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

2026年現在、AIエージェント開発の本質は「モデルを賢くする」ことではなく、「**モデル以外のすべて**」をエンジニアリングすることに移っています。これが**Harness Engineering**です。

### Harnessの定義
**Agent = Model + Harness**

- **Model**: LLM本体（知能）
- **Harness**: 手綱（制御）と鞍（安定）を含む「仕事用装備一式」。実行ループ、ツール、記憶、文脈管理、ガードレール、検証機構、監視、Hooksなどをすべて含む。

由来はHashiCorp共同創業者Mitchell Hashimotoによる命名で、「どんなに速い馬でも、手綱と鞍がなければ制御できない」という比喩です。哲学は明確です：

> 「モデルが間違えたら、モデルをアップデートするのではなく、**システムをエンジニアリングして二度と同じ間違いを起こさせない**。」

これはPrompt Engineering（2023）→ Context Engineering（2025）→ **Harness Engineering（2026）**という流れの最新段階です。[[1]](https://x.com/chenchengpro/status/2037332209003282747)

### 推奨アーキテクチャ：5層ハーネス + Meta Layer

#### 基本5層構造
1. **ガードレール層 (Safety & Policy Layer)**
2. **文脈・記憶管理層 (Context & Memory Engine)**
3. **ツール指揮層 (Tool Orchestration & Permissioning)**
4. **検証・ループ制御層 (Verification & Self-Correction Loop)** ← 最も重要
5. **監視・可視化層 (Observability & Telemetry)**

#### 上位Meta Layer：Harness of Harness (HoH)
既存ハーネスの外側に「**Planner → Developer → Independent QA**」のループを置くメタハーネス。上海人工知能実験室の研究で特に有効性が示されています。成功/失敗の「証拠(Evidence)」を次のループに引き継ぐのが特徴です。[[2]](https://x.com/itarutomy/status/2095346046104674736)

### 各層の詳細設計

**1. ガードレール層**
- Input Guard：Prompt Injection検知、Intent Classification
- Output Guard：LlamaGuard/WildGuard、PII検知、毒性・ハルシネーション検知
- Hard Rules：`CLAUDE.md`形式で**60行以内の不変ルール**のみ記述（AI生成ルールは性能を落とす傾向あり）

**2. 文脈・記憶管理層**
- **Skills**：漸進的知識開示（必要なスキルだけそのタイミングで注入。コンテキストを汚さない）
- Episodic Memory + Evidence Store（「このパターンは成功」「この検証結果は回帰」などを構造化して保持）
- Context Firewall：Sub-agentを使う場合はコンテキストを明確に分離（長コンテキストでの性能劣化対策）

**3. ツール指揮層**
- Tool Permission Matrix（役割ベース + 危険度別承認フロー）
- ツール数は**同時に3つ以内**を強く推奨（"tool thrash"防止）
- Sandbox実行（code interpreter、shell、networkアクセスは特に厳格に）

**4. 検証・ループ制御層（最重要）**
- **Hooks/Middleware**：Pre-Action、Post-Action、Pre-Completion Checklist
- Loop Breaker：同じツール・同じ引数を繰り返したら即座に停止
- Self-Correction：LLM-as-Judgeや多角的検証
- Retry Policy + Evidence-based Backoff

**5. 監視・可視化層**
- OpenTelemetry準拠のトレーシング（Thought → Action → Observationの全軌跡）
- メトリクス：Cost, Latency, Tool Calls, Safety Violation Rate, Success Rate, Trajectory Quality
- ツール：LangSmith / LangFuse / Arize Phoenix / OpenLLMetry

### 実装のベストプラクティス

- **最強フレームワーク**: **LangGraph**（状態機械 + Checkpoint + Human-in-the-loop + 再開性・監査性が抜群）
- **設計原則（ハーネス肥大化対策）**:
- 変更容易性の優先順位を明確にする（Gota氏の資料が非常に参考になります）
- Policy as Code化（宣言的ルール管理）
- 定期的なHarnessリファクタリング必須

- **人の役割の変化**（LayerX CTO 松本勇気氏の指摘）:
デザイナー → 「デザインを作るAgentのHarnessを作る」
QA → 「品質ガードレールを定義する」
セキュリティ → 「セキュリティポリシーをAgentに埋め込む」
これが究極のシフトレフトです。[[3]](https://x.com/i/status/2045652204154139095)

### 設計時のチェックリスト

- 同じ失敗を**二度と繰り返さない**仕組みがあるか？
- 無限ループを確実に検知・停止できるか？
- 人間がいつでも介入・修正・再開・監査できるか？
- すべての決定に「なぜそう判断したか」の証拠が残るか？
- Harness自体が複雑化しすぎていないか？（メタハーネスで制御）

### 参考資料・事例

- OpenAI Codexチーム：5ヶ月で人間の手を一切入れず約100万行（1500 PR）の社内プロダクトをAgentだけで構築
- Gota氏のSpeakerDeck：「無駄にハネスの設計 〜ハネスの変更容易性を高めるための優先順位〜」
- Shanghai AI LabのHarness-of-Harness (HoH)研究
- deepseek-harness（オープンソースのAgent runtime）

---

この設計で作れば、「たまに賢く動くおもちゃ」ではなく、「**信頼できる業務システム**」としてのAIエージェントが実現できます。

具体的に以下のどれかが必要でしたら深掘りします：
- LangGraphを使った具体的なコード例
- Coding Agent / Research Agent / 業務プロセスAgent別の設計
- ハーネス肥大化対策の詳細パターン
- Evaluation Harness（自動評価システム）の設計

どの方向で進めましょうか？