**AIエージェントの「Harness」設計**（2026年最新知見ベース）

2026年現在、「**Agent = Model + Harness**」が業界の共通認識になっています。同じモデルを使っても、**Harnessの設計品質で成功率・コスト効率が5〜30倍変わる**事例が複数報告されており、モデルを大きくするよりHarnessを磨く方がレバレッジが大きい局面に入っています。

### 1. Harnessとは何か

Harnessは「AIを単なる推論器から**自律的にタスクを完遂する存在**に変えるシステムレイヤー」です。

主な責務：
- 計画・分解・再計画
- 記憶（短期・長期・エピソード・手続き的）
- ツール呼び出しの制御と検証
- 状態管理とライフサイクル
- 検証（Verification）と自己修正
- 権限制御・安全・ガバナンス
- 観測可能性（全trajectoryのトレース）

有名な表現として、Rubric Labsは「Modern harnesses have strong opinions about: compaction, memory, planning, dispatch, tool calling, verification, permissioning」と述べています。

### 2. 最先端の設計フレームワーク：**ETCLOVG 7-Layer Architecture**

2026年で最も注目されている体系的アプローチです（複数の論文・実践報告で言及）。

| レイヤー | 内容 | 設計のポイント |
|-------------------|-----------------------------------|---------------|
| **E**xecution Sandbox | 安全な実行環境 | Docker/Firecracker/Cloud Sandbox、ファイル・ネットワーク・APIの厳格制限 |
| **T**ool Protocols | ツールの統一インターフェース | 厳格なスキーマ、入力検証、モック機能、バージョン管理 |
| **C**ontext State | 記憶・コンテキスト管理 | 階層的メモリ + Compaction（要約） + Forgetting戦略 + GraphRAG |
| **L**ifecycle Graphs | 実行ループの状態遷移 | 有限状態機械 or LangGraph風のグラフ。Planning-Acting-Observing-Verifying-Reflecting |
| **O**bservability | 完全な可観測性 | 全ての思考・ツール呼び出し・状態変化を構造化ログ。リアルタイム異常検知 |
| **V**erifiers | 検証機構 | LLM-as-Judge + コードベースchecker + End-State Verification（最も重要） |
| **G**overnance | 統制・ガバナンス | 企業ポリシー適用、Permissioning、Human-in-the-Loop gates、監査 |

この7レイヤーを**明確に分離**して設計することが、信頼性向上の鍵です。

### 3. 設計原則（実践的に重要なもの）

**必須原則**
- **Testability First**：Harnessを設計する最初に、Regression SuiteとSynthetic Failure Injection環境を作る
- **End-State Verification重視**：プロセスではなく「最終的に目的状態になったか」を厳密に検証（これが一番効く）
- **Model Agnostic**：Claude、GPT、Grok、Llamaなど簡単に切り替えられる抽象化
- **Declarative as much as possible**：可能な限り**Natural-Language Agent Harnesses**（自然言語で制約やポリシーを記述し、LLMに解釈させる）を取り入れる
- **Failure Mode Driven Development**：過去の失敗トレースを分析し、各失敗パターンに対するinterventionをharnessに硬く組み込む

**先進的な考え方**
- Leverageの移行：Thorsten Ball（Amp Inc.）は「2026年末にはもう誰もharnessの話をしなくなる。leverageはparallelism・I/O handling・周辺インフラ（彼は"Orbs"と呼んでいる）に移る」と予測。
- コードベースのharnessが冗長になりすぎたら、自然言語でharness自体を記述する方向（Natural-Language Agent Harnesses論文）。

### 4. 具体的な設計手順（実際に作る場合）

1. **ドメイン特定**：何のためのAgentか（ソフトウェアエンジニアリング、研究、業務自動化など）を明確にし、Success Criteriaを定義
2. **ETCLOVGの各レイヤーを1つずつ実装・テスト**（特にC, L, Vを最初に固める）
3. **Memory Architectureを慎重に設計**（これが最も差が出る部分の一つ）
4. **Verifierを多層化**（LLM Judgeだけに頼らない）
5. **Observabilityを徹底**（後から追加するのは非常に辛い）
6. **実 trajectoriyで繰り返し改善**（人間がトレースを見て「この失敗はどこで防げるか」を特定）

### 5. 技術スタック例（2026年時点）

- **Runtime**: LangGraph（最も成熟）、自前State Machine、CrewAI拡張、Waku Agent系
- **Memory**: Mem0 + GraphRAG + Procedural Memoryの組み合わせ
- **Evaluation Harness**: Inspect風の専用evalスイート + 校正済みLLM Judge
- **Sandbox**: E2B、Modal、企業内セキュアexecutor
- **Observability**: OpenTelemetry for Agents + 専用ダッシュボード

### まとめ：今一番効く投資先

「もっと良いモデルを入れる」ではなく、**「より厳密でテスト可能なHarnessを設計する」**ことです。

特に効くのは：
- 強力な**Verifier + End-State Checking**
- 賢い**Context Compaction + Memory Architecture**
- **Lifecycle Graph**の洗練
- **Governance/Permissioning**の堅牢化

---

必要であれば、以下のいずれかを深掘りした設計資料も作成できます：
- 具体的なETCLOVG実装例（コードレベル）
- コーディング特化AgentのHarness設計
- Evaluation Harnessの作り方
- Natural-Language Harnessの実装パターン

どの方向を詳しく知りたいですか？