Copilot の web grounding で除外ドメイン指定が使えるようになると、Microsoft 365 Copilot と Copilot Chat に対して「この外部サイトは参照しない」と管理者が限定的に指定できるようになります。Microsoft は 2026 年 3 月の更新情報でこの機能を案内し、4 月にロールアウトするとしています。外部 Web を丸ごと止めるほどではないものの、品質やコンプライアンスに不安があるサイトは見せたくない。そんな企業にちょうどよい中間的な統制です。 (TECHCOMMUNITY.MICROSOFT.COM)
現行の公開文書では、web search の管理導線は Microsoft 365 admin center の Copilot > Settings > Data Access > Web search for Microsoft 365 Copilot and Microsoft Copilot から、Microsoft 365 Apps admin center の Cloud Policy に進む形です。つまり今回の除外ドメイン指定は、既存の「web 検索を全部オン/オフする」運用の隙間を埋める実務向けの機能として理解すると分かりやすいです。 (Microsoft Learn)
Copilot の web grounding で除外ドメイン指定とは
web grounding は、Copilot が回答を作る際に、必要に応じて公開 Web の情報を参照して回答の根拠を補う仕組みです。Microsoft 365 Copilot と Copilot Chat は、ユーザーのプロンプトを解析し、数語の検索クエリを生成して Bing 検索サービスに送り、その結果をもとに回答を組み立てます。Copilot Chat では、どんな検索語とサイトが使われたかを引用表示で確認でき、表示期間は 24 時間です。 (Microsoft Learn)
今回の新機能で重要なのは、Microsoft の表現が「除外」である点です。少なくとも現時点の公開情報から読み取れるのは、「許可ドメインだけに限定する allowlist」ではなく、「参照させたくないドメインを外す blocklist 型に近い統制」だということです。確認できている骨子は「limited set of sites を exclude できる」「4 月ロールアウト」という点までで、件数上限やサブドメインの扱いなどは、今後の管理ドキュメントで確認する前提で見ておくのが安全です。 (TECHCOMMUNITY.MICROSOFT.COM)
まず整理したい：この機能で解決できること、別の統制を使うべきこと
除外ドメイン指定が向いているのは、「外部 Web は使いたいが、一部のサイトだけ参照させたくない」というケースです。逆に、「検索クエリ自体を Bing に送らせたくない」という要件なら、この機能だけでは足りません。Microsoft は、生成された web search query にはユーザーやテナントの識別子を含めないと説明する一方で、これらの生成クエリには DPA が適用されず、HIPAA や EU Data Boundary も適用対象外としています。さらに Copilot Chat で web search をオフにすると、Bing への web query は送信されず、基盤 LLM のみで回答します。つまり、懸念が「参照先の品質」ではなく「外部送信の有無」なら、Allow web search in Copilot ポリシーで対象ユーザーや部門の web search 自体を止める方が筋が通ります。 (Microsoft Learn)
| 悩み | 向く統制 |
|---|---|
| 一部の外部サイトだけ避けたい | 除外ドメイン指定 |
| 外部 Web 検索自体を止めたい | Allow web search in Copilot を無効化 |
| 社内の SharePoint / OneDrive / Teams 由来の過共有が心配 | Microsoft Purview DLP for Copilot や SAM Restricted Content Discovery |
上の切り分けで見落としやすいのが、外部 Web の統制と、内部データの過共有対策は別物だという点です。Microsoft は、敏感な内部サイトを Copilot discovery から除外するための SAM Restricted Content Discovery と、機密コンテンツを Copilot grounding から除外するための Microsoft Purview DLP for Copilot を案内しています。社内データの露出が不安なら、除外ドメイン指定ではなくこちらを優先して考えるべきです。 (Microsoft Learn)
どんなサイトを除外候補にするか
現場で失敗しやすいのは、「なんとなく怪しいから除外する」という決め方です。除外対象は、サイトの好き嫌いではなく、回答品質の劣化要因とコンプライアンスリスクの両方から選ぶとぶれません。
| 除外候補のタイプ | 除外を検討する理由 | 代わりに残したい参照先 |
|---|---|---|
| 二次転載・要約中心のまとめサイト | 一次情報から意味がずれやすい | ベンダー公式ブログ、公式ドキュメント、官公庁 |
| 広告色の強い比較・レビューサイト | 商用誘導が強く、中立な説明になりにくい | 公式仕様書、公式価格表、製品ドキュメント |
| 旧ドメイン・旧ブランドのアーカイブ | 古い情報が残りやすく、現行仕様と混ざる | 現在の公式ドメイン |
| 匿名運営の生成 AI 記事サイト | 出典や責任主体が曖昧で精度評価しにくい | 編集方針が明確な媒体、公式一次情報 |
| 社内で非推奨と決めている外部サイト | ブランド・法務・業界ルールに抵触する可能性 | 事前承認済みの参照先 |
ただし、個人ブログを一律に除外するのは早計です。IT 分野では、公式ドキュメントより先に実装上の注意点を整理している専門家ブログが役立つ場面もあります。除外の判断は「個人運営かどうか」ではなく、「一次情報に当たっているか」「更新が追えているか」「誤りがあった時に訂正される運営体制か」で見る方が実務的です。
回答品質と統制のバランスはこう考える
Microsoft は、web search を有効にすると Copilot が最新の Web 情報で回答を補強でき、品質向上につながると説明しています。一方で Copilot Chat は公開 Web データに grounded されたチャットであり、Microsoft 365 Copilot はそれに加えて Microsoft Graph 経由の社内データも使えます。つまり同じ除外ドメイン指定でも、影響が出やすいのは Copilot Chat の方で、Microsoft 365 Copilot は業務コンテキストが強い分だけ影響が相対的に小さい場面があります。検証はこの差を前提に設計するのが現実的です。 (Microsoft Learn)
さらに、Microsoft 365 Copilot にはユーザー側の Web content トグルがありますが、Copilot Chat にはそのトグルがありません。同じ部門で「回答が変わった」「変わっていない」という声が混在したら、まず管理者設定だけでなく、Microsoft 365 Copilot 側で個別ユーザーが Web content をオフにしていないかを見た方が早いです。 (Microsoft Learn)
もう一つ見落としやすいのが、Disabled in Microsoft 365 Copilot Work mode; Enabled in Microsoft 365 Copilot Web mode and Microsoft 365 Copilot Chat という中間オプションです。これは便利そうに見えますが、この設定を選ぶと Microsoft 365 Copilot の Researcher と Analyst では web search が無効になります。調査業務や市場分析のように外部情報の鮮度が重要な部門では、除外ドメイン指定で足りるのか、それともユーザーグループ単位で web search ポリシーを分けるのかを先に決めておかないと、あとで「思ったより調べてくれない」という不満につながります。 (Microsoft Learn)
| 情報の鮮度要求 | 統制リスク | 基本方針 |
|---|---|---|
| 高い | 低い | web grounding を維持し、除外は最小限 |
| 高い | 高い | 高リスクドメインだけ先に除外し、部門単位で検証 |
| 低い | 高い | web search を無効化する選択肢を優先 |
| 低い | 低い | まずは現状維持、問題サイトだけ監視 |
管理者の判断軸：除外する前に点数化する
「広報が嫌がっている」「現場が怪しいと言っている」だけで除外すると、回答品質と統制のバランスが崩れます。迷うなら、除外候補を点数化して優先順位を付けると運用が安定します。
| 判断軸 | 1 点 | 3 点 | 5 点 |
|---|---|---|---|
| 信頼性 | 公式・一次情報中心 | 編集体制はあるが二次情報が多い | 転載・要約中心で出典が弱い |
| コンプライアンス | 問題なし | 一部懸念あり | 明確に社内方針と衝突 |
| 代替性 | 代替が少ない | 一部代替あり | 公式代替が十分ある |
| 更新健全性 | 最新情報が保たれる | 旧情報が混在する | 古い情報が残り続ける |
| 業務影響 | 利用者が限定的 | 複数部門で触れる | 全社で参照されやすい |
実務では、合計 18 点以上を「除外候補」、13〜17 点を「パイロットで検証」、12 点以下を「監視対象」にすると判断しやすくなります。たとえば法務・広報・医療・金融のように説明責任が重い部門は、コンプライアンスの配点を重くします。逆に IT 運用や開発部門では、多少読みにくくても公式ドキュメントやベンダー KB を残す方が成果につながりやすいです。
Microsoft 365 admin center で導入前にやること
現行の公開文書では、web search の設定は Microsoft 365 admin center の Copilot > Settings > Data Access > Web search for Microsoft 365 Copilot and Microsoft Copilot から、Microsoft 365 Apps admin center の Cloud Policy に進む形です。また、Copilot Chat の管理は admin center の Copilot Control System から行え、Copilot や AI 関連設定は AI Administrator ロールでも扱えます。除外ドメイン指定が実装された後も、少人数の管理者だけに閉じず、AI Admin を含めた運用体制にしておくと変更管理が楽になります。 (Microsoft Learn)
| 今やること | 実務での進め方 |
|---|---|
| 除外候補ドメインを洗い出す | 直近の Copilot 回答や現場からの指摘をもとに 10〜20 件ほど候補化する |
| 理由を明文化する | 「誤情報が多い」ではなく、「旧ドメインで現行仕様と混在」「広告色が強い」など具体化する |
| 代替ソースを決める | 除外するなら、代わりに残したい一次情報をセットで決める |
| 対象部門を分ける | 法務・広報・研究開発など、影響の大きい部門から先にパイロットする |
| 成功条件を決める | 誤回答件数、ユーザー満足、問い合わせ件数、業務時間短縮などで測る |
検証時は、Copilot Chat の web search query citations を必ず活用したいところです。Copilot Chat では、使われた検索語とサイトが 24 時間だけ見えるため、「どのサイトが効いていたのか」「除外後に何が消えたのか」を比較できます。加えて Microsoft は、Copilot Dashboard で thumbs up / thumbs down の満足度や、利用傾向の把握を進めています。ドメイン除外の良し悪しを感覚で決めず、引用表示と満足度指標の両方で見るのが王道です。 (Microsoft Learn)
運用で失敗しやすいポイント
除外理由が曖昧なまま増やしてしまう
除外リストは、一度作ると増えやすく、減りにくいものです。「なんとなく不安」で追加すると、あとから誰も削除判断できなくなります。ドメインごとに、理由、代替ソース、責任者、見直し日をセットで持っておくと暴走しません。
代替ソースを設計しない
除外だけして、残すべき一次情報を決めない運用は危険です。Copilot の回答品質は、何を減らすかだけでなく、何を残すかで決まります。特に製品仕様、法令、セキュリティ、公的手続きに関わる質問では、公式サイトを残せているかが最重要です。
サポート手順を用意しない
ユーザーから「前より回答が弱くなった」と言われても、確認手順がなければ原因を切り分けられません。Copilot Chat では query citations が 24 時間で消えるため、検証期間中はスクリーンショット保存や報告テンプレートを決めておくと対応が速くなります。満足度や利用状況も、Copilot Dashboard の指標で前後比較できるようにしておくべきです。 (Microsoft Learn)
仕様公開前に決め打ちする
除外ドメイン指定の骨子は発表されていますが、実際の設定 UI やマッチ条件の細部は、今後の管理ドキュメントで確認した方が安全です。サブドメインを含むのか、どこまで柔軟に指定できるのかは、実装仕様を見てからルール化した方が運用事故を防げます。 (TECHCOMMUNITY.MICROSOFT.COM)
Copilot の web grounding で除外ドメイン指定は、「web を全部切る」と「何でも参照させる」の間を埋める、かなり実務的な統制です。特に、外部ソースの品質やコンプライアンスに敏感な企業では、有効な選択肢になりやすいでしょう。ただし、外部 query の送信そのものを止めたいのか、内部データの過共有を防ぎたいのかで、使うべき統制は変わります。まずは除外候補ドメインを 10 件ほど洗い出し、点数化して、除外する・パイロットする・監視する の 3 つに分けてください。そのうえで、ロールアウト後は query citations と満足度指標で前後比較する。この順番で進めると、回答品質と統制のバランスを崩しにくくなります。 (TECHCOMMUNITY.MICROSOFT.COM)
コメント