**AIエージェント ハーネス設計（2026年最新プラクティス）**

「AIエージェント ハーネス設計」というクエリから、**モデルを単なるエンジンとして包み込み、信頼性・観測可能性・安全性・評価を本質的に担保する制御レイヤー（Harness）の設計**を求めていると解釈しました。

現在（2026年）、業界のコンセンサスは「モデルは薄く、ハーネスを厚く（Thick Harness）」に移行しています。Prompt Engineering → Context Engineering → **Harness Engineering** → **Loop Engineering** が主流です。良いハーネスはコストを30-60%削減し、速度を30-50%向上させる「Harness Effect」が確認されています。[[1]](https://x.com/ZainHasan6/status/2078596952657412347)

### 1. ハーネスとは何か（本質）

ハーネスは「エージェントを生き続けさせるインフラ」です。フレームワークが「何をするか」を定義するのに対し、ハーネスは以下の責任を持ちます：

- **Timeout / Retry / Recovery**
- **State persistence & checkpointing**
- **Memory synchronization（セッション間）**
- **Sub-agent spawning & orchestration**
- **Sandboxing & permission control**
- **Observability / Evaluation / Guardrails**
- **Cost control & learning loop**

**核心アーキテクチャ（3次元の外部化）**：
- **Memory**：作業記憶、意味記憶、エピソード記憶、個人化記憶
- **Skills**：手順的知識、意思決定ヒューリスティック、規範的制約
- **Protocols**：Agent-User、Agent-Agent、Agent-Toolの契約

これらを**Mediators**（sandbox、observability、evaluation、approval loop、compression、orchestration）が仲介します。[[2]](https://x.com/CobusGreylingZA/status/2043638576848707662)

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

```
[User / Task]
↓
[Input Validator + Risk & Cost Pre-flight]
↓
[Intelligent Router] ←→ [Policy Engine] (swappable)
↓
[Orchestration Core (LangGraph StateGraph + Checkpointer)]
├── Planning Node
├── Tool Call Node → [Tool Harness / Sandbox]
├── Reflection / Verification Node (separate Judge)
└── Learning / Adaptation Node
↓
[Memory & Context Engine] (Hybrid: Short / Vector / Graph / Episodic)
↓
[Safety & Guardrail Mediators] (pre/post every critical action)
↓
[Output Validator + Human-in-the-Loop Gate]
↓
[Evaluation & Scoring Engine] → [Telemetry / Dashboard]
↓
[Persistent Learning Loop] (改善データを次の実行にフィードバック)
```

**設計原則（最重要）**：
- **Everything is Observable & Versioned**（プロンプト、ツール、評価関数、ポリシー全てGit管理）
- **Fail Fast & Gracefully** + **Human-in-the-Loop Ready**
- **Scaffolding is temporary** — モデルが進化したらハーネスを薄くできる設計にする
- **Never let the agent grade itself** — 常に独立したVerifierを使う
- **Composable Microservices** — Policy, Router, Approval, Memory Backendを疎結合に（イベントバス経由）

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

**① Orchestration Engine（最重要）**
- **LangGraph**を強く推奨（2026年現在も最強クラス）。
- 明示的なStateGraphで「計画→実行→検証→学習」のループをコードとして記述。
- `checkpointer` で任意のタイミングで状態を永続化（PostgreSQL + Redis推奨）。
- 利点：デバッグ容易、再現性高く、途中復帰可能。

**② Tool Harness / Sandbox（安全の要）**
```python
class ToolHarness:
async def execute(self, tool_name: str, args: dict, context: AgentContext):
# 1. Permission & Policy Check (RBAC + dynamic policy)
# 2. Input sanitization & PII redaction
# 3. Sandbox execution (e2b, Firecracker, Docker with seccomp)
# 4. Output validation (schema + safety scanner)
# 5. Trajectory recording (OpenTelemetry span)
# 6. Cost & latency telemetry
# 7. Post-execution guardrails
...
```
- 特にCode Interpreter、Browser、Shellツールは**完全隔離**必須。
- Worktreeパターン（作業ディレクトリを隔離）で安全性向上。

**③ Memory & Context Engine**
- 短期：会話履歴 + 最新状態
- 中期：Vector DB（PGVector/Qdrant）+ Knowledge Graph（Neo4j）
- 長期：Episodic Memory（成功/失敗トレースの要約）+ Self-written Skill Library
- Context Compression（LLM要約 or Map-Reduce）必須。

**④ Evaluation & Verification Engine**
- **LLM-as-Judgeは独立モデル**で実施（自己採点禁止）。
- 評価軸例：Correctness, Efficiency, Safety, Clarity, Tool Call Accuracy。
- Golden Dataset（自社タスクの正解トレース集）を構築し、継続的にベンチマーク。
- Incremental Evaluation（各ステップで部分点）。

**⑤ Observability Stack**
- OpenTelemetry + LangSmith / Phoenix / Helicone。
- Trajectory Visualizer（時系列で思考・ツール呼び出し・評価を表示）。
- Cost / Latency / Safety Violationの専用ダッシュボード。

### 4. 構築ロードマップ（実践的）

**Phase 0（1週間）**: 基本ReAct + 構造化Logging
**Phase 1（2-3週間）**: LangGraph + Checkpointer + Trajectory Recording
**Phase 2（3-4週間）**: Tool Sandbox + Permission System + Guardrails
**Phase 3（4週間）**: Evaluation Harness + 自社Golden Dataset作成
**Phase 4**: Multi-agent Hierarchy + Human-in-the-Loop + Auto-recovery
**Phase 5**: Composable化（Policy/Router/Approvalを独立マイクロサービス化）+ Self-improving Loop

### 5. 技術スタック例（2026年推奨）

- **Orchestration**: LangGraph（最優先）
- **Model Abstraction & Routing**: LiteLLM + 独自Router（タスク難易度・コスト・レイテンシで動的選択）
- **Memory**: LangGraph Checkpointer + PGVector + Neo4j
- **Observability**: LangSmith or Phoenix
- **Safety**: LlamaGuard + カスタムPolicy Engine（NVIDIA NeMo Guardrailsも有力）
- **Sandbox**: e2b または自前Firecrackerベース
- **Evaluation**: DeepEval拡張 or 自作LLM Judgeパイプライン

### 追加アドバイス

- **最初に作るべきもの**は「Trajectory Recorder」と「独立したVerifier」です。これがあるだけで品質が劇的に変わります。
- プロダクションでは「Thin Harness（Anthropicスタイル）」より「Thick Harness（LangGraphスタイル）」が安定性で勝っていますが、モデルが進化したら徐々にロジックをモデル側に移す準備を。
- 多剤系の場合は**Hierarchical + Sequential + Human-in-the-Loop**のハイブリッドが最も実用的です。[[3]](https://x.com/victorialslocum/status/2029501587446489528)

具体的なユースケース（例：社内業務自動化、コード生成エージェント、顧客対応エージェント、研究エージェントなど）があれば、それに最適化した設計図・コード例・評価指標をさらに深掘りできます。

必要であれば、LangGraphの実装サンプル、評価用Promptテンプレート、または特定のレイヤーの詳細設計も提供します。どのような部分を深く知りたいですか？