データの準備：ほとんどのAIプロジェクトが見落とす前提条件

Priyaの話をしましょう。彼女は120名規模のB2Bサービス企業を経営しています。収益は安定しており、チームは4年間にわたって着実に成長してきました。

6ヶ月前、彼女は6万ドルのパイロットプロジェクトを承認しました。2021年から営業チームが使っているCRMに統合された、予測型リードスコアリングツールの導入です。ベンダーは自信満々で、デモも印象的でした。

ところが3ヶ月後、スコアがランダムな印象を与えるようになりました。担当者たちはスコアを信頼しなくなり、自社の最有望顧客2社が低優先度と判定され、何十もの冷たいコンタクトが「ホット」と表示される理由を誰も説明できませんでした。ベンダーのサポートチームがセットアップを確認した後、契約前には見たことのなかったデータ完全性要件に関する2ページの文書を送ってきました。

AIが壊れていたのではありません。データが問題でした。

Gartnerによれば、2026年までに企業はAIプロジェクトの60%をデータの準備不足を理由に断念するとされています。モデルの品質が原因ではありません。チームのスキルでも、技術の成熟度でもありません。データが準備できていないのです。

これは地味で退屈に見えるため、多くのチームが省略してしまう前提条件です。しかし、その結果は致命的です。

この記事はPriyaのために、そしてAIツールにこれ以上のお金を使う前に自社のデータが準備できているかを確認したい、すべての創業者、オペレーション責任者、部門長のために書きました。

データの準備とは何か

「データの準備」とは完璧なデータを意味しません。使いたい特定のAI Capabilityに対して十分に機能するデータのことを指します。

より具体的に言えば、AI活用のために見つけられる、アクセスできる、構造化されている、最新である、そして許可されているデータのことです。

• 見つけられる：データがどこにあるか把握しており、数週間のプロジェクトなしにアクセスできる
• アクセスできる：AIツールがAPI、エクスポート、またはネイティブコネクターで読み取れる
• 構造化されている：モデルがパターンを学習できるだけのスキーマと一貫性がある
• 最新である：2年前の状況ではなく、現在の実態を反映している
• 許可されている：法務、セキュリティ、コンプライアンスがAI利用を承認している

多くのチームは、これらのうち1つか2つが弱いことに気づきます。それだけでパイロットは失敗します。

5つの失敗パターン

データが準備できていない状態を知ることは、準備できている状態を知ること以上に実行可能です。モデルが機能する前にAIプロジェクトを終わらせてしまう5つの失敗パターンを紹介します。

失敗パターン1：サイロ化したデータ

CRMには取引履歴があるのに、サポートチケットは確認できない。マーケティングプラットフォームは見込み客がダウンロードしたコンテンツをすべて把握しているのに、営業ツールからは見えない。財務システムには3年分の支払い履歴があるのに、カスタマーサクセスプラットフォームはどのアカウントが60日延滞しているか把握していない。

これは中堅企業で最もよく見られる失敗パターンで、連携したデータに依存するものを構築しようとするまで気づかれません。Ingest Capabilityは1つのシステムからデータを取得できます。しかし、AIが顧客の全体像（購入履歴、サポート対応、メールエンゲージメント、更新シグナル）を把握する必要がある場合、それらのシステムが相互に連携している必要があります。

通常、それは実現されていません。AIツールを購入した後ではなく、購入前に行う必要のある、本格的な統合作業なしには無理です。

失敗パターン2：スキーマのない非構造化フィールド

CRMには「メモ」フィールドがあります。サポートプラットフォーム、プロジェクト管理ツール、管理用スプレッドシートにも同様のフィールドがあります。担当者ごとに使い方が違います。何段落も書く人もいれば、何も書かない人もいます。「電話、留守電」と書く人もいれば、「2/14：J.Chenと通話、興味あり、CFO承認が必要、予算約4万ドル、Q2のタイミング」と詳細に書く人もいます。

スキーマのない自由記述フィールドは、パターンを学習するAIにとってほとんど役に立ちません。Analyze Capabilityは非構造化テキストからシグナルを抽出できますが、それにはシグナルとノイズを区別できるだけの量と一貫性が必要です。チームはツールを統合した後になって初めてこの問題に気づくことが多いです。モデルの出力がおかしく感じられますが、モデルは不整合な入力に対して最善を尽くしているだけです。

失敗パターン3：レコードのコンテキスト不足

データベースにレコードは存在するが、そのレコードに意味を与えるフィールドが欠けている。

CRMには8,000件の企業レコードがあるが、40%には業種タグがない。4年分の取引履歴があるが、受注・失注の理由が必須入力になったのは18ヶ月前からだ。

Predict Capabilityでリードスコアリングモデルを構築する場合、これらの欠損フィールドは小さな不便ではありません。それらはトレーニングシグナルそのものです。入力に成果が結びついていなければ、意味のある予測モデルを訓練することはできません。コンテキストはつなぎ目の組織です。それがないレコードは、意味のないデータポイントに過ぎません。

失敗パターン4：データ品質の問題

重複。タイポ。古くなったエントリ。同じ大企業アカウントが7種類の綴りで登録された「企業名」フィールド。担当者が更新を忘れたために変わらなかった商談ステージ。

品質の問題はモデルを診断が難しい形で混乱させます。不整合な参照資料を与えられたGenerate Capabilityは、不整合なドラフトを生成します。重複レコードで訓練されたリードスコアリングモデルは、それらが複数回出現するために特定の特徴を過大評価します。古い基準データから学習した異常検知ツールは、正常な行動を異常としてフラグします。出力がおかしく感じられますが、問題はモデルではありません。入力が問題なのです。

失敗パターン5：アクセスが制限されたデータ

データは存在します。それほど汚れてもいない。人間はアクセスできる。しかし、法務またはセキュリティチームがAIツールへの入力を禁じるポリシーを持っている。

「ChatGPTに個人情報を入れない」は合理的なポリシーです。しかし、AIが必要とするデータに顧客の名前、メールアドレス、または個人に紐づいた行動データが含まれている場合、そのポリシーはユースケース全体をブロックする可能性があります。メールを自動送信するExecute Capabilityには連絡先情報が必要です。サポートトリアージツールはチケットの内容を読む必要があります。文書レビューツールには文書が必要です。

パイロットを始める前に、ツールに入力するデータが法的にクリアされ、ポリシーとして文書化されているかどうかを確認してください。その会話はパイロットの後ではなく、前に行う必要があります。

5つの質問による監査

この監査を実施するためにデータサイエンスチームは必要ありません。自社のシステムを熟知した人と30分あれば十分です。

質問1：今日、ITに頼らずにAIが必要とするデータをダウンロードできるか？ できないなら、AIツールが何か有用なことをする前に解決すべきアクセス依存関係があります。

質問2：すべてのレコードにAIが必要とするフィールドがあるか、それとも40%がnullか？ ランダムに100件のレコードを取得してください。主要フィールドの20〜30%以上が空または明らかに誤っている場合、完全性の問題があります。

質問3：データは現在の実態を反映するほど最新か？ リードスコアリングには過去12〜18ヶ月の取引データが必要です。クリーンなデータが2年前のものであり、営業プロセスが18ヶ月前に変更されている場合、モデルは古いプロセスを学習します。

質問4：唯一の権威ある情報源があるか、それとも4つの矛盾するバージョンがあるか？ 「CRMが真実の情報源だが、営業はスプレッドシートを持っており、財務はERPに異なる数字を持っている」というのは一貫性の問題です。AIは競合するソースを調整できません。どのシステムが正しいかを誰かが決める必要があります。

質問5：法務またはセキュリティが、このデータをAIツールに入力することに関するポリシーを持っているか？ 明示的に確認してください。多くの中堅企業では、AIデータポリシーはまだ書かれていません。後ではなく、先に作成してください。

5つすべてに明確に答えられれば、データは開始できるほど準備が整っています。2つ以上が懸念される場合、そこにAI前の投資を向けるべきです。

データ準備ピラミッド

データの準備を5段階のピラミッドとして考えてください。多くのチームは、上位段階が価値をもたらす前に下から登る必要があります。

AIプロジェクトを始める多くの中堅企業は、第1段階か第2段階の途中にいます。それで構いません。第1段階や第2段階でもAIの作業は始められます。しかし、どの段階にいるかを把握している必要があります。なぜなら、展開できるCapabilityはその段階に依存するからです。

第1段階のチームは、比較的クリーンなテキストや構造化レコードからAnalyzeワークフローを実行し、ドキュメントや音声を使用可能な形式にするIngestを試すことができます。本格的なPredictワークフローはまだ実行できません。それには第3段階（ラベル付き履歴データ）が必要です。

第3段階にいるチームが第4段階を完了していない場合、ベンダー監査が入った瞬間にAIワークフローを停止せざるを得ない状況になります。ガバナンスは「あれば良い」ものではありません。ポリシーが追いつく前にスケールできる基盤です。

第5段階は、時間が経ってもAI価値を維持するチームと、パイロットが静かに劣化するチームを分けるものです。観測可能性とは、フィールドがnullになる、重複レコードが蓄積する、データの新鮮度が低下するといった品質低下を検知する仕組みが整っていることを意味します。それなしでは、6ヶ月前に機能していたモデルが今は誤った結果を出していても、担当者が解約済みのアカウントに電話するまで気づかないでしょう。

ACE Capability別の最低限の準備要件

すべてのCapabilityが同じデータ基盤を必要とするわけではありません。5つのCapabilityそれぞれの最低要件を示します。

このテーブルは順序付けに実用的です。クリーンなCRMデータはあるが履歴ラベルがない場合、PredictではなくAnalyzeとGenerateから始めましょう。低リスクなCapabilityを実行しながら、ラベリングの習慣を築いてください。12〜18ヶ月分のラベル付き成果が蓄積されたとき、Predictが手の届く範囲に入ります。

データが準備できていない場合の対処法

多くのチームはこの状況にいます。実際に機能するアプローチを紹介します。

最も準備が整っている1つのシステムから始める。 ほとんどの企業には、他よりクリーンなデータソースが1つあります。サポートチケットシステムはCRMより雑然としているかもしれませんが、CRMが成果付きで3年分のクリーンな取引履歴を持っているなら、そこからAI作業を始めましょう。最も望ましいユースケースではなく、最も強いデータに合ったユースケースを選んでください。

最初にIngestとAnalyzeを実行する。 これらは外部の状態を変えずに洞察を生み出す、読み取り専用のCapabilityです。PredictやExecuteの前にそれらを実行することで、より高度なCapabilityに向けてデータ品質を改善しながら価値を生み出せます。

モデルが必要になる前にラベリングの習慣を築く。 12ヶ月後にリードスコアリングが欲しければ、今日からCRMで受注・失注理由フィールドを必須入力にしましょう。準備が整ったとき、ラベルはすでに存在します。

独自のベースラインを持つベンダーAIを検討する。 Salesforce Einstein、HubSpotの予測スコアリング、Gongなどの製品は、自社データを追加する前から一定のシグナルを持つ事前訓練済みモデルを提供しており、小規模チームのコールドスタートのハンデを軽減します。

競争上の優位性としてのデータ準備

これは、苦労しているパイロットの只中にいるときには明らかではない部分です。

地味な統合作業（CRMのクレンジング、必須フィールドの徹底、システムの連携、データポリシーの文書化）を行うチームは、モデルの改善では消えない優位性を築いています。

モデルの品質はコモディティです。OpenAI、Anthropic、Googleはより優れたモデルを提供するために競争しています。18ヶ月後には、APIでアクセスできるモデルは今日よりはるかに高性能になるでしょう。しかし、汚れたサイロ化したデータに入力されたより優れたモデルは、依然として汚れた結果を生み出します。

次の3年間でAI競争に勝つ企業は、必ずしも最新モデルを最も早く採用した企業ではありません。モデルを機能させるデータ基盤を構築した企業です。クリーンなデータと基本的なモデルは、最新モデルと乱雑なデータをほぼ常に上回ります。

AIプロジェクトを成功させる地道な作業

AIパイロットが実際に価値を生み出すかどうかを決定する、地味なタスクを紹介します。

• AIツールを接続する前にCRMの連絡先とアカウントの重複を排除する
• 取引レコードで受注・失注理由を必須フィールドにする（可能なら12ヶ月分バックフィルする）
• 最も重要な自由記述フィールドを監査する：担当者は入力しているか？一貫しているか？
• データフローをマッピングする：主要システムのそれぞれで何が入り、何が出るか
• ベンダー契約に署名する前に、法務またはセキュリティチームにAIデータ使用ポリシーを書いてもらう
• 各主要データタイプ（顧客レコード、取引履歴、サポートチケット）の権威ある真実の情報源を特定する
• 監視の習慣を築く：誰が毎月データ品質をレビューし、何を確認するか？

これらは技術的に複雑なものではありません。すべてに、実際に実行するための継続的な組織的意志が必要です。それが多くのチームがこの作業を省略する本当の理由です。退屈で、時間がかかり、「AI」に感じられません。しかし、それはAIプログラムにおいて最も重要な作業です。

次に読む記事

ACE FrameworkはここでカバーしたData Foundationから構築されます。

• 7種類のデータ：AIワークフローが消費するデータの種類
• あなたのAIは壊れていない：本番環境でのデータ品質問題の診断
• ACE Framework：データを基盤とした6層スタック全体
• Ingest：最初のCapability、そしてデータアクセスと最も直接的に結びついているもの
• ほとんどのAIフレームワークが失敗する理由：ほとんどのフレームワークがデータ問題について見落としていること

地道な作業が輝かしい成果に勝ります。データを正しく整えれば、AIはあなたを驚かせるでしょう。省略すれば、モデルが「壊れている」のに実は正常に動作しているという状況で、6ヶ月を過ごすことになります。