**AIエージェント ハーネス設計（Harness Engineering）** — 2026年現在の最重要トピックです。

### 1. ハーネスとは何か？（根本的な考え方）

**「モデルはエンジン。ハーネスが車（またはOS）である。」**

LLM自体は stateless な推論エンジンに過ぎません。本当に価値を生むのは、その周囲に構築する**ハーネス（足場・手綱）**です。

- プロンプトエンジニアリング → コンテキストエンジニアリング → **ハーネスエンジニアリング** が現在の成熟段階です。
- LangChainがTerminalBenchで「同じモデルでTop30→Top5」に跳ね上がった事例や、OpenAI社内での「人間が1行も書かずに100万行のプロダクトをCodexエージェントで作った」事例は、全てハーネスの質で決まっています。

ハーネスが優れていると、モデルを交換しても挙動が安定し、逆にモデルが良くてもハーネスが貧弱だとすぐに崩れます。

### 2. 推奨アーキテクチャ（2026年版）

```mermaid
graph TD
A[LLM Inference Engine] --> B[Mediator Layer
（ハーネスの心臓部）]

subgraph "Externalized Intelligence"
B --> C[Memory Layer
・Working Context
・Semantic
・Episodic
・Personalized]
B --> D[Skills Layer
・Playbooks
・Heuristics
・Normative Constraints]
B --> E[Protocols Layer
・Agent-User
・Agent-Agent
・Agent-Tool]
end

B --> F[Operational Mediators]
F --> G[Orchestration Loop
+ Ralph Loop]
F --> H[Context Compressor
+ Selective Recall]
F --> I[Sandbox Executor
（Container/Browser）]
F --> J[Governance & Safety
（予算・承認・ポリシー）]
F --> K[Evaluation & Verification
（自動テスト・LLM Judge）]
F --> L[Observability & Tracing]
```

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

**（1）Orchestration Loop（最も重要）**
- 単純な ReAct ループではなく、**状態機械 + 明確な出口条件**を持つ。
- **Ralph Loop**（推奨パターン）：エージェントが「完了した」と主張したら即座にインターセプト → 自動テスト/リンター/レイアウトチェックを実行 → 失敗結果をフィードバックして強制継続。これを繰り返す。
- 最大イテレーション数、コスト上限、Human-in-the-Loopの強制ゲートをハードコードで入れる。

**（2）Memory Layer**
- すべてをコンテキストに詰め込まない。
- Working Context（現在進行中のタスク状態）はファイルシステム（永続ワークスペース）として持つのが強力。
- Episodic Memory（過去の成功/失敗トレース）はベクトル + グラフで管理。
- コンテキストが膨張したら、自動で要約・圧縮・選択的リコールをハーネス側で実行。

**（3）Skills & Protocols**
- スキルは「何を知っているか」ではなく「どう判断し、どう行動するか」（heuristics + normative constraints）。
- プロトコルは明確に分離（ユーザーへの報告形式、エージェント間手渡しルール、ツール呼び出し契約）。

**（4）Governance & Safety（これが差別化要因）**
- 破壊的アクションは必ず承認ゲート。
- 役割分離（決定する役割と実行する役割を分ける）。極端な例では14役割に分離して「1コンポーネントが決定と実行を同時にしない」設計も登場。
- ポリシー違反時は即座にロールバック可能な設計。

**（5）Evaluation Layer**
- 最終回答だけでなく**Trajectory評価**（過程も含めた評価）が必須。
- Autorubricや自動テストスイートをループ内に組み込む。
- 自己改善ループ（測定 → ハーネス調整 → 再実行）を閉じる。

### 4. 設計思想のスペクトラム（重要な意思決定）

- **Thin Harness（Anthropic寄り）**: モデルを信頼してシンプルなループに任せる。将来的にモデルが賢くなればハーネスを削れる設計。
- **Thick Harness（LangGraph寄り）**: 制御フローを明示的にコード/グラフで書く。信頼性とデバッグ性を最優先。
- **Hybrid（CrewAI寄り）**: 重要な部分はFlow（確定ロジック）、自律部分はCrewに任せる。

**推奨**: 最初は **Thick寄りで始めて**、モデルが進化したら徐々に削っていく（Scaffolding as removable）。モデルは特定のハーネスで学習されている場合が多いので、安易に全部削ると性能が落ちる。

### 5. 実装選択肢（2026年現在）

- **LangGraph**：最も成熟した「厚いハーネス」を作りやすい。
- **CrewAI + Flows**：生産性が高い。
- **Custom Minimal Harness**：多くのトップエンジニアが「教育目的でゼロから作る」動き（Akshayらの動きが影響大）。
- **Meta-Harness（Omnigentなど）**：Claude Code / Cursor / Codex / 自作エージェントを統一的にオーケストレーションし、ハーネスをスイッチ可能にするレイヤー。
- Observability：Phoenix（Arize）、LangSmith、OpenTelemetryを必ず入れる。

### 設計時に考えるべき質問（チェックリスト）

1. この機能はモデルの中に持つか、ハーネス（Memory/Skills/Protocols）に外部化するか？
2. モデルが「完了」と言ったら本当に信用できるか？（→ Ralph Loopが必要か）
3. ハーネスを1年後に薄くできる設計になっているか？
4. 同じモデルでもハーネスを変えたら性能が劇的に変わるポイントはどこか？
5. observabilityが十分で、なぜ失敗したかが1分でわかるか？

---

この領域は現在も急速に進化しています。特に**「ハーネスベンチマーク」**（ハーネス自体の質を測る指標）の議論が活発です。

具体的にどの部分を深掘りしたいですか？

- 具体的なコードアーキテクチャ（LangGraphでの実装例）
- Ralph Loopの詳細設計
- 多役割分離（14 roles）パターン
- 企業内導入時のガバナンス設計
- 記憶層の具体的な実装

用途（コーディングエージェント、業務自動化、研究用など）を教えていただければ、より尖った設計をお伝えできます。