AIの回答が部署で食い違う理由：オントロジーが解く「意味」の断絶

「先月のアクティブ顧客の数を出してくれ」。経営層から飛んできたこの単純な問いに対し、営業部門のAIは『820』と答え、経理部門のAIは『394』と答える。現場のエンジニアなら誰もが一度は経験する、あの胃が痛くなるような「数字の不一致」だ。しかし、ここで重要なのは、どちらのAIもバグを起こしているわけではないという事実である。営業部門のAIはCRMスキーマの『last_contact_at』を参照し、経理部門のAIは請求スキーマの『paid_at』と『amount > 0』を条件にSQLを生成した。どちらも、その部署が日常的に参照している「常識」に従っただけなのだ。

我々エンジニアは、AIを魔法の杖のように扱いがちだが、AIはあくまで「与えられた前提」を忠実に実行する計算機に過ぎない。同じ「アクティブ顧客」という言葉でも、営業にとっては「接触した相手」であり、経理にとっては「入金があった相手」である。この文脈のズレを放置したまま、より高性能なLLMに置き換えたところで、食い違いが解消されるはずがない。むしろ、賢いモデルほど、それぞれの部署の文脈をより深く解釈し、より精緻に「間違った（あるいは目的の異なる）数字」を導き出してしまう。これはAIの精度の問題ではなく、組織内に散らばる「言葉の定義」が誰にも管理されず、コードやExcelの片隅に埋もれているという、構造的な技術負債の問題である。

さらに深刻なのは、システムごとに顧客IDがバラバラに管理されているという現実だ。CRMの『cust_id』、会員基盤の『user_id』、請求システムの『client_no』。これらを突き合わせるための変換表は、誰がいつ作ったのかも定かではないスパゲッティコードの残骸と化している。人間は文脈で補完できるが、AIにはこれらが全くの別物に見えている。この「意味の断絶」を埋めるために、今再び注目されているのが「オントロジー」という概念である。これは単なるデータカタログの再来ではない。AIエージェントが業務に入り込み、自律的にクエリを投げるようになった今、曖昧な定義のままではシステムが崩壊する。我々が直面しているのは、AIを導入する前の「言葉の整理」という、極めて泥臭く、しかし避けては通れないエンジニアリングの原点回帰なのだ。

2000年代のセマンティックWebブームを知るベテランエンジニアにとって、「オントロジー」という言葉は、かつて挫折した理想郷のように響くかもしれない。当時、RDFやOWL、SPARQLといった技術スタックは、確かに強力な表現力を持っていた。しかし、それらを記述するコストはあまりに高く、現場のエンジニアは「そこまでやるならコードにIF文で書く」という現実的な選択を繰り返してきた。MDA（モデル駆動アーキテクチャ）やOCL（オブジェクト制約言語）で厳密なモデルを定義しようと試み、その複雑さと実行速度の低下に絶望した経験を持つ者も少なくないだろう。では、なぜ今、この概念が再びエンタープライズの表舞台に戻ってきたのか。

最大の理由は、供給側と需要側の両面で環境が激変したことにある。供給側では、LLMがオントロジーの下書きを自動生成できるようになった。かつて手作業で数千行の制約を書いていた苦労は、AIの支援によって劇的に軽減された。そして需要側では、AIエージェントという「曖昧さを許容しない」新たなプレイヤーが業務に参画した。人間であれば「まあ、この場合はこうだよね」と文脈で補完できた部分も、AIエージェントは定義がなければ動けない。この「AIという強制力」が、20年前に諦められた記述コストの壁を突破するトリガーとなったのだ。Palantirのような企業が長年培ってきたオントロジーの知見が、生成AIという技術の進化と合流し、今まさに「実行可能なスキーマ」として結実しようとしている。

ここで重要なのは、現在のオントロジーは「実装を生成する」ものではなく、「既存の実装の上に意味の層を被せる」ものだという点だ。既存のDWHやテーブルを破壊することなく、その上に意味的な制約を定義し、AIが参照する経路を統制する。これは、かつてのMDAが目指した「モデルから全てを作る」というトップダウンの理想とは対極にある、極めて現実的でプラグマティックなアプローチである。もちろん、粒度の問題は残っている。どこまで厳密に定義し、どこから先は「割りすぎ」なのか。この問いに対する答えは、20年前と変わらず、現場のエンジニアが試行錯誤の中で見つけ出すしかない。しかし、少なくとも我々には、AIという強力な道具がある。流行のバズワードとして消費するのではなく、この「意味の層」をどう設計し、誰が維持し続けるのかというガバナンスの設計こそが、これからのシニアエンジニアに求められる真のスキルセットとなるだろう。

オントロジーを実装に落とし込む際、最も重要なのは「ドキュメントではなく、実行されるコードとして定義する」という点だ。従来のデータ辞書やExcelの用語集は、作成された瞬間に陳腐化し、誰も見なくなるのが常だった。しかし、オントロジーはクエリの実行経路に組み込まれる。定義に反するクエリはAIが生成できず、あるいは実行時に弾かれる。この「強制力」こそが、従来のデータカタログとの決定的な差である。具体的には、クラス、プロパティ、関係、そして制約を定義し、それらを実データとバインドする。特に「制約」の記述は、機械の世界に現実のルールを教え込むための最も重要なプロセスだ。「仕入先が発注することはない」といった、人間なら自明なルールを明示的に書かなければ、AIは平然とあり得ない経路を辿り、自信満々に誤った答えを返してくる。

以下に、オントロジーが担うべき主要な層と、その役割を整理する。

この構造は、20年前のRDFSやOWLの概念を現代的に再解釈したものに他ならない。しかし、現代の製品はデータをトリプルストアに物理的に移すのではなく、既存のデータ基盤の上に論理的な層を定義する方式が主流だ。これにより、パフォーマンスの低下を最小限に抑えつつ、意味の統制が可能になった。ここで我々が自問すべきは、「アクティブ顧客」という言葉の定義を一本化して片方を捨てるべきか、という問いである。答えは否だ。営業には営業の、経理には経理の目的があり、定義は用途から決まる。減らすべきは数字のバリエーションではなく、言葉の曖昧さである。正式な名前を付け、それぞれの定義を明示することで、初めてAIは「正しい文脈」で回答を導き出せるようになる。

最後に、読者であるエンジニア諸君に問いたい。あなたの現場で、部署ごとに異なる数字が返ってくる時、それは本当にAIの精度の問題だろうか？ それとも、あなた自身が「言葉の定義」という最も重要な設計を放棄してきた結果ではないだろうか。AIエージェントが組織の隅々まで浸透する未来において、エンジニアの価値は「コードを書くこと」から「意味を定義し、統制すること」へとシフトしていく。明日から、あなたのプロジェクトで使われている「曖昧な用語」を一つ選び、それを実行可能なスキーマとして定義してみることから始めてほしい。その小さな一歩が、組織のデータガバナンスを根本から変える鍵になるはずだ。我々は、AIに振り回される側から、AIを正しく導く側へと進化できているだろうか？