「データガバナンス方針をご共有ください」——AI活用の外部発注を進めるなかで、こう依頼された瞬間に手が止まった方は少なくないはずです。社内にはデータ管理の方針を明文化した文書がなく、部門ごとにデータが分散し、責任者も曖昧。にもかかわらず、経営層からは「AI導入を急げ」と背中を押され、開発会社との打ち合わせは目前に迫っている——これがいま、多くの中堅企業の情報システム部門で起きている構図です。
データガバナンスという言葉は、AI活用の文脈で急激に重みを増しています。生成AIやRAG（検索拡張生成）を社内データで動かそうとした瞬間、「どのデータをAIに投入するのか」「誰がその判断をするのか」「AIが誤った出力をしたときに誰が責任を負うのか」といった問いが、発注者側に一斉に突き付けられるためです。開発会社としても、発注者側の管理方針が定まらないまま実装に踏み込むわけにはいきません。
しかし、データガバナンスは「作り込むほど正解に近づく大きな体系」ではなく、「まず輪郭を描き、動かしながら精緻化する仕組み」です。最初から完璧な方針書を求める必要はなく、むしろ AI発注前の段階でどこまで用意しておけば開発会社との会話が前に進むか、その最小構成を掴むことが最優先になります。
本記事では、AI活用を外部発注する立場の情報システム部門・DX推進担当を想定し、データガバナンスとは何か、AIガバナンス・ITガバナンスとどう違うのか、発注者側が最低限整備すべき構成要素・推進体制・導入ステップ・開発会社との合意項目を、AI事業者ガイドライン第1.2版（2026年3月改訂）の観点も踏まえて解説します。読み終えたときには、次の打ち合わせに持って行ける「データガバナンス方針の骨子」の目次が書けるようになることを目指します。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
データガバナンスとは何か——AI活用時代における位置づけ
データガバナンスは、直訳すれば「データの統治」ですが、実務的には「データを組織の資産として位置づけ、その利用・保管・保護・廃棄までを組織横断的に管理する仕組み」を指します。個々のシステム管理やセキュリティ対策の集合ではなく、「データに関する意思決定を、誰が・どのルールで・どの範囲まで行うか」を定める上位の枠組みです。
AI活用が広がる以前、データガバナンスは主にコンプライアンス対応や情報漏えい防止の観点から語られてきました。ところが、生成AIやRAGといった技術が社内データを直接活用しはじめた結果、データガバナンスは「守り」から「攻めと守りを両立させる意思決定基盤」に位置づけが変わっています。
データガバナンスの定義——「データを組織資産として統制する仕組み」
グローバルなデータマネジメントの標準体系であるDMBOK（Data Management Body of Knowledge）は、データマネジメントを、データ資産のライフサイクル全体（計画・方針・手順の策定から実施・監督まで）を通じてその価値を守り高めるための活動と位置づけ、その中心を支える機能としてデータガバナンスを配置しています（出典: DAMA International「DMBOK」、2017年）。
この位置づけを実務向けに言い換えると、データガバナンスとは次の3点を組織的に決めておく仕組みです。
- 方針（ポリシー）: どのデータを、どの範囲で、誰に対して、どこまで利用可能とするかのルール
- 役割（アカウンタビリティ）: データに関する意思決定・品質担保・利用承認を誰が担うかの明確化
- プロセス: データの登録・更新・共有・削除・監査を、日常業務の中でどう回すかの手順
重要なのは、データガバナンスは「情報システム部門だけの仕事」ではないという点です。データを実際に生成・利用するのは各事業部門であり、その品質や範囲を判断するのも各部門のオーナーです。情報システム部門はあくまで仕組みの提供者・運用支援者であり、意思決定の主体は業務部門にあります。
AI活用が発注者にデータガバナンスを迫る3つの理由
なぜ今、AI活用を進める発注企業に対して、開発会社が「データガバナンス方針の共有」を求めてくるのでしょうか。理由は大きく3つあります。
理由1: 学習データの品質責任は発注者側にある
RAGや社内特化型AIは、発注者が提供したデータを基に応答を生成します。データが古い・誤っている・重複しているといった品質問題は、そのままAIの出力品質の問題として顕在化します。開発会社はモデルやアーキテクチャの品質は担保できても、投入されるデータの品質までは責任を持てません。したがって、発注者側が「どのデータを、どの品質水準で提供するか」を事前に定義しておく必要があります。
理由2: データ提供範囲の意思決定は発注者しかできない
「営業部の顧客情報をAIに学習させてよいか」「人事評価データを検索対象に含めてよいか」といった判断は、開発会社には下せません。これは各部門のデータオーナーおよび経営層の意思決定事項です。発注者側にデータガバナンスの体制がないと、この判断が個別案件ごとに宙に浮き、プロジェクトが進みません。
理由3: 法令遵守の主体性は発注者にある
個人情報保護法・改正個人情報保護法上、データの取扱いに関する第一義的な責任は、そのデータを保有する事業者（＝発注者）にあります。開発会社は委託先という立場であり、発注者側でデータの取扱い方針が固まっていない状態では、契約締結にも進めません。総務省・経済産業省が2026年3月31日に公表した「AI事業者ガイドライン第1.2版」でも、AI利用者(発注者に相当)が果たすべき責務としてデータの適切な取扱いが明示されています。
「発注者にデータガバナンスがない」ことで発生する典型的な停滞パターン
データガバナンスが未整備のまま AI発注に進もうとすると、次のような停滞が実際のプロジェクトで頻発します。
- 開発会社との会話が止まる: 要件定義の初回打ち合わせで「対象データの範囲」「アクセス権限」「品質の受入基準」を問われても答えられず、次回持ち帰りが繰り返されて着手が2〜3ヶ月遅れる
- プロジェクトの再見積もりが発生する: PoC段階で「データが想定より汚れていた」「対象外データが混在していた」ことが判明し、開発会社から工数増の見積もり修正が入る
- PoC後の本番移行が断念される: PoCは動いたものの、本番運用に必要なデータ管理体制（品質モニタリング・アクセス監査・削除ポリシー）が発注者側に用意できず、本番移行が凍結される
これらは技術的な問題ではなく、発注者側のガバナンス設計の欠落が原因で発生します。逆に言えば、データガバナンスの骨子さえ用意できていれば、プロジェクトは着実に前進します。
データガバナンス・AIガバナンス・ITガバナンスの違い
データガバナンスの整備に取り掛かる前に、しばしば混乱を招く3つのガバナンス——データガバナンス・AIガバナンス・ITガバナンス——の違いを整理します。開発会社との会話で用語が使い分けられている場面では、「発注者として今、どのガバナンスの話をされているのか」を瞬時に判別できることが重要です。
3つのガバナンスを1枚の表で整理
3つのガバナンスは、対象範囲・目的・主管部門・関連ドキュメントが異なります。
項目 | データガバナンス | AIガバナンス | ITガバナンス |
|---|---|---|---|
主な対象 | データ資産（構造化・非構造化） | AI技術の設計・運用・監視 | IT全般（システム・ネットワーク・組織） |
主な目的 | データの品質・信頼性・利活用の担保 | AIの倫理・透明性・リスク管理 | IT投資の最適化・統制・リスク管理 |
主管部門 | データ管理責任者（CDO）／情報システム部門 | AI推進室／リスク管理部門 | CIO／情報システム部門 |
関連ドキュメント | データポリシー・データカタログ・品質基準 | AI利用ポリシー・AIリスク評価表 | IT戦略書・システム管理規程・ISMS文書 |
関連法規・標準 | 個人情報保護法・DMBOK | AI事業者ガイドライン・EU AI Act | ISO27001・COBIT |
データガバナンスがカバーする範囲——AIガバナンスとの重なり
データガバナンスとAIガバナンスは重なりが最も大きく、実務上の混同も頻発します。整理すると次のようになります。
- データガバナンス: AIに投入する「前」の段階、および出力データの管理までを含む。データそのものの品質・範囲・保管を扱う
- AIガバナンス: AIモデルの選定・学習・運用・監査を扱う。入力データの妥当性判断はデータガバナンス側の成果物を参照する
したがって、AIガバナンスの整備を先に進めても、データガバナンスが未整備であれば「良いモデルに、質の悪いデータが入る」構造から抜け出せません。逆に、データガバナンスを先に整備しておけば、AIガバナンスは「そのデータをどう扱うか」というより具体的な議論に踏み込めます。AIガバナンスの体系についてはAIガバナンスとは？中小企業が取り組むべき体制構築の全手順【2026年版】、生成AI特化の管理体制については生成AIガバナンスとは｜ガイドラインとの違いと構築5ステップで解説しています。
情報セキュリティ・ITガバナンスとの棲み分け
ITガバナンスと情報セキュリティ（ISMS）は、より広い枠組みでデータガバナンスを包含します。整理すると次の階層関係になります。
- ITガバナンス: IT全般の統制（最上位の枠組み）
- 情報セキュリティ（ISMS）: 情報資産の機密性・完全性・可用性（CIA）を守る
- データガバナンス: データ資産の品質・利活用・ライフサイクル管理
- AIガバナンス: AI技術特有のリスクへの対処
つまり、既にISMS認証を取得している企業であれば、情報セキュリティの土台は整っています。データガバナンスは、その上に「データを『守る』だけでなく『活用する』ための意思決定基盤」を追加するイメージです。ITガバナンス・情報セキュリティの基礎はITガバナンスとは？発注者が知るべき情報セキュリティ基礎で整理しています。
発注者が整備すべきデータガバナンスの4つの構成要素
ここからは、AI発注前に発注者側が明文化しておくべき「データガバナンスの4つの構成要素」を、開発会社が実務で参照する順に整理します。この4つを埋めることができれば、開発会社に共有する方針書の骨組みが完成します。
要素1: データポリシー（分類・利用範囲・保管期間・機密度定義）
データポリシーは、データガバナンスの最上位に位置する方針文書です。次の4項目を最低限含めます。
- データの分類: 顧客データ・従業員データ・営業データ・製品データなど、業務単位での分類
- 利用範囲: 各分類データを「誰が」「どの目的で」「どこまで」利用可能かの定義
- 保管期間: 各分類データの保管期限・アーカイブ条件・削除タイミング
- 機密度定義: 「公開」「社内限定」「機密」「極秘」の4段階などで機密度を分類し、AI投入可否の判断基準を紐付ける
AI活用の観点で特に重要なのは、機密度定義とAI投入可否のマッピングです。「機密ランク以上は生成AIに投入しない」「社内限定ランクはRAGの検索対象に含めてよいが、外部出力する回答には含めない」といったルールを事前に定めておくと、開発会社との議論が具体化します。
要素2: 役割と責任（データオーナー・データスチュワード・データガバナンス委員会）
データポリシーだけを作っても、運用する人がいなければ機能しません。データガバナンスでは、次の3つの役割を明確にします。
- データオーナー: 各データ資産の「持ち主」。データの利用範囲や品質水準を最終判断する。多くの場合、そのデータを日常的に扱う業務部門の部門長が務める
- データスチュワード: データオーナーの下でデータ品質を実務的に維持・監視する担当者。データの登録・更新・監査を実行する
- データガバナンス委員会: 部門横断でデータに関する意思決定を行う会議体。ポリシー改訂・部門間の利用調整・重大インシデントの判断などを担う
役割の明文化がなぜ重要かというと、AI開発の途中で発生する「このデータをAIに投入してよいか」という判断は、情報システム部門や開発会社では下せないためです。データオーナーが即答できる体制を作っておかないと、判断待ちでプロジェクトが停滞します。
要素3: データ品質基準（正確性・完全性・鮮度・一貫性の4指標）
AI活用では、投入するデータの品質が出力品質を決定づけます。データ品質の観点は伝統的に次の4指標で語られます。
- 正確性（Accuracy）: データの内容が事実と一致しているか。顧客の住所が最新か、商品名の表記が統一されているか
- 完全性（Completeness）: 必要な項目に欠損がないか。必須項目にNULLが混在していないか
- 鮮度（Timeliness）: データが十分に新しいか。日次更新すべきものが数ヶ月前の状態で放置されていないか
- 一貫性（Consistency）: 同じ意味のデータが複数箇所で矛盾していないか。営業部の顧客マスタと会計部の請求マスタで住所が異なっていないか
AI発注前に、これらの品質指標について「どのデータを、どの水準で提供できるか」を発注者側で把握しておくと、開発会社との受入検査の合意形成がスムーズになります。
要素4: メタデータ管理とデータリネージ（AI学習時のトレーサビリティ確保）
メタデータとは「データについてのデータ」であり、「このデータの意味」「更新履歴」「所有者」「利用制約」などを記述したものです。データリネージはメタデータの一部で、「このデータがどこから来て、どこで変換され、どこに使われているか」の経路情報を指します。
AI活用の観点でメタデータ管理が重要になる理由は、「AIが生成した回答の根拠となったデータを追跡できるかどうか」がガバナンスの成否を分けるためです。誤った回答が発生したとき、どのデータが原因かを特定できなければ、修正も改善もできません。データリネージが整備されていれば、「この回答は7月時点のFAQマスタを参照した結果である」「このデータは3ヶ月前に更新されている」といった追跡が可能になります。
最初から高機能なデータカタログツールを導入する必要はありません。まずはExcelやスプレッドシートでメタデータの一覧（データ名・保管場所・所有者・更新頻度・利用制約）を作成するだけでも、開発会社との会話の共通言語が生まれます。
データガバナンス推進体制の3層モデルと最小構成の目安
構成要素の次は、それを動かす「体制」の設計です。中堅企業では専任者を潤沢に確保することは難しいため、兼務を前提とした最小構成モデルを提示します。
3層モデル（推進責任者／データオーナー／データスチュワード）の役割
データガバナンスの推進体制は、次の3層で設計するのが標準的です。
- 推進責任者（第1層）: 経営層に位置し、データガバナンスの意思決定と予算執行を担う。CDO（Chief Data Officer）やCIOが兼務することが多い
- データオーナー（第2層）: 各業務部門の部門長クラス。担当するデータ領域の利用範囲・品質水準を判断する
- データスチュワード（第3層）: 各部門の現場担当者。データオーナーの方針の下、実際のデータ登録・更新・監査を実行する
この3層は、「意思決定」「範囲判断」「実行」の3段階に対応しています。層を混在させると、意思決定の遅延や実行漏れが発生しやすくなります。
情報システム部門の位置づけ——推進役か実装役か
3層モデルには情報システム部門が明示的に登場しません。これは、情報システム部門をどう位置づけるかが企業ごとに分かれるためです。
代表的な位置づけは2つあります。
- 推進役として位置づける: 情報システム部門の課長・部長が「データガバナンス推進事務局」を務め、全社への周知・委員会運営・ツール導入を担う。中堅企業ではこのパターンが現実的です
- 実装役として位置づける: 情報システム部門はデータカタログやアクセス制御などの仕組みを構築する立場に徹し、業務ルールは別途「データマネジメント推進室」が担う。大企業向けのパターンです
どちらを選ぶにせよ、情報システム部門が「単独でデータガバナンスを構築する主体」になってはいけません。データの意味と価値を判断できるのは業務部門であり、情報システム部門はあくまで支援役です。
中堅企業での最小構成——専任1名＋兼務2名から始めるパターン
従業員100〜500名規模の中堅企業では、次の最小構成から始めることが現実的です。
- 推進責任者: 情報システム部門長 or DX推進担当役員（兼務）
- データガバナンス推進事務局: 情報システム部門の課長クラス1名（専任、または業務時間の50%を割く）
- データオーナー: 主要な業務部門（営業・人事・経理・製造など）の部門長がそれぞれ兼務
- データスチュワード: 各部門から1名ずつを兼務（業務時間の10〜20%）
- データガバナンス委員会: 月1回、上記メンバーで開催
この構成であれば、新規採用や大規模な組織改編なしでスタートできます。まずはこの体制で数ヶ月運用し、必要に応じて専任者を増強する順で進めるのが失敗しにくいアプローチです。
経営層のコミットを引き出すために発注者側が用意すべき論点
体制構築の最大の壁は、経営層の理解と承認を得ることです。「データガバナンスは重要です」という抽象的な訴えは通りにくいので、次の3点をセットで提示すると承認を得やすくなります。
- AI活用プロジェクトが停滞するリスクの金額換算: PoC遅延3ヶ月＝機会損失いくら、といった具体的な数字
- 法令リスクの具体化: 個人情報保護法・AI事業者ガイドラインで発注者側が問われる責任範囲を明示
- 他社動向との比較: 同業他社のAI活用状況とデータガバナンス整備状況（公開情報の範囲で）
経営層は「損失回避」と「他社比較」に反応します。データガバナンスを「守り」ではなく「AI投資を確実に成果に変えるための土台」として位置づけると議論が前に進みやすくなります。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
AI活用を見据えたデータガバナンス導入の5ステップ
構成要素と体制が整理できたら、次は導入のロードマップです。ここでは、AI発注前に着手すべき最短経路として5ステップを提示します。各ステップの成果物（何を作れば次に進めるか）も明示するので、いま自社がどのステップで止まっているかを判定できます。
ステップ1: 対象データの範囲設定（スモールスタートの選び方）
全社データを一度に対象にしようとすると、必ず失敗します。最初の対象は「AI活用プロジェクトで実際に使うデータ」に絞り込むのが鉄則です。
範囲設定の判断基準は次の3つです。
- AI活用ユースケースが具体化しているか: 曖昧なユースケースのデータからは始めない
- データオーナーが明確か: 誰が判断するかが決まっているデータから始める
- 既に一定の品質が担保されているか: 荒れているデータから始めると挫折する
このステップの成果物: 対象データの範囲リスト（データ名・所有部門・想定AI活用シナリオを1枚にまとめた表）
ステップ2: 現状把握とギャップ分析（既存の管理状態を可視化）
対象範囲が決まったら、次は現状の把握です。対象データについて次の項目をヒアリングし、記録します。
- 保管場所（システム名・ファイルサーバのパス・クラウドサービス名）
- 現在のアクセス権限（誰が閲覧・編集できるか）
- 更新頻度と最新性
- 既知の品質問題（重複・欠損・表記揺れの有無）
- 現行のアクセスログや監査ログの有無
現状把握は、業務部門のデータスチュワードにヒアリングする形で進めるのが効率的です。情報システム部門だけで進めると、実際の運用実態と乖離した記録になります。
このステップの成果物: 対象データ×管理項目のマトリクス（ギャップが可視化される）
ステップ3: ポリシー・役割・品質基準の策定（方針書の目次を確定）
現状が可視化されたら、方針書の作成に入ります。この段階では網羅性より「開発会社と会話できる最低ラインを埋める」ことを優先します。
方針書の目次例（AI発注前に最低限埋めるべき項目）:
- データの分類と機密度定義
- AI投入可否のマッピング
- データオーナー・スチュワードの一覧
- データ品質基準（正確性・完全性・鮮度・一貫性）
- アクセス権限と監査の方針
- インシデント発生時のエスカレーションルート
このステップの成果物: データガバナンス方針書（初版・骨子レベル）
ステップ4: ツール・運用フローの整備（データカタログ／メタデータ管理の最小構成）
方針書ができても、日常運用に落とし込まなければ形骸化します。最初から高機能ツールを導入する必要はなく、次の順で段階的に整備します。
- メタデータ管理: Excel・スプレッドシートで対象データのメタデータ一覧を作成
- アクセス管理: 既存のIDaaS・Active Directoryなどでロールベースのアクセス制御を実装
- 監査ログ: クラウドサービスやDBの標準機能で監査ログを有効化
- データ品質チェック: 主要な品質指標について、月次・四半期の点検を業務化
規模が拡大した段階でデータカタログツール（TalendやAlationなど）や品質管理ツールを追加する順が現実的です。
このステップの成果物: 運用フロー図と管理台帳のテンプレート
ステップ5: モニタリングと継続改善（KPIと見直し周期の設計）
データガバナンスは「作って終わり」ではなく、継続改善が必須です。次のKPIを月次・四半期で追跡します。
- データ品質スコア（正確性・完全性・鮮度・一貫性の各指標）
- アクセス権限の異常検知件数
- インシデント発生件数と解消までのリードタイム
- データガバナンス委員会の意思決定件数（活動が形骸化していないかの指標）
方針書自体も、少なくとも年1回は見直し、AI活用の進化や法令改正を反映します。
このステップの成果物: KPIダッシュボードと見直しスケジュール
発注時に開発会社と合意すべきデータガバナンス5項目
本記事の中核となるセクションです。AI開発を外部委託する際、契約前あるいは要件定義前に発注者と開発会社の間で必ず合意しておくべき5項目を、実務チェックリスト形式で提示します。次の打ち合わせに、そのまま持って行ける粒度に落としています。
項目1: 対象データの範囲——AIに投入する／しない境界線の定義
最初に合意すべきは、AIに投入するデータと投入しないデータの明確な境界線です。「顧客の個人情報のうち氏名と電話番号は投入しない」「社内文書のうち機密ランク以上は対象外」といったレベルで具体化します。曖昧にしたまま進めると、開発中盤で「実は投入予定だった」データが発覚し、要件変更が発生します。
- 投入するデータの一覧（データ名・レコード数・カラム構成の概要）
- 除外するデータの一覧と除外理由
- グレーゾーンのデータの取扱い方針（サンプリング判断・マスキング等）
項目2: 保管場所と越境データ——クラウド／オンプレ／国外リージョンの取り扱い
AI活用ではデータの物理的保管場所も重要な合意事項です。特にクラウドサービスを利用する場合、リージョン（データの物理配置国）を明示的に指定する必要があります。国外リージョンにデータが渡ることは、個人情報保護法上の「越境移転」に該当する場合があります。
- 学習データ・利用ログの保管リージョン
- バックアップの保管先
- 開発会社側の社内システムに一時的にコピーされるデータの範囲
- 生成AIサービスを介する場合、そのサービスのデータ利用ポリシー（学習に使われるか等）
項目3: アクセス権限と監査ログ——開発会社側担当者への付与範囲
開発会社の担当者に、どのデータへの、どのレベルのアクセス権を付与するかを明確にします。開発中と本番運用中で異なる権限設計が必要です。
- 開発フェーズでのアクセス権限（担当者名・付与範囲・期間）
- 本番運用フェーズでの権限（保守担当者のアクセス範囲・緊急時の対応）
- 監査ログの取得範囲・保管期間・確認頻度
- 権限の付与・剥奪プロセス（プロジェクトメンバーの入退時の手順）
項目4: データ品質水準——受入検査で確認する指標
開発会社に提供するデータの品質水準と、開発会社が受入時に確認する検査項目を合意します。「提供時点で欠損率を10%以下にする」といった具体的な数値目標を持つのが望ましいですが、初期段階では検査項目の合意だけでも十分です。
- 提供データの品質チェック項目（欠損率・重複率・鮮度）
- 品質不足時の対応プロセス（発注者側でのクリーニングか、開発会社側の前処理での吸収か）
- 継続的な品質モニタリングの責任分担
- 定期的な品質報告のフォーマットと頻度
項目5: 削除・再学習ポリシー——プロジェクト終了時／モデル更新時の扱い
プロジェクトが完了した時点、あるいはモデルを更新する際のデータ・モデルの扱いを事前に合意します。多くの発注者がここで見落とすため、後々のトラブル原因になります。
- プロジェクト終了時の学習データの削除方法・削除証跡
- 生成AIモデルに含まれる学習痕跡の扱い（消去可能なのか、事実上残るのか）
- 定期的な再学習の頻度と、その際の追加データの受入プロセス
- 契約終了時のデータ返還・削除に関する条項
これら5項目を合意事項として文書化し、開発会社と共有すれば、要件定義以降の議論が具体的なユースケース設計に集中できます。
データガバナンス整備で参照すべきガイドラインと関連法規
データガバナンスの整備を進める上で、発注者が押さえておくべき公的ガイドラインと法規を、参照順序と使い分けの観点で整理します。全部を精読する必要はなく、自社の状況に応じた優先順位で読み解けば十分です。
AI事業者ガイドライン第1.2版（2026年3月改訂版）——AI利用者としての立ち位置
総務省・経済産業省が2026年3月31日に公表した「AI事業者ガイドライン第1.2版」は、AI活用に取り組む事業者が最初に読むべき文書です。ガイドラインは「AI開発者」「AI提供者」「AI利用者」の3つの主体別に指針が整理されており、AI導入を発注する企業は主に「AI利用者」に該当します。
AI利用者としての責務のうち、データガバナンスに関わる主要な観点は次のとおりです。
- 学習・利用するデータの適正性の確保
- プライバシー・機密情報の管理
- AIの出力に対する人間の関与と判断責任
- インシデント発生時の対応体制
ガイドライン自体は法的拘束力を持たないソフトローですが、契約書・監査対応・社内規程の作成時に参照されるデファクトスタンダードになりつつあります。
個人情報保護法・改正個人情報保護法——AIモデルへの学習データ利用の論点
個人情報保護法は、データガバナンスの根幹に関わる法規です。特にAI活用の文脈では次の論点を押さえます。
- 利用目的の特定と通知: 収集時点の利用目的にAI学習が含まれているか
- 第三者提供の制限: 開発会社に個人データを渡す場合の委託契約の範囲
- 越境移転の制限: 国外リージョンに個人データが渡る場合の同意・情報提供義務
- 本人の権利: 開示・訂正・削除請求への対応がAI環境下で可能か
個人情報保護委員会が公表するガイドラインは頻繁に改訂されるため、最新版を参照することが重要です。
DMBOK・DAMAフレームワーク——グローバルスタンダードとしての参照体系
DMBOK（Data Management Body of Knowledge）は、DAMA International（Data Management Association International）が策定するデータマネジメントの世界標準体系です。第2版以降、データガバナンスを中心に据えた11の知識エリアで構成されています（出典: DAMA International「DMBOK2」、2017年）。
DMBOKを丸ごと導入する必要はありませんが、「自社のデータガバナンス設計が体系的な観点を漏れなく網羅できているか」を確認するチェックリストとして参照する価値があります。特に、データ品質・メタデータ・データセキュリティといった個別領域の実装方針を検討する際の参考文献になります。
業界別ガイドライン（金融・医療・行政）——業種特有の追加規制の存在確認
業種によっては、業界固有のデータ管理ガイドラインが存在します。
- 金融: 金融庁「金融分野におけるAIシステム／サービスの利用に関するガイドライン」など
- 医療: 厚生労働省「医療情報システムの安全管理に関するガイドライン」
- 行政: 「政府情報システムにおけるクラウドサービスの利用に係る基本方針」
自社が該当業界にある場合、汎用的なガイドラインだけでなく業界固有のルールを併せて確認する必要があります。開発会社に業種特有の要件を伝え損ねると、後工程で大きな手戻りが発生します。
まとめ——AI発注前に最初の一歩として何をするか
ここまで、データガバナンスの定義から始まり、AIガバナンス・ITガバナンスとの違い、4つの構成要素、3層の推進体制、導入5ステップ、開発会社との合意5項目まで解説してきました。最後に、いま開発会社との打ち合わせを控えている読者が、明日から着手できる最短アクションを3つに絞って提示します。
アクション1: 対象データの範囲を1枚の表にまとめる
AI活用プロジェクトで実際に投入予定のデータについて、データ名・所有部門・想定利用シナリオ・機密度（暫定）を1枚のスプレッドシートにまとめます。網羅性は求めず、まず10〜20行程度で構いません。この1枚があるだけで、開発会社との会話は劇的に前進します。
アクション2: データオーナーを暫定的にでも決めて、共有する
対象データそれぞれについて、「暫定的にでもよいから、判断を下せる部門長を1名指名する」ことを進めます。正式な任命は後回しでも、まず名前を紐づけておくと、開発会社からの問い合わせに対する判断が滞りません。
アクション3: 開発会社との合意5項目の草案を作成する
先述の「発注時に開発会社と合意すべきデータガバナンス5項目」について、現時点の暫定案を A4 1枚に書き出します。空欄が多くても構いません。空欄自体が「発注者側で決めるべき論点」の可視化になります。5項目それぞれの着手ポイントを社内で分担すれば、次の1週間で草案の輪郭を埋められます。
- 項目1: 対象データの範囲: アクション1でまとめた1枚表の各データについて、「投入する／投入しない／要検討」の3値を仮置きする（担当: DX推進担当）
- 項目2: 保管場所と越境データ: 想定するクラウドサービス名とデフォルトリージョン（東京／米国など）を確認し、越境移転が発生するデータの有無を洗い出す（担当: 情報システム部門）
- 項目3: アクセス権限と監査ログ: 現行のIDaaS・Active Directoryで開発担当者に付与できるロール一覧を棚卸しし、開発フェーズと本番フェーズで分けて記述する（担当: 情報システム部門）
- 項目4: データ品質水準: 対象データの直近の欠損率・重複率・更新頻度をアクション2で指名したデータオーナーにヒアリングして数値化する（担当: 各データオーナー）
- 項目5: 削除・再学習ポリシー: 現行の業務委託契約テンプレートにデータ返還・削除条項が含まれているかを法務部に確認し、不足分を洗い出す（担当: 法務部・情報システム部門）
データガバナンスは、完璧を目指すほど動き出しません。逆に、輪郭だけでも先に描いてしまえば、開発会社との議論を通じて自然に精緻化されていきます。「まず動かす」ことを優先し、走りながら整えていく姿勢が、AI活用を成果につなげる発注者に共通する行動様式です。本記事の内容が、次の打ち合わせを一歩前に進める助けになれば幸いです。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- データガバナンス方針書は、開発会社に共有する前に完璧に仕上げなければなりませんか？
完璧である必要はありません。データガバナンスは「作り込んでから始める」のではなく「輪郭を描き、動かしながら精緻化する」仕組みだからです。骨子レベルの方針書でも、未確定の項目を空欄のままにせず「検討中の論点」として明示すれば、開発会社はその論点を一緒に詰める前提で提案を調整しやすくなります。初回共有では完成度よりも、次回打ち合わせまでに埋めるべき論点が明確かを重視してください。
- ISMS（ISO27001）認証を取得していれば、データガバナンスは別途整備しなくても大丈夫ですか？
いいえ、別途整備が必要です。ISMSは情報の機密性・完全性・可用性を守る仕組みであり、AIに投入するデータの品質や利用範囲、機密度に応じたAI投入可否の判断はカバーしていません。例えば「社内限定ランクのデータをRAGの検索対象に含めてよいか」といった判断は、ISMS認証の有無にかかわらずデータオーナーが個別に下す必要があり、この意思決定基盤こそがデータガバナンスの役割です。
- 専任担当者を置けない小規模な情報システム部門でも、データガバナンス体制は機能しますか？
機能します。専任担当者を新規に採用しなくても、情報システム部門長が推進責任者を、各業務部門長がデータオーナーを兼務する最小構成で立ち上げ可能です。データスチュワードも各部門から業務時間の10〜20%を割く兼務者で十分に運用できます。まずはこの体制で数ヶ月試行し、委員会の意思決定件数や品質指標の推移を見ながら、必要に応じて専任者の増強を検討する進め方が現実的です。
- 開発会社に「データガバナンスがまだ整っていない」と正直に伝えると、契約や提案に不利になりませんか？
不利にはなりません。むしろ現状と対象データの範囲を先に共有したほうが、開発会社は要件定義の精度を上げやすく、後工程の手戻りを防げます。未整備なまま曖昧に進めると、PoC段階でデータの汚れが判明して再見積もりが発生したり、本番移行に必要な管理体制が整わず凍結されたりするケースが実際に多く見られます。整っていない事実を先に伝えるほうが、結果的に手戻りコストを抑えられます。
- データガバナンス委員会は必ず月1回開催しなければなりませんか？
必須ではありません。立ち上げ期は意思決定事項が多いため月1回が目安ですが、運用が安定した後は四半期に1回などへ頻度を調整して構いません。判断基準は開催頻度そのものではなく、データオーナー間の利用調整や重大インシデントの判断が滞留していないかです。委員会が形骸化していないかは、KPIとして意思決定件数を追跡することで確認できます。
