Google Cloud Next '26 セッションいろいろ その1【イベントレポート】
こんにちは。サービス開発部の須澤です。
今回、ラスベガスで開催される Google Cloud Next '26 に参加するため、ラスベガスまでやってきました。
https://www.googlecloudevents.com/next-vegas
本記事では、私が参加したセッションについていくつか共有したいと思います。
関連記事はこちらです。
Google Cloud Next '26 イベントに参加するまで【イベントレポート】
Google Cloud Next '26 セッションいろいろ その2【イベントレポート】
Google Cloud Next '26 セッションいろいろ その3【イベントレポート】
Get real: Agents in the autonomous era
AIエージェントを作るのは、もはやそんなに難しくない時代になってきました。でも、それを本番環境で安全に・安定して・チームで管理しながら動かすとなると、話は一気に複雑になります。
Googleが今回のセッションで見せたのは、まさにその「その先」の話です。
エージェント基盤の4つの柱
複数のエージェントが連携して動くシステムを支えるのが、以下のアーキテクチャです。
Agent Gateway：エージェントの行動にポリシーを適用し、ガバナンスを担保
Agent Registry：エージェント同士が互いのスキルを発見・連携できるディレクトリ
A2Aプロトコル：エージェント間通信の共通規格
Agent Operability：監視・最適化・オブザーバビリティの統合管理
ラスベガスでマラソンを開催するAI
デモのテーマはユニークで、「ラスベガスでマラソンを企画・シミュレートする」というもの。3種類のエージェントがチームとして動きます。
PlannerエージェントがGoogle Mapsや各種データをもとにルートを設計
Evaluatorエージェントが「ちゃんと42.195kmになってるか」「地域への影響は？」を評価
Simulatorエージェントが仮想ランナーを動かして、実際に走らせてみる
面白いのは、エージェントが結果をテキストで返すだけでなく、地図上にルートを描画したり動的なUIを生成したりする点。A2UIというGoogleが公開した標準規格によって、画面まで作ってくれます。
エージェントに「記憶」を持たせる
一回きりの回答を返すだけなら、エージェントはステートレスでも困りません。でも実務で使うなら、過去の経験から学んで次に活かせないといけない。
今回紹介されたのは2つのアプローチです。一つはMemory Bank。過去のシミュレーション結果を長期記憶として蓄積し、次回の計画に自動で活用します。もう一つはAlloyDBを使ったRAG。「ラスベガスではラクダの通行に制限がある」みたいなローカルな情報を取得します。
AIがAIのバグを直す
デモ中、Simulatorエージェントが突然重くなるトラブルが発生。
ここで登場したのがCloud Assist（AIアシスタント）です。ログを収集・分析して原因を特定し、具体的な修正案まで出してくれました。
AIのデバッグをAIがやる、という光景がすでに現実になっています。
攻撃AIと防御AIがタッグを組むセキュリティ
Redエージェントが外部から実際にシステムを攻撃し、今回は認証バイパスの脆弱性を発見。「理論上の脆弱性」ではなく「実際に悪用できる」ことを証明した上で、攻撃の手順をまるごとドキュメント化します。
それを受けてGreenエージェントが修正案を提示。人間が承認すれば、コードに直接反映されます。
ペネトレーションテストからコード修正まで、ほぼ自動でループが回る世界、という感じです。
「作れる」から「運用できる」へ
AIエージェントはもう「作れる人だけのもの」じゃなくなってきています。次の課題は「どう運用するか」。作って終わりじゃなく、育てて、守って、管理する。その全体像を見せてくれたのが今回のセッションだったと思います。
3 quick wins across your small team with a unified AI workplace
スモールチームが抱える課題は、どの業界でも共通しています。「一人何役もこなさなければならない」「タスクが山積みで追いつかない」「データがバラバラで意思決定に時間がかかる」——これらの課題に対し、Gemini EnterpriseとGoogle Workspaceを組み合わせた具体的な解決策を提示しています。
実例①：問い合わせ対応の自動化
Workspace Studioを使い、受信した問い合わせに対して自動でドラフトメールを作成し、直近3つの空き時間を候補として提示する仕組みを構築。
実例②：クライアントブリーフの自動作成
Google Meetで録音→Geminiが文字起こし→自社のブランドスタイルを学習させたカスタムGem（AIエージェント）がブリーフを自動生成。さらにそのままWixのデザインツールに貼り付けるだけで、Webサイトの初稿が完成。
実例③：新しい収益源をその日のうちに立ち上げ
Notebook LMに通話の文字起こしをアップロードし、類似講座の調査・価格設定・カリキュラム案の作成を依頼。その日のうちに販売可能なワークショップの全体像が完成しました。
Gemini Enterpriseが実現すること
AIの本質的な価値は「既存の仕事を速くする」だけでなく、「これまで実現できなかったことを可能にする」点にある。このセッションはそのことを改めて示してくれました。
Build advanced AI applications with Spanner Graph
「AIの回答が信頼できない」「エージェントが的外れな判断をする」。その原因の多くは、AIに渡すデータの質と構造にあります。Googleが推進するSpanner Graphは、グラフデータベースの力でAIの精度を高め、大規模なエンタープライズ環境でも使える基盤として注目を集めています。
なぜ今、グラフなのか
グラフ構造のデータは、AIエージェントの「文脈理解」に非常に相性が良く、ハルシネーション（AIの誤った回答）を減らす効果があります。また、エージェントの長期記憶としても機能し、プロンプトの削減やコスト改善にもつながります。
Spanner Graphの特徴
従来のグラフDBが抱えていたスケール限界やメンテナンスコストを解消しつつ、以下の点で差別化されています。
SQLとGQLの併用：既存のSQLアプリを捨てずに、グラフクエリを段階的に導入できる
ベクトル検索・全文検索・グラフ検索の統合：一つのDBで複数の検索手法を使える
データの二重管理が不要：リレーショナルテーブルのデータをそのままグラフとして扱えるため、データ移行や同期の手間がない
99.999%の可用性：Cloud Spannerの堅牢なインフラがベース
実例①：Yahooのユーザーナレッジグラフ
10億人以上の認証済みユーザーと84億のプロフィールを持つYahooでは、以前はユーザーに関する簡単な問いに答えるだけでも1〜2日かかっていました。
Spanner Graphで個人ユーザーのナレッジグラフを構築した結果、AIエージェントの判断精度向上に加え、GDPRなどのプライバシー対応も大幅に簡素化されました。ユーザーノードを削除するだけで関連する300以上のデータセットにカスケード削除が走る仕組みです。
実例②：Targetのギフト探しAI
ギフト選びは「誰に」「何の機会に」「どんな関係性か」という複雑な文脈が絡み合います。Targetはこの課題にSpanner Graphを活用したコンバーサショナルなギフト探し機能を開発。構造化フィルターによる従来の仕組みから、自然言語で対話しながらグラフを横断して最適な商品を提案する仕組みへと転換しました。
結果として直帰率の低下・コンバージョン改善を達成し、わずか1シーズンでPoCから本番環境への移行を完了しています。
グラフは「AIに文脈を与えるインフラ」として、今後ますます重要な役割を担っていきそうです
おまけ
せっかくなので会場から少し離れた場所にあるTargetやFive Guysにも行ってみました。
お店はとてもよかったですが、メインストリートを外れると夜の雰囲気は緊張感あり。昼のうちに行くのがおすすめです。
