TL;DR
- 「AIアシスタントに役割を与えて勝手にスクラム開発させよう」と2.5ヶ月間試みたが、プロセスは見事に崩壊した
- プロセスの無視、ハルシネーションの連鎖、物理的なファイル競合によるマージ地獄など、AIの推論特性に起因する5つの事象を確認
- 現状のAIに自律的なプロセス管理を丸投げするのは時期尚早。ただ、AIが真面目に暴走する様子を観察する2.5ヶ月の試行錯誤は純粋に楽しく、現実的なアプローチ（人間が統制・AIが実行）へ切り替える良いきっかけになった
背景
ふと、「AIにプロンプトで『あなたはPO、あなたはスクラムマスター、そしてあなたは開発者ね』と役割を与えれば、自動でスクラム開発を進めてくれるのではないか？」という怠惰な思いつきから、AIスクラム開発を試してみました。
専用のマルチエージェントフレームワークなどは使わず、普段使っているCLI型AIアシスタントにプロンプトで指示を出すだけの軽量な検証構成です。
しかし検証自体は本格的で、普段の日常的なソフトウェア修正作業をすべてこの「AIスクラム開発」に置き換え、実際の開発サイクルの中で機能するかをあえて長期にわたってテストしてみました。
しかし結果として、AIにプロセス管理を丸投げするのは極めて困難であり、AIによる「ひとりスクラム」は見事に崩壊しました。
本記事では、その過程で起きた「AIならではのスクラム崩壊の事象」について備忘録としてまとめておきます。
検証において発生した課題（5つの事象）
約2.5ヶ月間、実際の修正作業を通じて試行錯誤を繰り返しながら、単一のAIアシスタントにスクラムプロセスを丸投げしてみた結果、主に以下の5つのプロセス崩壊が確認されました。
1. スクラムイベントの形骸化
LLMは本質的に「与えられた課題（プロンプト）に対する即時解決」を指向します。
そのため、「今はプランニングフェーズである」という制約を与えても、バックログ上にIssueが存在すると、プロセスを無視して直接コード修正（解決）に飛びついてしまう挙動が頻発しました。人間が定義した「プロセスや儀式の順守」を自律的なエージェントに強制することは至難の業でした。
2. プランニングの崩壊（会話上の連携の限界）
プランニングフェーズにおいて、プロンプトで複数の役割を与えて自律的に対話（計画立案）させようと試みましたが、単一のチャットセッション内でロールプレイを維持すること自体が困難でした。
仮に役割（人格）を切り替えながら対話させても、コンテキストが混ざってしまい、役割を切り替えるたびに前の役割の誤った推測（ハルシネーション）を無批判に引き継ぎ、要件からどんどん逸脱していくのが関の山です。単一のAIを用いた自己完結型の「会話による合意形成」プロセスは、現状の気軽なやり方ではどのみち成立しないと早々に諦めました。
3. アーキテクチャの破壊とマージ競合
実装フェーズに入ると、今度は物理的なファイルの操作において以下の2点が深刻な問題として浮上しました。
- 局所最適化による設計破壊: バグ修正などにおいて、AIはシステム全体の設計を考慮せず、最短で動作する解決策を即座に適用する傾向があります。パッチコードで解決してしまい、そのあと、それが大量に全体のコードを汚染しました。
- 状態同期の欠如（物理的なファイル競合）: 前項のプランニングが「会話のすれ違い」であったのに対し、こちらは「物理的なファイルの相互上書き」です。AIアシスタント自身が自律的にワークフロー（サブタスク）を切り出し、バックグラウンドで複数の作業を並行して走らせた結果、プロセス間でコード変更状況を認識（ファイルロック等の協調）できず互いの成果物を上書きし合う事態が発生。最終的にマージコンフリクトが多発し、その競合解決のためにAIがリソースを使い果たし、APIの利用コスト（トークン代）と時間を際限なく浪費する無限ループに陥りました。
4. ベロシティ計測の崩壊
プランニング時の「大・中・小（Tシャツサイズ）」での相対見積もり自体は、過去の基準を記録させることでAIにも正しく行わせることができました。
しかし、それを消化する「ベロシティの計測」は全く成立しませんでした。主な原因は以下の2点です。
- AI自身が「現在時刻」を正確に参照できず、作業にかかった経過時間を勘違いしてしまう。
- AI側のコマンド実行許可待ちなど、システム側の待機時間がノイズとして混入してしまうため、純粋な「タスクの消化時間」が計測不能となる。
5. レトロスペクティブによる行動変容の欠如
スプリント終了時のレトロスペクティブにおいて、AIに原因分析と改善策の提示を求めたところ、もっともらしい反省文を出力してくれました。
しかしLLMの構造上、テキストによるフィードバックが次回のセッションの永続的な行動基準（重み）に直接反映されるわけではありません。プロジェクトの規約ファイル（AI用のルール定義等）にどれだけ反省事項を記録しても、次のスプリントにおいて全く同様のミスがさんざん繰り返される結果に終わりました。
一時的な対策とその限界
上記の課題に対し、「人間がPOおよびスクラムマスターを兼任し、AIの行動を都度管理・修正する」という運用へ切り替えてみました。
これによりスクラムとしての体裁は辛うじて維持できたものの、人間側へのマイクロマネジメントの負荷が極めて高く、「開発プロセスの自動化・効率化」という当初の目的から完全に逸脱する結果となってしまいました。
考察
今回の検証から得られた教訓は以下の通りです。
- 得意・不得意の境界線の発見: LLMは「与えられた課題を最速で解く」ことにおいては天才的ですが、「人間と同じようにプロセスを管理し、アジャイルの儀式を守る」ことは根本的に苦手です。この境界線を明確に引けたことが最大の収穫でした。
- 単一AIによる「ひとりスクラム」からの卒業: プロンプトだけで複数人の役割を演じ分けさせるアプローチはコンテキスト崩壊を起こします。AIには「役割」ではなく「明確に区切られた単一のタスク」を与えるべきだと分かりました。
- 専用フレームワークの可能性とLLMの現在地: 「専用のマルチエージェントフレームワーク等を使えば解決するのでは？」という声もあるでしょう。確かにファイル競合（事象3）や時間計測（事象4）は緩和可能です。しかし、プロセスの無視（事象1）やハルシネーションの連鎖（事象2）といったLLMの推論特性そのものに起因する課題は残ります。だからこそ、無理にAI同士を協調させるのではなく、今のAIの強みを100%活かせる別のアーキテクチャを模索する余地があります。
おわりに：失敗を楽しむという知見
「全自動スクラム開発」はまだ夢の続きでしたが、これは決して悲観的な結末ではありません。
AIにプロセス管理を丸投げできないと分かったことで、「人間がプロセスを統制し、AIには実行のみに専念させる」という現実的なアプローチに切り替える良いきっかけになりました。
なにより、この2.5ヶ月間にわたる「AIが真面目に暴走し、見事に自滅していく姿」を観察する試行錯誤の過程自体が、技術的にとても刺激的で純粋に楽しい時間でした。
本記事が、AI活用に試行錯誤する皆さまにとって、クスッと笑える現時点でのアンチパターンとして楽しんでいただければ幸いです。