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

2026年現在、AIエージェント開発の主戦場は「モデルをどう使うか」から「モデルをどう取り巻くシステムを設計するか」に完全に移っています。これが **Harness Engineering（ハーネスエンジニアリング）** です。

### Harness（ハーネス）とは

馬具（手綱・鞍など）の意味から来ており、**「馬（エージェント）の力を制御し、目的の方向に有効に引き出すための装備一式」** を指します。

具体的には：
- LLM（脳）の周囲を囲む「体」や「実行環境」
- ツール連携、記憶管理、ガードレール、フィードバックループ、状態永続化、可観測性、統治機構などの総体

同じモデル・同じ温度・同じプロンプトでも、ハーネスが変われば性能が劇的に変わります（実例：42% → 78%）。モデルがコモディティ化する中、差別化の源泉はここにあります。[[1]](https://x.com/chenchengpro/status/2037332209003282747)

### 3層モデル（推奨フレームワーク）

エージェントを「ひとつのもの」として語るのは誤りです。以下の3層に分けて設計してください：

1. **ハーネス層（環境）** — 「動かせるようにする」
2. **ループ層（フィードバック）** — 「繰り返して改善できるようにする」
3. **グラフ層（流れ）** — 「複雑なプロセスを明示的に統制する」

覚え方：**環境 → フィードバック → 流れ**。[[2]](https://x.com/_moto___/status/2084765121180848368)

本クエリでは主に**ハーネス層の設計**に焦点を当てます。

### ハーネス設計の6大要素

生産レベルで使えるハーネスは、以下の6要素をすべて含むべきです。

**1. コンテキスト注入層**
- `CLAUDE.md` や `AGENTS.md` などのシステムプロンプトファイル（**60行以内に硬いルールのみ**）
- Skills（漸進的知識開示）：最初から全部詰め込まず、必要に応じてロード
- RAG + 長期記憶 + ドメインポリシー + タスク固有ルール
- **設計原則**: AIにプロンプトを作らせない。人間が「これだけは絶対守れ」という硬いルールを最小限に書く。

**2. アクション面（Tool System）**
- ツールレジストリ（自然言語記述 + JSON Schema + 権限情報）
- MCPサーバーなどのツール拡張機構（2026年時点の標準化の動き）
- Sandboxed Executor（コード実行、ブラウザ、API呼び出し）
- **重要ルール**: 同時に使うツールは**最大3つ程度**に抑える（tool thrashing防止）

**3. 永続化・状態管理層**
- チェックポイント（中断・復帰可能）
- 階層的メモリ（短期会話 + ベクトル + グラフ + ファイルシステム）
- 生成物（artifact）のバージョン管理（git-like）
- セッション間・チーム間での状態引き継ぎ

**4. 実行制御層（Control Plane）**
- Retry + exponential backoff + timeout
- 予算ガード（トークン/金額）
- Human-in-the-Loop承認ゲート
- Sub-agent生成（コンテキスト防火壁として機能）
- モデルルーティング（タスクによって最適モデルを選択）

**5. 安全性・統治層（Safety & Governance）**
- 最小権限原則（Least Privilege）
- Input/Output Guardrails（プロンプトインジェクション、PII、違反行動ブロック）
- ポリシーエンジン（企業コンプライアンス）
- 監査ログ（誰が・何を・なぜ実行したか）

**6. 可観測性層（Observability-first）**
- 構造化トレース（Thought → Action → Observation の全履歴）
- 評価（LLM-as-Judge + 自動テスト + 人間評価）
- ダッシュボード（成功率、コスト、介入率、失敗パターン）
- **最重要**: 全てのtrajectoryを**再生可能**にし、週次レビューで「この失敗を二度と繰り返さない仕組み」をハーネスに組み込む

### 設計原則（これを守らないと意味がない）

- **"Every mistake is engineered out"** — 失敗したら「モデルが悪い」で終わらせず、ハーネスにルール・hook・チェックとして永続化する。
- 最小主義を徹底（コンテキストもツールも増やしすぎない）。
- 停止条件は「エージェントが終わったと言う」ではなく、**外形的な証拠**（テスト通過、スキーマ検証、レビュー承認など）にする。
- ハーネス自体が肥大化しないよう、モジュール化・抽象化を進める（@gota_bara氏の資料参照）。

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

- **コア**: LangGraph（状態管理が強い）または自前State Machine + Pydantic
- **LLM抽象**: LiteLLM
- **可観測性**: OpenTelemetry + LangSmith / Phoenix / Helicone
- **Sandbox**: E2B, Modal, Firecracker系
- **メモリ**: PGVector + Redis + ファイルシステム + Graph DB
- **Guardrails**: NeMo Guardrails系 or 自前Policy Engine
- **Hooks**: 重要なノードにdeterministic middlewareを入れる（これが意外と効く）

### 評価と改善サイクル

1. 実運用でトレースを大量に集める
2. 毎週失敗レビュー（5〜15分）
3. 各失敗に対して「どうすれば二度と起きないか」をハーネスにエンコード
4. A/Bテストでハーネス改善の効果を測定

これを回すと、モデルがアップデートされなくてもエージェントは週単位で強くなります。

### 参考資料（必読）

- @_moto___氏の詳細解説（ハーネス・ループ・グラフの3層を最も体系的に整理）
- @gota_bara氏の「無駄なハーネス設計」資料（Speaker Deck）
- @chenchengpro氏のHarness Engineering解説（英語だが本質を突いている）
- OpenAI Codexチームの事例（人間が1行も書かずに100万行規模のプロダクト構築）

必要であれば、さらに具体的な**コンポーネントごとのクラス設計**、**状態スキーマ例**、**LangGraphでの実装パターン**、**チェックリスト**も深掘りできます。

どのような粒度・用途（社内ツール、プロダクト組み込み、Coding Agent特化など）のハーネス設計をお探しですか？