Firecrawl、データ保持ゼロの修正を提案　Research と開発者向け検索への設定伝播を補完

Firecrawl のデータ保持ゼロ設定には、サービス間の伝播に抜けがあった。プロジェクトメンバーの mogery は10月25日、PR #5394 を提出し、Research エージェントが当初、検索側のモードだけを見てデータ保持ゼロ（ZDR）を有効にするか判断していたと指摘した。チームが scrapeZDR: "forced" だけを設定した場合、Research、GitHub、開発者向け、政府機関向けの各検索では、データを全面的に保持する処理が続いていたという。これは提案者による既存の挙動の説明であり、影響を受けた顧客数や実際のデータ保持事例を示す公開証拠は現時点でない。修正提案

この問題には、異なる2種類の制御が関係している。公式の検索ドキュメントによると、enterprise パラメーターは検索部分を制御し、スクレイプ側の zeroDataRetention オプションとは別に設定される。エンドツーエンドの ZDR では、Firecrawl と上流の検索プロバイダーの双方がクエリーや結果を保存しないことが求められる。一方、匿名化モードでは、上流側が匿名化されたクエリーをキャッシュすることが許容される。Research エージェントや RAG パイプラインを構築するチームにとって、各リクエスト区間でどのモードが使われるかを確認することは、データ処理の境界に直接関わる。検索と ZDR のドキュメント

この提案では既存の設定解析関数を使い、スクレイプ側または検索側のいずれかで ZDR が強制されていれば、関連する Research コントローラーに保持制限を適用する。具体的な変更には、requests.target_hint のマスキング、Research のデータテーブルにある機微なフィールドの消去またはマスキング、クリーンアップジョブの登録、ログへの ZDR マーカーの付与とフィルターによる除去が含まれる。Research、開発者向け、政府機関向けサービスに送るヘッダーも firecrawl-zero-data-retention: true に変更される。実装の説明

エンジニアリング上の教訓は、クライアント側のフラグを確認するだけでなく、入口からデータベース、ログ、上流サービスまで、各段階で保持ポリシーを検証する必要があるということだ。提案者はテストの追加を記載しているが、ページには Research の深度テストが5件失敗したとも表示されており、それが修正に関連するかは判断できない。確認時点では PR はオープンのままで、正式な修正版やデプロイを裏付ける証拠はない。今後はマージとリリースの状況を追跡し、スクレイプ側の ZDR だけを強制するチーム設定で、フィールドのマスキングと上流へのヘッダーを検証する必要がある。テストと提案の状況