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

2026年現在、「AIエージェント ハーネス設計」は**最も重要なトピックの一つ**になっています。プロンプトエンジニアリング → コンテキストエンジニアリングの次に来るレイヤーとして「ハーネスエンジニアリング」と呼ばれています。

> 「The model is not the agent. The harness is.」
> モデルはエンジン（CPU）。ハーネスが車（OS）であり、足場（scaffolding）である。[[1]](https://x.com/CobusGreylingZA/status/2043638576848707662)

### 1. ハーネスとは何か

ハーネスとは、**生のLLMの周囲に構築する「外部化された知能と制御機構」**全体を指します。単なるツール呼び出しループではなく、以下の4つのレイヤーで構成されます。

- **Memory（記憶）**: 作業コンテキスト、意味的知識、エピソード記憶、個人化記憶
- **Skills（技能）**: 運用手順（SOP）、意思決定ヒューリスティック、規範的制約
- **Protocols（プロトコル）**: Agent↔User、Agent↔Agent、Agent↔Toolsの契約
- **Mediators（仲介層）**: Sandbox、Observability、Evaluation、Approval（Human-in-the-loop）、Orchestration

この4つを**どれだけ上手く外部化・管理できるか**が、エージェントの信頼性・安全性・パフォーマンスをほぼ決定します。同じモデルを使っていても、ハーネスの質で性能が劇的に変わります（LangChainがTerminalBenchで大幅向上した事例など）。[[2]](https://x.com/akshay_pachaar/status/2042586319390674994)

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

```mermaid
graph TD
subgraph Harness_Core["Harness Core (薄いLLMループ)"]
Executor["Executor
（Graph / State Machine）"]
Router["Intent Router / Dispatcher"]
end

subgraph Externalized["Externalized Intelligence"]
Memory["Memory System
・Working Context
・Vector + Knowledge Graph
・Episodic Memory"]
Skills["Skills Registry
・Tools（function calling）
・Procedures / SOPs
・Heuristics / Constraints"]
Protocols["Protocols
・I/O Contracts
・Handoff Protocol
・Tool Schema Standard"]
end

subgraph Mediators["Mediators（最も重要）"]
Sandbox["Sandboxing & Security"]
Observability["Observability & Tracing"]
Evaluator["Self-Evaluation & Reflection Loop"]
Approver["Approval / HITL Loop"]
Orchestrator["Multi-Agent Orchestrator"]
end

LLM["LLM Engine（Thin）"]
User["User / External Environment"]

LLM <--> Executor
Executor <--> Memory
Executor <--> Skills
Executor <--> Protocols
Executor <--> Mediators
Mediators <--> User
```

**設計の基本方針**
- **LLMは薄く保つ**（Thin Model）：複雑なロジックはハーネス側に移動
- **Scaffolding Mindset**：将来的にモデルが賢くなったらハーネスを「薄くしていける」設計にする
- **Explicit vs Implicit**の選択：
- **Thick Harness**（推奨）：LangGraphのようにグラフで制御フローを明示（信頼性重視）
- **Thin Harness**：Anthropic風にモデルにほとんどを任せる（モデル依存が強くなる）

### 3. 各コンポーネントの詳細設計

**1. Executor / Runtime**
- メインループを実装（ReAct、Plan-Reflect-Execute、Hierarchicalなど戦略をプラグイン化）
- LangGraphのStateGraphをベースにすると開発が早い
- 状態はすべて明示的なStateオブジェクト（Pydanticモデル推奨）

**2. Memory System**
- 複数階層で管理：
- Short-term: 現在のタスクコンテキスト
- Semantic: Vector DB（Chroma, PGVectorなど）
- Episodic: 過去の成功/失敗トレース（RAGで呼び出し）
- Long-term: Knowledge Graph（重要な事実関係を構造化）

**3. Skills Registry**
- ToolはOpenAI/Anthropic互換のJSON Schemaで統一
- 「手順書（SOP）」もSkillsとしてRAG化（「この種のタスクはこうやる」という手順を蓄積）
- Normative Constraints（禁止事項・品質基準）もここで管理

**4. Mediators（これが差が出る部分）**
- **Observability**: すべての思考・行動を構造化ログ（LangSmith, Phoenix, OpenTelemetry）
- **Self-Evaluation**: 各ステップ終了後に「この軌跡は適切か？」を別LLM or 同じモデルでレビュー
- **Sandbox**: コード実行はDocker/Firecracker、ブラウザ操作は専用環境
- **Approval Loop**: 高リスク行動（金銭操作、外部API書き込み）はHuman確認必須
- **Compression**: コンテキストが長くなったら要約・圧縮する仕組み

**5. Protocols**
- Agent Handoffの標準化（Multi-agent時に重要）
- 出力は常に構造化（JSON mode or tool calling）

### 4. 実装時の推奨技術スタック（2026）

- **言語**: Python（エコシステムが圧倒的）
- **基盤**: LangGraph（最も成熟） or 理解を深めたいなら最小ハーネスをゼロから実装
- **Memory**: LlamaIndex + Neo4j（Graph） + Qdrant/PGVector
- **Observability**: LangSmith or Phoenix + custom tracer
- **Sandbox**: E2B, Modal, or 自前Docker

**Minimal Harnessから始めることを強く推奨**します。最初は didactic（教育的な）で魔法の少ない実装にし、理解を深めてからプロダクション化してください。

### 5. 設計時のチェックリスト

- 新しい機能を追加するとき：「これはMemoryに入れるべきか？Skillsか？Mediatorか？」
- 「より良いモデルに置き換えたら、ハーネスをシンプルにできるか？」（将来性テスト）
- セルフレビューループがあるか？
- すべての行動にトレーサビリティがあるか？
- ハーネスが陳腐化検知・自動修正できる仕組みはあるか？

---

この設計は、OpenAIの内部事例（人間が1行もコードを書かずに100万行のプロダクトを5ヶ月で作った事例）、LangGraph/Anthropicの方向性、2026年現在のコミュニティの知見を統合したものです。[[3]](https://x.com/taimuhanashiro/status/2023008135464788127)

具体的に「評価ハーネス寄り」「運用ハーネス寄り」「Multi-agent特化」など、**どのようなユースケースで作りたいか**を教えていただければ、さらに詳細な設計図・コード構成・クラス設計まで落とし込んでお答えします。