「Public Preview: Fabric IQ Ontology Knowledge Source in Microsoft Foundry IQ」は、Microsoft Edgeそのものの機能追加ではありません。重要なのは、Microsoft Foundry IQがMicrosoft FabricのOntologyをナレッジソースとして扱えるようになり、エージェントがFabricで管理済みのセマンティックレイヤーを参照できるようになる点です。Edge管理者はブラウザー更新よりも、Foundryポータル利用時のサインイン、権限、同意フロー、Fabricワークスペースへのアクセス確認を優先して見直すべきです。
2026年6月5日前後に公開・更新された公式情報では、この機能は「In preview」、つまり本番前の検証用途として提供される位置付けです。既存のRAG基盤やAzure AI Searchのインデックスをすぐ置き換えるのではなく、Fabric Ontologyを信頼できる業務語彙として使えるか、権限やデータ境界を守ったままエージェントに接続できるかを段階的に確認しましょう。(マイクロソフト Azure)
Microsoft Edgeの変更ではなく、Foundry IQとFabric IQの連携強化と捉える
今回の発表名に「Microsoft Foundry IQ」が含まれるため、Edgeのリリース情報として見た場合は少し分かりにくいかもしれません。整理すると、主役はEdgeブラウザーではなく、Microsoft Foundry IQ、Azure AI Search、Microsoft Fabric IQ Ontologyの連携です。
Microsoftのドキュメントでは、Foundry IQはエージェントが実行時に参照できるナレッジソースとナレッジベースを提供する仕組みとして説明されています。Fabric IQ OntologyはOneLake上に存在するセマンティックレイヤーで、業務エンティティ、関係、ビジネスルール、裏付けとなるテーブルを表現します。これをFoundry IQのナレッジソースとして公開することで、エージェントはFabricデータを業務文脈に沿って扱えるようになります。(Microsoft Learn)
Edgeとの関係で押さえるべき点は、公式手順の前提条件に「FoundryプロジェクトとFabricワークスペースの両方にアクセスできる同じIDでサインインしているEdgeまたはChromeブラウザー」が含まれていることです。つまり、Edge管理者が見るべきなのは、新しいEdgeポリシーの配布ではなく、ポータル操作・認証・同意・アクセス権が社内環境で妨げられないかです。(Microsoft Learn)
何が変わるのか
今回の変更により、Microsoft Foundry IQはMicrosoft Fabric Ontologyを「Fabric Ontology knowledge source」として扱えるようになります。Azure AI Searchのドキュメントでは、このナレッジソースはMicrosoft Fabric Ontologyに接続し、エージェント型検索パイプラインでグラウンディングデータとして使われると説明されています。(Microsoft Learn)
従来の検索インデックス型ナレッジソースでは、ドキュメントやデータを取り込み、チャンク化し、検索インデックスを構成する流れが中心でした。一方、Fabric Ontology knowledge sourceはライブデータを取得時に直接クエリする方式で、個別の取り込みパイプラインを必要としません。取得時にはエンドユーザーのアクセストークンを利用し、Microsoft Fabricに対してユーザーの代理で認証します。(Microsoft Learn)
| 観点 | 従来のインデックス型ナレッジソース | Fabric Ontology knowledge source |
|---|---|---|
| 主な対象 | ドキュメント、Blob、OneLake、SharePointなどを検索用に取り込む | Fabric IQ Ontologyで定義された業務エンティティや関係 |
| データ取得 | 事前にインデックス化して検索 | 取得時にOntologyを直接クエリ |
| 強み | 文書検索、全文検索、ベクトル検索、ハイブリッド検索 | 業務語彙、関係、ルールに基づく構造化された回答 |
| 注意点 | インデックス更新、権限同期、チャンク設計が重要 | Ontology設計、データバインディング、ユーザー権限が重要 |
| 向いている用途 | 規程、マニュアル、FAQ、技術文書の検索 | 顧客、注文、製品、設備、売上など業務概念をまたぐ質問 |
例えば、エージェントに「前四半期に1万ドルを超える注文を行った顧客は？」と質問した場合、テーブル名や列名を直接意識させるのではなく、Customer、Order、Productのような業務概念を使って回答させる設計がしやすくなります。Fabric IQには自然言語をOntologyの構造化クエリへ変換するNL2Ontologyレイヤーがあり、業務用語で質問できる点が特徴です。(Microsoft Learn)
対象になる組織と対象外になりやすい組織
このプレビューの恩恵が大きいのは、すでにMicrosoft Fabricでデータ基盤を整備し、業務部門とデータチームの間で共通の用語定義を持たせたい組織です。FabricのOntologyは、Customer、Order、Product、Sensor、Routeのような概念、プロパティ、関係、OneLake上の実データとのバインディングを定義する仕組みです。(Microsoft Learn)
特に向いているのは、次のようなケースです。
- 営業、製造、物流、店舗運営など、複数部門のデータをまたいでAIエージェントに回答させたい
- 既存のRAGでは「似た文書」は見つかるが、顧客・注文・在庫・設備の関係を正しく扱いにくい
- Power BIやOneLakeに蓄積したデータを、AIエージェントから業務用語で安全に参照させたい
- データの意味、単位、関係、制約をエージェントごとにプロンプトで説明する運用から脱却したい
一方、まだFabricワークスペースやOntologyを整備していない組織では、すぐに成果が出るとは限りません。Ontologyは単なるデータ接続ではなく、業務概念の設計とデータバインディングが品質を左右します。先に「どの業務質問に答えたいのか」「どのエンティティと関係が必要か」を決めてから検証するほうが失敗しにくくなります。
管理者が最初に確認すべき設定
導入前に確認すべきポイントは、Edgeのバージョンよりも、Fabric、Foundry、Azure AI Search、Microsoft Entra IDの権限まわりです。
| 確認項目 | 見るべき担当者 | 確認内容 |
|---|---|---|
| Fabricテナント設定 | Fabric管理者 | Ontology itemのプレビュー設定、Graph作成設定が有効か |
| Fabricワークスペース | Fabric管理者、データ管理者 | Ontology項目が存在し、必要なユーザーが読み取れるか |
| Foundryプロジェクト | Azure/AI管理者 | Foundryプロジェクト、モデル、エージェント作成権限があるか |
| Azure AI Search | Azure管理者、開発者 | agentic retrieval対応リージョンのSearchサービスを使っているか |
| Microsoft Entra ID | ID管理者 | 同じテナント内でSearchサービスとFabricワークスペースを扱えるか |
| Edge/Chrome環境 | Edge管理者、端末管理者 | 同じIDでFoundryとFabricの両方にサインインできるか |
| データ境界 | セキュリティ、法務、監査 | リージョン、コンプライアンス境界、プレビュー利用条件を確認したか |
Fabric Ontologyを利用するには、Fabricテナント側で「Enable Ontology item (preview)」が必要です。また、Ontologyに関連するGraphを使うには「User can create Graph」も必要です。これらが無効な場合、Ontology項目の作成やアクセス時にエラーが発生する可能性があります。(Microsoft Learn)
Azure AI Search側では、Fabric Ontology knowledge sourceの前提条件として、agentic retrievalを提供するリージョンのAzure AI Searchサービス、Ontology項目を持つMicrosoft Fabricワークスペース、同一Microsoft Entra IDテナント、ナレッジソースを作成する権限などが挙げられています。(Microsoft Learn)
開発者が押さえるべき実装の流れ
実装は大きく分けて、Ontologyの準備、ナレッジソースの作成、ナレッジベース化、エージェントへの接続、テストの順で進めます。Microsoft Learnの手順でも、OneLake上の既存Fabric IQ Ontology項目を指すナレッジソースを作成し、それをナレッジベースでラップして、Foundryエージェントに接続する流れが示されています。(Microsoft Learn)
実装手順の全体像
| 手順 | 作業 | 失敗しやすいポイント |
|---|---|---|
| 1 | Fabric側でOntologyを作成・公開する | エンティティ、プロパティ、関係、データバインディングが不完全 |
| 2 | FoundryまたはAPIでナレッジソースを作成する | workspaceId、ontologyId、権限の指定ミス |
| 3 | ナレッジソースをナレッジベースに追加する | 説明文が曖昧で、エージェントが参照タイミングを判断できない |
| 4 | エージェントにナレッジベースを接続する | システムプロンプトにFabric IQを使う条件が書かれていない |
| 5 | 実業務に近い質問で検証する | 回答は自然だが、根拠データや業務定義とずれている |
| 6 | 権限別にテストする | 開発者では見えるが一般ユーザーでは取得できない |
APIで作成する場合、ナレッジソース定義ではkindにfabricOntologyを指定し、FabricワークスペースIDとOntology IDを渡します。公式ドキュメントでは、workspaceIdとontologyIdがFabric Ontology knowledge source固有の必須パラメーターとして示されています。(Microsoft Learn)
{
"name": "sales-fabric-ontology-ks",
"kind": "fabricOntology",
"description": "Sales domain ontology for customers, orders, products, and store operations.",
"fabricOntologyParameters": {
"workspaceId": "{fabric-workspace-id}",
"ontologyId": "{fabric-ontology-id}"
}
}ナレッジベースの説明文は軽視しないでください。公式手順でも、ナレッジベースの説明は実行時にエージェントがそのナレッジベースを参照するタイミングを判断するために使われると説明されています。単に「Sales data」ではなく、「顧客、注文、店舗、商品、売上、設備テレメトリに関する質問ではこのナレッジベースを使う」のように、対象範囲を明確に書くことが重要です。(Microsoft Learn)
既存環境からの移行で注意すべきこと
この機能はプレビューです。既存の本番RAG、Azure AI Searchインデックス、Power BIレポート、データエージェントをいきなり置き換えるより、まずは限定された業務領域で並行検証するのが現実的です。
置き換えるのではなく、役割分担から始める
Fabric Ontology knowledge sourceは、文書検索のすべてを代替するものではありません。規程、マニュアル、議事録、FAQのような非構造化文書は従来のインデックス型ナレッジソースが向いています。一方で、顧客、注文、商品、設備、拠点、イベントのように「関係」が重要なデータはOntologyに向いています。
実務では、次のように分けると設計しやすくなります。
| 質問例 | 向いているナレッジソース |
|---|---|
| 「返品ポリシーの例外条件を教えて」 | SharePointやBlobなどの文書系ナレッジソース |
| 「今月、売上が落ちた店舗と関連する在庫状況を教えて」 | Fabric Ontology knowledge source |
| 「この製品カテゴリの最新マニュアルを要約して」 | ファイル・文書検索系ナレッジソース |
| 「特定顧客の注文履歴と担当営業の関係を説明して」 | Fabric Ontology knowledge source |
| 「社内規程と売上データを組み合わせて判断して」 | 複数ナレッジソースを持つナレッジベース |
Azure AI Searchのナレッジソースは、複数のナレッジソースを1つのナレッジベースで参照でき、取得時にサブクエリが生成される設計です。複数ソースを使う場合は、どの質問でどのソースを使うかを説明文や取得指示で明確にする必要があります。(Microsoft Learn)
Ontologyの品質が回答品質を決める
AIエージェントの回答が不安定な場合、モデルやプロンプトだけを調整しても限界があります。Fabric Ontologyでは、エンティティタイプ、プロパティ、関係、データバインディングが業務語彙の基盤になります。Microsoftの説明では、Ontologyはテーブルや列ではなく、概念、関係、ルール、データソースとの接続を持つビジネスコンテキストレイヤーとして位置付けられています。(Microsoft Learn)
例えば「優良顧客」という言葉を使うなら、単なる売上金額なのか、粗利、継続期間、解約リスク、地域、契約種別を含むのかをOntology上で明確にする必要があります。ここを曖昧にしたままエージェントに接続すると、自然な文章では答えるものの、部門ごとに期待と違う回答になりやすくなります。
セキュリティと権限で確認すべきポイント
Fabric Ontology knowledge sourceは、取得時にエンドユーザーのアクセストークンを利用するOBO、つまりon-behalf-ofのフローを使います。retrieveリクエストではAzure AI Searchの通常認証に加えて、x-ms-query-source-authorizationヘッダーでエンドユーザーのトークンを渡す必要があります。(Microsoft Learn)
ここで重要なのは、「開発者が見えるデータ」と「実際の利用者が見えるデータ」が一致するとは限らない点です。検証では、管理者、業務部門ユーザー、閲覧権限が限定されたユーザーなど、複数の権限パターンでテストしてください。
権限テストで見るべき観点
| テスト観点 | 確認する内容 |
|---|---|
| 認証 | EdgeまたはChromeで同じIDを使い、FoundryとFabricの両方にアクセスできるか |
| Fabric権限 | ユーザーが対象ワークスペースとOntology項目を読み取れるか |
| Search認証 | Azure AI Searchへのサービス認証とユーザートークンが別々に成立しているか |
| 最小権限 | 不要なFabricワークスペースやデータまで参照できないか |
| 監査 | どのユーザーがどのエージェント経由でどのデータにアクセスしたか追跡できる設計か |
| 同意 | Entra IDの管理者同意やユーザー同意フローが社内ポリシーでブロックされないか |
また、プレビューAPIや外部サービス接続では、データ処理や保存がAzureコンプライアンス境界の外に関係する場合があるとMicrosoftは注意喚起しています。Fabric IQに接続する場合のコスト、データフロー、地理的境界、承認は利用者側で管理する必要があります。(Microsoft Learn)
リージョン、データ所在地、ネットワークの注意点
Fabric IQは、Fabricワークスペースのリージョンに基づいてデータを取得・処理します。Azure AI SearchサービスとFabricワークスペースが異なるAzureリージョンにある場合、クエリ結果がリージョンをまたいで返される可能性があるため、データレジデンシー要件を事前に確認してください。(Microsoft Learn)
特に金融、医療、公共、製造業の機密データを扱う場合は、次の確認を導入判定に含めるべきです。
- Fabricワークスペースのリージョンが社内のデータ所在地ポリシーに合っているか
- Azure AI Search、Foundryプロジェクト、Fabricワークスペースの配置が監査要件に合っているか
- プレビュー機能を本番データで試すことが社内ルール上許可されているか
- クロスリージョンで返される可能性のある結果データを許容できるか
- 機密データを扱う場合、検証用データセットを匿名化・縮小できるか
「動いたから展開する」ではなく、「どの境界内で、誰が、どのデータに、どの用途でアクセスできるか」を明文化してから次の段階に進むことが重要です。
Edge管理者が見るべき展開上の注意点
Edge管理者の関与は限定的ですが、ゼロではありません。Foundryポータル、Fabricポータル、Microsoft Entra IDの同意フローを利用するため、企業管理のEdge環境でサインインやポップアップ、条件付きアクセス、拡張機能、プロキシ制御が影響する可能性があります。
公式手順では、FoundryプロジェクトとFabricワークスペースの両方にアクセスできる同じIDでサインインしているEdgeまたはChromeブラウザーが前提に含まれます。(Microsoft Learn) そのため、Edge管理者は次を確認しておくと導入時の切り分けがしやすくなります。
| 確認項目 | 実務上の見方 |
|---|---|
| サインイン状態 | 複数アカウントが混在していないか。FoundryとFabricで同じテナントのIDを使っているか |
| 条件付きアクセス | 管理対象デバイス、MFA、場所条件により、FabricまたはFoundryだけ失敗しないか |
| ブラウザー制御 | 社内プロキシや拡張機能がポータル画面、OneLakeカタログピッカー、同意画面を妨げないか |
| 検証端末 | 開発者端末だけでなく、標準業務端末のEdgeでも操作できるか |
| 問い合わせ対応 | 「Edgeの不具合」ではなく、ID・権限・テナント設定・プレビュー制限の可能性を切り分けられるか |
特に、開発者の個人環境では成功するのに、業務端末ではOneLakeカタログが表示されない、同意画面が完了しない、別テナントにサインインしてしまう、といった問題が起きやすい領域です。Edge管理者はAI機能そのものを設計するより、安定してポータル操作できる標準環境を用意する役割と考えるとよいでしょう。
よくあるトラブルと原因
Fabric IQ連携では、エラーの原因がブラウザー、Entra ID、Fabric設定、Foundry設定、Ontology設計のどこにあるのか分かりにくくなります。MicrosoftのFabric IQ接続ドキュメントでは、404、401、同意エラー、空または不正確な結果、エージェントがFabric IQツールを呼ばないケースがトラブル例として挙げられています。(Microsoft Learn)
| 症状 | 主な原因 | 対応 |
|---|---|---|
| Ontology項目を作成できない | FabricテナントでOntology preview設定が無効 | Fabric管理ポータルでOntology item設定を確認 |
| Ontologyへアクセスするとエラーになる | Graph作成設定が無効 | 「User can create Graph」を確認 |
| OneLakeカタログで対象Ontologyが見えない | サインインIDに読み取り権限がない | FabricワークスペースとOntology項目の権限を確認 |
| 404またはNot Found | ID指定ミス、対象Fabric項目が未公開 | workspaceId、ontologyId、公開状態を確認 |
| 401 Unauthorized | Entraアプリ、管理者同意、スコープ設定の問題 | API権限、同意、クライアント設定を確認 |
| 回答が空、または業務定義とずれる | エンティティ、プロパティ、関係、データバインディングが不完全 | Ontology設計を見直し、実データで検証 |
| エージェントがOntologyを使わない | ナレッジベース説明やシステムプロンプトが曖昧 | 「業務データの質問ではFabric IQを使う」と明示 |
| 新しいデータが反映されない | 上流データ更新後にOntology側の更新が反映されていない | Ontologyの更新・リフレッシュ手順を確認 |
Ontologyでは、上流データソースに新しい行が追加された場合でも、Ontology項目で見えるようにするには手動更新が必要なケースがあると説明されています。最新データを前提にするエージェントでは、データ更新タイミングと回答の鮮度を必ず確認してください。(Microsoft Learn)
導入判断の基準
このプレビューを試すべきかどうかは、「AIエージェントに業務データを自然言語で聞けるか」だけで判断しないほうが安全です。次の条件を満たすほど、検証価値が高くなります。
| 判断基準 | 試す価値が高い状態 | まだ早い状態 |
|---|---|---|
| Fabric利用状況 | OneLakeやPower BIを含むFabric活用が進んでいる | Fabricワークスペースが未整備 |
| 業務語彙 | 顧客、注文、商品などの共通定義がある | 部門ごとに同じ言葉の意味が違う |
| Ontology設計 | エンティティ、関係、データバインディングを設計できる | テーブルをそのままAIに渡したいだけ |
| セキュリティ | ユーザー権限別の検証計画がある | 管理者アカウントだけで検証する予定 |
| 本番適用 | プレビューとして限定PoCから始める | 既存本番RAGをすぐ置き換えたい |
| Edge環境 | 管理対象Edgeでポータル操作と認証を検証できる | 開発者PCだけで成功確認して終える |
特に重要なのは、Ontologyを「AI用の飾り」ではなく「業務用語の契約」として扱うことです。ここが整っていれば、エージェントごとに複雑なプロンプトで業務定義を説明する必要が減り、回答の一貫性を高めやすくなります。
管理者・開発者向けの確認チェックリスト
導入前には、次の順番で確認すると手戻りを減らせます。
| フェーズ | チェック内容 |
|---|---|
| 事前整理 | 対象業務、想定質問、利用ユーザー、扱うデータ分類を決める |
| Fabric準備 | Ontology preview設定、Graph設定、ワークスペース、Ontology項目、データバインディングを確認 |
| Foundry準備 | Foundryプロジェクト、モデル、エージェント作成権限、ナレッジベース設計を確認 |
| Search準備 | Azure AI Searchサービス、APIバージョン、権限、同一Entra IDテナントを確認 |
| Edge確認 | 管理対象Edgeで同じIDによるFoundry/Fabricサインインと同意フローを検証 |
| セキュリティ確認 | ユーザー別アクセス、データレジデンシー、監査、プレビュー利用可否を確認 |
| 品質検証 | 正解が分かっている質問、権限差が出る質問、曖昧な質問でテスト |
| 展開判断 | 本番導入ではなく、限定ユーザー・限定データ・限定業務で段階展開 |
まず取るべき次のアクション
今回の「Public Preview: Fabric IQ Ontology Knowledge Source in Microsoft Foundry IQ」は、Edgeの新機能として追うより、Fabricで整備した業務セマンティックレイヤーをエージェントの知識源にできるプレビュー機能として評価するのが正確です。
最初にやるべきことは、社内のFabricワークスペースに検証可能なOntologyがあるかを確認することです。次に、Fabricテナント設定、Graph設定、Foundryプロジェクト、Azure AI Search、Entra ID権限、EdgeまたはChromeでの同一IDサインインを確認します。そのうえで、既存RAGを置き換えるのではなく、1つの業務領域に絞って「業務用語で聞いた質問に、権限を守って、根拠ある回答が返るか」を検証してください。
プレビュー段階では、成功条件を「動くこと」ではなく「権限、データ境界、回答品質、運用担当が説明できること」まで含めて定義するのが安全です。
コメント