---

2025年8月末、OpenAIのとあるリポジトリに最初のコミットが記録された。書いたのは人間ではない。Codex CLIとGPT-5が生成したコードだ。それから5ヶ月後、このリポジトリは約100万行のコードと1,500件のプルリクエストを抱える規模にまで成長した。プロジェクトを主導したのは当初わずか3名のエンジニアで、後に7名へ拡大した。1人あたり1日平均3.5件のPRを処理した計算になる。

彼らは優れたプロンプトを書いたのだろうか。もちろんそれもある。だが成功の本質は別の場所にあった。エージェントに「何を指示するか」ではなく、エージェントが「正しく動き続ける環境」をどう設計するか。この問いに対する体系的な回答が、2026年初頭に急速に広まった概念――ハーネスエンジニアリングである。

本稿では、この概念がなぜ今必要とされているのか、従来のプロンプトエンジニアリングやコンテキストエンジニアリングと何が違うのか、そしてAIを「使う」時代から「動かし続ける」時代への移行が何を意味するのかを、主要プレイヤーの事例と共に読み解いていく。

「プロンプトの工夫」だけでは本番環境を支えられない

ChatGPTの登場から3年。AIの活用技術は劇的に変わった。2023年から2024年にかけて、エンジニアたちが磨いてきたのは「プロンプトエンジニアリング」、つまりAIへの指示文をいかに巧みに設計するかという技術だった。Chain-of-Thoughtで推論過程を引き出し、Few-shotで出力形式を揃える。単発の質問応答や要約タスクでは、この手法は確かに有効だった。

しかし、AIが「一問一答のアシスタント」から「自律的に仕事をこなすエージェント」へと進化するにつれ、プロンプトだけに依存するアプローチの限界が3つの形で露呈した。

第一に、プロンプトの脆弱性だ。意味的にはまったく同じ指示でも、表現が少し違うだけで出力品質に大きな差が生じる。「please」の一語を加えるだけで応答スタイルが変わり、モデルのマイナーアップデートで昨日まで動いていたプロンプトが機能しなくなる。元GitHubのMLエンジニア、Hamel Husainはプロンプトのみに依存するアプローチの限界を繰り返し指摘しており、デモ以上の製品品質を実現するにはより体系的な仕組みが必要だと論じている。

第二に、デモと本番環境の深刻な乖離だ。LangChainが2025年11月から12月にかけて1,340名を対象に実施した調査によれば、本番環境でエージェントを稼働させている組織は57%に達した。一方で、最大の障壁として「品質」を挙げた回答者は32%に上る。デモでは華々しく動くエージェントが、本番の多様な入力と長時間の実行に晒されると、あちこちで躓く。

第三に、長時間タスクでの文脈喪失だ。Dex Horthyが2025年に提唱した「dumb zone」と呼ばれる現象がある。コンテキストウィンドウの使用量が一定水準（約40%）を超えると、エージェントのパフォーマンスが著しく劣化するのだ。プロンプトをどれほど洗練させても、この問題はアーキテクチャレベルでしか解決できない。

では、プロンプトの「次」に来るものは何か。

「何を見せるか」を設計する技術が台頭した

2025年、AIエンジニアリングの語彙に新しい言葉が加わった。コンテキストエンジニアリングだ。OpenAI創設メンバーのAndrej Karpathyは2025年6月、Xへの投稿でこう定義した。「コンテキストエンジニアリングとは、次のステップに向けてコンテキストウィンドウを適切な情報で満たすための繊細な技芸と科学だ」。

プロンプトエンジニアリングが「AIへの指示をどう書くか」に集中するのに対し、コンテキストエンジニアリングは視野をもっと広く取る。RAG（検索拡張生成）で外部知識を動的に注入し、MCP（Model Context Protocol）でツールやデータソースとの接続を標準化し、会話履歴の圧縮・要約でセッション全体を通じた情報品質を維持する。AIに「何を指示するか」ではなく、「何を見せるか」を体系的に設計する技術体系だ。

Gartnerはこれを「AIシステムが意図を理解し、より良い判断を下し、文脈に沿った出力を提供できるよう、関連データ・ワークフロー・環境を設計・構造化すること」と定義している。エンタープライズでの実装において、コンテキストエンジニアリングは確実に成果を上げてきた。

だが、これでもまだ足りなかった。エージェントが「正しく考える」ための情報は揃えられるようになった。しかし、エージェントが「正しい軌道を外れない」ようにするには、情報供給の外側にもう一つのレイヤーが必要だったのだ。

Hashimotoが名付けた「ハーネス」という概念

2026年2月5日。HashiCorp共同創業者でTerraformの生みの親、Mitchell Hashimotoがブログ記事「My AI Adoption Journey」を公開した。コードを1行も手書きせずにプロダクト開発を続けてきた実践の記録だ。その中で彼は、AIエージェントの活用を6つのステージに整理し、第5段階に「ハーネスエンジニアリング」という名前をつけた。

Hashimotoによる定義はシンプルだ。「エージェントがミスをするたびに、そのエージェントが同じミスを二度と犯さないよう解決策をエンジニアリングする」。この定義はHashimoto個人の実践から生まれたものだが、後にOpenAIやLangChainが概念を拡張し、ツール設計・検証ループ・環境構築を含むより広範なシステムエンジニアリングとして再定義していくことになる。

「ハーネス」とは馬具のことだ。馬がどれほど強く速く走れても、手綱も鞍も柵もなければ、その力を有用な仕事に変換することはできない。同様に、AIモデルがどれほど高性能でも、制御と検証の仕組みがなければ、実用に耐える仕事は生まれない。

2026年2月11日、OpenAIが「Harness engineering: leveraging Codex in an agent-first world」を発表。さらにThoughtWorksのBirgitta BöckelerがMartin Fowlerのサイトで同テーマの分析記事を公開し、わずか数週間でこの概念はAIエンジニアリングの中核語彙として定着した。

Hashimoto自身は、具体的な実装として2つのプラクティスを挙げている。一つは「AGENTS.md」の継続更新。エージェントが誤った動作をするたびに、その修正策をドキュメントファイルに追記していく。もう一つは、スクリーンショット取得やフィルタ付きテスト実行といった専用ツールの整備だ。いずれにも共通するのは「複利効果」という考え方だ。ハーネスへの一つの改善は、以降のすべてのエージェント実行に自動的に適用される。プロンプトを毎回書き直すのとは質的に異なる投資なのだ。

では、コンテキストエンジニアリングとハーネスエンジニアリングは、具体的に何が違うのか。

「考えを助ける」と「軌道を守る」は別の仕事だ

両者の違いを一言で表現するなら、こうなる。

コンテキストエンジニアリングは「モデルがうまく思考できるよう支援する」技術だ。いわば”Think Well”。一方、ハーネスエンジニアリングは「システム全体が目標から逸脱しないよう防ぐ」技術だ。いわば”Stay on Course”。

馬のメタファーに戻れば、コンテキストは馬に見せる地図や道標。ハーネスは手綱・鞍・柵・道路そのもの。10頭の馬が同時に安全に走れる環境を設計することが、ハーネスエンジニアリングの仕事だ。

重要なのは、三者の関係が「入れ子構造」であるという点だ。プロンプトエンジニアリングはコンテキストウィンドウの中で行うこと。コンテキストエンジニアリングはウィンドウに何を詰めるかを決めること。ハーネスエンジニアリングはウィンドウの外側にあるすべてのシステム設計だ。外側の層は内側の層を包含し、その上に新たな要素を加えている。つまりハーネスの中にはコンテキストエンジニアリングが組み込まれており、コンテキストの中にはプロンプトエンジニアリングが含まれている。競合ではなく、段階的な拡張だ。

BöckelerはOpenAIのCodexチームの実践を分析し、ハーネスの構成要素をコンテキストエンジニアリング・アーキテクチャ制約・ガベージコレクションの3カテゴリに整理した。このうちコンテキスト供給を超えた独自の要素は後者の2つだ。

第一に、アーキテクチャ制約。AIエージェントだけに任せず、カスタムリンターや構造テストという決定論的な仕組みでコード品質と構造的基準を強制する。AIの判断に「審判」を設けるイメージだ。

第二に、ガベージコレクション。ドキュメントの矛盾やアーキテクチャ制約の違反を定期的に発見・修正するメンテナンスエージェント群だ。人間が行う「定期レビュー」を自動化した仕組みとも言える。

これらの仕組みは、情報を「渡す」のではなく、エージェントの振る舞いを「制御する」。この違いこそが、コンテキストエンジニアリングとハーネスエンジニアリングを分かつ境界線だ。

同じモデルでも、ハーネス次第で成果は劇的に変わる

ハーネスエンジニアリングの威力を端的に示すのが、「モデルはCPU、ハーネスはOS」というアナロジーだ。どれほど高性能なCPUも、OSが貧弱ではその力を活かしきれない。

OpenAIのCodexチームの事例は冒頭で触れた。当初3名のエンジニアが主導し、後に7名へ拡大したチームが、5ヶ月間にわたり手書きコード0行で100万行超のコードベースを維持した。その核心は、「ゴールデン原則」をリポジトリに直接エンコードし、クリーンアッププロセスを自動化するハーネス設計にあった。プロンプトの工夫ではなく、コードベースそのものを「エージェントが正しいパターンを複製しやすい環境」として作り上げたのだ。

LangChainの実験はさらに明快だ。同社のコーディングエージェントは、使用するモデルを一切変えることなく、ハーネス設計の改善のみによってTerminal Bench 2.0のスコアを52.8%から66.5%へと13.7ポイント向上させた。ランキングはTop 30からTop 5へ跳ね上がった。この結果は「モデル選択よりもハーネス設計が成果を決める」という主張の、最も鮮明な実証の一つだ。

Anthropicのアプローチはまた異なる角度からハーネスの価値を示した。同社が2025年に発表した長時間エージェント向けの2段構成ハーネスでは、「初期化エージェント」が初回セッションで環境を構築し、「コーディングエージェント」が各セッションで増分的な進捗を積み上げながら次セッションへの引き継ぎ情報を残す。交代シフトのエンジニアに完璧な引き継ぎ書を渡すような設計で、セッション間の記憶喪失という構造的問題を解消した。

3社のアプローチは異なるが、結論は同じだ。モデルの性能を追い求めるよりも、モデルが動く環境を設計することのほうが、実用上の成果に直結する。

ハーネスは万能薬ではない――見えてきた課題と限界

ただし、ハーネスエンジニアリングを銀の弾丸と見なすのは危険だ。概念の急速な普及の陰で、いくつかの構造的な課題が浮かび上がっている。

最も根本的な問いは、「これは既存のCI/CDやテスト自動化と何が違うのか」というものだ。カスタムリンター、構造テスト、定期的なメンテナンスジョブ――これらは従来のソフトウェアエンジニアリングで長年実践されてきた手法でもある。ハーネスエンジニアリングの新しさは、これらの手法を「AIエージェントの制御」という文脈で再構成し、AGENTS.mdのようなエージェント固有の仕組みと統合した点にある。だが、概念の境界線はまだ曖昧だ。

導入コストの問題もある。OpenAIの事例は華々しいが、そもそもGPT-5とCodex CLIという自社の最先端ツールを持つチームの成果であり、一般企業がどこまで再現できるかは未知数だ。Manusがわずか6ヶ月でハーネスを5回書き直したという事例は、ハーネス設計が一度で完成しない反復的なプロセスであることを示している。その反復に投資できるリソースがあるかどうかは、組織によって大きく異なる。

さらに、AGENTS.mdにエラーパターンを蓄積し続けるアプローチには、特定の失敗ケースへの過学習リスクが潜む。ハーネスが分厚くなるほどシステム全体の複雑性は増大し、どこかの時点で「ハーネス自体のメンテナンスコスト」が新たな問題になり得る。Vercelが過剰なツールライブラリを80%削減し、エージェントの成功率を80%から100%へ向上させたエピソードは、この問題の裏返しだ。制約を足すことだけが正解ではなく、引くべきときに引く設計判断が求められる。

現時点でのハーネスエンジニアリングの議論はソフトウェア開発の文脈にほぼ限定されており、マーケティング、法務、医療といった他領域への適用可能性は未検証のままだ。概念の汎用性が証明されるには、もう少し時間が必要だろう。

「コードを書く人」から「環境を設計する人」へ

こうした課題を踏まえてもなお、ハーネスエンジニアリングがソフトウェアエンジニアの仕事の本質を変えつつあることは否定しがたい。

従来、エンジニアの価値は「良いコードを書くこと」に集約されていた。しかしハーネスエンジニアリングの世界では、「環境を設計し、意図を明確化し、フィードバックループを構築すること」が中心的な仕事になる。「コードは資産」という時代から、「エージェントが正しく動き続ける環境が資産」という時代への転換だ。

LangChainの調査では、89%の組織がすでに何らかの可観測性（オブザーバビリティ）を導入し、62%が詳細なトレーシングを実装済みだと報告されている。エージェントの挙動を「観測可能」にすることが、ハーネス設計の出発点として定着し始めている。

2026年以降、この領域には3つの潮流が見える。汎用エージェントからテスト専門・品質保証・クリーンアップといった役割への専門分化。Anthropicが開発しOpenAI・Google・Microsoftが採用、2025年12月にLinux Foundation傘下のAgentic AI Foundationへ寄贈されたMCPの業界標準化。そして、ハーネス設計そのものの競争優位化だ。プロンプトの工夫はすぐに模倣されるが、本番で鍛えられたハーネスの蓄積は数ヶ月から数年を要する。

AIに手綱をつける者が、AIの力を引き出す

冒頭のOpenAIの話に戻ろう。3名から始まったチームが100万行のコードベースを維持できたのは、彼らが卓越したコーダーだったからではない。エージェントが犯すミスを一つひとつ拾い上げ、それを二度と起こさない仕組みへと変換し続けた。ハーネスに刻まれた改善は複利のように積み上がり、やがてエージェントは「指示されなくても正しく動く」存在に近づいていった。

「2025年はエージェントの年だった。2026年はエージェントハーネスの年だ」。この言葉は、単なるバズワードの交代ではない。AIが「動く」ことを証明した時代から、「確実に動かし続ける」仕組みを問う時代への、不可逆な移行を宣言するものだ。馬の力を引き出すのは、馬自身の脚力ではなく、手綱を握る者の設計にある。AIの時代も、おそらく同じだ。

出典・参考情報

1. Mitchell Hashimoto, “My AI Adoption Journey” (2026年2月5日) — https://mitchellh.com/writing/my-ai-adoption-journey

2. OpenAI, “Harness engineering: leveraging Codex in an agent-first world” (2026年2月11日) — https://openai.com/index/harness-engineering/

3. Birgitta Böckeler, “Harness Engineering” (2026年, martinfowler.com) — https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html

4. Anthropic, “Effective harnesses for long-running agents” (2025年) — https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

5. LangChain, “State of Agent Engineering” (2025年) — https://www.langchain.com/state-of-agent-engineering

6. LangChain, “Improving Deep Agents with harness engineering” — https://blog.langchain.com/improving-deep-agents-with-harness-engineering/

7. Aakash Gupta, “2025 Was Agents. 2026 Is Agent Harnesses.” (2026年) — https://aakashgupta.medium.com/2025-was-agents-2026-is-agent-harnesses-heres-why-that-changes-everything-073e9877655e

8. Gartner, “Context Engineering” — https://www.gartner.com/en/articles/context-engineering

9. Andrej Karpathy, “Context engineering (Xポスト)” (2025年6月) — https://x.com/karpathy/status/1937902205765607626

10. Vercel, “We removed 80% of our agent’s tools” (2025年12月) — https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools

■合わせて読みたい

■関連記事