Azure AI Foundryで「Fireworks models on Microsoft Foundry (preview)」を使う場合、最初に押さえるべき結論は、これは本番移行を急ぐ機能ではなく、Fireworks AIが提供するオープンウェイトモデルやカスタムモデルをFoundryプロジェクト内で検証・展開するためのパブリックプレビューだという点です。利用には、Azureサブスクリプション単位でのプレビュー機能登録、Foundryプロジェクトの権限、対応リージョン、データ共有・コンプライアンス要件の確認が必要です。公式ドキュメントでは、プレビュー機能はSLAなしで提供され、本番ワークロードには推奨されないと説明されています。(Microsoft Learn)
公式ページ名は「Fireworks models on Microsoft Foundry (preview)」ですが、日本語圏ではAzure AI Foundryの更新情報として探す読者も多いため、本記事ではAzure AI Foundry／Microsoft Foundryを併記します。特に管理者は「有効化してよいか」、開発者は「どのモデルを、どのデプロイ方式で、どの制約のもと使うか」を切り分けて確認することが重要です。
Azure AI FoundryのFireworks models on Microsoft Foundryとは
Fireworks models on Microsoft Foundryは、Fireworks AIとの統合により、Foundryのモデルカタログやプロジェクト管理の中でオープンウェイトモデルを扱えるようにするプレビュー機能です。公式ドキュメントでは、Azureから直接提供される前の新しいオープンソースモデルを試せること、独自モデルの重みをインポートしてFireworksのGPU基盤にデプロイできること、プロビジョニング済みスループットでスケールできることが説明されています。(Microsoft Learn)
ポイントは、Fireworks AIを単体で使うのではなく、Foundryプロジェクト内のガバナンス、アクセス制御、プロジェクト管理と組み合わせて利用できることです。モデル選定、デプロイ、エンドポイント利用、クォータ管理をFoundry側の運用に寄せられるため、検証環境をAzure中心に統一したいチームには扱いやすい構成です。(Microsoft Learn)
ただし、プレビュー機能である以上、既存の本番AIアプリにそのまま置き換える判断は避けるべきです。まずは検証用プロジェクトで、データ取り扱い、応答品質、レイテンシ、コスト、ガードレール、障害時の代替手段を確認してから、段階的に適用範囲を広げるのが安全です。
今回の変更で確認すべきポイント
今回の公式情報で重要なのは、「モデルが増えた」だけではありません。管理者・開発者・セキュリティ担当者が、それぞれ別の観点で設定を確認する必要があります。
| 確認項目 | 影響範囲 | 実務での対応 |
|---|---|---|
| プレビュー機能であること | 本番利用、SLA、障害対応 | 本番ワークロードではなく、まず検証・PoC用途に限定する |
| サブスクリプション単位の有効化 | Azure管理者 | Azure portalのPreview featuresでFireworks.EnableDeployを登録する |
| Foundryプロジェクト権限 | 開発者、プロジェクト管理者 | サブスクリプション権限だけでなく、Foundryプロジェクト側のロールを確認する |
| 対応リージョン | インフラ設計、データ所在地 | Data Zone StandardとGlobal provisioned throughputで選べる範囲が異なる点を確認する |
| データ共有とコンプライアンス | セキュリティ、法務、監査 | MicrosoftとFireworks AI間のデータ共有、EU Data Boundary、FedRAMP、PCI DSSの扱いを事前評価する |
| カスタムモデルの制限 | MLエンジニア、MLOps | LoRAやアダプターではなく、フルウェイトモデルが対象である点を確認する |
| クォータと課金 | FinOps、運用 | Per-TokenとPTUの違い、TPM制限、クォータ申請の必要性を確認する |
公式ドキュメントでは、プレビュー機能の登録にSubscription OwnerまたはSubscription Contributorロールが必要で、モデルをデプロイするにはFoundryプロジェクト上の適切な権限が必要とされています。また、プレビュー機能の登録には最大30分かかる場合があります。(Microsoft Learn)
管理者が最初に確認すべき設定
管理者が最初に行うべき作業は、Foundryポータルでモデルを探すことではなく、Azureサブスクリプション側でFireworks on Foundryを使える状態にすることです。公式手順では、Azure portalから対象サブスクリプションを開き、Preview featuresでFireworks.EnableDeployを検索して登録します。登録後は、状態がRegisteredになっているか確認します。(Microsoft Learn)
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| サブスクリプション確認 | Azure portalで対象サブスクリプションを開く | 検証用と本番用のサブスクリプションを取り違えない |
| プレビュー機能登録 | Preview featuresでFireworks.EnableDeployを登録 | 説明文とデータプライバシー条件を確認してから登録する |
| 登録状態確認 | State列がRegisteredになるまで待つ | 最大30分程度かかる場合がある |
| Foundry権限確認 | プロジェクト側のRBACを確認 | サブスクリプション権限だけでデプロイできるとは限らない |
| 無効化方針 | 不要時はサブスクリプション単位で解除 | プレビュー利用を停止する手順も運用メモに残す |
RBACについては、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerといったロール名が、以前のAzure AI系ロール名から変更されている点にも注意が必要です。公式RBACドキュメントでは、ロール名の変更中でもロールIDと中核的な権限は変わらないと説明されています。自動化スクリプトではロール名ではなくロール定義IDを使うと、名称移行中の揺れによるトラブルを減らせます。(Microsoft Learn)
対応リージョンとデプロイ方式の違い
Fireworks models on Microsoft Foundryでは、選べるデプロイ方式によってリージョンの考え方が変わります。公式ドキュメントでは、Fireworks経由のData Zone StandardデプロイはEast US、East US 2、Central US、North Central US、West US、West US 3で利用可能とされています。一方、ベースモデルとカスタムモデルのGlobal provisioned throughputデプロイは、Azure Governmentクラウド環境を除くグローバルAzureリージョンで利用可能とされています。(Microsoft Learn)
| デプロイ方式 | 向いている用途 | 注意点 |
|---|---|---|
| Data Zone Standard | 従量課金で検証したい場合、米国データゾーン内で処理したい場合 | Fireworksでは利用可能リージョンが限定される |
| Global provisioned throughput | 安定したスループットを確保したい場合、大きな検証負荷を見込む場合 | PTUのクォータと実際の容量確保を分けて考える |
| Per-Token | まず小さく試したい場合、利用量が読みにくい場合 | 対応モデルや廃止通知、レート制限を確認する |
Microsoft Foundry Modelsのデプロイタイプ全般では、Global、Data Zone、Regionalで推論データの処理場所や課金方式、性能特性が異なります。標準系は従量課金、プロビジョニング系は予約容量に近い考え方で、低いレイテンシ変動や予測可能なスループットが必要な場合はプロビジョニング系を検討します。(Microsoft Learn)
PTUを使う場合は、「クォータがあること」と「その時点で容量を確保できること」は同じではありません。公式ドキュメントでは、クォータは上限を示すものであり、実際の容量はデプロイ時に割り当てられると説明されています。容量不足時は、PTU数を下げる、別リージョンを試す、時間を置くといった対応が必要です。(Microsoft Learn)
FoundryポータルからFireworksモデルをデプロイする流れ
プレビュー機能が登録されたら、FoundryポータルのモデルカタログからFireworksモデルをデプロイできます。公式手順では、FoundryポータルでDiscoverからModelsを開き、対象のFireworksモデルを選択してDeployを実行します。デプロイ画面では、デプロイ名、デプロイタイプ、モデルバージョン、Tokens per Minute Rate Limit、ガードレールを設定します。(Microsoft Learn)
| 設定項目 | 推奨する考え方 |
|---|---|
| Deployment name | dev-fw-deepseek-v32のように環境、提供元、モデル名が分かる名前にする |
| Deployment type | 検証初期はコストを抑えやすい方式、本格負荷試験ではPTUを検討する |
| Model version | 後から再現できるよう、利用したバージョンを設計書やGitに記録する |
| Tokens per Minute Rate Limit | 想定外のコスト増や過負荷を避けるため、検証段階では低めに設定する |
| Guardrails | 既定のMicrosoft.DefaultV2だけで十分か、業務要件に合わせてテストする |
デプロイ処理には最大30分かかる場合があり、完了後はFoundryプロジェクトのDeploymentsページで状態がSucceededになっているか確認します。その後、発行されたエンドポイントとキーを使って推論リクエストを送るか、Playgroundで簡易テストを行います。(Microsoft Learn)
ガードレールについては、Microsoft Foundryがモデルやエージェントに適用できる安全性・セキュリティ制御を提供しており、リスク検出、介入ポイント、検出時のアクションを設定する仕組みです。モデルには既定でMicrosoft.DefaultV2ガードレールが割り当てられると説明されています。(Microsoft Learn)
利用できるカタログモデルと選び方
公式ページに掲載されているFireworksモデルは、DeepSeek、MiniMax、Moonshot AI、OpenAI、Qwen、Zhipu AIなどのオープンウェイト系モデルです。モデル一覧はプレビュー期間中に変わる可能性があるため、実際のデプロイ前にはFoundryのモデルカタログで最新状態を確認してください。(Microsoft Learn)
| プロバイダー | モデルID | 主な用途の目安 | サポートされるオファー |
|---|---|---|---|
| DeepSeek | FW-DeepSeek-v3.1 | 汎用チャット、推論タスク | PTU |
| DeepSeek | FW-DeepSeek-v3.2 | 複雑な推論タスク | Per-Token、PTU |
| MiniMax | FW-MiniMax-2.5 | 会話、指示追従 | Per-Token、PTU |
| Moonshot AI | FW-Kimi-K2-Instruct-0905 | チャットワークロード | PTU |
| Moonshot AI | FW-Kimi-K2-Thinking | 多段推論、問題解決 | PTU |
| Moonshot AI | FW-Kimi-K2.5 | 長文コンテキスト、マルチモーダル用途 | Per-Token、PTU |
| Moonshot AI | FW-Kimi-K2.6 | コーディング、長期実行、エージェント系検証 | Per-Token、PTU |
| OpenAI | FW-gpt-oss-120b | 幅広い生成タスク | Per-Token、PTU |
| Qwen | FW-Qwen3.5-122B-A10B | 汎用チャット、推論 | PTU |
| Qwen | FW-Qwen3.5-397B-A17B | 大規模な推論・生成 | PTU |
| Zhipu AI | FW-GLM-4.7 | バイリンガルのチャット・推論 | PTU |
| Zhipu AI | FW-GLM-5 | 高性能なバイリンガルチャット・推論 | Per-Token、PTU |
モデル選定では、まず「何を解かせるか」を決めます。社内FAQや一般的なチャットなら汎用モデル、コード生成や長い作業指示ならコーディングや長期実行に強いモデル、複雑な判断や多段推論ならThinking系や大規模推論モデルを候補にします。次に、Per-Tokenで小さく試すか、PTUで安定した処理能力を確保するかを判断します。
すべてのカタログモデルは、Chat Completions API向けのOpenAI/v1 APIと、Responses APIへアクセスするためのFoundry SDKおよびエンドポイントをサポートすると説明されています。既存アプリから移行する場合は、SDK、APIエンドポイント、認証、model指定、エラーハンドリングを検証環境で確認してから差し替えます。(Microsoft Learn)
カスタムモデルを持ち込む場合の注意点
Fireworks on Foundryでは、カタログモデルだけでなく、独自またはファインチューニング済みのオープンウェイトモデルをインポートしてデプロイできます。公式のカスタムモデル手順では、モデルファイルを準備し、Foundryポータルで登録し、Azure Developer CLIのazdでモデル重みをアップロードし、Fireworks推論基盤へデプロイする流れになっています。(Microsoft Learn)
カスタムモデルのインポートでは、モデルディレクトリにconfig.json、.safetensorsまたは.binの重みファイル、重みシャードを示す.index.json、トークナイザーファイルが必要です。さらに、プレビューではフルウェイトモデルのみが対象で、LoRAアダプターやカスタム量子化モデルはサポートされないと説明されています。(Microsoft Learn)
| 確認項目 | 失敗しやすいポイント | 対策 |
|---|---|---|
| モデルアーキテクチャ | Foundryで選んだアーキテクチャと実ファイルが合わない | 登録前にベースモデル、設定ファイル、重み形式を照合する |
| 必須ファイル | tokenizerやindexファイルの不足でインポートが失敗する | アップロード前にチェックリスト化する |
| アップロード | 大規模モデルの転送に時間がかかる | 安定した回線、作業端末、再試行手順を用意する |
| デプロイ | PTU不足や容量不足で失敗する | 事前にクォータと候補リージョンを確認する |
| 同時運用 | 同一プロジェクト内の制限を見落とす | カスタムモデルはプロジェクト設計単位で分ける |
カスタムモデルのデプロイでは、特定プロジェクト内で同時に有効化できるカスタムモデルデプロイに制限があるため、検証用・評価用・本番候補用を同じプロジェクトに詰め込みすぎない設計が必要です。公式手順では、1つのプロジェクト内で同一カスタムモデルのアクティブなデプロイは1つだけと説明されています。(Microsoft Learn)
データプライバシーとコンプライアンスで確認すべきこと
最も見落としやすいのが、データの扱いです。Fireworks on Foundryを利用すると、データはMicrosoftとFireworks AIの間で共有され、異なるコンプライアンスおよびデータ処理ルールが適用されます。公式ドキュメントでは、そのデータ共有が自社のコンプライアンス要件に適しているかを顧客側が評価する責任があると説明されています。(Microsoft Learn)
特に、Fireworks on FoundryはEU Data Boundaryのコミットメントから除外され、FedRAMPは達成されておらず、PCI DSSは適用されないとされています。支払いデータやカード会員データの保存、処理、送信には使わないよう明記されています。金融、公共、医療、グローバル企業の個人データ処理では、検証段階でもデータ分類と持ち込み可否の判断が必要です。(Microsoft Learn)
実務では、次のように判断すると安全です。
| データ・用途 | 利用判断の目安 |
|---|---|
| 公開済みテキスト、サンプルデータ | 検証に使いやすい |
| 社内文書の要約 | 機密区分、契約、保持ポリシーを確認してから使う |
| 個人情報を含む問い合わせ | 匿名化やマスキングを先に検討する |
| 決済・カード会員データ | 利用しない |
| 政府・FedRAMP前提のワークロード | 承認担当者に利用可否を確認する |
| EU Data Boundaryを前提にした処理 | Fireworks on Foundryが除外される点を前提に再評価する |
また、MicrosoftはFireworks on Foundry経由でデプロイされたサードパーティおよびオープンウェイトモデルについて、安全性、セキュリティ、Responsible AI特性を開発・学習・微調整・評価しないと説明しています。顧客向けアプリケーションや業務判断に使う場合は、モデルの適合性、安全性評価、出力検証、監査ログ、誤回答時の運用フローを自社で用意する必要があります。(Microsoft Learn)
開発者が実装前に確認すべきAPIと運用設計
開発者は、モデルがデプロイできたかだけでなく、アプリケーション側の呼び出し設計まで確認する必要があります。FireworksのカタログモデルはChat Completions APIとResponses APIに対応するため、既存のOpenAI互換クライアントを使える可能性がありますが、エンドポイント、認証情報、モデル名、レスポンス形式、エラー時の挙動は必ず実測します。(Microsoft Learn)
PTUを利用する場合、負荷が割り当て容量を超えるとHTTP 429が返ります。公式ドキュメントでは、429は単なる障害ではなく、デプロイがその時点でフル利用されていることを示す設計上のシグナルと説明されています。retry-after-msやretry-afterヘッダーを見て再試行する、別デプロイへ逃がす、標準デプロイをフォールバック先にするなど、アプリケーション側で処理方針を決めておきます。(Microsoft Learn)
特に生成トークン数の見積もりは、スループットに影響します。PTUでは、リクエストごとにプロンプトサイズや予想生成サイズをもとに利用量が評価されるため、max_tokensを必要以上に大きく設定すると、実際の出力が短くても同時実行数が下がる場合があります。検証では、実際の業務プロンプトに近い入力で平均入力トークン、平均出力トークン、429発生率を測定します。(Microsoft Learn)
既存環境からの移行で注意すべき点
Fireworks AIの既存アカウントを持っていても、既存のFireworksデプロイをそのままFoundryで使えるわけではありません。公式FAQでは、Foundryで新しいデプロイを作成する必要があると説明されています。既存のFireworks利用をAzure側へ移したい場合は、モデル、エンドポイント、認証、課金、ログ、データ処理条件を新しいFoundryデプロイとして再設計する必要があります。(Microsoft Learn)
移行時は、次の順序で進めると手戻りを減らせます。
| フェーズ | 実施内容 | 合格条件 |
|---|---|---|
| 事前評価 | 利用データ、リージョン、コンプライアンス、権限を確認 | セキュリティ担当者が検証利用を承認している |
| 小規模検証 | サンプルデータでモデル品質とAPI互換性を確認 | 期待する出力形式、速度、エラー処理を確認できる |
| 負荷検証 | TPM、PTU、429、レイテンシを測定 | 想定ピーク時の処理方針が決まっている |
| ガードレール検証 | 危険な入力、禁止語、業務NG出力を試験 | 誤ブロックと見逃しの許容範囲が決まっている |
| 段階展開 | 社内ユーザーや限定機能から展開 | ロールバック先と監視項目が明確になっている |
また、StandardのPer-Token推論オファーでは、モデル廃止前の通知期間が15日と説明されています。長期間使う業務アプリでは、モデルIDを固定して終わりではなく、廃止通知の監視、代替モデル候補、再評価手順を運用に組み込む必要があります。(Microsoft Learn)
よくあるトラブルと確認ポイント
Fireworks models on Microsoft Foundryのトラブルは、モデルそのものよりも、プレビュー登録、リージョン、権限、クォータ、ファイル要件で発生しやすいです。公式ドキュメントでも、登録状態、対応リージョン、クォータ、アクセス拒否、デプロイ状態の確認がトラブルシューティング項目として示されています。(Microsoft Learn)
| 症状 | 主な原因 | 確認する場所 |
|---|---|---|
| モデルカタログにFireworksモデルが出ない | プレビュー機能が未登録、またはリージョン非対応 | Azure portalのPreview features、Foundryの対象リージョン |
| 登録がRegisteringのまま | 反映待ち、登録処理の停滞 | 最大30分待って状態を更新し、それでも変わらなければ再登録を検討 |
| デプロイで権限エラー | Foundryプロジェクト側のRBAC不足 | Foundry projectのAccess control、ロール名の新旧表記 |
| クォータエラー | Fireworks用容量やPTU不足 | クォータ申請フォーム、PTU割り当て、別リージョン |
| カスタムモデルのインポート失敗 | 必須ファイル不足、アーキテクチャ不一致 | config.json、重みファイル、index、tokenizer、モデル種別 |
| 期待より同時実行できない | max_tokens過大、PTU不足、429処理不足 | 実測ログ、利用率メトリック、リトライ設計 |
| 出力が業務ルールに合わない | ガードレール未調整、評価不足 | Microsoft.DefaultV2、カスタムガードレール、評価データセット |
Fireworks機能を無効化したい場合は、プロジェクト内の設定だけでなく、Azureサブスクリプションレベルでプレビュー機能を解除する流れになります。検証終了後に利用を止める場合は、デプロイ削除、キーの無効化、クォータ・コスト確認、プレビュー機能解除までを一連の終了手順として残しておくと安全です。(Microsoft Learn)
まず何から始めるべきか
Azure AI FoundryでFireworks models on Microsoft Foundryを試すなら、最初の一歩は「モデルを選ぶ」ことではなく、「使ってよい条件を確認する」ことです。プレビュー機能であり、MicrosoftとFireworks AI間のデータ共有があり、EU Data BoundaryやFedRAMP、PCI DSSに関する制約もあります。業務データを投入する前に、検証用サブスクリプション、検証用Foundryプロジェクト、サンプルデータ、最小権限のRBACを用意してください。(Microsoft Learn)
そのうえで、管理者はFireworks.EnableDeployの登録とRBACを確認し、開発者はFoundryポータルから小さなモデルデプロイを作成してAPI応答を検証します。次に、必要に応じてPTU、ガードレール、カスタムモデル、モデル廃止時の代替手順を確認します。ここまでをチェックリスト化しておけば、Fireworks on Foundryを単なる新機能の試用ではなく、将来のAIモデル運用基盤の候補として冷静に評価できます。
コメント