社内データガバナンスの構築法：法務・IT部門が押さえるべきポイント

1　最初に押さえる結論：データガバナンスは「台帳・権限・ルール・監視」の4点から始める

データガバナンスを大規模なDXプロジェクトとして始める必要はありません。まず重要なのは、データの所在を把握し、責任者を決め、利用・保存・提供のルールを設定し、その運用状況を確認できる状態を作ることです。

2　データガバナンスと情報セキュリティ・個人情報保護の違い

情報セキュリティは、機密性・完全性・可用性を確保するための防御や管理が中心です。個人情報保護は、個人の権利利益を守るために個人情報の取得・利用・提供等を規律します。これに対し、データガバナンスは、個人情報に限らず、営業秘密、技術情報、財務情報、ログ、AI学習・入力データ等も含め、データの価値とリスクを全社的に管理する枠組みです。

デジタル庁のデータガバナンス・ガイドラインも、データを企業価値向上のための経営資源として位置付け、越境データ、データセキュリティ、データマチュリティ、AI等の先端技術への対応を重要な柱として示しています。したがって、法務部門だけでも、IT部門だけでも完結しません。

ここで重要なのは、ガバナンスを「守りの規制対応」だけにしないことです。データの定義、品質、責任者、共有方法が統一されていれば、営業・経営企画・開発が同じデータを再利用しやすくなり、重複収集や手作業の照合作業も減ります。逆に、品質や来歴が不明なデータは、AI分析や経営判断に利用するほど誤った意思決定のリスクを高めます。法令遵守とデータ活用は対立するものではなく、共通基盤を整えることで両立させるものと考えるべきです。

3　法的な基盤：個人情報保護法22条～25条をライフサイクルで捉える

個人情報保護法には「データガバナンス」という名称の義務はありません。しかし、社内ガバナンスを構成する重要な義務が複数定められています。2026年6月改正のPPC通則ガイドラインでは、安全管理措置について、リスクに応じた必要かつ適切な内容とすることが求められています。

重要なのは、条文ごとに別々のチェックリストを作るのではなく、取得→利用→共有→保存→削除というデータライフサイクルに沿って統合することです。

4　最初の実務は「データマップ」と「処理台帳」を作ること

どのデータを保有しているか分からない状態では、アクセス制御も削除も監査もできません。最初に、主要なシステム・共有ドライブ・SaaS・データベース・端末・委託先を対象に、データの所在を洗い出します。

台帳に最低限入れたい項目

全社のファイルを一件ずつ登録するのではなく、「採用管理」「給与計算」「顧客管理」「営業分析」「サービスログ」など処理活動単位で整理すると運用しやすくなります。GDPRが適用される企業では、Article 30の処理活動記録（RoPA）との統合も検討できます。

データ品質とデータ来歴も台帳の一部にする

ガバナンスでは「漏えいしないこと」だけでなく、「正しいデータを使っていること」も重要です。同じ顧客を複数IDで登録している、更新元が分からない、CSV転記で値が変わる、誰が加工した集計値か追えないといった状態では、誤送信・誤請求・誤分析にもつながります。

重要データについては、元システム、取得元、更新責任者、加工処理、連携先を追えるようにします。いわゆるデータリネージュを詳細な技術図として作る必要はありませんが、「どこから来て、どの処理を経て、どこへ渡るか」を説明できることが重要です。AI学習・分析基盤へ投入するデータでは、出所・利用条件・品質の確認が特に重要になります。

5　データ分類は3～4段階に絞り、現場が判断できるようにする

「すべて重要情報」と分類すると、結局すべて同じ扱いになり、重要度に応じた管理ができません。実務上は、公開可否と漏えい時の影響を基準に3～4段階程度へ分類し、各区分に具体的な取扱方法を対応させるのが現実的です。

不正競争防止法上の営業秘密として保護を受けたい情報については、秘密管理性・有用性・非公知性の3要件を意識します。2025年3月改訂の営業秘密管理指針は、秘密として管理しようとする情報の範囲を従業員等に認識可能な状態にすることを重視しており、データ分類とアクセス管理は営業秘密保護の基盤にもなります。

6　アクセス権限は「付与」より「棚卸し」と「剥奪」が難しい

PPCガイドラインは、個人データについてアクセス制御とアクセス者の識別・認証を求めています。実務では、入社時よりも異動・兼務・退職・プロジェクト終了後に権限が残り続けることが大きなリスクです。

権限管理の基本フロー

・Joiner：入社・着任時に職務に必要な最小権限のみ付与

・Mover：異動・兼務変更時に旧権限を見直す

・Leaver：退職・契約終了時にアカウント・APIキー・共有リンクを停止

・Periodic Review：特権ID・機密データは定期的に棚卸し

「部長だから全部見られる」「管理者だから常時アクセス可能」という設計では、職務上の必要性と権限が一致しません。権限グループを職務単位で設計し、例外権限には期限・承認者・理由を記録する運用が有効です。

6-1　裁判例：クラウドに保存するだけでは「秘密管理」にならない

大阪地方裁判所の裁判例では、取引先・取引内容等の情報が会社契約のクラウドに保存され、全従業員以外の第三者は自由にアクセスできない状態にあったものの、営業秘密である旨の表示がなく、一般の業務ファイルと区別されず、全従業員がアクセスでき、対象情報を具体的に秘密として扱う規程・注意喚起・研修等もなかったことから、秘密管理性が否定されました。裁判所は、社外の第三者が自由にアクセスできないようにしているだけでは、特定の情報を秘密として管理しているとはいえないとしています。

また、東京地方裁判所の裁判例では、情報管理規程、ITセキュリティ基準、社内通達、情報セキュリティ研修、部署単位のアクセス制限等が整備されていた一方、部署内では担当外案件にも事実上アクセスでき、機密性の異なる大量のファイルが混在し、個々のファイルに「極秘」「Confidential」等の表示もなかったことなどから、不正競争防止法上の営業秘密性が否定されました。

もっとも、この東京地裁判決は、営業秘密性が否定されたからといって、従業員による持出しが許されるとはしていません。会社の管理外にある私的オンラインストレージへの大量アップロードや、競合会社に勤務する第三者への送信については、機密保持違反、情報管理規程違反、公私混同等の懲戒事由に該当するとし、事案の重大性等を踏まえて懲戒解雇も社会通念上相当と判断しました。

これらの裁判例からは、「営業秘密として法的保護を受けるための管理」と「社内情報として利用・複製・持出しを統制するための管理」を分けて設計する必要があることが分かります。重要データについては、単に社内クラウドへ保存するだけでなく、分類、秘密表示、アクセス範囲、複製・持出しルール、教育・周知、異動・退職時の権限処理までを一体として運用することが重要です。

7　ログは「全部取る」より、監査目的を先に決める

ログ保存の目的は、事故後の調査だけではありません。通常時に、誰が、いつ、どのデータへアクセスし、何を行ったかを確認できる状態を作ることが重要です。ただし、無期限・無目的に大量保存すれば、コストだけでなく新たな情報資産・個人情報リスクを生みます。

重要システムでは、認証、権限変更、ダウンロード、外部共有、管理者操作、削除、API利用等を中心に監査ログを設計し、保存期間を決めます。ログそのものに個人情報や機密情報が含まれる場合には、ログへのアクセス権限や保管場所もガバナンスの対象です。

8　保存期間・削除：個人情報保護法に一律の保存年限はない

旧稿のように「保存期間終了後は必ず一定期間内に削除」と一律に説明するのは適切ではありません。PPCのQ&Aは、個人情報保護法自体は一律の保存期間や廃棄時期を定めていない一方、法22条に基づき、利用する必要がなくなった個人データは遅滞なく消去するよう努めるとしています。

したがって、データごとに、業務上の必要性、法令上の保存義務、契約、訴訟・紛争対応、監査、バックアップ運用を踏まえて保持期間を定めます。削除期限だけでなく、「何をもって利用不要と判断するか」「バックアップからいつ消えるか」「削除を一時停止するリーガルホールドを誰が判断するか」を決めておく必要があります。

保存期間表に入れたい項目

9　生成AI利用をデータガバナンスから切り離さない

生成AIの利用は「AIポリシー」だけで管理すると、既存のデータ分類・委託先管理・秘密情報管理と二重構造になります。2026年3月のAI事業者ガイドライン第1.2版、2025年施行のAI法、PPCの生成AI利用に関する注意喚起を踏まえ、既存のデータガバナンスへAI利用を組み込む方が実務的です。

PPCは、個人情報を含むプロンプト入力について利用目的の範囲内であることを確認するよう求め、本人同意なく個人データを入力し、そのデータが応答生成以外の目的、例えばモデル学習に利用される場合には個人情報保護法違反となる可能性があると注意喚起しています。

社内AI利用ルールに最低限入れたい事項

10　クラウド・委託先・再委託は「データの行き先」を管理する

SaaS、クラウド、BPO、開発会社等にデータを預ける場合、契約書だけ確認して終わるのではなく、どのデータが、どの事業者に、どの国・リージョンで、どの再委託先を通じて処理されるかを把握する必要があります。

個人データの取扱いを委託する場合は法25条の監督義務が問題となり、外国にある第三者への提供に該当する場合は法28条の検討が必要です。クラウドが直ちに「委託」や「第三者提供」に該当するわけではないため、サービス提供者がデータを取り扱う権限・実態を確認して法的関係を整理します。

委託先台帳で管理したい項目

11　越境データは「保存場所」だけでなくアクセス可能性を見る

国外リスクは、サーバの物理所在地だけで判断できません。外国の拠点・委託先から国内サーバへアクセスできる場合、外国法制や現地でのデータ取扱いを確認すべき場面があります。PPCガイドラインが安全管理措置として「外的環境の把握」を求めていることからも、クラウド契約時には保存国、運用拠点、サポートアクセス、再委託先まで確認するのが安全です。

グローバル企業では、国別にバラバラの申請様式を作るより、データ移転台帳に「送信元・送信先・データ種類・目的・法的根拠・安全措置」を記録し、法務が例外をレビューする運用が有効です。

12　法務・IT・事業部門の役割を分ける

データガバナンスが失敗する典型は、「個人情報は法務」「システムはIT」と縦割りにすることです。実際には、法的要件を技術設定へ変換し、システム上の制約を規程・契約へ反映する相互連携が必要です。

日本法上、一般企業に一律のDPO設置義務はありません。責任者の名称よりも、権限・報告先・レビュー対象を明確にすることが重要です。GDPRが適用される場合のDPO義務は「一定規模以上」ではなく、公的機関、大規模な定期的・体系的監視、大規模な特別カテゴリーデータ処理等の要件で判断します。

ガバナンス会議は「報告会」ではなく判断の場にする

部門横断のデータ委員会を置く場合、件数報告だけで終わると形骸化します。会議で扱うべきなのは、例外承認、高リスクAI利用、重大な委託先変更、長期未是正事項、データ削除の例外、国外移転、新規二次利用など、部門単独では決めにくい論点です。

会議資料も、事故件数だけでなく、権限棚卸し未完了、削除期限超過、未承認SaaS、重大監査指摘、委託先評価未了などの指標を定点観測します。経営層が「どのリスクを許容し、どこへ投資するか」を判断できる情報にすることが重要です。

13　新規サービスの前に「データ審査」を入れる

データガバナンスを既存システムの後追い監査だけにすると、問題が設計段階で作り込まれます。新規サービス、SaaS導入、AI導入、分析基盤構築、顧客データの二次利用、国外移転などを開始する前に、簡易なデータ審査を入れる方が効率的です。

新規案件の事前確認項目

GDPRが適用される企業では、Data Protection by Design and by DefaultやDPIAとの接続も必要です。日本企業でも、高リスクな個人情報利用やAI利用については、事前レビューの考え方を採り入れると、後からの大幅改修を避けやすくなります。

14　例外申請を認めるなら、期限と責任者を必ず付ける

現場では、レガシーシステム、取引先要請、短期プロジェクト等の理由で標準ルールを満たせない場面があります。例外を全面禁止すると、無断利用やシャドーITが増えることがあります。

そのため、例外には①理由、②対象データ、③代替措置、④承認者、⑤期限、⑥見直し日を記録します。「一度例外を承認したら恒久化」することを避け、期限到来時に標準へ戻すか再承認する仕組みにします。

15　監査は一律年1回ではなく、リスクに応じて設計する

個人情報保護法やPPCガイドラインが、全てのデータガバナンス監査を一律年1回と定めているわけではありません。PPCガイドラインは、取扱状況の自己点検や他部署・外部者による監査を例示しつつ、具体的方法はリスクに応じて決める考え方を採っています。

最重要データ、特権ID、外部共有、AI利用、退職者権限などは頻度を高め、低リスクな領域はサンプル確認とするなど、重点監査が有効です。監査で指摘するだけでなく、是正期限・責任者・再確認日まで管理することが重要です。

16　KPI・KRIで「守れているか」を数値化する

データガバナンスは、事故件数だけを指標にすると、事故が起きていない間は統制の実効性を測れません。平時の管理状況を示すKPI・KRIを設定します。

数値は取締役会やリスク委員会へ定期報告できる形にすると、データガバナンスをIT部門だけの運用課題ではなく、経営リスクとして扱いやすくなります。

17　90～180日で構築する現実的なロードマップ

全社一斉に完璧な台帳を作ろうとすると止まりやすいため、顧客DB、人事、決済、生成AI利用、重要技術などリスクの高い領域から始め、対象を段階的に広げる方法が現実的です。

初期段階ではExcelや既存のIT資産台帳を使っても構いません。重要なのは、専用ツールの導入そのものではなく、台帳を更新する業務イベントを決めることです。新規SaaS導入、システム改修、委託先変更、退職、データ二次利用、AI導入などをトリガーに台帳が更新される仕組みを作らなければ、作成直後から陳腐化します。

また、データガバナンスは一度完成して終わる制度ではありません。組織変更、M&A、新規事業、法改正、クラウド構成変更、AIモデル変更などに応じて見直す必要があります。年次レビューだけに依存せず、大きな変更時に随時レビューする「イベント駆動型」の運用を併用することが実効性につながります。

18　よくある失敗と修正方法

19　2026年改正個人情報保護法への備え

2026年7月17日に改正個人情報保護法が公布されましたが、多くの規定は公布から2年以内で政令が定める日から施行され、2026年9月15日時点では政令・規則・ガイドライン等の整備が続いています。

したがって、現時点のデータガバナンスは現行法・現行ガイドラインに基づいて運用しつつ、法令台帳に「改正待ち」の項目を設け、施行日・規則・ガイドライン確定時に規程、台帳、システム設定を見直せるようバージョン管理しておくことが安全です。

20　FAQ

21　企業が整備しておきたい実務チェックリスト

22　まとめ：データガバナンスは「データを使える状態」にする法務基盤

データガバナンスの目的は、データ利用を止めることではありません。どのデータなら、誰が、どの条件で、安全かつ適法に利用できるかをあらかじめ決めることで、事業部門が安心してデータを活用できる状態を作ることです。

そのためには、法務が規程だけを作る、ITがセキュリティ設定だけを行うという分業では足りません。データ台帳、分類、権限、保存・削除、AI、委託先、越境移転、監査を一つの運用体系にし、経営層がリスクと改善状況を把握できるようにすることが重要です。

新規サービスやAI利用が増える企業ほど、問題発生後に個別対応するより、平時のデータガバナンスを整備した方が、法的リスクの低減と事業スピードの両立につながります。

23　主要な裁判例・公的資料

• 【裁判例】大阪地方裁判所判決（令和3年（ワ）第11560号）
• 【裁判例】東京地方裁判所判決（令和2年（ワ）第27963号）
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（令和8年6月一部改正）
• 個人情報保護委員会「個人情報保護法ガイドラインに関するQ&A」
• デジタル庁「データガバナンス・ガイドライン」（2025年6月20日）
• 経済産業省「サイバーセキュリティ経営ガイドライン Ver3.0」
• 経済産業省「営業秘密管理指針」（2025年3月改訂）
• 経済産業省・IPA／AISI「AI事業者ガイドライン 第1.2版」（2026年3月31日）
• 内閣府「人工知能関連技術の研究開発及び活用の推進に関する法律（AI法）」および同法に基づく適正性確保指針
• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」
• 個人情報保護委員会「令和8年 改正個人情報保護法について」
• European Commission / EDPB: GDPR obligations, Data Protection by Design and by Default, DPO guidance