2026/04/28 ⼤栗 宗 ついに来た！ 本格的なマルチクラウド時代の Google Cloud 

⾃⼰紹介 2 ⼤栗 宗（@maroon1st） クラウド事業本部所属 ⽇系SIer → クラスメソッド → 某外資 → クラスメソッド (2回⽬) 最近クラウド⼆⼑流？エンジニアをやってます ● Google Cloud, AWS, Cloudflare, etc ● Google Cloud Partner Top Engineer 2023, 2024, 2025, 2026 ● Google Cloud Partner All Certification Holders 2025 

Agentic Enterprise 3 

⼈間と AI エージェントが共に働く企業 4 AI エージェントが企業データに基づいて⾃律的に動くためには、 データがどこにあっても活⽤できることが必要 Google Cloud 3 層 でマルチクラウド対応を発表 ● Network ● Analytics ● Transaction ロックインせず技術的な優位性で勝負する！という意気込みだと思っています 

3 層全部で揃ったマルチクラウド対応 5 ネットワーク層の相互接続 分析層の統合 トランザクション層の マルチクラウド Network Analytics Transaction Spanner Omni Cross-cloud Lakehouse (formerly BigLake) ● Partner Cross-Cloud Interconnect ● AWS Interconnect - multicloud 

Network 6 

Cross-Cloud Interconnect 双⽅向 GA 7 2025年11⽉に Google Cloud と AWS を簡単に直結する Interconnect を発表 Next 2026 直前に⼀般提供開始 2 拠点 4 ルーターの 4 重冗⻑を Google Cloud と AWS で事前設置 ● 作成と承認だけですぐに繋がる ● セットアップが数⽇から数分に ● 1〜100 Gbps をオンデマンド拡張 ● パフォーマンスとレイテンシが安定 

Partner Cross-Cloud Interconnect for AWS 8 対応リージョンは 5 ペア（⽶東 1 / ⽶⻄ 2 / 欧州 2）まもなくシンガポール？ ⽇本はまだなので早く来てほしい！！！ なお、オレゴンリージョンの AWS ↔ GCP RTT は約 10 ms でした。 Network Connectivity Center（NCC）も Preview 対応して Google Cloud で複 雑な VPC 構成でも簡単に AWS と接続可能になります。 クラウド間接続が Peer to Peer からマルチクラウド WAN へ進化！ 

ブログ書いてます 9 https://dev.classmethod.jp/articles/aws-and-google-cloud-aws-interconnect-multicloud-ga/ 

プレビューは Google Cloud メインでブログ書いてますよ！ 10 https://dev.classmethod.jp/articles/partner-cross-cloud-interconnect-for-aws-google-cloud-aws-preview/ 

Analytics 11 

BigLake から Google Cloud Lakehouse へ 12 2026 年 4 ⽉ 20 ⽇ 付で BigLake → Google Cloud Lakehouse に改称 2026 年 4 ⽉ 22 ⽇ に Cross-cloud Lakehouse が Preview Iceberg REST Catalog のメタデータを検出して、AWS の S3 データを⾼速かつ 低遅延でアクセスします。 今後 Snowflake、Databricks、AWS Glue にまたがるエンタープライズデータ を分析可能になります。 

Cross-Cloud Interconnect 13 オプションの Cross-Cloud Interconnect を活⽤して安定的な分析が可能に 

ブログ書いてます 14 https://dev.classmethod.jp/articles/cross-cloud-lakehouse-preview-bigquery-aws-iceberg/ 

Transaction 15 

Cloud Spanner ＝ NewSQL ＋ マルチモデル 16 分散 SQL を切り開いた NewSQL の代表的なサービス ● NoSQL の⽔平スケーリング ＋ RDBMS の ACID ＋ 外部整合性 ● Relational / Key-Value / Vector/ Graph の各種データモデル ● 全⽂検索にカラム型エンジン ● 可⽤性 99.999％ AI エージェントのコンテキスト基盤としても注⽬ 

なぜ「どこでも動く Spanner」が必要だったか 17 ● 事業継続性 ○ クラウドを超えた⾼可⽤性の確保 ○ 緊急時のクラウド撤退 ● データレジデンシー ○ データ主権を確保するためのオンプレミス戦略 ○ Google Cloud がサポートしていない地域での運⽤ ● マルチ / ハイブリッド クラウド戦略 ○ ポータビリティの確保 ○ 多数の環境に渡る⼀貫したソフトウェア ● Spanner に関⼼がある⾮ GCP 顧客 ○ ⾃⼰管理を好むユーザー ○ 他のインフラストラクチャーのみを利⽤している 

Spanner を⽀える技術 18 Spanner のコア技術 ● 環境に依存しない技術 ○ Paxos コンセンサス（2PC の単⼀障害点を補完） ○ ⾃動シャーディング ○ 同期レプリケーション ● Google に依存する技術 ○ Colossus → 抽象化レイヤー ○ TrueTime → 再構築 

Colossus 19 Colossus は Google のほぼすべてのプロダクトを⽀えるファイルシステム 依存を解消するため Colossus 相当の機能を提供する抽象化レイヤーを導⼊ ● ローカルファイルシステムの書き込み ● ネットワーク経由アクセス ● シャードの分割 ● シャードの再配置 Spanner Omni のストレージは SSD + ext4 が推奨 

TrueTime 20 TrueTime は ● 原⼦時計 ＋ GPS で⾼精度な時刻同期基盤を構築 ● 時刻を不確実性を含む区間として表現 [earliest, latest] ● Commit Wait : ε の幅だけ書き込みを待ってからコミット ● 外部整合性を保証 TrueTime は原⼦時計ではなく 区間表現 と Commit Wait が重要 不確実範囲が他のDB操作とオーバーラップするので パフォーマンスを損なわない 

デプロイパターン 21 ● 単⼀サーバー ○ 1 台のマシンで実⾏される単⼀のサーバーがあります。 ● 単⼀ゾーン ○ 単⼀ゾーンに分散された複数のサーバーで実⾏されます。 ● 単⼀ロケーション、複数ゾーン （レプリケートされたデプロイメント） ○ 1 つのロケーション内の複数のゾーンに分散された複数のサーバーで実⾏されます。 ● 複数ロケーション、複数ゾーン ○ 複数のロケーションと複数のゾーンに分散された複数の サーバーで実⾏されます。 単⼀サーバーなら簡単に試せます！ macOS 上でも 

やっぱり、ブログ書いてます 22 https://dev.classmethod.jp/articles/spanner-omni-google-cloud-next26/ 

DEMO 23 

Google Cloud がマルチクラウドに本気になった年 24 Google Cloud は「外に出る」選択をした ● ロックインから技術的優位性へ ● Network‧Analytics‧Transaction の 3 層全部 で 揃った本気度 ● Agentic Era がそれを必然にした 

No content