AIの話になると、どうしても注目はモデルに集まりがちです。
どの生成AIを使うのか。
どのLLMが高性能なのか。
どのAIエージェントを導入すれば業務を自動化できるのか。
もちろん、それらは重要です。
しかし、企業でAIを本当に使おうとすると、もっと地味で、もっと本質的な問題にぶつかります。
AIに渡すデータは正しいのか。
そのデータの意味はそろっているのか。
部門をまたいでつながっているのか。
継続的に更新され、監視されているのか。
AIが判断に使ってよいデータなのか。
ここを抜きにしてAI導入を進めると、見た目は立派でも、実務では使えないAIになります。
AIの成否を分けるのは、モデルそのものだけではありません。
その下にあるデータ基盤と、データの意味を整える力です。
「AIを導入したい」と「AIを使える」は違う
多くの企業は、AIを業務に組み込みたいと考えています。
需要予測、在庫最適化、顧客対応、解約予測、教育支援、営業分析、問い合わせ分類、業務自動化。AIを使えそうな領域はたくさんあります。
しかし、AIを導入したいことと、AIを使える状態にあることは違います。
AI導入が進まない原因は、必ずしもモデルの性能不足ではありません。
むしろ、業務データが次のような状態になっていることが大きな障害になります。
- 部門ごとにデータが分断されている
- 同じ意味の項目名が複数ある
- 同じ会社や商品が別名で登録されている
- 指標の定義が部門ごとに違う
- 欠損や異常値の意味が分からない
- 入力ルールが途中で変わっている
- 現場の暗黙知がデータに反映されていない
- 本番運用で継続取得できないデータが混じっている
上にどれほど高性能なAIを乗せても、基礎となるデータが弱ければ、結果は不安定になります。
AIは魔法の箱ではありません。
与えられたデータから判断します。
だからこそ、AIを使う前に、データをAIが使える状態にする必要があります。
関係なさそうなデータが効くことはある
AI活用で難しいのは、どのデータが効くかが最初から分からないことです。
たとえば、顧客の解約予測を考えます。
契約年数、利用頻度、料金プランは、いかにも関係がありそうです。
しかし実際には、問い合わせ回数、ログイン時間帯、エラー発生頻度、キャンペーンメールへの反応、請求方法の変更などが、解約の兆候を示すこともあります。
サプライチェーンでも同じです。
需要予測では、過去の販売実績だけを見ればよいとは限りません。
天候、物流遅延、倉庫の混雑、サプライヤーの納期変動、港湾の混雑、センサー情報、顧客問い合わせ、規制変更、地政学リスクなど、一見遠いデータが意思決定に効くことがあります。
AIは、人間が見落としやすい弱いシグナルや、複雑な組み合わせを拾える場合があります。
その意味では、「関係なさそうだから」と最初から捨てるのは危険です。
ただし、逆も重要です。
何でもAIに入れれば精度が上がるわけではありません。
関係の薄いデータ、品質の悪いデータ、意味があいまいなデータ、未来情報が混ざったデータを入れると、むしろ精度は下がります。
場合によっては、見かけ上だけ高精度で、本番では使えないAIができます。
重要なのは、データを増やすことではありません。
そのデータが、何を意味し、どの判断に使えるのかを検証することです。
問題はデータがあるかではなく、AIが使えるデータか
企業には大量のデータがあります。
- ERPのデータ
- WMSやTMSのデータ
- 販売データ
- 在庫データ
- 購買データ
- 顧客データ
- 問い合わせ履歴
- 契約書や仕様書
- IoTセンサーのデータ
- 現場で作られたExcel
- 担当者しか知らないメモ
しかし、それらが存在していることと、AIが使えることは別です。
AI対応データには、少なくとも3つの条件が必要です。
Connected: つながっていること
Contextual: 文脈を持っていること
Continuous: 継続的に管理されていること
この3つは、AI時代のデータ基盤を考えるうえで非常に重要です。
Connected: データがつながっていないと、AIは全体を見られない
まず必要なのは、データがつながっていることです。
サプライチェーンでは、販売、需要計画、調達、製造、倉庫、輸送、顧客対応がつながっています。
ところが、システム上は部門ごとにデータが分断されていることがよくあります。
- 販売部門は販売実績を見る
- 物流部門は輸送状況を見る
- 倉庫部門は在庫と入出荷を見る
- 調達部門はサプライヤー納期を見る
- 経営層は集計されたレポートを見る
人間向けのレポートであれば、これでも何とかなるかもしれません。
しかしAIが高度な判断をするには、これらのデータがつながっている必要があります。
たとえば、ある商品の欠品リスクを予測するには、在庫数だけでは足りません。
- 需要が増えているのか
- サプライヤーの納期が遅れているのか
- 港や輸送ルートで遅延が起きているのか
- 倉庫の処理能力に余裕があるのか
- 代替商品はあるのか
- 重要顧客への影響はどれくらいか
これらをつなげて初めて、AIは実務的な判断に近づきます。
AIに必要なのは、単なるデータの山ではありません。
業務全体を見渡せるようにつながったデータです。
Contextual: 同じ言葉が同じ意味で使われているか
次に重要なのが、文脈です。
同じ会社を指しているのに、データ上では別々の名称になっていることがあります。
ABC group holdings
ABC mfg. inc.
ABC manufacturing
人間なら「たぶん同じ会社かな」と気づけるかもしれません。
しかし、AIやシステムが安定して判断するには、これらが同一の取引先なのか、別会社なのかを明確に解決しておく必要があります。
これは、エンティティ解決の問題です。
さらに厄介なのは、指標の意味です。
たとえば「オンタイム配送」という言葉があったとします。
しかし、地域や部門によって定義が違うことがあります。
- 出荷予定日に出したらオンタイムなのか
- 顧客到着日まで含めるのか
- 時間指定まで守った場合だけなのか
- 一部納品でもオンタイム扱いなのか
- 天災による遅延は除外するのか
この定義がそろっていないままAIに渡すと、AIは同じ言葉を違う意味で学習します。
教育現場でも同じです。
「学習意欲」「理解度」「提出状況」「つまずき」「主体性」といった言葉はよく使われます。
しかし、定義があいまいなままデータ化すると、AIは正しく判断できません。
AIにとって大事なのは、データがあることではありません。
そのデータが何を意味しているのかが明確であることです。
Continuous: データ品質は一度きれいにすれば終わりではない
3つ目が、継続性です。
データクレンジングというと、一度データをきれいにする作業のように思われがちです。
しかし、AI活用ではそれでは不十分です。
現実の業務データは常に変化します。
- 新しい商品が出る
- 取引先が統合される
- 入力ルールが変わる
- 現場の運用が変わる
- センサーが増える
- システムが更新される
- 担当者の入力方法が変わる
- 市場環境が変わる
すると、過去に整えたデータの意味や品質も少しずつ変わっていきます。
だから、AIに使うデータは継続的に監視しなければなりません。
- 欠損が増えていないか
- 異常値が増えていないか
- 入力ルールが変わっていないか
- 特定部門だけデータ傾向が違っていないか
- 学習時のデータと本番時のデータがずれていないか
- 取得できなくなった項目がないか
AIは一度作って終わりではありません。
AIを支えるデータ基盤も、一度整備して終わりではありません。
データエンジニアはAIに食べさせるデータを設計する
ここで、データエンジニアの役割が重要になります。
AI時代のデータエンジニアは、単にデータを集める人ではありません。
単にETL処理を書く人でもありません。
AIが使えるデータの流れを設計する人です。
具体的には、次のような役割を担います。
- データソースをつなぐ
- データの粒度をそろえる
- 表記ゆれを直す
- 重複を取り除く
- 欠損の意味を整理する
- データの発生時点を管理する
- 本番でも継続取得できるようにする
- 個人情報や機密情報を適切に扱う
- データ品質を監視する
- AIが使いやすい形に変換する
ここで重要なのは、前処理とは単なる掃除ではないことです。
前処理とは、データの意味をそろえ、AIが誤解しないようにする設計作業です。
たとえば、欠損値がある場合も、ただ平均値で埋めればよいとは限りません。
欠損には意味があることがあります。
- 入力漏れなのか
- 該当なしなのか
- まだ発生していないのか
- システム連携に失敗したのか
- 意図的に記録していないのか
これを考えずに機械的に処理すると、AIに間違った意味を教えてしまいます。
データサイエンティストは関係があるかを検証する
では、データサイエンティストは何をするのでしょうか。
データサイエンティストの役割は、このデータは関係ある、これは関係ないと最初から完全に見抜くことではありません。
重要なのは、関係があるかどうかを検証できる形にすることです。
まず、目的を明確にします。
- 何を予測したいのか
- 何を分類したいのか
- 何を最適化したいのか
- どの時点で判断したいのか
- その判断結果を業務でどう使うのか
次に、データ候補を広く洗い出します。
- 明らかに関係しそうなデータ
- 関係がありそうだが確認が必要なデータ
- 一見関係なさそうだが兆候を示すかもしれないデータ
- 使ってはいけない可能性のあるデータ
そのうえで、業務仮説を立てます。
- なぜこのデータが効く可能性があるのか
- どういう場合に効くのか
- 単独では弱くても、他のデータと組み合わせると意味が出るのか
- 強く見えても、実は未来情報を含んでいないか
そして、モデルで検証します。
- 入れた場合と入れない場合で精度が変わるか
- 特定のデータを抜くと性能が落ちるか
- 特徴量重要度はどうか
- SHAPなどで見たときに説明可能か
- 業務担当者が見ても納得できるか
- 本番運用でも継続して取得できるか
データサイエンティストは、人間の仮説とAIによる検証を往復する役割を持ちます。
関係ありそう、関係なさそうだけでは足りない
実務では、データを3つに分けると考えやすくなります。
| 分類 | 例 | 見るべき観点 |
|---|---|---|
| 明らかに関係がありそうなデータ | 販売実績、在庫、出荷、契約期間、利用頻度 | まず候補に入れる。ただしリークや定義ずれを確認する |
| 一見関係なさそうだが検証する価値があるデータ | ログイン時間帯、入力ミス、センサー値、天候、問い合わせ文の長さ | 弱い兆候や組み合わせ効果がないか検証する |
| 使ってはいけない、または慎重に扱うデータ | 未来情報、個人情報、差別につながる可能性があるデータ、本番取得できないデータ | 精度よりもリスク、説明可能性、継続性を優先する |
重要なのは、データを関係ある、ないだけで判断しないことです。
見るべきなのは、次の4つです。
- 効くかどうか
- 使ってよいかどうか
- 説明できるかどうか
- 継続運用できるかどうか
AI活用では、精度だけを見てはいけません。
使えないデータで高い精度が出ても、本番では意味がありません。
AIエージェント時代にはデータ基盤の重要性がさらに増す
AIエージェントは、単に質問に答えるだけではありません。
業務システムとつながり、状況を判断し、必要な処理を呼び出し、場合によっては自律的にアクションを取ります。
サプライチェーンなら、次のような動きが考えられます。
- 欠品リスクを検知する
- 代替サプライヤーを探す
- 輸送ルートを変更する
- 在庫移動を提案する
- 発注量を調整する
- 現場担当者に例外を通知する
しかし、AIエージェントが自律的に動くほど、データの信頼性は重要になります。
間違った在庫データを見て発注したらどうなるか。
同じ取引先を別会社と誤認したらどうなるか。
納期の定義が部門によって違っていたらどうなるか。
古いデータを最新情報として扱ったらどうなるか。
AIが単なる助言者であれば、人間が最後にチェックできます。
しかしAIが業務プロセスに深く入り、自律性を持つようになるほど、基盤データの誤りはそのまま業務リスクになります。
人間の関与はデータの信頼度で変わる
AIエージェントの運用では、人間の関与レベルを段階的に考える必要があります。
human-in-the-loop:
AIの提案を人間が毎回確認する
human-on-the-loop:
AIは通常処理を進め、人間は例外や高リスク判断を監視する
human-off-the-loop:
ガードレールの範囲内でAIが自律的に判断する
この段階を進めるための入口が、信頼できるデータです。
データがつながっていない。
定義がそろっていない。
品質が監視されていない。
この状態で自律性だけを上げると、AIは速く間違えます。
AIの自律性を高めるなら、先にデータ基盤とガードレールを整える必要があります。
AI時代の競争力はアルゴリズムよりデータ基盤に移る
現在、多くの企業が同じようなAIモデルやクラウドサービスを使えるようになっています。
生成AIも、機械学習基盤も、AIエージェントの仕組みも、以前より手に入りやすくなっています。
そうなると、差がつくのはモデルそのものだけではありません。
- 自社の業務データがどれだけ整っているか
- 業務の意味がデータに反映されているか
- 部門をまたいでデータがつながっているか
- 現場の暗黙知をデータ化できているか
- データ品質を継続的に維持できるか
- AIが安全に判断できるガードレールを作れているか
ここが競争力になります。
AI時代の企業に必要なのは、単なるAI導入ではありません。
AIが力を発揮できるデータ環境を作ることです。
教育でも同じ問題が起きる
これはサプライチェーンだけの話ではありません。
教育にもそのまま当てはまります。
たとえば、学習支援AIを考えてみます。
生徒の点数だけを見ても、理解の状況は分かりません。
提出物の内容、解答過程、間違え方、質問履歴、学習時間、授業中の反応、振り返りの記述など、さまざまなデータが必要になります。
しかし、それらをただ集めればよいわけではありません。
「理解度」とは何か。
「つまずき」とは何か。
「主体的に学んでいる」とは何か。
「支援が必要」と判断する基準は何か。
これらを定義せずにAIに渡すと、AIは表面的なデータだけで判断します。
たとえば、提出回数が多い生徒を意欲が高いと判断するかもしれません。
しかし実際には、何度もやり直して苦労している生徒かもしれません。
逆に提出回数が少ない生徒でも、深く考えて一度で質の高いものを出している場合もあります。
教育でも、AIにデータを渡す前に、データの意味を人間が考える必要があります。
AI活用で本当に必要なのはデータを読む力
AI時代に必要なのは、単にAIツールを操作する力ではありません。
プロンプトを書く力だけでもありません。
モデルを選ぶ力だけでもありません。
必要なのは、データを読む力です。
- このデータは何を表しているのか
- どの時点の情報なのか
- 誰が、何の目的で入力したのか
- 欠損にはどんな意味があるのか
- 部門によって定義が違っていないか
- 現実の業務を正しく反映しているのか
- AIが誤解しやすい形になっていないか
- 使うことで不公平やリスクが生まれないか
こうした問いを立てる力が重要になります。
AIの精度は、最終的にはモデルだけでは決まりません。
AIに渡されるデータの意味と品質によって大きく変わります。
AIに任せる前に、人間がデータの意味を整える
一見関係なさそうなデータも、AIの精度向上に役立つ可能性があります。
しかし、それをそのままAIに投げ込めばよいわけではありません。
必要なのは、データエンジニア、データサイエンティスト、業務担当者が協力して、データの意味を整えることです。
| 役割 | 担うこと |
|---|---|
| データエンジニア | AIが使える形でデータをつなぎ、整え、継続的に流れるようにする |
| データサイエンティスト | 関係があるかどうかを仮説と実験で検証する |
| 業務担当者 | そのデータが現場で何を意味するのかを説明する |
| IT技術者 | 権限、監査、運用、コストを含めてデータ基盤を設計する |
| 経営層 | AI導入だけでなく、データ基盤への投資を意思決定する |
AI時代に問われるのは、どのAIを使うかだけではありません。
AIに何を、どのような意味で渡すのかです。
ペントハウスを急いで建てる前に、まず基礎を作る必要があります。
その基礎こそが、データ基盤です。
AIの精度を上げる本当の仕事は、AIに入力する前から始まっています。
作成日: 2026-06-19
タグ候補: 生成AI データ基盤 データエンジニアリング データサイエンス AIエージェント