この記事の目次
AIにエラーの相談をした。原因が分かって、作業はおしまい。会話の画面も閉じました。
そのとき渡した設定ファイルや、AIが読んだコマンドの結果は、どこへ行ったのでしょう。
「自分のPCで使っているから、外には出ていないはず」「画面から消したから、もう残っていないはず」。そう思いたくなる場面です。でも、画面に見えている会話と、保存される記録は同じものとは限りません。
この記事は、AIに開発や調査を手伝ってもらい、設定・ログ・スクリーンショットを扱う人に向けたものです。秘密をうっかり見せた人を責める話ではありません。どこに写しができるのかを、一つずつほどいていきます。
画面を閉じても、別の場所に写しがある
たとえば、AIに「この接続エラーを調べて」と頼んだとします。AIが設定ファイルを開き、その内容がツールの結果として会話に入る。すると、元のファイルとは別に、会話の記録にも情報が含まれる可能性があります。
さらに、編集前のファイルの控え、画面のスクリーンショット、PCのバックアップもあります。元のファイルだけを直しても、すでにできた写しまで同時に直るわけではありません。
1つの情報でも、保存先は1つとは限らない
- AIへの入力・ツール出力
貼り付けた文章、読み込んだファイル、画面の内容。
- 端末の記録
会話の履歴・編集前の控え・一時ファイルを確認。
- サービス・接続先
送った先の保存・共有設定を別に確認。
- 同期・バックアップ
端末やフォルダーの写しが、どこに残るか確認。
この図は、確認先を整理するための見取り図です。すべての製品がすべての場所に保存する、という意味ではありません。製品・版・設定・接続先によって異なります。
具体例として、Claude Codeの公式資料には、会話の記録や編集前ファイルの履歴など、ローカルに保存されるデータが説明されています。保存先を変更できる構成もあるため、使っている環境の説明で確かめます。Claude Code公式：.claudeディレクトリ
閉じたのは、画面。それとも記録？
消えたように見えるときこそ、保存先を分けて考えます。AIに「消した？」と聞くだけでは、バックアップや接続先の状態までは確認できません。
残す項目を変えると、記録はどう変わる？
自分で作ったアプリのログでも、同じことが起きます。エラーを調べたいからと、リクエスト全体を記録すると、処理に使う秘密まで一緒に残してしまうことがあります。
ここでは、本物のキーもファイルも使いません。メモリ上の架空のデータだけで、「全部を記録する」と「必要な項目を選ぶ」の違いを見ます。実行しなくても、下の出力と見比べられます。
const request = {
operation: "summarize",
text: "練習用メモ",
token: "DEMO_TOKEN_DO_NOT_USE",
};
const fullLog = JSON.stringify(request);
const selectedLog = JSON.stringify({
operation: request.operation,
characters: request.text.length,
});
console.log("全文ログにダミー値が残る:", fullLog.includes(request.token));
console.log("項目を選んだ記録:", selectedLog);全文ログにダミー値が残る: true
項目を選んだ記録: {"operation":"summarize","characters":5}上の例はファイル保存・通信・環境変数の読み取りを行いません。trueは、架空の秘密が文字列に入ったという結果です。画面にはその値自体を出していません。
残す項目を選ぶと、分かることも変わる
- データ全体を文字列にする
処理に使ったダミーの秘密まで、記録に含まれる。
全文ログ：ダミー値を含む → true
- 必要な項目だけを選ぶ
操作名と文章の長さを記録。文章や秘密の値は選ばない。
要約処理 / 5文字
選んだ記録なら、操作名と文章の長さは分かります。一方、文章の内容は分かりません。それで調査に足りるかは、アプリの目的に応じて決めます。
これは万能なマスキングではありません。操作名に個人情報を入れれば、選んだ項目からでも漏れます。例外のメッセージや外部サービスの返答にも注意が必要です。「記録した後で隠す」前に、そもそも何を記録する必要があるかを絞ります。
実際に、会話ログから認証情報が見つかった
分類：事故の公表。 2026年10月15日公開のSato Kotaroさん「Claude Codeの会話ログは棚卸対象です」は、著者自身の保存先から、認証用トークンやパスワード入りの接続文字列が見つかったという報告です。
ここで確認できるのは、秘密が別の記録に残っていたという著者の報告です。外部の第三者に流出したことが確認された事例として紹介しているわけではありません。また、その保存先や保持設定が、ほかの製品や現在の自分の設定にもそのまま当てはまるとは限りません。
この事例から持ち帰りたいのは、会話だけでなく、ツール出力や編集前の控えも確認対象になるという視点です。元記事の一括対処や設定値を、そのまま自分の環境に当てはめる必要はありません。
自分の環境では、3か所を分けて見る
一人で開発していても、「使う人」「端末を管理する人」「共有先を管理する人」の視点を分けると、見落としに気づきやすくなります。
AIを使う人：何を見せたか
貼り付けた文章だけでなく、AIに読ませたファイル・ツールの出力・スクリーンショットも振り返ります。実際の値を別のチャットへ貼り直して相談するのは避けます。
確認するのは、まず情報の種類と関係した保存先です。「顧客の連絡先を含む画面」「テスト用の認証情報」のように、値を写さず整理します。AIに渡す前の線引きは情報の境界の教材も使えます。
端末を管理する人：誰が記録を読めるか
公式資料でログ・履歴・一時ファイルの場所を確認し、端末の利用者、同期、バックアップの対象を調べます。「PCの中」でも、共有フォルダーや別アカウントから読めるかどうかは別の話です。
実データを広く検索して値を表示するより先に、対象範囲と調査方法を決めます。業務の端末なら、管理者や情報管理の担当者へ相談します。
接続先を管理する人：どこまで送ったか
AIサービス、MCPの接続先、共有ストレージを別々に見ます。保存・学習利用・保持期間・閲覧できる人は、サービスの契約や設定で確かめます。端末から削除しても、送信先の保存データは別に確認します。
使う人・端末・接続先を分けて見る
- 何を見せた？
入力だけでなく、AIが読んだ結果や画像も対象。
- どこに残る？
会話、編集履歴、一時ファイルとバックアップ。
- 誰が読める？
端末・共有先・AIサービスの権限と契約を確認。
消す前に、何のための記録かを決める
ログは、トラブルや不正な操作を後から調べる材料にもなります。すべてを消すと、何が起きたか分からなくなることがあります。一方、目的なく長く残せば、秘密を扱う場所が増えます。
記録を役立てながら、残す範囲を絞る
- 調査に必要な記録
目的と担当を決め、読める人を制限して保全する。
何が起きたかを後から確かめる
- 不要になった記録
保存義務と調査の要否を確認し、決めた手順で扱う。
期間・削除対象・バックアップも確認
保存する目的、必要な項目、閲覧できる人、保存期間と削除方法をセットで決めます。仕事のデータなら、契約や社内の保存義務も確認します。OWASPのログ設計ガイドも、秘密を記録しない配慮と、記録を保護することの両方を扱っています。
もし、本物のキーを見つけたら
誰かが読める状態だったかもしれない場合は、ログを消すだけで終えません。発行元で失効・再発行を進め、利用履歴と公開範囲を確認します。調査に必要な記録は、担当者と相談して保全します。
ここまで確かめたら、次へ
- 入力と出力： AIに渡す必要のない秘密を除き、ツールが返す項目も確かめた。
- 保存先： 会話・編集履歴・一時ファイル・バックアップ・接続先を、確認済みと未確認に分けた。
- 閲覧範囲： 保存先を読める人と、同期・共有の有無を設定で確かめた。
- 保持方針： 目的・担当・期間・削除手順を決め、調査用の記録を無断で消さないようにした。
- 見つかった秘密： 値を再掲せず、必要な失効・再発行と利用履歴確認の担当を決めた。
「分からない」が残っていても構いません。どの保存先が未確認か分かれば、次に聞く相手を決められます。
次は、AIに触らせる範囲を決める
記録に残す情報を減らすには、AIに読ませる情報を減らすことも役立ちます。次はMCPの接続と権限で、読む・変える・送る範囲を整理しましょう。すでに漏えいが疑われる場合は、先に異常時の対応へ進みます。
一次資料と参考記事
情報確認日：2026年10月24日。製品の保存先・保持方法は変更されるため、利用中の版と設定を公式資料で確認してください。
- Claude Code公式：.claudeディレクトリ — ローカルに保存するデータの種類と構成。
- OWASP Logging Cheat Sheet — ログの項目選定、保護、保持の考え方。
- GitHub公式：機密データをリポジトリから削除する — 認証情報を公開した場合の失効・再発行と、削除だけでは回収できない写し。
- Sato Kotaroさん：Claude Codeの会話ログは棚卸対象です — 著者自身の環境に関する一次報告。本文の架空例と図は、本教材向けに作成しました。
書いた人
マーケティングの現場から、AIをつくり、仕事で使う側へ。実際に試したことや、つまずいたことを、図解と具体例で伝えています。
この記事のURL：https://nekoai-lab.github.io/ai-security-playbook/learn/ai-work-logs/
続けて読む
次に読むMCPをつなぐ前に、渡す権限を確かめる
