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

2026年現在、「AIエージェント ハーネス設計」はAIエンジニアリングで最も重要なテーマの一つです。モデル性能がコモディティ化する中で、同じモデルを使っても**ハーネス（実行環境・統治機構）の質で性能が2倍近く変わる**事例が多数報告されています。

### ハーネスとは何か？

「Harness（馬具）」という言葉通り、AI（馬）の力を**制御・方向づけ・安全に活用するための装備一式**です。

- 単なるプロンプトやツール統合を超える
- ルール、スキルファイル、ツール契約、フィードバックループ、ガードレール、メモリ管理、検証機構などを含む**実行基盤全体**
- 核心哲学：「エージェントがミスしたら、モデルを祈るのではなく、システムをエンジニアリングして**同じクラスのミスを二度と繰り返さない**ようにする」（Mitchell Hashimoto風）

これはPrompt Engineering（2023）→ Context Engineering（2025）の次の段階で、**Harness Engineering（2026）**と呼ばれています。[[1]](https://x.com/chenchengpro/status/2037332209003282747)

### なぜ重要か？

- 同じモデル・同じベンチマークで、harnessを変えるだけで42% → 78%という劇的な改善例が報告されている
- OpenAIのCodexチームが人間が1行も書かずに100万行のコードを生成した事例も「Agent-first + Harness Engineering」
- ハーネスは**組織固有**で模倣しにくい（自社のコードベース・失敗履歴・ドメイン知識が蓄積されるため）

### ハーネス設計の5大構成要素（主要レバー）

1. **System Prompts / Hard Rules**（CLAUDE.mdなど）
- 60行以内に硬いルールだけを書く
- AIが生成した曖昧なルールは性能を落とす傾向がある

2. **Skills（スキル）**
- 手順・判断基準・ドメイン知識をモジュール化
- **Progressive Disclosure**（必要なタイミングでだけ読み込む）
- コンテキストを汚染しない

3. **Tools / MCP Servers**
- 同時に3つ以内に抑える（Tool Thrashing防止）
- 明確な契約（input/output schema、permission level）

4. **Sub-agents（サブエージェント）**
- 役割分離ではなく**コンテキストの防火壁**として使う
- 長時間タスクを委譲して主スレッドのコンテキストをクリーンに保つ

5. **Hooks & Checkpoints**
- ワークフロー关键点での確定性チェック（PreCompletionChecklistなど）
- これが最もイン��クトが大きい改修であるケースが多い

これらに加えて重要なのが**Memory Architecture**（反射的メモリ、永続的progressファイル、stale memory検証）と**Trajectory Regulation**（暴走・無限ループ防止）です。[[2]](https://x.com/i/status/2037332209003282747)

### 設計原則（特に重要）

- **Failure-Driven Evolution**：毎回の失敗をharnessにencodeする文化を作る（週次レビュー推奨）
- **Context Minimalism**：無駄なトークンを徹底的に排除（サマリ化、persistent file活用、live state検証）
- **Explicit Contracts Everywhere**：成功基準はbinary（曖昧にしない）、環境契約（environment contracts）を明確化
- **Modularity & Changeability**：ハーネスが肥大化した時の変更容易性が命
- **Defense in Depth**：Permission budget、人間承認ゲート、sandbox、監視分類器を多層で
- **Retrospective Harness Optimization (RHO)**：過去のtrajectoryを分析してharness自体を自律的に改善

**ハーネスが肥大化した時の優先順位**については、Findyの@gota_baraさんのSpeakerDeckが非常に参考になります。ハーネスの変更容易性を高める頭の使い方・優先順位が整理されています。
→ https://speakerdeck.com/gotalab555/mu-de-huasutonohanesushe-ji-hanesunobian-geng-rong-yi-xing-wogao-merutamenoyou-xian-shun-wei

### 推奨アーキテクチャ（2026年現在）

- **Core Runtime**：Stateful Graph / State Machine（LangGraphが最も成熟）
- **Mediation Layer**：Hooks、Guardrails、Verification Middleware、LLM-as-Judge
- **Knowledge Plane**：Modular Skills + Multi-tier Memory（Working / Semantic / Episodic）
- **Governance Layer**：Token Budget、Step Limit、Human-in-the-Loop Escalation、Trajectory Monitor
- **Learning Loop**：Failure Mining → Harness Intervention提案（Life-Harness論文で88.5%相対改善の報告あり）

**実装パターン例（簡易）**：
- すべてのTool Call前にPermission & Budget Check
- Action実行後に必ずVerification Loop（binary success criteria）
- 長時間タスクはSub-agentに委譲 + 成果物のみ主agentに戻す
- 定期的にRetrospective Analyzerがtrajectoryをレビューして「この失敗クラスを防ぐ新しいHook/Skill」を提案

### おすすめリソース（2026年6月時点）

- **awesome-harness-engineering**（GitHub）：アーキテクチャ、原則、参考実装がまとまっている
- @gota_baraさんの資料（上記SpeakerDeck）
- Life-Harness論文（arxiv:2606.19380） — 失敗trajectoryからharness interventionを自動生成する手法
- LayerX CTO松本勇気さんの考察（役割変化についてのスレッド）
- Martin Fowler周辺の「Harness Engineering for Coding Agents」関連記事

ハーネス設計の本質は「**モデルを賢くするのではなく、モデルが置かれる環境を賢くする**」ことです。最初は小さく始め（基本的なHooks + Skills + ログ）、実際の失敗を積み重ねながら成長させるのが最も効果的です。

具体的なユースケース（コーディングエージェント、業務自動化エージェント、研究エージェントなど）で設計を深掘りしたい場合は、詳細を教えてください。実際のコードスケルトンや特定のレイヤーの設計もお手伝いできます。