AIが書く時代、要件定義は「上」に移動する
Claude Code・Cursor 3・GitHub Copilot CLI などの登場で、コード生成そのもののコストはほぼゼロに近づきました。実装工数の8割をAIが担う現場も珍しくありません。
ところが実際に現場で起きているのは「もっと上流の曖昧さが、そのまま成果物の曖昧さになる」という現象です。AIに要件をぶつけると、書き手の意図の曖昧さが倍速で可視化されます。
2026年4月、Zenn で話題になった記事「AIがコードを書くほど、要件定義は上に移動する——Spec・Context・Harness 三層設計」は、この現象に対する実践的な整理を提示しています。本記事ではその三層設計を受託・発注の視点から読み解き、発注者・受託者の双方が押さえるべき新しい要件定義のあり方を解説します。
三層設計とは何か
レイヤーの定義
三層設計では、AI エージェントに与える情報を以下の3層に分けて整理します。
| 層 | 役割 | 含まれる情報 |
|---|---|---|
| Spec（仕様） | 「何を作るか」を定義 | ユースケース、受け入れ基準、非機能要件、禁止事項 |
| Context（文脈） | 「どういう前提か」を定義 | 既存コード、社内規約、業界慣習、ドメイン用語辞書 |
| Harness（足場） | 「どう検証するか」を定義 | テストケース、CI設定、評価指標、ロールバック基準 |
従来のウォーターフォール型要件定義では、これらが一枚の仕様書に混在していました。AI時代では混ぜると精度が落ちるため、明示的に層を分ける必要があります。
なぜ層に分けるのか
AIエージェントはプロンプトの構造に敏感です。同じ情報を渡しても、整理されていない情報は精度を大きく落とします。
- Spec だけだと「既存コードに馴染まない出力」になる
- Context だけだと「既存コードの延長だが、要件を満たさない出力」になる
- Harness がないと「動くが、誰も検証できない出力」になる
三層全てが揃って初めて、AIは「意図した動くコード」を出してくれます。
発注者側のメリット
1. 「認識のズレ」が早期に顕在化
発注者が Spec を書くプロセスで、自分が思っていたことと、本当に必要なことのズレに気づけます。従来は設計書に落とす段階まで気づかなかったズレが、Spec を書いた瞬間に露出します。
2. 見積もりの精度が上がる
三層が揃った要件は、受託側が見積もりを出しやすい形式です。どの層が未定義かが明確になるため、「ここが決まっていないので見積もりできません」「決まるまで設計フェーズに含めます」といった会話がクリアになります。
ホームページ制作の見積もりで起きがちなズレはホームページ制作費用ガイド2026、LP制作の場合はLP制作費用ガイドでも解説しています。
3. 「AIで作ったから安い」の誤解を避けられる
「AIが書くなら安いでしょ？」という発注は現場でよく起きますが、実装費が下がった分、要件定義と検証の重みが増しているというのが実情です。三層設計を使えば、見積もりのどこに費用が乗っているかを説明しやすくなります。
受託者側のメリット
1. 責任分界点が明確になる
- Spec が曖昧 → 発注者責任で再定義
- Context が古い → 受託者が最新化するか、発注者がアップデート
- Harness が無い → 検証責任を発注者・受託者どちらが持つか明示
三層設計は責任分界点の言語化そのものです。トラブルの8割は「誰がどこまで責任を持つか曖昧」から発生するため、この効果は大きい。
2. AI活用の効率が上がる
Spec・Context・Harness を分けて渡すことで、AIエージェント（Claude Code / Cursor / Codex など）の出力精度が上がります。Claude CodeワークフローやCursor 3 vs Claude Codeで紹介しているベストプラクティスも、突き詰めると三層設計の考え方に収束します。
3. ナレッジの再利用が進む
Context 層は案件横断で再利用できる資産になります。業界別のドメイン辞書・社内コーディング規約・セキュリティチェックリストを整備しておくと、次案件から立ち上がりが劇的に早くなります。
実務的な進め方
フェーズ1：Spec ドラフト（発注者主導）
まず発注者側が以下を書き出します。
- 目的：なぜこれを作るのか
- ユーザーと利用シーン：誰が、いつ、どう使うか
- 成功基準：何が達成できれば完了か
- 禁止事項・制約：やってはいけないこと
- 非機能要件：性能・セキュリティ・可用性
この段階では「実装方法」は書きません。What と Why に専念します。
フェーズ2：Context 収集（両者協業）
- 既存システム・データベース設計書
- 社内コーディング規約・命名規則
- 業界慣習・用語辞書
- 過去プロジェクトの教訓
これらは受託者が整理しますが、内容は発注者が一次ソースを提供する必要があります。
フェーズ3：Harness 設計（受託者主導）
- 受け入れテストケース
- CI/CD 設計
- ロールバック手順
- リリース後の監視項目
フェーズ4：AI ループの起動
三層が揃ったら、AIエージェントに Spec・Context・Harness を順に与え、以下のサイクルを回します。
- AIが実装ドラフトを作成
- Harness（テスト）で自動評価
- 失敗したら AI が修正
- 人間は「判断が必要な分岐」のみレビュー
この運用の実例はカウシェ AIレビュー自動マージ事例も参考になります。
よくある失敗パターン
- Spec と Harness を同じ人が書く — テストが Spec に引きずられ、要件漏れを検知できない
- Context が古い情報のまま — 半年前の情報で AI が動き、バグが量産される
- 三層を一度に書き切ろうとする — Spec は常に進化するもの。反復前提で薄く書き始める
- AI 出力の検証を人間の勘に頼る — Harness がないと、結局「レビュアの気分次第」になる
まとめ
「AIに任せれば速い」時代は既に来ていますが、上流の曖昧さを許さないという副作用があります。
- 三層設計の本質：Spec（何を）・Context（どういう前提で）・Harness（どう検証するか）を分離
- 発注者メリット：認識ズレの早期検出・見積もり精度向上・「AIで安く」誤解の解消
- 受託者メリット：責任分界の明確化・AI精度向上・ナレッジ資産化
- 進め方：Spec → Context → Harness → AIループの順に構築
AIエージェントが優秀になればなるほど、発注者の思考整理力と、受託者の構造化支援力が案件の成否を決めるようになります。AI活用の技術論だけでなく、要件定義というビジネスプロセスそのものを再設計する時期に来ています。
グリームハブでは、AIエージェント時代の要件定義伴走・Spec書き起こし・Harness設計支援を含む上流工程サービスを提供しています。AI開発で迷子になっている発注者の方は、ぜひ一度ご相談ください。
参考ソース
