この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。NISTのログ管理資料を参照し、実データを使わずにマスキングと共有判断を確認できる形に整理しています。NISTではSP 800-92 Rev.1がDraftとして進行中であるため、本記事では実装の細部をNISTだけに依存せず、最小化・確認・共有範囲の考え方を中心に扱います。検証ステータス：📘 NIST公開資料確認済み・実運用ログ未使用
ログにはtokenだけでなく、メールアドレス、内部host名、query string、利用者ID、ファイルパスなど、単体では無害でも組み合わせると機微情報になる値が混ざります。AIやベンダーへ渡す前は、「秘密らしい文字列を消す」だけでなく、調査に必要な情報だけ残すという考え方が重要です。
今回の成功条件
ダミーログを変換し、秘密情報らしい値を伏せつつ、障害調査に必要なstatus=500などは残せれば成功です。
まず試す
printf '%s\n' 'user=demo@example.com token=dummy-secret status=500' | sed -E 's/token=[^ ]+/token=****/g; s/[[:alnum:]._%+-]+@[[:alnum:].-]+/****@****/g'
ここを見る
期待結果:
user=****@**** token=**** status=500
見るポイントは、何を消したかだけではありません。
tokenは消えたかメールアドレスは消えたか
status=500は残ったか元ログそのものは変更していないか
調査に不要な機微情報を消し、必要な事実を残すのが目的です。
1か所変えてみる
ip=192.0.2.10を追加してください。
printf '%s\n' 'user=demo@example.com token=dummy-secret ip=192.0.2.10 status=500' | sed -E 's/token=[^ ]+/token=****/g; s/[[:alnum:]._%+-]+@[[:alnum:].-]+/****@****/g'
IPアドレスはそのまま残ります。ここで「正規表現が足りない」とすぐ結論付けるのではなく、その共有先・調査目的でIPを残す必要があるかを判断します。
たとえばネットワーク障害の調査ならIPが重要な場合があります。一方、一般的な操作説明のためにAIへログを渡すだけなら不要かもしれません。
なぜ自動マスクだけで終わらないのか
マスキングは「文字列置換」ですが、情報漏えいの判断は文脈依存です。
たとえば次の値は、環境によって機微度が変わります。
| 値 | 残す意味 | リスク例 |
|---|---|---|
| HTTP status | 障害原因の切り分け | 比較的低い |
| 時刻 | 発生順序の確認 | 行動履歴と結び付く場合あり |
| host名 | 対象サーバー識別 | 内部構成の露出 |
| user ID | 特定利用者の再現 | 個人識別につながる |
| query string | API条件の確認 | tokenや検索語を含む可能性 |
| IP address | NW調査 | 利用場所・端末識別につながる場合あり |
つまり、正規表現を増やせば安全になるとは限りません。
自動変換 → 目視確認 → 共有目的に合わせた削減の3段階にすると、判断しやすくなります。
graph LR A[元ログ] --> B[コピー] B --> C[自動マスク] C --> D[人が再確認] D --> E[必要部分だけ共有]
失敗例をあえて作る
自由記述に秘密が入る例を追加します。
message="login failed with token dummy-secret"
先ほどのtoken=...用正規表現では消えません。
ここが大事です。「tokenという項目名を消した」ことと「秘密情報を全部消した」ことは別です。
URL、JSON、自由記述、stack trace、ファイルパスなど、ログ形式が変わればマスク条件も変わります。
事務職・業務でどこに使えるか
1. ベンダー問い合わせ前のログ整理
システム障害でログを送る場合、いきなり全文を添付するのではなく、
発生時刻
エラーコード
対象処理名
前後数行
だけを切り出し、利用者名・メール・token・内部URLなどを確認してから送る、という手順にできます。
2. AIへエラー内容を相談するとき
「このエラーの意味を教えて」とAIへ貼る前に、実データをダミーへ置換します。
たとえば、
user=USER_A host=HOST_A file=FILE_A.csv
のように、意味は残すが実値は消すと、AI側も文脈を読みやすくなります。
3. 手順書・ナレッジ化
実際の障害ログをそのまま社内Wikiへ載せず、再現用のダミーログへ置き換えておくと、後から別の担当者も安全に学習できます。
4. Excelで確認する場合
事務担当なら、ログをExcelへ貼り付けて、メールアドレスやtoken=の有無をフィルター・検索で二次確認する方法もあります。自動マスクだけに依存せず、共有前チェックリストとして使う発想です。
仕事で使うなら
元ログは変更せずコピーに対して処理し、共有前に対象範囲・保存先・保持期間を確認します。認証情報が実際に漏れた疑いがあれば、マスクだけで済ませず失効・rotationを検討します。
実務では次の順にすると扱いやすくなります。
元ログを保存する
必要範囲だけコピーする
自動マスクする
人が再確認する
調査に不要な行・列をさらに削る
共有先と保存場所を確認する
共有後、不要な一時ファイルを削除する
NIST Log Management project: https://csrc.nist.gov/projects/log-management
NIST SP 800-92: https://csrc.nist.gov/pubs/sp/800/92/final
