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

「The model is not the agent. The harness is.」というのが、今の業界のコンセンサスです。LLMはエンジンに過ぎず、本当の価値と信頼性・性能は**Harness（ハーネス）**で決まります。[[1]](https://x.com/CobusGreylingZA/status/2043638576848707662)[[2]](https://x.com/akshay_pachaar/status/2045510648474530263)

### 1. 現代的なHarnessのメンタルモデル

最新の考え方では、**Harnessをコア**に据え、以下の要素を**外部化（externalize）**します。

- **Memory（記憶）**
- Working Context（現在のタスク状態）
- Semantic Knowledge（意味的知識）
- Episodic Memory（出来事記憶）
- Personalized Memory（ユーザー固有の好み・履歴）

- **Skills（技能）**
- Operational procedures（手順）
- Decision heuristics（意思決定のヒューリスティック）
- Normative constraints（制約・ポリシー・境界）

- **Protocols（プロトコル）**
- Agent ↔ User
- Agent ↔ Agent（マルチエージェント）
- Agent ↔ Tools / Environment

これらを仲介するのが**Mediator Layer**です：
- Sandboxing
- Observability / Tracing
- Evaluation & Verification
- Approval / Human-in-the-loop
- Compression（コンテキスト圧縮）
- Sub-agent orchestration

このモデルが最も引用されている考え方です。新しい機能を追加するときに「これはMemoryに入れるべきか？Skillsか？Protocolか？Mediatorか？」と問うのが有効です。[[3]](https://x.com/i/status/2045510648474530263)

### 2. 推奨アーキテクチャ（実践的設計）

**推奨レイヤー構造（ETCLOVGに着想を得た7層風）**：

1. **Execution Sandbox Layer** — ツール実行・ファイル操作・ブラウザなどのサンドボックス
2. **Tool & Protocol Layer** — ツール定義、権限、呼び出しプロトコル
3. **Context & State Layer** — 多層メモリ管理（短期・長期・ベクトル・グラフ）
4. **Lifecycle & Orchestration Layer** — グラフ/ワークフロー（LangGraph風）、状態機械、ループ制御
5. **Observability Layer** — 完全トレース（Thought → Action → Observation → Evaluation）
6. **Verification & Evaluation Layer** — LLM-as-Judge、ルールベース、人間評価、自己検証
7. **Governance Layer** — ポリシー、承認フロー、予算・コスト制御、安全ガードレール

**イベント駆動**にするのが強く推奨されます。すべてを**Event Bus**（またはTrace Stream）を通じて流し、Logger/Evaluator/Visualizerが購読する形にすると、後から機能を追加しやすく、Replayも容易です。

### 3. 設計原則（これを守らないと痛い目を見る）

- **Observability First**：何もログを取らないエージェントは作らない。すべての思考・ツールコール・観測・コスト・評価を構造化して保存。
- **Reproducibility**：同じシード・同じ入力で完全に再現可能にする（乱数シード、ツールの非決定性を制御）。
- **Composability（交換可能性）**：Policy Engine、Approval Flow、Model Router、Memory Backendなどは独立して交換可能にする。フレームワークをモノリスにしない。
- **Scaffolding Mindset**：今の複雑なHarnessは「足場」。モデルが賢くなったら積極的に削除できる設計にする（Anthropicがよくやっている）。
- **Thin Model + Thick Harness** vs **Thick Model + Thin Harness**：用途によるが、**生産性・信頼性重視なら厚めのHarness**が現在優勢（特にCoding Agentや長時間タスク）。

### 4. 実装時の具体的なポイント

**コアコンポーネント**：
- **Run Manager**：1回のエージェント実行（run_id）を単位に管理
- **Agent Adapter**：LangGraph / CrewAI / OpenAI Agents SDK / 自前ReActなど、さまざまなエージェントを同じHarnessで動かせる抽象化層
- **Tool Harness**：権限チェック、モック機能、レート制限、サンドボックス実行
- **Memory Orchestrator**：異なる種類のメモリを適切にロード/圧縮/退避
- **Evaluator**：複数評価戦略（LLM Judge + ルール + 人間）を組み合わせ
- **Trace Store**：OpenTelemetry互換 + 専用スキーマ（Step, Thought, ToolCall, Observation, Evaluation, Cost）

**データモデル例**（Pydantic推奨）:
- `Run` → `Trajectory` → `Step`（Thought + Action + Observation + Eval）
- すべてのStepに `trace_id`, `parent_id`, `timestamp`, `token_usage`, `cost`, `metadata`

**技術スタック例**:
- **ベース**: LangGraph（現在最もバランスが良い）またはゼロからイベント駆動で構築
- **トレース**: LangSmith互換 or OpenTelemetry + ClickHouse/Postgres
- **評価**: Promptfoo + 自前Judge + Human Feedback
- **ダッシュボード**: React + Trace的可視化（LangSmith風）

### 5. 実践的な始め方

**おすすめ順位**:
1. **LangGraph + LangSmithを徹底的に使い倒す**（最も現実的。多くの企業がこれを拡張している）
2. 足りない部分（独自のMemoryレイヤー、強力なVerification、企業ガバナンス）を**カスタムMediator**として追加
3. 本当に独自に作りたい場合は、最小MVP（シンプルReActを完全にトレース・評価できるハーネス）から開始

最近は「Code as Harness」という考え方も強まっており、特にCoding Agentでは、生成されたコード自体を状態管理・検証の基盤にするアプローチが注目されています。

---

**さらに深掘りしたい場合**、以下の点を教えてください：
- 用途（Coding Agent / 業務自動化 / マルチエージェント / Research Agentなど）
- 既存で使っているフレームワーク
- 特に重視するポイント（コスト、信頼性、安全性、再現性、開発速度など）

現在の最先端は「モデルをどう賢くするか」ではなく「**Harnessをどう賢く設計するか**」に移っています。この認識が最も重要です。