ハーネスエンジニアリングの事例｜4社はモデルの外側で何を変えたか

ハーネスエンジニアリングとは、AIエージェントが同じ失敗を繰り返さないよう、モデルの外側にある指示・道具・検証・権限・実行環境を設計することです。

2026年2月から8月にかけて、OpenAI・LangChain・Anthropic・Uberが、ハーネスの作り方しだいで成績・品質・費用が大きく動いた事例を相次いで公開しました。本記事では4社の事例を「何を変え、何が変わったか」で比べ、同じモデルでハーネスだけを替えた比較では正答率の差が誤差の範囲に収まり、費用は最大3倍違ったという2026年10月の研究もあわせて紹介します。Claude CodeやCodexを開発チームで使い始めた開発責任者・テックリードが、最初に整える順番を決められるように構成しました。用語の基本はハーネスエンジニアリングとは？で解説しています。

4社の事例が示したのは、ハーネスが成果を上げる手段であると同時に、品質を落とす原因にも、費用を決める要因にもなることです。

結論から言えば、ハーネスで成績を上げた事例も品質を落とした事例もあり、費用を測ったUberと山東大学の研究では、どちらも大きな差が出ました。

表の数値は、各社と研究者が公表したものです。

事例を読むときは、木下雄一朗氏（株式会社キー・プランニング）のセミナー資料「ハーネス設計入門」（2026年9月）の整理が役に立ちます。同資料は、モデル以外のすべてを、走る前に進路を伝える「馬具」（AGENTS.md・Agent Skills）、走った後に逸脱を機械的に判定する「柵」（リンター・型チェック・テスト・フック）、触れられる範囲を最初から決める「境界」（サンドボックス・通信の遮断・最小権限）の3層に分けています。馬具は確率的にしか効きません。柵は決めた基準で機械的に判定しますが、テストのように実行環境で結果が揺れるものもあります。境界は、隔離・通信の制限・最小権限によって、許可された範囲の外へのアクセスや実行を止めます。

OpenAIの社内チームは、コードをすべてCodexに書かせ、人は1行も書かないと決めました。その代わりに時間を使ったのが、エージェントが迷わない環境づくりです。

Mitchell Hashimoto氏がこの取り組みを「ハーネスエンジニアリング」と呼んだ6日後の2026年2月11日に、OpenAIが公開した記事がその実践例です。

人が1行も書かないと決めたら、技術者は何をするのでしょうか。OpenAIの報告によると、社内チームは5か月をかけて、社内の利用者と外部の試験利用者がいる製品のベータ版を作りました。リポジトリは約100万行に達し、アプリの処理、テスト、CIの設定、文書、監視の道具まで、すべてCodexが書いています。手で書いたコードは0行です（InfoQの記事）。

3人で始めたチームがマージしたプルリクエストは約1,500件で、1人1日あたり平均3.5件にあたります。チームが7人に増えると、処理量は頭打ちにならずに増加しました。1回のCodexの実行が、技術者の寝ている間も含めて6時間ほど1つの作業を続けることもたびたびありました。

速く進むほど、人のレビューが詰まりの原因になりました。担当のRyan Lopopolo氏は、いまでは人のレビューのほとんどがマージ後で、レビューと修正もエージェントに任せていると対談で話しています。人の仕事は、コードを書くことから、環境を設計し、意図を伝え、フィードバックの仕組みを作ることへ移りました。

速さが出たのは、エージェントが参照する知識と、機械で守らせる決まりを整えてからでした。

まず、AGENTS.mdを百科事典ではなく目次として扱いました。100行程度に抑え、設計書・実行計画・仕様はdocs/以下の文書に分け、AGENTS.mdにはその場所だけを書きます。文書同士のリンクや構成の整合も、リンターとCIで機械的に確かめています。

次に、エラーメッセージに直し方を書いた独自のリンターです。エージェントは失敗するとエラーメッセージを読むので、メッセージそのものが次の一手の指示になります。依存の向きは型から画面まで6つの層の順に決め、層をまたぐ参照は構造テストで止めました。

最後が定期的な掃除です。エージェントはリポジトリにある書き方を、良いものも悪いものも真似します。守るべき原則をリポジトリに書き、ずれた箇所を片付ける作業を定期的に回して、悪い書き方が広がるのを防ぎました。この作業は、使わなくなったメモリを回収する仕組みになぞらえて、ガベージコレクションと呼ばれています。

LangChainは、モデルを固定したまま自社のコーディングエージェントのハーネスだけを直し、Terminal-Bench 2.0の成績を13.7ポイント上げました。

2026年2月17日に公開された同社の記事によると、効いたのはプロンプトの言い回しより、エージェントに自分の作業を確かめさせる仕組みでした。

Terminal-Bench 2.0は、機械学習・デバッグ・生物学などの89課題で、ターミナルを操作するエージェントの力を測るベンチマークです。LangChainのコーディングエージェント（deepagents-cli）は、既定のプロンプトと標準の道具の構成で52.8%でした。順位表では上位30位のわずかに外です。

モデルはOpenAIのコーディング向けモデルに固定し、ハーネスだけを繰り返し直した結果、成績は66.5%に向上しました。この13.7ポイントの差で、順位は上位5位に入りました。

改善の回し方そのものも仕組みにしています。実行の記録（トレース）をLangSmithから取り出して失敗の原因をまとめる手順をAgent Skillsの形にし、毎回同じやり方で分析できるようにしました。トレースからは、推論の誤り、課題の指示を守らない、テストや検証の欠落、時間切れといった失敗が見つかりました。

LangChainがまず手を入れたのは、エージェントが作業を終える直前です。モデルは最初に見つけたもっともらしい答えで終わりがちです。そこで、終了しようとした時点で処理に割り込み、課題の仕様に照らした検証を促す仕組みを入れました。

次が時間の予告です。Terminal-Benchには厳しい制限時間があり、エージェントは時間の見積もりが苦手です。残り時間の警告を差し込み、作業を切り上げて検証に移るよう促しました。

3つ目は堂々巡りの検知です。一度決めた方針に固執して、同じファイルに小さな修正を10回以上繰り返す記録がありました。ファイルごとの編集回数を数え、一定の回数を超えたら方針を見直すよう文脈を足しています。

推論量の配分も変えました。全工程を最大の推論量にすると時間切れが増えて53.9%、全工程を一段下げると63.6%でした。LangChainは計画と最後の検証に推論を厚くする配分を採り、ほかの改善と合わせて66.5%に届いています。同じ改善を回していない古い版のハーネスでClaudeのモデルを試すと59.6%にとどまり、モデルごとにハーネスを合わせる必要も見えました。

ハーネスは成績を上げるだけではありません。Anthropicは2026年4月、Claude Codeで3月から4月にかけて続いた品質の低下が、モデルではなくハーネス側の3つの変更で起きていたと公表しました。

APIと推論の基盤には影響がなく、3件とも4月20日のリリース（v2.1.116）で解消しています。

1つ目は推論量の既定値です。3月4日、長く考えている間に画面が固まったように見える問題を減らすため、Claude Codeの既定の推論量を「高」から「中」に下げました。賢さが落ちたという声が続き、4月7日に元へ戻しています。Anthropic自身、誤った取捨選択だったと認めました。

2つ目は、キャッシュの最適化に入ったバグです。3月26日、1時間以上放置したセッションを再開するときに、古い思考の記録を一度だけ消す変更を入れました。ところがバグで、以後のターンでも毎回消えるようになりました。Claudeは、なぜその操作を選んだかの記憶を失ったまま作業を続け、忘れっぽく同じことを繰り返すように見えました。キャッシュも外れ続け、利用上限の減りが速いという報告にもつながっています。修正は4月10日です。

3つ目はシステムプロンプトの1行です。4月16日、ツール呼び出しの合間の文章を短くする指示を足したところ、ほかのプロンプトの変更と重なってコーディングの品質が下がりました。1行ずつ外して影響を測ると、評価の1つで品質が3%低下していたことが判明しました。この指示は4月20日に取り消されています。

3つの変更は、それぞれ別の利用者に別の日程で効いていたため、全体としてはばらばらで一貫しない劣化に見え、ふだんのフィードバックの揺れと見分けにくかったといいます。思考の記録を消すバグは、人と自動のコードレビュー、ユニットテスト、E2Eテスト、自動の検証、社内での利用をすべて通過していました。無関係な2つの社内実験が、症状を隠していたためです。

柵を何重に立てても、すり抜ける変更は出ます。Anthropicの再発防止策は、その前提に立っています。Claude Codeのシステムプロンプトを変えるたびにモデルごとの評価を幅広く回し、1行ずつ外して影響を測る検証を続け、プロンプトの変更を確認しやすくする道具を作りました。賢さと引き換えになりうる変更には、様子を見る期間、広い評価、段階的な配布を入れます。社員が公開版と同じビルドを使う割合も増やすとしています。

興味深いのは、モデル固有の変更が対象のモデルにだけ効くよう、Claude Codeを作るチーム自身がCLAUDE.mdに指針を足した点です。ハーネスの作り手も、ハーネスで自分たちの作業を律しています。

Uberは、利用者とリクエストが大きく増えるなかで、ハーネスの設定と道具の渡し方を見直し、AIの総額を4月からほぼ横ばいに保ちました。

前提となる利用の規模も大きく、Uberではプルリクエストの70%以上にエージェントが関わり、社員が作ったAgent Skillsは3,600を超えます。数字は2026年8月27日に同社の技術ブログで公開されたものです。

Uberは、AIの費用の総額を次の6つの項の掛け算に分けています。

利用者数 × 1人あたりのセッション数 × 1セッションあたりのターン数 × 1ターンあたりのリクエスト数 × 1リクエストあたりのトークン数 × トークンの単価

前の2項は利用の広がりで、増えてよい項です。中の3項はエージェントが自分で生む手間で、ハーネスの工夫で減らせます。最後の単価は、どのモデルに何を任せるかで決まります。「AIの費用が増えた」という1つの数字を、増えてよい増え方と減らすべき増え方に分けられるのが、この分解の利点です。

2月から8月にかけて、エージェントを使う週ごとの利用者は7倍、週ごとのリクエストは9.4倍に増加しました。それでもモデルを固定して比べると、2月から7月にかけて、1,000リクエストあたりの費用はピークから約34%、1セッションあたりの費用は6月のピークから52%減少しました。

最も効いたのは、サブエージェントの既定のモデルでした。サブエージェントは入力と範囲が決まった作業を受け持つため、最上位の推論が要らない作業が多くあります。既定を安いモデルにして、必要なときだけ人が切り替えられるようにし、作業の分解と評価は主のモデルに任せました。

人が対話するセッションでは、プロンプトのキャッシュの保持時間を既定の5分から1時間に延ばしました。技術者がセッションを5分以上放置するたびにキャッシュが切れ、会話の履歴を正規の料金で送り直していたためです。1つの短い作業だけを受け持つサブエージェントは、5分のままにしています。

道具の渡し方も変えました。Uberがそれまで使っていた方式では、使うかどうかに関係なく、すべての道具の定義をセッションに読み込んでいました。道具が100を超えると定義だけで約5万〜7万トークンになり、ターンごとに送り直されていました。Uberは社内の1,000を超えるMCPの道具をコマンド（CLI）として呼べるようにし、必要な道具だけを探して読み込む仕組みに切り替えました。

探す手間も減らしています。社内のサービス、チーム、障害の記録、データの使われ方などをつないだ社内情報のグラフ（約2,400万の点と8,000万のつながり）を作り、エージェントが自然な文章で問い合わせられるようにしました。同じ質問に、グラフを使うエージェントは38秒で答えました。使わないエージェントは20分かけてサブエージェントを2つ起こし、3回エラーを出したうえで、そのデータは問い合わせられないと誤った結論を出しています。

必ず上がるとは限りません。2026年10月に公開された山東大学の研究の比較条件では、Claude Codeとmini-SWE-agentの正答率は5ポイント以内で同等と判定され、費用には最大3倍の差がありました。

研究チームは5つのモデルをClaude Code・OpenCode・mini-SWE-agentの3つのハーネスで動かし、ソフトウェア開発の課題集SWE-bench Verifiedで比べました。同等と判定されたのは、最も重いClaude Codeと最も軽いmini-SWE-agentを447課題・2つのモデルで比べた結果です。難しい45課題では、ハーネスを替えて正誤が入れ替わった課題の割合と、同じハーネスを再実行して入れ替わった割合が、どちらも13%でした。誤差を超えた差は、OpenCodeが最大9ポイント下回ったものだけです。

適用範囲には限りがあります。結果は主に1つのベンチマークから得たもので、著者は、汎用のエージェントでは事情が違いうること、非公開の最先端モデルで同じ差が出るかは確かめられていないことを明記しています。

一方、1課題あたりの費用は、同じモデル・同じ課題・同じ料金表で最大3倍の差が出ました。差を生んだのは、毎回の呼び出しに付けて送る前置き（システムプロンプトと道具の定義）です。Claude Codeは16,581トークン、OpenCodeは7,025トークン、mini-SWE-agentは829トークンで、ステップのたびに送り直されます。UberがMCPの定義を文脈から外したのと同じ理屈です。

評価の環境も成績を動かします。Anthropicは2026年2月、同じモデル・同じハーネス・同じ課題のまま、課題ごとのCPUとメモリの割り当てだけを変えてTerminal-Bench 2.0を回し、成績が最大6ポイント動いたと報告しました。評価の設定がそろっていない順位表では、3ポイント未満の差は疑ってかかるべきだというのが同社の見解です。

LangChainの13.7ポイントのように大きな改善もあります。ただ、自分のチームでハーネスを変えるときは、同じ設定を何度か回してぶれの幅を先に測り、費用も一緒に記録してください。

事例を自分のチームに持ち込むなら、境界、ルール、検証の門とループの順に整えるのが近道です。

木下氏の資料も、逆の順に進めると効かないルールと使われない道具が積み上がると指摘しています。以下は、同資料の手順に4社の事例を重ねたものです。

最初に決めるのは、エージェントが触れられる範囲です。サンドボックスやクラウド上の作業環境で動かし、本番の認証情報は渡しません。柵は完全ではなく、本番データの削除や機密の送信のように取り返しのつかない事故は、起きてから検知しても手遅れだからです。Anthropicの事例でも、何重ものレビューとテストを通った変更が品質を落としました。

危険が最も大きくなるのは、機密データに触れられる、信頼できない内容を読む、外部へ送信できる、の3つを同時に許したときです。Simon Willison氏はこれを「致命的な三要素（lethal trifecta）」と呼びました。外部のページやメールを読ませる作業では、プロンプトインジェクションで指示を書き換えられる前提に立ち、3つのうち少なくとも1つを構造で外します。道具ごとの権限の分け方は最小権限でAIエージェントのツール実行権限を設計する方法で扱っています。

Ghosttyの作者Mitchell Hashimoto氏は、2026年2月5日の記事で、エージェントが失敗するたびにその失敗が二度と起きないよう環境を直す取り組みを「ハーネスエンジニアリング」と呼びました。方法は2つです。間違ったコマンドを繰り返すといった単純な失敗にはAGENTS.mdへ1行足します。それで足りなければ、画面を撮影するスクリプトや、対象を絞ってテストを走らせるスクリプトのような道具を作り、その存在をAGENTS.mdで知らせます。同氏は、GhosttyのAGENTS.mdの各行がエージェントの悪い振る舞いから生まれ、ほぼすべてを解消できたと書いています。

Addy Osmani氏も、よいAGENTS.mdの各行は過去の具体的な失敗にさかのぼれるはずだと述べ、思いつきで書き足さないよう勧めています。書くのは、プロジェクトの概要、ビルドやテストのコマンド、固有の規約、触ってはいけないファイルです。一般常識やコードを読めば分かることは書かず、長い手順はAgent Skillsに切り出して必要な場面でだけ読ませます。Claude CodeではCLAUDE.mdが同じ役割を持ち、運用の例はClaude Codeチーム導入ガイドで紹介しています。

ルールは確率的にしか効かないため、守れたかどうかは機械に判定させます。フォーマッタ、リンター、型チェック、ビルド、テストを1つのコマンドにまとめ、人もエージェントも同じ門をくぐるようにします。AGENTS.mdに「このコマンドがすべて通ったら完了」と書いておけば、エージェントは失敗の出力を読んで自分で直し、再実行するループを回せます。LangChainが終了直前に検証を促したのも、OpenAIがリンターのメッセージに直し方を書いたのも、このループを速く回すための工夫です。

門を走らせる場所は3つあります。エージェント側のフック（Hooks）は編集や実行の瞬間に、Gitのフックはコミットやプッシュの前に、CIはプルリクエストの作成や更新のたびに、同じ検証を走らせます。内側ほど早く気づけ、外側ほど抜け道が少なくなります。CIでは、ブランチ保護で検証を必須のチェックに指定し、管理者などが迂回できる設定になっていないかも確かめます。GitHubのブランチ保護は、既定では管理者に適用されないためです。運用の確認項目はAIエージェントのガードレール運用チェックリストにまとめています。

ハーネスの寿命、小さなチームでの始め方、Claude Codeでの対応状況の3つの質問に答えます。

一部は不要になり、一部は残ります。Han Lee氏は2026年5月の記事で、システムプロンプト、道具のラッパー、計画と実行の分割、再試行の処理といったハーネスのコードの多くは次の世代のモデルに吸収されると指摘しました。同氏は、長く使われる製品を出しているチームがハーネスを90日で作り替える前提の部品として扱っていると観察し、その作り方を勧めています。一方、木下氏の資料は、テスト、権限と境界、プロジェクト固有の規約は次のモデルでも残ると整理しています。数か月に一度はルールをいったん削り、要るものだけ戻す棚卸しが欠かせません。

Hashimoto氏の方法からです。AGENTS.md（Claude CodeならCLAUDE.md）を短く作り、検証のコマンドを1つ決めて完了の条件に書き、失敗が出るたびに1行足してください。Uberのような費用の分解は、利用者が増えて請求額が気になり始めてからで間に合います。

AGENTS.mdは使えます。Claude Codeは2026年9月のv2.1.277から、CLAUDE.mdが無いプロジェクトではAGENTS.mdを読むようになりました。CLAUDE.mdがあればそちらを読み、2つを合わせて読むことはありません（Claude Codeの変更履歴）。

Agent Pluginsは、Agent SkillsとMCPの設定を1つのフォルダにまとめて配るための共通形式で、1.0が2026年8月6日に公開されました。公開時に対応したのはChatGPT、Codex、Cursor、GitHub Copilot、Kiro、VS Codeで、Claude Codeは含まれていません。コマンドやフックも共通形式の対象外なので、道具ごとに用意が要ります。

OpenAIとLangChainは検証のループを速くして成果を出し、Anthropicは柵をすり抜けた変更で品質を落とし、Uberは毎回送る文脈と探す手間を削って費用を抑えました。山東大学の研究は、ハーネスの改善を主張するなら、同じ設定の再実行によるぶれを上回る差が要ることを示しています。

自分のチームでは、境界を先に引き、失敗から1行ずつルールを足し、検証を1コマンドにまとめてエージェントにループを回させるところから始めてください。変更のたびに成績のぶれと費用を記録しておけば、効いた手と効かなかった手を見分けられます。

当社では、AIを活用した開発の内製化と、そのための体制づくりを支援しています。詳しくはAI導入支援をご覧ください。

参考資料（確認日：2026年10月28日）

• 木下雄一朗「ハーネス設計入門〜基礎知識の整理から実務へのステップアップ〜」（セミナー資料、2026年9月24日）
• Mitchell Hashimoto「My AI Adoption Journey」（2026年2月5日）
• OpenAI「Harness engineering」（2026年2月11日）
• LangChain「Improving Deep Agents with harness engineering」（2026年2月17日）
• Anthropic「Infrastructure noise in agentic coding evals」（2026年2月5日）
• Anthropic「An update on Claude Code quality reports」（2026年4月23日）
• Han Lee「Hidden Technical Debt of AI Systems: Agent Harness」（2026年5月8日）
• Uber「Running a Software Factory Efficiently at Uber Scale」（2026年8月27日）
• Vercel「Introducing Agent Plugins」（2026年8月6日）
• Liu, Han「What Does a Harness Buy? Tokens, Mostly」（2026年10月3日）
• Addy Osmani「Agent Harness Engineering」（2026年4月19日）
• Simon Willison「The lethal trifecta for AI agents」（2025年6月16日）