2025 年 8 月 5 – 6 日に Google Cloud Next Tokyo ’25 が開催されましたね、本記事は参加レポートとして Expo にステージが設置されている Developer Stage にフォーカスしてお送りします！
引用：https://www.googlecloudevents.com/next-tokyo/sessions?tab=all&c_97388=Developer+Stage
公式ホームページの通りですが、Google Developer Experts や Google Cloud Partner Top Engineer 2025 の Fellow の方々が発表しているステージです。
引用:https://www.googlecloudevents.com/next-tokyo/sessions?tab=all&c_97388=Developer+Stage
私は今回 8 回ほど参加して、10 分という短い時間の中で濃厚な技術の話を聞ける Developer Stage にハマってしまいました。また、登壇される方に知り合いも多く、学びと応援を一緒にできて非常に満足度が高かったです！
本記事では下記の 5 セッションについて取り上げていこうと思います！
- Cloud Run & GKE 最前線！ここ最近ではどう使い分けるべき？
- 今日から始める CI/CD Observability
- Cloud Run ではじめる LLM/MCP サーバー運用とセキュリティ対策
- テレメトリー API から学ぶ、Google Cloud Observability と OpenTelemetry の現在
- Eval-Centric AI: Agent 開発におけるベストプラクティスの探求
※ 写真にご本人が写られているものは事前に許可をいただいています。
@Makocchan_Re さんの Cloud Run と GKE をどのように使い分けていくかという話の中で Cloud Run に多めにフォーカスをあてた LT でした。
Google Developer Expert でもあり、2025 年の Google Cloud Partner Top Engineer Fellow でもあるということで勝手に目標としているお方です。
Cloud Run のユースケースは拡大中
Cloud Run の変遷を綺麗にまとめてくださっていて、私自身どこからちゃんと把握できているだろうかと振り返る良い機会となりました。GKE ではここに書いてあるようなユースケースは以前から備えていたというところから、両者の対応可能なユースケースが大きく被ってきていることがわかりました。
Cloud Run worker pools の紹介
今年 4 月に開催された Google Cloud Next ’25 で発表されて盛り上がった Cloud Run worker pools にも触れられていました。従来でも Cloud Run services でもやろうと思えばやれたが、大きな制約が発生してしまっていた Pull 型サブスクライブのユースケースにおいて活躍するだろうとのことでした。
私も Cloud Run は好きなサービスなので、ちょこちょこ worker pools の検証をしていたりします。常駐型のアプリケーションをサーバーレスでさくっとホスティングできることに利便性を感じています。機械学習アプリケーションやジョブでは、非同期にしたいケースも多いのかなと思っていて Pull 型サブスクライバーとして実装に適した worker pools の使い所は今後増えていくのだろうと思いました。
Cloud Run と GKE の使い分け
発表中では時間が足りなかったのもあり光の速さでめくられてしまった Cloud Run と GKE の比較表が後ほど X のポストに公開されていました。非常にありがたいです。
パフォーマンスや運用コストに加えて、ステートレス/ステートフルアプリケーションとの相性という観点が入っているのは重要だなと思いました。
こちらとは別のセッションにはなりますが、同様に Cloud Run と GKE の使い分けに関するスライドがあってポストしたところでした。その話もあったため、上記のスライドの比較表の納得感が非常に高く良い流れでこちらの LT を聞けたなと感じました。これら 3 スライドを総合することで、Cloud Run か GKE かどちらを選択すべきかという場面で確度高く技術選定ができそうだなと思いました！
続いて、@866mfs さんの CI/CD にもしっかりオブザーバビリティの考えを適用していこうと LT です。
2025 年の Google Cloud Partner Top Engineer Fellow であり、Jagu’e’r オブザーバビリティ分科会で共に運営として活動しているシゴデキなお方です。
オブザーバビリティの適用範囲
スライドにも書いてある通り、「オブザーバビリティは運用フェーズだけではない」という導入から話は始まりました。こちらのスライドの英文には 「オブザーバビリティはシステムの開発ライフサイクルのあらゆるフェーズで活用することができる」 という文脈が記述されており、目的が明確になれば取得すべきシグナルも定まるとのことでした。
オブザーバビリティのシフトレフト
上記にもある通り、オブザーバビリティはシステム開発ライフサイクルのあらゆるフェーズで活用できるということから 「運用だけでなく開発」にシフトレフトすることでより効率的なソフトウェアデリバリーが可能 となるとのことでした。
確かに開発にもオブザーバビリティを適用するともっと体験がよくある場面があるなとうなずきながら LT を聞いていました。例えば、CI/CD が失敗しているととりあえず再実行してみたりすぐにコードを読み解いたりと全く実行状況の情報を見ずにデバッグしていることがあるなと。運用時と同様にトレースを取得しログが紐づいていれば、この「とりあえず」を一気に削減でき作業効率を高められそうだと感じました。
CI の課題
では、テストとパイプラインにおける可視性、つまり CI/CD におけるオブザーバビリティを意識すべきであり、その課題感にも触れられていました。
前者の安全性では、Google Cloud の Workload Identity の中でも Service Account を使用せずに直接認証可能な Direct Workload Identity Federation を取り上げていました。
後者の可視性では、ツール例として「otel-cicd-action」や「github-actions-opentelemetry」を紹介しつつ Datadog の「CI Visibility」もいいぞ！とのことでした。（こちらについては以前イベントで登壇をご一緒にさせていただいた時によりフォーカスした資料が上がっていましたので貼っておきます。）
@msy78 さんの話題の LLM や MCP サーバーをどのようにセキュアに Cloud Run でホスティングするかという LT です。
Google Developer Expert や Google Cloud Partner Top Engineer でもあり、AWS HERO でもあるマルチクラウドでグローバルに活躍されているお方です。
LLM / MCP サーバーを含む処理
まずは、LLM と MCP サーバーが利用された場合の処理のフローをわかりやすくまとめてくださっていました。私自身ここらへんの処理の流れがあやふやだったので、大変勉強になりました。
MCP ホストである AI アプリケーションが MCP サーバーを介して内部データを利用したアクションや外部サービスとの連携など様々な機能を外部ツールとして利用できる様を理解できました。
自前で用意するなら Cloud Run GPUs
LLM や MCP サーバーを自前で用意するケースとしては、ドメインに特化したモデル利用やガバナンス・コンプライアンス要件・ビジネスユースケースに特化した情報の参照などがポイントになると説明されていました。
そういった場合のホスティング先として LLM ワークロードに向いている Cloud Run GPUs をあげられていました。GPU のドライバーインストール等が不要で数十秒でのデプロイ可能は非常に魅力的ですね！
一方で、現時点では日本の二つのリージョンは未対応ということでアップデートを待ちましょうとのことでした。
生成 AI アプリケーションのセキュリティ
今回のような AI アプリケーションをホスティングする場合には、通常の Web アプリケーションのセキュリティに加えて、生成 AI アプリケーションに特化したセキュリティ観点を「OWASP Top 10 for AI Applications 2025」 にて説明されていました。
また、Cloud Run でのセキュリティ対策も詳細にまとめてくださっていました。特に Cloud Run からパブリックに通信が出ていかない工夫として 「Direct VPC Egress ですべてのトラフィックを自前の VPC に流し込む」 といったところは Cloud Run ならではだなと感じました。
生成 AI を利用したアプリケーションに携わっていなかったこともあり、プロンプトインジェクションやデータ/モデルの汚染など今までになかったセキュリティ観点を今後は頭に入れていかなければならないと思わされた瞬間でした。
Cloud Run に加えて、生成 AI・セキュリティと自身が苦手とする分野の話をインプットでき、あっという間の 10 分でした！
@k6s4i53rx さんは、Google Cloud × OpenTelemetry × 生成 AI というのをポイントに発表されていました。
Google Developer Expert で OpenTelemtry Meetup や今年初開催の Observability Conference Tokyo 2025 のオーガナイザーもされています。（私も O11y Conf にはスタッフの一員として関わらさせてもらっています。）
Telemetry API の嬉しいポイント
Telemetry API とは、今年 4 月ごろに発表された Google Cloud Observability の新しいテレメトリーデータの受付エンドポイントです。この Telemetry API は OTLP 形式のトレースデータを Cloud Trace に取り込んでくれます。
従来の Cloud Trace API には、OTLP 形式のテレメトリデータは独自の変換をかまさないと送信できませんでした。そこが解消されたことで、「プロプライエタリからの解放」 が実現されるとの説明をされていました。
AI サービスとオブザーバビリティの関係性
AI を使ったサービスには特有の計測したい観点があり、それらをオブザーバビリティツールに送信して分析可能な状態にすることが重要という話がありました。
Cloud Trace では、OpenTelemetry 準拠のトレースデータから判断し、スパンが Gen AI semantic conventions に準拠した上で Gen AI semantic conventions に従う属性やイベントが含まれていると Cloud Trace の「生成 AI」タブにマッピングされて生成 AI に特化した情報を閲覧可能になるようです。
Cloud Trace の生成 AI タブ
こちらのスライドでは、1 つのスパンに invoke_agent という名前が付けられているトレースが示されています。このスパンが Gemini を呼び出していて、生成 AI イベントが含まれるようです。
その内容として、「プロンプトと回答の可視化」と「AI 関連タグの可視化」の大きく二つのカテゴリの情報が表示されています。
このような情報を収集しいつでも分析可能な状態にしておくことで、ブラックボックスになりがちな AI エージェントの挙動を把握できるようにしておくことが重要なんだなと改めて感じました！
Google Cloud が OpenTelemetry というオープン標準へ強くコミットしている姿勢を感じる LT でした。また、Cloud Trace では少し前に Explore がアップデートされて検索性が向上し使いやすくなったと思っていましたが、生成 AI に特化した情報がここまでリッチに見れるようになっていたことはこの場で初めて知り、生成 AI に対するオブザーバビリティが求められ進化していることを実感するアップデートだなと感じました。
本記事最後に紹介するのは、@K_Ryuichirou さんの LLMOps における継続的な評価を通じて継続的な改善を実現するためのアプローチに関する LT です。
Google Developer Expert であり、私が運営の一員として携わっている Jagu’e’r オブザーバビリティ分科会の次回 Meetup にスペシャルゲストとしてお招きするお方です。（10 月初旬開催予定ですので、ご期待ください！）
※ LT の冒頭で、時間の関係上抽象度の高い話になる点はご留意くださいとのアナウンスがありました。
DevOps と MLOps
LT の導入は、DevOps・MLOps・LLMOps がどのような流れで誕生した概念であるのかを説明してくださいました。
DevOps は顧客に多少不安定になっても顧客に新しい価値を提供したい Dev と不安定となるようなチャレンジは避けて顧客に安定的に価値を供したい Ops が協調していくための提案であり、原則の一つである継続的な改善がポイントであると。
一方、MLOps は機械学習の成果をスケールさせるために DevOps のプラクティスに基づく機械学習システムを育てる取り組みであり、継続的な訓練がポイントになるとのことでした。
そして、LLMOps
生成 AI プロジェクトはよく 「Demo hell」 と呼ばれる状況に陥り、「デモまでは行き着くものの、本番化が著しく困難」「品質を評価し、担保することが極めて困難」という課題があることを述べられていました。
Eval-Centric AI は、この課題を解決するための考え方であり、評価を中心とした開発 = 継続的な評価による継続的な改善を取り組むことが重要であるとのことでした。
生成 AI プロジェクトでは、モデルやデータをいじることが難しいケースが大半であり、自分たちでコントロール可能な「評価」というところでいかに継続的な改善するかという理解をしています。評価データや評価プロンプトが改善の肝になってきそうです。
Eval-Centric AI の実践
Agent 開発における原則として、スライドの 5 点をお話されていました。ここでは印象的だった 「独自のデータを定義して評価データを育てる」 について触れます。
スライドの「自分の業務というベンチマークはない」というところでは、世の中で取得できるような評価データが自分たちのユースケースにマッチすることはそうそうないということから、まずは 10 個でもいいから適切な評価データを用意して、その評価データをクリアできる状態に持っていくことが重要であると述べられていました。
こちらの話を聞いていて、「評価データを育てる」というフレーズが印象的で Eval-Centric AI の考え方の大きなポイントになりそうだなと感じました。
今回このように記事にしたおかげで、DevOps から MLOps そして LLOps という流れと AI サービスの「Demo hell」な課題が存在し、そのアプローチとしてモデルでもなくデータでもなく、評価を開発の中心に据えて「継続的な評価による継続的な改善」を行なっていくことが重要であるということをより理解することができました。
また、評価データでの評価でクリアできない時には AI がどういった思考過程やツール・エージェント呼び出しによって回答を導いたかを把握するためにはオブザーバビリティが必須なんだなと話がつながる瞬間もあり、これまた学びが多い LT でした。
みなさん、いかがだったでしょうか？
Google Cloud Next Tokyo の Developer Stage で 10 分では勿体無いくらい濃厚な技術セッションが行われていることが伝わったでしょうか？
もし一人でも多くの方にこの熱が伝わり、来年開催される Google Cloud Next Tokyo の Developer Stage に足を運んでみたいと思ってくださる方が増えたらとても嬉しいです。
私も来年の Developer Stage をいまから楽しみにしつつ、いつしかこの場やブレイクアウトセッションで登壇できるように今後も力をつけていきたいと執筆しながら改めて思いました！
ここまで読んでいただき、ありがとうございました！
Views: 0
