Microsoft 365 Copilotで社内情報を検索したとき、「どのSharePointサイトの情報を信じればよいのか分からない」と感じる場面は少なくありません。SharePoint: Authoritative Sitesは、その問題に対して、管理者が公式・信頼済みのSharePointサイトを指定できるようにする機能です。結論から言うと、これは「アクセス制御」ではなく、Copilot SearchやCopilot Chatで参照される社内情報の信頼性を高めるための情報ガバナンス機能です。
Microsoft 365 Roadmapの項目ID 561323では、対象製品はSharePointとMicrosoft Copilot、対象クラウドはWorldwide、プラットフォームはWeb、プレビューは2026年5月、一般提供は2026年6月、ステータスはLaunchedとされています。Roadmap API上の更新日時は2026-06-05 22:00 UTCで、日本時間では2026-06-06相当です。(Microsoft)
SharePoint: Authoritative Sitesとは
SharePoint: Authoritative Sitesは、管理者が特定のSharePointサイトを「公式で信頼できる情報源」として指定する機能です。たとえば、社内規程、就業ルール、ITヘルプ、ブランドガイドライン、経営方針、社内ニュースなど、組織として正本にしたい情報を持つサイトをAuthoritative Sitesとして扱えます。
Microsoft Learnでは、Authoritative Sitesは「公式に管理されたSharePointソース」を管理者が識別するための機能であり、指定されたサイトのコンテンツはCopilot Searchで信頼済みとして認識されると説明されています。検索結果では、ユーザーが信頼できる項目を識別しやすくするための視覚的な手掛かりも使われます。(Microsoft Learn)
重要なのは、Authoritative Sitesは「そのサイトだけをCopilotに使わせる機能」ではないことです。既存のSharePoint権限、共有設定、Microsoft 365のデータ保護設定を置き換えるものではありません。Copilotが表示できる組織データは、個々のユーザーが少なくとも表示権限を持つデータに限られます。(Microsoft Learn)
何が変わるのか
今回の変更で大きいのは、Copilotが社内情報を扱う際に、管理者が「どのSharePointサイトを公式情報源として扱うべきか」を明示できる点です。
従来もSharePointの権限、サイト構成、検索、ブックマーク、アクロニムなどで情報整理はできました。しかし、Copilotの利用が広がると、同じテーマについて複数のサイトに古い資料やドラフトが残っている場合、ユーザーは「どれが最新で正式な情報なのか」を確認する手間が増えます。
Authoritative Sitesを使うと、次のような変化が期待できます。
| 観点 | これまで起きやすかった問題 | Authoritative Sitesで狙える効果 |
|---|---|---|
| 社内規程 | 古い規程PDF、部門別コピー、最新版が混在する | 公式規程サイトを信頼済みソースとして扱いやすくなる |
| 社内ニュース | 部門サイトや過去投稿に似た情報が散在する | 公式ニュースサイトをユーザーが識別しやすくなる |
| ITヘルプ | 個人作成の手順書とIT部門の正式手順が混在する | IT部門管理サイトの情報を優先的に見つけやすくなる |
| 人事・総務情報 | 古い福利厚生資料が検索に出る | 公式ポータルへの誘導を強めやすくなる |
Roadmapでは、Authoritative Sitesに分類された高品質で信頼できるコンテンツ、たとえば会社ニュース、ポリシー、更新情報などが、Copilot ChatとCopilot Search体験で優先されると説明されています。(Microsoft) 一方、Microsoft Learnの設定ページでは主にCopilot Searchでの信頼済み表示として説明されているため、展開時はCopilot Searchでの見え方を先に確認し、Copilot Chatでの回答傾向も自社テナントで検証するのが安全です。(Microsoft Learn)
対象となる管理者・開発者・利用部門
SharePoint: Authoritative Sitesの影響を受けるのは、SharePoint管理者だけではありません。Copilotを業務利用する組織では、情報管理に関わる複数の担当者が確認すべき変更です。
| 対象者 | 確認すべきこと |
|---|---|
| SharePoint管理者 | 公式サイトの選定、PowerShellまたはCSOMでの設定、制限事項の確認 |
| Microsoft 365管理者 | Copilotライセンス、対象ユーザー、検索・Copilot体験への影響 |
| セキュリティ・コンプライアンス担当 | 過剰共有、機密情報、外部共有、感度ラベル、DLPとの整合性 |
| サイト所有者 | コンテンツの鮮度、責任者、更新フロー、古いファイルの整理 |
| 社内広報・人事・総務・IT部門 | 公式情報源として指定すべきサイトの洗い出し |
| 開発者・自動化担当 | CSOM APIを使った一括指定、解除、棚卸しスクリプトの設計 |
特に開発者は、Authoritative Sitesを単なる「フラグ設定」と見なさないことが重要です。誤ったサイトを一括で指定すると、ユーザーが古い情報や未承認情報を公式情報と誤認する恐れがあります。自動化する場合は、サイト所有者、最終更新日、情報分類、アクセス範囲を確認したうえで対象リストを作るべきです。
対象範囲とリリース情報
公式Roadmapの情報を整理すると、SharePoint: Authoritative Sitesの対象範囲は次のとおりです。(Microsoft)
| 項目 | 内容 |
|---|---|
| Roadmap ID | 561323 |
| 機能名 | SharePoint: Authoritative Sites |
| 対象製品 | SharePoint、Microsoft Copilot |
| プラットフォーム | Web |
| クラウド | Worldwide（Standard Multi-Tenant） |
| リリース段階 | Preview、General Availability |
| プレビュー開始 | 2026年5月 |
| 一般提供 | 2026年6月 |
| ステータス | Launched |
| 作成日時 | 2026-04-30 |
| 更新日時 | 2026-06-05 22:00 UTC |
Microsoft 365 Roadmapは商用機能の予定日や説明を提供するものですが、提供時期や内容は変更される可能性があると明記されています。展開計画を立てる際は、RoadmapだけでなくMicrosoft Learn、Microsoft 365管理センター、メッセージセンターの内容も合わせて確認してください。(Microsoft)
管理者が最初に確認すべき前提条件
Authoritative Sitesの設定には、いくつかの前提条件があります。Microsoft Learnでは、SharePoint管理者またはグローバル管理者ロール、管理者アカウントへのMicrosoft 365 Copilotライセンス、SharePoint Online Management Shellへのアクセスが必要とされています。(Microsoft Learn)
実務では、次の順番で確認すると失敗しにくくなります。
| 確認項目 | 判断基準 |
|---|---|
| 管理者ロール | SharePoint AdministratorまたはGlobal Administratorで作業できるか |
| Copilotライセンス | 設定を実行する管理者アカウントにMicrosoft 365 Copilotライセンスがあるか |
| 管理ツール | SharePoint Online Management Shellを利用できるか |
| 対象サイト | 個人用サイトではなく、組織管理のSharePointサイトか |
| コンテンツ品質 | 最新版、承認済み、所有者あり、更新ルールありのサイトか |
| 権限設計 | 必要なユーザーだけが閲覧できる状態になっているか |
ここで最も見落としやすいのが、「公式にしたいサイト」と「公式にしてよいサイト」は違うという点です。たとえば人事ポータルを公式情報源にしたい場合でも、過去の規程、ドラフト文書、部門限定資料、外部共有リンクが同じサイト内に残っていれば、先に整理が必要です。
設定方法：PowerShellとCSOM API
現時点のMicrosoft Learnでは、Authoritative SitesはPowerShellとCSOM APIで設定する機能として説明されています。サイト単位での指定に対応し、個人用サイトは対象外です。(Microsoft Learn)
PowerShellで単一サイトを指定する
単一サイトを指定するだけであれば、SharePoint Online Management Shellを使う方法が分かりやすいです。
Install-Module -Name Microsoft.Online.SharePoint.PowerShell -Force
Import-Module -Name Microsoft.Online.SharePoint.PowerShell
Connect-SPOService -Url "https://<tenant>-admin.sharepoint.com"
Set-SPOSite -Identity "https://<tenant>.sharepoint.com/sites/<siteName>" -IsAuthoritative $trueこの方法は、まず少数の公式サイトを試験的に指定する場合に向いています。たとえば、社内ポータル、人事規程サイト、ITヘルプサイトの3つだけを対象にして、検索結果の表示やユーザーの反応を確認する展開が現実的です。
CSOM APIで一括管理する
複数サイトを管理する場合や、棚卸し・一括指定・解除を自動化する場合はCSOM APIが候補になります。Microsoft Learnでは、CSOM version 16.1.26914.12004以降が必要とされています。(Microsoft Learn)
CSOMでは、次のような操作が用意されています。
| 操作 | 用途 |
|---|---|
| GetAuthoritativeResources | 現在のAuthoritative Sitesを取得する |
| SetResourceAsAuthoritative | 特定サイトをAuthoritative Siteに指定する |
| RemoveResourceAsAuthoritative | 指定を解除する |
| BulkSetResourceAsAuthoritative | 複数サイトを一括指定する |
| BulkRemoveResourceAsAuthoritative | 複数サイトを一括解除する |
一括処理を行う場合は、URLだけでなくSite IDを管理し、実行前後のリストを必ず保存してください。運用上は「誰が、いつ、どのサイトを、どの理由で公式扱いにしたか」を追跡できる状態にしておくと、後から監査や見直しがしやすくなります。
Authoritative Sitesに指定すべきサイトの判断基準
Authoritative Sitesは、数を増やせばよい機能ではありません。公式サイトが多すぎると、何が本当に信頼できる情報なのかが曖昧になります。Microsoft Learnでも、指定できるAuthoritative Sitesは最大100サイトとされています。(Microsoft Learn)
候補サイトは、次の基準で選定するとよいでしょう。
| 判断基準 | 指定に向いている例 | 指定を避けたい例 |
|---|---|---|
| 所有者が明確 | 人事部が管理する就業規則サイト | 所有者不明の旧ポータル |
| 更新ルールがある | 四半期ごとに棚卸しされるIT手順サイト | 最終更新が数年前のFAQ |
| 正式承認済み | 承認済み規程、公式ニュース、公式テンプレート | 作業中ドラフト、個人メモ |
| アクセス範囲が適切 | 全社員向け、部門向けなど権限が整理済み | Everyoneリンクが残る資料置き場 |
| 重複が少ない | 正本として運用されるサイト | コピー文書が多数ある部門サイト |
| 検索意図に合う | ユーザーがよく探す業務ルール、申請手順 | 利用頻度が低い一時プロジェクトサイト |
実務では、最初から100サイト近く指定するのではなく、10サイト未満のパイロットから始める方が安全です。まずは「全社員がよく検索する」「誤情報が出ると影響が大きい」「正式な所有部門がある」サイトを優先します。
指定前にやるべきコンテンツ整理
Authoritative Sitesを設定する前に、対象サイトのコンテンツ品質を見直してください。公式サイトとして指定すると、ユーザーはそのサイトの情報を信頼しやすくなります。つまり、古い情報が残っているサイトを指定すると、古い情報まで信頼されやすくなるリスクがあります。
最低限、次の点を確認します。
| 確認項目 | 具体的な確認内容 |
|---|---|
| 古いファイル | 旧版の規程、過去の手順書、重複PDFが残っていないか |
| ドラフト | 「確認中」「仮」「旧」などの資料が公開範囲にないか |
| 所有者 | サイト所有者、業務責任者、更新担当者が明確か |
| 更新日 | 重要ページの最終更新日が古すぎないか |
| 権限 | 全社員向け、部門向け、役職者向けの権限が分かれているか |
| 外部共有 | 外部ユーザーや匿名リンクが不要に残っていないか |
Microsoftは、Copilotとエージェントが最大限機能するには、コンテンツが最新で適切に管理されていることが重要だと説明しています。また、CopilotとエージェントはMicrosoft Graphからデータを取得し、既存の権限、共有設定、ポリシーを尊重します。(Microsoft Learn)
つまり、Authoritative Sitesの前にやるべきことは「公式フラグを立てること」ではなく、公式情報源として耐えられる状態にSharePointサイトを整えることです。
権限管理との関係：過剰共有は別途対策が必要
Authoritative Sitesは、アクセス権の問題を解決する機能ではありません。Copilotはユーザーがアクセスできるデータをもとに回答するため、過剰共有されたサイトやファイルがあると、ユーザーが本来見るべきではない情報をCopilot経由で見つけやすくなる可能性があります。
Microsoft Learnでは、Microsoft 365 Copilotはユーザーが少なくとも表示権限を持つ組織データだけを表示すると説明されています。これは安全に見えますが、逆に言えば、SharePoint側で広く共有されすぎているデータは、その権限の範囲内でCopilotにも使われ得るということです。(Microsoft Learn)
高リスクなSharePointサイトについては、Authoritative Sitesの指定より先に、Restricted Content DiscoveryやSharePoint Advanced Managementによる棚卸しを検討してください。Restricted Content Discoveryは、特定サイトのファイルが組織全体検索やMicrosoft 365 Copilot Business Chatに表示されるのを制限するための機能です。ただし、既存の権限そのものを変更する機能ではなく、過剰に使うと検索やCopilotの回答品質に悪影響が出る可能性もあります。(Microsoft Learn)
Restricted Content Discoveryとの違い
Authoritative SitesとRestricted Content Discoveryは、名前だけを見るとどちらもCopilot向けのSharePoint制御に見えますが、目的は反対に近いです。
| 機能 | 主な目的 | 使う場面 |
|---|---|---|
| Authoritative Sites | 公式・信頼済みサイトを識別しやすくする | 正式な社内情報を見つけやすくしたい |
| Restricted Content Discovery | 高リスクサイトの発見を一時的に制限する | 過剰共有や機密情報の整理が終わるまで露出を抑えたい |
| SharePoint権限管理 | 誰が何を見られるかを制御する | 情報漏えいを防ぐ基本設定 |
| Microsoft Purview | ラベル、DLP、監査、保持などを管理する | 機密情報やコンプライアンスを管理したい |
Authoritative Sitesは「見せるべき公式情報を分かりやすくする」機能です。一方で、Restricted Content Discoveryは「見つかると困る可能性がある情報を一時的に発見しにくくする」機能です。どちらか一方ではなく、サイトの状態に応じて使い分ける必要があります。
展開時の注意点
Authoritative Sitesを本番展開する際は、次の制限と運用ポイントを押さえてください。
Microsoft Learnでは、Authoritative Sitesには「最大100サイト」「変更反映に最大72時間」「サイトレベルのみ」「マルチGeoテナントではGeoごとに管理」「個人用サイトは対象外」といった制限が示されています。(Microsoft Learn)
| 注意点 | 実務上の対応 |
|---|---|
| 最大100サイト | 全社共通・影響度が高いサイトに絞る |
| 反映に最大72時間 | 設定直後に結果が変わらなくても慌てず、検証期間を確保する |
| サイト単位のみ | ライブラリ単位、フォルダー単位、ファイル単位の指定と混同しない |
| 個人用サイト非対応 | OneDriveや個人サイトを公式情報源として扱わない |
| マルチGeoはGeoごと | 日本、米国、欧州などGeo別に対象サイトを確認する |
| 解除・変更も運用対象 | 異動、組織改編、サイト統廃合時に見直す |
特に「最大72時間」は展開計画に入れておくべきです。月曜朝に設定して同日中にユーザーへ案内すると、まだ期待どおりに表示されず、問い合わせが増える可能性があります。設定、反映待ち、管理者検証、限定ユーザー検証、全体周知の順に進めると安全です。
パイロット展開の進め方
最初から全社展開するより、少数の重要サイトでパイロットを行う方が失敗を抑えられます。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 候補選定 | 人事、総務、IT、広報などから公式サイト候補を出す | 候補サイト一覧 |
| 品質確認 | 古い資料、ドラフト、重複、権限を確認する | 修正リスト |
| 対象確定 | まず3〜10サイト程度に絞る | 初期Authoritative Sites一覧 |
| 設定 | PowerShellまたはCSOMで指定する | 実行ログ |
| 検証 | Copilot Searchで検索結果、表示、参照元を確認する | 検証結果 |
| 周知 | ユーザーに「公式情報の見分け方」を案内する | 社内案内文 |
| 定期見直し | 月次または四半期で対象を更新する | 棚卸し記録 |
検証では、単に検索結果の順位だけを見るのではなく、ユーザーが実際に使う質問で確認してください。
例としては、次のような検索・質問が適しています。
- 「在宅勤務の申請方法」
- 「経費精算の締め日はいつ」
- 「最新のセキュリティ研修資料」
- 「社内ロゴの使用ルール」
- 「育児休業の手続き」
これらの検索で、公式サイトの情報が分かりやすく表示されるか、古い資料が目立っていないか、権限のない情報が表示されていないかを確認します。
開発者が確認すべき自動化・API運用のポイント
開発者がCSOM APIでAuthoritative Sitesを管理する場合は、単にAPIを呼び出すだけでなく、運用事故を防ぐ設計が必要です。Microsoft Learnでは、CSOMによる取得、指定、解除、一括指定、一括解除の操作が示されています。(Microsoft Learn)
実装時は、次の点を押さえてください。
| 観点 | 推奨対応 |
|---|---|
| 入力データ | CSVやリストにはURL、Site ID、所有者、指定理由を含める |
| 事前検証 | サイトが存在するか、個人用サイトでないかを確認する |
| 権限 | 実行アカウントやアプリ権限を最小限にする |
| ログ | 指定前、指定後、失敗時のエラーを保存する |
| ロールバック | 誤指定時に一括解除できるようにする |
| レビュー | 実行前に業務責任者とSharePoint管理者が承認する |
| 定期実行 | 自動実行する場合も、無条件追加ではなく差分確認を挟む |
避けるべきなのは、「更新日が新しいサイトを自動で全部Authoritativeにする」「アクセス数が多いサイトを自動で公式扱いにする」といった機械的な判断です。アクセス数が多いサイトが公式とは限りません。逆に、重要な規程サイトはアクセス頻度が低くても、公式情報源として指定すべき場合があります。
Copilot SearchとCopilot Chatでの確認ポイント
Copilot Searchは、Microsoft 365 Copilotアプリで利用できるAI活用型のエンタープライズ検索です。対象ユーザーにはMicrosoft 365 Copilotライセンスが必要で、管理者やユーザーによる追加セットアップなしにCopilot Searchタブが表示されるとされています。(Microsoft Learn)
Copilot SearchとCopilot Chatは用途が異なります。Copilot Searchは「必要な情報をすばやく見つける」体験で、Copilot Chatは「より深い回答、コンテンツ生成、作業実行」に向いています。データソースはいずれもMicrosoft Graphやコネクタなどを利用しますが、体験は異なります。(Microsoft Learn)
展開後は、次の観点で検証してください。
| 確認対象 | 確認内容 |
|---|---|
| Copilot Search | 公式サイトの情報が信頼できる情報として識別しやすいか |
| Copilot Chat | 社内規程や手順を質問したとき、公式情報に基づく回答になっているか |
| 参照元 | 回答や検索結果から開くリンクが適切なサイトか |
| 権限 | 権限のないユーザーに限定情報が表示されていないか |
| 古い情報 | 旧版ファイルや過去サイトが目立っていないか |
| ユーザー理解 | 「公式情報の見分け方」が利用者に伝わっているか |
Copilotの回答品質を確認する際は、1回の質問だけで判断しないことが大切です。同じテーマでも、聞き方によって参照される情報が変わる可能性があります。複数の言い回しでテストし、結果を記録しましょう。
よくある失敗と対策
Authoritative Sitesを権限対策だと誤解する
最も危険なのは、「Authoritative Sitesに指定すれば安全になる」と考えることです。この機能は信頼済みソースを識別しやすくするものであり、閲覧権限を絞る機能ではありません。権限の見直し、外部共有の整理、感度ラベル、DLP、Restricted Content Discoveryなどは別途検討が必要です。
古いサイトを公式扱いにしてしまう
公式ポータルに古いPDFや過去の規程が残っていると、それらもユーザーに信頼されやすくなります。指定前に、旧版資料をアーカイブする、最新版へのリンクに統一する、ドラフトを非公開ライブラリに移すなどの整理を行ってください。
対象サイトを増やしすぎる
Authoritative Sitesは最大100サイトまで指定できますが、上限いっぱいまで使うことが正解ではありません。公式サイトが多すぎると、管理が追いつかず、かえって信頼性が下がります。最初は全社共通の重要サイトに絞り、必要に応じて追加します。
反映前にユーザーへ案内してしまう
変更は最大72時間かかる可能性があります。設定直後に「今日から公式情報が優先されます」と案内すると、実際の表示と説明がずれて混乱します。管理者側で反映を確認してから周知しましょう。(Microsoft Learn)
マルチGeo環境で一部Geoしか設定しない
マルチGeoテナントでは、Authoritative SiteのデータはGeoごとに管理されます。日本の管理者が本社Geoだけ設定し、欧州や米国のGeoを見落とすと、地域によって検索体験が変わる可能性があります。(Microsoft Learn)
導入前チェックリスト
本番展開前に、次のチェックリストを使ってください。
| チェック | 内容 |
|---|---|
| □ | Roadmap ID 561323の対象範囲と最新ステータスを確認した |
| □ | SharePoint管理者またはグローバル管理者で作業できる |
| □ | 設定用管理者アカウントにMicrosoft 365 Copilotライセンスがある |
| □ | 公式情報源にするサイトの所有者が明確である |
| □ | 古い資料、ドラフト、重複ファイルを整理した |
| □ | Everyoneリンク、外部共有、不要な広範囲権限を確認した |
| □ | まず少数サイトでパイロットする計画がある |
| □ | 設定前後の検索結果を比較するテストクエリを用意した |
| □ | 反映に最大72時間かかる前提でスケジュールを組んだ |
| □ | 誤指定時の解除手順と実行ログの保存方法を決めた |
| □ | 利用者向けに公式情報の見分け方を案内する準備がある |
今やるべきこと
SharePoint: Authoritative Sitesは、Microsoft 365 Copilot時代の社内情報ガバナンスを強化するための重要な機能です。ただし、効果を出すには、設定コマンドを実行する前の準備が欠かせません。
まずは、社内で「正本」として扱いたいSharePointサイトを10件以内で洗い出してください。次に、そのサイトの所有者、更新状況、権限、古いファイルの有無を確認します。そのうえで、PowerShellまたはCSOM APIでパイロット設定を行い、Copilot SearchとCopilot Chatで実際の表示・回答傾向を検証します。
Authoritative Sitesは、Copilotに「何を信頼してほしいか」を伝える機能です。だからこそ、指定するサイトは慎重に選び、設定後も定期的に見直すことが重要です。
コメント