Google Cloudの新機能「ボーダーレス Lakehouse」— 他社クラウドのデータもコピーせず分析できる仕組み

Posted at 2026-09-02

はじめに

マルチクラウド環境でのデータ分析といえば、「S3やSnowflakeにあるデータをBigQueryで使いたいけど、コピーするとコストもかかるし鮮度も落ちる」という悩みが定番でした。2026年7月30日、Google CloudはNext Tokyoで「Borderless Lakehouse(ボーダーレス Lakehouse)」の機能強化を発表し、この課題への回答を打ち出しています。

本記事では、Google公式ドキュメント・公式ブログをもとに、ボーダーレス Lakehouseが何を解決する機能なのか、どういうアーキテクチャで動いているのか、実装面で何が必要になるのかを整理します。文中の番号は末尾の参考リンクに対応しています。

ボーダーレス Lakehouseとは

ボーダーレス Lakehouseは、ファイルを移行したり複雑なETLパイプラインを構築したりすることなく、Google Cloudから他のクラウドプロバイダに保存されているデータを直接クエリできる機能です。Lakehouse for Apache Icebergの一部として位置づけられており、BigQuery、スタンドアロンのApache Spark環境、Managed Service for Apache Sparkを使ってデータにアクセスできます。分析クエリだけでなく、連携データに対してAIを活用した分析情報とガバナンスも適用できるとされています。[1]

なお名称については変更があった点に注意が必要です。2026年4月20日付で、BigLakeは「Lakehouse for Apache Iceberg」に名称変更されました。BigLake metastoreは「Lakehouse ランタイムカタログ」という呼び方になっていますが、Lakehouse API、クライアントライブラリ、CLIコマンド、IAM名は変更されておらず、引き続き「BigLake」の名称で参照される点は紛らわしいので押さえておきたいところです。[2][3]

現時点(2026年8月)でこの機能はPre-GA(一般提供前)のステータスで、pre-GAサービス規約の対象となっています。「現状のまま」提供される機能であり、サポートが制限される場合がある点は留意しておく必要があります。[2][3][4]

なぜ今このタイミングで強化されたのか

Google Cloudの公式ブログでは、この機能強化の背景として「データレイクハウスの役割の変化」を挙げています。従来のデータレイクハウスは分析用の静的なデータ置き場でしたが、現在は常時稼働する自律型AIエージェントが、サプライチェーンの監視や異常検知、業務フロー実行などをリアルタイムで行う「アクションのためのシステム」としての役割を強めています。[5]

こうした常時稼働のAIエージェントを大規模に動かすには、エージェントが企業の全データにアクセスでき、かつ「どのデータをいつ使うべきか」という適切なコンテキストを持てることが不可欠です。しかし従来のデータ基盤では、高コスト・分断されたセキュリティ・弱いガバナンスがその実現の壁になっていた、というのがGoogleの課題認識です。[5]

アーキテクチャのポイント

公式情報を整理すると、ボーダーレス Lakehouseの技術的な特徴は大きく次の3点に集約されます。

1. Cross-Cloud Interconnectによるクロスクラウド接続

クラウドをまたいだ高度な分析やMLモデルのトレーニングには、これまで高額な下り(外向き)料金、ネットワークレイテンシ、脆弱なETLパイプラインといった「クラウド間の税金」が必要でした。ボーダーレス Lakehouseは、SLAで保証されたプライベートなPartner Cross-Cloud Interconnect接続を使うことで、AWSデータの変動する下り料金を回避しつつ、パブリックインターネットより安定した帯域幅と低いレイテンシを実現するとしています。[5]

2. カタログフェデレーション

連携カタログが更新間隔に基づいてリモートクラウドからメタデータを同期する仕組みが用意されています。[3] 対応するリモートカタログプロバイダには、AWS Glue、Databricks Unity Catalog、Snowflake HorizonのようなIcebergテーブルカタログが含まれます。これらを連携させることで、データはGoogle Cloudのユーザーやエンジンからローカルにあるかのように見える形で扱えるようになります。[6]

3. トランザクションデータベースまでの拡張

レイクハウスの世界はデータベースポートフォリオにも広がっており、Spanner Omni(Google Cloud外の環境でもSpannerを実行可能にする)や、AlloyDB向けLakehouse Federation(トランザクションシステムから直接データウェアハウスにクエリを発行可能にする)といった機能も合わせて発表されています。これにより、稼働中のトランザクションデータと過去データをコピーなしで一元的に分析できる、という設計思想です。[5]

実装面: 何が必要になるか

実際に構成する際は、以下のようなステップと前提条件が必要になります(Snowflakeを例にした場合)。

リージョン Secret Managerシークレット: シークレットベースの認証を使ってSnowflakeでボーダーレス Lakehouseを設定する際に必要になります。Personal Access Token(PAT)を使ったシークレットベースの認証と、Workload Identity連携(WIF)のどちらかを選択できます。[4]
エンドポイントの整合性: 例えばSnowflake Horizonはグローバルエンドポイントを使用しますが、ボーダーレス LakehouseではシークレットをLakehouseカタログと同じリージョンに保存する必要があるなど、リージョンをまたぐ設定の整合性に注意が必要です。[4]

構成後は、BigQueryの標準SQL、オープンソース版のApache Spark、Managed Service for Apache Sparkのいずれかからデータにアクセスできるようになります。[1] SQLで完結させたいチームはBigQuery側から、既存のSparkパイプラインを活かしたいチームはManaged Service for Apache Spark側から、というように既存のスキルセットに応じて入り口を選べる設計です。

トラブルシューティングで見えてくる実運用の勘所

公式のトラブルシューティングページからは、実運用でつまずきやすいポイントも見えてきます。連携カタログはメタデータを一定の更新間隔でリモートクラウドから同期する仕組みのため、共有・スキーマ・Namespace・テーブルといったリソースが多いほど同期に時間がかかることがあります。また、前回の更新が想定時間をオーバーした場合は今回の更新がスキップされ、次の間隔で再スケジュールされる仕様になっているため、「クエリしたデータが古く見える」という現象が起きた場合は、まずこのメタデータ更新のタイミングを疑うのが定石になりそうです。[3]

まとめ

ボーダーレス Lakehouseは、他クラウドのデータをコピーせずに直接クエリできるようにするGoogle Cloudの機能で、2026年7月のNext Tokyoで強化が発表された
背景には、データレイクハウスを「静的な置き場」から「常時稼働するAIエージェントのためのアクションシステム」へ進化させたいという狙いがある
Cross-Cloud Interconnect、カタログフェデレーション、Spanner Omni/AlloyDB Lakehouse Federationといった複数の技術要素で構成されている
2026年8月時点ではPre-GAのステータスであり、サービス規約や実運用上の制約(メタデータ更新のタイムラグなど)を踏まえた検討が必要

マルチクラウド構成でのデータガバナンスやAIエージェント基盤の設計を検討している方の参考になれば幸いです。

参考リンク

本記事は2026年8月時点の情報をもとにまとめています。ボーダーレス Lakehouseは現時点でPre-GAの機能であり、仕様が変更される可能性があるため、実際の導入検討時は必ず最新の公式ドキュメントをご確認ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up