Azure AI Foundryの「Use Foundry Tools in Fabric」は、Microsoft Fabric上でFoundry Toolsを使い、データ分析・データサイエンス・AIアプリ開発に生成AIやテキスト分析、翻訳などを組み込むための公式ガイドです。結論から言うと、まずはFabricの事前構築済みAIモデルで要件を満たせるかを確認し、未対応のFoundry Toolsや既存のAzureリソースを使いたい場合にBYOKを選ぶのが現実的です。
管理者が先に確認すべきポイントは、プレビュー機能であること、Fabric容量への課金、リージョンとクロスgeo処理、テナント設定、使用量監視です。開発者は、AI Functions、SynapseML、REST API、Python SDK、BYOKの使い分けと、モデル・消費率・退役日の変更に備えた実装を確認する必要があります。Microsoft LearnではFoundry Tools in Fabricをプレビュー機能として位置付け、利用方法を「Fabricの事前構築済みAIモデル」と「BYOK」の2つに整理しています。(Microsoft Learn)
Azure AI FoundryのUse Foundry Tools in Fabricで何ができるのか
Use Foundry Tools in Fabricは、FabricのNotebookやデータ処理ワークロードからFoundry Toolsを利用するための入口です。Foundry Toolsは、以前Azure Cognitive Servicesと呼ばれていた機能群の流れをくむもので、事前構築済みのAPIやモデルを使って、見る、聞く、話す、理解する、推論するといったAIアプリケーション開発を支援します。(Microsoft Learn)
Fabricでは、主に次の2つの使い方があります。
| 利用方法 | 概要 | 向いているケース |
|---|---|---|
| Fabricの事前構築済みAIモデル | Fabric認証でFoundry Toolsにアクセスし、使用量はFabric容量に対して課金される | まず小さく試したい、キー管理を簡素化したい、Fabric内の分析処理にAIを組み込みたい |
| BYOK | Azure上でFoundry Toolsをプロビジョニングし、自分のキーをFabricに持ち込んで使う | 事前構築済みモデルで未対応のツールを使いたい、既存のAzure AIサービス契約・キーを活用したい |
公式情報では、Fabricの事前構築済みAIモデルとしてAzure OpenAI Service、Text Analytics、Translatorが示されており、SynapseMLとREST APIに対応しています。Azure OpenAI ServiceについてはOpenAI Python Libraryから利用する方法も案内されています。(Microsoft Learn)
重要なのは、「FabricでFoundry Toolsが使える」といっても、すべてのFoundry ToolsがFabricの事前構築済みモデルとしてそのまま使えるわけではない点です。プレビュー段階では利用できるMicrosoft Foundry toolsが限定されるため、対象サービスを必ず公式表で確認してください。
変更点として押さえるべきポイント
2026年5月時点の公式ドキュメントでは、Foundry Tools in Fabricの説明が、利用方法、対象モデル、消費率、使用量監視を中心に整理されています。GitHub上のMicrosoftDocs/fabric-docsの履歴では、2026年4月30日にモデル退役日の更新、2026年5月12日にgpt-5.1とgpt-5-miniの追加が記録されています。モデルや消費率は変わり得るため、記事・設計書・運用手順に固定値として書きっぱなしにしないことが重要です。(GitHub)
| 確認項目 | 変更・確認ポイント | 実務上の影響 |
|---|---|---|
| 機能ステータス | Foundry Tools in Fabricはプレビュー | 本番利用前に仕様変更・リージョン制約・サポート条件を確認する |
| 利用経路 | 事前構築済みAIモデルとBYOKの2系統 | キー管理、課金、対応ツール、運用責任が変わる |
| 対象サービス | Azure OpenAI Service、Text Analytics、Translatorが中心 | Vision、Speech、Document IntelligenceなどはBYOKや別方式を検討する |
| 課金 | 事前構築済みAIサービスはFabric容量のCopilot and AIメーターに請求 | Spark処理のコストとは分けて予測・監視する |
| 使用量監視 | Capacity Metrics appでAI ServicesとAI Functionsの使用状況を確認 | 容量超過、スロットリング、想定外のAI利用を検知しやすくなる |
| モデル・消費率 | 消費率やモデル一覧は随時変更される可能性がある | モデル名、退役日、CU消費を定期確認する |
公式ドキュメントでは、消費率は変更される可能性があり、変更はMicrosoft Release NotesやMicrosoft Fabric Blogに記載された日付で有効になると説明されています。また、AIサービス利用に必要なCUが大幅に増える場合、支払い方法に応じたキャンセルオプションを利用できる旨も示されています。(GitHub)
管理者が最初に確認すべき設定
Fabric容量とテナント設定を確認する
FabricでAI Functionsや組み込みAIエンドポイントを使う場合、管理者側の設定確認が欠かせません。AI Functionsの前提条件として、CopilotおよびAzure OpenAIを利用する機能に関するテナントスイッチの有効化、必要に応じたクロスgeo処理の設定、有料Fabric容量が挙げられています。公式ドキュメントでは、AI FunctionsはFabric Runtime 1.3以降でサポートされることも示されています。(Microsoft Learn)
特に日本リージョンでFabricを使っている組織は、Azure OpenAI関連機能のデータ処理場所を確認してください。Copilot in Fabricの公式情報では、Fabric容量がUSまたはEU Data Boundary以外にある場合、管理者がクロスgeo処理のテナント設定を有効にしない限り、Copilotが既定で無効になるケースが説明されています。入力・出力のプロンプト、メタプロンプト、スキーマ、会話履歴などが処理対象になり得るため、社内のデータ分類ルールと照らし合わせる必要があります。(Microsoft Learn)
Capacity Metrics appでAI利用を見える化する
Foundry Tools in Fabricを展開する前に、Microsoft Fabric Capacity Metrics appを確認できる状態にしておきましょう。このアプリはFabric容量の消費状況を監視するためのもので、容量管理者がインストール・閲覧できます。ComputeページではAI FunctionsがSparkやDataflows Gen2とは別の操作カテゴリとして表示されるため、AI利用による負荷や消費傾向を把握しやすくなります。(Microsoft Learn)
事前構築済みAIサービスは、Fabric容量のCopilot and AIメーターに対して課金されます。一方、NotebookやSparkジョブの実行に使うSparkコンピューティングはSpark課金メーターで報告されます。つまり、AIを使ったNotebookのコストは「Spark処理」と「AI呼び出し」に分かれるため、片方だけ見ているとコスト見積もりを誤ります。(GitHub)
開発者はAI Functions、SynapseML、REST API、Python SDKをどう使い分けるか
開発者にとっての判断軸は、「何を処理するか」「どれくらいの規模か」「どこまで制御したいか」です。
| 方法 | 使いどころ | 注意点 |
|---|---|---|
| AI Functions | pandasやPySpark DataFrameに対して、分類、要約、翻訳、抽出などを少ないコードで実行したい | 利用できる関数・モデル・言語最適化の範囲を確認する |
| SynapseML | Spark DataFrameで大規模データを分散処理したい | ライブラリ、実行環境、課金、エラー処理を設計する |
| REST API | アプリやパイプラインから直接APIを呼び出したい | 認証、リトライ、レート制御、ログ出力を実装する |
| Python SDK | 単一のAPI呼び出しを細かく制御したい | SDKバージョン、モデル名、例外処理を管理する |
| BYOK | Fabricの事前構築済みモデルでは足りないFoundry Toolsを使いたい | Azure側のリソース、キー、リージョン、コスト管理が必要 |
Fabric AI Functionsは、ai.analyze_sentiment、ai.classify、ai.embed、ai.extract、ai.generate_response、ai.summarize、ai.translateなどを提供し、pandasやSparkのデータ処理に組み込みやすい形でAIを利用できます。画像、PDF、テキストファイルなどのマルチモーダル入力にも対応する説明がありますが、利用できる関数や設定は公式ドキュメントで確認してください。(Microsoft Learn)
一方、BYOKでSynapseMLを使う方法は、Vision、Speech、特殊なDocument Intelligence、既存のAzure AIサービスサブスクリプションを使いたい場合に向いています。公式ガイドでも、一般的なテキスト操作にはAI Functions、ビジョン・音声・特殊なドキュメントフォーム・既存Azure AIサービス契約がある場合にはBYOKでのSynapseML利用、という使い分けが示されています。(Microsoft Learn)
移行・既存環境で注意すべき点
Azure Cognitive Services表記を機械的に置き換えない
Foundry Toolsは以前Azure Cognitive Servicesと呼ばれていた領域を含みますが、既存コードを一括で「Foundry」に置き換えるのは危険です。たとえばBYOKのSynapseMLサンプルでは、from synapse.ml.cognitive import *のようなインポートが使われています。名称やドキュメント上の表現が変わっても、コード上のパッケージ名やクラス名が同時に変わるとは限りません。(Microsoft Learn)
移行時は、次の順で棚卸しすると失敗しにくくなります。
| 確認対象 | 見るべきポイント |
|---|---|
| Notebook | Azure OpenAI、Text Analytics、Translator、SynapseML、AI Functionsの呼び出し箇所 |
| モデル名 | デプロイ名をハードコードしていないか、退役日が近いモデルを使っていないか |
| 課金 | Fabric容量課金、Spark課金、Azure側のBYOK課金が混在していないか |
| キー管理 | BYOKのサブスクリプションキーをNotebookに平文で保存していないか |
| リージョン | Fabricホームリージョン、Azure OpenAI処理リージョン、クロスgeo設定 |
| 監視 | Capacity Metrics app、ログ、エラー率、実行時間、出力品質の確認方法 |
特にモデル名と消費率は、運用開始後に変わる可能性があります。公式表ではモデルごとのコンテキストウィンドウ、入力・出力のCU秒、退役日が掲載されるため、処理設計や見積もりに使う場合は定期確認を前提にしてください。(GitHub)
「Fabric容量に課金される」だけでコストを判断しない
Fabricの事前構築済みAIサービスはCopilot and AIメーターに報告されますが、NotebookやSparkジョブの実行自体はSpark課金メーター側に残ります。たとえばPySpark Notebookで数百万件のレビューを分類する場合、Notebook実行のCU消費と、ai.classifyなどAI関数呼び出しのCU消費は分けて報告されます。(GitHub)
実務では、PoCの段階から以下を記録しておくと、後の本番見積もりが楽になります。
| 記録する項目 | 理由 |
|---|---|
| 入力行数・文字数・トークン量 | AI呼び出しの消費量に影響する |
| モデル名・関数名 | 消費率や出力品質の差を比較できる |
| Spark実行時間 | AI以外の処理コストを把握できる |
| エラー率・再実行回数 | リトライによる追加コストを見積もれる |
| 出力の修正率 | 実運用で人手レビューが必要か判断できる |
展開前に確認したい実務チェックリスト
Foundry Tools in Fabricを社内展開する前に、管理者と開発者で次の項目を確認してください。
| 領域 | チェック項目 |
|---|---|
| 機能ステータス | プレビュー機能として扱い、仕様変更時の対応者を決めているか |
| 権限 | Fabric容量管理者、Notebook作成者、データ閲覧者の権限が整理されているか |
| テナント設定 | Copilot/Azure OpenAI関連機能、クロスgeo処理、会話履歴に関する設定を確認したか |
| リージョン | FabricホームリージョンとAI処理リージョンの違いを説明できるか |
| 利用方式 | 事前構築済みAIモデルで足りるか、BYOKが必要か判断したか |
| 実装 | AI Functions、SynapseML、REST API、Python SDKのどれを使うか決めたか |
| コスト | Copilot and AIメーターとSparkメーターを分けて見積もったか |
| 監視 | Capacity Metrics appでAI Services、AI Functions、Sparkの消費を確認できるか |
| セキュリティ | BYOKのキーを安全に管理し、Notebookに平文で残していないか |
| 品質 | AI出力をレビューし、必要に応じて評価用Notebookや検証データを用意したか |
AI Functionsの公式情報では、出力品質を評価するための評価Notebookが用意され、accuracy、precision、recall、F1、coherence、consistency、relevanceなどの指標を使った検証に触れられています。業務データにAIを適用する場合は、実装できたかどうかだけでなく、「業務判断に使える品質か」を展開前に確認してください。(Microsoft Learn)
よくある失敗と回避策
Fabricで使えるから全社展開してよいと考える
Foundry Tools in Fabricは便利ですが、プレビュー機能です。まずは部門限定のPoCで、リージョン、権限、課金、ログ、出力品質を確認しましょう。特に個人情報、機密文書、顧客対応文面、医療・金融・法務の判断に関わるデータでは、AI出力をそのまま最終判断に使わない運用が必要です。
BYOKを選ぶ理由を決めないまま始める
BYOKは柔軟ですが、キー管理、Azure側のリソース管理、リージョン、コスト、監査の責任が増えます。Text Analyticsや翻訳など、Fabricの事前構築済みAIモデルやAI Functionsで要件を満たせるなら、まずはそちらを検証した方が運用は軽くなります。BYOKは、Vision、Speech、特殊なDocument Intelligence、既存Azure AIサービス契約の活用など、明確な理由がある場合に選ぶべきです。(Microsoft Learn)
日本リージョンだからデータ処理も日本内だけだと思い込む
Azure OpenAI関連機能では、Fabric容量の地理的リージョンと実際のAI処理リージョンが一致しない場合があります。日本を含むUS/EU Data Boundary外の地域では、クロスgeo処理設定が必要になるケースがあるため、セキュリティ部門や法務部門と事前に確認してください。(Microsoft Learn)
コスト監視を後回しにする
AI機能は、小さなテストでは問題がなくても、大量データに適用した瞬間に消費量が増えます。たとえば「全レビューを分類する」「全PDFを抽出する」「全問い合わせ文を要約する」といった処理は、入力件数と文字数に比例してAI呼び出しが増えます。PoCの時点からCapacity Metrics appでCopilot and AIメーターを確認し、Spark消費と分けて記録しましょう。
まず取るべき次の行動
Use Foundry Tools in Fabricを検討している場合、最初にやるべきことは機能の試用ではなく、利用シナリオの切り分けです。具体的には、対象データ、必要なAI処理、処理件数、許容コスト、データ処理リージョン、求める出力品質を1枚に整理してください。
そのうえで、次の順に進めると安全です。
| 手順 | 実施内容 |
|---|---|
| 1 | 既存のNotebook、Azure AIサービス、SynapseML利用箇所を棚卸しする |
| 2 | 事前構築済みAIモデルで足りるか、BYOKが必要か判断する |
| 3 | 管理者がFabric容量、テナント設定、クロスgeo処理、Capacity Metrics appを確認する |
| 4 | 小規模データでPoCを行い、出力品質とCU消費を記録する |
| 5 | 本番展開前にモデル名、消費率、退役日、監視方法、レビュー体制を運用手順に落とし込む |
Azure AI FoundryのUse Foundry Tools in Fabricは、Fabric上のデータ活用にAIを組み込む有力な選択肢です。ただし、プレビュー、課金、リージョン、モデル変更、BYOKの責任範囲を理解せずに展開すると、コストやガバナンスでつまずきます。まずは「Fabricの事前構築済みAIモデルで足りるか」を確認し、足りない部分だけBYOKやSynapseMLを使う設計にすると、導入後の運用負荷を抑えやすくなります。
コメント