**AIエージェント ハーネス設計（Harness Engineering）2026年現在のベストプラクティス**

「AIエージェント ハーネス設計」は、2026年現在最も重要なトピックのひとつです。モデル性能自体よりも、「エージェントを取り巻く制御機構（ハーネス）」の質が成果を2倍以上変えることが複数の実証研究・実務で確認されています。OpenAIの社内事例（人間がほぼコードを書かずに100万行規模のプロダクトをエージェントだけで構築）、Anthropicの長時間実行に関する議論、LangChain Labsや日本のコミュニティ（@gota_bara氏の資料など）で急速に体系化されています。

ハーネスとは、馬具（horse harness）の比喩で、「生のモデル（馬）の力を適切に制御・方向づけ・増幅する仕組み一式」です。目的は「人間がステアリング（方向・制約・品質基準）を握り、エージェントが実行する」状態を安定的に実現することです。

### 1. 設計の基本原則

- **失敗を二度と起こさせない工学**：エージェントがミスしたら、手作業で直すだけでなく、ハーネスにルール・チェック・仕組みとして永久に組み込む（Mitchell Hashimoto流）。
- **Context is King**：コンテキストウィンドウを汚染しない。不要な情報を入れず、常にクリーンに保つ。
- **Data-Driven Iteration**：Evals、トレース、指標（成功率、トークン効率、コスト、レイテンシ）を徹底的に集めてハーネスを改善。
- **Thin vs Thick**：フロンティアモデル（高性能）には薄いハーネス、企業向け長時間タスクには厚いハーネス。
- **Progressive Disclosure**：全知識を最初に与えず、必要に応じてスキル・ルールをロード。
- **Short Feedback Loops**：長大な自律ループではなく、「Reason → Act → Verify → Adjust」の短い検証可能ループを重視。
- **Maintainability First**（特に重要）：ハーネスが肥大化すると変更が困難になる。優先順位付けとモジュール化が必須（@gota_bara氏のSpeakerDeck参照）。

### 2. 推奨アーキテクチャ

```mermaid
graph TD
subgraph Control Plane [Control Plane]
Rules[Rule Layer\n(CLAUDE.md / HARNESS_RULES.md)]
Policy[Policy Engine\n(Guardrails, Permissions)]
Orchestrator[Orchestrator\n(Main Loop + Sub-agent Spawner)]
end

subgraph Memory Plane [Memory Plane]
Persistent[Persistent FS\n(progress.md, logs, artifacts)]
Semantic[Semantic Memory\n(Vector DB)]
Working[Working Context\n(自動要約 + クリーンアップ)]
end

subgraph Execution Plane [Execution Plane]
Tools[Tool Layer\n(MCP / Limited Tools ≤3)]
Subagents[Sub-agents\n(Context Firewall)]
Executor[Executor\n(ReAct / Plan-Execute-Verify)]
end

subgraph Observation Plane [Observation Plane]
Hooks[Hooks & Middleware\n(Pre-check, Linter, Checklist)]
Eval[Eval & Metrics]
Observability[Observability\n(Trace, Log, Anomaly Detection)]
Meta[Meta-Harness\n(自己改善提案)]
end

Control Plane --> Execution Plane
Memory Plane <--> Execution Plane
Execution Plane --> Observation Plane
Observation Plane --> Control Plane
```

**4レイヤー構造**を基本とします：
- **Control Plane**：硬いルールと全体統制
- **Memory Plane**：永続性とコンテキスト衛生管理（最も重要）
- **Execution Plane**：実際の行動と並列化
- **Observation Plane**：観測・検証・自己改善（これがハーネスの進化エンジン）

### 3. 各レイヤーの詳細設計

**Rule Layer（最も基礎）**
- 専用ファイル（`HARNESS_RULES.md` または `AGENT_SPEC.md`）に60行以内で硬いルールのみ記述。
- 品質基準、禁止事項、ドメイン知識、完成条件（binaryで明確に）を記載。
- AI自身に生成させず、人間が慎重に保守（研究でAI生成ルールは性能低下を招くケースが多い）。

**Memory & Context Layer**
- **Persistent Filesystem**を第一級市民に：`progress.md`、`status.json`、`decision_log.md` を必ず読み書きさせる。
- コンテキストはサブタスクごとにリセット・要約。
- スキルはモジュール化（Skillportのような仕組み）してon-demandロード。
- 1エージェント1ワークツリーで並列実行時の競合を防止。

**Tool & Capability Layer**
- 同時に有効にするツールは3つ以内に制限（tool thrashing防止）。
- MCP（Model Communication Protocol）や類似規格で標準化。
- 権限モデルを厳格に：読み取り/書き込み/外部API/破壊的動作ごとに承認ゲートやサブエージェント分離。

**Orchestration & Loop Layer**
- 基本ループ：Plan → Execute → Observe（verify）→ Reflect/Adjust。
- Sub-agentは「コンテキストの防火壁」として活用。メインは思考をクリーンに保ち、重い作業を委譲。
- 長時間実行向けには状態永続化とチェックポイント必須。

**Observation & Self-Improvement Layer**
- あらゆる行動にHooksを挿入（編集時Linter、完了前Checklist、セキュリティスキャン）。
- 完全なトレーサビリティ（OpenTelemetry互換）。
- 評価指標を自動収集し、ハーネス改善提案まで行わせる（Meta-Harness）。
- 最終的に「Harness Engineering → Post-Training/Fine-tuning → Harness Engineering」のサンドイッチで継続改善。

### 4. 実装時のベストプラクティス（肥大化対策）

- ルールは「硬いルール」と「スキル」に明確に分離。
- ハーネス自体をバージョン管理し、変更容易性を最優先評価指標にする（@gota_bara氏資料の優先順位が参考になる）。
- Evalsを最初に設計。トレースを徹底的に分析して「どこでコケているか」を特定してからハーネスを修正。
- モデルごとに最適ハーネスが異なる（Model-Harness-Task fit）。プロファイル機能で切り替え可能に。
- 企業ユースでは「Human-in-the-Loopの適切な配置」（承認が必要なポイントのみ）が鍵。

### 5. 具体例：Software Engineering Agentの場合

- `PRODUCT_SPEC.md` で意図を構造化（Gokul RajaramのProductSpec風）。
- 編集時は即時Linter + 構文チェック。
- 進捗は必ず`progress.md`に書き、セッション跨ぎで読み込む。
- テスト失敗時は自動的に失敗パターンをルールに追加提案。
- Sub-agentで「調査用」「実装用」「検証用」を分離。

これにより、同じモデルでもベンチマーク成績が42%→78%になるような差が出ます。

### 参考・さらに深掘りしたい場合

- @gota_bara氏のSpeakerDeck「無でハーネスの設計」（ハーネス肥大化対策に最適）
- awesome-harness-engineering リポジトリ（アーキテクチャ・評価・参考実装集）
- LangChain Labs Viv氏のノート（Evals駆動型ハーネス構築）
- arXiv論文（HexStrike-AIによるHarness比較、効率化に関する2026年論文）

ハーネス設計は「一度作って終わり」ではなく、週次で失敗をルール化していく継続的プロセスです。最初はシンプルなRule + Persistent Memory + Short Loopから始め、トレースを見ながら徐々に厚くしていくのがおすすめです。

具体的なユースケース（例：コード生成、業務自動化、研究エージェントなど）や、特定のレイヤーのより詳細な設計（Mermaid拡張やコード例）が欲しい場合は、教えてください。すぐに深掘りした設計書を作成します。