AI開発が常識化した今、AIの「暴走」とローカルな文脈理解の欠如がソフトウェア開発現場の障壁だ。
本稿では、AIのハルシネーションを物理的に封じ込める最適解「チケット駆動」の実践論を考えてみた。
IssueをAIへの作業指示書とし、Markdownで文脈を制御する次世代アジャイルの真髄と、AIスクラム適用の限界に迫ってみた。
【参考】
AIエージェントのハルシネーションは「チケット駆動」で防ぐ～次世代アジャイル開発の実践論: プログラマの思索
AI開発の新潮流「Loop Engineering」を、Gitとチケット駆動（TiDD）で今日から安全に始める方法 #開発プロセス - Qiita
AIの暴走を物理的に封じ込める【Git × チケット駆動】のクローズドループ開発 #TiDD - Qiita
ちょっとAIにスクラム開発を任せてみたら破綻した話 #アンチパターン - Qiita
【1】2026年現在、プログラミングは全てAIに任せて開発するのが当たり前だろう。
もはや手作業のプログラミングは、伝統工芸と同じレベルに落ちた。
わざわざプログラミングを手作業で一つずつ書くのは、時間もかかるし、品質も不安だ。
むしろAIにやらせた方が楽だ。
しかし、設計、コーディング、テスト、ビルド、デプロイのすべての作業をAIに任せたとしても、人間の作業がなくなるわけではない。
むしろ、AIは暴走しやすいので、いかにAIをコントロールすべきか、に皆頭を使っているのではないだろうか。
【2】では、「AIによるプログラミング自動化」の問題点は何だろうか？
僕は3つあると思う。
1つ目は、AIはその人だけのコンテキスト、案件特有のコンテキスト、チームや組織の文化に根ざしたコンテキストがとても弱い。
2つ目は、AIは汎用的な知識だけで、私たちの意図を超えた範囲まで、勝手に機能実装したり、成果物を改変してくる。
つまり、AIは余計なお世話が多い。
3つ目は、AIはWordやPDFなどのドキュメント類をいきなり出力させると、意図しないレイアウトや思い通りでない内容が出る場合がある。
これもAIが余計なお世話を焼きすぎる。
【3】「AIはその人だけのコンテキスト、案件特有のコンテキスト、チームや組織の文化に根ざしたコンテキストがとても弱い」問題は、昔からずっと言われているAIの弱点だ。
たぶん、AIのコンテキストバッファは限定されていて、AIにローカルなコンテキストを保持させるにはコンテキストバッファは小さすぎる。
では、どうやって問題解消すべきか？
解決策の一つは、プロンプトを作業指示とみなし、GitHubのIssueに作業指示書として書く。
AIはIssueを前提条件かつ作業指示書とみなして実行してくれる。
@tokudiroによれば、プロダクトバックログを作って、AIにPBLに従ってプログラミングさせるやり方は上手くいくらしい。
しかし、PBL自身をテキストファイルで管理し、GitHubで管理するのは面倒だったらしい。
そこで、PBLに書いた製品の要件を全てGitHubのIssueに書き出して、PBLの優先順位をIssueの優先順に対応付けると上手くいったらしい。
理由は、作業指示書のIssueがたくさん存在し、Issueに基づいてコミットした履歴がIssueと紐づくことで、ノウハウやナレッジがAIにも蓄積されるからだろう。
つまり、Issueに従ったAIによるコミットは、AI自身がローカルなコンテキストを蓄積出来ていることを意味するのだろう。
すなわち、蓄積されたIssueとIssueに紐づくコミット履歴は、AI自身のノウハウ、ナレッジになるのだろう。
この解決策の良い点は、Issueにナレッジを貯める意識がなくても、PBLに沿ったIssue一覧とIssue実行履歴により、自然にAI自身にナレッジやノウハウが溜まることだろう。
結局、AI自身に経験主義を実践させて、ローカルなコンテキストを認識させているわけだ。
別の解決策は、AIとチャットしながら、試行錯誤したり、意思決定して何かを選択した履歴は、Issueコメントにすべて残す。
たとえば、AIに相談して、プログラミングの選択肢を3つ挙げさせた。
3つの選択肢のうち、1つを選んで、AIにIssueを書かせて実行させる。
その選択肢を実行させて、結果を見て、やはりこの選択肢は止める、という履歴もIssueコメントに残す。
@tokudiroによれば、AIとのチャットを別のチャット画面でやり取りさせるならば、Issueコメントに全て書き残せばいいと思いついたらしい。
Issueコメントに意思決定の履歴、試行錯誤の履歴も全て残せば、ローカルなコンテキストは全てIssueに集約される。
AIには、過去のIssueを全部読んでおけ、と言えば、ローカルなコンテキストを理解してくれる。
この解決策の良い点は、Issueコメントはmarkdownで書けるので、AIと相性がいい。
また、Issueコメントもmarkdownで書いた方が人間も読みやすい。
さらに、AIとのやり取りが複雑になれば、Issueを分割して、新規Issueに新たな作業指示書を書けばいい。
つまり、AIにローカルなコンテキストを理解させるために、Issueに作業指示書、ならびに、意思決定や試行錯誤などの履歴も集約させて、AIにIssueを読み込ませるわけだ。
GitHubならば、ソースコードの全てが存在し、コミット履歴もすべて残っているので、AIに案件特有のコンテキストもGitHubリポジトリそのものを読み込ませればいい。
すなわち、AIに読み込ませるローカルなコンテキストは、GitHubというIssueTrackingSystemそのものなわけだ。
【4】「AIは汎用的な知識だけで、私たちの意図を超えた範囲まで、勝手に機能実装したり、成果物を改変してくる」問題は、AIは先走りすぎて暴走してしまう弱点だ。
解決策は、上記の通り、プロンプトではなく、Issueを作業指示書としてAIに実行させることだ。
AIにガードレールを課すことと、IssueをAIの作業指示書として扱うことは同義だ。
【5】「AIはWordやPDFなどのドキュメント類をいきなり出力させると、意図しないレイアウトや思い通りでない内容が出る場合がある」問題は、ソースコードだけでなく、ドキュメント類もAIで自動化させたいのに上手く制御できない点にある。
単純なアイデアは、GitHubリポジトリのソースコードから、ユーザマニュアルをPDF出力せよ、とAIに直接指示させることだが、そのやり方では上手くいかなかった、と@tokujiroは言う。
やはり、ドキュメントの粒度や整合性、フォーマットなどをAIに指定しないと、AIは勝手に作ってしまう。
そこで、AIにまず、ユーザマニュアルや設計書に相当するテキストをmarkdownで出力させる。
ユーザマニュアルや設計書に相当するmarkdownファイルをインプットとして、AIやPandocでPDFやWordに出力するやり方を取る。
@tokudiroによれば、AIとmarkdownは相性が良いので、中間成果物としてmarkdownを出力させるのが良いらしい。
この意見は僕も同意する。
AIはテキストに強い。
特にAIはmarkdownに強い。
だから、まずドキュメント類そのものをテキスト出力し、フォーマットも別のmarkdownで指定して、AIに実行させる方がいいだろう。
【6】AIでプログラミングがいくら効率化されて自動化出来たとしても、人間によるコードレビューは必要だ。
@tokudiroと話していて気づいた点は、品質基準は人間だけが持っている。
AIに品質基準を持たせたとしても、最終的な品質基準は人間だけが最終決定するからだ。
つまり、人間がAIが生成したコードをゲートレビューしている状況と同じだ。
その時、人間によるAI生成済みソースコードのコードレビューはどうやるといいのか？
ここでも、AI自身にGitHubからDiff出力させて、そのDiffを人間がチェックする方法が良いだろう。
Diff自体もテキストなのでAIも扱いやすい。
人間にとっても、ソースコード全体は読めないが、Diffならば読みやすくなる。
今は、人間がプログラミングしなくなっても、大量のコードレビューが必要であり、コードレビューに時間がかかってボトルネックになっている状況だ。
結局、人間自身がボトルネックになっているわけだ。
【7】上記が「チケット駆動でAIを制御する仕組みのアイデア」だ。
ここから次の問題が思いつく。
「AIは監査プロセスを実装し実現できるのか？」
「AIはScrumプロセスを実装し実現できるのか？」
現代のソフトウェア開発では、Scrumでプロセスを回すのが主流だ。
すると、当然AIにScrumを回したくなる。
たとえば、開発チームの開発メンバーを複数のAIエージェントに任せてプログラミングさせて、スクラムマスターもAIに任せてスクラムチーム内の障害解決を担当させることができるだろう。
プロダクトオーナーさえも、PBLの元ネタとなる要求を渡せば、AIに任せられるだろう。
スクラムガイドをAIに事前に読み込ませれば、プロセスも役割もイベントも成果物もAIは理解するだろう。
では、本当にそれだけで、AI自身がScrumというプロセスを回せるのだろうか？
同様に、たとえば、ISO9001、A-SPICE、機能安全、サイバーセキュリティなどの規格に沿ったシステム監査がある。
これらの規格は、膨大なドキュメントとして手順、ワークフローシステム、制約条件などが細かく定義されている。
これらの規格のドキュメントをインプットにすれば、AIは一連のプロセスを理解するだろう。
では、本当にそれだけで、AI自身が規格に沿った監査プロセスを回せるのだろうか？
直感的には僕は疑問に感じる。
たったそれだけでAIが上手くいくならば、既に色んな人が試して、運用されている事例が出てくるだろう。
しかし、今時点ではそんな成功事例を聞かない。
なぜならば、AIはローカルなコンテキストに弱いからだ。
AIの暴走をチケット駆動で制御するアイデアは、IssueTrackingSystemに、人間とAIが相互会話した履歴を残し、Issueを作業指示書としてAIにガードレールを課すことで、AIを制御できる点にある。
この発想を、AIへScrumの適用、AIへ監査プロセスの適用を当てはめなければ、上手くいなかいだろうと直感する。
最近のコメント