2026年5月1日のMicrosoft Entra公式ドキュメント更新「Remove (preview) tags and license note from GSA agents articles」は、Microsoft EntraのGlobal Secure Access（GSA）でCopilot Studioエージェントの通信を保護する記事に関する更新です。結論から言うと、今回まず確認すべきなのは「機能の設定手順が大きく変わったか」ではなく、preview表記の削除をどこまで運用判断に反映してよいか、ライセンス確認をどう扱うか、既存のGSAエージェント構成に影響があるかです。
特にsecurity admins、compliance teams、enterprise IT readersにとって重要なのは、「previewの文字が消えた＝自社で即本番全面展開できる」と短絡しないことです。GitHub上の差分では、対象は主に2つのGSA agents関連記事のタイトル変更とライセンス注記の扱いであり、設定フロー全体を置き換えるような大幅変更ではありません。影響確認では、公式ドキュメント、Microsoft Entra管理センター、Power Platform管理センター、契約ライセンス、監査ログの4点を突き合わせて判断する必要があります。(GitHub)
Microsoft Entraの公式ドキュメント更新で何が変わったか
今回の更新は、MicrosoftDocsのentra-docsリポジトリにあるコミット0bb536b839a0edeb397604aef31fa7fc027244a2で確認できます。コミットメッセージは「Remove (preview) tags and license note from GSA agents articles」で、変更対象はGlobal Secure Access配下のGSA agents関連記事2本です。(GitHub)
主な差分は次のとおりです。
| 確認項目 | 変更内容 | 管理者が見るべきポイント |
|---|---|---|
| 概念説明記事 | Learn about Secure Web And AI Gateway for Microsoft Copilot Studio agents (preview)から(preview)が削除 | 社内資料や設計書で「プレビュー機能」と記載している場合、表記更新が必要か確認する |
| 概念説明記事 | 冒頭付近のライセンスinclude注記が削除 | ライセンス不要になったと解釈せず、別の公式ライセンスページで確認する |
| 構成手順記事 | Configure Secure Web and AI Gateway for Microsoft Copilot Studio agents (preview)から(preview)が削除 | 手順の変更ではなく、記事タイトル上のステータス表記変更として扱う |
| 変更規模 | 2ファイル、2 additions / 4 deletions | 大規模な仕様変更より、ドキュメント表記の整理に近い |
GitHubのパッチでは、概念説明記事と構成手順記事のタイトルから(preview)が削除され、概念説明記事ではライセンス注記のinclude行が削除されています。コミット日時は米国太平洋時間で2026年4月30日夜、日本時間では2026年5月1日に相当します。(GitHub)
「preview削除」をそのままGA化と読んでよいか
今回もっとも誤解しやすいのは、(preview)表記の削除を「関連機能が完全に一般提供された」と即断してしまうことです。
Microsoft LearnのMicrosoft Entra側記事では、Copilot Studioエージェント向けSecure Web and AI Gatewayのページタイトルからpreview表記が外れています。日本語版の概念説明記事も、2026年5月1日に更新されています。(Microsoft Learn)
一方で、Power Platform側の関連ドキュメントでは、ページタイトルに「preview」が残っており、記事本文でもプレビュー機能である旨が示されています。さらに、Power Platform側の記事には、プレビュー機能は本番利用を意図したものではなく、機能制限や変更の可能性があるという説明もあります。(Microsoft Learn)
そのため、実務では次のように判断するのが安全です。
| 判断してはいけないこと | 安全な判断 |
|---|---|
| preview表記が消えたので、全コンポーネントがGAになった | Entra側ドキュメントの表記は更新されたが、関連するPower Platform側ドキュメントや契約条件も確認する |
| ライセンス注記が削除されたので、追加ライセンスは不要 | ライセンス要件はMicrosoft Entraライセンスページや契約情報で再確認する |
| 設定済みの環境に変更作業は不要 | 既存コネクタ、ログ、ポリシー適用範囲、サポート対象トラフィックを点検する |
| 社内の本番展開基準を自動的に満たした | 自社の変更管理、リスク評価、監査証跡、サポート条件に照らして判断する |
企業利用では、ドキュメントのタイトル変更だけで本番展開可否を決めるのではなく、Microsoft 365管理センターのメッセージセンター、Microsoft Entra管理センターの実際の表示、Power Platform側の注意書き、契約ライセンスの4つを確認してから判断するべきです。
GSA agents記事が扱う機能の概要
今回の更新対象は、Microsoft EntraのGlobal Secure Accessを使って、Microsoft Copilot Studioエージェントのネットワーク通信にセキュリティ制御を適用する記事です。
Microsoft Learnの説明では、Global Secure Access for agentsにより、Copilot Studioエージェントが外部リソースへアクセスする通信に対して、ユーザー向けと同様のネットワークセキュリティポリシーを適用できます。具体的には、Webコンテンツフィルタリング、脅威インテリジェンスフィルタリング、ネットワークファイルフィルタリングなどをエージェントトラフィックに適用できます。(Microsoft Learn)
基本的な流れは次のとおりです。
| ステップ | 実施場所 | 内容 |
|---|---|---|
| エージェント通信の転送を有効化 | Power Platform管理センター | 環境または環境グループ単位でGlobal Secure Access for Agentsを有効にする |
| セキュリティポリシーを作成 | Microsoft Entra管理センター | Webコンテンツフィルタリング、脅威インテリジェンス、ファイルポリシーなどを作成する |
| ベースラインプロファイルへリンク | Microsoft Entra管理センター | 作成したポリシーをベースラインプロファイルに紐づける |
| 監視と調整 | Global Secure Accessログなど | ブロック状況、想定外の許可、業務影響を確認する |
構成には、Global Secure Access Administratorロール、Power Platform Administratorロール、Dataverseが追加されたPower Platform環境が必要です。(Microsoft Learn)
今回の更新後に確認すべきポイント
ライセンス注記の削除を「ライセンス不要」と解釈しない
GitHub上の差分では、概念説明記事からライセンス注記のinclude行が削除されています。ただし、これは「ライセンス要件がなくなった」という意味ではありません。
Microsoft Entraのライセンスページでは、Microsoft EntraエージェントIDはMicrosoft Agent 365の一部であり、Agent ID機能を使うにはMicrosoft Agent 365またはMicrosoft 365 E7ライセンスが必要と説明されています。また、エージェント向けネットワークコントロールにはMicrosoft Entra Internet Accessが必要で、Microsoft Entra Suiteに含まれるか個別ライセンスとして提供されるとされています。(Microsoft Learn)
確認すべき実務項目は次の3つです。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| Agent ID関連の利用権 | Microsoft Entraライセンス情報、契約情報 | Microsoft Agent 365またはMicrosoft 365 E7の対象か |
| ネットワークコントロール | Microsoft Entra Internet Accessの契約状況 | Microsoft Entra Suiteまたは単体ライセンスで利用可能か |
| 本番利用可否 | 契約条件、プレビュー条項、管理センター表示 | ドキュメント表記だけでなく契約・テナント状態と一致するか |
特にコンプライアンス部門は、「ドキュメントから注記が消えた」という事実だけでは監査証跡として不十分です。契約ライセンス、テナントで有効化されているSKU、Microsoftからの正式なアナウンスを合わせて記録しておくと、後の説明責任を果たしやすくなります。
ベースラインプロファイルのみ対応という制限を確認する
GSA agentsの運用で重要なのは、セキュリティポリシーの適用単位です。Microsoft Learnでは、Copilot Studioエージェント向けのセキュリティポリシーはGlobal Secure Accessのベースラインプロファイルを使って構成され、テナントレベルで一貫した制御を適用すると説明されています。(Microsoft Learn)
構成手順記事では、Conditional Accessポリシーにリンクされたセキュリティプロファイルは、Copilot Studioエージェントでは現在サポートされていないとされています。(Microsoft Learn)
つまり、ユーザー向けアクセス制御と同じ感覚で「部門ごと」「アプリごと」「エージェントごと」に細かく切り替えられると考えると、設計ミスにつながります。
実務では、次のように整理しておくと安全です。
| 設計観点 | 推奨される確認 |
|---|---|
| 適用範囲 | テナント単位で影響するポリシーとして扱う |
| 例外設計 | 業務上必要な外部サイトやAPIを事前に洗い出す |
| 検証環境 | 本番環境へ適用する前に開発環境でブロック挙動を確認する |
| 変更承認 | セキュリティ部門だけでなく、Copilot Studio運用担当、業務部門、監査担当を含める |
既存のCopilot Studioカスタムコネクタを再保存する必要があるか確認する
Power Platform側のドキュメントでは、環境または環境グループでGlobal Secure Access for Agentsを有効にした後、既存のCopilot Studioカスタムコネクタについては編集して保存し、トラフィックがGlobal Secure Access経由でルーティングされるようにする必要があると説明されています。新しく作成されるカスタムコネクタは、この構成を自動的に使用します。(Microsoft Learn)
この点は運用で見落とされやすいポイントです。GSA側のポリシーを作成しても、既存コネクタの通信が想定どおり制御対象になっていなければ、監査時に「ポリシーはあるが実効性がない」状態になりかねません。
確認手順としては、次の流れが現実的です。
| 順番 | 作業 | 確認内容 |
|---|---|---|
| 1 | Copilot Studioエージェントの棚卸し | どの環境、どの環境グループでエージェントが動いているか |
| 2 | カスタムコネクタの一覧化 | 既存コネクタと新規作成予定コネクタを分ける |
| 3 | 既存コネクタの編集・保存 | GSA有効化後に再保存が必要な対象を処理する |
| 4 | テスト通信 | 許可先、ブロック先、ログ出力を確認する |
| 5 | 証跡化 | 作業日、対象コネクタ、確認結果を記録する |
サポート対象外の通信を把握する
GSA agentsを導入しても、Copilot Studioエージェントのすべての通信が同じように制御できるわけではありません。
Microsoft Learnの構成記事では、既知の制限として、ベースラインプロファイルのみの対応、サードパーティDLPなどのGlobal Secure Accessパートナーエコシステム統合が未対応であること、Copilot Studio Bing検索ネットワークトランザクション、DataverseやAzure SQLナレッジソースへのネットワーク要求、LLMへのネットワーク要求などがサポート対象外として挙げられています。(Microsoft Learn)
導入前に、少なくとも次の観点で影響を確認してください。
| 通信・機能 | 確認すべきこと |
|---|---|
| HTTPノード | 外部APIやWebサービスへのアクセスがポリシーに沿って制御されるか |
| カスタムコネクタ | 既存コネクタがGSA経由に切り替わっているか |
| MCP Server Connector | 対象のMCPサーバー通信が想定どおり評価されるか |
| Bing検索や公開Web知識 | サポート対象外の可能性を前提に設計する |
| Dataverse / Azure SQLナレッジソース | ネットワーク制御対象として期待しすぎない |
| LLM関連通信 | オーケストレーションや結果強化の通信は別管理として扱う |
セキュリティ設計では、「どの通信を守れるか」だけでなく、「どの通信は今回の制御対象外か」を明文化することが重要です。制御対象外の通信を把握していないと、監査・インシデント対応・データ保護設計で過信が生まれます。
ログ上のエージェント名とブロック時の挙動を確認する
Power Platform側のドキュメントでは、Global Secure Accessのトラフィックログに返されるエージェント名は、エージェントの一意のschema nameになると説明されています。また、ブロックされた場合のエクスペリエンスとして、HTTPアクションでは502 Bad Gateway、コネクタでは403 Forbiddenが表示される既知の問題が示されています。(Microsoft Learn)
これは運用上、非常に重要です。業務部門から「エージェントが動かない」と問い合わせが来たとき、表示エラーだけではGSAポリシーによるブロックか、外部サービス側の障害か、コネクタ設定ミスかを切り分けにくいからです。
あらかじめ次の情報を運用台帳に残しておくと、トラブル対応が速くなります。
| 記録する情報 | 目的 |
|---|---|
| エージェント表示名 | 業務部門との会話で使う名称 |
| エージェントのschema name | GSAログ上の識別に使う |
| 利用コネクタ | サポート対象か確認する |
| 想定アクセス先 | 許可・ブロック判定の根拠にする |
| ブロック時の想定エラー | 問い合わせ一次対応で混乱を防ぐ |
| 管理責任者 | 例外申請やポリシー変更時の承認者を明確にする |
security adminsが見るべき運用影響
security adminsは、今回のドキュメント更新を「表記変更」として流すのではなく、エージェント通信のセキュリティベースラインを見直すきっかけにするべきです。
特に確認すべきなのは、ユーザー通信向けに作ったWebフィルタリングポリシーを、そのままエージェント通信に適用してよいかです。人間のユーザーなら業務判断でアクセスを止められる場面でも、エージェントは自動実行されるため、ブロックや許可の影響が見えにくくなります。
実務では、次の3段階で設計すると失敗しにくくなります。
最小限のベースラインを作る
最初から細かいカテゴリを大量にブロックすると、業務エージェントの検証が進まなくなることがあります。初期段階では、明らかに不要なカテゴリや高リスク宛先を中心に、脅威インテリジェンスフィルタリングとWebコンテンツフィルタリングを組み合わせるのが現実的です。
例として、次のような分類から始めます。
| 分類 | 初期方針の例 |
|---|---|
| 既知の悪性サイト | 原則ブロック |
| NSFWカテゴリ | 原則ブロック |
| 違法ソフトウェア・危険なダウンロード | 原則ブロック |
| 業務SaaS | 利用実態を確認して許可 |
| 開発者向けリポジトリ | 業務要件に応じて許可・制限を分ける |
Microsoft Learnの構成例でも、Web repositories、Illegal software、NSFWサイトなどをブロックする例が示されています。(Microsoft Learn)
エージェントごとの業務目的を台帳化する
同じCopilot Studioエージェントでも、社内FAQ用、顧客対応用、経費処理用、外部SaaS連携用では、許可すべき通信先が異なります。
セキュリティ部門だけでポリシーを決めると、正当な業務通信をブロックしてしまう可能性があります。逆に業務部門任せにすると、外部APIやクラウドストレージへの通信が過剰に許可される可能性があります。
おすすめは、次の項目を1枚の台帳にまとめることです。
| 項目 | 記入例 |
|---|---|
| エージェント名 | 営業FAQエージェント |
| 所有部門 | 営業企画部 |
| 利用環境 | 本番Power Platform環境 |
| 利用コネクタ | SharePoint、Microsoft Graph、外部CRM API |
| 外部通信先 | api.example-crm.com |
| データ種別 | 顧客名、商談情報 |
| 必要な制御 | 顧客情報を含むファイル送信の制限 |
| ログ確認者 | セキュリティ運用チーム |
この台帳があると、GSAポリシー変更時の影響調査、監査対応、障害時の切り分けが格段に楽になります。
本番適用前にブロックテストを行う
Microsoft Learnでは、ポリシー変更を本番環境に適用する前に開発環境でテストすることが推奨されています。(Microsoft Learn)
テストでは、単に「通信できるか」だけでは不十分です。次の観点を確認してください。
| テスト項目 | 合格条件 |
|---|---|
| 許可先への通信 | エージェントが正常に応答し、ログに記録される |
| ブロック先への通信 | 想定どおり拒否され、ログで理由を確認できる |
| 既存コネクタ | GSA有効化後に再保存済みで、GSA経由になっている |
| 業務エラー表示 | 利用者・運用者が問い合わせ時に説明できる |
| ロールバック | ポリシー解除または緩和の手順が用意されている |
compliance teamsが見るべき監査・証跡ポイント
compliance teamsにとって、今回の更新は「AIエージェントのネットワーク活動を統制できる範囲」を整理する機会です。
AIエージェントは、人間のユーザーと違って、処理が自動化され、外部サービスへのアクセスが連続的に発生する可能性があります。そのため、監査では「誰がアクセスしたか」だけでなく、「どのエージェントが、どの目的で、どの外部リソースへ通信したか」を説明できる状態が必要です。
監査で残すべき証跡
| 証跡 | 目的 |
|---|---|
| 公式ドキュメント更新の確認日 | 変更管理の起点を明確にする |
| 影響を受ける社内エージェント一覧 | 管理対象を特定する |
| ライセンス確認結果 | 利用権と契約条件を説明する |
| GSAポリシー設定内容 | 制御方針を証明する |
| ベースラインプロファイルへのリンク状況 | 実際に適用されていることを示す |
| ログ確認手順 | 継続的な監視体制を示す |
| 例外承認記録 | ブロック解除や許可追加の妥当性を説明する |
特にライセンスについては、GitHubのコミットでライセンス注記が削除されたことと、Microsoft Entraのライセンスページで示されている要件を分けて扱う必要があります。ドキュメント上の注記削除だけを根拠に「ライセンス影響なし」と記録するのは避けるべきです。(GitHub)
社内規程に反映すべき表現
社内規程や設計書に反映する場合は、次のような書き方が実務的です。
| 避けたい表現 | 推奨表現 |
|---|---|
| GSA agentsはプレビュー終了のため本番利用可 | Microsoft Entra側ドキュメントではpreview表記が削除されたが、利用可否は関連ドキュメント、契約条件、テナント表示に基づいて判断する |
| ライセンス注記が削除されたため追加ライセンス不要 | ライセンス要件はMicrosoft Entraライセンス情報および契約内容で確認する |
| すべてのCopilot Studio通信をGSAで制御する | サポート対象のトラフィック、コネクタ、既知の制限を確認した範囲で制御する |
| エージェント通信はユーザー通信と同じ扱い | エージェント固有の自動実行、外部接続、ログ識別を考慮して管理する |
enterprise IT readersが移行準備でやるべきこと
enterprise IT readers、つまり大規模環境のIT企画・運用担当者は、今回の更新を受けて、すぐに全社展開するよりも「展開可能な状態か」を確認する移行準備に着手するのが現実的です。
おすすめの進め方は次のとおりです。
| フェーズ | 作業 | 成果物 |
|---|---|---|
| 調査 | 公式ドキュメント、GitHub差分、管理センター表示を確認 | 変更確認メモ |
| 棚卸し | Copilot Studioエージェント、環境、コネクタを一覧化 | エージェント台帳 |
| ライセンス確認 | Agent 365、Microsoft 365 E7、Microsoft Entra Internet Accessを確認 | ライセンス確認記録 |
| 検証 | 開発環境でGSA for Agentsを有効化 | テスト結果 |
| ポリシー設計 | Web、脅威、ファイル制御の初期ルールを作成 | セキュリティベースライン |
| 監視設計 | ログ確認、アラート、問い合わせ対応を整備 | 運用手順書 |
| 段階展開 | 低リスク環境から本番へ拡大 | 展開計画 |
この順序にすると、ドキュメント更新をきっかけに、エージェントのセキュリティ統制を無理なく本番運用へ近づけられます。
失敗しやすいポイントと回避策
preview表記だけで社内判断を変えてしまう
今回の更新では、Microsoft Entra側の記事タイトルからpreview表記が削除されています。しかし、関連するPower Platform側のドキュメントにはpreview表記やプレリリースに関する注意が残っています。(Microsoft Learn)
回避策は、変更管理の判断材料を1つのページに限定しないことです。Microsoft Entra側、Power Platform側、契約条件、管理センターの実表示をセットで確認してください。
ライセンス注記の削除をコスト削減と誤解する
GitHub差分でライセンスinclude注記が削除されていても、Microsoft EntraのライセンスページにはAgent IDやエージェント向けネットワークコントロールに関するライセンス要件が示されています。(GitHub)
回避策は、ライセンス判断をドキュメント差分ではなく、正式なライセンスページと契約情報に基づいて行うことです。
テナント単位の影響を見落とす
Copilot Studioエージェント向けのポリシーは、ベースラインプロファイルを使い、テナントレベルで適用されます。特定のエージェントだけに細かく分離して適用できると考えると、想定外の業務影響が出る可能性があります。(Microsoft Learn)
回避策は、低リスク環境から段階的に検証し、例外が必要な通信先を事前に洗い出すことです。
ログ名と業務名が一致せず、障害対応に時間がかかる
GSAログで返されるエージェント名は、業務部門が使う表示名ではなく一意のschema nameになる場合があります。(Microsoft Learn)
回避策は、エージェント表示名、schema name、所有部門、利用コネクタ、想定通信先を台帳化することです。
よくある疑問
今回の更新で設定手順は変わったのか
GitHub差分を見る限り、今回のコミットは主にタイトルから(preview)を削除し、ライセンス注記のinclude行を削除する内容です。構成手順全体が大きく変更されたわけではありません。(GitHub)
ただし、現行のMicrosoft Learn記事では、前提ロール、Power Platform管理センターでの有効化、Microsoft Entra管理センターでのポリシー作成、ベースラインプロファイルへのリンク、監視と保守が引き続き重要です。(Microsoft Learn)
既存環境では何を最初に確認すべきか
最初に確認すべきなのは、既存のCopilot Studioエージェントとカスタムコネクタです。Power Platform側ドキュメントでは、GSA for Agentsを有効にした後、既存のカスタムコネクタは編集して保存する必要があると説明されています。(Microsoft Learn)
その次に、GSAログで通信が取得されているか、ブロック対象が想定どおり拒否されるか、正当な業務通信が過剰に止まっていないかを確認します。
コンプライアンス上、今回の更新をどう記録すべきか
「Microsoft Entra側のGSA agents関連記事でpreview表記が削除された。ただし、Power Platform側の関連ドキュメントやライセンス要件、サポート対象範囲を確認したうえで利用判断する」と記録するのが安全です。
また、ライセンス注記の削除については、「注記の表示位置・扱いの変更」として記録し、ライセンス不要とは書かないようにします。
本番展開の判断基準は何か
本番展開前には、少なくとも次の条件を満たしているか確認してください。
| 判断基準 | 確認内容 |
|---|---|
| ライセンス | Agent 365、Microsoft 365 E7、Microsoft Entra Internet Accessの要件を確認済み |
| サポート範囲 | 対象コネクタ、対象外通信、既知の制限を確認済み |
| 運用設計 | ログ監視、問い合わせ対応、例外承認フローがある |
| 検証 | 開発環境で許可・ブロック・ログ出力をテスト済み |
| 変更管理 | セキュリティ、業務部門、IT運用、コンプライアンスの承認を取得済み |
まず取るべき次のアクション
今回のMicrosoft Entraドキュメント更新は、GSA agentsに関する表記の整理として重要です。ただし、運用上は「previewが消えたかどうか」だけを見るのではなく、ライセンス、関連ドキュメント、サポート対象、既存コネクタ、ログ監視まで含めて確認する必要があります。
まずは、次の順番で対応してください。
- GitHub差分とMicrosoft Learnの現行ページを確認する
- 社内資料に残っている「preview」表記を洗い出す
- Power Platform側ドキュメントのpreview表記や注意事項も確認する
- Agent 365、Microsoft 365 E7、Microsoft Entra Internet Accessのライセンス要件を確認する
- Copilot Studioエージェントと既存カスタムコネクタを棚卸しする
- 開発環境でGSA for Agentsのポリシー適用とログ出力を検証する
- 本番展開前に、例外申請・ログ監視・障害対応の運用手順を整える
Microsoft EntraのGSA agentsは、AIエージェントの外部通信を可視化・制御するうえで重要な領域です。今回の更新を、単なるドキュメント表記の変更として終わらせず、エンタープライズ環境におけるAIエージェント統制を見直すきっかけにするとよいでしょう。
コメント