AI活用をデータガバナンスで止めないために｜データオーナーとデータスチュワード

AI活用が事業側で進み、データやツールの使用許可がDX推進・情報システムにどんどん回ってくる。
しかし、「そのデータの正しさは誰が担保するのか」「誰の許可で他部門と連携してよいのか」「品質が崩れたときに誰が直すのか」。これらに答えられる人が社内にいない、という手詰まりに直面しているDX推進・情報システム担当者もいるかと思います。

情シスからすれば「それは事業側が決めること」、事業側に戻せば「基盤は情シスの領域」。
責任範囲が組織の境目で宙に浮いたまま、データ整備そのものが進まない。
この状態を「役割と責任を設計できる状態」にするのが本記事の目的です。

以下では、なぜデータガバナンスが進まないのかを構造で言語化し、両者の違いを比較で整理、横断責任者の位置づけを確認したうえで、役割を形骸化させないための4つの仕組みまで整理します。

データガバナンスが追いつかない現実

AI失敗の半分近くは、データの整備が原因

AI活用で成果が出るかどうかは、モデルの選定よりもデータの整備で決まる。
直近の調査は、この認識が数字として現れつつあることを示しています。

データ統合基盤を提供するFivetranは、2025年第1四半期に日米欧アジアの企業のデータ責任者401名を対象に「AI Data Readiness Survey」を実施し、42%が「自社のAIプロジェクトの半数以上が、データ整備の問題で失敗または遅延した」と回答したことを公表しました（Fivetran公式リリース, 2025-05-13）。

同じ調査では結果側の数字も出ています。
データが半分未満しか統合されていない企業のうち68%が、失敗または遅延したAIプロジェクトによって収益機会を失っていると回答しました。
原因の側でも結果の側でも、AIの成否がデータ整備の状態に強く連動していることが読み取れます。

AI活用が進んだ現在、次の課題はデータにあるということをこれらの数字が示しています。

なぜ、ガバナンスは追いつかないのか

では、なぜデータの整備が進まないのか。
話を前に進めようとすると必ずぶつかるのが、責任範囲の曖昧さです。
これは、大きく2つの構造で起きています。

1つ目は、組織間の投げ合いです。
データ整備を情報システム部門に投げれば「そのデータをどう使うかは事業側が決めることで、こちらは基盤しか扱えない」と返ってくる。
事業部門に戻せば「基盤の整備は情シスの領分だから、こちらから動きようがない」と返ってくる。
責任範囲が組織の境目であいまいのまま、話が動かない状態です。

2つ目は、部門の内側で起きています。
仮に「事業部門が担当する」と大枠で決まったとしても、その部門のなかで誰の仕事かが明文化されていない、というつまずきです。

「部門として持つ」ことにはなっていても、実際に手を動かす個人が指名されていないため、誰も動き出さない。
担当者を決めるための部内会議も、忙しさに押されていつまでも開かれない。
結果、部門としての担当という名目だけが残り、動きは何も起きないまま数週間が経過する、という展開になります。

この2つが重なるため、「データガバナンスは大事だ」という総論では全員が合意していても、実務のレベルで前に進められない状態に陥ります。
総論の合意と、実務の停滞が両立してしまうのが、AI活用を止めてしまっている問題です。

AI活用をガバナンスで止めないために

問題ははっきりしています。
責任の所在が宙に浮いている。だからガバナンスも進まず、AI活用も止まる。

逆に言うと、責任を「役割」として設計し、その役割が忙しさに押されて形だけにならない運用にできれば、ガバナンスはAI活用のブレーキではなく、止まらないための運用の仕組みとして機能します。

以下では、その設計を3ステップに分けて開いていきます。

まず、決定に責任を持つ人と実行に責任を持つ人を、役割として明文化する。
データオーナーとデータスチュワードという2つの役割です。

次に、部門ごとの役割だけでは横断判断が止まるため、全社に一人の横断責任者を置く。

最後に、役割を決めた後で形骸化させないための4つの仕組み。
責任を役職に紐づけ、チェックをツールに寄せ、経営の場で可視化し、必ずカレンダーに入れる、を実装するところまでを扱います。

責任範囲を設計する｜データオーナーとデータスチュワード

データオーナー：決めることに責任を持つ役割

データオーナーとは、担当するデータ領域について、事業上の説明責任と決定権限を持つ人のことです。
この定義は、データマネジメント分野の国際標準的な参照文書であるDAMA-DMBOK(Data Management Body of Knowledge)に沿ったもので、「事業部門の人物であり、担当ドメイン内のデータに関する意思決定について説明責任を負う」と整理されています（Actian: Data Owner vs. Data Steward）。

任命される人は、そのデータを実際に使う事業部門の長で、多くの場合、部長クラスです。
営業データであれば営業部長、人事データであれば人事部長、というかたちで割り当てられます。

責任範囲は、主に次の4つで整理できます。

• データの定義と分類
  何をこのデータ領域に含め、機密性はどのレベルかを決めます。

• アクセス権限の承認
  誰がこのデータを見られるか、他部門・外部への連携を許可するかを判断します。

• データ品質の基準設定
  「このデータはどの水準まで整っていれば業務・分析で使えるか」の合意水準を定めます。

• 活用の説明責任
  整備されたデータが実際に事業価値を生んでいるか、投資対効果を経営に対して説明します。

一言でまとめると、データオーナーはWhatに答える人です。
「このデータをどう扱うべきか」「何を許し、何を許さないか」の判断を出す立場にあります。

データスチュワード：日々の運用に責任を持つ役割

データスチュワードとは、データオーナーが決めた方針を、日々のデータで実行する人のことです。
データマネジメントコーチのNicola Askhamは、この関係を「データオーナーがAccountable(説明責任)、データスチュワードがResponsible(実行責任)」と表現しています。
判断を下すのがオーナー、手を動かすのがスチュワードという分業です（Nicola Askham: Data Owners and Data Stewards）。

任命される人は、現場でデータを実際に扱う実務担当です。
事業部門のなかでデータに詳しいアナリスト、業務エキスパート、あるいはデータ活用の担当者が該当します。

責任範囲も、大きく4つで整理できます。

1つ目は、データ品質の監視。
決められた品質基準にデータが達しているか、日々確認する。

2つ目は、メタデータ(データの辞書)の維持。
カラム名の意味、算出ロジック、更新頻度などを最新の状態に保つ。

3つ目は、ルールの実行。
データオーナーが承認したアクセスルール・分類ポリシーを、実際のデータに適用する。

4つ目は、利用者への窓口対応。
他部門から「この指標の定義は何か」「このデータを見てよいか」と問合せが来たとき、一次対応する。

まとめると、データスチュワードはHowに責任を持つ人です。
「決められたことを、どう運用として回すか」の実行が仕事の中心にあります。

違いを一覧表で整理する

両者の違いをまとめると、次の一覧のとおりです。
焦点・責任種類・担当領域・任命される人・権限・主な作業の6点で対比します。

全社に一人、横断責任者を置く｜CDO・CAIO・CIO

部門横断の判断は、部門の合議では止まる

役割を部門ごとに置くと、次の課題として、部門を横断する判断の場面が出てきます。

たとえば、営業部データオーナーと財務部データオーナーの両方が「顧客ID」というデータを扱う場合、その定義や品質基準を統一するかどうかは、どちらか一方の部門長の判断だけでは決められません。

統一しない選択はそれぞれの部門にとっての局所最適につながりますが、統一すると全社の顧客分析が可能になる代わりに、両部門の運用に変更が発生します。

このような判断は、部門オーナーの合議で決めようとすると止まります。
それぞれの部門にとっては優先度が異なり、負担も一致しないからです。
合議で決まらないまま時間が経過し、そのあいだ全社のデータ活用は前に進まなくなります。

こうした横断判断を担うために、全社に一人、横断責任者を置く、というのが次のステップになります。

CDO・CAIO・CIOの位置づけ

経営に近い位置にデータの横断責任者を置く動きは、直近の調査でも数値として現れています。

Gartnerがデータ&アナリティクス責任者を対象に実施した「CDAO Agenda Survey 2025」によれば、CDAO(Chief Data & Analytics Officer)の70%が自社のAI戦略と運用モデルにも責任を持ち、CEOへの直接報告体制も2024年の21%から2025年には36%まで上昇しています（Gartner Newsroom, 2025-05-12）。

データ責任者は、経営会議で意思決定に参加する役員として位置づけられ始めています。

役員クラスの候補として名前が挙がるのは、主に次の3つの役職です。

• CDO(Chief Data Officer、最高データ責任者
  データの整備と統制を全社視点で束ねる役職です。
  事業部門ごとのデータオーナーを横断的にまとめ、全社としてどのデータ領域に優先的に投資するか、部門をまたぐ用語の統一をどう進めるかを判断します。

• CAIO(Chief AI Officer、最高AI責任者
  AIの戦略・活用推進・AIリスク管理を担う役職です。
  生成AIの登場以降、新設される例が増えており、AI利用のガイドライン策定、リスク審査、活用の全社推進を担当します。

• CIO(Chief Information Officer、最高情報責任者
  既存の情報システムの運用と情報インフラを担う役職です。
  データの利用よりも、システム基盤の安定運用に軸足があります。

3者はそれぞれ視点が異なるため、本来は分けて置くのが理想ですが、日本での実装は少し異なります。

CDO Club Japanが2024年度に実施した設置状況調査によれば、日本企業でCDOが在籍する割合は11.7%です。うち、AI推進の主責任者としてはCDOが41%を占め、専任のCAIOを置いている企業は4%にとどまっています。「CDO兼CAIO」型が、日本での実装の主流となっている状況です（CDO Club Japan調査(2024年度)）。

専属ではなく役員クラスの誰か一人を兼任で立てる

専任のCDOを置けるのは大企業に限られます。
設置率11.7%という数字は、日本企業の大半でCDOという役職そのものが存在しないことを意味しています。

ここで大切なのは、名称ではなく機能です。
CIO・CTO・経営企画担当役員のうち誰か一人が、横断責任者の役割を兼任で担うのが現実的な選択になります。

その役員が担うのは、経営会議に月次でデータの状態を持ち込み、部門横断で必要な判断を下す、という機能です。
判断を下す権限があり、経営陣に定期報告する場を持っていれば、役職名がCDOでなくても機能は成立します。

逆に、名称だけCDOを置いても、経営会議に定期の場がなく、部門長への指示権限もないなら、意味はありません。

役割を形骸化させないための4つの仕組み

役割を明文化し、横断責任者を立てても、それだけでは半年後には形だけになりがちです。
異動で担当者が変わり、忙しさで日々のチェックが飛び、経営の関心が薄れると、決めた役割は名目だけが残って動きは止まるという展開が起きます。

形骸化を防ぐには、次の4つの仕組みを組み合わせる必要があります。
責任を「人」ではなく「役職」に紐づける、チェックをツールに寄せる、経営の場でデータの状態を可視化する、そして全部をカレンダーに入れる、の4点です。順に見ていきます。

1. 責任を「人」ではなく「役職」に紐づける

1つ目は、責任者の指名を氏名ではなく役職名で行うことです。

責任者を氏名で指名すると、その人が異動・退職した瞬間に責任者不在の期間が生まれます。
後任が誰かは自動では決まらず、部内で調整会議が開かれるまで空席が続きます。
「営業部データオーナー：山田太郎」と書けば、山田氏の異動と同時にこの記述は無効になります。

役職名で紐づけると、この空席が発生しません。
「営業部データオーナー：営業部部長」と書いておけば、部長が交代した瞬間から自動的に後任にオーナー職が引き継がれます。
人事異動と同じ流れで役割の引き継ぎが発生するため、業務としての引き継ぎ資料の作成も、既存の異動プロセスに組み込みやすくなります。

2. チェックをツールに寄せる

2つ目は、データの日々のチェックを人手ではなくツールに寄せることです。

データスチュワードが毎日目視で品質を見にいくモデルは、業務が忙しくなった瞬間に機能を停止します。
決算期・繁忙期・欠員が出た月には、優先度が下がって後回しになる。
数か月続くと、目視ルールは形式上存続していても、実務では確認されていない状態になります。

まず取り組むのが、データ品質テストです。
dbt tests、Great Expectationsといったツールで、「この項目は空欄にならない」「この指標は前日比±30%以内」のような、決めたルールを自動でチェックします。
ルールから外れたときには即座に通知が飛ぶ設計にできます（dbt tests公式ドキュメント、Great Expectations公式）。
ここは無料または安価に始められるため、最初の一歩として取り組みやすい領域です。

扱うデータや部門が増えてきたら、さらにツールを足していきます。
決めていないルールの異常まで自動で見つけるツールや、用語定義・オーナー・アクセス履歴を1箇所に一覧できるデータカタログ(Alation、Atlanなど)です。
前者があれば、急にデータ量が半減した、更新が停止した、といった見落としがちな異常も拾えます。後者があれば、スチュワードが問合せに答えるとき、定義とオーナーをその場で確認できます。

最初からすべてを揃える必要はありません。
品質テストの自動化を出発点にすれば、スチュワードの仕事は「アラートが鳴ったときの原因調査と修正判断」に絞り込めます。

目視で品質を見にいく作業から解放され、忙しい時期にも仕組みが持続します。

3. 経営の場でデータの状態を可視化する

3つ目は、月次の経営会議でデータの状態を定期的に見る場を作ることです。

データオーナーとデータスチュワードの働きは、経営が見ていない場所では自然に劣後します。
他の営業KPIや財務KPIと並んで経営会議の議題に上がっていれば、劣後しにくくなります。

経営会議で見るのは、データの状態が事業にどう影響しているかです。
他の営業KPIや財務KPIと並べたときに、経営がその場で判断できる粒度に絞ります。

まず、AI活用やデータ活用が止まっている案件です。
データ整備が原因で止まっているプロジェクトが何件あり、どの部門で起きているか。
データ整備の遅れが事業に与えている影響を、経営に見せます。

次に、重点的に進めているデータ整備プロジェクトの進捗です。
半期ごとに設定した整備テーマ(たとえば「顧客IDの全社統一」)が予定どおり進んでいるかを追います。

そして、事業に影響した重大なデータの問題があれば、その報告です。
誤ったデータで意思決定しかけた、顧客に不正確な情報が渡った、といった事象は、件数ではなく個別の事案として経営に共有します。

見るだけで終わらせないためには、議事録に次のアクションが具体的に残ることが必要です。

「営業部データオーナーが月末までに顧客IDの定義案を提示する」「止まっているAI案件について、横断責任者が次回までに優先順位を決める」といったように、次の一手が誰の担当で、いつまでにという形で記録される状態が最低ラインです。

4. 全部、カレンダーに入れる

4つ目は、これまでの3つを定期の予定として全部カレンダーに入れることです。

責任の役職紐付け、ツールでの自動チェック、経営会議での可視化。ここまでの3つを決めても、集まる時間がカレンダーに入っていなければ、忙しさに押されて次第に消えていきます。
「今月は他の議題が多いから来月に」「担当が繁忙期だから見送り」が数回続くと、実務としては存在しない仕組みになります。

月次では、経営会議でのデータ状態レビューと、現場運用のためのスチュワードシップ会議を持ちます。経営会議では前節で挙げた3〜4個の指標を見て、次のアクションを決める。
スチュワードシップ会議では、日々のツールアラートの棚卸しと、部門をまたぐ問合せの整理を行います。

四半期では、データオーナー会議を開きます。
優先順位の見直し、変更承認(定義や分類の変更)、SLAの見直しといった、月次より上位の判断を行う場です。

年次では、データ活用戦略と体制のレビューを行います。
役職への紐付けは現状のままでよいか、使っているツールは適切か、指標の設計は経営判断に貢献しているか。年に一度、大枠を見直します。

参加者が固定され、日時が固定され、議事録が残る。これが動き続けるデータガバナンスの最小条件です。
カレンダーへの登録は、決めた運用が「決めただけで終わるか、実務として動くか」を左右する分岐点になります。

まとめ

AI活用におけるデータガバナンスが進まないのは、責任が誰にも紐づいていないからです。
組織間で情シスと事業部門が投げ合い、部門の中でも個人まで指名されていない、という2段のあいまいさが同時に起きている状態を解決する必要があります。

解くための最初の一手は、役割の明文化です。
決定に責任を持つデータオーナー(事業部門の長・Accountable)と、日々の運用に責任を持つデータスチュワード(現場実務担当・Responsible)を、役割として設計する。
部門ごとの役割だけでは横断判断が止まるため、全社に一人の横断責任者を立てる。
名称ではなく、経営会議に定期の場を持ち、部門横断で判断を下せる権限があることが判断基準になります。

役割を決めるだけでなく、形骸化させない仕組みまで作って初めて、データガバナンスはAI活用を止めない仕組みになります。

本記事がAI活用を止めるデータガバナンス体制を解決するきっかけになると幸いです。