MENU

Billing for Microsoft Fabric Planningの期限・移行対応｜2026年7月GA前の課金確認

Microsoft

「Billing for Microsoft Fabric Planning（Preview）」という案内を見て、「Microsoft Fabric Planningが廃止されるのか」「2026年7月までに移行が必要なのか」と不安になった担当者もいるでしょう。

結論から言えば、2026年6月24日時点で、Microsoft Fabric Planningの廃止、非推奨化、強制移行期限は公表されていません。明示されている将来日付は2026年7月の一般提供予定であり、サービス停止日や課金の適用開始日とは別に考える必要があります。

今回のNoticeで確認すべきなのは、移行作業そのものよりも、Plan（Preview）で導入される役割別・30日セッション単位のCU消費と、自動化ジョブ単位の課金です。すでにプレビューを利用している組織は、一般提供前に利用者の役割、Fabric容量、リージョン、接続方式を確認しておく必要があります。([Microsoft Fabric Community][1])

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Billing for Microsoft Fabric Planningの期限・移行対応の結論

今回の発表は、既存サービスを終了して別サービスへ移すための移行通知ではありません。公式ブログでは、Microsoft Fabric Planningの課金モデルと、2026年7月に一般提供する予定であることが説明されています。一方、移行期限や停止日は記載されていません。([Microsoft Fabric Community][1])

確認項目2026年6月24日時点の状況実務上の判断
サービスの廃止公表なし今回のNoticeだけを理由にデータを退避する必要はない
機能の非推奨化公表なし既存機能の置き換え通知ではない
強制移行期限記載なし2026年7月を移行期限として扱わない
一般提供2026年7月予定正式なGA発表を改めて確認する
課金適用開始日明記なしGA予定日と課金開始日を同一視しない
主な対応課金・容量・権限の確認プレビュー利用者はGA前に影響を試算する

したがって、「期限までに別サービスへ移行する」という対応ではなく、プレビューから一般提供へ移る前に、利用方法を課金モデルに合わせて見直すことが実質的な移行対応になります。

なお、Microsoft Learnでは同機能が「Plan（Preview）」、ブログでは「Fabric Planning」や「Planning in Microsoft Fabric」と表記されています。本記事では、いずれもMicrosoft Fabric IQの計画・予算編成機能を指すものとして扱います。(Microsoft Learn)

Microsoft Fabric Planningの課金モデルで変わること

Microsoft Fabric Planningでは、単純なユーザーライセンスでも、操作した時間だけを測る従量課金でもない、次のハイブリッド方式が採用されます。

課金対象単位主な対象
ユーザー操作役割別の30日セッションViewer、Stakeholder、Planner
自動処理成功したジョブ単位データ同期、Planningシート更新など
関連するFabric処理各サービスの既存メーターFabric SQL、OneLake、Power BI XMLA APIなど

利用者数だけで予算を立てると、実際のCU消費と大きくずれる可能性があります。重要なのは、登録上の肩書ではなく、ユーザーが30日間のセッション内で実際にどの操作を行うかです。

役割別に30日分のCUが消費される

Microsoftが公開した概算では、役割別の30日セッションに対して、次のCU-hoursが示されています。セッション期間は30日、計算上は730時間です。

役割主な操作1時間あたりの目安30日セッションの目安Viewerとの比較
Viewer閲覧、並べ替え、フィルター、ブックマーク0.05 CU-hours約37 CU-hours1倍
Stakeholderデータ入力、承認、コメント、書き戻し0.23 CU-hours約168 CU-hours約4.5倍
Plannerシート編集、モデル設計、ルール設定、管理1.16 CU-hours約847 CU-hours約23倍

PlannerはViewerの約23倍、Stakeholderの約5倍のCUを消費する計算です。

そのため、「対象者は100人」とだけ数えるのでは不十分です。100人全員が閲覧だけを行う場合と、20人がデータ入力し、5人が編集操作を行う場合では、必要な容量が大きく変わります。

閲覧しただけでもViewerセッションが始まる可能性がある

セッションは、ユーザー、役割、特定のFabric容量、30日間の期間をひも付けて管理されます。公式説明では、ユーザーがPlanningワークフローを開くか、意味のある操作を行った時点でセッションが開始されます。([Microsoft Fabric Community][1])

Microsoft Learnでは、操作に応じて役割が動的に決まることが説明されています。

ユーザーの操作判定される役割
Planningシートを開いて閲覧するViewer
データを入力する、承認する、書き戻すStakeholder
Planning項目を編集・作成するPlanner

利用者は通常Viewerから始まり、必要な操作を行うとStakeholderやPlannerへ昇格します。役割は30日間のセッション中に上位へ変更できますが、下位へ戻すことはできません。セッションが満了した後、次の操作時に新しいセッションが作成されます。(Microsoft Learn)

この仕組みでは、次のようなケースに注意が必要です。

「見るだけの予定だった部門長が数値を1回入力した」「検証中に一般利用者が編集操作を試した」といった場合、そのユーザーは上位役割として扱われます。役割昇格後の詳細な課金按分方法は今回のブログで説明されていないため、一般提供前にCapacity Metricsや実際の請求メーターで確認する必要があります。

同じユーザーでも容量が異なれば別に評価される

Planningの役割は、Fabric容量ごとに独立して評価されます。役割を複数容量間で共有することはできません。セッション自体も特定の容量にひも付きます。(Microsoft Learn)

そのため、検証用容量と本番用容量の両方を同じユーザーが利用すると、それぞれの容量でセッションが評価される可能性があります。

プレビュー環境から本番環境へ移す場合は、次のような運用を避けることが重要です。

  • 多数の利用者に検証用と本番用の両方を長期間開放する
  • ワークスペースを複数容量間で繰り返し移動する
  • 部門ごとに容量を分けたまま、同じユーザーへ広範囲なアクセス権を与える

移行テストは少人数で行い、一般利用者を本番容量へ切り替える日をできるだけそろえると、セッション数を把握しやすくなります。

自動化処理は成功したジョブ単位で課金される

Microsoft Fabric Planningでは、ユーザー操作以外に、モデル間のデータ同期や接続されたPlanningシートの更新などがジョブとして実行されます。

公開された概算では、成功したジョブ1件につき約2 CU-hoursです。処理時間や実行ユーザーの役割にかかわらず、成功したジョブごとの固定値として示されています。

例えば、1日100件の成功ジョブを30日間実行すると、単純計算では次の消費になります。

100件 × 30日 × 2 CU-hours
= 6,000 CU-hours

1件当たりの値が小さく見えても、部門別、拠点別、シナリオ別にジョブを分割している環境では無視できない量になります。

ジョブの実行回数を見積もる際は、スケジュール設定だけでなく、連鎖的に実行される更新処理や再実行も確認してください。ただし、今回公表された「成功ジョブ単位」のメーターだけを見て、失敗処理や関連するFabric処理がすべて無償になると判断するのは避けるべきです。

30％のバッファは固定料金ではない

Microsoftが公開した図には、Fabric SQL、OneLake、Power BI XMLA API、そのほかのFabric項目で消費されるCUについて、30％、約314 CU-hoursの「Estimated Buffer」が例示されています。

ここで注意したいのは、30％が全利用環境へ一律に加算される固定料金ではない点です。

Planningでは、次のような処理が別のFabricメーターとして計上されます。

  • Planningのメタデータを保持するFabric SQL
  • セマンティックモデルへのアクセス
  • XMLA APIによる処理
  • OneLakeの読み書き
  • Power BIレポートや分析処理
  • 書き戻し先データベースへの操作

30％は初期見積もりの予備値としては使えますが、最終的な容量判断は実測値で行う必要があります。データ量、更新頻度、利用するPlanningシート数、セマンティックモデルの設計によって、追加処理のCUは変わります。

課金は「1ユーザー月額」ではなくFabric容量を消費する

Microsoft Fabric Planningの役割別料金は、一般的なSaaSのように「Planner 1人につき月額いくら」と直接請求される仕組みではありません。役割やジョブに応じた使用量がCUとして計測され、既存のFabric容量をほかの分析・データ処理ワークロードと共有します。([Microsoft Fabric Community][1])

実際の金銭的な影響は、現在の容量状況によって異なります。

現在の容量状況想定される影響
十分な空き容量がある直ちにAzure請求額が増えない可能性はあるが、ほかの処理に使える余力が減る
容量使用率が高いスロットリング、処理遅延、タイムアウトのリスクが高まる
容量を拡張するF SKUのスケールアップや別容量の追加で費用が増える
Overageを利用する超過分の追加料金が発生する可能性がある
従量課金容量を停止・再開しているセッションが残っていても、容量の稼働計画との整合確認が必要

FabricのF SKUは、F2なら2 CU、F16なら16 CU、F32なら32 CU、F64なら64 CUというように、SKUごとに利用可能な容量が決まっています。容量選定は、Planningだけでなく、同じ容量上で稼働するPower BI、Data Factory、Warehouse、Sparkなどを含めて判断します。(Microsoft Learn)

CU-hoursを使った概算方法

初期調査では、次の式で30日分の消費量を概算できます。

30日分の概算CU-hours
= Plannerセッション数 × 847
+ Stakeholderセッション数 × 168
+ Viewerセッション数 × 37
+ 成功ジョブ数 × 2
+ 関連するFabric処理のCU-hours

ここで数える人数は、組織に登録されている全ユーザーではなく、対象容量で30日以内にPlanningを利用するユーザーです。

また、利用者を申請上の役割で分類するのではなく、実際に行う最上位の操作を基準に分類してください。

5人のPlanner、20人のStakeholder、100人のViewerで試算する場合

次の条件を仮定します。

条件数量
Planner5人
Stakeholder20人
Viewer100人
30日間の成功ジョブ100件
利用容量1つ
各ユーザーのセッション30日間に1回

役割別の消費量は次のとおりです。

計算対象計算式CU-hours
Planner5 × 8474,235
Stakeholder20 × 1683,360
Viewer100 × 373,700
成功ジョブ100 × 2200
合計11,495

30日を730時間として平均化すると、次の規模です。

11,495 CU-hours ÷ 730時間
= 平均 約15.7 CU

関連するFabric処理を含めずに、すでにF16の16 CUに近い計算です。

さらに、Microsoftの図を参考に役割別消費量へ30％の予備値を仮置きすると、次のようになります。

役割別消費量 11,295 CU-hours × 30％
= 約3,389 CU-hours

11,495 + 3,389
= 約14,884 CU-hours

14,884 ÷ 730時間
= 平均 約20.4 CU

単純平均ではF16を超え、F32の約64％に相当します。ここへ既存のPower BIレポート、データ更新、Warehouse、Data Factoryなどの負荷が加わります。

ただし、この計算は容量の最終決定に使うものではありません。ジョブが特定時間帯に集中する場合や、月末・予算編成期に同時アクセスが増える場合は、平均値が収まっていてもピーク時に容量不足が発生します。

期限・移行対応で見落としやすい点

2026年7月は強制移行期限ではない

公式ブログの表現は「2026年7月に一般提供予定」です。日付を確定したサービス停止や、プレビュー環境から移行しなければ使えなくなる期限ではありません。([Microsoft Fabric Community][1])

また、ブログには課金の具体的な適用開始日が記載されていません。

したがって、社内資料では次のように区別してください。

日付・期限扱い
2026年7月一般提供の予定時期
課金開始日公式な適用日を別途確認
プレビュー終了日現時点で明記なし
強制移行期限現時点で明記なし
社内対応期限組織側でGA前の確認期限を設定

「7月になれば自動的にすべて有料になる」「7月までに移行しないとデータが消える」といった案内は、現時点の公式情報だけでは根拠が不足しています。

プレビューだから無料とは限らない

Microsoft Fabricのプレビュー機能は、一般提供前の評価機能であり、本番利用を前提としていません。プレビューには通常のSLAが適用されず、機能や提供地域が制限される場合があります。(Microsoft Learn)

一方で、プレビューであることは無償であることを意味しません。今回、役割別セッションとジョブのCU消費が明示されているため、検証環境でも容量への影響を監視する必要があります。

また、Fabricの消費率は変更される可能性があり、MicrosoftはリリースノートやFabricブログなどで変更を通知すると説明しています。公開されたCU値を、将来にわたる固定値として長期契約や予算へそのまま使用するのは避けてください。(Microsoft Learn)

名目上のViewerではなく実際の操作で試算する

権限台帳で「閲覧者」となっていても、Planning上でデータ入力や承認を行えばStakeholderになります。編集操作を行えばPlannerになります。

特に注意したいのは、役割を下げられない点です。誤操作や検証操作によって上位役割へ昇格すると、その役割はセッション満了まで維持されます。(Microsoft Learn)

利用開始前に、各部門へ次の区分を明示しておくと過剰な役割昇格を防ぎやすくなります。

利用者区分許可する操作
閲覧者表示、フィルター、並べ替え、シナリオ比較
入力担当者数値入力、承認、コメント、書き戻し
設計担当者シート作成、モデル設計、ルール設定
管理者接続、権限、書き戻し先、運用設定

Microsoft Learnでは、ViewerとStakeholderにはFabricワークスペースのViewerロール、PlannerにはAdmin、MemberまたはContributorを割り当てる構成が推奨されています。Planning内の役割とFabricワークスペースの役割は別の権限モデルであるため、両方を確認してください。(Microsoft Learn)

日本リージョンではJapan Westに注意する

2026年6月時点のプレビューでは、Japan WestはPlanの非対応リージョンに含まれています。(Microsoft Learn)

Japan Westの容量を利用している組織は、2026年7月の一般提供予定だけを見て移行計画を確定しないでください。GA時点での対応リージョンを改めて確認する必要があります。

リージョンを変更するために別容量を新設する場合は、次の影響も確認します。

  • データ所在地と社内ポリシー
  • ワークスペースの移動可否
  • セマンティックモデルとの接続
  • ゲートウェイやクラウド接続
  • 同一ユーザーに対する容量別セッション
  • Azure側の予算、予約、クォータ

単に利用可能なリージョンへ移すのではなく、データレジデンシーやネットワーク要件を含めて判断してください。

B2BとPrivate Linkはプレビューの制約になる

Plan（Preview）には、移行判断へ直接影響する制約があります。

確認対象プレビュー時点の制約
Microsoft Entra B2BB2Bユーザーをサポートしない
Private LinkPrivate Linkを使用するテナントやワークスペースではPlan項目をサポートしない
My workspaceMy workspace上のセマンティックモデルは非対応
セマンティックモデルAdminまたはBuild権限が必要
認証方式OAuthまたはサービスプリンシパルを使用
Direct Lake追加設定が必要
Pro・PPUXMLAエンドポイントや埋め込みトークンを使う一部シナリオでは非対応

(Microsoft Learn)

外部の予算担当者をB2Bで招待している組織や、Private Linkを必須としている組織では、現在の構成をそのまま移行できない可能性があります。

セキュリティ要件を回避するためにPrivate Linkを外すのではなく、GA時点の対応状況、代替構成、Microsoftのロードマップを確認してから判断してください。

Plan項目だけでなく自動作成されるSQLデータベースも管理する

Plan（Preview）の項目を作成すると、Planningレポートのメタデータを保存するFabric SQLデータベースがワークスペース内に自動作成されます。(Microsoft Learn)

そのため、移行対象をPlanningシートだけで管理すると、依存関係を見落とす可能性があります。

移行台帳には、少なくとも次の項目を含めてください。

管理対象確認内容
Plan項目所有者、利用部門、用途
Planningシート入力項目、計算、レイアウト
PowerTable・Intelligence参照元、出力先
セマンティックモデルワークスペース、接続所有者、認証方式
Fabric SQL自動作成されたメタデータDB
書き戻し先接続、権限、テーブル構造
自動化ジョブ実行頻度、連鎖処理、成功件数
利用容量SKU、リージョン、既存使用率

一般提供前に実施する対応手順

現在の利用状況を3段階に分類する

まず、組織の利用状態を次のいずれかに分けます。

状況対応方針
Planを利用していない強制移行は不要。GAと正式課金情報を監視する
少人数でプレビュー検証中利用者と容量を限定し、30日分の実測データを取得する
本番に近い業務で利用中権限、容量、制約、ロールバック手順を優先的に確認する

本番に近い利用をしている場合でも、プレビュー環境を前提とした不可逆な業務切り替えは避けます。正式なGA条件、サポート範囲、プレビュー項目の引き継ぎ方法が確認できるまでは、既存の予算編成手段を復旧できる状態にしておくのが安全です。

利用者を「人数」ではなく「操作」で棚卸しする

対象ユーザーごとに、次の内容を記録します。

確認項目記録例
ユーザー・グループ経営層、部門長、入力担当、FP&A
利用する容量検証用F64、本番用F32など
想定操作閲覧、入力、承認、編集
想定役割Viewer、Stakeholder、Planner
利用開始時期月初、四半期末、予算編成期間
複数容量の利用あり・なし
外部ユーザーB2B利用の有無

特に、承認やコメントだけを行うユーザーがViewerに分類されていないか確認してください。Planning上での操作内容によってはStakeholderになります。

30日間の容量テストを実施する

セッションが30日間続くため、数日間の負荷試験だけでは実態を把握しにくくなります。

少なくとも1回の30日セッションを通して、次の情報を取得します。

確認する指標目的
役割別セッション数想定人数との差を確認する
Plannerへの昇格数誤操作や過剰権限を検出する
成功ジョブ数自動化課金を見積もる
Planning関連のCU役割・ジョブの実消費を確認する
Fabric SQL・OneLake・Power BIのCU追加メーターの影響を確認する
容量使用率既存ワークロードとの競合を確認する
スロットリング容量不足の有無を確認する
月末・締め日ピーク平均値では分からない集中負荷を確認する

Microsoftも、Capacity Metricsアプリを利用して実際の使用量を確認し、必要に応じてSKUを調整する方法を案内しています。(Microsoft Learn)

一般提供時に未確定事項を再確認する

2026年7月のGA発表時には、少なくとも次の内容を確認してください。

確認事項確認する理由
正式なGA日「7月予定」から変更される可能性がある
課金適用開始日GA日と同日とは限らない
最終的なCU消費率プレビュー中の概算から変わる可能性がある
役割昇格時の計算方法日割り、按分、セッション更新の詳細が必要
メーター名称Cost ManagementやCapacity Metricsで識別するため
プレビュー項目の引き継ぎ再作成や変換が必要か確認する
リージョン対応Japan Westなどの対応状況を確認する
B2B・Private Link対応セキュリティ構成を確定する
SLAとサポート範囲本番切り替えの可否を判断する

これらが確定する前に、年間の予約容量や大規模な本番展開を決定すると、過剰な容量を購入したり、逆に容量不足になったりする可能性があります。

Billing for Microsoft Fabric Planningへの対応で優先すべきこと

今回のNoticeは、Microsoft Fabric Planningの廃止や非推奨化を知らせるものではありません。2026年6月24日時点で、強制移行期限やサービス停止日は示されておらず、2026年7月は一般提供の予定時期です。

一方、プレビューを利用している組織にとっては、役割別の30日セッション課金が大きな影響を持ちます。特に、ViewerからStakeholder、Plannerへ動的に昇格する仕組みと、役割を30日間下げられない点は見落としやすい部分です。

最初に行うべき作業は、対象ユーザーを単純に数えることではありません。どの容量で、誰が、どの操作を行うかを棚卸しし、役割別CU、成功ジョブ、関連するFabric処理を合わせて試算してください。

そのうえで30日間の実測を行い、正式なGA日、課金適用日、最終的な消費率、プレビュー項目の引き継ぎ方法が公表された段階で、本番移行と容量変更を判断するのが安全です。
[1]: https://community.fabric.microsoft.com/t5/blogs/blogarticleprintpage/blog-id/fbc_fabricupdatesblogs/article-id/1483 “
Billing for Microsoft Fabric Planning (Preview) – Microsoft Fabric Community
“

Microsoft
課金 Microsoft Fabric Fabric Planning Capacity Units Microsoft Fabric IQ

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次