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

「AIエージェント ハーネス 設計」というクエリは、まさに今最もホットなトピックの一つです。2026年現在、**プロンプトエンジニアリング → コンテキストエンジニアリング → ハーネスエンジニアリング** が主流の考え方になっています。

### ハーネスエンジニアリングの本質

> **「モデルはCPU、ハーネスはOS」**

モデル自体をFine-tuningしたりプロンプトを磨いたりするのではなく、**モデルを包むランタイム・インターフェース・環境・検証機構全体を設計する**ことです。

有名な論文・議論では「**Adapt the Interface, Not the Model**」という原則が繰り返し出てきます。安価なモデルでも優れたハーネスを組み合わせることで、大幅な性能向上（相対88.5%改善の報告例あり）が得られ、ハーネスはモデル間で高い移植性を持ちます。[[1]](https://x.com/omarsar0/status/2058208914148389083)[[2]](https://x.com/i/status/2058208914148389083)

特に重要なのは**Code as Harness**の考え方です。長期的タスクでは純粋なテキストプロンプトではなく、**実行可能コードを状態管理・推論・検証の基盤**として使うアプローチが有力です。

### 推奨アーキテクチャ：5層ハーネスモデル

実務で最も使いやすい構造として、以下の**5層**を推奨します（2026年の日本語コミュニティでもよく参照されている整理です）。

1. **ツール指揮層 (Tool Orchestration)**
- 利用可能なツールの定義、権限範囲、呼び出しプロトコル（MCP、AGENTS.mdなどの標準化動きを活用）
- 構造化Action（Pydanticモデル必須）

2. **検証・自己修正ループ層 (Verification & Correction Loop)**
- 出力検証 → 失敗時は自動リトライまたは修正
- **MakerとVerifierは必ず分離**（自己評価バイアスを防ぐ）
- Outcome（最終状態）検証を最優先

3. **文脈・記憶管理層 (Context & Memory)**
- Short-term（構造化トレース）、Long-term（Vector + Graph）、Procedural Memory（過去の失敗パターンから抽出した「ハーネスルール」）

4. **ガードレール・安全層 (Guardrails & Safety)**
- 事前アクションスキャン（危険コマンド、データ漏洩リスク）
- 実行前承認フロー、ネットワーク許可リスト、自動停止ルール

5. **監視・可視化・評価層 (Observability & Evaluation)**
- 完全トレース（Thought → Action → Observation + コスト・トークン・時間）
- Regression Suite（本番失敗を自動的にテスト化）
- Capability Test + End-State Verification

### 詳細設計ポイント

**Harness Interface（最もレバレッジが高い部分）**
- 統一されたサイクル：`Observation → Thought → Action → Execution → New Observation`
- Actionは厳密にスキーマ定義（JSON Schema + Pydantic v2）
- コーディングエージェントの場合、生成物を即座にファイルシステムに書き、REPLで実行しながら進める「Code-as-Harness」構成が強力

**State Machine**
- LangGraphのようなグラフベース状態管理が標準的
- または**イベント駆動（asyncio）**アーキテクチャでTUI/Bash実行を統合する実装も増えています
- Persistent REPL + ファイルシステムを第一級の状態として扱う

**Evaluation Harness（Anthropicが特に強調）**
- テキスト出力評価から**Agent Outcome（最終状態）評価**へシフト
- 本番での失敗トレースを自動的にRegression Testに変換
- Code-based check（単体テスト実行、assert）を最大化
- LLM-as-Judgeを使う場合は**詳細なルーブリック**を作成し、別エージェントで評価。自己バイアスに注意

**Sandbox & Security**
- Docker + gVisor/Firecrackerレベルの強力分離
- リソース制限、タイムアウト、ネットワークallowlist必須
- 危険アクションは人間-in-the-loopまたは自動ブロック

### 技術スタック例（2026年推奨）

- **コア**: Python + Pydantic v2 + LangGraph（または自前イベント駆動）
- **Sandbox**: E2B風セキュア実行環境 or OpenDevin系
- **Observability**: Arize Phoenix or OpenTelemetry + カスタムハーネスダッシュボード
- **評価**: カスタムRegression Suite + コード実行エンジン + キャリブレーション済みLLM Judge
- **オーケストレーション**: Temporal.io（長時間実行の信頼性確保）

### 実装時の重要原則

- 失敗を「モデルが悪い」で終わらせず、**「ハーネスを改善する材料」**に変換する文化を作る
- 決定論性を可能な限り高める（seed固定、ツールの非確率性を減らす）
- 「安いモデル＋強力ハーネス」の組み合わせをデフォルト思考にする
- ハーネス自体をバージョン管理・再利用可能にする（Meta-Harness的なアプローチ）

---

必要であれば、以下も提供できます：

- 具体的なPydanticモデル定義例（Harness State, Action Schema）
- Mermaidによるアーキテクチャ図
- 5層ハーネスをMarkdownで記述するテンプレート（プロンプトとしてそのまま使えるもの）
- 特定のドメイン（コーディングエージェント、Webエージェント、研究エージェント）に特化した設計

どの部分を深掘りしたいですか？