目次

ボトルネックはモデルではなく、ハーネスにある

2026年、ソフトウェア開発の現場で「Harness Engineering」という概念が急速に広まっている。

OpenAIは3人のエンジニアで100万行のコードを書き上げた。Stripeは毎週1,300以上のPRをAIエージェントがマージしている。Rampでは全PRの50%以上をAIが生成している。

これらの企業に共通するのは、モデルそのものではなく「モデルが動作する環境」を設計するという発想の転換だ。

Can Bolukの「Hashline Experiment」が、この洞察を最も劇的に証明した。ファイル読み取り時に各行へ2-3文字のコンテンツハッシュを付与するだけで、あるモデルのベンチマークスコアが6.7%から68.3%に跳ね上がった。16モデル×180タスク×3回の大規模ベンチマーク。モデルの重みは一切変更していない。コストはわずか約300ドル。

11:a3|function hello() {
22:f1|  return "world";
33:0e|}

“You’re blaming the pilot for the landing gear.”（着陸装置の問題でパイロットを非難している。）

LangChainも追試し、同一モデル（gpt-5.2-codex）に対するハーネス改善だけでTerminal Bench 2.0スコアが52.8%から66.5%に向上。リーダーボード上で約30位から約5位に躍進した。

本記事では、Harness Engineeringの概念の系譜、体系的な設計パターン、主要企業の実装事例、そして未解決の課題までを解説する。

概念の系譜：テストハーネスからエージェントハーネスへ

「ハーネス」という比喩の起源

「ハーネス」はもともと馬具（手綱、鞍、ハミ）を意味する。強力だが予測困難な力を生産的な方向に導く仕組みの比喩だ。

ソフトウェア分野では「テストハーネス」が既存概念として存在していた。テスト対象のソフトウェアを動作させるための仮の部品を集めた仕組みである。

AI領域では、Gaoらが2021年に「Language Model Evaluation Harness（lm-eval）」を公開し、異なるバックエンド（HuggingFace、vLLM、API）を統一的に評価するオーケストレーション層としてハーネスの概念を導入した。

そしてエージェント分野では、2024年のTheAgentCompany（Xuら）がOpenHandsフレームワークを「エージェントハーネス」として紹介し、2025年にはZhangらが知覚・記憶・推論の3モジュールを着脱可能なハーネスとして設計し、性能向上効果を実証した。

この系譜は、馬具 → テストハーネス → LM評価ハーネス → エージェントハーネスと発展してきたことを示している。

Mitchell Hashimotoの定義

「Harness Engineering」という用語を定義したのは、HashiCorp共同創業者のMitchell Hashimotoだ。2026年2月のブログ記事「My AI Adoption Journey」でこう述べた。

エージェントがミスを犯すたびに、そのミスを二度と起こさないようにする仕組みを設計する

Hashimotoは自身のプロジェクト「Ghostty」でAGENTS.mdを管理している。各行は過去にエージェントが犯した失敗を防ぐルール——「学習済みの教訓のリビングドキュメント」だ。

Prompt → Context → Harness の3階層

Harness Engineeringは関連概念と階層的な関係にある。

レイヤー	問い	設計対象
Prompt Engineering	何を聞くべきか？	指示テキスト
Context Engineering	何を見せるべきか？	モデルに渡す全トークン
Harness Engineering	環境全体をどう設計すべきか？	制約、フィードバックループ、運用システム

LangChainのVivek Trivediはこれを簡潔な等式にまとめた。

Agent = Model + Harness

— “If you’re not the model, you’re the harness.”

HumanLayerのKyleはコンテキストエンジニアリングとの関係を次のように整理する。ハーネスエンジニアリングはコンテキストエンジニアリングのサブセットであり、コンテキストエンジニアリング自体はプロンプトエンジニアリングと体系的なAIエージェント信頼性技術のスーパーセットである。

エージェントハーネスの3つの本質的特性

Generative Agentsの西見氏は、エージェントハーネスに共通する3つの特性を整理した。

1. LLM外部性: モデル本体とは区別され、モデル交換時に再利用可能
2. 能力拡張: 単一推論で不可能な機能（評価実行、ツール使用、記憶保持）を実現
3. 進化性: 固定的ではなく、モデル進化に応じて調整が必要

この3番目の特性——進化性——はAnthropicが端的に言い表している。

モデルが改善し続けるにつれて、関心のあるハーネス組み合わせの空間は縮小しない。代わりに移動する。

ハーネスの構成要素：6つの設定レバー

HumanLayerのKyleは、Viv Trivedyの4レバーモデルを拡張し、ハーネスの構成要素を6つの設定レバーとして体系化した。

レバー	役割	例
1. CLAUDE.md / AGENTS.md	コードベース固有の指示	60行以下の簡潔なルール
2. MCPサーバー	ツール経由の機能拡張	Toolshed（Stripe）、CLI代替
3. スキル	段階的な知識開示	SKILL.md + バンドルリソース
4. サブエージェント	コンテキスト制御	コンテキストファイアウォール
5. フック	決定論的な制御フロー	PreToolUse/PostToolUse
6. バックプレッシャー	検証メカニズム	型チェック、テスト、カバレッジ

これら6つのレバーは、エージェントの能力を拡張しつつ品質を保証する、ハーネスの操作可能なインターフェースである。次章で、これらのレバーがどのような設計パターンとして組み合わされるかを見ていく。

8つの設計パターン

OpenAI、Stripe、Ramp、Anthropic、LangChain、HumanLayerの事例から、効果的なHarness Engineeringに共通する8つのパターンが浮かび上がる。

パターン1：構造化されたコンテキストファイル

すべての成功事例で、バージョン管理された指示ファイルが使われている。

巨大な一枚岩のファイルは失敗する。 OpenAIは約100行のコンパクトなエントリポイントを「目次」として使い、Stripeはディレクトリスコープのルールファイルでエージェントの移動に応じてコンテキストを自動アタッチする。HumanLayerのCLAUDE.mdは60行未満だ。

ETH Zurichの研究が衝撃的な結果を示した。138のエージェントファイルを検証したところ、LLM生成のエージェントファイルはパフォーマンスを害し、20%以上のコスト増加を招いた。人間が作成したファイルでも約4%の改善にとどまった。コードベース概要やディレクトリリストは効果なし。重要なのは手動でキュレーションされた、簡潔で普遍的な指示だけだ。

新入社員に初日から500ページのマニュアルを渡さないのと同じで、プログレッシブ・ディスクロージャーの原則が鍵になる。エージェントは小さなエントリポイントから開始し、必要に応じて深いコンテキストを取得する。

パターン2：プロンプトではなく機械的な強制

エージェントに「良いコードを書け」と指示するのは信頼できない。悪いコードを却下するリンターを構築する方が確実だ。

Stripeのブループリントは、創造的なLLMステップと決定論的なゲートを交互に配置する。モデルが「忘れて」もリンター実行をスキップすることは構造的に不可能だ。

OpenAIのカスタムリンターは、エラーメッセージに修正指示を直接埋め込む。UIコンポーネントがデータベースに直接依存しようとした場合、リンターはPRを失敗させ、エージェントに正確な修正指示を提供する。このリンター自体もCodexが実装した。

コードの何が気に入らないかを言語化できるなら、次のステップはそれを書き留めることだ — Ryan Lopopolo

「テイスト」は口頭の文化ではなく、コードとして実装される。

LangChainのミドルウェアパターンも同じ思想だ。完了前チェックリストはエージェントの早期終了をインターセプトして検証を強制し、ループ検出は同一ファイルへのN回編集後にアプローチの再検討を促す。

パターン3：実環境を模したサンドボックス

各エージェントセッションに、人間のエンジニアが使うのと同じ環境を隔離して提供する。

• Ramp: PostgreSQL、Redis、Temporal、RabbitMQを含むフルスタック。30分ごとの差分スナップショットで数秒起動
• Stripe: プリウォームプールから10秒以内でスピンアップ。「cattle, not pets」哲学に基づく標準化環境

隔離により権限管理の複雑さが排除され、エージェントに全権限を安全に付与できる。確認プロンプトなしで自由に動ける。Rampではエージェント自身が子セッションをスポーンして作業を並列化することもある。

パターン4：段階的フィードバックループ

安価で高速なフィードバックを先に、高コストな検証は必要な時だけ。

Stripeの3段階システムが最も明快だ。

Tier	内容	所要時間
Tier 1	ローカルリンター（事前計算・キャッシュ）	1秒以下
Tier 2	300万以上のテストから関連テストを選択実行	数分
Tier 3	CI失敗をエージェントに返して自己修正（最大1回の追加試行）	可変

2回のCI試行後も通過しない場合は人間に返される。LLMは無限リトライしても収穫逓減を示すという知見に基づく。

Rampはブラウザスクリーンショットと本番モニタリングによるビジュアル検証を追加。OpenAIはLogQL、PromQL、DOMスナップショットを統合。Anthropicはスプリント契約でテスト基準を事前に合意する。

パターン5：エントロピー管理（ガベージコレクション）

AI生成コードは、エージェントがセッション間で組織的な文脈を持ち越さないため、人間が書くコードよりも速く技術的負債を蓄積する。

OpenAIはこれを「ガベージコレクション」と呼んだ。当初は毎週金曜日に時間の20%を「AIスロップ」の手動クリーンアップに費やしていたが、スケールしなかった。代わりに、バックグラウンドのCodexタスクが継続的に逸脱を検出し、品質グレードを更新し、リファクタリングPRを自動生成する仕組みを構築した。

技術的負債は高利子のローンだ。複利で膨れ上がらせるより、小さなインクリメントで継続的に返済する方がほぼ常に良い。

パターン6：人間のレビューを信頼境界として維持

すべてのシステムが、コード生成は完全自律でありながら、マージ前には人間の承認を維持している。

• Stripeのminions：全コンテキストを含む自動記述PRを生成
• Rampのマルチプレイヤーセッション：リアルタイムでの観察が可能
• Anthropicのスプリント契約：テスト可能な基準を事前に合意

信頼モデルは「自律的な操作＋定義された段階での人間チェックポイント」だ。

パターン7：Context Rot対策

LangChainが体系化した問題だ。コンテキストウィンドウが埋まるにつれて、モデルの推論とタスク完了の能力が低下する現象——Context Rot。

Chroma社の研究では、18モデルを対象に、パフォーマンスがコンテキスト長の増加とともに低下し、ディストラクターの効果がコンテキストウィンドウが長くなるほど複合的に増大することが実証された。

HumanLayerの端的な指摘が刺さる。

より大きなコンテキストウィンドウは干し草の中の針を見つけやすくしない。単に干し草を増やすだけだ。

対策は3つの戦略で構成される。

1. コンパクション: コンテキストウィンドウの要約圧縮
2. ツール出力のオフロード: 大きな出力の先頭・末尾のみ保持し、全体はファイルシステムに保存。成功はサイレント、失敗は詳細出力
3. サブエージェントによるコンテキストファイアウォール: 離散的タスクをカプセル化し、凝縮された結果のみを親に返す

HumanLayerの初期の失敗が教訓的だ。全テストスイート（5分以上）をエージェントに実行させたところ、4,000行以上の合格テストがコンテキストを満杯にし、エージェントがタスクの焦点を失った。解決策は出力を吸収し、エラーのみを表面化すること。

パターン8：ジェネレータ-エバリュエータの分離

Anthropicが実証したパターン。エージェントに自分の生成物を評価させると、品質が明らかに平凡でも自信を持って褒める傾向がある——自己評価バイアスだ。

解決策はGANにインスパイアされた構造。生成するエージェントと評価するエージェントを分離する。独立したエバリュエータの調整は、ジェネレータに自己批判させるより「はるかに扱いやすい」。

評価基準の言語選択自体がジェネレータの出力を予期しない方法で導くという発見も重要だ。「最高のデザインは美術館の品質だ」のようなフレーズが、特定の視覚的収束を促した。ハーネス設計者は評価基準の言語で意図せず出力空間を制約してしまうリスクがある。

OpenAIの「エージェント間コードレビュー」も同じ思想だ。細かい指摘はエージェント間で行われ、人間は判断が必要なケースとエッジケースのみを扱う。

事例1：OpenAI — 3人で100万行、人間のコードはゼロ

OpenAIは2026年2月に5ヶ月間の社内実験を公開した。

• 3人のエンジニア（後に7人に拡大）で約100万行のプロダクションコードを構築
• 約1,500本のPRをマージ。人間が手で書いたソースコードはゼロ
• エンジニア1人あたり1日平均3.5本のPRを処理

初期の進捗は予想より遅かった。それはCodexの能力不足ではなく、環境が不十分に定義されていたからだ。

3つの柱

① Context Engineering: バージョン管理されたdocs/ディレクトリを「唯一の情報源」として整備。AGENTS.mdは約100行の「目次」。

エージェントの視点からは、コンテキスト内でアクセスできないものは存在しないのと同じ

② アーキテクチャ制約: Types → Config → Repo → Service → Runtime → UIの厳格なレイヤードアーキテクチャ。カスタムリンターと構造テスト（これ自体もCodexが生成）で機械的に遵守を強制。Zodなどの「Parse, Don’t Validate」パターンで状態空間を縮小。「退屈なテクノロジー」（React、Express、PostgreSQL等）を優先——トレーニングデータに豊富な確立技術の方がエージェントにとって扱いやすい。

これは通常、エンジニアが何百人にも増えてから初めて整備するアーキテクチャだ。コーディングエージェントを使う場合、最初から必要な前提条件になる

③ エントロピー管理: バックグラウンドのCodexタスクが逸脱を検出し、品質グレードを更新し、リファクタリングPRを自動生成。エージェントにChrome DevTools Protocol、LogQL、PromQLへのアクセスを付与し、自己デバッグを可能にした。

ブルックスの法則を覆す

チームが3人から7人に拡大するにつれて、スループットは増加した。各エンジニアが異なる専門性をハーネスにエンコードすると、チーム全員のエージェントがその知見を共有できる。フロントエンド専門家がReactのベストプラクティスをカスタムリンターに実装すれば、バックエンドエンジニアのエージェントも自動的にそのルールに従う。

モデルとハーネスの共進化

Gabriel Chua（OpenAI）は、Codexモデルがハーネスの存在下でトレーニングされていることを明らかにした。ツール使用、実行ループ、反復検証は後付けの機能ではなく、モデルが動作を学習する方法の一部だ。

ただしLangChainは、この共進化が過剰適合のリスクを生むことも指摘する。Codex-5.3ではapply_patchのツールロジック変更がパフォーマンス低下を招いた。HumanLayerのデータが示すように、Opus 4.6はClaude Code上では33位だが、異なるハーネスでは5位にランクされる。タスクに最適なハーネスが、モデルがポスト訓練されたハーネスであるとは限らない。

事例2：Stripe — Minionsが毎週1,300以上のPRをマージ

Stripeの「Minions」は、Block社のオープンソース「Goose」をフォークして構築された。

• 毎週1,300以上のPRがマージされる（すべて人間がレビュー）
• 年間1兆ドル以上の決済処理を支えるコードに適用
• Slackメッセージで要件を投げ、完全無人でPR作成まで完了

Blueprint：決定論とエージェントのハイブリッド

最大の技術的革新だ。決定論的ノード（リンティング、git操作）とエージェント型ノード（コード実装、CI修正）を交互に配置する状態機械。

ノード種別	形状	例	特徴
エージェント型	雲形	タスク実装、CI修正	広い裁量権、LLM呼び出しあり
決定論的	矩形	リンター実行、git push	LLM呼び出し一切なし

モデルが「忘れて」もリンター実行をスキップすることは構造的に不可能。個々のチームが特化したBlueprintを作成でき、ランタイム保証を維持しつつ柔軟性を両立する。

Toolshed：約500ツールの選択的提供

約500の社内ツールを一元管理するMCPサーバー。ただしエージェントにはタスクごとに関連ツールのみを選択的に提供する。ツール過負荷を防止するキュレーションだ。

10年の投資が配当を生んだ

What’s good for humans is good for agents.

2,000万行以上のRubyモノレポ、Bazelビルドシステム、Sorbet（型チェッカー、1,500万行以上カバー）、300万以上のテストスイート。Stripeの10年以上にわたる開発基盤への投資が、そのままMinionsの信頼性基盤になった。

事例3：Ramp — Inspectが開発者プラットフォームを再定義

フィンテック企業Rampの「Inspect」は、コーディングエージェントを超えたフルスタック開発者プラットフォームだ。

• 全マージ済みPRの50%以上をInspectが生成
• Inspect自体の80%以上がInspectによって書かれた
• 採用は完全にオーガニック（トップダウンの強制なし）

サンドボックスに本番環境を丸ごと再現

各InspectセッションはModal上のサンドボックスVMで実行。PostgreSQL、Redis、Temporal、RabbitMQ、Vite——すべてが単一サンドボックスに同居し、ネットワークホップが排除される。30分ごとのスナップショットで数秒起動。

検証ギャップの解消

Inspectの最大の差別化要因だ。テスト実行、SentryやDatadogのモニタリング確認、データベースクエリ、LaunchDarklyフィーチャーフラグ確認、変更前後のスクリーンショット撮影、VNCスタック＋Chromiumでの実ブラウザ操作まで行う。

インターフェースもSlackボット、Webインターフェース（ホストされたVS Code）、Chrome拡張機能（非エンジニアがReactコンポーネントを視覚的に選択して変更を指示）、マルチプレイヤーセッション（同僚がリアルタイムで協力）と多岐にわたる。

自分の組織にとって最高・最効率であることを保証する唯一の方法は、自分で作ることだ。 — Zach Bruggeman, Staff Engineer

事例4：Anthropic — GANに着想を得たジェネレータ-エバリュエータ構造

Anthropicは、長時間実行タスクでエージェントが失敗する2つの根本的な問題を特定した。

コンテキスト不安: モデルはコンテキストウィンドウの上限に近づくと作業を途中で終了する。コンパクション（要約圧縮）だけでは不十分で、コンテキストリセット（ウィンドウを完全にクリアして新しいエージェントを開始）が重要な対策になった。

自己評価バイアス: 品質が明らかに平凡でも自信を持って褒める。特にデザインのような主観的タスクで顕著。

オランダの美術館サイト

フロントエンドデザイン実験の最も印象的な事例だ。4つの評価基準（デザイン品質、オリジナリティ、クラフト、機能性）で、Claudeがもともと得意なクラフトと機能性よりもデザイン品質とオリジナリティに重み付けした。

初期はありふれたダークテーマのランディングページ。10回の反復後には、CSSパースペクティブで描画されたチェッカーフロアの3Dルーム、壁に自由配置されたアートワーク、ドアウェイベースのナビゲーションを備えた空間体験へと完全に再構想された。

コストと品質のトレードオフ

ハーネス	期間	コスト	結果
ソロエージェント	20分	$9	ゲームプレイが機能しない
フルハーネス（初期）	6時間	$200	機能するゲーム
フルハーネス（Opus 4.6最適化後）	3時間50分	$124.70	完成度の高いDAW

モデルが進化したらハーネスを単純化する

Opus 4.6のリリース時にスプリント分解構造を完全に削除した。Opus 4.6はより慎重に計画を立て、エージェンティックタスクをより長く維持できるため、以前必要だった構造的補助が不要になった。スプリントなしでビルダーが2時間以上一貫して実行できることが実証された。

ハーネスの各コンポーネントは「モデルが単体ではできないことへの仮説」だ。モデルが改善されれば、その仮説をストレステストし、不要になった部分を剥ぎ取り、新たに可能になった機能を追加する。

先行企業が築いた基盤

「Harness Engineering」はAIコーディングエージェントの文脈で生まれた用語だが、その基盤となる開発者生産性インフラは大手テック企業が長年にわたって構築してきたものだ。

企業	規模	特筆すべき投資
Google	2,000人以上のEngProdグループ	Bazel、ML強化コード補完（反復時間6%短縮）
Meta	DevInfraチーム	Sapling、Infer、Jest、Diff Authoring Timeメトリクス
Netflix	150人のProductivity Engineering	「Paved Roads」哲学、62分→5分のテスト短縮
Uber	200人のDeveloper Platform	月間10万回以上のデプロイ、DevPod（NPS -50→+8）

Stripeの事例が最も端的にこの関係を示している。10年以上にわたるDevbox、CI、Sorbetへの投資が、ほぼ偶然にMinionsの基盤になった。人間のために構築したものが、そのままエージェントにとっても最適だった。

エンジニアの役割はどう変わるか

OpenAIのCharlie Guoは、エンジニアの仕事が2つの明確に異なる半分に分裂していると指摘する。

環境構築者: ボトルネックは「エージェントの能力」ではなく「環境設計」にある。エージェントが詰まったら、それは環境設計の問題と捉え直す。

AIマネージャー: 「メーカーのスケジュール」から「マネージャーのスケジュール」への転換。計画立案・アーキテクチャ決定・品質ゲートキーピングが主要な仕事になる。

従来	ハーネスエンジニアリング
コードを書く（主な仕事）	コードは書かない
アーキテクチャ設計（仕事の一部）	アーキテクチャ設計（主な仕事）
ドキュメント（後回し）	ドキュメント（重要なインフラ）
PRレビュー（コード査読）	エージェント出力＋ハーネス有効性のレビュー
デバッグ（コードを読む）	エージェント行動パターンの分析

Charlie Guoの観察も示唆的だ。「アルゴリズムのパズルを解くことが好きなエンジニアはエージェントネイティブなワークフローに移行するのに苦労するが、製品を出荷することが好きなエンジニアは素早く適応する」。

未解決の課題

ブラウンフィールド問題

現在の成功事例はすべて**新規開発（グリーンフィールド）**だ。アーキテクチャ制約のない10年物のコードベースへの適用は未解決。Böckelerの比喩が秀逸だ——「一度も静的解析ツールを使ったことのないコードベースに対してツールを実行し、アラートの洪水に溺れる」。

検証ギャップ

リンティングはコードの構造的な正しさを保証するが、振る舞いの正しさ（ビジネスロジック）を保証するテストの議論が不足している。Anthropicの実験でも、エージェントが「合法的な問題を特定しながらも、大したことではないと自分自身を説得して承認してしまう」ケースが報告された。

セキュリティリスク

HumanLayerが警告する。スキルレジストリから数百の悪意あるスキルが発見されている。MCPサーバーはプロンプトインジェクションの危険なベクターになりうる。STDIOサーバーやnpx/uvxでクライアントサイド実行するサーバーも、ホストマシン上で任意コードを実行できる。

ベンダーのインセンティブ不整合

Can Bolukが指摘した構造的問題だ。AnthropicはGrok向けにハーネスを最適化しない。xAIはGemini向けに最適化しない。各ベンダーは自社モデルを競争上の堀として守っている。

オープンソースのハーネスはこの問題に対して構造的に有利だ。

An open-source harness tunes for all of them, because contributors use different models and fix the failures they personally encounter.

ハーネス問題は解決される。問いは、それが一企業によって非公開で一つのモデルのために解決されるのか、コミュニティによってオープンにすべてのモデルのために解決されるのか、だ。

始めるために

HumanLayerの実践から得られた教訓は明快だ。

1. シンプルに始める。 実際の失敗が起きてから設定を追加する。「念のため」数十のスキルやMCPサーバーをインストールするのは逆効果
2. 1ショット成功率より反復速度を最適化する。 完璧な一発を狙うより、高速なフィードバックループで素早くイテレーションする
3. テスト出力はエラーのみ表示する。 成功はサイレント、失敗は詳細出力
4. 出発点はAIエージェントではなく、既存の開発インフラ。 テストカバレッジ、リンター、ドキュメントの品質が基盤のすべてを決める

出荷にバイアスをかける。失敗に対してリアクティブに対処し、再発を防ぐソリューションを構築する。プリエンプティブな問題探しは避ける。 — Kyle, HumanLayer

リンク

• OpenAI: Harness engineering
• Stripe: Minions — Part 2
• Modal: How Ramp built Inspect
• Anthropic: Harness design for long-running apps
• Martin Fowler: Harness Engineering
• LangChain: The Anatomy of an Agent Harness
• LangChain: Improving Deep Agents
• Artificial Ignorance: The Emerging Harness Engineering Playbook
• HumanLayer: Skill Issue
• Can.ac: The Harness Problem
• Generative Agents: エージェントハーネスの起源