Azureの公式ドキュメント更新「Add files via upload」を見て、Azure環境の仕様変更や移行影響があるのか気になっている方も多いでしょう。結論から言うと、この更新は少なくともコミット単体では、APIやサービス仕様の変更ではなく、Azure Data FactoryからMicrosoft Fabricへの移行手順に関連する画像ファイル追加として確認できます。重要なのは「画像が追加されたか」ではなく、その画像が関係する移行導線、マウント手順、接続マッピング、非対応機能を自社環境で確認することです。公式ドキュメントの更新を運用判断に使う場合は、コミット内容とMicrosoft Learn本文の両方を見て、影響範囲を切り分けましょう。
Azureの公式ドキュメント更新「Add files via upload」で何が変わったか
今回確認すべき更新は、MicrosoftDocs/azure-docsリポジトリのコミット b9297d9 です。GitHub上ではコミットメッセージが「Add files via upload」とされ、変更対象は articles/data-factory/media/how-to-assess-and-upgrade-your-azure-data-factory-pipelines-to-fabric/ 配下の mount-from-fabric-migrate-end-point.png という画像ファイル1件です。コミット差分でも、テキストの追加・削除ではなく、PNGファイルが新規追加されたことが示されています。(GitHub)
このため、今回の「Add files via upload」を見ただけで「Azureの機能仕様が変わった」「既存パイプラインに即時影響がある」と判断するのは早計です。実務上は、該当画像が使われるAzure Data FactoryからFabric Data Factoryへの移行ドキュメントを確認し、画面導線や移行手順の説明が現在の運用手順とズレていないかを点検するのが正しい読み方です。
Microsoft Learnの関連ページ「Upgrade your Azure Data Factory pipelines to Fabric」は、2026年4月30日に最終更新されており、Azure Data FactoryパイプラインをFabricへ移行するための評価、マウント、接続マッピング、移行後検証について説明しています。(Microsoft Learn)
まず確認すべき結論：仕様変更ではなく移行手順の確認が中心
今回の更新で最初に見るべきポイントは、次の3つです。
| 確認ポイント | 見るべき内容 | 実務上の意味 |
|---|---|---|
| コミットの種類 | 画像ファイル追加か、本文・コード・設定変更か | 画像追加のみなら、即時の機能変更とは限らない |
| 対象サービス | Azure全体ではなく、Azure Data FactoryとMicrosoft Fabricの移行文脈か | 影響確認の対象をADF利用チームに絞れる |
| 関連ドキュメント本文 | 移行手順、マウント、接続、非対応項目 | 実際の運用手順や移行計画に反映する |
特に注意したいのは、「Add files via upload」というコミット名が汎用的で、変更内容を細かく説明していない点です。MicrosoftDocs系のリポジトリでは、画面キャプチャや補足画像の追加でもこのようなメッセージになることがあります。したがって、コミット名だけで影響度を判断せず、ファイルパスと関連ページを確認する必要があります。
今回のファイルパスには data-factory と how-to-assess-and-upgrade-your-azure-data-factory-pipelines-to-fabric が含まれています。つまり、主な確認対象はAzure Data FactoryのパイプラインをFabricへ評価・移行するシナリオです。Azure Virtual Machines、Azure App Service、Azure Storageなど、Azure全般にまたがる更新として扱う必要はありません。
Azure Data FactoryからFabricへの移行で確認すべき変更点
関連するMicrosoft Learn本文では、Azure Data Factoryパイプラインの移行開始方法として、Azure Data Factoryから始める方法とFabricワークスペースから始める方法の2つが説明されています。Azure Data Factoryから始める場合は移行前の準備状況評価に向き、Fabricワークスペースから始める場合は、移行対象のファクトリが分かっているときに直接マウントして進める導線です。(Microsoft Learn)
Fabricから開始するとADF側の評価をスキップする点に注意
Fabricワークスペースから移行を始める場合、Fabric側の「Migrate」導線からData Factoryを選び、対象のAzure Data Factoryインスタンスをマウントして移行へ進みます。ただし、Microsoft Learnでは、Fabricから開始するとAzure Data Factory内での評価ステップをスキップすると説明されています。移行前にパイプラインの準備状況を確認したい場合は、Azure Data Factory側から評価を開始する必要があります。(Microsoft Learn)
これは実務では大きな違いです。たとえば、開発環境で数本のパイプラインを試すだけならFabricから開始してもよい場合があります。一方、本番のデータ連携、日次バッチ、基幹システム連携が含まれる場合は、先にADF側で評価を実行し、非対応項目や要レビュー項目を洗い出すべきです。
「マウント」と「移行」は同じではない
移行関連のドキュメントで混同しやすいのが、Azure Data Factoryの「マウント」と「移行」です。
Microsoft Learnでは、マウントは既存のAzure Data Factory環境を移行、コピー、変更せずにFabricワークスペースから参照できる状態にするものと説明されています。また、FAQでは、マウントだけではパイプラインは移行されず、Fabric上のマウント済みデータファクトリから明示的に「Migrate to Fabric」を実行するまで移行は始まらないとされています。(Microsoft Learn)
つまり、運用判断では次のように分けて考える必要があります。
| 操作 | 何が起きるか | 運用上の判断 |
|---|---|---|
| マウント | ADFをFabricワークスペースから参照できるようにする | まずは可視化・確認用途として使いやすい |
| 移行 | 対象パイプラインをFabric Data Factory側へ作成する | 接続、トリガー、非対応機能の検証が必要 |
| 本番切り替え | 移行後のパイプラインを業務運用に使う | 非本番検証、監視、リカバリ手順が必須 |
「Fabric上にADFが見えたので移行済み」と誤解すると、検証や切り替え計画に抜けが出ます。特にクラウド管理者やソリューションアーキテクトは、マウント完了と移行完了をチケットや変更管理上で別ステータスとして扱うと安全です。
パイプライン評価で見るべきステータス
Azure Data Factory側から移行評価を実行すると、ファクトリや個別パイプラインが準備状況に応じて分類されます。Microsoft Learnでは、Ready、Needs review、Coming soon、Not compatibleというステータスが示されています。(Microsoft Learn)
| ステータス | 意味 | 取るべき対応 |
|---|---|---|
| Ready | 移行に対応している | 非本番環境で移行テストを行う |
| Needs review | 軽微な設定変更など確認が必要 | パラメーター、接続、認証、依存関係を確認する |
| Coming soon | 今後対応予定 | すぐに移行せず、ロードマップや更新を継続確認する |
| Not compatible | Fabric側に相当機能がない | 再設計、別サービス利用、現行維持を検討する |
実務で役立つのは、評価結果を単に「移行可否」として見るのではなく、パイプライン単位で対応方針を分けることです。たとえば、単純なBlob StorageからSQL Databaseへのコピー処理は早期移行候補にできます。一方、Self-hosted Integration Runtime、複雑なWebアクティビティ、イベントトリガー、動的なリンクサービスを多用しているパイプラインは、移行前に設計レビューが必要です。
接続マッピングは移行失敗を防ぐ重要ポイント
Azure Data FactoryからFabricへの移行では、リンクサービスをFabricの接続へマッピングする工程があります。Microsoft Learnでは、Azure Blob Storage、Azure Data Lake Storage Gen2、SQL Server、Azure SQL Database、Azure Data Explorer、Cosmos DB、PostgreSQL、MySQLなど、一部の接続について自動作成される認証方式が整理されています。(Microsoft Learn)
ここで重要なのは、「すべての接続が自動で安全に引き継がれるわけではない」という点です。ドキュメントでは、その他の接続については既存のFabric接続を選択するか、新しい接続を作成する必要があると説明されています。また、接続をマッピングしなくてもパイプライン自体は移行できますが、接続に依存するアクティビティは非アクティブ化され、後からFabric接続を構成して再有効化する必要があります。(Microsoft Learn)
移行前には、次のような接続棚卸しを行うと抜け漏れを減らせます。
| 棚卸し項目 | 確認例 |
|---|---|
| 接続先 | Blob Storage、ADLS Gen2、SQL Database、外部SaaSなど |
| 認証方式 | アカウントキー、SAS、サービスプリンシパル、マネージドIDなど |
| ネットワーク要件 | プライベート接続、オンプレミス接続、ファイアウォール制限 |
| 再作成要否 | Fabric接続として再作成が必要か |
| 検証方法 | 接続テスト、サンプル実行、権限エラー確認 |
特に本番運用では、接続エラーが移行後の最初の障害になりやすいです。移行作業の直前ではなく、評価段階で接続一覧を作り、認証方式ごとに対応方針を決めておきましょう。
非対応・再設計が必要な機能を先に洗い出す
関連ドキュメントでは、UXベースの移行体験でサポートされない項目も示されています。例として、Self-hosted Integration Runtime、Managed VNet系の統合ランタイム、SSIS IR、CDC、Apache Airflow、U-SQL、長尾系コネクタ、カスタムイベントトリガー、動的リンクサービス、複雑なWeb/HTTPアクティビティなどが挙げられています。(Microsoft Learn)
この一覧は、移行計画を作るうえで非常に重要です。なぜなら、非対応項目が含まれているパイプラインは、単純なクリック移行ではなく、Fabric側の設計へ置き換える検討が必要になるからです。
たとえば、次のような判断が考えられます。
| 現行ADFの構成 | 移行時の判断例 |
|---|---|
| 単純なスケジュール実行のコピー処理 | 早期移行候補にする |
| Self-hosted IRでオンプレミスDBへ接続 | Fabric側のゲートウェイや接続方式を再設計する |
| 動的リンクサービスを多用 | 接続パターンを分解し、Fabric接続として再構成する |
| カスタムイベントトリガーで起動 | Fabric側で代替の起動方式を検討する |
| グローバルパラメーター依存 | Fabricの変数ライブラリなどへの置き換えを検討する |
非対応項目があるからといって、全体移行を諦める必要はありません。Microsoft Learnでも、非対応アクティビティはそれを含むパイプラインに影響し、他の対応済みパイプラインは独立して移行できると説明されています。(Microsoft Learn)
運用チームが作るべき確認チェックリスト
今回のようなAzure公式ドキュメント更新を実務に落とし込む場合、更新内容を見て終わりにせず、確認項目として管理することが大切です。
| 確認項目 | 実施内容 | 完了基準 |
|---|---|---|
| 公式更新の記録 | コミットID、更新日、対象ページを記録 | 変更管理チケットに出典を残す |
| 影響範囲の切り分け | ADF、Fabric、関連ワークスペースを特定 | 対象外サービスを明確にする |
| ADFパイプライン棚卸し | 本番・検証・開発のパイプライン一覧を作る | 重要度と依存先が分かる |
| 移行評価 | ADF側から評価を実行 | Ready、Needs reviewなどで分類済み |
| 接続確認 | リンクサービスとFabric接続の対応を確認 | 未マッピング接続が一覧化されている |
| トリガー確認 | スケジュール、イベント、依存関係を確認 | 移行後の再有効化手順がある |
| 非対応機能確認 | SHIR、動的リンクサービス、複雑なWeb処理などを確認 | 再設計対象が明確 |
| 非本番検証 | テスト用Fabricワークスペースで実行 | エンドツーエンドで結果確認済み |
| 本番切り替え計画 | 戻し手順、監視、担当者を定義 | 変更承認を取得済み |
このチェックリストは、開発者だけでなくクラウド管理者、アーキテクト、技術意思決定者が同じ前提で会話するためにも有効です。特にグローバルチームでは、英語版Microsoft Learnの更新日とGitHubコミットをひも付けておくと、地域ごとの翻訳差分や反映タイミングのズレを吸収しやすくなります。
役割別に見るべきポイント
開発者はパイプライン単位で移行可否を見る
開発者は、個々のパイプラインとアクティビティに注目しましょう。評価結果がReadyでも、パラメーター、式、システム変数、接続先の権限が同じように動くとは限りません。
特に、pipeline().TriggerName のようなシステム変数に依存している場合は注意が必要です。Microsoft Learnでは、Azure Data FactoryとFabric Data Factoryでは一部のシステム変数の挙動差があり、必要に応じてトリガーイベントメタデータやパイプラインパラメーターを使う例が示されています。(Microsoft Learn)
クラウド管理者は権限と接続を確認する
クラウド管理者は、Fabricワークスペース、Microsoft Entra IDテナント、接続、資格情報、監視範囲を確認しましょう。関連ドキュメントでは、既存のAzure Data Factoryインスタンス、Microsoft Fabricテナントへのアクセス、同じMicrosoft Entra IDテナント内のFabricワークスペース、Fabricから開始する場合のContributor以上の権限が前提条件として示されています。(Microsoft Learn)
権限不足は、移行作業の途中で発覚すると時間を浪費します。事前に「誰が評価を実行するか」「誰がFabric接続を作成するか」「誰が本番切り替えを承認するか」を決めておくことが重要です。
アーキテクトは段階移行と再設計を判断する
ソリューションアーキテクトは、すべてを一括移行するのではなく、段階移行の単位を設計する必要があります。Readyのパイプラインから移行し、Needs reviewやNot compatibleは再設計対象として分けると、リスクを抑えながらFabric移行を進めやすくなります。
また、マウントは既存ADFをFabricワークスペースから扱う入口として使えますが、本格的な移行とは別物です。マウント段階、検証段階、本番利用段階を分けてロードマップ化しましょう。
移行準備のおすすめ手順
Azure Data FactoryからFabricへの移行を検討している場合は、次の順序で進めると安全です。
| 手順 | 実施内容 |
|---|---|
| 1 | 公式コミットとMicrosoft Learnの更新日を記録する |
| 2 | 対象ADFインスタンスとパイプラインを棚卸しする |
| 3 | 本番ではなく検証環境でADF側から移行評価を実行する |
| 4 | 評価結果をReady、Needs review、Coming soon、Not compatibleに分類する |
| 5 | リンクサービスとFabric接続の対応表を作る |
| 6 | Fabricワークスペースへマウントし、画面導線と表示内容を確認する |
| 7 | Readyのパイプラインから非本番移行を試す |
| 8 | トリガー、接続、パラメーター、監視を検証する |
| 9 | 戻し手順を用意してから本番移行を計画する |
ポイントは、最初から本番パイプラインを移行しないことです。Microsoft Learnでも、移行後は接続と資格情報の検証、グローバルパラメーターの変数ライブラリへの再作成、トリガーの再有効化、エンドツーエンドテスト、非本番環境での検証が推奨されています。(Microsoft Learn)
よくある失敗と回避策
Fabricから始めて評価を飛ばしてしまう
Fabricワークスペースから始める導線は便利ですが、ADF側の評価をスキップします。重要な本番パイプラインでは、先にADF側から評価を実行し、移行できない機能を洗い出しましょう。
マウント完了を移行完了と誤解する
マウントは既存ADFをFabricから参照するための段階です。実際の移行は、移行ボタンを明示的に実行してから始まります。変更管理では「マウント済み」と「移行済み」を分けて記録しましょう。
接続未設定のまま移行してアクティビティが動かない
接続をマッピングしなくてもパイプラインは移行できますが、依存するアクティビティは非アクティブ化されます。移行前にリンクサービスを棚卸しし、Fabric接続として再作成が必要なものを特定しておくべきです。
トリガーの再有効化を忘れる
Microsoft Learnでは、スケジュールトリガーは移行されるものの、移行後は設計上無効化されると説明されています。その他のトリガーも検証後に手動で再構成・再有効化が必要です。(Microsoft Learn)
パイプライン名の重複を見落とす
Fabricワークスペース内ではパイプライン名が一意である必要があり、同名パイプラインがある場合、移行ツールはそのパイプラインをスキップします。移行済みパイプラインには、ソースファクトリ名またはワークスペース名を含む命名形式が使われると説明されています。(Microsoft Learn)
今回の更新をどう扱うべきか
今回のAzure公式ドキュメント更新「Add files via upload」は、コミット単体では画像追加の更新です。したがって、障害対応や緊急パッチのように扱う必要はありません。
ただし、画像が追加された場所はAzure Data FactoryパイプラインをFabricへ評価・移行する手順に関係しています。ADFを利用している組織、とくにFabricへの段階移行やデータ基盤の統合を検討しているチームにとっては、画面導線と移行手順を再確認するよいタイミングです。
次に取るべき行動は明確です。まず、対象のAzure Data Factoryがあるかを確認します。次に、移行予定の有無にかかわらず、重要なパイプライン、接続、トリガー、統合ランタイムを棚卸しします。そのうえで、Fabric移行を検討している場合はADF側から評価を実行し、Readyのパイプラインから非本番環境で検証しましょう。
公式ドキュメント更新は、単なるニュースではなく、運用手順を見直すきっかけです。今回の更新も、Azure Data FactoryとMicrosoft Fabricの移行準備を具体化する材料として活用するのが最も実践的です。
コメント