G-gen の山崎です。当記事は、Google Cloud Next '26 in Las Vegas の2日目に行われたライトニングトークセッション「 8 Tips to Agentic Security Operations in 18 Minutes 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 AI を利用したセキュリティ運用における8つの Tips Tips 1: AI 推論の下に決定論的ルールを階層化する Tips 2: エージェントが必要とするデータを事前に計算する Tips 3: エージェントの権限を明示的に制限する Tips 4: ツールの出力は人間のためではなくエージェントのコンテキストウィンドウに合わせて設計する Tips 5: プロビナンスとリネージを通じてエージェントの決定に対する信頼を構築する Tips 6: 完璧な実行ではなくグレースフルデグラデーションを設計する Tips 7: 単体テストだけでなくシナリオハーネスを用いてシステムをテストする Tips 8: すべての要素、特にトークン使用量とアップストリームのレイテンシを観察する セッションの概要 Insight 社の John Giglio 氏と Hayden Holland 氏により、セキュリティ運用における AI エージェントの利用に関する実践的な8つの Tips が紹介されました。 セッションでは、AI を単なる確率論的な推論ツールとしてではなく、決定論的なシステムと組み合わせて安全かつ効率的に運用するための設計思想が語られています。 AI を利用したセキュリティ運用における8つの Tips Tips 1: AI 推論の下に決定論的ルールを階層化する エージェントの開発において、柔軟な AI の推論と、決定論的なルールベースの処理を組み合わせることが重要となります。AI の推論は確率論的であり、常に同じ結果を返すとは限りません。一方、決定論的なシステムは常に同じ結果を保証します。 セキュリティ領域においては、不確実性のある AI だけで環境に変更を加えることは大きなリスクを伴います。そのため、Insight 社では Site Reliability Engineering （以下、SRE）の手法に倣い、AI エージェントをデータのパターン認識や意思決定の補助として使用し、実際の実行部分は Python や Go 言語などで記述された決定論的なコードに委ねるアーキテクチャを採用しています。 SRE のマインドセットでは、運用業務を定期的に自動化して減らしていくことが求められますが、AI エージェントを使用することで、このプロセスをスピード感を持って対応することができます。 YAML や JSON スキーマ言語を多用してステップを定義し、期待される結果とそうでない結果を明確にしながらシステムを構築することで、AI エージェントは未知の脅威を探索する能力を提供し、決定論的なルールはシステムの安全な基盤を提供します。このように階層化することで、高い探索能力と耐久性のある実行の両立を実現できます。 Tips 2: エージェントが必要とするデータを事前に計算する Large Language Model （以下、LLM）を使用する推論やツール呼び出しには、多くのトークン消費とレイテンシが伴います。セキュリティ調査のたびに AI エージェントにあらゆる情報を探索させると、運用コストが膨大になり、回答を得るまでの時間も長くなります。 例えば、 MCP （Model Context Protocol）を使用して多数のツールをエージェントに接続し、すべてを自律的に推論させようとすると、処理が空回りし続ける可能性があります。この課題に対処するためには、エージェントにすべてを推論させるのではなく、エージェントが必要とするであろうデータを事前に計算し、準備しておくことが有効です。 エージェントには、明確に定義されたシステムプロンプトと、「この IP アドレスはウェブ環境で何をしているのか」といった特定のセキュリティのユースケースに特化した小さなスキル（skills）のみを使用させることが推奨されます。事前に与えられる情報が多いほど、エージェントの出力の精度は向上し、高価な LLM の呼び出し回数を最小限に抑えることができます。 参考 : What is the MCP and how does it work? 参考 : What is the Model Context Protocol (MCP)? Tips 3: エージェントの権限を明示的に制限する 現在、エージェントに自律的な意思決定をさせ、環境への変更権限を与えることには依然として高いハードルがあります。AI エージェントに対する完全な信頼が確立されていない段階では、エージェントの権限を明示的に制限するガードレールが不可欠です。コンテキストウィンドウ内に「何も編集しないで」という指示を含めたとしても、AI がそれを完全に遵守する保証はありません。 そのため、データを変更する可能性のあるツールの呼び出しについては、実行前に現在の権限レベルをチェックし、拒否ブロックを設ける必要があります。コンテキストウィンドウに指示を含めるだけでは、確実な保証は得られません。 2026年4月現在、多くの組織は「すべてを閲覧する」という読み取り専用の権限でエージェントを運用し、 Security Information and Event Management （SIEM）などのデータを通じて、エージェントの推論の精度を統計的に評価している段階とされています。 Tips 4: ツールの出力は人間のためではなくエージェントのコンテキストウィンドウに合わせて設計する エージェント間でデータを受け渡す際、ツールの出力結果はエージェントのコンテキストウィンドウに最適化されている必要があります。人間が見やすい形式で大量のデータをエージェントに渡すと、コンテキストウィンドウの上限に達し、重要な情報が無視されるなどの問題が発生します。システムは人間のためではなく、エージェントのために設計されなければなりません。 例えば、500件のファイアウォールルールのデータをそのまま返すよりも、関連性の高い上位10件の調査結果に絞り込み、「次に特定のルールについて詳細をクエリする」といったヒントを付与する方が効果的となります。エージェントは人間以上の情報を処理できる能力を持ちますが、コンテキストウィンドウの限界に配慮し、処理効率とのバランスを取る設計が求められます。適切なデータ量を提供することで、エージェントの能力を最大限に引き出すことができます。 Tips 5: プロビナンスとリネージを通じてエージェントの決定に対する信頼を構築する セキュリティチームがエージェントの自律的な意思決定を信頼するためには、ブラックボックスを排除し、推論の過程を検証できる仕組みが必要です。セッション内では、これを メタ可監査性 （Meta-auditability）と呼んで説明されています。 エージェントが導き出したすべての結論について、どのようなデータに基づき、どのような推論過程を経てそのツール呼び出しが行われたのかを遡って確認できるプロビナンスとリネージを設計に組み込む必要があります。セキュリティ担当者は本質的に懐疑的であり、証跡を直接確認できなければシステムを信頼しません。 運用の中でエージェントの行動パターンを継続的に監視・分析し、何十回も実行を繰り返す中で意思決定の傾向を把握します。この継続的な可視化を通じてのみ、少しずつシステムへの信頼を構築していくことができます。 Tips 6: 完璧な実行ではなくグレースフルデグラデーションを設計する システムの障害時に全体を停止させるのではなく、機能を縮小して稼働を継続する グレースフルデグラデーション の概念を、エージェントの設計にも取り入れることが推奨されます。 セキュリティ運用において、完璧な回答を待って時間がかかる、あるいは処理が失敗して何も情報が得られない状況は避けるべきであり、部分的でも正しい答えが得られるように出力結果に対してガードレールを設けることで、信頼性の高いシステムを目指すべきであると述べられました。 Tips 7: 単体テストだけでなくシナリオハーネスを用いてシステムをテストする エージェントをシステムとして本番環境に導入する前には、厳密なテストが不可欠です。しかし、単体テストや、結合テストによる検証だけでは不十分です。 AI エージェントが正しいセキュリティの意思決定を下すことを検証するためには、実際の運用に即したシナリオハーネスを使用する必要があります。サンドボックス環境を用意し、エージェントが予期せぬ挙動を示して制御不能に陥らないか、特定のシナリオにおいて適切なアクションを選択できるかを検証することが重要と語られました。 Tips 8: すべての要素、特にトークン使用量とアップストリームのレイテンシを観察する システムに対する信頼を維持するためには、エージェントの動作を継続的に観察し、可視化することが不可欠です。エージェントがどのような操作を行っているかを監視するだけでなく、トークン消費量やレイテンシの推移も把握する必要があります。 また、エージェントが機能しているように見えても、コンテキストが腐敗し、低品質な結果を出力し始めている可能性があります。コンテキストウィンドウの限界に近づいた際に見られる異常な応答やパフォーマンスの低下を検知するために、エージェントが行っているすべてを観察するという考え方を受け入れることが、安全な運用に繋がると述べられました。 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 13 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の武井です。当記事では、Google Cloud Next '26 in Las Vegas のセッション「 Secure what's next: AI-driven defense for the enterprise 」について、速報レポートをお届けします。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp はじめに AI がサイバーセキュリティにもたらす変革 変化する3つの軸 AI 自体を狙う新たな攻撃と、守るべき領域の拡大 Google が持つ可視性とフルスタックの AI インフラ 圧倒的な可視性 フルスタックの AI インフラと共同開発の優位性 Mandiant の最前線の知見 自律型防御に向けた新機能 human-led から human-on-the-loop へ Triage and Investigation Agent Threat Hunting Agent と Detection Engineering Agent Dark Web Intelligence Wiz による開発者起点のクラウドセキュリティ 垂直サイロ型から水平型への転換 Morgan Stanley の導入事例 AI 時代に向けた Wiz の進化 3 つのエージェントによる水平・エージェント型モデル クラウドネイティブから AI アプリケーション保護プラットフォームへ 2 つの方向への拡張 包括的なコードセキュリティの全体像 おわりに はじめに 本セッションでは、AI がサイバーセキュリティのあらゆる領域にもたらしている変化と、それに対抗するための 自律型サイバー防御 （Agentic defense）が紹介されました。 Google Cloud の COO 兼セキュリティ製品担当プレジデントである Francis deSouza 氏を中心に、脅威インテリジェンス、自律型セキュリティエージェント、Wiz を活用したクラウドセキュリティ、そして顧客事例まで、幅広い内容が扱われた密度の高いセッションでした。 AI がサイバーセキュリティにもたらす変革 変化する3つの軸 Google Cloud の Sandra Joyce 氏からは、AI が脅威状況（threat landscape）に与えるインパクトが Scale （規模）、 Speed （速度）、 Sophistication （巧妙化）の3つの軸で整理されて紹介されました。 1つ目の Scale について、攻撃者は AI を単なるアドバイザーとして使う段階から、完全に自律したエージェントを投入する段階へと移行しつつあります。これまで SOC は false positive（誤検知）の多さに悩まされてきましたが、今後は 大量の true positive によって捌ききれなくなる SOC へと変わっていくという指摘が印象的でした。 2つ目の Speed については、攻撃者が Gemini をはじめとする大規模言語モデル（以下、LLM）で公開スクリプトを武器化し、アジア・アフリカ・ヨーロッパのメールシステムに対して大規模な悪用を展開している事例が紹介されました。攻撃者はすでに人間の速度ではなくマシンの速度で動いており、防御側も同じ速度で応戦しなければならないというのが Sandra 氏のメッセージです。 3 つ目の Sophistication に関しては、ロシアの軍事情報機関に紐づくサイバースパイグループ APT28 が、オープンソースの LLM をその場で呼び出してコマンドを生成し、静的検知を回避するマルウェアを展開している事例が取り上げられました。また、Mandiant の最新 M-Trends レポートでは、脆弱性の悪用までの平均時間（Mean Time to Exploit）が マイナス 7 日間 であったことが紹介されました。Time to Exploit は「ベンダーが脆弱性を公開した日」または「パッチをリリースした日」を起点（0日）としますので、平均の Time to Exploit がマイナス値であることは、パッチが公開される前に悪用が行われているケースが常態化していることを意味します。 攻撃者側も進化しており、WormGPT や HexStrike AI MCP といったツールを連鎖させることで、セキュリティに詳しくない犯罪組織でも高度なエージェント型攻撃を組み立てられるようになっています。 AI 自体を狙う新たな攻撃と、守るべき領域の拡大 AI 時代には、攻撃の手口だけでなく、守るべき対象そのものも変わります。 プロンプトインジェクション 、 モデル抽出 、 データポイズニング 、 モデル蒸留 といった AI 固有の攻撃が観測されている一方、既存の攻撃も AI で強化されています。例えば、ディープフェイク動画とメールを組み合わせたマルチモーダルフィッシングは、成功率を底上げする典型的な手法として紹介されていました。 同時に、組織が守るべき領域も拡大しています。モデル、エージェント、プロンプト、データパイプラインといった AI インフラ全体 が新たな保護対象となり、加えて従業員が独自に導入した シャドー AI 、サプライチェーン経由で組織に入り込む外部 AI コンポーネントまで、可視化と管理の対象が広がっています。 Google が持つ可視性とフルスタックの AI インフラ 圧倒的な可視性 Francis 氏は、Google がこの脅威状況に対して独自の可視性を持っていると強調していました。 Google は世界で 40 億台以上のデバイスとユーザーを保護しており、VirusTotal には 500 億を超えるファイルが蓄積されています。さらに Google Play 経由で毎日 2,000 億を超えるファイルがスキャンされているそうです。 こうした観測結果は、Google Threat Intelligence が四半期ごとに発行する AI Threat Tracker レポートとしてコミュニティへ公開されています。最新版では、モデル蒸留や AI の敵対的利用の継続的な統合といったテーマに加え、Gemini 以外の非 Google 製ツールに関する知見も含まれています。 参考 : GTIG AI Threat Tracker: Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use フルスタックの AI インフラと共同開発の優位性 Google はデータセンター間を結ぶ約 200 万マイル（約320万キロメートル）規模の光ファイバー網を自社で運用しており、各レイヤを軍事グレードのセキュリティで保護しています。AI モデル自体の保護についても、 Model Armor や Agent Gateway を通じて、プロンプトインジェクション・ツール汚染・機密データ漏洩を防ぐ取り組みが進んでいます。 Francis 氏が特に強調していたのは、Google がセキュリティ製品を AI インフラと 共同開発 （co-engineering）している点でした。 一般的なセキュリティベンダーは新モデルが公開された当日に初めて中身を理解し始めるため、製品に新モデルを組み込むまで半年から 1 年のタイムラグが生じます。これは AI のタイムラインでは「1〜2 世代遅れ」を意味します。 Google の場合は新モデルのリリース初日から最新機能をセキュリティ製品に取り込めるため、攻撃者と同じ世代の AI で対抗できるという主張です。 Mandiant の最前線の知見 最前線の侵害対応で得られる知見を製品に還元している点も、Google の強みとして繰り返し強調されていました。 現在進行中の重大な侵害事案の多くに Mandiant が関与しており、そこで直面する最も複雑な攻撃手口が、将来の攻撃検知のために Google Cloud のインフラへ組み込まれています。 参考 : Mandiant 自律型防御に向けた新機能 human-led から human-on-the-loop へ Google のアプローチは、従来の「human-led（人間主導）」や「human-in-the-loop（人が都度関与する）」から、「 human-on-the-loop （エージェントが主体で人は監督する）」へと移行しつつあります。エージェント群が重労働を担い、人間はポリシー策定と全体の監督に集中するというモデルです。 Triage and Investigation Agent Google SecOps の自律型セキュリティエージェントである Triage and Investigation Agent が一般提供（GA）となりました。 このエージェントはすでに 500 万件を超えるアラートをトリアージした実績があり、従来は人手で約 30 分かかっていた調査を 60 秒程度で完結 できるとのことです。false positive が増え続ける環境下で迅速な判断が求められる SOC にとって、インパクトの大きい機能といえます。 参考 : Use Triage and Investigation Agent to investigate alerts Threat Hunting Agent と Detection Engineering Agent Triage and Investigation Agent に加え、以下 2 つのエージェントが Preview 公開となりました。いずれも Mandiant の第一線の専門家による検証を経たものです。 # エージェント名 説明 1 Threat Hunting Agent Google の脅威インテリジェンスとベストプラクティスに基づき、環境内の新興脅威を継続的かつ大規模に探索する 2 Detection Engineering Agent 検知カバレッジのギャップを特定し、発見内容に基づいて新たな検知ルールを自動生成・展開する これらの即利用可能なエージェントに加え、カスタムワークフローを構築・ホストするための Google SecOps MCP Server （GA）も提供されています。 Dark Web Intelligence Dark Web Intelligence が Preview 公開となりました。Gemini を基盤としてダークウェブを自律的に探索し、組織のプロファイリングを行ったうえで関連する外部脅威を抽出する機能です。 従来のダークウェブ調査ツールは誤検知が多いことが課題でしたが、Dark Web Intelligence では 98% の精度 で外部脅威を特定できると紹介されました。Forrester の調査によれば、Google のアプローチを採用することで侵害リスクとコストを 17% 削減できるという結果も示されていました。 参考 : Bringing dark web intelligence into the AI era Wiz による開発者起点のクラウドセキュリティ 垂直サイロ型から水平型への転換 ここからは、Wiz の VP of Product Marketing である Jiong Liu 氏のパートです。 クラウドの普及により、多くの企業の開発チームはアイデアを数日から数週間でコードに変え、クラウドへ展開できるようになりました。開発が水平（horizontal）かつアジャイルになった結果、セキュリティにも開発者と同じ速度で動くことが求められています。 しかし、多くのセキュリティ組織は依然として垂直（vertical）にサイロ化されたままです。アプリケーションセキュリティチームはコードスキャナー、DevOps チームはパイプラインスキャナー、クラウドセキュリティチームはランタイム向けツール、SecOps チームはまた別のスタック、といった具合にチーム・ツール・プロセスが分断されています。結果として、サイロごとに大量のアラートが発生し、本当のリスクが見過ごされ、開発とセキュリティの間には摩擦が生じます。 Wiz は、コード・パイプライン・クラウド・ランタイムといったライフサイクル全体のコンテキストを、単一の セキュリティグラフ （Security Graph）に統合します。そこから、悪用されれば事業に重大な損害を与え得るアタックパス（攻撃経路）を特定する、というのが基本的な設計思想です。 アタックパスという形で可視化されると、開発者も「どこを、なぜ、優先して直すべきか」を直感的に理解できるため、セキュリティと開発が同じ土俵でリスクを潰していけるようになります。Jiong 氏は、Wiz の顧客のうち 50% 以上が「クリティカル課題ゼロ」を達成している と紹介していました。 Morgan Stanley の導入事例 続いて、Morgan Stanley の Global CISO である Alonzo Ellis 氏が登壇し、同社のセキュリティモデルの転換について語りました。 同社では従来、アプリケーション・クラウド・オペレーションの各セキュリティが垂直にサイロ化されており、マルチクラウド環境におけるシグナル収集の限界、アラート過多と優先度判断の難しさ、セキュリティとエンジニアリング間の摩擦といった課題が顕在化していたそうです。 Wiz の導入により、クラウドとランタイムのコンテキストが単一のグラフに統合され、個別の指摘ではなく、 完全なアタックパス としてリスクを把握できるようになったといいます。優先順位付けも、単純な深刻度スコアではなく「どれだけ露出しているか」「クラウンジュエル（最重要資産）にどれだけ近いか」で行えるようになりました。 Morgan Stanley からは、具体的な成果として以下のような数字が共有されていました。 Wiz CSPM と Wiz Sensor で、クラウド環境内の 65,000 ワークロード・170 万アセット を保護中。Wiz Code も全社展開を進めている マルチクラウド環境における検知・対処速度が、従来の 約 45 分（手動の対応ワークフロー込み） から、検知はミリ秒単位、対処は 90 秒未満に短縮。MTTD は 99.99% 減、MTTR は 98% 減 Wiz のコンテキストにより、これまで可視化できていなかった 16 件のクリティカルリスクを特定し、ゼロまで低減 買収対象企業のセキュリティアセスメントにかかる期間を、従来の数カ月から 2 週間未満 に短縮 Alonzo 氏は AI 時代のセキュリティについて、「AI を採用するかどうかが課題ではなく、自社のセキュリティモデルが AI の導入速度に追随できるかどうかが課題だ」と述べていました。エージェントによってスケール・速度・自律性が高まるぶん、エージェント型の攻撃も従来より速く進化するため、防御側もマシン速度で動く必要があるという主張です。 AI 時代に向けた Wiz の進化 3 つのエージェントによる水平・エージェント型モデル Alonzo 氏のパートを受けて、Jiong 氏は Wiz 自身の進化について説明しました。「AI 時代にもう一度 Wiz をゼロから作り直すとしても、何も変えないだろう」という発言が印象的で、コンテキストエンジンとして設計された Wiz は、人間のセキュリティチームだけでなく AI エージェントが推論を行う基盤としても最適である、という自信が語られました。 Wiz が提示したのは、「水平かつエージェント型（horizontal, agentic）」のセキュリティアーキテクチャです。中核を担うのは、以下3種類のセキュリティエージェントです。 Red Agent : 環境に対する継続的なペンテスター（ホワイトハッカー）として機能し、アタックサーフェイス（攻撃対象領域）のあらゆる露出ポイントを自律的にプロービングして、リスクが実際に悪用可能かを判定する Blue Agent : 発生中の脅威をリアルタイムに調査する Green Agent : 完全な修復計画を自律的に作成する。リスクを作り込んだ正確なコード行を特定し、修正を開発者または開発者が使うコーディングエージェントに直接プッシュする これにより、検知と同じスピードで修復まで進められるようになります。これまでリスクのトリアージは環境内の最大のボトルネックでしたが、そのボトルネックを取り除くのが狙いです。 クラウドネイティブから AI アプリケーション保護プラットフォームへ Wiz はこのタイミングで、従来のクラウドネイティブなセキュリティプラットフォームから、 AI アプリケーション保護プラットフォーム （AI application protection platform）へと進化したことを発表しました。 コード・クラウド・ランタイムを横断して AI アプリケーションとクラウドアプリケーションを保護するもので、パブリッククラウドだけでなくプライベートクラウドやオンプレミスにも対応します。 2 つの方向への拡張 Google Cloud Next '26 のタイミングで、Wiz は対応範囲を 2 つの方向に拡張することも発表しました。 1 つ目は「あらゆるプラットフォーム、あらゆる AI」への対応拡大です。以下の領域が新たにカバー範囲に加わります。 データプラットフォーム : Databricks、Snowflake エンタープライズ AI 基盤 : Gemini Enterprise Agent Platform、AWS AgentCore、Microsoft Copilot Studio、Salesforce の Agentforce のような SaaS クラウド境界 : Cloudflare、Akamai、Apigee、Vercel からのコンテキスト取り込み 2 つ目は、AI ネイティブな開発ライフサイクルへの入り込みです。コーディングエージェントへの可視性を獲得するだけでなく、従来にはなかった地点にセキュリティを組み込めるようになる、という点が強調されていました。 Prevention （予防） : Wiz hooks や Wiz skills を通じて、コーディングエージェントに「セキュリティの脳」を注入する。開発者がコーディングエージェントにコードを書かせた直後に、Wiz がそのコードとデプロイ内容を評価し、組織のポリシーに沿って修正までかける。開発者が翌朝 PC の前に座ったときには、すでにセキュアなコードが仕上がっている状態を目指す。 Backlog Burn-down （既存バックログの消化） : 事前構築済みの Wiz セキュリティスキルを IDE に直接取り込み、Green Agent の洞察をもとにコードベースの自己修復（self-healing）を進める。 包括的なコードセキュリティの全体像 Francis 氏は、Wiz・Google SecOps・Mandiant・ CodeMender を組み合わせた包括的なコードセキュリティの構想を次のように整理していました。 Wiz : 環境のマッピングとクリティカルリスクの修正 CodeMender : AI ベースでコードベースをスキャンし、コードレベルで修正を実行 Mandiant : 脆弱性対応の成熟度（vulnerability readiness）を高める知見の提供 Google SecOps : 継続的な検証と保護 Google Threat Intelligence がこれら全体を下支え Wiz でコードセキュリティ戦略を立て、CodeMender・Wiz・Mandiant で環境内の脆弱性を特定・優先度付けし、修復ワークフローを起動する。さらに Mandiant で継続的な要件の評価を行い、Google SecOps で監視を続ける、というフルスタックの構成です。 おわりに 本セッションを通じて繰り返し語られていたのは、 AI vs AI の時代において、防御側にも同じ世代の AI と、マシン速度で動くエージェント群が必要 、というメッセージでした。 Google の強みは、脅威状況に対する圧倒的な可視性、AI インフラとセキュリティ製品の共同開発、そして Mandiant の最前線の知見を Google Unified Security として集約している点にあります。 そこへ Wiz が加わったことで、開発者起点のクラウドセキュリティから SOC の自律運用、さらにはコードレベルの自動修復までを一気通貫で扱えるプラットフォームへと進化しつつある、というのが今回の発表全体から伝わる方向性でした。 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

G-gen の杉村です。当記事では、Google Cloud Next '26 in Las Vegas の、2日目の開発者向けキーノートに関する速報レポートをお届けします。 Developer Keynote イベントの概要 キーノートの概要 技術的な概要 Google が強調したかったこと 全体像 Build agents with Agent Platform Creating multi-agent systems Enhancing agents with memory Debugging agents at scale Intent to infrastructure with Gemini Cloud Assist Build and share no-code agents Securing agents 関連記事 Developer Keynote イベントの概要 Google Cloud Next は、1年に1回開催される、Google Cloud の旗艦イベントです。2026年は、ラスベガスのマンダレイ・ベイにおいて4月22日（水）から24日（金）までの3日間で開催されます。 参考 : Google Cloud Next 2026 - Las Vegas Conference 例年、2日目の「開発者向け基調講演（ Developer Keynote ）」では、Google が開発者やデータサイエンティスト、機械学習エンジニアなど技術者向けに伝えたい主張や新サービスの発表などが行われます。当記事では、Google Cloud Next '26 の2日目の開発者向け基調講演を、特に注目すべき発表にフォーカスして紹介します。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp Developer Keynote キーノートの概要 Google Cloud Next '26 の初日に行われたオープニングキーノート（基調講演）では、Google Cloud の新機能の発表や、顧客事例が紹介されました。また、AI/ML や生成 AI 向けの開発プラットフォームである Vertex AI が Gemini Enterprise Agent Platform に改名されリブランディングされたことも示されました。 blog.g-gen.co.jp 当記事で紹介する、2日目の開発者向けキーノート（Developer Keynote）では、ラスベガスでのマラソン大会を計画・シミュレーションするデモ AI エージェントを題材に、エージェントの開発、デバッグ、インフラ構築、セキュリティ強化をウォークスルーで紹介する体裁が取られました。 チーフエバンジェリストの Richard Seroter 氏と、Developer Relations Engineer の Emma Twersky 氏のコンビが全体をファシリテーションします。AI エージェント開発を7つのデモにわけて、各デモでスペシャリストが登壇して紹介しました。 Richard Seroter 氏と Emma Twersky 氏 7つのデモは、以下のとおりです。 Build agents with Agent Platform（ Agent Platform でエージェントをビルドする ） Creating multi-agent systems（ マルチエージェントシステムを作成する ） Enhancing agents with memory（ メモリでエージェントを強化する ） Debugging agents at scale（ エージェントを大規模にデバッグする ） Intent to infrastructure with Gemini Cloud Assist（ Gemini Cloud Assist を使用してインテントからインフラストラクチャを構築する ） Build and share no-code agents（ ノーコードエージェントを構築して共有する ） Securing agents（ エージェントをセキュアにする ） これを通じて、Google Cloud と AI を活用すると、いかに素早く簡単にエージェント開発が進められるかを強調しました。 7つのデモ 技術的な概要 このキーノートで紹介されたマラソン大会計画エージェントは マルチエージェント 、すなわち複数の AI エージェントが協調してタスクを行うエージェントです。このマルチエージェントの開発をウォークスルーする形で、様々な技術がプレゼンテーションされました。 エージェントの開発は、AI エージェント開発用ライブラリである Agent Development Kit （ADK）を用いて行います。 開発されたエージェントは、 Agent Runtime （旧称 Vertex AI Agent Engine）にデプロイされます。Agent Runtime はフルマネージドの AI エージェント向けコンピュートプラットフォームであり、組み込みのセッション管理機能とメモリ管理機能などを備えています。 別々にデプロイされた複数のエージェント間の通信は A2A などの標準プロトコルが担い、ガバナンスは Gemini Enterprise Agent Platform に含まれる Agent Registry や Agent Gateway 、 Agent Identity といった機能が担保します。また、 Wiz はソースコードと環境をエージェントがスキャンすることで、セキュリティリスクを高度に可視化し、対処法を提示できます。 また開発作業や運用は、 Agent Observability や Gemini Cloud Assist を組み合わせることで、使い慣れた IDE（統合開発環境）から AI の補助を借りつつ迅速に行うことができます。 Google が強調したかったこと 前述のように、Google Cloud そのエコシステムには AI エージェントの開発、デプロイ、保守を効率的に、かつセキュアに行う手段が揃っています。Google Cloud とそのエコシステムを使って AI エージェントを開発、デプロイ、保守することで、 セキュリティとガバナンスを保ちつつ高速に AI エージェント開発ができる ことを、Google が改めて示した形になります。 また、リブランディングされた Gemini Enterprise Agent Platform が、組織が 統制を効かせつつ AI エージェントを活用する ためのプラットフォームであることも強調されました。多数のエージェントがさまざまな部署によってデプロイされても、重複開発を防ぎつつ、エージェント同士が相互に連携しあい、タスクを自律的に行っていくのが理想です。 そのうえでセキュリティを担保するには、組織が適切なプラットフォーム上で統制を効かせることが不可欠です。Gemini Enterprise Agent Platform には、そのようなサービスが揃っています。 公式ガイド Agent Platform overview から引用 全体像 開発者向けキーノートでは、ラスベガスでのマラソン大会を計画するマルチエージェントを開発します。エージェントの構成は以下のようなものです。 Planner agent : skills と tools を使って走行ルートを決める Evaluator agent : ビジネス要件や地域ルールに従って走行ルートを評価する Simulator agent : 街への影響を見るため、走行ルート上でランダムな振る舞いをする人々をシミュレーションする このような 複数のエージェントが相互に協調 し、マラソン大会の計画というタスクを実行していきます。 開発するマラソン大会計画エージェント Build agents with Agent Platform 走行ルート計画を立てる Planner agents の開発は、Gemini Enterprise Agent Platform の Agent Designer を使って行われました。UI 上で自然言語でエージェントの振る舞いを定義して、Get code ボタンを押すと、AI エージェント開発用ライブラリである Agent Development Kit （ADK）で記述された Python コードが自動生成されました。初期のプロトタイプは、このようにして Agent Designer で生成できます。 Agent Designer Planner agents は内部的に instructions、skills、tools で構成されています。 instructions はエージェントの振る舞いを決めるテキストプロンプトです。 skills は、LLM が自身の知識だけで完結せず、外部ツールや API 等と連携して作業できるように部品化された「実行可能な拡張機能」または「テキストのプロンプト」のことです。Google に特有な言葉ではなく、近年の AI エージェントツールにおいてよく用いられる用語です。タスクを進める中で適切な振る舞いができるように、Google Maps や Geographic Information System（GIS）、レース監督といった Skills が定義されています。 skills からは tools を呼び出すこともできますし、別途配置された Python スクリプトを呼び出すことなども可能です。 tools は、AI エージェントが外部のアプリケーションや API を「道具」のように呼び出すための定義のことです。ここでは、 Google Cloud MCP server for Google Maps が Tools として定義されています。Google Cloud MCP server は、Google Cloud が提供するフルマネージドのリモート MCP サーバーです。Skills で定義された振る舞いにより、MCP server tools が呼び出され、エージェントはマップ情報を手に入れることができます。 instructions、skills、tools こうして構築された Planner agents は、 Agent Runtime （旧称 Vertex AI Agent Engine）にデプロイされます。Agent Runtime はフルマネージドのエージェント用コンピュートプラットフォームです。セッション、メモリ、モニタリングなどのエージェント用機能がネイティブに備わっています。 Creating multi-agent systems 次に、他のエージェントも考えます。ルートを評価する Evaluator agent は Planner agent のサブエージェントとして配置します。一方で街への影響をシミュレーションする Simulator agent は、別の Agent Runtime インスタンスにデプロイされており、Planner agent とは A2A プロトコルを使って通信します。A2A プロトコルは、エージェント間の通信を標準化するプロトコル（あるいはフォーマット）です。 参考 : Agent2Agent (A2A) Protocol マルチエージェントのアーキテクチャ A2A プロトコルでは、各エージェントは Agent card と呼ばれる情報を持ち、自らの役割や能力を広告（advertise）します。これにより、エージェント同士は、呼び出すべき他のエージェントの情報を知ることができます。 Agent card またここでは、エージェントは Gemini Enterprise Agent Platform の Agent Registry という共通レジストリに登録されます。Agent Registry はインターネットにおける DNS のようにイメージできます。エージェントは他のエージェントについて Agent Registry に問い合わせ、必要な能力を持つ他のエージェントを探し出すことができます。Agent Runtime にデプロイされたエージェントは Agent Registry に登録され、相互に発見可能になります。エージェント同士の通信は A2A に基づいて行われるので、複雑な API コントラクトを定義する必要がありません。 参考 : Agent Registry overview Agent Registry に登録されたエージェント一覧 Agent Registry を使ったアーキテクチャ またエージェントが効果的にグラフィカルなユーザーインターフェイスを生成するための標準規格である A2UI も紹介されました。これにより AI が動的に UI を生成できるため、フロントエンドの作り込みにかかる時間が軽減されます。 参考 : a2ui.org A2UI の one-shot prompting A2UI で生成された UI（右ペイン） Enhancing agents with memory Planner agent は、 セッション と メモリ を使います。セッションは、1回の処理内での短期的な記憶であり、メモリはセッションをまたいで記録される長期的な記憶です。どちらの記憶領域も Agent Runtime に標準で備わっており、ADK 上の実装でも少量のコードで済みます。メモリ機能により、Planner agent は過去に策定された計画を覚えておくことができます。 参考 : Agent Platform Sessions overview 参考 : Agent Platform Memory Bank メモリとセッションを定義するソースコード また Planner agent が適切な走行ルートを策定するためには、州や市の定めるルールなどを知っておく必要があります。PDF などの非構造化データをエージェントが参照できるようにするために、ここでは RAG（Retrieval-Augmented Generation）を用います。RAG 構成のためには、非構造化データをエンベディング情報に変換してデータベースに格納する必要があります。 メモリ、セッション、RAG デモでは Google Cloud のデータエンジニアリングエージェントを使い、エンベディング情報を生成するデータパイプラインを簡単に開発できるとされました。Lightning Engine for Apache Spark を使って PDF を読み取り、チャンク化して AlloyDB のテーブルに格納します。本来であれば、チャンク化されたテキストはパイプラインによって、または手動でエンベディング情報に変換される必要があります。しかしここでは、AlloyDB の Auto vector embeddings 機能が使用されました。これにより、テーブルに格納されたデータが、自動的にベクトル化されます。 参考 : Generate and manage auto vector embeddings for large tables AlloyDB に格納された自治体ルールは、tools を通じて呼び出されます。この tools は Google Cloud から提供されている AlloyDB のリモート MCP サーバーを使って、AlloyDB のベクトル化情報をクエリします。 AlloyDB に格納されたチャンクとエンベディング Debugging agents at scale 大量のエージェントが運用されている状況下では、モニタリング、デバッグ、および障害対応の負担が増大します。Gemini Enterprise Agent Platform にはこの状況に対応するための機能が用意されています。 Agent Observability は、Agent Runtime にデプロイされたエージェントのモニタリングを行います。 Gemini Cloud Assist は、Google Cloud における開発や運用を AI で補助する機能の総称です。 参考 : Agent observability 開発者や運用者は、使い慣れた IDE や CLI ツールから、MCP 経由で Gemini Cloud Assist を呼び出し、Agent Observability の情報を自然言語で取得できます。これにより、大規模な AI エージェント運用環境でも、情報取得、障害の解決法の示唆、修正コードの適用などを、すべて 自然言語により 行えることが示されました。 自然言語による AI アプリケーション運用 Agent Observability では、エージェントの動作のトレース情報を確認できます。 AI アプリケーションのトレース情報 また、Gemini Cloud Assist の一部である Gemini Cloud Assist Investigations を使うと、AI がトレース情報やログなどを読み取り、障害の root-cause analysis（RCA、根本原因分析）を行ってくれます。 参考 : Gemini Cloud Assist Investigationsを解説。AIエージェントでトラブルシューティング - G-gen Tech Blog Gemini Cloud Assist Investigations また、任意の IDE から MCP 経由で Gemini Cloud Assist を呼び出すこともできます。自然言語でエラーの原因を問い合わせると、MCP 経由で情報が取得されます。Agent Observability の情報や GitHub 上の issue の情報が収集され、原因や解決方法、修正コードまでもが AI により回答されます。わずか数分で、エラーを解消できました。 IDE からのソースコード改修 Intent to infrastructure with Gemini Cloud Assist Simulator agent は、マラソンランナーをシミュレーションする必要があります。ランナーをシミュレーションするためのサブエージェントである Runner agent を、ここでは Google Kubernetes Engine（GKE）上で稼働させ、またモデルとしては Gemma 4 を用います。Gemma は、Google が提供するオープンモデルです。ローカル環境や GKE のようなプラットフォーム上で動作できます。インフラとして GKE を、モデルとして Gemma を使うことで、Agent Runtime と Gemini のようにフルマネージドな組み合わせよりも、より細かいカスタマイズを行うことができます。 参考 : Gemma モデルの概要 GKE と Gemma デモでは、Simulator agent はもともと Cloud Run service にデプロイされていました。この Cloud Run の定義ファイルを自然言語による指示で GKE に変換します。IDE から MCP 経由で Gemini Cloud Assist を呼び出し、この変換を実環境に適用します。Gemini Cloud Assist が人間と Google Cloud の間の翻訳者として動作したことで、自然言語を使ってインフラをデプロイできました。 Google Cloud と Gemini の統合により、ソースコード開発だけではなくインフラ構築や運用も、自然言語で行えることが示されました。 自然言語で Cloud Run から GKE へ移行する Build and share no-code agents 次に、ここまでで開発した ハイコードエージェント （または フルコードエージェント ）と、Gemini Enterprise app で構築するノーコードエージェントの連携が示されます。飲み物や食料、仮設トイレなどのロジスティクスまわりを計画する Supply chain agent を、ノーコードエージェントとして構築します。 ハイコードエージェントとノーコードエージェントの協調 Agent Runtime にデプロイされたエージェントは、 Gemini Enterprise アプリ からも呼び出し可能になります。Gemini Enterprise アプリは、かつては単に Gemini Enterprise と呼ばれていた、エンタープライズ従業員向けの AI ツールです。 参考 : Gemini Enterpriseを徹底解説！ - G-gen Tech Blog Gemini Enterprise アプリから Planner agent を呼び出すと、A2UI によって動的に生成された UI が反映されています。開発したハイコードエージェントは、カスタムアプリの UI から使用できることはもちろん、Gemini Enterprise アプリからも使用できることが示されています。 ハイコードエージェントを Gemini Enterprise アプリから呼び出す 続いて、ロジスティクス周りの業務を行う追加のエージェントを構築するため、Gemini Enterprise アプリのノーコードエージェント構築機能を使います。Gemini Enterprise アプリの Agent Designer では、ノーコードエージェントを視覚的な UI で構築できます。また Agent Designer は、自然言語で指示することで、自動的にノーコードエージェントを構築してくれます。 Agent Designer Gemini Enterprise アプリの Agent Designer で開発したノーコードエージェントも Agent Registry に登録されるため、他のエージェントから呼び出すことが可能です。 続けて、Gemini Enterprise アプリの UI から Planner agent に「ロジスティクス計画を含めた、総合的な計画を策定して」と指示すると、Planner agent から Supply chain agent が呼び出され、総合的なマラソン大会計画が策定できることが示されました。つまり、フルコードで Agent Runtime にデプロイされているエージェントと、Gemini Enterprise アプリのノーコードエージェントとして構築したエージェントが A2A プロトコルを通じて連携し、タスクを実行した ことになります。 ハイコードエージェントからノーコードエージェントが呼び出された Securing agents マルチエージェント環境のセキュリティを向上するための施策も紹介されました。 Agent Gateway は、エージェント間のプロキシといえます。エージェント間の通信に Identity and Access Management（IAM）ポリシーを適用し、エージェントがどこから使用可能かを制御します。 参考 : Agent Gateway overview Agent Gateway はエージェント間のプロキシ Agent Registry に登録されたエージェントには、自動的に固有の Agent Identity が付与されます。汎用的なサービスアカウントは複数のワークロードに付与できてしまう可能性がありますが、Agent Identity は 必ずエージェントごとに一意 であるため、監査可能性とセキュリティの面で優れています。 Agent Identity Agent Gateway はこの Agent Identity をアクセス制御に使用します。Agent Gateway の Egress Agent Policy は、エージェントから他のエージェントや tools などへのアウトバウンド通信を制御し、ガードレイルの役割を果たします。エージェントからインターネットへの通信を制御することもできます。 Egress Agent Policy デモの環境ではアクセスが厳密に制御されていたため、Planner agent から予算情報を取得するための Finance MCP Server へのアクセスを許可するために、Agent Gateway 上で IAM Allow ポリシーを追加します。ポリシーには条件（conditions）を付与することもでき、ReadOnly のみ、といった指定が可能です。 IAM Allow Policy の追加 続いて、クラウド向けのセキュリティソリューション Wiz が紹介されました。Google は2026年3月に、Wiz の買収完了を発表しました。 Wiz は AI アプリケーションの ソースコードとクラウドの実環境をスキャン して、セキュリティグラフを生成します。また Wiz は、アタックサーフェイス（Attack surface）を検査してリスクを見つけだす Red agent や、根本対処の方法を提示する Green agent など、AI エージェントを用いています。 Wiz と AI アプリケーション デモでは、Planner agent とそのモデル、tools などが可視化されている Wiz の UI が示されました。インターネットからサービスアカウントを通じて Cloud SQL（データベース）に到達できてしまう可能性があることなどが、可視化されています。 セキュリティグラフ Red agent はこのような攻撃経路を評価してリスクを提示するので、ソースコードの静的評価などよりも優れています。 Red agent のリスク提示 Green agent はこれらに対する対策を提示します。デモでは Claude Code の skills を使って Green agent に対処法を提示させ、環境に適用させました。 Green agent の対処法提示（1） Green agent の対処法提示（2） このように、Wiz を使って AI アプリケーションのリスクとその対処法を提示させて、使い慣れた CLI ツールや IDE から自然言語で対処する方法が示されました。これは、開発スピードを遅延させずにセキュリティを確保できることを意味しています。 関連記事 Google Cloud Next '26 の関連記事は、以下の記事一覧を参照してください。開催期間中は、記事が随時公開されます。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の山崎です。当記事は、Google Cloud Next '26 in Las Vegas の1日目に行われたブレイクアウトセッション「 Real-time multimodality: Building seamless experiences with the Gemini Live API 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 Gemini Live API の概要と特徴 自律的エージェントのプラットフォーム Gemini Live API を支える3つの柱 Affective dialog とコンテキストの記憶 Gemini Live API の新機能の紹介 Live Avatar（2026年4月現在、プライベートプレビュー） Live Avatar のデモ 企業の導入事例 Shopify : サポートアシスタント「Sidekick」 Citibank : 次世代金融ウェルスアドバイザー Otto : e コマースにおける対話型アドバイザー スクウェア・エニックス : 「真の相棒」としての AI セッションの概要 本セッションでは、 Gemini Live API のプロダクトリードを務める Fabien Mathey 氏や Google の Wendy Yin 氏が登壇し、Gemini Live API の基本機能や、新機能である 「Live Avatar」 の発表を行いました。 さらに、事例紹介として、Shopify、Citibank、ドイツの e コマース大手 Otto、そして株式会社スクウェア・エニックスの取り組みが紹介されました。特にスクウェア・エニックスからは「ドラゴンクエスト」シリーズの生みの親である堀井 雄二氏が登壇し、ゲームと AI の融合がもたらす未来のビジョンについて語られました。 Gemini Live API の概要と特徴 自律的エージェントのプラットフォーム 2026年4月現在、Gemini Live API は Gemini Enterprise Agent Platform 上で稼働しています。このプラットフォームは、単に AI に「指示」を出す段階から、タスクを「委任」する段階への移行を促すものです。 AI が知能を持つだけでなく、真の自律性を持つエージェントとして機能し、チームメンバーと同等の独立性と信頼性をもって行動するためには、人間が AI と対話するための全く新しい手段が必要であり、それを実現するのが Gemini Live API です。 参考 : Introducing Gemini Enterprise Agent Platform, powering the next wave of agents Gemini Live API を支える3つの柱 Gemini Live API は、以下の3つの特徴があります。 オーディオ（音声） 高品質で双方向の音声通話を提供します。会話が流暢であるだけでなく、ユーザーが AI の発言を途中で遮る（ Barge-in ）ことも可能です。これにより、人間同士が対話しているかのような自然な会話が実現します。 ビジョン（視覚） Gemini Live API は、画像、ライブビデオストリーム、画面共有など、AI に提供された視覚情報をリアルタイムで処理し、状況を理解します。 エンタープライズ対応 本番環境にアプリケーションを展開するために不可欠な、高いセキュリティ、スケーラビリティ、そして信頼性を提供します。 Affective dialog とコンテキストの記憶 セッション内では、Gemini Live API の リアルタイム処理能力 を示すデモが行われました。最初のデモでは、AI に英語で詩を読ませている途中で発言を遮り、「フランス語で教えて」と要求しました。AI はユーザーから主導権を奪うことなく、瞬時に言語をフランス語に切り替えて詩を読み上げました。 続いて Affective dialog のデモが披露されました。ユーザーが「来週は私の誕生日で、100人の友達を招待したから盛大なパーティーになる」とワクワクしたトーンで話しかけると、AI も明るい声で応じます。しかし直後に、ユーザーが「実は全員に断られて一人になってしまった」と悲しそうなトーンで伝えると、AI はその声のトーンの変化を途中で検知し、瞬時に共感を示すようなトーンへと変化しました。リアルタイムの会話に応じて感情的なトーンを調整するこの機能は、AI との対話をより人間らしいものにします。 さらに、 コンテキストの記憶 機能についても紹介されました。会話の冒頭でカメラを通じてユーザーが提示した配送ラベルを AI が視覚的に認識します。その後、カメラからラベルを外した状態で「先ほどの配送ラベルの番号は何だったか」と尋ねると、AI は正確な番号を回答しました。Gemini Live API は、単に音声を聞くだけでなく、ビデオストリーミングを通じて得た視覚情報をセッション全体を通して記憶に留めることができます。 Gemini Live API の新機能の紹介 Live Avatar（2026年4月現在、プライベートプレビュー） 本セッションで、ライブビデオ生成機能を備えた Gemini 3.1 Live API が紹介されました。 このアップデートにより、新たに Live Avatar 機能が追加され、高品質な音声対話のエクスペリエンスに加えて、リアルタイムでユーザーを見つめ、流暢で自然な表情で反応するエージェントを構築することができます。 Live Avatar のデモ ジョンソン・クリニックという仮想の診療施設の予約受付を行う Live Avatar のデモが行われました。 アバターは仮想の受付担当者として振る舞い、患者のフルネームや生年月日を正確に聞き取ります。その後、対面か遠隔診療かの希望、症状、希望する医師といった条件をヒアリングし、空いている予約枠を提示し、予約を完了させました。 企業の導入事例 Shopify : サポートアシスタント「Sidekick」 E コマースプラットフォームを提供する Shopify は、加盟店向けのアシスタントである「Sidekick」を Gemini Live API で強化しました。 デモでは、加盟店がドメイン設定タスクを実行するにあたって、Sidekick に音声で質問すると、AI が画面の UI をベースに手順を段階的に音声で案内し、加盟店の作業をリアルタイムにサポートしました。 Citibank : 次世代金融ウェルスアドバイザー 金融機関である Citibank は、Gemini Live API と Live Avatar を搭載した次世代のウェルスアドバイザー・モバイルアプリ「Citi Sky」を発表しました。 デモでは、顧客の譲渡性預金が来週満期を迎えるという状況下で、アプリ内の Live Avatar が、複数の選択肢を音声と画面で提示し、顧客からの回答を受けると、その場で更新手続きを完了させました。 Otto : e コマースにおける対話型アドバイザー ドイツの e コマース大手 Otto からは、プロダクト責任者の Richard Brunner 氏が登壇しました。 Otto は「Otto, good decision（Otto、良い決断）」というブランドポジショニングを掲げており、オンラインショッピングでの検索を「顧客にシステムを理解させる」ものから、「システムが顧客のコンテキストやニーズを理解し、良い決断を支援する」ものへと再定義しました。 デモでは、「完璧なコーヒーメーカーを探している」と話しかけたユーザーに対して、AI が「手早く淹れたいか、淹れる過程を楽しみたいか」といったユーザーが求める条件を自然な会話で深掘りし、ユーザーの好みに合った商品を提案する様子が示されました。 Otto はテキストベースのチャットボットも並行して構築を行い、そのテスト結果によると、テキストベースのチャットボットではシステムとユーザーの間の平均対話ターン数が「4回」であったのに対し、音声対話では「11回」に増加しました。 これは、音声対話によるエンゲージメントの飛躍的な向上を示しており、より深いアドバイザリー体験の提供に成功したと述べました。 スクウェア・エニックス : 「真の相棒」としての AI セッションの最後には、株式会社スクウェア・エニックスより「ドラゴンクエスト」シリーズの生みの親である堀井 雄二氏が登壇しました。 堀井氏は「人生はロールプレイングゲーム（RPG）である」という哲学を持ち、画面の向こうにいる一人一人の顔を浮かべながら、どうすれば面白いと思ってもらえるか、どうすれば驚いてもらえるか、そればかりを考えてきたと語りました。そして今、AI という新しい魔法の道具に巡り合い、ゲームと AI を融合させることで、ユーザー1人1人の言葉や行動に AI が心をあるかのように寄り添い、理解し合える世界が作れるのではないかと述べました。 デモ映像では、ドラゴンクエストの代表的なモンスターをベースとした「スラミィ」が登場し、プレイヤーからの問いかけに答える様子や、画面上のプレイヤーの外見をスラミィが視覚的に認識し、自発的に話しかける姿が披露されました。 堀井氏は、AI との冒険の旅が、あなたの人生の本当の力になるとし、それこそが、堀井氏が Google Cloud、ゲームを愛する全ての人と一緒に作り上げたい新しいロールプレイングゲームの姿であると語りました。 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 13 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の荒井です。当記事は Google Cloud Next '26 in Las Vegas の1日目に行われた ブレイクアウトセッション「What's new with Gemini from Google DeepMind」の速報レポートをお届けします。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 Google DeepMind と Gemini モデルの進化 DeepMind の歴史と Gemini Gemini ファミリーのラインナップ 多様な AI モデルと最新技術の展開 幅広い AI ポートフォリオ 最新技術がもたらす期待効果 Google Cloud におけるエンタープライズ向け AI の実装 DeepMind と Google Cloud の緊密な連携 エンタープライズ環境における「プラットフォーム」と「信頼」の重要性 マルチモーダルモデルの組み合わせ（パイプライン化） Replit 社における Gemini と Vertex AI の活用事例 ソフトウェア開発の民主化と Vertex AI の利点 Replit Agent と評価の重要性 セッションの概要 当セッションでは、Google DeepMind が開発する Gemini モデルの進化と、多様な AI 技術のポートフォリオについて解説されました。また Google Cloud におけるエンタープライズ向けの仕組みや、Replit 社による Vertex AI を活用したソフトウェア開発の民主化事例が紹介されました。 参考 : How Google DeepMind builds AI | Google Cloud Blog Google DeepMind と Gemini モデルの進化 DeepMind の歴史と Gemini Google DeepMind は、2010年にロンドンで設立され、人工汎用知能（AGI）の構築をミッションとして掲げています。現在は Google の AI モデル開発を統合し、Gemini モデルの開発を牽引しています。Gemini は、推論能力、マルチモーダル理解、エージェント機能、そしてコーディング能力において優れたパフォーマンスを発揮します。 DeepMind の成り立ちや取り組みについては、YouTube でドキュメンタリー映画が公開されています。 youtu.be Gemini ファミリーのラインナップ Gemini は 2年強の歴史があり、2026年4月現在、最新バージョンは 3.1 です。また Gemini ファミリーでは以下のモデルが提供されています。 モデル 概要と特徴 Pro 最も大規模で高機能。エージェントの駆動や、コーディング、STEM（科学、技術、工学、数学）分野の作業に最適。 Flash 性能と効率のバランスが優れており、最も人気のある主力モデル。 Flash-Light 最小、最速で、最も高いパフォーマンス効率を実現。 多様な AI モデルと最新技術の展開 幅広い AI ポートフォリオ Google DeepMind は、Gemini 以外にも多様な領域で特徴ある AI モデルを開発しています。オープンウェイトモデルから生成メディア、ロボティクスに至るまで、幅広い技術が提供されています。主要なモデルと技術は以下の表の通りです。 モデル 概要と特徴 Gemma 20億から300億のパラメータサイズを持つオープンウェイトモデルです。端末上（オンデバイス）で効率的に動作するのが特徴です。特定のタスクに特化した訓練に適しており、幅広い言語をサポートするほか、音声や動画の理解機能も組み込まれています。 Gemini Live 音声の入出力を直接処理するネイティブな音声モデルです。遅延が少なく（低遅延）、表現力豊かな音声対話を実現します。話しかけている人間の感情を反映（ミラーリング）したり、状況に合わせて自発的に話すことができます。 Lyria 音楽生成に特化したモデルです。テキストの指示（プロンプト）や画像をもとに、ボーカル（歌声）を含む最大3分間の完全な楽曲を生成することができます。 Gemini Deep Research 市場調査などの深い探索的リサーチを行うAI エージェントです。1回の API 呼び出しで、ウェブ上の公開情報だけでなく、ユーザー独自のデータソースにもアクセスして情報を収集します。テキストだけでなく、チャートやインフォグラフィックを含むレポートを生成します。 Genie テキストや画像から、キーボードで操作可能なインタラクティブな2Dまたは3Dの世界を生成するモデル（Genie 3）です。エンターテインメントやゲーム、教育分野に加え、ロボットが現実世界と相互作用する方法を学ぶためのシミュレーション環境としても非常に重要とされています。 Gemini Robotics（ER） 物理世界で動く汎用ロボットを制御するためのプラットフォームです。「Embodied Reasoning (ER : 身体的推論)」という技術を用い、ロボットが視覚を使って状況を理解し、推論して行動できるようにします。Boston Dynamics 社の「Spot」ロボットに搭載され、オブジェクトのカウントや計器の読み取りなどに活用されています。 上記以外にも、Gemini が利用されている Google プロダクトは数多くあります。詳しくは以下の記事を参照してください。 blog.g-gen.co.jp 最新技術がもたらす期待効果 これらの多様なモデルを組み合わせることで、テキストや画像だけでなく、音声や動画、さらには物理的なロボット制御まで、幅広い業務プロセスを自動化できます。用途に応じた最適なモデルを選択することで、コストパフォーマンスを高めつつ、新しいユーザー体験や革新的なサービスを創出することが可能になります。 Google Cloud におけるエンタープライズ向け AI の実装 DeepMind と Google Cloud の緊密な連携 DeepMind は自社の AI がすべての業界や地域を変革することを目指しており、最終的な目標である人工汎用知能（AGI）の構築に向けて、多種多様なユースケースからトレーニングすることを重視しています。そのため、Google 製品の裏側で動いているものと同じ最先端の AI モデルを、Google Cloud でも利用できるようにしています。 Google Cloud に実装し、開発者や顧客からの多様なフィードバックを得ることで AI モデルの継続的な改善に役立てています。 エンタープライズ環境における「プラットフォーム」と「信頼」の重要性 AI エージェントは高度な処理能力を持っていますが、企業の独自データ（顧客情報や非公開データなど）をあらかじめ把握しているわけではありません。そのため、銀行の KYC（顧客確認）プロセスやバイオテクノロジー企業の臨床データ分析といった重要業務で AI を自律的に稼働させるには、単なる AI モデルだけでなく、強固な「プラットフォーム」が不可欠です。 Google Cloud では、人間の介入なしにエージェントを安全に運用するため、具体的に以下のような仕組みがすでに実装されています。 スケーラブル クラウドの圧倒的な規模（クラウドスケール）を最大限に活かし、人間の介入なしでも、大規模な処理を効率的にスケールできる仕組み。 柔軟性 適切な認証を行い、機密性の高い社内データであっても、安全かつ柔軟に情報を検索できる仕組み。 信頼に基づいて構築 AI を安心して自律稼働させるための基盤であり、主に以下の機能によって担保されます。 エージェントが「どのような決定を下したか」「どのデータにアクセスしたか」「どのようなデータを生成・分類したか」を後から確認できる仕組み。 行動をリアルタイムで監視し、ポリシー違反時に即座に動作を停止させる機能。さらに、過去の成功・失敗例をコンテキストに戻し、継続的に自己改善させる仕組み。 このような強固な仕組みがあるからこそ、クラウド上での大規模なソフトウェア開発（コード生成）はもちろん、銀行や医療機関といったセキュリティ要件の厳しい業界でも、AI エージェントの導入が急速に拡大しています。 マルチモーダルモデルの組み合わせ（パイプライン化） 今後の AI 活用の展望として、複数のマルチモーダルモデルを組み合わせたパイプライン化が挙げられます。例えば「Google 検索で現在地の情報をグラウンディングし、天気を調べ、その天気の様子を示す動画を生成する」といったように、異なる機能を持つモデルを連携させることで、より高度で複合的なユースケースが実現されつつあります。 Replit 社における Gemini と Vertex AI の活用事例 ソフトウェア開発の民主化と Vertex AI の利点 Replit 社は、クラウドベースのソフトウェア開発プラットフォームを提供し、誰もがソフトウェアを作成できる環境を目指しています。同社は、インフラストラクチャの基盤として Google Cloud を採用し、Vertex AI を通じて Gemini モデルを活用しています。Vertex AI を使用することで、インフラ管理の負担が軽減され、セキュリティやコンプライアンス要件を容易に満たすことができます。 これにより、Replit 社はモデルの運用ではなく、ユーザー体験の向上にリソースを集中できるという大きなメリットを得ています。 Replit Agent と評価の重要性 Replit 社が提供する Replit Agent は、ユーザーが自然言語で指示を出すだけで、アプリケーションの計画、コーディング、デプロイまでを自動で行う機能です。このエージェントの裏側では、Gemini モデルが複雑なタスクを複数のステップに分解し、実行しています。また、AI エージェントの品質を維持・向上させるためには、継続的な評価が不可欠です。 Replit 社では、オフラインでの厳密な評価と、実際のユーザーの行動データを基にしたオンライン評価を組み合わせることで、モデルの精度を継続的に改善しています。こうした仕組みから、開発者はインフラ構築や環境構築の手間から解放され、アイデアを即座にアプリケーションとして形にできます。 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 ・Google Cloud 認定資格 7冠 最近ハマっていることは、息子とのポケモンカード Follow @arapote_tweet

G-gen の杉村です。当記事では、Google Cloud Next '26 で発表された Gemini Enterprise アプリ の新機能について、公式の投稿記事「Gemini Enterprise for the agentic task force: introducing long-running agents, agentic collaboration spaces, advanced governance, and more」の内容をもとに紹介します。 はじめに 名称変更とリブランディング 作業の自動化 強化されたエージェントデザイナー Skills が使用可能に 長時間稼働エージェント エージェント管理用受信トレイ A2UI のサポート Data Insights エージェントによる統合分析 Deep Research エージェントの強化 チームの生産性 プロジェクト Canvas の実装 エンタープライズ・エコシステム エージェントギャラリーと Marketplace の統合 Bring Your Own MCP ガバナンス 概要 Agent Identity Agent Registry Agent Gateway はじめに 以下の Google 公式投稿を参考に、Google Cloud Next '26 で発表された Gemini Enterprise アプリ の新機能を紹介します。なお、当記事で紹介する機能の提供ステータス（GA / Preview / Private Preview / Coming Soon）は2026年4月23日現在の情報です。 参考 : Gemini Enterprise for the agentic task force: introducing long-running agents, agentic collaboration spaces, advanced governance, and more 当記事では、上記の記事から画像を引用しており、引用した画像には「画像は公式投稿より引用」と付記してあります。 他の Google Cloud Next '26 の関連記事は、Google Cloud Next '26 カテゴリの記事一覧から参照してください。 blog.g-gen.co.jp 名称変更とリブランディング これまで「Gemini Enterprise」と呼ばれていた Google Cloud の生成 AI ウェブサービスは、 Gemini Enterprise アプリ という名称に変更されました。 これは、Google Cloud の AI 開発プラットフォームである Vertex AI が Gemini Enterprise Agent Platform と改称されたことに伴います。Gemini Enterprise Agent Platform という大きなブランドのもとに、Gemini Enterprise アプリや、新しく発表された AI エージェント向けサービス、そして従来からの Vertex AI サービス群が格納された形です。 Gemini Enterprise Agent Platform（画像は公式投稿より引用） 作業の自動化 強化されたエージェントデザイナー 従来より Gemini Enterprise アプリには、ノーコードエージェントを構築可能なエージェントデザイナー（Agent Designer）が付属していました。このエージェントデザイナーは、自然言語と UI 上の簡単な操作で、タスクを順次実行するノーコードエージェントを簡単に構築できるツールですが、従来は「親」と「子」の2階層のエージェントしか作れませんでした。 従来のエージェントデザイナー しかし今後、エージェントデザイナーは強化され、より複雑なノード構成を取ることができるようになります。Human in the Loop（HITL）のチェックポイントも作成できるようになり、これまでよりも充実したノーコードエージェントを構築可能になります。 当機能は2026年4月23日現在、まだ使用可能になっていません。 新しいエージェントデザイナー（画像は公式投稿より引用） Skills が使用可能に Gemini Enterprise アプリで Skills が使用可能になります。Skills は、LLM が自身の知識だけで完結せず、外部ツールや API 等と連携して作業できるように部品化された「実行可能な拡張機能」または「テキストのプロンプト」のことです。Google に特有な言葉ではなく、近年の AI エージェントツールにおいてよく用いられる用語です。 公式の投稿に掲載されたスクリーンショットからは、追加した Skills はオン・オフを切り替えることができることが示唆されています。 当機能は2026年4月23日現在、まだ使用可能になっていません。 Skills（画像は公式投稿より引用） 長時間稼働エージェント 長時間稼働エージェント （Long-running agents）は、大規模で複数のステップからなるワークフローを実行できる機能です。数時間から数日間、バックエンドで自律的に動作します。 従来の Gemini Enterprise アプリのエージェントは、ユーザーからのテキストプロンプトをきっかけに短時間動作し、同期的に回答を返すものでした。長時間稼働エージェントは、それとは一線を画すものです。 当機能は2026年4月23日現在、まだ使用可能になっていません。 エージェント管理用受信トレイ エージェント管理用受信トレイ （Inbox for agent management）は、エージェントの動作の経過や結果を受け取るためのメッセージボックスです。 メッセージは「入力が必要」「エラー」「完了」などに分類されます。長時間稼働するエージェントとの関連が深いものと想定されます。 当機能は2026年4月23日現在、まだ使用可能になっていません。 エージェント管理用受信トレイ（画像は公式投稿より引用） A2UI のサポート A2UI （Agent-to-UI）プロトコルは、エージェントが UI を動的に生成してユーザーとインタラクティブにやりとりをするための標準を定めた、オープンプロトコルです。Google が開発し、Apache 2.0 ライセンスのもとに公開しています。 参考 : a2ui.org A2UI が Gemini Enterprise アプリでサポートされるようになり、カスタムエージェントはリッチな UI を生成してユーザーとやりとりをすることができます。 当機能は2026年4月23日現在、Preview 公開されています。 参考 : Register and manage agents using A2UI and A2A Data Insights エージェントによる統合分析 Data Insights エージェント は、Gemini Enterprise アプリから利用可能な組み込みエージェントです。既にリリースされている Data Insights エージェントでは、BigQuery のデータを自然言語で問い合わせ可能でした。 Data Insights エージェントの分析対象に、ドキュメント、メール、チャットなどの非構造化データも加えることができるようになると発表されました。 新バージョンは2026年4月23日現在、まだ使用可能になっていません。 Deep Research エージェントの強化 Deep Research エージェント は、既に利用可能な Gemini Enterprise アプリの組み込みエージェントです。Web サイトや社内のデータソースに対して多段的なリサーチを行い、重厚なレポートを生成します。 発表内容は、Deep Research エージェントが強化されるというものでした。強化の内容は詳細に明かされていませんが、「バックグラウンドで何時間も動作」という説明があることから、より長時間の実行が可能になる等のものであることが示唆されています。 新バージョンは2026年4月23日現在、まだ使用可能になっていません。 チームの生産性 プロジェクト Gemini Enterprise アプリに プロジェクト 機能が追加されます。Google Workspace、Microsoft OneDrive、Teams チャットなど、さまざまなソースのコンテキストを統合して、特定のプロジェクトに特化したエキスパートエージェントを作成できる機能として説明されています。 1日目のキーノートの発表とあわせて解釈すると、これはデータソースを限定することでハルシネーションを低減するような仕組みであると想定されます。Gemini Notebook（旧 NotebookLM） のように、特定のデータソースに基づいたタスクを Gemini Enterprise アプリに実行させられるものである可能性があります。 公式投稿のスクリーンショットからは、プロジェクトは複数の同僚と共有できるものであることが示唆されています。 当機能は2026年4月23日現在、まだ使用可能になっていません。 Gemini Enterprise アプリのプロジェクト（画像は公式投稿より引用） Canvas の実装 Gemini Enterprise アプリに Canvas が実装されます。Canvas は、リアルタイムの編集機能を備えたエディタであり、Google Workspace 等に付属の Gemini アプリには付属しています。 Gemini Enterprise アプリでは、Canvas がリアルタイムの共同編集機能を備えており、チームでドキュメントやスライドを共同編集できます。AI にスライドの雛形を生成させ、チームでそれを共同編集するという使い方が想定されます。この共同編集は、Gemini アプリにはない機能です。 さらに、Microsoft 365 との相互運用性も意識されており、Canvas で作成したドキュメントやスライドを一般的な Microsoft Office 形式にエクスポートできるようになります。 当機能は2026年4月23日現在、まだ使用可能になっていません。 Canvas（画像は公式投稿より引用） エンタープライズ・エコシステム エージェントギャラリーと Marketplace の統合 エージェントギャラリー は、Gemini Enterprise アプリ内で、ユーザーが使用可能なエージェントを一覧表示する画面です。備え付けの「Google が開発したエージェント」、管理者によって配布される「組織のエージェント」、自分でノーコードで作成した「マイエージェント」などがリストアップされます。 今後、エージェントギャラリーに Agent Marketplace が統合されます。Agent Marketplace ではサードパーティが販売する AI エージェントを購入し、Gemini Enterprise アプリにインストールできます。管理者の承認を経て購入されたエージェントのみが使用可能になります。 当機能は2026年4月23日現在、Preview 公開されています。 参考 : Add and manage A2A agents from Google Cloud Marketplace - Configure marketplace visibility Bring Your Own MCP Bring Your Own Model Context Protocol （BYO-MCP）の実装が発表されました。 この機能により、ノーコードエージェントが自社サーバーでホストされているツールを検出して実行できるようになり、自動化の可能性が広がるとされています。詳細の記述がないものの、Gemini Enterprise アプリに MCP を登録しておき、ノーコードエージェントから呼び出せるようになるものと考えられます。 当機能は2026年4月23日現在、まだ使用可能になっていません。 ガバナンス 概要 Gemini Enterprise Agent Platform 製品群に含まれる Agent Identity、Agent Registry、Agent Gateway といった機能により、組織内で複数の AI エージェントのガバナンスを、ガバナンスを発揮しながら相互に協働させられる世界観が示されました。 Google Cloud Next '26 の2日目に行われた Developer Keynote（開発者向け基調講演）でも、これらについては解説されました。以下の記事も参照してください。 blog.g-gen.co.jp Agent Identity Agent Identity は、AI エージェントに割り振られる、暗号化された固有の ID です。人間が使う Google アカウントや一般のアプリケーションが用いるサービスアカウントとも区別されます。コンテキストアウェアなアクセスと mTLS が前提となっており、意図しない実行環境以外では認証情報が使用できないようになっています。 Agent Identity は Gemini Enterprise Agent Platform Runtime（旧称 Vertex AI Agent Engine）および Gemini Enterprise で使用可能です。 Agent Identity は、既に一般公開（GA）されています。 参考 : Agent Identity overview Agent Registry Agent Registry は、組織内で AI エージェントや MCP サーバー、tools 等が発見されやすいよう、集約管理したり、ユーザーにキュレート（推奨して提示）したりするためのツールです。こちらも、従来からその機能の一部が Gemini Enterprise で使用可能になりました。 Gemini Enterprise アプリから Agent Registry に登録された A2A エージェントを呼び出せるほか、Gemini Enterprise アプリのエージェントデザイナーで開発したノーコードエージェントも Agent Registry に登録されます。また、独自開発したハイコードエージェント（フルコードエージェント）から、Gemini Enterprise アプリのノーコードエージェントを A2A プロトコルで呼び出すなど、 ハイコードエージェントとノーコードエージェント の相互連携も可能になります。 2026年4月23日現在、Agent Registry は Preview 公開されています。 参考 : Agent Registry overview Agent Gateway Agent Gateway は、ネットワークポリシー、データアクセス、セキュリティガードレールを一元管理できる、管理者向けソリューションです。プロンプトインジェクションなどのリスクからの保護を提供する、とされています。またコンテキストアウェアアクセスの能力を持っており、会社固有のルールを適用することで、承認されていないエンドポイントにエージェントがデータを送信してしまうことを防ぐともされています。 これらの機能は、 Model Armor 、 Identity and Access Management （IAM）、 Identity-Aware Proxy （IAP）などの既存サービスとの統合により実現されます。Access control policies によりエージェントがこれらのサービスを適切に使用するように交通整理するのが、Agent Gateway です。 2026年4月23日現在、Agent Gateway は Private Preview 公開されています。使用には Google への申請と、審査への合格が必要です。 参考 : Agent Gateway overview 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。当記事では、Google Cloud Next '26 のセッションの1つ、「 Natively Integrating Wiz CNAPP with Google Security Operations 」について、速報レポートをお届けします。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 Wiz の概要 アタックパスの可視化とトキシックコンビネーションの特定 Google SecOps と Wiz を統合するメリット アーキテクチャ 事例1 事例2 おわりに セッションの概要 本セッションでは、Google Cloud の SIEM/SOAR プロダクトである Google SecOps と、新たに Google ファミリーに加わった Wiz の統合について紹介されました。 登壇者は Google Cloud の David Shao 氏と、Wiz の Matt Zvolensky 氏の2名でした。昨今 Wiz と Google SecOps を組み合わせたときにどのようなシームレスな体験が得られるのかというお問い合わせが増えていることから、今回のセッション開催に至ったとのことです。 参考 : Google Security Operations（SecOps） 参考 : Wiz Wiz の概要 Wiz は、マルチクラウド、プライベートクラウド、AI ワークロード、データ分析ワークロードまでを幅広く保護するクラウドセキュリティプラットフォームです。 その中核として、クラウド環境全体を可視化・保護する Wiz Cloud の他にも、開発段階からセキュリティを担保するシフトレフト向けの Wiz Code 、またシフトライト側では、クラウド環境で実際に発生した脅威への検知・対応を担う Wiz Defend という 3つの製品で構成されています。 セッションでは、Wiz が裏側で稼働させている 3種類のエージェントも紹介されていました。アタックサーフェス（攻撃対象領域）をスキャンして攻撃者が狙う侵入経路を探す レッドエージェント 、脅威の進行をプロアクティブに食い止める ブルーエージェント 、そしてそれらを統括して「そもそもどう攻撃を未然に防ぐか」を設計する グリーンエージェント の3 つです。 参考 : Wiz Cloud 参考 : Wiz Code 参考 : Wiz Defend 参考 : シフトレフトとシフトライト アタックパスの可視化とトキシックコンビネーションの特定 攻撃者は、開発者のサイロやクラウドチームのサイロを個別に狙うのではなく、サイロを横断して侵入経路を組み立てる、という話が印象的でした。インターネットに露出したポートから侵入し、脆弱な VM を踏み台にして深く入り込み、Kubernetes の権限を悪用して最終的に PII へ到達する、といった経路がそのイメージです。 Wiz はこうした攻撃経路（アタックパス）を環境内でマッピングし、個々では問題がなくても組み合わさると危険になる要素、いわゆる トキシックコンビネーション を特定したうえで、対処方法まで提示してくれる、という点が強みとして紹介されていました。 内部ではグラフデータベースがリスクの優先順位付けを行っており、セキュリティ運用チームが「とにかくすべてにパッチを当てる」のではなく、本当に重要なアラートに集中できるようにするのが狙いとのことです。 Google SecOps と Wiz を統合するメリット Google SecOps に Wiz を組み合わせる理由として、セッションでは次の3点が挙げられていました。 # 理由 意図 1 シフトレフトの実現 攻撃が発生する前にプロアクティブに防御し、特定したリスクを Google SecOps にフィードする 2 SOC の効率化 Wiz が膨大なイベントをフィルタリングし、重要な脅威のみを Google SecOps に送信することで、ノイズを減らす 3 セキュリティの民主化 SOC だけでなく、開発者やクラウドチームが Wiz を使用することで、リスクを低減させる また、優先順位付けのインパクトを示す顧客事例も紹介されていました。 元のイベント数 : 約4億件 検知に該当 : 1,000 件 クラウドのコンテキストを踏まえた脅威 : 55 件 いますぐ対処すべき重要インシデント : 41 件 4億件近いイベントをすべて Google SecOps に流し込むことは可能ですが、Wiz 側で絞り込んだ 55 件、あるいは 41 件だけをフィードするほうが SOC 運用としてははるかに現実的だ、というのが本パートの主張でした。 アーキテクチャ 事例1 こちらの事例は、Wiz Defend が中心となってクラウド環境やアイデンティティに関する情報を収集し、先程のように優先順位付けを行ったうえで Google SecOps にログを連携し、一方の CrowdStrike やメール、ファイアウォール等のログはすべて Google SecOps が管理するという役割分担です。 Wiz と Google SecOps は API で接続されており、通信は双方向です。SOC 側でステータスを更新したりコメントを追加したりすると、その内容が Wiz 側にも反映されるため、同じインシデントを両プラットフォームから追いかけることができます。 事例2 こちらの事例は、 Gemini Code Assist を Wiz と Google SecOps の両方の MCP サーバーに接続し、自然言語で管理します。 「Wiz で何が起きているか？」、「攻撃経路が見つかった場合、Google SecOps を使って対応を自動実行できるか？」といった質問を自然言語で投げ、各プラットフォームの横断した調査と対応につなげられるといったニュアンスで紹介されていました。 参考 : Gemini Code Assist Standard / Enterprise の概要 おわりに 本セッションを通じて語られていたのは、Wiz と Google SecOps の組み合わせが「プロアクティブな防御」と「インシデント発生後の対応」の両方をカバーできるという点でした。 Wiz でアタックパスを事前に発見してシフトレフトを効かせつつ、万一侵害が発生した場合には Google SecOps と Wiz Defend を組み合わせて、被害範囲・攻撃者の狙い・侵入経路・クリーンアップ方針を短時間で把握していく。こうした流れが Wiz と Google SecOps の組み合わせによって生まれるシームレスな体験だとわかりました。 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

G-gen の武井です。当記事では、Google Cloud Next '26 in Las Vegas のセッションの1つ、「 Chrome Enterprise Premium & Google Unified Security 」の速報レポートをお届けします。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 AI 時代にブラウザセキュリティが重要となる理由 働き方の変化とシャドー AI のリスク セキュアブラウザというアプローチ Chrome Enterprise Premium と Google Unified Security Chrome Enterprise Premium の位置づけ Google Unified Security との統合 エコシステム連携 Google SecOps との統合 グローバルネットワークを活かした脅威対策 セッションの概要 本セッションでは、 Chrome Enterprise Premium （旧 BeyondCorp Enterprise）と Google Unified Security を組み合わせて組織のブラウザ防御を統合し、AI ツールを安全に利用するためのアプローチが紹介されました。 参考 : Chrome Enterprise Premium でブラウザのセキュリティを強化 参考 : Google Unified Security AI 時代にブラウザセキュリティが重要となる理由 働き方の変化とシャドー AI のリスク かつてはウェブ検索の入り口だったブラウザは、今では SaaS や自社アプリ、生成 AI ツールにアクセスする業務の中心的な立場へと変化しています。この役割の変化に合わせてブラウザ防御のあり方も見直す必要がある、というのが本セッションの出発点でした。 登壇者は、AI が従業員の生産性を大きく押し上げる一方で、社内に承認された AI ツールがない場合、従業員は手近な無料ツールや公開サービスへ流れていきやすい点に警鐘を鳴らしていました。 セッション内で紹介された調査によると、AI を使用している従業員の約 80% が生産性の向上を実感しており、そのうち 70% が無料または公開されているツールに依存しています。こうした「シャドー AI」が、機密データの外部流出や悪意のあるツールへの接続といった深刻なリスクの温床になっていると強調されていました。 セキュアブラウザというアプローチ AI 利用そのものを禁止するのは現実的ではなく、重要なのは安全に使える環境を整えることです。従業員が AI にアクセスする入り口がブラウザである以上、 ブラウザで制御をかけることが組織の AI 利用を守るうえで最も合理的 であるというのが登壇者の主張でした。 ネットワークやデバイスの管理状態に依存せず、ユーザーがどこで作業していても追従するため、一元的な適用ポイントとして機能する点がブラウザ制御の強みだと説明していました。 Chrome Enterprise Premium と Google Unified Security Chrome Enterprise Premium の位置づけ Chrome Enterprise Premium は、Google が 2011 年から自社向けに運用してきたゼロトラストセキュリティ（旧 BeyondCorp）の知見をベースに、ブラウザを軸として商用化されたプロダクトです。 セッションでは「セキュアブラウザというカテゴリの先駆け」として位置づけが紹介されていました。すでに広く使われている Chrome 上で機能を有効化するだけで導入でき、ユーザー側での追加作業がほとんど発生しない点も強みとして挙げられていました。 また、Chrome Enterprise Premium の制御は、 発見 （Discovery）、 適用 （Enforcement）、 ガバナンス （Governance）の 3つの観点で整理されていました。 環境内に存在する未承認の AI ツールをまず発見し、次に保護ポリシーを適用して危険な操作をブロックまたはログに記録し、さらにデバイスポスチャなどの条件を重ねることでガバナンスを効かせていく、というのが基本的な流れです。 Google Unified Security との統合 Google Unified Security は、以下のソリューションで構成される統合セキュリティプラットフォームです。 Security Command Center による脅威の可視性 Google Threat Intelligence による迅速な脅威検出 Google SecOps によるセキュリティ運用の最新化 Chrome Enterprise Premium による安全なブラウジング Mandiant Consulting によるセキュリティ専門知識 セッションでは、これらの中でもブラウザがユーザーと組織のデータの接点になる以上、Chrome Enterprise Premium は Google Unified Security の中でも欠かせない要素であると強調されていました。 エコシステム連携 Google SecOps との統合 Chrome が収集するテレメトリの価値は、Google SecOps と統合することで最大化されるというのが本パートでの主張でした。 Chrome 拡張機能のテレメトリや、強化された URL ウェブリスクデータを含む包括的な情報を Google SecOps へ送信できます。Google SecOps には脅威分析用の Threat Intelligence やダッシュボードが標準で用意されているため、Chrome 由来のデータでアラートを強化し、より迅速な対応ワークフローにつなげることができます。 グローバルネットワークを活かした脅威対策 Google Cloud のグローバルネットワークを基盤としているため、修正パッチを数十億台規模のデバイスへ一気に配布でき、他のブラウザよりも早くゼロデイ脆弱性へのアップデートが適用できます。 また、Google SecOps 以外にも Mandiant や Google Threat Intelligence と組み合わせることで、プロアクティブな脅威ハンティングや迅速なインシデント対応が実現可能である点も紹介されていました。 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

G-gen の佐々木です。当記事では、Google Cloud Next '26 で発表された Google Kubernetes Engine （略称 GKE）の新機能について、公式の投稿記事「What's new in GKE at Next '26」の内容をもとに紹介します。 はじめに Accelerating the agentic era GKE Agent Sandbox（GA） Redefining the scalability ceiling GKE Hypercluster（Private GA） Supercharging state-of-the-art inference Predictive Latency Boost（GA） Automatic KV Cache Storage Tiering（GA） Eliminating RL compute bottlenecks RL Scheduler（Preview） RL Sandbox（Preview） RL Observability and Reliability Dashboards（Preview） Scaling on custom metrics Intent-based Autoscaling on Custom Metrics（GA） はじめに 以下の公式投稿を参考に、Google Cloud Next '26 で発表された Google Kubernetes Engine （略称 GKE）の新機能を紹介します。なお、当記事で紹介する機能の提供ステータス（GA / Preview / Private Preview / Coming Soon）は2026年4月23日現在の情報です。 参考 : What's new in GKE at Next '26 他の Google Cloud Next '26 の関連記事は、Google Cloud Next '26 カテゴリの記事一覧から参照してください。 blog.g-gen.co.jp Accelerating the agentic era GKE Agent Sandbox（GA） GKE Agent Sandbox は、 gVisor によるカーネル レベルの隔離技術を活用し、信頼できないコードやツール、エージェントを安全に実行するためのサンドボックス環境です。Gemini のセキュリティ基盤にも採用されている技術が利用されています。 毎秒300個のサンドボックスを1秒未満のレイテンシで起動できる、業界で最もスケーラブルかつ低レイテンシのエージェント インフラストラクチャとされています。特に Google Axion プロセッサ を使用するノード上で実行した場合に優れたコストパフォーマンスを実現できます。 参考 : About Agent Sandbox 参考 : Google Axion プロセッサ Redefining the scalability ceiling GKE Hypercluster（Private GA） GKE Hypercluster は、単一の GKE クラスタで、最大 100万チップ、256,000ノード、さらに複数の Google Cloud リージョンにまたがるインフラストラクチャを管理できる、GKE の新しい実行モデルです。従来の GKE では最大 65,000ノードまでがサポートされていましたが、およそ4倍の規模の大規模クラスタを複数リージョンにまたがって展開することができます。 地理的に分散したインフラストラクチャを統合されたコンピューティングリソースとして扱えるため、グローバル規模の AI ワークロードを 1 つのクラスタとして運用することが可能になります。 GKE Hypercluster では、セキュリティを損なうことなくクラスタの規模をグローバルに拡張するため、Google のソフトウェア強化型セキュリティエンジンである Titanium Intelligence Enclave を採用しています。ハードウェア証明（Hardware-attested）と Pod 単位での隔離により、Google Cloud のプラットフォーム管理者やユーザー側のクラスタ管理者ですらモデルの重みやプロンプトに直接アクセスできない「no-admin-access」モデルを実現しており、グローバル スケーリングとセキュリティを両立させます。 Supercharging state-of-the-art inference Predictive Latency Boost（GA） Predictive Latency Boost は、 GKE Inference Gateway において、機械学習ベースの予測を用いたルーティングを行う機能です。 キューの深さ、メモリ負荷、キャッシュの局所性、バッチサイズなどをシグナルとした従来のヒューリスティックに基づく予測ではなく、リアルタイムで学習を行うモデル（軽量な XGBoost 回帰モデル）によるレイテンシ予測でルーティング先を決定することで、Time-to-first-token（TTFT : 最初のトークン取得までのレイテンシ）を最大 70% 削減できるとされています。手動でのチューニングも不要です。 参考 : Predicted latency based scheduling for LLMs Automatic KV Cache Storage Tiering（GA） Automatic KV Cache Storage Tiering は、LLM 推論における KV キャッシュ を、RAM、Local SSD、Cloud Storage / Lustre といった異なるストレージ階層間で自動的に階層化する機能です。ロングコンテキストを扱う際のメモリボトルネックを解消できます。 たとえば、10K トークンのシステムプロンプトでは、RAM にオフロードすることで TTFT を 40% 以上削減し、スループットを 50% 向上させます。50K トークンのシステムプロンプトでは、Local SSD にオフロードすることでスループットをほぼ 70% 向上させます。 参考 : Tiered prefix cache guide (GitHub) Eliminating RL compute bottlenecks RL Scheduler（Preview） RL Scheduler は、GKE 上で実行される強化学習（Reinforcement Learning : RL）の学習ループにおいて ストラグラー効果 （Straggler effect : 分散処理において、処理が遅延している一部のノードがバッチ全体の完了を遅らせる現象）を抑制し、バッチ間のテイルレイテンシを解消するためのインテリジェントな推論スケジューラです。 サンプリングリクエストを適切なワーカーにルーティングすることで、ワーカー全体のスループットを最大化します。 参考 : py-inference-scheduler (GitHub) RL Sandbox（Preview） RL Sandbox は、強化学習における報酬計算やツール呼び出しを、カーネルレベルで隔離されたサンドボックス上で実行するための機能です。サンドボックスはミリ秒単位でのプロビジョニングが可能であり、強化学習のサンプリングステップや報酬評価ステップに組み込みやすい設計となっています。 これにより、安全性を確保しながら、強化学習における学習ループ全体の実行効率を高めることができます。 RL Observability and Reliability Dashboards（Preview） RL Observability and Reliability Dashboards では、強化学習ワークロード向けの ダッシュボード が提供されます。強化学習アプリケーションのメトリクスやトレースが収集され、学習ループ全体のボトルネックやエラーの特定・最適化を迅速に行えるようになります。 参考 : Monitor reinforcement learning workloads on GKE Scaling on custom metrics Intent-based Autoscaling on Custom Metrics（GA） GKE において、Horizontal Pod Autoscaler（HPA）が カスタムメトリクス をネイティブに扱えるようになりました。本機能はエージェントレスのアーキテクチャを採用しており、Pod から直接メトリクスを取得して HPA によるスケーリングの判断に用いることができます。 従来、CPU・メモリ以外のメトリクス（例 : キューの深さ、リクエスト数など）に基づいてオートスケーリングを行うには、クラスタ外部の監視スタックを介してメトリクスを取得する必要がありました。この方式では、外部監視スタックに障害が発生した場合に連鎖的にスケーリングが停止するリスクがあります。 本機能は Pod から直接メトリクスを取得するため、スケーリングにおける外部の監視スタックへの依存を排除できます。 参考 : Expose custom metrics for autoscaling 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では、Google Cloud Next '26 で発表された Cloud Run の新機能について、公式の投稿記事「What's new for Cloud Run at Next '26」の内容をもとに紹介します。 はじめに Empowering the new era of developers Google AI Studio によるフルスタックアプリのビルドとデプロイ（GA） Cloud Run MCP サーバー（GA） Billing Caps（Coming Soon） Embracing the agentic era Gemini Enterprise Agent Platform との統合（Private Preview） Cloud Run Instances（Private Preview） Cloud Run Sandboxes（Coming Soon） Automatic scaling for high-demand applications コンテナへの SSH 接続のサポート（Private Preview） Cloud Run Service Bindings（Coming Soon） Running AI models NVIDIA RTX PRO 6000 Blackwell GPU のサポート（GA） Ephemeral Disk（Preview） はじめに 以下の Google 公式投稿を参考に、Google Cloud Next '26 で発表された Cloud Run の新機能を紹介します。なお、当記事で紹介する機能の提供ステータス（GA / Preview / Private Preview / Coming Soon）は2026年4月23日現在の情報です。 参考 : What's new for Cloud Run at Next '26 他の Google Cloud Next '26 の関連記事は、Google Cloud Next '26 カテゴリの記事一覧から参照してください。 blog.g-gen.co.jp Empowering the new era of developers Google AI Studio によるフルスタックアプリのビルドとデプロイ（GA） Google AI Studio から、Cloud Run、Firestore、ユーザー認証を組み合わせたフルスタックアプリケーションをワンクリックで構築・デプロイできるようになりました。 Google AI Studio を使用してバイブコーディングで作成したアプリをそのまま Cloud Run にデプロイでき、プロトタイプから本番環境までシームレスに繋がる点が特徴です。 参考 : Introducing the new full-stack vibe coding experience in Google AI Studio Cloud Run MCP サーバー（GA） Google Cloud では、 Model Context Protocol （MCP）に対応したフルマネージドのリモート MCP サーバーが提供されており、 Cloud Run MCP サーバー もその1つです。 これを利用することで、開発者や AI エージェントは MCP 経由で Cloud Run 上のアプリケーションをデプロイ・管理できるようになり、エージェントが ツール として Cloud Run を操作するユースケースを容易に実現できます。 参考 : Use the Cloud Run remote MCP server Google Cloud が提供している MCP サーバーについては、以下の記事をご一読ください。 blog.g-gen.co.jp Billing Caps（Coming Soon） Billing Caps は、月あたりの最大利用額を設定できる機能であり、設定した金額に請求額が達すると Cloud Run が非アクティブとなります。これにより、想定外のコスト発生を未然に防ぐことができます。 Cloud Run では、リクエスト数に応じた料金と、コンテナインスタンスが実行されている間の CPU、メモリの時間あたりの料金が発生します。この仕様により、DDoS 攻撃のような不測のトラフィック急増や、バグによるリトライのループなどによって利用料金が跳ね上がる恐れがあります。 従来の対策としては、Cloud Billing の 予算アラート を使用して、利用料金が閾値を超過したときにアラートを飛ばす方法がありました。この方法は利用料金の増加に対して自動で対処できるようなものではなく、実際の対処は手動で行うか、Pub/Sub などを使用して自前で実装する必要がありました。 Billing Caps を用いることで、このような状況でサービスを強制停止できるようになります。サービス停止による損害とのトレードオフとなるため、本番運用のサービスでは慎重に設定する必要があるでしょう。 Embracing the agentic era Gemini Enterprise Agent Platform との統合（Private Preview） Gemini Enterprise Agent Platform は Vertex AI のリブランディングであり、AI エージェントの構築・拡張・ガバナンス・最適化のための新しいプラットフォームです。 Cloud Run との統合により、Agent Platform の実験環境で開発したエージェントを、アプリケーションを再構築することなく、そのまま Cloud Run に移行することができます。 参考 : Introducing Gemini Enterprise Agent Platform 参考 : Agent Platform の概要 Gemini Enterprise Agent Platform との統合 Cloud Run Instances（Private Preview） Cloud Run では、用途に応じて Cloud Run Services、Cloud Run Jobs、Cloud Run Worker Pools という3つの実行モデルが提供されています。 Cloud Run Instances は、コンテナインスタンスの基本機能のみを提供する新しい実行モデルであり、コンテナを常駐させておくためのフルマネージドのインスタンスを個別に作成することができます。 Cloud Storage バケットのボリュームマウントに対応しており、長時間稼働するバックグラウンドエージェント（例 : OpenClaw）のホスティングに適しています。 以下は、インスタンスを作成するコマンド例です（公式ブログより引用）。 $ gcloud run instances create \ --image alpine/openclaw:latest \ --port 18789 \ --memory 4Gi \ --default-url \ --add-volume mount-path = /home/node/.openclaw, type= cloud-storage, bucket = $BUCKET_NAME Cloud Run Instances Cloud Run Sandboxes（Coming Soon） AI エージェントがコードやコマンドを自律的に生成・実行する場合、それらを隔離された環境で安全に実行することが求められます。 Cloud Run Sandboxes は、Cloud Run 上で実行されているエージェントが生成したコードを、隔離された使い捨てのサンドボックス環境で実行するための機能です。 以下は、アプリケーションからサンドボックスを起動してコードを実行する場合のイメージです（公式ブログより引用）。 app . post ( '/execute' , ( req , res ) => { const escapedCode = req . body . code . replace (/ " / g , '\\"' ) ; exec ( `sandbox do -- /usr/bin/python3 -c " ${ escapedCode } "` , ( e , stdout , stderr ) => { res . send ({ stdout , stderr }) ; }) ; }) ; Cloud Run Sandboxes Automatic scaling for high-demand applications コンテナへの SSH 接続のサポート（Private Preview） Cloud Run はフルマネージド サービスのため、実行しているコンテナの中身を直接見ることができず、トラブルシューティングの際は Cloud Logging に出力したアプリケーションログ、Cloud Monitoring のメトリクスが頼りでした。 稼働中の Cloud Run コンテナに SSH でアクセスできる機能が追加されたことにより、コンテナ内からプロセスの状態やファイルシステムを直接調査したり、ネットワーク到達性の確認ができるようになることが期待されます。 Cloud Run 上のコンテナへの SSH 接続は、以下のコマンドで実施できるようになるようです。 $ gcloud run services ssh SERVICE SSH 接続のサポート Cloud Run Service Bindings（Coming Soon） Cloud Run Service Bindings は、Cloud Run におけるサービス間通信に関する機能のようです。公式ブログ上で機能の詳細は公開されていませんが、複数の Cloud Run サービスを安全かつ容易に接続できるようになることが期待されます。 Cloud Run Service Bindings 以下の記事で解説しているように、従来の仕様では、Cloud Run から別の Cloud Run に安全にアクセスするためには、 限定公開の Google アクセス を有効にした VPC を経由したり、Cloud Run の前段に内部アプリケーションロードバランサーを配置して Private Service Connect エンドポイント を構成したりする必要がありました。 blog.g-gen.co.jp blog.g-gen.co.jp Running AI models NVIDIA RTX PRO 6000 Blackwell GPU のサポート（GA） Cloud Run で NVIDIA RTX PRO 6000 Blackwell GPU が利用可能になりました。 従来以上に大きなモデル（最大700億パラメータ超）をサーバーレスで実行でき、リクエストに応じたスケーリング（アイドル時はゼロスケール）により、高額になりがちな GPU の利用料金を節約できます。 Cloud Run における GPU 利用は、特に低トラフィックのモデル推論において、アイドル時の GPU コストを抑制できる点が大きな利点となります。 Cloud Run における GPU の詳細については以下の記事で解説しています。 blog.g-gen.co.jp 参考 : High-performance inference meets serverless compute with NVIDIA RTX PRO 6000 on Cloud Run NVIDIA RTX PRO 6000 Blackwell GPU Ephemeral Disk（Preview） Ephemeral Disk は、インスタンスごとに作成される一時的なディスクストレージであり、インスタンスの起動時に作成され、停止時に削除されます。 大きなファイルの処理やスクラッチ用途でメモリを消費していたワークロードを、メモリではなくディスクに逃がせるようになり、メモリ消費の増大によるパフォーマンス劣化や、割り当てるメモリ量を多く設定することによるコストの増加を抑制できます。 従来、このような問題はコンテナインスタンスに Cloud Storage をマウントすることによって回避する方法が一般的でした。Ephemeral Disk はインスタンスのローカルディスクとして扱われるため、ネットワーク経由で読み書きを行う Cloud Storage マウントよりも高パフォーマンスでの読み書きが可能です。 Ephemeral Disk Ephemeral Disk は Cloud Run の各実行モデルで利用可能です。詳細は以下のドキュメントを参照してください。 参考 : Configure an ephemeral disk for Cloud Run services 参考 : Configure an ephemeral disk for Cloud Run jobs 参考 : Configure an ephemeral disk for Cloud Run worker pools 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。当記事では、Google Cloud Next '26 in Las Vegas の、1日目のキーノートに関する速報レポートをお届けします。 Google Cloud Next '26 in Las Vegas イベント概要 キーノートの概要 Google が強調したかったこと Google Cloud と AI AI モデル State-of-the-Art な Google のモデル Apple との協業 Gemini Enterprise Agent Platform 概要 エージェントのプラットフォーム 技術要素とサービス Gemini Enterprise アプリの進化 Shaun White 氏のデモ AI Hypercomputer 概要 技術的な新発表 Agentic Data Cloud 概要 技術的な発表 Agentic Defense 概要 Google SecOps のエージェント Wiz Agentic Taskforce Gemini Enterprise for Customer Experience による顧客体験 Google Workspace による従業員体験 AI must be open 次回の Google Cloud Next 関連記事 Google Cloud Next '26 in Las Vegas イベント概要 Google Cloud Next は、1年に1回開催される、Google Cloud の旗艦イベントです。2026年は、ラスベガスのマンダレイ・ベイにおいて4月22日（水）から24日（金）までの3日間、開催されます。 参考 : Google Cloud Next 2026 - Las Vegas Conference 例年、初日のキーノート、すなわち基調講演では、Google が最も強調したい主張や新サービスの発表などが行われます。当記事では、Google Cloud Next '26 の第1日目のキーノート（基調講演）を、特に注目すべき発表にフォーカスして紹介します。 また当記事は、Next の開催期間中に新たな情報が判明した場合等に、情報が追記・修正される場合があります。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp 当記事は1日目のキーノート（Opening Keynote）について解説しています。2日目に行われたキーノート（Developer Keynote）については、以下の記事を参照してください。 blog.g-gen.co.jp キーノートの概要 Google Cloud Next '26 の初日のキーノート（基調講演）では、Google Cloud の新機能の発表や、顧客事例が紹介されました。 ここ数年の Google Cloud Next と同じように、2026年も発表は AI が中心でした。というよりも、発表内容に AI が関係しないものが1つもなかったと言えるでしょう。 以下の公式記事は、この日のキーノートの概要を紹介しています。 参考 : Welcome to Google Cloud Next ‘26 キーノート（1日目） Google が強調したかったこと Google は AI プレイヤー各社の中でも先んじて「 AI エージェント 」や「 Agentic AI 」を提唱してきました。 Google Cloud はこれまでも、AI をベースにした新サービスを開発したり、あるいは既存サービスに AI を統合させる取り組みを進めてきました。この日に紹介された技術には、これまで以上に、それらの AI が エージェンティック （Agentic）に動作することが強調されています。 ここでいう「エージェンティック」とは、AI が人間の指示に基づいて自律的に、つまり現在の状況やアクセスできるデータに基づいて自分で判断しつつ動作することを指します。2022年末に OpenAI が初めて ChatGPT を公開したとき、生成 AI は人間のテキストによるインプットに対してテキストでアウトプットを返すだけのものでした。しかし2026年4月現在、AI は、接客、流通、観光、マーケティング、セキュリティ、その他社内業務といった あらゆる分野と業界でエージェンティックに動作するものとなりつつある ことが示され、またそれを支える技術やサービスが Google Cloud と Google Workspace で提供されていることが紹介されました。 「エージェンティック」が並ぶ キーノートでは、「エージェンティック」という言葉が多用され、以下のような定義も見られました。 Agentic Data Cloud : データ分析基盤への AI エージェントの適用 Agentic Defense : 情報セキュリティへの AI エージェントの適用 Agentic Taskforce : 顧客体験（Customer Experience）や Google Workspace への AI エージェントの適用 今回のキーノートで、Google は改めて、「AI エージェント」や「Agentic AI」を推し進め、組織に変革をもたらすことが彼らの提供する価値である、ということを強調したといえます。Google Cloud や Google Workspace にネイティブ統合されたエージェンティックな AI 機能が次々と紹介され、そのいくつかは実際に使用可能になっています。 Google Cloud と AI 冒頭、Google Cloud の CEO である Thomas Kurian 氏が登壇しました。昨年の1年間を AI の adaption（採用）だけでなく、AI による transformation（変革）が見られた年であると位置づけました。 組織内で AI を本番運用するのに重要なのは、AI の統合されたスタックであると述べ、Google がインフラ、開発力、モデルとツール、そして製品といったあらゆる層をカバーしていることを強調しました。 Thomas Kurian 氏 続けて Google の CEO である Sundar Pichai 氏が動画で出演し、AI への継続的な投資を行っていること、また Google 自身が、AI によってコーディングやワークフロー業務の高速化の恩恵を受けていることを強調しました。同氏は続けて、 Gemini Enterprise Agent Platform を発表しました。Gemini Enterprise Agent Platform については後述します。 Sundar Pichai 氏 AI モデル State-of-the-Art な Google のモデル Thomas Kurian 氏は、Google の State-of-the-Art（最先端）なモデルとして、改めて以下のような生成 AI モデルを改めて紹介しました。 Gemini 3.1 Pro（Preview） : Google が開発する最先端の LLM Gemini 3.1 Flash Image（Preview） : SNS 等でも注目を集めた画像生成モデル。通称「Nano Banana 2」 Lyria 3 Pro（Preview） : 音楽生成モデル Veo 3.1 Lite（Preview） : 軽量な動画生成モデル また、Google Cloud では Vertex AI を通して、Anthropic の提供する Claude Opus 4.7 などのモデルも使用可能であることが改めて紹介されました。 いずれも Google Cloud Next 開催前までに発表されていたものであり、この日、新しい AI モデルの発表はありませんでした。 新しい AI モデルの発表はなし Apple との協業 この日、Thomas Kurian 氏は、Apple が Gemini の技術をベースにした新しい基盤モデルを開発中であることを明かしました。この新しいモデルは Apple Intelligence や AI アシスタントである Siri に使用され、本年（2026年）の後半に発表される予定であることが示されました。 Apple の新しいモデルは Gemini の技術がベース Gemini Enterprise Agent Platform 概要 Gemini Enterprise Agent Platform は、Google Cloud の AI モデルやエージェント開発、そして運用のプラットフォームです。Gemini Enterprise Agent Platform は、以下の公式投稿によると「Vertex AI の進化版」とされており、Google Cloud の機械学習の開発・運用プラットフォームである Vertex AI のリブランディング です。 参考 : Introducing Gemini Enterprise Agent Platform, powering the next wave of agents Vertex AI から Gemini Enterprise Agent Platform への名称変更に伴い、 各種サブプロダクトも名称が変更 されます（例: Vertex AI Search は Agent Search に）。変更の一覧は以下のリリースノートに掲載されています。 参考 : Google Cloud release notes - April 22, 2026 - Vertex AI to Gemini Enterprise Agent Platform naming changes これに伴い、これまで単に Gemini Enterprise と呼ばれていた Web サービスは、 Gemini Enterprise アプリ （Gemini Enterprise app）と名称変更されます。他にも、たとえば Vertex AI Agent Engine は Agent Runtime に、Vertex AI Search は Agent Search に、といったように、名称が変更されています。 Thomas Kurian 氏は日本でもユーザーが拡大している Gemini Enterprise アプリと、この日発表された Gemini Enterprise Agent Platform をエージェンティック時代（Agentic era）のエンドツーエンドツールと位置づけ、組織での AI 変革に用いることができる旨を強調しました。 Gemini Enterprise Agent Platform では、AI のエージェントのライフサイクルを Build、Scale、Govern、Optimize の4段階にわけており、それぞれに技術要素やサービスが存在します。 Gemini Enterprise Agent Platform エージェントのプラットフォーム Gemini Enterprise Agent Platform は、組織内に多数の AI エージェントがデプロイされている状況で、それらに統制を効かせ、複数のエージェントが相互に協調してタスクをこなすための、まさに AI エージェントのプラットフォームとなることが想定されています。 公式ガイド Agent Platform overview から引用 2日目の開発者向けキーノート（Developer Keynote）では、その世界観が詳細に示されました。以下の記事も参照してください。 blog.g-gen.co.jp 技術要素とサービス 以下は、Gemini Enterprise Agent Platform に内包される技術要素やサービスの一例です。 Low-Code Agent Studio は、従来より Agent Designer という名称で Gemini Enterprise に備えられていた、AI エージェントのローコード開発ツールです。後に行われたデモでは、従来は「親」と「子」の2層でしか構成できなかったノーコードエージェントが、より複雑な多層構造にできるようになることが示唆されました。 新しい Low-Code Agent Studio Agent Registry は、組織内で AI エージェントが発見されやすいよう、AI エージェントを集約管理したり、ユーザーにキュレート（推奨して提示）したりするためのツールです。こちらも、従来からその機能の一部が Gemini Enterprise で使用可能になっていました。 Agent Marketplace を使うと、サードパーティが販売する AI エージェントのカタログを閲覧し、購入して組織に導入することができます。 Agent Identity は、AI エージェントが持つ暗号化された ID（cryptographic ID）です。エージェント間での認証、もしくはエージェントから他のシステムへの認証をセキュアに行えるようにします。 Agent Gateway は、AI エージェントに適用するセキュリティポリシーを一括管理するためのツールです。いわば生成 AI 用の WAF（Web Application Firewall）ともいえる Model Armor 等と統合される見込みです。 Agent Observability は、ロギングを通じてエージェントの推論過程やパフォーマンスを監視するためのダッシュボードです。 これらのサービスの、発表当日現在のリリース状況は、以下のリリースノートに掲載されています。 参考 : Google Cloud release notes - April 22, 2026 - Initial release of Gemini Enterprise Agent Platform Gemini Enterprise アプリの進化 これまで単に Gemini Enterprise と呼ばれていた Web サービスは、 Gemini Enterprise アプリ （Gemini Enterprise app）と名称変更されました。 なお関連して、Gemini Enterprise の新機能として プロジェクト 機能（Projects in Gemini Enterprise）が発表されました。プロジェクトは、AI エージェント用のワークスペースです。この機能では、AI エージェントを Google ドライブ、Gemini Notebook（旧 NotebookLM）、Google チャットなどのデータソースと連携させたうえで、エージェントのメモリ（記憶）をプロジェクト内のファイルや会話に限定します。これによりコンテキストの汚染を防ぎ、AI の精度を向上させます。 また Microsoft 365 との相互運用性の強化も発表されました。Gemini Enterprise 内で使用可能なエディタである Canvas により、ドキュメントやスライドを作成・編集し、これらは Microsoft 365 ファイル（Word や PowerPoint）にエクスポートできます。Canvas の詳細は明らかになっていませんが、これまでも Gemini アプリに搭載されていた Canvas と類似のものである可能性があります。 Microsoft 365 と Gemini Enterprise の相互運用性の強化 Gemini Enterprise アプリで公開が予定されている新機能などについては、以下の公式投稿にもまとまっています。強化されたノーコードエージェント向けの Agent Designer や Skills の採用など、さまざまなアップデートが予定されています。 参考 : Gemini Enterprise for the agentic task force: introducing long-running agents, agentic collaboration spaces, advanced governance, and more また、以下の記事も参照してください。 blog.g-gen.co.jp Shaun White 氏のデモ オリンピックのスノーボードハーフパイプ競技で金メダルを3回取得した Shaun White 氏を壇上に招き、Gemini を中心とした Google Cloud の技術を使って、ハーフパイプの技を分析するデモが行われました。Google Cloud の技術がスポーツ業界を含めた多くの実務で利用されていることを示すものです。 Shaun White 氏のデモ AI Hypercomputer 概要 シニア VP 兼 AI・インフラストラクチャ担当チーフテクノロジストである Amin Vahdat 氏により、 AI Hypercomputer で複数の技術革新があったことが紹介されました。AI Hypercomputer は、ハードウェアとソフトウェアを高度に連携させた AI プラットフォームアーキテクチャの呼称です。 参考 : What’s next in Google AI infrastructure: Scaling for the agentic era Google の強みは、AI トレーニングおよび推論用のプロセッサである TPU や Google が開発する Arm ベースの CPU である Google Cloud Axion を始めとする物理層から、オープンソースの AI プラットフォーム、AI モデル、それらを応用したアプリケーションまで、すべてのレイヤを一気通貫で所有していることです。 加えて NVIDIA とのパートナーシップにより、Google Cloud 上では高性能な GPU を従量課金で利用できます。 Amin Vahdat 氏 技術的な新発表 この日、 NVIDIA Vera Rubin NVL72 が Google Cloud で新たに使用可能になる予定であることが発表されました。 また、Google の第8世代 TPU である TPU 8t と TPU 8i が発表されました。t はトレーニングに、i は推論（inference）に最適化されていることを意味しています。TPU 8t はトレーニングに特化した TPU です。ICI（Inter-Chip Interconnect）技術により、単一の「スーパーポッド」で最大9,600個の TPU と 2 PB の共有メモリまでスケールアップできます。TPU 8i は推論に特化しており、従来世代よりもコスト効率が80%向上し、数百万ものエージェントを同時に低コストで実行できるとされています。 参考 : Inside the eighth-generation TPU: An architecture deep dive さらに、大規模な AI ワークロード向けの新しいネットワーク技術である Virgo Network が発表されました。Virgo Network は「メガスケールデータセンターファブリック（Megascale data center fabric）」とされており、大量の TPU 等を低遅延・広帯域で接続する技術です。これにより、AI のトレーニング期間を大幅に短縮できるとされています。 参考 : Introducing Virgo Network, Google’s scale-out AI data center fabric 第8世代 TPU Agentic Data Cloud 概要 BigQuery を中心としたデータ分析基盤は、従来から Google Cloud の大きな強みでした。Google は、従来からのデータ分析技術にも、AI を効果的に適用しています。 チーフプロダクト&ビジネスオフィサーの Karthik Narain 氏が登壇し、データ分析基盤における AI エージェントの活用を Agentic Data Cloud と位置づけました。 参考 : What’s new in the Agentic Data Cloud: Powering the System of Action Karthik Narain 氏 技術的な発表 Knowledge Catalog は、以前 Dataplex Universal Catalog と呼称されてきた、フルマネージドのデータカタログサービスです。2026年4月10日にプロダクト名の変更がアナウンスされていました。BigQuery とネイティブに統合されているほか、後述の Cross-Cloud Lakehouse などとも統合されています。 新発表された Smart Storage は、非構造化データに意味付け（semantic meaning）を容易にする仕組みです。Cloud Storage に画像や PDF データが格納されると、自動的にアノテーションが生成され、付加されます。メタデータ生成を自動化するデータパイプラインの構築は不要です。これにより、構築の手間と運用の負荷なしに、AI エージェント向けに非構造化データを整備できます。Smart Storage は「Coming Soon」とされており、2026年4月23日現在ではまだ使用できません。 参考 : Storage innovations to accelerate your AI workloads at Next ‘26 Smart Storage 従来から Gemini Enterprise に搭載されていた Deep Research Agent の進化も発表されました。従来の Deep Research は、Gemini Enterprise に接続された SaaS や Google ドライブなどを横断検索して重厚なレポートを生成してくれる機能でしたが、このデータソースとして BigQuery が加わり、Knowledge Catalog との連携も示唆されています。 さらにこの日新たに発表された Data Agent Kit は、データサイエンティストを AI が支援する仕組みです。これは VS Code、Gemini CLI、Codex、Claude Code、Jupyter ノートブックなどで利用可能な skills、tools、extensions、plugins などであり、dbt、Apache Spark、Apache Airflow などのためのソースコード生成を補助します。これらは、既に発表されている Google Cloud MCP Servers などとも連携し、データエンジニアやデータサイエンスを加速します。 参考 : Google Cloud MCP Serversを解説 - G-gen Tech Blog Lightning Engine for Apache Spark は、Apache Spark 向けのサーバーレスのエンジンです。オープンソース版よりも最大4.5倍高速とされています。 Cross-Cloud Lakehouse は、オープンソースのテーブルフォーマットである Apache Iceberg を基盤技術として、Amazon Web Services（AWS）や Azure などと Google Cloud の間で、データを移動したりコピーしたりすることなく、データを分析可能にする技術です。他にも Databricks、Salesforce Data360、SAP、ServiceNow、Snowflake などのプラットフォームとの間で、データの相互運用を可能にします。 2026年4月16日に一般公開（GA）された Partner Cross-Cloud Interconnect for Amazon Web Services などにより、クラウド間のネットワーク接続も容易になっていることが、クラウドサービスをまたいだデータ分析をさらに容易にしています。 参考 : AWS 向け Partner Cross-Cloud Interconnect の概要 なお従来まで BigLake と呼ばれていた BigQuery の機能群は、Google Cloud Next が開催される直前の2026年4月20日に、Google Cloud Lakehouse への改名が発表されていました。Cross-Cloud Lakehouse はこの Google Cloud Lakehouse の派生型です。 参考 : What is Google Cloud Lakehouse? Cross-Cloud Lakehouse Agentic Defense 概要 近年、AI を使用したサイバー攻撃が増加しています。これらに対する防御にも AI を使用することを、 Agentic Defense として強調しました。さらに、本年のキーノートでは初めてセキュリティ企業 Wiz の幹部が登壇しました。Google は、2026年3月に Wiz の買収完了を発表したばかりです。 参考 : Next ‘26: Redefining security for the AI era with Google Cloud and Wiz Google SecOps のエージェント Google は、SIEM（Security Information and Event Management）製品である Google SecOps を擁しており、同製品は早くから AI との統合を推し進めていました。SIEM とは、複数の IT 機器やクラウドサービスなどのログを統合管理・分析し、セキュリティ侵害等を検知するためのソリューションのことです。 Threat Hunting & Detection Agent は、その名の通り、AI がプロアクティブに新しい攻撃パターン等を発見するエージェントです。Google SecOps に Preview 版として提供されます。 Google SecOps に新たに搭載される Dark Web Intelligence は、Google が提供する脅威インテリジェンスである Google Threat Intelligence の一部であり、Gemini と統合されたダークウェブ分析機能です。自動的に自組織に特化したプロファイリングが構築され、それに基づいてダークウェブに対する情報収集を行います。 参考 : Bringing dark web intelligence into the AI era Google SecOps は「Gemini-Native」 Wiz この日、Wiz の共同創業者であり VP of Product である Yinon Costica 氏が壇上に招かれ、Wiz の概要説明とデモが行われました。Google は2026年3月に Wiz の買収完了を発表したばかりであり、Wiz 関係者のキーノート登壇は初めてです。 Wiz の Yinon Costica 氏（右）の登壇 Wiz は、クラウドサービスや AI アプリケーションに特化したセキュリティソリューションです。複数サービスにまたがって、リスクの防止、脅威の検知、対処などを行うことができる製品です。 Wiz は AI アプリケーションの保護ができることも強調され、脅威の把握や可視化、対処において AI エージェントが自律的に動作することが示されました。 Wiz は様々なクラウドプラットフォームのセキュリティ情報を集約できることや、わかりやすいビジュアルのユーザーインターフェイスに定評があります。検知されたアラートの意味や対処法まで、AI を活用してわかりやすく提示されます。 現在のところ、Wiz の管理・運用ユーザーインターフェイスや販売プロセス、課金システムなどは Google Cloud と統合されていません。今後は Wiz と Google Cloud の統合がより進んでいく可能性があります。 Wiz のデモ SecOps と Wiz に関しては、以下のセッションレポートも参照してください。 blog.g-gen.co.jp Agentic Taskforce Gemini Enterprise for Customer Experience による顧客体験 Google はこの日、 Agentic Taskforce と称して、エンゲージメントと生産性の再定義にあたり、2つの課題として「顧客へのストレスのない体験の提供」と「従業員の業務効率の向上」を挙げました。 Google は2026年1月に開催された全米小売業協会（NRF）の年次カンファレンスで、 Gemini Enterprise for Customer Experience を発表しました。Gemini Enterprise が「組織内の従業員向け」である一方、この Gemini Enterprise for Customer Experience は、小売業界等における顧客（Customer）すなわちエンドユーザー向けのプロダクトです。 Gemini Enterprise for Customer Experience Gemini Enterprise for Customer Experience では、商品の検索から注文までを自然言語で処理できます。米国のピザチェーンである Papa John's Pizza が、Gemini Enterprise for Customer Experience を導入した事例が紹介されました。 シニアプロダクトマネージャーの Patrick Marlow 氏は、YouTube TV のカスタマーサポートが最近、Gemini Enterprise for Customer Experience を使った音声サポートを導入したことを明かし、デモを展示しました。同氏が電話をかけると、流暢な AI 音声が応じます。同氏が早口の英語で、スポーツ観戦に適したプランについて問い合わせると、「スポーツプラン」がニーズに合致していることや、プランの概要を説明する音声が返ってきます。 AI の回答を途中でさえぎって話しかけても、AI エージェントは適切に回答します。さらに、途中で隣にいる設定の友人のために「スペイン語で説明してくれ」と依頼すると、AI 音声はシームレスにスペイン語で回答します。 YouTube TV のカスタマーサポートのデモ 同氏は、このワークフローは CX Agent Studio という UI によって構築されており、構築には6週間しかかかっていないことを明かしました。 CX Agent Studio Google Workspace による従業員体験 Google Workspace の VP of Product である Yulie Kwon Kim 氏が登壇し、 Workspace Intelligence の新発表とデモが行われました。Workspace Intelligence は、Google Workspace に統合された AI エージェントです。Google ドライブ、ドキュメント、Gmail などの Workspace アプリを横断して情報を収集し、状況を認識して人間の代わりにタスクを行います。 参考 : Introducing Workspace Intelligence Workspace Intelligence Workspace Intelligence については通常のリリースノート（機能アップデートを通知する公式サイト）にも掲載されており、現地時間2026年4月22日から3日程度かけてすべてのテナントで使用可能になることが示されています。リリースノートでは、Workspace Intelligence によって、Google Workspace 内のすべての生成 AI タスクが Gmail、Chat、カレンダー、ドライブ（ドキュメント、スプレッドシート、スライドを含む）など Google Workspace 全体のデータに基づいて実行される ようになり、ユーザーが手動でコンテキストを提供する必要がなくなるとされています。当機能は管理者設定でオフが可能ですが、デフォルトはオンになっています。 参考 : Introducing Workspace Intelligence, with admin controls デモでは、Google Chat の Web インターフェイスで Ask Gemini（Gemini に質問）画面にアクセスすると、今日やるべきタスクが関連するメール等と紐づけられて表示されています。チャット上で Gemini にファイルの検索を指示したうえで、Skill を指定してスライドの作成を指示すると、Gemini は検索結果のファイルをもとに新しいプレゼンテーションスライドを作成しました。 Workspace Intelligence のデモ さらに、Microsoft 365 から Google Workspace への移行を高速に行うための Rapid Enterprise Migration も発表されました。組織全体を、Microsoft 365 から Google Workspace へ移行する速度が最大5倍向上するとしていますが、詳細は明らかになっていません。 Rapid Enterprise Migration AI must be open 最後に、CEO の Thomas Kurian 氏が再度登壇しました。同氏は「AI Must Be Open（AI はオープンであるべき）」と述べました。 選択肢があること（Freedom to chose）が重要であるとして、自由にモデルやプロセッサが選択可能であることなどを重視する Google の一貫した姿勢が強調されました。 AI must be open 次回の Google Cloud Next 2027年の Google Cloud Next は、2027年4月13日から15日に開催されることが明かされました。次回も、舞台はラスベガスのマンダレイ・ベイです。 次回もラスベガス 関連記事 Google Cloud Next '26 の関連記事は、以下の記事一覧を参照してください。開催期間中は、記事が随時公開されます。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では、法令 API を使用して日本の法令を検索できる AI エージェントを構築し、Google Cloud 上で動作するチャットボットとして利用できるようにします。 構成 法令 API エージェント Google Cloud 上の構成 当記事で使用するもの 法令 API Agent Development Kit（ADK） Vertex AI Agent Engine Cloud Run バックエンドの構築 バックエンドの概要 法令 API エージェントの開発 ディレクトリ構成 プロジェクトの準備 agent.py init.py requirements.txt .env ローカルでの動作確認（ADK Web UI） エージェントのデプロイ Google Cloud の認証と設定 Agent Engine へのデプロイ フロントエンドの構築 フロントエンドの概要 チャットボットの開発 ディレクトリ構成 プロジェクトの準備 app.py Dockerfile OAuth 同意画面の構成 Cloud Run へのデプロイ サービスアカウントの作成 デプロイ 動作確認 機能の拡張について 判例検索エージェントの追加 Memory Bank による長期記憶の実装 構成 法令 API エージェント 当記事では、 Agent Development Kit （ADK） で定義された AI エージェントが Gemini モデルを LLM として使用し、ユーザーの質問に応じて 法令 API を呼び出すように構成していきます。 具体的には、ユーザーがチャットで質問を送ると Gemini がその意図を解釈し、エージェントに定義されたツール関数（法令 API を呼び出す関数）を選択・実行します。法令 API から返された検索結果や条文データは Gemini によって要約・整形され、自然言語による回答がユーザーに返ります。 法令 API エージェントの構成 Google Cloud 上の構成 当記事では、ADK で定義した AI エージェントを Vertex AI Agent Engine に、エージェントを利用するチャットボットを Cloud Run にデプロイします。 この2つのサービスは、いずれも ユーザーによるインフラ管理が不要 なフルマネージドな実行基盤を提供し、また リクエストを処理しているときだけ料金が発生する という特徴があります。 また、Cloud Run で Identity-Aware Proxy（IAP） を有効化することで、Google アカウントで認証したユーザーのみがチャットボットを利用できるようにします。 法令検索チャットボットの構成 参考 : Identity-Aware Proxy の概要 当記事で使用するもの 法令 API 法令 API はデジタル庁が提供している「e-Gov 法令検索」に格納されている法令（法律・政令・省令など）のデータを取得できる API であり、HTTP リクエストで法令一覧や法令の本文を取得したり、キーワード検索を行ったりできます。 API 仕様書は OpenAPI Specification（OAS）に基づいて作成されており、Swagger UI 上で各エンドポイントの仕様確認やリクエストの試行が可能です。また、YAML 形式の仕様ファイルも公開されています。 API の利用にあたっては認証や API キーの取得は不要であり、誰でも無料で利用できます。 参考 : e-Gov 法令検索 参考 : 法令API Version 2 参考 : デジタル庁における法令API、法令×デジタルの取り組みについて Agent Development Kit（ADK） Agent Development Kit （以下、 ADK ）は、Google Cloud が提供する AI エージェント構築のためのオープンソース フレームワークであり、単純なタスクをこなすエージェントから複数のエージェントが協働する複雑なワークフローまで容易に実装できます。 参考 : Agent Development Kit 参考 : Agent Development Kit の概要 Vertex AI Agent Engine Vertex AI Agent Engine （以下、 Agent Engine ）は AI エージェントの実行基盤を提供するフルマネージドサービスです。 Agent Engine ではエージェントとのマルチターン会話を実現する セッション機能 が組み込みで提供されており、その他、エージェントの機能拡張に必要な様々な機能を利用できます。 Agent Engine の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Cloud Run Cloud Run は Google Cloud のマネージドなコンテナ実行環境でアプリケーションを実行できる、サーバーレス コンテナコンピューティング サービスです。 Cloud Run はエージェントの実行基盤としても有用なサービスです。Agent Engine と比較すると、インフラ環境のカスタマイズ性に優れる反面、セッションなどエージェント特有の機能は独自に実装していく必要があります。 当記事では、エージェント自体の実行基盤としては Agent Engine を利用し、フロントエンドとしてエージェントとやり取りを行うチャットボットを Cloud Run に構築していきます。 Cloud Run の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp バックエンドの構築 バックエンドの概要 バックエンドとして、法令 API を呼び出す AI エージェントを ADK で開発し、Agent Engine にデプロイします。 バックエンドとして構築する範囲 法令 API エージェントの開発 ディレクトリ構成 最終的なディレクトリ構成は以下の通りになります。 lawapi_agent ディレクトリで AI エージェントを実装していきます。 . ├── lawapi_agent │ ├── agent.py │ ├── .env │ ├── __init__.py │ └── requirements.txt ├── pyproject.toml # 自動で作成 └── uv.lock # 自動で作成 ADK ではエージェントのパッケージ（ここでは lawapi_agent ディレクトリ）内に agent.py を配置し、そこにツール関数とエージェント定義を実装します。 プロジェクトの準備 エージェント開発用のディレクトリでプロジェクトを初期化します。 # uv プロジェクト初期化 $ uv init --no-readme # パッケージの追加 $ uv add " google-adk>=1.27.3 " " google-cloud-aiplatform[agent-engines]>=1.142.0 " " httpx>=0.28 " " python-dotenv>=1.1 " agent.py エージェントが法令検索を実行するためのツールとして、以下のツール関数を実装し、それらを使用するエージェントを ADK で定義します。 ツール関数名 処理内容 search_laws_by_keyword キーワードによる法令の全文検索を行います。該当した法令の条文テキストも一部取得します。 list_laws 法令名（部分一致）や法令種別などの条件を指定して、法令の一覧や法令 ID を取得します。 get_law_detail 法令 ID や法令番号を指定して、対象の法令データ（全文または特定の要素）を取得します。 ツール関数の docstring は ADK を通じて Gemini に渡されるため、引数の説明を正確に記述することが重要です。 コード末尾の root_agent でエージェントを定義しています。使用するモデルや振る舞いを指示するプロンプト（ instruction ）と、上記3つのツール関数を指定しています。 import httpx from google.adk.agents import Agent BASE_URL = "https://laws.e-gov.go.jp/api/2" def search_laws_by_keyword (keyword: str , limit: int = 10 ) -> dict : """法令の本文をキーワードで全文検索します。 Args: keyword: 検索キーワード。AND/OR/NOT検索やワイルドカード(*,?)が使えます。 limit: 取得件数の上限（デフォルト10、最大1000）。 Returns: dict: 検索結果。ヒットした法令と該当箇所のテキストを含みます。 """ try : resp = httpx.get( f "{BASE_URL}/keyword" , params={ "keyword" : keyword, "limit" : limit}, timeout= 30 , ) resp.raise_for_status() data = resp.json() total = data.get( "total_count" , 0 ) items = [] for item in data.get( "items" , []): law_info = item.get( "law_info" , {}) sentences = item.get( "sentences" , []) items.append({ "law_title" : law_info.get( "law_title" ), "law_num" : law_info.get( "law_num" ), "law_id" : law_info.get( "law_id" ), "matched_sentences" : [ { "position" : s.get( "position" ), "text" : s.get( "text" )} for s in sentences[: 5 ] ], }) return { "status" : "success" , "total_count" : total, "items" : items} except httpx.HTTPStatusError as e: return { "status" : "error" , "error_message" : f "APIエラー: {e.response.status_code}" } except Exception as e: return { "status" : "error" , "error_message" : str (e)} def list_laws (law_title: str = "" , law_type: str = "" , category_cd: str = "" , limit: int = 10 ) -> dict : """条件を指定して法令の一覧を取得します。 Args: law_title: 法令名（部分一致）。例: "個人情報", "労働基準" law_type: 法令種別。Constitution,Act,CabinetOrder,ImperialOrder,MinisterialOrdinance,Rule,Misc から指定。 category_cd: 事項別分類コード（001〜050）。例: "046"（民事）, "002"（刑事） limit: 取得件数の上限（デフォルト10）。 Returns: dict: 法令一覧。法令名、法令番号、法令IDなどを含みます。 """ try : params = { "limit" : limit} if law_title: params[ "law_title" ] = law_title if law_type: params[ "law_type" ] = law_type if category_cd: params[ "category_cd" ] = category_cd resp = httpx.get(f "{BASE_URL}/laws" , params=params, timeout= 30 ) resp.raise_for_status() data = resp.json() total = data.get( "total_count" , 0 ) laws = [] for law in data.get( "laws" , []): info = law.get( "law_info" , {}) laws.append({ "law_title" : info.get( "law_title" ), "law_num" : info.get( "law_num" ), "law_id" : info.get( "law_id" ), "law_type" : info.get( "law_type" ), }) return { "status" : "success" , "total_count" : total, "laws" : laws} except httpx.HTTPStatusError as e: return { "status" : "error" , "error_message" : f "APIエラー: {e.response.status_code}" } except Exception as e: return { "status" : "error" , "error_message" : str (e)} def get_law_detail (law_id: str , elm: str = "" ) -> dict : """法令IDを指定して法令の本文を取得します。 Args: law_id: 法令ID（例: "322CO0000000016"）または法令番号（例: "昭和二十二年政令第十六号"）。 elm: 取得する要素のパス。省略すると全文を取得します。 例: "MainProvision-Article_1" で第1条を取得。 Returns: dict: 法令の本文データ（JSON light形式）。 """ try : params = { "response_format" : "json" , "json_format" : "light" } if elm: params[ "elm" ] = elm resp = httpx.get(f "{BASE_URL}/law_data/{law_id}" , params=params, timeout= 30 ) resp.raise_for_status() data = resp.json() law_info = data.get( "law_info" , {}) revision_info = data.get( "revision_info" , {}) law_full_text = data.get( "law_full_text" , {}) return { "status" : "success" , "law_title" : law_info.get( "law_title" ), "law_num" : law_info.get( "law_num" ), "amendment_date" : revision_info.get( "amendment_date" ), "law_full_text" : law_full_text, } except httpx.HTTPStatusError as e: return { "status" : "error" , "error_message" : f "APIエラー: {e.response.status_code}" } except Exception as e: return { "status" : "error" , "error_message" : str (e)} root_agent = Agent( name= "law_search_agent" , model= "gemini-2.5-flash" , description= "日本の法令を検索・閲覧できるAIエージェント" , instruction=( "あなたは日本の法令を検索・調査する専門アシスタントです。 \n " "e-Gov法令APIを使って、ユーザーの質問に回答してください。 \n\n " "## 使い方のガイドライン \n " "- ユーザーが法律の内容について質問した場合、まず search_laws_by_keyword や list_laws で該当する法令を特定してください。 \n " "- 特定の法令の条文を確認したい場合は get_law_detail を使ってください。 \n " "- 条文を引用する際は、法令名と条番号を明記してください。 \n " "- 法令の解釈については、条文の内容を正確に伝えた上で、一般的な解釈を説明してください。 \n " "- 専門的な法的判断が必要な場合は、弁護士等の専門家への相談を推奨してください。 \n " ), tools=[search_laws_by_keyword, list_laws, get_law_detail], ) init .py ADK がエージェントパッケージを認識するために必要なファイルです。以下の1行だけ記述しておきます。 from . import agent requirements.txt Agent Engine へのデプロイ時に使用される依存関係の定義です。ローカル開発ではルートの pyproject.toml が使用されるため、このファイルはデプロイ専用です。 google-adk httpx google-cloud-aiplatform[adk,agent_engines] .env Gemini モデルを使用するための Vertex AI の接続設定を記述します。 adk web コマンドによるエージェントのローカル実行時に自動で読み込まれます。Agent Engine 上では Vertex AI の設定が自動で適用されるため、このファイルはローカル実行専用のものです。 GOOGLE_GENAI_USE_VERTEXAI = 1 GOOGLE_CLOUD_PROJECT = < プロジェクトID > GOOGLE_CLOUD_LOCATION =asia-northeast1 ローカルでの動作確認（ADK Web UI） 以下のコマンドを実行すると ADK の Web UI がローカルで起動します。ブラウザで http://localhost:8000 を開き、チャットでエージェントが正しく動作することを確認します。 # ADK Web UI の起動 $ uv run adk web . # ----- 出力の抜粋 ----- INFO: Started server process [ 49931 ] INFO: Waiting for application startup. +--------------------------------------------------------------------------- -- + | ADK Web Server started | | | | For local testing, access at http:// 127 . 0 . 0 .1:8000. | +--------------------------------------------------------------------------- -- + INFO: Application startup complete . INFO: Uvicorn running on http:// 127 . 0 . 0 .1:8000 ( Press CTRL+C to quit ) チャット UI から法令に関する質問を送信してみます。 ADK Web UI を使用したローカルでのエージェントの動作確認 エージェントが質問内容から適切なツール関数を判断・実行することで、法令 API からデータを取得して回答を行っています。 エージェントのデプロイ Google Cloud の認証と設定 デプロイの前に、Google Cloud CLI での認証を行っておきます。 # プロジェクト ID をシェル変数にセット $ PROJECT_ID = < プロジェクトID > # 認証 $ gcloud auth login $ gcloud auth application-default login # プロジェクトの設定 $ gcloud config set project $PROJECT_ID Agent Engine へのデプロイ adk deploy コマンドを使用して、 Agent Engine にエージェントをデプロイします。 # Agent Engine にエージェントをデプロイ $ uv run adk deploy agent_engine \ --project = $PROJECT_ID \ --region = asia-northeast1 \ --display_name =" Law Search Agent " \ lawapi_agent デプロイが成功すると、以下のように Agent Engine のリソース名が出力されます。 ✅ Created agent engine: projects/ < プロジェクト番号 > /locations/asia-northeast1/reasoningEngines/ < エージェント固有の数字 > このリソース名はチャットボットのデプロイ時に使用するため、シェル変数にセットしておきます。 # シェル変数にリソース名をセット ENGINE_ID =projects/ < プロジェクト番号 > /locations/asia-northeast1/reasoningEngines/ < エージェント固有の数字 > フロントエンドの構築 フロントエンドの概要 機械学習モデルのデモ用 Web UI を容易に作成できる Gradio という Python ライブラリを使用してチャットボットを実装します。 チャットボットは、コンテナイメージ化して Cloud Run にデプロイし、Web サービスとして公開できるようにします。 フロントエンドとして構築する範囲 参考 : Gradio チャットボットの開発 ディレクトリ構成 フロントエンドはエージェントとは別のディレクトリで構築します。 最終的なディレクトリ構成は以下の通りになります。 app.py にチャットボットを実装していきます。 . ├── app.py ├── Dockerfile ├── pyproject.toml # 自動で作成 └── uv.lock # 自動で作成 プロジェクトの準備 エージェントとは別のディレクトリで uv プロジェクトを初期化します。 # uv プロジェクト初期化 $ uv init --no-readme # パッケージの追加 $ uv add " google-cloud-aiplatform[agent-engines]>=1.142.0 " " gradio>=5.29 " app.py app.py では以下の処理を実装しています。 vertexai.init() で Vertex AI に接続し、 agent_engines.get() で Agent Engine にデプロイしたエージェントを取得 Agent Engine のセッション機能（ create_session ）を使い、ユーザーごとにマルチターンの会話を管理 agent.stream_query() でエージェントにメッセージを送信し、ストリーミングで応答を受信 gr.Blocks で Gradio のチャット UI を構築 import os import uuid import gradio as gr import vertexai from vertexai import agent_engines AGENT_ENGINE_ID = os.environ[ "AGENT_ENGINE_ID" ] def get_agent (): vertexai.init( project=os.environ.get( "GOOGLE_CLOUD_PROJECT" ), location=os.environ.get( "GOOGLE_CLOUD_LOCATION" ), ) return agent_engines.get(AGENT_ENGINE_ID) agent = get_agent() def chat (message: str , history: list , session_state: dict ) -> tuple [ str , dict ]: user_id = session_state.get( "user_id" ) if not user_id: user_id = str (uuid.uuid4()) session_state[ "user_id" ] = user_id session_id = session_state.get( "session_id" ) if not session_id: session = agent.create_session(user_id=user_id) session_id = session[ "id" ] session_state[ "session_id" ] = session_id response_text = "" for event in agent.stream_query( message=message, user_id=user_id, session_id=session_id, ): if event.get( "content" ) and event[ "content" ].get( "parts" ): for part in event[ "content" ][ "parts" ]: if part.get( "text" ): response_text += part[ "text" ] yield response_text, session_state with gr.Blocks( title= "法令検索エージェント" , fill_height= True , css= """ .title-row { text-align: center; margin-bottom: 0; } .caption-row { text-align: center; margin-top: 0; color: #666; font-size: 0.9em; } .input-row { position: sticky; bottom: 0; background: var(--background-fill-primary); padding: 10px 0; } """ , ) as demo: gr.Markdown( "<h1 class='title-row'>⚖️ 法令検索エージェント</h1>" "<p class='caption-row'>e-Gov法令APIを使って日本の法令を検索します</p>" ) session_state = gr.State(value={}) chatbot = gr.Chatbot( show_label= False , scale= 1 , avatar_images=( None , "https://em-content.zobj.net/source/google/412/balance-scale_2696-fe0f.png" ), placeholder= "質問を入力すると、ここに会話が表示されます" , ) with gr.Row(elem_classes= "input-row" ): textbox = gr.Textbox( placeholder= "法令について質問してください（例: 個人情報保護法の目的は？）" , show_label= False , container= False , scale= 7 , ) def respond (message, history, session_state): history = history + [ { "role" : "user" , "content" : message}, ] yield history, session_state, gr.update(value= "" , interactive= False ) assistant_text = "" for text, updated_state in chat(message, history, session_state): assistant_text = text session_state = updated_state yield ( history + [{ "role" : "assistant" , "content" : assistant_text}], session_state, gr.update(interactive= False ), ) yield ( history + [{ "role" : "assistant" , "content" : assistant_text}], session_state, gr.update(interactive= True ), ) textbox.submit( respond, inputs=[textbox, chatbot, session_state], outputs=[chatbot, session_state, textbox], ) if __name__ == "__main__" : port = int (os.environ.get( "PORT" , 8080 )) demo.launch(server_name= "0.0.0.0" , server_port=port) Dockerfile Cloud Run にデプロイするためのコンテナイメージを定義します。uv の公式イメージからバイナリをコピーし、依存パッケージのインストールとアプリケーションの起動を行います。 FROM python:3.14-slim COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/ WORKDIR /app COPY pyproject.toml uv.lock ./ RUN uv sync --frozen --no-dev COPY app.py . EXPOSE 8080 CMD [ " uv ", " run ", " python ", " app.py " ] OAuth 同意画面の構成 Cloud Run で IAP を有効化すると、Cloud Run 上のサービスへのアクセス時に Google アカウントでのログインが求められるようになり、許可されたユーザーのみがチャットボットを利用できます。 プロジェクトで OAuth 同意画面の構成をまだ行っていない場合、以下のドキュメントを参照して実施してください。 参考 : OAuth 同意画面を設定し、スコープを選択する Cloud Run へのデプロイ サービスアカウントの作成 Cloud Run 用のカスタムサービスアカウントを作成し、Agent Engine へのアクセスに必要な Vertex AI ユーザー （ roles/aiplatform.user ）ロールを付与します。 # サービスアカウントの作成 $ gcloud iam service-accounts create lawapi-frontend \ --display-name =" Law API Frontend " # Vertex AI User ロールの付与 $ gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount:lawapi-frontend@ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/aiplatform.user " デプロイ gcloud run deploy コマンドで Cloud Run にデプロイします。 --source オプションを指定すると、Cloud Build によるコンテナイメージのビルドとデプロイが自動で行われます。 --no-allow-unauthenticated と --iap を指定することで、IAP で認証されたユーザーのみがアクセスできるようにしています。 --service-account で先ほど作成したカスタムサービスアカウントを指定します。 $ gcloud run deploy lawapi-frontend \ --source . \ --region asia-northeast1 \ --set-env-vars " GOOGLE_CLOUD_PROJECT= $PROJECT_ID ,GOOGLE_CLOUD_LOCATION=asia-northeast1,AGENT_ENGINE_ID= $ENGINE_ID " \ --service-account lawapi-frontend@ ${PROJECT_ID} .iam.gserviceaccount.com \ --cpu 1 \ --memory 1Gi \ --no-allow-unauthenticated \ --iap Cloud Run の各種設定項目の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp 動作確認 デプロイが完了したら、Cloud Run サービスの URL にブラウザでアクセスします。 # デプロイ後に出力されるサービス URL Service URL: https://lawapi-frontend- < プロジェクト番号 > .asia-northeast1.run.app IAP が有効化されているため、Google アカウントでのログインが求められます。 IAP で保護されたウェブアプリ ユーザー （ roles/iap.httpsResourceAccessor ）ロールが付与されたユーザーでログインします。 Google アカウントでログインする ログイン後、チャット画面が表示されるので、法令に関する質問を入力してエージェントの動作を確認します。 例えば「個人情報保護法の目的は？」と質問すると、エージェントが法令 API を通じて個人情報保護法の条文を検索し、第1条の目的規定を引用しながら回答を返します。 チャットボットの動作確認 エージェントは会話のコンテキスト（文脈）を保持しているため、続けて「罰則はある？」のように追加の質問をすると、同じ法令の関連する条文を検索して回答します。 セッションによってコンテキストが保持されているかを確認 機能の拡張について 判例検索エージェントの追加 当記事で構築したエージェントは法令 API による法令の検索に特化していますが、ADK や Agent Engine の機能を活用することで、さらに高度なユースケースに対応させることができます。 たとえば、法令の条文だけでなく、実際の判例や裁判例を参照したいケースも多くあります。ADK では google_search ツールが組み込みで提供されており、以下のように判例を Web 検索するエージェントを構築できます（ agent.py の追加実装例）。 from google.adk.tools import google_search case_search_agent = Agent( name= "case_search_agent" , model= "gemini-2.5-flash" , description= "日本の判例・裁判例をWeb検索するサブエージェント。判例の検索、要旨の確認、判例の解説ができます。" , instruction=( "あなたは日本の判例・裁判例を検索・調査する専門アシスタントです。 \n " "Google検索を使って、ユーザーの質問に関連する判例を検索してください。 \n\n " "## 使い方のガイドライン \n " "- 判例を検索する際は「判例」「裁判例」「最高裁」「判決」などのキーワードを組み合わせてください。 \n " "- 裁判所のウェブサイト（courts.go.jp）の情報を優先してください。 \n " "- 判例を引用する際は、裁判所名、判決日、事件番号を明記してください。 \n " "- 判例の要旨や判旨を正確に伝えてください。 \n " "- 判例の解釈については、一般的な学説・通説を踏まえて説明してください。 \n " "- 専門的な法的判断が必要な場合は、弁護士等の専門家への相談を推奨してください。 \n " ), tools=[google_search], ) このような判例検索エージェントを法令検索エージェントのツールの一つとして組み込むことで、エージェントはユーザーの質問内容に応じて適切なツールを使い分けます。法令と判例の両方に関わる質問では、両方のツールを同一ターンで呼び出すことも可能です。 from google.adk.tools.agent_tool import AgentTool root_agent = Agent( name= "legal_research_agent" , model= "gemini-2.5-flash" , description= "日本の法令検索と判例検索を統合したリーガルリサーチAIエージェント" , instruction=( "あなたは日本の法律に関するリーガルリサーチを支援する統合アシスタントです。 \n " "法令検索ツールと判例検索ツールを使い分けてください。 \n\n " "## ツールの使い分け \n " "- **search_laws_by_keyword / list_laws / get_law_detail**: 法律・政令・省令などの法令の条文を検索・閲覧したい場合に使ってください。 \n " "- **case_search_agent**: 判例・裁判例を検索したい場合に使ってください。 \n\n " "## ガイドライン \n " "- ユーザーの質問に応じて、適切なツールを選択してください。 \n " "- 法令と判例の両方が関連する質問の場合は、両方のツールを活用してください。 \n " "- 最終的な回答は、法令の条文と判例を総合して分かりやすくまとめてください。 \n " "- 専門的な法的判断が必要な場合は、弁護士等の専門家への相談を推奨してください。 \n " ), tools=[ search_laws_by_keyword, list_laws, get_law_detail, AgentTool(agent=case_search_agent), ], ) 以下のスクリーンショットは、法令と関連する判例を同時に質問した際のエージェントの動作例です。まず法令 API による条文検索が実施され、その後、ツールとして組み込んでおいた判例検索エージェントによる Web 検索が行われています。最終的には、それらの検索結果を整理したものが回答されています。 まず法令 API を使用して条文を検索するツールを実行する その後、判例検索エージェントが関連する判例を Web 検索・要約する 参考 : Google Search Grounding for agents Memory Bank による長期記憶の実装 当記事のチャットボットでは Agent Engine のセッション機能を使って会話のコンテキストを保持していますが、セッションはあくまで一連の会話の中での短期的な記憶です。 Agent Engine では Memory Bank という長期記憶の機能が提供されており、過去のセッションの内容をユーザーごとに記憶として蓄積し、新しいセッションでも参照できます。 例えば、あるユーザーが以前の会話である法令について調べていた場合、別の日に新しいセッションで「前回調べていた法律の最新の改正内容を教えて」と質問すると、Memory Bank に保存された過去のコンテキストをもとに適切な回答を返すことが期待できます。 このように、Memory Bank を活用することで、ユーザーごとにパーソナライズされた法令調査アシスタントを構築することが可能になります。 参考 : Vertex AI Agent Engine Memory Bank の概要 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐藤です。当記事では、BigQuery から外部ストレージを参照する2つの構成、従来の外部テーブルと BigLake テーブルの違いを検証した結果を紹介します。 はじめに BigLake とは 検証方法 検証環境の構築 Cloud Storage 外部テーブルと BigLake テーブル 検証1. 列レベルのアクセス制御 概要 外部テーブルの場合 BigLake テーブルの場合 検証2. 行レベルのセキュリティ 概要 外部テーブルの場合 BigLake テーブルの場合 検証3. パフォーマンス比較 概要 メタデータキャッシュの更新 クエリの実行 ジョブ詳細の確認 はじめに BigLake とは BigLake とは、Google Cloud が提供する分析用データベース BigQuery で、アクセス権限の委任を使用して、BigQuery 外部のストレージにあるデータをクエリするための仕組みです。BigLake の仕組みで作成されたテーブルは BigLake テーブルと呼ばれ、外部テーブルの発展系とされています。 参考 : BigLake 外部テーブルの概要 BigLake の概要については、以下の記事も参考にしてください。 参考 : BigQueryを徹底解説！(応用編) - G-gen Tech Blog - BigLake 検証方法 BigLake テーブルの中でもメタデータキャッシュの効果が高いとされる Hive パーティショニング 構成を用いて、外部テーブルと BigLake テーブルを1つずつ作成します。 参考 : 外部でパーティションに分割されたデータを使用する それぞれのテーブルが、「セキュリティ（アクセス制御）」と「パフォーマンス（スキャン量）」においてどのような挙動の差を示すかを検証します。具体的には、以下の3点に着目しました。 観点 概要 列レベルのアクセス制御 データカタログのポリシータグを付与し、アクセス制御が可能か 行レベルのセキュリティ CREATE ROW ACCESS POLICY 文によるフィルタリングが適用できるか クエリパフォーマンス メタデータキャッシュによって、スキャン量（処理されたバイト数）がどの程度削減されるか 検証環境の構築 Cloud Storage 検証のため、Cloud Storage バケットを用意します。その中にフォルダ構成を作成して、CSV ファイルを配置します。 当検証では、Hive パーティショニング分割テーブルを作成するために、日付ごとにフォルダを分割しました。各フォルダ内には、1ファイルあたり約70 KB の CSV ファイルを100個、用意しました。 gs://biglake-connect-test/ └ datasets/ └ hive_partitioned/ ├ dt =2026-03-25/ │ ├ sample_data_0.csv │ ├ sample_data_1.csv │ └ ... ├ dt =2026-03-26/ │ ├ sample_data_0.csv │ ├ sample_data_1.csv │ └ ... └ dt =2026-03-27/ ├ sample_data_0.csv ├ sample_data_1.csv └ ... 参考 : 外部でパーティションに分割されたデータを使用する 外部テーブルと BigLake テーブル 外部テーブルと BigLake テーブルを作成します。どちらのテーブルも、同じ Cloud Storage パスを参照しています。DDL は以下のとおりです。 従来の外部テーブル CREATE EXTERNAL TABLE `project_id.dataset_id.external_table` WITH PARTITION COLUMNS ( dt DATE , ) OPTIONS ( hive_partition_uri_prefix = " gs://biglake-connect-test/ " , uris=[ ' gs://biglake-connect-test/* ' ], format = " CSV " ); BigLake テーブル CREATE OR REPLACE EXTERNAL TABLE `project_id.dataset_id.biglake_table` WITH PARTITION COLUMNS ( dt DATE , ) WITH CONNECTION `project_id.asia-northeast1.sample_gcs_connect` OPTIONS ( hive_partition_uri_prefix = " gs://biglake-connect-test/ " , uris=[ ' gs://biglake-connect-test/* ' ], max_staleness = INTERVAL 4 HOUR, metadata_cache_mode = ' MANUAL ' , -- 今回は手動でメタデータを更新する format = " CSV " ); 参考 : パーティション分割テーブルに外部テーブルを作成する 参考 : Cloud Storage 用の BigLake 外部テーブルを作成する 検証1. 列レベルのアクセス制御 概要 BigQuery には特定の列に対してアクセス制限をかける 列レベルのアクセス制御 機能があります。この機能では、ポリシータグと呼ばれるタグを、テーブルの列に適用することでアクセス制御を実現します。 外部テーブルと BigLake テーブルのそれぞれに対して、スキーマ編集画面からポリシータグを適用できるかを確認します。 参考 : 列レベルのアクセス制御の概要 参考 : BigQueryの列レベルのアクセス制御・行レベルのセキュリティを解説 - G-gen Tech Blog 外部テーブルの場合 外部テーブルの場合、Google Cloud コンソール画面の BigQuery テーブルのスキーマ編集画面にポリシータグを追加するボタンが表示されず、ポリシータグを設定できないことがわかります。 外部テーブルのスキーマ編集画面 BigLake テーブルの場合 BigLake テーブルには、同じ画面に Add policy tag ボタンが表示されており、ポリシータグを追加できることがわかります。 BigLake テーブルのスキーマ編集画面 検証2. 行レベルのセキュリティ 概要 行レベルのセキュリティ は、Google アカウントやグループが、特定の値を持った行にだけアクセスできるように制御する機能です。この機能では、アクセスポリシーという設定を、テーブルに適用することで有効化します。 外部テーブルと BigLake テーブルのそれぞれに対して、アクセスポリシーを定義する SQL が実行できるかを検証します。 参考 : BigQuery の行レベルのセキュリティの概要 参考 : BigQueryの列レベルのアクセス制御・行レベルのセキュリティを解説 - G-gen Tech Blog 外部テーブルの場合 外部テーブルに対してアクセスポリシーを作成する SQL を実行しようとすると、サポートされていない旨の警告が表示されます。 外部テーブル BigLake テーブルの場合 BigLake テーブルの場合は、同様の SQL が問題なく実行できます。 BigLake テーブル 検証3. パフォーマンス比較 概要 BigLake テーブルは、メタデータキャッシュを利用して外部ファイルの情報を事前に把握することで、不要なスキャンを最小限に抑えるプルーニングを効率化します。この仕組みによって具体的にどれほどの差が生じるのか、実測データをもとに確認します。 参考 : パフォーマンス向上のためのメタデータ キャッシュ メタデータキャッシュの更新 以下の SQL を実行して、BigLake テーブルのメタデータキャッシュを手動で更新します。 CALL BQ.REFRESH_EXTERNAL_METADATA_CACHE( ' project_id.dataset_id.biglake_table ' ); 参考 : BQ.REFRESH_EXTERNAL_METADATA_CACHE クエリの実行 外部テーブルと BigLake テーブルのそれぞれに対して、日付パーティションを指定してフィルタリングを行う以下のクエリを実行しました。 SELECT COUNT (*) , dt FROM `project_id.dataset_id.table_name` WHERE dt = ' 2026-03-26 ' GROUP BY dt; ジョブ詳細の確認 外部テーブルの場合 外部テーブル BigLake テーブルの場合 BigLake テーブル 従来の外部テーブルに対して、BigLake テーブルでは、スロット時間は 約58分の1 、処理されたバイト数は 約98分の1 まで減少しました。 日付ごとのフォルダの中には約7 MB の CSV が格納されているため、従来の外部テーブルでもパーティショニングが効果を発揮しており、特定のフォルダ内のファイルのみが読み込まれていることがわかります。しかし BigLake テーブルの場合、追加のメタデータキャッシングにより、必要最小限のファイルのみが読み込まれていることがわかります。 佐藤 孝俊 (記事一覧) クラウドソリューション部 2026年3月にG-gen にジョイン。 スノーボードにより鎖骨骨折中。

G-gen の杉村です。Google が提供する Google AI Studio で発行した API キー が何らかの方法で他人に知られたことにより、悪意ある主体によって大量に Gemini モデルへのリクエストが発行され、利用料が過剰に発生する事象が観測されています。当記事ではこの事象の説明と、対処法について解説します。 事象と背景 事象の原因 キーが他人に知られた原因 不正利用の原因 対策 対策の一覧 対象者 予算アラートと異常検知の設定 予算アラート 請求先アカウントの異常検知 迷惑メールに分類されない設定 Spend Caps の使用（Private Preview） 使用状況の把握 把握方法 課金レポートの確認 Cloud Asset Inventory の確認 API キーの制限の徹底 概要 API キーの所在の把握 API キーの制限 API キーの制限に関する仕様変更 ベストプラクティスへの準拠 Google AI Studio から Agent Platform への移行 Agent Platform を第一選択肢に 移行する場合 追加のセキュリティ施策 Google AI Studio の使用禁止 管理者設定による使用禁止 短絡的に禁止しない 目的別のプロジェクト分離 事象と背景 Google が提供する Web サービスである Google AI Studio では、 API キー を発行することで、生成 AI モデル Gemini を API 経由で呼び出すことができます。 Web 上のブログ記事や SNS などの情報では、この Google AI Studio で発行される API キーを使って、AI CLI ツールや IDE、その他 AI 関連ツールから Gemini を呼び出す方法が頻繁に紹介されています。 一方で2026年4月現在、API キーが何らかの方法で他人に知られたことにより、悪意ある第三者によって大量に Gemini モデルへのリクエストが発行され、利用料が過剰に発生する事象が複数件、観測されています。ケースによっては、数百万円を超える課金が発生したとされています。こうした課金は、たとえ意図しないものであっても、原則としてユーザー側が支払う義務を負うことになります。 このような事象が発生しないよう、厳正な予防措置が必要です。また、後述のように、Google AI Studio は「個人開発者、研究者、学生」等を対象としたサービスとされています。企業等が API 経由で Gemini を使用する場合は、 Gemini Enterprise Agent Platform （旧称 Vertex AI、略称 Agent Platform）と サービスアカウント の使用が推奨されます。 当記事ではこの事象の説明と、対処法について解説します。 Google AI Studio の画面 事象の原因 キーが他人に知られた原因 API キーが「流出」する原因は、複数が考えられます。 クライアントや Web ページへのハードコーディング（Google Maps や Firebase など、キーがクライアント側に露出することが前提の場合を含む） GitHub 等の公開リポジトリへのアップロード その他、意図しない公開 特に、Google Maps や Firebase など、キーがクライアント側に 露出することが前提 の API キーが「流出」し、Gemini API の不正利用に繋がったケースは注目に値します。これらの API キーは公式に「シークレット（機密情報） ではない 」と案内されているほか、HTML にハードコードする手法が紹介されているなど、クライアント側に露出することが前提であるとされてきました。そのため、このキーが他人に知られることは、厳密にいうと「流出」ではありません。 Google AI Studio における API キーの一覧 不正利用の原因 問題は、これらの API キーは Google Cloud プロジェクトに所属 する API キーであり、 他の API の呼び出しにも共通して使用できる ものであるという点です。 API キーには 制限 （restrictions）を設定できます。API キーの制限とは、アクセス可能な API を限定する設定のことです。クライアントに露出しているキーは、Google Maps API や Firebase API などに制限されているべきです。制限がかかっていないキーを使うと、そのキーが所属するプロジェクトで 有効 （enabled）になっている他の API を呼び出すことができます。 参考 : API キーに制限を追加する | API Keys API Documentation 過剰請求が発生したケースの中には、当初は API キーが所属するプロジェクトで Gemini API が有効化されていなかったため問題なかったものの、 あとから Gemini API が有効化された ことで、制限なしの API キーによって Gemini API を呼び出せるようになってしまった、という経緯のものがあったと考えられます。 Google Cloud における API キーの一覧 対策 対策の一覧 意図しない過剰請求を避けるには、以下のような対策の一部または全部を行うことが望ましいといえます。 予算アラートと異常検知の設定 使用状況の把握 API キーの制限の徹底 Google AI Studio から Agent Platform への移行 Google AI Studio の使用禁止 目的別のプロジェクト分離 上記は、概ね1から順番に行うことが望ましいですが、必ずすべてを実行する必要があるわけではありません。各項目の内容を理解して、必要性を判断してください。特に、1から3までは被害の拡大を防ぐために優先して順に実施することが望ましいです。4から6については、組織のポリシーや開発体制に合わせて適切なものを並行して検討、実施してください。 対象者 上記対策は、主に情報システム担当部門等、組織全体の情報セキュリティを管理する立場の方が実施することを想定したものも含まれていますが、開発者や利用部門などの一般利用者も参考にするべき対策も含まれています。 管理者、開発者、その他の一般利用者のいずれも、上記の対策を理解して検討することが推奨されます。 予算アラートと異常検知の設定 予算アラート 万が一、API キーやその他の認証情報が流出して API が不正利用され、過剰請求が発生した際には、その状況をすぐに検知して対策する必要があります。迅速に検知できるよう、請求先アカウントに 予算アラート を設定してください。 参考 : 予算と予算アラートの作成、編集、削除 | Cloud Billing | Google Cloud Documentation 参考 : 予算アラートの設定方法 - G-gen Tech Blog 予算アラートは、組織レベル、フォルダレベル、プロジェクトレベルのそれぞれで作成できます。それぞれのレベルで必要な権限が異なるため、詳細は上記のドキュメントを参照してください。 予算アラートの設定画面 請求先アカウントの異常検知 請求先アカウントには、予算アラートとは別に、 異常検知 （Anomaly detection）も設定可能です。 異常検知を正しく設定すると、過去の支出状況と比較して、異常と判断された場合に、請求先アカウントに「請求先アカウント管理者」ロールを持っている人や、該当のプロジェクトに「オーナー」ロールを持っている人に対してメール通知等を発報することができます。 参考 : 費用の異常を表示して管理する 参考 : Google Cloud請求先アカウントの異常検知（Anomaly Detection）を解説 - G-gen Tech Blog 迷惑メールに分類されない設定 予算アラートや異常検知のメールが Google から正しく届くよう、以下のドキュメントに掲載されているメールアドレス等からのメールが迷惑メールに分類されたりすることのないよう、正しく設定しておく必要があります。 参考 : Google Cloud サービスに関する重要なお知らせ - MSA チームが使用するメールアドレス Spend Caps の使用（Private Preview） 2026年4月23日、Google Cloud の旗艦イベント「Google Cloud Next」で、 Spend Caps 機能が公開されました。Spend Caps を使うと、Google AI Studio、Gemini Enterprise Agent Platform（旧称 Vertex AI、略称 Agent Platform）、Cloud Run、Cloud Run functions において、プロジェクトレベルのコスト制限を設けることができます。設定した予算に達するとアラート、もしくは API トラフィックの一時停止が可能です。 ただし2024年4月現在、当機能は Private Preview であり、使用には申請のうえ Google の審査が入ります。必ず使用できるわけではないうえ、Preview 中のサービスは本番環境での使用が推奨されていません。当機能が一般公開（GA）されるまでは他の対策を充実することを検討してください。 参考 : AI時代に向けた次世代FinOps 使用状況の把握 把握方法 単一または少数のプロジェクトの場合 単一または少数の Google Cloud プロジェクトの範囲内であれば、Google AI Studio と API キーの利用状況の確認は簡単です。 Google AI Studio の API キー一覧画面（ https://aistudio.google.com/api-keys ）にアクセスすることで、主に自分が発行した API キーの一覧を確認できます。 ただし、ここに一覧表示されるキーは、同画面で「インポート」した Google Cloud プロジェクトに紐づくキーのみです。企業等の組織全体のキー発行状況を確認するには、すべての Google Cloud プロジェクトをインポートする必要があり、これは UI の仕様からも現実的ではありません。 Google AI Studio における API キーの一覧 組織全体の場合 情報システム担当部門等のクラウド管理者が、Google Cloud 組織全体で Google AI Studio や API キーの使用状況を把握するためには、以下のような複数の手法が知られています。 課金レポートの確認 Cloud Asset Inventory の確認 以下に、それぞれの手法の概要と、その手法で何が把握できるのかについて解説します。 課金レポートの確認 自組織の 請求先アカウント の 課金レポート を確認することで、Google AI Studio 経由の Gemini API に関する課金の発生有無を把握できます。 これにより把握できることは「Google AI Studio 経由の Gemini API が使用され、料金が発生しているプロジェクト ID の一覧」です。把握できるスコープは「その請求先アカウントと紐づいているすべてのプロジェクト」です。 この操作を行うには、該当の請求先アカウントに対して少なくとも請求先アカウント閲覧者（ roles/billing.viewer ）ロールが必要です。権限が不足している場合、後述の手順で請求先アカウントを選択できません。 手順は、以下のとおりです。 Google Cloud コンソール（ https://console.cloud.google.com/ ）にログイン 検索ボックスに「レポート」と入力 サジェストされた「レポート / プロダクト ページ・課金」をクリック プルダウンメニューから請求先アカウントを選択 「レポートに移動」ボタンをクリック この画面で、以下の操作を行います。 画面上部の「グループ化」フィルタで「プロジェクト」を選択 画面上部の「サービス」フィルタでサービスを「Gemini API」のみに絞る 必要に応じて画面上部の「期間」フィルタで、期間を「使用日」「先月」に設定 これにより画面下部に、Google AI Studio 経由の Gemini API に関する課金が発生しているプロジェクトの一覧や、その課金額が一覧表示されます。 課金レポートによるプロジェクトの特定 Cloud Asset Inventory の確認 組織レベルで Cloud Asset Inventory を確認することで、Gemini API が有効化されているプロジェクト、すなわち Google AI Studio の API キーが発行されている可能性が高いプロジェクトを特定できます。 Cloud Asset Inventory は、組織やプロジェクトのクラウドリソース（アセット）のメタデータを保存および閲覧するためのサービスです。 これにより把握できることは「Google AI Studio 経由の Gemini API が使用されている可能性が高いプロジェクト ID の一覧」です。把握できるスコープは「Google Cloud 組織」です。 この操作を行うには、該当の Google Cloud 組織の組織ルートレベルで、クラウド アセット閲覧者（ roles/cloudasset.viewer ）ロールおよび Service Usage ユーザー（ roles/serviceusage.serviceUsageConsumer ）ロールが必要です。権限が不足している場合、後述の手順で組織ルートノードを選択できません。 Google AI Studio の利用者が API キーを使って Gemini API を使用するには、キーの所属する Google Cloud プロジェクトで generativelanguage.googleapis.com API（以下、Gemini API）が有効になっている必要があります。こういったプロジェクトを Cloud Asset Inventory で一覧化できます。 Gemini API が有効になるタイミングは、以下が考えられます。 Google AI Studio の UI で新規プロジェクトを作成した時点で、そのプロジェクトでは Gemini API が有効化される Google AI Studio の UI でプロジェクトをインポートし、同プロジェクトを指定して API キーを作成した時点で、そのプロジェクトでは Gemini API が有効化される よって、同 API が有効になっているプロジェクトでは、Google AI Studio の API キーが発行されたことがある可能性が高いといえます。課金レポートを確認する方式と比べ、まだ課金が発生していなくても、疑わしいプロジェクトを特定できます。 これらのプロジェクト一覧を表示する手順は、以下のとおりです。 Google Cloud コンソール（ https://console.cloud.google.com/ ）にログイン Cloud Asset Inventory の「リソース」画面に遷移（ https://console.cloud.google.com/iam-admin/asset-inventory/resources ） コンソール画面左上部のプロジェクトセレクタで、組織ルートノードを選択 アセット一覧表の上部のフィルタに services/generativelanguage.googleapis.com と入力 Cloud Asset Inventory による API 有効化済みプロジェクトの一覧 なお、Google AI Studio の UI で新規プロジェクトを作成した場合、以下のようなプロジェクトが自動作成されます。このような特徴を持つプロジェクトでは、Gemini API が利用されている可能性が高いことがすぐにわかります。 プロジェクト ID が右のような形式になっている: gen-lang-client-0123456789 組織ルートノード直下に作成される（フォルダに格納されていない） 組織、フォルダ、プロジェクトの一覧は、Resource Manager の「リソースの管理」画面（ https://console.cloud.google.com/cloud-resource-manager ）で確認できます。 API キーの制限の徹底 概要 Google AI Studio で発行する API キーは、 Google Cloud プロジェクトの API キー です。Google Cloud プロジェクトでは、Google Maps API や Firebase API を実行するためだったり、Google Workspace の各種 API を実行するためなど、様々な理由で API キーが発行される可能性があります。Google AI Studio の UI で発行する API キーは、Google AI Studio 専用というわけではなく、これらと同じものです。 前述のとおり、以下の流れで、過去に発行した API キーが原因で Gemini API が大量にリクエストされてしまう可能性があります。 Google Maps や Firebase のために、公開が前提である API キーを発行した ソースコードへのハードコード等により API キーが他人に知られる API キーが所属するプロジェクトで後から Gemini API が有効化される 上記の場合にも、Gemini API 等が不正利用されることを防ぐため、API キーには制限を設定する必要があります。 API キーの所在の把握 Google Cloud 組織配下で発行されている API キーの一覧を確認するには、 Cloud Asset Inventory が使用できます。 これにより把握できることは「過去に発行された API キーの一覧」「その API キーを格納している Google Cloud プロジェクトの一覧」です。把握できるスコープは「Google Cloud 組織」です。 この操作を行うには、該当の Google Cloud 組織の組織ルートレベルで、クラウド アセット閲覧者（ roles/cloudasset.viewer ）ロールおよび Service Usage ユーザー（ roles/serviceusage.serviceUsageConsumer ）ロールが必要です。権限が不足している場合、後述の手順で、プロジェクトセレクタにおいて組織ルートノードを選択できません。 以下の手順により、発行済みの API キーの一覧と、その所属プロジェクト等を確認できます。 Google Cloud コンソール（ https://console.cloud.google.com/ ）にログイン Cloud Asset Inventory の「リソース」画面に遷移（ https://console.cloud.google.com/iam-admin/asset-inventory/resources ） コンソール画面左上部のプロジェクトセレクタで、組織ルートノードを選択 アセット一覧表の上部のフィルタに apikeys.googleapis.com と入力 Cloud Asset Inventory による発行済み API キーの一覧 API キーの制限 API キーの所在を把握したら、プロジェクトの担当者に連絡し、API キーに 制限 （restrictions）が設定されていることを確認してください。API キーの制限とは、アクセス可能な API を限定する設定のことです。 参考 : API キーに制限を追加する | API Keys API Documentation 前述のとおり、Google Maps や Firebase など、他の目的で発行された API キーが他人に不正利用された場合、制限がかけられていないキーについては、そのキーを使って Gemini API などへのリクエストが可能です。 後述のプロジェクト分離などは別途検討する前提のうえで、API キーには制限を設定することが望ましいです。 以下の手順で、API キーの制限の状態を確認したり、制限を追加できます。 Google Cloud コンソール（ https://console.cloud.google.com/ ）にログイン 「API とサービス」画面の「認証情報」タブに遷移（ https://console.cloud.google.com/apis/credentials ） コンソール画面左上部のプロジェクトセレクタで、対象のプロジェクトを選択 表「API キー」を確認。制限が設定されていればキーの名前の左部に緑色のチェックマークが表示される。名前をクリックすることで制限の詳細を確認したり、制限を追加できる Google Cloud における API キーの一覧 なお、Google AI Studio から発行したキーにはデフォルトで制限が設定されており、Gemini API のみにしか使用できません。その場合でも、キーが他人に知られれば不正利用をすることが可能であるため、十分な注意が必要です。 API キーの制限に関する仕様変更 2026年5月7日、Gemini API を利用したことがあるユーザー、ないし関連する Google Cloud プロジェクトのオーナー等に「 2026年6月19日以降、制限なしの API キーは Gemini API で使用できなくなる 」という旨のメールが Google から通知されました。 これにより、過去に Google Maps や Firebase などのために発行された、公開することが前提の API キーが他人に知られ、課金を伴う Gemini API が勝手に使用されてしまうという事象は発生しなくなります。 前述のとおり、Google AI Studio から発行したキーにはデフォルトで制限が設定されていますので、Google AI Studio から発行したキーを使っている場合には、サービスへの影響はありません。 しかし、もし過去に Google Maps や Firebase などの背景で公開することが前提の API キーを発行し、それを Gemini API にも流用しているといった場合には、2026年6月19日以降に Gemini API が使用できなくなります。キーに適切な制限をかけるか、新しく Gemini API キー専用の制限付きキーを発行してそちらを使うように変更する必要があります。 ベストプラクティスへの準拠 使用していない API キーを削除する、アプリケーションごと（用途ごと）にキーを分離する、定期的なローテーションなど、以下のドキュメントに記載のベストプラクティスに準拠してください。 参考 : API キーの管理に関するベスト プラクティス | Authentication | Google Cloud Documentation また、以下のような基本的な事項に注意を払ってください。Google Maps や Firebase 利用用途で API キーを発行した場合、「API キーはシークレット（機密情報）ではない」とされていますが、少なくとも Gemini API では課金を伴う API リクエストの認証情報として使用されている以上、シークレットあるいはそれに準じるものとして扱うことが望ましいといえます。 原則としてソースコードに API キーをハードコーディングしない。する必要がある場合、API キーに制限をかける GitHub などの公開リポジトリに API キーをアップロードしない インターネット公開されているストレージに、API キーを配置しない 社内のチャットや、メール、ポータルサイト、その他多数の目に触れる場所に API キーを貼り付けない その他、公共のインターネットからアクセスできる場所に API キーを配置しない Google AI Studio から Agent Platform への移行 Agent Platform を第一選択肢に Gemini を API 経由で利用する場合は、Google AI Studio ではなく、代わりに Gemini Enterprise Agent Platform （旧称 Vertex AI、略称 Agent Platform）と サービスアカウント を用いた Gemini 利用を第一の選択肢として検討してください。 Google AI Studio は「個人開発者、研究者、学生」等を対象としたサービスとされており、企業で Gemini API を利用する場合は、Agent Platform API 経由で Gemini を呼び出すことが推奨されます。 参考 : Google AI Studio、Gemini Enterprise Agent Platform、Gemini Enterprise app の比較 | Google Cloud 参考 : Google AI Studio vs Agent Platform。違いや選び方を解説 - G-gen Tech Blog Agent Platform を使用することで、Google Cloud のサービスアカウントを使って認証できるようになります。サービスアカウントを使うと、Cloud Run や Compute Engine といった Google Cloud のコンピュートプラットフォーム上からは、テキスト形式の認証情報を 使うことなく 、Gemini を API 経由で呼び出すことができます。 この仕組みは Application Default Credentials（ADC）と呼ばれ、最も推奨される方法です。 参考 : アプリケーションのデフォルト認証情報を構成する 移行する場合 Google AI Studio から Agent Platform への移行については、以下の公式ガイドを参照してください。 参考 : Google AI Studio から Gemini Enterprise Agent Platform に移行する 追加のセキュリティ施策 Agent Platform を使用することで、Google Cloud に用意されている以下のような追加のセキュリティ施策を適用可能です。 Workload Identity を使うことで、Amazon Web Services（AWS）の IAM ユーザーなど、他のプラットフォームの認証情報に基づいて API を呼び出すことができます。 参考 : Workload Identity 連携 | Identity and Access Management (IAM) | Google Cloud Documentation VPC Service Controls という仕組みを使うと、呼び出し元の IP アドレスを制限したり、アイデンティティやそのコンテキスト情報などに基づいた、コンテキストアウェアなアクセス制限を適用できます。 参考 : VPC Service Controls の概要 | Google Cloud Documentation 参考 : VPC Service Controlsを分かりやすく解説 - G-gen Tech Blog Google AI Studio の使用禁止 管理者設定による使用禁止 Google Workspace または Cloud Identity を使っている場合、管理者設定により、組織で管理している Google アカウントに対して、Google AI Studio の使用を禁止できます。 これにより、開発者が無償版の API キーを発行して、組織の機密情報や顧客情報、個人情報等を Google に送信してしまうことを防ぐことができるほか、当記事の冒頭で紹介したような過剰請求を未然に防止できます。設定手順は以下の公式ドキュメントを参照してください。 参考 : その他の Google サービスを有効または無効にする | Advanced Google Workspace 管理画面における Google サービスのオン・オフ 短絡的に禁止しない Google AI Studio を禁止することはセキュリティと統制の観点で有用ですが、その代わり、組織における Google の生成 AI の検証やスピーディーな業務導入を阻害することにも繋がります。 短絡的に一律禁止とするのではなく、Google AI Studio をセキュアに使用するためのガイドラインや手順を整備するといった代替策や、禁止する場合でも社内で Agent Platform をスピーディーに使用開始するための手続きを整備するなど、 組織の AI 活用を阻害せずにセキュリティを確保する 方法の検討が望まれます。 目的別のプロジェクト分離 「事象の原因」の章で紹介したように、あとから Google Cloud プロジェクトで API が有効化されることによって、API キーを発行した当初には想定していなかった API が呼び出されることを防ぐには、 目的別にプロジェクトを分離 することが重要です。 Google Maps 用、Firebase 用、Gemini API 用など、用途・目的別に Google Cloud プロジェクトを分けて作成するほか、本番環境、ステージング環境、開発環境など、環境別にプロジェクトを分けるのも有効です。 プロジェクトを細かい粒度で分けることで、万が一 API キーやその他の認証情報が流出した際にも、 影響範囲を最小化 し、キーや認証情報の停止などの 対策 を適切な粒度で、かつスピード感を持って実行できるようになります。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では、ADK で開発した AI エージェントに BigQuery Agent Analytics のプラグインを組み込むことで、エージェントのリクエストやレスポンス、ツール呼び出しなどのイベントを BigQuery に記録し、SQL で分析できるようにしていきます。 構成 当記事で使用するもの Agent Development Kit（ADK） Agent Runtime BigQuery BigQuery Agent Analytics について 概要 BigQuery に記録されるイベントについて エージェントの開発 ディレクトリ構成 プロジェクトの準備 エージェントのソースコード（agent.py） Google Cloud 側の準備 BigQuery データセットの作成 Agent Runtime サービスアカウントへの IAM 付与 ローカル認証 .env ファイルの作成 ローカルでの動作確認（ADK Web） Agent Runtime へのデプロイ デプロイの実施 動作確認 構成 当記事では、 Agent Development Kit（ADK） で定義した AI エージェントを Agent Runtime （旧称 : Vertex AI Agent Engine）にデプロイし、エージェントの実行中に発生するイベント（LLM への入出力、ツール呼び出し、エージェントのライフサイクルなど）を BigQuery にストリーミング方式で記録できるようにします。 イベントの記録には、ADK が公式に提供する BigQuery Agent Analytics プラグイン （ BigQueryAgentAnalyticsPlugin ）を使用します。プラグインをエージェントに登録するだけで、BigQuery の Storage Write API を使用したイベントの記録と、イベント型ごとのビューの自動生成が行われます。 BigQuery に記録されたイベントにクエリを実行することで、トークン使用量の集計、ツール呼び出しの頻度分析、特定セッションのトレースなどを行うことができます。また、 Conversational Analytics 機能を使用した自然言語での分析や、BigQuery ML や Looker / Data Studio（データポータル）による高度な分析、可視化も可能です。 BigQuery Agent Analytics を使用してエージェントのイベントを BigQuery にストリーミングする 当記事で使用するもの Agent Development Kit（ADK） Agent Development Kit（ADK） は、Google Cloud が提供する AI エージェント構築のためのオープンソース フレームワークであり、単純なタスクをこなすエージェントから複数のエージェントが協働する複雑なワークフローまで容易に実装できます。 ADK には、当記事で使用する BigQueryAgentAnalyticsPlugin のような、エージェントの振る舞いを拡張するためのプラグインが用意されており、エージェントのコードを大きく変更することなくロギング、トレーシングなどの機能を追加できます。 参考 : Agent Development Kit の概要 参考 : Plugins Agent Runtime Agent Runtime は AI エージェントの実行基盤を提供するフルマネージドサービスです。 Agent Runtime では、エージェントとのマルチターン会話を実現するための組み込みの セッション機能 を利用することができるほか、エージェントの機能拡張に必要な様々な機能が提供されています。また、Agent Runtime のコンソールからチャット UI（Playground）で直接エージェントの動作確認を行うことができます。 Agent Runtime の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp BigQuery BigQuery は Google Cloud が提供するフルマネージドなサーバーレス データウェアハウスです。大量のデータを高速に分析できる SQL エンジンを備えており、 Storage Write API を用いたストリーミング インサートによってリアルタイムにデータを書き込むこともできます。 当記事では、エージェントのイベントを格納する先として BigQuery を使用します。BigQuery Agent Analytics プラグインが内部で Storage Write API を利用してイベントを非同期にストリーミングするため、エージェントのパフォーマンスへの影響を抑えつつログを蓄積できます。 BigQuery の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp 参考 : BigQuery の概要 参考 : BigQuery Storage Write API の概要 BigQuery Agent Analytics について 概要 BigQuery Agent Analytics は、AI エージェントのインタラクション データをキャプチャ・分析・可視化するためのオープンソース ソリューションです。エージェントのリクエスト、レスポンス、ツール呼び出し、エラーなどのイベントを BigQuery テーブルに直接ストリーミングすることで、SQL や BigQuery ML での分析や、ダッシュボードでの可視化を可能にします。 当記事を執筆している2026年4月現在では、以下の2つのフレームワークに対応しています。 Agent Development Kit（ADK） LangGraph（2026年4月現在ではプレビュー） ADK では BigQueryAgentAnalyticsPlugin という プラグイン が提供されており、これをエージェントに登録するだけで BigQuery に対するイベントのログストリーミングを有効化できます。プラグインには以下のような特徴があります。 Storage Write API による高スループット・低遅延の非同期書き込み マルチモーダルのコンテンツ（テキスト / 画像 / 音声 / 動画）を記録可能（コンテンツの種類によっては Cloud Storage にオフロード） OpenTelemetry と統合された分散トレーシングにより trace_id 、 span_id による実行フローの可視化が可能 ツールの呼び出し元（ LOCAL / MCP / SUB_AGENT / A2A / TRANSFER_AGENT ）を記録 新しいイベント型が追加された際に、既存テーブルに対して自動で列を追加 その他、詳細な仕様については、以下の公式ドキュメントを参照してください。 参考 : BigQuery Agent Analytics plugin for ADK 参考 : BigQuery エージェント分析を使用する BigQuery に記録されるイベントについて BigQuery に記録されるイベントは、大きく以下の5つのカテゴリに分類されます。 カテゴリ イベント型 内容 LLM interactions LLM_REQUEST / LLM_RESPONSE / LLM_ERROR LLM へのプロンプト、モデル出力、エラーに関するイベント トークン使用量、生成にかかった時間なども記録される Tool usage TOOL_STARTING / TOOL_COMPLETED / TOOL_ERROR ツール呼び出しの開始、完了、エラーに関するイベント ツールの呼び出し元（ tool_origin ）も記録される State Management STATE_DELTA エージェントの内部状態の変更に関するイベント Agent lifecycle & Generic Events INVOCATION_STARTING / INVOCATION_COMPLETED / AGENT_STARTING / AGENT_COMPLETED / USER_MESSAGE_RECEIVED エージェントの起動、実行完了、ユーザー入力の受信などのイベント Human-in-the-Loop (HITL) Events HITL_CREDENTIAL_REQUEST / HITL_CONFIRMATION_REQUEST / HITL_INPUT_REQUEST / 各イベントの _COMPLETED ユーザー認証情報の要求、ユーザーへの確認要求、ユーザーからの入力要求などの割り込みイベント これらのイベントはすべて agent_events という1つのテーブルにまとめて格納されますが、プラグインによって自動で生成されるビュー（ v_llm_request 、 v_llm_response 、 v_tool_completed など）を使用することで、イベント型ごとに分析が可能です。 イベントのスキーマや詳細な内容については、以下の公式ドキュメントを参照してください。 参考 : BigQuery Agent Analytics plugin for ADK - Event types and payloads エージェントの開発 ディレクトリ構成 当記事では、コーヒーに関する質問に回答する「コーヒーエージェント」を ADK で構築し、 BigQueryAgentAnalyticsPlugin を組み込みます。ユーザーからの質問は、Google 検索を行うサブエージェントをツールとして持つエージェントが処理します。 最終的なディレクトリ構成は以下の通りになります。 coffee_agent ディレクトリで AI エージェントを実装していきます。 . ├── coffee_agent │ ├── agent.py │ ├── .env │ └── __init__.py ├── pyproject.toml # 自動で作成 └── uv.lock # 自動で作成 プロジェクトの準備 エージェント開発用のディレクトリでプロジェクトを初期化します。 BigQueryAgentAnalyticsPlugin は google-adk をインストールするだけで併せて利用できます。 # uv プロジェクト初期化 $ uv init --no-readme # パッケージの追加 $ uv add " google-adk>=1.29.0 " エージェント用のパッケージディレクトリ（ coffee_agent ）を作成し、ADK がエージェントのパッケージとして認識できるように __init__.py を配置します。 # エージェントのパッケージディレクトリを作成 $ mkdir coffee_agent # __init__.py を作成 $ cat <<EOF > coffee_agent/__init__.py from . import agent EOF エージェントのソースコード（agent.py） エージェントのソースコードでは、以下のように BigQueryAgentAnalyticsPlugin を組み込んだエージェントを実装します。 BigQueryAgentAnalyticsPlugin のインスタンスを作成し、ログの記録先となる BigQuery プロジェクト・データセット・ロケーションを指定 root_agent をラップする App オブジェクトを作成し、 plugins 引数にプラグインを登録 ポイントとして、このエージェントを adk deploy コマンドで Agent Runtime にデプロイする際に、 root_agent ではなく App オブジェクト（ app ）をデプロイ対象として指定する必要があります（後述）。この App オブジェクトに plugins を登録しておくことで、デプロイ後のエージェントでプラグインが有効化されます。 import os from google.adk.agents import Agent from google.adk.apps import App from google.adk.plugins.bigquery_agent_analytics_plugin import ( BigQueryAgentAnalyticsPlugin, BigQueryLoggerConfig, ) from google.adk.tools import google_search from google.adk.tools.agent_tool import AgentTool PROJECT_ID = os.environ[ "GOOGLE_CLOUD_PROJECT" ] DATASET_ID = os.environ.get( "BQ_DATASET" , "agent_analytics" ) BQ_LOCATION = os.environ.get( "BQ_LOCATION" , "asia-northeast1" ) # BigQuery Agent Analytics プラグイン bq_analytics_plugin = BigQueryAgentAnalyticsPlugin( project_id=PROJECT_ID, dataset_id=DATASET_ID, location=BQ_LOCATION, config=BigQueryLoggerConfig( batch_size= 1 , batch_flush_interval= 0.5 , log_session_metadata= True , ), ) # Web 検索用サブエージェント search_agent = Agent( name= "search_agent" , model= "gemini-2.5-flash" , description= "Google検索でコーヒーに関する情報を調べるエージェント" , instruction= "ユーザーの質問に対してGoogle検索を使って情報を収集し、日本語で回答してください。" , tools=[google_search], ) # ルートエージェント root_agent = Agent( name= "coffee_agent" , model= "gemini-2.5-flash" , description= "コーヒーに関する情報を収集するエージェント" , instruction= """あなたはコーヒーの専門家アシスタントです。 ユーザーからの質問に対して、search_agentを活用しながらコーヒーに関する正確で有益な情報を提供してください。 対応できるトピックの例: - コーヒー豆の産地・品種・特徴 - 抽出方法（ドリップ、エスプレッソ、フレンチプレスなど） - 焙煎度合いと味わいの違い - カフェやコーヒーショップの情報 - コーヒーの健康効果や歴史 - ラテアートやバリスタの技術 回答は日本語で、わかりやすく丁寧に行ってください。""" , tools=[AgentTool(agent=search_agent)], ) # Agent Runtime デプロイ用 App (プラグインを登録) app = App( name= "coffee_agent" , root_agent=root_agent, plugins=[bq_analytics_plugin], ) また、 BigQueryLoggerConfig では動作確認をしやすくするために、 batch_size=1 / batch_flush_interval=0.5 を指定してイベントが即座に BigQuery へ書き込まれるようにしています。 BigQueryLoggerConfig では、このほかにもイベントの記録挙動を細かく制御できます。代表的なものを以下に挙げます。 パラメータ デフォルト 説明 table_id "agent_events" イベントを格納する BigQuery テーブル ID event_allowlist / event_denylist None 記録する / 除外するイベント型のリスト content_formatter None イベントの記録前にフォーマットを行うために使用する関数（ 参考 ） gcs_bucket_name None マルチモーダル コンテンツをオフロードする Cloud Storage バケット create_views True イベント型ごとのビューを作成するか view_prefix "v" 自動生成するビュー名のプレフィックス 参考 : BigQuery Agent Analytics plugin for ADK - Configuration options Google Cloud 側の準備 BigQuery データセットの作成 プラグインがイベント記録用のテーブル（ agent_events ）とビュー（ v_llm_request など）を自動で作成するため、あらかじめ格納先のデータセットのみ用意します。データセットのリージョンは、後述する Agent Runtime の稼働リージョンと一致させます。 # データセット ID とロケーションを環境変数にセット $ PROJECT_ID = < プロジェクトID > $ DATASET_ID =agent_analytics $ BQ_LOCATION =asia-northeast1 # データセットの作成 $ bq --location = $BQ_LOCATION mk \ --dataset \ --description =" BigQuery Agent Analytics for ADK " \ $PROJECT_ID : $DATASET_ID Agent Runtime サービスアカウントへの IAM 付与 Agent Runtime にデプロイしたエージェントから BigQuery に書き込みを行うために、Agent Runtime のサービスアカウント（ service-<プロジェクト番号>@gcp-sa-aiplatform-re.iam.gserviceaccount.com ）に対して以下のロールを付与します。 ロール スコープ 用途 BigQuery ジョブユーザー （ roles/bigquery.jobUser ） プロジェクト BigQuery ジョブ（クエリ・書き込み）の実行 BigQuery データ編集者 （ roles/bigquery.dataEditor ） データセット テーブル・ビューの作成、データの書き込み 最小権限の原則に従い、 roles/bigquery.dataEditor はエージェント分析用のデータセットに対してのみ付与します。データセット単位の IAM は SQL の GRANT 文を使って付与します。 # プロジェクト番号の取得 $ PROJECT_NUMBER = $( gcloud projects describe $PROJECT_ID --format =' value(projectNumber) ' ) # Agent Runtime 実行サービスアカウント $ RE_SA = " service- ${PROJECT_NUMBER} @gcp-sa-aiplatform-re.iam.gserviceaccount.com " # bigquery.jobUser はプロジェクトレベルで付与 $ gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${RE_SA} " \ --role =" roles/bigquery.jobUser " # bigquery.dataEditor はデータセットレベルで付与 $ bq query --use_legacy_sql =false \ " GRANT \` roles/bigquery.dataEditor \` ON SCHEMA \` ${PROJECT_ID} \` . ${DATASET_ID} TO 'serviceAccount: ${RE_SA} ' " 当記事では実施しませんが、マルチモーダル コンテンツを Cloud Storage にオフロードする場合は、対象バケットに対して Storage オブジェクト作成者 （ roles/storage.objectCreator ）および Storage オブジェクト閲覧者 （ roles/storage.objectViewer ）も付与します。 参考 : BigQuery Agent Analytics plugin for ADK - Prerequisites ローカル認証 ローカルから adk web や adk deploy を実行する際の Google Cloud CLI の認証を行っておきます。 # 認証 $ gcloud auth login $ gcloud auth application-default login # プロジェクトの設定 $ gcloud config set project $PROJECT_ID .env ファイルの作成 エージェントの実行時に Gemini Enterprise Agent Platform（旧称 : Vertex AI、以下 Agent Platform と記載）を利用するための環境変数を、 coffee_agent ディレクトリ配下の .env ファイルに設定します。ADK は adk web や adk deploy の実行時にこのファイルを自動で読み込みます。 # coffee_agent/.env を作成 $ cat <<EOF > coffee_agent/.env GOOGLE_GENAI_USE_VERTEXAI=1 GOOGLE_CLOUD_PROJECT= $PROJECT_ID GOOGLE_CLOUD_LOCATION=asia-northeast1 EOF GOOGLE_GENAI_USE_VERTEXAI : 1 を指定することで、Gemini API ではなく Agent Platform 経由で Gemini モデルを利用します GOOGLE_CLOUD_PROJECT : エージェントをデプロイする Google Cloud プロジェクト ID。 agent.py で BigQuery 出力先プロジェクトとしても参照されます GOOGLE_CLOUD_LOCATION : Agent Runtime およびモデルを利用するリージョン ローカルでの動作確認（ADK Web） Agent Runtime へのデプロイ前に、ローカルで ADK Web UI を起動してエージェントの動作と BigQuery へのログ記録を確認します。 agent.py に app = App(...) を定義しておくと、 root_agent ではなく app が自動検出され、 plugins で指定されているプラグインを有効化した状態でエージェントが起動します。 # ADK Web UI の起動 $ uv run adk web ブラウザで http://localhost:8000 を開き、チャット UI からエージェントに質問を送ってみます。 ADK Web UI からエージェントにメッセージを送信する BigQuery コンソールで、 agent_events テーブルが自動作成され、イベントが記録されていることを確認します。 SELECT timestamp , event_type, agent, content FROM `<プロジェクトID>.agent_analytics.agent_events` ORDER BY timestamp DESC LIMIT 20 ; エージェントの各種イベントが BigQuery テーブルに記録されている USER_MESSAGE_RECEIVED 、 LLM_REQUEST 、 LLM_RESPONSE 、 AGENT_COMPLETED といったイベントが時系列で記録されていれば、プラグインが正しく動作しています。 また、 agent_events テーブルとあわせて、イベント型ごとのビュー（ v_llm_request 、 v_llm_response 、 v_tool_completed など）も自動で作成されており、こちらもデータセット内で確認できます。 イベント型ごとのビューが自動作成されている 参考 : ADK CLI documentation - web Agent Runtime へのデプロイ デプロイの実施 Agent Runtime にエージェントをデプロイします。プラグインを含めてデプロイするには、 --adk_app_object オプションで App オブジェクトの変数名（ここでは app ）を指定する必要があります。このオプションを指定しない場合、デフォルトでは root_agent がデプロイ対象となり、プラグインが適用されません。 # Agent Runtime にエージェントをデプロイ $ uv run adk deploy agent_engine \ --project = $PROJECT_ID \ --region = asia-northeast1 \ --display_name =" Coffee Agent with BQ Analytics " \ --adk_app_object = app \ coffee_agent 参考 : ADK CLI documentation - deploy 動作確認 デプロイが完了したら、Agent Runtime のコンソール画面（ https://console.cloud.google.com/vertex-ai/agents/agent-engines ）でデプロイしたエージェントを選択し、チャット UI（Playground）で動作確認を行います。 コンソールのチャット UI で、コーヒーに関する質問を送信してみます。 Agent Runtime のコンソールからエージェントにメッセージを送信する ローカル実行時と同様に、BigQuery の agent_events テーブルにイベントが記録されていることを確認します。 Agent Runtime にデプロイしたエージェントのイベントが記録されている 自動作成された v_llm_response ビューを使用して、LLM のトークン使用量を集計してみます。以下は全体の平均トークン数を確認するクエリです。 SELECT AVG (usage_total_tokens) AS avg_tokens, AVG (usage_prompt_tokens) AS avg_prompt, AVG (usage_completion_tokens) AS avg_completion FROM `<プロジェクトID>.agent_analytics.v_llm_response`; v_llm_response ビューから平均トークン数を集計する 公式ドキュメントにいくつかのクエリサンプルが紹介されているので、こちらも参照してください。 参考 : BigQuery Agent Analytics plugin for ADK - Advanced analysis queries 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の min です。データポータル（英名 Data Studio、旧称 Looker Studio）の BigQuery データソース接続において、個人の Google アカウントではなくサービスアカウントの認証情報を使用する際、権限エラーや接続エラーが発生することがあります。当記事では、サービスアカウント接続がうまくいかない場合に確認すべきポイントをチェックリスト形式で解説します。 ※当記事に掲載しているエラーメッセージは、2026年3月時点の仕様に基づいています。 前提となる構成 サービスエージェントに権限があるか エラーメッセージ 対処法 設定ユーザーに「使用」権限があるか エラーメッセージ 対処法 VPC SC でアクセスがブロックされていないか エラーメッセージ 対処法 前提となる構成 以下のように、データポータルのレポートから BigQuery テーブルを参照する構成があります。 BigQuery テーブルは、 VPC Service Controls の境界で保護された Google Cloud プロジェクトに格納されています。また、データポータルのレポートから BigQuery への認証には、個人の Google アカウントではなく、サービスアカウントを使用しています。 データポータルから BigQuery を参照 このとき、いくつかのポイントでエラーが発生することがあります。以下に、3つのチェックリストとして紹介します。 サービスエージェントに権限があるか エラーメッセージ エラーメッセージ （日本語） Looker Studio サービス エージェントに、このサービスアカウントに対する「iam.service Account.getAccess Token」 権限がありません。 エラーメッセージ （英語） Looker Studio Service Agent is missing "iam.serviceAccount.getAccessToken" permission on this service account. サービスエージェントの権限不足を示すエラーメッセージ 接続設定時に上記のエラーが出る場合、サービスエージェントの権限不足です。 データポータルがユーザー指定のサービスアカウントになりすまして BigQuery にアクセスするためには、データポータル側の サービスエージェント （Google が管理する特殊なサービスアカウント）に対し、対象のサービスアカウントのアクセストークンを発行する権限が必要です。 単に対象のサービスアカウントに BigQuery データ閲覧者（ roles/bigquery.dataViewer ）等を付与するだけでは不十分であり、データポータルのサービスエージェント自体にも適切なロールを付与する必要があります。 このとき重要なのが、 どの組織のサービスエージェントか という点です。許可すべきサービスエージェントは、BigQuery やサービスアカウントが存在する Google Cloud 組織のものではなく、 データポータルのデータソースを作成・所有するアカウントの組織（Google Workspace または Cloud Identity のドメイン） に対応するサービスエージェントです。 サービスエージェントの仕様については、以下の記事も参照してください。 blog.g-gen.co.jp 対処法 データポータルのサービスエージェントに対し、対象のサービスアカウントに対する「 サービス アカウント トークン作成者 （ roles/iam.serviceAccountTokenCreator ）」ロールを付与します。 必ず「データポータルのデータソースを作成・所有するユーザー」の Google アカウントで 、以下の手順を実施してください。 データポータルサービスエージェントのヘルプページ にアクセス ページ内のフォームに「サービスエージェント」のアドレスが表示されるため、これをコピー Google Cloud コンソールで、データポータルが使用する（BigQuery にアクセスさせたい）サービスアカウントの設定画面を開く コンソールの [IAM と管理] > [サービス アカウント] に移動 対象のサービスアカウントをクリックし、詳細画面へ遷移 [アクセス権を持つプリンシパル] タブをクリックし、[アクセスを許可] をクリック 「新しいプリンシパル」に、手順2でコピーした データポータルサービスエージェントのメールアドレスを入力 「ロール」に「 サービス アカウント トークン作成者 （ roles/iam.serviceAccountTokenCreator ）」を選択し、保存 参考 : データポータル用に Google Cloud サービス アカウントを設定する - 設定の手順 設定ユーザーに「使用」権限があるか エラーメッセージ このサービス アカウントを使用する権限がありません。 サービスアカウントに対する権限不足を示すエラーメッセージ データポータルの画面上で「このサービスアカウントを使用する」という設定を行うためには、 設定操作を行っているユーザー自身 が、そのサービスアカウントを「使用する」権限を持っている必要があります。 この権限は「 サービス アカウント ユーザー （ roles/iam.serviceAccountUser ）」ロールに含まれています。 よくある落とし穴として、「サービス アカウント管理者（ roles/iam.serviceAccountAdmin ）が付与されているから問題ない（包含している）」と誤認してしまうケースがあります。サービス アカウント管理者ロールにはサービスアカウント自体を管理する権限はありますが、サービスアカウントとして振る舞うための権限（ iam.serviceAccounts.actAs ）は含まれていません。 参考 : データポータル用に Google Cloud サービス アカウントを設定する - ユーザーロールを付与する 参考 : Identity and Access Management roles and permissions - Service Account Admin 参考 : Identity and Access Management roles and permissions - Service Account User 参考 : Identity and Access Management roles and permissions - iam.serviceAccounts.actAs 対処法 データポータルのデータソース設定を行う ユーザーの Google アカウント に対し、対象サービスアカウントの「 サービス アカウント ユーザー （ roles/iam.serviceAccountUser ）」ロールを付与します。 コンソールの [IAM と管理] > [サービス アカウント] に移動 対象のサービスアカウントをクリックし、詳細画面へ遷移 [アクセス権を持つプリンシパル] タブをクリックし、[アクセスを許可] をクリック 「新しいプリンシパル」に、データポータルで設定操作を行うユーザーのメールアドレスを入力 「ロール」に「 サービス アカウント ユーザー （ roles/iam.serviceAccountUser ）」を選択し、保存 VPC SC でアクセスがブロックされていないか エラーメッセージ このサービス アカウントを使用する権限がありません。 サービスアカウントに対する権限不足を示すエラーメッセージ 接続先の Google Cloud プロジェクトが VPC Service Controls の境界で保護されている場合、外部からの API リクエストは原則として遮断されます。 データポータルは Google Cloud の VPC 内部ではなく、インターネット（Google のパブリック IP アドレス帯域）からアクセスを行います。そのため、VPC Service Controls の境界でアクセスがブロックされてしまいます。 Google Cloud 側のログを確認すると、VPC SC ( VPC_SERVICE_CONTROLS ) によるエラーログが記録されています。 対処法 VPC Service Controls を導入している環境では、データポータルからのアクセスを許可するために 上り（内向き）ルール （Ingress Rule）の設定が必要です。 Google Cloud コンソールの [セキュリティ] > [VPC Service Controls] に移動 対象の境界に適用されている境界を編集、または新規作成 上り（内向き）ルールの設定において、データポータルで使用している サービスアカウントのメールアドレス を追加 設定を保存 設定の詳細は、以下の記事の「VPC Service Controls の設定」でも解説しています。 blog.g-gen.co.jp 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の min です。BigQuery でデータ分析情報を生成する機能 データ分析情報 （Data insights）について解説します。 データ分析情報とは 概要 2つの分析レベル 分析情報を生成するモード 事前準備 必要な API の有効化 必要な IAM ロール テーブル分析情報 提供される機能 クエリの生成 説明の生成 生成言語の制御 生成手順 生成した分析情報の保存 データセット分析情報 提供される機能 データセットの説明 リレーションシップグラフ リレーションシップテーブル クエリの推奨 生成手順 制限事項 料金 データ分析情報とは 概要 データ分析情報 （ Data insights ）とは、BigQuery に統合された AI アシスタントである Gemini in BigQuery の機能の一つです。 BigQuery に蓄積されたデータを使用して分析を始める際、初めて見るテーブルにどのようなデータが入っているのか、他のテーブルとどのような関係があるのかを理解するには、通常、試しに SQL を書いてデータを抽出したり、設計書を読み解くなどの手間がかかります。 データ分析情報を使用すると、AI がテーブルやカラムの名前などの付帯情報（メタデータ）を読み取り、テーブルの概要を説明するテキストや、データ分析に役立つ SQL クエリを自動生成します。これにより、SQL に不慣れな非エンジニアの方や、初めてそのデータに触れるアナリストであっても、スムーズにデータ探索を開始できます。 参考 : BigQuery でデータ分析情報を生成する 2つの分析レベル データ分析情報には、分析の範囲に応じて以下の2つの機能が提供されています。それぞれの詳細については後述します。 機能名 分析対象 主な提供内容 テーブル分析情報 （table insights） 単一のテーブル データ内容や品質の分析、要約文の生成、データ抽出用 SQL クエリの提案 データセット分析情報 （datasets insights） 単一のデータセット 複数テーブル間の関係性の推論、テーブル結合を伴う SQL クエリの提案 後者のデータセット分析情報については、2026年4月現在、Preview 段階です。 分析情報を生成するモード BigQuery では、分析情報を生成する際に以下の2つのモードが用意されています。 モード 説明 用途 生成して公開 （Generate and publish） AI が生成したデータの説明や SQL クエリの提案を、Google Cloud のデータ辞書サービスである Dataplex Universal Catalog に保存します。権限を持つ他のメンバーと知識を共有できるほか、保存された説明を後から手動で編集することも可能です。 会社全体でデータの説明などのドキュメントを共有し、継続的に知識を蓄積・再利用したい場合。 公開せずに生成 （Generate without publish） その場限りの分析情報をすぐに作成します。生成された情報は、共有のデータ辞書には保存（公開）されません。 共有のデータ辞書に不要な情報を増やさず、一時的なデータ確認やお試しでの分析を素早く行いたい場合。 前者の生成して公開（Generate and publish）については、2026年4月現在、Preview 段階です。 Dataplex Universal Catalog については、以下の記事を参照してください。 blog.g-gen.co.jp 事前準備 必要な API の有効化 データ分析情報を使用するプロジェクトでは、事前に以下の API を有効化しておく必要があります。 BigQuery API Dataplex API Gemini for Google Cloud API 必要な IAM ロール コンソール画面からデータ分析情報を生成し、その結果を閲覧するためには、作業するユーザーの Google アカウントに対して以下の IAM ロールが付与されている必要があります。 データ分析情報の機能は内部的に Dataplex というデータ管理サービスの機能を使用しているため、BigQuery だけでなく Dataplex の権限も必要となる点に注意してください。 「BigQuery データ閲覧者（ roles/bigquery.dataViewer ）」または「BigQuery データ編集者（ roles/bigquery.dataEditor ）」 「Dataplex DataScan 編集者（ roles/dataplex.dataScanEditor ）」または「Dataplex DataScan 管理者（ roles/dataplex.dataScanAdmin ）」 参考 : BigQuery でデータ分析情報を生成する - 必要なロール テーブル分析情報 提供される機能 テーブル分析情報は、単一の BigQuery テーブルに含まれるデータの内容や品質、傾向を理解するための機能です。対象のテーブルに対して分析情報を生成すると、AI が以下のような情報を提供します。 クエリの生成 データ内のパターン、異常値、外れ値などを検出するための自然言語の質問と、それに対応する SQL クエリを提案します。 説明の生成 テーブル全体および各カラムに対する説明文を自動生成します。対象のテーブルに対して データ プロファイル スキャン （データの傾向や統計情報を抽出する機能）が実行されている場合、その結果も加味してより正確な説明が生成されます。 データ プロファイル スキャンについては、以下の公式ドキュメントを参照してください。 参考 : データをプロファイリングする 生成言語の制御 テーブルとカラムの説明を特定の言語で生成するように、Gemini に指示できます。 言語を指定するには、分析情報を生成する前に、テーブルの既存の説明文に「日本語で説明をして」といった短い指示を追記します。対象テーブルの「詳細」タブを開き、「詳細を編集」をクリックして指示文を追記および保存します。 詳細タブの画面 説明編集の画面 サポートされている言語の一覧については、以下を参照してください。 参考 : 言語サポート - Gemini 生成手順 Google Cloud コンソール画面から、テーブル分析情報を公開せずに生成する手順は以下のとおりです。 Google Cloud コンソールを開き、BigQuery Studio の画面に移動します。 画面左側の「エクスプローラ」ペインで、対象のプロジェクト名、データセット名の順に選択し、分析したいテーブルをクリックします。 画面右側にテーブルの詳細情報が表示されるため、上部のタブメニューから「分析情報」タブを選択します。 分析情報タブの画面 画面内の「公開せずに生成」ボタンをクリックします。 分析情報の生成には数分程度かかる場合があります。生成が完了すると、AI によって提案されたテーブルの概要や、データを分析するためのサンプル SQL クエリなどが同じ画面に表示されます。表示された SQL はそのまま実行したり、要件にあわせて書き換えて保存できます。 生成した分析情報の保存 Gemini in BigQuery は、データ分析情報を生成するときに、テーブルとカラムの説明を自動的に生成します。必要に応じてこれらの説明を編集し、BigQuery のスキーマや詳細情報として手動で保存できます。 テーブルで分析する内容を記述した詳細なテーブルの説明は、Gemini in BigQuery でより関連性の高い分析情報を生成するのに役立ちます。保存された説明は、自分や他のメンバーが参照できるだけでなく、今後の分析情報を生成するためにも使用されます。 説明文を保存する手順は以下のとおりです。 対象テーブルの画面で「分析情報」タブを開きます。 分析情報を生成後の分析情報タブの画面 画面内の「テーブルの説明」セクションにある「列の説明を表示」をクリックします。説明のプレビュー画面が表示されます。 説明のプレビュー画面 テーブル自体の説明を保存したい場合は、「詳細に保存」をクリックします。「提案された説明をコピー」をクリックして入力欄に内容を反映させたのち、「Save to details」をクリックします。 詳細に保存の画面 カラムの説明を追加・保存したい場合は、2. のプレビュー画面にて「列の説明」セクションにある「スキーマに保存」をクリックします。現在のスキーマとの変更内容の差分を確認し、問題がなければ「保存」をクリックします。 現在のスキーマの確認画面 データセット分析情報 提供される機能 データセット分析情報は、単一のデータセット内に存在する複数のテーブル間の関係性を把握するための機能です。当機能は 2026年4月現在、Preview 公開されています。 テーブル同士をどのように結合すれば意味のあるデータが抽出できるかを AI が推論し、以下の情報を提供します。 データセットの説明 データセット全体の概要を AI が要約して提供します。 リレーションシップグラフ データセット内のテーブル間の関係性を示す図を表示します。線にカーソルを合わせると、どのカラムをキーにして結合できるかといった詳細を確認できます。 リレーションシップテーブル テーブル間の関係性を表形式で一覧表示します。関係性の根拠として、明示的なシステム上の制約（外部キーなど）、過去のクエリの実行履歴に基づく使用状況、またはテーブル名やカラム名からの AI による推論が含まれます。 クエリの推奨 複数のテーブルを結合してデータを抽出するための、実践的な SQL クエリのサンプルを提供します。 生成手順 Google Cloud コンソール画面から、データセット分析情報を公開せずに生成する手順は以下のとおりです。 Google Cloud コンソールを開き、BigQuery Studio の画面に移動します。 画面左側の「エクスプローラ」ペインで、対象のプロジェクト名のツリーを選択し、分析したいデータセットをクリックします。 画面右側にデータセットの詳細情報が表示されるため、上部のタブメニューから「分析情報」タブを選択します。 分析情報タブの画面 画面内の「公開せずに生成」ボタンをクリックします。 分析情報の生成には数分程度かかる場合があります。生成が完了すると、AI によって提案されたデータセットの概要やリレーションシップグラフなどが同じ画面に表示されます。 例：Relationships の図 例：リレーションテーブル 制限事項 データ分析情報を使用する際の主な制限事項は以下のとおりです。 サポートされるテーブルは、BigQuery ネイティブのテーブル、BigLake テーブル、外部テーブル、ビュー カラムレベルのアクセス制御が設定されているテーブルに対して分析情報を生成するには、実行ユーザーが対象テーブルのすべてのカラムに対する読み取り権限を持っている必要がある テーブル分析情報において、AI が説明文を自動生成できるのは 1 テーブルあたり最大 350 カラムまで 新たにデータセット分析情報を生成すると、対象データセットに対する以前の分析情報は上書きされる マルチクラウド環境に保存されている、他クラウドのデータは対象外 参考 : BigQuery でデータ分析情報を生成する - 制限事項 料金 データ分析情報の機能自体に対する追加料金は発生しません。 データ分析情報は、Google Cloud プロジェクトにおいて、以下のいずれかの BigQuery 料金体系を適用している場合に使用できます。 オンデマンド Enterprise エディション Enterprise Plus エディション プロジェクトに BigQuery Editions の Standard エディションが適用されている場合は、データ分析情報を使用できないので注意してください。 また、生成された SQL クエリを BigQuery で実行した際には、通常の BigQuery のコンピューティング料金（データスキャンに対する課金など）が発生します。 参考 : Gemini for Google Cloud の料金 - Gemini in BigQuery の料金の概要 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の奥田です。当記事は、2026年3月19日に開催された Agentic AI Summit 2026 Spring で筆者と弊社の今野が登壇したセッション「Gemini Enterprise と ADK で実現する業務特化型エージェント開発の最前線 — ユーザー認証連携における Google Workspace 操作の実装方法と事例を公開」のレポートです。 セッションの概要 なぜ AI エージェントにユーザー認証が必要なのか サービスアカウントのリスク OAuth 2.0 によるユーザー認証連携 デモ : 議事録カレンダー登録エージェント デモの概要 Google Workspace への応用 なぜ ADK を選んだのか コードの実装 構成図とソースコードのディレクトリ構成 エージェントの定義 認証トークンの取得とカレンダー API の呼び出し 開発中に遭遇した落とし穴 ADK の State オブジェクト LiteLLM のセキュリティに関する注意 Gemini Enterprise へのデプロイ 参考リンク セッションの概要 当セッションでは、AI エージェントが Google Workspace のサービスを操作する際に不可欠な ユーザー認証連携 をテーマに、実装方法と事例を紹介しました。 セッション前半では、AI エージェントにおける認証の重要性を具体的なシナリオで解説し、議事録から Google Calendar にイベントを自動登録するエージェントのライブデモを行いました。後半では、 Gemini Enterprise 、 Agent Development Kit （以下、 ADK ）、 Agent Engine を組み合わせたアーキテクチャと、 OAuth 2.0 連携の実装ステップを紹介しました。 参考 : Gemini Enterprise 参考 : Agent Development Kit（ADK） 参考 : Agent Engine 参考 : OAuth 2.0 Agentic AI Summit 2026 Spring での実績は以下のとおりです。 合計 オンライン オフライン CSAT G-gen セッション 741 名 556 名 185 名 3.9 なぜ AI エージェントにユーザー認証が必要なのか サービスアカウントのリスク AI エージェントを業務で利用する場合、「エージェントが誰として外部サービスにアクセスするのか」が重要な設計課題です。 たとえば、社員 A さんが AI エージェントに「来週の火曜日に会議を入れて」と依頼したとします。エージェントは A さんの代わりに Google Calendar を操作する必要があります。このとき、システム共通のサービスアカウントに権限を一括付与して動かすと、エージェントは A さんだけでなく B さんや他の組織の C さんのカレンダーにもアクセスできてしまいます。 技術的には動作しますが、業務での利用には適しません。AI エージェントは人間と違い、バックグラウンドで大量のデータに触れることができます。だからこそ「誰として動いているのか」を明確に設計することが不可欠です。 OAuth 2.0 によるユーザー認証連携 この課題の解決策が OAuth 2.0 を使ったユーザー認証連携です。 仕組みはシンプルです。ユーザーが一度ログインして権限を許可すると、エージェントはそのユーザーのアクセストークンを使って API を呼び出します。エージェントはそのユーザーの権限の範囲内でしか動作しません。 A さんの AI エージェントが行った操作は「A さんが自分の権限で実行した」という記録です。コンプライアンスの観点でも重要なポイントです。 デモ : 議事録カレンダー登録エージェント デモの概要 セッションでは、議事録や ToDo メモからタスクを抽出し、Google Calendar にイベントを自動登録するエージェントのライブデモを行いました。 デモの流れは以下のとおりです。 Gemini Enterprise 上でエージェントを起動し、OAuth 認証を完了する 直近のカレンダー予定を確認する 日時とタイトルを入力してイベントを追加する 約 6,300 文字の架空の議事録（ポータルサイトプロジェクト）をエージェントに渡す エージェントが議事録から 9 個の ToDo を抽出し、カレンダーに一括登録する 不要なプライベートの予定を削除する デモで約 6,300 文字の議事録を使用したのは、 Gemini の従来の強みである大規模コンテキストウィンドウを利用するため です。長文の議事録であっても分割せずに一度で処理できることを示す狙いがありました。 エージェントは 9 個のタスクを抽出しましたが、そのうち 2 つは会議のアイスブレイク時に話題に上がったプライベートな内容（入学式の話）でした。エージェントがこれらを業務タスクと同列に扱ってカレンダーに登録しました。 デモ後半では「プライベートの予定を削除」と入力するだけで、エージェントが自律的に予定の性質を判断し、該当するイベントのみを削除しました。これは、エージェントが文脈を理解し、カレンダーの内容を自律的に評価した実践的な事例です。 このエージェントの導入効果として、 議事録 1 件あたりのカレンダー登録作業を手動10分から自動で1分程度に短縮 できます。タスクの抜け漏れを防ぐ実用的なエージェントです。 Google Workspace への応用 今回のデモでは Google Calendar を題材にしましたが、同じ OAuth 2.0 連携の仕組みを使うことで、Google Workspace の各サービスにも応用できます。 Gmail では、エージェントがユーザー本人としてメールボックスに下書きを作成したり、宛先・件名・本文を含むメールを送信できます。たとえばミーティングの議事録をまとめて関係者にフォローアップメールを自動送信するといった使い方が可能です。 Google ドキュメント や Google スライド では、箇条書きや構成案を渡すだけでドキュメントやスライドの雛型を作成できます。ユーザーはブラッシュアップやクリエイティブな作業に集中できます。 Google ドライブ では、ユーザー自身がアクセス権を持つファイルだけを検索できるため、他者のファイルに触れるリスクがありません。社内ドキュメントをナレッジベースとして RAG 構成と組み合わせる使い方が効果的です。 共通するポイントは、すべての操作がユーザー本人の権限の範囲内で動作することです。 なぜ ADK を選んだのか エージェント開発のフレームワークには LangChain や CrewAI など複数の選択肢があります。今回 ADK を採用した理由は大きく2つです。 1つ目は、 Google Cloud のエコシステムで完結させたかった ことです。フロントエンドの Gemini Enterprise、実行基盤の Agent Engine、そして開発フレームワークの ADK をすべて Google Cloud のサービスで統一することで、認証トークンの受け渡しやデプロイがマネージドサービス間でシームレスに連携します。前述のとおり、 tool_context.state を通じた OAuth トークンの自動受け渡しは、この統一されたエコシステムがあってこそ実現できる仕組みです。 2つ目は、 ADK と OAuth 2.0 を組み合わせた実装事例がまだ少なかった ことです。ADK 自体の利用例は増えていますが、Gemini Enterprise の OAuth 連携と組み合わせて Google Workspace を操作するパターンは、2026年4月現在でも公開事例が限られています。今回のセッションとデモを通じて、この実装パターンを広く共有したいという意図がありました。 コードの実装 構成図とソースコードのディレクトリ構成 構成図は以下です。 ソースコードは GitHub で公開しています。 参考 : G-gen-Tech-Blog/agentic-ai-summit-2026-spring-session-report リポジトリのディレクトリ構成は以下です。 . ├── __init__.py ├── agent.py # エージェント定義 ├── tools.py # ツール関数（Calendar API 操作） ├── config.py # 設定値の管理 ├── requirements.txt # 依存パッケージ ├── .env_example # 環境変数のサンプル ├── .gitignore └── README.md エージェントの定義 以下は ADK でエージェントを定義する agent.py の全体です。49 行でエージェントの定義が完結しています。 # agent.py from google.adk.agents.llm_agent import Agent from . import tools from google.adk.models.lite_llm import LiteLlm root_agent = Agent( name= "calendar_agent" , model=LiteLlm( "vertex_ai/gemini-3-flash-preview" , vertex_location= "global" ), description= "議事録を解析して Google Calendar にイベントを登録するエージェント" , instruction= """あなたは議事録からTodoを抽出して Google Calendar に登録するアシスタントです。 以下の手順で作業してください。 1. ユーザーから議事録を受け取る。 - ファイルパスが渡された場合は read_todo_file ツールでファイルを読み込む。 2. テキスト内容を解析し、議事録からTodoとそれに関係する情報を抽出する: - 日付・時刻（今年は2026年。月/日 の形式なら 2026年として解釈する） - イベントタイトル - 説明（あれば） - 終日イベントかどうか 3. 抽出した各イベントについて create_calendar_event ツールを呼び出して登録する。 - 日時は ISO 8601 形式にする（例: 2026-02-20T14:00:00） - 終日イベントの場合は日付のみ（例: 2026-03-01）、end_datetime は翌日にする - 時間の指定がない場合は終日イベントとして扱う - 終了時刻の指定がない場合は開始から1時間後を終了時刻とする - タイムゾーンは Asia/Tokyo 4. Todo テキストに参加者（メールアドレス）の記載があれば attendees に指定する。 ユーザーが参加者を指定した場合は、そのメールアドレスを追加する。 5. 登録結果をユーザーに報告する。 注意事項: - すべての日時は日本時間 (JST, Asia/Tokyo) を基準とする。 時刻の指定がある場合は日本時間として解釈すること。 - テキストは自由形式。「2/20 14:00 美容院」のようなフォーマットもあれば、 文章形式の場合もある。柔軟に解析すること。 - 日付が曖昧な場合は確認を求める。 """ , tools=[ tools.read_todo_file, tools.create_calendar_event, tools.list_calendar_events, tools.update_calendar_event, tools.delete_calendar_event, ], ) Agent クラスの model に LiteLlm で gemini-3-flash-preview （2026年4月現在）を指定しています。 instruction にはシステムプロンプトとして議事録の解析手順を記述し、 tools に呼び出し可能なツール関数を登録しています。 ADK では LiteLlm を使うことで Gemini 以外のモデル（Claude、GPT など）にも切り替えられます。 参考 : ADK LiteLLm ドキュメント 認証トークンの取得とカレンダー API の呼び出し 今回の構成で最も注目すべきポイントは、Gemini Enterprise・ADK・Agent Engine の3つのサービスが連携してユーザーの認証トークンをシームレスに受け渡す仕組みです。 通常、OAuth 2.0 を使ったアプリケーション開発では、トークンの取得・保存・リフレッシュ・有効期限の管理といった複雑な認証フローを開発者自身が実装する必要があります。しかし、Google Cloud のエコシステムではこの課題が解消されています。ユーザーが Gemini Enterprise 上で OAuth 認証を完了すると、取得されたアクセストークンは Agent Engine のセッションに自動で保存されます。ADK のツール関数では、引数として渡される ToolContext の state からそのトークンをわずか1行で取得できます。 この「Gemini Enterprise（認証 UI）→ Agent Engine（トークン管理）→ ADK（トークン利用）」という一連の流れが、Google Cloud のマネージドサービス間で自動的に実現される点が、このエコシステムの大きなメリットです。 以下の get_calendar_service 関数がその実装の核心です。 from google.oauth2.credentials import Credentials from googleapiclient.discovery import build from google.adk.tools import ToolContext def get_calendar_service (tool_context: ToolContext): """ Agent Engine 環境で Google Calendar サービスを認証・生成します。 """ # 1. 環境変数から管理画面で設定した ID を取得 auth_id = os.getenv( "AUTH_ID" ) # 2. トークンの取得を試みる access_token = tool_context.state.get(auth_id) if not access_token: access_token = tool_context.state.get( "authentication" ) # 3. トークンが見つからない場合 if not access_token: raise ValueError ( "認証トークンが取得できませんでした。" "チャット画面で Google ログインを完了させているか確認してください。" ) # 4. 取得したトークンでカレンダーサービスを構築 creds = Credentials(token=access_token) return build( "calendar" , "v3" , credentials=creds) ポイントは tool_context.state.get(auth_id) のわずか1行です。この1行の背後では、以下の処理が Google Cloud のマネージドサービスによって自動的に行われています。 Gemini Enterprise がユーザーに OAuth 同意画面を表示し、認可コードを取得する Agent Engine が認可コードをアクセストークンに交換し、セッションの state に保存する ADK のツール関数が ToolContext 経由でそのトークンを取得する 開発者が実装するのは tool_context.state.get(auth_id) でトークンを取り出し、 Credentials に渡す部分だけです。トークンの取得フロー、リフレッシュ、有効期限の管理はすべてマネージドサービス側が担います。 認証フローの実装が、Google Cloud のマネージドサービス連携により数行のコードに集約されています。 以下は、メインのツール関数である create_calendar_event です。 def create_calendar_event ( summary: str , start_datetime: str , end_datetime: str , tool_context: ToolContext, description: str = "" , timezone: str = "Asia/Tokyo" , attendees: list [ str ] | None = None , ) -> dict : """Google Calendar にイベントを作成する。""" service = get_calendar_service(tool_context) s_dt = start_datetime.strip() e_dt = end_datetime.strip() # 終日イベントかどうかの判定 is_all_day = ( "T" not in s_dt) and ( ":" not in s_dt) if is_all_day: s_dt = s_dt.replace( "/" , "-" ) e_dt = e_dt.replace( "/" , "-" ) event_body = { "summary" : summary, "description" : description, "start" : { "date" : s_dt}, "end" : { "date" : e_dt}, } else : if " " in s_dt: s_dt = s_dt.replace( " " , "T" ) if " " in e_dt: e_dt = e_dt.replace( " " , "T" ) event_body = { "summary" : summary, "description" : description, "start" : { "dateTime" : s_dt, "timeZone" : timezone}, "end" : { "dateTime" : e_dt, "timeZone" : timezone}, } if attendees: event_body[ "attendees" ] = [{ "email" : email} for email in attendees] event = service.events().insert(calendarId= "primary" , body=event_body).execute() return { "status" : "success" , "event_id" : event[ "id" ], "summary" : event[ "summary" ], "html_link" : event[ "htmlLink" ], } get_calendar_service(tool_context) を呼び出すことで、ログイン中のユーザーの権限で Google Calendar API を操作しています。終日イベントと時間指定イベントを date と dateTime で区別し、 attendees パラメータで参加者の追加にも対応しています。 開発中に遭遇した落とし穴 ADK の State オブジェクト 開発中、認証トークンの中身を確認しようとした際に以下のエラーに遭遇しました。 # やりたかったこと：state の中身を一覧表示したい print (tool_context.state.keys()) 上記の様に入力すると、以下の結果になります。 AttributeError: 'State' object has no attribute 'keys' ADK の State オブジェクトは、標準の Python 辞書（ dict ）ではなく、Python の MutableMapping プロトコルにも準拠していません。辞書のように値の取得や代入はできますが、 .keys() や .items() といった標準的なメソッドは持っていません。これはバグではなく、会話状態の差分追跡を確実に行うための意図的な設計です。 注意すべき点として、ADK には以下2つの state が存在します。 session.state tool_context.state （ context.state ） session.state は標準の Python 辞書（ dict ）であるため .keys() や .items() が通常どおり使えます。 一方、ツール関数の引数として渡される tool_context.state は前述の State オブジェクトであり、これらのメソッドは使えません。 session.state.keys() は正常に動作するのに tool_context.state.keys() ではエラーになるため、両者を混同するとデバッグ時に混乱を招きます。 ツール関数内では tool_context.state を使うため、 .get() メソッドで安全に値を取り出す必要があります。 # 正しい方法：.get() で安全に取得 access_token = tool_context.state.get(auth_id) 操作は .get() や直接代入（ tool_context.state[key] = value ）に留めることが推奨されます。ADK を使ったエージェント開発を始める方は、この仕様を事前に把握しておくとデバッグ時間を節約できます。 参考 : Context - Agent Development Kit (ADK) LiteLLM のセキュリティに関する注意 LiteLLM v1.82.7 / v1.82.8 は、サプライチェーン攻撃（TeamPCP）により侵害されました（2026年3月24日）。本デモの GitHub リポジトリのサンプルコードでは v1.83.0（攻撃後の正規リリース、2026年3月31日公開）にピン留めしています。 詳細は以下を参照してください。 参考 : LiteLLM 公式セキュリティアップデート 参考 : GitHub Issue #24518（タイムライン） Gemini Enterprise へのデプロイ 作成したエージェントを Agent Engine にデプロイした後、Gemini Enterprise のコンソールからエージェントを追加できます。画面からの操作のみでデプロイが完了します。 ユーザーごと、またはグループごとにエージェントの利用権限を管理することも可能です。組織全体への安全な展開が実現できます。 参考リンク 参考 : Agentic AI Summit 2026 Spring 参考 : 登壇資料 参考 : G-gen-Tech-Blog/agentic-ai-summit-2026-spring-session-report（ソースコード） 以下の動画でセッションの実演をご覧いただけます。 奥田 梨紗 (記事一覧) クラウドソリューション部データインテリジェンス課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025&2026 Follow @risa_hochiminh

G-gen の佐々木です。当記事では、Pub/Sub から直接 Vertex AI 上の AI モデルによる推論を取得することができる AI 推論 SMT 機能について解説します。 前提知識 Pub/Sub とは Single Message Transforms（SMTs） AI 推論 SMT の機能 基本事項 AI 推論 SMT の利点 使用できるモデル Model Garden で提供されているモデル Vertex AI Endpoints にデプロイしたモデル モデルの入力・出力 入力するメッセージの形式 推論後のメッセージの形式 制限事項 設定手順 手順の概要 サービスアカウントの作成・権限付与 定義ファイルの作成 トピックの作成 AI 推論 SMT を使用するサブスクリプションの作成 動作確認 メッセージのパブリッシュ メッセージの受信 前提知識 Pub/Sub とは Pub/Sub は Google Cloud におけるフルマネージドなメッセージングサービスです。 メッセージングサービスは、システム間に配置することでメッセージを非同期に中継することができます。これにより、システムの拡張性や保守性を向上することができます。 Pub/Sub を始めとしたメッセージングサービスの詳細やユースケースについては、以下の記事をご一読ください。 blog.g-gen.co.jp Single Message Transforms（SMTs） Single Message Transforms （以下、 SMTs ）は Pub/Sub を使用したストリーミング処理のパイプラインにおいて単純なデータ変換を実現する機能です。 この機能では、Pub/Sub のトピックとサブスクリプションのそれぞれに対して単純なデータ変換処理を実装します。これにより、データの形式の変換やマスキング、フィルタリングなどの処理を、メッセージの配信前に行うことができます。 SMTs の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp AI 推論 SMT の機能 基本事項 当記事で紹介する AI 推論 SMT （AI Inference Single Method Transform）は、SMTs の機能の1つであり、Vertex AI にある AI モデル（Gemini など）に Pub/Sub のメッセージを渡し、 推論を取得してメッセージに追加することができる 機能です。 通常の SMTs 同様に、AI 推論 SMT はトピックとサブスクリプションのどちらでも設定することができます。 トピックに設定した場合、推論結果がメッセージに追加されたあと、トピックに紐づくすべてのサブスクリプションにメッセージが配信されます。 トピックに対して AI 推論 SMT を設定した場合 サブスクリプションに設定した場合は、そのサブスクリプションでのみ推論を取得するような動作となります。Pub/Sub のユースケースに合わせて設定するとよいでしょう。 サブスクリプションに対して AI 推論 SMT を設定した場合 参考 : AI 推論 SMT 参考 : 単一メッセージ変換（SMT）の概要 - SMT のサンプル メッセージ フロー AI 推論 SMT の利点 AI 推論 SMT を使用してモデル推論とデータ変換を行う場合、以下のようなメリットがあります。 メッセージに対してリアルタイムで AI モデルによる推論結果を追加することができる（データ エンリッチメント） モデルから推論を取得するための処理をアプリケーション側に実装する必要がなくなる サブスクリプションに設定した場合、Pub/Sub はモデル エンドポイントの過負荷を回避し推論のスループットを最大化するため、リクエストレートを最適化する（フロー制御） ※ 単項 pull では最適化されない点に注意 参考 : AI 推論 SMT - メッセージ フロー 使用できるモデル Model Garden で提供されているモデル AI 推論 SMT では、トピックまたはサブスクリプションを作成する際にモデルの推論用のエンドポイントを指定します。 Vertex AI Model Garden で提供されているモデルを使用する場合、以下のような形式でエンドポイントを指定します。 - ai - aiInference : endpoint : "projects/<プロジェクトID>/locations/<モデルを利用するリージョン>/publishers/<モデルのパブリッシャー>/models/<モデル名>" 使用できるモデルの一覧については、以下のドキュメントで最新の情報を確認してください。 参考 : AI 推論 SMT - 互換性のある MaaS モデル Vertex AI Endpoints にデプロイしたモデル ユーザーが Vertex AI Endpoints を使用して Google Cloud 上にデプロイしたモデル（セルフデプロイ モデル）を推論に使用することもできます。 セルフデプロイ モデルを使用する場合は、モデルのエンドポイントの指定の仕方が異なります。 - aiInference : endpoint : "projects/<プロジェクトID>/locations/<エンドポイントのリージョン>/endpoints/<エンドポイント>" 参考 : エンドポイントにモデルをデプロイする モデルの入力・出力 入力するメッセージの形式 AI 推論 SMT による推論を行うためには、Pub/Sub に入力されるメッセージが特定の形式になっている必要があります。 例えば gemini-2.5-flash のような Gemini 基盤モデルを使用する場合、 Chat Completions API を使用して Gemini が呼び出されるため、以下のように Pub/Sub トピックに送信するメッセージの形式を API の仕様に合わせます。 { " model ":" google/gemini-2.5-flash ", " messages ": [ { " role ": " user ", " content ": " Explain how AI works in a few words " } ] } 参考 : AI 推論 SMT - メッセージ処理 推論後のメッセージの形式 AI 推論 SMT によって取得したモデルのレスポンスは、以下のように元のメッセージに追加されます。 { " original_message ": " <元のメッセージ> ", " model_output ": " <推論によって取得したモデルのレスポンス> " } 制限事項 AI 推論 SMT には以下のような制限事項があります。 トピックまたはサブスクリプションに設定できる AI 推論 SMT の数は1つまで Vertex AI Endpoints のプライベート エンドポイントはサポートされていない（公開エンドポイントのみ使用可） グローバル エンドポイントは、Gemini 基盤モデルでのみサポートされる。その他のモデルではリージョン エンドポイントのみ使用可能 Pub/Sub 側では入力されたメッセージのデータ形式などの検証は行われない。トピックにメッセージを送信する前に検証する必要がある 1つのメッセージごとに1つの推論リクエストのみが可能であり、バッチ推論は不可 指定したモデルによる推論は60秒以内に完了する必要がある 推論が60秒を超過するとタイムアウトとなり、Pub/Sub に設定したメッセージ保持期間と再試行回数の上限まで再試行が行われ、その後デッドレタートピックにメッセージが転送されます。 その他、制限事項に関する最新情報は以下のドキュメントをご一読ください。 参考 : AI 推論 SMT - 制限事項 設定手順 手順の概要 当記事で紹介する手順は、サブスクリプションに対して AI 推論 SMT によるメッセージ変換を設定し、そのサブスクリプションのコンシューマーに対してのみ推論結果を含めたメッセージを配信できるようにするためのものです。 参考 : AI 推論 SMT - AI 推論 SMT を作成する サービスアカウントの作成・権限付与 AI 推論 SMT を使用する場合、Cloud Pub/Sub サービスエージェント（ service-<プロジェクト番号>@gcp-sa-pubsub.iam.gserviceaccount.com ）に対して Vertex AI サービス エージェント （ roles/aiplatform.serviceAgent ）ロールを付与するか、カスタムサービスアカウントに対して Vertex AI ユーザー （ roles/aiplatform.user ）ロールを付与します。 当記事ではカスタムサービスアカウントを使用します。 # サブスクリプション用のサービスアカウントを作成 $ gcloud iam service-accounts create pubsub-ai-inference-smt \ --display-name =" Pub/Sub AI Inference SMT " # Vertex AI ユーザー ロールの付与 $ gcloud projects add-iam-policy-binding < プロジェクトID > \ --member =" serviceAccount:pubsub-ai-inference-smt@<プロジェクトID>.iam.gserviceaccount.com " \ --role =" roles/aiplatform.user " 定義ファイルの作成 ai-smt.yaml という名前で AI 推論 SMT の定義ファイルを作成します。これをトピックもしくはサブスクリプションの作成時に指定することで、AI 推論 SMT を使用することができます。 - aiInference : endpoint : "projects/<プロジェクトID>/locations/asia-northeast1/publishers/google/models/gemini-2.5-flash" unstructuredInference : { parameters : { "temperature" : 0.5 , "max_tokens" : 1000 } } serviceAccountEmail : "pubsub-ai-inference-smt@<プロジェクトID>.iam.gserviceaccount.com" endpoint にはモデルのエンドポイントを指定します。 unstructuredInference.parameters には、モデルに推論リクエストを送信する際のパラメータや最大トークン数などを指定できます。 serviceAccountEmail には、先ほど作成したサービスアカウントを指定します。 トピックの作成 Pub/Sub のトピックを作成します。 # トピックの作成 $ gcloud pubsub topics create ai-smt-topic トピックに AI 推論 SMT を設定する場合、ここで --message-transforms-file オプションを使用します。 参考 : gcloud pubsub topics create AI 推論 SMT を使用するサブスクリプションの作成 トピックに紐付けるサブスクリプションを作成します。 当記事ではサブスクリプション側に AI 推論 SMT によるメッセージ変換処理を設定するため、 --message-transforms-file で先ほど作成した定義ファイルを指定します。 # AI 推論 SMT を使用するサブスクリプションの作成 $ gcloud pubsub subscriptions create ai-smt-topic-sub \ --ack-deadline = 600 \ --topic ai-smt-topic \ --message-transforms-file ai-smt.yaml 動作確認 メッセージのパブリッシュ 作成したトピックに対してメッセージをパブリッシュしてみます。 AI 推論 SMT で Gemini モデルを指定しているため、 --message には、 Chat Completions API の仕様に合わせた形式でメッセージを設定します。 # プロンプトを含むメッセージのパブリッシュ $ gcloud pubsub topics publish ai-smt-topic --message =$' { "model":"google/gemini-2.5-flash","messages":[{ "role": "user", "content": "Vertex AI について簡単に説明して" }] } ' 参考 : gcloud pubsub topics publish メッセージの受信 サブスクリプションに配信されたメッセージを確認します。 # メッセージを受信し、データを復号したあと JSON に変換 $ gcloud pubsub subscriptions pull ai-smt-topic-sub \ --auto-ack \ --format =" value(message.data.decode(base64)) " | jq . 受信したメッセージには、元のメッセージである "original_message" に加え、サブスクリプション側の AI 推論 SMT によって "model_output" が含まれていることがわかります。 以下は受信したメッセージの例です。 { " model_output ": { " choices ": [ { " finish_reason ": " stop ", " index ": 0 , " logprobs ": null , " message ": { " content ": " Vertex AI は、Google Cloud が提供する、**機械学習（ML）開発のための統合プラットフォーム**です。 \n\n 簡単に言うと、MLモデルを開発する際に必要な「データの準備」「モデルの構築」「トレーニング」「デプロイ（公開）」「監視・管理」といった**あらゆる工程を、一つの場所で効率的に行えるようにするための「ワンストップショップ」**のようなものです。 \n\n **主なポイント：** \n\n 1. **統合された環境:** これまでバラバラだったML開発のツールやサービスを一つにまとめ、開発プロセスをシンプルにします。 \n 2. **効率化と高速化:** データサイエンティストやMLエンジニアが、インフラの管理に時間を取られることなく、モデルの開発や改善に集中できるよう設計されています。 \n 3. **幅広い対応:** カスタムモデルの構築はもちろん、画像認識や自然言語処理などの特定のタスクに対応した事前学習済みモデルの利用や、AutoML（自動機械学習）機能も提供します。 \n 4. **スケーラビリティ:** Googleの強力なインフラ上で動作するため、大規模なデータや複雑なモデルのトレーニングも柔軟に対応できます。 \n\n 例えるなら、ML開発に必要なあらゆる道具が揃った「高機能な作業台」のようなものです。これにより、企業はより迅速にMLをビジネスに導入し、価値を生み出すことができるようになります。 ", " role ": " assistant " } } ] , " created ": 1775550770 , " id ": " MsHUaYLcFaKTp_QP1_SwiAw ", " model ": " google/gemini-2.5-flash ", " object ": " chat.completion ", " system_fingerprint ": "", " usage ": { " completion_tokens ": 263 , " completion_tokens_details ": { " reasoning_tokens ": 1066 } , " extra_properties ": { " google ": { " traffic_type ": " ON_DEMAND " } } , " prompt_tokens ": 6 , " total_tokens ": 1335 } } , " original_message ": { " messages ": [ { " content ": " Vertex AI について簡単に説明して ", " role ": " user " } ] , " model ": " google/gemini-2.5-flash " } } 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の菊池です。BigQuery においてクエリを保存・管理するための3つの手法（保存済みクエリ、スケジュールされたクエリ、BigQuery パイプライン）と、それぞれの特徴や確認方法について解説します。 はじめに 保存済みクエリ 概要 設定方法 保存場所 特徴・利点 スケジュールされたクエリ 概要 設定方法 保存場所 特徴・利点 BigQuery パイプライン 概要 設定方法 保存場所 特徴・利点 クエリが見つからない場合の確認フロー はじめに BigQuery では、作成した SQL クエリを再利用したり自動実行したりするために、複数の保存・管理方法が用意されています。 2026年3月現在、主に以下の手法が提供されていますが、それぞれ管理される場所や用途が異なるため、作成したはずのクエリが見当たらないといった混乱が生じることがあります。 保存済みクエリ スケジュールされたクエリ BigQuery パイプライン 当記事では、これらの違いと、それぞれのクエリが Google Cloud コンソールのどこに表示されるかを整理します。 なお BigQuery 自体の詳細な解説については、以下の記事も参照してください。 blog.g-gen.co.jp 保存済みクエリ 概要 保存済みクエリ （saved queries）は、クエリエディタで作成した SQL を Google Cloud コンソール上に保存し、自分自身での再利用やチームメンバーとの共有を可能にする機能です。 参考 : 保存済みクエリを管理する 設定方法 クエリ エディタで SQL を記述後、ツールバーの [保存] > [クエリを保存] をクリックします。 クエリを保存 なお、プルダウンメニュー内にある「クエリ（従来）を保存」は旧来型の機能であり、バージョニングや他人への共有をすることができない保存方法です。現在では使用は推奨されません。 次に [クエリを保存] ダイアログで、クエリの名前を入力して、 [保存] をクリックします。 クエリの名前を入力して保存 保存場所 Google Cloud のコンソールで BigQuery のページに移動します。 [左ペインを開く] マークをクリックして、 [エクスプローラ] タブをクリックします。 左ペインのエクスプローラタブ プロジェクト名をクリックして開き、 [クエリ] をクリックします。 保存済みクエリの表示 保存済みクエリの一覧が表示されます。 保存済みクエリの一覧 特徴・利点 保存済みクエリには、自動的なバージョニング機能が備わっています。保存を実行するたびに新しいバージョンが記録されるため、過去の履歴を遡って以前の構文を確認したり、特定の時点の状態を参照したりすることが可能です。 保存済みクエリのバージョン履歴 また、保存したクエリごとに固有のリンク（URL）を発行できる点も大きな利点です。共有相手に適切な Identity and Access Management（以下、IAM）権限を付与することで、クエリを安全かつ迅速にチームメンバーへ共有できます。 スケジュールされたクエリ 概要 スケジュールされたクエリ （scheduled queries）は、特定の SQL クエリを定期的（日次、週次、あるいはカスタムの間隔）に自動実行するための機能です。 なおスケジュールされたクエリは、バックエンドで BigQuery Data Transfer Service の仕組みを使用しているため、スケジュールを設定済みのクエリは BigQuery Data Transfer Service のジョブ一覧に表示されます。 参考 : クエリのスケジューリング 設定方法 クエリ エディタで SQL を記述後、ツールバーの [スケジュール] をクリックします。 スケジュールをクリック スケジュールされたクエリを設定する画面が表示されるので、名前や繰り返しの設定をして [保存] をクリックします。 スケジュールの設定 保存場所 コンソール左側のナビゲーションメニューにある [スケジュールされたクエリ] をクリックします。 スケジュールされたクエリの選択 スケジュールされたクエリの一覧が表示され、作成済みの設定一覧や実行履歴、実行ステータスを確認できます。 スケジュールされたクエリ一覧 特徴・利点 スケジュールされたクエリを利用することで、定期的なデータの集計や中間テーブルの更新といった定型処理を自動化できます。 クエリの実行結果を指定したテーブルに上書き、あるいは追記するように制御できるほか、実行完了時や失敗時にメール通知を送信する設定も可能です。 BigQuery パイプライン 概要 BigQuery パイプライン （BigQuery pipelines）は、複数のデータ処理ステップをワークフローとして統合管理する機能です。 内部的には Dataform を使用しており、データの依存関係を考慮した複雑な処理体系を Google Cloud コンソール上で直接構築できます。 参考 : BigQuery パイプラインの概要 設定方法 コンソール左側の [エクスプローラ] タブでプロジェクト名をクリックして開き、 [パイプライン] をクリックします。 パイプライン一覧を開く パイプラインの一覧が表示されます。 [+パイプライン] をクリックして、パイプラインを新規作成します。 パイプライン一覧画面からの作成 あるいは、エディタペインのタブバーで [+] 記号の横にある 矢印マークをクリックし、 [パイプライン] をクリックすることでも新規作成できます。 エディタペインからのパイプライン作成 パイプライン画面 新規作成したパイプラインの画面で、 [タスクを追加] > [クエリ] をクリックします。 クエリを追加 クエリタスクが追加されるので、 [クエリを編集] をクリックします。 クエリを編集 クエリタスクの編集画面が表示されるので、クエリタスク名を修正してクエリを記載したら、 [クエリを保存] をクリックします。 クエリタスクの保存 保存場所 パイプラインで保存したクエリを確認するには、設定方法で開いたパイプライン一覧画面から、対象のパイプラインを選択します。 パイプライン選択 パイプラインの画面で確認したいクエリタスクをクリックすることで、クエリが表示されます。 パイプラインのクエリ確認 BigQuery パイプラインで作成されたクエリは、プロジェクト内の Dataform で管理されます。そのため、通常の [保存済みクエリ] や [スケジュールされたクエリ] の一覧には表示されません。 パイプラインのスケジュール実行は、 Dataform のワークフロー構成として管理されるため、 [スケジュールされたクエリ] の一覧にも表示されません。 特徴・利点 BigQuery パイプラインの最大の特徴は、複数のタスク間における依存関係を視覚的に管理できる点です。先行する処理が成功した後に後続の処理を実行するといった、複雑なクエリやテーブル更新の前後関係をキャンバス上で直感的に構築できます。 パイプラインのクエリの依存関係 クエリが見つからない場合の確認フロー 作成したクエリがどの機能で作成されたかによって、確認すべき場所が異なります。以下の表を参考に、適切な場所を確認してください。 手法 コンソールの確認場所 主な用途 保存済みクエリ エクスプローラタブ > 保存済みクエリ SQL の断片や定型文の保存・共有 スケジュールされたクエリ ナビゲーションメニュー > スケジュールされたクエリ 単一クエリの定期的な自動実行 BigQuery パイプライン エクスプローラタブ > パイプライン 依存関係を持つ複雑な ETL 処理の管理 「パイプラインを使い始めたが、保存したはずのクエリが [保存済みクエリ] に表示されない」、「パイプラインでスケジュールを設定したが、 [スケジュールされたクエリ] に表示されない」という場合は、前述したコンソールの確認場所から BigQuery パイプライン の項目を確認してください。 BigQuery パイプラインは内部で Dataform を使用しており、 保存済みクエリやスケジュールされたクエリとは独立した管理体系になっています。管理される場所が異なる点に注意が必要です。 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、GCPは未経験なので現在勉強中。