Microsoftの「Updating the taxonomy of failure modes in agentic AI systems」は、Microsoft 365 Copilotの画面が大きく変わる更新ではなく、エージェントAIの失敗モード分類をv2.0へ更新した公式情報です。結論から言うと、管理者と開発者は「プロンプト対策」だけでなく、MCP・プラグイン・外部ツール・エージェント間連携・人間承認・長時間セッションまで含めて、エージェントAIの設計と運用を見直す必要があります。
特に影響が大きいのは、Microsoft 365 Copilotのエージェント、Copilot Studioで作成したエージェント、Azure AI Foundryなどで構築した独自エージェント、MCPサーバーや外部API連携を使う業務自動化です。Microsoftは、2025年4月に公開したv1.0から12か月のレッドチーミング結果を踏まえ、v2.0で7つの新しい失敗モードを追加したと説明しています。公式ページ上は米国時間2026年6月4日公開の表記で、日本時間では2026年6月5日ごろに確認される更新情報として扱えます。(Microsoft)
MicrosoftのAI/Copilot更新で何が変わるのか
今回の更新の中心は、Microsoft製品の単一機能ではなく、エージェントAIシステムを安全に設計・評価するためのリスク分類の更新です。Microsoft AI Red Teamは、2025年4月に公開した「Taxonomy of Failure Modes in Agentic AI Systems」のv1.0を、実運用中のエージェントAIに対する12か月のレッドチーミング結果に基づいてv2.0へ更新しました。v2.0では、7つの新しい失敗モードの追加、緩和策の拡張、実際の攻撃パターンを踏まえた整理が行われています。(Microsoft)
重要なのは、エージェントAIでは「チャットの回答が間違う」だけがリスクではない点です。エージェントは外部データを読み、ツールを呼び出し、他のエージェントに作業を委任し、場合によってはファイル作成・送信・更新・削除のような業務操作まで行います。そのため、攻撃者にとっては、プロンプトそのものだけでなく、ツール定義、MCPサーバー、プラグイン、画面上の視覚情報、承認UI、永続メモリなども攻撃対象になります。
| 観点 | これまでの見方 | v2.0で重視すべき見方 |
|---|---|---|
| 主なリスク | プロンプトインジェクション、脱獄、誤回答 | サプライチェーン、MCP/プラグイン悪用、セッション汚染、ゴール乗っ取り |
| 管理対象 | モデル、プロンプト、データアクセス権 | エージェント、外部ツール、承認フロー、エージェント間通信、永続メモリ |
| セキュリティ評価 | 単発の入力テスト | 複数ステップの業務フロー全体を通したシステムレベルのテスト |
| 運用上の対策 | 注意書き、利用ルール、基本的なログ | SBOM、バージョン固定、出所検証、最小権限、人間承認の再設計 |
Microsoftは、この分類を「コンプライアンスのチェックリスト」ではなく、脅威モデリングの道具として使うべきだと説明しています。つまり、全項目を機械的に埋めるのではなく、自社のエージェントがどの条件で失敗モードに該当するかを確認し、検知または防止できる統制があるかを見直すことが目的です。(Microsoft)
追加された7つの失敗モード
Microsoftがv2.0で追加した失敗モードは、エージェントAIが外部ツールや複数ステップの処理を扱うようになったことで顕在化したものです。日本語で理解しやすいよう、実務上の意味と確認ポイントに分けて整理します。
| 新しい失敗モード | 何が問題か | 管理者・開発者が確認すべきこと |
|---|---|---|
| Agentic Supply Chain Compromise | プラグイン、MCPサーバー、プロンプトテンプレート、ツール説明文などに悪意ある自然言語の指示が紛れ込み、エージェントの動作が変えられる | 外部コンポーネントの棚卸し、出所確認、バージョン固定、変更監視、ツール説明文のレビュー |
| Goal Hijacking | 正常な業務依頼に見える指示が、エージェントの最終目的を別方向へ誘導する | 初期依頼と最終アクションの整合性確認、実行計画の検証、許可されたゴールの明文化 |
| Inter-Agent Trust Escalation | あるエージェントが別のエージェントやオーケストレーターに対し、偽の役割や権限を主張して権限昇格する | エージェントIDの検証、自己申告の権限を信頼しない設計、委任時の権限境界 |
| Computer Use Agent Visual Attack | 画面操作型エージェントが、画像・UI・隠しテキストなどから攻撃指示を読み取る | GUI操作エージェントの利用範囲、画面入力の信頼性、危険操作前の検証 |
| Session Context Contamination | セッション初期に混入した不正情報が、後続ステップの判断を徐々に汚染する | 信頼済みコンテキストと外部取得情報の分離、コンテキストの出所管理、長時間セッションの制限 |
| MCP / Plugin Abuse | MCPやプラグインのツール説明、サーバー側指示、プロトコル上の信頼関係が悪用される | MCPサーバーの許可リスト化、ツール権限の最小化、不要なプラグインの無効化 |
| Capability / Architecture Disclosure | ツール名、スキーマ、システムプロンプト構造、メモリ仕様、承認条件などが漏れ、攻撃者に内部構造を知られる | デバッグ情報の露出防止、内部仕様の非表示、アーキテクチャ情報を引き出すテスト |
Microsoftの説明では、エージェントAIのサプライチェーンは従来のコード依存関係だけではありません。自然言語で書かれたツール説明、プロンプトテンプレート、外部レジストリ、MCPサーバーも、エージェントの判断に影響する「実行可能な前提」として扱う必要があります。(Microsoft)
実務では、ここが最も見落とされやすいポイントです。たとえば「便利そうな外部MCPサーバーを追加する」「社内の誰かが共有したCopilotエージェントをそのまま公開する」「検証環境で作ったHTTP連携を本番にも流用する」といった行為は、すべてエージェントAIの攻撃面を広げます。
影響範囲はMicrosoft 365 Copilotだけではない
今回の分類はMicrosoft Security Blog上の研究記事ですが、影響範囲はMicrosoft 365 Copilotの利用者だけに限定されません。対象になるのは、Microsoft環境でエージェントAIを作る、接続する、公開する、監視するすべてのチームです。
| 対象 | 影響するポイント | 優先して確認すること |
|---|---|---|
| Microsoft 365 Copilotのエージェント | Agent Store、Agent Registry、共有エージェント、外部パートナーエージェント | 許可済みエージェント、作成者、公開範囲、割り当て対象 |
| Copilot Studio | 知識ソース、コネクタ、HTTP要求、スキル、公開チャネル、イベントトリガー | DLPポリシー、認証設定、不要な外部連携のブロック |
| Microsoft Entra | アプリ登録、エンタープライズアプリ、ユーザー同意、管理者同意、アプリ権限 | 過剰なOAuth権限、不要な同意、アプリ専用権限 |
| Microsoft Purview | Copilot/エージェントのデータ保護、監査、DLP、秘密度ラベル | 過共有の検出、AI利用状況の監査、機密データの保護 |
| Defender for Cloud Apps | OAuthアプリの可視化とガバナンス | どのアプリがMicrosoft 365データへアクセスしているか |
| Azure AI Foundry / 独自エージェント | レッドチーミング、リスク評価、CI/CDへの組み込み | 追加された7分類をテストケースに入れる |
Microsoft 365管理センターでは、Copilotのエージェントを有効化、無効化、割り当て、ブロック、削除でき、組織内ユーザーがアクセスできるエージェントは管理者が許可したものに限られます。管理者はAgent Registryで共有エージェントを確認し、安全でない、またはコンプライアンスに合わないエージェントをブロックできます。(Microsoft Learn)
また、Microsoft 365 CopilotはMicrosoft Graph内のデータを利用しますが、ユーザーが少なくとも閲覧権限を持つ組織データのみを提示する仕組みです。ただし、これは「権限設計が正しい」ことが前提です。SharePointやTeamsのアクセス権が広すぎる場合、Copilotやエージェントの回答にもその影響が出る可能性があります。(Microsoft Learn)
管理者が今すぐ確認すべき設定
今回の更新を受けて最初に行うべきことは、新機能を探すことではありません。既存のエージェント、アプリ、権限、承認フローを棚卸しし、エージェントAI特有の攻撃経路に耐えられるかを確認することです。
Microsoft 365管理センターでエージェントを棚卸しする
まず、Microsoft 365管理センターで組織内のエージェントを確認します。特に見るべきなのは、以下のような項目です。
| 確認項目 | 判断基準 |
|---|---|
| 公開済みエージェント | 業務目的、作成者、最終更新日、利用部門が明確か |
| 共有エージェント | 個人作成のまま広範囲に共有されていないか |
| 外部パートナーエージェント | 利用規約、プライバシー文書、必要権限を確認しているか |
| Frontier系・実験的エージェント | 本番データや全社ユーザーに広げていないか |
| 不要エージェント | 使われていないものを削除またはブロックしているか |
Microsoftのドキュメントでは、エージェントは検索機能、カスタムアクション、コネクタ、APIを追加してCopilotの機能を拡張するものと説明されています。これは便利な一方で、外部ツールやAPIがエージェントの行動範囲を広げることも意味します。(Microsoft Learn)
実務上は、「使ってよいエージェント」を全社で自由追加にするより、部署単位・業務単位で割り当てる方が安全です。特にメール送信、ファイル更新、CRM登録、チケット作成、外部HTTPアクセスを伴うエージェントは、公開前にセキュリティレビューを必須にしてください。
Microsoft Entraでアプリ同意と権限を見直す
エージェントAIのリスクは、Copilot画面だけで完結しません。外部アプリ、Graph API、OAuth同意、アプリ専用権限が絡むため、Microsoft Entra側の確認が重要です。
Microsoft Entraでは、ユーザーがアプリケーションにどのように同意できるかを制御できます。設定場所は、Microsoft Entra管理センターの「Identity > Applications > Enterprise apps > Consent and permissions > User consent settings」です。Microsoftは、この設定がユーザー同意を制限または無効化し、セキュリティリスクを減らすためのものだと説明しています。(Microsoft Learn)
確認すべきポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| ユーザー同意 | 一般ユーザーが高権限アプリへ自由に同意できる状態になっていないか |
| 管理者同意 | 組織全体へのアクセス許可が、必要最小限になっているか |
| アプリ権限 | Mail.ReadWrite、Files.ReadWrite.All、Sites.Read.Allなど広範囲な権限が不要に付与されていないか |
| アプリ専用権限 | ユーザーの操作なしで動ける権限をエージェントや連携アプリに与えすぎていないか |
| 退役アプリ | PoCや検証用アプリが本番テナントに残っていないか |
Microsoft Entraでは、テナントに追加されたアプリケーションの付与済み権限を確認し、不要または過剰な権限を取り消す手順が用意されています。過剰な権限を持つアプリや不審なアプリを検出した場合は、まずエンタープライズアプリの権限レビューを行うべきです。(Microsoft Learn)
Defender for Cloud AppsでOAuthアプリを可視化する
MCPやプラグイン、外部ツール連携を使うほど、OAuthアプリの管理は重要になります。Microsoft Defender for Cloud Appsのアプリ権限機能では、どのユーザーインストール型OAuthアプリがMicrosoft 365データへアクセスしているか、どの権限を持つか、誰がアクセスを許可したかを確認できます。(Microsoft Learn)
優先して確認したいのは、次のようなアプリです。
- 多数のユーザーが同意しているが、業務オーナーが不明なアプリ
- 高い権限を要求しているが、利用実態が少ないアプリ
- 外部発行元のアプリで、公開元やサポート体制が確認できないもの
- ファイル、メール、Teams、SharePointへの読み書き権限を持つアプリ
- 退職者や外部委託先が作成・管理していたアプリ
エージェントAIでは、OAuthアプリの権限がそのまま「エージェントが到達できる業務データや操作」に影響します。利用者向けには便利に見える連携でも、攻撃者に乗っ取られた場合の影響範囲を考えて許可する必要があります。
Copilot StudioではDLPと認証を必ず確認する
Copilot Studioでエージェントを作成している場合は、Power Platform管理センターのデータポリシーを確認します。Microsoftのドキュメントでは、Copilot StudioのコネクタをBusiness、Non-business、Blockedのデータグループに分類し、意図しないデータ流出から組織データを保護できると説明されています。(Microsoft Learn)
特に、次の機能は本番展開前に制御方針を決めておくべきです。
| 機能 | リスク | 推奨される確認 |
|---|---|---|
| 知識ソース | 公開Webサイトや広範囲なSharePointを取り込み、不要な情報を回答する | 利用可能な知識ソースを限定し、必要ならエンドポイント単位で許可・拒否する |
| Power Platformコネクタ | エージェントが外部システムを操作できる | 業務上必要なコネクタのみ許可する |
| HTTP要求 | 任意の外部URLへアクセスできる可能性がある | 原則ブロックし、必要な宛先だけ許可する |
| スキル | エージェント機能が広がり、検証範囲が増える | 本番利用前にセキュリティレビューする |
| 公開チャネル | Teams、SharePoint、Web、Direct Lineなどから利用可能になる | 利用者・公開範囲・認証要件を明確にする |
| イベントトリガー | 人間の明示的な入力なしに処理が走る | 高リスク業務では制限または追加承認を設ける |
Microsoftは、Copilot Studioのデータポリシーで、認証の要求、知識ソースのブロック、Power Platformコネクタのツール利用ブロック、HTTP要求のブロック、スキルのブロック、公開チャネルの制御、イベントトリガーのブロックなどを設定できると説明しています。(Microsoft Learn)
認証も必ず確認してください。Copilot Studioでは、エージェントの「Settings > Security > Authentication」から認証方式を選択でき、選択肢には「No authentication」「Authenticate with Microsoft」「Authenticate manually」があります。社内データや業務操作に関わるエージェントで「No authentication」を使う場合は、公開範囲とデータアクセスをかなり慎重に設計する必要があります。(Microsoft Learn)
Microsoft PurviewでCopilotとエージェントのデータ保護を確認する
エージェントAIの安全性は、エージェント側の設定だけでは担保できません。アクセス権が広すぎるファイル、秘密度ラベルが未整備のドキュメント、監査されていないAI利用があると、Copilotやエージェントの回答・操作に影響します。
Microsoft Purviewでは、Microsoft 365 CopilotとCopilot ChatのAIインタラクションに対して、監査、データ分類、秘密度ラベル、DLP、Insider Risk Management、Communication Compliance、eDiscovery、Compliance Managerなどの機能がサポートされています。(Microsoft Learn)
管理者は、次の順番で確認すると効率的です。
| 順番 | 作業 | 目的 |
|---|---|---|
| 1 | Microsoft 365 Copilotビューで過共有リスクを確認 | Copilotが参照し得るデータの権限を整理する |
| 2 | 秘密度ラベルとDLPポリシーを確認 | 機密情報がエージェント処理に流れないようにする |
| 3 | AIアプリのリスクのある操作を検出 | 危険なプロンプトや不適切な利用を把握する |
| 4 | 監査ログとアクティビティを確認 | インシデント時に追跡できる状態にする |
| 5 | 必要に応じてeDiscoveryや保持ポリシーを整備 | 法務・監査対応に備える |
Microsoft Purviewには、Microsoft 365 Copilot向けに「機密ラベルでデータを保護する」「AIアプリのリスクのあるやり取りを検出する」「Microsoft 365 Copilotとエージェント処理から秘密度ラベル付きアイテムを保護する」といった推奨事項やワンクリックポリシーが用意されています。(Microsoft Learn)
開発者が設計・移行・展開で見直すべきポイント
開発者にとって今回の更新は、「モデルに安全なプロンプトを入れる」だけでは不十分だというメッセージです。エージェントは、ツール、権限、記憶、外部入力、承認UIを組み合わせたシステムとして評価する必要があります。
外部コンポーネントをSBOMに含める
Microsoftは、エージェントのサプライチェーンを棚卸しし、プラグイン、MCPサーバー、プロンプトテンプレート、ツール説明文を含むSBOMを作成し、バージョンを固定することを推奨しています。特に「自然言語のツール説明をコードのように扱う」という考え方が重要です。(Microsoft)
開発チームでは、次のような項目をリポジトリや構成管理に含めると実務に落とし込みやすくなります。
| 管理対象 | 記録すべき情報 |
|---|---|
| MCPサーバー | URL、運用者、認証方式、許可ツール、バージョン、変更履歴 |
| プラグイン | 発行元、必要権限、利用API、更新日、レビュー担当者 |
| プロンプトテンプレート | 用途、入力変数、禁止事項、変更履歴、承認者 |
| ツール説明文 | エージェントに見せる説明文、隠れた指示の有無、想定外の誘導表現 |
| 外部API | 認証方式、レート制限、書き込み権限、失敗時の挙動 |
よくある失敗は、検証時に便利だった外部ツールを、そのまま本番に持ち込むことです。本番移行時には、「何を呼び出せるか」だけでなく、「そのツール定義を誰が変更できるか」「変更を検知できるか」まで確認してください。
エージェント間の信頼を自己申告にしない
複数エージェント構成では、オーケストレーターがサブエージェントに処理を委任します。このとき、サブエージェントが「私は管理者権限を持つエージェントです」「この操作は承認済みです」と主張しただけで信頼してはいけません。
Microsoftは、高リスクシナリオではエージェントIDを暗号学的に確立し、オーケストレーターが自己申告の役割に基づいて権限を上げない設計を推奨しています。(Microsoft)
実装上は、次のような設計が望まれます。
- エージェントごとに個別のIDを持たせる
- 共有の管理者アカウントや共通シークレットを使い回さない
- サブエージェントの要求権限をオーケストレーター側で再評価する
- 書き込み・削除・外部送信の操作は別権限に分離する
- エージェント間メッセージに、検証可能な発信元情報を含める
「社内エージェントだから信頼する」という前提は危険です。自然言語で役割や意図を偽装できる点が、従来のAPI連携とは違います。
Human-in-the-loopを“確認ボタン”で終わらせない
Microsoftのレッドチーミングでは、Human-in-the-loop、つまり人間承認のバイパスが一貫して悪用されたと説明されています。承認疲れ、確率的な承認呼び出し、単独では問題に見えない小さなステップの積み重ねによって、最終的に大きな影響を持つ操作へ到達するパターンが確認されています。(Microsoft)
そのため、単に「実行前にOKボタンを出す」だけでは不十分です。
| 悪い承認UI | 改善すべき承認UI |
|---|---|
| 「処理を続行しますか？」だけ表示 | どのデータに、どの操作を、どの権限で行うかを明示 |
| エージェント自身が作った説明文をそのまま表示 | 実際のツール呼び出し内容から承認文を生成 |
| 何度も同じ承認を出す | 頻度やパターンを監視し、承認疲れを検知 |
| 低リスク操作と高リスク操作が同じ承認 | 取消不能性、外部送信、影響範囲に応じて段階承認 |
| 複数ステップの最終結果が見えない | 一連の処理を分解し、最終的な影響を示す |
たとえば、ファイルを要約するだけなら低リスクでも、その後に「外部メールへ添付して送信」「CRMの顧客情報を更新」「契約書フォルダを一括変更」するならリスクは大きく変わります。承認は単発の操作ではなく、業務フロー全体で設計してください。
セッションコンテキストを信頼済み情報と分離する
エージェントAIは、長い会話や複数ステップのタスクの中でコンテキストを蓄積します。v2.0で追加されたSession Context Contaminationは、セッション初期に混入した不正な情報が、後続の判断に影響し続ける失敗モードです。
Microsoftは、蓄積されたコンテキストをセキュリティ上重要なデータ構造として扱い、コンテキストの出所追跡、信頼済みシステムコンテキストと外部取得情報の構造的分離、セッション整合性の監視、外部コンテンツが推論に与える影響範囲の制限を挙げています。(Microsoft)
開発時には、少なくとも次の設計を検討してください。
- システム指示、ユーザー入力、検索結果、外部Web、ツール出力を同じ文字列として混ぜない
- 外部取得情報には出所・取得時刻・信頼レベルを持たせる
- 長時間セッションでは、重要操作の前に意図と参照情報を再確認する
- 永続メモリへ保存する情報を制限し、保存前に検証する
- セッション途中で権限や目的が変わった場合は、新しいセッションとして扱う
セッション汚染は、単一のログ行だけを見ると異常に見えないことがあります。後から調査できるよう、入力、取得情報、ツール呼び出し、承認、最終アクションをひとつの流れとして追えるログ設計が必要です。
レッドチーミングで追加すべきテスト項目
Microsoftは、追加された7分類をレッドチーミングのカバレッジに入れることを推奨しています。特に、本番データや外部面に触れるエージェントでは、Computer Use Agent Visual Attack、Session Context Contamination、Capability Disclosure、Goal Hijackingを必須テストにすべきだと説明しています。(Microsoft)
開発チームやセキュリティチームは、次のようなテストケースを用意すると実務に落とし込みやすくなります。
| テスト分類 | テスト例 |
|---|---|
| サプライチェーン | MCPサーバーのツール説明に不正指示を入れた場合、エージェントが従うか |
| ゴール乗っ取り | 正常な依頼に見える文章で、最終的に別の送信先へ誘導できるか |
| エージェント間権限昇格 | サブエージェントが偽の役割を主張した場合、オーケストレーターが拒否するか |
| 視覚攻撃 | 画像や画面内の隠しテキストをエージェントが指示として扱わないか |
| セッション汚染 | 会話序盤の不正情報が後続の重要判断に影響しないか |
| MCP/プラグイン悪用 | 悪意あるツール説明やサーバー側指示で他ツールの挙動を上書きできないか |
| 機能開示 | ツール名、内部スキーマ、承認条件、システムプロンプト構造を聞き出せないか |
| Human-in-the-loop回避 | 小さな操作を積み重ねて、大きな影響を持つ処理に到達できないか |
Azure AI Foundryでは、AI Red Teaming Agentが生成AIシステムの安全性リスクを設計・開発段階で見つけるための機能として提供されており、自動スキャンや敵対的プロービングのシミュレーションにより、既知リスクの特定と評価を支援します。(Microsoft Learn)
ただし、ツールによる自動評価だけで十分とは考えない方が安全です。Microsoftも、ゼロクリックのHuman-in-the-loop回避、エージェント間の信頼昇格、セッション汚染は、モデル単体の評価だけでは表面化しにくく、完全なタスクフローを通したシステムレベルのテストが必要だと説明しています。(Microsoft)
移行・展開時に失敗しやすいポイント
今回の更新は、既存環境に対して「必ずこの日までに移行」という性質のものではありません。しかし、PoCから本番展開へ進むエージェントAIでは、移行時に次の失敗が起きやすくなります。
| 失敗しやすい場面 | 起きる問題 | 対策 |
|---|---|---|
| PoCの設定を本番へ流用する | 検証用の広い権限、未確認の外部ツール、デバッグ情報が残る | 本番移行前に権限・外部接続・ログ出力を再レビュー |
| エージェントを全社公開する | 想定外の部門が機密データや業務操作に使う | パイロット部門から段階展開する |
| MCP/プラグインの更新を自動追随する | ツール説明や機能変更に気づかない | バージョン固定と変更承認を行う |
| 承認UIを軽視する | ユーザーが内容を読まずに承認する | 操作内容・対象データ・影響範囲を明示する |
| 監査ログを後回しにする | インシデント時に原因を追えない | 入力、取得データ、ツール呼び出し、承認、出力を記録する |
| SharePoint権限を見直さない | Copilotやエージェントが過共有データを参照する | PurviewとSharePoint権限レビューを先に行う |
展開判断では、次の条件に該当するエージェントを高リスクとして扱うと整理しやすくなります。
- 社外送信、ファイル更新、削除、承認、購入、チケット起票などのアクションを実行する
- 顧客情報、契約情報、財務情報、人事情報、ソースコード、APIキーに触れる
- 外部Web、MCPサーバー、プラグイン、カスタムコネクタを利用する
- ユーザー操作なしにイベントトリガーで起動する
- 複数エージェントにタスクを委任する
- 永続メモリや長時間セッションを利用する
- GUIや画面情報を読み取り、操作する
逆に、公開情報のみを参照し、読み取り専用で、外部ツールを使わず、永続メモリも持たないエージェントは相対的に低リスクです。ただし、低リスクでも利用範囲やログの方針は明確にしておくべきです。
管理者と開発者がこの四半期に行うべきこと
Microsoftは、v2.0の追加内容を受けて、今四半期に行うべき具体策として、サプライチェーンの棚卸し、エージェントIDの暗号学的検証、7分類のレッドチームカバレッジ追加、Human-in-the-loop UXの監査を挙げています。(Microsoft)
日本企業のMicrosoft環境で実行するなら、次の順番が現実的です。
| 優先度 | やること | 担当 |
|---|---|---|
| 高 | Microsoft 365管理センターでエージェント一覧を確認し、不要・不明なものをブロック | Microsoft 365管理者 |
| 高 | Entraでアプリ同意、エンタープライズアプリ、OAuth権限をレビュー | ID管理者 |
| 高 | Copilot StudioのDLP、認証、HTTP要求、イベントトリガーを確認 | Power Platform管理者 |
| 高 | Purviewで過共有、秘密度ラベル、DLP、AI利用監査を確認 | セキュリティ・コンプライアンス担当 |
| 中 | MCPサーバー、プラグイン、プロンプトテンプレート、ツール説明文をSBOMに含める | 開発者 |
| 中 | Human-in-the-loopの承認文と承認条件を見直す | 開発者・業務オーナー |
| 中 | 追加された7失敗モードをテストケースに入れる | セキュリティチーム |
| 中 | 本番展開前の段階展開ルールを作る | 情シス・業務部門 |
最初から完璧なエージェントAIガバナンスを作る必要はありません。まずは「どのエージェントが、どのデータに、どの権限で、どの外部ツールを通じて、何を実行できるのか」を一覧化してください。ここが見えないままでは、Microsoftのv2.0分類を読んでも、自社のどこにリスクがあるか判断できません。
まとめ：エージェントAIは“モデル”ではなく“業務システム”として守る
Microsoftの「Updating the taxonomy of failure modes in agentic AI systems」は、エージェントAIのリスクが次の段階に入ったことを示す更新です。v2.0で追加された7つの失敗モードは、プロンプトだけでなく、MCP、プラグイン、外部ツール、画面操作、承認UI、永続メモリ、エージェント間通信まで守る必要があることを示しています。
管理者は、Microsoft 365管理センター、Microsoft Entra、Microsoft Purview、Defender for Cloud Apps、Power Platform管理センターを横断して、エージェントと権限を棚卸ししてください。開発者は、外部コンポーネントをSBOMに含め、Human-in-the-loopを再設計し、セッション全体を対象にしたレッドチーミングを行うべきです。
次に取るべき行動は明確です。まず、組織内のCopilotエージェントと外部連携を一覧化し、「本番データに触れる」「書き込み操作を行う」「外部ツールを使う」ものから優先して、今回追加された7つの失敗モードに照らして見直しましょう。
コメント