Azureの公式ドキュメント更新で「Delete articles/data-factory/media/how-to-assess-and-upgrade-your-azure-data-factory-pipelines-to-fabric/mount-from-fabric-migrate-end-point.png」を見かけた場合、まず押さえるべき結論は、この更新はAzure Data FactoryからMicrosoft Fabricへの移行機能そのものを変更する発表ではなく、公式ドキュメント内の画像アセット削除に関する変更だという点です。
ただし、対象パスが「Azure Data Factory pipelines to Fabric」の移行手順に関係しているため、開発者、クラウド管理者、ソリューションアーキテクトは無視せず、社内手順書・移行計画・運用レビューに影響がないかを確認すべきです。特に、ADFからFabricへの移行を検討中の組織では、画像削除そのものよりも、公式ドキュメントが示している「評価してから移行する」流れを再確認することが重要です。
Azureの公式ドキュメント更新で何が変わったか
今回のMicrosoftDocs系の更新は、GitHub上のAzure公式ドキュメントリポジトリで確認できるコミットです。コミット内容は、articles/data-factory/media/how-to-assess-and-upgrade-your-azure-data-factory-pipelines-to-fabric/mount-from-fabric-migrate-end-point.png というPNG画像ファイルの削除であり、差分上は1ファイルの変更として扱われています。GitHubの差分でも、このPNGが「deleted file」として削除されたことが確認できます。(GitHub)
重要なのは、このコミット単体からは、Azure Data FactoryやFabric Data Factoryの仕様変更、API変更、料金変更、実行基盤の変更は読み取れないことです。削除対象はドキュメント本文ではなくメディアファイルです。そのため、Azure環境で稼働しているパイプラインがこの更新によって突然変わるわけではありません。
一方で、対象画像は「Fabric側からAzure Data Factoryをマウントして移行を進める」文脈で使われていた画像です。現在のドキュメント本文では、FabricワークスペースからData Factoryを選び、Azure Data Factoryインスタンスをマウントする流れが説明されています。(GitHub)
| 確認対象 | 今回の更新から読み取れること | 実務での対応 |
|---|---|---|
| Azureリソース | パイプラインや接続設定の実行仕様変更ではない | 本番環境への緊急対応は不要 |
| 公式ドキュメント | 移行手順に関連する画像アセットが削除された | 該当ページの表示や社内資料の画像参照を確認 |
| 移行プロジェクト | ADFからFabricへの移行ドキュメントが継続的に更新されている | 移行前に最新版の公式手順を再確認 |
| 社内Runbook | 画像を引用・直リンクしている場合に影響する可能性 | スクリーンショットやリンク切れを点検 |
画像削除だけでも確認すべき理由
「画像が消えただけなら影響はない」と判断したくなりますが、AzureやMicrosoft Fabricの移行案件では、ドキュメント更新の小さな差分が運用判断に関係することがあります。
理由は3つあります。
1つ目は、移行手順の画面遷移が変わっている可能性です。画像ファイルの削除は、古いスクリーンショットの整理、UI変更への追従、別画像への差し替え準備などで発生します。今回の差分だけでUI変更を断定することはできませんが、管理者向けの手順書を作っている場合は、実画面と公式ドキュメントを照合する価値があります。
2つ目は、社内ドキュメントのリンク切れです。GitHub上の画像パスやMicrosoft Learnの画像を社内Wikiに直接貼っている場合、画像削除によって説明が欠落する可能性があります。特に移行手順書では、画面名よりもスクリーンショットに依存しているケースが多いため注意が必要です。
3つ目は、ADFからFabricへの移行がプレビュー要素を含む領域であることです。公式ドキュメントでは、移行機能に「Preview」と表記されている箇所があり、評価・マウント・移行・接続マッピング・検証という流れで段階的に進める構成になっています。(GitHub)
Azure Data FactoryからFabricへの移行で押さえるべき全体像
今回の更新を理解するには、背景にある「Azure Data Factory pipelines to Fabric」の移行フローを把握しておく必要があります。公式ドキュメントでは、Azure Data Factoryから開始する方法と、Fabricワークスペースから開始する方法の2つが示されています。(GitHub)
Azure Data Factoryから開始する場合
ADF側から開始する場合は、まずパイプラインの移行評価を実行します。評価結果では、ファクトリ全体と個別パイプラインが、Ready、Needs review、Coming soon、Not compatibleのいずれかに分類されます。評価結果はCSVとしてエクスポートできるため、オフラインレビューや改修計画にも使えます。(GitHub)
| 評価ステータス | 意味 | 実務上の判断 |
|---|---|---|
| Ready | Fabricへの移行に対応している | 非本番環境で移行・検証を開始しやすい |
| Needs review | パラメーターや設定変更などの確認が必要 | 修正内容を洗い出してから再評価 |
| Coming soon | 今後対応予定 | 業務影響が大きい場合は移行時期を遅らせる |
| Not compatible | Fabric側に同等機能がない | ADF継続、手動再設計、代替構成を検討 |
実務では、Readyの件数だけを見て判断しないことが大切です。たとえば、1本のNot compatibleなパイプラインが月次決算や顧客データ連携の中核であれば、移行全体のリスクは高くなります。評価結果は「移行できる数」ではなく、「止められない処理がどこにあるか」を見るために使うべきです。
Fabricワークスペースから開始する場合
Fabric側から開始する場合は、FabricワークスペースのツールバーにあるMigrateからData Factoryを選び、対象のAzure Data Factoryインスタンスをマウントして移行フローに進みます。公式ドキュメントでは、Fabricから開始するとADF内での評価ステップをスキップするため、移行前にパイプラインの準備状況を確認したい場合はADF側の評価から始めるよう案内されています。(Microsoft Learn)
この違いは重要です。すでに移行対象が明確で、検証環境で試すだけならFabric側から開始してもよいでしょう。一方、本番パイプラインの棚卸しや影響調査を兼ねるなら、ADF側から評価を実行するほうが安全です。
「マウント」と「移行」を混同しない
ADFからFabricへの移行で最も誤解されやすいのが、マウントと移行の違いです。
公式ドキュメントでは、マウントはAzure Data FactoryインスタンスをFabricワークスペース内で参照できるようにする操作であり、ADF環境を移行・コピー・変更するものではないと説明されています。(Microsoft Learn)
また、Azure Data Factory Itemの説明では、既存のADFをFabricワークスペース内に持ち込み、ADFパイプラインをFabric側から表示・管理できる一方で、パイプライン、データフロー、トリガー、統合ランタイム、スケジュールはADF側で実行され続けるとされています。既存パイプラインの実行基盤や課金もADF側に残ります。(Microsoft Learn)
| 操作 | 何が起きるか | 注意点 |
|---|---|---|
| マウント | ADFをFabricワークスペースから参照できる | パイプライン自体はまだ移行されない |
| 評価 | パイプラインやアクティビティの移行可否を確認する | 読み取り中心の確認として扱える |
| 移行 | 対応するパイプラインをFabric Data Factory側へ作成する | 接続、トリガー、パラメーターの検証が必要 |
| 検証 | Fabric側で実行結果や接続を確認する | 本番切り替え前に非本番で実施する |
「マウントしたから移行済み」と判断すると、運用引き継ぎや切り戻し計画で混乱します。マウントは移行準備の入口であり、本番移行の完了ではありません。
運用影響として確認すべきポイント
今回のドキュメント更新自体は画像削除ですが、対象ページがADFからFabricへの移行手順に関わるため、運用チームは次の観点を確認しておくと安全です。
接続マッピング
移行フローでは、ADFのLinked ServicesをFabricのConnectionsにマッピングします。公式ドキュメントでは、対応する認証方式については自動的に接続を作成しようとする一方、マッピングしない場合でもパイプライン自体は移行されるが、依存するアクティビティは非アクティブ化されると説明されています。(Microsoft Learn)
つまり、移行後に「パイプラインは存在するのに動かない」という状態が起こり得ます。移行前に、Linked Servicesの一覧、認証方式、接続先、シークレット管理方法を棚卸ししておきましょう。
トリガーとスケジュール
移行後のトリガーも要注意です。公式FAQでは、スケジュールトリガーは自動移行されるものの、設計上は無効化された状態になるため、Fabric側で手動で再有効化する必要があると説明されています。他のトリガーは、検証後に手動で再構成・再有効化が必要です。(GitHub)
本番運用では、移行直後にスケジュール実行が再開されると思い込むと、データ連携の遅延や未実行が発生します。移行チェックリストには、必ず「トリガーの再有効化」と「初回実行確認」を入れてください。
グローバルパラメーターと動的接続
ADFでグローバルパラメーターや動的なLinked Servicesを多用している環境では、移行の難度が上がります。Microsoftの移行計画ドキュメントでは、ADFとFabric Data Factoryの違いとして、グローバルパラメーターはFabric Variable Libraryに置き換える考え方が示され、動的接続についても実装パターンの差が説明されています。(Microsoft Learn)
メタデータ駆動型のパイプラインや、環境別に接続先を切り替える構成を使っている場合は、単純な移行ではなく再設計を前提に見積もるべきです。
移行準備で使える実務チェックリスト
ADFからFabricへの移行を検討している場合、今回の公式ドキュメント更新をきっかけに、次の順番で確認すると無駄がありません。
| 手順 | 確認内容 | 成果物 |
|---|---|---|
| 公式差分の確認 | 画像削除なのか、本文・仕様変更なのかを切り分ける | 変更内容メモ |
| 社内資料の点検 | 削除対象画像や古いスクリーンショットを引用していないか | Runbook修正版 |
| ADF資産の棚卸し | パイプライン、Linked Services、IR、トリガーを一覧化 | 移行対象リスト |
| 移行評価の実行 | Ready、Needs review、Coming soon、Not compatibleを確認 | 評価CSV |
| 優先順位付け | 業務重要度、失敗時影響、改修難度で分類 | 移行ロードマップ |
| 非本番検証 | Fabric側で接続、実行結果、トリガーを確認 | 検証記録 |
| 本番計画 | 切り替え手順、切り戻し、監視、担当者を決める | 本番移行計画 |
特にグローバル展開している組織では、FabricワークスペースとADFが同じMicrosoft Entra IDテナントにあるか、権限が足りているか、推奨されるリージョン構成になっているかも確認が必要です。Azure Data Factory Itemの前提条件では、ADFへのContributor権限、FabricワークスペースでのMemberまたはAdmin権限、同一Entra IDテナント、同一リージョンの利用推奨が示されています。(Microsoft Learn)
よくある失敗と回避策
公式ドキュメント更新を機能変更と誤解する
今回のような「Delete media file」の更新は、製品仕様の変更ではなくドキュメント資産の整理である可能性が高いです。差分を見ずに「Fabric移行機能が削除された」と判断しないようにしましょう。まずGitHubのコミットで、変更対象が本文なのか画像なのかを確認することが基本です。
評価せずにFabric側から移行を始める
Fabric側から始めるルートは便利ですが、ADF内の評価ステップをスキップします。既存パイプラインの互換性が分からない状態で進めると、接続、トリガー、未対応アクティビティの問題が後から出ます。業務影響があるパイプラインでは、ADF側の評価を先に実行してください。
接続だけ後回しにする
接続マッピングを後回しにしてもパイプラインは移行できますが、依存アクティビティが非アクティブ化される可能性があります。移行後すぐに動作確認したい場合は、認証方式とFabric Connectionsの準備を先に済ませておきましょう。
トリガーの再有効化を忘れる
移行後にスケジュールトリガーが無効化されていることを知らないと、翌朝のデータ更新が止まる可能性があります。移行当日のチェック項目に「トリガー状態」「初回実行」「失敗時通知」を入れてください。
開発者・管理者・意思決定者ごとの見るべきポイント
| 立場 | 見るべきポイント | 具体的なアクション |
|---|---|---|
| 開発者 | パイプライン、アクティビティ、接続の互換性 | 評価結果をもとにNot compatibleな箇所を改修 |
| クラウド管理者 | 権限、テナント、リージョン、監視、トリガー | FabricワークスペースとADFの運用設計を確認 |
| ソリューションアーキテクト | ADFとFabricの設計差分 | 動的接続、IR、パラメーター、スケジュールを再設計 |
| 技術責任者 | 移行タイミングとリスク | Readyな範囲から段階移行し、本番一括移行を避ける |
今回のAzure公式ドキュメント更新は、単体で見ると画像アセット削除です。しかし、対象がAzure Data FactoryからFabricへの移行手順に関係しているため、移行プロジェクト中のチームにとっては、公式手順の見直し、社内資料の更新、移行評価の再確認を行うよいタイミングです。
まずは、対象コミットが本文変更ではなく画像削除であることを確認します。次に、ADFからFabricへの移行を進める場合は、ADF側で移行評価を実行し、ReadyだけでなくNeeds review、Coming soon、Not compatibleの内容を見て優先順位を決めます。最後に、接続マッピング、トリガー、グローバルパラメーター、統合ランタイムを非本番環境で検証してから、本番移行に進むのが現実的です。
コメント