Google Cloud Next 2026 最終日 -使うことありそうな3本

こんにちは、ちゅらデータのエンジニア倉富です。

最終日は、Keynoteもなく午後2時で閉幕、Lightning Talk中心の半日でした。

Breakoutのリストを眺めてみると、Iceberg・ Cloud Run ・ Coding Agent と自身の業務で使いそうな3本のコンテンツが並んでいたので、これだけは聞いて帰ろうと決めて、朝から会場に入りました。ただ少し疲れ気味だったので、開始時間まではPartner Summitの会場でゆっくりしていました。ここは弦楽器を弾いている人がいて、ちょっとした異空間です。

（1） Unified Iceberg: Open standards, native performance

「Unified Iceberg: Open standards, native performance」というBreakoutに入りました。 Google Cloud のVice President of Data and Analyticsである Yuriy 氏のセッションです。冒頭で「過去1年間で、Apache Iceberg形式のデータが約3倍に伸びた」というトピックが紹介され、会場が「そうだよね」という空気で包まれていました（そうなの？）。

ただ、Icebergで本番運用に乗せようとすると、エンタープライズ品質の価格性能のためにメタデータ管理やコンパクションの実行、リアルタイム分析のために専用インフラを構築する必要があるため、大変だという話をされたうえで、その課題整理から話を始めていました。

去年 Google が手を打ったのが、 BigQuery のManaged Iceberg Tables、Iceberg REST Catalog、 BigQuery からIcebergへの最適化、マルチテーブルトランザクションといったあたりです。

ただし、「self-managed tables vs fully-managed experience」の二択は残っていました。Iceberg REST Catalogでオープンソースエンジン中心にETLを組むと、 BigQuery の機能との相互運用という制限が残っていました。

今年の発表が、

Iceberg REST Catalog tables are up for preview for full write and read interoperability with BigQuery and any Iceberg compatible engines like Trino, Spark and others.

Iceberg REST Catalogのテーブルが、 BigQuery とTrino/Sparkといった任意のIceberg互換エンジンとの間で、完全な書き込み/読み取りの相互運用ができる状態でPublic Previewになりました。今までの2種類のテーブル形式が、どちらの用途も1種類のテーブル形式でカバーできるようになります。

加えて発表されたのが、

• ・自動テーブル管理（コンパクション/メタデータ整理が自動）
• ・ BigQuery のストリーミングインフラ（Write API、数十GB/秒）が、Iceberg REST Catalog tablesで使える
• ・マルチステートメントトランザクションおよびCDCがIceberg上で動作

TPC-DSベンチマークで実行時間が2倍短縮です。

また、製品の改名も一気に進んでいました。Parth氏のデモ中で「Iceberg REST catalog, which was previously called BigLake 」と説明されていたので、私はてっきり BigLake がIceberg REST Catalogに改名されたのかと思ってメモしていたのですが、公式ドキュメントを確認したところ、正しくは下記でした。

• ・ BigLake → Google Cloud Lakehouse
• ・ BigLake metastore → Lakehouse runtime catalog
• ・Dataproc Serverless → Managed service for Apache Spark（オープンソースSpark比4倍性能）
• ・ Vertex AI → Gemini Enterprise Agent Platform

参考： Google Cloud Lakehouse 概要 – Google Cloud Documentation

毎度のことながら Google Cloud のリブランディングは、正直混乱してしまいます。「 BigLake 」で検索して出てくる古い記事と、「 Google Cloud Lakehouse 」で検索して出てくる新しい記事が並走している期間がしばらく続きそうです。APIやCLI、IAM名が引き続き BigLake のままなのは Google Cloud の思想に基づくものでしょう。

それでも、 BigLake から Lakehouse + Iceberg RESTという、業界標準寄りの名前に振ったことは象徴的だと思います。 Cloud Composer やDataprocもOSSの名前をサービス名に入れるようになってきているので、今回のリブランディングもその方針なのでしょう。

もう一点、実務で活用できそうなのが、 Zero-copy Parquet → Iceberg 変換です。今までParquetで組んだデータレイクを、Icebergに移行するには、変換ETLを組む必要がありましたが、UI上でin-placeで変換できるようになります。ETLパイプラインを減らせるならば、ありがたい話です。

Parth氏のデモでは、Sparkユーザーと BigQuery ユーザーが同じIcebergテーブルを共有して、SparkでINSERTしたデータが BigQuery 側からstrongly consistentに見えること、object tablesで非構造化データを結合、Conversational Analytics Agent（Gemini 1.5 Pro）で自然言語クエリ、といった内容が順に流れていました。「エンドユーザーから見ると、これがオープンソース形式で管理されていることに気づかない」という話でした。

（2）Architect zero-trust security with Cloud Run

最終日の午後は Cloud Run のセキュリティ系セッション「Architect zero-trust security with Cloud Run 」に参加しました。 Cloud Run で認証や通信まわりが楽になる話でした。地味ですがありがたい話です。

IAPが Cloud Run に直結（GA）- ロードバランサーとお別れ

特に私が嬉しかったのが、次の点です。

Identity-Aware Proxy（IAP）が、 Cloud Run のサービスに直接有効化できるようになりました。

この機能はGAされています。

今までは「社内ユーザーだけ通したい」という要件だけでも LB + Serverless NEG + IAP一式を組む必要があり、手間もコストもそれなりにかかっていました。それがサービス設定で済むようになります。Workforce Identity Federationとの直接統合もあって、外部への限定公開もやりやすいです。

Preview期間中は「社内で開発中のものをチームに共有する」など、限定的な用途でしか使えていなかったのですが、GAになったので、お客さまの案件でも要件によっては選択肢として使えそうです。社内ツールや軽めの認証付きアプリであれば、これで十分対応できます。

Service Bindingでサービス間通信が「2クリック」に（Coming Soon）

もう一つのハイライトが、サービス間通信です。 Cloud Run 同士で内部通信を組むときに、これまでは認証用のOIDCトークンをアプリ側で取得・付与するコードを実装し、ネットワーク側でVPCコネクタも設定する、という作業を毎回繰り返してきました。これが Service Binding で大幅に楽になります。

gcloud network-services service-bindings create --source=$FRONTEND_URI --destination=$BACKEND_URI

これだけです。アプリ側のトークン取得コードは不要、裏で Google マネージドのサイドカーがOIDC JWTを自動注入してTLS暗号化、Golden signalsの収集まで全部やってくれます。

エンタープライズ向けにはもう一段ガッツリした Cloud Service Mesh（Public preview） も並んでいて、L7 traffic managementやGKE/GCEとのクロスランタイムルーティングまで欲しい人はこちら。

おまけ: Agent Identity（Coming Soon）

エージェント関連は4つすべてがComing Soonで、まだ触れる段階ではないですが、Agent IdentityがSPIFFE identity（業界標準のサービス間ID仕様）で割り当てられるのは押さえておきたいポイントです。オープンな認証を使えるようにして、 Cloud Run をエージェント実行プラットフォームとして利用できるようにしようとしているのでしょうか？

（3）Accelerate CI/CD with Coding agents

最後は「Accelerate CI/CD with Coding agents」です。タイトルだけ見ると「また、Coding Agentの話か」と思いますが、実際は （1）で出てきたIceberg基盤一式（REST Catalog、Service Account、IAM、GCSバケット）を、 Coding Agent がTerraformで一気に構築するという運用デモでした。（1）の延長線上の話です。

ソリューションは Coding agent + GCPの拡張機能（extension）です。ベストプラクティスをレシピ集（テンプレート）としてextensionに事前に組み込み、エージェントは「自由に判断する」のではなく「レシピをdiscoveryして適用する」設計で、ガードレール付きのエージェントです。デモでは、Iceberg REST Catalog → Service Accounts → IAM Roles → Cloud Storageバケット → トークン管理をTerraformで一気にプロビジョニングしていて、生成プロセスがTerraformとして残るので人間がレビューでき、別環境への再適用もできます。「エージェントが作って終わり」ではなく「エージェントが作ったコードが残る」のがポイントです。

なぜこの方向性なのか、背景の数字が気になりました。

• ・AI生成コードの増加で、exposed secretsが前年比34%増
• ・複雑なインフラがIAM権限の過剰付与やセキュリティゲートのバイパスを誘発
• ・CI/CDパイプラインはサプライチェーン攻撃の格好の標的

AIでコードを書く量が増えれば、シークレットがGitHubに混入する確率も上がります。「AIを使う」と「シークレットを漏らさない」の二つを両立させるには、シークレット管理の仕組み自体を強くするしかないというのが問題認識でした。そのため、「自由にコードを書くエージェント」ではなく、「ベストプラクティスを組み込み済みのextension付きエージェント」という方向性のようです。

このレシピ集、もしかして Application Design Center（Public preview）のことかな？という気もします。あらためて調べてみようと思います。

参考：Application Design Center 概要 – Google Cloud Documentation

Q&Aも実務的で、「Snowflake/Databricks Unity Catalog とどう違う？」「スキーマ進化はどう扱う？」など、現場で必ず出る質問への答えが揃っていました。特に「Icebergを物理的な真実、各エンジンを論理的なビュー」として扱うアーキテクチャは、複数プラットフォーム横断のデータ基盤構築の提案で活用できる話です。

まとめ

 Google Cloud Next 2026 最終日は、業務に使えそうな話を3本聴きました。

整理すると、

• ・Icebergで、エンジン横断で扱える統一データ基盤を作る
• ・ Cloud Run Zero-trust で、その上のアプリやエージェントを安全に動かす
• ・ Coding Agent で、その基盤と守りの構成を自動構築する

Developer Keynoteで紹介されたマルチエージェントシステムを本格的に構築する機会はまだ多くないと思いますが、その土台になる機能は着実に揃ってきている印象でした。

これらの機能は、エージェント前提の構成でなくても、現行の開発に活用できそうなものも多くあります。Iceberg基盤も Cloud Run のIAP直結もService Bindingも、普通のWebアプリやデータ基盤の開発において十分役立ちます。

細かい検証ポイントは色々ありますが、GAやPreviewが触れるようになったら順番に見ていきたいと思います。

3日間お疲れさまでした。それでは、また。

※Google Cloud および Google Cloud 製品・サービス名称は Google LLC の商標です。

（本記事の内容は、2026年4月時点の情報に基づいています）