AI駆動開発 2026年9月3日

プロンプトの次は「ハーネス」だ——AI開発の成熟度を自動運転レベルで測る新フレームワーク

2026年7月30日から2日間にわたって開催された「AI駆動開発カンファレンス」。ベンダー、プラットフォーマー、SIer、さまざまな立場のキーパーソンが登壇したこのイベントで、AIそのものと並んで繰り返し語られた言葉がある。「ハーネス」、そして「ハーネスエンジニアリング」だ。

「LLMを導入したのに生産性が上がらない」「レビューに追われる」——こうした現場の悲鳴に対して、業界のトップランナーたちが口をそろえて指し示すのがこの概念だ。プロンプトを磨いても、コンテキストを整えても、越えられない壁がある。その壁を越えるための設計論が、ハーネスエンジニアリングだ。

3段階の変遷を整理する

AIを使った開発の歴史は、たかだか5年ほどだ。GitHubのCOOカイル・デイグル氏は「2年足らずでassistive（支援的）からautonomous（自律的）へ移行した」と語る。その密度の濃さは、3段階の変遷として整理できる。

第1段階：プロンプトエンジニアリング（主に2022年〜）

言葉でAIに指示を出せるインパクトは確かに大きかった。しかし、同じ依頼でも表現次第で出力が変わるため、手順を分けたり手本を見せたりといった工夫が体系化されていった。問題は、対話がその場限りであることだ。プロジェクトの文脈やコーディング規約はAIに蓄積されず、毎回説明し直す必要があった。

第2段階：コンテキストエンジニアリング（2024〜2025年）

AIが扱えるコンテキスト量が増えたことで、RAG（検索拡張生成）、マルチターン対話、圧縮技術（コンパクション）が一般化した。「うまく伝える」から「必要な情報を整えて渡す仕組みを作る」へとシフトし、プロジェクトの規約や設計方針をドキュメントとして常設して毎回読ませる運用が定着した。

ただし、AIエージェントを自律的に長時間・並列稼働させようとすると、コンテキストの提供だけでは制御しきれないという新たな限界が露呈することになった。

第3段階：ハーネスエンジニアリング（2026年〜）

そうして確立されてきたのが、モデルを取り囲む実行環境そのものを設計する「ハーネスエンジニアリング」だ。ハーネスとは馬具のこと——馬に乗り手の意図を伝えるための装具一式を指す。仕様や規約でAIに進路を示し、実行環境や品質検証のパイプラインを整える役割を担う。

「プロンプトからハーネスへの変遷は、過去の技術の置き換えではない。人間が設計する対象が、『点』から『面』へと広がってきた3つの段階を示すものだ」——記事中のこの整理は、本質をついている。

自動運転になぞらえた「成熟度5段階」

では、自分たちの組織はいまどの段階にいるのか。この問いに答えるフレームワークが、Cursorを生み出したAnysphereのニック・ミラー氏が引き合いに出したダン・シャピロ氏のモデルだ。2026年1月に発信された「The Five Levels: from Spicy Autocomplete to the Dark Factory」というブログ記事がもとになっており、NHTSAの自動運転レベルになぞらえた5段階で成熟度を表現している。

レベル0：自動運転機能がない世代のクルマ
AIは少し賢い検索エンジン程度。コードを書くのは100%人間だ。

レベル1：レーンキープとクルーズコントロール
AIはインターンのような存在。ユニットテストや関数の説明文など、切り出せる局所的な仕事だけを任せる。仕事の生産性は人間のタイピング速度が上限となり、開発プロセスは本質的には大きく変わらない。

レベル2：高速道路のオートパイロット
AIは頼もしい後輩のような存在となり、生産性は飛躍的に向上する。シャピロ氏は多くの開発者が現在このレベルにいると分析する。そして「危ういのは、AIを使う開発がここで『もう完成した』と感じさせてしまう点だ」と指摘している。

レベル3：人間はセーフティードライバー
人間がしていた開発者の役割はAIに取って代わられ、承認・監督・介入で関与する（Human in the loop）。AIエージェントが並列で稼働するため、人間はレビューに明け暮れる。シャピロ氏が「Life is diff（人生は差分確認だ）」と表現したとおりだ。

レベル4：ロボタクシー
AIエージェントがシニア開発者のように自律的に仕事を進め、人間はPM（プロダクトマネジャー）となる。仕様を書き、議論し、計画をレビューする。開発現場から離席し、戻ったらテスト結果を確認するだけという状態だ。

レベル5：ダークファクトリー
自動運転を越えた将来像。ファナックの無人工場のように人間の照明すら不要な状態で、仕様をソフトウェアに変えるブラックボックスに近い。実践者はまだ少数で、シャピロ氏自身も「信じ難い」と言いつつ「おそらくそれがわれわれの未来」と結んでいる。

この3段階遷移が示す構造的な意味

ここからは、この記事をどう読むかという話だ。

最も重要だと思うのは、「設計対象の拡大」という構造だ。プロンプトエンジニアリングは「何を言うか」という点の設計だった。コンテキストエンジニアリングは「何を渡すか」という線の設計に広がった。ハーネスエンジニアリングは「AIが動く環境そのもの」という面の設計だ。この拡大は不可逆だ。戻ることはない。

もうひとつ、「個人スキル依存」から「仕組みの資産化」へのシフトという観点も外せない。プロンプトを上手く書ける人がいればいい、というフェーズは終わりつつある。ハーネスを整備すれば、同じ品質を何度でも再現できる。スキルではなく、仕組みが競争優位になる。

ただし、正直に留保も入れておく。「ハーネスエンジニアリング」という言葉自体は2026年の業界用語であり、まだ定義が揺れている。カンファレンスで異口同音に語られているということは、実践が定着したというより「この概念が大事だ」という共通認識ができた段階、と読むのが適切だろう。「すでにハーネスで生産性10倍を達成した」という話ではなく、「ハーネスなしではスケールに限界がある」という認識が広がってきた、という段階だ。

実務的な示唆：あなたのチームはどこにいるか

シャピロ氏のフレームワークで自分のチームを当てはめてみると、おそらく多くのチームはレベル2のどこかにいる。GitHub CopilotやClaude Codeを導入して「以前より速くなった」という実感はあるが、それ以上の伸びを感じていない——というパターンだ。

この「レベル2の満足」は、実は危険な停滞だとシャピロ氏は指摘している。AIエージェントを並列で動かし始めたとき、ハーネスなしでは人間がレビューのボトルネックになる。「Life is diff」——開発の喜びがプルリクの差分確認に変わるという状態だ。実装の自動化を進めるほど、環境整備（ハーネス）への投資なしには人間が詰まる、という逆説が起きる。

実務で次に考えるべき問いは、だいたいこのあたりだ。