こんにちは。K.Platinum代表の沼田です。
先日、ある中堅メーカーさんの会議室で。社内データに接続したAIアシスタントのデモ中、僕はごく普通に聞きました。
「今月の売上は？」
画面に数字が出ます。役員の方がうなずく。その隣で、経理部長が首をかしげました。
「……その数字、うちの締めの数字と3,000万ちがいます」
場の空気が固まりました。担当の若手が「ハルシネーションかもしれません」と言いかけたところで、僕は止めました。違う。これは、AIが嘘をついたんじゃない。
30分ほど掘って、答えが出ました。その会社には「売上」の定義が2つあったんです。経理は検収ベース、営業は受注ベース。どちらも正しい。ただ、その2つが同じ言葉で呼ばれていることを、社内の誰も問題だと思っていなかった。AIは営業側のテーブルを素直に読んで、素直に答えただけでした。
先に結論を書きます。社内データにAIをつなぐ前にやるべきは、モデル選びでもRAG構築でもなく、「その言葉、どっちの意味ですか」を潰しておくことです。以下、その根拠と、うちが実際にやっている3ステップを書きます。
57%の企業が、同じ場面を見ている
これ、うちの顧客だけの珍事ではありません。
2026年6月にVentureBeatが実施した調査（従業員100名以上の企業101社）では、過去半年で57%の企業が「AIエージェントの自信満々な誤答」を経験し、その原因を"社内のビジネス文脈が欠けている／揃っていないこと"にまで突き止めています。しかも31%は、一度きりではなかったと答えている。
「AIの精度が悪い」ではなく「うちの文脈が渡っていない」——現場はもう気づきはじめている。にもかかわらず、その文脈を統制する層を本番運用できている企業は4社に1社にとどまります。
理由はシンプルで、生のデータベースには、ビジネスの文脈が入っていないからです。
テーブルにあるのは sales_amount とか status_cd みたいなカラム名だけ。そこに「うちで言う売上は検収ベース」「status_cd = 9 は失注だが、営業が入力を忘れるので実態は7も見る」といった、社内の人間なら全員が暗黙に知っている前提は、どこにも書かれていない。
ブレインパッドの技術メディアDOORS DXは、この構造をうまく言語化しています。生成AIは検索結果の正しさを検証する機構を持たず、渡されたものを「与えられた事実」として受け入れる。だからこれは「生成AIの能力不足ではなく、検索設計の問題」だと。
まったく同感です。AIは意図しないテーブルを参照し、条件を1つ落とし、存在しないカラムを推測で埋める。そしてその結果を堂々と返してくる。AIは「わからない」と言うのが、いちばん苦手なんです。
生々しい例もいくつも見てきました。
- CRMの「架電」記録の相当割合が実は留守電。AIは平然と「今月300件アプローチしました」と答える
- 「失注日」の入力ルールが部署ごとに違う（失注を確認した日／月末にまとめて入力）
これ、AIを入れたから起きた問題ではありません。もともとあった問題が、AIによって初めて可視化されただけです。人間同士なら「あ、それ営業ベースね」と空気で補正していた。AIは補正してくれない。
「定義の揺れ」は、出荷日・在庫・得意先コードに出る
うちは製造・流通・金融の基幹システムに触れる案件が多いのですが、この「定義の揺れ」はほぼ必ず出ます。頻出の3つを。
① 出荷日は、倉庫を出た日か、検収された日か
生産管理システム上の出荷日、営業が客先と握っている納品日、経理の売上計上日。3つとも違う日付で、3つとも「出荷日」と呼ばれていた現場がありました。納期遵守率をAIに集計させたら、部署ごとに違う数字が出るのは当たり前です。
② 在庫は、引当済みを含むか
「在庫いくつある？」の答えが、物理在庫なのか、引当を引いた有効在庫なのか。倉庫と営業で答えが違う。AIはたいてい物理在庫を返します。それを見た営業が客先に「まだ在庫あります」と答えたら、事故です。
③ 得意先コードは、統合前か統合後か
企業合併やグループ再編を経た会社だと、旧コードと新コードが並存しています。「A社の年間取引額」をAIに聞くと旧コード分が抜け落ちる。しかも、抜けていることに人間が気づけない。数字は「それっぽく」出てくるからです。
厄介なのは、どれも「AIの精度が悪い」という形で表面化することです。データの意味が揃っていないだけなのに、「うちにはまだAIは早い」という結論になり、プロジェクトが静かに死んでいく。
RAGを入れる前に、「言葉の辞書」を作る
じゃあどうするか。うちが最近、案件の入り口で必ずやるようになったのが「言葉の辞書を先に作る」ことです。技術用語で言えばセマンティックレイヤー——データと人間の言葉の間に、意味の翻訳層を1枚置く、という考え方です。
これは僕の私見ではありません。dbt Labsは2025年12月、指標定義エンジンのMetricFlowをApache 2.0でオープンソース化し、「LLMエージェントが統制された指標を安全に呼び出す」ユースケースを前面に出しました。マイクロソフトも公式ドキュメントで、Power BI Copilotの精度低下の主因はモデル側の準備不足（メジャー名の揺れ、説明の未記載）だと明記しています。AIに生SQLを書かせず、人間が定義した指標だけを呼ばせる。ベンダーが揃って「モデルではなく定義の問題だ」と言っているわけです。
とはいえ、中堅企業でいきなり本格的なセマンティックレイヤーを構築するのは重い。うちがやっているのは、もっと泥臭い3ステップです。
① 指標を10個だけ選ぶ
全部やろうとしない。その会社の会議で実際に飛び交っている指標を10個だけ拾います。売上、粗利、受注残、在庫回転、納期遵守率……。だいたい10個で日常の意思決定の8割はカバーできます。100個の辞書は誰も引きません。
② 定義のオーナーを決める
これが一番大事で、一番揉めます。「売上の定義は経理部長が決める」と、人を1人指名する。合議にすると永遠に終わりません。意味層の導入解説でも「誰が定義を管理するか」の承認フロー設計は必須項目で、ここを曖昧にした案件は例外なく後で揉めます。
③ 定義をコード側に置く
WordやExcelの用語集は3ヶ月で腐ります。誰も見ないからです。定義は、ビュー・中間テーブル・メトリクス定義ファイルといった動くコードの側に置く。AIが参照するのはそこだけ、というルールにする。コード側なら変更履歴が残り、レビューを通り、間違えたら戻せる。ドキュメントとして書くのではなく、システムとして強制するわけです。
この3つを、1つの業務領域からやります。全社ではなく、たとえば「受注〜出荷」だけ。少なくていい。
顧客の言葉から設計する仕事に興味はありませんか
K.Platinumでは、この上流の設計から手を動かすところまで担う仲間を募集中です。案件の進め方と募集条件を見る
なぜ「全社データ基盤から」だと失敗するのか
「どうせやるなら全社のデータ基盤を整備してから」——気持ちはわかります。でも、これで動き出したプロジェクトが最後まで走り切ったのを、僕はあまり見たことがありません。
理由はシンプルで、全社の合意形成は、技術の話ではなく政治の話になるからです。「売上の定義を経理に合わせる」は、営業の評価指標に手を突っ込む話でもある。全社でやろうとすると、この交渉を10指標ぶん同時にやることになります。
これも僕らだけの経験則ではありません。意味層導入の代表的な失敗パターンが「全社統合を一気に進めて合意形成に数ヶ月溶ける」で、処方箋は1〜2個のコア指標から始めて広げること。業界の答えは、もう出ています。
だから、1業務・10指標。そこでAIがまともに答えるようになった事実が、次の領域を動かす燃料になります。先に成果、あとで全社。順番が逆だと、たいてい途中で燃料が切れます。
17人だから、顧客の言葉を先に揃えられる
うちは17人のITコンサル会社です。大手SIerさんのように、データ基盤の構築に何十人も投入することはできません。
でも、この「言葉の辞書」の仕事は、人数ではどうにもならない類の仕事です。経理部長と営業部長の間に座り、「その売上って、どっちの売上ですか」と失礼にならない聞き方で聞き続ける。誰が何を守りたくてその定義を使っているのか、まで含めて。
僕は24歳で起業して、いま27歳。創業から3年ちょっとです。前職でも「システムの前に言葉を揃える」現場を何度も見ました。逆に言えば、そこを飛ばして技術から入った案件は、だいたい後で戻ってくる。
もし今、社内でAI活用の話が進んでいるなら、明日の会議で試してみてください。誰かが出した数字に、こう聞くだけです。
「その数字、どっちの定義ですか？」
即答が返ってこなければ、それが辞書を作りはじめる合図です。
まとめ：辞書が先、RAGは後
AIエージェントは、社内の曖昧さを容赦なく暴きます。それは怖いようでいて、実はチャンスでもある。20年なあなあにしてきた定義の揺れに、「AIが間違えるから」という誰も傷つかない理由で手をつけられるからです。
やることは3つ。指標を10個に絞る。定義のオーナーを1人決める。定義をコードに置く。1つの業務領域で成果を出してから次に広げる。全社データ基盤の完成を待つ必要はありません。
RAGを入れる前に、辞書を作る。遠回りに見えて、これがいちばん速い道でした。
沼田海斗（ぬまた・かいと）
株式会社K.Platinum 代表。24歳で創業。製造・流通・金融の基幹システムとデータ活用の現場に携わる。技術より先に「言葉」を揃えることを大事にしている。
K.Platinumでは、基幹データに強いエンジニア／コンサルタントを募集しています。「繋ぐ」より一段深いところ、顧客の言葉そのものを設計する仕事に興味がある方は、ぜひ採用ページをご覧ください。