宝探しをやめて、追跡を始める——データを見ずにデータを守る「code-first DSPM」

退会したユーザーのデータ、本当に消えていますか

アカウント削除のリクエストが来た。ユーザーテーブルから該当行を消した。処理は正常終了。

しかし、そのユーザーのメールアドレスは、サポートチケットの本文に残っている。分析基盤のイベントログにも残っている。エラー発生時のスタックトレースと一緒に、監視ツールにも送られている。

「機微データがどこにあるのか、把握できていない」——この問題を扱う分野が DSPM(Data Security Posture Management)です。機微データがどこに保存され、それが何のデータで、暗号化されているか、アクセス権が広すぎないか。データの所在とリスクを可視化するカテゴリで、ここ数年で急速に製品が増えました。

Aikido も 2026 年にこの領域に参入しました。ただし、既存の DSPM 製品とは根本的に違うやり方で、です。この記事では、その違いと——あえて——見つけられないものまで含めて解説します。

従来型 DSPM は「宝探し」

従来型の DSPM 製品(Cyera、Sentra、Orca など。Wiz のデータセキュリティ機能も同じ系統です)のやり方は、こうです。

本番のデータベースやストレージに接続する。中身をスキャンする。「16桁の数字だからクレジットカード番号らしい」「@ が入っているからメールアドレスらしい」と、データの見た目からそれが何かを推測する。

倉庫を全部開けて、中の荷物をひとつずつ確かめる。宝探しです。デプロイ済みの環境を直接見るので、そこに実在するデータを確実に棚卸しできる——これが強みです。

ただし、代償が2つあります。

第一に、ベンダーに本番データの読み取り権限を渡すことになります。機微データを守るためのツールに、まず機微データそのものを見せる。この構図に抵抗を感じる組織は、日本では特に少なくないはずです。

第二に、見た目からの推測は外れます。16桁の数字がすべてカード番号とは限らない。推測が外れた分だけ、誤検知として積み上がります。

Aikido のやり方は「追跡」——伝票を読む宅配便

Aikido の DSPM は、データそのものを一切見ません。読むのは、コードだけではありません。データベーススキーマ、ORM モデル、OpenAPI などの API 定義、Terraform や Kubernetes マニフェストといった Infrastructure as Code まで、アプリケーションを記述するファイル群すべてが解析対象です。この記事では、以下まとめて「コード」と呼びます。

考えてみれば、コードには最初から書いてあるのです。データベースのスキーマや ORM モデルは「何をどこに保存するか」を記述しています。カラム名が ssn なら、中身を開けなくても、そこに社会保障番号が入っていることは分かる。ストレージへの書き込み処理、API 定義、インフラ設定は「そのデータがどこへ運ばれるか」を記述しています。

荷物を開けずに、伝票と配送ルートで管理する。宅配便が毎日やっていることです。

この方式だと、データの「最終的な置き場所」だけでなく、アプリケーションに入った瞬間から出ていくまでの経路全体を追えます。フォームから入った氏名が、DB に保存され、エラーログに混入し、分析ツールへ送信され、LLM のプロンプトに埋め込まれる——その一本の線が見えるのです。

ここが両者の一番の違いです。従来型 DSPM は「データがある場所」を見つける。code-first DSPM は「データがどう流れたか」を追跡する。

比較を整理するとこうなります。

具体的に何が見つかるのか

Aikido が公開している検出カテゴリは、どれも現場で心当たりのあるものばかりです。

• ログへの個人情報混入 —— エラーハンドラ経由で Datadog や Sentry に流れる個人データ
• API が返しすぎているフィールド —— どのフロントエンドも使っていないのに、公開エンドポイントが date_of_birth を返している
• 第三者へのデータ送信の一覧 —— 分析ツール、CRM、決済、メール配信。どの外部ベンダーに何を渡しているかのリスト
• AI へのデータ送信 —— マスキングされないまま LLM プロバイダーに送られる顧客データ、ベクタ DB への格納、プロンプトログへの記録
• 暗号化の欠如 —— 平文保存、弱いハッシュ
• 本番データのテスト環境コピー —— マスクせずにステージングへ複製する CI ジョブ
• 削除処理の漏れ —— 冒頭の例。ユーザー行は消えるが、チケットや分析イベントは残る
• シークレットの露出 —— フロントエンドのバンドルやテストフィクスチャに混入した API キー

製品ページの説明では、いずれも「該当するファイルと行」まで特定され、修正はプルリクエストとして提案されるとされています。Aikido にはプラットフォーム全体に AutoFix(修正 PR の自動作成)の仕組みがあり、DSPM の検出結果もその流れに乗る設計です。レポートを読んでチケットを起票する仕事が、PR をレビューしてマージする仕事に変わる。ここが従来型との実務上の一番の違いです。

正直に書く: 見つけられないものが2つある

ここからは、製品ページの FAQ にも書かれている限界と、書かれていない限界の話です。

1つ目: コードが触れないデータは見えない。

誰も参照しなくなった古い S3 バケット。数年前に誰かが手動で出力した CSV。担当者の PC からアップロードされたバックアップ。コードを読む方式は「アプリケーションがデータをどう扱うか」の地図なので、現在のコードに登場しないデータは、その地図に載りません。

クラウド側のリスク——使われていないストレージの存在、公開設定、暗号化の欠如、過剰なアクセス権——は CSPM の領分で、Aikido では同じプラットフォーム内の別機能として確認できます。ただし、CSPM がバケットの存在や設定を見つけても、その中に何のデータが残っているかまで必ず分かるわけではありません。コードから外れた「野良データ」の中身の棚卸しは、実データをスキャンする従来型 DSPM の方が得意です。

2つ目: 名前のないデータは追跡できない。

others。備考。remarks。——こういう名前のカラムに個人情報が入っていたら、コードを読む方式では、それが宝だと分かりません。伝票に「雑貨」と書かれた箱の中身は、伝票からは分からない。中身をスキャンする従来型なら、ここで見つけられる可能性があります。宝探しの唯一にして明確な優位点です。

ただし、ここで立ち止まって考えたいのです。

others に個人情報を入れるという設計は、ツール以前に、組織自身がそのデータを追跡できていないことを意味します。名前の付いていないデータは、アクセス制御の対象になりません。暗号化ポリシーの対象にもなりません。退会時の削除処理からも漏れます。監査で「個人情報の保管場所一覧」を求められたとき、誰もそのカラムを挙げられません。GDPR や個人情報保護法の実務では、「どこに個人情報があるかを説明できること」自体が求められます。名前のないカラムの中の個人情報は、その説明責任の外に置かれたデータです。

ツールが見つけられないのではなく、誰も見つけられない状態が、設計の時点ですでに始まっている。code-first DSPM が others を検出できないのは弱点ですが、同時に、この方式の検出結果は「データにきちんと名前が付いているか」という組織の規律をそのまま映す鏡でもあります。

まとめ: 対立ではなく、層の違い

DSPM 製品の比較は「どちらが多く見つけるか」の話になりがちです。しかし整理すべきは層の違いです。

従来型は、本番に置かれた後のデータを見張る。code-first は、本番に置かれる前の経路で止める。前者は実在の棚卸しに強く、後者は原因と修正に強い。両方を備えるのが理想ですが、どちらか一方から始めるなら、判断基準は明確です——守るために、本番データを誰かに見せる必要があるかどうか。

code-first DSPM の答えは「見せる必要はない」です。スキーマと伝票を読めば、荷物の中身は分かるのだから。

見方を変えれば、「実データを見ない」という制約は、権限最小化(Principle of Least Privilege)というセキュリティ設計の原則を、ツール自身に適用した形でもあります。データを守る道具が、データへの特権アクセスを要求しない。この一貫性は、方式の限界と並べて、方式の思想として評価されてよい点です。

そして others カラムの教訓がもうひとつ。データ保護は、ツールを入れる前の「データに名前を付ける」という地味な規律から始まります。どんな DSPM を選んでも、名前のないデータは守れません。

---

参考:

• Aikido DSPM — コード・API 定義・インフラ設定から機微データの流れを追跡する機能

関連記事: 「データを守る」のが DSPM なら、「コードを直す」のが Aikido Libraries です。同時期に公開されたこの別機能(使用中のライブラリに CVE 修正をバックポートする機能)については、別記事で解説しています。