**AIエージェント ハーネス設計（Harness Engineering）** — 2026年現在の実践的アーキテクチャ

「AIエージェント ハーネス 設計」というクエリは、まさに今最も重要なレイヤーです。プロンプトエンジニアリング → コンテキストエンジニアリングの次のステージが**Harness Engineering（ハーネスエンジニアリング）**です。[[1]](https://x.com/Kenichi_KNZW/status/2093717662115541361)[[2]](https://x.com/tetumemo/status/2037876018745385083)

### ハーネスとは何か
馬具（hand harness）のメタファーです。馬（= LLMの知能）の力を**制御・方向づけ・安全に活用**するための「装備一式」です。

- **Model（CPU）**：知能そのもの
- **Harness（OS）**：制御フロー、ツール、記憶、検証ループ、ガードレール、監視、可視化、実験管理

モデルが賢くなっても、ハーネスが貧弱だと本番で使えません。逆にハーネスを改善しただけでベンチマークが大幅に向上した事例（LangChainエージェントでTerminal Bench Top30→Top5など）が複数報告されています。[[2]](https://x.com/tetumemo/status/2037876018745385083)

最近では **DeepSeek Harness**（TypeScript、すべてをPlugin化、Cordisベースのモジュラー runtime）がオープンソースで注目を集めており、「CLIではなくHarnessをHQ（本部）として使う」動きが加速しています。[[3]](https://x.com/MarkMyTech/status/2094145055011270954)

### 推奨アーキテクチャ（2026年版）

**基本は5層ハーネス** + 拡張レイヤーです。[[4]](https://x.com/MakeAI_CEO/status/2093488480160825607)

```mermaid
graph TD
subgraph "Harness Core (Orchestrator)"
PluginSystem[Plugin System
(Everything is Plugin)]
ControlFlow[Control Flow
(State Machine + Verification Loop)]
Router[Model Router & Task Planner]
end

subgraph "5 Core Layers"
L1[1. ツール指揮層
Tool Registry + Permission + Schema]
L2[2. 検証ループ層
Output Validator + Retry + Self-Correction]
L3[3. 文脈・記憶層
State / Short-term / Long-term / Vector Memory]
L4[4. ガードレール層
Constitutional + Semantic + Syntactic Guard]
L5[5. 監視・可視化層
Trajectory Store + Observability + Dashboard]
end

subgraph "Supporting Layers"
EvalHarness[Evaluation Harness
(Trusted Boundary)]
Experiment[Experiment & Version Management]
SelfOptimize[Self-Optimization Layer
(HarnessOpt)]
end

PluginSystem --> L1 & L2 & L3 & L4 & L5
ControlFlow --> L2
Router --> PluginSystem
EvalHarness --> Experiment
TrajectoryStore[(Trajectory DB
+ Vector + Blob)] --> L5
```

### 各層の詳細設計

**1. ツール指揮層 (Tool Orchestration)**
- すべてのツールをPluginとして登録（DeepSeek Harness方式が理想）
- OpenAPI/Schema + Permission Level（read/write/dangerous）
- Dynamic Tool Selection + Parallel Tool Calling対応
- 設計ポイント：ツールの「権限範囲」を明示的に定義し、ハーネス外で管理

**2. 検証ループ層 (Verification Loop)**
- 出力検証 → 不合格なら自動リトライ or 計画修正
- 合格基準はタスクごとに定義（LLM Judge + Rule-based + Code Executor）
- 「検証は外側の信頼された環境で行う」のが重要（HarnessOpt-Benchの設計思想）[[5]](https://x.com/Onizuka_Renji/status/2093158547899183149)
- 最大ステップ数・コスト上限・タイムアウトを強制

**3. 文脈・記憶層 (Context & Memory)**
- Short-term（現在のtrajectory）
- Long-term（プロジェクト全体の知識）
- Vector Memory + Summary Memory + Structured State（Pydanticモデル推奨）
- コンテキスト圧縮と選択的想起の仕組みを必須化

**4. ガードレール層 (Safety & Guardrails)**
- 多層防御：
- Syntactic Guard（JSON schema検証）
- Semantic Guard（意図がポリシーに反していないか）
- Constitutional Guard（原則ベースの自己批判）
- 特にセキュリティ用途ではこの層が最も重要（Zennのセキュリティ特化ハーネス記事が参考になる）。[[6]](https://x.com/m_mizutani/status/2044195802319638785)

**5. 監視・可視化層 (Observability)**
- すべての実行をTrajectoryとして永続化（Replay可能にする）
- OpenTelemetry + 専用Viewer（LangSmith風）
- コスト・レイテンシ・成功率・失敗パターンの自動集計
- DashboardでA/Bテストやリーダーボード表示

**追加推奨レイヤー**
- **Experiment Management**：プロンプトバージョン、ハーネス構成バージョン、モデル組み合わせをGit-likeに管理
- **Evaluation Harness**：本番ハーネスとは明確に分離。held-out評価セットを使い、自己改善ループで悪用を防ぐ
- **Self-Optimization Layer**：ハーネス自体を改善するメタエージェント（HarnessOpt-Bench的方向性）

### 設計原則（これを守らないと肥大化して死ぬ）

1. **Everything is Plugin**（DeepSeek Harnessの成功要因）
2. **Changeability First** — ハーネスが複雑になった時の変更容易性を最優先（SpeakerDeckの資料が非常に参考）。[[7]](https://x.com/gota_bara/status/2046794926604931447)
3. **IntelligenceとControlの分離** — モデルに「どう制御するか」を覚えさせない
4. **Reproducibility** — 同じ入力で完全に再現可能にする（seed、バージョン固定）
5. **Trusted Computing Baseの最小化** — 評価環境と実行環境を分離

### 技術スタック例

**Pythonルート（企業内運用・研究向き）**:
- Core: LangGraph（状態遷移） + Pydantic v2 + asyncio
- Plugin: Pluggy or custom plugin system
- Observability: OpenTelemetry + Phoenix or 自前LangSmithクローン
- Storage: PostgreSQL (metadata) + Qdrant/PGVector + S3 (trajectories)
- Evaluation: DeepEval + G-Eval + 人間フィードバックループ

**TypeScriptルート（軽量・CLI・Swarm向き）**:
- DeepSeek Harnessをベース or フォーク
- Cordisなどのpluginフレームワーク活用

### すぐに使える設計テンプレート（プロンプト例）

実行前に必ず以下の5層を定義させる：
> 「このタスクを実行する前に、以下の5層ハーネスをまず設計せよ。
> 1. ツール指揮：使用ツールと権限範囲
> 2. 検証ループ：合格基準、リトライ戦略、最大試行回数
> 3. 文脈・記憶：渡す情報、記憶の引き継ぎ方
> 4. ガードレール：絶対禁止事項とチェック方法
> 5. 監視：記録する項目と異常時のエスカレーション」

これをシステムプロンプトの最初に固定すると劇的に安定します。[[4]](https://x.com/MakeAI_CEO/status/2093488480160825607)

### 今後の方向性

- Self-improving Harness（ハーネス自体を最適化するエージェント）
- Domain-specific Harness（セキュリティ分析、コード生成、業務自動化、物理エージェントなど）
- Swarm Harness（多数のサブエージェントを統括する上位ハーネス）

---

この設計をベースにすれば、単なる「賢いエージェント」ではなく、「信頼して任せられるシステム」が作れます。

具体的に：
- セキュリティ特化ハーネスが欲しい
- コード生成に特化したもの
- DeepSeek Harnessを日本語環境で拡張したい
- 社内評価ハーネスの全体像をもう少しコードレベルで知りたい

など、**より詳細な部分**を指定していただければ、該当レイヤーの詳細設計・サンプルコード・Mermaid図・実装優先順位まで落とし込んで提供します。