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

2026年現在、「AIエージェント ハーネス」は単なるツール呼び出しのラッパーではなく、**「モデルを制御し、信頼性・生産性・安全性を最大化するためのOSのようなレイヤー」**として認識されています。プロンプトエンジニアリング → コンテキストエンジニアリングの次の段階です。

馬具（Harness）のメタファーの通り、「人間が手綱（steer）を握り、エージェントが実行する」仕組み全体を設計します。モデルはCPU、ハーネスはOSという比喩がよく使われます。[[1]](https://x.com/taimuhanashiro/status/2023008135464788127)[[2]](https://x.com/tetumemo/status/2037876018745385083)

### 1. ハーネス設計の基本原則

- **Steer（手綱）とExecuteの明確な分離**：人間/上位エージェントはゴール・制約・品質基準・評価基準を定義。下位エージェントはそれに従って実行。
- **変更容易性（Maintainability）が最優先**：ハーネスは肥大化しやすい。Gota氏の資料でも指摘されているように、ハーネスが複雑になった時の変更コストを最小化する設計が重要。[[3]](https://x.com/gota_bara/status/2046794926604931447)
- **「何をコードで担保し、何をモデルに任せるか」の境界を明確にする**：全てをLLMに任せると不安定。決定論的な部分はコード、曖昧な判断はモデル、意味的判断は中間レイヤー（semantic decision model）で処理。
- **Observability First**：全てのtrajectory（思考→行動→観測）を構造化ログとして記録。後から分析・改善できないハーネスは失敗。
- **Safety & Guardrails by Design**：入力・出力・ツール呼び出しの全レイヤーでガードレールを入れる。

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

```mermaid
graph TD
Steering[Steering Layer
目標・制約・品質基準・承認ゲート]
--> Orchestration[Orchestration Layer
Agent Loop / Graph / Planner / Reflector]

Orchestration <--> Memory[Memory Layer
Hierarchical Memory
Episodic / Semantic / Procedural]
Orchestration <--> Tools[Tool & Environment Layer
Sandbox + Guardrails + API Connectors]

Orchestration --> Evaluation[Evaluation & Feedback Layer
LLM Judge + Rule-based + Self-Critique]
Evaluation --> Observability[Observability & Experiment Layer
Tracing / Dashboard / A/B Test / Versioning]

Observability --> Steering
style Steering fill:#e3f2fd
style Evaluation fill:#f3e5f5
```

**レイヤーごとの設計ポイント**：

**Steering Layer（最も重要）**
- ゴール記述テンプレート（Success Criteriaを具体的なrubric化）
- 制約（コスト上限、ステップ上限、禁止事項）
- 品質基準（コードなら静的解析・テストカバレッジ・セキュリティ基準）
- Human-in-the-Loop / AI Supervisorのゲート

**Orchestration Layer（心臓部）**
- **LangGraph**（または同等のグラフフレームワーク）を強く推奨。状態遷移を明示的に定義できる。
- 基本パターン：ReAct + Planner + Reflector + Multi-Agent Supervisor
- ループ設計：最大ステップ・タイムアウト・コスト監視を強制的に入れる
- 最近のトレンドは「Agent Loop → JEV（Judgment, Evaluation, Verification）」のような構造化された意思決定フロー

**Memory Layer**
- 単なる会話履歴ではなく階層化（短期・長期・ベクトル・グラフメモリ）
- Context Engineeringの仕組み（要約、圧縮、重要情報抽出）をハーネス内に組み込む
- 目的見失いを防ぐための「Mission State」常時注入

**Tool & Environment Layer**
- 全てのツールを厳格なスキーマ（Pydanticなど）で定義
- Sandbox必須（E2B、Docker、専用runtimeなど）
- Tool callingの前にGuardrail、呼び出し後にもValidation

**Evaluation & Feedback Layer**
- Outcome Evaluation + Process Evaluationの両方
- LLM-as-Judgeは複数モデルで多数決 or 専用Evaluatorモデルを使用
- 自動改善ループ（失敗trajectoryからパターンを抽出し、ハーネス自体を改善）

**Observability Layer**
- 構造化トレース（LangSmith、Phoenix、OpenTelemetryカスタム）
- 失敗モード分析ダッシュボード
- Experiment管理（プロンプトバージョン、ハーネスバージョン、モデル組み合わせのA/Bテスト）

### 3. 設計時に特に注意すべきポイント

1. **ハーネス肥大化対策**（Gota氏の資料が参考になる）
- 責務を明確に分割（Steering / Orchestration / Evaluationは特に分離）
- 抽象化レイヤーを適切に作る（Agent Interfaceを安定させる）

2. **安全性（特に企業利用時）**
- Australian Signals Directorate（ASD）の「Agentic AI Harnesses」文書が参考。モデル上のレイヤーとしてハーネスを位置づけ、ガバナンスを強化している。[[4]](https://x.com/ken5scal/status/2099669888537432276)

3. **スケーラビリティ**
- 非同期実行対応
- コスト・レイテンシ監視をリアルタイムで
- 並列評価実行基盤

### 4. 実装おすすめ技術スタック（2026年9月時点）

- **コア**：LangGraph（最強候補） + Pydantic v2 + Structured Output
- **Memory**：LangGraphのチェックポインター + Vector DB + Graph DB
- **Evaluation**：DeepEval、UpTrain、独自LLM Judge
- **Sandbox**：E2B、Modal、Fireworks AI、または自前Kubernetes sandbox
- **Observability**：LangSmith / Helicone / 自前OpenTelemetryバックエンド
- **実験管理**：MLflow + Weights & Biases または独自実験トラッカー

完全に自作したい場合は、最近公開されているオープンソースハーネス（Hermes、rufloなど）を参考に「60本以上の論文を読み込んだ」アプローチも有効です。

### 5. 次のステップ

- 小さく始める：シンプルなReActループ + 完全なTrajectory Logging + シンプルEvaluatorから構築
- 徐々にSteering LayerとEvaluation Layerを強化
- 「ハーネス自体をエージェントで改善する」自己改善ループを目指す（これが2026-2027の主流になりつつある）

具体的なユースケース（ソフトウェア開発エージェント、RAGエージェント、業務自動化エージェント、研究エージェントなど）を教えていただければ、その領域に特化した詳細設計（クラス図、状態遷移図、評価指標セットなど）をお出しできます。

必要であれば：
- 実際のLangGraph実装コード例
- SpeakerDeck風の設計資料の骨子
- 評価指標の具体的なPromptセット

も提供します。どのような深さで設計したいか教えてください。