SharePoint の AI エージェントを使わせるかどうかは、「エージェントをオンにする／オフにする」という単純な設定だけで決まるわけではありません。2026年6月25日に更新された Microsoft Learn の「Manage access to agents in SharePoint」では、ライセンス、従量課金、SharePoint 権限、.agent ファイル、サイト単位の制御、Microsoft 365 管理センターでのブロックを組み合わせて管理する考え方が整理されています。(Microsoft Learn)
結論から言うと、SharePoint 管理者が最初に確認すべきことは「誰がエージェントを使えるか」よりも先に、エージェント経由で見えてしまう可能性がある SharePoint コンテンツの権限状態です。SharePoint の agents は、ユーザー本人のアクセス権に基づいて回答するため、権限設計が乱れているサイトでは、AI 導入によって“検索しやすくなっただけで、過剰共有の問題が表面化する”可能性があります。(Microsoft Learn)
SharePoint の「Manage access to agents in SharePoint」とは何が変わったのか
「Manage access to agents in SharePoint」は、SharePoint 上の AI エージェントへのアクセス管理を説明する Microsoft 公式ドキュメントです。対象は SharePoint in Microsoft 365 で、2026年6月25日時点の更新では、管理者が制御すべき領域が大きく3つに整理されています。(Microsoft Learn)
| 管理対象 | 何を制御するか | 主な設定場所・機能 |
|---|---|---|
| 誰が agents を使えるか | Microsoft 365 Copilot ライセンス、従量課金ポリシー、.agent ファイルの権限 | Microsoft 365 管理センター、Azure、SharePoint のファイル権限 |
| agents が参照できる情報 | サイト、ページ、ドキュメント ライブラリ、ファイルへのアクセス権 | SharePoint 権限、Microsoft 365 グループ、SharePoint Advanced Management、DLP |
| agents をどこで利用できるか | サイト上の表示、Copilot Chat での利用可否、制限付きサイトでの利用 | サイト所有者設定、Restricted Content Discovery、Copilot Control System |
今回のポイントは、SharePoint agents が「独立したチャットボット」ではなく、SharePoint の権限、Microsoft 365 Copilot、Microsoft Graph、管理センターのエージェント管理と密接に結びつく点です。単にユーザーに Copilot ライセンスを割り当てるだけでは、ガバナンスとしては不十分です。
影響範囲：SharePoint 管理者だけでなく、セキュリティ・課金・サイト所有者も関係する
SharePoint agents は、SharePoint サイト、ページ、ドキュメント ライブラリを知識ソースとして利用し、ユーザーのアクセス権に応じて回答します。Microsoft は、agents が Microsoft 365 の他の Copilot 体験と同様に、ユーザーのデータ権限に基づいて組織データへアクセスすると説明しています。(Microsoft Learn)
そのため、影響を受ける担当者は SharePoint 管理者だけではありません。
| 担当者 | 確認すべき内容 |
|---|---|
| SharePoint 管理者 | サイト権限、外部共有、.agent ファイル、Restricted Content Discovery の適用範囲 |
| Microsoft 365 管理者 | Copilot ライセンス、サービス プラン、Microsoft 365 管理センターでの agents 管理 |
| セキュリティ／コンプライアンス担当 | DLP、秘密度ラベル、過剰共有、監査ログ、アクセス制御 |
| Azure 管理者／課金担当 | 従量課金ポリシー、Azure サブスクリプション、コスト監視 |
| サイト所有者 | サイトのメイン agent、権限の棚卸し、不要な agent ファイルの管理 |
特に注意したいのは、SharePoint agents は「有効化しなければ使われない」タイプの機能ではない点です。公式ドキュメントでは、agents in SharePoint はアクティベーションを必要とせず、利用可否は Copilot ライセンスや従量課金の設定で管理するとされています。(Microsoft Learn)
管理者が押さえるべき更新ポイント
Microsoft 365 Copilot ライセンスで利用者を制御できる
現時点では、Microsoft 365 Copilot ライセンスを持つユーザーが SharePoint agents を利用できます。管理者は Microsoft 365 管理センターでライセンスを割り当て、必要に応じて Copilot ライセンス内のサービス プランを編集できます。(Microsoft Learn)
重要なのは、Microsoft 365 Copilot for SharePoint をユーザー単位でオフにできる一方で、その変更は SharePoint の agents だけに閉じないことです。公式情報では、この設定を無効化すると、そのユーザーの OneDrive の Copilot と SharePoint ページ作成時の Copilot も無効になると説明されています。(Microsoft Learn)
つまり、「SharePoint agents だけを止めたい」という目的でサービス プランを変更すると、想定外に OneDrive やページ作成支援まで影響する可能性があります。部門単位で展開を遅らせたい場合は、ライセンス設定だけでなく、サイト単位の制御やエージェントのブロックも合わせて検討するべきです。
Copilot ライセンスがないユーザーは従量課金で制御する
Microsoft 365 Copilot ライセンスを持たないユーザーに SharePoint agents を使わせる場合、従量課金の設定が関係します。公式ドキュメントでは、まず SharePoint agents を Azure リソースとして設定し、その後 Microsoft 365 管理センターで従量課金ポリシーを作成し、セキュリティ グループに割り当てる流れが示されています。(Microsoft Learn)
この仕組みでは、課金ポリシーに割り当てられたセキュリティ グループのメンバーだけが SharePoint agents にアクセスできます。(Microsoft Learn)
実務では、次のような設計が現実的です。
| 利用シナリオ | 推奨される制御 |
|---|---|
| 全社導入前の検証 | 検証用セキュリティ グループに従量課金ポリシーを割り当てる |
| 部門ごとに費用を分けたい | 部門別のセキュリティ グループと課金ポリシーを分ける |
| 一部ユーザーだけ試験利用 | 対象者だけをグループに追加し、コスト上限とアラートを設定する |
| 利用拡大を抑えたい | グループ管理を申請制にし、棚卸し日を決める |
従量課金を使う場合は、Azure 側のコスト管理も必須です。Microsoft は、Microsoft Cost Management で消費量を監視し、必要に応じて予算やアラートを設定できると説明しています。(Microsoft Learn)
.agent ファイルの権限が、個別 agent の利用可否に関係する
SharePoint agents は .agent ファイルとして表現されます。公式ドキュメントでは、この .agent ファイルの権限によって、誰がその agent にアクセスまたは編集できるかが決まるとされています。(Microsoft Learn)
これは非常に重要です。SharePoint では Word や Excel ファイルと同じ感覚でファイル権限を管理できますが、.agent ファイルは AI の入口になります。単なる設定ファイルとして放置すると、意図しないユーザーが agent を利用できる可能性があります。
確認すべきポイントは次のとおりです。
| 確認項目 | 見落としやすいリスク |
|---|---|
.agent ファイルの保存場所 | 権限が広いライブラリに置かれていると、多くのユーザーが利用できる |
| 編集権限 | 意図しないユーザーが agent の設定や参照先を変更する可能性がある |
| 共有リンク | 「リンクを知っている全員」などの共有設定が残っていると管理が難しくなる |
| 所有者 | 作成者が退職・異動した場合、管理責任が曖昧になる |
| 命名規則 | 検証用 agent と本番用 agent の区別がつかなくなる |
特に本番利用する agent は、専用ライブラリや管理対象サイトに集約し、所有者、用途、参照先、公開範囲を記録しておくと運用しやすくなります。
agents が回答できる情報は「SharePoint 権限」に左右される
SharePoint agents の回答は、ユーザーがアクセスできるデータソースに基づきます。公式ドキュメントでは、ユーザーが agent にアクセスできても、その agent が参照するサイトやドキュメント ライブラリへの権限を持っていない場合、制限されたソースの内容は回答に含まれないと説明されています。(Microsoft Learn)
一見すると安全に見えますが、問題は「現在の SharePoint 権限が正しいとは限らない」ことです。過去に作られたプロジェクト サイト、外部共有が残ったライブラリ、所有者不在のサイト、退職者が作成した共有リンクなどが残っていると、AI によって情報を見つけやすくなるだけで、権限の問題そのものは解決されません。
まず見直すべき SharePoint 権限
SharePoint agents の導入前後では、少なくとも次の権限を確認してください。
| 対象 | 確認内容 |
|---|---|
| Microsoft 365 グループ接続サイト | グループがプライベートか、不要なメンバーがいないか |
| グループ非接続サイト | サイト権限に古いユーザーや広すぎるグループが残っていないか |
| ドキュメント ライブラリ | 固有権限が増えすぎていないか |
| 共有リンク | 匿名リンク、外部共有リンク、期限切れでないリンクが残っていないか |
| 重要部門サイト | 人事、経理、法務、経営会議などのサイトが必要最小限の権限か |
| 旧プロジェクト サイト | 使われていないが検索・Copilot・agents の対象になり得る状態か |
Microsoft も、Copilot と agents を効果的に使うには、コンテンツが最新で適切に管理されていることが重要であり、既存の権限、共有設定、ポリシーを尊重してデータを取得すると説明しています。(Microsoft Learn)
SharePoint Advanced Management と Restricted Access Control の使いどころ
機密性の高いサイトでは、通常の SharePoint 権限だけでなく SharePoint Advanced Management の機能も検討対象になります。
公式ドキュメントでは、SharePoint 管理者は Restricted Access Control policy を使って、特定グループのユーザーだけにサイトアクセスを制限できると説明されています。これにより、そのサイトのコンテンツは、指定された制限グループのユーザーに対してのみ Microsoft 365 Copilot で表示されるようになります。(Microsoft Learn)
Restricted Access Control は、単に「見えにくくする」機能ではありません。指定グループに含まれていないユーザーは、以前の権限や共有リンクがあっても、サイトやコンテンツへアクセスできない制御です。(Microsoft Learn)
ただし、誤解しやすい点があります。Restricted Access Control のグループにユーザーを追加しても、それだけでサイトへのアクセス権が付与されるわけではありません。ユーザーは、通常のサイトまたはコンテンツ権限と、Restricted Access Control グループのメンバーシップの両方を満たす必要があります。(Microsoft Learn)
Restricted Access Control が向いているサイト
| サイト種別 | 適用を検討する理由 |
|---|---|
| 経営会議・役員会資料 | 一部の役職者だけに限定すべき情報が含まれる |
| 人事・評価・給与関連 | 閲覧対象者の範囲が厳格に決まっている |
| M&A・法務案件 | プロジェクト終了後もアクセス制御が重要 |
| セキュリティ インシデント対応 | 関係者以外に内容が見えるとリスクが高い |
| 顧客別の機密資料サイト | 担当チーム以外への共有を防ぎたい |
一方で、一般的な社内ポータルやナレッジ共有サイトにまで過剰に適用すると、検索や Copilot、agents の利便性を下げる可能性があります。制御対象は「情報漏えい時の影響が大きいサイト」に絞るのが現実的です。
Restricted Content Discovery は「一時的な発見抑制」として使う
SharePoint agents の利用場所を制御するうえで、Restricted Content Discovery も重要です。公式ドキュメントでは、SharePoint 管理者は Restricted Content Discovery を使って、個別サイトの agent 関連機能をオフにできると説明されています。これにより、ユーザーはサイトのグローバル ヘッダーにある Agent アイコンを見られず、既定の agent の利用、新しい agents の作成、そのサイトのコンテンツを他の agents に追加することができなくなります。(Microsoft Learn)
Restricted Content Discovery は、組織全体の検索や Microsoft 365 Copilot での発見を一時的に抑制するための機能です。Microsoft は、権限やガバナンスを見直す時間を確保するための一時的な制御として設計されていると説明しています。(Microsoft Learn)
ただし、この機能は既存の権限を変更しません。ユーザーが直接アクセス権を持っているコンテンツには引き続きアクセスできます。また、過剰に使うと検索結果や AI 生成回答の完全性・関連性に影響する可能性があるため、選択的に使う必要があります。(Microsoft Learn)
Restricted Content Discovery を使う判断基準
| 状況 | 使うべきか | 理由 |
|---|---|---|
| 権限レビュー中の人事サイト | 使うべき | レビュー完了まで Copilot や agents での発見を抑えたい |
| 外部共有の棚卸し中の部門サイト | 使うべき | 過剰共有の有無を確認する時間を確保できる |
| 全社員向けポータル | 原則不要 | 発見性を下げると利便性が落ちる |
| 使われていない旧プロジェクト サイト | 状況次第 | まずアーカイブや削除も検討する |
| ナレッジ共有サイト | 慎重に判断 | agents の効果を下げる可能性がある |
実務では、Restricted Content Discovery を「恒久的な隠し設定」として使うよりも、「権限棚卸しが終わるまでの安全弁」として期限を決めて適用する方が運用しやすくなります。
Microsoft Purview DLP で agents に使わせたくないファイルを制御する
機密ファイルを agents の回答に使わせたくない場合、Microsoft Purview Data Loss Prevention、つまり DLP も選択肢になります。公式ドキュメントでは、秘密度ラベルと DLP を組み合わせ、条件として「Content contains > Sensitivity labels」を使うことで、選択したファイルが agents によって処理されないようにできると説明されています。(Microsoft Learn)
一方で、現時点では .agent ファイルそのものに秘密度ラベルを直接追加することはできないとされています。.agent ファイルを DLP で管理したい場合は、秘密度ラベル条件ではなく、.agent 拡張子に基づく条件を使う必要があります。(Microsoft Learn)
この点は、管理者が誤解しやすいポイントです。秘密度ラベルを付けたドキュメントの保護と、agent ファイル自体の管理は分けて考える必要があります。
DLP で考えるべき設計
| 保護したい対象 | 推奨される考え方 |
|---|---|
| 機密ドキュメント | 秘密度ラベルを付与し、DLP ポリシーで agents の処理対象から除外する |
.agent ファイル | 拡張子 .agent を条件にした DLP ルールや監視を検討する |
| 外部共有ファイル | 外部共有制御と DLP を組み合わせる |
| 部門限定資料 | サイト権限、Restricted Access Control、DLP を併用する |
DLP は「最後の防波堤」として有効ですが、DLP だけに頼るべきではありません。SharePoint 権限、サイト設計、ライフサイクル管理、エージェントの公開範囲を合わせて設計することが重要です。
サイト所有者ができること：メイン agent の管理
SharePoint で作成した agents は、自動的に一覧や公開場所に表示されるわけではありません。ユーザーは Word や Excel ファイルを開くように .agent ファイルへ移動して利用できます。さらに、サイト所有者はサイトのメイン agent を選択でき、その agent はグローバル ヘッダーの Agent アイコンから開かれます。(Microsoft Learn)
この仕様から、サイト所有者の役割も重要になります。管理者が全体のポリシーを設計しても、各サイトでどの agent をメインにするか、古い agent を残すか、誰に編集を許すかは運用上のリスクになります。
サイト所有者には、最低限次のルールを周知しておくとよいでしょう。
| ルール | 理由 |
|---|---|
| 本番用 agent と検証用 agent を分ける | 誤って未検証の agent を利用されるのを防ぐ |
| agent の説明文に用途と対象者を書く | 利用者が目的に合わない agent を使うのを防ぐ |
| 参照先サイト・ライブラリを記録する | トラブル時に影響範囲を確認しやすい |
| 編集者を限定する | プロンプトや参照先の意図しない変更を防ぐ |
| 不要な agent は削除またはアーカイブする | 利用者の混乱と管理漏れを減らす |
Copilot Chat で使われる agents は Microsoft 365 管理センターでも管理する
SharePoint 上の agents は、Microsoft 365 Copilot Chat から利用される場合もあります。公式ドキュメントでは、テナント管理者と AI 管理者が Microsoft 365 管理センターの Copilot Control System の Agents セクションで、Copilot Chat で利用された SharePoint agents を確認し、必要に応じてブロックまたはブロック解除できると説明されています。(Microsoft Learn)
ただし、ここにも制限があります。現時点で agent のブロックが影響するのは Copilot Chat での可用性であり、OneDrive、SharePoint、Teams にはまだ適用されないとされています。(Microsoft Learn)
つまり、Microsoft 365 管理センターで agent をブロックしたからといって、SharePoint 内での利用まで完全に止まるとは限りません。SharePoint 側の .agent ファイル権限やサイト設定も同時に確認する必要があります。
設定変更で特に注意すべきポイント
SharePoint agents のアクセス管理では、設定変更の影響が複数サービスに広がることがあります。特に次の点は、変更前に関係者へ説明しておくべきです。
| 変更内容 | 期待する効果 | 注意点 |
|---|---|---|
| Microsoft 365 Copilot for SharePoint のサービス プランをオフ | ユーザー単位で SharePoint agents を抑止 | OneDrive Copilot と SharePoint ページ作成 Copilot も無効になる |
| 従量課金ポリシーをセキュリティ グループに割り当て | Copilot ライセンスなしユーザーの利用を制御 | Azure 課金とコスト監視が必要 |
.agent ファイル権限を変更 | 個別 agent のアクセス・編集を制御 | 共有リンクやライブラリ権限の継承を確認する |
| Restricted Access Control を適用 | 指定グループ以外のサイトアクセスを制限 | 通常の権限と制限グループの両方が必要 |
| Restricted Content Discovery を適用 | Copilot や検索での発見を一時的に抑制 | 既存権限は変わらず、使いすぎると検索・AI回答の質に影響する |
| Microsoft 365 管理センターで agent をブロック | Copilot Chat での利用を止める | SharePoint、OneDrive、Teams にはまだ適用されない |
移行期限はあるのか
2026年6月25日に更新された「Manage access to agents in SharePoint」自体には、SharePoint agents のアクセス管理に関する明確な移行期限は示されていません。したがって、現時点で読み取れる対応は「期限付きの強制移行」ではなく、既存環境の設定を見直し、必要に応じて新しい管理方法へ整理することです。(Microsoft Learn)
ただし、従量課金については注意が必要です。別の公式ドキュメントでは、既存の SharePoint agents の従量課金ポリシーを Org settings 配下で設定している場合、新しい課金ポリシーの更新を利用するには、既存ポリシーを切断してから新しいポリシーに SharePoint agents を接続する必要があると説明されています。(Microsoft Learn)
また、新しい従量課金ポリシーでは、セキュリティ グループごとにポリシーを割り当て、グループごとにコストを監視できること、SharePoint agents にアクセスできるのは課金ポリシーに割り当てられたセキュリティ グループのユーザーだけであることが示されています。(Microsoft Learn)
移行が必要になりやすいケース
| 現在の状態 | 対応方針 |
|---|---|
| Copilot ライセンスユーザーだけが agents を使う | ライセンスとサービス プラン、SharePoint 権限を確認する |
| Org settings 配下で古い従量課金を設定済み | 新しい課金ポリシーへの移行を検討する |
| 部門別にコストを見たい | セキュリティ グループ単位の課金ポリシー設計に変える |
| 誰が agents を使っているか把握できない | Microsoft 365 管理センターの Agents 管理と SharePoint の .agent ファイル棚卸しを行う |
| 機密サイトが多い | Restricted Access Control や Restricted Content Discovery の適用候補を整理する |
移行期限が明記されていないからといって、対応を後回しにするのは危険です。特に従量課金や権限整理は、利用が広がってから変更すると、コスト配賦や業務影響の調整が難しくなります。
管理者が今すぐ確認すべきチェックリスト
SharePoint agents の更新ポイントを踏まえると、管理者は次の順序で確認すると効率的です。
まず確認すること
| チェック項目 | 確認方法の例 |
|---|---|
| Microsoft 365 Copilot ライセンスの割り当て範囲 | Microsoft 365 管理センターで対象ユーザーと部門を確認 |
| Microsoft 365 Copilot for SharePoint サービス プラン | 無効化しているユーザーがいないか、影響範囲を確認 |
| 従量課金ポリシーの有無 | Copilot の Billing & usage、Azure サブスクリプションを確認 |
SharePoint agents の .agent ファイル | サイト・ライブラリ単位で棚卸し |
| 機密サイトの権限状態 | 人事、経理、法務、経営層関連サイトから優先確認 |
| Restricted Content Discovery の適用候補 | 権限レビュー中のサイトをリスト化 |
| Microsoft 365 管理センターの Agents 一覧 | 共有 agent、利用済み agent、ブロック対象を確認 |
| DLP と秘密度ラベル | agents に処理させたくないファイルの条件を確認 |
30日以内に進めたい対応
| 対応 | 目的 |
|---|---|
.agent ファイルの命名規則を決める | 本番・検証・部門別の区別を明確にする |
| agent 所有者を明記する | 退職・異動時の管理漏れを防ぐ |
| 機密サイトのアクセス権を棚卸しする | agents 経由の過剰共有リスクを下げる |
| 従量課金の予算アラートを設定する | 想定外のコスト増を防ぐ |
| サイト所有者向けガイドを作る | 現場で無秩序に agent が増えるのを防ぐ |
| ブロック手順を決める | 問題のある agent を見つけた時に即応する |
よくある誤解と失敗しやすいポイント
「ユーザー権限を尊重するなら安全」と考えてしまう
SharePoint agents はユーザー権限を尊重します。しかし、権限が正しく設定されていないサイトでは、AI が問題を作るのではなく、既存の過剰共有を見つけやすくします。導入前に権限を棚卸ししないと、「Copilot や agents が情報を漏らした」と見えてしまうトラブルにつながります。
「agent をブロックすれば全サービスで止まる」と考えてしまう
Microsoft 365 管理センターでのブロックは、現時点では Copilot Chat での可用性に影響します。公式ドキュメントでは、OneDrive、SharePoint、Teams にはまだ適用されないと説明されています。(Microsoft Learn)
完全に利用を止めたい場合は、.agent ファイル権限、サイト設定、ライセンス、従量課金ポリシーを組み合わせて確認してください。
「Restricted Content Discovery を広く使えば安心」と考えてしまう
Restricted Content Discovery は便利ですが、Microsoft は過剰な利用に注意を促しています。使いすぎると、検索や Microsoft 365 Copilot の回答に使えるコンテンツが減り、結果の完全性や関連性に影響する可能性があります。(Microsoft Learn)
全社的に一律適用するのではなく、権限レビュー中の高リスクサイトに絞って使うのが現実的です。
「DLP で .agent ファイルに秘密度ラベルを付ければよい」と考えてしまう
現時点では、.agent ファイルに秘密度ラベルを直接追加することはできません。.agent ファイルを DLP で管理したい場合は、.agent 拡張子に基づく条件を使う必要があります。(Microsoft Learn)
ドキュメント本体の保護と、agent ファイルの管理は別の設計として扱いましょう。
実務でのおすすめ運用モデル
SharePoint agents を安全に展開するなら、最初から全社一斉に広げるよりも、段階的に運用モデルを作る方が失敗しにくくなります。
| フェーズ | やること | 成果物 |
|---|---|---|
| 準備 | Copilot ライセンス、従量課金、SharePoint 権限を確認 | 利用対象者リスト、課金設計、権限棚卸し表 |
| 検証 | 限定グループで agents を利用 | よく使う業務シナリオ、問題点、コスト目安 |
| ガバナンス設計 | .agent ファイル管理、命名規則、所有者ルールを決定 | agent 管理ルール、サイト所有者向け手順 |
| 機密サイト対策 | Restricted Access Control、Restricted Content Discovery、DLP を適用 | 高リスクサイト一覧、適用ポリシー |
| 展開 | 部門ごとに利用範囲を拡大 | 部門別展開計画、問い合わせ対応フロー |
| 定着 | 利用状況、コスト、ブロック対象を定期レビュー | 月次レビュー、改善リスト |
特に日本企業では、SharePoint サイトが部門ごとに長期間運用され、過去の共有リンクや所有者不在サイトが残っていることがあります。SharePoint agents の導入は、AI 活用プロジェクトであると同時に、SharePoint 情報整理のきっかけでもあります。
まとめ：SharePoint agents の管理は「AI 設定」ではなく「情報ガバナンス」として見る
2026年6月25日に更新された「Manage access to agents in SharePoint」の重要点は、SharePoint agents のアクセス管理が、ライセンスだけでは完結しないことです。管理者は、Microsoft 365 Copilot ライセンス、従量課金ポリシー、.agent ファイル権限、SharePoint サイト権限、SharePoint Advanced Management、DLP、Microsoft 365 管理センターの Agents 管理を組み合わせて設計する必要があります。(Microsoft Learn)
まず取り組むべきことは、SharePoint agents の利用を止めることではありません。どのユーザーが使えるのか、どのサイトを参照できるのか、どの agent が存在するのか、どのサイトが過剰共有のリスクを持つのかを見える化することです。
次のアクションとしては、Copilot ライセンスと従量課金ポリシーを確認し、.agent ファイルを棚卸しし、人事・経理・法務などの高リスクサイトから権限レビューを始めてください。そのうえで、必要なサイトに Restricted Access Control や Restricted Content Discovery、DLP を適用すれば、SharePoint agents を業務効率化と情報保護の両方に活かしやすくなります。
コメント