こんにちは！開発現場の裏側で、ログやトレースの海に溺れかけているエンジニアの皆さん。
アプリケーションのパフォーマンス監視やエラー追跡のために、Datadogは本当に強力な相棒ですよね。「何かおかしい」と思った瞬間に原因へたどり着けるあの爽快感は、一度知ると手放せなくなります。
でも、ふとこんな恐怖を感じたことはありませんか？
「おい、今のログのペイロード……ユーザーのクレジットカード番号が入ってなかったか……？」
「あ、AWSの秘密鍵（Secret Access Key）がAPMのトレースデータに丸見えだ……」
……冷や汗が背中を伝いますよね。
ログやトレースにうっかり機密情報（PIIやシークレット）が混入してしまう事故は、どんなに優秀なチームでもヒューマンエラーとして起こり得ます。そしてそれが原因で、GDPRやPCI DSSといった厳格なコンプライアンス違反を叩き出そうものなら、会社全体の信頼が吹っ飛びます。
「じゃあ、アプリケーション側の全コードを書き直して、ログ出力の直前でマスク処理を入れるのか？」
――いやいや、そんな不毛な作業で貴重な開発時間を溶かすのはもう止めましょう。
今回は、Datadogの秘技「Sensitive Data Scanner (SDS)」を使って、アプリケーションに手を入れず、Datadog側で機密情報を自動的に検知・マスクする神アプローチを解説します。これをマスターすれば、コンプライアンス監査に怯える夜とはおさらばできますよ。
—
1. Sensitive Data Scanner（SDS）とは何か？
一言で言えば、SDSは「Datadogのインジェスチョン（取り込み）パイプラインの関所」です。
データがDatadogのサーバーに届いた瞬間、ストレージに保存されるより前の段階でスキャンをかけ、クレジットカード番号やパスワード、マイナンバー、APIキーなどのパターンに合致した文字列を検知し、見事に伏字（マスク）に置き換えてくれます。
従来のやり方 vs SDS
- 昔のやり方（アプリ側でマスク）:
各マイクロサービスのログ出力ライブラリやスパンプロセッサーを改造。新しい言語やフレームワークを導入するたびにマスク処理を実装・テストし直す地獄。
- SDSのやり方（Datadog側でマスク）:
Datadog側でルールをポチポチと設定するだけ。アプリのコードは1ミリも汚さない。
圧倒的に後者がスマートですよね。
—
2. 基礎セットアップ：SDSを有効化する
それでは、実際に手を動かしていきましょう。と言っても、画面を数回クリックするだけで準備は完了します。
ステップ1：権限の確認
SDSを設定するには、Datadogの組織内で 「Strict Data Governance Admin」 または 「Admin」 権限が必要です。権限がない場合は、インフラチームのボスにお願いして権限を付与してもらいましょう。
ステップ2：スキャンの対象を決める
SDSは、以下のデータソースに対して適用できます。
- ログ (Logs)
- APM トレース (Traces)
- RUM（Real User Monitoring）のイベント
- ネットワーク・セキュリティのイベント
今回は最も事故が多い「ログ」と「APMトレース」をターゲットに設定していきましょう。
—
3. HelloWorld的な動作確認：クレジットカード番号をマスクしてみよう
百聞は一見にしかず。テスト用のクレジットカード番号がログに混入した想定で、それが綺麗にマスクされるかを検証する「HelloWorld」ならぬ「Hello Masking」をやってみましょう。
① スキャンルールの作成
1. Datadogの画面左側メニューから [Security] ＞ [Sensitive Data Scanner] に移動します。
2. [Add Rule] ボタンをクリックします。
3. ここがあらかじめ用意されているテンプレート（Out-of-the-box rules）の宝庫です。「Credit Card Number」「Email Address」「AWS Access Key ID」など、世の中の主要な機密情報はすでに網羅されています。
4. 今回は「Credit Card Number（クレジットカード番号）」を選択してみましょう。
② マスキング方式の設定
ルールを設定する際、どうやって隠すかを選べます。
- Mask（部分マスク）: 下4桁だけ残して、他を “ にする（例: `1234`）
- Full Redact（完全置換）: 全てを `[REDACTED]` に置き換える
- Hash（ハッシュ化）: 一意のハッシュ値に変換する（元の値を推測させずに集計だけしたい場合に便利）
ここでは、安全かつデバッグもしやすい 「Mask（部分マスク）」 を選択し、適用するグループ（タグやサービス）を指定して保存します。
—
4. 精度高い動作確認：意図的に「事故」を起こしてテストする
設定ができたら、本当に正しくマスクされるかテストしてみましょう。手元のローカル環境やテスト環境から、以下のようなJSONを含んだログをDatadogに飛ばしてみます。
{
“level”: “INFO”,
“message”: “User checkout completed successfully.”,
“user_id”: “usr_998127”,
“payment_info”: {
“card_holder”: “TARO DATADOG”,
“credit_card”: “4111-2222-3333-4444”,
“cvv”: “999”
}
}
(※ `4111-2222-3333-4444` は、テスト用の一般的なダミーカード番号です)
結果の確認
Datadogのログエクスプローラーを開き、先ほどのログを検索してみましょう。SDSが正常に機能していれば、ログの中身は次のように変化しているはずです！
{
“level”: “INFO”,
“message”: “User checkout completed successfully.”,
“user_id”: “usr_998127”,
“payment_info”: {
“card_holder”: “TARO DATADOG”,
“credit_card”: “4444″,
“cvv”: “999”
}
}
お見事です！ アプリケーションのコードを一切いじっていないにもかかわらず、Datadogのインジェスチョン層でクレジットカード番号が見事に `4444` へとマスクされました。
—
5. 実務で役立つプロの知見：GDPR・PCI DSS対応の勘所
基礎がわかったところで、ここからが現場で本当に役立つプロの知見です。コンプライアンス対応を本気で行うためのベストプラクティスを3つ授けます。
知見1：カスタムパターンの正規表現（Regex）を使いこなす
テンプレートにある標準ルールだけでは、日本の固有情報（例えば、マイナンバーや特定の社内固有IDなど）には対応できません。
SDSでは、独自の正規表現（Regex）を使ったカスタムルールを作成できます。
> 💡 実務でのコツ:
> 単に正規表現を書くだけでなく、「周辺のキーワード（Luhnアルゴリズムや、`apikey:` などのプレフィックス）」を条件に含めることで、誤検知（False Positive）を劇的に減らすことができます。普通の英単語を機密情報と誤認してマスクしてしまうと、デバッグの時に泣くことになりますからね。
知見2：「シフトレフト」ではなく「多層防御」の思想で捉える
「機密情報はアプリケーション側で弾くべき（シフトレフト）」という理想論は、現場のスピード感の前には崩れ去りがちです。開発者が急いでコードを書く以上、うっかりログに機密を吐き出す事故はゼロになりません。
だからこそ、「アプリ側での水際対策」×「Datadog SDSによる最終防衛ライン」という多層防御（Defense in Depth）の思想が不可欠です。SDSは、人間のうっかりミスを救う最終セーフティネットとして機能させましょう。
知見3：スキャンによるコスト・パフォーマンスの最適化
SDSは非常に強力ですが、全てのログやトレースの全フィールドに対して重い正規表現のスキャンをかけ続けると、インジェスチョンのスループットにわずかながら影響を与えます。
そのため、実務では「機密情報が含まれ得るサービスやインデックス（`env:production` かつ `service:payment-` など）」に絞ってSDSを適用するのが、コストとセキュリティのバランスを取る上で最も賢い選択です。
—
まとめ
今回は、Datadog Sensitive Data Scanner（SDS）を用いた機密情報の自動マスクとコンプライアンス対応について解説しました。
- アプリを書き換えない: Datadogのパイプラインで自動マスクするため、開発工数がゼロ。
- 確実なセーフティネット: GDPRやPCI DSSなどの厳しい監査基準もクリア可能。
- 柔軟なカスタム性: 標準テンプレートに加え、独自の正規表現ルールで自社特有の機密もガード。
これをマスターすれば、明日から「ログに何か変なものが入っていないか……」と冷や汗をかく必要はもうありません。安心・安全なオブザーバビリティ環境を手に入れて、本来のプロダクト開発に全力を注ぎましょう！
あなたの毎日の運用監視ライフが、より快適でスリリングなものになりますように。それではまた次の現場でお会いしましょう！