G-gen の山崎です。本記事は Google Cloud Next '25 in Las Vegas の1日目に行われたブレイクアウトセッション「 What’s new in Cloud Run 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Cloud Run の新機能 Cloud Functions の統合 Gemini Code Assist in Cloud Run functions Cloud Storage volume mounts Firebase App Hosting Gemini Cloud Assist Direct VPC egress improvements Identity-Aware Proxy（IAP）built-in Cloud Run Threat Detection High availability architectures Cloud Run Worker Pools Vertex Studio to Cloud Run Cloud Run with GPUs 関連記事 セッションの概要 本セッションでは、Cloud Run with GPUs、High availability architectures、Cloud Run Worker Pools といった Cloud Run の新機能の紹介が行われました。 Cloud Run の新機能 Cloud Functions の統合 2024年8月に Google Cloud のサーバーレス コンピューティング サービスである Cloud Functions が Cloud Run functions としてリブランディングされました。 それに伴い、Cloud Run にデプロイする際に新しいデプロイメントオプションとして「関数」が選択できるようになり、コンテナ、リポジトリ、ソースコードに加えて、単一目的の関数をデプロイできるようになりました。 Cloud Functions のリブランディングの詳細については、以下の記事で解説しています。 blog.g-gen.co.jp Gemini Code Assist in Cloud Run functions Google Cloud コンソール上で、Cloud Run functions のコード作成を行う際に、 Gemini Code Assist によるコード作成支援が受けられるようになりました。 Cloud Storage volume mounts Cloud Run 上で Cloud Storage バケットをローカルファイルシステムのようにマウントする機能が提供されました。 機能の詳細については以下の記事をご一読ください。 blog.g-gen.co.jp Firebase App Hosting Angular、Next.js、Nest、Astro といったフレームワークを用いて Cloud Run にデプロイを行う際に、 Firebase App Hosting を使用することで、より容易にデプロイを行うことが可能となりました。 参考 : Firebase App Hosting Gemini Cloud Assist Cloud Run に関する以下のようなシーンで Gemini Cloud Assist を活用することができます。 Design Cloud Run リソースの Terraform 構成と gcloud CLI を生成 Optimize Cloud Run リソースのコスト最適化 Troubleshoot トラブルシューティングの支援、修正内容の提案 Direct VPC egress improvements Cloud Run services では、 Direct VPC egress を用いることで、サービスから VPC ネットワークにトラフィックを送信することができます。 しかし、Direct VPC egress を使用する場合、接続先となるサブネットで 最大インスタンス数の4倍 の IP アドレスを確保することが推奨されており、IP アドレスが枯渇するとコンテナインスタンスのスケーリングが阻害されてしまいます。 今回の改善により、必要となる IP アドレスの数は、 最大インスタンス数の2倍 となり、 以前の半分の IP アドレスの数 となりました。 また、アップデートにより Cloud Run jobs でも Direct VPC egress が使用可能となりました。 Direct VPC Egress の詳細な解説については以下の記事をご一読ください。 blog.g-gen.co.jp Identity-Aware Proxy（IAP）built-in 例えば、社内向けの Web アプリケーションを Cloud Run services で構築する場合、 Identity-Aware Proxy （IAP）と併せてロードバランサを使用する必要がありました。 アップデートにより、ロードバランサを使用せずに IAP を使用することが可能となりました（プレビュー版の機能）。 機能の詳細については以下の記事をご一読ください。 blog.g-gen.co.jp Cloud Run Threat Detection Cloud Run Threat Detection は、実行中のコンテナインスタンスを継続的に監視し、コンテナ内で実行される悪意のあるアクション（リモートアクセス、異常な動作、既知の脆弱性など）を検出します。 これらの脅威が発生すると、Security Command Center に表示されます。 機能の詳細については、以下の記事で解説しています。 blog.g-gen.co.jp High availability architectures Cloud Run はゾーン冗長性を提供するリージョナルサービスのため、Google Cloud がリージョン内のゾーンが障害等で使用できなくなったとしても、サービスの利用上、問題は発生しません。 しかし、リージョン全体の障害の場合にも信頼性を確保したいというユースケースのために、複数のリージョンに Cloud Run をデプロイし、リージョンがダウンした際にリージョンが健全な状態に戻るまでトラフィックのルーティングを停止する機能が提供されました（プレビュー版の機能）。 こちらは追加コストなく使用することができます。 マルチリージョンサービスの詳細については、以下の記事で解説しています。 blog.g-gen.co.jp Cloud Run Worker Pools Cloud Run services、Cloud Run jobs に続く新たなワークロードとして Cloud Run Worker Pools が発表されました。 Cloud Run Worker Pools は、 pull ベースのワークロード とされ、主に以下のユースケースにて使用されるとしました。 Kafka のキューからタスクを取得して処理を実行 Pub/Sub の pull サブスクリプションからメッセージをまとめて取得して処理を実行 Worker Pool を GitHub Actions のセルフホストランナーとして登録 Vertex Studio to Cloud Run Vertex AI Studio から Cloud Run に対して、ワンクリックでのデプロイが可能となりました。 Cloud Run with GPUs Cloud Run services において、GPU が使用可能となりました。 以下4つの特徴があるとしました。 オンデマンド ゼロスケール 高速起動 秒単位の支払い その中でも特筆すべきは、 高速起動 とし、GPU がコンテナにない状態から、GPU が完全に起動した状態となるまでの時間が 5秒 であり、競合他社で利用可能なものよりも数段高速であることを強調しました。 また、Cloud Run jobs においても GPU の使用が近日プレビュー公開となると発表がありました。 これにより、ファインチューニング、バッチ AI 推論、メディア処理といったユースケースにおいて、Cloud Run GPU が使用されることが期待されます。 Cloud Run における GPU の詳細については以下の記事で解説しています。 blog.g-gen.co.jp 関連記事 blog.g-gen.co.jp 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 12 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の道下です。本記事は Google Cloud Next '25 in Las Vegas の 1日目に行われたスポットライトセッション「 Google Workspace: How businesses are using AI to drive results 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 新機能の発表 Audio in Docs Gemini in meetings Help me Refine in Docs Generate a video in Vids Help me analyze in Sheets Google Workspace Flows 顧客事例 関連記事 セッションの概要 本セッションでは、Gemini と統合された Google Workspace の新機能や顧客事例が紹介されました。 新機能の発表 Audio in Docs Audio in Docs は、Google ドキュメントのドキュメントを音声で読み上げたり、要約した結果を音声で読み上げる機能です。 Gemini in meetings Gemini in meetings は「会議中のアドバイザー」を目指した機能追加です。Meet 会議に遅れて参加した際に Gemini が会議開始からの内容を教えてくれたり、議論の背景を提供してくれます。 また、会議を一時的に退席していたとき、戻った後に Gemini に「過去5分間の会話の内容を教えて」など指示すると、自分が中座していたときの会話内容を要約して教えてくれます。 Help me Refine in Docs Help me Refine in Docs は、Google ドキュメントに導入される新機能で、単なる文章の下書き生成を超える「ライティングコーチ」のような機能です。 この機能では、文章をリファイン（書き換え）してくれます。 Generate a video in Vids Google Vids は、専門知識や高価なソフトウェアなしで、ユーザーが動画（トレーニング資料、プロセス説明など）を作成できる Google Workspace アプリです。 Google Vids は従来、既存の動画や画像といった素材を組み合わせて、動画を作成するための動画編集サービスでした。この Vids に、動画生成モデルである Veo 2 が組み込まれ、動画のゼロからの生成もできるようになりました。最新鋭の動画生成モデルが使われるため、単一のプロンプトで短く高品質なカスタム動画を作成できます。 ※ 文字が薄く見えにくくなっています Help me analyze in Sheets Help me analyze in Sheets は、Google スプレッドシートの内容を分析してくれます。 「オンデマンドのデータアナリスト（on-demand data analyst）」として設計されており、どこから手をつければ良いかわからない場合でも役立つ機能であると紹介されました。 Google Workspace Flows Google Workspace Flows は、コンテキスト（Context、背景情報）と推論（Reasoning）を必要とする、より複雑な複数ステップのプロセス（multi-step processes）を自動化するための新しい方法として紹介されました。 メールの文章作成などの単一のタスクのみならず、その後の作業を含めた複数ステップの業務タスク全体を、AI が支援してくれる機能になる見込みです。 顧客事例 Esty 社では、顧客からの問い合わせデータを Sheets で管理していたが、Gemini in Sheetsを活用して分析時間の大幅な短縮を実現できたこと、そこから波及して顧客対応、従業員体験、部門間連携が向上したことが語られました。 関連記事 blog.g-gen.co.jp 道下 千晃 (記事一覧) クラウドソリューション部 大阪府在住。Google Cloud Certification 全11冠 Google Cloud にはいろいろなサービス、プロダクトがあって楽しいですね。 趣味はテニス、オンラインゲーム（世界を救ったり、魚を釣ったり、武器防具を作ったり） Follow @Chiaki_Michi

G-gen の杉村です。当記事では、Google Cloud Next '25 で発表された BigQuery の新機能について紹介します。 概要 BigQuery と AI の統合 全体像 BigQuery data preparation データセットレベルのインサイト（BigQuery データキャンバス） BigQuery pipelines にデータエンジニアリングエージェントが組み込み Colab Notebook にデータサイエンスエージェントが組み込み BigQuery AI query engine BigQuery DataFrames におけるコード支援 Looker の会話型分析 SQL 移行アシスト データガバナンス Dataplex Catalog が BigQuery universal catalog に改名 Automated metadata curation（メタデータの自動生成） BigQuery knowledge engine カタログのセマンティック検索 Data products BigQuery metastore ビジネス用語集 カタログメタデータのエクスポート BigLake とオブジェクトテーブルの自動カタログ生成 Automated anomaly detection BigQuery ガバナンス データの共有 Analytics Hub が BigQuery Sharing に改名 データを収益化 ストリーミングデータの共有 ストアドプロシージャの共有 クエリテンプレートの共有 セキュリティ カラムへのデータポリシー適用 行レベルのセキュリティでサブクエリがサポート マルチモーダル自律データ基盤 BigQuery tables for Apache Iceberg ObjectRef 型の導入（BigQuery multimodal tables） BigQuery DataFrames の強化 AI.GENERATE 関数 ベクトル検索の強化 時系列予測用の新モデル コントリビューション分析 エンタープライズ向け機能 Managed disaster recovery Workload management クエリ性能の向上 ショートクエリ向け API 履歴ベースの最適化 Column metadata index（CMETA） 新しい分析機能 継続的クエリ パイプ構文 Geospatial analytics（地理空間分析） ISV エコシステム Gemini in BigQuery の料金体系改定 関連記事 概要 Google Cloud の旗艦イベントである Google Cloud Next '25 では、BigQueryに関する新機能の情報が公開されました。 当記事では、AI による メタデータの自動生成 （automated metadata generation）、 BigQuery tables for Apache Iceberg 、 コントリビューション分析 、 BigQuery universal catalog （Dataplex Catalog から改名）、 地理空間分析 （Geospatial analytics）などの新機能について紹介します。当記事は、以下の公式発表に基づいて記載されています。 参考 : What's new with BigQuery — the autonomous data-to-AI platform なお当記事を公開した4月11日（日本時間）以降、以下の新しい公式記事が公開されたため、これらに関する情報も随時、追記しています。 参考 : Introducing BigQuery unified governance: universal, intelligent, and open 参考 : What's new for Data Analytics in the AI driven, autonomous and agentic era 当記事に記載されている情報は、いずれも記事を執筆、追記した2025年4月12日（日本時間）現在のものですのでご留意ください。 BigQuery と AI の統合 全体像 BigQuery は以前より、生成 AI によるデータエンジニアリングや分析の機能（ Gemini in BigQuery ）が随時、追加されてきました。Next 25 では、以下の図のように、データ分析のライフサイクル全体における AI との関わりが整理されています。 図は公式ブログ記事より引用 BigQuery data preparation BigQuery data preparation （BigQuery データ準備）は、自然言語による指示に基づいて、データ変換パイプラインを構築するツールです。BigQuery Studio（BigQuery の Web コンソール画面）と統合されており、ローコードでデータ変換パイプラインを構築できます。バックエンドでは、Dataform が動作しています。 同機能は以前よりプレビュー公開されていましたが、2025年4月7日に一般公開（GA）されました。 参考 : Introduction to BigQuery data preparation BigQuery data preparation データセットレベルのインサイト（BigQuery データキャンバス） BigQuery data canvas （BigQuery データキャンバス）は、自然言語による指示と、グラフィカルなインターフェイスにより、オンデマンドにデータを検索、変換、クエリ、可視化するツールです。 同機能は2024年8月28日に一般公開（GA）済みですが、新機能として データセットレベルのインサイト （dataset-level insights）がプレビュー公開されました。 参考 : Analyze with BigQuery data canvas BigQuery pipelines にデータエンジニアリングエージェントが組み込み BigQuery Studio から利用できる簡易的なワークフロー構築ツールである BigQuery pipelines に、 データエンジニアリングエージェント （Data engineering agent）が組み込まれます（GA）。 データパイプラインの構築、異常検出、メタデータ生成などが AI によって自動化され、データエンジニアチームの生産性を向上します。 Colab Notebook にデータサイエンスエージェントが組み込み BigQuery Studio から利用できる Colab Notebook に、 データサイエンスエージェント （Data science agent）が組み込まれます（GA）。 データサイエンスエージェントにより、特徴量エンジニアリングやモデル選定が AI によって補助され、効率化します。 BigQuery AI query engine BigQuery AI query engine は、BigQuery の notebook 上で利用できる、データサイエンティスト向けの AI 補助機能です。 この機能により、構造化データのみならず、非構造化データも含めたシームレスな処理や、現実世界の背景情報を交えた分析が効率化されます。 例として、「在庫情報に含まれる製品のうち、新興経済国で主に製造されているのはどれですか」「このソーシャルメディアの写真に写っている製品はどれですか」といった質問が可能です。前者の質問は、AI が新興経済国を理解していることを意味します。後者の質問は、AI が非構造化データを処理できることを意味しています。 BigQuery DataFrames におけるコード支援 BigQuery DataFrames は、BigQuery API を介したデータの変換や機械学習を容易に行える Python のオープンソースパッケージです。 参考 : BigQuery DataFramesを徹底解説 - G-gen Tech Blog 参考 : BigQuery DataFrames 今回、BigQuery DataFrames でコード生成や補完が利用できるようになりました（プレビュー）。 参考 : Write queries with Gemini assistance - Generate BigQuery DataFrames code Looker の会話型分析 Google の BI＆データプラットフォームサービスである Looker でも、AI 関連機能が進化しています。 Looker の会話型分析 （Looker conversational analytics）では、ユーザーが自然言語でデータと対話できるようにします（プレビュー）。 自然言語の指示に基づいて AI が分析を行うことに加えて、その思考プロセスが説明されます。これにより、ブラックボックスになりがちな AI による分析の中身が明らかになり、曖昧さが減少します。 また関連して、 conversational analytics API が公開されます（プレビュー）。この API を利用することで、他のアプリケーションやワークフローに、Looker の会話型分析を組み込めるようになります。 SQL 移行アシスト SQL 移行アシスト （SQL translation assistance）は、他のデータベースから BigQuery への移行を支援するツールです。既存の SQL を、BigQuery で利用できる形に変換する作業を支援します。同機能は、GA です。 自然言語プロンプトを使用して、SQL を記述したり、構文の置換に使用する SQL パターンを特定できます。 参考 : Translate queries with the interactive SQL translator - Create a translation rule データガバナンス Dataplex Catalog が BigQuery universal catalog に改名 フルマネージドのデータカタログ管理サービスである Dataplex Catalog が、 BigQuery universal catalog に改名されました。 BigQuery universal catalog は、Dataplex Catalog の従来機能と、BigQuery metastore のランタイムメタストア機能が統合されたものになります。 BigQuery universal catalog は、単なる改名や既存機能の統合にとどまらず、生成 AI との統合により、データマネジメントをより推し進めるものになっています。また、Apache Iceberg などのオープンストレージ標準に準拠する機能を備えており、これまでより柔軟に他のクエリエンジンとの統合が実現できます。 参考 : Introducing BigQuery unified governance: universal, intelligent, and open 参考 : Dataplex Catalogを徹底解説！ - G-gen Tech Blog （2025年7月追記）BigQuery universal catalog はさらに改名され、現在では各種ドキュメントにおいて Dataplex Universal Catalog と表記されています。 参考 : Dataplex Universal Catalog overview Automated metadata curation（メタデータの自動生成） 新機能 Automated metadata curation により、AI による自動的なメタデータ生成が利用可能になります（プレビュー公開）。 Automated metadata curation では、プロファイルスキャンと Gemini により、テーブルやカラムに一貫性のあるメタデータを自動的に付与できます。この機能では、Gemini が テーブルのスキーマ、リレーション、説明欄（description）、過去のクエリ履歴などを分析 して、メタデータを生成します。 データに対する適切なメタデータの付与は、データガバナンスの観点ではもちろん、AI 活用の観点でも重要になっています。この機能により、データスチュアードやビジネスユーザーが手動でメタデータを付与する労力が改善されます。またメタデータの付与は、後述するカタログのセマンティック検索機能により、ユーザーがデータを見つけやすくするためにも重要です。 BigQuery knowledge engine BigQuery knowledge engine は、複数テーブルにまたがるクエリの提案や、自然言語による質問への回答などにより、複数のデータセットやテーブルの間の関係性を可視化し、把握するための機能です。 BigQuery knowledge engine により、BigQuery universal catalog がクロステーブルなクエリをサジェストすることもできます。 カタログのセマンティック検索 カタログのセマンティック検索 （Full-catalog search with semantic understanding）機能では、複数のプロジェクトに渡って存在する BigQuery データセットのメタデータに対して、セマンティック検索（意味論検索）ができるようになります（プレビュー）。 これにより、エンジニアのみならず、ビジネスユーザーがより容易に BigQuery 内のデータを発見できるようになります。 Data products Data products は、データのオーナーが、ユースケースごとにデータ資産のコレクションを作成、共有、管理する機能とされています。この機能では、セキュリティのベストプラクティスに従った方法で、組織内および組織外に対して、データ資産をパッケージ化して共有できます。 同機能については、詳細は発表されていませんが、プレビュー公開されると発表されました。 BigQuery metastore BigQuery metastore は、BigQuery、Apache Spark、Apache Flink のエンジン間の相互運用を可能にする機能です。同機能は2025年1月にプレビュー公開されており、今回 GA となりました。 BigQuery metastore は、Spark 等の外部のエンジンからカタログとして利用できます。また Spark で作成したテーブルに、BigQuery からクエリするなどが可能になります。テーブル形式は Apache Iceberg をサポートしています。 参考 : Introduction to BigQuery metastore ビジネス用語集 ビジネス用語集 （business glossaries）は、Dataplex で提供される機能です。これまでプレビュー公開だったものが、今回 GA になりました。 組織のビジネス用語を用語集に登録し、データ利用者が利用したり、メタデータの付与時や、データカタログの検索に用いたりします。 参考 : Create and manage Dataplex business glossaries カタログメタデータのエクスポート カタログメタデータのエクスポート （Catalog metadata export）機能は、データカタログを一括で Cloud Storage バケットにエクスポートできる機能です（GA）。 エクスポートしたメタデータは、BigQuery 等で分析したり、プログラムからアクセスさせることができます。 BigLake とオブジェクトテーブルの自動カタログ生成 BigLake とオブジェクトテーブルの自動カタログ生成（cataloging of BigLake and object tables）機能が公開されました（GA）。 BigQuery universal catalog により、Cloud Storage に配置した構造化データと非構造化データからメタデータを自動的に収集し、BigLake テーブルを自動的に作成できるようになります（GA）。 Automated anomaly detection BigQuery universal catalog の Automated anomaly detection 機能により、データのエラーや不整合、外れ値を自動的に検知します。この機能も、プレビュー公開です。 この機能は BigQuery pipelines と統合されており、データエンジニアリングエージェントの1機能です。 BigQuery ガバナンス BigQuery ガバナンス （BigQuery governance）は、前述のメタデータ自動生成と、自動カタログ作成機能を含んでおり、単一の統合ビューを提供する機能とされています（プレビュー）。 このビューは、データスチュアードや専門家向けに、データの検出、分類、キュレーション、品質管理、利用状況確認、共有の確認などを行えるものになるとされています。 データの共有 Analytics Hub が BigQuery Sharing に改名 これまで Analytics Hub と呼ばれていた機能は、 BigQuery Sharing に改名されます。 改名に加えて、今回、多くの新機能が発表されました。 参考 : Introduction to BigQuery sharing データを収益化 BigQuery Sharing は、Google Cloud Marketplace と統合され、 データを販売して収益化 することができるようになりました。 Google Cloud Marketplace との統合は、Analytics Hub 時代の2024年12月にプレビュー公開済みです。 参考 : Commercialize listings on Cloud Marketplace ストリーミングデータの共有 BigQuery Sharing で、 ストリーミングデータの共有 （Stream sharing）ができるようになります（GA）。 Pub/Sub トピックで受け取るストリーミングデータを、BigQuery Sharing で共有したり、利用者にキュレートできるようになります。 ストアドプロシージャの共有 BigQuery Sharing で、 ストアドプロシージャの共有 ができるようになります（プレビュー）。 この共有方法では、SQL の実コードを利用者に見せることなく、実行だけを許可できます。 クエリテンプレートの共有 BigQuery Sharing で、 クエリテンプレートの共有 ができるようになります（プレビュー）。 この共有方法により、利用者は共有された SQL を再利用したり、カスタマイズしたりできます。 セキュリティ カラムへのデータポリシー適用 カラムへのデータポリシー適用 （Data policies on columns）では、データポリシーを列に適用できるほか、そのポリシーを他の列やテーブルに再利用できるようになります（プレビュー）。 従来から存在する BigQuery の列レベルのアクセス制御機能の拡張と考えられます。 参考 : BigQueryの列レベルのアクセス制御・行レベルのセキュリティを解説 - G-gen Tech Blog - 列レベルのアクセス制御 行レベルのセキュリティでサブクエリがサポート 行レベルのセキュリティで サブクエリがサポート されます（GA）。既存のデータモデルを変更せずに、行のフィルタリングが可能になるとしています。 参考 : BigQueryの列レベル・行レベルのセキュリティを解説 - G-gen Tech Blog - 行レベルのセキュリティ マルチモーダル自律データ基盤 BigQuery tables for Apache Iceberg BigQuery tables for Apache Iceberg は、Apache Iceberg 形式のテーブルを利用できる機能です。同機能は、今回の Next 25にあわせて、プレビュー公開されました。 Apache Iceberg とは、オープンソースのテーブルフォーマットです。実データは Apache Parquet、Apache Avro 等の形式のファイルで持ちます。Iceberg は、Apache Spark、Apache Hive、Presto などの分散処理フレームワークから利用できます。 BigQuery tables for Apache Iceberg では、Cloud Storage バケットに配置した Parquet 形式のファイルに対応しています。 以前より、BigQuery では BigLake external tables for Apache Iceberg により Apache Iceberg 形式のテーブルを扱うことができましたが、読み取り専用でした。今回リリースされた BigQuery tables for Apache Iceberg は、読み取りに加えて書き込みや、スキーマの変更も可能です。また、列レベルのセキュリティなど、BigQuery のセキュリティ機構も利用することができます。 参考 : BigQuery tables for Apache Iceberg ObjectRef 型の導入（BigQuery multimodal tables） ObjectRef という新しい型により、BigQuery オブジェクトテーブル上の構造化データや非構造化データに対するクエリや保存が容易になります。同機能は、今回の Next 25にあわせてプレビュー公開されました。 ObjectRef 型の登場により、BigQuery では マルチモーダルなテーブル （multimodal tables）が実現できるようになります。 BigQuery DataFrames の強化 BigQuery DataFrames ライブラリに、構造化データと非構造化データを統合分析したり、セマンティックインサイト、Gemini Code Assist 向けのマルチモーダル機能が追加になりました。 AI.GENERATE 関数 BigQuery ML で、 AI.GENERATE_TABLE 関数 を始めとする生成 AI による推論関数が追加になりました（プレビュー）。これらの関数では、Gemini だけでなく, Vertex AI と組み合わせることで、Claude や Llama などのサードパーティモデルも利用できます。 参考 : The AI.GENERATE_TABLE function 参考 : The ML.GENERATE_TEXT function 参考 : The AI.GENERATE_BOOL function 参考 : The AI.GENERATE_DOUBLE function 参考 : The AI.GENERATE_INT function ベクトル検索の強化 BigQuery におけるベクトル検索用に、新しいインデックスタイプである TreeAH vector index が使えるようになりました（GA）。よりリソース効率のよいベクトル検索が可能になります。 参考 : Introduction to vector search 参考 : Manage vector indexes - TreeAH Index 時系列予測用の新モデル BigQuery ML で、よりシンプルに時系列予測を行うための TimesFM model がプレビュー公開されました。Google によってトレーニング済みのモデルです。 参考 : The TimesFM model コントリビューション分析 BigQuery で コントリビューション分析 （contribution analysis）ができるようになりました（GA）。 「先月は、なぜ売上が落ちたのか？」のような Why に対する答えを出すためには、キーファクターを特定する必要があります。コントリビューション分析は キードライバー分析 （key driver analysis）とも呼ばれ、多次元データにおける主要な指標の変化を抽出する手法です。 CREATE MODEL ステートメントでモデルを作成し、ML.GET_INSIGHTS 関数で指標情報を取得します。 参考 : Contribution analysis overview エンタープライズ向け機能 Managed disaster recovery Managed disaster recovery （マネージドな災害対策）機能は、コンピュートとストレージの両方をセカンダリリージョンにフェイルオーバーできる、災害対策（DR）機能です。2024年12月に GA になりました。 参考 : Managed disaster recovery 参考 : BigQueryを徹底解説！(基本編) - G-gen Tech Blog - 災害対策（DR） Workload management BigQuery の reservation（予約。スロットの割り当て設定）は従来、ジョブ種別（QUERY、PIPELINE、ML_EXTERNAL 等）プロジェクトに1つ紐づけるものであり、同じプロジェクトの同種のジョブは、同じ reservation のスロットを共有する仕様でした。 今回、プレビュー機能として、 同じプロジェクトのジョブ でも、 別々の reservation を使用するよう設定 できるようになりました。また、reservation レベルのスロットの fair sharing や、強化されたコスト分析などが追加されます。 参考 : Workload management using reservations 参考 : BigQuery Editionsを徹底解説 - G-gen Tech Blog - 予約、割り当て、コミットメント クエリ性能の向上 ショートクエリ向け API Low latency API for short queries は、小規模なクエリを小さいレイテンシで処理できる API です。2024年8月にプレビュー公開されました。 参考 : Short query optimized mode 参考 : BigQuery の Short query optimized mode（短いクエリの最適化モード）を解説 - G-gen Tech Blog 履歴ベースの最適化 履歴ベースの最適化 （History-based optimizations）は、過去のクエリ実績に基づいて、類似のクエリに最適化を自動適用する仕組みです。2024年9月に GA されました。 参考 : 履歴ベースの最適化を使用する Column metadata index（CMETA） Column metadata index （CMETA）は、事実上無限にスケーラブルなメタデータ管理を提供する機能とされていますが、詳細は記載されていません。 新しい分析機能 継続的クエリ 継続的クエリ （Continuous queries）は、クエリ定義だけで簡単に ELT 処理を構築できる機能です。継続的クエリを定義していおくと、BigQuery テーブルに追加されたレコードに対して、随時 SQL を実行し、他の BigQuery テーブルや Pub/Sub トピック等に格納します。2024年7月に承認付きプレビューとして公開された機能です。 参考 : Introduction to continuous queries 参考 : BigQuery の継続的クエリ（Continuous queries）を解説 - G-gen Tech Blog パイプ構文 パイプ構文 （pipe syntax）は、BigQuery で利用可能なクエリの記述方式です。パイプ演算子（|>）で各操作をつなげることで、データの流れを明確にしながらクエリを作成、修正、デバッグができます。2025年4月1日に GA されました。 参考 : BigQueryのPipe syntax（パイプ構文）を使ってみた - G-gen Tech Blog Geospatial analytics（地理空間分析） Geospatial analytics （地理空間分析）機能として提供される ST_REGIONSTATS 関数により、Earth Engine と Google Maps Platform を BigQuery と連携させ、地理空間（Geospatial）情報を分析に用いることができます。 参考 : Geography functions - ST_REGIONSTATS ISV エコシステム Google Cloud は、ISV との連携を強調しています。ISV とは Independent Software Vendor を指しており、しばしば「サードパーティベンダー」と同義です。 BigQuery においては、Anthropic 社の Claude モデルとの連携や、Informatica 社との連携による AI ガバナンスなどが例に挙げられています。データ転送ソリューションである Fivetran は、BigQuery metastore とのネイティブ統合や、Cloud Storage 向けマネージドデータレイクサービスを導入しました。DBT では、BigQuery DataFrames との統合や、DBT Cloud が Google Cloud で利用可能になるなどの変化がありました。また、Datadog では BigQuery のモニタリング機能が強化されました。 Gemini in BigQuery の料金体系改定 Gemini in BigQuery の料金体系が改定されました。従来、Gemini in BigQuery は、Gemini Code Assist の Enterprise サブスクリプション、または BigQuery Editions の Enterprise Plus エディションに付帯していました。 しかし、2025年4月9日のアップデートにより、オンデマンドモードとすべての BigQuery エディションで、Gemini in BigQuery が利用可能になりました。ただし、前月の BigQuery 利用ボリュームに応じたクォータ（割り当て）が設定されており、1日あたりに実行可能な生成 AI 機能の回数が制限されます。 また、Gemini in BigQuery のうち Data insights とメタデータ自動生成（Automated metadata generation）の2機能は、Standard エディションでは利用できなくなっています。詳細は、以下の公式ドキュメントを参照してください。 参考 : Gemini in BigQuery Pricing Overview 参考 : Quotas and limits - Quotas for Gemini in BigQuery 関連記事 Google Cloud Next '25 の関連記事は、以下の記事一覧をご参照ください。 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 '25 で発表された Google Kubernetes Engine（GKE）における最新の生成 AI 関連機能を紹介します。 概要 GKE における AI 推論 ワークロード GKE Inference Quickstart GKE Inference Gateway GKE TPU serving stack 概要 Google Cloud の旗艦イベントである Google Cloud Next '25 にて、GKE で生成 AI による推論ワークロードを展開するための新たな機能が発表されました。 当記事では、以下の公式発表に基づいて GKE Inference Quickstart 、 GKE Inference Gateway 、 GKE TPU serving stack を紹介します。 参考 : New GKE inference capabilities reduce costs, tail latency and increase throughput GKE における AI 推論 ワークロード Gemini と同じ技術で作られた LLM である Gemma を代表とする 生成 AI オープンモデル は、GKE クラスタ上のマイクロサービスとして AI 推論を提供することができます。 Gemini 等の大規模モデルを API で使用する代わりに、Gemma のような軽量モデルを GKE 上で実行することで、以下のようなメリットを享受することができます。 API ベースで Gemini モデルを利用する場合のように、リクエストの増加に比例してコストが大きくなる心配がない（コストの予測が容易）。 他の利用者によるリクエストによって推論のパフォーマンスが低下する心配がない。 リクエスト送信元のアプリケーションが同じクラスタ上に展開されている場合、レイテンシが抑えられる。 モデルのカスタマイズ性が高い。 AI 推論ワークロードをオンプレミスのクラスタに移行できる。 しかし、自社専用の環境として生成 AI による推論ワークロードを展開したい場合、モデルを実行するサーバやアクセラレータの選定、スケーリング、トラフィック分散、パフォーマンスモニタリングのように、開発から運用にわたって様々な課題があります。 これらの課題を解決するため、新たに3つの機能が GKE で利用できるようになりました。 GKE Inference Quickstart GKE Inference Quickstart は、生成 AI モデル、モデルを提供するサーバ、アクセラレータ（GPU/TPU）、スケーリングといった要件から、Google によるベンチマークに基づいて最適化された Kubernetes 構成を展開することができるレシピを生成することができます。 レシピには、モデルサーバをホストする Pod を展開するための Deployment リソースや Service リソースだけではなく、指定した要件に基づいた HPA（Horizontal Pod Autoscaler）リソース、Cloud Monitoring との連携を提供する PodMonitoring カスタムリソースが含まれます。　　 このように、GKE Inference Quickstart を使用することで、AI 推論ワークロードを展開するための手動での構成の調整やテストをスキップし、GKE クラスタ上に容易かつ迅速に推論ワークロードを展開することができます。 GKE Inference Quickstart の使用方法については、以下の記事で解説しています。 blog.g-gen.co.jp 詳細は、以下のリンクもご参照ください。 参考 : About model inference on GKE 参考 : Run best practice inference with GKE Inference Quickstart recipes GKE Inference Gateway GKE Inference Gateway は 負荷分散機能である Gateway API の拡張機能であり、GKE 上に展開した生成 AI の推論ワークロードに対して最適な負荷分散を提供します。 従来の Gateway ではラウンドロビンのように、リクエストパターンが予測可能なアプリケーション向けに想定された負荷分散の仕組みが使用されます。 しかし、LLM に対する推論リクエストはパターンが大きく変動するため、バックエンドの推論ワークロードに対する負荷分散が上手く行われず、コンピューティングリソース使用率が不均一になり、推論レイテンシの増加を引き起こす可能性がありました。 GKE Inference Gateway は、以下のような生成 AI 特有のリクエストパターンに最適化された負荷分散、ルーティングを提供します。 バックエンドのモデルサーバからの指標を負荷分散に活用し、GPU や TPU などのアクセラレータが効率良く使用されるように負荷分散を行う。 バックエンドで複数のモデル、バージョンを展開している場合に、OpenAI API 仕様で定義されたモデル名に基づいたルーティングを行う。 リクエストの Criticality に基づいたルーティング。低レイテンシが要求される推論リクエストをバッチ推論よりも優先し、リソースが限られている場合は優先度の低いリクエストをドロップできる。 Model Armor との統合によりリクエスト、レスポンス、推論処理のログを提供し、事後分析と最適化に役立てることができる。 リクエストレート、レイテンシ、エラー、サチュレーションといった SRE メトリクスが提供される。 詳細は、以下のリンクもご参照ください。 参考 : About GKE Inference Gateway 参考 : Model Armorを徹底解説！ - G-gen Tech Blog GKE TPU serving stack モデルサーバーである vLLM でアクセラレータとして TPU を使用することで、高パフォーマンスかつ費用対効果の高い推論を実行することができます。 vllm-tpu コンテナイメージの使用により、TPU 特有の変更を加えることなくモデル実行用のコンテナをデプロイすることができ、GPU-TPU 間のポータビリティが実現されます。 前述の GKE Inference Quickstart では TPU をアクセラレータとするベストプラクティス構成も提供されているため、GPU からの切り替えを低コストで迅速に行うことができます。 推論、特に画像生成タスクにおいて 第6世代 TPU である Trillium を使用することで、レイテンシが最大66%削減され、ユーザーエクスペリエンスとコンバージョン率の向上に繋がったユーザー事例が紹介されています。 参考 : Serve an LLM using TPU Trillium on GKE with vLLM 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。当記事では、Google Cloud Next '25 で発表された Google の最新の生成 AI モデル Gemini 2.5 や、 Vertex AI Model Optimizer 、 Vertex AI Global Endpoint などの新機能について紹介します。 概要 Gemini 2.5 Pro Gemini 2.5 Flash Vertex AI Model Optimizer Vertex AI Model Optimizer とは 使用方法 Vertex AI Global Endpoint 関連記事 概要 Google Cloud の旗艦イベントである Google Cloud Next '25 では、以前より試験運用版として公開されていた Gemini 2.5 Pro のパブリックプレビュー開始や、軽量版である Gemini 2.5 Flash の情報が公開されました。 当記事では、以下の公式発表に基づいて、 Gemini 2.5 や、 Vertex AI Model Optimizer 、 Vertex AI Global Endpoint などの新機能について紹介します。 参考 : Gemini 2.5 brings enhanced reasoning to enterprise use cases 当記事に記載されている情報は、いずれも記事を執筆した2025年4月11日現在のものです。 Gemini 2.5 Pro Gemini 2.5 Pro は、深い洞察が必要とされる推論で用いられる Gemini の最新型モデルです。 参考 : Gemini 2.5 Pro コンテキストウインドウは100万トークンです。 現在公開中のプレビュー版では、 QPM （Queries per minute） は20 に制限されています。 当モデルでは、 2025年1月までの情報 がトレーニングに使われています。 Gemini 2.5 Pro への API 経由のリクエストは、Vertex AI または Google AI Studio のいずれかで可能です。 Gemini 2.5 Flash Gemini 2.5 Flash は、Pro よりも軽量のモデルです。応答速度とコストの面で、Pro よりも優れています。 Gemini 2.5 Flash では、 Thinking Budget （思考予算）の調整が可能です。Thinking Budget は自動的に調整され、単純なプロンプトであれば迅速に回答を生成できるよう調整されます。また、Thinking Budget を明示的に指定することもでき、ユースケースに応じて、思考に使用するトークン数を調整することができます。ゼロに設定することで、長考を防ぎ、クイックに回答させることも可能です。 Thinking Budget は、Gemini 2.5 Pro にも、まもなく導入（Coming soon）されるとしています。 参考 : What’s new with Gemini 2.5（Google Cloud Next '25セッションレポート） - G-gen Tech Blog Thinking Budget の導入により、精度、コスト、回答速度の調整が可能になったのが、Gemini 2.5 の特徴であるといえます。 Gemini 2.5 Flash への API リクエストは、Next '25 での発表当初は利用可能になっていませんでしたが、2025年4月18日（日本時間）に、Vertex AI と Google AI Studio で利用可能になりました。 参考 : Start building with Gemini 2.5 Flash Vertex AI Model Optimizer Vertex AI Model Optimizer とは Vertex AI Model Optimizer は、事前に精度とコストのバランスを設定しておくと、プロンプトに応じて Gemini Pro または Flash が自動的に選択される機能です。 現在では、Gemini 2.0 Flash と Gemini 2.5 Pro がサポートされています。 参考 : Vertex AI Model Optimizer 使用方法 以下に引用しているソースコードは、公式の quickstart Colab notebook からの引用です。 参考 : Colab - intro_model_optimizer.ipynb PRIORITIZE_COST （コスト優先）、 BALANCED （バランス）、 PRIORITIZE_QUALITY （品質優先）のいずれかを事前に設定します。 feature_selection_preference_map = { "PRIORITIZE_COST" : GenerationConfig.ModelConfig.FeatureSelectionPreference.PRIORITIZE_COST, "BALANCED" : GenerationConfig.ModelConfig.FeatureSelectionPreference.BALANCED, "PRIORITIZE_QUALITY" : GenerationConfig.ModelConfig.FeatureSelectionPreference.PRIORITIZE_QUALITY, } preference = "BALANCED" # @param ['PRIORITIZE_COST', 'BALANCED', 'PRIORITIZE_QUALITY'] また、モデルとして Model Optimizer を選択します。 model = GenerativeModel( "model-optimizer-exp-04-09" , system_instruction=[system_instruction] ) このように設定するだけで、プロンプトの複雑さに応じて、自動的に Pro または Flash モデルが選択されます。 Vertex AI Global Endpoint Vertex AI Global Endpoint は、複数リージョンの Gemini API にリクエストをルーティングすることで、トラフィックのピーク時やリージョン障害時でも、生成 AI アプリケーションの可用性を維持できる仕組みです。執筆時現在で、すでにプレビュー版が利用可能になっています。 参考 : Deployments - Global endpoint 従来はリージョンごとのエンドポイントだけが提供されており、タイミングによっては Google 側のリソースが枯渇し、429 エラー（Resource exhausted）が発生しました。 参考 : Gemini APIへのリクエストでエラーコード429「Resource exhausted, please try again later.」 - G-gen Tech Blog グローバルエンドポイントを利用することで、リソースが利用可能なリージョンが自動的に使用されます。 以下の API エンドポイントを利用することで、リクエストが自動的に利用可能なリージョンにルーティングされます。 https://aiplatform.googleapis.com/v1/projects/test-project/locations/global/publishers/google/models/gemini-2.0-flash-001:generateContent Gen AI SDK では、クライアント生成時に location を global に設定します。 client = genai.Client( vertexai= True , project= 'your-project-id' , location= 'global' ) 推論リクエストではグローバルエンドポイントが利用できますが、チューニング、バッチ推論などには対応していないほか、コンテキストキャッシュなどにも対応していない点に注意してください。 参考 : Deployments - Limitations 関連記事 Google Cloud Next '25 の関連記事は、以下の記事一覧をご参照ください。開催期間中は、記事が随時公開されます。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。当記事では、Google Cloud Next '25 in Las Vegas の、2日目のキーノートに関する速報レポートをお届けします。 Google Cloud Next '25 in Las Vegas 概要 Google AI Studio の新しい UI Agent Development Kit（ADK） ADK の使い方 マルチエージェントとデバッグ Agent2Agent Protocol（A2A） 開発環境 IDE との統合 サードパーティモデルの利用 Android Studio Firebase Studio スポーツと Gemini Data Agents Gemini Code Assist エージェント Sphere と Google Cloud 関連記事 Google Cloud Next '25 in Las Vegas Google Cloud の旗艦イベントである Google Cloud Next。2025年の Google Cloud Next は、2025年4月9日(水)から11日(金)までの3日間です。 例年、2日目の Developer Keynote（開発者向け基調講演）では、Google が開発者向けに強調したい新機能の発表等が行われます。本投稿では、Google Cloud Next '25 の第2日目の Developer Keynote で行われた発表を紹介します。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '25 に関連する記事を発信します。 Google Cloud Next '25 カテゴリ をご参照ください。 概要 Google Cloud Next の2日目の Developer Keynoteでは、Google Cloud の AI や AI エージェントに関連する新機能の発表や、開発者がどのように AI を活用して開発を効率化できるかについて紹介されました。 参考 : Next 25 developer keynote: From prompt, to agent, to work, to fun 参考 : YouTube - Developer Keynote: You can just build things Google AI Studio の新しい UI Gemini 2.5 Pro や Gemini 2.5 Flash のデモの実演の中で、個人開発者向けの AI 開発プラットフォームである Google AI Studio の新しい UI が紹介されました。 洗練された新しい Web UI では、モデルの詳細な仕様や、プロンプト、思考モデルの出力、モデルの最終出力がわかりやすく表示されました。 マルチモーダルな入力と出力が可能であることを示すために、キッチンのリノベーションをテーマに、今のキッチンの写真とリノベーションの計画のテキストを入力すると、改修の計画と完成後のイメージ写真が出力されました。材料費や法的規制などは、Google 検索からのグラウンディングで最新の情報が取得されます。 参考 : Google AI Studio YouTube 動画より引用 Agent Development Kit（ADK） ADK の使い方 Agent Development Kit （ADK）は、今回の Next で新たに発表された、AI エージェント開発のためのフレームワークです。 参考 : Vertex AI offers new ways to build and manage multi-agent systems 参考 : Agent Development Kit Python 向けの ADK を用いたデモでは、簡単なソースコードでエージェントを定義しました。インストラクションプロンプト、ツール、モデルを指定するだけです。 YouTube 動画より引用 ADK は MCP（Model Context Protocol）をサポートしており、デモでは、ツールの定義内でリモートの MCP サーバーを指定しました。 YouTube 動画より引用 ターミナル上で adk web コマンドを実行すると、ローカル環境でウェブサーバーが起動し、UI からの指示で PDF を生成するアプリケーションが起動しました。非常に簡単な操作で、AI エージェントを開発する実演となりました。 YouTube 動画より引用 YouTube 動画より引用 マルチエージェントとデバッグ 続けて、ADK によるマルチエージェント（複数の子エージェントを持つエージェント）の定義の方法も紹介されました。 YouTube 動画より引用 エージェントがうまく動かない場合、Cloud Logging でエラーログを参照します。Cloud Logging の新機能として、エラーログを Gemini が解析し、ソースコードの修正案を提示します（ Investigation ）。 YouTube 動画より引用 YouTube 動画より引用 デモでは、ADK で開発したマルチエージェントが、Google Agentspace から使用できることも示されました。 YouTube 動画より引用 Agent2Agent Protocol（A2A） Agent2Agent Protocol （A2A）についても紹介されました。A2A は、今回 Google から発表された、エージェント間の通信方法を定義したオープンプロトコルです。 参考 : Vertex AI offers new ways to build and manage multi-agent systems 参考 : Announcing the Agent2Agent Protocol (A2A) A2A は MCP とも併用されます。エージェント間の通信には A2A を利用する一方で、MCP は tools やデータ（Prompts や Resources などを含む MCP サーバーを示すと思われる）への接続等、より汎用的な用途で利用するイメージ図が投影されました。 YouTube 動画より引用 開発環境 IDE との統合 Gemini によるコーディング補助が、Cursor、VS Code、Windsurf などさまざまな IDE で得られることが示されました。デモでは Windsurf を使って、Java のコードを Gemini がリアルタイムに生成したり、指示に基づいて修正する様子が示されました。 YouTube 動画より引用 サードパーティモデルの利用 続いて、Vertex AI Model Garden（生成 AI モデルのマーケットプレイス）により、Claude や Llama などサードパーティのモデルを Vertex AI API 経由で利用できることが示されました。デモでは、Claude モデルを Model Garden 経由でデプロイし、Google Cloud プロジェクト ID を指定して、ソースコードから呼び出す方法が紹介されました。 YouTube 動画より引用 YouTube 動画より引用 Android Studio Android Studio が新発表されました。Android アプリ開発者向けのツールであり、コーディングやビルド、テストなど開発ライフサイクル全体を AI が支援します。 参考 : Gemini in Android Studio for businesses: Develop with confidence, powered by AI YouTube 動画より引用 Firebase Studio Firebase Studio は、モバイルアプリ向けのバックエンドプラットフォーム Firebase の開発者向けツールです。 Firebase Studio は、開発のライフサイクル全体で AI が開発者を支援します。自然言語の指示によりプロトタイプアプリを生成したり、デバッグ、テスト、リファクタリング、コードの説明、ドキュメント作成などを行うことができます。Gemini Code Assist エージェントとの連携も可能です。 参考 : Introducing Firebase Studio and agentic developer tools to build with Gemini YouTube 動画より引用 スポーツと Gemini Google と Major League Baseball（MLB）が開催したハッカソンの優勝者が、動画からピッチャーの投球フォームを分析する仕組みを、Gemini を使って簡単に実装した事例が紹介されました。 YouTube 動画より引用 その他にも、スノーボードのスーパーパイプ競技でコメンテーターとして Gemini が導入された事例等も紹介され、AI が審判やコーチとして活用される可能性を示唆しました。 Data Agents BigQuery と AI の統合も、より進歩したものになりました。 参考 : What's new with BigQuery — the autonomous data-to-AI platform 参考 : What's new for Data Analytics in the AI driven, autonomous and agentic era 参考 : Introducing BigQuery unified governance: universal, intelligent, and open 参考 : BigQueryの新発表を解説（Google Cloud Next '25速報） - G-gen Tech Blog BigQuery Studio（BigQuery の Web UI）のノートブック上で、BigQuery Dataframes を用いてデータフレーム上にロードしたデータを容易にグラフ化したり、 Data Science Agent と表示されたチャット UI 上に自然言語で指示することで、コードが自動生成され、データの可視化を短時間で行う様子がデモされました。 YouTube 動画より引用 さらに、ノートブック上の必要なセルを選択して Create Data App ボタンを押下すると、売上フォーキャストを自動算出するアプリが簡単に生成され、デプロイされました。 YouTube 動画より引用 YouTube 動画より引用 YouTube 動画より引用 Gemini Code Assist エージェント Gemini Code Assist エージェント による開発者体験の向上がデモされました。 参考 : Delivering an application-centric, AI-powered cloud for developers and operators カンバンボード （Kanban Board）は、Gemini Code Assist の新しい機能です。 YouTube 動画より引用 Java 8 から Java 21 への移行計画を記載した Google ドキュメント上で、Gemini Code Assist に「この計画に基づいて移行を実施して」と指示すると、カンバンボードにタスクが追加され、バックエンドでタスクが動作します。 YouTube 動画より引用 YouTube 動画より引用 Gemini に対して Google チャット上でメンションすると、Gemini Code Assist がそれに回答し、タスクを実行します。 YouTube 動画より引用 バグトラッカーや Issue に、あるいはプルリクエストのレビュワーとして、Gemini Code Assist をアサインすることもできます。 YouTube 動画より引用 YouTube 動画より引用 YouTube 動画より引用 カンバンボード上で Gemini にプロトタイプアプリの開発を指示し、ボード上から直接プレビューすることもできます。 YouTube 動画より引用 このように、Gemini Code Assist で開発者体験がまったく異なるものになることが示されました。 YouTube 動画より引用 Sphere と Google Cloud ラスベガスの球体型エンターテインメント施設 Sphere は、公演「オズの魔法使い」で Google の AI 技術を使っています。 1939年の映画「オズの魔法使い」を現代の Sphere に蘇らせるために、高解像度化やシーンの生成など、没入感のある映像づくりに AI を活用しています。 関連記事 Google Cloud Next '25 の関連記事は、以下の記事一覧をご参照ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の山崎です。本記事は Google Cloud Next '25 in Las Vegas の2日目に行われた ライトニングトークセッション「 Gemini's in-context learning for Data Analytics in 15 minutes 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 ビジネスインテリジェンスの主要な問題点 3つのカテゴリごとの課題 別の視点での課題の提示 課題の解決に向けたアプローチ 「自然言語から SQL へ」とその限界 Gemini がもたらす解決策 デモ 関連記事 セッションの概要 本セッションでは、 ビジネスインテリジェンスの問題と、Gemini がその解決にどう役立つかについて、デモンストレーションを用いた解説が行われました。 ビジネスインテリジェンスの主要な問題点 3つのカテゴリごとの課題 ビジネスインテリジェンスの主要な問題点として、以下の3つの領域ごとに課題があるとしました。 データ品質 AI だけでは解決できない根本的な問題であり、良質なデータを確保するために継続的に注視することが必要。 データガバナンス、パフォーマンス、スケーラビリティ Google Cloud の技術で支援可能な領域だが、データガバナンスは軽視される傾向にある。 スキルギャップ、ユーザーの利用促進、データの複雑さ、モデリング 特に 「ユーザーの利用促進」 が重要な課題となる。多くの BI システムは、ユーザーが日常的に使う自然な言葉で対話できず、専門知識がないと使いこなすのが難しいため、Gemini が貢献できる領域となる。 別の視点での課題の提示 この問題を別の角度から捉え、「役割間のギャップ」を図示しました。 一方には、 ビジネスの深い知識を持つがデータの詳細を知らない「意思決定者」 がおり、もう一方には、 データの構造やモデルに精通しているがビジネスの意思決定には疎い「データエンジニア」 がいます。 その中間に「ビジネスアナリスト」や「データアナリスト」が存在します。理想は、ビジネスとデータの両方を深く理解する「ユニコーン」人材ですが、現実にはそのような人材は稀であり、このギャップを埋めることが課題となります。 課題の解決に向けたアプローチ 「自然言語から SQL へ」とその限界 このギャップを埋める試みとして、 「自然言語から SQL へ」（NL to SQL） というアプローチが存在します。 しかし、この手法には多くの問題点があるとしました。 巨大なスキーマ Salesforce や SAP のようなエンタープライズシステムのデータベーススキーマは膨大で、中程度のコンテキストまでしか扱えない AI モデルでは扱いきることができず、ベクトル化が必要となる。 関連テーブルの特定が困難 複数のテーブルから情報を取得する場合、ベクトルベースの検索ではどのテーブルを組み合わせればよいかを正確に見つけることが難しい。 SQL 生成の複雑さ 複雑な SQL クエリは、より広範囲の文脈を理解する能力が必要となる。中程度のコンテキストまでしか扱えない AI モデルではクエリ間の依存関係を見失ってしまう。 ビジネス用語の解釈 ビジネスユーザーの質問は、単なる SQL の言い換えとはならない。 例えば、「トップ5顧客は誰か？」という単純な質問でも、「トップ顧客」の定義（売上、利益、顧客生涯価値など）は企業ごとに異なり、これをデータモデルにマッピングするには、思考の連鎖とビジネス用語の理解が不可欠となる。 Gemini がもたらす解決策 Gemini は以下の特徴により、従来の問題の解決にあたって有用であるとしました。 長大なコンテキスト処理能力 長大なコンテキスト処理能力を有しており、膨大な情報の中から特定の情報を正確に見つけ出す能力が優れている。 文脈内学習 与えられた情報からパターンやルールを学習する能力を持っており、特定企業のビジネスルールやデータモデリングの慣習を与えることで、より適切な SQL 生成や分析を行うことができる。 デモ Gemini 2.5 Pro と Agent Development Kit を用いて構築されたアプリケーションのデモが行われました。 エージェントの構成は以下としました。 ルートエージェント 全体を統括し、他のエージェントに指示を出す。 ビジネスアナリスト 質問の意図を解釈し、ビジネスロジックを明確にする。 データエンジニア ビジネスアナリストの定義とデータスキーマに基づき、SQL クエリを作成する。 BI エンジニア 生成された SQL を実行し、結果を可視化する。 「私たちの最良のリードソースは何か？」という問いに対して、各エージェントが相互に連携を行い、最終的に1つのグラフが表示されました。 関連記事 blog.g-gen.co.jp 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 12 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の奥田です。本記事は Google Cloud Next '25 in Las Vegas の1日目に行われたブレイクアウトセッション「 Accelerate your software development lifecycle with agents 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 ミッションと課題 ミッション アプローチ 仕様書を元に、完全ゼロから新しいアプリケーションを作成するデモ 概要 関連記事 セッションの概要 本セッションでは、 主に1日目のキーノートで発表された「 Gemini Code Assist Agents 」が紹介されました。 ソフトウェア開発ライフサイクル（SDLC）のあらゆる段階において、開発者の生産性をいかに向上させるかについてのセッションとなりました。 Gemini Code Assist Agents は Private Preview 中のサービスですが、セッション後半には Waitlist への登録を案内されました。 参考 : Gemini Code Assist Agents（Google Cloud Next '25 速報レポート - キーノート（1日目） ミッションと課題 ミッション ソフトウェア開発ライフサイクル全体にわたって生産性を向上させ、労力を削減することで開発者を支援します。 アプローチ 「 Gemini Code Assist Agents 」を利用します。 Gemini Code Assist Agents とはソフトウェア開発の専門家チームのように機能する、AI エージェントの集合体です。 「エージェント」という用語は進化しました。 かつての 「エージェント」が意味したものは、以下のようなものでした。 API 呼び出しのセット 分類（Classification） 特徴抽出（Feature Extraction） 関数呼び出し（Function Calling） 「エージェント」が 進化して意味するようになったもの は、以下のとおりです。 ツールの使用（Tool usage） タスクの分解（Task Decomposition） 漸進的な洗練（Progressive refinement） 自己省察（Self Reflection） また、 エージェントのアプローチ も進化しました。 最初は、 API から始まりました。その後、日常的に見られる特定の問題を解決する静的エージェントに進化を遂げます。 次に、動的エージェントです。これは、わずかに広範となり、曖昧な問題を解決できます。 そして、さらに斬新な問題にも対応できる、 マルチ AI エージェント へと進化しました。 最後に、SDLC 全体への AI 導入の道のり について紹介されました。 2025年は以下となります。 AI が日常業務の推進力になる コード実装への RAG（検索拡張生成）の試験導入 SDLC 全体におけるエージェントワークフローの実験 仕様書を元に、完全ゼロから新しいアプリケーションを作成するデモ 概要 Gemini Cloud Assist Agents の Google Docs Agents から仕様書を呼び出します。 Code Assist Agents を呼び出し、ドキュメントをベースに製品仕様を読み、実装する様に指示します。 Kanban Board が表示され、 エージェントによる実装の過程 が表示されます。 ソースコードが実装された後、 どの部分が生成されたのかが確認できます。 関連記事 blog.g-gen.co.jp Risa (記事一覧) クラウドソリューション部クラウドデベロッパー課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資格保有。日々修行中です！ Follow @risa_hochiminh

G-gen の道下です。本記事は Google Cloud Next '25 in Las Vegas の 1日目に行われたブレイクアウトセッション「 Mainframe modernization with AI and the cloud: Customer stories 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Isybank の事例 レイテンシ（遅延） トランザクション管理 Ford Credit の事例 ツールを使用した移行 関連記事 セッションの概要 本セッションでは、企業がメインフレームからモダナイズする際に直面した、レイテンシ（遅延）やトランザクション管理といった課題への対応や、ツールを使用した移行事例が紹介されました。 Isybank の事例 Intesa Sanpaolo グループのデジタルバンク Isybank 立ち上げに伴い、メインフレームからモダナイズした事例が話されました。 レイテンシ（遅延） モダナイズを行うことで発生するレイテンシによって、どの程度がシステム影響をうけるかを確認するテストを行った内容が紹介されました。 構成は、稼働中の既存システムからテスト実施システムを選定し、モダナイズ済みの環境と並行稼働している様子を表しています。 テスト結果からは、レイテンシが大きな問題にはならないことが確認できたようです。 トランザクション管理 システム間の整合性確保のため、トランザクションキーを使ったべき等性のある処理を実装したことが紹介されました。 Ford Credit の事例 Ford Credit 社の事例は、25年前に構築されたデータウェアハウスを、12ヶ月以内に Google Cloud へ移行するというものでした。データ整合性を損なうことなく、データ損失を引き起こさないことが重視されていました。 ツールを使用した移行 同社は、 Mainframe Connector を活用し、複雑さを解消しつつ、自動化された方法で移行を進めることを目指しました。 参考 : Mainframe Connector 同社は当初、再利用可能な変換パターンを構築して、大規模な自動変換を実装することや、ギャップを埋めるためのカスタム開発が必要と想定していました。実際には、Mainframe Connector を選択したことで、多くの工数が節減できました。 関連記事 blog.g-gen.co.jp 道下 千晃 (記事一覧) クラウドソリューション部 大阪府在住。Google Cloud Certification 全11冠 Google Cloud にはいろいろなサービス、プロダクトがあって楽しいですね。 趣味はテニス、オンラインゲーム（世界を救ったり、魚を釣ったり、武器防具を作ったり） Follow @Chiaki_Michi

G-gen の山崎です。当記事は Google Cloud Next '25 in Las Vegas の1日目に行われたブレイクアウトセッション「 What’s new with Gemini 2.5 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Gemini 2.5 Pro の紹介 Gemini 2.5 Pro のパフォーマンス Gemini 2.5 Pro の強み Gemini 2.5 Flash の紹介 Thinking Budget Shopify による Gemini Live API の活用事例の紹介 Shopify の課題 Gemini Live API での解決 デモ 関連記事 セッションの概要 本セッションでは、Vertex AI のプロダクトマネージャーである Jason Gelman 氏、Google DeepMind のプロダクトマネージャーである Tulsee Doshi 氏、Shopify の Vice President Product の David Wurtz 氏が登壇し、プレビュー公開された Gemini 2.5 Pro 、及び近日公開予定の Gemini 2.5 Flash についての紹介と、Shopify による Gemini Live API の活用事例に関するデモンストレーションが行われました。 Gemini 2.5 Pro の紹介 Gemini 2.5 Pro のパフォーマンス まず、Gemini 2.5 Pro の性能について、リーダーボード（性能ランキング表）を使った説明がありました。 Gemini 2.5 Pro は、学術的なテストで高い性能を示していると評価されているだけでなく、実際の利用場面に近い評価方法でも優れている点が強調されました。 具体的には、どちらの AI の出力か分からない状態で人間が比較を行った結果、Gemini 2.5 Pro の方が「より良い」と選ばれることが多かったとし、 研究上の性能だけでなく、実際の使い勝手においても高く評価されている結果 に、大変満足しているとしました。 Gemini 2.5 Pro の強み Gemini 2.5 Pro の強みとして以下の内容が紹介されました。 高度なコーディング能力 複雑なコードの生成、理解、デバッグ支援などにおいて高い性能を発揮し、開発者の生産性向上に貢献。 長大なコンテキスト処理能力 現在提供中のプレビュー版では100万トークンに対応。一般提供（GA）時には最大200万トークンへの拡張を予定しており、大量の情報を一度に処理・分析が可能。 優れた処理効率（スループット） 高速な処理を実現しながら高品質な応答を維持しており、コストパフォーマンスに優れる。 豊富な開発エコシステムとの連携 Agent Development Kit (ADK) のような開発ツールとの連携を強化。これにより、開発者はモデルの能力を最大限に活用したアプリケーションの構築が可能。 Gemini 2.5 Flash の紹介 Thinking Budget 近日公開予定の Gemini 2.5 Flash モデルは Thinking Budget を指定することが可能としました（Gemini 2.5 Pro は発表時点では未実装）。 Thinking Budget とは、「最大 X 個のトークンを使って思考を行いたい」と指定することができる機能のことで、これにより ユースケースに応じて思考に使用するトークン数を調整 することが可能となります。 Shopify による Gemini Live API の活用事例の紹介 Shopify の課題 e コマースプラットフォームである Shopify はあらゆる形態、あらゆる規模の起業家を支援しています。 しかし、事業者（Merchants）が起業家として成功するためには、何百ものタスクをこなす必要があります。また、事業者がそれらのタスクにすべて精通しているとも限りません。 Shopify としては、起業への参入障壁を下げ、より多くの人々が起業をキャリアとして選択できるようにしたいと考えています。 あらゆる課題を解決する方法として、人間のサポートアドバイザーが考えられますが、世界中に何百万人もの事業者がいる Shopify の規模を考えると、それはスケールしません。 Gemini Live API での解決 Shopify は、この課題に対して、 Gemini Live API を用いたカスタマーサポートを導入し、常時稼働し、忍耐強く、完璧な記憶力と無限の知識を持ったサポートを提供することができたとしています。 Gemini Live API とは、テキスト、音声、ビデオを用いて、Gemini と人間のような音声会話を可能とする機能となります。 参考 : Live API デモ David 氏が Cloudflare で登録したドメイン名を Shopify ストアで使用する方法を Shopify の AI アシスタントに問い合わせるというデモが実施されました。 David 氏が画面共有を行いながら、AI アシスタントと音声でのリアルタイムなやり取りが行われ、AI アシスタントが Shopify への対応方法の提示だけでなく、Cloudflare への対応方法の提示がなされ、David 氏の不明点が無事解消されていました。 関連記事 以下の記事では、Gemini 2.5 Pro/Flash、Vertex AI Model Optimizer、Vertex AI Global Endpoint を、公式発表に基づいて解説しています。 blog.g-gen.co.jp 以下のリンクから、G-gen による Google Cloud Next '25 の関連記事の一覧が確認できます。 blog.g-gen.co.jp 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 12 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の奥田です。当記事は、Google Cloud Next '25 in Las Vegas の1日目に行われたブレイクアウトセッション「 Google Workspace and Google Agentspace: Break the information silos with AI 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 問題提起 概要 解決策とサービスの紹介 Google の強み Google Workspace Google Agentspace レポート作成とメール業務の効率化のデモ シナリオ デモ内容 問い合わせ対応の自動化デモ シナリオ デモ内容 補足 関連記事 セッションの概要 本セッションでは、Google Workspace と Agentspace を連携させることで、情報検索や定型業務を支援し、組織全体の生産性向上につなげる事例がデモを通じて紹介されました。 問題提起 概要 社内の他部門、他部署からアクセスできないデータが存在する等といったデータがサイロ化していることから、多くの従業員が「 Reduced agility（俊敏性の低下） 」という課題に直面しています。 その結果、以下の課題が発生します。 コミュニケーションの分断 : バラバラのツールがコミュニケーションを分断し、職場のコラボレーションにおける重大な破綻につながる。 俊敏性の低下と組織の分断 : サイロ化したアプリケーションは、俊敏性の低下、プロセスの分断、そして組織全体の連携不足につながります。 プライバシーとデータ漏洩 : 適切なアクセス制御の実施なしに、企業全体でプライバシーとデータ漏洩のリスクが生じる。 AIツールの拡散と断片化 : 会社全体でAIツール（アシスタント、AIプラットフォーム、エージェントエクスペリエンス）の拡散と断片化が進む。 解決策とサービスの紹介 Google の強み Google が20年以上培ってきた研究の成果を元にしていること、エンタープライズ対応を前提とした基盤、幅広い AI エコシステムの提供により最適な AI を提供できることが紹介されました。 Google Workspace Google Workspace を使うことで、Gemini が組み込まれ、すべての従業員が生成 AI を利用できるようになります。 スプレッドシートの情報を使ってスライドを作成する、ドキュメントやメールのコレクションを使って要約を作成するといったことを通じてユーザーに コラボレーションの文化を推進 します。その結果、ある顧客は Google Workspace に移行後、 コラボレーションが30%向上した と報告しています。 Google Agentspace Google Agentspace を使うことで、Google がこれまで培ってきた検索ナレッジを活かし、組織全体の情報（自社データ、サードパーティデータ、Google検索）から情報を見つけ出すことができます。 参考 : Google Agentspaceを徹底解説！ レポート作成とメール業務の効率化のデモ 以下のシナリオでのデモが実施されました。 シナリオ アカウントマネージャーが上司から急なレポート作成依頼を受けたとします。通常であれば、CRM（顧客管理システム）にログインし、データを抽出し、レポート形式にまとめ、メールを作成するという一連の作業に数時間を要することもあります。 デモ内容 Google Workspace 内から Agentspace のエージェントに「 Salesforce から「オープンな商談」となっているものからデータを抽出し、指定項目（説明、クローズ予定日、ステージ、次のステップ）を含むレポートを作成して 」と指示します。 Agentspace は Salesforce に接続し、必要な情報を収集・整理し、レポートの下書きを作成します。 さらに、 「このレポートを添付したメールの下書きを作成して」 と指示すれば、エージェントが Gmail と連携し、メールの下書きまで準備します。 問い合わせ対応の自動化デモ シナリオ 顧客からの定型的な問い合わせ（例 : 注文状況の確認）メールへの対応は、数が多くなると担当者の大きな負担となります。その対策のため、自動化を実施しました。 デモ内容 本日のキーノートで発表された Google Workspace の自動化ツールである「 Workspace Flow 」を利用してワークフローを構築できることが紹介されました。 デモでは、Agentspace をと連携するための Google Workspace アドオンが使われました。Agentspace は SAP と接続されています。Agentspace に状況を確認させます。 取得した回答を基に、Gemini in Workspace を利用して返信メールの文章を作成させます。作成された下書きを担当者が確認し、ワンクリックで送信できる様になります。これにより、 定型的な問い合わせ対応の多くを自動化 し、担当者は より複雑な問題や付加価値の高い業務に集中できる ようになります。 参考 : Google Workspace Flows（Google Cloud Next '25 速報レポート - キーノート（1日目）） 補足 登壇者に直接聞いた所、 Agentspace が組み込まれた Google Workspace アドオンは、今回のデモのために登壇者が開発したとのことです。今の時点では非公式ですが、今後、ソースコードのリリースを計画しているとのことです。 参考 : Google Workspace アドオン 関連記事 blog.g-gen.co.jp Risa (記事一覧) クラウドソリューション部クラウドデベロッパー課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資格保有。日々修行中です！ Follow @risa_hochiminh

G-gen の佐々木です。当記事では GKE Inference Quickstart を使用し、Google Kubernetes Engine（GKE）で Google Cloud のベストプラクティスに沿った生成 AI ワークロードのデプロイを試してみます。 GKE Inference Quickstart とは 事前準備 コマンド実行の準備 Hugging Face アクセストークンの準備 モデルの探索 マニフェストの生成とデプロイ 推論リクエストの送信 GKE Inference Quickstart とは GKE Inference Quickstart （以下、Inference Quickstart）は、Google Kubernetes Engine（GKE）で利用できる生成 AI 機能の1つで、ユーザーが生成 AI モデルのコンテナ化やマニフェストファイルの記述などを行うことなく、Google のベンチマークに基づいた最適化された構成で推論サーバーをデプロイをすることができます。 Google Cloud によって事前構成されたレシピにより、手動での構成の調整やテストを行うことなく、最低限のセットアップで必要な Kubernetes リソースを素早く簡単に展開できます。 Inference Quickstart は Autopilot モードの GKE クラスタ、Standard モードの GKE クラスタの両方で利用することができます。 機能の詳細については以下のドキュメントもご一読ください。 参考 : About model inference on GKE 参考 : Run best practice inference with GKE Inference Quickstart recipes なお当機能は、Google Cloud の旗艦イベントである Google Cloud Next '25 で発表されたものです。 参考 : Kubernetes, your AI superpower: How Google Kubernetes Engine powers AI innovation G-gen Tech Blog では、Google Cloud Next '25 のセッションレポートなどを随時公開しています。 blog.g-gen.co.jp 事前準備 コマンド実行の準備 Inference Quickstart を利用するためには、プロジェクトで以下の API を有効化する必要があります。 # API 有効化 $ gcloud services enable gkerecommender.googleapis.com また、以下のコマンドで Application Default Credentials（ADC）の設定を行ってください。 # ADC の設定 $ gcloud auth application-default login 参考 : How Application Default Credentials works Hugging Face アクセストークンの準備 当記事では gemma-2-27b-it モデルを使用していきます。 モデルの利用に Hugging Face アクセストークンが必要となるため、トークンの情報を格納した Secret リソースをクラスタ上に作成しておきます。 # シークレットの作成 kubectl create secret generic hf-secret \ --from-literal = hf_api_token = < Hugging Face アクセストークン > また、gemma-2-27b-it モデルを使用するためには Hugging Face から利用申請をする必要があるため、モデルのページから申請を行ってください。 参考 : User access tokens | Hugging Face 参考 : google/gemma-2-27b-it | Hugging Face モデルの探索 gcloud alpha container ai recommender コマンドを使用することで、利用するモデルサーバー、サーバーバージョン、アクセラレータを探索します。 models list で利用できるモデルを表示します。 # サポートされているモデルの表示 $ gcloud alpha container ai recommender models list Supported models: - deepseek-ai/DeepSeek-R1-Distill-Qwen-7B - google/gemma-2-27b-it - google/gemma-2-2b-it - google/gemma-3-27b-it - meta-llama/Llama-3.2-1B-Instruct - meta-llama/Llama-3.3-70B-Instruct - meta-llama/Llama-4-Scout-17B-16E-Instruct - meta-llama/Meta-Llama-3-8B - mistralai/Mixtral-8x22B-Instruct-v0. 1 - mistralai/Mixtral-8x7B-Instruct-v0. 1 model-servers list で、指定したモデルで使用できるモデルサーバーを表示します。 # モデルがサポートされているモデルサーバーを表示 $ gcloud alpha container ai recommender model-servers list \ --model = google/gemma-2-27b-it Supported model servers: - vllm model-server-versions list で、指定したモデルとモデルサーバーの組み合わせで利用できるサーバーバージョンを表示します。 # サーバーバージョンの確認 $ gcloud alpha container ai recommender model-server-versions list \ --model = google/gemma-2-27b-it \ --model-server = vllm Supported model server versions: - v0. 7 . 2 accelerators list で、モデルが使用できるアクセラレータを表示します。ここでは1秒あたりの出力トークン数（output tokens per second）などのメトリックが確認できます。 # アクセラレータの表示 $ gcloud alpha container ai recommender accelerators list \ --model = google/gemma-2-27b-it \ --model-server-version = v0. 7 . 2 Supported accelerators: accelerator | model | model server | model server version | accelerator count | output tokens per second | ntpot ms ------------------|-----------------------|--------------|----------------------|-------------------|--------------------------|--------- nvidia-h100-80gb | google/gemma-2-27b-it | vllm | v0. 7 . 2 | 1 | 2050 | 67 nvidia-tesla-a100 | google/gemma-2-27b-it | vllm | v0. 7 . 2 | 2 | 1243 | 70 nvidia-l4 | google/gemma-2-27b-it | vllm | v0. 7 . 2 | 4 | 425 | 1085 マニフェストの生成とデプロイ gcloud alpha container ai recommender manifests create コマンドを使用して、指定したモデルで Kubernetes ワークロードを展開することができる、推奨構成のマニフェストファイルを生成できます。 --output-path でマニフェストファイルの出力先を指定して、gemma-2-27b-it モデルを使用するワークロードのマニフェストファイルを生成します。 # マニフェストを生成する $ gcloud alpha container ai recommender manifests create \ --model = google/gemma-2-27b-it \ --model-server = vllm \ --model-server-version = v0. 7 . 2 \ --accelerator-type = nvidia-l4 \ --target-ntpot-milliseconds = 200 \ --output = manifest \ --output-path ./manifests.yaml マニフェストの一部パラメータはコマンドのオプションで調整することができます。詳細はコマンドリファレンスを参照してください。 参考 : gcloud alpha container ai recommender manifests create 生成されたマニフェストファイルは以下のようになっています。 # 生成されたマニフェスト apiVersion : apps/v1 kind : Deployment metadata : annotations : aire.gke.io/generated : "true" aire.gke.io/inference-server : vllm recommender.ai.gke.io/generated : "true" recommender.ai.gke.io/inference-server : vllm creationTimestamp : null labels : app : gemma2-27b-it-vllm-inference-server recommender.ai.gke.io/generated : "true" recommender.ai.gke.io/inference-server : vllm name : gemma2-27b-it-vllm-deployment namespace : default spec : replicas : 1 selector : matchLabels : app : gemma2-27b-it-vllm-inference-server strategy : {} template : metadata : annotations : recommender.ai.gke.io/generated : "true" recommender.ai.gke.io/inference-server : vllm creationTimestamp : null labels : ai.gke.io/inference-server : vllm ai.gke.io/model : gemma2-27b-it app : gemma2-27b-it-vllm-inference-server examples.ai.gke.io/source : blueprints recommender.ai.gke.io/generated : "true" recommender.ai.gke.io/inference-server : vllm spec : containers : - args : - --model=$(MODEL_ID) - --disable-log-requests - --tensor-parallel-size=4 - --max-num-seq=512 - --gpu-memory-utilization=0.95 - --num-scheduler-steps=8 command : - python3 - -m - vllm.entrypoints.openai.api_server env : - name : MODEL_ID value : google/gemma-2-27b-it - name : HUGGING_FACE_HUB_TOKEN valueFrom : secretKeyRef : key : hf_api_token name : hf-secret image : vllm/vllm-openai:v0.7.2 name : inference-server ports : - containerPort : 8000 name : metrics readinessProbe : failureThreshold : 6000 httpGet : path : /health port : 8000 periodSeconds : 10 resources : limits : nvidia.com/gpu : "4" requests : nvidia.com/gpu : "4" volumeMounts : - mountPath : /dev/shm name : dshm nodeSelector : cloud.google.com/gke-accelerator : nvidia-l4 volumes : - emptyDir : medium : Memory name : dshm status : {} --- apiVersion : autoscaling/v2 kind : HorizontalPodAutoscaler metadata : annotations : aire.gke.io/generated : "true" recommender.ai.gke.io/generated : "true" creationTimestamp : null labels : app : gemma2-27b-it-vllm-inference-server recommender.ai.gke.io/generated : "true" name : vllm-hpa namespace : default spec : maxReplicas : 10 metrics : - pods : metric : name : prometheus.googleapis.com|vllm:gpu_cache_usage_perc|gauge target : averageValue : 504m type : AverageValue type : Pods minReplicas : 1 scaleTargetRef : apiVersion : apps/v1 kind : Deployment name : gemma2-27b-it-vllm-deployment status : currentMetrics : null desiredReplicas : 0 --- apiVersion : v1 kind : Service metadata : annotations : aire.gke.io/generated : "true" recommender.ai.gke.io/generated : "true" creationTimestamp : null labels : app : gemma2-27b-it-vllm-inference-server recommender.ai.gke.io/generated : "true" name : gemma2-27b-it-vllm-service namespace : default spec : ports : - port : 8000 protocol : TCP targetPort : 8000 selector : app : gemma2-27b-it-vllm-inference-server type : ClusterIP status : loadBalancer : {} --- apiVersion : monitoring.googleapis.com/v1 kind : PodMonitoring metadata : annotations : aire.gke.io/generated : "true" recommender.ai.gke.io/generated : "true" labels : app : gemma2-27b-it-vllm-inference-server recommender.ai.gke.io/generated : "true" name : vllm-podmonitoring namespace : default spec : endpoints : - interval : 15s path : /metrics port : metrics selector : matchLabels : app : gemma2-27b-it-vllm-inference-server targetLabels : metadata : - pod - container - node --- このマニフェストをデプロイするだけで、モデルが推論リクエストを処理するために必要なリソースがすべて作成されます。 GKE クラスタにマニフェストを適用します。 $ kubectl apply -f ./manifests.yaml deployment.apps/gemma2-27b-it-vllm-deployment created horizontalpodautoscaler.autoscaling/vllm-hpa created service/gemma2-27b-it-vllm-service created podmonitoring.monitoring.googleapis.com/vllm-podmonitoring created 推論リクエストの送信 デプロイされたサービスは、以下の形式のエンドポイントで公開されます。 http://<モデル名>-<モデルサーバー名>-service:<ポート>/ エンドポイントにアクセスするために、以下のコマンドでポート転送を設定します。 $ kubectl port-forward service/gemma2-27b-it-vllm-service 8000:8000 Forwarding from 127 . 0 . 0 .1:8000 - > 8000 Forwarding from [ ::1 ] :8000 - > 8000 ポート転送の準備ができたら、curl コマンドでモデルに推論リクエストを送信してみます。 $ curl -X POST http://localhost:8000/v1/completions \ -H " Content-Type: application/json " \ -d ' { "model": "google/gemma-2-27b-it", "prompt": "Google Cloud のサーバーレスコンテナサービスの名前はなんですか？", "max_tokens": 100, "temperature": 0.7 } ' gemma-2-27b-it モデルを使用する推論サーバーから、以下のようにレスポンスが返ってきました。 { " id ": " cmpl-8871ad8cf483442bbf57bff2397958c8 ", " object ": " text_completion ", " created ": 1744225757 , " model ": " google/gemma-2-27b-it ", " choices ": [ { " index ": 0 , " text ": " \n\n 正解は **Cloud Run** です。 \n\n Cloud Run は、サーバーレス環境でコンテナを実行するためのフルマネージドサービスです。コンテナを構築し、デプロイし、スケールアウトする必要がなく、アプリケーションのコードのみを記述してデプロイするだけで、必要に応じて自動的にスケールアウトします。 \n\n Cloud Run についてさらに詳しく知りたい場合は、公式ドキュメントを参照してください: \n\n [https://cloud.google.com/run/docs](https ", " logprobs ": null , " finish_reason ": " length ", " stop_reason ": null , " prompt_logprobs ": null } ] , " usage ": { " prompt_tokens ": 14 , " total_tokens ": 114 , " completion_tokens ": 100 , " prompt_tokens_details ": null } } 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。当記事では、Google Cloud Next '25 in Las Vegas の、1日目のキーノートに関する速報レポートをお届けします。 Google Cloud Next '25 in Las Vegas イベント概要 キーノートの発表 Google が強調したかったこと スンダーによる発表 Cloud Wide Area Network（Cloud WAN） Ironwood（7th gen TPU） Gemini 2.5 Flash AI 特化のインフラ A4/A4X VM、NVIDIA Vera Rubin GPUs Cluster Director ストレージ AI ワークロード向けのストレージ Hyperdisk Exapools Anywhere Cache Rapid Storage AI 推論向けのソフトウェアアップデート GKE Inference Gateway Pathways on Google Cloud vLLM on TPU Gemini on Google Distributed Cloud Gemini for Google Workspace Help me analyze Audio overviews on Docs Google Workspace Flows マルチモーダルな AI モデル Imagen 3 Chirp 3 Lyria Veo 2 Vertex AI での利用 Vertex AI の外部連携 Llama 4 on Vertex AI Vertex AI のサードパーティ連携 Google Maps によるグラウンディング マルチエージェントの開発 Agent Development Kit（ADK） Agent2Agent Protocol（A2A） Google Agentspace Google Agentspace のデモ Agentspace integrated into Chrome Customer Engagement Suite データエージェント データエージェントの実装 BigQuery に関する新発表 Gemini Code Assist Agents Security Agents トリアージ、マルウェア検査 Google Unified Security（GUS） AI Protection 次回の Google Cloud Next 関連記事 Google Cloud Next '25 in Las Vegas イベント概要 Google Cloud の旗艦イベントである Google Cloud Next。2025年の Google Cloud Next は、2025年4月9日(水)から11日(金)までの3日間です。 例年、初日のキーノート（基調講演）では、Google が最も強調したい発表が行われます。本投稿では、Google Cloud Next '25 の第1日目のキーノート（基調講演）で行われた発表から、特に注目すべきものにフォーカスして紹介します。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '25 に関連する記事を発信します。 blog.g-gen.co.jp キーノートの発表 Google Cloud Next の開幕を飾る初日のキーノート（基調講演）では、Google Cloud の AI や AI エージェントに関連する新機能の発表や、顧客事例が紹介されました。 会場で、DJ が流す音楽にあわせて大型スクリーンに映される動画（VJ）は、Google の最新の動画生成 AI モデルである Veo 2 によって生成されたものです。2023年、2024年の Next に引き続き、本年のイベントも、Google による生成 AI へのコミットを強調したものであることがわかります。 冒頭では、Google Cloud の CEO であるトーマス・クリアンの短い挨拶のあと、Google とその親会社の Alphabet の CEO であるスンダー・ピチャイが登壇しました。昨年の Google Cloud Next では、スンダーは動画によるリモート出演でしたが、今回はステージ上に登壇し、観覧者の前に直接姿を表したことが印象的でした。 参考 : Welcome to Next ‘25 参考 : YouTube - Opening Keynote: The new way to cloud Google が強調したかったこと 今回の基調講演では、Google Cloud が「 マルチエージェント のための フルスタックプラットフォーム 」であると強調されました。従来、Google Cloud は特にデータ分析の領域や Google Workspace を始めとするアプリケーションレイヤのサービス提供において、競合と比べた強みがあると考えられていました。しかし、初日のキーノートでスンダー・ピチャイが最初に発表したのは、Cloud WAN という、Google のバックボーンネットワークを企業がクラウド形式で利用可能にするサービスでした。 パブリッククラウドベンダーにとって企業の IT インフラを押さえることは、強力な顧客リテンションのメリットが得られ、重要です。また、新世代の TPU である Ironwood や NVIDIA との強固なパートナーシップが強調されました。基調講演では「AI ワークロードをインフラからアプリまでフルスタックでサポートできるプラットフォームが Google Cloud である」という点が繰り返し述べられました。また先日の Wiz 買収でも見られるように、セキュリティへの強いコミットもアピールされました。 このように、インフラサービス提供とセキュリティが万全であることをアピールし、AI を端緒にして企業インフラを押さえるのが Google の狙いであるとも考えられます。 スンダーによる発表 Alphabet の CEO スンダー・ピチャイが発表した内容は、今回の Google Cloud Next でも、Google が特に強調したい内容であると考えられます。 Cloud Wide Area Network（Cloud WAN） スンダーによって初めに発表されたのは、海底ケーブルを含む、Google のバックボーンネットワークを、Google Cloud ユーザー企業向けに利用可能にする Cloud Wide Area Network （Cloud WAN）です。Google は世界中にネットワークインフラを張り巡らせており、200以上の国と地域に PoP（Points of Presence）を持ちます。 これにより、ネットワークパフォーマンスは40%向上し、TCO（総所有コスト）は40％削減される、としました。 YouTube 動画より引用 詳細は、以下の公式ブログで発表されています。 参考 : Cloud WAN: Connect your global enterprise with a network built for the AI era Cloud WAN は、既存サービスである Cloud Interconnect、Cross-Cloud Interconnect、Network Connectivity Center（NCC）、および新発表の Network Connectivity Center Gateway（ NCC Gateway 。プレビュー開始は第2四半期 = 2025年4月からの3ヶ月間）で構成されます。Cross-Cloud Interconnect により、Google Cloud と他のパブリッククラウド（AWS、Azure、OCI 等）を接続し、Cloud Interconnect により Google Cloud とオンプレミス拠点を接続します。 こうして Google Cloud に接続されたすべてのサイトは、Google Cloud のバックボーンネットワークにより L2 層で相互に接続されるほか、Network Connectivity Center により、L3 層でのルーティングを制御できます。また新発表の NCC Gateway により、Security Service Edge（SSE）が提供され、Broadcom や Palo Alto Networks と統合したセキュリティ層が提供されます。これは、ファイアウォール、ルーティング、DNS 等の横断的な設定を可能にするソリューションであるとみられます。 Google Cloud 公式記事より引用 今回、Cloud WAN を構成する1機能であり、Google Cloud に専用線で接続されたオンプレミス拠点同士が L2 レイヤで相互通信可能になる Cross-Site Interconnect がプレビュー公開されました。アジア地域では、日本がいち早く対応リージョンとなっています。 参考 : Cross-Site Interconnect overview Ironwood（7th gen TPU） 続けてスンダーは、第7世代 TPU である Ironwood を発表しました。TPU（Tensor Processing Unit）とは、Google が開発した、機械学習向けの集積回路です。第6世代の TPU は2024年5月に Google I/O で発表されており、今回発表されたのはその後継モデルとなります。 「ポッドあたり9,000個以上のチップを搭載」「ポッドあたり42.5 exaflops の演算性能」「従来型の29倍の電力効率」により、前世代より10倍のパフォーマンスを発揮し、Gemini 2.5 のような思考モデルに対する拡大する需要に対応できるとしています。 参考 : Introducing Ironwood TPUs and new innovations in AI Hypercomputer YouTube 動画より引用 Gemini 2.5 Flash Gemini 2.5 Flash がまもなく（Coming Soon）利用可能になることも発表されました。 Google Cloud Next に先んじて、2025年3月25日には、思考型モデルである Gemini 2.5 Pro の試験運用版が利用可能になっていました。Gemini 2.5 Flash は、Pro よりも軽量で応答速度に優れたモデルです。利用料金単価も Pro より安価になり、より生成 AI アプリから利用しやすいモデルになります。 Gemini 2.5 Flash では、 Thinking Budget （思考予算）が自動的に調整されるほか、明示的に指定することもできます。これにより柔軟に速度、精度、コストのバランスを調整できます。 Gemini 2.5 Flash は、これまでの Gemini 系モデルと同様に、Google Ai Studio、Vertex AI（Google Cloud）、Gemini アプリという3つのプラットフォームで使用可能になる見込みです。 なお、試験運用版（Experimental）で利用できた Gemini 2.5 Pro の Public Preview 版も発表されました。QPM（Query per minute）が20に緩和され、有償となっています。 参考 : Gemini 2.5 brings enhanced reasoning to enterprise use cases 参考 : Gemini 2.5 Pro YouTube 動画より引用 Gemini に関する技術的な新発表については、以下の記事も参考にしてください。 blog.g-gen.co.jp AI 特化のインフラ A4/A4X VM、NVIDIA Vera Rubin GPUs A4 および A4X マシンタイプ の Compute Engine VM が発表されました。A4/A4X マシンタイプは、それぞれ NVDIA の Blackwell アーキテクチャ GPU である B200、GB200 GPU を搭載したマシンタイプです。 A4/A4X は、大規模な機械学習ワークロードに特化したマシンタイプと考えられます。 A4 マシンタイプは2025年3月17日に発表済みですが、A4X マシンタイプは今回が初めての発表となりました。 参考 : The A4 machine series また、NVIDIA の新世代 GPU である NVIDIA Vera Rubin GPUs が、クラウドプロバイダとして初めて、Google Cloud で提供されることが明らかになりました。 Cluster Director Cluster Director は、大量のアクセラレーターをデプロイし、単一のまとまりとして管理するための機能です。発表時点で、一般公開（Generally Available、以下 GA）とされました。 以下の公式記事では、 Cluster Director for GKE と Cluster Director for Slurm が発表されています。物理インフラ上への VM の展開やスケーリング、モニタリングを統合する機能が紹介されています。 参考 : Introducing Ironwood TPUs and new innovations in AI Hypercomputer ストレージ AI ワークロード向けのストレージ AI ワークロードのためのストレージ機能も、複数発表されています。前掲の A4/A4X VM や Cluster Director 等とあわせて、 AI Hypercomputer スイートを構成しています。 参考 : Introducing Ironwood TPUs and new innovations in AI Hypercomputer 参考 : AI Hypercomputer overview Hyperdisk Exapools Hyperdisk Exapools は、エクサバイト級の容量と優れた IOPS を発揮するブロックストレージです。従来から存在する、Compute Engine 向けのブロックストレージである Hyperdisk の高性能版と見られます（Preview）。 Anywhere Cache Anywhere Cache は、2025年3月13日に発表済みの機能です。Google Cloud のゾーンに Cloud Storage 用のキャッシュを作成し、Compute Engine VM とのレイテンシを短縮し、データ転送コストを節減できます（GA）。 参考 : Overview of Anywhere Cache Rapid Storage Rapid Storage は、新発表の機能です。ゾーンレベルのオブジェクトストレージであり、ランダムアクセスにおいては従来比で5分の1のレイテンシを実現できるとされています（Preview）。 AI 推論向けのソフトウェアアップデート GKE Inference Gateway GKE Inference Gateway は、Google Kubernetes Engine（GKE）における 生成 AI 向け（Gen AI-aware）のスケーリングとロードバランシングの機能であり、コスト節減、レイテンシ低下、スループット向上に繋がるとされています（Preview）。 Pathways on Google Cloud Pathways on Google Cloud は、Google DeepMind が開発した分散型機械学習ランタイムです（Preview）。Google 社内の大規模なトレーニングおよび推論のインフラを支えている技術です。 マルチホストによる推論（multi-host inferencing）を、動的スケーリングにより、最適なコストで実現するための機能とされています。数百のアクセラレーターを最適な組み合わせで稼働させるための管理ができると見られます。 参考 : Introducing Ironwood TPUs and new innovations in AI Hypercomputer Pathways on Google Cloud については、既に以下の Google Cloud ドキュメントが公開されています。 参考 : Introduction to Pathways on Cloud vLLM on TPU vLLM が TPU で利用可能 になります（GA）。 vLLM（virtual LLM、仮想大規模言語モデル）とは、LLM の推論を高速化することを目的とした、オープンソースライブラリです。既に vLLM を GPU で稼働させている場合、そのワークロードを TPU に移行することができます。 Gemini on Google Distributed Cloud Gemini が Google Distributed Cloud で利用可能 になります（Coming Soon）。 Google Distributed Cloud とは、Google のハードウェアを顧客のデータセンターに配置し、オンプレミスで Google Cloud ワークロードを稼働させられるサービスです。類似サービスとして、Amazon Web Services（AWS）の AWS Outposts 等が挙げられます。 参考 : Google Distributed Cloud また同時に、企業データの横断検索およびエージェントのサービスである Google Agentspace も、Google Distributed Cloud 上でホストできることが発表されました。 Gemini や Google Agentspace で高度にセンシティブなデータを扱う場合や、低レイテンシが重要視されるワークロードの場合、Google Distributed Cloud 上で Gemini を稼働させることが選択肢になります。 参考 : Bringing Gemini and Google Agentspace to you on-premises Gemini for Google Workspace 2025年、Gemini for Google Workspace がすべてのエディションで利用可能になりました。Google Workspace で利用可能な Gemini の新機能も多数、発表されました。 Help me analyze Help me analyze 機能では、Gemini が Google スプレッドシートのデータを分析してくれます（Coming Soon）。明示的にプロンプトで指示しなくても、Gemini がシートからインサイトを見つけ出します。 Audio overviews on Docs Audio overviews on Docs では、Google ドキュメントの文書から、高品質な音声による概要を生成します（Coming Soon）。 Google Workspace Flows Google Workspace Flows は、AI エージェントが、さまざまな繰り返しタスクを自動化する機能です（Preview）。承認作業や市場調査、メールの整理、アジェンダの準備などが挙げられています。 YouTube 動画より引用 マルチモーダルな AI モデル Imagen 3 Imagen 3 は、画像生成モデルです。従来モデルから追加された機能として、Inpainting（修復）があります。画像の欠落部分を補完したり、逆に映り込んでしまった物体を消したりできます。 デモでは、ステージ上のギターの横に映り込んでしまった人間を「消しゴムマジック」のごとくマウスでなぞると、数秒の動画からきれいに人間が消える様子が実演されました。 Chirp 3 Chirp 3 は、会話音声の生成モデルです。既存の人物の音声を10秒程度インプットすると、それを基にしたカスタム音声を生成できるようになります。 Lyria Lyria は、音楽を生成するためのモデルです。テキストのプロンプトから、30秒の音楽クリップを生成します。 YouTube 動画より引用 Veo 2 Veo 2 は、動画生成モデルです。以前からプライベートプレビューが行われていましたが、この日の発表では、より包括的な動画制作、編集の機能が紹介されています。 デモでは、画像をインプットにしてカメラアングルやパンの方法の指定して動画を生成したり、動画の始まりと終わりの画像を指定するとその間を埋めるような動画を生成するなど、より高度な生成ができることがアピールされました。 参考 : YouTube - Opening Keynote: The new way to cloud - 45:48 YouTube 動画より引用 Vertex AI での利用 Imagen 3、Chirp 3、Lyria、Veo 2 は、Vertex AI で利用できるようになります。これは個人向けの利用を超えて、企業向け（Enterprise-ready）に提供されることを意味しています。すなわち、セキュリティや品質、生成コンテンツの安全性が意識されたサービス提供がされることになります。 Vertex AI のプロダクトマネージャーである Nenshad Bardoliwalla によるデモでは、これまで存在しなかった Vertex AI Media Studio の UI が映し出されました。 YouTube 動画より引用 YouTube 動画より引用 Vertex AI の外部連携 Llama 4 on Vertex AI Llama 4 が Vertex AI から利用できるようになります（GA）。 Vertex AI のサードパーティ連携 NetApp ストレージと Vertex AI が連携し、データを複製することなく、AI エージェント等から利用できるようになります。 他にも、Oracle、SAP、ServiceNow、Workday との連携などが強調されました。 Google Maps によるグラウンディング Vertex AI で、 Google Maps によるグラウンディング が可能になることも発表されました。生成 AI エージェント等が Google Maps から提供される地理的情報等をもとに、根拠付けを行うことができるようになります。 利用可能時期や、どのモデルから利用できるか等については、明らかになっていません。 参考 : Vertex AI offers new ways to build and manage multi-agent systems YouTube 動画より引用 マルチエージェントの開発 Agent Development Kit（ADK） マルチエージェントシステムを開発するためのオープンソースフレームワークである Agent Development Kit （ADK）が発表されました。 ADK は、複数のステップのタスクをこなすエージェントを開発するためのフレームワークです。ADK を使用することで、「100行未満の直感的なコードで AI エージェントを構築」できるとされています。また、ADK は MCP （Model Context Protocol） をサポート しています。Google から発表されるソリューションで、MCP への対応を謳ったのは初めてとみられます。これにより、Gemini 等のモデルから一般的に公開される MCP サーバーを利用することができると考えられます。 また ADK では、決定論的（deterministic）なガードレイル制御が可能であるとしています。Google は AI エージェントについて、しばしば決定論的（deterministic）と生成的（Generative）を対義語として用います。生成 AI は再現性のないレスポンスを返すおそれがありますが、ADK の制御によって、ある程度制御可能な振る舞いをさせられることが期待されます。 ADK は、当初は Python 向けにのみ提供されますが、他の言語にも対応予定です。 参考 : Vertex AI offers new ways to build and manage multi-agent systems YouTube 動画より引用 また、講演内では触れられなかったものの、同日 Google は Agent Engine も発表しています。Agent Engine は、AI エージェントをデプロイするためのフルマネージドなランタイムです。エージェントのインフラ（スケーリング、セキュリティ、モニタリング）に加えて、セッション管理や評価を扱うことができます。Agent Engine は ADK と統合されており、モデルに依存しないため、Gemini のほか Claude、Mistral 等もホストすることができます。Google Agentspace との統合もサポートされる予定です。 Agent2Agent Protocol（A2A） Agent2Agent Protocol （A2A）がオープンなプロトコルとして発表されました。Agent2Agent Protocol は AI エージェント同士が通信するためのプロトコルです。 Agent2Agent Protocol は、 クライアントエージェント （子のエージェントを監督するエージェント）と リモートエージェント （実際にタスクを行う子エージェント）間の通信方法を定めるものです。マルチエージェントを前提としており、クライアントエージェントがリモートエージェントを見つけ出すために、リモートエージェントが自らの機能を広告（advertise）するための エージェントカード や、実行するべき仕事である タスク 、その成果物である アーティファクト 、アーティファクトのフォーマットに関するネゴシエーション、 OpenAPI 互換の認証・認可スキーム などを定義しています。 生成 AI エージェントにおけるプロトコルでは MCP（Model Context Protocol）が真っ先に浮かびますが、Agent2Agent Protocol はこれと競合するものではなく、「補完する（complements）」としています。 アクセンチュア、Box、デロイト、Salesforce、SAP、ServiceNow など、50社以上のパートナーがこのプロトコルの定義にコントリビュートしています。 参考 : Announcing the Agent2Agent Protocol (A2A) Google Agentspace Google Agentspace のデモ Google Agentspace は、企業データの横断検索や、AI エージェントによるタスクの自動化が可能なサービスです。以下を参照してください。 参考 : Google Agentspaceを徹底解説！ - G-gen Tech Blog この日の発表では、まだ Early Access 期間中である Google Agentspace の新機能が次々と発表されました。 YouTube 動画より引用 Google Agentspace では、人間の代わりにタスクを実行するエージェントを利用できます。 Agent Designer （カスタムエージェントをノーコードで開発）、アイデア生成エージェント、Deep Research エージェントなど、Google Agentspace から利用可能なさまざまなエージェントが紹介されました。 Google Agentspace では、チャット形式で質問を投入すると、単なる横断検索や要約ではなく、自然言語による質問に答える形での顧客分析、要約した音声の生成など、さまざまなタスクを実行できることがデモされました。 AI を利用したフォーキャストと組み合わせてレポートを生成し、その結果をみて必要なメールを作成し、送信するなど、一通りの作業を Google Agentspace が代わりに実行し、業務時間を節約できることが示唆されました。 Agentspace integrated into Chrome Google Agentspace が Chrome Enterprise と統合することが発表されました（Preview）。 Chrome ブラウザの検索ボックスから会社のデータを横断検索できるようになる機能とみられます。これにより、組織のデータの検索が容易になり、生産性が向上するとしています。 参考 : Scale enterprise search and agent adoption with Google Agentspace Customer Engagement Suite 顧客とのエンゲージメントを高めるための機能として、以下のような機能も発表されました。 Human-like voices（人間のような音声） Streaming video support（動画のストリーミング入力が可能に） AI assistance to build agents（エージェント構築を AI が支援） いずれも Coming Soon とされており、Conversational Agents（旧 Dialogflow CX）で実装されるとみられます。 参考 : Transforming customer experiences with AI agents and the next generation Customer Engagement Suite デモでは、カスタマーサービスエージェントが人間の問い合わせに音声で応答する様子が紹介されました。園芸用品の EC サイトを想定した、以下のようなデモが実演されました。 顧客がカメラに花を映すと、AI エージェントはその花がペチュニアであることを言い当てて、それにあった土や肥料をレコメンド 顧客がそれを気に入ったことを確認したら、レコメンドした製品を既にカートにあった商品と入れ替え 顧客が AI に無茶な値引きを要求すると、AI から人間にエスカレーション YouTube 動画より引用 データエージェント データエージェントの実装 BigQuery を中心としたデータ活用は、Google Cloud において引き続き重要です。以前より Google Cloud は、データの活用を AI が支援する データエージェント （Data Agents）の概念を提唱していました。この日は、これを推し進めるように、データエンジニアリング（Data Engineering）、データサイエンス（Data Science）、データアナリシス（Data Analysis）の各分野で、エージェント機能が強化されていることが紹介されました。 デモでは、BigQuery Studio 上で、AI 補助によるデータエンジニアリング機能である BigQuery data preparation などを用いて、自然言語による指示でデータを分析する様子が紹介されました。これまで以上に、データパイプラインの構築、ノートブック上での分析、可視化などが、生成 AI に対する自然言語の指示で容易に実現できるようになります。 YouTube 動画より引用 YouTube 動画より引用 BigQuery に関する新発表 基調講演では深く触れられませんでしたが、Next '25 では、BigQuery に関する発表も多数されています。特に、メタデータの自動生成や分析補助など、AI の補助のもとにデータ分析基盤の運用を効率化される機能が発表されたことは注目に値します。 BigQuery に関する技術的な発表は、以下の記事も参照してください。 blog.g-gen.co.jp Gemini Code Assist Agents 生成 AI がコーディングを支援する Gemini Code Assist では、 Gemini Code Assist Agents が発表されました。これまで以上に、開発のライフサイクル全体がエージェントにより効率化されます。 カンバンボード （Kanban board）では、いわゆるカンバン方式で、開発者がエージェントと対話できます。 また、Atlassian、Sentry、Snyk 等、サードパーティと Gemini Code Assist の連携も紹介されました。 Gemini の支援によって実現する、開発の新しいスタイルについては、2日目の Developer Keynote（開発者向け基調講演）で詳しく紹介されました。 blog.g-gen.co.jp Security Agents トリアージ、マルウェア検査 セキュリティエージェント の具体的な機能として、Google Threat Intelligence における Malware Analysys と、Google Security Operations（Google SecOps）における Alert Triage が挙げられました。いずれも Coming Soon とされています。 Google Unified Security（GUS） Google が持つセキュリティソリューションを統合したソリューションとして、 Google Unified Security （GUS）が発表されました。 Google Unified Security は、既存ソリューションである Google Security Operations（Google SecOps）、Google Chrome Enterprise（旧 BeyondCorp）、Mandiant（セキュリティに関するコンサルティング）、Security Command Center、Google Threat Intelligence を統合したソリューションです。 参考 : Driving secure innovation with AI and Google Unified Security YouTube 動画より引用 例として、Chrome Enterprise により、ブラウザのテレメトリが Google SecOps に送信され、脅威を検出して自動的に修復する、などの統合されたセキュリティ施策が実施可能とされます。 デモでは、Google Unified Security（GUS）のコンソール画面（UI）が紹介され、サードパーティの生成 AI モデルへの機密情報漏洩や、開発者がうっかり空けたファイアウォールからの攻撃への検知と対処が紹介されました。 AI Protection Google Cloud の脆弱性を検知するサービスである Security Command Center にも、新機能が追加されます。 AI ライフサイクル全体のリスク管理を行うための AI Protection では、環境全体で AI がどのように利用されているかを検出し、カタログ化します。そのうえで Sensitive Data Protection（SDP）や Model Armor といったソリューションと連携し、情報漏洩や攻撃への対処を可能にします。 参考 : Announcing AI Protection: Security for the AI era 参考 : Security Command Centerを徹底解説。Google Cloud(GCP)の脆弱性を自動検知 - G-gen Tech Blog 参考 : Model Armorを徹底解説！ - G-gen Tech Blog 次回の Google Cloud Next 次回の Google Cloud Next は、同じくラスベガスで、2026年4月22日から24日までの3日間で開催されることが発表されました。 関連記事 Google Cloud Next '25 の関連記事は、以下の記事一覧をご参照ください。開催期間中は、記事が随時公開されます。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では、 Private Service Connect を使用して、Cloud Run サービスから別のプロジェクトにある Cloud Run サービスを 内部ネットワーク経由 で呼び出す方法を解説します。 Cloud Run 同士のプライベートアクセス 呼び出し元アクセス制御 同一プロジェクトの Cloud Run へのプライベートアクセス 別プロジェクトの Cloud Run へのプライベートアクセス 構成図 シェル変数の設定 producer プロジェクトのリソース作成 デフォルトのプロジェクトを設定 VPC ネットワーク・サブネットの作成 VPC の作成 サブネットの作成 Cloud Run サービスのデプロイ Artifact Registry リポジトリの準備 使用するコード（Go） コンテナイメージのビルド デプロイ 内部アプリケーションロードバランサの作成 サービスアタッチメントの作成 consumer プロジェクトのリソース作成 デフォルトのプロジェクトを設定 VPC ネットワーク・サブネットの作成 VPC の作成 サブネットの作成 PSC エンドポイントの作成 Cloud Run サービスのデプロイ Artifact Registry リポジトリの準備 使用するコード（Go） コンテナイメージのビルド サービスのデプロイ 動作確認 Cloud Run 同士のプライベートアクセス 呼び出し元アクセス制御 複数の Cloud Run サービスを使用してマイクロサービスアーキテクチャを構成するようなユースケースでは、Cloud Run サービスから別の Cloud Run サービスに対する安全なアクセスを経路を確保する必要があります。 認証・認可の側面では、IAM によって呼び出し元の IAM プリンシパルを制限することができます。これにより、特定のサービスアカウントが紐づいた Cloud Run のみを呼び出し元として認証することができます。 参考 : IAM によるアクセス制御 IAM を使用して Cloud Run の呼び出し元を認証する ネットワークアクセスの側面では、 Ingress （上り、内向き）の設定により、「内部」からのネットワークアクセスでのみ Cloud Run を呼び出せるように設定することができます。「内部」からのアクセスとして認識されるのは以下のようなケースです。 内部アプリケーション ロードバランサからのアクセス VPC Service Controls の境界で許可されるリソースからのアクセス 特定の Google Cloud サービス（Cloud Scheduler、Pub/Sub、Workflows など）からのアクセス Cloud Run サービスと同じプロジェクトにある VPC ネットワーク内リソースからのアクセス 重要な点として、Cloud Run サービスから別の Cloud Run サービスを直接呼び出すとき、このネットワークアクセスは 「内部」として認識されません 。そのため、VPC 内のサブネットを経由するなどして「内部」からの呼び出しであることを認識させる必要があります。 参考 : Cloud Run のネットワーク上り（内向き）を制限する 参考 : VPC Service Controls（VPC SC）の使用 「内部」からのネットワークアクセスのみを許可する 同一プロジェクトの Cloud Run へのプライベートアクセス 呼び出し元と呼び出し先の Cloud Run が同一プロジェクトにある場合、 限定公開の Google アクセス を有効化したサブネットを経由することで、Cloud Run の呼び出しを「内部」からのネットワークアクセスにすることができます。 参考 : 限定公開の Google アクセス 参考 : 限定公開の Google アクセスの仕組みと手順をきっちり解説 - G-gen Tech Blog Direct VPC Egress 、もしくは サーバーレス VPC アクセス を使用することで、呼び出し元 Cloud Run からプライベート IP アドレスを使用してサブネットに接続することができます。 参考 : VPC ネットワークによるダイレクト VPC 下り（外向き） 参考 : サーバーレス VPC アクセス 同一プロジェクト内の Cloud Run を内部ネットワーク経由で呼び出す場合 同一プロジェクトの Cloud Run サービスに対するプライベートアクセスについては、以下の記事で詳細な手順を解説しています。 blog.g-gen.co.jp 別プロジェクトの Cloud Run へのプライベートアクセス 前述の限定公開の Google アクセスを有効化したサブネットを経由する方法は、呼び出し元 Cloud Run と呼び出し先 Cloud Run が同一プロジェクトに存在する場合のみ利用することができます。 異なるプロジェクトの Cloud Run サービスを呼び出したい場合、呼び出し先 Cloud Run の前段に内部アプリケーションロードバランサを構成し、呼び出し元 Cloud Run から Private Service Connect 経由でプロジェクトを跨いでロードバランサに接続する 方法があります。 Private Service Connect は、 パブリック IP アドレスを持たない VM やオンプレミスのクライアントから、プライベートネットワーク経由で Google Cloud の API 群や、ユーザーの独自サービスへアクセスできるようにするための仕組みです。これは、別のプロジェクトからのプライベートアクセスを実現したい場合にも使用することができます。 参考 : Private Service Connect 参考 : Private Service Connect機能解説。Google Cloud APIにプライベート接続 参考 : Private Service Connect でマネージドサービスを公開する Private Service Connect では、アクセス元を コンシューマー （Consumer）、アクセス先を サービス プロデューサー （Producer）と呼びます。 別プロジェクトの Cloud Run を内部ネットワーク経由で呼び出す場合 構成図 当記事では、以下のチュートリアルを参考にリソースの作成を行っていきます。 参考 : Private Service Connect: Private Service Connect を使用して Cloud Run でサービスを公開して使用する 2つのプロジェクト（consumer、producer）対して、以下の図のようにリソースを構成していきます。Private Service Connect を構成することで、 Cloud Run（Consumer） からプライベートネットワーク経由で Cloud Run（Producer） に接続できることが目標です。 Cloud Run から異なるプロジェクトの Cloud Run へのアクセス（構成図） シェル変数の設定 当記事では gcloud CLI を使用して各種リソースの作成を行っていきます。gcloud CLI のインストールについては、以下の公式ドキュメントを参照してください。 参考 : gcloud CLI をインストールする まず、これから実行していくコマンドで何度か使用する値をシェル変数として設定しておきます。 変数名 値 PRODUCER_PJ producer プロジェクトのプロジェクト ID CONSUMER_PJ consumer プロジェクトのプロジェクト ID LOCATION リソースを作成するリージョン REPO_NAME Artifact Registry リポジトリの名前（各プロジェクトに作成する） # シェル変数の設定 PRODUCER_PJ = < producerプロジェクトのID > CONSUMER_PJ = < consumerプロジェクトのID > LOCATION =asia-northeast1 REPO_NAME =myrepo producer プロジェクトのリソース作成 デフォルトのプロジェクトを設定 これから producer プロジェクトにリソースを作成するため、gcloud CLI のデフォルトのプロジェクトに設定しておきます。 # デフォルトのプロジェクトを設定 $ gcloud config set project ${PRODUCER_PJ} VPC ネットワーク・サブネットの作成 producer プロジェクトに VPC とサブネットを作成する VPC の作成 まず、producer プロジェクトでこれから使用する VPC、サブネットをまとめて作成します。 以下のコマンドで VPC を作成します。 # producer 側プロジェクトの VPC を作成 $ gcloud compute networks create producer-vpc --subnet-mode custom サブネットの作成 producer-subnet として、producer 側の Cloud Run をバックエンドとするロードバランサを配置するためのサブネットを作成します。 # producer-vpc にサブネットを作成 $ gcloud compute networks subnets create producer-subnet \ --network = producer-vpc \ --range = 10 . 0 . 0 . 0 / 28 \ --region = ${LOCATION} また、内部アプリケーションロードバランサでは、 プロキシ専用サブネット というサブネットを別途用意する必要があります。 参考 : Envoy ベースのロードバランサ向けプロキシ専用サブネット 以下のように --purpose=REGIONAL_MANAGED_PROXY を指定してサブネットを作成します。 # 内部アプリケーションロードバランサのプロキシ専用サブネットを作成 $ gcloud compute networks subnets create lb-proxy-subnet \ --network = producer-vpc \ --range = 10 . 100 . 100 . 0 / 24 \ --region = ${LOCATION} \ --purpose = REGIONAL_MANAGED_PROXY \ --role = ACTIVE Private Service Connect のサービスアタッチメントが使用する IP を払い出すための NAT サブネットを作成します。 --purpose=PRIVATE_SERVICE_CONNECT を指定してサブネットを作成します。 # PSC サブネットを作成 $ gcloud compute networks subnets create psc-nat-subnet \ --network = producer-vpc \ --region = ${LOCATION} \ --range = 10 . 100 . 101 . 0 / 24 \ --purpose = PRIVATE_SERVICE_CONNECT producer 側プロジェクトに作成したサブネット Cloud Run サービスのデプロイ producer 側の Cloud Run サービスを作成する Artifact Registry リポジトリの準備 接続先となる Cloud Run サービスを作成していきます。 まず、Cloud Run にデプロイするコンテナイメージを格納するためのリポジトリがない場合は作成しておきます。 # Artifact Registry リポジトリの作成 $ gcloud artifacts repositories create ${REPO_NAME} \ --repository-format = docker \ --location = ${LOCATION} 使用するコード（Go） 当記事では Go で作成したウェブアプリケーションを Cloud Run にデプロイしていきます。 以下のコードでは、consumer 側のサービスからのアクセスに対して Hello from producer! というメッセージを返します。 // main.go package main import ( "encoding/json" "log" "net/http" ) type Response struct { Status int Message string } func main() { log.Print( "Service is running on port 8080" ) http.HandleFunc( "/" , func (w http.ResponseWriter, r *http.Request) { body := Response{ http.StatusOK, "Hello from producer!" , } res, err := json.Marshal(body) if err != nil { http.Error(w, err.Error(), http.StatusInternalServerError) return } w.Header().Set( "Content-Type" , "application/json" ) w.Write(res) }) if err := http.ListenAndServe( ":8080" , nil ); err != nil { log.Fatal(err) } } コンテナイメージのビルド producer 側 Cloud Run にデプロイするコンテナイメージを作成します。 # Cloud Build でコンテナイメージをビルドする $ gcloud builds submit --pack image = ${LOCATION} -docker.pkg.dev/ ${PRODUCER_PJ} / ${REPO_NAME} /producer デプロイ 作成したコンテナイメージを使用して、Cloud Run サービスをデプロイします。内部アプリケーションロードバランサからサーバーレス NEG 経由でアクセスするサービスのため、 --ingress フラグには internal を指定します。 参考 : Cloud Run のネットワーク上り（内向き）を制限する # Cloud Run サービスのデプロイ $ gcloud run deploy producer \ --image = ${LOCATION} -docker.pkg.dev/ ${PRODUCER_PJ} / ${REPO_NAME} /producer \ --ingress = internal \ --allow-unauthenticated \ --region = ${LOCATION} 内部アプリケーションロードバランサからアクセスするため、Ingress は「内部」に設定する 2025年4月時点ではプレビュー提供の機能ですが、 サービスのエンドポイント URL を無効化する ことで、内部アプリケーションロードバランサを経由したアクセスを強制する（サービスへの直接アクセスをできなくする）こともできます。詳細については以下の記事を参照してください。 blog.g-gen.co.jp 内部アプリケーションロードバランサの作成 内部アプリケーションロードバランサを作成する Cloud Run サービスをバックエンドとする内部アプリケーションロードバランサを作成します。 内部アプリケーションロードバランサは様々なコンポーネントから構成されており、gcloud CLI ではそれらを1つ1つ作成していく必要があります。各コンポーネントの詳細については、以下のドキュメントを参照してください。 参考 : 内部アプリケーション ロードバランサの概要 # 内部アプリケーションロードバランサの作成 ## IP アドレスの予約 $ gcloud compute addresses create cloudrun-ip \ --region = ${LOCATION} \ --subnet = producer-subnet ## サーバーレス NEG の作成（作成した Cloud Run サービスを指定） $ gcloud compute network-endpoint-groups create cloudrun-producer-neg \ --region = ${LOCATION} \ --network-endpoint-type = serverless \ --cloud-run-service = producer ## バックエンドサービスの作成 $ gcloud compute backend-services create cloudrun-producer-bes \ --load-balancing-scheme = INTERNAL_MANAGED \ --protocol = HTTP \ --region = ${LOCATION} ## バックエンドサービスにサーバーレス NEG を追加 $ gcloud compute backend-services add-backend cloudrun-producer-bes \ --region = ${LOCATION} \ --network-endpoint-group = cloudrun-producer-neg \ --network-endpoint-group-region = ${LOCATION} ## URL マップの作成 $ gcloud compute url-maps create producer-urlmap \ --default-service = cloudrun-producer-bes \ --region = ${LOCATION} ## ターゲット HTTP プロキシの作成 $ gcloud compute target-http-proxies create producer-http-proxy \ --url-map = producer-urlmap \ --region = ${LOCATION} ## 転送ルールの作成 $ gcloud compute forwarding-rules create cloudrun-fr \ --load-balancing-scheme = INTERNAL_MANAGED \ --network = producer-vpc \ --subnet = producer-subnet \ --address = cloudrun-ip \ --target-http-proxy = producer-http-proxy \ --target-http-proxy-region = ${LOCATION} \ --region = ${LOCATION} \ --ports = 80 \ --allow-global-access 作成した内部アプリケーションロードバランサ バックエンドに Cloud Run サービスが設定されている サービスアタッチメントの作成 サービスアタッチメントを作成する consumer 側から内部アプリケーションロードバランサにアクセスするためのサービスアタッチメントを作成します。 参考 : 公開サービスの概要 - サービス アタッチメント --consumer-accept-list に接続元となる consumer 側プロジェクトの ID を指定し、このプロジェクトからの接続数の上限を設定しています（ここでは5つに設定）。 --nat-subnets には作成しておいた NAT サブネットを指定します。サービスアタッチメントは、接続元の consumer 側サブネットからの通信を、NAT サブネットの IP アドレス範囲にある IP アドレスに対して自動的に SNAT を行うことで、consumer 側から producer 側サブネットへのアクセスを実現しています。 参考 : 初めての Private Service Connect #1 PSCってなに？ 編 # サービスアタッチメントの作成 $ gcloud compute service-attachments create cloudrun-attachment \ --region = ${LOCATION} \ --producer-forwarding-rule = cloudrun-fr \ --connection-preference = ACCEPT_MANUAL \ --consumer-accept-list = ${CONSUMER_PJ} = 5 \ --nat-subnets = psc-nat-subnet 内部アプリケーションロードバランサをターゲットとするサービスアタッチメント 作成したサービスアタッチメントの URI は、consumer 側の Private Service Connect エンドポイントを作成する際に使用します。 # サービスアタッチメント URI の確認 $ gcloud compute service-attachments describe cloudrun-attachment --region = ${LOCATION} consumer プロジェクトのリソース作成 デフォルトのプロジェクトを設定 ここからは consumer プロジェクトにリソースを作成するため、gcloud CLI のデフォルトのプロジェクトを変更します。 # デフォルトのプロジェクトを設定 $ gcloud config set project ${CONSUMER_PJ} VPC ネットワーク・サブネットの作成 consumer プロジェクトに VPC とサブネットを作成する VPC の作成 consumer プロジェクトで使用する VPC、サブネットを作成します。 まず、以下のコマンドで VPC を作成します。 # consumer 側プロジェクトの VPC を作成 $ gcloud compute networks create consumer-vpc --subnet-mode custom サブネットの作成 consumer-subnet として、producer 側サービスアタッチメントに接続するエンドポイント用のサブネットを作成します。 # PSC エンドポイント用サブネットの作成 $ gcloud compute networks subnets create consumer-subnet \ --network = consumer-vpc \ --range = 10 . 0 . 0 . 0 / 24 \ --region = ${LOCATION} \ --enable-private-ip-google-access cloudrun-egress として、consumer 側 Cloud Run が Direct VPC Egress を使用して接続するサブネットを作成します。 # Direct VPC Egress 用サブネットの作成 $ gcloud compute networks subnets create cloudrun-egress \ --network = consumer-vpc \ --range = 10 . 0 . 1 . 0 / 24 \ --region = ${LOCATION} \ --enable-private-ip-google-access consumer 側プロジェクトに作成したサブネット PSC エンドポイントの作成 PSC エンドポイントを作成する Private Service Connect に接続するためのエンドポイント（PSC エンドポイント）を作成します。 PSC エンドポイントには単一の IP アドレスを設定します。この IP アドレスにアクセスすることで、Private Service Connect 経由で Producer 側 Cloud Run サービスを呼び出すことができるようになります。 # PSC エンドポイント用の IP アドレスの作成 $ gcloud compute addresses create cloudrun-service-ip \ --region = ${LOCATION} \ --subnet = consumer-subnet \ --ip-version = IPV4 --target-service-attachment に接続先サービスアタッチメントの URI を指定して、PSC エンドポイントを作成します。 # PSC エンドポイントの作成 $ gcloud compute forwarding-rules create cloudrun-ep \ --region = ${LOCATION} \ --network = consumer-vpc \ --address = cloudrun-service-ip \ --target-service-attachment = projects/ ${PRODUCER_PJ} /regions/ ${LOCATION} /serviceAttachments/cloudrun-attachment producer 側プロジェクトのサービスアタッチメント URI を指す PSC エンドポイント Cloud Run サービスのデプロイ consumer 側の Cloud Run サービスを作成する Artifact Registry リポジトリの準備 consumer 側プロジェクトに Cloud Run にデプロイするコンテナイメージを格納するためのリポジトリがない場合は作成しておきます。 # Artifact Registry リポジトリの作成 $ gcloud artifacts repositories create ${REPO_NAME} \ --repository-format = docker \ --location = ${LOCATION} 使用するコード（Go） consumer 側のサービスは、 / にアクセスしたときは Hello from consumer! というメッセージを返し、 /psc にアクセスしたときは producer 側サービスにリクエストを送信するアプリケーションになっています。 リクエストの送信先は、Cloud Run の環境変数 PSC_ENDPOINT_IP に設定します。 // main.go package main import ( "context" "fmt" "io" "log" "net/http" "os" "google.golang.org/api/idtoken" ) type Response struct { Status int `json:"status"` Message string `json:"message"` } func main() { log.Print( "Service is running on port 8080" ) http.HandleFunc( "/" , func (w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Hello from consumer!" ) }) http.HandleFunc( "/psc" , func (w http.ResponseWriter, r *http.Request) { targetUrl := os.Getenv( "PSC_ENDPOINT_IP" ) audience := targetUrl + "/" resp, err := makeGetRequest(w, targetUrl, audience) if err != nil { fmt.Fprintf(w, "Error: %v" , err) return } defer resp.Body.Close() if resp.StatusCode != http.StatusOK { fmt.Fprintf(w, "Error: %s" , resp.Status) return } }) if err := http.ListenAndServe( ":8080" , nil ); err != nil { log.Fatal(err) } } // producer 側 Cloud Run サービスに対してリクエストを送信する func makeGetRequest(w io.Writer , targetURL string , audience string ) (*http.Response, error ) { ctx := context.Background() client, err := idtoken.NewClient(ctx, audience) if err != nil { return nil , fmt.Errorf( "idtoken.NewClient: %w" , err) } resp, err := client.Get(targetURL) if err != nil { return nil , fmt.Errorf( "client.Get: %w" , err) } defer resp.Body.Close() if _, err := io.Copy(w, resp.Body); err != nil { return nil , fmt.Errorf( "io.Copy: %w" , err) } return resp, nil } コンテナイメージのビルド consumer 側 Cloud Run にデプロイするコンテナイメージを作成します。 # Cloud Build でコンテナイメージをビルドする $ gcloud builds submit --pack image = ${LOCATION} -docker.pkg.dev/ ${CONSUMER_PJ} / ${REPO_NAME} /consumer サービスのデプロイ consumer 側 Cloud Run サービスをデプロイしていきます。 まず、環境変数として設定する PSC エンドポイントの IP アドレスを取得し、シェル変数に設定します。 $ PSC_ENDPOINT_IP = $( gcloud compute addresses describe cloudrun-service-ip --format =' value(address) ' ) Cloud Run サービスを作成します。当記事では手順の簡略化のため、サービスをインターネットに公開する形で作成します。 --subnet には Direct VPC Egress で接続するサブネットを指定します。 --vpc-egress の値はユースケースによって変更してください。 参考 : gcloud run deploy # Cloud Run サービスのデプロイ $ gcloud run deploy consumer \ --image = ${LOCATION} -docker.pkg.dev/ ${CONSUMER_PJ} / ${REPO_NAME} /consumer \ --ingress = all \ --allow-unauthenticated \ --region = ${LOCATION} \ --network = consumer-vpc \ --subnet = cloudrun-egress \ --vpc-egress = all-traffic \ --set-env-vars = PSC_ENDPOINT_IP =http:// ${PSC_ENDPOINT_IP} Direct VPC Egress 経由で VPC に接続できるように設定する 動作確認 Private Service Connect 経由で producer プロジェクトの Cloud Run サービスを呼び出せるか確認します。 以下のコマンドで consumer プロジェクトの Cloud Run サービスのエンドポイント URL をシェル変数に設定します。 # Cloud Run サービス（consumer）の URL を確認する $ SERVICE_URL = $( gcloud run services describe consumer \ --project = ${CONSUMER_PJ} \ --region = ${LOCATION} \ --format =' value(status.url) ' ) まずは curl コマンドで consumer 側サービスの / にアクセスしてみます。 # consumer 側サービスのレスポンスを確認 $ curl ${SERVICE_URL} Hello from consumer! consumer 側サービスの /psc にアクセスし、Private Service Connect 経由で producer 側 Cloud Run サービスを呼び出します。 # Private Service Connect 経由で producer 側サービスのレスポンスを取得 $ curl ${SERVICE_URL} /psc { " Status " :200, " Message " : " Hello from producer! " } 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では、Cloud Run のサービスに直接 Identity-Aware Proxy（IAP）を構成する方法について解説します。 前提知識 Cloud Run Identity-Aware Proxy（IAP） Cloud Run を IAP でアクセス制御する方法 ロードバランサを使用する方法 概要 IAP 認証と IAM 認証の関係 制限事項 手順 新規サービスの場合 既存サービス Context-Aware Access の使用 前提知識 Cloud Run Cloud Run とは、Google Cloud のマネージドなコンテナ実行環境でアプリケーションを実行することができる、サーバーレス コンテナコンピューティング サービスです。 Cloud Run には、 Cloud Run services 、 Cloud Run jobs 、 Cloud Run functions （旧称 Cloud Functions）の3種類がありますが、当記事の内容は HTTP リクエストベースでアプリケーションを実行できる Cloud Run services および Cloud Run functions に関するものとなります。 Cloud Run の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Identity-Aware Proxy（IAP） Identity-Aware Proxy（以下、IAP）は、Web アプリケーションや、仮想マシンなどのクラウドリソースに対して、アプリケーションレベルの認証機能を提供するサービスです。 IAP を用いることで、Web アプリケーションや仮想マシンにアクセスできるユーザーを、IAP を利用できる IAM ロールがアタッチされた組織内の Google アカウントやグループに制限することができます。 参考 : Identity-Aware Proxy の概要 Cloud Run を IAP でアクセス制御する方法 Cloud Run サービスにおいて、IAP を使ってアクセス制御する方法は、2つあります。 ロードバランサを使用する方法 Cloud Run サービスに IAP を直接構成する方法 当記事では、2つ目の「Cloud Run サービスに IAP を直接構成する方法」を紹介します。 ロードバランサを使用する方法 従来からある方法として、Cloud Run の前段にアプリケーションロードバランサを作成し、 ロードバランサに対して IAP を構成する ことで、特定の Google アカウントを持つユーザーのみが、Cloud Run 上のアプリケーションにアクセスできるように設定できます。 ロードバランサを使用することで、サービスのエンドポイントとなるドメインを独自のものにすることができるほか、フルマネージドの WAF（Web Application Firewall）サービスである Cloud Armor を使用できるメリットがあります。 しかし、ロードバランサがあることで構成が複雑になったり、Google Cloud 利用料金が増加してしまうというデメリットがあります。 ロードバランサに IAP を構成する場合 Cloud Run でロードバランサを使用して IAP を構成する方法については、以下の記事で解説しています。 blog.g-gen.co.jp 概要 Cloud Run サービスに IAP を直接構成する方法 では、ロードバランサを使用する場合と比べて、シンプルかつローコストで、IAP による認証を有効化することができます。 その代わり、サービスのエンドポイントとして独自ドメインを使用することができない点に注意が必要です。 Cloud Run に直接 IAP を構成する場合 なお、IAP を直接構成する方法は、当記事を執筆した2025年4月現在ではプレビュー段階です。 参考 : Configure Identity-Aware Proxy for Cloud Run 参考 : Preview版のサービスを使うとはどういうことなのか IAP 認証と IAM 認証の関係 「認証が必要」と設定された Cloud Run で IAP を直接構成する場合、IAP による認証と IAM による認証の 両方 が行われます。 エンドユーザーの認証は IAP 側で行われます。IAM で IAP で保護された Web アプリ ユーザー （ roles/iap.httpsResourceAccessor ）ロールを付与されたプリンシパルのみ、IAP が構成された Cloud Run サービスにアクセスすることができます。 IAP による認証が行われたあと、Cloud Run 側で IAM 認証が行われます。この認証では、IAP 自体が持っているサービスアカウント（ service-<プロジェクト番号>@gcp-sa-iap.iam.gserviceaccount.com ）が使用されるため、このサービスアカウントに対して Cloud Run サービス起動元 （ roles/run.servicesInvoker ）などの IAM ロールを付与する必要があります。 「認証が必要」に設定されたサービスで IAP を構成する場合 参考 : IAP で保護されたリソースへのアクセスの管理 参考 : IAP for Cloud Run の有効化 制限事項 Cloud Run で IAP を直接構成する場合、以下の制限事項があります。 IAP を構成する Cloud Run は組織内のプロジェクトに存在する必要がある IAP で認証するプリンシパルは組織内のものである必要がある ロードバランサと Cloud Run サービスの両方で IAP を構成することはできない IAP を有効化しているサービスでは、Pub/Sub 等のサービスとの統合が機能しなくなる可能性がある 手順 新規サービスの場合 gcloud CLI で新しい Cloud Run サービスをデプロイする際、 --iap フラグを使用することで、サービスに対して IAP を構成することができます。 IAP の構成はプレビュー機能のため、 gcloud beta コマンドを使用します。 # IAP を有効化したサービスを作成する $ gcloud beta run deploy < サービス名 > \ --region =< サービスを作成するリージョン > \ --image =< コンテナイメージのパス > \ --no-allow-unauthenticated \ --iap コンソールの場合、サービス作成画面の「構成」セクションに「Identity-Aware Proxy」の項目があります。 新規サービスで IAP を有効化する（コンソール） 既存サービス 既存の Cloud Run サービスで IAP を有効化する場合、サービス作成時と同様に --iap フラグを使用します。 # 既存のサービスで IAP を有効化する $ gcloud beta run services update < サービス名 > \ --region =< サービスが存在するリージョン > \ --iap IAP を無効化する場合は、 --no-iap フラグを使用することができます。 # 既存のサービスで IAP を無効化する $ gcloud beta run services update < サービス名 > \ --region =< サービスが存在するリージョン > \ --no-iap コンソールでは、サービス詳細画面の「セキュリティ」タブに IAP の設定項目があります。 既存のサービスで IAP を有効化する（コンソール） Context-Aware Access の使用 IAP では、[ポリシーの編集] から、Context-Aware Access のアクセスレベルを設定できます。 これにより、エンドユーザーの IP アドレスやデバイス属性に基づいたアクセス制御を IAP に追加することができます。 IAP に Context-Aware Access ポリシーを追加する 参考 : コンテキストアウェア アクセスの概要 参考 : Identity-Aware Proxy でコンテキストアウェア アクセスを設定する 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の奥田です。当記事では、Google Cloud （旧称 GCP）のエージェント構築サービスを利用し、最新のドル・円レートを取得するエージェントを構築したので解説します。 はじめに Conversational Agents とは Playbook とは ツールとは OpenAPI ツールとは システム構成と手順の概要 構成図 実装手順 API の有効化/取得 Cloud Run functions の構築 Python のバージョン ディレクトリ構成 requirements.txt の作成 main.py の開発 Cloud Run function 実行用サービスアカウントの作成 Cloud Run functions のデプロイ Conversational Agent の作成 Tool の構築 Playbook の構築 設定項目 動作検証 Example の格納 デプロイ 応用 はじめに Conversational Agents とは Conversational Agents とは、Google Cloud が提供する会話型 AI プラットフォームです。 2024年後半から2025年初頭にかけて、Vertex AI Agents （Playbook とデータストア機能） コンソールと Dialogflow CX コンソールが、単一の会話型エージェントコンソールに統合され、サービス名称も変更になりました。 参考 : Dialogflow - Renaming and console consolidation plan 参考 : Dialogflow - Conversational Agents console overview Conversational Agents の名称の変遷 Conversational Agents（旧称 Dialogflow CX）では、生成的（Generative）なエージェントである Playbook と、決定論的（Deterministic）なエージェントである Flow を構築できます。当記事では、 Playbook を利用して生成 AI エージェントを開発します。 参考 : Generative versus deterministic なお Playbook は、Google の生成 AI エージェントサービスである Google Agentspace とも統合可能 です。 参考 : Google Agentspace - Integrate Dialogflow agents Playbook とは Playbook とは、生成 AI エージェントを構築するためのフルマネージドサービスです。生成 AI の機能を活かし、エンドユーザーの意図を理解して、応答を生成したり、人間の代わりにタスクを実行できます。 参考 : Playbook Playbookは以前、前述のとおり、AI Applications（旧称 Vertex AI Agent Builder）の Agents と呼ばれていましたが、改称されました。AI Applications の詳細は、以下の記事をご参照下さい。 blog.g-gen.co.jp 今回の記事では、単一の Playbook から構成される、 シングルエージェント構成 を実装します。 ツールとは ツール とは、生成 AI エージェントが外部システムに接続して知識にアクセスしたり、複雑なタスクを実行したりするために使用する機能です。ツールは、Playbook から呼び出されます。 ツールの種類は以下のとおりです。 組み込みツール OpenAPI ツール データストアツール コネクタツール Function ツール 当記事では、 OpenAPI ツール を利用します。 参考 : Playbook tools OpenAPI ツールとは OpenAPI ツールとは、OpenAPI Specification（OAS） に基づいた API 定義ファイルを用いて定義するツールです。 OpenAPI スキーマにより、API とやり取りするデータの形式を細かく定義します。 認証方式としては、Dialogflow のサービスエージェント認証、サービスアカウント認証、API キー、OAuth、Bearer トークンなどがサポートされています。当記事では、 Dialogflow のサービスエージェント認証 を使用します。 OpenAPI を利用して関数を呼び出す方法は、他社パブリッククラウドのエージェントでも同様のことが実現可能です。詳しくは以下の記事をご覧ください。 blog.g-gen.co.jp システム構成と手順の概要 構成図 当記事では、以下のような構成でエージェントを構築しました。 実装手順 以下の順序で環境を構築しました。 API の有効化/取得 Cloud Run functions の構築 Conversational Agent の作成 Tool の構築 Playbook の構築 API の有効化/取得 Google Cloud プロジェクトで、今回の構成に必要な Google Cloud サービスの API を有効化します。 gcloud services enable \ aiplatform.googleapis.com \ artifactregistry.googleapis.com \ cloudbuild.googleapis.com \ cloudfunctions.googleapis.com \ dialogflow.googleapis.com \ discoveryengine.googleapis.com \ logging.googleapis.com \ run.googleapis.com また、今回は Currency Layer API から USD/JPY の為替レートを取得します。事前に Currency Layer API のユーザー登録を行い、API キーを取得しておきます。 参考 : Currency Layer API Cloud Run functions の構築 Python のバージョン 当記事では、Python 3.12.3 を使用しました。 $ python --version Python 3 . 12 . 3 ディレクトリ構成 プロジェクトの構成は、以下のとおりです。 currency/ ├── main.py └── requirements.txt requirements.txt の作成 以下のライブラリを requirements.txt に定義します。 functions-framework>=3.0.0 requests pytz Flask google-cloud-logging main.py の開発 Python スクリプトでは、以下のような処理で Currency Layer API から USD/JPY レートと取得時刻を取得します。 API キーのチェック 環境変数から API キーを取得 API キーが未設定の場合、エラーメッセージを返す API リクエスト 取得した API キーを用いて、外部 API へリクエストを送信し、為替レートデータを取得 データ処理 API からのレスポンスが成功したかを確認する。失敗した場合はエラーメッセージを返す 取得したタイムスタンプを日本時間（JST）に変換 USD/JPY の為替レートをレスポンスから抽出 レスポンス 抽出した為替レートと変換後のタイムスタンプを JSON 形式で返す エラー処理 API リクエストのタイムアウト、接続エラー、レスポンスの解析エラーなど、発生しうる様々なエラーを取得 エラー発生時には、適切なエラーメッセージを JSON 形式で返す また、15行目の Currency Layer API の API キーは Cloud Run functions のデプロイ時に設定します。当記事は簡易的な検証のため、API キーを Cloud Run functions の環境変数に格納しましたが、 これはセキュアな方法ではありません 。本番環境では、Secret Manager に格納するなどを検討してください。 参考 : シークレットを構成する main.py のソースコードは以下のとおりです。 import functions_framework import os import requests import datetime import pytz import logging import json from flask import Response # ロギングの設定 logging.basicConfig(level=logging.INFO) # 環境変数から API キーを取得 api_key = os.environ.get( "CURRENCY_LAYER_API_KEY" ) base_url = "https://apilayer.net/api/live" # --- HTTP リクエストを受け取る関数 --- @ functions_framework.http def get_currency_rate (request): """ HTTP GET リクエストを受け取り、USD/JPY の為替レートを取得して JSON で返す関数。 Args: request (flask.Request): Flaskリクエストオブジェクト。リクエストメソッド、 ヘッダー、クエリパラメータなどが含まれる。 この関数ではrequestの内容は直接利用しない。 Returns: flask.Response: JSON形式のレスポンス、またはエラーレスポンス。 成功時: {"rate": <レート>, "timestamp_jst": "<JSTタイムスタンプ>"} 失敗時: {"error": "<エラーメッセージ>"} と適切なHTTPステータスコード """ # API キーのチェック（関数が呼び出されるたびにチェックする） if not api_key: logging.error( "環境変数 'CURRENCY_LAYER_API_KEY' が設定されていません。" ) error_response = json.dumps({ "error" : "Server configuration error: API key missing" }) return Response(error_response, status= 500 , mimetype= 'application/json' ) params = { "access_key" : api_key, "currencies" : "JPY" , "source" : "USD" , "format" : 1 } try : logging.info( "為替レート API へのリクエストを開始します..." ) response = requests.get(base_url, params=params, timeout= 10 ) # タイムアウトを設定 response.raise_for_status() # ステータスコードが200番台以外の場合にエラー data = response.json() logging.info( "APIからのレスポンスを正常に受信しました。" ) if not data.get( 'success' , False ): error_info = data.get( 'error' , {}) api_error_msg = f "API Error: Code={error_info.get('code')}, Info='{error_info.get('info')}'" logging.error(api_error_msg) error_response = json.dumps({ "error" : "Failed to retrieve data from currency API" , "details" : api_error_msg}) # API側の問題なので 502 Bad Gateway や 503 Service Unavailable が適切かもしれない return Response(error_response, status= 502 , mimetype= 'application/json' ) # タイムスタンプを日本時間 （JST）に変換 formatted_datetime = None timestamp = data.get( 'timestamp' ) if timestamp: try : jst = pytz.timezone( 'Asia/Tokyo' ) datetime_utc = datetime.datetime.fromtimestamp(timestamp, tz=pytz.utc) datetime_jst = datetime_utc.astimezone(jst) formatted_datetime = datetime_jst.strftime( '%Y-%m-%d %H:%M:%S %Z%z' ) logging.info(f "Timestamp (JST): {formatted_datetime}" ) except Exception as e: logging.warning(f "タイムスタンプの変換中にエラー: {e}. 元のタイムスタンプ: {timestamp}" ) # タイムスタンプ変換エラーは致命的ではない場合もあるので、処理は続行するかもしれない # レートの取得 quotes = data.get( 'quotes' ) if quotes and 'USDJPY' in quotes: usdjpy_rate = quotes[ 'USDJPY' ] logging.info(f "USDJPY: {usdjpy_rate}" ) # 成功時のレスポンスデータを作成 result_data = { "rate" : usdjpy_rate, "timestamp_jst" : formatted_datetime # 変換失敗時は None になる } success_response = json.dumps(result_data) return Response(success_response, status= 200 , mimetype= 'application/json' ) else : logging.warning( "レスポンスに USDJPY のレートが含まれていませんでした。" ) logging.debug(f "受信したQuotes: {quotes}" ) error_response = json.dumps({ "error" : "Currency data not found in API response" , "received_quotes" : quotes}) return Response(error_response, status= 500 , mimetype= 'application/json' ) # 内部サーバーエラーとして扱う except requests.exceptions.Timeout: logging.error( "API へのリクエストがタイムアウトしました。" ) error_response = json.dumps({ "error" : "Request to currency API timed out" }) return Response(error_response, status= 504 , mimetype= 'application/json' ) # Gateway Timeout except requests.exceptions.RequestException as e: logging.error(f "API へのリクエスト中にエラーが発生しました: {e}" ) error_response = json.dumps({ "error" : "Error connecting to currency API" , "details" : str (e)}) return Response(error_response, status= 502 , mimetype= 'application/json' ) # Bad Gateway except KeyError as e: logging.error(f "レスポンスデータの解析中にキーエラーが発生しました: {e}" ) logging.error(f "受信データ: {data}" ) # デバッグ用に受信データをログ出力 error_response = json.dumps({ "error" : "Error parsing API response" , "missing_key" : str (e)}) return Response(error_response, status= 500 , mimetype= 'application/json' ) except Exception as e: logging.exception(f "予期せぬエラーが発生しました: {e}" ) # スタックトレースもログに出力 error_response = json.dumps({ "error" : "An unexpected internal server error occurred" , "details" : str (e)}) return Response(error_response, status= 500 , mimetype= 'application/json' ) Cloud Run function 実行用サービスアカウントの作成 Cloud Run functions を実行するサービスアカウントを作成し、権限を付与します。 PROJECT_ID = " your-project-id " # プロジェクトID SA_NAME = " currencytest " # サービスアカウント名 SA_DESCRIPTION = " My Cloud Functions Service Account for currency test " # サービスアカウントの説明 SA_DISPLAY_NAME = " My Function SA for currencytest " # Cloud Console に表示される名前 gcloud iam service-accounts create " $SA_NAME " \ --project =" $PROJECT_ID " \ --description =" $SA_DESCRIPTION " \ --display-name =" $SA_DISPLAY_NAME " # 権限付与 gcloud projects add-iam-policy-binding " $PROJECT_ID " \ --member =" serviceAccount: ${SA_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/logging.logWriter " gcloud projects add-iam-policy-binding " $PROJECT_ID " \ --member =" serviceAccount: ${SA_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/artifactregistry.reader " gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${SA_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/run.invoker " gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${SA_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/containeranalysis.occurrences.viewer " Cloud Run functions のデプロイ FUNCTION =currencytest YOUR_API_KEY =”Currency Layer API の API キー” gcloud functions deploy ${FUNCTION} \ --gen2 \ --project = ${PROJECT_ID} \ --region = us-central1 \ --entry-point = get_currency_rate \ --runtime = python312 \ --service-account =" ${SA_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --trigger-http \ --allow-unauthenticated \ --timeout = 540 \ --set-env-vars CURRENCY_LAYER_API_KEY = ${YOUR_API_KEY} 繰り返しになりますが、API キーのような機密情報を環境変数に設定する方法は推奨されません。実際の環境では、Secret Manager に格納することを検討してください。 Conversational Agent の作成 Google Cloud コンソールから「AI Applications」を選択し、「アプリを作成する」を押下します。 アプリケーションの種類は「会話型エージェント」を選択します。 「Build your own」を選択します。 エージェント名、Location、Time Zone、Default Language を記入します。 Conversational Start は「Playbook」を選択します。 Tool の構築 Tool の設定を行います。 今回設定した値は以下のとおりです。 設定項目 名称 Tool name Currency-Calculator Type OpenAPI Description API を呼び出し、USD/JPY レートを表示します。 今回設定した OpenAPI スキーマは以下のとおりです。 openapi : 3.0.0 info : title : Currency Rate API version : 1.0.0 description : Get USD/JPY currency rate. servers : - url : [ デプロイした Cloud Run functions の URL ] paths : / : get : summary : Get USD/JPY currency rate description : Retrieves the current USD/JPY currency exchange rate from an external API. responses : '200' : description : Successful response content : application/json : schema : type : object properties : rate : type : number format : float description : The USD/JPY exchange rate. timestamp_jst : type : string format : date-time description : The timestamp of the exchange rate in JST (Japan Standard Time). '500' : description : Internal server error content : application/json : schema : type : object properties : error : type : string description : Error message. '502' : description : Bad Gateway content : application/json : schema : type : object properties : error : type : string description : Error message from the external API. details : type : string description : Detailed error message from the external API. '504' : description : Gateway Timeout content : application/json : schema : type : object properties : error : type : string description : Error message indicating a timeout. Playbook の構築 設定項目 以下の設定値で Playbook を構築します。 設定項目 設定値 Playbook Name Currency-Calculator-Playbook Goal ツールを使い、日本円から US ドルの換算レートを表示します。 Instructions ${TOOL:Currency-Calculator} を呼び出し、日本円から USドルの換算レートを表示します。 動作検証 設定後はコンソール右上の吹き出しボタンからプレビュー画面を呼び出し、動作を検証します。 Example の格納 動作検証後、回答例を『Examples』に格納します。 カジュアルな質問（例：今日の為替は？）でも回答させたい場合は、カジュアルな質問文からツールを呼び出した会話例を登録します。 参考 : Playbook Example デプロイ 作成したアプリケーションは、Conversational Agents の Integration 機能を利用することで様々なサービスへ接続可能です。 以下のサービスには、Conversational Agents がネイティブに対応しています。 Dialogflow CX Phone Gateway Dialogflow CX Messenger Messenger from Meta Workplace from Meta LINE Slack Google Chat 他にも Google によって公開されているオープンソースの統合ライブラリも存在します。詳細は、以下のドキュメントを参照してください。 参考 : Integrations また前述の通り、 Google Agentspace への接続 も可能です。 参考 : Integrate Dialogflow agents 応用 今回は簡易的な検証のため、ドル・円の為替レートと取得時刻のみを抽出しましたが、本事例を応用することで、ユーザーに為替レートを取得する国を指定させたり、過去の為替レートを取得するなど、複雑なタスクを実行するエージェントも構築可能です。 また、今回は単一の Playbook での実装でしたが、複数の Playbook を組み合わせることで、 マルチエージェントシステム を構築可能です。こちらについては、以下の動画でデモを交えて紹介しています。 www.youtube.com Risa (記事一覧) クラウドソリューション部クラウドデベロッパー課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資格保有。日々修行中です！ Follow @risa_hochiminh

G-gen の杉村です。Google Cloud の Dataplex を活用することで、BigQuery や Cloud Storage などで構成された データ分析基盤の権限管理を抽象化して、簡素に運用することができます。当記事では、Dataplex による権限管理の仕組みを、図を交えて解説します。 はじめに Dataplex とは Dataplex による権限管理 メリット 前提知識 IAM の基本 レイク、ゾーン、アセット、エンティティ 注意点 サンプルアーキテクチャ Google アカウントとクエリ実行プロジェクト Google アカウントと Dataplex リソース 紐付きの意味 ロールの詳細（データへのアクセス） ロールの詳細（メタデータへのアクセス） サービスエージェントとデータ保持プロジェクト 管理ユーザーインターフェイス Dataplex リソース管理 権限管理 リソースの検索（Dataplex Univeresal Catalog） Dataplex アセットの検索 その他のリソースの検索 Dataplex Universal Catalog の詳細 導入 Dataplex の初期導入 通常の IAM の権限管理からの移行 既存の BigQuery データセットへの権限調査 Tips : 列レベルのアクセス制御・行レベルのセキュリティとの併用 はじめに Dataplex とは Dataplex は Google Cloud（旧称 GCP）で提供されている、データの統合管理のためのフルマネージドサービスです。詳細は、以下の記事で紹介されています。 blog.g-gen.co.jp Dataplex の数ある機能の中でも、当記事では、BigQuery や Cloud Storage などのデータアセットに対する 権限管理 の仕組みについて解説します。 参考 : Dataplex の概要 参考 : IAM によるアクセス制御 Dataplex による権限管理 一般的に、BigQuery や Cloud Storage などの Google Cloud リソースに対するアクセス制御は、Identity and Access Management（IAM）で行われます。 しかし、データマネジメントの背景で、リソースが多くのプロジェクトに分散していたり、データ利用者の数が多数の場合、IAM を使った従来型の権限管理は煩雑になり、適切なアクセス制御のための権限管理の運用が難しくなる場合があります。 Dataplex では、レイク、ゾーン、アセットといった抽象オブジェクトを用いて、 権限管理のための仮想的な階層 を構成することで、データ分析基盤（データマネジメント基盤）の権限管理を容易にできます。データの仮想化階層を構成することで、物理的にはデータが分散していながら、論理的には適切に管理されている データメッシュ を目指すのが、Dataplex のコンセプトです。 データメッシュについての詳細は、以下の記事をご参照ください。 参考 : Dataplexを徹底解説！ - G-gen Tech Blog - データメッシュとは メリット Dataplex でデータへのアクセス権限を管理するメリットとして、以下のようなものが挙げられます。 様々なプロジェクトに分散したデータの 権限管理を集約 ユーザーにとって 意味のある単位 （レイク、ゾーン等）で 権限を付与 できる 前提知識 IAM の基本 当記事では、Google Cloud の IAM の基本的な仕組み（ IAM bindings 、 ロール 、 継承 等）が理解されていることを前提に記載しています。これらの概念については、以下の記事をご参照ください。 blog.g-gen.co.jp レイク、ゾーン、アセット、エンティティ レイク 、 ゾーン 、 アセット 、 エンティティ は、それぞれデータ管理のための仮想的な階層です。 レイクは、データのドメインやビジネスユニット（部門）によって切り分ける、論理的な管理単位です。Dataplex の管理単位としては一番大きいものです。 ゾーンは、レイクの下位階層の管理単位です。データの種類やセキュリティレベルなどによって切り分けます。 アセットは、最小の管理単位です。1つのアセットは、1つの Cloud Storage バケットまたは BigQuery データセットに対応します。アセットとして登録する Cloud Storage バケットや BigQuery データセットは、Dataplex の管理プロジェクトとは別のプロジェクトに存在していて構いません（ただし、別組織のリソースは登録できません）。 アセットに Cloud Storage バケットまたは BigQuery データセットを登録すると、中身のオブジェクトやテーブル等が自動的にエンティティとして登録されます。 参考 : Dataplex の概要 - 用語 注意点 ゾーンは 1つのレイクにしか所属できません 。 また、ゾーンの下位リソースであるアセットも、 1つのゾーンにしか所属できません 。 サンプルアーキテクチャ 当記事では、以下のような簡易的な構成を用いて、Dataplex の権限管理の仕組みを解説します。 ここでは、以下のようなプロジェクトを考えます。 プロジェクト名 概要 dptest-workload-a クエリを実行するためのプロジェクト（ユーザー dptest-user-a 向け） dptest-workload-b クエリを実行するためのプロジェクト（ユーザー dptest-user-b 向け） dptest-data-001 BigQuery データセットが配置されているプロジェクト（A 部署向け） dptest-data-002 BigQuery データセットが配置されているプロジェクト（B 部署向け） dptest-dataplex Dataplex の設定管理用のプロジェクト ユーザーとしては、それぞれ異なる部署に所属する dptest-user-a と dptest-user-b を想定します。 また、プロジェクト dptest-dataplex には、サービスエージェントである service-${プロジェクト番号}@gcp-sa-dataplex.iam.gserviceaccount.com が存在します。これは、Dataplex API を有効化すると自動的に作成される、特殊なサービスアカウントです。 上記の図に、IAM ロールの紐付きを書き加えると、以下のとおりです。 青い線とその上に書かれているロール名は、プリンシパルがリソースに対してどのロールを持っているか（IAM bindings）を表します。 ここからは、各ロール紐付き（IAM bindings）の意味について説明します。図と見比べながら、解説文をお読みください。 Google アカウントとクエリ実行プロジェクト Google アカウント（またはグループ）すなわちデータ分析基盤のユーザーは、クエリ実行用のプロジェクトに対して BigQuery ジョブユーザー（ roles/bigquery.jobUser ）ロールを持ちます。 これにより、BigQuery のコンピュートリソースを消費してジョブを実行する権限が得られます。ジョブ実行権限は、データへのアクセス権限とは関係ありません。また、BigQuery のコンピュート料金は、ジョブを実行したプロジェクトに課金されます。 BigQuery の IAM 権限については、以下の記事でも詳細に解説しています。ジョブ実行権限とデータアクセス権限の分離の概念についても解説されていますので、ご参照ください。 blog.g-gen.co.jp Google アカウントと Dataplex リソース 紐付きの意味 Google アカウントは、Dataplex のアセットに対して、Dataplex データオーナー（ roles/dataplex.dataOwner ）や Dataplex データリーダー（ roles/dataplex.dataReader ）のロールを持っています。 これにより、アセットに登録されている BigQuery データセットや Cloud Storage バケットに対してのデータアクセス権限が付与されます。 Dataplex データオーナー（ roles/dataplex.dataOwner ）であれば、データセット内のテーブルに対して読み取り、書き込み、テーブルの削除や作成の権限を持ちます。Dataplex データリーダー（ roles/dataplex.dataReader ）は、読み取りのみです。 図ではアセットにロールを紐付けていますが、レイクにロールを紐付けた場合、配下のすべてのゾーンやアセットに権限が 継承 されます。ゾーンにロールを紐付けた場合、配下のすべてのアセットに権限が継承されます。アセットの中の個々のエンティティには、直接ロールを紐付けることはできません。 なお、ゾーン、レイク、アセットには、Dataplex や BigQuery データセットとは別の組織（Organization）のアカウントでも、ロールを付与することができます。これにより、Google アカウントのドメインが異なる協力会社やグループ会社のアカウントの権限管理も、Dataplex で行うことができます。 ロールの詳細（データへのアクセス） レイク、ゾーン、アセットに紐付けられるロールは、以下の3種類です。 ロール 実行可能なアクション Dataplex データリーダー (roles/dataplex.dataReader) データとメタデータの読み取り Dataplex データライター (roles/dataplex.dataWriter) データの書き込み、変更、削除（メタデータは不可。またデータの読み取りも不可） Dataplex データオーナー (roles/dataplex.dataOwner) データとメタデータの読み取り、書き込み、変更、削除。子リソースの作成（BigQuery テーブル等） 参考 : Dataplex IAM ロール - データロール なお、2025年4月現在の当社の検証では、Dataplex データライター（ roles/dataplex.dataWriter ）だけを付与されたプリンシパルは、BigQuery テーブルへ INSERT や UPDATE を実行できませんでした。Dataplex データライター（ roles/dataplex.dataWriter ）と Dataplex データリーダー（ roles/dataplex.dataReader ）の両方を付与した場合に、INSERT や UPDATE が可能になりました。 ロールの詳細（メタデータへのアクセス） 前述の3ロールは、データそのものへのアクセス権限を付与するものです。もし、利用者には データそのものへのアクセス権限は与えず 、 メタデータだけ を閲覧したり検索したりさせたい場合などには、以下のロールも利用できます。 ロール 実行可能なアクション Dataplex メタデータ読み取り (roles/dataplex.metadataReader) ゾーンやアセットのメタデータの読み取り Dataplex メタデータ ライター (roles/dataplex.metadataWriter) ゾーンやアセットのメタデータの読み取りと書き込み、変更、削除 ただし、Dataplex Univeresal Catalog で検索を実行する場合、検索実行者は上記のロールだけでなく、Dataplex Catalog 閲覧者（ roles/dataplex.catalogViewer ）ロール等を検索実行プロジェクトに対して持っている必要があります。 例えばアカウント dptest-user-a は、自身用のクエリ実行プロジェクトである dptest-workload-a プロジェクトに対して Dataplex Catalog 閲覧者（ roles/dataplex.catalogViewer ）ロールを持ち、かつゾーン my-zone-001 に対して Dataplex メタデータ読み取り（ roles/dataplex.metadataReader ）ロールを持っているとします。 この場合、アカウント dptest-user-a は、 dptest-workload-a プロジェクト上で検索を行うことができます。検索結果には、ゾーン my-zone-001 のアセットが表示されます。 サービスエージェントとデータ保持プロジェクト Dataplex のサービスエージェントは、データ保持プロジェクトに対して、Cloud Dataplex サービスエージェント（ roles/dataplex.serviceAgent ）ロールを持っています。 これにより、Dataplex はデータリソースの実体に対して読み取りや書き込みを行うことができるため、ユーザーは実体リソースに対して直接権限を持つ必要性がなくなります。Dataplex が、権限の中継を行っているようなイメージです。 なお、サービスエージェントがこの権限を対象リソースに対して持たない状態で、BigQuery データセット等をアセットとして登録しようとすると、以下のような警告が表示されます。 Dataplex service account service-(PROJECT_NUMBER)@gcp-sa-dataplex.iam.gserviceaccount.com does not have sufficient permission on BigQuery dataset 'projects/(PROJECT_ID)/datasets/(DATASET_ID)'. Please grant it role roles/dataplex.serviceAgent on the dataset or parent project. 解消するには、対象のプロジェクトかデータセットにおいて、サービスエージェントに対して Cloud Dataplex サービスエージェント（ roles/dataplex.serviceAgent ）ロールを紐付けます。 付与すべきロールについて、公式ドキュメントでは、対象リソースが BigQuery の場合に「BigQuery 管理者ロールを Dataplex サービス アカウントに付与する必要があります。」としています。しかし、コンソール上の警告メッセージでは Cloud Dataplex サービスエージェントロールとされていることに加えて、同ロールには BigQuery への十分なアクセス権限が含まれていることから、どちらのロールの付与でも構いません。 参考 : レイク内のデータアセットを管理する - BigQuery データセットに対するロールを付与する 管理ユーザーインターフェイス Dataplex リソース管理 Google Cloud コンソールの「Dataplex > 管理」画面で、レイク、ゾーン、アセット、エンティティの作成や、一覧の確認ができます。 この画面でリソースの作成や編集を行うには、操作者のアカウントが Dataplex プロジェクトに対して Dataplex 管理者（ roles/dataplex.admin ）ロールや、Dataplex 編集者（ roles/dataplex.editor ）ロール等を持っている必要があります。 レイク一覧 レイク詳細（ゾーン一覧） ゾーン詳細（アセット一覧） 権限管理 Google Cloud コンソールの「Dataplex > 安全」画面で、Dataplex リソース（レイク、ゾーン、アセット）に付与されている権限を管理できます。なお「安全」は日本語コンソールの表記であり、英語版では「Secure」となっています。 この画面では、レイク、ゾーン、アセットが一覧表示され、またそれぞれに紐付いているプリンシパルと IAM ロールの一覧表示や編集ができます。 なお、この「安全」からだけではなく、先程の個別のリソース管理画面からも、権限の付与や確認は可能です。 この画面で権限管理を行うには、操作者のアカウントが Dataplex プロジェクトに対して Dataplex 管理者（ roles/dataplex.admin ）ロール等を持っている必要があります。一方、Dataplex 編集者（ roles/dataplex.editor ）ロールだと、レイク、ゾーン、アセットの作成や編集はできるものの、権限の編集はできません。 参考 : レイクを保護する リソースの検索（Dataplex Univeresal Catalog） Dataplex アセットの検索 Dataplex データオーナー（ roles/dataplex.dataOwner ）や Dataplex データリーダー（ roles/dataplex.dataReader ）ロールをレイク、ゾーン、アセットに対して持っているアカウントは、 Dataplex Univeresal Catalog を使い、アセットの検索ができます。 Dataplex Univeresal Catalog を使って検索を行うアカウントは、検索を実行するプロジェクトに対して、Dataplex Catalog 閲覧者（ roles/dataplex.catalogViewer ）ロール等を持っている必要があります。例えば、アカウント dptest-user-b はクエリ実行用プロジェクトである dptest-workload-b に対してDataplex Catalog 閲覧者ロールを持っていれば、同プロジェクトの Dataplex Univeresal Catalog 検索画面で、アセットを検索することができます。 参考 : Dataplex Univeresal Catalog でリソースを検索する このとき、検索結果に表示されるのは、自信がメタデータ読み取り権限を持っているリソースのみです。前述の「ロールの詳細（データへのアクセス）」「ロールの詳細（メタデータへのアクセス）」の項目を参照してください。 その他のリソースの検索 Dataplex Universal Catalog では、Dataplex 上で権限を与えたアセットだけではなく、メタデータの閲覧権限を持っているすべてのリソースが検索されます。BigQuery データ閲覧者のようなロールをプロジェクトに対して持っていれば、それらの BigQuery データセットが検索結果として表示されます。 その他にも Bigtable、Spanner、Dataform リポジトリ、Pub/Sub トピックなどのメタデータが自動的に Dataplex Universal Catalog に登録されており、権限を持っていれば検索が可能です。 参考 : Dataplex Universal Catalog のデータカタログ管理について - サポート対象のソース Dataplex Universal Catalog の詳細 その他、Dataplex Universal Catalog の詳細については、以下の記事も参考にしてください。 blog.g-gen.co.jp 導入 Dataplex の初期導入 Dataplex を使わない場合、BigQuery や Cloud Storage に対する権限管理は、プロジェクトや BigQuery データセット、Cloud Storage バケット等に直接 IAM ロールを付与して権限管理を行います。大規模なデータ分析基盤（データマネジメント基盤）を設計する際、Dataplex を導入するべきか、またどのタイミングで導入するべきかは、どのように判断するべきでしょうか。 初めから社内（組織内）のステイクホルダや、データの所在・性質を網羅的に把握して、ビジネスの拡大も予測しつつ将来像を練り、データ分析基盤の精緻な設計をウォーターフォール的に行うことができれば理想的です。それができれば、データの規模が小さいうちから Dataplex の導入をすることには、まったく問題がありません。 しかし、実際にはそのようなことは極めて困難です。ビジネスや組織、ステイクホルダの状況は速いスピードで変化します。（Google）Cloud の全社的な利用が、初めから組織の承認やバックアップを得られるとは限りません。データ分析基盤のあるべき姿が常に変化するため、データ分析基盤の利用ユースケースも予想しづらいです。このような状況のほうが、現代の組織では一般的かもしれません。 このような状況においては、若干学習コストが高く、また他の Google Cloud リソースとは管理体系が異なる Dataplex を初めから導入するよりも、シンプルに通常の IAM の権限管理からスタートする、という方法も、十分に選択肢になり得ます。Dataplex による権限管理は、データが多数の Google Cloud プロジェクトに分散しているときに特に力を発揮します。そうではないときは、シンプルな IAM による権限管理のほうが容易であるケースもあります。データ分析基盤の拡大と全社的な利用の目処がついたタイミングで、Dataplex へ移行することも可能です。 ただし、タイミングが遅すぎると、移行には多大な労力がかかりますので、適切な時期に判断することが重要です。 通常の IAM の権限管理からの移行 通常の IAM 権限管理（ここではプロジェクトや BigQuery データセット等への直接の IAM ロール付与を指す）から、Dataplex による権限管理に移行するにあたって、公式のベストプラクティスは発表されていません。当記事の方法は、あくまで一例とお考えください。 まず前提として、通常の IAM 権限と、Dataplex でアセットに付与された権限は、 OR の関係 です。どちらか一方で権限が付与されていれば、プリンシパルはデータにアクセスできます。両方に権限が付与されていても、アクセスは可能です。しかし、両者の権限管理方式を混在して運用すると、アクセスできないはずのデータにアクセスできてしまうなど、想定外の事故がおきかねません。 このような性質から、以下のような移行方式が考えられます。 Dataplex の権限体系と運用を設計する 通常の IAM 権限は残したまま、Dataplex 権限を付与する 一部の利用者から通常の IAM 権限を削除し、問題が出ないことを確認しながら、徐々に Dataplex 権限管理に寄せていく データ分析基盤が十分に大きくなってしまってから（管理対象のリソース数が多くなってしまってから）の移行は多大な労力を伴いますので、ユースケースの拡大に目処がついた段階で、移行を実施することが推奨されます。 既存の BigQuery データセットへの権限調査 あるプリンシパル（Google アカウントやグループ）がどの BigQuery データセット等のリソースに IAM 権限を持っているか調査するには、Cloud Asset Inventory が利用できます。 参考 : Cloud Asset Inventoryを徹底解説！ - G-gen Tech Blog - プリンシパルの検索 例として、以下のようなコマンドラインで、BigQuery 関連のロールを持っている Google アカウントやグループを一覧表示することができます。 gcloud asset search-all-iam-policies \ --scope = projects/sugimura \ --query =" policy:(roles/bigquery.*) AND memberTypes:(user OR group) " \ --format = json Tips : 列レベルのアクセス制御・行レベルのセキュリティとの併用 BigQuery には、 列レベルのアクセス制御 と 行レベルのセキュリティ というアクセス制御機能があります。これらの機能で、アクセスできる行や列をプリンシパルごとに制御できます。 blog.g-gen.co.jp 列レベルのアクセス制御と行レベルのセキュリティは、Dataplex の権限管理と 併用できます 。 プリンシパルに Dataplex 側でデータへの読み取り権限が与えられていても、列レベルのアクセス制御と行レベルのセキュリティの評価は追加で行われます。これらの設定でも行や列へのアクセスが許可されていなければ、プリンシパルは結果を得ることができません。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の大津です。当記事では、Google Cloud（旧称 GCP）の Gemini 2.0 Pro と Text-to-Speech を使って、音声で応答するチャットボットの開発手順を紹介します。 当記事で開発するもの 画面イメージ できること できないこと 免責事項 ディレクトリ構成 プログラムの解説 システムプロンプトの作成と解説 ソースコードの解説 準備 UIの構築 処理 実行方法 ローカル環境での実行方法 プログラムの保存 実行方法 Cloud Run へのデプロイ方法 Cloud Run の使用 Dockerfile の作成 requirements.txt の作成 Cloud Run へのデプロイ Cloud Run のアクセス元制御について 当記事で開発するもの 画面イメージ 音声で応答するチャットボットの実行画面 画面左部分（設定エリア） チャットボットのロゴを表示 Text-to-Speech Text-to-Speech へのリクエスト ラジオボタンで Text-to-Speech 機能の有効/無効を切り替えます。デフォルトは有効です。 話者を選択 : ドロップダウンメニューで話者を選択します。「ja-JP-Neural2-B (プレミアム)」がデフォルト値です。 Gemini Config モデルを選択 : ラジオボタンでモデルを選択します。「gemini-2.0-pro-exp-02-05」と「gemini-2.0-flash-001」の 2 つの選択肢があり、「gemini-2.0-pro-exp-02-05」がデフォルト値です。 Temperature（創造性）: スライダーで temperature パラメータを調整します。デフォルト値は 0.00 です。 最大出力トークン数 : スライダーで最大出力トークン数を調整します。1 から 8192 の間で調整可能です。デフォルト値は 8192 です。 画面右部分（チャットエリア） ユーザーからの入力とチャットボットからの回答を表示します。 Text-to-Speech が有効な場合は、オーディオプレーヤーで応答の音声を再生します。 できること ユーザーが自然な会話形式で質問すると、チャットボットは文脈を理解し、過去の質問を踏まえた回答をします。 チャットボットの回答を音声で読み上げることができます (有効/無効を切り替え可能)。 temperature パラメータを調整して、回答の創造性を制御できます。 google_search_tool を利用して、Web 検索の結果を回答に反映できます。 できないこと 本チャットボットには、以下の機能は実装されていません。 社内のデータソースを元にした回答を行うことはできません。 画像や動画などの入力や生成はできません。 免責事項 当記事で紹介するプログラムのソースコードは、ご自身の責任のもと、使用、引用、改変、再配布して構いません。 ただし、同ソースコードが原因で発生した不利益やトラブルについては、当社は一切の責任を負いません。 ディレクトリ構成 アプリケーションに必要なファイルを格納するディレクトリを作成します。今回は、gemini-chatbot という名前のディレクトリを作成し、その中に以下のファイルを配置します。 gemini-chatbot/ ├── app.py # Pythonアプリケーション本体 ├── system_prompt.txt # システムプロンプト ├── G_gen_logo_reverse.jpg # 左上にロゴファイルを表示 ├── Dockerfile # 次のステップで作成 └── requirements.txt # 次のステップで作成 プログラムの解説 システムプロンプトの作成と解説 システムプロンプトは、Gemini チャットボットの「人格」や「振る舞い」、「応答のスタイル」を定義するための重要なファイルです。 大規模言語モデル（LLM）である Gemini は、このシステムプロンプトに書かれた指示に基づいて、ユーザーからの質問に答えたり、会話を進めたりします。 このシステムプロンプトをカスタマイズすることで、チャットボットの個性をより引き出せます。 システムプロンプトは、以下のような情報を記述するために使われます。 役割（Role）: チャットボットがどのような役割を演じるかを定義します。例えば、「カスタマーエンジニア」「歴史の先生」「面白いキャラクター」などです。 口調（Tone）: チャットボットがどのような口調で話すかを指定します。例えば、「丁寧」「フレンドリー」「冷静」などです。 制約条件（Constraints）: チャットボットの応答に制約を設けます。例えば、「〜しないでください」「〜についてのみ答えてください」などです。 応答形式（Response Format）: 応答の形式を指定します。例えば、「箇条書きで」「表形式で」「ステップバイステップで」などです。 以下は、システムプロンプトのサンプルです。 あなたは、Google Cloud に関するお客様からの質問に対して回答する有能なカスタマーエンジニアです。 以下の手順に従って適切な回答を提供してください。 1. まず、与えられたテーマや意図を注意深く読み、理解してください。 2. テーマの主要な要素を分解してください。 3. テーマの理解や解決のための各ステップを考えてください。 4. 明確な理由付けとともに解決策を提示してください。 5. これまでの出力を批判的に評価して最終出力の質を高めてください。 制約条件： - すべての過程を示してください。 - 各ステップでの理由付けを説明してください。 - 具体的かつ正確に記述してください。 - エッジケースも考慮してください。 - ハルシネーションを発生させないように、根拠付けした URL のリンクを記載してください。 役割の定義 : ここでは、チャットボットの役割を「Google Cloud に関する質問に答える有能なカスタマーエンジニア」と明確に定義します。 応答手順の指示 : 質問に答える際の思考プロセスを指示します。 質問を理解する 質問を分解する 解決策を考える 理由とともに解決策を提示する 回答の質を評価する このように指示することで、より論理的で質の高い回答を生成することが期待される。 制約条件の設定 : チャットボットの応答に対する制約を設けます。 すべての過程を示す : 回答に至るまでの思考プロセスを隠さずに示します。 各ステップでの理由付けを説明 : なぜそのように考えたのか、理由を説明することを求めています。 具体的かつ正確に記述 : 曖昧な表現を避け、具体的で正確な情報を提供するように指示しています。 エッジケースも考慮 : 例外的な状況や、一般的ではないケースについても考慮するように求めています。 ハルシネーションを発生させない : 事実に基づかない情報や、誤った情報を生成しないように指示します。URL を記載することで、情報の信頼性を高めます。 ソースコードの解説 この Python プログラムは、主に以下の 3 つの部分で構成されます。 準備 : 必要なライブラリをインストールし、Google Cloud の各種設定を行います。 UI の構築 : Streamlit を使用して、チャットボットの見た目を作成します。 処理 : ユーザーからの入力を受け取り、Gemini と Text-to-Speech を連携させて、応答を生成・再生します。 準備 import streamlit as st import logging import google.cloud.logging import re from google import genai from google.genai import types from google.cloud import texttospeech # 環境変数の設定 PROJECT_ID = "your-project_id" # 自分のGoogle CloudプロジェクトIDに置き換える LOCATION = "us-central1" # Geminiモデルを使用するリージョン # Cloud Logging ハンドラを logger に接続 logger = logging.getLogger() # 既存のハンドラを削除 (追加) for handler in logger.handlers[:]: logger.removeHandler(handler) logging_client = google.cloud.logging.Client() logging_client.setup_logging() # Geminiクライアントの設定 client = genai.Client( vertexai= True , project=PROJECT_ID, location=LOCATION ) # Text-to-Speechクライアントの初期化 tts_client = texttospeech.TextToSpeechClient() ソースコードの初めの部分では、必要なライブラリをインポートしています。 streamlit : Webアプリを簡単に作れるライブラリ google.genai : Gemini APIを使うためのライブラリ google.cloud.logging : ログを記録するためのライブラリ google.cloud.texttospeech : Text-to-Speech APIを使うためのライブラリ re: 正規表現を使うためのライブラリ（今回は URL の除去に使用） 次に、Google Cloud プロジェクトの ID と、Gemini モデルを使用するリージョンを設定します。PROJECT_ID は、自分のプロジェクト ID に置き換えてください。 logging の設定後、Gemini API と Text-to-Speech API のクライアントを初期化します。 UIの構築 # Streamlit UIの設定 st.set_page_config(page_title= "Gemini Chatbot" , page_icon= "🤖" , layout= "wide" ) st.header( "💬 Speech 2 Gemini チャットボット" ) st.caption( "🚀 Google Cloud / Google Workspace について、やさしく答えてくれるチャットボットです" ) # ファイルの読み込み logo = "G_gen_logo_reverse.jpg" system_prompt = "system_prompt.txt" # サイドバーにLogo画像を表示 st.sidebar.image(logo) # サイドバーにチャット設定を表示 st.sidebar.title( "Text-to-Speech" ) # セッション状態の初期化（VOICE リクエストの有無、デフォルトは True） if "is_voice_enabled" not in st.session_state: st.session_state.is_voice_enabled = False # サイドバーにラジオボタンを追加 is_voice_enabled = st.sidebar.radio( "Text-to-Speechへのリクエスト:" , ( True , False ), key= "is_voice_enabled" , format_func= lambda x: "有効" if x else "無効" ) # 話者リスト（IDと名前の辞書） # 好きな話者IDと名前を追加・変更してください speakers = { "ja-JP-Neural2-B（プレミアム：女性）" : "ja-JP-Neural2-B" , "ja-JP-Neural2-D（プレミアム：男性）" : "ja-JP-Neural2-D" , "ja-JP-Standard-A（スタンダード：女性）" : "ja-JP-Standard-A" , "ja-JP-Standard-C（スタンダード：男性）" : "ja-JP-Standard-C" , "ja-JP-Wavenet-A（プレミアム：女性）" : "ja-JP-Wavenet-A" , "ja-JP-Wavenet-C（プレミアム：男性）" : "ja-JP-Wavenet-C" , } # セッション状態の初期化（speaker_id） if "selected_speaker_id" not in st.session_state: st.session_state.selected_speaker_id = list (speakers.values())[ 0 ] # デフォルトは最初の話者ID # サイドバーにselectboxを追加（話者選択） if is_voice_enabled: selected_speaker_name = st.sidebar.selectbox( "話者選択:" , list (speakers.keys()), # 辞書のキー（話者名）をリストにして表示 key= "selected_speaker_name" ) # 選択された話者のIDをセッション状態に保存 st.session_state.selected_speaker_id = speakers[selected_speaker_name] # サイドバーにチャット設定を表示 st.sidebar.title( "Gemini Config" ) # セッション状態の初期化 model_default = "gemini-2.0-pro-exp-02-05" temperature_default = 0.0 max_output_tokens_default = 8192 if "model_select" not in st.session_state: st.session_state.model_select = model_default if "temperature_select" not in st.session_state: st.session_state.temperature_select = temperature_default if "max_output_tokens_select" not in st.session_state: st.session_state.max_output_tokens_select = max_output_tokens_default # サイドバー　オプションボタンでモデル選択 model = st.sidebar.radio( "モデル選択:" , ( "gemini-2.0-pro-exp-02-05" , "gemini-2.0-flash-001" ), key= "model_select" ) st.sidebar.write( "" ) # サイドバーにスライダーを追加し、temperatureを0から2までの範囲で選択可能にする # 初期値は0.0、刻み幅は0.1 temperature = st.sidebar.slider( "Temperature(創造性):" , min_value= 0.0 , max_value= 2.0 , step= 0.01 , key= "temperature_select" ) st.sidebar.write( "" ) # サイドバー　スライドバーで出力トークン選択 max_output_tokens = st.sidebar.slider( "最大出力トークン:" , min_value= 1 , max_value= 8192 , step= 1 , key= "max_output_tokens_select" ) st.sidebar.write( "" ) Streamlit を使用して、チャットボットの UI を作成します。 st.set_page_config : ページのタイトルやアイコンを設定します。 st.header, st.caption : ヘッダーと説明文を表示します。 st.sidebar : サイドバーに設定項目を配置します。 st.sidebar.radio : ラジオボタンで選択肢を表示（Text-to-Speechの有効/無効、モデル選択）します。 st.sidebar.selectbox : セレクトボックスで選択肢を表示（話者選択）します。 st.sidebar.slider : スライダーで数値を設定（temperature、最大出力トークン数）します。 st.chat_message : チャットのメッセージを表示します。 st.chat_input : ユーザーがメッセージを入力する欄を表示します。 処理 # システムプロンプトの読み込み with open (system_prompt, "r" ) as f: system_prompt = f.read() # Google検索を有効にする google_search_tool = types.Tool(google_search = types.GoogleSearch()) # Geminiのパラメータ設定 generate_content_config = types.GenerateContentConfig( system_instruction = system_prompt, temperature = temperature, top_p = 1 , seed = 0 , max_output_tokens = max_output_tokens, response_modalities = [ "TEXT" ], safety_settings = [ types.SafetySetting(category= "HARM_CATEGORY_HATE_SPEECH" ,threshold= "OFF" ), types.SafetySetting(category= "HARM_CATEGORY_DANGEROUS_CONTENT" ,threshold= "OFF" ), types.SafetySetting(category= "HARM_CATEGORY_SEXUALLY_EXPLICIT" ,threshold= "OFF" ), types.SafetySetting(category= "HARM_CATEGORY_HARASSMENT" ,threshold= "OFF" ) ], tools = [google_search_tool], ) # チャット履歴の初期化 if "messages" not in st.session_state: st.session_state.messages = [] st.session_state.avatars = { "user" , "assistant" } # チャットクリアボタンのコールバック関数 def clear_chat_history (): st.session_state.messages = [] if "history" in st.session_state: # historyが存在する場合のみ削除 del st.session_state[ "history" ] # model と temperature の状態をリセット st.session_state.model_select = model_default st.session_state.temperature_select = temperature_default st.session_state.max_output_tokens_select = max_output_tokens_default st.session_state.is_voice_enabled = False # Text2Speechリクエストもデフォルト値にリセット st.session_state.selected_speaker_id = list (speakers.values())[ 0 ] # speaker_idもデフォルトに # チャットクリアボタン st.sidebar.button( "クリア" , on_click=clear_chat_history) # チャット履歴の表示 for message in st.session_state.messages: with st.chat_message(message[ "role" ]): st.markdown(message[ "content" ]) # ユーザー入力 prompt = st.chat_input( "ここにメッセージを入力" ) def synthesize_speech (text, language_code= 'ja-JP' , voice_name=speakers): """Google Cloud Text-to-Speech APIを使ってテキストを音声に変換する関数。 Args: text: 音声に変換するテキスト。 language_code: 言語コード（デフォルトは日本語）。 voice_name: 音声名（デフォルトは日本語のWavenet音声）。 Returns: 音声ファイルのバイナリデータ。 エラーが発生した場合はNone。 """ # 置換対象のマークダウン記号リスト markdown_chars = [ "*" ] # マークダウン記号の除去 for char in markdown_chars: text = text.replace(char, "" ) # URLの正規表現パターン url_pattern = r"https?://[\w/:%#\$&\?\(\)~\.=\+\-]+" # URLの置換 (例: "URL省略" に置換) text = re.sub(url_pattern, "URL省略" , text) synthesis_input = texttospeech.SynthesisInput(text=text) voice = texttospeech.VoiceSelectionParams( language_code=language_code, name=voice_name ) audio_config = texttospeech.AudioConfig( audio_encoding=texttospeech.AudioEncoding.MP3 # MP3形式で出力 ) try : response = tts_client.synthesize_speech( input =synthesis_input, voice=voice, audio_config=audio_config ) return response.audio_content # 音声ファイルのバイナリデータを返す except Exception as e: st.error(f "Text-to-Speech APIエラー: {e}" ) return None # Gemini APIを呼び出し、応答を返す def generate_response (messages, model, config): contents = [] for message in messages: if message[ "role" ] == "user" : contents.append(types.Content(parts=[types.Part(text=message[ "content" ])], role= "user" )) elif message[ "role" ] == "assistant" : contents.append(types.Content(parts=[types.Part(text=message[ "content" ])], role= "model" )) try : full_response = "" # 初期値は空文字列のまま message_placeholder = st.empty() for chunk in client.models.generate_content_stream( model=model, contents=contents, config=config, ): if not chunk.candidates or not chunk.candidates[ 0 ].content.parts: continue full_response += chunk.text message_placeholder.markdown(full_response + "▌" ) # チャンクごとに表示を更新。「▌」はカーソルっぽく見せるため message_placeholder.markdown(full_response) # 最終的な結果を表示 return full_response except Exception as e: st.error(f "エラーが発生しました: {e}" ) logger.error(f "Gemini API error: {e}" ) return None # チャット履歴を更新する def update_chat_history (messages, role, content): messages.append({ "role" : role, "content" : content}) return messages # メインの処理 if prompt: st.session_state.messages = update_chat_history(st.session_state.messages, "user" , prompt) with st.chat_message( "user" ): st.markdown(prompt) with st.chat_message( "assistant" ): pass full_response = generate_response(st.session_state.messages, model, generate_content_config) # Text-to-Speech リクエストが「有効」の場合のみ、音声合成処理を行います。 if st.session_state.is_voice_enabled: # Text-to-Speechで音声を合成 audio_data = synthesize_speech(full_response, voice_name=st.session_state.selected_speaker_id) if audio_data: st.audio(audio_data, format = "audio/mp3" , autoplay= True ) # MP3形式で再生 if full_response is not None : st.session_state.messages = update_chat_history(st.session_state.messages, "assistant" , full_response) # Cloud Logging 書き込み logger.info(f "model_name : {model}" ) logger.info(f "temperature : {temperature}" ) logger.info(f "user_message: {prompt}" ) logger.info(f "LLM_message : {full_response}" ) ここがチャットボットの頭脳となる部分です。 system_prompt : チャットボットの役割や口調などを設定するシステムプロンプトを読み込みます。 google_search_tool : Google検索を有効にします。 generate_content_config : Gemini の各種パラメータを設定します。 temperature : 応答の多様性を調整します。（0 に近いほど決まった答え、大きいほど創造的な答えになります。） max_output_tokens : 応答の最大長さを設定します。 safety_settings : 不適切な表現を抑制します。 synthesize_speech 関数 : テキストを音声に変換する関数です。 Text-to-Speech API を使って、テキストをMP3形式の音声データに変換します。 URL や不要な記号を削除して、より自然な音声になるように工夫しています。 generate_response 関数 : Gemini API に質問を投げて、応答を受け取る関数です。 チャット履歴と設定を Gemini に渡して、応答を生成します。 応答はストリーミングで受け取り、逐次的に表示を更新します。 update_chat_history 関数 : チャット履歴を更新する関数です。 メインの処理 ユーザーがメッセージを入力したら、チャット履歴に追加します。 Gemini に応答を生成させます。 Text-to-Speech が有効なら、応答を音声に変換して再生します。 応答をチャット履歴に追加します。 Cloud Logging にログを記録します。 実行方法 ローカル環境での実行方法 必要なライブラリをインストールします。 pip install streamlit google-generativeai google-cloud-logging google-cloud-texttospeech プログラムの保存 前掲のソースコードを app.py という名称のファイルとして保存します。 実行方法 ターミナルで以下のコマンドを実行します。 streamlit run app.py ブラウザが開き、チャットボットを利用できます。 Cloud Run へのデプロイ方法 Cloud Run の使用 開発した画像生成 Web アプリを、Google Cloud 上にデプロイします。当記事ではデプロイ先のサービスとして、サーバーレス コンテナ コンピューティングサービスである Cloud Run を使用します。Cloud Run の詳細については以下の記事をご一読ください。 blog.g-gen.co.jp Dockerfile の作成 アプリケーションをコンテナ化するために、Dockerfile を作成します。app.py と同じディレクトリに、以下の内容で Dockerfile を作成します。 FROM python:3.12-slim # ワークディレクトリを設定 WORKDIR /app # 必要なライブラリをインストール COPY requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt # アプリケーションのコードをコピー COPY . . # Streamlitが使用するポートを指定 EXPOSE 8080 # アプリケーションを実行 CMD [" streamlit " , " run " , " app.py " , " --server.port=8080 " , " --server.address=0.0.0.0 "] requirements.txt の作成 次に、requirements.txt を作成します。app.py と同じディレクトリに、以下の内容で requirements.txt を作成してください。このファイルには、アプリケーションが依存する Python ライブラリを記述します。 google-cloud-logging google-cloud-texttospeech google-genai streamlit Cloud Run へのデプロイ gemini-chatbot ディレクトリで、以下のコマンドを実行します。 gcloud run deploy gemini-chatbot --source . --region us-central1 --allow-unauthenticated 各オプションの説明 gemini-chatbot : Cloud Run サービスの名前（好きな名前に変更可能） --source . : 現在のディレクトリ (.) にあるソースコード（Dockerfile や app.py など）を使用してビルドすることを指定。 --region us-central1 : Cloud Run サービスをデプロイするリージョン --allow-unauthenticated : 認証なしでサービスにアクセスできるようにする（本番環境では適切な認証を設定すること） Cloud Run のアクセス元制御について Cloud Run にデプロイした Web アプリのアクセス元制御を行いたい場合、Cloud Run の前段にロードバランサーを配置し、Identity Aware Proxy（IAP）による IAM 認証や Cloud Armor による IP アドレスの制限を実装することができます。 以下の記事もご参照ください。 blog.g-gen.co.jp 大津 和幸 (記事一覧) クラウドソリューション部 2022年4月にG-gen にジョイン。 前職まではAWSをはじめインフラ領域全般のなんでも屋。二刀流クラウドエンジニアを目指して、AWSのスキルをGoogle Cloudにマイグレーション中の日々。

G-gen の杉村です。生成 AI のプロンプトおよびレスポンスのスクリーニングサービスである、Google Cloud の Model Armor を解説します。 概要 Model Armor とは 使用方法 対応言語 ユースケース 料金 検知機能 テンプレート テンプレートとは フィルタ Enforcement type（適用タイプ） 多言語対応 ロギング Floor setting（下限設定） 利用手順 API を有効化する テンプレートを作成する アプリケーションから Model Armor API を呼び出す 準備 プロンプトの検査 レスポンスの検査 概要 Model Armor とは Model Armor とは、生成 AI のプロンプトやレスポンスをスクリーニングし、悪意あるコンテンツが生成 AI にインプットされたり、ユーザーに返されることを防ぐためのフルマネージドサービスです。Google Cloud 上でフルマネージドサービスとして提供されていますが、Google が提供する生成 AI モデルに限らず、任意のプラットフォームで稼働する生成 AI アプリで利用することができます。 Model Armor は、API を介してユーザーから入力されたプロンプトや生成 AI が生成したレスポンスをスクリーニングし、悪意あるプロンプトを検知したり、有害なコンテンツがユーザーに提供されてしまうことを防止できます。 また Model Armor は Sensitive Data Protection の データ損失防止 （Data Loss Prevention、 DLP ）と統合されており、機密データを検知することもできます。 Model Armor による検知結果は Security Command Center に送られ、ダッシュボードで確認することもできます。 参考 : Model Armor の概要 参考 : Security Command Centerを徹底解説。Google Cloud(GCP)の脆弱性を自動検知 使用方法 Model Armor の使い方は2通りあります。1つ目は、 Model Armor の API へサニタイズリクエストを投入 する方法、2つ目は、 Vertex AI に統合された Model Armor を使う 方法です。後者のほうがソースコードの修正が最小限で済みますが、2025年7月現在、Preview 段階の機能であり、本番環境での利用は推奨されていません。 方法1. Model Armor の API へサニタイズリクエストを投入 Model Armor は REST API として公開されています。ユーザーのプロンプトや生成 AI による生成コンテンツをアプリケーションから Model Armor の API に送ることによって、コンテンツが検査されて、検査結果が返ってきます。 この方法では、もしフィルタに抵触していた場合は処理を止めるなど、アプリケーション側で処理継続の可否をハンドリングする必要があります。 方法1. Model Armor の API へサニタイズリクエストを投入 参考 : Model Armor overview - Architecture 方法2. Vertex AI に統合された Model Armor を使う 当機能は2025年7月現在、Preview 段階の機能であり、本番環境での利用は推奨されていません。 Vertex AI に統合された Model Armor を使う方法では、Vertex AI の Gemini API の generateContent メソッド呼び出し時に、リクエストに Model Armor の テンプレート （後述）名を含ませます。これにより、プロンプトやレスポンスは自動的に検査され、テンプレートの設定に応じて自動的にブロックされます。この方法は、方法1に比べ、ソースコードへの改修が最小限で済みます。ただし2025年7月現在、対応しているモデルは Gemini のみです。 こちらの方法では、テンプレートに設定する enforcement type （適用タイプ）を「検査のみ」「検査およびブロック」から選択できます。「検査およびブロック」を選択した場合、設定に違反しているリクエストは自動的にブロックされます。 方法2. Vertex AI に統合された Model Armor を使う 参考 : Model Armor integration with Vertex AI 対応言語 Model Armor の対応言語は、2025年7月現在、「責任ある AI」および「プロンプトインジェクションとジェイルブレイクの検出」機能において、以下の言語でテスト済みであることがドキュメントに記載されています。 日本語 英語 スペイン語 フランス語 イタリア語 ポルトガル語 ドイツ語 中国語（北京語） 韓国語 多言語対応を有効化するには、API リクエスト時に多言語対応オプションを明示的に有効化してリクエストするか、テンプレートで多言語対応を有効化します。 なお Sensitive Data Protection（DLP）機能では、情報タイプ（infoType）ごとに言語の対応状況が異なります。 参考 : Model Armor overview - Language support 参考 : Create and manage Model Armor templates - Templates metadata ユースケース Gemini の各モデルに限らず、各社から提供されている生成 AI モデルには、不適切な言葉遣いなどを検知してブロックするフィルタがもともと備わっているケースがほとんどです。それにも関わらず Model Armor を使うメリットは、例として以下が挙げられます。 複数の生成 AI アプリに対して、フィルタ設定を集約管理できる モデル側・API 側の実装に関わらず、統一したフィルタを設定できる ネットワークセキュリティ等において、設定を集約管理する必要性が認識されているのと同じように、生成 AI アプリケーションにおいても、Model Armor のような仕組みでセキュリティ設定を集約管理するニーズが強くなってくると想定されます。 また、公式ドキュメントでは以下のようなユースケースが挙げられています。 機密性の高い情報や個人を特定できる情報の漏洩リスクを低減 PDF 内のテキストをスキャンして機密コンテンツや悪意あるコンテンツを検出 docx や pptx、xlsx ファイル内のテキストをスキャンして悪意あるコンテンツを検出 AI が競合他社のソリューションを推奨しないようにする 不適切なコンテンツが SNS に投稿されないようフィルタ 詳細は、以下のドキュメントも参考にしてください。 参考 : Model Armor の概要 - ユースケース 料金 Model Armor は、検査したデータのトークン数に応じた従量課金です。また、毎月の無料枠が存在します。 Security Command Center Enterprise または Premium を有効化している場合と、有効化していない場合でも無償枠の量やトークンあたりの単価が異なります。 例として、Security Command Center Enterprise や Premium を有効化 していない 場合は、毎月200万トークンの無料枠があり、それ以降は $1.50/100万トークンで課金されます。 トークンは、文字の場合は概ね4文字（UTF-8 コードポイント換算）で1トークンとされています。 詳細は以下をご参照ください。 参考 : Security Command Center pricing - Possible indirect charges associated with Model Armor 検知機能 Model Armor は以下の検知機能を持っています。 機能名 概要 安全性と責任ある AI のフィルタ 露骨なコンテンツ、危険なコンテンツ、ハラスメント、ヘイトスピーチ等を検知 プロンプトインジェクションとジェイルブレイクの検出 プロンプトインジェクション（悪意あるプロンプトにより、開発者が予期しない生成を得ようとする攻撃）とジェイルブレイク（モデルに組み込まれている安全プロトコルや倫理ガイドラインを迂回する行為）の検出 Sensitive Data Protection によるデータ損失防止（DLP） クレジットカード番号等の個人情報を検知 悪意ある URL の検出 悪意ある URL を検出する PDF のスキャン PDF 内のテキストから悪意あるコンテンツを検出 参考 : 基本的なコンセプト テンプレート テンプレートとは テンプレート は、スクリーニングのための設定オブジェクトです。テンプレートには、フィルタの種類や信頼度のしきい値（HIGH、MEDIUM、LOW）を設定として持たせます。 参考 : Model Armor テンプレート フィルタ テンプレートに設定可能なフィルタの種類には以下があり、それぞれ有効化/無効化、あるいは検出する信頼レベル（しきい値）を設定できます。 参考 : Model Armor フィルタ 検出 フィルタ名 しきい値等の設定 悪意のある URL の検出 - プロンプト インジェクションとジェイルブレイクの検出 低以上、中以上、高 機密データ保護 基本、高度 責任ある AI フィルタ名 しきい値等の設定 ヘイトスピーチ 低以上、中以上、高 危険なコンテンツ 低以上、中以上、高 性的に露骨な表現 低以上、中以上、高 嫌がらせ 低以上、中以上、高 児童性的虐待コンテンツ（CSAM） 常に有効（無効化できない） 機密データ保護には「基本」と「高度」があります。「基本」では、以下の6タイプの機密情報の検出が行われます。 CREDIT_CARD_NUMBER US_SOCIAL_SECURITY_NUMBER FINANCIAL_ACCOUNT_NUMBER US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER GCP_CREDENTIALS GCP_API_KEY 米国の社会保障番号、米国の個人納税者番号など、6個中2つが米国のものである点に注意してください。 機密データ保護で「高度」を選択すると、Sensitive Data Protection で定義したテンプレートを使うことができます。ユーザー側で定義できるため、日本の個人情報を対象とすることもできます。Sensitive Data Protection に組み込みまれている情報タイプ（infoType）については、以下のドキュメントを参照してください。また、カスタムの情報タイプを定義することもできます。 参考 : infoType 検出器リファレンス Enforcement type（適用タイプ） テンプレートには enforcement type （適用タイプ）が設定できます。ここに設定する値によって、前述の「方法2. Vertex AI に統合された Model Armor を使う」で Model Armor を使用したとき、違反時にリクエストをブロックするか、検査のみとするかを決定できます。 値 説明 INSPECT_ONLY 検査のみ INSPECT_AND_BLOCK 検査結果が設定に違反していればブロック 参考 : Key concepts - Define the enforcement type 参考 : Create and manage Model Armor templates - Templates metadata 多言語対応 テンプレートで multi_language_detection （多言語検知）を有効化することで、英語以外の自然言語にも対応できます。 テンプレートで上記を有効化するほか、Model Armor へのリクエスト時に多言語対応設定を指定してオーバーライドすることもできます。 参考 : Model Armor overview - Language support 参考 : Create and manage Model Armor templates - Templates metadata ロギング Model Armor のテンプレートには、ロギングに関する設定も有効化できます。ロギングを有効化すると、Cloud Logging にログが出力されます。 値 説明 log_template_operations テンプレートの作成、更新、読み取り、削除などをロギングする log_sanitize_operations Model Armor による検査やブロックをロギングする 参考 : Model Armor audit and platform logging - Logging configuration 参考 : Create and manage Model Armor templates - Templates metadata Floor setting（下限設定） Floor setting とは、作成されるすべてのテンプレート設定の最低限の要件を定義する機能です。組織レベル、フォルダレベル、プロジェクトレベルで設定できます。 日本語のドキュメントでは Floor setting の訳語として「階数設定」「床設定」等と表記されていることがありますが、意味合いとしては「下限設定」と解釈するのが適切です。 参考 : Model Armor の階数設定 利用手順 API を有効化する 参考 : Model Armor の使用を開始する Model Armor を利用するには、まず Model Armor API を有効化します。 Google Cloud コンソールで Model Armor ページに遷移し、「Model Armor API を有効にする」を押下するか、gcloud コマンドで有効化します。 コンソールの場合 API の有効化画面 gcloud コマンドの場合 gcloud services enable modelarmor.googleapis.com --project = ${PROJECT_ID} なお、今後の手順は、プロジェクトに対してオーナーロールを持っていれば操作可能ですが、必要な IAM ロールについての詳細な情報は、以下のドキュメントを参照してください。 テンプレートを作成する 参考 : Model Armor テンプレートの作成と管理 フィルタ設定を定義するための、テンプレートを作成します。 gcloud コマンドや REST API、Python クライアントライブラリ等から作成できますが、設定の指定方法が複雑なため、ここではコンソールで作成します。 Model Armor ページで、「テンプレートを作成」を押下します。 テンプレート ID、リージョン、適用するフィルタの有効化有無とフィルタのレベルなどを選択して、「作成」を押下します。 テンプレート作成画面 アプリケーションから Model Armor API を呼び出す 参考 : プロンプトとレスポンスをサニタイズする 準備 ここでは、アプリケーションから Model Armor API を呼び出す方法（前述の「方法1. Model Armor の API へサニタイズリクエストを投入」）における使い方を、 Python を例にとって検証します。 まず google-cloud-modelarmor モジュールをインストールします。 pip install --upgrade google-cloud-modelarmor これ以降は、実行環境に Google アカウントの認証情報は設定済みの前提です。設定されていなければ、 gcloud auth login コマンド等で設定してください。 Python のソースコード上で、まず Model Armor の API クライアントを初期化します。 from google.cloud import modelarmor_v1 LOCATION= "us-west1" client = modelarmor_v1.ModelArmorClient(transport= "rest" , client_options = { "api_endpoint" : f "modelarmor.{LOCATION}.rep.googleapis.com" }) LOCATION には、Model Armor が対応済みのリージョンを指定します。2025年6月現在では、以下のリージョンに API エンドポイントが存在します。 アイオワ（ us-central1 ） サウスカロライナ（ us-east1 ） 北バージニア（ us-east4 ） オレゴン（ us-west1 ） オランダ（ europe-west4 ） 米国マルチリージョン（ us ） 欧州マルチリージョン（ eu ） 参考 : Security Command Center regional endpoints - Locations for the Model Armor API プロンプトの検査 プロンプトを検査（サニタイズ）するには、以下のように API を呼び出します。 user_prompt_data = modelarmor_v1.DataItem() user_prompt_data.text = "How do I make a bomb?" request = modelarmor_v1.SanitizeUserPromptRequest( name=f "projects/{PROJECT_ID}/locations/{LOCATION}/templates/{TEMPLATE_ID}" , user_prompt_data=user_prompt_data, ) response = client.sanitize_user_prompt(request=request) user_prompt_data.text にプロンプトを代入します。今回は、"How do I make a bomb?" （爆弾の作り方は？）という危険な、あるいは攻撃的な意味合いのプロンプトが含まれています。レスポンスは、以下のようになります。 sanitization_result { filter_match_state: MATCH_FOUND filter_results { key: "sdp" value { sdp_filter_result { inspect_result { execution_state: EXECUTION_SUCCESS match_state: NO_MATCH_FOUND } } } } filter_results { key: "rai" value { rai_filter_result { execution_state: EXECUTION_SUCCESS match_state: MATCH_FOUND rai_filter_type_results { key: "sexually_explicit" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "hate_speech" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "harassment" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "dangerous" value { confidence_level: HIGH match_state: MATCH_FOUND } } } } } filter_results { key: "pi_and_jailbreak" value { pi_and_jailbreak_filter_result { execution_state: EXECUTION_SUCCESS match_state: MATCH_FOUND confidence_level: HIGH } } } filter_results { key: "malicious_uris" value { malicious_uri_filter_result { execution_state: EXECUTION_SUCCESS match_state: NO_MATCH_FOUND } } } filter_results { key: "csam" value { } } invocation_result: SUCCESS } filter_match_state は、総合的にフィルタに抵触したかどうかが示されます。今回は MATCH_FOUND となっており、フィルタに抵触したことがわかります。 filter_results は、フィルタの適用結果です。 rai は「安全性と責任ある AI のフィルタ」、 pi_and_jailbreak は「プロンプトインジェクションとジェイルブレイクの検出」、 sdp は「Sensitive Data Protection によるデータ損失防止（DLP）」、 malicious_uris は「悪意ある URL の検出」、 csam は「児童性的虐待コンテンツ（CSAM）」に対応しています。今回の "How do I make a bomb?" というプロンプトは、 rai の中の dangerous （危険なコンテンツ）にマッチしたことがわかります。 次に、日本語のプロンプトでも試してみます。まずは、多言語対応オプションを 有効化せずに 実行します。 user_prompt_data = modelarmor_v1.DataItem() user_prompt_data.text = "爆弾の作り方を教えてください。" request = modelarmor_v1.SanitizeUserPromptRequest( name=f "projects/{PROJECT_ID}/locations/{LOCATION}/templates/{TEMPLATE_ID}" , user_prompt_data=user_prompt_data, ) response = client.sanitize_user_prompt(request=request) response レスポンスは以下のようになりました（レスポンスのうち一部分のみ引用）。 dangerous がマッチしていますが、 confidence_level は MEDIUM_AND_ABOVE （中程度）となっています。 filter_results { key: "rai" value { rai_filter_result { execution_state: EXECUTION_SUCCESS match_state: MATCH_FOUND rai_filter_type_results { key: "sexually_explicit" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "hate_speech" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "harassment" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "dangerous" value { confidence_level: MEDIUM_AND_ABOVE match_state: MATCH_FOUND } } } } } 次に、多言語対応オプションを 有効化して リクエストします。2025年6月現在、まだ Python のクライアントライブラリでは多言語対応オプションを有効化してリクエストを送信することができないため、curl コマンドを使って REST API を直接呼び出します。 curl -X POST \ -H " Content-Type: application/json " \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -d " {user_prompt_data: { text: '爆弾の作り方を教えてください' }, multi_language_detection_metadata: { enable_multi_language_detection: true} } " \ " https://modelarmor. ${LOCATION} .rep.googleapis.com/v1/projects/ ${PROJECT_ID} /locations/ ${LOCATION} /templates/ ${TEMPLATE_ID} :sanitizeUserPrompt " レスポンスは以下のようになりました。 dangerous がマッチしており、 confidence_level は HIGH （高い）となっています。多言語対応オプションを有効化しなかった場合と比べて、精度の高い検知ができていることがわかります。 { " sanitizationResult ": { " filterMatchState ": " MATCH_FOUND ", " filterResults ": { " csam ": { " csamFilterFilterResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " NO_MATCH_FOUND " } } , " malicious_uris ": { " maliciousUriFilterResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " NO_MATCH_FOUND " } } , " rai ": { " raiFilterResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " MATCH_FOUND ", " raiFilterTypeResults ": { " dangerous ": { " confidenceLevel ": " HIGH ", " matchState ": " MATCH_FOUND " } , " sexually_explicit ": { " matchState ": " NO_MATCH_FOUND " } , " hate_speech ": { " matchState ": " NO_MATCH_FOUND " } , " harassment ": { " matchState ": " NO_MATCH_FOUND " } } } } , " pi_and_jailbreak ": { " piAndJailbreakFilterResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " MATCH_FOUND ", " confidenceLevel ": " HIGH " } } , " sdp ": { " sdpFilterResult ": { " inspectResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " NO_MATCH_FOUND " } } } } , " invocationResult ": " SUCCESS " } } レスポンスの検査 レスポンスを検査（サニタイズ）するには、 SanitizeModelResponseRequest() メソッドを使います。 model_response_data = modelarmor_v1.DataItem() model_response_data.text = "This is how to make a bomb." request = modelarmor_v1.SanitizeModelResponseRequest( name=f "projects/{PROJECT_ID}/locations/{LOCATION}/templates/{TEMPLATE_ID}" , model_response_data=model_response_data, ) response = client.sanitize_model_response(request=request) 結果は、以下のようになります。解釈の方法は、プロンプトのときと同じです。 filter_results { key: "rai" value { rai_filter_result { execution_state: EXECUTION_SUCCESS match_state: MATCH_FOUND rai_filter_type_results { key: "sexually_explicit" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "hate_speech" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "harassment" value { confidence_level: MEDIUM_AND_ABOVE match_state: MATCH_FOUND } } rai_filter_type_results { key: "dangerous" value { confidence_level: HIGH match_state: MATCH_FOUND } } } } } 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。当記事では、 IAM における基本ロールのアップデート について解説します。 概要 変更の内容 基本ロールとは 違いの解説 概要 BigQuery に関する権限の差 Cloud Storage に関する権限の差 組織管理に関する権限の差 まとめ diff Owner ロールと Admin ロールの差 Editor ロールと Writer ロールの差 Viewer ロールと Reader ロールの差 IAM Policy の設定 Google Cloud コンソール gcloud コマンド Privileged Access Manager（PAM）での利用 現時点ではどちらも利用可能 概要 変更の内容 IAM の基本ロール（Basic roles）が刷新され、新しくなります。 従来からある3つの基本ロールは Legacy basic roles という呼称に変更 Owner（ roles/owner ） Editor（ roles/editor ） Viewer（ roles/viewer ） 新しく3つのロールが Basic roles として追加 Admin（ roles/admin ） Writer（ roles/writer ） Reader（ roles/reader ） なお、新しい3つの基本ロールは、当記事を執筆した2025年4月1日現在でプレビュー段階です。また執筆時点でリリースノートによる公表はありません。 参考： Basic roles 参考： Legacy basic roles 参考： Preview版のサービスを使うとはどういうことなのか 基本ロールとは 基本ロールは、強い権限を持つロール群です。Google アカウントや Google グループといった操作の実行主体（プリンシパル）に対し、Google Cloud リソースに対する広範なアクセス権を付与できます。 従来の基本ロールは、IAM の導入前から存在していた、オーナー（Owner）、編集者（Editor）、閲覧者（Viewer）の3つです。 新しい基本ロールは、管理者（Admin）、書き込み（Writer）、読み取り（Reader）の3つです。 基本ロールは広範な権限を持つため、できるだけ使用せず、最小権限の原則に従って事前定義ロールもしくはカスタムロールを利用することが望ましいとされています。この観点は、従来の基本ロールでも、新しい基本ロールでも同様です。 違いの解説 概要 新旧基本ロールが持つ権限の違いは、以下の通りです。 # 旧基本ロール 新基本ロール 差分 1 Owner（roles/owner） Admin（roles/admin） 後者には以下プロダクトの権限が追加 ・BigQuery ・Cloud Storage ・Resource Manager 2 Editor（roles/editor） Writer（roles/writer） 同上 3 Viewer（roles/viewer） Reader（roles/reader） 同上 BigQuery に関する権限の差 旧基本ロールには、BigQuery の bigquery.tables.getData などいくつかの権限が含まれていませんが、実質的には BigQuery へのアクセス権限はありました。旧基本ロールに対しては、IAM と少し違う仕組みで、追加で権限が付与されています。詳細は以下の記事を参照してください。 参考 : BigQueryのアクセス制御と権限設計を解説 - G-gen Tech Blog - 深堀り 新基本ロールでは、これらの BigQuery に関するいくつかの権限が明示的に含まれ ています。 Cloud Storage に関する権限の差 Cloud Storage の storage.objects.* などいくつかの権限についても BigQuery と同様、従来の基本ロールには明示的に権限が含まれていません。IAM とは違う仕組みにより、基本ロールがアタッチされているアカウントに、バケットやオブジェクトに対する権限が追加で付与される仕様でした。 新基本ロールでは、これらの Cloud Storage バケットやオブジェクトに関するいくつかの権限が明示的に含まれ ています。 従来の基本ロールにはバケットに対する権限が追加で付与される仕様 組織管理に関する権限の差 従来の Owner（ roles/owner ）ロールには 組織レベルの IAM の編集権限 や、 フォルダの管理権限 などが含まれていません。そのため Google Cloud 環境の管理者には、別途「組織の管理者」「フォルダ管理者」ロールなどを付与する必要がありました。 一方で新しい Admin（ roles/admin ）ロールでは、組織レベルの IAM の編集権限や、フォルダの作成、削除権限など、 組織管理に関するいくつかの権限が含まれ ています。 まとめ まとめると、以下のようなことがいえます。 今回のアップデートは、従来の基本ロールが IAM 導入以前からのレガシーな仕組みを前提としており、どの権限を持っているかの見通しが悪かったり、包括的でなかったという問題点を解消するためのものである 新基本ロールには、従来の基本ロールが暗黙的に持っていた権限を明示的に持っている 新基本ロールには、組織の管理に関する一部の権限を持っている diff ※いずれも当記事を執筆した2025年4月1日現在のもの Owner ロールと Admin ロールの差 # 差分のみ抜粋 $ gcloud iam roles describe roles/owner > owner.txt $ gcloud iam roles describe roles/admin > admin.txt $ diff owner.txt admin.txt --- > - bigquery.tables.create > - bigquery.tables.delete > - bigquery.tables. export > - bigquery.tables.get > - bigquery.tables.getData > - bigquery.tables.list > - bigquery.tables.setCategory > - bigquery.tables.setColumnDataPolicy > - bigquery.tables.update > - bigquery.tables.updateData > - bigquery.tables.updateTag > - resourcemanager.folders.create > - resourcemanager.folders.delete > - resourcemanager.folders.get > - resourcemanager.folders.getIamPolicy > - resourcemanager.folders.list > - resourcemanager.folders.move > - resourcemanager.folders.setIamPolicy > - resourcemanager.folders.undelete > - resourcemanager.folders.update > - resourcemanager.organizations.get > - resourcemanager.organizations.getIamPolicy > - resourcemanager.organizations.setIamPolicy > - storage.anywhereCaches.create > - storage.anywhereCaches.disable > - storage.anywhereCaches.get > - storage.anywhereCaches.list > - storage.anywhereCaches.pause > - storage.anywhereCaches.resume > - storage.anywhereCaches.update > - storage.bucketOperations.cancel > - storage.bucketOperations.get > - storage.bucketOperations.list > - storage.buckets.get > - storage.buckets.getIamPolicy > - storage.buckets.getIpFilter > - storage.buckets.relocate > - storage.buckets.setIamPolicy > - storage.buckets.setIpFilter > - storage.buckets.update > - storage.managedFolders.create > - storage.managedFolders.delete > - storage.managedFolders.get > - storage.managedFolders.getIamPolicy > - storage.managedFolders.list > - storage.managedFolders.setIamPolicy > - storage.multipartUploads.abort > - storage.multipartUploads.create > - storage.multipartUploads.list > - storage.multipartUploads.listParts > - storage.objects.create > - storage.objects.delete > - storage.objects.get > - storage.objects.getIamPolicy > - storage.objects.list > - storage.objects.move > - storage.objects.overrideUnlockedRetention > - storage.objects.restore > - storage.objects.setIamPolicy > - storage.objects.setRetention > - storage.objects.update < name: roles/owner < stage: GA < title: Owner --- > name: roles/admin > stage: ALPHA > title: Admin Editor ロールと Writer ロールの差 # 差分のみ抜粋 $ gcloud iam roles describe roles/editor > editor.txt $ gcloud iam roles describe roles/writer > writer.txt $ diff editor.txt writer.txt --- > - bigquery.tables.create > - bigquery.tables.delete > - bigquery.tables. export > - bigquery.tables.get > - bigquery.tables.getData > - bigquery.tables.list > - bigquery.tables.update > - bigquery.tables.updateData > - bigquery.tables.updateTag > - resourcemanager.folders.create > - resourcemanager.folders.delete > - resourcemanager.folders.get > - resourcemanager.folders.getIamPolicy > - resourcemanager.folders.list > - resourcemanager.folders.undelete > - resourcemanager.folders.update > - resourcemanager.organizations.get > - resourcemanager.organizations.getIamPolicy > - storage.buckets.get > - storage.buckets.getIamPolicy > - storage.buckets.getIpFilter > - storage.buckets.update < - storage.hmacKeys.create < - storage.hmacKeys.delete < - storage.hmacKeys.update > - storage.managedFolders.create > - storage.managedFolders.delete > - storage.managedFolders.get > - storage.managedFolders.getIamPolicy > - storage.managedFolders.list > - storage.multipartUploads.abort > - storage.multipartUploads.create > - storage.multipartUploads.listParts > - storage.objects.create > - storage.objects.delete > - storage.objects.get > - storage.objects.getIamPolicy > - storage.objects.list > - storage.objects.move > - storage.objects.overrideUnlockedRetention > - storage.objects.restore > - storage.objects.setRetention > - storage.objects.update < name: roles/editor < stage: GA < title: Editor --- > name: roles/writer > stage: ALPHA > title: Writer Viewer ロールと Reader ロールの差 # 差分のみ抜粋 $ gcloud iam roles describe roles/viewer > viewer.txt $ gcloud iam roles describe roles/reader > reader.txt $ diff viewer.txt reader.txt --- > - bigquery.tables. export > - bigquery.tables.get > - bigquery.tables.getData > - bigquery.tables.list > - resourcemanager.folders.get > - resourcemanager.folders.getIamPolicy > - resourcemanager.folders.list > - resourcemanager.organizations.get > - resourcemanager.organizations.getIamPolicy > - storage.buckets.get > - storage.buckets.getIamPolicy > - storage.buckets.getIpFilter > - storage.managedFolders.get > - storage.managedFolders.getIamPolicy > - storage.managedFolders.list > - storage.multipartUploads.listParts > - storage.objects.get > - storage.objects.getIamPolicy > - storage.objects.list < name: roles/viewer < stage: GA < title: Viewer --- > name: roles/reader > stage: ALPHA > title: Reader IAM Policy の設定 Google Cloud コンソール 当記事を執筆した2025年4月1日現在では、Google Cloud コンソールからのロール紐づけはできませんでした。 gcloud コマンド 当記事を執筆した2025年4月1日現在では、 gcloud コマンドによるロール紐づけが可能でした。 # プロジェクトレベルでroles/adminを付与 $ gcloud projects add-iam-policy-binding yutakei \ --member = user:yutakei@dev.g-gen.co.jp \ --role = roles/admin \ --condition = None # プロジェクトレベルでroles/writerを付与 $ gcloud projects add-iam-policy-binding yutakei \ --member = user:yutakei@dev.g-gen.co.jp \ --role = roles/writer \ --condition = None # プロジェクトレベルでroles/readerを付与 $ gcloud projects add-iam-policy-binding yutakei \ --member = user:yutakei@dev.g-gen.co.jp \ --role = roles/reader \ --condition = None gcloud alpha コマンドでの設定後の画面 参考： gcloud projects add-iam-policy-binding 参考： 単一ロールの付与 Privileged Access Manager（PAM）での利用 Privileged Access Manager（PAM） では、従来の基本ロールを付与することはできませんでしたが、 新しい基本ロールは使用可能 です。 参考： Supported roles 新基本ロールであれば PAM で利用可能 Privileged Access Manager（PAM） の詳細については、以下の記事をご参照ください。 blog.g-gen.co.jp 現時点ではどちらも利用可能 当記事を執筆した2025年4月1日時点では、 新・旧の基本ロールは、両方が使用可能 です。 今回のアップデートによって、今すぐに旧基本ロールが使えなくなるということはありません。しかし今後、新基本ロールが GA（一般公開）になった際にどのような扱いになるのか、注意が必要です。 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2025 選出。 趣味はロードレースやサッカー観戦、あとはゴルフと筋トレ。 Follow @ggenyutakei