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

2026年現在、AIエージェントの実用化で最も重要なテーマの一つが「**ハーネスエンジニアリング**」です。

**モデル（生の知能）＋ハーネス（実行環境・仕組み）＝エージェント**という考え方が主流になっています。プロンプトエンジニアリング → コンテキストエンジニアリングの次のレイヤーであり、モデルを替えなくても性能・信頼性・安全性が劇的に変わります。[[1]](https://x.com/tetumemo/status/2037876018745385083)

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

馬具（手綱・鞍）のメタファーです。馬（モデル）の力を制御し、目的の方向に安全に導くための「足場・仕組み」の全体を指します。

主な役割：
- ツールの呼び方・権限制御・観測の構造化
- 失敗時の自己修正ループ
- 記憶の永続化とコンテキストの圧縮
- ガードレールと承認フロー
- 可観測性（すべてを記録・分析可能にする）
- フィードバックによる継続的改善

良いハーネスは「同じ失敗を二度と繰り返さない」ように設計されます。モデルが進化してもハーネスが弱いと本番投入はほぼ不可能です。[[2]](https://x.com/_moto___/status/2093564841839710643)

### 2. 推奨設計：7層ハーネスモデル

多くの議論で共通して出てくるレイヤーを整理すると以下の7層になります（一部の議論では5層にまとめられることもあります）。

**第1層：ツールオーケストレーション**
- モデルに直接ツールを呼ばせない（構造化出力のみ返させる）
- スキーマ検証・権限チェック・実行・結果整形はハーネス側で完全に行う
- 危険操作（書き込み・削除・実行・外部API）は **Draft & Commit**（ドラフト→人間承認→コミット）
- 常に構造化されたObservation（何が起きたか、成功/失敗/タイムアウト）を返す

**第2層：検証ループ（Verification Loop）**
- 最も重要な層。「作る役」と「評価する役」を必ず分離
- 自己評価バイアスが非常に強いため、別エージェント（またはルールベース＋強いモデル）でレビュー
- ルーブリック（評価基準）を明文化（「設計原則を守っているか」「テスト通過か」など主観を排除）
- 各ステップ終了後に即時検証 → 早期失敗を徹底

**第3層：コンテキスト＆記憶管理**
- ターンごとにコンテキストを自動圧縮（完了タスクは要約、不要情報は削除）
- 永続記憶ファイル推奨：`CLAUDE.md` / `AGENTS.md` / `LESSONS.md` / `STATE.md` / `DESIGN.md`
- 記憶の種類を分ける（会話記憶・作業記憶・エピソード記憶・意味記憶・手続き記憶）
- 過去の失敗教訓を自動でルールに追加（これが最大の自己改善）

**第4層：ガードレール（Guardrails）**
- 行動ルール、データ漏洩防止、運用制限（トークン予算・時間制限・リトライ上限）
- リスクベースで強度を変える（顧客データ触るエージェント vs 内部ツールのみ）
- 法規制対応（EU AI Act、コロラド州AI法など）の証跡もここで生成

**第5層：可観測性（Observability）**
- すべての思考・行動・観測・コスト・結果を構造化ログ
- 指標例：有用出力あたりのコスト、30日後残存率、失敗パターン分類、ドリフト検知
- トレースはリプレイ可能に（同じ軌跡を別モデル/別プロンプトで再実行できる）

**第6層：ルーティング＆モデル選択**
- タスク種別でモデルを動的に切り替え（高速安価モデルで機械的チェック、強力モデルで計画・判断）
- 失敗時は代替経路（再構成 → 別モデル → 人間エスカレーション）

**第7層：フィードバック＆自己改善**
- 却下・失敗・予算超過のたびに教訓を抽出し、永続ルールに書き込む
- ハーネス自体が進化する閉ループ。これが「静的ハーネス」と「学習するハーネス」の分水嶺

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

- **基盤**: Stateful Graph（LangGraphが2026年も非常に強い選択肢）。ノードとして `Planner`、`Actor`、`Critic/Verifier`、`Tool Executor`、`Summarizer`、`Router` などを定義
- **状態管理**: Pydanticで厳格に型付けされたState + Checkpointing（中断・再開・デバッグ容易）
- **記憶**: ファイルベース（リポジトリ内Markdown + JSON）＋ Vector DBを併用
- **実行基盤**: Durable Execution（Temporal.ioなど）で長時間タスクを信頼性高く処理
- **ツール定義**: 宣言的（description + JSON Schema + permission level + risk score + examples）

**シンプルな開始点**
1. 基本ReActループ＋強力な検証ループ
2. 永続ルールファイル（LESSONS.md）を必ず読み込ませる
3. すべての操作を構造化ログに出力
4. 危険操作にHuman-in-the-Loopを入れる

これだけでも大幅に改善します。

### 4. 実践的な設計テンプレート（Markdown例）

リポジトリのルートに置くファイル例：

- **`AGENTS.md`**：全体憲法・役割分担・禁止事項
- **`DESIGN.md`**：設計原則・品質基準・ルーブリック
- **`LESSONS.md`**：これまでの失敗と教訓（日付＋事例＋ルール化）
- **`STATE.md`**：現在のプロジェクト状態・制約・完了タスク一覧

プロンプトの最初にこれらをすべて読み込ませる（または要約版を動的に注入）。

### 5. ベストプラクティスと落とし穴

**やるべきこと**
- 「モデルを強くする」より「ハーネスを強くする」を優先
- 検証は必ず分離（自己評価を信用しない）
- 失敗を「記憶の資産」に変換する仕組みを最初から入れる
- 可観測性を最優先（ログがなければ改善できない）
- リスク比例のガードレール（過剰摩擦は生産性を殺す）

**避けるべきこと**
- 全部を1つの巨大プロンプトに押し込む
- 同じモデルをすべてのタスクに使う
- ハーネスを一度作って放置（腐る）
- 目的が曖昧なまま高度なハーネスを組む（ゴミを高品質に作るだけになる）

### まとめ

2026年のAIエージェント開発で「どのモデルを使うか」はもはや二次的な質問です。本当に差が出るのは**ハーネス設計の巧拙**です。

人間の役割は徐々に「コードを書く」から「エージェントが正しく・安全に・継続的に価値を生み出す環境を設計する」へとシフトしています。それがハーネスエンジニアリングの本質です。[[3]](https://x.com/taimuhanashiro/status/2023008135464788127)

具体的なユースケース（コーディングエージェント、業務自動化、研究エージェントなど）があれば、さらに詳細なアーキテクチャやコードスケルトンをお見せできます。どのような場面でのハーネス設計をお考えですか？