「システムのカラム名『sales_amt』は、経理部の言う『売上』と同じですか？それとも営業部の『受注額』ですか？」
データ活用プロジェクトの現場では、このような会話が頻繁に交わされます。そしてそのたびに、誰も自信を持って答えられないという沈黙が流れる傾向があります。
企業のDX（デジタルトランスフォーメーション）が進む中で、システム上の「データ定義」と、現場で飛び交う「ビジネス用語」の乖離が深刻な問題になっています。ドキュメントを整備しようとしても、システムの改修スピードに追いつかず、いつの間にか定義書は形骸化してしまいます。そこで多くの担当者が目を向けるのが、NLP（自然言語処理）技術を使った自動化です。
「AIに社内ドキュメントを読み込ませれば、自動的に用語集を作ってくれるはず」
「変更があればAIが勝手に検知して、同期してくれるだろう」
もしそうお考えなら、少し立ち止まって検証してみる必要があります。技術的な観点から論理的に分析すると、その期待は半分正解で、半分は危険な誤解を含んでいます。
実務の現場における一般的な傾向として言えるのは、ツールを導入するだけで解決するほど、人間が使う「言葉」は単純ではないということです。
今回は、NLP活用の限界と、それでもAIを使ってデータガバナンスを成功させるための「現実的な付き合い方」について、技術的な裏側を噛み砕いて分かりやすく解説します。
なぜ「データ定義」と「ビジネス用語」の乖離は止まらないのか
そもそも、なぜこれほどまでにデータ定義とビジネス用語は乖離してしまうのでしょうか。AI技術の活用を議論する前に、まずは私たちが直面している構造的な問題を論理的に整理しておきましょう。
データカタログが「ゴミ捨て場」になるメカニズム
多くの企業で導入されているデータカタログやメタデータ管理ツールですが、導入当初は整理されていても、半年もすれば誰も見ない「情報のゴミ捨て場」になってしまうケースは珍しくありません。
理由はシンプルです。システムの変更速度に対して、ドキュメントの更新コストが高すぎるからです。
現代のアジャイル開発やマイクロサービスアーキテクチャでは、データベースのスキーマ変更やAPIの仕様変更が頻繁に行われます。開発エンジニアはコードを修正し、機能をリリースすることに集中するため、Excelの定義書やWikiの用語集を更新するのはどうしても「後回し」になりがちです。
一方で、ビジネスサイドでは新しい商品やサービスが生まれ、それに伴って新しい「用語」が誕生します。例えば、サブスクリプション型のビジネスモデルを採用している組織で、マーケティング部が使う「LTV（顧客生涯価値）」の計算式が、戦略変更に伴い「粗利ベース」から「売上ベース」へと変更されるようなケースを想像してください。システム上のカラム名はltv_calcのまま変わらず、定義だけが変わっていくのです。
この二つの変化のスピードが異なるため、手動での同期は事実上不可能です。結果として、「ドキュメントは信用できないから、詳しい人に直接聞こう」という属人化への回帰が起こります。データガバナンスの取り組みの多くが「文化的な定着」に失敗するという指摘が業界でよくなされますが、その根底にはこの「更新コスト」の問題が潜んでいます。
NLP（自然言語処理）への過度な期待と現実
この状況を打破するために期待されているのがNLP（自然言語処理）技術です。特に近年の大規模言語モデル（LLM）の進化により、非構造化データ（テキスト）の意味理解能力は飛躍的に向上しました。
「SQLのコメントや設計書から、AIが自動で意味を抽出してカタログ化してくれればいいのに」
そう考えるのは自然な仮説です。しかし、技術的な視点から検証すると、「抽出できること」と「正しい定義として使えること」は全く別の問題です。ここに大きな落とし穴があります。
1. コンテキスト（文脈）の欠如
AIモデル、特に汎用的なLLMは、インターネット上の膨大なテキストデータで学習されていますが、個別の組織における「社内用語」や「暗黙の了解」は学習していません。
最新の研究では、プロンプトを反復させることで推論精度を向上させる手法なども報告されていますが、そもそも学習データに存在しない「社内固有の文脈」をAIがゼロから生み出すことは不可能です。「売上」という単語一つとっても、それが「グロス」なのか「ネット」なのか、あるいは「計上ベース」なのかは、その組織の文脈に依存します。
2. 確率論的な限界
生成AIはあくまで確率論に基づいて「それらしい答え」を予測するシステムです。99%の精度で正解を出したとしても、残りの1%で重大な誤解釈（ハルシネーション）を起こすリスクがあります。データ定義という「正確性が命」の領域において、この不確実性は無視できないコストとなります。
3. 「丸投げ」アプローチの破綻
かつては「AIにドキュメントを読ませれば自動で辞書ができる」というアプローチが模索されましたが、現在ではこの方法は現実的ではないというのが一般的な見解です。AIは「補助」にはなりますが、「正解の判定者」にはなり得ません。
したがって、AIに過度な期待を寄せるのではなく、「人間がコンテキストを与え、AIがそれを整理・補完する」という役割分担（Human-in-the-loop）を前提にシステムを設計する必要があります。ここからは、よくある誤解を通して、その理由をさらに深掘りしていきましょう。
誤解①：「既存ドキュメントをAIに学習させれば、完璧な用語集ができる」
まず一つ目の大きな誤解は、AIを「魔法の整理整頓係」だと思っていることです。「社内の共有フォルダにある設計書やマニュアルを全部AIに読ませれば、統一された用語集ができる」という仮説をよく耳にしますが、実証データに照らし合わせると、これはうまくいきません。
ドキュメントに書かれていない「暗黙知」の壁
NLPの基本原則に「Garbage In, Garbage Out（ゴミを入れればゴミが出てくる）」という言葉があります。AIは入力されたデータ以上の知識を生み出すことはできません。
例えば、金融業界のシステム統合などで、「残高」という言葉の定義統一が課題になるケースがよくあります。システムドキュメントには単に「残高」としか書かれていなくても、現場の実態を調査すると以下の事実が判明することがあります。
- 勘定系システム担当: 「帳簿残高（未記帳分を含む）」
- ATMシステム担当: 「支払可能残高（手数料分を差し引いた額）」
- 営業担当: 「預かり資産残高（投資信託の時価評価額を含む）」
現場の担当者は、ドキュメントに書かれていない「暗黙知」や「文脈（どの部署の話か）」で会話を補完しています。「いつものあれ」で通じる世界です。しかし、AIにはその暗黙知がありません。ドキュメント上の「残高」という文字だけを見て、これらの違いを識別することは不可能です。
表記揺れと「文脈による意味の変化」はAIでも完全には解けない
さらに厄介なのが、日本語特有の曖昧さと表記揺れです。
- 売上高
- 売上金額
- Sales Amount
- Total Sales
これらが同じものを指しているのか、微妙に違うのか。技術的な仕組みを少し解説すると、近年のAI（Transformerモデルなど）は、言葉を「ベクトル（数値の羅列）」に変換し、その距離（コサイン類似度）で意味の近さを判定します。これにより、「売上」と「Sales」が近い意味であることは判定できます。
しかし、「契約金額」と「請求金額」のように、言葉としてのベクトル距離は近くても、ビジネス上の意味（発生タイミングや法的拘束力）が全く異なるケースがあります。これをAIが自動で「同一用語」として名寄せしてしまうと、重大な事故につながります。
文脈による意味の変化を、単一のドキュメント学習だけで正確に切り分けるのは、最新のモデルをもってしても至難の業なのです。
誤解②：「自動同期システムを入れれば、運用工数はゼロになる」
二つ目の誤解は、運用の完全自動化に関するものです。「一度システムを構築すれば、あとはAIが勝手にやってくれる」という考え方は、データガバナンスにおいては致命傷になりかねません。
ビジネスの変化スピードと「言葉」の寿命
ビジネス用語は生き物です。市場環境の変化や戦略の転換によって、言葉の定義は常に変化します。
例えば、サブスクリプションモデルを導入した瞬間から、「顧客」の定義は「一度買った人」から「継続課金している人」へと変わるかもしれません。この変化をAIが自動検知して、勝手に定義を書き換えてしまったらどうなるでしょうか？
過去のデータ分析結果との整合性が取れなくなり、「先月のレポートと数字が合わない」という混乱を招きます。さらに最悪なのは、その変更がいつ、誰の意図で行われたのかが追えなくなることです。
定義の変更は、システム的な更新ではなく、ビジネス的な意思決定です。これをAI任せにすることは、経営判断をAIに丸投げするのと同義です。
完全自動化ではなく「サジェスト」が正解である理由
では、AIは役に立たないのでしょうか？いいえ、そうではありません。使い方の問題です。
実証に基づいたアプローチとして推奨するのは、AIを「オートパイロット（自動操縦）」ではなく「コパイロット（副操縦士）」として使う方法です。
- × 誤った使い方: AIが勝手に用語集を更新する。
- ○ 正しい使い方: AIが「新しい用語がコード内に見つかりました。これは〇〇と同じ意味ですか？」と人間に提案（サジェスト）する。
この「Human-in-the-loop（人間がループの中に入る）」構成こそが、現時点での最適解です。AIは膨大なソースコードやログを監視し、変化の兆候を見つけるのが得意です。一方で、その変化を「正式な定義」として採用するかどうかの判断は、人間（データスチュワード）が行う。この役割分担が、運用工数を減らしつつ品質を保つ鍵となります。
誤解③：「技術部門だけでデータ定義の統一は完結できる」
最後の誤解は、組織とプロセスに関するものです。データ定義や用語集の整備を「IT部門のタスク」として切り離していませんか？あるいは、AIツールさえ導入すれば技術部門だけで完結できると考えていないでしょうか。
用語集は「システム仕様書」ではなく「共通言語」
NLP（自然言語処理）を活用してデータベースのカラム名から物理名を抽出・整理したとしても、それがビジネスサイドの実務で使われなければ意味がありません。技術的に整合性の取れた定義書ができても、現場が「使いにくい」「言葉の定義が実態と異なる」と感じれば、またExcelによる独自管理（サイロ化）が始まってしまいます。
最新の知見では、データ定義における失敗の多くは「定義欠損」、つまり言葉の意味やビジネス文脈のズレに起因することが明らかになっています。データ定義書の本質的な価値は、ビジネスサイドとITサイドの「共通言語」を作ることにあります。これは技術的な課題というよりも、コミュニケーションとデータガバナンスの課題です。
現場を巻き込まない自動化が失敗する理由
データ定義の自動化において、技術部門主導で高機能なツールを導入したものの、現場で定着せずに失敗するケースは珍しくありません。
主な原因は、NLPなどの技術だけでは「現場の暗黙知」を完全に汲み取ることが難しい点にあります。例えば、現場では特定の見積書や契約書の文脈に基づいて「売上」や「仕掛品」を判断している場合、システム上のマスタデータだけを学習したAIモデルでは、その微妙なニュアンスや除外条件（ビジネスロジック）を反映しきれません。
その結果、AIが自動生成したタグや定義が現場の感覚とズレてしまい、「使えないツール」として形骸化してしまいます。特に非構造化データや複雑な商流を含むデータにおいては、データの欠損や偏りがAIの学習を歪め、誤った定義を導き出すリスクも指摘されています。
推奨される現実的なアプローチ（ハイブリッド型）
現在推奨されているベストプラクティスは、完全自動化への依存を避け、人間主導の辞書構築をAIが支援するハイブリッドなアプローチです。
- 現場の暗黙知を定義する: まず現場のキーマンを巻き込み、「自分たちが業務で使っている言葉」や「判断ルール」を棚卸しします。
- AIによるマッピング支援: その人間が定義した「正解（辞書）」に基づいて、AIを使ってシステム上のデータとの紐付けや、表記揺れの検出を行います。
- 継続的な監視と対話: ビジネス環境の変化により言葉の定義（計測ルールなど）は変わります。定期的に意味のズレがないか、ビジネスサイドとITサイドで確認するフローを構築します。
技術はあくまで支援役であり、定義の「オーナーシップ」は現場とITが共有すべきものです。
成功への道筋：AIを「翻訳者」として使いこなすための3ステップ
ここまで、あえて厳しい現実を論理的に解説してきましたが、悲観する必要はありません。正しいアプローチを取れば、NLPはデータガバナンスの強力な武器になります。
AIを「魔法使い」ではなく、ビジネスとシステムの間の優秀な「翻訳者」として育てるための3つのステップを、具体的にご紹介します。
ステップ1：スコープを絞った「正解データ」の整備
いきなり全社のデータを対象にしてはいけません。まずは特定の部署、特定の業務ドメイン（例：営業領域や顧客管理）に絞りましょう。
そして、その領域における「正解となる用語集（Glossary）」を人間が手動で作ります。ここだけは地道な作業が必要です。主要なビジネス用語30〜50個程度で構いません。それぞれの用語に対して、意味、計算式、類義語を定義します。
これがAIにとっての「教師データ（Ground Truth）」となります。質の高い教師データがなければ、AIは迷子になります。適切に導入した場合、最初に「顧客ID」周りの定義だけを徹底的に固めることで、その後のAIによる名寄せ精度が80%台から95%以上に向上する事例もあります。
ステップ2：AIによる揺らぎ検知と人間による承認フローの確立
次に、整備した正解データをベースに、NLPツールを導入します。ここでのAIの役割は、システム上のメタデータ（カラム名やテーブル定義）をスキャンし、正解用語との関連性をスコアリングすることです。
- 「この『uriage_kin』カラムは、用語集の『売上金額』と95%の確率で一致します」
- 「この『customer_id』は、『会員ID』の可能性があります」
このようにAIが候補を提示（サジェスト）し、データスチュワードが「承認」または「修正」を行うワークフローを構築します。人間が修正した結果は、再びAIの学習データとなり、次回の提案精度が向上します。このサイクルを回すことで、AIは「自社の文脈」を学習していきます。
ステップ3：用語集を日常業務に埋め込む仕組みづくり
最後に、作成した用語集が「使われる」仕組みを作ります。ここでNLPの力が発揮されます。
例えば、社内チャットツール（SlackやTeams）にBotを常駐させます。「LTVってどういう定義？」と聞くと、整備された用語集からAIが回答してくれる仕組みです。あるいは、BIツール（TableauやPower BI）でレポートを作成する際に、用語の定義がツールチップで自動表示されるように連携します。
「わざわざ用語集を見に行く」のではなく、「業務の中に定義が溶け込んでいる」状態を作ることで、データ定義とビジネス用語の乖離は自然と埋まっていきます。
まとめ
データ定義とビジネス用語の同期において、NLPは強力なサポーターですが、全自動の解決策ではありません。実証に基づいたアプローチとして重要なのは、以下の3点です。
- AIに文脈理解を期待しすぎない: 暗黙知は人間が補完する必要がある。
- Human-in-the-loopを前提にする: AIは提案し、人間が決断するプロセスを作る。
- 小さく始めて育てる: 特定領域の正解データを作り、徐々に適用範囲を広げる。
技術はあくまで手段です。本当に大切なのは、その技術を使って「ビジネスとITが同じ言葉で話せる文化」を作ることです。少し遠回りに見えるかもしれませんが、この仮説検証のプロセスを経ることでしか、真に効率的で活用されるデータガバナンスは実現できません。
コメント