顧客のドメインをモデルへ — ユビキタス言語からオントロジーまで

はじめに — 顧客のモデルは大半が人の頭の中にある
最も安い第一歩 — ユビキタス言語
境界づけられたコンテキスト — 同じ単語が別のものを指すとき
名詞をモデリングする — エンティティ、値オブジェクト、集約
三つの語を切り分ける — タクソノミー vs オントロジー vs ナレッジグラフ
形式スタック — RDF、RDFS、OWL、そして schema.org
運用スタック — プロパティグラフとPalantirのオントロジー
形式オントロジーはいつ元が取れるのか
失敗モード — 美しいが誰も使わないオントロジー
おわりに — 概念ではなく問いから
参考資料

はじめに — 顧客のモデルは大半が人の頭の中にある

Forward Deployed Engineerが顧客先に初めて着任したとき、最も価値ある資産はたいていどのデータベースにもありません。それは20年現場を守ってきた保全リーダーの頭の中に、査定担当者の指先の感覚に、配車担当が「いや、それは普通そうやらない」と言うときのあの暗黙知に宿っています。

FDEの中核的な仕事の一つは、この散らばった暗黙知をチーム全体が共有でき、機械が読める明示的なモデルへ変えることです。この記事はそのはしごを下から上へ登ります — 最も安く価値の高い第一歩であるユビキタス言語から、形式オントロジー(RDF/OWL)を経て、運用オントロジー(プロパティグラフとPalantir流のオブジェクト+リンク)まで。役割そのものはFDEクラフト深掘りとForward Deployed Engineerを目指すで扱ったので、ここでは「ドメインをモデルに変える」という一つの技芸に集中します。

そして最初に正直に言っておきます。オントロジーは最も過剰設計されやすい成果物であり、最も多い失敗は美しいが誰も使わないオントロジーです。この記事の半分は、その罠を避ける話です。

最も安い第一歩 — ユビキタス言語

形式グラフを描くずっと前に、ほぼ無料で高レバレッジの一手があります。Eric EvansのDomain-Driven Designが言う**ユビキタス言語(ubiquitous language)**です。Martin Fowlerはこれを「開発者と利用者の間に共通の、厳密な言語を築く実践」と要約します。

肝は厳密さです。Evansの言うとおり「ソフトウェアは曖昧さをうまく扱えない(software doesn't cope well with ambiguity)」からです。現場で「設備」「装備」「資産」「号機」が人によって別のものを指しているのに、誰もその違いを名指ししなければ、その混乱はそのままコードに流れ込みます。

だからFDEの最初の成果物はグラフではなく用語集です。ドメイン専門家と向き合い、同じ単語を繰り返し使い返し、ぎこちない・不正確な箇所を互いに指摘して磨く。Fowlerが述べるとおり、ドメイン専門家は意味がぼやける用語に異議を唱え、開発者は設計を崩す曖昧さを捕まえます。この対話そのものがモデルを検証します。そしてこの言語は、会議でも、コードでも、画面ラベルでも、DBのカラム名でも同一に使われねばなりません。翻訳レイヤーが生まれた瞬間、バグが生まれます。

境界づけられたコンテキスト — 同じ単語が別のものを指すとき

大きな組織で、ユビキタス言語を一つに統一しようとする試みはたいてい失敗します。Fowlerは理由を明言します — 「大規模システムでドメインモデルを完全に統一するのは、実現可能でも費用対効果的でもない」。

彼の例が正確です。ある電力会社で「meter(メーター)」という語は「組織の部分ごとに微妙に異なるもの」を指しました — あるチームには系統への接続点、別のチームには顧客との契約関係、また別のチームには壁に付いた物理装置。会話ではぼかして済ませられても、「精密なコンピュータの世界では」できません。

DDDの答えは強引な統一ではなく**境界づけられたコンテキスト(bounded context)**です。言語が変わる境界でモデルを分け(「言語が変われば別のモデルが要る」)、コンテキスト間は明示的なマッピングでつなぐ。FDEにとってこれは贅沢ではなく生存技術です。保全部門の「作業指示」と経理部門の「作業指示」が別物だと序盤に捕まえ損ねれば、数か月後の統合フェーズでその代償を払います。

名詞をモデリングする — エンティティ、値オブジェクト、集約

言語が定まったら、名詞に構造を与えます。DDDは三つの道具をくれます。

エンティティ(Entity)。 時間を通じて続く同一性を持つもの。ポンプA17は部品を替え位置を移しても、やはり同じポンプです。属性が同じでも別個体なら、それはエンティティです。
値オブジェクト(Value Object)。 同一性を持たず属性だけで定義されるもの。金額(100, JPY)やGPS座標のように交換可能で、たいてい不変です。同じ値なら同じものとして扱います。
集約(Aggregate)。 Fowlerの定義で「一つの単位として扱えるドメインオブジェクトの塊」。注文とその明細行が代表例です。塊ごとに集約ルートがあり、「外部からの参照はルートにのみ向かうべき」で、「トランザクションは集約の境界を越えるべきでない」。

集約がなぜ重要かというと、それがそのまま一貫性の境界だからです。作業指示・保全項目・使用部品を一つの集約にまとめれば、何を原子的に変えるべきで、何が独立に変わってよいかがそのまま見えてきます。この判断は、後のグラフスキーマとトランザクション設計へそのまま引き継がれます。

三つの語を切り分ける — タクソノミー vs オントロジー vs ナレッジグラフ

ここで人が最もよく混同します。三つの語は別のものを指します。

タクソノミー(taxonomy) は階層分類です。is-a関係一つで概念をツリーに掛けます。図書分類や商品カテゴリがそうです。
オントロジー(ontology) はOntotextの定義で「ある領域内の概念群と、それらの間に成り立つ関係を形式的に記述したもの」です。タクソノミーと違い「関係を表現し、複数の概念をさまざまな仕方で互いに結びつける」。つまり一つの階層ではなく多方向の関係網です。
ナレッジグラフ(knowledge graph) は、そのオントロジーを実際の事実へ適用した結果です。Ontotextの言うとおり「オントロジーのデータモデルを個々の事実の集合に適用してナレッジグラフを作る」。オントロジーはスキーマ、ナレッジグラフはそのスキーマで満たした実データです。

タクソノミー (分類): 階層一つ。is-a のみ。
  Asset
   +- Pump
   +- Motor

オントロジー (スキーマ): 概念 + 関係の「種類」。多方向。
  Asset      --hasPart-->      Part
  WorkOrder  --services-->     Asset
  Technician --qualifiedFor--> AssetType

ナレッジグラフ (事実): オントロジーを実データへ適用。
  Pump#A17 --hasPart--> Seal#9        (一つの事実 = ノード + エッジ)
  WO#4421  --services--> Pump#A17

一文で言えば、オントロジーが「構造を記述して、ナレッジグラフがデータを捉える舞台を整える」(Ontotext)。だから「オントロジーを作ろう」と「ナレッジグラフを作ろう」は別の作業です。前者はスキーマ設計、後者はデータパイプラインです。

形式スタック — RDF、RDFS、OWL、そして schema.org

形式オントロジーをきちんとやるなら、セマンティックウェブ・スタックの三層を学びます。

RDF はトリプルモデルです。あらゆる事実を(主語、述語、目的語)で書き、各要素をURIで全域的に識別します。「データをそのスキーマから切り離し」複数の出所を一つにつなぐのが肝です。
RDFS(RDF Schema) はここにクラスとプロパティ、そしてsubClassOfのような階層を載せます。つまりタクソノミー水準のスキーマです。
OWL は論理を加えます。クラス、オブジェクトプロパティ(個体-個体)、データタイププロパティ(個体-値)、そして個体(individual)。さらに論理構成子(and/or/notで「Mother = Woman AND Parent」)、カーディナリティ(「hasChild max 4」)、逆関係(inverse)、推移性(transitive)、関数性(functional)、対称性(symmetric)、素(disjoint)宣言が付きます。決定的なのは**推論器(reasoner)**が、これらの規則から「帰結を自動的に計算」し、人が見落とす事実を発見することです。

具体的な実物が気になるならschema.orgを見てください。2011年6月にBing・Google・Yahooが立ち上げ、同年11月にYandexが加わったこの語彙は、いまタイプ823個、プロパティ1,529個を収め、ウェブページに構造化データを埋め込む事実上の標準です。オントロジーが学術の玩具ではなく、毎日検索を回すインフラだという証拠です。

運用スタック — プロパティグラフとPalantirのオントロジー

FDEが実際にデプロイするのは、たいていOWLファイルではなくプロパティグラフです。Neo4j流のラベル付きプロパティグラフ(LPG)は四つの部品から成ります — ノード(ドメインの個体)、ラベル(ノードの種類を分類)、リレーションシップ(方向と型を持つエッジ)、そしてノードとリレーションシップの両方に付くプロパティ(キー・値)。RDFトリプルとの決定的な違いがここです。RDFでエッジに属性を付けるには迂回(reification)が要りますが、LPGはリレーションシップがそのまま属性を持ちます。運用クエリやグラフ探索には、こちらがはるかに便利です。

この運用オントロジーの産業的頂点がPalantir Foundryのオントロジーです。Palantirのドキュメントはこれを「組織の運用レイヤー」であり「組織のデジタルツイン」と呼び、二つに分けます。

セマンティック要素 — オブジェクト型(object type)、プロパティ、リンク型(link type)。「既存のデータソースをオントロジーのオブジェクト・プロパティ・リンクへマッピング」して組織の意味を定義します。
キネティック要素 — アクション型(action type)、関数(function)、動的セキュリティ。ここが普通のグラフDBと分かれる点です。アクション型はグラフを読むだけでなく、オペレーターの決定を受けてグラフを変えます。

同じ事実: 「作業指示 4421 がポンプ A17 を保全する」

RDFトリプル:      wo:4421  ex:services  asset:A17 .
プロパティグラフ:  (:WorkOrder {id:4421})-[:SERVICES]->(:Asset {id:'A17'})
Palantirオブジェクト: WorkOrder(4421) --link:services--> Asset(A17)
                    + ActionType: 「保全完了にする」が状態を変える

核心の違いは動詞です。形式オントロジーは世界がどうあるかを記述し、運用オントロジーはその上で何をできるかまで含みます。

形式オントロジーはいつ元が取れるのか

では、いつ重いOWLを持ち出し、いつ実用的なプロパティグラフで十分なのか。正直な判断基準はこうです。

形式オントロジー(RDF/OWL)が元を取る場合:

複数の組織やシステムが同じ意味を共有せねばならないとき。標準語彙、規制報告、機関間のデータ交換のように、相互運用性が本質のとき。schema.orgがウェブ全体で通用する理由がこれです。
推論が実際の価値を生むとき。「これらの規則から論理的に何が導かれるか」が業務上の問いであるとき。規則がよく変わる規制・コンプライアンス領域での規則ベース分類が典型です。
意味が長く生き、複数チームで何年も共有されるべきとき。

実用的なプロパティグラフで十分な場合:

一つの組織の中で、定まった問いに速く答え、グラフを探索・運用するのが目的のとき。FDEプロジェクトの大多数はここに属します。
リレーションシップが多くの属性(いつ、誰が、どれだけ)を持ち、何より速度が重要なとき。

大まかな規則を一つ。推論器が一晩回して発見してくれる新事実が実際に無いなら、OWLの論理装置は大半がコストです。その場合、スキーマ付きのプロパティグラフのほうが正直な選択です。

失敗モード — 美しいが誰も使わないオントロジー

さて、この記事で最も重要な節です。オントロジーのよくある失敗は、間違ったモデルではなく使われない完璧なモデルです。

症状はいつも似ています。半年がかりのオントロジー委員会が開かれ、世界のあらゆる概念を収めた優雅なクラス階層が描かれ、発表は拍手を浴び、その後は誰もそれをクエリしません。データがつながっていないか、ビジネスの問いと無関係か、あるいは両方です。完全性のためにモデリングしたのであって、使用のためではなかったのです。

処方は方向を逆にすることです。概念ではなく問いから始める。 ホワイトボードのクラス図からではなく、ビジネスが今日答えを得られず苛立っている問いのリストから。たとえば — 「来四半期に故障確率が最も高い設備は?」「この作業指示に今投入できる有資格の保全員は?」「倉庫Xにどの部品をどれだけ在庫すべきか?」。これらに答えるのに必要な個体と関係だけをモデリングし、残りは問いが生じるまで先送りします。

もう一つの規律。オントロジーは実データにつながったまま育てるべきです。データに触れないオントロジーは、検証されていない仮説にすぎません。ユビキタス言語と同じく、オントロジーも進化し続ける生きた成果物であるべきです。

おわりに — 概念ではなく問いから

まとめるとこうです。FDEがドメインをモデルに変える仕事ははしごです。土台はほぼ無料のユビキタス言語 — ドメイン専門家とともに厳密な共通語彙を築くこと。その上に境界づけられたコンテキストで同じ単語の衝突を扱い、エンティティ・値オブジェクト・集約で名詞に構造と一貫性の境界を与えます。さらに上には形式スタック(RDF/RDFS/OWL)と運用スタック(プロパティグラフ、Palantir流のオブジェクト+リンク+アクション)があり、どちらを選ぶかは相互運用性と推論が本当に要るかで分かれます。

そして最も正直な助言を一つ。はしごの高い段へ急がないでください。価値の大半は下の二段 — 共有言語と明確な境界 — から生まれます。オントロジーを建てたい誘惑が来るたびに、こう問うてください。「このモデルは、ビジネスが実際に投げかけるどの問いに答えるのか?」 答えが無いなら、それは今建てるべきものがオントロジーではないという合図です。

よく作られたナレッジグラフは、それ自体が終点ではなく、次の段階の土台になります。このグラフをLLM検索の基盤に使うGraph RAGとナレッジグラフ構築は、プロダクションRAGパターンへ続きます。