【完全攻略】今さら聞けないハーネスエンジニアリングとは？

ライター：國末拓実
編集：小澤健祐

「ChatGPTにあれだけプロンプトを工夫したのに、自社の業務では結局うまく動かない」「AIエージェントを使ってみたけど、すぐに迷子になって途中で止まってしまう」

そんな経験はないでしょうか？

いま、AI活用の世界では「プロンプトエンジニアリング」「コンテキストエンジニアリング」の次に広がりつつある考え方として、「ハーネスエンジニアリング（Harness Engineering）」が注目を集めています。

この表現を早い段階で明確に使った一人が、HashiCorp（ハシコープ）共同創業者の Mitchell Hashimoto（ミッチェル・ハシモト） 氏です。

参考：Mitchell Hashimoto「My AI Adoption Journey」

また、LangChain の Vivek Trivedy（ビベック・トリヴェディ） 氏が「Agent = Model + Harness（エージェントとは、モデルとハーネスの和である）」という分かりやすい等式で整理したことで、この概念はより語りやすくなりました。

参考：Vivek Trivedy「The Anatomy of an Agent Harness」

そこでこの記事では、ハーネスエンジニアリングの基本概念から、ハーネスを構成する主要素、「同じモデルでも性能が大きく変わる」3つの事例、OpenAI・Anthropic・LangChainの最新動向、自社で始めるための導入ステップまで、ビジネスパーソン向けに分かりやすく解説します。

読み終える頃には、「なぜプロンプトやコンテキストだけでは足りないのか」「自社で何から手をつければいいのか」がはっきりイメージできるはずです。

ハーネスエンジニアリングとは？基本概要

まずは、ハーネスエンジニアリングとは何か、その基本的な概念から見ていきましょう。

ハーネスエンジニアリングとは何か

ハーネスエンジニアリングとは、広い定義では「LLM（大規模言語モデル）以外のすべてを設計する技術」です。

「ハーネス（Harness）」とは、もともと馬車の馬を制御するための「馬具」や、登山で身体を固定する「安全ベルト」を指します。共通する本質は「強力だが予測不可能な力を、目的通りに安全に制御するための器具」であるという点です。

これをAIに当てはめると、馬は強力だが予測不可能なLLMで、ハーネスはそれを取り囲む 制約・ツール・フィードバックループ・検証ロジック・観測レイヤー を含む制御インフラ全体のことです。

参考：Martin Fowler サイト掲載 Birgitta Böckeler「Harness engineering for coding agent users」

LangChain の Vivek Trivedy 氏は次のように表現しています。

Agent = Model + Harness. If you're not the model, you're the harness.（エージェント＝モデル＋ハーネス。あなたがモデルでないなら、あなたはハーネスである）

つまり、AIエージェント開発では、エンジニアの仕事の一部が「コードを直接書くこと」から「モデルが安全に動作するための環境を整えること」へと広がっているのです。

参考：Vivek Trivedy「The Anatomy of an Agent Harness」

特に Hashimoto 氏は「エージェントが何かミスをしたら、二度と同じミスをしないように仕組みを加える」という発想を示しました。

これは、失敗のたびにハーネスを少しずつ締め直していく、いわばラチェット的な改善として理解できます。

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

ここまで読んで「コンテキストエンジニアリングとどう違うの？」と疑問に思われた方も多いはずです。

3つの概念の関係を表に整理すると以下のようになります。

この3つは対立関係ではなく 入れ子構造 です。

プロンプトエンジニアリングはコンテキストエンジニアリングの一部であり、コンテキストエンジニアリングはハーネスエンジニアリングの一部に含まれます。

イメージとしては、プロンプトが「台詞」、コンテキストが「舞台装置」、ハーネスが「劇場の建物・スタッフ・防災設備」まで含めた 興行全体 に近いと考えてください。

ハーネスを構成する3つの主要素

次に、ハーネスを構成する具体的な要素を、3つの大カテゴリに整理して解説します。

①永続的ストレージとコンテキスト管理

LLMは本質的に「記憶を持たない」存在です。

会話セッションが終わると、どんな指示も忘れてしまいます。

これを補うのがハーネスの永続化機能です。

• ファイルシステム連携：途中の作業メモや計画を todo.md などに書き出し、次のセッションで読み込ませる
• Git連携：エージェントが書いたコードを自動コミットし、失敗時に巻き戻し可能にする
• 必要に応じたマークダウンのファイル（AGENTS.md／CLAUDE.md）：プロジェクト固有のルールやコーディング規約を記述する常時ロードファイル

参考：OpenAI「Harness engineering: leveraging Codex in an agent-first world」

特に重要なのが、長時間のタスクでコンテキストウィンドウが枯渇する「Context Rot（コンテキスト腐敗）」への対策です。

Compaction（要約の圧縮）、Tool-call offloading（巨大出力をディスクに退避させる）、Progressive disclosure（段階的な開示）などの技術がここに含まれます。

②自己検証ループとガードレール

AIエージェントが「完了しました」と宣言しても、それが本当に正しいとは限りません。

ハーネスはこの「幻想による完了報告」を防ぐ仕組みを持ちます。

• 自動テスト実行：エージェントが「完了」と言ったら、ハーネスが自動でlintやテストを走らせ、失敗ならエラーログとともにエージェントに差し戻す
• Playwright（プレイライト）等のブラウザ自動操作：UIの動作確認をエージェントに代行させる
• 破壊的コマンドのブロック：rm -rf（フォルダ全削除）や DROP TABLE（テーブル削除）など危険な操作はハーネス層で物理的に止める
• Human-in-the-Loop（人間承認ゲート）：本番デプロイや高額決済の前に必ず人間に確認を求める

ここでのポイントは、ThoughtworksのDistinguished Engineer Birgitta Böckeler（ビルギッタ・ベケラー） 氏が重視した「計算的Sensor を実行ループに組み込む」という発想です。

参考：Birgitta Böckeler「Harness engineering for coding agent users」

AGENTS.md に詳細ルールを書くだけ（自然言語による指示）では、AIは確率的に必ずルールを破ります。

リンターやテストといった機械的に間違いを止める仕組みをハーネスに直接埋め込むことが、信頼性確保の鍵となります。

③オーケストレーションとメモリ管理

複雑な業務は、1人のAIに全部やらせるのではなく、専門領域ごとにエージェントを分けたほうが成果が上がります。

• Planner（計画担当）：タスクを細かいステップに分解する
• Generator（実装担当）：実際のコードや文書を生成する
• Evaluator（評価担当）：結果を厳しく審査する
• サンドボックス：危険な操作を隔離環境で実行する

特にAnthropic（アンスロピック）が提案した GAN（敵対的生成ネットワーク）着想ハーネス は、Generator と Evaluator を完全分離することで「自己評価バイアス（自分に甘い採点）」を構造的に排除する革新的な設計として注目されています。

参考：Anthropic「Harness design for long-running application development」

「ハーネス次第で性能が変わる」3つの事例

「ハーネスがそんなに重要なの？」という疑問に答える、参考になるデータや事例を3つ紹介します。

事例①：SWE-Bench Pro で22ポイントもスコアが変動

SWE-Bench Pro は、AIエージェントの実務的なコーディング能力を測るために提案された、長期・複雑タスク重視のベンチマークです。

このベンチマークをめぐって、ハーネスの差を示す興味深い報告があります。

BSWEN のブログでは、全く同じモデルの重み（賢さ）を使っても、エージェントのscaffold（足場＝ハーネス）を変更するだけで、スコアが22ポイント変動したと報告されています（基本scaffoldで38%、フルハーネスで60%）。

参考：BSWEN「What Does SWE-bench Pro Reveal About Agent Scaffold Performance?」

ただし、この22ポイント差は公式論文ではなくブログ上の整理であるため、「ハーネスの影響は非常に大きい可能性がある」と読むのが安全です。

事例②：LangChain が同じモデルで Top30圏外 → Top5

LangChain（ラングチェーン）社は、オープンソースのコーディングエージェント「deepagents-cli」を用いて、ハーネスエンジニアリングの効果を示しました。

参考：LangChain「Improving Deep Agents with harness engineering」

基盤となるLLM（gpt-5.2-codex）を一切変更せず、ファインチューニング（追加学習）も行わずに、エージェントの実行環境（ハーネス）の設計のみを最適化した結果、Terminal Bench 2.0 という厳格なベンチマークでスコアが 52.8% → 66.5%（+13.7ポイント） に向上し、ランキングで 下位30位圏外から一気にトップ5入り を果たしました。

これは、モデルの知能が一定であっても、ツール・検証システム・オーケストレーションの設計によって、エージェントのパフォーマンスが大きく変わり得ることを示す象徴的な事例です。

事例③：HumanLayer の記事で同モデルが28位変動

HumanLayer が公開した分析によれば、Claude Opus 4.6 を Claude Code 上で動かすと Terminal Bench 2.0 で約 33位、ポストトレーニング時には未見だった別ハーネスに乗せ替えると 5位 まで跳ね上がったと報告されています。

参考：HumanLayer「Skill Issue: Harness Engineering for Coding Agents」

同じモデルでも、ハーネスを変えるだけで順位が大きく動くという報告は、ハーネスエンジニアリングの重要性を端的に示しています。

業界を牽引する3大事例

ハーネスエンジニアリングを実装した代表的な事例を3つ紹介します。

OpenAI Symphony：5ヶ月で100万行・1500 PR

OpenAIの社内エンジニアリングチーム（Ryan Lopopolo（ライアン・ロポポロ） 氏主導）は、人間が手動でコードを1行も書かずに、内部向けソフトウェアを構築・リリースするという極端な実験を実施しました。

参考：OpenAI「Harness engineering: leveraging Codex in an agent-first world」

実験の主な数値：

• 期間：2025年8月から約5ヶ月
• コードベース：約100万行（インフラ／ロジック／テスト／ドキュメント／監視）
• マージPR数：約1,500件
• チーム規模：少人数（公開資料では約3名のコアチーム）
• PR/エンジニア/日：平均3.5本（OpenAI記事で報告された値）

実験成功の鍵となったのが「Symphony（シンフォニー）」と呼ばれるオーケストレーションシステムです。

Linear（プロジェクト管理ツール）のチケットボードを「control plane（制御面）」に変換し、各チケットに独立した作業空間とCodexエージェントを自動的に割り当てる仕組みです。

参考：OpenAI「An open-source spec for Codex orchestration: Symphony」

また、Symphony の公開記事では、一部チームで最初の3週間に landed PR 数が500%増加したことが報告されています。

Anthropic：GAN着想 Three-Agent ハーネス

Anthropicの Prithvi Rajasekaran（プリスヴィ・ラジャセカラン） 氏率いるLabsチームは、敵対的生成ネットワーク（GAN）に着想を得た三層エージェント構成を発表しました。

参考：Anthropic「Harness design for long-running application development」

• Planner：要件をプロダクト仕様に分解する
• Generator：実装を行う
• Evaluator：Playwright（ブラウザ自動操作）を使ってアプリを実際に動かし、4基準（デザイン品質／独自性／技巧／機能性）で採点する

「Generator と Evaluator を完全分離することで、エージェントが自分の作業に甘い採点をする問題を構造的に解決した」という点が革新的です。

記事では、フルハーネスによって約6時間の長時間実行でアプリを作り込み、Evaluator が人間の確認だけでは見落としやすい細かな不具合まで指摘できたことが報告されています。

LangChain deepagents-cli：同モデルで14ポイント改善

前述した事例②と重なりますが、LangChain の deepagents-cli は OSS のコーディングエージェントとして、ハーネスエンジニアリング単独の効果を分かりやすく示した事例です。

参考：LangChain「Improving Deep Agents with harness engineering」

改善の中核となったのは以下の3つのミドルウェアです。

• LocalContextMiddleware：環境のマッピング
• ループ検出：同じ失敗を繰り返すのを止める
• タイムバジェッティング：厳格なタイムアウト管理

OSSのため、コードを読みながら自社のハーネス設計に応用できる点もメリットです。

ハーネスエンジニアリング導入の5ステップ

「ではうちの会社で何から始めればいいの？」という方のために、現実的な導入ステップを5つに整理しました。

STEP1 失敗パターンを見つける

まずは、既に使っているAIエージェントがどこで失敗しているかを観察することから始めます。

「指示を無視してファイルを書き換えた」「途中で目的を見失った」「同じエラーを繰り返した」など、失敗の種類をリストアップします。

これがハーネス設計の出発点です。

STEP2 全体的なハーネスの設計

次に、観察した失敗を 機械的に止める仕組み を作ります。

• 命名規則を破ったらリンターでブロック
• テストが通らないと「完了」を許さない
• 危険なコマンドはサンドボックスで実行禁止

「自然言語で注意する」だけでなく、コードレベルで制御を試みる ことが重要です。

STEP3 ルールファイルの整備

AGENTS.md／CLAUDE.md のような短いルールファイルに、自社のトーン＆マナー、コーディング規約、参照すべき公式情報源、過去の失敗から得た教訓などを記述します。

Y Combinator CEO の Garry Tan（ゲイリー・タン） 氏は、自身の CLAUDE.md が20,000行まで膨らんだ後、約200行のポインタ集に削った経験を踏まえ、「Thin Harness, Fat Skills（ハーネスは薄く、スキルは厚く）」という哲学を提唱しています。

参考：Garry Tan「Thin Harness, Fat Skills」

「あれもこれも詰め込む」のではなく、最小限のポインタに絞るのがコツです。

STEP4 Human-in-the-Loop ゲート設計

すべてを自動化するのではなく、重要な判断ポイントで人間の承認を挟む 仕組みを設計します。

• 本番環境へのデプロイ前
• 顧客への自動メール送信前
• 高額決済の処理前
• 共有ドライブのファイル削除前

「自由度が高すぎるAIは事故を起こす」という前提で、戦略的にブレーキを置くのがポイントです。

STEP5 ラチェットを回し続ける

導入して終わりではなく、新しい失敗が見つかるたびにハーネスを締め直すことを続けます。

この「ラチェット的に改善し続ける」考え方は、「失敗はモデルだけの責任ではなく、環境設定や検証手段の不足でもある」とみなすマインドセットの転換を要求します。

毎月の運用レビューで「今月どんな失敗があったか」「それをハーネスでどう防げるか」を議論する場を設けると、システム全体の信頼性が漸進的に蓄積していきます。

おわりに

この記事では、ハーネスエンジニアリングの基本概念から、構成要素、3つの実証データ、業界の最新事例、自社で始める5ステップ、そして規制対応までを徹底解説しました。

「AIを使ってみたけど期待通りに動かない」と感じてきた組織ほど、効果を実感しやすい領域です。

まずは、自社で使っているAIエージェントの「過去1ヶ月の失敗例を10個書き出してみる」ところから始めてみてください。

それが、ハーネスエンジニアリングの最初の一歩になります。

※このコンテンツには日本HPの公式見解を示さないものが一部含まれます。また、日本HPのサポート範囲に含まれない内容や、日本HPが推奨する使い方ではないケースが含まれている可能性があります。また、コンテンツ中の固有名詞は、一般に各社の商標または登録商標ですが、必ずしも「™」や「®」といった商標表示が付記されていません。