**AIエージェントハーネスの設計（2026年版）**

2026年現在、AIエージェント開発の本質は「モデルを賢くすること」から「モデルを囲む仕組み（Harness）を強くすること」にシフトしています。プロンプトエンジニアリング → コンテキストエンジニアリング → **ハーネスエンジニアリング** が主流です。[[1]](https://x.com/tetumemo/status/2037876018745385083)

### 1. ハーネスとは

**定義**
「Agent = Model + Harness」（Hashimoto & Trivedy）。モデル（CPU）に相当するLLMの外側にある「OS」に相当するすべての仕組みです。ランタイム、コンテキスト管理、セーフティ、記憶、評価、回復機構、フィードバックループなどを含みます。[[2]](https://x.com/immeivise/status/2094274173149589818)

馬具（reins/hand）という語源の通り、AIの強大な能力を「制御しつつ最大限に活かすための足場」です。特に長期自律実行（long-running tasks）で重要で、単発の推論ではなく「何日も動き続けるエージェント」を安定運用するための基盤です。[[3]](https://x.com/_philschmid/status/2008175408923959574)

評価ハーネス（ベンチマーク用）とエージェントハーネス（運用用）が混同されやすいため、**ランタイム層・コンテキスト層・セーフティ層**の3層で責務を分離することを推奨します。

### 2. 設計原則

- **Composability（構成可能性）**：フレームワークをモノリスにせず、Policy Engine、Model Router、Approval Layer、Observabilityなどを独立コンポーネント化。将来の変更に強い。
- **Persistence & Recoverability**：コンテキストウィンドウを超えた長期実行を前提。状態は常に永続化し、クラッシュしても復旧可能。
- **Observability First**：すべての思考・ツールコール・状態遷移・判断根拠をトレース。ログをそのまま「記憶」に変換（"dreaming"）。
- **Explicit & Binary Criteria**：成功条件を曖昧にせず、明確・二値的に定義。
- **Feedback Loopの高速化**：失敗を安価にし、即座に学習に繋げる（linterはedit time、テストは早期）。
- **Isolation**：1 Agent 1 Worktree（または1 Sandbox）。並列実行時の干渉を防ぐ。
- **Meta-Harness対応**：単一ハーネスだけでなく、「ハーネスを管理するハーネス（Harness of Harness = HoH）」を上位に置けるようにする。[[4]](https://x.com/itarutomy/status/2095346046104674736)

### 3. 推奨アーキテクチャ

**レイヤード + Graph + Meta-Harness** の3層構造を推奨：

```
[ Meta-Harness (HoH) ]
├── Planner (次の開発目標・未解決Issue選定)
├── Developer (実装担当エージェント)
└── QA Tester (独立検証：ブラックボックス + ホワイトボックス)
↓ (Evidence + Unsolved Issues を次のループに渡す)

[ Agent Harness Core ]
├── State Graph Engine (LangGraph風 永続化グラフ)
├── Context & Memory Layer (Short-term / Semantic / Procedural / Progress File)
├── Tool & MCP Layer (標準化されたツール接続)
├── Runtime & Execution (Sandbox + Retry + Human-in-the-Loop)
├── Guardrails & Safety Layer (出力検証、権限、コスト制限)
└── Observability & Tracing (OpenTelemetry + 構造化ログ)

[ Evaluation & Experiment Layer ]
├── Multi-scorer (LLM-as-Judge + コード検証 + 人間フィードバック)
├── Experiment Tracker (A/Bテスト、コスト・成功率・回帰検知)
└── Leaderboard / Report Generator
```

状態はすべて**永続化グラフ**（チェックポイント）で管理。進捗は「Persistent Progress File」（JSONやMarkdown）に書き込み、各ループ開始時に読み込む。これが長期実行の最も安価で効果的な手法です。[[5]](https://x.com/rohit4verse/status/2036845273117581676)

### 4. 主要コンポーネント詳細

- **State Graph**：ノード例 = Planner, Actor, Critic/Reflector, Tool Executor, QA Validator, Summarizer。条件付きエッジでルーティング。
- **Memory System**：
- Short-term：グラフの現在の状態
- Semantic：Vector DB（PGVector/Qdrant）
- Procedural：過去の成功Trajectoryからのスキル抽出（DSPy-like）
- Project Memory：Progress File + Evidence Store（「何が検証済みか」「どのIssueが未解決か」を明示）
- **Tool Integration**：MCP（Model Context Protocol）的な標準化インターフェースを採用。ツール実行は常にSandbox（Docker/Firecrackerなど）。
- **Guardrails & Safety**：事前・事後検証、予算キャップ、機密情報マスキング、Jailbreak検知。
- **Evaluation**：単一の最終結果だけでなく**Trajectory評価**（各ステップの質）。LLM Judgeはrubricを明確に。回帰検知を重視。
- **Observability**：全実行を構造化ログ化。過去ログを自動で次のコンテキストや合成データに変換。

### 5. 実装のベストプラクティス（2026年現在）

- 構文エラーはedit timeにlinterで捕捉。
- 完了条件は「binary（はい/いいえで判定可能）」に。
- 1エージェント1 git worktreeで完全分離。
- ログを記憶に変換する仕組みを必ず入れる。
- ベンチマークだけでなく「実ユーザーのユースケースでの継続評価」を最優先。
- ベンダーロックイン回避のため、自社データ・ワークフロー中心のハーネスを構築（モデルはLiteLLMなどで抽象化）。[[6]](https://x.com/gauri__gupta/status/2093850113101946971)

### 6. 技術スタック提案

- **Core**：LangGraph（または後継の永続グラフフレームワーク） + Pydantic
- **LLM抽象化**：LiteLLM + Structured Output（o1-like reasoningモデル対応）
- **Memory**：PGVector + Summary Chain + Progress File（シンプルなJSON/Markdown）
- **Sandbox**：E2B, Firecracker, または自前Docker
- **Observability**：OpenTelemetry + LangSmith/Phoenix類似の自社ツール
- **Evaluation**：DeepEval/RAGASをエージェント向けに拡張 + 自前LLM Judge
- **UI/運用**：CLI + Web Dashboard（Streamlit/FastAPI + React）

### 7. 最小スケルトン例（LangGraph風）

```python
class AgentState(TypedDict):
messages: Annotated[list, add]
progress: dict # Persistent Progress
evidence: list
unsolved_issues: list
next: str

graph = StateGraph(AgentState)

graph.add_node("planner", planner_node) # 次目標 + Issue選定
graph.add_node("developer", developer_node)
graph.add_node("qa_tester", qa_tester_node) # 独立QA
graph.add_node("summarizer", summarizer_node)

# 条件付きルーティング + チェックポイント保存
graph.add_conditional_edges(...)

harness = AgentHarness(
graph=graph,
persistence=PostgresCheckpoint(),
evaluators=[BinarySuccessChecker(), LLMTrajectoryJudge()],
guardrails=ProductionGuardrails()
)

result = harness.run(task=long_running_task, max_loops=100)
```

### まとめと進化方向

2026年の勝負は**「自分のデータとワークフローで学習・複利が効くハーネス」**をどれだけ早く強く構築できるかです。モデルはラボが提供しますが、ハーネス（ループ・記憶・評価・回復の仕組み）はあなたが所有すべき資産です。[[7]](https://x.com/SuccessSparksX/status/2095351627859300417)

最初はシンプルなGraph + Progress File + 基本Evaluatorから始め、徐々にMeta-Harness（HoH）や完全なマイクロサービス化（イベントバス経由の疎結合コンポーネント）に進化させるのが現実的です。

必要であれば、特定のユースケース（コーディングエージェント、研究エージェント、業務自動化など）に特化した詳細設計やコード例をさらに深掘りします。どのような場面でのハーネス設計をお考えですか？