「せっかく社内ChatGPTを入れたのに、みんなすぐ使わなくなる」という声を、2025年後半から本当によく聞くようになりました。決裁が下りて、Azure OpenAIやEnterprise版のChatGPT、Geminiを契約して、社内ポータルからログインできるところまでは進む。ところが3か月後にログを見ると、アクティブな利用者が全社員の1割前後で止まっている、というパターンです。
原因を「AIの性能」に求めがちですが、実務の現場で切り分けていくと、ほぼ確実にデータ準備側の話になります。就業規則の最新版を見に行けない、営業データの「売上」の定義が部署ごとに違う、権限がないはずの人事情報が回答に混ざる、といった問題は、モデルをGPT-4oからClaude Opusに替えたところで一切解決しません。
社内AIを業務に定着させるうえで本当にやるべきデータ準備を、対象データの3分類・進め方の4ステップ・費用感・落とし穴の順に、情シスや基盤担当のマネージャーが発注や社内推進で使える形で整理します。
社内AIを導入した企業から相談を受けるとき、うまくいっていないケースの症状はきれいに3つに分かれます。
「うちの育休は何日？」と聞いたら「一般的な日本企業では〜」と返る、「先月の東京エリアの売上は？」と聞いたら「正確な数字は社内システムをご確認ください」と返る。この症状は、AIが社内の文書やテーブルを見に行っていないことで起きます。
社内ChatGPT製品の多くはRAG（検索拡張生成）を組み込んで販売されていますが、そこに投入する社内データが接続されていない、または対象範囲が狭すぎる状態のまま運用に入ってしまう企業が少なくありません。ツールを買った瞬間に賢くなるわけではなく、社内文書を渡す仕組みを別途整える必要があります。
「先月の売上」を聞いたら数字は返ってきたが、経理の最終数字と1割ずれている。「稼働率」を聞いたら店舗別の平均が出たが、休業日を含めた計算になっている。指標の定義が社内で1つに揃っていない状態でAIに数値を触らせると、こうした「もっともらしいが違う」回答が量産されます。
BIツールで人間が見る前提のデータは、多少ずれていても目視で気づけます。しかしAIは自然文で「そこそこ合っている数字」を出すのが得意なので、間違いに気づける人が少なく、意思決定の品質が下がる方向に働きます。この問題は、AI-readyなデータとは？生成AIに使えるデータの条件と整え方で整理した「定義の統一」に踏み込まないと解決しません。
パイロットで動かしたら、営業部の誰かが「他部署の給与テーブル、見えちゃうんですけど」と気付いた。あるいは、人事情報を扱う想定でなかったのに、AIが機密文書に基づいて回答してしまった。この時点で導入プロジェクトは事実上凍結します。
権限がAIの問い合わせの瞬間に効かない構成でRAGやMCPを組んでしまうと、後から「見せてよいデータだけ」を切り出す作業が莫大になります。データ準備の初期段階で、誰がどの文書・どのテーブルを見てよいかをシステム的に表現できる状態を作っておかないと、パイロット止まりで終わります。
3つの症状に共通するのは、AIそのものの問題ではなく、AIに渡すデータの側が業務で使える状態に整っていないという1点です。ここを飛ばして「もっと良いモデルを試そう」と進めても、たいていは同じ壁にぶつかります。
「データを準備する」と一言で言っても、社内AIに扱わせるデータは性質の違う3つに分かれ、それぞれ整え方が違います。まずこの整理を持っておくと、ベンダー提案書を読むときの解像度が変わります。
就業規則、業務マニュアル、営業提案書、議事録、契約書、社内Wiki。テキストや資料の形で存在する社内知識です。「うちの育休は？」「A案件の値引きルールは？」といった自然文の問い合わせに答えさせる用途で、これが最も需要が大きい層です。
整え方はRAG（検索拡張生成）が定石で、文書をチャンク分割してベクトル化し、質問との類似度で検索してAIに渡します。仕組みの詳細はRAGとは？企業の社内データをAIに使わせる仕組みと作り方｜2026年版にまとめました。実務でつまずくのは、ベクトルDBの選定より前に、対象文書の版管理と権限です。
版管理と権限を整えないままベクトル化に進むと、精度改善のフェーズで必ず巻き戻しが発生します。文書棚卸しは地味ですが、外せない工程です。
DWH（データウェアハウス）に蓄積されている業務データです。「先月の店舗別売上上位10店」「顧客の解約率」といった数値集計の問い合わせに答えさせる用途で、精度と信頼性の要求が最も高くなります。
整え方の要は指標の定義を統一することです。「売上」が税込みか税抜きか、返品を含むか、締日はいつか、といった前提が部署ごとに違うと、AIは平均的な数字を返して意思決定を歪めます。dbt Semantic Layer、Cube.dev、Looker LookML、Snowflake Cortex Analystといったセマンティックレイヤーで、社内で認定された指標だけをAIに触らせるのが現代の定石です。詳細はセマンティックレイヤーとは？AI時代のデータ活用の要を参照してください。
Snowflakeが2024年に公表した内部ベンチマークでは、単一プロンプトのGPT-4oが51%だったText-to-SQL精度が、セマンティックレイヤー経由のCortex Analystでは90%を超えました（Snowflake公式ブログ）。同じLLMを使っても、渡し方を整えるだけで精度が2倍近く変わります。
生SQLをAIに書かせる構成はデモとしては映えますが、本番導入では権限と定義の統制が難しく、監査でも指摘を受けやすい構成になります。
「A社との商談ステータスを『提案中』に更新して」「明日の会議室を予約して」といった、参照だけでなく操作を伴う問い合わせに答えさせる用途です。MCP（Model Context Protocol）やLangChainのツール呼び出しで、AIに業務システムを触らせる形で対応します。
MCPは2024年11月にAnthropicが公開したオープン標準で、GoogleはBigQuery向けのフルマネージドMCPサーバーをPreviewで公開したのち、2026年時点ではGoogle管理のMCPサーバー群を一般提供しています。BigQueryだけでなくSalesforce・Slack・Jira・GitHubなど主要SaaSにも公式・OSSのMCPサーバーが出ています。仕組みはMCPとは？AIエージェントとBigQueryをつなぐ標準規格の実装ガイドで整理しました。
操作系はデータ準備というより「AIに何を触らせて何を触らせないか」の権限設計が本質です。読み取り専用から始めて、書き込みは段階的に開放するのが安全な進め方です。
3種類のデータを全部いきなり整えようとすると、確実に頓挫します。実務でうまくいく進め方は、対象を絞って4ステップで回すやり方です。
「営業担当の見積り作成支援」「経理の規程照会Bot」「情シスの一次サポート」など、価値が見えやすい1つに絞ります。選定のポイントは3つです。
Evastが支援する現場でも、最初のユースケースはほぼ例外なく「バックオフィスの問い合わせ削減」から入ります。金額に直結しない代わりに、失敗の影響が小さく、対象データの範囲を狭く切りやすいためです。
選んだユースケースに必要なデータを洗い出し、以下を1つずつ潰します。
このフェーズを飛ばして先にツールを選ぶと、後工程で必ず戻ってきます。地味ですが、ここに時間をかけた案件ほど本番導入後の精度が安定します。
3種類のデータ性質に応じて、必要な仕組みを最小構成で組みます。
すべて自前で組むかマネージドを使うかは、社内のデータエンジニア人数と学習コストで決めます。パイロットではマネージドで速く動かして、価値検証後に必要ならOSSに置き換えるのが定石です。
小さく展開して回答精度と業務効果を測定し、対象範囲を広げていきます。ここで見るべき指標は「AIの回答精度」だけではありません。
利用が定着しない原因の多くは「回答が微妙に間違っている」ことなので、正答率の目視レビューと現場ヒアリングを最初の3か月は毎週回します。ここで精度を上げ切ってから、隣の部署・隣のユースケースへと広げていきます。
社内AIのデータ準備は、対象範囲と統制要件で費用が大きく変わります。発注前の予算感覚として、代表的な3パターンを置いておきます。
| パターン | 対象 | 期間 | 初期費用 | 月額運用 |
|---|---|---|---|---|
| スモールスタート | 1部署・1ユースケース | 3〜5か月 | 200万〜800万円 | 15万〜60万円 |
| 部門展開 | 1本部・3〜5ユースケース | 6〜10か月 | 800万〜2,000万円 | 40万〜150万円 |
| 全社AI基盤 | 全社主要データ・複数用途 | 1年〜1年半 | 1,500万〜5,000万円 | 100万〜500万円 |
初期費用にはデータ棚卸し・権限整理・RAG/MCP/セマンティックレイヤーの構築・ベンダー支援費が含まれます。月額運用は、LLM APIの従量課金（ChatGPT Enterprise、Claude Team、Gemini API、Azure OpenAIなど）、ベクトルDBのマネージド費、BIツールライセンス、監視・保守費の合計です。
ヘビーユースの現場ではLLMのトークン課金だけで月100万円を超えることもあり、想定利用量とモデル選択（軽い問い合わせはHaikuやGPT-4o mini、複雑なものだけOpus/GPT-4o）を含めた設計が費用最適化の要になります。データ基盤側の初期費用の内訳はデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説で分解しました。
Evastが伴走している案件と、他社に発注した後に相談が来た案件を並べると、社内AIのデータ準備でつまずくパターンは驚くほど似ています。代表的な5つを共有します。
「まず全部入れてから精度を見ましょう」の提案は、聞こえは前向きですが、対象範囲を絞らないまま数万件の文書をベクトル化すると、検索でノイズが増えて精度が下がります。古い版と新版が両方ヒットして矛盾する回答が出るのが典型例です。先に対象範囲を絞ってから入れるが鉄則です。
パイロットは開発環境で全員フルアクセスで動かしていたが、本番展開の直前で「機密文書のアクセス制御ができていない」と法務・情シスから待ったがかかる。ここから権限設計をやり直すと3〜6か月遅延します。権限は最初のユースケース選定の時点で要件を固める必要があります。
BIダッシュボードで見る分には気にならなかった「売上」「顧客数」の定義違いが、AIの回答では致命傷になります。「先月の売上」が回答するたびに変わる、部署によって違う数字が返る、といった状態は現場の信頼を一気に失います。数値系のユースケースを組むなら、セマンティックレイヤーは省略できません。
初期構築時にベクトル化した文書がそのまま放置され、半年後には古い規程で回答するようになる。文書の追加・更新・削除をベクトルDBに反映する運用フロー（差分同期、削除フラグ、承認フロー）を設計に組み込まないと、時間が経つほど精度が落ちます。
1部署・限定ユーザーでうまくいったからと、次の日から全社に開放して失敗するパターンです。対象データ範囲・利用者の背景知識・許容できる回答精度が違うと、同じ仕組みでも定着しません。部署ごと・ユースケースごとに、STEP2の棚卸しから毎回やり直すのが安全です。
社内AIのデータ準備は、「全社データをAI-readyに整える」という発想で始めると、ほぼ確実に頓挫します。1つのユースケースに絞り、そこに必要なデータだけを整え、精度と定着を確認してから次に進む、という順番でしか成果は出ません。
判断の起点として、まず次を確認するのがおすすめです。
Evastは、データ基盤の設計から社内AIのデータ準備・RAG構築・MCP接続・セマンティックレイヤー導入まで、1ユースケース単位で3〜6か月のスモールスタート伴走から入る形で支援しています。「まず何から手をつけるべきか」から相談したい場合は、データ基盤構築サービスの窓口からお問い合わせください。
社内AIが本当に業務を変えるかどうかは、モデルの選択ではなく、渡すデータの整え方と、対象範囲を絞る勇気で決まります。
データ基盤社内AIやRAGを検討すると、構成図に必ず「ベクトルデータベース」という箱が登場します。埋め込み（エンベディング）で意味を数値化して検索する仕組み、キーワード検索との違い、RAGでの役割、Pinecone・pgvector・BigQueryなど主要製品の特徴、専用DBと既存DB拡張の選び方、導入時の落とし穴までを、非エンジニアのマネージャー向けに整理します。
データ基盤社内ChatGPTを入れたのに「うちの規程では」を返せない、という悩みは多くの企業で起きています。この記事では、RAG（検索拡張生成）の仕組みと構成要素、なぜ社内AIに必須なのか、実装に必要なデータ基盤・ベクトルDB・チャンク設計の要件、現場で起きる典型的な落とし穴、そして4〜8週間のスモールスタート手順まで、情報システム部・データ基盤担当のマネージャー向けに整理します。
データ基盤「AIに社内DBを触らせたいが、接続先ごとにAPI開発は非現実的」――MCPはこの詰まりを解く標準規格です。Google公式BigQuery MCPサーバー(2026年Preview)の機能、権限設計・SQL精度・監査ログの落とし穴、3〜5か月・100〜500万円の導入相場を実装目線で示します。
