データパイプラインとは？2026年版 仕組み・ETLとの違い・設計3軸を図解

BigQueryもBIツールも入れた。それなのに月曜の朝、ダッシュボードの数字は先週の金曜のまま止まっている。原因を辿ると、結局どこかのCSVを担当者が手で落とし忘れていた。こういうご相談が、データ活用の現場では驚くほど多いです。

道具は揃っているのに、データが流れてこない。見覚えがある方は多いのではないでしょうか。ツール選定より前に、そもそも「毎日データが自動で流れ続ける状態」が作れていないのが真因だったりします。

この「データの流れ」を自動化する仕組みが「データパイプライン」です。

正直に言うと、検討を始めた担当者がほぼ必ずつまずくのは、「ETLパイプラインと何が違うのか」という疑問だと思います。両者は対立ではなく包含関係にあります。ETLパイプラインは、データパイプラインという広い枠の中の一種類に過ぎません。

さらに2026年時点では、FivetranやtroccoなどのマネージドETL／ELTが接続の主流になり、AIコーディング補助がSQL変換や監視スクリプトの初稿を書く前提になってきました。同じ「パイプラインを組む」でも、2020年頃の常識をそのまま持ち込むと過剰投資になりがちです。

以下の順で、定義から2026年の設計判断までを一気に整理します。

• データパイプラインの定義と4つの構成ステージ
• ETLパイプラインとの違い（比較表つき）
• 設計3軸（処理タイミング／変換の場所／マネージド or 自作）で選ぶ主要パターン
• 支える4つの技術要素（オーケストレーション・監視・リトライ・冪等性）
• AI連携で変わる2026年の新常識
• Evastの現場で見た落とし穴3つと、導入の進め方

データパイプラインとは？データを自動で運び、使える形に整える仕組み

データパイプラインとは、データを発生源から利用先まで自動で運び、途中で使える形に加工する処理の連なりです。パイプライン（pipeline）は本来「配管」を意味する言葉で、水道管の中を水が流れるように、データが処理から処理へと自動で流れていく様子を表しています。

対になるイメージは「人手によるバケツリレー」です。担当者が管理画面からCSVをダウンロードし、Excelで整形し、共有フォルダに置く。この手作業の連鎖をソフトウェアによる自動の流れに置き換えたものが、データパイプラインだと考えてください。

データパイプラインを構成する4つのステージ

データパイプラインは、おおむね「収集・処理・蓄積・提供」の4つのステージで構成されます。次の図のように、データは左から右へ流れ、その全体を下段のオーケストレーション・監視が支える構造です。

• 収集：SaaS・業務データベース・アプリのログなどから、データを抽出して運び出す
• 処理：型変換・表記揺れの統一・集計など、分析に使える形への加工を行う
• 蓄積：DWH（データウェアハウス。分析用にデータを集約するデータベース）やデータレイク（生データを加工せず安価に貯めておく置き場）に格納する
• 提供：BIツールでの可視化、機械学習モデル、業務システムなど、利用先へデータを届ける

図の下段にあるオーケストレーション・監視は、4つのステージそのものではなく「ステージ全体を毎日正しく動かし続けるための土台」です。この土台こそがパイプライン運用の肝になるため、後半の章で詳しく扱います。

データ基盤全体の中でパイプラインが占める位置

データ基盤（データの収集・蓄積・分析を担う社内のインフラ全体）にあてはめると、パイプラインはデータソースとDWHをつなぐ動脈にあたります。

図のとおり、どれだけ高性能なDWHやBIツールを揃えても、パイプラインが止まればデータは1行も届きません。冒頭の「数字が3日前のまま」という症状は、たいていこの動脈のどこかが詰まっています。

データ基盤そのものの考え方や構成要素は、データ基盤とは？企業が導入すべき3つの理由と構成要素を解説で詳しく解説しています。

データパイプラインとETLパイプラインの違いは「概念の広さ」

両者の違いは、ひとことで言えば「指している範囲の広さ」です。データパイプラインが「データを自動で運び・加工する処理全般」を指す総称であるのに対し、ETLパイプラインはそのうち「Extract（抽出）→ Transform（変換）→ Load（格納）の順で処理するタイプ」を指します。

次の図のように、ETLパイプラインはデータパイプラインという大きな枠の中の1区画です。「どちらを使うべきか」という二者択一の関係ではありません。

観点ごとに整理すると、次のようになります。なお、これは対等な二者の比較ではなく、右の列（ETLパイプライン）は左の列（データパイプライン）に含まれる関係です。

誤解されやすいのは「変換処理」の行です。たとえば業務システムのログをAmazon S3へ毎晩そのままコピーするだけの仕組みは、変換を含まないためETLとは呼べませんが、立派なデータパイプラインです。

ETLの3工程それぞれの仕組みや代表的なツールは、ETLとは？データ統合の基礎と選定ポイントを解説で図解つきで詳しく扱っています。

なぜ混同されやすいのか：かつては「パイプライン ≒ ETL」だった

2000年代まで、分析目的のデータ連携といえば「夜間のETLバッチ」が中心で、パイプラインといえばETLを指す時代が長く続きました。混同が多いのはこの歴史の名残です。

状況を変えたのが、2010年代のクラウドDWHの普及です。変換をDWH内で行うELT（Extract → Load → Transformの順で処理する方式）が台頭し、IoTやWeb行動ログのリアルタイム処理も一般化しました。

ETLという言葉では捉えきれない多様な形が生まれた結果、それらを総称する言葉として「データパイプライン」が定着した、という経緯です。

データパイプラインの設計3軸：「処理タイミング」「変換の場所」「責任分担」で分類する

データパイプラインの分類軸はいくつも語られますが、2026年時点で実務の設計判断に直結するのは、処理タイミング・変換の場所・責任分担の3つに絞れます。順にバッチかストリーミングか、ETLかELTか、マネージド接続に任せるか自作コネクタを書くかという選択です。

3軸は独立しているので、「バッチ × ELT × マネージド」「ストリーミング × ETL × 自作」のように掛け合わせて設計します。

正直に言うと、Evastが最近立ち上げるデータ基盤の8割は「バッチ × ELT × マネージド接続」の組み合わせに落ち着きます。ストリーミングも自作コネクタも、要件が本当にそれを必要としているケースは思ったより少ないというのが実感です。順に見ていきましょう。

【分類軸1】処理タイミング：バッチ処理かストリーミング処理か

バッチ処理は、1日1回や1時間に1回など、決まった間隔でデータをまとめて処理する方式です。日次の売上レポートやKPI集計のように「翌朝までに昨日分が見えればよい」用途では今も主流で、仕組みがシンプルなぶん開発・運用コストを抑えられます。

一方のストリーミング処理は、データが発生するたびに数秒〜数分以内で処理し続ける方式です。ECサイトの不正検知や工場センサーの異常検知など、データの鮮度がそのまま価値になる用途で使われます。Apache KafkaやGoogle Cloud Pub/Sub、Amazon Kinesisといった基盤が代表的ですが、バッチに比べて設計・運用の難易度は一段上がります。

迷ったら、まずバッチから始めるのが定石です。Evastの現場でも「リアルタイムで見たい」という初期要望を要件まで掘り下げると、実際には1時間ごとのバッチで十分だった、というケースが大半を占めます。

【分類軸2】変換の場所：ETL型かELT型か

変換をDWHに入れる前にETLツール側で行うのがETL型、生データを先にDWHへ入れてからSQLで変換するのがELT型です。BigQueryやSnowflakeといったクラウドDWHを使う構成では、DWHの計算能力を活かせるELT型が主流になっています。

どちらを選ぶかは、データ量・セキュリティ要件・分析要件の変化頻度などで判断が分かれます。5つの比較軸と選び方の判断基準は、ETLとELTの違いとは？5つの比較軸とELTが主流になった理由にまとめています。ETL・ELTそのものの土台をまだ押さえていない場合は、先にETLとは？データ統合の基礎と選定ポイントを解説を読んでからのほうが理解が早いはずです。

【分類軸3】責任分担：マネージドETL/ELTか、自作コネクタか

3つ目の軸は「接続部分を誰が面倒を見るか」です。SaaSや業務システムからデータを引き抜くコネクタを、外部サービスに任せるのか、自社で書くのか。ここが2026年の設計判断でいちばん見落とされがちなポイントだと思います。

• マネージドETL/ELT型：Fivetran、trocco、Airbyte Cloud、Meltano Cloudなどのサービスに、SaaS/DBからのコネクタ・スキーマ差分検知・再送を任せる。従量課金で高い代わりに、コネクタの追加・保守がほぼゼロコストになる
• 自作コネクタ型：Airbyte OSS、Embulk、Pythonスクリプト等でコネクタを書き、自社で運用する。ライセンス費は抑えられるが、SaaS側のAPI変更に追従する保守工数が長期でのしかかる

Evastがバッチ × ELT × マネージド接続を第一候補にする理由も、この軸にあります。DWH内部のSQL変換は自社の業務ロジックそのものなので内製すべき一方、SaaSとの接続部分は「壊れて直す」の繰り返しなので、月額を払って外に出したほうが総コストが安くなることが多いです。

一方で、大量のログや自社基幹の特殊フォーマットなど、マネージドサービスが対応していないソースだけは自作にする。マネージドを基本、例外だけ自作という切り分けが、2026年の落としどころだと感じます。

補足：リバースETLなど用途に特化した派生パターンもある

3軸の組み合わせの上に乗る応用形として、覚えておきたい派生が2つあります。

• ML向け特徴量パイプライン：機械学習モデルに入力する変数（特徴量）を生データから作り出す前処理の流れ
• リバースETL：DWHに集めた分析結果を、Salesforceなどの業務システム側へ書き戻す逆方向の流れ

いずれも「データを自動で運び・加工する」という本質は同じで、データパイプラインの一種です。

データパイプラインを支える4つの技術要素：オーケストレーション・監視・リトライ・冪等性

パイプラインは「作って終わり」ではなく「毎日動かし続ける」ものです。Evastのプロジェクトでも、工数の感覚としては初期構築が3割、安定運用の仕組みづくりが7割という配分になることが珍しくありません。

動かし続けるために押さえるべき技術要素は、次の4つです。

【技術要素1】オーケストレーション：Airflowなどで実行順序と依存関係を一元管理する

オーケストレーション（複数の処理を正しい順序・タイミングで実行するよう指揮する仕組み）は、パイプライン運用の中枢です。「売上データの取り込みが終わってから集計を始める」といった依存関係をDAG（有向非巡回グラフ。処理同士の順序関係を表す図）として定義すると、ツールが実行順序を自動で制御してくれます。

代表的なツールは、2015年にAirbnb社がオープンソース化した Apache Airflow です。事実上の標準として広く使われており、Google CloudのCloud Composer、AWSのAmazon MWAAなど、Airflowをマネージドサービス（運用をクラウド側に任せられる提供形態）として使える選択肢も揃っています。

後発のオープンソースであるDagsterやPrefectは、開発のしやすさやテスト機能を強みに採用が増えています。設計思想の違いと選び方はAirflow・Dagster・Prefect比較：データパイプラインのオーケストレーションツール選び方で詳しく整理しています。

OS標準のスケジューラであるcron（決まった時刻にコマンドを実行する仕組み）との違いは、「依存関係を知っているかどうか」です。cronは時刻しか管理できないため、前段の処理が失敗していても後段が平然と動いてしまいます。

【技術要素2】データパイプラインの監視：「止まったこと」「データが古いこと」に即座に気づく

データパイプラインの監視の基本は、次の3点セットです。

• 失敗の通知：ジョブが失敗したら、Slackやメールに即時に知らせる
• 処理時間の監視：普段20分の処理が2時間かかっていれば異常とみなす
• データ鮮度のチェック：最終更新が24時間以上前なら警告を出す

とくに見落とされがちなのがデータ鮮度です。パイプラインが止まってもダッシュボード自体は古いデータで表示され続けるため、「画面は出ているのに中身が止まっている」状態に気づけません。

ジョブの成否だけでなく、データそのものの状態を検査する仕組みを入れておくと安心です。dbt（SQLでデータ変換を開発・管理するツール）のテストやsource freshness（鮮度チェック）機能が代表的で、詳しくはdbtとは？BigQueryのデータ変換を効率化するツールを解説で扱っています。

近年は、こうしたパイプラインの死活監視に加えて、データの中身の異常（件数の急減、値の分布のズレ、欠損の急増など）まで自動で検知する「データ可観測性（データオブザーバビリティ）」という考え方も広がっています。まずは失敗通知とデータ鮮度監視から始め、対象データが増えてきた段階で中身の監視まで広げていくと、無理なく運用に組み込めます。監視する5つの観点、ツールの費用感、始め方の手順はデータオブザーバビリティとは？データ品質監視の5つの柱と始め方にまとめました。

【技術要素3】エラー処理とリトライ：一時的な失敗は自動で再実行する

リトライ（失敗した処理の自動再実行）は、運用負荷を下げる基本装備です。連携先APIのタイムアウトやネットワークの瞬断といった一時的なエラーは、「5分間隔で最大3回」のように間隔をあけて再実行するだけで成功することが多いためです。

Airflowなどのオーケストレーションツールでは、タスク単位でリトライ回数と間隔を設定できます。一方、連携元のレイアウト変更のような恒久的なエラーはリトライでは直らないため、規定回数で打ち切って人に通知する設計が必要です。

【技術要素4】冪等性：同じ処理を2回実行しても結果が変わらないように作る

冪等性（べきとうせい。同じ処理を何度実行しても結果が同じになる性質）は、リトライや手動再実行を安全にするための前提条件です。

たとえば追記（INSERT）だけで作られたパイプラインを再実行すると、同じデータが二重に取り込まれます。対象日のデータをいったん削除してから入れ直す「洗い替え」や、キーが一致すれば更新・なければ挿入するMERGE（Upsert）処理を使えば、何度実行しても結果は同じに保てます。

リトライ（技術要素3）を安心して使えるのは、冪等性が確保されているからこそです。4つの要素は独立した部品ではなく、互いに支え合う関係にあります。

AI連携で変わるデータパイプラインの新常識：SQL初稿・監視・障害対応まで

ここ1〜2年で、データパイプラインの作り方はAIコーディング補助と生成AIの前提を織り込んだものに変わってきました。「AIに任せる部分」と「人が最後に見張る部分」を最初から分けて設計するのが、2026年の現場の共通認識だと思います。実務で効いてくるのは、次の3つの変化です。

変化1：dbtモデル・変換SQLの初稿はAIに書かせる

もっとも普及しているのは、Claude CodeやGitHub Copilot、CursorといったAIコーディング補助にdbtモデル・変換SQL・テストコードの初稿を書かせる進め方です。カラム定義とサンプルデータ、狙う集計軸を渡せば、SELECT句とJOIN条件、{{ ref() }} を含んだdbtモデルまで一気に書いてくれます。

人の仕事は、業務ロジックが正しいかのレビューと、テスト（unique / not_null / relationships）の追加に集中させる。「一次原稿ゼロベース」の負担が消えたぶん、設計と検証にかける時間が実質2倍になった感覚があります。

変化2：異常検知・データ可観測性がAIで手が届く価格帯になった

以前は、データの中身の異常（件数急減、値の分布のズレ、欠損の急増など）を検知する「データ可観測性」ツールは、Monte CarloやAnomaloなど月額が高い専用サービスが中心でした。2025年以降は、dbtにMLベースの異常検知が組み込まれたり、BigQuery上で軽量なMLモデルを回して閾値を自動決定したり、生成AIに集計結果の要約と異常アラートを書かせるといった手作りの中間解が現実的な選択肢になっています。

まず失敗通知とデータ鮮度監視から入り、対象データが増えてきたら、AI/MLを使った中身の監視に段階的に広げる。この順番は数年前から変わっていませんが、中身の監視のハードルが確実に下がったのが2026年時点の変化です。

変化3：障害調査でAIエージェントに一次切り分けを任せる

Airflow・Dagster・Prefectの失敗ログをそのままAIに投げて、「どこで詰まったか」「一時的か恒久的か」「安全に再実行できそうか」の一次切り分けをさせる運用が増えてきました。エージェントに実行環境まで渡している現場では、ログ確認から再実行スクリプトのドラフトまでを人の手前で仕上げてくるところまで来ています。

ただし、正直に言うと冪等性が確保できていないパイプラインに再実行の判断まで任せるのは危険です。この変化を安全に取り込むためにも、前章の「監視・リトライ・冪等性」の3点セットが土台として効いてきます。

AI連携の話は「新しい設計軸」というより、既存の技術要素の上にAIをどう安全に乗せるかという運用改善に近い、というのが実務での感覚です。基盤自体をゼロから設計するときの土台は、データ基盤とは？企業が導入すべき3つの理由と構成要素を解説やETLとは？データ統合の基礎と選定ポイントを解説で押さえておいてください。

データパイプライン設計・運用の注意点：Evastの現場で見た3つの失敗

技術要素を押さえていても、設計と運用ルールを誤ると現場は混乱します。私たちが基盤の立て直し支援で実際に遭遇した失敗を、3つ紹介します。

【設計・運用の失敗1】cronとシェルスクリプトの乱立で、誰も全体像を把握できなくなる

ある企業では、5年かけて少しずつ増えたcronジョブ（シェルスクリプトの定時起動）が30本を超え、実行順序が「Aは深夜2時、Bは3時開始だから間に合うはず」という暗黙の時刻調整だけで保たれていました。データ量の増加でAの処理が3時を超えるようになった途端、後続が連鎖的に欠損し、原因特定に数日を要しました。

ジョブ間の依存関係が誰の頭の中にもない状態は、担当者の異動・退職で一気にブラックボックス化します。ジョブが10本を超えたあたりで、オーケストレーションツールへの移行と依存関係のコード化を検討してください。

【設計・運用の失敗2】パイプラインの失敗に1週間誰も気づかない「サイレント障害」

通知を仕込んでいない、あるいは通知が多すぎて誰も見なくなっている。どちらのパターンでも、結果は「気づかれない障害」です。前述のとおりダッシュボードは古いデータのまま表示され続けるため、経営会議の場で「この数字、先週から動いていなくないか」と指摘されて初めて発覚した例もあります。

対策はシンプルで、失敗通知とデータ鮮度監視を最初から組み込み、通知は「人が必ず見るチャンネル1つ」に絞ることです。通知の乱発はオオカミ少年化を招くため、警告レベルの整理も合わせて行いましょう。

【設計・運用の失敗3】障害復旧の再実行で、売上データが二重計上される

障害からの復旧時にバッチを手動で再実行したところ、その日の売上データが二重に取り込まれ、翌月のレポートの数字が合わないことで発覚した。冪等性を後回しにした典型的な失敗です。信頼を一度失ったダッシュボードは、数字が直った後もなかなか使ってもらえません。

「このパイプラインは再実行しても安全か？」を設計レビューの必須観点に加え、洗い替えやMERGEを標準パターンとして整備しておくことが予防策になります。

データパイプラインの導入の進め方と、コストを抑えるコツ

「自社にもデータパイプラインを導入したい」と考えたとき、最初から全社・全データを対象にすると、要件が膨らんで頓挫しがちです。おすすめは、価値の見えやすい1つの業務に絞って小さく始める進め方です。

たとえば、次のような単位でスモールスタートを切ると効果が見えやすくなります。

• 製造業：各設備の稼働ログを1本のパイプラインで日次集約し、稼働率ダッシュボードにつなぐ
• 通信・Web系：アクセスログやアプリのイベントログを収集し、翌朝までに前日分を見られるようにする
• 小売・多店舗：店舗ごとに散らばるPOSデータを本部のDWHへ自動連携し、全店の売上を一元把握する

まず1つの流れを作り、監視まで含めて安定して回ることを確認してから、対象データを段階的に広げる。この順番が、定着とコストの両面で失敗を防ぎます。検証を本番につなぐ具体的な手順はデータ基盤のPoCの進め方｜5ステップと成功基準・費用の目安で解説しています。

導入を自社で行うか外部に任せるかは、データエンジニアを確保できるかで判断が分かれます。判断軸はデータ基盤は内製と外注どっち？判断基準とハイブリッドの進め方で整理しました。

コスト面では、クラウドDWHの従量課金やETL・データ連携ツールのサブスク料金が、データ量の増加とともに膨らみます。無計画な全件スキャンを避ける設計と、要素ごとの見直しが効きます。毎月のランニングコストを抑える具体策はデータ基盤のランニングコスト削減｜4要素別の見直し方で詳しく扱っています。

まとめ：2026年の設計3軸と運用の土台を押さえてから、AI連携を乗せる

データパイプラインの定義からETLパイプラインとの違い、2026年の設計3軸と運用の要点までを整理しました。要点は次の6つです。

1. データパイプラインとは：データを発生源から利用先まで自動で運び・加工する処理の連なり
2. ETLとの違い：対立ではなく包含関係。ETLパイプラインはデータパイプラインの代表的な一種
3. 構成：収集 → 処理 → 蓄積 → 提供の4ステージと、それを支えるオーケストレーション・監視
4. 設計3軸：処理タイミング（バッチ／ストリーミング）・変換の場所（ETL／ELT）・責任分担（マネージド／自作）の3軸で判断する
5. 運用：監視・リトライ・冪等性は後付けではなく、設計段階から組み込む
6. AI連携：SQL初稿・異常検知・障害調査はAIに任せるが、冪等性の土台があってこそ安全に乗せられる

パイプラインは作った瞬間がゴールではなく、毎日動き続けて初めて価値を生みます。ツール選定の前に「止まったとき誰がどう気づき、どう復旧するか」まで描けているかを、ぜひ一度確認してみてください。

データパイプラインの設計・構築のご相談はEvastへ

株式会社Evastでは、データパイプラインの設計からオーケストレーション整備、DWH構築、BIダッシュボード開発まで、一貫したデータ基盤構築を支援しています。

• 「手作業のデータ集計を自動化したいが、何から始めるべきかわからない」
• 「cronジョブが乱立し、データ連携がブラックボックス化している」
• 「Airflowやdbtを使ったモダンなパイプラインに刷新したい」

このようなお悩みがあれば、お気軽にご相談ください。「止まったとき誰がどう気づき、どう復旧するか」まで見据えて、現状診断からアーキテクチャ設計、運用体制づくりまでを伴走します。

→ データ基盤構築サービスを見る → 無料相談を申し込む