生成 AI は日本語の一般的な意味を知っています。しかしあなたの会社での意味は知りません。 オントロジーは、その差を埋めるための仕組みです。
「解約しそうな優良顧客を教えて」と AI に聞けば、答えは返ってきます。問題は、その答えが誰の定義の「優良顧客」なのか分からないことです。
売上への貢献で見る。今期の数字が基準。
継続してくれているかで見る。金額は問わない。
回収リスクで見る。取引額が小さくても優良。
地図に線が引いてあっても、それが道路なのか川なのか県境なのかは、線を見ただけでは分かりません。分かるのは凡例があるからです。
会社のデータも同じです。「顧客」テーブルと「取引先」テーブルが別にあるとき、それが同じものなのか違うものなのかは、データだけを見ても分かりません。
オントロジーは、その凡例に当たります。中身は、言葉の定義（優良顧客とは何か）と、言葉どうしの関係（注文には必ず顧客がいる、店舗は地域に属する）を書いたものです。
人間向けの用語集と違うのは、機械がそのまま読んで使える形式で書く点だけです。
データも同じです。顧客ID という列があるだけでは、
それが発注者なのか請求先なのか担当営業なのか分かりません。
普通のデータベースは、データを行と列の表で持ちます。ナレッジグラフは短い文で持ちます。文はいつも、主語・述語・目的語の 3 つ組です。
表では、関係は「列」として押し込まれます。顧客ID という列名から、人間が意味を推測するしかありません。
文では、関係そのものに名前が付きます。だから後から関係を追加できます。そして何より、関係を次々に辿れます。
文が増えると、同じ言葉が何度も現れます。この重なりを辿れるようにすると、点（もの）と線（関係）のつながった網になります。これがグラフです。
「注文 1024」が 2 つの文に出てきます。この重なりが、点と線の網をつくります。
グラフの価値がはっきり出るのは、いくつもの関係を辿らないと答えられない質問です。質問を選ぶと、グラフ上で辿る道筋が光ります。
いずれも「AI が賢くなる」話ではなく、AI に渡す前提が整う話です。
定義を一箇所に置き、すべての AI がそれを参照します。
これまで：担当者がプロンプトに定義を貼り、更新のたびに全アプリを直すCRM の「顧客」と請求系の「取引先」を同じものとして扱えます。データを 1 か所に集める必要はありません。
これまで：突合表を Excel で管理し、片方が変わると壊れるどの定義の、どのバージョンに基づく答えかが記録に残ります。
これまで：AI の答えの根拠を、人が改めて調べ直すW3C の国際標準で書くため、製品やクラウドを変えても定義は資産として残ります。
これまで：ツールを変えると、蓄積した定義を作り直す提案の前提を揃えるため、よくある誤解を先に書いておきます。
モデルの性能は変わりません。変わるのは AI が参照する前提の正確さです。前提が曖昧なままモデルを大きくしても、答えは曖昧なままです。
既存システムはそのまま使います。オントロジーはその上に載る意味の層です。データを全部移す必要はありません。
組織が変われば言葉も変わります。だからバージョン管理と承認の流れが要ります。作る仕組みより、更新し続ける仕組みが重要です。
ひとつの業務領域から始めます。領域ごとに区切って持てるので小さく作って育てられます。全社の合意を待つ必要はありません。
順番に意味があります。棚卸しをせずに定義を書くと、既存システムと合わない定義ができます。
既存システムのテーブル定義、項目名、社内文書を集めます。「どんな言葉が、どこで、どう使われているか」を洗い出す段階です。AI で下書きを作り、作業量を圧縮できます。
用語と関係の候補を作り、業務の専門家が承認します。ここは自動化しません。誰が承認したかが、後で答えの根拠になるからです。承認済みの定義だけが公開されます。
承認済みの定義を、AI エージェントと業務システムに提供します。AI 側には読み取り専用で渡すため、エージェントが定義やデータを書き換えることはありません。
スパークル と読みます。非技術者向けの説明資料です。図中の製品・顧客・店舗はすべて架空の例です。 Azure、Microsoft、AWS、Amazon は各社の商標であり、本資料はこれらの企業と提携・承認関係にありません。