データ基盤とAI活用の前提

工数の大半はここに消える

AI導入の工数の内訳を後から集計すると、多くの案件でモデルに関わる作業は全体の1〜2割にとどまります。残りはデータの準備と接続です。

この構造は珍しいことではありません。統計的な分析でも、機械学習でも、同じ傾向が長年観察されてきました。にもかかわらず見積もりでは繰り返し軽視されます。理由は、データの問題が着手するまで見えないことにあります。

本章では、着手前に確認すべきデータ側の条件を扱います。第7章(DXの進め方)は「データがない状態からどう作るか」を扱いますが、本章は「あるデータが使える状態かどうか」を判定する視点です。

データ品質 ― 何が「汚れている」のか

データ品質の問題は抽象的に語られがちなので、実際に現れる形を具体的に挙げます。

欠損

値が入っていない状態です。問題は欠損の存在ではなく、欠損が何を意味するかが記録されていないことです。「0」なのか「未入力」なのか「該当なし」なのかが区別できないと、集計も予測も誤ります。

実務では、欠損の意味を業務担当者に確認する作業が必要です。「この列が空欄のときは電話確認している」という運用が判明することがあり、その場合、空欄自体が業務上の情報を持っています。

表記ゆれ

同じものが違う表記で入っている状態です。企業名(株式会社の位置、全角半角、旧社名)、商品名(型番の表記、スペースの有無)、地名、部署名。集計が合わない原因の大半はこれです。

AIによる名寄せ(同一のものを突き合わせる作業)は有効ですが、判定を任せきりにはできません。似ているが別物である場合があるためです。実務では、AIが候補を出し、人が確認して対応表を作る形が現実的です。作った対応表は資産として保守します。

ノイズと外れ値

入力ミス、テスト用データの混入、単位の違い(kgとg、円と千円)。これらは統計値を大きく歪めます。特に単位の混在は、平均値を見ただけでは気づきにくく、予測の精度を静かに落とします。

重複

同じ取引が複数回記録されている状態です。システム統合や再取り込みの際に発生します。件数を数える処理では致命的です。

「使えるかどうか」の判定手順

着手前に、次の作業を行えば大部分が判明します。所要時間は数日です。

1. 対象データを実際に数百件〜数千件、そのまま目で見る
2. 列ごとに、欠損の割合と、値の種類の数を数える
3. 主要な項目(顧客名、商品名、日付)の表記の種類を一覧にする
4. 期間の連続性を確認する(途中でシステムが変わっていないか、コード体系が改訂されていないか)
5. 業務担当者に、各列が実際にどう入力されているかを確認する

4番目が最も見落とされます。システム移行やコード改訂をまたぐデータは、見た目が同じでも連続していません。予測の学習には使えない、あるいは変換が必要になります。

データガバナンスとカタログ整備

データが使える状態にあるかとは別に、誰がそのデータについて決める権限を持つかという問題があります。

データオーナーを決める

各データについて、次を決めておく必要があります。

• 誰が正しさに責任を持つか(オーナー)
• 誰が使ってよいか(利用権限の範囲)
• 定義は何か(「売上」がどの時点・どの範囲を指すか)
• 更新の頻度と方法

これが決まっていない状態でAI活用を始めると、部署間で異なる数字が並立します。第15章で扱う「経営層と現場の数字が合わない」という問題の技術的な根はここにあります。

データカタログ

社内にどのようなデータがあり、どこにあり、誰が持っているかの一覧です。整備の効果は、AI活用の前段だけではありません。問い合わせと調査の時間が大きく減ります。

最初から網羅的なカタログを作る必要はありません。着手する業務に関係するデータから始め、使うたびに追記する形で十分機能します。

データパイプラインの設計

データを収集し、整え、保管し、更新し続ける仕組みです。設計時に決めるべき項目を挙げます。

この表の「検証」の行が、実務では最も効果があります。入力データの件数と欠損率を毎回記録し、前回と比べて大きく変わったら通知するだけの仕組みで、多くの事故を早期に検知できます。

構造化データと非構造化データ

扱い方が根本的に違うため、区別して考える必要があります。

非構造化データで最も手間がかかるのは版の特定です。同じ規程の新旧版が両方保存されていると、AIは古い方を根拠に答えることがあります。技術的な対処(日付での絞り込みなど)は可能ですが、根本的には「現行版はこれ」と決める運用が必要です。

データレイクとデータウェアハウス

用語として混同されやすいので、役割の違いを整理します。

• データウェアハウス ― 用途を決めて整えたデータを、集計・分析しやすい形で保管する場所。構造が決まっているため、使うときの手間が小さい。
• データレイク ― 生のデータを、形式を問わずそのまま蓄積する場所。用途が決まっていない段階でも保存できるが、使うときに整える作業が必要。

AI活用の文脈では、両方が必要になることが多いです。非構造化データ(文書、画像、音声)はレイクに、集計・予測に使う構造化データはウェアハウスに置く構成が一般的です。

ただし注意点があります。「とりあえずレイクに入れる」という方針は、整備の作業を後回しにしているだけです。保存しても、何がどこにあるかが分からなければ使えません。カタログの整備とセットで進める必要があります。

マスターデータ管理と部門間連携

顧客、商品、取引先、組織といった基本情報が、部署ごとに別々に管理されている状態は、AI活用の最大の障壁になります。

典型的な症状は次のとおりです。

• 同じ顧客が、営業システムと請求システムで別のIDになっている
• 商品の分類が、販売と生産で違う体系になっている
• 組織の階層が、人事システムと権限管理で一致していない

この状態では、データを横断した分析ができません。対処は統合ですが、全面統合は大きな投資になります。実務的な進め方は、対応表(どのIDがどのIDに対応するか)を作って維持することです。統合より安く、多くの用途はこれで足ります。

データの鮮度・更新頻度の設計

どの程度新しいデータが必要かは、用途によって違います。ここを過剰に設計すると費用が膨らみます。

設計の順序は、業務側の判断タイミングから逆算することです。「リアルタイムで」という要望は、実際には「翌朝までに」で足りる場合が多くあります。

個人情報の匿名化・仮名化

個人に関する情報をAIの学習や処理に使う場合、識別性を下げる技術的な手法があります。ただし技術的な処理を行っても、法令上の取り扱いが自動的に変わるわけではありません。法的な位置づけは、処理の内容と復元可能性によって判断されるため、必ず法務部門と個人情報保護委員会などが公開する一次情報を確認してください(第19章)。

技術的な考え方として押さえておくべきものを挙げます。

• 直接識別情報の削除 ― 氏名、住所、電話番号、メールアドレス、個人を識別できる番号の除去。最も基本ですが、これだけでは特定できる場合があります。
• 組み合わせによる特定のリスク ― 生年月日、郵便番号、性別の3項目だけでも、条件によっては個人が絞り込めます。「同じ属性の人が一定人数以上いる状態を保つ」という考え方(k-匿名性)がここから来ています。
• 仮名化 ― 識別子を別の記号に置き換える方法。対応表を保持すれば復元できるため、対応表の管理が要点になります。
• 集約 ― 個人単位ではなく、地域・年代などの集団単位に丸める方法。分析用途では有効です。

実務では、そもそも個人を識別する情報を送らない設計が最も確実です。要約や分類の用途では、氏名や連絡先を除去しても目的が達成できる場合が多くあります。送信する項目を必要最小限に絞る設計を最初に検討してください(第4章)。

着手前チェックリスト

本章の内容を、判定に使える形にまとめます。

1. 対象データを実際に数百件見た(サンプルではなく実データ)
2. 列ごとの欠損率と値の種類数を数えた
3. 主要項目の表記のゆれを一覧にした
4. 期間の連続性を確認した(システム移行・コード改訂の有無)
5. 各列が業務上どう入力されているかを担当者に確認した
6. データオーナーと利用権限が決まっている
7. 「売上」「顧客」などの定義が部署間で一致している
8. 必要な鮮度を業務の判断タイミングから逆算した
9. 個人を識別する情報を送らずに目的が達成できるかを検討した
10. データ取得が失敗したときに気づく仕組みがある

この10項目のうち答えられない数が、そのまま着手前に必要な調査工数の目安になります。