「学習に使わない」なら、AIの作業ログも残らない？

きっかけは、Warpのログ露出に関する報道

10月27日付のBleepingComputerは、AI開発環境Warpの基盤で使う第三者ベンダーへの攻撃により、エージェントの処理の記録とテレメトリが露出したと報じました。同記事はCEOの説明として、影響の可能性がある利用者はおおよそ1%との推定を紹介しています。

ただし、この記事の確認ではCEO本人の投稿を直接取得できていません。事件については報道を確認した段階であり、一次発表との独立照合は未完了です。報道本文

APIキーの流出や、報道に登場する攻撃手法を、確認済みの事実として広げません。別製品の事故も、Warpで同じことが起きた証拠にはしません。

まず分けたい、三つの話

「学習に使わない」と説明されていると、情報がどこにも残らないように感じることがあります。しかし、確認する項目は別です。

これは確認箇所を分けるための概念図です。今回の侵入経路や、すべての製品の内部構成を示したものではありません。

一つの説明で、三つ全部を判断しない。 ここが最初の確認です。

公式資料で確認できたこと

Warpの企業向け公式資料は、モデル提供者とのZero Data Retention（ZDR）の説明とは別に、クラウド会話やクラウドエージェントの実行には、機能のための会話データ保存が必要な場合があると記しています。

また、一部モデルにはZDRの対象外となる保持条件があるとも説明しています。

したがって、ZDRという言葉だけで製品全体の保存先や例外まで判断できません。 誰と誰の契約で、どの機能・モデルに適用されるかを読みます。Warp公式：Security overview

なお、これは通常の製品仕様の説明です。今回どの保存領域が侵害されたかを確認したものではありません。

学習しない。それなら履歴も消える？

その条件が、モデル提供者・製品の履歴・解析用ログのどれを指すか、分けて読みます。

自分は何を使っている？ まず機能を一つ選ぶ

いきなり設定を全部変える必要はありません。普段使う機能を一つ選び、次を確認します。

Warpには送受信を確認するNetwork Logや、収集内容の説明があります。これらは保存・送信を確認する補助になりますが、利用者が確認できる通信だけで、サービス側のすべての保存や第三者への影響を証明できるわけではありません。Warp公式：セキュリティの説明

設定の画面を共有するときも、メールアドレス、ワークスペース名、内部の接続先などが写っていないか確認してください。

設定を見るときの注意：公式資料同士にも差がある

公式Privacy資料には、FreeプランのAI機能ではテレメトリが必要との説明があります。一方、企業向けSecurity overviewにはFree利用者も収集を無効化できるとの説明があります。一般向けSecurityページにも異なる説明がありました。

今回の確認では、この差の理由を確定できていません。

• 公式Privacy資料
• 公式の企業向け資料

そのため、プラン名だけで「オフにできる」「使い続けられる」「事故の対象外」とは案内しません。

Warpで確認する場合は、実際の Settings → Privacy、ワークスペース管理者の設定、適用される契約を照合します。公式資料にある「Help improve Warp」「Send crash reports」も確認候補ですが、設定を切った後の機能への影響は、自分の版とプランで確認してください。

いまの設定は、過去の設定の証明ではありません。 今日オフにしたことで、すでに送信した情報が削除されたとも判断しません。

秘密を隠す機能にも、適用範囲がある

WarpのSecret Redactionは、設定されたパターンに一致する秘密情報を検出し、送信前に伏せる機能です。公式資料では既定で無効と説明されています。テレメトリ側の伏せ字処理とは別の仕組みです。

さらに、公式資料はSession SharingではSecret Redactionが適用されないと説明しています。共有セッションは、画面共有に近いものとして扱います。Warp公式：Secret Redaction

ここから分かるのは、伏せ字を有効にしただけで、すべての経路が保護されるわけではないことです。パターンに一致しない情報もありえます。

実際のキーや個人情報を使って試さないでください。確認するなら、管理者と合意した架空のデータで、どの機能・経路に適用されるかを確かめます。

ログには、秘密以外にも残したくないものがある

APIキーを伏せた後にも、顧客名、社内URL、ファイル名、未公開の事業内容が残る場合があります。

例えば次は、説明用の架空ログです。

# 共有前：説明に不要な識別情報まで含んでいる
顧客Aの請求書を /internal/project-a/invoices/ へ保存できない

# 共有用：問題の説明に必要な情報だけへ置き換える
テスト用フォルダへの書き込みで権限エラーになった

これは製品の実際のログ形式でも、自動匿名化の実装例でもありません。

大事なのは、APIキーだけを探して終わらず、その相談に必要な情報だけを渡すことです。削りすぎて原因が分からなくなる場合は、公開の場へ丸ごと貼るのではなく、承認された相談経路を選びます。

今日の設定だけで、過去まで決めない

今オフにしても、過去の収集や既存の記録の削除まで確認できたことにはなりません。

通知が届いたら、何をする？

以下は一般的な確認の進め方です。今回の事案についてWarpから全利用者へ示された対応手順として書いているものではありません。

1. 通知の正当性を確認する。 メール内のリンクだけを頼らず、普段のアプリ・公式サイト・管理者から案内を確認します。
2. 対象期間・機能・データを確認する。 全利用者の話か、自分のアカウントの話かを分けます。通知がないだけで対象外とも断定しません。
3. 疑わしい操作や利用履歴を残す。 ログや通知を急いで削除せず、会社利用なら担当者へ引き継ぎます。
4. 認証情報への影響が分かったら対応する。 キーの露出が確認された、疑われる根拠がある、または提供元から指示された場合に、発行元で失効・再発行と利用履歴を確認します。

すべてのキーを根拠なく一斉に交換する手順にはしません。稼働サービスとの関係を確認し、被害拡大の防止とサービス継続の両方を判断します。

今日の確認は、この四つ

• 使う製品・プラン・ワークスペースと、履歴・共有・クラウド実行の利用を整理した。
• 学習利用、機能のための保存、テレメトリを別々に確認した。不明は未確認として残した。
• 伏せ字が適用される機能と、共有するときの例外を確認した。
• 通知が来たときの相談先と、認証情報の管理担当を確認した。

「コードを公開しない」だけで終わらず、そのコードを扱うAIの会話・出力・共有先も見直す。

最初の一歩は、いつもの機能を一つ選び、その情報がどこへ送られ、何のために残るかを確かめることです。