Microsoft Fabric Data Warehouseの制限事項を確認するうえで重要なのは、「使える／使えない機能の一覧」として読むだけでなく、リージョン、SQL分析エンドポイント、データ型、保持期間、移行、CI/CDの設計にどう影響するかまで落とし込むことです。
結論から言うと、2026年5月8日時点で管理者や開発者が最優先で確認すべきポイントは、Fabric Data WarehouseとSQL analytics endpointの接続は同一リージョン前提であること、Lakehouse由来テーブルの自動検出にはDelta Parquetと/tables配下が重要であること、varchar(max)やデータ型の扱いに差があること、保持期間設定がTime travel・Clone table・Restore・Warehouse snapshotに影響することです。公式の「Limitations of Fabric Data Warehouse」はWarehouseとSQL analytics endpointに適用される制限事項をまとめたページであり、Fabric内のSQL databaseとは対象が異なります。(Microsoft Learn)
なお、確認時点では中心となる英語版「Limitations of Fabric Data Warehouse」ページのメタデータ上の更新日は2026年4月24日ですが、関連するData retention、Clone table、保持期間設定の公式ページは2026年5月8日に更新されています。実務では、制限事項ページだけでなく、関連ページに分かれている機能別の制限も併せて確認する必要があります。(GitHub)
Microsoft Fabricの「Limitations of Fabric Data Warehouse – Microsoft Fabric」で押さえるべき変更点
「Limitations of Fabric Data Warehouse – Microsoft Fabric」は、Fabric Data Warehouseを本番利用する前の設計チェックリストとして読むべき公式情報です。特に注意したいのは、制限事項が単に「一部機能が未対応」という意味ではなく、ワークスペース設計、データ配置、接続方式、移行手順、デプロイ方式に直接影響する点です。
| 確認項目 | 公式情報の要点 | 実務で取るべき対応 |
|---|---|---|
| リージョン | Fabric Data WarehouseとSQL analytics endpointの接続は、ソースとターゲットが同一リージョンにある必要があり、異なるリージョン間の接続は認証や接続に失敗する可能性があります。(Microsoft Learn) | 容量、ワークスペース、Lakehouse、Warehouseを作成する前にリージョンをそろえる。あとからまたぐ設計にしない。 |
| SQL analytics endpointの自動検出 | 自動検出されるにはDelta Parquet形式が前提で、/tables配下以外のDeltaテーブルはSQL analytics endpointに表示されません。(Microsoft Learn) | Lakehouseにデータを置く際、分析対象テーブルは/filesではなく/tables配下に配置する。 |
| データ型 | SQL analytics endpointやWarehouseでは、サポートされる永続化データ型に制限があります。未対応型は列として表現されない、または代替型への変換が必要になる場合があります。(Microsoft Learn) | 移行前にnvarchar、datetime、money、xml、jsonなどの扱いを確認し、変換方針を決める。 |
varchar(max) | SQL analytics endpointでは、mirrored itemやFabric databaseではvarchar(max)が扱われますが、LakehouseのSQL analytics endpointでは8KB切り捨ての影響が残る点に注意が必要です。(Microsoft Learn) | 長い文字列をキーや結合条件に使っている場合は、結合結果や切り捨てを検証する。必要に応じてvarchar(8000)へ明示変換する。 |
| 保持期間 | Warehouseのデータ履歴は既定で30日保持され、1〜120日の範囲で設定できます。保持期間はTime travel、Clone table、Restore point、Warehouse snapshotに影響します。(Microsoft Learn) | 本番環境では監査、復旧、ストレージコストを踏まえて保持期間を設計する。短縮前に復旧要件を確認する。 |
| ワークスペース内アイテム数 | 1つのワークスペースでWarehouseとSQL analytics endpointを合計150個までサポートします。(Microsoft Learn) | 部門別・環境別にワークスペース分割を検討し、無計画にWarehouseを増やさない。 |
| CI/CD・ソース管理 | Git統合やデプロイパイプラインでは、ALTER TABLEで制約や列を追加するとテーブルの削除・再作成につながり、データ損失のリスクがあります。(Microsoft Learn) | 本番デプロイ前に差分スクリプトの挙動を確認し、必要なら新テーブル作成、データ移行、リネームで安全に展開する。 |
対象者は管理者、データエンジニア、BI開発者
今回の制限事項は、Fabric Data Warehouseを操作する一部の開発者だけでなく、管理者、データエンジニア、BI開発者、移行担当者に影響します。
管理者が確認すべきこと
管理者は、まずリージョン、容量、ワークスペース、アクセス権、保持期間、アイテム数を確認します。特にリージョンは、後から修正しにくい設計要素です。WarehouseとSQL analytics endpointの接続は同一リージョン前提であるため、複数リージョンに分散したワークスペースや容量を使っている場合は、接続失敗や認証失敗の原因になります。(Microsoft Learn)
また、保持期間の変更は復旧可能な履歴に影響します。保持期間を短くすると、対象外になった履歴データはクリーンアップ対象になり、あとから保持期間を戻しても削除済み履歴は復元できない可能性があります。(Microsoft Learn)
管理者が最初に確認する項目は次のとおりです。
| 確認項目 | 確認方法 | 見落とした場合のリスク |
|---|---|---|
| 容量とワークスペースのリージョン | Fabric管理画面、容量設定、ワークスペース設定 | SQL接続や認証が失敗する |
| WarehouseとSQL analytics endpointの数 | ワークスペース内のアイテム棚卸し | 150個上限に近づき、新規作成できない |
| 保持期間 | sys.databasesで確認 | Time travelや復旧可能期間を誤認する |
| 管理者ロール | Workspace roleを確認 | 保持期間や展開設定を変更できない |
| Git統合・デプロイパイプライン | ワークスペースのSource control設定 | 本番展開時にテーブル再作成やデータ損失が起きる |
開発者が注意すべきSQL analytics endpointの制限
SQL analytics endpointは、LakehouseやWarehouseのデータをSQLで扱える便利な入口ですが、通常のSQL Serverと同じ感覚で設計すると詰まりやすい箇所があります。
Lakehouseのテーブルは/tables配下に置く
SQL analytics endpointで自動検出されるには、データがDelta Parquet形式であることが前提です。また、Lakehouse内の/tables配下にないDeltaテーブルはSQL analytics endpointに表示されません。/files配下に置いたデータは、ファイルとしては存在していても、SQLから見えるテーブルとしては扱われない点に注意が必要です。(Microsoft Learn)
よくある失敗例は、データエンジニアがSparkやDataflowで/files配下にデータを出力し、BI担当者が「SQL analytics endpointにテーブルが出ない」と問い合わせるケースです。この場合、データの中身ではなく、配置場所が原因になっている可能性があります。
Delta column mappingは「by name」と「by ID」で扱いが違う
公式情報では、Delta column mapping by nameはサポートされる一方、by IDはサポートされないとされています。列名変更やスキーマ変更を含むDeltaテーブル運用では、SQL analytics endpointで列が期待どおりに見えるかを検証する必要があります。(Microsoft Learn)
外部キー制約がスキーマ変更を止める場合がある
SQL analytics endpointでテーブル間に外部キー制約を追加すると、その後のスキーマ変更、たとえば新しい列の追加ができなくなる可能性があります。Delta Lake側には列があるのにSQL analytics endpoint側に表示されない場合、データ型だけでなく外部キー制約も確認すべきです。(Microsoft Learn)
varchar(max)とデータ型の扱いは移行前に必ず検証する
Fabric Data Warehouseでは、すべてのT-SQLデータ型を永続化できるわけではありません。Warehouseで永続化できるデータ型はSQL Serverの同名データ型をベースにしていますが、サポート範囲は限定されています。たとえば、varchar(max)とvarbinary(max)の保存上限は現在16MBとされています。(Microsoft Learn)
一方、SQL analytics endpointでは、Lakehouse、mirrored item、Fabric databaseでvarchar(max)の扱いに差があります。特にLakehouseのSQL analytics endpointでは、テーブルによって8KB切り捨ての影響が残るため、長い文字列列を比較、結合、キー扱いする場合は事前検証が必要です。(Microsoft Learn)
移行時に変換を検討すべき主なデータ型
| 既存環境で使われやすい型 | Fabric Data Warehouseでの考え方 | 実務上の判断 |
|---|---|---|
money、smallmoney | 代替としてdecimalを検討 | 通貨単位は別列や業務定義で管理する |
datetime、smalldatetime | datetime2を検討 | 精度とタイムゾーン処理を移行前に確認する |
nchar、nvarchar | char、varcharを検討 | UTF-8照合順序と文字数・バイト数の影響を確認する |
json | varcharを検討 | JSONを列として検索する頻度が高い場合は設計を見直す |
xml | 直接の同等型なし | 文字列化、分解、別ストレージ化を検討する |
geography、geometry | 緯度経度列、WKB、WKTなどで代替 | BI用途か空間演算用途かで保存形式を決める |
未対応の型は、クエリ内の変数や一時的な処理では使える場合があっても、テーブルや永続化オブジェクトとして保存できない場合があります。移行アセスメントでは、DDLだけでなく、ビュー、ストアドプロシージャ、ETLの中間テーブルまで確認してください。(Microsoft Learn)
保持期間の設定は「コスト削減」だけで判断しない
2026年5月8日更新の関連公式情報で特に重要なのが、Fabric Data Warehouseのデータ保持期間です。Warehouseはデータ履歴を既定で30日保持し、1〜120日の範囲で設定できます。この保持期間は、Time travel、Clone table、Restore point、Warehouse snapshotで過去データを参照できる範囲を決めます。(Microsoft Learn)
保持期間を長くすれば復旧や監査に強くなりますが、OneLakeストレージ消費は増えます。逆に短くすればストレージコストを抑えやすくなりますが、復旧可能な履歴が短くなります。公式情報では、保持期間を短くした場合、データアクセスの観点では不可逆的な影響があると説明されています。(Microsoft Learn)
保持期間を確認・変更するT-SQL
保持期間を確認するには、sys.databasesを使って現在の保持日数と実際の利用可能なカットオフ日を確認します。保持期間を変更できるのはAdminワークスペースロールのユーザーで、Member、Contributor、Viewerは現在の設定確認はできますが変更はできません。(Microsoft Learn)
SELECT
name,
time_travel_retention_period_days,
time_travel_retention_cutoff_date
FROM sys.databases;保持期間を15日に変更する場合は、次のように指定します。
ALTER DATABASE CURRENT
SET TIME_TRAVEL_RETENTION_PERIOD = 15 DAYS;設定値は1〜120日の整数日で指定します。小数日は指定できず、保持期間の計算にはUTCが使われます。(Microsoft Learn)
保持期間を変更する前の判断基準
| 利用シーン | 推奨される考え方 |
|---|---|
| 本番データウェアハウス | 障害復旧、誤更新、監査対応を考慮し、短くしすぎない |
| 開発・検証環境 | 履歴の重要度が低ければ1〜7日程度も検討できる |
| 大量更新が多い環境 | フルロードや大量MERGEが多いほど履歴データが増えやすいため、ストレージ監視が必要 |
| 監査・コンプライアンス重視 | 90日や120日など長めの保持を検討する。ただし組織の要件とコストを確認する |
| SnapshotやCloneを使う環境 | 参照したい過去時点が保持期間内に収まるか確認する |
Clone tableやWarehouse snapshotへの影響
Clone tableは、OneLake上のデータファイルをコピーせず、メタデータを使って過去時点または現在時点のテーブル複製を作る機能です。開発、テスト、復旧、過去時点のレポート作成に役立ちます。(Microsoft Learn)
ただし、Clone tableを作成できる過去時点は、構成済みの保持期間内に限られます。保持期間より前の時点に対するクローンは作成できません。また、ワークスペースをまたぐClone table、Warehouse間のClone table、Warehouse全体やスキーマ全体のクローン、LakehouseのSQL analytics endpointでのクローンはサポートされていません。(Microsoft Learn)
実務では、リリース前の退避や検証用コピーとしてClone tableを使う場合、次の2点を確認してください。
- クローンしたい時点が保持期間内にあるか
- スキーマ変更前の時点に戻れるか
特にスキーマ変更後は、変更前の状態でクローンを作れないケースがあります。リリース手順では、DDL変更の前に必要なクローンやスナップショットを確保しておくと安全です。(Microsoft Learn)
接続設定で確認すべきポイント
Fabric Data Warehouseへの接続では、TDSエンドポイントを使います。SQL接続文字列では、Microsoft Entra IDのユーザープリンシパルまたはサービスプリンシパルによる認証がサポートされ、SQL認証はサポートされません。(Microsoft Learn)
また、接続時にはTCP 1433が必要です。ファイアウォールではFQDNだけでなく、Power BI service tagsやSQL service tagsを許可する必要があります。(Microsoft Learn)
Initial Catalogを必ず指定する
SSMS、Visual Studio Code、JDBC、ODBC、SqlClient、独自アプリケーションなどから接続する場合、接続文字列に正しいWarehouse名をInitial CatalogまたはDatabaseとして指定する必要があります。認証自体が成功していても、Warehouse名が誤っていると接続に失敗します。(Microsoft Learn)
接続エラーが出た場合は、次の順で確認すると切り分けが早くなります。
| 確認順 | チェック内容 |
|---|---|
| 1 | 認証方式がMicrosoft Entra IDか。SQL認証を使っていないか |
| 2 | TCP 1433が許可されているか |
| 3 | Power BI service tagsとSQL service tagsが許可されているか |
| 4 | Server名とInitial Catalogを混同していないか |
| 5 | MultipleActiveResultSetsを指定していないか、またはfalseになっているか |
| 6 | 一時的なシステム更新による切断であれば、再接続とリトライを実装しているか |
MARSはFabric Warehouseでサポートされていないため、接続文字列にMultipleActiveResultSetsが含まれている場合は削除するかfalseにします。(Microsoft Learn)
移行時の注意点：SQL ServerやSynapseと同じ前提で進めない
Fabric Migration Assistantは、Azure Synapse Analyticsのdedicated SQL pool、SQL Server、その他SQLデータベースプラットフォームからFabric Data Warehouseへの移行を支援します。DACPACファイルのアップロード、またはソースへの直接接続を使ってスキーマを移行し、問題のあるT-SQLや定義を修正したうえでデータをコピーします。(Microsoft Learn)
ただし、ソース側のWarehouseとFabric Warehouseの間には完全なT-SQL互換性がありません。SQL認証、列レベル暗号化、スカラー関数、IDENTITY列、外部テーブル、マルチステートメントTVFなどは、移行前に個別の対応方針を決める必要があります。(Microsoft Learn)
移行前チェックリスト
| 項目 | 確認内容 | 対応例 |
|---|---|---|
| 認証 | SQL認証ユーザーが残っていないか | Microsoft Entra IDユーザーに置き換える |
| 権限 | ロール、GRANT、DENY、動的データマスクが移行後も意図どおりか | 移行後に権限レビューを実施する |
| 暗号化 | 列レベル暗号化を使っていないか | アプリ層暗号化やDynamic Data Maskingなど代替手段を検討する |
| UDF | スカラーUDFが移行対象か | inline可能か確認し、必要なら書き換える |
| IDENTITY | 既存DBと同じ採番挙動を期待していないか | 採番ロジックやキー設計を見直す |
| 外部テーブル | 外部テーブル依存がないか | Lakehouse、Pipeline、別の取り込み設計へ置き換える |
| データ型 | 未対応型や変換が必要な型がないか | 代替型へ変換し、精度と文字化けを検証する |
移行では、スキーマ移行、データコピー、並行比較、接続先切り替えの順に進めるのが基本です。特に権限とセキュリティオブジェクトは、データコピー前に修正しないと、意図しないユーザーに機密情報が見えるリスクがあります。(Microsoft Learn)
デプロイとソース管理で失敗しやすいポイント
Fabric WarehouseのSource controlはプレビュー機能で、Git統合とデプロイパイプラインを使って開発、テスト、本番環境へ変更を展開できます。Git統合ではWarehouseがSQL database project形式としてリポジトリに保存されますが、テーブルデータやSQLセキュリティ機能は含まれません。(Microsoft Learn)
このため、本番展開ではDDLだけでなく、権限設定やセキュリティ設定を別スクリプトとして管理する必要があります。公式情報でも、SQL security featuresはスクリプトベースでエクスポートまたは移行する必要があるとされています。(Microsoft Learn)
ALTER TABLEによる列・制約追加は慎重に扱う
Git統合やデプロイパイプラインでALTER TABLEを使って制約や列を追加すると、デプロイ処理がテーブルを削除して再作成し、データ損失につながる場合があります。(Microsoft Learn)
安全に展開するには、次のような手順を検討します。
| 手順 | 内容 |
|---|---|
| 1 | 新しい定義のテーブルを別名で作成する |
| 2 | INSERT、CTAS、Clone tableなどでデータを移す |
| 3 | 新テーブル側に必要な制約や列を追加する |
| 4 | 旧テーブルを退避または削除する |
| 5 | 新テーブルを旧テーブル名にリネームする |
| 6 | Git上のSQL database projectも実環境と同じ定義にそろえる |
また、Dataflow Gen2の出力先をWarehouseにした場合、DataflowsStagingWarehouseという項目がリポジトリやデプロイパイプラインに現れ、コミットや展開をブロックする可能性があります。CI/CD対象のワークスペースでは、Dataflow Gen2の出力先とソース管理の組み合わせを事前に検証してください。(Microsoft Learn)
トランザクションと並行更新の注意点
Fabric Data WarehouseはACID準拠のトランザクションをサポートし、BEGIN TRAN、COMMIT TRAN、ROLLBACK TRANといった標準的なT-SQL構文を利用できます。複数テーブルへの変更を1つのトランザクションとして扱えるため、整合性が必要な更新処理に有効です。(Microsoft Learn)
ただし、Fabric Data Warehouseではテーブルレベルのロックやスナップショット分離の挙動を理解しておく必要があります。DDL操作は同時実行中の読み取りやDMLをブロックすることがあり、UPDATE、DELETE、MERGEが同じテーブルに対して同時に走ると、書き込み競合が発生する可能性があります。(Microsoft Learn)
ETL・ELTで避けたい実装
- 同じテーブルに対して複数の
MERGEを同時実行する - 長時間のトランザクション内でDDLを実行する
- 本番レポート利用中に大規模なスキーマ変更を行う
- 競合時のリトライを実装していない
- ロールバック後に統計情報を更新しない
公式情報では、同じテーブルへの同時UPDATE、DELETE、MERGEを避けること、アプリケーションやETLパイプラインにリトライロジックを組み込むこと、指数バックオフを使うことが推奨されています。(Microsoft Learn)
テーブル設計で注意すべき制限
Fabric Data Warehouseでは、多くのテーブル機能を利用できますが、すべてのSQL Server機能が使えるわけではありません。たとえば、グローバル一時テーブル、計算列、インデックス付きビュー、パーティションテーブル、シーケンス、トリガー、ユニークインデックス、外部テーブルなどは現在サポートされていません。(Microsoft Learn)
一方、PRIMARY KEYやUNIQUE制約は、NONCLUSTEREDかつNOT ENFORCEDを指定した場合にサポートされます。FOREIGN KEYもNOT ENFORCEDが前提です。制約を「データ品質を保証する仕組み」として期待するのではなく、メタデータやクエリ設計上の補助として扱う意識が必要です。(Microsoft Learn)
テーブル設計の実務ポイント
| 設計テーマ | 推奨される対応 |
|---|---|
| 主キー・外部キー | NOT ENFORCEDであることを前提に、ETL側で重複・参照整合性を検証する |
| 計算列 | ETLやビュー、Semantic model側で計算する |
| パーティション | 物理パーティション前提の設計ではなく、ロード単位やテーブル分割で代替を検討する |
| トリガー | データ変更検知や監査はPipeline、ログ、アプリ側処理で設計する |
| 外部テーブル | Lakehouse、Shortcut、Pipelineなど別のデータ統合手段を検討する |
| 統計情報 | 大量ロード後は統計更新を検討する |
Pause and Resumeを使う場合の運用上の注意
Fabric容量を一時停止すると、実行中のSQL文やSQL Query Editor、Visual Query Editor、モデリングビューの操作はキャンセルされます。ユーザートランザクションがBEGIN TRANとCOMMIT TRANの途中で容量停止された場合、トランザクションはロールバックされます。(Microsoft Learn)
また、一時停止中はコンピュート課金は止まりますが、OneLakeストレージの課金は止まりません。再開後はキャッシュがクリアされた状態から始まるため、数回の実行までは性能低下を感じる場合があります。(Microsoft Learn)
コスト削減を目的に本番容量を頻繁に停止する場合は、次の影響を事前に説明しておくべきです。
| 影響 | 実務上の注意 |
|---|---|
| 実行中クエリのキャンセル | バッチ処理や長時間クエリの時間帯を避ける |
| トランザクションのロールバック | 更新処理中の停止を避ける |
| 背景クリーンアップの遅延 | 保持期間を超えた履歴データの削除が再開後に追いつく |
| キャッシュの消失 | 再開直後の性能をSLAに含める |
| ストレージ課金 | 停止してもOneLakeストレージ費用は継続する |
Power BI Semantic modelへの影響も確認する
WarehouseやSQL analytics endpoint上のデータは、Power BI Semantic modelと組み合わせて使われることが多いです。Direct Lakeは、Importのように明示的な取り込みを行わず、データレイク上のファイルを直接利用する方式です。一方、SKU制限や未対応機能に達した場合、Direct LakeはDirectQueryへフォールバックすることがあります。(Microsoft Learn)
また、Parquet、Apache Spark、SQLのデータ型がPower BI Desktopのデータ型にマッピングできない場合、同期プロセスで列が落ちる可能性があります。必要な列はETLで明示的に型変換するか、SQLビューで変換してからSemantic modelに取り込む設計が現実的です。(Microsoft Learn)
管理者・開発者が今日確認すべきチェックリスト
最後に、Fabric Data Warehouseの制限事項を受けて、すぐに確認すべき項目を整理します。
| 優先度 | 確認項目 | 対象者 |
|---|---|---|
| 高 | Warehouse、SQL analytics endpoint、Lakehouse、容量、ワークスペースのリージョンが一致しているか | 管理者 |
| 高 | Lakehouseの分析対象テーブルが/tables配下のDelta Parquetとして管理されているか | データエンジニア |
| 高 | SQL認証に依存していないか。Microsoft Entra ID認証へ移行できているか | 管理者、開発者 |
| 高 | 長い文字列列、varchar(max)、nvarchar、json、xmlなどの扱いを検証したか | 開発者、移行担当 |
| 高 | 保持期間が復旧要件、監査要件、ストレージコストと合っているか | 管理者 |
| 中 | Clone tableやWarehouse snapshotが保持期間内の時点を参照できるか | データエンジニア |
| 中 | Git統合やデプロイパイプラインでテーブル再作成が発生しないか | 開発者、DevOps担当 |
| 中 | Dataflow Gen2出力先とSource controlの組み合わせを検証したか | データエンジニア |
| 中 | 同じテーブルへの同時MERGEやUPDATEにリトライ設計があるか | 開発者 |
| 中 | Power BI Semantic modelで型変換漏れやDirectQueryフォールバックが発生していないか | BI開発者 |
まとめ：制限事項は「できないこと」ではなく設計条件として扱う
Microsoft Fabricの「Limitations of Fabric Data Warehouse – Microsoft Fabric」は、単なる制限一覧ではなく、Fabric Data Warehouseを安全に設計・移行・展開するための前提条件です。
まず確認すべきなのは、同一リージョン設計、SQL analytics endpointの自動検出条件、データ型とvarchar(max)の扱い、保持期間、移行時のT-SQL互換性、Source controlとデプロイパイプラインの制限です。これらを事前に確認すれば、接続失敗、列が表示されない、移行後に権限が崩れる、本番デプロイでデータが消える、といったトラブルを避けやすくなります。
次に取るべき行動は、既存のFabricワークスペースと移行予定環境を棚卸しし、リージョン、データ配置、接続文字列、保持期間、データ型、CI/CD手順をチェックリスト化することです。特に本番環境では、保持期間の短縮やDDL展開を実施する前に、Clone table、Snapshot、バックアップ相当の復旧手段を確認してから進めてください。
コメント