Google Cloud Next '26 の裏でこっそりリリースされたCloud Number Registry & Cloud Hub コスト分析 を試してみた

Transcript

1. Google Cloud Next '26 振り返り勉強会 Google Cloud Next '26 の裏でこっそりリリースされた Cloud Number Registry & Cloud Hub コスト分析 を試してみた 2026/04/28 渡邉 光
2. 渡邉 光（わたなべ ひかる） 所属：クラウド事業本部 コンサルティング部 役割：Google Cloud ソリューションアーキテクト 経歴 ITコンサル会社にて AWS / Google Cloud クラウドエンジニア 小売事業会社にて Google Cloud の CCoE クラスメソッドのアウトプット主体のカルチャーや Google Cloud ビジネスの拡大に興味を持ち、2025年10月に入社 資格 Google Cloud 認定資格 全冠 応用情報技術者試験 / LPIC Level 1/2 自己紹介 2
3. 1. はじめに 2. Part 1: Cloud Number Registry 3. Part 2: Cloud Hub コスト分析 4. まとめ アジェンダ 3
4. はじめに
5. Google Cloud Next `26 お疲れさまでした！ 今年のテーマは まさにAIエージェント時代で、AIが考えるだけでなく自律的に行動する時代への移 行を宣言したものだったかなと思います。中核発表は Gemini Enterprise Agent Platform で、 ADK・Agent Studio・Agent Memory Bank など、エンタープライズ向けエージェント開発・運用基 盤を一気通貫で提供するようなものが発表されました。 Gemini Enterprise Agent Platformの関連機能や、Cloud Runなどの主要サービスをテーマに登壇し ようとも考えたのですが、今回は、あえてAIエージェント関連のたくさんのリリースの裏で、こっ そりリリースされた2つのサービスについてお話したいと思います。 はじめに 5
6. Part 1: Cloud Number Registry
7. Google Cloud のネイティブ IPAM（IP Address Management）サービス Google Cloud 上の IP アドレス使用状況を一元的に可視化・管理できます。 （2026/4/22 Preview リ リース） 主にできること 機能 説明 IP 使用率の確認 サブネット・カスタム範囲ごとに使用率を可視化 空き IP の検索 指定プレフィックス長の空き IP 範囲を検索 IP リソースの検索 IP アドレス・属性で IP リソースを横断検索 こんな課題を解決する 複数プロジェクト・VPC が増えると IP 管理が困難に 「どの IP が使われているか」 「空き IP はどこか」把握できない 新規サブネット追加時の CIDR 重複リスク（VPC ピアリング・Shared VPC 環境で特に深刻） 従来はスプレッドシートで管理… Cloud Number Registry とは 7
8. Cloud Number Registry を理解するうえで、4つの主要リソースを把握しておく必要があります。 リソース 説明 IPAM admin scope 管理全体の起点。1組織につき1プロジェクト限定で設定。作成するだけで組織全体のリソースの自動検出が始 まる Registry book IP 管理情報をまとめる「台帳」 。admin scope 作成時に default が自動生成され、追加設定不要で使い始めら れる Realm 同一ルーティング境界内の IP 範囲をまとめる単位。VPC ネットワーク 1 つにつき 1 Realm が自動作成される Discovered / Custom range Discovered：リソース（サブネット・VM）から自動取得した IP 範囲 / Custom：オンプレミスや他クラウドの IP 範囲を手動で登録 主なリソースの概念 8
9. 主なリソースの概念 9
10. 組織（Organization） が設定されていること Cloud Number Registry 専用プロジェクトを用意すること（既存プロジェクトへの混在は非推 奨） IAM ロール： roles/cloudnumberregistry.ipamAdmin が必要 組織に対して IPAM admin scope を持てるプロジェクトは 1つだけ → 専用プロジェクトの作 成を強く推奨 Cloud Number Registryを触ってみる：前提条件 10
11. Cloud Number Registry 専用プロジェクトの Cloud Shell で gcloud コマンドを使って Cloud Number Registry API を有効 にします。 # 手順1: API の有効化 gcloud services enable cloudnumberregistry.googleapis.com 組織で Cloud Number Registry を構成できるプロジェクトは1つだけです。 同一組織内で既に設定済みのプロジェクトがないかgcloudコマンドを利用することで確認することができます。 # 手順2: 設定可能か確認（組織でまだ使われていないか） gcloud alpha number-registry ipam-admin-scopes check-availability \ --scopes=organizations/YOUR_ORG_ID \ --location=global AVAILABLE が返れば設定可能です。 UNAVAILABLE の場合は既に別のプロジェクトで設定済みになります。 scopeAvailabilities: - availability: AVAILABLE # ← これが返れば設定可能 scope: organizations/YOUR_ORG_ID セットアップ（手順1〜2） 11
12. IPAM admin scope を作成します。 # 手順3: IPAM admin scope を作成（ディスカバリー開始） gcloud alpha number-registry ipam-admin-scopes create my-ipam-scope \ --enabled-addon-platforms=gce \ # ← ここがポイント！ --scopes=organizations/YOUR_ORG_ID \ --location=global IPAM admin scope の作成ステータスは以下のコマンドで確認できます。 gcloud alpha number-registry ipam-admin-scopes describe my-ipam-scope \ --location=global READY_FOR_USE が表示されていれば、同期が完了し、Cloud Number Registry を使用できる状態になります。 createTime: '2026-04-23T22:57:45.199690103Z' enabledAddonPlatforms: - COMPUTE_ENGINE name: projects/*****/locations/global/ipamAdminScopes/my-ipam-scope scopes: - organizations/***** state: READY_FOR_USE updateTime: '2026-04-23T22:57:59.206255425Z' セットアップ（手順3） 12
13. 公式ドキュメントには --enabled-addon-platforms=COMPUTE_ENGINE と記載されているが、実際に 実行すると以下のエラーが発生しました。 ERROR: argument --enabled-addon-platforms: compute-engine must be one of [gce] ドキュメントと実装の乖離① 13
14. gcloud alpha number-registry ipam-admin-scopes create --help で確認すると、指定できる値 は gce とわかりました。修正して実行すると正常終了しました。 REQUIRED FLAGS --enabled-addon-platforms=[ENABLED_ADDON_PLATFORMS,...] Addon platforms that are enabled for this IPAM admin scope. Cloud Number Registry only discovers the IP addresses from the enabled platforms. ENABLED_ADDON_PLATFORMS must be (only one value is supported): gce Google Compute Engine. ドキュメントと実装の乖離① 14
15. ドキュメントには READY_TO_USE と記載されているが、実際のステータス値は READY_FOR_USE state: READY_FOR_USE # 実際の値（ドキュメントは READY_TO_USE と記載） 今回の検証で 2箇所 ドキュメントと実装の乖離を発見。Preview 段階のため今後修正される可 能性あり ドキュメントと実装の乖離② 15
16. # 手順4: Registry book の確認 gcloud alpha number-registry registry-books list --location=global createTime: '2026-04-23T22:57:46.704329908Z' isDefault: true name: projects/*****/locations/global/registryBooks/default updateTime: '2026-04-23T22:57:47.184329741Z' admin scope 作成と同時に default レジストリブックが自動生成される # 手順5: Realm の確認（VPC ネットワークごとに自動作成される） gcloud alpha number-registry realms list --location=global # VPC ネットワーク（内部 IPv4 ）のレルム — VPC ごとに自動作成 ipVersion: IPV4 trafficType: PRIVATE name: projects/*****/locations/global/realms/vpc-global-*****-***** # 外部 IP 用レルム — 固定で自動生成 name: projects/*****/locations/global/realms/google-owned-ipv4 trafficType: INTERNET trafficType: PRIVATE が VPC 内部レルム、 INTERNET が外部 IP 用レルム（google-owned-ipv4 / ipv6） 手順4 Registry book / 手順5 Realm の確認 16
17. 検出されたIP範囲について確認します。 gcloud alpha number-registry discovered-ranges list --location=global 組織内のサブネットやVMの内部IPが自動インポートされています。 # サブネット（test-subnet ）が自動インポート ipv4CidrRange: 192.168.0.0/24 attributes: - {key: rangeType, value: subnetwork} - {key: resourceName, value: projects/*****/regions/asia-northeast1/subnetworks/test-subnet} discoveryMetadata: resource: projects/*****/regions/asia-northeast1/subnetworks/test-subnet state: EXISTS --- # VM インスタンスの内部 IP も自動インポート ipv4CidrRange: 192.168.0.4/32 attributes: - {key: rangeType, value: instance} - {key: resourceName, value: projects/*****/zones/asia-northeast1-b/instances/vm01} parentRange: ...subnetworks-*****-primary-ipv4 # ← 親サブネットとのリレーションも記録 rangeType でリソース種別（subnetwork / instance）を区別。サブネット → VM IP の親子関係が自動で記録される 手順6 Discovered ranges の確認 17
18. 特定のサブネット範囲の IP 使用率を確認します。 gcloud alpha number-registry discovered-ranges show-utilization DISCOVERED_RANGE_NAME \ --location=global discoveredRange: ipv4CidrRange: 192.168.0.0/24 name: projects/*****/locations/global/discoveredRanges/compute-asia-northeast1-*****-subnetworks-*****-primary-ipv4 realm: projects/*****/locations/global/realms/vpc-global-*****-***** rangeUtilization: totalConsumed: '4' totalProduced: '256' usage: 0.015625 # ← 1.56% 項目 値 総 IP 数 256（/24） 使用中 IP 数 4 使用率 1.56%（ほぼ未使用） show-utilization を定期実行することでサブネット逼迫を先手で検知できる 手順7 IP 使用率の確認 18
19. 特定の Discovered range 内で空き IP 範囲を検索することができます。 # /28 （16 アドレス）の空き範囲を3 つ探す gcloud alpha number-registry discovered-ranges find-free-ip-ranges DISCOVERED_RANGE_NAME \ --cidr-prefix-length=28 \ --range-count=3 \ --location=global freeIpCidrRanges: - 10.0.0.0/28 - 10.0.0.16/28 - 10.0.0.32/28 新しいサブネットや VM を追加したいとき、空き CIDR ブロックをコマンド一発で発見できる 注意点：サブネット予約済みアドレス（ネットワーク・GW・ブロードキャスト）や停止中インスタンスのエフェ メラル IP も「空き」として含まれる場合がある 手順8 空き IP の検索 19
20. シーン 説明 大規模組織の IP 管理一元化 複数プロジェクト・VPC が混在する環境でも自動ディスカバリーで常に最新状態を維持 新規サブネット追加時の CIDR 重複防 止 find-free-ip-ranges で空き CIDR を一発確認。VPC ピアリング・Shared VPC 環境でのリスク 低減 IP 逼迫の早期発見 show-utilization を定期実行して使用率が高いサブネットを先手で検知 ハイブリッド環境での IP 管理 Custom range でオンプレ・他クラウドの IP 範囲も登録し一元管理 Cloud Number Registry の活用シーン 20
21. Part 2: Cloud Hub コスト分析
22. DevOps・SRE チーム向けの運用統合ダッシュボード — モニタリング・セキュリティ・コスト・メ ンテナンスを一画面に集約できるサービス。 Cloud Hub とは 22
23. Cloud Hubの最適化ページにGemini Cloud Assist のチャット機能が統合され、自然言語でコストに 関する質問や分析が行えるようになりました。 （2026/4/22 Preview リリース） 今回追加された機能 23
24. 最適化ページを開くと「Insights generated by Gemini (Geminiによる分析情報の生成)」セクシ ョンが自動表示されます。 Gemini 生成インサイトを確認する 24
25. 「4月23日に xxxxx@example.com によって vm01 と vm02 が作成された後、日次コストは 約 10倍に急増。新たに追加された Compute Engine リソースの vCPU 平均使用率はわずか 1.4%」 「Ask a follow up question」 をクリックするとチャットパネルが開き、追加質問を続けられます。 Gemini 生成インサイトを確認する 25
26. シナリオ 1：コスト急増の原因を調査する 26
27. シナリオ 1：回答② Gemini の詳細分析結果 27
28. Cost Analysis フル分析画面 28
29. セクション 内容 概要 コスト増加の原因サマリーと影響範囲 実施した調査 Gemini が行った分析（コスト推移・リソース特定・SKU 分析・監査ログ確認）の一覧 ワークロード別コスト vm01・vm02 それぞれの日次コスト（約 55.6 円/台） SKU レベル分析 E2 Instance Core / Ram など SKU 単位の費用内訳 ログデータとの相関 監査ログで確認した作成イベント（日時・実行者） 結論 レポートの結論 「Gemini can make mistakes」→ 最終確認は Billing レポート・監査ログで確認 Cost Analysis フル分析画面 29
30. 最もアイドル状態になっているリソースと削減できるコストの試算を教えて データをもとに 月次削減見込み額 を提示 シナリオ 2：無駄なリソースを特定 30
31. プロンプトのコツ ポイント 説明 1 質問 = 1 プロジェクト 複数プロジェクトの横断比較は非対応 日付範囲を明示 未指定は過去 7 日間がデフォルト。 2026-03-01 to 2026-03-31 形式でも指定可能 確認できる範囲 質問の種類 対応 月次コスト・特定リージョン・特定サービスのコスト コスト異常の根本原因分析・監査ログとの相関 オーバープロビジョニングリソースの特定 複数プロジェクト横断の比較 （1回1プロジェクトまで） プロンプトのコツと確認できる範囲 31
32. まとめ
33. Cloud Number Registry（Preview） 組織全体の IP を 自動ディスカバリーで一元管理 使用率確認・空き IP 検索・IP 横断検索が可能。多数プロジェクト・VPC ピアリング環境で特に有 用 現状は CLI のみ（コンソール UI は今後に期待） Cloud Hub コスト分析（Preview） Gemini Cloud Assist で 自然言語コスト分析が可能に コスト急増の根本原因を監査ログも含めて AI が仮説提示 まとめ 33
34. Cloud Number Registry ブログ: https://dev.classmethod.jp/articles/cloud-number-registry-preview/ 概要: https://docs.cloud.google.com/number-registry/overview Cloud Hub コスト分析 ブログ: https://dev.classmethod.jp/articles/cloud-hub-gemini-cloud-assist-cost-analysis/ Gemini Cloud Assist でコストを最適化: https://docs.cloud.google.com/hub/docs/optimize- gemini 参考リンク 34
35. ご清聴ありがとうございました！ 35