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

2026年現在、日本語AIコミュニティで最も注目されているのが「**ハーネスエンジニアリング**」です。
「AIエージェント = Model + Harness」という等式が浸透しており、**モデル本体以外のすべてを体系的に設計する**アプローチです。

### 1. Harnessとは何か

ハーネス（Harness）は元々「馬具一式」の意味。
馬（＝LLM）の力を最大限に引き出しつつ、暴走させないための**制御・装備・安全装置の全体**を指します。

主な構成要素：
- **Prompt / Context**
- **Tools**
- **Loop（反復サイクル）**
- **Memory & State**
- **Guardrails / Safety**
- **Observability**
- **Evaluation（評価）**

これらをバラバラに作るとすぐに破綻するため、**レイヤードアーキテクチャ**として設計します。

### 2. 推奨される5層ハーネス構造（2026年現在主流）

多くの実践者が使っている整理方法です：

1. **ツール指揮層 (Tool Orchestration Layer)**
- 利用可能なツールの登録・権限スコープ管理
- ツール呼び出しのスキーマ統一（Pydantic / JSON Schema）
- 並列呼び出し制御・依存関係解決

2. **検証ループ層 (Verification & Self-Correction Layer)**
- 出力検証（Rule-based + LLM-as-Judge）
- 自動リトライロジック（最大試行回数、指数バックオフ）
- 部分成功時のロールバック・回復戦略

3. **文脈・記憶層 (Context & Memory Layer)**
- 短期記憶（会話履歴）
- 長期記憶（Vector Store + Summary）
- 文脈圧縮（何を捨てるか・要約するかの戦略）
- タスク状態マシン（ToDo, InProgress, Blocked, Doneなど）

4. **ガードレール層 (Safety & Guardrail Layer)**
- 事前チェック（禁止アクション検知）
- 事後チェック（出力フィルタリング）
- 権限境界・最小権限原則（Blast Radiusの制限）
- 人間承認ゲート（Human-in-the-Loop）

5. **監視・可視化層 (Observability Layer)**
- 完全なTrajectory記録（Thought → Action → Observation）
- トレース（LangSmith, Phoenix, OpenTelemetry互換）
- メトリクス（Token消費、ステップ数、失敗パターン、コスト）
- 再現性確保（seed固定、deterministic mode）

### 3. 全体アーキテクチャ図（推奨）

```mermaid
graph TD
subgraph Harness ["Harness (Modelの外側)"]
direction TB

Tool[1. ツール指揮層]
Loop[2. 検証ループ層]
Memory[3. 文脈・記憶層]
Guard[4. ガードレール層]
Obs[5. 監視・可視化層]

Core[Core Executor\n(ReAct / Plan-and-Execute / Graph)]

Tool --> Core
Memory --> Core
Guard --> Core
Core --> Loop
Loop --> Core
Obs --> Tool
Obs --> Memory
Obs --> Guard
Obs --> Loop
end

Model[LLM / Model] <--> Core
Human[Human Feedback] <--> Guard
Env[External Environment\n(API・DB・Browser・Code Exec)] <--> Tool
```

### 4. 設計時の重要原則（これを守ると後で死なない）

- **責務の明確化**：各層は単一責任原則を守る。検証ループが記憶層を直接触らない。
- **変更容易性**：ハーネスは肥大化しやすい。**Strategy Pattern**や**Middlewareパターン**で拡張性を確保（gota_bara氏の資料が参考になります）。
- **再現性**：同じタスク・同じseedで完全に同じTrajectoryを再現できるようにする。
- **Fail Fast & Safe**：危険操作は必ずdry-run or 事前承認を挟む。
- **評価と運用を分離**：Evaluation Harness（ベンチマーク用）とRuntime Harness（本番運用用）は似ているが別物として設計。

### 5. 実装技術スタック例（2026年現在）

**おすすめ構成**
- **LangGraph**（最も成熟）：状態グラフ + チェックポイント + 人間介入が強い
- **LlamaIndex Workflows** or **CrewAI + カスタムHarness**
- **ゼロから作る場合**：Pydantic v2 + asyncio + structlog + OpenTelemetry

**最小動作するCore Executorの擬似コード例**

```python
async def run_with_harness(task: str, agent: Agent, harness: Harness) -> Result:
trajectory = []
state = harness.memory.initialize(task)

for step in range(MAX_STEPS):
# 1. ガードレール事前チェック
if not await harness.guard.pre_check(state):
break

# 2. エージェント呼び出し
action = await agent.get_action(state.history, harness.context.get())

# 3. ツール指揮
observation = await harness.tools.execute(action)

# 4. 検証ループ
verified, correction = await harness.verifier.check(action, observation)
if not verified:
state = harness.verifier.apply_correction(state, correction)
continue

# 5. 記憶更新 & ログ
state = harness.memory.update(state, action, observation)
harness.observer.record(step, action, observation)

trajectory.append((action, observation))
if harness.is_terminal(state):
break

# 最終評価
return harness.evaluator.evaluate(trajectory, task)
```

### さらに深掘りしたい場合

- 5層ハーネスの詳細設計
- マルチエージェント時のGraph Engineeringとの組み合わせ
- 評価ハーネス（Benchmark用）と運用ハーネスの違い
- 具体的なGuardrail実装例（禁止コマンドリスト、LLM Constitutionなど）

用途（内製フレームワーク構築、本番運用、ベンチマーク作成など）を教えていただければ、より具体的な設計資料やコードテンプレートをお渡しできます。

どの部分を深く知りたいですか？