自前ELはいつ選ぶか：dlt・Meltano・Pythonスクリプトの判断軸

FivetranとAirbyteで900以上のコネクタが揃ういま、新規プロジェクトでもまだ「自前でELを書く」場面は残ります。社内の独自APIで標準コネクタがない、特殊な認証フロー、外部公開していない基幹システム、画面スクレイピングが必要なレガシー業務システム。マネージドツールが手を出しにくい領域は、案外多いものです。

「自前ELは古い」と片付けるのは早計です。近年はdltやMeltanoのような、自前ELを書きやすくするOSSフレームワークが登場し、設計が大きく変わりました。自前ELが必要になる場面、回避すべきアンチパターン、近年のフレームワーク活用を整理します。

自前ELを選ぶべき場面

「マネージドの取り込みツールを選んだうえで、それで対応できない一部だけを自前」というのが、現実的なバランスです。

自前ELを避けるべきサイン

• FivetranかAirbyteに公式コネクタがある（同じものを自分で作るのは無駄）
• 運用人員が1〜2名しかいない（保守の責任を持ちきれない）
• SaaSのスキーマ変更を追従する余力がない
• 「とりあえず動けばいい」スクリプトを本番で動かそうとしている

自前ELは「動かす」のは簡単ですが、「動かし続ける」のが難しい領域です。スキーマ変更・APIエラー・リトライ・差分管理・モニタリングなど、運用要素が無限に出てくる。安易な自前化は、半年後に保守不能になる。

2026年の選択肢：dlt と Meltano

自前ELの土台を作ってくれるOSSフレームワークが普及しています。代表が dlt と Meltano です。

dltの最小例

import dlt
import requests

@dlt.resource(write_disposition="merge", primary_key="id")
def my_api_data():
    response = requests.get("https://api.example.com/v1/items")
    yield response.json()["items"]

pipeline = dlt.pipeline(
    pipeline_name="my_api",
    destination="snowflake",
    dataset_name="raw",
)
load_info = pipeline.run(my_api_data())
print(load_info)

dltは「Pythonの関数にdltデコレータを付けるだけで、スキーマ追従・差分書き込み・型推論まで自動でやる」というアプローチだ。`write_disposition=”merge”`を指定すれば、primary_keyに基づく差分書き込みが自動で構成される。スキーマも自動で推論され、DWH側のテーブルが作られる。

運用設計の勘どころ

• 差分取り込みの設計：updated_at、IDの最大値、Webhook、いずれの方式で差分を取るかを設計初期に決める。後から変更すると痛い。
• 失敗時のリトライ：APIエラーは必ず起きる。最低限、指数バックオフのリトライを入れる。
• スキーマ変更検知：dltなら自動追従、自前Pythonならスキーマ変更時にアラートを出す仕組みを作る。
• シークレット管理：APIトークンを環境変数やKMSで管理し、コードに埋め込まない。
• モニタリング：「昨日のデータが届いていない」を検知するfreshnessチェックを必ず入れる（データ品質ツール参照）。

オーケストレーターとの連携

自前ELは、AirflowやDagster、PrefectといったオーケストレーターのTaskとして動かすのが定石です。自前のPythonスクリプトは、オーケストレーターの@taskや@assetとして登録します。

# Dagsterのassetとして自前ELを動かす例
from dagster import asset
import dlt

@asset
def raw_my_api():
    pipeline = dlt.pipeline(
        pipeline_name="my_api",
        destination="snowflake",
        dataset_name="raw",
    )
    return pipeline.run(my_api_data())

オーケストレーターに統合することで、リトライ・スケジュール・通知・ログ集約が一元化されます。オーケストレーター選定はオーケストレーター選び方ガイドを参照してください。

よくあるアンチパターン

• cronで動かして放置：失敗が誰にも気づかれず、3ヶ月後に「全部欠損していた」と発覚する。
• 全件再取得で済ます：データ量が小さいうちは動くが、増えると一気に時間が爆発する。差分取り込みは早めに作る。
• テスト無しの本番投入：APIの仕様変更や認証切れに気づかず、深夜に全停止する。最低限のヘルスチェックを入れる。
• 属人化したスクリプト：書いた人しか分からないPython。dlt/Meltanoのような標準フレームワークに乗せる。

まとめ

• 自前ELが必要な場面は「独自API・特殊認証・大量データ・レガシー連携」に絞られる。
• 公式コネクタがあるものを自前で作るのは、ほぼ常に悪手。
• 2026年の標準はdltやMeltano。ゼロからPythonで書くより、フレームワークに乗る。
• 差分取り込み・リトライ・スキーマ追従・シークレット管理・モニタリングは設計初期から組み込む。
• オーケストレーターに統合して、運用機能を共通化する。

全体像はEL vs ETLとデータ取り込みツール選定、隣接の選択肢はFivetran とは・Airbyte とはにあります。自前ELの設計や、マネージドとの組み合わせ判断は、DE-STKの初回相談（30分・無料）もご利用ください。

よくある質問（FAQ）

Q. dltとAirbyte CDKは、どちらでカスタムコネクタを作るべき？

A. 用途次第です。Airbyte本体で既に他のソースを動かしているなら、CDKでAirbyteのコネクタとして作るのが運用一元化になり有利です。Airbyteを使っていない、もしくは独自のオーケストレーターから直接呼びたい場面では、dltの方が軽量で取り回しが良いです。「既存のEL基盤に統合するか、独立した取り込みとして書くか」を起点に選びます。

Q. Pythonスクリプトを本番運用するときの最低要件は？

A. 5つあります。差分取り込みのロジック、リトライ機構、失敗時の通知、シークレットの安全な管理、データ鮮度のモニタリング。これらが揃わないPythonスクリプトは、本番投入してはいけません。dltやMeltanoを使うと、これらの大半が標準で組み込まれるので、最低要件をクリアしやすくなります。

Q. 自前ELの保守工数は、どのくらいかかりますか？

A. 接続あたり、初年度は0.1〜0.2人月／年が目安です。APIの破壊的変更、スキーマ変更、認証方式変更などへの対応で、年に2〜4回は手を入れる必要があります。接続数が10を超えてくると、専任者1名分の工数になります。「公式コネクタなら任せられる」の価値が見えてくるのは、この保守工数の積み重ねを直視したときです。

Q. CDC（Change Data Capture）が必要な場合、自前で作れますか？

A. 作れますが、難易度が高いです。データベースのトランザクションログ（MySQLのbinlog、PostgreSQLのWAL等）を読む実装になり、専門性が要ります。Debezium・FivetranのHVRなど、CDCに特化したツールが既にあるので、自前で作る前にこれらを評価するのが現実的です。リアルタイム性の要件次第ですが、自前CDCを選ぶ場面は限定的です。