はじめに
「ハーネスエンジニアリング」という言葉を技術記事でよく見かけるようになりました。ただ、読み比べると各記事の解釈が微妙に違います。原本となる各社の一次情報をたどってみると、確かに定義が異なっていました。そこでハーネスエンジニアリングが生まれた背景、プロンプト・コンテキストエンジニアリングとの違い、各社の定義がなぜ異なるのか、整理してみました。
この記事を読むと、以下がわかります。
- プロンプト・コンテキスト・ハーネスエンジニアリングの3概念の違いと包含関係
- 各社（OpenAI・Anthropic・Böckeler/Fowler・GitHub/Microsoft・LangChain・学術）のハーネスエンジニアリング定義の比較
- 各社の定義がなぜ異なるのか、そして何が共通しているのか
ハーネスエンジニアリングが生まれた背景
ChatGPTの登場でLLMを使う機会が一般のエンジニアにも広がると、同じモデルでも指示の書き方によって結果が大きく変わることがわかってきました。プロンプトの設計・最適化を体系化したのがプロンプトエンジニアリングです。
ところが、エージェントやRAGが実務に入り込むにつれ、「1回のメッセージ」の最適化だけでは制御しきれない問題が出てきます。会話履歴・外部知識の注入・ツール定義・トークン配分——コンテキストウィンドウ全体を動的に管理する必要が生まれました。これがコンテキストエンジニアリングです。
さらにシステムが複雑になると、コンテキストの管理だけでも足りなくなります。長時間実行・複数エージェントの連携・実環境への書き込みが絡んでくると、ツールへのアクセス制御、エラー回復、安全性の強制、状態の永続化といった、システム全体の設計が必要になってきました。これがハーネスエンジニアリングです。2026年2月、OpenAI Codexチームがこの概念を体系的に報告したことで広まり始めました。
各社の定義
ハーネスエンジニアリングという言葉を各社の一次情報で調べると、使っている言葉は同じでも定義の焦点が異なります。
| 主体 | 定義の特徴 |
|---|---|
| OpenAI | Codexチームの実践（2026年2月）から提唱。スキャフォールドとフィードバックループを組み合わせた設計で、エージェントへの指示をAGENTS.mdで機械可読にエンコードする |
| Anthropic | Claude Codeの実践から定義。プランナー/ジェネレーター/エバリュエーターの三層構造。「できる限りシンプルに」を原則とし、モデルの進化に合わせてコンポーネントを削減していく |
| Böckeler/Fowler | 理論的な整理として、ガイド/センサー × 計算的/推論的の2軸で整理。TypeScript strict modeのようなコードベースの設定も「暗黙のハーネス」と見なす |
| GitHub/Microsoft | 開発者ツールの観点から、エージェント・スキル・MCPの組み合わせで構成。ガバナンスと再利用性を重視する |
| LangChain | フレームワーク開発の文脈から6つのコア要素で構成。モデル非依存を原則とし、「Context Rot」への対策を重視する |
| 学術（NLAH） | 科学的分析の観点から、自然言語エージェントハーネスとして形式仕様化。モデル非依存のハーネス外部化を目指す |
一見バラバラに見えますが、各社が論争しているわけではありません。それぞれの実践文脈が異なるため、定義の焦点が違っています。以下で各社の定義を順に見ていきます。
OpenAI
2026年2月に発表されたCodexチームの報告がきっかけとなりました。5ヶ月間、手動コードゼロで内部プロダクトを構築した経験から、スキャフォールド・フィードバックループ・ドキュメント・アーキテクチャ制約を機械可読にエンコードする考え方を提唱しています。AGENTS.mdによる設定、サンドボックス実行、ツール定義、ファイルアクセス制御が構成要素で、複数エージェントの並列実行を前提とした設計が特徴です。
"Humans steer. Agents execute."
Anthropic
Claude Codeの実践から定義しており、プランナー/ジェネレーター/エバリュエーターの三層構造を提案しています。
"'do the simplest thing that works' will likely remain our best advice for teams building agents on top of Claude." （出典）
シンプルさを原則とし、三層から不要なコンポーネントを削っていくアプローチです。モデルの進化との関係について、次の立場を明示しています。
"every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing" （出典）
ハーネスのコンポーネントはモデルが改善すれば不要になるという前提で設計するという考え方です。また、コンテキスト上限に近づくにつれ作業を早期打ち切りしてしまう現象を「context anxiety」と呼び、完全リセット＋引き継ぎアーティファクトで対処しています。
Böckeler / Fowler
Agent = Model + Harness（モデル以外のすべてがハーネス）という定義式を起点に、2軸で整理しています。
- ガイド（フィードフォワード制御） vs センサー（フィードバック制御）
- 計算的（決定論的: テスト、リンター）vs 推論的（非決定論的: AI分析）
特徴的なのは、TypeScript strict modeやRust Borrow Checkerのようなコードベースの設定も「暗黙のハーネス」と見なす視点です。「後付けするものではなく、内在するもの」という整理は、本記事で扱う他の定義には見られない観点です。
GitHub / Microsoft
.github/agents/ファイルによるカスタムエージェントの定義、Agent Skillsによるプロセスの自動再利用、MCPによる外部ナレッジソースへの接続を組み合わせた構成です。エンタープライズ向けのガバナンスと再利用性を重視しています。
LangChain
Böckeler/Fowlerと同じくAgent = Model + Harnessという定義式を採用し、6つのコア要素（ファイルシステム、コード実行、サンドボックス、メモリ、コンテキスト管理、長期実行サポート）でハーネスを構成しています。
"A well-configured environment, the right tools, durable state, and verification loops make any model more efficient regardless of its base intelligence" （出典）
モデルの改善に関わらずハーネスの価値は持続するという立場で、Anthropicとは対照的です。実証として「ハーネス変更のみでTerminal Bench 2.0のTop 30からTop 5に改善」という結果も報告しています。コンテキストが埋まるにつれ推論能力が低下する現象を「Context Rot」と呼び、圧縮とツール出力のオフロードで対処しています。
学術（NLAH）
arXivの論文（2603.25723）では、ハーネスを「Natural-Language Agent Harnesses（NLAH）」として形式仕様化する提案がされています。従来のハーネス設計はコントローラーコードに埋め込まれており、転送・比較・科学的分析が困難でした。NLAHはハーネスの動作を自然言語で記述した編集可能なアーティファクトとして外部化し、モデルが変わっても再利用できる形にすることを目指しています。
各社の定義がなぜ違うのか
定義が異なる理由は、各社がハーネスエンジニアリングに取り組んでいる文脈が異なるからです。OpenAIはCodexというコーディングエージェントの実践から、AnthropicはClaude Codeの実践から、Böckeler/Fowlerはソフトウェアエンジニアリングの理論的な整理として、GitHub/Microsoftは開発者ツールの設計として、LangChainはフレームワーク開発の立場から、学術はモデル非依存の形式仕様化として——それぞれの起点が違うため、定義の焦点も変わります。
各社が論争しているわけではありません。自社のプロダクトや実践を通じて見えたものを言語化した結果、同じ「ハーネスエンジニアリング」という言葉に異なる定義が乗っている状態です。
ただし、ひとつ興味深い対立点があります。ハーネスはモデルの進化とともに陳腐化するのか、それともモデルに関係なく価値を持ち続けるのか。AnthropicとLangChainの立場が対照的です。
Anthropicは、ハーネスのコンポーネントはモデルの能力不足を補うものだと位置づけています。モデルが改善すれば、そのコンポーネントは不要になる。実際に、三層構造のevaluatorがモデル改善により不要になった事例を報告しています。
"Tasks that used to need the evaluator's check to be implemented coherently were now often within what the generator handled well on its own, and for tasks within that boundary, the evaluator became unnecessary overhead." （出典）
「できる限りシンプルに」という原則の背景には、モデルの進化に追従して設計を軽くしていく思想があります。
一方LangChainは、ハーネスの変更だけでスコアが劇的に変わることを実証しています。
"we improved our coding agent Top 30 to Top 5 on Terminal Bench 2.0 by only changing the harness." （出典）
さらに同一モデルでもハーネス次第で結果が大きく変わると指摘しています。
"Opus 4.6 in Claude Code scores far below Opus 4.6 in other harnesses." （出典）
この対立の背景には、各社の立場の違いがあります。Anthropicはモデルを自ら開発・改善する側であり、モデルの能力向上に応じてハーネスを簡素化する方向で設計しています。LangChainはモデル非依存のフレームワークを提供する側であり、どのモデルと組み合わせてもハーネスが効果を発揮することを実証データで示しています。
もうひとつの違いとして、同じ「コンテキストが増えるにつれ性能が落ちる」という課題に対しても、名前もアプローチも異なります。Anthropicはこの現象を「context anxiety」と呼び、コンテキストを完全にリセットして引き継ぎアーティファクトで対処します。LangChainは「Context Rot」と呼び、圧縮とツール出力のオフロードで対処します。課題認識は一致していても、解法が異なる——これも実践文脈の違いが表れている部分です。
まとめ
各社の定義は異なりますが、各社の定義に共通して現れる要素があります。
- ツールの制限 — エージェントがアクセスできるツールの定義と制御
- 安全性の確保 — 有害・不正な行動を防止するルール
- エラー回復 — 自動リトライと検証ループ
- 行動の記録・追跡 — エージェントが何をしているかの把握
- 人間による承認 — 高リスクな判断時のチェックポイント
これらに共通しているのは、すべてがモデルの外側にあり、エージェントを安全かつ信頼性をもって動作させるための仕組みだということです。各社の定義を貫く核をひとことでまとめると、ハーネスエンジニアリングとは、エージェントの行動を制御・監視し、失敗に対処し、必要に応じて人間が判断できるようにするシステム設計です。各社の定義の違いは、この核にどの実践文脈から取り組んでいるかの違いだと言えます。
このシステム設計の中には、コンテキストウィンドウをどう管理するか（コンテキストエンジニアリング）も、モデルへの指示をどう書くか（プロンプトエンジニアリング）も含まれます。3概念は包含関係にあります。
| 概念 | 制御対象 | 問い |
|---|---|---|
| プロンプトエンジニアリング | 指示文 | 「どう言うか」 |
| コンテキストエンジニアリング | コンテキストウィンドウの中身 | 「何を見せるか」 |
| ハーネスエンジニアリング | エージェントの実行環境全体 | 「どう動かすか」 |
ハーネスエンジニアリングはコンテキストエンジニアリングを含み、コンテキストエンジニアリングはプロンプトエンジニアリングを含みます。プロンプトの最適化もコンテキストの管理も、ハーネスという大きなシステム設計の一部です。新しい概念が前の概念を否定したわけではなく、制御の対象がメッセージからセッション、セッションからシステム全体へと広がったということです。
いずれにせよ、AIの進化に対して概念の整理が追いついていない状態は今後も続くと思います。厳密に線引きするよりも、大きく捉えておくのがよさそうです。