2026.07.23 インフラ

Azure Data Factoryとは？仕組み・パイプラインとコンポーネント・料金と採用判断を実装者目線で解説

Azure Data Factory（ADF）はMicrosoft Azureのマネージドなクラウドデータ統合サービスで、複数のデータソースからデータを取り込み、変換し、目的のデータストアへ届けるETL／ELTのワークフローをコードをほとんど書かずに組めます。実装で最初に押さえるべきは、処理の入れ物であるパイプラインと、それを構成するアクティビティ・データセット・リンクされたサービス・統合ランタイムといったコンポーネントの関係です。この記事では定義から、データを動かすコピーアクティビティと変換を担うマッピングデータフロー、CI/CDと監視、料金を左右する課金軸、AWS GlueやMicrosoft Fabric Data Factoryとの違い、そして「どんなシステムで採用し、どこでは見送るか」の判断基準までを、2026年時点の公式ドキュメントに基づいて整理します。

目次

まとめ：Azure Data Factoryの要点と採用判断の分岐

Azure Data Factoryは、オンプレミスとクラウドにまたがるデータを、データドリブンなワークフローとして移動・変換できるマネージドな統合基盤です。処理の単位はパイプラインで、その中にコピーや変換などのアクティビティを並べ、接続情報はリンクされたサービス、実行環境は統合ランタイムが担います。変換はSparkベースのマッピングデータフローで視覚的に組め、CI/CDはAzure DevOpsとGitHubに対応します。次世代版としてMicrosoft Fabric上のData Factoryが位置づけられており、新規のデータ統合はFabricから始める案内も出ています（2026年時点）。

採用が合理的なのは、Azure中心の環境で、社内外に散らばるデータをデータウェアハウスやデータレイクに集約し、定期実行やイベント駆動で回すデータ基盤をマネージドに寄せたい場合です。逆に、ストリーミングのリアルタイム処理が主体ならStream AnalyticsやEvent系サービス、細粒度のコード変換が中心ならDatabricksやFunctionsが向きます。自社のデータ基盤にどの構成を組むべきか迷う段階なら、設計から相談できる開発会社に早めに当たると手戻りを防げます。

Azure Data Factoryの仕組みと主要コンポーネント

ADFは「パイプライン」を実行単位とするデータ統合サービスです。ひとつのパイプラインは、データを動かし変換する複数のアクティビティを論理的にまとめたもので、これを支えるいくつかのコンポーネントの連携で成り立ちます。実装の全体像は、各部品が何を担うかを押さえると一気に読み解けます。

ETL／ELT・データ統合のマネージドサービスという位置づけ

ADFは、抽出・変換・読み込み（ETL）と、抽出・読み込み・変換（ELT）、そしてデータ統合のプロジェクト向けに作られたクラウドサービスです。生データそのものは分析の文脈を持たないため、複数のソースから集めて加工し、意思決定に使える形へ整える工程が要ります。この一連の流れを担うのがデータ統合であり、その概念的な整理はETLとELTの違いやツール選定を解説した記事で前提を確認しておくと、この後のコンポーネントの話がつながりやすくなります。ADFはその概念を、Azure上でマネージドに実行する具体的な製品という位置づけです。

パイプライン・アクティビティ・データセット・リンクされたサービス

コンポーネントは役割で分かれます。パイプラインはアクティビティの論理グループで、まとめて管理・実行できる入れ物です。アクティビティはパイプライン内の処理ステップを表し、公式にはデータ移動・データ変換・制御の3種類に分かれます。データセットは、入力や出力として扱うデータの構造（どのテーブルやファイルか）を指し示す参照です。リンクされたサービスは接続文字列に近い存在で、データストアやコンピューティング環境への接続情報を定義します。ざっくり言えば、リンクされたサービスが「どこへ接続するか」、データセットが「その中のどのデータか」、アクティビティが「それをどう処理するか」を受け持つ構造です。

統合ランタイム（Integration Runtime）とトリガーの役割

統合ランタイムは、アクティビティとリンクされたサービスを橋渡しし、処理が実際に走るコンピューティング環境を提供する土台です。クラウド内やクラウド間の処理を担うAzure統合ランタイム、オンプレミスや閉域網のデータへ届くためのセルフホステッド統合ランタイム、既存のSSISパッケージをそのまま動かすAzure-SSIS統合ランタイムがあり、接続先やネットワーク要件で使い分けます。トリガーはパイプラインをいつ起動するかを決める処理単位で、一定間隔のスケジュール、時間ウィンドウ、BLOB到着などのイベントを起点に設定できる仕組みです。パラメーターや変数を使えば、同じパイプラインを引数違いで再利用でき、制御フローで分岐やループも組めます。

コピーアクティビティとマッピングデータフローによる移動と変換

ADFで実際にデータを動かし加工する中心は、コピーアクティビティとマッピングデータフローの2つです。ここを取り違えると、本来コード不要で組める変換を外部に切り出したり、逆に重い処理を無理にデータフローへ寄せたりして、性能と料金の両面で損をします。

コピーアクティビティで組むデータストア間のデータ移動の仕組み

コピーアクティビティは、ソースのデータストアからシンク（宛先）のデータストアへデータを移す処理です。オンプレミスのSQL ServerやOracle、ファイル共有、各種SaaS、Azure Blob StorageやAzure SQL Databaseなど、多数のコネクタ（90を超えるとされる・2026年時点）を通じて接続します。まずは一元化された場所へデータを集める「収集」の役割を担い、集めた先としてデータレイクの仕組みを実装視点で解説した記事で扱うようなストレージを使うのが典型です。コピー時に圧縮をかけて帯域を抑えたり、コピー前後にデータのプレビューや検証を挟んだりする機能も備わります。

マッピングデータフローとマネージドSparkによるデータ変換

集めたデータの変換を担うのがマッピングデータフローです。結合・集計・列の派生・行のフィルターといった変換ロジックを、ブラウザー上のグラフとして視覚的に組み立てられます。実行時にはADFが管理するSparkクラスターが必要に応じて起動し、処理が終わると停止するため、Sparkクラスターの構築や運用の知識がなくても大規模な変換を回せる点が持ち味です。手でコードを書きたい場合は、HDInsightやDatabricks、Machine Learningなどの外部コンピューティングを呼び出す変換アクティビティも使えます。変換後のデータは、BIから使うAzure Synapse AnalyticsやAzure SQL Databaseなどへ発行し、データウェアハウス（DWH）の仕組みと選び方を解説した記事で扱うような分析基盤に載せていきます。

CI/CDと監視（Azure DevOps・GitHub・Azure Monitor）

ADFはデータパイプラインのCI/CDに対応し、Azure DevOpsとGitHubを使って開発から公開までを段階的に進められます。パイプラインの定義はコードとして扱えるため、開発・検証・本番の各環境へ順に反映していく運用に向いた構造です。運用フェーズでは、スケジュールされたパイプラインとアクティビティの成功・失敗を監視でき、Azureポータルの監視画面に加え、Azure Monitorやログ、API、PowerShellから稼働状況を追えます。つまり、開発の版管理から本番の監視までを一貫してAzureのエコシステムに載せられるのが実装上の利点です。

Azure Data Factoryの料金の考え方と類似サービスとの違い

ADFは似た役割のサービスと混同されやすく、料金体系も直感に反しやすい領域です。課金軸と、周辺サービスとの守備範囲を押さえると、単独で使うか組み合わせるかの判断がつきます。

Azure Data Factoryの従量課金を構成する主な課金軸

ADFの料金は使った分だけ払う従量制で、いくつかの軸の合算で決まります。実測見積もりでは、この分解を知らないと桁がずれます。

課金軸 課金の対象
オーケストレーション アクティビティやトリガーの実行回数
データフロー実行 Sparkの計算時間（vCore時間）
データ移動 コピーのデータ統合単位（DIU時間）
SSIS統合ランタイム 割り当てたノードの稼働時間

散発的に少量を動かすだけならオーケストレーションとデータ移動の従量が中心で軽く収まります。一方、マッピングデータフローを多用したり、SSIS統合ランタイムを常時立てたりすると、計算・稼働時間の課金が積み上がります（金額は時点とリージョンで変動）。高頻度のデータフローほど、変換をコピー時の軽処理へ寄せられないか、実行時間を短縮できないかを設計段階で検討すると、コストを抑えやすくなります。

Azure Synapse・Microsoft Fabricとの関係と違い

ADFのパイプライン機能は、Azure Synapse Analyticsのパイプラインとしても提供され、分析基盤と統合された形で使えます。さらにMicrosoftは、次世代版としてMicrosoft Fabric上のData Factoryを打ち出しており、よりシンプルなアーキテクチャと組み込みのAI機能を備えるとして、データ統合を新規に始める場合はFabricから着手する案内を出しています（2026年時点）。既存のADFワークロードはFabricへアップグレードする移行パスも用意されます。したがって新規プロジェクトでは、単体のADFで組むか、SynapseやFabricを含む全体像で設計するかを最初に見極めるのが要点です。

AWS GlueやDatabricksなど類似サービスとの対応関係

マルチクラウドやAWSからの移行を検討する際は、対応物を押さえると設計を横展開できます。マネージドなETL／データ統合という役割は、AWSではGlueが近い立ち位置にあり、フルコードの分散処理が主体ならAzure・AWSともにDatabricksやSparkベースが選択肢です。クラウドごとの守備範囲や強みの違いはAWS・Google Cloud・Azureの特徴と使い分けを比較した記事で全体像を掴んでおくと、どのクラウドのデータ統合サービスに寄せるかの判断がしやすくなります。ADFはコード不要のパイプライン設計とAzureサービスとの密な連携が持ち味で、変換の自由度を最大化したい局面はDatabricks側に寄せる、という組み合わせが実務ではよく取られます。

Azure Data Factoryを採用すべき場面と見送る場面

ここからは判断です。ADFは万能のデータ処理基盤ではなく、向く用途と向かない用途がはっきり分かれます。要件から逆算し、条件付きで採否を言い切ります。

Azure Data Factoryの採用が第一候補として合理的になる条件

次のいずれかに該当するなら、ADFが第一候補になります。

  • Azure中心の環境で、複数のデータソースをDWHやデータレイクに定期集約したい
  • オンプレミスからクラウドへのデータ移行を、コネクタとマネージド運用で進めたい
  • 変換ロジックをコードではなく視覚的なデータフローで組み、運用を含めて任せたい
  • 既存のSSISパッケージをクラウドへ持ち込み、当面はそのまま動かしたい

いずれもコネクタとマネージド運用、そしてSparkクラスターを持たずに変換を回せる強みが効く領域です。特にサーバー管理を抱えずにデータ基盤を組みたい場合、従量課金で小さく始められる点が導入のハードルを下げます。

Azure Data Factoryを選ぶべきでない場面と代替サービス

一方で、次の要件にはADFを選びません。ここを混同すると設計が破綻します。第一に、ミリ秒〜秒単位で流れ続けるデータをリアルタイムに処理したいなら、バッチ寄りのADFより、Stream AnalyticsやEvent Hubs・Event Gridといったストリーミング系が向きます。第二に、複雑なコード変換や機械学習の前処理が主体なら、視覚的なデータフローで無理に組まず、DatabricksやSparkに寄せるべきです。第三に、扱うデータがAzure外の単一SaaS内で完結する軽微な連携なら、重厚なデータ統合基盤より、Logic AppsやPower Automateのワークフローで足ります。第四に、これからデータ統合を新規に始める場合は、単体ADFを組む前に次世代のMicrosoft Fabric Data Factoryを含めて比較し、後の移行を見越して選ぶ判断も要ります。

受託開発におけるデータ基盤の設計判断と外注先選定の実務的な勘所

実際のシステムでは、ADF単体ではなくストレージ・DWH・BI・場合によってはDatabricksを役割ごとに組み合わせる構成が普通です。どの変換をコピー時の軽処理に寄せ、どこをデータフローやDatabricksに載せるか、統合ランタイムをどの種類で用意するかは、データ量・閉域要件・月次コストのトレードオフで決まり、運用開始後の作り替えには相応の手間が伴います。要件定義の段階でデータの流れ全体を固めておくほど、後の手戻りを避けられる設計です。Azureを含むデータ分析基盤の構築・運用の相談では、ETLパイプラインの設計から実装・監視までを一貫して支援できます。

よくある質問

Azure Data Factoryの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。

Azure Data FactoryとSSISはどう違いますか？

SSISはSQL Server由来のオンプレミス前提のETLツールで、ADFはクラウド上のマネージドなデータ統合サービスです。両者は排他ではなく、既存のSSISパッケージはAzure-SSIS統合ランタイムを立てればADF上でそのまま実行でき、クラウドへの持ち込み口になります。新規に組むならクラウドネイティブなパイプラインとデータフローで設計し、資産を活かしたい範囲だけSSISを載せる、という併用が現実的です。

コピーアクティビティとマッピングデータフローの使い分けは？

コピーアクティビティはデータストア間の移動が役割で、ソースからシンクへデータを運ぶ処理です。マッピングデータフローは結合・集計・列変換などの加工を担い、実行時にマネージドなSparkで処理する仕組みです。単純にデータを移すだけならコピー、移した後に構造や中身を変換する必要があればデータフロー、と役割で切り分けます。軽い整形はコピー内の機能で済ませ、重い変換だけデータフローに寄せると料金を抑えやすくなります。

統合ランタイムにはどんな種類がありますか？

大きく3種類です。クラウド内やクラウド間の処理を担うAzure統合ランタイム、オンプレミスや閉域網のデータへ届くためのセルフホステッド統合ランタイム、既存のSSISパッケージを動かすAzure-SSIS統合ランタイムがあります。接続先がクラウド完結ならAzure統合ランタイム、社内ネットワーク内のデータに触るならセルフホステッド、と接続要件で選びます。

料金はどの要素で決まりますか？

従量課金で、複数の軸の合算です。アクティビティやトリガーの実行回数によるオーケストレーション、マッピングデータフローのSpark計算時間、コピーのデータ統合単位（DIU）時間、SSIS統合ランタイムのノード稼働時間が主な軸になります。散発的な少量処理なら軽く収まり、データフローの多用やSSIS統合ランタイムの常時稼働ほど費用が積み上がるため、実行頻度と処理方式が見積もりの勘所です（金額は時点とリージョンで変動）。

Microsoft Fabricがある今、ADFは使うべきですか？

既存のADFワークロードは継続して利用でき、Synapse内のパイプラインとしても使えます。ただしMicrosoftは新規のデータ統合について、次世代版であるMicrosoft Fabric上のData Factoryから始める案内を出しています（2026年時点）。したがって、これから組むなら単体ADFとFabricを比較し、将来の移行を見越して選ぶのが無難です。稼働中の資産はアップグレードパスが用意されているため、慌てて作り替える必要はありません。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る