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

2026年現在、AIエージェントの実用化において最も重要なシフトは「モデル中心」から「ハーネス中心」への転換です。モデルはエンジンに過ぎず、真の信頼性・安全性・再現性は**ハーネス（周囲の実行環境・足回り）**で決まります。プロンプトエンジニアリングの限界を超え、「どんな環境で動かすか」が競争力の中心になっています。[[1]](https://x.com/CobusGreylingZA/status/2043638576848707662)

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

ハーネス（馬具の手綱の意）は、以下の機能を統合した**エージェントのOS**です：

- 状態管理・記憶の圧縮
- ツール実行のサンドボックスと権限制御
- コンテキストのアセンブルと段階的ロード
- 観測可能性（トレーシング）
- ガードレール・承認ループ（Human-in-the-Loop）
- 評価・検証機構
- サブエージェントのオーケストレーション
- チェックポイントと復旧機構

モデルを「薄く（thin）」保ち、知能の多くを外部化・構造化するのが現代的な設計です。同じモデルでもハーネスの質で性能が大きく変わります。[[2]](https://x.com/Astrodevil_/status/2100532726076158373)

### 2. 推奨アーキテクチャ

```mermaid
graph TD
subgraph "Harness (OS)"
Orchestrator["Orchestrator
(State Machine / Supervisor)"]
Runtime["Agent Runtime
(Loop Executor)"]

Memory["Memory System
・Working Context
・Semantic Knowledge
・Episodic Memory
・Compressed State (4分類)"]
Skills["Skills Layer
・Procedures
・Heuristics
・Normative Constraints"]
Protocols["Protocols
(Agent-User / Agent-Agent / Agent-Tool)"]

Mediators["Mediators / Operational Layer"]
Mediators --> Sandbox["Sandbox + Execution Isolation"]
Mediators --> Observability["Observability & Tracing"]
Mediators --> Guardrails["Guardrails + HITL Approval"]
Mediators --> Evaluator["Evaluator + Verifier Agent"]
Mediators --> Compression["Context Compression + Receipt Generator"]

Runtime --> LLM["Thin LLM (Model Agnostic)"]
Runtime --> ToolRegistry["Tool Registry (OpenAI Function Calling準拠)"]
Orchestrator --> Runtime
Orchestrator --> Memory & Skills & Protocols
end

User["User / Human Oversight"] <--> Orchestrator
External["External World (Files, APIs, Browser)"] <--> Sandbox
```

**3つの外部化次元**（Memory / Skills / Protocols）と、それを仲介するOperational Layerが核です。[[3]](https://x.com/i/status/2043638576848707662)

### 3. 実践的な設計原則（特に重要）

日本の実務家がまとめている内容が非常に実用的です。失敗したときにプロンプトを追加するのをやめ、**環境側に制御を落とし込む**のがポイントです。[[4]](https://x.com/i/status/2100528941794808028)

**① 曖昧な指示を排除し、契約＋文脈マップを最初に渡す**
- 目的、作業範囲、絶対に触れてはいけない制約、合格条件、Human Approvalが必要な操作を明記
- 「地図（全体構造）」だけ最初に渡し、詳細は必要に応じてオンデマンドでロード（コンテキストを希少資源として扱う）
- AGENTS.md や RULES.md のような専用ファイルでプロジェクト規約を管理

**② 記憶を4つの圧縮状態に構造化**
- 生の会話ログではなく、「発見した事実」「決定事項と理由」「進捗状況」「今後の学び」の4状態に定期的に圧縮
- これにより長時間実行時の復旧が容易になり、コンテキスト爆発を防ぐ
- 高影響操作（外部公開、課金、破壊的コマンド）は**コードレベルで強制的にHuman Approval**を挟む（プロンプトに頼らない）

**③ 完了判定は自己申告を禁止し、客観的証拠＋レシートを要求**
- 「完了しました」という宣言を信用しない
- テスト通過、データ突合などの**環境側の客観的証拠**を必須に
- 検証は別エージェント（Verifier）に担当させ、修正権限を与えず「拒否権」のみ与える
- 終了時に「レシート」（目的・変更点・検証項目・残存リスク）を自動生成させて人間が高速レビューできるようにする

これらを実装すると、数百ターンに及ぶ実行でも人間が追跡可能になります。

### 4. 構築手順（Minimal Viable Harness）

1. **基礎レイヤー**
- セッション状態はSQLite（またはDuckDB）で永続化
- ツールはすべてOpenAI Function Calling互換スキーマで統一（モデル非依存に）

2. **必須ツール群**
- `read_file` / `edit_file` (unified diff推奨)
- `file_search`（ripgrep推奨）
- `list_directory`
- `execute_command`（bash）

3. **セキュリティ & Sandbox**
- ワークスペースをプロジェクトルートに厳格制限（path traversal防止）
- 危険コマンドはallowlist + 必須Human Approval
- 本番ではDocker / コンテナ / OS namespaceで隔離

4. **オーケストレーション**
- Orchestrator-Workerパターン（Planner → Executor + Verifier）
- プロンプトテンプレートは外部ファイル化（YAML/Markdown）してバージョン管理

5. **観測可能性**
- すべてのステップを構造化ログ化
- チェックポイント機能で途中復旧可能に

### 5. 技術スタック例（2026年時点）

- **コア**: LangGraph（状態機械として最適）または自前State Machine
- **トレーシング**: LangSmith / Phoenix / OpenTelemetry
- **記憶**: 構造化圧縮＋軽量RAG（最初はシンプルに）
- **フロント**: TUI（rich/typer）またはWebダッシュボード
- **Sandbox**: Docker + 権限制限、またはブラウザ系はPlaywright in isolated env

### まとめ：設計の優先順位

**環境設計 > モデル能力**

最初に「小さく始め、買わずに作り、対象業務を厳選」することをおすすめします。完璧なハーネスを目指さず、失敗パターンを1つずつコードと仕組みで潰していくアプローチが効果的です。

この方向性はOpenAI、Anthropic、BCGなどの事例でも一貫して強調されており、今後数年のAgentic AI開発の主流になると考えられます。[[5]](https://x.com/taimuhanashiro/status/2023008135464788127)

具体的なユースケース（コーディングエージェント、業務自動化エージェント、研究エージェントなど）があれば、さらに詳細な設計図やコード構造を深掘りできます。必要に応じて教えてください。