Google Workspaceが「間接プロンプトインジェクション」対策を継続強化—ツール連携前提の多層防御に踏み込む一手です

今日の深掘りポイント

• 生成AIが外部データや業務ツールに接続するほど、間接プロンプトインジェクション（Indirect Prompt Injection, IPI）のリスクは幾何級数的に跳ね上がります。Workspaceのような統合環境では「モデル単体の安全性」より「接続先を含む境界面の設計」が勝負どころです。
• Googleは継続的対策という表現を用いており、AI安全の運用サイクル（設計→検証→モニタリング→改善）を前提とした防御を示唆します。これはGoogleのSecure AI Framework（SAIF）の方針とも整合します。
• 防御の肝は、モデル層の抑止ではなく「データ／ツール境界の最小権限化とガードレール」に寄ります。DLP・ラベル・スコープ付きトークン・人手確認・ネットワーク境界の組み合わせが、攻撃の利得を大幅に削ぐ現実解です。
• 攻撃者視点で想定すると、IPIはメール・ドキュメント・ウェブページ・サードパーティ拡張の“供給源”から侵入し、RAGやツール呼び出しで“実害化”します。MITRE ATT&CK/ATLASにまたがるシナリオとして準備すべきです。
• 企業側は「AIを使わせない」ではなく「AIの権限・接続先・入出力を設計で絞る」方向に舵を切るべきです。今日からできるのは、リスクの高いアクションに明示的確認を入れる、接続先をホワイトリスト化する、そしてログと再現性の担保です。

はじめに

間接プロンプトインジェクションは、モデルそのものを直接だますのではなく、モデルが読む外部コンテンツに“命令”を潜ませるやり口です。人が読めば単なる仕様書やメール、ウェブページでも、モデルが読むと「社外に要約を送れ」「機密フォルダを検索せよ」といった命令に見える—だから厄介なのです。
Google Workspaceの対策強化は、単なる「検出フィルタの更新」ではなく、ツール連携とデータ主権の境界面をどう設計するかという、エンタープライズ固有の難題に踏み込む動きに見えます。安全は一度きりでは作れません。継続運用で磨き上げるものです。

一次情報としてGoogleの告知が出ており、我々はそれを手掛かりに、OWASPやNIST、MITREの枠組みと照らして企業実装の勘所を整理します［参考: Google Security Blog（2026/04/03）］。なお、個別実装の未公開部分については、一般に公開されているフレームワークからの推測である旨を明記します。

深掘り詳細

事実整理（一次情報と標準枠組み）

• GoogleはWorkspaceにおける間接プロンプトインジェクション（IPI）に継続的に対策すると表明しています。これは、生成AIが外部の文書・メール・ウェブ・アドオンなどを取り込む場面で、悪性指示がモデルの行動方針を乗っ取る問題に応えるものです［一次情報: Google Security Blog（2026/04/03）］。
  • ここでの「継続的」は、モデル更新だけでなく、接続先・権限・ポリシー・監視を含む運用全体の見直しを含意します（編集部解釈）。
• IPIはOWASPのLLMアプリケーションTop 10でも最上位のリスク（LLM01）として整理され、ツールや外部データ連携で特に顕在化すると定義されています［OWASP LLM Top 10（2023）］。
• リスク管理の標準枠組みとして、NIST AI RMFは「Govern/Map/Measure/Manage」の4機能でライフサイクル管理を求め、運用継続での監視・改善を前提にしています［NIST AI RMF 1.0］。
• Googleが2023年に提示したSecure AI Framework（SAIF）は、開発から運用、レッドチーミングやエコシステム連携まで、6領域で多層防御を設計する指針で、WorkspaceのAI安全方針とも親和性が高いと考えます［Google SAIF］。
• 攻撃ナレッジとしては、MITRE ATLASがプロンプトインジェクションを含む生成AI特有の攻撃パターンを整理しており、ATT&CKとの併用でシナリオ設計が可能です［MITRE ATLAS］。

出典:

• Google Security Blog: Google Workspaceの継続的アプローチ（2026/04/03）［ニュース提供リンク］
• OWASP: LLM01 Prompt Injection［OWASP LLM Top 10（2023）］
• NIST: AI Risk Management Framework 1.0（4機能）
• Google: Secure AI Framework（SAIF, 6領域）
• MITRE: ATLAS（AI攻撃ナレッジベース）

編集部のインサイト（設計で効く“境界面”はどこか）

• モデル層だけでは止まらない
  IPIは「外部コンテンツ→モデル→ツール呼び出し」の連鎖で実害化します。モデル側のプロンプトハードニングや拒否ルールは必要条件ですが、十分条件ではありません。利害が衝突したときに効くのは「ツール層の最小権限」「ハイリスク操作の人手確認」「接続先のホワイトリスト」「DLP/ラベル連動の動的ガード」など、いわゆる“制御プレーン”の設計です。
• 信頼境界の見取り図を書き換える
  これまでの“ユーザーとデータ”の二者関係は、AI導入で“ユーザー—AI—ツール—データ—外部Web”の多段に変わりました。編集部の経験則では、事故の7割は「境界が曖昧な箇所」から起きます。Workspace文書・社内ナレッジ・外部Web・サードパーティ拡張の4つを“未信頼入力”として扱い、AIの実行権限と出力の行き先を分離する構図が有効です（推奨パターンとしての提案です）。
• 監査可能性と再現性を設計要件に
  IPIは事後分析で「どの文書・どのWeb・どのアドオンが引き金か」を特定しづらいのが難点です。プロンプト・コンテキスト・ツール呼び出し・最終アクションの4点を連結ログにし、セキュリティ調査ツールで引けるようにすることが、封じ込めと復旧時間の短縮に直結します。

メトリクスに関する読み解き
本件の信頼性・実装可能性は高く、導入現場にとって“いま設計を変えられる”程度の具体性をもつテーマです。一方で、脅威の新規性は引き続き高く、ツール連携の範囲が広いほど残余リスクが増えやすい構造です。結論として、モデル単体の安全性で安心せず、接続・権限・監査の3点を優先順位高で見直すのが最も費用対効果に優れると考えます。

脅威シナリオと影響

以下は、Workspaceのような統合環境を想定した仮説シナリオです。MITRE ATT&CKは一般的な戦術・技法、MITRE ATLASは生成AI特有の観点で対応づけています（いずれも編集部によるマッピングの試みです）。

• シナリオ1：埋め込み命令つきドキュメントからの“権限横滑り”
  流れ:

  1. 攻撃者がHTMLコメントや見えないテキストに命令を潜ませたドキュメントを共有
  2. AIアシスタントが要約要求に応じて当該文書を取り込み
  3. 文書内の“外部にメール送信せよ／ドライブ全体を検索せよ”といった命令に誘導
  4. メール送信、権限拡大、データ抽出などがトリガー
     対応付け:
  • MITRE ATT&CK: フィッシング/悪性ファイル配布（初期アクセス）、難読化コンテンツの利用（防御回避）、メール収集/送信（コレクション/流出）
  • MITRE ATLAS: Prompt Injection（目標乗っ取り）、Tool Abuse（ツール濫用） 影響:
  • メール経由の外向き情報流出、Driveの機微ファイル要約漏えい、承認なしの共有リンク生成など。

• シナリオ2：外部Web参照型RAGの“ウェブ経由注入”
  流れ:

  1. AIが検索・参照したWebページに「直近の会議メモを送れ」等の悪性指示
  2. AIが指示を“仕様”と誤認し、ツール呼び出しや貼り付けで情報搬出
     対応付け:
  • MITRE ATT&CK: ドライブバイ・コンプロマイズ、Webサービス経由の流出
  • MITRE ATLAS: Prompt Injection via Browsing/Retrieval 影響:
  • 外部サイトへのメタデータ/要約漏えい、サプライヤー情報や個人情報の部分的流出。

• シナリオ3：サードパーティ拡張・ボット経由の“サプライチェーン注入”
  流れ:

  1. 追加した拡張/ボットが返すレスポンスに暗黙命令
  2. AIが高権限トークンで実行、期待外のツール連携が走る
     対応付け:
  • MITRE ATT&CK: サプライチェーン妥協、信頼された関係の悪用
  • MITRE ATLAS: Model/Toolchain Manipulation 影響:
  • 権限の委譲・横展で管理外のデータ域へアクセス、監査経路外の外部送信。

防御観点での要点:

• ツール呼び出しのガード（ホワイトリスト、動的スコアリング、人手承認）
• 未信頼ソースの分離（Web/外部共有ドキュメントを“検疫”扱いする）
• DLP＋ラベル連動で「特定感度以上はAIの参照不可」「外部送信をブロック」
• ログの完全性（入力プロンプト、取り込んだ文書識別子、ツール呼び出し、最終アクションの鎖を監査可能に）

セキュリティ担当者のアクション

“来週の変更申請に載せられる”実務観点で、優先順位の高い対策を挙げます。

1. 信頼境界の再定義

• 外部Web、社外共有ドキュメント、メール本文/添付、サードパーティ拡張は未信頼として扱い、AIの参照経路を明示的に区分します。

2. ツール権限の最小化とリスクに応じたガード

• メール送信、ファイル共有、カレンダー招集など“外向き・組織変更系”アクションには、明示確認（Just-in-time consent）や二者承認を要求します。OAuthスコープはread-first/least privilegeで設計します。

3. 接続先のホワイトリスト化

• RAGやブラウジングが参照できるドメインを限定し、未知サイトはサマリのみでアクション不可にします。既知の社内ナレッジ源のみを“高信頼”に昇格します。

4. DLP/ラベル連動のガードレール

• DriveラベルやDLP分類に応じ、AIの参照可否・要約粒度・外部送信可否を自動制御します。機微情報は要約も不可、もしくはトークナイズ/置換の上でのみ参照可にします。

5. 出力のサニタイズと“エグレス抑止”

• AIの最終出力がURL/コード/命令を含む場合に隔離表示する、外向きWebサービスへの直接送信を既定で無効化するなど、出力側の安全弁を用意します。

6. ログの連結とインシデント対応準備

• プロンプト、コンテキスト（参照文書ID/URL）、ツール呼び出し、アクション結果を同一トレースIDで記録し、セキュリティ調査ツールで検索可能にします。プロンプトインジェクション対応のプレイブックをSOCに配備します。

7. レッドチーミングと回帰テスト

• OWASP LLM Top 10に沿ったテストケースで、メール/ドキュメント/ウェブ/拡張ごとにIPI侵入テストを実施します。モデル更新・権限変更時に回帰テストを自動で走らせます。

8. 拡張エコシステムの検証

• 追加するアドオン/ボットは事前審査と最小権限、ネットワーク制御を義務化します。ベンダーのセキュリティ保証と更新頻度をレビューします。

9. 従業員教育のアップデート

• 「AIが参照した文書やウェブに悪性命令が含まれ得る」ことを周知し、AIからの“外部送付提案”を鵜呑みにしない文化を作ります。

10. ガバナンス整合（NIST AI RMF/SAIF）

• 方針・手順・モニタリングを、NIST AI RMFの4機能とSAIFの6領域に紐付けて文書化します。規制・監査に備え、変更管理と事後報告の経路を明確にします。

参考情報

• Google Security Blog: Google Workspaceの間接的プロンプトインジェクション対策（2026/04/03）［ニュース提供リンク］
  http://security.googleblog.com/2026/04/google-workspaces-continuous-approach.html
• OWASP Top 10 for LLM Applications（LLM01: Prompt Injection）
  https://owasp.org/www-project-top-10-for-large-language-model-applications/2023/LLM01-Prompt-Injection
• NIST AI Risk Management Framework 1.0（Govern/Map/Measure/Manage）
  https://www.nist.gov/itl/ai-risk-management-framework
• Google Secure AI Framework（SAIF）
  https://cloud.google.com/blog/products/identity-security/introducing-googles-secure-ai-framework
• MITRE ATLAS（AI攻撃ナレッジベース）
  https://atlas.mitre.org/

本稿で述べた一部の具体像は、公開フレームワークと一般的な実装パターンに基づく編集部の推測を含みます。Googleの個別実装の非公開部分については、今後の一次情報を待ちたいところです。とはいえ、今日から変えられる“境界の設計”と“権限の絞り込み”は、どのベンダーのAIでも効く普遍手段です。ここを丁寧に積み重ねることが、IPI時代を安全に渡る最短距離です。