**AIエージェント ハーネス設計**（Harness Engineering）

2025〜2026年現在、AIエージェントの実用化で最も重要なレイヤーとして注目されているのが「**ハーネス**」です。プロンプトエンジニアリング → コンテキストエンジニアリングの次に来る「**ハーネスエンジニアリング**」と呼ばれています。

モデルを「CPU」とするなら、ハーネスは「OS」に相当します。どれだけ賢いモデルを使っても、長期実行・複雑タスク・信頼性ではハーネスの設計が勝負を分けます。[[1]](https://x.com/tetumemo/status/2037876018745385083)

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

ハーネスとは、AIエージェントを**正しく・安全に・長時間安定して動かすための実行基盤**全体を指します。具体的に含む要素：

- 実行ループ（Agent Loop）の設計
- 状態管理・チェックポイント・回復機構
- ツールの登録・サンドボックス・権限管理
- 検証・QAレイヤー（Critic / Tester）
- 計画・記憶・証拠（Evidence）の蓄積機構
- 観測可能性（トレース・可視化・デバッグ）
- コスト制御・安全ガードレール・人間介入ポイント

単なるReActループではなく、「何が成功して何が失敗したか」を次のイテレーションに活かす**プロセス記憶**を持つのが現代的なハーネスです。[[2]](https://x.com/itarutomy/status/2095346046104674736)

### 2. 推奨アーキテクチャ（2026年現在）

#### 基本形：Stateful Graph + Checkpointing（LangGraph推奨）
- **StateGraph**（LangGraph）でノードと条件付きエッジを定義
- 全ての状態をPydanticモデルで厳密に型付け
- Checkpointer（Postgres / Redisなど）で任意のタイミングで状態を永続化 → 中断・再開・人間修正が可能

**主要ノード例**：
- Planner（計画立案）
- Agent（思考＋Tool Call決定）
- Tool Executor（実行＋検証）
- Critic / Reflector（結果評価・改善提案）
- Supervisor（マルチエージェント時の調整）
- Compiler / Reporter（最終成果物まとめ）

#### 進化形1：Harness-of-Harnesses (HoH)
既存のハーネスの外側にもう一段階ループを置くメタハーネス。
- **Planner**：現在の証拠から次の小さな開発目標を立てる
- **Developer**：目標に基づいて実装・修正
- **QA Tester**：独立してBlackbox + Whitebox検証（別LLM呼び出し推奨）

成功・失敗・回帰情報を「証拠」として次のループに渡すのが強力。長期コーディングベンチマークで大幅にスコアが向上した事例があります。[[2]](https://x.com/itarutomy/status/2095346046104674736)

#### 進化形2：JIT-Agent（Just-In-Time Harness）
タスクごとに最適な「ハーネスそのもの」（思考手順・ツール選択方針・検証方法）を生成し、実行中にエラーを見てハーネス自体を修正・進化させる。
固定ハーネスではなく「ハーネスを学習する」アプローチで、トークン効率と性能の両立に優れる。[[3]](https://x.com/LangChainJP/status/2096969356706034092)

### 3. 設計時に押さえるべき必須要素

| コンポーネント | 設計ポイント（重要度高） | おすすめ実装 |
|----------------------|-----------------------------------------------------|-------------|
| **State Management** | 全てを明示的なStateオブジェクトに。チェックポイント必須 | LangGraph Checkpointer + Postgres |
| **記憶・証拠** | 単なる会話履歴ではなく「成功証拠」「失敗パターン」「回帰記録」を保持 | Vector DB + 構造化Evidenceログ |
| **Tool Layer** | サンドボックス必須、権限レベル、タイムアウト、再試行、結果検証 | E2B / Firecracker、MCP互換、自動テスト |
| **Verification** | Agentとは独立したQA役を必ず入れる（HoHパターン） | LLM-as-Judge + ルールベース検証 |
| **Observability** | グラフ可視化、トレース、コスト・レイテンシ監視 | LangGraph Studio、OpenTelemetry、LangSmith/Phoenix |
| **Human-in-the-Loop**| 重要なアクションは承認ゲートを挟む | 状態を一時停止して人間介入 |
| **Safety & Governance** | 権限最小化、PII検知、ロールバック機構、トークン予算制御 | 専用Guard Node |

### 4. 実装時のベストプラクティス

- **全てをスキーマ化**：Pydantic v2必須。LLM出力もStructured Outputで厳格に。
- **Async First** + Durable Execution：長時間エージェントにはTemporal.ioとの組み合わせが非常に強い。
- **評価を二重化**：Held-out評価セット + 自動スコアリング + 人間評価。
- **可視化を最初に作る**：LangGraph Studioのようなビューがないと複雑なグラフは破綻しやすい。
- **「一度で完璧」を目指さない**：複数パス＋検証＋修正ループを前提に設計。

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

- **コア**：LangGraph（最も成熟）
- **軽量・カスタム派**：fx系やDeepSeek Harnessのようなプラグイン型
- **究極カスタム派**：自分好みのcoding harness（nvim並みに拡張可能にする）
- **観測・運用**：LangSmith / Helicone + Prometheus + Grafana
- **サンドボックス**：E2B、Aider-style、または自前MCPツールライブラリ

### さらに深掘りしたい場合

- 具体的なLangGraphの実装コード例（Medium分析エージェントやDeep Researchパターン）
- Harness-of-Harnessesの詳細設計
- コーディングエージェント特化ハーネス（Terminal BenchでTop5になった事例の再現）
- JIT-Agent風の動的ハーネス生成

どの方向を詳しく知りたいか教えてください。実際のユースケース（研究エージェント、コーディングエージェント、業務自動化など）を教えていただければ、それに最適化した設計図を書きます。