ハーネスエンジニアリングとは？AIエージェントの成果を決める環境設計を実例で解説

ハーネスエンジニアリングは、AIエージェントが安定して成果を出せるよう、モデルの外側にある環境（ハーネス）を設計する手法です。2026年2月にOpenAIが約100万行のコードをエージェントだけで生成した事例を公開し、開発現場の関心が一気に高まりました。本記事では、定義とプロンプト・コンテキストエンジニアリングとの違い、構成要素、OpenAIとAnthropicの設計思想の差、導入の始め方と見送るべき場面までを、一次情報をもとに整理します。

まとめ：ハーネスエンジニアリングは成果を左右する「モデルの外側」の設計

ハーネスエンジニアリングの要点は、AIの成果が「モデルの賢さ×環境の良さ」で決まるという前提に立ち、後者を設計対象に据えることにあります。OpenAIのCodexチームは3人から7人の体制で約5ヶ月、手書きコード0行のまま約100万行・約1,500件のPRを積み上げました。差を生んだのはモデルではなく、ルールファイル・ツール連携・フィードバックループ・状態管理・オーケストレーションという5つの層の設計です。

まず着手すべきは、ツール本体に組み込み済みのエージェントハーネスではなく、その上に載せるユーザーハーネスです。60〜100行に絞ったルールファイルと自動テストから始め、別エージェントによる検証で品質確認を機械化していくのが現実的な順序になります。一方、単発タスク中心の現場や、ルールファイル整備だけで満足してしまう運用では投資が回収できません。本記事は、この判断基準と失敗パターンまで含めて解説します。

ハーネスエンジニアリングの意味と「モデル＋ハーネス」という基本発想

馬具を語源とする「ハーネス」がAIエージェントで指す環境全体

「ハーネス（harness）」は本来、馬具や安全帯を指す言葉です。強い力を制御し、意図した方向へ導くための装具という意味があります。AIの文脈では、モデル単体を除いたすべて——リポジトリ構造、CI設定、フォーマットルール、パッケージマネージャ、プロジェクト指示、外部ツール連携、Linterなど——を束ねた環境全体を指します。賢いモデルでも、この環境が欠ければ幻覚や指示逸脱を起こし、業務では使いものになりません。

Agent＝Model＋Harnessが示す成果を決める2要素の関係

この考え方は「Agent ＝ Model ＋ Harness」という式で語られます。エージェントの成果は、モデルの性能だけでなく環境の質との掛け算で決まる、という見方です。LangChainはハーネスを「モデル以外の全要素」と広く定義し、Anthropicは入力・ツール呼び出し・状態管理・評価・記録を束ねてエージェントとして機能させる土台だと説明しています。評価すべきは「モデル単体」ではなく「モデル＋ハーネス」だ、という主張です。

用語の起点となったMitchell Hashimotoの「失敗の再発防止」定義

用語が広まった起点は、2026年2月にHashiCorp共同創業者のMitchell Hashimoto氏が自身のブログで示した定義です。氏は「エージェントが失敗するたびに、その再発を防ぐ仕組みを環境側にエンジニアリングする」習慣をharnessと呼びました。語そのものはソフトウェア領域では古く、言語モデル評価ツールlm-eval-harness（2020年公開、初版リリースは2021年）も「harness」を冠する初期の例の一つです。新しいのは、自律的に動くコーディングエージェントを御す設計対象として再定義された点です。

プロンプト・コンテキスト・ハーネス各エンジニアリングの違い

一問一答の精度を上げるプロンプトエンジニアリングの守備範囲

プロンプトエンジニアリングは、AIに渡す1回の指示文を工夫して出力精度を上げる手法です。役割の付与や出力形式の指定が代表的な技法で、一問一答の精度には効きます。ただし守備範囲は単発のやり取りに限られます。エージェントが数時間にわたって何百もの判断を下す状況には、指示文の工夫だけでは対応できません。

見せる情報を組み立てるコンテキストエンジニアリングの役割

次に位置するのがコンテキストエンジニアリングです。社内ドキュメント、過去の対話、ソースコード、MCP経由の情報など、AIが判断材料として受け取る情報全体を集め・絞り込み・維持する設計を指します。建築にたとえれば、プロンプトが「話しかけ方」、コンテキストが「設計図を手渡すこと」にあたります。国内の月間検索数も2,500前後あり、ハーネスを理解する前提知識として押さえる価値があります。

2つを内包するハーネスエンジニアリングの「運転設計」という位置づけ

ハーネスエンジニアリングは、この2つを内包する一段広い概念です。何を見せるかに加え、どの順番で動かすか、途中結果をどう評価するか、失敗時にどうやり直すか、次のセッションへ何を引き継ぐかまでを設計します。3者の関係はレイヤーであり、排他ではありません。「ハーネス ⊇ コンテキスト ⊇ プロンプト」と整理すると、学ぶ順番もこの順になります。

2026年に注目が集まった背景とOpenAIの100万行コード実験

コード生成の高速化で人間のレビューとQAがボトルネック化した構造

引き金は、コード生成の高速化が生んだ新しい詰まりです。エージェントが生成する差分量が増えるほど、確認待ち・差し戻し・仕様の見落としが累積します。OpenAIは、コードのスループットが上がるにつれ、固定的な制約が人間のレビュー能力（human QA capacity）へ移ったと述べています。生成を速くしても、検証が人間に張り付いたままでは全体は速くなりません。

3人→7人・5ヶ月・100万行・PR1500件というOpenAIの実測値

その解決策を実証したのが、OpenAIが2026年2月11日に公開した「Harness engineering: leveraging Codex in an agent-first world」（著者Ryan Lopopolo氏）です。空のGitリポジトリから始め、約5ヶ月で手書きコード0行のまま約100万行を生成し、約1,500件のPRをマージしました。チームは3人で着手して7人へ拡大。人を増やすほど速くなったことが、生産性の主因がハーネスそのものであることを示しています。初期は環境整備やツール連携の不足で生産性が低く、ハーネスを段階的に改善するにつれ伸びました。最初から高速だったわけではない、という順序が示唆的です。

「AIは増幅器」とするDORAが示す組織能力による成果差

組織側の条件も無視できません。DORAは「AIは増幅器である」とし、整った組織では強みを伸ばし、弱い組織では弱点を速く広げると指摘します。成否を分けるのはツール単体ではなく、内部データやドキュメントの品質、ワークフロー、評価の仕組みといった組織能力だという整理です。同じモデルを使っても成果に差が出る理由が、ここにあります。

ハーネスを構成する5つの要素と各要素を支える具体ツール

指示を与えるルールファイル（AGENTS.md／CLAUDE.md）の設計

1つ目はルールファイルです。プロジェクト固有の規約や禁止事項をAIに伝える文書で、ツールによりAGENTS.mdやCLAUDE.mdと名前が異なります。書くべき内容はAIが間違えやすいプロジェクト固有のルールに絞り、一般的な作法は省くのが効きます。OpenAIは、すべてを1ファイルに詰めず約100行の「目次」に留め、詳細はdocs/ディレクトリを正とする方式を採りました。

外部機能をつなぐツール連携（MCP）が担うハーネスの拡張

2つ目は、外部機能をAIにつなぐツール連携です。検索・DB・ブラウザ操作などをエージェントが自分で呼べるようにする層で、いまはMCP（Model Context Protocol）が標準的な接続方式になりました。たとえばFastMCPを使えばMCPサーバを手早く実装でき、自作ツールをハーネスへ組み込めます。ツールが足りないと、エージェントは推測で動き、誤った前提のまま作業を進めてしまいます。

出力を検証するフィードバックループとAIコードレビューの組み込み

3つ目は、出力を検証して直させるフィードバックループです。人間が毎回すべてを確認する運用は規模が上がると詰まるため、自動テストや別エージェントのレビューで品質を機械的に確認します。AnthropicがGAN（敵対的生成ネットワーク）から着想したように、生成役と評価役を分けると自己採点の甘さを避けられます。実装面ではClaude CodeのCode Review機能をハーネスへ組み込むと、PR単位での検証を自動化できます。

セッションをまたいで作業を引き継ぐコンテキスト・状態管理

4つ目は、セッションをまたいで作業を引き継ぐコンテキスト・状態管理です。AIには会話の記憶が残らないため、進捗ファイルに「前回どこまで進めたか」を書き出し、次のセッションのエージェントがそれを読んで再開する設計が要ります。OpenAIはチームの知識をすべてリポジトリ内のバージョン管理対象として共置しました。Slackやドキュメントに散ったままの情報は、エージェントからは存在しないのと同じだからです。

工程を自律で回すオーケストレーションとCIへの組み込み

5つ目は、工程を自律で回すオーケストレーションです。タスクの分割、実行順序、失敗時のやり直しを束ね、CIに組み込んで人手を介さず動かします。OpenAIはアーキテクチャ上の不変条件をカスタムLinterと構造テストで機械的に強制し、違反をCIで弾きました。Claude Code GitHub ActionsならPR作成からチェックまでを自動化でき、検証の連鎖をパイプライン化できます。

OpenAIとAnthropicで異なるハーネス設計アプローチの比較

リポジトリを正とするOpenAIのgolden principlesと自動ガベージコレクション

OpenAIのアプローチは、リポジトリを唯一の正（system of record）に据える点に特徴があります。プロジェクトの中核原則（golden principles）をコードベースへ埋め込み、バックグラウンドのCodexタスクを定期実行して逸脱を検出し、リファクタリングのPRを自動で出します。多くは1分以内に自動マージされる小さな修正です。金曜を手作業クリーンアップに充てた時期は工数の2割を消費して追いつかず、継続的な自動ガベージコレクションへ切り替えました。

役割分担で品質を守るAnthropicのPlanner・Generator・Evaluator

Anthropicは、役割の異なる複数エージェントで品質を守る設計を示しました。Plannerが短いプロンプトを製品仕様へ展開し（実装詳細はあえて未指定にして、早すぎる過剰仕様が下流のエラーへ連鎖するのを避ける）、Generatorが実装します。Generatorはコードを書く前にEvaluatorと「スプリント契約＝doneの共有定義」を結び、EvaluatorはPlaywrightで実ユーザーのようにUI・API・DBをクリック検証します。単独エージェントは起動はするが内部の接続が壊れたゲームを生み、3エージェント構成はそれを防ぎました。

2社の違いに見る「機械的強制」と「エージェント分業」という設計軸

2社の違いは、品質をどう担保するかの軸に集約できます。OpenAIは「機械的強制」、Anthropicは「エージェント分業」に重心を置きました。

どちらかが正解というわけではなく、コードベースの規模と仕様の固まり具合で使い分けます。

エージェントハーネスとユーザーハーネスの違いと注力すべき範囲

ツール本体に組み込まれるエージェントハーネス（作り手側）の領域

ハーネスには「作り手」と「使い手」の2層があります。エージェントハーネス（ビルダーハーネス）は、オーケストレーターや制御ループ本体を作る領域で、Claude CodeやCodexといったツール自体に内包されています。Garry Tan氏（Y Combinator CEO）は「Thin Harness, Fat Skills」として、ループ管理は約200行に薄く保ち、知能はSkillsへ、実行は決定論的なツールへ寄せる方針を示しました。多くの開発者は、この層を自前で書く必要がありません。

Claude CodeやCodexの上に載せるユーザーハーネス（使い手側）の領域

もう一方のユーザーハーネスは、既存ツールの上に自分たちの制約や仕組みを載せる領域です。Martin Fowler氏のサイトでBirgitta Böckeler氏は、これを「特定のユースケースと社内システム向けにカスタマイズした要素」と定義しました。CLAUDE.mdを書き、テストを整備し、ビルドチェックを自動化する——Claude Codeを日常的に使う開発者がやっていることの大半は、このユーザーハーネスにあたります。

多くの開発者がまず注力すべきはユーザーハーネスという判断

結論として、まず注力すべきはユーザーハーネスです。エージェントハーネスはツールが内包しており、自前のオーケストレーター開発は多くのチームにとって過剰投資になります。逆に、ルールファイルやSkillsの整備「だけ」で開発が回り始めたとき、「これで全部だ」と止まるのは射程の取り違えです。自分のチームに必要な範囲を、薄いユーザーハーネスから少しずつ広げていくのが妥当な順序になります。

ハーネスエンジニアリングを薄く始めるための初期構築の手順

60〜100行に絞ったルールファイルから着手する最初の一歩

始めの一歩は、ルールファイルを60〜100行に絞って書くことです。AIが既に知る一般論ではなく、「styled-componentsは使わずTailwindを使う」「.envの値をハードコードしない」といったプロジェクト固有のルールに限定します。長く書くほどタスク本来の文脈を圧迫し、規約も陳腐化して機械検証もしづらくなります。短く保ち、詳細は別ドキュメントへ逃がすのが起点です。

「Thin Harness, Fat Skills」に沿った薄いループと厚いスキルの分離

次に、薄いループと厚いスキルを分けます。制御ループは最小限に保ち、繰り返す定型作業（スクリーンショット取得、ログ確認など）はエージェントが自分で呼べるスキル・ツールとして切り出します。Claude Codeを拡張するSuperClaudeのようなフレームワークでコマンドやペルソナを足すと、ユーザーハーネスを薄いまま機能拡張できます。自作のシェルスクリプトをツール化するだけでも効果が出ます。

自動テストと別エージェント検証で品質確認を機械化する広げ方

最後に、品質確認を人手から機械へ移します。自動テストとLinterをCIへ組み込み、AIが出したコードをまず機械が弾く層を作ります。そのうえで、生成役とは別のエージェントにレビューさせ、自己採点の甘さを潰します。OpenAIがエージェント同士にコードレビューをさせ、意思決定の記録をリポジトリに残したように、検証と記録をハーネスへ組み込むほど、次のセッションが安定します。

ハーネスエンジニアリングを見送るべき場面と典型的な失敗パターン

単発タスク中心で環境投資が見合わない場合の見送り基準

ハーネスエンジニアリングが見合わない場面もあります。単発の調査や使い捨てスクリプトのように、同じ作業を繰り返さないタスクでは、環境への作り込みが回収できません。エージェントが数時間にわたり自律で動く前提がない限り、ルールファイルや検証ループの整備は過剰投資になります。まず「その作業は反復するか」を見送りの判断基準にしてください。

ルールファイル整備だけで「完了」と誤認する射程の取り違え

多い失敗は、ルールファイルを整えただけで「ハーネスエンジニアリングをやっている」と満足することです。CLAUDE.mdの整備はユーザーハーネスの入り口にすぎません。フィードバックループや状態管理、オーケストレーションが欠ければ、長時間タスクでは品質が崩れます。「モデルを呼んでいるだけのPoC」で止まらないよう、検証と引き継ぎの仕組みまで設計するかが分かれ目になります。

自己評価の甘さを放置して品質劣化を見逃す運用上の罠

運用上の罠は、エージェントの自己評価を信じることです。AIは自分の出力を「素晴らしい」と過大評価しがちで、コンテキストウィンドウが埋まると作業を終える前に切り上げる傾向も報告されています。生成役に検証まで任せると、起動はするが中身が壊れた成果物を見逃します。評価役を分け、テスト結果という客観的な事実で合否を決める設計が要ります。

よくある質問

ハーネスエンジニアリングについて、検索されることの多い疑問へ簡潔に回答します。

ハーネスエンジニアリングはエンジニア以外でも実践できますか？

設計思想の理解は、エンジニア以外にも役立ちます。「AIの成果はモデルより環境で決まる」「どこを人が見て、どこを機械に任せるか」という判断は、PMや経営者がベンダーや社内チームに確認すべき観点です。一方、ルールファイルやCIの実装そのものはエンジニアの領域です。非エンジニアは概念と判断軸を押さえ、実装は開発者に委ねる、という役割分担が現実的になります。

ハーネスエンジニアリングとAIエージェント開発・MLOpsは何が違いますか？

AIエージェント開発はエージェントを作ること全般を指し、ハーネスエンジニアリングはそのうち「モデルの外側の環境設計」に焦点を当てた部分概念です。MLOpsはモデルの学習・デプロイ・監視を扱う運用領域で、モデル内部に踏み込みます。ハーネスエンジニアリングはモデルを再学習せず、足場・制約・フィードバックループを設計する点で守備範囲が異なります。重なる部分はありますが、対象とする層が違います。

ハーネスはどのくらいの規模から作り込むべきですか？

反復するタスクが現れた時点が目安です。同じ種類の作業を週に何度もエージェントへ任せるなら、ルールファイルと自動テストの整備が回収できます。最初から大規模に作り込む必要はありません。60〜100行のルールファイルと最小限のCIから始め、エージェントがつまずいた箇所を都度ハーネスへ書き足していくと、必要な分だけ育っていきます。

Claude CodeやCodexを使えばハーネスエンジニアリングは不要ですか？

不要にはなりません。Claude CodeやCodexはエージェントハーネス（作り手側）を内包していますが、プロジェクト固有のルール、ツール連携、検証ループといったユーザーハーネスは利用者が載せる必要があります。ツールはあくまで土台で、自社の規約や品質基準をどう機械化するかは、個々のチームの設計次第です。高機能なツールほど、上に載せるユーザーハーネスの差が成果を分けます。

ハーネスエンジニアリングを学ぶ順番はどうすればよいですか？

プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリングの順が無理のない流れです。3者はレイヤー関係にあり、下位を理解せずに上位だけ学んでも噛み合わないためです。まず単発の指示精度、次に渡す情報の設計、最後に作業全体の運転設計へと広げます。実務では薄いユーザーハーネスを1つ作り、動かしながら各層の役割を体感するのが近道になります。

関連記事

• Serena MCPとは？概要と基本機能を徹底解説し基礎から理解：ツール連携層を支えるMCPサーバの基礎を知りたい場合に。
• Playwright MCPとは何か？その基本概念と登場の背景を解説：検証層でブラウザ操作を自動化する仕組みの理解に。
• コード生成AIのメリットとデメリットの詳細解説：ハーネスの前提となる生成AIの長所と短所を整理したい場合に。
• Claude CodeとSerena MCPの統合による開発効率の向上：ユーザーハーネス構築の具体例として参考になります。