はじめに：AI導入が進むほど「データ負債」が経営を止める
生成AIや予測AIが当たり前になり、「AIを使って成果を出す」こと自体は珍しくなくなりました。一方で、AI活用が進むほど、組織は別の壁にぶつかります。モデルの精度ではなく、データの品質・意味・流通・責任範囲が曖昧で、施策が再現できず、改善が回らない。つまり“AI活用の失速”の多くは、モデルの問題ではなく、データの問題として現れます。
ここで重要になるのが Data-centric AI という考え方です。これは「モデルのアルゴリズムを改良する前に、データの品質と構造を体系的に改善する」「AIにとって意味のあるデータの作り方・保ち方・使い回し方を設計する」という思想です。AI-readyなデータ分析基盤を作るには、どのLLM/モデルを採用するかよりも先に、データの定義・品質・運用（監視/責任分界）を整えるというData-centric AIの思想を土台に置く必要があります。（※ここで言う「モデル」はLLMに限らず、予測モデル・レコメンド・スコアリング・ルールベースを含む“意思決定に使う推論器”全般を指します。）
そしてもう一つ、見落とされがちなポイントがあります。Data-centric AIは、特定の職種だけの話ではありません。CDO（データ責任者）、データスチュワード、データエンジニア、データアナリスト、データサイエンティストが、それぞれ自分の領域だけで閉じていると、AI-readyには到達しません。AI時代は、単体スキルが急速にコモディティ化し、仕事が置き換えられやすくなる局面も増えます。だからこそ、データに関するマルチスキル（広さ×深さ）が、組織にも個人にも求められます。
本記事では、Data-centric AIを軸に「AI-readyなデータ分析基盤」と「データ職能の再設計」を、実務視点で整理します。
1. Data-centric AIとは何か：モデル中心からデータ中心へ
AI活用というと、多くの組織が「どのモデルを使うか」「どのアルゴリズムが良いか」に意識を奪われます。しかし現場では、成果を左右する“ボトルネック”は別の場所にあります。
同じ指標名なのに部署ごとに定義が違う（売上、CV、リード、粗利…）
欠損や重複が多く、前処理が毎回手作業になる
いつ・誰が・何を根拠にデータを直したのか分からない
学習データと本番データの分布がずれて、精度が崩れる
「正解ラベル」が曖昧で、評価が揺れる（施策の良し悪しが判定できない）
これらはモデルの問題ではなく、データの設計・統制・運用の問題です。Data-centric AIは、ここに正面から向き合います。具体的には、次のような問いを優先します。
そのデータは、意思決定に必要な“意味”が揃っているか（定義・粒度・単位）
品質は継続的に担保されているか（欠損、外れ値、遅延、重複、整合）
変化を検知できるか（ドリフト、仕様変更、計測変更）
使い回せる形になっているか（データプロダクト化、再利用設計）
責任境界は明確か（誰が定義し、誰が修正し、誰が承認するか）
「AI-ready」を本気で目指すなら、データを“集める”から“育てる”へ。データを“置く”から“運用する”へ。発想を変える必要があります。
2. AI-readyなデータ分析基盤とは：単なるDWH/BI整備では足りない
AI-readyな基盤とは、DWHやBIがある状態ではありません。重要なのは、AIシステムが継続的にビジネス価値を創出するために、データの収集・管理・活用・廃棄までのライフサイクル全体が設計・運用されている状態を指します。目指す姿を分解すると、概ね以下の要素に整理できます。
2-1. 意味が揃っている（Semantics）
データは数値だけでは価値になりません。意味が揃って初めて、組織で共有可能な資産になります。
KPI定義（何をもって達成（たとえば、「注文完了」など）とするか、キャンセルはどう扱うか）
イベント設計（計測の粒度、発火条件、命名規約）
参照系マスタ（顧客、商品、チャネル、施策、組織）
2-2. 品質が測れて、改善できる（Quality & Observability）
AIは入力に敏感です。品質が「気合」だと、必ず破綻します。
データ品質指標（欠損率、重複率、遅延、範囲チェック、整合性）
監視とアラート（異常検知、急変、ドリフト兆候）
変更管理（スキーマ変更、計測変更、ETL変更の影響把握）
2-3. 出自と責任が追える（Lineage & Governance）
「この数字はどこから来たのか」が追えない組織では、AI以前に意思決定が揺らぎます。
データリネージ（上流〜下流の流れ、変換の履歴）
オーナーシップ（定義責任、品質責任、アクセス責任）
承認プロセス（定義変更・計測変更・KPI変更）
2-4. 使い回せる（Data Product / Feature Reuse）
AI-readyの本質は「再現性」と「速度」です。毎回ゼロから作る文化だと、スケールしません。
データプロダクト化（利用者視点の提供、SLA、仕様）
特徴量の再利用（同じ特徴量を各チームが別々に作らない）
標準化（命名規約、テーブル設計、メタデータ）
2-5. ビジネス実装まで繋がる（Activation）
分析で終わると、AI-readyではありません。
配信・施策への接続（CRM、MA、広告、プロダクト内施策）
フィードバックループ（施策結果が再び学習データへ戻る）
効果測定の標準化（実験設計、因果推論の基礎整備）
AI-readyな基盤は、「データが正しい」だけでなく、「データが回る」状態です。そしてこの“回る”には、職能の連携設計が不可欠になります。
2-6. データガバナンスが果たすべき役割
ガバナンスは“ブレーキ”ではなく、AI活用をスケールさせるためのハンドルです。
AI-readyな基盤では、データの定義・品質・アクセス・変更が「人の記憶」ではなく「仕組み」で管理されている必要があります。具体的には、①指標/イベント定義の登録と変更管理、②品質監視とSLA、③データ分類と権限・監査、④計測/ETL変更のリリース手順が最低限のセットになります。ここが曖昧なままAI活用を進めると、モデル以前に“意思決定の再現性”が崩れます。
3. データ職能の再設計：役割は分業ではなく“協調設計”へ
ここからが本題です。AI時代のデータ組織は、役割分担だけを精緻化してもうまくいきません。なぜなら、価値創出は役割の境界をまたいで起きるからです。したがって、必要なのは「分業」ではなく、協調前提のオペレーティングモデルです。
以下、主要ロールを整理します（会社によって名称は異なります）。
3-1. 最高データ責任者「CDO （Chief Data Officer）」：全体最適と“意思決定の再現性”を担う
CDO （Chief Data Officer）は、単なるIT責任者でも分析部門長でもありません。ミッションは端的に言えば、データで意思決定できる会社にすることです。AI活用が前提になるほど、ここは「旗振り」ではなく「設計者」になります。
主な責務は次の通りです。
データ戦略：何を資産化し、どこで差別化するか（収益・競争優位に直結）
ガバナンス：定義・品質・責任のルールを設計し、形骸化させない
投資判断：基盤投資の優先順位を決める（短期ROIと長期負債のバランス）
組織設計：職能間の摩擦を減らし、価値創出の流れを作る
経営言語への翻訳：データ/AIの話を、経営KPI・リスク・投資対効果に落とす
このロールが自分の領域だけで完結してしまうと、「基盤を作って終わり」になりがちです。AI-readyを実現するには、データの意味（ビジネス）×流通（エンジニアリング）×価値化（分析/DS）のすべてを俯瞰できる必要があります。
3-2. データスチュワード：定義と品質の“運用者”として組織を支える
データスチュワードは、データガバナンスの現場実装を担います。誤解されがちですが、これは“監視役”ではなく、現場を止めずに整える仕組みを回す人です。
KPI/データ定義の整備と維持（辞書、用語、計測ルール）
データ品質のルール化・監視・改善（誰がいつ直すかまで含む）
メタデータ管理（利用者が迷わない、誤用しない状態を作る）
利用部門との調整（定義変更の合意形成、影響範囲の説明）
ここで重要なのは、スチュワードが「データの正しさ」だけを追うと、現場から嫌われることです。逆に「現場の都合」だけを優先すると、定義が崩れてAIが死にます。だからこそ、ビジネス成果とデータ統制を両立させる折衝力が求められます。
データガバナンスは「ルールを作ること」ではなく、「ルールが守られる状態を運用で作ること」です。そのためには、責任者の任命だけでなく、定義・品質・変更管理に関する意思決定権限（Decision Rights）を業務プロセスに埋め込む必要があります。権限がないスチュワードは“お願い係”になり、結局、定義ブレと品質事故が増えてAI活用が失速します。
この失速を止め、加速させるのがデータスチュワードの役割で、非常に重要な役割です。（後述ブロックで詳しく解説）
3-3. データエンジニア：パイプラインだけでなく“信頼できる流通”を設計する
データエンジニアは、ETLやDWH構築の人、で終わりません。AI-ready基盤では、データは“作って終わり”ではなく“運用して価値を出す”ものです。したがって責務も広がります。
計測〜収集〜加工〜提供の設計（再利用前提、保守前提）
データ品質・監視の仕込み（異常検知、遅延検知、スキーマ検知）
コスト最適化（クエリ設計、ストレージ設計、運用効率）
セキュリティ/権限設計（最小権限、個人情報、監査ログ）
下流の分析/AIが使いやすい形へのモデリング（粒度、履歴、キー設計）
AI時代に仕事が奪われやすいのは、単にツールを触れるだけの領域です。逆に、価値が残るのは「何をどう流通させると意思決定が速くなるか」「品質をどう運用設計に落とすか」といった、システム×業務×統制の接点です。ここは生成AIでも置き換えにくい“設計判断”が中心になります。
3-4. データアナリスト：可視化ではなく“意思決定の型”を作る
データアナリストはBIやダッシュボードの人、で終わると危険です。AIが当たり前になると、可視化や集計は自動化されやすい。一方で価値が残るのは、問いの設計・解釈・因果の見立てです。
KPIツリーと意思決定の設計（何を見て、どう動くか）
分析の再現性（指標定義、分析手順、データ利用の標準化）
実験・検証（A/B、準実験、施策の効果検証設計）
“解釈”の品質管理（誤読・過信・都合の良い解釈を防ぐ）
さらにAI-readyの世界では、アナリストはDS/エンジニア/スチュワードと協働し、「分析が回る仕組み」そのものに責任を持つ必要があります。例えば、アナリストが定義を理解せずに数字を出せば、スチュワードが困り、エンジニアが後追いで修正し、現場は混乱します。逆に、アナリストが定義と品質に踏み込み、流通設計にも関与できれば、組織は一気に強くなります。
3-5. データサイエンティスト：モデルだけでなく“データ設計と業務実装”まで見る
データサイエンティストも、モデル構築だけだと置き換えが進みやすい領域に入っていきます。AI時代のDSに求められるのは、次の3点です。
データの仕様を決める力（ラベル設計、学習データの定義、偏りの制御）
本番運用を設計する力（ドリフト、再学習、監視、説明可能性）
業務に埋め込む力（意思決定フロー、運用負荷、例外処理まで含める）
Data-centric AIの観点では、DSは「精度を上げる」だけではなく、「精度が維持される仕組み」を作る役割になります。これはエンジニアリングやガバナンスに踏み込むことを意味します。つまりDSも、幅広い理解（基盤、統制、業務）が必須です。
ここまで主要ロールを整理しましたが、Data-centric AIで成果が続くかどうかは、「定義・品質・変更」を“運用として回し続けられるか”にかかっています。
次章では、その運用の中心となるデータスチュワードに焦点を当て、必要なスキルとガバナンスの実効性（権限設計）まで具体化します。
4. Data-centric AIの主役はデータスチュワードである
4-1. なぜデータスチュワードが“主役”になるのか
Data-centric AIは「モデルのアルゴリズムを改良する前に、データの品質と構造を体系的に改善する」という発想です。AIの成果は、学習データ・評価データ・本番データの定義の一貫性と品質の維持で決まります。つまり、AIが価値を出し続けるには「データが継続的に信頼できる」状態を運用で作る必要があります。
この“運用で作る”を担う中核がデータスチュワードです。データスチュワードは単にデータを守る人ではなく、データの意味（定義）・品質（Quality）・統制（Governance）・利活用（Adoption）を同時に回して、組織がデータを「使い続けられる」状態を作る役割です。実務的には、貴サイトの既存記事でも触れられている通り、データスチュワードの主要役割は データ品質の維持／データ利用の促進／データガバナンスの推進の3つに集約できます。
AI時代にこの役割が主役になる理由はシンプルで、AIはデータの“意味と品質”が崩れた瞬間に壊れるからです。
・同じ「CV」でも定義がズレる
・イベント計測が変更されて気づかない
・ラベルが曖昧で評価が揺れる
・分布が変わっても検知できない
こうした“データ起因の破綻”を、組織の仕組みとして予防し、検知し、修復し、学習へ戻す。これがData-centric AIの運用であり、データスチュワードの主戦場です。
データスチュワードの役割・導入ステップは、別記事で詳しく整理しています
データスチュワードの重要性とは？データガバナンス成功の鍵を徹底解説
4-2. データスチュワードに必要なスキルセット（技術×ビジネス×推進）
データスチュワードに求められるのは「広さ」です。単体スキルだけだとAI時代に代替されやすい一方、スチュワードは“境界”に立つため、複数領域の理解を接続できる人が強いです。
（A）データの“意味”を揃える技術（Semantics）
KPI・指標の定義設計（何をもって売上／CV／解約／アクティブとするか）
イベント設計と命名規約（発火条件・粒度・プロパティ定義）
データモデリングの基礎（粒度、主キー、履歴、SCD、参照整合）
マスタ/参照系の統制（顧客・商品・施策・組織などの定義と結合ルール）
（B）品質を“測って直す”技術（Quality / Observability）
品質指標の設計（欠損、重複、遅延、範囲、整合性、異常値）
品質監視の運用（アラート設計、しきい値、一次対応・恒久対応の切り分け）
変更検知（計測変更、スキーマ変更、ETL変更、データドリフト兆候）
「どこで壊れたか」を追う力（リネージ／データフローの理解）
（C）ガバナンスとリスクの知識（Governance / Risk）
データ分類（機密・個人情報・社外秘など）と取り扱いルール
アクセス権限設計の考え方（最小権限、監査ログ、承認フロー）
保持/削除・目的外利用防止・委託先管理などの基本
インシデント時の対応ルール（誰が止め、誰が通知し、誰が復旧判断するか）
（D）ビジネスセンス（意思決定に効く“優先順位付け”）
「定義の厳密さ」と「現場のスピード」のバランス感覚
投資対効果の判断（全部整えるのではなく“効くところ”から整える）
利用者体験（探しやすい、迷わない、誤用しない）への感度
“データを作る”ではなく“データで成果を出す”視点（施策接続）
（E）推進力（合意形成と摩擦処理）
会議体の運営（データ定義変更、計測変更、品質改善の意思決定）
RACIを前提にした調整（誰が決め、誰が実装し、誰が使うか）
反発やサボタージュへの対処（「正しさ」だけで押さない）
ドキュメンテーション（データ辞書、変更履歴、リリースノート）
4-3. データガバナンスを“足りないまま”にしないための要点
データガバナンスは、規程を作って終わりではありません。AI-ready基盤におけるガバナンスは、スケールするための運用システムです。最低限、次の4つが揃うと一気に強くなります。
定義を決める仕組み（定義の登録・変更・周知・影響範囲の明示）
品質を維持する仕組み（監視、SLA、異常時の一次/恒久対応の分離）
アクセスとリスクを管理する仕組み（分類、権限、監査、目的外利用の防止）
変更を安全に通す仕組み（計測/スキーマ/ETL変更の“ゲート”とリリース手順）
そして、これらを“実際に回す”のがデータスチュワードであり、ここが回らない組織はData-centric AIの前提を満たしません。
4-4. ガバナンス施策を実際の業務改善に結びつけるには「権限（Decision Rights）」が必要
データガバナンスが形骸化する最大の理由は、責任だけがあり権限がないことです。データスチュワードは「お願い役」になると負けます。最低限、次の権限設計が必要です（全社でなくても、まずは対象ドメイン/対象KPIからで十分です）。
定義ゲート権限：KPI/イベント定義の新設・変更に“承認ステップ”として関与できる
品質ゲート権限：重大な品質劣化時に、データ公開の一時停止や注意喚起を出せる
計測変更の事前通知権限：プロダクト/計測側が勝手に変えるのを防ぐ（変更管理に組み込む）
アクセス共同承認：機微データのアクセス付与に、スチュワード（またはデータオーナー）が関与できる
エスカレーション権限：合意形成が詰まった時に、上位会議体（データ評議会等）へ上げられる
ポイントは、スチュワードを“統制の番人”にすることではありません。安全に速く回すための権限です。現場が速く動くほど、計測変更・定義ブレ・品質事故が起きます。だからこそ、権限を埋め込んだ運用が必要になります。
重要なのは、権限を「肩書き」ではなく「手続き」に落とすことです。例えば、定義変更・計測変更は“変更申請（Change Request）”として起票し、影響範囲（下流レポート／モデル／施策）とリリース日を明記したうえで承認する。品質劣化時は“暫定データ”としてラベル付けし、利用者に周知しつつ恒久対応を切る。
こうした手続きがあると、スチュワードのDecision Rightsが「現場を止める権力」ではなく、「現場を止めずに安全に進める仕組み」になります。
4-5. データスチュワードを中心にした最小ガバナンス体制（現実解）
大掛かりな全社ガバナンスを最初から狙うと失速しがちです。現実的には次の“最小セット”が強いです。
データオーナー（業務側）：定義の最終責任（ビジネス的に何が正しいか）
データスチュワード（横断）：定義・品質・変更管理の運用責任（回す人）
データカストディアン（IT/DE）：実装責任（パイプライン、権限、監視の仕組み）
データ評議会（Executive sponsor含む）：詰まりの解決、優先順位の裁定
この形にすると、「誰が決めるのか」「誰が直すのか」「誰が止めるのか」が明確になり、Data-centric AIの運用が回り始めます。
私自身、実務経験からデータスチュワードの存在なくしてAI-readyなデータ基盤を作ることはできないと考えており、下記のページでも詳しく書いています。
データスチュワードの重要性とは？データガバナンス成功の鍵を徹底解説
5. なぜ“マルチスキル”が必須になるのか：AI時代の職能は境界で価値が出る
ここまで見てきた通り、AI-readyな組織では、価値の発生地点が「職能の境界」にあります。
定義（スチュワード）×活用（アナリスト/現場）
流通（エンジニア）×学習（DS）
経営判断（Executive）×現場運用（全員）
境界を理解せずに自分の領域だけを最適化すると、全体が遅くなります。逆に、境界を跨いで会話できる人が増えるほど、組織の速度は上がります。
個人のキャリア観点でも同じです。単体スキルがAIで代替されやすい一方、価値が残るのは、次のような能力です。
目的から逆算して、必要なデータ仕様を定める力
データ品質と業務影響を同時に扱う力
合意形成（定義変更、KPI変更、計測変更）を進める力
リスク（個人情報、倫理、バイアス、監査）を踏まえた設計力
これらは「広さ」がないと成立しません。AI時代のデータ職能は、T字型を超えて、π（パイ）字型（複数の深さ）や、状況に応じて伸縮できる“柔らかいスキルセット”が武器になります。
6. 実装の進め方：AI-readyへ向けた現実的ロードマップ
最後に、構想倒れを防ぐための進め方を整理します。ポイントは「全部を一気にやらない」ことです。Data-centric AIは壮大に見えますが、始め方はシンプルです。
Step1：意思決定を1つ選ぶ（ユースケース固定）
まずは「どの意思決定をAI-readyにするか」を決めます。例えばマーケなら、
どの顧客に、いつ、何を出すか（CRM/リテンション）
どのチャネルに、どの予算配分をするか（広告最適化）
どのLP/導線が効いているか（実験・改善）
Step2：その意思決定に必要な“定義”を固める
KPI、イベント、顧客定義、施策定義を固めます。ここでスチュワードとアナリストが主導し、Executiveが後ろ盾になります。
Step3：品質を測り、監視する（運用の最小セット）
欠損・遅延・重複・範囲チェックなど、最低限の品質指標を置きます。エンジニアが仕組みにし、スチュワードが運用設計します。
Step4：使い回しできる形にする（データプロダクト化）
“そのユースケースのためのデータ”から、“複数用途に転用できるデータ”へ。テーブル設計、命名規約、メタデータ整備を進めます。
Step5：AI/分析を施策へ接続し、フィードバックを閉じる
モデルや分析結果が施策に反映され、結果がデータに戻る。ここが閉じると、AI-readyは一気に現実になります。
おわりに：Data-centric AIは「技術論」ではなく「経営の設計図」
AI-readyなデータ分析基盤を作るうえで、Data-centric AIは単なるトレンド用語ではありません。むしろ、データを中心に、組織の意思決定と運用を再設計するための経営思想です。
そして、その実現には「誰か一人の天才」ではなく、ロールごとの責任設計と、境界を跨ぐマルチスキルが必要になります。Executiveが方向性と合意形成を担保し、スチュワードが定義と品質を運用し、エンジニアが流通を設計し、アナリストが意思決定の型を作り、DSが学習と実装を成立させる。これらが一本の線で繋がったとき、AIは“単発のPoC”から“継続的な競争力”へ変わります。
AI時代は、オープンソースモデルの普及により、モデル性能の差別化が困難になった時代です。だからこそ、最後に差を作るのはデータの設計と運用、そしてそれを回せる組織能力です。Data-centric AIから始めることは、その最短ルートになります。
よくある質問（FAQ）
Q1. Data-centric AIとModel-centric AIの違いは？
A. Model-centric AIは固定データセットに対してモデルを最適化する従来型アプローチ。Data-centric AIはモデルを固定してデータ品質を体系的に改善する新しいアプローチです。
Q2. データスチュワードは何人必要？
A. 組織規模やデータドメインによりますが、まず1つのユースケースに1名配置し、スモールスタートが推奨されます。
Q3. 中小企業でもData-centric AIは導入可能？
A. 可能です。むしろデータ量が少ない中小企業こそ、高品質なデータで効果を出しやすいとAndrew Ngは指摘しています。
参考文献リスト
Data-centric AI関連
Landing AI – Data-Centric AI公式サイト
https://landing.ai/data-centric-ai
Andrew Ng氏の会社によるData-centric AIの定義と実践例MIT Sloan Management Review (2021)
“Why it’s time for ‘data-centric artificial intelligence'”
https://mitsloan.mit.edu/ideas-made-to-matter/why-its-time-data-centric-artificial-intelligence
Andrew Ng氏へのインタビュー。Data-centric AIの概念と必要性を解説MIT CSAIL – Introduction to Data-Centric AI (2024)
https://dcai.csail.mit.edu/
世界初のData-centric AIコース。カリキュラムと資料が公開されているData-centric AI Resource Hub
https://datacentricai.org/
Data-centric AIの公式リソースサイト
AI/MLプロジェクトの失敗率関連
Forbes (2025年10月)
“Why 95% Of AI Projects Fail And How Better Data Can Change That”
https://www.forbes.com/sites/garydrenik/2025/10/15/why-95-of-ai-projects-fail-and-how-better-data-can-change-that/
MIT報告に基づく95%失敗率の分析。Gartnerのコスト推定も引用RAND Corporation (2024)
“The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed”
https://www.rand.org/pubs/research_reports/RRA2680-1.html
65人のデータサイエンティストへのインタビューに基づく研究。5大失敗要因を特定Qlik Research
“Data Quality is Not Being Prioritized on AI Projects”
https://www.qlik.com/us/news/company/press-room/press-releases/data-quality-is-not-being-prioritized-on-ai-projects
企業の81%がAIデータ品質に苦戦しているという調査結果
データガバナンス・データスチュワード関連
Google Cloud – What is Data Governance?
https://cloud.google.com/learn/what-is-data-governance?hl=ja
データガバナンスとデータスチュワードの定義Talend – データガバナンスとは
https://www.talend.com/jp/resources/what-is-data-governance/
日本語でのデータガバナンスとデータスチュワードの関係解説IBM – Data and AI governance: A complementary duo
https://www.ibm.com/think/insights/data-ai-governance-complementary-duo-enterprise-success
データガバナンスとAIガバナンスの相補関係
学術文献
Whang, S.E., et al. (2023)
“Data collection and quality challenges in deep learning: A data-centric AI perspective”
The VLDB Journal (引用数：792)
https://link.springer.com/article/10.1007/s00778-022-00775-9Zha, D., et al. (2025)
“Data-centric artificial intelligence: A survey”
ACM Computing Surveys (引用数：538)
https://dl.acm.org/doi/abs/10.1145/3711118Rosenbaum, S. (2010)
“Data governance and stewardship: designing data stewardship entities”
Health Services Research (引用数：323)
https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1475-6773.2010.01140.x
コメント