雑多煮

雑多に書きとめる個人の記録

オントロジーの入門記事を読むと既視感がある

2026年8月2日

オントロジーという言葉を最近よく見る。Palantirは前からオントロジーこそAIを業務に繋ぐ鍵だと言っていて、2025年11月にMicrosoftがOntologyを含むFabric IQを、2026年6月にDatabricksがGenie Ontologyを発表した。ZennにもQiitaにも入門記事がある。見かけるたびに読んで、そのたびに困惑した。分からなかったからではない。逆で、どれも知っている話に見えたからだ。

数年前は逆向きに困惑していた。当時はDWHのモデリング手法であるData Vaultの本を読んでいて、そこに出てくる「オントロジー」が分からなかった。今は世間がオントロジーと言っていて、それが分かってしまう。二つを突き合わせれば済む話かと思ったら、もう一つ引っかかりが残った。なんで今なんだろう、という。

3000行のSQLがあった

前職に入った頃、データ基盤にモデリングという工程はなかった。ソースシステムからそのまま落としてきたテーブルが並んでいて、売上や契約数はそこから直接集計していた。3000行くらいのSQLが、入社した時点でもう置いてあった。

それでも数字は出る。出るのだが、テーブルを繋ごうとすると、そこで詰まった。user_id同士を結合したら繋がらない。商品を指すIDで繋ごうとしたら、そもそもそのIDを持っていないテーブルがある。代わりに別の識別用の列があって、これはシステムが採番して埋める値ではないから、誰も入れなければNULLのままだ。実際、NULLだらけだった。

このとき覚えたことは単純で、名前は同一性を保証しない。user_idという列名は、それが誰かを識別できることを約束しない。

そのあと、基盤を作り直すことになった。履歴を持てるように層を分けて、その途中でData VaultのHubを作る作業をやった。Hubというのは、顧客や契約といった業務概念（business concept）を識別する業務キー（business key）の一意なリストを持つテーブルのことだ。実物は拍子抜けするほど単純で、hub_customerなら顧客を指すキーが1行に1個ずつ並ぶ。ほかは、いつどこから来たかの列が付くくらい。どのテーブルを写すかではなく、うちの業務には何が「いる」のか、それを何で識別するのかを決めないと作れない。

トランザクションのたびに採番されるIDも、最初はHubにしていた。注文番号や契約番号のように、業務がその番号で対象を追いかけているなら、取引に振られた番号でもHubの資格がある。ただ、うちのその番号は、システムの外では誰も参照していなかった。単一システムの処理に付く、ただの通し番号だった。ソースのテーブルの割り方が、そのままHubの割り方になっていた。あとで少し直したけれど、全部ではない。

本のほうが先にオントロジーと言っていた

その頃はData Vaultを作るために本を読んでいて、そこにオントロジーという言葉が何度も出てくる。企業のオントロジーに合わせてモデルを作れ、というような話だった。

正直、分かるようで分からなかった。哲学の用語がなぜDWHの本に出てくるのか。概念と関係の体系だと説明されても、それはモデリングと何が違うのか。当時は「要するにHubを決めるときの頭の使い方のことらしい」と雑にまとめて、棚に上げた。

雑なまとめだったけど、外してもいなかったと思う。Data Vaultの構造自体がそういう作りになっている。業務概念を識別する業務キーをHubが持ち、どの顧客がどの契約に紐づくかといった関係はLinkが持つ。属性が変わってきた履歴は、HubやLinkの脇に時刻付きで積んでいく（Satelliteと呼ぶ）。何が識別の対象で、何で識別し、何と何が繋がり、それがどう変わってきたか。概念そのものの定義ではない。ただ、この四つを実データの上で持つ仕組みを、この設計は物理層に持っていた。

2026年の記事にも同じ問いがある

オントロジーという語は、哲学にも、RDFやOWLで概念と関係を形式的に書く分野にも前からある。今年の入門記事が説明しているのは、企業向け製品がそう呼んでいるほうだ。業務の概念と関係を機械可読に定義して、AIエージェントにも渡す層。顧客とは何か、契約と顧客はどう繋がるか。それをAIが参照できる形で持て、と。

Hubを作ってLinkを張るときにやっていたことと、問いの一部が重なる。何を概念として立て、何で識別し、どう繋ぐか。

もちろん同じものではない。HubとLinkとSatelliteは、概念や関係の意味を明示的には定義しない。オントロジーでは型や語彙、制約などもモデルの一部になり、企業向け製品はさらに指標やアクション、権限まで扱う。仕様を眺めるほど、扱う範囲は自分が知っていた世界より広く見えてくる。特にルールやアクションの層は別種の難しさに見えるけど、そこで何が起きるのかはまだ語れない。

一つだけ、二つが同じ失敗に別の名前を付けている場所がある。Palantirの公式ドキュメントは、同じ実体をソースシステムごとに別のオブジェクト型（object type）にしてしまう設計をSystem Silosと呼んで戒めている。Data Vault側にも、ソースの技術IDを業務キーとみなしたり、ソーステーブル一つにつきHubを一つ機械的に立てたりするとsource system data vaultになる、という昔からの戒めがある。現実の対象をモデルにしろ、ソースの構造をモデルにするな、と。出発点も語彙も違うのに、同じ禁止が時代をまたいで書き直され続けている。転んだ一回が、うちのuser_idだった。もう一回は、最初に立てたHubの並びそのものだった。

0埋めしないとidが一致しない

問いの一部が昔からあったのなら、なんで今になって騒がれているんだろう。モデリングの重要性なんて何十年も言われてきた。ただ、説かれたから工程が増えた現場を、自分は見たことがない。

先に認めておくと、冒頭に挙げた賑わいの根拠は主として売る側の発表だ。買う側の痛みは、まだ直接見ていない。カテゴリだけが立って痛みが後から見つからなかった例なら、この業界にはいくらでもある。

それでも今回は痛みの側に賭ける。自分が見てきた欠落は、AIに答えを書かせたとき黙って誤りに変わる種類のものだったからだ。

心当たりが一つある。SQLのコメントに、こういうのが書いてあるのを見たことがある。

-- 0埋めしないとidが一致しない

この一行が担っているのは、同一性解決の一部だ。桁を揃えなければ同じものを同じと言えないし、揃えていいかどうかはこの但し書きを知らないと判断できない。その知識はどこのマスターにもモデルにも定義ファイルにもない。書いた本人のクエリのコメントにある。似た但し書きは他のクエリにも散らばっていて、微妙に違うことが書いてあったりする。

コメント自体はテキストだからAIは読める。実際、Genie Ontologyを組み込んだDatabricksのGenie Oneのように、テーブルやクエリや文書から知識の断片を拾って、生成元や使用頻度や鮮度で権威度を採点する製品も出てきた。でも、順位が高いことと正しいことは違う。どれを正としてどの場面に適用するかを決める根拠までは、たいてい書かれていない。人間はそこを、隣の席に聞いたり一度失敗して覚えたりして埋めてきた。

モデリングされていない弊害は、この補修がずっと吸収してきたんだと思う。払われていたのは個人の時間だった。現に前職では作り直しになったし、痛みが顔を出すことはあった。ただ、そのたびに個別の現場の作り直しとして処理されて、また沈む。説く声が効かなかった理由は一つではないだろうけど、少なくとも一つはこれな気がする。痛みが出るのは別々の現場で、まとめて数えられる場所がなかった。

読み手も変わる。概念モデルや定義書は、書いても読むのは人間だった。定義を機械に読ませる仕組みなら、セマンティックレイヤーやスキーマとして前からある。違いは、機械可読かどうかだけではない。これまでは定義の外に残った部分を、最後は人が埋めていた。エージェントも人に聞けるし、Slackを読みにいく製品も出てきた。ただ、聞いて分かったことは、そのままでは管理された共有知識にならない。次のエージェントは、また同じ断片を探すところから始める。

オントロジーの賑わいは、その先回りに見える。人の頭の中にあった補修知識を、管理できる場所へ移す試みなんだろう。新しい概念が生まれたというより、昔からある欠落を沈めておけなくなった、という説明のほうが自分には筋が通る。

「0埋めしないとidが一致しない」と書いたことのある人は、オントロジーの材料をもう持っている。あとはそれをコメントの外に出すだけ、と言いたいところだけど、その「出すだけ」で数年かかったのが前職だった。

参考