はじめに

Day1のレポートに続き、Google Cloud Next Tokyo '26のDay2基調講演にも参加しました。Day1がGemini Enterpriseとそれを支える6つのレイヤーの全体像、および企業の活用事例が中心だったのに対し、Day2はインフラ・エージェント開発・データ・セキュリティといった各レイヤーを技術的に深掘りする内容でした。

本記事もDay1同様、講演内容を公開情報と照合しながら整理したレポートです。裏付けが取れなかった数値は「基調講演内で紹介された数値」として区別して記載します。

インフラ層：AI Hypercomputerの全体像

生成AIの普及とともにAIコンピューティングの需要は急速に伸び続けており、Google Cloudはハードウェアからモデル、エージェントを支えるプラットフォームまで、すべてのレイヤーを自社で手掛けてきたことを強みとして紹介しました。エージェント時代のコンピューティングはもはや1つのチップの性能だけでなく、データセンター全体で定義されるとして、クリーンエネルギーや大規模な冷却専用フロアといった要素まで含めて単一のシステムに統合したものが「AI Hypercomputer」だと説明されています。

顧客事例3社

Woven by Toyota（トヨタのモビリティ技術子会社）：交通事象の理解を進め、時空間にまたがるAIモデルの学習効率化に取り組んでいるとして紹介されました。同社は「Woven City AI Vision Engine」など独自の空間・時系列理解モデルの開発を進めており、Google Cloud上での学習効率化が言及されています
チューリング株式会社：完全自動運転の実現を目指し、自動運転向けのVLM（Vision Language Model）・VLAモデルの開発を進めている企業です。日本語特化のVLM「Heron-NVILA」の開発など、日本の道路環境に最適化したAI開発を進めていると紹介されました
SyntheticGestalt：約100億件の化合物データを学習した分子特化の基盤モデルをGoogle Cloud上で開発し、分子の分析・設計を高精度に行っています。経済産業省・NEDOの「GENIAC」プロジェクトの支援を受けており、将来的にはこのモデルをGoogle Cloud Marketplace経由で公開する計画もあるとされています

第8世代TPUとNVIDIA最新GPU

計算基盤としては、まずGoogle独自の第8世代TPUが紹介されました。学習向けの「TPU 8t」と推論向けの「TPU 8i」という、異なる要求に合わせて設計された2つのアクセラレーターを用意しているとのことです。

GPUについては、Google CloudはNVIDIAの最新世代「Vera Rubin NVL72」をいち早く提供するクラウドの一つになるとしています。実際、Google CloudはVera Rubin NVL72をA4 Ultraインスタンスとして提供する計画を明らかにしており、高速なインターコネクトにより、トークンあたりのコストで最大10倍程度の効率化が見込めるとされています。

汎用ワークロード向けには、カスタム設計のArm CPU「Axion」の展開も拡大しています。新しい「N4A」インスタンスは、同等のx86ベースインスタンスと比較して最大2倍の価格性能比、80%優れたワットあたりの性能を実現するとしており、この数値は公式ブログの発表内容とも一致します。汎用VM向けのArmベース「N4A」に加え、ネットワーク処理に優れた「C4」系、大容量メモリの「M4」系など、用途に応じた選択肢が広がっているとのことです。

ストレージとネットワークの再設計

チップの性能を引き出すため、ストレージも保存から読み込みまで再設計されているとの説明がありました。

Google Cloud Managed Lustre：業界をリードする並列ファイルシステムで、最大毎秒10TBのスループットを実現するとのこと。これはGoogle Cloud Next '26（グローバル版、4月）でDDNとの協業により発表された数値で、前年比10倍のスループット向上とされています
Cloud Storage Rapid：既存の大規模データを活用したいというニーズに向けて、読み込み性能が高くコスト効率にも優れたオブジェクトストレージの選択肢として紹介されました。単一ゾーンのバケットで毎秒15TBを超える読み込み帯域幅を実現するとされています
保存した瞬間から非構造化データに自動でインテリジェンスを付与し、AIエージェントが扱いやすい形にする機能も紹介されました

ネットワークについては、新しい「Virgo Network」が、13万4000個のチップを1つのファブリックに接続し、非ブロッキングで最大47ペタビット/秒の分岐帯域幅を実現するとされています。計算能力としては170万エクサフロップス規模という数値が基調講演内で紹介されましたが、公式資料では約160万エクサフロップスと紹介されており、近い水準の数値として捉えるのが妥当です。

運用面では、複数リージョンにまたがる25.6万ノード・100万チップ規模を単一のKubernetes準拠コントロールプレーンで管理する「GKEハイパークラスター」が、2026年4月のグローバル発表に続きTokyo版でも紹介されました。あわせて、ホットスナップショット機能によって起動処理などにかかる時間を大幅に圧縮できるとの言及もありました。

登壇者は、これらをコンピューティング・ストレージ・ネットワークが一体となった、AIの推論・学習のライフサイクル全体を加速するための専用設計のインフラだとまとめました。

エージェント開発：AntigravityからGemini Enterprise Agent Platformへ

続いて、Google Cloudの登壇者がAIエージェント開発の最新情報を紹介しました（発言中の名乗りが聞き取れなかったため、登壇者名は省略します）。

AIの進化によってエージェントを1つ作ること自体はかつてないほど簡単になった一方、デモレベルのエージェントと、実際の業務で成果を出せるエージェントの間には大きな乖離があると指摘されました。業務で成果を出すには、社内情報につながるMCP（Model Context Protocol）の用意、複雑な業務をこなすための複数エージェントの組み合わせ、誰でも同じように使えるフロントエンドの用意、想定外の事態に備えたガードレールなど、対応すべきことが多いといいます。こうした複雑さゆえに、エージェントは1人1人が個別に作るのではなく、プラットフォームを使って管理する必要があるというのが登壇者の主張でした。

デモ：購買エージェントの開発から本番運用まで

デモではまず、自然言語で要件を伝えるだけでエージェント開発を支援するツール「Antigravity」（Googleが2025年11月に発表したエージェント型IDE）を使い、社内向けの購買エージェントを開発する様子が示されました。

このエージェントをGemini Enterprise上で動かすと、これまでテキスト中心だったやり取りに対して、エージェント自身が文脈に応じてボタンや入力項目といったUIをその場で生成する様子が示されました。ノートPCの購買申請を例に、エージェントが在庫管理エージェントとA2A（Agent2Agent）通信を行って在庫を確認し、申請台数を調整、さらに予算管理のMCPを呼び出して部門予算の残額を確認したうえで申請を完了させる流れがデモされました。

裏側の仕組み：Agent Registry・Identity・Gateway

デモの後半では、この裏側の仕組みが解説されました。

Agent Runtime：エージェントをホスティングするサービス。今回のエージェントもここにデプロイされている
Agent Registry：複数のエージェントやMCPサーバーを一元管理する仕組み。レジストリに登録されていないエージェント・MCP以外とは通信できないよう制御されており、社内にどんなエージェント・ツールが存在し、どんな権限を持っているかを一覧できる
Agent Identity：すべてのエージェントに割り当てられるID。これがないと、どのエージェントがどのリソースにアクセスしたかを追跡できず、問題発生時に対象を止めたり影響範囲を調査したりすることができない。IDがあることで、アクセスを細かく制御し、権限を絞って問題の拡大を防ぐことができる
Agent Gateway：エージェントへの入出力の通信を管理する仕組み。ここにプロンプトインジェクション対策の「Model Armor」を組み合わせることで、不正な指示を検出してブロックできる。デモでは実際に、購買申請を無条件で承認させ、支払先を書き換えさせようとする攻撃を仕掛け、Model Armorがこれを検知してブロックする様子が示された
Agent Observability（トレース）：エージェントが何と通信し、どこにどれだけ時間がかかっているかを可視化する機能。デモでは購買エージェントの処理時間の内訳（在庫確認や予算チェックにかかった秒数など）が表示された

登壇者は、Antigravityで作ったエージェントをプラットフォームにデプロイすることで、スケーリングはAgent Runtimeが担い、UIはエージェント自身が生成するためフロントエンド開発が不要になり、エージェント間通信はMCP・A2Aが、権限管理はAgent Identity・Registryが、攻撃対策はModel Armorが担う構成になると説明しました。開発者が意識すべきは業務ロジックそのものだけになる、というのが要点です。

公共部門の事例：GovTech東京「東京アプリ」

続いて登壇したのは、GovTech東京の業務執行理事兼CTOを務める井原正博氏でした。同氏は民間のテクノロジー企業でサービス開発や組織立ち上げに携わってきましたが、2024年1月、妻の実家がある能登半島で地震により被災し、行政サービスや情報にアクセスできない不安を自ら経験したことが、行政のデジタル化に携わる転機になったと語りました。

GovTech東京は、東京都と都内62区市町村と連携して行政のデジタル化を推進するために設立された組織です。井原氏は同組織の特徴として、開発を外部に委託しきるのではなく、自分たちで設計・開発・運用する「内製開発」にこだわっている点を挙げました。開発したソフトウェアを東京都だけのものにせず、他の自治体でも活用できる形で公開していく方針も紹介されています。

東京都公式アプリの要件とCloud Spanner選定理由

内製開発の中心にあるプロジェクトが「東京都公式アプリ（東京アプリ）」です。2025年2月にリリースされ、現在は600万ダウンロードを超え都民の生活に浸透しつつあるといいます。今後は、行政手続き・防災・子育てなど、あらゆる行政サービスの入り口となる、1000万人規模のユーザーに対応するアプリへの拡張を目指しているとのことでした。

このスケールのアプリを実現するにあたり、井原氏は次の3つの要件を軸にアーキテクチャを検討したと説明しました。

いかなる状況でも安定して動作すること。特に災害時に必要とされるサービスほど安定性が重要
データがリアルタイムに整合していること。行政サービスとして届ける情報に矛盾があってはならない
自分たちのチームが主体的にコントロールできる、内製開発向きの技術スタックであること

この3点をもとに技術選定を行った結果、Google Cloudを、データベースにはCloud Spannerを採用したと述べました。日本の行政組織がCloud Spannerを本番採用する事例はまだ少ないとしながらも、1000万人規模の書き込みスケールと強い整合性を両立する要件を満たす選択として評価したとしています。先行事例が少ないこと自体は懸念材料ではなく、内製開発組織として自分たちで判断し責任を持てる体制があるからこそ選べる選択肢だと位置づけました。

井原氏は最後に、目指しているのは1つのアプリではなく、巨大都市において住民が必要な時に必要な行政サービスに確実につながるための公共デジタル基盤であるとし、東京での取り組みを他の自治体にも広げていきたいと締めくくりました。

データ層：エージェンティックデータクラウドのデモ

続いて、架空の企業「シンバルフード」のマーケター視点で、Google Cloudの「エージェンティックデータクラウド」機能を紹介するデモ映像が上映されました。「シンバル（Cymbal）」はGoogleのデモでたびたび使われる架空ブランド名で、Day1のGoogle Picsデモに登場した「シンバル社」と同じ系列と考えられます。

デモのシナリオは、SNSで話題のジェラートを海外市場へ展開したいというもので、通常であればトレンドを捉えてから実際のビジネス指標を検証するまでに数週間かかる工程を、エージェントを使って数分に短縮するという内容でした。

最初の壁として挙げられたのが「データの散らかり」です。原材料データはPDFで、購買データはAWSとBigQueryにまたがって存在するという、クラウドをまたいだ非構造化・構造化データの混在状態から始まります。

デモでは、Geminiがクラウドストレージ上のPDF（原材料表とサプライヤーの規格書）を読み込み、両者のつながりを自動的に見つけ出し、構造化データに変換するSQLをその場で生成しました。続いて、AWS S3にあるデータをBigQueryの外部テーブル（フェデレーテッドクエリ）として登録し、データを物理的に移動させない「ゼロコピー」の形でBigQuery側のデータと結合、これらをナレッジグラフのノードとして追加しました。この基盤をもとに、自然言語で問い合わせに応答するデータエージェントを作成し、地域・顧客セグメントを絞ったキャンペーンのコンバージョン予測やROI予測をシミュレーションし、報告用スライドの自動作成までを一気通貫で行う様子が示されました。

登壇者は、これを「PDFなど気付きにくいデータを読み解く力」「AWSなどクラウドの壁を越えたデータ活用」「自然言語で使えるエージェンティックなツール」の組み合わせによって、データに基づく意思決定のインテリジェンスを進化させる取り組みだとまとめました。

マーケティング事例：NTTドコモの「フルAIマーケティング」構想

NTTドコモからは、マーケティングプロセスをゼロベースでAIを使って再構築する「フルAIマーケティング」構想が紹介されました。同社はさまざまなサービスの提供を通じて顧客一人ひとりとの関係を深め、ロイヤルカスタマーの母数を拡大していくことを事業成長の軸に据えているといいます。

課題として挙げられたのが、施策のバリエーションの多さです。ドコモには1億人を超えるdポイント会員がおり、顧客の特徴を表すプロファイルは2000種類を超え、サービスラインナップも多様です。サービス横断で1人ひとりに最適なカスタマージャーニーを設計しようとすると、検討すべき組み合わせは膨大になり、人手による検証を繰り返すのは現実的ではないといいます。

そこで、AIエージェントを使ったマーケティングエンジンの構築を進めているとのことでした。必要になるデータとして、顧客理解のためのデータ、施策設計のロジック、過去の施策結果・検証結果、事業のルールの4種類が挙げられ、これらを統合してAIが施策を判断・実行する仕組みを目指しているといいます。あわせて、AIが現場の担当者にも納得感のある精度の高い施策を実行するには、マニュアルやドキュメントに含まれる実践知をAIに取り込む必要があるとして、社内向けデータプラットフォームを通じて、業務に特化したデータ活用人材や利用ログから蓄積された実践知を、AIが扱える形に構造化する取り組みが紹介されました。

Google Cloudを選んだ理由としては、1億人規模・2000種類超のプロファイル・月間160億回を超える顧客アプローチという大規模な定常データに加え、顧客の声や営業担当者による非定型データまでを一つの基盤で統合的に扱える点、そしてデータ基盤に生成AIが組み込まれており、分析から施策実行までを複数のツールに分断せずワンストップで進められる点が挙げられました。

同社はこの基盤の上で、施策設計や意思決定支援だけでなく、クリエイティブの作成・審査・検証まで複数のエージェントをつなぎ合わせて運用する計画を持っているとし、セキュリティを保ちながら安定的に稼働させる基盤としてGemini Enterprise Agent Platformの活用を検討しているとのことでした。2027年をめどに「フルAIオペレーション」の実現を目指しており、目的はマーケティングの単純な自動化ではなく、多様なサービスを顧客一人ひとりの日常により自然に、より価値ある体験として届け続けることだと締めくくりました。

セキュリティ：Big SleepからCodeMender、AI Threat Defenseへ

最後のセッションはセキュリティです。登壇者はまず、AIが自律的に脆弱性を見つけ出す能力が顕在化しており、脆弱性が発見されてから悪用されるまでの時間は1.6日にまで圧縮されていると指摘しました（この具体的な数値は基調講演内の言及で、公式資料での裏付けは確認できませんでした）。

Googleはこの状況を、AIの進化を見越してあらかじめ備えてきたことで乗り越えられるとしています。同社は2023年、脆弱性をAIで発見する研究プロジェクト「Project Naptime」を開始し、その後DeepMindとの共同プロジェクト「Big Sleep」に発展しました。Big Sleepは2024年、広く使われるオープンソースのデータベースエンジンSQLiteにおいて、AI単独でゼロデイ脆弱性（未知の悪用可能な脆弱性）を発見するという世界初の事例を達成しています。

さらに2025年には、AIによる脆弱性発見のスピードにコード修復が追いつかないという課題を解決するため、自動コード修復エージェント「CodeMender」を開発・発表し、2026年7月にプレビュー提供が始まりました（Day1の記事でも触れた内容です）。CodeMenderは複数のモデルを選択できる仕様になっており、その選択肢の一つが、Gemini 3.5 Flashをベースにセキュリティ業務に特化させたカスタムモデル「Gemini 3.5 Flash Cyber」です。

登壇者は、攻撃者が持てる情報は外部から観測できる範囲に限られる一方、防御側は資産の所在やシステム構成、アプリケーションの本来の目的など、はるかに多くのコンテキストを持っているとして、このコンテキストの非対称性こそがセキュリティチームにとっての強みになると説明しました。この強みを活かすために、Googleが社内で実践してきた「準備」「スキャンと優先順位付け」「修復」「監視」の4ステップを統合的に提供するのが、Day1でも紹介された自律型セキュリティソリューション「AI Threat Defense」です。

デモ1：Wizによるリスクの可視化と優先順位付け

まず、Google Cloudのセキュリティ企業Wiz（AI Threat Defenseの構成要素の一つ）の担当者によるデモが行われました。マルチクラウド・マルチ環境をエージェントでスキャンし、利用しているAIの資産（AIエージェント、モデル、MCPサーバーなど）を検出・可視化し、ガードレールの設定ミスや、実際に行われているプロンプトインジェクションなどの攻撃（ランタイム上の異常）も検知します。

デモでは、1件1件のリスクを個別に見るだけでは本当に優先すべき対応が判断できないとして、複数のリスクの「組み合わせ」に注目する手法が示されました。具体的には、Pythonで開発されたチャットボット型AIエージェントが、機密データ（メールアドレスやクレジットカード番号など）を含むCloud SQLデータベースにアクセスできる権限を持ちながら、インターネットに公開されている状態がグラフ構造で可視化されました。この状態が本当に危険かどうかを実際に検証するのが「Red Agent」で、様々な手法でシステムへの攻撃を試行し、このケースではチャットボットAPIの認証バイパスの脆弱性を発見、実際に機密データの取得に成功する様子が示されました。これにより、数あるリスクの中から最優先で対応すべきものが特定されたことになります。

問題の修復を提案するのは「Green Agent」で、根本対応（認証ロジックの修正）に加えて、暫定対応としてファイアウォール設定の変更などをその場で提案します。あわせて、GitHubリポジトリのソースコードをスキャンした結果検出されたSQLインジェクションの脆弱性についても、そのコードから生成されたコンテナが実際にどの環境で稼働し、どのURLでインターネットに公開されているかまで関連付けて可視化する様子が示されました。

デモ2：CodeMenderによるコード修復

Wizのデモに続き、Google Cloudの担当者からCodeMenderのデモが行われました。Wizが未知の脆弱性ではなくパターンマッチング的な検知にとどまるのに対し、CodeMenderは熟練したセキュリティエンジニアのような考え方で未知の脆弱性を検出できる点が違いだと説明されました。

デモでは、CodeMenderに脆弱性の検索・修正パッチの作成・適用という3つの指示を与えるだけで一連の対応が完了する様子が示されました。モデルは選択可能で、先述の「Gemini 3.5 Flash Cyber」も選べます。今回のデモでは複数のファイルから構成されるCコードを題材に、コードの処理の流れを追跡しないと発見できない脆弱性を、エージェントが順を追って確認していく様子が上映されました。

まとめ

Day2の基調講演は、Day1で示されたGemini Enterpriseの全体像を、インフラ・エージェント開発・データ・セキュリティという各レイヤーで深掘りする内容でした。TPU 8t/8i、Vera Rubin NVL72、Axion N4Aといったハードウェアから、Managed Lustre・Cloud Storage Rapid・Virgo NetworkといったI/O層、Antigravityやエージェントプラットフォームの各コンポーネント（Registry・Identity・Gateway・Runtime）、そしてBig Sleep・CodeMender・AI Threat Defenseに至るセキュリティ層まで、Google Cloudが自社開発している技術スタックの厚みを軸にした構成だったと言えます。

GovTech東京とNTTドコモの事例は業種こそ異なりますが、どちらも大規模なデータを一つの基盤に統合し、AIエージェントに広く権限を持たせすぎずに活用するという設計思想が共通していました。エージェントの利便性と安全性をどう両立させるかは、Day1・Day2を通じて基調講演全体を貫くテーマだったといえそうです。

参考（Day1と重複しない、Day2で新たに参照した情報源）