要件定義から設計・開発までをAIで回す3つの箱
# 要件定義から設計・開発までをAIで回す3つの箱
「要件定義から設計・開発までをAIで回したい」。ここ数週間、この相談を何度も聞いている。
気持ちはよくわかる。ひとつのAIに任せれば、要件を読み、設計を起こし、コードを書き、テストまで回せそうに見えるからだ。
だが、 現場で本当に効くのは“一発で全部やらせる”ことではない。むしろ、工程ごとに引き渡し可能な箱を作る方が安定する。
OpenAIの Agents SDK では、オーケストレーション、ハンドオフ、ガードレール、人間レビューが分かれている。MCP の Resources は読むための文脈を、Claude Code overview は複数ファイルにまたがる作業とテストの実行を前提にしている。つまり、エージェントは「全部をひとつにまとめる」より、「何を渡し、何を受け取るか」を決める方が本質だ。
ひとつの長い指示が崩れやすい理由
要件定義、設計、開発は、同じプロジェクトの中でも問いが違う。
要件定義で問うのは、何を作るか、なぜ作るか、何をやらないかだ。設計で問うのは、どこを分けるか、どのデータが流れるか、失敗したらどう戻すかだ。開発で問うのは、どのファイルをどう変え、どう確かめるかだ。
この3つを1本の長いプロンプトに押し込むと、AIは平気で境界を飛び越える。要件の曖昧さを設計で埋め、設計の抜けをコードの推測で補い、最後にテストでごまかす。出力はそれっぽい。だが、後で直すときに地雷になる。
サーバーワークスの AI駆動開発の要件定義・設計・プロセスを体系化した記事 も、AIの出力を前提に評価と改善を回す重要性を整理している。そこにさらに必要なのは、フェーズごとの引き渡しの型だ。
引き渡しは3つの箱で考える
最初から巨大な仕様書を作るより、次の3箱に分けた方がずっと扱いやすい。
1. 要件箱
ここに入れるのは、目的、背景、制約、非目的、受け入れ条件、未決定点だ。
この箱の役割は、AIに「何を理解すべきか」を渡すことではない。むしろ、「何を勝手に決めてはいけないか」を明確にすることにある。
要件箱が薄いと、設計箱が勝手に要件を補完し始める。そこからズレる。
2. 設計箱
ここに入れるのは、画面やAPIの境界、データの流れ、エラー時の振る舞い、権限の分け方、テスト観点だ。
設計箱では、実装の細部よりも、どこで状態が変わるかをはっきりさせる。たとえば「登録できる」ではなく、「どの状態からどの状態へ遷移するのか」を書く。AIは文章の上手さより、状態の前後が揃っている方が強い。
3. 開発箱
ここに入れるのは、対象ファイル、変更順、確認コマンド、ロールバックの考え方だ。
Claude Code の overview が示すように、複数ファイルをまたぐ変更やテスト実行は、ちゃんと切り分けた方が回しやすい。開発箱があれば、AIは「どこを触るか」を迷いにくい。人間もレビューしやすい。
3箱をつなぐルール
3箱の考え方で大事なのは、箱の中身よりも「次の箱に渡してよい条件」を決めることだ。
たとえば、要件箱から設計箱に渡す条件はこうなる。
- 受け入れ条件が3つ以上書かれている
- 例外時の振る舞いが1つ以上ある
- 人間が決める論点が残っている
この条件を満たしていなければ、まだ設計に進めない。設計箱から開発箱に渡す条件も同じだ。
- 変更対象のファイルが見えている
- 影響範囲が説明できている
- 失敗時の戻し方が書かれている
OpenAI の agent evals が示すように、評価は飛ばすと意味がなくなる。AIの出力が良いかどうかは、見た目ではなく、箱の受け渡し条件を満たしたかで測るべきだ。
人間が残す場所を先に決める
AIでつなぐと言っても、全部を自動にする話ではない。
むしろ、止める場所を先に決める方が大事だ。OpenAI のドキュメントでも、Guardrails と human review は危ない作業の前で止めるための仕組みとして整理されている。
たとえば次のような境界は、人間に残した方がいい。
- 外部送信が発生する瞬間
- 権限や請求に触る変更
- 顧客向けの確約表現
- 既存仕様を壊す可能性がある差分
ここを先に決めると、AIは安心して速くなる。逆に境界がないと、速いだけで怖い。
MCP の Resources と Tools の分離も、発想は同じだ。読むための文脈と、動かすための手段を分ける。要件定義から設計・開発までの流れも、同じように読む箱、考える箱、動かす箱に分けた方が崩れにくい。
明日からやるなら
いきなり全社で変える必要はない。まずはひとつの案件で、次の3ファイルを作ればいい。
- `requirements.md`
- `design.md`
- `implementation.md`
各ファイルは1ページで十分だ。長くするより、渡す条件を書いた方が効く。
そして、AIに頼む前に次の3点だけ確認する。
- これは要件の話か、設計の話か、実装の話か
- 人間が決める論点はどこか
- どうなったら次の箱に渡してよいか
この3点が揃うと、AIは急に使いやすくなる。要件定義から設計・開発までをAIでつなぐとは、ひとつの魔法の指示を探すことではない。引き渡しの単位を小さくし、判断を見える化することだ。
この切り分けのいいところは、AIの失敗を小さく閉じ込められることだ。要件箱で迷ったら設計に進ませない。設計箱で迷ったらコードを触らない。開発箱で迷ったら、テストと戻し方を先に直す。全部を一気に直そうとしないだけで、手戻りはかなり減る。
実際、社内文書の下書きや問い合わせ対応でも同じだ。最初に「何を確定するか」「誰が決めるか」「どこで止めるか」を分けるだけで、AIの出力は急に読みやすくなる。AIの強さは一枚の完成度ではなく、次の箱に渡せる状態で返ってくることにある。
まとめると
AIは万能の1枚岩ではない。よく回るのは、要件、設計、開発の3箱を順番に渡す流れだ。
箱が小さくなるほど、AIは推測しにくくなる。人間はレビューしやすくなる。手戻りも減る。
「要件定義から設計・開発までをAIで」は、全部を丸投げする話ではない。むしろ、つなぎ目をちゃんと設計する話だ。ここを押さえると、AIはようやく現場の道具になる。
