
データはある。なぜ、AIの検証を始められないのか?
AI活用の会議で、こんな返答があると、検証を始められそうに感じます。
「データはあります」
過去の問い合わせ履歴や営業日報、検査記録、契約書、議事録、顧客マスタ。業務の記録は、すでに社内に蓄積されています。
ところが、PoCを始めようとデータを確認すると、そのままでは使えないことが分かってきます。
ファイル形式や項目の定義が部署ごとに異なり、古いデータと新しいデータでは入力ルールも違います。正解を示すラベルが付いていないデータもあります。
個人情報や機密情報の扱いが曖昧なうえ、そもそも誰が管理責任を持つのか分からないこともあります。
ここで初めて、データがあることと、AIに使えることは違うと分かるのです。

保存されているだけで、業務の判断に使えるだろうか
AIテーマを選ぶときは、データがあるかどうかに加え、そのデータを使って、業務の判断を再現できるかまで確かめる必要があります。
問い合わせ履歴があっても、最終回答の良し悪しが分からなければ、回答品質は評価しにくくなります。営業日報も、商談の進み具合や受注結果と結びついていなければ、営業支援には使いにくいものです。
契約書が大量に残っていても同じです。どの条項を、どの基準で修正したかが記録されていなければ、レビュー支援に使える範囲には限界があります。
KPMGは、AIがパイロットから全社展開へ進む際、データ定義の不一致、データ所有、アクセス制御、系統管理が重要になると指摘しています。AIはデータの矛盾を魔法のように消してくれるわけではありません。むしろ、矛盾を増幅することがあります。
データ部門だけでは、データの意味は分からない
データ部門や情報システム部門(情シス)は、データの場所や形式、利用権限、システムとの連携方法を把握しています。一方、そのデータが業務上何を意味するかは、現場に聞かなければ分からないことも多くあります。
たとえば、ある項目が空欄なら、システム上は値が欠けている状態として扱われます。ところが現場では、「空欄の場合は通常パターンを意味する」という運用かもしれません。逆に、入力されている項目でも、現場では信用されていないデータかもしれません。
この違いは、データベースを見ただけでは分かりません。
AIを使う業務場面を選ぶときは、データ部門、事業部、情シスが一緒に、データ成立性を確認する必要があります。ここでいうデータ成立性とは、対象業務の判断に必要なデータを利用でき、AIの出力も評価できる状態かどうかです。
PoC前に見るべき5つのデータ確認
AIテーマをPoCに進める前に、少なくとも、次の5つを確認しておきます。

この5つを確認すると、データがどのような状態で使えるのか、具体的に判断できます。
特に見落とされやすいのは、評価可能性です。
AIに入力するデータがあっても、出力が正しいかどうかを判断するためのデータがない場合があります。この状態では、PoCの評価が担当者の感想にとどまりやすくなります。

データが足りないときは、先に何を整えるかを決める
必要なデータが十分に使えないからといって、そのテーマを諦める必要はありません。ただし、すぐにPoCへ進むのではなく、準備の仕方や検証する範囲を変える必要があります。
たとえば、次のような進め方があります。
データ整備テーマとして扱う
範囲を限定してPoCする
人手で評価データを作る
既存データではなくPoC中にデータを収集する
AIに任せる範囲を狭め、人の確認を厚くする
こうした進め方は、PoCが始まってからではなく、テーマを選ぶ段階で検討しておきます。
PoCが始まってからデータ問題が見つかると、スケジュールも期待値も崩れます。AIを検証するはずが、データの棚卸しに取り組むことになってしまいます。
それ自体は必要な仕事かもしれません。しかし、最初の目的と違うため、関係者の納得感が下がります。

データ成立性は、経営価値ともつながっている
データを使える状態にすることは、技術上の準備だけではありません。効果を確かめるまでの時間や、必要な投資にも関わります。
データが整っているテーマはPoCを早く進められ、効果測定や他部門への展開、本導入時の運用設計もしやすくなります。
データが弱いテーマは、AIの前に業務標準化や入力ルールの整備が必要になります。その場合、AI投資ではなく、データ基盤・業務基盤への投資として説明する必要があります。
ここを分けないと、経営会議で「なぜAI PoCなのに、データ整備費用が必要なのか」という話になります。
AIユースケース選定では、データ成立性を単なるチェック項目ではなく、テーマの進め方を決める判断材料として扱うべきです。
データ部門が最初に持つべき「使えるデータ」の定義
では、AI活用で「使えるデータ」と呼べるのは、どのような状態でしょうか。保存されているだけでなく、AIに入力できる形式になっていても、それだけでは十分とはいえません。
使えるデータとは、業務上の意味が説明でき、AIの入力として使え、出力の良し悪しを評価でき、本導入時にも権限と運用が成立するデータです。
この定義を持つと、データ確認の会話が変わります。
「データはありますか」ではなく、「この業務判断に必要な情報は、どのデータで再現できますか」と聞けるようになります。
データ確認会議の進め方
データ部門がAIユースケース選定に入るときは、次の順番で確認するとよいです。
まず、対象業務の判断場面を確認する
その判断に使われている情報を洗い出す
情報がどのシステム・ファイルに残っているかを見る
データの粒度、頻度、品質、欠損、表記ゆれを確認する
利用権限と本導入時の制約を確認する
AI出力を評価するための正解・参照情報があるかを見る
この順番で確認するのには、理由があります。最初からデータベースを見ると、業務判断との接続が弱くなります。最初に業務判断を見ることで、必要なデータと不要なデータが分かれます。
データ量に加えて、判断を再現できるかを確かめる
AIに必要なのは、量が多いだけのデータではなく、業務判断を再現できるデータです。必要なデータの所在、粒度、品質、権限、評価可能性を整理することが、PoC直前で止まるリスクを減らします。
データ部門が「今は無理」と言う前にできること
データ部門は、AIテーマに対して「データが整っていないので難しい」と言わざるを得ない場面があります。
ただ、その一言で終えると、事業部には次に何をすればよいかが伝わりません。例えば、次の三つの選択肢を示せば、進め方を一緒に考えられます。
一つ目は、範囲を狭めることです。全社データでは無理でも、一部署、一業務、一期間に絞れば使えるかもしれません。
二つ目は、人手で評価データを作ることです。最初から完全な正解データがなくても、PoC用に代表ケースを選び、専門家が評価する方法があります。
三つ目は、データ整備テーマとして切り出すことです。AI PoCではなく、業務データを標準化する取り組みとして経営に提案します。
こうした選択肢を示すことで、データ部門は、できるかどうかの判定に加えて、進め方の検討にも関われます。
データ確認でよくある落とし穴
データ確認でよくある落とし穴は、データ項目表だけを見て安心することです。
項目があることと、使えることは違います。入力率が低かったり、現場で信用されていなかったりする項目もあります。部署や時期によって意味が違う項目も、そのままAIに入力すると問題になります。
そのため、データを確認するときには、現場に次のように聞く必要があります。
「この項目は、実務で信用されていますか」
「この値が空欄のとき、現場ではどう解釈していますか」
「この分類は、誰がどの基準で入力していますか」
こうした質問によって、データの表面ではなく、業務上の意味が見えてきます。
データ確認の会議では、例えば次のように目的を共有してみます。
「データがあるかどうかではなく、この業務判断を再現できるデータかどうかを一緒に確認しましょう」
何の判断に使うかを共有すれば、データの棚卸しに加え、業務での使い方まで話し合えます。AIに使えるデータを判断するには、システムの中身だけでなく、現場がそのデータをどう意味づけているかを見なければなりません。
データ部門がこの役割を担えると、AIテーマは「できるか、できないか」の議論から、「どの条件なら進められるか」の議論に変わります。
データの有無に加え、業務判断の再現やAIの評価に使えるか、利用権限に問題はないかを確かめます。現場がデータの意味を説明できることや、本導入後も運用できることまで確認し、PoCへ進める状態かどうかを判断します。
データを確認することは、AIの材料を集めるだけの作業ではありません。本導入へ進める条件がそろっているかを確かめる、最初のステップなのです。
参考情報
AIの活用を、テーマ選びから実践へ
自社のどの業務にAIを活かすか。選んだテーマをどう実現し、現場で使い続けられるようにするか。
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium(アイブリウム)株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。