投稿者 global-ai-media 
生成AIの活用フェーズは、単なる対話や検索から、業務プロセスを自律的に実行する「エージェント」へと移行しつつあります。しかし、Microsoft 365 CopilotやServiceNowといった主要プラットフォームで指摘された新たな脆弱性は、この進化に潜む重大なセキュリティリスクを浮き彫りにしました。日本企業がAIによる業務自動化を推進する上で避けて通れない「権限管理」と「信頼性」の課題について解説します。
「チャットボット」から「エージェント」へ：リスクの質的変化
生成AIの活用は、情報を検索・要約する「RAG（検索拡張生成）」の段階から、ユーザーに代わってシステム操作やワークフローを実行する「AIエージェント」の段階へと進化しています。この変化は業務効率を劇的に向上させる一方で、セキュリティリスクの質を大きく変えつつあります。
最近、セキュリティ研究者によってMicrosoft 365 CopilotやServiceNowのAIエージェントにおける脆弱性が指摘されました。これらは、攻撃者がターゲットのメールアドレスなどを知っているだけで、AIを介してセキュリティ制御を回避し、不正なアクションを実行させることが可能になるというものです。これまでAIのリスクといえば「ハルシネーション（嘘の回答）」や「情報漏洩」が中心でしたが、エージェント化に伴い、「不正な業務実行」や「権限昇格」といった、より直接的な実害を伴うリスクが顕在化しています。
間接プロンプトインジェクションと「混乱する代理人」
今回指摘された問題の核心は、「間接プロンプトインジェクション」と呼ばれる攻撃手法と、AIエージェントが持つ権限の曖昧さにあります。攻撃者は、AIが読み込むメールやドキュメントの中に、人間には見えない形で悪意ある指示（プロンプト）を埋め込みます。AIがその情報を処理する際、本来のユーザーの指示ではなく、埋め込まれた悪意ある指示を優先して実行してしまうのです。
例えば、AIエージェントが「管理者権限」に近い操作権限を持っていた場合、攻撃者は一般社員のふりをしてAIを騙し、本来アクセスできないデータの取得や、承認プロセスのバイパスを行わせることが可能になります。これはセキュリティ用語で「Confused Deputy（混乱した代理人）」問題と呼ばれ、権限を持つAIが、悪意ある第三者の手先として利用されてしまう現象です。
日本企業におけるSaaS活用とガバナンスの盲点
多くの日本企業において、Microsoft 365やServiceNowは業務インフラの中核を担っています。特にDX（デジタルトランスフォーメーション）の一環として、これらのプラットフォーム上でAIによる自動化を進めようとしている組織にとって、今回の事例は対岸の火事ではありません。
日本企業特有の課題として、SaaS導入時に「ベンダーがセキュリティを担保してくれている」という過度な安心感を持つ傾向があります。しかし、AIエージェントの挙動は、設定された「アクセス権限」と「データ範囲」に依存します。ベンダー側がプラットフォームの脆弱性を修正しても、企業側がAIに対して過剰な権限（全てのSharePointサイトへのアクセス権など）を付与していれば、内部不正や外部からの攻撃に対して脆弱なままとなります。稟議や承認といった日本的なワークフローをAIに任せる場合、このリスクは内部統制（J-SOX）上の不備にもつながりかねません。
日本企業のAI活用への示唆
AIエージェントの導入を安全に進めるために、日本の意思決定者や実務担当者は以下のポイントを再点検する必要があります。
1. AIへの「最小権限の原則」の徹底
「便利だから」という理由で、AIエージェントに広範な管理者権限や全データへのアクセス権を与えていないか見直してください。AIはユーザーの代理として動くため、そのユーザーが本来必要とする最小限の権限のみで動作するように設計・設定する必要があります。特にServiceNowのようなワークフロー基盤では、AIが実行できるアクションを厳格に制限することが重要です。
2. 「Human in the Loop」の再定義
AIによる完全自動化を目指すのではなく、重要な意思決定や外部へのデータ送信、システム設定の変更といったクリティカルな操作の直前には、必ず人間による最終確認プロセスを挟む設計にすべきです。これにより、万が一AIがプロンプトインジェクション攻撃を受けたとしても、実害が出る前に人間が食い止めることが可能になります。
3. ベンダー任せにしないリスク評価
MicrosoftやServiceNowなどの大手ベンダーであっても、AI機能の実装初期段階では予期せぬ挙動が発生し得ます。新機能を全社展開する前に、情報システム部門やセキュリティチームによるPoC（概念実証）を行い、意図しないデータアクセスや操作が可能になっていないか、自社のセキュリティポリシーに照らし合わせて検証する体制を持つことが不可欠です。