ハーネスエンジニアリングとは？AIエージェントの「モデル以外」を設計する実践

ハーネスエンジニアリングとは、AI エージェントを動かすために「モデル以外のすべて」を設計する仕事です。LangChain が 2026 年 3 月に公開した記事の言い方を借りれば Agent = Model + Harness、つまりエージェントはモデルとハーネス (harness) の合計であり、モデルでない部分はすべてハーネスだと定義されます。システムプロンプト、ツール、ファイルシステムやサンドボックス、サブエージェントの起動ロジック、フックやミドルウェアがそこに含まれます。
2026 年に一気に広まった用語で、同じモデルでもハーネス次第で成果が大きく変わることが実証されたのが背景です。以下では定義・注目された理由・設計の枠組み・着手の順番を整理します。なお自動車や電子機器の配線束を指す「ワイヤーハーネス設計」とは別の話題です。

ハーネスは「モデルでない部分」の総称

LangChain の Vivek Trivedy 氏は、ハーネスをモデル自体ではないコード・設定・実行ロジックのすべてと定義しています。素のモデルは入力を受けてテキストを返すだけで、状態の保持、コード実行、リアルタイム情報の取得、環境構築はできません。これらはすべてハーネス側の機能です。

同記事が挙げるハーネスの中身は、おおむね次の 5 つに整理できます。

• システムプロンプト
• ツール、Skills、MCP サーバーとその説明文
• 同梱されるインフラ (ファイルシステム、サンドボックス、ブラウザ)
• オーケストレーション (サブエージェント生成、ハンドオフ、モデルのルーティング)
• 決定論的に動くフック／ミドルウェア (コンパクション、継続処理、lint 実行)

言い換えると、「エージェントにこう振る舞ってほしい」という要求を、プロンプトの文章ではなく機能として実装する営みがハーネスエンジニアリングです。

なぜ 2026 年に注目されたのか

決定的だったのは、モデルを変えずにハーネスだけを変えて性能が動いた実例です。LangChain は自社のコーディングエージェントについて、ハーネスのみの変更で Terminal Bench 2.0 のランキングをトップ 30 圏外からトップ 5 に上げたと報告しています。同じ記事では、Claude Code 上の Opus 4.6 が他のハーネス上での同モデルより低いスコアになる例も挙げられています。モデルがポストトレーニングされた環境が、自分のタスクにとって最良のハーネスとは限らないということです。

実務側の事例もあります。OpenAI のチームは「手打ちのコードを書かない」という制約を課してエージェント前提の開発体制を作り、5 か月で 100 万行規模のプロダクトを構築した過程を公開しました。そこで最難関として挙げられているのは、モデル選定ではなく環境・フィードバックループ・制御系の設計です。Anthropic も長時間稼働エージェント向けのハーネス設計について技術記事を出しています。

ここから読み取れる実務上の意味は明快です。エージェントの品質が出ないとき、最初に疑うべきはモデルの賢さではなく、その周囲の環境と検証の仕組みだということです。

プロンプト／コンテキストエンジニアリングとの関係

3 つの用語は競合ではなく入れ子の関係にあります。プロンプトエンジニアリングは指示文の設計、コンテキストエンジニアリングは各ステップでモデルに何を見せるかの設計、ハーネスエンジニアリングはそれらを含む実行基盤全体の設計です。

ただし境界の見え方は立場で変わります。Thoughtworks の Birgitta Böckeler 氏は、コーディングエージェントの利用者が外側のハーネスを整えることは「コンテキストエンジニアリングの一形態」だと述べています。ハーネスという語の定義がかなり広いため、話す相手が実行基盤の話をしているのか、AGENTS.md や Skills の運用の話をしているのかを確認してから議論するのが安全です。

作る側のハーネスと、使う側のハーネス

Böckeler 氏は同心円のモデルで、中心にモデル、その外側にエージェント製品側が実装する内側のハーネス (builder harness)、さらに外側に利用者が組む外側のハーネス (user harness) を置いています。Claude Code や Codex を使う開発者は、内側のハーネスを作り直す必要はありません。整えるべきは外側です。

外側のハーネスの目的は 2 つとされています。1 つは初回で正しい成果物が出る確率を上げること、もう 1 つは人間の目に届く前にエージェント自身が自己修正できるフィードバックループを用意することです。レビューの負担が減り、無駄なトークンも減ります。

設計の骨組み：ガイドとセンサー

Böckeler 氏の枠組みは、制御を 2 方向 × 2 種類で整理します。実際に何を作るか決めるときの見取り図として使いやすい分類です。

• ガイド (フィードフォワード): エージェントが動く前に方向づけるもの。コーディング規約を書いた AGENTS.md や Skills、ブートストラップ用スクリプト、コードモッド用ツールなど
• センサー (フィードバック): 動いた後に観測して自己修正させるもの。lint、型チェック、テスト、モジュール境界を検査する構造テスト、レビュー用の Skills など
• 計算的 (computational): 決定論的で高速。ミリ秒〜秒で終わり結果が安定するため、変更ごとに回せる
• 推論的 (inferential): LLM による意味的な判定。表現力は高いが遅く高価で非決定的

重要なのは、ガイドとセンサーのどちらかしかない状態は機能しないという指摘です。センサーだけならエージェントは同じミスを繰り返し、ガイドだけならルールが効いたかどうかを誰も確認できません。

そして人間の役割は、この 2 つを回し続けること (ステアリングループ) だとされています。同じ問題が複数回起きたら、その場で直すのではなくガイドかセンサーを更新して再発確率を下げる。センサーのメッセージを LLM が読んで直せる形で書く、たとえば独自 lint の警告文に修正手順を含めるという工夫も紹介されています。

何から手をつけるか

一次情報を踏まえると、着手順序は次のように整理できます。

1. 失敗を記録する。エージェントがどこで詰まり、どんな品質問題を出したかを列挙します。ハーネスの要件はここから生まれます
2. 決定論的なセンサーを実行ループに埋め込む。「テストを実行してください」とマークダウンに書くのと、フックで毎回強制するのでは信頼性が違います。lint・型チェック・テストはまずここに入れます
3. 検証手段を与える。テストランナー、ログ、スクリーンショット、ブラウザなど、エージェントが自分の成果を観測できる道具を用意します
4. 規制対象の穴を確認する。Böckeler 氏は保守性・アーキテクチャ適合性・機能的な振る舞いの 3 分類を挙げ、既存ツールが豊富な保守性が最も harness しやすく、振る舞いの検証が最も未解決だとしています。AI が生成したテストが緑であることに信頼を置きすぎないのが現実的です
5. センサーが早い段階で走るよう配置する。速い検査はコミット前、高価な検査 (ミューテーションテスト、広い視野のレビュー) は統合後のパイプラインへ、と費用と速度で振り分けます
6. ハーネス自体の効き方を測る。後続記事では、センサーの発火履歴をログに残し、常に緑のセンサーは不要かもしれない、頻繁に落ちるセンサーはガイド側の不足を示す、という読み方が示されています

もう一点、コードベース側の「harness しやすさ」も効きます。静的型付けの言語は型チェックがそのままセンサーになり、モジュール境界が明確なら構造テストが書けます。新規開発ならこの性質を初期の技術選定に織り込めますが、技術的負債が多い既存システムでは最も必要な場所で最も作りにくい、という難しさが指摘されています。

過度な期待を避けるための前提

ハーネスを厚くすればよいわけではありません。コンテキストが埋まるほど性能が落ちる問題 (context rot) があるため、ルールファイルを足し続けると逆効果になり得ます。Böckeler 氏は Thoughtworks のポッドキャストで、明日からやることを 1 つ挙げるならマークダウンを半分に削ることだと答えています。

限界もはっきりしています。計算的センサーは重複コードや複雑度、アーキテクチャの逸脱を確実に捉えますが、問題の誤診や過剰実装、指示の読み違いは計算的にも推論的にも安定して検出できません。仕様が曖昧なら、正しさはどのセンサーの管轄にもならないという指摘は重要です。ハーネスの目的は人間のレビューをゼロにすることではなく、人間の判断を本当に必要な場所へ寄せることだと理解しておくのが妥当です。

まとめと次の一歩

ハーネスエンジニアリングは、モデルの選定から「モデルの知性を活かす環境の設計」へ関心を移す考え方です。まずは自分たちのエージェント運用で繰り返している失敗を 3 つ書き出し、それぞれに対して事前のガイドと事後のセンサーのどちらを足すかを決めてみてください。フックで強制できる決定論的な検査から入れるのが費用対効果の高い出発点です。

chot Inc. は Web サイト制作・フロントエンド開発と AI アプリケーション開発を手がけています。AI エージェントを組み込んだ機能の設計や、検証と自己修正の仕組みまで含めた実装で判断に迷う点があれば、お問い合わせからご相談ください。

出典

• LangChain: エージェントハーネスの解剖 (The Anatomy of an Agent Harness)
• martinfowler.com (Birgitta Böckeler): コーディングエージェント利用者のためのハーネスエンジニアリング
• martinfowler.com (Birgitta Böckeler): コーディングエージェント向けの保守性センサー
• martinfowler.com: ハーネスエンジニアリングについての最初の考察 (メモ)
• OpenAI: ハーネスエンジニアリング — エージェント前提の世界で Codex を活用する
• Anthropic: 長時間稼働するエージェントのための効果的なハーネス
• LangChain ドキュメント: Deep Agents の概要 (ハーネスの構成要素)
• Thoughtworks Technology Podcast: ハーネスエンジニアリングとは何か
• Terminal Bench 2.0 リーダーボード