入力前に除外する情報
- APIキー、アクセストークン、秘密鍵、パスワード
- 顧客名、担当者名、メールアドレス、電話番号、住所
- 社内ドメイン、IPアドレス、ホスト名、ファイルパス
- 本番DBの接続先、スキーマ名、テーブル名、実データ
- コメントや例外メッセージに含まれる案件名・組織名
認証情報はマスキングツールへ入力する前に削除するのが安全です。置換結果へ残っていないかを確認するだけでなく、漏えい時には該当する認証情報を失効・再発行してください。
マスキング・匿名化の手順
- 共有に必要な最小範囲だけを切り出します。
- 対象形式に合ったマスキングツールを選びます。
- マスキング対象の種類とコメント・値の扱いを設定します。
- 結果側で置換を解除した箇所を含め、全文を検索します。
- 括弧、引用符、JSON構文などが壊れていないか確認します。
共有直前の最終確認
- 元データ固有の単語を複数選び、結果内検索で0件になることを確認する
- スクリーンショット、ファイル名、貼り付け先のタイトルも確認する
- マスキング後のコードを可能であれば構文チェックする
- 共有相手と公開範囲を再確認する
具体例：障害調査用のコードとログを共有する
JavaやPythonのソースコードとエラーログを一緒に共有する場合、コードだけをマスキングしても、ログのスタックトレース、URL、SQL、ファイルパスから元のクラス名や環境名が分かることがあります。
- 再現に必要なコードとエラー発生前後のログだけを切り出します。
- コード用とLog用のマスキングツールで、それぞれの構造に合わせて処理します。
- 同じ顧客IDやセッションIDが同じダミー値になっているか確認します。
- 元の社名、案件名、ドメイン、IP、メールアドレスを結果全体から再検索します。
「伏せ字があるから安全」と判断せず、第三者が残った情報を組み合わせて組織・顧客・環境を推測できないか確認してください。
よくある質問
- APIキーを一部だけ伏せてもよいですか？
- 識別や悪用につながる可能性があるため、原則として全体を削除・置換します。漏えいした可能性がある場合はキーを失効して再発行してください。
- マスキング結果をそのままAIや公開Issueへ投稿できますか？
- 自動検出には限界があります。元データ固有語での検索、構文確認、共有範囲の確認を人の目で行ってから投稿してください。