**AIエージェント ハーネス設計（2026年現在のベストプラクティス）**

「ハーネスエンジニアリング」は2025〜2026年に最も重要なパラダイムシフトの一つです。多くの専門家が繰り返す核心はこれです：

> **The model is not the agent. The harness is.**
> モデルはエンジン（CPU）。ハーネスは車（OS）。

モデルをいくら賢くしても、**ハーネスが弱いと信頼できないエージェント**になります。逆に、ハーネスを改善するだけで同じモデルでもベンチマークが劇的に向上します（例: LangChainがTerminalBenchでTop30→Top5に躍進）。

### 1. ハーネスの本質的な構造（推奨フレームワーク）

優れたハーネスは以下の4つのレイヤーで構成されます：

**中心：Harness Core（仲介層 / Mediators）**
- Sandboxing（実行隔離）
- Observability & Tracing（完全な可観測性）
- Evaluation & Scoring（自動評価）
- Approval Loops / HITL（人間の介入ポイント）
- Context Compression & Routing
- Sub-agent Orchestration

**このコアを中心に3つの知能を外部化（Externalization）**：

1. **Memory（記憶）**
- Working Context（現在進行中のタスク状態）
- Semantic Knowledge（事実・知識）
- Episodic Memory（過去の経験・軌跡）
- Personalized/Long-term Memory（ユーザー固有の嗜好・ルール）

2. **Skills（スキル / 手続き的知識）**
- Operational Procedures（どうやるか）
- Decision Heuristics（判断基準）
- Normative Constraints（やってはいけないこと、品質基準）

3. **Protocols（プロトコル / 契約）**
- Agent ↔ User
- Agent ↔ Agent（マルチエージェント）
- Agent ↔ Tools / External Systems

この構造の優れている点は、「新しい機能を追加するときに、どこに置くべきか」が明確になることです。

### 2. 推奨アーキテクチャ（Layered Design）

**Layer 0: Model Abstraction**
- LLM呼び出しの統一インターフェース
- Structured Output強制（Pydantic, JSON Schema, Tool Calling）
- Cost Control & Rate Limiting

**Layer 1: Loop Engine**
- ReAct（Thin Harness寄り）
- Graph/State Machine（LangGraphなど、Thick Harness寄り）
- Plan-and-Execute / Reflection Loop

**Layer 2: Mediator Layer（最も重要・最も厚くする）**
- **Policy Engine**：すべてのアクションに対してPolicy as Code + LLM Judgeで検証
- **Tool Executor**：Tool定義の一元管理 + 権限チェック + Sandbox実行
- **Trace Collector**：OpenTelemetry互換の構造化トレース（思考→ツール呼び出し→観測の親子関係を必ず記録）
- **State Manager**：バージョン管理されたMemory Graph

**Layer 3: Intelligence Layer**
- Hierarchical Memory System（コンテキストウィンドウを汚さない）
- Dynamic Skill Router（タスクに応じて必要なSkillだけロード）
- Protocol Registry

**Layer 4: Governance & Evaluation**
- 自動評価器（正確性・効率・安全性・ユーザ満足度）
- フィードバックループ（Human + LLM-as-Judge）
- 監査ログ・コストガバナンス・安全ガバナンス

### 3. 設計時の重要判断軸（Thin vs Thick）

- **Thin Harness（Anthropic寄り）**：モデルを強く信頼。シンプルなループに留め、モデルが賢くなったらハーネスを削る。
- **Thick Harness（LangGraph/CrewAI寄り）**：明示的なグラフ・検証・制約を厚く入れ、決定論性を高める。

**推奨**：最初はThickに作り、モデルが進化したら徐々にScaffolding（足場）を取り外していく設計にすること。これが「将来取り外せるハーネス」の条件です。

### 4. 実装で特に重要なポイント

**Observability（これが最優先）**
- すべてのステップを構造化トレースとして記録
- 後から完全にReplay & Debug可能にする
- 失敗パターンの自動クラスタリング

**Sandboxing**
- コード実行、ブラウザ操作、API呼び出しすべてを隔離
- 2026年現在、E2B、Modal、Firecrackerベースのソリューションが主流

**Memory設計**
- コンテキストウィンドウに全部詰め込まない
- Summary + Vector + Graph + Procedural Memoryの階層構造

**Evaluation Harness**
- 各タスクに専用のEvaluatorを用意
- 自動スコア + Human Feedbackの組み合わせ

### 設計チェックリスト

- [ ] すべてのアクションにPolicy Checkがあるか
- [ ] 完全なトレースが記録・再生可能か
- [ ] Memoryがコンテキストウィンドウを汚染していないか
- [ ] 重要なアクションにHuman Approval Gateがあるか
- [ ] 新しい機能を「Memory/Skill/Protocol/Mediator」のどこに置くべきか明確か
- [ ] より良いモデルに置き換えたときに、ハーネスを薄くできる余地があるか
- [ ] プロダクション要件（多テナント、RBAC、コスト制御、監査）が考慮されているか

### 参考になる考え方

- OpenAIの内部事例（5ヶ月で人間が1行も書かずに100万行のプロダクトをエージェントだけで作った話）
- Anthropicの「足場を徐々に取り外す」哲学
- LangGraphのState Machineアプローチ
- 「AGENTS.md」やADR（Architectural Decision Record）をハーネスに組み込む文化

---

必要であれば、**具体的な技術スタック（LangGraph + OTEL + Guardrails）での実装例**、**コードスケルトン**、**特定のユースケース（Coding Agent / Research Agent / Business Process Agent）向け設計**も深掘りできます。

どの部分を詳しく知りたいですか？