当記事は、ライオン株式会社様と株式会社G-genの 技術情報発信コラボレーション企画 『SAPと連携するデータ分析基盤の実践とTips』で執筆されたものです。 はじめに 当企画について 当記事について 目的と位置づけ、ユースケース なぜ分析環境が必要なのか？ データ基盤における分析環境の位置づけ 分析環境のユースケース Notebook 環境のアーキテクチャ Vertex AI Workbench の利用 Google Cloud サービスへのプライベートアクセス JupyterLab のための追加設定 外部サービスへのアクセス設定 バッチ処理のためのアーキテクチャ まとめ はじめに 当企画について 当記事は株式会社 G-gen 様とライオン株式会社の技術ブログ相互寄稿企画で執筆されたものです。ライオン側からは、 G-gen 様のご協力のもと、Google Cloud 環境に構築を進めているデータ基盤に関連した以下3つの記事をシリーズでお届けします。 ライオンのデータ基盤構築とSAPデータ活用体制 ライオンのデータマネジメント ライオンのデータ基盤における分析環境 👈 当記事 G-gen Tech Blog の記事一覧 blog.g-gen.co.jp LION Digital Inside の記事一覧 zenn.dev 当記事について ライオン株式会社にてデータ基盤まわりを担当しているフクヤマです。 当記事では、部署横断での安全なデータ共有とデータドリブン文化の定着を目的として、データマート（DM）層に部門単位の Google Cloud プロジェクトを用意し、Vertex AI Workbench を中核としたセキュアな分析環境を構築した事例を紹介します。 事例紹介の中で、VPC Service Controls 配下で外部 IP アドレスを持たずに BigQuery などへアクセスする設定や、Notebook をバッチ実行するための構成について解説します。 目的と位置づけ、ユースケース なぜ分析環境が必要なのか？ データ基盤に集約されたデータを迅速かつセキュアに活用するためには、ユーザ専用の分析環境が必要です。この環境を構築することにより、以下のようなメリットを期待しています。 部署横断的な活用の促進 異なる部門間でデータを共有し、共通の基盤のもとで意思決定を行うことで、組織全体の生産性向上に寄与 データドリブンな文化の醸成 ユーザが主体的にデータ活用できる環境を整備することによる、組織全体へのデータドリブンな文化の浸透、および現場レベルでの改善活動の一層の促進 セキュアな環境での実験と開発 VPC Service Controls などのセキュリティ技術を活用し、安心して分析や機械学習の実験が行える環境を提供 データ基盤における分析環境の位置づけ 当社のデータ基盤では、レイヤー構造で環境を分離しており、役割と管轄を明確化しています（詳細は 当社1つ目の記事 を参照）。この構成に従い、分析環境は DM 層に整備することになります（Figure 1）。ここでいう環境は、1つの Google Cloud プロジェクトを指しており、部門ごとあるいは業務プロジェクトごとに作成することを想定しています。 Figure 1: データ基盤における分析環境の位置づけ 分析環境においては、データ基盤に存在するデータ、具体的にはデータレイク（DL）層またはデータウェアハウス（DWH）層に位置するプロジェクトのデータに対しては参照のみを許可しています。分析者はこれらのデータを主に Notebook から参照のうえ、必要な処理・分析を実施します。処理済みのデータは必要に応じて分析環境上のテーブルとして保管され、活用されます（e.g. BIツールによる可視化）。 分析環境のユースケース 当社ではデータサイエンティストから分析専門職以外の一般ユーザにまで、分析環境を提供することを想定しています。それぞれの環境のユースケースとしては、おおまかに以下を想定しています（Table 1）。 Table 1: ユーザごとの分析環境のユースケース No ユーザ ユースケース 主な利用サービス 1 データサイエンティスト ・Notebook 環境で Python を使った次の処理 ・アドホック分析 ・機械学習モデル構築 ・バッチ処理（スケジュール実行） ・コード管理 ・BigQuery ・Vertex AI ・Artifact Registory ・Cloud Run ・Cloud Storage 2 データアナリスト ・SQLを活用したダッシュボード・レポーティングの作成 ・データ探索によるインサイト抽出 ・BigQuery ・Looker 3 一般ユーザ ・ダッシュボード・定型レポートの閲覧 ・業務指標のモニタリング （・SQL活用） ・BigQuery ・Looker 当記事では上記のうち、データサイエンティストの分析環境について紹介します。 Notebook 環境のアーキテクチャ Vertex AI Workbench の利用 データサイエンティストが試行錯誤しながらデータ分析をしたり、機械学習モデルを開発する環境としては、 Notebook （ Jupyter 環境）が必要です。Notebook の利用にあたり、当社では大きく以下の2つの要件があり、これらを満たすため、 Vertex AI Workbench を利用することに決めました（Figure 2）。 要件1. ユーザーが日常的に Python でデータ探索・分析を行うこと 要件2. ユーザ管理の VPC 内に環境を配置したうえで、VPC Service Controls（以降、VPC SC）を利用して企業データのセキュリティレベルを確保すること Notebook 環境を利用できるサービスとしては、Colab Enterprise や Cloud Dataproc もありますが、要件を満たさなかったため候補から外れました。Colab Enterprise は要件2を満たさず、Cloud Dataproc は大規模分散処理や Spark 利用が前提であれば有力な選択肢となるが要件1の観点でオーバースペックだったためです。 Figure 2: データサイエンティスト向け分析・モデル開発環境 設計上のポイントは、VPC SC のサービス境界（Service Perimeter）により、Vertex AI をはじめ、本環境で利用するサービスの全てが保護されることです。この保護機能によりデータの漏洩防止対策が充実する一方で、設計で考慮すべきことがいくつか出てきます。 Google Cloud サービスへのプライベートアクセス Vertex AI Workbench インスタンス（以降、Workbench インスタンス）からは、様々な理由で他の Google Cloud サービスにアクセスする必要があります。代表的なケースは、分析対象のデータを参照するために、BigQuery や Cloud Storage にアクセスするといったものです。 当社の場合、Workbench インスタンスには外部 IP アドレスを持たせていないため、別の Google Cloud サービスにアクセスする際にはインターネットを経由せずにアクセスする必要がありました。この場合、アクセス対象が VPC SC にサポートされている Google Cloud API に限定されていれば、限定公開の Google アクセス（Private Google Access）と restricted.googleapis.com VIP を組み合わせたプライベートアクセス方式を採用することでセキュアにアクセスできることがわかり、この方式を採用しました。 設定方法の詳細は、以下の記事が参考になりました。Cloud DNS については、デフォルトドメイン（ *.googleapis.com ）を restricted.googleapis.com に向ける設定にしています。 blog.g-gen.co.jp JupyterLab のための追加設定 VPC SC のサービス境界によって保護されている Workbench インスタンスについて、前述のように外部 IP アドレスを持たない、かつ Google Cloud API へのパブリックアクセスを許可していない場合は、JupyterLab をブラウザ上で起動するために追加の設定が必要となります。 なぜなら、そのような Workbench インスタンスは VPC ネットワークの外部にあるサービスエンドポイントにアクセスする必要があるからです。具体的には、 restricted.googleapis.com VIP を利用するサービスエンドポイントとして、DNS に以下のドメインを追加で設定する必要があります。 notebooks.googleapis.com *.notebooks.cloud.google.com *.notebooks.googleusercontent.com 詳細は以下の公式ドキュメントをご覧ください。 参考 : Vertex AI Workbench インスタンスを作成する - ネットワーク構成オプション 外部サービスへのアクセス設定 本記事のメインテーマではありませんが、ソースコード管理ツールなどの外部サービス（Github、PyPI、Docker など）へのアクセスについて補足です。 今回はインスタンスに外部 IP アドレスを持たせないため、Cloud NAT でアウトバウンド通信をさせています。また、通信制御は Cloud NGFW の FQDN オブジェクトを利用して、対象サービスの FQDN に対してのみアウトバウンド通信を許可することで、不要な外部通信を排除しています。 バッチ処理のためのアーキテクチャ 当社のデータ分析基盤では、分析やデータ活用のため、バッチ処理を定期実行（スケジュール実行）させる要件があります。データサイエンティストから、Notebook に記述したプログラムをそのままバッチ処理として実行したいというニーズが挙がったため、スクリプトを新しく記述してワークフロー化することは見送り、Notebook 上のプログラムをバッチ処理として実行する方法を検討しました。 調査したところ、Vertex AI Workbench には Notebook のスケジュール実行（ エグゼキュータ ）機能が備わっていることを発見し、これで一件落着！・・・と思いきや、調査を進めたところ、エグキュータ機能は VPC SC 下ではサポートされていないことが判明しました。試行錯誤するなかでドキュメントを読み漁ったところ、公式ドキュメントに、以下の記載を見つけました。 In instances that use VPC Service Controls, use of the executor isn't supported. 参考 : Introduction to Vertex AI Workbench - Limitations すなわち、エグゼキュータは VPC SC 環境下では利用できないことが判明しました。気を取り直して代替手段を調査したところ、VPC SC 配下でバッチ処理をスケジュール実行する際のベストプラクティスとして、Cloud Scheduler、Cloud Run services、Cloud Run jobs を組み合わせた方法を発見しました。 参考 : ベスト プラクティス: スケジュールされたジョブを VPC Service Controls の境界で実行する 上記のドキュメントを参考に、Notebook ファイルをバッチ実行するための OSS である papermill を組み込んだ Docker コンテナを Cloud Run jobs として登録することで、ひとまず目的としたジョブのバッチ処理が実現できました。 まとめ 当記事では、ライオンのデータ基盤における分析環境について、主にデータサイエンティスト向け環境の概要をご紹介しました。 今後はより広範な業務ユーザや非エンジニアの分析ニーズに応えるため、Google Cloud の提供する生成 AI 機能のを積極的に導入するなどして、専門知識のないユーザでも自然言語で問い合わせてデータの取得やレポート作成などが行える環境を整備し、データ分析への参入障壁の軽減にも挑戦したいです。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、2021年よりクラウドの導入から最適化までを支援しているGoogle Cloud専業のクラウドインテグレーターです。

記事の移行について 当記事は移行しました Google Workspace Flows は、日本時間2025年12月4日に Google Workspace Studio に名称を変更して一般公開されました。 これに伴い、Google Workspace Studio についての解説記事は、以下のページに移行されています。 blog.g-gen.co.jp window.addEventListener('DOMContentLoaded', () => { const canonicalUrl = "https://blog.g-gen.co.jp/entry/google-workspace-studio-explained"; let canonicalLink = document.querySelector('link[rel="canonical"]'); if (!canonicalLink) { canonicalLink = document.createElement('link'); canonicalLink.setAttribute('rel', 'canonical'); document.head.appendChild(canonicalLink); } canonicalLink.setAttribute('href', canonicalUrl); });

G-gen の佐々木です。当記事では、Cloud Run jobs で実行されるジョブのエラー通知を、 Cloud Logging と Cloud Monitoring で作成します。リソースの作成には IaC である Terraform を使用します。 はじめに アラートのリソース構成 Terraform コード全文 バージョン定義 リソース定義 Terraform コード解説 ローカル変数 ログベースの指標 通知チャンネル アラートポリシー 動作確認 はじめに Cloud Run jobs は Google Cloud のサーバーレス コンテナ コンピューティング サービスである Cloud Run の実行モデルの1つであり、コンテナ化されたバッチジョブの長時間実行に特化したサービスです。 サーバーレス、つまりユーザーによるインフラの管理を必要とせず、またコンテナ化されていればランタイムを問わずバッチジョブを実行することができます。 Cloud Run jobs は非常に扱いやすい強力なサービスですが、ジョブ実行が失敗したときなど、ユーザーへの何かしらの通知を実装したい場合には、別途モニタリングの仕組みを構成する必要があります。 当記事では、Google Cloud のモニタリングサービスである Cloud Logging および Cloud Monitoring を使用することで、Cloud Run jobs のジョブ実行失敗をメール通知する仕組みを構成していきます。 各サービスの詳細な解説は以下の記事をご一読ください。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp アラートのリソース構成 Cloud Run jobs は、ジョブ実行の失敗時にエラーログを出力します。 当記事では、Cloud Logging に記録されたエラーログを Cloud Monitoring の ログベースの指標 として取り込み、 アラートポリシー を使用してアラートの通知を送信します。 ログベースの指標とアラートポリシーを使用したアラート通知の構成 Terraform コード全文 バージョン定義 当記事で使用する Terraform および Terraform の Google Cloud プロバイダのバージョンは以下の通りです。 # versions.tf terraform { required_version = ">= 1.13" required_providers { google = { source = "hashicorp/google" version = ">= 7.7" } } } リソース定義 アラート通知のために以下の3つのリソースを定義します。 ログベースの指標 通知チャンネル アラートポリシー なお、モニタリングの対象となる Cloud Run ジョブはすでに作成してあるものとします。 リソース定義の詳細は後ほど解説していきます。 # monitoring.tf locals { project_id = "sample-project" location = "asia-northeast1" job_name = "sample-job" notification_email = "sample@g-gen.co.jp" } # ログベースの指標 resource "google_logging_metric" "this" { project = local.project_id name = "error_metric_for_$ { local.job_name } " # Cloud Logging のクエリを定義 filter = <<-EOT severity>=ERROR resource.type="cloud_run_job" resource.labels.job_name="$ { local.job_name } " resource.labels.location="$ { local.location } " logName=~"cloudaudit.googleapis.com%2Fsystem_event" EOT metric_descriptor { metric_kind = "DELTA" value_type = "INT64" } } # 通知チャンネル resource "google_monitoring_notification_channel" "this" { project = local.project_id display_name = "ジョブエラー通知用メールアドレス" type = "email" force_delete = false labels = { email_address = local.notification_email } } # アラートポリシー resource "google_monitoring_alert_policy" "this" { project = local.project_id display_name = "Error Alert for $ { local.job_name } " # アラートの表示名 combiner = "OR" severity = "ERROR" # アラートの重大度（CRITICAL / ERROR / WARNING） enabled = true notification_channels = [ google_monitoring_notification_channel.this.id ] conditions { display_name = "Error Condition for $ { local.job_name } " condition_threshold { # filterのmetric.typeにログベースの指標を指定（resource.typeの指定も必須） filter = "resource.type=\"cloud_run_job\" AND metric.type=\"logging.googleapis.com/user/$ { google_logging_metric.this.name } \"" comparison = "COMPARISON_GT" # threshold_value の値よりも大きいときにアラート作成 threshold_value = 0 aggregations { alignment_period = "60s" per_series_aligner = "ALIGN_COUNT" } duration = "60s" # ログベースの指標にデータがないときにアラートを止める evaluation_missing_data = "EVALUATION_MISSING_DATA_INACTIVE" } } alert_strategy { # アラート作成時のみ通知を送信する notification_prompts = [ "OPENED" ] } documentation { subject = "ジョブ($${resource.label.job_name})の実行に失敗しました" content = <<-EOT ## Google Cloudプロジェクト $${resource.label.project_id} ## Cloud Runジョブ名 $${resource.label.job_name} ## アラートの説明 Cloud Runジョブ**($${resource.label.job_name})**の実行に失敗しました。 ジョブの実行ログおよびTerraformテンプレートの設定値を確認してください。 EOT mime_type = "text/markdown" } } Terraform コード解説 ローカル変数 当記事では、通知対象のジョブ名や通知先メールアドレスなどの情報は locals に定義しています。 locals { project_id = "sample-project" # プロジェクトID location = "asia-northeast1" # ジョブが存在するリージョン job_name = "sample-job" # ジョブ名 notification_email = "sample@g-gen.co.jp" # 通知先メールアドレス } 当記事のコードをモジュール化し、複数のジョブで同様のアラート通知を設定するようなケースでは、これらの変数は variables で定義し、モジュールの外から値を渡せるようにするのがよいでしょう。 ログベースの指標 ログベースの指標 として、通知対象ジョブのエラーログを取り込む Cloud Monitoting 指標を定義します。 ログベースの指標では、Cloud Logging の特定のログエントリの数などを Cloud Monitoring の指標として記録することができます。 resource "google_logging_metric" "this" { project = local.project_id name = "error_metric_for_$ { local.job_name } " # Cloud Logging のクエリを定義 filter = <<-EOT severity>=ERROR resource.type="cloud_run_job" resource.labels.job_name="$ { local.job_name } " resource.labels.location="$ { local.location } " logName=~"cloudaudit.googleapis.com%2Fsystem_event" EOT metric_descriptor { metric_kind = "DELTA" value_type = "INT64" } } ログベースの指標としてエラーログを取得するために、Cloud Logging のクエリ言語を使用してログをフィルタリングします。このクエリを filter の値として定義しています。 Cloud Logging に出力されるジョブ実行エラーログは以下のフィールドが含まれています。これをクエリに使用します。 フィールド名 値 severity ERROR resource.type cloud_run_job resource.labels.job_name ジョブの名前 resource.labels.location ジョブが存在するリージョン logName projects/<プロジェクトID>/logs/cloudaudit.googleapis.com%2Fsystem_event Cloud Run jobs のジョブ実行エラー時のログ 参考 : Log-based metrics overview 参考 : Cloud Loggingのクエリ言語の構文を徹底解説 - G-gen Tech Blog 参考 : google_logging_metric （Terraformドキュメント） 通知チャンネル Cloud Monitoring で作成されるアラートの通知先として 通知チャンネル を設定します。 当記事ではメール通知を設定しますが、通知先チャンネルとしては Slack や SMS、Pub/Sub などを設定することも可能です。 resource "google_monitoring_notification_channel" "this" { project = local.project_id display_name = "ジョブエラー通知用メールアドレス" type = "email" force_delete = false labels = { email_address = local.notification_email } } 参考 : Create and manage notification channels 参考 : google_monitoring_notification_channel （Terraformドキュメント） アラートポリシー 実際にアラートを作成するリソースである Cloud Monitoring の アラートポリシー を設定します。 resource "google_monitoring_alert_policy" "this" { project = local.project_id display_name = "Error Alert for $ { local.job_name } " # アラートの表示名 combiner = "OR" severity = "ERROR" # アラートの重大度（CRITICAL / ERROR / WARNING） enabled = true notification_channels = [ google_monitoring_notification_channel.this.id ] conditions { display_name = "Error Condition for $ { local.job_name } " condition_threshold { # filterのmetric.typeにログベースの指標を指定（resource.typeの指定も必須） filter = "resource.type=\"cloud_run_job\" AND metric.type=\"logging.googleapis.com/user/$ { google_logging_metric.this.name } \"" comparison = "COMPARISON_GT" # threshold_value の値よりも大きいときにアラート作成 threshold_value = 0 aggregations { alignment_period = "60s" per_series_aligner = "ALIGN_COUNT" } duration = "60s" # ログベースの指標にデータがないときにアラートを止める evaluation_missing_data = "EVALUATION_MISSING_DATA_INACTIVE" } } alert_strategy { # アラート作成時のみ通知を送信する notification_prompts = [ "OPENED" ] } documentation { subject = "ジョブ($${resource.label.job_name})の実行に失敗しました" content = <<-EOT ## Google Cloudプロジェクト $${resource.label.project_id} ## Cloud Runジョブ名 $${resource.label.job_name} ## アラートの説明 Cloud Runジョブ**($${resource.label.job_name})**の実行に失敗しました。 ジョブの実行ログおよびTerraformテンプレートの設定値を確認してください。 EOT mime_type = "text/markdown" } } L15~L16 ジョブ実行失敗時のエラーログが1つでも記録されたときにアラートを作成したいため、 conditions.condition_threshold.comparison の値を COMPARISON_GT （閾値より上）、 conditions.condition_threshold.threshold_value の値（閾値）を 0 に指定します。 L25 conditions.condition_threshold.evaluation_missing_data の値を EVALUATION_MISSING_DATA_INACTIVE にすることで、ログベースの指標にデータが記録されないときにアラートを止める（復旧させる）ようにしています。 これは、今回設定しているログベースの指標が「Cloud Logging にジョブ失敗のエラーログが記録されたとき」だけ取得されるものであり、 エラーログがないときは値が何も取得されない ため、アラートが一度作成されると復旧しない（指標の値として0が記録されないと復旧しない）ためです。 もし、エラーの対処後にアラートを手動で復旧させたい場合は、 conditions.condition_threshold.evaluation_missing_data は記述しないか、値に EVALUATION_MISSING_DATA_NO_OP を設定します（ 参考 ）。 L29~L32 alert_strategy.notification_prompts では OPENED を指定し、アラートの作成時のみメール通知を送信するように設定しています。 ここで CLOSED も一緒に記述した場合、アラート復旧時にもメール通知が送信されます。しかし、先述したように今回設定しているログベースの指標には復旧時の手がかりがないため、アラートは作成後すぐに止める（復旧させる）ように設定しています。この場合、アラート作成のメール通知のすぐ後に復旧時のメール通知も送信されてしまうため、復旧時の通知はあえて行わないようにしています。 L34~L48 documentation にはアラート通知メールの本文（ドキュメント）を定義できます。 ドキュメントはマークダウンで記述することができ、 ${varname} の形式で変数を使用することもできます。これにより、アラート対象となっているジョブのプロジェクト ID やジョブ名など、そのアラート固有の情報をドキュメントに含めることができます。 参考 : Alerting overview 参考 : Annotate notifications with user-defined documentation - Variables in documentation 参考 : google_monitoring_alert_policy （Terraformドキュメント） 動作確認 アラート通知対象のジョブを失敗させ、アラートを作成してみます。 Cloud Run のジョブを失敗させる Google Cloud コンソールの ポリシーの詳細 画面でアラートポリシーを確認すると、ジョブ実行の失敗を示すエラーログがログベースの指標として記録されています。アラート閾値は 0 であり、アラート作成条件は 閾値よりも上 のため、Cloud Monitoring によってアラートが作成されます。 ジョブ失敗時のエラーログがログベースの指標に記録されている 同じく ポリシーの詳細 画面の インシデント 欄に、作成されたアラートが表示されています。 アラートポリシーによって作成されたアラート 通知チャンネルに設定したメールアドレスに対しては、アラートポリシーによって作成されたアラートメールが alerting-noreply@google.com から送信されています。 Cloud Monitoring のアラートメール メール本文は以下のようになっており、アラートポリシー作成時にマークダウンで記述したドキュメントのほか、対象のアラートおよびエラーログのリンクも含まれています。 アラートメールの本文 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。2025年10月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Cloud Run functions 第1世代を第2世代にアップグレードするツール (Preview) Google チャットで、スラッシュ（/）でアプリが呼び出せるように Google Gen AI SDK に C# 版が登場（Preview） gemini-2.5-flash-image（通称 Nano Banana）が一般公開（GA） Google Cloud の AI Applications が「Vertex AI Search」に名称変更 Gemini in Chrome が Google Workspace ユーザー向けに一般公開（GA） Looker の Private IP インスタンスで Connected Sheets が利用可能に Google Meet で画面上にタイマーを表示できるように Gemini 2.5 Computer Use model がプレビュー公開 Colab Enterprise で post-startup script が設定できるように（Preview） BigQuery でクエリ実行時に使用する予約（reservation）を明示的に指定可能に Google が Gemini Enterprise を発表 Secret Manager が GKE の Kubernetes Secrets と自動同期可能に（Preview） Google Meet で AI によるバーチャルメイクアップが登場 Gmail にスケジュールを自動調整する Help me schedule 機能が登場 Google スプレッドシートの AI 関数が Google 検索グラウンディングに対応 Google が新しい動画生成モデル Veo 3.1 と Veo 3.1 Fast を公開 Veo 2 で動画内へのオブジェクト追加や削除が可能に（Preview） Cloud Armor の階層型セキュリティポリシーが Preview → GA Looker Studio Pro で Slack へのレポート共有が Preview 公開 BigQuery Studio の UI に新機能が追加 Google Workspace に「Business Continuity エディション」が登場 Cloud Run の Direct VPC egress で VPC Flow Logs と Private NAT がサポート Ask Gemini in Google Meet が英語で利用可能に BigQuery で conversational analytics への Early access が募集開始 Cloud SQL で複数のアップデート AlloyDB for PostgreSQL で、時系列予測機能が登場（Preview） Google Meet に待合室（waiting rooms）機能が登場 Gemini アプリが LaTeX フォーマット生成・PDF 出力に対応 Gemini アプリで Google スライドのプレゼンテーションが生成可能に BigQuery に Data Engineering Agent が登場（Preview） BigQuery で3つの「Managed AI functions」が Preview 公開 Application Load Balancers で Authorization policy が一般公開（GA） BigQuery で reservation groups が利用可能に（Preview） Google Workspace の監査ログイベントのスキーマが変更 請求先アカウントの異常検知（Anomalies）が Preview → 一般公開（GA） Google Cloud 公式ドキュメントのドメインが変更 はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Cloud Run functions 第1世代を第2世代にアップグレードするツール (Preview) Upgrade 1st gen functions to Cloud Run functions (2025-10-01) Cloud Run functions 第1世代を第2世代にアップグレードするツールが公開（Preview）。 第1世代の HTTP 関数と Pub/Sub 関数に対応。関数を第2世代として複製し、トラフィックを新しい第2世代関数にリダイレクトする。最終コミット前にロールバックもできる。 Google チャットで、スラッシュ（/）でアプリが呼び出せるように Quickly find and use Google Chat apps and Workspace actions with the redesigned integrations menu (2025-10-01) Google チャットで、スラッシュ（/）でアプリが呼び出せるように。 /poll のようにしてアプリを呼び出せる。2025年9月29日から15日間かけて順次ロールアウトされる。 Google Gen AI SDK に C# 版が登場（Preview） Vertex AI release notes - October 02, 2025 (2025-10-02) Google Gen AI SDK に C# 版が登場（Preview）。 Gemini などへの API リクエストをラップするクライアントライブラリ。これまでは Python、Java、Go、Node.js 版などが存在していた。 gemini-2.5-flash-image（通称 Nano Banana）が一般公開（GA） Vertex AI release notes - October 02, 2025 (2025-10-02) gemini-2.5-flash-image（通称 Nano Banana）が Preview から一般公開（GA）。 プロンプトからの画像生成 複数画像を参照しての生成 マルチターンでの画像編集 GA に伴いコストに優れるバッチ推論も可能になった。 Google Cloud の AI Applications が「Vertex AI Search」に名称変更 Vertex AI Search release notes - October 02, 2025 (2025-10-02) Google Cloud の AI Applications が「Vertex AI Search」に名称変更。今回で、4回目の名称変更。 Generative AI App Builder → Vertex AI Search and Conversation → Vertex AI Agent Builder → AI Applications → Vertex AI Search かつて AI Applications の中に Search と Agents が含まれていたが、Agents が Conversational Agents として独立して、Search も1プロダクトとして独立した形。 Gemini in Chrome が Google Workspace ユーザー向けに一般公開（GA） Use the Gemini in Chrome AI browsing assistant, now generally available (2025-10-03) Gemini in Chrome が Google Workspace ユーザー向けに一般公開（GA）になった。 ただし現在はまだ米国在住のユーザーしか使えない。GWS アプリやブラウザの最大10個のタブをコンテキストとして読み取って AI がタスクを実行。要約、質問への回答等が可能。 Looker の Private IP インスタンスで Connected Sheets が利用可能に Looker Connected Sheets Private IP support (2025-10-06) Looker（Google Cloud Core）の Private IP インスタンスに、Connected Sheets からアクセスできるようになった。 管理者側で有効化が必要。2025年10月6日から15日間かけて順次ロールアウト。 Google Meet で画面上にタイマーを表示できるように Set timers in Google Meet on the web (2025-10-07) Google Meet で画面上にタイマーを表示できるようになった。 会議や登壇でのユースケースが考えられる。2025年10月6日から3日間かけてロールアウト。 Gemini 2.5 Computer Use model がプレビュー公開 Introducing the Gemini 2.5 Computer Use model (2025-10-07) Gemini 2.5 Computer Use model がプレビュー公開。 AI が PC 画面のクリック、入力、スクロールなどの操作を行えるようになる。クリック箇所などの座標が JSON 形式レスポンスに含まれる。アクション自体は Playwright 等でプログラム側で実行。Google AI StudioとVertex AIで使用可能。 参考 : Computer Use model and tool ‐ Google Cloud Colab Enterprise で post-startup script が設定できるように（Preview） Use a post-startup script (2025-10-07) Colab Enterprise で post-startup script が設定できるように（Preview）。 post-startup script は、ランタイムに設定する。ランタイム起動時に自動的に必要なパッケージをインストールなどが可能。スクリプトは Cloud Storage バケットに格納するか HTTPS エンドポイント経由で取得。 BigQuery でクエリ実行時に使用する予約（reservation）を明示的に指定可能に Flexibly assign reservations (2025-10-08) BigQuery でクエリ実行時に使用する予約（reservation）を明示的に指定する機能が Preview → GAになった。 これにより1つのプロジェクトで、クエリごとにオンデマンドを使うか Editions を使うかを切り替えられる。SQLの記述で指定することもできる。 参考 : BigQuery Editionsを徹底解説 - プロジェクト内での予約の使い分け - G-gen Tech Blog Google が Gemini Enterprise を発表 Introducing Gemini Enterprise (2025-10-10) Google が Gemini Enterprise を発表。 既存サービス Google Agentspace が改称され、機能追加とともにライセンス体系も一新。以前の Google Agentspace との大きな違いは以下。 Gemini Code Asssit ライセンスが付与されたこと ノーコードエージェント開発（Agent Designer）が下位プランにも付属 以下の記事も参照。 blog.g-gen.co.jp Secret Manager が GKE の Kubernetes Secrets と自動同期可能に（Preview） Synchronize secrets to Kubernetes Secrets (2025-10-13) Secret Manager を GKE の Kubernetes Secrets と自動同期する機能が Preview 公開。 環境変数方式でもマウント方式でも利用できる。従来からあった Secret Manager add-on だとマウント方式でしか利用できなかった。 Google Meet で AI によるバーチャルメイクアップが登場 AI-powered makeup in Google Meet (2025-10-13) Google Meet で AI によるバーチャルメイクアップが登場。 コップなどで顔が少し隠れても崩れない。12種類から選択可能。Google Workspace Business Standard 以上で利用可能。 2025年10月8日から15日かけて順次ロールアウト。 Gmail にスケジュールを自動調整する Help me schedule 機能が登場 Use Help me schedule to easily set up a meeting time over email (2025-10-14) Gmail に Help me schedule 機能が登場。 Gemini がメールの文章を読み取り、スケジュール調整が必要な場合、カレンダーから時間帯を自動的に提案してくれる。 即時リリース組織では2025年10月13日から15日間かけて順次ロールアウト。 Google スプレッドシートの AI 関数が Google 検索グラウンディングに対応 The AI function in Google Sheets is now enhanced with Google Search results for more up-to-date answers (2025-10-14) Google スプレッドシートの AI 関数が Google 検索によるグラウンディングをするようになった。 LLM が知らない最新情報をもとに生成が可能になる。2025年10月15日から15日間かけて順次ロールアウト。 Google が新しい動画生成モデル Veo 3.1 と Veo 3.1 Fast を公開 Veo 3.1 preview (2025-10-15) Google が新しい動画生成モデル Veo 3.1 と Veo 3.1 Fast を公開。 Gemini アプリで回数制限付きで無料で使える。Vertex AI や Gemini AI Studio から API 経由で使用可能。API 利用は料金に注意。 参考動画 : Google Gemini App 公式 X アカウント Veo 2 で動画内へのオブジェクト追加や削除が可能に（Preview） Insert objects into Veo videos (2025-10-15) 従来からある動画生成モデル Veo 2 で、動画内への物体の追加や削除が可能になった（Preview）。 Cloud Armor の階層型セキュリティポリシーが Preview → GA Hierarchical security policies overview (2025-10-15) Cloud Armor（フルマネージド型 WAF）の階層型セキュリティポリシーが Preview → 一般公開（GA）。 組織レベルまたはフォルダレベルで「階層型バックエンドセキュリティ ポリシー」を作成すると、配下のすべての「グローバル外部アプリケーションロードバランサ」にポリシーが適用される。 Google Cloud Armor Enterprise（Annual または Paygo）が必要。階層型ポリシーが適用されたプロジェクトは自動的に Paygo で登録されてしまうので、費用に注意が必要。 Looker Studio Pro で Slack へのレポート共有が Preview 公開 Share and schedule reports with Slack (2025-10-16) Looker Studio Pro で Slack へのレポート共有が Preview 公開。 チャンネルやユーザーにレポートをスケジュール配信できる。Looker Studio 無償版では不可 BigQuery Studio の UI に新機能が追加 BigQuery release notes - October 16, 2025 (2025-10-16) BigQuery Studio の UI に新機能が追加。 左部の Explorer ペインが Explorer、Classic Explorer、Git repository の3セクションに 新 Explorer はツリー式表示ではなくディレクトリ風表示。検索も可能で、パンくずリストあり。 ジョブ履歴は、かつては画面下部分に表示。今後は details のタブとして表示 リソース詳細は基本的に同じタブの中に表示される Ctrl + click して新しいタブで開くか、タブ名をダブルクリックしてタブを固定すればタブの中身が置き換わらない 最近閉じたタブ、なども表示可能 その他細かい変更 Google Workspace に「Business Continuity エディション」が登場 Introducing Business Continuity editions: Support business continuity and resilience for enterprise customers (2025-10-17) Google Workspace に「Business Continuity エディション」が登場。 Microsoft 365 ユーザー等向けのバックアップとして使用可能。メール、カレンダー、ドライブ、チャットなどをデータ同期して、何かあった際のバックアップとして利用できる。 Cloud Run の Direct VPC egress で VPC Flow Logs と Private NAT がサポート Cloud Run release notes - October 21, 2025 (2025-10-21) Cloud Run の Direct VPC egress で VPC Flow Logs と Private NAT がサポートされた。VPC Flow Logs は Preview、Private NAT 対応は GA（一般公開）。 これまでは、Cloud Run から Direct VPC egress 経由で VPC に出ると、VPC Flow logs は記録されなかった。また、Private NAT の利用は不可だった。 Ask Gemini in Google Meet が英語で利用可能に Ask Gemini in Google Meet coming to Workspace enterprise customers (2025-10-22) Google Meet 内で AI アシスタント Gemini に質問したり要約を依頼できる機能 Ask Gemini in Google Meet が利用可能になった。ただし、現在のところ英語版のみ。対象エディションは Enterprise Standard および Enterprise Plus。 途中参加した議論の要約、重要なポイントやアクションアイテムのリストアップなどが可能。 BigQuery で conversational analytics への Early access が募集開始 BigQuery release notes - October 23, 2025 (2025-10-23) BigQuery で conversational analytics（会話形分析）への Early access（早期アクセス）が募集開始。 既存の Data Canvas 等との違いはあまり情報がないが、新しい機能と思われる。応募フォーム経由で組織やプロジェクト ID を添えて申し込む。 Cloud SQL で複数のアップデート Cloud SQL for PostgreSQL release notes - October 23, 2025 (2025-10-23) (1) Cloud SQL で新しいマシンシリーズが使用可能になった。 Enterprise エディション : N4 マシンシリーズが使用可能に Enterprise Plus エディション : C4A マシンシリーズが使用可能に 使えるストレージのタイプも、マシンシリーズに依存して変わるため注意。これまでより選択肢の幅が広がった。 (2) Cloud SQL for PostgreSQL で、メモリ使用量の急増をプロアクティブに検知して、Connection を強制終了して OOM（out-of-memory）を回避するようになった。キャンセルさあれたクエリはログで確認できる。 AlloyDB for PostgreSQL で、時系列予測機能が登場（Preview） Perform time-series forecasting (2025-10-23) AlloyDB for PostgreSQL で、時系列予測機能が登場（Preview）。 Vertex AI のリモートモデルを SQL から呼び出す形で、予測を生成できる。 Google Meet に待合室（waiting rooms）機能が登場 Introducing a new waiting rooms experience in Google Meet (2025-10-23) Google Meetに待合室（waiting rooms）機能が登場。 入室承認前に参加者を待機させられる他、管理者から待機者にメッセージを送れる。予定作成時に待合室をオンにしておくと使える。2025年10月23日から15日間かけて順次ロールアウト。 Gemini アプリが LaTeX フォーマット生成・PDF 出力に対応 New LaTeX features in the Gemini app (2025-10-27) Gemini アプリが LaTeX フォーマット生成・PDF 出力に対応。 LaTeX とは、印刷物や PDF 等の組版用フォーマット。Gemini アプリに「PDF化して」と指示することで、Canvas で作ったページを LaTeX 化すると、プレビュー画面でPDF として表示したり、ダウンロードできる。 Business Starter 以上で既に使用可能。 Gemini アプリで Google スライドのプレゼンテーションが生成可能に Generate presentations in the Gemini app (2025-10-28) Gemini アプリで Google スライドのプレゼンテーションが生成できるようになった。Canvas で生成して Google スライドにエクスポート。 Business Starter 以上の Google Workspace エディションや Google AI Pro で利用可能。2025年11月12日までに順次ロールアウト。 BigQuery に Data Engineering Agent が登場（Preview） Use the Data Engineering Agent to build and modify data pipelines (2025-10-27) BigQuery に Data Engineering Agent が登場（Preview）。 Dataform もしくは BigQuery pipelines 形式のデータパイプラインを自然言語指示により生成。エージェントはデータセットやテーブルのメタデータを読み込んで解釈する。 BigQuery で3つの「Managed AI functions」が Preview 公開 Managed AI functions (2025-10-28) BigQuery で3つの「Managed AI functions」が Preview 公開。バックエンドでは生成 AI モデル Gemini を使用。 AI.IF （WHERE 句で使用してフィルタリング） AI.SCORE （スコアリング・ランク付け） AI.CLASSIFY （分類） Application Load Balancers で Authorization policy が一般公開（GA） Authorization policy overview (2025-10-28) Application Load Balancers で Authorization policy が一般公開（GA）。 Load Balancer に mTLS 等に基づく認可ルールを設定できる。接続元が Compute Engine VM や GKE 等であればサービスアカウントやタグによる認証もサポート。 BigQuery で reservation groups が利用可能に（Preview） Prioritize idle slots with reservation groups (2025-10-29) BigQuery の予約（reservation）でアイドルスロットを優先的に共有させるグルーピングが可能に（Preview）。 通常、アイドルスロットは管理プロジェクト内で平等に分配されるが、グループを設定するとグループ内で互いに優先的にスロットをシェアするようになる。 Google Workspace の監査ログイベントのスキーマが変更 Enhanced admin audit log events (2025-10-29) Google Workspace の監査ログイベントのスキーマ変更が予定されている。分析などに使っている場合は要確認。 2025年10月29日から15日間かけてロールアウト。フィールド名や値表記などが変更される。Google ドライブ、Gmail などのログに影響。 請求先アカウントの異常検知（Anomalies）が Preview → 一般公開（GA） View and manage cost anomalies (2025-10-30) 請求先アカウントの異常検知（Anomalies）機能が Preview → 一般公開（GA） 通常の使用パターンから逸脱した課金スパイクを検知・通知。以下の記事も参照。 blog.g-gen.co.jp Google Cloud 公式ドキュメントのドメインが変更 Announcing docs.cloud.google.com: The new home for Google Cloud documentation (2025-10-30) Google Cloud の公式ドキュメントのドメインが変更される。 従来 : https://cloud.google.com/〜 今後 : https://docs.cloud.google.com/〜 URL のうち、変更になるのは、原則的にはドメイン名の部分のみ。旧リンクはしばらく存続し、今後数週間以内に、新ドメインへのリダイレクトが始まるとのこと。 またドキュメントへの他言語への翻訳が迅速になる、とも発表された。Google はドキュメント作成や翻訳に AI を使用していることを公表している。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

当記事は、ライオン株式会社様と株式会社G-genの 技術情報発信コラボレーション企画 『SAPと連携するデータ分析基盤の実践とTips』で執筆されたものです。 はじめに 当企画について 自己紹介 当記事について 概要 データマネジメントのプロセス アジリティ、ガバナンス、利活用促進のバランス 設計 3つのレイヤ DataLake DWH Datamart データカタログとメタデータ 実現するためのプロダクト Dataform、BigQuery Looker まとめ はじめに 当企画について 当記事は株式会社 G-gen 様とライオン株式会社の技術ブログ相互寄稿企画で執筆されたものです。 ライオン側からは、 G-gen 様のご協力のもと、Google Cloud 環境に構築を進めているデータ基盤に関連した以下3つの記事をシリーズでお届けします。 ライオンのデータ基盤構築とSAPデータ活用体制 ライオンのデータマネジメント 👈 当記事 ライオンのデータ基盤における分析環境 G-gen Tech Blog の記事一覧 blog.g-gen.co.jp LION Digital Inside の記事一覧 zenn.dev 自己紹介 データサイエンスグループのハマノです。 もともとデータサイエンティストとしてライオンに入社し、データ分析を行っていましたが、データ基盤の必要性を感じ、入社後はガッツリとデータマネジメントに携わるようになりました。とりあえずデータを準備するだけに留まらず、継続的に全社的な業務が回るように、設計・構築・運用を踏まえたエンジニアリングを行うところが面白いなと思っています。 当記事では、ライオンで行っているデータマネジメントについて紹介したいと思います。 当記事について ライオンでは2022年5月より基幹システムとして SAP S/4HANA （以下、SAP）を利用していますが、SAP に蓄積されたデータにまとめてアクセスする手段は、各部門の業務で用いるいくつかの帳票ツール（BO やアドオン）に限られており、部門ごとにサイロ化している傾向がありました。そのため、様々なデータの取得・解析が必要なデータサイエンティストや、自部門の業務の改善をしようとする業務担当者が必要なデータにスムーズにアクセスすることが困難な状態でした。 当記事は、データ基盤を構築することで、 データの取得に関するボトルネックを解消 し 意思決定までのプロセスをスムーズに することを目的とした活動について記載しています。 当企画の1つ前の記事である フクヤマからの投稿 で共有いたしましたが、我々は当初、SAP その他の業務システム由来のデータをインポートする複数のテンプレート群を持つデータ分析基盤構築向けのリファレンスアーキテクチャである Google Cloud Cortex Framework の利用を検討しました。しかし、アドオンテーブルなどを含む当社での SAP の実装においては、必要なデータを含むテーブルに対するテンプレートのカバー率が低く、Cortex Framework を効果的に使えないことが判明しました。 我々はこの事実を受け、Cortex Framework のテンプレートに依存しないデータモデルの設計と実装を行うことを選択しました。ここからは、我々がデータマネジメントをどう定義し、どんなツールを使って実現するかを検討した話を簡単にご紹介します。 概要 データマネジメントのプロセス データマネジメントについては、一般的には DMBOK などで詳細に定義されていますが、少しシンプルにすると、以下の3つのプロセスに分解される活動です。 アジリティの確保 ガバナンスの確保 利活用の促進 まず アジリティ は、すぐにデータを利用出来る状態にすることです。データ基盤は、基幹システムとの依存関係を切り離し、独自システムとして構築します。リスクやサービスレベルを変えることで、開発スピードを上げます。また、クラウドサービスを使って、スケーラブルな設計をします。 次に ガバナンス は、品質の担保やセキュリティ面の考慮です。ユーザーが懸念なくデータを利活用できるよう準備します。 利活用の促進 は、BI や AI などの分析ツールを提供し、データを使いやすくするプロセスです。ユーザーが、データを利活用できるために、業務プロセスでどのように意思決定を行うかを理解した上で、データを活用する機能やデータそのものを適切に提供することが重要となります。 アジリティ、ガバナンス、利活用促進のバランス 上に挙げたアジリティ、ガバナンス、利活用の促進はどれも重要な要素ですが、実のところこれらは本質的にトレードオフの関係にあり、バランスを取りながら進める必要があります。 ユーザー部門主導でのデータ利活用を優先して、既存の Excel ファイルなどをかき集めてアウトプットをする仕組みを作ったものの、運用に関する考慮をしておらず、担当者の異動や業務の見直しなどによりファイルが作成されなくなることや、人材リソースの不足でプロジェクトを中断するケースなどは、コンサルティング会社が主導した場合でも発生するといった話を耳にすることがあります。 逆に、外部の会社にデータ基盤の構築を委託し、その会社がつくったカッチリと決めた設計書、運用プロセスでは、ビジネスの変化に柔軟に対応できず、担当者のスピード感と合わず、上手く回ってないというケースもよく耳にします。 他にも、データの移動と保管、整合性維持にかかるコストを節約することを目論み、データカタログを整備しデータ仮想化技術によって各システムから動的にデータを取得するソリューションを導入すれば、労せずにデータ基盤が手に入るという構想のもと始めたプロジェクトが、主要システムのスキーマ取得すら試行錯誤続きで満足にできず、接続ができたとしても必要なパフォーマンスが出ず使い物にならなかった、といったような話も聞いたりします。 これらの望まざる状況を避けるためには、トレードオフを見極め、自社をよく知る担当者が、目指すべきデータマネジメントを定める必要がありますし、同時に状況に合わせて見直していく必要もあります。これらのプロセスは、メンバーのモチベーションを高めるためにも重要な要素であると考えられます。 とはいえ初期の状態では、何を可視化するか、誰がどういう意思決定を行うか、等が決まっていない、あるいは分かっていないケースも多いので、BI で出来ることのイメージを膨らませてもらうために、仮に設計したダッシュボードにより「可視化で何が出来るか」についての共有することも必要です。 当社でも、まずはイメージを持ってもらうために、汎用的なデータ基盤を目指し、アジリティ（データ準備）に重きを置いたデータマネジメントを目指すことにしました。 SAP のデータを整備から着手することになりましたが、ABAP が読めないことに加えて、生成 AI でも効率的に変換できなかったため、SAP の定義書を見ながら、SQL で再現しました。不明点は、社内の担当者・導入ベンダーに確認したり、Cortex Framework の SQL を参考にしたりしながら進めています。 設計 3つのレイヤ まずは、データベース設計部分の話です。ライオンのデータ基盤では、アジリティを高めるために、データベースの階層を以下の3レイヤに分けて考えています。 DataLake DWH Datamart DataLake DataLake は、SAP のデータを同期したテーブルとしています。Fivetran の連携機能により、最新断面でのデータや履歴データを連携しています。 Fivetran の機能により、履歴データでは、Slowly changing dimension Type2 でのフォーマットで連携することを設定できるので、データの性質に合わせて連携しています。 DWH DWH は、BI の可視化軸に合わせて、スタースキーマの設計をするべきところですが、たいていの場合は、BI のユースケースが定まっていないので、設計できません。 今回は、SAP のデータが厳密な第3正規化で設計された ER モデルであることから、スタースキーマに近づくことを見据えて、Datamart 作成のための中間テーブルを DWH レイヤで作成していて、マスタテーブルの整備を中心に行いました。ファクトテーブルでは、あまりフィルタ条件などは入れずに、変化の少ないビジネスロジックだけを実装しています。 将来的には、BIに合わせたスタースキーマの設計など、このレイヤの設計に重点を置く予定です。 正直、今は、そこまでキレイなものではなく、現段階では「後悔の塊」のようなレイヤになっています。 Datamart Datamart には、DWH に対して、変化する可能性もあるロジックを実装しています。また、Datamart では、とりあえず利用しそうな列名を詰め込んだ大福帳形式（OBT: One Big Table）を採用し、汎用的に利用できるデータを準備しています。こうすることで、依頼者からの依頼に対して、素早く対応できるようにしています。 OBT は、BI や集計の目的に合わせたテーブルとして、様々なテーブルを結合して作成しています。 例えば、会計用 OBT だと、様々なテーブルを結合することで、会計年月/勘定を計上した組織 / 勘定を計上した組織 / 勘定種別（総売上、売上原価、販促費など）/ 金額のようなカラム名を持つ1つのテーブルにすることです。1つのテーブルにすることで、パフォーマンスのリスク、テーブル結合ミスなどのリスクを減らし、スムーズに利用することが出来ます。 とはいえ、OBT は良いことばかりでなく、依頼に合わせて様々なカラムを追加することが往々にして発生するため、大なり小なりデータ品質や保管効率は劣化することになりますし、BigQuery をもってしても（クラシックな RDBMS ほどではないにせよ）パフォーマンス・運用の問題が出ることはあります。 これらの設計も BI や仕様に合わせて、今後、チームで協力して細かく見直していきたいところです。 データカタログとメタデータ データマネジメントといえば、データカタログなどのメタデータ管理が先行してしまうことも多いと思います。設計書などにも言えることですが、作成するドキュメントは「誰がどういう時に利用するものか？」「本当に必要か？」を問うことで、やらないコトを決めて開発の加速にリソースを集中することが望ましいと考えています。 まず、データ基盤導入では、以下の2段階のフェーズに分けて実際の行動を整理します。 Phase1: まだ利用用途が固まってない導入 PoC フェーズ Phase2: 利用用途が固まり、データ活用を民主化し、ユーザーでの利用を加速するフェーズ Phase1 では、利用者の大半は「BI 画面を見るだけの人」で、データカタログを必要とする人は、一部のデータサイエンティストやデータエンジニアです。 データベースに直接アクセスする人は少人数で、基礎知識のあるユーザーがほとんどです。また、このフェーズでデータサイエンティストが使うデータの種類はそれほど多くはないものの、外部システムからデータ基盤にデータを連携・蓄積する工程はまとめて行う方が効率が良いため、実際には使われないテーブルやカラムが数多く存在するという状況が発生します。加えて、この時点ではユースケースが定まっておらず、データモデルを決め切れていないため、テーブル構成も流動的で、大きな変更が発生する可能性も高いと言えます。このような状態で厳格に様式を定めた詳細なデータカタログを作ったとしても、大きな変更が発生して手戻りにつながることから、データカタログやメタデータの整備に過剰に注力することなく、口頭レベル・簡易ドキュメントでデータの仕様を共有する方が効率的と考えます。 さらに、このフェーズで、多くの「BI 画面を見るだけの人」は、データ分析をすることが目的ではなく、ダッシュボード上の可視化されたグラフを見て意思決定するためにデータ基盤を利用する人です。このようなユーザーはデータカタログを必要としていませんので、この時点で慌ててデータカタログを整備する必要はありませんし、将来に向けてデータカタログの整備を始める場合でも、スタート時は Looker などの BI ツールを使って、最低限のデータカタログ・アクセス権を大まかに管理するくらいで十分と感じています。 Phase2 では、利用用途が固まり、データモデルを設計する段階になります。データモデルが固まることで、DWH や Datamart をどのように定義するべきかを定めることができます。例えば、スタースキーマなどの設計に従って、データモデルが整備されていると、このフェーズからデータベースを使い始めるユーザーが扱いやすいものになりますし、DWH や Datamart のデータカタログの整備を積極的に行うことで、利用者が自主的にデータを活用することを促進できます。 もちろん、フェーズが進んでいくごとに、ユーザーのポートフォリオも変わっていくので、データカタログの必要性と費用対効果を意識しながら徐々に整備を進めて行くのが良いと考えています。 実現するためのプロダクト Dataform、BigQuery 今後、DWH、Datamart の設計を見直すと、たくさんのテーブルが作成されることが予想され、これらのテーブル管理、処理のオーケストレーションの管理が必要になります。つまり、テーブルがたくさんできることで、それらの依存関係も複雑になるので、依存関係を可視化して、変更の影響が自動で整理できるようになっていることが求められます。 また、増分更新や差分更新は、初回実行時と差分実行時の処理を分ける必要がありますが、複数のメンバーでそれぞれのテーブル・処理に対して都度コードを書くようになっていると、効率が悪いだけでなく、コードの書き方が人に依存してしまいがちでメンテナンスができなくなります。Dataform では、 when 関数、 pre_operations ブロックがついているので、テーブルや処理の違いを吸収し汎用的なコードでの実装をサポートしてくれます。JavaScript で拡張することも出来るので、共通して使いたい変数の実装など、痒い所に手が届きますし、これが無料で使えるのが驚きです。 GitHub と連携したスケジュール実行も可能です。 我々は、このような利点を踏まえ、新データ基盤内の ELT ツールとして Dataform を採用しました。 BigQuery のスケーラブルなリソースに加え、内部のデータ操作は基本的に SQL を中心に完結しますので、この処理を効率的に管理する ELT ツールの Dataform を活用することで安価で効率的な仕組み作りを実現できています。 整理すると、Dataform は オーケストレーション機能 依存関係の可視化 when 関数、 pre_operations ブロックなどの拡張機能 GitHub 連携 スケジュール実行 などの機能があり、DWH、Datamart の管理を効率化するツールになっています。 Looker Google Cloud で利用できる各種 BI ツールの中でも、Looker は特に使いやすいプロダクトです。 ユーザーは、合計の操作が必要な利益などの指標、割り算の操作が必要な利益率などの指標の可視化の要望があり、可視化する粒度が変わる度に計算が必要な指標は BI 側にロジックを実装する必要があります。 管理者や高度な分析を行うデータサイエンティストにとっては、それらの指標を LookML でコードとして定義し、extends 機能により再利用できるようにすることで、DRY（Don't Repeat Yourself）の原則に従った設計が可能になります。また一般ユーザーは、GUI で一般的なエンタープライズ向けの BI と同じような操作で分析が可能です。 さらに、いわゆるデータセットはセマンティックレイヤという形でコードの形で管理されることで、差分管理も可能になります。ツールによっては画面ごとに手作業で GUI を使って作る必要があるダッシュボードも、コードとして定義・管理できるので、新しい画面の迅速な実装が可能となりますし、担当者間での知見の共有や業務の分担も進めやすいです。昨今の技術トレンドを考えると、セマンティックレイヤをコードとして定義できていることで、生成AIとの相性も良いです。 整理すると、Looker は ディメンジョン、ファクトの概念に合った設計 LookML によるコードでの指標定義、指標の説明などメタデータ管理、ダッシュボード管理 DRY の原則を実現できる extends 機能 セマンティックレイヤによるデータセット管理 などの機能があり、長期的な目線で考えた時に有用なツールと考えました。 以上はエンジニア観点での Looker の利点ですが、ユーザーにとっても、可視化機能に加えて、ディメンション（集計軸）、ファクト（数値）が明確に分かれていることで、迷うことなく、直感的にグラフ作成や集計を行うことができ、LookML でメタデータをコードで管理できます。また、セマンティックレイヤがコードにより可視化とは独立して管理されることで、生成 AI モデルを自由に検証できるので、自然言語での問い合わせや動的なグラフ作成など、将来の可能性が広がると考えています。 まとめ 上記のように、外部リソースに大きく依存することなく、データマネジメントのアウトラインを定め、データを物理的に Google Cloud に集め、Google Cloud のプロダクトを使って、全社的にデータを利活用できる状態を目指して、設計・実装を進めています。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、2021年よりクラウドの導入から最適化までを支援しているGoogle Cloud専業のクラウドインテグレーターです。

G-gen の杉村です。Google の生成 AI 開発ツールである Vertex AI と Google AI Studio の違いや、それぞれのユースケースについて解説します。 概要 Vertex AI と Google AI Studio 差異の一覧 選定の基本的な考え方 セキュリティと統制 Vertex AI の場合 Google AI Studio の場合 割り当てとレート制限 概要 Vertex AI の場合 Google AI Studio の場合 Google Cloud プロダクトとの連携 Vertex AI の場合 Google AI Studio の場合 データの保護 Vertex AI の場合 Google AI Studio の場合 サポート Vertex AI の場合 Google AI Studio の場合 移行 Google AI Studio から Vertex AI への移行 Google AI Studio の使用を禁止する Vertex AI でモデルを気軽に試す 概要 Vertex AI と Google AI Studio Vertex AI は、Google Cloud が提供するフルマネージドの機械学習プラットフォームです。データの準備からモデルのトレーニング、デプロイ、管理まで、ML 開発のライフサイクル全体をサポートします。最近では特に生成 AI 関連機能が充実しています。企業における利用や研究者、個人開発に至るまで、多様なユースケースに対応できます。 Vertex AI では、API 経由で様々なモデルを呼び出せるほか、Web UI 上でパラメータを指定してモデルにリクエストを投入できる Vertex AI Studio 画面も用意されています。 参考 : Vertex AI の生成 AI の概要 Vertex AI Google AI Studio は、Google の最新の生成 AI モデルである Gemini をはじめとする生成 AI モデルを、Web ブラウザから手軽に試すことができる開発ツールです。主に個人または小規模開発者を対象としています。また、無料である程度の機能が試用できることも魅力の1つです。このサービスの API 経由で Gemini を呼び出す機能のことを単に Gemini API と呼称することもあります。 Google AI Studio は Vertex AI と同様、API 経由で様々なモデルを呼び出せるほか、Web UI 上でパラメータを指定してモデルにリクエストを投入できます。 参考 : Google AI Studio のクイックスタート Google AI Studio 差異の一覧 Vertex AI と Google AI Studio の主な違いを一覧表にまとめます。 項目 Google AI Studio Vertex AI 提供形態 Google サービス Google Cloud プロダクト ターゲット 個人開発者、研究者、学生 企業、官公庁、研究者 主な用途 プロトタイピング、学習、アイデア検証 本番環境のアプリケーション開発、その他の業務利用 実行環境 Web ベースの UI Google Cloud 料金 無料枠あり、有料ティアに引き上げ可能 従量課金 データ保護 無料枠ではデータがサービス改善に使われる可能性あり データは分離・保護され、モデル学習には利用されない セキュリティ API キー IAM、組織ポリシー、VPC SC、サービスアカウントなど高度なセキュリティ 主な機能 ・Gemini モデルの試用 ・プロンプトの作成と調整 ・API キーの発行 左記に加えて以下 ・AI エージェント構築 ・MLOps ・IAM、VPC SC 等との連携 ・監査ログ (Cloud Audit Logs) ・高度なモデルチューニング 選定の基本的な考え方 Vertex AI と Google AI Studio のどちらを使用したほうがよいかの原則的な考えかたとしては、以下のようなものが挙げられます。 Vertex AI は、企業、官公庁、研究者など幅広い利用者が想定されている Google AI Studio は、個人開発者、研究者、学生が想定されている 基本的には、「 プロトタイピングや学習は Google AI Studio 」「 企業等における本格的な開発や、本番利用は Vertex AI 」と覚えておけば、大きく間違うことはないでしょう。 その理由として、当記事で以下に挙げるようなことが考えられます。 セキュリティと統制 Vertex AI の場合 Vertex AI は Google Cloud と統合 されているため、詳細なアクセス制御や高度なセキュリティが使用できます。API キーを発行せずとも、Cloud Run 等のプラットフォームで動作するアプリケーションであれば、サービスアカウントを利用することでセキュアに API 呼び出しが可能です。また IAM によるアクセス制御が可能なため、ローカル開発においても、Google アカウント認証により手軽に API 呼び出しが可能です。 参考 : アクセス制御 - Google Cloud 参考 : アプリケーションのデフォルト認証情報を構成する - Google Cloud Vertex AI は Google Cloud に統合されているため、管理者が利用状況を可視化し、セキュアでない振る舞いが観測されたときにサービスアカウントを停止したり、アクセス権限を剥奪したりすることが可能です。また VPC Service Controls （VPC SC）、 Cloud Armor 等の保護機能も充実しています。 参考 : 生成 AI のセキュリティ管理 - Google Cloud また、 Cloud Audit Logs による監査ログ機能により、使用状況や設定の変更履歴などを記録することができます。 参考 : データアクセス監査ログを有効にする - Google Cloud 参考 : Cloud Audit Logsを解説。Google Cloudの証跡管理 - G-gen Tech Blog よって、企業や官公庁、研究機関などにおいて、生成 AI アプリケーションを開発したり API 経由で AI を利用する際には、Vertex AI を選択することが推奨されます。 Google AI Studio の場合 Google AI Studio は、Google アカウントさえ持っていれば無料で使用できたり、API キーを発行することですぐに生成 AI モデルへのリクエストをアプリケーションに組み込むことができる魅力があります。一方で、セキュリティを考慮した組織レベルの統制や、アクセス制御等の機能が 備わっていません 。 例えば、管理者やマネージャーが、開発者の Google AI Studio の利用状況や API キーの発行状況を 確認することができません 。Google AI Studio で無料版の API キーを使用する場合、入出力データが Google によってサービス改善に使われたり、モデルの再トレーニングに使用される可能性がありますが（後述）、無償版 API キーが使用されていないかなどを、管理者が知る術はありません。 また、Google AI Studio で発行できる API キーは単なる文字列であり、漏洩する危険性が否定できません。開発者は API キーをローカルに保存したり、アプリケーションに組み込むために何らかのデータストアに API キーを保存する必要があります。経験の浅い開発者だと、API キーをソースコードにハードコードしてしまうおそれもあります。 よって、Google AI Studio はプロトタイピングや個人開発、学習など、限定的な用途で用いることが推奨されます。Google AI Studio でプロトタイピングを行い、本格的な開発時は Vertex AI に移行する、といった選択肢も考えられます。 参考 : Gemini API キーを使用する ‐ Gemini API 割り当てとレート制限 概要 独自開発のアプリケーションから Gemini リクエストを送るには、Vertex AI を使う場合と、Google AI Studio の API キーを使う場合の2つの選択肢があります。 いずれの場合でも、一定の時間内で送信可能なリクエスト数に上限があります。 このようなリクエスト数制限は、Vertex AI では 割り当て （Quota）と呼ばれ、Google AI Studio の API キーの場合は レート制限 と呼ばれます。 Vertex AI の場合 Vertex AI API 経由での Gemini リクエストに対する割り当てにおいては、 動的共有割り当て （Dynamic shared quota、DSQ）という仕組みが使われています。 通常の Google Cloud API の割り当て（クォータ）は静的であり、Google Cloud コンソールから上限緩和リクエストを送ることができます。しかし Gemini の DSQ はこれとは異なり、上限緩和リクエストはできません。DSQ は動的であり、Gemini の割り当てはすべての Gemini ユーザーからの需要に応じて動的に決定します。同じソースからのリクエストが短い時間で急増すると、優先度が調整され、リクエストがエラーになります（ 429 RESOURCE_EXHAUSTED ）。 本番アプリケーション等でこの制限を避けるには、global ロケーションの使用、エクスポネンシャルバックオフの実装、 Provisioned Throughput （プロビジョニングされたスループット）の購入などを検討します。Provisioned Throughput とは、API スループットを事前に予約購入しておき、固定月額料金で利用する仕組みです。 429 RESOURCE_EXHAUSTED エラーへの対策や Provisioned Throughput についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp Google AI Studio の場合 Google AI Studio の API キーを使用した Gemini へのリクエストには、 レート制限 （rate limits）があります。以下の3つに対して制限があり、いずれか1つでも上限を超えるとエラーになります。 1分あたりのリクエスト数（RPM） 1分あたりのトークン数（入力）（TPM） 1日あたりのリクエスト数（RPD） レート制限には、無償版よりも有償版のほうが高い値が設定されており、有償版でも使用金額が多いほど 使用量ティア （Tier 1〜3）が上がり、高い値が設定されます。使用金額の上限を満たしていても、使用量ティアは API キーの管理ページから明示的にアップグレードする必要があります。 また、ドキュメントには「指定されたレート上限は保証されず、実際の容量は異なる場合がある」旨が記載されています。 このことから、本番環境のアプリケーションで確実にリクエスト量を確保するには、Google AI Studio の API キー ではなく 、Google Cloud の Vertex AI API の Provisioned Throughput を使うことが推奨されます。 詳細は以下のドキュメントを参照してください。 参考 : レート制限 Google Cloud プロダクトとの連携 Vertex AI の場合 Vertex AI は Google Cloud プロダクトであるため、BigQuery などの他の Google Cloud プロダクトとの連携も容易です。 BigQuery ML では、Vertex AI のリモートモデルを呼び出し、SQL で生成 AI モデル等の機械学習モデルを呼び出し、BigQuery データセット上のデータを使った推論やトレーニングが可能です。 Compute Engine 、 Cloud Run 、 Google Kubernetes Engine（GKE） 等のコンピューティングプラットフォームにおいては、インスタンス等にサービスアカウント（人ではなくプログラムが使うアカウント）をアタッチすることで、API キー等を発行しなくても Vertex AI の API を呼び出すことができます。これにより、セキュアに Gemini 等のモデルを API 経由で呼び出すことができます。 Vertex AI Agent Engine は、AI エージェントに特化したホスティングサービスです。フルマネージドであり、インフラの管理は必要ありません。 セキュリティの観点においても、 Cloud Armor と呼ばれる生成 AI 向けの防御サービスを利用したり、 VPC Service Controls という API 保護サービスを利用することで、多段での防御やアクセス制御が可能です。Vertex AI の API 自体へのアクセス制御も、 Identity and Access Management （IAM）と呼ばれる仕組みにより、詳細に行うことができます。Google アカウントにアクセス許可を与えたり、組織の Google グループ単位でアクセス制御を行うことが可能です。 Google AI Studio の場合 一方で Google AI Studio には、これらの連携は用意されていません。 Google Cloud プロダクトと連携しようと考える場合、Google AI Studio の API 呼び出しは API キーで認証し、Google Cloud プロダクトの呼び出しは IAM で認証する、というように、異なる認証機構をまたいだ設計が必要になります。 データの保護 Vertex AI の場合 Vertex AI は企業や官公庁、研究機関での利用が想定されていることから、データの保護が規約で定義されています。ユーザーが入力したプロンプトやデータ、また AI モデルが生成したレスポンスについては、Google がサービス改善に利用したり、モデルの再トレーニングに使用することはありません。 参考 : Vertex AI とデータの保持ゼロ - Google Cloud 参考 : Cloud Data Processing Addendum (Customers) - Google Cloud Google AI Studio の場合 一方で Google AI Studio の場合、無料枠を利用する場合は、Google によって入出力データがサービス改善に利用されたり、モデルの再トレーニングに使用される場合があります。利用規約にはこれが明記されており、また「本無料サービスには、プライベート情報、機密情報、または個人情報を送信しないでください。」と記述されています。 参考 : Gemini API 追加利用規約 ただし Google AI Studio で有料版の API キーを使用する場合、上記規約でいうところの「有料サービス」の扱いになり、入出力データがプロダクトの改善に使用されることはない、としています。 サポート Vertex AI の場合 Vertex AI は Google Cloud プロダクトであり、技術サポート窓口である カスタマーケア のサポート対象です。また Google Cloud の再販パートナーの技術サポートサービスにおいても、サポート対象となる可能性が高いといえます。当社 G-gen の技術サポート窓口の場合、サポート対象です。 参考 : Google Cloud カスタマーケア Google AI Studio の場合 一方の Google AI Studio には、公式のサポートサービスは存在していません。再販パートナーの技術サポートサービスにおいては、各社の裁量によるところになります。当社 G-gen の技術サポート窓口では、Google AI Studio はサポート対象ではありません。 移行 Google AI Studio から Vertex AI への移行 Google AI Studio の API キーを発行する際には Google Cloud プロジェクトが必要であり、また有償版 API の課金は、Google Cloud 請求先アカウントにひも付きます。つまりこの時点で、Google Cloud のりように必要な要素は整っているといえます。 Google AI Studio から Vertex AI に移行するための手順を示した公式ドキュメントも公開されています。 参考 : Google AI Studio から Vertex AI に移行する Google AI Studio の使用を禁止する Google Workspace（Cloud Identity）の管理者は、組織で管理している Google アカウントに対して、Google AI Studio の使用を禁止することができます。 以下の公式ドキュメントに従い、「AI Studio」を無効化することで、配下の Google アカウントは Google AI Studio を使用できなくなります。 参考 : その他の Google サービスを有効または無効にする - Google Workspace 管理者 ヘルプ これにより、組織の開発者が無償版の API キーを発行して、組織の機密情報や顧客情報、個人情報等を Google に送信してしまうことを未然に防ぐことができます。 Vertex AI でモデルを気軽に試す Google AI Studio を使わなくても、Vertex AI には手軽に最新の生成 AI モデルを試すための Web UI が用意されています。 Vertex AI Studio は、Google Cloud コンソール（Web UI）上で生成 AI モデルを試用したり、プロンプトチューニングを行ったり、プロンプトを保存・比較する機能を備えた画面です。 細かいパラメータの調整や、Cloud Run にサンプルアプリケーションを簡単にデプロイする機能も備えています。 参考 : クイックスタート: Vertex AI Studio を使用して Gemini にテキスト プロンプトを送信する - Google Cloud 参考 : Vertex AI Studio の機能- Google Cloud Vertex AI Studio 画面 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の min です。 Agent Development Kit （ADK）の Web UI による評価とデバッグの方法を解説します。 はじめに ADK とは 評価とデバッグ Event とは 必要な依存関係 デバッグ機能 概要 Events ビュー Trace ビュー 評価機能 概要 1. テストケースの作成 2. 評価の実行 3. 結果の分析 実践 実践例 1. 正常系の動作確認 2. 異常系のデバッグ 3. プロンプトの調査と改善 4. 回帰テストの作成 はじめに ADK とは Agent Development Kit（ADK） とは、AI エージェントを開発するためのフレームワークです。Google により開発され、2025年10月現在、Python 用と Java 用のライブラリが公開されています。特定のモデルやデプロイ環境に依存せず、他のフレームワークとの互換性も考慮されています。 参考 : What is Agent Development Kit? 参考 : How to run Evaluation with the ADK AI エージェントの開発から Web UI を用いた動作検証までの流れについては、以下の記事もご参照ください。 blog.g-gen.co.jp 本記事では、ADK に組み込まれた Web UI を用いて、AI エージェントのデバッグと評価を行うサイクルを解説します。 評価とデバッグ AI エージェントは、その挙動が非決定的であるため、品質を担保し、意図しない振る舞いを修正する「評価」と「デバッグ」のプロセスが重要です。 ADK は、開発者がコード内にテストを記述する従来の方法に加え、開発サイクルの中でインタラクティブにエージェントの挙動をテストし、その品質を定量的に評価するための機能をフレームワーク自体に組み込んでいます。この機能は Web UI を通じて利用できます。 この機能は、次に説明する「Event」というコアコンセプトに基づいています。 Event とは Event とは、ADK における情報伝達の基本単位 です。ユーザーの最初の入力からエージェントの最終応答まで、その間に発生したすべての重要な出来事を記録した「不変のレコード」と考えることができます。 具体的には、以下のような情報がすべて Event として扱われます。 ユーザーからのメッセージ（ author: 'user' ） エージェントによる思考や応答テキスト LLMに対するツール使用の要求（ functionCall ） ツールの実行結果（ functionResponse ） 状態の変化やエラー通知 これらの Event が時系列に連なることで、エージェントとのインタラクションの全容が記録されます。ADK の Web UI が提供するデバッグ・評価機能は、この Event のストリームを可視化し、分析するためのツールです。 参考 : Understanding and Using Events 必要な依存関係 Web UI で評価機能を利用するには、追加の依存関係をインストールする必要があります。 pip install " google-adk[eval] " インストール後、以下のコマンドで Web UI を起動できます。 <path_to_your_agents_folder> の部分には、エージェントの定義ファイルが格納されているフォルダへのパスを指定してください。 adk web < path_to_your_agents_folder > ブラウザで http://127.0.0.1:8000 にアクセスすると、Web UI が表示されます。 デバッグ機能 概要 ADK の Web UI は、Event のストリームを分析するための2つの主要なビューを提供します。 これらを使うことで、エージェントの内部的な動作を詳細に追跡できます。 Events ビュー Events ビュー は、発生したすべての Event を時系列に沿ってリストアップするビューです。Event の全体像や、個々の Event の中身を確認したい場合に役立ちます。 例えば、LLM が生成したツール呼び出しの引数（ functionCall の args ）や、ツールの実行結果（ functionResponse の response ）などを確認できます。 Trace ビュー Trace ビュー は、Event の流れを「誰が誰を呼び出したか」という親子関係で再構成し、処理の全体像を階層的に把握しやすくしたビューです。 LLM による思考からツール実行、最終応答の生成といった一連の流れや、各ステップの処理時間を直感的に理解できるため、処理フローの把握やボトルネックの特定に有効です。各トレース行をクリックすると、関連する Event の詳細をパネルで確認できます。 参考 : Debugging with the Trace View 評価機能 概要 デバッグによって個々の挙動を分析できるようになったら、次は 評価 （Evaluate）機能を使って、エージェントの品質を体系的に測定し、改善サイクルを回します。 評価機能は、「期待される対話（テストケース）」と「実際の対話」を比較し、その品質をスコアで定量化するためのインタラクティブな機能です。評価は、主に「テストケース作成」「評価の実行」「結果の分析」という3つのステップで構成されます。 1. テストケースの作成 まず、評価の基準となる「正解」の対話シナリオをテストケースとして作成します。 Web UI 上でエージェントと対話し、期待に近い応答が得られたセッションを作成します。その後、画面右側の Eval タブで評価セットを作成または選択し、 Add current session ボタンで現在の会話をテストケースとして保存します。 保存したテストケースは、編集アイコンから応答テキストを修正するなど、より理想的なシナリオに編集することも可能です。 2. 評価の実行 次に、準備したテストケースを使ってエージェントの性能を評価します。 評価セットから実行したいテストケースを選択し、 Run Evaluation ボタンをクリックします。評価時には、以下のメトリクスに対する合格閾値を設定します。 Tool trajectory avg score : 期待されるツールの使用順序や引数と、実際のものとの一致度。 Response match score : 期待される最終応答と、実際の応答との意味的な類似度。 Start をクリックすると評価が実行されます。 3. 結果の分析 評価が完了したら、結果を分析して次の改善アクションに繋げます。 結果一覧に Fail がある場合、 Fail にカーソルを合わせると、 Actual （実際の出力）と Expected （期待される出力）の比較や、どのスコアが閾値を下回ったかが表示され、失敗の原因を把握できます。 評価で失敗したケースは、デバッグの対象です。Trace ビューや Events ビューを使い、なぜ期待と異なる挙動になったのかを詳細に調査しましょう。 参考 : How to run Evaluation with the ADK 実践 実践例 次に、公式のクイックスタートエージェントを例に、実際のデバッグと評価のサイクルを紹介します。 参考 : クイックスタート: Agent Development Kit でエージェントをビルドする 1. 正常系の動作確認 まず、 adk web でUIを起動し、 multi_tool_agent に「What is the weather in New York?」と質問します。 Trace ビュー を開くと、 call_llm （思考）→ execute_tool[get_weather] （ツール実行）→ call_llm （最終応答）という一連のEventの流れが可視化され、エージェントが正しく動作していることを確認できます。 2. 異常系のデバッグ 次に、エージェントが対応していない「What is the weather in Okinawa?」と質問してみます。 Events ビュー に切り替えて Event リストを確認します。ツール呼び出し時の応答 functionResponse を調査します。 Event 詳細ビューで Event > response を見ると、エージェントからの応答（response）を確認できます。 これにより、エージェントはツールを呼び出そうとしたものの、ツール自体が「Okinawa」に対応していないためエラーになった、という事実を特定できます。 3. プロンプトの調査と改善 では、なぜエージェントは対応していない都市でもツールを呼び出そうとしたのでしょうか。 Events ビュー の、ツール呼び出し後の text を調査します。 Event 詳細ビューで Request > system_instruction を見ると、エージェントへの指示書（プロンプト）を確認できます。この指示書に「New York にしか対応していない」という情報が不足していれば、エージェントが他の都市でもツールを呼び出そうとするのは自然な挙動です。 このように、エージェントの意図しない挙動は、プロンプトやツールの説明文（docstring）をより明確に記述することで修正できる場合が多くあります。 4. 回帰テストの作成 ステップ1で確認した「正常系の動作」の対話セッションを、テストケースとして保存します。 これは、将来的にコードを変更した際に、この正しい挙動が壊れていないか、つまり回帰（リグレッション）していないかをチェックするために重要です。このようなチェックを回帰テスト（リグレッションテスト）といいます。 期待に近い結果をテストケースとして保存しておけば、将来の回帰テストに利用できます。またテストケース内のやりとりを修正してより期待に近づけ、プロンプトチューニングの際の評価に利用することもできます。 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の武井です。当記事では、Google Cloud が提供するセキュリティ運用プラットフォームである Google SecOps を徹底解説します。 Google SecOps とは 概要 主な特徴 主な機能 エディションと料金体系 用語と機能 Security Information and Event Management（SIEM） Security Orchestration, Automation, and Response（SOAR） Cloud-Native Application Protection Platforms（CNAPP） Security Command Center（SCC） SCC Enterprise Mandiant と Google Threat Intelligence（GTI） VirusTotal Gemini データ取り込み（SIEM） 概要 直接取り込み データフィード Cloud Run functions Bindplane 概要 エディション 構成要素 Bindplane Server Collector や Gateway のデプロイパターン Forwarders（非推奨） Ingestion API Namespace ログ取り込み監視 ログの正規化（SIEM） パーサーと UDM UDM の構造 UDM イベント UDM エンティティ UDM フィールド デフォルトパーサー カスタムパーサー パーサーの管理 パーサー拡張機能 脅威検知（SIEM） インテリジェンスと IoC Matches Curated Detections Curated Detections の使用方法 YARA-L ルール YARA-L ルールの基本構造 単一イベントルールとマルチイベントルール 単一ルール マルチイベントルール YARA-L ルールの変数 YARA-L ルールの特殊文字 YARA-L ルールサンプル ログの検索 ケース管理と対応自動化（SOAR） ケースとは ケース化のメカニズム Playbooks Playbooks の構成要素 Playbooks の管理 ダッシュボード 概要 ネイティブダッシュボード レガシーダッシュボード SIEM ダッシュボード SOAR ダッシュボード SOAR レポート Google SecOps MCP server 認定資格 関連記事 Google SecOps とは 概要 Google Security Operations （以下、 Google SecOps 、旧称 Chronicle）は、SIEM、SOAR、脅威インテリジェンス、AI（Gemini）を統合した Google Cloud のセキュリティ運用プラットフォームです。 従来のセキュリティ運用では、ログの収集・検索、検知ルールの管理、インシデントの調査や対応といったプロセスがそれぞれの製品・ツールごとに分かれており、運用面に課題がありました。 Google SecOps はこれらを一つのクラウドネイティブな基盤上で統合し、 ログ分析 > 脅威検知 > 調査 > 自動対応 を一気通貫で実現します。 Google の大規模インフラが可能にするスケーラビリティ、Mandiant / VirusTotal などを含む豊富な脅威インテリジェンス、そして Gemini による自然言語での運用支援により、これまで専門知識や人材に依存していた作業を効率化できるのが大きな特徴です。 参考 : Google SecOps overview 主な特徴 Google SecOps の主な特徴は以下の通りです。 特徴 説明 スケーラブル ペタバイト級のログ検索や数万件規模のルール実行に対応し、大規模環境でも高性能を維持 料金体系 ログデータ量（GB/年）を基本軸としたシンプルな料金体系 Gemini による運用支援 自然言語での質問やアウトプットの生成が可能で、専門知識がなくても効率的な運用が可能 脅威インテリジェンス Google Threat Intelligence に加え Mandiant や VirusTotal の知見を活用し、最新の攻撃や Indicators of Compromise（IoC、侵害の兆候） を迅速に検知 SOAR 機能 アラート管理から Playbooks による自動対応まで一貫して提供し、SOC 運用を効率化 主な機能 Google SecOps の主な機能は以下の通りです 機能 説明 Investigation （調査） ログやエンティティ（ユーザー・端末・IPなどの対象）を検索し、不審な挙動を調べる Detection （検知） ルール、IoC、UEBA（行動分析）に基づきアラートを生成 Cases （管理） 複数のアラートを「ケース」として集約管理（＝インシデント対応の単位） Response （対応） Playbooks でアラート通知後の対応を自動化 Dashboards （可視化） 検知状況をダッシュボードやレポートで把握 Marketplace （拡張） 検出ルールや Playbooks を追加拡張 API （設定） UI に加えプログラマブルな設定、自動化、外部連携が可能 エディションと料金体系 Google SecOps には Standard、Enterprise、Enterprise Plus の3エディションがあり、いずれのエディションにおいても 取り込んだログデータ量 （GB単位/年）が基本的な料金軸です。 Standard エディションでは Gemini AI や Google Threat Intelligence が使用できないため、 基本的には Enterprise もしくは Enterprise Plus エディションが推奨 されます。 BigQuery UDM ストレージは SIEM と SOAR のデータを BigQuery にエクスポートするための、Enterprise Plus エディションのみが利用可能な機能となります。 機能 Standard Enterprise Enterprise Plus SIEM / SOAR の基本機能 〇 〇 〇 Curated Detections（Google 提供の検出ルール） – 〇 〇 UEBA（ユーザーとエンティティの行動分析） – 〇 〇 Gemini AI による運用支援 – 〇 〇 Google Threat Intelligence – 〇 〇 Mandiant / VirusTotal との統合 – – 〇 Applied Threat Intelligence – – 〇 BigQuery UDM ストレージ – – 〇 参考： 料金 Google SecOps は Google Cloud と統合されていますが、オーダー方法などが他の Google Cloud プロダクトとは異なる特殊なプロダクトです。オーダーや料金等に関する詳細については、Google または販売パートナーのセールス担当者にお問い合わせください。 用語と機能 Security Information and Event Management（SIEM） 組織内の様々な IT システムリソース・機器、アプリケーションから、膨大な量のログやデータが日々出力されています。これらのログには、IT リソースに対する攻撃の痕跡や兆候も記録されていますが、単純に1つ1つのログを閲覧するだけでは気付くことが出来ません。 Security Information and Event Management （SIEM） はこれら大量のログを一元的に収集し、リアルタイムに相関分析し、攻撃や脅威の兆候、つまり不審なアクティビティや攻撃のパターンを自動的に検出するソリューションです。 SIEM により、セキュリティ運用者は全体像の把握が容易になり、運用の効率を飛躍的に向上させることができます。 参考： Google Security Operations SIEM overview Security Orchestration, Automation, and Response（SOAR） Security Orchestration, Automation, and Response は「セキュリティオーケストレーション、自動化、レスポンス」を意味しており、通常は SOAR と略されて呼称されます。SOAR は、SIEM によって脅威が検知された後の対応プロセスを自動化・効率化するためのソリューションです。 参考： Google Security Operations SOAR Overview インシデントが発生した際、アナリストは影響範囲の調査、関連情報の収集、隔離措置、関係者への報告など、多くの手作業に追われます。SOAR は、これらの定型的な作業を Playbooks （プレイブック）と呼ばれる一連のワークフローとして定義し、自動で実行させることができます。 例として、以下のような作業を Playbooks により自動化できます。 疑わしい IP アドレスやドメインのレピュテーション（評判）を外部の脅威インテリジェンスサービスに問い合わせる 不審なファイルが見つかった場合、サンドボックス環境で実行してその挙動を分析する 感染が疑われるエンドポイントをネットワークから自動的に隔離する 担当者へ Slack やメールで通知し、JIRA などのチケット管理システムにインシデントを起票する Cloud-Native Application Protection Platforms（CNAPP） Cloud-Native Application Protection Platforms （CNAPP） とは、クラウドネイティブ アプリケーションの環境全体を保護するために設計された、統合的なセキュリティプラットフォームのことを指します。 従来のセキュリティ対策は仮想マシン（VM）が中心でした。しかし、コンテナやサーバーレスが中心となるクラウドネイティブ環境では、開発から本番稼働までのライフサイクル全体でセキュリティを確保する必要があります。CNAPP は、これまで別々のツールだった以下の機能を、1つのプラットフォームに統合します。 ツール名 説明 CSPM （Cloud Security Posture Management） クラウドの設定ミスや脆弱性を検出し、コンプライアンスを維持 CWPP （Cloud Workload Protection Platform） コンテナやサーバーレスファンクションなど、実行中のワークロードを保護 CIEM （Cloud Infrastructure Entitlement Management） 過剰な権限を持つ IAM ユーザーやサービスアカウントを検出 Security Command Center（SCC） Google Cloud では、Security Command Center（SCC）が CNAPP としての役割を担い、Google Cloud 環境のアセットを自動的に検出し、潜在的なリスクや脅威を可視化します。 主な機能は以下の通りです。 不審な API コールやマルウェア、暗号通貨マイニングなどの脅威をリアルタイムで検出する VM やコンテナイメージに存在する OS の脆弱性をスキャンし、優先順位をつけて管理・報告する 「ストレージバケットが意図せず公開されている」「ファイアウォールルールが緩すぎる」といった設定上の問題を特定・可視化する CIS ベンチマークなどの業界標準に準拠しているかを継続的に評価する SCC で検知した脆弱性や設定ミス、脅威イベントを Google SecOps に取り込むことで、検知後の対応を自動化することも可能です。 Security Command Center は、Google SecOps とは別プロダクトとして位置づけられており、Google Cloud の中でスタンドアロンのプロダクトとしても使用できます。Security Command Center についての詳細は、以下の記事も参照してください。 blog.g-gen.co.jp SCC Enterprise SCC の Enterprise ティアを利用している場合、 Google SecOps 機能 を SCC の拡張機能として利用することもできます。 ただし、ログ取り込み、Curated Detections（マネージドな脅威検出ルール）、YARA-L ルール（カスタムな脅威検出ルール）、SOAR など、各種機能に通常の SecOps とは異なる上限が設定されています。（2025年12月時点） 機能 上限 ログ取り込み Curated Detections で対応可能なサービスのログに限定 Curated Detections Cloud Threats のうち、Google Cloud、AWS、Azure に関する脅威検出に限定 YARA-L ルール 最大20個の単一イベントルールに限定 SOAR Curated Detections で対応可能なサービスならびに一部の ITSM、コミュニケーションツールとの統合に限定 Gemini 自然言語検索とケース調査の概要に限定 ログ保持期間 3ヶ月（通常の SecOps は12ヶ月） 上記を含むその他の詳細は以下の公式ドキュメントをご確認ください。 参考： Security Command Center Enterprise の Google Security Operations 機能の上限 参考： サポートされている Google SecOps ログデータの収集 参考： クラウド脅威のカテゴリの概要 参考： サポートされている Google Security Operations の統合 Mandiant と Google Threat Intelligence（GTI） Google は独自の脅威インテリジェンスデータベースとして Google Threat Intelligence （GTI）を運用しています。Google SecOps はこの GTI と連携し、組織内に存在する既知の脅威をリアルタイムで検知します。 参考 : Google Threat Intelligence - 攻撃者を把握 | Google Cloud 一方で攻撃側も日々新しい手法やツールを考案し、既存のナレッジで検出できない攻撃を仕掛けてきます。これに対応するために、Google のセキュリティチームが世界中のネットワークを監視しています。 Mandiant サイバーセキュリティコンサルティング もそのうちの一つであり、GTI の運用だけでなく、顧客に対するセキュリティコンサルティングサービスを提供しています。 参考 : Mandiant サイバー セキュリティ コンサルティング | Google Cloud VirusTotal VirusTotal は、指定されたファイルや URL がマルウェアで汚染されていないかを確認することができるウェブサービスです。また、セキュリティ研究者向けの機能や、エンタープライズ向けの有償サービスも提供しています。 Google SecOps は VirusTotal と連携しており、SecOps が発見した IoC を VirusTotal で確認・可視化することなどが可能です。 参考 : VirusTotal 参考 : VirusTotal の情報を表示する | Google Security Operations | Google Cloud Gemini Google SecOps には、Google の生成 AI「 Gemini 」が統合されており、セキュリティ運用にかかる負担を大幅に軽減できます。 後述する検索クエリの作成、脅威検出ルールや Playbooks の設計、アラートの根本原因調査など、専門知識に依存する作業を自然言語で支援し、 人手での試行錯誤やそれに伴う工数を削減 します。 参考： Use Gemini in Chronicle SecOps データ取り込み（SIEM） 概要 Google SecOps は、Google Cloud や Google Workspace に加え、 数多くの外部製品との連携が可能 です。 そのため、分散していたログ管理を Google SecOps に集約し、単一のビューで相関的な分析と脅威検知ができます。 参考： Google SecOps ログの取り込み Google SecOps のログ取り込みには以下のような方法があります。 名称 説明 直接取り込み Google Cloud や Google Workspace から直接 SecOps にログを挿入 データフィード Amazon S3 やサードパーティ API などから SecOps にログを挿入 Cloud Run functions Google 提供の Python スクリプトから SecOps にログを挿入 Forwarders Linux / Windows Server 等にインストールするエージェント Bindplane Linux / Windows Server 等にインストールするエージェント Ingestion APIs Google SecOps が用意するデータ取り込み用 API 直接取り込み Google Cloud および Google Workspace に関するログデータは、Cloud コンソールや Google SecOps 専用の管理コンソール（以下、SecOps UI）から直接取り込めます。 Cloud Logging のログ Cloud Asset のメタデータ Security Command Center の検出結果 Google Workspace アクティビティログ 直接取り込みによるログ連携はシンプルな操作で完結します。詳細は以下をご確認ください。 参考： Google Security Operations に Google Cloud データを取り込む 参考： Google Workspace のデータを Google SecOps に送信する データフィード Google SecOps では、AWS、Azure、その他 SaaS など、Google Cloud 以外の環境のログデータを取り込む仕組みとして データフィード機能 があります。 SecOps UI もしくは Feed Management API を用いて、ログソース（Amazon S3、Cloud Storage、Pub/Sub、Webhook など）を指定し、各種ログを SecOps に取り込む設定を行います。 ソースタイプ 概要 ストレージ Google Cloud、AWS、Azure のクラウドストレージバケットに保存されたログデータを定期的に取得 Amazon SQS S3 バケットの通知をキュー経由で受信し、ログデータを取得（リアルタイムかつ安定的に取り込み） ストリーミング Amazon Data Firehose、Cloud Pub/Sub、Webhook などを経由し、SIEM の HTTPS エンドポイントにログデータをストリーミングでプッシュ サードパーティ API CrowdStrike、SentinelOne、Palo Alto など、外部 SaaS から API 経由でログデータを取得 参考： フィード管理の概要 Cloud Run functions データフィードに対応していない SaaS のログデータの取り込みや、取り込み前にログデータを整形・フィルタリングしたい場合、Cloud Run functions を使用してログデータを取り込めます。 Box や Trend Micro など、一部の SaaS については Google が作成した Python スクリプト（Cloud Run functions でデプロイする前提のコード）が提供されています。 Pub/Sub を除くすべてのスクリプトは、ソースデバイスから定期的にデータを収集するように実装されています。 参考： Cloud Run functions としてデプロイされた取り込みスクリプトを使用する Bindplane 概要 Linux や Windows といったクラウドやオンプレミス上のサーバーのログやテレメトリデータの取り込みには、 Bindplane と呼ばれる収集エージェントが使用できます。 Bindplane では収集したデータを正規化したり、正規表現に一致するログを削除したりするなどのエンリッチメントが可能で、単なる収集エージェントというよりは、 テレメトリパイプライン として位置づけられています。 参考： Google SecOps で Bindplane を使用する エディション Google SecOps では Bindplane（Google エディション）が無料で利用できます。 さらに、Enterprise Plus エディションを契約しているの場合、上位互換にあたる Bindplane Enterprise（Google エディション）も無料で利用できます。 参考： Bindplane の Google エディション 以下の用途で Bindplane を使用する場合、Bindplane Enterprise が推奨されます。 大規模環境でのログデータ取り込み 正規表現以外の高度なフィルタリング機能を使用したログデータ加工 個人情報（PII）の秘匿化 構成要素 Bindplane は以下の3つに分類されます。 コンポーネント 役割 Server Bindplane の管理サーバーで、Controller（エージェント）の集中管理を担う Collector 旧称 Bindplane Agent、ログやテレメトリデータの転送を行うエージェント Gateway セキュリティ上の都合で直接データ転送ができない Collector に代わってデータを中継・転送するゲートウェイサーバー 参考： ゲートウェイ コレクタをファイアウォールで保護する Bindplane Server Bindplane Server は Bindplane の管理コンソールです。 Bindplane を統括的に運用・管理するコンポーネントで、複数の Collector や Gateway の運用を一元管理するためには必須です。 主な機能 説明 集中管理 Collector や Gateway の起動/停止/再起動といった管理タスクの実行やステータス表示 モニタリング Collector や Gateway の CPU 使用率、メモリ使用率、スループットなどの指標を追跡 アラート通知 Collector や Gateway がダウンした場合や指標のしきい値を超えた場合など、重要なイベントのアラートと通知 構成管理 Collector や Gateway の構成ファイルの編集、環境変数の設定などを適用 管理画面 Web UI からの操作・設定変更を提供 参考： Bindplane 管理コンソール Collector や Gateway のデプロイパターン Bindplane には、環境や用途に応じて、いくつかのデプロイパターンが用意されています。 参考： Bindplane エージェントのアーキテクチャ パターン1：Bindplane Collector をフォワーダーとして機能させる方式 例：Linux サーバーやネットワーク機器などから Syslog を Bindplane Collector に集約し、Google（Google SecOps や Cloud Logging）にログを送信 パターン2：Bindplane Collector から直接送信する方式 例：Syslog 出力に対応していない Windows などの場合、Bindplane Collector をエージェントとして直接インストールし、Google にログを送信 パターン3：Bindplane Collector が複数の Google 送信先にログを送信する方式 例：Google SecOps と Cloud Logging の両方同時にログを送信（SecOps は分析用途、Logging は監査用途といった具合の使い分け） パターン4：Bindplane Gataway 経由でログを転送する方式 例：セキュリティ上の都合で直接データ転送ができない環境において、Bindplane Gataway を介して Google にログを送信 Forwarders（非推奨） Bindplane の他にも Forwarders と呼ばれる Google SecOps 純正の収集エージェントがありますが、対応するフォーマットに限りがあるなど、Bindplane と比べると性能面で劣ります。 Forwarders は2027年1月に提供が終了する予定です。これらから Forwarders は非推奨であり、今後、収集エージェントを利用する場合は Bindplane が推奨されます。 参考： フォワーダーをインストールして構成する 参考： Feature deprecations Ingestion API Ingestion API は、収集エージェントを使用せずに、アプリケーションやシステムから直接 Google SecOps にログデータを送信するための API インターフェイスです。 これにより、オンプレミス・クラウド・SaaS などの多様な環境から、プログラマブルに効率よくデータを取り込むことができます。 主な特徴 説明 エージェント不要 Bindplane や Forwarder を介さず、API 経由で直接 SecOps にログを送信 高い柔軟性 非構造化ログ、SecOps 向けに正規化した UDM ログを送信 重複排除 各ログに付与される一意のバッチ ID に基づき重複処理を防止 Ingestion API には、以下のような API メソッドが用意されています。 メソッド 説明 udmevents UDM イベント（UDM 形式のログ）を送信 unstructuredlogentries 非構造化ログをそのまま送信し、Google SecOps 側で正規化 entities ログ内のユーザー・端末・IP などをエンティティとして登録 logtypes サポートされているログタイプのリストを取得 参考： Ingestion API Namespace Namespace （名前空間）は、アセット（VM やサーバー等）を一意に識別するためにログに付与する識別子です。   Google SecOps では、ログ内の IP アドレスなどをキーにして、アセットの行動履歴（タイムライン）を紐付けます。しかし、複数の取り込み先で IP アドレスやホスト名が重複しているような場合、それらが「同一のアセット」として混同（aliasing）される恐れがあります。   以下のように、ログの取り込み時に Namespace を付与することで、たとえ IP アドレスが同じアセットが複数あったとしても、それらを論理的に異なるアセットとして管理できます。   取り込み先 役割 IP アドレス Namespace Google Cloud Web サーバー 10.0.1.100 GCP AWS DB サーバー 10.0.1.100 AWS オンプレミス ファイルサーバー 10.0.1.100 ONPREM これにより、複数の取り込み先で IP アドレスなどの情報が重複していても正しく分析できるだけでなく、特定の Namespace のデータのみを特定のユーザーグループに閲覧させるといった制御（RBAC）が可能になります。   参考： アセットの名前空間を使用する ログ取り込み監視 Google SecOps へのログ取り込み状況は Cloud Monitoring で監視できます。 Google SecOps 向けの指標はすべて chronicle.googleapis.com/ で始まり、例えば以下のようなものが用意されています。これらを Cloud Monitoring のアラートポリシーやダッシュボードの作成等に利用できます。 指標 表示名 説明 ingestion/log/record_count Total Ingested Log Count 取り込まれたログの合計数（60秒ごとにサンプリング） ingestion/log/bytes_count Total Ingested Log Size 取り込まれたログの合計サイズ（60秒ごとにサンプリング） 例えば上記指標を用いて、ログ転送エージェントが60分間ログを送信しない場合にアラートを送信させることも可能です。このように、来るはずのデータがこない状況を検知するための仕組みを サイレントソース検知 （silent source detection）ともいいます。 参考： 取り込み分析情報に Cloud Monitoring を使用する 参考： chronicle (Google Cloud metrics) ログの正規化（SIEM） パーサーと UDM Google SecOps は多様な製品のログを取り込めますが、当然ながら各製品ごとログフォーマットは異なります。 Google SecOps では、各製品のログが SecOps に送られると、 パーサー （parser）というコンポーネントで UDM （Unified Data Model）形式にパースされます。 これにより、異なる製品の異なるフォーマットのログが1つの形式に統一され、SecOps による分析や脅威検知に利用できるようになります。 以下はベンダーが異なる Firwall 製品のログを UDM で正規化したイメージです。 項目 ベンダー A のログ形式 ベンダー B のログ形式 UDM のログ形式 送信元 IP src=1.2.3.4 srcip=10.3.4.5 principal.ip 宛先 IP dst=2.3.4.5 dstip=20.3.4.5 target.ip 宛先 Port dstPort=55323 dstport=443 target.port アクション deny action="deny" security_result.action 参考： 統合データモデルの概要 UDM の構造 UDM は Google SecOps に取り込まれたログデータを統一的に扱うための共通スキーマ（データモデル）であり、大きく分けて次の2つの構成要素から成ります。 コンポーネント 説明 イベント 発生したセキュリティイベントやアクティビティの情報（ログの本体に相当） エンティティ イベントの主体（ユーザー・端末・IP 等）に関するコンテキスト（背景情報） このようにイベントとエンティティの両方を定義することで、「誰が」「どこから」「何をしたか」を明確にし、脅威のトリアージや相関分析を効率的に行えるようになります。 参考： UDM の構造 参考： 論理オブジェクト: イベントとエンティティ UDM イベント UDM イベントは、 セキュリティ関連の出来事そのもの を表し、例えば、「ユーザーがログインした」、「ファイルが削除された」、「ファイアウォールが通信を拒否した」といったアクションを、UDM の標準化されたフィールドで記述します。 イベントには以下のような情報が含まれます。 セクション 説明 主な項目例 Metadata イベントに関連する一般的な情報。タイムスタンプや製品情報など、イベントのメタデータを保持 event_timestamp , event_type , product_name , vendor_name など Nouns アクティビティに関与したエンティティ（主体）。ユーザー、端末、プロセス、IP などが該当 hostname , ip , mac , user , process など Security_result イベント内で特定されたリスクや脅威、またはそれらを軽減するために取られた措置に関する情報 rule_name , severity , action , threat_name など Network イベントに含まれるネットワークの詳細情報（セッション ID、送受信バイト数など） session_id , direction , ip_protocol , sent_bytes , received_bytes など 参考： UDM イベントの構造 引用：Google Cloud 公式ドキュメントより UDM エンティティ UDM エンティティは、 イベントに関連する登場人物やオブジェクトに関する文脈情報 を補足するものです。例えば、「攻撃元の IP」、「実行ユーザー」、「対象となる端末やアプリケーション」などが該当します。 UDM では、これらのエンティティを次のような役割に分類して整理します。 セクション 説明 主な項目例 Metadata エンティティに関する一般的な情報や、エンティティを生成した製品情報を保持（収集タイムスタンプ、間隔、製品名などのメタデータを含む） product_entity_id , entity_type , product_name , vendor_name など Entity このエンティティが表す名詞（noun）を定義します。ユーザー、アセット、ドメイン、IPアドレスなど、イベント内で識別される対象が該当 asset , user , resource , namespace , labels など Relation 当該エンティティと他のエンティティとの関係性を示す relationship , entity , entity_type , direction など 参考： UDM エンティティの構造 引用：Google Cloud 公式ドキュメントより UDM フィールド UDM イベントとエンティティの全フィールドについては以下のドキュメントに網羅されています。 参考： UDM field list ただし、UDM のフィールド数は膨大なため、SecOps における主要なフィールドについては別途以下のドキュメントも用意されています。 例えば後述するデフォルトパーサーで取り込めないログタイプ（取り込み対象のデータソース）をカスタムパーサーで取り込む場合の指標としても使えます。 参考： Key UDM fields for parsers デフォルトパーサー デフォルトパーサー （事前構築済みパーサー）とは、オリジナルのログデータを UDM フィールドに変換するためのデータマッピングがあらかじめ組み込まれた、Google によって管理・提供されるパーサーのことです。 デフォルトパーサーのリストは、以下のドキュメントで確認できます。 参考 : Supported log types and default parsers カスタムパーサー 取り込み対象の製品向けのデフォルトパーサーが存在しない場合、 カスタムパーサー を使用して独自のデータマッピングをユーザー側で記述します。 カスタムパーサーのリストは、以下のドキュメントで確認できます。 参考： Supported log types without a default parser パーサーの管理 パーサーは SecOps UI や Google SecOps CLI（ secops ）から管理します。 デフォルトパーサーの表示 デフォルトパーサーのアップデート管理 パーサー拡張機能の作成管理 カスタムパーサーの作成管理 なお Google SecOps CLI は chronicle_cli の後継にあたり、パーサーの管理以外にも、フィードの管理や検出ルールの管理など、Google SecOps の様々な機能の管理にも使用されます。 参考 : Manage prebuilt and custom parsers 参考： Parser Management パーサー拡張機能 パーサー拡張機能 （Parser Extensions）は、既存のパーサー（デフォルトパーサーまたはカスタムパーサー）をベースとして、フィールドの更新や拡張といった処理を後付けで適用できる機能です。 サードパーティ製品側の仕様変更などでパース処理を修正したい場合に、ベースのパーサーを直接書き換えることなく、差分のみを適用することができます。 製品側の急な変更にできる限り小さい労力で対応 するには、この機能を使います。 参考： パーサー拡張機能 脅威検知（SIEM） インテリジェンスと IoC Matches Google SecOps は、 Mandiant 、 VirusTotal 、 Google Threat Intelligence （GTI）などの、備え付けの脅威インテリジェンスソースによってキュレーション（推奨）された IoC を自動的に取り込む（ingest）ようになっています。 これらのインテリジェンスは、SecOps に取り込まれた後、UDM イベントデータの継続的な分析に使用されます。これにより、既知の悪意のあるドメイン、IPアドレス、ファイルハッシュ、URL に一致する IoC が自動的に発見 され、一致が見つかった場合はアラートが生成されます。（IoC Matches） 参考： Google SecOps で IoC が自動的に照合される仕組み Curated Detections IoC Matches とは別に、特定の脅威カテゴリをカバーできるよう、 Curated Detections と呼ばれるマネージドなルールセットがあります。 Curated Detections を使用する場合、Enterprise エディション以上の契約が必要です。また UEBA や Applied Threat Intelligence については Enterprise Plus エディションの契約が必要です。 脅威カテゴリ カバーするルールセット Cloud Threats Google Cloud、AWS、Azure、Office 365、Okta Chrome Enterprise Threats Chrome 拡張機能の脅威、Chrome ブラウザの脅威 Windows Threats 異常な PowerShell、暗号通貨マイニング、ランサムウェア など Linux Threats 権限の昇格や変更、マルウェアによる不審なアクティビティ、Mandiant が評価した脅威 など macOS Threats Mandiant が評価した脅威 Risk Analytics for UEBA 認証、ネットワークトラフィック、ピアグループ、不審なアクティビティ、データ損失 Applied Threat Intelligence Mandiant Threat Intelligence によるネットワークやホスト関連の IoC 特定 参考： Use the curated detections page Curated Detections の使用方法 Curated Detections は対象のログソースがある状態で、SecOps UI から一括あるいは個別に有効化するだけで使用可能となります。 有効化の際、ルールの動作モードとして Precise （高精度）と Broad （広範囲）を選択できます。 前者の場合、信頼性の高いアラートを生成するため誤検知が少なくなります。一方後者の場合はヒューリスティックなアラート検出を行うため、異常検知をしやすくなる反面、誤検知の可能性も高くなります。 参考： Modification of all the rules in a rule set YARA-L ルール パーサーによって正規化され UDM となったイベントデータは、前述のとおり Google のインテリジェンスによって自動的に分析されますが、独自の検知ルールを定義したい場合は YARA-L 2.0 という構文を用いて記述することができます。 参考： YARA-L 2.0 言語の概要 YARA-L 2.0 は UDM に対する検索にも用いられます。また YARA-L 2.0 の記述には、生成 AI モデルである Gemini の力を借りることもできます。ルールエディタで Gemini に対して自然言語で目的などを指示することで、YARA-L ルールを記述することができます。 参考： Gemini を使用して YARA-L ルールを生成する YARA-L ルールの基本構造 YARA-L ルールはルール名と最大6つのセクションから構成されます。 セクション 必要性 説明 meta 必須 ルールに関するメタデータ（Key-Value）で、 author 、 description 、 severity 、 version など events 必須 検出対象とする UDM イベントの条件を定義。SQL の WHERE 句に相当し、演算子を省略した場合は自動的に and が適用 match 任意 events セクション内で定義した変数を基に検出イベントをグループ化。SQL の GROUP BY に相当 outcome 任意 検知結果に含めたい追加情報。例えば count() や array_distinct() 関数を用いて、検出対象の件数や一覧を出力 condition 必須 検知をトリガーする条件。例えばイベント変数 $e を使用し、条件が一致した場合にルールをトリガーするように定義 options 任意 ルールの実行方法の制御で使用し、2025年10月現在、設定できるのは allow_zero_values = true （マッチ結果が空でもルールをトリガーする）のみ 参考： YARA-L 2.0 language syntax 単一イベントルールとマルチイベントルール 単一イベントルールとは、1種類のログイベントのみを対象とし、そのレコード単体の条件一致や発生回数などで脅威検知を行うルールです。特定のイベント種別における「回数の多さ」や「頻度の異常」を検出する用途に適しています。 一方のマルチイベントルールは、複数のログイベント間の時系列や相関関係を条件に含めるルールで、単一イベントだけを見ても判断しづらい脅威の「意図」や「文脈」をより正確に捉えることができます。 ここでは「ブルートフォース攻撃の検知」を例に両者の違いを確認します。 単一ルール 以下は 同じユーザーが1時間以内に複数回ログインに失敗した場合を検出 する単一イベントルールの例です。 このルールでは、「同一ユーザーで失敗イベントが一定回数を超えたかどうか」だけに着目しており、ユーザーがその後ログインに成功したかどうかまでは考慮していません。 rule single_event_rule_example { meta : author = "ACME Corp" description = "Multiple consecutive failed logins" severity = "Medium" events : $fail.metadata.log_type = "OKTA" $fail.metadata.event_type = "USER_LOGIN" $fail.security_result.action = "BLOCK" $fail.target.user.userid = $user match : $user over 1h outcome : $fail_principal_ip = array_distinct($fail.principal.ip) $fails_before_success = count_distinct($fail.metadata.product_log_id) $last_failure = max($fail.metadata.event_timestamp.seconds) condition : #fail > 10 } マルチイベントルール 以下は 同じユーザーが複数回ログインに失敗した後でログインに成功した場合を検出 するマルチイベントルールの例です。 このルールでは成功と失敗（ $success 、 $fail ）という2種類のイベントを同じユーザー（ $user ）で関連付け、 events と outcome で時系列で表しています。 単に失敗回数が多いだけのケース（パスワード忘れなど）ではなく、 「多数の失敗のあとに成功している = ブルートフォースが成功した可能性がある」 という、より意味のあるパターンにフォーカスして検知できるようになります。 rule multi_event_rule_example { meta : author = "ACME Corp" description = "Multiple consecutive failed logins, followed by a success" severity = "Medium" mitre_attack_technique = "Brute Force" mitre_attack_technique_id = "T1110" events : $fail.metadata.log_type = "OKTA" $fail.metadata.event_type = "USER_LOGIN" $fail.security_result.action = "BLOCK" $fail.target.user.userid = $user $success.metadata.log_type = "OKTA" $success.metadata.event_type = "USER_LOGIN" $success.security_result.action = "ALLOW" $success.target.user.userid = $user $fail.metadata.event_timestamp.seconds < $success.metadata.event_timestamp.seconds match : $user over 1h outcome : $fail_principal_ip = array_distinct($fail.principal.ip) $success_principal_ip = array_distinct($success.principal.ip) $fails_before_success = count_distinct($fail.metadata.product_log_id) $first_success = min($success.metadata.event_timestamp.seconds) $last_failure = max($fail.metadata.event_timestamp.seconds) condition : #fail > 10 and $success and $first_success >= $last_failure } 参考： Single event rule 参考： Multiple event rule YARA-L ルールの変数 YARA-L では、ルール内で UDM イベントを柔軟に扱うために変数（ $variable の形式）と特殊文字が使用できます。 以下のサンプルルールは、Office 365 への macOS 端末からのログインイベントを識別するルールであり、ユーザーIDとIPアドレスを変数化し、30分間の同一組み合わせをグループ化しています。 rule office365_mac_os_login { meta : author = "ACME Corp" description = "Identifies an Office 365 login on a mac os" severity = "Low" events : $e.metadata.event_type = "USER_LOGIN" $e.metadata.log_type = "OFFICE_365" $e.principal.platform = "MAC" $e.security_result.action = "ALLOW" $e.target.user.userid = $account $e.principal.ip = $ip match : $account, $ip over 30m outcome : $target_user_userid = array_distinct(strings.to_lower($e.target.user.userid)) $security_result_summary = array_distinct($e.security_result.summary) condition : $e options : allow_zero_values = true } 変数 使用セクション 説明 イベント変数 events outcome condition UDM イベントそのものを表す変数で、events セクションを $e と宣言してイベント全体を参照し、condition セクションで検知条件として指定 プレースホルダー変数 events match outcome condition イベント内の特定のフィールドの値を一時的に保持する変数。 $e.target.user.userid = $account のように設定し、他イベントや時間範囲で比較・グループ化するために使用 一致変数 match 複数のイベントをグループ化するための変数。 SQL の GROUP BY に相当し、同一アカウント・同一 IP などの条件でイベントをまとめる。 例： match: $account, $ip over 30m （30分間の同一ユーザーと IP の組み合わせをグループ化） 参考： 変数 YARA-L ルールの特殊文字 変数の前に # を付けると、その変数にマッチしたイベントの件数をカウントできます。 これはカウント文字と呼ばれる特殊文字で、主に condition セクションで使用します。 例えば以下は、同一ホストから複数ユーザーのログイン失敗が発生した場合を検出するルールです。 rule win_password_spray_kc { meta : author = "Chronicle Security" description = "Detect repeated authentication failure with multiple users from a single origin." severity = "Low" events : $event.metadata.event_type = "USER_LOGIN" $event.metadata.vendor_name = "Microsoft" $event.security_result.action = "BLOCK" $event.principal.hostname = $principalHost $event.target.user.userid = $targetUser match : $principalHost over 30m outcome : $targetUser_distinct_count = count_distinct($targetUser) $targetUser_uniq_list = array_distinct($targetUser) condition : #targetUser > 10 } 上記サンプルにおける condition セクションのカウント文字 #targetUser > 10 は、 そのホストから10件を超える異なるユーザーの失敗イベントがあった場合 を検知ルールのトリガー条件としています。 参考： カウント文字 YARA-L ルールサンプル Curated Detections とは別に、 Google 管理の YARA-L ルールサンプル も提供されています。 Curated Detections の使用には Enterprise エディション以上の契約が必要ですが、こちらのルールサンプルはどのエディションでも無料で使用可能です。 詳細は以下の公式ドキュメントや GitHub をご確認ください。 参考： デフォルトの検出ルール 参考： detection-rules ログの検索 Google SecOps の SIEM では、 Raw Log Search と UDM Search の両方が利用可能です。 Raw Log Search は取り込まれた生ログ（UDM 化される前のログデータ）を対象にし、UDM 検索は正規化されたイベントを検索対象とします。 生ログは、主にデータ取り込み状況の確認やパーサー動作の検証などのトラブルシューティング用途で利用されることが多く、日常的な分析や相関調査では UDM 検索を用います。 検索種別 概要 用途 Raw Log Search 各ベンダー固有フォーマットのログをそのまま検索。文字列一致や正規表現での検索が可能 データ取り込み確認、パーサーの検証、UDM 変換の確認など UDM Search SIEM に取り込まれたログを UDM スキーマに基づいて正規化し、共通フォーマットで検索可能 アラート調査、相関分析、ピボットテーブル・統計的検索の利用など UDM 形式に正規化されたデータは、ベンダーごとの項目名や値のばらつきを吸収し、一貫したフィールド名・データ型・列挙値によって統一的な検索により、ログ検索時のフィールド抽出コストを削減し、迅速かつ標準化された分析が可能です。 参考： Use raw log search 参考： Search for events and alerts ケース管理と対応自動化（SOAR） ケースとは Google SecOps の SOAR 機能では、SIEM で作成されたアラートを ケース というチケットとして自動的にグルーピングし、SecOps UI でその後のライフサイクルを管理できる状態に整えます。 ケースとは、関連するセキュリティアラートやイベントを後述するメカニズムによってグルーピングしたもので、端的にまとめると 類似した特徴を持つアラート群 と言えます。 これにより、SIEM で検出した同一の脅威に関連する類似のアラートを効率的かつ効果的に管理することができます。 参考： Cases overview ケース化のメカニズム SOAR によるケース化の条件には以下の基準があります。 条件 説明 エンティティ アラートに関与する主体（ユーザー・端末・IP アドレス等）が同一である 発生時刻 アラートの発生時刻が特定の時間帯で集中している 検出ルール アラートが同一もしくは類似する検出ルールによって生成されている なお、デフォルトのルールの調整や手動でケース化ルールを作成する場合は、SecOps UI の SOAR Setting から調整可能です。 参考： Configure an alert grouping Playbooks Playbooks （プレイブック）は、SOAR による自動化を実現するアクションの定義オブジェクトです。 Playbooks では、SIEM によって検知されたアラートに対してあらかじめ一連の対応手順を定義することで、自動または半自動でアクションを実行する仕組みです。これにより、対応プロセスを標準化・迅速化できます。 Playbooks の構成要素 Playbooks は次の4つの要素で構成されます。 要素 概要 トリガー （Trigger） Playbooks を起動する条件。特定のアラートやイベントの発生時、またはスケジュールを契機に自動実行される アクション （Action） 実行される処理。例えば「VirusTotal への照会」、「Jira チケット起票」、「ユーザーの無効化」など フロー （Flow） 条件分岐や承認を制御する仕組み。自動判断やアナリストの入力を挟みながら次の処理を決定する ブロック （Block） 再利用可能な処理単位。複数の Playbooksで共通利用できる部品化されたモジュール 参考： Use triggers in playbooks 参考： Manage actions in playbooks 参考： Use flows in playbooks 参考： Work with playbook blocks Playbooks の管理 Playbooks は運用面を考慮した設計と継続的な改善が求められます。SecOps UI では、Playbooks の実行履歴や成功率、稼働環境ごとの傾向を可視化でき、運用状況を踏まえた最適化が可能です。 Marketplace を活用すれば、Google や外部ベンダーが提供する Playbooks や Block を追加・再利用できます。これにより、新しい検知ルールや自動化タスクを迅速に取り込み、既存ワークフローに統合できます。 また Gemini を利用することで、自然言語で「目的」「トリガー」「アクション」「条件」を指示するだけで Playbooks の雛形を生成でき、設計工数を大幅に削減できます。 一方で、Playbooks で すべてを自動化するのは現実的ではなく 、次のような判断軸を持つことが重要です。 対応の種類 自動化の可否 例 定型的・繰り返し発生する対応 〇 ログイン失敗の調査、マルウェア検知後の隔離、レピュテーション照会など 分析や意思決定を伴う対応 △ インシデントの深刻度評価、例外対応、再発防止策の検討など（アナリストの判断が適宜必要なもの） このように、 どの工程を自動化し、どの工程を人が判断するか を明確に切り分けることが、Playbooks の設計では非常に重要な観点です。 Google SecOps では、この考え方を基本とし、Sec Ops UI での統合管理・Marketplace での拡張・Gemini での支援を組み合わせることで、Playbooks を継続的に最適化していくことができます。 参考： Use the Google SecOps Marketplace (SOAR only) 参考： Create and edit a playbook with Gemini ダッシュボード 概要 Google SecOps には、蓄積されたログデータやケース対応状況を可視化するための ダッシュボード機能 が備わっています。 ダッシュボードは大きく分けてネイティブとレガシーの2種類がありますが、基本的には YARA-L ベースの ネイティブダッシュボード の利用が推奨されます。 2025年12月時点では、以下4つのダッシュボード機能が確認できます。 メニュー名 分類 説明 ネイティブダッシュボード Native YARA-L 構文ベースの標準ダッシュボード。SIEM や SOAR の可視化に使用 SIEM ダッシュボード Legacy 従来版のダッシュボード。現在は新規作成不可（非推奨） SOAR ダッシュボード Legacy 従来版のダッシュボード。SOAR データの可視化に使用 SOAR レポート Legacy 従来版の SOAR データのレポート生成機能 参考： ダッシュボードの概要 ネイティブダッシュボード ネイティブダッシュボード は、YARA-L 構文を使用して作成される Google SecOps の標準ダッシュボード機能です。 ネイティブダッシュボードには Curated ダッシュボード と呼ばれる、Google が提供する事前構築済み（マネージドな）ダッシュボードが豊富に用意されており、SIEM と SOAR データの可視化に幅広く対応しています。 Curated ダッシュボードの一部 Curated ダッシュボードは YARA-L に基づき構成されているため、既存ダッシュボードの YARA-L クエリを参考に、独自のダッシュボードを作成することも可能です。 また、インポート/エクスポート機能も兼ね備えているため、別の SecOps インスタンスのダッシュボードを取り込むこともできますし、レポート機能を使ったレポート生成（PNG/JSON/PDF 形式）が可能です。 参考： PCI キュレート ダッシュボードの概要 参考： 一般的なキュレートされたダッシュボードの概要 参考： ダッシュボードを管理する レガシーダッシュボード SIEM ダッシュボード ネイティブダッシュボードがサポートされる以前よりあった従来版のダッシュボードで、SIEM データの可視化に使用されていました。 当社環境においては、2025年12月時点で利用できなくなっており、公式ドキュメントにも記載の通り、今後はネイティブダッシュボードの利用が推奨されます。 参考： ダッシュボードの概要 SOAR ダッシュボード SOAR データの可視化を目的とした従来版のダッシュボードで、ケース対応の状況（SOC Status）やプレイブックの実行状況（Playbooks Dashboard）を可視化するための事前構築済みダッシュボードの用意もありますが、以下のようにネイティブダッシュボード側にも同様の Curated ダッシュボードが用意されています。 SOAR 向けの Curated ダッシュボード 参考： SOAR ダッシュボードの概要 SOAR レポート SOAR ダッシュボードのレポート管理機能となり、PDF または Word 形式でレポートを生成できます。 スケジュール機能も兼ね備えており、日次/週次/月次 レベルで指定した時間に指定の宛先にレポートを送信することも可能です。 なお当社環境においては、以下の警告とともに高度な SOAR レポート機能が2025年12月時点で利用できなくなっています。 参考： SOAR レポートの詳細 参考： SOAR レポートで Looker Explores を使用する Google SecOps MCP server Google SecOps MCP server は、Google Cloud が提供する Google Cloud MCP Servers の 1 つです。Gemini CLI などの MCP クライアントから、自然言語で Google SecOps を操作することができます。 使用可能な主なツールとユースケースは以下のとおりです。以下は一部抜粋であり、他にも多数のツールがあります。 カテゴリ ツール ユースケース ケース運用 list_cases , get_case , update_case 未対応ケースの棚卸し、ケース詳細の確認、担当者の更新 検索・調査 translate_udm_query , udm_search , search_entity 検索条件（UDM クエリ）の作成・変換を行い、ログ/イベントを検索して、関連するユーザー/端末/IP などのエンティティを特定 ルール運用 create_rule , list_rules , list_rule_errors 検知ルールの作成と棚卸し、適用・運用上のエラーの把握 取り込み/整備 create_feed , create_parser , list_parsers ログ取り込み設定（フィード）の作成、ログ整形のためのパーサー作成、パーサーの一覧取得 また、以下の記事では Gemini CLI と Google SecOps MCP Server を使ったユースケースについて解説しています。こちらもあわせてご確認ください。 blog.g-gen.co.jp 認定資格 Google Cloud 認定資格である Professional Security Operations Engineer は、Google SecOps や Security Command Center を中心としたセキュリティ運用の知見を問う認定資格です。 Google SecOps の管理・運用担当者や、Google Cloud のセキュリティ担当者は、この資格の学習を経て知識を深めることができます。 blog.g-gen.co.jp 関連記事 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 趣味はロードレースやサッカー観戦、ゴルフ、筋トレ。 Follow @ggenyutakei

G-gen の福井です。Google Workspace Events API と NotebookLM Enterprise API を利用して、Google ドライブ上のファイル操作をトリガーに NotebookLM のノートブック管理を自動化するアーキテクチャと、その実装例を紹介します。 はじめに 当記事の概要 NotebookLM Enterprise とは Google Workspace Events API とは 免責事項 実現したいこと 目的と処理の内容 構成図（To-be） 構成図（Can-be） イベント処理方式について 事前準備 デベロッパープレビュープログラムへの登録 各種APIの有効化 サービスアカウントの準備と権限移譲 サービスアカウントの作成 ドメイン全体の委任の設定 Pub/Sub の準備 サンプルアプリケーション ファイル構成 ライブラリのインストール 環境変数の設定 Google Workspace Events APIでイベントを購読 イベントを処理し NotebookLM を操作 動作確認 はじめに 当記事の概要 NotebookLM は、組織のナレッジ活用に非常に強力なツールですが、運用において課題もあります。例えば、一度ノートブックに登録したソースは、元のファイルが更新されても自動では同期されません。そのため、常に最新の情報を反映させるには、手作業でノートブック内のソースの更新が必要です。また、新しいナレッジのトピックごとにノートブックの作成やソースの追加を手作業で行うのは、運用負荷が高くなりがちです。 当記事では、これらの課題を解決するため、Google ドライブ上のファイルを更新すると、関連する NotebookLM Enterprise のノートブックが自動で作成され、ソースが新規追加・更新される仕組みと実装方法を解説します。 この自動化を実現するために、 NotebookLM Enterprise API と、現在デベロッパープレビュー版として提供されている Google Workspace Events API を使用します。 NotebookLM Enterprise とは NotebookLM Enterprise は、組織の内部情報（ドキュメントやデータ）をソースとして使用する、AI搭載の調査・作成アシスタントです。無償版の NotebookLM や、Google Workspace に付属する NotebookLM Pro とは異なり、Enterprise 版は Google Cloud プロジェクト内で有効化され、より高度な組織利用を前提とした機能が提供されます。 無償版や Pro 版との詳細な機能比較については、以下の記事をご参照ください。 blog.g-gen.co.jp Enterprise 版の特筆すべき点として、まず高度なID連携とアクセス制御が挙げられます。Google Workspace アカウントだけでなく、Microsoft Entra ID や Okta などのサードパーティIDプロバイダーとの連携に対応しており、IAM を使用したアクセス制御も可能です。 また、VPC Service Controls による強固なセキュリティ境界を設定できるほか、サポートするファイル形式として Microsoft Word、PowerPoint、Excel が追加されています。 そして最も重要な特徴として、Enterprise 版は唯一 API が提供されており、当記事で紹介するような外部システムとの連携や業務自動化を実現できます。 参考 : What is NotebookLM Enterprise? Google Workspace Events API とは Google Workspace Events API は、Google Workspace 上で発生するイベント（例: Google ドライブでのファイルの作成・更新、Google Chat のスペースへのメッセージ投稿など）をサブスクライブ（購読）するための API です。 イベントが発生すると、通知エンドポイントである Cloud Pub/Sub トピック に対してリアルタイムに近い形で通知が送信されます。これにより、Google Workspace 上のアクティビティをトリガーとしたアプリケーション連携や自動化処理を実装できます。 当記事執筆時点（2025年10月）では、デベロッパープレビュー版として提供されています。したがって、当記事で解説する内容は一般提供（GA）の際に変更される可能性があることを予めご了承ください。 参考 : Google Workspace Events API 概要 参考 : Google Workspace デベロッパー プレビュー プログラム 免責事項 当記事で紹介するプログラムのソースコードや構成ファイルは、ご自身の責任のもと、使用、引用、改変、再配布して構いません。 ただし、同ソースコードが原因で発生した不利益やトラブルについては、当社は一切の責任を負いません。 実現したいこと 目的と処理の内容 当記事で実装するシステムは、 「特定の Google ドライブフォルダと NotebookLM Enterprise のノートブックを同期させる」 ことを目的としています。 ユーザーの操作をトリガーにシステムがどのように自動処理を行うか、具体的な流れを以下に示します。 処理の流れ ユーザーの操作（Google ドライブ） システムの自動処理（NotebookLM Enterprise） 1 NotebookLM-TopicA フォルダを作成し、最初のファイルを追加する NotebookLM-TopicA ノートブックを新規作成し、追加されたファイルをソースとして登録する 2 NotebookLM-TopicA フォルダに2つ目のファイルを追加する 既存の NotebookLM-TopicA ノートブックに、2つ目のファイルをソースとして登録する 3 NotebookLM-TopicA フォルダ内の既存ファイルを更新する 既存の NotebookLM-TopicA ノートブック内の対応するソースを削除し、改めてソースとして登録する このように、ユーザーは Google ドライブ上でファイルを管理するだけで、意識することなく NotebookLM のナレッジを常に最新の状態に保つことができます。 ただし、今回はノートブック管理自動化の構成検討のきっかけを与えるための記事です。本記事で提示するサンプルは基本動作に留まるため、実際の運用では以下のような考慮が別途必要となります。 Google Workspace イベントのサブスクリプション更新 ノートブックのソースに登録するファイル種類の判定 ノートブックのソースに登録したファイルの移動や削除のハンドリング 同期処理の中で同じソースに対するイベントが複数発生している場合は同期処理を1回にまとめる 例外処理、リトライ処理 ...など 構成図（To-be） 今回実装する自動化システムは、複数の Google Cloud サービスを連携させることで実現します。以下に、本番運用を想定した「あるべきアーキテクチャ」の全体図と、各コンポーネントの役割を解説します。 構成図（To-be） コンポーネント 役割 Google ドライブ ユーザーがノートブックのソースとなるドキュメントを保存・管理する場所です。特定のフォルダへのファイルの追加や更新が、自動化のトリガーとなります。 Google Workspace Events API Google ドライブでのファイル操作を監視し、イベント（ファイルの作成・内容変更など）が発生した際に、その情報を Cloud Pub/Sub へ通知する役割を担います。 Cloud Pub/Sub Google Workspace Events API からの通知を受け取り、メッセージをキューイングします。後述の Cloud Run jobs がこのキューからメッセージを取得（Pull）して処理を開始します。 Cloud Run jobs イベント処理のメインロジック（コンテナ化されたPythonスクリプト）を実行する環境です。 Cloud Scheduler によって定期実行され、Pub/Sub からイベントを一括（バッチ）で取得し、処理します。 Firestore Google ドライブのフォルダやファイル ID と、それに対応する NotebookLM のノートブック ID の対応関係を保存・管理するための NoSQL データベースです。 NotebookLM Enterprise API Cloud Run jobs で実行されるスクリプトからの指示を受け、実際にノートブックの作成、ソースの追加といった操作を実行します。 構成図（Can-be） 当記事ではこのアーキテクチャの中核をなす イベント処理ロジック に焦点を当てます。そのため、実装の解説では Cloud Run jobs の設定までは踏み込まず、Python スクリプトを ローカル環境で実行する 方法をご紹介します。 当記事で実装する範囲の構成図を、以下に記載します。 構成図（Can-be） イベント処理方式について 今回のアーキテクチャでは、イベント処理に Cloud Pub/Sub からの Push 型 ではなく、Cloud Run jobs による Pull 型 の定期実行を採用しています。 その理由は、Google Workspace Events API の性質にあります。ファイルの編集中は、短時間に多数の更新イベントが発生する可能性があり、その都度 Push 型で処理を起動すると、非効率かつコスト増に繋がる恐れがあります。 そのため、一定間隔（例: 5分ごと）でジョブを起動し、Pub/Sub に溜まったイベントをまとめて取得・処理する Pull 型のバッチ処理方式が、コスト効率が良くなります。 事前準備 デベロッパープレビュープログラムへの登録 2025年10月現在、Google Workspace Events API は、デベロッパープレビューのため、Google Workspace デベロッパー プレビュー プログラムへの登録が必要です。 登録に関する内容は、以下の参考サイトをご参照ください。 参考 : Google Workspace デベロッパー プレビュー プログラム 各種APIの有効化 使用する Google Cloud プロジェクトで以下の API を有効化します。 gcloud services enable \ workspaceevents.googleapis.com \ pubsub.googleapis.com \ drive.googleapis.com \ discoveryengine.googleapis.com \ firestore.googleapis.com サービスアカウントの準備と権限移譲 今回の仕組みでは、スクリプトがユーザーに代わって Google ドライブのファイルにアクセスする必要があります。これを実現するために、 サービスアカウント を作成し、「ドメイン全体の委任」という仕組みを使用して、そのサービスアカウントにユーザーデータへのアクセス権を付与します。 ドメイン全体の委任は、ユーザーの同意を必要とせずに、Google Workspace ユーザーのデータにアクセスする権限をアプリケーションに付与できる機能です。 サービスアカウントの作成 サービスアカウントの作成とロール付与 # 環境変数の設定 PIPELINE_GCP_PROJECT_ID =t-fukui NOTEBOOKLM_GCP_PROJECT_ID =massive-clone-455106-n9 SA_NAME =domain-wide-delegation-sa # サービスアカウントの作成 gcloud iam service-accounts create $SA_NAME \ --display-name =" ドメイン全体の委任用のサービスアカウント " # ロール付与（NotebookLM を動かすプロジェクト用） gcloud projects add-iam-policy-binding $PIPELINE_GCP_PROJECT_ID \ --member =" serviceAccount: $SA_NAME @ $PIPELINE_GCP_PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/logging.logWriter " \ --condition = None gcloud projects add-iam-policy-binding $PIPELINE_GCP_PROJECT_ID \ --member =" serviceAccount: $SA_NAME @ $PIPELINE_GCP_PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/pubsub.subscriber " \ --condition = None gcloud projects add-iam-policy-binding $PIPELINE_GCP_PROJECT_ID \ --member =" serviceAccount: $SA_NAME @ $PIPELINE_GCP_PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/datastore.user " \ --condition = None # ロール付与（NotebookLM ノートブック自動管理の仕組みを動かすプロジェクト用） gcloud projects add-iam-policy-binding $NOTEBOOKLM_GCP_PROJECT_ID \ --member =" serviceAccount: $SA_NAME @ $PIPELINE_GCP_PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/logging.logWriter " \ --condition = None 作成したサービスアカウントの OAuth 2 クライアント ID を取得（後の手順で使用） gcloud iam service-accounts describe \ domain-wide-delegation-sa@ $( gcloud config get-value project ) .iam.gserviceaccount.com \ --format =' value(uniqueId) ' ドメイン全体の委任の設定 特権管理者アカウントで Google 管理コンソールにログインします。 Google 管理コンソール：ホーム [セキュリティ] > [アクセスとデータ管理] > [API の制御] > [ドメイン全体の委任を管理] > [新しく追加] を選択します。 ドメイン全体の委任：新しく追加を選択 以下の値を入力して、[承認] を選択します。 項目名 入力値 クライアント ID 前の手順で取得した「サービスアカウントの OAuth 2 クライアント ID」の値 OAuth スコープ https://www.googleapis.com/auth/drive.readonly https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/pubsub 新しいクライアント ID を追加 参考 : API アクセスをドメイン全体の委任で制御する Pub/Sub の準備 Google Workspace Events API からの通知を受け取るための Pub/Sub トピックと、スクリプトがメッセージを読み出すためのサブスクリプションを作成します。 トピックとサブスクリプションの作成 # トピックを作成 gcloud pubsub topics create blog-topic # サブスクリプションを作成 gcloud pubsub subscriptions create blog-subscription --topic = blog-topic --ack-deadline = 600 トピックへのパブリッシュ権限の付与 # トピックIDを取得 export TOPIC_ID = $( gcloud pubsub topics describe " blog-topic " --format =' value(name) ' ) # Workspace Events API のサービスアカウントに権限を付与 gcloud pubsub topics add-iam-policy-binding ${TOPIC_ID} \ --member =" serviceAccount:drive-api-event-push@system.gserviceaccount.com " \ --role =" roles/pubsub.publisher " 参考 : Pub/Sub トピックを作成してサブスクライブする サンプルアプリケーション ファイル構成 今回開発する Python ファイルの構成は以下のとおりです。 ファイル名 用途 xxx-yyy.json ドメイン全体の委任で設定したサービスアカウントのサービスアカウントキーファイル サービスアカウントキーの取り扱いには注意が必要です。詳細は、参考サイト「サービス アカウント キーを管理するためのベスト プラクティス」をご参照ください。 当記事では、検証目的でプログラムをローカルで実行するため、サービス アカウント キーが必要ですが、Cloud Run jobs 等で実行する場合は、サービスにアタッチされたサービスアカウントの情報が使用されるため、サービス アカウント キーは不要です。 .env 環境変数用のファイル create_subscription.py Google Workspace Events APIでイベントを購読するファイル process_events.py 変更イベントを処理し、NotebookLM のノートブックやソースを作成、更新するファイル 参考 : サービス アカウント キーを作成する 参考 : サービス アカウント キーを管理するためのベスト プラクティス ライブラリのインストール サンプルプログラムを動かすために、以下の Python ライブラリをインストールします。 python-dotenv == 1 . 1 . 1 google-auth-oauthlib == 1 . 2 . 2 firebase-admin == 7 . 1 . 0 google-api-python-client == 2 . 181 . 0 google-cloud-pubsub == 2 . 31 . 1 環境変数の設定 設定する値は、ご自身の環境に合わせて変更してください。 .env # ドメイン全体の委任で設定したサービスアカウントのサービスアカウントキーのパス GOOGLE_APPLICATION_CREDENTIALS = " /aaa/bbb/ccc/xxx-yyy.json " # NotebookLM ノートブック自動管理の仕組みを動かす Google Cloud プロジェクト ID PIPELINE_GCP_PROJECT_ID = " xxx " # NotebookLM を動かす Google Cloud プロジェクト 番号 NOTEBOOKLM_GCP_PROJECT_NUMBER = " 123 " # 委任されたユーザーのメールアドレス # ※ ドメイン全体の委任設定を行った組織のユーザーであること # ※ 以下の権限を有していること #　　→ 監視対象のフォルダの共有ドライブのルートに対して「閲覧者」以上の権限 #　　→ Cloud NotebookLM ユーザー（ベータ版）（roles/discoveryengine.notebookLmUser）以上の権限 DELEGATED_USER_EMAIL = " xxx@xxx.co.jp " # 監視対象のフォルダ # ※ 仕様により、共有ドライブのルートフォルダは指定不可です。共有ドライブ内にフォルダを作成して、作成したフォルダを指定してください TARGET_RESOURCE = " //drive.googleapis.com/files/xxx " # 監視の通知先の Pub/Sub トピック名, サブスクリプション TOPIC_NAME = " blog-topic " PUBSUB_SUBSCRIPTION_ID = " blog-subscription " # ノートブックのロケーション NOTEBOOKLM_LOCATION = " global " Google Workspace Events APIでイベントを購読 Google Workspace Events API を使用するには、まず「どのリソース」の「どのイベント」を監視したいかを定義し、「サブスクリプション（購読）」を作成する必要があります。 今回は、特定の Google ドライブフォルダ配下で発生するファイルの作成と内容変更のイベントを購読するサブスクリプションを作成します。 create_subscription.py import json import os import time from typing import Any, Dict from dotenv import load_dotenv from google.auth import default from google.auth.exceptions import RefreshError from google.auth.transport.requests import AuthorizedSession, Request from requests.exceptions import HTTPError # .envファイルから環境変数を読み込む load_dotenv() class DriveSubscriptionCreator : """ Google Workspace Events API を使用して、Google ドライブのリソースに対する サブスクリプションを作成するクラス。 """ def __init__ (self): """共通で使用する変数の初期化、各種クライアントをセットアップする。""" self._set_env_value() self.credentials = self._initialize_credentials() self.authed_session = AuthorizedSession(self.credentials) def _set_env_value (self): """環境変数の値を取得して変数に設定する""" # 必須の環境変数とインスタンス変数名のマッピング required_env_vars = { "DELEGATED_USER_EMAIL" : "delegated_user_email" , "PIPELINE_GCP_PROJECT_ID" : "pipeline_gcp_project_id" , "TOPIC_NAME" : "topic_name" , "TARGET_RESOURCE" : "target_resource" , } # ループで環境変数を取得し、設定されていなければ例外を発生させる for env_name, attr_name in required_env_vars.items(): value = os.getenv(env_name) if not value: raise ValueError (f "環境変数 {env_name} が設定されていません。" ) # setattr() を使ってインスタンス変数（self.xxx）を設定 setattr (self, attr_name, value) def _initialize_credentials (self): """ドメイン全体の委任を使用して認証情報を初期化およびリフレッシュする。""" print ( "認証情報を初期化しています..." ) try : default_credentials, _ = default(scopes=[ "https://www.googleapis.com/auth/drive.readonly" ]) credentials = default_credentials.with_subject(self.delegated_user_email) credentials.refresh(Request()) print ( "認証に成功しました。" ) return credentials except RefreshError as e: print ( "認証エラー: サービスアカウントの権限委任設定を確認してください。" ) print (f "エラー詳細: {e}" ) raise def _create_subscription (self) -> str : """サブスクリプション作成リクエストを送信し、オペレーション名を取得する。""" print (f "サブスクリプションを作成しています... Target: {self.target_resource}" ) body = { "targetResource" : self.target_resource, "eventTypes" : [ "google.workspace.drive.file.v3.created" , "google.workspace.drive.file.v3.contentChanged" , ], "notificationEndpoint" : { "pubsubTopic" : f "projects/{self.pipeline_gcp_project_id}/topics/{self.topic_name}" }, "driveOptions" : { "includeDescendants" : True }, "payloadOptions" : { "includeResource" : True , "fieldMask" : "file.id,file.name,file.mimeType,file.parents" , }, "ttl" : "14400s" , } try : response = self.authed_session.post( "https://workspaceevents.googleapis.com/v1beta/subscriptions" , json=body, ) response.raise_for_status() operation = response.json() print ( "サブスクリプション作成リクエストが受理されました。" ) print ( "LRO:" , json.dumps(operation, ensure_ascii= False , indent= 2 )) return operation[ "name" ] except HTTPError as e: print ( "サブスクリプションの作成に失敗しました。" ) print (f "エラー: {e.response.text}" ) raise def _wait_for_operation (self, op_name: str ) -> Dict[ str , Any]: """Long Running Operation の完了を待つ。""" print (f "オペレーションの完了を待っています: {op_name}" ) while True : try : poll = self.authed_session.get(f "https://workspaceevents.googleapis.com/v1beta/{op_name}" ) poll.raise_for_status() j = poll.json() if j.get( "done" ): if "error" in j: raise RuntimeError (json.dumps(j[ "error" ])) print ( "オペレーションが完了しました。" ) return j.get( "response" , {}) print ( "オペレーションはまだ進行中です。2秒待機します..." ) time.sleep( 2 ) except HTTPError as e: print ( "オペレーションのポーリング中にエラーが発生しました。" ) print (f "エラー: {e.response.text}" ) raise def run (self): """サブスクリプション作成のメインフローを実行する。""" try : op_name = self._create_subscription() result = self._wait_for_operation(op_name) print ( " \n --- サブスクリプション作成完了 ---" ) print (json.dumps(result, ensure_ascii= False , indent= 2 )) print ( "---------------------------------" ) except (HTTPError, ValueError , RuntimeError ) as e: print (f " \n サブスクリプション作成プロセスでエラーが発生しました: {e}" ) if __name__ == "__main__" : try : creator = DriveSubscriptionCreator() creator.run() except Exception as e: print (f "スクリプトの実行に失敗しました: {e}" ) 参考 : Google Workspace サブスクリプションを作成する 参考 : サブスクリプション作成のイベントタイプ イベントを処理し NotebookLM を操作 Pub/Sub に溜まったイベントメッセージを取得し、その情報に基づいて実際に NotebookLM のノートブックとソースを管理するスクリプトを作成します。 このスクリプトは、今回の自動化の仕組みにおける心臓部であり、以下の役割を担います。 Pub/Sub から Drive のイベントメッセージを取得する。 イベント情報からファイルIDを特定し、Drive API で詳細なファイル情報を取得する。 Firestore を使って、Drive のフォルダと NotebookLM のノートブックの対応関係を管理する。 NotebookLM Enterprise API を呼び出し、ノートブックの作成・ソースの追加・更新（削除・追加）を行う。 process_events.py import json import os from typing import Any, Dict, Optional, Tuple from dotenv import load_dotenv from firebase_admin import firestore from google.auth import default from google.auth.exceptions import RefreshError from google.auth.transport.requests import AuthorizedSession, Request from google.cloud import pubsub_v1 from googleapiclient.discovery import build from requests.exceptions import HTTPError # .envファイルから環境変数を読み込む load_dotenv() class DriveEventProcessor : """ Google ドライブのイベントを処理し、NotebookLMと連携するプロセッサ。 """ def __init__ (self): """共通で使用する変数の初期化、各種クライアントをセットアップする。""" self._set_env_value() sa_credentials, delegated_credentials = self._initialize_credentials() # 【委任ユーザーとして操作するAPI】 # Drive, NotebookLM (authed_session) はユーザーのデータにアクセスする self.credentials = delegated_credentials # 互換性のために維持 self.authed_session = AuthorizedSession(delegated_credentials) self.drive = build( "drive" , "v3" , credentials=delegated_credentials) # 【サービスアカウントとして操作するAPI】 # Firestore, Pub/Sub はGCPリソースにアクセスする self.firestore_client = firestore.Client(credentials=sa_credentials) self.subscriber_client = pubsub_v1.SubscriberClient(credentials=sa_credentials) # NotebookLM APIのエンドポイント設定 endpoint_prefix = "" if self.notebooklm_location == "global" else f "{self.notebooklm_location}-" self.notebooklm_base_url = f "https://{endpoint_prefix}discoveryengine.googleapis.com/v1alpha" def _set_env_value (self): """環境変数の値を取得して変数に設定する""" # 必須の環境変数とインスタンス変数名のマッピング required_env_vars = { "DELEGATED_USER_EMAIL" : "delegated_user_email" , "PIPELINE_GCP_PROJECT_ID" : "pipeline_gcp_project_id" , "NOTEBOOKLM_GCP_PROJECT_NUMBER" : "notebooklm_gcp_project_number" , "PUBSUB_SUBSCRIPTION_ID" : "pubsub_subscription_id" , "NOTEBOOKLM_LOCATION" : "notebooklm_location" , } # ループで環境変数を取得し、設定されていなければ例外を発生させる for env_name, attr_name in required_env_vars.items(): value = os.getenv(env_name) if not value: raise ValueError (f "環境変数 {env_name} が設定されていません。" ) # setattr() を使ってインスタンス変数（self.xxx）を設定 setattr (self, attr_name, value) def _initialize_credentials (self) -> Tuple[Any, Any]: """サービスアカウント自身の認証情報と、ドメイン全体の委任を使用した認証情報の両方を返す。""" try : # 共通のスコープでデフォルト（サービスアカウント自身）の認証情報を取得 sa_credentials, _ = default( scopes=[ "https://www.googleapis.com/auth/drive.readonly" , "https://www.googleapis.com/auth/cloud-platform" , "https://www.googleapis.com/auth/pubsub" , ] ) # 委任されたユーザーの認証情報を作成 delegated_credentials = sa_credentials.with_subject(self.delegated_user_email) delegated_credentials.refresh(Request()) print ( "認証に成功しました。" ) # (サービスアカウント自身の認証情報, 委任ユーザーの認証情報) のタプルで返す return sa_credentials, delegated_credentials except RefreshError as e: print ( "認証エラー: サービスアカウントの権限委任設定を確認してください。" ) print (f "エラー詳細: {e}" ) raise def _create_notebook (self, title: str ) -> str : """NotebookLMに新しいノートブックを作成する。""" url = f "{self.notebooklm_base_url}/projects/{self.notebooklm_gcp_project_number}/locations/{self.notebooklm_location}/notebooks" response = self.authed_session.post(url, json={ "title" : title}) response.raise_for_status() return response.json()[ "notebookId" ] def _add_drive_source (self, notebook_id: str , file_id: str , mime_type: str , display_name: str ) -> dict : """NotebookLMのノートブックにGoogle ドライブのソースを追加する。""" url = f "{self.notebooklm_base_url}/projects/{self.notebooklm_gcp_project_number}/locations/{self.notebooklm_location}/notebooks/{notebook_id}/sources:batchCreate" body = { "userContents" : [ { "googleDriveContent" : { "documentId" : file_id, "mimeType" : mime_type, "sourceName" : display_name, } } ] } response = self.authed_session.post(url, json=body) response.raise_for_status() return response.json() def _delete_source (self, notebook_id: str , source_id: str ): """NotebookLMのノートブックからソースを削除する。""" url = f "{self.notebooklm_base_url}/projects/{self.notebooklm_gcp_project_number}/locations/{self.notebooklm_location}/notebooks/{notebook_id}/sources:batchDelete" source_full_name = f "projects/{self.notebooklm_gcp_project_number}/locations/{self.notebooklm_location}/notebooks/{notebook_id}/sources/{source_id}" body = { "names" : [source_full_name]} response = self.authed_session.post(url, json=body) response.raise_for_status() def _get_file_info (self, file_id: str ) -> Optional[Dict[ str , Any]]: """Google ドライブからファイルメタデータを取得する。""" try : return ( self.drive.files() .get( fileId=file_id, fields= "id,name,mimeType,parents,driveId" , supportsAllDrives= True , ) .execute() ) except HTTPError as e: print (f "Driveファイル情報の取得に失敗しました (ID: {file_id}): {e}" ) return None def _get_notebook_folder_info (self, file_meta: Dict[ str , Any]) -> Optional[Tuple[ str , str ]]: """ファイルの親を遡り、ノートブックの基準となるフォルダのIDと名前を取得する。""" path_items = [] parent_id = (file_meta.get( "parents" ) or [ None ])[ 0 ] while parent_id: try : parent_meta = self._get_file_info(parent_id) if not parent_meta: return None path_items.insert( 0 , { "id" : parent_meta[ "id" ], "name" : parent_meta[ "name" ]}) is_shared_drive_root = not parent_meta.get( "parents" ) and parent_meta.get( "driveId" ) if is_shared_drive_root: drive_info = self.drive.drives().get(driveId=parent_meta[ "driveId" ], fields= "name" ).execute() path_items.insert( 0 , { "id" : parent_meta[ "driveId" ], "name" : drive_info[ "name" ]}) break parent_id = (parent_meta.get( "parents" ) or [ None ])[ 0 ] except HTTPError as e: print (f "親フォルダの探索中にエラーが発生しました (ID: {parent_id}): {e}" ) return None # 階層が期待通りかチェック (共有ドライブ > ドライブ(自動で入る) > サブスクリプションフォルダ > ノートブックフォルダ) if len (path_items) >= 4 : notebook_folder = path_items[ 3 ] return notebook_folder.get( "id" ), notebook_folder.get( "name" ) return None def _get_or_create_notebook (self, folder_id: str , title: str ) -> Optional[ str ]: """Firestore/NotebookLMからノートブックを取得または新規作成する。""" notebook_ref = self.firestore_client.collection( "notebooks" ).document(folder_id) notebook_doc = notebook_ref.get() if notebook_doc.exists: print (f "既存のノートブックをFirestoreで発見: '{title}'" ) return notebook_doc.to_dict().get( "notebookId" ) else : print (f "ノートブックが見つかりません。新規作成します: '{title}'..." ) try : new_notebook_id = self._create_notebook(title) print (f "NotebookLMにノートブックを作成しました: {new_notebook_id}" ) notebook_data = { "notebookId" : new_notebook_id, "title" : title, "sources" : {}} notebook_ref.set(notebook_data) print (f "Firestoreにノートブック情報を保存しました: '{title}'" ) return new_notebook_id except HTTPError as e: print (f "ノートブックの新規作成またはFirestoreへの保存に失敗しました: {e}" ) return None def process_drive_event (self, event_data: Dict[ str , Any]): """単一のDriveイベントを処理する。""" file_id = event_data.get( "file" , {}).get( "id" ) if not file_id: print ( "イベントデータにファイルIDが見つかりません。" ) return print (f "イベントを処理中 (File ID: {file_id})" ) file_info = self._get_file_info(file_id) if not file_info: return if file_info[ "mimeType" ] == "application/vnd.google-apps.folder" : print (f "フォルダはスキップします: {file_info.get('name')}" ) return folder_info = self._get_notebook_folder_info(file_info) if not folder_info: print (f "ノートブックフォルダを特定できませんでした: {file_info.get('name')}" ) return notebook_folder_id, notebook_title = folder_info notebook_id = self._get_or_create_notebook(notebook_folder_id, notebook_title) if not notebook_id: return notebook_ref = self.firestore_client.collection( "notebooks" ).document(notebook_folder_id) notebook_data = notebook_ref.get().to_dict() or {} existing_source = notebook_data.get( "sources" , {}).get(file_id) try : if existing_source and existing_source.get( "sourceId" ): print (f "既存ソースを更新します: {file_info['name']}" ) self._delete_source(notebook_id, existing_source[ "sourceId" ][ "id" ]) print (f "古いソースを削除しました: {existing_source['sourceId']['id']}" ) print (f "新しいソースを追加します: {file_info['name']}" ) source_info = self._add_drive_source(notebook_id, file_id, file_info[ "mimeType" ], file_info[ "name" ]) new_source_id = source_info.get( "sources" , [{}])[ 0 ].get( "sourceId" ) if new_source_id: update_path = f "sources.{file_id}" notebook_ref.update( { update_path: { "sourceId" : new_source_id, "displayName" : file_info[ "name" ], "updatedAt" : firestore.SERVER_TIMESTAMP, } } ) print ( "Firestoreのソース情報を更新しました。" ) else : print ( "NotebookLMの応答から新しいSourceIDを取得できませんでした。" ) except HTTPError as e: print (f "ソースの処理中にエラーが発生しました: {e}" ) except Exception as e: print (f "予期せぬエラーが発生しました: {e}" ) print (f "ファイル(ID: {file_id})の処理が完了しました。" ) def run (self, batch_size: int = 10 ): """ Pub/Subからメッセージを取得し、イベント処理ループを開始する。 batch_size の値を大きくしすぎると、Pub/Subメッセージ取得からACKまでの時間が長くなり、確認応答期限を過ぎてメッセージが再送される可能性が高くなります。 """ subscription_path = self.subscriber_client.subscription_path( self.pipeline_gcp_project_id, self.pubsub_subscription_id ) print (f "サブスクリプションをリッスン中: {subscription_path}..." ) total_processed = 0 try : while True : response = self.subscriber_client.pull( subscription=subscription_path, max_messages=batch_size, return_immediately= True ) if not response.received_messages: print ( "処理するメッセージはありません。" ) break print (f "{len(response.received_messages)}件のメッセージを取得しました。" ) ack_ids = [] for msg in response.received_messages: try : event_data = json.loads(msg.message.data.decode( "utf-8" )) self.process_drive_event(event_data) ack_ids.append(msg.ack_id) total_processed += 1 except json.JSONDecodeError as e: print (f "メッセージのJSONパースに失敗しました: {e}" ) ack_ids.append(msg.ack_id) # 処理できないメッセージはACKして再配信を防ぐ except Exception as e: print (f "メッセージ処理中に予期せぬエラーが発生しました。再試行されます。: {e}" ) # エラーが発生したメッセージはACKせず、再配信を待つ if ack_ids: self.subscriber_client.acknowledge(subscription=subscription_path, ack_ids=ack_ids) print (f "{len(ack_ids)}件のメッセージを確認応答しました。" ) except Exception as e: print (f "メッセージ取得ループでエラーが発生しました: {e}" ) finally : self.subscriber_client.close() print ( "サブスクライバーをクローズしました。" ) print (f "--- バッチ処理完了。合計 {total_processed} 件のメッセージを処理しました ---" ) if __name__ == "__main__" : try : processor = DriveEventProcessor() processor.run() except Exception as e: print (f "スクリプトの実行に失敗しました: {e}" ) 参考 : Create and manage notebooks (API) 動作確認 ノートブックが作成されていない状態で、ノートブックの新規作成、ソースの追加・更新の確認を行います。 NotebookLM：トップ画面（動作確認前の状態） 操作1 create_subscription.py を実行します。 操作2 監視対象フォルダに、フォルダを新規作成し、その中にファイルを追加します。 監視対象フォルダ ├── 案件1 │ └── 案件1のファイル └── 案件2 └── 案件2のファイル ファイル種類 名前 ファイルの内容 フォルダ 案件1 − フォルダ 案件2 − Google ドキュメント 案件1のファイル 今日の天気は「えび」です Google スライド 案件2のファイル 好きな食べ物は「羊」です 操作3 process_events.py を実行します。 フォルダに対応したノートブックが作成されています。 NotebookLM：トップ画面（動作確認後の状態） 作成したファイルが正しくソースとして追加されています。 NotebookLM：ノートブック（案件1のソース確認） NotebookLM：ノートブック（案件2のソース確認） 操作4 既存ファイルの更新と、既存フォルダへファイルを追加します。 既存ファイル「案件1のファイル」の内容を 今日の天気は「桜えび」です に変更します。 既存フォルダ「案件2」に、Google ドキュメントのファイルを新規に追加します。（内容： 適度な大きさのえびは「車海老」です ） 操作5 process_events.py を実行します。 更新したファイルが正しくソースとして反映されています。 NotebookLM：ノートブック（案件1の更新ソース確認） 新たに追加したファイルもソースとして正しく追加されています。 NotebookLM：ノートブック（案件2のソース追加確認） 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進

当記事は、ライオン株式会社様と株式会社G-genの 技術情報発信コラボレーション企画 『SAPと連携するデータ分析基盤の実践とTips』で執筆されたものです。 はじめに 概要 データ基盤整備の必要性 「収益力の強靭化」から見据える未来経営とデジタル改革 データ活用環境の課題 目指す姿 構成設計 当初案 大幅な見直しへ SAPデータ活用に向けて Cortex Frameworkの導入検証について 今後の方針 まとめ はじめに 当記事は株式会社G-gen様とライオン株式会社の技術ブログ相互寄稿企画で執筆されたものです。 ライオン側からは、 G-gen様のご協力のもと、Google Cloud環境に構築を進めているデータ基盤に関連した以下3つの記事をシリーズでお届けします。 ライオンのデータ基盤構築とSAPデータ活用体制　👈当記事 ライオンのデータマネジメント ライオンのデータ基盤における分析環境 G-gen Tech Blog の記事一覧 blog.g-gen.co.jp LION Digital Inside の記事一覧 zenn.dev 概要 ライオン株式会社にてデータ基盤まわりを担当しているフクヤマです。 当記事では、ライオンが進めるデジタル改革の1つであるデータ基盤整備について、背景や取組の全体像をご紹介しています。当社では、さまざまなシステムに散らばるデータをどのように一元化し、活用していくかが長年の大きなテーマです。そこで、最新のクラウド技術を活用し、より早く、柔軟に、そして正確に情報を取り扱える仕組み作りに挑戦しています。 私たちが「収益力の強靭化」 や「未来経営とデジタル改革」を実現するために直面している課題や、実際にどのような構成やツールを取り入れてシステムを設計しているか、SAPデータ活用体制を例に、試行錯誤の一端も含めて記載しておりますので、参考にしていただけますと幸いです。 データ基盤整備の必要性 「収益力の強靭化」から見据える未来経営とデジタル改革 当社グループは、経営ビジョン「次世代ヘルスケアのリーディングカンパニーへ」を掲げ、パーパス「より良い習慣づくりで、人々の毎日に貢献する」の実践によるサステナブルな社会への貢献と事業の成長を目指しております。 今年度より「収益力の強靭化」をテーマとした中期経営計画「Ｖｉｓｉｏｎ２０３０ ２ｎｄ ＳＴＡＧＥ」をスタートさせ、3つの基本方針「事業ポートフォリオマネジメントの強化」、「経営基盤の強化」、「ダイナミズムの創出」にもとづく施策を推進しております。 当社デジタル部門は、それらの施策をデジタル面から支え、迅速な経営変革に寄与するため、日々活動に取り組んでおります。 データ活用環境の課題 市場環境の激しい変化や多様化する顧客ニーズに対応し、的確な意思決定を多数かつ高精度に行うためには、データを組織の重要な資産と位置付け、その価値を最大化することが不可欠です。しかしながら、当社のデータ活用には、以下のような課題が存在しています。 データのサイロ化 各種業務システムがオンプレミスおよびクラウド環境に個別に存在しており、データの統合や取得のハードルが高い。 業務システムに対する大量アクセスが集中すると、システム負荷の増大によりパフォーマンス低下や障害発生などのインシデントリスクが顕在化する恐れがある。 ガバナンス 各業務システムから個別にデータを取得しても、属人的なデータ加工および保管が行われると、データ品質の管理が困難になり、誤った意思決定リスクを増大させる。 適切な権限管理の難しさ に伴うデータセキュリティのリスクがある。 スピード・柔軟性の欠如 高品質なデータに基づく迅速な分析および意思決定が難しい状況では、急なビジネスチャンスやリスクへの対応が遅れ、競合他社に対して優位性を失う可能性がある。 データソースの代表格としてはSAPが挙げられます。当社では2022年5月にSAP S/4 HANAを稼働しております。SAPのERPとしての機能の利用は進んだ一方、蓄積されるデータを活用する環境としていくつかのシステムの導入を検討しましたが、費用対効果、可用性の問題で苦戦し断念した経験があります。 近年、当社ではデータサイエンティストやアナリストが活躍する場面が多くなっておりますが、これら専門人材だけではなく全社員がよりデータに基づいて業務遂行するためには、環境整備を必要としていました。 目指す姿 これらの課題を解消する手段として、組織横断でデータを一元管理するデータ基盤をGoogle Cloud上に構築を進めています。データの取り込み・加工・提供までの一連の処理を基盤上で自動化・管理することで、最新の経営情報をより早く提供し、迅速で高精度な意思決定を可能とする体制を目指しています。 前置きが長くなりましたが、次章以降では本基盤の構成検討、およびSAPデータの活用体制について説明します。 構成設計 当初案 当初はSAPデータの早期活用実現を重視し、Google Cloud Cortex Framework（以降、Cortex Framework）というフレームワークの導入を想定していました。また全体構成として、単一のGoogle Cloudプロジェクトに各種機能を集約したシンプルな全体構成を考えていました（Figure 1）。 Figure 1: 当初の全体構成 Cortex Framework SAPデータなどのデータソースからGoogle Cloudに連携した生データの取り込みから活用までの一連の処理に必要なテンプレートを提供しています。例えばSAPデータの場合、複雑に正規化されたデータモデルをBigQueryでそのまま使うことは難しいですが、Cortex Frameworkでは事前定義されたスキーマ変換・ビュー定義が提供されています。 また、GoogleがSAPデータ分析用に設計したLooker用ダッシュボードテンプレートなどを提供しており、ゼロからデータモデル設計をする必要がないため、短期間での分析環境の構築が期待できます。当時、当社にはSAPデータに関する専門知識を備えたデータエンジニアがいなかったため、データ活用までの工数を最小化できる可能性があることが大変魅力的でした。 BigQuery 本基盤の中核となるサービスです。フルマネージドであり費用・運用面でコストメリットが優れており、また、基盤の規模に関わらずユーザリクエストに応じて柔軟にリソース管理が行われ、高いパフォーマンスを示すため、基盤運用側・利用側の双方にとってメリットが大きいです。 Fivetran 本基盤において、SAP（Microsoft Azure上のRISE with SAP）からのデータ連携ツールとして採用しました。Fivetranは、データ連携（同期・CDC機能）の構築・管理を自動化するフルマネージドなデータパイプラインツールです。Google Cloudの複数サービスを組み合わせたパイプライン実装も検討しましたが、当時の当社人材は実装経験が浅く開発工数・運用負荷が多くかかることが予想されたこと、また、短期間でのデータ連携が求められていたことから、フルマネージドな外部ツールでカバーすることにしました。 大幅な見直しへ まず全体構成についてですが、単一プロジェクトから複数プロジェクトの構成に大幅に見直し（Figure 2）、プロジェクトごとの役割・機能、担当者の明確化を行いました。今となっては、この見直しは必然だったように思いますが、全社展開することを想定した場合に、当初案のようなシンプルな構成はリソースの所在の把握はしやすい一方で、リソース管理・責任分界点の定義の難しさなど、結果的に運用・管理が煩雑化しガバナンスが効かなくなることが懸念されました。 Figure 2: 見直し後の全体構成 構成見直しの主な内容は以下です。 レイヤー構造への分解 データの処理の流れを意識し、レイヤー構造に分解することで、各プロジェクトの役割と管轄を明確化しました（Table 1）。このように分解することで、最小権限の原則に則った権限付与に伴うセキュリティの向上や、基盤拡張時にもスケールしやすいものになったと考えます。 Table 1: プロジェクトのレイヤー構造 No レイヤー 役割 管轄 1 DL層 各種データソースから取り込んだデータを保管し、各層にデータを提供する領域 基盤管理部門 2 DWH層 DM層のデータ利用の要望に応じ、分析や集計に適した構造にデータを整えるための領域. DM層の各プロジェクトで共通利用可能なデータを整備. 基盤管理部門 3 DM層 各業務部門の特定の目的に応じて、データを利活用するための領域 業務部門 管理用プロジェクトの新設 複数プロジェクト構成にすることで、リソースの管理・利用状況の監視を一元管理する必要が出てきました。 新設した1つはログ集約用のプロジェクト（Logging Hub project）です。このプロジェクトでは、監査ログを収集するとともに、事前定義した監視対象のリソース操作を検知・アラート発報し、トラブルシューティングや運用改善を図っています。 また、もう1つはデータガバナンス管理用のプロジェクト（Data Governance project）です。このプロジェクトでは、Dataplexの導入を検討しています。このサービスを利用することで、組織内のデータを1つのプロジェクトに集約せずに統合管理が可能です。主にはDL層・DWH層に存在するデータの権限管理の一元化、メタデータ管理によるカタログ化、データ品質チェックを担うことを想定しており、現在検証を進めています。これらの機能は、今後データソース・ユーザが拡大した際には必要性が増すと考えています。また、メタデータ管理については、生成AI活用の観点でも重要なタスクと認識しているため、注力すべき事項と考えています。 Cortex Framework導入見送り いくつかの観点での検証結果から、当社においては導入効果が限定的と判断し、導入を最終的には見送る判断を下し、自社でデータモデリングの設計・実装を進めることにしました。これに伴い、Cortex Frameworkのワークフローのオーケストレーションツールとして導入予定であったCloud Composerは、BigQuery向けデータパイプライン管理ツールであるDataformで代替することにしました（検討内容は次章で説明します）。 SAPデータ活用に向けて Cortex Frameworkの導入検証について 導入見送りの判断を下したのは、前章の通りです。本フレームワークで提供される各種テンプレートはSAP標準テーブルが対象です。そのため、自社の業務要件に応じて作成されるテーブル（カスタムテーブル）を活用するためには、提供テンプレートのカスタマイズが必要になります。この点に特に留意しながら、実施した検証結果は以下の通りです。 当社の場合は、見たい指標や分析項目が開発過程である程度明確化してきたので、このような検証の流れ・結果にはなりましたが、カスタムテーブル数が少なく、SAPデータを使用した分析例を急ぎ検証する必要がある組織は、一度検討してみることをお勧めします。 機能カバレッジ 当社では現在、SAP BOを活用して業務部門に対してレポート（以降、BOレポート）を提供しています。BOレポートの元となっているテーブル群は、今後データ基盤でも少なくとも利用が想定されることから、これらテーブルとCortex Frameworkの処理対象となるテーブル（標準テーブル）の比較を行うことで、カバレッジを評価しました（Table 2）。 Table 2: 機能カバレッジ評価結果 No 評価項目 評価結果（%） 1 対象テーブル(*1)のうち業務活用が見込まれるテーブルの割合 50 2 BOレポートに利用されるテーブルのうち対象テーブル(*1)のカバー率 30 (*1) Cortex Frameworkの処理対象となる標準テーブル 評価結果No.1では、当社環境においてはSAP標準テーブルのみでは十分な業務活用が期待できないことを示唆しており、その他のカスタムテーブルの使用が必須であることを意味します。一方、評価結果No.2では、Cortex Frameworkが提供するテンプレートで現在の業務ニーズをカバーするには不十分であるという具体的な数値となりました。 これらの結果から、Cortex Frameworkを充分に活用するには、当社独自のカスタマイズまたはゼロベースでの追加処理作成が数多く必要であり、本フレームワークの強みであるSAPデータ分析環境の迅速な整備の恩恵を、当社においては享受することが難しいことを意味します。 運用・コスト負担 Cortex FrameworkではワークフローのオーケストレーションツールとしてCloud Composerを前提としたテンプレートが提供されています。前述の機能カバレッジの検証結果を踏まえると、まず金額負担の観点では、Cloud Composerの月間費用（当社環境での試算）は割高と判断しました。また、運用負担の観点では、Cloud Composerほどの高機能なオーケストレーションは現時点で不要であることから、Dataformでのデータパイプライン開発の検証も行い、こちらも導入の目途が立ちました。 したがって、複数ツールの運用・管理は負担になることを考慮し、Dataformでの開発に切り替えました。 今後の方針 Cortex Framework自体は導入見送りの判断を行いましたが、テンプレートが提供するデータモデリングの内容（テーブル間リレーション、結合方法、など）は有益であるため、開発の参考にしたいと思っています。また、データパイプラインツールとしてはひとまずDataformを採用して開発を進めます。 Dataformは操作対象がBigQuery内のアセットに限定されますが、ツール利用料自体は無料であり、またSQL中心のELTツールであるため、開発者だけでなく、処理履歴（リネージ）も含めて把握したいユーザにとっても、シンプルでわかりやすいものではないかと、現時点では思っています。 まとめ 当記事では、ライオン株式会社におけるデジタル改革の一環として、SAPデータの活用を軸にGoogle Cloud上でのデータ基盤構築の取り組みと、その検討プロセスをご紹介しました。 今回の取り組みを通して、組織全体でデータを価値ある資産として活用し、迅速かつ高精度な意思決定を実現するための土台が形成されつつあることを実感しています。今後も引き続き、進化する技術環境に対応した柔軟なデータ基盤の構築に取り組むことで、企業の競争力強化とイノベーションの推進に寄与していきます。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、2021年よりクラウドの導入から最適化までを支援しているGoogle Cloud専業のクラウドインテグレーターです。

G-gen の杉村です。2025年10月、Google の AI アシスタントサービス Google Agentspace が Gemini Enterprise に名称変更され、追加の機能とともに再発表されました。変更後のライセンス体系等の違いについて解説します。 Gemini Enterprise とは Gemini Enterprise の発表 発表内容 変更点 ライセンス体系 Gemini Enterprise への移行 サブスクリプション移行パス イメージ図 Google Agentspace Enterprise からの移行 Google Agentspace Enterprise Plus からの移行 Google Agentspace Frontline からの移行 年間サブスクリプションのアップグレード Gemini Enterprise とは Gemini Enterprise （旧称 Google Agentspace）は、Google の AI アシスタントサービスです。Google Workspace や Microsoft 365、Confluence や Salesforce などの外部サービスに接続して、横断検索を行ったり、検索結果を取得して AI が要約・生成・分析などのタスクを行います。また NotebookLM Enterprise、Deep Research、独自開発エージェントの統合など各種付加機能も持っています。これらを活かし、Gemini Enterprise は企業のための AI プラットフォームとして機能します。 Gemini Enterprise は、2024年12月に Google Agentspace という名称で Early Access 提供が開始され、2025年7月31日に一般公開（GA）されました。そして2025年10月10日、現在の名称である Gemini Enterprise に改称し、追加の機能とともに再発表されました。 参考 : Gemini Enterprise: Best of Google AI for Business | Google Cloud Gemini Enterprise は以下の記事で詳細に解説されていますので、参考にして下さい。 blog.g-gen.co.jp Gemini Enterprise の発表 発表内容 日本時間2025年10月10日、Google Agentspace は、 Gemini Enterprise に改称のうえ、新サービスとして再発表されました。同日付で、公式ガイドなども名称が一新されました。 この再発表においては、特に以前の Google Agentspace には付属していなかった Gemini Code Assist Standard ライセンスが付与されるなど、追加の特典が利用可能になっています。また今後、様々な AI 関連機能が追加され、AI アシスタントのプラットフォームとして進化していくことが、Google によって示唆されています。 参考 : Gemini Enterprise を発表 参考 : Gemini Enterprise release notes ‐ October 9, 2025 変更点 この再発表では、以前の Google Agentspace と比較して、以下のような変更が加えられます。 Google Agentspace は Gemini Enterprise へ改名。ドキュメントや Web コンソール画面上の表記も変更になる サブスクリプション（ライセンス）体系が変更。特に Gemini Enterprise Standard 以上では Gemini Code Assist Standard ライセンスが付属 一方で、この再発表に伴い、基本的には Google Agentspace 時代からあった機能や契約に悪い影響はありません。Google からは以下のように通知されています。 一般提供（GA）済みの機能に、 廃止や変更はない 既存のサブスクリプション契約は、期間が終了するまで条件や請求金額に変更はない サポートレベルに変更はない 既存機能を利用するにあたり、ユーザーが取るべきアクションは特にない よって、従来の Google Agentspace ユーザーは大きく影響を受けずに、Gemini Enterprise を使い続けることができます。また、Google Agentspace の年間または3年間の長期サブスクリプションの契約者は、所定のルールで Gemini Enterprise に アップグレード することも可能です。詳細は後述します。 ライセンス体系 Gemini Enterprise では、ライセンス契約にあたる サブスクリプション を購入して、利用ユーザー1人ずつにライセンスを割り当てる必要があります。 ライセンス体系の詳細は、以下の記事に2025年10月17日現在の最新情報に基づく解説を掲載しています。以下の解説をご確認いただきつつ、当記事を読み進めてください。 参考 : Gemini Enterpriseを徹底解説！ - G-gen Tech Blog - 料金とライセンス Gemini Enterprise への移行 Gemini Enterprise への改称に伴い、Google Agentspace の機能が廃止されたり変更されることは ありません 。既存の Google Agentspace ユーザーは、基本的には特になにもしなくてもそのまま Gemini Enterprise を使い続けることができます。購入済みのサブスクリプション（ライセンス）も、しばらくはそのまま利用可能です。 しかし、 2025年12月31日以降 、既存の Google Agentspace ライセンスのサブスクリプションは 購入することはできなくなります 。よって、月間サブスクリプションを購入していた既存の Google Agentspace ユーザーや、Google Agentspace の導入を検討していたが Gemini Enterprise への改称後（サブスクリプション体系変更後）に正式導入をするユーザーは、Gemini Enterprise の新しいサブスクリプション体系を理解して、移行パスを検討する必要があります。 サブスクリプション移行パス イメージ図 以下は、旧来の Google Agentspace サブスクリプションの種類と、新しい Gemini Enterprise サブスクリプションの対応を表した図です。 Google Agentspace から Gemini Enterprise への移行パス" Google Agentspace Enterprise からの移行 Google Agentspace Enterprise の移行先は、Gemini Business か Gemini Enterprise Standard が移行先として考えられます。 どちらを選択する場合も、Google Agentspace Enterprise には付属していなかった「 ノーコードエージェント の開発機能（Agent Designer）」や「 Google のプリメイドエージェント （Deep Research やアイデア生成エージェントなど）」が付属することになります。 また、Gemini Enterprise Standard を選択すれば、 Gemini Code Assist Standard ライセンスも付属します。これは、アプリケーション開発者が使用できるコーディング補助エージェントのライセンスです。VSCode などの IDE で利用でき、コード生成、保管、コードの説明など、様々な機能が利用でき、開発スピードを大幅にアップします。 注意点として、Gemini Business は Google Cloud との連携ができません 。VPC Service Controls や BigQuery との連携など、高度な機能が利用できなくなります。また Google Cloud コンソールからのオンライン購入ができないほか、G-gen などの Google Cloud 販売パートナーからの購入もできません。Gemini Business は Gemini Enterprise を初めて導入するライトユーザー向けにハードルを下げた廉価版と考えることができることから、既存ユーザーは Gemini Enterprise Standard 以上を検討することが推奨されます。 Google Agentspace Enterprise Plus からの移行 Google Agentspace Enterprise Plus からの移行先は、Gemini Enterprise Standard か Gemini Enterprise Plus が候補となります。 いずれを選択した場合でも、Gemini Code Assist Standard ライセンスが新しく付与されます。 Gemini Enterprise Standard を選択した場合は、ユーザー1人あたりに割り当てられるストレージ量が減少するのと引き換えに、サブスクリプション料金が安価になります。 Gemini Enterprise Plus を選択した場合は、今後（2025年10月17日現在）機能追加が見込まれる、高度な管理機能が利用可能です。この管理機能には、ノーコードエージェントを従業員へ配布したり管理したりする機能などが考えられます。ただし2025年10月17日現在、「高度な管理機能」に関して、具体的にどのような機能が追加されるかなど、公式なロードマップの発表がないため、現在では Standard と Plus の機能差異が小さいものとなっています。詳細は Google のセールス担当者等にお問い合わせください。 Google Agentspace Frontline からの移行 Google Agentspace Frontline の移行先は、Gemini Enterprise Frontline になります。サブスクリプションに含まれる内容に大きな変化はありません。ただし、サブスクリプション料金に違いがあります。 Frontline サブスクリプション 年間サブスクリプションのアップグレード Google Agentspace の年間または3年間のサブスクリプションを既に購入したユーザーについては、契約期間中は、追加シートをこれまで同じ形態で追加購入可能です。 また、希望すれば、Google Agentspace の年間サブスクリプションを、追加コストなしで Gemini Enterprise にアップグレード できます。またその場合でも、契約期間の最初の1年間が終わるまでの間、従来と同じ金額で追加ライセンスを購入できます。アップグレードすることで Gemini Enterprise に含まれる Gemini Code Assist Standard ライセンスなどの追加の恩恵を得ることができます。 移行先のサブスクリプションがどれになるのか、またどのような手続きになるかなど、詳細は Google Cloud または Google Cloud 販売パートナーのセールス担当者にお問い合わせください。 window.addEventListener('DOMContentLoaded', () => { const canonicalUrl = "https://blog.g-gen.co.jp/entry/gemini-enterprise-explained"; let canonicalLink = document.querySelector('link[rel="canonical"]'); if (!canonicalLink) { canonicalLink = document.createElement('link'); canonicalLink.setAttribute('rel', 'canonical'); document.head.appendChild(canonicalLink); } canonicalLink.setAttribute('href', canonicalUrl); }); 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。Google Colaboratory、略称 Colab は、Google が提供する Jupyter ノートブックベースの開発環境サービスです。Colab には無料版、従量課金プラン、サブスクリプションプランである Colab Pro と Pro+、そして企業等の組織向けの Colab Enterprise があります。それぞれの違いやユースケースを解説します。 Colab の概要 プランの選び方 Colab 無料版 Colab 従量課金プラン Colab Pro / Pro+ Colab Enterprise Colab の概要 Google Colaboratory（以下、 Colab ）は、Web ブラウザから直接 Python コードを実行できる、Jupyter ノートブックベースの開発環境です。環境構築が不要で、GPU や TPU といったハードウェアアクセラレータも利用できる手軽さから、データ分析や機械学習の学習・研究目的で広く利用されています。 Colab には、無料プラン、従量課金（Pay As You Go）プラン、Colab Pro、Colab Pro+、そして Google Cloud のサービスとして提供される企業向けの Colab Enterprise があります。それぞれの違いは以下の通りです。 特徴 Colab 無料版 Colab 従量課金プラン Colab Pro / Pro+ Colab Enterprise 主な対象ユーザー 個人、学習者 個人、研究者 個人、研究者 企業、組織 提供形態 Google サービス Google サービス Google サービス Google Cloud サービス 課金体系 無料 従量課金 月額サブスクリプション 従量課金 (Google Cloud の請求先アカウント) リソース 制限あり 使用分だけ支払 定量が割当 マシンタイプで柔軟に構成 バックグラウンド実行 なし なし Pro+ のみ可能 (最大24時間) 可能 セキュリティ・管理 Google アカウント Google アカウント Google アカウント Google アカウント、IAM、組織のポリシー、VPC Service Controls、CMEK など Google Cloud 連携 限定的 限定的 限定的 BigQuery、Vertex AI などとシームレスに連携 参考 : 最適な Colab のプランを選択する - Colab 参考 : Colaboratory よくある質問 - Colab 参考 : Colab Enterprise の概要 - Google Cloud プランの選び方 原則的に、Colab の無料プラン、従量課金（Pay As You Go）プラン、Colab Pro、Colab Pro+ は、個人や研究者、小規模な分析チームなどに適しています。 一方で、企業などの組織が Colab を利用したい場合、Google Cloud と統合されており高度なアクセス管理等が可能な Colab Enterprise が推奨されます。Colab Enterprise へのアクセス管理は、Google Workspace や Cloud Identity で統合管理される Google アカウントをベースに行われます。Colab Enterprise では、以下のようなことが可能です。 組織側でアカウントの管理を行う（Google Workspace / Cloud Identity） Identity and Access Management（IAM）による詳細なアクセス管理 Google グループやドメイン全体へのアクセス権限付与 VPC Service Controls による接続元 IP アドレス制限 CMEK（顧客管理の暗号鍵）によるストレージ暗号化 BigQuery や Vertex AI と連携したデータ分析や AI 活用 企業等の組織で無料プランや Colab Pro 等を利用することもできますが、高度なアクセス管理機能はありません。作成したノートブックは Google ドライブに保存され、Google ドキュメントなどのファイルと同じように扱われます。 また、Colab Enterprise は Google Cloud プロジェクトに紐づいており、利用料金は Google Cloud の請求先アカウントに課金されます。通常の Google Cloud サービス同様、特別な手続きなく G-gen などの Google Cloud 販売パートナー経由で利用することも可能です（G-gen を含む一部の販売パートナーは、Colab Pro や Pro+ も再販可能です）。 Colab 無料版 無料版の Colab は、誰でもすぐに無料で Python の実行環境を手に入れられる点が最大のメリットです。 GPU や TPU も無料で利用できますが、割り当てられるリソースは保証されておらず、特に高性能な GPU が利用できるかは、そのときどきの Google の リソース状況に左右 されます（有償プランの利用者が優先されます）。 また、長時間利用しない場合や、一定時間を超える処理を実行した場合にセッションが切断されるため、長時間の処理には向きません。 なお、作成したノートブックは、Google ドライブのマイドライブに保存されます。 これらから、無料版の Colab は主に、 プログラミングの学習や、小規模なデータ分析、短時間で終わる機械学習モデルの実験など に適しています。 Colab 従量課金プラン Colab 従量課金プラン（Pay As You Go プラン）は、無料版の各種制限を緩和する、個人向けの有料プランです。 コンピューティングユニット を必要な分だけ購入し、その分を Google に支払います。コンピューティングユニットとは、Colab の実行基盤（VM）の CPU、GPU、TPU などのコンピュートリソースを抽象化した単位です。 Colab 従量課金プランでは、コンピューティングユニットを100または500の単位で購入します。購入後は90日間有効で、必要に応じて追加購入できます。 作成したノートブックは、無料版と同様、Google ドライブのマイドライブに保存されます。 Colab 従量課金プランは、無料版とほぼ同じユースケースにおいて、 より多くのリソースを使いたい場合 に適しています。 Colab Pro / Pro+ Colab Pro と Colab Pro+ は、無料版の各種制限を緩和する、個人向けの有料サブスクリプションプランです。従量課金プランとの違いは、毎月定額の料金を支払うことで、所定のコンピューティングユニットが割り当てられる点です。コンピューティングユニットが足りなくなった場合、必要に応じて追加購入できます。 Colab Pro では100ユニット、Colab Pro+ では500ユニットのコンピューティングユニットを受け取ることができます（期間限定特典で、より多くのユニットが割り当てられることもあります）。コンピューティングユニットの単価は従量課金プランと同じですが、Colab Pro / Pro+ の特典として、より高性能な GPU（プレミアム GPU。型番はそのときにより異なる）やより多くのメモリが割り当てられます。 さらに Colab Pro+ では、バックグラウンド実行が可能になります。ブラウザを閉じても、ノートブックは最大24時間稼働します。これにより、より複雑なデータ処理、本格的な機械学習モデルのトレーニングが可能です。 なお、Colab Pro / Pro+ は再販が可能な販売パートナーもあります。G-gen の場合、G-gen 経由での Colab Pro / Pro+ の購入が可能です。 作成したノートブックは、無料版と同様、Google ドライブのマイドライブに保存されます。 Colab Pro / Pro+ は、従量課金プランよりもリソースが優遇（プレミアム GPU 等）されており、バックグラウンド実行も可能なことから、 より本格的・日常的に Colab を利用する研究者、開発者、個人 に適しています。ただしより大人数で組織的に使用する場合は、Colab Pro / Pro+ のセキュリティと統制機能では不足する可能性があるため、後述の Colab Enterprise を検討します。 Colab Enterprise Colab Enterprise は、前掲の個人向けプランとは異なり、企業や組織での利用に特化した Google Cloud のサービスです。Google Cloud のサービスとして、マネージドなノートブック環境が提供されます。 参考 : Colab Enterprise の概要 ノートブックの実行環境は ランタイム と呼ばれ、様々なインスタンスタイプから選択でき、GPU もアタッチできます。ノートブックのスケジュール実行なども指定でき、任意の日時にノートブックを実行できます。 参考 : ノートブックの実行スケジュールを設定する また Google Cloud と高度に統合されているため、以下のような高度なセキュリティも用いることができます。 組織側でアカウントの管理を行う（Google Workspace / Cloud Identity） Identity and Access Management（IAM）による詳細なアクセス管理 Google グループやドメイン全体へのアクセス権限付与 VPC Service Controls による接続元 IP アドレス制限 CMEK（顧客管理の暗号鍵）によるストレージ暗号化 BigQuery や Vertex AI と連携したデータ分析や AI 活用も可能です。ノートブックの実行ユーザーの認証情報を使用して、BigQuery や Vertex AI、Cloud Storage などの Google Cloud サービスの API に、ノートブック上のコードからアクセスできます。 参考 : Google Cloud サービスと API へのアクセス なお作成したノートブックは、Google Cloud プロジェクトのリソースとして管理されます。無料版のように、Google ドライブのファイルとして扱われることはありません。 Colab Enterprise は、 企業や官公庁、教育機関などの組織が統制を効かせて Colab を利用したいケース に適切です。 なお、Google Cloud で提供される他の Jupyter ノートブックサービスとして、Vertex AI Workbench があります。比較観点や詳細については、以下の記事も参照してください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の min です。Agent Development Kit（ADK）と BigQuery を組み合わせた AI エージェントにおけるリスクを管理し、 安全に運用するための設計アプローチ を説明します。 はじめに ADK と BigQuery AI エージェントに潜むリスク 多層防御 対策1. ツールセットによる静的制御 書き込み制御（WriteMode） 認証情報の分離（ADC） 対策2. アプリケーションによる動的制御 指示による行動の制約（Instruction） 実行前の検証（Callback） 対策3. クラウド基盤による防御 コストの保護 最小権限の原則（IAM） トレーサビリティの確保 はじめに ADK と BigQuery ADK と BigQuery を使ったエージェントの基本的な開発方法は以下の記事をご参照ください。 blog.g-gen.co.jp AI エージェントに潜むリスク AI エージェントにデータベースへのアクセス権限を付与することは、以下のようなリスクを伴います。 意図しないデータ操作 エージェントが誤って UPDATE や DELETE といったデータ変更クエリを生成・実行し、重要なデータを破壊・改ざんしてしまう。 高額なクエリ実行 大規模なテーブルに対して非効率なクエリ（例: WHERE 句のない SELECT * ）を実行し、想定外の高額な BigQuery 利用料金が発生する。 情報漏洩 本来アクセスが許可されていない機密データ（個人情報など）にアクセスし、その結果をユーザーに回答してしまう。 多層防御 これらのリスクに対処するため、単一の対策に頼るのではなく、複数の防御線を組み合わせる 多層防御 （Defense in Depth）を基本的な考え方として採用します。ここでは、ツール・アプリケーション・クラウド基盤という3つの階層で構成される設計手法を紹介します。 No. 名称 対策1 ツールセットによる静的制御 対策2 アプリケーションによる動的制御 対策3 クラウド基盤による防御 参考 : BigQuery と ADK & MCP: 新しいファーストパーティ ツールセットでエージェント開発を加速 参考 : BigQuery meets ADK: 10 tips to safeguard your data (and wallet) from agents なお、当記事では AI のハルシネーション等による意図しないデータの改ざんや大容量のクエリを防ぐ意味での「防御」を紹介しています。外部からの意図的な攻撃による情報漏洩やデータ改ざん、各種インジェクションなどへの対策とは趣旨が異なりますが、多層防御の考えかたはそのような対策にも普遍的に使える考えかたです。 対策1. ツールセットによる静的制御 エージェントの基本的な振る舞いを、初期化時の設定で制限する静的な制御手法です。開発の初期段階で導入できる、最も基本的な防御線となります。 書き込み制御（WriteMode） データへの意図しない変更を防ぐための最も基本的なガードレールです。ADK の BigQueryToolset の WriteMode を BLOCKED に設定することで、エージェントが生成できる SQL を SELECT 文のみに強制します。 from google.adk.tools.bigquery import BigQueryToolConfig, WriteMode # データの変更をブロックする読み取り専用モードに設定 tool_config = BigQueryToolConfig(write_mode=WriteMode.BLOCKED) bigquery_toolset = BigQueryToolset( # ... tool_config=tool_config ) WriteMode には以下の3つのモードがあります。 モード 説明 BLOCKED デフォルト 。 SELECT 文のみが許可され、DML (Data Manipulation Language) や DDL (Data Definition Language) といったデータ変更・定義操作はすべてブロックされます。分析用途のエージェントでは、原則としてこのモードを使用します。 PROTECTED DML/DDL の実行を許可しますが、その操作対象は BigQuery セッション内で作成された一時テーブルに限定されます。永続的なテーブルへの変更は防がれるため、中間データの加工など、限定的な書き込みが必要な場合に使用できます。 ALLOWED すべての SQL 操作が許可されます。データの変更・削除も可能なため、使用には最大限の注意が必要です。このモードの採用は慎重に検討すべきです。 認証情報の分離（ADC） アプリケーションコードからサービスアカウントキーなどの認証情報を分離し、実行環境に認証を委任する手法です。Google Cloud の アプリケーションのデフォルト認証情報 （ADC）を利用することで、キー漏洩のリスクを大幅に低減します。 参考 : アプリケーションのデフォルト認証情報を設定する from google.adk.tools.bigquery import BigQueryCredentialsConfig import google.auth # アプリケーションのデフォルト認証情報を取得 application_default_credentials, _ = google.auth.default() # 取得した認証情報を BigQuery ツールセットに設定 credentials_config = BigQueryCredentialsConfig( credentials=application_default_credentials ) 対策2. アプリケーションによる動的制御 エージェントの動作（実行時）に応じて、アプリケーションロジックでリアルタイムに制御を加える動的な手法です。静的制御だけでは防ぎきれない、より複雑なリスクに対応します。 指示による行動の制約（Instruction） LLM へのプロンプト（ instruction ）を通じて、エージェントの思考や行動に制約を課す手法です。エージェントの役割、目的、そして「してはならないこと」を自然言語で明確に定義します。 参考 : プロンプト エンジニアリング: 概要とガイド instruction= """ あなたは `sales_data_jp` データセットを分析するデータ分析エージェントです。 ユーザーの質問に答えるため、BigQueryに対するSQLクエリを生成・実行します。 以下のガイドラインに厳密に従ってください: - データ操作（DML）: UPDATE, DELETE, INSERT といったDML操作は一切許可されていません。 - クエリの最適化: `SELECT *` は使用しないでください。必ず必要な列のみを指定してください。 - 結果のサイズ: `LIMIT` 句を必ず含め、返される行数を最大100行に制限してください。 """ 実行前の検証（Callback） ツールが実行される直前に、その引数（生成されたSQLなど）をコードで検証し、危険な操作をブロックする手法です。ADK の コールバック機能 を用いることで、プロンプトによる制約をさらに確実なものにします。 from typing import Dict, Any, Optional from google.adk.runtime.tool_runner import ToolContext, BaseTool def validate_sql_callback (tool: BaseTool, args: Dict[ str , Any], tool_context: ToolContext) -> Optional[Dict]: """ 'execute_sql' ツールが実行される前に呼び出されるコールバック関数 """ if tool.name == 'execute_sql' : sql_query = args.get( 'sql_query' , '' ).lower() forbidden_keywords = [ 'delete' , 'update' , 'drop' , 'truncate' , 'alter' ] if any (keyword in sql_query for keyword in forbidden_keywords): return { "result" : "セキュリティポリシー違反のため、このクエリは実行できません。" } return None root_agent = Agent( # ... before_tool_callback=validate_sql_callback ) 対策3. クラウド基盤による防御 アプリケーションの制御が万が一突破された場合でも、クラウド基盤レベルで被害を食い止める最後の砦となる対策です。 コストの保護 BigQuery の機能を利用して、意図しない高額課金を防ぐ手法です。これには2つのアプローチがあります。 Dry Runによる事前見積もり dry_run オプションでクエリのスキャン量を見積もり、しきい値を超えたら実行を中止します。これは「実行前の検証」の中で実装できます。 参考 : 費用の見積もりと管理 最大課金バイト数の強制 maximum_bytes_billed パラメータを設定し、クエリのスキャン量に厳格な上限を設けます。上限を超えたクエリは BigQuery が自動的に失敗させます。 最小権限の原則（IAM） 情報セキュリティの基本原則である「 最小権限の原則 」を、Google Cloud の IAM を用いて適用します。エージェントが使用するサービスアカウントには、そのタスク遂行に必要最小限の権限のみを付与します。 ロール データ閲覧のみであれば、「BigQuery データ閲覧者（ roles/bigquery.dataViewer ）」と「BigQuery ジョブユーザー（ roles/bigquery.jobUser ）」のみを付与します。 スコープ 権限をプロジェクト全体ではなく、特定のデータセットやテーブルに限定します。 アクセス制御 必要に応じて、列レベル・行レベルのアクセス制御を組み合わせることで、さらにきめ細やかなデータ保護を実現します。 BigQuery の権限管理については、以下の記事も参照してください。 blog.g-gen.co.jp トレーサビリティの確保 問題発生時の原因究明を迅速化するため、エージェントの行動を追跡可能にする（トレーサビリティを確保する）仕組みも重要です。 ADK Web UI ローカル開発時に、エージェントの思考プロセスやツール呼び出しを視覚的に追跡します。これにより、意図しない挙動を示した際のデバッグや、プロンプトチューニングが容易になります。 Cloud Logging / Cloud Trace 本番環境にデプロイされたエージェントの実行履歴を記録・分析します。アプリケーションのパフォーマンス監視や、エラー発生時の詳細なコンテキスト把握に役立ちます。 参考 : Cloud Trace の概要 BigQuery 監査ログ BigQuery で実行された全てのクエリを記録します。どのサービスアカウントが、いつ、どのようなクエリを実行したかを正確に把握できるため、不正な操作や情報漏洩インシデントの調査に不可欠です。 参考 : BigQuery の監査ログの概要 BigQuery の監査ログについては、以下の記事も参照してください。 blog.g-gen.co.jp 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の杉村です。Google スプレッドシートで、セルに関数を入力するだけで生成 AI が利用できる AI 関数 について解説します。 はじめに AI 関数とは 利用可能エディション 留意点 仕様 使用例1 : 要約 使用例2 : 感情分析 使用例3 : 翻訳 使用例4 : 文章の生成 制限 はじめに AI 関数とは Google スプレッドシートの AI 関数 とは、セルに関数を入力するだけで生成 AI が利用できる機能です。AI 関数のバックエンドには、Google の生成 AI モデルである Gemini が使用されています。 AI 関数は、テキストの生成、要約、分類、感情分析などに利用できます。日本語、英語をはじめ、スペイン語、ポルトガル語、韓国語、フランス語、イタリア語、ドイツ語などに対応しています。 参考 : Use the AI function in Google Sheets - Google Docs Editors Help AI 関数 利用可能エディション AI 関数は、Google Workspace の以下のエディションで利用できます。 Business Standard / Plus Enterprise Standard / Plus Google AI Ultra for Education エディションごとに利用可能な Gemini 機能は、以下の公式ドキュメントにまとまっていますので参考にしてください。 参考 : Google Workspace with Gemini を使ってみる - Business / Enterprise - Google ドキュメント エディタ ヘルプ なお当機能の日本語対応が発表されたのは2025年9月23日であり、「即時リリース」設定のドメインには2025年9月23日から15日間かけて順次ロールアウト、「計画的リリース」のドメインには2025年10月6日から15日間かけて順次ロールアウトされます。当記事の公開時点では、お使いのドメインではまだ利用可能になっていない可能性があります。 参考 : Google Workspaceの新機能をいち早く使う方法 - G-gen Tech Blog 留意点 大前提として、AI 関数は生成 AI モデルを使用しています。生成される内容は誤りを含んでいる場合があるため、一般的な生成 AI サービスと同様、留意が必要です。 参考 : 生成AIのよくある誤解を整理してAIの業務活用を推進する - G-gen Tech Blog なお、有償版 Google Workspace の各エディションの AI 関連機能では、入力したデータが Google のモデルの再トレーニング等に許可なく利用されることはありません。 参考 : Google Workspace with Gemini に関するよくある質問 - Google Workspace 管理者ヘルプ 参考 : Google Workspace の生成 AI に関するプライバシー ハブ - Google Workspace 管理者ヘルプ 仕様 AI 関数は、以下の文法で使用します。 =AI("プロンプト", [参照セルまたは範囲]) 「プロンプト」には AI への指示を自然言語で記述します。「参照セルまたは範囲」には、AI が生成を行う時に参照するセルまたはセルの範囲を記述します。「参照セルまたは範囲」はオプションであり、必須ではありません。 なお AI 関数は、Google 検索を使ってグラウンディングを行い、インターネットから最新情報を取得したうえで生成を行います。 使用例1 : 要約 例として、AI 関数は以下のように使用します。 =AI("セルの内容を50文字以内で要約して", B2) このようにすることで、B2 セルの文字列が要約されます。 文章の要約 要約結果 この関数をコピーして複数行に貼り付けることで、複数行に対する処理が可能です。貼り付けてすぐはセルが紫色にハイライトされて結果が表示されませんが、しばらく待つと生成結果が表示されます。表示されない場合は、「更新して挿入」を押下します。 複数セルへのコピー 使用例2 : 感情分析 以下は、サービスに対するユーザーの感想を、「ポジティブ」「ニュートラル」「ネガティブ」に分類させる例です。 =AI("ユーザーの感想を「ポジティブ」「ニュートラル」「ネガティブ」のいずれかに分類して", B2) 感情分析 使用例3 : 翻訳 AI 関数では、別の言語に文章を翻訳させることもできます。 =AI("この文章を日本語から対象言語に翻訳して", B2:C2) ここでは、参照先セル範囲として、感想文と翻訳先の言語が書かれたセルを指定しています。 翻訳 使用例4 : 文章の生成 当記事でサンプルとして掲載している「ユーザーの声」も、AI 関数で生成したものです。 =AI("架空のWebサービスの使用感に関するユーザーの声を生成して。トーンは次のセルの通りで。",B2) 文章の生成 制限 2025年10月現在、AI 関数には以下のような制限があります（代表的なもののみ抜粋）。 AI の回答はテキストのみ（画像や動画の出力はできない） 他のシートにはアクセスできない AI 関数は他の関数にネストできない（例 : =IF(AI(“sentiment analysis”, A2)),”negative”,0) ） 利用回数制限がある。明確な数値は公開されていないが、短期制限と長期制限がある。利用制限に抵触した場合、最大24時間待つ必要がある 複数セルで生成を行う場合、一度に生成できるのは最初の200個のセルまで。生成が終わるまで待機してからそれ以降のセルで生成を行う 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の min です。データ変換パイプラインツールである Dataform における、 SQLXファイルにおけるテーブル定義 と、その中で使用される 組み込み関数 について解説します。 Dataform と SQLX テーブル定義の基本 主要な組み込み関数 組み込み関数の解説 ref() resolve() self() name() schema() database() 関数の使い分けと実践 workflow_settings.yaml の設定例 stg_users.sqlx dim_users.sqlx 展開結果 Dataform と SQLX Dataform は、Google Cloud 上でデータ変換のワークフローを開発、テスト、デプロイ、スケジューリングするためのサービスです。データアナリストやエンジニアは、SQL を用いて BigQuery 内にテーブルやビューを効率的に作成・管理できます。 Dataform の中核となるのが SQLX というファイル形式です。SQLX ファイルは、標準的な SQL に加えて、Dataform 独自の機能を追加したものです。具体的には、ファイルの先頭に config ブロック と呼ばれる設定ブロックを記述し、その後に SELECT 文を記述することで、テーブルやビューの定義とデータの中身を一度に管理できます。 参考 : Dataform の概要 参考 : Dataform コア 以下の記事では Dataform の基本的な概念を解説しています。あわせてご参照ください。 blog.g-gen.co.jp テーブル定義の基本 SQLX ファイルで新しいテーブルを定義する際の基本的な構造は、以下のようになります。 config { type : " table " , schema: " my_dataset " , name: " my_new_table " } SELECT ' hello ' AS greeting, CURRENT_TIMESTAMP () AS created_at config ブロックでは、作成するアセットの タイプ （ table 、 view 、 incremental など）や、出力先の スキーマ （BigQuery のデータセット名）、 テーブル名 などを指定します。 config ブロックに続く SELECT 文が、そのテーブルの定義となります。 この SQLX ファイルを Dataform が実行すると、BigQuery の my_dataset データセット内に my_new_table という名前のテーブルが作成されます。 *  参考 : テーブルを作成する 主要な組み込み関数 Dataform の SQLX ファイルでは、 config ブロックや SELECT 文の中で、 ref() や self() といった 組み込み関数 を使用できます。これらの関数は、Dataform が SQL をコンパイルして BigQuery で実行する際に、実際のテーブル名やスキーマ名に自動的に置き換えられます。 これにより、環境（開発/本番）ごとに出力先を変更したり、テーブル間の依存関係を明示的に定義したりすることが容易になります。 *  参考 : Dataform コアのリファレンス 主要な組み込み関数の概要を、以下の表にまとめます。 関数名 主な用途 参照対象 返り値の例 ref() Dataform ワークスペース内の他のテーブル/ビューを参照し、依存関係を定義する ワークスペース内の他の SQLX ファイル my-project.my_dataset.my_table resolve() Dataform 管理外の BigQuery 上の既存テーブル/ビューを参照する BigQuery 上の任意のテーブル/ビュー my-project.another_dataset.external_table self() 増分テーブルなどで自分自身のテーブルを参照する 現在の SQLX ファイルが生成するテーブル my-project.my_dataset.this_table name() 生成されるテーブル/ビュー名を取得する 現在の SQLX ファイルのファイル名または config の name this_table schema() 生成されるテーブル/ビューのスキーマ名（データセット名）を取得する config の schema または workflow_settings.yaml の defaultDataset my_dataset database() 生成されるテーブル/ビューのデータベース名（プロジェクトID）を取得する workflow_settings.yaml の defaultProject my-project 組み込み関数の解説 ref() ref() 関数は、 Dataform ワークスペース内の他のテーブルやビューを参照する ために使用する最も基本的な関数です。 ref() 関数の引数には、参照したい SQLX ファイルのファイル名を指定します。 例えば source_customers.sqlx というファイルで定義されたテーブルを参照したい場合、以下のように記述します。 SELECT * FROM ${ref( " source_customers " )} Dataform は SQL コードをコンパイルする際に ${ref("source_customers")} の部分を、 source_customers.sqlx で定義されたテーブルの完全な名前（例: my-project.my_dataset.customers ）に置き換えます。 ref() を使用する最大のメリットは、 テーブル間の依存関係が自動的に解決される ことです。Dataform は ref() の記述を基に依存関係グラフ（DAG）を構築し、参照元のテーブルが作成された後で参照先のテーブルを作成するように、実行順序を自動で制御します。 resolve() resolve() 関数は、 Dataform 側で依存関係を追跡する必要がない、BigQuery 上の既存のテーブルやビューを参照する ために使用します。 ref() が Dataform ワークスペース内で定義されたアセットを参照し、依存関係を自動で管理するのに対し、 resolve() は Dataform の管理外にある BigQuery 上のテーブルなどを参照し、依存関係を追加しません。 resolve() の引数には、スキーマ（データセット）名とテーブル名を指定します。 -- "raw_data" データセットの "sales_2025" テーブルを参照 SELECT * FROM ${resolve( " raw_data " , " sales_2025 " )} コンパイル時、この部分は my-project.raw_data.sales_2025 のような完全なテーブル名に置き換えられます。 resolve() で参照したテーブルは、Dataform の依存関係グラフには含まれません。 そのため、Dataform は resolve() で参照されるテーブルの存在や作成順序を管理しません。 self() self() 関数は、 自分自身のテーブル名 を完全な形式で参照するために使用します。 引数は不要です。 この関数は、特に type: "incremental" を指定した 増分テーブル を定義する際に非常に役立ちます。増分テーブルでは、前回の実行で作成した自分自身のテーブルから最新のデータを取得し、新しく追加されたデータのみを追記する、といった処理を記述するために使用します。 この関数は、テーブル定義のメインとなる SELECT 文の実行前に処理を追加する pre_operations ブロック内で特に有効です。 config { type : " incremental " } -- pre_operations は、メインのSELECT文の実行前に実行されるSQLブロック SELECT * FROM ${ref( " source_sessions " )} pre_operations { -- when(incremental(), ...) は増分実行時のみ中のSQLを実行する構文 ${ when (incremental(), ` DELETE FROM ${self()} WHERE session_date IN (SELECT DISTINCT session_date FROM ${self()})`) } } 上記の例では、 pre_operations ブロック内で、これから挿入するデータと同じ日付の既存データを一度削除するために self() を使用しています。 self() は、この SQLX ファイル自身が作成するテーブルの完全な名前（例: my-project.my_dataset.this_table ）に展開されます。 name() name() 関数は、 この SQLX ファイルから生成されるテーブル名 を返します。具体的には、SQLX ファイルのファイル名（拡張子を除く）が返されます。例えば、 user_summary.sqlx というファイル内で ${name()} を使用すると、 user_summary という文字列が返されます。 config ブロックで name プロパティを指定してテーブル名を明示的に上書きした場合、 name() はその上書きされた名前を返します。 schema() schema() 関数は、 この SQLX ファイルから生成されるアセットのスキーマ（データセット）名 を返します。 この値は、 config ブロックの schema プロパティで指定された値が返されます。 database() database() 関数は、 この SQLX ファイルがターゲットとするデータベース名 を返します。Google Cloud のコンテキストでは、これは Google Cloud プロジェクト ID に相当します。 関数の使い分けと実践 workflow_settings.yaml の設定例 前掲の関数を組み合わせることで、柔軟で再利用性の高いデータパイプラインを構築できます。 例えば、 workflow_settings.yaml で開発環境と本番環境の変数を定義し、出力先を切り替える構成がよく用いられます。 defaultProject : my-project defaultLocation : asia-northeast1 defaultDataset : dataform defaultAssertionDataset : dataform_assertions dataformCoreVersion : 3.0.0 この設定ファイルを基に、次に示すような SQLX ファイルを記述できます。 stg_users.sqlx config { type : " view " , schema: " dwh_stg " , name: " users " } SELECT user_id, user_name, register_date FROM ${ resolve( " raw_data " , " users_source " ) } dim_users.sqlx config { type : " table " , schema: " dwh_mart " , name: " dim_users_summary " } -- Dataformで作成した中間ビュー (stg_users) を参照 SELECT register_date, COUNT ( DISTINCT user_id) AS new_users FROM ${ref( " stg_users " )} GROUP BY register_date 展開結果 このワークスペースをコンパイルすると、各関数は以下のように展開されます。 stg_users.sqlx 内の ${resolve("raw_data", "users_source")} は my-project.raw_data.users_source になります。 dim_users.sqlx 内の ${ref("stg_users")} は my-project.dwh_stg.users になります（ stg_users.sqlx の config で定義したスキーマと名前が反映されます）。 dim_users.sqlx の実行時、もし self() を使えば my-project.dwh_mart.dim_users_summary を参照します。 各ファイル内で ${database()} は my-project を、 ${schema()} はそれぞれの config ブロックで指定されたスキーマ名（ dwh_stg または dwh_mart ）を返します。 このように組み込み関数を適切に使用することで、SQL コード内にプロジェクト ID やデータセット名をハードコーディングすることなく、依存関係が明確で保守性の高いデータパイプラインを構築できます。 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-genの杉村です。Google の生成 AI ノートブックサービスである NotebookLM で、Google Cloud 認定資格など、資格試験の勉強をする方法を紹介します。 はじめに NotebookLM とは NotebookLM による学習 データソース追加 テストの生成 フラッシュカードの生成 レポートの生成 音声解説 動画解説 はじめに NotebookLM とは NotebookLM は、Google の生成 AI ノートブックサービスです。ウェブサイトやテキストファイル、Google ドキュメントなど、様々なデータソースを読み込ませて、それらの情報源をベースにして生成 AI とチャットができるほか、クイズやレポートの生成、ラジオのような解説音声の生成などを行うことができます。 NotebookLM は、Google アカウントさえあれば無償で利用することができます。Google Workspace や有償版 Google アカウントに所属する NotebookLM in Pro や、Google Cloud サービスである NotebookLM Enterprise であれば、入力したデータは Google によって再トレーニングされないなど、データが保護されます。 NotebookLM 以下の記事も参考にしてください。 参考 : NotebookLMの情報整理と応用テクニック - G-gen Tech Blog 参考 : NotebookLM の「音声概要」で聴く学習を試してみたら便利すぎた - G-gen Tech Blog 参考 : NotebookLM無償版・Pro・Enterpriseの違い - G-gen Tech Blog 参考 : NotebookLM vs Gemini アプリ:業務で使い分けるための実践知識まとめ - G-gen Tech Blog NotebookLM による学習 NotebookLM の以下のような機能は、試験やスキルアップのための学習に活かすことができます。 データソースを追加することによる AI とのチャット クイズ（テスト）生成 フラッシュカード生成 レポート生成 音声解説生成 動画解説生成 当記事では、これらの機能を使い、Google Cloud 認定資格「Professional Security Operations Engineer」の勉強をした事例を紹介します。 なお、当記事で紹介する機能やスクリーンショットは、記事を執筆した2025年9月下旬現在のものです。 データソース追加 最初に行うことは、ノートブックの新規作成と、データソースの追加です。 まず、 https://notebooklm.google.com/ にアクセスします。Google アカウントへのログインを求められた場合、ログインします。表示されたトップ画面で「ノートブックを新規作成」をクリックします。 NotebookLM トップ画面 「ソースを追加」画面が表示されるので、ここにデータソースを追加します。データソースは、あとからいつでも自由に追加可能です。 データソースの追加 今回は、以下のようなデータソースを追加しました。 G-gen Tech Blog の試験対策記事（ Professional Security Operations Engineer試験対策マニュアル - G-gen Tech Blog ） 公式の試験ガイド（ https://services.google.com/fh/files/misc/professional_security_operations_engineer_exam_guide_english.pdf ） Google SecOps の公式ドキュメント（ https://cloud.google.com/chronicle/docs/secops/secops-overview?hl=en ）から、特に学習したい機能のページを抜粋して追加 社内の試験 Tips に関する Google ドキュメント なお記事を執筆した2025年9月下旬現在、アスタリスクを使用して「 https://cloud.google.com/chronicle/docs/* 」のように URL をワイルドカード形式で指定することはできず、エラーになります。 データが取り込めると、ノートブック画面が表示されます。タイトルが自動で生成されるほか、概要の文章が中央部分に表示されています。学習を進めるに当たって、さらに理解を深めたいと感じた領域については、随時、左上の「ソース」ブロックの「+ 追加」ボタンからデータソースを追加します。 ノートブック画面 テストの生成 画面右側の「Studio」ブロックにある「テスト」ボタンを押下して、NotebookLM にテストを作成させます。「テスト」ボタンを押すと、数分後にテストが生成されます。 生成されたテスト 生成されたテスト「セキュリティ 問題集」をクリックすると、4肢選択式のテストが始まります。 4肢選択式のテスト 「説明」をクリックすると、その問題に関する詳細な説明を AI に依頼することができます。解説文中には、引用元のデータソースへのリンクが含まれます。 AI による解説（左部分） わからないことがあれば、画面中央下のテキストボックスに質問を入力することで、AI にさらに詳細な解説を求めたり、わからない単語を説明させることができます。 フラッシュカードの生成 次に、画面右側の「Studio」ブロックにある「フラッシュカード」ボタンを押下して、NotebookLM にフラッシュカードを作成させます。フラッシュカードとは、学生が英単語を覚えるときに使うような、表面に質問が書いてあり、裏面に答えが書いてあるようなカードです。「フラッシュカード」ボタンを押すと、数分後に生成されます。 フラッシュカード フラッシュカードは、試験直前の知識の確認などに有用です。 レポートの生成 画面右側の「Studio」ブロックにある「レポート」ボタンを押下すると、どのようなレポートを生成するかの選択肢が表示されます。AI が提案する選択肢の中から1クリックで選べるほか、プロンプトで細かくテイストを指示することもできます。 レポート生成時の選択肢 今回は「独自に作成」を選び、以下のようなプロンプトを記述してみました。 プロンプトを記述して独自レポートを生成 Google Cloud 認定資格「Professional Security Operations Engineer」の試験勉強をしたいです。 Google SecOps や Security Command Center の各機能の詳細な解説や、SecOps 運用体制に関する説明など、試験に役立つコンセプトを詳細にまとめたレポートを作ってください。特に、技術的な解説を多めに、また詳細にお願いします。 数分後、以下のようなレポートが生成されました。 NotebookLM によって生成された学習用レポート 音声解説 「Studio」ブロックにある「音声解説」ボタンを押下すると、2人の人物がラジオやポッドキャストのように、データソースに関する会話をしている音声を生成できます。 移動中や家事の合間などの「ながら勉強」に利用できます。 英語の音声が生成されてしまう場合には、「音声解説」ボタンの右上に表示されている鉛筆マークを押してください。ここでは出力言語が選べるほか、どのような音声を生成するか、また音声の長さなどを詳細に指定することができます。焦点を当てるトピックを自然言語で指示することもできます。 音声概要の詳細設定画面 生成された音声はノートブック上で再生できるほか、mp4 形式でダウンロードすることもできます。今回はデフォルト設定で、約21分間の音声が生成されました。 生成された音声 動画解説 NotebookLM では、動画による解説を生成することもできます。「Studio」ブロックにある「動画解説」ボタンを押下します。こちらでも、鉛筆マークを押すことで、出力言語や注力するトピックなどを指定できます。 動画はスライドと、それを解説する音声で構成されており、日本語で生成することができます。生成された動画はノートブック上で再生できるほか、mp4 形式でダウンロードすることもできます。デフォルト設定のまま生成したところ、約8分間の動画が生成されました。 動画概要で生成された動画（1） 動画概要で生成された動画（2） 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。2025年9月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Podcast API が許可リスト制で公開 BigQuery の Managed disaster recovery で soft failover が実行可能に Cloud Run worker pools で GPU が使えるように Google Vids で Google スライドから動画を生成できるように GKE Enterprise 機能の一部が追加費用なしで利用可能に Cloud SQL で最終バックアップの取得有無をインスタンス単位で設定可能に AlloyDB AI natural language が Public Preview NotebookLM Enterprise で API によるノートブック操作が可能に Veo 3 と Veo 3 Fast が値下げ environment タグが Google Cloud コンソールのプロジェクト表記に反映 Vertex AI Agent Engine で複数アップデート Google スプレッドシートに変更履歴の「凝縮表示」が登場 Looker Studio で破壊的仕様変更 職務ごとの「事前定義ロール」が新しく登場 IAM 権限不足エラー表示がより詳細に Model Armor と Application Load Balancer が統合可能に BigQuery advanced runtime が一般公開（GA） Google Agentspace と NotebookLM Enterprise で Model Armor が使用可能に Googleカレンダーの予定複製時に Google Meet 会議が複製されなくなる Google Meet で Ask Gemini in Meet が一部の顧客に展開開始 Gemini アプリの Gems が他人に共有できるように Compute Engine で GPU 等を確保しやすい Flex-start VM が一般公開（GA） BigQuery から PostgreSQL-dialect の Spanner への federated queries が GA Gemini 2.5 Flash with Live API Native Audio が Preview 公開 Google スプレッドシートの AI 関数が日本語でも利用可能に Google スプレッドシートで Gemini による関数生成が強化 Gemini CLI extensions for BigQuery が公開 gemini-1.5-pro-002 と gemini-1.5-flash-002 の提供が終了 Gemini 2.5 Flash と Flash-Lite の新しいバージョンが Preview 公開 Cloud SQL でマネージドコネクションプール機能が Preview → GA BigQuery で history-based optimizations がデフォルトで有効に Dataplex でカラムレベルのリネージが利用可能に Privileged Access Manager（PAM）で複数のアップデート Google チャットのスペースのロールに「オーナー」が新設 パソコン版 Google ドライブでランサムウェア検出がベータ公開 Cloud DNS で Alias record タイプが Preview → GA 音声合成モデル Gemini-TTS が一般公開（GA） はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Podcast API が許可リスト制で公開 Generate podcasts (API method) (2025-08-28) Podcast API が許可リスト制で公開。利用にはGoogleへの申請が必要。 ポッドキャスト風音声が API 経由で生成できる。テキスト、画像、音声、動画をインプットして、MP3 音声を出力。 製品ラインとしては NotebookLM Enterprise だが、NotebookLM Enterprise や Agentspace のライセンスは不要。API endpoint は以下。 https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/podcasts BigQuery の Managed disaster recovery で soft failover が実行可能に Managed disaster recovery (2025-09-03) BigQuery の Managed disaster recovery で soft failover が実行可能に。 両リージョンが生きているときのみ使用可能。セカンダリリージョンへのレプリケーション完了を待ってフェイルオーバ・昇格する。計画的切り替えや、災対訓練などに利用可能。 Cloud Run worker pools で GPU が使えるように GPU support for worker pools (2025-09-03) Cloud Run worker pools（Preview 中）で GPU が使えるように。 NVIDIA L4 GPUs with 24 GB VRAM が使用可能。 Google Vids で Google スライドから動画を生成できるように 'Help me create' in Google Vids now includes support for Google Slides (2025-09-03) 動画編集ツール Google Vids に、Google スライドから動画を生成する機能が登場。 スライドを解説するような動画が簡単に制作できる。Business Starter以上で使えるが、まずは英語版のみ・順次ロールアウトな点に注意。 GKE Enterprise 機能の一部が追加費用なしで利用可能に GKE release notes - September 02, 2025 (2025-09-02) GKE Enterpriseで提供されていた機能の一部が、追加費用なしで GKE Standard で利用可能になった。 Fleet dashboard、Multi-team Management、Config Controller など。他の一部機能は、スタンドアロンな SKU として課金され使用可能。 Cloud SQL で最終バックアップの取得有無をインスタンス単位で設定可能に Take a final backup at instance deletion (2025-09-03) Cloud SQL インスタンスの削除時に最終バックアップを自動で取るかどうか、またその保持期間を、インスタンスの設定値として事前に設定できるようになった。 Cloud SQL for MySQL / PostgreSQL / SQL Server のいずれにも対応。 AlloyDB AI natural language が Public Preview AlloyDB AI natural language overview (2025-09-04) AlloyDB for PostgreSQL で、AlloyDB AI natural language が Public Preview。 エンドユーザーの自然言語による質問に対して SQL を自動生成。 alloydb_ai_nl.get_sql() 関数で DB 側で SQL を生成できるので、生成 AI モデルの API 呼び出しが不要。 NotebookLM Enterprise で API によるノートブック操作が可能に Create and manage notebooks using the API (2025-09-05) NotebookLM Enterprise で API 経由でノートブック作成、データソース追加、リストアップ、最近見られたノートブックの表示、削除などができるようになった。 個人版や Google Workspace 付属の NotebookLM ではなく、Google Cloud で提供されるEnterprise 版のみの機能であることに注意。 Veo 3 と Veo 3 Fast が値下げ Veo 3 and Veo 3 Fast – new pricing, new configurations and better resolution (2025-09-08) 動画生成モデル Veo 3 が、以下のとおり値下げ。 Veo 3 : $0.75 / second → $0.40 / second Veo 3 Fast : $0.40 / second → $0.15 / second environment タグが Google Cloud コンソールのプロジェクト表記に反映 Designate project environments with tags (2025-09-10) Google Cloud プロジェクトに environment タグを付けると、Google Cloud コンソールでプロジェクト表記の右に環境名が表示できるようになった。 オペレーションミス等の予防に少し役立つ。 Vertex AI Agent Engine で複数アップデート Vertex AI release notes - September 10, 2025 (2025-09-10) Vertex AI Agent Engine で複数アップデート。 A2A 対応 サンドボックス環境でのコード実行（Preview） 双方向ストリーミング Google Cloud コンソールで Memory Bank タブが登場 Google スプレッドシートに変更履歴の「凝縮表示」が登場 Understand changes more quickly with condensed version history in Sheets (2025-09-10) Google スプレッドシートに、変更履歴の「凝縮表示」が登場。 変更があったセルを含む行のみが表示される表示方法。順次ロールアウト。 Looker Studio で破壊的仕様変更 Looker Studio release notes - September 11, 2025 (2025-09-11) Looker Studio で、2つの破壊的仕様変更（破壊的仕様変更 = Breaking change。後方互換性を維持しない仕様変更）。 データソースへの認証が「閲覧者の認証情報」のとき、そのデータソースのディメンションの HYPERLINK() でのリンク化や画像表示がレンダリングされなくなる ただし Looker Studio Pro で、レポート作成者と閲覧者が同じチームワークスペースに所属している場合はこの制限は適用されない Explorer 機能が廃止される Explorer 機能は数年にわたり Beta 公開だった 既存の Explorer は自動でレポートに変換される 職務ごとの「事前定義ロール」が新しく登場 Predefined roles for job functions (2025-09-12) 職務ごとの「事前定義ロール」が新しく登場。以下に一例を示す。 Databases administrator（ roles/iam.databasesAdmin ） Infrastructure administrator（ roles/iam.infrastructureAdmin ） Data scientist（ roles/iam.dataScientist ） Site reliability engineer（ roles/iam.siteReliabilityEngineer ） IAM 権限不足エラー表示がより詳細に Troubleshoot permission error messages (2025-09-12) Google Cloudコンソールで IAM 権限不足エラーの際に、足りない権限を含んでいるロール一覧が表示されるようになった。 Request permissions ボタンを押してエッセンシャルコンタクトのTechnical 担当者宛てに、権限付与の依頼メールを送信することもできる。 Model Armor と Application Load Balancer が統合可能に Configure a traffic extension to call the Model Armor service (2025-09-15) Model Armor と Application Load Balancer が統合可能になった（GA）。 ALB に Service Extension を挟み込むことで、ALB を通るすべてのプロンプトとレスポンスが Model Armor で検査される。 BigQuery advanced runtime が一般公開（GA） Use the BigQuery advanced runtime (2025-09-15) BigQuery advanced runtime が一般公開（GA）。 新しいランタイム（実行環境）。2025年9月15日から2026年初頭にかけ全プロジェクトでデフォルトになるが、それまでは任意で有効化できる。以下の性能向上。 Enhanced vectorization（新しいクエリ処理モデル） Short query optimization（小規模クエリを高速化） Short query optimization については、以下の記事も参照。 blog.g-gen.co.jp Google Agentspace と NotebookLM Enterprise で Model Armor が使用可能に Google Agentspace release notes - September 15, 2025 (2025-09-15) Google Agentspace と NotebookLM Enterprise で Model Armor が使用可能に。 AI へのプロンプトとレスポンスをスクリーニングし情報漏洩や悪意ある攻撃を遮断。 Googleカレンダーの予定複製時に Google Meet 会議が複製されなくなる Enhancing meeting privacy for copied Calendar events (2025-09-16) Googleカレンダーで予定を複製したときに、Google Meet 会議は複製されなくなる。 会議のプライバシーを保つためと説明されている。順次ロールアウトで、管理者による設定でこの挙動は変更できない。 Google Meet で Ask Gemini in Meet が一部の顧客に展開開始 Ask Gemini in Meet: Your Personal Meeting Assistant (2025-09-17) Google Meet で Ask Gemini in Meet が一部の顧客に展開開始。会議中に Gemini に依頼ができる。 議論経過を要約 結論やアクションアイテムを列挙 途中参加したミーティングのこれまでの内容をキャッチアップ まずは英語のみ対応だが他の言語も追って対応予定。 Gemini アプリの Gems が他人に共有できるように Introducing Gems sharing in the Gemini app, including admin controls (2025-09-18) Gemini アプリの Gems が他人に共有できるようになった。 共有相手には Gem 一覧やドライブの共有アイテムに表示される。共有すると、Gem は Google ドライブでファイルとして管理される。共有の方式は Google ドライブファイルと同じ。 組織内・外への共有が可能であり、編集権限付与も可。 Gems の詳細は以下の記事を参照。 blog.g-gen.co.jp Compute Engine で GPU 等を確保しやすい Flex-start VM が一般公開（GA） About Flex-start VMs (2025-09-22) Compute Engine で GPU などを確保しやすい Flex-start VM が一般公開（GA）。 Flex-start VM は、最大7日間実行できる割引価格のインスタンス。Dynamic Workload Scheduler（DWS）によりスケジューリングが最適化さており、通常よりリソースを確保できる可能性が高い。 BigQuery から PostgreSQL-dialect の Spanner への federated queries が GA Spanner release notes - September 22, 2025 (2025-09-22) BigQuery から PostgreSQL-dialect の Spanner への federated queries が一般公開（GA）。 従来は GoogleSQL インスタンスのみ対応していた。クロスリージョンでもクエリ可能。 Gemini 2.5 Flash with Live API Native Audio が Preview 公開 Gemini 2.5 Flash - Live API native audio (2025-09-23) Gemini 2.5 Flash with Live API Native Audio（ gemini-live-2.5-flash-preview-native-audio-09-2025 ）が Preview 公開。 音声/テキスト/動画をインプットとして音声やテキストをアウトプット。低レイテンシで AI との自然な会話を実現する。 Google スプレッドシートの AI 関数が日本語でも利用可能に Generate data with AI function in Sheets now available in seven additional languages (2025-09-23) Google スプレッドシートの AI 関数が、日本語でも利用可能になる。 AI 関数では、セルの内容を生成 AI モデル Gemini が処理できる。 Google Workspace の管理者設定で「即時リリース」に設定してある場合、2025-09-23から15日以内にロールアウト。「計画的リリース」なら2025-10-06から15日以内にロールアウト。 Google スプレッドシートで Gemini による関数生成が強化 Gemini in Google Sheets now provides smarter, more conversational formula generation (2025-09-24) Google スプレッドシートで、Gemini による関数生成が強化された。 Google スプレッドシートではもともと、Gemini に自然言語で指示するとセル関数を生成できたが、今回の強化で「挙動をステップバイステップで詳細に解説」、「エラー修正」、「複数候補の提示」など、より便利になった。 Gemini CLI extensions for BigQuery が公開 Develop with the Gemini CLI (2025-09-24) BigQuery を自然言語でクエリ・操作できる Gemini CLI extensions for BigQuery が公開。従来より公開されていた MCP Toolbox がベース。 gemini extensions install のようにしてインストールできる。 gemini-1.5-pro-002 と gemini-1.5-flash-002 の提供が終了 Model versions and lifecycle (2025-09-24) 従前からの通告のとおり、本日から gemini-1.5-pro-002 や gemini-1.5-flash-002 の提供が終了。 これらのモデルへのリクエストは404となる。移行先は Gemini 2.0 や 2.5。 Gemini 2.5 Flash と Flash-Lite の新しいバージョンが Preview 公開 Vertex AI release notes - September 25, 2025 (2025-09-25) Gemini 2.5 Flash と Flash-Lite の新しいマイナーバージョンが Preview 利用可能。新しいモデル名は以下のとおり。 gemini-2.5-flash-preview-09-2025 gemini-2.5-flash-lite-preview-09-2025 以下の公式記事によると、精度が上がり、レイテンシは下がった。 参考 : Continuing to bring you our latest models, with an improved Gemini 2.5 Flash and Flash-Lite release - Google Developers Blog Cloud SQL でマネージドコネクションプール機能が Preview → GA Managed Connection Pooling overview (2025-09-25) Cloud SQL for PostgreSQL でマネージドコネクションプール機能が Preview → GA。 特に for PostgreSQL 版では、Preview 期間中は IAM 認証インスタンスではマネージドコネクションプールが使用できなかったが、使用できるようになった。 BigQuery で history-based optimizations がデフォルトで有効に Use history-based optimizations (2025-09-29) BigQuery で history-based optimizations がデフォルトで有効になった。 同じクエリを複数回実行することで、何もしなくてもクエリ実行時間やスロット消費が最適化される。 Dataplex でカラムレベルのリネージが利用可能に Column-level lineage (2025-09-29) Dataplex でカラムレベルのリネージが利用可能になった。 従来はテーブルレベルだったが、このアップデートにより列のレベルで、値がどこから来たか（単なる複製か、その他の依存関係か）がグラフィカルに表示できるようになった。 カラムレベルのリネージ Privileged Access Manager（PAM）で複数のアップデート IAM release notes - September 26, 2025 (2025-09-29) Privileged Access Manager（PAM）で複数のアップデート。 多段階の承認者 リクエスト時のスコープ調整 サービスアカウントを承認者として指定 権限付与の途中取り下げ ...など。PAM については以下の記事を参照。 blog.g-gen.co.jp Google チャットのスペースのロールに「オーナー」が新設 Changes to membership roles in Google Chat spaces to enable more flexible permissions (2025-09-29) Google チャットのスペースのロールに「オーナー」が増えて「マネージャー」「メンバー」とあわせて3種類になる。 既存のマネージャはオーナーになる。マネージャはオーナーとほぼ同じ権限だがスペース削除やオーナー移譲ができない。 パソコン版 Google ドライブでランサムウェア検出がベータ公開 Ransomware detection and file restoration for Google Drive available in beta (2025-09-30) パソコン版 Google ドライブでランサムウェア検出機能のベータ版が利用可能に。 ランサムウェアが検知されるとファイル同期が停止され警告が表示され、ユーザーと管理者にメールが送信される。またドライブ内に同期されたファイルなら簡単に以前のバージョンに復元できる。 Cloud DNS で Alias record タイプが Preview → GA Alias records (2025-09-30) Cloud DNS で Alias record タイプが Preview → GA。 ドメインのゾーンエイペックスに置ける、CNAME と同じ挙動をするレコード。 CNAME レコードは他の種類のレコードと重複してはいけないため、ゾーンエイペックス（example.com ゾーンにおける example.com）には CNAME を作れない。ここで ALIAS レコードが使われる。 example.com → Cloud Storage バケットのオブジェクトに飛ばす、などが可能になる。 音声合成モデル Gemini-TTS が一般公開（GA） Gemini-TTS (2025-09-30) 音声合成モデル Gemini-TTS が一般公開（GA）。 日本語を含む70以上の言語に対応し、30種類の声色がある。既存の Chirp との違いは、自然言語プロンプトでトーンやアクセントをきめ細かく指示できる点。Vertex AI Studio から試せる。 ※ TTS = Text-to-Speach 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Google Workspace では毎週、数個の機能アップデートが行われており、日々便利になり続けています。新しい機能の中には発表されてからすぐ使えるようになるわけではなく、時間をかけてロールアウト（順次リリース）されていくものがあります。そのスピードを制御する管理者設定について紹介します。 新機能のリリース設定 リリーススケジュール 即時リリースと計画的リリース 設定の変更 新機能のリリース設定 Google Workspace では、毎日のように新機能のアップデートが行われます。週に10個以上のアップデートが行われることも珍しくありません。アップデートは公式のリリースノートで確認することができます。リリースノートには日本語版もありますが、翻訳が数週間遅れるため、最新情報を確認するには英語版のサイトを見ることが推奨されます。 参考 : Google Workspace Updates 新しい機能のほとんどは、発表されてからすぐ使えるようになるわけではなく、時間をかけて順次リリースされます。この順次展開は ロールアウト （rollout）と呼ばれます。ロールアウトはすべての Google Workspace テナント（ドメイン）に同時に行われるのではなく、ある組織と別の組織では、ロールアウトされるタイミングが異なります。 また、組織ごとに、管理コンソールで リリース設定 を以下のいずれかから選択できます。 即時リリース （Rapid Release） 計画的リリース （Scheduled Release） どちらを選択するかによって、新機能がロールアウトされるタイミングや、早期一般提供（早期 GA）段階の機能を使用できるかどうかが決まります。リリース設定は、管理コンソール（ https://admin.google.com/ ）の [アカウント] > [アカウント設定] > [設定] から設定できます。 参考 : ユーザーに新機能をリリースするタイミングを選択する - Google Workspace 管理者ヘルプ リリーススケジュール ロールアウトの早さは、個々のアップデートごとに異なります。概ね以下のいずれかであり、そのアップデートがどれに該当するかは、アップデート記事に記載されています。 即時（Available now / Currently available / Already available。発表直後から利用可能） 完全に展開（ Full rollout 。起算日から1～3 日） 段階的に展開（ Gradual rollout 。起算日から最長 15 日） 長期的に展開（ Extended rollout 。起算日から15 日以上） 起算日は即時リリースと計画的リリースで異なっており、これも記事に記載されます。原則的に即時リリースのほうが起算日が早いですが、計画的リリースと同時のときもあります。 例として、「 Google スプレッドシートの AI 関数機能の日本語対応 」という機能アップデートでは、即時リリースは2025-09-23を起算日とする Gradual rollout で、計画的リリースの場合は2025-10-06を起算日とする Gradual rollout でした。 即時リリースと計画的リリース 即時リリース （Rapid Release）を選択している場合、いち早く新機能を使用することができます。 計画的リリース （Scheduled Release）では、即時リリースに1週間〜数週間遅れて機能がロールアウトされます。 公式ドキュメントでは、特に大組織においては以下のような戦略をとることを推奨しています。 本番環境ドメインでは計画的リリースを選択 テスト環境のドメインでは即時リリースを選択 テスト環境のドメインで新機能を試用したり、ユーザーからの問い合わせへの準備を整える。問題がなければ本番環境にも適用 このようにすることで、UI が変わったり新しい機能が使えるようになることでのユーザーの混乱を抑えたり、不具合の影響を抑えるなどが可能になります。しかし上記の方法は、複数の Google Workspace ドメインを保持する必要があり、管理工数や追加のライセンス費用が必要になってしまうため、運用体制の余力に応じて検討することになります。 設定の変更 リリース設定（即時リリースまたは計画的リリース）を変更するには、以下の手順を行います。この設定は、組織全体に適用されます。適用対象の組織部門等を選択することはできません。 1. 特権管理者アカウント等で管理コンソール（ https://admin.google.com/ ）にログイン 2. 左部メニューから [アカウント] > [アカウント設定] をクリック 3. [設定] をクリック [アカウント] > [アカウント設定] > [設定] 4. [新機能] をクリックし、即時リリースまたは計画的リリースを選択して保存 [新機能] なお、上記の「[新機能]」の下部に見える「新サービス」設定では、Google Workspace に新サービスがリリースされたときに、自動的に使用可能にするかどうかを選択する設定です。例えば、2024年11月には Google Vids という動画編集ツールが新サービスとしてリリースされました。 参考 : 新しいサービスをデフォルトで有効または無効にする - Google Workspace 管理者ヘルプ 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Google Cloud や Google Workspace といったクラウドサービスと、「英語」という言語の関係性について、またクラウド利用にあたっての言語の違いに関する注意点等について解説します。 クラウドと英語 Google 公式ドキュメント 生成 AI 関連機能 訳語の難しさと違い 認定資格 クラウドと英語 Google Cloud や Google Workspace といったクラウドサービスと、「英語」という言語は深い関係性を持ちます。多くのクラウドサービスで、ユーザーインターフェイスや公式ドキュメント、また新機能が 第1に対応する言語は英語 です。特に近年は生成 AI 関係のサービスや機能においては、リリース直後はまず英語のみが対応し、他の言語がそれに追随するといった状況が見られます。 その理由として、まず Google Cloud、Google Workspace、Amazon Web Services（AWS）、Microsoft Azure といった主要なパブリッククラウドサービスは、いずれもアメリカ合衆国出身の企業が開発したものであるからという点が挙げられます。開発者や、サービスを最初に利用するユーザーは、英語を母語とする人々です。 次に、市場規模も理由の1つです。英語は実質的に世界で最も多く話者を持つ言語であることから、最も優先すべき言語となります。クラウドサービスのローカライズ、特に日本語の対応は数か月遅れる場合もあります。 この状況から、クラウドサービスを利用するにあたって、日本語を母語とする人たちにとって注意すべき点が多々あります。当記事ではそのような注意点などについて解説します。 Google 公式ドキュメント Google Cloud や Google Workspace の公式ドキュメントは、主として以下のウェブサイトに公開されています。 Google Cloud 公式ガイド（ https://cloud.google.com/docs?hl=ja ） Google Workspace 管理者ヘルプ（ https://support.google.com/a/?hl=ja ） これらのドキュメントでは、 英語版のドキュメントに最も新しい情報が掲載 されており、日本語への翻訳は遅れる場合が多く見られます。同じ URL の同一ページでも、英語版に切り替えると、日本語版とは 異なる情報が表示される 場合があります。英語版と日本語版でで掲載情報が異なる場合、 正しい情報は英語版 であることに留意してください。 特に、サービスのアップデートが頻繁に行われる生成 AI 関連サービスや機能においては、最新情報や正しい情報を得るために、 可能であれば英語版ドキュメントを参照する ことが望ましいといえます。また、Preview 中だった機能が一般公開（GA）した場合なども、GA 直後は日本語版ドキュメントのみに「プレビュー」表記が残り、英語版ドキュメントからは表記が消えている、というケースもあります。日本語版ドキュメントと英語版ドキュメントでページ構成自体が異なっているケースもあります。 Google Cloud ドキュメントは、画面右上の地球儀マークから、言語を切り替えることができます。 Google Cloud ドキュメントの言語切替 Google Workspace ドキュメントは、画面の一番下までスクロールして最下部にあるセレクタで言語を切り替えることができます。 Google Workspace ドキュメントの言語切替 なお、Google Cloud・Google Workspace のいずれのドキュメントも、URL の末尾にクエリパラメータとして ?hl=en を付与すれば英語版ドキュメントが、 ?hl=ja を付与すれば日本語版ドキュメントが表示されます（クエリパラメータは、 # で始まるアンカーよりも前に書きます）。 例 # 英語版ドキュメントへの URL https://cloud.google.com/resource-manager/docs/managing-notification-contacts?hl=en # 英語版ドキュメントへの URL（アンカーがある場合） https://cloud.google.com/resource-manager/docs/managing-notification-contacts?hl=en#notification-categories 生成 AI 関連機能 Google Workspace の生成 AI 関連などでは、まず英語のみが対応し、続けて他の言語が対応する例があります。以下は、その例です。 参考 : “Take notes for me” in Google Meet now captures “next steps” 参考 : Language expansion for “suggested next steps” when using “Take Notes for Me” 最初の記事は、Google Meet のウェブ会議で Gemini が議事録を作成してくれる Take notes for me 機能に関する2025年2月18日のリリースです。次の記事は、その約半年後の2025年8月7日に、Take notes for me 機能が日本語、韓国語、フランス語、スペイン語などを含む追加の言語に対応したことを発表する記事です。 同様に、Google スプレッドシートの AI 関数機能も、機能自体の発表（ 2025-06-25 ）から3ヶ月ほど遅れて、日本語等の追加の言語の対応が発表（ 2025-09-23 ）されました。 生成 AI は特に自然言語に関するタスクを得意としますが、品質が重視されるようなサービスでは、Google が調整に時間をかけるケースがあります。上記の議事録機能のほか、画像生成などに関しても、日本語対応には時間がかかりました。これは、一歩間違えればコンプライアンスや倫理問題に繋がりかねない言語間の違いを調整するために、Google が慎重に調整を行っているためと考えられます。 Google Workspace では、日本のユーザーでも、 言語の個人設定で言語を切り替える ことで、英語版のみに対応している機能を使えるようになるケースがあります。 Google Workspace の個人の言語設定を英語に変更するには、Gmail や Google ドライブなど Google Workspace のいずれかのアプリ画面を開いてから、右上のアバター画像をクリックし、「Google アカウントを管理 > 個人情報 > ウェブ向けの全般設定 > 言語」をクリックします。表示された設定画面で、英語が存在しない場合は「+ 他の言語を追加」をクリックして英語を追加し、メイン言語に設定します。 言語設定の変更 ただし、機能によっては「米国に居住するユーザーのみ利用可能」など、居住国で制限がされるケースもあるため、このような場合には言語設定を切り替えても利用することはできません。これは、欧州連合（EU）など特に法的規制が厳しい国のユーザーに対する対策などであると考えられます。 訳語の難しさと違い Google Cloud においては、公式ドキュメントや Google Cloud コンソール（Web UI）を日本語で利用することができます。ただし、ときとして用語が日本語へ翻訳されたことで逆にわかりづらくなるようなケースもあります。 原語 日本語訳(ドキュメント) Commited use discounts（CUD） 確約利用割引（CUD） BigQuery data preparation BigQuery データの準備 Privileged Access Manager Admin 特権アクセス マネージャー管理者 また、特に IAM ロールの名称の翻訳でしばしば見られるのは、ドキュメント上の訳語と、Google Cloud コンソール上の訳語が異なるケースです。 例えば前掲の Privileged Access Manager Admin（ roles/privilegedaccessmanager.admin ）ロールは、公式ドキュメント上は「Privileged Access Manager 管理者」と記載されていますが、Google Cloud コンソール上は「特権アクセス マネージャー管理者」と表記されます。コンソール上で IAM ロールを付与しようとして「Privileged Access Manager 管理者」で検索しても、見つからないことになります。特に IAM ロールの場合、 roles/ で始まる ID を使って識別するか、コンソールの言語設定を英語版に切り替えることで対策できます。 Google Cloud コンソールの表記を英語に切り替えるには、コンソール右上の三点リーダーから「設定（英語では Preferences）」を選び、「言語と地域」を選んで表示される設定画面で、英語を選択して保存します。米国英語である English (United States) と英国英語である English (United Kingdom) がありますが、特にこだわりがなければ米国英語を選択するのが無難でしょう。 Google Cloud コンソールの言語切替 認定資格 Google Cloud 認定資格も、特に新しいものはまず英語版のみが発表されます。日本語は比較的優遇されており、英語以外の言語では日本語が最も対応している認定資格が多いです。 2025年9月下旬現在、14個の Google Cloud 認定試験のうち、10個の試験が日本語に対応しています。逆に日本語以外では、スペイン語とポルトガル語が1資格（Cloud Digital Leader）、フランス語が2個の資格（Cloud Digital Leader と Associate Cloud Engineer）で対応しているのみです。日本がマーケットとして重視されている点と、「英語が苦手」な人が多い実態が考慮されているように思われます。 Google Cloud 認定資格試験の言語の対応状況については、以下の記事も参照してください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。組織で定めた標準構成の Google Cloud プロジェクトを、Terraform を使って払い出すためのサンプル構成ファイルをご紹介します。 はじめに 標準構成のプロジェクトと Terraform 免責事項 フォルダ構成 ルートモジュール main.tf provider.tf variables.tf terraform.tfvars リソースモジュール projects.tf apis.tf iam.tf variable.tf カスタマイズ トラブルシューティング はじめに 標準構成のプロジェクトと Terraform 企業や官公庁などにおいて、複数の部署やチームが Google Cloud を利用する場合、情報システム部門等が Google Cloud プロジェクトの標準的な構成を定め、それを利用部門に対して払い出し、セキュアな利用を促すことは一般的に行われています。 Terraform などの Infrastructure as Code（IaC）ツールを用いることで、以下のような所定の構成を持つプロジェクトをミスなく、少ない工数で払い出すことができるようになります。 所定の請求先アカウントをプロジェクトに紐づけ 所定の IAM ロールを申請者に付与 決まった構成の VPC ネットワークとサブネットを作成 所定の「組織のポリシーの制約」をプロジェクトにアタッチ 当記事では、Google Cloud で IaC を実現するときのデファクトスタンダードである Terraform を用いた場合の、ファイル構成や構成ファイルのサンプルをご紹介します。 免責事項 当記事で紹介するプログラムのソースコードや構成ファイルは、ご自身の責任のもと、使用、引用、改変、再配布して構いません。 ただし、同ソースコードが原因で発生した不利益やトラブルについては、当社は一切の責任を負いません。 フォルダ構成 当記事のサンプルでは、以下のようなフォルダ構成を取ります。 environments/ └ prd 　├ main.tf 　├ backend.tf 　├ variables.tf 　└ terraform.tfvars modules/ └ projects/ 　├ apis.tf 　├ iam.tf 　├ projects.tf 　└ variables.tf この構成では、 ルートモジュール （terraform apply などを実行するディレクトリ）と、 リソースを定義するモジュール を別々のディレクトリに配置しています。このような構成は Google Cloud の公式ドキュメントでも、ベストプラクティスとして記載されています。 参考 : ルート モジュールのベスト プラクティス - Google Cloud 上記のサンプルでは environments ディレクトリに prd というディレクトリだけを用意し、ここをルートモジュールとしています。必要に応じて複数の環境のディレクトリを作成します。prd、stg、dev といった区切り方や、あるいは部署ごと、サブシステムごとといった区切り方が考えられます。適切な区切り方は、運用体制などに応じて検討します。 リソースを定義するモジュールは、 modules ディレクトリ以下に格納します。今回は projects というディレクトリを作成し、ここに標準構成のプロジェクトを定義します。これをルートモジュールから呼び出すことで、同じ構成のプロジェクトの複数の払い出しを実現します。 ルートモジュール main.tf ルートモジュールの main.tf は、以下のように記述します。 # 1個目のテナント module "tenant_test01" { source = "../../modules/projects" # テナント固有情報 tenant = { name = "my-test-project-01" folder_id = "123456789012" billing_account_id = var.common_billing_account } tenant_groups = { admin = [ "group:sys-admin@example.com" , "user:john-doe@example.com" ] developer = [ "group:dev-team-01@example.com" ] viewer = [ "user:ichiro-suzuki@g-gen.co.jp" ] } } # 2個目のテナント module "tenant_test02" { source = "../../modules/projects" # テナント固有情報 tenant = { name = "my-test-project-02" folder_id = "123456789012" billing_account_id = var.common_billing_account } tenant_groups = { admin = [ "group:sys-admin@example.com" , "user:john-doe@example.com" ] developer = [ "group:dev-team-02@example.com" ] viewer = [ "user:tom-brown@g-gen.co.jp" ] } } 今回のサンプルでは、1つの main.tf ファイルに複数のテナント（利用部署）のプロジェクトを記述しています。利用部署が増えるたびに、 module "tenant_test01" { ... } の部分を増やしていきます。 プロジェクトが所属するフォルダは、テナントごとに指定できるようにしました。一方、プロジェクトに紐づける請求先アカウントは変数を使って共通の請求先アカウント ID を指定できるようにしました。変数への値の代入は、変数ファイル（ terrafoirm.tfvars ）で行います。 また、IAM ロールの付与も実現しています。あらかじめ「admin」「developer」「viewer」という権限セットをリソースモジュール側で定義しておきます。定義に応じた IAM ロールが、ここで指定した Google グループやアカウントに付与されます。 provider.tf provider.tf では、プロバイダの情報と、state ファイルを格納するバックエンドバケットを定義します。 先述の Google のベストプラクティスのドキュメントでは、provider はリソースモジュール側で定義していましたが、ここでは統一された標準構成をすべてのテナントにデプロイする意図で、ルートモジュール側に持たせました。 # provider ・バックエンド定義 provider "google" { region = "asia-northeast1" request_timeout = "60s" } terraform { required_providers { google = { source = "hashicorp/google" version = "~> 7.3.0" } } required_version = ">= 1.5.7" backend "gcs" { bucket = "my-state-bucket" prefix = "standard-project/" } } state ファイルを Cloud Storage バケットに格納することの意義などについては、以下の記事も参考にしてください。 blog.g-gen.co.jp variables.tf このファイルでは、ルートモジュールの変数を宣言しています。今回は、組織が共通で使う請求先アカウントの ID を代入するための変数を宣言します。 # 共通の請求先アカウント variable "common_billing_account" { type = string } terraform.tfvars このファイルでは、組織が共通で使う請求先アカウントの ID を変数に代入します。これにより、同じ請求先アカウントを複数のプロジェクトに紐づけできます。 common_billing_account = "01234A-56789B-43210C" Terraform においては、Google Cloud プロジェクトに紐づける請求先アカウントは名称ではなく英数字とハイフンで構成される ID で指定することに注意してください。 参考 : google_project - Terraform リソースモジュール projects.tf このファイルでは、Google Cloud プロジェクトのみを定義します。 # プロジェクト resource "google_project" "project" { # DELETE だと terraform で削除されるとプロジェクトが削除される。"ABANDON" だと state のみ削除 deletion_policy = "ABANDON" # プロジェクト名は6~30文字、英大文字不可 name = var.tenant.name project_id = var.tenant.name folder_id = var.tenant.folder_id billing_account = var.tenant.billing_account_id # false で default VPC ネットワークを作成しない auto_create_network = false } 誤用や事故を防ぐため、プロジェクト名とプロジェクト ID は同一の値としました。またここで、所属するフォルダ ID や紐づける請求先アカウントを指定しています。 deletion_policy はメタ引数（Google Cloud リソースとしての構成には影響はないが、Terraform が管理上用いる引数）です。値を DELETE にすると、Terraform リソースが削除されたときに、実際に Google Cloud プロジェクトも削除されます。ABANDON にすると、Terraform の state からは削除されますが、実際に Google Cloud プロジェクトは削除されずに残ります。 参考 : google_project - Terraform また、 auto_create_network の値を false にすることで、本番環境では推奨されない構成であるデフォルトネットワークの作成を防いでいます。ただし、組織全体でデフォルトネットワークの作成を防ぐには、このようにリソース作成時に作成をスキップするだけでなく、組織のポリシーの制約である constraints/compute.skipDefaultNetworkCreation を用いることが推奨されます。 組織のポリシーについては以下の記事も参照してください。 blog.g-gen.co.jp apis.tf このファイルでは、プロジェクトで有効化する API を記述します。 ## プロジェクトで有効化するサービス API locals { apis = [ "compute.googleapis.com" , "cloudfunctions.googleapis.com" , "run.googleapis.com" ] } # API 有効化 resource "google_project_service" "enable_apis" { for_each = toset (local.apis) project = google_project.project.id service = each.value } 参考 : google_project_service - Terraform 有効化する対象 API は、配列形式のローカル変数で定義しています。対象の API を増やしたい場合は、ここに追加します。 iam.tf このファイルでは、IAM ロールの付与方法を定義します。ルートモジュールで「admin」「developer」「viewer」という権限セットが記述されていましたが、それぞれどのようなロールが付与されるかは、このファイルに定義されています。 ######################### # IAM 定義 - 管理者グループ ######################### # ロール : 閲覧者 resource "google_project_iam_member" "admin_viewer" { for_each = toset (var.tenant_groups.admin) project = google_project.project.id role = "roles/viewer" member = each.value } # ロール : プライベート ログ閲覧者 resource "google_project_iam_member" "admin_private_log_viewer" { for_each = toset (var.tenant_groups.admin) project = google_project.project.id role = "roles/logging.privateLogViewer" member = each.value } # ロール : Compute 管理者 resource "google_project_iam_member" "admin_compute_admin" { for_each = toset (var.tenant_groups.admin) project = google_project.project.id role = "roles/compute.admin" member = each.value } # ロール : Cloud Run 管理者 resource "google_project_iam_member" "admin_cloud_run_admin" { for_each = toset (var.tenant_groups.admin) project = google_project.project.id role = "roles/run.admin" member = each.value } ######################### # IAM 定義 - 開発者グループ ######################### # ロール : 閲覧者 resource "google_project_iam_member" "developer_viewer" { for_each = toset (var.tenant_groups.developer) project = google_project.project.id role = "roles/viewer" member = each.value } # ロール : プライベート ログ閲覧者 resource "google_project_iam_member" "developer_private_log_viewer" { for_each = toset (var.tenant_groups.developer) project = google_project.project.id role = "roles/logging.privateLogViewer" member = each.value } # ロール : Compute インスタンス管理者（v1） resource "google_project_iam_member" "developer_compute_admin" { for_each = toset (var.tenant_groups.developer) project = google_project.project.id role = "roles/compute.instanceAdmin.v1" member = each.value } # ロール : Cloud Run デベロッパー resource "google_project_iam_member" "developer_cloud_run_admin" { for_each = toset (var.tenant_groups.developer) project = google_project.project.id role = "roles/run.developer" member = each.value } ######################### # IAM 定義 - 閲覧者グループ ######################### # ロール : 閲覧者 resource "google_project_iam_member" "viewer_viewer" { for_each = toset (var.tenant_groups.viewer) project = google_project.project.id role = "roles/viewer" member = each.value } # ロール : プライベート ログ閲覧者 resource "google_project_iam_member" "viewer_private_log_viewer" { for_each = toset (var.tenant_groups.viewer) project = google_project.project.id role = "roles/logging.privateLogViewer" member = each.value } 参考 : IAM policy for projects - Terraform for_each = toset(var.tenant_groups.admin) member = each.value のように定義することで、ルートモジュールから渡されたすべての Google グループやアカウントに対して、IAM ロールが付与されるようにしています。 なお、ここでは google_project_iam_member という Terraform リソースを使用しています。その他の IAM ポリシー関係のリソースとの違いや注意点については、以下の記事を参照してください。 blog.g-gen.co.jp variable.tf このファイルでは変数を宣言します。ルートモジュールから渡されるべき変数を定義しています。 # テナント情報 variable "tenant" { type = object ( { name = string folder_id = string billing_account_id = string } ) } # 権限を付与する Google アカウント・グループのリスト variable tenant_groups { type = object ( { admin = list ( string ) developer = list ( string ) viewer = list ( string ) } ) } カスタマイズ ここまで掲載したサンプル構成ファイルをカスタマイズすることで、組織内で標準化されたプロジェクトを複数のテナントに払い出すことができます。 カスタマイズすることで、例として、払い出したプロジェクトに標準構成の VPC ネットワークを作成してそれを Network Connectivity Center ハブに接続する等も可能です。 当記事に掲載した構成ファイルはあくまでサンプルですので、実際には組織のガイドライン、運用ルール、運用体制などに準じた形の構成ファイルを記述し、使用してください。 トラブルシューティング terraform apply コマンドを実行した際に、以下のようなエラーが出力されることがあります。 Error: Provider produced inconsistent result after apply When applying changes to module.tenannt_test01.google_project_iam_member.admin_cloud_run_admin["group:non-existing-group@example.com"], provider "provider[\"registry.terraform.io/hashicorp/google\"]" produced an unexpected new value: Root resource was present, but now absent. This is a bug in the provider, which should be reported in the provider's own issue tracker. エラーメッセージには「Terraform の Google Cloud provider のバグである」旨が記述されていますが、実際にはこのエラーは、 存在しない Google グループ を IAM メンバーに指定した際に発生しました。このエラーが出力された際は、IAM ロール付与対象のプリンシパルとして指定した Google アカウントやGoogle グループの存在有無を確認してください。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it