投稿者 global-ai-media 
Google Geminiにおいて、悪意のあるカレンダー招待を通じてプライベートデータが漏洩する脆弱性が報告されました。この事例は、生成AIを社内システムやグループウェアと連携させる際に潜む「間接的プロンプトインジェクション」のリスクを浮き彫りにしています。日本企業がLLM活用を進める上で避けて通れないセキュリティ課題と、現実的な対策について解説します。
悪意ある招待状がAIを操る「間接的プロンプトインジェクション」
今回報告されたGoogle Geminiの脆弱性は、攻撃者が作成した「悪意のある指示を含むカレンダー招待」をユーザーが受信することから始まります。ユーザーがGeminiに対して「今日の予定を教えて」と尋ねると、AIはカレンダー情報を読みに行きますが、その際、招待状に含まれた隠された指示（プロンプト）まで実行してしまいます。結果として、ユーザーの意図しないデータ送信や操作が行われる可能性があります。
これは「間接的プロンプトインジェクション（Indirect Prompt Injection）」と呼ばれる攻撃手法です。従来のプロンプトインジェクションはユーザー自身がAIに特殊な命令を入力するものでしたが、間接型では、AIが参照するメール、カレンダー、ウェブサイトなどに攻撃コードが仕込まれます。RAG（検索拡張生成）や社内データ検索など、AIに「外部データを読ませる」活用が進む現代において、極めて深刻な脅威となりつつあります。
クラウド基盤への侵入と権限昇格のリスク
元記事では、カレンダー情報の漏洩に加え、Google Cloud Vertex AIのエージェント機能における権限昇格の可能性についても触れられています。これは、AIエージェントが持つ「ツールを実行する権限」が悪用されるリスクを示唆しています。
企業システムにおいて、AIが単に回答を生成するだけでなく、APIを叩いて設定変更を行ったり、データベースを操作したりする自律型エージェント（Agentic AI）の導入が期待されています。しかし、もしAIが外部からの悪意ある入力によって騙され、本来アクセスすべきでない領域にアクセスしたり、管理者権限でコマンドを実行したりすれば、企業の基幹システムそのものが危険に晒されます。特にクラウド環境のIAM（Identity and Access Management）設定とAIの挙動が複雑に絡み合う部分では、従来のセキュリティ診断では見落としがちな穴が生まれやすいのです。
日本企業の現場におけるジレンマと対策
日本国内でも、Microsoft 365 CopilotやGoogle Workspaceと連携したGeminiの導入が進んでおり、業務効率化への期待が高まっています。しかし、「会議の調整」や「メールの要約」といった便利な機能は、AIが常に外部からの入力データ（招待状や受信メール）に晒されている状態であることを意味します。
セキュリティを重視するあまりAIのアクセス権限を過度に絞れば、利便性は損なわれます。一方で、無邪気に全権限を与えれば、今回のような攻撃を受けた際に甚大な被害をもたらします。日本の組織文化では、一度セキュリティ事故が起きると技術全体の利用が凍結される傾向がありますが、リスクをゼロにすることを目指すのではなく、「万が一AIが騙されても被害を最小限に抑える」設計思想への転換が必要です。
日本企業のAI活用への示唆
今回の事例を踏まえ、日本企業が実務レベルで検討すべきポイントは以下の3点に集約されます。
- 「人間参加（Human-in-the-Loop）」の設計維持：
AIが外部入力を元に重要なアクション（外部への送信、設定変更、決済など）を行う場合は、必ず人間が最終確認を行うプロセスを挟むべきです。特に自動化が進むAgentic AIの導入初期においては必須のガードレールとなります。 - AIに対する「最小権限の原則」の徹底：
従業員に付与された権限をそのままAIエージェントにも与えるのではなく、AIが実行可能なスコープを厳密に制限する必要があります。「読み取り専用」にするか、特定のAPIしか叩けないようにするなど、AIが乗っ取られた際の爆発半径（Blast Radius）を最小化するIAM設計が求められます。 - 入力データのサニタイズと信頼境界の再定義：
AIに読み込ませるデータ（メール、カレンダー、Web検索結果）は「信頼できない入力」として扱う必要があります。従来のWebアプリ開発と同様に、LLMに入力されるデータに対しても、セキュリティ製品によるフィルタリングや、プロンプト内での区切り文字による明確な指示の分離など、防御策を講じることが重要です。