Azure ETLとは？Data Factoryの機能・料金・導入判断の進め方を解説

社内に散らばったデータをAzureへ集約したい、あるいはオンプレミスのETL基盤をクラウドへ移行したい。そう考えたとき、「Azure ETLの具体的な仕組みがわからない」「どのサービスを選べばよいか判断できない」という壁にぶつかることは少なくありません。ETLとELTの違いから料金体系まで、調べるほど情報が増えて判断が難しくなるのも、このテーマの特徴です。

Azure上でETL/ELTを実現する中心サービスはAzure Data Factory（ADF）です。90種類以上のコネクタ（※）、ノーコードのGUI、フルマネージドのサーバーレス実行基盤を備え、オンプレミスのSSIS資産からSaaS間のデータ連携まで幅広いユースケースに対応します。Azureを主要クラウドとして使っている組織であれば、まず検討すべき選択肢といえます。

※最新情報はMicrosoft公式ドキュメントをご参照ください。

判断を前に進めるには、ETL/ELTの方式選択・ADFの構成要素・料金体系・自社への適合性という4つの軸を順に整理するのが近道です。それぞれの論点を以下で具体的に見ていきます。

なお、ETL基盤の構築だけでなく、統合後データのマーケティング活用まで一気通貫で進めたい場合は、GENIEE CDPの併用も有効です。ADFで連携したデータを活用フェーズにつなげるまでの立ち上がりを短縮できます。

ETLとELTの違い：Azure上での方式選択の前提知識

Azure上でデータパイプラインを設計するとき、最初に問われるのが「ETLにするかELTにするか」という選択です。

どちらも「データを抽出して変換して格納する」という目的は同じですが、変換をどのタイミング・どこで行うかが根本的に異なります。この違いを理解しておくと、ツール選定や設計方針の判断がずっとシンプルになります。

ETLの処理フローと特徴

ETLはExtract（抽出）→ Transform（変換）→ Load（格納）の順で処理が進みます。データソースから取り出したデータを、専用のステージング領域やエンジン上で変換・整形してから、ターゲットのデータベースやDWHへ格納します。

この方式の特徴は、ターゲットDBに届く時点でデータがすでに整形済みである点です。変換処理の負荷はステージング側が引き受けるため、ターゲットDB側に変換コストが発生しません。複雑なビジネスロジックや多段階の変換処理が必要なケース、あるいはターゲットDBの処理能力が限られている環境では、ETLが安定した選択肢になります。

一方で、変換ロジックの変更が生じた場合にステージング側の設計を修正する必要があり、柔軟性という点では後述のELTと比べてやや硬い構造になりやすい面もあります。

ELTの処理フローと特徴

ELTはExtract（抽出）→ Load（格納）→ Transform（変換）の順で処理します。データをまずターゲットDBへそのままロードし、変換はターゲットDB上で行います。

この方式が注目されるようになった背景には、クラウドDWHの普及があります。Azure Synapse AnalyticsのようなクラウドDWHは大規模な並列処理能力を持つため、ロード後の変換処理をDB側に任せても十分なパフォーマンスが得られます。大量データを高速に変換したい場合や、生データをそのまま保持しておいて後から変換ロジックを柔軟に変えたい場合に、ELTは有利に働きます。

ただし、ターゲットDBの処理能力が変換コストを直接受け持つ構造であるため、DBのスペックや課金体系によってはコストが想定以上に膨らむ可能性があります。変換処理の規模とDBの性能・コストのバランスを事前に見積もることが重要です。

自社に適した方式の判断基準

ETLとELTのどちらを選ぶかは、次の4つの軸で整理すると判断しやすくなります。

判断軸	ETLが有利なケース	ELTが有利なケース
データ量	小〜中規模	大規模・高頻度
変換の複雑さ	複雑なビジネスロジックが必要	比較的シンプルな変換
ターゲットDBの処理能力	処理能力が限られている	高性能なクラウドDWH（Synapse等）が利用可能
リアルタイム性要件	バッチ処理中心	準リアルタイム〜バッチ両対応

一般的な指針として、小〜中規模かつ変換ロジックが複雑な場合はETL、大規模かつAzure Synapse Analyticsのような高性能なクラウドDWHが利用できる場合はELTが選ばれやすい傾向があります。ただし、この2軸だけで決まるわけではなく、チームのスキルセットや既存システムとの兼ね合いも実際の選択に影響します。

なお、Azure Data Factory（ADF）はETL・ELT両方の方式に対応しており、方式を決めた後の実装ツールとして機能します。次章でADFの詳細を確認します。

Azure Data Factoryとは？Azure ETL基盤の中心サービス

ETL/ELTの方式が整理できたところで、Azure上でそれを実現する具体的なサービスを見ていきます。

Azure Data Factory（ADF）はMicrosoftが提供するフルマネージドのクラウドETL/ELTサービスで、Azureエコシステムにおけるデータ統合の中心的な役割を担います。データソースとデータストアをつなぐ「オーケストレーター層」として機能し、データの移動・変換・スケジューリングをまとめて管理できます。

Microsoftのデータ統合戦略は、従来のAzure Data Factory（スタンドアロン版）から、統合分析プラットフォーム「Microsoft Fabric」に内包された「Data Factory in Fabric」へと軸足を移しています。新規プロジェクトではFabric Data Factoryの利用が推奨されており、既存のADF環境については直ちに移行する必要はありませんが、中長期的なロードマップとしてFabricへの移行を視野に入れることが重要です。本記事では従来のAzure Data Factoryを中心に解説します。

ADFが選ばれる主な理由

ADFが多くのAzure環境で採用される理由は、機能の幅広さよりも「運用負荷の低さ」と「Azureとの統合性」にあります。

まず、フルマネージド・サーバーレスの実行基盤であるため、インフラのプロビジョニングやスケーリングをユーザーが管理する必要がありません。データエンジニアはパイプラインの設計と変換ロジックに集中できます。

コネクタの豊富さも実務上の強みです。SaaS（Salesforce、ServiceNowなど）・オンプレミスDB・他クラウドストレージを含む90種類以上のコネクタが用意されており、接続先が多様な環境でも追加開発なしに対応できるケースが多くあります。

変換処理については、マッピングデータフローというGUI上でドラッグ＆ドロップで変換ロジックを組み立てられる機能があります。内部的にはApache Sparkクラスターで実行されるため、大規模データにも対応しながら、コーディングなしで変換パイプラインを構築できます。

Azureを主要クラウドとして使っている組織にとっては、Azure Synapse Analytics・Power BI・Microsoft Entra ID（旧Azure Active Directory）とのネイティブ統合が特に大きな利点です。分析基盤全体を一貫した設計で構築しやすく、権限管理やセキュリティポリシーもAzureの仕組みに乗せられます。

ADFが対応するユースケース

ADFが実際に使われる場面は、大きく4つのパターンに整理できます。

• CRM・ERP・SaaSなど複数システムのデータを統合し、分析用のDWHへ集約する
• 定期バッチによるDWHへのデータ投入（日次・週次の売上データ集計など）
• オンプレミスのデータベースやファイルサーバーからAzureへのデータ移行
• 既存のSSISパッケージをクラウド上でそのまま実行するリフト＆シフト移行

特にSSIS資産のクラウド移行については、ADFが専用の実行基盤（Azure-SSIS統合ランタイム）を持っており、既存パッケージを大幅に書き直すことなく移行できる点が評価されています。この詳細は後続の章で改めて整理します。

Azure Data Factoryの構成要素とパイプラインの処理フロー

ADFを実際に使い始めると、「リンクサービス」「データセット」「統合ランタイム」といった固有の用語が次々と登場します。これらは独立した概念ではなく、パイプラインを動かすための5つの構成要素として体系的に整理できます。

各要素の役割と関係性を把握しておくと、設計時の迷いが大幅に減ります。

リンクサービスとデータセット

ADFでデータを扱う前に、まず「どこに接続するか」と「何を操作するか」を定義する必要があります。この2つを担うのがリンクサービスとデータセットです。

リンクサービスは接続先への認証情報やエンドポイントを定義するコンポーネントです。Azure Blob StorageへのアクセスキーやSQL Serverの接続文字列など、「その接続先に到達するための情報」をここに集約します。接続先が変わればリンクサービスを更新するだけでよく、パイプライン全体を修正する必要はありません。

データセットは、リンクサービスで定義した接続先の中で「どのデータを操作するか」を指定するコンポーネントです。特定のBlobコンテナ内のCSVファイル、あるいはSQL Serverの特定テーブルといった、データの構造・場所・フォーマットをここで定義します。

この2層構造により、接続先の認証情報とデータの場所・構造を分離して管理できます。同じリンクサービスを複数のデータセットで再利用できるため、接続先が増えても設定の重複が生じにくい設計になっています。

アクティビティとパイプライン

データの移動・変換・制御という実際の処理を担うのがアクティビティです。アクティビティは大きく3種類に分けられます。

• コピーアクティビティ：データソースからデータストアへのデータ移動を担う。最も基本的なアクティビティで、ほぼすべてのパイプラインで使用される
• データフローアクティビティ：データの変換処理を担う。マッピングデータフローを使えばGUI上でノーコードの変換ロジックを構築でき、内部的にはApache Sparkクラスターで実行される
• 制御アクティビティ：条件分岐（If Condition）・ループ（ForEach）・待機・エラーハンドリングなど、パイプラインの実行フローを制御する

パイプラインは、これらのアクティビティを論理的にグループ化し、実行順序と依存関係を定義するコンテナです。「コピーが成功したらデータフローを実行する」「エラーが発生したら通知アクティビティを起動する」といった処理の流れをパイプライン単位で管理します。

パイプラインはトリガーによって自動実行できます。スケジュールトリガー（毎日深夜2時に実行など）、イベントトリガー（Blobストレージへのファイル到着を検知して起動）、タンブリングウィンドウトリガー（重複しない連続した時間間隔でパイプラインを定期実行し、各ウィンドウの開始・終了時刻をパイプライン内で参照できる。バックフィル処理にも対応）の3種類があり、ユースケースに応じて使い分けます。

統合ランタイム（Integration Runtime）

統合ランタイム（IR）は、ADFのアクティビティが実際に実行されるコンピューティング基盤です。接続先の場所や要件に応じて3種類から選択します。

Azure統合ランタイム

Azureのマネージドクラウド上で動作する実行基盤です。Azure Blob StorageやAzure SQL Databaseなど、パブリッククラウド上のデータソース・データストア間のデータ移動と変換に使用します。

インフラの管理は不要で、ADFが自動的にスケールします。クラウド上のリソースのみを扱う場合はこれが基本の選択肢です。

セルフホステッド統合ランタイム

オンプレミスのサーバーや、プライベートネットワーク内の仮想マシンにインストールして使用するIRです。

インターネット経由でアクセスできないオンプレミスのDBやファイルサーバーへの接続が必要な場合に選択します。社内ネットワーク内に設置したエージェントがADFとの通信を仲介するため、ファイアウォールの内側にあるデータソースにも安全にアクセスできます。

Azure-SSIS統合ランタイム

既存のSSISパッケージをAzure上でそのまま実行するための専用基盤です。オンプレミスで動いていたSSISパッケージを、コードを書き直すことなくクラウドへ移行できます。SSIS資産を持つ組織がAzureへ移行する際の有力な選択肢であり、詳細は後続の章で改めて取り上げます。

パイプライン構築の概念的な流れは、「接続先の定義（リンクサービス）→ データ構造の定義（データセット）→ 処理ロジックの設計（アクティビティ・パイプライン）→ 実行基盤の選択（統合ランタイム）」という順序で進みます。この流れを頭に入れておくと、ADFの料金体系も理解しやすくなります。

Azure Data Factoryの料金体系とコスト試算

ADFは初期費用ゼロの従量課金制です。使った分だけ課金される仕組みのため、小規模な検証から始めやすい反面、パイプラインの規模や実行頻度によってコストが大きく変動します。料金体系の構造を理解しておくことが、導入後のコスト管理において重要になります。

月間一定数のアクティビティ実行については無料枠が設けられており、小規模な検証段階では実質的にコストをかけずに試せます。本番運用に移行する前に、自社の実行パターンに基づいた試算を行うことを強くお勧めします。

4つの課金軸と単価の仕組み

ADFの課金は複数メーターで構成され、主要なのはオーケストレーション、データ移動、データフロー（vCore時間）です。加えてパイプライン/外部アクティビティ実行や監視・操作系の課金が発生します。

1. オーケストレーション課金

パイプラインの実行回数・アクティビティの実行回数・トリガーの実行回数に対して課金されます。実行のたびに課金が発生するため、実行頻度が高いパイプラインでは積み上がりやすい項目です。月間の無料枠を超えた分から課金対象となります。

2. データ移動課金（DIU時間）

コピーアクティビティによるデータ移動は、DIU（データ統合ユニット）という処理能力の単位で課金されます。DIUはADFがデータ移動に割り当てるCPU・メモリ・ネットワーク帯域のまとまりで、DIU数と実行時間の積が課金の基準になります。DIU数を増やすと処理速度は上がりますが、その分コストも増加します。

3. データフロー課金（vCore時間）

マッピングデータフローはSparkクラスターを使って実行されるため、vCore時間で課金されます。注意が必要なのは、Sparkクラスターの起動時間もvCore時間に含まれる点です。実行頻度が低いパイプラインでは、データ処理時間よりも起動オーバーヘッドがコストの大半を占めることがあります。実行頻度が低い場合は、データフローの使用を絞るか、クラスターのTTL（存続時間）設定を調整することでコストを抑えられます。

4. 統合ランタイム稼働時間課金

Azure-SSIS IRは専用VMクラスターとして稼働時間課金されます。Self-hosted IRは主に実行メーター側で課金され、加えて配置先インフラ（VM等）の費用は別途考慮が必要です。

規模別のコスト試算例

以下は、典型的な2つのパイプライン規模における概算月額のイメージです。実際のコストはデータ量・変換の複雑さ・実行頻度・リージョンによって大きく変動するため、あくまで参考値として捉えてください。

規模	前提条件	主な課金項目	コスト感
小規模	月1回バッチ・1〜2データソース・コピーアクティビティのみ	オーケストレーション・データ移動（DIU時間）	無料枠内または数百円程度に収まるケースが多い
中規模	日次バッチ・5データソース・マッピングデータフロー使用	オーケストレーション・データ移動・データフロー（vCore時間）	月数千円〜数万円程度になるケースが多い（データフローの実行時間が支配的）

コストを抑えるうえで効果的なポイントとして、DIU数の調整（必要以上に大きくしない）、データフローの実行頻度の見直し、Azure Hybrid Benefitの活用（既存SQL ServerライセンスをAzure-SSIS IRに適用）が挙げられます。

正確な試算にはAzure公式の料金計算ツール（Azure Pricing Calculator）を使い、自社の実行パターンに基づいた数値を入力することが推奨されます。ツール上でリージョン・DIU数・実行回数・データフロー時間を入力すると、月額の概算を確認できます。

Azure Data Factoryの導入検討時に考慮すべきこと

ADFの機能と料金体系が把握できたところで、「では自社に合っているか」という判断に移ります。ADFへの適合性は、データソースの種類と数・チームの技術スキル・SSIS資産の有無・他クラウドとの併用状況・予算規模の5軸で判断できます。

特にAzureを主要クラウドとして使用している、SSIS資産がある、ノーコード開発が必要、Synapse AnalyticsやPower BIとの連携など、これらの条件が重なるほど、ADFの適合性は高まります。

データソースの種類と数による判断

ADFのコネクタはSaaS（Salesforce・ServiceNow・Dynamics 365など）・オンプレミスDB（SQL Server・Oracle・MySQLなど）・クラウドストレージ（AWS S3・Google Cloud Storageなど）・ファイル形式（CSV・Parquet・JSONなど）と幅広くカバーしています。接続先が多様で数が多い環境では、このコネクタの網羅性が大きな強みになります。

一方、AWS・GCPとの本格的なマルチクラウド環境で、Azureに依存しない中立的なデータ統合基盤を求める場合は、FivetranなどのサードパーティETLツールも選択肢に入ります。Fivetranはコネクタのメンテナンスをベンダーが担うため、接続先のAPI変更への追従コストを下げたい場合に有利です。

判断の目安として、接続先の大半がAzureサービスまたはADFのコネクタでカバーされているなら、ADFで完結させる方がAzureエコシステムとの統合性の面で有利です。マルチクラウドの比重が高い場合は、サードパーティツールとの併用も含めて検討する価値があります。

SSISからの移行可否と難易度

SSIS資産を持つ組織にとって、ADFは最も現実的なクラウド移行先の一つです。Azure-SSIS統合ランタイムを使えば、既存のSSISパッケージをAzure上でそのまま実行できます。パッケージの書き直しが不要なため、移行リスクと工数を大幅に抑えられます。

移行の難易度に影響する主な要因は、オンプレミス依存の接続先の有無です。SSISパッケージがオンプレミスのDBやファイルサーバーに接続している場合、セルフホステッドIRを組み合わせてネットワーク経路を確保する設計が必要になります。この部分の設計が移行プロジェクトで最も検討を要するポイントになることが多いです。

コスト面では、Azure Hybrid Benefitを活用することで、既存のSQL ServerライセンスをAzure-SSIS IRに適用してコストを削減できる可能性があります。ライセンスの適用条件はMicrosoft公式で確認が必要ですが、既存ライセンスを持つ組織では見落とせない選択肢です。

他のETLツールとの比較観点

ADFと他のETLツールを比較する際に見るべき軸は、開発スタイル・主要ユースケース・コネクタ数・課金体系・SSIS対応の5点です。以下の表で主要ツールを整理します。

比較軸	Azure Data Factory	Fivetran	Integrate.io
開発スタイル	ノーコードGUI＋コード（ARM/SDK）	ノーコード（設定ベース）	ノーコードGUI＋SQL変換
主要ユースケース	ETL/ELT・データ移行・SSIS移行	ELT特化・SaaSデータ収集	ETL/ELT・API連携
コネクタ数	90種類以上（最新情報は公式サイトで参照を）	500種以上（最新情報は公式サイト参照を）	200種類以上の変換・多数コネクタ（最新情報は公式サイト参照を）
課金体系	従量課金（実行回数・DIU時間等）	要確認（公式サイト参照を）MAR（月間アクティブ行数）ベース従量課金（2026年改定）	要確認（公式サイト参照を）固定料金制（$1,999/月〜）
SSIS対応	Azure-SSIS IRで対応	非対応	非対応
Azureエコシステム統合	ネイティブ統合	部分的に対応	部分的に対応

ADFが有利なのは、Azureを中心に使っている・SSIS資産がある・Synapse/Power BIとの連携が必要というケースです。Fivetranが有利なのは、SaaSからのデータ収集をメンテナンスフリーで運用したい・マルチクラウド環境でAzureへの依存を避けたいというケースです。Integrate.ioはAPI連携を含む中規模のETLパイプラインで選ばれることが多く、AzureへのロックインなしにETL/ELTを構築したい場合の選択肢になります。

ツール選定の最終的な判断は、自社のクラウド戦略・既存資産・チームのスキルセットの3点を軸に行うのが現実的です。ADFは「Azureを使い続ける前提」が固まっている組織では、他ツールと比べて統合コストが低く、長期的な運用管理も一元化しやすい選択肢といえます。

まとめ

Azure上でのETL/ELT構築を検討するとき、最初に問われるのは方式の選択（ETLかELTか）であり、その答えはデータ量・変換の複雑さ・ターゲットDBの処理能力・リアルタイム性要件の4軸で整理できます。

そのうえで、Azure Data Factoryはリンクサービス・データセット・アクティビティ・パイプライン・統合ランタイムという5つの構成要素で動き、従量課金制のコスト構造を持つサービスです。

導入の第一歩として現実的なのは、Azureアカウントの無料枠を使って1つのデータソースで小規模なパイプラインを試験構築することです。コピーアクティビティだけのシンプルなパイプラインでも、ADFの操作感・コスト感・Azureとの統合性を実際に確認できます。本番設計に進む前に、この小さな検証を挟むことで、設計上の見落としを早期に発見しやすくなります。