データを複数の場所から集め、変換して、分析用の置き場へ届ける——その一連の流れをクラウド上で組み立てるサービスが Azure Data Factory（ADF）です。Microsoft Learnの概要では、ハイブリッドなETL／ELTとデータ統合を、コード不要の視覚的な環境でオーケストレーションするクラウドサービスだと説明されています。

この記事では、公開ドキュメントだけを根拠に、ADFが「何をするサービスか」を初心者向けに整理します。パイプライン・データセット・アクティビティという3つの用語の関係と、他のAzureデータサービスとの役割分担を押さえることがゴールです。

結論：ADFは「データ移動と変換の指揮者」

概念	一言で言うと	初心者が覚える比喩
Azure Data Factory	データ統合・ETL／ELTのオーケストレーションサービス	工場の「生産ライン全体の設計図とスケジュール管理」
パイプライン	処理の流れをまとめた単位	レシピの手順書
データセット	入出力データの型・場所の定義	材料と完成品の「型番シート」
アクティビティ	パイプライン内の1ステップ（コピー、変換など）	手順書の「1工程」

ADFはデータそのものを永続保管する倉庫ではありません。Microsoft Learnでは、データの移動と変換をオーケストレーションし、スケジュール実行・監視・再実行を担う、と位置づけられています。倉庫（Azure Synapse Analytics、Azure SQL Database、Data Lake Storageなど）へ届ける「配達と加工の司令塔」だと捉えると迷いにくいです。

ADFが解決する問題

確認できる事実

Microsoft Learnの導入記事では、組織のデータはオンプレミス、SaaS、複数クラウドに分散しがちで、分析の前に「集める・整える・届ける」必要があると説明されています。ADFは90以上の組み込みコネクタで多様なソースとシンク（出力先）を接続し、サーバーレスでスケールする、と記載されています。

製品ページでも、データエンジニアがコーディングなしでパイプラインを構築し、ETL／ELTワークロードを自動化できる、とされています。

実務解釈

ADFを検討する場面は、次のようなときです。

状況	ADFが向く理由	注意点
毎日・毎時のバッチでデータを集めたい	スケジュールトリガーで自動実行できる	リアルタイム1件ずつの処理は別サービスが向く
オンプレとクラウドの両方から取り込みたい	ハイブリッド統合が公式の想定ユースケース	セルフホステッド統合ランタイムの設計が要る
変換ロジックを視覚的に組みたい	Mapping Data Flowsでノーコード変換が可能	複雑なロジックはSpark系やSQL側でやる選択もある
複数ステップの依存関係を管理したい	パイプラインで順序・分岐・エラー処理を定義できる	1ステップだけならCopy Activity単体でも可

「とにかく全部ADF」ではなく、移動と変換のオーケストレーションが担当範囲だと覚えておくと、他サービスとの線引きが楽になります。

3つの基本コンポーネント

パイプライン（Pipeline）

Microsoft Learnでは、パイプラインは「データを移動・変換する一連のアクティビティをグループ化した論理単位」です。1つのファクトリ（ADFの管理単位）に複数のパイプラインを置けます。

初心者向けの最小構成は次のイメージです。

[スケジュールトリガー]
        ↓
[パイプライン]
  ├─ アクティビティ1: ソースからステージングへコピー
  ├─ アクティビティ2: データフローで変換
  └─ アクティビティ3: 倉庫へロード

パイプラインは「何を、どの順で、失敗したらどうするか」をまとめた設計図です。個別のSQLスクリプトや手動コピーをバラバラに運用するより、再実行・監視・履歴を一元化しやすくなります。

データセット（Dataset）

データセットは、パイプラインが参照するデータの論理的な型です。Microsoft Learnでは、データセットはデータの構造（テーブル名、ファイルパス、列定義など）を記述し、実体のストレージとはリンクで結ばれる、と説明されています。

データセットで決めること	例
データの場所	Blobコンテナ、SQLテーブル、ファイルパス
形式	CSV、Parquet、テーブルスキーマ
入出力の役割	ソース用データセット／シンク用データセット

「データセット＝ファイルそのもの」ではありません。ストレージ上の実データを指し示すメタデータだと理解すると、アクティビティとの関係が見えやすくなります。

アクティビティ（Activity）

アクティビティはパイプライン内の1つの処理ステップです。Microsoft Learnの一覧では、代表的な種類として次が挙げられます。

種類	代表例	役割
データ移動	Copy Activity	ソースからシンクへデータをコピー
データ変換	Mapping Data Flow	視覚的に変換ロジックを定義・実行
制御	Lookup、If Condition、ForEach	分岐・ループ・メタデータ取得
外部処理	Databricks Notebook、Stored Procedure	外部エンジンで処理を実行

Copy ActivityはADFで最もよく使われるアクティビティのひとつで、組み込みコネクタ経由で多様なソースとシンク間のデータ移動を担います。変換が必要なら、Mapping Data Flowや外部のSpark／SQL処理をパイプラインに組み込む、という使い分けが基本形です。

ADFと他のAzureデータサービスの関係

確認できる事実

Microsoft LearnのAzureデータサービス比較では、ADFはデータ統合とオーケストレーション、Azure Synapse Analyticsは分析用の統合プラットフォーム（SQL、Spark、パイプライン統合）、Azure Data Lake Storageは大規模データの保存、それぞれ役割が分かれています。ADFの製品説明でも、統合したデータをSynapse Analyticsなどへ届け、Power BIで洞察を得る流れが示されています。

実務解釈

サービス	主な役割	ADFとの関係
Azure Data Factory	移動・変換のオーケストレーション	—
Azure Data Lake Storage	生データ・加工済みデータの保存	ADFのコピー先／ソースになりやすい
Azure Synapse Analytics	SQL／Sparkによる分析・倉庫	ADFがデータを届ける先のひとつ
Azure Databricks	Sparkベースの処理・機械学習	ADFパイプラインからNotebookを呼び出せる
Azure Stream Analytics	リアルタイムストリーム処理	バッチ中心のADFとは用途が異なる

「ADF＝データウェアハウス」ではありません。倉庫やレイクは置き場、ADFはそこへ届ける配線と加工の司令塔です。チーム内でこの線引きを共有しておくと、設計議論がすっきりします。

ETL／ELTにおけるADFの立ち位置

確認できる事実

Microsoft Learnの導入では、ADFはETL（抽出・変換・格納）とELT（抽出・格納・変換）の両方のパターンに対応すると明記されています。Copy Activityでまずデータレイクへ生データを載せ（ELT寄り）、Mapping Data Flowで変換してから倉庫へロードする（ETL寄り）といった組み合わせが可能です。

実務解釈

パターン	ADFでの典型的な構成	向く場面
ETL寄り	Copy → Data Flow（変換）→ Copy（倉庫へ）	載せる前に品質を固めたい
ELT寄り	Copy（レイクへ）→ Synapse／Databricksで変換	生データを残し、後から変換を変えたい
移動のみ	Copy Activityだけのパイプライン	変換は下流のSQLやBIで行う

どちらが正解という話ではなく、変換をどこでやるかを先に決め、ADFのパイプラインでその順序を表現する、という進め方が初心者には安全です。

実装チェックリスト

ADFの役割を「オーケストレーション」と一文で説明できる
パイプライン・データセット・アクティビティの違いを図で書ける
ソースとシンク（出力先）を一覧にした
Copy Activityで足りるか、変換（Data Flow／外部処理）が要るか判断した
倉庫／レイクなどの置き場とADFの役割分担を整理した
ETLかELTか（変換の場所）を決めた
スケジュールトリガーと再実行方針（失敗時の通知先）を決めた
オンプレソースがある場合、統合ランタイムの要否を確認した

失敗パターン

ADFをデータ保管場所だと思う → 対策：永続保管はData Lake StorageやSynapseなど。ADFはパイプラインとメタデータの管理が中心。

データセットと実ファイルを同一視する → 対策：データセットは「型と場所の定義」。実体はリンクされたストレージ側にある。

Copyだけで変換も全部やろうとする → 対策：単純な型変換や列マッピングはCopy内で可能な場合もあるが、複雑な変換はData Flowや下流のSQL／Sparkに任せる。

パイプラインを1本に全部詰め込む → 対策：ソース単位やドメイン単位でパイプラインを分け、共通処理は子パイプラインやテンプレート化を検討する。

スケジュールと監視を後回し → 対策：本番運用ではトリガー設定と失敗通知（アラート、Logic Apps連携など）を最初から設計に入れる。

リアルタイム要件をADFに押し付ける → 対策：秒単位のストリーム処理はStream AnalyticsやEvent Hubs連携など別サービスを検討。ADFはバッチ統合が主戦場。

参考リンク

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。