AIアクセスのためのデータ分類：CIO向け4階層フレームワーク

最も多いAIガバナンス上のインシデントは、AIが誤った回答を生成するハルシネーションではありません。それは、社員が顧客の個人情報（PII）、機密契約書、社内財務データを公開AIツールに貼り付けることです。データ分類ポリシーのない企業では、これが毎日起きています。

社員が不注意なわけではありません。ルールを教わっていないのです。そして既存のルール、つまりSOC 2監査から導入したデータ分類ポリシーは、AIを想定して書かれていません。

この記事では、AIに特化した4階層データ分類フレームワークを解説します。どのデータカテゴリをどのAIツール階層に使えるか、ベンダー環境へのマッピング方法、GDPR Article 22の法的な下限、そして実際に使えるかたちで運用する方法を説明します。このフレームワークは AIユーセージポリシーの構築 の実装と連携しています。

なぜ既存のデータ分類ポリシーでは不十分なのか

Key Facts: AIデータガバナンスのギャップ

• 43%の組織がAI活用における最大の障壁としてデータ品質と準備状況を挙げていますが、多くの組織のデータ分類ポリシーはAIシステム以前に作成されており、AIに固有の3つの露出経路（入力の学習利用、プロンプト保持、第三者モデルへのルーティング）に対応していません（Informatica、2025年）
• GDPR Article 22は、信用審査、採用、サービスアクセスなど個人に重大な影響を与える自動意思決定を行うAIシステムに適用され、EU全域でのGDPR違反に対する制裁は現在、大企業向けに数千万ユーロ規模に達しています（EU Data Protection Board、2025年）
• 消費者向けAIツール（無料のChatGPT、個人用Claudeアカウント）には正式なデータ処理契約がなく、そこに貼り付けられたデータは学習や保持に対する契約上の保護を受けられません。こうしたツールを業務に使っている社員のうち、この利用規約を認識していない割合は推定78%に上ります（Microsoft、2024年）

ある程度のガバナンス成熟度を持つ企業の多くは、データ分類ポリシーを持っています。SOC 2監査やISO 27001認証と合わせて導入したものです。公開、内部、機密、制限といった階層を定義し、社員はそれぞれの階層に応じた取り扱いをするよう定められています。

しかしそれらのポリシーは、別の脅威モデルを前提に設計されています。データは自社が管理するシステムに留まり、アクセス制御と暗号化で守られた状態で、組織内外の人間と共有されると想定していました。

AIシステムは、既存のポリシーが対応していない3つの点で脅威モデルを変えます。NIST SP 800-60 は情報の種類をセキュリティカテゴリにマッピングする連邦標準であり、データ分類の基盤となるフレームワークを提供していますが、現代のAIシステムを想定して作られておらず、AI固有の露出経路に対応するための拡張が必要です。

入力の学習利用。 消費者向けAIツール、そして一部のエンタープライズツールでもデフォルト設定では、入力データを使ってモデルの学習や微調整（ファインチューニング）を行う場合があります。社員が機密の戦略文書を公開ChatGPTアカウントに貼り付けると、そのコンテンツがモデルの学習データの一部になり、適切な質問をした人なら誰でも断片的にアクセスできる可能性があります。従来のデータ分類は不正アクセスからの保護を想定していましたが、AIの入力学習は別の種類の露出を生みます。データがモデル自体の一部になるのです。これが AIアウトプットのIPと著作権 が隣接するガバナンス上の課題である理由です。

プロンプトの保持と取得。 多くのAIツールは会話履歴を保持します。その一部はベンダーの品質レビューのために他のユーザーやベンダーがアクセスできる状態になることもあります。営業担当者が提案書の作成にAIツールを使って見込み客の予算情報を貼り付けた場合、その会話がベンダーのシステムに無期限に残る可能性があります。

第三者モデルへのルーティング。 多くのAI生産性ツールは独自モデルを持っていません。バックエンドでプロンプトをOpenAI、Anthropic、Googleにルーティングしています。ガバナンスの問題は、表面上使っているAIツールだけでなく、連鎖するすべてのモデルプロバイダーに及びます。

既存のデータ分類ポリシーに「機密データは保存・転送時に暗号化しなければならない」と書いてあるかもしれません。それは正しいですが不十分です。データ処理契約（DPA）の有無にかかわらず機密データを第三者モデルプロバイダーに送信してよいかどうかについては何も述べていません。AIに特化したポリシーがそのギャップを埋めます。

「既存のデータ分類ポリシーは、データが管理下のシステムに留まることを前提としています。AIはその前提を3つの点で変えます。ツールが入力を学習に使う可能性、会話履歴を保持すること、そして審査していない第三者モデルプロバイダーにプロンプトをルーティングする可能性です。『機密データは保存・転送時に暗号化』というポリシーは、この3つのリスクのいずれにも対応していません。」（Rework）

4階層AI データアクセス体系

AI ツールのアクセス判断に特化して設計された分類フレームワーク。入力の学習利用、プロンプト保持、第三者モデルへのルーティングというAI固有の露出経路に対応するため、従来のデータ分類を拡張したものです。Tier 1（公開）：すでに公開されているデータ。承認済みのあらゆるツールで使用可能。Tier 2（内部）：通常の業務データ。署名済みDPAと非学習コミットメントを持つエンタープライズAIツールで使用可能。Tier 3（機密）：顧客PII、財務データ、契約書、知的財産などを含み、プライベートクラウドまたはオンプレミスのAI展開のみ許可。Tier 4（制限）：HIPAA、GLBA、生体認証データなどを含み、明示的な法務承認と書面による契約コミットメントなしに外部AIに処理させることを禁止。この体系はデータ階層をツールカテゴリにマッピングし、社員が操作のたびにポリシー文書を参照せずに正しいAIアクセス判断を下せるようにします。

4階層AIデータ分類フレームワーク

このフレームワークは、一つの実践的な問いに答えるよう設計されています。このデータをそのAIツールに入力できるか？

Tier 1：公開

定義： すでに公開されているデータ、または公開されても事業上の影響がほとんどないデータ。

例：

• 公開しているウェブサイト、ブログ、マーケティング資料のコンテンツ
• 公開されている競合他社の情報（ウェブサイト、プレスリリース、公開ファイリングから）
• 自社固有でない一般的な業界知識
• 公開されている規制ガイダンスと基準文書
• 公開ナレッジベース、Wikipedia、公開調査資料

AIツール許可： 消費者向けツールや正式なDPAのないツールを含め、承認済みのあらゆるAIツールでTier 1データを処理できます。

監査頻度： 特定の監査は不要。Tier 1データは定義上、保護すべき機密性を持ちません。

注意： 公開であることは、タスクにとって重要度が低いことを意味しません。マーケティングチームが競合分析の入力として競合他社の公開プレスリリースを使うのはTier 1データの使用であり、ビジネス上の成果が重要であっても分類は変わりません。分類は入力データについてのものであり、作業の戦略的重要性についてではありません。

Tier 2：内部

定義： 公開ではないが、漏洩しても事業上の影響が限定的なデータ。通常の業務データ、内部プロセス文書、機密性の低い社内コミュニケーションを含みます。

例：

• 内部プロセス文書と標準業務手順書
• 通常の内部会議のメモ（戦略的・財務的内容を含まないもの）
• 機密性の低い社員間のコミュニケーション
• 財務的・戦略的内容を含まない内部プロジェクト管理データ
• 競争上機密でない詳細を含まない一般的な製品 Roadmap の説明
• 個人識別子のない集計・匿名化済み顧客データ

AIツール許可： Tier 2データは以下を持つエンタープライズAIツールで処理できます。

• 企業と署名済みのData Processing Agreement（DPA）
• エンタープライズ契約における入力の非学習コミットメント
• SOC 2 Type II認証または同等の認証

これらの基準を満たすツールには、OpenAI Enterprise、Anthropic Claude for Business、Microsoft 365 Copilot（M365コンプライアンス境界内）、Google Workspace with Gemini for Workspaceが含まれます。

消費者向けツール（ChatGPT無料版、Claude.ai個人アカウント、Google Bard個人アカウント）はTier 2データには承認されていません。

監査頻度： DPA条件が最新であることと非学習コミットメントが有効であることを確認するため、エンタープライズツール契約を四半期ごとに確認します。

Tier 3：機密

定義： 露出すると事業上、法的、または評判上の重大な損害をもたらすデータ。ほとんどの事業運営において最高レベルの保護が必要です。

例：

• 識別可能なかたちでの顧客PII（氏名、メールアドレス、電話番号、住所）
• 顧客の使用データ、取引履歴、アカウント詳細
• 署名済み契約書と法的合意書
• 財務予測、業績見通し、未公開の業績情報
• M&A関連資料（対象リスト、取引条件、デューデリジェンス）
• 機密ロジックを含む知的財産、独自アルゴリズム、ソースコード
• 社員の個人データ（HR記録、業績評価、報酬情報）
• 弁護士・依頼人特権が付与されたコミュニケーション
• 取締役会資料と取締役会レベルの戦略文書

AIツール許可： Tier 3データには以下のいずれかが必要です。

• 組織が唯一のテナントであり、データが自社環境外に出ないプライベートクラウドAI展開
• 自社インフラ上のオンプレミスAI展開
• データレジデンシーの保証、エアギャップ型モデルサービング、データが学習に使われずベンダースタッフがアクセスできないという契約上のコミットメントを持つエンタープライズAIツール

2026年時点では、OpenAI Enterprise、Anthropic Claude for Business、Microsoft Copilotを含む多くの商用エンタープライズAIツールは、デフォルト設定でTier 3データには適していません。追加費用でプライベート展開オプションを提供しているベンダーもあります。Tier 3として承認する前に、具体的なベンダー設定を確認してください。

監査頻度： Tier 3データをAIワークフローで処理した社員を毎月確認し、Tier 2承認ツールにTier 3データが入力された例外を報告します。

GDPRの注意： Tier 3の顧客PIIは、AIが個人に対して重大な意思決定を行う場合、GDPR Article 22の自動意思決定要件の対象となります。下記の法的下限セクションを参照してください。

Tier 4：制限

定義： 露出すると深刻な法的、財務的、または安全上の結果をもたらすデータ。AI利用前に明示的な法務・セキュリティレビューが必要です。

例：

• HIPAA（医療保険の相互運用性と説明責任に関する法律）が適用される医療・健康データ（患者記録、治療歴、臨床データ）
• GLBA（グラム・リーチ・ブライリー法）または銀行規制が適用される規制対象金融データ（融資判断、信用データ、規制監視下の口座レベルの金融記録）
• AIへの明示的な制限がある業界固有の規制が適用されるデータ（COPPA適用の子供のデータ、FERPA適用の一部教育記録）
• 国家機密と国家安全保障に関連するデータ（政府機関請負業者に関連）
• 訴訟ホールド中または裁判所命令の対象となっているデータ
• 生体認証識別子（指紋、顔認識データ、声紋）

AIツール許可： CISOと法務顧問による明示的な書面承認、データ取り扱いに関するベンダーとの具体的な契約上のコミットメント、代替アプローチが実行不可能な理由の文書化なしに、エンタープライズ向けツールを含む外部AIツールでTier 4データを処理することはできません。

Tier 4データの適切な答えは、ほとんどの場合、外部データ送信のないオンプレミスAIです。規制産業では、Tier 4データでのAI利用前にコンプライアンス顧問に相談してください。

監査頻度： Tier 4のAI利用はケースバイケースのレビューと文書化が必要です。定期的な監査スケジュールで運用される「通常の」Tier 4 AIワークフローは存在しません。各事例が例外扱いです。

データ階層とベンダー環境のマッピング

この表はデータ階層をツールカテゴリにマッピングしています。AIユーセージポリシーの意思決定ツリーとして使用してください。

列ヘッダーはデータ階層です。セルの値はそのツールカテゴリがそのデータ階層を処理できるかどうかを示します。「このツールカテゴリでこの階層のデータを使えるか？」という読み方をしてください。

「プライベートクラウド」設定についての注意。 複数のエンタープライズAIベンダーが、データが専用環境に留まり、モデルコールが自社のクラウドリージョンを超えず、ベンダーの運用チームがデータにアクセスできないプライベートまたは分離した展開オプションを提供しています。これらの設定はコストが高く運用も複雑ですが、Tier 3データに向けたエンタープライズ階層ツールとオンプレミス展開の橋渡しになります。ベンダーがこれを提供する場合、Tier 3として承認する前に具体的な契約上のコミットメント（データレジデンスSLA、運用アクセス不可コミットメント、監査ログアクセス）を書面で入手してください。

法的下限：GDPR Article 22とAI

EUで事業を行う、またはEUに対してサービスを提供する企業にとって、GDPR Article 22はAIベースの個人データを使った意思決定における法的最低基準を規定しています。

Article 22が述べていること。 GDPR Article 22 は、法的または同等の重大な影響を生じさせる完全自動化処理のみに基づく意思決定の対象にされない権利をデータ主体に与えています。「完全自動化」とは意味のある人間のレビューがないことを意味します。「法的または同等の重大な影響」には、信用判断、採用判断、サービスへのアクセス、その他の重大な結果が含まれます。

AIワークフローへの意味。 AIが個人に対して重大な意思決定を行い（信用スコアリング、採用推薦、顧客サービス階層の割り当て、誰に連絡するかを決めるリードスコアリング）、それが意味のある人間のレビューなしに行われる場合、EU在住のデータ主体に対してGDPR Article 22上の問題が生じます。

実務上のコンプライアンス対応。 識別可能な個人に関する重大な意思決定を行うAI PredictまたはExecuteワークフローには、以下が必要です。

1. 形式的なゴム印でなく真に意味のある人間によるレビューステップ
2. 処理に対する文書化された根拠（正当な利益または明示的な同意）
3. 個人が人間によるレビューを要求し結果に異議を唱えるためのメカニズム

これはAI固有の要件ではありません。人に関するあらゆる自動意思決定に適用されます。ただしAIは企業が行う自動意思決定の量と高度さを劇的に増加させたため、顧客または従業員データを使った大規模なAI活動を行う企業にとって、GDPR Article 22のコンプライアンスは今や積極的なガバナンス課題となっています。

CCPA（カリフォルニア州）。 カリフォルニア州消費者プライバシー法は、個人情報を用いた自動意思決定に関する消費者の権利を規定しています。CCPAが適用される企業は、カリフォルニア州の消費者を対象としたAIワークフローが2025年3月施行のCCPA規制に準拠した適切な開示とオプトアウトの仕組みを含むことを確認すべきです。

HIPAA。 保護された健康情報（PHI）を処理するAIには、AIベンダーとのBusiness Associate Agreement（BAA）が必要です。PHIはデフォルトでTier 4です。ベンダーがBAAに署名できない場合、PHIをそのツールに入力することはできません。

GLBA。 グラム・リーチ・ブライリー法が適用される金融機関は、顧客の金融情報を処理するAIツールがSafeguards Ruleの顧客データ保護要件を満たすことを確認する必要があります。

実務的な運用：機能させながら苦痛なく使う

分類フレームワークが失敗するのは、設計が悪いからではなく実践で使うことができないからです。実際に機能させる方法を説明します。

ソースでデータにラベルを付ける。 データが存在するシステムに階層ラベルを組み込んでください。SharePointドキュメントライブラリに機密ラベルを付ける。CRMフィールドにデータ階層タグを付ける。契約管理システムに分類メタデータを持たせる。データが存在する場所でラベルが付いていれば、社員はタスクの途中にポリシー文書を参照する必要がなくなります。ツールが教えてくれます。

分類を守るプロンプトテンプレート。 AIツールを頻繁に使うチームのために、入力を事前分類する承認済みプロンプトテンプレートを提供してください。提案書作成のための営業チームテンプレートに「自社の内部情報のみをここに入力してください」と書いてあれば、操作のたびにポリシー文書を参照せずにどの階層が適切かを思い出させることができます。

実際の例に基づいたトレーニング。 実際の業務シナリオを提示する分類トレーニングは、抽象的なルールよりも効果的です。「この顧客契約書を起案支援ツールに貼り付けるとき、それはTier 3データです。つまりその契約書AIツールはChatGPT Enterpriseではなくオンプレミス展開を使わなければなりません。」具体的なほうが抽象的なものより伝わります。

インシデントパターンのレビュー。 ほとんどの分類違反は意図的ではありません。該当する場面でルールを知らなかったり思い出せなかったりした結果です。四半期ごとにインシデントパターンをレビューしてください。どの種類のデータがどこに行っているか、違反がどのチームやツールに集中しているか、特定のチームやツールがより高リスクかどうか。パターンを使ってトレーニングを改善する、責任追及ではなく。

例外処理。 Tier 3のユースケースが発生し、正当なビジネス上の理由があり、ベンダーのプライベート展開オプションで対応できる場合があります。例外プロセスを構築してください。申請、CISOのレビュー、特定の契約上のコミットメント確認、期限付き承認。正式な例外経路を持つことで、チームがブロックされるか野放しになるかのどちらかを防げます。

コンプライアンスの監査

入力をログに残す。 DPAを持つエンタープライズAIツールはプロンプトの入力と提出した社員の監査ログを提供するはずです。これを有効にしてください。四半期ごとにその階層に承認されていないツールに入力されたTier 3またはTier 4のコンテンツがないかログをレビューします。

高リスクな役割のスポットチェック。 Tier 3またはTier 4データを定期的に扱う役割（財務、法務、HR、大口契約へのアクセスを持つ営業）はより注意深い監視が必要です。データ階層ルールに対してAIツールの使用ログをレビューする四半期ごとのスポットチェックを行います。

インシデント報告の分析。 報告されたすべてのAIインシデントはデータ分類の観点から評価されるべきです。そのインシデントはTier 2ツールへのTier 3データ入力が原因でしたか？それは分類の適用ギャップです。未承認ツールの使用が原因でしたか？それはシャドーAIのギャップです。インシデントを分類して、一回限りのエラーか体系的な問題かを特定します。

年次全体レビュー。 データの種類は事業の発展に伴い変化します。新しいデータソースが追加されます。規制要件が変わります。現在の分類が最新の事業データと規制要件に合っているかを確認するため、階層割り当てリスト全体を年次でレビューします。

分類は、どのデータをどこに送れるかを教えてくれます。しかしより難しい問題は、AIワークフローが分類されたデータに触れて何かが起きたとき何をすべきか、という問題です。それはまず承認ゲートとベンダーレビューのプロセスが答えなければならない問いです。

Rework分析： AIデータガバナンスのインシデントパターンに基づくと、最も多い違反はTier 2承認ツール（エンタープライズ版ChatGPT、Claude for Business）でのTier 3データ（顧客PII、契約書、財務予測）の処理であり、消費者向けツールでの処理ではありません。これは社員が消費者向けツールを正しく避けながらも、エンタープライズ階層のツールがデフォルト設定ではTier 3データに承認されていないことに気づいていないために起きます。Tier 3データにはプライベートクラウド展開（具体的な契約上のコミットメントが必要）またはオンプレミスAIのいずれかが必要です。この記事のベンダー対応表は、社員がエンタープライズ契約の細かい条文を読むことを前提とせずに、Tier 2/Tier 3の境界線を見えるようにするために設計されています。

次に読む記事

読む：AIユーセージポリシーの構築、この分類フレームワークを実装する6セクションのポリシー構造について。

読む：AI承認ゲートとベンダーレビュー、新しいAI製品がどのツール階層に入るかを判断するベンダー評価チェックリストについて。

読む：AIリスクレジスター：追跡すべき内容、データ分類違反がより広いAIリスク追跡にどう組み込まれるかについて。

読む：ビジネスAIを動かす7種類のデータ、AI能力にはどのようなデータが必要で、どの種類が最も高いガバナンス要件を持つかについて。

関連記事：

• AI Execute アクションの監査証跡：分類されたデータを処理するExecute対応AIワークフローのログ要件
• データ準備：多くのAIプロジェクトが見落とすステップ：AIアクセスルールを適用する前にデータ品質を理解する