AI活用の前提としてのデータ基盤——何から整えるか

エグゼクティブ・サマリー

• 「データがない」は四つの別々の状態を指している。 存在しない／散在している／品質が低い／意味が定義されていない。原因が違えば打ち手も費用も違うのに、同じ一言で片付けられているために、投資判断が止まる。
• データ整備を目的にしない。 全社のデータを綺麗にしてからAIに進む計画は、ほぼ完走しない。特定のユースケースから逆算し、そのために必要なデータだけを整える。範囲を絞ることが、唯一の完走条件である。
• 五種類を分けて扱う。 マスタ／トランザクション／センサ・稼働／非構造化（文書・図面・画像）／暗黙知。難易度も整備手段も別物であり、まとめて計画すると必ず最も難しいものに引きずられる。
• 品質は感覚ではなく6軸で測る。 完全性・正確性・一貫性・適時性・一意性・追跡可能性。「品質が悪い」ではなく「一意性が満たされていない」と言えれば、直す対象が特定できる。
• 最大のボトルネックは意味の未定義である。 同じ「稼働時間」「不良」「顧客」が部署ごとに別の定義で使われている限り、どれだけデータを集めても合算できない。データ辞書とID統一は、技術ではなく業務側の仕事である。
• 器は小さく始めて育てる。 表計算から始め、必要になった段階でデータベース、次に分析基盤へ移す。最初に大きな基盤を買うと、載せるデータが揃う前に運用が形骸化する。

AI活用の相談で最も多く聞く言葉は「うちにはまだデータがない」である。しかし実際に現場へ入ると、データは存在していることがほとんどである。日報がある。点検記録がある。生産実績がある。図面も作業手順書もある。存在していないのではなく、使える形になっていない。この違いは重要で、前者なら取得の仕組みから作る必要があるが、後者は整理と定義の問題であり、多くの場合はるかに安く済む。

本稿は、ロボットやシステムを販売しない中立の立場から、AI活用の前提となるデータ基盤を「何から、どの順で、どこまで」整えるかを整理する。大規模な全社データ基盤の構築論ではない。最初のユースケースを動かすために必要な最小限を見極め、そこから育てるための実務的な手順として書いている。

1. 「データがない」の四つの正体

まず言葉を分解する。ここを曖昧にしたまま予算の議論に入ると、必ず見積が過大になる。

実務での出現頻度は、②③④が圧倒的に多い。①は「新しく測りたいもの」に限られる。そして④は、費用としては最も小さいのに、着手が最も遅れる。技術部門は業務定義を決められず、業務部門はデータの話だと思って手を出さないため、誰の仕事にもならないまま残る。

最初にやるべきことは、この四分類で自社の状態を仕分けることである。仕分けの結果、④だけが問題だと分かれば、基盤の購入は不要になる。

2. ユースケースから逆算する

データ整備を先に完成させてからAIに進む、という計画はほぼ完走しない。理由は三つある。終わりが定義できないこと、途中で成果が出ないため予算が続かないこと、そして整備した項目が実際のAI用途で使われる保証がないことである。

順序は逆にする。

1. ユースケースを一つ選ぶ（例：特定設備の予知保全、特定品目の需要予測、点検報告書の作成支援）
2. そのユースケースが必要とする項目だけを列挙する（多くの場合10〜30項目に収まる）
3. 列挙した項目を四分類で仕分ける
4. 不足を埋める作業だけを計画する

この順で進めると、整備の範囲が具体化し、費用も期間も見積れる。設備の予知保全にAIをどう使うかやAIによる需要予測の実装のようなユースケース側の資料と、本稿を並べて使うのが実務的である。

ユースケースの選び方は、価値の大きさよりもデータの近さを優先してよい。最初の一件は成功させることに意味があり、成功実績がなければ二件目の予算はつかない。価値が大きくデータが遠い案件は、二巡目に回す。

3. 五種類のデータを分けて扱う

一括りに「データ」と呼ぶと、最も難しいものに全体が引きずられる。次の五つは、整備の難易度も手段も別物である。

マスタが最初である。 品目IDと設備IDが揃っていなければ、どのデータも結合できない。逆にマスタさえ揃えば、既存システムに散っているデータの多くは後から繋がる。マスタ整備は地味で、成果が見えにくく、政治的な調整を伴うが、ここを飛ばすと後工程がすべて割高になる。

センサ・稼働データには契約が絡む。 ロボットや設備の稼働データはベンダーのクラウドに閉じていることが多く、自社で取れるかどうかは契約に書いたかどうかで決まる。この論点はロボット稼働データの収集・可視化基盤で詳しく扱っている。導入後に依頼すると、多くの場合は有償の追加開発になる。

非構造化データは、生成AIの登場で扱いやすくなった領域である。 一方で、集めれば使えるわけではない。版が古い手順書、承認前の図面、個人の端末にしかない写真が混ざったまま利用すると、誤った回答の根拠になる。対象範囲と版管理を先に決める。現場業務における生成AIの実装の内容と併せて検討したい。

4. データレディネス診断——12問

投資判断の前に、次の12問に答える。答えられない項目が、そのまま次にやることになる。

1. このユースケースに必要な項目を、10〜30項目に列挙できているか
2. 各項目が、どのシステム・どの帳票に存在するか特定できているか
3. 各項目の定義（何を含み、何を含まないか）が文書化されているか
4. 主要なマスタのIDが、システム間で一致しているか
5. 欠損率をおおよそ把握しているか
6. データがいつ入力されるか（実績発生からの遅れ）を把握しているか
7. 過去どこまで遡れるか。遡れる期間はモデルの学習に足りるか
8. データの所有者（オーナー）が部署単位で決まっているか
9. 抽出の権限と手段があるか（毎回情報システム部門に依頼が要る状態か）
10. 外部サービスへ持ち出してよいデータかどうかの判断基準があるか
11. 保存期間と削除の方針が決まっているか
12. 誰がこのデータを日常的に見ているか（見ていないデータは劣化する）

12問のうち、③④が「いいえ」なら、器の議論は時期尚早である。⑨が「いいえ」の場合、技術ではなく業務プロセスの問題として扱う。⑫が「いいえ」のデータは、整備しても必ず劣化する。誰も見ていないデータは、遅かれ早かれ壊れる。

5. 品質を6軸で測る

「データの品質が悪い」は、対策の指示にならない。次の6軸に分解すると、直す対象が特定できる。

このうちAI活用で効いてくるのは、一意性と適時性である。一意性が崩れていると、集計も学習も成立しない。適時性が確保されていないと、予測モデルは学習時と運用時で条件が変わり、実運用で精度が出ない。逆に完全性は、多少の欠損なら扱う手段があり、最初から100%を目指す必要はない。

品質改善は、システム側の後処理ではなく入力の業務設計で解く方が安く続く。入力が作業の自然な一部になっていなければ、どんな検査ロジックも追いつかない。

6. 意味を揃える——データ辞書とID統一

最も安く、最も効き、最も後回しにされる作業である。やることは二つしかない。

データ辞書。 ユースケースで使う項目について、項目名・定義・単位・値の範囲・更新頻度・オーナー部署を一行ずつ書く。最初は20〜30行で足りる。重要なのは網羅性ではなく、「含まないもの」を書くことである。「稼働時間：電源が入っており、かつ実作業を行っている時間。段取り替えと待機を含まない」——この一行があるだけで、後の議論が半分になる。

ID統一。 品目・設備・拠点・顧客について、正となるIDを一つ決め、他システムのIDとの対応表を持つ。すべてを一つに統合しようとすると数年かかるので、まず対応表方式で始める。対応表は表計算で運用できる。

この二つは業務部門にしか決められない。技術部門に丸投げすると、既存システムの実装がそのまま定義になり、後から業務と食い違う。進め方としては、関係部署から一名ずつ集めた小さな会議を数回開き、その場で決めて文書化するのが速い。データを使いこなす人材の育成で述べた通り、この作業は人材育成としての効果も大きい。

7. 器の選び方——段階的に育てる

最初から大きな基盤を導入すると、載せるデータが揃う前に契約だけが走る。段階で考える。

第1段階を飛ばすべきではない。表計算で回してみると、必要な項目と不要な項目、更新の手間、見る人の有無が短期間で明らかになる。ここで得た知見が、第2段階以降の要件になる。

判断基準は単純である。手作業の負担が明確に痛くなってから、次の段階に進む。 痛みが出る前に投資すると、運用が定着しないまま器だけが残る。

8. ガバナンスの最小セット

厳格な規程を作ろうとすると時間がかかり、その間に現場は個別の判断で進んでしまう。まず次の五点だけ決める。

1. オーナー：データ種別ごとに責任部署を一つ決める
2. アクセス：誰が見られるか、誰が変更できるか
3. 持ち出し：外部サービス（生成AIを含む）に入力してよいデータの区分
4. 保存期間：いつまで持ち、いつ消すか
5. 記録：重要データの更新履歴を残す

③は特に急ぐ。区分が示されていないと、現場は「たぶん大丈夫」で判断するか、逆に何も使えないと諦めるかのどちらかになる。どちらも望ましくない。詳細は現場で使えるAIガバナンスで扱っているが、入れてよいデータの例と、入れてはいけないデータの例を数行ずつ書いた紙一枚があるだけで、現場の判断は大きく変わる。

9. 90日の始め方

90日の終わりに手元に残るのは、基盤ではなく判断材料である。何が足りず、それを埋めるのにいくらかかり、そのユースケースは成立するのか。ここまで来てから器の議論をすれば、見積は現実的な大きさに収まる。

10. 落とし穴

• 全社のデータを綺麗にしてから始める。 終わりが定義できず、途中で成果が出ないため予算が続かない。
• 器を先に買う。 載せるデータと見る人が揃う前に契約すると、運用が形骸化する。
• 意味の定義を技術部門に任せる。 業務定義は業務部門の仕事であり、委譲できない。
• 誰も見ないデータを整備する。 見られていないデータは必ず劣化する。整備と同時に、見る人と見る頻度を決める。
• 完全性を100%目指す。 欠損は扱う手段がある。優先すべきは一意性と適時性である。
• 稼働データの取得を契約に書かないまま導入する。 後から依頼すると有償の追加開発になる。
• 成果指標を決めずに進める。 何がどれだけ改善したら成功かを、ロボット導入のKPI設計の考え方で先に決めておく。

11. チェックリスト

• 最初のユースケースを一つに絞ったか
• 必要項目を10〜30に列挙し、四分類で仕分けたか
• マスタのIDを、正となる一つに決めたか（統合ではなく対応表でよい）
• データ辞書に「含まないもの」を書いたか
• 遡れる期間が、そのユースケースに足りるか確認したか
• 品質を6軸で評価し、一意性と適時性を優先したか
• 入力を作業の一部に組み込む業務設計にしたか
• 稼働データの取得権限を、契約書で確保しているか
• 外部サービスへの持ち出し基準を、紙一枚で示したか
• データ種別ごとにオーナー部署を決めたか
• 誰が、どの頻度でそのデータを見るか決めたか
• 器の導入判断を、手作業の負担が痛くなるまで保留したか

まとめ

AI活用の前提となるデータ基盤は、大きな投資から始まるものではない。実際に足りていないのは、多くの場合ストレージでも分析ツールでもなく、意味の定義とIDの一致という、費用のかからない部分である。ここを埋めないまま器に投資すると、揃わない数字が高価な画面に表示されるだけになる。

出発点は、ユースケースを一つに絞り、必要項目を列挙し、四分類で仕分け、データ辞書とID対応表を作ることである。90日あれば、投資判断に足る材料は揃う。順序を逆にした取り組み——全社整備を先に完成させようとした計画——が、どこで止まってきたかは、業界を見渡せば繰り返し確認できる。

一方で、この領域は自社の中だけで判断するのが難しい。どこまで整えれば十分なのか、他社は何から手を付けたのか、どのユースケースが実際に立ち上がり、どれが止まったのか。こうした情報は事例集には出てこない。うまくいかなかった話ほど、外には出ないからである。

RobiZyは、ユーザー企業・メーカー・SIer・運用事業者・自治体・大学が同席するNPO法人の会員組織である。特定の製品やサービスを売らない中立の立場だからこそ、整備の順序や見積の相場感、他社がどこでつまずいたかといった、通常は社外に出てこない情報が行き交う場になっている。データ基盤の整備は、正解が一つに決まらず、他社の実地の経験が最も効く領域である。関心のある方は、正会員としての参加をご検討いただきたい。