「Embulkで5年以上動いているデータ転送基盤を、そろそろ見直したい」。そんな相談を月に何件かいただきます。
Embulkはオンプレでのデータ転送で長年使われてきたOSSで、いま動いている基盤の多くは大きな障害もなく回っているのが実情です。ただ、v0.11以降の破壊的変更、Rubyプラグイン非推奨の方針、社内で保守できるメンバーの減少といった変化が重なり、「このまま使い続けていいのか」を判断せざるを得ない状況が増えています。
そこで本記事では、Embulkから移行すべきかの判断軸と、移行する場合の代替ツール5つの使い分けを、稟議とベンダー選定にそのまま使える形で整理しました。データパイプラインそのものの基礎はデータパイプラインとは？ETLとの違いと設計3軸【2026年版】で扱っているので、こちらはEmbulk固有の判断と、移行判断の落とし穴に軸足を置いています。
Embulkは2015年にTreasure Dataから公開されて以降、10年以上使われてきたバッチ型のデータ転送OSSです。YAMLで転送設定を書き、Input/Output/Filter のプラグインを組み合わせて多様なDB・ファイル・SaaS間のデータ転送を実装できる、というシンプルな設計が受け入れられてきました。
一方で、2023年6月のv0.11.0リリース以降、開発方針に大きな転換が入っています。要点は3つあります。
1つ目：JRubyが内蔵から外れた。v0.9系まではEmbulkの実行環境にJRubyが同梱されており、Rubyで書かれたプラグイン（embulk-input-mysql など初期世代の主要プラグイン）がそのまま動作していました。v0.11ではJRubyが同梱されなくなり、Rubyプラグインを使うには自分でJRubyを導入する構成に変わっています。
2つ目：Ruby プラグインが v1.0 以降で非推奨になる。公式のロードマップでは、v1.0でRubyプラグインは第一級のサポート対象から外れる方針が示されています。既存のRubyプラグインの多くは Java プラグインに置き換わっていますが、コミュニティ製の古いプラグインで、Java版が用意されていないものは動作しなくなる可能性があります。
3つ目：コミュニティ活動の重心が変わっている。Embulkコミュニティは今も残っており、2026年9月にはユーザーミートアップも予定されています。ただし、周辺のOSSプラグイン（コネクタ）の新規追加ペースは、FivetranやAirbyteなど商用・準商用の競合と比べて緩やかで、新しいSaaS対応が公式にすぐ追いつく状況ではありません。
これらは「Embulkが止まる」という話ではなく、「使い続けるなら前提が変わっている」という話です。判断の材料としては、いま動いているパイプラインで使っているプラグインがv0.11・v1.0でも動くか、社内でEmbulkを触れるメンバーが残っているか、この2点をまず確認するのが出発点になります。
Embulkからの移行は「新しいツールに乗り換える」だけの話ではなく、「いま動いている転送基盤の総保守コストを、この先3〜5年でどれだけ払うか」を決める判断です。判断材料になる4つの問いを並べます。
問い1：使っているプラグインは v0.11・v1.0 でも動くか。ここが動くなら、慌てて移行する必要はありません。逆に、社内独自の古いRubyプラグインや、メンテナンスが止まっているコミュニティプラグインに依存している場合は、そのままでは近い将来動かなくなるので、移行を前提に計画するほうが安全です。
問い2：Embulkを触れるメンバーは何人残っているか。プラグインが動いても、yamlを直せる人・障害時にログを追える人が社内に1〜2人しかいない状態では、その担当者の異動・退職が単一障害点になります。ここが弱いなら、GUIで運用できるSaaS型ツールへの移行が、属人化解消の観点で費用対効果が高くなります。
問い3：転送先・転送元にモダンなSaaSが増えているか。Salesforce、HubSpot、Google Ads、Meta Adsなど、業務側で使うSaaSが増えている企業では、Embulkのプラグインでは追随しきれない場面が出てきます。FivetranやAirbyteのようにSaaSコネクタが日々追加されるツールに寄せると、追加開発が要件定義とテストだけで終わるようになります。
問い4：転送量は今後増えるか減るか。転送量が横ばい〜減少なら、既存Embulkを延命する判断も現実的です。転送量が数倍に伸びる見込みがあるなら、スケーラビリティと運用負荷の両面で、マネージド型SaaSに寄せるほうが総額で有利になります。
この4つを社内で先に整理してから、次のツール選定に進むと、比較軸がぶれずに済みます。「Embulkがオワコンだから移行」というだけでツール選定を始めると、代替ツールのコストや制約が見えていない状態で決まってしまい、移行後に「思ったより高い」「思ったより自由度が低い」という失望が起きやすくなります。
Embulkから移行する場合の代替は、大きく「国産SaaS」「海外SaaS」「OSSセルフホスト」「自作」の4系統に分かれます。代表的な5つを、Embulkからの移行のしやすさと合わせて整理します。
| ツール | 種別 | 月額費用の目安 | Embulk資産の活用 | 向いているケース |
|---|---|---|---|---|
| TROCCO | 国産SaaS | 10万〜50万円 | ◎（内部でEmbulk利用） | 既存yaml/ノウハウを活かして移行したい国内企業 |
| Reckoner | 国産SaaS | 3万〜30万円 | × | 中小規模で国内SaaS中心の連携 |
| Fivetran | 海外SaaS | 5万〜100万円超（MAR課金） | × | SaaS連携が多く、コネクタ数最優先 |
| Airbyte OSS | OSSセルフホスト | 0円＋インフラ費／運用工数 | △ | 技術者を専任で置ける組織、コスト最重視 |
| 自作（Airflow + Python等） | 自作 | 0円＋開発・保守工数 | △ | 特殊な業務ロジックが多く既製ツールでは足りない |
TROCCOは、株式会社primeNumberが提供する国産のデータ統合SaaSで、内部エンジンにEmbulkを採用しています。既存Embulkのyaml設計の考え方や、Input/Output/Filterプラグインの発想がほぼそのまま活きるため、他ツールへの完全書き換えより移行コストを抑えやすい傾向があります。2026年3月にはDWANGO（旧KADOKAWA Connected事業）から、オンプレEmbulkからTROCCOへ移行した実務事例も公開されています。国内サポートと日本語UIが必要な組織で第一候補になりやすい選択肢です。料金の詳細はTROCCOの料金と代替ツールを中立比較にまとめています。
Reckonerは、株式会社スリーシェイクの国産SaaSです。GUIで転送設定を組む点はTROCCOと同じですが、料金レンジがより低く、月3万円台から始められるため、転送ジョブが少ない中小規模の環境で選ばれます。SaaSコネクタの豊富さと、大量ジョブでの安定性ではTROCCO・Fivetranに一歩譲る場面があるので、要件に応じて使い分けが必要です。
Fivetranは、海外発のデータ統合SaaSで、コネクタ数（700超）と自動スキーマ追従の強さで知られています。料金はMonthly Active Rows（MAR）課金で、転送量が読みにくい環境では月額が数倍にぶれることがあります。SaaSコネクタが多く必要な環境（広告・営業系のSaaSを大量に扱う組織など）では第一候補ですが、コスト管理の設計を最初にきちんと入れる必要があります。
Airbyte OSSは、モダンなOSSデータ統合ツールで、セルフホスト版は無料で使えます。Docker/Kubernetesで自前で立てて運用する形で、コネクタ数はFivetranに次いで多く、コスト最重視の技術者組織で選ばれます。ただし、監視・バックアップ・バージョン更新をすべて自前で担うため、「Embulkの運用が重いから移行する」動機で選ぶと、運用負荷が下がらないことがあります。マネージド版のAirbyte Cloudもありますが、料金体系はクレジット課金でFivetranに近い水準です。
自作（AirflowやDagster + Python）は、業務ロジックが特殊で既製ツールでは足りない場合の選択肢です。転送処理を自前で書ける自由度と引き換えに、コネクタも監視もすべて自作になり、初期の実装工数と継続的な保守工数が最大になります。転送ジョブが数百本規模で、独自の業務ルールが多い環境で選ばれます。
ツールの詳しい比較軸はデータ連携ツールの選び方：コスト・サポート・コネクタ数で比較、料金の内訳と目安はデータ連携ツールの費用相場と見積もりの内訳【2026年版】にまとめています。
前節の表で「Embulk資産の活用」を◎とした唯一のツールがTROCCOです。ここは移行判断で重視される観点なので、もう少し具体的に整理します。
TROCCOが既存Embulk運用と親和性が高い理由は3つあります。1つ目は、転送処理のエンジンにEmbulkそのものが使われていること。2つ目は、転送設定の粒度（Input・Output・Filter・Column mapping）が同じ発想で組まれていること。3つ目は、TROCCOの提供元であるprimeNumberが、Embulkの初期からのメジャーコントリビュータであり、Embulk特有の挙動やハマりどころに詳しいこと。
ただし、既存のyamlファイルをTROCCOへそのままインポートするような機能はなく、GUIで転送設定を作り直す作業自体は必要です。「yaml資産がそのままエクスポートできる」ではなく、「yamlの設計思想を持ったまま、GUI上で組み直せる」という理解が正確です。
一方で、TROCCOはprimeNumberの主力製品なので、Embulk自身の将来性（v0.11、v1.0）について、当事者としては中立的な立場を取りにくい構造にあります。Embulkの現状評価やロードマップ判断を仰ぐ場合は、TROCCOと利害関係のない第三者（弊社を含む中立のコンサルティング事業者）にセカンドオピニオンを求めるほうが、意思決定の精度が上がります。
Embulkからの移行プロジェクトで、実際の現場で工数が読み違えられる落とし穴を並べます。
1つ目：既存ジョブ本数を過少に見積もる。「メインの転送は10本くらい」と聞いていても、cronで動いている補助ジョブ、月次で回るバックアップ、テスト環境のジョブなどを含めると、実は40〜50本あるケースが多くあります。棚卸しは、cron、ジョブスケジューラ、Digdag、シェルスクリプトの4か所を必ず確認してください。
2つ目：カスタムFilterプラグインの移植を後回しにする。長く運用されているEmbulk環境では、社内で書かれたカスタムFilterプラグイン（列名変換、値のクレンジング、独自の集計など）が動いていることがあります。TROCCOやFivetranに移行する場合、これらのロジックはdbtや前段のSQLに書き直す必要があり、テーブル1本あたり数日〜1週間の工数がかかります。
3つ目：既存のyaml管理をそのまま持ち込もうとする。Embulkのyamlは1ファイル1転送で、Gitで管理してレビューする文化と相性が良いですが、SaaS型ツールに移るとこの運用は変わります。誰がGUIから設定を変更したか、承認フローをどう組むかを、移行と同時に決めておかないと、移行後に「誰が何を変えたか分からない」状態に戻ります。
4つ目：転送量ベースの料金試算を実測なしでやる。FivetranのMAR課金やAirbyte Cloudのクレジット課金は、実際の転送量が想定と乖離することが多い料金体系です。見積もり段階では過去3ヶ月のEmbulkログから実測データ量を出し、その数字で試算するほうが安全です。カタログの想定値だけで稟議を通すと、初月から予算オーバーになるケースがあります。
5つ目：並行運用を短くしすぎる。Embulkと新ツールの並行運用は、少なくとも1ヶ月、理想は2〜3ヶ月確保します。転送結果の行数・値の一致を業務側と一緒に検証しないまま切り替えると、「数字が微妙に違う」という指摘が出て信頼を失います。
工数の目安は、転送ジョブ数と移行先で大きく変わります。ジョブ10〜30本・移行先がTROCCOなら3〜4ヶ月・300万〜700万円、同規模でAirbyte OSS/自作なら5〜8ヶ月・800万〜1,500万円が現場感覚です。既存のカスタムプラグイン数、業務ロジックの複雑さで上下します。
移行プロジェクト特有ではない、データ基盤全般でよくある失敗はデータ基盤構築でよくある失敗と発注前チェックリストにまとめています。運用側の体制設計はデータ基盤の運用・保守｜体制と工数、コスト削減の実務を参考にしてください。
Embulk移行は既存資産のリバースエンジニアリングを含むため、全てを外注に投げると費用が跳ね、全てを内製で回すと社内リソースが枯渇します。実務的な分担の目安を並べます。
この分担のポイントは、PoCの段階で社内担当者が新ツールを触れる状態に上げておくことです。ここが抜けると、外注が終わった後に「GUIは触れるがトラブル時に何もできない」状態になり、追加費用が青天井になります。内製と外注の詳しい判断基準はデータ基盤は内製と外注どっち？判断基準とハイブリッドの進め方にまとめています。
Embulk移行は、いきなり全ジョブを一気に切り替えるより、代表的な1〜2本のパイプラインで移行先ツールを実際に動かし、料金・運用感・既存ロジックの再現性を確かめてから全体計画を組むほうが、総額と定着率の両面で安全になります。300万〜1,000万円の初期投資レンジで、以降は月10万〜50万円で運用できる規模なので、稟議のハードルも投資対効果で説明可能な水準です。
Evastでは、既存Embulk環境の棚卸しから、移行先ツールの中立的な選定、PoC・本格移行・並行運用までを一気通貫で支援しています。TROCCOとの利害関係を持たない立場から、Embulk継続・TROCCO移行・他SaaS移行・自作の4パターンを費用と運用負荷で比較し、御社の環境に合った現実的な選択肢をお出しできます。既存のジョブ本数と対象データソースを伺えれば、初期プロジェクト費と月額のオーダー感、3〜6ヶ月の工程の初稿までは無料でお出しします。
データ基盤データパイプラインはデータを自動で運び使える形に整える仕組み。ETLとの違い、主要ツール4層（Fivetran・trocco・dbt・BigQuery等）の比較、月額相場と最小構成、監視3階層とコスト削減の順序を、Evast現場の失敗3つと図解で整理。
データ基盤freee会計・マネーフォワード クラウド会計のデータをBigQueryに載せる方法を、trocco・Fivetran・Airbyte・Cloud Run内製・特化型SaaSの5パターンで費用比較。月額0円〜月30万円まで、freeeプラン別のAPI制限差、非同期ジョブや締め後修正の実装落とし穴、Shopifyや広告費との突合ユースケースを稟議に使える形で整理した2026年版です。
データ基盤Shopifyの注文・顧客・在庫データをBigQueryで分析する方法を、Fivetran・trocco・Airbyte・Cloud Run内製・Stitch/Hevoの5パターンで費用比較。月0円〜月20万円まで、月商1,000万〜10億円規模のD2Cケースを想定した費用相場と、GraphQL calculated cost・Bulk Operations API・多店舗・多通貨・返品遅延・メタフィールドの実装落とし穴を整理した2026年版です。
