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

2026年現在、AIエージェントの実務投入で最も重要なレイヤーになっています。プロンプトエンジニアリング → コンテキストエンジニアリングの次に来るのが**ハーネスエンジニアリング**です。

### 1. ハーネスとは何か

**AGENT = MODEL + HARNESS**

- **Model**：思考エンジン（CPUに相当）
- **Harness**：手綱・OS・実行環境全体。モデルが暴走しないよう制御し、失敗を学習し、信頼性を高める仕組み全体

多くの場合、性能の50%以上は「モデルそのもの」ではなく「ハーネスの質」で決まります。モデルを変えずにハーネスだけ改善してベンチマークを大幅に向上させた事例（HarnessXなど）が複数報告されています。

### 2. 優れたハーネスの設計原則

**核心原則（これを守らないとすぐに局所最適に陥る）**

- **Verification Before Execution**：LLMが提案した行動をそのまま実行しない。観測証拠・幾何的到達可能性・ポリシー整合性・テスト通過などを**独立した検証層（Jev = Judge/Evaluator）**で確認してから実行。
- **Intelligence Externalization**：可能な限り知能をモデル外に押し出す（記憶、スキル、ルール、プロトコル）。
- **Evolvable & Prunable**：失敗をデータとしてハーネスに蓄積。「逸脱が出たら1行足す」のはOKだが、**定期的にルールを全部捨てて本当に必要なものだけ戻す**運用が必須。技術的負債が溜まりやすい。
- **Separation of Concerns**：考えるモデル、判断するモデル（Jev）、実行するTool、制御するHarness、人間を明確に分離。
- **Observability First**：全ての軌跡（trajectory）を構造化ログとして残し、簡単に分析・再現可能にする。

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

```
[User / Goal]
↓
[Orchestrator (Control Loop)]
↓
├── Memory Layer
│ ├── Hierarchical Event Memory（観測・進捗・失敗・終了判定）
│ ├── Spatiotemporal Graph / Knowledge Graph（環境中心の永続記憶）
│ └── Working Context（圧縮・要約された短期記憶）
│
├── Policy & Rules Engine（AGENTS.md / Rules as Code）
├── Skills & Protocols Registry（手順・ヒューリスティック・対話契約）
├── Tool Registry + Validators（lint,型チェック,テスト,ポリシーチェック）
├── Jev Layer（小型専門判断モデル）← ここが超重要
├── Sandbox & Safety Layer（権限・サンドボックス・承認ゲート）
├── Evaluation & Feedback Engine（自動評価 + 人間評価 + 改善提案）
└── Experiment Tracker / Harness Compiler
```

**Harness Compiler**という考え方も出てきています。ユーザーが「この業務を自動化して」と言うと、大規模モデルが以下を自動設計する：

タスク分解 → 判断ポイント抽出 → Policy生成 → Evaluation生成 → Shadow Mode検証 → 閾値調整 → 本番化

### 4. 実践的な設計ポイント

1. **AGENTS.md / Rules**を最優先で作る
- 「このAgentは何をしてもよいか」「絶対にしてはいけないこと」を明文化
- コードレビューと同じレベルで厳密に運用

2. **Jev（判断専門の小型モデル）を徹底活用**
- 毎回巨大モデルに聞くのは非効率。判断・評価は専門の小型モデルに任せる。

3. **失敗ループの設計**
- 単なるReActループではなく、「失敗→ハーネス更新→検証」の閉ループにする
- 改善は「プロンプトを増やす」ではなく「ハーネスコンポーネントを編集・追加・削除」

4. **定期的なPruning（剪定）**
- 数週間ごとにルール・スキル・回避策を全部見直し、不要なものを削除
- モデルが賢くなると、昔のガードレールが逆に足を引っ張る

5. **Observability & Experimentation**
- LangSmith/Phoenix相当のトレーシングは必須
- 異なるハーネスバージョンをA/Bテストできる仕組みを作る

### 5. 参考になる考え方（2026年現在）

- **HarnessX**：コンポーネントを「置換代数」で定義し、AEGISという多剤エージェントで自動進化させるアプローチ。モデル固定で大幅改善。
- **HarnessVLN**（ロボットナビゲーション）：イベントメモリ + 時空間グラフ + 実行前検証の組み合わせが秀逸。
- LayerX CTO松本勇気氏の指摘：人の役割が「ものを作る」から「ハーネス（Agent）を作る」に完全にシフトしている。

### 始め方（おすすめ）

1. まずは**最小限の didactic harness**を自分で作ってみる（Akshay氏などが公開している考え方を参考）。
2. 1つの限定ドメイン（例：請求書処理、見積書作成、コードレビューなど）で徹底的に磨く。
3. LangGraph + Pydantic厳格スキーマ + 独自Validator群 + 構造化ログが現実的なスタート地点。
4. 「プロンプトを磨く」思考から完全に脱却して、「環境（ハーネス）を設計する」思考に切り替える。

ハーネス設計は今まさに最前線の領域です。モデル選定よりハーネス設計の方が差が出る時代に完全に移行しています。

具体的に「コーディングエージェント向け」「社内業務自動化向け」「物理エージェント（ロボット）向け」など、**どのドメインのハーネス設計**を深掘りしたいか教えてください。より具体的なコンポーネント設計・コード構成・評価指標まで落とし込んでお答えします。