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

2026年現在、最も重要なAIエージェント設計の考え方の一つが「**ハーネスエンジニアリング**」です。プロンプトエンジニアリング → コンテキストエンジニアリングの次のレイヤーとして、急速に注目されています。[[1]](https://x.com/tetumemo/status/2037876018745385083)

### ハーネスとは何か？

**馬具（harness）のメタファー**から来ています。馬（＝高性能なLLM）の力を最大限に引き出しつつ、暴走させず、安全に目的の方向へ導く「手綱・鞍・装備一式」のことです。

> 「モデルはCPU（またはエンジン）、ハーネスはOS（または車）」

同じモデルを使っても、ハーネスの質で性能が**劇的に変わる**ことが実証されています（例: LangChainチームがTerminal BenchでTop30圏外→Top5に躍進）。OpenAIが5ヶ月で人間が1行もコードを書かずに100万行のプロダクトを構築した事例も、ハーネス設計の成果です。[[2]](https://x.com/taimuhanashiro/status/2023008135464788127)

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

1. **環境設計 > モデル能力**
進捗が遅い原因のほとんどはモデルではなく、ハーネス（環境）の未成熟。

2. **作る役と評価する役を分離**（最重要）
AIは自分の生成物を過大評価する（自己評価バイアス）。必ず別エージェントに評価させる。

3. **正の参照 + 負の導出**
「こうあるべき（Positive Reference）」と「これをしてはいけない（Negative Derivation）」を両方明示的に設計。

4. **Scaffolding（足場）は一時的**
モデルが賢くなるにつれ、ハーネスを**薄く**していく（AnthropicのClaude Codeは定期的に不要なステップを削除）。ただし、モデルが特定のハーネスで学習されている場合は慎重に。

5. **失敗を前提にした設計**
小さく作って検証→原因切り分け→CLAUDE.md / Skills / Constitutionに反映のサイクルを高速化。

### 推奨アーキテクチャ（2026年現在のベストプラクティス）

ハーネスは以下の**4〜7層構造**で設計することをおすすめします：

**Layer 0: Constitution（憲法）**
- `DESIGN.md` / `CLAUDE.md` / `AGENTS.md`
- 設計原則、品質基準、禁止事項、評価ルーブリックを記述
- エージェントが最初に必ず読むドキュメント

**Layer 1: Context（文脈管理）**
- 必要な情報だけ段階的にロード（「地図を渡せ」）
- 外部化メモリ：ファイルシステム + ベクトルDB + エピソード記憶
- Working Context / Semantic Memory / Episodic Memoryを分離

**Layer 2: Constraints & Protocols（制約・契約）**
- ツールの権限範囲（Path scoping）
- 禁止パターン（rm -rfの危険パス、生産環境アクセスなど）
- Agent-User / Agent-Agent / Agent-Toolのプロトコル定義
- Guardrails + Schema Validation

**Layer 3: Orchestration（制御中枢）**
- **選択肢**:
- Thin：シンプルReActループ（Anthropic寄り）
- Thick：LangGraphによる明示的状態遷移グラフ（制御重視）
- Hybrid：Supervisor + Sub-agent構成

**Layer 4: Verification & Reflection（検証・内省）**
- 独立したEvaluator Agent
- Rubric-based評価（「美しいか？」ではなく「設計原則を満たしているか？」）
- 自己改善ループ（計画→実行→観察→改善）

**Layer 5: Feedback & Evolution（学習・進化）**
- 人間の修正や失敗トレースを自動的に憲法やスキルに反映
- Self-Harness（エージェントが自らのハーネスコードを提案・評価・適用）

**Cross-cutting Concerns**
- Observability（完全トレーシング）
- Sandbox + Approval Gates + Resource Limiting
- Audit Log + Human-in-the-Loop

### 実践的な始め方

1. **まずは小さく**
- 対象ドメインの`DESIGN.md`を作成
- 正の仕様と負の禁止事項を明確化
- 「作るエージェント」と「検証エージェント」を分離して動かしてみる

2. **技術スタック例**
- **最高峰**: LangGraph + LangSmith（観測可能性最強）
- **バランス型**: CrewAI Flows + カスタムEvaluator
- **薄型志向**: AnthropicのClaude Codeパターン（シンプルループ）
- 観測: OpenTelemetry + Phoenix / LangSmith
- 安全: Llama Guard系 + カスタムガードレール

3. **評価指標**
- タスク成功率
- コスト効率（トークン使用量）
- 安全違反率
- 自己改善サイクル速度

### 今後の方向性

- Self-Improving Harness（ハーネス自体をAIが進化させる）
- ハーネスがモデル weights に吸収されていく過程（ただし完全に無くなるわけではない）
- プロダクション向け：多テナント、RBAC、リソース隔離、監査（ハーネスだけでは不十分な領域）

---

**参考文献・元ネタ（重要）**:
- Anthropic Engineering Blog "Harness Design for Long-Running Applications"
- OpenAIの内部事例（5ヶ月100万行プロジェクト）
- Akshay氏・Cobus Greyling氏らの「The Model is not the Agent, the Harness is」議論
- 日本語圏では@tetumemoさん、@tsubotaxさん、@kajikentさん、@seikei_kinさんらの解説が秀逸

具体的なドメイン（コーディングエージェント、研究エージェント、カスタマーサポートエージェント、自治型エージェントなど）で設計したい場合、**用途を教えてください**。その用途に最適化したレイヤー構成・憲法テンプレート・LangGraph実装パターンをさらに深掘りします。