{ "componentChunkName": "component---src-templates-post-js", "path": "/saaswoti-cai-nisitaontoroziwozuo-tutemiyousirizu-3-donoji-neng-gashi-erunoka/", "result": {"data":{"ghostPost":{"id":"Ghost__Post__6ad5b842d3fc9f00013c2337","title":"SaaSを題材にしたオントロジーを作ってみようシリーズ #3.5 番外編 セマンティックレイヤー","slug":"saaswoti-cai-nisitaontoroziwozuo-tutemiyousirizu-3-donoji-neng-gashi-erunoka","featured":false,"feature_image":null,"excerpt":"\n作ったオントロジーは、結局どこで使うのか？\n\n\nセマンティックレイヤーという考え方を、手を動かして理解する\n\n\n今回は番外編です。新しいクラスは1つも追加しません。\n\n前回は、FeatureとEntitlementを導入しました。あわせて、Tenantから見たhasEntitlementと、Entitlementから見た\nentitledTenantという、逆プロパティのペアも定義しました。\n\nここでいったんクラスを増やす手を止めて、そこまでに作った語彙が実際どこで役に立つのか\nを確かめます。というのも、ここまで3回クラスを増やしてきて、そろそろこう思っている方がいるはずだからです。\n\nこれ、作ったはいいけど、結局どこでどう使うの？\n\n\nたとえば、実際の業務では次のような問いが出てきます。\n\n株式会社ABCというテナントは、SaaSの機能としての販売管理機能を使えるのか？\n\n\nこの質問に答えるために、あなたは今、どうしますか？\n\n・請求管理システムの契約画面を開いて確認する？\n・社内の管理DBにSQLを投げる？\n・Slackでカスタマーサクセスに聞く？\n\n\nどの方法でも答えは出ます。","custom_excerpt":null,"visibility":"public","created_at_pretty":"19 October, 2026","published_at_pretty":"19 October, 2026","updated_at_pretty":"19 October, 2026","created_at":"2026-10-19T15:27:14.000+09:00","published_at":"2026-10-20T01:55:51.000+09:00","updated_at":"2026-10-20T01:55:51.000+09:00","meta_title":null,"meta_description":null,"og_description":null,"og_image":null,"og_title":null,"twitter_description":null,"twitter_image":null,"twitter_title":null,"authors":[{"name":"Akihiro YAGASAKI","slug":"akihiro","bio":null,"profile_image":"https://ghost.tech.anti-pattern.co.jp/content/images/2022/04/yagasaki--2-.jpeg","twitter":null,"facebook":null,"website":null}],"primary_author":{"name":"Akihiro YAGASAKI","slug":"akihiro","bio":null,"profile_image":"https://ghost.tech.anti-pattern.co.jp/content/images/2022/04/yagasaki--2-.jpeg","twitter":null,"facebook":null,"website":null},"primary_tag":null,"tags":[],"plaintext":"\n作ったオントロジーは、結局どこで使うのか？\n\n\nセマンティックレイヤーという考え方を、手を動かして理解する\n\n\n今回は番外編です。新しいクラスは1つも追加しません。\n\n前回は、FeatureとEntitlementを導入しました。あわせて、Tenantから見たhasEntitlementと、Entitlementから見た\nentitledTenantという、逆プロパティのペアも定義しました。\n\nここでいったんクラスを増やす手を止めて、そこまでに作った語彙が実際どこで役に立つのか\nを確かめます。というのも、ここまで3回クラスを増やしてきて、そろそろこう思っている方がいるはずだからです。\n\nこれ、作ったはいいけど、結局どこでどう使うの？\n\n\nたとえば、実際の業務では次のような問いが出てきます。\n\n株式会社ABCというテナントは、SaaSの機能としての販売管理機能を使えるのか？\n\n\nこの質問に答えるために、あなたは今、どうしますか？\n\n・請求管理システムの契約画面を開いて確認する？\n・社内の管理DBにSQLを投げる？\n・Slackでカスタマーサクセスに聞く？\n\n\nどの方法でも答えは出ます。しかし、問いの意味自体は、どの方法で調べても同じはずです。\n\nこのTenantに、\n販売管理Featureに対する有効なEntitlementが存在するか？\n\n\nこれが、問いの正体です。第3回でFeatureとEntitlementを定義したのは、まさにこの「問いの正体」を書けるようにするためでした。\n\nそして、この「意味の定義」を、複数のシステムから共通で使える形にしたものが、セマンティックレイヤーです。\n\n\n--------------------------------------------------------------------------------\n\n1. セマンティックレイヤーとは何か\n一言でいうと、\n\nセマンティックレイヤー：\n データの意味を一箇所に定義し、\n どのツール・どのシステムからでも\n 同じ意味で問い合わせられるようにする仕組み\n\n\nもう少し具体的にいきます。\n\nセマンティックレイヤーが無い世界:\n\n 請求システム → grantedFeature という項目で機能を持つ\n CRM → enabledFeature という項目で機能を持つ\n 社内DB → entitlements テーブルの feature_id カラム\n\n 3つとも同じことを記録しているのに、\n 呼び名がバラバラで、横断して聞けない。\n\nセマンティックレイヤーがある世界:\n\n 共通語彙 saas:entitlesFeature\n ├── 請求システムの grantedFeature\n ├── CRMの enabledFeature\n └── 社内DBの feature_id\n\n どのシステムのデータでも、1つの問いで横断できる。\n\n\nセマンティックレイヤーの本質は、「どのカラムに何が入っているか」ではなく、「それが何を意味するか」を定義することです。\n\n「レイヤー（層）」と呼ぶのは、これが問い合わせる側とデータの間に挟まる層だからです。\n\n問い合わせる側（人、BIツール、AI）\n │ 共通の語彙で問う\n ↓\nセマンティックレイヤー（意味の定義と、各システムとの対応）\n │ 各システムの書き方の違いを、ここで吸収する\n ↓\n各システムのデータ（請求システム、CRM、社内DB…）\n\n\n間に層が1枚あるので、問い合わせる側は、下にあるデータがどう書かれているかを知らなくても済みます。\n\nそして今回は、この「バラバラの語彙を1つの問いで横断する」ところまで、実際に手元で動かします。\n\nところで、「セマンティックレイヤー」で検索すると、たぶん次のようなものが出てきます。\n\n・Snowflake の Semantic Views\n・Databricks の Metric Views（Unity Catalog semantics）\n・Power BI / Microsoft Fabric の Semantic Model\n・dbt Semantic Layer、Cube、Looker の LookML\n\n\nそして、そこに書かれているのは、だいたいこういう話です。\n\n「売上」「アクティブユーザー数」の計算式を1箇所で定義して、\nどのBIツールからでも同じ数字が出るようにしましょう。\n\n\n一方、このシリーズで作っているのは、Turtleで書いたクラスとプロパティです。計算式は1つも出てきません。\n\nあれ？\nこのシリーズの「セマンティックレイヤー」と、\n世の中の「セマンティックレイヤー」、\n同じものの話をしている？\n\n\n結論から書きます。\n\n同じ言葉で、2つの系統のものが呼ばれている。\n\n メトリクス型：数字の「計算のしかた」を定義する\n オントロジー型：世界の「何が何であるか」を定義する\n\nこのシリーズが作っているのは、後者。\n\n\nこの記事では、まずこの2つの違いを整理してから、オントロジー型のほうを実際に動かします。後半で手を動かしているときに「あれ？」とならないためです。\n\n> 製品の名称や提供状況は動きが速いため、本記事の内容は2026年10月時点の公式ドキュメントに基づいています。出典は末尾にまとめました。\n2つの系統とも、上で書いた「データの意味を一箇所に定義する」という点は同じです。違うのは、「意味」として何を定義するかです。\n\nメトリクス型が定義する「意味」:\n 「月間アクティブテナント数」とは、\n subscriptions テーブルの status = 'active' の行を\n tenant_id で重複排除して数えたもの\n\nオントロジー型が定義する「意味」:\n 「Tenant」とは、Subscription を持ち、\n Entitlement を通じて Feature を利用できる単位であり、\n hasEntitlement と entitledTenant は互いに逆向きの関係である\n\n\n前者は数字の作り方、後者はものごとの関係を定義しています。\n\nこの違いがどこから来たのかを見ていきます。\n\n\n--------------------------------------------------------------------------------\n\n2. メトリクス型セマンティックレイヤーは、なぜ生まれたか\n2.1 出発点は「数字が合わない」問題\nメトリクス型が解こうとしてきた問題は、とても具体的です。\n\n営業のダッシュボード: 今月のアクティブテナント 128社\nCSのダッシュボード: 今月のアクティブテナント 131社\n経営会議の資料: 今月のアクティブテナント 125社\n\n\n3つとも間違ってはいません。トライアル中を含めるか、解約予定を含めるか、月末時点か月中の最大か。計算式が、ダッシュボードごとに少しずつ違うのです。\n\nそこで、「計算式を1箇所に集めて、全員がそれを使う」という発想が生まれました。\n\n2.2 置き場所の変遷\nこの「計算式の置き場所」は、時代とともに移動してきました。\n\n第1世代: BIツールの中\n Looker の LookML、Power BI のデータセット（現 Semantic Model）\n → もともと、そのBIツールのために設計された。\n いまは外部からも使えるが（Looker の Open SQL Interface、\n Power BI の XMLA エンドポイントなど）、\n ツール固有の言語や接続方式に合わせる必要がある。\n\n第2世代: BIツールから独立（ヘッドレス）\n dbt Semantic Layer（MetricFlow）、Cube、AtScale\n → どのBIツールからでも、APIやSQLで同じ定義を使える。\n （dbt の API は dbt platform で提供される）\n\n第3世代: データ基盤の中\n Snowflake Semantic Views、Databricks Metric Views\n → データと同じ場所で、同じ権限管理の下に置かれる。\n\n\nMicrosoft Fabric の Semantic Model は、第1世代の Power BI の Semantic Model\nと同じものかと思います。ただ、Fabric 上では Direct Lake という方式で OneLake\nのデータを直接読めるので、第1世代と第3世代の中間にあたります。\n\nなお、この「世代」は説明のための筆者の整理で、業界やベンダーの公式な区分ではありません。新しい世代ほど優れている、という意味でもありません。いま「セマンティックレイヤー」として話題になっているのが、主に第3世代だということを表現したいため、この整理をしました。\n\n2.3 実際には、こう書く\n第1回で作ったTenant・Subscription・Planが、ふつうのテーブルとしてデータウェアハウスに入っているとして、具体的に見てみます。\n\ntenants (tenant_id, name)\nsubscriptions (subscription_id, tenant_id, plan_id, status, started_at)\nplans (plan_id, plan_name)\n\n\nここで、次の問いを考えます。\n\nQ1. プラン別に、毎月いくつ新しい契約が始まっているか？\n\n\n※Q2は9章で出てきます。\n\nSnowflakeのSemantic Viewでは、こう定義します。\n\n-- あくまでもイメージで、動作保証はないです\nCREATE SEMANTIC VIEW subscription_sv\n TABLES (\n subscriptions PRIMARY KEY (subscription_id),\n plans PRIMARY KEY (plan_id)\n )\n RELATIONSHIPS (\n subscriptions (plan_id) REFERENCES plans\n )\n DIMENSIONS (\n plans.plan_name AS plans.plan_name,\n subscriptions.start_month AS DATE_TRUNC('MONTH', subscriptions.started_at)\n )\n METRICS (\n subscriptions.new_subscriptions AS COUNT(DISTINCT subscriptions.subscription_id)\n )\n COMMENT = 'プラン別・月別の新規契約';\n\n\n使う側は、計算式を知らなくても、こう問い合わせるだけです。\n\nSELECT plan_name, start_month, AGG(new_subscriptions)\nFROM subscription_sv\nGROUP BY plan_name, start_month;\n\n\nDatabricksのMetric Viewでは、YAMLで同じことを書きます。\n\n-- あくまでもイメージで、動作保証はないです\nCREATE VIEW main.saas.subscription_metrics\nWITH METRICS LANGUAGE YAML AS $$\nversion: 1.1\nsource: main.saas.subscriptions\njoins:\n - name: plan\n source: main.saas.plans\n on: source.plan_id = plan.plan_id\nfields:\n - name: plan_name\n expr: plan.plan_name\n - name: start_month\n expr: DATE_TRUNC('MONTH', started_at)\nmeasures:\n - name: new_subscriptions\n expr: COUNT(DISTINCT subscription_id)\n$$;\n\nSELECT plan_name, start_month, MEASURE(new_subscriptions)\nFROM main.saas.subscription_metrics\nGROUP BY ALL;\n\n\n書き方は違いますが、やっていることは同じです。\n\n2.4 メトリクス型の「共通の形」\n製品は違っても、中身の構成要素はほぼ共通しています。\n\n論理テーブル どのテーブルを使うか\nリレーション テーブル同士をどう結合するか\nディメンション どの切り口で分けるか（プラン別、月別…）\nメジャー 何をどう集計するか（COUNT, SUM, 比率…）\n同義語・説明 人間とAIのための補足\n\n\nそして、問い合わせ方も共通しています。\n\nSnowflake AGG(new_subscriptions)\nDatabricks MEASURE(new_subscriptions)\nCube MEASURE(...)\nLooker AGGREGATE(...)\n\n\nAGG()やMEASURE()は、「定義側に書いてある集計式（ここではCOUNT(DISTINCT …)）で集計して」という指示です。使う側は、COUNTや\nSUMを自分で書く必要がありません。\n\n集計のしかたは定義側が持ち、使う側は切り口を選ぶだけ。これがメトリクス型の設計の核です。\n\nこの「共通の形」を標準にする動きも進んでいます。2025年9月、Open Semantic\nInterchange（OSI）が立ち上がり、2026年1月にはYAML/JSONで記述する仕様の初版（v0.1）が公開されました。2026年7月にはApache\nIncubatorに入り、Apache Ossie（incubating）に改称されています。\n\n2026年1月の初版仕様はRDF/OWLに触れられていませんでしたが、2026年5月にはオントロジー仕様の草案が出ており、7月のApache移管の時点では『セマンティックレイヤーとオントロジーの両方のための仕様』と明示的に説明されています。\n\n\n--------------------------------------------------------------------------------\n\n3. オントロジー型セマンティックレイヤー\nもう1つの系統は、このシリーズで作っているものです。\n\nオントロジー型が定義するもの:\n\n クラス Tenant, Subscription, Plan, Feature, Entitlement\n プロパティ hasSubscription, basedOnPlan, hasEntitlement\n 関係の性質 hasEntitlement と entitledTenant は互いに逆向き\n 階層 ある関係は、別の関係の一種である（7章で実例を見ます）\n 制約 Entitlement には必ず Tenant と Feature が1つずつ必要\n\n\nルーツは、W3Cが標準化したSemantic\nWebの技術（RDF、OWL、SPARQL、SHACL）です。データベースのテーブルではなく、「主語・述語・目的語」の3つ組（トリプル）で世界を記述します。\n\nメトリクス型との一番の違いは、定義から新しい事実を導けること（推論） と、どのテーブルにも属さない「意味の対応」を書けること\nです。「意味の対応」とは、「請求システムのこの項目と、CRMのこの項目は同じ意味だ」という取り決めのことで、7章で実際に書きます。\n\nメトリクス型:\n 定義は「テーブルの上」に乗っている。\n テーブルが先にあり、その上に計算式を載せる。\n\nオントロジー型:\n 定義は「テーブルから独立」している。\n 意味の体系が先にあり、各システムのデータをそこに接続する。\n\n\nこのシリーズで作っているのは、こちらです。\n\n「Tenantとは何か」\n「FeatureとEntitlementはどう違うか」\n「PlanとFeatureの関係は何か」\n\n\nこのあたりは、言葉で説明するより動かしたほうが早いので、このあと実際に手を動かして確かめます。\n\n\n--------------------------------------------------------------------------------\n\n4. T-BoxとA-Box\nオントロジーを実際に使うとき、記述は2つに分かれます。\n\nT-Box（Terminology Box）＝ 語彙の定義\n 「Tenantというクラスが存在する」\n 「hasEntitlementはTenantからEntitlementへの関係である」\n 「entitledTenantはhasEntitlementの逆方向である」\n\nA-Box（Assertion Box）＝ 事実の記述\n 「ex:tenant-abcはTenantである」\n 「ex:entitlement-abc-csv-exportの対象テナントはex:tenant-abcである」\n\n\nたとえで言うと、こうです。\n\nT-Box ＝ 言語のルールブック\nA-Box ＝ そのルールで書かれた文章\n\n\n第1回〜第3回で書いてきた「オントロジー定義のTurtle」がT-Box、「具体的なデータのTurtle」がA-Boxです。\n\nここで大事なのは、セマンティックレイヤーの本体はT-Boxのほう\nだという点です。A-Boxはデータなので日々変わりますが、T-Boxは「意味の取り決め」なので、そう頻繁には変わりません。\n\nでは、そのT-Boxは具体的に何の役に立つのでしょうか。ここからは、手を動かして確認します。\n\n\n--------------------------------------------------------------------------------\n\n5. 手を動かす準備\n5.1 インストール\npip install rdflib owlrl\n\n\nrdflibは、これまでの記事でも使ったRDF操作ライブラリです。owlrl\nは、そのrdflibの上でOWL/RDFSの推論を行うライブラリです。推論とは、T-Boxに書かれたルールを使って、データに書かれていない事実を導き出すことを指します。今回はこの推論が主役になります。\n\n5.2 T-Boxを保存する\nontology.ttlとして保存します。第1回〜第3回で定義した語彙のうち、今回使う分だけの抜粋です。\n\n# ontology.ttl — T-Box（語彙の定義）\n@prefix saas: .\n@prefix rdf: .\n@prefix rdfs: .\n@prefix owl: .\n@prefix xsd: .\n\n#\n# Classes\n#\n\nsaas:Tenant a owl:Class ;\n rdfs:label \"Tenant\"@en , \"テナント\"@ja .\n\nsaas:Plan a owl:Class ;\n rdfs:label \"Plan\"@en , \"プラン\"@ja .\n\nsaas:Subscription a owl:Class ;\n rdfs:label \"Subscription\"@en , \"契約\"@ja .\n\nsaas:Feature a owl:Class ;\n rdfs:label \"Feature\"@en , \"機能\"@ja .\n\nsaas:Entitlement a owl:Class ;\n rdfs:label \"Entitlement\"@en , \"機能利用資格\"@ja .\n\n#\n# Tenant and Subscription\n#\n\nsaas:hasSubscription a owl:ObjectProperty ;\n rdfs:domain saas:Tenant ;\n rdfs:range saas:Subscription ;\n rdfs:label \"has subscription\"@en .\n\nsaas:basedOnPlan a owl:ObjectProperty ;\n rdfs:domain saas:Subscription ;\n rdfs:range saas:Plan ;\n rdfs:label \"based on plan\"@en .\n\n#\n# Plan and Feature\n#\n\nsaas:includesFeature a owl:ObjectProperty ;\n rdfs:domain saas:Plan ;\n rdfs:range saas:Feature ;\n rdfs:label \"includes feature\"@en .\n\n#\n# Tenant and Entitlement（第3回で定義した逆プロパティのペア）\n#\n\nsaas:hasEntitlement a owl:ObjectProperty ;\n rdfs:domain saas:Tenant ;\n rdfs:range saas:Entitlement ;\n rdfs:label \"has entitlement\"@en ,\n \"機能利用資格を持つ\"@ja .\n\nsaas:entitledTenant a owl:ObjectProperty ;\n owl:inverseOf saas:hasEntitlement ;\n rdfs:domain saas:Entitlement ;\n rdfs:range saas:Tenant ;\n rdfs:label \"entitled tenant\"@en ,\n \"利用資格の対象テナント\"@ja .\n\nsaas:entitlesFeature a owl:ObjectProperty ;\n rdfs:domain saas:Entitlement ;\n rdfs:range saas:Feature ;\n rdfs:label \"entitles feature\"@en ,\n \"利用可能にする機能\"@ja .\n\n#\n# Datatype Properties\n#\n\nsaas:name a owl:DatatypeProperty ;\n rdfs:range xsd:string .\n\nsaas:featureCode a owl:DatatypeProperty ;\n rdfs:domain saas:Feature ;\n rdfs:range xsd:string .\n\nsaas:entitlementStatus a owl:DatatypeProperty ;\n rdfs:domain saas:Entitlement ;\n rdfs:range xsd:string .\n\n\n今回の主役は、この1行です。\n\nsaas:entitledTenant a owl:ObjectProperty ;\n owl:inverseOf saas:hasEntitlement ;\n\n\n「entitledTenantはhasEntitlementの逆プロパティである」という宣言です。第3回で定義したものを、そのまま持ってきています。\n\n5.3 A-Boxを保存する\ndata.ttlとして保存します。第3回のインスタンス例と同じく、Entitlement側からsaas:entitledTenant\nでTenantを指す書き方です。\n\n# data.ttl — A-Box（実データ）\n@prefix saas: .\n@prefix ex: .\n@prefix xsd: .\n\n#\n# Tenant\n#\n\nex:tenant-abc a saas:Tenant ;\n saas:name \"株式会社ABCテナント\" ;\n saas:hasSubscription ex:subscription-abc-standard .\n\n#\n# Subscription\n#\n\nex:subscription-abc-standard a saas:Subscription ;\n saas:basedOnPlan ex:plan-standard .\n\n#\n# Plans\n#\n\nex:plan-standard a saas:Plan ;\n saas:name \"Standard Plan\" ;\n saas:includesFeature\n ex:feature-project-management ,\n ex:feature-csv-export ,\n ex:feature-api-access .\n\nex:plan-enterprise a saas:Plan ;\n saas:name \"Enterprise Plan\" ;\n saas:includesFeature\n ex:feature-project-management ,\n ex:feature-csv-export ,\n ex:feature-api-access ,\n ex:feature-saml-sso ,\n ex:feature-audit-log ,\n ex:feature-sales-management ,\n ex:feature-inventory-management .\n\n#\n# Features\n#\n\nex:feature-project-management a saas:Feature ;\n saas:name \"基本プロジェクト管理\" ;\n saas:featureCode \"core.project-management\" .\n\nex:feature-csv-export a saas:Feature ;\n saas:name \"CSVエクスポート\" ;\n saas:featureCode \"data.csv-export\" .\n\nex:feature-api-access a saas:Feature ;\n saas:name \"APIアクセス\" ;\n saas:featureCode \"integration.api-access\" .\n\nex:feature-saml-sso a saas:Feature ;\n saas:name \"SAML SSO\" ;\n saas:featureCode \"security.saml-sso\" .\n\nex:feature-audit-log a saas:Feature ;\n saas:name \"監査ログ\" ;\n saas:featureCode \"security.audit-log\" .\n\nex:feature-sales-management a saas:Feature ;\n saas:name \"販売管理\" ;\n saas:featureCode \"sales.management\" .\n\nex:feature-inventory-management a saas:Feature ;\n saas:name \"在庫管理\" ;\n saas:featureCode \"inventory.management\" .\n\n#\n# Entitlements（Standard Plan由来。販売管理機能に対するEntitlementは存在しない）\n#\n\nex:entitlement-abc-project-management a saas:Entitlement ;\n saas:entitledTenant ex:tenant-abc ;\n saas:entitlesFeature ex:feature-project-management ;\n saas:entitlementStatus \"active\" .\n\nex:entitlement-abc-csv-export a saas:Entitlement ;\n saas:entitledTenant ex:tenant-abc ;\n saas:entitlesFeature ex:feature-csv-export ;\n saas:entitlementStatus \"active\" .\n\nex:entitlement-abc-api-access a saas:Entitlement ;\n saas:entitledTenant ex:tenant-abc ;\n saas:entitlesFeature ex:feature-api-access ;\n saas:entitlementStatus \"active\" .\n\n\n5.4 実行スクリプトを保存する\nこれまでの記事ではsparqlquery\nコマンドを使いましたが、あのコマンドは推論をしてくれません。今回は推論の有無を切り替えたいので、短いスクリプトを用意します。query.py\nとして保存してください。\n\n\"\"\"query.py — Turtleファイルを読み込んでSPARQLを実行する。\n\n使い方:\n python query.py <クエリファイル.rq>\n python query.py --inference <クエリファイル.rq>\n\n--inference を付けると、T-Boxの定義（owl:inverseOf、rdfs:subPropertyOfなど）に\n基づく推論を行ったうえで問い合わせる。\n\"\"\"\n\nimport sys\n\nfrom rdflib import Graph\n\ndef main(argv: list[str]) -> int:\n use_inference = \"--inference\" in argv\n paths = [a for a in argv if a != \"--inference\"]\n\n if len(paths) < 2:\n print(__doc__)\n return 1\n\n *data_files, query_file = paths\n\n graph = Graph()\n for path in data_files:\n graph.parse(path, format=\"turtle\")\n\n triples_before = len(graph)\n\n if use_inference:\n import owlrl\n\n owlrl.DeductiveClosure(owlrl.OWLRL_Semantics).expand(graph)\n\n with open(query_file, encoding=\"utf-8\") as f:\n query = f.read()\n\n results = graph.query(query)\n\n print(\",\".join(str(v) for v in results.vars))\n for row in results:\n print(\",\".join(\"\" if value is None else str(value) for value in row))\n\n mode = \"推論あり\" if use_inference else \"推論なし\"\n print(\n f\"\\n-- {len(results)} 行 / {mode}\"\n f\"（トリプル数 {triples_before} -> {len(graph)}）\"\n )\n return 0\n\nif __name__ == \"__main__\":\n sys.exit(main(sys.argv[1:]))\n\n\nやっていることは3つだけです。\n\n1. 指定されたTurtleファイルを全部1つのグラフに読み込む\n2. --inference が付いていたら推論して、導けるトリプルを追加する\n3. SPARQLを実行して結果を表示する\n\n\n推論にOWLRL_Semanticsを指定している点だけ、先に理由を書いておきます。owlrlには軽いRDFS_Semanticsもありますが、今回主役になる\nowl:inverseOfはOWLの語彙なので、RDFS推論では処理されません。この違いは8章でもう一度触れます。\n\n\n--------------------------------------------------------------------------------\n\n6. T-Boxは、本当に結果を変えるのか\n6.1 まず問い合わせてみる\n「株式会社ABCが使える機能は何か？」を聞きます。query-features.rqとして保存してください。\n\n# query-features.rq — 株式会社ABCが使える機能は何か？\nPREFIX saas: \nPREFIX ex: \n\nSELECT ?featureName ?featureCode\nWHERE {\n ex:tenant-abc saas:hasEntitlement ?entitlement .\n ?entitlement saas:entitlesFeature ?feature .\n ?entitlement saas:entitlementStatus \"active\" .\n ?feature saas:name ?featureName .\n ?feature saas:featureCode ?featureCode .\n}\nORDER BY ?featureCode\n\n\n注目してほしいのは1行目のパターンです。\n\nex:tenant-abc saas:hasEntitlement ?entitlement .\n\n\nTenant側からsaas:hasEntitlementでたどっています。一方、data.ttlに書いてあるのは逆向きのsaas:entitledTenant\nだけでした。\n\n実行します。\n\npython query.py ontology.ttl data.ttl query-features.rq\n\n\n結果:\n\nfeatureName,featureCode\n\n-- 0 行 / 推論なし（トリプル数 103 -> 103）\n\n\n0行です。T-Boxを読み込んでいるにもかかわらず、何も返りません。\n\nこれは、多くの人が最初にハマるところです。\n\nT-Boxに owl:inverseOf と書いただけでは、\n逆方向のトリプルは自動的には存在しない。\n\n\nRDFのグラフには、書かれたトリプルしか入っていません。ex:entitlement-abc-csv-export saas:entitledTenant\nex:tenant-abcは存在しますが、ex:tenant-abc saas:hasEntitlement\nex:entitlement-abc-csv-exportは、まだどこにも書かれていないのです。\n\nここで、正直に書いておかなければならないことがあります。\n\n「逆方向をたどるには推論が必須」というわけではない。\n\n\n次の2つは、どちらも推論なしで3件返ります。\n\n# データが書かれている向きで、そのまま問う\n?entitlement saas:entitledTenant ex:tenant-abc .\n\n# SPARQLの逆パス演算子 ^ を使う\nex:tenant-abc ^saas:entitledTenant ?entitlement .\n\n\nつまり、推論の価値は「逆方向が取れること」そのものではありません。\n\n推論の本当の価値:\n\n データがどちら向きに書かれていても、\n 問い合わせる側は saas:hasEntitlement 一本で書ける。\n\n そして次の7章で見るように、\n クエリを1文字も変えないまま、\n 複数のシステムのデータを束ねられる。\n\n\nデータがどちら向きに書かれているかという違いは、間に挟まる層が吸収します。だから問い合わせる側は、データの書かれ方を知らなくてよい。1章で説明した「レイヤー（層）」の価値は、ここにあります。\n\n6.2 推論を有効にする\n--inferenceを付けて、もう一度実行します。\n\npython query.py --inference ontology.ttl data.ttl query-features.rq\n\n\n結果:\n\nfeatureName,featureCode\n基本プロジェクト管理,core.project-management\nCSVエクスポート,data.csv-export\nAPIアクセス,integration.api-access\n\n-- 3 行 / 推論あり（トリプル数 103 -> 368）\n\n\n3行返ってきました。そして、トリプル数が103から368に増えています（この増え方の内訳は8章で見ます）。\n\n何が起きたのでしょうか。\n\nT-Boxにこう書いてあった:\n saas:entitledTenant owl:inverseOf saas:hasEntitlement\n\nA-Boxにこう書いてあった:\n ex:entitlement-abc-csv-export saas:entitledTenant ex:tenant-abc\n\n推論エンジンは、この2つから次を導き出した:\n ex:tenant-abc saas:hasEntitlement ex:entitlement-abc-csv-export\n\n\nつまり、T-Boxに書いた1行（owl:inverseOf）が、問い合わせの結果を0行から3行に変えた\nのです。T-Boxは人間向けの説明書きではありません。推論エンジンが読んで、データに書かれていない事実を導くためのルールとして働きました。\n\nontology.ttlを読み込まずに推論しても、この結果は出ません。逆方向であるという情報が、どこにも無いからです。ぜひontology.ttl\nを外して試してみてください。\n\n6.3 販売管理機能について聞いてみる\nでは冒頭の問いに戻ります。query-sales.rqとして保存してください。\n\n# query-sales.rq — 株式会社ABCは、販売管理機能を使えるか？\nPREFIX saas: \nPREFIX ex: \n\nSELECT ?featureName ?status\nWHERE {\n ex:tenant-abc saas:hasEntitlement ?entitlement .\n ?entitlement saas:entitlesFeature ex:feature-sales-management .\n ?entitlement saas:entitlementStatus ?status .\n\n ex:feature-sales-management saas:name ?featureName .\n}\n\n\n実行します。\n\npython query.py --inference ontology.ttl data.ttl query-sales.rq\n\n\n結果:\n\nfeatureName,status\n\n-- 0 行 / 推論あり（トリプル数 103 -> 368）\n\n\n推論を有効にしても0行です。これは推論不足ではなく、グラフの中に該当するEntitlementが存在しないという答えです。\n\n厳密に言うと、OWLの推論は「書かれていない＝偽」とは考えません。これを開世界仮定と呼びます。反対に、書かれていないことを偽とみなす考え方を閉世界仮定と呼びます。ふつうのデータベースは、こちらの考え方です。\n\nそれでもここで「使えない」と言い切れるのは、「Entitlementはすべてこのグラフに記録されている」という業務上の前提\nを置いているからです。Entitlementの記録元を網羅しているからこそ、0行を「無い」と読めます。ただし、7章で見るとおり、実務ではこの前提こそが崩れやすいのです。\n\n株式会社ABCは、販売管理機能を使えない。\n販売管理機能を対象とした有効なEntitlementが、\nグラフの中に1つも存在しないから。\n\n\ndata.ttlを見ると、ABCが契約しているStandard Planにも、販売管理は含まれていません。クエリの結果とも矛盾しません。\n\n冒頭の問いに、事実に基づいて答えられました。\n\n\n--------------------------------------------------------------------------------\n\n7. 本番: バラバラの語彙を、1つの問いで横断する\nここまでは1つのシステムのデータだけでした。ここからが、セマンティックレイヤーが本当に役に立つ場面です。\n\n7.1 現実の状況\n実務では、こうなっています。\n\n株式会社ABCは、商談の結果、\nStandard Planに含まれないSAML SSOと監査ログを\n個別に付与されている。\n\nただし、その事実の記録場所はバラバラ:\n\n 請求システム : SAML SSO を課金対象として登録\n → billing:grantedFeature という項目名\n\n CRM : 監査ログ を有効化済みとして記録\n → crm:enabledFeature という項目名\n\n\n同じ「機能を利用可能にした」という意味なのに、項目名が違います。普通なら、どちらかに寄せる変換バッチを書くところです。\n\nセマンティックレイヤーでは、データを書き換えず、意味の対応だけを宣言します。\n\n7.2 マッピングを宣言する\nmapping.ttlとして保存してください。\n\n# mapping.ttl — 各ソースシステムの語彙を、共通語彙 saas: に接続する\n@prefix saas: .\n@prefix rdfs: .\n@prefix billing: .\n@prefix crm: .\n\nbilling:grantedFeature rdfs:subPropertyOf saas:entitlesFeature .\nbilling:forCustomer rdfs:subPropertyOf saas:entitledTenant .\n\ncrm:enabledFeature rdfs:subPropertyOf saas:entitlesFeature .\ncrm:forAccount rdfs:subPropertyOf saas:entitledTenant .\n\n\nrdfs:subPropertyOfは、「このプロパティは、あのプロパティの一種である」という宣言です。\n\nbilling:grantedFeature rdfs:subPropertyOf saas:entitlesFeature\n\n意味:\n 「請求システムのgrantedFeatureで結ばれているものは、\n saas:entitlesFeatureでも結ばれていると見なしてよい」\n\n\nこれだけです。4行の宣言で、2つのシステムの語彙が共通語彙に接続されました。\n\n7.3 各システムのデータをそのまま置く\ndata-multi-source.ttlとして保存してください。各システムの語彙のまま、一切書き換えていません。\n\n# data-multi-source.ttl — 2つの別システムから取り込んだ、そのままの形のデータ\n@prefix saas: .\n@prefix ex: .\n@prefix billing: .\n@prefix crm: .\n\n#\n# 請求システム由来（billing: 語彙）\n#\n\nex:billing-entitlement-001\n billing:forCustomer ex:tenant-abc ;\n billing:grantedFeature ex:feature-saml-sso ;\n saas:entitlementStatus \"active\" .\n\n#\n# CRM由来（crm: 語彙）\n#\n\nex:crm-entitlement-042\n crm:forAccount ex:tenant-abc ;\n crm:enabledFeature ex:feature-audit-log ;\n saas:entitlementStatus \"active\" .\n\n\n7.4 同じクエリで、横断して問い合わせる\nなお、a saas:Entitlement\nというクラス型付けを書いていません。第3回でEntitlementをクラスとして定義したので気になるかと思いますが、今回の問いはプロパティの経路だけでたどれるため、省いています。型付けが必要になるのは、SHACLで検証する場合や、クラス単位で数え上げる場合です。\n\nここが大事なところです。クエリは6.1節のものを、1文字も変えません。\n\npython query.py --inference \\\n ontology.ttl mapping.ttl data.ttl data-multi-source.ttl \\\n query-features.rq\n\n\n結果:\n\nfeatureName,featureCode\n基本プロジェクト管理,core.project-management\nCSVエクスポート,data.csv-export\nAPIアクセス,integration.api-access\n監査ログ,security.audit-log\nSAML SSO,security.saml-sso\n\n-- 5 行 / 推論あり（トリプル数 113 -> 410）\n\n\n3行から5行に増えました。増えたのは、請求システム由来のSAML SSOと、CRM由来の監査ログです。\n\n改めて、何をやったか整理します。\n\nやったこと:\n ・請求システムのデータを、billing: 語彙のまま置いた\n ・CRMのデータを、crm: 語彙のまま置いた\n ・「これらは saas: の何に相当するか」を4行宣言した\n\nやらなかったこと:\n ・項目名をそろえるために、データを書き換える変換バッチやETL処理を書く\n ・クエリを1文字でも変更する\n\n\nこれが、セマンティックレイヤーです。\n\nデータを1箇所に集めて形を揃えるのではなく、\n「意味の対応」を宣言することで、\nバラバラのままのデータを1つの語彙で問い合わせる。\n\n\n新しいシステムが増えたら、mapping.ttl\nに数行足すだけです。クエリを書く側は、各システムの項目名を知らなくてよい。違いは間の層がすべて引き受けます。これが「レイヤー」と呼ばれる理由です。\n\n\n--------------------------------------------------------------------------------\n\n8. SQLと比べて、何が違うのか\n「同じことをSQLでもできるのでは？」という疑問に、正直に答えます。\n\nまずSQLで書いてみます。\n\nSELECT f.name, f.code\nFROM entitlements e\nJOIN features f ON e.feature_id = f.id\nWHERE e.tenant_id = 'abc' AND e.status = 'active'\n\nUNION\n\nSELECT f.name, f.code\nFROM billing_entitlements be\nJOIN features f ON be.granted_feature_id = f.id\nWHERE be.customer_id = 'abc' AND be.status = 'active'\n\nUNION\n\nSELECT f.name, f.code\nFROM crm_entitlements ce\nJOIN features f ON ce.enabled_feature_id = f.id\nWHERE ce.account_id = 'abc' AND ce.status = 'active';\n\n\nできます。ちゃんと動きます。ただし、違いが2つあります。\n\n違い1: 増えたときに変わるのはどちらか\n\nSQL:\n 4つ目のシステムが増えたら、\n このクエリ自体に UNION を1ブロック足す。\n このクエリを使っている全ての箇所を直す。\n\nセマンティックレイヤー:\n mapping.ttl に2行足す。\n クエリは変更しない。\n\n\nただし公平に言えば、実務のSQLでは、このUNIONをあちこちに書いたりはしません。dbtなどの変換処理で1つのentitlements\nテーブル（またはビュー）にまとめておけば、直す場所は1箇所で済みます。2章で見たメトリクス型のセマンティックレイヤーも、この前提に立っています。\n\nそのため、本当の違いは次の「違い2」のほうです。\n\n違い2: 「同じ意味である」がどこに書かれているか\n\nSQLのUNION\nは、「この3つのテーブルは同じものとして扱う」という判断をクエリの中に埋め込んでいます。その判断の根拠は、クエリを書いた人の頭の中にしかありません。\n\n一方、rdfs:subPropertyOf\nは、その判断をクエリの外に、機械が読める宣言として書いています。だから推論エンジンが自動で適用できるし、他の人も他のツールも同じ判断を再利用できます。\n\nもう1点あります。よく「SPARQLならスキーマ変更に強い」と言われますが、それは半分だけ本当です。\n\nSPARQLも、述語のIRIが変わればクエリは壊れる。\nその意味では、カラム名が変わればSQLが壊れるのと同じ。\n\n本当の違いは、\n「変更に強い」ことではなく、\n「意味の対応関係を、クエリの外に、\n 機械可読な形で書き出せる」こと。\n\n\nそして、これにはコストもあります。\n\n推論のコスト:\n 今回は103トリプルが368に増えた（約3.5倍）。\n\n\nただし、この「3.5倍」を鵜呑みにしないでください。増えた265トリプルの内訳を数えると、こうなっています。\n\n増加 265トリプルの内訳:\n\n 262件 W3C語彙（owl:, rdfs: など）に関わるトリプル\n ・大半（約230件）は、データの量と関係なく毎回追加されるもの\n （例:「owl:Thing はクラスである」のような事実）\n ・残りは、データ中のIRIや値ごとに機械的に付く自明なもの\n （例:「X は X と同じものである（owl:sameAs）」）\n 3件 saas:hasEntitlement の導出（＝実際に欲しかったもの）\n\n\nつまり3.5倍の大半は、データ量に関係なく発生する固定オーバーヘッドです。A-Boxが小さいほど倍率は大きく見えます。データを増やすと、倍率そのものは下がっていきます。実際に\ndata.ttlと同じ形のデータを20倍に増やして試すと、推論後のトリプル数は推論前の約1.8倍まで下がりました。\n\nとはいえ、絶対的な計算量とメモリは確実に増えます。本番では次のような判断が必要になります。\n\n・推論結果を事前に計算して保存しておく（マテリアライズ。問い合わせのたびには推論しない）\n・推論を使わず、SPARQLの逆パス演算子（6.1節の ^）で書く\n・必要な導出だけを CONSTRUCT（クエリ結果から新しいトリプルを作る構文）で明示的に作る\n\n\nここで1つ注意点があります。「軽いRDFS推論に絞る」という対策をよく見かけますが、今回のハンズオンではそれをやると、うまく動かなくなります。\n\nowl:inverseOf は、RDFS推論では処理されない。\n\n実測:\n RDFS_Semantics → 0行\n OWLRL_Semantics → 3行\n\n\nrdfs:subPropertyOfはRDFS語彙なのでRDFS推論でも処理されますが、owl:inverseOfはOWLの語彙です。この記事のquery.py\nがOWLRL_Semanticsを使っているのは、そのためです。\n\n魔法ではありません。トレードオフのある設計選択です。\n\n\n--------------------------------------------------------------------------------\n\n9. メトリクス型と比べて、何が違うのか\n8章ではSQLと比べました。ここでは、2章で見たメトリクス型のセマンティックレイヤーと比べます。\n\n違いが一番よくわかるのは、得意な問いが違うところです。2つの問いを用意しました。\n\nQ1. プラン別に、毎月いくつ新しい契約が始まっているか？\n （集計の問い）\n\nQ2. 株式会社ABCというテナントは、販売管理機能を使えるか？\n （関係をたどる問い。しかも記録が複数システムに散らばっている）\n\n\n9.1 Q1（集計）は、メトリクス型の得意分野\nQ1は、2.3節で見たとおり、メトリクス型ならきれいに書けます。\n\nオントロジー型でも、SPARQLで集計はできます。Subscriptionの開始日を表すsaas:subscriptionStart\nは後続の会で正式に定義する予定ですが、ここでは先取りして使います。\n\nSELECT ?planName ?month (COUNT(DISTINCT ?sub) AS ?newSubscriptions)\nWHERE {\n ?sub a saas:Subscription ;\n saas:basedOnPlan ?plan ;\n saas:subscriptionStart ?started .\n ?plan saas:name ?planName .\n BIND(SUBSTR(STR(?started), 1, 7) AS ?month)\n}\nGROUP BY ?planName ?month\n\n\n書けます。ただし、次のような点でメトリクス型に分があります。\n\n・「new_subscriptions とはこの計算式である」という定義を、\n 再利用可能な部品として置く標準的な仕組みが、OWLにはない。\n （OWLは「何が存在するか」の言語であって、「どう数えるか」の言語ではない。\n 統計などの多次元データを記述する W3C の RDF Data Cube 語彙はあるが、\n 計算式そのものを定義する、広く使われた標準はない）\n\n・時間の粒度（日・週・月）、足し算できない指標（期末残高など）の扱いを、\n メトリクス型は定義側で面倒を見てくれる。SPARQLでは毎回書く。\n\n・数億行の集計は、列指向のデータウェアハウスのほうが圧倒的に速い。\n\n\n9.2 Q2（関係・横断）は、オントロジー型の得意分野\nQ2の答えは、「ABCに、販売管理機能を対象とした有効なEntitlementがあるか」です。しかも現実には、その記録が請求システムとCRMに、別々の項目名で散らばっています。\n\n請求システム: billing_entitlements.granted_feature_id\nCRM: crm_entitlements.enabled_feature_id\n\n\nオントロジー型では、こう書くだけで2つを同じ意味として扱えます。\n\nbilling:grantedFeature rdfs:subPropertyOf saas:entitlesFeature .\ncrm:enabledFeature rdfs:subPropertyOf saas:entitlesFeature .\n\n\n問い合わせる側はsaas:entitlesFeature一本で書けばよく、データ自体は書き換えません。これは7章で実際に確かめたとおりです。\n\nでは、メトリクス型ではQ2はどうなるか。ここは公平に書いておきます。\n\n「メトリクス型は複数ソースを束ねられない」は、正確ではない。\n\nメトリクス型の世界では、\n複数ソースの統合は、セマンティックレイヤーの「下」で済ませておく。\ndbt などの変換処理で、請求とCRMのテーブルを\n1つの entitlements テーブルに揃えてから、その上に定義を載せる。\n\n\nつまり、違いは「束ねられるか」ではなく、束ねる判断をどこに書くかです。\n\nメトリクス型:\n 「grantedFeature と enabledFeature は同じ意味だ」という判断は、\n 変換処理（SQL）の中に書かれる。\n\nオントロジー型:\n 同じ判断を、変換処理の外に、\n 機械が読める「意味の宣言」として書く。\n\n\nそして、Q2はそもそも集計の問いではありません。メトリクスとディメンションという型に、自然には収まらない問いです。\n\n9.3 比較表\nここまでの比較を表にまとめます。\n\n観点メトリクス型オントロジー型定義する単位メジャー・ディメンション・結合クラス・プロパティ・関係答えやすい問いどれだけ？（集計）何が何と、どうつながっている？\n定義の置き場所テーブルの上（DWHのカタログ）テーブルから独立（Turtleなど）複数ソースの語彙合わせ下の変換層（dbt等）で済ませておく\nマッピングとして宣言する推論なし（集計の意味づけはある）あり（逆関係、上位プロパティ、クラス階層）書かれていない事実の扱い「無い」とみなす（閉世界仮定）\n推論では「わからない」とみなす（開世界仮定、6.3節）。ただしSPARQLの結果やSHACLの検証は、グラフにあるものだけで判断する制約の検証\n定義の整合性は作成時に検証される。データの制約はテスト（dbt testsなど）で確認するSHACLで宣言する集計性能強い（列指向エンジン）\n弱め（大規模集計は不得意）標準Apache Ossie（旧OSI）が整備中W3C標準（RDF/OWL/SPARQL/SHACL）人材・ツール豊富少ない\nAIとの組み合わせセマンティックモデルを手がかりに、自然文→SQL（Cortex Analyst、Genieなど）自然文→SPARQL、ナレッジグラフ9.4\nメトリクス型のPros / Cons\nPros:\n ・「数字が合わない」問題に、直接対応する\n ・データウェアハウスの中にあり、権限管理も性能もそのまま使える\n ・SQLの延長なので、データ分析の人材がそのまま使える\n ・BIツールやAIエージェントとの連携が、製品として整っている\n\nCons:\n ・定義はテーブル構造に依存する。テーブルが先、意味が後\n ・「AとBは同じ意味」という判断が、変換処理のSQLに埋もれやすい\n ・推論がない。書いた計算式以上のことは出てこない\n ・集計にならない問い（関係・資格・依存）は、型に収まりにくい\n\n\n9.5 オントロジー型のPros / Cons\nPros:\n ・意味の体系がテーブルから独立しているので、ソースが増えても影響を受けにくい\n ・意味の対応関係を、クエリの外に機械可読な形で書ける\n ・推論で、書かれていない事実を導ける\n ・W3C標準なので、特定ベンダーに閉じない\n\nCons:\n ・集計・時間粒度・大規模データの扱いは、メトリクス型に劣る\n ・RDF/SPARQLを扱える人が少ない\n ・既存のRDBのデータをRDFとして扱う工程（変換か仮想化）が別途必要\n ・推論には計算コストがかかり、設計判断が要る\n\n\nどちらも魔法ではありません。目的が違う道具です。\n\n\n--------------------------------------------------------------------------------\n\n10. AIがセマンティックレイヤーを使う場合\nもう1つ、いまの時代に重要な応用に触れておきます。\n\nLLM（大規模言語モデル）に「株式会社ABCは販売管理機能を使えますか？」と聞いたとき、何が起きるべきでしょうか。\n\nセマンティックレイヤーが無い場合:\n LLMが学習データからそれっぽい答えを生成する\n → ハルシネーション（幻覚）のリスク\n\nセマンティックレイヤーがある場合:\n LLMが、問いをSPARQLに変換する\n → セマンティックレイヤーに問い合わせる\n → 返ってきた事実に基づいて答える\n\n\nセマンティックレイヤーがあれば、LLMは「答えを創作する」のではなく「問いを翻訳する」役割に徹することができます。\n\n人間の質問:\n 「株式会社ABCは販売管理機能を使える？」\n\nLLMが生成するSPARQL:\n\n\nPREFIX saas: \nPREFIX ex: \n\nSELECT ?featureName ?status\nWHERE {\n ex:tenant-abc saas:hasEntitlement ?e .\n ?e saas:entitlesFeature ?f .\n ?f saas:name ?featureName .\n FILTER(CONTAINS(?featureName, \"販売管理\"))\n ?e saas:entitlementStatus ?status .\n}\n\n\nセマンティックレイヤーの応答:\n （0行）\n\nLLMの最終回答:\n 「株式会社ABCは現在、販売管理機能を利用できません。\n この機能に対する有効なEntitlementが\n 存在しないためです。」\n\n\nここでLLMが正しいクエリを組み立てられるのは、T-Boxに「Tenant」「Entitlement」「Feature」が何であり、どうつながっているかが書いてあるからです。T-Boxからは、クエリの形（どのプロパティをたどるか）が分かります。絞り込む値の「販売管理」は、LLMが質問の言葉から取り出しています。\n\nLLMにテーブル定義だけを渡した場合:\n 「entitlements.status って何の状態？」\n 「tenant_id と customer_id は同じもの？」\n → 推測が入る\n\nLLMにT-Boxを渡した場合:\n 第3回で Entitlement の rdfs:comment に書いた\n 「特定のTenantに、特定のFeatureを提供する権利、資格または状態」\n が読める\n → 推測が減る\n\n\n第1回からrdfs:labelとrdfs:commentを丁寧に書いてきたのは、人間のためだけではなかったわけです。\n\nなお、今回のontology.ttlは、説明を短くするためにrdfs:comment\nを省いています。実際にLLMへ渡すなら、第3回までの定義をコメントごと渡します。\n\nこの方向性は、メトリクス型の製品にも共通しています。どの製品も、AIエージェント向けの機能を足しています。\n\nSnowflake Semantic View に、AI向けの指示や検証済みクエリを書ける句がある\n → Cortex Analyst などが参照する\nDatabricks Metric View に synonyms（同義語）を書ける\n → Genie が参照する\nLooker LookML を、Gemini の会話型分析の根拠として使う\n\n\n目的は共通していて、「LLMに計算を推測させず、定義に従って決定的に答えさせる\n」ことです。これは、この章で見た「LLMを『答えを創作する役』から『問いを翻訳する役』にする」という話と、まったく同じ方向です。\n\n\n--------------------------------------------------------------------------------\n\n11. 2つの系統は近づいている\nここまで「2つの系統」として分けてきましたが、実は最近、両者の境界は少しずつ曖昧になっています。きっかけは、10章で見たとおり、どちらもAIに正確に答えさせる手段として注目されていることです。\n\n11.1 Microsoft Fabric IQのOntology\n一番わかりやすい合流の例が、MicrosoftがIgnite 2025で発表したFabric\nIQです。その中核に、Ontologyというアイテム（2026年10月時点でプレビュー）があります。\n\nFabric IQ の Ontology で定義するもの（公式ドキュメントより）:\n\n entity type （≒ クラス）\n relationship （≒ プロパティ）\n 継承・namespace\n metric ← Power BI の Semantic Model の DAX メジャーを参照する\n rule （自然言語で書く）\n\n\n面白いのは、metricをオントロジーの中で「参照」している点です。計算式そのもの（DAX）は元のSemantic\nModelが持ち続け、オントロジーはそれを「このエンティティに関する指標」として結びつけます。\n\nオントロジー : 「Tenant とは何か」「何とつながっているか」\nメトリクス層 : 「Tenant ごとの数字を、どう計算するか」\n\n→ 置き換えるのではなく、重ねている\n\n\nまた、FabricのOntologyはRDF / Turtle / OWLのサブセットの取り込みと、RDF /\nTurtleでの書き出しをドキュメントに載せています（取り込み先は空のOntologyアイテムで、取り込み結果は、そのまま保たれた要素・自動で調整された要素・対応していない要素に分けて報告されます）。データ・分析基盤の大手が、W3Cのオントロジー形式との行き来を公式にうたった例です。\n\nさらに、FabricのOntologyは基本的には自分でデータを持たない「仮想的な意味のレイヤー」で、実際の問い合わせは接続先のデータソースで実行されます（多段の関係をたどる場合などは、FabricのGraphにデータを任意で実体化することもできます）。これは、RDFの世界で以前からあるR2RML\n/ Ontop（SPARQLをSQLに書き換えて、元のDBで実行する）とよく似た発想です。\n\n11.2 Apache Ossie も、オントロジーを対象に加えた\n2章で触れたOSI（現 Apache Ossie）も、同じ方向に動いています。2026年7月にApache\nIncubatorへ移ったとき、Ossieは自らを「セマンティックレイヤーとオントロジーの両方のための仕様」と位置づけ直しました。\n\nさらに、草案段階（v0.2.0.dev0）のオントロジー仕様では、概念や関係にiri\nフィールドを持たせ、既存のRDF/OWL語彙のクラスやプロパティと対応づけられるようになっています。メトリクス型から始まった標準化が、オントロジー、さらにW3Cの語彙との接続にまで広がってきたわけです。\n\n11.3 「オントロジー」という言葉の広がり\nちなみに、Palantir\nFoundryのOntologyは、オブジェクト型・リンク型・アクション型という独自のモデルで業務の世界を表現するもので、RDF/OWLをデータモデルの基盤にはしていません（Palantir自身の資料では、RDF/OWL形式との入出力もうたわれています）。MicrosoftのGraphRAGも、LLMでテキストからナレッジグラフを作るもので、RDFではありません。\n\n「オントロジー」「ナレッジグラフ」と名乗っていても、\nW3C標準の RDF/OWL とは限らない。\n\n\nここは混乱しやすいので、覚えておくと便利です。\n\n\n--------------------------------------------------------------------------------\n\n12. レイヤー構成を整理する\n最後に、全体像を整理します。\n\n問い合わせる側（BIツール、AI、スクリプト、人間）\n │\n │ 共通語彙 saas: で問う\n ↓\nセマンティックレイヤー\n ├── ontology.ttl ＝ T-Box（意味の定義）\n └── mapping.ttl ＝ 各ソース語彙との意味の対応\n │\n │ 推論して、書かれていない事実も導く\n ↓\nRDFとして表現されたデータ（A-Box）\n │\n │ ここに、元のデータをRDFに変換する（取り込む）工程が必要\n ↓\n実際のデータソース\n ├── Postgres\n ├── SaaSのAPI\n └── CSV など\n\n\nここで、正直に書いておかなければならないことがあります。\n\n今回の記事では、data.ttl を手で書いた。\n\nしかし実務では、データはPostgresやSaaSのAPIの中にある。\nそれをA-Box（RDF）にする工程は、\n誰かが作らなければならない。\n\n\nこの工程は、この記事では扱っていません。実際には、次のような選択肢があります。\n\n・定期的にRDFへ書き出す（マテリアライズ）\n・問い合わせ時にSQLへ変換する（R2RML / Ontop などの仮想化。データはRDBに置いたまま、SPARQLをSQLに書き換えて実行する）\n・アプリケーション側でRDFとして書き出す\n\n\n「セマンティックレイヤーがあれば変換が不要になる」わけではありません。7章で不要になったのは、項目名をそろえるための変換でした（mapping.ttl\nが語彙どうしの対応を引き受けたからです）。PostgresなどのデータをRDFの形にする変換は、依然として必要です\n。セマンティックレイヤーが不要にするのは、「システムごとにバラバラな意味の解釈を、問い合わせる側が毎回やり直すこと」です。\n\nメトリクス型のセマンティックレイヤーも含めて描き直すと、こうなります。\n\n問い合わせる側（BIツール、AIエージェント、人間）\n │\n ├──「どれだけ？」────→ メトリクス型セマンティックレイヤー\n │ （Snowflake / Databricks / Fabric / dbt）\n │ │\n │ │ 「Tenant」「Plan」の意味は\n │ │ オントロジーに従う\n │ ↓\n └──「何が何と、どう？」→ オントロジー型セマンティックレイヤー\n （このシリーズで作っている saas: 語彙）\n │\n ↓\n 各システムのデータ\n （SaaS管理基盤、請求、CRM、サポート…）\n\n\nオントロジー = 意味の基準\n 「Tenantとは何か」\n 「EntitlementとSubscriptionはどう違うか」\n 「請求システムの customer と CRM の account は同じものか」\n\nメトリクス層 = 計算の基準\n 「Tenantごとの月間利用量を、どう集計するか」\n 「プラン別の新規契約数を、どう数えるか」\n\n\nメトリクス型で「アクティブテナント数」を定義するとき、その前提には「そもそもTenantとは何か」「どの状態をアクティブと呼ぶか」という取り決めがあるはずです。その取り決めを、テーブルやSQLの中に埋もれさせずに書き出したものが、オントロジーです。\n\n2つは競合ではなく、積み重なるものだと考えています。そして、このシリーズが作っているのは下の層、つまり意味の基準のほうです。\n\nここまで見てきた「意味の定義」は、このシリーズの第1回から第3回で作ってきたもの、そのものです。\n\n第1回：Tenant, User, Membership, Role, Permission, Subscription, Plan, Resource\n第2回：Organization, Workspace, Team, RoleAssignment\n第3回：Feature, Entitlement\n\n\nつまり、オントロジーを作ること＝セマンティックレイヤーの語彙を構築すること\nでした。第4回以降で語彙が増えるたびに、このセマンティックレイヤーが答えられる問いも増えていきます。\n\n\n--------------------------------------------------------------------------------\n\nまとめ\n「セマンティックレイヤー」には、2つの系統がある:\n\n メトリクス型（Snowflake / Databricks / Fabric / dbt / Cube / Looker）\n 数字の計算のしかたを、テーブルの上に定義する\n → 「どれだけ？」に強い。数字のズレをなくす\n\n オントロジー型（RDF / OWL / SPARQL / SHACL）\n ものごとの関係と意味を、テーブルから独立して定義する\n → 「何が何と、どうつながっている？」に強い。推論と横断ができる\n\n このシリーズが作っているのは、オントロジー型\n\nセマンティックレイヤーとは:\n データの意味を一箇所に定義し、\n どのツールからでも同じ意味で問い合わせられるようにする仕組み\n\nオントロジーとの関係:\n T-Box（クラスとプロパティの定義）がセマンティックレイヤーの本体\n A-Box（実データ）はT-Boxの語彙で記述される\n\nT-Boxは飾りではない:\n owl:inverseOf を書いておくと、推論で逆方向をたどれる\n → 推論なし 0行、推論あり 3行\n\n意味の対応を宣言すれば、語彙の違いを吸収できる:\n rdfs:subPropertyOf で各システムの語彙を共通語彙に接続\n → データもクエリも変更せず、3行から5行に\n\n正直な限界:\n ・逆方向は、推論なしでも（逆パス ^ などで）取れる。\n 推論の価値は「問い合わせる側が共通語彙一本で書けること」\n ・owl:inverseOf はRDFS推論では処理されない（OWLの推論が必要）\n ・推論の増加分の大半は固定オーバーヘッド（265件中、約230件）\n ・SPARQLも述語IRIが変われば壊れる\n ・PostgresなどからA-Boxへの変換工程は別途必要\n\n\n手を動かした手順は、次の4ステップでした。\n\n1. pip install rdflib owlrl\n2. ontology.ttl（T-Box）と data.ttl（A-Box）を保存する\n3. python query.py ontology.ttl data.ttl query-features.rq\n → 0行（hasEntitlement 方向のトリプルがまだ存在しない）\n4. python query.py --inference ontology.ttl data.ttl query-features.rq\n → 3行（T-Boxの owl:inverseOf から、逆向きの事実が導かれた）\n\n\nここまでで、このシリーズで作っているオントロジーがどう使われるかが、なんとなく伝わったかと思います。具体的なユースケースでどう使うの？というのは、さらに別の会でもっと具体的に説明したいと思います。\n\n\n\n次回（第4回）からは、語彙の構築に戻ります。テーマは「使える。でも、どこまで？」です。Featureが使えるとして、その上限と消費量をどう表現するか、という話に入っていこうと思います！\n\nこちらからは以上です。\n\n\n--------------------------------------------------------------------------------\n\n参考資料（2026年10月時点）\n * Snowflake — Semantic views: \n https://docs.snowflake.com/en/user-guide/views-semantic/querying / CREATE\n SEMANTIC VIEW: \n https://docs.snowflake.com/en/sql-reference/sql/create-semantic-view\n * Snowflake — Open Semantic Interchange: \n https://www.snowflake.com/en/blog/open-semantic-interchange-ai-standard/ /\n 仕様公開: \n https://www.snowflake.com/en/blog/open-semantic-interchanges-specs-finalized/\n * Apache Ossie (incubating): \n https://ossie.apache.org/updates/ossie-enters-apache-incubator/ /\n オントロジー仕様（草案）: https://github.com/apache/ossie/blob/main/ontology/ontology.md\n * dbt v1.12（Ossie形式の読み込み）: \n https://docs.getdbt.com/docs/dbt-versions/dbt-upgrade/upgrading-to-v1.12\n * Databricks — Metric views: https://docs.databricks.com/aws/en/metric-views/ /\n Unity Catalog semantics: https://docs.databricks.com/aws/en/uc-semantics/\n * Microsoft — Fabric IQ: https://learn.microsoft.com/en-us/fabric/iq/overview /\n Ontology: https://learn.microsoft.com/en-us/fabric/iq/ontology/overview\n * Microsoft — Power BI semantic model（旧 dataset）: \n https://learn.microsoft.com/en-us/power-bi/connect-data/service-datasets-rename \n / XMLA エンドポイント: \n https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-connect-tools \n / Direct Lake: \n https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview\n * dbt — MetricFlow の Apache 2.0 化: \n https://www.getdbt.com/blog/open-source-metricflow-governed-metrics\n * Cube — SQL API: https://docs.cube.dev/reference/core-data-apis/sql-api\n * Looker — Open SQL Interface: \n https://docs.cloud.google.com/looker/docs/sql-interface\n * Palantir Foundry Ontology: \n https://www.palantir.com/docs/foundry/ontology/core-concepts\n * Microsoft GraphRAG: https://microsoft.github.io/graphrag/\n * Ontop（R2RML / 仮想ナレッジグラフ）: https://ontop-vkg.org/guide/","html":"

作ったオントロジーは、結局どこで使うのか？

セマンティックレイヤーという考え方を、手を動かして理解する

今回は番外編です。新しいクラスは1つも追加しません。

前回は、FeatureとEntitlementを導入しました。あわせて、Tenantから見たhasEntitlementと、Entitlementから見たentitledTenantという、逆プロパティのペアも定義しました。

ここでいったんクラスを増やす手を止めて、そこまでに作った語彙が実際どこで役に立つのかを確かめます。というのも、ここまで3回クラスを増やしてきて、そろそろこう思っている方がいるはずだからです。

これ、作ったはいいけど、結局どこでどう使うの？\n

たとえば、実際の業務では次のような問いが出てきます。

株式会社ABCというテナントは、SaaSの機能としての販売管理機能を使えるのか？\n

この質問に答えるために、あなたは今、どうしますか？

・請求管理システムの契約画面を開いて確認する？\n・社内の管理DBにSQLを投げる？\n・Slackでカスタマーサクセスに聞く？\n

どの方法でも答えは出ます。しかし、問いの意味自体は、どの方法で調べても同じはずです。

このTenantに、\n販売管理Featureに対する有効なEntitlementが存在するか？\n

これが、問いの正体です。第3回でFeatureとEntitlementを定義したのは、まさにこの「問いの正体」を書けるようにするためでした。

そして、この「意味の定義」を、複数のシステムから共通で使える形にしたものが、セマンティックレイヤーです。

1. セマンティックレイヤーとは何か

一言でいうと、

セマンティックレイヤー：\n    データの意味を一箇所に定義し、\n    どのツール・どのシステムからでも\n    同じ意味で問い合わせられるようにする仕組み\n

もう少し具体的にいきます。

セマンティックレイヤーが無い世界:\n\n    請求システム  →  grantedFeature という項目で機能を持つ\n    CRM           →  enabledFeature という項目で機能を持つ\n    社内DB        →  entitlements テーブルの feature_id カラム\n\n    3つとも同じことを記録しているのに、\n    呼び名がバラバラで、横断して聞けない。\n\nセマンティックレイヤーがある世界:\n\n    共通語彙 saas:entitlesFeature\n    ├── 請求システムの grantedFeature\n    ├── CRMの enabledFeature\n    └── 社内DBの feature_id\n\n    どのシステムのデータでも、1つの問いで横断できる。\n

セマンティックレイヤーの本質は、「どのカラムに何が入っているか」ではなく、「それが何を意味するか」を定義することです。

「レイヤー（層）」と呼ぶのは、これが問い合わせる側とデータの間に挟まる層だからです。

問い合わせる側（人、BIツール、AI）\n    │  共通の語彙で問う\n    ↓\nセマンティックレイヤー（意味の定義と、各システムとの対応）\n    │  各システムの書き方の違いを、ここで吸収する\n    ↓\n各システムのデータ（請求システム、CRM、社内DB…）\n

間に層が1枚あるので、問い合わせる側は、下にあるデータがどう書かれているかを知らなくても済みます。

そして今回は、この「バラバラの語彙を1つの問いで横断する」ところまで、実際に手元で動かします。

ところで、「セマンティックレイヤー」で検索すると、たぶん次のようなものが出てきます。

・Snowflake の Semantic Views\n・Databricks の Metric Views（Unity Catalog semantics）\n・Power BI / Microsoft Fabric の Semantic Model\n・dbt Semantic Layer、Cube、Looker の LookML\n

そして、そこに書かれているのは、だいたいこういう話です。

「売上」「アクティブユーザー数」の計算式を1箇所で定義して、\nどのBIツールからでも同じ数字が出るようにしましょう。\n

一方、このシリーズで作っているのは、Turtleで書いたクラスとプロパティです。計算式は1つも出てきません。

あれ？\nこのシリーズの「セマンティックレイヤー」と、\n世の中の「セマンティックレイヤー」、\n同じものの話をしている？\n

結論から書きます。

同じ言葉で、2つの系統のものが呼ばれている。\n\n    メトリクス型：数字の「計算のしかた」を定義する\n    オントロジー型：世界の「何が何であるか」を定義する\n\nこのシリーズが作っているのは、後者。\n

この記事では、まずこの2つの違いを整理してから、オントロジー型のほうを実際に動かします。後半で手を動かしているときに「あれ？」とならないためです。

製品の名称や提供状況は動きが速いため、本記事の内容は2026年10月時点の公式ドキュメントに基づいています。出典は末尾にまとめました。

2つの系統とも、上で書いた「データの意味を一箇所に定義する」という点は同じです。違うのは、「意味」として何を定義するかです。

メトリクス型が定義する「意味」:\n    「月間アクティブテナント数」とは、\n    subscriptions テーブルの status = 'active' の行を\n    tenant_id で重複排除して数えたもの\n\nオントロジー型が定義する「意味」:\n    「Tenant」とは、Subscription を持ち、\n    Entitlement を通じて Feature を利用できる単位であり、\n    hasEntitlement と entitledTenant は互いに逆向きの関係である\n

前者は数字の作り方、後者はものごとの関係を定義しています。

この違いがどこから来たのかを見ていきます。

2. メトリクス型セマンティックレイヤーは、なぜ生まれたか

2.1 出発点は「数字が合わない」問題

メトリクス型が解こうとしてきた問題は、とても具体的です。

営業のダッシュボード:  今月のアクティブテナント  128社\nCSのダッシュボード:    今月のアクティブテナント  131社\n経営会議の資料:        今月のアクティブテナント  125社\n

3つとも間違ってはいません。トライアル中を含めるか、解約予定を含めるか、月末時点か月中の最大か。計算式が、ダッシュボードごとに少しずつ違うのです。

そこで、「計算式を1箇所に集めて、全員がそれを使う」という発想が生まれました。

2.2 置き場所の変遷

この「計算式の置き場所」は、時代とともに移動してきました。

第1世代: BIツールの中\n    Looker の LookML、Power BI のデータセット（現 Semantic Model）\n    → もともと、そのBIツールのために設計された。\n      いまは外部からも使えるが（Looker の Open SQL Interface、\n      Power BI の XMLA エンドポイントなど）、\n      ツール固有の言語や接続方式に合わせる必要がある。\n\n第2世代: BIツールから独立（ヘッドレス）\n    dbt Semantic Layer（MetricFlow）、Cube、AtScale\n    → どのBIツールからでも、APIやSQLで同じ定義を使える。\n      （dbt の API は dbt platform で提供される）\n\n第3世代: データ基盤の中\n    Snowflake Semantic Views、Databricks Metric Views\n    → データと同じ場所で、同じ権限管理の下に置かれる。\n

Microsoft Fabric の Semantic Model は、第1世代の Power BI の Semantic Model と同じものかと思います。ただ、Fabric 上では Direct Lake という方式で OneLake のデータを直接読めるので、第1世代と第3世代の中間にあたります。

なお、この「世代」は説明のための筆者の整理で、業界やベンダーの公式な区分ではありません。新しい世代ほど優れている、という意味でもありません。いま「セマンティックレイヤー」として話題になっているのが、主に第3世代だということを表現したいため、この整理をしました。

2.3 実際には、こう書く

第1回で作ったTenant・Subscription・Planが、ふつうのテーブルとしてデータウェアハウスに入っているとして、具体的に見てみます。

tenants       (tenant_id, name)\nsubscriptions (subscription_id, tenant_id, plan_id, status, started_at)\nplans         (plan_id, plan_name)\n

ここで、次の問いを考えます。

Q1. プラン別に、毎月いくつ新しい契約が始まっているか？\n

※Q2は9章で出てきます。

SnowflakeのSemantic Viewでは、こう定義します。

-- あくまでもイメージで、動作保証はないです\nCREATE SEMANTIC VIEW subscription_sv\n  TABLES (\n    subscriptions PRIMARY KEY (subscription_id),\n    plans         PRIMARY KEY (plan_id)\n  )\n  RELATIONSHIPS (\n    subscriptions (plan_id) REFERENCES plans\n  )\n  DIMENSIONS (\n    plans.plan_name           AS plans.plan_name,\n    subscriptions.start_month AS DATE_TRUNC('MONTH', subscriptions.started_at)\n  )\n  METRICS (\n    subscriptions.new_subscriptions AS COUNT(DISTINCT subscriptions.subscription_id)\n  )\n  COMMENT = 'プラン別・月別の新規契約';\n

使う側は、計算式を知らなくても、こう問い合わせるだけです。

SELECT plan_name, start_month, AGG(new_subscriptions)\nFROM subscription_sv\nGROUP BY plan_name, start_month;\n

DatabricksのMetric Viewでは、YAMLで同じことを書きます。

-- あくまでもイメージで、動作保証はないです\nCREATE VIEW main.saas.subscription_metrics\nWITH METRICS LANGUAGE YAML AS $$\nversion: 1.1\nsource: main.saas.subscriptions\njoins:\n  - name: plan\n    source: main.saas.plans\n    on: source.plan_id = plan.plan_id\nfields:\n  - name: plan_name\n    expr: plan.plan_name\n  - name: start_month\n    expr: DATE_TRUNC('MONTH', started_at)\nmeasures:\n  - name: new_subscriptions\n    expr: COUNT(DISTINCT subscription_id)\n$$;\n\nSELECT plan_name, start_month, MEASURE(new_subscriptions)\nFROM main.saas.subscription_metrics\nGROUP BY ALL;\n

書き方は違いますが、やっていることは同じです。

2.4 メトリクス型の「共通の形」

製品は違っても、中身の構成要素はほぼ共通しています。

論理テーブル     どのテーブルを使うか\nリレーション     テーブル同士をどう結合するか\nディメンション   どの切り口で分けるか（プラン別、月別…）\nメジャー         何をどう集計するか（COUNT, SUM, 比率…）\n同義語・説明     人間とAIのための補足\n

そして、問い合わせ方も共通しています。

Snowflake   AGG(new_subscriptions)\nDatabricks  MEASURE(new_subscriptions)\nCube        MEASURE(...)\nLooker      AGGREGATE(...)\n

AGG()やMEASURE()は、「定義側に書いてある集計式（ここではCOUNT(DISTINCT …)）で集計して」という指示です。使う側は、COUNTやSUMを自分で書く必要がありません。

集計のしかたは定義側が持ち、使う側は切り口を選ぶだけ。これがメトリクス型の設計の核です。

この「共通の形」を標準にする動きも進んでいます。2025年9月、Open Semantic Interchange（OSI）が立ち上がり、2026年1月にはYAML/JSONで記述する仕様の初版（v0.1）が公開されました。2026年7月にはApache Incubatorに入り、Apache Ossie（incubating）に改称されています。

2026年1月の初版仕様はRDF/OWLに触れられていませんでしたが、2026年5月にはオントロジー仕様の草案が出ており、7月のApache移管の時点では『セマンティックレイヤーとオントロジーの両方のための仕様』と明示的に説明されています。

3. オントロジー型セマンティックレイヤー

もう1つの系統は、このシリーズで作っているものです。

オントロジー型が定義するもの:\n\n    クラス         Tenant, Subscription, Plan, Feature, Entitlement\n    プロパティ     hasSubscription, basedOnPlan, hasEntitlement\n    関係の性質     hasEntitlement と entitledTenant は互いに逆向き\n    階層           ある関係は、別の関係の一種である（7章で実例を見ます）\n    制約           Entitlement には必ず Tenant と Feature が1つずつ必要\n

ルーツは、W3Cが標準化したSemantic Webの技術（RDF、OWL、SPARQL、SHACL）です。データベースのテーブルではなく、「主語・述語・目的語」の3つ組（トリプル）で世界を記述します。

メトリクス型との一番の違いは、定義から新しい事実を導けること（推論） と、どのテーブルにも属さない「意味の対応」を書けることです。「意味の対応」とは、「請求システムのこの項目と、CRMのこの項目は同じ意味だ」という取り決めのことで、7章で実際に書きます。

メトリクス型:\n    定義は「テーブルの上」に乗っている。\n    テーブルが先にあり、その上に計算式を載せる。\n\nオントロジー型:\n    定義は「テーブルから独立」している。\n    意味の体系が先にあり、各システムのデータをそこに接続する。\n

このシリーズで作っているのは、こちらです。

「Tenantとは何か」\n「FeatureとEntitlementはどう違うか」\n「PlanとFeatureの関係は何か」\n

このあたりは、言葉で説明するより動かしたほうが早いので、このあと実際に手を動かして確かめます。

4. T-BoxとA-Box

オントロジーを実際に使うとき、記述は2つに分かれます。

T-Box（Terminology Box）＝ 語彙の定義\n    「Tenantというクラスが存在する」\n    「hasEntitlementはTenantからEntitlementへの関係である」\n    「entitledTenantはhasEntitlementの逆方向である」\n\nA-Box（Assertion Box）＝ 事実の記述\n    「ex:tenant-abcはTenantである」\n    「ex:entitlement-abc-csv-exportの対象テナントはex:tenant-abcである」\n

たとえで言うと、こうです。

T-Box ＝ 言語のルールブック\nA-Box ＝ そのルールで書かれた文章\n

第1回〜第3回で書いてきた「オントロジー定義のTurtle」がT-Box、「具体的なデータのTurtle」がA-Boxです。

ここで大事なのは、セマンティックレイヤーの本体はT-Boxのほうだという点です。A-Boxはデータなので日々変わりますが、T-Boxは「意味の取り決め」なので、そう頻繁には変わりません。

では、そのT-Boxは具体的に何の役に立つのでしょうか。ここからは、手を動かして確認します。

5. 手を動かす準備

5.1 インストール

pip install rdflib owlrl\n

rdflibは、これまでの記事でも使ったRDF操作ライブラリです。owlrlは、そのrdflibの上でOWL/RDFSの推論を行うライブラリです。推論とは、T-Boxに書かれたルールを使って、データに書かれていない事実を導き出すことを指します。今回はこの推論が主役になります。

5.2 T-Boxを保存する

ontology.ttlとして保存します。第1回〜第3回で定義した語彙のうち、今回使う分だけの抜粋です。

# ontology.ttl — T-Box（語彙の定義）\n@prefix saas: <https://example.com/ontology/saas#> .\n@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .\n@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .\n@prefix owl:  <http://www.w3.org/2002/07/owl#> .\n@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .\n\n#\n# Classes\n#\n\nsaas:Tenant a owl:Class ;\n    rdfs:label \"Tenant\"@en , \"テナント\"@ja .\n\nsaas:Plan a owl:Class ;\n    rdfs:label \"Plan\"@en , \"プラン\"@ja .\n\nsaas:Subscription a owl:Class ;\n    rdfs:label \"Subscription\"@en , \"契約\"@ja .\n\nsaas:Feature a owl:Class ;\n    rdfs:label \"Feature\"@en , \"機能\"@ja .\n\nsaas:Entitlement a owl:Class ;\n    rdfs:label \"Entitlement\"@en , \"機能利用資格\"@ja .\n\n#\n# Tenant and Subscription\n#\n\nsaas:hasSubscription a owl:ObjectProperty ;\n    rdfs:domain saas:Tenant ;\n    rdfs:range saas:Subscription ;\n    rdfs:label \"has subscription\"@en .\n\nsaas:basedOnPlan a owl:ObjectProperty ;\n    rdfs:domain saas:Subscription ;\n    rdfs:range saas:Plan ;\n    rdfs:label \"based on plan\"@en .\n\n#\n# Plan and Feature\n#\n\nsaas:includesFeature a owl:ObjectProperty ;\n    rdfs:domain saas:Plan ;\n    rdfs:range saas:Feature ;\n    rdfs:label \"includes feature\"@en .\n\n#\n# Tenant and Entitlement（第3回で定義した逆プロパティのペア）\n#\n\nsaas:hasEntitlement a owl:ObjectProperty ;\n    rdfs:domain saas:Tenant ;\n    rdfs:range saas:Entitlement ;\n    rdfs:label \"has entitlement\"@en ,\n               \"機能利用資格を持つ\"@ja .\n\nsaas:entitledTenant a owl:ObjectProperty ;\n    owl:inverseOf saas:hasEntitlement ;\n    rdfs:domain saas:Entitlement ;\n    rdfs:range saas:Tenant ;\n    rdfs:label \"entitled tenant\"@en ,\n               \"利用資格の対象テナント\"@ja .\n\nsaas:entitlesFeature a owl:ObjectProperty ;\n    rdfs:domain saas:Entitlement ;\n    rdfs:range saas:Feature ;\n    rdfs:label \"entitles feature\"@en ,\n               \"利用可能にする機能\"@ja .\n\n#\n# Datatype Properties\n#\n\nsaas:name a owl:DatatypeProperty ;\n    rdfs:range xsd:string .\n\nsaas:featureCode a owl:DatatypeProperty ;\n    rdfs:domain saas:Feature ;\n    rdfs:range xsd:string .\n\nsaas:entitlementStatus a owl:DatatypeProperty ;\n    rdfs:domain saas:Entitlement ;\n    rdfs:range xsd:string .\n

今回の主役は、この1行です。

saas:entitledTenant a owl:ObjectProperty ;\n    owl:inverseOf saas:hasEntitlement ;\n

「entitledTenantはhasEntitlementの逆プロパティである」という宣言です。第3回で定義したものを、そのまま持ってきています。

5.3 A-Boxを保存する

data.ttlとして保存します。第3回のインスタンス例と同じく、Entitlement側からsaas:entitledTenantでTenantを指す書き方です。

# data.ttl — A-Box（実データ）\n@prefix saas: <https://example.com/ontology/saas#> .\n@prefix ex:   <https://example.com/data/> .\n@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .\n\n#\n# Tenant\n#\n\nex:tenant-abc a saas:Tenant ;\n    saas:name \"株式会社ABCテナント\" ;\n    saas:hasSubscription ex:subscription-abc-standard .\n\n#\n# Subscription\n#\n\nex:subscription-abc-standard a saas:Subscription ;\n    saas:basedOnPlan ex:plan-standard .\n\n#\n# Plans\n#\n\nex:plan-standard a saas:Plan ;\n    saas:name \"Standard Plan\" ;\n    saas:includesFeature\n        ex:feature-project-management ,\n        ex:feature-csv-export ,\n        ex:feature-api-access .\n\nex:plan-enterprise a saas:Plan ;\n    saas:name \"Enterprise Plan\" ;\n    saas:includesFeature\n        ex:feature-project-management ,\n        ex:feature-csv-export ,\n        ex:feature-api-access ,\n        ex:feature-saml-sso ,\n        ex:feature-audit-log ,\n        ex:feature-sales-management ,\n        ex:feature-inventory-management .\n\n#\n# Features\n#\n\nex:feature-project-management a saas:Feature ;\n    saas:name \"基本プロジェクト管理\" ;\n    saas:featureCode \"core.project-management\" .\n\nex:feature-csv-export a saas:Feature ;\n    saas:name \"CSVエクスポート\" ;\n    saas:featureCode \"data.csv-export\" .\n\nex:feature-api-access a saas:Feature ;\n    saas:name \"APIアクセス\" ;\n    saas:featureCode \"integration.api-access\" .\n\nex:feature-saml-sso a saas:Feature ;\n    saas:name \"SAML SSO\" ;\n    saas:featureCode \"security.saml-sso\" .\n\nex:feature-audit-log a saas:Feature ;\n    saas:name \"監査ログ\" ;\n    saas:featureCode \"security.audit-log\" .\n\nex:feature-sales-management a saas:Feature ;\n    saas:name \"販売管理\" ;\n    saas:featureCode \"sales.management\" .\n\nex:feature-inventory-management a saas:Feature ;\n    saas:name \"在庫管理\" ;\n    saas:featureCode \"inventory.management\" .\n\n#\n# Entitlements（Standard Plan由来。販売管理機能に対するEntitlementは存在しない）\n#\n\nex:entitlement-abc-project-management a saas:Entitlement ;\n    saas:entitledTenant ex:tenant-abc ;\n    saas:entitlesFeature ex:feature-project-management ;\n    saas:entitlementStatus \"active\" .\n\nex:entitlement-abc-csv-export a saas:Entitlement ;\n    saas:entitledTenant ex:tenant-abc ;\n    saas:entitlesFeature ex:feature-csv-export ;\n    saas:entitlementStatus \"active\" .\n\nex:entitlement-abc-api-access a saas:Entitlement ;\n    saas:entitledTenant ex:tenant-abc ;\n    saas:entitlesFeature ex:feature-api-access ;\n    saas:entitlementStatus \"active\" .\n

5.4 実行スクリプトを保存する

これまでの記事ではsparqlqueryコマンドを使いましたが、あのコマンドは推論をしてくれません。今回は推論の有無を切り替えたいので、短いスクリプトを用意します。query.pyとして保存してください。

\"\"\"query.py — Turtleファイルを読み込んでSPARQLを実行する。\n\n使い方:\n    python query.py <ttlファイル...> <クエリファイル.rq>\n    python query.py --inference <ttlファイル...> <クエリファイル.rq>\n\n--inference を付けると、T-Boxの定義（owl:inverseOf、rdfs:subPropertyOfなど）に\n基づく推論を行ったうえで問い合わせる。\n\"\"\"\n\nimport sys\n\nfrom rdflib import Graph\n\ndef main(argv: list[str]) -> int:\n    use_inference = \"--inference\" in argv\n    paths = [a for a in argv if a != \"--inference\"]\n\n    if len(paths) < 2:\n        print(__doc__)\n        return 1\n\n    *data_files, query_file = paths\n\n    graph = Graph()\n    for path in data_files:\n        graph.parse(path, format=\"turtle\")\n\n    triples_before = len(graph)\n\n    if use_inference:\n        import owlrl\n\n        owlrl.DeductiveClosure(owlrl.OWLRL_Semantics).expand(graph)\n\n    with open(query_file, encoding=\"utf-8\") as f:\n        query = f.read()\n\n    results = graph.query(query)\n\n    print(\",\".join(str(v) for v in results.vars))\n    for row in results:\n        print(\",\".join(\"\" if value is None else str(value) for value in row))\n\n    mode = \"推論あり\" if use_inference else \"推論なし\"\n    print(\n        f\"\\n-- {len(results)} 行 / {mode}\"\n        f\"（トリプル数 {triples_before} -> {len(graph)}）\"\n    )\n    return 0\n\nif __name__ == \"__main__\":\n    sys.exit(main(sys.argv[1:]))\n

やっていることは3つだけです。

1. 指定されたTurtleファイルを全部1つのグラフに読み込む\n2. --inference が付いていたら推論して、導けるトリプルを追加する\n3. SPARQLを実行して結果を表示する\n

推論にOWLRL_Semanticsを指定している点だけ、先に理由を書いておきます。owlrlには軽いRDFS_Semanticsもありますが、今回主役になるowl:inverseOfはOWLの語彙なので、RDFS推論では処理されません。この違いは8章でもう一度触れます。

6. T-Boxは、本当に結果を変えるのか

6.1 まず問い合わせてみる

「株式会社ABCが使える機能は何か？」を聞きます。query-features.rqとして保存してください。

# query-features.rq — 株式会社ABCが使える機能は何か？\nPREFIX saas: <https://example.com/ontology/saas#>\nPREFIX ex:   <https://example.com/data/>\n\nSELECT ?featureName ?featureCode\nWHERE {\n    ex:tenant-abc saas:hasEntitlement ?entitlement .\n    ?entitlement saas:entitlesFeature ?feature .\n    ?entitlement saas:entitlementStatus \"active\" .\n    ?feature saas:name ?featureName .\n    ?feature saas:featureCode ?featureCode .\n}\nORDER BY ?featureCode\n

注目してほしいのは1行目のパターンです。

ex:tenant-abc saas:hasEntitlement ?entitlement .\n

Tenant側からsaas:hasEntitlementでたどっています。一方、data.ttlに書いてあるのは逆向きのsaas:entitledTenantだけでした。

実行します。

python query.py ontology.ttl data.ttl query-features.rq\n

結果:

featureName,featureCode\n\n-- 0 行 / 推論なし（トリプル数 103 -> 103）\n

0行です。T-Boxを読み込んでいるにもかかわらず、何も返りません。

これは、多くの人が最初にハマるところです。

T-Boxに owl:inverseOf と書いただけでは、\n逆方向のトリプルは自動的には存在しない。\n

RDFのグラフには、書かれたトリプルしか入っていません。ex:entitlement-abc-csv-export saas:entitledTenant ex:tenant-abcは存在しますが、ex:tenant-abc saas:hasEntitlement ex:entitlement-abc-csv-exportは、まだどこにも書かれていないのです。

ここで、正直に書いておかなければならないことがあります。

「逆方向をたどるには推論が必須」というわけではない。\n

次の2つは、どちらも推論なしで3件返ります。

# データが書かれている向きで、そのまま問う\n?entitlement saas:entitledTenant ex:tenant-abc .\n\n# SPARQLの逆パス演算子 ^ を使う\nex:tenant-abc ^saas:entitledTenant ?entitlement .\n

つまり、推論の価値は「逆方向が取れること」そのものではありません。

推論の本当の価値:\n\n    データがどちら向きに書かれていても、\n    問い合わせる側は saas:hasEntitlement 一本で書ける。\n\n    そして次の7章で見るように、\n    クエリを1文字も変えないまま、\n    複数のシステムのデータを束ねられる。\n

データがどちら向きに書かれているかという違いは、間に挟まる層が吸収します。だから問い合わせる側は、データの書かれ方を知らなくてよい。1章で説明した「レイヤー（層）」の価値は、ここにあります。

6.2 推論を有効にする

--inferenceを付けて、もう一度実行します。

python query.py --inference ontology.ttl data.ttl query-features.rq\n

結果:

featureName,featureCode\n基本プロジェクト管理,core.project-management\nCSVエクスポート,data.csv-export\nAPIアクセス,integration.api-access\n\n-- 3 行 / 推論あり（トリプル数 103 -> 368）\n

3行返ってきました。そして、トリプル数が103から368に増えています（この増え方の内訳は8章で見ます）。

何が起きたのでしょうか。

T-Boxにこう書いてあった:\n    saas:entitledTenant owl:inverseOf saas:hasEntitlement\n\nA-Boxにこう書いてあった:\n    ex:entitlement-abc-csv-export saas:entitledTenant ex:tenant-abc\n\n推論エンジンは、この2つから次を導き出した:\n    ex:tenant-abc saas:hasEntitlement ex:entitlement-abc-csv-export\n

つまり、T-Boxに書いた1行（owl:inverseOf）が、問い合わせの結果を0行から3行に変えたのです。T-Boxは人間向けの説明書きではありません。推論エンジンが読んで、データに書かれていない事実を導くためのルールとして働きました。

ontology.ttlを読み込まずに推論しても、この結果は出ません。逆方向であるという情報が、どこにも無いからです。ぜひontology.ttlを外して試してみてください。

6.3 販売管理機能について聞いてみる

では冒頭の問いに戻ります。query-sales.rqとして保存してください。

# query-sales.rq — 株式会社ABCは、販売管理機能を使えるか？\nPREFIX saas: <https://example.com/ontology/saas#>\nPREFIX ex:   <https://example.com/data/>\n\nSELECT ?featureName ?status\nWHERE {\n    ex:tenant-abc saas:hasEntitlement ?entitlement .\n    ?entitlement saas:entitlesFeature ex:feature-sales-management .\n    ?entitlement saas:entitlementStatus ?status .\n\n    ex:feature-sales-management saas:name ?featureName .\n}\n

実行します。

python query.py --inference ontology.ttl data.ttl query-sales.rq\n

結果:

featureName,status\n\n-- 0 行 / 推論あり（トリプル数 103 -> 368）\n

推論を有効にしても0行です。これは推論不足ではなく、グラフの中に該当するEntitlementが存在しないという答えです。

厳密に言うと、OWLの推論は「書かれていない＝偽」とは考えません。これを開世界仮定と呼びます。反対に、書かれていないことを偽とみなす考え方を閉世界仮定と呼びます。ふつうのデータベースは、こちらの考え方です。

それでもここで「使えない」と言い切れるのは、「Entitlementはすべてこのグラフに記録されている」という業務上の前提を置いているからです。Entitlementの記録元を網羅しているからこそ、0行を「無い」と読めます。ただし、7章で見るとおり、実務ではこの前提こそが崩れやすいのです。

株式会社ABCは、販売管理機能を使えない。\n販売管理機能を対象とした有効なEntitlementが、\nグラフの中に1つも存在しないから。\n

data.ttlを見ると、ABCが契約しているStandard Planにも、販売管理は含まれていません。クエリの結果とも矛盾しません。

冒頭の問いに、事実に基づいて答えられました。

7. 本番: バラバラの語彙を、1つの問いで横断する

ここまでは1つのシステムのデータだけでした。ここからが、セマンティックレイヤーが本当に役に立つ場面です。

7.1 現実の状況

実務では、こうなっています。

株式会社ABCは、商談の結果、\nStandard Planに含まれないSAML SSOと監査ログを\n個別に付与されている。\n\nただし、その事実の記録場所はバラバラ:\n\n    請求システム : SAML SSO を課金対象として登録\n                  → billing:grantedFeature という項目名\n\n    CRM          : 監査ログ を有効化済みとして記録\n                  → crm:enabledFeature という項目名\n

同じ「機能を利用可能にした」という意味なのに、項目名が違います。普通なら、どちらかに寄せる変換バッチを書くところです。

セマンティックレイヤーでは、データを書き換えず、意味の対応だけを宣言します。

7.2 マッピングを宣言する

mapping.ttlとして保存してください。

# mapping.ttl — 各ソースシステムの語彙を、共通語彙 saas: に接続する\n@prefix saas:    <https://example.com/ontology/saas#> .\n@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .\n@prefix billing: <https://example.com/source/billing#> .\n@prefix crm:     <https://example.com/source/crm#> .\n\nbilling:grantedFeature rdfs:subPropertyOf saas:entitlesFeature .\nbilling:forCustomer    rdfs:subPropertyOf saas:entitledTenant .\n\ncrm:enabledFeature     rdfs:subPropertyOf saas:entitlesFeature .\ncrm:forAccount         rdfs:subPropertyOf saas:entitledTenant .\n

rdfs:subPropertyOfは、「このプロパティは、あのプロパティの一種である」という宣言です。

billing:grantedFeature rdfs:subPropertyOf saas:entitlesFeature\n\n意味:\n    「請求システムのgrantedFeatureで結ばれているものは、\n      saas:entitlesFeatureでも結ばれていると見なしてよい」\n

これだけです。4行の宣言で、2つのシステムの語彙が共通語彙に接続されました。

7.3 各システムのデータをそのまま置く

data-multi-source.ttlとして保存してください。各システムの語彙のまま、一切書き換えていません。

# data-multi-source.ttl — 2つの別システムから取り込んだ、そのままの形のデータ\n@prefix saas:    <https://example.com/ontology/saas#> .\n@prefix ex:      <https://example.com/data/> .\n@prefix billing: <https://example.com/source/billing#> .\n@prefix crm:     <https://example.com/source/crm#> .\n\n#\n# 請求システム由来（billing: 語彙）\n#\n\nex:billing-entitlement-001\n    billing:forCustomer ex:tenant-abc ;\n    billing:grantedFeature ex:feature-saml-sso ;\n    saas:entitlementStatus \"active\" .\n\n#\n# CRM由来（crm: 語彙）\n#\n\nex:crm-entitlement-042\n    crm:forAccount ex:tenant-abc ;\n    crm:enabledFeature ex:feature-audit-log ;\n    saas:entitlementStatus \"active\" .\n

7.4 同じクエリで、横断して問い合わせる

なお、a saas:Entitlementというクラス型付けを書いていません。第3回でEntitlementをクラスとして定義したので気になるかと思いますが、今回の問いはプロパティの経路だけでたどれるため、省いています。型付けが必要になるのは、SHACLで検証する場合や、クラス単位で数え上げる場合です。

ここが大事なところです。クエリは6.1節のものを、1文字も変えません。

python query.py --inference \\\n    ontology.ttl mapping.ttl data.ttl data-multi-source.ttl \\\n    query-features.rq\n

結果:

featureName,featureCode\n基本プロジェクト管理,core.project-management\nCSVエクスポート,data.csv-export\nAPIアクセス,integration.api-access\n監査ログ,security.audit-log\nSAML SSO,security.saml-sso\n\n-- 5 行 / 推論あり（トリプル数 113 -> 410）\n

3行から5行に増えました。増えたのは、請求システム由来のSAML SSOと、CRM由来の監査ログです。

改めて、何をやったか整理します。

やったこと:\n    ・請求システムのデータを、billing: 語彙のまま置いた\n    ・CRMのデータを、crm: 語彙のまま置いた\n    ・「これらは saas: の何に相当するか」を4行宣言した\n\nやらなかったこと:\n    ・項目名をそろえるために、データを書き換える変換バッチやETL処理を書く\n    ・クエリを1文字でも変更する\n

これが、セマンティックレイヤーです。

データを1箇所に集めて形を揃えるのではなく、\n「意味の対応」を宣言することで、\nバラバラのままのデータを1つの語彙で問い合わせる。\n

新しいシステムが増えたら、mapping.ttlに数行足すだけです。クエリを書く側は、各システムの項目名を知らなくてよい。違いは間の層がすべて引き受けます。これが「レイヤー」と呼ばれる理由です。

8. SQLと比べて、何が違うのか

「同じことをSQLでもできるのでは？」という疑問に、正直に答えます。

まずSQLで書いてみます。

SELECT f.name, f.code\nFROM entitlements e\nJOIN features f ON e.feature_id = f.id\nWHERE e.tenant_id = 'abc' AND e.status = 'active'\n\nUNION\n\nSELECT f.name, f.code\nFROM billing_entitlements be\nJOIN features f ON be.granted_feature_id = f.id\nWHERE be.customer_id = 'abc' AND be.status = 'active'\n\nUNION\n\nSELECT f.name, f.code\nFROM crm_entitlements ce\nJOIN features f ON ce.enabled_feature_id = f.id\nWHERE ce.account_id = 'abc' AND ce.status = 'active';\n

できます。ちゃんと動きます。ただし、違いが2つあります。

違い1: 増えたときに変わるのはどちらか

SQL:\n    4つ目のシステムが増えたら、\n    このクエリ自体に UNION を1ブロック足す。\n    このクエリを使っている全ての箇所を直す。\n\nセマンティックレイヤー:\n    mapping.ttl に2行足す。\n    クエリは変更しない。\n

ただし公平に言えば、実務のSQLでは、このUNIONをあちこちに書いたりはしません。dbtなどの変換処理で1つのentitlementsテーブル（またはビュー）にまとめておけば、直す場所は1箇所で済みます。2章で見たメトリクス型のセマンティックレイヤーも、この前提に立っています。

そのため、本当の違いは次の「違い2」のほうです。

違い2: 「同じ意味である」がどこに書かれているか

SQLのUNIONは、「この3つのテーブルは同じものとして扱う」という判断をクエリの中に埋め込んでいます。その判断の根拠は、クエリを書いた人の頭の中にしかありません。

一方、rdfs:subPropertyOfは、その判断をクエリの外に、機械が読める宣言として書いています。だから推論エンジンが自動で適用できるし、他の人も他のツールも同じ判断を再利用できます。

もう1点あります。よく「SPARQLならスキーマ変更に強い」と言われますが、それは半分だけ本当です。

SPARQLも、述語のIRIが変わればクエリは壊れる。\nその意味では、カラム名が変わればSQLが壊れるのと同じ。\n\n本当の違いは、\n「変更に強い」ことではなく、\n「意味の対応関係を、クエリの外に、\n  機械可読な形で書き出せる」こと。\n

そして、これにはコストもあります。

推論のコスト:\n    今回は103トリプルが368に増えた（約3.5倍）。\n

ただし、この「3.5倍」を鵜呑みにしないでください。増えた265トリプルの内訳を数えると、こうなっています。

増加 265トリプルの内訳:\n\n    262件  W3C語彙（owl:, rdfs: など）に関わるトリプル\n           ・大半（約230件）は、データの量と関係なく毎回追加されるもの\n             （例:「owl:Thing はクラスである」のような事実）\n           ・残りは、データ中のIRIや値ごとに機械的に付く自明なもの\n             （例:「X は X と同じものである（owl:sameAs）」）\n      3件  saas:hasEntitlement の導出（＝実際に欲しかったもの）\n

つまり3.5倍の大半は、データ量に関係なく発生する固定オーバーヘッドです。A-Boxが小さいほど倍率は大きく見えます。データを増やすと、倍率そのものは下がっていきます。実際にdata.ttlと同じ形のデータを20倍に増やして試すと、推論後のトリプル数は推論前の約1.8倍まで下がりました。

とはいえ、絶対的な計算量とメモリは確実に増えます。本番では次のような判断が必要になります。

・推論結果を事前に計算して保存しておく（マテリアライズ。問い合わせのたびには推論しない）\n・推論を使わず、SPARQLの逆パス演算子（6.1節の ^）で書く\n・必要な導出だけを CONSTRUCT（クエリ結果から新しいトリプルを作る構文）で明示的に作る\n

ここで1つ注意点があります。「軽いRDFS推論に絞る」という対策をよく見かけますが、今回のハンズオンではそれをやると、うまく動かなくなります。

owl:inverseOf は、RDFS推論では処理されない。\n\n実測:\n    RDFS_Semantics  → 0行\n    OWLRL_Semantics → 3行\n

rdfs:subPropertyOfはRDFS語彙なのでRDFS推論でも処理されますが、owl:inverseOfはOWLの語彙です。この記事のquery.pyがOWLRL_Semanticsを使っているのは、そのためです。

魔法ではありません。トレードオフのある設計選択です。

9. メトリクス型と比べて、何が違うのか

8章ではSQLと比べました。ここでは、2章で見たメトリクス型のセマンティックレイヤーと比べます。

違いが一番よくわかるのは、得意な問いが違うところです。2つの問いを用意しました。

Q1. プラン別に、毎月いくつ新しい契約が始まっているか？\n    （集計の問い）\n\nQ2. 株式会社ABCというテナントは、販売管理機能を使えるか？\n    （関係をたどる問い。しかも記録が複数システムに散らばっている）\n

9.1 Q1（集計）は、メトリクス型の得意分野

Q1は、2.3節で見たとおり、メトリクス型ならきれいに書けます。

オントロジー型でも、SPARQLで集計はできます。Subscriptionの開始日を表すsaas:subscriptionStartは後続の会で正式に定義する予定ですが、ここでは先取りして使います。

SELECT ?planName ?month (COUNT(DISTINCT ?sub) AS ?newSubscriptions)\nWHERE {\n    ?sub a saas:Subscription ;\n         saas:basedOnPlan ?plan ;\n         saas:subscriptionStart ?started .\n    ?plan saas:name ?planName .\n    BIND(SUBSTR(STR(?started), 1, 7) AS ?month)\n}\nGROUP BY ?planName ?month\n

書けます。ただし、次のような点でメトリクス型に分があります。

・「new_subscriptions とはこの計算式である」という定義を、\n  再利用可能な部品として置く標準的な仕組みが、OWLにはない。\n  （OWLは「何が存在するか」の言語であって、「どう数えるか」の言語ではない。\n    統計などの多次元データを記述する W3C の RDF Data Cube 語彙はあるが、\n    計算式そのものを定義する、広く使われた標準はない）\n\n・時間の粒度（日・週・月）、足し算できない指標（期末残高など）の扱いを、\n  メトリクス型は定義側で面倒を見てくれる。SPARQLでは毎回書く。\n\n・数億行の集計は、列指向のデータウェアハウスのほうが圧倒的に速い。\n

9.2 Q2（関係・横断）は、オントロジー型の得意分野

Q2の答えは、「ABCに、販売管理機能を対象とした有効なEntitlementがあるか」です。しかも現実には、その記録が請求システムとCRMに、別々の項目名で散らばっています。

請求システム: billing_entitlements.granted_feature_id\nCRM:          crm_entitlements.enabled_feature_id\n

オントロジー型では、こう書くだけで2つを同じ意味として扱えます。

billing:grantedFeature rdfs:subPropertyOf saas:entitlesFeature .\ncrm:enabledFeature     rdfs:subPropertyOf saas:entitlesFeature .\n

問い合わせる側はsaas:entitlesFeature一本で書けばよく、データ自体は書き換えません。これは7章で実際に確かめたとおりです。

では、メトリクス型ではQ2はどうなるか。ここは公平に書いておきます。

「メトリクス型は複数ソースを束ねられない」は、正確ではない。\n\nメトリクス型の世界では、\n複数ソースの統合は、セマンティックレイヤーの「下」で済ませておく。\ndbt などの変換処理で、請求とCRMのテーブルを\n1つの entitlements テーブルに揃えてから、その上に定義を載せる。\n

つまり、違いは「束ねられるか」ではなく、束ねる判断をどこに書くかです。

メトリクス型:\n    「grantedFeature と enabledFeature は同じ意味だ」という判断は、\n    変換処理（SQL）の中に書かれる。\n\nオントロジー型:\n    同じ判断を、変換処理の外に、\n    機械が読める「意味の宣言」として書く。\n

そして、Q2はそもそも集計の問いではありません。メトリクスとディメンションという型に、自然には収まらない問いです。

9.3 比較表

ここまでの比較を表にまとめます。

観点メトリクス型オントロジー型
定義する単位メジャー・ディメンション・結合クラス・プロパティ・関係
答えやすい問いどれだけ？（集計）何が何と、どうつながっている？
定義の置き場所テーブルの上（DWHのカタログ）テーブルから独立（Turtleなど）
複数ソースの語彙合わせ下の変換層（dbt等）で済ませておくマッピングとして宣言する
推論なし（集計の意味づけはある）あり（逆関係、上位プロパティ、クラス階層）
書かれていない事実の扱い「無い」とみなす（閉世界仮定）推論では「わからない」とみなす（開世界仮定、6.3節）。ただしSPARQLの結果やSHACLの検証は、グラフにあるものだけで判断する
制約の検証定義の整合性は作成時に検証される。データの制約はテスト（dbt testsなど）で確認するSHACLで宣言する
集計性能強い（列指向エンジン）弱め（大規模集計は不得意）
標準Apache Ossie（旧OSI）が整備中W3C標準（RDF/OWL/SPARQL/SHACL）
人材・ツール豊富少ない
AIとの組み合わせセマンティックモデルを手がかりに、自然文→SQL（Cortex Analyst、Genieなど）自然文→SPARQL、ナレッジグラフ

9.4 メトリクス型のPros / Cons

Pros:\n    ・「数字が合わない」問題に、直接対応する\n    ・データウェアハウスの中にあり、権限管理も性能もそのまま使える\n    ・SQLの延長なので、データ分析の人材がそのまま使える\n    ・BIツールやAIエージェントとの連携が、製品として整っている\n\nCons:\n    ・定義はテーブル構造に依存する。テーブルが先、意味が後\n    ・「AとBは同じ意味」という判断が、変換処理のSQLに埋もれやすい\n    ・推論がない。書いた計算式以上のことは出てこない\n    ・集計にならない問い（関係・資格・依存）は、型に収まりにくい\n

9.5 オントロジー型のPros / Cons

Pros:\n    ・意味の体系がテーブルから独立しているので、ソースが増えても影響を受けにくい\n    ・意味の対応関係を、クエリの外に機械可読な形で書ける\n    ・推論で、書かれていない事実を導ける\n    ・W3C標準なので、特定ベンダーに閉じない\n\nCons:\n    ・集計・時間粒度・大規模データの扱いは、メトリクス型に劣る\n    ・RDF/SPARQLを扱える人が少ない\n    ・既存のRDBのデータをRDFとして扱う工程（変換か仮想化）が別途必要\n    ・推論には計算コストがかかり、設計判断が要る\n

どちらも魔法ではありません。目的が違う道具です。

10. AIがセマンティックレイヤーを使う場合

もう1つ、いまの時代に重要な応用に触れておきます。

LLM（大規模言語モデル）に「株式会社ABCは販売管理機能を使えますか？」と聞いたとき、何が起きるべきでしょうか。

セマンティックレイヤーが無い場合:\n    LLMが学習データからそれっぽい答えを生成する\n    → ハルシネーション（幻覚）のリスク\n\nセマンティックレイヤーがある場合:\n    LLMが、問いをSPARQLに変換する\n    → セマンティックレイヤーに問い合わせる\n    → 返ってきた事実に基づいて答える\n

セマンティックレイヤーがあれば、LLMは「答えを創作する」のではなく「問いを翻訳する」役割に徹することができます。

人間の質問:\n    「株式会社ABCは販売管理機能を使える？」\n\nLLMが生成するSPARQL:\n
PREFIX saas: <https://example.com/ontology/saas#>\nPREFIX ex:   <https://example.com/data/>\n\nSELECT ?featureName ?status\nWHERE {\n    ex:tenant-abc saas:hasEntitlement ?e .\n    ?e saas:entitlesFeature ?f .\n    ?f saas:name ?featureName .\n    FILTER(CONTAINS(?featureName, \"販売管理\"))\n    ?e saas:entitlementStatus ?status .\n}\n
セマンティックレイヤーの応答:\n    （0行）\n\nLLMの最終回答:\n    「株式会社ABCは現在、販売管理機能を利用できません。\n      この機能に対する有効なEntitlementが\n      存在しないためです。」\n

ここでLLMが正しいクエリを組み立てられるのは、T-Boxに「Tenant」「Entitlement」「Feature」が何であり、どうつながっているかが書いてあるからです。T-Boxからは、クエリの形（どのプロパティをたどるか）が分かります。絞り込む値の「販売管理」は、LLMが質問の言葉から取り出しています。

LLMにテーブル定義だけを渡した場合:\n    「entitlements.status って何の状態？」\n    「tenant_id と customer_id は同じもの？」\n    → 推測が入る\n\nLLMにT-Boxを渡した場合:\n    第3回で Entitlement の rdfs:comment に書いた\n    「特定のTenantに、特定のFeatureを提供する権利、資格または状態」\n    が読める\n    → 推測が減る\n

第1回からrdfs:labelとrdfs:commentを丁寧に書いてきたのは、人間のためだけではなかったわけです。

なお、今回のontology.ttlは、説明を短くするためにrdfs:commentを省いています。実際にLLMへ渡すなら、第3回までの定義をコメントごと渡します。

この方向性は、メトリクス型の製品にも共通しています。どの製品も、AIエージェント向けの機能を足しています。

Snowflake   Semantic View に、AI向けの指示や検証済みクエリを書ける句がある\n            → Cortex Analyst などが参照する\nDatabricks  Metric View に synonyms（同義語）を書ける\n            → Genie が参照する\nLooker      LookML を、Gemini の会話型分析の根拠として使う\n

目的は共通していて、「LLMに計算を推測させず、定義に従って決定的に答えさせる」ことです。これは、この章で見た「LLMを『答えを創作する役』から『問いを翻訳する役』にする」という話と、まったく同じ方向です。

11. 2つの系統は近づいている

ここまで「2つの系統」として分けてきましたが、実は最近、両者の境界は少しずつ曖昧になっています。きっかけは、10章で見たとおり、どちらもAIに正確に答えさせる手段として注目されていることです。

11.1 Microsoft Fabric IQのOntology

一番わかりやすい合流の例が、MicrosoftがIgnite 2025で発表したFabric IQです。その中核に、Ontologyというアイテム（2026年10月時点でプレビュー）があります。

Fabric IQ の Ontology で定義するもの（公式ドキュメントより）:\n\n    entity type      （≒ クラス）\n    relationship     （≒ プロパティ）\n    継承・namespace\n    metric           ← Power BI の Semantic Model の DAX メジャーを参照する\n    rule             （自然言語で書く）\n

面白いのは、metricをオントロジーの中で「参照」している点です。計算式そのもの（DAX）は元のSemantic Modelが持ち続け、オントロジーはそれを「このエンティティに関する指標」として結びつけます。

オントロジー   : 「Tenant とは何か」「何とつながっているか」\nメトリクス層   : 「Tenant ごとの数字を、どう計算するか」\n\n→ 置き換えるのではなく、重ねている\n

また、FabricのOntologyはRDF / Turtle / OWLのサブセットの取り込みと、RDF / Turtleでの書き出しをドキュメントに載せています（取り込み先は空のOntologyアイテムで、取り込み結果は、そのまま保たれた要素・自動で調整された要素・対応していない要素に分けて報告されます）。データ・分析基盤の大手が、W3Cのオントロジー形式との行き来を公式にうたった例です。

さらに、FabricのOntologyは基本的には自分でデータを持たない「仮想的な意味のレイヤー」で、実際の問い合わせは接続先のデータソースで実行されます（多段の関係をたどる場合などは、FabricのGraphにデータを任意で実体化することもできます）。これは、RDFの世界で以前からあるR2RML / Ontop（SPARQLをSQLに書き換えて、元のDBで実行する）とよく似た発想です。

11.2 Apache Ossie も、オントロジーを対象に加えた

2章で触れたOSI（現 Apache Ossie）も、同じ方向に動いています。2026年7月にApache Incubatorへ移ったとき、Ossieは自らを「セマンティックレイヤーとオントロジーの両方のための仕様」と位置づけ直しました。

さらに、草案段階（v0.2.0.dev0）のオントロジー仕様では、概念や関係にiriフィールドを持たせ、既存のRDF/OWL語彙のクラスやプロパティと対応づけられるようになっています。メトリクス型から始まった標準化が、オントロジー、さらにW3Cの語彙との接続にまで広がってきたわけです。

11.3 「オントロジー」という言葉の広がり

ちなみに、Palantir FoundryのOntologyは、オブジェクト型・リンク型・アクション型という独自のモデルで業務の世界を表現するもので、RDF/OWLをデータモデルの基盤にはしていません（Palantir自身の資料では、RDF/OWL形式との入出力もうたわれています）。MicrosoftのGraphRAGも、LLMでテキストからナレッジグラフを作るもので、RDFではありません。

「オントロジー」「ナレッジグラフ」と名乗っていても、\nW3C標準の RDF/OWL とは限らない。\n

ここは混乱しやすいので、覚えておくと便利です。

12. レイヤー構成を整理する

最後に、全体像を整理します。

問い合わせる側（BIツール、AI、スクリプト、人間）\n    │\n    │  共通語彙 saas: で問う\n    ↓\nセマンティックレイヤー\n    ├── ontology.ttl ＝ T-Box（意味の定義）\n    └── mapping.ttl  ＝ 各ソース語彙との意味の対応\n    │\n    │  推論して、書かれていない事実も導く\n    ↓\nRDFとして表現されたデータ（A-Box）\n    │\n    │  ここに、元のデータをRDFに変換する（取り込む）工程が必要\n    ↓\n実際のデータソース\n    ├── Postgres\n    ├── SaaSのAPI\n    └── CSV など\n

ここで、正直に書いておかなければならないことがあります。

今回の記事では、data.ttl を手で書いた。\n\nしかし実務では、データはPostgresやSaaSのAPIの中にある。\nそれをA-Box（RDF）にする工程は、\n誰かが作らなければならない。\n

この工程は、この記事では扱っていません。実際には、次のような選択肢があります。

・定期的にRDFへ書き出す（マテリアライズ）\n・問い合わせ時にSQLへ変換する（R2RML / Ontop などの仮想化。データはRDBに置いたまま、SPARQLをSQLに書き換えて実行する）\n・アプリケーション側でRDFとして書き出す\n

「セマンティックレイヤーがあれば変換が不要になる」わけではありません。7章で不要になったのは、項目名をそろえるための変換でした（mapping.ttlが語彙どうしの対応を引き受けたからです）。PostgresなどのデータをRDFの形にする変換は、依然として必要です。セマンティックレイヤーが不要にするのは、「システムごとにバラバラな意味の解釈を、問い合わせる側が毎回やり直すこと」です。

メトリクス型のセマンティックレイヤーも含めて描き直すと、こうなります。

問い合わせる側（BIツール、AIエージェント、人間）\n    │\n    ├──「どれだけ？」────→ メトリクス型セマンティックレイヤー\n    │                      （Snowflake / Databricks / Fabric / dbt）\n    │                         │\n    │                         │ 「Tenant」「Plan」の意味は\n    │                         │ オントロジーに従う\n    │                         ↓\n    └──「何が何と、どう？」→ オントロジー型セマンティックレイヤー\n                              （このシリーズで作っている saas: 語彙）\n                                 │\n                                 ↓\n                            各システムのデータ\n                            （SaaS管理基盤、請求、CRM、サポート…）\n
オントロジー   = 意味の基準\n    「Tenantとは何か」\n    「EntitlementとSubscriptionはどう違うか」\n    「請求システムの customer と CRM の account は同じものか」\n\nメトリクス層   = 計算の基準\n    「Tenantごとの月間利用量を、どう集計するか」\n    「プラン別の新規契約数を、どう数えるか」\n

メトリクス型で「アクティブテナント数」を定義するとき、その前提には「そもそもTenantとは何か」「どの状態をアクティブと呼ぶか」という取り決めがあるはずです。その取り決めを、テーブルやSQLの中に埋もれさせずに書き出したものが、オントロジーです。

2つは競合ではなく、積み重なるものだと考えています。そして、このシリーズが作っているのは下の層、つまり意味の基準のほうです。

ここまで見てきた「意味の定義」は、このシリーズの第1回から第3回で作ってきたもの、そのものです。

第1回：Tenant, User, Membership, Role, Permission, Subscription, Plan, Resource\n第2回：Organization, Workspace, Team, RoleAssignment\n第3回：Feature, Entitlement\n

つまり、オントロジーを作ること＝セマンティックレイヤーの語彙を構築することでした。第4回以降で語彙が増えるたびに、このセマンティックレイヤーが答えられる問いも増えていきます。

まとめ

「セマンティックレイヤー」には、2つの系統がある:\n\n    メトリクス型（Snowflake / Databricks / Fabric / dbt / Cube / Looker）\n        数字の計算のしかたを、テーブルの上に定義する\n        → 「どれだけ？」に強い。数字のズレをなくす\n\n    オントロジー型（RDF / OWL / SPARQL / SHACL）\n        ものごとの関係と意味を、テーブルから独立して定義する\n        → 「何が何と、どうつながっている？」に強い。推論と横断ができる\n\n    このシリーズが作っているのは、オントロジー型\n\nセマンティックレイヤーとは:\n    データの意味を一箇所に定義し、\n    どのツールからでも同じ意味で問い合わせられるようにする仕組み\n\nオントロジーとの関係:\n    T-Box（クラスとプロパティの定義）がセマンティックレイヤーの本体\n    A-Box（実データ）はT-Boxの語彙で記述される\n\nT-Boxは飾りではない:\n    owl:inverseOf を書いておくと、推論で逆方向をたどれる\n    → 推論なし 0行、推論あり 3行\n\n意味の対応を宣言すれば、語彙の違いを吸収できる:\n    rdfs:subPropertyOf で各システムの語彙を共通語彙に接続\n    → データもクエリも変更せず、3行から5行に\n\n正直な限界:\n    ・逆方向は、推論なしでも（逆パス ^ などで）取れる。\n      推論の価値は「問い合わせる側が共通語彙一本で書けること」\n    ・owl:inverseOf はRDFS推論では処理されない（OWLの推論が必要）\n    ・推論の増加分の大半は固定オーバーヘッド（265件中、約230件）\n    ・SPARQLも述語IRIが変われば壊れる\n    ・PostgresなどからA-Boxへの変換工程は別途必要\n

手を動かした手順は、次の4ステップでした。

1. pip install rdflib owlrl\n2. ontology.ttl（T-Box）と data.ttl（A-Box）を保存する\n3. python query.py ontology.ttl data.ttl query-features.rq\n   → 0行（hasEntitlement 方向のトリプルがまだ存在しない）\n4. python query.py --inference ontology.ttl data.ttl query-features.rq\n   → 3行（T-Boxの owl:inverseOf から、逆向きの事実が導かれた）\n

ここまでで、このシリーズで作っているオントロジーがどう使われるかが、なんとなく伝わったかと思います。具体的なユースケースでどう使うの？というのは、さらに別の会でもっと具体的に説明したいと思います。

次回（第4回）からは、語彙の構築に戻ります。テーマは「使える。でも、どこまで？」です。Featureが使えるとして、その上限と消費量をどう表現するか、という話に入っていこうと思います！

こちらからは以上です。

参考資料（2026年10月時点）

","url":"https://ghost.tech.anti-pattern.co.jp/saaswoti-cai-nisitaontoroziwozuo-tutemiyousirizu-3-donoji-neng-gashi-erunoka/","canonical_url":null,"uuid":"a4602a42-50eb-4713-a38a-30cf7ea57972","page":null,"codeinjection_foot":null,"codeinjection_head":null,"codeinjection_styles":null,"comment_id":"6ad5b842d3fc9f00013c2337","reading_time":30}},"pageContext":{"slug":"saaswoti-cai-nisitaontoroziwozuo-tutemiyousirizu-3-donoji-neng-gashi-erunoka"}}, "staticQueryHashes": ["176528973","2358152166","2561578252","2731221146","4145280475"]}