「実案件でしか分からないこと」だけを実案件で学ぶ — AIエージェント時代のSDLC設計

AIエージェントをソフトウェア開発に導入するとき、多くの組織は「まず小さなタスクで試し、問題が見つかったら改善し、少しずつAIに任せる範囲を広げていく」という段階的なアプローチを取る。これは間違いではないが、実務では一つ大きな問題がある。学習が遅いのだ。実案件を一つ最後まで進めるには要求整理から設計、実装、テスト、リリースまで一連の工程が必要で、その結果として「要求を曖昧に渡したらAIが補完してしまった」「人間のレビューを減らしたら内部品質をどう担保するか分からなくなった」といった問題を、数日から数週間後に初めて学ぶことになる。しかし、こうした問題の中には実案件をやらなくても事前に分かるものがかなり多い。

著者は導入時の問題を三つに分けることを提案する。一つ目は「実験しなくても設計できること」。例えば人間のレビューを外すなら代わりの品質保証が必要、本番環境を変更するなら変更可能な範囲を制限する必要、といったことは演繹で事前に洗い出せる。二つ目は「実案件でなくても検証できること」。過去のレビュー指摘やバグ、テストケースがあれば、AIがそれらを検出・修正できるか机上で試せる。三つ目が「実案件でしか分からないこと」。チームがAIと人間の役割変更を受け入れられるか、大規模コードベースで未知の失敗が起きるか、といった現実的な課題だ。つまり、最初から全部を実案件で学ぶのではなく、演繹できることは先に設計し、疑似環境で検証できることは先に検証し、実案件でしか分からないことだけを実案件で学ぶということだ。

もう一つ重要な指摘は「何を決めてよいか」だけではなく「何を決めてはいけないか」を明示すること。人間なら曖昧な要求を見て「PdMに聞いた方がいい」と判断するが、AIエージェントは必ずしもそうしない。もっともらしい回答を生成でき、曖昧さを推論で埋め、その解釈がステップを踏むごとに確定事項になっていく。AIの自律性を高めるほど、「決められることリスト」より「決めてはいけないことリスト」の方が重要になるのだ。組織はこれを、要求定義の段階で構造化して明示する必要がある。