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

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

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

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

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

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

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

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

G-gen の杉村です。2026年3月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud のアップデート Gemini 3.1 Flash-Lite が Preview 公開 IAM で Service account principal sets が使えるようになった BigQuery の Conversational Analytics がアップデート gemini-embedding-2-preview が登場 Cloud Storage に Rapid bucket が登場（GA） Cloud Run への IAP 認証の直接設定が一般公開（GA） BigQuery でグローバルデフォルトロケーションが設定可能に AlloyDB のエンハンストバックアップが一般公開（GA） BigQuery data preparation が Cloud Storage と Google ドライブに対応 Cloud NGFW（Enterprise tier）に URL フィルタリングが登場 Imagen モデルが廃止へ 音楽生成モデル Lyria 3 が Vertex AI 経由で使用可能に（Public Preview） Vertex AI Search の回答モデルに gemini-3.1-pro、gemini-3-flash が登場 AlloyDB と Cloud SQL で Conversational analytics が Preview 公開 TPU7x が提供開始 Google Workspace のアップデート Google Workspace の Gemini アプリの共有（公開リンク）が可能に Gemini in Chrome の対応地域が拡張（日本は未対応） NotebookLM にスライドの PPTX 形式エクスポートなどの機能追加 Google Meet の会議の参加者承認時、疑わしいリクエストが分けて表示される Gemini アプリでこれまでより長く3分間の音楽の生成が可能に Google Workspace に「ゲストアカウント」機能が登場 Google ドライブのランサムウェア検出が Beta 版 → 一般公開（GA） はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud のアップデート Gemini 3.1 Flash-Lite が Preview 公開 Gemini 3.1 Flash-Lite (2026-03-03) Gemini 3.1 Flash-Lite が Preview 公開。 「Gemini 2.5 Flash に相当する回答品質」を目指している。Vertex AI や Google AI Studio から利用可能。 IAM で Service account principal sets が使えるようになった Service accounts (2026-03-03) IAM で Service account principal sets が使えるようになった。あるプロジェクト/フォルダ/組織配下の全サービスアカウント or 全サービスエージェントを指すセット。 あるプロジェクト内の全サービスアカウントは principalSet://cloudresourcemanager.googleapis.com/projects/123456789012/type/ServiceAccount 、あるフォルダ内の全サービスエージェントは principalSet://cloudresourcemanager.googleapis.com/folders/123456789012/type/ServiceAgent のように表現される。 IAM 許可ポリシーや拒否ポリシーに、プリンシパルとして書き込める。 BigQuery の Conversational Analytics がアップデート BigQuery release notes - March 09, 2026 (2026-03-09) BigQuery の Conversational Analytics がアップデート。 BigQuery Studio の SQL 実行結果から会話をスタートできる AI.FORECAST、AI.DETECT_ANOMALIES、AI.GENERATE に対応 ObjectRef 対応で非構造化データが扱える パーティション列で効率的にクエリをする ジョブ履歴に {‘ca-bq-job’: ‘true’} が付く 次の質問のサジェストが出る gemini-embedding-2-preview が登場 Gemini Embedding 2 (2026-03-10) gemini-embedding-2-preview が登場。 マルチモーダルなエンベディングモデルで、ドキュメントの OCR や動画から音声トラックを抽出することも可能。 Cloud Storage に Rapid bucket が登場（GA） Rapid Bucket (2026-03-10) Cloud Storage に Rapid bucket が登場（GA）。 VM と同じゾーンにバケットを配置することで低レイテンシで高スループットを実現。AI/MLやデータ分析、ロギング、ストリーミング記録などに使用することを想定。 Cloud Run への IAP 認証の直接設定が一般公開（GA） Configure IAP for Cloud Run (2026-03-13) Cloud Run にロードバランサーなしで IAP 認証を設定する機能が Preview → 一般公開（GA）。 GA にあわせて組織外ユーザーの認証も可能になった。これまでは組織内ユーザーに限定されていた。 BigQuery でグローバルデフォルトロケーションが設定可能に Specify global settings (2026-03-16) BigQuery でグローバルデフォルトロケーションが設定可能になった。 組織レベルまたはプロジェクトレベルで適用できる。これまで場所の指定がない場合はシステム側の挙動に依存していたが、このアップデートにより、意図しないリージョンでのリソース作成や、場所指定漏れによるエラーを未然に防ぐことができる。 AlloyDB のエンハンストバックアップが一般公開（GA） Manage enhanced backups (2026-03-16) AlloyDB のエンハンストバックアップ（拡張バックアップ）が一般公開（GA）。 Backup and DR サービスと連携。一元化されたバックアップ管理プロジェクトで管理および保存される。 変更不可のストレージ: バックアップは、Backup and DR で管理される Backup Vault に保存される 保持の適用: ポリシーにより、バックアップの誤った削除や悪意のある削除を防ぐ 高度なスケジュール設定: バックアップの頻度と保持ルールを高度にカスタマイズできる 一元管理: AlloyDB、Cloud SQL、Compute Engine などの複数のGoogle Cloud ワークロードにわたって統一されたモニタリングとレポート BigQuery data preparation が Cloud Storage と Google ドライブに対応 BigQuery release notes - March 23, 2026 (2026-03-23) BigQuery の「データ準備（Data preparation）」が、Cloud Storage と Google ドライブからのデータ取り込みに対応。 Data preparation とは、AI によるデータエンジニアリング支援ツール。ファイルをテーブルに取り込んで変換等する作業などが簡単に実装できる。 Cloud NGFW（Enterprise tier）に URL フィルタリングが登場 URL filtering service overview (2026-03-24) Cloud NGFW（Enterprise tier）に URL フィルタリングが登場。 HTTP(S)トラフィックのドメイン / SNI 情報に基づいて URL フィルタリングを行う。 Cloud NGFW の Enterprise tier では、VPC にエンドポイントを構築し、パケットを横から検査する。エンドポイントの存在した時間に応じて料金が発生する。 参考 : Cloud Next Generation Firewall pricing Imagen モデルが廃止へ Vertex AI release notes - March 24, 2026 (2026-03-24) 画像生成モデル Imagen モデルが廃止へ。 推奨される後継モデルは gemini-2.5-flash-image （いわゆる Nano Banana 2）。以下のようなモデルが廃止される（一部抜粋）。 imagegeneration@006 imagetext@001 imagen-3.0-capability-002 imagen-3.0-fast-generate-001 imagen-3.0-generate-002 imagen-4.0-fast-generate-001 imagen-4.0-generate-001 imagen-4.0-ultra-generate-001 音楽生成モデル Lyria 3 が Vertex AI 経由で使用可能に（Public Preview） Lyria 3 (2026-03-25) 音楽生成モデル Lyria 3 が Vertex AI 経由で使用可能になった（Public Preview）。インプットにはテキストと画像が使える。 lyria-3-pro-preview : 184秒の音楽生成 lyria-3-clip-preview : 30秒の音楽生成 Vertex AI Search の回答モデルに gemini-3.1-pro、gemini-3-flash が登場 Answer generation model versions and lifecycle (2026-03-26) Vertex AI Search の回答モデルに新しいモデルが登場 gemini-3.1-pro-preview gemini-3-flash-preview なおこれまで使えていた Gemini 3 Pro Preview は使用不可になる。 AlloyDB と Cloud SQL で Conversational analytics が Preview 公開 Conversational analytics for Cloud SQL for PostgreSQL overview (2026-03-26) AlloyDB for PostgreSQL、Cloud SQL for PostgreSQL / MySQL で、Conversational analytics（会話型分析）が Preview 公開。 Google Cloud コンソールから自然言語を使って、テーブルに対するクエリを発行できる。BigQuery に続いて、運用データベースでも自然言語による DB へのクエリが可能になった。 TPU7x が提供開始 TPU7x (Ironwood) (2026-03-31) Google Cloud で新しい TPU「TPU7x」が提供開始。Google Kubernetes Engine（GKE）で使用可能。第7世代 TPU である Ironwood ファミリーであり、大規模 AI トレーニング・推論向け。 Google Workspace のアップデート Google Workspace の Gemini アプリの共有（公開リンク）が可能に Workspace admins can allow Gemini app conversation sharing for their organizations (2026-03-04) Google Workspace の Gemini アプリの共有（公開リンク）が可能になった。これまでは個人版のみ可能だった。 公開リンクは Google アカウントがなくても閲覧可。デフォルトで無効で、管理者設定で有効化の必要あり。許可するかどうかはセキュリティ上の考慮が必要。 Gemini in Chrome の対応地域が拡張（日本は未対応） Gemini in Chrome expands to more countries and languages, including Canada, New Zealand, and India (2026-03-13) Gemini in Chrome が従来の米国に加えて、カナダ、ニュージーランド、インドに対応。 Gemini in Chrome とは、開いているタブのコンテキストに基づいて記事の要約、解説、情報を検索したり、コンテンツの生成（テキスト・画像）、また Gemini Live などを使える機能のこと。 日本のユーザーは未対応なため注意。 NotebookLM にスライドの PPTX 形式エクスポートなどの機能追加 New ways to customize and interact with your content in NotebookLM (2026-03-20) NotebookLM に機能追加。 インフォグラフィックのスタイル指定 パワポ形式でのスライドのエクスポート スライド微調整 Cinematic Video Overviews (ただし英語のみ) ...など。 対象の Google Workspace エディションは全エディションだが、Cinematic Video Overviews のみ Business Standard 以上など。 Google Meet の会議の参加者承認時、疑わしいリクエストが分けて表示される Safeguarded guest admit flow in Google Meet (2026-03-24) Google Meetの会議の参加者承認にアップデート。信頼性が怪しい入室リクエストについては、通常のリクエストとは分けて表示されるようになる。 Gemini アプリでこれまでより長く3分間の音楽の生成が可能に Create longer musical tracks in the Gemini app with Lyria 3 Pro (2026-03-25) Gemini アプリで、新モデル Lyria 3 Pro により、3分間の音楽生成が可能になった。従来は30秒。 Google Workspace の Business Standard 以上のエディションで、2026年3月25日から数日かけてロールアウト。 Google Workspace に「ゲストアカウント」機能が登場 Introducing guest accounts: Collaborate securely and communicate with non-Workspace users in Google Chat (2026-03-30) Google Workspace に「ゲストアカウント」機能が登場。 外部の人を Google Chat 経由で招待すると、一意の ID が割り当てられたゲストアカウントが発行される。 Google ドライブ上のファイルの共同作業が可能（ファイル新規作成は不可）。Workspace Guests OU に配置され各種ポリシーを適用可能。 有償ライセンス数 × 5個のゲストアカウントが作成可能。 Google ドライブのランサムウェア検出が Beta 版 → 一般公開（GA） Ransomware detection and file restoration for Google Drive now generally available (2026-03-30) Google ドライブでランサムウェア検出＆ファイル修復機能が Beta 版 → 一般公開（GA）。 デスクトップ版 Google ドライブを使っている場合に、ランサムウェアが検出されると、ファイル同期が停止され、管理者や本人にアラート通知。 万一、ドライブ上のファイルが暗号化されても一括復元が可能。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では、Google Cloud が提供する、フルマネージドの AI エージェントプラットフォームである Vertex AI Agent Engine について解説します。 はじめに Vertex AI Agent Builder とは Vertex AI Agent Engine とは 他のエージェント実行基盤との比較 Agent Engine の基本 エージェントの開発 エージェントの実行環境 実行環境の基本事項 コールドスタート エージェントの使用 エージェントに対する権限付与 Agent Engine のサブリソース セッション Memory Bank Code Execution Example Store（プレビュー機能） エージェントの品質評価 オブザーバビリティ モニタリング ロギング トレース セキュリティ 料金 はじめに Vertex AI Agent Builder とは Vertex AI Agent Builder は、Google Cloud 上で AI エージェントを構築、管理、実行するために必要な機能を提供するプロダクト群です。 Vertex AI Agent Builder では、エージェント開発を容易にするオープンソース フレームワークである Agent Development Kit （ADK）、ユースケースに応じたエージェントのサンプルが多数提供される Agent Garden 、GUI を用いてローコードでエージェントの設計・テストを行うことができる Agent Designer 、そして当記事で紹介する Agent Engine などが提供されています。 参考 : Vertex AI Agent Builder の概要 Vertex AI Agent Engine とは Vertex AI Agent Engine （以下、Agent Engine）は、Vertex AI Agent Builder に内包されたプロダクトの1つで、エージェントを実行するためのフルマネージドの実行基盤を提供します。 Agent Engine では、組み込みの機能としてエージェントのマルチターン会話を実現する セッション 機能や 自動スケーリング 機能、その他エージェントの機能拡張・運用管理に必要な様々な機能を利用することができます。 参考 : Vertex AI Agent Engine の概要 他のエージェント実行基盤との比較 Google Cloud における代表的なエージェント実行基盤としては、Agent Engine の他に Cloud Run 、 Google Kubernetes Engine （GKE）などがあります。 Cloud Run では、Agent Engine と同様にサーバーレスの実行基盤でエージェントを実行することができます。Agent Engine と比較して実行環境のカスタマイズ性が高い反面、セッションの保持のようなエージェント特有の機能は Cloud SQL や Firestore などのサービスと連携するなどして独自に実装する必要があります。 GKE では Agent Engine や Cloud Run と比較して、コンピューティングリソースやネットワーク等インフラストラクチャの細かい制御が可能です。Kubernetes によるカスタマイズ性の非常に高いエージェント実行基盤を構築することができますが、トレードオフとして環境の構築・運用コストが高くなります。 実行環境 Agent Engine Cloud Run GKE セッション機能 組み込み 独自実装 独自実装 自動スケーリング 組み込み 組み込み 独自実装 実行環境のカスタマイズ性 低い 中程度 高い 環境の構築、運用コスト 低い（サーバーレス） 低い（サーバーレス） 高い（マネージド Kubernetes クラスタ） Google Cloud 上で新たに AI エージェントの構築を検討する際は、まずはエージェントの実行に特化した Agent Engine の利用を検討し、Agent Engine では実現できない要件がある場合に Cloud Run や GKE を検討するのが良いでしょう。 参考 : Choosing the Right Deployment Path for Your Google ADK Agents Agent Engine の基本 エージェントの開発 Agent Engine では、Agent Development Kit（ADK）や LangChain、LangGraph などのフレームワークで開発したエージェントのほか、フレームワークに依存しない独自のエージェント（カスタムエージェント）をデプロイすることができます。 2026年3月現在、Agent Engine にエージェントをデプロイするには、Vertex AI SDK または REST API、ADK 用の CLI などを用いてデプロイ用の API を呼び出す必要があります。Google Cloud コンソールや gcloud CLI によるデプロイはサポートされていません。 以下の記事では、ADK を用いて開発したエージェントを Agent Engine にデプロイする手順を解説しています。 blog.g-gen.co.jp 参考 : Vertex AI Agent Engine の概要 - サポートされているフレームワーク 参考 : エージェントを開発する 参考 : エージェントをデプロイする エージェントの実行環境 実行環境の基本事項 Agent Engine にデプロイしたエージェントは、Google Cloud が管理するフルマネージドの実行基盤で実行されます。 Agent Engine にデプロイしたエージェントに対してリクエストが送信されると、Agent Engine はリクエストを処理するための コンテナインスタンス を起動し、その上でエージェントを実行します。 したがって、Agent Engine のインスタンスは Cloud Run のように サーバーレス であり、必要なときだけコンピューティングリソースを確保してエージェントを実行するという特徴があります。 2026年3月現在はプレビュー提供の機能ですが、起動するコンテナインスタンスが確保するコンピューティングリソース（CPU、メモリ）や、コンテナインスタンスの最小・最大数、インスタンスあたりのエージェントの同時実行数は、エージェントのデプロイ時に指定することができます。 項目 設定値 デフォルト値 CPU（vCPU） 1, 2, 4, 6, 8 4 メモリ（Gi） 1, 2, 4, 8, 16, 32 4 最小インスタンス数 0~10 0 最大インスタンス数 1~1,000 10 エージェント同時実行数 1以上 9 参考 : エージェントをデプロイする - カスタマイズされたリソース制御を定義する コールドスタート Agent Engine では、起動中のインスタンスがない場合、もしくは現在起動中のインスタンスでリクエストを処理しきれない場合に、それを処理するためのインスタンスを追加で起動します。 このような仕様から、コンテナインスタンスの起動待機時間により、エージェントのレスポンスが遅くなることがあります（ コールドスタート ）。コールドスタートによる平均レイテンシーは約4.7秒とされています。 これを回避するためには、常に起動したままにするインスタンスの数（min_instances）をリクエストの量に応じた適切な数（1以上）に設定します。 2026年3月現在、min_instances の設定はプレビュー提供の機能となっており、min_instances の値を1以上に設定していても、エージェントがアイドル状態の間はコンピューティングリソースの料金が発生しません。しかし、この仕様は将来的には変更される可能性があるため、適切なインスタンス数を設定できるようにパフォーマンスのモニタリングを行うことが重要です。 参考 : Vertex AI Agent Engine ランタイムを最適化してスケーリングする - コールド スタートの問題 エージェントの使用 Agent Engine で実行されるエージェントは、Vertex AI SDK や REST API を使用して呼び出すことができます。 また、Agent Development Kit（ADK）を使用して開発したエージェントであれば、Google Cloud コンソールからエージェントを直接呼び出して会話することも可能です。 Google Cloud コンソールからエージェントと会話する 参考 : Agent Development Kit エージェントを使用する エージェントに対する権限付与 エージェントが BigQuery にアクセスする場合など、Agent Engine で実行されるエージェントが Google Cloud API を利用する場合、 AI Platform Reasoning Engine サービスエージェント または カスタムサービスアカウント に対して必要な IAM 権限を付与します。 サービスエージェントは以下の形式で Agent Engine を利用しているプロジェクト内に存在します。 service-<プロジェクト番号>@gcp-sa-aiplatform-re.iam.gserviceaccount.com 参考 : デプロイされたエージェントのアクセスを管理する Agent Engine のサブリソース セッション Agent Engine にデプロイしたエージェントは、ユーザーとエージェントの会話履歴を保持する セッション機能 を組み込みで利用することができます。 セッションはユーザーがエージェントとの会話を開始したときに新たに作成され、ユーザーとエージェントの会話内容を記憶していきます。 セッションは、設定された有効期限か会話の終了によって削除されます。セッションが削除されるとそれまでの会話履歴は失われるため、会話の終了後、再度エージェントを利用するときに以前の会話履歴を参照させたい場合は後述の Memory Bank を利用する必要があります。 セッションは、Agent Development Kit（ADK）で開発したエージェントの場合は何も追加で実装する必要がなく、自動的に処理されます。それ以外の方法でエージェントを実行する場合は、API を利用してセッションを作成・管理することができます。 参考 : Vertex AI Agent Engine セッションの概要 Memory Bank Memory Bank はセッション機能と同様にユーザーとエージェントの会話履歴を記憶する機能です。 セッション機能が特定ユーザーの1つのセッション内の記憶を保持する機能であるのに対して、Memory Bank は特定ユーザーの複数のセッションにまたがる 長期記憶 を保持する機能です。長期記憶により、ユーザーごとにパーソナライズされた会話をセッション間でも継続することができます。 Memory Bank では、LLM を使用して会話の中から意味のある情報を 抽出 し、既存の記憶と 統合 することで記憶内容を洗練する機能と、記憶をマネージドのストレージに保存して必要な時に 検索・取得 する機能が提供されます。 参考 : Vertex AI Agent Engine Memory Bank の概要 Code Execution Code Execution はエージェントがタスク内で生成したコードを、エージェントの実行環境とは分離された安全なサンドボックス上で実行する機能です。 サンドボックスでコードを実行するためには、Agent Development Kit（ADK）等を使用してサンドボックスを作成しておき、それを使用してコードを実行するようにエージェントを実装する必要があります。 サンドボックスは1秒以内に高速で起動し、エージェントが生成したコードを実行します。 なお、当機能は2026年3月時点では us-central1 リージョンのみで利用可能となっています。 エージェントが生成したコードを Code Execution サンドボックスで実行する 参考 : Vertex AI Agent Engine コード実行 Example Store（プレビュー機能） Example Store は、Few-shot プロンプティングによってエージェントの回答品質を制御するための機能であり、エージェントが LLM に推論リクエストを送信する際に利用することができる プロンプトと回答の組み合わせのいくつかの例（Few-shot） を保存・管理することができます。 Example Store を使用するには、事前に Example Store インスタンスを作成し、サンプルとなるプロンプトと回答の組み合わせをインスタンスにアップロードしておく必要があります。 Agent Development Kit（ADK）で開発したエージェントの場合、エージェントが使用する Example Store インスタンスを事前に指定しておくことで、プロンプトの内容に応じて自動的にサンプルを取得して LLM へのリクエストに含めることができます。それ以外の方法でエージェントを実行する場合は、API を利用して Example Store から例を検索・取得し、LLM へのリクエストに含めるように実装する必要があります。 エージェントが Example Store に保存されたサンプルを使用して LLM に推論リクエストを送信する 参考 : Few-Shotプロンプティング 参考 : Vertex AI Agent Engine Example Store の概要 エージェントの品質評価 Agent Engine で実行するエージェントの品質は、 Gen AI Evaluation Service を使用して評価することができます。 Gen AI Evaluation Service は Google Cloud コンソールや Vertex AI SDK から利用することができます。評価用のプロンプトのリストをデータセットとしてエージェントに渡して、エージェントから得られた回答を、事前定義された指標やユーザー定義の指標をベースに評価することができます。 参考 : Vertex AI SDKのGen AI Clientを使用してエージェントを評価する 参考 : Gen AI Evaluation Service の概要 オブザーバビリティ モニタリング Agent Engine は Cloud Monitoring と統合されており、組み込みの指標やカスタム指標、アラートを使用してエージェントをモニタリングすることができます。 組み込みの指標としては、以下の指標がサポートされています。 リクエスト数 リクエストのレイテンシー CPU 割り当て時間 メモリ割り当て時間 参考 : エージェントをモニタリングする ロギング Cloud Logging との統合により、エージェントが標準出力や標準エラー出力に書き込んだログは、デフォルトで Cloud Logging に転送されます。構造化されたログを記録したい場合は、組み込みの Python ロガーや Cloud Logging クライアントを使用します。 なお、Cloud Logging との統合はセッション機能、Memory Bank などの Agent Engine のサブリソースではサポートされていません。 参考 : エージェントのロギング トレース 2026年3月時点ではプレビュー提供の機能ですが、 Cloud Trace との統合により、エージェントが実行した関数呼び出しや LLM とのやり取りなどをタイムラインとして取得し、個々のオペレーションのパフォーマンスを分析することができます。 参考 : エージェントをトレースする セキュリティ エージェントの実行基盤として Agent Engine を使用する場合、Google Cloud が提供するエンタープライズレベルのセキュリティ機能を統合することができます。 例えば、 VPC Service Controls を使用することで、Agent Engine で実行されるエージェントが BigQuery API や Cloud SQL Admin API などの Google Cloud API に安全にアクセスしつつ、エージェントによるデータの移動を事前定義した境界内に制限することができます。なお、VPC Service Controls は Code Execution のサンドボックスで実行されるコードにも適用されます。 また、セッション機能や Memory Bank で保存されるユーザーの会話履歴は、 顧客管理の暗号鍵（CMEK） を使用して暗号化することができます。 参考 : Vertex AI Agent Engine の概要 - エンタープライズ セキュリティ 料金 エージェントの実行基盤のコンピューティングリソースの利用料金として、vCPU とメモリの量に利用時間をかけた料金が発生します。エージェントがリクエストを処理していないアイドル時間については課金対象外となっています。 リソース 料金 備考 vCPU 1 vCPUあたり $0.0864/時間 1ヶ月の最初の50 vCPU 時間（1 vCPU の場合は50時間）は無料枠。アイドル時間は無料 メモリ 1 GiBあたり $0.009/時間 1ヶ月の最初の100 GiB 時間（1 GiB の場合は100時間）は無料枠。アイドル時間は無料 セッションや Memory Bank などエージェントの記憶に関する機能の利用料金として、保存した量に応じて以下の料金が発生します。 機能 料金 備考 セッション 保存されたイベント1,000件あたり $0.25 Memory Bank 保存された記憶 : 1,000件あたり $0.25/月 保存された記憶の取得 : 記憶1,000件ごとに $0.50 記憶生成の LLM 費用が別途かかる 1ヶ月あたり最初に取得する1,000件までは無料 エージェントがタスク内で生成したコードを Code Execution を使用してサンドボックス上で実行する場合、サンドボックスのコンピューティングリソース料金が別途発生します。 リソース 料金 備考 vCPU 1 vCPUあたり $0.0864/時間 アイドル時間は無料 メモリ 1 GiBあたり $0.009/時間 アイドル時間は無料 参考 : Vertex AI の料金 - Vertex AI Agent Engine 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では、Artifact Registry で不要になったイメージを自動削除する クリーンアップポリシー について、特定のイメージが削除されないように条件付きの 保持ポリシー を組み合わせて使う方法を解説します。 クリーンアップポリシーとは 機能の概要 保持ポリシーを使用するケース 保持ポリシーで設定可能な条件 当記事のユースケース 設定方法 保持対象イメージへのタグの付与 ドライラン ポリシーの適用 クリーンアップポリシーとは 機能の概要 Artifact Registry の クリーンアップポリシー は、リポジトリ内のイメージを条件に基づいて自動的に削除する機能です。 開発を続けていると、不要なイメージが蓄積し、ストレージコストが増大してしまう場合があります。クリーンアップポリシーを設定することで、不要なイメージを自動的に削除することができます。 クリーンアップポリシーには以下の2種類があります。 種類 説明 削除ポリシー（Delete） 条件に一致したイメージを削除する 保持ポリシー（Keep） 条件に一致したイメージを削除から保護する 1つのリポジトリに対して、削除ポリシーと保持ポリシーを複数組み合わせて設定できます。保持ポリシーは削除ポリシーよりも優先されるため、「基本的には削除するが、特定の条件に一致するイメージは残す」という運用が可能です。 クリーンアップポリシーの詳細については、以下の記事で解説しています。 blog.g-gen.co.jp 参考 : クリーンアップ ポリシーの概要 参考 : クリーンアップ ポリシーを構成する 保持ポリシーを使用するケース 保持ポリシーを使用せずに削除ポリシーのみを適用していると、「本番環境で現在利用しているイメージが削除ポリシーによって削除されてしまう」といった問題が起こり得ます。 例えば Cloud Run jobs では、ジョブに設定されているコンテナイメージが削除されてしまうと、実行時にコンテナインスタンスが立ち上がらずにジョブが失敗してしまいます。 使用するコンテナイメージが削除され、Cloud Run jobs のジョブが失敗したケース このケースでは、Cloud Logging で以下のようなエラーを確認できます。 Image ' <Artifact Registryのコンテナイメージのパス> ' not found. 保持ポリシーで設定可能な条件 保持ポリシーは、条件に一致するイメージを削除から保護するためのポリシーであり、以下のような条件を指定できます。 条件 説明 tagState タグの状態（ tagged / untagged / any ） tagPrefixes タグのプレフィックス（例: release , prod ） versionNamePrefixes バージョン名のプレフィックス packageNamePrefixes パッケージ名のプレフィックス olderThan 指定した期間より古いイメージ newerThan 指定した期間より新しいイメージ また、 mostRecentVersions を使うことで、直近の N 個のバージョンを保持するという指定も可能です。 参考 : クリーンアップ ポリシーの設定 - 条件付き保持ポリシーの作成 当記事のユースケース 当記事では、以下のようなユースケースを想定します。 release タグが付いたイメージは本番環境にデプロイされているため、常に保持したい 直近5バージョンは開発・デバッグのために残しておきたい 上記以外の古いイメージは自動的に削除したい これを実現するために、以下の3つのポリシーを組み合わせます。 ポリシー名 設定内容 keep-tagged-release release プレフィックスが付いたタグ付きイメージを保持 keep-minimum-versions 直近5バージョンを保持 delete-all 上記の保持ポリシーで保護されなかったイメージをすべて削除 ポリシーの定義ファイル（記事内では policy.json とする）は以下の通りです。 [ { " name ": " keep-tagged-release ", " action ": { " type ": " Keep " } , " condition ": { " tagState ": " tagged ", " tagPrefixes ": [ " release " ] } } , { " name ": " keep-minimum-versions ", " action ": { " type ": " Keep " } , " mostRecentVersions ": { " keepCount ": 5 } } , { " name ": " delete-all ", " action ": { " type ": " Delete " } , " condition ": { " tagState ": " any " } } ] このポリシーでは、2つの保持ポリシーによって「 release プレフィックスのタグが付いたイメージ」と「直近5バージョン」が保護されます。 そして、保護していないイメージは削除ポリシーによって削除されます。 保持ポリシーは削除ポリシーよりも優先される ため、保持対象のイメージが誤って削除されることはありません。 設定方法 保持対象イメージへのタグの付与 当記事では以下のスクリーンショットのように、 v1.0.0 タグが付いたイメージを本番環境で運用中のイメージと想定し、以降のバージョンが増えることによってイメージが削除されないように、保持ポリシーの条件である release タグを付与します。 保持したいイメージに release タグを付けておく ドライラン クリーンアップポリシーを適用する前に、まず ドライラン で削除対象のイメージを確認することを推奨します。ドライランでは実際の削除は行われず、削除対象となるイメージが Cloud Logging に記録されます。 # ドライランの設定でクリーンアップポリシーを適用する $ gcloud artifacts repositories set-cleanup-policies < リポジトリ名 > \ --project =< プロジェクトID > \ --location = asia-northeast1 \ --policy = policy.json \ --dry-run ドライランが実行されると、Cloud Logging にどのイメージが削除対象となったかが記録されます。 Cloud Logging で以下のような条件でフィルタリングし、ドライランのログを確認します。 protoPayload.serviceName="artifactregistry.googleapis.com" protoPayload.methodName="google.devtools.artifactregistry.v1.ArtifactRegistry.BatchDeleteVersions" ドライラン結果として以下のようなログが出力されているので、意図しないイメージが削除対象になっていないか確認します。削除対象のイメージは protoPayload.request.names にリスト形式で記録されています。 { " protoPayload ": { " @type ": " type.googleapis.com/google.cloud.audit.AuditLog ", " status ": {} , " authenticationInfo ": { " principalEmail ": " service-xxxxxxxxxxxx@gcp-sa-artifactregistry.iam.gserviceaccount.com " } , " requestMetadata ": { " callerIp ": " private ", " callerSuppliedUserAgent ": " stubby_client ", " requestAttributes ": { " time ": " 2026-03-25T13:29:47.993615022Z ", " auth ": {} } , " destinationAttributes ": {} } , " serviceName ": " artifactregistry.googleapis.com ", " methodName ": " google.devtools.artifactregistry.v1.ArtifactRegistry.BatchDeleteVersions ", " authorizationInfo ": [ { " resource ": " projects/<プロジェクトID>/locations/asia-northeast1/repositories/<リポジトリ名>/packages/- ", " permission ": " artifactregistry.versions.delete ", " granted ": true , " resourceAttributes ": {} , " permissionType ": " DATA_WRITE " } ] , " resourceName ": " projects/<プロジェクトID>/locations/asia-northeast1/repositories/<リポジトリ名>/packages/- ", " request ": { " @type ": " type.googleapis.com/google.devtools.artifactregistry.v1.BatchDeleteVersionsRequest ", " parent ": " projects/<プロジェクトID>/locations/asia-northeast1/repositories/<リポジトリ名>/packages/- ", " names ": [ " projects/<プロジェクトID>/locations/asia-northeast1/repositories/<リポジトリ名>/packages/<イメージ名>/versions/sha256:92e1bbc6c7a85472768f3bbe191bb11a2d00531b0c542093025dfc6d41885894 ", " projects/<プロジェクトID>/locations/asia-northeast1/repositories/<リポジトリ名>/packages/<イメージ名>/versions/sha256:e4f1245e24b0c9947b31f6565e2b573583b32e570dcba40e4cb9e2596ea39251 ", " projects/<プロジェクトID>/locations/asia-northeast1/repositories/<リポジトリ名>/packages/<イメージ名>/versions/sha256:064ee8f6db44777f1164ab037c85c54780ec6912bea647484e88601da10ca115 ", " projects/<プロジェクトID>/locations/asia-northeast1/repositories/<リポジトリ名>/packages/<イメージ名>/versions/sha256:54c09f62de97bccd6cf12f7f964aea22469cac1d7b2a378a656f8ae599fc5183 ", " projects/<プロジェクトID>/locations/asia-northeast1/repositories/<リポジトリ名>/packages/<イメージ名>/versions/sha256:a4f9c3250d99a2ef8d1174e7e932231b613c4777ee52b4f7ae6789f6e4422171 " ] , " validateOnly ": true } } , " insertId ": " 18prm54d2w06 ", " resource ": { " type ": " audited_resource ", " labels ": { " service ": " artifactregistry.googleapis.com ", " project_id ": " <プロジェクトID> ", " method ": " google.devtools.artifactregistry.v1.ArtifactRegistry.BatchDeleteVersions " } } , " timestamp ": " 2026-03-25T13:29:47.981759939Z ", " severity ": " INFO ", " logName ": " projects/<プロジェクトID>/logs/cloudaudit.googleapis.com%2Fdata_access ", " operation ": { " id ": " projects/<プロジェクトID>/locations/asia-northeast1/operations/2bd61d82-efbc-41a1-b0e8-5606076b4c45 ", " producer ": " artifactregistry.googleapis.com ", " first ": true } , " receiveTimestamp ": " 2026-03-25T13:29:48.932576392Z " } 対象イメージの sha256: の後ろの英数字12桁が Artifact Registry にあるイメージ名と一致するようになっています。 release タグの付いているイメージを除いて古い順からイメージが削除され、新しい順に5つのイメージと release タグの付いたイメージが残されることがわかります。 削除ポリシーの対象となっているイメージ（赤枠） ポリシーの適用 ドライランの結果に問題がなければ、 --no-dry-run フラグを指定してポリシーを適用します。 # クリーンアップポリシーを適用する $ gcloud artifacts repositories set-cleanup-policies < リポジトリ名 > \ --project =< プロジェクトID > \ --location = asia-northeast1 \ --policy = policy.json \ --no-dry-run ポリシーが適用されると、以降はクリーンアップポリシーに基づいてイメージが自動的に削除されます。 イメージが削除され、release タグが付いたイメージは削除対象とならずに保持されている（赤枠） 参考 : gcloud artifacts repositories set-cleanup-policies 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の三浦です。当記事では、Google が提供する標準機能を使って、Dropbox から Google ドライブへのデータを移行した検証の結果を紹介します。 概要 Dropbox からのデータ移行とは 前提条件 制約 検証概要 検証環境 検証の流れ 設定手順 [Dropbox] 移行元のチームフォルダ Path の確認（チームフォルダを移行する場合のみ） [Google Workspace] 移行先の共有ドライブ ID の確認（チームフォルダを移行する場合のみ） [Google Workspace] 移行用の CSV の準備 [Google Workspace] データ移行の実施 個人フォルダの移行結果 チームフォルダの移行結果 [Dropbox] 移行後に Dropbox のファイルを追加 [Google Workspace] 差分移行の実施と確認 概要 Dropbox からのデータ移行とは すべての Google Workspace エディションでは、管理機能として Dropbox のデータをフォルダ単位で Google ドライブにコピーして移行する機能が提供されています。また、初回移行後に Dropbox 側で追加・更新されたファイルは、差分移行によって Google ドライブ側へ反映できます。 Dropbox からの移行では、フォルダの種類に応じて移行先が異なります。 Dropbox 側のフォルダ 移行先 個人フォルダ マイドライブ チームフォルダ 共有ドライブまたは共有ドライブ内のフォルダ 参考 : Dropbox から Google ドライブに移行する 参考 : Dropbox のファイル移行で移行されるデータ 前提条件 当機能で移行を実施するには、以下の要件があります。詳細は以下の公式ドキュメントをご確認ください。 Google Workspace 側では 特権管理者ロール が必要です。 Dropbox 側では チーム管理者 権限が必要です。 参考 : Dropbox アカウントからファイルを移行する 制約 当機能には以下のような主な制限があります。 一度に移行可能なフォルダ（個人フォルダまたはチームフォルダ）数は最大 150 移行できるファイル数は 1 ユーザーあたり最大 500,000 外部ユーザー / アプリによって作成されたファイルやフォルダは 移行できない 上記以外の制約については、以下の公式ドキュメントを確認してください。 参考 : Dropbox アカウントからファイルを移行する 参考 : Dropbox のファイル移行で移行されるデータ 検証概要 検証環境 検証環境は以下のとおりです。 プラットフォーム ライセンス Google Workspace Business Starter Dropbox Standard 移行テスト用の Dropbox フォルダおよび移行先の Google ドライブは以下のとおりです。 Dropbox フォルダ名 種類 格納ファイル 移行先 三浦健斗 個人フォルダ test-member.xlsx マイドライブ Dropbox チーム フォルダ チームフォルダ test-team.pptx 共有ドライブ（test-team-drive） 検証の流れ 以下の手順でデータの移行を実施します。 項目 作業 プラットフォーム 1 移行元のチームフォルダ Path の確認（チームフォルダを移行する場合のみ） Dropbox 2 移行先の共有ドライブ ID の確認（チームフォルダを移行する場合のみ） Google Workspace 3 移行用の CSV の準備 Google Workspace 4 データ移行の実施 Google Workspace 5 移行後に Dropbox のファイルを追加 Dropbox 6 差分移行の実施と確認 Google Workspace 設定手順 [Dropbox] 移行元のチームフォルダ Path の確認（チームフォルダを移行する場合のみ） Dropbox 公式ドキュメントに従い、ストレージ レポートをエクスポートします。 参考 : チーム ストレージのレポートを作成する方法 エクスポートした CSV の Path 列の値を控えておきます。 チームフォルダ Path の確認 [Google Workspace] 移行先の共有ドライブ ID の確認（チームフォルダを移行する場合のみ） 共有ドライブの管理画面にアクセスします。 参考 : 共有ドライブを管理する 画面を右にスクロールすることで、共有ドライブ ID が確認できるので、控えておきます。 共有ドライブ ID の確認 [Google Workspace] 移行用の CSV の準備 Google Workspace の管理コンソールにログインします。 参考 : 管理コンソールにログインする [データ] > [データのインポートとエクスポート] > [データ移行（新規）] から Dropbox の [移行] を選択します。 Dropbox の移行を選択 ステップ2の [サンプル CSV をダウンロード] を選択します。 移行用のサンプル CSV のダウンロード ダウンロードした CSV を開き、以下のとおりに入力し、保存します。各列の入力内容は、個人フォルダとチームフォルダで異なります。 列名 個人フォルダの場合 チームフォルダの場合 Source DropboxValue Dropbox ユーザーのメールアドレス チームフォルダ Path（前手順で確認した値） Target Drive FolderID 空欄（未入力） 共有ドライブ ID（前手順で確認した値） Target GUser 空欄（未入力） 共有ドライブの管理者権限を持つユーザーのメールアドレス 以下は検証環境用のサンプルです。データ 1 行目が個人フォルダ、データ 2 行目がチームフォルダの例です。 Source DropboxValue,Target Drive FolderID,Target GUser admin@miurak-test.com,, /Dropbox チーム フォルダ,0AFJq5HIP3tBRUk9PVA,admin@miurak-test.com 参考 : ステップ 2: 移行するフォルダを選択する ステップ3の [サンプル CSV をダウンロード] を選択します。 マッピング用のサンプル CSV のダウンロード ダウンロードした CSV を開き、以下のとおりに入力し、保存します。この CSV では、Dropbox 側のユーザーまたはグループと、Google Workspace 側のユーザーまたは Google グループのメールアドレスをマッピングします。 列名 入力内容 Source Email Dropbox のユーザーまたはグループのメールアドレス Destination Email Google Workspace のユーザーまたは Google グループのメールアドレス 以下は検証環境で使用したサンプルです。 Source Email,Destination Email admin@miurak-test.com,admin@miurak-test.com 参考 : ステップ 3: ID マップを作成してアップロードする [Google Workspace] データ移行の実施 ステップ1の [交流] を選択し、本データ移行ツールへの権限付与内容を確認の上で許可します。 交流を選択 権限の付与 Dropbox テナントの接続確認 ステップ2、ステップ3それぞれの [CSV をアップロード] を選択し、前手順で作成した CSV をアップロードします。 CSV アップロードを選択 アップロード完了確認 ステップ4では、移行時のオプションを設定します。主な設定項目とデフォルト値は以下のとおりです。 項目 デフォルト値 マッピングされていない ID ID マップに含まれていない ID をマッピングする（ID の移行元ドメインを保持） 作成日 / 更新日 作成日や変更日に関係なくすべてのファイルを移行 ファイル形式 すべてのファイル形式を移行 ファイルサイズ サイズに関係なくすべてのファイルを移行 設定を変更する場合は、[設定を変更] を選択して内容を編集し、[変更の保存] を選択します。今回はデフォルト値で設定しました。 移行時のオプション設定 参考 : （省略可）ステップ 4: 移行を設定する [移行を開始] を選択することでデータ移行が開始されます。進行状況は 10 秒ごとに更新されるため、完了まで待ちます。 移行を開始を選択 移行処理中 移行が完了したことを確認します。詳細は [移行レポートをエクスポート] および [フォルダレポートをエクスポート] から確認できます。後続の手順で差分移行を検証するため、この時点では [移行を終了する] を選択しません。 移行完了確認 検証時のフォルダレポート 参考 : Dropbox の移行レポートについて 個人フォルダの移行結果 マイドライブを確認し、Dropbox の個人フォルダからファイルが移行されていることを確認します。 個人フォルダの移行確認 チームフォルダの移行結果 共有ドライブを確認し、チームフォルダ名のフォルダが新規で作成され、その配下にファイルがコピーされていることを確認します。 チームフォルダの移行確認 [Dropbox] 移行後に Dropbox のファイルを追加 データの移行後に、Dropbox の個人フォルダおよびチームフォルダへ新規でファイルをアップロードします。 差分検出用のファイル追加（個人フォルダ） 差分検出用のファイル追加（チームフォルダ） [Google Workspace] 差分移行の実施と確認 [差分移行を実行] を選択します。 差分移行の実行 参考 : Dropbox の差分移行を実行する 移行が成功したことを確認します。 差分移行の完了確認 差分移行時のフォルダレポート Google ドライブを確認し、追加したファイルがコピーされていることを確認します。 差分検出の確認（個人フォルダ） 差分検出の確認（チームフォルダ） 移行が完了したら、[移行を終了する] > [移行を終了して削除] を選択し、移行を終了します。 移行の終了 注意事項として、 すべての移行が完了してから 移行の終了をしてください。移行終了後に同じデータで新規の移行を開始すると、同じファイルの移行が再度実施され Google ドライブ側にファイルが重複する可能性があります。 参考 : （省略可）ステップ 7: 移行を終了する 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。 ネットワーク・セキュリティ・唐揚げ・辛いものが好き。 Google Cloud Partner All Certification Holders 2025 / Google Cloud Partner Top Engineer 2026

G-gen の佐々木です。当記事では、IAM 拒否ポリシーを使用して Google Cloud プロジェクトの削除を防止する方法を解説します。 プロジェクト削除の防止方法 IAM 拒否ポリシー（Deny Policy） リーエン（Lien） 拒否ポリシーとリーエンの比較 拒否ポリシーの設定手順 コンソールの場合 CLI の場合 使用する設定ファイル 組織レベルの拒否ポリシー フォルダレベルの拒否ポリシー プロジェクトレベルの拒否ポリシー Terraform の場合 拒否ポリシーの削除 プロジェクト削除の防止方法 IAM 拒否ポリシー（Deny Policy） 当記事で使用する IAM 拒否ポリシー （Deny Policy、以下「拒否ポリシー」と表記）は、プリンシパル（ユーザーやグループなど）に対して、特定の操作を 明示的に禁止する ためのポリシーです。 拒否ポリシーは IAM による許可よりも優先度が高いため、たとえ IAM ロールによって権限が付与されていても、拒否ポリシーで制限された操作は実行できません。 機能の詳細については以下の記事も参照してください。 blog.g-gen.co.jp リーエン（Lien） プロジェクト削除を防ぐ方法としては、拒否ポリシーのほかに リーエン （Lien）を使用する方法もあります。 リーエンは、Google Cloud プロジェクトに対して ロック をかける仕組みです。リーエンが設定されている間は、たとえプロジェクトの削除権限を持つユーザーであっても、先にリーエンを削除（解除）しない限りプロジェクトを削除することができません。 リーエンを使用してプロジェクト削除を防止する方法については、以下の記事をご一読ください。 blog.g-gen.co.jp 拒否ポリシーとリーエンの比較 拒否ポリシーとリーエンはどちらもプロジェクトの削除を防止することができる機能ですが、以下のような違いがあります。 比較項目 拒否ポリシー リーエン アプローチ プリンシパルの操作に対する明示的な拒否（禁止） リソース（プロジェクト）に対する物理的なロック 適用スコープ 組織、フォルダ、プロジェクト（下位リソースに波及する） プロジェクト単体 例外の許可 可能（特定のプリンシパルをポリシーの適用対象外にできる） 不可（誰であっても、プロジェクトの削除前にリーエンの解除が必要） 最適なユースケース 組織全体や特定の範囲（本番環境など）が 誤操作 や 悪意を持った操作 により削除されることを防ぐ 特定のプロジェクトが 誤操作 により削除されることを防ぐ 組織や特定のフォルダ（本番環境フォルダなど）にある複数のプロジェクトに対して、プロジェクト削除防止のガードレールを敷きたい場合は拒否ポリシーが適しています。一方で、特定のプロジェクトの削除を防ぎたい場合はリーエンが適しています。 また、拒否ポリシー方式は IAM の仕組みによる厳格な禁止であり、クラウドの管理者のみが拒否ポリシーを編集する権限を持つことで、悪意を持った操作を防止することができます。一方のリーエン方式では、例としてプロジェクトのオーナー権限等が奪取されてしまった場合にはリーエン自体が編集されてしまうため、セキュリティ面の強固さは相対的に劣ります。 これらは併用することができるため、まずは拒否ポリシーで全体のガードレールを敷き、管理者等のユーザーだけが例外的にプロジェクトの削除を行えるようにします。その上で、特に重要なプロジェクトに対してリーエンを設定するとよいでしょう。 拒否ポリシーの設定手順 コンソールの場合 Google Cloud コンソールから拒否ポリシーを設定する場合、IAM コンソールの [許可しない] タブから [拒否ポリシーを作成] を選択します。 コンソールから拒否ポリシーを作成する 拒否されたプリンシパル 項目に public:all を入力することで、すべてのプリンシパルを拒否ポリシーの対象とします。また、 例外のプリンシパル 項目には、例外的にプロジェクトの削除を行うことができるプリンシパルを入力します。 そして、プロジェクトの削除を拒否するため、 拒否される権限 項目に cloudresourcemanager.googleapis.com/projects.delete を入力します。 プロジェクトの削除を拒否するポリシーを作成する ポリシーを作成すると、例外として指定したプリンシパル以外は、プロジェクトを削除する権限を付与されていても削除操作を行うことができなくなります。 拒否ポリシーによりプロジェクトの削除が選択できなくなっている CLI の場合 使用する設定ファイル gcloud CLI で拒否ポリシーを設定する場合、ポリシーの内容を記述した JSON ファイルを用意します。 以下はプロジェクトの削除を拒否するポリシーの例です。当記事ではファイル名を deny-project-delete.json とします。 { " displayName ": " Prevent Project Deletion ", " rules ": [ { " denyRule ": { " deniedPrincipals ": [ " principalSet://goog/public:all " ] , " exceptionPrincipals ": [ " principalSet://goog/group/<グループのメールアドレス> ", " principal://goog/subject/<ユーザーのメールアドレス> ", " principal://iam.googleapis.com/projects/-/serviceAccounts/<サービスアカウントのメールアドレス> " ] , " deniedPermissions ": [ " cloudresourcemanager.googleapis.com/projects.delete " ] } } ] } deniedPrincipals には、ポリシーによる拒否の対象となるプリンシパルを指定します。 principalSet://goog/public:all はすべてのプリンシパルを意味します。 exceptionPrincipals には、ポリシーで拒否している操作を例外的に許可するプリンシパルを指定します。 対象とするプリンシパルの記法（指定方法）については以下のドキュメントを参照してください。 参考 : Principal identifiers - Principal identifiers for deny policies deniedPermissions はポリシーによって拒否する権限を指定します。ここではプロジェクトの削除操作を拒否するため、 cloudresourcemanager.googleapis.com/projects.delete を指定します。 拒否ポリシーで使用できる権限（拒否の対象に設定できる操作）については、以下のドキュメントを参照してください。 参考 : Permissions supported in deny policies 組織レベルの拒否ポリシー 組織レベルで拒否ポリシーを設定すると、組織内のすべてのプロジェクトに対してポリシーが適用されます。 ポリシーの作成時に対象組織の ID を指定する必要があります。 # 組織IDを検索してシェル変数に設定する $ ORG_ID = $( gcloud organizations list --format =" value(ID) " --filter =" displayName=<組織の名前> " ) # 組織レベルで拒否ポリシーを適用する $ gcloud iam policies create < 任意のポリシー名 > \ --attachment-point = cloudresourcemanager.googleapis.com/organizations/ ${ORG_ID} \ --kind = denypolicies \ --policy-file = deny-project-delete.json 参考 : gcloud iam policies create フォルダレベルの拒否ポリシー フォルダレベルで拒否ポリシーを設定すると、そのフォルダ内のすべてのプロジェクトに対してポリシーが適用されます。 ポリシーの作成時に対象フォルダの ID を指定する必要がありますが、組織内でフォルダがネストされている場合、ID の取得には少々手間がかかります。 # 組織IDを取得してシェル変数に設定する $ ORG_ID = $( gcloud organizations list --format =" value(ID) " --filter =" displayName=<組織の名前> " ) # 対象のフォルダIDを取得してシェル変数に設定する（組織直下のフォルダの場合） $ FOLDER_ID = $( gcloud resource-manager folders list \ --organization = ${ORG_ID} \ --filter =" displayName=<フォルダの名前> " \ --format =" value(ID) " ) # 親フォルダの中を検索して対象フォルダのIDを取得する（フォルダがネストされている場合） $ FOLDER_ID = $( gcloud resource-manager folders list \ --folder =< 親フォルダのID > \ --filter =" displayName=<親フォルダの名前> " \ --format =" value(ID) " ) # 取得したフォルダIDを使って拒否ポリシーを作成する $ gcloud iam policies create < 任意のポリシー名 > \ --attachment-point = cloudresourcemanager.googleapis.com/folders/ ${FOLDER_ID} \ --kind = denypolicies \ --policy-file = deny-project-delete.json プロジェクトレベルの拒否ポリシー プロジェクトレベルで拒否ポリシーを設定すると、そのプロジェクトに対してのみポリシーが適用されます。 # プロジェクトレベルで拒否ポリシーを適用する $ gcloud iam policies create < 任意のポリシー名 > \ --attachment-point = cloudresourcemanager.googleapis.com/projects/ < プロジェクトID > \ --kind = denypolicies \ --policy-file = deny-project-delete.json Terraform の場合 Terraform を使用して拒否ポリシーを設定することもできます。 以下の例では、フォルダに対してプロジェクト削除を拒否するポリシーを設定します。 # フォルダに対して拒否ポリシーを設定する locals { folder_id = "<フォルダID>" permitted_principals = [ "principalSet://goog/group/<グループのメールアドレス>" , "principal://goog/subject/<ユーザーのメールアドレス>" , "principal://iam.googleapis.com/projects/-/serviceAccounts/<サービスアカウントのメールアドレス>" ] } resource "google_iam_deny_policy" "this" { parent = urlencode ( "cloudresourcemanager.googleapis.com/folders/$ { local.folder_id } " ) name = "prevent-project-deletion" display_name = "Prevent Project Deletion" rules { description = "First rule" deny_rule { denied_principals = [ "principalSet://goog/public:all" ] denied_permissions = [ "cloudresourcemanager.googleapis.com/projects.delete" , ] exception_principals = local.permitted_principals } } } 参考 : google_iam_deny_policy 拒否ポリシーの削除 拒否ポリシーは、コンソールや gcloud CLI で削除することができます。 CLI で拒否ポリシーを削除するには、以下のコマンドを実行します。 # 組織レベルの拒否ポリシーを削除する $ gcloud iam policies delete < 対象のポリシー名 > \ --attachment-point = cloudresourcemanager.googleapis.com/organizations/ < 組織ID > \ --kind = denypolicies # フォルダレベルの拒否ポリシーを削除する $ gcloud iam policies delete < 対象のポリシー名 > \ --attachment-point = cloudresourcemanager.googleapis.com/folders/ < フォルダID > \ --kind = denypolicies # プロジェクトレベルの拒否ポリシーを削除する $ gcloud iam policies delete < 対象のポリシー名 > \ --attachment-point = cloudresourcemanager.googleapis.com/projects/ < プロジェクトID > \ --kind = denypolicies 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

Google アカウントでは、2段階認証として登録した携帯電話の番号が使えなくなったなどの理由で、アカウントからロックアウトされてしまう場合があります。当記事では、アカウントにログインできなくなった場合の解決策と復旧手順を解説します。 アカウントからのロックアウト 別の方法を試す 管理者による対応（Google Workspace の場合） アカウント復旧プロセス（個人アカウントの場合） アカウントからのロックアウト Google アカウントの2段階認証（2要素認証）では、パスワードの入力後に、登録した電話番号への SMS 送信やワンタイムパスワード、またはモバイルアプリへの通知などによって本人確認を行います。 しかし、以下のような理由で2段階目の認証を通過できなくなることがあります。 機種変更や解約により、電話番号が使えなくなった （Google Workspace の場合）アカウントの初期作成後に、2段階認証の登録の猶予期間を過ぎてもユーザーが2段階認証を設定しなかった このような場合には、複数の復旧経路が用意されています。 別の方法を試す ログイン画面でコードの入力を求められた際、まず確認すべきなのが画面下部にある「 別の方法を試す 」または「 ログインできない場合 」というリンクです。 Google は、メインの電話番号が利用できない場合に備え、複数の認証パスを提示することがあります。以下の選択肢が表示されるかを確認してください。 選択肢 操作 信頼済みのデバイス すでにログイン済みの PC やタブレットで「はい」を押す 再設定用メールアドレス 予備として登録した別のアドレスにコードを送信する バックアップコード 事前に保存していた（あるいは管理者から発行される）8桁の使い捨てコードを入力する 参考 : 2 段階認証プロセスに関する一般的な問題を修正する これらの対処手段を使うには、予め Google アカウントに複数の2段階認証手段やメールアドレス、信頼済みデバイスが登録してあること、あるいはバックアップコードが発行済みであることが前提です。 管理者による対応（Google Workspace の場合） 使用しているアカウントが組織向けの Google Workspace アカウントである場合は、組織の特権管理者が管理コンソールから以下の操作を行うことで、ログインさせることができます。 操作 説明 2 段階認証の一時的な無効化 管理者が、2段階認証の設定をオフにした 設定グループ を作成して対象アカウントを一時的に移動するなどする バックアップコードの発行 管理者が8桁の使い捨てコードを管理画面で生成してユーザーに伝える 参考 : 組織によって 2 段階認証プロセスが適用されている場合にアカウントがロックされるのを回避する 参考 : ユーザーのセキュリティ設定を管理する - ユーザーのバックアップ確認コードを取得する 2段階認証を必須している Google Workspace 組織では、新しいユーザー作成直後に2段階認証を設定していなくてもログインできる猶予期間（ 新しいユーザーの登録期間 ）を設定できます。この期間のうちにユーザーが2段階認証をセットアップしないと、アカウントからロックアウトされてしまいます。このようなときにも、上記のような対処が取れます。 アカウント復旧プロセス（個人アカウントの場合） Google Workspace アカウントではなく、個人アカウントの場合、最終手段として アカウント復旧 （Account Recovery）の手続きを行います。 Google アカウント復旧ページ（ https://accounts.google.com/signin/recovery ）にアクセス 復旧したいメールアドレスを入力 画面の指示に従い、本人確認のための質問に回答 このプロセスでは、Google のシステムが「操作している人物が真の所有者であるか」を多角的に判断します。電話番号が間違っていても、過去に使用したパスワードや再設定用メールアドレスの有無によって、復旧が認められる場合があります。 なおアカウント復旧を成功させるためには、Google が所有者を特定しやすい環境で操作することが重要です。 環境 説明 普段と同じ場所 自宅や職場など、いつもログインしている Wi-Fi ネットワークを利用する 普段と同じデバイス 以前そのアカウントでログインに成功したことがある PC やスマートフォンを使用する ブラウザの利用 普段から使い慣れているブラウザ（Chrome など）を使用する 参考 : Google アカウントや Gmail を復元する方法 参考 : アカウント復元手順を完了するためのヒント G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、2021年よりクラウドの導入から最適化までを支援しているGoogle Cloud専業のクラウドインテグレーターです。

G-gen の堂原です。当記事では、Google Workspace の 共有ドライブ において、ファイルやフォルダが 組織外へ共有されてしまうことを防ぐ 方法を紹介します。「アクセスレベルによる制限」、「共有ドライブレベルでの制限」そして「管理コンソールを用いた組織部門レベルでの制限」の3手法を解説します。 はじめに アクセスレベルによる制限 共有ドライブレベルでの制限 組織部門レベルでの制限 はじめに 共有ドライブ は Google ドライブの機能であり、チームでファイルを保存、検索、アクセスすることができます。ファイルごと、またはフォルダごとん、組織内部のメンバーはもちろん、組織外部のメンバーに対してもアクセス権限を付与することができます。 参考 : 共有ドライブとは 共有ドライブのファイルやフォルダは、簡単な手順で他人に共有することができます。それゆえに、意図しない情報漏洩を防ぐためには、外部のメンバーに対する共有設定を適切にコントロールする必要があります。 参考 : Googleドライブの「やってはいけない」。ファイルをインターネット公開しない設定 - G-gen Tech Blog 当記事では、共有ドライブの外部共有を制限する以下の3つの方法を紹介します。 アクセスレベルによる制限 共有ドライブレベルでの制限 管理コンソールを用いた組織部門レベルでの制限 これらの手法のうち、1つ目が最も手軽に設定でき、3つ目が最も詳細に設定できます。 アクセスレベルによる制限 共有ドライブ内のファイルやフォルダをユーザーやグループに共有するためには、操作を行うユーザーが、対象となるファイルやフォルダに対して適切な アクセスレベル （アクセス権限）を持っている必要があります。必要最低限のアクセスレベルを付与することで、不用意な外部共有を防ぐことができます。 ファイルとフォルダで、共有操作に必要なアクセスレベルは異なります。 ファイルを共有する場合 : 「管理者」、「コンテンツ管理者」、「投稿者」のいずれかが必要 フォルダを共有する場合 : 「管理者」、「コンテンツ管理者」のいずれかが必要 さらに、フォルダの共有に関しては、共有ドライブの設定で、コンテンツ管理者による共有操作を禁止することができます。 共有ドライブの画面において、ページ上部の共有ドライブ名をクリック ドロップダウンメニューが表示されるので、「共有ドライブの設定」をクリック 3.「コンテンツ管理者にフォルダの共有を許可する」のチェックを外す なお、上記の状態でコンテンツ管理者が共有操作をしようとすると、管理者に対して以下のようなリクエストメールが送信されます。 参考 : 共有ドライブのファイルへのアクセスの仕組み - Google Workspace ラーニング センター 共有ドライブレベルでの制限 共有ドライブの設定を変更することで、その共有ドライブにおける外部共有を一律で制御できます。 共有ドライブの画面において、ページ上部の共有ドライブ名をクリック ドロップダウンメニューが表示されるので、「共有ドライブの設定」をクリック 3.「（Google Workspace アカウント名）外のユーザーにファイルへのアクセスを許可する」のチェックを外す 組織部門レベルでの制限 共有ドライブは、Google Workspace のいずれかの 組織部門 に必ず所属します。デフォルトでは最上位の組織部門に属していますが、管理コンソールから任意の組織部門に移動させることができます。 3つ目の方法として、共有ドライブが所属する組織部門レベルの設定で、外部共有を制限することができます。 管理コンソール（ https://admin.google.com/ ）にログイン 左のサイドバーの「アプリ」をクリック 「Google Workspace」をクリック 「ドライブとドキュメント」をクリック 「ドライブとドキュメントの設定」に遷移するため、設定項目にある「共有設定」をクリック 6.共有ドライブが所属する組織部門を選択 7.「共有オプション」をクリック 8.「（Google Workspace アカウント名）の外部との共有」から、設定したい項目を選択 ここで選択できるオプションは以下のとおりです。 オフ : 外部との共有を一律で制限する 許可リスト登録済みドメイン : 管理コンソールで事前に設定した、許可されたドメインのユーザーにのみ共有を許可する オン : 外部との共有を制限しない この設定には継承の概念があり、親の組織部門で設定された内容は子の組織部門にも反映されます。この設定は、子の組織部門で上書きすることも可能です。 参考 : 組織の外部共有を管理する - Google Workspace 管理者 ヘルプ 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。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 カレンダー の異なる予定で、同じ Google Meet の会議 URL を使用する方法について解説します。 はじめに 手順1 : 既存の会議コードを取得 手順2 : 複製先予定にビデオ会議を追加 手順3 : 複製先のビデオ会議を既存の会議コードで上書き はじめに Google カレンダー では、予定に Google Meet のビデオ会議を紐づけることができます。 また、Google カレンダーでは予定を複製することができます。例えば、定例会議など同じメンバーでの会議が週2回で行われる場合、1つ目の予定を複製して2つ目の予定を作るなどといった使い方ができます。 しかし、既存の予定を複製して新しい予定を作成した場合、 既存の予定に紐づけられていた Google Meet ビデオ会議が引き継がれません 。「Google Meet のビデオ会議を追加」を押すと、全く新しいビデオ会議の URL が払い出させれます。 なお、これは2025年9月に行われた機能改修によるものであり、これ以前では、カレンダー予定を複製すると同じビデオ会議 URL が引き継がれていました。2026年2月現在では、セキュリテイ上の理由でこの仕様が変更され、URL が引き継がれなくなりました。 参考 : Google Workspace Updates: Enhancing meeting privacy for copied Calendar events 当記事では、既存の予定に紐づけられていた Google Meet ビデオ会議を、複製した予定にも紐づける方法を紹介します。 なお当記事では Google Workspace アカウントを利用した場合の仕様について解説しており、個人アカウントでは仕様が異なる可能性があります。 手順1 : 既存の会議コードを取得 まずは既存の予定に紐づけられているビデオ会議の会議コードを取得します。会議コードは URL の後半部分となります。例えば https://meet.google.com/abc-defg-hij であれば、会議コードは「abc-defg-hij」となります。 手順2 : 複製先予定にビデオ会議を追加 次に、複製先の予定編集画面で、いったんビデオ会議を新規に作成します。編集画面で「Google Meet のビデオ会議を追加」を押します。この時点では、複製元の予定とは異なるビデオ会議が紐づけられます。 手順3 : 複製先のビデオ会議を既存の会議コードで上書き 次に複製先の予定編集画面で、会議コードを編集します。下図を参考に「Google Meet に参加する」ブロックの右端にある下矢印をクリックし、会議の詳細を表示します。続けて「ミーティング コード」の鉛筆マークをクリックすることで、会議コードを編集することができます。 編集欄で、「手順1」で取得した会議コードを入力することで、ビデオ会議を既存の会議コードで上書きすることができます。 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の佐々木です。当記事では、MacOS が搭載する Apple Silicon のような ARM64 ベースの環境でビルドしたコンテナイメージを Cloud Run にデプロイしたときに発生するエラーについて解説します。 事象 原因 対処法 docker コマンドを使用する方法 Cloud Build を使用する方法 事象 以下のように、ARM64 ベースの環境で docker build コマンドを使用して、アプリケーションをビルドします。 # アーキテクチャ確認 $ uname -m arm64 # コンテナイメージをビルド・プッシュ $ docker build -t < Artifact Registryのパス > / < イメージ名 > : < タグ > . $ docker push < Artifact Registryのパス > / < イメージ名 > : < タグ > その後、コンソールや gcloud CLI を使用して Cloud Run サービスへのデプロイを試みました。すると、以下のエラーメッセージが出力され、デプロイが失敗しました。 Cloud Run does not support image '{Artifact Registry内のコンテナイメージのパス}': Container manifest type 'application/vnd.oci.image.index.v1+json' must support amd64/linux. Cloud Run のデプロイに失敗する 原因 Cloud Run は、実行するコンテナイメージとして、 x86_64（amd64）アーキテクチャ のコンテナイメージを想定しています。 docker build コマンドは、デフォルトではホストマシンの CPU アーキテクチャに合わせたコンテナイメージを生成します。そのため、Arm ベースのプロセッサを搭載した Mac 環境などで、何も指定せずに docker build を実行すると、 ホストマシンの CPU アーキテクチャ（ARM64）に合わせた コンテナイメージが作成されます。 このような ARM64 向けにビルドされたイメージを Cloud Run へデプロイしようとすると、アーキテクチャの不一致により、前述のエラーメッセージが表示されてデプロイに失敗します。 参考 : コンテナ ランタイムの契約 - サポートされる言語とイメージ 対処法 docker コマンドを使用する方法 docker コマンドを使用してローカル PC 上でコンテナイメージをビルドしたい場合、以下のように --platform オプションで CPU アーキテクチャを指定してビルドを実行します。 # docker コマンドを使用して Cloud Run 用のコンテナイメージをビルドする $ docker build --platform linux/amd64 -t < Artifact Registryのパス > / < イメージ名 > : < タグ > . $ docker push < Artifact Registryのパス > / < イメージ名 > : < タグ > 参考 : ソースをコンテナにビルドする - Dockerfile を使用してビルドする - ローカルにビルドして Docker で push する Cloud Build を使用する方法 Google Cloud のサーバーレス CI/CD サービスである Cloud Build を使うと、クラウド上のフルマネージドのビルド環境でコンテナイメージをビルドすることができます。 Cloud Build を使用する場合、開発者ごとの環境の差異を考慮することなく、同一の環境でビルドを行うことができるメリットがあります。 gcloud CLI の gcloud builds submit コマンドを使用することで、Cloud Build を使用してビルドとプッシュを一括で行うことができます。 # Cloud Build を使用して Google Cloud のビルド環境でコンテナイメージをビルドする $ gcloud builds submit --tag < Artifact Registryのパス > / < イメージ名 > : < タグ > 参考 : Cloud Build の概要 参考 : ソースをコンテナにビルドする - Dockerfile を使用してビルドする - Cloud Build を使用してビルドする 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の片岩です。当記事では Vertex AI Custom Training において カスタムコンテナ を使用し、標準では提供されていない LightGBM モデルの学習から 寄与度（SHAP）の出力 まで実行する方法を紹介します。 はじめに ビルド済みコンテナとカスタムコンテナの使い分け カスタムコンテナの利点 構成図 初期設定 データの準備と分割 カスタムコンテナの準備 ディレクトリとリポジトリの準備 学習スクリプトの作成 Dockerfile の作成 コンテナのビルドとプッシュ 学習ジョブの実行 推論と評価指標の確認 分析レポートの解釈 はじめに ビルド済みコンテナとカスタムコンテナの使い分け Vertex AI Custom Training には学習ジョブを実行するためのコンテナイメージとして、大きく 2 つの選択肢があります。 コンテナの種類 特徴 向いているケース ビルド済みコンテナ Google Cloud が用意したイメージ XGBoost や TensorFlow など、標準的なフレームワークをすぐに使いたい時 カスタムコンテナ 自分で Dockerfile を書いて作成するイメージ LightGBM など未提供のライブラリを使いたい時や、独自の処理を組み込みたい時 カスタムコンテナの利点 ビルド済みコンテナでもジョブ実行時の引数に requirements=["lightgbm", "shap"] のように指定することでライブラリを追加できます。ビルド済みコンテナについては以下の記事を参照してください。 blog.g-gen.co.jp しかし実務の本番運用において、実行時にライブラリを動的にインストールすることは、以下のデメリットがあります。 1 点目は、 環境の再現性が低下する ことです。 ジョブを実行するたびにインターネットから最新のパッケージを取得するため、依存ライブラリのバージョンが上がったために突然ジョブが落ちたり、学習結果が変わってしまうといった、本番運用で避けたいリスクを招きます。 2 点目は、 実行のたびにオーバーヘッドが発生する ことです。 毎回ライブラリをダウンロードしてインストールする処理が走るため、余計な待ち時間が発生します。 カスタムコンテナを利用することにより、上記のデメリットを回避できます。 参考 : カスタム コンテナの概要 構成図 当記事で紹介する手順に関する構成図は以下のとおりです。環境構築の負荷を軽減するため、ソースコードの作成や Python 実行環境に Colab Enterprise を使用します。 初期設定 はじめにライブラリのインストールと環境変数の設定を行います。今回は可視化や解釈のためのライブラリ（ seaborn 、 shap ）も追加します。 # 必要なライブラリのインストール !pip install google-cloud-aiplatform lightgbm shap scikit-learn pandas seaborn matplotlib -q # プロジェクトとリージョンの設定 # ※ ご自身の環境に合わせて書き換えてください PROJECT_ID = "your-project-id" LOCATION = "asia-northeast1" # バケットとフォルダの定義 ROOT_BUCKET = "gs://your-bucket" EXPERIMENT_NAME = "diamonds-lgbm-v1" WORK_DIR = f "{ROOT_BUCKET}/{EXPERIMENT_NAME}" # Vertex AI SDK の初期化 from google.cloud import aiplatform aiplatform.init(project=PROJECT_ID, location=LOCATION, staging_bucket=WORK_DIR) # バケットが存在しない場合のみ作成 !gsutil mb -l {LOCATION} {ROOT_BUCKET} データの準備と分割 データは機械学習デモで使用されるダイヤモンドの価格データを使用します。このデータはカラットなどの数値データや、カットや色といったカテゴリ変数を含みます。 学習データと推論データに分割して Cloud Storage に保存します。 import seaborn as sns from sklearn.model_selection import train_test_split import pandas as pd # データのロード (~54,000行) df = sns.load_dataset( 'diamonds' ) # 文字列カラムを 'category' 型に変換 cat_cols = [ 'cut' , 'color' , 'clarity' ] for col in cat_cols: df[col] = df[col].astype( 'category' ) # 学習データと推論データに 90:10 の割合で分割 train_full_df, test_df = train_test_split(df, test_size= 0.1 , random_state= 42 ) # データの保存 train_filename = "train.csv" train_full_df.to_csv(train_filename, index= False ) test_filename = "test.csv" test_df.to_csv(test_filename, index= False ) # GCS へアップロード !gsutil cp {train_filename} {WORK_DIR}/data/{train_filename} !gsutil cp {test_filename} {WORK_DIR}/data/{test_filename} print (f "学習データ: {WORK_DIR}/data/{train_filename}" ) print (f "推論データ: {WORK_DIR}/data/{test_filename}" ) カスタムコンテナの準備 ディレクトリとリポジトリの準備 Colab Enterprise 上に作業ディレクトリを用意し、Google Cloud 上に完成したコンテナの保存先となる Artifact Registry のリポジトリを作成します。 # 作業用ディレクトリの作成 !mkdir -p custom_container # Artifact Registry にリポジトリを作成 (初回のみ) !gcloud artifacts repositories create custom-training-repo \ --repository- format =docker \ --location={LOCATION} \ --description= "Custom Training Repository" || true 学習スクリプトの作成 コンテナ内で実行される task.py を作成します。 今回はモデルの学習だけでなく、過学習を確認するための学習曲線と、予測の根拠を説明するための寄与度の画像を生成し、モデルと一緒に Cloud Storage へアップロードする処理を組み込みます。 %%writefile custom_container/task.py import argparse import os import pandas as pd import lightgbm as lgb import shap import matplotlib.pyplot as plt from sklearn.model_selection import train_test_split from google.cloud import storage from urllib.parse import urlparse import warnings warnings.filterwarnings( 'ignore' ) parser = argparse.ArgumentParser() parser.add_argument( '--train-data-uri' , dest= 'train_data_uri' , type = str , required= True ) args = parser.parse_args() # --- GCS ダウンロード / アップロード用の関数 --- def download_from_gcs (gcs_uri, local_file): parsed_url = urlparse(gcs_uri) client = storage.Client() bucket = client.bucket(parsed_url.netloc) blob = bucket.blob(parsed_url.path.lstrip( "/" )) blob.download_to_filename(local_file) def upload_to_gcs (local_file, gcs_dir): parsed_url = urlparse(gcs_dir) client = storage.Client() bucket = client.bucket(parsed_url.netloc) blob_path = f "{parsed_url.path.lstrip('/').rstrip('/')}/{local_file}" bucket.blob(blob_path).upload_from_filename(local_file) # --- 1. データの準備 --- print (f "Downloading data from {args.train_data_uri}..." , flush= True ) local_train_file = "train.csv" download_from_gcs(args.train_data_uri, local_train_file) df = pd.read_csv(local_train_file) cat_cols = [ 'cut' , 'color' , 'clarity' ] for col in cat_cols: df[col] = df[col].astype( 'category' ) X = df.drop(columns=[ "price" ]) y = df[ "price" ] # スクリプト内で学習用と検証用に分割 (データリーク防止) X_train, X_val, y_train, y_val = train_test_split(X, y, test_size= 0.1 , random_state= 42 ) # --- 2. モデルの学習 --- print ( "Training LightGBM model..." , flush= True ) model = lgb.LGBMRegressor(n_estimators= 100 , random_state= 42 ) # 学習過程を記録するために eval_set を渡す model.fit( X_train, y_train, eval_set=[(X_train, y_train), (X_val, y_val)], eval_names=[ 'train' , 'valid' ] ) # --- 3. 分析画像の生成と保存 --- # ① 学習曲線の描画 lgb.plot_metric(model, metric= 'l2' ) plt.title( 'Learning Curve (MSE)' ) plt.tight_layout() plt.savefig( "learning_curve.png" ) plt.close() # ② SHAP値（寄与度）の描画 print ( "Calculating SHAP values..." , flush= True ) explainer = shap.TreeExplainer(model) shap_values = explainer(X_val.sample( min ( 1000 , len (X_val)), random_state= 42 )) plt.figure() shap.plots.beeswarm(shap_values, show= False ) plt.title( "SHAP Feature Importance" ) plt.tight_layout() plt.savefig( "shap_importance.png" ) plt.close() # --- 4. 成果物のアップロード --- aip_model_dir = os.getenv( "AIP_MODEL_DIR" ) if aip_model_dir: print (f "Uploading artifacts to: {aip_model_dir}" , flush= True ) model.booster_.save_model( "model.txt" ) upload_to_gcs( "model.txt" , aip_model_dir) upload_to_gcs( "learning_curve.png" , aip_model_dir) upload_to_gcs( "shap_importance.png" , aip_model_dir) print ( "Upload completed." , flush= True ) Dockerfile の作成 Dockerfile を記述します。ベースイメージには Python 3.12 を指定し、LightGBM に必要な libgomp1 をインストールします。 %%writefile custom_container/Dockerfile FROM python: 3.12 -slim # LightGBM に必須の OS ライブラリをインストール RUN apt-get update && apt-get install -y --no-install-recommends \ libgomp1 \ && rm -rf /var/lib/apt/lists/* # 必要な Python ライブラリのインストール RUN pip install --no-cache- dir \ pandas scikit-learn lightgbm shap matplotlib google-cloud-storage WORKDIR /app COPY task.py /app/task.py ENTRYPOINT [ "python" , "task.py" ] コンテナのビルドとプッシュ Cloud Build を使用してコンテナをビルドし、プッシュします。 # Cloud Build でビルドとプッシュを実行 REPO_NAME = "custom-training-repo" IMAGE_URI = f "{LOCATION}-docker.pkg.dev/{PROJECT_ID}/{REPO_NAME}/lgbm-shap-trainer:latest" !gcloud builds submit --tag {IMAGE_URI} ./custom_container 学習ジョブの実行 作成した自作コンテナ ( IMAGE_URI ) を指定して、学習ジョブを送信します。引数 base_output_dir を指定することで、指定した Cloud Storage のパス配下にモデルや画像を保存できます。 # ジョブの定義 job = aiplatform.CustomContainerTrainingJob( display_name= "diamonds-lgbm-shap-job" , container_uri=IMAGE_URI, ) # ジョブの実行 print ( "ジョブを送信しました。完了までお待ちください..." ) job.run( machine_type= "n1-standard-4" , replica_count= 1 , args=[ f "--train-data-uri={WORK_DIR}/data/train.csv" ], # 成果物の保存先フォルダを指定 base_output_dir=f "{WORK_DIR}/model_output" ) 推論と評価指標の確認 ジョブ完了後、Cloud Storage から学習済みモデルをダウンロードし、Colab Enterprise 上でテストデータに対する精度評価を行います。 import numpy as np import lightgbm as lgb from sklearn.metrics import r2_score, mean_squared_error import pandas as pd # 1. 学習の成果物のダウンロード MODEL_DIR = f "{WORK_DIR}/model_output/model" print ( "学習済みモデルと分析画像をダウンロードします..." ) !gsutil cp {MODEL_DIR}/model.txt . !gsutil cp {MODEL_DIR}/learning_curve.png . !gsutil cp {MODEL_DIR}/shap_importance.png . # 2. テストデータの読み込み df_test = pd.read_csv(f "{WORK_DIR}/data/test.csv" ) cat_cols = [ 'cut' , 'color' , 'clarity' ] for col in cat_cols: df_test[col] = df_test[col].astype( 'category' ) X_test = df_test.drop(columns=[ "price" ]) y_true = df_test[ "price" ] # 3. ローカル推論の実行 local_model = lgb.Booster(model_file= "model.txt" ) predictions = local_model.predict(X_test) # 4. 評価指標の計算と表示 r2 = r2_score(y_true, predictions) rmse = np.sqrt(mean_squared_error(y_true, predictions)) print ( "-" * 30 ) print (f "評価結果 (データ数: {len(y_true)}件)" ) print (f "R2 Score (決定係数): {r2:.4f}" ) print (f "RMSE (誤差の大きさ): {rmse:.4f}" ) print ( "-" * 30 ) 以下は筆者の環境における実行結果です。R2スコアが 0.98 を超える精度の高いモデルが作成できました。 ------------------------------ 評価結果 (データ数: 5394件) R2 Score (決定係数): 0.9817 RMSE (誤差の大きさ): 543.6218 ------------------------------ 分析レポートの解釈 単に予測精度を出すだけでなく、AI が なぜその予測をしたのか を解釈することは実務において重要です。コンテナ内で生成した学習曲線の画像と SHAP を用いた個別データの分析結果を確認します。 import shap from IPython.display import Image, display print ( "=== 学習曲線 (過学習の確認) ===" ) display(Image( "learning_curve.png" )) print ( " \n === 全体の寄与度 (SHAP Beeswarm) ===" ) display(Image( "shap_importance.png" )) # --- 個別データに対するSHAP（表形式）--- print ( " \n === 特定のデータ（1件目）の予測の根拠 ===" ) explainer = shap.TreeExplainer(local_model) single_instance = X_test.iloc[[ 0 ]] shap_values_single = explainer(single_instance) shap_df = pd.DataFrame({ "特徴量 (Feature)" : single_instance.columns, "実際の値 (Value)" : single_instance.values[ 0 ], "価格への影響 (SHAP値)" : shap_values_single.values[ 0 ] }) shap_df = shap_df.reindex(shap_df[ "価格への影響 (SHAP値)" ].abs().sort_values(ascending= False ).index) base_value = explainer.expected_value predicted_price = predictions[ 0 ] print (f "【ベースライン価格 (平均)】: {base_value:.2f}" ) display(shap_df.style.format({ "価格への影響 (SHAP値)" : "{:+.2f}" }).hide(axis= "index" )) print (f "【最終予測価格】: {predicted_price:.2f}" ) 学習曲線（Learning Curve） を確認すると、学習データと検証データの誤差（MSE）が共に右肩下がりで収束しています。 これは、未知のデータである検証データに対しても過学習を起こすことなく学習ができている証拠です。 全体の寄与度 では、上にある特徴量ほど予測への影響力が大きいことを示しています。横軸の 0 を基準に、右側が 価格を上げる要因 、左側が 価格を下げる要因 です。 プロットの赤色は数値が大きいデータであり、青色は数値の小さいデータを表しています。例えば carat は右側に赤色でプロットされているため、 carat が大きいほど高価になる ことが分かります。 最後に 特定の1件に対する予測の根拠 を表形式で出力しました。 全体の平均価格（ベースライン）を基準として、「重さが0.24カラットと小さいためマイナス評価」「透明度（clarity）がVVS1と高品質であるためプラス評価」といったように、最終的な予測価格に至るまでの内部の計算ロジックをビジネス部門に説明できます。 片岩 裕貴 (記事一覧) クラウドソリューション部 クラウドディベロッパー課 和歌山県在住のエンジニア。興味分野はAI/ML。Google Cloud Partner Top Engineer に選出（2025 / 2026）。

G-gen の片岩です。当記事では Vertex AI Custom Training を使用して、機械学習モデルのトレーニングから推論まで実行する方法を紹介します。Vertex AI Custom Training を使うことで、クラウド上のフルマネージド環境で機械学習モデルをトレーニングできます。 はじめに 機械学習モデルのトレーニング手法 Vertex AI Custom Training とは 構成図 初期設定 データの準備と分割 学習スクリプトの作成 学習ジョブの実行 推論の実行 推論結果の確認 はじめに 機械学習モデルのトレーニング手法 Google Cloud のマネージドサービスを使って機械学習モデルをトレーニングする方法は、大きく分けて3つあります。 手法 向いているケース Vertex AI AutoML データを用意するだけで、少ない手順でモデルをトレーニングしたい時 BigQuery ML BigQuery のデータを使用して SQL でモデルをトレーニングしたい時 Vertex AI Custom Training モデルの開発環境や工程を細かく制御したい時 当記事では、最も柔軟性の高い Vertex AI Custom Training に焦点を当て、モデルのトレーニングおよび推論を実行する方法をご紹介します。 Vertex AI についての解説、Vertex AI AutoML や BigQuery ML についての詳細は以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp Vertex AI Custom Training とは Vertex AI Custom Training は、PyTorch、TensorFlow、Scikit-learn や XGBoost といったフレームワークを実行できるフルマネージドサービスです。 ローカルで開発した Python コードを Docker コンテナとして実行するため、サーバーの起動や停止といったインフラ管理を意識せず、 コードの自由度 と クラウドのスケーラビリティ を両立できます。 AutoML では対応しきれない細かいチューニングや、独自のアルゴリズムを実装したいエンジニアにとって、有用な選択肢です。 参考 : カスタム トレーニングの初心者向けガイド 構成図 当記事で紹介する手順に関する構成図は、以下のとおりです。環境構築の負荷を軽減するため、ソースコードの作成や Python 実行環境に Colab Enterprise を使用します。 Colab Enterprise については以下の記事を参照してください。 blog.g-gen.co.jp 初期設定 はじめに、ライブラリのインストールと環境変数の設定を行います。 今後、別のモデルを作成する時にバケットを使い回せるようにするため、Cloud Storage はバケットの中にディレクトリを作成します。 # 必要なライブラリのインストール !pip install google-cloud-aiplatform xgboost scikit-learn pandas -q # プロジェクトとリージョンの設定 # ※ ご自身の環境に合わせて書き換えてください PROJECT_ID = "your-project-id" LOCATION = "asia-northeast1" # バケットとフォルダの定義 ROOT_BUCKET = "gs://your-bucket" EXPERIMENT_NAME = "california-housing-xgb-v1" WORK_DIR = f "{ROOT_BUCKET}/{EXPERIMENT_NAME}" # Vertex AI SDK の初期化 from google.cloud import aiplatform # staging_bucket を指定すると、自動生成されるファイルもこのフォルダに整理されます aiplatform.init(project=PROJECT_ID, location=LOCATION, staging_bucket=WORK_DIR) # バケットが存在しない場合のみ作成 !gsutil mb -l {LOCATION} {ROOT_BUCKET} データの準備と分割 データは機械学習デモにしばしば使用される California Housing（カリフォルニアの住宅価格）を使用します。このデータセットは、scikit-learn に含まれています。 モデルの作成に使用する学習データと推論に使用する推論データに分割し、Cloud Storage に保存します。 from sklearn.datasets import fetch_california_housing from sklearn.model_selection import train_test_split import pandas as pd # データのロード data = fetch_california_housing(as_frame= True ) df = data.frame # 学習データと推論データに 90:10 の割合で分割 train_full_df, test_df = train_test_split(df, test_size= 0.1 , random_state= 42 ) # 学習データの保存 train_filename = "train.csv" train_full_df.to_csv(train_filename, index= False ) # 推論データの保存 test_filename = "test.csv" test_df.to_csv(test_filename, index= False ) # GCS へアップロード (フォルダ /data 配下へ) !gsutil cp {train_filename} {WORK_DIR}/data/{train_filename} !gsutil cp {test_filename} {WORK_DIR}/data/{test_filename} print (f "学習データ: {WORK_DIR}/data/{train_filename}" ) print (f "推論データ: {WORK_DIR}/data/{test_filename}" ) 学習スクリプトの作成 Vertex AI Custom Training として実行する Python スクリプトを作成します。今回は機械学習アルゴリズムに XGBoost を採用します。 環境変数 AIP_MODEL_DIR で与えられた Cloud Storage に作成したモデルを保存すると、自動的に Vertex AI Model Registry にアップロードされます。 %%writefile task.py import argparse import pandas as pd import xgboost as xgb from sklearn.model_selection import train_test_split from sklearn.metrics import mean_squared_error import os from google.cloud import storage from urllib.parse import urlparse # 引数の受け取り parser = argparse.ArgumentParser() parser.add_argument( '--train-data-uri' , dest= 'train_data_uri' , type = str , required= True ) args = parser.parse_args() # GCS から学習用データセットをダウンロード parsed_url = urlparse(args.train_data_uri) bucket_name = parsed_url.netloc blob_path = parsed_url.path.lstrip( "/" ) local_filename = "downloaded_train.csv" client = storage.Client() bucket = client.bucket(bucket_name) blob = bucket.blob(blob_path) print (f "Downloading training data from: {args.train_data_uri}" , flush= True ) blob.download_to_filename(local_filename) # 学習用データセットを読み込む df = pd.read_csv(args.train_data_uri) # 特徴量とターゲットに分離し、Numpy Array に変換 target_col = "MedHouseVal" X = df.drop(columns=[target_col]).values y = df[target_col].values # トレーニングに必要な学習データと評価データに分割する X_train, X_val, y_train, y_val = train_test_split(X, y, test_size= 0.1 , random_state= 42 ) # XGBoost モデルの構築と学習 model = xgb.XGBRegressor( n_estimators= 100 , learning_rate= 0.1 , max_depth= 5 , random_state= 42 , objective= 'reg:squarederror' ) model.fit( X_train, y_train, eval_set=[(X_val, y_val)], verbose= True ) # 評価スコアを Cloud Logging に出力する score = model.score(X_val, y_val) mse = mean_squared_error(y_val, model.predict(X_val)) print (f "Validation Score (R^2): {score:.4f}" , flush= True ) print (f "Validation MSE: {mse:.4f}" , flush= True ) # モデルの保存 model_filename = "model.bst" model.save_model(model_filename) aip_model_dir = os.getenv( "AIP_MODEL_DIR" ) if aip_model_dir: print (f "Uploading model to: {aip_model_dir}" , flush= True ) parsed_url = urlparse(aip_model_dir) bucket_name = parsed_url.netloc blob_path = parsed_url.path.lstrip( "/" ).rstrip( "/" ) + "/" + model_filename # Cloud Storage にアップロード bucket = client.bucket(bucket_name) blob = bucket.blob(blob_path) blob.upload_from_filename(model_filename) print ( "Model upload completed." , flush= True ) 学習ジョブの実行 作成したスクリプトをコンテナで実行します。今回は Google Cloud が 提供するビルド済みコンテナを使用するため、Dockerfile の作成は不要です。 また、軽量なモデルのため n1-standard-4 マシンタイプを使用しますが、巨大なモデルをトレーニングしたい場合は GPU を使用することで高速に処理できます。 # ジョブの定義 job = aiplatform.CustomTrainingJob( display_name= "california-housing-xgb-job" , script_path= "task.py" , container_uri= "asia-docker.pkg.dev/vertex-ai/training/xgboost-cpu.2-1:latest" , requirements=[ "pandas" , "google-cloud-storage" ], staging_bucket=WORK_DIR, model_serving_container_image_uri= "asia-docker.pkg.dev/vertex-ai/prediction/xgboost-cpu.2-1:latest" ) # ジョブの実行 print ( "ジョブを送信しました。完了まで5分ほどお待ちください..." ) model = job.run( machine_type= "n1-standard-4" , replica_count= 1 , model_display_name= "california-housing-xgb-model" , # GCS上の学習データパスを引数で渡す args=[f "--train-data-uri={WORK_DIR}/data/train.csv" ] ) ジョブ終了後に Cloud Storage にモデルが保存されていることを確認できます。 Google Cloud コンソールの モデルレジストリの画面でモデルが作成されていることを確認できます。 推論の実行 本番運用では Vertex AI に備わっているオンライン推論やバッチ推論を使用して大量のリクエストを捌きますが、ここでは Colab Enterprise の実行環境上で推論を実行します。 # --------------------------------------- import xgboost as xgb import pandas as pd import matplotlib.pyplot as plt # --- モデルの場所 --- model_gcs_uri = model.uri # GCSのパスを直接指定する場合 # model_gcs_uri = WORK_DIR + "/aiplatform-custom-training-xxxxx/model" print (f "参照モデル: {model_gcs_uri}" ) # 推論データのダウンロード !gsutil cp {model_gcs_uri}/model.bst . !gsutil cp {WORK_DIR}/data/test.csv . print ( "ダウンロード完了。推論を開始します..." ) # モデルの読み込み local_model = xgb.XGBRegressor() local_model.load_model( "model.bst" ) # データの読み込み df_test = pd.read_csv( "test.csv" ) # 推論用に「正解列」を削除したデータフレームを作ります target_col = "MedHouseVal" X_test = df_test.drop(columns=[target_col]) # 推論の実行 # .values をつけて数値行列として渡します predictions = local_model.predict(X_test.values) # --- 結果の表示 --- print ( " \n === 推論結果 (最初の10件) ===" ) for i, pred in enumerate (predictions[: 10 ]): print (f "データ{i}: 予測価格 {pred:.4f}" ) 推論結果の確認 最後に予測結果と正解データを照合して評価指標を計算し散布図を描画します。 from sklearn.metrics import r2_score, mean_squared_error import numpy as np # 正解データの抽出 y_true = df_test[ "MedHouseVal" ] # 精度評価 (答え合わせ) r2 = r2_score(y_true, predictions) rmse = np.sqrt(mean_squared_error(y_true, predictions)) print ( "-" * 30 ) print (f "評価結果 (データ数: {len(y_true)}件)" ) print (f "R2 Score (決定係数): {r2:.4f}" ) print (f "RMSE (誤差の大きさ): {rmse:.4f}" ) print ( "-" * 30 ) # 結果の可視化 (散布図) plt.figure(figsize=( 8 , 8 )) plt.scatter(y_true, predictions, alpha= 0.5 , color= 'blue' , label= 'Predictions' ) # 理想線 (y=x) min_val = min (y_true.min(), predictions.min()) max_val = max (y_true.max(), predictions.max()) plt.plot([min_val, max_val], [min_val, max_val], 'r--' , label= 'Ideal Fit' ) plt.title(f "Actual vs Predicted (R2: {r2:.3f})" ) plt.xlabel( "Actual Price" ) plt.ylabel( "Predicted Price" ) plt.legend() plt.grid( True ) plt.show() 片岩 裕貴 (記事一覧) クラウドソリューション部 クラウドディベロッパー課 和歌山県在住のエンジニア。興味分野はAI/ML。Google Cloud Partner Top Engineer に選出（2025 / 2026）。

G-gen の三浦です。当記事では、 Google Workspace CLI と、Google が提供する生成 AI CLI ツールである Gemini CLI を組み合わせて、Google Workspace の管理操作を自然言語で行いました。 概要 Gemini CLI とは Google Workspace CLI とは 検証の流れ Google Workspace CLI のセットアップ インストールと初期設定 OAuth 同意設定（Step A） OAuth クライアント作成（Step B） セットアップ完了 CLI の認証 Gemini CLI の設定 動作検証 ユーザーおよびグループのリストアップ 予定のリストアップ（Google カレンダー） ファイルのリストアップ（Google ドライブ） メールのリストアップ（Gmail） 概要 Gemini CLI とは Gemini CLI とは、ターミナルから直接 Gemini の機能を利用できる、オープンソースの生成 AI コマンドラインインターフェイスです。詳細は以下の記事をご参照ください。 blog.g-gen.co.jp Google Workspace CLI とは Google Workspace CLI は、Google Workspace の各種 API をターミナルから操作できるコマンドラインツールです。操作結果を JSON で取得できるため、一覧取得や絞り込み、簡易的な集計にも利用できます。 当ツールは Google の公式サポート対象製品 ではありません 。Google の従業員によって開発されたツールではありますが、公式製品ではなく、技術サポートやその他のサポートは 提供されません 。また、当ツールは Apache-2.0 ライセンスのもとに公開されているオープンソースツールであり、無償で利用できます。また当記事を執筆した2026年3月6日現在では v0.3.3 であり、v1.0 に向けて破壊的変更が入る可能性もあることに留意して下さい。 参考 : googleworkspace/cli - GitHub 当ツールには AI エージェント向けの skills が豊富に用意されており、Gemini CLI などから自然言語の指示で gws コマンドを実行して Google Workspace を操作できるのが特徴です。 当記事で検証した Google Workspace の管理操作は以下のとおりです。 対象 検証内容 Admin SDK Google Workspace のユーザー一覧の取得、最終ログイン日時の集計、所属グループの確認 Google カレンダー 今日の予定一覧の取得、来週の空き時間の抽出 Google ドライブ マイドライブのファイル一覧取得、更新日時による絞り込み Gmail 受信トレイの一覧取得、未読メールの絞り込み なお Google Workspace CLI の利用には、Google Cloud プロジェクト上での API 有効化や OAuth クライアントの作成が必要です。今回は検証用に専用の Google Cloud プロジェクトを用意し、その環境で動作確認します。 参考 : googleworkspace/cli - GitHub 検証の流れ 検証手順は以下のとおりです。 項番 内容 説明 1 Google Workspace CLI のセットアップ Google Cloud プロジェクトの選択、API の有効化、OAuth クライアントの設定を行います。 2 Google Workspace CLI のログイン Google アカウントで認証します。 3 Gemini CLI の設定 Gemini CLI の拡張機能として Google Workspace CLI を導入します。 4 Gemini CLI からの操作検証 Gemini CLI から自然言語で Google Workspace の操作を依頼し、動作を確認します。 Google Workspace CLI のセットアップ インストールと初期設定 以下のコマンドで Google アカウントにログインします。gcloud コマンドが使えない場合、公式ドキュメントの手順に沿ってインストールします。 gcloud auth login 参考 : Google Cloud CLI をインストールする Google Workspace CLI のセットアップ時に API を有効化するため、事前に Cloud Resource Manager API を有効化しておきます。 # 環境変数を設定 PROJECT_ID = " your-project-id " # Google Cloud プロジェクト ID を設定 　 gcloud services enable cloudresourcemanager.googleapis.com --project = $PROJECT_ID 以下のコマンドで Google Workspace CLI をインストールします。 npm install -g @googleworkspace/cli 以下のコマンドで Google Workspace CLI のセットアップを実施します。 gws auth setup セットアップは 5 つのステップで構成されています。Step 1（gcloud CLI の確認）は自動で完了します。 Google アカウントを選択し、Enter キーを押します。 ┌ gws auth setup ─────────────────────────────────────────────────┐ │ ✓ Step 1 /5: gcloud CLI — found │ │ ▸ Step 2 /5: Authentication │ │ ○ Step 3 /5: GCP project │ │ ○ Step 4 /5: Workspace APIs │ │ ○ Step 5 /5: OAuth credentials │ └─────────────────────────────────────────────────────────────────┘ ┌Select a Google account──────────────────────────────────────────┐ │ ○ ➕ Login with new account │ │▸ ◉ miura@dev.g-gen.co.jp │ │ ○ xxxxxx@example.com │ └─────────────────────────────────────────────────────────────────┘ Google Cloud プロジェクトを選択します。先ほど API を有効化したプロジェクトを選択します。 ┌Select a GCP project─────────────────────────────────────────────┐ │ ○ ➕ Create new project │ │▸ ◉ your-project-id │ │ ○ project-aaa │ └─────────────────────────────────────────────────────────────────┘ 続いて、使用する API を有効化します。選択した API が Google Cloud プロジェクト上で有効化されます。今回は以下の 4 つを選択します。 API 用途 Admin SDK API ユーザー・グループの管理 Google Calendar API カレンダーの予定管理 Google Drive API ドライブのファイル操作 Gmail API メールの送受信・管理 # ◉ が選択済み（今回は Drive / Gmail / Calendar / Admin SDK を選択） ┌Select APIs to enable 4 / 22 selected─────────────────────────────┐ │ ◉ Google Drive drive.googleapis.com │ # 選択 │ ○ Google Sheets sheets.googleapis.com │ │ ◉ Gmail gmail.googleapis.com │ # 選択 │ ◉ Google Calendar calendar-json.googleapis.com │ # 選択 │ ○ Google Docs docs.googleapis.com │ │ ○ Google Slides slides.googleapis.com │ │ ○ Google Tasks tasks.googleapis.com │ │ ○ People ( Contacts ) people.googleapis.com │ │ ○ Google Chat chat.googleapis.com │ │ ○ Google Vault vault.googleapis.com │ │ ○ Groups Settings groupssettings.googleapis.com │ │ ○ Reseller reseller.googleapis.com │ │ ○ Licensing licensing.googleapis.com │ │ ○ Apps Script script.googleapis.com │ │ ◉ Admin SDK admin.googleapis.com │ # 選択 │ ○ Classroom classroom.googleapis.com │ │ ○ Cloud Identity cloudidentity.googleapis.com │ │ ○ Alert Center alertcenter.googleapis.com │ │ ○ Google Forms forms.googleapis.com │ │ ○ Google Keep keep.googleapis.com │ │ ○ Google Meet meet.googleapis.com │ │ ○ Cloud Pub/Sub pubsub.googleapis.com │ └─────────────────────────────────────────────────────────────────┘ OAuth クライアント ID の作成と入力を行います。ターミナルに表示される Step A（OAuth 同意画面の設定）と Step B（OAuth クライアント ID の作成）の手順を実施します。 ┌ gws auth setup ─────────────────────────────────────────────────┐ │ ✓ Step 1 /5: gcloud CLI — found │ │ ✓ Step 2 /5: Authentication — miura@dev.g-gen.co.jp │ │ ✓ Step 3 /5: GCP project — your-project-id │ │ ✓ Step 4 /5: Workspace APIs — 4 enabled, 0 skipped │ │ ▸ Step 5 /5: OAuth credentials — Waiting for manual input... │ │ │ │ Manual OAuth client setup required. │ │ │ │ Step A — Consent screen ( if not configured ) : │ │ https://console.cloud.google.com/apis/credentials/consent │ │ → User Type: External, then save through all screens. │ │ │ │ Step B — Create an OAuth client: │ │ https://console.cloud.google.com/apis/credentials │ │ → ' Create Credentials ' → ' OAuth client ID ' │ │ → Application type: Desktop app │ └─────────────────────────────────────────────────────────────────┘ ┌Enter OAuth Client ID────────────────────────────────────────────┐ │ > │ └─────────────────────────────────────────────────────────────────┘ OAuth 同意設定（Step A） Step A で表示されている URL へアクセスし、[開始] を選択します。 開始を選択 以下の情報を入力し、[次へ] を選択します。 アプリ名： 任意のアプリ名 ユーザーサポートメール： 管理者のメールアドレスを指定 アプリ情報を入力 参考 : Manage OAuth App Branding 先の Step A で User Type: External と指定があったため、[外部] を選択し、[次へ] を選択します。 対象を設定 任意のメールアドレスを入力し、[次へ] を選択します。 連絡先情報を設定 ポリシーを確認の上で、[同意します] を選択し、[続行] > [作成] を選択します。 ポリシーの確認 [対象] へ移動し、テストユーザーの [+Add users] を選択し、セットアップ時に指定した自身の Google アカウントを選択し [保存] を選択します。 テストユーザーの追加 追加確認 OAuth アプリの公開ステータスが テスト中 のため、テストユーザーにアカウントを追加することでアクセスが可能になります。 公開ステータスの確認 参考 : Manual OAuth setup (Google Cloud Console) OAuth クライアント作成（Step B） 次に Step B の URL へアクセスし、 [認証情報を作成] > [OAuth クライアント ID] を選択します。 OAuth クライアント ID を選択 Step B の指定（ Application type: Desktop app ）に従い、[デスクトップ アプリ] を選択します。 デスクトップアプリを選択 任意の名前を入力し、[作成] を選択します。 OAuth クライアント ID の作成 OAuth クライアント ID とクライアントシークレットが表示されるので、控えておきます。 クライアント ID とシークレットの確認 セットアップ完了 ターミナルへ戻り、クライアント ID とシークレットを入力して Enter を押します。 ┌Enter OAuth Client ID────────────────────────────────────────────┐ │ > XXXXX.apps.googleusercontent.com │ └─────────────────────────────────────────────────────────────────┘ ┌Enter OAuth Client Secret────────────────────────────────────────┐ │ > GOCSPX-XXXXX │ └─────────────────────────────────────────────────────────────────┘ 以下のように表示されれば、セットアップは完了です。 $ gws auth setup { " account " : " miura@dev.g-gen.co.jp " , " apis_enabled " : 4 , " apis_failed " : 0 , " apis_skipped " : 0 , " client_config " : " ~/.config/gws/client_secret.json " , " message " : " Setup complete! Run `gws auth login` to authenticate. " , " project " : " XXXXX " , " status " : " success " } 　 ✅ Setup complete ! Run `gws auth login` to authenticate. $ CLI の認証 以下のコマンドで認証を実施します。 gws auth login scope（アプリがアクセスできるデータの範囲）の設定画面が表示されるので、今回は以下の 5 つを選択し、Enter を押します。 scope 用途 admin.directory.group.readonly グループ情報の参照 admin.directory.user.readonly ユーザー情報の参照 calendar.readonly カレンダーの予定参照 drive.readonly ドライブのファイル参照 gmail.readonly メールの参照 # [x] が選択済み（今回は Admin SDK（user / group）/ Calendar / Drive / Gmail の readonly を選択） Select OAuth scopes 5 / 72 selected 　 ───────────────────────────────────────────────────────────────────────────────────────────────── [ ] ✨ Recommended ( All Non-Restricted + Readonly ) [ ] 🔒 Read Only [ ] ⚠️ Full Access ( All Scopes ) ～省略～ [ x ] drive. readonly ⛔ RESTRICTED # 選択 ～省略～ [ x ] gmail. readonly ⛔ RESTRICTED # 選択 ～省略～ [ x ] admin.directory.group. readonly # 選択 ～省略～ [ x ] admin.directory.user. readonly # 選択 ～省略～ [ x ] calendar. readonly # 選択 ～省略～ ───────────────────────────────────────────────────────────────────────────────────────────────── ↑↓ Navigate Space Toggle a All Enter Confirm Esc Cancel 　 OAuth アプリの公開ステータスが テスト中 の場合、指定できるスコープに上限があります。デフォルトの Recommended は多数のスコープを含むため、明示的に利用するスコープを選択する必要があります。 参考 : Interactive (local desktop) ブラウザが開き認証画面が表示されるため、アカウントを選択します。 アカウントを選択 OAuth アプリから前手順で選択したスコープに対する権限付与の許可画面が表示されるため、内容を確認して [許可] を選択します。 権限許可の設定 You may now close this window. とブラウザに表示されるため、コンソールへ戻り、以下内容が出力されていることを確認します。 { " credentials_file " : " ~/.config/gws/credentials.enc " , " encryption " : " AES-256-GCM (key secured by OS Keyring or local `.encryption_key` ) " , " message " : " Authentication successful. Encrypted credentials saved. " , " scopes " : [ " https://www.googleapis.com/auth/drive.readonly " , " https://www.googleapis.com/auth/gmail.readonly " , " https://www.googleapis.com/auth/admin.directory.group.readonly " , " https://www.googleapis.com/auth/admin.directory.user.readonly " , " https://www.googleapis.com/auth/calendar.readonly " , " https://www.googleapis.com/auth/cloud-platform " ] , " status " : " success " } cloud-platform スコープは gws auth login の実行時に自動で追加されます。 Gemini CLI の設定 以下のコマンドで Gemini CLI の Extension（拡張機能）として、Google Workspace CLI をインストールします。 gemini extensions install https://github.com/googleworkspace/cli 以下の警告が表示された場合、 Y を入力して Enter を押します。 The extension you are about to install may have been created by a third-party developer and sourced from a public repository. Google does not vet, endorse, or guarantee the functionality or security of extensions. Please carefully inspect any extension and its source code before installing to understand the permissions it requires and the actions it may perform. 　 Agent skills inject specialized instructions and domain-specific knowledge into the agent ' s system prompt. This can change how the agent interprets your requests and interacts with your environment. Review the skill definitions at the location(s) provided below to ensure they meet your security standards. Do you want to continue? [Y/n]:Y この警告は、サードパーティ製の拡張機能がエージェントのシステムプロンプトに指示を追加し、動作に影響を与える可能性があることを示しています。インストール前にソースコードや権限を確認することが推奨されています。 以下のコマンドで google-workspace-cli が拡張機能として登録されていることを確認します。 gemini extensions list 2 >&1 | grep -n " google-workspace-cli " 　 # 出力例 25:✓ google-workspace-cli ( latest ) 28: Path: ~/.gemini/extensions/google-workspace-cli 34: ~/.gemini/extensions/google-workspace-cli/CONTEXT.md 動作検証 ユーザーおよびグループのリストアップ Gemini CLI を起動し、以下プロンプトを入力します。 Google Workspace のユーザーを一覧で確認したい 以下のように gws コマンドの実行許可が出ることを確認し、許可します。 > Google Workspace のユーザーを一覧で確認したい 　 Action Required Shell: gws admin users list ...（省略） Allow execution of: ' gws ' ? 1 . Allow once 2 . Allow for this session 3 . No, suggest changes ( esc ) 　 ユーザーが 10 件表示されることを確認します。 # 出力例（各種値はマスク） 　 ✦ Google Workspace のユーザー一覧（最初の 10 件）を取得しました。 　 ┌───────────────────────┬──────────────────┬───────────────────────────────────┐ │ ID │ 氏名 │ プライマリメールアドレス │ ├───────────────────────┼──────────────────┼───────────────────────────────────┤ │ 1070 *********** 6529 │ g*** s******* │ 13 ****.***@***************.** │ │ 1161 *********** 2967 │ や******** │ a*************@***************.** │ │ 1015 *********** 9379 │ あ******* │ a******@***************.** │ │ 1161 *********** 5713 │ こ******** │ a*********@***************.** │ │ 1031 *********** 8256 │ し****** │ b**@***************.** │ │ 1158 *********** 3809 │ t*** C***** │ c*****@***************.** │ │ 1089 *********** 0291 │ み******** │ c***************@***************.** │ │ 1071 *********** 2585 │ t*** C** │ c*******.****@***************.** │ │ 1159 *********** 7349 │ で******** │ d*******@***************.** │ │ 1168 *********** 3985 │ t*** s***** │ d****************@***************.** │ └───────────────────────┴──────────────────┴───────────────────────────────────┘ 　 さらに多くのユーザーを確認したい場合や、特定の条件で絞り込みたい場合はお知らせください。 　 次に以下プロンプトで、最終ログイン日時をもとに集計します。 最終ログインが1週間前のユーザーが何名いるか知りたい Gemini CLI は gws admin users list を実行してユーザーの lastLoginTime を取得し、その結果をもとに最終ログイン日時を集計しました。 # 出力例 　 ✦ 全ユーザー 100 名を調査した結果、以下のようになりました。 　 * 最終ログインが 1 週間以上前のユーザー： 71 名 * まだ一度もログインしていないユーザー： 9 名 * 過去 1 週間以内にログインしたユーザー： 20 名 次に、ユーザーが所属している Google グループを確認します。 miura@dev.g-gen.co.jp が所属している Google グループを知りたい Gemini CLI は最初に gws admin groups list を実行しましたが、 fields の指定方法が誤っていたため一度エラーになりました。その後、 fields を --params 内へ移して再実行し、正常に結果を取得できました。 # 出力例（メールアドレスはマスク） 　 ✦ miura@dev.g-gen.co.jp が所属している Google グループは以下の通りです。 　 ┌─────────────────────────────────────┬─────────────────────────┐ │ メールアドレス │ グループ名 │ ├─────────────────────────────────────┼─────────────────────────┤ │ m*******************@************** │ m********************* │ │ m***************@************** │ a** │ │ t***@************** │ t*** │ └─────────────────────────────────────┴─────────────────────────┘ 予定のリストアップ（Google カレンダー） 以下プロンプトを入力し、今日の予定を一覧で確認します。 今日の予定を一覧で確認したい。開始時刻、タイトル、参加者の有無だけ出して 本日の予定が一覧表示されることを確認します。 # 出力例 　 ✦ 本日の予定は以下の通りです。 　 ┌──────────┬──────────┬────────────────────┐ │ 開始時刻 │ タイトル │ 参加者 │ ├──────────┼──────────┼────────────────────┤ │ 08:00 │ 会議 │ あり ( 自分含め 2 名 ) │ └──────────┴──────────┴────────────────────┘ 　 他に確認したい時間帯や、特定の予定の詳細が必要であればお知らせください。 　 次に、来週の平日 13:00〜18:00 の空き時間を確認します。 来週の平日、13:00〜18:00 の間で予定が入っていない時間帯を日ごとに教えて 来週の空き時間が日別に出力されることを確認します。 # 出力例 　 ✦ 来週の平日（ 2026 / 03 / 09 〜 03 / 13 ）、13:00〜18:00 の空き時間は以下の通りです。 　 　 * 3 / 9 ( 月 ) : 13:00 〜 18:00（終日空いています） * 3 / 10 ( 火 ) : 空き時間なし * 3 / 11 ( 水 ) : 13:00 〜 18:00（終日空いています） * 3 / 12 ( 木 ) : 13:00 〜 18:00（終日空いています） * 3 / 13 ( 金 ) : 13:00 〜 14:00、15:00 〜 18:00 　 　 予定の調整やミーティングの作成など、他にお手伝いできることはありますか？ 　 ファイルのリストアップ（Google ドライブ） 以下プロンプトを入力し、マイドライブのファイルを新しい順に 10 件取得します。 マイドライブのファイルを新しい順に 10 件だけ確認したい。ファイル名、種類、更新日時を出して Gemini CLI は gws drive files list を実行します。なお、 fields は --fields ではなく --params 内に指定する必要があり、最初の実行でエラーになった後、Gemini CLI が自動で修正し再実行しました。 # 出力例（ファイル名はマスク） 　 ┌───────────────┬─────────────────────────┬─────────────────────┐ │ ファイル名 │ 種類 ( MIMEタイプ ) │ 更新日時 ( UTC ) │ ├───────────────┼─────────────────────────┼─────────────────────┤ │ **** │ Google ドキュメント │ 2025-07-16 04:52:29 │ │ **** │ Google スライド │ 2025-07-14 15:52:29 │ │ **** │ Google スプレッドシート │ 2025-07-14 15:50:37 │ │ **** │ PDF │ 2025-07-13 13:29:10 │ │ **** │ テキストファイル │ 2025-03-10 07:40:26 │ │ **** │ フォルダ │ 2025-03-10 07:40:24 │ │ … │ … │ … │ └───────────────┴─────────────────────────┴─────────────────────┘ 　 次に、直近 7 日以内に更新されたファイルに絞り込みます。 直近 7 日以内に更新された Google Drive のファイルだけを一覧で確認したい。ファイル名と更新日時を出して 確認した結果、該当ファイルが存在しない場合はその旨が表示されることを確認します。 ✦ 直近 7 日以内（ 2026 年 2 月 27 日以降）に更新された Google Drive のファイルは見つかりませんでした。 　 　 参考までに、先ほど確認したマイドライブの最新ファイルは 2025 年 7 月に更新された「****」でした。より長い期間（例：直近 1 ヶ月や 1 年）で確認したい場合は、その旨お知らせください。 メールのリストアップ（Gmail） 以下プロンプトを入力し、受信トレイの最新メールを 10 件取得します。 受信トレイのメールを新しい順に 10 件だけ確認したい。差出人、件名、受信日時を出して Gemini CLI は gws gmail users messages list / get を用いてメール一覧を取得し、表形式に整形して表示します（差出人・件名は記事掲載用にマスクしています）。 # 出力例（差出人・件名はマスク） 　 ┌───────────────┬───────────────┬────────────────────┐ │ 差出人 │ 件名 │ 受信日時 ( JST換算 ) │ ├───────────────┼───────────────┼────────────────────┤ │ ******** │ ******** │ 2026 / 03 / 04 10:50 │ │ ******** │ ******** │ 2026 / 03 / 03 17:40 │ │ ******** │ ******** │ 2026 / 03 / 03 02:01 │ │ … │ … │ … │ └───────────────┴───────────────┴────────────────────┘ 　 次に、未読メールに絞り込んで最新 10 件を取得します。 未読メールを新しい順に 10 件だけ確認したい。差出人、件名、受信日時を出して # 出力例（差出人・件名はマスク） 　 ✦ 未読メールの最新 10 件は以下の通りです。 　 ┌───────────────┬───────────────┬────────────────────┐ │ 差出人 │ 件名 │ 受信日時 ( JST換算 ) │ ├───────────────┼───────────────┼────────────────────┤ │ ******** │ ******** │ 2026 / 03 / 04 10:50 │ │ ******** │ ******** │ 2026 / 03 / 03 17:40 │ │ … │ … │ … │ └───────────────┴───────────────┴────────────────────┘ 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。 ネットワーク・セキュリティ・唐揚げ・辛いものが好き。 Google Cloud Partner All Certification Holders 2025 / Google Cloud Partner Top Engineer 2026