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

「AIエージェント ハーネス 設計」というクエリは、まさに現在最も重要なトピックの一つです。プロンプトエンジニアリング → コンテキストエンジニアリングの次のレイヤーとして**ハーネスエンジニアリング**が注目されています。[[1]](https://x.com/tetumemo/status/2037876018745385083)[[2]](https://x.com/taimuhanashiro/status/2023008135464788127)

### ハーネスとは何か

**ハーネス（Harness）**とは、馬具（手綱・鞍）のメタファーで、**凍結したLLM/エージェントを「制御・増幅・信頼性確保」するための実行時環境全体**を指します。

モデル自体は薄く（thin）、知能の多くをハーネス側（Memory, Skills, Protocols, Mediators）に外在化する設計が主流です。モデルを頻繁に変えてもハーネスは再利用可能で、1つのハーネスが複数のバックボーン（18種類以上）で一般化するという研究結果もあります。[[3]](https://x.com/omarsar0/status/2058208914148389083)

企業の実践では「The Harness, Not the Agent」と言われるほど重要視されており、OpenAI内部ではCodexエージェント＋強力なハーネスで**人間が1行もコードを書かずに5ヶ月で約100万行・1500 PRの社内プロダクトを構築**した事例が有名です。[[2]](https://x.com/taimuhanashiro/status/2023008135464788127)

### 設計原則（2026年現在）

1. **Model is CPU, Harness is OS** — モデルは計算リソース、ハーネスが状態・制御・検証を担う
2. **Code as Harness** — 脆い自然言語プロンプトではなく、実行可能コード（状態管理・検証ロジック）でハーネスを表現
3. **FailureをReusable Interventionに変換** — 繰り返し発生する失敗パターンをハーネス側に吸収
4. **Observability First & Replayable** — すべての決定・行動・結果をトレース可能に
5. **Security & Containment by Design** — Sandbox、権限スコープ、事前検証、ロールバックをデフォルトで
6. **Generalization over Specialization** — 特定のモデルに最適化せず、環境構造を捉える

### 推奨アーキテクチャ（3 Layer + 横断層）

Meta/Stanfordの論文で定義された3層を基盤に、現代の実践を加えた設計です。[[4]](https://x.com/marfinxx/status/2082892144520400922)

```mermaid
graph TD
subgraph Interface Layer
A[Standardized Agent Protocol
Input: Observation + Context
Output: Thought + Action]
B[Tool Schema Registry + Validation]
end

subgraph Mediation & Control Layer
C[Policy Engine / Guardrails]
D[Execution Sandbox + Scoped Credentials]
E[Human-in-the-Loop Gate]
F[Rate Limit / Cost Control / Rollback]
end

subgraph State & Intelligence Layer
G[Episodic Memory
(会話履歴・軌跡)]
H[Semantic Memory
(知識グラフ・RAG)]
I[Procedural Skills
(プレイブック・ヒューリスティック)]
J[World Model / File State Manager]
end

subgraph Orchestration Layer
K[Loop Controller
(ReAct / Plan-Execute-Verify / Reflexion)]
L[Multi-Agent Supervisor
+ Peer Review Mechanism]
end

subgraph Evaluation & Adaptation Layer
M[Automatic Evaluator
(Success, Efficiency, Safety, Quality)]
N[Failure Pattern Miner → Harness Update
(Meta-Harness style)]
O[RL on Harness (ClawGym系)]
end

subgraph Observability Layer
P[OpenTelemetry Tracing
+ Decision Replay]
Q[Metrics + Cost + Safety Dashboard]
end

User --> A
A <--> B
B <--> C
C <--> D & E & F
K <--> G & H & I & J
K <--> L
K <--> M & N
Everything --> P & Q
```

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

**1. Harness Interface Layer**
- 統一された入出力プロトコル（JSON Schema厳格定義推奨）
- Tool callingはMCP（Model Context Protocol）や類似の標準化された形式
- 「Code as Harness」：状態（ファイルシステム・DB）をコードでモデル化し、LLMが直接操作可能にする

**2. Mediation & Control Layer（最も重要な部分）**
- **Pre-Action Validation**：ツール呼び出し前にポリシー・安全性・影響範囲をチェック
- **Sandbox**：コンテナ/仮想環境、APIキー最小権限、ネットワーク制限
- **Approval Gates**：高リスク行動は人間承認必須（動的リスクスコアリング）
- **Circuit Breaker & Rollback**：失敗パターン検知で自動停止・巻き戻し

**3. State & Intelligence Layer**
- 短期：会話履歴 + 作業中コンテキスト
- 中期：エピソード記憶（成功/失敗トレース）
- 長期：ベクトル + グラフ知識 + Procedural Skills（再利用可能なプレイブック）
- 「Code Harness」として、状態遷移をコードで表現（LangGraph状態機やカスタムDSL）

**4. Orchestration & Evaluation Layer**
- 基本ループ：Plan → Execute → Verify → Adapt
- Multi-agentの場合：Supervisor + Worker + Reviewerパターン
- 評価指標：Task Success, Step Efficiency, Safety Violation Rate, Output Quality, Cost per Task
- 高度化：失敗トレースから自動的にハーネス（ガードレールや検証コード）を改善（Meta-Harness的アプローチ）

**5. Observability Layer**
- すべてのステップを構造化ログ（Thought, Action, Observation, Score, Cost）
- トレースはReplay可能に（後からデバッグ・評価可能）
- Dashboardで「どのハーネスパターンが最も成功するか」を可視化

### 実装技術スタック例（2026年）

- **コアフレームワーク**: LangGraph（状態管理最強）、CrewAI/LlamaIndex（簡易）、またはゼロから自作（推奨）
- **Observability**: OpenTelemetry + LangSmith/Phoenix/Helicone類似
- **Sandbox**: Docker/Kubernetes + eBPF制限、またはFirecracker軽量VM
- **Policy Engine**: OPA (Open Policy Agent) や独自DSL
- **Evaluation**: カスタムスコアラー + LLM-as-Judge + 人間フィードバックループ
- **言語**: Python（エコシステム豊富）＋ TypeScript（フロント/プロトコル）

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

- [ ] モデルを固定したままハーネスだけ変えたときの性能差を測定できるか
- [ ] 同じ失敗パターンが2回以上発生したら自動的にハーネスを強化できるか
- [ ] 全行動がトレース可能で、任意の時点からリプレイ可能か
- [ ] 高リスク行動にHuman-in-the-Loopが確実に入るか
- [ ] Multi-agent時の協調・検証機構があるか
- [ ] ハーネス自体がバージョン管理され、A/Bテスト可能か

ハーネス設計は「一度作ったら終わり」ではなく、**継続的に失敗から学習して進化させるシステム**です。これがまさに「Harness Engineering」の本質です。

具体的に「コーディングエージェント向け」「カスタマーサポートエージェント向け」「社内業務自動化向け」など、ユースケースを教えていただければ、より詳細なコンポーネント設計・コード例・Mermaid図を深掘りできます。