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

2026年現在、AIエージェントの実用化で最も重要なテーマの一つが「**ハーネスエンジニアリング**」です。プロンプトエンジニアリング、コンテキストエンジニアリングの次のレイヤーとして定着しています。[[1]](https://x.com/tetumemo/status/2037876018745385083)

### ハーネスとは何か

**ハーネス（Harness）**とは、馬具（手綱・鞍）のメタファーで、AIエージェント（特にLLM）の力を**制御・方向づけ・安全に成果につなげるための周辺インフラ全体**を指します。

- 「**モデルはCPU、ハーネスはOS**」という比喩が秀逸です。
- モデル単体の性能向上には限界があり、同じモデルでもハーネスの質で性能が2〜5倍以上変わります（Terminal Benchなどで実証済み）。
- OpenAIの事例では、ハーネス設計により**人間が1行もコードを書かずに5ヶ月で約100万行・1500PRの社内プロダクトを構築**した事例があります。[[2]](https://x.com/taimuhanashiro/status/2023008135464788127)

要するに、**「何を指示するか」より「どんな環境で動かすか」**が勝負の時代です。

### 推奨アーキテクチャ（2026年現在の収束形）

現代的なハーネスは**「Thin LLM + Thick Orbiting Layers」**が主流です。モデル自体は薄く保ち、知能を外部化します。

```
[ Memory ]
↑↓
[ Protocols ] ←→ [ Harness Core (Mediator) ] ←→ [ Skills ]
↑↓
[ Environment / Tools / User ]
```

**主要レイヤー**（Akshay / Cobus Greylingらのフレームワークを基に整理）：

1. **Memory Layer**（状態管理）
- Working Context（現在進行中のタスク）
- Semantic Memory（知識・ベクターDB）
- Episodic Memory（過去の軌跡・失敗学習）
- Long-term / Personalized Memory

2. **Skills Layer**（手順・判断基準）
- Operational Procedures（SOPs）
- Decision Heuristics（意思決定の癖）
- Normative Constraints（「やるべきこと」「やってはいけないこと」）

3. **Protocols Layer**（契約）
- Agent ↔ User
- Agent ↔ Agent（マルチエージェント）
- Agent ↔ Tools / Environment

4. **Mediator（ハーネスの心臓部）**
- Sandboxed Tool Execution
- Observability & Structured Logging（全ステップを再現可能に）
- Evaluation / Reflection Loop（セルフレビュー）
- Approval & Human-in-the-Loop
- Context Compression & Routing
- Guardrails & Policy Engine

### 設計の核心原則

**1. 正の参照 + 負の導出**（最も実践的）
- **正の参照**：DESIGN.md（憲法）、仕様JSON、成功ルーブリック
- **負の導出**：禁止事項リスト、ガードレール（仕様から自動生成も可能）
- これで「美しいデザインか？」のような主観も「設計原則に準拠しているか？」に変換可能。[[3]](https://x.com/tsubotax/status/2042861698491781557)

**2. 生成と評価の分離（最重要）**
- AIは自分が出したものを過大評価する（自己評価バイアス）。
- 必ず「生成エージェント」と「評価エージェント（Critic）」を分ける。Anthropicも強く推奨。

**3. Thin vs Thickのバランス**
- **Anthropic寄り**：モデルが賢くなればハーネスを薄く削除（scaffoldingは一時的）。
- **LangGraph寄り**：明示的なグラフで決定論的制御を厚くする。
- ベストは「**取り外し可能なscaffolding**」として設計すること。モデルが進化したらハーネスも進化させる。

**4. Observability First**
- 全ての実行を構造化ログ化（LangSmith/Langfuse推奨）。
- 同じ入力で完全に再現可能（replayability）にする。

### 実装のための設計ステップ

1. **要件定義**
- 対象ドメイン（コーディング、研究、業務自動化など）
- 成功指標（Success Rate, Step Efficiency, Cost, Safety Score）

2. **憲法・仕様レイヤー作成**
- DESIGN.md（最上位原則）
- 仕様のJSON化（28コンポーネント + 89禁止ルールなどの事例あり）
- ルーブリック（評価基準）の整備

3. **Orchestration Layer設計**
- LangGraphでStateGraphを作成（Nodes: Planner, Actor, Evaluator, Reflector）
- またはOpenAI Agents SDK / CrewAI Flows

4. **Safety & Control Plane**
- Tool権限システム
- Budget / Rate Limit / Rollback機構
- 出力ガード（LlamaGuard系）

5. **Evaluation Harness構築**
- Synthetic test cases生成
- LLM-as-Judge（別エージェント）
- 失敗トレースからの自動改善ループ（Self-Improving Harness）

6. **Iterative Improvement**
- 生産環境のトレースを収集 → ハーネス自体を改善（これが次のモデルのトレーニングデータにもなるフライホイール）。

### おすすめ技術構成（2026年）

- **Orchestration**: LangGraph（最も完成度が高い）
- **Observability**: LangSmith + Phoenix
- **Memory**: Mem0 / Zep または PGVector + Redis
- **Evaluation**: DeepEval (Agent版) + カスタムルーブリック
- **Safety**: Constitutional AI + Policy Engine

### 実例での効果

- LangChainチーム：ハーネス改善だけでTerminal Bench 2.0でTop30→Top5にジャンプ。
- Anthropic事例：ソロエージェント（失敗）→ 3エージェント構成（高品質完成）でコスト20倍でも品質が段違い。
- デザインシステムでも「DESIGN.md + JSON仕様 + 検証ハーネス（CIで自動停止）」で維持可能性が劇的に向上。

---

**まとめると**、2026年のAIエージェント開発で最もレバレッジが高いのは**ハーネス設計**です。モデル選びで消耗する時代は終わり、「同じモデルをどれだけ賢く、安全に、長く動かせる環境を設計できるか」が競争力になります。

具体的なドメイン（例：コーディングエージェント、Web Agent、社内業務エージェントなど）が決まっていれば、さらに具体的なアーキテクチャ図やコードスケルトン、DESIGN.mdのテンプレートをお渡しできます。どの部分を深掘りしますか？