データパイプラインとは
データパイプラインとは、データをある場所から別の場所へ移動・変換・格納する一連の処理を自動化した仕組みです。業務システム・ログ・APIなどの多様なデータソースから、分析用データウェアハウスやデータレイクへデータを届けるまでの流れ全体を指します。
「パイプライン」という名称は、データが水道管の中を流れるように処理ステップを順番に通過していくイメージに由来します。各ステップは独立したコンポーネントとして実装され、障害時の再実行やスケールアウトが容易な設計が理想とされます。
データパイプラインが重要視される背景には、データ活用の高度化があります。企業が保有するデータは業務システム・IoTセンサー・ウェブログ・SNS連携など多様な形式で蓄積されており、これらを分析可能な形に整えて届けるまでの工程が複雑化しています。データパイプラインは「データエンジニアリング」の中核領域として、DMBOK2（データマネジメント知識体系）でも「データ統合・相互運用性（Data Integration & Interoperability）」として独立した章を持ちます。
ETL・ELT・リバースETLの違いと使い分け
データパイプラインを語る上で最初に理解すべき概念が、ETL・ELT・リバースETLの3つのパターンです。それぞれの処理順序と適している場面が異なります。
ETL（Extract・Transform・Load）
ETLは「抽出→変換→格納」の順で処理します。データソースからデータを取り出し（Extract）、中間の変換エンジン上でクレンジング・加工・統合（Transform）してから、最終的な形でデータウェアハウスに格納（Load）します。
ETLが適している場面は、変換処理が複雑でデータウェアハウスに格納する前に品質を確保したい場合、またはDWH側の演算コストを抑えたい場合です。DataSpider・Talend・IBM DataStageなど伝統的なETLツールはこのパターンで設計されています。
ELT（Extract・Load・Transform）
ELTは「抽出→格納→変換」の順で処理します。データをまず生のままDWHやデータレイクに格納（Load）してから、DWH内部の演算能力を活用して変換（Transform）します。
BigQuery・Snowflake・Redshiftのような高性能クラウドDWHの普及により、変換をDWH側に任せるELTが近年の主流になっています。変換ロジックをSQLで記述するdbt（data build tool）は、ELTパターンの「Transform」フェーズを担うツールとして急速に普及しています。Fivetranは「Extract→Load」部分を自動化したSaaSで、dbtと組み合わせてELTパイプラインを構成することが多いです。
リバースETL（Reverse ETL）
リバースETLは、DWHや分析基盤に蓄積されたデータを、CRM・MAツール・広告プラットフォームなど業務システムに逆向きに送り返すパターンです。分析結果をそのままSalesforceの顧客レコードに書き戻したり、分析セグメントをFacebook広告に連携したりする用途が代表例です。Census・Hightouch・RudderStackがリバースETLの主要ツールです。
| パターン | 処理順 | 変換の場所 | 主な用途 |
|---|---|---|---|
| ETL | Extract → Transform → Load | 中間エンジン（ETLサーバー） | 基幹系連携・厳密な品質管理が必要な場面 |
| ELT | Extract → Load → Transform | DWH内（SQL・Sparkなど） | クラウドDWH活用・大量データ・柔軟な変換 |
| リバースETL | DWH → Transform → 業務システム | リバースETLツール | 分析結果をCRM・広告・MAに反映 |
バッチ処理とストリーム処理の使い分け
データをどのタイミングで処理するかによって、バッチ処理・ストリーム処理・マイクロバッチの3つのモデルがあります。設計時にどれを選ぶかは、レイテンシ要件とコストのトレードオフで決まります。
バッチ処理
バッチ処理は、一定の時間間隔（夜間・毎時・毎日）でデータをまとめて処理するモデルです。売上日次集計・月次レポート生成・大量データの定期変換など、リアルタイム性が求められない処理に適しています。Apache Spark・AWS Glue・Google Cloud Dataproc・Airflowによるジョブスケジューリングが代表例です。
バッチ処理の利点は、処理コストが低く安定している点と、複雑なジョイン処理やウィンドウ集計が実装しやすい点です。欠点はデータの鮮度に遅延が生じる点で、最短でも数分〜数時間の遅れが発生します。
ストリーム処理
ストリーム処理は、データが発生するたびにリアルタイムで処理するモデルです。クレジットカードの不正検知・IoTセンサーの異常検知・ユーザー行動のリアルタイム分析など、低レイテンシが求められる場面で使われます。Apache Kafka・Apache Flink・Google Cloud Dataflow（Apache Beamベース）・Amazon Kinesisが代表的なプラットフォームです。
ストリーム処理では「Exactly-once（厳密に1回）」の処理保証が重要な課題になります。ネットワーク障害による再送や重複処理を防ぐために、チェックポイントとトランザクション管理を組み合わせます。
マイクロバッチ
マイクロバッチは、数秒〜数分単位の短いバッチ間隔で処理するアプローチで、バッチとストリームの中間に位置します。Apache Spark Structured Streaming（旧Spark Streaming）が代表例で、完全なストリーム処理よりも実装が容易でありながら、分単位のリアルタイム性を実現できます。
| 処理モデル | レイテンシ目安 | 適した用途 | 代表ツール |
|---|---|---|---|
| バッチ | 数分〜数時間 | 日次集計・月次レポート | Spark・Airflow・Glue |
| マイクロバッチ | 数秒〜数分 | 準リアルタイム分析 | Spark Streaming・Flink |
| ストリーム | ミリ秒〜秒 | 不正検知・IoT・行動分析 | Kafka・Flink・Dataflow・Kinesis |
主要データパイプラインツールの比較
データパイプラインを構築するツールは、オープンソース・クラウドマネージド・商用パッケージに大別されます。以下に代表的なツールを整理します。
| ツール名 | 種別 | デプロイ形態 | 主な用途 | 試験との関連 |
|---|---|---|---|---|
| DataSpider Servista | 有償 | オンプレ／クラウド | 業務システム連携（ERP・CRM・EDI） | 国内試験での出題頻度が高い |
| Apache Airflow | OSS | セルフホスト／マネージド | バッチワークフロー管理（DAG定義） | データエンジニアリング領域で頻出 |
| Fivetran | 有償SaaS | クラウドネイティブ | ELT（SaaS→DWHの自動同期） | ELT概念の具体例として参照される |
| AWS Glue | 有償PaaS | AWS | サーバーレスETL・カタログ管理 | クラウドETLの代表例 |
| Google Cloud Dataflow | 有償PaaS | GCP | バッチ・ストリーム統合処理（Apache Beam） | ストリーム処理の問題で言及される |
| Talend Open Studio | OSS（有償版あり） | オンプレ／クラウド | ETL設計・データ品質管理 | DMBOKのデータ統合領域と対応 |
| dbt（data build tool） | OSS（有償版あり） | クラウド中心 | ELT変換層（SQLによるモデリング） | 「Transform in DWH」概念の具体例 |
DataSpider（国内試験での重要度が高いツール）
DataSpider Servistaは、株式会社セゾンテクノロジー（旧アプレッソ）が開発・提供する国産ETLミドルウェアです。GUIベースのフロー設計でコーディング不要のデータ連携が可能で、SAP・Oracle・Salesforce・各種DBへの豊富なアダプタを持ちます。金融・製造・官公庁など国内大企業での採用実績が多く、データ統合に関する国内試験の問題文に登場することがあります。
Apache Airflow（ワークフロー管理の標準）
Airflowは、Airbnbが開発しApache Software Foundationに移管されたOSSのワークフロー管理ツールです。DAG（有向非巡回グラフ）でジョブの依存関係を定義し、Pythonコードでパイプライン全体を記述します。AWSのAmazon MWAA・GoogleのCloud Composerとしてマネージドサービスが提供されており、データエンジニアの標準ツールとして広く普及しています。
dbt + Fivetranの組み合わせ
Fivetranは180以上のSaaSコネクタを持つELTのExtract→Load専用SaaSで、Salesforce・Stripe・PostgreSQLなどからDWHへのデータ同期を自動化します。dbtは変換（Transform）フェーズをSQLで宣言的に記述するツールで、データリネージの可視化やテスト機能も備えます。両者を組み合わせた「Fivetran + dbt」はModern Data Stackの代表的な構成として知られています。
設計時に押さえるべき4つの重要ポイント
データパイプラインを本番運用に耐える形で設計するには、機能要件（何を運ぶか）に加えて非機能要件（どのように運ぶか）への対応が不可欠です。以下の4点は試験でも出題される頻度が高い設計原則です。
スキーマ進化（Schema Evolution）への対応
データソース側のスキーマ変更（カラム追加・型変更・削除）に対してパイプラインが壊れないよう設計する考え方。後方互換・前方互換の区別とともに、スキーマレジストリ（Apache Confluent等）の役割を理解しておくと試験でも実務でも有利です。
キーワード: スキーマレジストリ、後方互換（Backward Compatible）、Avro / Parquet
冪等性（Idempotency）の保証
同じデータを2回投入しても結果が変わらない設計。ネットワーク障害や再実行時の二重挿入を防ぐためにUPSERT（INSERT OR REPLACE）やチェックポイントを活用します。冪等性はデータパイプラインの信頼性設計の核心であり、試験でも設計原則として問われます。
キーワード: UPSERT、Exactly-once、At-least-once、チェックポイント
パイプライン監視とアラート
ジョブの失敗検知、データ遅延アラート、行数・件数の期待値チェック（Data Quality Check）を組み込む。AirflowのSLAミス通知やGreat Expectationsのようなデータ品質フレームワークが代表例です。監視設計はデータスチュワードの責務領域と重なります。
キーワード: Data Quality Check、SLA、Great Expectations、データ系譜（Data Lineage）
スケーラビリティとパーティショニング
データ量の増大に対して水平スケール（ノード追加）できる設計。Sparkの分散処理、BigQueryのパーティション分割テーブル、S3のプレフィックス設計などが典型例。パーティショニングキーの選択を誤るとホットスポット問題が生じます。
キーワード: 水平スケール、パーティション、シャーディング、ホットスポット
データマネジメント試験（仮称）・プロフェッショナルデジタルスキル試験（仮称）での頻出ポイント
IPAが2027年度開始予定のデータマネジメント試験（仮称）では、DMBOK2の「データ統合・相互運用性」領域が出題範囲の重要部分を占めます。プロフェッショナルデジタルスキル（データ・AI）試験（仮称）では、「データエンジニアリング」科目としてパイプライン設計の知識が問われる見込みです。
以下の概念は特に重点的に確認しておくことを推奨します。
- ETL / ELT の違いと使い分け:どちらのパターンがどのような状況に適しているか。DWHの演算能力が高い場合はELTが有利という判断基準を説明できること。
- データ変換の種類:クレンジング（欠損値処理・型変換・名寄せ）・エンリッチメント（外部データとのジョイン）・集約（グループ集計）の区別。
- 冪等性とExactly-once:同じデータを複数回処理しても副作用が発生しない設計の必要性と実現手段（UPSERT・チェックポイント）。
- スキーマ管理:データソース変更への対応策。スキーマレジストリによるバージョン管理と後方互換性の維持。
- バッチ vs ストリームの設計判断:レイテンシ要件に基づく選択基準。不正検知・センサー分析はストリーム、日次レポートはバッチという典型パターン。
- データ系譜（Data Lineage）:データがどのソースからどの変換を経て最終テーブルに至ったかを追跡する能力。監査・品質管理の基盤となる概念。
試験対策として、DMBOK2の第8章「データ統合・相互運用性」を参照することを推奨します。また、IPAが公表している出題範囲改定案では「データエンジニアリング」領域に「データパイプライン構築・管理」が明示されています。
データマネジメント試験の出題範囲を確認する
PassDojoでは、データマネジメント試験の出題範囲予測と学習ロードマップを公開しています。パイプライン設計を含む「データ統合・相互運用性」領域の学習に活用してください。
関連用語：データレイク・データウェアハウス・データメッシュ
データパイプラインを理解するためには、データの格納先となるアーキテクチャの概念も整理しておく必要があります。
データウェアハウス（DWH）
DWHは、分析・レポーティング向けに最適化された構造化データのストレージです。スタースキーマ・スノーフレークスキーマなどの次元モデルで設計されることが多く、BigQuery・Snowflake・Amazon Redshift・Azure Synapse Analyticsが代表例です。ETL/ELTの格納先として、データパイプラインの終点になります。
データレイク
データレイクは、生データ（構造化・半構造化・非構造化）をそのまま格納する低コストのストレージです。Amazon S3・Google Cloud Storage・Azure Data Lake Storageが代表例。スキーマを後から定義する「Schema-on-Read」アプローチを取り、機械学習の学習データや将来的な分析用途を想定して蓄積されます。
データレイクハウス
データレイクハウスはDWHとデータレイクの両方の特性を統合したアーキテクチャです。Delta Lake（Databricks）・Apache Iceberg・Apache Hudiが代表的な実装で、データレイクの低コストストレージ上にDWHのようなACIDトランザクション・スキーマ管理・タイムトラベル機能を追加しています。試験ではデータレイクハウスを「DWHとデータレイクの統合」と説明できることが重要です。
データメッシュ
データメッシュは、データの所有権を中央集権的なデータチームではなく、各ビジネスドメインに分散させるアーキテクチャ思想です。「ドメインオーナーシップ」「データをプロダクトとして扱う」「セルフサービス基盤」「フェデレーションされたガバナンス」の4原則で構成されます。試験よりも実務設計での重要度が高い概念ですが、データマネジメント試験（仮称）では「データガバナンスのアーキテクチャ」として登場する可能性があります。
よくある質問（FAQ）
ETLとELTはどちらが優れていますか？
どちらが優れているかは一概には言えず、ユースケースによって最適解が異なります。クラウドDWH（BigQuery・Snowflakeなど）を使う場合はELTが有利です。変換処理が複雑でDWHへの格納前に厳密な品質管理が必要な場合、またはDWHの演算コストを抑えたい場合はETLが適しています。
DataSpiderとAirflowの違いは何ですか？
DataSpider Servistaは主にデータ転送・連携に特化したETLミドルウェアで、GUIで設定できるコーディング不要のツールです。Airflowは主にパイプライン全体のスケジューリングと依存関係管理（ワークフローオーケストレーション）を担うツールで、Pythonで記述します。Airflow単体ではデータ転送処理は書かず、Spark・Glue・DBなどの実処理を呼び出す役割を果たします。
データパイプラインの監視で重要な指標は何ですか？
代表的な監視指標は、(1)ジョブ完了/失敗ステータス、(2)処理時間（SLA遵守率）、(3)処理件数の期待値との乖離（データ品質チェック）、(4)エラーレコード数・エラー率、(5)データ遅延（最新データの鮮度）の5つです。Great ExpectationsやMonteCarlo DataがData Observabilityツールとして活用されています。
個人がデータパイプラインを学ぶにはどうすれば良いですか？
入門段階ではAirflowをローカルにDockerで起動してDAGを作成する体験が効果的です。クラウドに触れる場合はGoogleのBigQuery SandboxとGoogle Cloud Composerの無料枠を活用できます。dbtは「dbt Cloud」の無料プランで実際のELT変換を体験できます。理論面ではDMBOK2の第8章「データ統合・相互運用性」の精読を推奨します。
関連記事——さらに深く学ぶ
- データマネジメント試験の試験範囲予測【DMBOK・IPA発表を読み解く】— パイプライン設計を含む出題範囲の全体像
- データマネジメントとは？企業のデータ活用を支える基盤をわかりやすく解説— DMBOK2の11領域とデータ統合の位置づけ
- データマネジメント試験の勉強法と学習ロードマップ【2027年合格戦略】— 学習優先度の高い領域の整理
- DSSv2.0「データマネジメント類型」新設を読み解く【データスチュワード／データエンジニア／データアーキテクト】— データエンジニアに求められるスキル定義
- プロフェッショナルデジタルスキル試験「データ・AI領域」出題範囲を完全解説— データエンジニアリング科目の出題範囲詳細
- Open Data Spaces（ODS）とは？IPAが公開した分散データマネジメント基盤の全体像— データパイプラインの先にある分散データ基盤の動向