はじめに
AI駆動開発の世界では、今さまざまな手法やキーワードが次々と登場しています。
- プロンプトエンジニアリング
- コンテキストエンジニアリング
- 仕様駆動開発（SDD: Specification-Driven Development）
- エージェンティックワークフロー
- ハーネスエンジニアリング（Harness Engineering）
- Vibe Coding
新しい概念が次々と登場し、「結局どれが正解なのか？」と迷っている方も多いのではないでしょうか。
私たちのチームでも、約6週間にわたってこのテーマを週次で議論し続けました。CursorやGitHub Copilotを業務に本格導入し、複数のプロジェクトで実践を重ねながら、それぞれが異なるアプローチを試してきました。
その結果、興味深いことが分かりました。
入り口となる手法は多様だが、突き詰めていくと本質的には同じ結論に収束する。
本記事では、現場での実践と議論から得られた「AI駆動開発の本質」について、個々の手法に囚われすぎず本質的な部分に焦点を当てて考察します。
目次
- 手法の乱立と、その裏側にある共通構造
- AI駆動開発の進化系譜 ― 三つのエンジニアリング
- 開発者の役割の本質的な変化
- ドキュメントとコードの一元化 ― SSOTの再定義
- コンテキストは「足し算」ではなく「引き算」で設計する
- AI出力の品質保証 ― 自然言語では担保できない領域の扱い方
- レビューの再発明という避けて通れない課題
- 手法より重要な「アジャイルな姿勢」
- 結論 ― 全ての手法は一点に収束する
1. 手法の乱立と、その裏側にある共通構造
1.1 なぜこれほど多くの手法が登場するのか
AI駆動開発に関する手法が次々と生まれる背景には、LLM（大規模言語モデル）の二つの特性があります。
- 非決定的である ― 同じ入力でも出力が揺れる
- コンテキスト（文脈）に強く依存する ― 何を渡すかで出力品質が劇的に変わる
この二つの特性をどう制御するかが全ての手法の出発点です。制御の切り口が異なるため、手法が多様化するのです。
1.2 全ての手法に共通する三つの要素
しかし、どの手法を深掘りしても、結局は以下の三要素に帰着します。
| 要素 | 役割 |
|---|---|
| インプット設計 | AIに何を渡すか（コンテキスト） |
| プロセス設計 | どの順序で何をさせるか（ワークフロー） |
| アウトプット検証 | 出力をどう検証し、フィードバックするか |
SDDは「プロセス設計」を軸にした手法であり、コンテキストエンジニアリングは「インプット設計」を、ハーネスエンジニアリングは「アウトプット検証」を軸にした手法です。それぞれ強調点は違えど、三要素を包含するという点では同じです。
つまり、どの手法を選んでもゴールは「この三要素を適切に設計する」ことに集約される。
2. AI駆動開発の進化系譜 ― 三つのエンジニアリング
2.1 三つの進化の系譜
業界で登場してきた手法は、実は綺麗な進化の系譜を描いています。
（1） プロンプトエンジニアリング
┗(AIへの指示の工夫)
↓
（2） コンテキストエンジニアリング
┗(AIに与える文脈全体の設計)
↓
（3） ハーネスエンジニアリング
┗(AI出力の機械的な品質保証)
（1） プロンプトエンジニアリング
「良い質問を書けば良い答えが返る」という、最も初期のアプローチです。単発の指示（Prompt）を工夫する段階。
（2） コンテキストエンジニアリング
プロンプトだけでは足りず、「どのファイルを読ませるか」「どんなルールを事前に与えるか」「過去のチャット履歴をどう扱うか」といった、AIに与える文脈全体を設計する段階。
SDDやエージェンティックワークフローは、このコンテキスト設計を「工程」として定型化したものと捉えることができます。
（3） ハーネスエンジニアリング
コンテキストをいくら整えても、自然言語の指示だけではLLMが制約を100%守っているかを証明できません。そこで、リンターやスクリプト、CLIコマンドといった 機械的なチェック機構（Harness） をローカル開発サイクルに組み込み、AI出力を自動検証する段階へと進みます。
CI/CDのようにプッシュ後に実行するのではなく、AIがコードを生成している最中のフローに組み込む のが特徴です。「整合性駆動開発」とも呼ばれます。
2.2 系譜が示していること
この進化は「古い手法が捨てられる」ものではなく、各段階が下位層として積み重なっていく ものです。ハーネスエンジニアリングを実践していても、内部ではコンテキスト設計やプロンプト設計を行っています。
新しい手法が出たからといって焦って乗り換える必要はなく、自分たちが今どの層を扱っているかを自覚することが重要です。
3. 開発者の役割の本質的な変化
3.1 「コードを書く人」から「指示書を設計する人」へ
ある現場では、開発工数の大半が「超詳細設計（実装計画書）」の作成とレビューに費やされるスタイルへ移行しました。実装計画書さえ正確であれば、AIによるコード生成自体は（生成する規模にもよりますが）ごく短時間で完了してしまいます。
この変化が意味するのは、開発者の価値が以下のように移動したということです。
Before: タイピング速度 × ロジック構築力
After : 業務理解の深さ × AIへの指示書の設計力
3.2 Vibe Codingだけでは到達できない領域
「雰囲気（Vibe）でAIと対話しながらコードを書く」Vibe Codingは、入門として優れていますが、プロダクション品質に必要な以下の要素はカバーできません。
- テスト観点の網羅性
- コード品質と可読性
- チームのコーディング規約への準拠
- ドメイン知識に基づく妥当性判断
これらを担保するのは、依然として人間の責務です。「AIに任せる」のではなく「AIに任せられる状態を人間が設計する」 のが、AI駆動開発における開発者の真の仕事です。
4. ドキュメントとコードの一元化 ― SSOTの再定義
4.1 「仕様書はもう要らないのでは？」問題
AI時代になって最初にぶつかる問いがこれです。
最新のソースコードが正解であるなら、別途仕様書を持つ意義は何か？
この問いに正面から向き合うと、仕様書の役割を再定義する必要に迫られます。
4.2 仕様書は「正解」ではなく「目次（インデックス）」である
私たちが辿り着いた結論は次の通りです。
仕様書は「正解そのもの」ではなく、「複雑なブラックボックスを探索するためのインデックス」である。
メソッド数の多いクラスに対して、AIがソースコードをゼロから解析するのは極めて非効率です。人間が理解しやすい自然言語で書かれた「1対1対応の仕様書」をMasterとして保持しておくことで、AIの変更特定精度と速度が飛躍的に向上します。
4.3 DocCommentアプローチ ― コード自体を仕様書へ昇華させる
SDD最大の弱点は「仕様書とソースコードが乖離する」ことです。そこで、別ファイルで仕様書を管理するのではなく、ソースコードのメソッド上部に詳細な自然言語の仕様（ブロックコメント）を記述する というアプローチに収束しました。
/**
* 【ダッシュボード画面】の売上サマリーを取得する。
*
* - 対象店舗: 呼び出し元で指定された店舗ID
* - 集計期間: 当日0:00 〜 現在時刻
* - 返品・取消レシートは集計から除外する
* - ユビキタス言語: 「売上サマリー」は税込金額の合計を指す
*/
fun fetchSalesSummary(storeId: String): SalesSummary { ... }
このアプローチには二つの大きな価値があります。
（1）AIのコンテキスト理解を助けるメタデータとして機能する
複雑なロジックをAIに1行ずつ解析させるのはトークン消費が激しく、ハルシネーションのリスクも高い。メソッド上部の自然言語要約があれば、AIは瞬時かつ正確に「このメソッドが何をしているか」を把握できます。
（2）ユビキタス言語がAgentic Searchの最強タグになる
Claude等のエージェントは、コード全体を逐次読むのではなく、Grepや正規表現による検索（Agentic Search）でアタリをつけてから必要なコードを読み込みます。コメント内にプロジェクト固有のユビキタス言語を徹底して書いておくことで、AIはプロンプトで指示された業務用語とコメント内の用語を正確にマッチングできるようになり、広大なコードベースから修正箇所を一発で特定できます。
4.4 実装計画書はバージョン管理しない
ついでに議論になったのが「AIが生成した実装計画書」の扱いです。これを永続ドキュメントとして管理すると、ソースコード修正のたびに実装計画書も更新する二重管理コストが発生します。
結論は以下の通り。
- 実装計画書はバージョン管理しない
- PRのメッセージやチケットのコメントに記載する
- 将来の調査時はコミット履歴から該当PR・チケットに遡る
「永続化すべきドキュメント」と「一過性の意図の記録」を区別することが、二重管理地獄を回避する鍵になります。
5. コンテキストは「足し算」ではなく「引き算」で設計する
5.1 ありがちな失敗 ― 完璧な仕様書を用意しようとする
AI駆動開発を始めた人がよく陥る罠があります。
AIに完璧な仕事をさせるには、完璧なルールと仕様書を事前に用意しなければならない
これは正しいように見えて、最大の落とし穴です。完璧なコンテキストを用意する作業自体が、新たなボトルネックになってしまいます。
5.2 アウトプットドリブンという方針
私たちが採用した方針は以下です。
まず必要最小限のコンテキストでAIに実行させ、出力に満足できない場合に限って、不足情報を「ルール」や「Masterドキュメント」として補強する。
この「引き算」のアプローチにより、コンテキストエンジニアリングの工数を最小限に抑えられます。そして、補強されたルールは実際の失敗に基づいているため、必ず実利に結びついています。
5.3 コンテキストの最小化原則
実践的には以下のような最小化ルールが有効です。
- チャット履歴を長くしすぎない ― 精度が劣化する
- ファイルが肥大化していたら分割してから渡す
- 一つのタスクに絞って指示を出す ― トークン制限を考慮してタスクを細分化
- 「不要な情報を渡さない」ことは「必要な情報を渡す」のと同じくらい重要
5.4 型から入るか、ゼロベースで攻めるか
実践の現場では、二つのアプローチが共存していました。
| アプローチ | 特徴 | 向いている場面 |
|---|---|---|
| 型ベース（SDD/OSSスキル活用） | 既存の型を導入し、フローの再現性を重視 | チームの習熟度にばらつきがあり、標準化が必要な場面 |
| ゼロベース | 個別のコードや設計書から都度コンテキストを構築 | 熟練者が複雑なコードに対応する場面 |
どちらが正解ということはなく、プロジェクトの習熟度と対象の複雑性で使い分ける のが現実的です。両者は対立するものではなく、「アウトプットを最大化する」という同じゴールに向かう別ルートです。
6. AI出力の品質保証 ― 自然言語では担保できない領域の扱い方
6.1 自然言語による制約の限界
「こういう書き方はしないでください」とルールに書いても、LLMが100%守るとは限りません。確率的に生成するモデルの宿命です。
これに対し、自然言語ではない機械的な仕組みで担保する発想が、前述のハーネスエンジニアリングです。
6.2 具体的な実践 ― Skillとしてのチェック機構
例えばセルフレビューのチェックリスト（未プッシュ差分の有無、DBエラーログの確認など20〜30項目）をAIに任せようとすると、以下のような課題にぶつかります。
- チェック項目の抜け漏れ（30項目あるはずが10項目で終わる）
- 「NGの根拠は示せるが、OKだった項目の網羅性の証明が難しい」
- トークン制限により一度に実行しきれない
これをAIの静的解析だけで解決しようとすると失敗します。そこで以下のように切り分けます。
| 手段 | 担保できるもの |
|---|---|
| CLIコマンド（grep等） | 確実に証明可能な事実 |
| Pythonスクリプト | 複雑なロジックが絡むチェック |
| AIによる判断 | 文脈に依存する総合判断 |
そして、それぞれをCursorの Skill として分割・登録し、順次実行させます。AIはあくまで「判断」部分に専念させ、「検証」は機械的仕組みに委ねるのです。
6.3 結局のところ、これは「テストファースト」と同じ思想
よく考えると、この発想は目新しいものではありません。
「人間が自然言語で書いた要求を、機械的に検証できる形に落とし込む」
これはTDD（テスト駆動開発）や契約プログラミングと同じ思想です。対象がAI出力に変わっただけで、品質担保の本質は変わっていません。ハーネスエンジニアリングは、この古典的な思想をAI時代に適用した結果として自然発生したものだと言えます。
7. レビューの再発明という避けて通れない課題
7.1 実装スピードが上がった結果、何が起きたか
AI駆動開発で実装スピードが跳ね上がると、即座にレビューがボトルネック化します。実装が速くなった分、シニアエンジニアへのレビュー依頼が殺到するのです。
これはAI駆動開発に取り組む全ての組織が直面する課題と言えるでしょう。
7.2 現場で検討された三つのアプローチ
（1）レビュー役割の再定義
「実装計画書通りに実装されているか」はセルフレビューの責務とし、レビュアーは「計画書の妥当性」のみを確認する。レビューの粒度をメタ化することで、レビュアーの負荷を下げます。
（2）あえてコード生成を遅らせる
複雑な仕様を扱うチームでは、当面AI活用を「設計・調査フェーズ」に限定し、コード生成は従来ペースに保つ判断をしました。コード生成だけが加速するとレビューが回らず、現場が崩壊する という合理的な判断です。
これは非常に重要な示唆を含んでいます。「AIで何でも加速させればよい」わけではなく、組織全体のスループットで考えて最適な場所にAIを投入する べきだということです。
（3）レビューの暗黙知をSkill化する
GitLab CLIなどを使って過去のMR/PRデータやレビューコメントをAIに分析させ、シニアエンジニアの指摘傾向や観点を形式知化するアプローチ。これが成功すれば、「レビュー観点Skill」として組織の資産になります。
7.3 V字モデル全体のバランス設計
結局のところ、AI駆動開発はV字モデルの一工程だけを加速させるのではなく、 全工程のバランスを取り直す という視点が必要になります。実装だけ速くしても、設計やレビューが追いつかなければ意味がありません。
8. 手法より重要な「アジャイルな姿勢」
8.1 マニュアルを渡しても浸透しない理由
組織にAI駆動開発を浸透させようとすると、必ずこの壁にぶつかります。
マニュアル通りにやったのに、期待するアウトプットが出ない
この時点で思考停止してしまい、「AIは使えない」というネガティブな印象を持って離脱するケースが多発します。
8.2 なぜマニュアルだけでは不十分なのか
理由は単純です。AIの進化が速すぎるから です。
- モデルは数ヶ月で大幅に更新される
- ツールの新機能が継続的に追加される
- 今日最適なやり方が来月も最適とは限らない
- 「詳細な実装計画書を書く」という現在のベストプラクティスですら、モデル進化で不要になる可能性がある
8.3 求められる資質は「継続的改善」の姿勢
AI駆動開発において人間に求められる最も重要な資質は、以下のものです。
「特定のやり方に固執せず、状況に応じて開発プロセス自体を疑い、継続的に改善していくアジャイルな姿勢」
AIから望む結果が得られなかった時、すぐに諦めるのではなく以下を問い続けることが、AI時代の開発者に求められる「業務設計力」です。
- なぜ（Why）失敗したのか？
- どのようなコンテキスト（What）が不足していたのか？
- プロセスのどこに問題があったのか？
8.4 二段階の浸透アプローチ
組織レベルでは、以下のような二段階浸透が有効でした。
- 第1段階（型の提供） ― まずはマニュアル通りに実践してもらう
- 第2段階（型破り） ― サイクルを回す中で生じた「うまくいかない部分」をチームで振り返り、独自の最適ワークフローを見出す
いきなり自律的改善を求めるのではなく、型を通じて感覚を掴ませた上で、型破りへと誘導するのです。
9. 結論 ― 全ての手法は一点に収束する
9.1 流行の手法を並べて見えてくるもの
冒頭に挙げた手法をもう一度並べてみます。
- プロンプトエンジニアリング
- コンテキストエンジニアリング
- 仕様駆動開発（SDD）
- エージェンティックワークフロー
- ハーネスエンジニアリング
- Vibe Coding
これらを実践してみて気づくのは、表現の違いはあっても、最終的に目指している状態は同じ だということです。
9.2 収束する本質 ― 三つの原理
どの手法を経由しても、最終的には以下の三つの原理に辿り着きます。
原理1：AIを主体とした開発プロセスの再設計
AIは補助ツールではなく開発の主体である。開発者の役割は「コードを書く」から「AIへの指示書を設計し、出力を検証する」へと変わる。設計はAIと親和性の高いMarkdownへ移行し、ソースコード自体をDocCommentによってSSOTへ昇華させる。
原理2：アウトプットドリブンによる必要最小限のコンテキスト管理
完璧な事前準備を目指さず、最小限のコンテキストで実行し、失敗に応じて補強する「引き算」のアプローチを基本とする。永続化すべきものと一過性のものを区別し、二重管理を排除する。
原理3：プロセス自体を継続的に改善するアジャイルな姿勢
特定の手法に固執せず、AI・ツールの進化に合わせてプロセス自体を疑い続ける。失敗を「AIが悪い」ではなく「自分たちの設計が悪い」と捉え、コンテキストエンジニアリングを通じて継続的に改善する。
9.3 手法選びで迷っている方へ
もしあなたが「どの手法から始めればよいか」で迷っているなら、答えはシンプルです。
どれから始めても構わない。
大事なのは、選んだ手法を深く実践し、上記の三原理に辿り着くことです。SDDから入ろうが、コンテキストエンジニアリングから入ろうが、ハーネスエンジニアリングから入ろうが、本気で取り組めば必ず同じ結論に行き着きます。
手法は入り口でしかありません。入り口は違っても、辿り着く場所は同じです。
9.4 最後に ― 「何を使うか」より「どう向き合うか」
AI駆動開発の本質は、ツールや手法の選択ではなく、開発という行為そのものに対する向き合い方の変革 にあります。
- AIを信頼し、主体として扱う勇気
- 自分たちの業務を言語化し、プロセスとして設計する知的誠実さ
- 失敗をAIのせいにせず、自分たちの改善余地として捉える姿勢
これらを備えた組織や個人は、どのツールを使っても、どの手法を選んでも、確実に成果を出せます。逆にこれらが欠けていれば、最新のツールを導入しても宝の持ち腐れです。
手法は分岐するが、本質は一点に収束する。
この視点を持ちながら、自分たちのチームに合った入り口を選び、深く実践していただければと思います。
おわりに
本記事は、6週間にわたる週次ディスカッションの内容をもとに、トピック軸で再構成したものです。現場の具体的な事例やツール名にはあえて深入りせず、普遍的に適用できる考え方にフォーカスしました。
皆さんのチームでも、きっと同じような議論が行われているのではないでしょうか。もし本記事の結論に共感いただけたなら、ぜひコメントで実践されている工夫や、異なる結論に至った経緯などを共有いただけると嬉しいです。
AI駆動開発は、まだ始まったばかりの分野です。本質を見失わずに、共に試行錯誤を続けていきましょう。