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

2026年現在、AIエージェントの実用化で最も重要なテーマの一つが「**ハーネスエンジニアリング**」です。モデル（LLM）そのものではなく、モデルを取り巻く**実行環境・足場・制御機構**を徹底的に設計することで、信頼性・安全性・再現性を劇的に向上させるアプローチです。[[1]](https://x.com/CobusGreylingZA/status/2043638576848707662)[[2]](https://x.com/_vmlops/status/2057707195933110432)

よく言われる比喩は「**モデルはエンジン、ハーネスは車**」。同じエンジンでも、ハーネス（足回り・制御システム）が貧弱だとすぐに壊れるし、優れたハーネスなら信頼して走らせられる、という意味です。

### 1. ハーネスの核心コンセプト

優れたハーネスは以下の3つの外部化（Externalization）と、それを仲介する運用層で構成されます：

- **Memory（記憶）**：作業コンテキスト、意味的知識、エピソード記憶、個人化メモリ
- **Skills（スキル）**：運用手順、意思決定ヒューリスティック、規範的制約（境界）
- **Protocols（プロトコル）**：ユーザー間・エージェント間・ツール間の契約

これらを仲介する**Operational Layer**：
- Sandboxing（サンドボックス）
- Observability（可観測性・トレース）
- Evaluation / Verification（評価・検証ゲート）
- Approval loops（承認ループ / Human-in-the-loop）
- Sub-agent orchestration（サブエージェント制御）
- Compression（コンテキスト圧縮）

これにより「プロンプトだけ磨く」段階から脱却し、**環境設計そのものが知能の大部分を担う**状態を作ります。[[3]](https://x.com/i/status/2043638576848707662)

### 2. 推奨アーキテクチャ（2026年時点のベストプラクティス）

```mermaid
graph TD
subgraph Core ["Core Orchestrator"]
Loop["Agent Loop
(Plan → Act → Observe → Critique)"]
end

subgraph External ["Externalized Intelligence"]
Memory["Memory System
(Working + Semantic + Episodic + Personal)"]
Skills["Skill Registry + Guardrails"]
Protocols["Protocol Layer
(User/Agent/Tool)"]
end

subgraph Operational ["Operational Layer"]
Sandbox["Sandbox Executor
(Docker/Firecracker)"]
Tracer["Comprehensive Tracer + Logger"]
Evaluator["Evaluator + Verification Gates"]
Meta["Meta-Harness Engine
(Trace-driven Evolution)"]
end

Core <--> External
Core <--> Operational
Operational <--> External
```

**主要モジュール設計**

**1. State & Session Management**
- 毎回「きれいな状態」から開始（clean start/end）
- Persistent State（ファイルシステム or DB）
- Checkpoint機能（失敗時に巻き戻し可能）
- Scope Lock：「1機能ずつ」「完了判定基準を明確に」

**2. Memory System（4層推奨）**
- Working Context：現在のタスク状態（構造化データ推奨）
- Semantic Memory：Vector DB + Graph DB（長期知識）
- Episodic Memory：過去の実行トレース（成功/失敗パターン）
- Personalized Memory：ユーザー固有の好み・履歴

**3. Skill & Tool Registry**
- ツールごとにPermission Level、Pre/Post Condition、Verification Functionを定義
- 「正の参照（仕様・成功例）」と「負の導出（禁止パターン・ガードレール）」を両方管理
- 動的登録可能にしておく

**4. Verification Gates & Evaluator**
- Action実行後に自動検証
- Self-Critique + Multi-Stage Verification
- 閾値を超えたらHuman Approval or Sub-agentに委譲
- 完了宣言は「自分で証明」させる

**5. Observability & Tracer（最も重要）**
- 全ての思考・行動・結果・状態変化を構造化ログ化
- これが**自己改善の燃料**になる（次項参照）
- LangSmith/LangFuse相当の専用ビューアーを用意

**6. Meta-Harness Layer（先進的）**
- 実行トレースからハーネス自体（プロンプト、ワークフロー、ガードレール）を自動改善
- HarnessXのような「合成可能なプリミティブ」として設計
- AIに「ハーネスのコードを書かせる」メタ最適化ループ

### 3. 設計原則（守るべきもの）

- **Externalization First**：可能な限りLLMのコンテキストから知能を外に出す
- **Observability by Design**：何もログを取らないハーネスは作らない
- **Composability**：ハーネスを「手書き」ではなく「組み立てる」ものにする
- **Positive Reference + Negative Derivation**：仕様書を正の参照にし、そこからガードレールを自動導出
- **Scope & Lifecycle Strict**：スコープを狭く、セッションを明確に
- **Fail Fast & Learn**：失敗を前提に設計し、トレースから急速に改善

### 4. 実装技術スタック例（Python中心）

- **Orchestrator**：LangGraph（状態機として最適）または自前実装
- **LLM Abstraction**：LiteLLM（モデルスイッチ容易に）
- **Memory**：PostgreSQL + pgvector + Neo4j（グラフ）
- **Sandbox**：Docker + gVisor または Firecracker（強分離）
- **Tracing**：OpenTelemetry + 専用DB
- **Evaluation**：LLM-as-Judge + ルールベース + 人間フィードバック
- **Frontend/Debug**：Streamlit/Gradio または専用Web UI

**特に推奨**：最初は最小限の didactic（教育的な）ハーネスをゼロから作ってみる。魔法のようなフレームワークに頼ると本質が掴めません。

### 5. さらに進化させるために

- ハーネス自体をバージョン管理・実験管理（MLflow的なもの）
- 複数モデルでのパフォーマンス比較を自動化
- Behavioral Coverage：書いたテストケースだけでなく、リスク経路も自動生成
- サブエージェントによる並列改善ループ

最近の議論では、**同じモデルでもハーネスの質で結果が10倍以上変わる**事例が複数報告されています。特にClaudeや最新モデルでコード生成・リファクタリングを行う場合、ハーネス設計の巧拙がそのまま生産性に直結します。[[4]](https://x.com/neil_xbt/status/2063866362498281573)

---

必要であれば、以下のいずれかを深掘りした詳細設計をお渡しできます：

- 具体的なクラス図・コードスケルトン
- Memory実装パターン詳細
- Meta-Harness（自己改善）機構の設計
- 企業内プロダクション向けガバナンス付きハーネス
- Speaker Deckで共有されている「正の参照と負の導出」手法の適用例

どのような粒度・焦点で設計資料が欲しいか教えてください。実際にプロダクションで使えるレベルまで落とし込んで設計します。