ハーネスエンジニアリング入門：AIコーディングエージェントを「確実に動かす」設計思想

AIコーディングエージェントを日常的に使っていると、あるジレンマに気づく。Claude CodeやCursorを動かすと、単純なタスクは驚くほどうまくいく。だが、複雑なマルチステップのタスクや長時間にわたる作業になると、エージェントは途中で方向を見失ったり、同じミスを繰り返したりする。

「もっと良いモデルを使えば解決するのか？」——多くの人がそう考える。だが、2026年初頭に広まりつつある洞察は、そうではないということだ。 問題はエージェント自体ではなく、エージェントが動く「環境」にある。

この環境を設計・構築する技術が、「 ハーネスエンジニアリング（Harness Engineering） 」だ。プロンプトエンジニアリング、コンテキストエンジニアリングに続く第3の進化として、AI研究者とソフトウェアエンジニアの双方から注目を集めている。

プロンプト→コンテキスト→ハーネス：AIとの協業の進化

AIとの協業の方法論は、この数年で段階的に進化してきた。それぞれの世代は前の世代の限界を乗り越える形で登場している。

プロンプトエンジニアリング（第1世代）

プロンプトエンジニアリングは「 何を言うか 」を最適化する技術だ。GPT-3やChatGPTの登場とともに一般化し、2022〜2023年に全盛期を迎えた。

「あなたはシニアエンジニアです。以下のコードをリファクタリングしてください」といった指示の書き方を工夫することで、モデルの出力を制御しようとするアプローチだ。単発タスクや簡単なQ&Aには強力だが、長期的なタスクや複雑なワークフローへの対応には限界がある¹。

コンテキストエンジニアリング（第2世代）

2025年中頃、LangChainのHarrison Chaseらが「コンテキストエンジニアリング」という概念を広めた。これは「 何を知るべきか 」を最適化する技術で、モデルが「見る」情報環境全体を設計することに焦点を当てる²。

プロンプトエンジニアリングはコンテキストエンジニアリングのサブセットだ。「プロンプトエンジニアリングが最初の良い出力を得るための技術なら、コンテキストエンジニアリングは1000番目の出力でも良い品質を維持するための技術」³と言われる。ツール定義、RAG、メモリ管理などがその構成要素になる。

しかし、コンテキストエンジニアリングにも盲点があった。エージェントが「どう実行されるか」——ツールを呼び出すタイミング、失敗した時のリトライ、複数のコンテキストウィンドウにまたがる状態管理——これらは扱われていなかった。

ハーネスエンジニアリング（第3世代）

2025年末から2026年にかけて、より広い概念として「ハーネスエンジニアリング」が台頭してきた。「 どう動かすか 」を最適化する技術で、エージェントが確実・長期・自律的に動作するための「環境」そのものを設計・構築することを指す。

ハーネスとは何か

「ハーネス（Harness）」という言葉は、馬具の「馬のたずな・締め具」から来ている。AIの文脈では、 エージェント（＝モデル）を包むソフトウェアシステム全体 のことを指す。

ハーネスはエージェント自体ではない。エージェントが信頼性高く、効率的に、制御可能な形で動作するための「器」だ⁴。具体的には以下の機能をカバーする：

• ツールディスパッチ：エージェントがどのツールを呼び出し、結果をどう処理するか
• コンテキスト管理：関連情報の注入・不要情報の削減・古い情報の圧縮
• 安全性の強制：破壊的操作の防止、サンドボックス管理
• 状態管理：複数のコンテキストウィンドウにまたがるセッション継続性
• リトライ・検証ループ：失敗した時の自律的な回復

ML Engineer のPhilipp Schmidは次のように表現している：「 競争優位の源泉はもはやプロンプトではない。ハーネスが捕捉するトラジェクトリ（成功・失敗の軌跡）こそがデータセットであり、次世代モデルのトレーニングに直結する。 」⁵

アナロジーとして：ハーネスのないエージェントは、手綱のない馬だ。どれだけ優秀な馬でも、操ることができなければ目的地には着かない。

OpenAIの実験：0行の手書きコードで100万行のプロダクト

ハーネスエンジニアリングが単なる理論ではないことを示す、最も説得力ある実例がある。2026年2月11日、OpenAIのエンジニアRyan Lopopoが公式ブログで公開した実験だ⁶。

実験の概要

OpenAIのチームは2025年8月から約5ヶ月間、ある「実験」を行った：

「私たちのチームは、手動で書かれたコードが0行のソフトウェアプロダクトを構築・出荷するという実験を行ってきた」

プロダクトは内部の日常ユーザーと外部アルファテスターが存在し、デプロイ・破損・修正というサイクルを実際に回している。すべてのコード——アプリケーションロジック、テスト、CI設定、ドキュメント、オブザーバビリティ、社内ツール——がCodexによって書かれた。その規模は約100万行。そして推定所要時間は「手書きの1/10」。

チームの哲学はシンプルだった：「 Humans steer. Agents execute.（人間が方向を決め、エージェントが実行する。） 」

コアコンセプト：4つの「可読性」設計

OpenAIのチームが発見したのは、エージェントを大規模に機能させるために、4種類の「可読性（Legibility）」を設計する必要があるということだった。ここでの「可読性」とは、人間が読みやすいという意味ではなく、「エージェントがシステムの状態を定量的に把握できる度合い」を指している。

1. Agent Legibility（エージェント可読性）

リポジトリをCodexが読めるように最適化する。人間の新入り社員ではなく、エージェントのために読みやすく設計するという発想の転換だ。

「エージェントが実行中にコンテキストでアクセスできないものは、存在しないも同然だ。Google Docs、チャットスレッド、人々の頭の中にある知識はシステムにアクセスできない。リポジトリに存在するバージョン管理されたアーティファクト（コード、マークダウン、スキーマ、実行可能なプラン）のみが、エージェントが見られるものだ。」

2. Repository-Resident Knowledge（リポジトリ常駐ナレッジ）

ドキュメントとアーキテクチャ知識をリポジトリに集約する。 AGENTS.md、ARCHITECTURE.md、設計ドキュメント、製品仕様がすべてgitで管理される。そして重要なのは、それらが最新状態を保つよう、専用のリンターとCIが整合性を強制していることだ。

docs/
├── design-docs/
│   ├── index.md
│   └── core-beliefs.md
├── exec-plans/
│   ├── active/
│   └── completed/
├── product-specs/
│   └── index.md
└── DESIGN.md, FRONTEND.md, SECURITY.md ...

3. Application Legibility（アプリ可読性）

実装スループットが上がると、次のボトルネックはヒューマンQAになった。エージェントがアプリケーション自体を「見られない」からだ。

解決策：アプリをエージェントに直接見せる。Chrome DevTools MCPをCodexに接続してUIを確認させ、ワークツリーごとにアプリをブート可能にして並列実行できるようにした。

4. Architecture Enforcement（アーキテクチャ強制）

「ゴールデンプリンシプル」と呼ぶ機械的なルールをリポジトリに埋め込み、リンターとCIで強制する。バックグラウンドのCodexタスクが定期的にコードベースをスキャンし、逸脱を検出してリファクタリングのプルリクエストを自動で開く。これが「AIスラップ（AI slop）」——コードが徐々に品質低下していく問題——を防ぐ仕組みだ。

エンジニアの役割はどう変わるのか

ハーネスエンジニアリングは単なる技術の話ではなく、エンジニアリングという職業の本質を問い直す。

2026年の時点で、開発組織の97%がAIをソフトウェア開発ライフサイクルに活用している⁷。「エンジニアがコードを書く」から「エンジニアがエージェントを操る」への移行は、もはや仮説ではなく現実だ。

この移行に伴い、 稀少リソースが変わる。 かつては計算量が制約だった。今は「人間の時間と注意」が制約だ。この転換は、あらゆるエンジニアリングのトレードオフを変える。「待つことが高くつき、修正は安い」——以前とは逆の世界だ。

ハーネスエンジニアを名乗るには、新しいスキルセットが必要になる：

• 環境設計：エージェントが動く文脈を整える能力
• 意図の仕様化：何を達成すべきかを曖昧さなく記述する能力
• フィードバックループ設計：エージェントが自己修正できる仕組みを作る能力
• 「テイスト」のコード化：アーキテクチャ上の美意識を機械的なルールとして表現する能力

gtcode.comはこれを次のように表現している：「エージェントはエンジニアリング判断力の代替ではなく、マシンスピードで動く判断力の乗数だ。判断力はどこかから来なければならない。ハーネスエンジニアリングとは、それがどこから来るかを決定し、正確にコード化し、リポジトリ以外には見えないシステムにとって可読にする実践だ。」⁸

実践する上での注意点

ハーネスエンジニアリングは万能薬ではない。始める前に知っておくべき落とし穴がある。

まず、 リポジトリレベルのコンテキストファイルの効果は一様ではない。 研究によると、AI生成の CLAUDE.md や AGENTS.md はエージェントの成功率を下げる可能性がある。人間が書いたものでも改善幅はわずかで、コストは増加する傾向がある。

次に、 モデルが改善されるたびに設計の見直しが必要になる。 philschmid.deが言う「Build to Delete（削除するために作れ）」——アーキテクチャをモジュラーに保ち、新しいモデルが旧来のロジックを置き換えるための準備をする——という考え方が重要だ⁵。

最後に、 小規模・単純なタスクには過剰設計になりうる。 「シンプルに始めろ。巨大なコントロールフローを作るな。ロバストなアトミックツールを提供し、モデルにプランを立てさせろ」という原則は、ハーネスエンジニアリングを始める上での現実的なガイドラインだ。

まとめ

ハーネスエンジニアリングを3行でまとめると：

1. エージェントではなく環境を設計する：どれだけ優秀なモデルも、動く環境が適切でなければ力を発揮できない
2. 知識をリポジトリに宿らせる：エージェントが見られるものだけが存在する。口頭・Docs・Slack上の知識は、エージェントにとって存在しない
3. 人間の役割は判断とアーキテクチャ：コードを書くことではなく、エージェントが信頼できる判断基準を埋め込むことが仕事になる

エンジニアリングの本質は変わらない——「どこに判断力を宿らせるか」を決めることだ。その「どこ」が、かつてはコード自体だったものが、今はハーネスという環境になりつつある。

「馬は速い。ハーネスがすべてだ。」

参考文献