AIエージェントが暴走する時、最初に疑うべきは「権限設計」

この記事でわかること:

• AIエージェント暴走の典型パターン
• 権限設計が暴走を防ぐ理由
• 2026年のガードレール設計ベストプラクティス

結論: 暴走は「権限が広すぎる」から起きる

AIエージェントが意図しない動作（暴走）をした時、現場で最初に疑うべきは権限設計です。プロンプトのバグや学習データの偏りより、「できることが多すぎた」が根本原因のケースが圧倒的に多いというのが2026年の業界共通認識です。

典型的な暴走事例

事例1: 大量メール送信

カスタマーサポートAIが、無限ループに陥って同じ顧客に1時間で2,000通のメールを送信。原因はメール送信権限に上限がなかったこと。

事例2: 本番DB書き換え

データ分析エージェントが、本番DBへの書き込み権限を持っていたため、検証中に重要テーブルを更新。復旧に半日かかりました。

事例3: 不正な経費承認

業務自動化エージェントが、経費申請の承認権限を持ち、プロンプトインジェクション攻撃により高額経費を自動承認。

事例4: 外部API呼び出し暴走

翻訳エージェントが外部APIをループで呼び続け、1日で数十万円の課金。レート制限がなかった。

権限が広すぎる構造的理由

1. 「便利だから全部渡す」

開発時に「念のため」と多めの権限を付与し、本番でもそのままになるパターン。

2. 既存ロールの流用

「管理者ロール」を雑にAIに割り当て、人間管理者と同じ権限を与えてしまう。

3. ツール選択の自由度

AIエージェントに「使えるツール一覧」を与えると、意図しないツールを使うことがある。

権限設計の5原則

原則1: 最小権限の原則

AIエージェントには「そのタスクで本当に必要な権限だけ」を与えます。読み取りで十分なら書き込みは禁止、特定テーブルだけで十分なら他テーブルへのアクセスは禁止。

原則2: ホワイトリスト方式

「これは禁止」ではなく「これだけ許可」のホワイトリスト設計にします。新しい機能・ツールはデフォルトで使えない状態がスタート。

原則3: レート制限

すべての操作にレート上限を設定します。メール送信なら1時間100通まで、API呼び出しなら1分10回までなど。

原則4: 承認フロー

重要な操作（金額が大きい、不可逆、PII関連）は必ず人間の承認を経由させます。AIだけで完結させない。

原則5: 監査ログ

すべての操作をログ化し、後から追跡可能にします。異常パターンを自動検知する仕組みも組みます。

実装パターン

パターン1: 専用サービスアカウント

AIエージェント専用のサービスアカウントを作り、必要最小限のIAMロールを付与します。人間用アカウントを使い回すのは厳禁です。

パターン2: ツールのラッパー

AIに渡すツールは、生のAPIではなくラッパー関数にします。ラッパー内で引数検証・レート制限・ログを実装。

async function sendEmailSafely(to, subject, body) {
  if (rateLimiter.exceeded()) throw new Error('rate limit');
  if (!isWhitelisted(to)) throw new Error('not allowed');
  log.info('AI agent sending email', { to, subject });
  return await emailService.send(to, subject, body);
}

パターン3: ステージング検証

本番デプロイ前に、必ずステージング環境で「暴走テスト」を実施します。意図的に異常な指示を与えて、ガードレールが効くか確認。

パターン4: 段階的解放

新しいAIエージェントは初期は権限を絞り、運用実績に応じて段階的に権限を広げます。「1日100件まで」「1週間順調なら500件まで」のように。

OWASP LLM Top 10との関連

権限設計はLLM06: Excessive Agency（過剰な権限委譲）として明確に脆弱性カテゴリ化されています。2026年は監査対応でも権限設計の妥当性が問われるようになりました。

暴走対応プレイブック

暴走が起きた時の対応手順を事前に用意しておきます。

1. 即時停止: エージェントを止めるキルスイッチ
2. 被害範囲特定: 監査ログから影響を把握
3. 復旧: 必要に応じてロールバック
4. 原因分析: 権限・プロンプト・入力データのどこに問題があったか
5. 恒久対策: ガードレール強化、テスト追加

事例: 暴走を未然に防いだケース

あるFinTechで、AIエージェントの導入時に「5万円以上の操作は人間承認必須」というガードレールを設定。結果、後にプロンプトインジェクション攻撃を受けた際も、攻撃者が試みた100万円の不正送金が承認段階で止まりました。初期設計のガードレールが効いた典型例です。

まとめ

AIエージェント暴走の根本原因は、多くの場合「権限が広すぎた」ことです。最小権限・ホワイトリスト・レート制限・承認フロー・監査ログの5原則で設計すれば、暴走の被害は最小化できます。2026年のAIエージェント運用は、機能設計と同じくらいガードレール設計が重要です。「動くこと」だけでなく「暴走しないこと」を設計の一級市民として扱いましょう。