AIに投資して成果が出ない企業の共通点

McKinseyが2024年に発表したグローバル調査によると、AIから 有意義なROIを達成した企業はわずか11% にとどまります1。残り89%の企業は、ツールを導入したのに期待した成果を得られていません。

私はこの数字を見ても驚きませんでした。現場でデータ基盤の構築を手がけていると、「AIを入れたい」という相談の大半が、実はデータの問題だと気づくからです。モデルの精度が悪いのではありません。 そもそもモデルに渡すデータが「使える状態」になっていない のです。

Gartnerの調査でも、データ品質の低さが原因でAIプロジェクトの成果が損なわれていると、データ責任者の約6割が回答しています2。問題の根はモデル側ではなく、データ側にあります。

AI Readyなデータとは何か

「AI Ready」という言葉は曖昧に使われがちですが、私たちは5つの条件で定義しています。データがどこまで整っているかを、この段階で確認してください。

レベル条件具体例
Lv.1 構造化行と列がある。機械が読める形式BigQueryテーブル、CSV
Lv.2 品質管理欠損・重複・矛盾がないdbt testsによるバリデーション
Lv.3 文書化カラムの意味、単位、更新頻度が明記sales_amount_yen vs col1
Lv.4 アクセス可能SQLやAPIで即座に取得できるMetabase、REST API
Lv.5 鮮度保証定期的に更新され、最新性が担保日次/時間次の自動同期

多くの組織はLv.1すら満たせていません。共有フォルダの奥にあるExcelファイル、メール添付のPDF、「あの人のPCにしかない」データ。こうした状態でAIツールを導入しても、 出てくるのは「もっともらしいが間違った分析」 だけです。そもそもデータをどこに集約するのかという土台については、 データウェアハウスって結局何なの？ で整理しています。

データが「使える」までの5段階

データがAI Readyになるまでには、明確なレイヤー構造があります。

AI Readinessスタック: Raw DataからAI Readyまでの5段階

このスタックを下から積み上げることが、 AIプロジェクトの成功率を根本的に変えます 。Lv.0からいきなりLv.5を目指すのは無理があります。私は一段ずつ確実に上がることが重要だと考えています。

よくある4つの失敗パターン

私が現場で繰り返し目にする失敗を整理します。

データ整備の前にAIツールを購入する

これが最も多い失敗です。高額なAIプラットフォームを契約したものの、データがバラバラでそもそも投入できません。結果として、AIツールは高価な置物になります。

「データが多い = AIが賢くなる」と思い込む

データは 量より質 が決定的に重要です。矛盾したデータ、重複したレコード、定義が曖昧なカラム。こうしたノイズをAIは「学習」してしまい、出力の信頼性が崩壊します。

AIの出力を無条件に信じる

入力データに問題があれば、AIは 自信に満ちた誤りを生成します 。いわゆる「ハルシネーション」はLLMだけの問題ではありません。ビジネスデータの文脈でも同じことが起きます。売上データに二重計上があれば、AIは「売上が好調です」と自信を持って報告するでしょう。元データの品質を知らないまま出力を鵜呑みにするのは危険です。

機密データを外部AIサービスに送信する

ガバナンスのないままChatGPTやClaudeに社内データを貼り付けている組織は少なくありません。データ分類と利用ポリシーの整備が先です。

AIは「壊れたデータ」を直せない

改めて強調します。 AIはデータ品質の問題を解決しません 。入力がゴミなら、出力は「もっともらしく聞こえるゴミ」になるだけです。

GoogleのDORA（DevOps Research and Assessment）チームの研究でも、データ駆動型の意思決定で成果を上げている組織は、データの信頼性とアクセス性を先に確保していることが示されています3。AIは手段であり、 信頼できるデータという土台がなければ機能しません 。

実践的なアーキテクチャ

私たちが実際に構築しているパイプラインを紹介します。これは流行りのツールを並べたものではなく、AI Readinessの各レベルに対応させた設計です。

実践パイプライン: BigQuery → dbt → Metabase → NotebookLM

なぜこの構成なのか

  • BigQuery: スケーラブルで、SQLさえ書ければ誰でもアクセスできます。DWHの選び方は BigQueryとSnowflakeの違い で比較しています
  • dbt: SQLベースでデータ変換とテストを一元管理でき、 schema.yml でカラムの意味を文書化できます。壊れないデータ基盤を作る考え方は dbtで壊れないデータ基盤をつくる にまとめました
  • Metabase: ノーコードでダッシュボードを作成でき、JSON形式でのエクスポートがAI連携と相性が良いです
  • NotebookLM: 構造化されたJSONを投入すれば、データの傾向分析や要約を高精度で返します

ポイントは、 各ツールがAI Readinessのレベルに対応している ことです。場当たり的にツールを入れるのではなく、レベルを一段ずつ上げるために選定しています。

まず足元を固める

AI活用の議論をすると、モデルの選定やプロンプトの工夫に話が集中しがちです。しかし現実には、 議論の8割は「データをどう整理するか」 で決着がつきます。

地味ですが、これが本質です。データが整っていれば、AIツールの選択肢は広がり、成果も出やすくなります。データが整っていなければ、どんな高価なAIも機能しません。

Footnotes

  1. McKinsey & Company「The state of AI in early 2024」- AIから有意義なROIを達成した企業は全体の11%にとどまると報告 ↩

  2. Gartner「Data Quality Market Guide」- データ品質の低さがAI/アナリティクスの成果を損なっているとCDOの約6割が回答 ↩

  3. Google Cloud DORA Team「Accelerate State of DevOps Report」- データ駆動型組織のパフォーマンス要因を継続的に研究 ↩