**AIエージェント ハーネス設計（Harness Engineering）2026年最新アプローチ**

2026年現在、AIエージェントの実用化で最も重要なのは「モデルそのもの」ではなく「**Harness（ハーネス）**」です。
よく言われるようになった言葉でまとめると：

> **Agent = Model + Harness**

モデルは商品化されつつあり、同じ最先端モデルを使っても、ハーネスの質で性能が2倍近く変わります（同じモデル・同じベンチマークで42%→78%になった事例など）。[[1]](https://x.com/chenchengpro/status/2037332209003282747)

ハーネスとは、馬の手綱（harness）のように**エージェントの力を制御・方向づけ・安全に活用するためのシステム全体**を指します。プロンプトエンジニアリング（2023）→コンテキストエンジニアリング（2025）→**Harness Engineering（2026）**という進化の最終形です。

### ハーネス設計の核心原則

1. **「同じ失敗を二度と繰り返さない」エンジニアリング**（Terraform創業者Mitchell Hashimotoの哲学）
2. 人間の役割を「コードを書く」から「**ループと制約の設計**」へ移行（Humans steer, agents execute）
3. モデルに頼らず、**システムで品質・安全・効率を保証**する
4. 長期実行・生産利用に耐えうる**自己改善ループ**を組み込む
5. 観測可能性（Observability）と再現性を最優先

### 推奨アーキテクチャ（2026年標準形）

```mermaid
graph TD
Constitution[憲法レイヤー\n(CLAUDE.md / AGENTS.md / Quality Gates)] --> Orchestration[オーケストレーション\n(Main Loop + Hooks)]
Skills[Skillsレイヤー\n(漸進的知識開示)] --> Orchestration
Tools[MCP Tools\n(最大3-4個に制限)] --> Orchestration
Memory[永続メモリ\n(Filesystem + Vector + Graph)] --> Orchestration
SubAgents[Sub-Agents\n(コンテキスト防火壁)] --> Orchestration
Safety[安全・包含レイヤー\n(Scope/Approval/Snapshot/Rollback)] --> Orchestration
Evaluation[評価・フィードバックレイヤー\n(Rule + LLM Judge + Self-Reflection)] --> Orchestration
Observability[観測性レイヤー\n(Trajectory全記録 + Analytics)] --> All
Orchestration --> SelfImprovement[自己改善ループ\n(ハーネス自体をAgentに改善させる)]
```

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

**1. 憲法レイヤー（Constitution / System Prompt）**
- 60行以内に厳格に収める（AIが生成した長大な指示は性能低下を招く）
- 硬いルールのみ記述（「絶対に〜するな」「必ず〜を確認せよ」）
- ファイル名例：`CLAUDE.md`、`AGENTS.md`、`QUALITY.md`
- バージョン管理必須（Gitでハーネス自体を管理）

**2. Skills & Toolレイヤー**
- Skills：必要な知識を「漸進的に」開示（コンテキストを汚さない）
- Tools：MCP（Model Context Protocol）対応を推奨。**最大3〜4個**に厳格制限（tool thrashing防止）
- ツール記述は明確に（名前・説明・パラメータの意図を人間が完全に理解できるレベル）

**3. メモリ＆状態管理**
- 短期：会話コンテキスト
- 長期：**ファイルシステムを第一級のメモリとして活用**（これが非常に効果的）
- 補助：Vector DB + Knowledge Graph
- 重要なのは「何をいつ、どの粒度で永続化するか」の設計

**4. オーケストレーション＆Sub-Agent**
- メインループ：計画→実行→観察→改善のサイクルを明示的に設計
- **Sub-Agentは「コンテキスト防火壁」**として使う（長時間タスクを分離してメインの思考をクリーンに保つ）
- Hooks/Middleware：重要なポイントに確定性チェックを挿入（PreCompletionChecklistなど）

**5. 安全・包含レイヤー（最も重要）**
- ファイルシステムのスコープ厳格化（allowed write paths, protected patterns）
- 破壊的アクションは**必ず承認ゲート**を通す
- Snapshot + Rollback機構
- Blast Radius（影響範囲）事前計算
- Symlink traversal、絶対パス、親ディレクトリ操作の完全ブロック

**6. 評価・自己改善レイヤー**
- 多層評価：Rule-based → LLM-as-Judge → Human Review
- **自己改善ループ**：エージェントに「自分のハーネスを改善させる」仕組みを実装（Zennなどで34反復の実運用記録が出ている）
- 毎週の失敗レビューをハーネスにコード化（これが最も効果的）

**7. 観測性レイヤー**
- 全てのTrajectory（思考→行動→観測）を構造化ログ化
- LangSmith / Phoenix / 自前トレーサー
- 失敗パターン分析ダッシュボード必須

### 実装技術スタック例（2026年現在）

- **基盤**: LangGraph（状態機械として最適） or LangChain + カスタムMiddleware
- **フロントエンド的インターフェース**: Claude Code / Cursor / Codex / Amazon Bedrock AgentCore Harness
- **安全基盤**: 専用Sandbox + Policy Engine
- **自己改善**: Meta-promptでハーネスコード自体を生成・適用するループ
- **評価**: Inspect（UK AISI系）や自作の多角的Evaluator

### 設計時の優先順位（実務的アドバイス）

1. **安全と包含**（最初に固める）
2. **観測可能性**（何が起きているか完全に把握できるように）
3. **自己改善ループ**（人間の介入を徐々に減らす）
4. **Skills/Toolのモジュール化**
5. **憲法の洗練**

ハーネスが肥大化してきた時の変更容易性を保つために、**憲法・Skills・Hooksを明確に分離**して設計してください。[[2]](https://x.com/gota_bara/status/2046794926604931447)

### 参考資料（2026年最新）

- awesome-harness-engineering（GitHubリポジトリ）
- 「Harness Engineering入門 — Agent = Model + Harness で読み解くAIエージェント運用」（Qiita）
- Anthropicのlong-running application向けHarness design
- LayerXやfindyのSpeakerDeck資料
- 「agent運用してたらやりがちな失敗事例12選」（Zenn）

---

**ご質問の意図を教えてください。**
- 特定ドメイン（ソフトウェア開発、研究、業務自動化など）のハーネス設計を深掘りしたい
- 安全設計／自己改善ループの具体的な実装パターンが見たい
- コード例（LangGraphでの実装スケルトン）が欲しい
- 評価ハーネスに特化した設計が欲しい

用途を教えていただければ、より具体的な設計書・コード・Mermaid図・ポリシー例をお出しします。