Copilot Studioを使えば、専門知識がなくてもチャットボットを数時間で作成できます。しかし「誰でも簡単に作れる」ことは、情報システム部門にとっては新たなリスクの入り口でもあります。社内の機密情報が外部に送信されたり、退職者が作成したボットが野良稼働し続けたりするケースは、実際の企業でも起き始めています。
本記事では、Copilot Studioを全社展開する前に情シス担当者が押さえておくべきセキュリティ・ガバナンス設計を、DLPポリシー・データソース制御・監査ログ・作成権限の4つの観点から具体的に解説します。

想定読者

本記事は、次のような方を想定しています。

• Copilot Studioの全社展開・PoC拡大を検討している情報システム部門の担当者
• 「野良ボット」「シャドーIT」化を懸念しているセキュリティ管理者
• Power Platform管理センターの設定にまだ慣れていない管理者
• 既にCopilot Studioを試験導入したが、ガバナンスルールを後付けで整備したい方
• 監査対応・情報セキュリティ規程の観点でCopilot Studio導入の説明責任を求められている方

---

1. なぜCopilot Studioにガバナンス設計が必要なのか

Copilot StudioはMicrosoft Power Platformのローコード基盤上に構築されており、Power Automateと同様に「作成のハードルが低い」ことが最大の魅力です。一方でこの手軽さは、情シス部門が把握していないボットが社内のあちこちで作られる「シャドーIT化」のリスクと表裏一体です。

具体的には、次のような事態が起こり得ます。

• 現場担当者が良かれと思って作成したボットが、社外のSaaSに顧客データを自動送信する設定になっていた
• 退職した社員が個人アカウントで作成したボットが、権限を引き継がれないまま稼働し続ける
• 複数部署が同じテーマのボットを別々に作成し、回答内容が食い違う「情報の二重管理」状態になる
• ボットが参照する社内文書に人事情報や取引先の機密情報が混在しており、想定外の相手に開示されてしまう

Power Automateのガバナンスでは主に「フローが誤って重要データを更新・削除しないか」が焦点でしたが、Copilot Studioは生成AIが会話の中でどこまで情報を引き出し、誰に開示するかという新しい種類のリスクを扱う必要があります。従来のRPAガバナンスの延長線上ではなく、AI特有のリスクとして設計し直すことが重要です。

2. DLP（データ損失防止）ポリシーの設計と設定手順

DLP（Data Loss Prevention）ポリシーは、Copilot StudioやPower Automateが「どのコネクタ同士でデータをやり取りしてよいか」を制御する、ガバナンスの根幹となる機能です。設定はPower Platform管理センターで行います。

DLPポリシーの基本的な考え方

DLPポリシーでは、利用可能なコネクタを次の3グループに分類します。

1. 業務データ（Business）グループ → 社内システム・Microsoft 365関連のコネクタ（SharePoint、Dataverse、Outlookなど）
2. 非業務データ（Non-Business）グループ → 個人向けSNSや外部の汎用サービスなど
3. ブロック（Blocked）グループ → 利用を一切禁止するコネクタ

同じポリシー内で「業務データ」グループと「非業務データ」グループのコネクタを組み合わせたフロー・ボットは作成できなくなるため、たとえば「社内SharePointの情報を個人のGoogleドライブに転送する」といった組み合わせを構造的にブロックできます。

設定手順（概要）

1. Power Platform管理センター（admin.powerplatform.microsoft.com）にテナント管理者としてサインインする
2. 「ポリシー」→「データポリシー」から新規ポリシーを作成する
3. 適用範囲を「環境単位」で指定する（全社一律ではなく、Copilot Studio用の検証環境と本番環境で段階的に適用するのが安全）
4. 利用するコネクタを「業務データ」「非業務データ」「ブロック」の3グループに振り分ける
5. 生成AI系コネクタ（HTTP呼び出しを伴うカスタムコネクタなど）は原則ブロックし、必要な場合のみ個別に許可申請させる運用にする
6. 保存後、対象環境で違反するボット・フローがないか「ポリシーの影響を受けるフロー」画面で確認する

ありがちな失敗は、最初から全社一律の厳格なDLPポリシーを適用してしまい、現場のボット作成が止まってしまうケースです。まずは検証環境で緩めのポリシーから始め、実際の利用状況を見ながら段階的に締めていく進め方をおすすめします。

3. データソースの制御とセンシティビティラベル

Copilot Studioの回答精度と安全性は、接続するデータソースの管理状態に大きく左右されます。DLPがコネクタ間の「動線」を制御するのに対し、ここでは「どのデータをボットに読ませるか」自体を制御します。

データソース整備の3原則

• 参照範囲を最小化する：ボットには部署全体のSharePointサイトをまるごと接続するのではなく、必要なフォルダ・リストだけに絞って接続する
• 機密度の高い文書を除外する：人事評価、給与、契約書、取引先の個人情報が含まれる文書は、専用の分離されたライブラリに格納し、ボットの参照対象から明確に外す
• Microsoft Purviewのセンシティビティラベルを活用する：機密文書に「社外秘」「限定公開」などのラベルを付与しておくことで、Copilot Studio側でもラベルに応じたアクセス制御が働く

「ボットは元データのアクセス権限を継承する」という原則

見落とされがちですが、Copilot Studioのボットは基本的に利用者本人が元々アクセスできる範囲のデータしか回答に使えません（ユーザーコンテキストでの認証を使う設定の場合）。逆に言えば、ボット側の権限設定を誤って「サービスアカウント経由で全データにアクセス可能」にしてしまうと、本来閲覧権限のない社員にも機密情報が渡ってしまうリスクがあります。認証方式が「ユーザー本人の権限で検索するか」「管理者権限で一括検索するか」を必ず確認し、後者を選ぶ場合は参照データソースを厳格に絞り込んでください。

4. 作成権限・公開範囲の管理

「誰でも簡単にボットを作れる」ことは長所であると同時に、管理者にとっては統制すべき対象です。

作成権限を絞る

既定では、ライセンスを持つユーザーは誰でも環境内にCopilot Studioのボットを作成できます。全社展開の初期段階では、作成権限を「Power Platform管理者」または特定のセキュリティグループに限定し、申請制で環境を払い出す運用が安全です。Power Platform管理センターの環境設定から、DLPポリシーと同様に環境単位でメーカー権限を制御できます。

公開範囲を用途ごとに整理する

ボットの公開範囲は用途によって明確に分けて管理します。

1. 社内限定（Teamsチャネル配布） → 情シス問い合わせボット、経費精算案内ボットなど
2. 特定部署限定（チーム内のみ） → 部署固有の業務マニュアル参照ボットなど
3. 社外公開（Webサイト埋め込み） → 顧客向けFAQボットなど、公開前に必ずセキュリティレビューを実施

社外公開するボットは、社内限定ボットとは別のDLPポリシー・データソース制御を適用し、誤って社内限定の情報が混入しないよう環境自体を分離することを推奨します。

野良ボットを防ぐ棚卸しの仕組み

作成後の放置を防ぐため、四半期に一度など定期的に「稼働中のボット一覧」をPower Platform管理センターの分析ダッシュボードで棚卸しし、利用実績のないボットや作成者が退職済みのボットを洗い出す運用ルールを設けておくと安心です。

5. 監査ログでボットの利用状況を可視化する

Copilot Studioの利用状況は、Microsoft Purviewの監査ログおよびPower Platform管理センターの分析画面から確認できます。

確認できる主な項目

• ボットの作成・更新・削除の履歴（誰が・いつ・何を変更したか）
• 会話ログ（ユーザーがボットに送信した質問と回答内容）
• トピックのトリガー率・エスカレーション率（AIが回答できず人間に引き継いだ割合）
• DLPポリシー違反の検知履歴

監査ログ運用の実務ポイント

会話ログには機密情報が含まれる可能性があるため、閲覧権限を情報セキュリティ担当者・管理者に限定し、アクセスログ自体も記録しておくことが望ましいです。また、社内規程で個人情報を扱う業務にAIチャットボットを利用する場合は、監査ログの保存期間や開示請求への対応方針をあらかじめ情報セキュリティ委員会などで合意しておくと、後々のトラブルを避けられます。

エスカレーション率が高いトピックは、ボットの回答精度に課題がある可能性が高いため、定期的に監査ログを確認し、データソース側の整備につなげるPDCAサイクルを回すことも重要です。

よくある質問

Q. Copilot Studioのガバナンス設計は情シス部門だけで完結できますか？

A. DLPポリシーやアクセス権限の技術的な設定は情シス部門で対応可能ですが、「どの情報を社外秘とするか」「どの業務にAIチャットボットの利用を許可するか」といった判断は、法務・情報セキュリティ委員会など全社的な合意形成が必要です。技術設定と運用ルールの両輪で進めることをおすすめします。

Q. 小規模なPoC段階でもDLPポリシーは必要ですか？

A. PoC段階であっても、実際の社内データに接続する場合はDLPポリシーの設定を推奨します。PoCで許容してしまった構成がそのまま本番展開されるケースは多く、後から締め直す方が手間がかかります。

Q. Copilot StudioとMicrosoft 365 Copilotでガバナンスの考え方は違いますか？

A. Microsoft 365 Copilotは既存のMicrosoft 365内のデータ・権限体系をそのまま利用するのに対し、Copilot Studioは独自にボットを作成しデータソースを接続する自由度が高い分、ガバナンス設計の主体的な検討がより重要になります。

Q. 既存のPower Automateで運用しているDLPポリシーをそのまま流用できますか？

A. 環境が同じであればDLPポリシーは共有されますが、Copilot Studio特有のAIコネクタ・生成AI関連のコネクタについては、既存ポリシーで想定されていないケースが多いため、棚卸しと見直しをおすすめします。

Q. ガバナンス整備にどのくらいの期間がかかりますか？

A. DLPポリシーの基本設計だけであれば1〜2週間程度で着手可能ですが、データソースの棚卸し・センシティビティラベルの整備を含めると、部署の規模により1〜3ヶ月程度を見ておくと現実的です。

まとめ

本記事のポイントをまとめます。

• Copilot Studioは作成が容易な分、シャドーIT化・情報漏洩のリスクを構造的に防ぐガバナンス設計が不可欠
• DLPポリシーはPower Platform管理センターで環境単位に設定し、検証環境から段階的に締めていく
• ボットが参照するデータソースは範囲を最小化し、機密文書はセンシティビティラベルで保護する
• 作成権限・公開範囲を用途ごとに整理し、定期的な棚卸しで野良ボットを防ぐ
• 監査ログを定期的に確認し、AI特有のリスクに対応したPDCAサイクルを回す

Copilot Studioのセキュリティ・ガバナンス設計でお困りの際は、ぜひc3indexにご相談ください。

---

c3index に相談する

c3index は、基幹システム・保守・クラウド移行を専門とするシステム会社です。
Power Automate / Copilot Studioの導入実績を活かし、ガバナンス設計から運用定着まで一貫してご支援します。まずはお気軽にお問い合わせください。