データ分類とは何か、DLP・AI利用・SaaS外部共有で迷わない分類軸、確認手順、初動対応、判断基準を情シス・開発者・SaaS管理者向けに整理します。
冒頭要約：データ分類はDLP導入前の「判断基準」を作る作業
データ分類とは、組織の情報を「公開してよい」「社内限定」「機密」「特に制限が必要」のように分け、誰が、どこで、どの条件なら扱えるかを決める作業です。
DLP、CASB、SaaS外部共有の棚卸し、AIエージェント利用ルールは、分類基準がないと「何を止めるべきか」「何を例外として認めるか」を判断できません。
最初から全ファイルを完璧に分類しようとすると止まりやすいため、顧客情報、個人情報、契約、財務、人事、ソースコード、認証情報のような高リスクデータから始めるのが現実的です。
この記事では、2026年7月1日時点で確認できるNIST、Microsoft、Google Cloudの公式情報をもとに、情シス、開発者、SaaS管理者、CSIRTが実務で使えるデータ分類の始め方を整理します。
この記事は、防御・確認・初動対応を目的にした実務ガイドです。DLP製品の比較や特定サービスの詳細設定ではなく、データ分類をどう設計し、SaaS共有、AI利用、漏えい疑い、ログ確認へつなげるかに焦点を置きます。
読者別の影響：誰が何を決めるべきか
データ分類は、セキュリティ担当だけの作業ではありません。分類を決める人、ラベルを付ける人、例外を承認する人、インシデント時に説明する人が分かれるため、役割ごとに確認観点を置く必要があります。
| 読者 | まず知りたいこと | 主な確認対象 |
|---|---|---|
| 個人・一般利用者 | AIやSaaSへ入力してよい情報か | メール、ファイル、チャット、顧客情報、個人情報 |
| 情シス担当者 | DLPや外部共有制御の基準を作れるか | Microsoft 365、Google Workspace、Slack、Box、IdP、端末 |
| 開発者 | ソースコード、ログ、APIキー、設計書をどう扱うか | GitHub、CI/CD、チケット、監視ログ、クラウドストレージ |
| SaaS管理者 | 外部共有やゲスト権限を分類に応じて判断できるか | Drive、SharePoint、Slack Connect、Notion、CRM、SFA |
| CSIRT / SOC | 漏えい疑い時に影響範囲を切り分けられるか | 監査ログ、DLPアラート、アクセスログ、データ所有者 |
| 法務・管理部門 | 契約、規程、個人情報保護、通知判断と矛盾しないか | 情報管理規程、委託契約、保持期限、削除要件 |
分類は「ラベル名を決める」だけでは終わりません。どのデータを、誰が、どのSaaSで、どこまで共有してよいかまで決めて初めて、DLP や CASB のポリシーに落とし込めます。
データ分類とは：情報の重要度を現場が判断できる形にすること
NIST SP 800-60は、情報タイプと情報システムをセキュリティカテゴリへマッピングする考え方を示しています。実務では、この考え方をそのまま複雑に導入するより、機密性、完全性、可用性の影響を見ながら、自社の業務で判断できる分類へ落とし込むことが重要です。
小さく始めるなら、次の4段階で十分です。
| 分類 | 例 | 基本ルール |
|---|---|---|
| 公開可 | 公開済みブログ、採用ページ、公開プレス資料 | 社外共有可。ただし公開前レビューと改ざん防止は必要 |
| 社内限定 | 社内手順、議事録、一般的な社内資料 | 社外共有不可。AI入力やSaaS共有は社内承認済み環境に限定 |
| 機密 | 顧客情報、契約、財務、人事、未公開計画、設計書 | 外部共有は承認制。DLP、監査ログ、期限付き例外を必須にする |
| 要制限 | 認証情報、秘密鍵、個人情報の大量データ、未公表インシデント情報 | 原則入力・共有禁止。必要な場合は専用保管庫、暗号化、限定アクセスを使う |
Microsoft Purviewの公式ドキュメントでは、分類は手動、パターン照合、Trainable classifiersなど複数の方法で実施でき、分類結果を感度ラベルや保持ポリシーなどに使う考え方が説明されています。Google Cloud Sensitive Data Protectionでも、機密データの検出、分類、匿名化、検査がデータ保護の構成要素として整理されています。
最初から10段階以上の分類を作ると、現場が判断できず、ラベル付けが形だけになります。まずは「社外へ出してよいか」「承認が必要か」「AIや外部SaaSへ入力してよいか」を判断できる粒度にします。
まず確認すること：データ分類の10項目チェックリスト
データ分類を始めるときは、分類名より先に、データの所在、所有者、共有範囲、利用場面を確認します。ここを飛ばしてDLPルールだけ作ると、誤検知、業務停止、例外申請の乱発につながります。
| 確認項目 | 見る内容 | 実務上の判断 |
|---|---|---|
| 1. データ種別 | 顧客、個人、契約、財務、人事、ソースコード、ログ、認証情報 | 先に保護すべきデータを決める |
| 2. 保存場所 | SaaS、共有ドライブ、GitHub、クラウドストレージ、端末、チケット | Data Discovery の対象を決める |
| 3. 所有者 | 部門、データオーナー、システムオーナー | 分類変更と例外承認の責任者を置く |
| 4. 共有範囲 | 社内、外部ゲスト、リンク共有、委託先、AIツール | SaaS外部共有リンクの棚卸し へつなげる |
| 5. 利用目的 | 営業、開発、サポート、監査、分析、AI学習・要約 | 目的外利用や過剰コピーを見つける |
| 6. AI入力可否 | 生成AI、AIエージェント、社内RAG、外部API | AIエージェント利用ルール とそろえる |
| 7. DLP対象 | メール、SaaS、端末、クラウド、ブラウザ、API | 検知、警告、ブロック、承認の動作を分ける |
| 8. 保持期限 | 保管期間、削除日、契約終了日、法令・規程 | 不要データを減らし、漏えい時の影響を抑える |
| 9. 監査ログ | 閲覧、ダウンロード、共有、削除、ラベル変更、DLP検知 | ログ保管 と調査導線を確認する |
| 10. 例外 | 期限、承認者、代替策、再レビュー日 | 無期限例外を作らず、例外申請テンプレート へ残す |
このチェックリストで重要なのは、分類をデータ単体で見ないことです。同じ「顧客情報」でも、公開事例ページ、営業中の見積、問い合わせログ、障害対応ログでは、共有可否と保持期限が変わります。
初動対応：分類ルールがないまま高リスクデータを見つけた場合
分類運用の開始前に、外部共有やAI入力、DLPアラート、監査ログで高リスクデータが見つかることがあります。この場合は、分類プロジェクトとして後回しにせず、初動対応として扱います。
やること
- 対象データの保存場所、所有者、共有先、最終アクセス、外部送信先を記録する。
- 顧客情報、個人情報、認証情報、契約、財務、人事、ソースコードのいずれを含むか確認する。
- 外部共有やAI入力がある場合は、業務目的、承認者、期限、代替手段を確認する。
- 監査ログ、DLPアラート、SaaS共有ログ、IdPログを保全する。
- 影響が大きい場合は、漏えい疑い初動テンプレート へ移し、時刻、判断者、対象データ、初動措置を分けて記録する。
- GitHubやCI/CDに秘密情報が含まれる場合は、GitHub secret leak対応チェックリスト を使い、削除より先に失効と影響確認を行う。
やらないこと
- 所有者確認やログ保存をせずに、対象ファイルや共有リンクを一括削除しない。
- 「DLPで検知した」だけで漏えいと断定しない。
- 例外理由を残さずにDLPルールを無効化しない。
- 機密データのサンプルをチャット、チケット、AIツールへ貼り付けて二次拡散させない。
- 分類名だけを付けて、共有範囲や保持期限を見直さない。
記録すること
| 記録項目 | 例 |
|---|---|
| 対象 | SaaS名、ファイル名、リポジトリ、チケット、ログ種別、管理用ID |
| 分類 | 公開可、社内限定、機密、要制限、未分類 |
| 所有者 | 部門、データオーナー、技術責任者、承認者 |
| 露出経路 | 外部共有、AI入力、メール送信、端末コピー、API、GitHub、ログ |
| 時刻 | 発見、共有作成、最終アクセス、停止、承認、エスカレーション |
| 判断 | 継続、範囲縮小、停止、失効、追加調査、インシデント化 |
| 後続対応 | DLPルール、感度ラベル、SaaS権限棚卸し、教育、例外レビュー |
記録は、後から責任追及するためではなく、影響範囲と再発防止を説明するために残します。特に個人情報や認証情報が関係する場合は、時系列と判断根拠を分けて残すことが重要です。
判断基準：どこから始め、どこでエスカレーションするか
データ分類は、全社で一斉に完了させるものではありません。最初に扱うべき領域を優先度で分けます。
| 優先度 | 条件 | 対応 |
|---|---|---|
| 高 | 認証情報、秘密鍵、個人情報の大量データ、顧客情報、契約、未公表インシデント情報を含む。外部共有、AI入力、公開リポジトリ、委託先共有がある | 共有や入力を一時停止し、所有者、ログ、アクセス範囲を確認。CSIRT、法務、管理者へエスカレーションする |
| 中 | 社内限定や機密の可能性があるが、共有先と所有者は説明できる。期限やラベルが未整備 | 分類ラベル、期限、例外申請、DLP監査モードを設定し、次回レビュー日を置く |
| 低 | 公開済み情報、社内一般情報で、所有者、共有範囲、保持期限が明確 | 台帳に記録し、定期レビューへ回す |
エスカレーションの目安は、「分類が分からないこと」ではなく、「重要データが広く共有され、誰も説明できないこと」です。たとえば、個人情報を含むファイルが外部リンクで共有され、所有者が退職済みで、最終アクセスが直近なら、分類整理ではなく初動対応として扱います。
最初の30日は、顧客情報、個人情報、契約、認証情報、ソースコード、障害ログの6種類だけでも十分です。分類名を増やすより、保存場所、所有者、外部共有、AI入力可否、ログ確認をそろえることを優先します。
DLP・AI利用・SaaS共有へ落とし込む方法
分類ルールは、ドキュメントとして置くだけでは効果が出ません。DLP、AI利用、SaaS共有、開発者ワークフローに反映して初めて、日々の判断基準になります。
| 領域 | 分類をどう使うか | 関連ページ |
|---|---|---|
| DLP | 機密・要制限データの検知条件、警告文、ブロック条件、例外承認を分ける | DLPとは、DLPとCASBの違い |
| CASB / SSPM | SaaS上の外部共有、未承認アプリ、ゲスト権限を分類に応じて確認する | CASBとは、SSPMとは |
| AI利用 | 入力禁止データ、要匿名化データ、社内限定AIでのみ扱うデータを決める | AIエージェント利用ルール |
| SaaS外部共有 | 共有先、期限、所有者、データ分類をセットでレビューする | SaaS外部共有リンクの棚卸し |
| 開発者ワークフロー | ログ、シークレット、設計書、リポジトリ添付の扱いを分ける | GitHub secret leak対応チェックリスト |
| インシデント対応 | 漏えい疑い時に、対象データと通知・報告の判断材料を早く集める | 漏えい疑い初動テンプレート |
Microsoft Purviewの感度ラベルでは、ラベルの優先順位や公開ポリシーが重要になります。最も制限が強いラベルをどう扱うか、ユーザーが低い分類へ変更するときに理由を求めるか、CopilotやAIアプリがラベルの利用権限をどう扱うかまで確認しておくと、AI利用ルールと矛盾しにくくなります。
Google CloudのSensitive Data Protectionでは、データ検出、検査、匿名化、DLP APIが整理されています。クラウドやAIワークロードで機密データを扱う場合は、保存済みデータだけでなく、プロンプト、レスポンス、ログ、分析用データセットにも分類の考え方を適用します。
よくある誤解
「DLPを入れればデータ分類は不要」
DLPは検知やブロックの仕組みであり、何を機密とみなすかは別に決める必要があります。分類基準がないと、誤検知を止めるためにルールを緩めすぎたり、業務に必要な共有まで止めたりします。
「分類ラベルを付ければ安全」
ラベルは判断の入口です。アクセス制御、外部共有、DLP、保持期限、監査ログ、例外承認とつながっていなければ、見た目だけの分類になります。
「全ファイルを分類してから運用を始める」
完璧な分類を待つと、DLPもAI利用ルールも進みません。高リスクデータから始め、未分類データを「低リスク」と扱わないルールを置くほうが現実的です。
「AIに入れたらすぐ漏えい」
AI入力のリスクは、利用するサービス、契約、保存設定、権限、入力データの分類で変わります。重要なのは、入力してよい分類、匿名化が必要な分類、入力禁止の分類を明確にすることです。
「個人情報だけ見ればよい」
個人情報は重要ですが、認証情報、秘密鍵、ソースコード、契約、未公開インシデント情報、障害ログも高リスクです。漏えい時の影響は、法令だけでなく、事業継続、顧客信頼、攻撃面の拡大でも判断します。
関連用語・関連ページ
データ分類は、SaaS管理、AI利用、DLP、漏えい初動、開発者セキュリティをつなぐ基準です。次のページを合わせて読むと、実務に落とし込みやすくなります。
| 目的 | 内部リンク |
|---|---|
| 用語を確認する | Data Classification、DLP、Data Discovery、Data Loss Event |
| 違いを理解する | DLPとCASBの違い、認証と認可の違い |
| SaaS共有へ適用する | SaaS外部共有リンクの棚卸し、SaaS権限棚卸しチェックリスト |
| AI利用へ適用する | AIエージェント利用ルール、MCPサーバー権限・トークン確認 |
| 漏えい疑いに備える | 漏えい疑い初動テンプレート、ログを読む初心者向けの基本 |
| 開発者向けに確認する | GitHub secret leak対応チェックリスト、SBOMとOSVで学ぶ依存関係確認 |
| 知識を定着させる | セキュリティ用語クイズ |
まとめ：分類は「止めるため」ではなく「迷わず扱うため」に作る
データ分類の目的は、現場の利用を止めることではありません。どの情報なら社外共有できるのか、どの情報は承認が必要なのか、どの情報はAIや外部SaaSへ入力してはいけないのかを、迷わず判断できる状態にすることです。
最初に作る分類は、公開可、社内限定、機密、要制限の4段階で十分です。顧客情報、個人情報、契約、財務、人事、ソースコード、認証情報から始め、所有者、保存場所、共有範囲、保持期限、監査ログ、例外期限をセットで記録します。
DLPやCASB、SSPM、AI利用ルールは、データ分類の上に乗る運用です。ツールを先に入れるのではなく、何を守り、どこで警告し、どこから止め、誰が例外を承認するかを先に決めると、現場で使える情報保護に近づきます。
公式情報・参考情報
- NIST SP 800-60 Vol. 1 Rev. 1: Guide for Mapping Types of Information and Information Systems to Security Categories — 情報タイプと情報システムをセキュリティカテゴリへマッピングする考え方を確認できる。
- Microsoft Learn: Classifiers overview — Microsoft Purviewでの手動分類、自動パターン照合、Trainable classifiers、分類結果の活用を確認できる。
- Microsoft Learn: Learn about sensitivity labels — 感度ラベルの優先順位、公開ポリシー、Microsoft 365やCopilot/AIアプリでの保護観点を確認できる。
- Google Cloud Documentation: Sensitive Data Protection overview — データ検出、分類、匿名化、検査、DLP APIの構成要素を確認できる。
- Google Cloud: Cloud Data Loss Prevention is now part of Sensitive Data Protection — Cloud DLPがSensitive Data Protectionに統合され、検出・分類・保護に使われることを確認できる。
