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

「AIエージェント ハーネス設計」は現在非常にホットなテーマです。単なる「Agentを作る」ではなく、**「Agentを制御・持続可能にする仕組み（Harness）を設計する」**というHarness Engineeringの考え方が日本コミュニティを中心に広がっています。ハーネスとは馬具（手綱・鞍）の意味で、人間がゴール・制約・品質基準・記憶・検証ロジックを定義し、エージェントに力を正しく引き出させるレイヤーです。[[1]](https://x.com/taimuhanashiro/status/2023008135464788127)

### 1. ハーネスの本質的な役割

- **モデル（確率的な脳）とハーネス（制御システム）の明確な分離**：モデル weights はほぼ更新せず、外側のハーネスで再現性・継続学習・検証を実現する。
- 主要課題解決：非決定性、長期実行時のコンテキスト劣化、コスト暴走、失敗からのリカバリ、評価の難しさ。
- 目標：デモを超えて「本番で信頼できる」「メンテナンス可能な」エージェントシステムを構築。

### 2. 推奨アーキテクチャ（7〜8層ハーネス）

Ignacio Martinez氏（Oracle）の議論などを参考に、以下のようなレイヤード設計が有効です。[[2]](https://x.com/ShimizuYusuke/status/2102351647754289234)

1. **Model Interface Layer** — LLM/API抽象化（OpenAI, Anthropic, Grok, Claude 4, vLLMなど切り替え容易）
2. **Prompt & Tool Schema Layer** — 構造化プロンプト、Pydantic/JSON Schemaによるツール定義の自動変換
3. **Reasoning & Planning Layer** — ReAct, Plan-and-Execute, Reflection, LLMCompilerなど複数戦略をスイッチ可能。弱いモデルでは計画が精度を上げ、強いモデルではコストを下げる効果が実証されている（「An Empirical Study of Harness Design for Coding Agents」より）。[[3]](https://x.com/connect24h/status/2101084865026519267)
4. **Memory & Knowledge Layer**（最も重要） —
- Hierarchical Event Memory（観測・進捗・失敗・イベントをタスク中心に記録）
- Spatiotemporal / Semantic Graph（環境・エンティティ中心）
- Compaction戦略（MEMORY.md、日次ログ、Vector + Graph + Relationalの併用）
- Umwelt概念（エージェント固有の知覚世界として組織文書を扱う）
5. **Verification & Critique Layer** — LLMの提案を盲目的に実行せず、**観測証拠・到達可能性・サブゴール整合性**を検証（HarnessVLNの成功要因）。これによりリカバリと停止判定が劇的に改善。
6. **Execution & Tool Layer** — Sandboxed実行、再試行、並列ツールコール、Human-in-the-Loop承認、コスト監視。
7. **Orchestration Layer** — Multi-agent（Supervisor, Hierarchical, Swarm）、Temporal.ioなどの信頼性実行基盤、OpenAI Agents APIのような長時間ジョブ対応。
8. **Evaluation & Feedback Layer（Meta）** — 継続的改善のための評価ハーネス。

**バックボーンとして推奨**：LangGraph（または同等の状態永続化グラフエンジン）。Checkpointing（Postgresなど）で状態を永続化し、人間介入や途中再開を容易にする。

### 3. 特に重要な設計ポイント（Maintainability重視）

Gota氏の「Harness Engineering入門」でも強調されているように、ハーネスは肥大化しやすいため、**変更容易性**を最優先に設計してください。[[4]](https://x.com/gota_bara/status/2046794926604931447)

- **明確なインターフェースと疎結合**：各レイヤーを独立モジュール化。Memory, Verifier, Plannerなどはプラグイン形式に。
- **Event-Driven + Observable First**：すべての思考・ツールコール・検証結果をOpenTelemetryでトレース。LangSmith/Phoenix相当のビューアを必須。
- **Evaluation Harnessの構築**：
- Golden Trajectoryによる回帰テスト
- Rubric付きLLM-as-Judge（成功率だけでなく効率・コスト・安全性も評価）
- 構成要素ごとのA/Bテスト（計画あり/なし、検証レイヤーあり/なしなど）
- 成功率だけでなくSPL（Success weighted by Path Length）などの効率指標も追う

- **Production Survival Patterns**（Oracleガイド参考）：
- コストガードレール（トークン予算超過で強制停止）
- 自動コンパクションと記憶の階層管理
- 並行エージェント間の競合回避（ワークツリーやDBトランザクション）

### 4. 実装時の優先順位（ハーネスが複雑になった時の指針）

1. Memory Architectureの固め（これが一番効く）
2. Verification/Critiqueレイヤーの追加
3. 計画と実行の明確な分離
4. 徹底したObservability
5. Evaluation Harnessの自動化

これで「作る」から「育てる・制御する」フェーズに移行できます。

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

- **Core**：LangGraph + Pydantic + asyncio + Temporal.io
- **Memory**：PGVector + Neo4j（グラフ） + Postgres（イベントログ）
- **Evaluation**：DeepEval拡張版 + 独自Rubric + synthetic data generator
- **Observability**：OpenLLMetry + 自前ダッシュボード or LangSmith
- **Deployment**：OpenAI Agents API風の長時間実行基盤 or Kubernetes + Celery

### 次にやるべきこと

- まずは**Memory + Verification**を中心にした最小ハーネスをPoCで作ってみる
- 特定ドメイン（コーディングエージェント、研究エージェント、業務自動化）でGolden Trajectoryを10〜20個集めて評価基盤を整備
- Speakerdeck「μでのハーネスの設計」（Gota氏）を参考に、メンテナビリティを意識したコード構造にする

具体的にどの部分を深掘りしたいですか？

- 詳細なMemory Harness設計（ファイル vs DB vs Graphの使い分け）
- Evaluation Harnessの具体的な実装例（Rubric設計含む）
- Coding Agent向けHarnessの構成要素比較
- Mermaidによるアーキテクチャ図
- 生産性が高いHarness Engineerの思考法

用途（業務自動化、SWE-Bench系、 embodied agentなど）を教えていただければ、よりピンポイントな設計資料をお渡しできます。