**AIエージェント ハーネス設計**（2026年現在の実践的まとめ）

「モデルはエンジン、ハーネスは車体」というアナロジーが今最もよく使われています。どれだけ高性能なLLM（Claude 4、o3、Grokなど）を使っても、ハーネス（実行環境）が脆ければ長時間タスクで必ず破綻します。プロンプトを追加し続けるアプローチは限界に来ており、本質は**外側の構造設計**に移っています。

### ハーネスが担う4つの役割（Greg Isenbergらの整理を基に）

1. モデルを**ループで動かし続ける**
2. **手（ツール）**を与え、安全に実行する
3. **長時間にわたる記憶**を適切に管理する
4. **ルールと境界**を強制し、人間承認を挟む

これをしっかり設計すると、モデルを替えても同じ業務知識を活かせる「業務特化の自走AI」が作れます。

### ハーネス設計の3大原則（最も実践的）

最近の議論で特に優れているのが以下の3点です：

**① 曖昧な指示を排除し、「契約（Contract）」を最初に渡す**
- 目的・作業範囲・絶対に触れてはいけない制約・合格条件・人間の明示承認が必要な操作を**構造化**して渡す
- 「払い戻しを減らせ」みたいな願望指示ではなく、**合格条件を明確化**
- 最初に全情報を渡さない → **Progressive Disclosure（段階的開示）**。地図だけ渡して、必要になったら詳細を引き出させる

**② 記憶を「生ログ」から4つの構造化状態へ圧縮する**
定期的に以下の4つに圧縮：
- 発見した事実（Facts）
- 決定した事項とその理由（Decisions & Rationale）
- 現在の進捗状況（Progress）
- 今後の学び・次のアクション（Learnings）

これにより、途中で停止しても長い会話履歴を最初から読み直さずに復旧可能。重要な操作（外部公開、課金、破壊的操作）は**コードレベルでガード**（プロンプト依存をやめる）。

**③ 完了は自己申告ではなく、客観的証拠で判定し「レシート」を発行**
- 「完了しました」は信用しない
- テスト通過、データ突合、別検証エージェントの承認など**環境側の証拠**を要求
- 終了時に以下の「レシート」を必ず生成：
- 目的に対する達成度
- 変更箇所
- 検証した項目／未検証の項目
- 決定事項
- 残存リスク

これで数百ターンの履歴を追わずに人間がレビュー可能になります。

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

```mermaid
graph TD
A[Contract Manager
（目的・制約・合格条件）] --> B[State Manager
（4状態圧縮 + Append-only Log）]
B --> C[Loop Engine
（ReAct / Plan-and-Execute / カスタム）]
C --> D[Tool & Sandbox Layer
（Progressive Disclosure + Permission System）]
D --> E[Verifier
（別エージェント or Rule-based）]
E --> F[Receipt & Auditor
（Tamper-evident Log）]
F --> G[Observability
（LangSmith / OpenTelemetry / 自前ダッシュボード）]

subgraph "Safety Layer"
H[Code Guardrails
（人間承認ゲート）]
end
C --> H
```

**主要コンポーネントの設計ポイント**:

- **Contract Manager**: タスク開始時にYAML/JSONで定義。バージョン管理必須。
- **State Manager**: Append-onlyを厳守（履歴を後から書き換えない）。定期的に圧縮。
- **Tool Layer**: 最初は最小限（Bash + 必要最小ツール）に抑える「ミニマルハーネス」も有効。コンテキスト汚染を防ぐ。
- **Verifier**: 自己点検を避けるため、**別の役割のエージェント**を立てる。
- **Safety**: プロンプトではなく**コードで強制**（DecoratorやMiddlewareで実装）。

### 実装アプローチの選択肢

**A. 既存フレームワークをハーネスとして使う（最速）**
- LangGraph（状態管理が強い）
- CrewAI / AutoGen（マルチエージェント）
- OpenAI Swarm / AnthropicのManaged Agents

**B. 自前ミニマルハーネス（推奨度高い）**
800〜2000行程度のシンプルなPythonスクリプトから始めるチームが増えています。後からLangGraphなどに移行しやすいです。重要なのは**ループを小さく読みやすく保つ**こと。

**C. 業務特化型ハーネス**
会計、人事、顧客対応、コードレビューなど特定ドメインに最適化した「Agent Harness as Product」が2026年のトレンドです。蓄積されたルールと検証ロジックが競争力になります。

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

- [ ] 合格条件は測定可能か？
- [ ] 重要な操作に人間承認ゲートはあるか？（コードで強制）
- [ ] 記憶は構造化圧縮されているか？
- [ ] 完了判定は自己申告に依存していないか？
- [ ] ログはAppend-onlyで、外部検証可能か？
- [ ] ツール定義はProgressive Disclosureになっているか？
- [ ] モデルを替えても動くように抽象化されているか？

この設計をしっかりやると、モデルが変わっても「業務を回す力」はどんどん強くなっていきます。プロンプトエンジニアリングから**ハーネスエンジニアリング**へのパラダイムシフトが、今まさに起きています。

必要であれば、特定ドメイン（例: バックオフィス、ソフトウェア開発、営業支援）向けのより詳細な設計テンプレートも作成できます。どの部分を深掘りしたいか教えてください。