**AIエージェントのハーネス設計（Harness Engineering）**

2026年現在、AIエージェントの実用化で最も重要なレイヤーになっています。プロンプトエンジニアリング → コンテキストエンジニアリングの次に来るのが**ハーネスエンジニアリング**です。[[1]](https://x.com/tetumemo/status/2037876018745385083)

### ハーネスとは何か

**馬具（手綱・鞍）のメタファー**です。馬（＝強力だが制御が必要なLLM）の力を最大限に引き出しつつ、暴走させず、目的の方向に確実に進めるための「仕組み全体」を指します。

よく使われる比喩：
- **モデルはCPU、ハーネスはOS**
- **モデルはエンジン、ハーネスは車体・制御システム**
- **Scaffolding（足場）** — モデルが到達できない高みへ到達させるための仮設構造（後で一部は取り外せる）

要するに「**Model is not the agent. The harness is.**」という考え方です。同じモデルを使っても、ハーネスの設計次第で性能が劇的に変わります（LangChainチームはハーネス改善だけでTerminalBenchでTop30→Top5に跳ね上がった事例があります）。[[2]](https://x.com/akshay_pachaar/status/2042586319390674994)

### ハーネスのコアアーキテクチャ（2026年現在の標準的理解）

優れたハーネスは以下の要素で構成されます：

**1. Central Harness（中核）**
- 実行ループ（ReAct、Plan-and-Execute、Graph-basedなど）
- 状態管理（State Machine）
- Orchestrationロジック

**2. Orbiting Components（周回する3つの主要次元）**
- **Memory（記憶）**：Working Context / Semantic Knowledge / Episodic Memory / Personalized Memory。コンテキストウィンドウに全部詰め込まない賢い圧縮・引き継ぎが鍵。
- **Skills（技能）**：Operational procedures、decision heuristics、normative constraints（行動指針）。「この設計原則を守れ」というルール群。
- **Protocols（プロトコル）**：Agent↔User、Agent↔Agent、Agent↔Toolsの通信契約。明確な入出力スキーマとエラーハンドリング。

**3. Mediators（仲介層）** — これが最も重要
- Sandboxing（コード実行は必ず隔離）
- Observability & Tracing（全trajectoryをログ）
- Context Compression
- Evaluation System（特に重要）
- Approval / Human-in-the-Loop
- Sub-agent Orchestration

### 設計の重要原則（Anthropic・OpenAIの実践から）

1. **自己評価バイアスを絶対に避ける**
- 1つのエージェントに「作る＋評価させる」と過大評価する。
- **必ず役割分離**（Creator Agent vs Reviewer/Evaluator Agent）。[[3]](https://x.com/masahirochaen/status/2037175753620807701)

2. **主観をルーブリック化する**
- 「良いデザインか？」ではなく、「我々のDesign PrinciplesのXX項目を満たしているか？」というチェックリスト化。
- これでデザイン品質すら自動評価可能に。

3. **Environment Design > Model Capability**
- 進捗が遅い原因の多くはモデルではなく、ハーネス（環境）の未整備。
- 「地図を渡せ」：必要なコンテキストを段階的に、適切なタイミングで与える。

4. **Human steer, Agent execute**
- 人間はゴール設定・制約条件・品質基準・介入タイミングを担当。
- 失敗時は「何が足りなかったか」を明確にフィードバック。

5. **Scaffolding is temporary**
- モデルが賢くなるにつれ、ハーネスを簡素化できる部分は簡素化する。
- ただし「モデルはこのハーネスで学習されている」場合もあるので、慎重に（performance regressionに注意）。

### 具体的な設計パターン

**厚いハーネス（Thick Harness）推奨シーン**
- 複雑な長期タスク（大規模コーディング、事業プロセス）
- 確実性が最優先
- LangGraphスタイル：明示的なグラフで全状態遷移をコードで定義

**薄いハーネス（Thin Harness）推奨シーン**
- モデルが非常に賢い場合（Claude 4 / GPT-5クラス）
- Anthropicが好む「dumb loop」＋強力なモデル依存

**ハイブリッド（現実的）**
- 重要な意思決定ポイントはグラフで明示的に制御
- ルーチンタスクはモデルに任せる
- 常に「このロジックは将来モデルに内包可能か？」を意識

**コーディングエージェント特化の場合**
- Codeを単なる出力ではなく「状態の基盤（operational substrate）」として扱う
- ファイル構造、Design.md（憲法）、JSON Contracts、自動検証ハーネスを整備
- Peer code reviewを別エージェントにさせる

### 実装時に最初に作るべきもの（優先順位）

1. 完全なObservability（LangSmith相当のトレース）
2. 堅牢なEvaluator（別エージェント＋ルーブリック）
3. 明確なDesign Principles / Constitution（Design.md）
4. Sandbox + Tool使用制限 + コストガードレール
5. 状態の永続化とコンテキスト圧縮戦略

### 今後の方向性

- ハーネス同士の相互運用プロトコル（A2Aなど）の標準化
- 「Agent OS」的なレイヤーへの収束（重複するmemory/tool/approvalレイヤーを抽象化）
- ハーネス自体をAIに設計させるメタハーネス

---

**参考になる主な情報源（2026年時点）**
- Anthropic Engineering Blog: “Harness design for long-running application development”
- OpenAI内部事例（5ヶ月・約100万行・人間0行コードのプロダクト構築）
- Meta/StanfordのAgent Harnessに関する論文
- LangGraph、CrewAI Flows、OpenAI Agents SDKの比較

この領域はまだ急速に進化中です。特に**「作る役と評価する役の明確な分離」**と**「ルーブリックによる品質のコード化」**を最初に固めると、ほとんどのプロジェクトで大きな改善が見られます。

具体的に「コーディングエージェント向け」「RAGエージェント向け」「社内業務自動化向け」など、用途を教えていただければ、より詳細なアーキテクチャ図やコンポーネント設計を深掘りできます。