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

2026年現在、「AIエージェントの性能の半分以上はモデルではなくハーネス（実行外殻）で決まる」という認識が広く共有されています。モデルを頻繁に変えるのではなく、**ハーネスを systematically に設計・進化させる**ことが最も効果的なアプローチです。

### 1. Agent Harnessとは何か

ハーネスとは、** stateless な LLM を状態を持ち、信頼性が高く、安全で、複雑なタスクを実行できるエージェントに変換するランタイム層**です。

単なる「ツール呼び出しラッパー」ではなく、以下の役割を持ちます：

- 記憶のライフサイクル管理
- スキル（手順・ヒューリスティック）の注入
- プロトコル（対話契約）の強制
- 安全・観測可能性・評価の仲介

人気のメンタルモデル（Akshay Pachaar / Daily Dose of DS 由来）では、ハーネスの中心に**3つの軌道**があります：

- **Memory**：作業記憶、意味的知識、 episodic memory、個人化記憶
- **Skills**：運用手順、意思決定ヒューリスティック、規範的制約
- **Protocols**：Agent-User、Agent-Agent、Agent-Tool の契約（失敗モードがそれぞれ異なる）

これらを繋ぐ**Mediators**として、Sandbox、Observability、Evaluation、Approval Loop、Orchestration、Compression が存在します。新しい機能を追加するときに「どこに置くか」をこのフレームで考えるのが極めて有効です。[[1]](https://x.com/akshay_pachaar/status/2045510648474530263)

### 2. 推奨アーキテクチャ（2026年時点）

```mermaid
graph TD
A[Experiment / Task Manager] --> B[Harness Core]
B --> C[Guardrail & Safety Layer]
B --> D[Router / Planner]
B --> E[Specialist Agents / Sub-agents]
B --> F[Reviewer / Verifier]

C --> G[Memory System\n(Short-term + Vector + Graph + Episodic)]
D --> H[Skills Registry\n(Reusable Playbooks + Heuristics)]
E --> I[Tool & Action Protocol\n(Standardized Schema)]
F --> J[Evaluation Engine\n(LLM-as-Judge + Rule + Human)]

B --> K[Mediators]
K --> L[Sandbox\n(E2B / Firecracker / Daytona)]
K --> M[Observability & Tracing\n(OpenTelemetry + LangSmith-like)]
K --> N[Approval & Rollback Gate]
K --> O[Cost / Latency / Safety Monitor]

J --> P[Dashboard & Experiment Tracker]
```

**主要レイヤーの設計ポイント**：

1. **Guardrail & Safety Layer**（最外殻）
- 入力ガード（PII、危険指示）
- アクション前承認（人間 or 別のLLM）
- 能力スコープ（このエージェントは何を触れるかACL化）
- 異常検知（行動パターンの逸脱）

2. **State Management（全ノードで共有）**
- 単一の状態オブジェクト（question, route, draft, final_answer, trace, blocked など）
- 短期記憶（会話コンテキスト）
- 長期記憶（Vector DB + Graph DB）
- Episodic Memory（過去の成功/失敗トレース）

3. **Skills & Protocols**
- Skills は「コードとして」管理（Python関数 or LangGraphノード）
- Protocols は厳格なJSON Schema + バージョン管理
- 「シンプルなルールはLLMに任せずPythonで書く」（Guardrail + Routerは軽量Python推奨）

4. **Sandbox & Execution**
- Web Agent → Playwright + DOM + Screenshot + Accessibility Tree
- Code Agent → E2B / Daytona / 自前Firecracker microVM
- すべての外部作用はSandbox経由でログ必須

5. **Evaluation & Evolution**
- Rule-based + LLM-as-Judge（Chain-of-Verification推奨）
- Trajectory評価（結果だけでなく過程も）
- HarnessX風の**自動進化**：失敗トレースを分析 → どのコンポーネントが悪いかを特定 → Skills/Protocols/Memoryを自動提案（AEGISのようなメタエージェント）

### 3. 実装時のベストプラクティス

- **シンプルから始める**：最初は「Guardrail → Router → Specialist → Reviewer」のグラフで十分（post:2の例が参考になる）。
- **Deterministic部分とNon-deterministic部分を明確に分離**：前者はPython、後者はLLM。
- **Tracingを徹底**：すべての思考・行動・観測・評価を構造化ログとして残す。これがハーネス進化の燃料になる。
- **モデル非依存設計**：ハーネスが良いと、安価なモデルでも大幅に性能が上がる（88.5%相対改善の論文例あり）。[[2]](https://x.com/omarsar0/status/2058208914148389083)
- **生産運用考慮**：
- コスト追跡（トークン + 実行時間）
- ロールバック機構
- 人間-in-the-loopのシームレスな挿入
- 実験管理（どのSkillバージョンがどのタスクで何%改善したか）

### 4. おすすめ学習リソース（2026年9月時点）

- **日本語**：Qiita「Agent Harness：LLMとAIエージェントの間を埋める決定的なレイヤー」
- **英語（強く推奨）**：
- Akshay Pachaar / Daily Dose of DS の "Anatomy of Agent Harness"
- HarnessX論文（小米系、AEGISによる自動ハーネス進化）
- HarnessDev（LLM自身がハーネスをゼロから作って進化させるベンチマーク）
- GitHub：ECC, DeepSeek Harness, Learn Claude Code, OpenHands, context-mode

特に「**Learn Claude Code**」や「**ECC**」のような最小構成から本番志向のオープンソースハーネスを実際に動かして読むのが最速です。[[3]](https://x.com/DivyanshT91162/status/2099225910419579301)

### 設計の指針（最終アドバイス）

- 「モデルを強くする」ではなく「**ハーネスを賢くする**」ことを第一目標に。
- 新しい機能を追加するときは必ず「Memory / Skills / Protocols / Mediatorsのどこに置くべきか」を自問する。
- ハーネス自体をバージョン管理し、A/Bテストや自動進化の対象にする（これが2026-2027年の勝負所）。

具体的なユースケース（Web Agent、Coding Agent、社内業務エージェント、Multi-agentチームなど）があれば、そちらに特化した詳細設計図やコード構成も出せます。どの方向性を深掘りしたいですか？