AI APIデータ保持チェックリスト：ログ、プロンプト、出力、課金記録

AI APIデータ保持チェックリストは、本番トラフィックが開始される前に、単純な質問に答える必要があります。それは、モデル呼び出し後にどのレコードが存在し、誰がそれを読み取ることができ、どのくらいの期間保持され、購入者が後でどのような証拠を確認できるか、というものです。

その質問はすぐに複雑になります。1回のAIリクエストで、プロンプト記録、出力記録、ゲートウェイリクエストログ、プロバイダーの不正使用監視ログ、監査イベント、トレース、キャッシュエントリ、請求行、サポートチケット、エクスポート、スクリーンショット、インシデントメモが作成される可能性があります。一部の記録はエンジニアリングの障害デバッグに役立ちます。一部は財務の支出照合に役立ちます。一部は調達がベンダー設定がレビューされたことを証明するのに役立ちます。機密性の高いワークロードでは、一部はまったく存在すべきではありません。

このAI APIデータ保持チェックリストを使用して、実際の顧客データをゲートウェイ経由でルーティングする前に、これらの記録を分離してください。目標は、やみくもに記録を少なくすることではありません。目標は、すべてのプロンプトと出力を長期的なデータストアに変えることなく、運用、セキュリティ、財務、調達のために適切な証拠を保持することです。

Flatkeyの購入者にとって、このレビューはゲートウェイ承認ファイルに含まれます。Flatkeyの現在の公開サイトでは、この製品をモデルアクセス、ルーティング、請求、使用状況分析、運用管理のためのAI APIゲートウェイおよびモデル運用プラットフォームとして位置付けています。そのため、ルート、モデル、所有者、使用状況、コストに関する証拠を一元化するのに自然な場所となります。ただし、承認前にアカウント固有の保持期間、プロバイダー契約、ペイロードストレージの動作を確認する必要性がなくなるわけではありません。

AI APIデータ保持チェックリスト

ベンダーのスローガンではなく、記録のクラスから始めましょう。「ゼロデータ保持」というあるプロバイダーの機能は、ゲートウェイログ、可観測性トレース、請求台帳、エクスポート、またはサポートワークフローを自動的に説明するものではありません。

これがAI APIデータ保持チェックリストの核です。すべての記録クラスを定義し、保持の所有者を割り当て、日付付きの読み戻しで設定を証明し、データがコピーされる可能性のあるすべての場所に更新トリガーを設定します。

保持とトレーニングを分離する

プロバイダーのトレーニングポリシーは、レビューの中の1行にすぎません。調達チームは、APIデータがモデルのトレーニングに使用されるかどうかをよく尋ねます。それは重要ですが、プロンプトや出力が不正使用監視、アプリケーションの状態、製品機能、サポート、分析、または請求のために保存されるかどうかには答えていません。

OpenAIのプラットフォームデータ管理では、モデルトレーニング、不正使用監視のための保持、アプリケーションの状態の保持を区別しています。同じドキュメントには、不正使用監視ログにはプロンプトと応答が含まれる可能性があり、デフォルトで最大30日間保持されると記載されています。一方、対象となる顧客は、修正された不正使用監視やゼロデータ保持などの管理を申請できます。また、一部のAPIで保存されるアプリケーションの状態や、ファイル、会話、ビデオ、キャッシング、ウェブ検索、ホストされたコンテナ、その他の機能に関する機能固有の動作など、エンドポイント固有の例外もリストされています。

AnthropicのAPIデータ保持に関するドキュメントでは、ゼロデータ保持を、API応答が返された後に顧客データが保存されないことと定義していますが、法的要件、不正使用防止、機能固有のストレージは例外としています。また、機能の適格性はAPIの機能によって異なる場合があるとも述べています。

GoogleのGemini Developer API ZDRドキュメントには、有料サービスのプロンプトと応答はGoogleの製品改善には使用されないと記載されていますが、同時に、不正使用監視のための限定的なプロンプトと応答のロギングや、特定の機能のための機能固有のストレージについても説明されています。このページは、ZDRが普遍的な前提ではなく、構成と機能選択のレビューであることを明確にしています。

購入者にとっての教訓は実践的です。プロバイダーのポリシーの証拠は保管しますが、それが独自のAI APIデータ保持ポリシーに取って代わらないようにしてください。プロバイダーが保持するもの、ゲートウェイが保持するもの、そして可観測性スタックが両方をコピーするものは、それぞれ異なる場合があります。

プロンプトと出力には独自のルールが必要

プロンプトと出力は、AI APIデータ保持チェックリストの中で最もリスクの高い記録です。なぜなら、それらはしばしば最も有用なデバッグの証拠と最も機密性の高いビジネスデータを含むからです。

プロンプトと出力の保持は、例外的なワークフローとして扱います。

1. デフォルトで生のペイロードを保存しない：特定のワークロードで必要な場合を除き、本番環境のルートでは保存しません。
2. 墨塗りされたペイロードの保存を許可する：フィクスチャによって、プロンプト、出力、ツール結果、検索チャンク、エラー、ストリーミングイベント全体でマスキングが機能することが証明された後にのみ許可します。
3. 完全なペイロードの保存を許可する：名前付きインシデント、ステージングテスト、顧客承認済みワークフロー、またはベンダーへのエスカレーションの場合にのみ許可します。
4. 収集前に有効期限を設定する：デバッグウィンドウが永続的なストレージにならないようにします。
5. ペイロードログへのアクセスを記録する：ログビューアが機密システムになるためです。
6. クリーンアップされたインシデントの概要を保持する：ペイロードの有効期限が切れた後は、生のプロンプトや出力ではなく、概要を保持します。

ここではOWASP Logging Cheat Sheetが役立ちます。なぜなら、このチートシートはログ内の機密値をフォーマットの問題ではなく、設計上の問題として扱っているためです。シークレット、アクセストークン、機密性の高い個人データ、支払いデータ、接続文字列、暗号化キー、および機密性の高い分類データは、通常、ロギングの前に削除、マスキング、サニタイズ、ハッシュ化、または暗号化する必要があります。AIのプロンプトには、これらのカテゴリがすべて含まれる可能性があります。

墨塗りパターンについては、ツールのドキュメントも同じ方向性を示しています。Langfuse maskingは、トレースデータがアプリケーションを離れる前にデータを墨塗りできます。Helicone Omit Logsは、リクエストとレスポンスのボディを省略しながら運用メトリクスを維持するように設計されています。Portkey request logging controlsは、リクエスト/レスポンスのコンテンツをメトリクス指向のロギングから分離します。異なるスタックを使用している場合でも、パターンは同じです。つまり、保存およびエクスポートの前に墨塗りまたは省略します。

リクエストログはメタデータを優先すべき

リクエストログは通常、AI API運用の主力です。有用であるために生のプロンプトを含む必要はありません。

ほとんどの本番環境のルートでは、メタデータ優先のイベントで十分です。

{
  "request_id": "req_01jz4...",
  "timestamp": "2026-07-04T04:00:00Z",
  "environment": "production",
  "owner_key_id": "support_summarizer_prod",
  "route": "support-summary",
  "endpoint_family": "chat_completions",
  "requested_model": "approved-summary-route",
  "served_provider": "selected_by_gateway",
  "prompt_tokens": 1840,
  "output_tokens": 312,
  "status": "success",
  "latency_ms": 1420,
  "cost_usd": "0.0042",
  "payload_storage": "none",
  "retention_class": "ops_metadata_90d"
}

そのイベントは、プロンプトのボディやレスポンスのボディを保持することなく、課金レビュー、インシデントの相関付け、ルーティングレビュー、SLOレビュー、不正利用の調査、および所有者へのチャージバックをサポートします。

Cloudflare AI Gatewayのロギングは、リクエストログに関する決定を明示的に行う必要がある理由を示しています。ゲートウェイログには、プロバイダー、モデル、ステータス、トークン使用量、コスト、期間、プロンプト、レスポンス、およびポリシーアクションを含めることができ、リクエストごとの制御によって、リクエストとレスポンスのボディが保存されるかどうかが変わる可能性があります。保持チェックリストには、デフォルトのゲートウェイ設定と、リクエストごとのオーバーライドパスの両方を記録すべきです。

このリクエストログのチェックリストを使用してください。

ここで、AI APIのデータ保持は理論的なものではなく、運用上のものになります。エンジニアは必要な記録を引き続き入手できる一方で、プライバシーとセキュリティの所有者は、何が意図的に省略されているかを確認できます。

監査ログはペイロードログではない

監査ログは、誰が何を、いつ変更したか、そして制御パスが機能したかどうかに答えます。通常、デバッグペイロードよりも長く存続させるべきですが、バックドアのペイロードストアになってはなりません。

AI APIデータ保持チェックリストには、以下の監査イベントを含める必要があります。

• APIキーの作成、ローテーション、無効化、削除。
• ワークスペース、プロジェクト、ルート、プロバイダー、モデルポリシーの変更。
• クォータ、予算、課金コントロールの変更。
• ペイロードロギングの有効化、無効化、例外承認。
• 機密ログおよびエクスポートへのアクセスイベント。
• 管理者ロールの変更と権限付与。
• データのエクスポート、削除、サポートエスカレーションイベント。

監査ログには、実行者、ターゲット、アクション、タイムスタンプ、ソースシステム、承認参照、および変更前後の状態を記録する必要があります。生のプロンプト、生の出力、生のAPIキー、ベアラートークン、ペイメントカードデータ、および墨塗りされていない顧客データの保存は避けるべきです。

調達部門がゲートウェイ操作のための永続的なイベントモデルを必要とする場合は、この記事をFlatkeyのAI API使用状況の監査ログに関するガイドと関連付けてください。監査ログは保持ポリシーが適用されたことを証明するものであり、ポリシーをトリガーした機密ペイロードを保持する必要はありません。

課金記録には異なる保持要件がある

課金記録はプロンプトデータのように見えないため、AI APIデータ保持チェックリストで見落とされがちです。しかし、それらは依然として重要です。

課金および財務記録には、以下が含まれる場合があります。

• APIキー、ワークスペース、チーム、プロジェクト、顧客、または環境ID。
• モデル、プロバイダー、エンドポイントファミリー、およびルート。
• プロンプトトークン、出力トークン、キャッシュされたトークン、画像/ビデオユニット、期間、またはリクエスト数。
• 単価、実効価格、マークアップ、クレジット、税金、請求書明細、リチャージ記録、返金、および残高移動。
• タイムスタンプ、請求期間、請求書ID、決済プロバイダーID、および台帳参照。

これらの記録は、財務、税務、カスタマーサポート、および調達チームが照合の証拠を必要とするため、通常、デバッグペイロードよりも長く保持する必要があります。それでも最小化は必要です。課金台帳は、支出を証明するために生のプロンプトや出力を必要とすべきではありません。

この課金保持テーブルを使用してください。

Flatkeyの現在の価格ページでは、透明性の高いモデル価格、従量課金制の使用、クォータ制限、使用状況分析、コスト管理、および請求レビューパスについて説明しています。これらを役立つ公開スクリーニング情報として扱い、その後、ライブダッシュボード、アカウント規約、請求書、およびエクスポートを自身の購入者記録として確認してください。

購入者所有の証拠ファイルを構築する

信頼ページは役立ちますが、永続的な成果物は購入者が所有するべきです。6か月後のレビュー担当者は、承認日に何がチェックされ、その後何が変更されたかを確認できる必要があります。

この構造でフォルダーまたはガバナンス記録を作成してください。

この証拠ファイルは、AI APIのデータ保持をベンダーの主張から、再現可能なレビュープロセスへと変えます。また、レビュー担当者がマーケティングコピーからやり直すのではなく、現在の状態と以前の状態を比較できるため、更新も容易になります。

ローンチ前に保持クラスを設定する

各システムに独自の保持期間を考案させないでください。保持クラスを定義し、すべての記録をいずれかのクラスにマッピングしてください。

retention_classes:
  ops_metadata_90d:
    stores_payload: false
    records:
      - request_id
      - route
      - provider
      - model
      - status
      - latency
      - token_usage
      - cost
    access: engineering_ops_finance_security
  debug_payload_72h:
    stores_payload: true
    approval_required: true
    redaction_required: true
    expiration_required_before_collection: true
    access: named_incident_responders
  audit_control_1y:
    stores_payload: false
    records:
      - actor
      - action
      - target
      - before_after_state
      - approval_reference
    access: security_procurement_admins
  finance_ledger_contract_term:
    stores_payload: false
    records:
      - usage
      - pricing_snapshot
      - invoice
      - recharge
      - balance_movement
    access: finance_procurement

正確な期間は、契約、セキュリティポリシー、税務要件、顧客との約束事から導き出す必要があります。重要なのは、トラフィックが開始される前にクラスが存在し、ペイロードストレージが別のプロパティとして可視化されていることです。

これがFlatkeyとどう適合するか

Flatkeyは、公開されている製品の機能が、単一のAPIゲートウェイ、モデルルーティング、使用状況の可視化、課金、クォータ制御、および運用レビューを中心に構成されているため、この運用モデルをサポートできます。2026年7月4日のライブ価格APIチェックでは、success=true、45のモデル行、48のベンダーレコード、価格バージョンa42d372ccf0b5dd13ecf71203521f9d2が返され、/v1/chat/completions、/v1/messages、Gemini generateContent、画像生成、ビデオエンドポイントなどのエンドポイントパスがサポートされていました。

Flatkeyをゲートウェイの証拠収集の場として使用し、公開ページでは証明できないアカウント固有の詳細を確認します。

• Flatkeyがどのリクエストメタデータを保存するか。
• 生のプロンプトとレスポンスの本文が保存されるかどうか。
• ペイロードストレージを無効化、スコープ設定、墨消し、または時間制限できるかどうか。
• キー、ルート、クォータ、課金、ログアクセスに対してどの監査イベントが利用可能か。
• 財務照合のためにどの課金エクスポートが利用可能か。
• 各ルートの背後でどのプロバイダー保持設定が適用されるか。
• どのサポート、エクスポート、可観測性パスがリクエストデータをコピーできるか。

この区別は重要です。ゲートウェイは運用と証拠収集を簡素化できますが、最終的なAI APIデータ保持チェックリストの所有権は購入者にあります。

本番前保持テストの実行

本番ルートを承認する前に、テストワークロードに対してチェックリストを実行します。

1. 通常のリクエストを送信し、メタデータログにプロンプトや出力の本文が含まれていないことを確認します。
2. メールアドレス、アクセストークン形式の文字列、アカウントID、支払い関連の値、独自コードのマーカーなど、事前に用意した機密フィクスチャを含むリクエストを送信します。
3. ルートが承認されたデバッグレーンに明示的に入らない限り、これらのフィクスチャがログ、トレース、アラート、サポートエクスポート、または課金記録に表示されないことを確認します。
4. 非本番環境でスコープ付きのデバッグペイロード例外を有効にし、承認、アクセスロギング、墨消し、有効期限を確認します。
5. デバッグ保持期間が終了するのを待つか、データをパージし、読み返しでペイロードが返されなくなったことを確認します。
6. ロギングポリシーの変更とパージに関する監査イベントを取得します。
7. 課金または使用状況の行を取得し、ペイロードコンテンツなしで照合できることを確認します。
8. スクリーンショット、APIの読み返し結果、タイムスタンプ、アカウントID、レビュー担当者名を証拠ファイルに記録します。

このテストは、チームがゲートウェイでペイロードストレージを無効にしても、トレースエクスポーター、アラートメッセージ、サポートチケット、またはデバッグスクリーンショットを通じてプロンプトテキストが漏洩するという、よくある失敗を検出します。

信頼性レビューにおける位置づけ

AI APIのデータ保持は、より広範なゲートウェイレビューの一部です。エンタープライズAI APIゲートウェイチェックリストを使用して、アクセス、ルーティング、課金、クォータ、運用所有権をカバーします。AI APIベンダーリスク評価を使用して、上流のプロバイダー契約とサードパーティプロセッサーを比較します。調達部門から、ゲートウェイがキー、ルート、クォータ、ロギングポリシーを変更した人物をどのように証明するのか尋ねられた場合は、AI API使用状況の監査ログガイドを使用してください。

これらのレビューは連携させる必要があります。ゲートウェイチェックリストは制御面を示します。ベンダーリスク評価は上流の契約とデータ境界を示します。監査ログガイドは永続的な管理証拠を示します。このAI APIデータ保持チェックリストは、各リクエストの後に何が残るかを示します。

よくある質問

AI APIのデータ保持とは何ですか？

AI APIのデータ保持とは、AI APIリクエスト後にプロンプト、出力、メタデータログ、監査イベント、トレース、課金行、サポート記録、プロバイダー側の記録がどのくらいの期間保存されるかを決定するポリシーとシステム動作のことです。

ゼロデータ保持はログなしと同じですか？

いいえ。ゼロデータ保持は通常、顧客コンテンツに対するプロバイダーまたは機能固有の制御を指します。ゲートウェイのメタデータ、監査ログ、課金記録、可観測性エクスポート、サポートチケット、またはすべてのプロバイダー機能をカバーしているとは限りません。常にスコープと例外を確認してください。

デバッグのためにプロンプトと出力を保存すべきですか？

例外的にのみ行うべきです。本番トラフィックではメタデータログをデフォルトにすべきです。墨消しされたペイロードまたは完全なペイロードは、承認されたワークフロー、スコープが限定されたインシデント、ステージングテスト、または顧客が承認したレーンに対してのみ保存し、収集前に有効期限を設定してください。

AI APIリクエストログはどのくらいの期間保持すべきですか？

普遍的な期間はありません。メタデータログは、インシデントレビュー、課金照合、不正使用調査に十分な時間が必要な場合が多いです。生のプロンプトと出力のペイロードは、通常、メタデータ、監査ログ、または課金記録よりもはるかに短い保持期間にすべきです。

AI APIの保持において、どの課金記録が重要ですか？

財務証拠として、使用状況の行、トークン数、モデル/プロバイダー識別子、価格のスナップショット、請求書、再チャージ記録、返金、所有者マッピングを保持してください。これらの記録には、生のプロンプトや出力の本文は必要ありません。

調達部門はゲートウェイベンダーに何を尋ねるべきですか？

リクエストメタデータ、ペイロードストレージの動作、墨消し、削除、監査ログ、アクセス制御、課金エクスポート、プロバイダー保持設定、およびサードパーティのエクスポート先に関する日付付きの証拠を要求してください。次に、その証拠を自社のデータ分類およびインシデント対応ポリシーと比較します。

結論

AI APIデータ保持チェックリストは、曖昧な信頼性の主張をレビュー可能な運用ファイルに変えます。プロンプトと出力、リクエストログと監査ログ、課金記録とデバッグペイロードを分離してください。デフォルトでメタデータを保持し、例外的にのみ生のペイロードを保存し、保存前に墨消しをテストし、更新のために日付付きの証拠を保存します。モデルアクセス、使用状況、課金、ルーティングを1つのゲートウェイサーフェスで一元化する準備ができたら、Flatkeyの現在の価格とモデルカタログを確認し、キーを取得してください。