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

「AIエージェント ハーネス設計」とは、**単なるプロンプトやツール呼び出しのループではなく、信頼性・観測可能性・安全性を備えた「エージェント実行プラットフォーム」**を設計することです。

2026年現在、業界のコンセンサスは明確です。

> **「Model is not the Agent. The Harness is.」**
> LLMはエンジンに過ぎず、本質的な能力はハーネス（周囲のインフラ）に外在化されている。[[1]](https://x.com/CobusGreylingZA/status/2043638576848707662)[[2]](https://x.com/i/status/2043638576848707662)

モデルを中心にした設計（Model-Centric）から、ハーネスを中心にした設計（Harness-Centric / Inverted Architecture）へのパラダイムシフトが起きています。

### 1. ハーネスの本質的な役割

ハーネスが担うのは以下の外部化（Externalization）です：

- **Memory（記憶）**: 作業コンテキスト、意味的知識、エピソード記憶、個人化された長期記憶。単なるコンテキストウィンドウではない。
- **Skills（技能）**: 運用手順、意思決定ヒューリスティック、規範的制約（normative constraints）、SOP（標準作業手順）。
- **Protocols（プロトコル）**: ユーザーとの対話契約、他のエージェントとの通信契約、ツールとのインターフェース契約。
- **Mediators（仲介層）**: サンドボックス、観測可能性（observability）、評価ループ、人間承認（approval gates）、圧縮、sub-agent orchestration。

これらを**ハーネスがランタイムに組み立てる**ことで、薄い（thin）モデルでも高い信頼性を実現します。[[3]](https://x.com/akshay_pachaar/status/2045510648474530263)

### 2. 推奨アーキテクチャ（Harness-Centric Design）

```mermaid
graph TD
subgraph "Harness Core (Orchestrator)"
Graph[Stateful Graph Engine\n(LangGraph-style)]
Router[Intent Router / Decision Node]
end

subgraph "Externalized Intelligence"
Memory[Memory Layer\n(Working + Semantic + Episodic + Procedural)]
Skills[Skills Layer\n(Tools + Heuristics + SOPs + Constraints)]
Protocols[Protocols Layer\n(Agent-User / Agent-Agent / Agent-Tool)]
end

subgraph "Mediators / Operational Layer"
Observability[Observability & Tracing\n(OpenTelemetry)]
Safety[Sandbox + Guardrails + Permissions]
Evaluation[Evaluation Loop\n(LLM-as-Judge + Human Feedback)]
HIL[Human-in-the-Loop Gates]
Orchestration[Multi-Agent Coordination]
end

LLM[Thin LLM Reasoning Engine]

Harness_Core --> LLM
Externalized_Intelligence --> Harness_Core
Mediators -.-> Harness_Core
```

**設計原則**:
- **厚いハーネス（Thick Harness）から始める**：最初はLangGraphなどで制御フローを明示的に定義（ノード・エッジ・状態遷移をコードで書く）。
- **Scaffoldingとして設計**：モデルが賢くなるにつれて徐々に取り除けるようにする（AnthropicやManusの事例のように）。[[4]](https://x.com/akshay_pachaar/status/2042586319390674994)
- **将来のモデル交換容易性**：同じハーネスで異なるモデル（Claude, GPT, Grok, Llamaなど）をスイッチ可能にする。

### 3. 各レイヤーの詳細設計

**① Harness Core（オーケストレータ）**
- **推奨実装**: LangGraph（または同等の状態機械グラフ）。これが2026年現在、最も成熟した「Agent Runtime/Harness」基盤。
- 状態（State）を明示的に定義（メッセージ履歴、ツール結果、計画、評価スコアなど）。
- ノード例: `planner`、`tool_call`、`critic`、`router`、`human_approval`、`summarizer`。
- 条件付きエッジで制御フローをコードとして表現（モデルに全部任せない）。

**② Memory Layer**
- **階層化**が重要：
- Working Context（短期）：Redisやin-memory
- Semantic Memory：Vector DB（Pinecone, Weaviate, PGVector）
- Episodic Memory：構造化ログ + Graph DB（過去の成功/失敗事例）
- Procedural Memory：Skills/SOPのバージョン管理
- 忘却（forgetting）機構も必須。

**③ Skills & Protocols Layer**
- Toolは単なる関数ではなく、「権限付き」「スキーマ検証済み」「前後ガードレール付き」のもの。
- 規範的制約（Constitutional Principles）をSkillsとして外部化。
- Protocolsは明確な契約（JSON Schema + 失敗時ハンドリング）とする。

**④ Mediators（最も重要な生産性・安全レイヤー）**
- **Observability**: 全ての思考・行動・観測をトレース（LangSmith, Phoenix, OpenTelemetry）。これがないと改善不可能。
- **Safety Harness**: Tool呼び出し前の権限チェック、出力ガードレール、高影響アクション時のHuman Approval Gate。
- **Evaluation Loop**: 各ステップorタスク終了時に自動評価（LLM-as-Judge）＋人間フィードバック。成功基準を明確化。
- **Resource Governance**: トークン予算、実行時間、コスト制限（特にマルチテナントの場合必須）。

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

- **基盤**: LangGraph + LangChain/LlamaIndex
- **Memory**: Hybrid（Redis + Vector DB + Relational/Graph DB）
- **Observability**: LangSmith or Helicone + OpenTelemetry
- **Guardrails**: NVIDIA NeMo Guardrails or custom constitutional checker
- **Multi-agent**: LangGraphのStateGraph + Supervisorパターン（固定チームより動的recruitmentの研究も注目）
- **評価**: DSPy風の最適化 or 専用Evalフレームワーク

**注意**: 単なる「coding agent」（ローカルファイルシステム中心）のパターンを一般化しすぎないこと。プロダクションでは**本格的なSystems Engineering**（マルチテナント、RBAC、リソース隔離、監査ログ、データベース中心の状態管理）が必要になります。[[5]](https://x.com/ashpreetbedi/status/2040841492860735634)

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

1. 新しい機能を追加するとき「これはMemory/Skills/Protocols/Mediatorsのどこに置くべきか？」を必ず問う。
2. ハーネスは「取り外し可能（removable）」に設計されているか？
3. より良いモデルに換装したときに、ハーネスを簡略化できるか？（これが本当の成功指標）
4. 観測可能性と評価ループが十分に強いか？
5. 重要な決定ポイントにHuman Gateはあるか？

---

この設計は、**LangGraphを基盤にした厚めのハーネス**を推奨しつつ、将来的に薄く進化できるようにしています。

具体的に：
- 特定のユースケース（Coding Agent, Customer Support, Research Agent, Enterprise Workflowなど）
- 技術スタックの制約
- チームの成熟度

を教えていただければ、より詳細なアーキテクチャ図、コードスケルトン、状態定義例、評価指標などを深掘りして提案します。

どのようなエージェントを構築したいですか？