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

「ハーネスエンジニアリング」は、2025〜2026年に最も注目されているAIエージェントの設計思想です。プロンプトエンジニアリング → コンテキストエンジニアリングの次のレイヤーとして位置づけられています。

**核心の比喩**：
- **モデル = CPU**
- **ハーネス = OS**

モデルがどれだけ賢くても、ハーネス（足場・手綱・制御機構）が貧弱だと本番で信頼できない。逆に優れたハーネスは、古いモデル（GPT-3.5 Turboなど）でも実用レベルに引き上げます。[[1]](https://x.com/swarm_japan/status/2071941883925065792)

実際、LangChainチームはハーネス改善だけでTerminal-Bench 2.0でTop30圏外→Top5に躍進し、OpenAI内部ではCodexエージェントだけで人間が1行もコードを書かずに5ヶ月・約100万行のプロダクトを構築した事例があります。[[2]](https://x.com/tetumemo/status/2037876018745385083)

### 1. 設計目標（優先順位）

1. **信頼性・持続可能性**（動かし続ける）
2. **安全性・セキュリティ**（特にCredential管理）
3. **観測可能性（Observability）**
4. **評価可能性・再現性**
5. **コスト効率とスケーラビリティ**

モデル能力より「環境設計」が勝負を決める時代です。

### 2. 推奨全体アーキテクチャ

**Layered Harness Architecture**（推奨）

```
[Human / Supervisor Layer] ← 人間のステアリング
↓
[Outer Loop / Harness Core]
- Guardrails（MaxSteps, Cost Budget, Timeout）
- Verification & Evaluation Agent（別個体）
- Observation Cleaner
↓
[Agent Loop Engine]（Inner Loop）
- State Machine（LangGraph推奨）
- Planner / Actor / Criticパターン
↓
[Memory & Context Layer]
- Constitutional Docs（DESIGN.md, AGENTS.md）
- Staged Context Loading
- Working / Semantic / Episodic Memory
↓
[Tool & Environment Layer]
- Tool Registry + Tool Search（オンデマンド）
- Sandbox / Permission System
- Credential Proxy（エージェントに直接渡さない）
↓
[Observability & Logging Layer]（全層横断）
- Tracing, Cost Tracking, Audit Log
```

**主要な6構成要素**（Swarmさんの整理が秀逸）：
- ツールレジストリ + コンテキスト管理プリミティブ
- ガードレール + エージェントループ
- 検証ステップ + コスト追跡
- Observation Cleaning
- 評価ルーブリック（自己評価バイアス対策）
- セキュリティ・分離機構

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

#### (1) Outer Loop / Supervisor（最も重要）
- Inner Loop（通常のReActなど）が暴走しないよう監視
- 予算・ステップ数・時間制限を強制
- 定期的に「Verification Step」を挟む
- 人間の承認ゲート（重要なAction前）

#### (2) Verification & Evaluation Layer
- **自己評価バイアス対策**：作成エージェントと評価エージェントを完全に分離
- 主観的評価（「美しいか？」）ではなく、**ルーブリック化**（設計原則遵守チェックリスト）
- Rubric例：「セキュリティ原則を3つ以上満たしているか」「エラーハンドリングが適切か」など

#### (3) Observation Cleaning（地味に最重要）
- 生のTerminal出力やブラウザのDOMをそのままエージェントに渡さない
- 重要な情報だけを抽出・要約して渡す中間層を必ず入れる
- これがないとノイズで判断が崩壊する（Anthropicの実験で証明済み）

#### (4) Memory & Context Design
- 「地図を渡せ」：全部のコンテキストを最初に渡さない（段階的ロード）
- **Constitutional Documents**：
- `DESIGN.md`（憲法・設計原則）
- `AGENTS.md`（役割・制約・品質基準）
- ファイルシステム記憶（コーディングエージェントの場合）とDB記憶を併用

#### (5) Tool Layer
- Tool Search / オンデマンドロード（コンテキスト節約）
- ツール定義は厳格に契約化（JSON Schemaなど）
- Sandbox必須（特にブラウザ・Terminal操作時）

#### (6) Security Harness（2026年現在特に重要）
- Credentialはエージェント外で管理（Proxyパターン）
- 最小権限原則（Scoped Permission）
- ワークフロー内容漏洩防止
- IronClawのようなセキュリティファーストのオープンソースハーネスを参考に

### 4. 実装時の推奨技術・パターン

**フレームワーク選択**:
- **LangGraph**：最も「厚いハーネス」が作りやすい（状態遷移を明示的に設計可能）
- CrewAI / AutoGen：用途による
- 一から作る場合はState Machine + Pydantic厳格化

**推奨パターン**:
- Hierarchical Agents（Supervisor + Worker + Evaluator）
- Self-Review Loop（ただしEvaluatorは別）
- "Scaffolding that is designed to be removed"（モデルが進化したらハーネスを薄くしていく覚悟）

** observability**:
- LangSmith / Phoenix / 自前実装（Prompt + Tool Call + Observation + Costを全記録）

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

- [ ] 自己評価バイアスを排除できているか？
- [ ] Observation Cleaning層があるか？
- [ ] Guardrails（特にコスト・ステップ）は堅牢か？
- [ ] Credentialがエージェント内に漏れないか？
- [ ] コンテキストが爆発しない設計か？（Tool Search採用）
- [ ] ルーブリックによる客観評価が可能か？
- [ ] ハーネス劣化検知・修復の仕組みはあるか？（Cursorが優秀）

### 今後の方向性

2026年は「エージェントを作る年」から「エージェントを動かし続ける年」に完全に移行しています。モデルの賢さよりも、ハーネスの設計品質が本番耐性を決めます。

ハーネスは「一時的な足場」であり、最終的にはモデルに吸収されていくべきものです。しかし、現時点ではこの足場を徹底的に設計する力が競争力の源泉です。

**主要参考資料（優先度順）**:
- Anthropic "Harness design for long-running application development"
- Cursor.aiのAgent Harness改善記事
- OpenAI内部事例（ハーネスエンジニアリング関連）
- Swarmさん、テツメモさんなどの日本語一次まとめ

必要であれば、**具体的なLangGraph実装例**、**ルーブリックテンプレート**、**IronClaw風セキュリティハーネス**の設計、または特定のユースケース（コーディングエージェント / 業務自動化エージェント / ブラウザエージェントなど）に特化した詳細設計も出せます。

どのような深さ・方向性でさらに掘り下げますか？