TECH PLAY

株式会社G-gen

株式会社G-gen の技術ブログ

全808件

G-gen の佐々木です。当記事では、ADK で開発した AI エージェントに BigQuery Agent Analytics のプラグインを組み込むことで、エージェントのリクエストやレスポンス、ツール呼び出しなどのイベントを BigQuery に記録し、SQL で分析できるようにしていきます。 構成 当記事で使用するもの Agent Development Kit(ADK) Agent Runtime BigQuery BigQuery Agent Analytics について 概要 BigQuery に記録されるイベントについて エージェントの開発 ディレクトリ構成 プロジェクトの準備 エージェントのソースコード(agent.py) Google Cloud 側の準備 BigQuery データセットの作成 Agent Runtime サービスアカウントへの IAM 付与 ローカル認証 .env ファイルの作成 ローカルでの動作確認(ADK Web) Agent Runtime へのデプロイ デプロイの実施 動作確認 構成 当記事では、 Agent Development Kit(ADK) で定義した AI エージェントを Agent Runtime (旧称 : Vertex AI Agent Engine)にデプロイし、エージェントの実行中に発生するイベント(LLM への入出力、ツール呼び出し、エージェントのライフサイクルなど)を BigQuery にストリーミング方式で記録できるようにします。 イベントの記録には、ADK が公式に提供する BigQuery Agent Analytics プラグイン ( BigQueryAgentAnalyticsPlugin )を使用します。プラグインをエージェントに登録するだけで、BigQuery の Storage Write API を使用したイベントの記録と、イベント型ごとのビューの自動生成が行われます。 BigQuery に記録されたイベントにクエリを実行することで、トークン使用量の集計、ツール呼び出しの頻度分析、特定セッションのトレースなどを行うことができます。また、 Conversational Analytics 機能を使用した自然言語での分析や、BigQuery ML や Looker / Data Studio(データポータル)による高度な分析、可視化も可能です。 BigQuery Agent Analytics を使用してエージェントのイベントを BigQuery にストリーミングする 当記事で使用するもの Agent Development Kit(ADK) Agent Development Kit(ADK) は、Google Cloud が提供する AI エージェント構築のためのオープンソース フレームワークであり、単純なタスクをこなすエージェントから複数のエージェントが協働する複雑なワークフローまで容易に実装できます。 ADK には、当記事で使用する BigQueryAgentAnalyticsPlugin のような、エージェントの振る舞いを拡張するためのプラグインが用意されており、エージェントのコードを大きく変更することなくロギング、トレーシングなどの機能を追加できます。 参考 : Agent Development Kit の概要 参考 : Plugins Agent Runtime Agent Runtime は AI エージェントの実行基盤を提供するフルマネージドサービスです。 Agent Runtime では、エージェントとのマルチターン会話を実現するための組み込みの セッション機能 を利用することができるほか、エージェントの機能拡張に必要な様々な機能が提供されています。また、Agent Runtime のコンソールからチャット UI(Playground)で直接エージェントの動作確認を行うことができます。 Agent Runtime の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp BigQuery BigQuery は Google Cloud が提供するフルマネージドなサーバーレス データウェアハウスです。大量のデータを高速に分析できる SQL エンジンを備えており、 Storage Write API を用いたストリーミング インサートによってリアルタイムにデータを書き込むこともできます。 当記事では、エージェントのイベントを格納する先として BigQuery を使用します。BigQuery Agent Analytics プラグインが内部で Storage Write API を利用してイベントを非同期にストリーミングするため、エージェントのパフォーマンスへの影響を抑えつつログを蓄積できます。 BigQuery の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp 参考 : BigQuery の概要 参考 : BigQuery Storage Write API の概要 BigQuery Agent Analytics について 概要 BigQuery Agent Analytics は、AI エージェントのインタラクション データをキャプチャ・分析・可視化するためのオープンソース ソリューションです。エージェントのリクエスト、レスポンス、ツール呼び出し、エラーなどのイベントを BigQuery テーブルに直接ストリーミングすることで、SQL や BigQuery ML での分析や、ダッシュボードでの可視化を可能にします。 当記事を執筆している2026年4月現在では、以下の2つのフレームワークに対応しています。 Agent Development Kit(ADK) LangGraph(2026年4月現在ではプレビュー) ADK では BigQueryAgentAnalyticsPlugin という プラグイン が提供されており、これをエージェントに登録するだけで BigQuery に対するイベントのログストリーミングを有効化できます。プラグインには以下のような特徴があります。 Storage Write API による高スループット・低遅延の非同期書き込み マルチモーダルのコンテンツ(テキスト / 画像 / 音声 / 動画)を記録可能(コンテンツの種類によっては Cloud Storage にオフロード) OpenTelemetry と統合された分散トレーシングにより trace_id 、 span_id による実行フローの可視化が可能 ツールの呼び出し元( LOCAL / MCP / SUB_AGENT / A2A / TRANSFER_AGENT )を記録 新しいイベント型が追加された際に、既存テーブルに対して自動で列を追加 その他、詳細な仕様については、以下の公式ドキュメントを参照してください。 参考 : BigQuery Agent Analytics plugin for ADK 参考 : BigQuery エージェント分析を使用する BigQuery に記録されるイベントについて BigQuery に記録されるイベントは、大きく以下の5つのカテゴリに分類されます。 カテゴリ イベント型 内容 LLM interactions LLM_REQUEST / LLM_RESPONSE / LLM_ERROR LLM へのプロンプト、モデル出力、エラーに関するイベント トークン使用量、生成にかかった時間なども記録される Tool usage TOOL_STARTING / TOOL_COMPLETED / TOOL_ERROR ツール呼び出しの開始、完了、エラーに関するイベント ツールの呼び出し元( tool_origin )も記録される State Management STATE_DELTA エージェントの内部状態の変更に関するイベント Agent lifecycle & Generic Events INVOCATION_STARTING / INVOCATION_COMPLETED / AGENT_STARTING / AGENT_COMPLETED / USER_MESSAGE_RECEIVED エージェントの起動、実行完了、ユーザー入力の受信などのイベント Human-in-the-Loop (HITL) Events HITL_CREDENTIAL_REQUEST / HITL_CONFIRMATION_REQUEST / HITL_INPUT_REQUEST / 各イベントの _COMPLETED ユーザー認証情報の要求、ユーザーへの確認要求、ユーザーからの入力要求などの割り込みイベント これらのイベントはすべて agent_events という1つのテーブルにまとめて格納されますが、プラグインによって自動で生成されるビュー( v_llm_request 、 v_llm_response 、 v_tool_completed など)を使用することで、イベント型ごとに分析が可能です。 イベントのスキーマや詳細な内容については、以下の公式ドキュメントを参照してください。 参考 : BigQuery Agent Analytics plugin for ADK - Event types and payloads エージェントの開発 ディレクトリ構成 当記事では、コーヒーに関する質問に回答する「コーヒーエージェント」を ADK で構築し、 BigQueryAgentAnalyticsPlugin を組み込みます。ユーザーからの質問は、Google 検索を行うサブエージェントをツールとして持つエージェントが処理します。 最終的なディレクトリ構成は以下の通りになります。 coffee_agent ディレクトリで AI エージェントを実装していきます。 . ├── coffee_agent │ ├── agent.py │ ├── .env │ └── __init__.py ├── pyproject.toml # 自動で作成 └── uv.lock # 自動で作成 プロジェクトの準備 エージェント開発用のディレクトリでプロジェクトを初期化します。 BigQueryAgentAnalyticsPlugin は google-adk をインストールするだけで併せて利用できます。 # uv プロジェクト初期化 $ uv init --no-readme # パッケージの追加 $ uv add " google-adk>=1.29.0 " エージェント用のパッケージディレクトリ( coffee_agent )を作成し、ADK がエージェントのパッケージとして認識できるように __init__.py を配置します。 # エージェントのパッケージディレクトリを作成 $ mkdir coffee_agent # __init__.py を作成 $ cat <<EOF > coffee_agent/__init__.py from . import agent EOF エージェントのソースコード(agent.py) エージェントのソースコードでは、以下のように BigQueryAgentAnalyticsPlugin を組み込んだエージェントを実装します。 BigQueryAgentAnalyticsPlugin のインスタンスを作成し、ログの記録先となる BigQuery プロジェクト・データセット・ロケーションを指定 root_agent をラップする App オブジェクトを作成し、 plugins 引数にプラグインを登録 ポイントとして、このエージェントを adk deploy コマンドで Agent Runtime にデプロイする際に、 root_agent ではなく App オブジェクト( app )をデプロイ対象として指定する必要があります(後述)。この App オブジェクトに plugins を登録しておくことで、デプロイ後のエージェントでプラグインが有効化されます。 import os from google.adk.agents import Agent from google.adk.apps import App from google.adk.plugins.bigquery_agent_analytics_plugin import ( BigQueryAgentAnalyticsPlugin, BigQueryLoggerConfig, ) from google.adk.tools import google_search from google.adk.tools.agent_tool import AgentTool PROJECT_ID = os.environ[ "GOOGLE_CLOUD_PROJECT" ] DATASET_ID = os.environ.get( "BQ_DATASET" , "agent_analytics" ) BQ_LOCATION = os.environ.get( "BQ_LOCATION" , "asia-northeast1" ) # BigQuery Agent Analytics プラグイン bq_analytics_plugin = BigQueryAgentAnalyticsPlugin( project_id=PROJECT_ID, dataset_id=DATASET_ID, location=BQ_LOCATION, config=BigQueryLoggerConfig( batch_size= 1 , batch_flush_interval= 0.5 , log_session_metadata= True , ), ) # Web 検索用サブエージェント search_agent = Agent( name= "search_agent" , model= "gemini-2.5-flash" , description= "Google検索でコーヒーに関する情報を調べるエージェント" , instruction= "ユーザーの質問に対してGoogle検索を使って情報を収集し、日本語で回答してください。" , tools=[google_search], ) # ルートエージェント root_agent = Agent( name= "coffee_agent" , model= "gemini-2.5-flash" , description= "コーヒーに関する情報を収集するエージェント" , instruction= """あなたはコーヒーの専門家アシスタントです。 ユーザーからの質問に対して、search_agentを活用しながらコーヒーに関する正確で有益な情報を提供してください。 対応できるトピックの例: - コーヒー豆の産地・品種・特徴 - 抽出方法(ドリップ、エスプレッソ、フレンチプレスなど) - 焙煎度合いと味わいの違い - カフェやコーヒーショップの情報 - コーヒーの健康効果や歴史 - ラテアートやバリスタの技術 回答は日本語で、わかりやすく丁寧に行ってください。""" , tools=[AgentTool(agent=search_agent)], ) # Agent Runtime デプロイ用 App (プラグインを登録) app = App( name= "coffee_agent" , root_agent=root_agent, plugins=[bq_analytics_plugin], ) また、 BigQueryLoggerConfig では動作確認をしやすくするために、 batch_size=1 / batch_flush_interval=0.5 を指定してイベントが即座に BigQuery へ書き込まれるようにしています。 BigQueryLoggerConfig では、このほかにもイベントの記録挙動を細かく制御できます。代表的なものを以下に挙げます。 パラメータ デフォルト 説明 table_id "agent_events" イベントを格納する BigQuery テーブル ID event_allowlist / event_denylist None 記録する / 除外するイベント型のリスト content_formatter None イベントの記録前にフォーマットを行うために使用する関数( 参考 ) gcs_bucket_name None マルチモーダル コンテンツをオフロードする Cloud Storage バケット create_views True イベント型ごとのビューを作成するか view_prefix "v" 自動生成するビュー名のプレフィックス 参考 : BigQuery Agent Analytics plugin for ADK - Configuration options Google Cloud 側の準備 BigQuery データセットの作成 プラグインがイベント記録用のテーブル( agent_events )とビュー( v_llm_request など)を自動で作成するため、あらかじめ格納先のデータセットのみ用意します。データセットのリージョンは、後述する Agent Runtime の稼働リージョンと一致させます。 # データセット ID とロケーションを環境変数にセット $ PROJECT_ID = < プロジェクトID > $ DATASET_ID =agent_analytics $ BQ_LOCATION =asia-northeast1 # データセットの作成 $ bq --location = $BQ_LOCATION mk \ --dataset \ --description =" BigQuery Agent Analytics for ADK " \ $PROJECT_ID : $DATASET_ID Agent Runtime サービスアカウントへの IAM 付与 Agent Runtime にデプロイしたエージェントから BigQuery に書き込みを行うために、Agent Runtime のサービスアカウント( service-<プロジェクト番号>@gcp-sa-aiplatform-re.iam.gserviceaccount.com )に対して以下のロールを付与します。 ロール スコープ 用途 BigQuery ジョブユーザー ( roles/bigquery.jobUser ) プロジェクト BigQuery ジョブ(クエリ・書き込み)の実行 BigQuery データ編集者 ( roles/bigquery.dataEditor ) データセット テーブル・ビューの作成、データの書き込み 最小権限の原則に従い、 roles/bigquery.dataEditor はエージェント分析用のデータセットに対してのみ付与します。データセット単位の IAM は SQL の GRANT 文を使って付与します。 # プロジェクト番号の取得 $ PROJECT_NUMBER = $( gcloud projects describe $PROJECT_ID --format =' value(projectNumber) ' ) # Agent Runtime 実行サービスアカウント $ RE_SA = " service- ${PROJECT_NUMBER} @gcp-sa-aiplatform-re.iam.gserviceaccount.com " # bigquery.jobUser はプロジェクトレベルで付与 $ gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${RE_SA} " \ --role =" roles/bigquery.jobUser " # bigquery.dataEditor はデータセットレベルで付与 $ bq query --use_legacy_sql =false \ " GRANT \` roles/bigquery.dataEditor \` ON SCHEMA \` ${PROJECT_ID} \` . ${DATASET_ID} TO 'serviceAccount: ${RE_SA} ' " 当記事では実施しませんが、マルチモーダル コンテンツを Cloud Storage にオフロードする場合は、対象バケットに対して Storage オブジェクト作成者 ( roles/storage.objectCreator )および Storage オブジェクト閲覧者 ( roles/storage.objectViewer )も付与します。 参考 : BigQuery Agent Analytics plugin for ADK - Prerequisites ローカル認証 ローカルから adk web や adk deploy を実行する際の Google Cloud CLI の認証を行っておきます。 # 認証 $ gcloud auth login $ gcloud auth application-default login # プロジェクトの設定 $ gcloud config set project $PROJECT_ID .env ファイルの作成 エージェントの実行時に Gemini Enterprise Agent Platform(旧称 : Vertex AI、以下 Agent Platform と記載)を利用するための環境変数を、 coffee_agent ディレクトリ配下の .env ファイルに設定します。ADK は adk web や adk deploy の実行時にこのファイルを自動で読み込みます。 # coffee_agent/.env を作成 $ cat <<EOF > coffee_agent/.env GOOGLE_GENAI_USE_VERTEXAI=1 GOOGLE_CLOUD_PROJECT= $PROJECT_ID GOOGLE_CLOUD_LOCATION=asia-northeast1 EOF GOOGLE_GENAI_USE_VERTEXAI : 1 を指定することで、Gemini API ではなく Agent Platform 経由で Gemini モデルを利用します GOOGLE_CLOUD_PROJECT : エージェントをデプロイする Google Cloud プロジェクト ID。 agent.py で BigQuery 出力先プロジェクトとしても参照されます GOOGLE_CLOUD_LOCATION : Agent Runtime およびモデルを利用するリージョン ローカルでの動作確認(ADK Web) Agent Runtime へのデプロイ前に、ローカルで ADK Web UI を起動してエージェントの動作と BigQuery へのログ記録を確認します。 agent.py に app = App(...) を定義しておくと、 root_agent ではなく app が自動検出され、 plugins で指定されているプラグインを有効化した状態でエージェントが起動します。 # ADK Web UI の起動 $ uv run adk web ブラウザで http://localhost:8000 を開き、チャット UI からエージェントに質問を送ってみます。 ADK Web UI からエージェントにメッセージを送信する BigQuery コンソールで、 agent_events テーブルが自動作成され、イベントが記録されていることを確認します。 SELECT timestamp , event_type, agent, content FROM `<プロジェクトID>.agent_analytics.agent_events` ORDER BY timestamp DESC LIMIT 20 ; エージェントの各種イベントが BigQuery テーブルに記録されている USER_MESSAGE_RECEIVED 、 LLM_REQUEST 、 LLM_RESPONSE 、 AGENT_COMPLETED といったイベントが時系列で記録されていれば、プラグインが正しく動作しています。 また、 agent_events テーブルとあわせて、イベント型ごとのビュー( v_llm_request 、 v_llm_response 、 v_tool_completed など)も自動で作成されており、こちらもデータセット内で確認できます。 イベント型ごとのビューが自動作成されている 参考 : ADK CLI documentation - web Agent Runtime へのデプロイ デプロイの実施 Agent Runtime にエージェントをデプロイします。プラグインを含めてデプロイするには、 --adk_app_object オプションで App オブジェクトの変数名(ここでは app )を指定する必要があります。このオプションを指定しない場合、デフォルトでは root_agent がデプロイ対象となり、プラグインが適用されません。 # Agent Runtime にエージェントをデプロイ $ uv run adk deploy agent_engine \ --project = $PROJECT_ID \ --region = asia-northeast1 \ --display_name =" Coffee Agent with BQ Analytics " \ --adk_app_object = app \ coffee_agent 参考 : ADK CLI documentation - deploy 動作確認 デプロイが完了したら、Agent Runtime のコンソール画面( https://console.cloud.google.com/vertex-ai/agents/agent-engines )でデプロイしたエージェントを選択し、チャット UI(Playground)で動作確認を行います。 コンソールのチャット UI で、コーヒーに関する質問を送信してみます。 Agent Runtime のコンソールからエージェントにメッセージを送信する ローカル実行時と同様に、BigQuery の agent_events テーブルにイベントが記録されていることを確認します。 Agent Runtime にデプロイしたエージェントのイベントが記録されている 自動作成された v_llm_response ビューを使用して、LLM のトークン使用量を集計してみます。以下は全体の平均トークン数を確認するクエリです。 SELECT AVG (usage_total_tokens) AS avg_tokens, AVG (usage_prompt_tokens) AS avg_prompt, AVG (usage_completion_tokens) AS avg_completion FROM `<プロジェクトID>.agent_analytics.v_llm_response`; v_llm_response ビューから平均トークン数を集計する 公式ドキュメントにいくつかのクエリサンプルが紹介されているので、こちらも参照してください。 参考 : BigQuery Agent Analytics plugin for ADK - Advanced analysis queries 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出(2024 / 2025 Fellow / 2026)。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説(SF、ミステリ)、カラオケなど。 Follow @sasashun0805
G-gen の min です。データポータル(英名 Data Studio、旧称 Looker Studio)の BigQuery データソース接続において、個人の Google アカウントではなくサービスアカウントの認証情報を使用する際、権限エラーや接続エラーが発生することがあります。当記事では、サービスアカウント接続がうまくいかない場合に確認すべきポイントをチェックリスト形式で解説します。 ※当記事に掲載しているエラーメッセージは、2026年3月時点の仕様に基づいています。 前提となる構成 サービスエージェントに権限があるか エラーメッセージ 対処法 設定ユーザーに「使用」権限があるか エラーメッセージ 対処法 VPC SC でアクセスがブロックされていないか エラーメッセージ 対処法 前提となる構成 以下のように、データポータルのレポートから BigQuery テーブルを参照する構成があります。 BigQuery テーブルは、 VPC Service Controls の境界で保護された Google Cloud プロジェクトに格納されています。また、データポータルのレポートから BigQuery への認証には、個人の Google アカウントではなく、サービスアカウントを使用しています。 データポータルから BigQuery を参照 このとき、いくつかのポイントでエラーが発生することがあります。以下に、3つのチェックリストとして紹介します。 サービスエージェントに権限があるか エラーメッセージ エラーメッセージ (日本語) Looker Studio サービス エージェントに、このサービスアカウントに対する「iam.service Account.getAccess Token」 権限がありません。 エラーメッセージ (英語) Looker Studio Service Agent is missing "iam.serviceAccount.getAccessToken" permission on this service account. サービスエージェントの権限不足を示すエラーメッセージ 接続設定時に上記のエラーが出る場合、サービスエージェントの権限不足です。 データポータルがユーザー指定のサービスアカウントになりすまして BigQuery にアクセスするためには、データポータル側の サービスエージェント (Google が管理する特殊なサービスアカウント)に対し、対象のサービスアカウントのアクセストークンを発行する権限が必要です。 単に対象のサービスアカウントに BigQuery データ閲覧者( roles/bigquery.dataViewer )等を付与するだけでは不十分であり、データポータルのサービスエージェント自体にも適切なロールを付与する必要があります。 このとき重要なのが、 どの組織のサービスエージェントか という点です。許可すべきサービスエージェントは、BigQuery やサービスアカウントが存在する Google Cloud 組織のものではなく、 データポータルのデータソースを作成・所有するアカウントの組織(Google Workspace または Cloud Identity のドメイン) に対応するサービスエージェントです。 サービスエージェントの仕様については、以下の記事も参照してください。 blog.g-gen.co.jp 対処法 データポータルのサービスエージェントに対し、対象のサービスアカウントに対する「 サービス アカウント トークン作成者 ( roles/iam.serviceAccountTokenCreator )」ロールを付与します。 必ず「データポータルのデータソースを作成・所有するユーザー」の Google アカウントで 、以下の手順を実施してください。 データポータルサービスエージェントのヘルプページ にアクセス ページ内のフォームに「サービスエージェント」のアドレスが表示されるため、これをコピー Google Cloud コンソールで、データポータルが使用する(BigQuery にアクセスさせたい)サービスアカウントの設定画面を開く コンソールの [IAM と管理] > [サービス アカウント] に移動 対象のサービスアカウントをクリックし、詳細画面へ遷移 [アクセス権を持つプリンシパル] タブをクリックし、[アクセスを許可] をクリック 「新しいプリンシパル」に、手順2でコピーした データポータルサービスエージェントのメールアドレスを入力 「ロール」に「 サービス アカウント トークン作成者 ( roles/iam.serviceAccountTokenCreator )」を選択し、保存 参考 : データポータル用に Google Cloud サービス アカウントを設定する - 設定の手順 設定ユーザーに「使用」権限があるか エラーメッセージ このサービス アカウントを使用する権限がありません。 サービスアカウントに対する権限不足を示すエラーメッセージ データポータルの画面上で「このサービスアカウントを使用する」という設定を行うためには、 設定操作を行っているユーザー自身 が、そのサービスアカウントを「使用する」権限を持っている必要があります。 この権限は「 サービス アカウント ユーザー ( roles/iam.serviceAccountUser )」ロールに含まれています。 よくある落とし穴として、「サービス アカウント管理者( roles/iam.serviceAccountAdmin )が付与されているから問題ない(包含している)」と誤認してしまうケースがあります。サービス アカウント管理者ロールにはサービスアカウント自体を管理する権限はありますが、サービスアカウントとして振る舞うための権限( iam.serviceAccounts.actAs )は含まれていません。 参考 : データポータル用に Google Cloud サービス アカウントを設定する - ユーザーロールを付与する 参考 : Identity and Access Management roles and permissions - Service Account Admin 参考 : Identity and Access Management roles and permissions - Service Account User 参考 : Identity and Access Management roles and permissions - iam.serviceAccounts.actAs 対処法 データポータルのデータソース設定を行う ユーザーの Google アカウント に対し、対象サービスアカウントの「 サービス アカウント ユーザー ( roles/iam.serviceAccountUser )」ロールを付与します。 コンソールの [IAM と管理] > [サービス アカウント] に移動 対象のサービスアカウントをクリックし、詳細画面へ遷移 [アクセス権を持つプリンシパル] タブをクリックし、[アクセスを許可] をクリック 「新しいプリンシパル」に、データポータルで設定操作を行うユーザーのメールアドレスを入力 「ロール」に「 サービス アカウント ユーザー ( roles/iam.serviceAccountUser )」を選択し、保存 VPC SC でアクセスがブロックされていないか エラーメッセージ このサービス アカウントを使用する権限がありません。 サービスアカウントに対する権限不足を示すエラーメッセージ 接続先の Google Cloud プロジェクトが VPC Service Controls の境界で保護されている場合、外部からの API リクエストは原則として遮断されます。 データポータルは Google Cloud の VPC 内部ではなく、インターネット(Google のパブリック IP アドレス帯域)からアクセスを行います。そのため、VPC Service Controls の境界でアクセスがブロックされてしまいます。 Google Cloud 側のログを確認すると、VPC SC ( VPC_SERVICE_CONTROLS ) によるエラーログが記録されています。 対処法 VPC Service Controls を導入している環境では、データポータルからのアクセスを許可するために 上り(内向き)ルール (Ingress Rule)の設定が必要です。 Google Cloud コンソールの [セキュリティ] > [VPC Service Controls] に移動 対象の境界に適用されている境界を編集、または新規作成 上り(内向き)ルールの設定において、データポータルで使用している サービスアカウントのメールアドレス を追加 設定を保存 設定の詳細は、以下の記事の「VPC Service Controls の設定」でも解説しています。 blog.g-gen.co.jp 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー(猫)」。
G-gen の min です。BigQuery でデータ分析情報を生成する機能 データ分析情報 (Data insights)について解説します。 データ分析情報とは 概要 2つの分析レベル 分析情報を生成するモード 事前準備 必要な API の有効化 必要な IAM ロール テーブル分析情報 提供される機能 クエリの生成 説明の生成 生成言語の制御 生成手順 生成した分析情報の保存 データセット分析情報 提供される機能 データセットの説明 リレーションシップグラフ リレーションシップテーブル クエリの推奨 生成手順 制限事項 料金 データ分析情報とは 概要 データ分析情報 ( Data insights )とは、BigQuery に統合された AI アシスタントである Gemini in BigQuery の機能の一つです。 BigQuery に蓄積されたデータを使用して分析を始める際、初めて見るテーブルにどのようなデータが入っているのか、他のテーブルとどのような関係があるのかを理解するには、通常、試しに SQL を書いてデータを抽出したり、設計書を読み解くなどの手間がかかります。 データ分析情報を使用すると、AI がテーブルやカラムの名前などの付帯情報(メタデータ)を読み取り、テーブルの概要を説明するテキストや、データ分析に役立つ SQL クエリを自動生成します。これにより、SQL に不慣れな非エンジニアの方や、初めてそのデータに触れるアナリストであっても、スムーズにデータ探索を開始できます。 参考 : BigQuery でデータ分析情報を生成する 2つの分析レベル データ分析情報には、分析の範囲に応じて以下の2つの機能が提供されています。それぞれの詳細については後述します。 機能名 分析対象 主な提供内容 テーブル分析情報 (table insights) 単一のテーブル データ内容や品質の分析、要約文の生成、データ抽出用 SQL クエリの提案 データセット分析情報 (datasets insights) 単一のデータセット 複数テーブル間の関係性の推論、テーブル結合を伴う SQL クエリの提案 後者のデータセット分析情報については、2026年4月現在、Preview 段階です。 分析情報を生成するモード BigQuery では、分析情報を生成する際に以下の2つのモードが用意されています。 モード 説明 用途 生成して公開 (Generate and publish) AI が生成したデータの説明や SQL クエリの提案を、Google Cloud のデータ辞書サービスである Dataplex Universal Catalog に保存します。権限を持つ他のメンバーと知識を共有できるほか、保存された説明を後から手動で編集することも可能です。 会社全体でデータの説明などのドキュメントを共有し、継続的に知識を蓄積・再利用したい場合。 公開せずに生成 (Generate without publish) その場限りの分析情報をすぐに作成します。生成された情報は、共有のデータ辞書には保存(公開)されません。 共有のデータ辞書に不要な情報を増やさず、一時的なデータ確認やお試しでの分析を素早く行いたい場合。 前者の生成して公開(Generate and publish)については、2026年4月現在、Preview 段階です。 Dataplex Universal Catalog については、以下の記事を参照してください。 blog.g-gen.co.jp 事前準備 必要な API の有効化 データ分析情報を使用するプロジェクトでは、事前に以下の API を有効化しておく必要があります。 BigQuery API Dataplex API Gemini for Google Cloud API 必要な IAM ロール コンソール画面からデータ分析情報を生成し、その結果を閲覧するためには、作業するユーザーの Google アカウントに対して以下の IAM ロールが付与されている必要があります。 データ分析情報の機能は内部的に Dataplex というデータ管理サービスの機能を使用しているため、BigQuery だけでなく Dataplex の権限も必要となる点に注意してください。 「BigQuery データ閲覧者( roles/bigquery.dataViewer )」または「BigQuery データ編集者( roles/bigquery.dataEditor )」 「Dataplex DataScan 編集者( roles/dataplex.dataScanEditor )」または「Dataplex DataScan 管理者( roles/dataplex.dataScanAdmin )」 参考 : BigQuery でデータ分析情報を生成する - 必要なロール テーブル分析情報 提供される機能 テーブル分析情報は、単一の BigQuery テーブルに含まれるデータの内容や品質、傾向を理解するための機能です。対象のテーブルに対して分析情報を生成すると、AI が以下のような情報を提供します。 クエリの生成 データ内のパターン、異常値、外れ値などを検出するための自然言語の質問と、それに対応する SQL クエリを提案します。 説明の生成 テーブル全体および各カラムに対する説明文を自動生成します。対象のテーブルに対して データ プロファイル スキャン (データの傾向や統計情報を抽出する機能)が実行されている場合、その結果も加味してより正確な説明が生成されます。 データ プロファイル スキャンについては、以下の公式ドキュメントを参照してください。 参考 : データをプロファイリングする 生成言語の制御 テーブルとカラムの説明を特定の言語で生成するように、Gemini に指示できます。 言語を指定するには、分析情報を生成する前に、テーブルの既存の説明文に「日本語で説明をして」といった短い指示を追記します。対象テーブルの「詳細」タブを開き、「詳細を編集」をクリックして指示文を追記および保存します。 詳細タブの画面 説明編集の画面 サポートされている言語の一覧については、以下を参照してください。 参考 : 言語サポート - Gemini 生成手順 Google Cloud コンソール画面から、テーブル分析情報を公開せずに生成する手順は以下のとおりです。 Google Cloud コンソールを開き、BigQuery Studio の画面に移動します。 画面左側の「エクスプローラ」ペインで、対象のプロジェクト名、データセット名の順に選択し、分析したいテーブルをクリックします。 画面右側にテーブルの詳細情報が表示されるため、上部のタブメニューから「分析情報」タブを選択します。 分析情報タブの画面 画面内の「公開せずに生成」ボタンをクリックします。 分析情報の生成には数分程度かかる場合があります。生成が完了すると、AI によって提案されたテーブルの概要や、データを分析するためのサンプル SQL クエリなどが同じ画面に表示されます。表示された SQL はそのまま実行したり、要件にあわせて書き換えて保存できます。 生成した分析情報の保存 Gemini in BigQuery は、データ分析情報を生成するときに、テーブルとカラムの説明を自動的に生成します。必要に応じてこれらの説明を編集し、BigQuery のスキーマや詳細情報として手動で保存できます。 テーブルで分析する内容を記述した詳細なテーブルの説明は、Gemini in BigQuery でより関連性の高い分析情報を生成するのに役立ちます。保存された説明は、自分や他のメンバーが参照できるだけでなく、今後の分析情報を生成するためにも使用されます。 説明文を保存する手順は以下のとおりです。 対象テーブルの画面で「分析情報」タブを開きます。 分析情報を生成後の分析情報タブの画面 画面内の「テーブルの説明」セクションにある「列の説明を表示」をクリックします。説明のプレビュー画面が表示されます。 説明のプレビュー画面 テーブル自体の説明を保存したい場合は、「詳細に保存」をクリックします。「提案された説明をコピー」をクリックして入力欄に内容を反映させたのち、「Save to details」をクリックします。 詳細に保存の画面 カラムの説明を追加・保存したい場合は、2. のプレビュー画面にて「列の説明」セクションにある「スキーマに保存」をクリックします。現在のスキーマとの変更内容の差分を確認し、問題がなければ「保存」をクリックします。 現在のスキーマの確認画面 データセット分析情報 提供される機能 データセット分析情報は、単一のデータセット内に存在する複数のテーブル間の関係性を把握するための機能です。当機能は 2026年4月現在、Preview 公開されています。 テーブル同士をどのように結合すれば意味のあるデータが抽出できるかを AI が推論し、以下の情報を提供します。 データセットの説明 データセット全体の概要を AI が要約して提供します。 リレーションシップグラフ データセット内のテーブル間の関係性を示す図を表示します。線にカーソルを合わせると、どのカラムをキーにして結合できるかといった詳細を確認できます。 リレーションシップテーブル テーブル間の関係性を表形式で一覧表示します。関係性の根拠として、明示的なシステム上の制約(外部キーなど)、過去のクエリの実行履歴に基づく使用状況、またはテーブル名やカラム名からの AI による推論が含まれます。 クエリの推奨 複数のテーブルを結合してデータを抽出するための、実践的な SQL クエリのサンプルを提供します。 生成手順 Google Cloud コンソール画面から、データセット分析情報を公開せずに生成する手順は以下のとおりです。 Google Cloud コンソールを開き、BigQuery Studio の画面に移動します。 画面左側の「エクスプローラ」ペインで、対象のプロジェクト名のツリーを選択し、分析したいデータセットをクリックします。 画面右側にデータセットの詳細情報が表示されるため、上部のタブメニューから「分析情報」タブを選択します。 分析情報タブの画面 画面内の「公開せずに生成」ボタンをクリックします。 分析情報の生成には数分程度かかる場合があります。生成が完了すると、AI によって提案されたデータセットの概要やリレーションシップグラフなどが同じ画面に表示されます。 例:Relationships の図 例:リレーションテーブル 制限事項 データ分析情報を使用する際の主な制限事項は以下のとおりです。 サポートされるテーブルは、BigQuery ネイティブのテーブル、BigLake テーブル、外部テーブル、ビュー カラムレベルのアクセス制御が設定されているテーブルに対して分析情報を生成するには、実行ユーザーが対象テーブルのすべてのカラムに対する読み取り権限を持っている必要がある テーブル分析情報において、AI が説明文を自動生成できるのは 1 テーブルあたり最大 350 カラムまで 新たにデータセット分析情報を生成すると、対象データセットに対する以前の分析情報は上書きされる マルチクラウド環境に保存されている、他クラウドのデータは対象外 参考 : BigQuery でデータ分析情報を生成する - 制限事項 料金 データ分析情報の機能自体に対する追加料金は発生しません。 データ分析情報は、Google Cloud プロジェクトにおいて、以下のいずれかの BigQuery 料金体系を適用している場合に使用できます。 オンデマンド Enterprise エディション Enterprise Plus エディション プロジェクトに BigQuery Editions の Standard エディションが適用されている場合は、データ分析情報を使用できないので注意してください。 また、生成された SQL クエリを BigQuery で実行した際には、通常の BigQuery のコンピューティング料金(データスキャンに対する課金など)が発生します。 参考 : Gemini for Google Cloud の料金 - Gemini in BigQuery の料金の概要 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー(猫)」。
G-gen の奥田です。当記事は、2026年3月19日に開催された Agentic AI Summit 2026 Spring で筆者と弊社の今野が登壇したセッション「Gemini Enterprise と ADK で実現する業務特化型エージェント開発の最前線 — ユーザー認証連携における Google Workspace 操作の実装方法と事例を公開」のレポートです。 セッションの概要 なぜ AI エージェントにユーザー認証が必要なのか サービスアカウントのリスク OAuth 2.0 によるユーザー認証連携 デモ : 議事録カレンダー登録エージェント デモの概要 Google Workspace への応用 なぜ ADK を選んだのか コードの実装 構成図とソースコードのディレクトリ構成 エージェントの定義 認証トークンの取得とカレンダー API の呼び出し 開発中に遭遇した落とし穴 ADK の State オブジェクト LiteLLM のセキュリティに関する注意 Gemini Enterprise へのデプロイ 参考リンク セッションの概要 当セッションでは、AI エージェントが Google Workspace のサービスを操作する際に不可欠な ユーザー認証連携 をテーマに、実装方法と事例を紹介しました。 セッション前半では、AI エージェントにおける認証の重要性を具体的なシナリオで解説し、議事録から Google Calendar にイベントを自動登録するエージェントのライブデモを行いました。後半では、 Gemini Enterprise 、 Agent Development Kit (以下、 ADK )、 Agent Engine を組み合わせたアーキテクチャと、 OAuth 2.0 連携の実装ステップを紹介しました。 参考 : Gemini Enterprise 参考 : Agent Development Kit(ADK) 参考 : Agent Engine 参考 : OAuth 2.0 Agentic AI Summit 2026 Spring での実績は以下のとおりです。 合計 オンライン オフライン CSAT G-gen セッション 741 名 556 名 185 名 3.9 なぜ AI エージェントにユーザー認証が必要なのか サービスアカウントのリスク AI エージェントを業務で利用する場合、「エージェントが誰として外部サービスにアクセスするのか」が重要な設計課題です。 たとえば、社員 A さんが AI エージェントに「来週の火曜日に会議を入れて」と依頼したとします。エージェントは A さんの代わりに Google Calendar を操作する必要があります。このとき、システム共通のサービスアカウントに権限を一括付与して動かすと、エージェントは A さんだけでなく B さんや他の組織の C さんのカレンダーにもアクセスできてしまいます。 技術的には動作しますが、業務での利用には適しません。AI エージェントは人間と違い、バックグラウンドで大量のデータに触れることができます。だからこそ「誰として動いているのか」を明確に設計することが不可欠です。 OAuth 2.0 によるユーザー認証連携 この課題の解決策が OAuth 2.0 を使ったユーザー認証連携です。 仕組みはシンプルです。ユーザーが一度ログインして権限を許可すると、エージェントはそのユーザーのアクセストークンを使って API を呼び出します。エージェントはそのユーザーの権限の範囲内でしか動作しません。 A さんの AI エージェントが行った操作は「A さんが自分の権限で実行した」という記録です。コンプライアンスの観点でも重要なポイントです。 デモ : 議事録カレンダー登録エージェント デモの概要 セッションでは、議事録や ToDo メモからタスクを抽出し、Google Calendar にイベントを自動登録するエージェントのライブデモを行いました。 デモの流れは以下のとおりです。 Gemini Enterprise 上でエージェントを起動し、OAuth 認証を完了する 直近のカレンダー予定を確認する 日時とタイトルを入力してイベントを追加する 約 6,300 文字の架空の議事録(ポータルサイトプロジェクト)をエージェントに渡す エージェントが議事録から 9 個の ToDo を抽出し、カレンダーに一括登録する 不要なプライベートの予定を削除する デモで約 6,300 文字の議事録を使用したのは、 Gemini の従来の強みである大規模コンテキストウィンドウを利用するため です。長文の議事録であっても分割せずに一度で処理できることを示す狙いがありました。 エージェントは 9 個のタスクを抽出しましたが、そのうち 2 つは会議のアイスブレイク時に話題に上がったプライベートな内容(入学式の話)でした。エージェントがこれらを業務タスクと同列に扱ってカレンダーに登録しました。 デモ後半では「プライベートの予定を削除」と入力するだけで、エージェントが自律的に予定の性質を判断し、該当するイベントのみを削除しました。これは、エージェントが文脈を理解し、カレンダーの内容を自律的に評価した実践的な事例です。 このエージェントの導入効果として、 議事録 1 件あたりのカレンダー登録作業を手動10分から自動で1分程度に短縮 できます。タスクの抜け漏れを防ぐ実用的なエージェントです。 Google Workspace への応用 今回のデモでは Google Calendar を題材にしましたが、同じ OAuth 2.0 連携の仕組みを使うことで、Google Workspace の各サービスにも応用できます。 Gmail では、エージェントがユーザー本人としてメールボックスに下書きを作成したり、宛先・件名・本文を含むメールを送信できます。たとえばミーティングの議事録をまとめて関係者にフォローアップメールを自動送信するといった使い方が可能です。 Google ドキュメント や Google スライド では、箇条書きや構成案を渡すだけでドキュメントやスライドの雛型を作成できます。ユーザーはブラッシュアップやクリエイティブな作業に集中できます。 Google ドライブ では、ユーザー自身がアクセス権を持つファイルだけを検索できるため、他者のファイルに触れるリスクがありません。社内ドキュメントをナレッジベースとして RAG 構成と組み合わせる使い方が効果的です。 共通するポイントは、すべての操作がユーザー本人の権限の範囲内で動作することです。 なぜ ADK を選んだのか エージェント開発のフレームワークには LangChain や CrewAI など複数の選択肢があります。今回 ADK を採用した理由は大きく2つです。 1つ目は、 Google Cloud のエコシステムで完結させたかった ことです。フロントエンドの Gemini Enterprise、実行基盤の Agent Engine、そして開発フレームワークの ADK をすべて Google Cloud のサービスで統一することで、認証トークンの受け渡しやデプロイがマネージドサービス間でシームレスに連携します。前述のとおり、 tool_context.state を通じた OAuth トークンの自動受け渡しは、この統一されたエコシステムがあってこそ実現できる仕組みです。 2つ目は、 ADK と OAuth 2.0 を組み合わせた実装事例がまだ少なかった ことです。ADK 自体の利用例は増えていますが、Gemini Enterprise の OAuth 連携と組み合わせて Google Workspace を操作するパターンは、2026年4月現在でも公開事例が限られています。今回のセッションとデモを通じて、この実装パターンを広く共有したいという意図がありました。 コードの実装 構成図とソースコードのディレクトリ構成 構成図は以下です。 ソースコードは GitHub で公開しています。 参考 : G-gen-Tech-Blog/agentic-ai-summit-2026-spring-session-report リポジトリのディレクトリ構成は以下です。 . ├── __init__.py ├── agent.py # エージェント定義 ├── tools.py # ツール関数(Calendar API 操作) ├── config.py # 設定値の管理 ├── requirements.txt # 依存パッケージ ├── .env_example # 環境変数のサンプル ├── .gitignore └── README.md エージェントの定義 以下は ADK でエージェントを定義する agent.py の全体です。49 行でエージェントの定義が完結しています。 # agent.py from google.adk.agents.llm_agent import Agent from . import tools from google.adk.models.lite_llm import LiteLlm root_agent = Agent( name= "calendar_agent" , model=LiteLlm( "vertex_ai/gemini-3-flash-preview" , vertex_location= "global" ), description= "議事録を解析して Google Calendar にイベントを登録するエージェント" , instruction= """あなたは議事録からTodoを抽出して Google Calendar に登録するアシスタントです。 以下の手順で作業してください。 1. ユーザーから議事録を受け取る。 - ファイルパスが渡された場合は read_todo_file ツールでファイルを読み込む。 2. テキスト内容を解析し、議事録からTodoとそれに関係する情報を抽出する: - 日付・時刻(今年は2026年。月/日 の形式なら 2026年として解釈する) - イベントタイトル - 説明(あれば) - 終日イベントかどうか 3. 抽出した各イベントについて create_calendar_event ツールを呼び出して登録する。 - 日時は ISO 8601 形式にする(例: 2026-02-20T14:00:00) - 終日イベントの場合は日付のみ(例: 2026-03-01)、end_datetime は翌日にする - 時間の指定がない場合は終日イベントとして扱う - 終了時刻の指定がない場合は開始から1時間後を終了時刻とする - タイムゾーンは Asia/Tokyo 4. Todo テキストに参加者(メールアドレス)の記載があれば attendees に指定する。 ユーザーが参加者を指定した場合は、そのメールアドレスを追加する。 5. 登録結果をユーザーに報告する。 注意事項: - すべての日時は日本時間 (JST, Asia/Tokyo) を基準とする。 時刻の指定がある場合は日本時間として解釈すること。 - テキストは自由形式。「2/20 14:00 美容院」のようなフォーマットもあれば、 文章形式の場合もある。柔軟に解析すること。 - 日付が曖昧な場合は確認を求める。 """ , tools=[ tools.read_todo_file, tools.create_calendar_event, tools.list_calendar_events, tools.update_calendar_event, tools.delete_calendar_event, ], ) Agent クラスの model に LiteLlm で gemini-3-flash-preview (2026年4月現在)を指定しています。 instruction にはシステムプロンプトとして議事録の解析手順を記述し、 tools に呼び出し可能なツール関数を登録しています。 ADK では LiteLlm を使うことで Gemini 以外のモデル(Claude、GPT など)にも切り替えられます。 参考 : ADK LiteLLm ドキュメント 認証トークンの取得とカレンダー API の呼び出し 今回の構成で最も注目すべきポイントは、Gemini Enterprise・ADK・Agent Engine の3つのサービスが連携してユーザーの認証トークンをシームレスに受け渡す仕組みです。 通常、OAuth 2.0 を使ったアプリケーション開発では、トークンの取得・保存・リフレッシュ・有効期限の管理といった複雑な認証フローを開発者自身が実装する必要があります。しかし、Google Cloud のエコシステムではこの課題が解消されています。ユーザーが Gemini Enterprise 上で OAuth 認証を完了すると、取得されたアクセストークンは Agent Engine のセッションに自動で保存されます。ADK のツール関数では、引数として渡される ToolContext の state からそのトークンをわずか1行で取得できます。 この「Gemini Enterprise(認証 UI)→ Agent Engine(トークン管理)→ ADK(トークン利用)」という一連の流れが、Google Cloud のマネージドサービス間で自動的に実現される点が、このエコシステムの大きなメリットです。 以下の get_calendar_service 関数がその実装の核心です。 from google.oauth2.credentials import Credentials from googleapiclient.discovery import build from google.adk.tools import ToolContext def get_calendar_service (tool_context: ToolContext): """ Agent Engine 環境で Google Calendar サービスを認証・生成します。 """ # 1. 環境変数から管理画面で設定した ID を取得 auth_id = os.getenv( "AUTH_ID" ) # 2. トークンの取得を試みる access_token = tool_context.state.get(auth_id) if not access_token: access_token = tool_context.state.get( "authentication" ) # 3. トークンが見つからない場合 if not access_token: raise ValueError ( "認証トークンが取得できませんでした。" "チャット画面で Google ログインを完了させているか確認してください。" ) # 4. 取得したトークンでカレンダーサービスを構築 creds = Credentials(token=access_token) return build( "calendar" , "v3" , credentials=creds) ポイントは tool_context.state.get(auth_id) のわずか1行です。この1行の背後では、以下の処理が Google Cloud のマネージドサービスによって自動的に行われています。 Gemini Enterprise がユーザーに OAuth 同意画面を表示し、認可コードを取得する Agent Engine が認可コードをアクセストークンに交換し、セッションの state に保存する ADK のツール関数が ToolContext 経由でそのトークンを取得する 開発者が実装するのは tool_context.state.get(auth_id) でトークンを取り出し、 Credentials に渡す部分だけです。トークンの取得フロー、リフレッシュ、有効期限の管理はすべてマネージドサービス側が担います。 認証フローの実装が、Google Cloud のマネージドサービス連携により数行のコードに集約されています。 以下は、メインのツール関数である create_calendar_event です。 def create_calendar_event ( summary: str , start_datetime: str , end_datetime: str , tool_context: ToolContext, description: str = "" , timezone: str = "Asia/Tokyo" , attendees: list [ str ] | None = None , ) -> dict : """Google Calendar にイベントを作成する。""" service = get_calendar_service(tool_context) s_dt = start_datetime.strip() e_dt = end_datetime.strip() # 終日イベントかどうかの判定 is_all_day = ( "T" not in s_dt) and ( ":" not in s_dt) if is_all_day: s_dt = s_dt.replace( "/" , "-" ) e_dt = e_dt.replace( "/" , "-" ) event_body = { "summary" : summary, "description" : description, "start" : { "date" : s_dt}, "end" : { "date" : e_dt}, } else : if " " in s_dt: s_dt = s_dt.replace( " " , "T" ) if " " in e_dt: e_dt = e_dt.replace( " " , "T" ) event_body = { "summary" : summary, "description" : description, "start" : { "dateTime" : s_dt, "timeZone" : timezone}, "end" : { "dateTime" : e_dt, "timeZone" : timezone}, } if attendees: event_body[ "attendees" ] = [{ "email" : email} for email in attendees] event = service.events().insert(calendarId= "primary" , body=event_body).execute() return { "status" : "success" , "event_id" : event[ "id" ], "summary" : event[ "summary" ], "html_link" : event[ "htmlLink" ], } get_calendar_service(tool_context) を呼び出すことで、ログイン中のユーザーの権限で Google Calendar API を操作しています。終日イベントと時間指定イベントを date と dateTime で区別し、 attendees パラメータで参加者の追加にも対応しています。 開発中に遭遇した落とし穴 ADK の State オブジェクト 開発中、認証トークンの中身を確認しようとした際に以下のエラーに遭遇しました。 # やりたかったこと:state の中身を一覧表示したい print (tool_context.state.keys()) 上記の様に入力すると、以下の結果になります。 AttributeError: 'State' object has no attribute 'keys' ADK の State オブジェクトは、標準の Python 辞書( dict )ではなく、Python の MutableMapping プロトコルにも準拠していません。辞書のように値の取得や代入はできますが、 .keys() や .items() といった標準的なメソッドは持っていません。これはバグではなく、会話状態の差分追跡を確実に行うための意図的な設計です。 注意すべき点として、ADK には以下2つの state が存在します。 session.state tool_context.state ( context.state ) session.state は標準の Python 辞書( dict )であるため .keys() や .items() が通常どおり使えます。 一方、ツール関数の引数として渡される tool_context.state は前述の State オブジェクトであり、これらのメソッドは使えません。 session.state.keys() は正常に動作するのに tool_context.state.keys() ではエラーになるため、両者を混同するとデバッグ時に混乱を招きます。 ツール関数内では tool_context.state を使うため、 .get() メソッドで安全に値を取り出す必要があります。 # 正しい方法:.get() で安全に取得 access_token = tool_context.state.get(auth_id) 操作は .get() や直接代入( tool_context.state[key] = value )に留めることが推奨されます。ADK を使ったエージェント開発を始める方は、この仕様を事前に把握しておくとデバッグ時間を節約できます。 参考 : Context - Agent Development Kit (ADK) LiteLLM のセキュリティに関する注意 LiteLLM v1.82.7 / v1.82.8 は、サプライチェーン攻撃(TeamPCP)により侵害されました(2026年3月24日)。本デモの GitHub リポジトリのサンプルコードでは v1.83.0(攻撃後の正規リリース、2026年3月31日公開)にピン留めしています。 詳細は以下を参照してください。 参考 : LiteLLM 公式セキュリティアップデート 参考 : GitHub Issue #24518(タイムライン) Gemini Enterprise へのデプロイ 作成したエージェントを Agent Engine にデプロイした後、Gemini Enterprise のコンソールからエージェントを追加できます。画面からの操作のみでデプロイが完了します。 ユーザーごと、またはグループごとにエージェントの利用権限を管理することも可能です。組織全体への安全な展開が実現できます。 参考リンク 参考 : Agentic AI Summit 2026 Spring 参考 : 登壇資料 参考 : G-gen-Tech-Blog/agentic-ai-summit-2026-spring-session-report(ソースコード) 以下の動画でセッションの実演をご覧いただけます。 奥田 梨紗 (記事一覧) クラウドソリューション部データインテリジェンス課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025&2026 Follow @risa_hochiminh
G-gen の佐々木です。当記事では、Pub/Sub から直接 Vertex AI 上の AI モデルによる推論を取得することができる AI 推論 SMT 機能について解説します。 前提知識 Pub/Sub とは Single Message Transforms(SMTs) AI 推論 SMT の機能 基本事項 AI 推論 SMT の利点 使用できるモデル Model Garden で提供されているモデル Vertex AI Endpoints にデプロイしたモデル モデルの入力・出力 入力するメッセージの形式 推論後のメッセージの形式 制限事項 設定手順 手順の概要 サービスアカウントの作成・権限付与 定義ファイルの作成 トピックの作成 AI 推論 SMT を使用するサブスクリプションの作成 動作確認 メッセージのパブリッシュ メッセージの受信 前提知識 Pub/Sub とは Pub/Sub は Google Cloud におけるフルマネージドなメッセージングサービスです。 メッセージングサービスは、システム間に配置することでメッセージを非同期に中継することができます。これにより、システムの拡張性や保守性を向上することができます。 Pub/Sub を始めとしたメッセージングサービスの詳細やユースケースについては、以下の記事をご一読ください。 blog.g-gen.co.jp Single Message Transforms(SMTs) Single Message Transforms (以下、 SMTs )は Pub/Sub を使用したストリーミング処理のパイプラインにおいて単純なデータ変換を実現する機能です。 この機能では、Pub/Sub のトピックとサブスクリプションのそれぞれに対して単純なデータ変換処理を実装します。これにより、データの形式の変換やマスキング、フィルタリングなどの処理を、メッセージの配信前に行うことができます。 SMTs の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp AI 推論 SMT の機能 基本事項 当記事で紹介する AI 推論 SMT (AI Inference Single Method Transform)は、SMTs の機能の1つであり、Vertex AI にある AI モデル(Gemini など)に Pub/Sub のメッセージを渡し、 推論を取得してメッセージに追加することができる 機能です。 通常の SMTs 同様に、AI 推論 SMT はトピックとサブスクリプションのどちらでも設定することができます。 トピックに設定した場合、推論結果がメッセージに追加されたあと、トピックに紐づくすべてのサブスクリプションにメッセージが配信されます。 トピックに対して AI 推論 SMT を設定した場合 サブスクリプションに設定した場合は、そのサブスクリプションでのみ推論を取得するような動作となります。Pub/Sub のユースケースに合わせて設定するとよいでしょう。 サブスクリプションに対して AI 推論 SMT を設定した場合 参考 : AI 推論 SMT 参考 : 単一メッセージ変換(SMT)の概要 - SMT のサンプル メッセージ フロー AI 推論 SMT の利点 AI 推論 SMT を使用してモデル推論とデータ変換を行う場合、以下のようなメリットがあります。 メッセージに対してリアルタイムで AI モデルによる推論結果を追加することができる(データ エンリッチメント) モデルから推論を取得するための処理をアプリケーション側に実装する必要がなくなる サブスクリプションに設定した場合、Pub/Sub はモデル エンドポイントの過負荷を回避し推論のスループットを最大化するため、リクエストレートを最適化する(フロー制御) ※ 単項 pull では最適化されない点に注意 参考 : AI 推論 SMT - メッセージ フロー 使用できるモデル Model Garden で提供されているモデル AI 推論 SMT では、トピックまたはサブスクリプションを作成する際にモデルの推論用のエンドポイントを指定します。 Vertex AI Model Garden で提供されているモデルを使用する場合、以下のような形式でエンドポイントを指定します。 - ai - aiInference : endpoint : "projects/<プロジェクトID>/locations/<モデルを利用するリージョン>/publishers/<モデルのパブリッシャー>/models/<モデル名>" 使用できるモデルの一覧については、以下のドキュメントで最新の情報を確認してください。 参考 : AI 推論 SMT - 互換性のある MaaS モデル Vertex AI Endpoints にデプロイしたモデル ユーザーが Vertex AI Endpoints を使用して Google Cloud 上にデプロイしたモデル(セルフデプロイ モデル)を推論に使用することもできます。 セルフデプロイ モデルを使用する場合は、モデルのエンドポイントの指定の仕方が異なります。 - aiInference : endpoint : "projects/<プロジェクトID>/locations/<エンドポイントのリージョン>/endpoints/<エンドポイント>" 参考 : エンドポイントにモデルをデプロイする モデルの入力・出力 入力するメッセージの形式 AI 推論 SMT による推論を行うためには、Pub/Sub に入力されるメッセージが特定の形式になっている必要があります。 例えば gemini-2.5-flash のような Gemini 基盤モデルを使用する場合、 Chat Completions API を使用して Gemini が呼び出されるため、以下のように Pub/Sub トピックに送信するメッセージの形式を API の仕様に合わせます。 { " model ":" google/gemini-2.5-flash ", " messages ": [ { " role ": " user ", " content ": " Explain how AI works in a few words " } ] } 参考 : AI 推論 SMT - メッセージ処理 推論後のメッセージの形式 AI 推論 SMT によって取得したモデルのレスポンスは、以下のように元のメッセージに追加されます。 { " original_message ": " <元のメッセージ> ", " model_output ": " <推論によって取得したモデルのレスポンス> " } 制限事項 AI 推論 SMT には以下のような制限事項があります。 トピックまたはサブスクリプションに設定できる AI 推論 SMT の数は1つまで Vertex AI Endpoints のプライベート エンドポイントはサポートされていない(公開エンドポイントのみ使用可) グローバル エンドポイントは、Gemini 基盤モデルでのみサポートされる。その他のモデルではリージョン エンドポイントのみ使用可能 Pub/Sub 側では入力されたメッセージのデータ形式などの検証は行われない。トピックにメッセージを送信する前に検証する必要がある 1つのメッセージごとに1つの推論リクエストのみが可能であり、バッチ推論は不可 指定したモデルによる推論は60秒以内に完了する必要がある 推論が60秒を超過するとタイムアウトとなり、Pub/Sub に設定したメッセージ保持期間と再試行回数の上限まで再試行が行われ、その後デッドレタートピックにメッセージが転送されます。 その他、制限事項に関する最新情報は以下のドキュメントをご一読ください。 参考 : AI 推論 SMT - 制限事項 設定手順 手順の概要 当記事で紹介する手順は、サブスクリプションに対して AI 推論 SMT によるメッセージ変換を設定し、そのサブスクリプションのコンシューマーに対してのみ推論結果を含めたメッセージを配信できるようにするためのものです。 参考 : AI 推論 SMT - AI 推論 SMT を作成する サービスアカウントの作成・権限付与 AI 推論 SMT を使用する場合、Cloud Pub/Sub サービスエージェント( service-<プロジェクト番号>@gcp-sa-pubsub.iam.gserviceaccount.com )に対して Vertex AI サービス エージェント ( roles/aiplatform.serviceAgent )ロールを付与するか、カスタムサービスアカウントに対して Vertex AI ユーザー ( roles/aiplatform.user )ロールを付与します。 当記事ではカスタムサービスアカウントを使用します。 # サブスクリプション用のサービスアカウントを作成 $ gcloud iam service-accounts create pubsub-ai-inference-smt \ --display-name =" Pub/Sub AI Inference SMT " # Vertex AI ユーザー ロールの付与 $ gcloud projects add-iam-policy-binding < プロジェクトID > \ --member =" serviceAccount:pubsub-ai-inference-smt@<プロジェクトID>.iam.gserviceaccount.com " \ --role =" roles/aiplatform.user " 定義ファイルの作成 ai-smt.yaml という名前で AI 推論 SMT の定義ファイルを作成します。これをトピックもしくはサブスクリプションの作成時に指定することで、AI 推論 SMT を使用することができます。 - aiInference : endpoint : "projects/<プロジェクトID>/locations/asia-northeast1/publishers/google/models/gemini-2.5-flash" unstructuredInference : { parameters : { "temperature" : 0.5 , "max_tokens" : 1000 } } serviceAccountEmail : "pubsub-ai-inference-smt@<プロジェクトID>.iam.gserviceaccount.com" endpoint にはモデルのエンドポイントを指定します。 unstructuredInference.parameters には、モデルに推論リクエストを送信する際のパラメータや最大トークン数などを指定できます。 serviceAccountEmail には、先ほど作成したサービスアカウントを指定します。 トピックの作成 Pub/Sub のトピックを作成します。 # トピックの作成 $ gcloud pubsub topics create ai-smt-topic トピックに AI 推論 SMT を設定する場合、ここで --message-transforms-file オプションを使用します。 参考 : gcloud pubsub topics create AI 推論 SMT を使用するサブスクリプションの作成 トピックに紐付けるサブスクリプションを作成します。 当記事ではサブスクリプション側に AI 推論 SMT によるメッセージ変換処理を設定するため、 --message-transforms-file で先ほど作成した定義ファイルを指定します。 # AI 推論 SMT を使用するサブスクリプションの作成 $ gcloud pubsub subscriptions create ai-smt-topic-sub \ --ack-deadline = 600 \ --topic ai-smt-topic \ --message-transforms-file ai-smt.yaml 動作確認 メッセージのパブリッシュ 作成したトピックに対してメッセージをパブリッシュしてみます。 AI 推論 SMT で Gemini モデルを指定しているため、 --message には、 Chat Completions API の仕様に合わせた形式でメッセージを設定します。 # プロンプトを含むメッセージのパブリッシュ $ gcloud pubsub topics publish ai-smt-topic --message =$' { "model":"google/gemini-2.5-flash","messages":[{ "role": "user", "content": "Vertex AI について簡単に説明して" }] } ' 参考 : gcloud pubsub topics publish メッセージの受信 サブスクリプションに配信されたメッセージを確認します。 # メッセージを受信し、データを復号したあと JSON に変換 $ gcloud pubsub subscriptions pull ai-smt-topic-sub \ --auto-ack \ --format =" value(message.data.decode(base64)) " | jq . 受信したメッセージには、元のメッセージである "original_message" に加え、サブスクリプション側の AI 推論 SMT によって "model_output" が含まれていることがわかります。 以下は受信したメッセージの例です。 { " model_output ": { " choices ": [ { " finish_reason ": " stop ", " index ": 0 , " logprobs ": null , " message ": { " content ": " Vertex AI は、Google Cloud が提供する、**機械学習(ML)開発のための統合プラットフォーム**です。 \n\n 簡単に言うと、MLモデルを開発する際に必要な「データの準備」「モデルの構築」「トレーニング」「デプロイ(公開)」「監視・管理」といった**あらゆる工程を、一つの場所で効率的に行えるようにするための「ワンストップショップ」**のようなものです。 \n\n **主なポイント:** \n\n 1. **統合された環境:** これまでバラバラだったML開発のツールやサービスを一つにまとめ、開発プロセスをシンプルにします。 \n 2. **効率化と高速化:** データサイエンティストやMLエンジニアが、インフラの管理に時間を取られることなく、モデルの開発や改善に集中できるよう設計されています。 \n 3. **幅広い対応:** カスタムモデルの構築はもちろん、画像認識や自然言語処理などの特定のタスクに対応した事前学習済みモデルの利用や、AutoML(自動機械学習)機能も提供します。 \n 4. **スケーラビリティ:** Googleの強力なインフラ上で動作するため、大規模なデータや複雑なモデルのトレーニングも柔軟に対応できます。 \n\n 例えるなら、ML開発に必要なあらゆる道具が揃った「高機能な作業台」のようなものです。これにより、企業はより迅速にMLをビジネスに導入し、価値を生み出すことができるようになります。 ", " role ": " assistant " } } ] , " created ": 1775550770 , " id ": " MsHUaYLcFaKTp_QP1_SwiAw ", " model ": " google/gemini-2.5-flash ", " object ": " chat.completion ", " system_fingerprint ": "", " usage ": { " completion_tokens ": 263 , " completion_tokens_details ": { " reasoning_tokens ": 1066 } , " extra_properties ": { " google ": { " traffic_type ": " ON_DEMAND " } } , " prompt_tokens ": 6 , " total_tokens ": 1335 } } , " original_message ": { " messages ": [ { " content ": " Vertex AI について簡単に説明して ", " role ": " user " } ] , " model ": " google/gemini-2.5-flash " } } 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出(2024 / 2025 Fellow / 2026)。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説(SF、ミステリ)、カラオケなど。 Follow @sasashun0805
G-gen の菊池です。BigQuery においてクエリを保存・管理するための3つの手法(保存済みクエリ、スケジュールされたクエリ、BigQuery パイプライン)と、それぞれの特徴や確認方法について解説します。 はじめに 保存済みクエリ 概要 設定方法 保存場所 特徴・利点 スケジュールされたクエリ 概要 設定方法 保存場所 特徴・利点 BigQuery パイプライン 概要 設定方法 保存場所 特徴・利点 クエリが見つからない場合の確認フロー はじめに BigQuery では、作成した SQL クエリを再利用したり自動実行したりするために、複数の保存・管理方法が用意されています。 2026年3月現在、主に以下の手法が提供されていますが、それぞれ管理される場所や用途が異なるため、作成したはずのクエリが見当たらないといった混乱が生じることがあります。 保存済みクエリ スケジュールされたクエリ BigQuery パイプライン 当記事では、これらの違いと、それぞれのクエリが Google Cloud コンソールのどこに表示されるかを整理します。 なお BigQuery 自体の詳細な解説については、以下の記事も参照してください。 blog.g-gen.co.jp 保存済みクエリ 概要 保存済みクエリ (saved queries)は、クエリエディタで作成した SQL を Google Cloud コンソール上に保存し、自分自身での再利用やチームメンバーとの共有を可能にする機能です。 参考 : 保存済みクエリを管理する 設定方法 クエリ エディタで SQL を記述後、ツールバーの [保存] > [クエリを保存] をクリックします。 クエリを保存 なお、プルダウンメニュー内にある「クエリ(従来)を保存」は旧来型の機能であり、バージョニングや他人への共有をすることができない保存方法です。現在では使用は推奨されません。 次に [クエリを保存] ダイアログで、クエリの名前を入力して、 [保存] をクリックします。 クエリの名前を入力して保存 保存場所 Google Cloud のコンソールで BigQuery のページに移動します。 [左ペインを開く] マークをクリックして、 [エクスプローラ] タブをクリックします。 左ペインのエクスプローラタブ プロジェクト名をクリックして開き、 [クエリ] をクリックします。 保存済みクエリの表示 保存済みクエリの一覧が表示されます。 保存済みクエリの一覧 特徴・利点 保存済みクエリには、自動的なバージョニング機能が備わっています。保存を実行するたびに新しいバージョンが記録されるため、過去の履歴を遡って以前の構文を確認したり、特定の時点の状態を参照したりすることが可能です。 保存済みクエリのバージョン履歴 また、保存したクエリごとに固有のリンク(URL)を発行できる点も大きな利点です。共有相手に適切な Identity and Access Management(以下、IAM)権限を付与することで、クエリを安全かつ迅速にチームメンバーへ共有できます。 スケジュールされたクエリ 概要 スケジュールされたクエリ (scheduled queries)は、特定の SQL クエリを定期的(日次、週次、あるいはカスタムの間隔)に自動実行するための機能です。 なおスケジュールされたクエリは、バックエンドで BigQuery Data Transfer Service の仕組みを使用しているため、スケジュールを設定済みのクエリは BigQuery Data Transfer Service のジョブ一覧に表示されます。 参考 : クエリのスケジューリング 設定方法 クエリ エディタで SQL を記述後、ツールバーの [スケジュール] をクリックします。 スケジュールをクリック スケジュールされたクエリを設定する画面が表示されるので、名前や繰り返しの設定をして [保存] をクリックします。 スケジュールの設定 保存場所 コンソール左側のナビゲーションメニューにある [スケジュールされたクエリ] をクリックします。 スケジュールされたクエリの選択 スケジュールされたクエリの一覧が表示され、作成済みの設定一覧や実行履歴、実行ステータスを確認できます。 スケジュールされたクエリ一覧 特徴・利点 スケジュールされたクエリを利用することで、定期的なデータの集計や中間テーブルの更新といった定型処理を自動化できます。 クエリの実行結果を指定したテーブルに上書き、あるいは追記するように制御できるほか、実行完了時や失敗時にメール通知を送信する設定も可能です。 BigQuery パイプライン 概要 BigQuery パイプライン (BigQuery pipelines)は、複数のデータ処理ステップをワークフローとして統合管理する機能です。 内部的には Dataform を使用しており、データの依存関係を考慮した複雑な処理体系を Google Cloud コンソール上で直接構築できます。 参考 : BigQuery パイプラインの概要 設定方法 コンソール左側の [エクスプローラ] タブでプロジェクト名をクリックして開き、 [パイプライン] をクリックします。 パイプライン一覧を開く パイプラインの一覧が表示されます。 [+パイプライン] をクリックして、パイプラインを新規作成します。 パイプライン一覧画面からの作成 あるいは、エディタペインのタブバーで [+] 記号の横にある 矢印マークをクリックし、 [パイプライン] をクリックすることでも新規作成できます。 エディタペインからのパイプライン作成 パイプライン画面 新規作成したパイプラインの画面で、 [タスクを追加] > [クエリ] をクリックします。 クエリを追加 クエリタスクが追加されるので、 [クエリを編集] をクリックします。 クエリを編集 クエリタスクの編集画面が表示されるので、クエリタスク名を修正してクエリを記載したら、 [クエリを保存] をクリックします。 クエリタスクの保存 保存場所 パイプラインで保存したクエリを確認するには、設定方法で開いたパイプライン一覧画面から、対象のパイプラインを選択します。 パイプライン選択 パイプラインの画面で確認したいクエリタスクをクリックすることで、クエリが表示されます。 パイプラインのクエリ確認 BigQuery パイプラインで作成されたクエリは、プロジェクト内の Dataform で管理されます。そのため、通常の [保存済みクエリ] や [スケジュールされたクエリ] の一覧には表示されません。 パイプラインのスケジュール実行は、 Dataform のワークフロー構成として管理されるため、 [スケジュールされたクエリ] の一覧にも表示されません。 特徴・利点 BigQuery パイプラインの最大の特徴は、複数のタスク間における依存関係を視覚的に管理できる点です。先行する処理が成功した後に後続の処理を実行するといった、複雑なクエリやテーブル更新の前後関係をキャンバス上で直感的に構築できます。 パイプラインのクエリの依存関係 クエリが見つからない場合の確認フロー 作成したクエリがどの機能で作成されたかによって、確認すべき場所が異なります。以下の表を参考に、適切な場所を確認してください。 手法 コンソールの確認場所 主な用途 保存済みクエリ エクスプローラタブ > 保存済みクエリ SQL の断片や定型文の保存・共有 スケジュールされたクエリ ナビゲーションメニュー > スケジュールされたクエリ 単一クエリの定期的な自動実行 BigQuery パイプライン エクスプローラタブ > パイプライン 依存関係を持つ複雑な ETL 処理の管理 「パイプラインを使い始めたが、保存したはずのクエリが [保存済みクエリ] に表示されない」、「パイプラインでスケジュールを設定したが、 [スケジュールされたクエリ] に表示されない」という場合は、前述したコンソールの確認場所から BigQuery パイプライン の項目を確認してください。 BigQuery パイプラインは内部で Dataform を使用しており、 保存済みクエリやスケジュールされたクエリとは独立した管理体系になっています。管理される場所が異なる点に注意が必要です。 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、GCPは未経験なので現在勉強中。
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 エージェントプラットフォームである Agent Runtime (旧称 : Vertex AI Agent Engine)について解説します。 はじめに Agent Platform とは Agent Runtime とは 他のエージェント実行基盤との比較 Agent Runtime の基本 エージェントの開発 エージェントの実行環境 実行環境の基本事項 コールドスタート エージェントの使用 エージェントに対する権限付与 補助的な機能 セッション Memory Bank Code Execution Example Store(プレビュー機能) エージェントの品質評価 オブザーバビリティ モニタリング ロギング トレース セキュリティ 料金 はじめに Agent Platform とは Gemini Enterprise Agent Platform (旧称 : Vertex AI、以下 Agent Platform と記載)は、Google Cloud 上で AI エージェントを構築、管理、実行するために必要な機能を提供する統合プラットフォームです。 Agent Platform では、エージェント開発を容易にするオープンソース フレームワークである Agent Development Kit (ADK)、ユースケースに応じたエージェントのサンプルが多数提供される Agent Garden 、GUI を用いてローコードでエージェントの設計・テストを行うことができる Agent Designer 、そして当記事で紹介する Agent Runtime などの、エージェントの構築に役立つ各種機能が提供されています。 参考 : Agent Platform の概要 Agent Runtime とは Agent Runtime は、Agent Platform に内包されたプロダクトの1つで、エージェントを実行するためのフルマネージドの実行基盤を提供します。 Agent Runtime では、組み込みの機能としてエージェントのマルチターン会話を実現する セッション 機能や 自動スケーリング 機能、その他エージェントの機能拡張・運用管理に必要な様々な機能を利用することができます。 参考 : エージェント ランタイム 他のエージェント実行基盤との比較 Google Cloud における代表的なエージェント実行基盤としては、Agent Runtime の他に Cloud Run 、 Google Kubernetes Engine (GKE)などがあります。 Cloud Run では、Agent Runtime と同様にサーバーレスの実行基盤でエージェントを実行することができます。Agent Runtime と比較して実行環境のカスタマイズ性が高い反面、セッションの保持のようなエージェント特有の機能は Cloud SQL や Firestore などのサービスと連携するなどして独自に実装する必要があります。 GKE では Agent Runtime や Cloud Run と比較して、コンピューティングリソースやネットワーク等インフラストラクチャの細かい制御が可能です。Kubernetes によるカスタマイズ性の非常に高いエージェント実行基盤を構築することができますが、トレードオフとして環境の構築・運用コストが高くなります。 実行環境 Agent Runtime Cloud Run GKE セッション機能 組み込み 独自実装 独自実装 自動スケーリング 組み込み 組み込み 独自実装 実行環境のカスタマイズ性 低い 中程度 高い 環境の構築、運用コスト 低い(サーバーレス) 低い(サーバーレス) 高い(マネージド Kubernetes クラスタ) Google Cloud 上で新たに AI エージェントの構築を検討する際は、まずはエージェントの実行に特化した Agent Runtime の利用を検討し、Agent Runtime では実現できない要件がある場合に Cloud Run や GKE を検討するのが良いでしょう。 参考 : Choosing the Right Deployment Path for Your Google ADK Agents Agent Runtime の基本 エージェントの開発 Agent Runtime では、Agent Development Kit(ADK)や LangChain、LangGraph などのフレームワークで開発したエージェントのほか、フレームワークに依存しない独自のエージェント(カスタムエージェント)をデプロイすることができます。 2026年3月現在、Agent Runtime にエージェントをデプロイするには、Agent Platform SDK または REST API、ADK 用の CLI などを用いてデプロイ用の API を呼び出す必要があります。Google Cloud コンソールや gcloud CLI によるデプロイはサポートされていません。 以下の記事では、ADK を用いて開発したエージェントを Agent Runtime にデプロイする手順を解説しています。 blog.g-gen.co.jp 参考 : Aエージェント ランタイム - サポートされているフレームワーク 参考 : エージェントをスケーリングする 参考 : エージェントをデプロイする エージェントの実行環境 実行環境の基本事項 Agent Runtime にデプロイしたエージェントは、Google Cloud が管理するフルマネージドの実行基盤で実行されます。 Agent Runtime にデプロイしたエージェントに対してリクエストが送信されると、Agent Runtime はリクエストを処理するための コンテナインスタンス を起動し、その上でエージェントを実行します。 したがって、Agent Runtime のインスタンスは Cloud Run のように サーバーレス であり、必要なときだけコンピューティングリソースを確保してエージェントを実行するという特徴があります。 2026年4月現在はプレビュー提供の機能ですが、起動するコンテナインスタンスが確保するコンピューティングリソース(CPU、メモリ)や、コンテナインスタンスの最小・最大数、インスタンスあたりのエージェントの同時実行数は、エージェントのデプロイ時に指定することができます。 項目 設定値 デフォルト値 CPU(vCPU) 1, 2, 4, 6, 8 4 メモリ(Gi) 1, 2, 4, 8, 16, 32 4 最小インスタンス数 0~10 1 最大インスタンス数 1~1,000 10 エージェント同時実行数 1以上 9 参考 : エージェント ランタイム 参考 : エージェントをスケーリングする 参考 : カスタマイズされたリソース制御を定義する コールドスタート Agent Runtime では、起動中のインスタンスがない場合、もしくは現在起動中のインスタンスでリクエストを処理しきれない場合に、それを処理するためのインスタンスを追加で起動します。 このような仕様から、コンテナインスタンスの起動待機時間により、エージェントのレスポンスが遅くなることがあります( コールドスタート )。コールドスタートによる平均レイテンシーは約4.7秒とされています。 これを回避するためには、常に起動したままにするインスタンスの数(min_instances)をリクエストの量に応じた適切な数(1以上)に設定します。 2026年4月現在、min_instances の設定はプレビュー提供の機能となっており、min_instances の値を1以上に設定していても、エージェントがアイドル状態の間はコンピューティングリソースの料金が発生しません。しかし、この仕様は将来的には変更される可能性があるため、適切なインスタンス数を設定できるようにパフォーマンスのモニタリングを行うことが重要です。 参考 : エージェント ランタイムのパフォーマンスを最適化してスケーリングする - コールド スタートの問題 エージェントの使用 Agent Runtime で実行されるエージェントは、Agent Platform SDK や REST API を使用して呼び出すことができます。 また、Agent Development Kit(ADK)を使用して開発したエージェントであれば、Google Cloud コンソールからエージェントを直接呼び出して会話することも可能です。 Google Cloud コンソールからエージェントと会話する 参考 : エージェントを使用する エージェントに対する権限付与 エージェントが BigQuery にアクセスする場合など、Agent Runtime で実行されるエージェントが Google Cloud API を利用する場合、 AI Platform Reasoning Engine サービスエージェント または カスタムサービスアカウント に対して必要な IAM 権限を付与します。 サービスエージェントは以下の形式で Agent Runtime を利用しているプロジェクト内に存在します。 service-<プロジェクト番号>@gcp-sa-aiplatform-re.iam.gserviceaccount.com 参考 : デプロイされたエージェントのアクセスを管理する 補助的な機能 セッション Agent Runtime にデプロイしたエージェントは、ユーザーとエージェントの会話履歴を保持する セッション機能 を組み込みで利用することができます。 セッションはユーザーがエージェントとの会話を開始したときに新たに作成され、ユーザーとエージェントの会話内容を記憶していきます。 セッションは、設定された有効期限か会話の終了によって削除されます。セッションが削除されるとそれまでの会話履歴は失われるため、会話の終了後、再度エージェントを利用するときに以前の会話履歴を参照させたい場合は後述の Memory Bank を利用する必要があります。 セッションは、Agent Development Kit(ADK)で開発したエージェントの場合は何も追加で実装する必要がなく、自動的に処理されます。それ以外の方法でエージェントを実行する場合は、API を利用してセッションを作成・管理することができます。 参考 : Agent Platform セッションの概要 Memory Bank Memory Bank はセッション機能と同様にユーザーとエージェントの会話履歴を記憶する機能です。 セッション機能が特定ユーザーの1つのセッション内の記憶を保持する機能であるのに対して、Memory Bank は特定ユーザーの複数のセッションにまたがる 長期記憶 を保持する機能です。長期記憶により、ユーザーごとにパーソナライズされた会話をセッション間でも継続することができます。 Memory Bank では、LLM を使用して会話の中から意味のある情報を 抽出 し、既存の記憶と 統合 することで記憶内容を洗練する機能と、記憶をマネージドのストレージに保存して必要な時に 検索・取得 する機能が提供されます。 参考 : Agent Platform メモリバンク Code Execution Code Execution はエージェントがタスク内で生成したコードを、エージェントの実行環境とは分離された安全なサンドボックス上で実行する機能です。 サンドボックスでコードを実行するためには、Agent Development Kit(ADK)等を使用してサンドボックスを作成しておき、それを使用してコードを実行するようにエージェントを実装する必要があります。 サンドボックスは1秒以内に高速で起動し、エージェントが生成したコードを実行します。 なお、当機能は2026年4月時点では us-central1 リージョンのみで利用可能となっています。 エージェントが生成したコードを Code Execution サンドボックスで実行する 参考 : Code Execution 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プロンプティング 参考 : Example Store の概要 エージェントの品質評価 Agent Runtime で実行するエージェントの品質は、 Gen AI Evaluation Service を使用して評価することができます。 Gen AI Evaluation Service は Google Cloud コンソールや Agent Platform SDK から利用することができます。評価用のプロンプトのリストをデータセットとしてエージェントに渡して、エージェントから得られた回答を、事前定義された指標やユーザー定義の指標をベースに評価することができます。 参考 : エージェントの評価 参考 : Gen AI Evaluation Service の概要 オブザーバビリティ モニタリング Agent Runtime は Cloud Monitoring と統合されており、組み込みの指標やカスタム指標、アラートを使用してエージェントをモニタリングすることができます。 組み込みの指標としては、以下の指標がサポートされています。 リクエスト数 リクエストのレイテンシー CPU 割り当て時間 メモリ割り当て時間 参考 : モニタリングを設定する ロギング Cloud Logging との統合により、エージェントが標準出力や標準エラー出力に書き込んだログは、デフォルトで Cloud Logging に転送されます。構造化されたログを記録したい場合は、組み込みの Python ロガーや Cloud Logging クライアントを使用します。 なお、Cloud Logging との統合はセッション機能、Memory Bank などの Agent Runtime のサブリソースではサポートされていません。 参考 : ロギングの設定 トレース 2026年4月時点ではプレビュー提供の機能ですが、 Cloud Trace との統合により、エージェントが実行した関数呼び出しや LLM とのやり取りなどをタイムラインとして取得し、個々のオペレーションのパフォーマンスを分析することができます。 参考 : トレースを設定する セキュリティ エージェントの実行基盤として Agent Runtime を使用する場合、Google Cloud が提供するエンタープライズレベルのセキュリティ機能を統合することができます。 例えば、 VPC Service Controls を使用することで、Agent Runtime で実行されるエージェントが BigQuery API や Cloud SQL Admin API などの Google Cloud API に安全にアクセスしつつ、エージェントによるデータの移動を事前定義した境界内に制限することができます。なお、VPC Service Controls は Code Execution のサンドボックスで実行されるコードにも適用されます。 また、セッション機能や Memory Bank で保存されるユーザーの会話履歴は、 顧客管理の暗号鍵(CMEK) を使用して暗号化することができます。 参考 : エージェント ランタイム - エンタープライズ セキュリティ 料金 エージェントの実行基盤のコンピューティングリソースの利用料金として、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/時間 アイドル時間は無料 参考 : Agent Platform の料金 - エージェント ランタイム 佐々木 駿太 (記事一覧) 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 = "Deny project deletion" 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
G-gen のminです。BigQuery の データマスキング 機能を解説します。データマスキングを使うと、機密情報をマスキングして特定できない形でクエリ結果に表示させることができ、分析を阻害せずにデータを保護することができます。 データマスキングとは 概要 列レベルのアクセス制御との違い 仕組み 権限とロール マスキングルールの種類 定義済みルール カスタムマスキングルーチン ルールの優先順位 設定手順 分類とポリシータグの作成 データポリシーの作成 テーブル列へのタグ付け データポリシーの列への直接付与 制約と注意点 互換性のない機能 SQL で利用する際の注意点 コストへの影響 セキュリティの考慮事項 データマスキングとは 概要 BigQuery の データマスキング とは、BigQuery テーブルの特定の列に対して、ユーザーの権限に応じてデータをマスクして表示する機能です。 ポリシータグと呼ばれるタグをテーブルの列に付与することで、誰が機密情報に直接アクセスできるか、あるいはマスクされた状態でアクセスできるか、またマスキングをどのように行うかを定義します。この機能により、分析を阻害せずにデータを保護することができます。 参考 : Introduction to data masking 列レベルのアクセス制御との違い BigQuery で特定の列を保護する他の機能として、 列レベルのアクセス制御 があります。 参考 : BigQueryの列レベルのアクセス制御・行レベルのセキュリティを解説 - G-gen Tech Blog 列レベルのアクセス制御とデータマスキングの主な違いは、「権限がない場合にエラーにするか、マスクして見せるか」という点です。 比較項目 列レベルのアクセス制御 データマスキング 主な目的 特定の列へのアクセス自体を制限する アクセスを許可しつつ、値を加工してマスクする 権限がない場合の挙動 クエリに含めるとエラー(Access Denied)になる 値がマスクされて表示される 分析への影響 クエリ自体が実行できない マスクされた状態で集計や結合が可能 主なユースケース 閲覧を完全に禁止すべき極めて機密性の高い情報 個人の特定は避けつつ、統計分析には利用したい情報 列レベルのアクセス制御では、権限のないユーザーが機密情報の列を含むクエリを実行すると エラー になります。 一方、データマスキングを使用すると、権限のないユーザーでもクエリ自体は成功させつつ、データの値をハッシュ値や NULL、あるいは「XXXX」のように、 別の文字列に置き換えて表示 させることができます。 仕組み データマスキングは、以下のように設定されます。 分類(Taxonomy)とポリシータグの作成 分類はデータの意味的な区分を表すコンテナです。この分類の中に、「個人情報」「機密情報」など複数のポリシータグを定義できます。各ポリシータグには IAM ロールを直接紐づけることが可能です。 データポリシーの作成 ポリシータグに対して、「どのようなマスキングルールを適用するか」と「どのプリンシパルに適用するか」を定義します。 テーブル列への適用 テーブルの列にポリシータグを紐付けます。 ポリシーが適用された列へクエリが実行されると、クエリ実行時に以下のように動的に表示結果に反映されます。 タグに紐づく IAM ポリシーが評価される 対象ユーザーのロールが確認される 必要に応じてマスキングルールが適用される 権限とロール データマスキングの挙動は、ユーザーが持つ IAM ロールによって決定されます。主に以下の2つのロールが関係します。 ロール名 ID 権限の内容 きめ細かい読み取り roles/datacatalog.categoryFineGrainedReader 元のマスクされていない生データを閲覧できる。 マスクされた読み取り roles/bigquerydatapolicy.maskedReader マスクされたデータを閲覧できる。 ユーザーが上記のどちらの権限も持っていない場合、 Access Denied エラーとなり、クエリは失敗します。 マスキングルールの種類 定義済みルール データポリシーには、以下の定義済みのマスキングルールを適用できます。 参考 : Introduction to data masking - Data masking rules ルール名 動作概要 適用可能なデータ型 ハッシュ(SHA-256) 値を SHA-256 でハッシュ化して表示します。同じ値は常に同じハッシュ値になる(決定論的である)ため、JOIN のキーとして利用可能です。 STRING, BYTES メールマスク メールアドレスの @ の前を XXXXX に置き換えます(例: XXXXX@gmail.com )。無効な形式の場合は SHA-256 ハッシュ化されます。 STRING 先頭/末尾 4 文字 先頭または末尾の 4 文字のみを表示し、残りを XXXXX に置き換えます。文字列が短い場合は SHA-256 ハッシュ化されます。 STRING 年月日マスク 日付をその年の1月1日に切り詰めます(例: 2026-02-14 → 2026-01-01 )。 DATE, DATETIME, TIMESTAMP デフォルトのマスキング値 データ型に応じたデフォルト値を返します。 全ての型 NULL 化 NULL を返します。データ型自体もマスクしたい場合に使用します。 全ての型 ランダムハッシュ 読み取りごとに一意のソルトを自動生成して非決定論的にハッシュ化します。同じ値でもクエリごとに結果が変わるため、セキュリティ強度は高いですが、異なるクエリ間での JOIN はできません。ポリシータグでは使用できず、列に直接付与するデータポリシーで使用できます STRING, BYTES カスタムマスキングルーチン 定義済みのマスキングルールの他に、ユーザー定義関数を使用して、独自のマスキングロジックを作成することも可能です。例えば、「電話番号の下4桁だけを表示する」「特定の辞書に基づいて置換する」といった高度な要件に対応できます。 ただし、 STRUCT 型には対応していません( STRUCT の中の各フィールドに対しては適用可能です)。 ルールの優先順位 1つのポリシータグに対して、複数のデータポリシーを設定することが可能です。ユーザーが複数のグループに所属している場合など、複数のルールが同時に適用されるユースケースでは、以下の優先順位に従って、最も具体的で有用性の高いルールが優先されます。 カスタムマスキングルーチン ランダムハッシュ ハッシュ(SHA-256) メールマスク 末尾 4 文字 先頭 4 文字 年月日マスク デフォルトのマスキング値 NULL 化 例えば、あるユーザーに対して「ハッシュ」の権限と「NULL 化」の権限の両方が与えられている場合、優先度の高い「ハッシュ」が適用されます。 参考 : Introduction to data masking - Data masking rule hierarchy 設定手順 参考 : Mask column data 分類とポリシータグの作成 Google Cloud コンソールの BigQuery > ポリシータグ を選択します。 分類(Taxonomy)とポリシータグを作成します。 データポリシーの作成 作成したポリシータグを選択し、データポリシーを管理を選択します。 「マスキングルール」と「対象のプリンシパル(ユーザーやグループ)」を指定します。 指定されたプリンシパルに roles/bigquerydatapolicy.maskedReader ロールが付与されます。 テーブル列へのタグ付け BigQuery のテーブルスキーマ編集画面 > Add policy tag を選択して、対象の列にポリシータグを付与します。 データポリシーの列への直接付与 別の設定手順として、ポリシータグを作成せずに、 データポリシーをテーブルの列に直接紐付ける ことができます。 ただし2026年2月現在、この設定方法は Preview です。また2026年2月現在、コンソール画面からの設定操作はできず、SQL を実行するか、REST API へのリクエストによって設定します。 この設定方法を使う場合は、いくつかの制約事項がありますので、使用の際は必ず公式ドキュメントを確認してください。 参考 : Mask column data - Mask data by applying data policies to a column 以下に、SQL を使った設定操作を紹介します。  CREATE TABLE または ALTER TABLE ステートメントを使用し、 OPTIONS 句でデータポリシーを指定します。 データポリシーの作成 -- 例: データポリシー「ハッシュ(SHA-256)」のマスキングを東京リージョンに作成 CREATE DATA_POLICY `your-project-id.region-asia-northeast1.test_direct_masking_policy` OPTIONS( data_policy_type= " DATA_MASKING_POLICY " , masking_expression= " SHA256 " ); テーブル列へのポリシー適用 -- 例: 既存の列にデータポリシーを適用する ALTER TABLE `your-project-id.your-dataset.your- table ` ALTER COLUMN email SET OPTIONS ( data_policies=[ " {'name':'your-project-id.region-asia-northeast1.test_direct_masking_policy'} " ]); 制約と注意点 互換性のない機能 レガシー SQL サポートされていません。GoogleSQL を使用する必要があります。 ワイルドカードテーブル ワイルドカードを使用したクエリでは、参照されるすべてのテーブルのすべての列に対して、生データの閲覧権限「きめ細かい読み取り」が必要です。 パーティション/クラスタ化列 パーティションまたはクラスタ化キーとして設定されている列に対してデータマスキングを適用した場合、その列を含むクエリはサポートされません。 テーブルのコピー テーブルコピーを行うには、ソーステーブルの全列に対する生データの閲覧権限が必要です。 SQL で利用する際の注意点 マスクされた列を SQL の WHERE 句などで使用する場合、挙動に注意が必要です。 SHA-256 ハッシュなどの決定的なマスキング(同じ入力に対して常に同じ結果が返るもの)では、等価比較( = )や GROUP BY による集計は機能しますが、大小比較( > や < )や LIKE 検索は元の値に基づいた結果にならないため、意味をなしません。 コストへの影響 オンデマンドでの BigQuery の料金はスキャンしたデータ量に基づきます。データマスキングで「NULL 化」や「デフォルトのマスキング値」が適用される場合、その列のデータはスキャンされず、課金対象のバイト数が削減される場合があります。 一方、ハッシュ化などの計算を伴うマスキングの場合、通常通りのスキャン料金が発生します。 セキュリティの考慮事項 SHA-256 ハッシュは決定論的であるため、ブルートフォース攻撃に対して脆弱になる可能性があります。攻撃者が元の値のリストを持っている場合、それらをハッシュ化して比較することで、元の値を推測できる可能性があります。 より高いセキュリティが必要な場合は、NULL 化やデフォルトマスキングルール、あるいは非決定論的なハッシュ化を行うランダムハッシュなど別のマスキング方法を検討してください。ただし、前述のとおり、ランダムハッシュは列に直接データポリシーを付与する場合にのみ使用できます(2026年2月現在、Preview)。 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー(猫)」。
G-gen の助田です。当記事では、 Network Connectivity Center を使い、異なるプロジェクトの VPC ネットワーク同士を接続する手順を解説します。 はじめに Network Connectivity Center とは 検証シナリオ ハイブリッドスポーク使用時の注意点 設定手順 事前準備 プロジェクト A: NCC ハブの作成とスポークの接続 プロジェクト B: スポークの作成と接続リクエストの送信 プロジェクト A: 接続リクエストの承認 疎通確認 ルートテーブルの確認 PING による疎通テスト はじめに Network Connectivity Center とは Network Connectivity Center (以下、NCC)は、Google Cloud 上の VPC ネットワークやオンプレミスネットワーク等を、ハブアンドスポークモデルで一元管理するためのネットワーク接続管理サービスです。複数の VPC ネットワークを統合管理し、推移的ルーティングや拠点間接続を実現できます。 NCC の基本的な仕様や詳細な説明については、以下の記事をご参照ください。 blog.g-gen.co.jp 検証シナリオ 当記事では、ハブを管理するプロジェクト A と、そこへ接続するスポークを持つプロジェクト B の構成を検証します。 具体的には、プロジェクト A に作成する NCC ハブ( ncc-hub-central )に対して、自プロジェクトの VPC ネットワーク( vpc-a )と、別プロジェクトであるプロジェクト B の VPC ネットワーク( vpc-b )を、それぞれスポークとして接続します。これにより、異なるプロジェクトに存在する VPC ネットワーク間で経路情報を交換し、 相互通信が可能な状態 を実現します。 構成図は、以下の通りです。 構成図 リソース定義は以下の通りです。 項目 プロジェクト A(ハブ管理) プロジェクト B(スポーク接続) プロジェクト ID project-a-hub project-b-spoke VPC ネットワーク名 vpc-a vpc-b サブネット subnet-a( 10.0.0.0/24 ) subnet-b( 172.16.0.0/24 ) リージョン asia-northeast1 asia-northeast1 NCC ハブ名 ncc-hub-central - スポーク名 spoke-a spoke-b ハイブリッドスポーク使用時の注意点 当記事ではプロジェクトを跨いだ VPC スポーク の接続手順を紹介しますが、プロジェクト間接続において、ハイブリッドスポーク(Cloud VPN、Cloud Interconnect、ルーター アプライアンス)は、 ハブと同じプロジェクト内に存在する必要 があります。 例えば、外部ネットワーク(オンプレミスや他クラウド等)との接続用リソースをスポーク側のプロジェクト(今回の例ではプロジェクト B)に配置し、プロジェクト A のハブへ接続することはできません。ハイブリッド接続を行う場合は、 ハブ側のプロジェクトへリソースを集約しなければならない という設計上の制約に留意が必要です。 参考 : ハイブリッドスポーク 設定手順 事前準備 プロジェクトを跨いだネットワーク構成とする場合、各プロジェクトでの作業内容に応じて適切な IAM 権限の付与が必要です。今回は以下の作業を実施するため、それぞれのプロジェクトで権限を設定します。 当記事の作業では、プロジェクト A において、ハブの作成や別プロジェクトからの接続承認、および自プロジェクトの VPC ネットワークのスポーク化を行います。この作業のためにハブの作成者が必要な権限は以下のとおりです。 リソース ロール プロジェクト A ・ハブ アンド スポーク管理者( roles/networkconnectivity.hubAdmin ) ・スポーク管理者( roles/networkconnectivity.spokeAdmin ) ・Compute ネットワーク管理者( roles/compute.networkAdmin ) 一方のプロジェクト B では、スポークを作成し、プロジェクト A のハブに対して接続リクエストを送信します。この作業のためにスポークの作成者が必要な権限は以下のとおりです。 リソース ロール プロジェクト A ・グループ ユーザー( roles/networkconnectivity.groupUser ) プロジェクト B ・スポーク管理者( roles/networkconnectivity.spokeAdmin ) ・Compute ネットワーク管理者( roles/compute.networkAdmin ) 上記では、プロジェクト A と B にそれぞれ別の管理者がいる前提で必要な権限を分けて記載しましたが、両方のプロジェクトに対して同じ管理者が操作をしても構いません。 参考 : ハブとスポークを操作する 参考 : 別のプロジェクトでスポークを提案する プロジェクト A: NCC ハブの作成とスポークの接続 まずはネットワークの中心となるハブを作成し、プロジェクト A 自身の VPC ネットワークを接続します。 NCC ハブのトポロジを選択します。今回は相互通信を行うため、 メッシュ トポロジ を選択します。 ハブ -トポロジ選択- ハブ名を入力し、作成ボタンを押下します。(スポークの追加は後ほど行います) ハブ -構成- 続いて、スポークを作成します。先ほど作成したハブに、 vpc-a をスポーク spoke-a として接続します。 スポークA -接続先のハブ設定- スポークA -編集- 同一プロジェクト内のスポーク接続では特別な承認ステップは発生せず、作成直後にスポークのステータスが Active となります。 スポークA -作成完了後- プロジェクト B: スポークの作成と接続リクエストの送信 次に、プロジェクト B でスポークを作成し、別プロジェクトにある NCC ハブへ接続します。 接続するハブのロケーションを指定します。別のプロジェクトにあるハブへ接続するため、 「別のプロジェクト内」 を選択し、ハブが存在する プロジェクト ID と ハブ名 を指定して、次のステップを押下します。 スポークB -接続先のハブ設定- vpc-b をスポーク spoke-b として作成します。 スポークB -編集- 作成完了後、スポークのステータスが 「確認待ち(Pending)」 となることを確認します。 スポークB -承認待ち- この時点では経路情報の交換は行われておらず、VPC ネットワーク間での通信はできません。 プロジェクト A: 接続リクエストの承認 プロジェクト間のスポーク接続においては、ハブ管理者が リクエストを承認する ことでハブへの接続が有効化されます。 プロジェクト A のハブ詳細画面から、ステータスが [確認待ち] のスポークを選択します。 リクエスト内容を確認後、 [スポークを承認] を押下し、接続を承認します。 スポークB -承認実行- 承認後、ステータスが Active となります。 スポークB -承認済- 疎通確認 ルートテーブルの確認 接続完了後、NCC ハブおよび各 VPC ネットワークのルートテーブルを参照し、以下の通りルートが追加されていることを確認します。 NCC ハブのルートテーブル スポーク A( 10.0.0.0/24 )およびスポーク B( 172.16.0.0/24 )のサブネットルートが学習されていることを確認します。 NCC ハブのルートテーブル VPC ネットワーク A のルートテーブル ネクストホップを NCC ハブとする 172.16.0.0/24 へのルートが自動追加されていることを確認します。 VPC-A ルートテーブル VPC ネットワーク B のルートテーブル 同様に 10.0.0.0/24 へのルートが追加されていることを確認します。 VPC-B ルートテーブル PING による疎通テスト 検証用に作成した各 VPC ネットワーク内の VM 間で、プライベート IP アドレスによる疎通を確認しました。 # VPC ネットワーク B の VM から、VPC ネットワーク A のVM(10.0.0.2)へ ping 実行 ping 10 . 0 . 0 . 2 -c 4 PING 10 . 0 . 0 . 2 ( 10 . 0 . 0 . 2 ) 56 ( 84 ) bytes of data. 64 bytes from 10 . 0 . 0 .2: icmp_seq = 1 ttl = 64 time = 1 . 23 ms 64 bytes from 10 . 0 . 0 .2: icmp_seq = 2 ttl = 64 time = 0 . 456 ms 64 bytes from 10 . 0 . 0 .2: icmp_seq = 3 ttl = 64 time = 0 . 421 ms 64 bytes from 10 . 0 . 0 .2: icmp_seq = 4 ttl = 64 time = 0 . 443 ms --- 10 . 0 . 0 . 2 ping statistics --- 4 packets transmitted, 4 received, 0 % packet loss, time 3004ms rtt min/avg/max/mdev = 0 . 421 / 0 . 637 / 1 . 230 / 0 . 342 ms NCC ハブを介して、プロジェクトを跨いだ通信が正常に行われていることが確認できました。 助田 真輝 (記事一覧) クラウドソリューション部所属。2024年11月、G-genにジョイン。クラウドインフラ設計、特にネットワークとセキュリティ分野に強い関心を持ち、関連技術の探求に日々取り組む。