AI APIのマスキングポリシーとは、チームがモデルに送信できる内容、モデルの応答後に保存できる内容、リクエストログに表示される内容、そして顧客がチケットを起票したときにサポートが閲覧できる内容を定めるルールブックです。これが重要なのは、プロンプトや出力がもはや一時的な開発者入力ではなくなるからです。それらはデバッグ記録、監査証跡、スクリーンショット、エクスポート、サポート添付ファイル、調達レビュー資料になります。
このポリシーの弱い版は、「機微データをログに記録しない」とだけ述べます。それでは不十分です。本番トラフィックがモデルゲートウェイに到達する前に、フィールド単位の判断、責任者、保持期間、例外処理が必要です。優れたAI APIマスキングポリシーは、エンジニアリングにいつリクエストをブロックするか、セキュリティにいつデータをマスクするか、サポートにいつチケットを削除するか、そして調達にどの証跡がワークフローの統制を示すかを伝えます。
Flatkeyがこの文脈で有用なのは、現在の公開サイトがflatkey.aiを、公式のGPT、Claude、Gemini、その他のモデルトラフィック向けの単一APIキーとして位置づけ、利用分析、コスト制御、提供元をまたぐ単一請求書を備えていると示しているためです。これを、統合されたアクセスおよびレビューの表面として扱ってください。自社のデータ分類、法務レビュー、保持ポリシー、サポートマスキングワークフローの代替だとは考えないでください。導入前に、購入者アカウント内の正確なアカウント設定、ログ、エクスポート、保持動作、DPAの範囲を確認してください。
AI APIマスキングポリシー：短縮版
AI APIのマスキングポリシーは、プロンプトが本番環境に到達する前に、次の5つの運用上の問いに答えるべきです。
| Question | Policy decision | Owner |
|---|---|---|
| What data is forbidden in prompts? | Block secrets, payment data, raw credentials, private keys, and unsupported regulated data before the API call | Security owner |
| What data can be masked and sent? | Replace direct identifiers with tokens, hashes, labels, or synthetic placeholders when task quality still holds | Application owner |
| What gets stored in logs? | Prefer metadata-only logs by default; store payload excerpts only for approved debug cases | Platform owner |
| What can support see? | Redact customer prompts, outputs, attachments, screenshots, and traces before ticket sharing | Support owner |
| When can redaction be bypassed? | Require named exception, incident purpose, access limit, retention date, and legal/security approval | Governance owner |
実践上の目的は、役立つ詳細をすべて消すことではありません。目的は、プロンプト、出力、ログ、チケットを統制されていない機微記録に変えることなく、デバッグ、利用状況の照合、顧客サポートに必要な十分な証跡を残すことです。
正規表現一覧ではなく、データマップから始める
LLMプロンプトのマスキングは、チームが狭い正規表現のリストから始めると、たいてい失敗します。正規表現は明らかなパターンを見つけるのに役立ちますが、ポリシーを定義するものではありません。まず、AIトラフィックがどこに現れるかをマッピングしてください。
| Record surface | Typical fields | Default handling |
|---|---|---|
| Prompt body | User text, tool arguments, uploaded context, retrieved documents, system instructions | Classify before send; block or tokenize sensitive values |
| Model output | Generated answer, citations, tool calls, code, structured JSON | Scan before display, storage, export, or ticket copy |
| Gateway metadata | Provider, model, status, latency, token count, request ID, workspace, environment | Keep for ops and billing unless it reveals sensitive content |
| Gateway payload log | Prompt, response, tool input/output, attachments, embeddings input | Off by default or short-retention debug vault |
| Support ticket | Customer report, copied prompt, output, screenshots, HAR files, stack traces | Redact before sharing broadly; separate incident evidence from routine support |
| Analytics export | Cost rows, usage rows, customer/team labels, error categories | De-identify labels when exports leave the operational team |
このマップは、AI APIマスキングポリシーの付録にすべきです。これによりレビュー担当者は、どのフィールドが分類対象か、どれがマスクされるか、どれが保持されるか、どの役割が例外を承認できるかを具体的に確認できます。
モデル呼び出し前にプロンプトを分類する
プロバイダーの保持制御は重要ですが、プロンプトの衛生管理の代替にはなりません。OpenAIの現在のAPI data controlsでは、顧客が明示的にオプトインしない限りAPIデータはOpenAIのモデル訓練に使用されないとされていますが、同時に、プロンプト、応答、派生メタデータを含む可能性があり、既定で最大30日保持される不正利用監視ログについても説明しています。AnthropicのAPIおよびデータ保持に関するドキュメントも同様に、データ処理の取り決め、ゼロデータ保持、そして安全性フラグが付いた入力と出力が保持される場合を区別しています。
つまり、ポリシーは「プロバイダーが学習に使わないから」という点だけに依存すべきではありません。本番向けのAI APIマスキングポリシーでは、境界を越えてはならないものを定義する必要があります。
| データの種類 | 推奨アクション | 置換例 |
|---|---|---|
| APIキー、セッショントークン、OAuthリフレッシュトークン、秘密鍵 | リクエストをブロックし、所有者に通知する | SECRET_BLOCKED |
| 支払いカード番号と銀行情報 | 準拠し承認済みの支払いワークフローが存在しない限りブロックする | PAYMENT_FIELD_REMOVED |
| パスワードまたは復旧用の回答 | ブロックし、セキュリティチケットを作成する | CREDENTIAL_REMOVED |
| タスク品質に不要な直接的な個人識別子 | トークン化または一般化する | CUSTOMER_4821, city_region |
| デバッグに必要なアカウントID | ハッシュ化するか、内部の代理IDを使用する | acct_hash_... |
| 内部システムプロンプトと非表示のポリシーテキスト | ユーザー入力やサポートチケットに露出させない | SYSTEM_CONTEXT_REDACTED |
プロンプト分類器は、有用であるために完璧である必要はありません。必要なのはエスカレーション経路です。リクエストに認証情報が含まれている場合はブロックします。モデルが必要としない個人データが含まれている場合はマスキングします。製品が本当に機微な値を必要とする場合は、文書化された目的、限定されたモデル経路、保持責任者、レビュー担当者を求めます。
独自の分類器を構築しているチームには、Google Sensitive Data Protection が、非識別化およびマスキング変換の概念に関する有用な公式参考資料です。特定のゲートウェイにそれらの制御が有効になっている証拠としてではなく、設計パターンの参照元として使用してください。
記録になる前に出力をスキャンする
プロンプト出力のプライバシーは、チームがモデルの回答を表示用の成果物と捉えるため、見落とされがちです。実際には、出力はチケットにコピーされ、チャット履歴に保存され、分析に埋め込まれ、バグレポートに添付され、顧客メールに貼り付けられます。出力ポリシーは、少なくとも次の4つのリスクをカバーすべきです。
| 出力リスク | 制御 |
|---|---|
| モデルが機微なプロンプト内容を繰り返す | 保持やサポート共有の前に生成テキストをスキャンする |
| モデルがシステム指示や非表示の文脈を明かす | ポリシー/前文の漏えいパターンを検出してブロックする |
| モデルが個人情報や財務情報をでっち上げる | 規制対象または顧客影響のある用途の前に、ソースを意識したレビューを義務付ける |
| モデルに安全でないコード、秘密情報、認証情報が含まれる | 隔離し、セキュリティレビューに回す |
OWASPのLLM02機微情報漏えいのリスクカテゴリは、漏えいを、個人データ、財務情報、健康記録、機密の業務データ、認証情報、法的文書を含み得るモデルおよびアプリケーションのリスクとして位置づけています。これは重要な注意点です。AI APIのマスキングポリシーは入力フィルタリングだけではありません。出力検査、保存制御、サポートワークフロー制御でもあります。
リスクの高いワークフローでは、生成された回答を生のプロンプトから分離しておきます。通常運用ではマスク済みのトランスクリプトを保存し、承認済みの目的がある場合にのみ、制限されたインシデント保管庫に生の証拠を保持します。
AI APIログのマスキングをメタデータ優先にする
AI APIのログマスキングは、メタデータ優先のデフォルトから始めるべきです。ほとんどのプラットフォームチームは、リクエストID、モデル名、ステータスコード、レイテンシ、トークン数、ルート試行、環境、所有者、コスト項目を必要とします。生のプロンプトと生のレスポンスは、常に必要とは限りません。
CloudflareのAI Gatewayのロギングドキュメントは、この区別が重要である理由を示す良い例です。ログの収集とログペイロードの収集を別々に扱う制御に加え、ポリシーが発火した際のDLPフィールドも文書化しています。VercelのAI Gatewayオブザーバビリティドキュメントは、監視とデバッグのための支出、モデル使用量、可観測性メトリクスのログ記録を説明しています。これらの例は、Flatkeyの機能主張ではありません。どのゲートウェイ購入者も評価すべき運用パターンを示しています。メタデータ、ペイロード、DLPシグナル、保持、削除は別々の判断です。
このログポリシーをベースラインとして使用してください。
| ログ項目 | デフォルト | 例外 |
|---|---|---|
| リクエストID、ワークスペース、環境、ルート、モデル、プロバイダー | 保持する | なし。サポートと監査に必要 |
| ステータス、エラーコード、レイテンシ、リトライ/フォールバックイベント | 保持する | なし。信頼性レビューに必要 |
| トークン使用量とコスト見積もり | 保持する | 必要な場合は、財務エクスポートで顧客/チームラベルを非識別化する |
| プロンプトとレスポンス本文 | デフォルトでは保存しない | 名前付きインシデントを伴う短期保持のデバッグ保管庫 |
| ツール引数とツール出力 | フィールドごとにマスクし、承認済みのスニペットのみを保存する | セキュリティインシデントまたは再現可能なバグケース |
| DLP一致カテゴリ | ポリシーIDとカテゴリを保持する | 一致した秘密そのものは保存しない |
AI APIのマスキングポリシーは、削除の仕組みも定義すべきです。誰がログを削除できるのか。誰が法的保全を設定できるのか。生のペイロードが削除された後、派生分析はどうなるのか。チームがこれらの質問に答えられないなら、ペイロードロギングは広範な本番利用にまだ適していません。
広がる前にサポートチケットをマスクする
サポートチケットは、慎重に設計されたエンジニアリング制御が漏れやすい場所です。顧客がチケットに完全なプロンプトを貼り付けます。エンジニアがリクエスト本文付きのトレースを添付します。スクリーンショットにキーが含まれます。サポート用マクロがスレッドを別ベンダーに転送します。すると、機密レコードはもはやモデルの経路上にあるだけではなく、ヘルプデスク、メール通知、データウェアハウスのエクスポート、インシデントの事後検証にも存在することになります。
AI APIのマスキングポリシーでは、サポートを別個の面として扱うべきです:
| サポート成果物 | 必要なレビュー |
|---|---|
| コピーされたプロンプトまたはモデル出力 | 広範なサポート閲覧の前に、識別子、シークレット、規制対象データをマスキングする |
| スクリーンショット | キー、メールアドレス、顧客ID、リクエスト本文、非表示のプロンプトを切り抜くかぼかす |
| HARファイルまたはトレース | 認可ヘッダー、Cookie、ペイロード、署名付きURLを除去する |
| チケット添付ファイル | エスカレーション前に機密ファイルをマスキングまたは削除する |
| ベンダーへのエスカレーション | 生の顧客コンテンツではなく、最小限の再現データを共有する |
Zendeskの公式APIドキュメントは、チケットコメント内の文字列に対するマスキングと、別個のコメント添付ファイルのマスキング用エンドポイントを文書化することで、この運用モデルを支えています。チームが別のヘルプデスクを使っていても、ポリシー上のポイントは同じです。サポートのマスキングは、誰かが漏えいした値に気づいた後の場当たり的な片付けではなく、明示されたワークフローであるべきです。
インシデントの前に例外を定義する
厳格なポリシーには、制御された例外経路が必要です。これがないと、チームは非公式にポリシーを迂回するか、本番問題を解決するための証拠を少なすぎる状態で残してしまいます。
次の例外記録を使用してください:
| 項目 | 必須値 |
|---|---|
exception_id |
インシデントまたは調査に紐づく一意のID |
business_purpose |
デバッグ、不正調査、安全性レビュー、法的保全、または顧客承認済みサポート |
data_scope |
デフォルトで「完全なペイロード」ではなく、許可される正確なフィールド |
access_group |
時間制限付きアクセス権を持つ、名前付きの担当者または役割 |
retention_until |
例外を終了する日付またはイベント |
reviewer |
セキュリティ、法務、プライバシー、またはプロダクトオーナー |
customer_notice_required |
理由付きの yes/no |
deletion_or_redaction_task |
ループを閉じるフォローアップチケット |
例外経路は、軽率な生データアクセスを防げるだけの厳しさと、インシデント対応に十分な速さの両方を満たすべきです。日常的なデバッグには、まず合成再現データまたはマスキング済みのフィクスチャを使用してください。法的保全では、弁護士の指示により必要な範囲のみを保持してください。カスタマーサポートでは、元のサポート文脈の外で顧客提供の生コンテンツを使用する前に、同意を求めてください。
ポリシーに責任者を明記する
責任者のいないポリシーは、棚に置かれたまま使われない文書になります。面ごとに判断責任を割り当ててください:
| 対象面 | 主担当 | 副担当 | レビュー頻度 |
|---|---|---|---|
| プロンプト分類器とブロックルール | セキュリティエンジニアリング | アプリケーションプラットフォーム | 毎月およびインシデント後 |
| 出力スキャナー | プロダクトエンジニアリング | Trust and Safety | 毎月 |
| ゲートウェイログの項目 | プラットフォームエンジニアリング | セキュリティエンジニアリング | 四半期ごと |
| 保持スケジュール | プライバシー/法務 | セキュリティエンジニアリング | 四半期ごと |
| サポートのマスキングワークフロー | サポート運用 | セキュリティ運用 | 毎月 |
| エクスポートおよび分析の非識別化 | データ/財務運用 | プライバシー/法務 | 四半期ごと |
| 例外承認 | セキュリティ/プライバシー委員会 | インシデントコマンダー | すべての例外ごと |
大規模なモデル変更、新しいモダリティ、新しいサポートツール、新しいデータ処理者、そしてプロンプトまたは出力の露出を伴うインシデントの後には、AI APIのマスキングポリシーを見直してください。マスキングは一度きりの正規表現プロジェクトではありません。AIトラフィックのライフサイクルに追随する、生きた制御です。
Flatkeyの購入者がこのポリシーをどう使うべきか
チームが統合されたAI APIアクセスを評価している場合は、このポリシーを調達チェックリストとして使用してください。トラフィックが直接のプロバイダーアカウント、社内プロキシ、またはマネージドゲートウェイのどれを通る場合でも、同じ質問をしてください:
- どのリクエスト項目が、ログ、エクスポート、請求書、ダッシュボード、サポートワークフローで見えるのか?
- ペイロードログは無効化、範囲限定、または期間制限できるのか?
- 生のプロンプトと出力を閲覧できるのは誰か?
- サポートチケットと添付ファイルはどのようにマスキングされるのか?
- どの保持設定が契約上のものか、設定可能なものか、または運用上の慣行にとどまるのか?
- プロバイダーはサブプロセッサー、DPAの範囲、法的保全、削除要求をどのように扱うのか?
- 生の顧客コンテンツをエクスポートせずに、購入者が監査用にエクスポートできる証拠は何か?
Flatkeyの現在の公開ページでは、1つのキー、モデルアクセス、使用状況分析、コスト管理、プリペイド残高、そしてプロバイダーをまたぐ1つの請求書を中心に据えています。そのため、AI APIの運用レビューを一元化するための関連性の高い場所となっています。ただし、購入者は、いかなるゲートウェイもプライバシー、保持、またはサポート証跡のシステム・オブ・レコードとして扱う前に、アカウント固有の制御を確認する必要があります。現在のプラン、モデル、チャージに関する文脈については、承認前にFlatkeyの料金を確認してください。
実装チェックリスト
初回の本番リリース前に、このチェックリストを使用してください：
- プロンプト、出力、メタデータ、ログ、チケット、スクリーンショット、エクスポートの各フィールドを分類する。
- AI APIリクエストの前に、シークレットと認証情報をブロックする。
- タスク品質に不要な個人識別子は、トークン化または一般化する。
- メタデータログを既定で保存し、RAWペイロードの取得には承認を必須にする。
- 承認済みのデバッグ用ペイロードには、短い保持期間を設定する。
- 保存、分析エクスポート、またはサポート共有の前に、出力をスキャンする。
- エスカレーション前に、サポートチケット、添付ファイル、スクリーンショット、トレースをマスキングする。
- 例外の責任者、保持日付、削除タスクを文書化する。
- プロバイダーのデータ制御、DPA条件、サブプロセッサーの範囲、アカウント設定を確認する。
- インシデント、新しいモデル、新しいサポートツールの後に、AI APIのマスキングポリシーを見直す。
よくある質問
AI APIのマスキングポリシーとは何ですか？
AI APIのマスキングポリシーは、プロンプト、モデル出力、ゲートウェイログ、エクスポート、サポートチケット全体で、どの機微なフィールドをブロック、マスク、トークン化、保持、削除、または承認すべきかを定義します。これは、フィールド単位の取り扱いと責任者を割り当てるため、プライバシー表明よりも具体的です。
プロバイダーのゼロデータ保持だけで十分ですか？
いいえ。ゼロデータ保持または変更された保持設定は、プロバイダー側の保存を減らすことはできますが、自社のプロンプトの分類、ログのクリーンアップ、サポートチケットのマスキング、エクスポートの統制までは行いません。プロバイダーの保持は、より広範なAI APIマスキングポリシーの中の1つの制御として扱ってください。
AI APIログにはプロンプトと出力を含めるべきですか？
ほとんどの本番トラフィックでは、メタデータのみのログを既定にすべきです。RAWのプロンプトと出力は、デバッグまたはコンプライアンス目的が承認され、アクセスが制限され、保持期間が短く、クリーンアップ作業が追跡されている場合にのみ保存してください。
サポートは顧客のプロンプトをどのように扱うべきですか？
サポートは、再現に必要な最小限の情報のみを求め、広範囲への共有前にコピーされたプロンプトと出力をマスキングし、トレースやスクリーンショットからシークレットを除去し、RAW証跡は保持責任者がいる限定されたインシデントまたはサポートのワークフロー内にのみ残すべきです。
Flatkeyチームはどこから始めるべきですか？
ペイロードログ、データ保持、ゲートウェイガバナンスの内部連携から始めてください。AI APIペイロードログを確認し、AI APIデータ保持チェックリストと組み合わせ、あなたのGDPR AI APIゲートウェイチェックリストにマッピングし、その後キーを取得して、本番前にアカウント固有の設定を確認してください。
最終的なポイント
永続的なAI APIマスキングポリシーとは、開発者、サポートチーム、プライバシーレビュー担当者、財務責任者の全員が運用できるものです。有用なメタデータは保持してください。機微な値が拡散する前にマスクまたはブロックしてください。RAWペイロードは、明示された例外に対してのみ保存してください。サポートチケットはエスカレーション前にマスキングしてください。そして、ゲートウェイのレビュー画面、最新のプロバイダードキュメント、そして自社のDPA証跡を用いて、そのポリシーが単に文書化されているだけでなく、実際に機能していることを証明してください。
