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

2026年現在、AIエージェントの性能を決める最大の要因は「モデルそのもの」ではなく、「ハーネス（Harness）」です。これは**馬具（手綱）**のメタファーで、AIの強大な能力を「制御し・方向づけ・安全に活用するための足場・仕組み」の総称です。[[1]](https://x.com/tetumemo/status/2037876018745385083)

プロンプトエンジニアリング → コンテキストエンジニアリング → **ハーネスエンジニアリング**という進化が起きています。特に長時間稼働するコーディングエージェントや自律エージェントでは、ハーネス設計の善し悪しが成果を劇的に変えます（例: LangChainチームはハーネス改善だけでTerminal BenchでTop30圏外→Top5に躍進）。

### ハーネスとは何か？（4層モデル）

エージェントは基本的に「whileループ＋LLM呼び出し」です。これを4つのレイヤーで包む考え方が現在主流です：

1. **Prompt Engineering** — 1回のLLM呼び出しで何を言わせるか
2. **Context Engineering** — そのターンで見せる情報全体（記憶、ツール出力、過去履歴）の最適化
3. **Harness Engineering** — **モデル周りの実行基盤**（これが本題）
4. **Loop Engineering** — 外側の自律ループ全体の管理（停止条件、進捗検知、長期コンテキスト劣化対策）

ハーネスは特に第3層に該当し、「モデルはCPU/エンジン、ハーネスはOS/車」という表現がよく使われます。[[2]](https://x.com/NainsiDwiv50980/status/2073291641943957618)

### ハーネスの本質的なアーキテクチャ（2026年現在のコンセンサス）

優れたハーネスは**モデルを薄く（thin）保ち、知能を外部化**します。中心にモデルを置き、周囲を以下の4要素で取り囲む設計が有力です：

- **Memory（記憶）**
- Working Context（現在進行中のタスク状態）
- Semantic Memory（事実・知識、RAG）
- Episodic Memory（過去の経験・エピソード）
- Procedural Memory（「どうやるか」の手順）

- **Skills（技能）**
- ツール定義
- 意思決定ヒューリスティック
- Normative Constraints（「やってはいけないこと」のルール群）

- **Protocols（プロトコル）**
- Agent ↔ User
- Agent ↔ Agent（マルチエージェント連携）
- Agent ↔ Tools

- **Mediators（仲介層）** ← **ここが最も重要**
- Sandboxing（サンドボックス実行）
- Observability（完全トレーシング）
- Evaluation / Verification（別エージェントによる評価）
- Approval Loops（人間承認フロー）
- Sub-agent Orchestration
- Compression（コンテキスト圧縮）

### 設計原則（これを守らないと失敗する）

1. **Maker-Checker Separation（作成者と評価者を分離）**
最大の落とし穴は「AIに自分の成果物を自己評価させる」こと。必ず**別エージェント**（Verifier/Critic）を作り、ルーブリック（評価基準表）で機械的に評価させる。

2. **Rubric-based Evaluation**
「良いデザインか？」のような主観はAIに直接聞かない。「我社のデザイン原則10項目をすべて満たしているか？」のように具体的なチェックリストに変換する。

3. **Scaffolding Designed to be Removed**
モデルが賢くなるほどハーネスを薄くしていく（Anthropicは積極的に計画ステップを削除している）。しかし、モデルは特定のハーネスで訓練されている場合が多いので、急に全部外すと性能が落ちる。

4. **Explicit vs Implicit Controlの選択**
- **厚いハーネス**（LangGraph推奨）：状態を明示的なグラフ（State Machine）で定義。全決定点をコードで制御。
- **薄いハーネス**（Anthropic寄り）：シンプルなReActループに任せ、モデルに多くを決めさせる。

### 実践的な設計手順（おすすめ順）

**Phase 1: 基盤設計**
- 成功基準を**ルーブリック**として完全に言語化（これが最も時間を使うべき作業）
- 状態機械を設計（Planning → Tool Selection → Execution → Reflection → Verification → Termination）
- ツールごとにPermission Level（Read / Write / High Risk）を定義

**Phase 2: 安全・制御レイヤー**
- Pre-LLM Guard（入力検証、Prompt Injection対策）
- Post-LLM Guard（出力スキーマ検証、危険コマンドブロック）
- Behavioral Guard（長期異常行動検知）
- Budget Guard（トークン・コスト・時間の上限）

**Phase 3: 評価・観測性**
- 独立したEvaluator Agentの構築
- 完全なトレーシング（LangSmith, Phoenix, OpenTelemetry）
- Human-in-the-Loopの挿入ポイント設計
- 長期実行のためのContext Rot対策（要約、外部ファイル化、階層的記憶）

**Phase 4: スケーリング**
- Sub-agent化（専門エージェントへの委譲）
- イベント駆動アーキテクチャへの移行
- ハーネスのモジュール化（Policy Engine, Approval Layerなどをswap可能に）

### 技術的おすすめスタック（2026年）

- **最強基盤**: **LangGraph**（状態管理・チェックポイント・人間介入が抜群）
- 組み合わせ例: LangGraph + Guardrails + DSPy（最適化） + Outlines（構造化出力）
- 観測性: LangSmith or Helicone + OpenTelemetry
- 評価: 専用Critic Agent + ルーブリック + 自動テスト実行

### 最後に：これからの勝負所

モデル性能が頭打ちに近づく中、**「どんな環境（ハーネス）でAIを動かすか」**が競争優位性になります。特に企業内では「自社特有のハーネス（自社のルール・ワークフロー・品質基準を完全にコード化したもの）」が、AIネイティブな業務プロセスそのものになっていきます。

ハーネス設計は「プロンプトを書く」レベルではなく、「AIのためのオペレーティングシステムを設計する」レベルです。

必要であれば、具体的なユースケース（コーディングエージェント、RAGエージェント、カスタマーサポートエージェントなど）に合わせた詳細アーキテクチャ図やLangGraphの実装テンプレートも提供できます。どのようなエージェントのハーネスを設計したいですか？