【2026年7月版】AIエージェントのセキュリティ脆弱性6分類と対策｜プロンプトインジェクション・権限昇格・データ流出リスクを中小企業向けに徹底解説

「AIエージェントに社内システムの操作権限を渡したが、想定外の顧客リストが外部に送信された」「PDF要約エージェントが埋め込み指示に従い、機密ファイルの中身をSlackに投稿した」「MCPサーバー経由でIDE設定が改ざんされコード実行が発生した」——2025年以降、こうしたAIエージェント固有のインシデントが実在CVEとして登録され始めています。この記事ではAIエージェントの脆弱性を6分類で整理し、Guardrails AI・NeMo Guardrails・LLM Guard・Lakera・Galileo等の対策ツールをOSSと商用で切り分け、中小企業向けの監査ログ設計と顧客データ漏洩の発見装置まで徹底解説します。導入前に自社のエージェント権限マップを1枚の表で書き出してから以下の順で判断してください。

AIエージェント脆弱性6分類（OWASP LLM Top 10対応）

2025年8月にはGitHub Copilotのリモートコード実行としてCVE-2025-53773、Cursor IDEのMCPサーバー経由の脆弱性としてCVE-2025-54135（CurXecute）・CVE-2025-54136（MCPoison）が公表されており、これらはすべて上記6分類のうち①プロンプトインジェクションと③ツール乱用が連鎖したケースです（NVDおよびGitHub Advisory Databaseで検索可能）。GoogleエコシステムでもGeminiJackと呼ばれる間接インジェクション実証攻撃が2025年に公表され、Docs経由でメール・カレンダーの情報が窃取される経路が確認されています。中小企業では専任のセキュリティ担当がいないケースが多いため、6分類のうちどれか1つが欠けても被害が連鎖しやすい構造にあります。担当者が確認するのは「エージェントに渡した権限一覧」「監査ログの7項目が揃っているか」の2点で、この棚卸しを月次で回す運用が定着の鍵です。

対策ツール・フレームワーク6社と料金（OSS／商用の切り分け）

料金は変動するため契約前に必ず各社公式サイトで最新条件を確認してください。中小企業では既に社内でオープンソースを扱える情シス担当がいるならGuardrails AI＋LLM Guard＋Cerbosの3点セット（すべて無料）から始め、可観測性が足りなくなった段階でLakera GuardまたはGalileoを重ねる順序が実務的です。Rebuff（rebuff.ai）は自己強化型インジェクション防御として広く紹介されてきましたが、2025年5月にリポジトリがアーカイブされ更新停止しています。新規採用は避け、既存導入済み環境では2026年内にLLM GuardまたはLakera Guardへの置き換えを計画してください。同様にWhyLabs LangKitは事業終了に伴いOSSとしてGitHubで公開継続中ですが、商用サポートは終了しているため中小企業の本番運用には向きません。

AIと担当者の役割分担（検出SLA・エスカレーション・監査体制）

設計上の分岐点は「AIが自動で止めてよい範囲」と「必ず担当者エスカレーションが要る範囲」の線引きです。金銭取引・顧客個人データ更新・外部宛メール送信・APIキーを含むレスポンス生成の4系統は例外なく人間承認を挟む設計が実装ラインの目安になります。承認ゲートの具体的な実装パターンはAIワークフロー承認自動化ガイドを、エージェント本体の設計思想はAIエージェント×中小企業実装ガイドを参照してください。担当者が確認するのは「アラートの緊急度分類」「承認判断の記録」の2点で、判断根拠を1行でも監査ログに残す習慣が後工程の証跡になります。

中小企業向け監査ログ7項目と顧客データ漏洩の発見装置

中小企業のAIエージェント運用で最も欠落しがちなのが監査ログの設計です。他社記事は「監査ログを残しましょう」で終わりますが、専任セキュリティ担当がいない現場では「何を、どの形式で、どこに、何日保管するか」が具体化されないと運用が続きません。以下の7項目を最低構成として、JSON Lines形式でストレージに追記し、SIEMまたは既存のログ基盤（CloudWatch Logs／Google Cloud Logging／Datadog／自前のPostgreSQL）に転送する構成が現実的です。

顧客データが漏洩したときに「気づけるか」の発見装置として、監査ログの上に3つの検知トリガーを重ねます。第1にカナリアトークン——実在しないダミー顧客レコード（例：customer_id=CANARY-001、メールアドレスはドメインを自社管理下に置く）を本番データに紛れさせ、そのIDがログの出力先や外部送信メールに登場した瞬間にSlackへ即時アラートを飛ばします。第2にDLP系の出力フィルタ——メールアドレス・電話番号・マイナンバー形式の文字列が想定外の出力先（社外ドメイン・不明API）へ流れたら送信をブロックし監査ログに記録します。第3に月次の棚卸し——エージェントが持つツール権限一覧と実際の呼び出しログを突き合わせ、90日間一度も使われていない権限を剥奪します。この3層を組めば、専任セキュリティ担当がいなくても「漏れたことに気づかない期間」を大幅に短縮できます。社内RAGの権限設計は社内マニュアルAI検索の実装ガイド、ChatGPT API利用時の管理はChatGPT API業務実装ガイドを併読してください。

導入手順の4ステップ

ステップ1：脅威モデリング（1〜2週間）——現行のAIエージェントが持つツール権限を1枚の表で棚卸しし、6分類のうちどの脆弱性が該当するかを整理します。OWASP LLM Top 10（2025年版）のPDFを参照し、LLM01〜LLM10のうち自社に該当する項目に優先度を付けます。金銭・顧客データ・外部送信の3系統に触れているエージェントは無条件で優先度Aとして扱い、対策設計を先行させます。

ステップ2：対策実装（2〜4週間）——OSSの3点セット（Guardrails AI＋LLM Guard＋Cerbos）をエージェントの入出力とツール呼び出し境界に組み込みます。並行して監査ログ7項目のスキーマを確定し、JSON LinesでCloudWatch LogsまたはGoogle Cloud Loggingへ出力する経路を構築します。人間承認ゲートはSlack承認ボットまたは既存の稟議システムに接続し、承認履歴も監査ログの一部として保存します。

ステップ3：レッドチーミング（1〜2週間）——PromptfooでYAML定義した攻撃シナリオ（既知の間接インジェクション・多言語難読化・PDF埋め込み指示など）をCI/CDに組み込みます。Garakで既知攻撃パターンの網羅スキャンを実行し、Guardrailsが検出できなかったパターンを追加ルール化します。カナリアトークンを本番相当のステージング環境に投入し、アラートが実際に飛ぶことを確認します。

ステップ4：運用と月次レビュー（継続）——監査ログの月次レビューでは「blocked_by_guardrail」の件数推移、「human_approval_required」の承認待ち時間、90日未使用の権限リストの3点をダッシュボード化します。四半期ごとにレッドチーミングを再実行し、年1回のインシデント対応訓練で全社の初動を確認します。運用担当は情シス1名＋業務責任者1名の2名体制が下限です。

失敗パターン3つと回避策

失敗1：検出後の対応手順が未定義——ガードレールがアラートを飛ばしても「誰が」「何分以内に」「どう対処するか」が決まっておらず、Slackチャンネルに通知が溜まるだけで実質無視されるケース。回避策は初動フロー（一次受け→切り分け→対応→事後報告）を1枚のフローチャートに落とし、当番制で回すこと。エスカレーション先の連絡手段を電話まで含めて明記し、営業時間外の対応可否も先に決めておきます。

失敗2：監査ログの欠落・非検索性——ログは出力しているがファイル分割ルールが曖昧で、いざインシデント発生時に該当時刻のログが見つからないケース。回避策は日次ローテーション＋90日以上の保管＋SIEMまたはBigQuery／Athena等での検索可能化。上記の7項目スキーマを守れば、たとえば「customer_id=X の read が発生した全エージェント」を数秒で抽出できます。ログ本文の暗号化と保管期間ポリシーの明文化もセットで行います。

失敗3：PoC止まりで本番展開に至らない——ガードレール・監査ログを開発環境では組んだが、本番エージェントに適用しないまま数か月経過するケース。回避策は「本番リリース時のチェックリスト」にセキュリティ7項目（ツール権限最小化／入力スキャン／出力スキャン／人間承認ゲート／監査ログ／カナリアトークン／レッドチーミング済み）を組み込み、未達項目があると本番デプロイをブロックする仕組みを開発フローに組み込むこと。CIパイプラインでの静的チェック化まで踏み込むと定着します。

よくある質問