複数の生成AIサービスを併用する企業で統制設計が破綻する最大の原因は、「ベンダーごとの仕様差を無視して一律のルールで統制しようとする」ことです。生成AI併用の統制設計では、データ取扱ポリシー・管理者機能・監査ログの実装がベンダーごとに異なるため、統制装置を「どこに置くか」を仕様に合わせて分岐させる必要があります。この記事では、CopilotとChatGPT、Gemini、Claudeを例に、ベンダーごとに何が違い、その差が統制設計のどの判断に影響するかを整理します。
生成AI併用時の統制設計で分岐する3つの要素
企業が複数の生成AIサービスを併用する際、統制設計は次の3要素の仕様差によって分岐します。
データ取扱ポリシーの差
各ベンダーは、入力データを学習に利用するか、保存期間をどう設定するかについて異なるポリシーを持ちます。例えばMicrosoft 365 Copilotは、企業向けプランではテナント内データのみを参照し学習には利用しない設計ですが、ChatGPTの無償版では入力内容が学習に利用される可能性があります。GeminiやClaudeも、プランによって学習利用の有無や保存期間が変わります。
この差により、「どのサービスでどのレベルの情報を扱わせるか」という判断基準がベンダーごとに異なります。統制設計では、データの機密度分類とベンダーのデータ取扱ポリシーを対応させ、機密度の高いデータを扱うサービスと、検証・試行に留めるサービスを区別する必要があります。
管理者機能の差
ベンダーごとに提供される管理者コンソールの機能範囲は大きく異なります。Microsoft 365 Copilotは、Microsoft 365管理センターおよびPower Platform管理センターを通じて、ユーザーの利用状況・共有範囲・コネクタの接続先を管理者が一元的に制御できます。一方、ChatGPT EnterpriseやClaude for Workも管理者機能を提供しますが、制御の粒度や監査ログの詳細度はMicrosoftのエコシステムとは異なります。
この差により、「管理者が統制装置として何を使えるか」が決まります。例えば環境分離・コネクタDLP・公開承認フローといった統制装置は、ベンダーが提供する管理機能に依存します。管理機能が提供されないサービスでは、統制装置を技術的に置けないため、利用ガイドライン上の禁止事項として代替するか、利用範囲を限定する判断が必要になります。
監査ログの差
監査ログの取得範囲と粒度も、ベンダーごとに異なります。Microsoft 365ではMicrosoft Purviewを通じて操作ログ・共有ログを取得できますが、監査ロールの付与が必要であり、閲覧範囲がメール等まで及ぶ場合は社内承認が得られないケースもあります。ChatGPTやClaudeも、有償プランでは利用ログを提供しますが、「誰が誰に共有したか」といった操作記録の詳細度はベンダーによって異なります。
監査設計では「技術的に取得できるか」ではなく「その権限が社内で承認されるか」が決定要因になります。監査ログを統制装置として置けない場合、代替手段として外部の管理基盤へログを載せ替えるか、残存リスクとして記録する判断が必要です。
統制装置の「置き場所」をライセンス配布範囲に合わせる
統制装置の設計は、ライセンスの配布範囲という前提に依存します。例えばMicrosoft 365 Copilotの有償ライセンスが一部にしか配布されていない前提では、広く使われるエージェントをCopilot Studioへ昇格させ、環境分離・コネクタDLP・環境別クレジット割当・公開承認フローという統制装置を必ず通過させる設計が成立していました。
しかし有償ライセンスが対象組織のほぼ全員に配布された結果、全社展開の主経路は「Copilot Studioへ昇格」ではなく「Agent Builderのままギャラリーへ掲載」へ転換しました。Agent Builderは環境の概念を持たず、コネクタDLPの対象外であるため、Copilot Studio環境側に置いた統制装置の上を、全社展開の主経路が通らなくなりました。
具体的には、開発から本番への段階検証、コネクタDLPによる出口統制、環境別クレジット割当と上限到達時の自動停止、公開承認フロー、この4つが主経路に対して効かなくなりました。全社公開のゲートはギャラリー掲載に置き換わりましたが、その審査主体と基準は未定義であり、ガバナンス上の空白として残りました。
統制の思想（入口は止めず出口で締めるガードレール型）は変えず、装置の置き場所を「環境」から「人（セキュリティグループ）とデータ（権限・ラベル）」へ再配置する方針で組み替える必要があります。統制設計はライセンスの配布範囲という前提に依存しており、前提が変われば、統制の思想ではなく装置の置き場所を組み替えます。
ベンダーごとの仕様差を整理する観点
複数の生成AIを併用する統制設計では、ベンダーごとの仕様差を次の観点で整理します。
データ保存場所とテナント分離
Microsoft 365 Copilotは、テナント内のデータのみを参照し、他社のテナントと分離されています。一方、ChatGPTやGemini、Claudeの無償版・個人向けプランでは、入力内容が学習に利用される可能性があり、保存場所も企業が管理できる範囲外です。有償プランでは学習利用をオプトアウトできますが、その設定がデフォルトで有効かどうかはベンダーによって異なります。
統制設計では、テナント分離が保証されるサービスと、そうでないサービスを区別し、前者には機密度の高いデータの入力を許可し、後者には禁止または限定的な利用に留める判断を行います。
管理者が利用状況をどこまで把握できるか
Microsoft 365では、管理センターを通じてユーザーの利用状況・共有範囲・外部コネクタの接続先を一元的に把握できます。ChatGPT EnterpriseやClaude for Workも管理者機能を提供しますが、利用状況の可視化範囲や、共有の制御方法はMicrosoftのエコシステムとは異なります。
統制設計では、管理者が「誰が何をどこに共有したか」を把握できるサービスと、そうでないサービスを区別します。把握できない場合、利用ガイドライン上で「外部共有禁止」といった代替統制を置くか、利用範囲を限定する判断が必要です。
監査ログの取得範囲と承認可能性
監査ログの取得は、技術的な実装だけでなく、社内での権限承認が決定要因になります。Microsoft PurviewによるMicrosoft 365の監査ログ取得では、監査ロールの付与が必要ですが、メール等まで閲覧範囲が及ぶことが理由で社内承認が得られないケースがあります。
監査目的の大半は外部のエージェント管理基盤へ載せ替えることができますが、「誰が誰に共有したか」の操作記録だけは代替手段がなく、残存リスクとして記録する必要があります。監査設計は「技術的に取得できるか」ではなく「その権限が社内で承認されるか」で決まります。
一律ルールでは統制できない理由
「全社で一つの利用ガイドラインを作り、全てのサービスに適用する」という発想は、ベンダーごとの仕様差を無視するため機能しません。例えば「外部共有禁止」というルールを全サービスに適用しても、管理者が共有状況を把握できないサービスでは遵守を監視できず、ルールが形骸化します。
統制設計では、ベンダーごとに「技術的に統制装置を置けるか」を判断し、置けない場合は利用範囲を限定するか、代替統制を用意する必要があります。一律ルールではなく、「このサービスでは技術統制、このサービスでは利用範囲限定」というように、ベンダーごとに統制手段を分岐させる設計が必要です。
統制設計の分岐点をどこに置くか
複数の生成AIを併用する統制設計では、次の分岐点を明確にします。
機密度分類とサービスの対応付け
データの機密度分類（例：公開可・社外秘・機密）を定義し、各分類に対して「どのサービスで扱ってよいか」を対応付けます。テナント分離と学習オプトアウトが保証されるサービスには機密度の高いデータを許可し、そうでないサービスには公開可レベルのデータのみを許可するといった判断を行います。
統制装置が置けるサービスと置けないサービスの区別
管理者機能と監査ログの実装を確認し、「環境分離・コネクタDLP・公開承認フロー」といった統制装置を置けるサービスと、置けないサービスを区別します。置けないサービスでは、利用ガイドライン上の禁止事項として代替するか、利用範囲を限定する判断を行います。
ライセンス配布範囲と統制装置の置き場所の連動
ライセンスの配布範囲が変わると、統制装置の置き場所も組み替える必要があります。全社展開の主経路が「特定の環境を通過する」から「ギャラリー掲載」へ転換した場合、統制装置を「環境」から「人とデータ」へ再配置します。前提が変われば、統制の思想ではなく装置の置き場所を組み替えます。
ベンダーごとの統制設計を構造化する手順
複数の生成AIを併用する統制設計は、次の手順で構造化します。
- ベンダーごとのデータ取扱ポリシー・管理者機能・監査ログの実装を一覧化する。各サービスの公式ドキュメント（例：Microsoft 365 Copilot 導入とオンボード ガイド（IT管理者向け）、Anthropic Privacy Center（プライバシーセンター）、Anthropic Trust Center（セキュリティ・コンプライアンス情報）など）を参照し、学習利用の有無・保存場所・管理者機能の範囲・監査ログの粒度を整理します。
- データの機密度分類を定義し、各分類に対して利用を許可するサービスを対応付ける。機密度の高いデータは、テナント分離と学習オプトアウトが保証されるサービスのみに許可し、そうでないサービスには公開可レベルのデータのみを許可します。
- 統制装置を置けるサービスと置けないサービスを区別し、代替統制を設計する。管理者機能が提供されないサービスでは、利用ガイドライン上の禁止事項として代替するか、利用範囲を限定します。
- ライセンス配布範囲と統制装置の置き場所を連動させる。ライセンスの配布範囲が変わった場合、統制装置を「環境」から「人とデータ」へ再配置するなど、前提に合わせて組み替えます。
- 監査設計では、権限の社内承認可能性を先に確認する。監査ロールの付与が承認されない場合、代替手段として外部の管理基盤へログを載せ替えるか、残存リスクとして記録します。
- 検証、決定、手順書の順序を崩さない。決定を急がせる前に、検証結果を材料として先に出します。
未使用期間による削除基準が成立しない理由
「90日間未使用のエージェントを一律で削除する」といった基準は、一見すると管理の効率化に見えますが、実務では成立しません。半年に1回など低頻度で稼働するエージェントが存在するため、未使用期間による一律削除は成立しませんでした。この基準を撤回した理由は、稼働頻度がエージェントの価値を表さないためです。
統制設計では、削除基準を「未使用期間」ではなく「所有者の承認」や「定期レビュー」に置き換える必要があります。所有者が明示的に削除を承認しない限り、エージェントを自動削除しない設計が、低頻度稼働のエージェントを保護します。