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

2026年現在、最も重要なAIエンジニアリングのテーマの一つが「**ハーネスエンジニアリング**」です。モデル自体を改善するのではなく、モデルを取り巻く「手綱（harness）」＝足場・仕組みを設計することで、信頼性・安全性・実用性を劇的に向上させるアプローチです。

「**モデルはCPU、ハーネスはOS**」という比喩が最もわかりやすい表現です。[[1]](https://x.com/tetumemo/status/2037876018745385083)

### 1. ハーネスとは何か（核心）

ハーネスとは以下の要素を統合した**実行環境全体**です：

- **持続的な状態管理**（Memory / Notebook）
- **明確なツールインターフェース**と権限制御
- **検証ゲート**（自己完了を許さない）
- **スコープ制御**（一度に1機能にロック）
- **明示的な計画アーティファクト**
- **観測可能性・トレーシング**
- **Safety Guardrails & Sandbox**
- **Human-in-the-loop / Approvalフロー**
- **スキル・プロトコル**（運用手順・規範）

これらが不足すると、どんなに高性能なモデル（Claude 4.5 Opusなど）でも「デモ止まり」になります。良好なハーネスがあると、**同じモデルでも出力品質が劇的に変わる**ことがAnthropicの実験でも証明されています（ハーネスなし：20分/$9で使い物にならない → ハーネスあり：6時間/$200で実用レベルのゲーム完成）。[[2]](https://x.com/_vmlops/status/2057707195933110432)

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

**レイヤード + イベント駆動型**を推奨します。将来的には「モノリシックなフレームワーク」から脱却し、**Composable Microservices**（Policy Engine、Approval Layer、Memory Layerを独立交換可能）にするのがベストプラクティスです。[[3]](https://x.com/DamiDefi/status/2068598041368826125)

#### 中心となる実行ループ（Agent Loop）

```text
1. Context Assembly（豊富なコンテキスト構築）
2. Planning（明示的な計画をArtifactとして生成）
3. Model Routing（タスクに応じたモデル選択）
4. Tool/Skill Execution（厳格にsandboxed）
5. Observation
6. Verification（別エージェント or Rubricによる評価）← 最も重要
7. Reflection → Plan Update
8. (Success or Escalate to Human)
```

**自己評価バイアス**（自分の作ったものを過大評価する問題）を避けるため、**「作る役」と「評価する役」は必ず別エージェント**に分離してください。これはAnthropicも強く強調している点です。[[4]](https://x.com/masahirochaen/status/2037175753620807701)

### 3. 主要コンポーネントの設計詳細

| コンポーネント | 目的 | 設計のポイント | おすすめ実装 |
|-----------------------|----------------------------------|-------------------------------------------|-------------|
| **Context Engine** | 適切な情報を与える | Working Memory + Episodic + Architectural Knowledge + RAG | Vector DB + Graph DB + Summary Compression |
| **Planner** | 計画の明示化 | Hierarchical Planning（高レベル→サブタスク） | Dedicated Planner Agent + Markdown Artifact |
| **Tool Registry** | 安全なツール実行 | JSON Schema厳格化 + Permission System + Versioning | Pydantic + Custom Wrapper |
| **Memory System** | 忘却防止 | Short-term / Long-term / Procedural Memory | Redis (短期) + PGVector/Neo4j (長期) |
| **Verifier / Critic** | 品質保証 | 独立した評価エージェント + Rubricベース評価 | Separate Critic Agent |
| **Safety Layer** | 逸脱防止 | Scope Lock, Approval Gates, Sandbox | E2B / Firecracker / Custom Policy Engine |
| **Observability** | デバッグ・改善 | 完全トレーシング + 可視化 | LangSmith / Phoenix + OpenTelemetry |
| **Orchestrator** | 全体統制 | State Machine + Background Tasks + Queuing | LangGraph or Custom (推奨) |

### 4. 実装アプローチの選び方

1. **学習・最小限スタート**：Bash + Pythonの最小ループ（「learn-claude-code」系）から作る。黒魔術を理解するのに最適。[[5]](https://x.com/TeksCreate/status/2075014877840584856)
2. **本番志向**：**LangGraph**（checkpoint/persistenceが非常に強い）。状態を永続化しやすい。
3. **エンタープライズ**：独自ハーネスを構築。Policy Engine、Approval Workflow、Budget Controlなどを独立マイクロサービス化。

**最初に作るべきもの**（MVP順）：
1. 強力なContext Assembly機構
2. 明示的なPlanning Artifact生成
3. 独立したVerifier Agent
4. 完璧なTracing & Logging
5. Sandbox + Permission System

### 5. 評価ハーネスの設計（超重要）

- **Rubric化**：主観的な評価項目（「美しいか？」）を「設計原則X,Y,Zを満たしているか？」に変換
- **Multi-Agent Evaluation**：Creator vs Critic
- **Harness-Ready Repository**：リポジトリ自体を「エージェントが作業しやすい構造」に事前整備（これだけでROIが非常に高い）[[6]](https://x.com/theplgeek/status/2032522450982879273)

### 設計時のチェックリスト

- [ ] 自己評価バイアス対策は入っているか
- [ ] 計画は明示的なArtifactとして保持されているか
- [ ] 検証ゲートはスキップ不可能か
- [ ] スコープは厳密に制御されているか
- [ ] 全てのアクションに完全なトレース可能性があるか
- [ ] Memoryは圧縮・要約されているか（コンテキストウィンドウ対策）
- [ ] Sub-agent生成機構はあるか（専門エージェントの動的スポーン）

---

この設計を基に具体的なユースケース（ソフトウェア開発エージェント、業務自動化エージェント、デザインエージェントなど）を教えてくれれば、さらに深掘りしたアーキテクチャ図、プロンプト例、コード構成を提案できます。

**次の質問例**：
- 「ソフトウェア開発特化のハーネス設計が欲しい」
- 「LangGraphを使った具体的な実装パターンを見たい」
- 「評価Rubricの具体例が欲しい」
- 「企業内導入時のガバナンス設計も含めて」

必要に応じて深掘りしましょう。