**AIエージェント ハーネス設計（Harness Engineering）** — 2026年現在の実践的ガイド

「AIエージェント ハーネス設計」というクエリは、まさに今最も重要なトピックの一つです。モデル自体ではなく、**モデルを囲む環境（Harness）**がエージェントの性能を大きく左右するという認識が、Anthropic・OpenAI・LangChain/LangGraph・CrewAIなどの主要プレイヤーで共通しています。[[1]](https://x.com/i/status/2042586319390674994)[[2]](https://x.com/i/status/2057707195933110432)

### 1. ハーネスとは何か

ハーネス（Harness）は、** statelessなLLMを信頼性が高く、制御可能で、観測可能な自律エージェントに変えるための実行環境・制御層**です。

主な役割：
- モデルに毎回読ませる「指示（System Instructions / Meta-Prompt）」
- 永続的な状態管理（State Persistence）
- 完了宣言を許さない**Verification Gates**
- スコープの制限（1つのタスク/機能にロック）
- セッションの明確なライフサイクル（Start Clean → Work → Verify → End Clean）

これがないと、エージェントは「コードを書いた→Doneと言った→実は壊れている」という失敗を繰り返します。

### 2. 設計哲学のスペクトラム（Thin vs Thick）

| アプローチ | 代表例 | 特徴 | メリット | デメリット | 向いているケース |
|----------------|----------------|-----------------------------------|-----------------------------------|-------------------------------------|---------------------------|
| **Thin** | Anthropic | 「愚かなループ」+ モデルにほぼ全権限 | モデルが進化したら簡単に簡略化可能 | 現在のモデルでは信頼性が低い | 研究・高速プロトタイピング |
| **Medium** | OpenAI Agents | Code-first（Pythonロジック）+ Priority Stack | 開発者にとって自然 | 複雑なワークフローで制御が弱まる | 開発者向けツール |
| **Thick** | LangGraph, CrewAI Flows | 明示的なグラフ/フロー + 決定論的制御 | 信頼性・デバッグ性・チェックポイントが強い | モデルが進化しても一部が陳腐化しやすい | **本番運用・企業利用** |

**2026年の推奨**: **Pragmatic Thick**（厚めの制御を基本としつつ、Scaffoldingとして「取り外し可能」に設計する）。モデルが賢くなったら特定のノードを削除・融合できるようにする。[[1]](https://x.com/i/status/2042586319390674994)

### 3. 推奨アーキテクチャ（全体像）

```mermaid
graph TD
subgraph "Harness Core"
A[Session Manager] --> B[State Store
(Checkpointing)]
B --> C[Meta-Instruction Loader]
C --> D[Orchestrator Graph]
end

subgraph "Graph Nodes"
D --> E[Planner / Router]
E --> F[Reasoner
(LLM Call)]
F --> G{Action Type?}
G -->|Tool| H[Tool Harness
(Validate→Sandbox→Execute)]
G -->|Final Answer| I[Verifier Gate]
H --> J[Observation Parser + State Update]
J --> F
I -->|Pass| K[Session Finalizer
+ Artifact Export]
I -->|Fail| F
end

subgraph "Supporting Layers"
L[Memory System
(Short/Long-term + Vector)]
M[Guardrails & Safety Layer]
N[Observability
(Trace, Cost, Audit)]
O[Human-in-the-Loop Gateway]
end

L -.-> D
M -.-> H
M -.-> I
N -.-> D
O -.-> I
```

**核心はState Graph + Checkpointing**です。LangGraph（または同等のフレームワーク）を使うと、各ノード間の状態を自動で永続化でき、クラッシュ時や中断時の復旧が極めて強力になります。

### 4. 各コンポーネントの詳細設計

#### (1) Meta-Instruction Layer（最も重要）
毎ターン/セッション開始時に読ませる指示群：
- 全体ビジョン（What is the ultimate goal?）
- スコープ制限（Do not touch X, Y）
- Verification基準（何をもって「完了」とするか）
- 出力フォーマット厳格化
- 失敗時の振る舞い

これを**バージョン管理**し、A/Bテストできるようにする。

#### (2) State Management
- **必須項目**: Current Task, Artifacts（生成物）, Verification Status, Compressed History, Tool Use Log
- 永続化: Postgres（構造化状態） + Redis（高速アクセス） + Blob Storage（Artifacts）
- チェックポイント: 重要なノード終了後に必ず保存（Temporal.io併用が強力）

#### (3) Tool Harness（安全の要）
- Tool Registry（スキーマ、権限、レートリミット、side-effect分類）
- Pre-execution Validation（入力サニタイズ、権限チェック、LLM-as-Judge）
- Sandbox Execution（Docker/Firecracker/Cloud Function）
- Post-execution Audit + Structured Output Parsing

#### (4) Verification Gates
- 自動検証（単体テスト実行、diffチェック、LLM Judge）
- 人間承認（高リスクアクション時）
- 「Done」を宣言する前に必ず通過させる

#### (5) Memory System
- Working Memory（現在のコンテキスト）
- Episodic Memory（過去のセッション）
- Semantic Memory（RAG + Graph RAG）
- 積極的な要約・圧縮機構

#### (6) Observability & Governance
- OpenTelemetry + LangSmith/Phoenix/Helicone相当
- 全ての決定にTrace IDを付与
- Cost Guardrail（予算超過で自動停止）
- Audit Log（誰が・いつ・何を承認したか）

### 5. 実装おすすめスタック（2026年時点）

- **フレームワーク**: LangGraph（明示的制御が欲しい場合）または **Custom Graph on Temporal.io**（超長時間実行・信頼性最優先）
- LLM: Claude 4 / Grok / GPT-5系をタスクに応じてルーティング
- 状態管理: Pydanticモデル厳格化 + JSON Schema
- 観測: OpenLLMetry + 自前ダッシュボード
- Sandbox: Firecracker microVM or 専用Kubernetes namespace

### 6. 設計時のベストプラクティス

1. **Scaffolding Mindset** — 「モデルが賢くなったら削除できる」設計にする。
2. **Remove Complexity Iteratively** — 新しいモデルが出たら、Plannerノードや一部のVerificationを削除して性能を再測定。
3. **Vision First** — ハーネス設計の前に「このエージェントは何のために存在するのか（ビジョン）」を明確にする。これがループ設計と指示の根源になる。[[3]](https://x.com/kawai_design/status/2067799814985994477)
4. **評価をハーネスに組み込む** — 単なる成功率ではなく、Verification Pass Rate、Human Intervention Rate、Cost per Successful TaskをKPIにする。
5. **最初は厚く、後で薄く** — プロダクションでは厚めの制御から始め、信頼性が確保できたら徐々にモデルに任せる。

---

この設計をベースに具体的なユースケース（コード生成エージェント、業務自動化エージェント、リサーチエージェントなど）があれば、さらに詳細な設計書（クラス図、状態遷移図、プロンプト例、LangGraph実装スケルトン）を作成できます。

必要であれば：
- 特定のドメイン向けハーネス設計
- Thin Harness版との比較実装
- 実際のLangGraphコード例

をお伝えします。どの方向を深掘りしますか？