ChatGPT・Claude・Microsoft Copilot別、各 AIの推奨セキュリティ設定米国・英国・イスラエルの公的ガイダンスから実装方法を整理|セキュリティ対策Lab

投稿日時: 2026年09月25日更新日時: 2026年09月25日

企業でChatGPT、Claude、Microsoft Copilotを利用する場合、法人契約へ切り替えるだけでは管理は完了しません。SSO、多要素認証、アカウントの入退社連携、外部サービスとの接続、データ保持、監査ログ、AIエージェントの操作権限まで設定して初めて、企業の情報システムとして管理できます。

米国CISA・NSA・FBI、英国NCSC、イスラエル国家サイバー局（INCD）などが共同策定した「Engaging with artificial intelligence」は、組織がAIを利用する際の対策として、フィッシング耐性のあるMFA、最小権限、第三者AIへ入力するデータの確認、ログ・監視、サプライチェーン評価、小規模な試行などを挙げています。

英国NCSCの「Guidelines for secure AI system development」も、AIが参照できるデータや実行できる操作を制限し、リスクの高い機能を必要な利用者だけへ提供する考え方を示しています。

イスラエル政府のResponsible AI Guide案では、外部AIへ保護情報を入力しないことや、外部AIと組織環境を自動接続する場合にはCISOやDPOなどへ相談し、承認を得ることが示されています。ただし、この資料は公共部門向けのパブリックコメント版で、民間企業への法的義務を示すものではありません。

これらの公的資料は「ChatGPTのLockdown Modeをオンにする」といった製品固有の設定値までは指定していません。本稿では、公的ガイダンスが示す原則と、OpenAI、Anthropic、Microsoftが現在提供する公式管理機能を対応付け、企業の初期設定として使える形に整理します。

対象は主にChatGPT Enterprise、Claude Enterprise、Microsoft Copilot／Microsoft Copilot Chatです。個人向けアカウントを機密業務で使う前提ではありません。

最初に設定したい10項目

項目	初期設定の考え方
業務アカウント	法人が管理するアカウントへ限定
SSO	有効化し、企業IdPへ統合
MFA	IdP側でフィッシング耐性のあるMFAを必須化
アカウント管理	SCIM等で入社・異動・退職と連動
権限	一般利用者・開発者・管理者を分離し最小権限
外部連携	Apps、MCP、Connectors、Agentsを許可制にする
書き込み操作	送信・更新・削除は必要な部署だけ許可し、可能なら承認を入れる
データ保持	法務・監査・インシデント調査の要件に合わせて期間を設定
監査ログ	SIEM、eDiscovery、調査で利用できる状態にする
Web・外部検索	機密性の高い部署では必要性を確認し、不要なら制限

この10項目は政府機関がそのまま提示している製品設定表ではありません。CISA、NSA、NCSC、INCD、NISTが示すMFA、最小権限、データ保護、監視、サプライチェーン、リスク管理を、各製品の管理機能へ落とし込んだ編集部の整理です。

米国・英国・イスラエルの公的資料から確認できる共通原則

フィッシング耐性のあるMFAをAIにも適用する

CISA、NSA、FBI、NCSC、INCDなどの共同ガイダンスは、AIシステムへのアクセスにフィッシング耐性のあるMFAを使用するよう示しています。例としてFIDO2セキュリティキーが挙げられています。

企業ではChatGPTやClaude側だけでMFAを設定するより、Microsoft Entra ID、Okta、Google WorkspaceなどのIdP側でパスキー、FIDO2、証明書などを強制すると、他のSaaSと同じポリシーで管理できます。

特にAI管理者、経営層、情報システム部門、顧客情報やソースコードへアクセスできる利用者は、パスワードだけで認証させない構成にします。

AIが見られる情報と実行できる操作を最小権限にする

共同ガイダンスは、need-to-knowとleast privilegeに基づいて特権アクセスを管理するよう示しています。

生成AIでは、利用者本人のファイル権限だけではなく、AIへ付与する次の権限を確認します。

メールを読む
SharePoint、OneDrive、Google Driveを検索する
SlackやTeamsを参照する
GitHubリポジトリを読む
ファイルを作成・更新する
メールを送信する
チケットを作成する
コードを変更する
外部APIを実行する

「参照できる」と「変更できる」は分けます。要約・検索だけが目的なら、書き込み、送信、削除まで許可する必要はありません。

外部AIへ入力する情報を分類する

共同ガイダンスは、第三者AIを利用する場合、入力がモデル再学習へ使われるか、どこで保存・処理されるか、契約終了後にデータがどう扱われるかを確認するよう求めています。

イスラエル政府のResponsible AI Guide案は、組織外の汎用AIに個人情報、機密情報、営業秘密、知的財産、法的秘匿情報などの保護情報を入力しないよう示しています。

民間企業では、自社の法人契約・DPA・保持設定・利用目的を踏まえ、例えば次のように区分できます。

情報区分	個人向けAI	法人契約AI
公開情報	条件付き利用	利用可
社内一般	原則利用しない	社内規程に基づき利用
顧客情報・個人情報	利用しない	契約・用途・アクセス権を確認して個別判断
営業秘密・重要ソースコード	利用しない	専用環境・最小権限で限定
パスワード・秘密鍵・認証トークン	入力しない	原則入力しない

コネクタやエージェントの自動接続は承認制にする

イスラエル政府のガイド案では、外部AIと組織の業務環境を自動接続する場合、CISO、DPO、AIリスク管理責任者などへ相談し、承認を得るよう示しています。

ChatGPT、Claude、Copilotでは、Apps、MCP、Connectors、Agentsを追加すると、AIが組織データへ直接アクセスしたり、外部サービスで操作したりできます。

一般利用者が自由に接続先を増やせる構成より、利用部門の申請、情報システム・セキュリティ部門による権限確認、少人数での試行、ログ確認という流れを設けます。

小規模に試行し、ログを取れる状態で展開する

共同ガイダンスは、本格導入前に低リスク環境でAIを試行し、ファイアウォール、EDR、ログ監視など既存のセキュリティ基盤と統合できるか確認する方法を示しています。

NCSCも、AIのアクセス制御、監査ログ、インシデント対応、継続監視をライフサイクル全体で扱うよう示しています。

全社員へ一斉配布するより、少人数、読み取り専用、外部連携を絞った状態から開始し、設定と運用が確認できてから対象を広げます。

ChatGPT Enterpriseで確認したい設定

OpenAIはChatGPT Enterpriseの管理者向けクイックスタートで、広く利用者を招待する前にSSO・SCIM、ロール、Workspace設定、Apps、GPTs、Connectors、Codex、Work、監査・コンプライアンス機能を確認する流れを案内しています。

SSOとSCIMを全社展開前に設定する

企業では次の順序にすると管理しやすくなります。

企業ドメインを検証
SAML SSOを有効化
IdP側でフィッシング耐性MFAを必須化
SCIMでユーザー作成・無効化を自動化
退職者のアクセスを人事マスターと連動して停止
Owner／Adminを必要最小限にする

ChatGPT EnterpriseではSCIMとカスタムRBACを利用できます。OpenAI自身も、広範なオンボーディングより前にSSO・SCIMを設定する流れを案内しています。

RBACでCodex・Work・Agentsを全社員へ開放しない

Enterpriseのカスタムロールでは、ChatGPT Work、Codex、接続ツール、Workspace Agentsなどをグループ単位で制御できます。

初期設定のモデル例は次の通りです。

利用者	Chat	Web	Apps	Work	Codex／Agent
一般社員	許可	業務に応じて	承認済みのみ	原則無効	無効
管理部門	許可	必要に応じ制限	承認済みのみ	個別許可	無効
開発者	許可	許可	GitHub等限定	必要時	許可
高機密部門	許可	制限を検討	最小限	原則無効	個別判断

これはOpenAIの既定値ではなく、最小権限を適用するためのモデル例です。

Apps・GPTs・MCP・コネクタを許可制にする

外部連携では、接続先だけでなくOAuth Scopeと「読む／書く」の違いを確認します。

特に、メール送信、ファイル更新、GitHubへの書き込み、外部API実行などは、一般利用者へ一律に許可せず、必要なグループへ限定します。

新しいAppsやMCPを追加する際は、データ送信先、第三者の保持条件、管理者が停止できるか、監査ログを取得できるかまで確認します。

高機密部門ではLockdown Modeを検討する

OpenAIはChatGPT Enterpriseのセキュリティ設定としてLockdown Modeを案内しています。Web検索、ブラウジングなどネットワーク接続を伴う機能を強く制限したいチームで利用できます。

全社へ一律適用するより、M&A、法務、経営企画、研究開発、未公開財務情報、インシデント対応など、外部通信の必要性が低くデータ機密性が高い部署で適用を検討します。

IP Allowlistingはネットワーク設計と合わせて使う

固定の社内出口IP、VDI、SASEなどを利用している場合、ChatGPT EnterpriseのIP Allowlistingにより、認証情報が漏れた場合でも許可IP以外からのアクセスを制限できます。

一方、在宅勤務やモバイル回線、海外出張で送信元が頻繁に変わる企業では運用負荷が上がります。利用可能だから有効にするのではなく、自社のアクセス経路と合わせます。

Compliance Platformを監査へ接続する

OpenAIはEnterprise向けにCompliance Logs PlatformやStateful Compliance APIを提供しています。

SIEM、eDiscovery、DLPなどへ連携する場合は、平時から次を確認できるようにします。

管理者・ロール変更
新しいApps・Connectors
GPT／Agentの共有
Codex・Workの利用
退職者アカウントの残存
異常な利用量や外部連携

保持期間・データレジデンシーを契約時に決める

ChatGPT Enterpriseでは対象契約でデータ保持、データレジデンシー、推論レジデンシー、Enterprise Key Managementなどを利用できます。

「日本リージョンを選んだので、すべての処理とログが日本だけに残る」と単純化せず、保存、推論、セキュリティログを分けて確認します。

OpenAIはChatGPT Enterpriseなどの法人向けデータを、標準ではモデル学習へ使用しないとしています。

Claude Enterpriseで確認したい設定

Claude EnterpriseではSSO、SCIM、カスタムロール、Connector／MCP権限、監査ログ、Compliance API、カスタム保持期間などを利用できます。

Domain Verification・SSO・SCIMを先に設定する

導入時は次を確認します。

企業ドメインを検証
SSOを有効化
IdP側でフィッシング耐性MFAを必須化
SCIMでアカウントライフサイクルを自動化
Owner／Primary Ownerを必要最小限にする

SSOだけを導入し、退職者削除が手作業のままだと運用漏れが残ります。

Custom RolesでClaude Code・Web Search・Connectorsを分ける

Claude EnterpriseのCustom Rolesでは、機能や管理権限、Connector、モデルアクセスをグループ単位で制御できます。

全社員にClaude Codeや外部Connectorを許可する必要はありません。

開発者だけClaude Codeを許可し、営業は承認済みクラウドストレージのみ、法務はWeb Searchを制限するといった設計が可能です。

Connectorは「Always allow」を安易に設定しない

AnthropicのConnector権限には、Always allow、Needs approval、Blocked、Customがあります。

新規ロールではConnectorがNeeds approvalで開始します。高リスクな書き込み系操作はNeeds approvalまたはBlockedから始めます。

注意点として、AnthropicはConnector権限機能が有効化された際、既存Custom Roleが「All connectors / Always allow」で初期化される場合があると案内しています。導入済み組織では有効化後に全ロールを再確認します。

MCP・組織コネクタは企業IdP経由で管理する

Enterprise-managed authenticationを利用できる環境では、管理者が利用可能なMCP Connector、対象ロール、OAuth Scopeを管理できます。

個人Googleアカウントや個人Slackを自由に接続させるより、企業IdPと組織管理されたConnectorへ寄せます。

また、企業ドメインのConnectorを個人Claudeアカウントへ接続させない制御も確認対象です。

Plugin・Skillを組織管理し、スキャン機能を使う

Claude Enterpriseでは組織管理のPlugin／Skill機能とスキャン機能を利用できます。

企業では、利用者がGitHubなどから不明なPluginやSkillを個人判断で追加する運用を避け、承認済みのライブラリへ寄せます。

カスタム保持期間を設定する

Claude EnterpriseではChatとProjectにカスタム保持期間を設定でき、現行の最短期間は30日です。設定しない場合はデータが無期限に保持されるため、導入時に自社の監査・法務要件と合わせます。

AnthropicのZero Data RetentionはAPI等の別条件で提供される仕組みで、Claude for Workへ自動的に適用されるものではありません。契約名だけで判断せず、対象製品を確認します。

Anthropicは法人向けClaude for Work等の入力・出力を、標準ではモデル学習へ使用しないとしています。ただし、利用者が明示的にフィードバックを送る場合などは別条件があります。

Audit LogsとCompliance APIを監査対象にする

最低限、次の変更を監査します。

SSO・SCIM設定
管理者ロール
Connector／MCP追加
Plugin・Skill追加
保持期間変更
退職者のアカウント
異常な利用状況

Microsoft Copilotで確認したい設定

Microsoft CopilotはMicrosoft 365のアクセス権やSensitivity Label、保持・監査ポリシーを引き継ぎます。

そのため導入時の中心は「Copilotだけの設定」ではなく、SharePoint、OneDrive、Teams、Entra ID、Purviewを先に整えることです。

SharePoint・OneDriveの過剰共有を先に修正する

MicrosoftはCopilot導入の基盤整備として、最初にoversharingを修正する手順を案内しています。

確認対象は次の通りです。

Everyone Except External Users
Anyone Link
全社共有サイト
所有者不明サイト
長期間利用されていないサイト
権限継承が崩れたフォルダ
機密情報を含む広範囲共有

Copilotが新しい権限を勝手に付与するわけではありません。しかし、利用者が以前から見られたものの把握していなかったファイルを検索・要約しやすくするため、既存の過剰共有が表面化します。

Restricted Access Controlなどで修復中のサイトを囲う

Microsoftは、重要サイトにRestricted Access Controlを設定し、会社全体の共有グループやAnyoneリンクを制限することを推奨する導入ガイダンスを公開しています。

すぐに全サイトの権限修正が終わらない場合でも、高リスクなサイトから制限します。

Purview Sensitivity LabelとDLPをCopilotへ適用する

Microsoft CopilotはPurviewのSensitivity Labelやアクセス制御を引き継ぎます。

導入前に、Public、Internal、Confidential、Highly Confidentialなど自社の分類を整えます。

DLPでは、特定の機密データやConnectorがCopilot／Agent経由で処理・送信されないよう制御できます。ユーザー自身が閲覧できても、AIで処理させる必要がない情報は別に制限する考え方が使えます。

Entra IDでConditional Accessとフィッシング耐性MFAを設定する

Microsoft CopilotはMicrosoft Entra IDを利用するため、次を既存ポリシーへ組み込みます。

MFA必須
パスキー／FIDO2等のフィッシング耐性認証
高リスクユーザーの制御
Intune準拠端末の要求
管理者・高権限ユーザー向けの強いConditional Access

Copilotだけ別の弱い認証にしないことがポイントです。

Web Searchは部署別に制御する

Microsoftは「Allow web search in Copilot」ポリシーを提供しており、ユーザー／グループ単位でWeb検索を制御できます。

現行では次の選択肢があります。

CopilotとCopilot Chatの両方で有効
両方で無効
Copilot Work modeでは無効、Web mode／Copilot Chatでは有効

法務、M&A、機密研究などではWork modeのWeb検索を無効化し、調査・マーケティング部門では許可するなど、業務別に分けられます。

Copilot StudioのAgent・ConnectorをDLPで制御する

Copilot StudioのData Policyでは、ConnectorをBusiness／Non-business／Blockedへ分類できます。

さらに、

未認証Agent
外部Knowledge Source
HTTPリクエスト
Skills
外部チャネル
Event Trigger

などを制限できます。

特にEvent Triggerは人間の操作なしでAgentが外部イベントへ反応するため、業務上必要なものだけへ限定します。

Purview Audit・eDiscoveryで調査できる状態にする

Copilotの利用はPurview Audit、eDiscovery、保持ポリシーなど既存Microsoft 365のガバナンスへ統合できます。

インシデント時に、誰が、どのCopilot／Agentを使い、どの情報へアクセスしたかを確認できる状態にします。

Microsoftは法人向けCopilotのプロンプト、応答、Microsoft Graphから参照したデータを基盤モデルの学習に使用しないとしています。

3製品の設定比較

管理項目	ChatGPT Enterprise	Claude Enterprise	Microsoft Copilot
法人データの基盤モデル学習	標準で使用しない	標準で使用しない	使用しない
SSO	対応	対応	Entra ID
SCIM／アカウント自動管理	対応	対応	Entra ID／Microsoft 365
カスタム権限	RBAC	Custom Roles	Entra／M365／各サービス権限
外部連携制御	Apps、GPTs、MCP、Connectors	Connectors、MCP、Plugins、Skills	Connectors、Agents、Copilot Studio
高リスク操作	ロール・機能制御	Approval／Blocked等	DLP・Agent Policy
Web検索制限	Lockdown Mode等	Custom Role等	Web Search Policy
監査	Compliance Platform/API	Audit Logs／Compliance API	Purview Audit／eDiscovery
データ保持	Enterprise設定・契約	Custom Retention、最短30日	Purview Retention
高機密向けの主な制御	Lockdown Mode、IP制限等	Connector・Web・Code権限制限	DLP、RAC、Sensitivity Label等

製品機能は2026年9月23日時点です。契約、地域、ライセンス、段階提供によって利用可否が異なるため、導入時に管理画面と契約条件を確認してください。

600～規模では4グループ程度から始める

従業員600人以上の企業で、部署ごとに細かい例外を大量に作ると運用が複雑になります。

最初は次の4グループ程度へ分ける方法があります。

グループ	対象例	設定例
標準利用	一般社員	Chat・要約・翻訳、承認済みWeb検索
情報接続利用	営業、人事、企画	承認済みコネクタのみ、書き込みは個別許可
開発利用	エンジニア	GitHub、Claude Code、Codex等を限定許可
高機密利用	法務、M&A、経営、R&D	Web・外部連携制限、強いMFA、保持期間を個別設定

IdPのグループと連動させると、異動時の設定変更も行いやすくなります。

「Enterpriseだから安全」ではなく、外部連携追加のたびに再評価する

ChatGPT Enterprise、Claude Enterprise、Microsoft Copilotはいずれも法人向けのデータ保護・管理機能を備えています。

一方、導入後にApps、MCP、GitHub、Slack、SharePoint、メール、Agentsを追加すると、AIが扱える情報と操作は拡大します。

新しい連携を追加するたびに、次を確認します。

何のデータを読むか
何を書き込めるか
誰の権限で動くか
どこへ通信するか
操作ログを残せるか
管理者が即時停止できるか

NCSCはAIが外部システムで操作を実行する場合、可能なアクションを制限し、必要に応じてAI外部のフェイルセーフも設けるよう示しています。

プロンプトインジェクション対策はモデル任せにしない

ChatGPT、Claude、Copilotはいずれもプロンプトインジェクション対策を実装していますが、企業の設定まで不要になるわけではありません。

Web、メール、GitHub、外部文書などをAIへ読ませる場合、そこに攻撃者が用意した指示が埋め込まれる可能性があります。

企業側では、

外部情報を読む機能と社内データを分離
書き込み権限を必要最小限にする
高リスク操作へ人間の承認を入れる
不要なWeb検索を無効化
Connector／MCP／Agentを許可制にする
操作ログを取得する

という複数の制御を組み合わせます。

Microsoft Copilotで確認されたEchoLeakについては、以下の記事で整理しています。

Microsoft 365 Copilotでゼロクリックの情報漏洩が可能な「EchoLeak」

導入時のチェックリスト

法人契約と個人向けAIの利用範囲を分けた
SSOを設定した
フィッシング耐性MFAを設定した
SCIM等で入退社を連動した
管理者を必要最小限にした
一般社員・開発者・高機密部門をロール分けした
入力可能な情報区分を決めた
保存期間を決めた
データ所在地・学習利用条件を確認した
Apps・Plugins・MCP・Agentsを棚卸しした
読み取りと書き込み権限を分けた
個人アカウントによる企業データConnector接続を制限した
Web Searchの必要性を部門別に確認した
高リスク操作に人間の承認を入れた
監査ログをSIEMやeDiscoveryで確認できる
新機能追加時に設定を再評価する担当を決めた
AIインシデントをCSIRTの対応手順へ組み込んだ

情報システム部門が決めるべきなのは「どのAIか」だけではなく「どこまで権限を与えるか」

3製品とも法人向け環境では、SSO、アクセス管理、データ保護、監査の仕組みを備えています。

企業側で差が出るのは、これらを実際に設定し、外部連携を管理できているかです。

公的ガイダンスを製品設定へ落とすと、確認順序は次のようになります。

法人管理アカウントへ限定する
SSOとフィッシング耐性MFAを設定する
SCIM等でアカウントライフサイクルを管理する
最小権限のロールを作る
機密データの入力ルールを決める
Connector・MCP・Agentを許可制にする
書き込み操作へ承認を入れる
ログと保持期間を設定する
小規模展開で確認する
新機能追加のたびに再評価する

AIセキュリティ全体のリスクと公的ガイドラインについては、以下の記事で整理しています。

AIセキュリティとは？生成AI・AIシステムのリスクと企業のセキュリティ対策

各AIサービスのデータ保護や企業向け機能の違いは、以下の記事で確認できます。

ChatGPT・Claude・Microsoft Copilot別、各 AIの推奨 セキュリティ設定 米国・英国・イスラエルの公的ガイダンスから実装方法を整理