Microsoft developer platform documentation updateで2026年5月5日に反映された「fix: Set default data source as lakehouse when Use Data agent flag」は、見た目は小さな修正ですが、Data Agentの作成方法に影響する変更です。結論から言うと、--datasource-typeを明示せずにスクリプトを実行している場合、既定のデータソースがontologyからlakehouseに変わる可能性があります。
特に確認すべきなのは、Microsoft Fabric Data Agentを使う検証環境、CI/CD、社内手順書、ワークショップ用のセットアップ手順です。Ontologyを前提にした構成であれば、--datasource-type ontologyを明示してください。Lakehouseを使う構成であれば、今回の変更は初期構築を分かりやすくする方向の修正です。
このPull Requestは、2026年5月5日にMicrosoftのGitHubリポジトリでマージされ、リリースv1.22.4にも含まれています。変更対象は主にscripts/02_create_fabric_items.pyとscripts/07_test_agent.pyの2ファイルです。(GitHub)
Microsoft developer platform documentation updateで何が変わったのか
今回の更新は、Microsoft developer platformそのものの大規模な仕様変更というより、Microsoft FabricとMicrosoft Foundryを使うソリューションアクセラレーター内のスクリプト挙動を実務向けに調整したものです。
主な変更点は次の3つです。
| 変更点 | 変更前 | 変更後 | 実務上の意味 |
|---|---|---|---|
| Data Agent作成時の既定データソース | ontology | lakehouse | 引数を省略するとLakehouseをデータソースにしたData Agentが作られやすくなる |
| エージェントテスト時の会話管理 | 会話IDを明示的に扱わない流れ | OpenAIクライアントで会話を作成し、conversation_idを渡す | 複数ターンの会話コンテキストを維持しやすくなる |
| テスト終了時の後処理 | クライアントや会話リソースの後処理が限定的 | 会話削除と非同期クライアントのクローズを追加 | 未クローズセッション警告や不要な会話リソースを減らしやすい |
Pull Requestの説明では、scripts/02_create_fabric_items.pyの--datasource-type既定値をontologyからlakehouseへ変更し、scripts/07_test_agent.pyでは会話作成、会話IDの受け渡し、会話削除、非同期クライアントのクローズが追加されたとされています。(GitHub)
影響を受けやすいユーザー
今回のMicrosoft developer platform documentation updateで最も影響を受けるのは、Data Agent作成スクリプトを「引数なし」または「最小引数」で実行しているチームです。
具体的には、次のようなケースでは確認が必要です。
| 対象 | 確認すべき理由 |
|---|---|
scripts/02_create_fabric_items.pyを手順書どおりに実行している人 | --datasource-typeを省略していると、以前と違うデータソース構成になる可能性がある |
| CI/CDや検証環境でスクリプトを自動実行しているチーム | 既定値変更により、生成されるData Agentのデータソースが変わる可能性がある |
| Ontologyを前提にデモやワークショップを作っている人 | Lakehouse接続では、Ontology上のビジネス概念や関係性を前提にした質問が期待どおりに動かない可能性がある |
| Data Agentの会話テストを自動化している開発者 | conversation_idを使う流れになったため、SDKや認証、後処理の確認が必要になる |
一方で、すでに--datasource-type lakehouseまたは--datasource-type ontologyを明示している場合、既定値変更による影響は限定的です。また、Data Agent作成をスキップしている場合も、データソース既定値の影響は受けにくいと考えられます。
Lakehouseが既定になった意味
今回の変更で重要なのは、「LakehouseとOntologyのどちらが優れているか」ではありません。用途が違います。
Microsoft Fabric Data Agentは、Lakehouse、Warehouse、Power BI semantic model、KQL database、Ontologyなど複数のデータソースに対応しています。Microsoftのドキュメントでは、Data Agentがユーザーの質問に応じて適切なデータソースを判断し、SQL、DAX、KQLなどのクエリ生成・実行を行う仕組みが説明されています。(Microsoft Learn)
Lakehouseを既定にするメリットは、初期検証やサンプル実行で扱いやすいことです。データがDeltaテーブルとして用意されていれば、SQL Analytics Endpoint経由で自然言語からSQLに近い形で問い合わせやすくなります。Fabric Data Agentのデータソース追加ドキュメントでも、LakehouseはSQL系データソースとして扱われ、NL2SQLの流れで利用されることが示されています。(Microsoft Learn)
一方、Ontologyは業務概念や関係性を明示したい場合に向いています。Fabric IQのドキュメントでは、Data AgentがOntologyをソースとして接続し、業務概念を理解して回答に使えることが説明されています。(Microsoft Learn)
LakehouseとOntologyの選び方
Data Agentのデータソースは、デモの成功率だけでなく、本番運用時の説明責任や保守性にも関わります。迷った場合は、次の基準で選ぶと判断しやすくなります。
| 観点 | Lakehouseを選ぶべきケース | Ontologyを選ぶべきケース |
|---|---|---|
| 主な目的 | まず動かす、テーブルに対して自然言語で質問する | 業務用語、関係性、ドメイン知識を反映したい |
| データ構造 | テーブル名・列名が分かりやすい | 複数テーブルの関係や業務概念の整理が必要 |
| 初期構築 | 比較的シンプル | Ontology作成・バインド・更新管理が必要 |
| 質問例 | 「売上が高い商品を教えて」 | 「優良顧客に影響している要因を関係性から見たい」 |
| 注意点 | 列名が曖昧だと回答精度が落ちやすい | Preview機能やGraph設定、更新タイミングの確認が必要 |
実務では、最初はLakehouseでData Agentの動作を確認し、業務部門が使う言葉とテーブル構造の差が大きくなってきたらOntologyを検討する流れが現実的です。
移行時にまず確認すべき設定
今回の変更で失敗しやすいのは、「以前と同じコマンドを実行しているのに、作られるData Agentの前提が変わる」ケースです。既存環境を壊さないために、最初にスクリプト実行箇所を確認してください。
--datasource-typeを明示する
Ontologyを使うなら、次のように明示します。
python scripts/02_create_fabric_items.py --datasource-type ontologyLakehouseを使うなら、こちらも明示しておくと、将来の既定値変更や手順書の読み違いを防げます。
python scripts/02_create_fabric_items.py --datasource-type lakehouseポイントは、「既定値に任せない」ことです。検証環境では省略しても動くことがありますが、チーム運用では意図がコードに残りません。特にGitHub Actions、Azure DevOps、社内のPowerShellスクリプト、README、ワークショップ資料では、明示的に書いておく方が安全です。
自動化スクリプト内の呼び出しを検索する
LinuxやmacOSでは、次のように検索できます。
grep -R "02_create_fabric_items.py" .
grep -R "--datasource-type" .Windows PowerShellでは、対象ファイルを絞って確認すると効率的です。
Select-String -Path .\**\*.ps1,.\**\*.md,.\**\*.yml,.\**\*.yaml -Pattern "02_create_fabric_items.py","--datasource-type"02_create_fabric_items.pyの呼び出しが見つかったのに--datasource-typeがない場合は、LakehouseとOntologyのどちらを前提にしているかを確認し、引数を追加してください。
既存のData Agentは自動で切り替わらないと考える
今回の変更は、主に「スクリプトでData Agentを作成する際の既定値」に関するものです。すでに作成済みのFabric Data Agentが、Pull RequestのマージだけでOntologyからLakehouseへ自動変換されるわけではありません。
ただし、環境を作り直す、--clean相当の操作を行う、CI/CDで再作成する、といった運用では影響が出ます。再作成後は、Fabricワークスペース上でData AgentのデータソースがLakehouseになっているのか、Ontologyになっているのかを必ず確認してください。
エージェントテストスクリプトで確認すべき点
今回のPRでは、scripts/07_test_agent.pyにも変更が入っています。テスト開始時にAIProjectClientを初期化し、OpenAIクライアントから会話を作成し、そのconversation_idをチャット処理に渡す流れが追加されました。Pull Requestの差分では、テスト終了時に会話を削除し、非同期クライアントを閉じる処理も確認できます。(GitHub)
MicrosoftのAzure AI Projectsクライアントライブラリでは、AIProjectClient.get_openai_client()を使って認証済みのOpenAIクライアントを取得し、ResponsesやConversationsなどの操作に使えると説明されています。(Microsoft Learn)
確認すべきポイントは次のとおりです。
| 確認項目 | 見るべき内容 |
|---|---|
| SDKバージョン | azure-ai-projectsなど、必要なパッケージがConversations操作に対応しているか |
| 認証 | az loginやマネージドIDなど、Foundry/Fabric側にアクセスできる資格情報になっているか |
| 会話の継続性 | 1問目の内容を踏まえて2問目に回答できるか |
| 後処理 | テスト終了時に会話削除やクライアントクローズで警告が出ないか |
| エラー処理 | 会話削除に失敗した場合、警告として扱われるか、テスト全体を止めるべきか |
開発チームでは、単に「返答が出たか」だけでなく、会話の文脈が維持されるかをテスト項目に入れるべきです。たとえば、1問目で「売上上位の商品」を聞き、2問目で「その中で利益率が高いものは？」と続けて質問すると、会話IDの受け渡しが効いているかを確認しやすくなります。
権限とガバナンスで見落としやすい点
Data AgentのデータソースがLakehouseになると、確認すべき権限も変わります。MicrosoftのData Agent共有・権限管理ドキュメントでは、LakehouseはRead権限、OntologyはOntologyアイテムへのReadに加えて、バインドされた基盤データソースへのRead権限が必要と説明されています。(Microsoft Learn)
| データソース | 最低限確認したい権限 | よくある失敗 |
|---|---|---|
| Lakehouse | LakehouseアイテムへのRead、必要に応じてテーブルアクセス | Data Agentは作れたが、特定テーブルの質問で失敗する |
| Ontology | OntologyへのReadと、基盤のLakehouse・Semantic model・KQL databaseなどへのRead | Ontologyは見えるが、実データへの問い合わせで失敗する |
| Power BI semantic model | Data Agent経由の問い合わせではRead権限を確認 | Build権限が必要だと思い込み、過剰権限を付与する |
| Warehouse | 対象テーブルへのSELECT権限 | スキーマは見えるがクエリ実行で失敗する |
権限エラーが出たときに、すぐ管理者権限を付与するのは避けてください。Data Agentはデータアクセスを扱うため、最小権限を守る方が安全です。まずは、対象データソースにReadまたはSELECT相当の権限があるかを確認しましょう。
変更後に実施したい動作確認
移行や設定変更後は、次の順番で確認すると問題を切り分けやすくなります。
| 手順 | 確認内容 | 合格基準 |
|---|---|---|
| スクリプト実行 | --datasource-typeを明示して実行 | 想定どおりのData Agentが作成される |
| Fabric上の確認 | Data Agentのデータソースを見る | LakehouseまたはOntologyが意図どおり選ばれている |
| 単発質問 | テーブルや業務項目に関する質問をする | 正しいデータソースを参照した回答が返る |
| 追跡質問 | 前の質問を踏まえた質問をする | 会話コンテキストを維持して回答する |
| 権限テスト | 権限の異なるユーザーで質問する | 見えるべきデータだけにアクセスできる |
| 後処理確認 | テスト終了ログを見る | 会話削除やクライアント終了で不要な警告が出ない |
特に重要なのは、Data Agentの回答精度だけで判断しないことです。回答が自然に見えても、想定外のデータソースを参照している場合があります。LakehouseとOntologyの両方を作成している環境では、Data Agentの設定画面や定義ファイルを確認し、どちらが接続されているかを明確にしてください。
よくある失敗と対策
引数省略のまま本番手順にしてしまう
検証時は引数省略でも問題なく動くことがあります。しかし、今回のように既定値が変わると、同じコマンドでも結果が変わります。
対策はシンプルです。手順書、README、CI/CD、社内Wikiでは必ず次のどちらかを書きます。
--datasource-type lakehouseまたは
--datasource-type ontologyOntology前提の質問をLakehouseに投げてしまう
Ontologyでは、業務概念や関係性を使って質問できる構成を作れます。一方、Lakehouseではテーブル名や列名の品質が回答精度に直結します。
たとえば、Ontologyで「重点顧客」「影響度」「関連設備」といった業務用語を定義していた場合、Lakehouseに切り替えると、同じ質問が期待どおり解釈されない可能性があります。Lakehouseを使う場合は、テーブル名・列名・Data Agentの指示文・few-shot例を見直してください。
既存環境と新規環境の挙動を混同する
既存のData Agentを使っている環境ではOntology、新しく作り直した環境ではLakehouse、という混在が起きる可能性があります。これが最も見落としやすいポイントです。
チームで検証する場合は、環境ごとに次の情報を記録しておくと混乱を防げます。
| 記録項目 | 例 |
|---|---|
| リポジトリのバージョン | v1.22.4 |
| 実行したコマンド | python scripts/02_create_fabric_items.py --datasource-type lakehouse |
| Data Agent名 | dataagent_xxx |
| 接続データソース | LakehouseまたはOntology |
| 検証した質問 | 売上、顧客、商品など |
| 検証者と日付 | 2026年5月5日以降の確認日 |
会話管理の変更を単発テストだけで判断する
scripts/07_test_agent.pyの変更は、単発質問では効果が分かりにくい部分です。会話IDを使う意味は、複数ターンのやり取りで文脈を維持することにあります。
そのため、テストでは次のような連続質問を使うと確認しやすくなります。
1問目: 売上が高い商品カテゴリを3つ教えて
2問目: その中で利益率が最も高いものは？
3問目: その理由をデータの観点で説明して2問目以降で「その中で」という文脈を正しく扱えない場合は、会話IDの受け渡し、SDK、エージェント実行オプション、認証状態を確認してください。
開発チーム向けチェックリスト
今回の更新を受けて、開発チームでは次のチェックを行うと安全です。
| チェック項目 | 対応 |
|---|---|
| リリース確認 | v1.22.4以降を使っているか確認する |
| コマンド確認 | --datasource-typeを明示する |
| 手順書更新 | 「既定はOntology」と書かれた古い説明を修正する |
| Data Agent確認 | Fabric上で接続先がLakehouseかOntologyか確認する |
| 質問例確認 | Lakehouse向け、Ontology向けで質問例を分ける |
| 権限確認 | ReadやSELECTなど最小権限で動くか確認する |
| 会話テスト | 複数ターンの質問で文脈維持を確認する |
| ロールバック方針 | Ontologyへ戻す場合のコマンドと再作成手順を決めておく |
まとめ：既定値に頼らず、Data Agentの接続先を明示する
今回のMicrosoft developer platform documentation updateは、Data Agent作成時の既定データソースをLakehouseに寄せる変更です。初期検証やテーブル中心の分析では扱いやすくなりますが、Ontologyを前提にした構成では注意が必要です。
対応としては、まず自分たちの手順やCI/CDで--datasource-typeを省略していないか確認してください。Lakehouseを使うなら--datasource-type lakehouse、Ontologyを使うなら--datasource-type ontologyを明示します。そのうえで、Fabric上のData Agent接続先、権限、複数ターンの会話テストを確認すれば、今回の変更による意図しない差分を抑えられます。
小さな既定値変更でも、AIエージェントの回答元データが変わると、検証結果や利用者体験に影響します。公開手順や運用手順では「何を既定にするか」ではなく、「どのデータソースを使うかを明示する」ことを基準にしてください。
コメント