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

2026年現在、「ハーネスエンジニアリング」はAIエージェントの実用化において最も重要なレイヤーになっています。プロンプトエンジニアリング → コンテキストエンジニアリングの次の段階として位置づけられ、「モデル（馬）の能力を最大限に引き出す手綱・鞍・環境一式」を設計するアプローチです。[[1]](https://x.com/tetumemo/status/2037876018745385083)

OpenAIが人間が1行もコードを書かずに5ヶ月で約100万行のプロダクションコードをCodexエージェントだけで構築した事例や、Anthropicの実験（同じモデルでもハーネス次第で成果が劇的に変わる）でその有効性が証明されています。[[2]](https://x.com/taimuhanashiro/status/2023008135464788127)

### ハーネスとは何か
ハーネス = **モデル以外のすべて**。エージェントが信頼性高く、長期間、複雑なタスクを遂行するための「足場（scaffolding）」です。

主な目的：
- 自己評価バイアスを排除
- 状態の一貫性を保つ
- 安全・権限制御を行う
- 検証・修正ループを強制する
- 人間のスティアリング（舵取り）を容易にする

### 推奨ハーネスアーキテクチャ（7層モデル）

```text
[ Layer 7: 評価・観測 (Evaluation & Observability) ]
↑↓
[ Layer 6: 永続化・記憶 (Persistence & Memory) ]
↑↓
[ Layer 5: 権限・安全ゲート (Permissions & Safety) ]
↑↓
[ Layer 4: オーケストレーション (Orchestration) ]
↑↓
[ Layer 3: 制御ループ (Control Loop) ]
↑↓
[ Layer 2: コンテキスト管理 (Context Management) ]
↑↓
[ Layer 1: ツール・アクション (Tools & Actions) ]
↑
[ Constitutional Layer (憲法・DESIGN.md) ]
```

#### 各層の詳細設計

**Layer 0: Constitutional Layer（最重要）**
- `DESIGN.md` または `CONSTITUTION.json` として全エージェントが最初に読む「設計原則」
- 品質基準、禁止事項、判断軸をルーブリック化（「美しいか？」ではなく「この設計原則のXX項目を満たしているか？」）
- バージョン管理され、変更時は全関連ドキュメントに自動反映

**Layer 1: ツール・アクション**
- ツールを「閲覧」「提案」「実行」の権限レベルで分類
- ツール呼び出しは必ずスキーマ検証を通す
- 危険操作（削除・本番反映・外部送信）はHuman-in-the-Loop必須

**Layer 2: コンテキスト管理**
- 「地図を渡す」設計：必要な情報だけ段階的にロード
- コンテキストウィンドウを無駄に消費しないよう、要約・要約の要約・グラフDB参照を組み合わせる
- 現在の状態を常に明確に（「今どのサブタスクか」「完了済み成果物は何か」）

**Layer 3: 制御ループ（Core Engine）**
最も重要な部分。推奨パターン：
```python
class AgentHarness:
async def run(self, task: Task, agent_config: AgentConfig):
state = initialize_state(task)

while not is_complete(state):
# 1. Plan / Think
plan = await executor.think(state)

# 2. Act
action = await executor.act(plan, state)
observation = await execute_in_sandbox(action)

# 3. Verify (別エージェント推奨)
verification = await evaluator.verify(observation, state, rubric)

if not verification.passed:
state = await corrector.fix(state, verification.feedback)
continue

state = update_state(state, observation, verification)

return final_report(state)
```

**Layer 4: オーケストレーション**
- シングルエージェント vs マルチエージェント（Creator + Evaluator + Auditorは最低3体推奨）
- 同じモデル・同じ価値観で全部やらせない（連鎖失敗防止）

**Layer 5: 権限・安全**
- 閲覧/提案/実行の3権分離
- 送信・削除・本番反映は人間承認必須
- 「善意の独断介入」も評価対象に
- 判断不能時は明確に「辞退・エスカレーション」

**Layer 6: 永続化・記憶**
- セッションごとのクリーンスタート + 長期記憶の両立
- 操作ログ・差分・因果関係を必ず記録（「AIの報告」ではなく「証跡」）

**Layer 7: 評価・観測**
- 自己評価禁止 → 別エージェントで評価
- 詳細ルーブリックベースの評価
- 自動テスト + LLM Judge + 人間レビューを組み合わせ
- トレースはLangSmith/Phoenix/自前ダッシュボードで可視化

### 実装時の設計原則（2026年現在のベストプラクティス）

1. **環境設計 > モデル能力** — 進捗が遅い原因のほとんどはハーネスが未熟
2. **作る役と評価する役は完全に分離** — 自己評価バイアスは非常に強い
3. **ルーブリック化** — 主観的判断を可能な限り構造化
4. **Human steer, Agent execute** — 人間は目標・制約・品質基準を設定し、実行は任せる
5. **証跡ファースト** — 差分と操作ログを最優先で残す
6. **ハーネスは進化させる** — 失敗パターンを検知したら、ハーネス側に再利用可能な介入として組み込む

### 技術スタック例（2026年推奨）

- **Runtime**: LangGraph または 自前状態マシン（Pydantic + asyncio）
- **評価**: 専用Evaluator Agent（Claude 4 / GPT-5クラスを分離）
- **可視化**: Phoenix, LangSmith, または自前Streamlit/FastAPIダッシュボード
- **永続化**: PostgreSQL + PGVector + ファイルシステム（成果物）
- **サンドボックス**: Docker + 権限制限Playwright + コード実行環境
- **実験管理**: 自前実験トラッカー（MLflowのAgent版）

### 次のステップとしておすすめ

1. まずは**自分のメイン作業環境**に`DESIGN.md` + シンプルな制御ループ + 別Evaluatorを導入
2. 失敗したタスクを分析し、ハーネスに「再利用可能な修正パターン」として追加
3. 徐々にLayerを厚くしていく（特に権限・評価・記憶）

ハーネス設計は「一度作ったら終わり」ではなく、**継続的に育てていく知的アルファ**です。モデルが進化しても、ハーネスの設計空間はむしろ広がります。

具体的なユースケース（コーディングエージェント、研究エージェント、業務自動化など）でより詳細な設計図やコード例が必要でしたら、教えてください。実際のプロジェクトで使っているテンプレートも共有できます。