SnowflakeとBigQueryを事業部ごとに使い分け、両者をまたぐデータ統合基盤の刷新を検討している数千人規模企業のデータ基盤担当者は、部門横断の分析を行うたびにETL（Extract-Transform-Load、データを抽出・変換して別システムへコピーする処理）ジョブを組み直す作業に追われている。SIer（システムインテグレーター）に運用を委託している場合、連携先が増えるたびに保守契約の見直しと追加費用の稟議が発生する。
Google Cloudは2026年7月30日、Next Tokyoで「borderless Lakehouse（ボーダーレス・レイクハウス）」の拡張を発表した[1]。柱の一つが、AWS Glue、Databricks Unity Catalog、Snowflake Horizonとのカタログフェデレーション（複数クラウドのデータカタログを横断して参照する仕組み、現在プレビュー）である。データを移動させず、BigQueryやApache Sparkから他クラウドのデータへ双方向でアクセスできる[1][2]。
📢 Next Tokyo で Borderless Lakehouse 発表
データの物理的な場所に関係なく、Gemini Enterprise と会話エージェントがデータを分析して行動に移すことを可能に。データを移行することなく、AWS や Azure 上のデータに Gemini を直接適用できます。
#GoogleCloudNext🗼— Google Cloud Japan (@googlecloud_jp) 元投稿を見る
Google Cloud Japanの公式アカウントも同日、データを移さずAWS・Azure上のデータへGeminiを適用できる点を発表の要点として挙げている[3]。
マルチクラウド構成を組む企業のデータ基盤担当者にとって、この機能は既存のETLパイプラインをどこまで置き換えられるか、データ転送コストの構造がどう変わるかの判断材料になる。本稿は発表内容を整理し、日本企業の稟議・保守契約の実情に照らして検討すべき点をまとめる。
予備知識
- レイクハウス: データレイクの柔軟な保存とデータウェアハウスの分析性能を両立させる分析基盤
- Iceberg（アイスバーグ）: 複数の分析エンジンから共通形式で読み書きできるオープンなテーブル形式
- ETL: データを抽出・変換して別システムへコピーする処理。連携先が増えるほど本数が増える
- カタログフェデレーション: 複数クラウドのデータカタログを横断して参照し、データを動かさずに検索・クエリできる仕組み
レイクハウス、データファブリック、データメッシュなど複数のアーキテクチャ選択肢を横断比較しており、マルチクラウド構成の是非を検討する際の判断材料になる。
カタログフェデレーションとは何か Glue・Unity Catalog・Horizonをどうつなぐか
カタログフェデレーションとは、Iceberg REST catalog（Icebergテーブルの所在をAPI経由で解決する標準規格）を介して、他クラウドのデータカタログをBigQueryやManaged Service for Apache Sparkから直接参照する仕組みである[1]。対象はAWS Glue、Databricks Unity Catalog、Snowflake Horizonの3つで、いずれも2026年8月時点でプレビュー提供となっている[1][2]。
これまで他クラウドのデータをBigQueryで分析するには、コピーを作る前提のETLパイプラインが必要だった。カタログフェデレーションでは、BigQueryがIceberg REST catalog経由で相手先のカタログに問い合わせ、データを移動させずに直接クエリを実行する[1]。
| 連携先カタログ | 提供元 | ステータス（2026年8月時点） | アクセス経路 |
|---|---|---|---|
| AWS Glue Data Catalog | AWS | プレビュー | BigQuery / Managed Spark |
| Databricks Unity Catalog | Databricks | プレビュー | BigQuery / Managed Spark |
| Snowflake Horizon | Snowflake | プレビュー | BigQuery / Managed Spark |
3社とも同時にプレビューへ入った点が今回の発表の特徴であり、特定ベンダーとの連携に限らずマルチクラウド構成そのものへの対応を打ち出している[1]。
特定クラウドへのロックインを避けつつ複数クラウドのデータベースを運用する構成パターンを解説しており、カタログフェデレーション導入後の構成設計に応用できる。
Cross-Cloud Interconnectと転送コストの構造変化
Cross-Cloud Interconnectとは、Google Cloudと他クラウドの間を専用線で結び、変動制の下り転送費用（エグレス）を発生させずにデータへアクセスできるネットワーク接続サービスである[1]。AWS上のデータへのアクセスにおいて、この専用線経由であれば変動エグレス費用がゼロになり、代わりに接続自体の利用料（時間課金）がかかる仕組みになっている[1]。
パートナー経由のCross-Cloud Interconnectは、1Gbpsから100Gbpsまでの帯域を定額サブスクリプションで契約できるモデルで提供されている[1]。データ量に比例して費用が変動するエグレス課金から、帯域に応じた固定費への切り替えが可能になる。
同じ発表でGoogle Cloudは、コスト最適化されたBigQuery組み込みAI関数でトークン消費が230分の1になっている顧客がいるとしている[1]。比較対象と測定条件は公開されていない。カタログフェデレーション自体の効果ではないが、クエリの実行方式を見直すことで処理コストが下がる余地があるという文脈で紹介されている。
数百人規模で自社LLM基盤や生成AIサービスをAWS上に構築し、年次予算策定サイクルを持つ企業のインフラ担当・調達担当が対象になる。GPUインスタンスを一定期間確保できるCapacity Block（GPUインスタンスを予約購入できるAW[…]
既存のETLパイプラインとどう役割分担するか
カタログフェデレーションは既存のETLを全面的に置き換えるものではない。プレビュー段階でありSLA（サービス品質保証）が未提供のため、日次バッチのような高頻度・低遅延の定型処理は当面ETLに残す判断が現実的である[1]。
一方、部門をまたぐ一時的な参照や、月次レポート作成時だけ他クラウドのデータを見に行くような探索的分析には向いている。コピーを作らない分、ストレージの二重持ちとデータの鮮度ずれという、ETL連携につきものの問題を避けられる。
| 観点 | ETLでのコピー連携 | カタログフェデレーション |
|---|---|---|
| データ移動 | 発生する（重複保存） | 発生しない |
| 変換処理 | パイプライン側で実施 | クエリ時にエンジン側で解決 |
| 適した用途 | 高頻度・低遅延の定型集計 | 部門横断の探索的分析・一時参照 |
| 提供状況（2026年8月） | GA（各社の既存機能） | プレビュー（SLA未提供）[1] |
既存パイプラインの棚卸しをして、更新頻度と参照範囲の2軸で仕分けるところから着手するのが妥当である。
数千人規模でAzure MonitorとDatadogを併用し、年次のコスト監査で監視ツール契約の妥当性を問われる企業のITインフラ担当者は、今回の発表を無視できない。対象はマイクロソフトのAzure Monitor、具体的にはSLI（サ[…]
日本企業のマルチクラウド稟議でこの選択はどう判断されるか
同じ状況は日本企業にも起きている。事業部ごとに異なるクラウド・分析基盤を導入した結果、全社横断のデータ活用が進まないという課題は業種を問わず共通である。
違うのは意思決定の経路である。米国企業がエンジニアリング部門の裁量でプレビュー機能を試せる場合でも、日本企業では複数クラウドにまたがる契約は情報システム部門単独で完結せず、調達・法務・セキュリティ部門を通す稟議が必要になることが多い。SIerに保守を委託している構成では、新規の接続経路を追加するだけでも保守契約の範囲外作業として見積もりが発生し、監査・内部統制の観点からアクセス経路の追加自体が承認対象になる。
| 観点 | 米国企業に多い進め方 | 日本企業に多い進め方 |
|---|---|---|
| プレビュー機能の試用 | 担当チームの裁量で先行検証 | 情シスが起案し稟議・承認を経てから |
| 複数クラウド契約の追加 | 既存契約の拡張で対応しやすい | 調達・法務・セキュリティの合議が必要 |
| 保守委託先との関係 | 内製比率が高く柔軟 | SIerとの契約範囲の見直しが先に必要 |
含意は二つある。IT部門は、プレビュー段階の今のうちに検証環境で対象データを絞った小規模検証を行い、稟議に必要な材料（用途・データ範囲・費用試算）を先に揃えておくべきである。決裁側は、GA（一般提供）移行の時期とSLA提供の有無を確認するまでは、本番の重要データ連携への適用を保留する判断が妥当である。
まとめ
IT部門の担当者は、まず既存のETLパイプラインを更新頻度と参照範囲で棚卸しし、カタログフェデレーションへの置き換え候補を絞り込むことが次の一手になる。決裁側は、プレビューのSLA未提供という制約と、Cross-Cloud Interconnectへの切り替えによる転送費用構造の変化を費用試算に反映したうえで、GA移行時期を見て投資判断を下すのが妥当である。マルチクラウド構成を前提にした基盤刷新は、機能の目新しさよりも自社の稟議プロセスと保守契約の実情に照らして進めるべき論点である。
よくある質問（FAQ）
Q. カタログフェデレーションはもう本番環境で使えますか。
A. 2026年8月時点でプレビュー提供であり、SLAが未提供のため本番の重要データ連携への適用は時期尚早である[1]。
Q. ETLはもう不要になりますか。
A. ならない。高頻度・低遅延の定型処理はETLに残し、部門横断の探索的分析にカタログフェデレーションを使い分けるのが現実的である。
Q. データ転送費用は必ず下がりますか。
A. Cross-Cloud Interconnect経由であれば変動エグレス費用はゼロになるが、代わりに接続自体の定額利用料がかかるため、自社のデータ量とアクセス頻度に応じた試算が必要である[1]。
出典
[1] Google Cloud, “Introducing the borderless Lakehouse”(2026-07-30) https://cloud.google.com/blog/products/data-analytics/introducing-the-borderless-lakehouse[2] itbrief.asia, “Google Cloud expands borderless Lakehouse across clouds”(2026-07-30) https://itbrief.asia/story/google-cloud-expands-borderless-lakehouse-across-clouds [3] Google Cloud Japan 公式X「Next Tokyo で Borderless Lakehouse 発表」（2026-07-30） https://x.com/googlecloud_jp/status/2082664481369280918
