🐧 要するにどういう話か
コンテキストエンジニアリングはLLMに何を見せるべきか（何を見せないべきか）が問題だったが、ハーネスエンジニアリングは、コンテキストだけでなく、ツール、スキル、制約、フィードバックループも含めたLLMの動作環境をきちんと設計すべきである、という話である。
1. はじめに
当初、AIエージェントにおける問いは「そもそも動作するのか」であった。しかし現在は、「信頼性、一貫性、スケーラビリティを持って動作できるか」という問いへと移行している。この転換により、新たなエンジニアリング領域が誕生した。
モデルが汎用品となり、エージェントがデモ段階からプロダクション環境へ移行したことで、成否を分けるのはモデルそのものではなく、それを包む「システム」となった。これがハーネスエンジニアリング（Harness Engineering）が注目される理由である。
2. ハーネスの定義
2.1 用語の由来
ここでの「ハーネス（harness）」は馬具（手綱、鞍など）に由来する。強大な動力を持つ「馬」を、ハーネスによって特定の方向へ制御する構造を指す。
AIシステムにおいて「馬」に相当するのは大規模言語モデル（LLM）である。GPTやClaude、Gemini、Llamaなどは極めて高性能だが、単体では制御が困難であり、ハルシネーションの発生、長期タスクの喪失、不適切なツール呼び出し、コンパイルは通るが動作しないコードの生成といった問題が起こる。ハーネスエンジニアリングは、モデルの知能を代替することなく、これらを適切に制御し、特定の方向へ導く役割を担う。
2.2 広義の定義
定義式は Agent = Model + Harness である。ハーネスとは、モデル以外のすべてのコード、設定、および実行ロジックを指す。
モデル単体はエージェントではない。ハーネスによって状態管理、ツール実行、フィードバックループ、強制的な制約が付与されて初めて、モデルは「エージェント」として機能する。
ハーネスの構成要素は以下の通りである：
- システムプロンプト
- ツール、スキル、MCP（Model Context Protocol）およびその定義
- 統合インフラ（ファイルシステム、サンドボックス、ブラウザ等）
- オーケストレーションロジック（サブエージェント生成、ハンドオフ（仕事の引き渡し）、モデルルーティング）
- 決定論的な実行を担保するフックおよびミドルウェア（コンパクション、継続処理、リントチェック）
2.3 狭義の定義
コーディングエージェントなどの高度なツールを利用する場合、システムプロンプトや検索メカニズム、オーケストレーションの一部は既に内包されている。ユーザーは自身のユースケースに合わせて、その外側に「外部ハーネス」（自作MCPサーバーによる内部ツール接続や、保存フックによる自動チェックなど）を構築することになる。これにより、構造は [モデル] → [ビルダーハーネス] → [ユーザーハーネス] の3層構造となる。
適切に設計された外部ハーネスは、以下の2点を実現する。
- エージェントが初回試行で正解に到達する確率の向上
- 人間に通知される前に問題を自己修正するフィードバックループの提供
結果として、レビュー工数の削減とトークン消費の抑制、およびシステム品質の向上が可能となる。
3. ハーネスエンジニアリングの本質
3.1 定義
ハーネスエンジニアリングとは、AIエージェントの信頼性を大規模に担保するための「環境・制約・フィードバックループ・インフラ」を設計する実践である。
ハーネスエンジニアの責務は、モデルの構築やファインチューニングではなく、モデルが受け取るコンテキスト、利用可能なツール、ガードレール、検証システム、リカバリメカニズムなど、モデルの外周すべてを構築することにある。
ソフトウェアエンジニアがアプリケーションを、MLエンジニアがモデルを構築するならば、ハーネスエンジニアは「モデルと現実世界の信頼性を結ぶレイヤー」を構築する。
3.2 背景
本用語はLangChainのViv氏によって提唱された。OpenAIが、人間が書いたコードを1行も含まない100万行規模の内部プロダクトを発表したことで注目を集めた。これは、エンジニアが直接コードを書くのではなく、「AIエージェントが信頼性高くコードを書くためのシステム（ハーネス）」を設計した結果である。
3.3 コンピュータサイエンスによる比喩
- モデル ≈ CPU
- コンテキストウィンドウ ≈ RAM
- ハーネス ≈ OS
- エージェント ≈ アプリケーション
OSなしにCPU上でソフトウェアを直接実行しないのと同様に、コンテキスト管理や失敗処理を行うハーネスなしにAIエージェントをデプロイすることはない。
3.4 関連領域との関係
- プロンプトエンジニアリング: LLMへの入力最適化。コンテキストエンジニアリングの一部。
- コンテキストエンジニアリング: 情報フローの管理。ハーネスエンジニアリングの中心的柱であり、プロンプトエンジニアリングの上位概念。
- MLエンジニアリング: モデルの学習・調整・デプロイ。モデル自体の構築を担う別領域。
- エージェントエンジニアリング: ロジック、ツール、ワークフローの構築。ハーネスエンジニアリングを補完する関係。
- DevOps / プラットフォームエンジニアリング: インフラ、CI/CDを管轄。AI特有の課題を扱う点でハーネスエンジニアリングと重複する。
要約すると、プロンプトエンジニアリングは「単一の対話」を、エージェントエンジニアリングは「ロジック」を、ハーネスエンジニアリングは「信頼させるシステム全体」を最適化する。
4. ハーネスエンジニアリングの基礎
4.1 3つの柱
- コンテキストエンジニアリング: 情報へのアクセスタイミング、構造、内容を管理する。
- 手法：コンテキスト圧縮、動的注入、外部知識保持、優先度スコアリング。
- アーキテクチャ制約: 誤操作を構造的に防止する。
- 手法：ツールアクセス制御、リント、型チェック、CI/CDパイプラインによる強制、スコープ境界。
- 制約は能力を制限するものではなく、ミスを捕捉することで自律性を高めるためのものである。
- エントロピー管理: 蓄積する不整合を排除する。
- 手法：定期監査、自動クリーンアップ、回帰検出、ドリフト監視。
- エージェント主導の開発はコード生成速度が速いため、エントロピーが加速しやすい。
4.2 OpenAIからの知見
- エンジニアの役割: コード記述から、環境設計、意図の明確化、フィードバックループの構築へと移行する。
- 地図の提供: 詳細すぎるマニュアルはモデルを混乱させる。詳細なガイダンスではなく、外部リソースへの「地図」を提供すべきである。
AGENTS.md の活用: 百科事典的に記述せず、外部ソースへのインデックス（目次）として機能させる。- 段階的な開示: エージェントに対して一度にすべてを教えず、安定したエントリーポイントから段階的に情報を開示する。
- 認識可能性の最適化: リポジトリ構造自体からビジネスドメインを推論できるよう設計する。
- 不変条件の強制: 実装方法を指示するのではなく、境界でのデータ形状などの不変条件（Invariant）を強制する。
- 黄金律によるガベージコレクション: 機械的なルールを組み込み、コードベースのエントロピーを継続的に返済する。
4.3 LangChainからの知見
- コンテキスト劣化: ウィンドウが飽和すると推論能力が低下する。戦略的なコンテキスト管理が不可欠である。
- 配信メカニズムとしてのハーネス: コンパクションやツールコールのオフロードにより、最適なコンテキストを配信する。
- Ralph Loop: フックを用いてモデルの終了試行を遮断し、クリーンな状態にプロンプトを再注入して目標まで完遂させるパターン。
4.4 Anthropicからの知見
- 役割の分離: 環境をセットアップする「初期化エージェント」と、実作業を行いアーティファクトを残す「コーディングエージェント」に分ける。
- リセット vs コンパクション: 状態を完全にリセットするか、その場で要約して維持するかを選択する。
- 生成器と評価器の分離: GAN（敵対的生成ネットワーク）の構造を応用し、作業担当と判定担当を分けることで、自己評価の楽観視を回避する（プランナー/生成器/評価器の3層構成）。
- ハーネスの簡素化: モデルの性能向上に伴い、不要になったコンポーネントは積極的に削除する。
4.5 Thoughtworksからの知見
- フィードフォワードとフィードバック: 実行前のガイド（フィードフォワード）で成功率を高め、実行後のセンサー（フィードバック）で自己修正を促す。
- 計算的制御 vs 推論的制御:
- 計算的: テスト、リント等。決定論的で高速（CPU実行）。
- 推論的: AIレビュー、LLM-as-a-Judge等。低速・高コストだが高度な判断が可能。
- ステアリングループ: 再発防止のため、フィードフォワードおよびフィードバック制御を反復的に改善する。
- ハーネス適性（Harnessability）: 強い型定義、明確なモジュール境界を持つコードベースほど、エージェントによる制御が容易になる。
4.6 HumanLayerからの知見
- 設定の最適化: 課題の正体はモデルの能力不足ではなく、多くの場合「設定の問題」である。
- 決定論的な注入:
CLAUDE.md 等はシステムプロンプトに決定論的に注入すべきである。LLMに生成させたエージェント設定ファイルは、多くの場合パフォーマンスを低下させる。
- MCPサーバーの管理: ツール過多によるコンテキスト圧迫と、プロンプトインジェクションのリスクを管理する必要がある。
- スキルの段階的開示: 再利用可能なツールを「スキル」として定義し、必要に応じて開示することでコンテキストを効率化する。
- コンテキストファイアウォール: サブエージェントを用いて親スレッドへのノイズ混入を防ぎ、一貫性を維持する。
- バックプレッシャー: エージェントが自身の作業を検証できる能力（およびその効率的な実装）が、成功率と強く相関する。
5. 結論
ハーネスエンジニアリングは、需要に対して供給が不足している新興領域である。モデルの性能が向上しても、最適なハーネスの組み合わせを追求する空間が縮小することはない。AIエンジニアの本質的な仕事は、不要な要素を削ぎ落とし、新たなコンポーネントを組み合わせることで、システムの能力を最大化し続けることにある。
📚 参考文献
|