**AIエージェントの「ハーネス設計」（2026年最新視点）**

2026年現在、「AIエージェント ハーネス設計」は最も重要なトピックのひとつになっています。**「AgentそのものよりHarnessが本質」**という認識が、企業・研究の両方で主流です。

### 1. 「Harness」とは何か

ハーネス（Harness）とは、**馬の手綱（手綱・鞍・制御装備）**から来ています。

- LLMを「馬」とするなら、ハーネスは「人間が制御するための全システム」
- 単なるReActループやツール呼び出しラッパーではない
- **Agentの性能の約半分を決める外殻**（提示詞・記憶方式・制御フロー・安全機構・状態管理・監査などすべてを含む）

著名な見解：
- 「The Harness, Not the Agent」（企業での失敗のほとんどはHarness不足）
- HarnessX論文（小米系）：同じモデルでもHarnessを変えるだけで平均+14.5%、最大+44%改善
- OpenAIも「Harness Engineering」「Codex harness」という言葉を公式に使用

### 2. 推奨アーキテクチャ（2026年実践版）

```mermaid
graph TD
subgraph Human_Steering ["Human Steering Layer"]
Goal[Goal + Constraints
+ Success Criteria]
Policy[Policy & Approval Rules]
end

subgraph Orchestration_Harness ["Orchestration Harness Core"]
Manager[Manager
(Long-term Planning)]
State[Verified State Store
★最重要]
Auditor[Auditor
(Independent Verification)]
Safety[Safety & Guardrails Engine]
Critic[Critic / Evaluator]
end

subgraph Execution_Runtime ["Execution Runtime"]
Executor[Tool Executor
(Sandbox + Scoped Permission)]
Memory[Multi-level Memory Mediator]
SubAgent[Sub-Agent Orchestrator]
Observability[Observability & Immutable Audit]
end

subgraph Plugin_Layer ["Plugin / Extensibility Layer"]
Everything[All is Plugin
(Skills, Protocols, Mediators)]
end

Human_Steering --> Orchestration_Harness
Orchestration_Harness <--> Execution_Runtime
Execution_Runtime <--> Plugin_Layer
```

### 3. 主要コンポーネントの設計指針

#### (1) Human Steering Layer（最重要）
- 単なる「タスク指示」ではなく、**制約・品質基準・承認ポリシー・エスカレーションパス**まで言語化
- 「正しいものを作るためのメタ定義」がここで決まる（LayerX CTO松本勇気氏の指摘通り）

#### (2) Orchestration Harness Core
- **State Storeを「検証済み事実のみ」にする**（LongHorizon-Harnessの核心）
- **MEAパターン**（Manage–Execute–Audit）を強く推奨：
- Manager：次の小課題と受け入れ条件を定義
- Executor：新鮮なコンテキストで実行
- Auditor：**読み取り専用**で実環境を検証（これが劇的に効く）

#### (3) Execution Runtime
- **Sandboxは必須**（E2B、Firecracker、独自のTool Proxy推奨）
- Permissionは「グラフベース」で管理（誰が・何を・どのスコープでできるか）
- Memoryは最低4層に分離：
- Working Context（短期）
- Semantic Memory
- Episodic Memory（出来事）
- Procedural Skills（ playbook）

#### (4) Plugin-first Architecture
DeepSeek Harness（2026年に急成長中）の影響が非常に大きいです。**「すべてをPluginにする」**設計にすると、将来的に壊れにくい。

### 4. 設計時の重要原則（優先度順）

1. **State is King**（特に長期タスク）
2. **Audit > Execution Log**（Executorの自己申告を信用しない）
3. **Intelligence Externalization**（LLMは薄く保つ）
4. **Evolvability**（失敗トレースからPrompt/Tool/Protocolを自動改善）
5. **Safety by Design**（設定フェーズが最も脆弱という研究結果あり）

### 5. 実装技術スタック（2026年おすすめ）

**Orchestration**:
- LangGraph（まだ最強クラス）
- Custom State Machine + LongHorizon-Harnessパターン
- DeepSeek Harness系（Pluginアーキテクチャ採用時）

**Safety/Guardrails**:
- Guardrails AI + 独自Permission Graph
- NVIDIA NeMo Guardrails（企業向け）

**Observability**:
- LangSmith/Phoenix + Immutable Audit Trail

**Sandbox**:
- E2B or 独自の軽量VM + Scoped OAuth

### 参考資料（最新）

- HarnessX（自動進化するHarness）
- LongHorizon-Harness（MEAループ、2026年長期タスクの定番）
- AI Agent Harness安全性ベンチマーク（6フェーズ評価、arXiv:2608.17597）
- Akshay氏の「Anatomy of Agent Harness」（Memory/Skills/Protocols/Mediatorsの整理が秀逸）

---

**質問を深掘りできます**：

- **企業内生産Agent**向けの安全重視ハーネス
- **長期複雑タスク**特化（SWE-Bench級）のState管理設計
- **Plugin-first完全版**の具体的な実装（DeepSeek Harness風）
- **自動進化機構**（AEGIS-like）の入れ方

どの方向性を深く設計したいか教えてください。具体的なユースケース（例：社内業務自動化、ソフトウェア開発Agent、研究用エージェントなど）を教えていただければ、それに最適化した設計図・コンポーネント・実装コードの骨子まで出せます。