**AIエージェント ハーネス設計（2026年最新プラクティス）**

「AIエージェント ハーネス設計」は、現在最も重要なトピックのひとつです。2026年現在、**プロンプトエンジニアリング → コンテキストエンジニアリング → ハーネスエンジニアリング**が主流となっています。モデルそのものより、周囲の「手綱（Harness）」をどれだけ強く設計できるかが、信頼性・生産性・安全性を決めます。

多くの専門家が繰り返す核心はこれです：

> 「The model is not the agent. The harness is.」
> LLMはエンジン。ハーネスが車体であり、OSである。[[1]](https://x.com/CobusGreylingZA/status/2043638576848707662)

### 1. ハーネスエンジニアリングの本質

ハーネスとは、以下のすべてを指します：

- **永続状態（State）** — 単なる会話履歴ではなく、ノートブック的な長期記憶
- **検証ゲート（Verification Gates）** — 「完了」と言わせない仕組み
- **スコープ制御** — 一度に1機能にロックする
- **セッションライフサイクル** — 毎回クリーンスタート＋クリーンエンド
- **スキル・手順・規範** — 手続き的知識の外部化
- **プロトコル** — Agent-to-Human / Agent-to-Agent / Agent-to-Toolの契約
- **運用レイヤー** — サンドボックス、観測可能性、評価、承認ループ、自己改善

これらをしっかり設計すると、同じモデルでも出力品質が劇的に変わります（Anthropicの実験では、適切なハーネスで「使い物にならない」→「実際に遊べるゲーム」レベルになった事例が報告されています）。[[2]](https://x.com/_vmlops/status/2057707195933110432)

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

```mermaid
graph TD
Core[Thin LLM Core\n(ReAct / Plan-Execute-Verify)]

subgraph Externalization [Externalized Intelligence]
Memory[Memory Layer\n・Working Context (cached)\n・Semantic (Vector)\n・Episodic (SQLite)\n・Procedural (Skills)]
Skills[Skills Layer\n・SOPs・Heuristics・Normative Constraints]
Protocols[Protocols Layer\n・A2H / A2A / A2T Contracts]
end

subgraph Mediators [Mediators / Operational Layer]
Safety[Safety Harness\n・Approval Gates・Constitutional AI・Permission Model]
Observability[Observability\n・OpenTelemetry・Structured Traces]
Evaluation[Evaluation & Self-Improvement\n・Trace-driven Harness Optimizer]
Orchestration[Orchestration\n・Supervisor + Sub-agents・Bounded Loops]
Compression[Context Management\n・Compaction without breaking cache]
end

Core --> Harness[Agent Harness Core]
Harness --> Externalization
Harness --> Mediators
```

この図のポイントは**LLMを薄く保ち、知能を外部化する**ことです。新しい機能追加時に「どこに置くか」を明確に判断できるようになります（Memory？Skills？Protocols？Mediator？）。[[3]](https://x.com/akshay_pachaar/status/2045510648474530263)

### 3. 各レイヤーの詳細設計

#### **Execution Core（実行中枢）**
- **Bounded Turn Cycle**：無限ループ防止のため、iteration ceiling + token/time budgetを必ず設定
- 基本ループ：**Observe → Act → Observe → Reflect**（またはPlan → Execute → Verify → Improve）
- 必ず「完了判定ゲート」を別エージェントorルールベースで挟む

#### **Memory Design（最も重要）**
- **Working Context**：プロンプトキャッシュを聖域化（PREFIXとして再利用）
- **Episodic Memory**：SQLite + 構造化ログ（後でトレース解析に使用）
- **Semantic Memory**：Vector DB（PGVector/Qdrant）
- **Long-term Procedural**：`MEMORY.md` + `USER.md` + `AGENTS.md`（日本コミュニティで非常に人気のシンプル手法。キャッシュを壊さない）

#### **Safety Harness（暴走防止）**
- **正の参照 + 負の導出**（日本で特に洗練されている手法）：仕様書・憲法を「正の参照」として明示的に与え、失敗事例から「負の導出」（禁止パターン）を自動生成・強化する
- **Approval Gates**：manual / smart / off の3段階。破壊的アクションは必ずsmart gate以上
- Toolは**Narrow Waist（一本の漏斗関数）**で提供 → コンテキスト汚染防止

#### **Self-Improvement Loop（最先端）**
- 実行トレースを収集 → 別メタエージェントがハーネス自体（指示書、スキル、ゲートルール）を改善
- 「自分のハーネスをClaude Codeなどに改善させ続ける」閉ループの実運用例が2026年日本で多数報告されています。[[4]](https://x.com/ai_hakase_/status/2075551871968694481)

### 4. 実装時の推奨原則（日本コミュニティ実践例より）

1. **証跡設計**：見せられる証跡と内部監査用証跡を明確に分離
2. **ワークスペーステンプレート標準化**：`.cursor/rules/` や `CLAUDE.md`、`AGENTS.md` を一元管理
3. **並列開発時のmain保護ルール**：AIエージェントがmainブランチを壊さない運用規約
4. **Context Compaction戦略**：履歴を絶対に書き換えず、要約＋削除で対応（キャッシュ保護のため）

### 5. 技術スタック例（2026年中盤）

- **Orchestration**：LangGraph（後継版）または独自State Machine
- **LLM抽象化**：LiteLLM + スマートルーター
- **Memory**：SQLite + PGVector + Markdownファイル
- **Observability**：OpenTelemetry + 自作Trace Evaluator（AEGIS類似）
- **Guardrails**：Pydantic + 専用分類器 + Constitutional Prompt
- **Frontend**：Claude Code / Cursor / Codexとのハイブリッド運用が主流

### 6. 最初に作るべき「Minimal Didactic Harness」

本格的に始めるなら、**教育目的で読みやすい最小ハーネス**をゼロから作ることを強く推奨します（Akshay氏がやっていたアプローチ）。魔法を排除し、各部品の役割を明確にすると、後でスケールしやすくなります。

必要な最初のコンポーネント：
- Bounded ReAct Loop
- SQLite-backed episodic memory
- Permissioned Tool Narrow Waist
- Simple Approval Gate
- Trace Collector + Self-Improvement Prompt

---

この設計をベースにすれば、単なる「デモエージェント」ではなく、企業内で実際に使える「生産エージェント」を構築できます。

具体的にどの部分を深掘りしたいですか？

- 自己改善ループの詳細設計
- 正の参照＋負の導出の実装例
- Memory.md中心のシンプル実装
- LangGraphでのState設計
- 安全ガードレールの実コード例

用途（コード生成エージェント、研究エージェント、業務自動化エージェントなど）を教えていただければ、さらに具体的な設計書をお渡しします。