「データはある。でも使えない」
――AIが露わにするデータ基盤の現実

AIに任せる範囲を広げるために、データそのものを整える

はじめに：データはある。でも、AIが使える状態にはなっていない

AIエージェントを業務で使おうとすると、最初にぶつかる壁は、AIの性能ではなく、データであることが多い。

AIに渡すデータの準備が間に合わない。どのシステムのデータを使えばいいか決まらない。社内に同じ情報が複数のシステムにバラバラに入っていて、どれが正しいか分からない。そういった、データに関する問題だ。

Qlik社が2025年に実施したエージェンティックAIの調査によると^*1、AI導入の障壁として最も多く挙げられたのが「データ品質、可用性、アクセス」で、その次がシステム統合の問題だった。AIの制約は、モデルの性能よりも、企業内のデータ基盤とシステムの整備にあるというのが、現場の実感と一致している。

本稿では、なぜこの問題が生まれ、何を整えればよいかを整理する。既存のシステムとAIをどうつなぐかは、次回で扱う予定だ。

データの問題は、AIの前からあった

「データがある」と「AIが使えるデータがある」は、同じではない。

この差を多くの企業がAIを触ってはじめて実感する。ただ、問題はAIが持ち込んだわけではない。

ある調査^*2では、情報システム担当者708人に企業のデータ管理実態を尋ねたところ、企業に導入されているシステムの数は平均23.3個にのぼり、取引先データの連携は66%が手作業に頼っていた。8割超がデータに「重複」や「表記ゆれ」などの品質問題を抱えており、こうしたデータ基盤の整備不足がAI活用時の精度低下につながっていると87.3%が実感しているという。

23個のシステムに分散したデータは、それぞれの業務のために作られた、というのが背景にある。販売管理、会計、CRM、グループウェア、それぞれが独立していて、互いをつなぐ設計にはなっていない。いわゆる「データサイロ」の状態だ。これはAIが登場する前から業務の非効率の原因だったが、担当者が手作業でつなぐことで何とか回っていた。

AIはその手作業を前提にしない。システムをまたいでデータを参照し、判断に使うためには、あらかじめデータが整理されていることが必要になる。AIが来て、問題が生まれたのではなく、AIが来て、問題が見えるようになった。

「DWH」や「データレイク」だけでは対応しにくくなる場面

AIに使えるデータ基盤の話をするとき、既存のデータウェアハウス（DWH）やデータレイクとの関係を確認しておくと、何を整えるべきかが見えやすくなる。既存のDWHやデータレイクをそのままAIに接続できているケースも多い。ただし、扱うデータの種類や用途が広がるにつれ、対応しにくくなる場面が出てくる。

DWH（データウェアハウス） は、高い信頼性とパフォーマンスを持つ分析用のデータベースだ。過去からの定番で、財務・売上などの構造化データを扱い、BIツールに繋ぐ用途で導入されてきた。ただし、比較的コストが高く、非構造化データ（テキスト、ログ、音声）は扱いにくい。

データレイク は、あらゆるデータを低コストで大量に蓄積する場所だ。構造化・非構造化を問わず入れられる。しかし、管理が行き届かないと、データの品質が担保されず、「何があるかは分からないが、とにかく溜まっている」という状態（データスワンプ）になりやすい。

データレイクハウス は、この二つの弱点を補う設計だ。データレイクのようにコストを抑えながら大量・多種のデータを扱えて、DWHのような信頼性とパフォーマンスを両立する。BIから機械学習、生成AIまで、同じ基盤で扱える点が特徴になっている。

AIエージェントが大量のデータを参照し、学習・推論・記録を繰り返す使い方では、構造化データだけでなく、ドキュメント・会話ログ・画像などの非構造化データも扱う必要が生まれることがある。その場合、既存のDWHだけでは対応しにくくなる。どの構成が合うかは、扱うデータの種類と業務の目的によって変わる。

ARCHITECTURE実際に使われるアーキテクチャ：メダリオン

データレイクハウスを設計するとき、よく使われる構造が「メダリオンアーキテクチャ」だ。データを3つの層に分けて整備する。

ブロンズ層（生データ）：各システムからデータをそのまま取り込む。変換や加工は行わない。

シルバー層（整形済みデータ）：重複を除去し、表記を統一し、他のシステムのデータと突き合わせられる状態に整える。AIに参照させるデータの大半はこの層になる。

ゴールド層（目的別マート）：分析・レポート・AIの用途に合わせて、使いやすい形にまとめた出力層。ダッシュボードや判断用のデータセットがここに置かれる。

この3層の分離は、「生のデータを保持しながら、目的に応じた品質のデータを提供する」ための設計だ。新しい業務でAIを使いたいとき、ブロンズ層のデータを再利用しながらシルバー層の整備を広げることで、既存の環境を壊さずに段階的に進められる。

AIに使えるデータがないとき、何が起きているか

DWHでも、データレイクでも、「データがある」はずの企業が本番でつまずく。その原因は、主に次の3つだ。

1. システムをまたいで情報がつながっていない

同じ取引先が、CRMには「株式会社〇〇」、会計システムには「㈱〇〇」、基幹システムには「〇〇（株）」と入っているような状態だ。人間が単体で読む分には同一企業と分かるが、AIが複数のシステムをまたいでデータを突き合わせると、名寄せの精度が落ちる。「同じ取引先の最新情報を参照する」「複数システムの購入履歴を統合する」といった処理で、誤ったマッチングや欠損が起きやすくなる。また、「この顧客が最後に何を購入したか」を確認するためには、複数のシステムをまたがなければならないが、その連携設計がない。

2. データの品質が担保されていない

値が欠けている、古い、単位がバラバラ、表記が統一されていない。個人が使う分には許容できる揺れが、AIが大量のデータを参照する場面では誤判断の原因になる。特に、過去のデータをAIの学習や評価に使う場合、品質の低いデータは「学習させてはいけないデータ」になりうる。

3. 履歴と来歴が残っていない

「なぜそのデータになったのか」という経緯が記録されていない。更新のたびに上書きされ、過去の状態が残らない設計のシステムが多い。また、「このデータはどのシステムから、どの処理を経て今の値になったか」（来歴・リネージ）が追えないと、AIが出した判断の根拠を確認できない。問題が起きたとき、原因の特定が困難になる。

AIが使えるデータ基盤を、段階的に整える

全社のデータを、一度に整える必要はない。一つの業務から始めて、段階的に整えていく。

PROCESS 1手順1：現状をアセスメントする

どのシステムに、どんなデータが、どの状態で入っているかを把握する。AIに使わせたい業務を一つ決め、そこに必要なデータがどこにあるかを確認する。この段階では、既存システムを変える必要はない。現状のデータのフローと品質の問題を可視化することがゴールだ。まずは財務・販売・顧客のどの領域から始めるかを決める。

PROCESS 2手順2：基盤の方向を決める

現状のアセスメントをもとに、データ基盤のアーキテクチャ方針を決める。既存のDWHやデータレイクを活かすか、Databricksのようなデータレイクハウスのプラットフォームをあらたに導入するか。Salesforce Data 360（旧Data Cloud）のようにデータ統合とCRM・AIエージェントを一体で扱う選択肢もあれば、AWSのサービスを組み合わせる方法もある。どの組み合わせが最もコストと運用の観点で合うかは、現状のシステム構成と目的によって変わる。どの基盤を選ぶかより、「既存システムを止めずに、段階的に整えられるか」が判断基準になる。

PROCESS 3手順3：ユースケースを一つ絞り、整えて検証する

全社のデータを一度に整えようとしない。効果が見えやすく、データの範囲が限定できる一つのユースケースに絞り、ブロンズ→シルバーの整備とAIへの接続を検証する。この段階で品質の問題が具体的に見えてくる。AIが参照したデータと、AIの出力の関係を記録する設計も、この段階から組み込む。

PROCESS 4手順4：ガバナンスを設計し、範囲を広げる

検証で確認した内容をもとに、データへのアクセス制御と品質管理の仕組みを設計する。その後、同じ設計を別のユースケースや部門へ広げていく。AIに任せる業務が増えるほど、統治する中間層（誰が・どのデータを・どう使えるかを管理する仕組み）の整備が重要になる。

ガバナンスはデータ基盤の設計と一体で考える

AIエージェントが業務で動くとき、「このデータを参照してよいか」の判断は、あらかじめデータに設定しておく必要がある。これは、AIエージェントに何を実行させるかの権限設計（第1回で触れたエージェント側のガバナンス）とは別の層の話だ。

データ側のガバナンスとして必要になるのは、次のような設計だ。

データに属性を付与する：このデータは、どの部門のもので、どの目的で収集され、誰まで参照できるか。機密区分と利用目的を設定する。

来歴（リネージ）を管理する：このデータは、どのシステムから、どの処理を経て、今の値になったか。来歴が追えると、AIの判断根拠を確認でき、問題が起きたときの原因特定が早くなる。

品質を継続的に監視する：データの欠損・重複・鮮度などを定期的に確認し、AIが参照するデータの品質を維持する仕組みを持つ。

こうした管理を一元化する仕組みを「データカタログ」と呼ぶ。データの場所・権限・品質・来歴を同じ場所で管理し、誰がどのデータを使えるかを可視化する仕組みだ。使うプラットフォームや製品を問わず、こうした層を整えることが、AIを組織的に使うための前提になる。

「データを部署をまたいで検索できるようにしたところ、質問した人の権限外の情報が回答に含まれた」というケースは、この設計がなかったために起こる。技術的に参照できるかどうかではなく、使ってよいかどうかの管理がデータ基盤の設計段階で必要になる。

AIが使えるデータ基盤は、経営判断の基盤でもある

データを整えることは、AIのためだけではない。

判断に使えるデータがある、ということは、経営層が現場の実態を把握しやすくなることでもある。営業・製造・財務のデータがバラバラのまま存在していても、経営の判断には使えない。それらをつなぎ、一貫した形で参照できる状態にすることが、データに基づく意思決定の出発点だ。

AIは、その状態を「自動的に活用できる仕組み」として機能する。逆に言えば、データが整っていない組織でAIを使うと、間違ったデータを大量に高速で処理する仕組みができあがる。精度が低いまま大量に判断を出し続けると、問題が気づかれにくくなる。

長年「後でやろう」と先送りにされてきたデータの問題が、AIを使おうとしたことで優先順位が上がる。その機会を、AIのためだけでなく、経営判断の精度を上げるための投資として位置づけることができれば、取り組みの意義が広がる。データ基盤の整備は、ゴールではなく、AIを組織の業務に根付かせるための継続的なプロセスだ。

着手前の自己確認

• データの所在確認

  AIに使わせたい業務で必要なデータが、どのシステムにあるかを把握しているか

• 整合性の確認手段

  複数のシステムに同じ情報が入っていて、どれが正しいかを確認する手段があるか

• 来歴の記録

  データに「いつ更新されたか」「どのシステムから来たか」の来歴が残っているか

• アクセス制御

  AIが参照できるデータと、参照してよいデータの線引き（アクセス制御・機密区分）ができているか

• データ品質の把握

  データの品質問題（重複、欠損、表記ゆれ）のうち、AI判断に影響するものを把握しているか

• 基盤方針の決定

  既存の基盤（DWH・データレイク）の延長で整備するか、レイクハウスを新たに導入するかの方針が決まっているか

まとめ

AIを本番で動かそうとすると、多くの場合、最初にぶつかるのはデータの問題だ。その問題はAIが持ち込んだわけではなく、ずっとあったものがAIによって表に出る。

AIに使わせたい業務のデータから、段階的に整える。ブロンズ（生データ）→シルバー（整形・統合）→ゴールド（目的別）という3層で管理し、AIが参照できる品質と来歴が担保されたデータを整備する。アクセス制御・品質・来歴を一元管理するガバナンスの仕組みを、データ基盤と同時に設計する。この順序で進めることで、AIが成果につながる環境をつくっていける。次回は、この基盤に、基幹システムなどの既存システムを止めずにどうつなぐかを扱う予定だ。

ウフルは、Databricks・Salesforce Data 360（旧Data Cloud）・AWSなどを活用したデータ基盤の構築から、データに基づく意思決定の設計、AIエージェントによる業務の自動化・高度化まで、一貫して支援しています。自社のデータがどこにあり、何が使えて、何が整っていないかを確認するところから、一緒に考えましょう。