2026年6月5日に公開・更新された「Generally Available: Private Connectivity for Azure AI Search and Foundry Knowledge Bases」は、Microsoft Edgeそのものの画面やメニューが変わる更新ではありません。重要なのは、EdgeやCopilot Chat、社内ポータルから利用するAI検索・ナレッジベースの裏側で、Azure AI SearchとMicrosoft Foundry間の通信をより閉域寄りに設計しやすくなった点です。
結論から言うと、社内データを使ったCopilot／AI検索／RAG／エージェントをMicrosoft Edge経由で利用している組織は、Azure AI Search、Foundry Knowledge Bases、Private Link、Network Security Perimeter、EdgeのCopilot管理ポリシーをセットで見直すべき更新です。一方、Edgeを通常のWebブラウザーとして使っているだけの環境では、すぐにユーザー操作が変わる可能性は高くありません。
Microsoft EdgeのAI/Copilot更新で何が変わるのか
今回の公式更新では、Azure AI SearchとFoundry Knowledge Basesが、検索リソースとFoundryサービス間のプライベートなエンドツーエンド接続をサポートするようになったとされています。対象になる通信は、データ取り込み、AIによるエンリッチメント、検索・取得、エージェント連携などです。接続方式としては、Shared Private LinkまたはNetwork Security Perimeterを使う構成が示されています。(マイクロソフト Azure)
ここで注意したいのは、「Microsoft Edgeの新機能が追加された」というより、Edgeから利用されるAI体験のバックエンドを安全に構成しやすくなったという位置づけです。
たとえば、次のような構成では影響があります。
| 利用シーン | 今回の更新との関係 |
|---|---|
| EdgeのサイドバーからCopilot Chatを利用して社内情報を調べる | Edgeは入口。裏側の社内検索やAIエージェントがAzure AI Search／Foundryを使う場合に関係する |
| 社内ポータルをEdgeで開き、AI検索やチャットボットを使う | AI検索基盤がAzure AI SearchとFoundryで構成されていればネットワーク設計の見直し対象 |
| Microsoft 365やTeamsに公開したカスタムエージェントをEdgeから利用する | エージェントがFoundry Knowledge BasesやAzure AI Searchを参照する場合に関係する |
| Edgeを単なるブラウザーとして使い、Azure AI SearchやFoundryを使っていない | 直接の設定変更は基本的に不要 |
Azure Updatesの「Launched」は、Azureの更新ステータス上、一般提供済みで本番利用を想定した状態を意味します。(マイクロソフト Azure) そのため、プレビュー検証ではなく、本番環境のAI検索基盤として採用を検討しやすくなった点が大きな変化です。
今回の更新を一言でいうと「AI検索の通信経路を閉じやすくなった」
従来、Azure AI Search、Azure OpenAI、Foundry、Storage、Cosmos DB、SQL Databaseなどを組み合わせてRAGやエージェント検索を構築する場合、どの通信がパブリックエンドポイントを経由するのか、どこにPrivate Linkが必要なのか、どのリソースにRBACを付与するのかを細かく整理する必要がありました。
今回のGenerally Availableにより、Azure AI SearchとFoundry Knowledge Basesの間でも、Shared Private LinkまたはNetwork Security Perimeterを使って、より一貫したプライベート接続設計を取りやすくなります。
Azure AI SearchのShared Private Linkは、Searchサービスから仮想ネットワーク内のAzureリソースへ、パブリックエンドポイントではなく仮想ネットワークIPアドレスを使って接続するための仕組みです。Microsoft Learnでは、Foundryリソースへの接続もShared Private Linkの対象として説明されています。(Microsoft Learn)
管理者がまず確認すべき影響範囲
最初にやるべきことは、Edgeの設定画面を見ることではありません。自社のAI検索・Copilot活用が、Azure AI SearchとFoundryに依存しているかを確認することです。
影響が大きい組織
次のいずれかに当てはまる場合は、今回の更新を優先的に確認してください。
| 確認項目 | 該当する場合の対応 |
|---|---|
| Azure AI Searchを社内検索、RAG、チャットボットで使っている | Searchリソースのネットワーク設定、Private Endpoint、Shared Private Linkを確認する |
| Microsoft FoundryでKnowledge Basesやエージェントを使っている | Foundry側のPrivate Link、Agent Service、Knowledge Base接続を確認する |
| EdgeからCopilot Chatや社内AIポータルを業務利用している | Edge側のCopilotポリシーとバックエンドのデータ経路を合わせて確認する |
| 公開ネットワークアクセスを無効化したい、またはすでに無効化している | DNS、RBAC、NSPの許可ルール、Private Endpointの承認状態を重点的に確認する |
| 金融、医療、公共、製造などでデータ持ち出し制御が厳しい | Network Security Perimeterのログと強制モードへの移行計画を作る |
影響が限定的な組織
次のような環境では、今回の更新による即時対応は限定的です。
| 環境 | 理由 |
|---|---|
| Edgeを通常のブラウザーとしてのみ利用 | Azure AI Search／Foundryの通信経路に関係しない |
| Copilot Chatを一般的なWeb検索や文章作成だけに使っている | 社内ナレッジベース連携がなければ影響は小さい |
| Azure AI Searchを使っているが、FoundryやKnowledge Basesと連携していない | 今回の主対象からは外れる可能性がある |
| 検証環境のみでAI検索を使っている | 本番化前の設計見直しとして確認すればよい |
ただし、今後EdgeのCopilot Chatや社内AIポータルを本格展開する予定があるなら、最初から閉域接続を前提に設計した方が後戻りを減らせます。
Edge管理者が見るべきポイント
Microsoft 365 Copilot Chatは、Microsoft Edgeのサイドバーから利用できます。ユーザーがMicrosoft EntraアカウントでEdgeにサインインしている場合、Copilot Chatにはエンタープライズデータ保護が適用されます。(Microsoft Learn)
そのため、Edge管理者は「Copilotアイコンを表示するか」だけでなく、誰が、どのプロファイルで、どのデータをAIに渡せるのかを確認する必要があります。
Edge側で確認したい設定
| 確認項目 | 実務上の判断基準 |
|---|---|
| Entra IDでのEdgeサインイン | 業務データを扱うユーザーは個人アカウントではなく職場または学校アカウントで利用させる |
| Copilot Chatの表示制御 | 利用部門、検証部門、禁止部門でポリシーを分ける |
| ページコンテキスト共有 | 社内文書、PDF、業務Webアプリの内容がCopilotに渡る可能性を把握する |
| DLP連携 | Microsoft Purview、Intune MAM、Defender for Cloud Appsなどの制御と整合させる |
| ブラウザープロファイル分離 | 個人利用と業務利用が混在しないようEdge for Businessの運用を確認する |
Microsoftのドキュメントでは、Copilot Chat in Edgeでブラウジングコンテキストを使う場合、ユーザーのプロンプトや同意に応じて、URL、ページタイトル、ユーザーの問い合わせ、会話履歴、ページ情報などが応答生成に使われることがあります。(Microsoft Learn) 社内AI検索を展開する場合は、この挙動を利用者教育とポリシーに落とし込むことが重要です。
Copilotアイコンやサイドバーの管理も見直す
Microsoft Edge for Businessでは、Microsoft365CopilotChatIconEnabled ポリシーにより、Microsoft 365 Copilot Chatアイコンをツールバーに表示するかどうかを制御できます。このポリシーはWindowsとmacOSのEdgeバージョン139以降でサポートされています。(Microsoft Learn)
また、Edgeのポリシー一覧には、Microsoft EdgeでのCopilotによる閲覧の可用性を制御する AllowBrowsingWithCopilot、Copilotの新しいタブページを制御する CopilotNewTabPageEnabled、Copilotアドレスバー提案を制御する CopilotAddressBarSuggestionsEnabled なども掲載されています。(Microsoft Learn)
実務では、次のように段階的に分けると運用しやすくなります。
| 展開段階 | Edge側の考え方 | Azure側の考え方 |
|---|---|---|
| 検証 | 一部ユーザーにCopilot Chatを表示 | Search／Foundryの接続ログを確認 |
| 限定展開 | 対象部門だけCopilotを許可 | Shared Private LinkまたはNSPを本番相当で構成 |
| 全社展開 | EdgeポリシーをIntuneやグループポリシーで標準化 | 公開ネットワークアクセス、RBAC、監査ログを継続監視 |
| 規制部門向け展開 | サイドバー、ページコンテキスト、DLPを厳格化 | Private Endpoint、NSP強制モード、ログ保管を必須化 |
サイドバー自体を制御する HubsSidebarEnabled もありますが、Microsoft Edgeバージョン141以降では、Copilotのツールバー表示制御は Microsoft365CopilotChatIconEnabled が唯一の手段と説明されています。(Microsoft Learn) 古いポリシー設計のまま運用している場合は、Edgeのバージョン更新と合わせて棚卸ししてください。
Azure側で理解すべき2つの接続方式
今回の更新で特に重要なのが、Shared Private LinkとNetwork Security Perimeterです。名前が似ていても役割は異なります。
| 方式 | 向いているケース | 注意点 |
|---|---|---|
| Shared Private Link | Azure AI Searchから特定のAzureリソースやFoundryリソースへプライベートに接続したい | 接続先リソース側でPrivate Endpoint接続の承認が必要。利用量に応じた課金対象になる |
| Network Security Perimeter | 複数のPaaSリソースを論理的な境界でまとめ、流出防止・ログ取得・許可ルール管理をしたい | 学習モードで通信を確認してから強制モードに移行する必要がある |
Shared Private Linkを選ぶ場面
Shared Private Linkは、Searchサービスから接続先リソースへプライベートアウトバウンド接続を作るための仕組みです。Microsoft Learnでは、Azure AI Searchがパブリックエンドポイントではなく仮想ネットワークIPアドレスへ接続すると説明されています。(Microsoft Learn)
次のような場合に向いています。
- Azure AI Searchのインデクサーが、プライベート化されたStorage、Cosmos DB、SQL Databaseなどへ接続する
- AIエンリッチメントやベクトル化でFoundryリソースへ接続する
- Knowledge Basesやエージェント検索で、SearchとFoundryの通信を閉じたい
- 接続先が明確で、個別にPrivate Linkを承認・管理できる
注意点は、Shared Private Linkを作っただけでは完了しないことです。作成後は接続が保留状態になり、接続先リソースの所有者による承認が必要です。また、Foundryリソーススキルなどでは、マネージドIDを使うキーレス構成が前提になるケースがあります。(Microsoft Learn)
Network Security Perimeterを選ぶ場面
Network Security Perimeterは、仮想ネットワーク外にあるPaaSリソースを論理的な境界で囲み、ネットワークアクセスを制御する仕組みです。Azure AI Search、Azure Storage、Microsoft Foundry ModelsのAzure OpenAIなどのリソースに対して、アクセスログ取得、データ流出防止、インバウンド／アウトバウンド制御を行えます。(Microsoft Learn)
次のような場合に向いています。
- Search、Foundry、Storage、Key Vaultなど複数のPaaSリソースを一括で境界管理したい
- どの通信が許可・拒否されるかをログで確認しながら移行したい
- 将来的にAI検索基盤を複数部門へ広げる予定がある
- パブリックネットワークアクセスの有効・無効だけでは統制が足りない
NSPでは、SearchサービスとFoundryリソースを同じ境界に入れる、または境界間通信を許可することで、スキル、ベクタライザー、エージェント検索などのFoundry呼び出しをプライベートチャネルにできます。(Microsoft Learn)
特に重要なのは、最初から強制モードにしないことです。学習モードで実際の通信を確認し、必要なアクセスルールを洗い出してから強制モードへ切り替えるのが安全です。NSPの強制モードでは、明示的に許可されていない通信が拒否されます。(Microsoft Learn)
管理者・開発者向けチェックリスト
実際の対応では、ブラウザー、ID、ネットワーク、アプリ、ログを分けて確認すると漏れを減らせます。
| 分類 | 確認すること | 失敗しやすいポイント |
|---|---|---|
| Edge | Entra IDプロファイルでサインインしているか | 個人プロファイルでCopilotを使い、業務データの扱いが曖昧になる |
| Edgeポリシー | Copilot表示、サイドバー、ページコンテキスト、DLPの制御 | 古いサイドバーポリシーだけでCopilotを制御したつもりになる |
| Azure AI Search | Public network access、Private Endpoint、Shared Private Link、RBAC | Searchの受信経路と送信経路を混同する |
| Foundry | Private Link、Knowledge Bases、Agent Service、マネージドID | Foundry側のネットワーク分離だけ設定し、Search側の許可を忘れる |
| DNS | privatelink 系の名前解決が想定どおりか | VMや開発端末から見るとパブリックIPへ解決される |
| 認証 | APIキーではなくマネージドIDとRBACを使えるか | NSP内でもAPIキー利用時に明示ルールが必要になる場合がある |
| ログ | NSPAccessLogs、Searchの実行履歴、Foundry側のエラーを確認 | 接続失敗をアプリの不具合として扱い、ネットワーク拒否を見落とす |
Microsoft Learnでは、SearchサービスがマネージドIDとMicrosoft Entraベースのロール割り当てで認証する場合、同じNSP内のリソース間通信はネットワークレベルで暗黙的に許可されます。一方、APIキーで認証する場合は、同じ境界内でも明示的なインバウンド／アウトバウンドルールが必要になると説明されています。(Microsoft Learn)
移行・展開の進め方
既存のAI検索基盤を止めずに移行するには、いきなりPublic network accessを無効化しないことが重要です。次の順序で進めると、障害の切り分けがしやすくなります。
| 手順 | 作業内容 | 成功条件 |
|---|---|---|
| 現状把握 | Edge、社内AIアプリ、Azure AI Search、Foundry、データソースの通信図を作る | どの通信がユーザー操作、検索、エンリッチメント、エージェント呼び出しなのか説明できる |
| ID整理 | Search、Foundry、データソースに必要なマネージドIDとRBACを設定 | APIキー依存を減らし、権限が最小化されている |
| 検証環境構築 | Shared Private LinkまたはNSPを検証環境で構成 | インデクサー、検索、エージェント呼び出しが成功する |
| ログ確認 | NSP学習モードやSearch実行履歴で通信を確認 | 想定外のパブリック経路や拒否予定通信を把握できる |
| Edgeポリシー適用 | Copilot表示、サイドバー、DLP、プロファイル利用を管理 | 対象ユーザーだけが業務プロファイルで利用できる |
| 段階展開 | 一部部門から本番展開 | 問い合わせ、403、名前解決エラー、検索失敗を監視できる |
| 強制化 | NSP強制モードやPublic network access無効化を実施 | 業務影響なくAI検索・ナレッジベースが動作する |
開発者は、ローカルPCからの接続テストと、Azure内のVMやアプリからの接続テストを分けてください。Private Endpointを使う構成では、同じFQDNでもDNS解決によって接続先が変わります。ローカルでは成功するのにAzure上では失敗する、またはその逆が起きるためです。
よくあるトラブルと対処法
Copilotや社内AI検索からナレッジベースを参照できない
まず確認するのは、EdgeではなくAzure側です。Foundry Knowledge BasesやAzure AI Searchに接続できない場合、Private Endpointの承認状態、DNS解決、マネージドIDのRBAC、NSPの許可ルールを確認してください。
特に、Public network accessを無効化したあとに失敗する場合は、次の原因が多くなります。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| 403エラー | RBAC不足、NSPルール不足、APIキー利用時の明示ルール不足 | マネージドIDのロールとNSPログを確認 |
| タイムアウト | Private DNSの誤り、Private Endpoint未承認 | VNet内から名前解決と接続先IPを確認 |
| Foundry側でKnowledge Baseが読み込めない | Searchリソースへの接続不可 | FoundryプロジェクトのID、Searchのネットワーク設定、接続状態を確認 |
| インデクサーだけ失敗する | Searchからデータソースへのアウトバウンド経路不足 | Shared Private LinkまたはNSPアウトバウンドルールを確認 |
| Edgeでは動くが別アプリでは失敗 | ブラウザーではなくアプリの実行場所・DNS・IDが異なる | クライアントごとに通信経路を分けて調査 |
Shared Private LinkとPrivate Endpointを混同している
Private Endpointは「クライアントからSearchへ入る」経路で使うことが多く、Shared Private Linkは「Searchから別のAzureリソースへ出ていく」経路で使います。Microsoft Learnでも、Searchサービスへのプライベートなインバウンド接続と、インデクサーやKnowledge Baseのためのアウトバウンド接続は別のシナリオとして説明されています。(Microsoft Learn)
この違いを理解しないまま設定すると、Searchの画面上はPrivate Endpointがあるのに、インデクサーやエージェント検索だけ失敗するという状態になりがちです。
Azure OpenAIとFoundryのサポート状態を同じものとして扱う
NSPのFoundry関連サポートでは、Microsoft.CognitiveServicesリソースの種類によって一般提供とプレビューが分かれる点にも注意が必要です。Microsoft Learnでは、AIServices 種類のMicrosoft Foundryに対するNSPサポートは一般提供、OpenAI 種類のAzure OpenAI Serviceに対するNSPサポートはパブリックプレビューと説明されています。(Microsoft Learn)
本番設計では、「FoundryがGAだからAzure OpenAI側もすべてGA」と短絡しないようにしてください。利用しているリソースの種類、リージョン、SKU、接続方式を個別に確認する必要があります。
Edge利用者に周知すべきこと
利用者向けの説明では、Azureのネットワーク用語をそのまま伝える必要はありません。重要なのは、Copilotや社内AI検索に入力してよい情報、入力してはいけない情報、業務プロファイルの使い分けです。
周知文は、次のように具体化すると伝わりやすくなります。
| 周知する内容 | 例 |
|---|---|
| 業務では職場アカウントのEdgeプロファイルを使う | 個人アカウントのEdgeプロファイルでは社内AI検索を使わない |
| 機密情報の扱い | 顧客情報、未公開契約、個人情報は社内ルールに従って入力する |
| ページ要約の注意 | 社外秘ページやPDFを要約する前に、DLPや組織ルールの対象であることを理解する |
| エラー時の報告先 | 「Copilotが壊れた」ではなく、表示されたエラー、利用ページ、時刻を報告する |
EdgeのCopilot Chatでは、ユーザーの許可やプロンプトに応じて閲覧コンテキストが利用される場合があります。(Microsoft Learn) そのため、技術的な閉域接続だけでなく、利用者の入力ルールもセットで整備することが大切です。
今回の更新で取るべき次のアクション
今回のPrivate Connectivity一般提供は、Microsoft EdgeのUI更新ではなく、EdgeやCopilotから利用するAI検索基盤を安全に運用するための重要なバックエンド更新です。
まず、自社がAzure AI Search、Microsoft Foundry、Foundry Knowledge Bases、社内AIエージェントを使っているか確認してください。該当する場合は、次の順序で進めるのが現実的です。
- Edgeから利用されているAI機能とバックエンド構成を棚卸しする
- Azure AI SearchとFoundry間の通信経路を図にする
- Shared Private LinkとNetwork Security Perimeterのどちらを使うか決める
- マネージドID、RBAC、DNS、Private Endpoint、NSPログを検証する
- EdgeのCopilot関連ポリシーとDLP設定を合わせて見直す
- 学習モードや限定展開で問題を潰してから本番展開する
EdgeをAI活用の入口にする企業ほど、ブラウザー設定だけでは安全性を担保できません。Edge、Copilot、Azure AI Search、Foundry、ネットワーク、ID管理を一つの流れとして設計することが、今回の更新を実務で活かすポイントです。
コメント