会社のコードをAIに渡せる？開発支援ツールの法人管理機能を比較

会社のコードをAIへ読ませたい。でも、顧客の情報や未公開の実装も入っている。そんなとき「学習には使いません」という案内だけで導入を決めるのは、少し待ちたいところです。どれだけ保存されるか、誰がアクセスを止められるか、AIがどこまで操作できるかも確認しましょう。

この記事では、公式資料の比較から、GitHub Copilot、Cursor、Claude、ChatGPTとCodexを選ぶときの確認点を説明します。プランや契約条件は変わるため、候補を絞ったあとに、契約時点の一次情報と自社の必須条件を照合してください。

必須条件から、必要な比較へ進む

SSOは会社の認証でログインする仕組み、SCIMは入退社に合わせて利用者を自動で作成・停止する仕組みです。SIEMは複数システムの記録を集めて調べる仕組みで、認証とも別の要件です。自社で外せない条件を選び、対応する表や製品節へ進んでください。

外せない条件	先に読むところ
コードを学習に使わせず、会社のIDで利用者を管理したい	学習利用・SSO・SCIMの比較
読めるリポジトリ・モデル・MCPや実行範囲を制限したい	実行権限の比較、Copilot、Cursor
保存日数を自社で決めたい	Claudeの保持、ChatGPTの保持・共有
AIへの入力本文まで記録したい	Copilot監査の対象外、Cursor監査の対象外

学習不使用だけなら各製品が候補に残ります。条件が複数ある場合は、そのすべてを満たす契約を残し、最後に試験用コードで設定の効き方を確かめます。

4製品の法人管理機能

学習利用と入退社の管理

ここからは、残った候補を具体的な機能で比べます。まず認証とアカウントの作成・停止です。製品名が同じでも、個人版と法人版、TeamとEnterpriseでは対象が違う点を見てください。

項目	GitHubの法人版	Cursorの法人版	Claudeの法人版	ChatGPTの法人版
モデル学習	Business/Enterpriseの顧客データを学習に使用しない	Privacy Modeを有効にするとCursor・LLM提供元とも学習不使用	商用コンテンツは既定で学習不使用	法人ワークスペースのデータは既定で学習不使用
チーム全体のプライバシー	組織・企業ポリシー	TeamsでPrivacy Modeを強制可能	Teamで商用プライバシーを適用	ワークスペースのポリシー
SSO	GitHubの組織・EnterpriseのID管理側で管理	法人向けプランでSAML/OIDC SSO	法人向けプランでSSO	Business/EnterpriseでSAML SSO。SCIMなどのプロビジョニングとは別
SCIM	GitHub EnterpriseのIDライフサイクルと組み合わせる	Enterprise	Enterprise。TeamはJITのみ	Enterprise。Businessは非対応

実行権限と監査・保持

次に、AIが実行できる操作と、あとから追える記録を比べます。操作を制限できることと、その内容を記録できることは別なので、二つとも要件に合うかを見ます。

項目	GitHubの法人版	Cursorの法人版	Claudeの法人版	ChatGPTの法人版
モデル・機能の制御	機能・モデル・エージェント・クライアントのポリシー	Enterpriseでモデル・MCP・リポジトリ・エージェントを制御	EnterpriseのRBAC、接続先・管理制御	Enterpriseで機能・アクセスを細かく制御
監査	Enterprise監査ログ、エージェント活動あり	Enterprise監査ログ	Enterprise監査ログ / Compliance API	Enterpriseのコンプライアンス・管理機能を確認
個別保持期間	GitHubの機能・データ種別ごとに確認	Enterpriseのデータ管理でCloud Agent等を管理	Enterpriseの個別保持期間	Enterpriseの保持設定・契約条件を確認。Businessに同等の設定を前提にしない
ローカルセッション内容の監査	ローカルのプロンプトはEnterprise監査ログに含まれない	エージェント応答・生成コードは監査ログに含まれない	Compliance API等の対象範囲を契約で確認	Businessの利用分析・支出はチャット本文の監査とは別。EnterpriseもComplianceの権限・対象を確認
エージェントの外部作用	クラウドエージェント・MCP・モデルのポリシー	Enterpriseで自動実行・ブラウザ・ネットワーク・MCPを制御	権限・接続先・RBACとClaude Codeのポリシー	Codexのサンドボックス・権限とワークスペース制御

「監査ログあり」という一言だけでは、入力したプロンプト本文まで管理者が見られるか分かりません。「設定を変えた人を知りたい」のか「AIに送ったコードを確認したい」のか、調べたいことを具体的に書いておきましょう。

GitHub CopilotはGitHub上のポリシーを中心に統制する

Copilotは、GitHubで管理する組織・企業のポリシーとリポジトリの権限を組み合わせやすい製品です。CLI、cloud agent、モデル、MCP、GitHub.com上の機能、公開コードとの一致検出を管理対象として選べます。

cloud agentは組織側で有効化し、リポジトリ単位で利用可否を制限できます。コードを読める場所だけでなく、エージェントを使ってよい場所も絞る考え方です。

GitHubでコードを管理している会社なら、リポジトリへのアクセスとCopilotの設定を同じ管理画面で扱えます。今の管理方法へ追加しやすいかを見ると、導入後の負担も想像しやすくなります。

Copilotの監査ログは端末上のプロンプト本文までは記録しない

GitHub Enterpriseで、たとえば次の操作を追いたい場合は、監査ログの対象を調べます。

• Copilot プラン・ポリシー変更
• ライセンス付与・削除
• GitHubのWebサイト上のエージェント活動

一方、GitHub Docsは、ローカルクライアントのセッション内プロンプトを監査ログへ含めないと説明しています。

VS CodeやCopilot CLIから送った内容まで全部追える、と考えるとここで要件から外れます。端末上のプロンプトも必要なら、フックや独自ログを用意してSIEMへ送るなど、別の記録方法を設計しましょう。

Copilotはモデルごとのデータ取扱いの差も見る

Copilotで使うモデルの提供元は一つではありません。審査する際は、製品全体の方針に加えて、実際に有効にするモデルも見ておきます。

GitHub Docsでは、多くのOpenAI・Anthropicのモデル提供元との間で、データを保持しないZDR条件を持つと案内しています。ただし、一部のプレビューモデルには例外があります。保持条件が異なるために、既定で有効になる対象から外れるモデルもあります。

Enterpriseでは利用可否のポリシーでモデルを絞れます。許可するモデルを決め、その提供元と保持条件を審査の記録へ残しておきましょう。

Cursor TeamsはPrivacy ModeとSSO、Enterpriseで統制が増える

Cursor Teamsは、請求・管理の集約、チーム全体のPrivacy Mode、SAML/OIDC SSO、チーム用マーケットプレイス、利用分析をまとめて導入する候補です。

管理者がPrivacy Modeを有効にすると、Cursorもモデル提供元もコードデータを学習へ使わないと案内されています。社員それぞれの設定任せにせず、チーム全体へ適用できるかを確かめてください。

小規模チームで「学習不使用、SSO、請求の集約」が必要なら、Teamsでも満たせる項目があります。料金は契約体系と席種で異なり、旧TeamsのStandard席は$40/user/月でした。これから契約する場合は、旧料金をそのまま予算にせず現行プランを確認しましょう。

Cursor Enterpriseはリポジトリ・モデル・MCP・ネットワークを管理できる

Teamsで足りない制限があるなら、Enterpriseで追加される次の機能を調べます。

• SCIM
• リポジトリへのアクセス制御・ブロックリスト
• モデルへのアクセス制限
• MCP制御
• 自動実行の制御
• ブラウザー・ネットワークの制御
• 監査ログ
• サービスアカウント
• SIEMへのログ配信

エージェントにシェル、ネットワーク、ブラウザーを使わせると、コードの提案を受けるだけのときより操作範囲が広がります。ログインの管理に加えて、管理者が実行範囲を固定できるかまで確認しましょう。

Enterpriseの安全性強化の文書でも、組織全体へのPrivacy Modeの強制、実行範囲を制限するサンドボックスの有効化、モデル・MCP・持ち込みAPIキー（BYOK）・ネットワークの管理が勧められています。会社の許可範囲に合わせて、この設定を試験導入で確かめます。

Cursorの監査ログも生成コード本文を全部保存するわけではない

Cursor Enterpriseでは、次のような管理上の操作が監査ログに残ります。

• 認証
• ユーザー・役割
• APIキー
• チーム設定
• リポジトリ
• Cloud Agentの環境
• プライバシー設定
• 外部連携

ただし、文書ではエージェントの応答や生成コードの内容は監査ログへ記録しないと説明されています。

「誰がPrivacy Modeを変えたか」を調べる用途と、「開発者がAIへ何を入力したか」を残す用途では、必要な記録が違います。後者が必要なら、フックでプロンプトやコードを自社のログへ送る設計などを追加します。

Claude Teamは学習不使用とSSOを小規模チームから使える

Claude TeamはSSO、接続先の管理、組織内検索、Claude Codeを中央請求で使う候補です。SCIMは対象外で、JITによる作成を使っても、退職者のメンバー削除は管理者が行います。公式のJIT・SCIM対応範囲を参照してください。

Claude Codeへソースコードを渡し、学習利用と認証を会社で管理したい段階なら、Teamが比較候補になります。さらに自動のユーザー管理や詳しい記録が必要なら、Enterpriseの機能へ進みます。

Claude EnterpriseはSCIM・監査・保持期間の設定を追加する

Claude Enterpriseでは、Teamに加えて次の管理機能が案内されています。RBACは、役割に合わせて権限を割り当てる仕組みです。

• RBAC
• SCIM
• 監査ログ
• Compliance API
• Analytics API
• データ保持期間の個別設定
• ネットワーク単位のアクセス制御
• 許可IPアドレスの指定

組織のチャットやプロジェクトのデータへ、個別の保持期間を設定できます。社内規程で日数が決まっている場合は、必要な対象すべてへ適用できるかを照合しましょう。

通常のAnthropic APIは、原則30日以内にバックエンドから削除されます。一方、Claude for Work / Enterpriseのチャットや開発セッションは、製品を続けて使うために保存されます。APIの「30日」をClaude CodeやClaude製品の履歴へそのまま当てはめないでください。

ChatGPT Business + Codexは対象ワークスペースと学習条件を分けて確認する

ChatGPT Businessのワークスペースのデータは、Codexを使う場合も、既定でOpenAIのモデル学習に使われません。各メンバーのチャットとCodex履歴は個別に扱われます。

管理者の支出管理や利用分析で分かるのは、使用量やクレジットなどです。それが見えるからといって、全員の非共有チャット本文まで自動で開けるわけではありません。

Codexの席を選ぶ際は、契約の日付にも注意してください。2026年6月24日以降、新しいChatGPT Businessワークスペースや、その日までにlegacy Codex席を一度も追加していない既存ワークスペースには、legacy Codex席を新たに追加できません。2026年6月24日より前にCodex席を追加していた、またはその時点で招待が保留中だった対象ワークスペースは、legacy Codex席を継続・追加できます。Standard/Premium席はChatGPTとCodexを含みますが、legacy Codex席は従量利用のCodex専用で、ChatGPTのワークスペースのチャットは使えません。

導入前には、ワークスペースが対象条件を満たすか、Standard/Premium席を使うか従来のCodex専用席を使うかを確かめます。共有クレジットと支出上限の管理担当者も決めましょう。入力したプロンプトをすべて監査したい場合は、別途Compliance（コンプライアンス）の利用条件とログ設計を確認します。

ChatGPTの共有・保持・監査は、契約プランごとに確かめる

OpenAIのEnterprise向けプライバシー約款では、BusinessとEnterpriseの企業データを既定で学習へ使わないとしたうえで、Enterprise側に次の機能を案内しています。

• SAML SSO
• 詳細なアクセス制御
• 保持期間の設定
• 企業向けデータ管理

Business向け製品ページでは、Businessの役割・SAML SSO・基本的な利用分析に対し、EnterpriseにはSCIM・RBAC・集中支出管理・ユーザー別の利用分析などが加わると説明されています。SSOだけが欲しい場合と、入退社の自動管理まで必要な場合を分けて比較してください。

共有とデータの書き出しも、プランごとに確認したいところです。Businessはメンバーが共有リンクを管理できますが、ワークスペース全体で共有リンクを無効にするEnterprise向け設定はなく、Businessワークスペースからのデータの書き出しも利用できません。

Enterpriseではワークスペース設定で共有を制御し、Compliance Platformで許可されたログを、証拠開示に使うeDiscovery、情報漏えいを防ぐDLP、ログを集めて監視するSIEMへ接続できます。ただし、取得できる記録、権限、保持期間は契約と設定で確認します。Enterpriseでも、メンバー自身がワークスペースのデータを書き出す機能は利用できません。

同じ法人向け製品でも、管理できる範囲はそろっていません。契約プラン、ワークスペースの設定、席種、Complianceの権限を要件表へ書き分けると、導入後の思い違いを減らせます。

ソースコード以外もデータ一覧へ入れる

コードの扱いが決まったら、端末の出力やテストデータも見てみましょう。エージェントが調査中に読む可能性があるためです。試験導入（PoC）の前に、次の表へ送信可否と条件を記入します。

データ	送信してよいか	保持条件	除外方法
ソースコード			リポジトリ・パスのポリシー
プロンプト			ログ・保持期間
端末の出力			秘密情報のマスキング
テストデータ			サンプル化
.env・秘密情報	原則送らない	-	除外・遮断
本番ログ	必要最小限	契約確認	秘密情報の除去
接続先のデータ		提供元を確認	取得範囲の制限
フィードバック報告		別保持の場合あり	フィードバック送信の制御

フィードバックとして送る報告や、MCPでつないだ外部サービスには、別の保持条件が適用される場合があります。表を埋めるときも、コード本体の方針だけで全部を判断しないようにしましょう。

試験用のコードで、管理者の設定が効くかを試す

候補を絞れたら、法人プランの管理者設定を使い、テスト用リポジトリで確かめます。個人Proで設定をOFFにできても、社員全員へ同じ条件を強制できるかは分からないためです。

1. 管理者がプライバシー・学習利用のポリシーを設定
2. テストユーザーをSSOでログイン
3. 許可モデルだけ表示されるか確認
4. 遮断対象のリポジトリ・パスを試す
5. エージェントのシェル・ネットワークを制限
6. MCP・接続先を無効化
7. ユーザーのアクセスを停止
8. 監査ログへ何が残ったか確認
9. 端末上のプロンプト本文が残るか確認
10. 保持・削除を契約条件と照合

禁止したモデルや接続先をメンバーが選べないか、アクセス停止後も使えてしまわないかを確かめ、残った記録と照合します。ファイルの試験には、実在する秘密情報の代わりに、識別できる無害な文字列を入れたテストファイルを使います。例えば遮断対象のファイルについては、期待する結果を「エージェントが内容を読めず、回答にも識別文字列が出ない」と先に書いておきます。ただし、回答へ出なかったことだけでは、送信されなかった証明にはなりません。製品が示す遮断の結果や、取得できる範囲の記録も合わせて確かめましょう。

記録は「設定した制限／メンバー側で試した操作／期待した結果／実際の結果／確認できたログ」の一行で残せます。操作が通ったのにログに記録されない場合は、操作の制限と監査の要件を別々に見直します。本文まで記録する仕組みを追加するなら、そのログを誰が読めるか、何日残すかも決めておかないと、今度は監査用の保存先へ機密情報が集まってしまいます。

不明な条件を残したまま、本番コードへつながない

試験の記録で期待と違った行、契約書に回答がない行だけを、未解決事項として残します。「条件／対象プラン・モデル／問い合わせ先／回答待ちの間に投入しないデータ」を一行にまとめれば、同じ要件を最初から調べ直さずに済みます。

監査の対象やモデルの保持条件は製品の営業・サポートへ、ログの保管・閲覧権限は社内のセキュリティ担当へ、個別保持や契約上の約束は法務・調達へ確認します。回答がそろうまでは、その条件に関わる本番コードやデータを接続しません。

会社側で必要な制限を適用でき、保存・外部送信・実行権限・記録の範囲を説明できることが導入の判断材料です。候補を絞れたら、試験用コードの結果と契約の回答を合わせて、利用を許す業務を決めましょう。