こんにちは！データエンジニアの myshmeh です。
前回の記事では、データ分析エージェントの精度向上を題材に、オントロジーと Semantic Layer は対立するものではなく、互いに補完しうる関係なのではないか、という観点を整理しました。
本記事ではその続編として、実際のオントロジーツールに触れ、それぞれの利点に踏み込みます。具体的には、形式論理の取り入れ度合いが異なる Microsoft Fabric IQ と Protégé を通じて、 Semantic Layer と比較した際の特徴と、実務に取り入れる際の難しさを整理してみたいと思います。
オントロジーのいろいろ
オントロジーを試す前に、オントロジーは定義が一つに定まらない領域であることを押さえたいと思います。
オントロジーは、哲学に端を発する領域で、業界によって様々なニュアンスを含みます。特にテック業界では、「概念の構造的定義」のような立ち位置で説明されることが多いですが、何を持って「構造的定義」とするかは、人によって異なり曖昧な気がしています。
いくつかツールを見てみると、オントロジー・知識グラフと称される多くは、「概念の構造的定義」に形式論理をどれだけ持ち込むかという、スペクトラムで分類できる印象を持ちました。
例えば、スペクトラムの軽い側は概念とその関係をグラフで表し記述内容をクエリ可能にする一方、重い側は記述内容のクエリに加えて論理に基づく演繹的推論まで可能にしています。
形式論理とは？
ざっくり言えば、ある主張を、記号を用いて構造的に表現して、当該主張の理屈が通るか示す数学分野です。これを取り入れると、オントロジーでは、「 P ならば Q 」「 P かつ Q はありえない」といったルールを書けば、ツールがその帰結や矛盾を自動で導いてくれます。具体的なイメージは、後段の Protégé デモで掴んでいただければと思います。
では、上記の両端のアプローチにはどんな特徴があるのでしょうか？ここからは、 1 つ目の具体例に Microsoft Fabric IQ を、 2 つ目に伝統的オントロジーツールである Protégé を用いて、それらを紹介したいと思います。
オントロジーのそれぞれ
Microsoft Fabric IQ
Microsoft Fabric IQ は、「 OneLake 全体に配置されたデータを統合し、ビジネスの言語に従って整理するためのワークロード」です。
MS Fabric のストレージである OneLake には、 lakehouses 、 eventhouses および Power BI セマンティックモデル等のデータが個々に閉じた状態で管理されています。 Fabric IQ は、これらを一貫性のあるモデルでまとめて、統合的なデータアクセスを可能にすることを目的の一つとしています。加えて、当該モデルをグラフ形式で表現し、概念間の関係を走査可能にすることで、 AI によるデータの説明の品質を上げることも目的の一つに挙げられています。特に後者は、本記事の趣旨である「軽いオントロジー」の代表的な利点であると思います。
基本概念
Fabric IQ では、主に以下の概念を扱って、関心事をオントロジーとして記述します。
- Entity types: ビジネス上の関心事。
- Static properties: Entity に紐づく属性。テーブルのカラムに相当する。
- Data bindings: Entity に対応するテーブル定義。
- Relationship types: Entity 同士の関係。
利用例
これら基本概念を定義すると、次のようなグラフ構造が出来上がります。
出典 https://learn.microsoft.com/en-us/fabric/iq/ontology/tutorial-3-preview-ontology
Freezer/Store/SaleEvent が Entity 、それらを結ぶ矢印が Relationship types に当たります。各 Entity には対応するテーブルデータが bind されるため、画像下部の赤枠のように、データ間の関係性をクエリできます。
加えて、下図のように、Fabric data agentという、自然言語 Q&A エージェントをオントロジーに連携させることができます。 Store や Freezer という概念が参照されていることがわかると思います。
オントロジー作成方法の詳細に関しては、次の公式チュートリアルを参照いただければと思います。
何が嬉しいの？
ここまでで、 Fabric IQ では、異なる OneLake リソースのデータをビジネス上の言語で統合するため、オントロジーが使われていることがわかりました。
では、 Semantic Layer と比べて、本オントロジーを用いる利点は何でしょうか？特に、前段で触れた、形式論理を用いないオントロジーとしての利点はどうでしょうか？
私は、何よりもまず、グラフという表現形式による恩恵があると思います。具体的には、オントロジーは、グラフ構造を用いて、特定のノードに隣接するノードとその関係性をクエリすることができます。したがって、 AI エージェントに任意のドメイン知識を構造的に参照させ、品質の高いアウトプットを促すことができます。
次に、オントロジーは特定データウェアハウスのデータに閉じない、よりビジネスの関心を反映したモデリングができます。例えば、 Fabric IQ では、 OneLake のリソースを跨いだオントロジー構築をサポートしています。これによって、 AI エージェントは、オントロジーにアクセスするだけで、データ基盤全体のコンテキストを取得することができるようになります。
まとめると、形式論理を用いない「軽い」オントロジーでも、 Semantic Layer にない恩恵が得られることがわかりました。では、形式論理まで踏み込んだ「重い」側では、これに加えてどのような世界が広がっているのでしょうか？ Protégé を通じて、それを覗いてみたいと思います。
Protégé
Protégé は、スタンフォード大学が開発する、 OSS のオントロジーエディタです (参考: Protégé 公式サイト)。 1987 年の初版以来 30 年以上にわたって開発が続いており、以下のように生物・医学領域等で採用されています。
Fabric IQ が「データ統合のためのオントロジー」を志向していたのに対し、 Protégé は OWL (Web Ontology Language) という、形式論理を用いたオントロジー言語をベースにしています。その特徴として、概念やその関係性を論理的に厳密な形で記述でき、その記述を基に reasoner による推論を扱える事が挙げられます。したがって、 Protégé は、本記事でいう「スペクトラムの重い側」の 1 例と言えると考えています。
ここからは、便宜のためにあえて形式論理の詳細には深く立ち入らず、 Protégé の基本と利用のイメージを紹介する形で、 Protégé の魅力を紹介したいと思います。
基本概念
基本方針として、 Protégé では、対象ドメインと対応するルールを定義して、それらルールの整合性や、導かれる新たな論理的帰結を明らかにしていきます。
対象ドメインの定義には、主に次の構成要素を使います。
- Class: 個体の集合です。 Class は、階層で定義することもできます。 e.g. 寿司、マグロ寿司
- Individual: 具体的な個体です。 e.g. 今夜握った 1 貫目のマグロ寿司、 2 貫目のマグロ寿司
- Object Property: 個体間の関係です。 e.g. 寿司にはネタが乗っている
下図の例だと、円が Class 、ダイヤが Individual 、矢印が Object Property に相当します。
出典: An Introduction to Ontology Engineering (Maria Keet)
ルールは、上記の構成要素を組み合わせて定義します。代表的な形は以下の 2 つです：
- 「寿司は和食の一種である」のような、クラス間の包含関係
- 「巻き寿司は必ず何らかのネタを巻く」のような、個体間の関係
デモだぞ
ここで、実際に Protégé を用いて簡単なオントロジーを作成し、形式論理がもたらす恩恵を噛み締めてみましょう！
今回は、日本人の魂である寿司のオントロジーを作ってみます。具体的には、 Class をざっくり「寿司」と「寿司ネタ」に分けて、寿司がネタをどう使っているかを Object Property として定義します。
デモ環境の設定
では、早速、 Protégé で上記 Class を作成します。 Protégé では、全ての Class は、大元の Thing Class の子集合として定義します。
一旦、好きなマグロ寿司とかっぱ巻きを NamedSushi の子集合として定義してみました。併せて、対応するネタも SushiTopping 内の子集合として定義しています。
Sushi > NamedSushi に寿司を、 SushiTopping > Fish/VegetableTopping に寿司ネタを定義
ちなみに、 FishTopping と VegetableTopping は同居しない（ i.e. 魚であって野菜でもあるものはない）ので、これらを Disjoint だと指定しました。
FishTopping の説明欄に、 VegetableTopping が Disjoint であると指定されている
次に、 Object Property (i.e. 関係) として、各寿司がネタをどう扱うかを定義します。マグロ寿司はマグロを乗せます。一方、かっぱ巻きはきゅうりを巻きます。したがって、これら 2 つの関係を、 putsTopping 、 rollsTopping と定義してみました。
topObjectProperty直下に 2 つの Object Property を定義
ここで、「寿司はネタを puts/rolls する」というように主語・目的語を限定するための設定もしておきます。下図のように、 Domain (ここでいう主語) に Sushi 、 Ranges (ここでいう目的語) に SushiTopping を指定しました。
最後に、各 Sushi Class に、上記 Object Property を用いてルールを設定していきます。 MaguroSushi は、「マグロ寿司はマグロを乗せる」という意味で、 putsTopping some MaguroTopping とルール指定します。同様に、 KappaMaki は、 rollsTopping some KyuriTopping と指定しました。
これで、ベースとなるオントロジーができました。図に起こすとこんな感じです。
では、ここから、形式論理がもたらす 2 つの恩恵をみてみましょう！
嬉しさ 1/2: 自動分類
Protégé では、ある Class の子 Class をロジックによって指定することができます。
例えば、握り寿司と巻き寿司という Class を新たに作ります。
握り寿司は、寿司であって、何らかのネタを乗せたものです。したがって、 Equivalent To （同等なもの）フィールドに、その旨を指定します。
同様に、巻き寿司は、何らかのネタを巻いたものとして指定します。
ここで、 Reasoner > Start reasoner を押してオントロジーを推論システムにかけます。すると、勝手に NigiriSushi に MaguroSushi が、 MakiSushi に KappaMaki が分類されてます！
ここで、面白い例として、マグロの軍艦巻きを NamedSushi に追加します。マグロの軍艦巻きは、よく見るとマグロというネタを乗せてもいれば、海苔で巻いてもいるので、この寿司店では握り・巻き寿司どちらでもあると整理したとしましょう。下図のように、 puts/rollsTopping some SushiTopping とルールを加えます。
改めて、推論システムを走らせると、下図のように、軍艦巻きが NigiriSushi 、 MakiSushi の両方に分類されているのがわかります！
ここまでの出来事を図に反映すると、以下のようになると思います。
ルールから、機械的に寿司種別が分類された
このように、 Protégé では、ルールの積み重ね（形式論理）を駆使して、明示していない事実が自動的に導出されます。特に、本例の軍艦巻きのような、会社独自のドメイン知識が整合性を持って表現できることは、アツいポイントだと思っています。
嬉しさ 2/2: 不整合検出
Protégé は、定義したルールに反するオントロジーの更新を見逃しません。
例えば、タラの芽（ TaraNoMeTopping ）という山菜をネタに追加するとします。寿司職人は VegetableTopping の子集合に追加しましたが、助手が誤って鱈と思い FishTopping の子集合に追加したとしましょう。
そんなことあるんか？というのは置いておいて...
推論システムを走らせると、 TaraNoMeTopping が赤くなっています！
TaraNoMeTopping の説明欄は、 Equivalent To が Nothing になっていて、そのような Class の個体が存在できないことを示しています。
この時、 Nothing の右側の"?"アイコンを押すと、なぜ Nothing なのかの説明を参照できます。下図の通り、 FishTopping と VegetableTopping は Disjoint と定義されています。したがって、魚であり野菜であるネタは同居できないわけです。
Explanation 1 の 3 行目に FishTopping DisjointWith VegetableTopping とある
このように、 Semantic Layer や軽いオントロジーでは人間・ AI エージェントに頼りきりのドメイン記述の整合性が、 Protégé では、推論システムによって機械的に担保することができます。結果として、 AI エージェントの参照先として、より厳密なコンテキストを提供する事が期待できます！
小まとめ: Fabric IQ vs Protégé
ここまでで、スペクトラムの両端に位置するツールを駆け足で見てきました。
両者に共通する Semantic Layer にはなかった強みは、グラフ表現によるビジネスドメインの記述力です。「店舗は冷蔵庫を運用する」「マグロ寿司はマグロを乗せる」のように、 SQL の JOIN に縛られない、ビジネスの言葉そのままの関係性を表現できる点は、両者ともに大きな恩恵だと思います。
一方で、形式論理をどれだけ取り入れるかによって、それぞれの強みは大きく異なる印象を持ちました。
Fabric IQ (軽い側) では、概念とその関係性を構造的に記述することで、 AI エージェントがドメインを構造的に参照する土台を提供してくれます。導入のハードルが低く、 OneLake のリソース統合という文脈にも馴染みやすい一方で、記述内容の整合性や、明示していない事実の導出は、人間（ないし AI ）の解釈に委ねられます。
Protégé (重い側)では、推論システムによって、明示していないルールの帰結を機械的に導出し、定義の不整合まで自動で検出してくれます。「軍艦巻きは握り・巻きの両方に分類される」「魚かつ野菜のネタは存在し得ない」というような、独自・複雑なドメイン知識を、整合性を持って表現したい場面では、心強い味方になる印象です。
つまり、ざっくり整理すると、軽い側は AI エージェントとの相性とドメインの記述力を、重い側はそれらに加えて推論による厳密性を、それぞれもたらしてくれると言えそうです。
…と、ここまでだと「じゃあ用途に応じて使えば良い」という綺麗な結論になりそうですが、実際に触ってみると、どちらにもなかなか悩ましいところがあります。次節では、その「もやもや」を整理してみたいと思います。
オントロジーのもやもや
しかし難しいわけでだな
ここまで、 Fabric IQ と Protégé で、オントロジーの良さに目を向けましたが、それぞれに無視できない難しさも感じました。
まず、 Fabric IQ 含む軽いオントロジーでは、推論機能は限定的と思われます。つまり、「冷蔵庫が店舗を運用する」というような誤った関係性が記述されても、ツールは何も言ってくれません。結果として、オントロジーの整合性や妥当性は、書き手に委ねられることになります。オントロジーが小さいうちは問題なくても、複雑になるにつれて、維持コストは上がりそうです。推論がないことで、皮肉にも AI を誤解させる材料にならないかは、注視すべきポイントだと思いました。
一方、 Protégé は形式論理の力で整合性を機械的に保証してくれる代わりに、利用する側に相応の CS 知識を要求してきます。私自身、オントロジーに入門する中で、集合論、記述論理等の領域がないと理解が難しいと感じる点が多くありました（実際、本記事では大分説明を省き、単純化しました）。組織として継続的にオントロジーを保守していくとなると、一般的なデータエンジニアに任せるには、ハードルはなかなか高い印象です。加えて、データエンジニアリング領域で厳密なオントロジーの先行事例が乏しい（と思われる）状況で、自社のドメイン記述に向き合っていく覚悟も問われそうです。
こうして両者の難しさを並べてみると、「導入しやすさ」と「厳密な推論」のトレードオフがあり、どちらを選んでも、保守コストが高そうです。したがって、執筆時点では、安易にオントロジーを導入するのは避けたほうが良い印象を持ちました。
使い分けの私見
最後に、現時点での使い分けの私見を書いてみます。
前段の通り、オントロジーの恩恵は大きい一方、運用コストが高そうです。したがって、自社ドメインの複雑さや AI 活用の重要度と天秤にかける必要があると思いました。
つまり、ドメインがシンプル・小規模なら、オントロジーまで踏み込まず、 Semantic Layer + アナリストの工数で十分なケースは多そうです。多少のドメイン知識は、テーブル等の説明欄に記載することで対応できるのではないでしょうか。
他方で、ドメインが複雑または AI 活用が事業上重要なら、オントロジーの導入価値はあると思います。ただし、いきなり Protégé 的な厳密なアプローチに飛び込むのではなく、 Fabric IQ のような軽いものでドメインの形を掴み、必要に応じて厳密性を上げていく流れが安全かなと感じます。
とはいえ、まだ私も使ってみた段階ですし、データエンジニア業界で便利ツールも登場するだろうから、引き続きキャッチアップしていきたいと思っています。
まとめ
いかがでしたでしょうか？本記事では、 Fabric IQ と Protégé を通して、形式論理の有無というスペクトラムでオントロジーの特徴を眺めつつ、 Semantic Layer と比べた利点と、実務に取り入れる際の難しさを考えてみました。
いずれにせよ、オントロジーは、データエンジニア業界でこれからも注目されてくとは思いますので、引き続きウォッチしていきたいです。もし、データ基盤周りでのオントロジー事例をご存知でしたら、ぜひ教えてください！
本記事が、オントロジーとは何かのヒントになれば幸いです。お読みいただきありがとうございました。
「AI時代だからこそ、 Data Engineering の基礎を固めていきたい」という思いで発足したデータエンジニア2名によるグループです。発信を通して私たちも学んでいきたいと考えているので、フィードバックや感想などいただけるととても嬉しいです！
Discussion
とろたくの居場所も作ってあげてください。
たくあん作って...
「とろたく巻き」を
NamedSushi配下に作成して、マグロとたくあん巻いたやつと定義して...へいお待ち！
