**AIエージェント ハーネス設計（Harness Engineering）**

2026年現在、「ハーネス設計」はPrompt Engineering、Context Engineeringに続く最重要トピックになっています。AnthropicやOpenAIが公式に取り上げ、Mitchell Hashimoto（Terraform/Vagrant作者）が用語の起源とされ、性能差が明確に出る領域です。[[1]](https://x.com/kawai_design/status/2037313908969750831)

### ハーネスとは何か

**「AIが働く環境そのもの」**を設計するレイヤーです。

- **Prompt**：指示の言葉
- **Context**：AIに見せる情報全体（会話履歴、ツール出力、資料）
- **Harness**：AIが使えるツール・権限・失敗検知・制御機構の仕組み全体
- **Loop**：確認→修正→再実行の繰り返しフロー

ハーネスは「馬具（手綱）」の意味通り、強力だが制御しにくいAIの知能を、人間が意図した方向に効率的に引き出すための**制御・観測・安全装置**です。モデル性能よりハーネスの質が結果を左右する時代です。[[2]](https://x.com/i/status/2091054972582719926)

### ハーネス設計の主要構成要素

良いハーネスは以下の6つのレイヤーで構成されます。

#### 1. Tool Interface Layer（ツール抽象化層）
- すべてのツールに豊富な**メタデータ**を付与
- `risk_level`（0-5）
- `requires_approval`（高リスク行動はHuman-in-the-Loop）
- `cost_profile`、`latency_profile`、`reliability_score`
- `domain`、`example_usage`
- 動的ツール登録（コード変更なしでツール追加可能）
- 統一された呼び出し規約＋自動スキーマ生成＋フォールバック戦略

#### 2. Permission & Governance Layer（権限・統治層）
- Agent向け細かいRBAC（役割ベースアクセス制御）
- リスクベースの承認フロー（Tier 0: 参照のみ、Tier 1: 承認必要、Tier 2: 複数承認＋監査）
- Sandboxing戦略（特にCode Interpreter、ブラウザ操作、ファイルシステム）
- 推奨：E2B、Firecracker、またはセキュアなコンテナ

#### 3. Observation & Control Plane（観測・制御平面）
- 専用トレース設計（重要なポイント）
- `agent.thought`
- `agent.plan`
- `agent.action`
- `agent.observation`
- `agent.reflection`
- `agent.loop_decision`
- 各スパンにコスト・トークン・モデル・信頼度を紐付け
- リアルタイムSteering機能（人間が途中で介入して方向修正可能）

#### 4. Failure Detection & Recovery Harness（失敗検知・回復機構）
これがハーネスの核心の一つです。

- ループ検知（同じ行動の繰り返し）
- Goal drift検知（当初の目的から逸脱）
- 異常行動検知（ハルシネーションによるツール誤用）
- 自動リカバリー戦略（違うモデルを使う、コンテキスト圧縮、Human Escalation）

#### 5. Memory & State Management Harness
- 単なる会話履歴ではなく、**階層的メモリ構造**
- Working Memory（現在注目している情報）
- Episodic Memory（これまでの軌跡）
- Semantic Memory（知識）
- Procedural Memory（学習した手順）
- 状態の永続化と部分復元（長時間実行対応）

#### 6. Evaluation & Quality Gate
- 各実行に対して自動スコアリング（正しさ、効率性、安全性、経済性）
- ハーネス変更時の回帰テスト
- A/Bテスト機構（異なるハーネス設計を本番流量で比較）

### 推奨アーキテクチャパターン（2026年現在）

```mermaid
graph TD
Supervisor[Supervisor Agent
（目標管理・ハーネス制御）] --> Worker1[Worker Agent 1]
Supervisor --> Worker2[Worker Agent 2]
Supervisor --> ToolRouter[Tool Router + Permission Checker]
ToolRouter --> SandboxedTools[Sandboxed Tools]
Observer[Observer / Trace Pipeline] --> Eval[Evaluation Engine]
HumanHITL[Human-in-the-Loop Gate] <--> Supervisor
State[Persistent State
（Postgres + Redis + Vector）] <--> All
```

- **Hierarchical + Graph**（LangGraphが最も成熟）
- Coding Agentなら**OpenHands**のような専用ハーネスをベースにするのが有力
- 肥大化対策：ハーネス自体をモジュール化し、変更容易性を最優先（@gota_baraのSpeakerDeckが参考になる）[[3]](https://x.com/gota_bara/status/2046794926604931447)

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

- [ ] すべてのツールにリスクメタデータは付いているか？
- [ ] 高リスク行動に適切な承認ゲートはあるか？
- [ ] 異常時に人間が介入できる仕組みはあるか？
- [ ] トレースが「なぜその行動を取ったか」まで追えるか？
- [ ] ハーネス変更時の評価が自動化されているか？
- [ ] コスト・ループ・Goal driftのガードレールは十分か？

### 今後の方向性

モデルがさらに賢くなればなるほど、ハーネスの重要性は増します。
「誰が一番賢いモデルを持っているか」ではなく、「誰が最も効率的・安全・制御可能なハーネスを設計できるか」が競争優位性になります。

具体的なユースケース（特にCoding Agent、業務自動化エージェント、Research Agentなど）が決まっている場合は、その領域に特化した詳細設計も可能です。教えてください。