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

「AIエージェント ハーネス 設計」というクエリは、まさに今最もホットなトピックの一つです。最近の議論では、**「モデルを賢くするより、ハーネスを賢く設計せよ」**という考え方が主流になっています。LLM自体は薄く（thin）保ち、知能の大部分を外側の「ハーネス」に押し出すアーキテクチャが推奨されています。[[1]](https://x.com/_avichawla/status/2062082282878627946)

### 1. ハーネスとは何か？（根本的な再定義）

従来のイメージ（ツールをLLMにボルトオンする）ではなく、**ハーネスが主役**です。

ハーネスの中心に薄いLLMを置き、周囲を以下の3つの次元で取り囲みます：

- **Memory（記憶）** — 作業コンテキスト、意味的知識、エピソード記憶、個人化記憶。それぞれライフサイクルが異なる。
- **Skills（スキル）** — 手順的知識、意思決定ヒューリスティック、規範的制約。タスクごとにモデルを特化させる。
- **Protocols（プロトコル）** — エージェント↔ユーザー、エージェント↔エージェント、エージェント↔ツールの契約。失敗モードがそれぞれ異なる。

これらを繋ぐ**Mediators（仲介層）**として以下を配置：
- Sandboxing（サンドボックス）
- Observability（可観測性）
- Context Compression
- Evaluation / Verification
- Approval Loop
- Sub-agent Orchestration

この設計により、「新しい機能をどこに置くか？」が明確になります（安定知識→Memory、プレイブック→Skills、契約→Protocols、ループ制御→Mediators）。[[2]](https://x.com/akshay_pachaar/status/2045510648474530263)

### 2. 全体アーキテクチャ（推奨）

```mermaid
graph TD
A[Experiment / Task Config] --> B[Harness Runner]
B --> C[Adaptive Harness Manager\n(MemoHarness風)]
C --> D[Memory System\n(Working + Semantic + Episodic)]
C --> E[Skill & Tool Registry]
C --> F[Protocol & Guardrail Engine]
B --> G[Execution Loop Engine\n(Loop Engineering)]
G <--> H[Thin LLM Caller\n(Model Agnostic)]
G <--> I[Environment / Sandbox]
G --> J[Observer & Tracer\n(LangSmith風)]
J --> K[Evaluator\n(LLM-as-Judge + Rule-based)]
K --> C
style C fill:#e3f2fd
```

**実行ループのシーケンス**（1エピソード）：

```mermaid
sequenceDiagram
participant Harness as Harness Manager
participant Agent as Thin LLM + Skills
participant Env as Environment/Sandbox
participant Eval as Evaluator

Harness->>Env: reset(task)
loop 最大ステップ or Done
Harness->>Agent: get_next_action(trajectory + retrieved memory)
Agent->>Harness: Action (JSON / Code / Thought)
Harness->>Env: execute(action)
Env->>Harness: Observation + State Change
Harness->>Eval: incremental verification (optional)
Harness->>Harness: diagnose & store experience (MemoHarness)
end
Harness->>Eval: final_evaluation(trajectory)
Eval->>Harness: Score + Diagnosis + Reusable Pattern
Harness->>Harness: Update global & case memory
```

### 3. 主要設計コンポーネントの詳細

**① Adaptive Harness（静的→動的への進化）**
固定ハーネスは限界があります。**MemoHarness**的なアプローチが有力です：
- ハーネスを6つの編集可能面に分解：Context, Tool, Generation, Orchestration, Memory, Output。
- 各実行後に「何が起きたか・なぜ失敗したか」を診断ドキュメント化。
- 類似過去ケースを参照して、そのタスク専用のハーネスを動的に調整。
- 結果：固定SOTAを大幅に上回る（例: Shell Agentで0.722→0.806）。勾配やラベル不要。[[3]](https://x.com/minervacosmetic/status/2078262532033413414)

**② Loop Engineering（実行制御の設計パターン）**
本番運用に必須。以下の10パターン程度を整理して設計契約を決める：
- 状態保存・再開・停止
- 検証ループ（自己採点禁止、別検証エージェント推奨）
- ネストされた3つのループ（Agent分単位、Developer時間単位、Market日単位）
- Worktree / Isolationによる安全性確保

日本でも「ループエンジニアリングのデザインパターン」として体系化が進んでいます。[[4]](https://x.com/jar2/status/2078332878430343611)

**③ Guardrail設計（日本コミュニティの重要論点）**
「禁止事項を増やせばいい」はNG。AIの力を半減させる。
- マイクロマネジメントではなく、「AIが安心して働ける環境」を作る。
- ガードレールは最小限に精査。人間の管理と同じ原則。[[5]](https://x.com/_maogeng/status/2078451674029654401)

**④ Security & Isolation**
複数クライアント/タスクを扱う場合、Vault/Repositoryを完全に分離。機密情報は「AI読ませ用」と「人間専用」に分ける。

### 4. 設計原則（守るべきこと）

- **Model Agnostic**：モデルを簡単に差し替え可能（deepagentsのような取り組みが参考）。
- **Reproducibility & Observability**：全軌跡をトレース、シード固定、コスト追跡必須。
- **Learn from Failure**：失敗を次のハーネス改善の燃料にする。
- **Sandbox First**：Docker/Firecracker + Playwrightなどで強力に隔離。
- **Avoid Over-Engineering**：最初は最小ハーネスから始め、経験を積みながら進化させる。

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

- **基盤**：LangGraph / deepagents（モデル非依存ハーネス） / LangSmith（トレーシング）
- **Memory**：Vector DB + Graph DB + Episodic Store
- **Evaluation**：LLM-as-Judge + ルールベース + 人間-in-the-loop
- **Adaptive部分**：MemoHarness風の経験蓄積レイヤー（自作推奨）
- **Sandbox**：セキュアなコード実行環境 + ブラウザ自動化

最近の潮流として、**「Code as Harness」**（複数LLM呼び出しをコード生成で代替）や、**自動ハーネス進化**の研究も活発です。ただし、自動進化は単純なtest-time searchに負けるケースもあるため、評価は慎重に。[[6]](https://x.com/arxivsanitybot/status/2078897823580361057)

---

**まとめ**
2026年現在、AIエージェントの性能は「モデルの賢さ」よりも**ハーネスの質**で決まります。静的なテンプレートではなく、「経験から学ぶ動的な構造」としてハーネスを設計することが本質です。

具体的なユースケース（コーディングエージェント、社内業務自動化、研究用ベンチマークなど）があれば、もっと詳細な設計図やコードスケルトン、特定のデザインパターンを深掘りできます。どのような場面でのハーネス設計をお考えですか？