Cloudflare AI Gateway のログ設定：制御とテスト

Cloudflare AI Gateway のログ設定は、チームが必要とする証拠と、保存を避けるべき内容から始めます。ダッシュボードは要求を見えるようにする一方、プロンプト、応答、メタデータの新しい保存場所にもなり得ます。適切な設定は運用目的と、アカウントの現行ログ契約の両方に依存します。

現行の Workers Logs と Legacy Logs のどちらが適用されるかを確定し、収集と本文保存を意識して設定します。機密情報を含まない合成マーカーで実際の要求経路を試し、できた記録を確認してください。必要な運用情報を保持しつつ、本文保存を止めれば他のすべてのシステムからも内容が消えるとは考えないでください。

プロンプトに顧客とのやり取りを含む、サポートアシスタントを考えます。技術者はプロバイダー障害の診断と使用量の帰属を知る必要がありますが、やり取りの全文を一般診断用の保存先へコピーする必要はないかもしれません。これは設定と証拠の問題であり、可観測性を諦める理由ではありません。

このガイドは運用設定の提案を扱います。法的な適合認証ではなく、すべてのアカウントが同じ料金、保持、エクスポートの条件を持つとも想定しません。

Cloudflare AI Gateway のログ設定は適用条件で変わる

現行の AI Gateway ログ文書 は、最初のゲートウェイを作った時期で顧客を分けています。2026 年 9 月 24 日以降に最初のゲートウェイを作った顧客は Workers Logs の料金と保持に従い、それ以前の顧客は Legacy Logs を利用します。設定する実際のアカウントで、この条件を確認してください。

古い記事の保持期間やログの利用枠を、すべての配置に適用しないでください。該当するサービス条件、選択設定、確認日を記録します。アカウントやログ構成が変わったら再確認します。

同じ文書は、ログ項目全体の収集と、その中の要求、応答本文の保存を区別しています。ログが有効か無効かという二択より、必要な内容を精密に話し合えます。

最初に障害調査の質問を定義する

運用担当が答える必要のある質問を書きます。失敗した負荷、使ったプロバイダーとモデル経路、再試行の有無、ユーザーが待つのをやめる前に応答したか、宛先作業は未解決か、といった問いです。

多くは限定したメタデータとアプリの操作番号で答えられ、常に完全なプロンプトを必要とはしません。一方、内容品質の調査には、一般的な要求情報では説明できない、明示して管理するサンプルが必要なこともあります。

用途を分けてください。日常診断と、正式に認められた調査では、異なる確認済みの証拠手順を使えます。いつか不具合の再現に使えるかもしれないという理由で、全顧客の文章を永久保存してはいけません。

既存の AI Gateway ガイド は、より広いプロキシと費用制御の役割を扱います。ここでの設定作業は、実際にどの証拠が存在するかと、選んだ収集動作を確定することです。

項目全体と本文の制御を分けて設定する

Cloudflare は項目全体の収集に cf-aig-collect-log、要求と応答の本文保存に cf-aig-collect-log-payload を説明しています。後者を false にすると本文なしでメタデータを残せます。項目全体を無効にすると、メタデータを含む項目が収集されません。適用前に現行のヘッダーの意味を読んでください。

以下はヘッダー方針の例であり、完全な要求でも、配置後の動作の証明でもありません。

1cf-aig-collect-log-payload: false

信頼できるアプリコンポーネントで方針を適用します。一般の呼び出し元が任意の制御ヘッダーを挿入して、組織の証拠方針を変えられてはいけません。サーバーが転送、設定、削除するヘッダーを決めます。

一度の成功から既定値を推測しないでください。ゲートウェイ設定と要求別の上書きを別々に確認します。主モデルで動く設定でも、フォールバックや別クライアントでは異なる可能性があります。

実際に適用される方針を記録する

アプリ側の設定を版管理し、関係するゲートウェイ設定を残します。どの要求種類が本文を保持し、どれがメタデータのみで、どれが収集しないかを説明します。

別のモデル連携を追加する際も、ログ経路を確認対象にします。そうしなければ、チームは一つの全体方針だと思っていても、異なる保持動作の経路が増えていきます。

メタデータを別の本文にしない

業務内容を直接表さない作業番号と要求番号で、ゲートウェイの証拠とアプリ記録を結べます。既存権限の中で原本を探すにはサポート番号で十分かもしれません。件名やメールアドレスをメタデータへコピーすれば、本文を除く理由が失われます。

許可するメタデータのスキーマを定義します。名前だけでなく値も調べます。label という項目でも、ユーザーの文章で埋めれば個人情報や機密内容になり得ます。

調査できるだけの一貫した参照番号を、アプリとゲートウェイに使います。全文を別の道具へコピーしたり、すべての技術者に顧客システムを開放したりせず、失敗を追跡できる必要があります。

合成マーカーで収集を検証する

識別しやすい印を含む、機密情報のない要求を送ります。該当する保存先で、想定する方針の下、その印が本文、メタデータ、出力先、アプリログに現れるかを確認します。

通常応答、上流エラー、利用している場合は代替経路も試します。エラー処理は、通常の収集経路外で要求本文を診断フィールドへコピーしやすい場所です。

Cloudflare のゲートウェイ認証の文書 がアクセス制御の参照先です。ログ設定が接続先も守ると想定せず、実際の認証情報と経路を確認します。

エクスポートと他の保存先も確認する

ゲートウェイで本文を抑止しても、アプリ、モデルプロバイダー、外部監視サービスが何も保存しない証明にはなりません。実際のデータ経路を図示し、それぞれ固有の契約で確認します。

ログを出力するなら、宛先を読める人とコピーの期限を記録します。一つのサービスから消しても、以前の出力が消えた証明にはなりません。どのシステムがどの証拠を担当するかを手順書に示します。

追跡、例外管理、サポートの画面画像も確認します。ゲートウェイが正しくても、広い担当者が見られるチケットへ顧客プロンプトを貼ることはあり得ます。

通常の回帰テストは合成例を使います。実内容で調査する必要があれば、記録なしに一般方針を変えず、特定の目的と管理されたアクセスを定めます。

有用な証拠と保守に予算を付ける

実装には、経路確認、要求方針の組み込み、メタデータ設計、権限準備、検証が含まれます。継続費用はログ条件、量、下流保存先に依存するため、見積もり前に現行のアカウント料金を確かめます。

ゲートウェイ条件と納品するテストを示した GBP の提案を求めます。設定だけの仕事と、複数モデルや出力先のログを作り直す仕事では、範囲が異なります。

引き継ぎには、実際の方針、責任者、合成テスト結果、証拠不足を調べる方法を含めます。新しいクライアント、経路、保存先など、再検証を必要とする変更も列挙します。

当社の範囲を限定した AI 連携パイロット で確認できます。アカウント条件、モデル経路、現在の保存先、障害時の問いを添えてゲートウェイのログ評価をご依頼 ください。既定で可能だから保存するのではなく、役立つ可観測性にできます。

よくある質問

すべてのアカウントで同じログ条件ですか？ いいえ。現行文書は、最初のゲートウェイを 2026 年 9 月 24 日以降に作った顧客と、それ以前を分けています。料金や保持の前提に頼る前に Workers Logs と Legacy Logs のどちらかを確認します。

本文なしでメタデータを保持できますか？ 文書化された本文制御は、適切な設定でメタデータのみの項目を可能にします。ゲートウェイと要求別方針を検証し、実際の保存先のテスト記録を確認します。

二つの収集ヘッダーはどう違いますか？ 項目全体の制御はログ収集そのものを決め、本文制御はメタデータを残しながら要求と応答の原文保存を決めます。全体を止めるとメタデータもなくなるので、必要な証拠から選びます。

本文を止めれば他のサービスも保存しませんか？ いいえ。アプリログ、プロバイダー、出力先、監視道具には別の動作と契約があります。一つの設定を普遍的な保持保証にせず、全経路を確認します。

顧客データなしでどうテストしますか？ 機密情報を含まない要求に合成マーカーを入れ、記録と出力を調べます。通常、エラー、再試行、フォールバックを含め、メタデータへ間接的に入らないかも確認します。

クライアントがログ方針を選んでよいですか？ その権限を意図して与える場合だけです。組織方針は信頼できるサーバーで適用し、受理または上書きするヘッダーを決めます。一般の利用者が黙って変えてはいけません。

評価では何を納品すべきですか？ 適用契約、保存先、実効方針、アクセス責任者、保持の判断を特定します。合成検証結果と、新経路や保存先を繰り返し確認する手順も含めます。