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

「AIエージェント ハーネス 設計」というクエリは、まさに今最もホットで議論の多いテーマです。モデル自体ではなく、**モデルを有用で信頼性が高く、安全に動作させる「ハーネス（足場・運用基盤）」**が価値の大部分を占めるとの認識が業界で広がっています。[[1]](https://x.com/akshay_pachaar/status/2042586319390674994)

### 1. Agent Harnessとは何か？（現在の議論の整理）

**Harness** = statelessなLLMを**状態を持つ信頼できるエージェント**に変えるインフラ層。

主な構成要素：
- Orchestration（実行ループ）
- Memory & State Management
- Tool Integration & Governance
- Planning / Reflection / Self-correction
- Observability / Tracing / Evaluation
- Safety, Guardrails, Human-in-the-Loop
- （本番運用時は）Multi-tenancy, RBAC, Cost Control, Durable Execution

**大きな議論の軸（2026年現在）**：

- **Thin Harness vs Thick Harness**
- **Anthropic寄り（Thin）**: 「dumb loop」（プロンプト組み立て→モデル呼び出し→ツール実行のシンプル繰り返し）。モデルが賢くなればハーネスは薄くするべき。
- **LangGraph寄り（Thick）**: ロジックを明示的なグラフ（StateGraph）でエンコード。決定性・デバッグ容易性・制御性を重視。
- **OpenAI / CrewAI**: 中間。Code-first（Pythonネイティブ）やDeterministic Flowを組み合わせる。

- **Scaffolding（足場）のメタファー**（非常に有用）
足場は一時的。建物（モデル）ができ上がれば外す。実際、Anthropicはモデル更新ごとにplanningステップを削除している。ただし、**モデルは特定のハーネスで訓練されている**ため、安易に変えると性能が落ちる。[[1]](https://x.com/akshay_pachaar/status/2042586319390674994)

- **重要なカウンターポイント**（Ashpreet Bediらの指摘）
「Harness Engineering」という言葉が、**本当の難しさ（Systems Engineering）の70%を隠している**可能性がある。Multi-tenancy、RBAC、resource isolation、durable state、audit、approval flowなどは従来のシステムエンジニアリングの問題。Coding Agent（端末＋ローカルファイルシステム）のパターン（AGENTS.md、virtual filesystem）を一般化しすぎるのは危険。**Agent = Model + System**というフレームの方が健全。[[2]](https://x.com/ashpreetbedi/status/2040841492860735634)

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

**基本方針**:
- **Explicit Stateを徹底**（LangGraphが現在最強クラス）
- **Designed to be removed**（将来モデルが良くなったら簡単に簡略化できる構造にする）
- 人間の役割を「Environment Designer（良い環境・地図・フィードバックループを作る人）」にシフト
- 「Harnessability（ハーネスしやすさ）」を指標にする：どれだけ観測・介入・修正・評価しやすいか

**レイヤード設計**:

**1. Orchestration Layer（心臓部）**
- **LangGraph（強く推奨）**：StateGraph + checkpointing + persistence
- ノード例：Supervisor, Planner, Actor, Critic, Tool Executor, Router, Summarizer
- 利点：中断・再開、人間介入、バージョン管理、視覚的デバッグが可能

**2. Memory & Knowledge Layer**
- Working Memory：グラフのState（構造化）
- Semantic Memory：Vector DB（Progressive Disclosure＝最初は地図だけ渡す）
- Episodic Memory：トレースの要約＋長期ストレージ
- Procedural Memory：Skill Library / Tool Registry
- 実践Tips：「巨大なAGENTS.md」は失敗しやすい。**100行程度の目次＋構造化された/docs/** にする（mapではなくindex）。

**3. Tool & Capability Harness**
- 統一されたTool Schema（Pydantic + JSON Schema）
- **Permission System必須**（read-only / write / budget制御）
- Sandboxing（特にコード実行）
- Discoveryメカニズム（エージェントが新しいスキルを自ら見つける）

**4. Planning & Governance Layer**
- Hierarchical Planning（高レベル計画 → 分解）
- Reflection / Self-correctionループ
- Mechanically enforced rules（linter、dependency validation、background entropy cleanup agent）

**5. Observability & Evaluation Layer（最も投資すべき）**
- Full Tracing（LangSmith / Phoenix / OpenTelemetry）
- メトリクス：Task Success Rate, Cost/Task, Latency, Tool Accuracy, Safety Violation, Drift
- Evaluation Harness：Trajectory評価、LLM-as-Judge、実際の業務成功率
- Human Feedback Loopの体系的組み込み

**6. Production System Layer（本番必須）**
- Multi-tenancy & RBAC
- Resource Quota & Isolation（1テナントがトークンを食いつぶさない）
- Durable Execution（LangGraph checkpoint + Postgres / Temporal）
- Audit & Approval Flow

### 3. 技術スタック推奨（2026年）

- **最もバランス良い**：LangGraph + LangSmith + Postgres (with pgvector) + Qdrant/Pinecone + OpenTelemetry + Phoenix
- **高速プロトタイピング**：CrewAI Flows または LlamaIndex Workflow
- **Long-horizon / 大規模**：ByteDanceのDeer Flow（message gateway + sandboxed sub-agents + shared memory）のようなアーキテクチャを参考
- **Enterprise**：Semantic Kernel + Azure監視系

### 4. 設計時のチェックリスト

1. 新しい高性能モデルに置き換えたとき、ハーネスを**薄くできる**か？（Future-proofing test）
2. すべての思考・行動・観測が**完全にトレース可能**か？
3. 重要なアクションに**Human-in-the-Loop**を組み込めるか？
4. コスト・安全性・決定性のバランスが取れているか？
5. 「Harness」だけを考えていないか？全体として**System**になっているか？

### 追加アドバイス

- **過剰設計を避ける**：単純なタスクはReActやシンプルなループで十分。すべてをグラフにする必要はない。
- Coding Agentのパターン（filesystem中心）は、**単独の開発者用**には非常に有効だが、チーム・プロダクション用途ではデータベース＋構造化記憶に早く移行した方が良い。
- 最終的に勝つのは「モデルを最も効率的に有用にするハーネス（システム）」を作ったチームです。モデルは commoditize（一般化）しつつ、ハーネス/システムは差別化要因になり続けます。

具体的に深掘りしたい部分があれば教えてください：
- LangGraphでの具体的なState設計例
- Evaluation Harnessの構築方法
- Multi-agent orchestrationパターン
- Enterprise向けガバナンス設計
- コスト最適化アーキテクチャ

必要に応じてコード例や図も出せます。<|eos|>