人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる
「人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる」という言葉に惹かれた。
アイデアをラフなメモ書き。
【参考】
チケット駆動でAIを制御する仕組みのアイデア: プログラマの思索
AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論: プログラマの思索
TkDD: Ticket-Driven Development and the Knowledge We’re Throwing Away
AI開発の新潮流「Loop Engineering」を、Gitとチケット駆動(TiDD)で今日から安全に始める方法 #開発プロセス - Qiita
AIの暴走を物理的に封じ込める【Git × チケット駆動】のクローズドループ開発 #TiDD - Qiita
ちょっとAIにスクラム開発を任せてみたら破綻した話 #アンチパターン - Qiita
【1】AIによるソフトウェア開発はもはや当たり前と思う。
しかし、AIが生成したプログラムに対し、テスト駆動開発や仕様駆動開発だけの品質保証だけでは物足りないのでは?と個人的に考えている。
案件のコンテキスト、その人個人が持つコンテキスト、既成組織が今までに築いてきた組織文化(ドキュメント化されていないノウハウ)無しで、AIがソフトウェア開発できるか?
実際、「人間が作ったプログラムは品質基準に対し不足する要素が多すぎるが、AIが作ったプログラムは余計なものをたくさん作りすぎる。AIは品質基準を超過しすぎる」傾向がある。
@takaiよりこの言葉を聞いて、思わずなるほど、と思った。
つまり、AIによるプログラミングの速度が速すぎるために、AIは、人間が用意したスコープ以上の成果物をたくさん作り出してしまう。
AIは無駄な機能をたくさん作ってしまう。
そこで、AIが生成したプログラムに対して、テスト駆動開発や仕様駆動開発で、品質を担保しようとする。
しかし、AIはテストプログラムもすぐに作れてしまう。
つまり、AIはたくさん作った無駄な機能に対しても、テストプログラムを作って、いくらでもきちんと動くものを作ってくれる。
本来は、人間がこれだけのスコープでいいよ、と前提条件や制約条件をたくさんプロンプトに書き込んでやらないといけない。
AIはこれ以上無駄な機能を作るな。
AIは、人間が指定した前提条件の範囲内で機能を作れ、と。
しかし、この前提条件をすべて書き出すのは難しい。
自分の頭の中にあるやりたいことは曖昧だ。イメージしかない。
案件特有のコンテキストは、たくさんのドキュメントの行間に埋もれている。
既成組織が今までに積み上げてきた標準プロセスは、過去のたくさんの障害やレビュー、プロセス改善の経緯を踏まえて、たくさんの改訂を反映して、作られてきている。
そんな過去の経緯までAIは知らない。
また、今は、AIが暴走して無駄な機能を作らないように、人間がコードレビューやゲートレビューを各工程でガードを掛けている方針が各チームでやっている。
たとえば、CodexやClaudeCodeでは、skills.mdにたくさんの手順を入れ込んだり、AIの中間成果物を途中でコードレビューしているだろう。
だから、今は、プログラミングしているよりも、コードレビューばかりやっている人が多いだろう。
むしろ、AIによるプログラミングの速度が速すぎるために、人間のコードレビューがボトルネックになっているわけだ。
【2】そこで、AIの暴走を防ぐために、チケット駆動で制御する発想は良いと考える。
AIにローカルなコンテキストを読み込ませるために、GitHubのIssueに「AIへの作業指示書」「AIとやり取りした意思決定の履歴」「AIとやり取りして試行錯誤した履歴」を残すやり方は、一つの解決策ではないかと考える。
@tokudiroのアイデアがそうだ。
AI開発の新潮流「Loop Engineering」を、Gitとチケット駆動(TiDD)で今日から安全に始める方法 #開発プロセス - Qiita
AIの暴走を物理的に封じ込める【Git × チケット駆動】のクローズドループ開発 #TiDD - Qiita
ちょっとAIにスクラム開発を任せてみたら破綻した話 #アンチパターン - Qiita
【3】@tokudiroのアイデアを僕なりに理解した内容が下記になる。
【4】「AIの暴走をチケット駆動で制御する」アイデアは、世界中で皆考えているようだ。
下記記事では「チケット駆動開発」を「TkDD」と呼んでいる。
Ticket Driven Developmentの略だ。
下記記事の文中にある「AIに欠けているものは思考プロセスとその変化」という言葉が心に引っかかった。
TkDD: Ticket-Driven Development and the Knowledge We’re Throwing Away
【5】このアイデアをもっと試してみたいと思う。
| 固定リンク
« 「System of Systems(SoS)の統合テストは不可能だ」という言説を聞いた | トップページ | AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi »
「ソフトウェア工学」カテゴリの記事
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- AI時代のソフトウェア開発者とはアーキテクトの役割として再定義される(2026.08.30)
- AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi(2026.08.22)
- 人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる(2026.08.16)
- 「System of Systems(SoS)の統合テストは不可能だ」という言説を聞いた(2026.08.16)
「チケット駆動開発」カテゴリの記事
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- 人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる(2026.08.16)
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)


コメント