AIが使えるデータ基盤の作り方｜構造化データを整える4つの定石

AI時代に必要なデータの意義と知識を紹介する連載、なぜAIの話は、いつも「データ」の話になるのか。

前回の第2回では、データが整っていないとAIが実際どう困るのかを、9つの失敗パターンとして見てきました。

前回の記事：AIで成果を出すためのデータ整理｜ただ集める・ただ整えるでは通用しない

第3回から第6回では、9つの失敗パターンに対してのそれぞれの打ち手を紹介します。

本記事で扱うのは、9つの失敗パターンのうち「データそのものが、AIに使える状態か」という第1カテゴリ、その中でも売上・顧客数・在庫といった表形式の数値データ——いわゆる構造化データの整え方です。

「営業はSalesforce、経理は会計ソフト、ECはShopify、問い合わせはZendesk——このバラバラな状態を、どうすればいいのか」。あるいは、「データ基盤を作ると言われても、何にいくらかかって、誰がやるのか、見当もつかない」。そんな課題を抱えている企業が取るべき対策になります。

データ整備は、闇雲に手をつけるものではありません。
実は定石があり、自社が4つの課題のどこに該当するかを見極めれば、打ち手と優先順位はおのずと決まります。

打ち手は4つ。
バラバラのデータを集める「データ統合」、言葉の意味を揃える「セマンティックレイヤー」、中身の正確さと新しさを保つ「データ品質管理」、過去を残す「履歴設計」。

この4つを、それぞれ「何をするのか」「なぜ必要か」「社内で決めることと外注できることの切り分け」という並びで見ていきます。

データ統合——バラバラのシステムを一箇所に集める

最初の打ち手は、第2回で「いちばん多くの会社に当てはまる」とお話ししたサイロ化、つまりデータの分断への打ち手です。

多くの会社では、営業はSalesforce、経理は会計ソフト、ECはShopify、問い合わせはZendesk、というように、部署ごとにデータが別々のシステムに入っています。
一つひとつは正しい選択でも、それらは互いに連携していません。(出典: What Are Data Silos? — IBM)。

たとえば「ある顧客が、何を買って、いくら払って、何回問い合わせてきたか」を知りたくても、いまは3つのシステムを個別に開いて、人が手作業で突き合わせるしかありません。
この状態でAIに「この顧客の全体像は?」と尋ねても、AIはシステムをまたいで情報を見ることができませんから、どこか一つのシステムの中だけを見た、断片的な答えしか返せないのです。

ここでの打ち手が、データ統合です。
やることはシンプルで、各業務システムからデータを抜き出して、1箇所に集めます。この「集める先」のことを、DWH（データウェアハウス）と呼びます。
社内のあらゆるデータを横断的に見るための、専用の保管庫のようなものだと思っていただくと近いかと思います。
そして、集めたのちに顧客IDや注文番号といった共通の項目で、データ同士を結びつけます。

これによって、「顧客Aの注文履歴と、支払い状況と、問い合わせ履歴」を、1つの画面で、あるいはAIへの1つの質問で、参照できるようになります。

この「抜き出して集める」作業は、かつては連携先ごとに専用のプログラムを書く必要があり、そこが負担の大きいところでした。
いまは、Fivetranや、海外製のAirbyte、国産のtroccoといった連携ツールを使えば、設定画面の操作だけで、主要なSaaSやデータベースからの取り込みを自動化できます。
集める先のDWHそのものは、BigQuery(Google Cloud)、Snowflake、Amazon Redshift(AWS)などが代表的です。
製品の優劣はここでは扱いませんが、いずれも「全社のデータを集めて横断的に扱うための、クラウド上の保管庫」だと捉えていただければ十分です。

経営として押さえておきたい判断が2つあります。
1つは、どのシステムのデータを、どの順番で集めるか。
全部を一度に集める必要はありません。まず事業上の優先度が高いデータ、例えば売上、顧客、在庫といったあたりから始めて、効果を確かめながら対象を広げていくのが、現実的なやり方です。

もう1つは、社内にこの作業を担えるデータエンジニアがいるかどうか。
いなければ、初期構築は外部に委託し、日々の運用を少しずつ社内に移していく、という進め方が多く取られています。

整理すると、外部に任せやすいのは基盤の初期構築のほうで、社内に握っておきたいのは「どのデータを優先するか」の判断と、日々の運用になります。

セマンティックレイヤー——数字に「共通の定義」を与える

次の打ち手は、同じ言葉が部署ごとに違う意味で使われている、という失敗パターンへの打ち手です。

いちばん分かりやすいのは「売上」です。
営業部門では「受注した時点の金額」を売上と呼び、経理部門では「納品して計上した時点の金額」を売上と呼んでいる。
同じ「売上」という言葉が、実は違う数字を指している、ということが社内では珍しくありません。

人間の社員なら「ああ、これは営業の言う売上ね」と暗黙のうちに補えますが、AIはその使い分けを知りません。この状態でAIに「今月の売上は?」と聞くと、どちらの定義のデータを拾うかによって、返ってくる数字が変わってしまいます。

そこで取るべき対策が、セマンティックレイヤーという打ち手です。
全社で使う指標——売上、粗利、解約率、顧客生涯価値など——について、「この言葉は、この計算式で出す」という定義を、1箇所にまとめておきます。平たく言えば、社内共通の「指標の辞書」を作る、ということです。

この辞書があると、AIは質問を受けたときに「売上とは、この計算式のことだ」と辞書を引いてから答えを組み立てるので、部署ごとに数字がブレる問題がなくなります。

意味づけがあるかないかで、AIの精度はどれくらい変わるのか。
第2回でも触れた数字ですが、AIがデータベースに直接質問したときの正答率は16%だったのに対し、意味づけの層を介して質問すると54%まで上がった、という検証結果があります(出典: arXiv:2311.07509(査読前のプレプリント)、The Golden Age of the Semantic Layer — AtScale)。

同じAI、同じデータでも、辞書があるかないかで、答えの確からしさはここまで変わるのです。
この辞書を技術的に実装するには、dbt、Cube、Lookerといったツールがありますが、ここでは「指標の定義を一元管理するための道具」とだけ捉えていただければと思います。

この打ち手には、経営の方に知っておいていただきたい点があります。
それは、この打ち手で最も時間がかかるのは、技術の実装ではなく「定義を揃える」という社内の合意形成のほうだ、という点です。
営業、経理、マーケティングといった各部門に「あなたたちの言う売上とは何か」をヒアリングし、食い違いを擦り合わせて、全社で1つの定義にまとめる。
この作業は、地味なようでいて、いちばんの難所になります。

そして、ここが今回の4つの打ち手のなかでも、外注と社内の切り分けが最もはっきり出るところです。
「御社の売上の定義はどれにしますか」という問いは、外部に委託できません。 これは社内でしか決められないことで、しかも部門間の利害がからむため、経営層が主導して各部門を巻き込んで初めて前に進みます。

一方で、定義が決まったあとに、それを仕組みへ落とし込む技術実装は、外部に任せられます。
「定義を決める」のは社内、「仕組みに落とす」のは外部、という役割分担が自然なかたちです。
ここを取り違えて、定義の合意形成まで外部に丸投げしてしまうと、多くの場合途中で行き詰まります。

データ品質管理——正確さと新しさを保つ

データが繋がって、言葉の意味も揃った。しかし、データの中身そのものが実態と合っていなければ、AIは正しく答えられません。
3つ目の打ち手は、この「中身の正確さと新しさ」を保つ、データ品質管理です。

実態と合っていない、とは具体的にどういうことか。
たとえば、同じ顧客が手違いで2件登録されている。
「株式会社ABC」「(株)ABC」「ABC Co.,Ltd.」が、別々の取引先として並んでいる。
退職した担当者が、まだ登録されたまま残っている。

こうした無秩序は、どの会社のデータにも、多かれ少なかれ存在しています。
やっかいなのは、AIはこうした不正確なデータを与えられても、「このデータは怪しいぞ」とは立ち止まってくれないことです。
人間なら「これは表記ゆれだな」「この情報は古いな」と気づいて補正しますが、AIはばらついたまま淡々と処理を進め、もっともらしい顔で、間違ったデータに基づく答えをそのまま返してきます。

データ品質管理の手段は、大きく4つの作業に分かれます。
1つ目は名寄せ。
同じ取引先や顧客が、表記の違いで別々に登録されている状態を、1つにまとめる作業です。
「株式会社ABC」と「(株)ABC」を、同一の取引先として統合します。
(出典: 名寄せとは — Salesforceブログ、データクレンジングと名寄せとは — EVER RISE)。

2つ目はデータクレンジング。
入力ミスや重複、フォーマットのばらつき——日付の書き方が「2025/1/1」と「2025-01-01」で混在している、全角と半角が混ざっている、といったもの——を検出して、表記をそろえる作業です。

3つ目はバリデーション。
これは、データが登録・更新されるたびに、おかしな値が紛れ込んでいないかを自動でチェックする仕組みです。
「金額がマイナスになっていないか」「必須項目が空欄のまま登録されていないか」を、システム側で水際でせき止めます。Great Expectationsや、dbt tests、Sodaといったツールを使うと、こうしたチェックを自動化できます。

そして4つ目が鮮度管理。
データの更新頻度を決めて、古い情報が残り続けないようにする取り組みです。在庫や注文状況のように常に最新であってほしいデータと、月次の売上集計のように日次や週次で十分なデータとでは、求められる更新の間隔が違いますから、データの性質に応じて頻度を決めます。

データ品質管理の担当切り分けは、こう考えると整理しやすいかと思います。
表記をそろえる、重複を検出する、といった技術的な処理は、ツールやエンジニアに任せられます。
既存データの初期クレンジングも、外部に委託しやすい部分です。

けれど、「この2社は本当に同じ取引先なのか」「正しい社名はどちらなのか」という最後の判断は、その取引先と日常的にやりとりしている現場の担当者にしかできません。 ここは外部には分かりようがない領域です。
そしてもうひとつ大事なのは、データ品質は一度きりのクレンジングでは終わらない、ということです。
データは毎日追加・更新されますから、品質のチェックを継続的に回す仕組みと、「何が正しいか」の判断基準は、社内に持ち続ける必要があります。

履歴設計——過去の状態を再現できるようにする

4つ目は、AIに「変化」を語らせたいなら欠かせない打ち手です。
過去の状態を残しておく、履歴設計です。

多くの業務システムは、情報が変わると、そのつど最新の値で上書きします。
たとえば、ある顧客の契約プランが1月に「プレミアム」から「ベーシック」へ変わると、システム上は「ベーシック」だけが残り、「かつてプレミアムだった」という事実は消えてしまいます。
日々の業務はそれで回りますが、AIに「去年の今ごろ、プレミアムプランの顧客は何人いたか」「契約プランが変わる前と後で、その顧客の利用はどう動いたか」と尋ねた瞬間に、行き詰まります。過去の姿が記録されていなければ、AIは時間をまたいだ比較ができないからです。

やっかいなのは、過去のデータがないとき、AIが「分かりません」と答えるとは限らないことです。
最悪の場合、現在の数字をそのまま使って、過去の問いに平然と答えてしまいます。

打ち手はこうです。
業務システムが上書きしてしまうこと自体は、変えなくてかまいません。
そこは触らず、データを集約する先のDWHに取り込むたびに、「その時点の状態」を丸ごと保存しておきます。
これをスナップショットと呼びます。
ある瞬間のデータの状態を、写真のように1枚ずつ残していくイメージです。
これを定期的に撮り続けていくと、「3か月前の時点で、契約プランはどうだったか」「半年前と今で、何が変わったか」を、後からたどれるようになります。

この打ち手には、ひとつ、見落とすと取り返しのつかない点があります。
それは、スナップショットは「始めた時点」からしか、過去を記録できないということです。
仕組みを入れる前の過去は、もう取り戻せません。
だからこそ、データの集約基盤であるDWHを作るタイミングで、履歴設計も一緒に組み込んでおくのが、最も効率的なやり方になります。
後から追加することもできますが、それまでの過去は失われたままです。

外注と社内の切り分けでいえば、仕組みそのものの構築はDWH構築の一部として外部に委託できます。
社内で決めるべきは、どのデータの履歴を残すか、の選定です。
すべてのデータの履歴を残す必要はありませんから、時系列で振り返りたいもの——顧客の契約情報、商品の価格、組織の構成など——を優先して選ぶことをおすすめします。

どこから手をつけるか

最後に、4つの打ち手をどの順で進めるか、優先順位を整理します。

土台になるのは、データ統合です。
データがバラバラのままでは、いくら言葉の定義を揃えても、いくら品質を上げても、AIが横断的に使える状態にはなりません。
ですから、まずは統合から着手するのが基本になります。

ただし、セマンティックレイヤー（定義の統一）と品質管理は、統合を待ってから始めるのではなく、統合と並行して進めるのが得策です。
「どのデータを、どの定義で集めるか」「品質の基準をどう設けるか」を、データを集めるのと同時に決めてしまうほうが、後からやり直す手間が減るからです。

そして履歴設計は、先ほどお伝えしたとおり「始めた時点」からしか記録が残らないため、DWHを構築するそのときに、一緒に組み込んでおくのが合理的です。

そして、自社がどの課題に当てはまるのかは、第2回でご紹介した9つの失敗パターンと照らし合わせ、最も業務への影響が大きいところから着手するのが現実的な進め方ではないかと思います。

まとめ——定石を知れば、第一歩は決まる

AI投資の成否は、AIの性能よりも手前の、自社データの状態で決まります。そして、その「整える」には定石がありました。

バラバラのデータを集める(データ統合)、言葉の意味を揃える(セマンティックレイヤー)、中身の正確さと新しさを保つ(データ品質管理)、過去を残す(履歴設計)。

この4つを、統合を土台に、定義と品質は並行で、履歴はDWH構築と同時に。
闇雲に始めるのではなく、自社が第2回の失敗パターンのどこに該当するかを見極めれば、打ち手と優先順位はおのずと決まります。

本記事では、売上や顧客数といった、表に収まる構造化データの話をしました。
けれど、企業に眠る知識の多くは、契約書や議事録、マニュアル、提案書といった、文書の形をしています。
構造化データをきれいに整えても、それだけでは、この文書に眠る知識には手が届きません。

次回の第4回では、こうした非構造化データをAIが扱えるようにする方法と、構造化・非構造化を合わせた統合的な管理について掘り下げていきます。

連載：なぜAIの話は、いつも「データ」の話になるのか

第1回：なぜAIの話がデータの話になるのか
第2回：AIで成果を出すためのデータ整理
第3回：AIが使えるデータ基盤の作り方
第4回：非構造化データをAIが使えるようになる方法
第5回：整ったデータを安心してAIに渡すための4つの打ち手
第6回：整えたデータを保ち続ける組織のつくり方
第7回：データとAIが生み出す企業の成長サイクル