AI Readyなデータ基盤とオントロジー実装入門 ─ Knowledge Graphで「意味のわかるデータ」を作る

目次

• AI Readyなデータ基盤とは何か
• まず用語を整理する — データ基盤まわり
• まず用語を整理する — 意味づけまわり
• AI Readyに重要な標準・言語
• Glossary・Ontology・Knowledge Graphの違い
• AI Readyなデータ基盤の5層構造
• なぜAIにはオントロジーが必要か
• オントロジー実装の考え方 — Competency Questionから始める
• 最小オントロジーの設計 — 個人事業向け
• RDF/OWLの最小コード例
• OWLとSHACLの役割の違い
• 元データとオントロジーをつなぐMapping
• 実装方式の2パターン — MaterializedとVirtual
• オントロジー以外で必要なもの
• 検証の5段階
• OWL 2 Profiles — 用途別の軽量版
• 個人事業向け最小構成と答えられる問い
• 関連ツール一覧
• まとめ

---

AI Readyなデータ基盤とは何か

AI Readyなデータ基盤とは、AIがデータを「読める」だけでなく、「そのデータが何を意味し、どうつながり、どこまで信頼してよいか」を機械的に理解できる基盤のことです。

「AIに分析させたいからデータを渡す」という発想だと、多くの場合うまくいきません。AIはデータの列名と値を見ることはできますが、その列が何を意味するのか、他のテーブルとどうつながっているのか、その数字がどこから計算されたのかを自分では判断できないからです。あなたが「売上のトレンドを分析して」と頼んでも、AIは「売上」という言葉の意味をデータの文脈の中で正しく把握できているとは限りません。

具体的に、AI Readyなデータ基盤が答えられなければならない問いを並べると次のようになります。

• どのテーブルに何が入っているか分かるか
• customer と client が同じ意味か違う意味か分かるか
• 「売上」がどう計算されるか分かるか
• その数字がどこから来たか追跡できるか
• 品質が悪いデータを事前に弾けるか
• AIが質問したときに、正しいデータを正しい意味で取りに行けるか

これらがすべて機械的に解決できる状態を「AI Ready」と呼びます。逆に言えば、データが単にDWHに存在するだけでは不十分であり、「データの意味のネットワーク」が構造化されて初めてAIは正確に動きます。本記事ではこの「意味のネットワーク」を作るための概念と実装方法を、個人事業・小規模チームでも始められるレベルから順を追って解説します。

---

まず用語を整理する — データ基盤まわり

AI Readyなデータ基盤を理解するには、まず基礎的な用語を整理する必要があります。似た言葉が多く混乱しやすい領域ですが、それぞれが異なる役割を持っています。

DWH（Data Warehouse） は、分析用に整理されたデータ置き場です。生データをそのまま突っ込む場所ではなく、レポートや集計をしやすいように整頓された倉庫のイメージです。BigQuery、Snowflake、Redshiftなどが代表的なサービスです。小規模チームでもBigQueryのオンデマンド課金を使えば月数百円から始められます。

Lakehouse は、Data LakeとDWHの中間に位置するアーキテクチャです。Data Lakeの「なんでも柔軟に入れられる」という特性と、DWHの「分析しやすい整理された構造」を両立させようとする概念です。Delta LakeやApache Icebergなどの技術がこのアプローチを実現します。

Metadata（メタデータ） は、データについての説明データです。「この列は何の意味か」「更新頻度は何か」「誰が管理者か」「最終更新日時はいつか」といった情報がメタデータに当たります。データ本体と同じくらい重要であり、AIがデータを理解するために不可欠な情報です。

Data Catalog（データカタログ） は、データの目録です。どのデータがどこにあり、何を表しているかを探せる仕組みです。OpenMetadata、DataHub、Google Dataplexなどのツールが代表的です。規模が小さければ、Notionやスプレッドシートで代用することもできます。

Lineage（データリネージ） は、データが「どこから来て、どの処理を通って、今の形になったか」の流れです。raw → staging → mart → dashboardという変換の連鎖を追跡できる仕組みです。数字が突然変わったとき、その原因を追跡するために必須の概念です。

Provenance（データプロベナンス） は、「このデータは誰が、いつ、どう作ったか」という由来情報です。Lineageが「処理の流れ」を追うのに対し、Provenanceは「出自の説明」に注目します。「この推定値は手入力なのか、広告管理画面からのAPIコールで取得したのか」といった情報がProvenanceです。AIが数字の信頼性を判断するために重要です。

---

まず用語を整理する — 意味づけまわり

データ基盤の物理的な構造に加えて、「意味」を扱うための語彙も整理しておきましょう。この領域こそが、AI Readyなデータ基盤の核心です。

Glossary（グロッサリー） は、業務用語集です。「Leadは見込み客」「Clientは契約済み顧客」「Engagementは案件・契約単位」といった、チーム内で使う言葉の意味を統一するためのドキュメントです。人間が用語を揃えるのが主な目的ですが、これをデータカタログに取り込むことでAIも参照できるようになります。

Taxonomy（タクソノミー） は、分類表です。親子関係を中心に概念を整理します。「コンテンツ → 記事 → 事例記事」のように階層的に分類する構造がTaxonomyです。ECサイトの商品カテゴリなどがわかりやすい例です。

Ontology（オントロジー） は、概念（何が存在するか）と関係（どう結びつくか）を機械が読めるように明示したモデルです。業務世界の意味の設計図とも言えます。「ArticleはKeywordをtargetsできる」「InvoiceはEngagementに属する」といった、概念同士の関係を形式的に表現します。TaxonomyがWordとして「親子関係」を扱うのに対し、OntologyはWord同士のあらゆる種類の「関係」を扱えます。

Knowledge Graph（ナレッジグラフ） は、オントロジーという設計図に沿って実データを入れた「関係のネットワーク」です。「Article_123はLead_456を生んだ」「Client_007はEngagement_021を持つ」というように、実際の個体（Individual）が関係でつながったグラフ構造です。GoogleのKnowledge Panelや、ChatGPTが事実を参照するときの情報源がこれに近いものです。

Semantic Layer（セマンティックレイヤー） は、指標やメトリクスの計算ルールを管理する層です。「売上は何を足すのか」「LTVはどう定義するのか」「MAUはユニークユーザーをどの期間で数えるのか」といった定義を一元管理します。ツールごとに計算式が違って数字がブレる問題をSemanticLayerで解決します。dbt Semantic LayerやCubeがこのアプローチを実装しています。

---

AI Readyに重要な標準・言語

オントロジーとKnowledge Graphを実装するためには、業界標準の言語と仕様を知っておく必要があります。難しそうに見えますが、実際に使うのはそのうちの一部です。

RDF（Resource Description Framework） は、データを「主語-述語-目的語」の3つ組（トリプル）で表すルールです。「Article_100 - targetsKeyword - Keyword_SEO」のように、すべての関係を3つの要素で表現します。このシンプルな構造が、あらゆるデータをグラフとして統一的に扱えるようにします。

OWL（Web Ontology Language） は、オントロジーを書くための言語です。クラス・関係・制約・推論の前提を定義します。「Article（記事）というクラスが存在し、ArticleはKeyword（キーワード）をtargetsできる」といった意味の設計図を書くための言語です。

SHACL（Shapes Constraint Language） は、RDFデータが「期待した形」になっているか検査するための言語です。「Articleは公開日を必ず1つ持たなければならない」「必ず1つ以上のKeywordに紐付いていなければならない」というルールを定義し、実データを検査できます。

SPARQL は、RDF/Knowledge Graphを検索するクエリ言語です。RDBに対するSQLのようなものです。「どの記事が、2026年に公開されて、SEOというキーワードに紐付いているか」といった問いを、グラフを辿りながら答えられます。

JSON-LD は、JSONに「意味づけ」を足した形式です。WebページにStructured DataとしてSchemaを埋め込むときにもよく使われます（Googleリッチスニペットなど）。WebやAPIと相性が良く、既存のJSONデータにメタデータを追加するのに便利です。

SKOS（Simple Knowledge Organization System） は、TaxonomyやGlossaryを整理するための標準語彙です。「preferredLabel（推奨名称）」「altLabel（別名）」「narrower（下位概念）」「broader（上位概念）」といった語彙が定義されています。

R2RML は、RDB（リレーショナルデータベース）をRDFにどう対応づけるかを定義する標準です。「テーブルをグラフに変換する対応表」と理解してください。既存のDWHをオントロジー層につなぐために使います。

---

Glossary・Ontology・Knowledge Graphの違い

似ている概念を改めて整理すると、次のような階層関係にあります。この違いを理解することが、実装設計の第一歩です。

Glossary（グロッサリー） は用語辞典です。「Leadとは見込み客のことである」という定義を人間が読めるように記述したものです。主な目的は、チーム内で言葉を揃えることです。データカタログに入れておくことで、AIが用語を調べるための参照先になります。

Taxonomy（タクソノミー） は分類表です。親子関係で概念を整理します。Glossaryよりも構造が明確ですが、扱える関係は主に「上位・下位・同位」に限られます。

Ontology（オントロジー） は世界の設計図です。概念間の関係まで定義します。「ArticleはKeywordをtargetsできる」「InvoiceはEngagementに属する」というように、概念間のあらゆる種類の関係を形式的に記述できます。Glossaryが「言葉の意味の辞書」であるのに対し、Ontologyは「概念の関係の地図」です。

Knowledge Graph（ナレッジグラフ） は設計図に基づく実データの地図です。Article_123やLead_456のような実際の個体（Individual）を、オントロジーの設計図に従って配置したものです。設計図（Ontology）があって初めて、データをグラフとして正しく解釈できます。

まとめると、Glossary → Taxonomy → Ontology → Knowledge Graphの順に抽象度が下がり、実データに近づいていきます。AIが「意味を理解してデータを扱う」ためには、少なくともOntologyのレベルまで定義が必要です。

---

AI Readyなデータ基盤の5層構造

AI Readyなデータ基盤を設計するとき、次の5層を意識すると整理しやすくなります。小規模チームであれば全層を一度に揃える必要はなく、上から順に段階的に積み上げていくことができます。

第1層: Canonical Data層 はDWH/Lakehouseを中心とした正本データです。顧客テーブル、記事テーブル、セッションテーブル、請求テーブルといった分析の源泉データがここに入ります。dbtなどのツールを使ってraw → staging → martの変換パイプラインを構築するのが一般的です。

第2層: Metadata/Catalog/Lineage層 はデータの説明・所在・流れの管理層です。どのテーブルに何が入っているか、列は何を意味するか、データがどこから来たかを記録します。OpenMetadataやDataHubのようなデータカタログツール、またはdbt docsのようなツールでこの層を実現できます。

第3層: Business Semantics層 は業務用語の意味管理層です。Glossary（用語集）、Taxonomy（分類体系）、Semantic Layer（メトリクス定義）がここに入ります。「売上」「LTV」「MAU」といった指標の計算ルールをここで一元管理することで、ツールごとの定義のブレを防ぎます。

第4層: Ontology/Knowledge Graph層 は概念同士の関係を機械可読に表現する層です。OWLで設計図を書き、RDFで実データをグラフとして表現します。AIがデータを「意味として」辿るための入口がここです。

第5層: Serving層 はAI・アプリから使うための入口です。SQL、SPARQL、REST API、ベクトル検索など、利用側のニーズに合わせた形式でデータを提供します。RAG（Retrieval-Augmented Generation）のためのベクトルDBもここに位置づけられます。

小規模チームで「まず始める」なら、第1層と第2層を整えてから、第3層のGlossaryを作ることをお勧めします。第4層のOntologyは、「AIに質問に答えさせたい」という具体的な目的が生まれてから取り組むのが現実的です。

---

なぜAIにはオントロジーが必要か

AIは、そのままではデータを「列名と値の集まり」としてしか見られません。人間なら「client_idとcustomer_idは同じ意味だろう」と文脈から推測できますが、AIには確信を持って判断する根拠がありません。これは単なるLLMの限界ではなく、データの側に意味が記述されていないことが根本原因です。

具体的に、オントロジーがない場合にAIが判断できないことを並べてみます。

• client_id と customer_id は同じ意味のエイリアスなのか、別の概念なのか
• contract と engagement は同じエンティティを指すのか、違うのか
• article と deliverable はどういう関係にあるのか（成果物の一形態が記事なのか、無関係なのか）
• lead と invoice はどうつながっているのか（どんな中間概念を経由するのか）

オントロジーがあると、これらの意味の関係をAIが辿れるようになります。「client_idとcustomer_idはowl:sameAsで同一エンティティだと定義されている」「leadはconvertedToでengagementにつながる」という定義があれば、AIはそれを前提として質問に答えられます。

さらに重要なのは、AIが「どこまで確信を持っていいか」を判断できるようになることです。オントロジーとSHACLによるデータ品質検証が組み合わさると、「このデータはschema validationをパスしているから信頼できる」「このフィールドはProvenanceが記録されていないから推定値の可能性がある」といった判断ができるようになります。

---

オントロジー実装の考え方 — Competency Questionから始める

オントロジーを「きれいに作ること」を目的にすると、実務で役立たない理論的な図鑑になりがちです。そうならないために、実装の最初のステップはCompetency Question（コンピテンシークエスチョン）を先に定義することです。

Competency Questionとは、「このオントロジーを使って答えたい代表的な質問」のことです。個人事業向けの例を挙げると、次のようなものです。

• どのキーワード群が受注につながったか
• どの記事が問い合わせを生んだか
• どの案件タイプが継続につながりやすいか
• どのSNS投稿が商談化に効いたか

これらの問いを先に決めることで、「どの概念をモデル化すべきか」「どの関係を定義すべきか」が自然に決まります。Competency Questionが曖昧なまま設計を進めると、「きれいだけど誰も使わない」オントロジーができ上がります。

次のステップはBounded Context（バウンデッドコンテキスト）で範囲を絞ることです。最初から全社のデータをオントロジー化しようとすると確実に挫折します。最初は1つの業務の流れに絞りましょう。

• Lead-to-Cash（リード獲得から売上まで）
• Content-to-Conversion（コンテンツから問い合わせ・受注まで）

個人事業であれば「Content-to-Conversion」から始めるのが自然です。「記事を書く → 検索流入 → 問い合わせ → 受注」というシンプルな流れを、まずオントロジーとして定義します。

その後、まずGlossaryを作ります。用語を一覧化して意味を明確にする作業です。例えば以下のようなものです。

• Lead = 見込み客（問い合わせや資料ダウンロードなどのアクションをした人）
• Client = 契約済み顧客（実際に発注いただいた方）
• Engagement = 案件・契約単位（1つのプロジェクト、1つの契約）
• Deliverable = 納品物（記事、設計書、データ分析レポートなど）
• Invoice = 請求書

このGlossaryが整ったら、次のステップとしてOntologyを設計します。Glossaryが「言葉の意味」を定義するのに対し、Ontologyは「概念同士の関係」を定義します。

---

最小オントロジーの設計 — 個人事業向け

個人事業・小規模チーム向けに、まず実装すべき最小オントロジーを定義します。複雑にしすぎず、Competency Questionに答えるために必要最小限の概念と関係だけを含めます。

クラス（種類）の定義:

• Client — 顧客
• Engagement — 案件・契約
• Deliverable — 納品物
• Article — コンテンツ記事
• Keyword — 狙っているSEOキーワード
• Lead — 見込み客
• Invoice — 請求書

関係（ObjectProperty）の定義:

• hasDeliverable: Engagementが Deliverableを持つ（案件と納品物の関係）
• targetsKeyword: ArticleがKeywordを狙う（記事とキーワードの関係）
• generatedLead: Articleが Leadを生んだ（記事と問い合わせの関係）
• convertedTo: LeadがEngagementに転換した（見込み客と案件の関係）
• billedFor: InvoiceがEngagementに対して発行される（請求書と案件の関係）
• billedTo: InvoiceがClientに発行される（請求書と顧客の関係）

属性（DatatypeProperty）の定義:

• publishedAt: Articleの公開日（xsd:date型）
• amount: Invoiceの金額（xsd:decimal型）
• contractedAt: Engagementの契約日（xsd:date型）

この最小構成があれば、「どの記事がどのキーワードを狙い、どの見込み客を生み、どの案件・売上につながったか」という一連のフローをデータとして辿れるようになります。

---

RDF/OWLの最小コード例

実際にOntologyをコードとして書いてみましょう。RDF/OWLの最もシンプルな記法がTurtle（.ttl）形式です。XMLよりずっと読みやすく、始めやすい形式です。

@prefix ex:   <https://example.com/ontology/> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .

# ------------------------------------------
# クラス定義（どんな「種類」が存在するか）
# ------------------------------------------

ex:Article a owl:Class ;
  rdfs:label "記事"@ja ;
  rdfs:comment "SEOを意識して公開したコンテンツ記事"@ja .

ex:Keyword a owl:Class ;
  rdfs:label "キーワード"@ja ;
  rdfs:comment "記事が検索流入を狙うキーワード"@ja .

ex:Lead a owl:Class ;
  rdfs:label "見込み客"@ja ;
  rdfs:comment "問い合わせや資料ダウンロードを行った人"@ja .

ex:Engagement a owl:Class ;
  rdfs:label "案件"@ja ;
  rdfs:comment "契約または進行中のプロジェクト単位"@ja .

ex:Invoice a owl:Class ;
  rdfs:label "請求書"@ja ;
  rdfs:comment "案件に対して発行した請求書"@ja .

# ------------------------------------------
# ObjectProperty（もの同士を結ぶ関係）
# ------------------------------------------

ex:targetsKeyword a owl:ObjectProperty ;
  rdfs:domain ex:Article ;
  rdfs:range  ex:Keyword ;
  rdfs:label  "キーワードを狙う"@ja .

ex:generatedLead a owl:ObjectProperty ;
  rdfs:domain ex:Article ;
  rdfs:range  ex:Lead ;
  rdfs:label  "見込み客を生んだ"@ja .

ex:convertedTo a owl:ObjectProperty ;
  rdfs:domain ex:Lead ;
  rdfs:range  ex:Engagement ;
  rdfs:label  "案件に転換した"@ja .

ex:billedFor a owl:ObjectProperty ;
  rdfs:domain ex:Invoice ;
  rdfs:range  ex:Engagement ;
  rdfs:label  "案件に対して請求した"@ja .

# ------------------------------------------
# DatatypeProperty（ものと値を結ぶ属性）
# ------------------------------------------

ex:publishedAt a owl:DatatypeProperty ;
  rdfs:domain ex:Article ;
  rdfs:range  xsd:date ;
  rdfs:label  "公開日"@ja .

ex:amount a owl:DatatypeProperty ;
  rdfs:domain ex:Invoice ;
  rdfs:range  xsd:decimal ;
  rdfs:label  "請求金額"@ja .

# ------------------------------------------
# Individual（実データの1件）
# ------------------------------------------

ex:Article_100 a ex:Article ;
  ex:publishedAt     "2026-04-01"^^xsd:date ;
  ex:targetsKeyword  ex:Keyword_SEO ;
  ex:generatedLead   ex:Lead_501 .

ex:Keyword_SEO a ex:Keyword ;
  rdfs:label "AI Readyデータ基盤"@ja .

ex:Lead_501 a ex:Lead ;
  ex:convertedTo ex:Engagement_201 .

ex:Engagement_201 a ex:Engagement .

ex:Invoice_301 a ex:Invoice ;
  ex:billedFor ex:Engagement_201 ;
  ex:amount    "300000"^^xsd:decimal .

このコードは「Article_100という記事が、“AI Readyデータ基盤”というKeywordを狙い、Lead_501という見込み客を生み、その見込み客がEngagement_201という案件に転換し、Invoice_301として30万円の請求が発生した」という一連のビジネスの流れを、機械が読める形で表現しています。

Turtle形式の読み方のポイントは2つです。a は rdf:type（〜というクラスのインスタンスである）の略称です。また、^^xsd:date のような表記は、リテラル値の型を明示するためのものです。

---

OWLとSHACLの役割の違い

OWLとSHACLは似たように見えて、まったく異なる役割を持ちます。この違いを理解しないと、「なぜ2つ必要なのか」が分かりにくくなります。

OWL は概念の意味や関係を表現するための言語です。「ArticleとKeywordはtargetsKeywordで結びつく」という意味の定義を書くためのものです。OWLの世界観は「Open World Assumption（開世界仮説）」に基づいています。書かれていないことは「まだ分かっていないだけかもしれない」と解釈されます。つまり、「publishedAtが書かれていないArticle」は「公開日が存在しないArticle」ではなく、「公開日がまだ記録されていないArticle」として扱われます。

SHACL は実データがルール通りかを検査するための言語です。「Articleは公開日を必ず1つ持たなければならない」というバリデーションルールを書くためのものです。SHACLの世界観は「Closed World Assumption（閉世界仮説）」に基づいています。必須項目が無いなら、それはエラーです。

整理すると「意味の定義 = OWL」「データ検査 = SHACL」と分けて考えるのが実務的です。

SHACLの実装例を見てみましょう。

@prefix ex:  <https://example.com/ontology/> .
@prefix sh:  <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:ArticleShape a sh:NodeShape ;
  sh:targetClass ex:Article ;
  sh:property [
    sh:path     ex:publishedAt ;
    sh:datatype xsd:date ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:message  "Articleは公開日を正確に1つ持たなければなりません"@ja
  ] ;
  sh:property [
    sh:path     ex:targetsKeyword ;
    sh:class    ex:Keyword ;
    sh:minCount 1 ;
    sh:message  "Articleは最低1つのKeywordに紐付いていなければなりません"@ja
  ] .

ex:InvoiceShape a sh:NodeShape ;
  sh:targetClass ex:Invoice ;
  sh:property [
    sh:path     ex:billedFor ;
    sh:class    ex:Engagement ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:message  "Invoiceは必ず1つのEngagementに紐付かなければなりません"@ja
  ] ;
  sh:property [
    sh:path     ex:amount ;
    sh:datatype xsd:decimal ;
    sh:minCount 1 ;
    sh:message  "Invoiceには請求金額が必要です"@ja
  ] .

このSHACLを使うと、「公開日が入っていないArticle」「Keywordに紐付いていないArticle」「案件に紐付いていないInvoice」「金額が入っていないInvoice」をプログラムで自動検出できます。PythonのpySHACLライブラリを使えば、数行のコードで検証を実行できます。

from pyshacl import validate

# shacl_graphにSHACLファイル、data_graphにRDFデータを読み込んで検証
conforms, results_graph, results_text = validate(
    data_graph,
    shacl_graph=shacl_graph,
    inference='rdfs',
    abort_on_first=False,
)

if not conforms:
    print(results_text)

---

元データとオントロジーをつなぐMapping

オントロジーを設計しただけでは、既存のDWHやRDBのデータとつながっていません。実際のデータをオントロジーの世界に引き込むためのマッピング定義が必要です。これがR2RMLの役割です。

具体的に、DWHの mart_articles テーブルがあるとして、そのデータをRDFにマッピングする例を示します。

@prefix rr:  <http://www.w3.org/ns/r2rml#> .
@prefix ex:  <https://example.com/ontology/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# mart_articles テーブル → Article クラスへのマッピング
<#ArticleMapping>
  rr:logicalTable [ rr:tableName "mart_articles" ] ;
  rr:subjectMap [
    rr:template "https://example.com/ontology/Article_{article_id}" ;
    rr:class ex:Article
  ] ;
  rr:predicateObjectMap [
    rr:predicate ex:publishedAt ;
    rr:objectMap [
      rr:column "published_at" ;
      rr:datatype xsd:date
    ]
  ] ;
  rr:predicateObjectMap [
    rr:predicate ex:targetsKeyword ;
    rr:objectMap [
      rr:template "https://example.com/ontology/Keyword_{primary_keyword_id}"
    ]
  ] .

このマッピングが意味することを日本語で説明すると、次のようになります。

• mart_articles テーブルの各行を、Article_{article_id} というURIを持つ Article クラスのインスタンスとして扱う
• published_at カラムの値を publishedAt プロパティにマッピングする
• primary_keyword_id カラムの値を使って、対応する Keyword_{id} というURIのリソースに targetsKeyword でリンクする

このマッピング定義を使うことで、DWHの表形式データを自動的にRDF形式のグラフデータに変換できます。Ontop、D2RQ、RMLMapperなどのツールがR2RMLのマッピングを実行してくれます。

---

実装方式の2パターン — MaterializedとVirtual

オントロジーとKnowledge Graphの実装方式には、大きく2つのアプローチがあります。自分の状況に合った方を選ぶことが重要です。

Materialized KG（マテリアライズド） は、実際にRDFを生成してGraph DB（Triple Store）に保存する方式です。Apache Jena Fuseki、GraphDB、Stardog、Amazon Neptuneなどがこのカテゴリのデータベースです。

向いているケース：グラフ探索が多い（「この概念から3ホップ先の概念を探す」等）、推論エンジンを使いたい、SPARQLを本格的に活用したい、Knowledge Graphが一次情報源になる場合です。

一方で、RDFとDWHのデータを同期させる仕組みが必要になり、二重管理のコストが発生します。

Virtual KG（バーチャル） は、元データはRDB/DWHに置いたまま、マッピング定義を使って見かけ上RDF/Graphとして見せる方式です。Ontop、UltraQ、Trifidなどのツールがこのアプローチを実現します。

向いているケース：データを二重管理したくない、まず小さく始めたい、DWHが唯一の正本であり続けたい場合です。SPARQLクエリをリアルタイムでSQLに変換してDWHに問い合わせるため、データの鮮度は常に最新です。

個人事業・小規模チームへの推薦はVirtual KGか、かなり小さなMaterialized KGです。まずはDWHを整え、R2RMLでマッピングを書き、Virtual KGとして動かしてみることをお勧めします。本格的なグラフDBへの移行はニーズが明確になってから検討すれば十分です。

---

オントロジー以外で必要なもの

AI Readyなデータ基盤は、オントロジーだけで完成するわけではありません。オントロジーは「意味のネットワーク」を提供しますが、それ以外にも必要な要素があります。

Semantic Layer はメトリクス定義の統一を担います。「売上の計算式がBIツールとSQLとAIへの問いで違う」という問題を解決します。dbt Semantic Layer、Cube、LookML（Looker）などのツールがこの役割を果たします。AIに「今月の売上は？」と問いかけたとき、Semantic Layerがあれば「売上とはこの計算式で定義されたものである」という文脈をAIに渡せます。

Lineage は数字の流れを追跡可能にします。「なぜこの数字が変わったのか」を調べるとき、raw → staging → martの変換パイプラインをグラフとして辿れることが重要です。OpenLineage、dbt docs、Apache Atlasなどが対応しています。

Provenance は由来が説明できる状態を作ります。「この推定値は手入力なのか、広告管理画面のAPI由来なのか、アルゴリズムで推定したのか」という出自の説明がないと、AIはデータの信頼性を判断できません。PROV-Oという標準オントロジーを使ってProvenanceを記録できます。

Data Quality（データ品質管理） は検査の仕組みです。NULL値の多い列、重複レコード、日付型エラー、更新が止まったテーブルを自動検知できる状態が必要です。Great Expectations、dbt tests、SHACL検証などを組み合わせます。

Access Control（アクセス制御） は誰がどこまで見てよいかの管理です。AIエージェントが「見てはいけないデータ」にアクセスしてしまうリスクを防ぐために、列レベル・行レベルのセキュリティ設計が必要です。

---

検証の5段階

オントロジーとデータ基盤を実装したら、それが正しく機能しているかを検証する必要があります。検証は5つの段階に分けて考えます。

第1段階: 構文検証 はRDF/Turtle/JSON-LDの文法エラーチェックです。Protégéというオントロジー編集ツールや、RDFLibのパーサーを使って構文エラーを検出します。Turtle形式は人間が読みやすい反面、コロンやピリオドの位置ミスが起きやすいので注意が必要です。

第2段階: 論理検証 はReasoner（推論エンジン）を使ったオントロジー定義の矛盾チェックです。「ArticleはLeadでもある」のように、クラス定義が論理的に矛盾していないかを確認します。HermiT、Pellet、FaCT++などの推論エンジンが対応しています。

第3段階: SHACL検証 は実データが期待どおりの形かのチェックです。前述のSHACLルールに基づいて、「必須フィールドが埋まっているか」「型が合っているか」「必要な関係が存在するか」を自動検証します。pySHACLを使えばPythonから実行できます。

第4段階: DWH側の品質検証 は元テーブルの品質チェックです。オントロジー層に問題がなくても、元データが汚ければ意味がありません。invoice_idがユニークか、published_atがNULLだらけでないか、日別件数が急減していないか（処理パイプラインが停止していないか）といったチェックをdbt testsやGreat Expectationsで自動化します。

第5段階: 受け入れ検証 はCompetency Questionに実際に答えられるかの確認です。最初に定義したCQ（例：「どの記事がLeadを生んだか」）を、SPARQLまたはSQLで実際に問い合わせて、期待する答えが返るかを確認します。これがAI Readyであることの最終確認です。

---

OWL 2 Profiles — 用途別の軽量版

OWL 2には、用途に合わせた軽量版（Profile）があります。フルスペックのOWLは非常に強力ですが、それに応じて計算コストも高くなります。規模や用途に合わせてProfileを選ぶことが重要です。

OWL 2 QL（Query Language） は大量データの問い合わせ向きのProfileです。RDB/DWH連携と相性が良く、Virtual KG向きです。SQL書き換えを活用した効率的な問い合わせが可能です。DWHを正本にして、オントロジーをVirtual KGとして使う場合に最適です。

OWL 2 RL（Rule Language） はルールベース推論向きのProfileです。比較的軽い推論を回しやすく、ルールエンジンで効率よく処理できます。「Leadが転換したEngagementは、そのLeadを生んだArticleと間接的につながる」といった推論を表現できます。Knowledge Graphを主役にして軽い推論を使うなら、RLが適しています。

OWL 2 EL（Existential Language） は大規模な階層分類向きのProfileです。医療分類（SNOMED CT）や大規模な生物分類体系などで使われます。個人事業レベルで使う機会は少ないでしょう。

選択の目安: DWHを正本にしてVirtual KGから始めるならOWL 2 QL。Graphを主役にして軽い推論を使いたいならOWL 2 RL。

---

個人事業向け最小構成と答えられる問い

最後に、個人事業・小規模チームが実際に始められる最小構成をまとめます。理論は理論として、「何から手を付けるか」を具体的に示します。

最小クラス構成:

• Article — 公開したコンテンツ記事
• Keyword — 記事が狙うSEOキーワード
• Lead — 問い合わせや資料DLをした見込み客
• Client — 契約済み顧客
• Engagement — 案件・プロジェクト
• Invoice — 請求書

最小関係構成:

• Article targets Keyword — 記事とキーワードの紐付け
• Article generated Lead — 記事と問い合わせの紐付け
• Lead convertedTo Engagement — 見込み客と案件の転換記録
• Engagement billedBy Invoice — 案件と請求書の紐付け

この構成で答えられる問い（Competency Questionの実現）:

• 直近3ヶ月で、どのキーワード群が受注額に貢献したか
• どのコンテンツが問い合わせで終わらず、契約まで至ったか
• どの記事が流入だけでなく商談化・受注に効いたか
• 月別の流入キーワード → 問い合わせ → 受注の変換率はどう変わっているか

この最小構成は、スプレッドシートやNotionのGlossaryから始め、DWHがBigQueryやDuckDBであれば既存のテーブルをR2RMLでマッピングするだけで構築できます。

重要なのは、オントロジーは「きれいな理論」のためではなく、「売上に近い問いをAIに正しく解かせる」ために使うという目的意識です。Competency Questionが明確で、それに答えるデータとマッピングが整っていれば、小さなオントロジーでも十分に機能します。

---

関連ツール一覧

AI Readyなデータ基盤を構築するためのエコシステムを整理します。すべてを使う必要はなく、フェーズに応じて必要なものを選択してください。

DWH・変換・モデリング

• dbt — SQLベースでデータ変換を管理するツール。Semantic Layerも持てる。個人事業から大企業まで幅広く採用されており、まずここから始めるのが現実的
• Apache Iceberg — Lakehouse向けのオープンなテーブル形式。スナップショットやスキーマ変更に強く、BigQueryやSnowflakeとも統合できる

データリネージとカタログ

• OpenLineage — データ処理の流れを記録するための標準フォーマット。ツール間でLineageを共有できる
• DCAT（Data Catalog Vocabulary） — Data Catalogのメタデータを表現するためのW3C標準語彙

オントロジー設計・編集

• Protégé — オントロジー編集ツール（Stanford大学製。無料）。GUIでクラスや関係を定義でき、OWL/Turtle形式でエクスポートできる。まずここでオントロジーを設計することをお勧めする
• PROV-O — Provenance（来歴）を表現するためのW3C標準オントロジー
• SKOS — TaxonomyやGlossaryを整理するための標準語彙
• Schema.org — WebページのStructured Dataでよく使う語彙。SEO文脈でも登場し、GoogleのリッチスニペットにJSON-LDで使われる

RDF処理・SPARQLエンドポイント

• RDFLib — PythonでRDFを扱うライブラリ。Turtle形式のパース、SPARQL実行、マッピングなどができる
• pySHACL — PythonでSHACL検証を実行するツール。RDFLibと組み合わせて使う
• Apache Jena Fuseki — SPARQLを実行できるオープンソースサーバ。ローカルでKnowledge Graphを動かす際に使いやすい

データ品質

• Great Expectations — データ品質テストのためのツール。「この列は100以上のはず」「この列にNULLはないはず」といったルールを定義して自動検証できる

Virtual KG・マッピング

• Ontop — RDB/DWHをVirtual KGとして見せるツール。R2RMLやOBDA（Ontology-Based Data Access）マッピングをサポート
• R2RML — RDBをRDFにどう対応づけるかを定義するW3C標準

---

まとめ

AI Readyなデータ基盤を作るということは、データに「意味のネットワーク」を加えることです。DWHにデータを入れるだけでは不十分で、「このデータが何を意味し、他のデータとどうつながり、どこから来て、どこまで信頼できるか」という情報が機械可読な形で整備されて初めて、AIはデータを「理解して」使えるようになります。

本記事で解説した内容を振り返ります。

• AI Readyの定義: データの存在だけでなく、意味・関係・由来・品質がすべて機械可読な状態
• 5層構造: Canonical Data → Metadata/Catalog/Lineage → Business Semantics → Ontology/KG → Serving
• Glossary → Taxonomy → Ontology → KG という段階的な意味の構造化
• OWLで意味を設計し、SHACLでデータを検証するという役割分担
• Competency Questionを先に定義することで、実用的なオントロジーを設計する
• Materialized KG vs Virtual KG: 小規模チームはVirtual KGかシンプルなMaterialized KGから始める

すべてを一度に揃える必要はありません。最初は用語集（Glossary）を作ることから始め、Competency Questionを定義し、最小限のオントロジーをProtégéで設計する。この小さな一歩が、AIとデータが正しく対話できる基盤への第一歩です。

データの「意味のネットワーク」が整うほど、AIへの問いかけの精度が上がり、出てくる答えの信頼性が高まります。それがAI Readyという状態の本質です。個人事業・小規模チームであっても、正しい順番で取り組めば必ず実現できます。ぜひ自分のビジネスのCompetency Questionを書き出すところから始めてみてください。

関連記事

• e-Stat × DuckDB × BigQuery × dbt で作る政府統計データ基盤 — 政府統計 API を DuckDB で探索し、BigQuery + dbt で本番データ基盤に仕上げる実装例
• e-Stat API Python クライアントの設計と実装 — 外部データソースを型安全に取り込む Python クライアントの設計パターン