ETLをノーコードで作る範囲と限界：変換・データ量・運用で決める受託切替の条件

ETLをノーコードで組めるツールは、SaaSや基幹データベースからDWHへの取り込みを画面操作だけで定時実行できます。一方で、業務固有の変換ロジック、メモリや評価時間の上限、同期間隔の下限といった制約があり、要件によっては途中で作り込みへ戻る必要があるのです。この記事では、ノーコードETLで任せられる処理と限界に当たる条件を、Power Query OnlineやFivetranの公式ドキュメントに書かれた上限値をもとに整理します。導入前の判定表、PoCでの測り方、受託開発へ切り替える条件と併用構成まで扱います。

まとめ：ノーコードETLは定型の取り込みまで、業務固有の変換と大量処理は作り込みへ

ノーコードETLが力を発揮するのは、コネクタが用意されたSaaSやデータベースから、列の型変換・結合・集計程度の変換を挟んでDWHへ定時に取り込む処理です。接続先が標準コネクタで揃い、変換が画面のステップで表現できるなら、コードを書く理由はほとんどありません。

限界が生じるのは、次に示す3方向です。業務ルールを反映した変換はステップ数とスクリプト上限で管理しきれなくなり、データ量は評価コンテナーのメモリや1日あたりの評価時間で頭打ちになります。運用面では、同期間隔の下限がプランで決まり、初回の全件同期や再同期が請求額を押し上げます。

判断の目安は単純です。変換の中身が業務ルールそのものになった時点、または本番相当のデータ量でPoCを流して上限に当たった時点で、取り込みはノーコードのまま残し、変換と監視をコードで作り込む構成へ切り替えます。製品ごとの料金比較が知りたい場合は、ETLツール比較7製品の課金単位と料金の実額で整理しています。

ノーコードETLとは何か：GUIで組める抽出・変換・ロードの範囲とiPaaSとの違い

ETLは抽出（Extract）・変換（Transform）・格納（Load）の頭文字で、仕組みの全体像はETLの仕組みとELTとの違いを整理した記事で解説しています。ここではノーコードで組む場合に何が画面で完結し、何が残るのかに絞ります。

コネクタ設定と画面上の変換ステップで処理を組むノーコードETLの定義

ノーコードETLは、接続先ごとに用意されたコネクタへ認証情報を登録し、取り込む表と列を画面で選び、変換を「列の削除」「型の変更」「結合」といったステップとして積み上げて処理を作る方式です。スケジュールも画面で指定し、実行履歴とエラー通知までツール側が持ちます。

裏側では、画面で積んだステップがツール固有の定義やスクリプトに変換されて保存されます。Power Query Onlineであれば、ステップはM言語のマッシュアップスクリプトになり、そのサイズ上限は512KBと公式に定められています。画面で組めるといっても、無制限に積めるわけではありません。

ノーコードETL・ローコードETL・iPaaSを処理単位と変換の深さで比較

名前が似ている3種類は、扱うデータの単位と変換の深さで分けると混同しにくくなります。

iPaaSは「受注が1件入ったら会計SaaSへ登録する」ようなイベント単位の連携が得意で、表をまとめて集計する処理は守備範囲外です。iPaaSの位置づけはiPaaSの仕組みと料金の数え方を解説した記事、方式の選び分けはiPaaSとETLの連携方式5種の選定表にまとめています。

ノーコードETLに任せられる処理：定型の取り込みと画面で表現できる変換

ノーコードで完結しやすいのは、接続先が標準コネクタで揃い、変換が「列を整える」範囲に収まる処理です。代表的なパターンを順に見ます。

SaaSや基幹データベースからDWHへ全件と差分を取り込む定型パターン

Salesforceやkintone、広告管理画面、業務システムのデータベースからDWHへ表をそのまま写す処理は、ノーコードETLの中心的な使い道です。コネクタが差分の検出と型の対応づけを肩代わりするため、利用者が決めるのは対象の表と実行間隔くらいになります。

FivetranではSaaS接続を作ると、最初にhistorical sync（過去分の全件同期）を実行しないと接続が使えない仕様です。全件取り込み後は差分だけを定期同期するので、写すだけの処理なら設計作業はほぼ発生しません。

列の型変換・結合・集計など画面のステップで表現できる変換処理

日付文字列を日付型に直す、顧客マスタと受注表を顧客IDで結合する、月別に売上を合計するといった変換は、どのノーコードETLでも画面のステップで組めます。表計算ソフトでの加工と同じ発想で作れるため、データを日常的に扱う業務担当者でも読み書きできる点が強みです。

AWSのGlue DataBrewのように、データ準備の工程に特化した画面で変換レシピを組む製品もあります。仕組みと料金はAWS Glue DataBrewの仕組みとGlue Studioとの使い分けで解説しています。

プリセットのデータモデルで変換まで任せるFivetranのQuickstart型

変換そのものを製品側の既製品に任せる方式もあります。FivetranのQuickstart data modelsは、自前のdbtプロジェクトを作らずに事前構築済みのデータモデルを追加できる機能です。広告やCRMなど、項目構成が世界共通に近いSaaSでは、分析用の表まで画面操作だけで揃います。

ただし既製のモデルは汎用の集計軸で作られています。自社独自の顧客区分や商品階層で集計したい場合は、結局どこかに自社の変換を足すことになります。

ノーコードETLの限界：変換ロジック・データ量・運用の3方向で詰まる条件

限界は製品の出来不出来より、画面操作という方式そのものから生じます。公式に数値で示されている上限を手がかりに、詰まる条件を具体化します。

業務固有の変換ロジックはステップ数とスクリプト上限で破綻しやすい

「得意先ランクと契約形態の組み合わせで単価を決め、月中の改定は日割りで反映する」といった業務ルールを画面のステップで表現すると、条件分岐が数十ステップに膨らみます。どのステップがどのルールに対応するかを第三者が追えなくなり、改定のたびに作った本人しか直せない状態に陥ります。

処理を組めても、製品側の上限に当たる点にも注意が必要です。Power Query Onlineはエディターでのクエリ評価が1回10分でタイムアウトし、マッシュアップスクリプトは512KBが上限で、超えるとデータフローを開くこともできなくなる場合があると公式に記載されています。変換に業務ルールが入り始めたら、ノーコードで粘るより変換だけをコードへ移すほうが保守の総量は小さく済みます。

データ量はメモリ上限と1日の評価時間で頭打ちになるPower Queryの例

データ量の限界は、行数そのものより処理環境の枠で決まります。2026年10月時点のPower Query Onlineの公式ドキュメントでは、次の上限が示されています。

• 評価コンテナーはワーキングセット1GB・コミット6GBが上限で、6GBは引き上げ不可
• Power BI ProのデータフローGen1は1時間1,000回・1日8時間・同時20件まで
• Microsoft FabricのデータフローGen2は1時間5,000回・1日100時間まで
• 1つのデータフローに置けるテーブルは50個まで

1日8時間の評価枠は、夜間バッチで数千万行を結合する処理を毎日回すと使い切れる量です。上位のライセンスへ移れば枠は広がりますが、メモリの6GBは製品の構造上の上限なので、大きな結合を1回で処理する設計そのものを見直す必要があります。

同期間隔の下限と初回の全件同期が契約プランと請求額を押し上げる

Fivetranの同期頻度は1分から24時間までの選択式で、既定は6時間です。1分間隔はEnterpriseとBusiness Criticalプランに限られ、Liteコネクターでは選べません。「在庫を5分以内にDWHへ反映したい」という要件が後から出ると、プランの格上げが前提になります。

過去分の取り込み期間を後から延ばすと再同期が発生する点も見落とされがちです。行数で課金される製品では、再同期のたびに請求が膨らみます。課金単位ごとの膨らみ方はETLツール比較の課金単位の章で扱っています。

失敗時の再実行・差分の巻き戻し・変更のテストが画面では管理しにくい

運用で困るのは、処理が途中で失敗したときです。どこまで書き込まれたかを確かめ、重複しないように再実行する手順は、画面操作のツールでは担当者の記憶に頼りがちになります。変換ステップを1つ変えたときに既存の集計値が変わらないかを確かめるテストも、画面上では仕組み化しにくい領域です。

変更履歴の管理も同じ課題を抱えます。コードであればGitで差分を見て戻せますが、画面で組んだ処理は製品が持つ履歴機能の範囲でしか追えません。月次決算の数字に使うデータを流すなら、誰がいつ何を変えたかを後から説明できる状態かを導入前に確認しておきます。

導入前に確かめる項目：接続先・変換の複雑さ・データ量・担当者の4軸の判定表

ノーコードETLで足りるかは、ツールを触る前に4つの軸でかなり絞り込めます。

ノーコードETLで足りるかを接続先・変換・データ量・担当者で判定

実務ではまず「変換の中身」の行だけを見れば十分です。ここが右列に入るなら、ほかの軸が左列でも、変換部分はいずれ作り込みが必要になります。接続先が右列の場合は、そのデータだけを別の仕組みで取り込み、残りをノーコードで扱う分割も選べます。

本番相当のデータ量を1回流して上限に当たるかを測るPoCの手順

判定表で迷う場合は、無料枠や試用期間を使って本番相当の条件で1回流すのが確実です。

1. 直近1か月分の実データで、最も行数の多い表と最も変換の複雑な表を1本ずつ選ぶ
2. 本番で想定する変換ステップをすべて組み、所要時間とエラーの有無を記録する
3. 製品の上限値（評価時間・メモリ・同期間隔）と記録値を並べ、余裕が半分以上あるかを見る
4. 変換ステップを1つ変更し、作成者以外が意図どおりに直せるかを確かめる

手順4は見落とされがちですが、担当者の異動後に保守できるかを測る唯一の方法です。サンプルの数百行で試すと上限に当たらないまま導入が決まり、本番移行後に枠不足が判明するので、行数は本番に揃えます。

ノーコードETLを見送り受託開発へ切り替える条件と取り込みとの併用構成

ここからは判断を言い切ります。ノーコードETLは「入れるか入れないか」の二択ではなく、取り込み・変換・監視のどこまでを任せるかで決めるものです。

受託開発へ切り替える3条件：業務ルールの変換・枠超過・障害時の責任

次の条件のどれか1つに当たれば、少なくとも変換部分は作り込みに切り替えます。第一に、変換が単価計算や与信判定などの業務ルールそのものになった場合です。第二に、PoCで評価時間やメモリの上限に対して余裕が半分を切った場合で、データ量は増える一方なので1年以内に枠を超えます。第三に、処理の失敗が請求や決算の誤りに直結し、障害時に原因と影響範囲を説明する責任が生じる場合です。

この3条件に当たる処理は、変換をSQLやPythonで書き、テストと監視を組み込んだデータ基盤として作るほうが長期の保守費は下がります。一創ではデータ分析基盤構築・MLOps構築支援として、既存のノーコードETLを残したまま変換と監視の層を作る構成から相談を受けています。

取り込みはノーコード、変換はdbtやSQLで書く併用構成が向く組織

多くの組織で落としどころになるのは、取り込みをノーコードETLに任せ、DWHに入った後の変換をdbtやSQLで書く構成です。FivetranもTransformations for dbtで変換を宛先のDWH上で実行する連携を用意しており、製品側もこの分担を前提にしています。

この構成が向くのは、SQLを書ける担当者が1人以上いて、変換ロジックをGitで管理したい組織です。dbtの役割と選び方はdbtの仕組みとdbt Core・Cloudの選び方で解説しています。取り込みの手間はノーコードで減らし、業務ルールはレビュー可能なコードに置く、という分け方です。

ノーコードETLを採用しないほうがよい場面：接続2本以下と即時反映

接続先が2本以下で変換も単純なら、ノーコードETLの月額を払うより、DWHやクラウドの標準機能で済ませるほうが安く収まります。AWSのAuroraからRedshiftへ写すだけなら、Zero-ETL統合でETLを挟まずに複製する方法があります。

注文1件ごとに在庫や会計へ即時反映したい要件も、ノーコードETLの領分ではありません。表をまとめて動かすETLではなく、イベント単位で動くiPaaSやAPI連携を選びます。ETLを入れること自体を目的にせず、データの単位と反映の速さから方式を逆算するのが失敗しない順序です。

よくある質問

ノーコードでETLを組む検討の段階でよく出る質問に回答します。

ノーコードETLツールは無料で使えますか？

無料枠や試用期間を設けている製品はありますが、多くは取り込める行数や処理時間、接続数に上限があります。無料枠が向いているのは、本番運用ではなく、本文で紹介したPoCで上限に当たるかを測る用途です。製品ごとの無料枠の条件と有料プランの課金単位は、ETLツール比較7製品で公式ページをもとに整理しています。

ノーコードETLとiPaaSはどちらを選べばよいですか？

表をまとめてDWHへ取り込み、集計や分析に使うならノーコードETL、受注や申込など1件ごとのイベントを別のSaaSへ即時に反映するならiPaaSが向いています。両方の要件がある組織では、分析用の取り込みをETL、業務の自動化をiPaaSに分けて併用するのが一般的です。方式ごとの分岐条件はiPaaSとETLの違いの選定表で確認できます。

非エンジニアだけでノーコードETLを運用できますか？

取り込みと簡単な変換の作成までは、表計算ソフトに慣れた業務担当者でも対応できます。難しくなるのは、処理が失敗したときの再実行や、接続先のSaaSが項目を変えたときの修正です。運用まで非エンジニアだけで回すなら、処理の数を絞り、作成者以外も手順書で直せる状態を作ってから本番に移すことを勧めます。

ノーコードETLからコードベースへ移行するときの注意点は何ですか？

最初に、画面で組んだ各ステップが何の業務ルールに対応しているかを書き出し、移行後の集計値と突き合わせられるようにします。移行は一度に全部ではなく、変換の複雑な表から1本ずつ進め、旧処理と新処理を並行稼働させて結果が一致するかを数週間確かめてから切り替えます。取り込み部分をノーコードのまま残す構成も、移行時に検討する選択肢の一つです。

AWS Glue DataBrewもノーコードETLに含まれますか？

DataBrewは、データのクレンジングや整形を画面上のレシピで組むデータ準備のサービスで、変換工程をノーコードで担う製品の一つです。SaaSからの取り込みやスケジュール全体の管理は、AWS Glueの他の機能や別のサービスと組み合わせて構成します。仕組みと料金の考え方はAWS Glue DataBrewの解説記事で詳しく扱っています。

関連記事

• ノーコードツール比較｜業務アプリ・Web・EC用途別の代表製品と選び方：ETL以外の用途でノーコードツールを選ぶときの比較軸がわかります。
• TROCCOのセキュリティ｜暗号化・IP制限・監査ログのプラン別条件：国産のノーコードETLを導入する前に確認したいセキュリティ要件を整理しています。
• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説：ノーコードかどうか以前の、ETLの基本と選定観点を押さえられます。