AIエージェントのハルシネーションは「チケット駆動」で防ぐ～次世代アジャイル開発の実践論

AIにスクラム開発を任せるとコンテキストが崩壊し暴走する。
これを防ぐ現実解が、GitとチケットでAIに物理的ガードレールを設ける「チケット駆動開発」だ。
ここではAIの暴走を封じる実践手法から、ユーザーすら代替する次世代パラダイム「Loop Engineering」まで、開発プロセスの未来を紐解いてみる。

【参考】
AI開発の新潮流「Loop Engineering」を、Gitとチケット駆動（TiDD）で今日から安全に始める方法 #開発プロセス - Qiita

AIの暴走を物理的に封じ込める【Git × チケット駆動】のクローズドループ開発 #TiDD - Qiita

ちょっとAIにスクラム開発を任せてみたら破綻した話 #アンチパターン - Qiita

AIエージェントだけでスクラムを回してみた

Context Engineeringの次が来た??Loop Engineering

【1】AIでScrumのようなアジャイル開発プロセスを実装できるのか？

この疑問の意図は、AIがこれだけ進化していると、AIエージェントを人間と同一視することで、AI同士の相互作用により、より大きな効果が見込めるのか？だ。
人間も1人だけよりも、複数人の人格が異なる人達がそれぞれの強みを掛け合わせることで大きな威力を発揮する。
AIエージェント同士の協力関係でも似たような効果が得られるのか？

それは、AIエージェントによる1つの社会実験だ。
人間を使った社会実験は実際は出来ない。
しかし、AIエージェントを使えば、シミュレーションみたいに何度でもやり直しできる。

すると、ソフトウェア開発の文脈では、標準化された開発プロセスに対し、AIエージェントを使ってプロセス実装できるか？という疑問にたどり着く。

【2】AIでScrumプロセスを実装した事例が2つある。
1つは失敗した事例、もう一つは成功した事例だ。

失敗した事例は、ちょっとAIにスクラム開発を任せてみたら破綻した話 #アンチパターン - Qiitaになる。
記事を読む限り、AIはハルシネーションを多発し、自分自身が何をやるべきか混乱している感じだ。
まあ、能力の低い、できない開発チームはこんな感じになりやすい。

上記記事の面白い点は、AIが暴走してしまう点だ。
一人のAIに、プロダクトオーナー、スクラムマスター、開発者の役割切り替えを課すと、AIは混乱してしまった。
先輩たちに上記の記事を話したら、AIのコンテキストサイズに収まりきらず、記憶できなかったからでは？という指摘を受けた。
確かに、人間でも同様に3つの役割を課されると混乱するだろうが、AIでも同じなわけだ。

【3】そこで、AIの暴走を封じ込めるために、GitHubとチケット駆動というガードレールを入れた開発スタイルだ。

AIの暴走を物理的に封じ込める【Git × チケット駆動】のクローズドループ開発 #TiDD - Qiitaの記事になる。

（引用開始）
AIにプロセスやコンテキストの管理を丸投げすると、推測が発散して暴走と破綻を招く。
これを防ぐには、アーキテクチャによってAIの行動に物理的な「ガードレール（境界線）」を設ける必要がある。
**「チケット（Issue）による境界線設定」と「Gitによる絶対的な状態管理」**を組み合わせた『チケット駆動開発（TiDD）』は、現在の私たちが手応えを感じている、極めて現実的で強力なアプローチの一つである。
（引用終了）

興味深い点は、Issueというチケットを作業指示書とみなし、GitHubに蓄積されたリポジトリのソースコードを外部記憶媒体とみなして、AIのハルシネーションを起こさせない仕組みを作った点だ。
つまり、チケット駆動が起点になれば、AIにガードレールを自然に実装できることになるわけだ。

【4】この考え方を発展させると、AIによる開発プロセス実装を「Loop Engineering」で実装したい流れになる。

AI開発の新潮流「Loop Engineering」を、Gitとチケット駆動（TiDD）で今日から安全に始める方法 #開発プロセス - Qiita

（引用開始）
現在、AI開発の最前線では「プロンプトからループへ」というパラダイムシフト（Loop Engineering）が提唱されている。
しかし、AIを自律ループさせるフレームワークを現場でゼロから構築・運用するのは、まだハードルが高い。
そこで、既存の定着した技術である【Git × チケット駆動】を用いた構成が、手軽で安全な「Loop Engineeringの実装の第一歩」になり得ると考えている。
（引用終了）

僕の理解では、Harness Engineering ＝Scrumプロセス実装、ScrumチームそのものをAIで代替。
Loop Engineering ＝Scrumチームの外にいるユーザ自身もAIで代替。

上記の記事では、AIはScrumプロセスだけでなく外側のループも飲み込めるはず、と主張している。
この意見はすごく大胆だな仮説だ。
この意見が本当ならば、ソフトウェア開発も要件定義も全てAIでやらせてしまえばいい。
ソフトウェア開発を成功させるにはScrumの適用が一番だ。
そのScrumプロセスはAIで実装できる。
さらに、Scrumチームに要求を渡すユーザそのものをAIで代用できるならば、Scrumチームの外側もAIで代替できる。

AIがScrumプロセスを実装し、Scrumプロセスの外側も代替するならば、ソフトウェア開発の世界全体はAIで全て制御できるだろう。
たぶん、今、皆がこのアイデアを試している最中だろう。

AIは急激に進化しているので、今時点でうまくいかなくても、来年にはLoopEngineeringを超えた新たな概念が生まれて、問題解決してくだろう。
つまり、AIによる問題解決のレベルがどんどん上っていくだろう。

この進化の先も見届けたいと思う。