「ChatGPTとClaudeとGemini、どれを使えばいいですか？」AIエージェントの導入を検討している現場では、この質問が繰り返されます。ベンチマークスコアを比較し、最高点のモデルを選ぶ。それが正解だと多くの人が信じてきました。
しかし2025〜2026年にかけて、この前提を根本から覆す知見が相次いで登場しています。Morpho社の調査によると、SWE-benchにおいてハーネス設計の違いでスコアが最大22ポイント変動する一方、モデルの入れ替えではわずか1ポイントしか変わりませんでした。
つまり「どのモデルを使うか」より「どんな環境でエージェントを走らせるか」の方が、成果に対する影響がはるかに大きいということです。この「環境」の設計こそが、ハーネスエンジニアリングです。
※本記事は2026年3月時点の情報を基に執筆しています。ハーネスエンジニアリングは生まれたばかりの概念であり、定義や実践手法は今後さらに進化することが予想されます。
[目次を開く]
ハーネスエンジニアリングとは何か
ハーネスエンジニアリングの定義は論者によって異なりますが、いずれも「モデルの外側」に焦点を当てている点で共通しています。
Google DeepMindのStaff EngineerであるPhilipp Schmid氏は、エージェントハーネスを「AIモデルを包み込み、長時間実行されるタスクを管理するためのインフラストラクチャ」と定義しています。つまり、ハーネスはエージェントそのものではなく、エージェントが安定動作するための「土台」を指します。
LangChainはよりシンプルに定義しています。
「モデルでないものはすべてハーネス」
エージェント ＝ モデル ＋ ハーネス
PCに例えると、さらにわかりやすくなります。
| PCの構成要素 | AIエージェントの対応 |
|---|---|
| CPU | LLM（推論エンジン） |
| OS | ハーネス |
| アプリケーション | エージェントが実行するタスク |
CPUがどれほど高性能でも、OSがなければアプリは動きません。同様に、LLMがどれほど優秀でも、ハーネスがなければ長時間タスクは安定しないのです。
この概念はいつ生まれたのか
実は「ハーネスエンジニアリング」という言葉が業界全体に広まったのは、2026年2月のたった数週間のことです。
2026年2月5日、HashiCorpの共同創業者でTerraformの作者でもあるMitchell Hashimotoがブログ記事を公開し、この実践に明確な名前を与えました。その数日後、OpenAIが「Harness engineering: leveraging Codex in an agent-first world」を発表。さらにEthan Mollickがモデル・アプリ・ハーネスという3つの概念でAIガイドを再構成したことで、この用語はAIエンジニアリングの核心的な語彙として一気に定着しました。
そして、きっかけとなった象徴的な事例がOpenAIのCodexチームの報告です。
「5ヶ月間、人間はコードを1行も書かなかった」
OpenAIのCodexチームは、2025年8月から5ヶ月間の社内実験において、手書きソースコードを一切使用せずに約100万行のコードを含むベータ製品を構築・リリースしました。わずか3〜7人のエンジニアがプルリクエストやCIのワークフローを通じてエージェントをガイドし、Codexエージェントがバグの再現、修正案の提示、結果の検証などを自律的に反復しました。
この成果の核心は「優れたモデルを使ったこと」ではなく、「AIが安定して成果を出せる環境＝ハーネスを設計したこと」にありました。
プロンプト→コンテキスト→ハーネスの進化
AIとの向き合い方は、段階的に進化しています。
| 時期 | アプローチ | 焦点 |
|---|---|---|
| 2023〜2024年 | プロンプトエンジニアリング | AIへの指示の書き方 |
| 2025年中頃〜 | コンテキストエンジニアリング | AIへ何を見せるかの設計 |
| 2026年〜 | ハーネスエンジニアリング | AIが動く環境全体の設計 |
2023〜2024年はプロンプトエンジニアリングの全盛期でした。AIにどう指示するかが重要だった時代です。
2025年中頃、Andrej Karpathy氏が「プロンプトの書き方よりも、モデルが推論時に持てるコンテキスト全体をシステムレベルで設計することが重要だ」と強調したことで、コンテキストエンジニアリングが広まりました。
しかし、AIエージェントが本格的な実務環境で動くようになると、コンテキスト設計だけでは対処できない問題が浮かび上がりました。
- エージェントがチームの慣習を無視してコードを書く
- アーキテクチャの依存ルールに違反する
- 並列実行中に互いの作業を上書きする
- コード品質がじわじわ劣化していく
これらは「何をモデルに見せるか」の問題ではなく、「システムが何を防ぎ、何を測定し、何を修正するか」の問題です。ここにハーネスエンジニアリングの必要性があります。
定義の「揺れ」を正直に見る
ハーネスエンジニアリングは急速に広まった概念であるがゆえに、定義が論者によってまだ揺れています。これは概念が生まれたばかりである証でもあります。
主な定義の違い
| 提唱者 | 定義の特徴 |
|---|---|
| OpenAI（Codexチーム） | コンテキスト管理・アーキテクチャ制約・ガベージコレクションの3要素。ソフトウェア開発特化 |
| Mitchell Hashimoto（起源） | 「エージェントがミスした時、再発防止の仕組みを作る」というシンプルなアイデア |
| LangChain | 「モデルでないものはすべてハーネス」というより広い定義 |
| Martin Fowler | 「AIエージェントを制御下に置くためのツールと実践の総体」 |
コンテキストエンジニアリングとの境界線問題
特に議論になっているのが「コンテキストエンジニアリングとの違い」です。
| 観点 | コンテキストエンジニアリング | ハーネスエンジニアリング |
|---|---|---|
| 問い | 何をモデルに見せるか？ | システムが何を防ぎ、測定し、修正するか？ |
| 手段 | RAG、MCP、プロンプト設計 | リンター、CI、ガードレール、フィードバックループ |
| 例 | AGENTS.md の内容設計 | AGENTS.md への違反を検知するCI |
「コンテキストは情報を与える。ハーネスはシステムが脱線しない場所を作る。」
ただし実際には、この2つの概念は重なり合う部分が多く、「どちらのフレームを使っても設計判断に大きな差は生じない」という実務的な見方もあります。重要なのは「コンテキスト設計だけでは対処できない領域がある」という認識自体です。
ハーネスの3つの主要要素
OpenAIのCodexチームが定義したハーネスエンジニアリングの3本柱を見ていきましょう。
1. コンテキスト管理
エージェントに渡す情報を厳選し、必要なものだけを適切なタイミングで渡す設計です。OpenAIはこの点について重要な教訓を共有しています。
「コンテキストは希少資源だ。巨大な指示ファイルはタスクやコード、関連ドキュメントを圧迫する。情報が多すぎると、すべてが『重要』になり、何も重要でなくなる。」
そのため、AGENTS.md は「百科事典」ではなく「目次」として扱い、詳細は構造化されたdocs/ディレクトリに分散させることが推奨されています。
関連記事：
📄
CLAUDE.md の書き方完全ガイド：Claude Code にプロジェクトコンテキストを正しく伝える
2. アーキテクチャ制約とガードレール
AIコーディングエージェントを「自由に走らせる」のではなく、守るべき制約を明示し、逸脱したら検知・修正・停止できるようにする考え方です。
OpenAIの実装では、依存関係をTypes→Config→Repo→Service→Runtime→UIという順序で管理し、エージェントがこのレイヤーの外で操作できないよう構造テストとCIで機械的に強制しています。
逆説的ですが、解決空間を制約するとエージェントはより生産的になります。何でも生成できる状態では、行き止まりを探索してトークンを無駄にします。
関連記事：
📄Claude Code Hooks 完全ガイド：PreToolUse から PostToolUse まで徹底解説
3. ガベージコレクション（フィードバックループ）
エージェントが定期的にドキュメントの不整合やアーキテクチャ制約の違反を検出し、自己修正するループです。
AIエージェントはコードを大量生成するため、時間とともにドリフト（仕様からのずれ）が蓄積します。これを「エントロピー」と呼び、ガベージコレクションはそのエントロピーと戦う仕組みです。
エンジニアの仕事はどう変わるか
エージェントファーストなワークフローで最も大きな変化は、技術的なものではなく認識論的なものです。
エンジニアの仕事は「正しいコードを書くこと」から「エージェントが確実に正しいコードを書ける環境を作ること」にシフトします。これらは根本的に異なる問題です。
従来のソフトウェア開発： 何かが壊れた → デバッグする → コードを直す
ハーネスエンジニアリング： 何かが壊れた →「何の機能が欠けているか？」を問う → ツール・ガイドライン・ドキュメントを整備する → エージェントが自律的に修正できる環境を作る
2026年、エンジニアのスキルセットとして求められるのは「コードを書く力」だけでなく、「AIが正しく動ける環境を設計する力」が加わることになります。
代表的なハーネスツール・フレームワーク
| ツール | 特徴 |
|---|---|
| Claude Code（Anthropic） | コーディング特化の先駆的ハーネス。CLAUDE.md と SKILL.md で環境を設計 |
| Codex Harness（OpenAI） | OpenAIが実証した開発ハーネス。オープンソース |
| LangGraph（LangChain） | マルチエージェントパターン（plan-and-execute、ルーティング）に対応 |
| AutoGen（Microsoft） | イベント駆動型のエージェント間協調フレームワーク |
| OpenClaw | ハーネスを内包した自律型AIエージェントプラットフォーム（ハーネスより上位レイヤー） |
OpenClawについての補足： OpenClawは「ハーネスツール」というより、ハーネスの概念を内包した自律型AIパーソナルアシスタントです。Claude CodeやCodex CLIより一段上のレイヤーにあたり、常時起動・チャット連携・スキル管理といったハーネス機能をまるごと提供します。
関連記事：
📄Devin vs Claude Code vs Codex CLI 徹底比較【2026年最新】AI駆動開発ツールを徹底解説
📄Claude CodeのSKILL.mdの書き方と活用方法を徹底解説【2026年版】
ハーネスのセキュリティリスクにも注意
ハーネスはAIエージェントに強い権限を与える設計です。そのため、セキュリティリスクも相応に高まります。
OpenClawのような強い権限を持つエージェントでは、以下の「致命的な三重奏」と呼ばれるリスクが存在します。
- プライベートデータへのアクセス（メール・ファイル等）
- 信頼できないコンテンツへの露出（外部からのメール・Webページ等）
- 外部との通信能力（メール送信・API呼び出し等）
また、エージェントが外部コンテンツを処理する際のプロンプトインジェクション攻撃にも警戒が必要です。悪意のある指示が埋め込まれたドキュメントをエージェントが読み込むことで、意図しない操作が実行されるリスクがあります。
関連記事：
📄プロンプトインジェクションとは？AIシステムを脅かす攻撃手法と対策を徹底解説
📄.envのベストプラクティスとAIエージェント時代のシークレット管理
概念の「今後」をどう見るか
モデルが進化するにつれて、今日ハーネスに存在する機能の一部はモデル自体に吸収されていくでしょう。計画立案・自己検証・長期的な一貫性がネイティブに向上し、コンテキストの注入が少なくて済むようになります。
しかし、プロンプトエンジニアリングが今日も依然として価値を持つように、ハーネスエンジニアリングも有用であり続ける可能性が高いです。 なぜなら、ハーネスは単にモデルの欠点を補うものではなく、「正しく構成された環境」「適切なツール」「永続的な状態管理」「検証ループ」は、どれほど優秀なモデルでも効率を高めるからです。
またハーネスの「旬」は数ヶ月〜1年かもしれません。しかし、決定論的ツールによる品質強制・テスト駆動の仕様定義・設計判断の記録といった原則自体は、普遍的なソフトウェアエンジニアリングのベストプラクティスです。LLMが進化しても、これらの価値は変わりません。
まとめ
ハーネスエンジニアリングを一言で言えば、「AIエージェントにとってのOS設計」です。
| ポイント | 内容 |
|---|---|
| 生まれた時期 | 2026年2月（概念自体は2025年後半から） |
| 提唱者 | Mitchell Hashimoto → OpenAI Codexチームが普及 |
| 定義の状態 | まだ揺れている（論者によって異なる） |
| コアの考え方 | モデルより環境設計が成果を左右する |
| 3要素 | コンテキスト管理・アーキテクチャ制約・フィードバックループ |
どれほど優秀なモデルも、動く環境が整っていなければ本来の力を発揮できません。逆に言えば、適切なハーネスを設計すれば、現状のモデルでも劇的に成果を上げられる可能性があります。
「AIを使う」から「AIが動く環境を設計する」へ。この視点の転換が、これからのDX推進において重要なカギになるでしょう。まずは CLAUDE.md や AGENTS.md の整備など、小さなハーネスから始めてみてはいかがでしょうか。
