AIアプリ防御の実装論: 本番で効くランタイム・ガードレール

CloudflareのAI Security for Apps一般提供を含む最近の動きは、業界の共通理解を明確にしました。モデルが安全でも、アプリが安全とは限らないという点です。実際のリスクは、プロンプト・ツール呼び出し・認証・外部連携が交差するランタイム境界で発生します。

参考: https://blog.cloudflare.com/ai-security-for-apps-ga/。

なぜモデル評価だけでは守れないのか

高性能なモデルを使っていても、アプリ層が弱いと事故は起きます。

• 権限境界の曖昧なツール連携
• テナント境界をまたぐ検索・参照
• 外部通信の無制限許可
• ユーザー/セッションのリスク評価欠如

セキュリティはモデル単体属性ではなく、システム全体特性として設計する必要があります。

本番向け三層防御モデル

第1層: 入力・文脈制御

• プロンプト組み立て前に機微情報分類
• テナント単位のデータ境界を強制
• 注入疑いパターンをゲートウェイで遮断

第2層: 実行時ポリシー制御

• ツール呼び出しの許可リスト
• リクエスト単位の最大ステップ/最大コスト
• ID・挙動に紐づく動的リスクスコア

第3層: 出力・アクション制御

• ポリシークラス別レスポンスフィルタ
• 高リスク操作時の確認フロー
• 判定根拠を残す不変証跡ログ

「止めた」ことより、「なぜ止めたかを説明できる」ことが重要です。

インシデント対応の準備項目

攻撃が起きた瞬間に必要なのは、以下への即答能力です。

1. どの入力文脈が該当操作を誘発したか
2. どのポリシー判定が通過/拒否したか
3. どの外部宛先へ通信したか
4. どのテナント・ユーザーに影響したか

事後にログを寄せ集める体制では遅すぎます。平時から検索可能な監査軸を作っておくべきです。

指標設計は誤検知率だけでは不十分

運用品質を測るには次を見ます。

• エンドポイント別の拒否率
• 異常セッションの封じ込め時間
• 攻撃再発率（アクターフィンガープリント単位）
• 事後レビュー完了までの時間

これらが改善していれば、防御は「運用可能な仕組み」になっています。

実装時の要点

• ポリシー判定を実行経路に近づける
• ポリシー更新をバージョン管理しレビュー対象化
• ツール連携は四半期ごとにレッドチーム検証
• 緊急停止スイッチを定期演習

まとめ

AIアプリのセキュリティは周辺ミドルウェアではなく、可用性と同等の中核要件です。ランタイムで統制できる組織ほど、事故コストを抑えながら開発速度を維持できます。