「請求書が去年より1.4倍。どこからコストダウンすればいいか分からない」。そんな相談を月に何件かいただきます。
データ基盤のランニングコストが読みにくいのは、費目が「収集・変換・DWH・連携プラットフォーム・ファイル連携・BI・人件費」と7レイヤに分かれていて、レイヤごとに効く打ち手が違うためです。DWHのクエリだけ叩いても、FivetranのMARやHULFT保守費、iPaaSのフロー本数課金はそのまま残る。全体を眺めた上でレイヤ別に手順を切らないと、コストダウンしても数ヶ月でリバウンドします。
そこで本記事では、Evast支援先で6ヶ月20〜35%削減した実務を、収集／変換／連携プラットフォーム／ファイル連携／大規模連携 のレイヤ別コストダウン手順として整理しました。DWH単体の最適化はBigQueryの料金体系とコスト削減、初期構築費の話はデータ基盤構築の費用相場で扱っているので、こちらは「動かし続けるレイヤ別の月額」に軸足を置いています。
データ基盤の毎月のコストは、図のように4つの要素に分かれます。要素ごとに、効く削減の手段が違います。
どの要素が重いかは、会社によって大きく違います。クエリ費が大半を占める会社もあれば、BIライセンスや人件費が効いている会社もあります。Evastの支援先でも、月額80万円のうち55万円がBigQuery、15万円がFivetran、10万円がLookerだった、というように内訳の偏りは会社ごとに違います。だからこそ、まず内訳を見える化する。ここが出発点です。
「うちはどのレイヤから叩けば効くのか」を先に一望できるよう、7レイヤ×3タイムラインで整理しました。各レイヤ名をクリックすると該当セクションに飛べます。
| レイヤ | すぐ効く（1ヶ月） | 中期（3〜6ヶ月） | 構造改革（6ヶ月〜） | 期待削減率 |
|---|---|---|---|---|
| データ収集（Ingest） | 同期頻度を毎時→3時間おき | 増分同期・CDC切替、休眠コネクタ停止 | 内製Python＋Cloud Runへの置換 | 20〜40% |
| データ変換（Transform／ELT） | 不要dbtモデルの剪定 | Materialization見直し（table→incremental） | Composer 3オートスケール、Airflow統合 | 30〜60% |
| DWH（保管・計算） | SELECT *廃止、未使用テーブル削除 | パーティション／マート化、Auto-Suspend短縮 | Editions／コミットメント割引 | 20〜50% |
| 連携プラットフォーム（iPaaS／EAI） | 休眠フロー停止、接続先棚卸し | フロー統廃合、リアルタイム→バッチ化 | OSS併用ハイブリッド化、グループ共通利用 | 15〜40% |
| ファイル連携（SFTP／HULFT／EDI） | 休眠取引先の連携停止 | マネージドSFTP化、圧縮フォーマット導入 | クラウド型EDIへリプレース | 20〜50% |
| 大規模連携 | ジョブ並列度・時間帯の見直し | Parquet＋ZSTD、CDCへ切替 | データ仮想化・可搬技術で物理コピー削減 | 20〜50% |
| BIライセンス／人件費 | 未使用アカウント棚卸し | 閲覧者と編集者の分離 | 手作業レポートの自動化 | 20〜40% |
削減額の絶対値が大きくなりやすいのは、DWH・データ収集・ファイル連携の3つ。特に「ファイル連携（HULFT／オンプレEDI）」は保守費と運用人件費が抱き合わせで下がるので、着手前後の差が読みやすいレイヤです。
クラウドコストを組織で継続的に最適化する考え方は、FinOps（クラウド財務管理）と呼ばれます。FinOps Foundationは、Inform（可視化）／Optimize（最適化）／Operate（運用化） の3フェーズと、「全員がコスト責任を持つ」「意思決定はビジネス価値で行う」といった原則群を提唱しています（原則の数はFinOps Foundation側で改訂される場合があるため、最新はfinops.org参照）。
3つのフェーズを月次で1周させれば十分です。
Evastの支援でも、未使用リソースの削除やオーバースペックの見直しといった Inform → Optimize の1周だけで、クラウドコストが1〜3割下がった事例が半数以上を占めます。一度の大掃除より、毎月の小さな手入れ。以降のセクションで、各フェーズの実務を掘り下げます。
「先月までと使い方は変えていないのに、請求が跳ね上がった」というケースには、共通の原因があります。可視化したときに、まず疑いたいポイントです。
このうち重いクエリ・放置リソースは、次節の高コストクエリ特定で一気に見つけられます。BigQueryで請求が膨らむ典型パターンはBigQueryの料金体系とコスト削減｜課金トラップと対策で具体的に解説しています。
「削減しよう」と思っても、どのクエリが重いのかが分からないと手が付けられません。BigQueryなら INFORMATION_SCHEMA.JOBS_BY_PROJECT を叩けば、スキャン量順にランキングが取れます。
-- 直近30日、総スキャン量が多い実行ユーザーTOP10
SELECT
user_email,
ROUND(SUM(total_bytes_billed) / POW(1024, 4), 2) AS billed_tb,
ROUND(SUM(total_bytes_billed) / POW(1024, 4) * 6.25, 0) AS cost_usd,
COUNT(*) AS runs,
ANY_VALUE(SUBSTR(query, 1, 200)) AS sample_query
FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
AND job_type = 'QUERY'
AND state = 'DONE'
GROUP BY user_email
ORDER BY billed_tb DESC
LIMIT 10;クエリ単位でTOP10を取りたい場合は GROUP BY query（またはクエリのハッシュ）に変更してください。
total_bytes_billedは課金対象のバイト数、6.25 USD/TBはオンデマンドStandard SKUの目安単価です（2026年時点、公式最新はcloud.google.com/bigquery/pricing参照）。実際に走らせると、上位3〜5本のクエリで全体スキャン量の6〜8割を占めていることが多く、ここを叩くだけで請求が数割落ちます。
Snowflakeなら ACCOUNT_USAGE.QUERY_HISTORY と WAREHOUSE_METERING_HISTORY を組み合わせて同様のランキングが作れます。SnowflakeとBigQueryのコスト構造の違いはSnowflakeとBigQuery比較：コスト・性能・機能の違いと選び方で比較しています。
「全社で月100万円」だけ見えていても、どの部門が使っているか分からなければ削減の判断はできません。ここで効くのがタグ／ラベルによるコスト配賦です。
Evastで最初に整えるのは、最低限の3ラベルです。
| ラベル | 例 | 目的 |
|---|---|---|
env | prod / stg / dev | 環境別コスト、dev放置の検知 |
team | marketing / sales / finance | 部門別配賦、責任所在 |
project | ad-report / cdp-v2 | プロジェクト別損益 |
GCPならリソース作成時にラベルを付与、SnowflakeならOBJECT TAGを付けます。運用ルールとしては、
の3点を回すと、半年ほどで「誰のコストか分からないリソース」はほぼゼロになります。
多くの企業で最初に効くのが、クラウドDWHのコストです。BigQueryのようにスキャンしたデータ量に課金されるDWHでは、クエリの書き方ひとつで費用が大きく変わります。
SELECT * をやめ、必要な列だけを指定するたとえば100GBのテーブルに SELECT * を繰り返すのと、必要な数列だけを読むのとでは、スキャン量が10分の1以下になることもあります。BigQueryの具体的な削減策はBigQueryの課金トラップと具体的な削減策で詳しく解説しています。
BigQueryのオンデマンド課金は 6.25 USD/TB（Standard SKU、2026年時点）です。一方Editionsの定額プランは、Standard で 0.04 USD/slot-hour から。月100スロットを24時間×30日確保すると 100 × 0.04 × 24 × 30 = 2,880 USD/月 になります。同じ2,880ドルをオンデマンドで賄うと約460TBのスキャンに相当するため、実務上の損益分岐点は概ね月400〜500TB付近。ここから逆算すると、
が目安になります。実際に切り替える前に、直近3〜6ヶ月の total_bytes_billed で試算してから判断するのが確実です。
BigQueryとは課金モデルが異なるSnowflakeには、固有の削減レバーがあります。特に効くのがウェアハウスの止め方とサイズ設計。以下は現場でよく使う打ち手です。
Amazon Redshiftは、ノード型かServerlessかで打ち手が変わります。夜間停止やスパイクの吸収に効くレバーが用意されています。
各DWHの料金構造の横断比較は、Amazon Redshiftの料金はAmazon Redshiftの料金体系｜インスタンス・Serverless・課金の目安、DWH全体の見積はDWHコスト見積ガイド｜BigQuery・Snowflake・Redshiftの試算方法を参照してください。
データ収集レイヤは、Fivetran・Airbyte等のELTツールのMAR（Monthly Active Rows）課金と、SaaS API側のコール数課金が二重で効いてくる領域です。ここは「頻度を落とす／方式を変える／内製に寄せる」の3手が定石です。
Evast支援先の例では、Fivetranの連携18本を「頻度3時間おき化＋未使用4本停止」に整理しただけで、MAR課金が月15万円→13万円（-2万円）に落ちました。Fivetran固有の削減レバーはFivetranのコスト最適化｜MARの削減と契約プランの見直し、収集ツールの選び方はデータ連携ツールの選び方：コスト・サポート・コネクタ数で比較を参照してください。
変換レイヤのコストは、dbt Cloudのモデル実行数課金 と DWH側のスキャン量課金 が同時に効いてくるのが厄介です。dbtでmodelを増やすほどDWHスキャンも比例して増えるので、変換設計の見直しは二重で効きます。
Materialization戦略（最も効く）
view → table → incremental → ephemeral の使い分けを見直すtableにしていたモデルをincrementalに切り替えると、スキャン量が1〜2桁減ることが多いtableにしていたモデルはephemeralに落として物理化を止めるモデル剪定
dbt run --select tag:dailyのようにタグで絞り、全モデル無条件ビルドをやめるdbt source freshnessで更新のないsourceは、その配下のモデルビルドをスキップする設定にするBigQueryスケジュールドクエリ
INFORMATION_SCHEMA.JOBS_BY_PROJECTで重複実行しているスケジュールドクエリを検出し、統合Airflow／Cloud Composer環境費
Evast支援先の実測では、dbtモデル120本のうち32本を剪定＋主要ファクト5本をincremental化した結果、dbt CloudのMonthly Model Runsが38%減、それに紐づくBigQueryスキャン量も29%減となりました。
ASTERIA Warp・DataSpider・Boomi・Workato等のiPaaS／EAIは、DWHとは別文脈で「基幹〜SaaS〜社外」を繋ぐレイヤです。契約体系は主にフロー本数課金・実行回数課金・接続先数課金の3モデルに分かれ、効く打ち手も変わります。
| 課金モデル | 代表製品 | 効く打ち手 |
|---|---|---|
| フロー本数課金 | ASTERIA Warp Core／DataSpider | 似た処理のフロー統廃合、共通部品化 |
| 実行回数課金 | Workato／Zapier for Companies | リアルタイム→バッチ化（1時間ごとに寄せる）、無駄なポーリング停止 |
| 接続先数課金 | Boomi／Informatica IPC | 休眠接続の停止、接続先の集約 |
さらに横断で効くのが次の3手です。
Evastの直近事例では、Boomi接続数が58ある製造業の顧客で、休眠接続24本を停止＋グループ間で1ライセンス共通化することで、年額ライセンス費が42%減になりました。iPaaS／連携ツール全般の料金相場はデータ連携ツールの料金相場ガイドで扱っています。
意外と大きいのがファイル連携レイヤです。HULFTのようなオンプレ製品は「ライセンス保守費＋サーバー運用の人件費」がセットで積み上がるため、着手すると効果が読みやすい領域です。
ライセンス・保守費の直接削減
運用改善による削減
Evastで支援した卸売業の例では、オンプレHULFT（サーバー2台＋保守）月28万円を、クラウド型EDIサービス月11万円にリプレース。加えてサーバー当直の人件費が月5万円削減され、合計で月22万円のランニングコスト削減となりました。
数TB／日以上を動かす大規模連携は、単価が小さくても総額が大きくなりやすいレイヤです。ここでは「動かさない・小さくする・ずらす」の3方向で削減余地があります。
動かさない：データ可搬技術・データ仮想化
小さくする：CDCと圧縮
ずらす：並列度と時間帯制御
max_active_runs／Cloud Composerのworker_concurrencyを見直し、同時起動を減らしてピークslotを下げるEvast支援先の物流業（日次3.2TB連携）では、CSV→Parquet+ZSTDへの切替＋フル→CDC化で、BigQuery側の月間スキャン量が62%減、外部転送費が48%減。合計で月30万円強の削減となりました。
ツールと連携レイヤの次に効くのが、BIライセンスと運用の人件費です。
BIライセンスの見直し
主要BIツールの選び方はPower BI・Tableau・Looker比較｜5軸の違いと選び方【2026年版】もあわせてご覧ください。
運用の人件費
見落とされがちですが、人件費もランニングコストの一部です。毎月、誰かが手作業でデータを集計したり、レポートを作り直したりしているなら、そこにコストがかかっています。月40時間かかっていたレポート集計を自動化した場合、時給4,000円換算で月16万円の削減。特定の担当者しか分からない属人的な運用を仕組み化しておくと、その人が抜けたときの混乱も防げます。運用の外部並走という選択肢はデータマネジメント支援、運用保守の費用相場はデータ基盤の運用保守・保守委託の費用と体制【2026年版】にまとめています。
Evast支援先の一例（BtoB SaaS、従業員120名、データエンジニア1名）。データ基盤の月額80万円を、6ヶ月で52万円まで下げた実例です。
着手前の内訳（月80万円）
6ヶ月後（月52万円、-35%）
効いたのは派手な打ち手ではなく、Inform→Optimizeを毎月1周させた結果です。1ヶ月目にダッシュボードと上位クエリ抽出、2〜3ヶ月目にクエリ書き換えとFivetran整理、4ヶ月目にEdition試算とBI棚卸し、5〜6ヶ月目に月次レビューの定例化。段階的に積み上げたパターンです。
削減プロジェクトが空回りする理由には、いくつか典型パターンがあります。
段階的に立ち上げるのが現実的です。1ヶ月で全部やろうとした支援先は、例外なく6ヶ月目に運用が形骸化しました。
このロードマップを1周させると、6ヶ月で20〜35%の削減がEvast支援先の中央値ゾーンです。
FinOpsのOperate（運用化）で肝になるのが月次のコストレビュー会議です。専任チームがない会社でも、月30分の会議を回すだけで十分機能します。
参加者（3〜5名）
アジェンダ（30分）
| 時間 | 議題 | 資料 |
|---|---|---|
| 0〜5分 | 前月コスト実績・前月比・予算比 | 請求ダッシュボード |
| 5〜15分 | 増減トップ3の理由と対応 | ラベル別コスト、上位クエリ |
| 15〜25分 | 削減施策の進捗と新規施策の提案 | ロードマップ |
| 25〜30分 | 来月の予算アラート閾値・宿題 | 議事メモ |
追いかけるKPIの例
この形式で半年運用したEvast支援先では、月次レビューが定例化して以降、削減施策のリバウンドがほぼゼロになっています。会議体をつくらないと、削減施策は3ヶ月で形骸化します。
6ヶ月やってみて残る教訓は次の7点です。
今月の請求書を開いて、7レイヤの内訳がすぐ出せなければ、そこが最初の課題です。
株式会社Evastでは、データ基盤の設計・構築からBIダッシュボード開発、運用定着まで を一貫して支援しています。
「収集／変換／連携プラットフォーム／ファイル連携／大規模連携のどれから手を付けるべきか分からない」。そんな相談を月に何件かいただきます。
直近3ヶ月の請求書（BigQuery／Snowflake／Fivetran／HULFT／iPaaS／BI等）をお預かりし、レイヤ別コストダウン試算レポート（無料） としてお返しします。
現状のコスト内訳の可視化や、削減できる箇所の洗い出しからでも構いません。自社の状況に合った見直しを先にざっくり知りたい方は、データ活用の無料診断もご利用ください。
データ基盤データ基盤構築の費用相場を、初期構築費・クラウド利用料・運用保守費の3層に分けて整理します。規模別レンジ、工程ごとの内訳と人月単価、内製と外注の違い、見積もりが会社ごとに2〜3倍ずれる理由、安すぎる見積もりの危険サイン、3〜5年のTCOで考える判断基準まで解説。発注を検討中のマネージャーが予算と業者選定を判断するための実務記事です。
データ基盤Amazon RedshiftからBigQueryへの移行判断・費用・工程を、稟議とベンダー選定にそのまま使える形で整理します。BigQuery Data Transfer ServiceでのRedshift移行、SUPER型やDISTKEY/SORTKEYの扱い、AWS→GCPのエグレス費用、10TB規模で初期1,000万〜2,000万円・3〜4ヶ月という目安まで解説します。
データ基盤BigQueryのパーティションとクラスタリングは、設定手順は簡単でも「どの列を選ぶか」の判断ミスで数十倍のスキャン量になり、月次の請求書ショックを招きます。パーティション3種の使い分け、クラスタリング列の選び方、現場でよくある設計ミス5つ、既存テーブルへの後付け手順、require_partition_filterでの事故防止まで、スキャン量を9割減らすためのテーブル設計の型を整理した2026年版です。