**AIエージェント ハーネス設計（2026年現在のベストプラクティス）**

2026年現在、AIエージェントの成否を決める最大の要因は**モデルそのものではなく「Harness（ハーネス）」**です。同じモデル・同じプロンプトでも、ハーネスの設計次第で性能が42%→78%に跳ね上がる事例が複数報告されています。[[1]](https://x.com/chenchengpro/status/2037332209003282747)[[2]](https://x.com/i/status/2037332209003282747)

**Harness Engineering**とは：
- エージェントを包む「手綱（harness）」全体のシステム設計
- 失敗が発生したら「モデルを祈る」のではなく、ハーネスを修正して**二度と同じ失敗を起こさない**ようにエンジニアリングする思想
- 2023年のPrompt Engineering、2025年のContext Engineeringの次のステージ

### 1. ハーネスの全体アーキテクチャ（推奨レイヤリング）

```
[User / Supervisor]
↓
[Core Harness Engine] ← 状態マシン・Loop Controller (LangGraph推奨)
├── Instruction Layer (System Prompt + Skills + Protocols)
├── Memory Layer (Working / Semantic / Episodic / Procedural)
├── Tool & Action Layer (Sandbox + Approval Gate + MCP)
├── Verification & Eval Layer (Hooks + LLM-as-Judge + Human-in-the-Loop)
├── Observability Layer (Tracing / Logging / Metrics)
└── Safety & Guardrail Layer (Permission / Jailbreak Detection / Escalation)
↓
[Sub-agents / External Tools]
```

**設計の鉄則**：
- モデルは「薄く」保つ（知能を外側のレイヤーに押し出す）
- ハーネスが肥大化しやすいため、**変更容易性（Maintainability）を最優先**にする
- 長い自律ループではなく、**短く監査可能なLoop**を複数組み合わせる（Loop Engineering）

### 2. 主要構成要素と設計ポイント

#### (1) Instruction Layer（最もインパクト大）
- **System Promptファイル**（CLAUDE.mdスタイル）：60行以内に硬いルールのみ記述。AI生成のプロンプトは避ける（トークン増 + 性能低下の原因）。[[1]](https://x.com/chenchengpro/status/2037332209003282747)
- **Skills**：手続き的知識をモジュール化。「漸進的開示（Progressive Disclosure）」で必要な時だけロード。全部詰め込まない。
- **Protocols**：Agent-User、Agent-Agent、Agent-Toolの契約を明確化。

#### (2) Memory Layer
- Working Memory（現在のタスク状態）
- Semantic Memory（Vector DB：PGVector / Qdrant）
- Episodic Memory（過去の実行履歴）
- Procedural Memory（Skillsとしてコード化）

#### (3) Tool & Action Layer
- 同時に有効にするツールは**最大3つ**まで（Tool Thrashing防止）。[[1]](https://x.com/chenchengpro/status/2037332209003282747)
- MCPサーバーやSandboxを必ず挟む
- 重要なActionには**Approval Gate（人間承認）**を入れる

#### (4) Verification & Eval Layer（これが信頼性を決める）
- **Hooks**：ワークフロー关键点に確定性チェックを挿入（PreCompletionChecklistが特に効果大）。
- タスク完了宣言前に「本当にDoneか？」を複数角度で検証。
- EvalはLLM-as-Judge + ルールベース + 人間フィードバックのハイブリッド。

#### (5) Observability Layer
- Tracing（LangSmith相当）：思考プロセスを完全に可視化
- 各Loopの入力・出力・中間状態をログ
- 週次レビュー用の失敗アーカイブを自動生成

#### (6) Safety & Guardrail Layer
- 特に企業利用では最重要。認証情報はエージェント本体から完全に分離。
- 権限境界、出力フィルタリング、エスカレーションパスを最初から設計。

### 3. Loop Engineering（ハーネスを動かす心臓部）

基本ループ：**Reason → Act → Observe → Verify → Adjust**

これをドメインごとに複数設計：
- 短い検証ループを重視（長時間自律は監査不能で危険）
- 各ループに明確な停止条件・エスカレーション条件を設定
- 実世界フィードバックをハーネスに還元する閉ループを作る

### 4. 設計時の優先順位（ハーネス肥大化対策）

ハーネスは必ず肥大化します。以下の優先順位で設計してください（FindyのGota氏の資料が非常に参考になります）。[[3]](https://x.com/gota_bara/status/2046794926604931447)

1. **変更容易性・モジュール性**
2. 再利用性
3. 観測可能性
4. 安全性
5. 性能

SkillsはOSS（skillportなど）で管理、Hooksはミドルウェア化、Contextは圧縮・正規化を徹底。

### 5. 技術スタック例（2026年実践的構成）

- **Orchestration**: LangGraph（状態管理最強）
- **LLM抽象化**: LiteLLM
- **Observability**: LangSmith / Arize Phoenix / OpenTelemetry
- **Memory**: PostgreSQL + PGVector + Neo4j（Graph Memory）
- **Skills管理**: 専用フレームワーク or 自作モジュールシステム
- **Deployment**: FastAPI + Temporal.io（長時間ワークフロー）+ Kubernetes

プロトタイプは**LangGraph + LangSmith**から始めるのが最も早いです。

### 始め方（今週からできること）

1. 既存のエージェントの全失敗をリストアップ
2. 各失敗に対して「どうハーネスで防ぐか」を1つずつルール/Skill/Hook化
3. System Promptを「硬いルール中心・60行以内」にリファクタ
4. 最低1つのVerification Hookを入れる
5. Tracingを完全に入れて人間が全思考プロセスを見えるようにする

これを毎週繰り返すだけで、エージェントはモデルをアップデートしなくても着実に強くなります。

---

**参考資料（特に重要）**
- Chen Cheng氏の「Harness Engineering」投稿（5つのレバー解説）
- Gota氏のSpeaker Deck「無駄に肥大化するハーネスの設計」
- Philipp Schmid氏のAgent Harness論（高レベル視点）

実務でハーネスを設計している方、特定のドメイン（コーディング、業務自動化、研究など）の詳細設計が必要でしたら、具体的に教えてください。より深掘りしたアーキテクチャ図やコード例、Skillの分割戦略などを提供できます。