Microsoft FabricのOntology（プレビュー）は、単に「データの関係図を作る機能」ではありません。Customer、Order、Product、Sensorのような業務概念を、エンティティ型・プロパティ・リレーションシップとして定義し、OneLake上の実データと結び付けることで、Power BI、AIエージェント、Graph、Real-Time Intelligenceなどが同じ業務用語でデータを扱えるようにする仕組みです。(Microsoft Learn)
結論から言うと、Microsoft FabricでOntology（プレビュー）を使う場合、管理者はテナント設定とGraphの有効化、開発者・データ担当者はデータバインディング、キー設計、更新運用、Power BI semantic modelからの生成可否を必ず確認する必要があります。プレビュー機能のため、いきなり本番の中核に組み込むのではなく、対象ドメインを絞って検証し、権限・容量・データ型・更新手順を固めてから展開するのが安全です。
Microsoft FabricのOntology（プレビュー）で何が変わるのか
Microsoft FabricのOntology（プレビュー）が変えるのは、データの「保存場所」よりも、データの「意味の扱い方」です。
従来のデータ活用では、同じ「顧客」「注文」「設備」「在庫」という言葉でも、部門ごとに定義が違うことがよくあります。営業では「顧客」は商談先、経理では請求先、サポートでは契約中の利用者を指す、といったズレです。この状態でAIエージェントやBIレポートを使うと、回答や集計結果が部門ごとに食い違いやすくなります。
Ontology（プレビュー）は、こうした業務概念をFabric IQの中で共通のビジネス語彙として定義し、OneLakeのデータソースとバインドします。Microsoftの公式説明では、OntologyはFabric IQ（プレビュー）ワークロードの一部であり、ドメインやOneLakeソースをまたいで意味を統一するエンタープライズ語彙・セマンティックレイヤーとして位置付けられています。(Microsoft Learn)
実務上の変化は、次のように整理できます。
| 変化する点 | これまで起きやすかった課題 | Ontology（プレビュー）で期待できること |
|---|---|---|
| 業務用語の定義 | 「顧客」「注文」などの意味が部門ごとに違う | エンティティ型として共通定義を持てる |
| データソースとの接続 | テーブルや列名を知らないと分析しづらい | 業務概念からデータをたどれる |
| AIエージェントの回答 | データ構造に依存し、文脈を誤解しやすい | 定義済みの業務語彙を前提に推論できる |
| グラフ分析 | 結合ロジックが個別実装になりやすい | リレーションシップを明示して探索できる |
| ガバナンス | 定義・制約・由来が分散しやすい | 意味、制約、来歴を概念レイヤーで管理しやすい |
重要なのは、Ontologyが「AI向けの飾り」ではなく、BI、データ分析、AIエージェント、業務アクションを同じ意味体系でつなぐ基盤として設計されている点です。
Ontology（プレビュー）の中心はエンティティ型・プロパティ・リレーションシップ
Ontology（プレビュー）を理解するには、まず構成要素を押さえる必要があります。公式ドキュメントでは、Ontologyはエンティティ型、エンティティインスタンス、プロパティ、リレーションシップで構成されると説明されています。(Microsoft Learn)
エンティティ型は業務概念の共通モデル
エンティティ型は、Customer、Order、Shipment、Product、Sensorのような業務上の概念を表す再利用可能な論理モデルです。
たとえば小売業であれば、次のようなエンティティ型が考えられます。
| エンティティ型 | 具体例 | 使いどころ |
|---|---|---|
| Store | 店舗 | 店舗別売上、在庫、設備監視 |
| Product | 商品 | 商品別分析、需要予測 |
| Customer | 顧客 | 購買履歴、問い合わせ履歴 |
| Freezer | 冷凍設備 | 温度監視、異常検知 |
| Order | 注文 | 受注、配送、キャンセル分析 |
ポイントは、単なるテーブル名ではなく、組織内で合意した「業務上の概念」として定義することです。テーブルごとに「customer_id」「client_id」「account_no」のような列名が違っていても、Ontology側では「Customer」という概念に整理できます。
プロパティはエンティティの属性
プロパティは、エンティティが持つ属性です。Customerなら氏名、メールアドレス、顧客ID、会員ランクなどが該当します。Sensorなら設置場所、型番、温度、湿度などが考えられます。
ここで注意したいのは、プロパティ名を安易に元の列名のまま採用しないことです。たとえば、複数のテーブルに「ID」という列がある場合、何のIDなのか分かりにくくなります。業務部門にも伝わる名前にするなら、「CustomerId」「StoreId」「SensorId」のように、意味が明確な名称を選ぶべきです。
リレーションシップは概念同士のつながり
リレーションシップは、エンティティ型またはエンティティインスタンス同士の方向付きの関係です。公式説明では、Customer places Orderのような例が挙げられています。(Microsoft Learn)
実務では、次のような関係を定義できます。
| リレーションシップ | 意味 |
|---|---|
| Customer places Order | 顧客が注文する |
| Store stocks Product | 店舗が商品を在庫する |
| Freezer locatedIn Store | 冷凍設備が店舗に設置されている |
| Sensor monitors Freezer | センサーが冷凍設備を監視する |
| Order contains Product | 注文に商品が含まれる |
この関係が明示されると、「冷凍設備の異常が、どの商品、どの店舗、どの顧客注文に影響するか」といった多段階の分析がしやすくなります。単純な集計ではなく、業務プロセスをまたいだ推論に向いているのがOntologyの特徴です。
影響範囲は管理者・開発者・BI担当・業務部門にまたがる
Ontology（プレビュー）は、Microsoft Fabric上の単独アイテムとして完結するものではありません。Fabric IQは、Ontology、Plan、Graph、Data agent、Operations agent、Power BI semantic modelsなど複数の要素を含むワークロードとして説明されており、Ontologyはそれらに共通の業務文脈を提供する役割を持ちます。(Microsoft Learn)
そのため、影響範囲はデータエンジニアだけに閉じません。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| Fabric管理者 | テナント設定、容量、権限管理 | Ontology item、Graph、Data agent、Operations agent関連設定 |
| データエンジニア | OneLake、Lakehouse、Eventhouseとの接続 | 管理テーブル、データ型、キー、列名、更新手順 |
| BI・Power BI担当 | semantic modelとの整合性 | 既存モデルから生成するか、用語をどう合わせるか |
| 開発者 | AIエージェントやアプリ連携 | NL2Ontology、Graph、GQL/KQL、アクセス制御 |
| 業務部門・データオーナー | 用語定義とルールの合意 | 「顧客」「注文」「設備」などの定義責任者 |
特に見落としやすいのが、業務部門の関与です。Ontologyは技術的にはFabric上で作成できますが、業務用語の定義が曖昧なまま作ると、AIや分析の結果も曖昧になります。最初に「誰がその用語の定義に責任を持つのか」を決めることが、展開成功の前提です。
管理者が最初に確認すべきテナント設定
Ontology（プレビュー）を使うには、Fabric管理者によるテナント設定が必要です。公式ドキュメントでは、Ontology item（preview）を作成するには「Enable Ontology item (preview)」が必要であり、Ontologyに関連付くGraphを使うには「User can create Graph (preview)」の設定が必要とされています。(Microsoft Learn)
管理者が確認すべき設定は、少なくとも次の4つです。
| 確認項目 | 必要になる場面 | 未設定の場合の影響 |
|---|---|---|
| Enable Ontology item (preview) | Ontologyアイテムを作成する | Ontology作成時にエラーになる可能性 |
| User can create Graph (preview) | Ontologyに関連するGraphを使う | 新規Ontologyへのアクセス時にエラーになる可能性 |
| Data agent関連のテナント設定 | Fabric Data Agentと連携する | Data Agent作成や連携でエラーになる可能性 |
| Operations agent関連の設定 | Operations agentと連携する | Operations agent作成や利用でエラーになる可能性 |
ここでの実務ポイントは、Ontologyだけを有効にして終わらせないことです。Ontologyのグラフ表示や関係探索はGraphに依存します。AIエージェントと組み合わせる場合は、Data agentやOperations agent側の設定も必要になります。
また、設定を有効化する範囲も慎重に決めるべきです。プレビュー段階では、全社一斉に開放するよりも、検証用ワークスペースや特定のセキュリティグループに絞って開始する方が管理しやすくなります。
データバインディングで確認すべき実務上の注意点
Ontology（プレビュー）の価値は、業務概念を実データと結び付けて初めて発揮されます。この接続がデータバインディングです。
公式ドキュメントでは、データバインディングはエンティティ型、リレーションシップ型、プロパティのスキーマを具体的なデータソースに接続するものと説明されています。対象には、OneLakeの静的データ、Eventhouseなどの時系列データが含まれます。(Microsoft Learn)
静的データを先にバインドする
時系列データを扱う場合でも、最初に静的データのバインディングを完了する必要があります。たとえば、冷凍設備の温度データを扱うなら、まずFreezerというエンティティ型に対して、FreezerId、設置店舗、機種、稼働開始日などの静的属性を結び付けます。
その後、温度や湿度のような時系列データをバインドします。時系列データ側にもFreezerIdなどのキーが必要で、静的データ側のキーと正確に対応している必要があります。
キー設計を後回しにしない
エンティティ型キーは、データの各レコードを一意に識別するための重要な要素です。公式ドキュメントでは、キーとして使える列は文字列または整数列と説明されています。(Microsoft Learn)
実務では、次のような失敗が起きやすくなります。
| 失敗しやすいケース | 起きる問題 | 対策 |
|---|---|---|
| 顧客IDがシステムごとに違う | Customerが重複または分裂する | マスター統合ルールを先に決める |
| 複合キーが未整理 | 注文明細などを一意に識別できない | OrderId + LineNoなどのキー設計を確認する |
| 数値型と文字列型が混在 | バインドや生成で不整合が出る | ETLで型を統一する |
| 表示名だけをキーのように使う | 同姓同名や名称変更で破綻する | 不変のIDをキーにする |
Ontologyの設計では、見た目の分かりやすさよりも、同一性を正しく扱えるかが重要です。AIエージェントに使わせる場合も、キーが曖昧だと回答の根拠が不安定になります。
LakehouseとDeltaテーブルの制約に注意する
データバインディングには制約があります。公式ドキュメントでは、OneLake securityが有効なLakehouseはデータバインディングのデータソースとして使えないこと、OntologyがサポートするのはLakehouseと同じOneLakeディレクトリにある管理テーブルであり外部テーブルではないこと、列マッピングが有効なDeltaテーブルはOntology Graphでサポートされないことが説明されています。(Microsoft Learn)
展開前に、次の項目を確認してください。
| 確認項目 | 実務での見方 |
|---|---|
| OneLake security | 有効なLakehouseをバインド対象にしていないか |
| テーブル種別 | 外部テーブルではなく管理テーブルか |
| 列マッピング | 特殊文字やスペースを含む列名で自動的に有効化されていないか |
| テーブル名変更 | マッピング作成後に名前変更する予定がないか |
| 静的バインディング | 1つのエンティティ型に複数の静的ソースを混ぜようとしていないか |
| データ型 | サポート外の型をETLで変換しているか |
特に列名にスペース、改行、カンマ、セミコロン、括弧などが含まれる場合は注意が必要です。分析基盤では問題なく使えても、GraphやOntology側では制約に引っかかることがあります。
上流データの更新は自動反映と考えない
Ontology（プレビュー）では、上流データに新しい行が追加されても、Ontologyアイテムで見えるようにするには手動更新が必要とされています。(Microsoft Learn)
これは運用設計上、かなり重要です。
たとえば、店舗の温度センサー監視にOntologyを使う場合、EventhouseやLakehouse側に新しいデータが届いていても、Ontology側のグラフやクエリ結果がすぐ最新になるとは限りません。業務判断やエージェントの回答に使うなら、「いつのデータまで反映済みか」を明確にする必要があります。
運用では、次のようなルールを決めておくと安全です。
| 運用項目 | 決めるべき内容 |
|---|---|
| 更新頻度 | 日次、時間単位、検証時のみなど |
| 更新担当 | 管理者、データエンジニア、運用担当の誰が行うか |
| 更新失敗時の対応 | 再実行、通知、利用停止判断 |
| エージェント利用時の表示 | 回答が参照するデータ更新時刻を明示するか |
| 容量監視 | Graph更新がFabric容量に与える影響を確認するか |
トラブルシューティング情報では、Ontologyの基盤となるGraphの更新が容量使用に影響し、容量上限に達するとキャンバスやエンティティ型一覧が読み込めない場合があると説明されています。Graph更新スケジュールを設定する場合は、Fabric Capacity Metrics appなどで負荷を監視する運用が必要です。(Microsoft Learn)
Power BI semantic modelから生成する場合の移行ポイント
既存のPower BI semantic modelを使っている組織では、Ontology（プレビュー）をゼロから作るのではなく、semantic modelから生成する選択肢があります。
公式ドキュメントによると、semantic modelからOntologyを生成すると、新しいOntologyアイテム、semantic modelのテーブルに対応するエンティティ型、列に基づく静的プロパティとデータバインディング、semantic modelのリレーションシップに基づくリレーションシップ型が作成されます。(Microsoft Learn)
ただし、自動生成だけで完成と考えるのは危険です。生成後に、次の作業が必要です。
| 生成後に確認すること | 理由 |
|---|---|
| エンティティ型名 | テーブル名のままだと業務用語として分かりにくい場合がある |
| プロパティ名 | 列名由来の略称や技術名が残る可能性がある |
| キー | 複合キーや不足キーを手動確認する必要がある |
| リレーションシップ | 意味のある業務関係として表現できているか確認する |
| 時系列データ | 自動生成されないため、別途バインドが必要 |
| データ型 | Decimalなど一部の型で制約に注意する必要がある |
semantic modelからの生成にはワークスペースやデータ要件の制約もあります。たとえば、既定の「My workspace」からは生成できないと説明されています。また、semantic modelが公開されていない、テーブルが非表示、リレーションシップが未定義といった状態では、エンティティ型が生成されない、または不足する可能性があります。(Microsoft Learn)
移行時のおすすめは、既存のsemantic modelをそのままOntology化するのではなく、まず代表的な1つのドメインで検証することです。たとえば「顧客」「注文」「商品」だけに絞り、業務部門と名称・キー・関係を確認してから範囲を広げると、後戻りが少なくなります。
Graphとクエリでできること、できないこと
Ontology（プレビュー）のグラフ機能は、Graph in Microsoft Fabricに依存します。公式説明では、Ontology graphはデータバインディングとリレーションシップ定義から作られるクエリ可能なインスタンスグラフであり、ノードはエンティティインスタンス、エッジはメタデータを持つリンクとして扱われます。(Microsoft Learn)
Graphを使うと、次のような分析がしやすくなります。
| シナリオ | 具体例 |
|---|---|
| 影響範囲分析 | 異常が発生した設備から、影響する店舗・商品・注文をたどる |
| 依存関係分析 | サプライヤー変更が、どの商品や契約に影響するか調べる |
| 経路探索 | 出荷、配送、倉庫、顧客までの流れをたどる |
| コミュニティ分析 | 関連の強い顧客群や商品群を見つける |
| AI回答の文脈補強 | 質問に対して関連する概念を横断して回答する |
ただし、Graph側にもプレビュー段階の制約があります。MicrosoftのGraph制限ページでは、Graphはパブリックプレビューであり、SLAなしで提供され、本番ワークロードには推奨されないと説明されています。また、Graph作成時のデータソースやデータ型、Graphインスタンス数、サイズなどにも制限があります。(Microsoft Learn)
本番展開を検討する場合は、少なくとも次の点を確認してください。
| 確認項目 | なぜ重要か |
|---|---|
| Graphの利用可否 | リージョンやテナント設定に依存する可能性がある |
| ワークスペース単位の権限 | Graphへのアクセスはワークスペース権限と関係する |
| データ規模 | 大量ノード・エッジでは性能検証が必要 |
| 更新頻度 | 更新が容量使用量に影響する |
| スキーマ変更 | 構造変更時の再作成や再取り込みが必要になる場合がある |
プレビュー段階では、「PoCでは動いたから本番でも問題ない」と判断しないことが大切です。データ量、更新頻度、権限、利用者数を実運用に近い条件で試すべきです。
AIエージェント連携で注意すべきこと
Ontology（プレビュー）は、AIエージェントの回答品質を高めるための業務文脈としても重要です。Fabric IQの公式説明では、OntologyはFabric agentsやReal-Time Intelligenceコンポーネントで利用できる共有コンテキストレイヤーを提供し、AI agent groundingやクロスドメイン推論に適しているとされています。(Microsoft Learn)
また、Fabric IQではData agentがOntologyをソースとして利用でき、業務概念を理解した回答につなげられると説明されています。Operations agentも、リアルタイムデータを監視し、ビジネスアクションを推奨する用途でFabric IQの構成要素として位置付けられています。(Microsoft Learn)
ただし、AIエージェントに接続する前に、次の準備が必要です。
| 確認項目 | 不十分な場合に起きること |
|---|---|
| エンティティ名が分かりやすい | AIが曖昧な回答を返しやすい |
| リレーションシップが業務上自然 | 誤った関係を前提に推論する可能性がある |
| プロパティの説明がある | ユーザー質問との対応が弱くなる |
| キーとデータバインディングが正しい | 間違ったデータを参照する可能性がある |
| 権限が適切 | 見えてはいけないデータにアクセスするリスクがある |
| 更新時刻が分かる | 古いデータを最新情報として扱う可能性がある |
特に、Ontologyの名前設計はAI利用で重要です。たとえば「Tbl_Cust_Mst」よりも「Customer」、「Prod」よりも「Product」の方が、業務ユーザーにもAIにも意味が伝わりやすくなります。略語を残す場合は、説明文を補うか、業務部門が使う正式名称に寄せるべきです。
展開前に確認したいチェックリスト
Ontology（プレビュー）を導入する前に、以下を確認しておくと失敗を減らせます。
| チェック項目 | 確認内容 |
|---|---|
| 対象ドメイン | 最初に扱う業務領域を1つに絞っているか |
| 用語定義 | Customer、Order、Productなどの定義責任者がいるか |
| テナント設定 | Ontology itemとGraphが有効化されているか |
| ワークスペース | My workspaceではなく検証用または共有ワークスペースを使うか |
| 権限 | 作成者、閲覧者、データソースアクセス権を整理しているか |
| データソース | OneLake、Lakehouse、Eventhouse、semantic modelの制約を確認したか |
| キー | エンティティを一意に識別できるキーを決めたか |
| データ型 | サポートされる型に変換済みか |
| 列名 | 特殊文字やスペースが原因で列マッピング問題を起こさないか |
| 更新運用 | 手動更新、更新頻度、失敗時対応を決めたか |
| 容量 | Graph更新やクエリがFabric容量に与える影響を監視するか |
| AI連携 | エージェントに接続する前にOntologyの品質を確認したか |
| プレビューリスク | SLAや制約を踏まえて本番適用範囲を限定しているか |
このチェックリストで未確認の項目が多い場合は、いきなりAIエージェント連携まで進めず、まずOntology単体で作成・バインド・Graph表示・クエリ確認を行うのが現実的です。
導入を進めるためのおすすめ手順
Microsoft FabricのOntology（プレビュー）を試す場合は、次の順番で進めるとスムーズです。
小さな業務領域を選ぶ
最初から全社の業務概念を定義しようとすると、関係者調整だけで止まりやすくなります。まずは「店舗と設備」「顧客と注文」「商品と在庫」など、3〜5個程度のエンティティ型で表現できる領域を選びます。
既存のsemantic modelを棚卸しする
Power BI semantic modelがすでに整備されている場合は、Ontology生成の候補になります。ただし、モデルがそのまま業務用語として適切とは限りません。テーブル名、列名、リレーションシップ、非表示テーブル、キー定義を確認します。
管理者にテナント設定を依頼する
Ontology item、Graph、必要に応じてData agentやOperations agentの設定を確認します。設定対象は、検証用のユーザーグループやワークスペースに限定すると管理しやすくなります。
エンティティ型とキーを先に決める
データを接続する前に、エンティティ型、プロパティ、キー、リレーションシップの草案を作ります。ここで業務部門に確認を取り、言葉の意味をそろえます。
静的データをバインドしてから時系列データを追加する
静的データのバインディング、キー設定、表示名の確認を行い、その後に時系列データを追加します。時系列データでは、キーが静的データと正確に一致しているかを必ず確認します。
Graph表示とクエリを確認する
Ontologyのプレビュー体験やGraph表示で、エンティティとリレーションシップが期待どおりに見えるかを確認します。関係が抜けている、ノードが少なすぎる、データが表示されない場合は、キー、データバインディング、権限、列マッピングを見直します。
AIエージェント連携は最後に行う
Data agentやOperations agentと連携するのは、Ontologyの定義とデータバインディングが安定してからにします。AIエージェントは便利ですが、曖昧なOntologyをつなぐと、もっともらしいが根拠の弱い回答を生むリスクがあります。
まとめ：Ontology（プレビュー）はAI活用前の「意味合わせ」から始める
Microsoft FabricのOntology（プレビュー）は、OneLake上のデータを業務概念として整理し、Graph、Power BI semantic model、Data agent、Operations agentなどに共通の文脈を与えるための機能です。単なるデータカタログではなく、エンティティ型、プロパティ、リレーションシップ、データバインディングを通じて、組織内の言葉とデータを接続する仕組みと考えると理解しやすくなります。
管理者は、Ontology item、Graph、AIエージェント関連のテナント設定と権限を確認する必要があります。開発者やデータエンジニアは、OneLakeやLakehouseの制約、キー設計、データ型、列マッピング、手動更新、容量使用量を確認すべきです。Power BI担当者は、semantic modelから自動生成できる部分と、手動で見直すべき部分を切り分ける必要があります。
次に取るべき行動は明確です。まず小さな業務領域を1つ選び、業務用語、キー、リレーションシップを整理します。そのうえで、管理者設定を確認し、静的データのバインディング、Graph表示、クエリ確認までを検証します。AIエージェント連携は、Ontologyの品質が確認できてから進めるのが安全です。
コメント