テクノロジー

AIエージェントの「ハーネス」設計 ── 暴走を防ぐ5つの実装パターン（2026年版）

AIエージェントの「ハーネス」設計 ── 暴走を防ぐ5つの実装パターン（2026年版）

「ガードレール」から「ハーネス」へ ── 用語が更新されている

少し前まで、AIエージェントの安全運用は 「ガードレール（guardrails）」 という言葉で語られていました。直訳すると「車線をはみ出さない柵」。ところが2025年後半以降、海外の実装コミュニティを中心に 「ハーネス（harness）」 という言葉が使われるようになっています。

違いはこうです:

  • ガードレール: はみ出さなければOK、という消極的な安全装置
  • ハーネス: 馬具のように、力を引き出しながら方向を制御する積極的な制御装置

Optiensでも、社内のAIエージェント運用は ハーネス設計 を起点にしています。「危ないから止める」ではなく、「価値を引き出すために制御する」設計思想です。本稿は、Optiensが実装している5つのハーネスパターンを公開するものです。

ハーネスパターン1: 権限スコープの最小化（Principle of Least Privilege）

何をするか: AIエージェントに渡すAPIキー・データベース接続・ファイルアクセス権を、業務に必要な最小限に限定する。

実装例

  • 「請求書発行エージェント」→ 請求書テンプレート＋顧客マスタ（読み取り）＋PDF生成API のみ。メール送信権限は持たせない（人間が確認後に送信）
  • 「市場調査エージェント」→ Web検索 + ファイル書き込み（指定ディレクトリのみ）。社内DBへの書き込み権限は持たせない

よくある失敗

「とりあえず管理者権限を渡して、必要なものは自分で取りに行かせよう」

これが最も典型的な事故源です。AIエージェントは「指示された目的を達成するために最善の手段を選ぶ」ので、権限がある = 使える と判断すれば本当に使います。最小権限は、AIを信頼するか否かの問題ではなく、設計上の必須要件です。

ハーネスパターン2: 不可逆操作の人間承認ゲート

何をするか: 「削除」「送信」「決済」「公開」など、取り消せない操作は必ず人間の承認を経由させる。

実装例

  • メール送信エージェント → メール本文を生成してDraft（下書き）に保存まで自動化、送信ボタンは人間
  • データ削除エージェント → 削除候補リストを作成してSlackで通知まで、削除実行は人間が承認
  • 投稿自動化 → SNS投稿の予約まで自動化、最終公開前に管理者がレビュー画面で確認

Optiensの社内事例

営業リード対応で、AIエージェントが返信文をGmail下書きに作成しますが、送信ボタンは私（代表）が押します。1日数十件のメールが、判断と承認だけで処理できます。「全自動」ではなく「人間の判断を最大化する自動化」が、ハーネス設計の核心です。

ハーネスパターン3: 出力の構造化バリデーション

何をするか: AIエージェントの出力を、スキーマ（型定義）で必ず検証してから次のステップに渡す。

実装例

// Zod等で出力スキーマを定義
const InvoiceSchema = z.object({
  customerName: z.string().min(1),
  amount: z.number().positive().int(),
  dueDate: z.string().regex(/^\d{4}-\d{2}-\d{2}$/),
  items: z.array(z.object({ name: z.string(), qty: z.number() })).min(1),
});

const result = await agent.run(...);
const validated = InvoiceSchema.parse(result); // 型が合わなければ例外
  • 金額が文字列で返ってきた → エラー（型検証で阻止）
  • 必須項目が空 → エラー（スキーマで阻止）
  • 日付形式が間違っている → エラー（regex で阻止）

スキーマを通らない出力は次のステップに進めない、という制御が、データ汚染と異常動作を構造的に防ぎます。

ハーネスパターン4: 実行回数・コストの上限制御

何をするか: 1回の実行・1日の実行・1ヶ月の実行で、API呼び出し回数・トークン消費・コストのハードリミットを設定する。

実装例

  • per-run上限: 1回のジョブで API呼び出し50回まで（ループ暴走防止）
  • per-day上限: 1日のトークン消費 100万トークンまで（コスト爆発防止）
  • per-month上限: 月額API費用 5万円を超えたら自動停止＋通知

なぜ重要か

AI エージェントは「目的を達成するまで諦めない」設計が一般的です。しかし、設計バグや想定外の入力があると、無限ループ → AI API に数百回コール → 数日で数十万円 のような事故が起こり得ます。クラウド・API キー漏洩での高額請求事例（Firebase API キー悪用で 900 万円超の事故報道など）と同様、無人で API を呼び続ける設計には常にこのリスクが伴います。

ハードリミットは、コードの正しさを信じないことが起点。ループ脱出が想定通り動いている保証がない以上、外部からの強制停止を必ず仕込みます。

ハーネスパターン5: 監査ログの構造化記録

何をするか: AIエージェントの全実行ステップを、構造化されたログとして残し、後から検証・再現可能にする。

何を記録するか

  • 開始時刻・終了時刻
  • 入力パラメータ（PII等はマスクして）
  • AIに渡したプロンプト（バージョン番号付き）
  • AIから返ってきた生レスポンス
  • ツール呼び出しの履歴（どのAPIを何回呼んだか）
  • 最終的な業務上の結果（成功・失敗・人間に引き渡し）

なぜログが「ハーネス」か

事故・トラブルが起きた時、ログがないとAIエージェントは「ブラックボックス」です。何が原因だったか、再発防止策は何か、判断材料がない。ログがあって初めて、エージェントを信頼できる業務システムとして運用できるのです。

Optiensは、Supabaseに agent_runs テーブルを設けて、全実行を記録しています。問題が起きたら数分で「いつ・何が・なぜ」が追えます。

5パターンまとめ表

パターン防ぐ事故実装難易度
1. 最小権限スコープ不要なシステム操作・情報漏洩★★☆
2. 不可逆操作の人間承認誤送信・誤削除・誤決済★☆☆
3. 出力スキーマ検証データ汚染・型不一致による下流エラー★★☆
4. 実行回数・コスト上限暴走による高額請求★☆☆
5. 構造化監査ログトラブル時の原因追跡不能★★★

特に1・2・4は最低限必須です。これらを実装しないままエージェントを業務に組み込むのは、シートベルトなしで運転するようなものです。

「全自動」より「半自動 × 高頻度」が安全で効率的

AIエージェント運用で多くの中小事業者が誤解しているのが、「全自動 = ゴール」 という思い込みです。実際は逆で、「99%まで自動化、最後の1%は人間の判断」 が、安全性と効率を両立する設計です。

  • 全自動: 失敗した時の損失が大きく、ハーネス設計のコストも高い
  • 半自動: 人間の判断時間は1日数分、損失リスクは限定的、構築コストも安い

Optiensでは、お客様への提案時に 「ゴール = 全自動」を一旦疑う ことから始めます。半自動でハーネスをしっかり張ったエージェントの方が、結果として持続可能で投資対効果が高いケースがほとんどです。

ハーネス設計付きAIエージェント導入のご相談

Optiens は、AIエージェントの 設計から運用まで、本稿で紹介した5つのハーネスパターンを標準実装としてご提供しています。「AI 導入したいが暴走が怖い」という経営者の方は、まず 無料AI活用診断 で AI 活用の方向性をご確認ください。御社の業務に合わせた具体的なハーネス設計案は 詳細レポート（¥5,500税込） でお届けします。

← ブログ一覧へ