e2e-fabric-cost-estimation

テレメトリ — 必須。 すべての api.fabric.microsoft.com 呼び出しには x-ms-fabric-skill: e2e-fabric-cost-estimation（az rest の場合は --headers "x-ms-fabric-skill=e2e-fabric-cost-estimation"）を含める必要があります。 すべての LRO ポーリング、fabric_lro、リトライにも適用されます。スニペットでは省略されていますが、必ず追加してください。

重要な注意事項

1. ワークスペース名からワークスペースの詳細（ID を含む）を特定するには、すべてのワークスペースを一覧表示してから、JMESPath フィルタリングを使用します。
2. ワークスペース ID、アイテムの種類、アイテム名からアイテムの詳細（ID を含む）を特定するには、そのワークスペース内でその種類のアイテムをすべて一覧表示してから、JMESPath フィルタリングを使用します。
3. 料金はリージョンごとに異なります。 価格を検索する前に、必ず Fabric REST の GET /v1/capacities（region／sku／state を返します）または ARM を使って容量の Azure リージョンを特定するか、ユーザーに確認してください。また、提示するすべての金額にリージョンを明記してください。

🔴 必須のライブ料金取得 — 回答にドル金額を含める場合は必ず実施してください。 いかなる金額、コスト、損益分岐点、課金モードの比較、RI と PAYG の分析、移行コスト、またはコスト計算表を提示する前にも、Azure Retail Prices API（https://prices.azure.com/api/retail/prices）を呼び出すシェルコマンド（bash／powershell）を必ず実行してください。これは、Databricks／Synapse の移行コスト、Autoscale と基本 SKU の損益分岐点、RI と PAYG の損益分岐点、コスト計算表、課金モードの戦略など、価格を含むすべての回答に例外なく適用されます。まず、CU 時間あたりの PAYG ライブ料金（priceType eq 'Consumption'、* Capacity Usage CU メーター）、予約期間の合計額、および autoscale for Spark Capacity Usage CU の料金を取得してから計算してください。記憶した料金やハードコードした料金をもとに、価格に関する質問に回答してはいけません。また、数式だけで損益分岐点を推定してはいけません。メーターの検索結果がない場合は、その旨をユーザーに伝えてください。ハードコードした料金に黙って切り替えてはいけません（たとえば、Autoscale の料金を $0.18/CU-hr と仮定してはいけません。Autoscale のメーターは別個の料金であり、必ず取得する必要があります）。 例外 — 容量の純粋なサイジング： 容量ユニットのみで回答し、ドル金額を含まない質問（例：「80 CU に適合する SKU はどれですか？」、「P2 は何 CU に相当しますか？」）は CU の計算であり、料金の取得は不要です。そのサイジングの回答にドル金額を添えた時点で、料金の取得が必須になります。

🟠 まず確認し、その後に実行 — デフォルトを仮定しないでください。 料金を含むリクエストでは、取得や計算の前に Azure リージョン と ワークロードのプロファイル（例：1 日あたりの CU 時間、ノード／ジョブの詳細、移行元クラスターのサイズ）の 2 つの入力が必要です。どちらかが不足している場合は、最初の応答で不足している入力をユーザーに確認し、そこで停止してください。デフォルトのリージョンを選んだり（「まず始めるため」に East US やその他のリージョンを仮定したり）、料金 API を呼び出したり、仮定の値から見積もりを提示したりしてはいけません。不足している入力をユーザーが提供した後に限り、ライブ料金を取得して計算してください。必須の料金取得ルールは最終的な料金提示を含む回答に適用されますが、確認を求めることが正しい対応です。

🔴 AUTOSCALE の料金は別個のメーターです — 基本／PAYG 料金を流用しないでください。 autoscale for Spark Capacity Usage CU メーターは、基本の * Capacity Usage CU PAYG 料金とは別の料金です。必ず独自の API 呼び出しで取得し、返された retailPrice を読み取ってください。基本／PAYG 料金（または 0.18 のような記憶した金額）を Autoscale の変数に割り当てるのは、正確性に関わるバグです。たとえば、autoscaleRate = paygRate や autoscaleRate = 0.18 は禁止です。Autoscale メーターの検索結果がない場合は、そのリージョンの Fabric Spark メーターをすべて一覧表示し、その旨をユーザーに伝えてください。基本料金で代用してはいけません。

Fabric のコスト見積もり

前提知識

• COMMON-CORE.md — Fabric のトポロジー、容量の概念、認証とトークンの対象者
• COMMON-CLI.md — 容量の検出や認証手順（az login、トークンの取得）に関する CLI のパターン

---

目次

トピック	セクション
Fabric の課金モデルの概要	§ 課金モデル
容量ユニット（CU）のリファレンス	§ CU リファレンス
ワークロードのコスト見積もり	§ ワークロードの見積もり
ストレージの料金	§ ストレージ
ネットワークの料金	§ ネットワーク
課金モードの戦略	§ 課金戦略
SKU のサイズ選定ツリー	§ SKU のサイズ選定
移行コストのワークシート	§ ワークシート
料金 API のリファレンス	pricing-api-reference.md
必須／推奨／回避	§ 必須／推奨／回避

---

Fabric の課金モデル

Microsoft Fabric は、すべてのワークロードが 容量ユニット（CU） のプールを共有する 統合容量モデル を採用しています。課金の各要素は次のとおりです。

要素	説明	課金方式
コンピューティング（CU 秒）	クエリ、Spark ジョブ、パイプラインで消費される処理能力	容量 SKU に対する CU の消費量
ストレージ（GB／月）	Delta テーブル、Files、ショートカット用の OneLake ストレージ	GB あたりの月額料金
ネットワークのエグレス（GB）	Azure リージョンから外部へ出るデータ	GB あたりのエグレス料金
容量予約	基本 SKU の契約（F2～F8192）	月次または年次の契約

課金モード

モード	説明	最適な用途
予約インスタンス（RI）	1 年または 3 年の契約。大幅な割引（コンピューティング料金はライブ API から取得）	安定したベース負荷
従量課金制（PAYG）	時間単位の課金。契約不要。通常価格が適用されます	テスト、予測不能なワークロード
Spark の自動スケール課金	オプトイン型のサーバーレスモデル。Spark ジョブは容量からオフロードされ、Spark CU 時間あたりで課金されます。Spark ではバーストと平滑化が無効になり、容量 CU は消費されません	変動する Spark の費用を安定した容量の費用から分離する場合
Fabric 試用版	試用容量（サイズはテナントや利用資格によって異なります。一般的には最大 F64、60 日間）。使用前に現在の試用条件を確認してください。本番環境のサイズ選定には使用しないでください	評価のみ

容量 SKU の階層 — ライブ価格の取得

ハードコードした価格は使用しないでください。 実行時に Azure Retail Prices API から常に最新の価格を取得してください。

手順 1：顧客のリージョンを特定する

顧客がすでに Fabric 容量を保有している場合は、コア Fabric REST API を使用してリージョン、SKU、状態を取得します。GET https://api.fabric.microsoft.com/v1/capacities は各容量の region、sku、state を返します。Azure Resource Manager（az resource list）も代替手段として使用できます。リージョンを返さないのは Fabric の Admin API（/v1/admin/capacities）のみです。resources/pricing-api-reference.md のテンプレートを参照してください。

まだ容量がない場合は、デプロイ予定の Azure リージョンをユーザーに確認してください。

ステップ 2：Fabric の最新料金を取得する

Azure Retail Prices API（公開 API、認証不要）に問い合わせます。料金が発生する質問では、Autoscale とベース料金の損益分岐点や、課金モード（PAYG／RI／一時停止・再開）の戦略も含め、計算を行う前に必ずシェル（bash／powershell）でこの取得を実行してください。 数式だけで損益分岐点や課金上のトレードオフを考えないでください。コマンドを実行してから、返された retailPrice の行を使って計算します。

curl -s "https://prices.azure.com/api/retail/prices?api-version=2023-01-01-preview&\$filter=serviceName%20eq%20'Microsoft%20Fabric'%20and%20armRegionName%20eq%20'<region>'" | jq '.Items[] | {meterName, retailPrice, unitOfMeasure, type, reservationTerm}'

resources/pricing-api-reference.md のリファレンステンプレートを使用して NextPageLink の結果をページネーションし、選択したリージョンの Fabric 容量メーターに絞り込みます。Retail Prices API は F-SKU ごとに 1 行を返すわけではありません。skuName／armSkuName に対して ^F\d+ を照合しても、一致するものはありません。現在、PAYG の CU 時間あたりの料金は、meterName が Capacity Usage CU で終わるワークロード別の Consumption メーターに基づいて請求されます（priceType eq 'Consumption'、unitOfMeasure eq '1 Hour'）。ベースのコンピューティング料金には、それらの料金の 最頻値の retailPrice を使用します（低い CU 時間あたりの料金です。必ず API が返す値を使用し、このスキル内の例示的な数値を転記しないでください）。予約の料金は meterName eq 'Fabric Capacity CU' から取得します（従来の定額メーターは現在、予約専用です）。それらの行から CU あたりの料金を読み取ります。

ステップ 3：料金表を作成する

API が返すのは CU あたりの料金であり、SKU ごとの料金ではありません。ドキュメントに記載された SKU→CU マップ（Fn = n CU。例：F64 = 64、F128 = 128、F256 = 256、F512 = 512、F1024 = 1024、F2048 = 2048、F4096 = 4096、F8192 = 8192）の各 SKU の CU 数を CU あたりの料金に乗じて、SKU ごとの料金表を作成します。

各 reservationTerm の区分を、正しく 月額に換算します（予約の行は時間単価ではなく、契約期間全体の合計額です）。

• PAYG の月額 = consumptionCuHourRate × skuCUs × 730（Consumption 行。priceType eq 'Consumption'、meterName は * Capacity Usage CU に一致）
• 1 年 RI の月額 = reservationRetailPrice × skuCUs ÷ 12（730 を乗じないでください）
• 3 年 RI の月額 = reservationRetailPrice × skuCUs ÷ 36

月額への換算方法については、resources/pricing-api-reference.md のガイダンスを参照してください。

ステップ 4：ユーザーに提示する

リージョンを明記して、料金表を提示します。

Fabric Capacity Pricing — Region: [detected_region] (live as of [today's date])

| SKU | CUs | Monthly PAYG | 1-Year RI | 3-Year RI | RI Savings |
|-----|-----|-------------|-----------|-----------|------------|
| F4  | 4   | $[live]     | $[live]   | $[live]   | [calc]%    |
| ... | ... | ...         | ...       | ...       | ...        |

Source: Azure Retail Prices API (prices.azure.com)

重要：API に接続できない場合は、その旨をユーザーに伝え、Azure 料金計算ツールを案内してください。ハードコードされた料金を代わりに使用しないでください。情報が古くなるためです。

---

容量ユニットのリファレンス

ワークロード別の CU 消費量

ワークロード	CU 消費モデル	主な指標
Spark（ノートブック、SJD）	Spark セッションのアクティブ中に CU 秒を消費	vCore × 継続時間
SQL DW（ウェアハウスのクエリ）	クエリごとに CU 秒を消費	クエリの複雑さ × スキャンしたデータ量
Power BI（セマンティックモデル、レポート）	クエリ／更新ごとに CU 秒を消費	データセットのサイズ、更新頻度、DAX の複雑さ
データパイプライン	アクティビティの実行ごとに CU 秒を消費	アクティビティの種類、移動するデータ量
Eventhouse／KQL	クエリと取り込みで CU 秒を消費	取り込み率、クエリ頻度
Dataflows Gen2	更新ごとに CU 秒を消費	変換の複雑さ、データ量
OneLake	ストレージのみ（保存中のデータに CU は不要）	保存データ量（GB）

Spark CU のマッピング（移行時に重要）

文書化された換算：1 Fabric CU = 2 Spark vCore（Fabric Spark の同時実行制限）。したがって、ノードあたりの CU 相当値は vCores ÷ 2 です。以下の vCore 数はプールのノード既定値です。SKU のサイズを決定する前に、必ずパイロットで実際の消費量を検証してください。

Spark プールのノードサイズ	vCore	メモリ	ノードあたりの CU 相当値（vCores ÷ 2）
Small	4 vCores	32 GB	2 CUs
Medium	8 vCores	64 GB	4 CUs
Large	16 vCores	128 GB	8 CUs
X-Large	32 vCores	256 GB	16 CUs
XX-Large	64 vCores	512 GB	32 CUs

F64 容量では、基本で 128 Spark vCore が利用でき、標準（容量課金）モデルで Spark のバースト機能を使用すると最大 3 倍（384 vCore）までバーストできます。

Spark の課金には明確に異なる 2 つのモデルがあります。混同しないでください。

1. 標準（容量課金）Spark：Spark ジョブは容量 SKU の CU を消費します。バースト（最大 3 倍）と平滑化が適用されます。消費される CU 時間 = nodes × CU-per-node × active-seconds / 3600 となり、容量に対して課金されます。
2. Spark のオートスケール課金（オプトイン、サーバーレス）：Spark ジョブを容量から切り離し、autoscale for Spark Capacity Usage CU メーターで Spark CU 時間あたりに課金する別の課金モデルです。このモデルでは、Spark ジョブは容量 CU を消費せず、Spark のバーストと平滑化は無効になります。Spark CU の上限を設定し、アクティブなセッション時間のみが課金対象になります。変動する Spark 費用を定常状態の容量費用から切り離す場合に使用してください。同じ SKU で「基本容量を超えてバースト」する機能ではありません。

Databricks から Fabric Spark へのマッピング

⚠️ 未検証の経験則：これらのマッピングは概算であり、Microsoft による公式な文書化はありません。容量のサイズを決定する前に、パイロットワークロードで検証してください。

Databricks クラスター構成	Fabric の相当構成	CU の推定値
2× Standard_D4ds_v5（各 4 vCores）	2× Small ノード	ピーク時 ~4 CUs
4× Standard_D8ds_v5（各 8 vCores）	4× Medium ノード	ピーク時 ~16 CUs
8× Standard_D16s_v5（各 16 vCores）	8× Large ノード	ピーク時 ~64 CUs
オートスケール 2～10 ワーカー（D4s）	オートスケール 2～10 Small ノード	バースト時 ~4～20 CUs

---

ワークロードのコスト見積もり

ステップ 0：現在の支出を検出する（ソースプラットフォーム）

Fabric のコストを見積もる前に、Azure Cost Management を使用して顧客の実際の現在の支出を取得します。resources/pricing-api-reference.md § Azure Cost Management API のクエリテンプレートと CLI の使用パターンを利用してください。

• サービス別の先月分（ServiceName でグループ化し、Databricks / Synapse / HDInsight / Power BI / Microsoft Fabric に絞り込み）：製品ごとのベースラインを把握します
• 日次の推移（粒度 Daily、ServiceName でグループ化）：ピーク日を把握し、ピーク時の CU 需要に対応付けます

応答を解析して、次の情報を抽出します。

• サービス別の先月分の合計支出（Databricks、Synapse、HDInsight、Power BI）
• リソースの内訳（コンピューティング、ストレージ、ネットワーク）
• 日次コストのピーク値と平均値のパターン

Azure 以外のソースプラットフォーム（AWS、GCP、Databricks、Snowflake、Teradata）

ソースが Azure 上にない場合は、そのプラットフォームから現在の支出をリアルタイムで取得してください。ソース側の価格をハードコードしたり推測したりしないでください。顧客の実際の請求額または消費量を優先し、公開リスト価格の API がある場合に限りそれを使用してください。それ以外の場合は、公式の料金ページまたは請求書を参照し、情報源と日付を明記してください。検証済みエンドポイント（AWS Price List、GCP Cloud Billing Catalog）と Databricks / Snowflake の実使用量クエリについては、resources/pricing-api-reference.md § Source Platform Pricing (Multi-Cloud) を参照してください。

Databricks 固有：クラスターの使用状況を取得する

pricing-api-reference.md § Databricks Clusters API を参照してください。COMMON-CLI.md に従ってトークンを取得し、GET /api/2.0/clusters/list を呼び出します。主なフィールドは、cluster_name、node_type_id、num_workers、autoscale です。

Synapse 固有：プールの構成を取得する

az synapse sql pool および az synapse spark pool の CLI コマンドについては、pricing-api-reference.md § Synapse Pools を参照してください。

ステップ 1：既存のワークロードをプロファイリングする

ソースプラットフォームから以下のメトリクスを収集します。

ソースプラットフォーム	収集するメトリクス	確認場所
Databricks	クラスターの稼働時間／日、DBU 消費量、ワーカー数、ノードの種類	クラスターのメトリクス、課金コンソール
Synapse Spark	プールの稼働時間、ノード数、ノードサイズ	Synapse Studio → Monitor → Apache Spark pools
Synapse SQL	DWU 時間／日、クエリ数、スキャンされたデータ量	DMV、Azure Monitor
Azure SQL/SQLDB	DTU/vCore の稼働時間、クエリパターン	Performance Insights
Power BI Premium	P-SKU のサイズ、更新頻度、ユーザー数	Power BI 管理ポータル
HDInsight	VM の稼働時間、クラスターサイズ、HDFS ストレージ	Azure の課金情報
AWS Redshift / EMR	ノードの種類、ノード数、クラスターの稼働時間、ストレージ容量（GB）	AWS Cost Explorer、AWS CLI でクラスター構成を確認
Google BigQuery / Dataproc	スロットまたはオンデマンドでスキャンされた TB 数、Dataproc の vCPU 時間	Cloud Billing エクスポート、GCP コンソール
Snowflake	ウェアハウスのサイズ、1 日あたりのクレジット消費量、ストレージ容量（TB）	ACCOUNT_USAGE.METERING_DAILY_HISTORY
Teradata Vantage	ノード／AMP 数、TCore、ストレージ、またはマーケットプレイスの従量課金単位	顧客の請求書／クラウドマーケットプレイスの使用量情報

ステップ 2：Fabric CU の需要に対応付ける

Spark ワークロード（最も一般的な移行シナリオ）：

Daily CU demand = Σ (job_duration_hours × nodes × CU_per_node)
                  where CU_per_node = node_vCores ÷ 2

Example:
- 3 Spark jobs/day
- Job 1: 2 hours × 4 Medium nodes (4 CU each) = 2 × 4 × 4 = 32 CU-hours
- Job 2: 1 hour × 2 Small nodes (2 CU each) = 1 × 2 × 2 = 4 CU-hours
- Job 3: 0.5 hours × 8 Large nodes (8 CU each) = 0.5 × 8 × 8 = 32 CU-hours
- Total daily: 68 CU-hours
- Peak concurrent: 32 CUs (Job 1 or Job 3)

SQL ウェアハウスのワークロード（Synapse Dedicated SQL / DW）：

DWU から CU への換算式を使ってサイズを決めないでください。Microsoft は公式な換算値を公開していないため、DWU ÷ 2 の数値は確約済み SKU の選定には使えません。代わりに、顧客の実際の課金データを基に見積もり、パイロットで検証します。

Workflow (measured, not heuristic):
1. Pull the customer's real DWU-hours/day from their Synapse invoice line
   or Azure Cost Management (Meter: "cDWU" / "Compute"), not from peak DWU.
2. Run a representative workload on the smallest candidate Fabric F-SKU and
   read measured CU-seconds from the Capacity Metrics app (see § Validation).
3. Scale that measured CU/DWU-hour ratio to the customer's total DWU-hours,
   then feed the resulting CU demand into the live-API SKU pricing lookup.
4. Present the number as pilot-validated, never as a formula output.

⚠️ パイロットなしで確約できるサイズを提示しないでください。 まだパイロットを実施できない場合は、DWU 時間を測定対象の入力値として示し、パイロットデータが得られるまで見積もりは保留であると明記してください。成果物として DWU ÷ 2 の CU 値を提示しないでください。

Power BI ワークロード：

CU demand ≈ P-SKU CU equivalent × utilization%

P1 = 64 CUs (F64), P2 = 128 CUs (F128), P3 = 256 CUs (F256), P4 = 512 CUs (F512), P5 = 1024 CUs (F1024)
EM1/A1 = 8 CUs (F8), EM2/A2 = 16 CUs (F16), EM3/A3 = 32 CUs (F32)

Example — single Power BI P-SKU, like-for-like migration:
- P2 at 70% avg utilization, 15 refreshes/day
- P2 direct equivalent = 128 CUs (F128)
- Effective sustained demand: 128 × 0.70 ≈ 90 CUs. Refresh bursts are short and
  absorbed by capacity smoothing, so the sustained concurrent demand stays ~90 CUs.
- Apply the 1.2× safety factor to the *demand* (NOT the source nameplate):
  90 × 1.2 = 108 CUs → round up to next tier → **F128**
- F128 is the direct P-SKU equivalent and already provides headroom over a
  sub-100% workload. Do NOT multiply the source P-SKU's *rated* nameplate
  (128) by the safety factor — the nameplate already exceeds the utilized
  demand, so 128 × 1.2 → F256 double-counts headroom and over-provisions.

ステップ 3：集計してサイズを決める

Sized CU = max over time of (Σ concurrent CU across all workloads in that window) + headroom
           (workloads share one capacity; size to the worst-case *concurrent sum*,
            NOT max(individual workload peaks) — peaks in different workloads can coincide)

Build a time-bucketed demand curve (e.g., hourly) summing Spark + SQL + PBI + Pipelines
CU in each bucket, then take the maximum bucket.

Recommended SKU = next SKU above (max_concurrent_CU × 1.2 safety factor)
  where max_concurrent_CU is the worst-case *effective/measured* concurrent CU
  DEMAND (already utilization-adjusted) — NOT a source SKU's rated nameplate.
  For a single Power BI P-SKU like-for-like migration, the recommendation is the
  direct CU-equivalent tier (P1→F64, P2→F128, P3→F256); do not inflate it further.

Two billing options for Spark:
  A) Standard (capacity-billed): include Spark CU in the concurrent sum above (one SKU).
  B) Autoscale Billing for Spark: size the base SKU for SQL + PBI + Pipelines only;
     Spark is offloaded and billed separately (does not consume capacity CUs).

注：容量の平滑化によって短時間のバースト（対話型は約 5～64 分、バックグラウンドは最大 24 時間）は再配分されますが、定常状態での同時実行の合計は減りません。継続的な同時需要に合わせてサイズを決めてください。

---

ストレージの料金

ライブ検索：OneLake ストレージ料金

Azure Retail Prices API から、顧客のリージョンにおける OneLake ストレージ料金を取得します。OneLake ストレージは階層化されており、単一の OneLake Storage メーターは存在しません（このフィルターでは 0 件が返されます）。階層別のメーター名を使い、データのアクセスパターンに一致する階層を選択してください。メーター名は OneLake Storage Hot Data Stored、OneLake Storage Cool Data Stored、OneLake Storage Cold Data Stored です。ミラーリングされたレプリカには Storage Mirroring Data Stored を使用します（フィルター：serviceName eq 'Microsoft Fabric' and armRegionName eq '<region>'。reservationTerm を含む行は無視してください）。フィルターで 0 件が返された場合は、そのリージョンの Fabric ストレージメーターをすべて一覧表示してユーザーに示してください。ハードコードされた料金を黙って使用してはいけません。実行可能なテンプレートについては、resources/pricing-api-reference.md を参照してください。

ストレージの種類と料金モデル

ストレージの種類	料金検索フィルター	備考
OneLake（マネージド Delta/Parquet）	meterName eq 'OneLake Storage Hot Data Stored'（または Cool/Cold）	Fabric の主要ストレージです。アクセスパターンに応じて階層化されます
OneLake ショートカット（コピーなし）	$0（ショートカットのメタデータのみ）	ソースストレージの料金は引き続き適用されます
ADLS Gen2（ショートカット経由のソース）	serviceName eq 'Storage' and skuName eq 'Hot LRS'	既存のストレージであり、重複はありません
ミラーリングストレージ	meterName eq 'Storage Mirroring Data Stored'	OneLake 内の Delta レプリカ

既存プラットフォームからのストレージ容量の見積もり

ソース	メトリック	Fabric での相当量
Databricks DBFS／マネージドテーブル	Delta テーブルの合計サイズ（GB）	OneLake Tables/ でも同じサイズ
Synapse Spark マネージドテーブル	ADLS Gen2 の synfs コンテナーサイズ	移行またはショートカットを使用。同じサイズ
Synapse SQL DW ストレージ	DBCC PDW_SHOWSPACEUSED	おおむね同じ（Delta 形式）
Power BI データセット	モデルサイズ（圧縮後、メモリ内）	データセットのインポートでは、非圧縮 Delta の場合、圧縮後のサイズの 2～4 倍
HDInsight HDFS	HDFS の du 出力	Delta に変換。通常は生データと比べて 30～60％圧縮

---

ネットワークのデータ送信料金

ライブ検索：データ送信レート

serviceName eq 'Bandwidth' and armRegionName eq '<region>' and meterName eq 'Standard Data Transfer Out' フィルターを使って、顧客のリージョンの帯域幅／データ送信レートを取得します（reservationTerm がある行は無視してください）。実行可能なテンプレートについては、resources/pricing-api-reference.md を参照してください。

データ送信コストモデル

Azure のデータ送信料金は階層制であり、データの送信元によって適用されるメーターが変わります。GB あたりの単一の定額料金を適用してはいけません。まず階層と送信元を特定し、その後で最新の料金を検索してください。

シナリオ	料金の参照元	軽減策
同一リージョン内	無料	容量とストレージを同じ場所に配置します
インターネットへのデータ送信の第 1 階層	Bandwidth API：最初の 100 GB／月は無料（meterName eq 'Standard Data Transfer Out'）、以降は階層制	少量の転送を無料枠内にまとめます
インターネットへのデータ送信（無料枠超過分）	Bandwidth API：月間転送量に応じた階層制。GB 数が増えると段階的に料金が下がります	パブリックダウンロードを最小限にし、各料金階層を個別に計算します
リージョン間のデータ送信	Bandwidth API：meterName eq 'Inter Region Data Transfer Out'	OneLake のリージョンショートカットを使用します
クロスクラウドのソース（AWS/GCP → Fabric）	Azure ではなく、ソースクラウドのデータ送信メーター（AWS Data Transfer Out／GCP Network Egress）	同じクラウドのショートカットを経由してステージングします。データ送信料金はデータの発生元のクラウドで課金されます
Private Link／Private Endpoint	標準のデータ送信料金に加えて、PE の時間料金および GB あたりの PE データ処理料金	コンプライアンス要件がある場合に使用します。3 つすべての料金項目を予算に含めてください

移行時のデータ送信コストの見積もり：一度限りの移行では、移行するデータ量を該当する各料金階層（無料 → 第 1 階層 → 第 2 階層 …）に割り当て、各階層の最新のレートを適用します。AWS/GCP から移行する場合は、ソースクラウドのデータ送信コストも加算してください。同一リージョン内の Azure 間のデータ移動：$0。

---

課金モードの戦略

判断フレームワーク

┌─────────────────────────────────────────────────────────────┐
│ Is the workload Spark-heavy (>50% of CU demand)?            │
│                                                             │
│ YES → Consider Autoscale Billing for Spark (offloads Spark  │
│       from capacity, billed separately) + Reserved Instance │
│       sized for the non-Spark base (SQL + PBI + Pipelines). │
│       Alternative: one capacity-billed SKU sized for the    │
│       full concurrent sum if you prefer a single bill.      │
│                                                             │
│ NO → Is demand predictable and steady?                     │
│      YES → Reserved Instance (1-year or 3-year)            │
│      NO  → Pay-As-You-Go (for evaluation period)          │
│            then reassess after 30 days of metrics          │
│                                                             │
│ Intermittent (dev/test, scheduled batch windows)?          │
│   → Pause/resume the capacity (billing stops while paused) │
│     instead of, or combined with, PAYG.                    │
└─────────────────────────────────────────────────────────────┘

Spark を多用するワークロード：Spark の自動スケール課金と標準キャパシティの比較

Spark には異なる 2 つの課金モデルがあります。同じ Spark ジョブに対して併用することはできないため、どちらかを選択してください。

• 標準（キャパシティ課金）：Spark はキャパシティ SKU の CU を消費します（3 倍のバーストと平滑化が適用されます）。すべてのワークロード（SQL + PBI + Pipelines + Spark）の同時実行 CU 合計を時間の経過に沿ってまかなえる SKU を 1 つ選びます。
• Spark の自動スケール課金（オプトインのサーバーレス）：Spark ジョブはキャパシティから切り離され、autoscale for Spark Capacity Usage CU メーターで Spark CU 時間ごとに個別に課金されます。Spark ではバーストと平滑化が無効になり、これらのジョブはキャパシティ CU を消費しません。これにより、Spark 以外の通常時の負荷（SQL DW + Power BI + Pipelines）に合わせてベースキャパシティを選び、Spark は最大 Spark CU 上限を設定して個別に支払えます。

Spark の自動スケール料金（$/CU-hour）をリアルタイムで取得してください。**ベース料金／PAYG 料金を流用せず、値をハードコードしないでください。**自動スケールや損益分岐点に関する質問では、最初にシェルでこの取得処理を実行し、API が返す retailPrice を確認してください。

curl -s "https://prices.azure.com/api/retail/prices?api-version=2023-01-01-preview&\$filter=serviceName%20eq%20'Microsoft%20Fabric'%20and%20armRegionName%20eq%20'<region>'%20and%20meterName%20eq%20'autoscale%20for%20Spark%20Capacity%20Usage%20CU'" | jq '.Items[] | select(.reservationTerm == null) | {meterName, retailPrice, unitOfMeasure, armRegionName}'

返された行の retailPrice の値を自動スケール料金として使用してください。該当リージョンの行が返されない場合は、そのリージョンの Fabric Spark メーターをすべて一覧表示して提示してください。ベース料金を推測、コピー、流用してはいけません。実行可能なテンプレートについては、resources/pricing-api-reference.md を参照してください。

見積もり式（自動スケール課金モデル、リアルタイム料金を使用）：

Example (fill in live prices from API):
- SQL DW peak: 16 CUs
- Power BI peak: 8 CUs  
- Spark peak: 64 CUs (but only 4 hours/day)
- Pipelines: 4 CUs

Base capacity (standard, capacity-billed): sized for SQL + PBI + Pipelines = 16 + 8 + 4 = 28 CUs raw
  → apply 1.2× safety: 28 × 1.2 = 33.6 CUs → round up to next tier → **F64**
  Monthly cost: [look up F64 1-Year RI rate from API, amortized ÷ 12]
  
Spark (Autoscale Billing, offloaded from capacity):
  64 CU × 4 hours/day × 30 days = 7,680 CU-hours/month
  Cost: 7,680 × [live 'autoscale for Spark Capacity Usage CU' rate from API]

Total: [base RI ÷ 12] + [Spark autoscale] + [storage] + [egress]
Compare vs. current spend from Cost Management API above.

予約インスタンスと PAYG の損益分岐点

静的な使用率のしきい値に依存してはいけません。特定の SKU とリージョンの最新の料金から損益分岐点を計算してください。

monthlyAmortizedReservationCost = skuCUs × reservationRetailPrice ÷ (12 for 1-yr | 36 for 3-yr)
paygMonthlyAtFullUse            = skuCUs × paygCuHourRate × 730
breakEvenHoursPerMonth          = monthlyAmortizedReservationCost ÷ (skuCUs × paygCuHourRate)

→ If expected billed hours/month > breakEvenHoursPerMonth, the RI wins.
→ Express RI savings as (paygMonthlyAtFullUse − monthlyAmortizedReservationCost) ÷ paygMonthlyAtFullUse.

reservationRetailPrice（契約期間全体の料金）と paygCuHourRate（priceType eq 'Consumption'、* Capacity Usage CU メーターから）は、どちらも Retail Prices API から取得します。需要の変動が大きい場合や季節変動がある場合は、小さめの RI ベースと PAYG、または変動分に対する Spark の自動スケール課金を組み合わせてください。

---

SKU サイジングの判断ツリー

入力変数

ユーザーから次の情報を収集します。

1. 全ワークロードにおけるピーク時の同時実行 CU 需要
2. 1 日あたりの平均消費 CU 時間
3. ワークロードの構成比（Spark、SQL、PBI、その他の割合）
4. 成長予測（12 か月の予測）
5. コンプライアンス要件（Private Link、専用キャパシティ）
6. 予算の制約（月額上限）

サイジングアルゴリズム

1. Build a time-bucketed concurrent-demand curve; concurrent_CU = Σ workload CU per bucket
2. peak_CU = max concurrent_CU over the curve (NOT max of individual workload peaks)
3. Pick the CU basis by billing mode (Spark is the only workload that can be offloaded):
     If using Autoscale Billing for Spark:
       basis_CU = max concurrent (SQL + PBI + Pipelines)   # Spark offloaded, billed separately
     Else (standard, capacity-billed):
       basis_CU = peak_CU                                  # Spark included in the concurrent sum
4. Apply the growth forecast to the CU DEMAND, before sizing (never to a chosen SKU —
   multiplying a SKU by a growth factor can invent a tier that does not exist):
     projected_CU = basis_CU × (1 + growth_rate)
5. Apply the 1.2x safety factor to the projected demand (BOTH billing modes, incl. the
   Autoscale base):
     sized_CU = projected_CU × 1.2
6. Round UP to the next real SKU tier. The ONLY valid Fabric capacity tiers are
   **F2, F4, F8, F16, F32, F64, F128, F256, F512, F1024, F2048, F4096, F8192**
   (CUs double at each step). There are NO in-between sizes: never name an
   interpolated tier such as F48, F96, F192, or F1500 — always snap to an
   existing tier from that list, even in comparisons, ranges, or asides.
7. Validate: chosen-SKU monthly cost ≤ budget constraint
8. If budget exceeded: recommend workload optimization or phased migration

SKU クイックリファレンスセレクター

サイジング後の CU をこの表に入力します。つまり、まずサイジングアルゴリズムの手順 1～5 を実行して sized_CU = peak_CU × (1 + growth_rate) × 1.2 を計算し、その値を（ピーク需要の生値ではなく）階層に割り当てます。安全係数と成長率は左列にすでに反映されているため、重ねて適用しないでください。

サイジング後の CU（成長率 + 1.2 倍の安全係数を適用）	推奨ベース SKU	備考
≤ 2 CUs	F2	試用／ごく小規模な開発
3–4 CUs	F4	開発／テスト、小規模チーム
5–8 CUs	F8	小規模な本番環境
9–16 CUs	F16	中規模の本番環境
17–32 CUs	F32	標準的な本番環境
33–64 CUs	F64	大規模な本番環境、複数チーム
65–128 CUs	F128	エンタープライズ
129–256 CUs	F256	大規模エンタープライズ
257–512 CUs	F512	非常に大規模なエンタープライズ
513–1024 CUs	F1024	複数チームが利用するエンタープライズプラットフォーム
1025–2048 CUs	F2048	非常に大規模な環境
2049–4096 CUs	F4096	ハイパースケール環境
4097–8192 CUs	F8192	単一キャパシティで最大の階層
> 8192 CUs	複数のキャパシティ	複数キャパシティのアーキテクチャ／ワークスペースの分割を検討

---

移行コストのワークシート

テンプレート：ユーザーへの提示

移行コストを見積もる際は、上記の API から取得した最新データを使用します。次の主要なセクションを含むワークシートを作成してください。

• ヘッダー — 顧客／プロジェクト名、リージョン、価格の基準日、データソース
• 現在の支出 — Cost Management API から取得したプラットフォームごとの最新の月額コスト（Databricks、Synapse SQL/Spark、Power BI Premium、Storage）
• ソースワークロードプロファイル — 1 日あたりの Spark ジョブ数、1 日あたりの SQL DWU 時間、Power BI SKU の使用率、パイプライン実行数、ストレージ容量（TB）
• Fabric の CU 需要 — ワークロードの種類ごとのピーク時と平均の CU 推定値、および合計
• 推奨構成 — ベース SKU（F ティア）、Spark の課金モード、RI の契約期間
• 月額コストの内訳 — 最新の API 価格に基づく容量、Spark オートスケール、ストレージ、ネットワーク送信の各コスト
• 現在のコストとの比較 — 差額と変化率

印刷可能なテンプレート全体については、resources/cost-estimation-worksheet.md を参照してください。

---

必須／推奨／回避

必ず行うこと

• 比較対象の両方について、必ず最新の価格を取得してください。 対象（Fabric）の価格は Azure Retail Prices API（prices.azure.com）から取得し、ソースプラットフォームの価格は、そのプラットフォームの最新の課金／価格 API または顧客の実際の請求書から取得してください。どちらについても、金額をハードコードしないでください。
• ヒューリスティックな換算だけで SKU や確定コストを決定しないでください。 すべてのプラットフォーム間の vCore→CU および DWU→CU の対応付けは、パイロットでの検証にのみ使用する入力値として扱ってください（Fabric 内部の 1 CU = 2 Spark vCores という比率は文書化されていますが、ソースエンジンから Fabric への同等性は確認されていません）。ヒューリスティックから算出した数値は暫定値として提示し、確定したサイジングや RI の購入前に、パイロットワークロード（Capacity Metrics アプリで測定した CU 消費量）の実施を必須としてください。
• 顧客のリージョンを検出してください。 既存の Fabric 容量から特定するか、明示的に確認してください。価格はリージョンによって異なります。
• 顧客が Azure サブスクリプションにアクセスできる場合は、Azure Cost Management API から現在の支出を取得してください。 これにより、比較の基準を設定できます。
• 見積もりの前に、必ずソースワークロードプロファイルを確認してください。 ワークロードの規模を想定しないでください。
• すべてのコスト要素を含めてください。 コンピューティング（CU）、ストレージ、ネットワーク送信、プレミアム機能（Private Link、BCDR）を含みます。
• データソースを明確に記載してください。 リージョン、通貨、API クエリ日、および検証用の Azure Pricing Calculator へのリンクを記載します。
• Spark の CU 需要が 50% を超える場合は、Spark の Autoscale Billing を別途計上してください。 この課金モデルでは Spark は容量から切り離され、独立して課金されます。ベース容量にまとめて計上しないでください。
• SKU の選定前に、ピーク時の CU 需要に 1.2 倍の安全係数を適用してください。
• RI の分析を含めてください。 推奨 SKU について、PAYG、1 年、3 年の比較を示します。
• ワークシートのテンプレートを提示し、すべての項目を最新のデータで埋めてください。

推奨

• Spark の比重が高いワークロードには、Spark の Autoscale Billing を推奨します。 Spark を容量から切り離して個別に課金することで、バースト性のある Spark ジョブに備えたベース SKU の過剰なプロビジョニングを回避できます（この課金モデルでは、Spark のバーストと平滑化は無効になります）。
• Spark の比重が高い混合ワークロードには、RI のベース容量と Spark の Autoscale Billing の組み合わせをデフォルトで推奨します。
• 既存の ADLS Gen2 データには、データコピーより OneLake Shortcuts を推奨します。 ストレージコストの二重計上を回避できます。
• 容量とストレージは同じ Azure リージョンに配置することを推奨します。 リージョン間のデータ送信コストをなくせます。
• 予算に制約がある場合は、段階的な移行を推奨します。 F8/F16 から開始し、段階的にスケールアップします。
• 移行後は、毎月の使用率監視を推奨します。 実際の使用状況データを 30 日以上収集してから RI を推奨してください。
• 見積もりにワークロードの平滑化を含めてください。 Fabric は、対話型のバーストを約 5～64 分にわたって、バックグラウンドジョブを最大 24 時間にわたって平滑化します。ただし、Autoscale Billing を利用する Spark では、平滑化が無効になります。平滑化によってバーストは再分配されますが、定常状態における同時需要は低下しません。

避けるべきこと

• 価格をハードコードしないでください — 常に最新の情報源を使用してください（Fabric には Azure Retail Prices API、現在の支出には各プラットフォームの価格 API または実際の請求書を使用します）。ハードコードした値は古くなります
• 公開価格 API がないプラットフォーム（Databricks DBU、Snowflake クレジット、Teradata）の価格を推測しないでください — 顧客の実際の使用量または請求書、あるいは公式価格ページを使用し、その出典を明記してください
• 出典と日付を記載せずに価格を提示しないでください — 必ず「[日付] 時点の Azure Retail Prices API に基づく」と記載してください
• 定常状態が確立される前に 3 年間の RI を推奨しないでください — ワークロードのパターンが実証されるまで待ってください（最低 3 か月）
• ピーク時の Spark 処理だけを基準に容量を決めないでください — Spark を同時実行 CU の合計に含める（標準）か、Spark の Autoscale Billing を使ってオフロードしてください。ベース SKU でカバーするのは、Spark 以外の定常状態です
• Power BI の CU 消費を無視しないでください — セマンティックモデルの更新や対話型クエリは、多くの CU を消費します
• 複数リージョンまたはハイブリッドアーキテクチャでは、ネットワークのエグレスを忘れないでください
• CU と vCore を混同しないでください — CU は Fabric の統一された課金単位で、vCore は Spark の実行リソースです。Fabric Spark 内では、vCore から CU への比率が文書化されている（1 CU = 2 Spark vCore。「Spark CU Mapping」セクションを参照）ため、Fabric プールノードから CU への換算は一意に決まります。ヒューリスティックなのは、プラットフォーム間の同等性、つまりソースエンジンの vCore（Databricks／Synapse／EMR）を Fabric CU に換算することであり、SKU サイズを確定する前にパイロットで検証する必要があります
• Cost Management API の確認を省略しないでください — ユーザーが Azure にアクセスできる場合は、必ずプログラムを使って現在の支出のベースラインを把握してください

---

例

例 1：Databricks 移行のコスト見積もり

ユーザーのプロンプト：「毎日、4×D8s_v5 クラスターで約 3 時間実行する Databricks Spark ジョブが 5 つあり、Power BI P1 と 2TB の Delta テーブルもあります。Fabric ではいくらかかりますか？」

エージェントのワークフロー：

1. リージョンを特定します（ユーザーに尋ねるか、GET /v1/capacities または ARM で既存の容量を確認します。§ Fabric capacity discovery を参照）
2. Cost Management API を使って Databricks の現在の支出を取得します
3. Retail Prices のページネーションパターンを使って Fabric の最新の価格を取得します
4. CU の需要を計算し、ワークシートを提示します

CU の計算ロジック：

Spark: 5 jobs × 3h × 4 nodes × 4 CU/node (D8s_v5 = 8 vCores = Medium = 4 CU) = 240 CU-hours/day
Peak concurrent (2 jobs overlap): 2 × 4 × 4 = 32 CUs → candidate for Autoscale Billing for Spark
PBI: P1 = 64 CUs (F64 equivalent) — steady-state base
Storage: 2 TB × OneLake tiered rate (from API)

Recommended config (Autoscale Billing for Spark option):
  Base: F64 (1-Year RI) — covers Power BI P1 steady-state
  Spark: Autoscale Billing — 240 CU-hours/day × 30 days × live 'autoscale for Spark Capacity Usage CU' rate
  Storage: 2 TB × 1024 GB × live OneLake Hot rate
  Total = (Base RI ÷ 12) + Spark Autoscale + Storage

価格の検索：Retail Prices API を armSkuName eq 'Fabric_Capacity_CU_Hour' + armRegionName eq '<region>' + meterName eq 'Fabric Capacity CU' でフィルターします。reservationTerm はフィルター可能な OData フィールドなので、reservationTerm eq '1 Year' で 1 年契約の行を直接取得するか、返された各行からフィールドを読み取ることができます。その契約期間の合計額を 12 で割り、64 CU を掛けて月額に換算します。Spark の料金には meterName eq 'autoscale for Spark Capacity Usage CU' を、ストレージには meterName eq 'OneLake Storage Hot Data Stored' を使用します。ページネーションとフィルターパターンの詳細は、pricing-api-reference.md を参照してください。

例 2：Synapse SQL DW の移行

ユーザーのプロンプト：「Synapse DW1000c を 1 日あたり 18 時間実行しており、ウェアハウスデータが 5TB あります。」

エージェントのワークフロー：

1. Cost Management API を使って Synapse の現在の支出を取得します（フィルター："Azure Synapse Analytics"）
2. 顧客のリージョンについて、Retail Prices のページネーションパターンを使って Fabric の最新の価格を取得します
3. CU の需要を計算し、SKU を推奨します

CU の計算ロジック：

Sizing input: the customer's measured DWU-hours/day from their Synapse invoice
(DW1000c × 18h ≈ 18,000 DWU-hours/day) — NOT a DWU ÷ 2 CU formula.
Pilot the workload on a candidate F-SKU, read CU-seconds from Capacity Metrics,
and scale the measured CU/DWU-hour ratio to total DWU-hours.
Do NOT apply an assumed engine-efficiency discount; size from the pilot's measured CU,
not from a guessed "% less CU" factor.
Pilot-start SKU: F512 as a conservative starting tier to run the pilot on.

Pricing (from API):
  F512 PAYG monthly: paygCuHourRate × 512 CUs × 730   (priceType eq 'Consumption', '* Capacity Usage CU' meter)
  F512 1-yr RI monthly: reservationRetailPrice × 512 CUs ÷ 12   (reservation row is a TERM TOTAL, not ×730)
  Storage: 5 TB × 1024 × OneLake Hot rate

Recommendation: Start F512 PAYG → monitor 30 days → right-size down (e.g., to F256 RI) if measured CU is lower