AI開発でリリースが遅れ続ける理由と、その止め方

遅れは、事前にリスクとして書かれていました

重要だったのは、遅延自体が事前にリスクとして認識されていたことです。

全体アップデートの計画を立てたとき、AIはリスクの一覧を作っていました。35件並んでいて、その1つがこれです。

スコープ膨張による全体ローンチ遅延｜影響度：高

遅れることは、着手前から文書に書いてありました。

書いたのはAIです。この「スコープを広げるとローンチが遅れる」という指摘については、結果的にそのとおりになりました。

それでも私は、当初「あとでいい」としていた範囲を、「リリース前に完成させる」方針に変えました。全部そろった状態で出したかったからです。

想定作業量は66〜80時間まで膨らみました。

そして、書かれていたとおりに遅れました。

何を作っているのか、どういう体制で進めているのかはこちらです。

タスクが増える仕組み

今回の運用では、AIから「この仕様書は実装と食い違っています」「この関数は使われていません」「この処理は将来問題になる可能性があります」といった指摘が次々に出てきました。

その中には誤認もあります。こちらで確認して、対応不要と判断したものも少なくありません。

ただ、自分だけでは見落としていた重要な指摘が混じることもある。そこが難しいところでした。AIが挙げたから対応するのではなく、まず正しいかを確認し、そのうえで今やるべきかを判断する必要があります。

当時はその2段階の判断が十分に整理できておらず、「気づいたことはまず起票する」という運用に寄りすぎていました。結果として、処理する以上の速度でタスクが増えていきました。

起票漏れ対策が、今度はタスク増加につながりました

2026年7月7日、「タスク発生即時起票の義務」というルールを作りました。

起票漏れが続いていたため、「後で起票する」「まとめて起票する」を禁止し、発生した瞬間に必ず記録することにしました。

その3週間後の7月28日、今度は真逆のルールを作ることになりました。タスク総量の抑制です。

3週間の間に、今度はタスク総量を抑えるルールが必要になりました。

記録を徹底すること自体は必要でしたが、すべてを独立したタスクとして残すと、今度は対応対象が増えすぎます。

つまり必要だったのは、記録することと、今すぐ対応することを分けるルールでした。

遅延によって起きたこと

数週間の遅れで、販売開始のタイミングが後ろ倒しになり、営業予定も組み直す必要が出ました。

また、協力をお願いしていた飲食店とのアポイントも仕切り直しになりました。

ここで重要だったのは、遅延の兆候自体は事前に見えていたことです。

リスク一覧には「スコープ膨張による全体ローンチ遅延」と書かれていました。

つまり問題は、リスクを知らなかったことではなく、リスクを認識したうえで、どこまでを今回のリリース対象にするかという判断ルールが十分に機能していなかったことでした。

問題は、AIの性能より判断ルールの設計にありました

AIをProducer・Architect・Reviewer・Devのように役割ごとに分けて運用することはできました。

ただし、役割を分けるだけでは、どの改善を今やるか、どこから先は後回しにするかまでは決まりません。

開発を進める役割と、優先順位を判断する役割を同じ人が担うと、「せっかくならここまで完成させたい」という判断に寄りやすくなります。

15年間、クライアント様へのご支援では、着手前に合意した基準に照らしながら、いま進める場合の影響と、見送る場合の影響を一緒に整理してきました。

AI開発でも必要だったのは同じで、AIの指摘を受けたあとに、人が優先順位を判断する基準でした。

また、事業を進めるか止めるかといった最終判断までAIに委ねるべきではないと考えています。AIの指摘自体が間違っていることもあるため、最終的には事業全体を見て人が判断する必要があります。

同じ出来事を、判断の側から書いた記事があります。 → 新規事業の撤退基準は、着手前に決める

どう止めたか

そこで、AIから出てくる改善候補を選別するために、運用ルールを整理しました。大きく4つです。

同梱できる副次タスクは本体にまとめる。他のタスクと同時に対応できるものは同時に行う。現時点でユーザー影響がなく、将来的な懸念として残すものはpendingに格納する。そして新しいタスクに着手するたびに、「同梱できるものはないか」「実装順序はどれが適切か」を確認する。

特に効いたのが4つ目です。着手のたびに毎回確認するので、忘れようがありません。

判断基準は3つに絞りました

「起票するかどうか」を毎回考えていると、それ自体が時間を使います。

仕様書の古さや、ユーザーには見えない内部品質の問題は起票せず、常設のリストに1行足すだけにしました。

同じファイル・同じ主題の是正は、別タスクにせず、本体に同梱します。

そして、「ユーザーが困っていない」かつ「課金・セキュリティ・本番の安定性に影響しない」ものは、起票しない。

中でも、3つ目が一番大事です。

「やったほうがいい」と「やらないと困る」は別物だと、基準として書き下しました。

効果

効果は、数字にも出ました。

ルール前は、1つのタスクをクローズするたびに、派生タスクを3〜10件、新規に起票していました。処理速度より増加速度のほうが速い状態です。

ルール後はこうなりました。

あるタスクでは、派生7件をすべて常設リストに集約し、独立したタスクを1本も作らずにクローズしました。

別のタスクでは、派生10件を常設リスト送りにして個別起票ゼロ。

すでに起票してしまったタスクを取り消して本体に同梱した例もあります。AIが「これはルール違反です」と判定して差し戻してきました。

ある依頼は、調べた結果「やらない」と判定してクローズしました。

常設リストの未処理は現在65件あります。

これは放置ではなく、いまは着手しないと決めたものです。

この区別は重要です。放置は忘れることですが、こちらは記録したうえで「いまは着手しない」と決めた状態です。

記録を減らしすぎても問題が出ます

一方で、タスクを増やさないことだけを優先すると、必要な記録まで失う可能性があります。

タスクファイルを一切作らずに26回分の変更を進めたことがありました。

何をやったかの記録がコミット履歴にしか残らず、レビューも実装後に1回だけ。その結果、有料会員向けの制限が消えていたのを見逃しました。

だから、「起票しない」と「記録しない」は別です。

常設リストに1行残すのが最低ラインです。1行あれば、後で拾えます。

まとめ

• AIの指摘には誤りもある一方、自分だけでは気づけなかった重要な論点が含まれることもある
• だから、まず「その指摘は正しいか」、次に「正しくても今やるべきか」を分けて判断する
• 遅延を抑えるには、AIの性能だけでなく、どこまで今やるかを判断するルールが必要

改善候補は、探そうと思えばいくらでも出てきます。

だからこそ、優先順位を付けるだけでなく、「今回はやらない」「後で扱う」と決める基準が必要です。

AIが候補を出し、人が正誤と優先度を判断する。この役割分担が重要だと考えています。

判断の選択肢は二択ではありません。その整理はこちらの記事に書きました。