生成AIの本番運用開始、しかし使い物にならない……高精度な自社専用LLMを実現するデータ整備の勘所

では、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による辞書の自動生成の組み合わせがカギとなります」（眞田氏）