Google Cloud Next 25参加レポート: 生成AIワークロードにおけるSREとセキュリティについて学んできた

はじめに

こんにちは、URBAN HACKSでインフラエンジニアをしています安坂です。
2025年4月にラスベガスで開催されたGoogle Cloud Next 25に参加してきました！
参加の主目的は担当プロジェクト及び組織横断で活用できるナレッジの獲得で、個人的な裏テーマとして生成AI時代におけるインフラエンジニアの在り方について解像度を上げることも掲げておりました。
この記事では、特に印象に残った生成AIワークロードにおけるSREとセキュリティに関して、現地で聴講したセッションやデモを通じて得た学びや気づきをご紹介します。

生成AIワークロードにおけるSRE

今までSREとしてクリティカルユーザージャニー(CUJ)を定義し、そこから可用性やレイテンシのSLI/SLOの策定及びその監視などを経験してきました。
しかし、こと生成AIを活用する際の観点などは考えられていなかったのでまさに目から鱗でした。

生成AIでSREとして意識すべき観点

参加セッション「SRE for gen AI workloads: Are you ready?」より
従来のインフラ監視だけでは、生成AI特有の課題を十分に捉えることはできません。
特にLLM(大規模言語モデル)を使用する際、従来のようなサーバーのレイテンシやエラーレートのようなメトリクスの監視に加えて、コスト増加と不正使用の抑制が見落とされがちなので監視していく必要があります。
また、ユーザー満足度を客観的に捉え、継続的に評価する視点も、今後ますます重要になっていきます。

コスト増加

コスト増加抑制のため、以下のような指標を見ていく必要があるとのことでした。
BigQueryでの高額課金の話は有名ですが、LLMでも使い方次第では高額課金の可能性がありますので生成AI導入とセットでこちらの監視は必須になりそうです。

• ランニングコスト
• 入力/出力トークン数
• レートリミット

不正使用の抑制

ユーザーにプロンプト入力を許可するワークロードでは、ユーザーはLLMに対してあらゆる質問を投げかけることができます。
そのため、意図しない応答を防ぐための制御が不可欠です。
単なる「おふざけ」や「過剰な負荷」をかける行為だけでなく、
モデルに意図的な誤動作を引き起こさせる「プロンプトインジェクション」と呼ばれる攻撃への対策が重要であると理解しました。
セッション内では、これらのリスクに関連して以下の2つの指標が紹介されていました。

• Bad Query Rate（不適切な質問率）
  • 極端に長いメッセージでワークロードに負荷をかけたり無関係な話題に関する質問の割合
• Safety Issue Rate（安全性の問題の発生率）
  • 有害なコンテンツの提供を許してしまった割合
    （例：セッションでは「ハッカーになるにはどうしたらいいか」という質問を行い、その応答の安全性を評価していました）

ユーザー満足度

LLMは非決定的（毎回結果が変わる）なので、ユーザー満足度を客観的に可視化する仕組みが重要になります。具体的にはユーザーの感情や会話の継続率など(エンゲージメント維持率)を計測することでユーザー体験を定量的に評価していく必要があるとのことでした。

ユーザー満足度の定量的な評価例

セッションでは以下のようなSLOを策定した上でダッシュボードで例を示していました。
GeminiやChatGPT等の対話型生成AIを使用しているとGood/Badボタンが出てきたり、どちらの回答の方が好ましいですか？と出てくるあれを集計するイメージです。

• ポジティブな会話の割合が60%以上であること(左上)
• ネガティブな会話の割合が20%未満であること(右上)
• エンゲージメント維持率が70%以上であること(左下)

実践的なアクションプラン

上述したような新たな観点への対応のため、以下に挙げるようなアクションが推奨されました。

• Model Armorの利用による安全な設定
  • Model Armorとは、プロンプトや応答を自動でスクリーニングし、プロンプトインジェクションなどのリスクを未然に防ぐことで、ワークロードの安全性と信頼性を高めるGoogle Cloudのフルマネージドサービスです。
  • 管理者側で一元的にポリシーを設定・適用できるため、開発チームや運用チームの負担を軽減しつつ、セキュリティレベルを一定以上に保つことが可能になります。
• リアルデータを元に継続的に評価
  • これは従来通りかもしれませんが、非決定的という特性上今まで以上に継続的に評価をしていくことが重要になります。
• FirebaseのGenkitとCloud Observabilityを併用し、LLMの品質と信頼性を両立
  • FirebaseのGenkit
    • OpenTelemetryを活用し、ユーザーとのやり取りのトレースから感情や行動を収集します
  • Cloud Observability
    • インフラ/アプリケーションのテレメトリーデータの収集や、Genkitのデータを統合したダッシュボードによるSLI/SLOの可視化を行います

Cloud Observabilityの活用イメージ

ここで、Cloud Logging(Cloud Observabilityの機能の1つ)に新たに追加される「Investigate」機能をデモを交えて紹介したいと思います。「Investigate」は、GeminiでCloud Observabilityを強化するもので、
1つのログからシステムの状態を総合的に判断して被疑箇所の洗い出しとその修正案の提示、そのままデプロイまで支援する機能とのことでした。
今でもネットワーク疎通のトラブルシューティングなどはサービスとして提供されていますが、ついに秘技箇所をシステムから総合的に判断できるようになったとのことで、GAになったら積極的に使いたいと思いました。

Cloud LoggingのUIに新たに「Investigate」というボタンが追加され、エラーログから直接調査を始めることができます。

Cloud Logging経由でなくても「Investigate」は使えるようですが、Logging経由の場合必要な情報が自動で入力されるのでスムーズです。

遷移先の「Investigation」画面内では、Hypotheses（仮説）タブに原因分析と推奨アクションが提示されます。
さらに、Geminiによる「Suggest」リンクから、ソースコード修正案が自動生成されます。


生成された修正案を確認し問題なければ、「保存と再デプロイ」ボタンからそのままデプロイまで一気通貫で実行可能です。

実際にデモを見て、これまでエンジニアが手作業で対応していたトラブルシューティングが大幅に効率化できることを実感しました。
もちろんGeminiからの提案を完全に鵜呑みにしてデプロイするのは危険なので開発者で理解して進める必要はありますが、総合的に判断し具体的な修正提案まで自動化できる仕組みは非常にありがたいですし心強いと感じました。

生成AIワークロードにおけるセキュリティ

SREパートでも一部触れていますが、興味深かったものを簡単にご紹介できればと思います。

生成AIにおける各役割の責任モデル

こちらは「Secure by design for AI applications and agents」というセッションで、
Palo Alto Networks社が空港における航空管制官・旅客・航空会社・保安検査といった役割を、生成AIワークロードにおける企業、ユーザー、モデル提供者、セキュリティパートナーになぞらえ、それぞれが担うべき責任範囲を明確に示していました。

企業の責任（Enterprise Responsibility）

航空管制官（Airport Control Authority）のような存在

• ユーザー研修
• ポリシー・管理設定の導入
• データガバナンス（統制）
• データソースの選定
• アプリ設計指針
• LLM Opsのプロセス定義

ユーザーの責任（User Responsibility）

旅客・スタッフ（Passengers and Staff）のような存在

• アカウンタビリティ（利用ルールを理解し、責任ある利用を行うこと）
• ポリシー・管理の理解
• データガバナンス遵守
• アプリの安全な利用
• LLM Opsのプロセス遵守

モデル提供者の責任（Google / 3rd Party Model(s)）

飛行機と滑走路（Aircraft and Runway）のような存在

• 認証・アクセス管理
• モデル更新・パッチ管理
• 著作権管理・プロンプトガードレール
• モデルポスチャ（モデルの運用ポリシー）
• 暗号化と鍵管理
• 実行環境の機密性

セキュリティパートナーの責任（Palo Alto Networks）

保安検査（Terminal and Baggage Security）のような存在

• アクセス制御とポスチャ管理
• プロンプトインジェクション防御
• 情報漏洩対策（DLP）
• マルウェア検出・脅威予防
• 悪意あるWebからの保護
• ランタイムのセキュリティ保護

保安検査に相当するセキュリティ対策については、Palo Alto Networks社のようなパートナーに任せる選択肢もあれば、Google Cloudが提供する各種セキュリティサービス（Model Armor、Cloud DLP、Confidential VMsなど）を組み合わせて自社で構築・運用することも可能です。
パートナーに依頼することで高度な防御力や専門知識を享受できる一方で、自社運用を選べば柔軟性やコスト管理のしやすさを確保できます。
それぞれのメリットを踏まえつつ、自社の体制やリスク許容度に応じた最適な選択をしていくことが求められそうです。

番外編: セキュリティブース

番外編として、エキスポ会場に設けられていたセキュリティ関連のブースにも足を運びました。
会場では、Model Armor、Identity and Access Management（IAM）、Security Command Centerなど、サービス単位で細かくブースが分かれており、それぞれのエキスパートであるGooglerが直接デモを交えながら、サービスの仕組みや活用方法について丁寧に解説してくれていました。

特に印象的だったのは、実際のユースケースに即した具体的な相談ができることです。
ちょうどプロジェクトで発生していたPAM（Privileged Access Manager）まわりの課題について相談したところ、エキスパートから具体的なベストプラクティスや設定上の注意点をアドバイスしてもらうことができました。
普段のサポートケース対応は文面のコミュニケーションなので、どうしてもニュアンスの違いによるもどかしさを感じる場面もあります。
現地でエキスパートと直接ディスカッションできる環境はとても貴重で、オンラインでは得られない深い理解と納得感を得ることができました。

さいごに

Google Cloud Next 25では、体感として8割以上が生成AI関連のセッションでした。
現在、自分の担当プロダクトでは生成AIを活用した機能はありませんが、今後ほぼ確実に利用していくことになると感じています。
実際に活用イメージも湧いてきたため、開発に先立って必要な観点をアップデートできたのは非常に有意義でした。
特に、これまでSREはインフラやバックエンド側からユーザー体験を支える役割が中心でしたが、
今後はUX領域にも踏み込んで観測・改善に取り組む必要があると強く感じました。
また、Model ArmorやGenkit、Cloud ObservabilityといったGoogle Cloudの機能について、
実際に導入していく具体的なイメージを掴むことができたのも大きな収穫です。
今回はNextなのでGoogle Cloudを中心としたサービスが多く紹介されていましたが、
本質はどのクラウドにも共通するものだと考えており、自システムに合った形で取り入れていくことが重要だと感じました。
生成AI時代における新しい考え方や活用事例の学びが、読者の皆さんの気づきや参考になれば幸いです！