**AIエージェントハーネス設計（2026年最新プラクティス）**

「ハーネスエンジニアリング」は、プロンプトエンジニアリングの次のレイヤーとして完全に定着しています。モデルはCPU、ハーネスはOS（実行環境・手綱・足場）という理解が主流です。モデル性能よりハーネスの設計品質が実務成果を大きく左右する時代です。[[1]](https://x.com/DatabricksJP/status/2068976921288052959)

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

**モデル＋ハーネス＝エージェント**です。

ハーネス（Harness）が担うのは以下の変換です：
- LLMの推論・意思決定 → 実際のアクション（ツール実行、状態更新、長期実行）
- 生の知能 → 信頼性・安全性・再現性・観測可能性の高いシステム

主な役割：
- 状態管理（Stateful Execution）
- ツール・権限・サンドボックスの制御
- 記憶・コンテキストの階層管理
- フィードバックループと自己修正
- ガードレール・予算・停止条件
- 完全なオブザーバビリティ

LangGraphは「Runtime寄り」、LangSmithは「Observability寄り」で、ハーネス全体を構築する際の最も実践的な基盤となっています。[[2]](https://x.com/LangChain/status/1993746547587338508)

### 2. 本番運用に必要な8大構成要素（+α）

Databricksが整理した8要素が非常に参考になります。[[3]](https://x.com/i/status/2068976921288052959)

1. **システムプロンプト / 憲法（Constitution）**
DESIGN.mdやJSON化した設計原則を最初に読ませる。AIが常に参照すべき不変のルール。

2. **ツール実行レイヤー**
統一インターフェース（名前、説明、JSON Schema、permission_level、execution_env）。Tool Registry + 自動ドキュメント生成。

3. **サンドボックス**
コード実行、ブラウザ、API呼び出しを隔離。権限は最小原則。

4. **永続ストレージ + 階層型メモリ**
- Working Memory（短期）
- Semantic Memory（ベクトル）
- Episodic Memory（過去の軌跡）
- Procedural Memory（スキル・プレイブック）
三層〜四層記憶アーキテクチャが2026年の主流。

5. **コンテキスト管理 & Observation Cleaning**
生のターミナル出力やログをそのまま渡さない。中間層で「本当に重要な情報だけ」にクリーニングしてからエージェントに渡す。これが意外と重要。

6. **フィードバックループ（Loop Engineering）**
- Inner Loop：実行ループ（Plan → Execute → Observe）
- Outer Loop：監督・検証ループ
**Planner → Generator ↔ Evaluator** の分離が特に有効（自己評価バイアス対策）。

7. **ガードレール & 制御機構**
- 最大ループ回数・トークン予算
- 人間介入条件（HITL）
- 停止条件・エスカレーション
- コスト・安全ガード

8. **オブザーバビリティ & 評価基盤**
すべての思考・行動・観測をトレース（LangSmith推奨）。LLM-as-Judge + Rubric + 人間フィードバックの組み合わせ。

**追加推奨要素**：
- Explicit State Graph（LangGraph）
- Multi-Agent Orchestration（Supervisor + Specialist）
- Evaluation Harness（オフライン評価 + オンラインA/Bテスト）

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

**最強組み合わせ（実績多数）**：
- **Orchestration**: LangGraph（StateGraph + conditional edges）
- **Observability**: LangSmith（またはOpenTelemetry + 自前ダッシュボード）
- **LLM Abstraction**: LiteLLM または OpenRouter
- **Memory**: PGVector + Redis + GraphDBの組み合わせ
- **Evaluation**: Rubricベースの専用Evaluator Agent

**設計パターン**：
- **Hierarchical**（監督者＋専門エージェント）
- **Graph-based**（すべての分岐を明示的に定義 ← 信頼性重視）
- **Scaffolding that can be removed**（モデルが賢くなったらハーネスを簡略化できる設計にする）

Anthropicは比較的「Thin Harness」（モデルを信頼）、LangGraph派は「Thick Harness」（制御を明示的に書く）という違いがありますが、どちらも「Harness is the Product」という認識は共通です。[[4]](https://x.com/akshay_pachaar/status/2042586319390674994)

### 4. 設計時に必ず決めるべきこと（チェックリスト）

- コンテキストは「段階的に渡す」（地図を全部一度に渡さない）
- 最大試行回数・トークン予算・コストアラート
- 人間が介入する明確な条件（何を人間が最終判断するか）
- Evaluatorは必ずGeneratorと分離（自己評価バイアス対策）
- Observation Cleaningレイヤーの有無
- 失敗時の「ゴミ捨て（Garbage Collection）」戦略（古いコンテキストの圧縮）
- 評価Rubricの明文化（「美しいか」ではなく「設計原則を満たしているか」）

### 5. 実装の優先順位（MVP → 本番）

1. **Minimal Harness**（LangGraph + 基本ツール + LangSmithトレース）
2. **Memory & State設計**（これが一番泥臭い）
3. **Evaluation Harness構築**（Golden Dataset + Rubric + LLM Judge）
4. **Safety & Control Layer**（予算・ループ制限・HITL）
5. **Multi-Agent & Long-horizon対応**（Deer Flowなどの長時間エージェント参考）

### おすすめ学習リソース（2026年時点）

- Anthropic「Harness design for long-running application development」
- Databricks「AI Harness」ブログ
- OpenAIの内部事例（100万行コード自動生成）
- LangChainのTerminal Bench改善事例

---

ハーネス設計は「AIがどう動くか」ではなく「AIが**どんな環境で**動くか」を決める仕事です。これからのAIエンジニアリングの本質はここにあります。

具体的なユースケース（コーディングエージェント、業務自動化エージェント、研究エージェントなど）があれば、その用途に最適化した設計図をさらに深掘りして書きます。必要であればLangGraphの具体的なState Schema例や評価Rubricのテンプレートも提供可能です。