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

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

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

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

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

G-gen の堂原です。当記事では、Google Workspace の 共有ドライブ において、ファイルやフォルダが 組織外へ共有されてしまうことを防ぐ 方法を紹介します。「アクセスレベルによる制限」、「共有ドライブレベルでの制限」そして「管理コンソールを用いた組織部門レベルでの制限」の3手法を解説します。 はじめに アクセスレベルによる制限 共有ドライブレベルでの制限 組織部門レベルでの制限 はじめに 共有ドライブ は Google ドライブの機能であり、チームでファイルを保存、検索、アクセスすることができます。ファイルごと、またはフォルダごとん、組織内部のメンバーはもちろん、組織外部のメンバーに対してもアクセス権限を付与することができます。 参考 : 共有ドライブとは 共有ドライブのファイルやフォルダは、簡単な手順で他人に共有することができます。それゆえに、意図しない情報漏洩を防ぐためには、外部のメンバーに対する共有設定を適切にコントロールする必要があります。 参考 : Googleドライブの「やってはいけない」。ファイルをインターネット公開しない設定 - G-gen Tech Blog 当記事では、共有ドライブの外部共有を制限する以下の3つの方法を紹介します。 アクセスレベルによる制限 共有ドライブレベルでの制限 管理コンソールを用いた組織部門レベルでの制限 これらの手法のうち、1つ目が最も手軽に設定でき、3つ目が最も詳細に設定できます。 アクセスレベルによる制限 共有ドライブ内のファイルやフォルダをユーザーやグループに共有するためには、操作を行うユーザーが、対象となるファイルやフォルダに対して適切な アクセスレベル （アクセス権限）を持っている必要があります。必要最低限のアクセスレベルを付与することで、不用意な外部共有を防ぐことができます。 ファイルとフォルダで、共有操作に必要なアクセスレベルは異なります。 ファイルを共有する場合 : 「管理者」、「コンテンツ管理者」、「投稿者」のいずれかが必要 フォルダを共有する場合 : 「管理者」、「コンテンツ管理者」のいずれかが必要 さらに、フォルダの共有に関しては、共有ドライブの設定で、コンテンツ管理者による共有操作を禁止することができます。 共有ドライブの画面において、ページ上部の共有ドライブ名をクリック ドロップダウンメニューが表示されるので、「共有ドライブの設定」をクリック 3.「コンテンツ管理者にフォルダの共有を許可する」のチェックを外す なお、上記の状態でコンテンツ管理者が共有操作をしようとすると、管理者に対して以下のようなリクエストメールが送信されます。 参考 : 共有ドライブのファイルへのアクセスの仕組み - Google Workspace ラーニング センター 共有ドライブレベルでの制限 共有ドライブの設定を変更することで、その共有ドライブにおける外部共有を一律で制御できます。 共有ドライブの画面において、ページ上部の共有ドライブ名をクリック ドロップダウンメニューが表示されるので、「共有ドライブの設定」をクリック 3.「（Google Workspace アカウント名）外のユーザーにファイルへのアクセスを許可する」のチェックを外す 組織部門レベルでの制限 共有ドライブは、Google Workspace のいずれかの 組織部門 に必ず所属します。デフォルトでは最上位の組織部門に属していますが、管理コンソールから任意の組織部門に移動させることができます。 3つ目の方法として、共有ドライブが所属する組織部門レベルの設定で、外部共有を制限することができます。 管理コンソール（ https://admin.google.com/ ）にログイン 左のサイドバーの「アプリ」をクリック 「Google Workspace」をクリック 「ドライブとドキュメント」をクリック 「ドライブとドキュメントの設定」に遷移するため、設定項目にある「共有設定」をクリック 6.共有ドライブが所属する組織部門を選択 7.「共有オプション」をクリック 8.「（Google Workspace アカウント名）の外部との共有」から、設定したい項目を選択 ここで選択できるオプションは以下のとおりです。 オフ : 外部との共有を一律で制限する 許可リスト登録済みドメイン : 管理コンソールで事前に設定した、許可されたドメインのユーザーにのみ共有を許可する オン : 外部との共有を制限しない この設定には継承の概念があり、親の組織部門で設定された内容は子の組織部門にも反映されます。この設定は、子の組織部門で上書きすることも可能です。 参考 : 組織の外部共有を管理する - Google Workspace 管理者 ヘルプ 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の堂原です。当記事では、 Google カレンダー の異なる予定で、同じ Google Meet の会議 URL を使用する方法について解説します。 はじめに 手順1 : 既存の会議コードを取得 手順2 : 複製先予定にビデオ会議を追加 手順3 : 複製先のビデオ会議を既存の会議コードで上書き はじめに Google カレンダー では、予定に Google Meet のビデオ会議を紐づけることができます。 また、Google カレンダーでは予定を複製することができます。例えば、定例会議など同じメンバーでの会議が週2回で行われる場合、1つ目の予定を複製して2つ目の予定を作るなどといった使い方ができます。 しかし、既存の予定を複製して新しい予定を作成した場合、 既存の予定に紐づけられていた Google Meet ビデオ会議が引き継がれません 。「Google Meet のビデオ会議を追加」を押すと、全く新しいビデオ会議の URL が払い出させれます。 なお、これは2025年9月に行われた機能改修によるものであり、これ以前では、カレンダー予定を複製すると同じビデオ会議 URL が引き継がれていました。2026年2月現在では、セキュリテイ上の理由でこの仕様が変更され、URL が引き継がれなくなりました。 参考 : Google Workspace Updates: Enhancing meeting privacy for copied Calendar events 当記事では、既存の予定に紐づけられていた Google Meet ビデオ会議を、複製した予定にも紐づける方法を紹介します。 なお当記事では Google Workspace アカウントを利用した場合の仕様について解説しており、個人アカウントでは仕様が異なる可能性があります。 手順1 : 既存の会議コードを取得 まずは既存の予定に紐づけられているビデオ会議の会議コードを取得します。会議コードは URL の後半部分となります。例えば https://meet.google.com/abc-defg-hij であれば、会議コードは「abc-defg-hij」となります。 手順2 : 複製先予定にビデオ会議を追加 次に、複製先の予定編集画面で、いったんビデオ会議を新規に作成します。編集画面で「Google Meet のビデオ会議を追加」を押します。この時点では、複製元の予定とは異なるビデオ会議が紐づけられます。 手順3 : 複製先のビデオ会議を既存の会議コードで上書き 次に複製先の予定編集画面で、会議コードを編集します。下図を参考に「Google Meet に参加する」ブロックの右端にある下矢印をクリックし、会議の詳細を表示します。続けて「ミーティング コード」の鉛筆マークをクリックすることで、会議コードを編集することができます。 編集欄で、「手順1」で取得した会議コードを入力することで、ビデオ会議を既存の会議コードで上書きすることができます。 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

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

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

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

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

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にジョイン。クラウドインフラ設計、特にネットワークとセキュリティ分野に強い関心を持ち、関連技術の探求に日々取り組む。

G-gen の杉村です。2026年2月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud のアップデート BigQuery でパラメータ化クエリがコンソールから実行できるように Spanner で SQL からリモート関数を実行できるように（Preview） Google Cloud remote MCP Server が Resource Manager に対応（Preview） Gemini Enterprise と NotebookLM Enterprise でクエリ履歴がログ出力 Looker Studio（Pro）で複数のアップデート 複数サービスのリモート MCP サーバーが提供開始（Preview） Cloud KMS の Autokey がプロジェクトレベルで有効化可能に（Preview） BigQuery に新 AI 機能「dataset insights」が登場（Preview） Gemini Enterprise にモバイルアプリが登場（Private GA） App Engine（Standard 環境）からCloud Runへの移行コマンドが Preview Network Intelligence Center の Flow Anlyzer にレイテンシモードが登場 Looker の Conversational Analytics が iframe で埋め込み可能に（Preview） Vertex AI Search の回答用モデルで Gemini 3 Pro が Preview 公開 BigQuery で複数リージョンのデータを結合できるグローバルクエリが Preview Security Command Center の Standard tier が刷新 Gemini 3.1 Pro が登場 Gemini Enterprise でノーコードエージェントの共有が可能に BigQuery でデータセット復元のための UNDROP SCHEMA が GA Cloud Run functions（2nd gen）の Direct VPC Egress が一般公開（GA） ファイアウォールポリシーで Network contexts が使用可能に BigQuery のレガシー SQL が廃止へ（2026-06-01から） Gemini 等の呼び出しの料金体系の選択肢が追加（Preview） Google Workspace のアップデート Chromebook Plus の Chrome ブラウザに Gemini が統合（米国のみ） Google Meet の音声リアルタイム翻訳が一般公開、日本語は未対応 Gmail に校正（proofread）機能が登場 新アドオン「AI Expanded Access」が登場 Google カレンダーにおける DLP（Data Loss Prevention）が Beta 公開 Google ドキュメントで「音声概要」が使用可能になる Google Workspace 管理コンソールで Gemini の使用状況レポートが強化 Gemini アプリで30秒間の音楽を生成できるようになった Googleスプレッドシートに SHEET() 、SHEETS() 関数が登場 Google グループの「組織外のメンバーを禁止」が厳格化 Google フォームの回答結果を Gemini で定量的に分析できるように Google Vids の AI アバター＆ボイスオーバー（音声生成）が日本語に対応 Gemini アプリから Google Chat をデータソースとして参照できるように はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud のアップデート BigQuery でパラメータ化クエリがコンソールから実行できるように Run parameterized queries (2026-02-02) BigQuery でパラメータ化クエリが Google Cloud コンソールから実行できるようになった。これまでは bq コマンドやプログラムからしか実行できなかった。 パラメータ化クエリ（Parameterized queries）とは、 @変数名 や ? といったプレイスホルダを置いておき、後から値を渡せるクエリのこと。 Spanner で SQL からリモート関数を実行できるように（Preview） Spanner remote functions (2026-02-02) Spanner で SQL からリモート関数を実行できるようになった（Preview）。 Cloud Run または Cloud Run functions に関数をホストして SQL から呼び出し可能。複雑なロジックを SQL から切り離して任意の言語で記述できる。 Google Cloud remote MCP Server が Resource Manager に対応（Preview） MCP Reference: cloudresourcemanager.googleapis.com (2026-02-03) Google Cloud remote MCP Server が Resource Manager に対応（Preview）。 現在のところ使用可能な tool は search_projects のみ。会話の中でプロジェクト ID が必要になったときなど、他の MCP server 等と組み合わせて使用か。 Google Cloud remote MCP Server については、以下の記事を参照。 blog.g-gen.co.jp Gemini Enterprise と NotebookLM Enterprise でクエリ履歴がログ出力 Gemini Enterprise release notes - February 04, 2026 (2026-02-04) Gemini Enterprise と NotebookLM Enterprise でユーザザークエリとレスポンスが Cloud Logging に記録されるようになった。 REST API 経由で明示的な有効化が必要。NotebookLM Enterprise は、ドキュメント上はクエリ履歴は記録されないように見える。ノートブック作成、共有、削除、取得が記録される。 Looker Studio（Pro）で複数のアップデート Looker Studio release notes (2026-02-05) Looker Studio Pro Looker Studio Pro のサブスクリプションが Google Workspace 管理コンソールから購入できるようになった（従来は Looker Studio コンソールから購入） Conversational Analytics で、思考（reasoning）のステップが閲覧できるようになった Looker Studio チャート（図表）を PNG 画像としてエクスポートできるようになった レポート内の特定コンポーネントへのリンクを生成できるようになった 複数サービスのリモート MCP サーバーが提供開始（Preview） Supported products (2026-02-05) 複数サービスのリモート MCP サーバーが提供開始（Preview） Cloud Monitoring Cloud Logging Developer Knowledge API Vertex AI Search Google Cloud remote MCP Server については、以下の記事を参照。 blog.g-gen.co.jp Cloud KMS の Autokey がプロジェクトレベルで有効化可能に（Preview） Enable Cloud KMS Autokey (2026-02-11) Cloud KMS の Autokey がプロジェクトレベルで有効化可能になった（Preview）。 Autokey とは、Cloud KMS の暗号鍵を自動で生成、ローテなどしてくれる機能。ストレージ暗号化のために都度 KMS 鍵を手動で新規作成しなくてよい。 従来は、「フォルダレベルで有効化」する必要があった。 BigQuery に新 AI 機能「dataset insights」が登場（Preview） Generate dataset insights (2026-02-12) BigQuery に新 AI 機能「dataset insights」が登場（Preview）。 あるデータセット内のインサイト情報を生成する。以下が生成される。 データセットの説明（Description） テーブル間の関係性を可視化する「関係グラフ」 テーブル間の関係性を明らかにするための「サンプルクエリ」 ...等。 BigQuery dataset insights Gemini Enterprise にモバイルアプリが登場（Private GA） Gemini Enterprise release notes - February 12, 2026 (2026-02-12) Gemini Enterprise にモバイルアプリが登場（Private GA）。 使用には Google に申請が必要。モバイル端末から企業データを元にした AI タスクが実現可能。 App Engine（Standard 環境）からCloud Runへの移行コマンドが Preview App Engine standard environment for Java gen2 release notes - February 12, 2026 (2026-02-12) App Engine（Standard 環境）からCloud Runへの移行補助コマンドが Preview 公開。 Java、PHP、Node.js、Python、Ruby、Goの各言語に対応。 Network Intelligence Center の Flow Anlyzer にレイテンシモードが登場 Flow Analyzer overview (2026-02-13) ネットワーク管理ツール Network Intelligence Center の Flow Anlyzer に、パケットの RTT を分析可能な「レイテンシモード」が登場（GA）。 VPC Flow logsをもとにしてレイテンシ傾向を確認できる。 Looker の Conversational Analytics が iframe で埋め込み可能に（Preview） Embedding Conversational Analytics (2026-02-17) Looker の Conversational Analytics が iframe で埋め込み可能に（Preview）。 自社サイトやアプリに会話形分析を埋め込める。現在は Looker（Original）でのみ対応であり Google Cloud core では使用できない。 Vertex AI Search の回答用モデルで Gemini 3 Pro が Preview 公開 Answer generation model versions and lifecycle (2026-02-17) Vertex AI Search の回答用モデルで Gemini 3 Pro（ gemini-3-pro-preview/answer_gen/v1 ）が Preview 公開。 これまでは Gemini 2.5 Flash、Gemini 2.0 Flash のみ。なお Gemini 3 Flash はまだ使えない。 BigQuery で複数リージョンのデータを結合できるグローバルクエリが Preview Global queries (2026-02-17) BigQuery で複数のリージョンに保存されているデータセットを統合して参照できるグローバルクエリ機能が Preview 公開された。 これまでは異なるロケーションのデータ同士は結合できないため転送が必要だった。別プロジェクト同士でも実行可。 Security Command Center の Standard tier が刷新 Standard tier enhanced and automatically activated for some customers (2026-02-11) Security Command Center の Standard tier（無償）が刷新。 2026年2月11日から数カ月かけて自動的に移行される。DSPM などこれまで使えなかった機能が追加される一方で Web Security Scanner custom scans などは使えなくなる。 Gemini 3.1 Pro が登場 Gemini 3.1 Pro: A smarter model for your most complex tasks (2026-02-19) Gemini 3.1 Pro が登場。複雑なタスクやアニメーション生成などでより強化。 Vertex AI、Google AI Studio、Gemini CLI、Geminiアプリ、NotebookLMなどで提供開始。 Gemini Enterprise でノーコードエージェントの共有が可能に Share an agent (2026-02-23) Gemini Enterprise で個人が作成したノーコードエージェントを他人に共有できるようになった。 データソースへのアクセス権も共有されてしまうので注意。管理者による承認を必須にもできる。 BigQuery でデータセット復元のための UNDROP SCHEMA が GA Share an agent (2026-02-23) BigQuery で誤って削除したデータセットを復元するための UNDROP SCHEMA 構文が Preview → 一般効果（GA）された。タイムトラベル期間内のデータが復旧できる。 以下の記事も参照。 blog.g-gen.co.jp Cloud Run functions（2nd gen）の Direct VPC Egress が一般公開（GA） Configure Direct VPC egress for 2nd gen functions (2026-02-24) Cloud Run functions（2nd gen）の Direct VPC Egress が Preview → 一般公開（GA）。 関数から VPC リソースや VPN で接続されたオンプレミスリソースへ、プロキシインスタンスなしでアクセスできる。 ファイアウォールポリシーで Network contexts が使用可能に Network contexts (2026-02-25) ファイアウォールポリシーで Network contexts が使えるようになった。 IP アドレス帯で指定しなくても、コンテキストで接続元や宛先を指定できるようになりルール構成を簡素にできる。使えるコンテキストは以下のとおり。 Internet : インターネットとの送受信トラフィック Non-internet : 非インターネット。ロードバランサ、IAP、VPC など VPC networks : Non-internet のサブセットで、VPC ネットワーク間などの通信 Intra-VPC : Non-internet のサブセットで、同一の VPC 内での通信 BigQuery のレガシー SQL が廃止へ（2026-06-01から） Legacy SQL feature availability (2026-02-25) 以前から周知のとおり BigQuery のレガシー SQL は使えなくなる。免除申請も可能。 組織で 2025-11-01 から 2026-06-01 の間でレガシー SQL が使われていない場合、レガシー SQL は 2026-06-01 から使えなくなる 組織で 2025-11-01 から 2026-06-01 の間でレガシー SQL が使われた場合、既存ワークロードは稼働し続けるが、新規のものは稼働しなくなる可能性がある Gemini 等の呼び出しの料金体系の選択肢が追加（Preview） Vertex AI consumption options (2026-02-24) リリースノート未掲載（ドキュメント更新は 2026-02-24）。 Vertex AI 経由の Gemini 等の呼び出しの料金体系はこれまで Pay Go / Provisioned Throughput の2種類だったが、Pay Go が3種類（Standard / Priority / Flex) に増え、割り当てと単価が異なる。 Priority は 429 Resource exhausted 対策になる。 Standard : 従来の通常の従量課金 Priority : 単価が高い代わりにより高い割り当て Flex : 単価が安い代わりにレイテンシが大きい Google Workspace のアップデート Chromebook Plus の Chrome ブラウザに Gemini が統合（米国のみ） Gemini in Chrome is coming to Chromebook Plus devices (2026-02-03) Chromebook Plus（Chromebook のハイエンド版）の Chrome ブラウザに Gemini が統合。 ただしまずは米国内ユーザーのみ。ブラウザ上の記事の要約や開いているタブをコンテキストにしたタスク実行など。 Google Meet の音声リアルタイム翻訳が一般公開、日本語は未対応 Speech translation in Google Meet now generally available for businesses (2026-02-04) Google Meet の音声リアルタイム翻訳が一般公開（GA）された。 日本語は未対応で、英語、スペイン語、仏語、独語、ポルトガル語、イタリア語に対応。2026-01-27から順次ロールアウト。 Gmail に校正（proofread）機能が登場 Proofread your email with Gemini in Gmail (2026-02-04) Gmail に校正（proofread）機能が登場。生成 AI モデル Gemini が文章を簡潔・洗練されるよう書き換えを提案してくれる。 2026-02-04から順次展開される。ただし、日本語の対応状況はドキュメントに記載がなく不明。 新アドオン「AI Expanded Access」が登場 Get higher access to advanced AI in Google Workspace (2026-02-05) Google Workspace でより大きいAI機能の割り当て（使用回数上限）が得られる新しいアドオン「AI Expanded Access」が登場。 通常の Workspace プランより、画像や動画生成回数が多かったり、Proモデルの回数上限が大きくなる。 Google カレンダーにおける DLP（Data Loss Prevention）が Beta 公開 Data loss prevention policies for Google Calendar now available in beta (2026-02-11) Google カレンダーにおける DLP（Data Loss Prevention、データ損失防止）が Beta 公開。Enterprise Standard エディション以上が対象。 カレンダー予定への添付ファイルや、説明欄テキストに機密データが添付されることを防ぐ。試用にはフォームから申請が必要。 Google ドキュメントで「音声概要」が使用可能になる Listen to audio summaries in Google Docs (2026-02-12) Google ドキュメントで「音声概要」が使用可能になる。 Gemini が Docs を要約して音声で読み上げる。音声種別や読み上げ速度の調整も可能。 Google Workspace Business Standard 以上または Google AI Pro が必要。2026-02-12から15日間程度かけて順次展開。 Google Workspace 管理コンソールで Gemini の使用状況レポートが強化 View Gemini feature usage and threshold reports in the Admin console (2026-02-17) Google Workspace 管理コンソールで Gemini の使用状況レポートが強化された。 使用量上限（割り当て）へ達しているユーザー数なども見え、エディションのアップグレードの判断に使える。 Gemini アプリで30秒間の音楽を生成できるようになった Create custom soundtracks with Lyria 3 in the Gemini app (2026-02-18) Gemini アプリで30秒間の音楽を生成できるようになった。 Google の Lyria 3 モデルを使用。展開まで3日程度かかる場合あり。Google Workspace ユーザーや個人の Google アカウントでも利用可能。 Googleスプレッドシートに SHEET() 、SHEETS() 関数が登場 Two new functions in Google Sheets (2026-02-23) Googleスプレッドシートに以下の関数が新登場 =SHEET() =SHEETS() 引数で渡したシート名の番号を返したりファイルのシート数を返すため、ファイルの構成が変わっても数式の維持ができる。15日間かけてロールアウト。 Google グループの「組織外のメンバーを禁止」が厳格化 New internal and external membership classifications for Google Groups (2026-02-23) Googleグループの「組織外のメンバーを禁止」が厳格化。 これまで「組織外のメンバーを許可する」をオフにしても、管理者による操作やグループをネストすること等で所属できてしまったが、今後は不可能になる。2026年5月15日以降に適用。 Google フォームの回答結果を Gemini で定量的に分析できるように AI avatars and AI voiceovers in Google Vids now available in seven new languages (2026-02-24) Google フォームの回答結果を Gemini で定量的に分析できるようになる。 回答結果一覧を「テーマ別パーセンテージ」で集計して、回答の傾向をグラフで表示。Business Standard 以上に順次展開される。 Google Vids の AI アバター＆ボイスオーバー（音声生成）が日本語に対応 AI avatars and AI voiceovers in Google Vids now available in seven new languages (2026-02-24) 動画編集ツール Google Vids で、AI アバター＆ボイスオーバー（音声生成）が日本語に対応。 AI 生成の人物が入力した台本に基づいてナレーションしてくれる。これまで英語のみ対応していた。Google Workspace ユーザー向けに順次展開。 Gemini アプリから Google Chat をデータソースとして参照できるように Google Chat now available as a data source in Gemini app (2026-02-25) Gemini アプリから Google Chat をデータソースとして参照できるようになった。 従来の Google ドライブ、Gmail などに加えての追加。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の堂原です。当記事では、Google Workspace の Google Meet で、誰が会議に参加できるかを定義する 会議へのアクセス 設定について、仕様を解説します。会議へのアクセス設定は「オープン」「信頼済み」「制限付き」から選択できますが、その結果はユーザーの属性や会議にアクセスした時間によって異なります。 はじめに 会議へのアクセスの設定値 タイミングによる挙動の違い 概要 開催 15 分前～開催中 開催 16 分以上前 デフォルト設定について はじめに Google Workspace の Google Meet では、会議の主催者が「誰が会議にリクエスト無しで入室できるか」「誰が参加リクエストを送る必要があるか」等を制御するための 会議へのアクセス という設定項目が存在します。 この設定は、設定値やユーザーの属性（組織内・組織外、Google カレンダーで招待しているか）、開催中か開催前かなどで挙動が変化します。当記事ではその挙動について解説します。 なお当記事では Google Workspace アカウントを利用した場合の仕様について解説しており、個人アカウントでは仕様が異なる可能性があります。 会議へのアクセスの設定値 「会議へのアクセス」の設定値は、 オープン 、 信頼済み 、および 制限付き から選択できます。 設定名 説明 オープン 誰でもリクエスト無しで参加できます。 信頼済み 組織内のユーザーであれば誰でもリクエスト無しで参加でき、組織外のユーザーは招待されている場合はリクエスト無しで参加できます。 制限付き 招待されたユーザーのみがリクエスト無しで参加できます。 「信頼済み」と「制限付き」においては、参加リクエストを送れるように許可するか、それともリクエスト自体をできなくするかを決定するオプションが存在します。 参考 : Google Meet のビデオ会議を開始またはスケジュール設定する - パソコン - Google Meet ヘルプ タイミングによる挙動の違い 概要 Google Meet の会議に、誰がリクエスト無しで参加できるか、あるいはリクエストが必要か、またそもそも参加できないか、については、以下の要素に影響を受けます。 会議へのアクセスの設定値 ユーザーの属性 タイミング（開催の 15 分前～開催中 / 開催の 16 分以上前） 開催 15 分前～開催中 会議が進行中、または開始予定時刻の 15 分前以降の場合、会議へのアクセスの設定値とユーザーの属性によって以下のように挙動が決定します。 ユーザーの属性 オープン 信頼済み (誰でもリクエスト可にチェックあり) 信頼済み (誰でもリクエスト可にチェックなし) 制限付き (誰でもリクエスト可にチェックあり) 制限付き (誰でもリクエスト可にチェックなし) 主催者 入室可 入室可 入室可 入室可 入室可 組織内・招待済 入室可 入室可 入室可 入室可 入室可 組織外・招待済 入室可 入室可 入室可 入室可 入室可 組織内・未招待 入室可 入室可 入室可 要リクエスト 入室不可 組織外・未招待 入室可 要リクエスト 入室不可 要リクエスト 入室不可 非Googleアカウント 入室可 要リクエスト 入室不可 要リクエスト 入室不可 表の凡例 入室可 : リクエスト無しで会議に入室可能 要リクエスト : 入室にリクエストおよび主催者の承認が必要 入室不可 : 会議への入室不可（リクエストも送れない） 開催 16 分以上前 次に開始予定時刻よりも 16 分以上前に、会議に入ろうとしたときの挙動です。入室にあたっての確認がより厳しくなっていることがわかります。 ユーザーの属性 オープン 信頼済み (誰でもリクエスト可にチェックあり) 信頼済み (誰でもリクエスト可にチェックなし) 制限付き (誰でもリクエスト可にチェックあり) 制限付き (誰でもリクエスト可にチェックなし) 主催者 入室可 入室可 入室可 入室可 入室可 組織内・招待済 入室可 入室可 入室可 要リクエスト 入室不可 組織外・招待済 入室可 要リクエスト 入室不可 要リクエスト 入室不可 組織内・未招待 入室可 入室可 入室可 要リクエスト 入室不可 組織外・未招待 入室可 要リクエスト 入室不可 要リクエスト 入室不可 非Googleアカウント 入室可 要リクエスト 入室不可 要リクエスト 入室不可 デフォルト設定について デフォルトでは、「会議へのアクセス」は「信頼済み」が選択されています。 Google Workspace 管理コンソールより、組織全体、または特定の組織部門に対して、会議作成時のアクセス設定のデフォルト値を指定できます。 左のサイドバーにて、「アプリ」をクリック 「Google Workspace」をクリック 「Google Meet」をクリック 設定項目にある「Meet の安全性設定」をクリック 遷移後の画面で「アクセスタイプ」をクリック 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の堂原です。当記事では、 Agent Development Kit （ADK）を使用して開発した AI エージェントの開発者用 Web UI を、 Cloud Run へデプロイする方法を紹介します。 はじめに Agent Development Kit 当記事について ディレクトリ構成とソースコード Cloud Run へのデプロイ デプロイコマンド 実行例 留意事項 Gemini モデルとリージョン セッションの整合性 はじめに Agent Development Kit Agent Development Kit （ADK）は、Google によって開発された AI エージェント構築用のフレームワークです。ADK を使用することで、エージェントへの関数処理組み込みや外部ツールの利用、マルチエージェントの実装が行えます。 以下の記事カテゴリも参照してください。 blog.g-gen.co.jp 当記事について ADK には、開発したエージェントをブラウザ上でテストするための、 開発者用の Web UI 機能が備わっています。Web UI は、エージェントを開発しているローカル実行環境で adk web コマンドを実行することで起動できます。この Web UI は本来、開発者がローカル実行環境で使用することを想定しており、他人がアクセスすることは想定されていません。 当記事では、この Web UI をあえて Cloud Run （Cloud Run services）にデプロイして、外部からアクセス可能にします。PoC（概念実証）などの目的で複数人から AI エージェントを試用することが目的であり、 一般ユーザーによる使用を想定したものではない ことに注意して下さい。 ADK の Web UI 参考 : Build and deploy an AI agent to Cloud Run using the Agent Development Kit (ADK) 参考 : Deploy to Cloud Run - Agent Development Kit ディレクトリ構成とソースコード 当記事では、以下の記事で開発したエージェントを用います。 blog.g-gen.co.jp ディレクトリ構成は以下の通りです。 parent/ └ get_current_time/ ├ .env ├ agent.py └ __init__.py agent.py は、前掲の記事のソースコードです。 __init__.py は、以下の1行を記載します。 from . import agent .env には、エージェントが呼び出すエンドポイントの情報を記載します。 GOOGLE_GENAI_USE_VERTEXAI=TRUE とすることで Vertex AI 経由で Gemini API が呼び出されることになります（以下、Gemini API は Vertex AI 経由であることを前提とします）。 GOOGLE_GENAI_USE_VERTEXAI=TRUE GOOGLE_CLOUD_PROJECT={Gemini APIの呼び出し先のGoogle CloudプロジェクトのID} GOOGLE_CLOUD_LOCATION={Gemini APIの呼び出し先のリージョン} Cloud Run へのデプロイ デプロイコマンド ADK には、エージェントを Cloud Run へデプロイする adk deploy cloud_run コマンドが用意されています。このコマンドを使用することで、Dockerfile の作成やイメージのビルド、Cloud Run へのデプロイを一括で実行できます。 基本的な構文は以下の通りです。 adk deploy cloud_run [ OPTIONS ] AGENT AGENT には、エージェントのソースコードが格納されているフォルダへのパスを指定します。今回の場合においては、「parent」ディレクトリでコマンドを実行するのであれば get_current_time と指定します。 実行例 以下のシェルスクリプトを実行してデプロイします。環境変数には Cloud Run サービスをデプロイしたい Google Cloud プロジェクトの ID とリージョン、Cloud Run サービスに紐づけるサービスアカウントを設定してください。 export CLOUD_RUN_PROJECT = { Cloud Runサービスをデプロイする Google CloudプロジェクトのID } export CLOUD_RUN_LOCATION = { Cloud Runサービスをデプロイするリージョン } export CLOUD_RUN_SERVICE_ACCOUNT_EMAIL = { Cloud Runサービスにアタッチするサービスアカウント } adk deploy cloud_run \ --project = $CLOUD_RUN_PROJECT \ --region = $CLOUD_RUN_LOCATION \ --service_name = adk-get-current-time \ --with_ui \ get_current_time \ -- \ --service-account = $CLOUD_RUN_SERVICE_ACCOUNT_EMAIL \ --allow-unauthenticated 主要なオプションの詳細は以下の通りです。 --service_name : Cloud Runサービスのサービス名 --with_ui : Cloud Run サービス上で ADK の Web UI を起動させるために必要なフラグです -- (get_current_time の後ろ) : この記号以降には、サービスアカウントの指定や未認証アクセスの許可（ --allow-unauthenticated ）など、Cloud Run サービスに関するオプションを記載します。 gcloud run deploy コマンドにつけるオプションと同じとなります。 留意事項 Gemini モデルとリージョン .env ファイルの GOOGLE_CLOUD_LOCATION で指定したリーションにおいて、エージェントが呼び出す Gemini モデルが公開されている必要があります。 2026年2月現在、東京リージョンを例に取ると、公開されているモデルは gemini-2.5-flash や gemini-2.5-pro などです。 gemini-3-flash-preview などの最新モデルを利用したい場合は、 .env ファイルに GOOGLE_CLOUD_LOCATION=global と記述する必要があります。最新モデルは各個別リージョンではなく global ロケーションのみで公開される傾向があります。 どのロケーションでどのモデルが公開されているかについては、以下の公式ドキュメントを参照してください。最新情報を得るためには、ドキュメントを英語版に切り替えて確認してください。 参考 : Deployments and endpoints セッションの整合性 デプロイした Cloud Run サービスの Dockerfile を確認すると、Web UI の立ち上げコマンドは以下のようになっています。 CMD adk web --port = 8000 --host = 0 . 0 . 0 . 0 --session_service_uri = memory:// --artifact_service_uri = memory:// " /app/agents " 上記より、エージェントのセッション情報はコンテナのメモリ上で管理されます。そのため、以下の挙動が発生します。 複数コンテナ時の挙動 : 複数のコンテナが稼働している場合、アクセスの度に見えるセッション情報が異なる、不安定な状態になります。 リビジョンの更新 : Cloud Run のリビジョンが新しくなると、セッションはリセットされます。 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

Google Workspace において Google ドライブなどのストレージ容量上限を規定するための仕組みである、 ストレージプール の仕組みについて解説します。 概要 ストレージプールとは 対象となるデータ エディションごとの上限 ストレージ容量の管理 使用状況の確認 ストレージ制限の設定 容量が不足した場合の挙動 ストレージプールを増やす方法 ライセンスの追加購入 上位エディションへのアップグレード 追加ストレージの購入 概要 ストレージプールとは ストレージプール とは、組織内のすべてのユーザーが共有で使用できる、合算されたストレージ容量の仕組みです。Google Workspace のほとんどのエディションでは、契約しているライセンス数に応じた合計容量が組織全体の「プール」として提供され、その範囲内で全ユーザーがストレージを消費します。 例えば、Business Standard ライセンスには1ユーザーあたり 2 TiB のストレージが含まれています。50ユーザー分契約している場合、組織全体で 100 TiB（2 TiB × 50）のストレージプールが使用可能です。 参考 : 組織全体での保存容量の使用状況を確認する 対象となるデータ ストレージプールでは、以下の Google Workspace サービスのデータが合算してカウントされます。 サービス 説明 Google ドライブ マイドライブ内のファイル、共有ドライブ内のファイル、ゴミ箱内のファイル Gmail メールと添付ファイル（迷惑メールやゴミ箱内のアイテムを含む） Google フォト バックアップされた写真や動画 なお、以前は Google ドキュメント、スプレッドシート、スライドなどの Google 形式のファイルは容量を消費しませんでしたが、2022年5月2日以降に作成または編集されたファイルは、ストレージ消費の対象となります。 参考 : Google Workspace のストレージに関するよくある質問（管理者向け） エディションごとの上限 以下に、代表的なエディションの、ライセンス数あたりのストレージ上限を記載します。 エディション 上限 Business Starter 30 GiB × ユーザー数 Business Standard 2 TiB × ユーザー数 Business Plus 5 TiB × ユーザー数 Enterprise Standard 5 TiB × ユーザー数 Enterprise Plus 5 TiB × ユーザー数 参考 : 組織全体での保存容量の使用状況を確認する - ストレージ管理ツールに関するよくある質問 ストレージ容量の管理 使用状況の確認 組織全体で、上限に対してどのくらいのストレージが消費されているかを確認するには、いくつかの方法があります。 参考 : 組織全体での保存容量の使用状況を確認する 1つ目は、管理者アカウントで管理コンソール（ https://admin.google.com/ ）にアクセスし、左部メニューから「ストレージ」をクリックします。ここでは、組織全体の総容量、使用済み容量、およびストレージを多く消費しているユーザーや共有ドライブを特定できます。 管理コンソール > ストレージ 2つ目は、管理者アカウントで Google ドライブの画面にアクセスし、左下の「保存容量」をクリックすることです。この画面の上部には、各アカウントがどれくらいストレージを消費しているかが表示されます。管理権限を持つアカウントであれば、同画面の左下に、プール全体の消費状況が表示されます。 Google ドライブの「保存容量」画面 ストレージ制限の設定 特定のユーザーがプールの容量を大きく独占することを防ぐために、上限を設定することができます。上限は、ユーザーごと、グループごと、組織部門ごとなどの単位で設定できます。 例えば一般社員とデザイン部門で組織部門やグループを分け、「一般社員には 50 GiB まで」「デザイン部門には 500 GiB まで」といった制限を設定することで、ストレージプールの枯渇を防止できます。 参考 : ユーザーの保存容量の上限を設定する また、共有ドライブごとに個別の容量制限（上限）を設定することも可能です。部門ごとに共有ドライブを作成して上限を設定することで、ストレージプール消費量のバランスを取ることができます。 参考 : 共有ドライブの保存容量の上限を設定する 容量が不足した場合の挙動 組織全体でストレージプールの空き容量がなくなった場合、以下の制限が発生します。 まず、Google フォトでは直ちに、新規ファイルの追加やバックアップができなくなります。 次に、上限を超えた状態が14日間続いた時点か、保存容量超過が25%まで達した時点のどちらか早い方のタイミングで、以下の影響が生じます。 サービス 制限 Google ドライブ 新しいファイルの追加が不可 Google ドキュメント、スプレッドシート、スライド、フォームなど 新しいファイルの作成、編集、コピー、フォームの送信等が不可 Google Meet 会議の録画が不可 これらに加え、公式の FAQ には「（前略）この上限を超えた場合、Google はお客様によるドライブへのアップロードを無効にする、ご利用のドメインを停止する、ご利用のドメインとそのすべてのデータを削除する権限を有します。」と記載されています。 参考 : Google Workspace のストレージに関するよくある質問（管理者向け） ストレージプールを増やす方法 ライセンスの追加購入 ストレージプールは「1 ユーザーあたりの容量 × ライセンス数」で決まるため、ユーザーライセンスを追加で購入することで、組織全体のプール容量が増加します。 上位エディションへのアップグレード より多くのストレージが含まれるエディション（例 : Business Standard から Business Plus への移行など）にアップグレードすることで、ユーザーあたりの割り当て容量を増やすことができます。 参考 : 組織の空き容量を増やす、または保存容量を追加する 追加ストレージの購入 ライセンスを追加せずに容量だけを増やしたい場合、追加ストレージを購入できます。10 TiB 単位などのサブスクリプション形式で提供されています。 参考 : 組織用に Google Workspace の追加の保存容量を購入する G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-gen の堂原です。当記事では、 Google Workspace の Gmail で、メールの送受信を特定のメールアドレスやドメインとの間にだけ許可し、それ以外は制限する方法について解説します。 はじめに 当記事について 仕様 手順1 : アドレスリスト作成 手順1-1 : アドレスリストの管理画面への遷移 手順1-2 : アドレスリストの作成 手順2 : 「配信を制限」の設定 手順2-1 : コンプライアンス画面への遷移 手順2-2 : 「配信を制限」の設定 はじめに 当記事について E メールの利用に際して、組織内のユーザーが外部の不特定多数とメールを送受信することを防ぎたいケースがあります。例えば、学校の生徒が持つメールアドレスからは、同じ学校の教師と生徒だけと送受信できるようにするケースが考えられます。 Google Workspace の Gmail には「 配信を制限 」という機能があります。これを利用することで、管理者が許可した特定のメールアドレスやドメインとのみ送受信できるようにし、それ以外は禁止するように構成できます。当記事では、「配信を制限」機能の設定方法を紹介します。 参考 : メールの送受信を承認済みアドレスまたはドメインのみに制限する - Google Workspace 管理者 ヘルプ 仕様 「配信の制限」設定を行うと、対象の 組織部門 に所属するユーザーは、指定されたアドレスリストに含まれない送信元からのメールを受信できなくなり、またアドレスリストに含まれない宛先へメールを送信できなくなります。 制限に抵触した場合、送信元のメールアドレスには バウンスメール が返送されます。 バウンスメール例 手順1 : アドレスリスト作成 手順1-1 : アドレスリストの管理画面への遷移 まずは、送受信を許可したいドメインやメールアドレスを設定した アドレスリスト を作成するために、「アドレスリストの管理画面」へ遷移します。 管理コンソール（ https://admin.google.com/ ）にログイン 左のサイドバーの「アプリ」をクリック 「Google Workspace」をクリック 「Gmail」をクリック 「Gmail の設定」に遷移するため、設定項目にある「ルーティング」をクリック 「アドレスリストの管理」は最上位の組織部門でしか設定できないため、最上位の組織部門を選択 「アドレスリストの管理」をクリック 手順1-2 : アドレスリストの作成 「アドレスリストの管理」画面にて、アドレスリストを作成します。 「アドレスリストの管理」にて、「アドレスリストを追加」をクリックします。 「アドレス」に送受信を許可したいアドレスとドメインを入力します。注意点として、メールの送信に失敗した際に送信元に送られてくるバウンスメールを受信するためには、 mailer-daemon@googlemail.com を許可する必要があります。 手順2 : 「配信を制限」の設定 手順2-1 : コンプライアンス画面への遷移 「配信を制限」設定は「Gmail の設定」の「コンプライアンス」画面にあるため、まずはそこまで遷移します。 左のサイドバーにて、「アプリ」をクリック 「Google Workspace」をクリック 「Gmail」をクリック 設定項目にある「コンプライアンス」をクリック 手順2-2 : 「配信を制限」の設定 「配信を制限」の設定画面を開きます。 メールの送受信を制限したい組織部門を選択 「配信を制限」欄にある「設定」をクリック 以下が「配信を制限」の設定画面です。 メールの送受信を許可したいアドレスリストを 1. の箇所に追加します。 2. の箇所に入力した文言は、バウンスメール管理者からのメッセージとして記載されます。 再掲 : バウンスメール例 3. にチェックを付けた場合、同じドメインの Google Workspace アカウント（今回だと dev.g-gen.co.jp ）に対して送信するメールは、「配信を制限」設定の影響を受けなくなります。すなわち、組織のドメインをアドレスリストに追加していなくても、組織内であればメールの送受信が可能です。 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の菊池です。当記事では、Looker で BigQuery のデータを可視化するための一連のフローを、スクリーンショット付きで解説します。BigQuery との接続から、LookML の自動生成と調整、Explore での可視化などを説明します。 はじめに 当記事について Looker、ビュー、Explore、モデル 構成図 BigQuery 側の準備 デモ用データセットの作成 サンプルデータの投入 接続用サービスアカウント（SA） の作成と権限付与 Looker の接続設定 BigQuery への接続（Connection）の作成 接続テストと設定の保存 LookML プロジェクトの作成（新規モデルの作成） プロジェクトページへ移動 データベース接続を選択 テーブルを選択する 主キーの選択 作成する Explore を選択する モデル名を入力 LookML の定義と調整 自動生成されたファイルの確認 ディメンションからメジャーへの修正 日付データの修正 変更のコミットと本番反映 Explore でデータを可視化してみる Explore 画面の操作 フィルターの使い方 ディメンションからメジャーへの修正をしなかった場合 日付データの修正をしなかった場合 はじめに 当記事について 当記事では、Looker でデータを可視化する際の一連のフローである「BigQuery との接続・認証」「LookML の作成」、そしてビジュアリゼーション作成を含む「Explore での可視化」について解説します。 Looker、ビュー、Explore、モデル Looker とは、エンタープライズ向けのデータプラットフォームです。開発者向けのセマンティックレイヤーとユーザー向けの BI ツールの両方の特徴を併せ持っています。 Looker 独自のモデリング言語である LookML を使用することで、分析対象のデータの構造とビジネスルールを定義するデータモデルを作成、管理できます。 Looker は、この LookML で定義されたデータモデルから自動的に SQL を生成します。そのため、SQL を知らないユーザーでも、直感的なインターフェースからデータを探索し、分析できます。 参考 : Looker 参考 : LookMLの紹介 Looker は、データベースのテーブルと1対1で紐づく「 ビュー 」、どのビューをユーザーに見せるか定義する「 Explore 」、どのデータベースに接続するか、どの Explore をユーザーに公開するか定義する「 モデル 」の3つの構造で成り立っています。 参考 : LookMLの用語と概念 これら3つの構成要素についての詳細は、以下の記事も参照してください。 blog.g-gen.co.jp 構成図 今回構成する Looker から BigQuery のテーブルを参照する環境は以下の通りです。 構成 BigQuery 側の準備 デモ用データセットの作成 以下の名前でデモ用のデータセットを作成します。 項目 設定値 データセット名 looker_demo_source サンプルデータの投入 BigQuery では、Google Merchandise Store （Google ブランドの商品を販売するオンラインストア）の Google アナリティクス 4 のデータがサンプルデータとして使用できます。今回はそのサンプルデータから以下の SQL の結果を取得して参照用のテーブルとします。 WITH UserData AS ( SELECT event_date AS date , user_pseudo_id, ( SELECT value.int_value FROM UNNEST(event_params) WHERE key = ' ga_session_id ' ) AS session_id, geo.country AS country, event_name, ( SELECT value.string_value FROM UNNEST(event_params) WHERE key = ' session_engaged ' ) AS session_engaged_flag, ( SELECT value.int_value FROM UNNEST(event_params) WHERE key = ' engagement_time_msec ' ) AS engagement_time_msec FROM `bigquery- public -data.ga4_obfuscated_sample_ecommerce.events_*` WHERE PARSE_DATE( ' %Y%m%d ' , _TABLE_SUFFIX) BETWEEN DATE ' 2021-01-01 ' AND DATE ' 2021-01-31 ' ) SELECT date , --日付 COUNT ( DISTINCT CASE WHEN session_engaged_flag = ' 1 ' THEN user_pseudo_id WHEN event_name = ' first_visit ' THEN user_pseudo_id WHEN engagement_time_msec > 0 THEN user_pseudo_id END ) AS active_users, --アクティブユーザー数 COUNT ( DISTINCT CASE WHEN event_name = ' first_visit ' THEN user_pseudo_id END ) AS new_users, --新規ユーザー数 COUNT ( DISTINCT CONCAT (user_pseudo_id, CAST (session_id AS STRING))) AS sessions, --セッション数 country, --国 FROM UserData GROUP BY date , country ORDER BY date このテーブルには 2021 年 1 月の日付、国ごとのアクティブユーザー数、新規ユーザー数、セッション数が含まれています。 列名 説明 date 日付 active_users アクティブユーザー数 new_users 新規ユーザー数 sessions セッション数 country 国 SELECT 文のクエリ結果は、[結果の保存]をクリックし、[ローカルへのダウンロード] > [ CSV ]を選択して保存します。 クエリ結果の保存 作成していたデータセット「looker_demo_source」の右側の三点リーダーをクリックし、[テーブルを作成]を選択します。 [テーブルを作成]画面では、以下のように設定して、[テーブルを作成]をクリックします。 項目 設定値 ソース > テーブルの作成元 アップロード ソース > ファイルを選択 ダウンロードした CSV ファイル ソース > ファイル形式 CSV 送信先 > プロジェクト 自身のプロジェクト 送信先 > データセット looker_demo_source 送信先 > テーブル ga4_daily_metrics_by_country スキーマ > 自動検出 チェックを入れる 詳細オプション > ヘッダー行のスキップ 1 接続用サービスアカウント（SA） の作成と権限付与 Looker が BigQuery データベースへのアクセスに使用する認証を構成します。 サービスアカウント作成 1.Google Cloud コンソールで[ API とサービス] > [認証情報]へ移動します。 2.[認証情報を作成] を選択し、[サービス アカウント] を選択します。 3.サービス アカウントの作成画面で以下を入力して、[作成して続行] を選択します。 項目 設定値 サービスアカウント名 looker-bq-connection-sa サービスアカウントID サービスアカウント名を入力すると自動で同じ値が入力される。 サービスアカウントの説明 Looker から BigQuery へのアクセス用 サービスアカウント作成画面 4.権限の設定画面で、[ロールを選択] フィールドで以下のロールを選択します。２つ目以降も[別のロールを追加] を選択して、同じようにロールを選択します。 BigQuery > BigQuery データ編集者 BigQuery > BigQuery ジョブユーザー サービスアカウントの権限設定画面 サービスアカウントの権限設定 5.[続行] を選択して [完了] を選択します。 サービス アカウントの認証を構成 1.[認証情報] ページで、新しく作成したサービス アカウントのメールを選択します。 サービスアカウントの選択 2.サービス アカウントの詳細画面で[鍵]タブを選択し、[キーを追加] のプルダウンから [新しいキーを作成] を選択します。 サービスアカウントに新しいキーを作成 3.[キーのタイプ] で [JSON] を選択し、[作成] を選択します。 キーのタイプを選択 4.秘密鍵（JSON ファイル）がコンピュータに保存されるので、ダウンロード先をメモしてから[閉じる]をクリックします。 秘密鍵のダウンロード 鍵を再度ダウンロードすることはできないため、ここで忘れずに保存先をメモしておきます。 Looker の接続設定 BigQuery への接続（Connection）の作成 1.以下の 2 つの方法のいずれかで、[データベースを Looker に接続] ページを開きます。 [管理者] パネルの [データベース] セクションで [接続] を選択します。[接続（Connections）]ページで、[接続を追加（Add Connection）] ボタンをクリックします。 管理者パネルから接続ページへ メイン ナビゲーション パネルの [作成] ボタンをクリックし、[接続] メニュー項目を選択します。 メインパネルの作成から接続ページへ 2.全般設定の画面で以下の通りに設定し、[次へ]をクリックします。 項目 設定値 名前 conn-ga4-daily-demo SQL 言語（SQL Dialect） [Google BigQuery Standard SQL]を選択 プロジェクトの範囲 [すべてのプロジェクト]をチェック 全般設定 3.データベース設定の画面で以下の通りに設定します。 項目 設定値 課金プロジェクト ID データセットを作成したプロジェクトのID ストレージ プロジェクト ID なし プライマリ データセット looker_demo_source データベース設定 4.認証の設定で以下の通りに設定し、[次へ]をクリックします。 項目 設定値 認証方法 [サービスアカウント]を選択 サービスアカウント証明書 ダウンロードしていた秘密鍵（JSONファイル）を指定 認証の設定 5.オプションの設定で以下の通りに設定し、[次へ]をクリックします。 項目 設定値 ノードあたりの最大接続数 30 接続プールのタイムアウト 120 この接続に関する同時実行クエリの最大数 200 この接続に関するユーザーあたりの同時実行クエリの最大数 25 最大課金ギガバイト数 なし その他の JDBC パラメータ なし メンテナンス スケジュール なし コンテキストの無効化 選択 SSL 選択 テーブルと列を事前にキャッシュに保存 選択 スキーマを取得してキャッシュに保存 選択 PDT を有効にする オフ データベースのタイムゾーン Asia - Tokyo クエリのタイムゾーン Asia - Tokyo オプションの設定（1） オプションの設定（2） オプションの設定（3） 接続テストと設定の保存 6.接続の該当するフィールドをすべて入力したら、必要に応じて接続をテストを実施します。 接続テスト 7.[次へ]をクリックして、接続設定の確認をしたら、[保存]をクリックします。 接続の保存 LookML プロジェクトの作成（新規モデルの作成） プロジェクトページへ移動 1.Development Mode（開発モード）になっていることを確認し、ナビゲーション パネルの [開発] セクションから、[プロジェクト] を選択します。 開発パネルからプロジェクトページへ 2.[LookML プロジェクト] ページで、[New Model] をクリックします。 プロジェクトページ データベース接続を選択 3.[データベース接続を選択]画面で以下の通り設定して、[次へ]をクリックします。 項目 設定値 データベース接続 conn-ga4-daily-demo LookML Project Name proj_ga4_analysis データベース接続を選択 テーブルを選択する 4.[テーブルを選択する]画面で、Looker で接続するプロジェクトとデータセットを選択し、右側の[Tables]をクリックします。 項目 設定値 GCPプロジェクト データセットが存在する Google Cloud プロジェクト データセット looker_demo_source GCP プロジェクトとデータセット選択 5.選択したデータセットに存在するテーブルの一覧が表示されるので、以下のテーブルを選択します。その他のオプションはデフォルトのままで[次へ]をクリックします。 項目 設定値 テーブル ga4_daily_metrics_by_country テーブルの選択 主キーの選択 6.[主キーの選択]画面では、テーブルを適切に結合するための主キーを設定します。この手順は省略可能です。今回は主キーは不要なので何も選択せずに[次へ]をクリックします。 主キーの選択 作成する Explore を選択する 7.[作成する Explore を選択する]画面では、Explore のビューとして使用するテーブルを選択します。テーブル「ga4_daily_metrics_by_country」の横にあるチェックボックスを選択して、[次へ]をクリックします。 作成する Explore を選択 モデル名を入力 8.[モデル名を入力]画面で以下のモデル名を入力して、[完了してモデルを表示]ボタンをクリックします。 項目 設定値 モデル名 ga4_daily_demo モデル名を入力 以上の手順で、LookMLプロジェクトとモデルが作成され、Looker IDE（統合開発環境）が開かれます。 Looker IDE 参考 : モデルの生成 LookML の定義と調整 自動生成されたファイルの確認 直前の処理から遷移した Looker IDE 画面へは、メイン ナビゲーション メニューの [開発] パネルからもアクセスできます。ナビゲーション メニューで [開発] を選択して、[開発] パネルを開きます。 [開発] パネルでプロジェクトの一覧が表示されるので、アクセスするプロジェクトの名前を選択します。「プロジェクトを検索」欄にプロジェクト名の一部を入れることで、簡単に探し出すことができます。 プロジェクトへ移動 Looker IDE 画面 遷移した Looker IDE 画面の左側にある「①IDE ナビゲーション バー」から「ファイルブラウザ」を選択します。すると、②機能パネルにファイルブラウザが表示されます。 ファイルブラウザでファイルを選択すると、③IDE エディタパネルに選択したファイルの内容が表示されます。 ファイルブラウザには2種類のファイルが既に作成されています。これらは、モデルを作成する際に選択したテーブルの定義を元に作成されたファイルです。 作成されたファイル views フォルダにある「ga4_daily_metrics_by_country.view」というファイルは、Looker のビュー（View）を定義するファイルです。データベースのテーブル「ga4_daily_metrics_by_country」と1対1で対応しおり、テーブル内の各列を定義します。 ビューファイル models フォルダにある「ga4-daily-demo.model」というファイルは、Looker のモデルを定義するファイルです。 このファイルでは、 explore パラメータを使用して Explore（エクスプロア）が定義されています。ユーザーが UI 上で見る「データ探索（Explore）」画面の元となる定義です。モデルファイルは、どのデータベースに接続するか、どの Explore をユーザーに公開するかを管理します。 モデルファイル 自動で生成されたモデルファイルとビューファイルは、この状態でも BigQuery のテーブルを BI として確認できる状態です。 しかし、自動生成されたファイルをそのまま使うのではなく、いくつか修正する必要があります。なぜ修正が必要かについては、データを可視化する部分で説明します。 ディメンションからメジャーへの修正 ビューファイルはテーブル内の各列をディメンションとメジャーとして定義します。ディメンションとは、日付や顧客名、商品カテゴリといったデータの属性や切り口を表します。メジャーとは、売上合計やユーザー数、平均年齢といった集計値や計算したい値を表します。 自動生成されたビューファイルでは、数値として表示したい列がディメンションとして定義されている場合があります。そのような列はメジャーに修正する必要があります。 以下の3つの数値列をディメンションからメジャーへ修正します。 物理名 論理名 active_users アクティブユーザー数 new_users 新規ユーザー数 sessions セッション数 修正箇所 修正前 修正後 dimension measure type: number type: sum メジャー（measure）への修正 日付データの修正 以下の列は日付のデータを YYYYMMDD 形式（例：2026年1月1日の場合、20260101）の数値で格納した列です。BigQuery でテーブルを作成する際、スキーマ自動検出にしていたため、数値の列として作成されました。 物理名 論理名 date イベント日 date 列を日付型として扱うために、以下のように修正します。 修正箇所 修正前 修正後 dimension dimension_group type: number type: time なし timeframes: [date, week, month, year, raw] なし datatype: yyyymmdd 日付型の定義 変更のコミットと本番反映 ファイルに変更点がある場合、以下のようにファイル名の右側に青い丸が付き、エディタパネルの右上に「Save Changes」ボタンが表示されます。 ファイルに変更点がある場合 Save Changes ボタン 「Save Changes」ボタンをクリックすると変更が保存され、画面右上にある Git ボタンが「Validate LookML」となります。 Git ボタン（Validate LookML） 画面右上にある Git ボタンは、プロジェクトの状態に応じて、プロジェクトを環境に反映するために必要なアクションが表示されます。 アクション 表示 LookML を検証 Validate LookML commit、ブランチをリモートに push Commit Changes & Push 本番環境にデプロイ Deploy to Production ファイルに変更点がある場合、Git ボタンは「Validate LookML」となり、それをクリックすることで変更内容にエラーがないか検証されます。 エラーがない場合、Git ボタンは「Commit Changes & Push」となり、画面右側のサイドパネルには LookML の検証結果が表示されます。 LookML の検証結果 「Commit Changes & Push」となっている Git ボタンをクリックすると、Commit 画面が表示されます。変更を反映するファイルにチェックを入れ、コミットメッセージを入力して [Commit] ボタンをクリックします。 Commit 画面 Commit と Push が行われると、Git ボタンは「Deploy to Production」と表示されます。 本番環境へデプロイ 「Deploy to Production」となっている Git ボタンをクリックすることで、変更内容が本番環境にデプロイされます。本番環境にデプロイされた変更内容は、Looker インスタンスを使用するユーザー全員が確認できます。 変更内容を作業者が確認するだけならば、「Deploy to Production」をクリックする手前までで充分です。 参考 : 開発モードと本稼働モード Explore でデータを可視化してみる Explore 画面の操作 ナビゲーション メニューで [Explore] を選択して、[Explore] パネルを開きます。Explore の一覧が表示されるので、アクセスする Explore の名前を選択します。 「Explore を検索」欄に Explore 名の一部を入れると、すぐに探しだすことができます。 Explore を開く Explore 画面が表示されます。左側の[すべてのフィールド]タブに一覧で表示されているフィールドから、グラフとして表示したいフィールドを選択していきます。 Explore の初期画面 フィールドの一覧から、以下のフィールドを順に選択していきます。Date フィールドについては、[Date Date] の左側にある▼マークをクリックすることで、Date、Month、Week、Yearというフィールドが展開されます。 Date Country Sessions Active Users New Users フィールドの選択 フィールドを選択すると右側にある [データ] パネルに選択したフィールドが追加されます。右上にある [実行] ボタンをクリックします。 データパネル 選択したフィールドのデータが取得されます。「行数上限に達しました。結果の一部が表示されない可能性があります。」というメッセージが表示されることがあります。右上にある「行数上限」が 500 になっていますが、取得したデータが500行以上ある場合にこのメッセージが表示されます。 全てのデータを表示したい場合は、行数上限の値を取得データの行数より大きい値（例 : 5000）のようにして、[実行] ボタンを再度クリックします。 [ビジュアリゼーション] パネルの左側にある▼マークをクリックすると、[ビジュアリゼーション] パネルが表示されます。 ビジュアリゼーションパネルの展開 今回は、Country フィールドに国名のデータがあったため、Google マップのビジュアリゼーションが自動で選ばれました。 ここから、ビジュアリゼーションを表（テーブル）形式へ変更する場合は、ビジュアリゼーションパネルにあるテーブルのマークをクリックします。 ビジュアリゼーションの変更 テーブル形式のビジュアリゼーション テーブルの Country フィールドを見ると、数値の他にデータの値を表す水平棒グラフのビジュアリゼーションが表示されています。 セルのビジュアリゼーション このビジュアリゼーションが不要な場合は、ビジュアリゼーションタブの右側にある [編集] タブをクリックします。 表示されたパネルの [系列] タブを選択し、[カスタマイズ] で Sessions を展開し、「セルのビジュアリゼーション」をオフにします。 セルのビジュアリゼーションをオフにする セルのビジュアリゼーションなし 参考 : Explore の作成と編集 参考 : Looker での Explore の表示と操作 参考 : セルのビジュアリゼーション フィルターの使い方 フィールドの値を絞り込みたい場合は、フィルタを追加します。フィルタの追加方法は以下の2通りです。 左側のフィールド一覧で、フィールド名の右側にある [フィールドでフィルタ] を選択します。 [データ] パネルの [結果] タブで、フィールドの見出しにある歯車を選択し、[フィルタ] を選択します。 フィルタの追加方法 [フィルタ] パネルが開き、選択したフィールドのフィルタが表示されます。フィルタの値を指定するには、「任意の値」の欄をクリックします。 フィルタする値の選択箇所 値の一覧が表示されるので、フィルタに使用する値を選択します。 フィルタの値の選択 [実行] ボタンをクリックすることで、[ビジュアリゼーション] パネルの表が、フィルタで指定した値で絞り込みされます。 フィルタの結果 フィルタ方法を「次を含む」や「次で始まる」などに変更する場合は、「任意の値」欄の左側で選択します。 フィルタ方法の変更 参考 : データのフィルタリングと制限 ディメンションからメジャーへの修正をしなかった場合 LookML の定義と調整の手順で数値の列を、ディメンションからメジャーへ修正していました。 メジャーにした列は以下のような挙動になります。 Country : Albaniaでフィルタした場合の結果は、以下の通りです。 Countryでフィルタした結果 ここで、DateフィールドをMonthフィールドに変えた場合、フィルタした国の1ヶ月の数値として集計された結果になります。 月単位の集計結果 ディメンションとメジャーの挙動の違いを確認するため、active_users を dimension に変えて、反映してみます。 active_usersをディメンションにした場合 1ヶ月の集計結果は以下の図の通り、3行になってしまいます。 active_usersをディメンションにした結果 これは、active_users がディメンションであることにより、集計対象の数値ではなく、数字の1、2、3で分類する項目とみなされるようになったためです。意図した集計結果を出すためには、集計したい列をメジャーとして定義する必要があることがわかります。 日付データの修正をしなかった場合 date 列の元となった Google アナリティクス4のデータの event_date 列は日付を YYYYMMDD 形式で表示した文字列でした。 そして、その列から作成したサンプルデータの date 列は自動でスキーマを読み取った際に数字データとして取り込まれました。 そのため、生成されたままの date 列の定義では、数字のディメンションとして読み取られます。 修正する前の date 列の定義 date列の定義を修正しない場合 ここで、タイプによる挙動の違いを確認するため、date フィールドの type を string（文字列）に変えてみます。この状態では、日付データとしては認識されないことがわかります。 date 列を type:string に修正 type を string に修正した date 列 菊池 健太 (記事一覧) クラウドソリューション部データエンジニアリング課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、GCPは未経験なので現在勉強中。

G-gen の min です。Google Apps Script（以下、GAS）で開発したアドオンをユーザーが実行した際、スクリプトプロパティの読み取り時に PERMISSION_DENIED エラーが発生しました。本記事では、この事象の原因と対処法を解説します。 事象 原因 対処法 定数としてコード内に記述する ユーザーにスクリプトファイルへの閲覧権限を付与する 事象 GAS で作成した機能を Google Workspace アドオンとして配布し、利用者がそのアドオンのメニューを実行した際、以下のようなエラーログが Google Cloud の Cloud Logging に記録され、処理が失敗しました。 { " insertId ": " -w58fk8fbk0qfb ", " jsonPayload ": { " message ": " ストレージからの読み取り中にサーバーエラーが発生しました。エラーコード: PERMISSION_DENIED。 ", " serviceContext ": { " service ": " AKfycbw...（省略）... " } } , " resource ": { " type ": " app_script_function ", " labels ": { " project_id ": " 000000000000 ", " invocation_type ": " menu ", " function_name ": " callUpdateMasterData " } } , " severity ": " ERROR ", " labels ": { " script.googleapis.com/deployment_id ": " AKfycbw...（省略）... " } } メインのエラーメッセージは、以下のとおりです。 ストレージからの読み取り中にサーバーエラーが発生しました。エラーコード: PERMISSION_DENIED。 該当のスクリプトでは、 PropertiesService.getScriptProperties().getProperty('KEY_NAME') メソッドを使用し、GAS エディタ上で手動設定した スクリプトプロパティ を読み取ろうとしていました。 該当のソースコード const TARGET_URL = PropertiesService . getScriptProperties () . getProperty ( 'TARGET_URL' ) ; function callUpdateMasterData () { // ...処理... // URLにアクセスしてデータを取得する const response = UrlFetchApp . fetch ( TARGET_URL ) ; // 結果をログに出力する Logger . log ( 'Response Code: ' + response . getResponseCode ()) ; } スクリプトプロパティ 原因 このエラーは、Google Workspace Marketplace で配布されるアドオンのセキュリティ仕様と、スクリプト実行環境の関係に起因しています。 Google Workspace アドオンでは、スクリプト実行ユーザーの環境で処理が実行されます。しかし、スクリプトプロパティは「スクリプトプロジェクト（ファイル）に紐づく共有ストレージ」であり、 そのファイルにアクセス権を持つユーザー間で共有 されるものです。 Marketplace 経由で配布されたアドオンを使用する場合、実行ユーザー（アドオン利用者）はスクリプトプロジェクト自体の所有者や編集者ではありません。 ユーザーには、開発者の Google ドライブ内にある GAS プロジェクトファイル自体へのアクセス権限がないため、結果としてそのファイルに付随するプロパティストアへのアクセスも拒否されます。 PropertiesService.getScriptProperties() を用いた読み取り処理が、実行時に PERMISSION_DENIED エラーとなります。 参考 : プロパティ サービス 対処法 定数としてコード内に記述する 外部サービスの URL や固定の ID など、公開されても問題ない設定値であれば、スクリプト プロパティではなくコード内の定数（ const ）として記述することでエラーを回避できます。 // 修正前：スクリプトプロパティから読み取る（アドオン配布時にエラーになる） // const TARGET_URL = PropertiesService.getScriptProperties().getProperty('TARGET_URL'); // 修正後：コード内に定数として定義する const TARGET_URL = 'https://blog.g-gen.co.jp/' ; function callUpdateMasterData () { // ...処理... // URLにアクセスしてデータを取得する const response = UrlFetchApp . fetch ( TARGET_URL ) ; // 結果をログに出力する Logger . log ( 'Response Code: ' + response . getResponseCode ()) ; } ただし、 API キーなどの機密情報 はソースコード内に直接記述してはいけないことに十分留意してください。 ユーザーにスクリプトファイルへの閲覧権限を付与する アドオンの実行ユーザーに対して、実体となる GAS プロジェクトファイルの 閲覧者権限 を付与します。 スクリプト プロパティはファイルに紐づくメタデータであるため、ユーザーがファイル自体へのアクセス権を持っていれば、プロパティの読み取りが可能になります。 ただし、この方法は ユーザーがソースコードを閲覧可能になる というセキュリティ上の懸念があります。社内用ツールなど、ソースコードの内容が利用者に公開されても問題ない場合にのみ採用してください。 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。