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

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

連載の第1回では、AIで成果が出るかどうかは、AIの性能よりも手前の「自社データの状態」で決まる——という連載全体の流れをお話ししました。

第1回：なぜAIの話は、いつも「データ」の話になるのか

第2回からの記事では「なぜ、AIとデータの結びつきがそこまで強いのか」を理解するための内容になっています。

本記事ではまず、データが揃っていないと、AIに実際どんなことが起きるのかを見ていきます。

経営層の方からよく聞くのは、このような疑問です。
「営業はSalesforce、経理は会計システム、サポートはまた別のツール——うちは、CRMだけ入れればAIで何とかなるんですか？」「部署ごとにシステムがバラバラで、データがつながっていない。これがAIにどう響くんでしょうか？」

多くの方は、データが分散していること自体を「不便だけれど、まあそういうもの」と捉えていて、それがAI時代に経営へ直結するとは、まだ気づいていないように見えます。

この第2回でお伝えしたいことは、
データは「ただ集める」「ただ整える」だけでは通用しない。
AIで成果を出すには、これからお話しする9つの失敗パターンに、自社が当てはまっていないかを点検する必要があります、ということです。

9つにはいくつか専門用語が並びますが、すべて「その状態だと、AIがこう間違える/会社がこう損をする」という言葉にして記載します。

まず「サイロ化」から——AIが会社の全体像を見られない、という損失

9つのパターンの中でも、いちばん多くの会社に当てはまり、いちばん経営に響くものから始めます。
データが部署ごとに分断されている状態、いわゆるサイロ化です。

サイロ化とは簡単に、部署ごとにデータが孤立して、横につながらない状態を指します。
(出典: What Are Data Silos? — IBM)。

なぜ、こうなるのでしょうか。
理由はシンプルで、多くの会社は縦割りで、部門をまたいで全体最適を考える主体がいないまま、各部署がそれぞれ便利なシステムを選んで入れてきたからです(出典: サイロ化とは — データ・アプリケーション)。

営業はSalesforce、経理は会計システム、サポートは問い合わせ管理ツール。
一つひとつは正しい選択でも、気づけば社内に、互いに口をきかないデータの島が、いくつもできあがっています。

問題は、この状態でAIに何かを尋ねたときに起きます。
たとえば経営者が「あの大口顧客、いくつ注文して、いくら払って、何回問い合わせてきている?」と聞いたとします。
本来なら一息で答えてほしい問いですが、その答えは注文管理・会計・サポートの3つのシステムに、ばらばらに散っています。
AIは自分がつながっているデータからしか答えられませんから、システムの1つだけを見て「注文は3件です」とは言えても、支払いやクレームまで含めた、一人の顧客の全体像までは組み立てられません。

AIが会社の全体像を見られないということは、全体最適の判断ができないということです。
これはAIの性能の問題ではなく、データがつながっていないこと自体が生んでいる、経営の損失です。

この危機感は、数字にも表れ始めています。
ECサイトを運営する企業の経営層400名への調査では、「データ統合なしにAI競争に勝てない」と感じている経営層が58.0%に上りました。
ところが、実際にデータ統合を実現できている企業は24.2%、2026年に統合のための基盤投資を増やす予定の企業は18.2%にとどまります
(出典: データ分断に約6割が危機感 — ネットショップ担当者フォーラム(メルカート調べ、2026年3月、n=400))。

調査対象がEC企業の経営層なので、すべての企業にそのまま重なるとは限りません。
それでも、「まずい気はしているが、手は打てていない」という危機感と打ち手のギャップは、リソースの限られる会社ほど切実なのではないかと思います。

9つの失敗パターンは、3つのカテゴリに整理できます

サイロ化は分かりやすい入り口ですが、AI時代のデータの落とし穴は、これだけではありません。

とはいえ、闇雲に「あれもこれも」と並べても点検にはなりませんので、起こりがちな失敗を9つに絞り、自社を見るときの順番として、3つのカテゴリに整理しました。

1つ目は、そもそもデータそのものが、AIに使える状態か。
つながっているか、言葉の意味が定義されているか、正確で新しいか、過去が残っているか、文章や画像も扱えるか、という問いです。

2つ目は、AIにそのデータを扱わせるための、ガバナンスとセキュリティがあるか。
誰が使ってよいか、AIに渡してよいデータの線引きがあるか、出どころを後から辿れるか。

そして3つ目は、整えた状態を、保ち続ける組織があるかです。

3つのカテゴリに沿って、9つのパターンを順に見ていきます。
それぞれ「どんな状態か」「AIがどう間違える・何を損なうか」「打ち手は何と呼ばれるか」の順でお話しします。

カテゴリ①　データそのものが、AIに使える状態か

パターン1　つながっていない(サイロ化)

最初のパターンは、すでに見たサイロ化です。
部署ごとにデータが島になっていて、AIが会社の全体像を組み立てられない状態。
AIは見ることのできるデータの中だけで答えてしまうので、つじつまは合っていても、肝心の全体が抜け落ちた答えになります。

このサイロをつなぎ、散らばったデータを「一人の顧客」「一つの取引」として見えるようにする打ち手を、データ統合と呼びます。

具体的に何が起きるかは、ルールの揃っていない営業システムにAIを入れるとどうなるかを描いたこちらの記事も、手触りの参考になるかと思います。
整え方そのものは深い話になりますので、ここではまず、つながっていないこと自体がすでに損失なのだ、ということをお伝えしておきます。

パターン2　意味が定義されていない

データはつながっても、すぐ次の壁が待っています。
AIに「先月の売上は？」と聞いたとき、その「売上」が税込なのか税抜なのか、受注ベースなのか計上ベースなのか、どの部門のものなのか。

人間の社員なら暗黙のうちに補えるこうした意味づけを、AIは知りません。
意味の定義が社内になければ、AIはその言葉が何を指すのかを当てずっぽうで推測するしかなく、もっともらしいけれど見当違いの数字を、平然と返してきます。

データに意味や定義を添えるこの仕組みは、専門的にはセマンティックレイヤーと呼ばれますが、社内の言葉に置きかえるなら、AIが自社のデータを読み解くための「辞書」のようなものです。

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

同じAI、同じデータでも、辞書があるかないかで、答えの確からしさがここまで変わるのです。
「うちはちゃんと貯めているから大丈夫」という会社ほど、この落とし穴は見えにくいものです。意味づけの話は、連載の後の回でも改めて掘り下げます。

パターン3　正確でない・古い

データはあっても、その中身が正確で新しいとは限りません。
同じ取引先が「株式会社○○」と「○○(株)」のように複数の表記で登録されていたり、入れてほしい項目が人によって空欄だったり、何年も前の古い情報がそのまま残っていたり。
人間なら「これは表記ゆれだな」「この情報は古いな」と気づいて補正しますが、AIは人のように「なんだか変だぞ」と立ち止まってはくれません。
ばらついたまま淡々と処理を進め、かえって間違いを広げてしまいます。

こうした「データの正確さ・新しさ」を保つ取り組みを、データ品質管理と呼びます。

粗悪なデータ品質が組織にもたらす損失について、調査会社のGartnerは年平均で1,290万ドルにのぼると試算しています(出典: Data Quality — Gartner)。
これは2020年の、しかも既にデータ品質ツールを導入済みの大企業を対象にした数字なので、そのまま自社の金額に置きかえる必要はありません。
それでも、「持っているデータが汚れていると、見えないところでこれだけのコストが流れ出ていく」という傾向そのものは、規模を問わず影響してくるのではないかと思います。

パターン4　過去が残っていない

意外と見落とされがちなのが、過去の情報が残っていない、という状態です。
多くのシステムは、情報が変わるとそのつど最新の値で上書きします。 顧客の担当者が変わった、料金プランが変わった、取引条件が変わった——古い値は消え、いつも「いま」の姿だけが残ります。
日々の業務はそれで回りますが、AIに「あの取引先、去年の今ごろはどのプランだった？」「担当者が変わる前と後で、売上はどう動いた？」と尋ねた瞬間に、行き詰まります。
過去の姿が記録されていなければ、AIは時間をまたいだ比較も、傾向の分析もできないからです。

変化の履歴を消さずに、ある時点の状態を後から再現できるよう残しておくこと。この打ち手を、SCD（ここでは履歴を残す設計と呼んでおきます）と言います。(出典: Slowly Changing Dimensions Type 2 — Analytics Engineering)。

経営にとっての意味はシンプルで、過去を残していないと、AIに「変化」を語らせることができない、ということです。
AIに期待したい仕事の多くは、実は「以前と比べてどうか」という時間の比較ですから、ここが抜けていると、効果は大きく削がれてしまいます。

パターン5　非構造化データが使えない

ここまでは主に、表に収まる数字やリストの話でした。
けれど、企業に眠る情報の大半は、議事録、商談メモ、メール、契約書、問い合わせ記録といった、文章や画像の形をしたものです。
こうしたデータは非構造化データと呼ばれ、企業が持つ情報のおよそ90%を占めるとされています(出典: 企業が持つ情報の90%は非構造化データ — Box Japan(IDC白書を引用))。
本来は宝の山ですが、AIが検索したり参照したりできる形に整えていなければ、AIはそこに触れることすらできません。

文章や画像をAIが検索して、その中身を根拠に答えられるようにする仕組みを、RAG(必要な文書を検索して引っぱってくる仕組み)と呼びます(出典: What is Retrieval Augmented Generation? — Databricks)。

社内文書をこの形にしておくと、AIは一般論ではなく「御社の契約書の、この条項では」と、出どころ付きで答えられるようになります。
非構造化データの扱いは、それ自体が大きなテーマなので連載の後の回に譲りますが、ここでは「文章や画像の山を、使える形にしていないと、AIの目にはそもそも映らない」ということだけ、押さえていただければと思います。

カテゴリ②　AIに扱わせるための、ガバナンスとセキュリティがあるか

データが使える状態になったら、次は「AIに、そのデータを扱わせてよいのか」という問いに移ります。
この過程を飛ばすと、せっかく整えたことが、かえってあだになりかねません。

パターン6　誰が使ってよいか、決まっていない

AIに社内データをつなぐと、たいていのAIは「それを操作している人が、もともとアクセスできる範囲」をそのまま参照します。
Microsoftも、自社のAIアシスタントについて「利用者がアクセス権を持つ内容しか、要約・参照できない」と明記しています(出典: Microsoft 365 Copilot data protection architecture — Microsoft Learn)。

一見、安全に聞こえます。けれど裏を返すと、もともとの権限設計が緩ければ、その緩さが、そのままAIから露出するということです。

たとえば、本来は役員しか見られないはずの人事評価や給与の情報が、フォルダの共有設定の甘さで全社員に見えてしまっていたら、その情報は、一般社員が使うAIの答えにも、するりと出てきてしまいます。

人やAIが、どのデータにどこまで触れてよいかを決めて線を引いておくことを、アクセス制御と呼びます。

皮肉なことに、サイロをつないで全社のデータをAIから見えるようにするほど、この「誰がどこまで見てよいか」の設計が効いてきます。つなぐことと、絞ること。この2つは、いつもセットで考える必要があるのです。

パターン7　AIに使わせてよいかの区別がない

アクセス制御が「社内の誰に見せるか」の話だとすれば、こちらは「そもそも、AIに渡してよいデータなのか」という、もう一段手前の区別です。

顧客の個人情報、取引先との機密、まだ公表していない財務——これらを、社内の便利な道具とはいえ、AIに読ませてよいのか。
とりわけ、外部のAIサービスを使う場合や、自社の業務データをAIの学習に使う場合には、慎重な線引きが要ります。

ここで重要になるのが、データを「これは外に出せる」「これは社内限り」「これはAIに渡してはいけない」と仕分けておくデータ分類と、顧客から得た同意の範囲を管理する同意管理です。

たとえば、サポート対応のために集めたデータを、AIの学習にまで使ってよいかは、取得したときの同意がそこまでカバーしているかで変わります(出典: Consent for AI Training Data — CookieScript)。
デジタル庁のガイドラインも、従来の情報セキュリティが機密性、つまり「外に出さないこと」を最優先にしがちだった点に触れ、これからは守るべきものを守りながら、使うべきものは使えるようにする設計へ、と促しています(出典: データガバナンス・ガイドライン — デジタル庁)。
守りと活用は、二者択一ではなく、線引きの問題なのだと思います。

パターン8　出どころや加工をたどれない

AIが「この数字です」「この方針をおすすめします」と答えたとき、その答えが社内のどのデータを根拠にし、そのデータがどこから来て、どう加工されたものなのかを、後から辿れないという問題もあります。

辿れなければ、AIの答えが間違っていたときに原因を突き止められませんし、万一、機密データが想定外に使われていても気づけません。
経営として「なぜそうなったのか」を説明できない状態は、AIを業務の判断に組み込むほど、リスクとして重くなっていきます。

データの出どころと加工の経路を追跡できるようにしておく仕組みをデータリネージ、誰がいつどのデータに触れたかの記録を監査ログと呼びます(出典: Why Data Lineage is Essential for AI — Solidatus、What Is Data Lineage? — IBM)。

地味な備えですが、これは、AIの判断を後から説明できる状態にしておくための保険のようなものです。
出どころを説明できないAIは、経営の道具としては危うい、と捉えておくのがよいかと思います。

カテゴリ③　整えた状態を、保ち続ける組織があるか

パターン9　整えた状態を保つ担当がいない

ここまでの8つを頑張って整えても、最後の一つが抜けていると、すべては時間とともに崩れていきます。

データは生き物のようなもので、放っておけば新しい表記ゆれが生まれ、定義は再びあいまいになり、古い情報がたまっていきます。
一度きれいにした部屋も、掃除する人がいなければ、また散らかってしまうのと同じです。

整えた状態に責任を持つ役割は、一般に二つに分けて語られます。
データオーナーは、その領域のデータに最終責任を持つ立場で、多くは部門長や管掌役員が担います。
データスチュワードは、日々の品質や整理を実際に見る運用担当を指します
(出典: Data Owner vs. Data Steward — Actian、The Role of Data Stewards Today — Alation)。

専任のデータ部門を置く体力のある会社ばかりではありませんが、ここで大事なのは、立派な組織を作ることではありません。
兼任でかまわないので「このデータは、誰が責任を持ち、誰が日々見るのか」を決めておくこと。それだけで、整えた状態は、ずいぶん長持ちします。

デジタル庁のガイドラインも、データを持続的・組織的に活かす総合的な能力(データマチュリティ)を、企業が不断に高めていくべきものとして挙げています(出典: データガバナンス・ガイドライン — デジタル庁)。
仕組みを作る人ではなく、保つ人がいるか。これが、AIの成果を一過性で終わらせないための、最後の問いになります。

自社点検リスト——9つのうち、いくつできているか

ここまでの9つを、そのまま点検リストにしました。
それぞれ、自信を持って「できている」と言えるものに、チェックを入れてみてください。

① データそのものが、AIに使える状態か

□ 部署をまたいで、一人の顧客・一つの取引を、つながった形で見られる
□ 「売上」などの言葉の意味・定義が社内で揃っていて、AIにも渡せる
□ 表記ゆれ・重複・空欄・古い情報を、整える仕組みがある
□ 情報が変わっても過去の状態が残り、時点をまたいだ比較ができる
□ 議事録・契約書・メールなどの文章も、AIが検索・参照できる形にしている

② AIに扱わせるための、ガバナンスとセキュリティがあるか

□ 誰がどのデータにどこまで触れてよいか、線が引かれている
□ AIに渡してよいデータと、渡してはいけないデータを仕分けている
□ AIの答えの出どころと、データの加工経路を、後から辿れる

③ 整えた状態を、保ち続ける組織があるか

□ 各データについて「誰が責任を持ち、誰が日々見るか」が決まっている

チェックの入らない項目があったなら、そこが、自社のAI投資の成果を知らぬ間に止めている場所かもしれません。

9つすべてを、一度に完璧にする必要はありません。 点検は全体に、着手は一点から。
この順番が、限られた人数でも今日から動ける、現実的なやり方ではないかと思います。

まとめ——「ただ集める・ただ整える」では、通用しない

AI投資の成否は、AIの良し悪しよりも手前の、自社データの状態で決まります。
そして、その「整える」は、ただ集めて、ただ並べることではありませんでした。
データそのものがAIに使える状態か、AIに扱わせるための備えがあるか、そして整えた状態を保つ人がいるか。
AI時代のデータ整備とは、この問いに自社で答えられる状態を、こつこつと作っていくことなのだと思います。

次回からは第3回〜第5回にかけて、3つのカテゴリ・9つのパターンを「どう整えるか」という打ち手の側から解説していきます。

第3回で扱うのは、最初のカテゴリ「データそのものを、AIに使える状態にする」。
具体的な打ち手と、取り組む際に必要な人材・期間・コストまでを見ていきます。

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

第1回：なぜAIの話がデータの話になるのか
第2回：AIで成果を出すためのデータ整理
第3回：データそのものを、AIに使える状態にする
第4回：AIに扱わせるための、ガバナンスとセキュリティを整える
第5回：整えた状態を、保ち続ける組織をつくる
第6回：自社のデータ状態を見極める問い