当記事は、ライオン株式会社様と株式会社G-genの 技術情報発信コラボレーション企画 『SAPと連携するデータ分析基盤の実践とTips』で執筆されたものです。 当企画について ライオンによる記事 1. ライオンのデータ基盤構築とSAPデータ活用体制 2. ライオンのデータマネジメント 3. ライオンのデータ基盤における分析環境 G-gen による記事 1. VPC Service Controls の境界の分割設計に関する考察 2. Security Command Center検出結果のPub/Subエクスポートをフィルタリングする 3. Security Command Center検出結果を一時的にミュートする方法 当企画について 当記事は株式会社 G-gen 様とライオン株式会社の技術ブログ相互寄稿企画で執筆されたものです。 当企画では、ライオン側からは、Google Cloud 環境に構築を進めているデータ基盤に関連した以下の記事を公開しました。 ライオンのデータ基盤構築とSAPデータ活用体制 ライオンのデータマネジメント ライオンのデータ基盤における分析環境 G-gen 側からは、Google Cloud のセキュリティと統制に関わる、以下の記事を公開しました。 VPC Service Controlsの境界の分割設計に関する考察 Security Command Center検出結果のPub/Subエクスポートをフィルタリングする Security Command Center検出結果を一時的にミュートする方法 当記事では、上記の記事をそれぞれ要約してお伝えします。 ライオンによる記事 1. ライオンのデータ基盤構築とSAPデータ活用体制 ライオン株式会社では、中期経営計画「Vision 2030 2nd STAGE」の実現に向け、全社的なデータ活用を支える基盤構築を Google Cloud 上で進めています。これまではデータのサイロ化やガバナンス不足、特に SAP データの活用障壁が課題となっており、これらを解消して迅速な意思決定を可能にし、「未来予測型経営」への変革を実現することが目的です。 構築にあたり、当初は SAP データ活用テンプレートである「Cortex Framework」を用いたシンプルな構成を検討しましたが、検証の結果、大幅な方針転換を行いました。まず、ガバナンスとセキュリティ強化のため、単一プロジェクトから機能別（DL/DWH/DM）の階層構造へと構成を見直しました。また、Cortex Framework については、同社の業務独自テーブル（カスタムテーブル）への対応率が低く、標準テンプレートの適用範囲が限定的であったため、今回は導入を見送りました。 最終的に、データ連携には「Fivetran」、パイプライン管理には運用負荷が軽く安価な「Dataform」を採用し、自社要件に合ったモデリングを実装する体制を整えました。これにより、組織全体でデータを資産として活用するための強固な土台形成を実現しています。 blog.g-gen.co.jp 2. ライオンのデータマネジメント ライオン株式会社のデータサイエンスグループによる、データ基盤におけるSAP データの利活用に向けた取組み事例の紹介です。 データマネジメントにおいては「アジリティ・ガバナンス・利活用」のバランスを考慮し、現在は利用イメージの共有を優先するため「アジリティ（データ準備の速さ）」を重視しています。アーキテクチャは DataLake、DWH、Datamart の3層構造とし、Datamart は扱いやすさを優先して大福帳形式（OBT）を採用。データカタログの整備はフェーズを見極めて行う方針です。 技術面では、ELT ツールに SQL ベースで処理の依存関係管理ができる「Dataform」、BI ツールに指標定義をコード（LookML）で管理できる「Looker」を採用しました。これら Google Cloud 製品を活用し、外部に依存しすぎない、自社主導での全社的なデータ利活用の実現を目指しています。 blog.g-gen.co.jp 3. ライオンのデータ基盤における分析環境 部署横断的なデータ共有とデータドリブン文化の定着を目的として、データマート層に部門単位の Google Cloud プロジェクトを整備しました。特にデータサイエンティスト向けに、Python を用いた自由な分析と、VPC Service Controls による高いセキュリティレベルを両立するため、Vertex AI Workbench を採用しました。 セキュアなネットワーク構成として、インスタンスに外部 IP アドレスを持たせず、インターネットを経由しない「限定公開の Google アクセス」と restricted.googleapis.com を利用して BigQuery 等へ接続しています。また、JupyterLab を利用するために DNS 設定を追加し、外部サービス（GitHub 等）への通信は Cloud NAT と FQDN によるフィルタリングで厳格に制御しています。 また VPC Service Controls 環境下でのバッチ実行にあたり、VPC Service Controls 配下では Vertex AI 標準のスケジュール実行機能（エグゼキュータ）が非対応であることが判明しました。解決策として、Cloud Scheduler と Cloud Run jobs、OSS の papermill を組み合わせ、Notebook をコンテナ化してバッチ実行するアーキテクチャを確立しました。 今後は生成 AI を活用し、専門知識がない一般ユーザーでも自然言語でデータ抽出やレポート作成が行える環境の整備を目指しています。 blog.g-gen.co.jp G-gen による記事 1. VPC Service Controls の境界の分割設計に関する考察 当記事は、Google Cloudのリソース保護サービス「VPC Service Controls」における「境界（Perimeter）」の設計方針について解説しています。 VPC Service Controls は、APIやデータ操作を特定 IP アドレスからのリクエストに限定するなど、指定領域内でのデータ移動を制御するセキュリティ機能です。保護範囲を定義する「境界」と、異なる境界間を接続する「境界ブリッジ」という構成要素があります。 境界は組織内で増えすぎないように、ある程度の単位にまとめることが推奨されます。境界をプロジェクト等の単位で細分化すると、境界間での API リクエスト発生時に許可ルール（ブリッジや外向き・内向きルール）の設定が複雑化し、運用負荷が肥大化するためです。 「誰がどのプロジェクトにアクセスするか」という制御は IAM の責務とし、VPC Service Controls はあくまで接続元 IP などのコンテキストに基づく多層防御の役割を持たせるのが適切です。 接続元やアクセス制御の要件が明確に異なるユースケースが複数存在する場合は、複数の境界を作成することを検討します。ただしその場合も、Terraform 等による構築自動化で運用負荷を下げる工夫が望まれます。 zenn.dev 2. Security Command Center検出結果のPub/Subエクスポートをフィルタリングする 当記事は、Google Cloud の Security Command Center の検出結果を Pub/Sub へ通知（継続的エクスポート）する際に、特定の条件でフィルタリングする方法とクエリの記述例を紹介しています。 Security Command Center は脆弱性や異常検知を Pub/Sub 経由で外部ツールへリアルタイムに連携できますが、全件ではなく必要な情報のみを通知するために「検出結果クエリ」を利用します。このクエリは独自の文法を持ちますが、コンソール画面のフィルタ操作から自動生成することも可能です。 記事内では、以下の実用的なクエリサンプルが解説されています。 基本フィルタ : ミュート済みを除外し、アクティブな検出結果のみを抽出する記述 特定プロジェクト : project_display_name 属性（実態はプロジェクト ID）を用いた指定方法 特定フォルダ配下 : contains 関数を使用し、リソース階層情報（resource_path）に特定のフォルダ ID が含まれるかを判定する方法 これらを活用することで、運用監視に必要な重要度の高い通知のみを適切にエクスポートすることが可能になります。 zenn.dev 3. Security Command Center検出結果を一時的にミュートする方法 当記事は、Google Cloud の Security Command Center における「動的ミュートルール」の活用方法と設定手順について解説しています。 Security Command Center のミュートルールは、特定の条件に合致するセキュリティ検出結果をコンソール上で非表示にする機能です。中でも「動的ミュートルール」は、指定した期日まで、あるいは構成が一致しなくなるまで一時的に検出結果をミュートできます。 これにより、計画メンテナンス、開発環境での例外的な運用、誤検知への対応、一時的なリスク受容などの場面において、許容済みの検出結果をノイズとして排除し、重要なセキュリティ通知に集中できる環境を構築できます。 記事では「特定期間中の VM インスタンスへのパブリック IP 割り当てを許容する」シナリオを例に、以下の手順で検証を行っています。 動作確認 : ルール設定前に、対象の VM が検出結果として表示されることを確認 設定 : 有効期限や検出クエリ（条件）を指定し、動的ミュートルールを作成 適用確認 : 該当する検出結果がデフォルト一覧から非表示になり、専用フィルタを通した場合のみ閲覧できる状態になることを確認 設定期間が終了すればルールは自動的に無効化されるため、一時的なリスク管理に有効な手段となります。 zenn.dev G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、2021年よりクラウドの導入から最適化までを支援しているGoogle Cloud専業のクラウドインテグレーターです。

G-gen の高宮です。 Google Calendar API と Google Meet REST API を利用し、Google Meet の成果物作成を有効化したカレンダーの予定を作成する方法を解説します。 はじめに 概要 Google Calendar API とは Google Meet REST API とは 免責事項 事前準備 各種 API の有効化 OAuth 同意画面の構成 デスクトップ アプリケーションの認証情報を承認 アーティファクト作成を有効化したイベントと Meet 会議の作成処理 プロジェクトの初期化 ファイル構成 ライブラリのインストール 実装 動作確認 はじめに 概要 Google カレンダーの Web UI では、予定（以下、イベント）を作成後、「Google Meet のビデオ会議を追加」を押下するか、ゲストを追加することで、イベントに Meet 会議の URL を追加することができます。 また、Meet 会議で録画や文字起こしなどの成果物（以下、アーティファクト）作成を、会議が開始されると同時に開始したい場合、ビデオ通話オプションの「会議の記録」タブで、以下の項目にチェックを入れます。これにより、自動記録が有効化されアーティファクトが作成されます。 Gemini でメモを生成する 会議を文字起こし 会議を録画 公式ドキュメントでは、 自動メモ生成 機能を使用するために推奨される会議の長さは、15 分から最大 8 時間までであることが記載されています。 参考 : Google Meet の自動メモ生成 当記事では、Google Calendar API と Google Meet REST API を使用して、API 経由でアーティファクト作成を有効化したイベントと Meet 会議の作成方法を解説します。 Google Calendar API とは Google Calendar API は、HTTP 呼び出しまたは Google クライアント ライブラリを使用してアクセスできる RESTful API です。この API を利用すると、Google カレンダーの Web UI で利用できるほとんどの操作を、自身のプログラムから呼び出すことができます。 参考 : Google Calendar API の概要 以下の記事も参照してください。 blog.g-gen.co.jp Google Meet REST API とは Google Meet REST API は、HTTP 呼び出しまたは Google クライアント ライブラリを使用してアクセスできる RESTful API です。この API を利用すると、自身のプログラムから以下の操作ができます。 Meet 会議のためのスペースの作成、取得、更新 参加者と参加者セッションのリストを取得 アーティファクトを取得 また、Google Workspace Events API を使用して Meet イベントに登録できます。特定の会議スペースまたは特定のユーザーに属するすべてのスペースを登録することで、変更の通知を受け取れます。 参考 : Google Meet REST API の概要 参考 : Google Workspace Events API を使用してイベントに登録する 参考 : Google Meet のイベントに登録する 免責事項 当記事で紹介するプログラムのソースコードは、ご自身の責任のもと、使用、引用、改変、再配布して構いません。 ただし、同ソースコードが原因で発生した不利益やトラブルについては、当社は一切の責任を負いません。 事前準備 各種 API の有効化 使用する Google Cloud プロジェクトで以下の API を有効化します。 Google Calendar API Google Meet REST API gcloud services enable \ calendar-json.googleapis.com \ meet.googleapis.com OAuth 同意画面の構成 Google Cloud コンソールで、ハンバーガーメニューから > Google Auth platform > [ブランディング] に移動します。 「開始」ボタンを押下し、以下の情報を入力し、OAuth 同意画面の設定を構成します。 項目 値 アプリ名 同意を求めるアプリの名前 ユーザーサポートメール 同意に関して問い合わせる際に使用するメールアドレス 対象 内部 メールアドレス 使用しているメールアドレス 参考 : OAuth 同意画面を構成する 参考 : Manage OAuth App Branding デスクトップ アプリケーションの認証情報を承認 Google Cloud コンソールで、ハンバーガーメニューから > Google Auth platform > [クライアント] に移動します。 「クライアントを作成」を押下します。 アプリケーションの種類 で デスクトップアプリ を選択し、デスクトップアプリの名前を入力して「作成」を押下します。 OAuth クライアントの作成が完了したら、「JSON をダウンロード」*を押下し、クライアントシークレットを保存します。 参考 : デスクトップ アプリケーションの認証情報を承認する アーティファクト作成を有効化したイベントと Meet 会議の作成処理 当記事では、Astral 社が開発・提供している、Rust 製のパッケージ・プロジェクト管理ツールの uv を使用します。 参考 : uv Introduction プロジェクトの初期化 以下のコマンドを実行して、Python プロジェクトを初期化、仮想環境を構築します。 uv init < プロジェクト名 > uv venv ファイル構成 ファイル名 説明 client_secret.json 作成したクライアントから発行したクライアントシークレット .python-version uv で使用する Python のバージョン main.py メイン処理 pyproject.toml プロジェクトのパッケージや依存関係の管理 token.json 認証情報（アクセストークンやリフレッシュトークン）を保管 ライブラリのインストール 以下のコマンドを実行して、必要なライブラリをインストールします。 uv add google-api-python-client == 2 . 187 . 0 uv add google-auth-oauthlib == 1 . 2 . 3 実装 main.py に以下のコードを実装します。 本実装では、API の呼び出しは、 google-api-python-client ライブラリを使用して行っています。 import os import datetime from google.auth.transport import requests from google.oauth2.credentials import Credentials from google_auth_oauthlib.flow import InstalledAppFlow from googleapiclient.discovery import build def authorize () -> Credentials: """Calendar API と Meet API を呼び出すために OAuth 2.0 認証を行い、Credentials オブジェクトを返す""" CLIENT_SECRET_FILE = "./client_secret.json" credentials = None if os.path.exists( "token.json" ): credentials = Credentials.from_authorized_user_file( "token.json" ) if credentials is None : flow = InstalledAppFlow.from_client_secrets_file( CLIENT_SECRET_FILE, scopes=[ "https://www.googleapis.com/auth/calendar.events.owned" , "https://www.googleapis.com/auth/meetings.space.created" , ], ) flow.run_local_server(port= 0 ) credentials = flow.credentials if credentials and credentials.expired: credentials.refresh(requests.Request()) if credentials is not None : with open ( "token.json" , "w" ) as f: f.write(credentials.to_json()) return credentials USER_CREDENTIALS = authorize() def create_event (): """Calendar API を使用してイベントを作成する""" # サービスオブジェクトの構築 service = build( "calendar" , "v3" , credentials=USER_CREDENTIALS) # 指定した時刻から1時間の予定を作成 now = datetime.datetime.now() startTime = now.isoformat() endTime = (now + datetime.timedelta(hours= 1 )).isoformat() event = { "summary" : "Google Calendar Meet Test Event" , "start" : { "dateTime" : startTime, "timeZone" : "Asia/Tokyo" , }, "end" : { "dateTime" : endTime, "timeZone" : "Asia/Tokyo" , }, } # 自身のカレンダーに予定を追加 event = service.events().insert(calendarId= "primary" , body=event).execute() return event def create_space (): """Meet API を使用して アーティファクト生成を有効化した Space リソースを作成する""" # google-api-python-client での実装 service = build( "meet" , "v2" , credentials=USER_CREDENTIALS) # 変更する Space リソースのボディ定義 space_body = { "config" : { "artifactConfig" : { "recordingConfig" : { "autoRecordingGeneration" : "ON" , }, "transcriptionConfig" : { "autoTranscriptionGeneration" : "ON" , }, "smartNotesConfig" : { "autoSmartNotesGeneration" : "ON" , }, } } } # Space リソースの作成 return service.spaces().create(body=space_body).execute() def update_event (eventId: str = None , meetUri: str = None ): """Calendar API を使用して既存のイベントに Meet 情報を追加する""" # サービスオブジェクトの構築 service = build( "calendar" , "v3" , credentials=USER_CREDENTIALS) # 予定の更新 event = service.events().get(calendarId= "primary" , eventId=eventId).execute() event[ "conferenceData" ] = { "conferenceSolution" : { "key" : { "type" : "hangoutsMeet" }, }, "entryPoints" : [ { "entryPointType" : "video" , "uri" : meetUri, } ], } updated_event = ( service.events() .update( calendarId= "primary" , eventId=event[ "id" ], body=event, conferenceDataVersion= 1 , ) .execute() ) return updated_event def main (): """メイン処理""" # イベントと Space の作成 event = create_event() print (f "Google Calendar URL {event.get('htmlLink')}" ) space = create_space() meet_uri = space.get( "meetingUri" ) print (f "Meet URL {meet_uri}" ) # イベントに Space を紐付けて更新 event = update_event(eventId=event[ "id" ], meetUri=meet_uri) # カレンダーの更新結果を確認（イベントのURLは変わらず、作成した Meet URL が追加されている） print (f "Update Google Calendar URL {event.get('htmlLink')}" ) print (f "Calendar Meet URL {event['conferenceData']['entryPoints'][0]['uri']}" ) if __name__ == "__main__" : main() authorize 関数は作成した client_secret.json を使用して、OAuth の認証を行います。Google アカウントを選択し認証に成功すると、 token.json が作成され、認証情報（アクセストークンやリフレッシュトークン）が保管されます。 scopes ではアプリから操作できる範囲を限定しているので、実装する処理に応じてスコープを変更する必要があります。 create_event 関数は認証に使用した Google アカウントの Google カレンダーにイベントを作成します。今回実装した処理では、実行した時刻から1時間の予定を作成しています。 create_space 関数はアーティファクト生成を有効化した Meet 会議のスペースを作成しています。設定は JSON 形式で実装します。Google Meet REST API の呼び出しは、 google-apps-meet ライブラリからも可能ですが、本機能は2025年11月時点でベータ版として提供されているので使用していません。 update_event 関数は [2.] で作成したイベントの event["conferenceData"] に、[3.] で作成したスペースの Uri を設定しています。 main 関数が実行されると、イベント、スペースの作成、イベントの更新処理が順番に呼び出されます。 参考 : Google Calendar API のスコープを選択する 参考 : Events 参考 : REST Resource: spaces 動作確認 ターミナルで uv run main.py を実行することで、OAuth の同意画面が表示されます。Google アカウントを選択し認証すると、認証された Google アカウントの Google カレンダーにアーティファクト作成が有効化された Meet 会議を含むイベントが登録されます。 登録されたイベントの Meet 会議に参加すると、アーティファクト作成が自動で開始されることが確認できます。 高宮 怜 (記事一覧) クラウドソリューション部クラウドエクスプローラ課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya

G-gen の堂原です。本記事では、Google Cloud の 共有 VPC （Shared VPC）を設定または利用する際に必要な IAM 権限について解説します。 はじめに ホストプロジェクト有効化時の IAM 権限 必要な IAM ロール 権限不足時のエラーメッセージ 共有 VPC 利用時の IAM 権限 必要な IAM ロール コンソールでの設定 ユースケース別の具体例 Compute Engine VM の起動 Cloud Run サービスの Egress 接続 無効化時の IAM 権限に関する挙動 はじめに 共有 VPC は、複数のプロジェクト間で VPC ネットワークを共有できる機能です。ネットワークの管理を行う ホストプロジェクト と、そのネットワークリソースを利用する サービスプロジェクト を定めて管理します。 参考 : 共有 VPC 共有 VPC については、以下の記事も参照してください。 blog.g-gen.co.jp 共有 VPC の有効化時や利用時には、組織、フォルダ、ホストプロジェクト上での適切な IAM 権限設定が必要です。 当記事では、共有 VPC の有効化時と利用時、それぞれの IAM 権限設定と、無効化時の IAM 権限設定の挙動について解説します。 ホストプロジェクト有効化時の IAM 権限 必要な IAM ロール Google Cloud のコンソール画面にて、プロジェクトを共有 VPC の「ホストプロジェクト」として有効化する操作を行う際は、操作するプリンシパル（Google アカウントやサービスアカウント）に対して、以下のとおりロールを付与する必要があります。 ロールを付与するリソース ロール名 組織またはフォルダ Compute Shared VPC 管理者（ roles/compute.xpnAdmin ） ホストプロジェクト Project IAM 管理者（ roles/resourcemanager.projectIamAdmin ） ※ resourcemanager.projects.setIamPolicy 権限があれば他のロールでも可能 ただし、gcloud コマンドを用いて有効化する際は「Project IAM 管理者」ロールは必要ありません。コンソールで操作する場合のみ、「Project IAM 管理者」ロールが無いと設定画面に遷移する際にエラーメッセージが表示されます。 重要な点は、「Compute Shared VPC 管理者」ロールは、ホストプロジェクト自身ではなく、その 上位の組織またはフォルダレベル で付与する必要があるという点です。 参考 : 共有 VPC - 管理者と IAM 権限不足時のエラーメッセージ 上記の権限が不足している場合、コンソールや gcloud コマンドでホストプロジェクトを有効化しようとすると、以下のようなエラーメッセージが表示されます。 Required 'compute.organizations.enableXpnHost' permission for 'projects/xxx' または プロジェクト「xxx」の 'compute.subnetworks.setIamPolicy', 'resourcemanager.projects.setIamPolicy' 権限がありません。 これらのメッセージは、一見すると対象のプロジェクトレベルでの権限付与を促しているように見えます。 しかし、前述のとおり、「Compute Shared VPC 管理者」ロールは、ホストプロジェクト自身ではなく、その 上位の組織またはフォルダレベル で付与する必要がある点に注意してください。 共有 VPC 利用時の IAM 権限 必要な IAM ロール サービスプロジェクトにおいて、共有されたサブネットを利用するためには、操作を行うプリンシパル（Google アカウントやサービスアカウント）が、ホストプロジェクトまたは該当サブネットに対して「Compute ネットワーク ユーザー（ roles/compute.networkUser ）」ロールを有している必要があります。 ホストプロジェクトレベルで付与した場合、そのホストプロジェクト上のすべてのサブネットを利用することができます。 参考 : 共有 VPC をプロビジョニングする - 共有 VPC を使用する コンソールでの設定 共有 VPC コンソール画面では、ホストプロジェクトの初期有効化時に、プリンシパルに対して「Compute ネットワーク ユーザー」ロールを付与するための設定が用意されています。 「役割別のユーザーの選択」画面では、どのプリンシパルに「Compute ネットワーク ユーザー」ロールを付与するかを決定します。例えば、各サービスプロジェクトの「Compute インスタンス管理者」ロールや「オーナー」ロールを持つプリンシパルなど、既にサービスプロジェクトに対して特定のロールを持つプリンシパルに対して、「Compute ネットワーク ユーザー」ロールを付与することができます。 役割別のユーザーの選択 「アクセスを許可」画面では、上記で選択したプリンシパルに対し、プロジェクトレベルで「Compute ネットワーク ユーザー」ロールを付与するか（すなわち、ホストプロジェクト上のすべてのサブネットが利用可能）、あるいは個々のサブネットレベルで付与するかを選択します。 アクセスを許可 ユースケース別の具体例 Compute Engine VM の起動 サービスプロジェクトにおいて共有 VPC ネットワーク上に Compute Engine VM を起動するには、 操作者の Google アカウント が、ホストプロジェクトの該当サブネットへの「Compute ネットワーク ユーザー」ロールを持っている必要があります。 Cloud Run サービスの Egress 接続 サービスプロジェクト上の Cloud Run サービスから、ホストプロジェクト上のサブネットに Direct VPC Egress などで接続するケースです。 この場合、 「Cloud Run サービス エージェント」 に対して、ホストプロジェクトの該当サブネットへの「Compute ネットワーク ユーザー」ロールを付与する必要があります。 Cloud Run サービスエージェントのメールアドレスは、以下の形式です。 service-{サービスプロジェクト番号}@serverless-robot-prod.iam.gserviceaccount.com 参考 : ダイレクト VPC 下り（外向き）と共有 VPC ネットワーク - IAM 権限を設定する なお、サービスエージェントとは、Google Cloud サービスが使用する特殊なサービスアカウントのことです。以下の記事も参照してください。 参考 : サービスエージェントとは何か - G-gen Tech Blog 無効化時の IAM 権限に関する挙動 Google Cloud コンソールからホストプロジェクトの共有 VPC 設定を無効化すると、ホストプロジェクトにおいて、プロジェクトレベル、またはサブネットごとに設定されているすべての「Compute ネットワーク ユーザー」ロール設定が自動的に削除されます。 この自動的な削除処理は Google Cloud コンソールからの操作時のみ行われます。一方で、gcloud コマンド（ gcloud compute shared-vpc disable ）で無効化した場合は、「Compute ネットワーク ユーザー」ロール設定は自動的には削除されず、残ります。 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の堂原です。当記事では、Ingress 設定が「内部」となっている Cloud Run サービス に対し、異なる Google Cloud プロジェクトから VPC ネットワークを経由して プライベートアクセス する方法について解説します。 はじめに Cloud Run サービスの Ingress 設定 異なるプロジェクトからのアクセス アクセス先プロジェクトがホストプロジェクトの共有 VPC を経由する 構成 留意点 アクセス先 Cloud Run が共有 VPC へ Egress 接続する 構成 留意点 VPC Service Controls を利用する 構成 留意点 内部ロードバランサを経由する はじめに Cloud Run サービスの Ingress 設定 Cloud Run サービスの Ingress（上り）設定は、サービスにアクセス（リクエスト）できるネットワークトラフィックを制御します。 この設定を「 内部 」にすると、インターネットからの直接的なアクセスをブロックし、同じ Google Cloud プロジェクト内の VPC ネットワークや、特定の Google Cloud サービス（Cloud Scheduler や Cloud Tasks など）からのアクセスのみに制限できます。 詳しくは以下のブログで紹介しています。 blog.g-gen.co.jp 異なるプロジェクトからのアクセス Ingress 設定が「内部」になっている Cloud Run サービスにおいては、同一の Google Cloud プロジェクト（以後、「プロジェクト」）の VPC ネットワークからであればアクセス可能ですが、異なるプロジェクトからアクセスするには、追加の構成が必要です。 このプロジェクト間プライベートアクセスの実現方法として、次のようなパターンがあります。 アクセス先プロジェクトがホストプロジェクトの共有 VPC を経由する アクセス先 Cloud Run が共有 VPC へ Egress 接続する VPC Service Controls を利用する 内部ロードバランサを経由する なお当記事では、「アクセス先プロジェクト」はアクセス先の Cloud Run サービスが属するプロジェクトを、「アクセス元プロジェクト」はアクセス元のリソース（Compute Engine VM など）が属するプロジェクトを指します。 当記事では、各パターンについて紹介します。 参考 : プライベート ネットワークと Cloud Run  |  Google Cloud アクセス先プロジェクトがホストプロジェクトの共有 VPC を経由する 構成 共有 VPC 経由で Cloud Run サービスへリクエストする場合で、アクセス 先 プロジェクトが 共有 VPC の ホストプロジェクト である場合は、Cloud Run サービスからみて「内部」アクセスと判定されます。 構成の概要は以下のとおりです。 アクセス先プロジェクトで共有 VPC を有効化し、ホストプロジェクトとする アクセス元プロジェクトをサービスプロジェクトとして、サブネットを共有する 上記の構成により、アクセス元プロジェクトに共有されたサブネット上の Compute Engine VM 等から、Cloud Run サービスの URL に HTTP リクエストをすることが可能です。アクセス元リソースが Cloud Run サービスや Cloud Run ジョブの場合、自プロジェクトの共有されたサブネットに Egress 接続することで、アクセスすることができます。 留意点 本構成においては以下のような点に気をつける必要があります。 アクセス 先 プロジェクトが共有 VPC ホストプロジェクト ではない 場合は、後述の Egress 接続設定が必要 アクセス元リソースが外部 IP アドレスを有していない場合、サブネットで限定公開の Google アクセス（Private Google Access）を有効化する、または Cloud NAT を利用する必要がある。外部 IP アドレスを有している場合は共に不要 アクセス先 Cloud Run が共有 VPC へ Egress 接続する 構成 アクセス先 の Cloud Run サービスが、 Direct VPC Egress または サーバーレス VPC アクセス を用いて共有 VPC に Egress 接続設定をしている場合、その共有 VPC は Cloud Run サービスからみて「内部」と判定されます。 構成の概要は以下のとおりです。 任意のプロジェクト（アクセス元でもアクセス先でもない、第三のプロジェクトでも可）をホストプロジェクトとして共有 VPC を設定する アクセス元プロジェクトとアクセス先プロジェクトの両方をサービスプロジェクトとして、ホストプロジェクトにアタッチし、サブネットを共有する アクセス先の Cloud Run サービスで、共有されたサブネットへの Egress 接続（Direct VPC Egress またはサーバーレス VPC アクセス）を構成する 上記の構成で、アクセス元プロジェクト上で、共有されたサブネットから Cloud Run サービスの URL に HTTP リクエストをすることが可能となります。 留意点 本構成においては以下のような点に気をつける必要があります。 アクセス元プロジェクトをホストプロジェクトとすることも可能 アクセス先 Cloud Run サービスの Egress 接続の「トラフィックルーティング」設定は、「プライベート IP へのリクエストのみを VPC にルーティングする」でも本構成は成立する アクセス元リソースが外部 IP アドレスを有していない場合、サブネットで限定公開の Google アクセス（Private Google Access）を有効化する、または Cloud NAT を利用する必要がある。外部 IP アドレスを有している場合は共に不要 VPC Service Controls を利用する 構成 アクセス先プロジェクトの Cloud Run Admin API を保護する VPC Service Controls 境界に含まれている VPC ネットワークは、Cloud Run サービスからみて「内部」と判定されます。 構成の概要は以下のとおりです。 VPC Service Controls の境界を作成する 境界に、アクセス先プロジェクトと、アクセス元プロジェクトの VPC ネットワークを含める（アクセス元プロジェクトを含める必要はない） 境界で保護するサービスに Cloud Run Admin API（ run.googleapis.com ）を含める アクセス元プロジェクトのリソースは、境界内の VPC ネットワークを経由して Cloud Run サービスにアクセスする 上記の構成で、VPC Service Controls に含まれている VPC ネットワーク上のサブネットから Cloud Run サービスの URL に HTTP リクエストをすることが可能となります。 留意点 本構成においては以下のような点に気をつける必要があります。 本構成において、VPC ネットワークは共有 VPC である必要はない VPC Service Controls の設定について 「保護するリソース」にアクセス元プロジェクトを含める必要はない 「VPC のアクセス可能なサービス」において、「CLoud Run Admin API」を許可する必要がある アクセス元リソースが外部 IP アドレスを有していない場合、サブネットで限定公開の Google アクセス（Private Google Access）を有効化する、または Cloud NAT を利用する必要がある。外部 IP アドレスを有している場合は共に不要 内部ロードバランサを経由する Cloud Load Balancing の一種である 内部アプリケーションロードバランサ のバックエンドとして Cloud Run サービスを登録し、アクセス元リソースからそのロードバランサにアクセスするという構成です。 詳しくは以下の記事で紹介しています。 blog.g-gen.co.jp 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の杉村です。Google が提供できる生成 AI チャットサービスである Gemini アプリ では、Google スライドを生成できます。当記事では、このスライド生成機能について紹介します。 Gemini アプリによるスライド生成 プロンプト入力と Canvas の使用 スライドの生成 Google スライドへのエクスポート 資料を引用した生成 Gemini アプリによるスライド生成 Google が提供できる生成 AI チャットサービスである Gemini アプリ では、 Canvas 機能を使って Google スライドを生成できます。 Canvas 機能とは、生成 AI との自然言語を使った指示により、資料や Web サイト（HTML）、Web アプリ（JavaScript）、スライドや PDF などを作成したり、対話を通じて成果物の微修正を行うことができる機能です。 参考 : Canvas でドキュメントやアプリなどを作成する - Gemini アプリ ヘルプ プロンプト入力と Canvas の使用 Gemini アプリ（ https://gemini.google.com/ ）へアクセスし、プロンプトを入力します。 また「ツール」をクリックして、 Canvas をクリックして有効化します。その後、Enter キーを押下します。 プロンプトの入力 今回のプロンプトは以下のようにしました。 日本のクラウドインテグレーター、株式会社G-genのエンジニア採用向けの資料を作りたいです。アウトプットは Google スライドとしてください。 インターネット上から、G-gen のエンジニア採用関連の情報を検索して資料を作って下さい。 スライドの生成 3分ほど待つと、画面右側の Canvas エリアにスライドが生成されました。 スライドの表紙 プロンプトでの指示通り、インターネットで公開されている情報からスライドが生成されています。 スライドの中身（1） スライドの中身（2） スライドの中身（3） 最後のページには、画像の 引用元 が表示されています。資料を商用利用したりインターネットに公開する前に、利用規約を確認することが望ましいでしょう。 画像の引用元 Google スライドへのエクスポート Canvas エリアの右上の「スライドにエクスポート」ボタンを押下すると、資料が Google ドライブに Google スライドとしてエクスポート されます。 Google スライドへのエクスポート なお「スライドにエクスポート」ボタンの右側のダウンロードボタンを押すと、 PDF としてのダウンロード も可能です。 資料を引用した生成 スライドの生成にあたり、 既存の資料 を参考として添付することができます。Gemini は、添付した資料を参考にして新しい資料を作成します。 既存資料の追加 今回のプロンプトは、以下のようにしました。 日本のクラウドインテグレーター、株式会社G-genのエンジニア採用向けの資料を作りたいです。アウトプットは Google スライドとしてください。 添付した資料を使って、新しい資料を生成してください。また、G-gen のエンジニア採用関連の情報をインターネット上から検索して追加の参考資料としてください。 また、添付資料として、G-gen の Web 採用説明会の投影スライドを追加しました。資料はパソコンからアップロードすることも、Google ドライブ上のファイルを指定することもできます。 出力は、以下のようになりました。今回生成された資料には、アップロードした既存資料の情報が反映されています。 スライドの中身（4） スライドの中身（5） スライドの中身（6） 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

当記事は、ライオン株式会社様と株式会社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 開発ツールである Gemini Enterprise Agent Platform （旧称 Vertex AI ）と Google AI Studio の違いや、それぞれのユースケースについて解説します。 概要 Agent Platform と Google AI Studio 差異の一覧 選定の基本的な考え方 セキュリティと統制 Agent Platform の場合 Google AI Studio の場合 Gemini API の不正使用 割り当てとレート制限 概要 Agent Platform の場合 Google AI Studio の場合 Google Cloud プロダクトとの連携 Agent Platform の場合 Google AI Studio の場合 データの保護 Agent Platform の場合 Google AI Studio の場合 サポート Agent Platform の場合 Google AI Studio の場合 移行 Google AI Studio から Agent Platform への移行 Google AI Studio の使用を禁止する Agent Platform でモデルを気軽に試す 概要 Agent Platform と Google AI Studio Gemini Enterprise Agent Platform （略称は Agent Platform 。旧称は Vertex AI ）は、Google Cloud が提供するフルマネージドの機械学習プラットフォームです。データの準備からモデルのトレーニング、デプロイ、管理まで、ML 開発のライフサイクル全体をサポートします。最近では特に生成 AI 関連機能が充実しています。企業における利用や研究者、個人開発に至るまで、多様なユースケースに対応できます。 Agent Platform では、API 経由で様々なモデルを呼び出せるほか、Web UI 上でパラメータを指定してモデルにリクエストを投入できる Agent Studio 画面も用意されています。 参考 : Agent Platform の概要 参考 : Agent Studio の概要 Gemini Enterprise Agent Platform Google AI Studio は、Google の最新の生成 AI モデルである Gemini をはじめとする生成 AI モデルを、Web ブラウザから手軽に試すことができる開発ツールです。主に個人または小規模開発者を対象としています。また、無料である程度の機能が試用できることも魅力の1つです。このサービスの API 経由で Gemini を呼び出す機能のことを単に Gemini API と呼称することもあります。 Google AI Studio は Agent Platform と同様、API 経由で様々なモデルを呼び出せるほか、Web UI 上でパラメータを指定してモデルにリクエストを投入できます。 参考 : Google AI Studio のクイックスタート Google AI Studio 差異の一覧 Agent Platform と Google AI Studio の主な違いを一覧表にまとめます。 項目 Google AI Studio Agent Platform 提供形態 Google サービス Google Cloud プロダクト ターゲット 個人開発者、研究者、学生 企業、官公庁、研究者 主な用途 プロトタイピング、学習、アイデア検証 本番環境のアプリケーション開発、その他の業務利用 実行環境 Web ベースの UI Google Cloud 料金 無料枠あり、有料ティアに引き上げ可能 従量課金 データ保護 無料枠ではデータがサービス改善に使われる可能性あり データは分離・保護され、モデル学習には利用されない セキュリティ API キー IAM、組織ポリシー、VPC SC、サービスアカウントなど高度なセキュリティ 主な機能 ・Gemini モデルの試用 ・プロンプトの作成と調整 ・API キーの発行 左記に加えて以下 ・AI エージェント構築 ・MLOps ・IAM、VPC SC 等との連携 ・監査ログ (Cloud Audit Logs) ・高度なモデルチューニング 選定の基本的な考え方 Agent Platform と Google AI Studio のどちらを使用したほうがよいかの原則的な考えかたとしては、以下のようなものが挙げられます。 Agent Platform は、企業、官公庁、研究者など幅広い利用者が想定されている Google AI Studio は、個人開発者、研究者、学生が想定されている 基本的には、「 プロトタイピングや学習は Google AI Studio 」「 企業等における本格的な開発や、本番利用は Agent Platform 」と覚えておけば、大きく間違うことはないでしょう。 その理由として、当記事で以下に挙げるようなことが考えられます。 セキュリティと統制 Agent Platform の場合 Agent Platform は Google Cloud と統合 されているため、詳細なアクセス制御や高度なセキュリティが使用できます。API キーを発行せずとも、Cloud Run 等のプラットフォームで動作するアプリケーションであれば、サービスアカウントを利用することでセキュアに API 呼び出しが可能です。また IAM によるアクセス制御が可能なため、ローカル開発においても、Google アカウント認証により手軽に API 呼び出しが可能です。 参考 : アクセス制御 - Google Cloud 参考 : アプリケーションのデフォルト認証情報を構成する - Google Cloud Agent Platform は 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 を利用する際には、Agent Platform を選択することが推奨されます。 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 でプロトタイピングを行い、本格的な開発時は Agent Platform に移行する、といった選択肢も考えられます。 参考 : Gemini API キーを使用する ‐ Gemini API Gemini API の不正使用 Google AI Studio と Gemini API に関連して、Gemini API の不正使用により意図しない多額の請求が発生する事象が観測されています。詳細は以下の記事を参照してください。 blog.g-gen.co.jp 割り当てとレート制限 概要 独自開発のアプリケーションから Gemini リクエストを送るには、Agent Platform を使う場合と、Google AI Studio の API キーを使う場合の2つの選択肢があります。 いずれの場合でも、一定の時間内で送信可能なリクエスト数に上限があります。 このようなリクエスト数制限は、Agent Platform では 割り当て （Quota）と呼ばれ、Google AI Studio の API キーの場合は レート制限 と呼ばれます。 Agent Platform の場合 Agent Platform 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 の Agent Platform API の Provisioned Throughput を使うことが推奨されます。 詳細は以下のドキュメントを参照してください。 参考 : レート制限 Google Cloud プロダクトとの連携 Agent Platform の場合 Agent Platform は Google Cloud プロダクトであるため、BigQuery などの他の Google Cloud プロダクトとの連携も容易です。 BigQuery ML では、Agent Platform のリモートモデルを呼び出し、SQL で生成 AI モデル等の機械学習モデルを呼び出し、BigQuery データセット上のデータを使った推論やトレーニングが可能です。 Compute Engine 、 Cloud Run 、 Google Kubernetes Engine（GKE） 等のコンピューティングプラットフォームにおいては、インスタンス等にサービスアカウント（人ではなくプログラムが使うアカウント）をアタッチすることで、API キー等を発行しなくても Agent Platform の API を呼び出すことができます。これにより、セキュアに Gemini 等のモデルを API 経由で呼び出すことができます。 Agent Platform の1機能である Agent Runtime は、AI エージェントに特化したホスティングサービスです。フルマネージドであり、インフラの管理は必要ありません。 セキュリティの観点においても、 Cloud Armor と呼ばれる生成 AI 向けの防御サービスを利用したり、 VPC Service Controls という API 保護サービスを利用することで、多段での防御やアクセス制御が可能です。Agent Platform の API 自体へのアクセス制御も、 Identity and Access Management （IAM）と呼ばれる仕組みにより、詳細に行うことができます。Google アカウントにアクセス許可を与えたり、組織の Google グループ単位でアクセス制御を行うことが可能です。 Google AI Studio の場合 一方で Google AI Studio には、これらの連携は用意されていません。 Google Cloud プロダクトと連携しようと考える場合、Google AI Studio の API 呼び出しは API キーで認証し、Google Cloud プロダクトの呼び出しは IAM で認証する、というように、異なる認証機構をまたいだ設計が必要になります。 データの保護 Agent Platform の場合 Agent Platform は企業や官公庁、研究機関での利用が想定されていることから、データの保護が規約で定義されています。ユーザーが入力したプロンプトやデータ、また AI モデルが生成したレスポンスについては、Google がサービス改善に利用したり、モデルの再トレーニングに使用することはありません。 参考 : Gemini Enterprise Agent Platform とデータの保持ゼロ - Google Cloud 参考 : Cloud Data Processing Addendum (Customers) - Google Cloud Google AI Studio の場合 一方で Google AI Studio の場合、無料枠を利用する場合は、Google によって入出力データがサービス改善に利用されたり、モデルの再トレーニングに使用される場合があります。利用規約にはこれが明記されており、また「本無料サービスには、プライベート情報、機密情報、または個人情報を送信しないでください。」と記述されています。 参考 : Gemini API 追加利用規約 ただし Google AI Studio で有料版の API キーを使用する場合、上記規約でいうところの「有料サービス」の扱いになり、入出力データがプロダクトの改善に使用されることはない、としています。 サポート Agent Platform の場合 Agent Platform は Google Cloud プロダクトであり、技術サポート窓口である カスタマーケア のサポート対象です。また Google Cloud の再販パートナーの技術サポートサービスにおいても、サポート対象となる可能性が高いといえます。当社 G-gen の技術サポート窓口の場合、サポート対象です。 参考 : Google Cloud カスタマーケア Google AI Studio の場合 一方の Google AI Studio には、公式のサポートサービスは存在していません。再販パートナーの技術サポートサービスにおいては、各社の裁量によるところになります。当社 G-gen の技術サポート窓口では、Google AI Studio はサポート対象ではありません。 移行 Google AI Studio から Agent Platform への移行 Google AI Studio の API キーを発行する際には Google Cloud プロジェクトが必要であり、また有償版 API の課金は、Google Cloud 請求先アカウントにひも付きます。つまりこの時点で、Google Cloud のりように必要な要素は整っているといえます。 Google AI Studio から Agent Platform に移行するための手順を示した公式ドキュメントも公開されています。 参考 : Google AI Studio から Gemini Enterprise Agent Platform に移行する Google AI Studio の使用を禁止する Google Workspace（Cloud Identity）の管理者は、組織で管理している Google アカウントに対して、Google AI Studio の使用を禁止することができます。 以下の公式ドキュメントに従い、「AI Studio」を無効化することで、配下の Google アカウントは Google AI Studio を使用できなくなります。 参考 : その他の Google サービスを有効または無効にする - Google Workspace 管理者 ヘルプ これにより、組織の開発者が無償版の API キーを発行して、組織の機密情報や顧客情報、個人情報等を Google に送信してしまうことを未然に防ぐことができます。 Agent Platform でモデルを気軽に試す Google AI Studio を使わなくても、Agent Platform には手軽に最新の生成 AI モデルを試すための Web UI が用意されています。 Agent Studio は、Google Cloud コンソール（Web UI）上で生成 AI モデルを試用したり、プロンプトチューニングを行ったり、プロンプトを保存・比較する機能を備えた画面です。 細かいパラメータの調整や、Cloud Run にサンプルアプリケーションを簡単にデプロイする機能も備えています。 参考 : クイックスタート: Agent Studio を使用して Gemini にテキスト プロンプトを送信する - Google Cloud 参考 : Agent Studio の機能 - Google Cloud Agent 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 の実行フロー例 インテグレーション インテグレーションとは インテグレーションの種類 インスタンス Playbooks の管理 ダッシュボード 概要 ネイティブダッシュボード レガシーダッシュボード SIEM ダッシュボード SOAR ダッシュボード SOAR レポート Google SecOps MCP server Agentic SOC（AI エージェントによるセキュリティ運用） 概要 Security Tokens トリアージと調査エージェント（TIN） エージェントの自動化（Agentic Automation） 検出エンジニアリングエージェント 脅威ハンティングエージェント 認定資格 関連記事 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/年）が軸。AI エージェントは別途トークンが必要 Gemini による運用支援 自然言語での質問やアウトプットの生成が可能で、専門知識がなくても効率的な運用が可能 脅威インテリジェンス Google Threat Intelligence に加え Mandiant や VirusTotal の知見を活用し、最新の攻撃や Indicators of Compromise（IoC、侵害の兆候） を迅速に検知 SOAR 機能 アラート管理から Playbooks による自動対応まで一貫して提供し、SOC 運用を効率化 主な機能 Google SecOps の主な機能は以下の通りです 機能 説明 Investigation （調査） ログやエンティティ（ユーザー・端末・IPなどの対象）を検索し、不審な挙動を調べる Detection （検知） ルール、IoC、UEBA（行動分析）に基づきアラートを生成 Cases （管理） 複数のアラートを「ケース」として集約管理（＝インシデント対応の単位） Response （対応） Playbooks でアラート通知後の対応を自動化 Dashboards （可視化） 検知状況をダッシュボードやレポートで把握 Content Hub （拡張） 検知ルール、インテグレーション、Playbooks などのコンテンツを追加拡張 API （設定） UI に加えプログラマブルな設定、自動化、外部連携が可能 エディションと料金体系 Google SecOps には Standard、Enterprise、Enterprise Plus の3エディションがあり、いずれのエディションにおいても 取り込んだログデータ量 （GB単位/年）が基本的な料金軸です。ただし、各種 AI エージェントの利用には、取り込みログ量とは別に Security Tokens （セキュリティトークン）が必要です。詳細は後述の Agentic SOC の章をご確認ください。 Standard エディションでは Gemini AI や Google Threat Intelligence が使用できません。また、AI エージェント（Agentic SOC）についても同様です。そのため、 基本的には 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 – 〇 〇 トリアージと調査エージェント（TIN） – 〇 〇 検出エンジニアリングエージェント – 〇 〇 脅威ハンティングエージェント – – 〇 Mandiant / VirusTotal との統合 – – 〇 Applied Threat Intelligence – – 〇 BigQuery UDM ストレージ – – 〇 なお、脅威ハンティングエージェントは、公開プレビュー期間中は Enterprise Plus のみで利用可能とされています。 Google SecOps は Google Cloud と統合されていますが、オーダー方法などが他の Google Cloud プロダクトとは異なる特殊なプロダクトです。オーダーや料金等に関する詳細については、Google または販売パートナーのセールス担当者にお問い合わせください。 参考： Pricing 用語と機能 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 についての詳細は、以下の記事も参照してください。 参考 : Security Command Centerを徹底解説。Google Cloud(GCP)の脆弱性を自動検知 - G-gen Tech Blog SCC Enterprise SCC の Enterprise ティアを利用している場合、Google SecOps 機能を SCC の拡張機能として利用することもできますが、各種機能に通常の SecOps とは異なる上限が設定されています。 機能 上限 ログ取り込み Curated Detections で対応可能なサービスのログに限定 Curated Detections Cloud Threats のうち、Google Cloud、AWS、Azure に関する脅威検出に限定 YARA-L ルール 最大20個の単一イベントルールに限定 SOAR Curated Detections で対応可能なサービスならびに一部の ITSM、コミュニケーションツールとの統合に限定 Gemini 自然言語検索とケース調査の概要に限定 ログ保持期間 3ヶ月（通常の SecOps は12ヶ月） なお、SCC Enterprise ティアは2027年5月21日に EOL の予定です。 参考 : Security Command Center release notes Mandiant と Google Threat Intelligence（GTI） Google は独自の脅威インテリジェンスデータベースとして Google Threat Intelligence （GTI）を運用しています。Google SecOps はこの GTI と連携し、組織内に存在する既知の脅威をリアルタイムで検知します。 参考 : Actionable threat intelligence at Google scale 一方で攻撃側も日々新しい手法やツールを考案し、既存のナレッジで検出できない攻撃を仕掛けてきます。これに対応するために、Google のセキュリティチームが世界中のネットワークを監視しています。 Mandiant サイバーセキュリティコンサルティング もそのうちの一つであり、GTI の運用だけでなく、顧客に対するセキュリティコンサルティングサービスを提供しています。 参考 : Mandiant Cybersecurity Consulting VirusTotal VirusTotal は、指定されたファイルや URL がマルウェアで汚染されていないかを確認することができるウェブサービスです。また、セキュリティ研究者向けの機能や、エンタープライズ向けの有償サービスも提供しています。 Google SecOps は VirusTotal と連携しており、SecOps が発見した IoC を VirusTotal で確認・可視化することなどが可能です。 参考 : VirusTotal 参考 : View VirusTotal information Gemini Google SecOps には、Google の生成 AI「 Gemini 」が統合されており、セキュリティ運用にかかる負担を大幅に軽減できます。 後述する検索クエリの作成、脅威検出ルールや Playbooks の設計、アラートの根本原因調査など、専門知識に依存する作業を自然言語で支援し、 人手での試行錯誤やそれに伴う工数を削減 します。 参考 : Gemini in Google SecOps overview データ取り込み（SIEM） 概要 Google SecOps は、Google Cloud や Google Workspace に加え、 数多くの外部製品との連携が可能 です。 そのため、分散していたログ管理を Google SecOps に集約し、単一のビューで相関的な分析と脅威検知ができます。 参考 : Data ingestion overview 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 アクティビティログ 直接取り込みによるログ連携はシンプルな操作で完結します。詳細は以下をご確認ください。 参考 : Ingest Google Cloud logs 参考 : Collect Google Workspace logs データフィード 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 経由でログデータを取得 参考 : Data feeds overview Cloud Run functions データフィードに対応していない SaaS のログデータの取り込みや、取り込み前にログデータを整形・フィルタリングしたい場合、Cloud Run functions を使用してログデータを取り込めます。 Box や Trend Micro など、一部の SaaS については Google が作成した Python スクリプト（Cloud Run functions でデプロイする前提のコード）が提供されています。 Pub/Sub を除くすべてのスクリプトは、ソースデバイスから定期的にデータを収集するように実装されています。 参考 : Ingest logs with Cloud Run functions Bindplane 概要 Linux や Windows といったクラウドやオンプレミス上のサーバーのログやテレメトリデータの取り込みには、 Bindplane と呼ばれる収集エージェントが使用できます。 Bindplane では収集したデータを正規化したり、正規表現に一致するログを削除したりするなどのエンリッチメントが可能で、単なる収集エージェントというよりは、 テレメトリパイプライン として位置づけられています。 参考 : Deploy the Bindplane agent for collection エディション Google SecOps では Bindplane（Google エディション）が無料で利用できます。 さらに、Enterprise Plus エディションを契約しているの場合、上位互換にあたる Bindplane Enterprise（Google エディション）も無料で利用できます。 参考 : Bindplane's Google editions 以下の用途で Bindplane を使用する場合、Bindplane Enterprise が推奨されます。 大規模環境でのログデータ取り込み 正規表現以外の高度なフィルタリング機能を使用したログデータ加工 個人情報（PII）の秘匿化 構成要素 Bindplane は以下の3つに分類されます。 コンポーネント 役割 Server Bindplane の管理サーバーで、Controller（エージェント）の集中管理を担う Collector 旧称 Bindplane Agent、ログやテレメトリデータの転送を行うエージェント Gateway セキュリティ上の都合で直接データ転送ができない Collector に代わってデータを中継・転送するゲートウェイサーバー 参考 : Firewall your gateway collectors Bindplane Server Bindplane Server は Bindplane の管理コンソールです。 Bindplane を統括的に運用・管理するコンポーネントで、複数の Collector や Gateway の運用を一元管理するためには必須です。 主な機能 説明 集中管理 Collector や Gateway の起動/停止/再起動といった管理タスクの実行やステータス表示 モニタリング Collector や Gateway の CPU 使用率、メモリ使用率、スループットなどの指標を追跡 アラート通知 Collector や Gateway がダウンした場合や指標のしきい値を超えた場合など、重要なイベントのアラートと通知 構成管理 Collector や Gateway の構成ファイルの編集、環境変数の設定などを適用 管理画面 Web UI からの操作・設定変更を提供 Collector や Gateway のデプロイパターン Bindplane には、環境や用途に応じて、いくつかのデプロイパターンが用意されています。 参考 : Bindplane collector architecture パターン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 Gateway 経由でログを転送する方式 例：セキュリティ上の都合で直接データ転送ができない環境において、Bindplane Gateway を介して Google にログを送信 Forwarders（非推奨） Bindplane の他にも Forwarders と呼ばれる Google SecOps 純正の収集エージェントがありますが、対応するフォーマットに限りがあるなど、Bindplane と比べると性能面で劣ります。 Forwarders は2027年1月に提供が終了する予定です。これらのことから Forwarders は非推奨であり、今後、収集エージェントを利用する場合は Bindplane が推奨されます。 参考 : Install and configure the forwarder 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 サポートされているログタイプのリストを取得 参考 : Ingest data with the 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 による分析や脅威検知に利用できるようになります。 以下はベンダーが異なる Firewall 製品のログを 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 は次の要素で構成されます。 要素 概要 トリガー （Triggers） Playbooks を起動する条件。特定のアラートやイベントの発生時、またはスケジュールを契機に自動実行される アクション （Actions） 実行される処理。例えば「VirusTotal への照会」、「Jira チケット起票」、「ユーザーの無効化」など フロー （Flows） 条件分岐や承認を制御する仕組み。自動判断やアナリストの入力を挟みながら次の処理を決定する ブロック （Blocks） 再利用可能な処理単位。複数の Playbooks で共通利用できる部品化されたモジュール ループ （Loops） 配列（リスト）に対する繰り返し処理。for each として、アラート内のエンティティ群やリスト項目を1件ずつ反復し、各項目に対して同じアクションを実行する AI エージェント （AI Agents） AI エージェントを組み込み、自律的な分析・判断を行わせるステップ。 Triage and Investigation Agent （TIN）で、アラートを自律調査して True/False Positive の判定・信頼度スコアを返し、その結果を後続の分岐に利用できる 参考 : Playbook and automation overview 参考 : Embed AI agents in playbooks Playbooks の実行フロー例 前述の構成要素を組み合わせた、典型的な Playbooks の実行フローは以下のとおりです。 SIEM が検知したアラートを起点に、対象の判定、是正、通知・記録、ケースのクローズまでを一連のワークフローとして自動実行します。 順序 要素 処理内容の例 1 トリガー 特定の検知ルールによるアラートを契機に Playbooks を起動 2 コンディション アラートが是正対象（特定の組織・プロジェクト配下など）かを判定 3 アクション （是正） 意図しない公開設定の是正やユーザーの無効化など、脅威への対処を実行 4 アクション （通知・記録） Slack 等で担当者へ通知し、ケースにコメントとして対応内容を記録 5 アクション （クローズ） 自動対応が完了したケースをクローズし、未対応のまま残さない このフローのポイントは、検知（SIEM）と対応（SOAR）が Google SecOps 上でシームレスにつながっている点です。アラートの検知からケースのクローズまでを人手を介さず完結でき、アナリストは対応記録のレビューに集中できます。 以下の記事でも具体例を解説していますのでこちらもあわせてご確認ください。 参考 : Google SecOpsのPlaybooksでアラート対応を自動化する（GitHub編） - G-gen Tech Blog インテグレーション インテグレーションとは Playbooks は、それ単体では Slack や BigQuery のような外部サービスを操作できません。外部サービスへの接続と操作を担うのが インテグレーション です。 Playbooks に組み込む個々のアクション（VirusTotal への照会、Slack への通知など）は、いずれも対応するインテグレーションによって提供されます。つまりインテグレーションは、 Playbooks に組み込むアクションの実態 と言えます。 参考 : Google Security Operations response integrations インテグレーションの種類 インテグレーションは大きく以下の2種類に分けられます。 種類 説明 事前定義済みインテグレーション Google や外部ベンダーが提供するインテグレーション。VirusTotal、Slack、Google BigQuery をはじめ数多くの外部サービスに対応 カスタムインテグレーション Google SecOps 組み込みの IDE （統合開発環境）を使用し、Python でユーザーが独自に開発するインテグレーション 事前定義済みインテグレーションは、 Content Hub （旧称 Marketplace）からインストールして使用します。Content Hub はインテグレーションに限らず、検知ルールやダッシュボードなど、Google SecOps のコンテンツ全般を一元的に入手・管理できる基盤です。 Playbooks を設計する際の基本的な考え方として、まずは操作したい外部サービスに対応する事前定義済みインテグレーションの有無を Content Hub で確認し、存在しない場合にカスタムインテグレーションを開発する、という順序が効率的です。 参考 : Content Hub overview 参考 : Use the IDE インスタンス インストールまたは開発したインテグレーションは、 インスタンス として有効化することで、Playbooks から使用可能な状態となります。 インスタンスには、接続先の API エンドポイントや認証情報（API トークン、サービスアカウント等）といった接続情報を設定します。またインスタンスは環境（Environment）単位で構成するため、本番環境と検証環境で異なる接続先を使い分けるといった運用が可能です。 Playbooks の管理 Playbooks は運用面を考慮した設計と継続的な改善が求められます。SecOps UI では、Playbooks の実行履歴や成功率、稼働環境ごとの傾向を可視化でき、運用状況を踏まえた最適化が可能です。 Content Hub を使用すれば、Google や外部ベンダーが提供する Playbooks や Blocks を追加・再利用できます。これにより、新しい検知ルールや自動化タスクを迅速に取り込み、既存ワークフローに統合できます。 また Gemini を利用することで、自然言語で「目的」「トリガー」「アクション」「条件」を指示するだけで Playbooks の雛形を生成でき、設計工数を大幅に削減できます。 一方で、Playbooks で すべてを自動化するのは現実的ではなく 、次のような判断軸を持つことが重要です。 対応の種類 自動化の可否 例 定型的・繰り返し発生する対応 〇 ログイン失敗の調査、マルウェア検知後の隔離、レピュテーション照会など 分析や意思決定を伴う対応 △ インシデントの深刻度評価、例外対応、再発防止策の検討など（アナリストの判断が適宜必要なもの） このように、 どの工程を自動化し、どの工程を人が判断するか を明確に切り分けることが、Playbooks の設計では非常に重要な観点です。 Google SecOps では、この考え方を基本とし、SecOps UI での統合管理・Content Hub での拡張・Gemini での支援を組み合わせることで、Playbooks を継続的に最適化していくことができます。 参考 : Use the Content Hub for SOAR standalone 参考 : 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 を使ったユースケースについて解説しています。こちらもあわせてご確認ください。 参考 : Google SecOps MCP serverを使ってみた - G-gen Tech Blog Agentic SOC（AI エージェントによるセキュリティ運用） 概要 これまで解説した Gemini による運用支援は、検索クエリや YARA-L ルールの作成、ケース調査の要約など、アナリストの作業を「補助する」ものでした。これに対し、近年の Google SecOps では、アラートの調査や判定といった一連のタスクを AI エージェントが自律的に実行する 機能の提供が進んでいます。 Google はこうした方向性を Agentic SOC （エージェント型 SOC）というビジョンとして掲げており、トリアージや脅威ハンティング、検出エンジニアリングといった作業を担う複数の AI エージェントを Google SecOps 上に展開しています。 エージェント 役割 操作方法 トリアージと調査エージェント アラートを自律的に調査し、脅威か誤検知かを判定する SecOps UI 検出エンジニアリングエージェント 脅威に対する既存ルールのカバレッジを評価し、検出できない範囲を埋めるルールを生成する MCP クライアント 脅威ハンティングエージェント 過去のテレメトリを対象に、未検知の脅威をプロアクティブに探索する SecOps UI 参考 : Agentic defense with Google Security Operations Security Tokens 前述のとおり、Google SecOps の基本的な料金軸は取り込んだログデータ量ですが、AI エージェントの利用については Security Tokens （セキュリティトークン）という別の単位で課金されます。エージェントが使用する基盤モデルのトークン消費量に基づいて計測されるもので、データ取り込み量ベースの基本サブスクリプションとは別建てです。 ただし、すべての AI 機能がトークンを消費するわけではありません。 区分 対象 消費する 一般提供（GA）のエージェント。Web UI、CLI、チャット、MCP からの手動実行と、アラートの自動トリアージのような自動実行の両方が対象 消費しない プレビュー段階のエージェント、および自然言語検索やケース要約といったアシスト機能 つまり、後述の検出エンジニアリング エージェントと脅威ハンティングエージェントは、いずれもプレビュー段階であるため、現時点ではトークンを消費しません。一般提供が開始された時点でトークン消費の対象となります。 トークンは以下の順序で消費されます。 種類 説明 無償トークン（日次） Enterprise Plus および Google Unified Security（GUS）に自動的に付与。米国太平洋時間の 00:00 にリセットされ、翌日への繰り越しは不可。Enterprise には日次の無償枠の付与なし 有償サブスクリプション（年次） 追加購入するトークン。12ヶ月の契約期間内で有効で、次期には繰り越されない 超過（Overage） 上記2つを使い切った後に自動的に発生 つまり Enterprise Plus であれば、日次の無償枠の範囲内で追加費用なくエージェントを使用できます。消費量の目安は、トリアージ1件あたり以下のとおりです。 処理の内容 消費量の目安 早期に判定が確定する簡易的なトリアージ 約10万トークン 詳細な調査まで実施するトリアージ 約50万トークン 同じトリアージ1件でも幅があるのは、エージェントが調査の深さを動的に判断するためです。対象アラートに紐づくログの量や、どこまで裏付けを取る必要があるかによって、実行される検索の回数や参照する情報量が変わります。 上記はあくまで目安であり、実際の消費量や必要な金額は環境や契約内容によって異なります。費用の試算については Google または販売パートナーのセールス担当者にお問い合わせください。 また、自社環境での実際の消費量は、 Agentic Usage Dashboard と Triage and Investigation Agent Metrics というマネージドなダッシュボードから確認できます。これらのダッシュボードでは、トークンの消費量に加えて、調査の実施件数やエージェントの性能、アナリストからのフィードバックといった運用状況もあわせて把握できます。 参考 : Google SecOps Agentic SOC Security Tokens pricing and billing 参考 : Monitor alerts on the Triage Agent dashboard トリアージと調査エージェント（TIN） トリアージと調査エージェント （Triage and Investigation Agent、以下 TIN ）は、Google SecOps に組み込まれた AI ベースの調査エージェントです。アラートを受け取ると、関連するイベントやユーザー・端末・IP アドレスの確認・分析を自動的に行い、主に以下の3つを出力します。 出力 内容 判定（Disposition） アラートが実際の脅威（True Positive）か、誤検知（False Positive）かを分類 確信度（Confidence level） 判定にどの程度の自信があるかを High / Medium / Low で提示 要約（Summary explanation） アラートの概要と、判定に至った根拠・調査結果の要約を提示（推奨される次のアクションを含む） これにより、アナリストは「アラートを一から調査する」状態から、「AI が出した調査結果をレビューする」状態へと移行できます。TIN は Mandiant の知見 や業界のベストプラクティスに基づいて調査を行い、判定の根拠や調査ステップが提示されるため、エージェントがどのように結論へ至ったかを確認できます。 TIN の起動方法には、アラート発生後に自動で調査を開始する 自動調査 と、アナリストが必要に応じて開始する 手動調査 の2種類があります。 参考 : Triage alerts with the Triage Agent エージェントの自動化（Agentic Automation） エージェントの自動化 （Agentic Automation）は、SOAR の Playbooks に AI エージェントを1つのステップとして組み込む仕組みです。前述の SOAR セクションで述べた Playbooks は、あらかじめ定義された手順を確実に実行する「決定論的な自動化」でした。エージェントの自動化は、ここに TIN による「動的な AI 判断」を加え、 判定結果に応じて後続の対応を分岐・自動化 できるようにするものです。 SOAR セクションで触れた「定型的な作業は自動化し、判断を伴う対応は人が担う」という考え方を、AI エージェントによって一段進めるものと言えます。例えば、次のような Playbooks を構成できます。 段階 条件 動作 起動 すべてのアラート Playbooks が起動し、TIN が一次調査を実施 分岐①（自動クローズ） 判定が False Positive かつ確信度が High （＝誤検知の可能性が高い） ケースを自動的にクローズし、アナリストの確認負荷を削減 分岐②（修復へ接続） 判定が True Positive ホストの隔離やユーザーのブロックといった修復アクションへ接続 分岐③（手動レビューへ接続） 判定が False Positive かつ確信度が Low / Medium アナリストへの割り当て・手動レビューに接続し、二次確認を促す このように、確度の高い誤検知は自動的にクローズして「ノイズ」を減らしつつ、確証のある脅威は修復アクションへ、判断に迷うものはアナリストへ振り分ける、といった運用が可能になります。重要なアクションの主導権は人間が握りつつ、定型的な一次対応に AI の判断を組み込める点が特徴です。 参考 : Embed AI agents in playbooks また、以下の記事では TIN の有効化手順、有効化前後のアラート画面の違い、TIN を組み込んだ Playbooks の作成と動作確認まで、具体的な手順を解説しています。あわせてご覧ください。 参考 : Google SecOpsのAIエージェントでアラートの一次対応を自動化する - G-gen Tech Blog 検出エンジニアリングエージェント 検出エンジニアリングエージェント （Detection Engineering Agent）は、ある脅威を既存の検出ルールで検出できるかを評価し、検出できない範囲があれば、それを埋める YARA-L ルールの下書きを生成する AI エージェントです。 TIN や後述の脅威ハンティングエージェントが SecOps UI から使用するのに対し、当エージェントは MCP （Model Context Protocol）経由で操作する点が特徴です。前述の Google SecOps MCP server を Antigravity や Claude Code といった MCP クライアントに登録し、自然言語で指示します。 カバレッジの評価は以下の流れで実行されます。 順序 処理 説明 1 脅威検出の機会の生成 セキュリティブログや脅威レポートなどの文章から脅威の情報を抽出し、優先順位を付けた 脅威検出の機会 （Threat Detection Opportunity、TDO）を作成 2 合成イベントの生成 TDO をもとに、その攻撃が起きたときに記録されるであろうログ（ 合成イベント ）を UDM 形式で生成 3 カバレッジの評価 既存のルールが生成された合成イベントを検出するかを確認 4 ルールの生成 検出の抜けが見つかった場合、それを埋める YARA-L ルールの下書きを作成 合成イベントは実際に Google SecOps に取り込まれるため、取り込みクォータと検出クォータを消費します。また、評価したい脅威のログタイプに対応するパーサーが環境に存在することが前提であり、対応するパーサーがない場合はそのログタイプのカバレッジを評価できません。 生成されたルールは、そのまま作成すると検出したい攻撃以外のログにも一致することがあります。公式ドキュメントも、生成されたルールは検出エンジニアがレビューしたうえでデプロイすることを前提としています。 参考 : Use the Detection Engineering Agent 以下の記事では、Antigravity CLI から検出エンジニアリングエージェントを使用し、カバレッジの評価からルールの作成・確認までを実施した検証結果を解説しています。あわせてご覧ください。 参考 : Google SecOpsのAIエージェントで脅威を検出できるか評価する - G-gen Tech Blog 脅威ハンティングエージェント 脅威ハンティングエージェント （Threat Hunt Agent）は、過去に蓄積されたテレメトリを対象に、脅威の仮説検証を自律的に行う AI エージェントです。Gemini により動作し、Google Threat Intelligence、Mandiant の知見、MITRE ATT&CK フレームワークに基づいて調査します。 検知されたアラートを起点とする TIN と異なり、アラートが上がっていない領域に対してプロアクティブに探索する点が特徴です。防御をすり抜けた脅威を発見し、攻撃者の滞留時間（dwell time）を削減することを狙いとしています。 ハントは以下の流れで実行されます。 順序 処理 説明 1 対象の選択 脅威アクター、キャンペーン、マルウェア、ソフトウェアツールキット、TTP といったカテゴリから対象の脅威を選択 2 期間の指定 探索対象とする過去テレメトリの期間を指定（最大30日） 3 ハントの実行 エージェントがハント計画を立て、YARA-L 2.0 による検索をバックグラウンドで自律的に実行 4 結果の確認 結果はケースとして作成され、判定（Determination）とともに確認 ハントは Emerging Threats、Google Threat Intelligence の情報、MITRE ATT&CK マトリクスなどから起動します。作成されるケースには Threat Hunt for [対象名] という接頭辞が付くため、通常のケースと区別できます。判定は Substantial Evidence （有力な証拠あり）、 Evidence Found （証拠を検出）、 Threat Not Found （脅威なし）などで示されます。 使用にあたっては以下の前提があります。 項目 内容 エディション プレビュー期間中は Enterprise Plus のみ ケース管理 新しいケース管理エクスペリエンスの有効化が必要（こちらも Public Preview） ハントの上限 プレビュー期間中は同時実行数と1日あたりの実行数に上限あり 参考 : Threat Hunt agent overview 認定資格 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 武井 祐介 (記事一覧) クラウドソリューション部 > 事業開発部。 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 が要約・生成・分析などのタスクを行います。また Gemini Notebook Enterprise（旧 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 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。