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

2026年現在、「ハーネス設計」はPrompt Engineeringの次のレイヤーとして最も重要なテーマになっています。同じモデルを使っても、ハーネスの質で性能が大きく変わる時代です。

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

**ハーネス（Harness）**とは、AIエージェントを「安全に・安定して・再現性高く・制御可能に」動かすための**実行環境全体**のことです。

馬具（手綱・鞍）のメタファーから来ており、人間が**ゴール・制約・品質基準・停止条件**を決め（steer）、エージェントに実行させるという役割分担を表しています。

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

ループ（Plan → Execute → Verify → Iterateなど）はハーネス**内部の仕組みの一つ**に過ぎず、ハーネス自体がより広い概念です。

### 2. ハーネスに含めるべき主要要素

良いハーネスは以下のレイヤーで構成されます：

**Layer 0: Intent & Constraint Layer（意図固定層）**
- タスクの成功条件・品質基準・禁止事項・予算・最大ループ回数
- 人間が最初に明確に言語化・固定する部分（これが最も重要）

**Layer 1: Orchestration Layer（指揮系統）**
- Supervisor / Router（どのエージェントに何を任せるか）
- 役割分担（Planner, Worker, Reviewer, Verifier, Criticなど）
- Multi-agent構成の設計

**Layer 2: Execution Engine（実行エンジン）**
- 状態管理（State Graph推奨）
- ループ制御（ReAct, Reflection, Plan-and-Executeなど切り替え可能）
- Checkpointing（途中状態の保存・Time Travelデバッグ）
- 停止条件・早期終了ロジック

**Layer 3: Memory & Knowledge Layer（記憶層）**
- Hierarchical Memory（Working / Episodic / Semantic / Procedural）
- Reflective Memory（過去の失敗から学んだパターンを保存）
- コンテキストのガベージコレクション（不要な記憶の削除）

**Layer 4: Tool & Action Layer（道具・行動層）**
- Tool Schemaの厳密な契約（Environment Contract）
- 権限管理（ destructive actionは必ず確認）
- Action Realization（自然言語の意図 → 実際のツールコールへの変換）
- Sandbox実行

**Layer 5: Verification, Guardrails & Observability Layer（検証・安全・可観測性層）**
- LLM-as-Judge / Rubric-based Grader
- 安全性分類器（危険行動検知）
- 完全なトレーシング（思考過程・ツールコール・トークン消費・コスト）
- 失敗ログからの自動Harness改善（HarnessForge / Life-Harness的アプローチ）

### 3. 設計原則（優先順位）

ハーネスが肥大化してきたときの優先順位（Gotaさんらの知見より）：

1. **Steerability（操縦可能性）** — 人間がいつでも介入・方向修正できるか
2. **Observability（可観測性）** — 何が起きているか完全に理解できるか
3. **Safety & Controllability** — 暴走・破壊行動を防げるか
4. **Reproducibility** — 同じ入力で同じ軌跡を再現できるか
5. **Changeability** — ハーネス自体を変更しやすい構造か（これが崩れると地獄）

その他重要原則：
- **Environment beats Intelligence**（環境設計が知能を上回る）
- 失敗を「モデルの弱さ」ではなく「ハーネスとポリシーのミスマッチ」と捉える
- コスト意識（トークン予算、コンテキスト肥大防止）

### 4. おすすめ実装アプローチ（2026年現在）

**最強ベース**: **LangGraph**（または同等のState Graphアーキテクチャ）
- 状態を明示的にグラフで管理できるのが圧倒的に強い
- Checkpoint機能でデバッグが神レベル

**より本格的に作り込む場合**:
- Orchestration: Temporal.io または Celery
- State Store: Postgres + Redis
- Memory: PGVector / Qdrant + 階層化メモリ
- Guardrails: Pydantic + LM Guard / NeMo Guardrails
- Observability: LangSmith / Phoenix / 自前トレースシステム
- Evaluation: 自動評価ループ + 人間評価のハイブリッド

**先進的な方向**:
- HarnessForge型：失敗ログからハーネス自体を進化させるメタエージェント
- Reflective Memory + Procedural Skillの蓄積
- Cross-model transferableなHarness（弱いモデルで抽出した失敗パターンが強いモデルにも効く）

### 5. 設計時に必ず決めるべきこと（Checklist）

- 成功判定基準は何か？（誰が・どうやって判定するか）
- どの時点で人間にエスカレーションするか
- 最大トークン/コスト/ループ回数のガード
- 重要な行動（ファイル削除、APIコールなど）前の確認フロー
- 記憶の有効期限と重要度評価ロジック
- 失敗パターンの分類と対応（trajectory regulation）
- ログの粒度と可視化方法

---

ハーネス設計は「プロンプトを書く」から「AIが働く環境そのものを設計する」フェーズへの移行です。

これからの差別化要因は**「どれだけ良いハーネスを組めるか」**です。モデル性能はコモディティ化しつつあり、仕組みの設計力が真の競争力になっています。

必要であれば、特定のユースケース（コーディングエージェント、調査エージェント、業務自動化など）に特化した詳細設計も出せます。どのような場面でのハーネス設計を考えていますか？