[Google Cloud Next '26 Las Vegas] 自律型 SRE の拡張：Gemini Enterprise Agent Platform 上の Agent Runtime の活用

Google Cloud Next '26 Las Vegasとは

Google Cloud Next '26は、2026年4月22日から4月24日の3日間、アメリカ・ラスベガスのMandalay Bayにおいて開催されるGoogleのクラウドサービスに関する世界最大級のイベントです。「ディープ ラーニング、刺激的なセッション、共同での問題解決など、充実した 1 週間になることでしょう。業界の専門家や、あなたと同じ課題や機会に直面している同業者から直接学ぶチャンスです。Next 26 を終える頃には、他では得られない斬新なアイデア、最先端のスキル、行動につながる知見を身につけていることでしょう。」と銘打っており、AIコンテンツで大いに盛り上がった昨年や一昨年にも勝るとも劣らないイベントとなることが期待されます。

私たちNTTインテグレーションも、Google Cloudに精通した専門家として、技術イノベーションの最新動向を取り入れ、顧客に対するソリューション提供に活かしていくことを目指して参加しています。

このような貴重な機会ですので、現地からいち早くブログで最新情報や熱量を発信してまいります。

本記事で紹介するセッション概要

• 講演日時：2025年4月23日 4:00 - 4:45 GMT-7
• セッションタイトル：Scaling autonomous SRE with Agent Runtime on Gemini Enterprise Agent Platform
• 登壇者
  • Cedric Yao
    • グーグルクラウドの GTM 部門 アプリケーションイノベーションプログラム責任者
  • Afrina M
    •  グーグルクラウドのシニア製品マネージャー
  • Mir Islam
    • PayPal の AI Ops&SRE ディレクター
• セッション内容のサマリ
  • グローバル決済業界のリーダー企業は、コードスピードでインシデントにどのように対応しているのでしょうか？このセッションでは、PayPalがGemini Enterprise Agent Platform上のAgent Runtimeを使用して、自律的なサイト信頼性エンジニアリング（SRE）エージェントプラットフォームを構築し、拡張した方法をご紹介します。PayPalのアーキテクチャは、本番環境のオブザーバビリティスタックと直接統合され、インシデントの検出、分析、解決を行います。このシステムによって、平均修復時間（MTTR）と手作業に費やす総時間の両方を大幅に削減できた経緯を解説します。マルチエージェントループのアーキテクチャから、大規模な自律的修復に必要なガバナンスまで、本番環境における導入プロセスを詳しく見ていきます。

なぜこのテーマが重要か

システムが複雑化するほど、それを支える SRE の負担も同じ速度で増えていきます。セッション内で Mir 氏が紹介した 2025 年のレポートによれば、AI やオペレーション向けツールへの投資を増やした企業でも、運用上の toil は減らなかった。「むしろ、AI が何をしているかを確認するダッシュボードが増えた分だけ、負担は増えた」というのが実態だったそうです。問題の根っこはツールの数ではなく、それらを束ねるオーケストレーションの欠如にあることが話されていました。

PayPal はその問題が最も先鋭化した例のひとつです。

PayPal は世界最大の決済処理業者のひとつです。毎分 500 万ドルの収益がシステムを流れ、3,000 のマイクロサービスが稼働し、1 日に 25 億回の API インタラクションが発生し、年間に 1,050 万件の本番変更が走ります。「私たちに失敗は許されない」と Mir 氏は言います。

しかし、その裏側で誰も語らないことがある、と続けました。信頼性を維持するためには膨大な人的努力が必要であり、SRE と本番エンジニアは燃え尽き寸前となっているそうです。

PayPal が直面していた課題は複合的なものでした。繰り返しの手動トリアージによる集中力の低下、オンコールシフト交代のたびに失われるコンテキスト、遅延する RCA ドキュメント、深夜対応による燃え尽き。そして最も大きかったのは、インシデント対応の 70% の労力がデータ収集と手動での相関分析に費やされていたことです。

「問題はツールが足りないことではない。オーケストレーションが欠けていることだ」と Mir 氏は整理しました。

セッション内容

エージェントを構成する 3 つの要素

Cedric Yao 氏は最初に、エージェントの概念整理から入りました。

エージェントには 2 つの見方があります。ひとつは「あなたの代理として動くエージェント」。もうひとつは「成果物としてのエージェント」、つまり ADK や LangGraph といったフレームワークを使って構築・デプロイするソフトウェアとしてのエージェントです。このセッションで扱うのは後者です。

効果的なエージェントを構成する要素として、Cedric 氏は 3 つを挙げました。

Models（モデル）は、さまざまな能力・特性を持つ多数のモデルの中から、タスクに最適なものを選べる柔軟性のことです。「100 人のインターンを採用したとして、全員が同じスキルセットである必要はない」という比喩で表現されていました。

Context（コンテキスト）は、新しいインターンを組織のやり方に習熟させるように、エージェントに組織固有のコンテキストを与える仕組みです。「このサーバーが不調なとき、シャットダウンしてもいいか？」という判断ひとつとっても、コンテキストがなければ正しく動けません。

Tooling（ツーリング）は、オーケストレーション、デプロイの仕組み、エージェントの監視・評価まで含む広い概念です。「返ってきたインターンたちをどう管理するか」というメタファーで語られていました。

PayPal の自律型 SRE プラットフォーム

まず「データがどこにあるか」を理解すること

PayPal チームが最初にやったのは、AI でもモデルでもフレームワークでもなかったとのことです。「自分たちのデータがどこにあるか」を把握し、文書化することを最初に実施したそうです。

把握した主要なデータソースは BigQuery、CAL、ServiceNow、Splunk / Datadogの 4 つです。

そしてこれらに横断的にアクセスするための統合 API レイヤー「NCP（SRE NCP tool）」を構築されたそうです。「この NCP レイヤーへの投資が、エージェントを実用的にした」と Mir 氏は述べていました。

ADK による開発の加速

エージェントのフレームワークとして、複数の選択肢を評価し、社内製のものも試作されたそうです。最終的に Google の ADK（Agent Development Kit）を採用した理由は明快でした。開発時間を 60〜70% 削減し、コーディング量も 40〜50% 減らし、POC から本番デプロイまで 2〜3 週間で到達できたからだと述べていました。

「なぜそんなに速いか」という問いへの Mir 氏の答えは「ほとんどのインフラ的な仕込みが既に組み込まれているから」でした。セッション・メモリ管理、永続コンテキスト、マルチエージェントのスーパーバイザールーティング、並列実行。自社でオーケストレーターを作ったときはすべて自分たちで考える必要があったものが、最初から揃っています。さらに Vertex AI 上でオートスケールと組み込みモニタリングが動くため、本番運用の基盤も確保されています。

モデル選定とその柔軟性

「何のモデルを使っているか？」はエージェントについて話すと必ず出る質問です。Mir 氏の答えは「常に最新・最大のモデルを試すが、最終的にはユースケースがモデルを決める」でした。

Google Cloud の Model Garden で 200 以上のモデルを試せる環境があり、Vertex AI の評価フレームワークで精度、ハルシネーション率、レイテンシ、コストをプロファイリングした上で選定しているそうです。「コード変更なしでモデルを入れ替えられるように設計しているので、新しいものが出たらすぐ試せる」と述べていました。本番で使用しているモデルの名前も挙げられましたが、セッション時点の情報であり最新の状況とは異なる可能性があるため、この記事では言及を控えます。

大規模展開のための Agent Governance と Golden Path

Afrina M 氏のパートは、Mir 氏が構築した「1 つのエージェントシステム」を出発点として、「これが企業内に数千・数万規模で展開されたとき何が起きるか」という問いから始まりました。

4 つのガバナンスピラー

Afrina 氏は「エージェントを新入社員のように考える」という比喩でガバナンスの 4 要素を整理しました。

Agent Security はセキュリティアクセス（社員証）にあたり、エージェントが持つ権限と境界を定義します。Agent Gateway は建物の入退出管理に相当し、アクセス可能なシステムと制限エリアを制御します。Identity and Registry は組織図です。どのエージェントが何の目的で存在し、誰と連携しているかを管理します。Observability は人事評価にあたり、エージェントが正しい判断をしているか、ハルシネーションを起こしていないかを監視します。

そのうえで、現状の問題として Afrina 氏が指摘したのは、エージェントを構築するだけでも IDE・フレームワーク・オーケストレーター・評価ツールと無数の選択肢があり、デプロイになると選択肢はさらに増えるという点です。各チームが異なる選択をすると、ガバナンスの一貫性は保てません。「クリックオプス（GUI を手動で設定すること）でガバナンスを実装する」という誘惑に負けやすく、可観測性は後回しになる傾向があるとも述べていました。

Golden Path と Application Design Center

Golden Path とは、最もシンプルで退屈なデプロイの標準経路です。Afrina 氏は「boring であることが目的」と繰り返し強調していました。

実装は 3 ステップです。ステップ1はランタイムの選択で、企業のニーズに合う 1 つに絞ります。ステップ2が核心で、インフラデプロイテンプレートを作成し、4 つのガバナンスピラーをすべてそこに埋め込みます。これは一度だけ行う作業です。ステップ3でこのテンプレートをエージェントビルダー全員に配布します。開発者はエージェントのロジックを乗せるだけで本番にデプロイできます。

このテンプレート管理の仕組みを実現するのが Application Design Center（ADC）です。Google Cloud ネイティブのツールで、プラットフォームエンジニアや SecOps チームがデプロイアーキテクチャのテンプレートを作成・管理し、開発者はそれをセルフサービスで利用できます。「開発者にとって、ガバナンス周りは全部設定済み。エージェントのロジックを push するだけで本番に出せる状態を作るのが目標だ」と Afrina 氏は締めくくりました。

会場の様子

会場でスピーカーが「SRE や本番エンジニアの人は手を挙げて」と呼びかけると、想定よりはるかに多くの手が上がりました。「では、過去 2 週間でインシデント対応のために叩き起こされた人は？」という問いにも多くの手が続いたときがこのセッションの中で一番印象的でした。

PyaPal の実例については、一貫して「実際に 3,000 のマイクロサービスを抱えた現実の中でどう動かしているか」という視点が貫かれていました。グリーンフィールドの理想論ではなく、「我々の現実はこうだった」という率直さが際立っていた。他のセッションではなかなか聞けない話です。

Afrina 氏のパートは、スケールに関心のある組織にとって刺さる内容でした。エージェントを 1 つ作ることと、1,000 個を統治することはまったく別の問題です。そのことを正面から扱ったセッションを聞けたことは記帳だったかなと思います。

まとめ

1. SRE 自動化の核心は「ツールを増やすこと」ではなく「オーケストレーション」: ダッシュボードやアラートをいくら増やしても、エンジニアの認知負荷は下がらない。PayPal が示したのは、エージェントを連携させてインシデントの「検知→トリアージ→緩和→報告」を自律的に実行するというアプローチです
2. ADK と Agent Platform(旧Vertex AI) の組み合わせが本番環境へのデプロイのハードルを下げた: 開発時間 60〜70% 削減・POC から本番 2〜3 週間という数字は、ゼロベースでフレームワークを構築した経験があるチームならより実感できるはずです。セッション・メモリ・マルチエージェントルーティングが組み込みで使えることの価値は大きいと感じました
3. 「1 つ作れる」と「1,000 個を守れる」は別問題: エージェントを組織に展開するには、4 つのガバナンスピラー（Security / Gateway / Identity / Observability）を標準化された形でインフラに組み込む必要があります。プラットフォームチームがエージェント展開の設計を始めるなら、Golden Path と ADC のアプローチからまず検討するのが筋だと思います

参考

Google Cloud、Google Workspace に関するご相談はXIMIXへ！

Google Cloud、Google Workspaceに関する お問い合わせはこちら
XIMIX®はNTTインテグレーションが所有する登録商標です。（商標登録第６７５５２３４号）