RAG・AI検索

Databricks Genie Oneに見る、データ基盤がない会社のAIエージェント導入が失敗する理由

2026年6月16日18分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

5分で自社の状況を診断する

GXO COLUMN

AI・自動化

結論：AIエージェントは「社内データの意味」を知らないと業務に使えない

2026年6月17日、WSJはDatabricksが企業向けAIエージェント「Genie One」を発表したと報じた。財務、マーケティング、営業などの業務部門が、自社データを使って分析や意思決定を進めるための「agentic co-workers」と位置づけられている。

このニュースの本質は、AIエージェントの新製品紹介ではない。企業AIの主戦場が、チャット画面からデータ文脈・権限・業務定義へ移っている という点である。

社内データが部門ごとに分断され、商品コード、顧客コード、粗利定義、案件ステータスが揃っていない会社では、AIエージェントを入れても「それらしい回答」はできても「業務判断」はできない。

AI ASSESSMENT

PoC の前に「そもそも使えるか」を30分で見極めませんか？

対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。

30分壁打ちを予約

AIエージェント導入前に整えるべきデータ

横にスクロールして確認できます

項目	整っている状態	未整備だと起きること
マスタ	顧客、商品、拠点、担当者の定義が統一	AIが別部門の数字を混ぜる
指標定義	売上、粗利、在庫、案件確度が明確	部門ごとに答えが違う
権限	利用者ごとに見えるデータを制御	AIが見せてはいけない情報を返す
更新頻度	日次・週次・月次の違いを管理	古い数字で判断する
出典	AI回答の根拠データを追える	経営会議で説明できない

AIエージェントが業務部門に広がるほど、データ基盤は「情シスの裏方」ではなく、AI活用の前提条件になる。

中堅企業が最初に作るべき構成

いきなりDatabricks級の全社基盤を作る必要はない。まずは次のような小さな構成で始めるとよい。

横にスクロールして確認できます

段階	実装すること	成果
1	販売管理、会計、CRM、在庫のデータを集約	同じ数字を見る
2	BIで売上、粗利、在庫、案件を可視化	経営判断を早める
3	RAG/AI検索でデータと文書を横断検索	担当者の確認時間を減らす
4	AIエージェントに分析・要約・提案を任せる	業務部門の判断支援へ進む

重要なのは、AIを先に作らないことだ。AIが参照するデータ、指標、権限、ログを整えてからAIエージェントへ進む方が、PoCで終わりにくい。

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

この記事の要点

AIエージェント導入の前に「社内データの意味」を揃える
データ基盤がない会社では、AIは業務判断ではなく文章生成で止まりやすい
BI、RAG、AIエージェントは別物ではなく段階導入で考える
業務部門がAIを使う時代ほど、情シスのデータ設計が重要になる

保存用チェックリスト

横にスクロールして確認できます

チェック	確認項目
□	顧客・商品・拠点・担当者マスタが統一されている
□	売上・粗利・在庫・案件確度の定義が文書化されている
□	部署・役職・担当範囲ごとに閲覧権限を制御できる
□	AI回答の根拠データと更新日時を追跡できる
□	BIで見ている数字とAIが参照する数字が同じ
□	データオーナーと更新責任者が決まっている

90日ロードマップ

横にスクロールして確認できます

期間	実施内容	成果物
1〜30日	販売、会計、CRM、在庫のデータ所在を棚卸し	データマップ、マスタ課題一覧
31〜60日	売上、粗利、案件、在庫の指標定義を統一	指標辞書、権限一覧
61〜90日	BIとAI検索の小さな業務範囲で検証	初期ダッシュボード、AI回答評価表

RFPに入れるべき項目

横にスクロールして確認できます

項目	書くべき内容
対象データ	販売、会計、CRM、在庫、問い合わせ、文書
指標定義	売上、粗利、在庫、案件確度、顧客ランク
権限	部署、役職、担当顧客、機密区分
AI連携	RAG、自然言語BI、AIエージェントの範囲
ログ	参照データ、回答、出典、利用者、実行結果
運用	データ更新、指標変更、権限変更、回答レビュー

費用感・KPIの目安

導入を社内で検討するには、説明できる数字まで置いておくと話が進めやすい。初期相談でよく使う目安は次の通りである。

横にスクロールして確認できます

導入範囲	期間目安	費用レンジ	判断KPI
現状診断・データ棚卸し	2〜4週間	30万〜120万円	対象データ、権限、課題一覧を作れるか
小規模PoC	1〜2か月	150万〜500万円	1業務で20〜30%の確認時間削減
MVP開発	3〜4か月	500万〜1,500万円	月100〜300時間の削減、利用継続率60%以上
本番展開	4〜8か月	1,500万〜5,000万円	3部門以上で利用、月次改善サイクル定着

この数字は確定見積ではなく、社内稟議の初期レンジである。重要なのは、開発費だけでなく、月額運用費、クラウド費、AI API費、改善保守費を分けることだ。特にAIエージェント、BI、データ基盤は作って終わりではなく、データ更新、権限変更、プロンプト・評価改善が毎月発生する。

相談前に整理しておく項目

対象業務は月何件あり、1件あたり何分かかっているか
利用者は何部門・何名か
既存システムは何個あり、API連携できるか
個人情報、契約情報、ソースコードなど機密データを扱うか
PoC成功条件を精度、時間削減、費用削減のどれで見るか
初期予算と月額運用予算を分けて考えられているか

これらが整理されているほど、初回相談で概算費用、優先順位、ロードマップを出しやすくなる。

90日で実装判断へ進めるロードマップ

検討を情報収集で終わらせず、要件定義まで進めるには、90日で「何を決めるか」を先に固定する必要があります。特にAIエージェント、データ基盤、クラウド、セキュリティ、レガシーシステム刷新が絡む案件では、情報収集のまま30日以上止まると、PoC費用だけが先行しやすくなります。

横にスクロールして確認できます

期間	この期間で決めること	成果物	失敗しやすいポイント
1〜7日	経営課題、対象業務、既存システム、利用データを棚卸しする	現状整理シート、業務フロー、システム構成図	AI導入やDX推進が目的化し、売上・粗利・工数・リスクのどれを改善するか曖昧になる
8〜30日	RFP、要件定義、概算費用、セキュリティ条件をそろえる	RFPドラフト、要件一覧、概算見積、リスク台帳	ベンダー選定を価格比較だけで進め、権限、監査ログ、データ所在、保守体制が抜ける
31〜60日	PoCまたはMVPの範囲を最小化する	PoC計画、KPI、検証データ、受入基準	精度や画面の見栄えだけを見て、本番運用、既存API連携、障害時対応を確認しない
61〜90日	本番化、段階移行、運用改善の判断を行う	導入ロードマップ、体制表、運用設計、稟議資料	レガシー刷新や基幹連携の影響を後回しにし、追加費用と納期遅延が発生する

GXOへの相談では、初回から完成したRFPを用意する必要はありません。むしろ、現行Excel、販売管理、CRM、ERP、WMS、会計、問い合わせ管理などのどこにデータがあり、誰が更新し、どの判断に使えていないかを30分で確認できる状態の方が、相談の質は上がります。初回相談のゴールは「発注するか」ではなく、150万円のPoCで足りるのか、500万円以上のMVPにすべきか、1,500万円以上の段階刷新として扱うべきかを切り分けることです。

GXOに相談すべきケース

Databricks、Snowflake、BigQueryなどのデータ基盤を検討している
AIエージェントを入れたいが、販売・会計・CRM・在庫データが分断されている
BIやRAGを作ったが、経営・営業・現場で使われていない

GXOでは、データ活用基盤、AIエージェント開発、DX・システム開発を組み合わせ、AIが使えるデータ基盤と業務導線を設計する。 → 相談はこちら

参考資料

Wall Street Journal "Databricks Releases General AI Agents for Businesses" https://www.wsj.com/cio-journal/databricks-releases-general-ai-agents-for-businesses-abffb409
Databricks "Data Intelligence Platform" https://www.databricks.com/product/data-intelligence-platform

AIエージェント導入前に、データ基盤を点検しませんか

GXOでは、販売・会計・CRM・在庫データの統合、BI、RAG、AIエージェント化まで段階的に設計します。

データ基盤・AI活用を相談する

相談前に取得しておくと早い情報

相談前に、会社名、部署、役職、業種、従業員規模、対象業務、既存システム、現在の課題、検討予算、希望時期、セキュリティ制約、補助金利用予定の12項目を整理しておくと早い。ここまで整理できていれば、初回面談では会社説明に時間を使わず、現状システムの棚卸し、API連携、データ移行、権限管理、運用保守、費用対効果の議論に入れます。

GXO実務追記: AI開発・生成AI導入で発注前に確認すべきこと

この記事のテーマは、単なるトレンド紹介ではなく、業務選定、データ整備、セキュリティ、PoCから本番化までの条件を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。

まず決めるべき3つの論点

横にスクロールして確認できます

論点	確認する内容	未整理のまま進めた場合のリスク
目的	売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか	成果指標が曖昧になり、PoCや開発が終わっても投資判断できない
範囲	対象部署、対象業務、対象データ、対象システムをどこまで含めるか	見積もりが膨らむ、または重要な連携が後から漏れる
体制	自社責任者、現場担当、ベンダー、保守運用者をどう置くか	要件確認が遅れ、納期遅延や品質低下につながる

費用・期間・体制の目安

横にスクロールして確認できます

フェーズ	期間目安	主な成果物	GXOが見るポイント
事前診断	1〜2週間	課題整理、現行確認、投資判断メモ	目的と範囲が商談前に整理されているか
要件定義 / 設計	3〜6週間	要件一覧、RFP、概算見積、ロードマップ	見積比較できる粒度になっているか
PoC / MVP	1〜3ヶ月	検証環境、効果測定、リスク評価	本番化判断に必要な数値が取れるか
本番導入	3〜6ヶ月	本番環境、運用設計、教育、改善計画	導入後の運用責任と改善サイクルがあるか

発注前チェックリスト

AIで置き換える業務ではなく、成果が測れる業務を選んだか
参照データの所有者、更新頻度、権限、機密区分を整理したか
PoC成功条件を精度、時間削減、CV改善、問い合わせ削減などで数値化したか
プロンプトインジェクション、個人情報、ログ保存、モデル選定のルールを決めたか
RAG/エージェントの回答を人が監査する運用を設計したか
本番化後の費用上限、API使用量、障害時フォールバックを決めたか

参考にすべき一次情報・公的情報

上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。

GXOに相談するタイミング

次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。

見積もり依頼前に、要件やRFPの粒度を整えたい
既存ベンダーの提案が妥当か第三者視点で確認したい
補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
PoCや診断で終わらせず、本番導入と運用改善まで進めたい

Databricks Genie Oneに見る、データ基盤がない会社のAIエージェント導入が失敗する理由を自社条件で診断したい方へ

GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。

AI/RAG導入診断を相談する

※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。

追加の一次情報・確認観点

この記事の内容を社内で検討する場合は、一般論だけで判断せず、次の一次情報と自社データを照合してください。特に、稟議・RFP・ベンダー選定では「何を実装するか」よりも「どのリスクをどの水準まで下げるか」を先に決めると、見積もり比較のブレを抑えられます。

横にスクロールして確認できます

確認領域	参照先	自社で確認すること
AIリスク管理	NIST AI Risk Management Framework	用途、リスク、評価方法、運用責任者を確認する
LLMセキュリティ	OWASP Top 10 for LLM Applications	プロンプトインジェクション、情報漏えい、権限設計を確認する
AI事業者ガイドライン	総務省 AI関連政策	説明責任、透明性、安全性、利用者保護の観点を確認する
DX推進	IPA デジタル基盤センター	DX推進指標、IT人材、デジタル基盤の観点で現状を確認する
個人情報	個人情報保護委員会	個人情報・委託先管理・利用目的・安全管理措置を確認する

稟議・RFPで使う数値設計

投資判断では、導入前後で測れる指標を3から5個に絞ります。下表のように、現状値・目標値・測定方法・責任者をセットにしておくと、PoC後に本番化するかどうかを判断しやすくなります。

横にスクロールして確認できます

指標	現状確認	目標の置き方	失敗しやすい例
対象業務数	現状の対象業務を棚卸し	初期は1から3業務に限定	対象を広げすぎて要件が固まらない
月間処理件数	件数、担当者、例外率を確認	上位20%の高頻度業務から改善	件数が少ない業務を先に自動化する
例外対応率	手戻り、確認待ち、属人判断を計測	例外の分類と承認ルールを定義	例外をAIやシステムだけで吸収しようとする
正答率・再現率	テストデータで評価	業務許容ラインを明文化	体感評価だけで本番化する
人手確認率	承認が必要な判断を分類	高リスク判断は人間承認	全自動化を前提に設計する

よくある失敗と回避策

横にスクロールして確認できます

失敗パターン	起きる理由	回避策
目的が曖昧なままツール選定に入る	比較軸が価格や機能数に寄る	経営課題、業務課題、測定KPIを先に固定する
現場確認が不足する	例外処理や非公式運用が見落とされる	担当者ヒアリングと実データ確認を必ず行う
運用責任者が決まっていない	導入後の改善が止まる	業務側とIT側の責任分界をRACIで定義する
AIの回答品質を本番で初めて確認する	評価データと禁止事項が未定義	テストセット、NG例、監査ログを用意する