生成AIやエージェントの企業導入で、「使ってよいか」の判断は既に多くの組織で済んでいる。ボトルネックになっているのは、ログ設計・保持期間・監査運用の具体化だ。 本記事では、主要ベンダー5社の一次情報と日欧の規制動向を基に、ログ・個人情報・著作権・社内利用ルールの論点をテンプレートとして整理します。法務助言ではなく、社内規程の「たたき台」としてご活用ください。
この記事の位置づけ
対象読者はビジネスサイド（CS責任者・カスタマーサクセス・情シス企画・法務連携担当）です。ソースコードやスクリプトは載せず、図解・表・箇条書きで「何を決めるべきか・なぜそうなるか」を中心に解説します。数値・制度はすべて一次情報に基づき、推測には「推測」と明示しています。
なぜ今、ガバナンス設計が審査通過のボトルネックなのか
「AI利用の可否」から「監査証跡の再現性」へ
2025年から2026年にかけて、主要クラウドベンダーは生成AIサービスの監査機能を相次いで強化しています。Microsoft Purviewの監査ログ保持が最長10年まで拡張され（2026年2月更新）、Google Geminiの監査ログイベント定義が2026年2月26日に更新されるなど、「利用ログをどう残すか」の選択肢は広がり続けています。
一方で、ベンダー間の保持ポリシーには大きな差があります。
- OpenAI API：多くのエンドポイントで標準30日保持。Zero Data Retention（ZDR）の申請も可能
- Anthropic Claude Enterprise：既定は無期限保持。最短30日からの任意設定が可能で、保持変更は監査ログに記録される
- Google Gemini App：会話履歴は3か月・18か月・36か月の3段階から選択（既定18か月）
- Microsoft Purview：監査ログは標準180日、E5ライセンスで1年、追加オプションで最長10年
- AWS Bedrock：モデル呼出ログは既定無効。有効化後は設定削除まで継続保存
この不統一が意味するのは、「30日で統一」のような単純なルールでは社内規程が成立しないということです。アプリの会話履歴、APIの推論ログ、監査イベントログはそれぞれ法的目的が異なるため、データの種類ごとに保持方針を設計する必要があります。
推測：監査証跡が導入速度を決める時代へ
2026年は「AI利用の可否」ではなく「監査証跡の再現性」が導入速度を左右すると考えられます。根拠は、主要ベンダー5社が2025年から2026年にかけて監査機能を集中的に強化している点と、各社に例外申請（ZDR等）の仕組みが整備されている点です。これは推測ですが、一次情報のパターンに基づいています。
ベンダー別データ保持・学習利用の実態
主要5社のデータ保持と学習利用について、一次情報に基づき整理します。全社が「企業向けサービスでは顧客データを学習に使わない」と明記している点は共通していますが、適用範囲と保持期間の設計は大きく異なります。
OpenAI（Enterprise / API）
OpenAIは、Enterprise Privacy（2026年1月8日更新）で以下を明記しています。
- デフォルトで学習に使用しない
- データの所有権は顧客にある
- 保持期間は提供形態に応じて顧客が制御可能
API利用時は、多くのエンドポイントで30日保持が標準です。Abuse Monitoring（不正利用の監視）について、Modified Abuse MonitoringやZero Data Retention（データを一切保持しない設定）の選択肢が用意されています。2025年10月22日以降、法的保全対応を除き、削除データは30日以内に削除に戻した旨が公表されています。
運用上のポイント：標準30日保持を基準に、高機密業務や越境制約のある業務をZDR申請の例外フローとして設計すると、規程が整理しやすくなります。
Anthropic（Claude Enterprise / Claude Code）
AnthropicのClaude Enterpriseは、カスタム保持設定で以下を明記しています。
- 既定は無期限保持
- 最短30日からの任意保持期間に変更可能
- 保持変更は監査ログに記録される
- 通常は顧客がController（管理者）、AnthropicがProcessor（処理者）
- 学習利用は原則オプトイン（Development Partner Program経由）
Claude Codeについては、商用API・Team・Enterpriseプランで原則30日保持、EnterpriseプランではZDR設定が可能です。
運用上のポイント：「既定無期限」のまま運用すると社内のデータ保持規程と衝突しやすいため、導入時に保持日数を必須設定項目にすることを推奨します。
Google（Workspace Gemini / Vertex AI）
GoogleのWorkspace AI機能について、一次情報では以下が確認できます。
- 許可なく学習に使用しない
- 人手によるレビューは行わない
- データリージョン制御が可能
Gemini Appの会話履歴は管理者が3か月・18か月・36か月から選択でき、既定値は18か月です。設定変更の反映には最大72時間かかります。Gemini監査ログイベント（2026年2月26日最終更新）では、検索・出力・会話履歴設定変更等の監査イベントが定義されています。
Vertex AI経由でのClaude利用時は、機能ごとに保持条件が異なります。例えばGrounding（外部情報を参照する機能）利用時は、プロンプト・コンテキスト・出力が30日間保持され、無効化できない条件もあります。
運用上のポイント：「アプリの会話履歴設定」と「API機能別のログ保持」は別系統で管理されるため、社内規程ではサービス単位で保持一覧表を分けて管理する必要があります。
Microsoft（Copilot for Microsoft 365 / Purview）
Microsoftは、Microsoft 365 Copilotのデータ保護（2025年12月8日最終更新）で以下を明示しています。
- 顧客データを基盤モデルの学習に使用しない
- DPA（データ処理契約）・製品条項が適用される
- ラベル・保持・eDiscovery・監査との連携が可能
Purview監査ログの保持期間は3段階です。標準ライセンスで180日、E5等の上位ライセンスで1年、追加オプションで最長10年まで延長できます。
ただし、Copilot Studio監査（2026年1月27日最終更新）では、監査ログにはメタデータが中心で、会話のフルテキストは監査画面に保持されない旨が明記されています。会話本文の調査にはDSPM for AI（AI向けデータセキュリティ管理機能）を経由する必要があります。
運用上のポイント：インシデント対応手順を「監査ログ経路」と「会話本文の調査経路」の2系統で設計する必要があります。
AWS（Bedrock）
AWS Bedrockは、データ保護ドキュメントで入力・出力を基盤モデルの学習に使わないと明記しています。モデル呼出ログは、入力・出力とメタデータをCloudWatch・S3に記録できますが、既定では無効です。有効化後は設定を削除するまで継続保存されます。
運用上のポイント：監査要件がある企業は、導入初期の段階でログ出力を明示的に有効化する必要があります。「既定無効」のため、後から有効にしても遡って取得はできません。
ログ・監査設計テンプレート — 4層分離モデル
ベンダー間の保持ポリシーの違いに対応するには、自社側でログの種類を体系的に分類し、それぞれに保持方針を定義する必要があります。以下に、最低限必要な4層分離モデルをテンプレートとして提示します。
4つのログ層とその役割
| 層 | データ区分 | 内容 | 保持期間の目安 | 既定値の考え方 |
|---|---|---|---|---|
| L1 | 推論入出力ログ | プロンプト（入力）とレスポンス（出力） | 30日〜90日 | ベンダー標準に合わせる。高機密業務はZDR検討 |
| L2 | 監査イベント | 誰が・何を・いつ実行したか | 1年〜3年 | 社内監査サイクルに合わせる |
| L3 | 運用メタデータ | モデル名、トークン量、ツール呼出履歴 | 90日〜1年 | コスト分析・利用傾向の把握に活用 |
| L4 | 例外申請・承認履歴 | ZDR申請、高リスク利用承認、法務承認 | 3年〜5年 | 監査対応・コンプライアンス証跡として長期保持 |
この4層を分離する理由は、法的目的と利用者が異なるためです。L1（推論ログ）は開発チームがデバッグに使いますが、L2（監査イベント）は内部監査やコンプライアンス部門が参照します。L4（例外申請履歴）は外部監査への証跡として必要です。すべてを同じ保持期間で管理すると、不必要なデータの長期保存（コスト増・リスク増）か、必要なデータの早期削除（監査不能）のどちらかが起きます。
例外申請フローの設計
一次情報から確認できるように、主要ベンダーはいずれも例外申請の仕組みを備えています。
- OpenAI：ZDR・Modified Abuse Monitoringは申請・要件付き
- Google Vertex AI：Abuse Monitoringの例外申請導線あり
- Anthropic：Enterprise管理者が保持期間変更・ZDRを契約条件で制御
社内の例外申請フローは、以下の3要素で設計します。
申請トリガー（3類型）- 保持短縮（ZDR）：高機密データを扱う業務
- 外部ツール連携：社外サービスとのデータ連携
- 越境利用：国外拠点でのAI利用、国外へのデータ移転
- セキュリティ部門 → 法務部門 → システム責任者の3段階審査
- 申請必須情報：対象データ、法域、代替案、失効日、監視方法
- 期限付き承認（30日・90日・180日で再承認）
- 例外の作成・更新・失効を必ずログ化
- 定期棚卸しで期限切れを自動検知
インシデント対応設計
AIサービスに関するインシデント対応では、監査ログと会話本文の調査経路が分離しているベンダーがある点に注意が必要です（特にMicrosoft Copilot）。最小手順として以下の4ステップを事前に定義しておきます。
- 監査ログで実行主体と操作時刻を特定する — L2（監査イベント）から「誰が・いつ・何を」を特定
- 会話本文・参照データを照合する — 製品によって取得経路が異なるため、事前にベンダー別の調査手順を確認
- 影響範囲を確定する — 対象ユーザー・データ種別（個人情報／機密／一般）・外部送信の有無を判定
- 規程に基づき報告・封じ込め・再発防止を記録する — 経営・法務・顧客への連絡判定基準を事前に定義
個人情報・著作権の地域別論点整理
EU — AI Act段階適用と著作権義務
EUでは、AI Act（Regulation (EU) 2024/1689）の段階適用が進行中です。欧州委員会のAI Actページ（2026年1月27日更新）によると、以下の日程が確定しています。
- 2025年2月2日：AIリテラシー義務の適用開始（全ての利用者組織が対象）
- AI Act第53条：汎用AI（GPAI）提供者に対し、著作権ポリシーの整備と学習データ要約の公開を義務付け
- GPAI実施規範（Code of Practice）：2025年7月10日に最終版が公開、2025年8月1日に適切性評価を開始
個人情報保護の観点では、EDPB（欧州データ保護委員会）がOpinion 28/2024（2024年12月18日採択）で、AIモデルにおける匿名性評価と正当利益の適用条件を整理しています。CNIL（フランスの個人情報保護当局）は2026年1月5日に、AIモデルが個人データを処理するかどうかをケース別に判断すべきとする見解を公開しています。
社内規程への示唆：EU拠点でAIを利用する場合、AIリテラシー教育の提供義務は既に適用開始されています。著作権ポリシーについては、利用するAIサービスのGPAI提供者が第53条の義務を履行しているかを確認し、自社の利用規程に反映する必要があります。
米国 — 判例と行政解釈の更新が継続
米国著作権局は「Copyright and Artificial Intelligence」プロジェクトで、Part 2（AI生成物の著作物性、2025年1月29日公開）とPart 3（学習データに関する論点、2025年5月9日プレ公開）を段階的に公開しています。
社内規程への示唆：米国は連邦AI法が存在せず、判例・行政解釈の更新速度が高いため、四半期ごとの動向監視を規程に組み込むことを推奨します。
日本 — 既存法とガイドラインの組み合わせ
日本では以下の2つが主要な参照先です。
- 経済産業省「AI事業者ガイドライン」（第1.0版、2024年4月19日公表）：AI開発者・提供者・利用者それぞれの責務を整理
- 文化庁「AIと著作権に関する考え方について」（2024年3月）：AI生成物と著作権の関係を整理
社内規程への示唆：日本ではEUのような単独のAI規制法が即時適用される状況ではなく、個人情報保護法・著作権法の既存法とガイドラインの組み合わせで社内規程を設計する運用が現実的です。
社内展開の実務設計
教育プログラムの設計
EU AI Actでは、AIリテラシー義務が2025年2月2日から先行適用されており、EU拠点を持つ企業には既に義務が発生しています。国内企業でも、この基準をベンチマークとした教育体制の構築が有効です。
役割別に教育を分離する- 一般利用者：利用範囲の理解、禁止事項の把握、個人情報・機密情報の入力制限
- プロンプト設計者：適切な入力設計、出力の著作権リスク、バイアスへの配慮
- 管理者：保持設定の管理、例外申請の審査、監査ログの読み方
- 監査担当：インシデント対応手順、ベンダー別の調査経路、報告基準の判定
- 年次再受講を基本とする
- ベンダーの仕様変更時に追補研修を実施（保持ポリシーの変更、新機能の追加時など）
例外申請の運用設計
前述の例外申請フローを実運用に落とし込む際のポイントは以下の3点です。
例外類型の明確化- 保持短縮（ZDR）：機密区分が最高位のデータを扱う業務
- 外部ツール連携：社外APIやサードパーティサービスとの連携
- 越境利用：EU拠点からのアクセス、国外データ移転を伴う利用
- 対象データの種別と量
- 適用法域（日本国内のみ / EU含む / 米国含む）
- 代替手段の検討結果
- 例外の有効期限
- 監視方法の具体策
- 期限付き承認とし、30日・90日・180日の再承認サイクルを設定
- 定期棚卸しで期限切れの例外を自動検知し、再審査または失効処理を実施
インシデント対応手順の事前定義
AIサービスに起因するインシデント（個人情報の意図しない出力、機密情報の外部送信、異常な大量利用など）に備えて、以下の判定基準を事前に定義しておきます。
検知パターン- 監査イベントの異常：大量出力、異常時間帯の利用、権限外アクセス
- ユーザー報告：意図しない個人情報の出力、不適切な回答
- 外部からの通報：顧客やパートナーからの情報漏洩の指摘
- 該当アカウント・APIキー・連携機能の一時停止
- 監査ログの保全（証拠としての確保）
- 個人情報が含まれる場合 → 法務・個人情報保護担当への即時連絡
- 顧客データが含まれる場合 → 経営判断・顧客連絡の要否を判定
- 外部送信が確認された場合 → 送信先への削除要請を検討
あわせて読みたい
まとめ：テンプレートを「自社版」に仕上げるために
本記事で提示したガバナンス設計テンプレートのポイントを整理します。
- 保持期間は単一ルールで統一できない — ベンダー間で30日から無期限まで差があり、推論ログ・監査イベント・メタデータ・例外履歴の4層に分けてそれぞれ保持方針を定義する
- 「学習不使用」は全社共通だが、適用範囲は異なる — 全ベンダーが企業向けサービスでの学習不使用を明記しているが、アプリ・API・連携機能で適用範囲が分かれるため、サービス単位で確認が必要
- 例外申請フローを初期設計に含める — ZDR・外部連携・越境利用の3類型を定義し、期限付き承認と定期棚卸しで運用する
- 地域別の規制差を規程に反映する — EU AI Actのリテラシー義務は適用済み、著作権のGPAI義務は段階適用中。日本は既存法＋ガイドラインの組み合わせ。米国は四半期ごとの動向監視が必要
- インシデント対応は2経路で設計する — 監査ログ経路と会話本文の調査経路が分離しているベンダーがあるため、事前に両経路の手順を確認しておく
推測：高機密業務では「デフォルト保持」運用のまま監査承認が通りにくい
ベンダー既定値が不統一であること、各社に例外申請機能が存在することから、高機密業務では「デフォルト設定のまま」での運用は監査承認が通りにくいと考えられます。これは一次情報のパターンに基づく推測です。
本記事のテンプレートは「論点整理の道具」としてご提供しています。自社の業種・規模・法域に合わせたカスタマイズや、具体的なベンダー設定の支援が必要な場合は、Agenticベース までお気軽にご相談ください。生成AI・エージェント導入のガバナンス設計から運用定着まで、実務に即したサポートをご提供します。
この記事の著者
Agentic Base 編集部
AIエージェントとWebメディア運用の知見を活かし、実践的なナレッジを発信しています。
