ログが既定で残るとき、AIアプリのデータ責任はどう変わるか

2026年10月26日、Googleは新規の有料プロジェクトでGenerate Contentのリクエスト保存を既定で有効にした。既存プロジェクトの設定は変わらない。プロジェクト作成は、請求先だけでなくデータの扱いを決める場面でもある。リリースノート

この違いは見落とされやすい。アプリケーションが同じ回答を返しても、残る記録は異なり得るからだ。サービス移行では、回答の正しさや業務フローが動くかを先に確かめることが多い。しかし、その試験だけでは、後から誰が会話を閲覧できるのか、どの複製が残るのか、保存した失敗例が何に使われるのかは分からない。確認対象はモデル呼び出しだけではなく、その後の情報の行き先にも及ぶ。

動作が同じでも、記録まで同じとは限らない

小売企業が顧客対応アシスタントを新しいプロジェクトに移す場面を考えてみる。プロンプト、顧客向け画面、返金ルールは変えず、機能テストにも合格した。それでも技術者には別の確認が必要だ。移行先に引き継がれたのは意図したデータ設定なのか、それとも同じアプリケーションコードだけなのか。

これは仮想例であり、報告された事故ではない。設定をリリース審査に含める理由を示している。正常な応答はシステムの一つの性質を証明し、適切な記録のライフサイクルは別の性質を証明する。両者は代替できない。「動くか」だけでは、回答から利用者には見えない変化を取りこぼす。

ここには実際のトレードオフがある。注文を読み違えたと顧客から指摘された際、やり取りの記録は原因の再現に役立つ。証拠が不足すれば、想像上の問題を修正したり、本当の障害を再現できなかったりする。一方、調査に役立つ記録にも、その目的と無関係な情報が含まれ得る。観測可能性の向上と不要な保持の削減は二者択一の標語ではなく、具体的な業務に合わせて調整する設計目標である。

複製は、最初の目的より長く残り得る

Googleの方針は、通常のログ保持、データセット保持、任意のモデル改善への共有を区別している。ログの方針

本稿が注目するのは用途の移行だ。技術者が失敗した会話を見つけ、明白な識別情報を除いて評価用の例として保存したとする。その例の価値は、今後繰り返し使える点にある。文章が見慣れたままで、元の会話が日常の操作画面から消えていても、この移行には明確な責任者と目的が必要になる。

氏名を取り除けば個人との結び付きが必ず消えるわけではない。注文の詳細、場所、珍しい事情が組み合わされば、背景を知る人には本人が分かるかもしれない。逆に、全てを一般的な仮の情報に置き換えると、誤りを起こした条件まで失われ得る。有用な評価例は、会話全体を当然のように保存するのではなく、試験すべき仕組みを残す。その切り分けが可能かどうかは、課題ごとに確かめる必要がある。

障害の証拠を集めることと、再利用できる試験を維持することは別の仕事になる。前者は「何が起きたか」を問う。後者は「同じ種類の誤りの再発を見つけるため、どの特徴が必要か」を問う。分けて考えれば、判断は具体的になる。住所検証の失敗を試すなら、ある表記の曖昧さは必要でも、実在顧客の購買履歴全体までは不要かもしれない。

これは、削除が完了したという理解にも関わる。担当者から元の記録が見えなくなっても、評価用の複製がなお有用か、誰がアクセスできるか、いつ目的を再審査すべきかは別問題だ。特定のシステムに欠陥があるという指摘ではない。情報が複製された後は、責任もその複製を追う必要があるという分析である。

一つの設定では全ての目的を説明できない

Googleは別途、不正利用の監視プロセスを文書化している。そのため開発者向けログを無効にしても、事業者が保持する全記録の消去とは説明できない。不正利用監視の文書

AIアプリケーションを評価する購入者にとって、「データは保存されるか」は出発点にすぎない。各複製の目的、責任者、その目的が終わる条件を示す方が役に立つ。同じ情報でも、障害調査、サービスの不正利用の検知、試験集の作成では必要な判断が違う。一つのリクエストに由来するからといって、それらを一つの決定にまとめる理由にはならない。

同様に、保存されたリクエストが全て汎用モデルの学習に使われると結論付けるのも誤りだ。保存、アクセス、再利用は異なる概念である。一つのプライバシー表示にまとめれば説明は簡単になるが、評価は難しくなる。違反も絶対的な安全も先に決め付けず、文書上の制御と実際の設定を照合することが重要になる。

見直しは、普段の開発の区切りから始められる。プロジェクトの作成、環境の移行、原因調査用の例の出力、評価集への登録である。それぞれの時点で、目的とアクセス範囲がなお適切かを確認する担当者が必要だ。これは運用上の分析枠組みであり、実施すれば自動的に法令順守が成立するという意味でも、全チームが同じ保持方針を持つべきだという意味でもない。

既定のログが、気付かれないまま続く誤りの発見を助けることはあり得る。無効化によって保持情報が減っても、失敗を説明できなくなる場合がある。判断は、必要な証拠、業務の機微性、代替手段によって変わる。本稿は顧客の設定を調査しておらず、情報漏えいを認定してもいない。

今回の変更から得られる実務上の示唆は、ログへの賛否よりも具体的だ。アプリケーションを作り直しても、それまでのデータ処理の前提が再現されるとは限らない。利用者に見える動作とともに、その前提も確認する必要がある。