ログ・エラー文・DBの中身をAIに貼る前に:コード作業での渡してよい情報の線引き

先に押さえる:「学習されない」と「送られない」は別

線引きが必要な理由は、ツールの設定で変わるのが主に学習利用や保存であり、入力内容が事業者のサーバーに送られること自体は変わらないからです。2026年10月28日に開いた公式ページから、確認できた範囲を挙げます。

• Claude Code:プロンプトとモデルの出力はネットワーク経由で送信されます。学習利用はプランで異なり、Free・Pro・Maxはデータ利用設定がオンなら学習に使われ得ます。Team・Enterprise・APIなどの商用プランでは、顧客が提供に同意しない限り学習しないとされています。保存期間も設定とプランで異なります(例:個人向けで学習利用を許可しない場合は30日)。詳細はClaude Codeのデータ利用ページにあります。
• Cursor:Cursorのデータ利用ページによると、Privacy Modeがオンなら顧客データはCursorの学習に使われず、提供元モデル事業者ともゼロデータ保持の契約があるとされます。ただし不正利用の検知に該当した場合は調査のため一時保存され得ること、最終的なプロンプト構築はCursorのバックエンドを経由することも書かれています。オフなら、プロンプトやコード片を機能改善や学習に使い得るとされています。
• GitHub Copilot:コンテンツ除外はBusiness・Enterpriseプランの組織向け機能で、指定ファイルをCopilotに使わせない仕組みです。ただしIDE経由で間接的に渡る型定義などの意味情報は使われ得ること、VS CodeなどのエディタのCopilot ChatではEditモードとAgentモードに対応していないことが明記されています。

つまり、学習オフやPrivacy Modeは「秘密を預けてよい」という意味ではありません。さらに、Claude Codeは会話の記録をローカルにも平文で保存します(商用プランの記載では既定30日、場所は~/.claude/projects/)。一度貼った値は自分のPCにも残ります。

個人情報については、日本の個人情報保護委員会が2023年6月2日に生成AIサービスの利用に関する注意喚起を出しています。個人情報を入力するリスクが論点になっている、という点だけここでは押さえてください。自社データが法令や契約上どう扱えるかは、本文では判断できません。社内の情報管理ルールと契約を優先してください。

情報の種類別の判断表

以下は公式仕様ではなく、上の事実を踏まえた編集上の目安です。会社の規程が厳しければそちらに従ってください。

• 例外クラス名・エラーメッセージの定型部分、区分：渡す、扱い方：そのまま。ただしメッセージ内に値が埋め込まれていないか確認
• スタックトレース、区分：伏せて渡す、扱い方：行番号・関数名は残す。社内パッケージ名、ユーザー名入りの絶対パスは置換
• アプリケーションログ、区分：伏せて渡す、扱い方：該当の前後数行に絞る。ID・メール・IPは同じ値に同じ記号を振って置換
• HTTPリクエスト/レスポンス、区分：伏せて渡す、扱い方：Authorization、Cookie、クエリのトークン、ボディ内の個人情報を置換
• 設定ファイル・.env、区分：伏せて渡す(値は渡さない)、扱い方：キー名と値の「形」だけ。値は<SECRET>など
• 接続文字列、区分：伏せて渡す、扱い方：ユーザー、パスワード、ホストを置換。ポートとスキーム、DB種別は残す
• テーブル定義・インデックス、区分：渡す、扱い方：列名自体が機微(例:疾病名の列)なら置換
• 実行計画(EXPLAIN)、区分：伏せて渡す、扱い方：構造は残し、条件に含まれるリテラルを置換
• 本番DBのSELECT結果・ダンプ、区分：渡さない、扱い方：列の型、件数、NULLの有無、説明用の合成データで代替
• パスワード・APIキー・秘密鍵・セッショントークン、区分：渡さない、扱い方：貼ってしまったら失効・再発行
• 顧客の問い合わせ本文、氏名・住所・電話番号を含むデータ、区分：渡さない、扱い方：状況の要約だけを書く
• NDA対象や未公開のソースコード、区分：契約・社内規程次第、扱い方：自分では決めず、ツールの利用可否を確認

伏せ字への書き換え例

以下はすべて説明用の例で、実在のシステムとは関係ありません。また、これらの書き換えを実際のAIに貼って試した結果ではありません。

例1:ログとスタックトレース

置換前(説明用):

2026-10-28 10:15:32 ERROR OrderService - failed for user tanaka.taro@example.co.jp (id=88231)
java.sql.SQLException: Duplicate entry 'tanaka.taro@example.co.jp' for key 'users.uk_email'
    at com.acmecorp.shop.order.OrderRepository.insert(OrderRepository.java:142)

置換後:

<TIME> ERROR OrderService - failed for user <EMAIL_1> (id=<USER_ID_1>)
java.sql.SQLException: Duplicate entry '<EMAIL_1>' for key 'users.uk_email'
    at com.example.app.order.OrderRepository.insert(OrderRepository.java:142)

コツは、同じ値には同じ記号(<EMAIL_1>)を使うことです。「メッセージ内の値と、ログ行の値が同一」という情報が原因の手がかりになるため、全部を***にすると解析力が落ちます。一意制約名(users.uk_email)や行番号は秘密ではないので残します。

例2:HTTPリクエスト

POST /api/v1/payments HTTP/1.1
Host: api.<COMPANY>.example
Authorization: Bearer <TOKEN>
Cookie: session=<SESSION>
Content-Type: application/json

{"customer_id":"<CUSTOMER_ID>","amount":1200,"card_last4":"<LAST4>"}

金額や項目名は不具合の再現に必要なので残し、認証情報と顧客を特定できる値だけを置換します。

例3:接続文字列とエラー

postgres://<USER>:<PASSWORD>@<HOST>:5432/<DB>
FATAL: password authentication failed for user "<USER>"

「認証失敗」が分かれば相談できるので、実際のパスワードは不要です。

例4:DBの中身は「形」で伝える

本番の行をそのまま貼る代わりに、次のように書き換えます。

usersテーブル(説明用):
- email: varchar(255), UNIQUE, NOT NULL
- 重複エラーが出たのは同一メールの2行(大文字小文字だけ違う。値は伏せる)
- created_at: 2行とも2026-10-28(日付は残してよい場合)

再現に行そのものが必要なら、a@example.comとA@example.comのような合成データを作って渡します。

そのまま使える依頼文

以下はデバッグの相談です。ログ・エラー文は個人情報、認証情報、社内名称を
<EMAIL_1>のような記号に置換済みです。同じ記号は同じ値を指します。

【環境】Java 17 / Spring Boot 3.x / PostgreSQL(バージョンは実際のものに)
【起きていること】登録API実行時に一意制約違反が出る
【期待する動作】同一メールの重複登録は400で返したい
【ログ】(置換済みログを貼る)
【関連コード】(該当メソッドのみ。秘密値は含めない)

お願い:
1. 原因の仮説を可能性の高い順に3つ
2. それぞれを確認する方法(ログ出力の追加位置など)
3. 修正案。実データを使わない再現テストも
値の復元や推測はしないでください。

「復元しないで」と書いても情報が送られなくなるわけではなく、あくまで回答の方向づけです。守りは貼る前の置換で作ります。

貼る前の手順と、人が確認すること

1. 使っているプランと設定を確認する。Privacy Modeの状態、個人向けか商用か、会社が導入を許可しているツールか。
2. 範囲を絞る。ログは全文でなく、エラー前後の数十行にします。
3. 種類別に置換する。上の表の「伏せて渡す」を、同じ値には同じ記号で置換します。
4. 貼る直前に目視で検索する。@、Bearer、password、token、secret、BEGIN PRIVATE KEY、数字の長い並び、社名・ドメイン名を探します。これは自動検出ではないので、取りこぼしは起こり得ます。
5. 出力を確認する。AIが提案したSQLやコマンドを、内容を読まずに本番へ流さないでください。まずは合成データを入れたテスト環境で試します。

エージェント型のツールは、あなたが貼った文字列だけでなく、ファイルを自分で読みに行くことがあります。.envや秘密鍵のあるディレクトリを作業対象に含めない、機密ファイルを読ませない設定が使えるか確認する、といった事前の備えも必要です。使える設定はツールごとに異なるため、各公式ドキュメントで確認してください。

秘密情報を貼ってしまったときは、AI側の削除を探す前に、そのキーやパスワードを失効・再発行します。これが最も確実な対処です。