統合オントロジーとは？YAML実装例と運用手順

統合オントロジーとは

AIに「先月の純売上を出して」と頼む場面を考えます。AIがテーブル名を知っていても、純売上に返品を含めるのか、テスト注文を除くのか、どの日付を基準にするのかが分からなければ、正しいSQLは作れません。人には常識でも、AIには書かれていない前提です。

統合オントロジーとは、顧客・注文・商品などの業務概念と、その定義、関係、指標、業務ルール、物理テーブルへの対応を、機械が読める一つの論理モデルとして管理する設計です。たとえば「顧客」という言葉に、次の情報をまとめて結びます。

人が使う名前、説明、同義語
顧客と注文の関係と多重度
参照するテーブル、主キー、カラム
純売上などの指標と除外条件
責任者、品質チェック、正解例

重要なのは、すべてを巨大な一ファイルへ詰め込むことではありません。複数のYAMLへ分割しても構いません。業務定義とデータ実装を同じ論理モデル、同じレビュー、同じテストで追跡できることが要点です。

似た仕組みとの違い

「用語集」「セマンティックレイヤー」「知識グラフ」と何が違うのかを先に切り分けます。実際には組み合わせて使うもので、どれか一つが他を完全に置き換えるわけではありません。

仕組み	中心となる情報	主な用途	統合オントロジーとの関係
データカタログ・用語集	説明、Owner、分類、検索用メタデータ	データを探し、意味を確認する	説明やOwnerを取り込めるが、結合や指標の実行規則までは別途必要
セマンティックレイヤー	指標、ディメンション、エンティティ、結合	BIやAIで同じ集計結果を再利用する	重要な構成要素。統合オントロジーでは業務ルールや物理対応も同じ変更単位に含める
知識グラフ	エンティティと関係のインスタンス	関係をたどり、横断的に問い合わせる	オントロジーをスキーマとしてグラフを構築できるが、グラフDBは必須ではない
GraphRAG	文書から抽出した概念、関係、要約、根拠	複数文書にまたがる検索と回答生成	文書検索の方式。売上定義やSQLの正式な契約を置く仕組みとは目的が異なる

オントロジーという言葉自体には、W3CのOWL 2のような形式的な表現方法もあります。本記事のYAMLはOWL 2の代替規格ではなく、AI分析を小さく始めるための実務用スキーマです。

最小構成のYAML

EC事業で「先月の純売上」を一貫して答えるための最小例です。YAMLとして省略なく構文解析できる形にし、業務概念、物理データ、関係、指標、ルール、品質、正解例を一つずつ入れています。

version: "1.0"
ontology:
  id: commerce_analytics
  name: EC分析
  owner: data-platform-team
  status: active
  timezone: Asia/Tokyo
  reviewed_at: "2026-08-08"

entities:
  - id: customer
    label: 顧客
    description: 一意のcustomer_idで識別される購入主体
    synonyms:
      - 購入者
      - customer
    source:
      table: analytics.dim_customers
      primary_key: customer_id
    properties:
      - id: customer_id
        column: customer_id
        type: string
        required: true
      - id: last_order_at
        column: last_order_at
        type: timestamp
        required: false

  - id: order
    label: 注文
    description: 決済状態を持つ一回の注文
    synonyms:
      - 受注
      - purchase
    source:
      table: analytics.fct_orders
      primary_key: order_id
    properties:
      - id: order_id
        column: order_id
        type: string
        required: true
      - id: customer_id
        column: customer_id
        type: string
        required: true
      - id: net_amount
        column: net_amount
        type: numeric
        required: true
        unit: JPY
        description: 注文額から確定済みの返品額を控除した金額
      - id: ordered_at
        column: ordered_at
        type: timestamp
        required: true
      - id: status
        column: status
        type: string
        required: true
        allowed_values:
          - completed
          - cancelled
          - refunded
      - id: is_test
        column: is_test
        type: boolean
        required: true

relationships:
  - id: customer_places_orders
    from: customer
    to: order
    cardinality: one_to_many
    join:
      from_property: customer_id
      to_property: customer_id

metrics:
  - id: net_revenue
    label: 純売上
    description: 完了済みの本番注文に含まれる返品控除後売上。cancelledとrefundedは集計対象外
    entity: order
    aggregation:
      type: sum
      property: net_amount
    filters:
      - property: status
        operator: equals
        value: completed
      - property: is_test
        operator: equals
        value: false
    time_property: ordered_at
    owner: finance-team

business_rules:
  - id: active_customer
    label: アクティブ顧客
    description: 直近90日以内に注文した顧客
    entity: customer
    condition:
      property: last_order_at
      operator: within_days
      value: 90

quality_checks:
  - id: order_id_unique
    entity: order
    property: order_id
    assertion: unique_and_not_null
    severity: error
  - id: net_amount_non_negative
    entity: order
    property: net_amount
    assertion: greater_than_or_equal
    value: 0
    severity: error

examples:
  - question: 先月の純売上は？
    expected:
      metric: net_revenue
      time_range: previous_calendar_month

このファイルだけでSQLが自動実行されるわけではありません。実際には、YAMLを読むパーサー、DWHのスキーマを確認する検証処理、指標定義をSQLへ変換するアダプター、実行権限の制御が必要です。YAMLはそれらが参照する契約です。

各フィールドの読み方

フィールド	役割	レビューする人
`ontology`	モデル全体の識別子、Owner、状態、日付境界に使うタイムゾーン、確認日を持つ	データ基盤責任者
`entities`	顧客や注文の定義と、テーブル・主キー・プロパティを結ぶ	業務担当者とデータ担当者
`relationships`	エンティティ間の向き、多重度、結合キーを宣言する	データモデラー
`metrics`	指標の集計方法、除外条件、時間軸、Ownerを固定する	指標Ownerと分析担当者
`business_rules`	「アクティブ顧客」など、会話では共有済みに見える条件を明示する	業務Owner
`quality_checks`	AIが使う前に満たすべき最低限の品質条件を持つ	データ基盤運用者
`examples`	自然言語の質問を、期待する指標と条件へ対応付ける	利用部門とAI評価担当者

ネストした項目は、次のように読みます。

エンティティ：source.tableとsource.primary_keyが物理テーブルを示し、properties内のidを業務上の名前、columnを実カラム名として対応付けます。type、required、allowed_valuesはAIが使う前の制約です。
関係：fromとtoはエンティティIDを参照し、cardinalityが一対多などの多重度、joinが双方の結合プロパティを表します。
指標：aggregationが集計方法、filtersが除外・対象条件、time_propertyが期間絞り込みに使う日時です。「先月」の境界はontology.timezoneで解釈します。式だけでなく時間軸とOwnerまで一緒に決めます。
ルールと品質：conditionは業務語彙を判定可能な条件へ変換し、assertionとseverityは違反時に処理を止めるか判断する材料になります。

labelやdescriptionだけを業務担当者が決め、tableやcolumnだけをデータ担当者が決めると、また二つの定義が分かれます。一つのPull Requestで両者が同じ差分を見る状態を作ることが、この形式を採る実務上の利点です。

何を検証すれば実務で使えるか

YAMLを保存できたことと、正しい分析に使えることは別です。最低でも次の五段階をCIまたは定期ジョブで確認します。

構文：YAMLとして読み込めるか、必須フィールドと型が自社JSON Schemaに合うか
参照整合性：from、to、entityが、存在するIDを指しているか
物理整合性：宣言したテーブル、カラム、主キー、型がDWHの実体と一致するか
実行安全性：生成SQLをdry runし、読み取り専用、スキャン上限、行・列権限を守れるか
回答品質：examplesの質問に対して、期待した指標、期間、フィルター、数値が得られるか

特に大切なのは最後の確認です。構文が正しくても、「先月」が暦月ではなく直近30日として解釈されれば、業務回答は間違います。期待するSQLまたは集計結果をテストケースとして保存し、LLMやスキーマを変えた後も回帰テストします。

変更管理は「誰が、何を、どう確かめたか」まで残す

指標や業務ルールは必ず変わります。変化を止めるのではなく、変更の影響を追跡できる運用にします。おすすめの流れは次の通りです。

変更理由と影響する質問・ダッシュボード・AI機能をPull Requestへ書く
業務Ownerが定義を、データOwnerが物理対応と品質条件を承認する
構文、参照、DWHスキーマ、dry run、正解例のテストを自動実行する
ID削除や意味変更は破壊的変更として扱い、旧定義に廃止予定日を付ける
公開後は回答失敗ログを確認し、同義語・ルール・正解例へ戻す

「純売上」の計算式だけを直す場合でも、その定義を使うダッシュボードやAI回答へ影響します。IDを使い回して意味を黙って変えず、変更履歴と適用日を残してください。また、YAMLへ認証情報や顧客の実データを保存してはいけません。置くのは定義と参照先だけです。

向く会社・向かない会社

向く状況	まだ向かない状況
同じKPIが部署やツールごとに違う	利用者が一人で、指標も数個しかない
BIとAIの両方から同じ定義を使いたい	元データの粒度・主キー・品質がまだ定まっていない
複数テーブルの関係と業務ルールが重要	規程文書の検索だけが目的で、数値計算をしない
変更時に影響範囲と承認者を追跡したい	定義を保守するOwnerもテスト運用者も置けない

統合オントロジーを作っても、欠損データ、誤った主キー、過剰な権限、危険なSQL、LLMの誤推論は自動では解決しません。品質テスト、アクセス制御、実行ガードレール、評価を別の責務として組み合わせます。

参考にした一次資料

上記YAMLはDecisionFlow独自の例ですが、エンティティ、プロパティ、関係、物理データへのバインドという考え方は、次の公式資料を参照して整理しました。

Palantir Foundry — Ontology overview：Object、Property、Linkとデータ・業務フローの接続を参照（アクセス日: 2026-08-08）
Microsoft Fabric IQ — What is ontology (preview)?：Entity Type、Property、Relationship、Data Bindingの定義を参照。記事執筆時点ではpreview（アクセス日: 2026-08-08）
Snowflake — The Agent Context Layer for Trustworthy Data Agents：AIエージェント向けコンテキストに、意味層だけでなくオントロジーや運用知識が必要という整理を参照（アクセス日: 2026-08-08）
W3C — OWL 2 Web Ontology Language Primer：Class、Property、Individualなど、形式オントロジーの基本概念との境界確認に参照（アクセス日: 2026-08-08）

まとめ

統合オントロジーは、難しい知識グラフから始めるものではありません。まず一つの重要な業務質問を選び、関係するエンティティ、物理テーブル、指標、除外条件、Owner、正解例を同じ変更単位へ置くところから始めます。

最初の完成条件は「YAMLを書いた」ではなく、業務担当者とデータ担当者が同じ定義を承認し、その定義から作った回答をテストで再現できることです。一つの指標で運用できてから、隣接するエンティティと質問へ広げてください。

統合オントロジーとは？AI分析向けYAML設計・検証・変更管理【実装例】