**AIエージェント ハーネス設計（Harness Engineering）完全ガイド**

2026年現在、「ハーネス設計」は**Prompt Engineering → Context Engineeringの次のレイヤー**として、日本国内外で最も重要なテーマの一つになっています。モデルそのものより「モデルを動かす環境（足場）」の設計が、信頼性・安全性・長期運用性能を大きく左右します。[[1]](https://x.com/tetumemo/status/2037876018745385083)

### 1. ハーネスとは何か

**ハーネス（Harness）** = 馬具（手綱・鞍）のメタファー。

- **モデル = CPU / 馬の力**
- **ハーネス = OS / 馬具一式**

モデルがどれだけ賢くても、適切に制御・観測・修正・評価する仕組みがなければ本番では使い物になりません。特に**長時間稼働するコーディングエージェントや自律型エージェント**では、ハーネスの品質が性能の大部分を決めることが実証されています（Terminal-Benchでの劇的な順位向上事例や、OpenAI社内での「人間が1行もコードを書かずに100万行生成」事例など）。[[2]](https://x.com/i/status/2023008135464788127)

**核心哲学**: 「**Harness is the Product**」
価値の源泉はモデルではなく、ハーネス（外側のシステム）にある。

### 2. ハーネス設計の主要構成要素（2026年標準）

優れたハーネスは以下の6つのレイヤーで構成されます：

1. **Tool Registry + Context Management Primitives**
- ツールの登録・権限管理・スキーマ検証
- 「必要な地図だけ段階的に渡す」コンテキスト制御（全情報を一気に渡さない）

2. **Agent Loop + Guardrails**
- Inner Loop（エージェントの推論サイクル）
- Outer Loop（ハーネスが監視・介入する外側ループ）
- Max Steps、コスト予算、タイムアウト、Hallucination Loop検知

3. **Observation Cleaning Layer**（非常に重要）
- 生のターミナル出力、ブラウザ結果、ログをそのままAIに渡さない
- ノイズ除去・重要情報抽出・要約を行う中間層
- これがないと「幻覚ループ」に簡単に陥る

4. **Verification & Review Layer**
- 「作るエージェント」と「評価するエージェント」を明確に分離（自己評価バイアス対策）
- ルーブリック化された評価基準（「美しいか？」ではなく「設計原則に準拠しているか？」）
- 複数回のセルフレビューループ

5. **Memory & State Management**
- Checkpointing（途中保存・復元）
- 短期記憶・長期記憶・ナレッジの適切な引き継ぎ
- グラフ構造メモリやベクトル+構造化データの組み合わせ

6. **Observability + Eval Harness**
- OpenTelemetry準拠の完全トレーシング
- コスト追跡・パフォーマンス計測
- 自動評価パイプライン（LLM-as-Judge + 人間評価のハイブリッド）

### 3. 設計原則（Anthropic・OpenAIの実践から）

- **環境設計 > モデル能力**：進捗が遅い原因のほとんどはモデルではなくハーネス
- **Humans steer, Agents execute**：人間はゴール・制約・品質基準を設定し、エージェントに実行させる
- **Observation Cleaningを必ず入れる**：これが最も地味で最も効果的な改善点
- **Inner LoopとOuter Loopを明確に分離**：Outer Loopが異常を検知して介入
- **Rubric化**：主観的な品質も評価可能な形式に落とし込む
- **失敗を学習ループに組み込む**：単発ではなく、反復改善を前提にした設計

### 4. 推奨アーキテクチャパターン

**最も実践的な選択（2026年）**：

**A. LangGraph中心パターン（推奨）**
- 状態遷移をグラフとして定義
- チェックポイント機能で堅牢な永続化
- LangSmith/LangFuseで強力な可観測性
- Outer LoopをSupervisorエージェントとして実装

**B. カスタムLoop Engineeringパターン**
- asyncio + Pydanticで軽量に構築
- Inner/Outer Loopを明示的に2レイヤーで実装
- 専用Observation Cleanerを挟む
- AgentCoreや独自のManaged KBと組み合わせ

**C. Multi-Agent Hierarchical Harness**
- Planner → Executor → Critic → Verifierの階層構造
- 役割を明確に分離したSkill/Sub-agent/Hook/ナレッジのパッケージ化

### 5. 設計時に必ず決めるべきこと（チェックリスト）

- 成功の定義（何をもってタスク完了とするか）をルーブリック化
- 人間の介入ポイント（承認が必要な destructive action）
- コスト予算と早期停止ロジック
- Observation Cleaningの方針（何を抽出・削除するか）
- レビュー担当エージェントの分離方法
- 長期記憶の更新戦略（何をいつどのように保存するか）
- 異常検知時のエスカレーション経路

### 実践アドバイス

- **最初に作るべきもの**：シンプルなOuter Loop + Observation Cleaner + 基本Guardrails
- **評価駆動開発**：ハーネスを作る段階から強力なEval Harnessを用意
- **「クライアントが複雑さを知らなくていい」設計**：裏側は複雑でも、利用者はシンプルに使えるようにする
- 非エンジニアでもハーネス的な思考（環境設計）が浸透してきている

ハーネス設計は「泥臭い」部分が多いですが、ここを磨いた組織とそうでない組織の差は今後ますます開いていきます。

具体的に「コーディングエージェント向け」「RAG中心の業務エージェント向け」「ブラウザ操作エージェント向け」など、**用途を教えていただければ、より具体的なアーキテクチャ図・コードスケルトン・構成例**をお出しできます。

どのようなユースケースのハーネスを設計したいですか？