Fabricオントロジーとは？Fabric IQの作成手順と新エクスペリエンスの変更点【2026年9月】

Microsoft Fabricのオントロジー（ontology）は、「顧客」「店舗」「冷凍庫」といった業務上の概念とその関係・ルール・指標を1か所で定義し、OneLake上の実データに結び付けるアイテムです。2025年11月のMicrosoft Ignite 2025で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で意味を定義する実装手順で扱っています。

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つです。

「Fabric IQがGAした」と書く第三者記事がありますが、GAしたのは上表の個別アイテムで、ワークロード全体の表記は「IQ (preview)」のままです。

オントロジーを構成する8つの要素と命名の制約

新エクスペリエンスの概要ページが挙げるコア概念は次の8つです。旧エクスペリエンスのコア概念（エンティティ型・エンティティインスタンス・プロパティ・リレーションシップと、データ側のデータバインディング・オントロジーグラフ）に、メトリック・ルール・名前空間が加わりました。

ルールは「実行されない」点に注意してください。ドキュメントには、ルールは自然文の定義であり、オントロジー自体はルールを実行しないと書かれています。ルールはエージェントが推論するときの文脈として読まれるもので、違反を検知して通知したい場合はActivatorなど別の仕組みが必要です。

このほか、単一親の継承（VehicleからCarとTruckを派生させるなど）と、複数のエンティティ型で1つの定義を共有する共有プロパティも使えます。継承元のエンティティ型に問い合わせると、直下の派生型のインスタンスもまとめて返ります（1階層まで）。ただし継承は段階的に展開中で、テナントや容量によってはまだ使えない場合があります。

命名には制約があります。エンティティ型名とプロパティ名は1〜26文字で、英数字（公式の表記は alphanumeric）・ハイフン・アンダースコアしか使えず、先頭と末尾は英数字でなければなりません。この条件から日本語名は使えないと考えるのが安全で、社内の呼び名はエンティティ型の「シノニム」（別名）として登録します。シノニムを付けられるのはエンティティ型だけで、プロパティとリレーションシップには説明文とキー・値のメタデータしか付けられません。

セマンティックモデル・Graphとの役割分担

Power BIセマンティックモデルとの違い：分析用モデルと業務語彙

両者は置き換えの関係ではありません。オントロジーはセマンティックモデルから生成でき、メトリックはセマンティックモデル側のDAX式を参照し続けます。オントロジー側で説明文を書き換えてもセマンティックモデルは変わらないので、KPIの計算式はセマンティックモデルで管理し、エージェント向けの意味付けはオントロジーで足す、という分担になります。

Graph in Microsoft Fabricとの違い：グラフの実体化は任意

ナレッジグラフとの関係は、新エクスペリエンスで考え方が変わりました。旧エクスペリエンスでは、データバインディングとリレーションシップからインスタンスのグラフが自動で作られる前提でした。新エクスペリエンスでは、オントロジーから導かれるのはスキーマのグラフだけで、既定ではインスタンスデータを読み込みません。

グラフが必要になるのは、多段の経路探索・依存関係の分析・最短経路のように「つながり方そのもの」が答えになる質問です。その場合だけ、対象のエンティティ型を選んでグラフを実体化（materialize）します。所要時間はデータ量しだいで数分から数時間。グラフの更新も容量を消費します。単純な検索・集計・時系列の質問は、グラフを作らずに元のデータソースへ直接問い合わせます。グラフデータベース全般の使いどころはベクトルデータベースとグラフデータベースの違いを参照してください。

オントロジーの作成手順（新エクスペリエンス）

前提条件：テナント設定・ワークスペース・権限

• 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つ目のテーブルを結合する手順も載っています）。時系列データはイベントハウスとレイクハウスの両方から複数結び付けられます。
• 元データに新しい行が入っても自動では反映されず、オントロジーの手動更新が必要です。

列名の制約は既存テーブルで引っかかりやすい部分です。バインディングの前にメダリオンアーキテクチャの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は、［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/<workspace-ID>/items/<ontology-item-ID>/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/<ID>/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<double> のように表されます。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の書き方で説明しています。

課金と容量の見積もり：Ontology Discoveryは読み取り1回1,000 CU秒

新エクスペリエンスの課金メーターは次の3つです（2026年9月22日更新）。旧エクスペリエンスの「Ontology Modeling（0.0039 CU/時）」とは体系が別物なので、2026年前半の記事にある料金例は使えません。

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モードのセマンティックモデル：バインディングが生成されず、レイクハウスへの付け替えが前提になります。データ基盤がまだレイクハウスに集まっていない組織では、先にそちらを整えるべきです。
• ルール違反の自動通知が要件：新エクスペリエンスのルールは実行されず、Activator連携もありません。この要件だけならActivatorやoperations agentを直接使うほうが近道です。
• セマンティックモデル1つで質問が完結する：データエージェントをセマンティックモデルに直接つなげば足ります。オントロジーが持つセマンティックモデル由来の文脈はオントロジーエージェントしか使わず、データエージェントには渡らないとドキュメントに明記されているためです。オントロジーの価値は、複数のデータソースや部門をまたいで言葉をそろえるときに出ます。
• 行レベルの権限設計が固まっていない：オントロジーはOneLakeセキュリティやソース側の行レベルセキュリティ（RLS）・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年版】
• データファブリックとは？構成要素とアクティブメタデータの実装・採用判断を解説
• ベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】
• データレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説
• Microsoft Ignite 2025で発表されたAI戦略や新技術: Frontier FirmとWork IQの全貌