LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

データ取込（EL/ingestion）が担う役割

データ取込（ingestion）とは、SaaS・データベース・ファイルなど複数のソースからデータを抽出（Extract）し、変換を加えずにそのままDWH（データウェアハウス）やデータレイクへ格納（Load）する処理を指します。FivetranはこのEL部分を担う代表的なマネージドサービスであり、Airbyteはオープンソース（OSS）とクラウド版の両方を提供するプラットフォームです。

ELT（Extract Load Transform）とは、抽出したデータをまず変換せずに格納し、格納後にDWH側で変換処理を行う設計思想です。Fivetranの公式ドキュメントは、クラウドストレージとモダンな列指向DWHの普及により、変換前にデータを絞り込む従来のETLパイプラインから、生データをそのまま格納してから変換するELTへの移行が進んだと説明しています^*1。本稿では、このELTのうちEL（抽出・格納）を担うFivetranとAirbyteに絞って解説します。

多数のSaaS・DBそれぞれに専用の抽出スクリプトを自前で書き、API仕様変更やスキーマ変更に個別対応する体制は、ソース数が増えるほど保守負荷が積み重なります。FivetranとAirbyteは、この抽出・格納部分を標準化されたコネクタ群として提供することで、個別スクリプトの保守から解放される点に価値があります。

コネクタとコネクションで組む取込の骨格

Fivetranにおけるコネクタ（connector）とは、特定のソースからデータを抽出し、選択した送信先（destination）に格納する、Fivetranが事前構築したデータパイプラインです^*2。コネクション（connection）は、そのコネクタを使ってソースから送信先へデータを複製する個別のパイプラインインスタンスを指します^*2。1つのコネクタに対して複数のコネクションを作成できる構成です。

Fivetranの各コネクタは、それぞれ固有のスキーマを作成・管理します^*3。コネクタの種類によって、ソース側からプッシュされるデータを受け取る方式と、Fivetran側からリクエストを送ってレスポンスを取得する方式のいずれかで動作します^*3。

Airbyteも同様に、ソース（source）・送信先（destination）・コネクタ（connector）という構成要素で成り立ちます。Airbyteの特徴は、コネクタの提供形態がOSS版とクラウド版で共通していることです。600以上のコネクタが利用可能で、この点はプランの違いにかかわらず共通しています^*4。

コネクタ選定時に確認すべき点は、対象のSaaS・DBに対応するコネクタが両社に用意されているか、対応していない場合に独自コネクタを開発できるか（Fivetranの場合はConnector SDK^*2、Airbyteの場合はConnector Builder^*4）の2点です。標準コネクタで対応できないソースが多いほど、開発・保守の工数が増える点に留意が必要です。

増分同期と初回同期、再同期の仕組み

Fivetranでは、コネクションの利用開始時に実行される「historical sync（履歴同期）」があり、そのうち最初の1回を「initial sync（初回同期）」と呼びます^*5。初回同期の完了後は、変更・追加されたデータのみを対象にする「incremental sync（増分同期）」モードに移行します^*5。増分同期では、前回同期からの変更点を追跡するために「カーソル」という仕組みで同期履歴を記録します^*5。

データ整合性の問題が発生した場合は「re-sync（再同期）」を実行し、ソースの全履歴データを再取得します^*5。一部のコネクタでは1日1回の「rollback sync」も実行され、通常の増分同期よりも広い範囲の過去データを再取得することで、増分同期の時間枠外で発生した変更も取り込みます^*5。

Airbyteのsync mode（同期モード）は、ソース側の読み取り方式（Incremental／Full Refresh）と送信先側の書き込み方式（Append／Overwrite／Deduped）の組み合わせで構成されます^*6。Incrementalは前回同期以降に追加されたレコードのみを読み取る方式で、カーソルを使う方法とCDC（Change Data Capture、変更データ取得）を使う方法があります^*6。初回のIncremental同期はFull Refreshと同等の挙動になります^*6。

両社とも同期の実行間隔（スケジュール）を設定できます。Fivetranは固定間隔（デフォルト6時間ごと）・Cronスケジュール・手動トリガーの3方式に対応し、プランによって最短1分間隔まで選択できます^*7。Airbyteも同様にScheduled・Cron・Manualの3方式があり、Airbyte Cloudでは最短でも1時間に1回の間隔が上限です^*8。

スキーマ変更（ドリフト）への自動対応

ソース側でカラムの追加・削除・型変更が発生した際、取込基盤側がどう追従するかは運用の安定性を左右する要素です。Fivetranはカラムの型変更を検知すると、既存データと新データの両方を損失なく表現できる、より汎用的な型へ自動的にカラムを昇格させます^*3。例えば数値型（DOUBLE）と真偽値型（BOOLEAN）が混在する場合は、両方を表現できる文字列型（STRING）に変換されます^*3。

Airbyteはスキーマ変更の検知・伝播方法をコネクションごとに設定できます^*9。「フィールド変更のみ伝播」「フィールド・ストリーム変更をすべて伝播」「変更を手動承認」「変更検知時に同期を停止」という4つの設定から選べます^*9。新しいカラムの追加は基本的に非破壊的変更として自動反映できますが、既存の主キーやカーソルが削除される変更は「破壊的変更」として扱われ、設定にかかわらず同期が自動的に一時停止し、手動レビューが必要になります^*9。

この違いは、内製で運用する場合に想定すべきリスクの範囲に直結します。カラム追加程度の変更は両社とも自動反映できますが、主キー変更のような構造的な変更は人の判断を挟む設計になっている点を踏まえ、監視・アラートの体制を事前に組んでおく必要があります。

FivetranのMAR課金モデル

Fivetranの課金は、MAR（Monthly Active Rows、月間アクティブ行数）という単位に基づく使用量課金です^*10。MARとは、Fivetranが1カ月間に処理した行数のことで、新規追加された行（Insert）と既存行の更新・削除（Update）が対象に含まれます^*10。一方、値に変化のない行の再取得や、コネクタ設定時に行う初回の一括データロード（initial sync）はMARの対象から除外されます^*10。

各コネクションの利用量に応じて単価（spend rate）が変動する仕組みで、公式ドキュメントは「利用量が増えるほど単価は下がる」という料率構造を説明しています^*10。加えて、月間利用量が1MAR〜100万MARの標準コネクションには、一律5米ドルの基本料金（base charge）が課される仕組みです（Freeプランには適用されません）^*10。

プラン構成はFree・Standard・Enterprise・Business Criticalの4段階です^*11。Freeプランはコネクション用途で月間50万MARまで無料で利用でき、Standardプランは700以上のフルマネージドコネクタと15分間隔での同期に対応します^*11。Enterpriseプランでは1分間隔の同期やVPNトンネル、Business Criticalプランでは顧客管理鍵による暗号化やPCI DSS（クレジットカード業界の国際的なセキュリティ基準）Level 1認証といった、データ保護要件の高い企業向けの機能が加わります^*11。

MAR単位の課金は、テーブル数やコネクタ数ではなく「実際に変化したデータ量」に応じて費用が変動する点が特徴です。ソースの更新頻度が高い、あるいは監視対象のテーブルが多いプロジェクトほど、事前にMARの見積もりを行っておくことが予算策定の前提になります。

AirbyteのOSS・クラウド・プラン構成

Airbyteはオープンソース版（Core）とクラウド版（Standard・Plus・Pro・Enterprise Flex・Self-Managed Enterprise）を提供しています^*4。Coreはセルフホストでの利用を前提とした無料の選択肢で、自社でOSSソフトウェアを運用できるデータエンジニアリング組織向けとされています^*4。

Standard・Plusはデータ量に応じたボリュームベース課金のフルマネージドクラウドサービスです^*4。一方、Proプランは「Data Workers」という単位で計算されるキャパシティベース課金を採用しており、公式サイトは「データ量ではなく計算リソースの容量に対して課金する」点を明確にしています^*4。1つのData Workerで複数の同期を並行実行できる仕組みで、データ量が急増しても費用が急変しない予測可能性を訴求しています^*4。

この比較から見えるのは、Fivetranが運用の手間を最小化する方向に設計され、Airbyteは費用構造とカスタマイズの選択肢を広げる方向に設計されている違いです。自社で運用体制を持てるかどうかが、どちらの方向性が合うかを分ける分岐点になります。

取込（EL）とdbt等の変換（T）の役割分担

Fivetranの公式ドキュメントは、データ変換とモデリングをFivetranと顧客の間で分担する「shared responsibility model（責任共有モデル）」を採用していると説明しています^*3。Fivetranの責任範囲は、ソースから送信先までの抽出・格納を設計・構築・運用・保守し、送信先内での変換・モデリング・検証を統合することです^*3。一方、顧客の責任範囲は、格納されたデータを自社の要件に合わせて変換するSQLクエリを書き、それを継続的に保守することです^*3。

この分担が意味するのは、FivetranやAirbyteが担うのは「正確でクリーンな生データを届けること」までであり、そのデータをビジネス指標や分析用のテーブルへ加工する工程はdbt等の変換ツールの役割だという点です。取込基盤の選定だけでは分析基盤全体は完結せず、変換工程を含めた設計が別途必要になります。

実務上、取込フェーズと変換フェーズを同じチームが兼務するケースもありますが、必要なスキルは異なります。取込フェーズではコネクタの設定・同期スケジュール・スキーマ変更対応の理解が求められ、変換フェーズではSQLの設計力とデータモデリングの知識が求められます。両方を1人が兼任する体制では、どちらかの工程で手薄になりやすい点に注意が必要です。

内製と外注、導入の判断軸

データ取込基盤を内製で構築・運用する場合、コネクタの選定・スキーマ変更設定・同期スケジュールの設計に加え、MARや課金単位の見積もり・監視体制の整備という複数領域の知識が必要になります。ソース数が増えるほど、これらの設定を個別に管理する工数も増加します。

失敗コストの観点では、スキーマ変更の伝播設定を誤ると、想定外のカラム追加がそのまま自動反映され、下流の変換処理やBIダッシュボードでエラーが発生する事態につながります。特に主キー削除のような破壊的変更を放置すると、同期自体が停止し、データ更新が滞る状態が発生します^*9。監視体制を整えずに導入すると、こうした停止に気づくまでの時間が長引くリスクがあります。

必要スキル・工数の面では、コネクタ設定・MARの見積もり・スキーマ変更設定・同期スケジュール設計・変換ツールとの連携確認という一連の作業を、データエンジニアリングの知識を持つ担当者が対応する体制が現実的です。これらを1人で兼務するのは難しく、取込基盤の担当者と変換（dbt等）の担当者を分けて配置する体制が実務では取られます。

外部パートナーに委託する場合と内製で進める場合の違いは、コネクタ・プラン選定の妥当性を第三者の視点で検証できるかどうかに表れます。特にFivetranのMAR課金とAirbyteのボリューム/キャパシティ課金は将来のデータ量増加によって費用構造が変わるため、事前のシミュレーションを外部の知見を交えて行うことで、想定外のコスト増を防ぎやすくなります。LASSIC IT事業部は、元請（プライムベンダー）としてシステムの保守・運用を受託する体制を備え、要件整理からコネクタ選定、運用開始後の監視まで一貫して対応します。

まとめ：データ取込基盤導入を外注で進める判断軸

本稿では、FivetranとAirbyteが担うデータ取込（EL/ingestion）の仕組みを、コネクタ・増分同期・スキーマ変更対応・課金モデルという一次情報の観点から整理しました。要点は3つに集約できます。第一に、コネクタとコネクションという構成要素を通じて、多数のソースからの抽出・格納作業を標準化できる点が両サービスの共通の価値です。第二に、Fivetranはマネージド運用とMAR課金、AirbyteはOSSとクラウド課金（ボリューム/キャパシティ）という異なる方向性を持ち、自社の運用体制に応じた選択が必要です。第三に、取込（EL）とdbt等の変換（T）は役割が異なり、取込基盤の導入だけでデータ活用が完結するわけではありません。これらを踏まえたうえで、自社の体制に合った導入方法を選ぶことが大切です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Fivetran「Core Concepts」（fivetran.com）
2. *2　出典：Fivetran「Pricing FAQ」（fivetran.com）
3. *3　出典：Fivetran「Core Concepts」（fivetran.com）
4. *4　出典：Airbyte「Pricing」（airbyte.com）
5. *5　出典：Fivetran「Sync Overview」（fivetran.com）
6. *6　出典：Airbyte「Sync Modes」（docs.airbyte.com）
7. *7　出典：Fivetran「Sync Overview」（fivetran.com）
8. *8　出典：Airbyte「Sync Schedules」（docs.airbyte.com）
9. *9　出典：Airbyte「Schema Change Management」（docs.airbyte.com）
10. *10　出典：Fivetran「Pricing FAQ」（fivetran.com）
11. *11　出典：Fivetran「Pricing」（fivetran.com）

Tweet