原因調査用のログをAIに足してもらう：出す情報と出してはいけない情報

まず線引きを決める：出す情報と出さない情報

OWASP のロギングチートシートは、パスワード、アクセストークン、暗号鍵、セッション識別値、データベース接続文字列などを、通常はそのままログに記録せず、削除・マスク・サニタイズ・ハッシュ化・暗号化するよう勧めています。氏名や電話番号、メールアドレスなども、必要性を検討し、本人を識別する必要がなければ削除や仮名化を検討します。

これを踏まえた、依頼時の判断表が次です。ここでの区分は原因調査用ログの目安です。情報の機微さや保管先、チームの方針に応じて調整してください。

• 処理名、関数名、手順番号、判断：条件付き、ログでの扱い方：内部構造や機密情報を含まない名前にする
• 件数、サイズ、経過時間、判断：条件付き、ログでの扱い方：個人や機密の内容を推測できない範囲にする
• 分岐の結果（true/false、選ばれた経路）、判断：条件付き、ログでの扱い方：機密情報を明かさない分類名にする
• エラーの種類、メッセージ、スタック、判断：条件付き、ログでの扱い方：入力値、パス、接続先などが含まれないか確認する
• 内部ID（注文ID、ジョブID）、判断：条件付き、ログでの扱い方：個人に結び付く可能性を確認し、必要なら一時的な相関IDなどに置き換える
• メールアドレス、氏名、電話番号、住所、判断：避ける、ログでの扱い方：出す必要があるなら「有無」だけにする
• パスワード、APIキー、トークン、Cookie、セッション値、判断：避ける、ログでの扱い方：「設定あり／なし」だけ。値は出さない
• 接続文字列、.env の中身、判断：避ける、ログでの扱い方：接続先の種類だけ（例: 「db=primary」）
• リクエスト・レスポンス本文の全体、判断：避ける、ログでの扱い方：必要なキー名と型だけ出す
• ユーザーが入力した自由記述、判断：条件付き、ログでの扱い方：長さと有無のみ。出すなら改行を除去して長さを制限する

最後の行は、ログ偽装への備えでもあります。OWASP は、構造化形式（JSON など）を使い、ログに含める入力値をサニタイズして、改行文字などによるログ偽装を防ぐよう勧めています。構造化形式でも入力値の扱いを確認し、長さを制限するなど安全に記録するのが要点です。

置き場所の決め方：手掛かりは「境目」に置く

ログは多いほどよいわけではありません。不具合の調査では、次の境目に絞ると手掛かりになりやすくなります。

1. 入口と出口：関数やAPIの開始と終了。件数や成否だけを出します。
2. 分岐点：if や switch で、どちらに進んだか。
3. 外部とのやり取り：DB、ファイル、外部API を呼ぶ前後。結果の種類と所要時間を出します。
4. 例外を捕まえた場所：エラーの種類と、どの処理中だったか。
5. 値が変わる場所：変換や計算の前後。値そのものでなく、型・長さ・範囲内かの判定を出します。

出力先も決めておきます。Node.js の公式ドキュメントでは、グローバルの console は process.stdout と process.stderr に出力し、log・info は stdout、warn・error は stderr を使うと説明されています。ブラウザのコンソールは MDN にあるとおり、ログの種類ごとに表示を分け、フィルタできます。実際の保存先や閲覧範囲は実行環境によって異なります。ブラウザのコンソールは利用者側でも開けるため、秘密に近い値は出さないでください。

AIに渡す依頼文テンプレート

次の文面を、【】 を埋めて使ってください。実際に実行して確かめた例ではなく、依頼の型として用意したものです。

次のコードの不具合を調べるため、原因調査用のログを追加してください。
修正はせず、ログの追加だけにしてください。

【症状】例: 注文確定ボタンを押すと、たまに合計金額が0円になる
【再現条件】例: クーポン適用後に数量を変更したとき
【言語・実行環境】例: Node.js、ローカル開発のみ
【対象のコード】（ここに関数単位で貼る。秘密情報はダミーに置き換える）

条件:
- ログは JSON 1行で、キーは event, step, result, elapsedMs の形にする
- 出してよいのは、処理名、件数、分岐の結果、エラーの種類、経過時間
- 次は絶対に出力しない: パスワード、トークン、APIキー、Cookie、
  メールアドレス、氏名、住所、電話番号、接続文字列、リクエスト本文の全体
- 値が必要な場合は、値そのものではなく「有無」「型」「長さ」にする
- ユーザー入力は長さを制限し、改行などをサニタイズしてから構造化ログのフィールドに入れる
- ログの追加箇所ごとに、「なぜここに置くか」を1行で書く
- 通常動作を変えない（戻り値、例外、処理順は変更しない）
- 調査後に消しやすいよう、ログ呼び出しに目印のコメント DEBUG-TEMP を付ける

最後に、追加したログの一覧と、出力されうる項目を表にしてください。

貼り付けるコードにも注意が必要です。本番のキー、実在の顧客データ、.env の中身は貼らず、user@example.com や API_KEY_DUMMY のような説明用データに置き換えます。AIサービスの「学習に使わない」設定と、貼った情報が外部に出ないことは別の話です。設定の有無にかかわらず、貼る内容を絞るのが基本です。

返ってきた差分を人が確認する手順

AIの答えは、次の順で確認します。

1. 差分だけを見る：git diff で、作業ツリーとステージング領域の差分を確認し、ログ以外の変更が混ざっていないかを見ます。条件式や戻り値が変わっていたら差し戻します。Git の使い方は git-scm.com のドキュメントで確認できます。
2. 出力項目を1行ずつ読む：表の「避ける」に当たる変数が、オブジェクトごと渡されていないかを見ます。console.log(user) のようにオブジェクト全体を渡すと、中の項目が意図せず出ます。
3. エラー出力を疑う：error.message や例外オブジェクトに、入力値や接続先が含まれる場合があります。種類と所要時間だけにするか、確認してから出します。
4. ダミーデータで動かす：ダミーのメールアドレスと「SECRET_DUMMY」という文字列を入力し、出力に出ていないかを検索します。出ていれば、そのログは危険です。
5. 調査後に消す：DEBUG-TEMP で検索して削除するか、残すならログレベルを分けて、本番では出ない設定にします。コミット前に差分を再確認してください。

説明用の例として、頼んだ後に期待する出力は次のような形です（想定する形であり、実行結果ではありません）。

{"event":"checkout","step":"coupon_applied","result":"true","itemCount":3,"elapsedMs":12}
{"event":"checkout","step":"total_calculated","result":"zero","itemCount":3,"elapsedMs":15}

この2行から、クーポン適用後に合計が0になる、と絞り込めます。金額の中身やユーザー情報を出さなくても、「どの手順で結果が変わったか」は分かります。

追加の依頼で足す・減らす

1回目のログで絞り込めなかった場合は、範囲を狭めて再依頼します。「total_calculated の直前の計算だけ、入力の型と範囲内かの判定を出してください。値そのものは出さないでください」のように、場所と出力の種類を指定します。逆に、ログが多すぎて読めないときは、「入口と出口以外のログを削って」と頼みます。

どうしても値が必要な場合は、AIには出させず、人が手元のデバッガで一時的に確認する方法もあります。本番のログに値を残さずに済みます。

最後に、依頼文の「出さないもの」の一覧は、プロジェクトごとに育ててください。自分のサービスで実際に扱う項目名（customerPhone、authHeader など）を書き足すと、AIが見逃しにくくなります。