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

「モデルはエンジン、ハーネスは車（またはOS）である」——これが現在のコンセンサスです。LLM本体よりも、周囲のインフラ（ハーネス）がエージェントの実用性・安全性・信頼性を大部分決定します。プロンプトエンジニアリングの次に来るのが**ハーネスエンジニアリング**です。[[1]](https://x.com/CobusGreylingZA/status/2043638576848707662)

### 1. ハーネスとは何か

ハーネス（Harness）は、**生のLLMを信頼できる自律エージェントに変換する実行基盤**です。

主な役割：
- 知能の外部化（Memory / Skills / Protocols）
- 実行の制御・監視・安全確保
- 失敗からの学習と改善

**Memory（記憶）**：作業コンテキスト、意味的知識、エピソード記憶、個人別記憶
**Skills（技能）**：運用手順、意思決定ヒューリスティック、規範的制約
**Protocols（プロトコル）**：ユーザー間・エージェント間・ツール間の契約
**Mediators（仲介層）**：サンドボックス、観測可能性、圧縮、評価、承認ループ、サブエージェント調整

この外部化により、モデル自体を「薄く」保ち、モデルを交換しやすくします。[[2]](https://x.com/akshay_pachaar/status/2045510648474530263)

### 2. 設計原則（これを守らないと失敗する）

1. **Externalization First** — 可能な限り知能をモデル外に押し出す
2. **Observability by Default** — ログを取っていないことは「起こっていない」と考える
3. **Modularity & Composability** — Policy Engine、Approval Flow、Model Routerなどは交換可能にする（モノリシックは避ける）
4. **Scaffolding Mindset** — 将来的にモデルが賢くなったらハーネスを薄くできる設計にする（Anthropicの思想）
5. **Safety & Cost by Design** — デフォルトで承認ゲート、予算制限、停止条件を入れる
6. **Designed for Self-Improvement** — トレースから弱点を抽出し、ハーネス自体を改善するループを持つ

### 3. 推奨アーキテクチャ（レイヤード設計）

```mermaid
graph TD
A[User / Human Oversight] --> B[Orchestration Engine
Loop / Graph / Multi-Agent]
B --> C[Mediators Layer]
C --> D[Memory System]
C --> E[Skills & Protocols]
C --> F[Tool Execution & Sandbox]
C --> G[Guardrails & Approval]
B --> H[Observability & Evaluation]
H --> I[Persistence Layer
State / Audit / Artifacts]
B --> J[LLM Abstraction Layer]
```

**主要8構成要素**（Databricksの整理を基に拡張）：

1. **System Prompt / Instructions**（Skillsの一部）
2. **Memory Management**（4層構造が理想）
3. **Tool Execution + Sandbox**
4. **Context Management & Compression**
5. **Orchestration Loop**（Plan → Execute → Verify → Iterate）
6. **Guardrails / Approval Loops / Budget Control**
7. **Observability / Tracing / Evaluation**
8. **Persistence & Learning Loop**

### 4. 各コンポーネントの詳細設計ポイント

**Memory System**
- Working Context（現在のタスク）
- Semantic Memory（ベクトル + グラフDB）
- Episodic Memory（過去の実行トレース）
- Personalized / Long-term Memory
- 重要：忘却戦略（古いものは圧縮・要約・削除）

**Tool & Execution**
- 権限付きツールレジストリ（許可リスト）
- Sandbox（コード実行はDocker/Firecracker、ブラウザは専用Sandbox推奨）
- Manifestパターン（変更前に「これを実行します」と人間に見せる）

**Orchestration**
- 厚いハーネス（LangGraphなど明示的グラフ） vs 薄いハーネス（Anthropic風シンプルReAct）
- 用途によって使い分ける。コーディングエージェントは比較的厚めが安定しやすい
- 役割分離（Planner / Worker / Reviewer / Verifier）

**Safety & Governance**
- 予算（トークン/コスト）制限
- 最大ループ回数
- 人間承認ゲート（特に破壊的アクション時）
- Policy Engine（交換可能にする）

**Observability & Evaluation**
- 詳細トレース（LangSmith / OpenTelemetry）
- 自動評価スコアラー
- Weakness Mining（失敗パターンを自動抽出）
- ダッシュボード（コスト、成功率、安全違反、レイテンシ）

### 5. 実装時の技術的選択肢

**おすすめスタート**
- **最小ハーネスから作る**：魔法を排除した didactic な実装（Akshay氏らが言及しているアプローチ）
- **LangGraph + LangSmith**：厚いハーネスが欲しい場合の最速
- **Custom構築**：FastAPI + Celery + LiteLLM + VectorDB + PostgreSQL + OpenTelemetry

**注意すべき落とし穴**
- ファイルシステムを主記憶にしない（同時実行・クエリ・RBACで破綻する）
- 多 tenant / RBAC / リソース隔離を後回しにしない
- ハーネスをモデルに過度に特化させない（モデル交換時に性能低下）
- 承認ゲートなしの完全自律は本番では危険

### 6. 次のアクション（実践編）

1. 特定ドメイン（例：ソフトウェア開発、調査、レポート作成）で**最小ハーネス**をプロトタイプ作成
2. 全ての実行をトレース保存
3. 失敗トレースを分析 → ハーネス改善（新しいSkill追加、Guardrail強化、Loop変更）
4. 徐々にSelf-Harness化（ハーネスが自ら改善提案する仕組み）

ハーネス設計は「一発正解」が存在しません。**継続的な観測・分析・改善のループ**そのものが競争力になります。

必要であれば、特定の部分（Memoryアーキテクチャ、Approval Workflow、Coding Agent特化ハーネスなど）をさらに深掘りした設計ドキュメントも作成できます。

参考にした主な議論：
- Harrison Chase / LangChain周辺の議論
- 「The model is not the agent. The harness is.」というフレームワーク
- 日本語コミュニティでのハーネスエンジニアリング実践知見

この設計思想で進めれば、モデルが変わっても長く使える頑健なエージェント基盤が作れます。