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

2026年現在、AIエージェント（特に長時間稼働するコーディングエージェントや自律エージェント）の設計において、最も重要なレイヤーが「**ハーネス（Harness）**」です。プロンプトエンジニアリング → コンテキストエンジニアリングの次の段階として「**ハーネスエンジニアリング**」が注目されています。[[1]](https://x.com/tetumemo/status/2037876018745385083)

### ハーネスとは何か

**馬具（手綱・鞍）のメタファー**です。馬（＝強力だが制御しにくいLLM）の力を最大限に引き出しつつ、安全に目的地へ導くための仕組み全体を指します。

よく使われる比喩：
- **モデル = CPU**
- **ハーネス = OS**

モデルそのものは「賢い計算機」に過ぎず、**信頼性・持続性・品質・安全性を決めるのは周囲のハーネス**です。同じモデルでもハーネスが変わると、成功率やコストが5〜30倍変わるという報告もあります。[[2]](https://x.com/omarsar0/status/2084714744880173451)

実際のインパクト例：
- LangChainエージェントのハーネス改善だけでTerminal BenchでTop30→Top5に上昇
- OpenAI内部でCodexエージェントを使い、人間が1行もコードを書かずに5ヶ月で約100万行・1500PRのプロダクトを構築
- ある論文ではハーネス改善だけでSWE-bench系ベンチマークが6.7%→68.3%に跳ね上がった事例も

### ハーネス設計の核心原則

1. **Intelligence Externalization（知能の外部化）**
- モデルの中にすべてを詰め込まない
- Memory、Skills、Protocolsを明確に外部化

2. **Observability First & Friction Logging**
- すべての思考・行動・観測・失敗を構造化ログ
- 「小さな行き止まり」や「使えないツール呼び出し」も記録 → 3回同じパターンが出たらハーネス自体を改善

3. **Iterative Harness Evolution**
- 最初から完璧なハーネスを作らない
- 実際の運用ログからボトルネックを発見し、徐々に強化（これが最も効果的）

4. **Deterministic Boundaries**
- スコープ、受け入れ条件、停止条件を明確化
- 無限ループ防止、コスト制限、品質ゲートを強制

5. **「Humans steer, Agents execute」**
- 人間はゴール・制約・品質基準・介入タイミングを設計
- エージェントは実行と細かい改善を担当

### 推奨アーキテクチャ（2026年現在のベストプラクティス）

```
[Task & Goal Definition]
↓
[Harness Core (Orchestrator)]
├── Execution Loop Engine（ReAct / Plan-Execute / 自律ループ）
├── Persistent State Layer（推奨：永続IPython Kernelなど）
├── Memory System
│ ├── Working Memory（現在進行中のコンテキスト）
│ ├── Semantic Memory（知識）
│ ├── Episodic Memory（過去の軌跡）
│ └── Personal/Organizational Memory
├── Skill & Procedure Repository（操作手順・ヒューリスティック・制約）
├── Protocol Layer（Agent-User / Agent-Agent / Agent-Toolの契約）
├── Mediator Layer
│ ├── Sandbox & Security
│ ├── Observability & Tracing
│ ├── Evaluation & Verification（Rule + LLM Judge + Human）
│ ├── Compression & Context Management
│ └── Human-in-the-Loop Gate
└── Self-Improvement Loop（摩擦ログ→ハーネス更新）
↓
[Environment / Tools（最小主義が最近のトレンド）]
```

**最近の有力アプローチ（Prime Agentなど）**：
- 無数のツールを定義するのではなく、「**永続的なIPython Kernel 1つだけ**」をツールとする
- モデル自身に「履歴をコードで検索させる」「サブエージェントをプログラム的に起動させる」「状態をREPL外に永続化させる」という設計
- 長時間セッションを「プログラミング問題」として扱う思想が非常に有効です。[[3]](https://x.com/airiaiai8/status/2085305290921234599)

### 設計時に特に注力すべきポイント

- **Friction Logの設計**：エージェントが「報告しにくい小さな失敗」を1行で残せる窓口を作る。これがハーネス改善の最強の燃料になります。
- **Skill Loading Mechanism**：関連する手順書・制約・ベストプラクティスを適切なタイミングでコンテキストにロードする仕組み（Skill-load rate / Harness-following rateで評価）。
- **Evaluationの多層化**：単なる最終結果評価ではなく、Skill Selection → Invocation → Interpretation → Execution → Validationの各段階を評価。
- **Sandboxの強度**：特にコーディングエージェントではDocker + 権限制限 + ネットワーク制御が必須。

### 実装を始めるおすすめ順序

1. 最小ハーネス（シンプルReAct + 構造化ログ + 停止条件）を作る
2. 摩擦ログ機構を追加して1週間運用
3. ログから繰り返しパターンを抽出し、Skill/Procedureとして外部化
4. Persistent State（永続カーネルやDB）を導入
5. Evaluation & Human Gateを強化
6. Self-evolving的なハーネス更新ループを追加

このアプローチで、最初は「賢いモデルに頼る」状態から、徐々に「賢く回る仕組み」にシフトできます。

---

もっと具体的に知りたい部分を教えてください：

- **コーディングエージェント特化**のハーネス設計
- Prime Agent風の**永続IPython Kernel**中心アーキテクチャの詳細
- 実際の**コード構造例**（Python）
- Anthropicの公式ハーネス設計論文の深掘り
- 評価指標の具体的な設計方法
- マルチエージェント向けハーネス

用途（社内ツール開発、プロダクト構築、研究用ベンチマークなど）も教えていただけると、より的確な設計を提案できます。