--- title: "Fabricオントロジーとは？Fabric IQの作成手順と新エクスペリエンスの変更点【2026年9月】" url: "https://www.issoh.co.jp/tech/details/10573/" published: 2026-01-13 updated: 2026-09-29 categories: ["データ分析・BI"] publisher: "株式会社一創" --- # Fabricオントロジーとは？Fabric IQの作成手順と新エクスペリエンスの変更点【2026年9月】 Microsoft Fabricのオントロジー（ontology）は、「顧客」「店舗」「冷凍庫」といった業務上の概念とその関係・ルール・指標を1か所で定義し、OneLake上の実データに結び付けるアイテムです。2025年11月の[Microsoft Ignite 2025](/tech/details/10008/)でFabric IQとともに発表され、2026年9月時点でもプレビューのままです。 2026年9月には「新エクスペリエンス」がプレビュー公開され、作成手順・エージェント連携・課金メーターが入れ替わりました。旧エクスペリエンスでは新規作成ができなくなり、2027年1月31日に退役します。この記事では、Microsoft Learnの現行ドキュメント（ontology概要ページの更新日は2026年9月15日）をもとに、新エクスペリエンスの仕様を整理します。 ## まとめ：Fabricオントロジーの要点と2026年9月時点の状況 - **正体**：業務概念の定義と、実データへの対応付け（データバインディング）を保持するアイテム。データそのものは元のレイクハウスやイベントハウスに残り、オントロジーはコピーを持ちません。 - **提供状況**：Fabric IQワークロードもオントロジーもプレビュー。同じFabric IQのPlanningは2026年7月、Graphとoperations agentは同年6月にGAしていますが、オントロジーは対象外です。 - **新エクスペリエンスで増えたもの**：DAXメジャーを参照するメトリック、自然文のビジネスルール、名前空間、継承、バージョン履歴、RDF/OWLのインポート、Plan/Actの2モードを持つオントロジーエージェント。 - **消えたもの**：Fabric Activatorとの連携。旧版でアラートを組んでいた場合は、Activatorを別途構成し直す必要があります。 - **課金**：定義の読み取り1回につき1,000 CU秒（Ontology Discovery）。F2容量なら1日分の処理能力を約173回の読み取りで使い切る計算です。 - **最初に確認すること**：テナント設定「Enable Ontology item (preview)」の有効化と、セマンティックモデルがImportモードでないか（Importモードからはデータバインディングを生成できません）。 以下、定義と構成要素、作成手順、エージェント連携、移行と課金の順に説明します。 ## Fabricオントロジーの定義とFabric IQ内の位置づけ ### 一般的な意味のオントロジーとFabric版の違い 情報科学でいうオントロジーは、概念とその関係を機械が読める形で定義したものです。W3CのRDFやOWLで記述するのが標準的な方法で、こちらの一般的な定義と記述方法は[RDFとOWLで意味を定義する実装手順](/tech/details/17449/)で扱っています。 Fabricのオントロジーは、この考え方をFabricのアイテムとして製品化したものです。違いは、定義を実データに結び付けて、エージェントがそのまま問い合わせに使える点にあります。Microsoft Learnは、オントロジーを「データの保存のされ方と、業務としての理解のされ方の隔たりを埋める層」と説明しています。RDF/OWLファイルはインポートできますが、Fabric独自の内部モデルに変換され、表現できない要素は取り込まれません。なお、日本語版のMicrosoft Learnでは「オントロジ」と長音なしで表記されています。 ### Fabric IQワークロードを構成する6つのアイテム Fabric IQはMicrosoft IQ（Work IQ・Foundry IQ・Web IQ・Fabric IQ）の一部で、業務データの文脈を担当します。Fabric上のIQワークロードには次のアイテムが含まれ、中核はオントロジーとPower BIセマンティックモデルの2つです。 | アイテム | 役割 | 提供状況（2026年9月） | | ------------------ | --------------- | --------------- | | Ontology | 業務語彙と実データの対応付け | プレビュー | | Power BIセマンティックモデル | メジャー・階層を持つ分析モデル | GA（Power BIと共有） | | Graph | ノードとエッジの保存・探索 | GA（2026年6月） | | Planning | 計画・予測・予実管理 | GA（2026年7月） | | Data agent | 自然言語での質疑応答 | GA（2026年3月） | | Operations agent | リアルタイム監視と対処の提案 | GA（2026年6月） | 「Fabric IQがGAした」と書く第三者記事がありますが、GAしたのは上表の個別アイテムで、ワークロード全体の表記は「IQ (preview)」のままです。 ## オントロジーを構成する8つの要素と命名の制約 新エクスペリエンスの概要ページが挙げるコア概念は次の8つです。旧エクスペリエンスのコア概念（エンティティ型・エンティティインスタンス・プロパティ・リレーションシップと、データ側のデータバインディング・オントロジーグラフ）に、メトリック・ルール・名前空間が加わりました。 | 要素 | 内容 | 例 | | ------------ | ---------------------- | --------------------- | | エンティティ型 | 業務概念の再利用可能な定義 | Customer、Store | | エンティティインスタンス | データに裏付けられた個々の実体 | 特定の店舗 | | プロパティ | 型を持つ属性 | 顧客のメールアドレス | | リレーションシップ | 2つのエンティティ型のつながり | Customer places Order | | メトリック | セマンティックモデルのDAXメジャーへの参照 | 売上、在庫金額 | | ルール | 自然文で書く業務ルール | 冷凍設備は90日ごとに点検 | | 名前空間 | 要素を部門・ドメイン単位で分ける範囲 | 販売、物流 | | データバインディング | 定義と元データ列の対応付け | StoreId列をキーに対応 | ルールは「実行されない」点に注意してください。ドキュメントには、ルールは自然文の定義であり、オントロジー自体はルールを実行しないと書かれています。ルールはエージェントが推論するときの文脈として読まれるもので、違反を検知して通知したい場合はActivatorなど別の仕組みが必要です。 このほか、単一親の継承（VehicleからCarとTruckを派生させるなど）と、複数のエンティティ型で1つの定義を共有する共有プロパティも使えます。継承元のエンティティ型に問い合わせると、直下の派生型のインスタンスもまとめて返ります（1階層まで）。ただし継承は段階的に展開中で、テナントや容量によってはまだ使えない場合があります。 命名には制約があります。エンティティ型名とプロパティ名は1〜26文字で、英数字（公式の表記は alphanumeric）・ハイフン・アンダースコアしか使えず、先頭と末尾は英数字でなければなりません。この条件から日本語名は使えないと考えるのが安全で、社内の呼び名はエンティティ型の「シノニム」（別名）として登録します。シノニムを付けられるのはエンティティ型だけで、プロパティとリレーションシップには説明文とキー・値のメタデータしか付けられません。 ## セマンティックモデル・Graphとの役割分担 ### Power BIセマンティックモデルとの違い：分析用モデルと業務語彙 | 観点 | セマンティックモデル | オントロジー | | ------ | ------------ | ------------------- | | 単位 | テーブル・列・メジャー | エンティティ型・関係・ルール | | 主な利用者 | Power BIレポート | エージェント・アプリ | | 計算式 | DAXメジャーを保持 | メジャーを参照（編集は自身にのみ保存） | | データソース | 1モデル内のテーブル | レイクハウス・イベントハウス等を横断 | | 提供状況 | GA | プレビュー | 両者は置き換えの関係ではありません。オントロジーはセマンティックモデルから生成でき、メトリックはセマンティックモデル側のDAX式を参照し続けます。オントロジー側で説明文を書き換えてもセマンティックモデルは変わらないので、KPIの計算式はセマンティックモデルで管理し、エージェント向けの意味付けはオントロジーで足す、という分担になります。 ### Graph in Microsoft Fabricとの違い：グラフの実体化は任意 ナレッジグラフとの関係は、新エクスペリエンスで考え方が変わりました。旧エクスペリエンスでは、データバインディングとリレーションシップからインスタンスのグラフが自動で作られる前提でした。新エクスペリエンスでは、オントロジーから導かれるのはスキーマのグラフだけで、既定ではインスタンスデータを読み込みません。 グラフが必要になるのは、多段の経路探索・依存関係の分析・最短経路のように「つながり方そのもの」が答えになる質問です。その場合だけ、対象のエンティティ型を選んでグラフを実体化（materialize）します。所要時間はデータ量しだいで数分から数時間。グラフの更新も容量を消費します。単純な検索・集計・時系列の質問は、グラフを作らずに元のデータソースへ直接問い合わせます。グラフデータベース全般の使いどころは[ベクトルデータベースとグラフデータベースの違い](/tech/details/4682/)を参照してください。 ## オントロジーの作成手順（新エクスペリエンス） ### 前提条件：テナント設定・ワークスペース・権限 - Fabric管理者が［OneLake catalog］＞［Govern］＞［Configurations］＞［Tenant settings］で「Enable Ontology item (preview)」を有効にする（無効だと作成時にエラーになります）。 - Fabric容量が割り当てられたワークスペースを使う。セマンティックモデルからの生成は「My workspace」では動きません。 - データエージェントやoperations agentと組み合わせる場合は、それぞれのテナント設定も有効にする。 - 日本リージョンの容量では、オントロジーエージェントが既定で無効。米国とEUデータ境界の外にある容量では、テナント設定「Data sent to Azure OpenAI can be processed outside your capacity’s geographic region, compliance boundary, or national cloud instance」を有効にする必要があります。 - ワークスペースのContributor以上の権限を用意する。エージェントで定義を作成・適用するにはContributor以上が必要で、Viewerは既存の定義の説明と問い合わせだけです。 トラブルシューティングのページは、アイテムの作成に失敗する最も一般的な原因としてテナント設定の未有効化を挙げています。 ### エンティティ型・プロパティ・リレーションシップを手動で定義する流れ 1. ワークスペースで新しいOntologyアイテムを作成し、キャンバスの［Add entity type］でエンティティ型（例：Store）を追加する。 2. エンティティ型の［Configure］ページで［Manage property bindings］を開き、プロパティを追加する。型を決めていない段階なら「Unknown」を選べる。 3. ［Add binding and properties］でOneLakeカタログからテーブルを選ぶと、列がプロパティ候補として並ぶ。名前を整えて保存する。 4. 文字列か整数のプロパティをエンティティ型キーに設定する。 5. ［Add relationship］で起点と終点のエンティティ型を選び、キー列同士、または対応表（mapping table）を指定して保存する。リレーションシップ名は重複させない（重複名で問い合わせが失敗する既知の問題があります）。 型を「Unknown」にしたプロパティは、データを結び付けるまで問い合わせ結果にもグラフにも出てきません。先に業務の言葉で骨組みを作り、データソースが決まってから型を確定させる使い方ができます。 ### データバインディングの対応ソースと型の制約 バインディングできるのは、Eventhouse・KQLデータベース・Lakehouse・ミラーリングデータベース・セマンティックモデル・SQLデータベース・Warehouseの7種類です。プロパティの型は整数・真偽値・日時・倍精度・文字列の5種類で、エンティティ型キーに使えるのは文字列と整数だけです。 - レイクハウスは**マネージドテーブルのみ**。別の場所にある外部テーブルは使えません。 - 列名にスペースや「,」「;」「=」などがあると、Deltaの列マッピングが自動で有効になり、グラフで扱えなくなります。 - 制限事項の節では、静的データのバインディングはエンティティ型ごとに1つとされています（同じページに、共通列で2つ目のテーブルを結合する手順も載っています）。時系列データはイベントハウスとレイクハウスの両方から複数結び付けられます。 - 元データに新しい行が入っても自動では反映されず、オントロジーの手動更新が必要です。 列名の制約は既存テーブルで引っかかりやすい部分です。バインディングの前に[メダリオンアーキテクチャ](/tech/details/16438/)のSilver層やGold層で列名を英数字とアンダースコアにそろえておくと、後から作り直す手間を避けられます。 ## Power BIセマンティックモデルからの自動生成 ### 自動で作られる要素と手作業で残る作業 セマンティックモデルのリボン（または［…］メニュー）で［Generate Ontology］を選ぶと、テーブルがエンティティ型に、列がプロパティとバインディングに、モデル内のリレーションシップがリレーションシップ型に、DAXメジャーがメトリックになります。 生成後に手作業で残るのは、時系列データのバインディング、エンティティ型キーの確認（特に複合キー）、リレーションシップ型へのデータの結び付け、名前の変更の4つです。2つ目以降のセマンティックモデルを同じオントロジーに加えたい場合は、UIではなくオントロジーエージェント経由でしか追加できません。生成にも問い合わせにも、元のセマンティックモデルに対するReadとBuildの両方の権限が必要です。 ### Import・Direct Lake・DirectQueryで変わるバインディングの可否 生成で最も差が出るのは、セマンティックモデルのストレージモードです。トラブルシューティングのページ（2026年9月6日更新）では、次の場合に「オントロジーは作られるがエンティティ型にデータバインディングが付かない」とされています。 - 元のセマンティックモデルがImportモード - Direct Lakeモードで、背後のレイクハウスがあるワークスペースの受信パブリックアクセスが無効 旧エクスペリエンスのドキュメントでは、DirectQueryモードもバインディング生成の対象外でした。Importモードのモデルからは、エンティティ型・プロパティ・リレーションシップの定義だけが生成されます。定義だけ作ってからレイクハウスのテーブルへバインディングし直すのが現実的な手順です。 数値型にも落とし穴があります。Graph in Microsoft FabricはDecimal型に対応していないため、Decimal列を含むテーブルから生成すると、そのプロパティは問い合わせで常にnullです。金額列がDecimalのモデルは、オントロジー側でプロパティをDouble型として作り直す必要があります。 ### DAXメジャーはコピーせず参照するメトリック メトリックは、DAXメジャーをコピーせず、元のセマンティックモデルへのリンクとして保持します。DAX式を表示するには元モデルへの書き込み権限が必要で、権限がなければ名前・説明・所属テーブルだけが見えます。メジャーの式を変えてもメトリックは自動更新されないので、オントロジー側での更新が必要です。複数テーブルを参照するメジャーでも、紐づくエンティティは定義されたテーブル1つだけです。 ## オントロジーエージェントの使い方：Plan modeとAct mode 新エクスペリエンスには、オントロジーの中で動くチャット型のオントロジーエージェントが組み込まれています。ワークスペース内のレイクハウス・イベントハウス・セマンティックモデルを調べて定義とバインディングの下書きを作り、質問に答え、変更を提案します。 既定はPlan modeで、下書き・検証・問い合わせ・説明はできますが、オントロジーは書き換えません。Act modeに切り替えたときだけ変更を適用し、適用前に内容を示します。変更は全体の書き直しではなく差分（patch）として提案され、エンティティやリレーションシップのIDが保たれるため、下流の問い合わせが壊れにくくなっています。 問い合わせでは、バインド先に応じてエンジンを使い分けます。イベントハウスにはKQL、レイクハウスにはSQL、セマンティックモデルにはDAX、グラフを実体化していればリレーションシップの探索にGQL（openCypherではなくISO GQL）です。既定で返す行数はKQL・SQL・GQLが最大1,000行、DAXが最大200行です。 運用上の制限も押さえておきます。 - エージェントが参照できるのは、オントロジーと同じワークスペースにある項目だけ。別ワークスペースのデータはショートカットで持ち込む。 - 添付ファイルは1会話10件まで、1件5MBまで。業務要件書やデータ辞書を読ませて命名に使えます。 - 会話はブラウザのセッション内にしか残らず、ページを再読み込みすると消えます。24時間を超えて続けることもできません。 - 会話データは終了後最大2日間保持され、基盤モデルの学習には使われないとされています。 - Act modeで適用した変更に自動のロールバックはない。戻すときはバージョン履歴から復元するか、以前の定義を適用し直します。 ## エージェント・外部AIからオントロジーを使う6つの経路 | 経路 | 向いている用途 | 主な利用者 | | ----------------------- | ------------------ | ---------- | | オントロジーエージェント | 定義の作成・改善・試験 | オントロジーの作成者 | | Fabric data agent | Fabric内での対話型分析 | アナリスト・業務担当 | | Fabric operations agent | リアルタイム監視と対処の提案 | 運用チーム | | Foundry IQ agent | ツール呼び出しを含む自作エージェント | 開発者 | | Copilot Studio agent | ローコードの会話エージェント | 業務部門の作成者 | | オントロジーMCPサーバー | 任意のMCPクライアントからの接続 | 開発者 | ### データエージェント接続時の既知の不具合と回避策 Fabric data agentは、［Add a data source］でオントロジーを選ぶだけで接続できます。ただし2026年9月13日更新のドキュメントに、2つの既知の問題が載っています。 1つは、**データバインディングにセマンティックモデルを使っているオントロジーでは、データエージェントが動かない**ことです。セマンティックモデルから生成したオントロジーをつなぐ前に、各エンティティ型の［Configure］でバインド先がセマンティックモデルになっていないかを確かめてください。もう1つは集計が正しく行われない問題で、エージェント指示に `Support group by in GQL` を追記するよう案内されています。作成直後の数回の質問が「データがない」で失敗することもあり、その場合は数分待ってから再実行します。 ### MCPサーバーのエンドポイントとVS Codeからの接続 オントロジーはMCP（Model Context Protocol）サーバーとして公開でき、F2以上の有償Fabric容量か、Fabricを有効にしたPower BI Premium（P1以上）が必要です。エンドポイントは、オントロジーを開いたときのURLに含まれるワークスペースIDとアイテムIDから組み立てます。VS Codeでは `.vscode/mcp.json` に次のように登録します。 ``` { "servers": { "fabric-ontology": { "type": "http", "url": "https://api.fabric.microsoft.com/v1/mcp/dataPlane/workspaces//items//ontologyEndpoint" } } } ``` 登録時にVS Codeが認証を求めるので、Fabricのアカウントでサインインします。以後はチャットのエージェントモードからオントロジーを参照できます。MCP経由の定義の読み取りも、後述するOntology Discoveryメーターの課金対象です。ビジネスルールはMCPのツールで取得できますが、読み取り専用で、ルールの実行は呼び出し側に任されます。 ## REST APIで定義を取得してレビュー・CI/CDに組み込む オントロジーの定義はFabric REST APIの `getDefinition` で取り出せます。新エクスペリエンスの定義は、Analysis Servicesの表形式モデルと同じTMDL形式のテキストで返り、エンティティ型ごとに `entities/<名前空間>#<名前>.tmdl` のファイルに分かれます（既定の名前空間なら `entities/Sensor.tmdl` のように名前だけ）。旧エクスペリエンスのアイテムは `EntityTypes//definition.json` のJSON形式なので、取得処理を書き分ける必要があります。呼び出しには、オントロジーへの読み書き権限と `Item.ReadWrite.All` スコープが必要です。サービスプリンシパルとマネージドIDにも対応しています。 次のPythonスクリプトは、新エクスペリエンスの定義を取得して、エンティティ型ごとの通常プロパティ数と時系列プロパティ名を一覧にします。処理に時間がかかると202が返るので、Fabric共通の長時間実行操作（LRO）の手順でポーリングします。 ``` import base64 import re import sys import time import requests from azure.identity import DefaultAzureCredential API = "https://api.fabric.microsoft.com/v1" def fetch_definition(workspace_id, ontology_id, session=None): s = session or requests.Session() if session is None: token = DefaultAzureCredential().get_token("https://api.fabric.microsoft.com/.default").token s.headers["Authorization"] = f"Bearer {token}" r = s.post(f"{API}/workspaces/{workspace_id}/ontologies/{ontology_id}/getDefinition") r.raise_for_status() if r.status_code == 202: op_id = r.headers["x-ms-operation-id"] while True: time.sleep(int(r.headers.get("Retry-After", 30))) r = s.get(f"{API}/operations/{op_id}") r.raise_for_status() status = r.json()["status"] if status == "Failed": sys.exit(f"getDefinition failed: {r.text}") if status == "Succeeded": r = s.get(f"{API}/operations/{op_id}/result") r.raise_for_status() break return r.json()["definition"]["parts"] def summarize(parts): for part in parts: path = part["path"] if not (path.startswith("entities/") and path.endswith(".tmdl")): continue text = base64.b64decode(part["payload"]).decode("utf-8") name = re.search(r"^entity\s+(\S+)", text, re.M).group(1) base = re.search(r"^\s*baseEntityType:\s*(\S+)", text, re.M) props = re.findall(r"^\s*property\s+(\S+)\s*\n\s*dataType:\s*(\S+)", text, re.M) static = [n for n, t in props if not t.startswith("TimeSeries")] series = [n for n, t in props if t.startswith("TimeSeries")] print(name, "base=", base.group(1) if base else None, "props=", len(static), "timeseries=", series) if __name__ == "__main__": summarize(fetch_definition(sys.argv[1], sys.argv[2])) ``` Microsoft Learnの定義形式ページに載っている風力発電所（WindFarm）の定義例をこのスクリプトに通すと、12個のエンティティ型が出力されます。そのうち時系列データを持つ行は次のとおりです。 ``` wind_turbines base= None props= 9 timeseries= ['EnergyKwh', 'Diameter', 'Ratio', 'Efficiency', 'Power', 'Voltage', 'Timestamp'] ``` TMDLの `baseEntityType` には継承元のエンティティ型が `<名前空間>#<名前>` 形式で入り、時系列プロパティの型は `TimeSeries` のように表されます。TMDLのテキストなので、FabricのGit統合でワークスペースの変更をコミットすれば、エージェントがAct modeで適用した変更も差分としてレビューできます。デプロイパイプラインでの環境間の移送も同じ定義で行えます。逆方向の `updateDefinition` は現在の定義を上書きする操作なので、取得した定義を編集して丸ごと送り返すのが前提です。暗号化された秘密度ラベルが付いたオントロジーでは `getDefinition` を呼べません。 ## 旧エクスペリエンスからの移行と2027年1月31日の退役 現在、旧エクスペリエンスではオントロジーを新規作成できません。既存アイテムは2027年1月31日まで使えますが、それ以降に備えて新エクスペリエンスへ移す必要があります。旧アイテムを開くと表示されるバナーの［create a copy in the new experience］で、エンティティ型・プロパティとバインディング・リレーションシップ型を引き継いだ別アイテムが作られます。 コピーは別アイテムなので、自動では移りません。移行時に手作業が要るのは次の3点です。 - データエージェント・operations agent・ダッシュボードなど、下流の接続先を新アイテムにつなぎ直す。 - ビジネスルールを新エクスペリエンスで作り直す。旧版のルールはActivatorによるアラートの定義でしたが、新版のルールは自然文の定義です。 - 旧版でFabric Activatorのアラートを使っていた場合は、Activatorをデータソース側に別途構成する。新エクスペリエンスにはActivatorとの直接連携がありません。 用語も変わっています。旧版の概要ページにあった「NL2Ontology（自然言語をオントロジーの構造化クエリに変換する層）」は、新エクスペリエンスのドキュメントには出てきません。自然言語での問い合わせはオントロジーエージェントが担い、KQL・SQL・DAX・GQLを直接生成します。 旧版で「未対応」とされていた機能も入りました。バージョン履歴（名前は100文字まで、説明は500文字まで、復元すると定義全体が置き換わる）と、TTL・RDF/RDFS・OWLファイルのインポートです。インポートは空のオントロジーにしかできず、多重継承は最初の親だけが残ります。エクスポートはTTLとRDFのみで、OWLでは書き出せません。2026年1月27日更新のFAQページには「バージョン管理は使えない」という古い回答が残っているので、判断には各機能のページを使ってください。RDFの問い合わせ言語については[SPARQLの書き方](/tech/details/3428/)で説明しています。 ## 課金と容量の見積もり：Ontology Discoveryは読み取り1回1,000 CU秒 新エクスペリエンスの課金メーターは次の3つです（2026年9月22日更新）。旧エクスペリエンスの「Ontology Modeling（0.0039 CU/時）」とは体系が別物なので、2026年前半の記事にある料金例は使えません。 | メーター | 対象 | レート | | ----------------------------- | ---------------------- | ----------- | | Ontology Discovery | UI・MCPサーバーからの定義の読み取り | 1回1,000 CU秒 | | Ontology Logic and Operations | 子アイテムのEventhouse・Graph | 各子アイテムと同じ | | Ontology AI | MCPサーバーとオントロジーエージェント | トークン量に応じる | 1,000 CU秒という値は、小さな容量では無視できません。F2は2 CUなので、1日に使える処理能力は2 CU×86,400秒＝172,800 CU秒です。平準化を考えない単純計算では、定義の読み取り約173回でF2の1日分に達します。複数人がキャンバスを開いたり、MCP経由のエージェントが頻繁に定義を読んだりする使い方なら、F2では足りない可能性が高いと考えてください。試験導入でもMicrosoft Fabric Capacity Metricsアプリで消費量を監視し、読み取り回数から必要な容量を逆算するのが安全です。 2026年10月1日からは、AI処理の消費量が固定値ではなく、使うモデル・推論の深さ・呼び出すサービスの数に応じて変わる方式になります。オントロジーの定義はOneLakeに保存されるため、通常のOneLakeストレージ料金も対象です。グラフの更新スケジュールを細かく設定すると容量超過でキャンバスが開かなくなることがあり、その場合はスケジュールを減らすか止めるよう案内されています。 ## 本番導入を見送るべき4つの条件 プレビューであること自体より、次の条件に当てはまるかどうかで判断したほうが実務に合います。 - **業務の中核がImportモードのセマンティックモデル**：バインディングが生成されず、レイクハウスへの付け替えが前提になります。データ基盤がまだ[レイクハウス](/tech/details/13628/)に集まっていない組織では、先にそちらを整えるべきです。 - **ルール違反の自動通知が要件**：新エクスペリエンスのルールは実行されず、Activator連携もありません。この要件だけならActivatorやoperations agentを直接使うほうが近道です。 - **セマンティックモデル1つで質問が完結する**：データエージェントをセマンティックモデルに直接つなげば足ります。オントロジーが持つセマンティックモデル由来の文脈はオントロジーエージェントしか使わず、データエージェントには渡らないとドキュメントに明記されているためです。オントロジーの価値は、複数のデータソースや部門をまたいで言葉をそろえるときに出ます。 - **行レベルの権限設計が固まっていない**：オントロジーはOneLakeセキュリティやソース側の[行レベルセキュリティ（RLS）](/tech/details/5442/)・OLS・CLSを尊重しますが、エージェントは利用者の権限で動くため、元データの権限が曖昧なままだと回答の範囲も曖昧になります。 逆に、店舗・設備・出荷のように複数のシステムに散らばった実体を横断して質問したい場合、特にイベントハウスの時系列データと台帳系のテーブルを組み合わせたい場合は、プレビュー段階でも検証する価値があります。Microsoft Learnのチュートリアル（架空の小売企業Lakeshore Retailで、店舗・商品・冷凍設備の温度データを結び付ける題材）が、その典型例です。 ## よくある質問 ### Fabric IQとは何ですか？オントロジーとの関係は？ Fabric IQは、Microsoft Fabric上で業務データに意味付けをするワークロードで、Work IQ・Foundry IQ・Web IQと並ぶMicrosoft IQの一部です。中核はオントロジーとPower BIセマンティックモデルで、ほかにGraph・Planning・データエージェント・operations agentを含みます。オントロジーは、このうち業務語彙と実データの対応付けを担当するアイテムです。 ### Fabricのオントロジーはナレッジグラフと同じものですか？ 別物です。オントロジーは「何がどうつながるか」という定義とデータの対応付けを持ち、ナレッジグラフ（Graph in Microsoft Fabric）はノードとエッジを保存して探索します。新エクスペリエンスではグラフの実体化は任意で、多段の経路探索などが必要なときだけエンティティ型を選んで作ります。 ### Fabricのオントロジーは正式リリース（GA）されていますか？ 2026年9月時点ではプレビューです。Microsoft Learnの概要ページ（2026年9月15日更新）にもプレビューと明記されています。同じFabric IQのPlanning（2026年7月）、Graphとoperations agent（同6月）、データエージェント（同3月）はGAしていますが、オントロジー本体とIQワークロードはプレビューのままです。 ### Fabricオントロジーの料金はどのくらいかかりますか？ 専用のライセンス料はなく、Fabric容量のCU消費で課金されます。定義の読み取りは1回1,000 CU秒、子アイテムのEventhouseとGraphはそれぞれのレート、エージェントとMCPサーバーはトークン量に応じて消費します。F2では約173回の読み取りで1日分の処理能力に達する計算なので、試験導入でもCapacity Metricsアプリで消費を確認してください。 ### NL2Ontologyは新エクスペリエンスでも使えますか？ NL2Ontologyは旧エクスペリエンスの概要ページで説明されていた自然言語クエリの層で、新エクスペリエンスのドキュメントにはこの名称が出てきません。新エクスペリエンスでは、オントロジーエージェントが質問に応じてKQL・SQL・DAX・GQLのクエリを生成し、実行したクエリと結果を示します。 ### エンティティ型やプロパティに日本語の名前を付けられますか？ 付けられないと考えてください。エンティティ型名とプロパティ名は1〜26文字で、英数字（alphanumeric）・ハイフン・アンダースコアのみと定められています。日本語の呼び名はエンティティ型のシノニム（別名）や説明文として登録すると、エージェントが「店舗」「売り場」といった言い方を同じ概念として扱えるようになります。 ## 関連記事 - [オントロジーとは？RDFとOWLで意味を定義する実装手順【2026年版】](/tech/details/17449/) - [データファブリックとは？構成要素とアクティブメタデータの実装・採用判断を解説](/tech/details/16436/) - [ベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】](/tech/details/4682/) - [データレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説](/tech/details/13628/) - [Microsoft Ignite 2025で発表されたAI戦略や新技術: Frontier FirmとWork IQの全貌](/tech/details/10008/) --- 出典: [Fabricオントロジーとは？Fabric IQの作成手順と新エクスペリエンスの変更点【2026年9月】]()（株式会社一創）