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

2026年現在、「AIエージェント ハーネス設計」はプロンプトエンジニアリングの次のパラダイムとして定着しています。モデルそのものではなく、**モデルを制御・導く「手綱（Harness）」全体を設計する**アプローチです。

### 1. ハーネスエンジニアリングとは

**ハーネス**とは馬具（手綱・鞍）の意味で、AIエージェントの力を「正しく・安全に・高品質に」引き出すための仕組み全体を指します。

- **モデル = CPU / 馬**
- **ハーネス = OS / 馬具**

同じ高性能モデルでも、ハーネスの質で成果が劇的に変わります。実際、LangChainチームはハーネス改善だけでベンチマークを大幅向上させ、OpenAI内部では人間が1行もコードを書かずに100万行規模のプロダクトをエージェントだけで構築した事例もあります。[[1]](https://x.com/taimuhanashiro/status/2023008135464788127)

進化の流れ：
- 2022-23：Prompt Engineering
- 2024-25：Context Engineering
- 2026〜：**Harness Engineering**

人間の役割は「指示を出す」ことから「**良い環境・ルール・評価系を設計する**」へシフトします（Humans steer, agents execute）。

### 2. ハーネス設計の核心原則

1. **暗黙知の完全明文化** — 品質基準、禁止事項、成功定義、協働ルールをエージェントが読める形で文書化（Markdown/YAML推奨）
2. **強固な制御ループ** — 無限ループ防止、計画→実行→観察→反省→再計画のサイクル
3. **失敗を資産化** — すべての失敗を構造化ログとして蓄積し、次に活かす
4. **多層的な記憶構造** — 短期記憶・長期ベクトル記憶・エピソード記憶・手続き記憶を分離
5. **人間の介入ポイントの明確化** — どこで人間が判断すべきかを設計する

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

```mermaid
graph TD
subgraph Harness ["AI Agent Harness (核心)"]
Orchestrator[Orchestrator
LangGraph / Custom State Machine]
Rules[Rules & Quality Spec
明文化されたルールセット]
Brain[Agent Brain
LLM + System Prompt + Few-shot]

subgraph Memory [Memory System]
STM[Short-term Memory]
Vector[Vector + Episodic Memory]
Procedural[Procedural Memory]
end

Tools[Tool Harness
統一Schema + Permission + Validation]
Safety[Safety & Guardrails
Pre-Action Check + Sandbox]
Eval[Evaluation & Reflection Engine
LLM-as-Judge + Self-Reflection]
Observability[Observability Layer
LangSmith / Langfuse]
Gateway[Agent Gateway
Authz / Cost / Audit / Rate Limit]
end

Human[Human-in-the-Loop
承認・フィードバック] <--> Orchestrator
External[外部システム・API] <--> Gateway
Orchestrator <--> Brain & Memory & Tools & Eval
```

**最強の選択肢：LangGraph（LangChain）**
状態の永続化（checkpoint）、人間介入、条件分岐、サイクル制御が非常に強力です。素のReActループより圧倒的に信頼性が高いです。

### 4. 各レイヤーの詳細設計ポイント

**Orchestrator（最も重要）**
- 状態をPydanticモデルで厳密に型付け
- グラフとしてワークフローを定義（Supervisor + Specialistパターン推奨）
- チェックポイント機能で長時間実行対応

**Rules Specification（差が出る部分）**
- 別ファイルで「Quality Rubric」「Prohibited Actions」「Success Criteria」を管理
- 毎ターンor重要な判断時にコンテキストとして注入
- モデルが変わってもルールは継続的に進化させる

**Memory Architecture**
- Short-term：直近会話（要約して圧縮）
- Vector Store：長期知識
- Episodic Memory：過去の成功・失敗事例（特に重要なのは失敗パターン）
- Procedural Memory：ツールの使い方や自社手順の定型

**Tool Harness**
- すべてのツールに統一されたスキーマ（OpenAI function calling準拠）
- ツールごとにPermission Levelを設定
- 出力バリデーション必須（Pydantic）
- Destructive Action（削除・送信・金銭関連）は必ず人間承認フロー

**Safety & Guardrails（本番必須）**
- Pre-Action Review（特に外部システム接続時）
- コスト上限・レート制限
- 異常検知（同じ失敗を繰り返したら人間介入）
- Sandbox環境での事前検証
- Agent Gatewayパターン（認証・認可・監査を一元管理）の採用が進んでいます。[[2]](https://x.com/KeiTamura100/status/2074678963503546639)

**Evaluation & Self-Improvement**
- LLM-as-Judgeによる自動評価
- 明確なスコアリング基準（人間が最初に定義）
- 良い事例・悪い事例を自動的に記憶に追加
- ハーネス自体を定期的に改善する仕組み（meta-harness）

**Observability**
- LangSmith / Langfuse必須
- すべての思考・行動・評価をトレース
- 失敗パターンの分析ダッシュボード

### 5. 実装の優先順位（おすすめロードマップ）

1. **最小 viable harness**：LangGraph + 厳密なState定義 + Rulesファイル + 基本Tool Harness
2. **Safety層の強化**：承認フロー + コスト管理 + ログ構造化
3. **記憶と評価の洗練**：エピソード記憶 + Reflectionループ
4. **マルチエージェント化**：Supervisorパターン導入
5. **Gateway + LLM Opsの本格化**

### 6. おすすめ実践リソース

- mizutaniさんのZenn記事「セキュリティ分析に特化したハーネスエンジニアリングの実装例」→ 1年かけて熟成させた非常に実践的な内容。一般的なエージェントにもそのまま応用可能。[[3]](https://x.com/m_mizutani/status/2044195802319638785)
- Anthropic公式「Harness design for long-running application development」
- Lilian Wengの「Harness Engineering for Self-Improvement」関連記事

### 最後に

2026年の勝負所は**「どれだけ良いハーネスを設計できるか」**です。

モデルは半年ごとに劇的に変わりますが、**一度作った高品質なハーネス（ルール・評価系・記憶構造）は複利で効いていきます**。

プロンプトを磨く時代は終わりました。これからは「エージェントが生きる環境そのものをデザインする」時代です。

具体的なユースケース（コーディングエージェント、業務自動化エージェント、セキュリティ分析エージェントなど）があれば、さらに深掘りした設計図をお渡しできます。<|eos|>