**AIエージェント ハーネス設計（2026年現在の実践的アプローチ）**

「モデルはエンジン、ハーネスが車である」という表現が象徴するように、2026年現在、AIエージェントの本質はLLMそのものではなく、その周囲の**ハーネス（Harness）**にあります。ハーネスとは、LLMを信頼性が高く、安全で、再現性のある自律エージェントに変える実行基盤のことです。[[1]](https://x.com/CobusGreylingZA/status/2043638576848707662)

### 1. ハーネスが重要な理由

- 同じモデルを使っても、ハーネスの質でベンチマーク結果が大きく変わる（例: TerminalBenchなどでLangChainが大幅向上）。
- モデルは急速に進化するが、ビジネスロジック・安全性・観測可能性はハーネスに外在化すべき。
- 将来的に「足場（scaffolding）として設計し、モデルが賢くなったら徐々に取り外す」ことが理想とされている。

### 2. コア設計原則（現在のコンセンサス）

1. **Append-only Immutable Session Record**
会話履歴を絶対にインラインで書き換えない。すべての状態変化を追記ログとして記録し、リプレイ可能にする。これが信頼性とデバッグの基盤。

2. **Minimal / Commoditized Loop**
制御ループは小さく、退屈で、標準的なものにする。独自の複雑なループは避ける（誰も勝てない）。

3. **Progressive Disclosure（段階的開示）**
プロンプトに全ツール・全スキル定義を載せない。最初は名前・説明・参照パスだけ渡し、必要時にエージェント自身が詳細をフェッチする。これによりコンテキスト汚染とトークン浪費を防ぐ。[[2]](https://x.com/LeoTava8/status/2098489072927064065)

4. **Externalizationの明確化**
- **Memory**: Working Context / Semantic / Episodic / Personalized
- **Skills**: 手順・ヒューリスティック・規範的制約（normative constraints）
- **Protocols**: Agent-to-User、Agent-to-Agent、Agent-to-Toolの契約

5. **Mediator Layerの重視**
Sandboxing、Observability、Compression、Evaluation、Approval Loop、Sub-agent Orchestration。これらがハーネスの「運用脳」。

6. **MiniMal Harnessの有効性**（日本コミュニティでも注目）
Bashなどの最小ツールに絞り、複雑な専用ツールを排除すると、KVキャッシュ効率・指示従順性・コンテキスト明瞭性が劇的に向上するケースが多い。[[3]](https://x.com/ai_hakase_/status/2098532800706089085)

### 3. 推奨アーキテクチャ

```mermaid
graph TD
subgraph Harness [AI Agent Harness]
Loop[Core Loop Manager
（Minimal ReAct / LangGraph / Custom State Machine）]
Mediator[Mediator Layer
Sandbox・Guardrails・Observability・Evaluator・Router]

subgraph Externalized [Externalized Intelligence]
Memory[Memory Layer
Working + Semantic Vector + Episodic Log + Personal]
Skills[Skills Layer
Procedural + Heuristics + SOPs]
Protocols[Protocols Layer
A2U / A2A / A2Tool Contracts]
end

LLM[Thin LLM Engine]
end

Env[External Environment
Tools, Browser, APIs, Code Executor]
Human[Human-in-the-Loop / Approval]

Loop <--> Mediator
Mediator <--> Memory & Skills & Protocols
Mediator <--> LLM
Mediator <--> Env
Mediator <--> Human
```

**各レイヤーの設計ポイント**

- **Core Loop**: 薄く保つ（Anthropic寄り）か、明示的グラフで制御（LangGraph寄り）かは用途による。2026年は「薄く始めて、必要に応じて厚くする」アプローチが主流。
- **Mediator Layer**: 最も重要な差別化領域。
- Sandbox: コード実行はFirecracker/gVisorなどの軽量マイクロVM推奨。
- Guardrails: アクションごとに危険度スコアリング + 自動/人間承認フロー。
- Observability: OpenTelemetry + tamper-evident（改ざん検知可能）な実行トレース。外部検証可能性が次のフロンティア。
- Intent Router: どのSkillをいつロードするかの動的決定（コンテキスト節約に必須）。

- **Memory Layer**: 単なる会話履歴ではなく、ライフサイクルを分ける（短期作業記憶 vs 長期意味記憶 vs エピソード履歴）。

- **AGENT.md / Skill定義**: 多くのチームが採用。エージェントごとに役割・許可アクション・規範・参照ドキュメントを宣言的に記述。ハーネスはこのファイルを読み込んで動的にSkillをロード。

### 4. 薄いハーネス vs 厚いハーネスの選択

- **薄いハーネス（Anthropic寄り）**: モデルに多くを任せる。モデルが賢くなればハーネスを削れる。将来的に有利だが、現時点の信頼性は低い。
- **厚いハーネス（LangGraph / CrewAI寄り）**: グラフやFlowsでロジックを明示。制御性・安全性が高いが、モデル進化時にリファクタリングコストが発生。
- **現実的な推奨**: **Minimal Harnessから始め、評価しながら徐々に厚くする**。そして「この足場はいつ取り外せるか？」を常に意識する。

### 5. 実装時のTips

- **技術スタック例**:
- Orchestration: LangGraph（明示的制御が欲しい場合） or 純粋なPythonループ（ミニマル志向）
- Observability: LangSmith / LangFuse / Phoenix + OpenTelemetry
- Sandbox: E2B, Modal, または自前Docker/Firecracker
- Memory: PGVector + SQLite（append-only log）+ Redis（working memory）
- Evaluation: LLM-as-Judge + ルールベース + 人間フィードバック

- **最初に作るべきもの**:
1. Append-onlyログ機構
2. シンプルなReActループ + Progressive Tool Disclosure
3. 基本的なGuardrail + Sandbox
4. セッション再現（Replay）機能

ハーネス設計は「一度作ったら終わり」ではなく、モデルが進化するたびに削ぎ落としていく**進化する足場**です。

もっと具体的な部分（例: AGENT.mdのテンプレート、Mediatorのコード構成、LangGraph vs Minimalの実装比較、Multi-agentの場合のProtocol設計など）が知りたい場合は、深掘りしたいトピックを教えてください。実際のSpeaker Deck「ハーネス設計入門」なども参考にしながら、実務で使えるレベルまで落とし込めます。