生成AIの本番運用開始、しかし使い物にならない……高精度な自社専用LLMを実現するデータ整備の勘所
AIのための「翻訳辞書」を作るべし 辞書の作り方から実運用フェーズでの典型的な壁と乗り越え方まで解説
企業の生成AI活用がPoCを超え本番運用へ進む中、「現場で成果を出せるほどの精度が担保できない」という壁に直面するケースが増えている。2026年6月9日に開催した編集部主催イベント「EnterpriseZine Day 2026 Summer」に登壇したQuollio Technologies 取締役副社長 COOの眞田貴央氏は、社内データを集約・意味付けするデータカタログ「Quollio Data Intelligence Cloud(QDIC)」を展開する同社の知見をもとに、LLMを自社専用の知性へと変える「翻訳辞書」と「協調判断(Human-In-The-Loop)」というアプローチを説明。品質工学の視点から本番導入を阻む要因をひも解き、AIの能力を引き出す現実的な運用設計について具体例とともに解説した。
各部門のKPIは達成しているのに、経営は「赤」
講演冒頭、Quollio Technologies 取締役副社長 COOの眞田貴央氏は、企業組織における生成AI活用の課題の本質を、製造業との構造的類似から説明。製造業では、各製造工程の数値が基準内であっても、最終検査で不具合が見つかることがある。この構造は、企業のデータ活用にも当てはまるという。
「マーケティングがリードを獲得し、営業が受注し、カスタマーサクセス(CS)が定着支援を行い、最後に経理が経営レポートをまとめる。この流れで各部門のKPIは『緑(達成)』なのに、経営レポートを開くと全体指標が『赤(不合格)』になる──これが部分最適の弊害です」(眞田氏)
たとえば、マーケティングがリード数を前年比200%に拡大しても、質を問わないリードばかりなら後工程に歪みが生じる。営業が値引きで受注目標を達成し、CSが契約数を維持していても、裏ではサポート工数が増え、解約が増加しているかもしれない。そうすれば、LTV(顧客生涯価値)はマイナスとなり、獲得コストを回収できず、企業全体の収益最大化は失敗に終わる。
冒頭で示した「最終工程で初めて発覚する不具合」の原因を、同氏は以下3点に整理する。
- 自部門の個別KPIを見ると、センサーが常に緑(達成)になること
- MAやSFA、製品利用ログ、ERPなどの業務システムがサイロ化し、顧客が会社全体をどう通り抜けたかを示す横串データがないこと
- 小さなズレが積み重なる、特定の組み合わせで問題が顕在化すること
「単変量の通過条件、つまり個別指標を縦割りに見るだけのアプローチでは、こうした多変量の相関領域に潜む真因を捉えられません。最終工程で初めて分かる不具合は、全工程のデータを横串で見ない限り真因に到達できない。これこそが、今回の講演の出発点です」(眞田氏)
AIの実業務への定着を阻む「3つの壁」 根本原因は“不完全な”メタデータ整備
何十もの工程から出力される膨大な変数の中から、部門間の相関や相互作用を見つける作業を人手で行うのは現実的ではない。これは、大量データからのパターン認識を得意とする生成AI/LLMが担うべき領域で、多くの企業が「自然言語で問いかければ、AIが横断的に分析して解約率上昇の真因を返してくれる」世界を期待している。
一方で、実業務にAIを投入しようとすると以下のような「3つの壁」が立ちふさがるという。
- ハルシネーション:自社データベースに存在しないテーブル名やカラム名を自信満々に出力し、現場の信頼を損なう
- 根拠不在:回答がどのテーブル・定義に基づくか示されず、重大な業務判断に使えない
- 権限制御の欠如:機密性の高い個人情報や財務情報まで横断的にアクセスできてしまう
これらの根本的な原因は、「AIが単独で正しく動くためのデータの文脈、すなわち信頼できるメタデータが外部に整備されていないことにある」と眞田氏は指摘する。汎用LLMは一般常識やSQL構文、業界標準の概念知識はもつものの、企業固有の“社内常識”は持ちあわせていない。
しかし、企業のデータベースは物理構造中心に設計されており、業務上の意味や定義が明文化されていないケースが多い。そのため、「売上を出して」といった指示に対しても、どのデータをどう集計すべきかAIは判断できず、推測に頼ったSQL生成によって構文エラーやハルシネーションを招いてしまうのだ。このズレを埋めるために不可欠なのが、社内常識を機械可読な形に翻訳した「辞書」であり、これこそが次世代データカタログの役割である。
「1ヵ所のデータウェアハウスにデータを集めさえすれば、AIが勝手に分析してくれるという考え方があります。しかし、集めるだけでは動きません。データウェアハウスはあくまでデータを保管する倉庫であり、中身を正しく取り出すには、図書館でいう蔵書目録や検索システムにあたる『データカタログ』が必要です。データの業務的意味を管理する辞書があって初めて、AIはそのデータを正しく扱えるセマンティック層を構築できます」(眞田氏)
Quollioが提供するデータカタログには、業務的意味や用語定義を管理するメタデータ管理、データの来歴を追うリネージ、業務ルールに沿ったアクセス制御を行うガバナンスという3つの中核機能がある。これらがコンテキストとしてAIエージェントへ供給されることで、同義語の混同解消、根拠付きの応答、業務単位での権限制御といった効果が生まれる。データカタログは、人間がデータを探すためのツールから、AIに文脈を供給して制御する「コントロールプレーン」へと役割を進化させている。
完璧な翻訳辞書を用意した後も、「とある問題」が待ち受ける……
この「翻訳辞書」をAIに組みこむと、回答精度はどう変化するのか。Quollioは複数条件で精度を比較し、メタデータなし(Agent 0)、物理構造のみ(Agent 1)、ビジネスメタデータまで含めた構成(Agent 2)の3種類で検証を行った。
AIが自律的に動作するフェーズにおいて結果を比較すると、Agent 0は推測依存のため構文エラーやハルシネーションが多発し、正答率は低水準にとどまった。Agent 1は実行可能なSQLを生成できるものの、ビジネスロジックの理解が浅く中レベルの正答率にとどまった。対して、翻訳辞書を与えたAgent 2は高い正答率を示したという。
「ビジネスメタデータを扱えるようにするだけで、AIの精度は大きく押し上げられる」と眞田氏は語る。推測駆動から根拠駆動へと変わり、「売上」という言葉が指す物理カラムを辞書から明確に引いて応答できるようになるからだ。メタデータへの投資こそが、AIをスマートにするための有効なルートの1つだと強調した。
とはいえ、どれほど完璧な翻訳辞書を整備してデータカタログで基礎精度を高めても、実業務への適用では「もう1つの高い壁」があることも検証から明らかになったという。それが、現場ユーザーが日常的に発する「曖昧な指示」に起因する構造的限界である。
たとえば「直近の主要な売上トレンドを横串で出して」といったリクエストでも、「直近」がいつのことを指すのか、「主要な」がどの売上や顧客を意味するのかによって正解が変わり、AIは迷ってしまう。
「意味はデータカタログの辞書で解けても、ユーザーの『意図』はメタデータだけでは解けません。売上の計算定義や同義語マッピングは辞書に書き切れても、その問いの背後にある利用目的の業務文脈まではデータカタログには書かれていません。だから、どれだけ完璧な辞書を作っても、AIが単独で100%正解を当てにいくには構造的限界があるのです」(眞田氏)
そこでQuollioが提示するのが、AIが自身の回答の確信度を測り、迷ったときは勝手に推測せず人間に確認を求める「協調判断(Human-In-The-Loop:HITL)」のアプローチだ。翻訳辞書をもつAgent 2に、この協調判断を組み込んだ構成を測定すると、正答率は顕著に向上。「直近」「主要な」といった言葉の定義が不足していると判断した際、直近1年と仮置きして進めるのではなく、「直近1年でよろしいですか、それとも今四半期ですか?」とユーザーに問い返す運用設計である。
眞田氏はこのアプローチの効果として、辞書だけでは対応しきれない曖昧な指示の意図を会話で補完できること、業務的に意味をなさない攻撃的な問い合わせには「答えない」というガードレールを敷けること、回答に至った根拠が対話として残るため現場が信頼しつづけられることの3点を挙げた。
では、AIに渡す辞書は誰が作るのか?
このアプローチに関して現場から出てくるのが、「その辞書は誰が作るのか」という率直な疑問だろう。多くのデータカタログ導入はUIを整えた後、現場に定義の手入力を依頼した段階で止まり、忙しさから「いつかやる」が積み重なって中身が空のまま形骸化し、費用対効果が疑問視されて予算が打ち切られてきた。
これに対しQuollioは、「AIのための辞書作りをAI自身に担わせる」という運用モデルを推奨する。具体的には、システムをユーザーと接するフロントステージ(表側)と辞書を育てるバックステージ(裏側)の2つに分け、それぞれ異なるAIエージェントを配置するという。
フロントステージでは、業務ユーザーの自然言語の問いに「データ検索用AI(Agent B)」が応答し、問いの解釈と対話を行う司令塔AI、SQLを生成・実行するデータソースAI、インサイトを可視化する出力整形AIなどで構成されるエージェント群が協調判断(HITL)を通じて曖昧さを対話で排除しながら、必要に応じてデータカタログのメタデータを参照する。
バックステージでは、「データ登録用AI(Agent A)」が稼働する。Agent Aは、古いテーブル定義書や用語集、業務マニュアル、過去のSQL履歴など社内に眠る既存のデータ資産を読み込み、論理名や業務定義を推測して推薦し、標準的なデータ連携プロトコル経由でデータカタログへメタデータを自動登録していく。
なかでも、フロントステージでの利用ログや対話データが、バックステージのAgent Aの登録精度を高めるフィードバックとして循環する点が重要だ。現場が使えば使うほど、裏側でAIによる辞書が自動成長するエコシステムができあがる。人間は膨大な手入力から解放され、AIが推薦した定義の「確認と承認」という本質的な判断業務にだけ時間を割けるようになる。
講演終盤、眞田氏はAIの本番運用に向けた具体的な進め方にも触れた。選択肢には、単一部門データに絞る「単工程トライアル」と、全データを最初から統合する「全社一斉構築」があるが、前者は部門間の交互作用による真因に届きにくく成果を実感しづらい一方、後者は数年と数億円規模の投資が必要となり予算面のリスクが高い。
そこでQuollioが推奨するのが、現場の具体的な問いから出発し、必要なデータだけを縦につなぐ「段階的連結分析(Path B)」だ。まず、月次・四半期で既に追っている最終工程の数字からスタートし、その数字を大きく動かしたと見込まれる中間工程へ一歩踏み込んで、関連データの異常を確かめる。
つなぐ過程で露呈する「部門間でのデータカラム定義の不一致」というボトルネックを翻訳辞書で解消しつつ、最小限の3〜5ソースだけを縦に統合し、数ヵ月という短いサイクルで具体的な分析レポートを提示して実証する。3ヵ月ごとに効果を測定し、Go/No-Go判定を入れながら対象領域を徐々に広げていく。
同社は、自社データとAIを接続した際の精度や本番適応性を3ヵ月で定量評価し、本番導入計画まで伴走するプロフェッショナルサービス「AI impact PoC」を提供している。眞田氏は、講演を次の一言で締めくくった。
「データとAIを本番運用へ進めようとするとき、構造的な壁は必ず存在します。その壁を越えるためには、翻訳辞書としてのデータカタログと協調判断の運用設計、そしてAIによる辞書の自動生成の組み合わせがカギとなります」(眞田氏)
この記事は参考になりましたか?
提供:株式会社Quollio Technologies
【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社
この記事は参考になりましたか?
この記事をシェア
