Microsoft 365 Copilotの「Domain exclusion for web grounding」は、Copilotが回答を作る際に参照するWeb情報のうち、管理者が指定した一部のサイトを除外できるようにする更新です。結論から言うと、Web検索を全面停止するのではなく、特定ドメインだけをWeb groundingの参照元から外したい組織向けの管理機能と考えると分かりやすいです。Microsoft 365 Roadmap ID 503144では、対象はMicrosoft 365 CopilotとCopilot Chat、GA予定は2026年6月、状態はIn development、対象クラウドはWorldwide、対象プラットフォームはDesktopとWebとされています。(Microsoft)
この更新で重要なのは、「CopilotにWebを使わせるか、使わせないか」の二択だけでなく、「Web groundingは使うが、このサイトは使わせない」という中間の制御が可能になる点です。ただし、現時点の公式ロードマップでは、除外できるサイト数、具体的な設定画面、ワイルドカード指定の可否、既存ポリシーとの優先順位などの詳細は公開されていません。Microsoft 365 Roadmap自体も、商用機能の予定日と説明は推定であり変更される可能性があると明記しています。(Microsoft)
Microsoft 365 CopilotのDomain exclusion for web groundingとは
Domain exclusion for web groundingは、Microsoft 365 CopilotやMicrosoft 365 Copilot ChatがWeb groundingを行う際に、管理者が指定した限定的なサイトを参照対象から除外できるようにする機能です。
Web groundingとは、Copilotがユーザーの質問に答えるとき、Microsoft 365内のデータや大規模言語モデルの知識だけでなく、Bing検索サービスを通じてWeb上の最新情報を補助的に使う仕組みです。Microsoftは、Web検索が有効な場合、CopilotがユーザーのプロンプトからWeb情報が役立つ語句を抽出し、Bing検索サービスに検索クエリを送信すると説明しています。(Microsoft Learn)
今回の更新は、このWeb groundingの参照元に対して「除外リスト」を持たせるものです。たとえば、次のような場面で使うことが想定されます。
- 信頼性に課題がある公開サイトをCopilotの回答根拠に使わせたくない
- 自社情報を転載している外部サイトや古いドキュメントミラーを参照させたくない
- 競合サイトや比較サイトを業務回答の根拠に含めたくない
- 社内のAI利用ポリシー上、特定ドメインを生成AIの参照対象から外したい
従来の管理では、Web検索をオンにするかオフにするかの判断が中心でした。今回の機能により、Web groundingの有用性を残しながら、問題になりやすい参照元だけを抑制しやすくなります。
何が変わるのか
今回の変更点は、管理者によるWeb grounding制御がより細かくなることです。
| 項目 | これまでの主な制御 | Domain exclusion for web grounding追加後の考え方 |
|---|---|---|
| Web grounding全体 | Allow web search in Copilotポリシーで有効・無効を管理 | Web groundingを有効にしたまま、一部サイトを除外できる |
| 対象サービス | Microsoft 365 Copilot、Copilot ChatのWeb検索制御 | Microsoft 365 CopilotとCopilot ChatのWeb groundingで除外対象を指定 |
| 制御単位 | テナント、ユーザー、グループ単位のWeb検索可否 | サイト単位の除外が追加される見込み |
| 主な目的 | Web検索の利用可否を決める | Web検索の参照元品質やポリシー適合性を高める |
| 注意点 | Web検索を無効にすると最新情報を使いにくくなる | 除外しすぎると回答品質や引用の幅が狭くなる |
Microsoft Learnでは、Allow web search in Copilotポリシーにより、管理者がMicrosoft 365 CopilotとCopilot ChatのWeb検索をユーザーまたはグループ単位でオン・オフできると説明されています。未構成の場合、一般的な商用環境ではWeb検索は既定で利用可能です。(Microsoft Learn)
今回のドメイン除外は、この「Web検索を使うかどうか」の制御に加えて、「どのWebサイトを使わせないか」を調整する方向の更新です。
影響範囲：対象になるユーザー、サービス、環境
公式ロードマップの情報を整理すると、現時点での影響範囲は次のとおりです。
| 確認項目 | 内容 |
|---|---|
| Roadmap ID | 503144 |
| 機能名 | Microsoft Copilot (Microsoft 365): Domain exclusion for web grounding |
| 対象サービス | Microsoft 365 Copilot、Microsoft 365 Copilot Chat |
| 目的 | 管理者が、Web groundingから除外する限定的なサイトを指定できるようにする |
| リリース段階 | General Availability |
| GA予定 | 2026年6月 |
| 状態 | In development |
| 対象クラウド | Worldwide (Standard Multi-Tenant) |
| 対象プラットフォーム | Desktop、Web |
| 公式情報の更新時点 | API上のmodifiedは2026-05-26 23:00:59 UTC。日本時間では2026-05-27に相当 |
Roadmap上ではGCC、GCC High、DoDはこの機能の対象クラウドとして表示されていません。そのため、政府機関向けクラウドで同じタイミング・同じ仕様で利用できると断定しない方が安全です。政府機関向け環境ではWeb検索の既定値や有効化手順が商用環境と異なる場合があり、Microsoft LearnでもGCCとDoDではWeb検索が利用可能だが既定でオフと説明されています。(Microsoft Learn)
Web groundingとWeb検索の仕組みを整理
Domain exclusion for web groundingを正しく評価するには、CopilotがWebをどのように使うのかを理解しておく必要があります。
Microsoft 365 CopilotやCopilot ChatでWeb検索が有効な場合、Copilotはユーザーのプロンプト全体をそのままBingへ送るのではなく、Web検索が役立つと判断した語句から検索クエリを生成します。Microsoftは、生成された検索クエリには、ユーザーまたはテナントを識別する情報、ファイル全体、Edgeで要約したWebページやPDF全体は含まれないと説明しています。(Microsoft Learn)
一方で、Web検索クエリはMicrosoft 365内部のプロンプトや応答とは扱いが異なります。Microsoftの説明では、Bing検索サービスはMicrosoft 365とは別に動作し、生成されたWeb検索クエリにはDPA、HIPAA、EU Data Boundaryが適用されないとされています。(Microsoft Learn)
つまり、今回のドメイン除外は「Web検索を使う前提で、参照元サイトを制御する機能」です。機密情報の入力そのものを防ぐ機能でも、SharePointやOneDriveの権限設計を置き換える機能でもありません。
管理者がまず確認すべき設定
この機能が展開されたとき、管理者が最初に確認すべきなのは「自社でWeb groundingをどのように許可しているか」です。
Allow web search in Copilotポリシー
現行の主要な管理ポイントは、Allow web search in Copilotポリシーです。このポリシーはCloud Policy service for Microsoft 365で利用でき、Microsoft 365管理センターのCopilot Control Systemページからも設定できると説明されています。(Microsoft Learn)
確認すべきポイントは次の3つです。
| 確認項目 | 判断のポイント |
|---|---|
| Web検索を全社で許可しているか | 全社許可なら、除外ドメインの設計が重要になる |
| 部門やユーザーグループごとに許可しているか | 法務、経営企画、研究開発などリスクが高い部門を分けて考える |
| Web検索を無効にしているか | Web検索を無効化している場合、ドメイン除外の効果は限定的になる可能性が高い |
Web検索をオフにすると、Copilot ChatはBing検索サービスへWebクエリを送信せず、基盤となるLLMだけで応答を生成するとMicrosoft Learnに記載されています。(Microsoft Learn) そのため、すでにWeb検索を全面的に無効化している組織では、今回のドメイン除外よりも「Web検索を一部部門に解禁するか」の方が大きな論点になります。
Microsoft 365管理センターとCopilot Control System
Roadmapの説明には「#copilotcontrolsystem」というタグが含まれています。既存のMicrosoft Learnでは、Copilot Control Systemページの設定セクションからWeb検索関連ポリシーを管理できると説明されています。(Microsoft Learn)
ただし、Domain exclusion for web groundingの具体的な設定場所やUI名は、現時点のRoadmap情報だけでは確認できません。展開前に、Microsoft 365管理センター、Message center、Roadmap、Microsoft Learnの更新をセットで確認する運用にしておくのが現実的です。
除外ドメインを決める判断基準
Domain exclusion for web groundingで最も難しいのは、「どのサイトを除外するか」です。除外リストを作るだけなら簡単ですが、過剰に除外するとCopilotの回答品質が下がります。逆に少なすぎると、導入目的を果たせません。
おすすめは、次の優先順位で検討する方法です。
| 優先度 | 除外候補 | 判断基準 | 例 |
|---|---|---|---|
| 高 | 明らかに信頼できない情報源 | 誤情報、古い情報、出典不明の転載が多い | 非公式のミラーサイト、スクレイピングサイト |
| 高 | 自社情報の無断転載・古い転載元 | 現行の公式情報と矛盾する内容が検索に出やすい | 旧製品資料の転載、削除済み資料のキャッシュ系サイト |
| 中 | 業務上参照させたくない外部サイト | 社内ポリシーや契約上、AI回答の根拠にしたくない | 特定の競合比較サイト、掲示板型サイト |
| 中 | 品質にばらつきが大きいUGCサイト | 内容が有用な場合もあるが検証が必要 | Q&Aサイト、フォーラム、まとめサイト |
| 低 | 公式ドキュメントや公的機関サイト | 基本的には除外しない | Microsoft Learn、官公庁、標準化団体、主要ベンダー公式 |
除外リストは「嫌いなサイト一覧」ではなく、「Copilotの回答根拠として使うと業務上のリスクが高いサイト一覧」として管理するのがポイントです。
たとえば、IT部門であれば、古いPowerShellコマンドを掲載したまま更新されていないブログを除外したくなるかもしれません。ただし、そのブログにしか実務上の回避策が載っていないケースもあります。まずは問い合わせ履歴、Copilotの利用ログ、ヘルプデスクで発生した誤回答事例を見て、実害のあるサイトから絞り込むべきです。
除外しすぎによる失敗に注意
Domain exclusion for web groundingは便利な制御ですが、万能ではありません。特に注意したいのは、除外リストを「安全そうに見えるから」という理由で広げすぎることです。
除外しすぎると、次のような問題が起きます。
- Copilotが最新情報を取得しにくくなる
- 回答の引用元が偏る
- ユーザーが手動でWeb検索し直すようになり、かえって統制が弱くなる
- 開発者や運用担当者が必要な技術情報にたどり着きにくくなる
- 部門ごとに「使えないCopilot」という評価になり、定着が進まない
特にIT、法務、営業企画、調達、研究開発のように外部情報の鮮度が重要な部門では、Web groundingの価値を残す設計が必要です。
実務では、最初から大量のドメインを登録するよりも、次のような段階展開が向いています。
| フェーズ | やること | 成功基準 |
|---|---|---|
| 準備 | 除外候補ドメインを10〜20件程度に絞る | 除外理由を説明できる |
| 検証 | 代表的な業務プロンプトで回答を比較する | 回答品質が大きく落ちない |
| パイロット | 一部部門で適用し、問い合わせや不満を収集する | 誤参照が減り、業務影響が許容範囲 |
| 本番 | 全社または対象グループへ展開する | 除外リストの変更手順と承認者が決まっている |
| 運用 | 月次または四半期で見直す | 古い除外、過剰な除外を削除できる |
DLPやSharePoint権限管理との違い
Domain exclusion for web groundingは、Copilotガバナンスの一部です。ただし、DLP、SharePoint権限、SharePoint Advanced Management、Purviewの監査とは役割が異なります。
| 仕組み | 主な役割 | Domain exclusionとの違い |
|---|---|---|
| Domain exclusion for web grounding | Web groundingで使う外部サイトを除外する | 外部Webの参照元制御 |
| Allow web search in Copilot | Web検索そのものを許可・禁止する | Web grounding全体のオン・オフ |
| Microsoft Purview DLP for Copilot | 機密情報を含むプロンプトやラベル付きファイルの処理を制御する | 入力内容・社内コンテンツ側の保護 |
| SharePoint/OneDrive権限 | ユーザーがアクセスできる社内データを制御する | Copilot以前の基本的なアクセス制御 |
| SharePoint Advanced Management RCD | 機密性の高いSharePointサイトをCopilot discoveryから除外する | 社内サイトの検出・参照抑制 |
| Purview監査・DSPM | Copilot利用状況、検索語、リスクを確認する | 運用後の可視化と検証 |
Microsoft 365 Copilotは、ユーザーが少なくとも表示権限を持つ組織データだけを表示し、SharePointなどMicrosoft 365サービスの権限モデルを利用すると説明されています。(Microsoft Learn) そのため、社内情報の過剰共有をDomain exclusionで解決しようとするのは誤りです。
社内の機密サイトや過剰共有されたSharePointサイトが問題なら、まず権限、サイト所有者、共有リンク、感度ラベルを見直す必要があります。Microsoftは、Copilot導入の安全な基盤として、PurviewやSharePoint Advanced Managementを使って、過剰共有、所有者不在、非アクティブ、機密データを含むサイトやファイルを特定することを推奨しています。(Microsoft Learn)
機密情報対策ではPurview DLPも確認する
Domain exclusionは「このドメインを回答根拠に使わせない」という制御です。一方、ユーザーがプロンプトに機密情報を入力してしまうリスクには、Microsoft Purview DLP for Copilotの方が直接的です。
Microsoft Learnでは、プロンプトにクレジットカード番号、パスポート番号、社会保障番号、カスタムの機密情報タイプなどが含まれる場合、DLPポリシーによって外部Web検索をgrounding sourceとして使うことをブロックできると説明されています。(Microsoft Learn)
また、感度ラベル付きのファイルやメールについて、Copilotの応答要約で処理されないようにするDLP制御も一般提供されています。対象はMicrosoft 365 Copilot、Copilot Chat、Word、Excel、PowerPoint内のCopilotなどで、SharePoint OnlineとOneDrive for Businessに保存されたファイルが対象に含まれます。(Microsoft Learn)
つまり、実務上は次のように分担して考えるとよいです。
- Web参照元の品質を制御したい：Domain exclusion for web grounding
- Web検索自体を止めたい：Allow web search in Copilot
- 機密情報を含むプロンプトからWeb検索させたくない：Purview DLP for Copilot
- 社内ファイルをCopilot要約に使わせたくない：感度ラベルとDLP for Copilot
- 社内サイトの過剰共有を直したい：SharePoint/OneDrive権限、SAM、Purview DSPM
管理者向けの展開チェックリスト
GA前後に管理者が確認すべき項目を、実務向けに整理します。
| チェック項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 既存のWeb検索ポリシー | Allow web search in Copilotの設定状況 | Web検索が無効なのにドメイン除外だけ設計してしまう |
| 対象ユーザー | 全社、部門、役職、パイロットグループ | 法務・開発・営業で必要なWeb情報が異なる |
| 除外候補ドメイン | 除外理由、影響業務、代替情報源 | 感覚で大量登録して回答品質を落とす |
| テストプロンプト | 業務で実際に使われる質問を用意 | 技術検証用の抽象プロンプトだけで判断する |
| ユーザー通知 | なぜ特定サイトが参照されないのか説明 | 「Copilotの精度が落ちた」と誤解される |
| 監査・モニタリング | Purview監査、DSPM、利用レポート | 設定して終わりになり、効果検証されない |
| 変更管理 | 追加・削除の申請者、承認者、期限 | 一度入れた除外が放置される |
| 例外対応 | 特定部門だけ除外を緩めるか | 全社一律で業務に合わない制御になる |
特に重要なのは、除外リストに「理由」と「見直し期限」を持たせることです。たとえば「example.comを除外」とだけ記録するのではなく、「旧製品仕様を掲載しており、2026年4月に営業提案で誤引用が発生。2026年9月に再確認」のように残しておくと、後から判断しやすくなります。
開発者が確認すべきポイント
Microsoft 365 Copilot向けにエージェント、プラグイン、Graph connectors、MCPベースの連携、社内データ接続を扱っている開発者も、この更新を無関係と考えない方がよいです。
ただし、Domain exclusion for web groundingの対象としてRoadmapで明示されているのは、Microsoft 365 CopilotとCopilot ChatのWeb groundingです。自作エージェントが独自APIを呼び出す場合、Graph connectorsで取り込んだ外部データを使う場合、Copilot Studioや別サービス側でWeb検索を構成している場合まで同じ除外リストが適用されるとは限りません。
開発者は次の点を確認してください。
| 項目 | 確認ポイント |
|---|---|
| エージェントの外部参照 | 独自API、外部SaaS、公開Web APIを呼んでいないか |
| 回答根拠の表示 | 除外対象サイトが引用や根拠に出ないか |
| エラー時の挙動 | 除外により情報不足になったとき、ユーザーにどう説明されるか |
| 管理者設定との整合性 | Copilot Control System、Integrated Apps、Cloud Policyと矛盾しないか |
| テストデータ | 除外前・除外後で同じプロンプトを比較できるか |
| ドキュメント | 「このエージェントはどの情報源を使うか」を管理者に説明できるか |
Microsoft 365 Copilotでは、エージェントが有効な場合、必要に応じてCopilotがエージェントを使い、管理者はMicrosoft 365管理センターのIntegrated appsでエージェントの権限、データアクセス、利用規約、プライバシー声明を確認できると説明されています。(Microsoft Learn) 開発者は、Web groundingの除外設定とは別に、エージェント側のデータ取得経路も棚卸ししておくべきです。
ユーザーへの説明で押さえるべきこと
この種の管理機能は、ユーザーに説明しないまま適用すると「Copilotの回答が変わった」「前は出ていた情報が出なくなった」と受け取られます。展開時には、技術的な説明よりも、業務上の意味を簡潔に伝えることが重要です。
ユーザー向けには、次のような説明が分かりやすいです。
Microsoft 365 Copilotの回答品質と情報ガバナンスを高めるため、一部の外部WebサイトをCopilotのWeb参照元から除外します。Web検索全体を止めるものではありませんが、特定サイトの情報はCopilotの回答根拠に使われない場合があります。必要な情報が見つからない場合は、公式サイトや社内ナレッジを確認してください。
また、ユーザーが知っておくべき実務上のポイントは次の3つです。
- Copilotの回答にWeb情報が含まれない場合がある
- 除外されたサイトを手動で閲覧できるかどうかは、別の社内ルールやネットワーク制御による
- 機密情報をプロンプトに入力してよい、という意味ではない
特に最後の点は重要です。Domain exclusionは、ユーザーの入力内容を安全にする機能ではありません。機密情報の入力ルール、感度ラベル、DLP、監査の教育は引き続き必要です。
展開前に用意したいテストプロンプト
設定を入れる前に、業務部門ごとの代表的なプロンプトを準備しておくと、展開後の影響を判断しやすくなります。
| 部門 | テストプロンプト例 | 確認したいこと |
|---|---|---|
| IT管理 | 「Microsoft 365 CopilotのWeb検索制御について最新情報を整理して」 | 公式ドキュメントが優先されるか |
| 開発 | 「Microsoft Graph connectorとCopilot agentの違いを比較して」 | 技術情報の根拠が信頼できるか |
| 法務 | 「AI利用ポリシーを作る際の注意点を整理して」 | 不確かな法解釈を断定しないか |
| 営業 | 「競合サービスとの比較表を作って」 | 除外した競合・比較サイトに依存しないか |
| 広報 | 「当社に関する公開情報を要約して」 | 古い転載サイトや不正確な情報を拾わないか |
| 人事 | 「生成AI利用研修の項目を作って」 | 社内ルールと矛盾しないか |
テストでは、回答の正確性だけでなく、引用元、情報の新しさ、除外対象サイトへの依存度、回答が曖昧になった場合の表現も確認します。
運用開始後はログと監査で見直す
Domain exclusion for web groundingは、設定した瞬間に完了する機能ではありません。運用後は、実際にCopilotがどのようなWeb検索語を使い、どのような回答を返しているかを確認しながら調整する必要があります。
Microsoft Learnでは、Web検索クエリのログにより、管理者がCopilotが生成した正確なWeb検索クエリを検索、監査、eDiscoveryの対象にできると説明されています。また、Purview Data Security Posture Management for AIのActivity Explorerで、元のプロンプト、応答、サポートリソースと並べてWeb検索語を確認できるとされています。(Microsoft Learn)
運用では、次の観点で見直すと効果的です。
- 除外したドメインが実際に問題を減らしているか
- 除外により業務上必要な回答が出にくくなっていないか
- 新たに除外すべき低品質サイトが出てきていないか
- 公式情報源まで誤って除外していないか
- DLPや感度ラベルで対応すべき問題をドメイン除外で代替していないか
除外リストは、半年に一度の棚卸しでは遅い場合があります。Copilotの利用が活発な組織では、最初の3か月は月次で見直し、その後は四半期ごとにレビューする運用が現実的です。
今回の更新でやるべきこと
Domain exclusion for web groundingは、Microsoft 365 CopilotのWeb groundingをより現実的に業務利用するための管理機能です。Web検索を全面的に止めるのではなく、問題のあるサイトだけを参照元から外せるようになる点が大きな変更です。
管理者は、まずAllow web search in Copilotの現在の設定、対象ユーザー、Web groundingの利用方針を確認してください。そのうえで、除外候補ドメインを少数から選び、業務プロンプトで回答品質を比較し、パイロット展開から始めるのが安全です。
開発者は、自作エージェントや外部データ連携がWeb groundingの除外設定とどう関係するかを検証し、管理者に説明できる形で情報源を整理しておく必要があります。
この更新は、Copilotの利用を止めるための機能ではありません。むしろ、Microsoft 365 CopilotとCopilot Chatを安心して使うために、Web参照元の品質とガバナンスを調整する機能です。GA予定の2026年6月に向けて、今のうちにWeb検索ポリシー、DLP、SharePoint権限、除外候補ドメインの棚卸しを始めておきましょう。
コメント