Copilot Studioのセキュリティはどう考える？責任あるAIとリスク管理の基本

Copilot Studioのセキュリティを考えるときは、回答内容だけでなく、利用する情報、公開範囲、接続先、実行権限まで確認する必要があります。

社内規程を検索するエージェントと、顧客情報を使って登録・更新まで行うエージェントでは、誤回答や誤処理が起きた場合の影響が異なります。そのため、一律の対策ではなく、利用目的とリスクに応じて必要な対策を選びます。

Microsoftは、責任あるAIの原則として、信頼性と安全性、プライバシーとセキュリティ、透明性、アカウンタビリティなどを掲げています。これは、NIST AI RMF、ISO/IEC 42001、AI事業者ガイドラインにも共通する考え方です。

この記事では、責任あるAIとリスク管理の考え方をもとに、Copilot Studioで情報・利用者・接続先の範囲を決め、最小権限、環境分離、人による確認、失敗時の対応へ落とし込む方法を整理します。構成全体から確認したい場合は、先に「Copilot Studioの構成はどう決める？データ・処理・利用画面から考える設計の基本」をご覧ください。

目次

Copilot Studioのセキュリティを、責任あるAIとリスク管理から考える

Copilot Studioのセキュリティ対策を考えるときは、最初からすべての設定を厳しくするのではなく、エージェントの利用目的と、問題が起きた場合の影響を整理します。

たとえば、公開情報を案内するエージェントと、顧客情報を参照して業務システムへ登録するエージェントでは、必要な対策が異なります。後者では、情報漏えいだけでなく、誤登録、誤送信、権限の過剰付与なども考慮する必要があります。

Microsoftは、責任あるAIの原則として、次の6つを掲げています。

• 公平性
• 信頼性と安全性
• プライバシーとセキュリティ
• インクルーシブ性
• 透明性
• アカウンタビリティ

Copilot Studio向けの責任あるAIのガイダンスでも、アクセス制御、最小特権、監視・監査、人による確認、継続的な評価などが重視されています。

また、AIリスク管理の参考となる枠組みには、NIST AI RMF、ISO/IEC 42001、日本のAI事業者ガイドラインがあります。

それぞれ対象や目的は異なりますが、共通するのは、AIの利用目的、扱う情報、影響を受ける人、役割と責任を明確にし、リスクに応じた対策を継続的に見直すことです。

ただし、これらの原則や枠組みは、Copilot Studioの設定値を直接指定するものではありません。具体的な対策は、エージェントごとに次を確認して決めます。

• どの業務で利用し、問題が起きた場合に誰へ影響するか
• どの情報を参照・入力・保存するか
• 誰が利用し、誰が管理・公開するか
• どのTool・フロー・APIへ、どの権限で接続するか
• どの処理に人の確認を入れ、公開後に誰が監視・改善するか

社内FAQの検索だけを行う場合は、認証、Knowledgeのアクセス権、回答根拠の確認が中心になります。一方、顧客情報を使って登録・更新・通知まで行う場合は、最小権限、環境分離、人による確認、失敗時の停止や復旧まで必要です。

つまり、Copilot Studioのセキュリティでは、対策項目を一律に並べるのではなく、利用目的と影響を把握し、リスクに応じて必要な対策を選ぶことが重要です。

次の章では、この考え方を具体化するため、エージェントが扱う情報、利用者、接続先の範囲を整理します。

情報・利用者・接続先の範囲を決める

Copilot Studioのセキュリティ対策では、エージェントが何を参照し、誰が利用・変更し、どこへ接続するかを明確にします。確認する範囲が曖昧なままでは、Knowledgeのアクセス権、公開範囲、Toolの実行権限を適切に設定できません。

Knowledgeには、業務に必要な情報だけを設定します。情報源へ接続できることと、その情報をすべての利用者へ回答してよいことは別です。

利用者が本来持つアクセス権を超えて情報を取得しないか、古い文書や対象外の情報まで検索されないかを確認します。

会社・顧客情報を扱う場合は、情報区分だけでなく、利用目的、社内規程、契約・NDA上の条件も確認します。情報の利用可否を判断する方法は、「Copilotに会社や顧客の情報を入力して大丈夫？業務で判断するポイント」で詳しく整理しています。

利用・作成・公開できる人を決める

次に、エージェントを利用できる人だけでなく、作成・編集・公開できる人も決めます。

• 誰がエージェントを利用できるか
• 社内全体か、特定部署だけに公開するか
• 誰がKnowledgeやInstructionsを変更できるか
• 誰がToolや接続先を追加・変更できるか
• 誰が本番環境へ公開できるか

共同作成者や公開担当者を必要以上に増やすと、意図しない設定変更や接続先の追加が起きやすくなります。利用者の公開範囲だけでなく、作成・変更・公開の権限も分けて管理することが重要です。

Toolの接続先と資格情報を確認する

Tool、Power Automate、APIを利用する場合は、接続先と実行権限を確認します。

特に、利用者本人の接続で実行する場合と、作成者が設定した接続で実行する場合では、アクセス権の基準が変わります。作成者の接続を使う場合は、利用者が本来持たない権限を間接的に使う構成になっていないか確認します。

また、生成オーケストレーションによってAIがToolを選択できることと、そのToolへ強い実行権限を与えてよいことは別です。入力値の検証、Tool側の権限、人による確認を組み合わせて、影響範囲を抑えます。

Copilot Studioのセキュリティでは、設定を厳しくすること自体が目的ではありません。Knowledgeの参照範囲、利用・公開できる人、Toolの接続先と資格情報、処理結果の保存先を明確にし、必要な範囲だけを許可することが基本です。

次の章では、この範囲をもとに、最小権限、環境分離、人による確認、失敗時の対応を組み合わせます。

最小権限・環境分離・人の確認で影響範囲を抑える

情報・利用者・接続先を整理したら、誤操作や情報漏えいが起きた場合の影響を抑える対策を組み合わせます。

重要なのは、事故を完全になくそうとするだけではありません。問題が起きても影響を限定し、人が止め、確認し、復旧できる状態を作ることです。

必要な権限だけを与える

KnowledgeやTool、接続資格情報には、業務に必要な範囲だけの権限を設定します。

たとえば、データの参照だけを行うToolに、登録・更新・削除の権限まで与える必要はありません。利用者本人の権限で実行するのか、作成者が設定した接続を使うのかも確認します。

主に次の点を見直します。

• Knowledgeの閲覧範囲が広すぎないか
• Toolに不要な登録・更新・削除権限がないか
• 作成者の強い権限を利用者が間接的に使わないか
• エージェントの所有者や共同作成者が多すぎないか
• 接続情報を異動・退職後も適切に管理できるか

最小権限は、利用者の権限だけではなく、エージェント、Tool、接続、作成者の権限を一体として確認することが重要です。

開発・検証・本番環境を分ける

本番環境を直接変更すると、検証中の設定や接続が利用者へ影響する可能性があります。

そのため、可能な範囲で開発・検証・本番環境を分け、ソリューションや環境変数を使って接続先を管理します。

• 検証中のエージェントを本番利用者へ公開しない
• 検証環境へ本番の機密データを持ち込みすぎない
• 開発用と本番用の接続先を分ける
• 本番へ公開できる担当者を限定する
• DLPポリシーで不適切なコネクタの組み合わせを制限する

環境を分けるだけでは十分ではありません。接続先や資格情報が共通のままでは、検証操作が本番データへ影響する可能性があります。

重要な処理には人の確認を入れる

AIが処理を選択できることと、人の確認なしに実行してよいことは分けて考えます。

特に、次の処理には確認や承認を入れることを検討します。

• 顧客や社外への情報送信
• データの登録・更新・削除
• 金額や契約に関する処理
• 承認結果や重要な判断の確定
• 個人情報や機密情報を含む処理

AIには、必要な情報の収集や入力案の作成までを任せ、最終的な実行は人が確認する方法もあります。

すべての処理へ承認を入れると業務が遅くなるため、誤処理が起きた場合の影響と、取り消しや修正のしやすさを基準に判断します。

失敗時に停止・確認・復旧できるようにする

Toolやフローは、通信エラー、権限不足、入力値の不備などで失敗する可能性があります。

失敗を想定し、次を決めておきます。

• 利用者へ何を表示するか
• 管理者や担当者へどう通知するか
• 途中まで処理された内容を確認できるか
• 二重登録を防げるか
• 再実行、差し戻し、取り消しができるか
• 自動処理を停止し、人へ引き継げるか

失敗した処理を自動的に繰り返すだけでは、二重登録や重複通知につながる場合があります。再実行する前に、どこまで処理が完了したかを確認できる構成が必要です。

Copilot Studioのセキュリティ対策では、権限を絞るだけでなく、環境を分け、重要な処理を人が確認し、失敗時に影響を広げず復旧できる状態を作ることが重要です。

次の章では、責任あるAIとリスク管理の考え方を踏まえ、ここまでの確認事項を実務チェックリストとして整理します。

責任あるAIとリスク管理を、Copilot Studioの設計・運用へ落とし込む

責任あるAIやAIリスク管理の枠組みは、Copilot Studioの具体的な設定値を示すものではありません。一方、製品設定だけを確認しても、対象業務のリスクに合った対策かどうかは判断できません。

公開情報を案内するエージェントと、顧客情報を使って登録・更新・外部送信まで行うエージェントでは、必要な対策が異なります。

まず利用目的と影響を整理し、情報・利用者・接続先の範囲を明確にします。そのうえで、リスクに応じて最小権限、環境分離、人による確認、失敗時の対応を組み合わせます。

設計・公開・運用時には、次の項目を確認します。

すべてのエージェントへ、同じ強さの対策を適用する必要はありません。情報の機密性、処理内容、利用者、誤処理時の影響に応じて、必要な対策を選びます。

たとえば、社内FAQを検索するエージェントでは、認証、Knowledgeのアクセス権、回答根拠の確認が中心になります。一方、顧客情報を使って登録・更新するエージェントでは、最小権限、環境分離、人による確認、失敗時の停止・復旧まで必要です。

Copilot Studioのセキュリティでは、設定を厳しくすること自体が目的ではありません。利用目的と影響を把握し、扱う範囲を明確にしたうえで、問題が起きても影響を限定し、人が確認・停止・復旧できる状態を作ることが重要です。

また、公開後も権限、Knowledge、接続先、処理結果を定期的に確認します。責任あるAIとリスク管理の考え方を、設計時のチェックだけで終わらせず、運用と改善まで継続して反映します。