**AIエージェント ハーネス設計（2026年最新プラクティス）**

「AIエージェント ハーネス」とは、単なるツール呼び出しラッパーではなく、**LLMを薄く保ちながら知能の大部分をランタイム側（コード・状態・検証・制御）に押し出した実行基盤**です。プロンプト頼みの不安定さを排除し、長期的・状態を持つタスクで再現性・検証可能性・安全性を担保します。

2026年現在、Meta/Stanfordなどの研究で「**Code as Agent Harness**」が主流になっており、プロンプト中心から「実行可能なコード構造中心」へのパラダイムシフトが起きています。[[1]](https://x.com/marfinxx/status/2082892144520400922)

### 1. 基本原則（これを守るだけで設計品質が大きく変わる）

- **Model is thin, Harness is intelligence**：モデルは推論エンジンとして最小限に。記憶・スキル・プロトコル・制御はハーネス側で外部化。
- **失敗をハーネスの資産に変換**：繰り返し起きる失敗パターンをコード（Intervention/Guard/Verifier）として蓄積。
- **Stateful First**：すべて状態を持ち、再現可能にする（ファイルモデル、永続メモリ、トランザクション）。
- **Verification > Planning**：計画は複雑タスクでそこそこ有効だが、最終Verifier（LLM-as-Judge）の方がコストパフォーマンスが高い。不可逆アクションは事前承認ゲート必須。[[2]](https://x.com/arkyyang/status/2100938306070761594)
- **Portability**：良いハーネスはモデルを容易に交換可能（1つのハーネスが17モデル以上に一般化する事例あり）。

### 2. 推奨アーキテクチャ（3 Layer + Mediators）

```mermaid
graph TD
subgraph "Harness Core"
Executor[Executor Engine\n(ReAct / Plan-Execute / JEV Loop)]
State[State Machine\n(Atomic + Persistent)]
end

subgraph "Layer 1: Harness Interface"
ToolAdapter[Tool / Environment Adapter\n(標準化されたAction/Observation)]
FileModel[Stateful File & Resource Model]
Env[Environment Simulator\n(Desktop / API / Sandbox)]
end

subgraph "Layer 2: Harness Mechanisms"
Planner[Planner / Skill Registry]
Memory[Multi-level Memory\n(Working / Semantic / Episodic)]
Verifier[Verifier + Evaluator\n(Outcome + Process)]
Feedback[Feedback Loop\n(失敗→Intervention生成)]
end

subgraph "Layer 3: Harness Scaling"
Orchestrator[Multi-Agent Orchestrator]
Review[Peer Review / Automated Verification]
Approval[Approval Gates\n(人間 or 強Verifier)]
end

subgraph "Mediators (横断)"
Sandbox[Sandbox & Permission System]
Observability[Observability\n(OpenTelemetry + Trace)]
Evaluator[Metrics & Auto-Eval]
end

User[User / Task] --> Executor
Executor <--> Interface
Executor <--> Mechanisms
Mechanisms <--> Scaling
Executor <--> Mediators
```

**Layer 1 (Interface)**: LLMと現実の実行環境を疎結合。Actionをコード実行可能形式（Python関数、JSON Schema厳格定義）に変換。

**Layer 2 (Mechanisms)**: 長期的推論を支える中核。永続メモリ、動的計画更新、Verifierが特に重要。

**Layer 3 (Scaling)**: 複数エージェント、コードレビュー、PR-like検証。企業・プロダクションで必須。

**Mediators**: 安全性と可観測性を全レイヤーで担保。

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

| コンポーネント | 責務 | 推奨実装（2026） | 重要度 |
|----------------|------|------------------|--------|
| **Executor** | メインループ制御、予算管理（step/token/time）、例外回復 | Async + State Machine。JEV（Judge-Evaluate-Verify）ループ推奨 | ★★★★★ |
| **State Machine** | 原子性のある状態管理、再現性確保 | Pydanticモデル + SQLite/JSONL永続化。トランザクション必須 | ★★★★★ |
| **Tool Adapter** | ツール呼び出しの標準化・サニタイズ | OpenAI tool call互換 + 厳格JSON Schema + 自動ドキュメント生成 | ★★★★★ |
| **Verifier** | 最終出力/状態の正しさチェック | LLM-as-Judge（低コストモデル可）+ Rule-based。False Positive削減に非常に有効 | ★★★★★ |
| **Memory System** | Working / Semantic / Episodic / Procedural | Vector + Graph + Code Memory（codebase-memory-mcp類）。圧縮機構必須 | ★★★★ |
| **Sandbox** | 権限管理、ネットワーク隔離、巻き戻し | Docker/Firecracker or OS-level capability。不可逆アクションは事前ゲート | ★★★★★ |
| **Observability** | 全トレース、失敗パターン抽出 | OpenTelemetry + 可視化（LangSmith後継 or Phoenix類）。失敗をInterventionに変換するフック | ★★★★ |
| **Intervention Registry** | 過去失敗から学んだガード/修正コード集 | 失敗発生時に自動/手動でInterventionを登録。ハーネス自体を改善 | ★★★★ |

### 4. 実装時の推奨プラクティス

- **データモデル**：すべてPydantic v2で厳格定義（Task, Trajectory, Observation, Action, Verdict）。
- **言語**：Python（研究・柔軟性）またはTypeScript（プロダクション）。両対応のStrands Harnessのようなプロジェクトも登場。
- **ループ設計**：純粋ReActより「Plan → Execute → Verify → Adapt」の構造を基本に。
- **評価**：Outcome評価だけでなくProcess評価（効率、安全性、説明可能性）も実施。
- **構成管理**：YAML + Hydra-likeでハーネス設定をバージョン管理。A/Bテスト容易に。
- **高ROIから始める**：まずは**Sandbox + Verifier + Observability**を実装。これだけで信頼性が劇的に上がる。

### 5. 最新トレンド（2026年9月時点）

- **Code Harness**が主流。プロンプトではなく「実行可能なコード構造」で状態と検証を管理。
- **Planning + Release Control**論文：計画は複雑タスクに有効だがモデル間で転移しにくい。Verifier単独でも高い費用対効果。
- 実用プロジェクト例：Strands Harness（コスト28%減）、univer（Office-like runtime）、JEVフレームワーク（Inner/Outerループによる自己改善）、impeccable（デザイン特化）など。
- 科学・コーディング・業務エージェントでは「ハーネス自体をRLで改善する」Meta-Harness的なアプローチが増加。

### 始め方（おすすめ）

1. 小さく始める：Gym-like Environment + シンプルExecutor + Verifierだけの実装。
2. 既存をフォーク：LangGraph / Inspect AI / AutoGenの最新版、または新興のStrands Harnessをベースに拡張。
3. 失敗トレースを徹底的に貯めてInterventionを蓄積（これが差別化要因）。

この設計をベースにすれば、研究用途からプロダクションの自律型コーディングエージェント、科学発見エージェントまで対応可能です。

具体的にどの部分を深掘りしたいですか？
- 詳細クラス図・コードスケルトン
- Sandbox / Verifierの実装例
- Multi-agent Scaling層
- JEVループやMeta-Harness風自己改善機構
- 特定のドメイン（コーディング / ウェブ / 科学）向け特化設計

用途を教えてください。より具体的な設計書・コードに落とし込みます。