2026年4月30日のAzure公式ドキュメント更新「Fix image syntax in migration guide」は、結論から言うと、Azureサービスの仕様変更ではなく、移行ガイド内の画像表示に関する修正として確認すべき更新です。対象は「Azure Data Factory pipelines to Fabric Data Factory」への移行ガイドで、開発者・クラウド管理者・ソリューションアーキテクトは、画面手順の見え方だけでなく、移行準備・接続設定・トリガー・非対応機能の確認にもつなげると実務上の価値があります。
今回のコミットでは、MicrosoftDocs/azure-docs リポジトリの articles/data-factory/how-to-upgrade-your-azure-data-factory-pipelines-to-fabric-data-factory.md が対象になっており、差分は1ファイル、2追加・2削除です。変更箇所は Fabric ワークスペース側から移行を開始する手順内の画像構文で、API、コマンド、設定値、移行条件そのものが変更されたわけではありません。(GitHub)
Azureの公式ドキュメント更新「Fix image syntax in migration guide」で何が変わったか
今回の更新名である「Fix image syntax in migration guide」は、直訳すると「移行ガイド内の画像構文を修正する」という意味です。GitHub上の差分を見る限り、修正対象は Azure Data Factory から Fabric Data Factory へパイプラインを移行するガイド内の画像ディレクティブです。
特に影響するのは、Fabric ワークスペースから移行を開始する「Option B: Start from Fabric」の説明部分です。該当箇所では、Fabric ワークスペースのツールバーで Migrate を選び、Migrate to Fabric パネルから Data Factory を選択する手順と、Azure Data Factory インスタンスをマウントする手順のスクリーンショットが扱われています。(GitHub)
| 確認項目 | 内容 | 実務上の見方 |
|---|---|---|
| 更新日 | Microsoft Learn上の対象ページは2026年4月30日更新 | 移行検討中のチームは最新版として再確認する |
| 対象サービス | Azure Data Factory、Microsoft Fabric Data Factory | ADFからFabricへの移行準備に関係する |
| 変更内容 | 移行ガイド内の画像構文修正 | 画面手順・スクリーンショット表示の修正と見るのが妥当 |
| 変更規模 | 1ファイル、2追加・2削除 | 大規模な仕様変更ではない |
| 優先度 | 移行作業中なら中、未検討なら低〜中 | 本番移行前の手順書確認に使う |
この種の公式ドキュメント更新では、「画像だけの修正だから無視してよい」と判断しがちです。しかし、移行ガイドの画像は作業者が画面操作を確認するための重要な情報です。社内手順書やレビュー資料で同じ画面を引用している場合は、最新の公式ページと表示内容が一致しているか確認しておくと、移行作業時の認識ずれを減らせます。
仕様変更ではなく、移行手順の見え方を正す更新として扱う
今回のコミット差分には、Azure Data Factory の機能追加、Fabric Data Factory の新しい制約、認証方式の変更、コマンド変更などは確認できません。したがって、運用チームが緊急で設定を変更する必要がある更新ではありません。
ただし、対象ページそのものは重要です。Microsoft Learn の対象ガイドは、Azure Data Factory の既存パイプラインを Fabric に持ち込むための手順を説明しており、移行前評価、互換性ギャップの確認、対応済みパイプラインの移行、更新が必要な項目の計画までを扱っています。(Microsoft Learn)
実務では、今回の更新を次のように扱うとよいでしょう。
| 状況 | 対応 |
|---|---|
| すでにADFからFabricへの移行を進めている | 公式ページの該当スクリーンショットと社内手順書を照合する |
| これから移行を検討する | 画像修正だけでなく、移行ガイド全体を読み直す |
| 本番移行直前 | 手順の画面遷移、接続マッピング、トリガー再有効化を再確認する |
| Azure更新情報を監視しているだけ | サービス仕様変更ではなくドキュメント品質修正として記録する |
ポイントは、「今回の更新自体は小さいが、対象になっている移行ガイドは運用影響が大きい」という切り分けです。
対象はAzure Data FactoryからFabric Data Factoryへの移行ガイド
対象ページでは、Azure Data Factory から Fabric Data Factory へ移行を開始する方法として、主に2つの入口が示されています。1つは Azure Data Factory から開始して移行評価を行う方法、もう1つは Fabric ワークスペースから開始して、移行したいファクトリを直接マウントする方法です。(Microsoft Learn)
| 開始方法 | 向いているケース | 注意点 |
|---|---|---|
| Azure Data Factoryから開始 | 事前にパイプラインの移行可否を確認したい | 評価結果を見てから移行計画を立てられる |
| Fabricワークスペースから開始 | 移行対象のADFが明確で、Fabric側で作業を進めたい | ADF内の事前評価ステップをスキップする |
特に注意したいのは、Fabricワークスペースから開始する方法では、ADF側での評価ステップをスキップする点です。公式ガイドでも、パイプラインの準備状況を確認したい場合は、Azure Data Factory側の評価ステップから始めるよう案内されています。(Microsoft Learn)
つまり、画面上はFabricからすぐ移行できそうに見えても、実務では先に評価を行う方が安全です。複雑なパイプライン、動的なリンクサービス、オンプレミス接続、イベントトリガーを含む環境では、移行可否の判定を省略しない方がよいでしょう。
今回の更新後に確認すべき実務ポイント
社内手順書のスクリーンショットが古くなっていないか
今回の更新は画像構文の修正です。そのため、まず見るべきなのは社内Wiki、運用手順書、移行説明資料、変更申請書に掲載している画面キャプチャです。
特に次の画面を引用している場合は、公式ページと見比べてください。
| 確認する画面 | 見るべきポイント |
|---|---|
| Fabric ワークスペースの Migrate ボタン | ボタンの場所、表示名、作業者が迷わない説明になっているか |
| Migrate to Fabric パネル | Data Factory の選択箇所が分かるか |
| ADFインスタンスのマウント画面 | どのファクトリを選ぶのか、権限やテナント条件が明記されているか |
| 移行後のパイプライン確認画面 | 作成先、命名規則、検証手順が書かれているか |
社内資料では、画面キャプチャだけを貼るよりも、「どのボタンを押すか」「押した後に何を確認するか」まで書く方が安全です。UIは更新される可能性があるため、手順書では画像に依存しすぎない表現にしておきましょう。
Fabricから開始する場合でも事前評価を省略しない
Azure Data Factory の移行評価では、パイプラインやアクティビティが Ready、Needs review、Coming soon、Not compatible のような状態で分類されます。評価結果はCSVとしてエクスポートでき、パイプライン名、アクティビティ単位の状態、互換性に関するメモを確認できます。(Microsoft Learn)
| ステータス | 意味 | 実務での判断 |
|---|---|---|
| Ready | 移行可能と判断できる状態 | 優先的に検証環境へ移行する候補 |
| Needs review | 軽微な修正や確認が必要 | パラメーター、接続、式を確認してから移行 |
| Coming soon | サポート予定だが現時点では待つべき項目 | 本番移行対象から一旦外す |
| Not compatible | Fabricに同等機能がなく再設計が必要 | 手動再構築や代替方式を検討 |
評価結果を見ずに移行を始めると、あとから「一部アクティビティだけ動かない」「トリガーの再設定が必要だった」「グローバルパラメーターの置き換えを忘れていた」といった問題が起きやすくなります。
接続と認証方式を移行前に棚卸しする
ADFからFabricへの移行では、リンクサービスやデータセットの考え方がそのまま残るわけではありません。Fabricでは、接続とアクティビティ設定を中心に構成する考え方へ移ります。Microsoftのベストプラクティスでも、認証パターン、ネットワーク要件、スケジュールとトリガー、監視、SLA、コスト、可観測性を事前に評価することが推奨されています。(Microsoft Learn)
移行前に、最低限以下を一覧化してください。
| 棚卸し対象 | 具体例 | 確認ポイント |
|---|---|---|
| リンクサービス | Azure SQL Database、ADLS Gen2、Blob Storage | Fabric側の接続にどう置き換えるか |
| 認証方式 | アカウントキー、SAS、サービスプリンシパル、マネージドID | Workspace identityに置き換えられるか |
| ネットワーク | SHIR、Managed VNet IR、Private Endpoint | OPDGやVirtual Network Data Gatewayの設計が必要か |
| パイプライン式 | 動的パス、日付式、環境別URI | Fabric側で同じ式が動くか |
| トリガー | スケジュール、イベント、依存関係 | 移行後に再設定・再有効化が必要か |
コネクタについては、ADFとFabric Data Factoryで対応状況や認証方式、細かいプロパティに差があります。たとえば、Azure SQL DatabaseやADLS Gen2など主要な接続先でも、Fabric側でサポートされない追加プロパティがある場合があります。(Microsoft Learn)
移行後の検証項目を先に決めておく
移行作業で失敗しやすいのは、「移行できたか」だけを見て、「正しく動くか」を後回しにするケースです。公式ガイドでは、移行後に接続と資格情報の検証、グローバルパラメーターの変換、トリガーの再有効化、エンドツーエンドテスト、本番前の非本番環境での検証が示されています。(Microsoft Learn)
検証では、次の観点を使うと抜け漏れを減らせます。
| 検証項目 | 確認内容 | 合格基準の例 |
|---|---|---|
| 接続 | データソースとシンクに接続できるか | 認証エラーなしで読み書きできる |
| データ件数 | ADF実行時とFabric実行時で件数が合うか | 行数、主キー件数、NULL件数が一致する |
| スキーマ | 型、桁数、日付形式が変わっていないか | 主要テーブルの型差分がない |
| 実行時間 | SLA内に終わるか | 既存ADF実行時間と比較して許容範囲内 |
| リトライ | 障害時に期待どおり再試行されるか | 再試行回数、タイムアウトが設計どおり |
| 監視 | 失敗時に検知できるか | 監視画面、通知、運用フローで追跡できる |
特に日付、タイムゾーン、NULL処理、文字コード、ファイル名の動的生成は、画面上の移行完了だけでは見落とされやすいポイントです。テストデータには、月末、祝日、空データ、重複データ、異常値を含めておくと、移行後の差分を発見しやすくなります。
開発者・管理者・アーキテクト別の確認ポイント
今回のようなドキュメント更新は、担当者によって見るべき観点が異なります。全員が同じ粒度で読むよりも、役割ごとに確認内容を分ける方が効率的です。
| 役割 | 確認すべき点 | 具体的なアクション |
|---|---|---|
| 開発者 | パイプライン式、アクティビティ、データ変換 | 評価結果でNeeds reviewやNot compatibleの箇所を洗い出す |
| クラウド管理者 | 権限、テナント、接続、ゲートウェイ | Fabricワークスペース、Entra ID、認証方式を確認する |
| ソリューションアーキテクト | ADFとFabricの設計差分 | 移行方式をリフト＆シフトではなく再設計込みで判断する |
| 技術意思決定者 | 移行リスク、工数、段階移行 | 本番移行前に非本番検証とロールバック計画を要求する |
| 運用担当者 | トリガー、監視、障害対応 | 移行後の再有効化手順と監視ルールを更新する |
Microsoftの移行計画ガイドでは、ADFとFabricのアーキテクチャ差分として、データセット、動的接続、グローバルパラメーター、ID、Key Vault、スケジューリングなどが挙げられています。単純に「ADFのパイプラインをFabricへ移す」と考えるのではなく、どの機能を再利用し、どこを置き換えるかを先に決めることが重要です。(Microsoft Learn)
移行準備で特に注意したい非対応・再設計ポイント
Azure Data FactoryからFabric Data Factoryへの移行では、すべての機能がそのまま移行できるわけではありません。公式ガイドでは、UXベースの移行体験でサポート対象外となる項目も示されています。たとえば、Self-hosted Integration Runtime、Managed Virtual Network IR、SSIS IR、CDC、Apache Airflow資産、一部のSaaSコネクタ、カスタムイベントトリガー、動的リンクサービス、複雑なWeb/HTTP認証などは、再設計や代替方式の検討が必要です。(Microsoft Learn)
| 領域 | 失敗しやすい思い込み | 実際に確認すべきこと |
|---|---|---|
| 統合ランタイム | SHIRが自動でFabricに移る | OPDGやVirtual Network Data Gatewayへの置き換えを設計する |
| グローバルパラメーター | 自動でFabric側に変換される | Variable Libraryへ手動で移す計画を立てる |
| トリガー | 移行後すぐ本番実行できる | スケジュールトリガーの再有効化、イベント系の再構成を確認する |
| 接続 | リンクサービスが完全に同じ動きをする | Fabric接続で使える認証方式とプロパティを確認する |
| パイプライン名 | 同名でも上書きされる | 同名パイプラインがある場合のスキップや命名規則を確認する |
| 動的構成 | パラメーター化された接続がそのまま使える | Fabric側の接続設計を再作成する |
グローバルパラメーターについては、Fabricではワークスペース内のVariable Libraryを使って定数を管理します。ADFのグローバルパラメーターは、エクスポート、Fabric側での変数作成、式の更新、動作検証という流れで移行する必要があります。また、組み込みアップグレード体験やPowerShell移行ツールでは、グローバルパラメーターや @globalParameters() 参照の自動変換は行われないとされています。(Microsoft Learn)
「マウント」と「移行」を混同しない
今回の画像修正箇所は、Fabric側からADFを選んでマウントする手順に関係します。ここで重要なのは、マウントは移行そのものではないという点です。
公式FAQでは、マウントは既存のAzure Data FactoryをFabricワークスペース内で参照するためのスナップショットであり、明示的に Migrate to Fabric (Preview) を選ぶまでパイプラインは移行されないと説明されています。(Microsoft Learn)
運用手順書では、次のように分けて書くと誤解を防げます。
| 作業 | 意味 | 本番影響 |
|---|---|---|
| 評価 | パイプラインやアクティビティの互換性を確認する | 読み取り中心で影響は限定的 |
| マウント | ADFをFabricワークスペースから参照できるようにする | 移行ではない |
| 移行 | 対象パイプラインをFabricワークスペースへ作成する | 検証と接続設定が必要 |
| 再有効化 | トリガーやアクティビティを動作可能にする | 本番実行に直結するため慎重に行う |
「マウントできたので移行完了」と判断すると、接続、資格情報、トリガー、監視の確認が漏れます。作業ステータスは「評価済み」「マウント済み」「移行済み」「検証済み」「本番切替済み」のように分けて管理しましょう。
今回の更新を受けたおすすめの対応手順
実際のチームでは、今回の更新を次の順序で処理すると無駄がありません。
| 手順 | 作業内容 | 担当の例 |
|---|---|---|
| 1 | 公式ページの更新日と対象箇所を確認する | 技術リード、ドキュメント担当 |
| 2 | 社内手順書のFabric起点移行手順と画像を照合する | クラウド管理者 |
| 3 | 移行対象ADFの評価を実行し、CSVを取得する | 開発者、データ基盤担当 |
| 4 | Ready、Needs review、Coming soon、Not compatibleに分類する | アーキテクト |
| 5 | 接続、認証、ゲートウェイ、トリガー、グローバルパラメーターを棚卸しする | 運用・セキュリティ担当 |
| 6 | 非本番環境で移行と検証を行う | 開発者、QA担当 |
| 7 | 本番切替手順とロールバック条件を明文化する | 技術意思決定者、運用責任者 |
特に本番移行前は、評価CSVを残すことをおすすめします。評価結果を証跡として保存しておけば、変更審査や障害発生時の切り戻し判断で「どのパイプラインを、どの状態で移行したか」を説明しやすくなります。
まとめ：今回の更新は小さいが、移行ガイドの再確認には使える
Azureの公式ドキュメント更新「Fix image syntax in migration guide」は、差分だけを見ると画像構文の修正であり、Azure Data FactoryやFabric Data Factoryの仕様変更として扱う必要はありません。緊急の設定変更やコード修正が必要な更新ではないと考えてよいでしょう。
一方で、対象ページはAzure Data FactoryからFabric Data Factoryへの移行ガイドです。移行中または移行検討中のチームにとっては、画面手順、事前評価、接続マッピング、トリガー、グローバルパラメーター、非対応機能を見直すよいきっかけになります。
次に取るべき行動は明確です。まず公式ページの該当箇所と社内手順書を照合し、移行対象のADFパイプラインで評価を実行してください。そのうえで、Readyなものから非本番環境で検証し、Needs reviewやNot compatibleの項目は再設計計画に分けて管理するのが安全です。
コメント