社内にAIを入れてみた会社から、よく聞く悩みがあります。
「AIが、うちの言葉を分かってくれない」。
たとえば「顧客」という言葉。営業部では商談中の相手も「顧客」ですが、経理部では入金実績のある相手だけが「顧客」です。人間同士なら文脈で読み分けるこのズレを、AIは平気で踏み抜きます。RAG（社内文書検索）を組んでも、営業マニュアルと経理規程を同じ「顧客」で検索して、混ざった答えを返してくる。
この「言葉と構造の問題」に、実は20年以上前から名前がついています。オントロジーです。そして一度は「理想主義的すぎる」とすたれたこの技術が、いまAIの世界で急速に再注目されています。今回はその理由を、流行語としてではなく実務の目線で解説します。
オントロジーとは：AIに渡す「会社の辞書と地図」
オントロジーとは、ざっくり言えば「概念と、概念どうしの関係を、機械が読める形で明示的に定義したもの」です。
- 「顧客」とは何か（定義）
- 「顧客」には「見込み顧客」と「契約顧客」がある（分類関係）
- 「契約顧客」は必ず「契約書」を持つ（制約）
- 「解約」は「契約顧客」にしか起きない（関係のルール）
用語集が「辞書」だとすれば、オントロジーはそこに「地図」を足したものです。言葉の意味だけでなく、言葉と言葉がどう繋がっているか、何が許されて何があり得ないかまで書いてある。
段階で捉えると分かりやすいです。①ただの用語集（言葉と意味のリスト）→ ②タクソノミー（上下関係のある分類ツリー）→ ③オントロジー（分類に加えて、横の関係や制約まで定義）。右に行くほど強力ですが、作る・維持するコストも跳ね上がります。この「コストが跳ね上がる」が、後で述べる歴史的挫折の伏線です。
一度すたれた歴史：セマンティックWebの教訓
オントロジーは2000年代前半、「セマンティックWeb」という構想の中心にいました。Webの生みの親ティム・バーナーズ＝リーが提唱した、「Web全体を機械が意味を理解できるデータの網にする」という壮大な構想です。RDFやOWLといった標準規格も整備されました。
しかし、この構想は主流にはなりませんでした。理由は技術ではなく運用です。
- 書ける人がいない：厳密なオントロジーの記述は専門家の仕事で、現場の人には書けなかった
- 完璧を目指して終わらない：世界を正確にモデル化しようとすると、定義論争が無限に続く
- 書いた瞬間から古びる：業務は変わるのに、オントロジーの更新が追いつかない
つまり「理屈は正しいが、維持コストに人間が耐えられなかった」。これが約20年前の結論でした。
なぜ今、復活しているのか：4つの理由
理由1：LLMの「言葉の曖昧さ」を、構造で補正できる
LLMは言葉の扱いが天才的ですが、その言葉が社内で何を指すかは知りません。冒頭の「顧客」問題です。ここにオントロジー（あるいはその実用版であるナレッジグラフ）を渡すと、AIは「経理文脈の顧客は入金実績あり」という前提で答えられるようになります。
代表例がGraphRAGと呼ばれる手法です。従来のRAGが「質問に似た文書の断片」を探すのに対し、GraphRAGは文書から概念と関係のグラフを作っておき、関係をたどって答えます。「A社の解約に関わった担当者の、他の担当案件は？」のような、複数の関係を渡り歩く質問は、ベクトル検索だけでは原理的に苦手で、グラフ構造の出番になります。
ベクトル検索は「似ているものを拾う」技術、ナレッジグラフは「繋がっているものをたどる」技術。対立ではなく役割分担ですが、後者を支えるのがオントロジーです。
理由2：AIエージェントどうしの「共通語彙」が必要になった
2026年のAI活用の主戦場は、単発のチャットから「複数のAIエージェントが連携して業務を進める」構成に移りつつあります。すると新しい問題が生まれます。エージェントAの言う「タスク完了」と、エージェントBの言う「タスク完了」は同じ意味か？
人間の組織が職務定義書や業務フロー図を必要とするように、AIエージェントの組織にも「共通の語彙と、やりとりの約束事」が要ります。ツール呼び出しのスキーマ定義、エージェント間プロトコル、社内ナレッジの構造化。呼び名は様々ですが、やっていることは全部オントロジーの現代版です。
理由3：「維持コスト」をLLM自身が下げた
歴史の皮肉ですが、オントロジーを殺した「書ける人がいない・更新が追いつかない」問題を、LLMが解決しつつあります。
- 社内文書からの概念・関係の候補抽出をLLMが下書きできる
- 用語のゆれ（「クライアント」「お客様」「取引先」）の検出と統合案をLLMが出せる
- 業務文書が更新されたら、オントロジー側の矛盾をLLMが指摘できる
20年前は専門家が手で書くしかなかったものが、「LLMが下書きし、人間が承認する」体制に変わった。オントロジーはLLMを助け、LLMはオントロジーの維持を助ける。この相互補完が成立したことが、再注目の実務的な最大の理由だと私は考えています。
理由4：データ基盤の世界が先に「意味の層」に到達していた
BI・データ分析の世界では、「セマンティックレイヤー」（指標や用語の定義を一元管理する層）がここ数年で当たり前になりました。「売上」の定義が部署ごとに違ってダッシュボードが信用されない、という古典的な問題への答えです。また、海外ではPalantirが自社製品の中核概念をまさに「オントロジー」と呼び、業務データを意味づけしてAIに渡す設計を前面に出しています。
つまり、AI文脈とデータ基盤文脈の両方から「AIに仕事をさせたければ、まず意味の定義を渡せ」という同じ結論に合流してきたのが現在地です。
現実的な注意点：2000年代の失敗を繰り返さないために
ここまで読むと「よし、うちもオントロジーを作ろう」となりそうですが、20年前の教訓を忘れると同じ失敗をします。
完璧なオントロジーを最初に作ろうとしないこと。 定義論争で半年溶かすのが、この分野の伝統的な死に方です。
更新されないオントロジーは、嘘の辞書になること。 間違った定義をAIに渡すと、AIは自信満々に間違えます。作る計画と同じ重さで、更新の運用（誰が・いつ・何をトリガーに直すか）を決める必要があります。
すべての業務に必要なわけではないこと。 一問一答のFAQボットに重いオントロジーは過剰です。効くのは、複数部署・複数システム・複数エージェントをまたいで「同じ言葉」が飛び交う場面です。
コラム：圏論とはどう違う？
数学好きの方から「それは圏論と何が違うのか」と聞かれることがあります。共通点は、どちらも「もの自体ではなく、関係で世界を記述する」発想であること。図に描くとどちらも「丸と矢印」になります。
違いは役割です。オントロジーは「この業務ドメインの語彙と関係を正しく書き写す」ための記述の道具で、正しさの根拠は現実の業務にあります。圏論は、構造と構造の対応関係（関手）まで数学の対象にする変換と抽象化の道具です。たとえるなら、オントロジーが「1つの世界の地図」で、圏論は「地図と地図の間の翻訳規則まで扱う文法」。営業DBと経理DBの語彙をつなぐとき「対応づけが関係構造を壊していないか」と問うのは、圏論でいう「関手が構造を保つか」という問いそのものです。複数部署・複数システムのオントロジーを接続する段階になると、この発想が効いてきます。
実務の始め方：30語の「AI向け用語集」から
弊社がAI導入のご支援でおすすめしているのは、いきなりオントロジーではなく「AIに読ませる前提の用語集を、30語だけ作る」ことです。
- AIによく聞く業務領域から、誤解されやすい用語を30個選ぶ
- 各用語に「定義・含むもの・含まないもの・関連する用語」を1〜3行で書く
- それをAIのシステムプロンプトやRAGの前提知識として渡す
- AIの誤答が出るたびに、用語集の穴として直す
これは実質「軽量オントロジー」の第一歩ですが、専門知識なしで今日から始められて、効果もすぐ体感できます。実際、弊社自身も社内のAI運用基盤で「事業・タスク・承認」といった中核概念の定義と関係を明文化してAIに渡す運用をしており、AIの誤解が減る効果を日々確認しています。用語のゆれが揃うだけで、AIの答えの安定感は目に見えて変わります。
30語で効果を感じたら、分類（タクソノミー）へ、そして関係と制約（オントロジー）へ。段階を上がるのは、必要になってからで十分です。
まとめ
- オントロジーは「概念と関係の機械可読な定義」。AIに渡す会社の辞書＋地図
- 2000年代に維持コストで一度挫折した技術が、LLMの登場で「維持できるもの」に変わった
- ベクトル検索が拾えない「関係」を扱えるため、RAGの精度問題・エージェント連携の語彙問題への答えとして再注目されている
- ただし完璧主義は禁物。「AI向け用語集30語」からの段階導入が現実解