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

「モデルはエンジン。ハーネスが車である」という認識が2026年の業界コンセンサスです。どれだけ賢いモデルを使っても、ハーネスが貧弱だとプロダクションで必ず壊れます。

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

ハーネスとは、**モデルを「制御可能で、デバッグ可能で、信頼できる労働力」に変換する全周辺システム**です。

特に日本コミュニティで広く共有されているフレームワークとして以下の**3層モデル**が有効です：

- **ハーネス層**：作業環境・制約・許可されたツールと権限の設計（「何をさせてはいけないか」を最初に決める）
- **ループ層**：観察→推論→行動の繰り返し＋検証・リフレクション・自己修正機構
- **グラフ層（Graph Engineering）**：全体のワークフローを有向グラフとして明示的に設計（分岐・並列・検査・人間承認をノードとして定義）

ループだけでは複雑な業務は破綻します。**グラフエンジニアリング**が2026年の主流になっています。

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

```mermaid
graph TD
A[Input/Output Layer
UI・Voice・Document] --> B[Control & Safety Layer]
B --> C[Orchestration & Graph Engine]
C --> D[Memory & Knowledge System]
C --> E[Tool Integration Layer
(MCP Servers)]
C --> F[Reasoning Layer
(Model Router: SLM/LLM/LRMs)]
G[Observability & Evaluation Layer] --> B
G --> C
G --> D

subgraph "最重要: Control Plane"
B
end
```

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

**1. Control & Safety Layer（最優先で設計）**
- Policy Engine（何を許可/拒否するか）
- Approval Gates（不可逆操作＝メール送信・金銭・コードデプロイ時は必ず人間承認）
- Termination Conditions（「孫子の兵法」的に勝ち目がないと判断したら即停止）
- Budget Guardrails + Cost Control
- Credential Management（最小権限原則）

**2. Orchestration & Graph Engine**
- 有向グラフでワークフローを定義（LangGraphの考え方をさらに進化させたもの）
- ノード例：Planner、Worker、Critic、Validator、HumanGate、Evaluator
- 状態の永続化とチェックポイント（必ず復元可能にする）
- 並列実行・動的分岐のサポート

**3. Memory System（競争力の源泉）**
- Working Memory（現在進行中のコンテキスト）
- Semantic Memory（Vector DB）
- Episodic Memory（過去の軌跡・成功/失敗パターン）
- Procedural Memory（スキル・ベストプラクティス）
- 企業全体の「Company Brain」（Graph DB推奨）とエージェントグラフを一体化させる動きが強い

**4. Tool Integration Layer**
- **MCP (Model Context Protocol)** が2026年の標準インターフェースになっています
- MCP Server経由でツールを標準化・発見可能・安全に接続
- Sandbox必須（E2B的なセキュア実行環境）

**5. Observability & Evaluation Layer**
- 完全なトレーシング（トークン消費・コスト・品質・意思決定経路）
- LLM-as-Judge + タスク固有メトリクス + 人間のpreferenceデータ
- フィードバックループによる継続的改善

### 3. 設計原則（これを守ると失敗率が劇的に下がる）

1. **Constraint First** — 自由を与える前に、徹底的に制約を設計する
2. **Explicit Success Criteria** — 「これができたら完了」というバイナリ条件を必ず定義
3. **Verification Everywhere** — 重要なアクションには常にCritic/Validatorを入れる（自己検証＋他エージェント検証）
4. **Debuggability First** — グラフをビジュアル化できる状態にする
5. **Composability** — Policy Engine、Approver、Model Routerなどは交換可能にする（モノリシックフレームワークに全力で依存しない）
6. **Progressive Autonomy** — 最初は人間承認多め → 信頼スコアが上がったら自動度を上げる

### 4. 技術スタック例（2026年時点）

- **Orchestration**: LangGraph系 or 新世代Graph Engine + Temporal
- **Memory**: Vector（Qdrant/Pinecone）＋ Graph DB（Neo4j / HydraDB系）＋ Redis
- **Safety**: カスタムPolicy Engine + 最新Guardrailモデル + Sandbox
- **Tools**: MCP Serversを徹底活用
- **Evaluation**: 自前Evaluator Swarm + OpenTelemetry
- **Interoperability**: A2A（Agent-to-Agent）プロトコル

### 5. 具体例：Software Development Agent Harnessの場合

- Design Agent → Critic Agent（UI/UXレビュー）→ Coder Agent → Test Agent → Security Scanner → Human Approval Gate
- すべてのステップでグラフ上に明示
- コード書き換えは必ずlinter + test実行を通過させるノードを挟む
- 進捗はpersistent progress fileに常時書き込み（コンテキスト消失対策）

---

**設計チェックリスト（これで80点以上取れればかなり強い）**

- [ ] 不可逆操作にHuman Gateがあるか
- [ ] グラフとしてワークフローが明示的に設計されているか
- [ ] Memoryの4種類（Working/Semantic/Episodic/Procedural）が整理されているか
- [ ] MCPまたは同等の標準ツール接続層があるか
- [ ] 完全なトレーシングと自動評価機構があるか
- [ ] 「勝ち目がない」と判断するTermination条件があるか
- [ ] 各コンポーネントが疎結合で交換可能か

必要であれば、特定のユースケース（営業エージェント、リサーチエージェント、コードエージェントなど）に特化した詳細設計も出せます。

この設計思想で作られたハーネスは、モデルが入れ替わっても頑健に動き続けます。それが2026年現在の正しいアプローチです。