Salesforceデータをどう運ぶ？ AirbyteとAppFlowを比較検証して AppFlow + dbt に着地した話
こんにちは。業務変革室でデータエンジニアをしている千葉です。こちらはエクサウィザーズ Advent Calendar 2025 5日目の記事です。
現在、私たちのチームでは、社内データの民主化と活用を加速させるための「分析基盤」の構築を進めています。
その出発点となるのが、Salesforce などの SaaS 上に存在するデータを DWH へ集約するためのデータ連携（ELT）パイプラインの構築です。
今回は、Airbyte, Dify, n8n, Amazon AppFlow の4つのサービスを比較・検証し、最終的に Amazon AppFlow + dbt という構成に着地した経緯をご紹介します。
今回の検証における「要件」
今回のミッションは、以下の通りです。
「Salesforce等の業務データを、セキュアかつ低コストで分析基盤へ連携すること」
これを実現するために、以下の4つのプロダクトをリストアップしました。
- Airbyte (OSS版/Self-Hosted): ELTツールのデファクトスタンダード
- Dify: LLMアプリ開発プラットフォーム
- n8n: ワークフロー自動化ツール
- Amazon AppFlow: AWSフルマネージドのSaaS連携サービス
Dify や n8n については、昨今のトレンドである「Agentic AI（自律型AI）」を考慮すると、データパイプラインも汎用的なワークフローツールで一本化できるのではないか？という仮説があったためです。
なぜ他ツールを見送ったか
まずは、採用に至らなかったツールの評価ポイントを整理します。
1. Airbyte (OSS版)
Modern Data Stack の代表格であり、コネクターの網羅性は圧倒的でした。
当初は PyAirbyte といったライブラリを検証したりと最有力候補でした。
-
良かった点:
- コネクターが豊富: メジャーな SaaS からロングテールなものまで対応可能。
- OSSの信頼性: データ同期（Sync）の仕組みが堅牢です。
-
微妙な点:
- ユーザー管理の課題 (OSS版): OSS版はユーザー管理機能がなく、構築時のEmail/Passのみで管理します（SSO 等は Enterprise 版の機能）。「データマートのカオス化を防ぐためにデータソース追加権限は管理者に絞る」という運用方針だとしても、チーム開発におけるセキュリティとガバナンスに不安が残りました。
- 学習コスト: 標準コネクターがない場合、CDK を使って自作する必要がありますが、独自仕様のキャッチアップに一定の工数を見込む必要がありました。
2. Dify / n8n
これらは社内の別文脈で検証が進んでいた経緯から候補に挙げましたが、「データ連携」というより「プロセス自動化」の文脈で強力でした。
-
良かった点・微妙な点:
- 自由度が高すぎる: ETL 専用ツールではないため、エラーハンドリング、スキーマ変更への追従、増分更新のロジックなどをすべて自分たちで作り込む必要があります。
- 用途の違い: 単発のタスク実行や LLM を絡めた処理には最強ですが、「大量データを信頼性高く転送し続ける」という基盤用途には不向きと判断しました。
AppFlow を選択した理由
最終的に採用したのが Amazon AppFlow です。選定の決め手となったのは以下のポイントです。
1. コネクターの充実とAWS親和性
Airbyte の網羅性には及ばないですが、Salesforce はもちろん、主要なSaaSに対応しています。
- 対応コネクター例: Salesforce, Snowflake, S3, RDS, Redshift, Slack, Jira, Zendesk, Google Sheets, Google Analytics 4, Datadog, GitHub 等
2. カスタムコネクターの柔軟性 (vs Lambda)
標準コネクターがない場合でも、AWS Lambda を使ってカスタムコネクターを作成できます。
Lambda コネクター利用時には「1実行あたり最大30秒（Lambda の仕様では最大15分の実行が可能ですが、AppFlow からの呼び出し時はさらに短くなります）」という制約があり、基本的にはページネーションによるデータ取得を前提としています。
この「ページングしながらデータを取得する」ように実装すれば、Lambda のタイムアウトを回避しつつ大量データの取得が可能です。我々は普段から AWS を利用しているため、Airbyte の独自仕様を覚えるよりも Lambda を書くほうが学習コストが低いと判断しました。
使用感としては AWS Glue のネイティブ接続に近い印象です。
3. コストパフォーマンス
サーバーレスのため待機コストがかからず、実行回数と転送量だけの従量課金で済みます。スモールスタートには最適です。
※ 課題：Salesforce レポートの取得
Salesforce の「オブジェクト（テーブル）」の取得はスムーズですが、「レポート」データの取得には課題があります。レポートは xlsx 形式でのダウンロードとなるケースが多く、ページネーションが効かないためタイムアウトのリスクがあります。
この部分に関しては、PoC としてのスクリプト作成は完了しており、AppFlow ではなく完全なカスタムスクリプトを Lambda や Glue といった環境での運用を検討する必要がありそうです。
結論：AppFlow + dbt によるアーキテクチャ
以上の検証から、私たちのデータ基盤は以下の構成で進めることにしました。
Amazon AppFlow (EL: Extract & Load)
- 役割: データの「運び屋」に徹する。
- SaaS 上のデータをそのままの形（Raw Data）でS3やDWHのランディングゾーンへ配置します。
- インフラ管理コストを最小限にしつつ、Salesforce連携を確実に遂行します。
dbt (T: Transform)
- 役割: データの「加工・整形」を担う。
- AppFlowが運んできたデータを、分析しやすい形に変換し、データマートを作成します。
- バージョン管理やテストを dbt で一元管理することで、品質を担保します。
- dbt の実行については GitHub Actions などを検討しています。
その先の展望：Amazon Quick Suite への期待
今回は「データを運んで整える（ELT）」部分のお話でしたが、その後の「活用」フェーズにおいて注目しているのが、先日発表された Amazon Quick Suite です。
(この記事は AWS re:Invent 2025 開催直前に執筆しています。イベント本番で新たな情報が発表されている可能性があります。)
従来の Amazon QuickSight が進化し、「Agentic AI」を中核に据えたプラットフォームになると発表されました。
単なる BI（可視化）だけでなく、Quick Flows（ワークフロー自動化）や Quick Automate（プロセス最適化）といった機能が統合される予定です。
- 現状: Dify や n8n は ELT には不向きと判断しました。
- 期待: Quick Suite が進化すれば、分析結果（BI）をトリガーにして、「売上が低下したらアラートを飛ばす」「特定条件で次のアクションを実行する」といったワークフローが、分析基盤とシームレスに統合される可能性があります。
「データを見て終わり」ではなく、「データを見たら AI が次のアクションを提案・実行してくれる」。
そんな次世代のデータ活用基盤の有力な選択肢として、AppFlow + dbt で整えたデータの「出口」としての活用を期待しつつ、引き続きウォッチしていく予定です。
Discussion