G-genの min です。データポータル（英名 Data Studio、旧称 Looker Studio）には、フィルタや期間などを適用した特定の表示状態を URL として保存・共有する機能があります。本記事では、特定の表示状態を保存・共有するための「 レポートの現在のビューにリンクする 」と「 カスタム ブックマーク リンク 」という2つの機能について、設定方法から利用例まで解説します。 概要 レポートの現在のビューにリンクする（手動生成） 概要 設定方法 カスタム ブックマーク リンク（自動更新） 概要 設定方法 カスタム ブックマーク リンクの応用 URL パラメータの構文 レポート間のドリルスルー 注意事項 概要 用途に応じて以下の2種類の方法があります。 機能 URL生成方法 設定 レポートの現在のビューにリンクする 共有 メニューから都度、手動で生成 事前の設定は必要なし カスタム ブックマーク リンク URL が自動更新され、アドレスバーからコピー可能 レポート編集者が事前に有効化する必要あり 以降で、それぞれの機能について詳しく解説します。 レポートの現在のビューにリンクする（手動生成） 概要 「レポートの現在のビューにリンクする」とは、レポートの編集者や閲覧者が、 その時点での表示状態 をキャプチャし、その状態を反映した URL を手動で生成する機能です。 フィルタや期間設定はもちろん、グラフのドリルダウンやクロスフィルタリングといったインタラクティブな操作結果も URL に含められます。特定の分析結果を一時的な共有リンクとして利用するのに適しています。 この URL を受け取ったユーザーは、共有者が意図した表示状態でレポートを閲覧できます。また、閲覧者自身がこの URL をブックマークすることで、いつでも同じ表示状態でレポートにアクセスできます。 参考 : レポートへのリンクを取得する 設定方法 レポートを表示または編集モードで開きます。 共有したい表示状態になるように、フィルタや期間、グラフのドリルダウンなどを操作します。 画面右上の 共有 ボタンの横にある下矢印をクリックし、 レポートへのリンクを取得 を選択します。 ダイアログで レポートの現在のビューにリンクする のチェックボックスをオンにします。 リンクをコピー をクリックして URL を取得し、共有します。 カスタム ブックマーク リンク（自動更新） 概要 レポートの設定で カスタム ブックマーク リンク を有効にすると、レポートの閲覧者がフィルタなどを操作するたびに、その設定が URL の末尾にパラメータとして 自動的に付与されます 。 この設定を有効にすると、閲覧者がフィルタなどを操作するたびに URL が自動で更新されます。ブラウザのアドレスバーから直接 URL をコピーして共有やブックマークができます。 参考 : レポートの設定を含むカスタム ブックマーク リンクを作成する 設定方法 この設定には、レポートの編集権限が必要です。 レポートを編集モードで開きます。 メニューから ファイル > レポート設定 を選択します。 レポート設定パネルの カスタム ブックマーク リンク で、 閲覧者の設定をレポートのリンクで有効にする のチェックボックスをオンにします。 カスタム ブックマーク リンクの応用 「カスタム ブックマーク リンク」機能は、URL パラメータの仕組みを理解することで、さらに応用ができます。 URL パラメータの構文 カスタム ブックマーク リンク機能を有効にしたレポートでフィルタなどを操作すると、URL は以下のような構造になります。 https://datastudio.google.com/reporting/REPORT_ID/page/PAGE_ID?params=クエリパラメータ params= 以降の クエリパラメータ 部分に、フィルタの値などの表示状態が JSON 形式で格納されます。この JSON 部分を理解し、手動またはプログラムで生成することで、高度な利用が検討できます。 レポート間のドリルスルー 例えば、サマリーレポート（例 : エリア別売上サマリー）から、特定の項目で絞り込んだ状態を維持したまま、詳細レポート（例 : 店舗別売上）へ遷移させることができます。 これを実現するには、サマリーレポートの表に、パラメータを付与した詳細レポートへの URL をリンクとして埋め込みます。 具体的には、データポータルの計算フィールドで HYPERLINK 関数と CONCAT 関数を使い、選択したディメンション（例ではエリア名）を含むパラメータ付きの URL を動的に生成します。この URL には「エリア」での絞り込み情報を含めることができます。これにより、ユーザーはエリア名をクリックするだけで、そのエリアに絞り込まれた詳細な分析へ深掘りできます。 注意事項 表示モードでのみ有効 「カスタム ブックマーク リンク」機能は、レポートの 表示モード でのみ機能します。編集モードでは URL にパラメータは自動付与されません。 URL の文字数制限 非常に多くのフィルタ値を設定すると URL が長くなり、ブラウザの上限（通常 2,000 文字まで）を超えると、設定が正しく反映されません。レポートはデフォルト設定で表示されます。 アクセス制御には利用不可 URL パラメータは手動で編集が可能なため、特定のデータへのアクセスを制御する目的には利用できません。データアクセス制御には、データソース側での行レベルセキュリティなどの方法を利用する必要があります。以下の記事も参考にしてください。 blog.g-gen.co.jp 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の min です。データポータル（英名 Data Studio、旧称 Looker Studio）の レポートの公開設定 は、レポートに加えた変更が閲覧者に表示されるタイミングを制御する機能です。この機能を利用して、レポートのバージョンを管理する方法を解説します。 概要 使用方法 公開設定を有効にする 変更内容を公開する 下書き版と公開版を切り替えて表示する バージョンの仕組み バージョン履歴との連携 レポートコピー時の挙動 概要 レポート作成時、デフォルトの状態では、編集者がレポートに加えた変更はほぼリアルタイムで閲覧者にも表示されます。これは個人での利用には便利ですが、複数人での共同編集を行う場合、編集中途の不完全なレポートが閲覧者に表示されてしまう可能性があります。 レポートの公開設定を有効にすると、レポートが「 公開版 」と「 下書き版 」の2つのバージョンに分離されます。閲覧者には常に安定した「 公開版 」が表示され、編集者は「 下書き版 」で作業を続けることができます。そして、下書き版の編集が完了したタイミングで、内容を公開版に反映（公開）できます。 参考 : レポートの公開設定 使用方法 公開設定を有効にする レポートの公開設定を有効化する手順は以下の通りです。 1. データポータルでレポートを編集モードで開きます。 2. メニューから [ ファイル ] > [ 公開設定 ] を選択します。 3. 表示されたダイアログで [ レポートの公開 ] のトグルスイッチをオンにして、[ 保存 ] をクリックします。 この設定を有効にすると、その時点のレポートが「 公開版 」として保存され、以降の編集はすべて「 下書き版 」に対して行われます。 変更内容を公開する 下書き版で行った変更を公開版に反映させる手順は以下の通りです。 1. レポートの編集画面の右上にある [ 公開 ] ボタンをクリックします。 2. 確認ダイアログが表示されるので、再度 [ 公開 ] をクリックします。 これにより、下書き版の内容が公開版に上書きされ、閲覧者が見るレポートが更新されます。 下書き版と公開版を切り替えて表示する 編集者は、表示モードで「 下書き版 」と「 公開版 」を自由に切り替えて確認できます。閲覧者は公開版しか見ることはできません。 1. データポータルでレポートを編集モードで開きます。 2. レポート名の右横に表示される [ 下書き版 ] > [ 変更履歴を表示 ] をクリックします。 3. 表示したいバージョンを選択します。 これにより、キャンバス画面上で下書き版と公開版の表示を切り替え、公開前に変更点を確認できます。 バージョンの仕組み バージョン履歴との連携 レポートの公開設定は、データポータルの標準機能である「 バージョン履歴 」と連携して動作します。バージョン履歴からは、過去に保存された任意のバージョンを「公開」または「この版を復元」できます。この2つの操作は似ていますが、挙動が異なるため注意が必要です。 操作 影響を受けるバージョン 説明 公開 公開版 閲覧者が見る 公開版 が、指定したバージョンに置き換わります。現在の 下書き版は変更されません 。 この版を復元 下書き版 編集中の 下書き版 が、指定したバージョンで上書きされます。現在の 公開版は変更されません 。 例えば、「昨日の状態にレポートを戻したいが、現在編集中の内容は破棄したくない」という場合は「公開」を選択します。一方で、「編集していた内容を破棄して、昨日の状態からやり直したい」という場合は「この版を復元」を選択します。 参考 : 公開設定と変更履歴 レポートコピー時の挙動 公開設定がオンになっているレポートをコピーする場合、コピーするユーザーの権限によって挙動が異なります。 コピーするユーザー コピーされる内容 コピー後の公開設定 編集者 下書き版 と 公開版 の両方 オン のまま 閲覧者 公開版 のみ オフ 編集者がレポートをコピーすると、公開設定を含めたすべての状態が複製されます。閲覧者がコピーした場合は、その時点の公開版のみがコピーされ、通常の（公開設定がオフの）レポートとして扱われます。 レポートをコピーするための操作は、下記をご参照ください。 参考 : レポートをコピーする 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の佐々木です。当記事では、Google Cloud のサーバーレス コンテナサービスである Cloud Run の機能の1つ、 Cloud Run worker pools について解説します。 Cloud Run worker pools とは 概要 ユースケース Cloud Run services と共通の仕様 リビジョン単位の管理 CPU、メモリ容量の制限、GPU の使用 ボリュームマウント機能 Secret Manager へのアクセス VPC へのプライベート接続 サイドカーコンテナの使用 pull 型の実行モデル スケーリング ワーカープールのデプロイ 料金 Cloud Run worker pools とは 概要 Cloud Run worker pools とは、サーバーレスなクラウドインフラでコンテナを実行することができる Cloud Run の実行モデルのうちの一つです。 Cloud Run には他にも Cloud Run services 、 Cloud Run jobs 、 Cloud Run functions （旧称 Cloud Functions）といった実行モデルがありますが、これらはいずれも HTTP リクエストの受信や API 経由の手動実行、Cron によるスケジュール実行など、外部からの何かしらのトリガーによりコンテナ化したアプリケーションを実行するものです。 Cloud Run worker pools はこれらの実行モデルと異なり、Pub/Sub や Kafka のようなメッセージキューなどに対して、アプリケーションが能動的にメッセージやタスクの取得を行う pull 型 のワークロードを実行するモデルとなっています。 参考 : Deployment options and resource model - Cloud Run worker pools Cloud Run worker pools 後述しますが、Cloud Run worker pools は実行形態が他のモデルとは異なるものの、サービスの仕様は Cloud Run services と共通する箇所が多くなっています。Cloud Run services については以下の記事もご一読ください。 blog.g-gen.co.jp ユースケース Cloud Run worker pools では、以下のような pull 型ワークロードをサーバーレスで実現することができます。 Pub/Sub の pull サブスクリプションからメッセージを取得して処理を実行する Kafka キューからタスクを取得して処理を実行する GitHub Actions の Runner をホスティングしてワークフローを実行する このようなワークロードを Google Cloud で実現する場合、GKE や Compute Engine など、ユーザー側でインフラをある程度管理する必要があるサービスを利用する必要がありました。 Cloud Run worker pools を使用することで、インフラ管理が不要かつ、垂直・水平方向のスケーリングを容易に行えるといったサーバーレスのメリットを享受することができます。 Cloud Run services と共通の仕様 リビジョン単位の管理 新規作成や構成の変更など、Cloud Run worker pools でワーカープールをデプロイするたびに リビジョン （バージョン）が作成されます。 このリビジョンを使用することで、新しいリビジョンへの段階的な移行や、新旧リビジョンのインスタンスを一定の割合で起動するインスタンス分割、リビジョンのロールバックなどを容易に行うことができます。 新旧リビジョンで一定割合数のインスタンスを起動する（インスタンス分割） 参考 : Manage worker pool revisions CPU、メモリ容量の制限、GPU の使用 Cloud Run ではコンテナインスタンスに割り当てる CPU 数、メモリ容量について、上限・下限が存在します。 以下のように、CPU の数に応じて、割り当てることができるメモリ容量の幅が決まります。 CPU（個） メモリ容量 1 512 MiB ~ 4 GiB 2 512 MiB ~ 8 Gib 4 2 GiB ~ 16 GiB 6 4 GiB ~ 24 GiB 8 4 GiB ~ 32 GiB CPU、メモリの設定値は Cloud Run の利用料に直結する要素であり、ワークロードの実行に必要な量を適切に見積もる必要があります。 デフォルトでは、1 vCPU、メモリ容量512 MiB がワーカープールに設定されます。 また、worker pools でも GPU を使用することが可能です。Cloud Run における GPU の利用については以下の記事をご一読ください。 blog.g-gen.co.jp 参考 : Configure memory limits for worker pools 参考 : Configure CPU limits for worker pools 参考 : GPU support for worker pools ボリュームマウント機能 ボリュームマウント機能により、Cloud Storage バケット、NFS ボリューム、インメモリボリュームなどの外部のボリュームを、ワーカープールのコンテナインスタンスにマウントすることができます。 マウントしたボリュームは、コンテナ内のディレクトリとしてローカルファイルシステム同様にアクセスすることができます。 参考 : Configure Cloud Storage volume mounts for worker pools Cloud Run におけるボリュームマウントについては以下の記事もご一読ください。 blog.g-gen.co.jp Secret Manager へのアクセス アプリケーションが使用する API キー、パスワードのような機密情報は、Secret Manager で作成したシークレットに保存することで、Cloud Run から簡単に利用することができます。 Cloud Run が Secret Manager のシークレットにアクセスする方法として、以下の2種類があります。 シークレットの読み込み方法 特徴 Cloud Run の環境変数として読み込む プログラムから環境変数を読み取ることでシークレットの値にアクセスできる。 シークレットの値はコンテナインスタンス起動時に環境変数として読み込まれるため、 シークレットの更新は起動中のコンテナインスタンスに反映されない 点に注意が必要。 シークレットのバージョンを latest ではなく特定のバージョンで固定することで、コンテナインスタンスごとに異なる値が参照されないようにすることが推奨される。 Cloud Run のボリュームとしてマウント シークレットをコンテナインスタンスにボリュームとしてマウントし、ファイルシステム経由で値を読み込む。 シークレットの値は、起動中のインスタンスであっても常に最新のものが読み込まれる。 参考 : Configure secrets for worker pools VPC へのプライベート接続 Cloud SQL データベースへの読み書きを行う場合など、ワーカープールのコンテナインスタンスから VPC 内のリソースにアクセスする必要がある場合は、 Direct VPC Egress や サーバーレス VPC アクセス を使用することで、プライベート IP アドレスによる接続を実現することができます。 参考 : Direct VPC egress with a VPC network Cloud Run における VPC へのプライベート接続については、以下の記事をご一読ください。 blog.g-gen.co.jp サイドカーコンテナの使用 Cloud SQL Auth Proxy や AlloyDB Auth Proxy、ログやメトリクスのエージェントなど、サイドカーコンテナが必要となるユースケースでは、マルチコンテナ機能により複数のコンテナイメージをリビジョンに設定することができます。 参考 : Deploy worker pools to Cloud Run - Deploy multiple containers (sidecars) to a worker pool pull 型の実行モデル Cloud Run worker pools には実行をトリガーするためのエンドポイント、URL がありません。Pub/Sub や Kafka などのメッセージキューに対して処理を行うために、コンテナインスタンスは常に起動されています。 したがって、HTTP リクエストの受信をトリガーとする Cloud Run services と異なり、デプロイするコンテナがポートでリクエストをリッスンする必要がありません。 参考 : Deployment options and resource model - Cloud Run worker pools スケーリング 他の実行モデルとの重要な違いとして、Cloud Run worker pools には 自動スケーリング機能がありません。 基本的にコンテナインスタンスの数は手動で調整する必要があり、 インスタンス数が0のときはワーカープールが無効になります。 また、インスタンス数はリビジョン単位ではなくワーカープール単位で設定されるため、インスタンス数の変更により新たなリビジョンが作成されることはありません。 参考 : Manual scaling for worker pools ワーカープールの自動スケーリングを行いたい場合は、pull 対象（Pub/Sub や Kafka など）やワーカープールをモニタリングし、API 経由でインスタンス数を自動で変更するような仕組みが必要となります。 このような外部指標に基づいた自動スケーリングのためのツールとしては、Google Cloud 公式よりオープンソースツールである Cloud Run External Metrics Autoscaling（CREMA）が提供されています。 参考 : Autoscale worker pools with external metrics ワーカープールのデプロイ ワーカープールはコンテナレジストリにあるコンテナイメージ、もしくはソースコードからそのままデプロイすることができます。 コンテナレジストリは Google Cloud のサービスである Artifact Registory の利用が推奨されます。それ以外には Docker Hub のイメージも利用できるほか、Artifact Registry のリモートリポジトリ機能を用いることで、様々なパブリック/プライベートリポジトリを利用することができます。 参考 : Deploy worker pools to Cloud Run 参考 : Create remote repositories ソースコードからのデプロイでは、Google Cloud が提供している buildpacks を使用して、ワーカープールとしてデプロイされるコンテナイメージが自動で作成されます。 使用言語や依存関係などが自動で検出され、Google 管理の安全なベースイメージを用いてコンテナイメージのビルドが行われます。Dockerfile を使用しないため、ビルドの細かいカスタマイズはできない点に注意が必要です。 参考 : Deploy worker pools from source code 参考 : Google Cloud's buildpacks Cloud Run worker pools のデプロイ方法については、以下の記事もご一読ください。 blog.g-gen.co.jp 料金 Cloud Run worker pools では、コンテナインスタンスが使用する CPU、メモリの実行時間ぶんの料金が発生します。Cloud Run services とは異なり、コンテナインスタンスがアクティブであってもアイドル状態であっても同様の料金が発生します。 また他の実行モデルとは異なり、外部からのリクエストによる実行ではないため、リクエスト単位の料金はありません。 以下は、2025年7月現在の東京リージョン（asia-northeast1）における料金表です。 CPU メモリ 無料枠 毎月最初の 240,000 vCPU 秒 毎月最初の 450,000 GiB 秒 通常料金 $0.000011244 / vCPU 秒 $0.000001235 / GiB 秒 FlexCUD（1年） $0.00000809568 / vCPU 秒 $0.0000008892 / GiB 秒 FlexCUD（3年） $0.00000607176 / vCPU 秒 $0.0000006669 / GiB 秒 vCPU 秒 : vCPU が 1 つのインスタンスを 1 秒間 実行すること GiB 秒 : メモリ容量が 1 GiB のインスタンスを 1 秒間実行すること 例えば、通常料金で 1 vCPU、メモリ1 GiB、コンテナインスタンス1つのワーカープールを実行する場合、1ヶ月（30日=2592000秒）あたりの料金は以下のようになります。 項目 計算式 CPU 料金 $0.000011244 * (2592000秒 - 無料枠240000秒) = $26.45/月 メモリ料金 $0.000001235 * (2592000秒 - 無料枠450000秒) = $2.65/月 参考 : Cloud Run pricing なお、料金表に記載されている FlexCUD については以下のドキュメントを参照してください。 参考 : Compute flexible committed use discounts 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の min です。データポータル（英名 Data Studio、旧称 Looker Studio）から BigQuery をデータソースとして利用する際、意図しない挙動により BigQuery の利用料金が高額になるケースがあります。本記事では、特に CURRENT_DATE() のような非決定性関数を使用した場合のキャッシュの扱いや、プルダウンリストのコントロールによるクエリ発行時に注意が必要な挙動がありました。その共有と対策を解説します。 コスト増の原因になる挙動 1. CURRENT_DATE() 使用によるキャッシュ無効化 2. プルダウンリストのコントロールによるクエリ増加 具体的な対策 対策 1-1 : 非決定性関数の除外 対策 1-2 : テーブル関数の使用 対策2 : コントロール用データソースの分離とクロスフィルタリング 対策の検証 検証環境の構築 テーブル定義 サンプルデータ 分析用ビュー（問題のあるケース） 挙動確認 対策 1-1 の適用 対策 1-2 の適用 対策2 の適用 BigQuery の費用と追加のコスト最適化策 コスト増の原因になる挙動 データポータルのレポートから BigQuery テーブルをデータソースとして使用しているとき、BigQuery の利用料金が想定を超えて高くなる原因として、2つの挙動を例示します。 これらの挙動は、予期せぬスキャン量の増加やコスト発生につながることがあります。 1. CURRENT_DATE() 使用によるキャッシュ無効化 BigQuery に対して実行されるクエリで CURRENT_DATE() のような 非決定性関数 （実行されるたび出力が変わる関数）を使用していると、BigQuery のクエリキャッシュが適用されません。 参考 : クエリのキャッシュの例外 例えば、以下のケースでは、クエリが毎回再実行されます。 CURRENT_DATE() を使用して「今日から過去〇日間」のデータを取得するテーブルを作成 そのテーブルを データポータルのデータソースとして使用 こういったケースでは、レポートの再表示やフィルタ操作を行うたびにスキャンが発生し、キャッシュが利用されないため、BigQuery 利用料金の増加につながります。 2. プルダウンリストのコントロールによるクエリ増加 データポータルのレポートに配置する プルダウンリストのコントロール は、以下のタイミングで BigQuery にクエリが発行されます。 フィルタの選択肢を表示するためのデータ取得時 ユーザーがフィルタの値を変更したとき 例えば、表グラフが 1 つ、プルダウンリストのコントロールが 4 つある構成のレポートについて考えます。レポートを開いたりフィルタを操作したりするたびに、合計 5 件以上のクエリが一度に実行されます。 このケースでは、グラフやプルダウンリストのコントロールが参照しているデータリソースに対するデータスキャン量とそれに伴うコストが増加します。 具体的な対策 BigQuery のスキャン量とコストを削減するための具体的な対策を以下に説明します。 対策 1-1 : 非決定性関数の除外 最も直接的な対策は、クエリから CURRENT_DATE() のような非決定性関数を削除することです。ただし、この方法ではデータの取得期間が固定されるため、動的な期間指定には別の工夫が必要です。 対策 1-2 : テーブル関数の使用 ビューを使用する場合、BigQuery の テーブル関数 （Table Valued Function、TVF）を検討します。テーブル関数はパラメータを受け取ることができ、ビューのように振る舞います。さらに、動的な条件に基づいてデータをフィルタリングできるため、動的な期間指定が行えます。 データポータルのカスタムクエリからこのテーブル関数を呼び出し、その際に @DS_START_DATE と @DS_END_DATE といった データポータルの標準パラメータを関数に渡すことで、動的にパーティションテーブルへクエリすることで、 BigQuery のスキャン料金を削減することができます。 詳細は、後述の検証結果を参照してください。 参考 : テーブル関数 参考 : カスタムクエリでパラメータを使用する 対策2 : コントロール用データソースの分離とクロスフィルタリング プルダウンリストのコントロール専用の軽量なデータソースを作成し、データポータルの クロスフィルタリング 機能を使用します。ユーザーがプルダウンリストのコントロールで値を選択すると、クロスフィルタリング機能によって、その選択がメインのグラフに適用され、その際に必要なクエリが発行されます。 こちらの対策も、検証結果を後述します。 参考 : グラフのクロスフィルタリング 対策の検証 具体的な挙動と対策の効果を確認するため、検証環境を構築します。以降の SQL サンプルコードでは、プロジェクト ID とデータセット名を your-project.your-dataset と記述します。ご自身の環境の値に置き換えてご使用ください。 検証環境の構築 テーブル定義 まず、以下のスキーマで 3 つのテーブルを作成します。 売上ファクトテーブル ( sales_fact ) sales_date でパーティション分割します。 CREATE OR REPLACE TABLE `your-project.your-dataset.sales_fact` ( sales_date DATE , -- 売上日 store_id INT64, -- 店舗ID product_id INT64, -- 商品ID amount INT64 -- 売上金額 ) PARTITION BY sales_date; 商品マスタ ( product_master ) CREATE OR REPLACE TABLE `your-project.your-dataset.product_master` ( product_id INT64, product_name STRING, category STRING -- 商品カテゴリ ); 店舗マスタ ( store_master ) CREATE OR REPLACE TABLE `your-project.your-dataset.store_master` ( store_id INT64, store_name STRING, -- 店舗名 region STRING -- 地域 ); サンプルデータ 各マスタテーブルに 10 件程度のマスタデータを投入します。 sales_fact テーブルには、過去 3 年分、約 250 万件のトランザクションデータ（約75MB）を投入します。データ投入の具体的な SQL は長くなるため、ここでは割愛します。 分析用ビュー（問題のあるケース） 次に、 CURRENT_DATE() を使用して直近 2 年間のデータを集計するビューを作成します。これが問題を引き起こす可能性のあるビューです。 CREATE OR REPLACE VIEW `your-project.your-dataset.sales_summary_problematic` AS SELECT FORMAT_DATE( ' %Y-%m ' , f.sales_date) AS sales_month, sm.store_name, sm.region, pm.category, COUNT ( DISTINCT f.product_id) AS product_count, SUM (f.amount) AS total_sales FROM `your-project.your-dataset.sales_fact` f JOIN `your-project.your-dataset.product_master` pm ON f.product_id = pm.product_id JOIN `your-project.your-dataset.store_master` sm ON f.store_id = sm.store_id WHERE f.sales_date BETWEEN DATE_SUB( CURRENT_DATE ( ' Asia/Tokyo ' ), INTERVAL 2 YEAR) AND CURRENT_DATE ( ' Asia/Tokyo ' ) GROUP BY sales_month, sm.store_name, sm.region, pm.category; 挙動確認 上記で作成した sales_summary_problematic をデータソースとして データポータルのレポートを作成し、年月や地域を選択するプルダウンリストのコントロールを配置します。 このレポートを表示すると、1回の表示操作で、BigQuery のジョブ履歴には以下のようなクエリが4件記録されました。 このクエリのスキャン量（課金されるバイト数）は、1件ごとに、約 50 MB でした。 SELECT clmn0_ FROM ( SELECT t0.region AS clmn0_ -- region, sales_month, store_name, category に対して1件ずつ FROM ( SELECT * FROM `your-project.your-dataset.sales_summary_problematic` ) AS t0 ) GROUP BY clmn0_ ORDER BY clmn0_ DESC LIMIT 2000001 ; さらに、1回の表示操作で、BigQuery のジョブ履歴には以下のようなクエリが1件記録されました。 このクエリのスキャン量（課金されるバイト数）は、約 65 MB でした。 SELECT clmn0_, SUM (clmn4_) AS t0_qt_xxxxxxxxid, clmn1_, clmn2_, clmn3_ FROM ( SELECT t0.category AS clmn0_, t0.region AS clmn1_, t0.sales_month AS clmn2_, t0.store_name AS clmn3_, t0.total_sales AS clmn4_ FROM ( SELECT * FROM `your-project.your-dataset.sales_summary_problematic` ) AS t0 ) GROUP BY clmn0_, clmn1_, clmn2_, clmn3_ ORDER BY t0_qt_xxxxxxxxid DESC LIMIT 2000001 ; この5件のクエリは、ブラウザのリロードにより、レポートを再表示するたびに、同じスキャン量で同じ数のクエリが発行されました。 このように、ビュー内で CURRENT_DATE() を使用し、かつそのビューをプルダウンリストのコントロールで参照すると、一定期間内に同一ユーザーによる同一フィルタ条件の操作であっても、キャッシュが利用されないクエリが発行され、スキャン量が増加します。 対策 1-1 の適用 ビュー定義から CURRENT_DATE() のような非決定性関数を削除してみます。 CREATE OR REPLACE VIEW `your-project.your-dataset.sales_summary_cached` AS SELECT FORMAT_DATE( ' %Y-%m ' , f.sales_date) AS sales_month, sm.store_name, sm.region, pm.category, COUNT ( DISTINCT f.product_id) AS product_count, SUM (f.amount) AS total_sales FROM `your-project.your-dataset.sales_fact` f JOIN `your-project.your-dataset.product_master` pm ON f.product_id = pm.product_id JOIN `your-project.your-dataset.store_master` sm ON f.store_id = sm.store_id -- WHERE -- f.sales_date BETWEEN DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 2 YEAR) AND CURRENT_DATE('Asia/Tokyo') GROUP BY sales_month, sm.store_name, sm.region, pm.category; このビュー ( sales_summary_cached ) を使用すると、同じレポート表示条件（ブラウザのリロード）でのクエリ結果はキャッシュされました。 ただし、ビュー側では全期間のデータを集計しているため、データポータル側でフィルタを適用するまでのクエリは全期間のデータに対して行われ、表テーブルの初回スキャン量は約 65 MB でした。 対策 1-2 の適用 BigQuery のテーブル関数を使用してみます。 CREATE OR REPLACE TABLE FUNCTION `your-project.your-dataset.sales_summary_tf`( target_date_from DATE , target_date_to DATE ) AS ( SELECT FORMAT_DATE( ' %Y-%m ' , f.sales_date) AS sales_month, sm.store_name, sm.region, pm.category, COUNT ( DISTINCT f.product_id) AS product_count, SUM (f.amount) AS total_sales FROM `your-project.your-dataset.sales_fact` f JOIN `your-project.your-dataset.product_master` pm ON f.product_id = pm.product_id JOIN `your-project.your-dataset.store_master` sm ON f.store_id = sm.store_id WHERE -- パラメータで期間を指定することでパーティションのプルーニングが適用されます f.sales_date BETWEEN target_date_from AND target_date_to GROUP BY sales_month, sm.store_name, sm.region, pm.category ); データポータルでこのテーブル関数をデータソースとして使用するには、データソースの接続設定で「カスタムクエリ」を選択し、以下のように記述します。 SELECT * FROM `your-project.your-dataset.sales_summary_tf`(PARSE_DATE( ' %Y%m%d ' , @DS_START_DATE), PARSE_DATE( ' %Y%m%d ' , @DS_END_DATE)) データポータルの標準の期間パラメータである @DS_START_DATE と @DS_END_DATE をテーブル関数の引数として渡します。 これにより、データポータルの期間コントロールで指定された期間がテーブル関数に渡され、 sales_fact テーブルの sales_date パーティションを効果的に利用できます（パーティションのプルーニングが適用されます）。 参考 : 日付パラメータを使用して、基になるクエリに期間を渡す データポータルの「年月」のプルダウンリストのコントロールを「期間設定」のコントロールに変えます。 このレポートを表示すると、1回の表示操作で、BigQuery のジョブ履歴には以下のようなクエリが3件記録されました。（「期間設定」のコントロールに対してのクエリは発行されていませんでした。） SELECT clmn0_ FROM ( SELECT t0.region AS clmn0_ FROM ( SELECT * FROM `your-project.your-dataset.sales_summary_tf`(PARSE_DATE( ' %Y%m%d ' , @DS_START_DATE), PARSE_DATE( ' %Y%m%d ' , @DS_END_DATE)) ) AS t0 ) GROUP BY clmn0_ ORDER BY clmn0_ DESC LIMIT 2000001 ; さらに、1回の表示操作で、BigQuery のジョブ履歴には以下のようなクエリが1件記録されました。 SELECT clmn0_, SUM (clmn4_) AS t0_qt_xxxxxxxxid, clmn1_, clmn2_, clmn3_ FROM ( SELECT t0.category AS clmn0_, t0.region AS clmn1_, t0.sales_month AS clmn2_, t0.store_name AS clmn3_, t0.total_sales AS clmn4_ FROM ( SELECT * FROM `your-project.your-dataset.sales_summary_tf`(PARSE_DATE( ' %Y%m%d ' , @DS_START_DATE), PARSE_DATE( ' %Y%m%d ' , @DS_END_DATE)) ) AS t0 ) GROUP BY clmn0_, clmn1_, clmn2_, clmn3_ ORDER BY t0_qt_xxxxxxxxid DESC LIMIT 2000001 ; そしてこの4件のクエリは、対策1-1 と同じ条件（同じレポート表示条件（ブラウザのリロード）であっても、2 回目以降はスキャン量が0Bでした。 対策2 の適用 プルダウンリストのコントロール用のデータソースを作成し、データポータルのクロスフィルタリング機能を使用してみます。 プルダウンリストのコントロール用データソースの追加 「地域」「店舗名」フィルタ用データソースは your-project.your-dataset.store_master テーブルを参照します。 「商品カテゴリ」フィルタ用データソースは your-project.your-dataset.product_master テーブルを参照します。 レポート設定 データポータルのレポートで、メインの表は対策 1-2 で作成したテーブル関数 ( sales_summary_tf ) を参照するデータソースを使用します。 「地域」「店舗名」プルダウンリストのコントロールは、上記で作成した store_master を参照するデータソースを使用するように変更します。 同様に「商品カテゴリ」プルダウンリストのコントロールも product_master を参照するデータソースを使用するように変更します。 メインの表を選択し、[表のプロパティ] > 下部にある [グラフ インタラクション] セクション >「クロスフィルタリング」のトグルがオンとなっていることを確認します。 これにより、ユーザーがプルダウンリストのコントロールで値を選択すると、クロスフィルタリング機能によって、その選択がメインのグラフ（テーブル関数を参照しているデータソース）に適用され、その際に必要なクエリが発行されます。 このレポートを表示すると、1回の表示操作で、BigQuery のジョブ履歴には以下のようなクエリが1件記録されました。 このクエリのスキャン量（課金されるバイト数）は、10 MB でした。 SELECT clmn0_ FROM ( SELECT t0.category AS clmn0_ FROM `your-project.your-dataset.product_master` AS t0 ) GROUP BY clmn0_ ORDER BY clmn0_ DESC LIMIT 2000001 ; さらに、BigQuery のジョブ履歴には以下のようなクエリが2件記録されました。 このクエリのスキャン量（課金されるバイト数）は、1件ごとに、10 MB でした。 SELECT clmn0_ FROM ( SELECT t0.region AS clmn0_ --region, store_name ごとに1件ずつ FROM `your-project.your-dataset.store_master` AS t0 ) GROUP BY clmn0_ ORDER BY clmn0_ DESC LIMIT 2000001 ; BigQuery の費用と追加のコスト最適化策 BigQuery のオンデマンド料金モデルは、クエリによってスキャンされたバイト数に基づいて課金されますが、留意点があります。 BigQuery のオンデマンド料金には、 最小データ処理量 という概念があります。公式ドキュメントには、最小データ処理容量について次のように記載されています。 料金は MB 単位のデータ処理容量（端数は切り上げ）で決まります。クエリが参照するテーブルあたりのデータ最小処理容量は 10 MB、クエリあたりのデータ最小処理容量は 10 MB とします。 参考 : オンデマンド コンピューティングの料金 つまり、非常に小さなテーブルを参照するクエリや、結果データが小さいクエリであっても、最低 10 MB 分の料金が発生します。 したがって、クエリのスキャン量を減らすことと同時に、不要なクエリの発行回数を削減することがコスト最適化につながります。 INFORMATION_SCHEMA.JOBS を使用したクエリ調査方法や、その他のコスト最適化策については、以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の杉村です。2025年6月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Pub/Sub に Single Message Transforms（SMTs）機能が登場 BigQuery へのロード時に日付形式、タイムゾーンが指定可能に Google Workspace（Gmail） Googleドライブで "Catch me up" 機能が追加 Gemini アプリで GitHub リポジトリをインポート可能に Gemini 2.5 Pro の最新プレビュー版が利用可能に Oracle Database@Google Cloud が東京リージョンで利用可能に Model Armor が日本語を含む多言語対応 Google Vids における動画生成が音声付きに（Veo 3利用） Google フォームに Gemini が組み込み 新サービス Cloud Location Finder が登場 Looker で継続的インテグレーション（CI）機能がプレビュー公開 Looker（Google Cloud Core）で Code Interpreter in Conversational Analytics Cloud Run jobs で GPU が利用可能（Preview） Gemini 2.5 Flash/Pro が一般公開（GA） Google スプレッドシートの Gemini 分析が日本語に対応 Google フォームに新しいアクセス制御設定が追加 Google Meet で字幕スタイルをカスタマイズできるように BigQuery でメタデータの自動生成が可能に（Preview） 組織レベルで VPC Flow Logs が設定できるように（Preview） Cloud Armor で組織レベルのアドレスグループが作成可能に Gemini Code Assist が大幅パワーアップ Gemini CLI がリリース Artifact Registry で Generic レポジトリが GA Google スプレッドシートで AI 関数が一般公開 新しい Google Workspace アドオン「Google AI Ultra for Business」登場 Cloud Run で worker pools が利用可能に サイドパネルでの画像生成が Imagen 4 を使うように変更 Cloud Armor で階層型セキュリティポリシーが利用可能に（Preview） Security Command Center でリスクレポートを PDF ダウンロード Gemini アプリでスケジュール実行が利用可能に はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Pub/Sub に Single Message Transforms（SMTs）機能が登場 Single Message Transforms (SMTs) overview (2025-06-02) Pub/Sub に Single Message Transforms（SMTs）機能が登場。 Pub/Sub 内でメッセージに対して軽微な変換を直接実行。機密情報をマスク、タイムスタンプ形式を揃える、新しいフィールド作成など。トピックおよびサブスクリプション内のメッセージを対象にできる。 以下の記事も参照。 blog.g-gen.co.jp BigQuery へのロード時に日付形式、タイムゾーンが指定可能に BigQuery release notes - June 02, 2025 (2025-06-02) BigQuery の CREATE EXTERNAL TABLE と LOAD DATA で以下オプションが利用可能（Preview）。 time_zone date_format datetime_format time_format timestamp_format これまで DATE 型としてはロードできなかった「YYYY/mm/dd」といった日付形式をそのままロードできるようになる。従来は、自動スキーマ検知では取り入れることができたが、型を明示するとエラーになった。従来は、STRING 型でいったん取り込むなどしていた。 以下の記事も参照。 blog.g-gen.co.jp Google Workspace（Gmail） Gmail に Jira のアドオンが登場 Integrate Jira with Gmail to create, update, and track work items directly in your inbox (2025-06-02) Gmail に Jira のアドオンが登場。 Gmail から直接 Jira に issue の作成・閲覧などが可能。 Googleドライブで "Catch me up" 機能が追加 Stay up to date on the latest changes to your files in Drive using “Catch me up” (2025-06-03) Googleドライブで "Catch me up" 機能が追加。 最後に閲覧したときからのファイルの変更点を AI がまとめて表示してくれる。ただし現在のところ、アカウント設定を英語にする必要あり。順次ロールアウト。 Gemini アプリで GitHub リポジトリをインポート可能に Upload code folders or import your GitHub repositories directly into the Gemini app (2025-06-04) Google Workspace 付属の Gemini アプリで、GitHub リポジトリをインポートできるようになった。 リポジトリ内のコードを前提にして新たなコードを生成、修正したり、説明させたりできる。 Gemini 2.5 Pro の最新プレビュー版が利用可能に Vertex AI release notes - June 05, 2025 (2025-06-05) Gemini 2.5 Pro の最新プレビュー版 gemini-2.5-pro-preview-06-05 が利用可能に。 基本機能に違いはなく、精度が向上。 Oracle Database@Google Cloud が東京リージョンで利用可能に Regional availability (2025-06-05) Oracle Database@Google Cloud が東京リージョンで利用可能に。利用可能リージョンは以下のとおり。 asia-northeast1（Tokyo, Japan） us-east4（Northern Virginia） us-west3（Salt Lake City） europe-west2（London） europe-west3（Frankfurt） Model Armor が日本語を含む多言語対応 Security Command Center release notes - June 08, 2025 (2025-06-08) Model Armor が日本語を含む多言語対応。 「責任ある AI」および「プロンプトインジェクションとジェイルブレイクの検出」機能において、以下の言語が対応。 日本語 英語 スペイン語 フランス語 イタリア語 ポルトガル語 ドイツ語 中国語（北京語） 韓国語 以下の記事で検証結果を掲載。 blog.g-gen.co.jp Google Vids における動画生成が音声付きに（Veo 3利用） Generate video clips with sound using Veo 3 in Google Vids (2025-06-09) Google Workspace に付属の動画編集ツール Google Vids における動画生成が音声付きに。 新モデル Veo 3 を使って8秒間の動画クリップを生成。順次ロールアウト。なお現在のところ、動画生成はアカウントを英語設定にしないと使えない。 Google フォームに Gemini が組み込み Use Gemini in Google Forms to summarize form responses (2025-06-10) Google フォームにも Gemini が組み込まれる。 フォームへの回答をサマリ。回答者の回答だけでなくフォームのタイトル、説明、質問もコンテキストとして使われる。順次ロールアウト。 新サービス Cloud Location Finder が登場 Cloud Location Finder overview (2025-06-11) Google Cloud に新サービス Cloud Location Finder が登場。 指定の Google Cloud、AWS、Azure、OCI のリージョン・ゾーン間で、最もレイテンシや二酸化炭素排出量や小さい場所を検索できる。現在は gcloud または REST API のみ Looker で継続的インテグレーション（CI）機能がプレビュー公開 Looker Continuous Integration (2025-06-11) Looker で継続的インテグレーション（CI）機能がプレビュー公開。 プルリク時に「SQL や LookML のバリデーション」「Assert」「ダッシュボードのエラーチェック」などのバリデーションが走る。本番環境への展開前に各種チェックが可能。 Looker（Google Cloud Core）で Code Interpreter in Conversational Analytics Conversational Analytics Code Interpreter (2025-06-11) Original 版 Looker に続いて Google Cloud Core 版でも Code Interpreter in Conversational Analytics がプレビュー公開。 AI が自然言語の指示を Python に書き換えて、分析や可視化をしてくれる。デフォルトでオフだが管理ページから有効化できる。現在、以下のプラットフォームで利用可能。 Looker Studio Pro Looker（original） Looker（Google Cloud core） Cloud Run jobs で GPU が利用可能（Preview） Configure GPUs for Cloud Run jobs (2025-06-16) Cloud Run jobs で GPU が利用可能に（Preview）。 これで、Cloud Run services と jobs の両方で GPU が利用可能になった。24 GB の GPU メモリ（VRAM）を搭載した NVIDIA L4 GPU を1つ、コンテナインスタンスにアタッチ可能。 Gemini 2.5 Flash/Pro が一般公開（GA） Vertex AI release notes - June 17, 2025 (2025-06-17) Gemini 2.5 Flash/Pro が一般公開（GA）。 これまでの Preview 版は 2025-07-15 には使用不可になるので注意。同時に以下も利用可能に。 低レイテンシモデルである Gemini 2.5 Flash-Lite（Preview） 双方向の音声・動画やりとりができる Live API（申請が必要な Private GA） Gemini 2.5 Flash の価格帯は Preview 時から変更 thinking output は安価に、non-thinking output は高価に。 Google スプレッドシートの Gemini 分析が日本語に対応 Generate charts and valuable insights using Gemini in Google Sheets in additional languages (2025-06-17) Google スプレッドシートで、Gemini サイドパネルにおけるデータ分析が日本語に対応。 自然言語で指示すると裏で Python コードに変換し実行、スプシのデータから洞察や図表を生成してくれる。Business/Standard Enterprise以上のプラン等で利用可能。 Google フォームに新しいアクセス制御設定が追加 Adding new admin settings to control Google Form responses (2025-06-17) Google フォームに新しい管理者設定が追加。以下を管理画面から制御できるようになった。 組織のアカウントが組織外のフォームに回答できるかどうか 組織のアカウントが作ったフォームを組織外に共有できるかどうか Google Meet で字幕スタイルをカスタマイズできるように Google Meet now offers customizable caption styling (2025-06-17) Google Meet で字幕（caption）のスタイルをカスタマイズできるようになった。 サイズ、フォント、色を変更可能。順次ロールアウト。 BigQuery でメタデータの自動生成が可能に（Preview） Generate data insights in BigQuery (2025-06-18) BigQuery で Gemini によりテーブルと列の説明（Description）を自動生成可能に（Preview）。 Data insightでテーブルの分析情報を生成すると Description も生成。テーブル、外部テーブル、ビューで利用可。Google Cloud Next で発表されたメタデータ自動生成の実装。生成されるメタデータは、現在は英語のみ。 BigQuery のメタデータ自動生成 組織レベルで VPC Flow Logs が設定できるように（Preview） Enable VPC Flow Logs for an organization (2025-06-18) 組織レベルや VPC ネットワークレベルで VPC Flow Logs が設定できるように（Preview）。 これまではサブネットレベルや VLAN アタッチメントごとに有効化する必要があった。組織レベルで証跡管理の統制を取る際に有用。 Cloud Armor で組織レベルのアドレスグループが作成可能に Organization-scoped address groups (2025-06-24) Cloud Armor で組織レベルのアドレスグループが作成可能に（Preview）。 組織レベルで IP アドレスのグループを定義して、許可リストや拒否リストとして使い回すことができるようになった。これまではプロジェクトレベルで都度作成する必要があった。 Gemini Code Assist が大幅パワーアップ Gemini Code Assist release notes - June 25, 2025 (2025-06-25) Google のコーディング支援ツール「Gemini Code Assist」が大幅パワーアップ。 エージェントモード（複数ステップタスクの提案と実行） プロジェクト全体コンテキストへの理解 複数ファイルにまたがる編集 Google Cloud Next で発表された「Gemini Code Assist Agents」の一部が実装されたもの。 Gemini CLI がリリース Gemini CLI: your open-source AI agent (2025-06-25) Gemini CLI がリリース。Node.js ベースの CLI。 Gemini Code Assist と連携しており AI コーディングのインターフェイスとして利用可能。無料版および Gemini Code Assist Standard/Enterprise 付帯版。Google検索グラウンディングや MCP での拡張も対応。 Gemini CLI 起動直後 以下の記事も参照。 blog.g-gen.co.jp Artifact Registry で Generic レポジトリが GA Work with other artifact formats (2025-06-25) Artifact Registry で Generic レポジトリが GA。 特定フォーマットでなくバイナリや zip、YAML、PDF、テキスト、メディアファイルなど何でも格納できる。 Google スプレッドシートで AI 関数が一般公開 Generate data with Gemini in Google Sheets (2025-06-25) Google スプレッドシートで AI 関数が一般公開。テキスト生成、要約、分類などがスプシ上の関数だけで実現できる。 =AI("プロンプト") のように使う。Business/Enterprise Standard 以上などのエディションで利用可。2025-06-25から順次ロールアウトされていく。 新しい Google Workspace アドオン「Google AI Ultra for Business」登場 Introducing Google AI Ultra for Business: Providing Access to Advanced AI Features and Next-Gen tools (2025-06-26) Google Workspace に新しい AI アドオンライセンス「Google AI Ultra for Business」が登場。 Gemini アプリで動画生成の上限緩和 映像生成ツール Flow 画像生成ツール Whisk Project Mariner へのアクセス ... 等 2025-06-26 から Business/Enterprise エディションのアドオンとして購入可能。 Cloud Run で worker pools が利用可能に Deploy worker pools to Cloud Run (2025-06-26) Cloud Run で新しいデプロイモデルである worker pools が利用可能になった。 メッセージキューから Pull してタスクを処理していくための Cloud Run モデル。services と同様、リビジョンの概念あり。以下の記事も参照。 blog.g-gen.co.jp サイドパネルでの画像生成が Imagen 4 を使うように変更 Google Workspace Updates Weekly Recap - June 27, 2025 (2025-06-27) Googleドキュメント、スライド、Google Vids での画像生成が最新モデル Imagen 4 を使うようになった。 日本語にもすでに対応。従来よりプロンプト遵守の精度が上がったり、画像内のテキストの精度があがる等している。 Cloud Armor で階層型セキュリティポリシーが利用可能に（Preview） Hierarchical security policies overview (2025-06-27) Google Cloud のフルマネージド WAF である Cloud Armor で、階層型セキュリティポリシーが Preview 公開。 プロジェクト内だけでなく、組織で使い回せる。使用するには Cloud Armor Enterprise ティアの登録が必要。従来ポリシーと併用可能で先に階層型ポリシーが評価される。 Security Command Center でリスクレポートを PDF ダウンロード Hierarchical security policies overview (2025-06-27) Security Command Center（Enterprise/Premium）でリスクレポートを PDF ダウンロードできるようになった（Preview）。 ハイリスクリソースの分析 攻撃者のエントリポイント 問題ある設定の組み合わせ ... など Gemini アプリでスケジュール実行が利用可能に Gemini アプリでアクションのスケジュールを設定する (2025-06-29) Gemini アプリでスケジュール実行が利用可能になった。プロンプトでやらせたいアクションを指示すると、定期的に実行してくれる。 未読メールまとめ To Do 管理 ... など 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。Google が公開するオープンソースの AI エージェント Gemini CLI について解説します。 概要 Gemini CLI とは 料金 初期設定 インストール 認証 Cloud Shell での利用 リモートサーバー等での利用 使い方 対話型実行 非対話型実行 コンテキスト管理と拡張機能 概要 GEMINI.md（コンテキストファイル） Agent Skills Subagents Extensions IDE におけるエージェントモード プライバシーポリシーとデータ保護 Gemini モデルに関するデータ保護 Gemini CLI の統計情報 概要 Gemini CLI とは Gemini CLI とは、ターミナルから直接 Gemini の機能を利用できる、オープンソース（Apache 2.0 ライセンス）の AI エージェントです。 gemini コマンドを介して、自然言語でコーディング、デバッグ、情報検索、各種タスクの自動化などを実行できます。 主に開発者による利用が想定されている CLI ツールであるといえます。 Gemini CLI は、ローカルのファイルシステムを直接読み書きしたり、シェルコマンドを実行したり、Web 検索を行ったりできます。これにより、単なるコード生成に留まらず、プロジェクト全体にわたるリファクタリングや、定型的な開発タスクの自動化といった、より実践的なワークフローに Gemini を組み込むことが可能になります。 Gemini CLI は Google の最新モデルである Gemini 3 Pro などをモデルとして使用でき、100 万トークンという広大なコンテキストウィンドウを活用できます。 参考 : GitHub - google-gemini/gemini-cli 参考 : Gemini CLI - Gemini for Google Cloud 参考 : Gemini CLI documentation 料金 Gemini CLI は、使用方法によっては 無料 で利用できます。Gemini CLI 自体はオープンソースであるため、利用料金はかかりません。しかし、背後で動作する LLM（Gemini）の利用料金を考慮する必要があります。 個人の Google アカウントでログインすると、1分あたり 60 リクエスト、1日あたり 1,000 リクエストまで無料でモデルを呼び出すことができます。 より多くのリクエストが必要な場合、使用量ベース課金の Google AI Studio （API Key）または Google Cloud の Vertex AI、あるいは有償版の Gemini Code Assist ライセンスを利用することも可能です。 参考 : GitHub - docs/quota-and-pricing.md 参考 : Quotas and limits  |  Gemini Code Assist  |  Google for Developers Google Workspace アカウントでも Gemini CLI を利用可能です。後述する Login with Google の方法で Google Workspace アカウントを使って認証する場合、 Google Cloud プロジェクト ID の指定が必須 です。ただしこの方法を使って認証する場合、どのような利用規約が適用されるのか、また料金が発生するかどうかについて、Google は明確なドキュメントを用意していません。Google Workspace アカウントをお使いの方が業務等で Gemini CLI を利用する場合、後述の「初期設定 > 認証」の後で紹介するように、Google Cloud の Vertex AI で認証、あるいは Gemini Code Assist の有償プランを使って認証することが推奨されます。 初期設定 インストール Gemini CLI は npm パッケージとして配布されています。Node.js v18 以降がインストールされている環境で、以下のコマンドを実行してインストールします。 # npm コマンドによるインストール npm install -g @google/gemini-cli # もしくは以下のコマンド npx https://github.com/google-gemini/gemini-cli インストール後、 gemini コマンドを実行すると、Gemini CLI が起動します。 gemini Gemini CLI 起動直後 認証 初めて Gemini CLI を起動すると、文字への色付けなど見た目の設定に続いて、自動的に認証フローが開始されます。このフローによって、バックエンドで使用する Gemini API へ認証され、Gemini モデルの呼び出しが可能になります。 参考 : Gemini CLI authentication setup 参考 : GitHub - docs/get-started/authentication.mdx Gemini CLI の認証 Login with Google を選択すると、新しいブラウザウインドウがポップアップして、Google アカウントによる認証が走ります。Gemini CLI の無償版や Gemini Code Assist 有償プランと連携したいときは、この認証方法を選択します。 export GOOGLE_CLOUD_PROJECT = " my-google-cloud-project " Gemini API Key は、Google AI Studio の API キーを指定して認証するときに選択します。モデルの呼び出しが Google AI Studio 経由になります。これを選択することで、呼び出し量制限が緩和された従量課金になります。 Vertex AI を選択すると、モデルの呼び出しが Google Cloud の Vertex AI 経由になります。この方法で認証するには、事前に Vertex AI API（ aiplatform.googleapis.com ）を有効化した Google Cloud プロジェクトを用意しておく必要があります。その後、環境変数または .env ファイルで、プロジェクト ID やリージョンなどを指定します。 export コマンドで事前に以下のような環境変数を定義しておくか、 .env と名付けたファイルをコマンド実行ディレクトリに配置することで、設定が読み込まれます。 .env ファイル（環境変数）の例 GOOGLE_GENAI_USE_VERTEXAI = " true " GOOGLE_CLOUD_PROJECT = " my-google-cloud-project " GOOGLE_CLOUD_LOCATION = " global " Google Cloud をすでに利用中であれば、この認証方法を選択することで、呼び出し量制限が緩和された従量課金になります。また、入力したプロンプトや出力されたレスポンスは、Google Cloud の規約に従って保護され、再トレーニングなどには使われません。 なお Vertex AI 経由の認証の場合、事前に gcloud auth application-default login コマンドを実行して、Gemini CLI が Google Cloud へ認証できるようにする必要があります。 Cloud Shell での利用 Google Cloud ユーザーの場合、Web コンソールに付属している Cloud Shell と呼ばれる仮想 Linux ターミナル環境でも、Gemini CLI が利用できます。 Cloud Shell にはデフォルトで Gemini CLI がインストールされており、 追加のセットアップは必要ありません 。 なお認証については、Gemini CLI を Cloud Shell 環境で起動すると、 Use Cloud Shell user credentials が選択肢として表示されます。これを選択すると、Gemini CLI は自動的に Cloud Shell 環境にログインしているユーザーアカウントの認証情報を使って認証を行います。 Cloud Shell 環境では Use Cloud Shell user credentials が選択できる Cloud Shell 環境における開発に関するその他の情報については、以下の記事も参考にしてください。Google Cloud ユーザーは、ローカル PC に何もインストールしなくても、Cloud Shell だけである程度の開発タスクを進めることができます。 blog.g-gen.co.jp リモートサーバー等での利用 リモートのサーバー上で Gemini CLI を認証するときなどには、Login with Google の認証方法を選択すると、操作の途中で処理が止まってしまうことがあります。この認証方法を選択した場合、認証フローの中でブラウザウインドウがポップアップし、ログイン操作後に localhost にリダイレクトして戻って来る挙動があることに由来します。リモートサーバーは localhost とは別のプラットフォームで動作していますので、ブラウザからのリダイレクト時に Gemini CLI まで情報を戻すことができないことが原因です。 認証プロセスの途中でスタックする このような場合には、 NO_BROWSER という名前の環境変数に値を設定してから Gemini CLI を起動することで、ブラウザのポップアップとリダイレクトをしない方法で認証を行うことができます（Gemini CLI の v0.1.11 以降で利用可能）。 参考 : GitHub - google-gemini/gemini-cli - Release v0.1.11 まず、 NO_BROWSER という名前の環境変数に何らかの値をセットします。 export NO_BROWSER =true その後、Gemini CLI を起動します。以前の認証方法から変更する場合、 /auth を実行します。 環境変数 NO_BROWSER を設定後、Login with Google を選択 すると CLI の再起動を促され、CLI が終了します。再度、gemini コマンドを実行して CLI を起動します。すると、以下のように認証用 URL が発行されるため、この URL にブラウザでアクセスします。 認証用 URL が発行される ブラウザ上で Google アカウントでログインすると、認証コードの文字列が発行されます。この文字列をコピーし、ターミナル上で貼り付けて Enter を入力すると、認証が完了します。 認証コードが発行される 使い方 対話型実行 ターミナルで gemini コマンドを引数なしで実行すると、対話型モードで Gemini CLI が起動します。 gemini プロンプトが表示されたら、自然言語で指示を入力します。 引数を2つ取って、足し算をする Python ライブラリを作ってください。 テストもしたいです。 すると、Gemini は思考プロセスや作業の内容を表示します。 ローカルへのファイル作成とコマンド実行（1） ローカルへのファイル作成とコマンド実行（2） シェルコマンドの実行やファイルを作成するときなどには、ユーザーに実行の許可を求めます。 次のタスクを実行 プロンプトでテストの実行も依頼していたことから、テストコードも作成してくれました。単一タスクではなく、指示に基づいて複数ステップのタスクを行っていることがわかります。 作成されたコードの実行（1） 作成されたコードの実行（2） 最後に、テストコードの実行まで行い、タスクが完了しました。 非対話型実行 パイプや引数を使って、ワンショットでタスクを実行することもできます。これは、シェルスクリプトに処理を組み込む際に便利です。 --prompt オプションをつけると、対話型でなく、ワンショットの処理を行ってくれます。 $ cat calculator.py | gemini --prompt " このコードを説明して " このPythonコードは `add` という名前の関数を定義しています。 この関数は `a` と `b` の 2 つの引数（数値）を受け取り、それらを足し算した結果を返します。 例えば、 `add ( 2 , 3 ) ` のように呼び出すと、 ` 5 ` が返ってきます。 コンテキスト管理と拡張機能 概要 Gemini CLI では、ユーザーが直接プロンプトを入力すると、それに沿って Gemini が自律的に動作し、タスクを進めます。しかし、組織ごとや開発プロジェクトごと、チームごとなどに、開発のルールや文化、技術的な制約がある場合、そういった背景情報をプロンプトとして毎回入力するのは非効率です。また、作成したプロンプトを各個人が属人的な資産として持ってしまうと、いわゆる車輪の再開発が発生してしまいます。 Gemini CLI には、こうした状況に対応するために、各種のコンテキスト管理機能や、拡張機能が用意されています。 GEMINI.md（コンテキストファイル） Agent Skills Subagents Extensions GEMINI.md（コンテキストファイル） GEMINI.md は、Gemini CLI にシステムプロンプトを与えるための、Markdown 形式のテキストファイルです。他の CLI ツールでいうと、例として Claude Codeの CLAUDE.md に相当します。こういったファイルは、LLM にコンテキストを与えるため コンテキストファイル とも呼ばれます。 開発プロジェクト（各ワークスペース）のルートディレクトリに配置し、使用する技術スタック、コーディング規約、プロジェクトのディレクトリ構成、重要なドメイン知識などを記述しておくことで、Gemini CLI がそれに沿った動作をするようになります。 参考 : Provide context with GEMINI.md files 例えば、 GEMINI.md に以下のように記述しておくと、Gemini はこの指示を常に念頭に置いて応答するようになります。 # プロジェクト概要 このプロジェクトは Python で記述されています。 コーディング規約は PEP 8 のスタイルガイドに従います。 # ルール .... なお GEMINI.md をユーザーディレクトリの ~/.gemini ディレクトリに配置することで、すべてのプロジェクトに適用することができます。GEMINI.md は階層的に動作するので、ユーザーレベルの GEMINI.md と、プロジェクトレベルの GEMINI.md を併用することもできます。 ~/.gemini/GEMINI.md をグローバルコンテキストファイル、各ワークスペースに配置された GEMINI.md をワークスペースのコンテキストファイルとも呼びます。 GEMINI.md にコンテキストを記述することで Gemini の動作をチューニングすることができますが、情報を詰め込みすぎるとベースのコンテキストを圧迫するため、後述の機能を併用して知識を分散させることが重要です。 Agent Skills Agent Skills 、または単に Skills は、特定の問題を解決するための「手順書」や「専門ツールのセット」を Gemini CLI に持たせるための拡張機能です。特定の API のリクエスト方法や、デプロイの実行手順などをドキュメント化し、特定の状況下で AI が実行可能なスキルとして登録できます。 参考 : Agent Skills 基本的に Markdown 形式のテキストファイルとして記述する点では GEMINI.md と同様ですが、GEMINI.md と異なるのは、Agent Skills は オンデマンドに呼び出される という点です。常にコンテキストとして読み込まれる GEMINI.md とは異なり、Agent Skills は AI が自律的に必要と判断したときにのみ呼び出され、コンテキストとして使用されます。これにより無駄にコンテキストを消費したり、コンテキストが肥大化して精度が下がることを防げます。 また、Agent Skills にはスクリプトやリファレンスドキュメントを同梱できます。プログラミング言語で事前に記述されたスクリプトを Agent Skills が実行することで、再現性のある形でタスクを実行できます。 1つの Agent Skills は1つのディレクトリにまとめられ、Markdown 形式のテキストファイルである SKILL.md や、実行可能スクリプトをまとめた scripts/ 、静的なドキュメントをまとめた references/ などで構成されます。Gemini CLI の Agent Skills は、Anthropic 社が提唱する agentskills.io の Agent Skills オープンスタンダードに準拠しており、Claude Code など他の AI エージェントツールと資産を共有できます。 参考 : Agent Skills Overview Subagents Subagents は、特定のタスクに特化したサブエージェントを呼び出し、タスクを委譲する機能です。 参考 : Subagents Subagents のメリットは、 コンテキストの分離 です。例えば、複雑なソースコードファイル群を読み解いて、エラー原因を調査するようなタスクでは、大量のコマンド実行と試行錯誤のログが発生します。これをサブエージェントに任せることで、調査過程のノイズはサブエージェントの独立したコンテキスト内にとどまり、メインエージェントには最終的な調査結果の要約だけが返却されます。これにより、コンテキストが圧迫されることを防ぐことができます。 Subagents は必要なときにメインエージェントが自律的に呼び出すほか、プロンプト内で @ で指定することで、明示的に呼び出すことも可能です。 なお、Subagents から Agent Skills を呼び出せるため、プロンプトの重複管理を防ぐことができます。 Extensions Extensions （拡張機能）は、Gemini CLI 用の拡張機能をまとめたパッケージです。GEMINI.md（コンテキストファイル）、Agent Skills、Subagents のほか、MCP サーバー、カスタムスクリプトなどもまとめてパッケージできます。 参考 : Gemini CLI extensions これにより、チームで開発した Agent Skills や Subagents などをパッケージングして配布できます。つまり、Extensions は Agent Skills や Subagents などを組織内で共有することで重複開発を防ぎ、開発効率を上げることに寄与します。 また公式の Gemini CLI extension gallery には多数の Extensions が一般公開されており、Google Cloud 関係の Extensions などをダウンロードしてすぐに使用することができます。 参考 : Browse Extensions Extensions は以下のようなコマンドで Gemini CLI に簡単にインストール可能です。 gemini extensions install https://github.com/gemini-cli-extensions/workspace Agent Skills や Sub-agents、Extensions による Gemini CLI の応用については、Google Cloud Next '26 のブレイクアウトセッションでも紹介されました。以下の記事を参照してください。 blog.g-gen.co.jp IDE におけるエージェントモード VS Code と IntelliJ の2つの統合開発環境（IDE）では、 Gemini Code Assist エージェントモード が使用でき、AI エージェントによる開発を行うことができます。このエージェントモードは、バックエンドで Gemini CLI と同じ技術が動作しています。 エージェントモードでは、単なる自然言語に従った生成に留まらず、計画、実行、検証、反復的な修正など、複数のステップを含む複雑なタスクをこなすことができます。 参考 : Gemini CLI - Gemini Code Assist agent mode 参考 : Agent mode overview Gemini Code Assist エージェントモードでは、VS Code と IntelliJ において、以下のような機能が利用可能です。MCP サーバーの利用や、ユーザーの承認を得ずにすべてのタスクを Gemini CLI が実行できる Yolo モード、その他のツールなどが使用できます。 Model Context Protocol（MCP）servers Gemini CLI commands（ /memory 、 /stats 、 /tools 、 /mcp ） Yolo（You Only Look Once）mode built-in tools（ grep 、 terminal 、 file read or file write ...） Web search Web fetch プライバシーポリシーとデータ保護 Gemini モデルに関するデータ保護 Gemini CLI の「Terms of Service and Privacy Notice」は以下で公開されています。なお、当記事の記載内容は2025年9月中旬現在の情報に基づいていますので、最新情報は必ず以下の規約ドキュメントを確認してください。 参考 : GitHub - docs/resources/tos-privacy.md Gemini CLI で Gemini モデルを使用した際に、どのようなプライバシーポリシーが適用され、収集されたデータ（プロンプト、回答、コード）がどのように扱われるかは、 認証方法によって決まります 。 No 認証方法 概要 利用規約 プライバシーポリシー 1 Login with Google かつ Gemini Code Assist 有償プラン なし データは Google のサービス改善やモデル改善に使われる可能性が ある Google Terms of Service Gemini Code Assist Privacy Notice for Individuals 2 Login with Google かつ Gemini Code Assist 有償プラン あり データは Google のサービス改善やモデル改善には使われ ない Google Cloud Platform Terms of Service Gemini Code Assist Privacy Notice for Standard and Enterprise 3 Gemini API Key（無償版） データは Google のサービス改善やモデル改善に使われる可能性が ある Gemini API Terms of Service - Unpaid Service Google Privacy Policy 4 Gemini API Key（有償版） データは Google のサービス改善やモデル改善には使われ ない Gemini API Terms of Service - Paid Service Google Privacy Policy 5 Vertex AI データは Google のサービス改善やモデル改善には使われ ない Google Cloud Platform Service Terms Google Cloud Privacy 上記から、データが保護される（入力したプロンプトや AI からのレスポンスなどが Google のサービス改善や再トレーニングに使われ ない ことを指します）ための条件は、以下のとおりです。 Gemini Code Assist の有償プラン（Standard / Enterprise）のライセンスと紐づいた Google アカウントで認証している（表の2） Gemini API Key（Google AI Studio）の有償版で認証している（表の4） Google Cloud の Vertex AI で認証している（表の5） 上記以外のケースでは、個人 Google アカウントか Google Workspace アカウントかに関わらず、入出力データは Google に再利用される可能性があります。 なお、2025年7月初頭ころの Terms of Service and Privacy Notice ドキュメントでは、Google Workspace ユーザーであれば、無条件でデータが保護されるように解釈できる記載がありました。しかし2025年7月中旬ころにこの記載が改められ、上記に要約したとおりの記載となっています。 参考 : GitHub - google-gemini/gemini-cli/docs/tos-privacy.md - 8957ad7 前述したように、 Login with Google の方法で Google Workspace アカウントを使って認証する場合、どのような利用規約が適用されるのか、また料金が発生するかどうかについて、Google はドキュメントに明記していません。Google Workspace アカウントをお使いの方が業務等で Gemini CLI を利用する場合、Vertex AI で認証、あるいは Gemini Code Assist の有償プランを使って認証することが推奨されます。 Gemini CLI の統計情報 前述の表は、Gemini モデル側のデータの扱いを示しています。一方、Gemini CLI 自体も 利用統計 （Usage Statistics）という情報を収集しています。利用統計の収集は、 オプトアウト （無効化）することができます。 参考 : GitHub - docs/reference/configuration.md - Usage Statistics 利用統計では、ツールの呼び出しや API リクエストの記録、CLI の設定情報などが収集対象です。一方で、プロンプトやレスポンス、氏名やメールアドレス、ファイルの内容などは収集されません。よって、オプトアウトする、しないに関わらず、プロンプトやレスポンスが保護されるかどうかは、前述の規約に依存します。 前述の表の1と3では、利用統計をオプトアウトしたとしても、停止されるのは上記の統計情報の収集のみであり、依然としてプロンプトやレスポンスなどは Google に収集され、サービス改善や再トレーニングに使用される可能性は残ります。 よって、Gemini CLI を業務で使用したり、機微な情報を扱う場合は、前述の表の 2、4、5 のいずれかを選択することが望ましいといえます。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の堂原です。本記事では Google Cloud（旧称 GCP）の BigQuery において、データセットとリモートモデルが異なるリージョンに存在する場合の、AI データ処理パイプラインを紹介します。 はじめに 本記事の趣旨 ML.GENERATE_TEXT 関数と Gemini 2.0 の対応リージョン 概要 今回用いるデータ テーブル構成と処理概要 留意点 実装 1. us-central1 へ転送するデータ抽出 2. データセット「tokyo_from_tokyo_to_us」のテーブルをデータセット「us」にコピー 3. リモートモデル「gemini-model-20-flash」を用いてテーブル「daily-feedback」を処理 4. データセット「us_from_us_to_tokyo」のテーブルをデータセット「tokyo」にコピー 5. 評価済みデータの整形 処理結果 はじめに 本記事の趣旨 本記事では、BigQuery データセット・テーブルと BigQuery ML のリモートモデルが異なるリージョンに存在する状況下における、データ処理パイプラインについて紹介します。 具体的には、 BigQuery Data Transfer Service を用いて、処理の対象となるデータをリモートモデルが存在するリージョンにコピーし、コピーしたデータに対して処理をします。 参考 : BigQuery の AI と ML の概要 参考 : BigQuery Data Transfer Service とは ML.GENERATE_TEXT 関数と Gemini 2.0 の対応リージョン BigQuery ML の ML.GENERATE_TEXT は、SQL クエリから直接大規模言語モデル（LLM）を呼び出し、テキスト生成や分類などのタスクを実行できる関数です。これにより、データの前処理から LLM による推論までを一貫して BigQuery で完結させることができます。 参考 : ML.GENERATE_TEXT 関数を使用してテキストを生成する  |  BigQuery  |  Google Cloud BigQuery ML の制約として、テーブルとリモートモデルは同一のリージョンに存在する必要があります。一方、2025 年 5 月現在、Gemini 2.0 や Gemini 2.5 は東京リージョン（asia-northeast1）で利用できず、東京リージョンに保存されている BigQuery のデータを直接処理できません。 参考 : Gemini 2.0 Flash  |  Generative AI on Vertex AI  |  Google Cloud 参考 : Gemini 2.5 Pro  |  Generative AI on Vertex AI  |  Google Cloud 概要 今回用いるデータ 今回使用するデータは、架空のスマートフォンに寄せられたユーザーフィードバックです。以下のスキーマを持つテーブルを想定しています。 フィールド名 型 説明 timestamp TIMESTAMP フィードバックを受けた日時 userEmail STRING ユーザーのメールアドレス userFeedback STRING ユーザーのフィードバックメッセージ 以下にサンプルデータを示します。 timestamp userEmail userFeedback 2025-05-24 09:20:00 UTC user_gg@example.com サポートセンターの対応が迅速で丁寧でした。これからも応援しています！ 2025-05-23 21:55:00 UTC user_ee@test.jp 通知音が小さくて気づかないことが多いです。もっと大きくしてください。マナーモードでも振動が弱いです。 テーブル構成と処理概要 当記事では、架空のスマートフォンに寄せられたユーザーフィードバックを、Gemini 2.0 Flash を使って「ポジティブ」「ネガティブ」「ニュートラル」に分類するパイプラインを構築します。 まず、登場する複数のデータセットとテーブルの関係性を図に示します。 パイプラインは以下の5つのステップで構成され、それぞれスケジュールされた時間で実行されます。 ステップ リージョン コンポーネント 開始時間 処理内容 1 asia-northeast1 スケジュールドクエリ 毎日 01:00 us-central1 へ転送するデータ抽出（「daily-feedback」テーブル更新） 2 us-central1 Data Transfer Service 毎日 01:30 データセット「tokyo_from_tokyo_to_us」のテーブルをデータセット「us」にコピー 3 us-central1 スケジュールドクエリ 毎日 02:00 リモートモデル「gemini-model-20-flash」を用いてテーブル「daily-feedback」を処理（「evaluation-of-daily-feedback」テーブル更新） 4 asia-northeast1 Data Transfer Service 毎日 02:30 データセット「us_from_us_to_tokyo」のテーブルをデータセット「tokyo」にコピー 5 asia-northeast1 スケジュールドクエリ 毎日 03:00 評価済みデータの整形（「evaluation-of-feedback」テーブル更新） 留意点 単純化するため、当記事ではスケジュールドクエリと Data Transfer Service の設定を個別に行い、30 分ごとに実行するようにしていますが、実際には Cloud Workflows などのオーケストレーションツールを用いて一連のパイプラインとして統合することが推奨されます。 また、本パイプラインでは、異なるリージョン間でデータを転送するため、BigQuery のデータ転送料金が発生します。同一リージョン内で処理を完結させる場合に比べて追加の費用がかかる点にご留意ください。詳細な料金については、Google Cloud の公式ドキュメントをご確認ください。 参考 : Data extraction pricing 実装 1. us-central1 へ転送するデータ抽出 asia-northeast1 に存在するフィードバックデータ「product-feedback」から、当日に処理したいデータを抽出します。この抽出結果は、一時的にデータセット「tokyo_from_tokyo_to_us」のテーブル「daily-feedback」に格納されます。 これは、Data Transfer Service によるデータ転送時の課金対象データ量を削減するためです。 -- 挿入先のテーブルを空に TRUNCATE TABLE `tokyo_from_tokyo_to_us.daily-feedback`; -- データ挿入 INSERT INTO `tokyo_from_tokyo_to_us.daily-feedback` SELECT * FROM `tokyo.product-feedback` WHERE DATE ( timestamp , " Asia/Tokyo " ) = DATE (@run_time, " Asia/Tokyo " ) - 1 ; この SQL は、BigQuery のスケジュールドクエリとして毎日午前 1 時に実行されるように設定します。 @run_time パラメータは、スケジュールドクエリの実行時に自動的に現在のタイムスタンプが渡されます。 2. データセット「tokyo_from_tokyo_to_us」のテーブルをデータセット「us」にコピー 次に、ステップ 1 で抽出したデータを asia-northeast1 から us-central1 へコピーします。これには Data Transfer Service を使用します。 Data Transfer Service の設定は以下の通りです。 送信元データセット : tokyo_from_tokyo_to_us (asia-northeast1) 送信先データセット : us (us-central1) オプション Overwrite destination table : 有効 このデータ転送は、毎日午前 1 時半に実行されるようにスケジュールします。 3. リモートモデル「gemini-model-20-flash」を用いてテーブル「daily-feedback」を処理 us-central1 にコピーされたデータに対して、BigQuery ML の ML.GENERATE_TEXT 関数を用いてフィードバックの評価を行います。評価結果は、データセット「us_from_us_to_tokyo」内の「evaluation-of-daily-feedback」テーブルに格納されます。 -- プロンプト DECLARE prompt_template STRING; SET prompt_template = """ スマートフォン「ryu-do phone」に対する、ユーザーからのフィードバックを与えます。そのフィードバックが以下の評価のうち、どれに最も当てはまるかを回答してください。: - ポジティブ - ネガティブ - ニュートラル # フィードバック UIが直感的でとても使いやすいです。 # 評価 ポジティブ # フィードバック 指紋認証の精度が悪く、なかなか認識してくれません。ストレスが溜まります。 # 評価 ネガティブ # フィードバック __feedback__ # 評価 """ ; -- 挿入先のテーブルを空に TRUNCATE TABLE `us_from_us_to_tokyo.evaluation- of -daily-feedback`; -- Geminiによるフィードバックの評価 INSERT INTO `us_from_us_to_tokyo.evaluation- of -daily-feedback` SELECT timestamp , userEmail, ml_generate_text_llm_result AS evaluation FROM ML.GENERATE_TEXT( MODEL `us.gemini-model -20 -flash`, ( SELECT REPLACE (prompt_template, " __feedback__ " , userFeedback) AS prompt, * FROM `us.daily-feedback` ), STRUCT( 0 AS temperature, 8192 AS max_output_tokens, TRUE AS flatten_json_output ) ); この SQL は、BigQuery のスケジュールドクエリとして毎日午前 2 時に実行されるように設定します。 4. データセット「us_from_us_to_tokyo」のテーブルをデータセット「tokyo」にコピー ステップ 3 で処理された評価結果を、再び asia-northeast1 へコピーします。これも Data Transfer Service を使用します。 送信元データセット : us_from_us_to_tokyo (us-central1) 送信先データセット : tokyo (asia-northeast1) オプション Overwrite destination table : 有効 このデータ転送は、毎日午前 2 時半に実行されるようにスケジュールします。 5. 評価済みデータの整形 最後に、asia-northeast1 にコピーされた評価済みデータを、元のフィードバックデータと結合し、最終的な形式に整形します。この整形結果は、分析用テーブル「evaluation-of-feedback」に格納されます。 -- データの重複を防ぐため、同一期間のデータを削除 DELETE FROM `tokyo.evaluation- of -feedback` WHERE DATE ( timestamp , " Asia/Tokyo " ) = DATE (@run_time, " Asia/Tokyo " ) - 1 ; -- 処理内容を挿入 INSERT INTO `tokyo.evaluation- of -feedback` SELECT evaluation. timestamp , evaluation.userEmail, feedback.userFeedback, evaluation.evaluation[f:id:ggen-sugimura:20250627090010p:plain] FROM `tokyo.evaluation- of -daily-feedback` AS evaluation INNER JOIN `tokyo_from_tokyo_to_us.daily-feedback` AS feedback ON evaluation. timestamp = feedback. timestamp AND evaluation.userEmail = feedback.userEmail; この SQL は、BigQuery のスケジュールドクエリとして毎日午前 3 時に実行されるように設定します。 処理結果 上記のパイプラインを実行することで、テーブル「evaluation-of-feedback」には以下のようなデータが格納されます。 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-genの福井です。Cloud Run から Cloud SQL に対し、内部通信と IAM データベース認証を使用してセキュアに接続する手順を紹介します。 はじめに 当記事の概要 内部通信での接続 IAM データベース認証 事前準備 API の有効化 環境変数の設定 環境構築 ネットワーク環境の構築 Cloud SQL インスタンスの作成 アプリケーションの準備 ディレクトリ構成 アプリケーションソース Cloud Run へのデプロイ サービスアカウントの作成と権限付与 Cloud SQL ユーザーとしてのサービスアカウント登録 Cloud Run にデプロイ 動作確認 はじめに 当記事の概要 当記事では、Google Cloud のフルマネージドなコンテナ実行環境である Cloud Run から、同じくフルマネージドなリレーショナルデータベースサービスである Cloud SQL へセキュアに接続する手順について解説します。 blog.g-gen.co.jp 具体的には、以下2点の方法でセキュアな接続を実現します。 内部通信での接続 当記事では、Cloud SQL インスタンスに外部 IP アドレスを付与せず、VPC ネットワーク内の閉じた経路で Cloud Run から接続します。これにより、セキュリティリスクを低減します。 また、Cloud Run から VPC ネットワークへのアクセスには、 Direct VPC Egress を利用します。 参考 : パブリック IP を無効にする 参考 : Cloud RunのDirect VPC Egressを解説 - G-gen Tech Blog IAM データベース認証 Cloud SQL のデータベースユーザーとパスワードでの認証の代わりに、サービスアカウントを利用した IAM データベース認証 を使用します。これにより、パスワード管理の煩雑さから解放され、アクセス制御を IAM で統一管理できるため、よりセキュアにデータベースへのアクセスが実現できます。 参考 : IAM 認証 事前準備 API の有効化 Cloud Run、Cloud SQL、VPC ネットワーク、およびコンテナイメージの保存に必要な Artifact Registry などの API を有効化します。 gcloud services enable \ sqladmin.googleapis.com \ compute.googleapis.com \ servicenetworking.googleapis.com \ artifactregistry.googleapis.com \ cloudbuild.googleapis.com \ run.googleapis.com 環境変数の設定 以降の手順で繰り返し使用する Google Cloud プロジェクト ID やリージョンなどの情報を環境変数に設定します。 ご自身の環境に合わせて、以下のコマンドで環境変数を設定してください。 # Google Cloud プロジェクト ID # ※ ご自身の Google Cloud プロジェクト ID に置き換えてください export PROJECT_ID = " your-project-id " # プロジェクトのデフォルトリージョン export REGION = " asia-northeast1 " # Cloud SQL インスタンス名 export SQL_INSTANCE_NAME = " my-postgres-instance " # Cloud Run サービス名 export RUN_SERVICE_NAME = " my-app-service " # VPC ネットワーク名 export VPC_NETWORK_NAME = " my-vpc-network " # サブネット名 export SUBNET_NAME = " my-subnet " # Cloud SQL が使用するプライベート IP アドレス範囲名 export PRIVATE_IP_RANGE_NAME = " my-ip-range " # Cloud Run で使用するサービスアカウント名 export RUN_SA_NAME = " run-sa-for-sql " # Cloud SQL のデータベース名 export DB_NAME = " postgres " 環境構築 ネットワーク環境の構築 Cloud Run と Cloud SQL が安全に通信するためのプライベートなネットワーク環境を構築します。 VPC ネットワークの作成 Cloud Run サービスが Cloud SQL インスタンスへプライベートにアクセスするための基盤となる、VPC ネットワークを作成します。 この VPC ネットワークを通じて、Cloud Run と Cloud SQL 間の安全な通信経路を確立します。今回は、サブネットの IP アドレス範囲を自分で定義できるカスタムモードで作成します。 gcloud compute networks create $VPC_NETWORK_NAME \ --subnet-mode custom サブネットの作成 作成した VPC ネットワーク内にサブネットを作成します。 このサブネットは、Cloud Run サービスから VPC ネットワーク内への通信（Direct VPC Egress）における経由点となります。 gcloud compute networks subnets create $SUBNET_NAME \ --network = $VPC_NETWORK_NAME \ --range = 10 . 0 . 0 . 0 / 24 \ --region = $REGION プライベートサービスアクセスのための IP アドレス範囲の作成 Cloud SQL などの Google マネージドサービスを VPC ネットワークにプライベート接続するためには、それらのサービス専用の IP アドレス範囲を VPC ネットワーク内に予約する必要があります。 以下のコマンドで、VPC ネットワークに名前付きの IP アドレス範囲を作成します。この範囲は、Cloud SQL インスタンスが VPC ネットワーク内で使用する IP アドレスのプールとなります。 gcloud compute addresses create $PRIVATE_IP_RANGE_NAME \ --global \ --purpose = VPC_PEERING \ --prefix-length = 24 \ --network = $VPC_NETWORK_NAME プライベートサービスアクセスの構成 作成した IP アドレス範囲を使用して、VPC ネットワークと Google Cloud のサービスプロデューサーネットワークとの間にプライベートサービスアクセスの接続を確立します。 gcloud services vpc-peerings connect \ --service = servicenetworking.googleapis.com \ --network = $VPC_NETWORK_NAME \ --ranges = $PRIVATE_IP_RANGE_NAME 参考 : Google Cloud サービスへのプライベートサービスアクセス Cloud SQL インスタンスの作成 Cloud Run サービスから接続する Cloud SQL for PostgreSQL インスタンスを作成します。 インスタンスの作成 以下のコマンドで、PostgreSQL インスタンスを作成します。重要なポイントは以下の通りです。 パラメータ 説明 --network 先ほど作成し構成した VPC ネットワークを指定します。これにより、Cloud SQL インスタンスがこの VPC ネットワークに関連付けられます。 --no-assign-ip インスタンスに外部 IP アドレスが割り当てられないようにし、内部 IP アドレスのみを持つようにします。これにより、VPC ネットワーク外部からの直接的なアクセスを防ぎ、セキュリティを向上させます。 --database-flags=cloudsql.iam_authentication=on IAM データベース認証を有効にします。これにより、データベースユーザー名とパスワードの代わりに、IAM プリンシパルを使用して認証できます。 gcloud sql instances create $SQL_INSTANCE_NAME \ --database-version = POSTGRES_16 \ --region = $REGION \ --tier = db-custom-1-3840 \ --edition = ENTERPRISE \ --network = $VPC_NETWORK_NAME \ --no-assign-ip \ --database-flags = cloudsql. iam_authentication =on アプリケーションの準備 ディレクトリ構成 今回開発する Python アプリケーションのディレクトリ構成は以下のとおりです。 cloud-sql-sec-connect-demo-app |-- requirements.txt |-- Dockerfile |-- main.py アプリケーションソース Cloud SQL に接続して簡単な情報を取得する Python のウェブアプリケーションを作成します。 Cloud SQL への接続では、 Cloud SQL Python Connector を使用します。Cloud SQL Python Connector は、IAM データベース認証などの安全な接続を容易に実現するためのライブラリです。 requirements.txt Flask==3.1.1 gunicorn==23.0.0 Werkzeug==3.1.3 SQLAlchemy==2.0.41 cloud-sql-python-connector[pg8000]==1.18.2 Dockerfile FROM python:3.12-slim WORKDIR /usr/src/app COPY requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 7860 CMD [ " python ", " ./main.py " ] main.py import os from flask import Flask, jsonify from google.cloud.sql.connector import Connector, IPTypes import sqlalchemy from sqlalchemy import text app = Flask(__name__) INSTANCE_CONNECTION_NAME = os.environ[ "INSTANCE_CONNECTION_NAME" ] DB_USER = os.environ[ "DB_USER" ] DB_NAME = os.environ[ "DB_NAME" ] connector = Connector() engine = sqlalchemy.create_engine( "postgresql+pg8000://" , creator= lambda : connector.connect( INSTANCE_CONNECTION_NAME, "pg8000" , user=DB_USER, db=DB_NAME, enable_iam_auth= True , ip_type=IPTypes.PRIVATE, ), ) @ app.route ( "/" ) def index (): with engine.connect() as conn: version = conn.execute(text( "SELECT version()" )).scalar() current_db = conn.execute(text( "SELECT current_database()" )).scalar() current_user = conn.execute(text( "SELECT current_user" )).scalar() return jsonify({ "postgres_version" : version, "current_database" : current_db, "current_user" : current_user }) if __name__ == "__main__" : app.run(debug= True , host= "0.0.0.0" , port= int (os.environ.get( "PORT" , 7860 ))) Cloud Run へのデプロイ サービスアカウントの作成と権限付与 Cloud Run サービスが Cloud SQL インスタンスへ安全に接続し、IAM データベース認証を利用するためには、専用のサービスアカウントを作成し、必要な IAM ロールを付与します。サービスアカウントを使用することで、個人の認証情報ではなく、アプリケーション固有の認証情報で Google Cloud サービスを認証できます。 サービスアカウントの作成 gcloud iam service-accounts create $RUN_SA_NAME \ --display-name =" Cloud Run Service Account for SQL " サービスアカウントへの権限付与 # Cloud SQL インスタンスに接続するためのロール gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: $RUN_SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/cloudsql.client " # IAM データベース認証を使用して Cloud SQL インスタンスにログインするためのロール gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: $RUN_SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/cloudsql.instanceUser " # Cloud Run サービスが Cloud Logging にログを書き込むためのロール gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: $RUN_SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/logging.logWriter " Cloud SQL ユーザーとしてのサービスアカウント登録 前の手順でサービスアカウントに必要な IAM ロール（ roles/cloudsql.instanceUser など）を付与しましたが、それだけでは IAM データベース認証は完了しません。実際にデータベースにログインできるようにするには、このサービスアカウントを Cloud SQL インスタンスのユーザーとして登録する必要があります。 以下のコマンドを実行して、先ほど作成したサービスアカウントを Cloud SQL インスタンスに IAM 認証ユーザーとして追加します。 重要な点として、 --type=CLOUD_IAM_SERVICE_ACCOUNT を指定し、ユーザー名にはサービスアカウントのメールアドレスから末尾の .gserviceaccount.com を除いた部分を指定します。 gcloud sql users create $RUN_SA_NAME @ $PROJECT_ID .iam \ --instance = $SQL_INSTANCE_NAME \ --type = CLOUD_IAM_SERVICE_ACCOUNT Cloud Run にデプロイ Dockerfile が存在するディレクトリで、以下の gcloud コマンドを順次実行します。 gcloud run deploy $RUN_SERVICE_NAME --source . \ --region = $REGION \ --allow-unauthenticated \ --port 7860 \ --memory = 1Gi \ --min-instances = 0 \ --max-instances = 1 \ --service-account = $RUN_SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com \ --network = $VPC_NETWORK_NAME \ --subnet = $SUBNET_NAME \ --vpc-egress = private-ranges-only \ --set-env-vars = INSTANCE_CONNECTION_NAME = $PROJECT_ID : $REGION : $SQL_INSTANCE_NAME , DB_USER = $RUN_SA_NAME @ $PROJECT_ID .iam, DB_NAME = $DB_NAME 動作確認 Cloud Run サービスのデプロイが完了したら、実際にサービスにアクセスして、Cloud SQL インスタンスへ正しく接続できているかを確認します。 gcloud run deploy コマンドの実行が成功すると、コンソールに Service URL: としてデプロイされたサービスの URL が表示されます。この URL にウェブブラウザでアクセスするか、 curl コマンドでリクエストを送信してください。 # デプロイ時に表示された Service URL に置き換えてください curl https://my-app-service-XXXXX.asia-northeast1.run.app 正しく設定されていれば、以下のような JSON 形式のレスポンスが返ってきます。表示される内容は、ご自身の環境や PostgreSQL のバージョンによって若干異なる場合があります。 { " current_database ": " postgres ", " current_user ": " run-sa-for-sql@your-project-id.iam ", " postgres_version ": " PostgreSQL 16.9 on x86_64-pc-linux-gnu, compiled by Debian clang version 12.0.1, 64-bit " } 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進

G-gen の岡田です。当記事では、Google Workspace ライセンスの自動割り当ての設定方法と注意点についてご紹介します。 はじめに Google Workspace ユーザーとライセンスの割り当て ライセンスの自動割り当てとは 手動でのライセンス割り当て ライセンスの自動割り当ての設定手順 自動割り当ての注意点 はじめに Google Workspace ユーザーとライセンスの割り当て Google Workspace でユーザー（アカウント）を作成した後、ライセンスを割り当てたり、割り当てを解除することができます。たとえば、あるユーザーには Google Workspace Enterprise Plus のみを割り当てて、別のユーザーにはそれに加えて Chrome Enterprise Premium のライセンスを割り当てる、などの設定が可能です。 当記事では、ライセンスの自動割り当ての設定方法と注意点を解説します。 参考 : ライセンスの割り当て、削除、再割り当て 管理画面でのライセンスの割り当て ライセンスの自動割り当てとは ライセンスの自動割り当て とは、現在ライセンスが割り当てられていないユーザーと、これから新規に作成されるユーザーに、ライセンスが自動的に割り当てられる機能です。自動割り当ては サブスクリプション （ライセンスの購入単位）ごとに設定できます。 この設定は、ユーザー作成のたびに手動でライセンスを付与する手間の削減や、割り当て漏れの防止に役立ちます。 なお、自動割り当ての設定について、オン・オフを変更できるのは、複数のサブスクリプションを契約している場合のみです。単一のサブスクリプションのみ（例として Google Workspace の特定エディションのみ等）の場合、自動割り当ては デフォルトでオン です。 手動でのライセンス割り当て まずは、手動でのライセンス割り当て作業の手順を説明します。「ライセンスの自動割り当て」が無効の場合、ユーザーを作成しただけではライセンスは自動的に付与されませんので、以下の手順でライセンスを付与する必要があります。 Google Workspace の管理コンソール（ https://admin.google.com ）にログイン [ディレクトリ] > [ユーザー] > [新しいユーザーの追加] へ移動 ユーザー情報を入力し、「新しいユーザーの追加」をクリックしてユーザーを作成 作成が完了したら、作成したユーザーをクリックし [ユーザーの詳細] > [ライセンス] からライセンスを割り当て 参考 : 管理コンソールにログインする 参考 : ユーザーの追加方法 ライセンスの自動割り当ての設定手順 以下の手順でライセンスの自動割り当てを設定すると、ライセンスが自動的に割り当てられるようになります。 Google Workspace の管理コンソール（ https://admin.google.com ）にログイン [お支払い] > [ライセンスの設定] へ移動 対象の組織部門を選択し、自動で割り当てたいライセンスを選択して [自動ライセンス] を「オン」に設定し、保存 自動割り当ての注意点 年間プランを契約している場合、購入済みのライセンス数が不足していると、追加のユーザーにはライセンスが付与されません。 ライセンスの自動割り当てが「オン」の場合、個々のユーザーのライセンス割り当てを個別に解除することはできません。 契約しているのが単一のサブスクリプションのみの場合、自動割り当てはデフォルトで「オン」に固定され、設定を変更することはできません。 あとからサブスクリプションを追加した場合、はじめに契約していたサブスクリプションは自動割り当てがデフォルトで「オン」になり、あとから契約したサブスクリプションは「オフ」になります。 岡田 海里 (記事一覧) クラウドソリューション部 クラウドサポート課 2021年4月にG-genに入社。

G-gen の佐々木です。当記事では、Cloud Run の新しい実行モデルである Cloud Run Worker Pools を、実際に使ってみます。 はじめに Cloud Run Worker Pools とは 想定ユースケース 当記事の構成 Pub/Sub の作成 Cloud Run Worker Pools の作成 使用するコード（Go） コンテナイメージの作成 Cloud Run Worker Pools のデプロイ コンソールから確認 動作確認 はじめに Cloud Run Worker Pools とは Cloud Run は Google Cloud のサーバーレス コンテナ コンピューティングサービスです。HTTP リクエストベースでコンテナを実行する Cloud Run services 、スケジュールやワークフローベースのバッチ実行に特化した Cloud Run jobs 、そして HTTP リクエストやイベントベースで関数を実行する Cloud Run functions （旧 : Cloud Functions）といった実行モデルがあります。 Cloud Run Worker Pools は、Google Cloud Next '25 で発表された Cloud Run の新たな実行モデルであり、外からのリクエストを受けて実行される従来の実行モデルとは異なり、タスクやメッセージを能動的に取得する Pull ベース の実行モデルとされています。 参考 : Deployment options and resource model - Cloud Run worker pools Cloud Run Worker Pools の実行モデル サービスの詳細については、以下の記事で解説しています。 blog.g-gen.co.jp また、Cloud Run の基本については、以下の記事をご一読ください。 blog.g-gen.co.jp 想定ユースケース Cloud Run で Pull ベースの実行モデルが利用可能になると、従来の実行モデルでは実装が難しかった以下のようなユースケースが Cloud Run で実現できます。 Pub/Sub の pull サブスクリプションからメッセージを取得して処理を実行する Kafka キューからタスクを取得して処理を実行する GitHub Actions の Runner をホスティングしてワークフローを実行する 従来、このようなユースケースでは GKE で Kubernetes クラスタ上にワーカーを展開するケースなどが一般的でしたが、Cloud Run Worker Pools の登場により、サーバーレスのメリットを享受しながらワーカーを展開することができます。 GKE 上のワーカーで Pub/Sub のメッセージを Pull するケースについては、以下の記事で紹介しています。 blog.g-gen.co.jp 当記事の構成 当記事では、Pub/Sub から Pull したメッセージの処理を行う Cloud Run Worker Pools を作成します。 当記事で解説する内容は、記事を執筆した2025年6月25日当時（Preview 版）のものです。Cloud Run Worker Pools は2026年4月に一般公開（GA）されました。 Pub/Sub の作成 gcloud CLI で Pub/Sub のトピックと pull サブスクリプションを作成します。 当記事ではトピック名を worker-pools-topic 、サブスクリプション名を worker-pools-sub とします。` # Pub/Sub トピックの作成 $ gcloud pubsub topics create worker-pools-topic # Pub/Sub サブスクリプションの作成 $ gcloud pubsub subscriptions create worker-pools-sub --topic = worker-pools-topic Cloud Run Worker Pools の作成 使用するコード（Go） Cloud Run Worker Pools にデプロイするコンテナイメージを用意します。 以下のコードでは、Pub/Sub の Streaming Pull API を使用してメッセージを Pull し、メッセージの内容をログ出力します。 package main import ( "context" "fmt" "io" "log" "os" "cloud.google.com/go/pubsub" // Pub/Sub クライアントライブラリ ) // メッセージを StreamingPull する関数 func pullMessages(w io.Writer , c context.Context, projectId, subId string ) error { // Pub/Sub Client client, err := pubsub.NewClient(c, projectId) if err != nil { return fmt.Errorf( "pubsub.NewClient: %v" , err) } defer client.Close() // サブスクリプションの参照 sub := client.Subscription(subId) // メッセージを Pull し続ける err = sub.Receive(c, func (_ context.Context, msg *pubsub.Message) { fmt.Fprintf(w, "%v \n " , string (msg.Data)) // メッセージを標準出力に出力 msg.Ack() }) if err != nil { return fmt.Errorf( "sub.Receive: %v" , err) } return nil } func main() { ctx := context.Background() // 環境変数からプロジェクト ID と PubSub トピック ID を取得 projectId := os.Getenv( "PROJECT_ID" ) subId := os.Getenv( "SUBSCRIPTION_ID" ) err := pullMessages(os.Stdout, ctx, projectId, subId) if err != nil { log.Fatal(err) } } 参考 : Pull subscriptions - StreamingPull API コンテナイメージの作成 当記事では Dockerfile を使用せず、Cloud Build で Buildpack を使用してコンテナイメージをビルドします。 # Cloud Build で Buildpack を使用してコンテナイメージをビルド $ gcloud builds submit --pack image = < Artifact Registory のパス > 参考 : Google Cloud's buildpacks Cloud Run Worker Pools のデプロイ ベータ版の API を使用して、Cloud Run Worker Pools をデプロイしていきます。 2025年6月26日現在では、 gcloud beta run worker-pools deploy を使用して Cloud Run Worker Pools をデプロイすることができます。 # Cloud Run Worker Pools のデプロイ $ gcloud beta run worker-pools deploy hello-worker-pools \ --region = asia-northeast1 \ --image =< Artifact Registory のパス > \ --set-env-vars = PROJECT_ID = < Pub/Subがあるプロジェクト ID > , SUBSCRIPTION_ID =worker-pools-sub \ --scaling = 3 当記事では、 hello-worker-pools という名前で Cloud Run Worker Pools を作成します。 --image には先ほど作成したコンテナイメージを指す Artifact Registory のパスを指定し、環境変数（ --set-env-vars ）としてプロジェクト ID と Pub/Sub のサブスクリプション ID（当記事では worker-pools-sub ）を設定します。 最後にスケーリングの設定（ --scaling ）ですが、現在 Cloud Run Worker Pools では手動スケーリングのみサポートされているため、起動するインスタンス数をここで決定します。 当記事では Pub/Sub のメッセージが複数のコンテナインスタンスで分散処理されるかを確認するため、コンテナインスタンス数を 3 に固定して進めていきます。 参考 : gcloud beta run worker-pools deploy コンソールから確認 2025年6月26日現在、Google Cloud コンソール上には Cloud Run Worker Pools の画面が存在していますが、サービスの作成や更新はできず、CLI でデプロイしたサービスの表示と削除のみが可能になっています。 他の実行モデル同様に、デプロイした内容が リビジョン 単位で管理されていることがわかります。 Cloud Run Worker Pools の詳細画面（コンソール） 動作確認 Pub/Sub にメッセージを送信し、Cloud Run Worker Pools がメッセージを処理できるかを確認してみます。 Pub/Sub トピックのコンソール画面から、100個の Hello, Worker Pools!! というメッセージをトピックにパブリッシュします。 トピックにメッセージをパブリッシュする パブリッシュ後、Cloud Run Worker Pools のログを確認してみると、Cloud Run 側からメッセージを能動的に取得（Pull）できていることがわかります。 Cloud Run Worker Pools のログ 今回はコンテナインスタンス数を3に設定しているため、各コンテナインスタンスでメッセージが分散処理されているかを確認してみます。 ログエクスプローラから、以下のクエリで Cloud Run Worker Pools のログを検索します。 resource.type = "cloud_run_worker_pool" resource.labels.worker_pool_name = "hello-worker-pools" resource.labels.location = "asia-northeast1" textPayload="Hello, Worker Pools!!" ログの label.instanceId フィールドにログを出力した（=メッセージを処理した）コンテナインスタンスの ID が記録されているため、以下のようにクエリに追加することで、各コンテナインスタンスで処理したメッセージ数を確認できます。 resource.type = "cloud_run_worker_pool" resource.labels.worker_pool_name = "hello-worker-pools" resource.labels.location = "asia-northeast1" textPayload="Hello, Worker Pools!!" labels.instanceId="<インスタンスIDの値>" 当記事では3つのコンテナインスタンスのそれぞれで、38件、34件、28件のメッセージが処理されていました。起動しているコンテナインスタンス間でメッセージがある程度分散されていることがわかります。 各コンテナインスタンスごとのメッセージの処理数を確認する 佐々木 駿太 (記事一覧) 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 Workspace の標準機能である Google カレンダーと Google ToDo リストの概要、および連携による業務効率向上のための設定方法や利用例を解説します。 Google カレンダー Google カレンダーとは 活用術 1 : 業務時間と勤務場所の設定 活用術 2 : 業務時間分析 Google ToDo リスト Google ToDo リストとは 活用術 1 : タスクの整理 活用術 2 : 定期的なタスクの登録 活用術 3：他サービスとの連携 活用術 4 : タスク管理の Tips Google カレンダーと Google ToDo リストの連携 Google カレンダー Google カレンダーとは Google カレンダー は、Google が提供する オンラインカレンダーサービス です。個人の予定管理に加え、チームメンバーとのスケジュール共有、会議の招待、Google Meet を使用したビデオ会議へのアクセスなど、多岐にわたる機能を備えています。 Google カレンダーには、以下の特徴があります。 クラウドベースでのアクセス 直感的なインターフェースによる容易な予定作成・編集 他のユーザーとのカレンダー共有による円滑な予定調整 予定前のリマインダー通知による意図しない予定の見逃し防止 Gmail、Google Meet など、他の Google サービスとのシームレスな連携 参考 : カレンダーでできること 活用術 1 : 業務時間と勤務場所の設定 Google カレンダーには、単に予定を登録するだけでなく、より効率的にスケジュールを管理するための機能があります。その一つが 「業務時間と勤務場所」 の設定です。 設定手順 Google カレンダーを開き、画面右上の設定アイコン（歯車マーク）から「設定」を選択します。 次に、左側のメニューから「全般」セクション内の「業務時間と勤務場所」をクリックし、「業務時間を有効にする」のチェックボックスをオンにして各曜日の勤務時間を設定します。必要に応じて、日ごとの勤務場所（例 : オフィス、自宅、出張先）も設定できます。 メリット 設定を実施することにより業務時間外に会議が提案された場合、予定を作成するユーザーにその旨が通知されるため、自身の勤務時間外や外出中での会議設定を効果的に回避できます。 次に、どのように働いているか 社員の勤務環境を可視化 することもできます。昨今、オフィス勤務だけでなく自宅でのリモートワークやサテライトオフィス、コワーキングスペースなどハイブリッドな形式で業務をすることも多いかもしれません。そのような環境でチームメンバーや関係者に対し、現在の働き方（例 : オフィス勤務、リモートワーク）を知らせることができます。 Web会議で参加するのか、もしくはオフィスでオフライン形式で会議に参加できるのかをカレンダー上に表記することで、会議や共同作業も簡単にスケジュールを調整できます。 参考 : Google カレンダーで業務時間と業務場所を設定する 活用術 2 : 業務時間分析 自身の業務で何にどれくらい時間がかかっているのかを把握したい場合、Google カレンダーの 「時間の分析情報」 機能が有効です。この機能により、時間の使い方を分析できます。 「時間の分析情報」では、主に、週単位や月単位で会議に費やした時間、頻繁に会議を行う相手や会議が多い曜日・時間帯といった会議の傾向、会議が予定されていない時間などを分析できます。 手順 Google カレンダーの左側パネルにある 「時間の分析情報」 をクリックし、表示されたダッシュボードで時間の内訳や会議の傾向などを確認します。 ラベルの活用 より詳細な分析には、カレンダーの予定に 「ラベル」 を付与することを推奨します。例えば、「プロジェクトA」「資料作成」「顧客対応」といったラベルを作成し、各予定に割り当てることで、それぞれの活動に費やした時間を具体的に把握できます。 参考 : 会議に割いた時間を確認する Google ToDo リスト Google ToDo リストとは Google ToDo リストは、シンプルで直感的な タスク管理ツール です。Gmail や Google カレンダーのサイドパネルからアクセスでき、タスクの作成、ステータス管理、期日設定が可能です。 また、Google カレンダー上の切り替えボタンを押すことで全画面で Todo リストを確認することができます。 特徴 シンプルで直感的な操作性 Gmail のメールからの直接的なタスク作成、Google カレンダーへのタスク期日表示など、Google サービスとの連携 タスクへの期日設定とリマインダー通知機能 活用術 1 : タスクの整理 手順 Google ToDo リストを開き、画面上部（または下部）に表示されている現在のリスト名（例 : マイタスク）をクリックした後、「新しいリストを作成」を選択し、リスト名を入力します。 活用例 リストは、例えば以下のように分類して利用できます。 プロジェクト別（例 : 「プロジェクトX」「新機能開発」「マーケティングキャンペーン」） 業務内容別（例 : 「資料作成」「会議準備」「雑務」） リストを分けることでタスクが整理され、優先すべき作業に集中しやすくなります。 参考 : リストを整理する 活用術 2 : 定期的なタスクの登録 毎週月曜日の定例報告や毎日の日報作成など、定期的に発生するタスクは「繰り返し設定」の使用が効果的です。 手順 タスクを作成または編集する際に日付（期日）を設定し、日付の下に表示される「繰り返し」（時計マークのアイコン）をクリックして、繰り返しの頻度（毎日、毎週、毎月、毎年など）、間隔、終了日などを設定します。 効果 登録作業の削減（一度の設定でタスクが自動的に作成されます） タスク実行漏れの防止（定期的な業務の確実な遂行を支援します） 習慣化の促進（日常的に行いたい学習や運動などの習慣も、繰り返しタスクとして登録することで継続しやすくなります） 参考 : タスクを追加または編集する 活用術 3：他サービスとの連携 Google ToDo リストは、他の Google サービスと連携することで利便性が向上します。 Gmail からのタスク追加 受信したメールを開き、上部にある「ToDo リストに追加」アイコン（チェックマークにプラスが付いたアイコン）をクリックすることで、そのメールに関連するタスクを容易に作成できます。メールへのリンクも自動的にタスクに紐づけられるため、後から詳細を確認する際に便利です。 参考 : タスクを追加または編集する カレンダーでのタスク表示 Google ToDo リストで期日を設定したタスクは、Google カレンダー上にも表示されます（カレンダーの左側パネルで「ToDo リスト」カレンダーのチェックボックスをオンにする）。これにより、予定とタスクを一元的に把握できます。 参考 : タスクを追加または編集する 活用術 4 : タスク管理の Tips Google ToDo リストでは、タスクの下にサブタスクを作成できます。この機能を用いて大きなタスクを作成した後、具体的な行動レベルまで分割しサブタスクとして登録します。 これにより、着手すべき点が明確になり、達成感も得やすくなります。 また、全てのタスクが同じ重要度とは限りません。Google ToDo リストの「スター」機能で重要なタスクに印を付けたり、リスト内でタスクをドラッグアンドドロップして並び替えたりすることで、優先度の高いタスクから着手できます。 さらに、具体的な期日を設定することで、タスクへの意識が高まり、計画的な進行ができます。Google ToDo リストでは、各タスクに期日と時刻を設定できます。 Google カレンダーと Google ToDo リストの連携 Google カレンダーは 「時間軸の管理」 、ToDo リストは 「タスクの実行管理」 を担います。この2つを組み合わせることで、以下のような相乗効果が期待できます。 タスクの視覚的リマインド Google ToDo リストで期日を設定したタスクは、Google カレンダーの終日予定のセクションや指定した日時に表示されます。これは視覚的なリマインダーとして機能し、日々の予定の中でいつそのタスクに取り組むべきかを把握しやすくします。 タスク実行時間の確保 重要なタスクや集中して取り組みたいタスクがある場合、そのための時間をGoogle カレンダーに予定として確保（例 : 「資料作成集中タイム」など）し Todo リストに対してもタスクとして登録することで、該当タスクへの集中を促し、より確実にタスクを遂行できます。 横澤 綜一 (記事一覧) 事業開発部カスタマーサクセス課 英文学科からITの世界へ。Google Workspace 専任サポートから Google Workspace のカスタマーサクセスへロールが代わり日々奮闘中。週5でジムに通う。

G-gen の松本です。この記事では Google Workspace の AppSheet Core と AppSheet Enterprise Plus の違いについて解説します。 概要 AppSheet とは AppSheet のサブスクリプションプラン AppSheet Core Google Workspace に無料付帯 テンプレートから簡単にアプリ作成 Google Workspace アプリとの連携 管理コンソールでの制御 AppSheet Enterprise Plus 最上位プラン Google グループを利用したユーザーのアクセス制御 多様なデータソースとの連携 OCR 機能 チームへのリソース共有 組織全体のガバナンス強化 外部IDプロバイダ （IdP）との連携による高度な認証 詳細な監査ログと利用状況モニタリング Gemini との統合 概要 AppSheet とは AppSheet とは、Google が提供するノーコード開発プラットフォームです。プログラミングの知識不要で、業務アプリケーションを開発できます。その中でも AppSheet Core プランは、Google Workspace のサービスの一部として提供されています。 AppSheet を使うと、専門的なプログラミング知識がなくても、スプレッドシートなどの既存のデータソースを活用して、チェックリスト・在庫管理・日報・顧客管理などのカスタム業務アプリを簡単に作成できます。 AppSheet Core については、以下の記事も参照してください。 blog.g-gen.co.jp AppSheet のサブスクリプションプラン AppSheet には Free、Starter、Core、Enterprise Plus の計4つのサブスクリプションプランがあります。 AppSheet Free は、個人利用やプロトタイプ開発、テスト、個人間の共有など、特定の用途に限り無料でAppSheetの機能を利用できるプランです。 AppSheet Starter は、AppSheet 無料プランの上位プランであり、無料プランに比べてより多くのユーザーでの利用、基本的な自動化機能を備えています。主に個人事業主や小規模チームでの運用や、基本的な業務効率化アプリケーション開発に適したプランです。 AppSheet Core は、AppSheet Starter の上位プランであり、AppSheet Starter に比べてより高度なアプリ機能、自動化機能、セキュリティ機能を備えています。主に中小規模の組織での運用や、より実用的なビジネスアプリケーション開発に適したプランです。 AppSheet Enterprise Plus は、AppSheet Core の上位プランであり、AppSheet Core に比べてより高度な機能、管理機能、セキュリティ機能を備えています。大規模な組織での運用や、複雑なアプリケーション開発に適したプランです。また Gemini とも統合されており、強力な生成 AI 機能を備えたアプリを開発できます。アプリに生成 AI 機能（画像からの文字読み取りやテキストの分類など）を組み込みたい場合は、AppSheet Enterprise Plus を選びます。 参考 : サブスクリプションの選び方 参考 : AppSheet を無料で使用する（プロトタイプと個人用） AppSheet Core Google Workspace に無料付帯 AppSheet Core ライセンスは、主要な Google Workspace エディションでコアサービスとして登録されており、追加のサブスクリプションの登録不要で利用できます。 参考 : 組織で AppSheet を管理する AppSheet Core が利用可能な Google Workspace エディションは以下の通りです。 Business Starter Business Standard Business Plus Enterprise Starter Enterprise Standard Enterprise Plus Education Standard Education Plus Enterprise Essentials Plus Frontline Starter Frontline Standard Frontline Plus Google Workspace for Nonprofits テンプレートから簡単にアプリ作成 AppSheet では、プログラミングの知識が無くてもドラッグ＆ドロップ操作で直感的にアプリを開発できます。また、用途別に様々なテンプレートも用意されているので、それらを利用して開発することもできます。 AppSheet のテンプレート選択画面 Google Workspace アプリとの連携 AppSheet は、Gmail、Google Calendar、Google スプレッドシートなどの Google Workspace コアアプリをデータベースとして連携ができます。既存のデータを活用してアプリを構築できるため、手軽に業務の効率を高められます。 以下は、Googleの各種サービスと連携して実現できるアプリの例です。 Gmail との連携 例として、AppSheet の顧客管理アプリで設定したアクション（例：商談成立、見積もり提出後）に応じて、顧客へのお礼メールやフォローアップメールを Gmail で自動送信できます。 顧客との関係性を強化しつつ、人的ミスによるフォロー漏れを防ぎ、顧客満足度の向上に貢献します。 Google スプレッドシートとの連携 タスク名、担当者、期日、進捗状況などを Google スプレッドシートで管理し、AppSheet で担当者ごとのタスク表示、進捗更新、期日管理などの機能を持つアプリが作成できます。 各メンバーのタスク状況やプロジェクト全体の進捗を一目で把握でき、タスクの遅延防止に繋がります。 Google カレンダーとの連携 会議、セミナー、ワークショップなどのイベント情報を AppSheet で作成・管理し、その予定を Google カレンダーに自動的に登録・同期。参加者への招待、出欠確認なども AppSheet 上で完結できます。 イベントに関する情報を AppSheet で集約し、Google カレンダーでスケジュールとして可視化することで、情報管理の効率化に貢献します。 管理コンソールでの制御 管理者は、以下の操作を有効化または無効化できます。 外部のアプリユーザーとの間での AppSheet のアプリとデータベースの共有 外部アプリデータへの接続 外部の宛先に送られる自動化メール アプリの API を使用した外部統合 Webhook 機能 参考 : AppSheet へのアクセスを管理する AppSheet Enterprise Plus 最上位プラン AppSheet Enterprise Plus は、AppSheet Core の最上位プランです。より高度な機能、管理機能、セキュリティ機能を備えており、大規模な組織での運用や、複雑なアプリケーション開発ができます。 また、Enterprise Plus には Gemini for App Creation 、 Gemini for AppSheet Solutions といった AI 機能も備わっており、生成 AI 補助のもとアプリを開発したり、AI 機能を使ったアプリを開発することができます。 その他にもバージョン管理、Active Directory や OpenID Connect との認証連携、チーム機能など、エンタープライズグレードの AppSheet 利用のための機能が充実しています。 参考 : サブスクリプションの選び方 Google グループを利用したユーザーのアクセス制御 AppSheet ではデフォルトですべてのユーザーでアプリの作成ができますが、Google グループを使用することでアプリの作成を行うユーザーを限定できます。 Google グループで「アプリ作成を許可する」メンバーが所属するグループを作成し、AppSheet に統合することで Google Workspace 内でアプリの開発者/利用者を分けて運用できます。 参考 : Google グループを使用してユーザーのアクセスをコントロールする 多様なデータソースとの連携 複数のクラウドベースのデータソースや大規模なデータベースと接続することで、大量のデータを活用したアプリを開発できます。 AppSheet で Google スプレッドシートをデータソースとして使用する場合、サポートされる行数は最大100,000行です。しかし、AppSheet Enterprise Plus ライセンスでは以下の大規模データソースと接続できるため、より大規模なデータセットを利用できます。 Apigee AppSheet API AWS DynamoDB BigQuery MariaDB MySQL OData オンプレミス データベース Oracle PostgreSQL Salesforce SQL Server 参考 : サブスクリプションの選び方 OCR 機能 光学文字認識 （OCR） 機能を利用し、画像データや手書き文字から文字情報を読み取り、テキストデータとして抽出できます。例えば、複数の名刺や請求書をカメラで撮影し、抽出したデータをフォームに入力することなどができます。 AppSheet の OCR 機能を使用すると画像からフォームに自動的に入力できるため、データ入力にかかる時間を短縮できます。 参考 : 光学式文字認識（OCR） チームへのリソース共有 AppSheet Enterprise Plus では、組織で作成したサンプルアプリの共有ができます。チーム内で共有することで開発時間の短縮や、作成するアプリの品質向上に繋がります。 また、AppSheet Enterprise Plus では MySQL などのクラウドデータベースや、Google スプレッドシートなどへの接続設定を共有できます。チーム全体が同じデータソースを利用することで、データソースの設定時間を削減でき、接続情報を管理できるためセキュリティの向上に繋がります。 参考 : リソースをチームと共有する 組織全体のガバナンス強化 AppSheet Enterprise Plus では、組織全体の AppSheet 利用に関する詳細なルール （ガバナンスポリシー）を管理者が一元的に設定できます。AppSheet Core でも一部の制御は可能ですが、Enterprise Plus ではより細かな設定が可能です。 例として、組織として許可したデータソース （特定のデータベースやクラウドストレージのフォルダなど）以外への接続を禁止し、接続可能なデータソースを制限できます。 これにより、情報漏洩リスクが低減できます。 参考 : ガバナンス ポリシーを定義する 外部IDプロバイダ （IdP）との連携による高度な認証 AppSheet Enterprise Plus では、Okta や Azure AD （Active Directory） など、企業で既に利用している外部のIDプロバイダ（IdP）と連携したシングルサインオン（SSO）環境を構築できます。 AppSheet Core でも Google Workspace アカウントでの認証が基本ですが、Enterprise Plus を利用することで、従業員は普段利用しているIDとパスワードで AppSheet アプリにアクセスでき、 IdP側で設定されている多要素認証を AppSheet 利用時にも適用できます。 これらにより、ユーザーの利便性を損なうことなく、企業全体の認証ポリシーに準拠した強固なアクセス管理が可能です。 参考 : Active Directory を使用してユーザー アクセスを制御する 参考 : Okta を使用してユーザーのアクセスを制御する 参考 : OpenID Connect を使用してユーザーのアクセスを制御する 詳細な監査ログと利用状況モニタリング AppSheet Enterprise Plus では、アプリの利用状況やデータ変更に関する詳細な監査ログを取得し、管理者が確認・分析できます。これにより、いつ、誰が、どのような操作を行ったかを追跡し、セキュリティインシデント発生時の原因究明や不正アクセスの検知に役立ちます。 具体的には、以下のような情報が記録されます。 アプリの起動、同期、データ変更（追加・更新・削除）の履歴 自動化の実行履歴 エラーの発生状況 これらの監査ログは、Google Cloud の BigQuery にエクスポートしてより長期間の保管や高度な分析を行うこともできます。AppSheet Core でも基本的なエラーログなどは確認できますが、Enterprise Plus ではより詳細な確認が可能です。 参考 : Audit History を使用してアプリのアクティビティをモニタリングする 参考 : チーム監査ログを BigQuery にエクスポートする Gemini との統合 AppSheet の Enterprise Plus エディションは、Google の生成 AI モデルである Gemini と統合 されています。 Gemini for App Creation は、AI 補助のもとアプリを開発できる機能です。自然言語でアプリのアイデアやビジネスプロセスの説明をするだけで、推奨されるテーブルと列を提案するなど、アプリ開発を AI が補助します。 Gemini for AppSheet Solutions は、アプリの中で AI を利用できる機能です。Gemini for AppSheet Solutions を使うと、画像から情報を抽出したり、PDF ドキュメントを処理したり、情報を分類したりできます。つまり、生成 AI の協力な機能を備えたアプリをノーコードで開発できます。 なお、前者の Gemini for App Creation は、Enterprise Plus エディションだけでなく、AppSheet Core とその他の有料ライセンスで使用可能です。 一方で後者の Gemini for AppSheet Solutions を使うには、AppSheet の Enterprise Plus エディションが必要です。画像からの文字読み取りや、テキストを分類させたりするなどの生成 AI 機能をアプリに組み込みたい場合は、AppSheet Enterprise Plus エディションのライセンスを購入してください。 参考 : Gemini in AppSheet を使用する 参考 : サブスクリプションの選び方 松本 迅人 (記事一覧) クラウドソリューション部 クラウドサポート課 栃木県出身。6年間製造関係の会社に在籍し、その後IT業界にシフト。 現在は Google Workspace を中心にカスタマーサポートに従事。 趣味はキャンプ、カメラ、エレキベース、バイク

G-gen の杉村です。Google Cloud のログ収集、保管、閲覧サービスである Cloud Logging のクエリ言語を徹底解説します。 クエリ言語 Logging クエリ言語とは クエリ言語のその他の用途 基本的な使い方 クエリの仕方 例文 ログエクスプローラでの生成 ブール演算子 AND、OR 括弧 NOT 比較演算子 =、!=（equal、not equal） :（has） フィールドの存在確認 正規表現 =~、!~（正規表現） 正規表現の記述 検索のスピード 文字列の検索 グローバル制限（単純な検索） SEARCH 関数 時間の指定 ログエクスプローラでの指定 クエリ言語での指定 コメント 高速な検索 インデックスの利用 時間帯を絞る 部分一致よりもイコール クエリ言語 Logging クエリ言語とは Google Cloud のログ収集、保管、閲覧サービスである Cloud Logging は、Google Cloud コンソールの ログエクスプローラ 画面で、 Logging クエリ言語 （Logging query language）という独自のクエリ言語を使ってログを自在にフィルタし、閲覧することができます。Logging クエリ言語は、ログエクスプローラのほか、gcloud コマンドや Cloud Logging API へのリクエストにも使うことができます。 Logging クエリ言語の構文（文法）は以下のドキュメントに記載されています。当記事では、重要な構文の書き方を解説します。 参考 : Logging のクエリ言語 クエリ言語のその他の用途 Cloud Logging では ログルーター （シンク）を用いて、ログを任意のログバケットや BigQuery に転送、保管できます。ログルーターには、転送対象のログを指定するための含有フィルタや除外フィルタを記述します。 このフィルタの記述にも、Logging のクエリ言語が使われます。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - ログルーティングとログの保存 また、Cloud Logging のログに基づいてメールなどを発報するためのログベースのアラートやログベースの指標などにおいても、対象のログを指定するために Logging クエリ言語が使われます。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - ログ監視 このように、Logging クエリ言語は Cloud Logging に関わる多くの場面で使われます。 基本的な使い方 クエリの仕方 Logging クエリ言語は、Google Cloud コンソールの「ロギング」 > 「ログ エクスプローラ」の画面で使用します。 もしクエリを書き込む検索ボックスが表示されていない場合は、「クエリを表示（①）」を押下します。検索ボックス（②）にクエリを記載し、「クエリを実行（③）」を押下することで、検索が実行されます。 クエリ言語の使い方 例文 Logging クエリ言語を使ったクエリの例文を、いくつか紹介します。 Google Kubernetes Engine（GKE）クラスタのログで、重要度が ERROR のログ resource . type = " k8s_cluster " AND severity= " ERROR " インスタンススケジュールによる Compute Engine VM の起動・停止ログ ( protoPayload.methodName= " v1.compute.instances.stop " OR protoPayload.methodName= " v1.compute.instances.start " ) AND protoPayload.authenticationInfo.principalEmail= " service-1234567890@compute-system.iam.gserviceaccount.com " アカウント john.doe@g-gen.co.jp によって実行された BigQuery テーブル my_table へのクエリのログ protoPayload.authenticationInfo.principalEmail= " john.doe@g-gen.co.jp " AND protoPayload.methodName= " jobservice.insert " AND protoPayload.serviceData.jobInsertResponse. resource .jobStatistics.referencedTables.tableId= " my_table " ログエクスプローラでの生成 Logging クエリ言語には、当記事で紹介するような多数の構文がありますが、ほとんど覚える必要がないともいえます。 ログエクスプローラで、検索したいログと類似のログを見つけたあと、対象のフィールドの値（①）をクリックして表示されたプルダウンメニューから「一致エントリを表示」または「一致エントリを非表示」を選択（②）すると、その値を検索するようなクエリが検索ボックス（③）に追加されます。 クエリ言語はコンソールで生成できる このようにして追加されたクエリ言語を、部分的に修正して、目当てのログを探すためのクエリを作成することができます。 Logging クエリ言語の文法を詳細に覚えなくても、基本的な文法と概要を理解していれば、類似のログから検索クエリを生成して、目当てのログへたどり着くことができます。 ブール演算子 AND、OR AND と OR は、Logging クエリ言語を使う上で最も重要な演算子です。 AND と OR は、必ず 大文字 で書く必要があります。小文字で書くと、検索キーワードとして解釈され、後述のグローバル制限（グローバル検索）が行われてしまいます。 protoPayload.methodName= " v1.compute.instances.stop " OR protoPayload.methodName= " v1.compute.instances.start " 上記のクエリでは、メソッド名が "v1.compute.instances.stop" または "v1.compute.instances.start" であるログを抽出しています。上記のようなクエリで、 AND を使うことはありえません。メソッド名が "v1.compute.instances.stop" であり、 かつ "v1.compute.instances.start" であるログはありえないからです。 OR を使うことで、"v1.compute.instances.stop" または "v1.compute.instances.start" に当てはまるログがすべて抽出されます。 なお、 AND は省略することができます。2つの以上のステートメント（個々のクエリの記述のこと）を記載したとき、結合方法は AND になります。以下の2つのクエリは、同じ意味を持ちます。 protoPayload.methodName= " v1.compute.instances.stop " AND resource .labels.instance_id= " 1234567890123456789 " protoPayload.methodName= " v1.compute.instances.stop " resource .labels.instance_id= " 1234567890123456789 " 括弧 OR や AND は括弧でくくることができます。以下のクエリでは、メソッド名が "v1.compute.instances.stop" であり、かつインスタンス ID が "1234567890123456789" または "0987654321098765432" であるログが抽出されます。 protoPayload.methodName= " v1.compute.instances.stop " AND ( resource .labels.instance_id= " 1234567890123456789 " OR resource .labels.instance_id= " 0987654321098765432 " ) NOT NOT は、 AND と OR の意味を反転します。以下のクエリでは、メソッド名が "v1.compute.instances.stop" であり、かつインスタンス ID が "1234567890123456789" ではない ログが抽出されます。 NOT も、必ず大文字で書く必要があります。 protoPayload.methodName= " v1.compute.instances.stop " AND NOT resource .labels.instance_id= " 1234567890123456789 " また、 NOT の代わりに - （マイナス記号）を使うこともできます。以下のクエリは、上記のクエリと同じ意味です。 protoPayload.methodName= " v1.compute.instances.stop " - resource .labels.instance_id= " 1234567890123456789 " 比較演算子 =、!=（equal、not equal） = や != はその見た目のとおり、一致していること、または一致していないことを指します。 以下の2つのクエリは同じ意味を持ちます。 protoPayload.methodName= " v1.compute.instances.stop " AND NOT resource .labels.instance_id= " 1234567890123456789 " protoPayload.methodName= " v1.compute.instances.stop " AND resource .labels.instance_id!= " 1234567890123456789 " = や != の前後には、スペースを入れても入れなくても構いません。 protoPayload.methodName = " v1.compute.instances.stop " AND resource .labels.instance_id != " 1234567890123456789 " :（has） : は has と呼ばれ、指定した文字列を含むログを抽出します。 以下のログでは、 protoPayload.authenticationInfo.principalEmail に "@g-gen.co.jp" という文字列が含まれているログを抽出します。 protoPayload.authenticationInfo.principalEmail : " @g-gen.co.jp " AND protoPayload.methodName= " jobservice.insert " また、 : では括弧を使って複数の条件を指定することができます。 protoPayload.authenticationInfo.principalEmail : ( " @g-gen.co.jp " OR " @example.co.jp " ) AND protoPayload.methodName= " jobservice.insert " また、 : を使ったクエリでは、大文字と小文字は区別されません。以下のクエリは、1つ前のクエリと同じ結果を返します。 protoPayload.authenticationInfo.principalEmail : ( " @G-GEN.CO.JP " OR " @EXAMPLE.CO.JP " ) AND protoPayload.methodName= " jobservice.insert " フィールドの存在確認 :* を使うと、値を問わず、そのフィールドが存在しているログエントリを抽出できます。 protoPayload.serviceName= " iap.googleapis.com " protoPayload.authenticationInfo.principalEmail:* 正規表現 =~、!~（正規表現） =~ は、正規表現を使うための比較演算子です。Logging クエリ言語では、 RE2 と呼ばれる Google が定義する正規表現構文を使います。 以下のクエリでは、メソッド名が "v1.compute.instances." で始まるログを抽出します。 protoPayload.methodName=~ " ^v1\.compute\.instances\..+ " ^ は文字列の先頭を意味します。 . はそのままだと任意の文字列を意味するメタ文字なので、 \ でエスケープします。末尾の .+ は、任意の文字列が1文字以上繰り返されることを意味します。 !~ は、 =~ とは逆に、正規表現に一致しないログを抽出します。 resource .labels.instance_id = " 1234567890123456789 " AND protoPayload.methodName !~ " v1.compute.instances.get " なお、正規表現では大文字と小文字は区別されます。以下の2つのクエリでは、結果が異なります。 protoPayload.methodName=~ " ^v1\.compute\.instances\..+ " protoPayload.methodName=~ " ^V1\.COMPUTE\.INSTANCES\..+ " 正規表現の記述 正規表現はプログラマーにとっては使い慣れたツールですが、正規表現の文法に慣れていない人もいるでしょう。日本語で指示して Gemini アプリ（ https://gemini.google.com ）などの生成 AI に正規表現を記述させるのも有用です。 ただし、無償版 Google アカウントで利用する Gemini アプリに投入したプロンプトなどは、Google によってモデルの再トレーニングに利用される場合があることに注意してください。Google Workspace アカウントでログインした状態で Gemini アプリを使っている場合、データは保護されます（エンタープライズグレードのデータ保護）。 参考 : Gemini for Google Workspace に関するよくある質問 - Gemini for Google Workspace ではどのようにデータが保護されますか？ 検索のスピード 以下の2つのクエリの意味はほとんど同じですが、 : を使ったクエリよりも、 =~ を使った正規表現によるクエリのほうが 高速 です。 protoPayload.authenticationInfo.principalEmail : " @g-gen.co.jp " protoPayload.authenticationInfo.principalEmail =~ " .+@g-gen\.co\.jp " 文字列の検索 グローバル制限（単純な検索） 以下のように単純に文字列をダブルクォーテーションで囲って検索ボックスに入力し、クエリすることで、その文字列を含むログを抽出できます。 " password authentication failed " このような文字列による単純な検索を、グローバル制限（global restriction）またはグローバル検索といいます。グローバル制限は、以下のように AND や OR を使うことができます。 ( " password authentication failed " AND ( " postgres " OR " mysql " ) ) グローバル制限による検索では、暗黙的に : （has）が使われています。グローバル制限による検索では、ログエントリのすべてのフィールドを : で検索するため、結果が返ってくるのが遅くなる可能性があります。 SEARCH 関数 前述のグローバル制限による単純な文字列検索では、結果が返ってくるまで時間がかかる場合があります。Logging クエリ言語の組み込み関数である SEARCH() 関数を使うと、検索対象のフィールドを指定できます。 SEARCH(textPayload, " password authentication failed " ) SEARCH() 関数は、フィールドを指定しないで検索に使うこともできます。このとき、前述の単純な検索との違いは、検索時に文字列が「トークン化」されることです。 例えば、大文字と小文字が区別されなかったり、スペースで空けた複数の文字列は順序が区別されません。以下の2つのクエリは同じ結果を返します。 SEARCH( " hello world " ) SEARCH( " World hello " ) 大文字と小文字や、文字列の順序を区別させたい場合は、文字列をバッククォートで囲みます。以下の2つのクエリは、返ってくる結果が異なります。 SEARCH( " `hello world` " ) SEARCH( " `world hello` " ) SEARCH() 関数では、部分的なテキストは区別されてしまいます。以下のクエリでは、world という単語が途中で切れているので、 hello world という文字列は抽出されません。 SEARCH( " `hello wor` " ) なお、以下の1つ目のクエリのように文字列をダブルクォーテーションで囲わずに検索ボックスに入力してそのまま検索すると、 SEARCH() 関数を使った検索になります。以下の2つのクエリは同じ意味です。 password authentication failed SEARCH( " password authentication failed " ) 時間の指定 ログエクスプローラでの指定 ログエクスプローラでは、ログの検索対象とする時間を指定できます。 できるだけ検索対象の時間帯を絞ることで、クエリの結果が返ってくるまでのスピードを向上させることができます。 ログエクスプローラで時間帯を指定 クエリ言語での指定 クエリ内で時間帯を指定することもできます。Cloud Logging のログエントリには以下のように timestamp フィールドが必ず含まれていますので、このフィールドを使ってログを絞り込みます。 timestamp >= " 2025-02-24T09:40:00+09:00 " AND timestamp <= " 2025-02-24T09:50:00+09:00 " タイムスタンプの末尾を +09:00 とすれば日本のタイムゾーンになります。末尾を Z とすれば UTC です。 コメント -- で始まる行はコメントであり、無視されます。 -- このクエリは、Compute Engine VM に対するすべてのメソッドの実行を抽出します protoPayload.methodName=~ " ^v1\.compute\.instances\..+ " 高速な検索 インデックスの利用 Cloud Logging のログエントリには、 インデックス が存在します。インデックスは、物理的な書籍でいう索引や、ページに貼られた付箋のようなものと理解することができます。フィールドにインデックスが作成されることによって、そのフィールドに対する検索が高速化します。 参考 : ログエントリの迅速な検索 参考 : カスタム インデックスを構成する ログバケットに対して、ユーザーが任意のフィールドにカスタムインデックスを指定することもできるほか、すべてのログバケットで、 デフォルトで 以下のフィールドにインデックスが作成されています。 resource.type resource.labels.* logName severity timestamp insertId operation.id trace httpRequest.status labels.* split.uid これらのフィールドに対して検索をかけると、高速な検索が可能です。 例えば、検索したいログの対象となっているインスタンス ID が分かっている場合は、ID を指定することで検索が高速になります。 resource.labels.* にはデフォルトのインデックスが作成されているからです。 protoPayload.methodName= " v1.compute.instances.stop " AND resource .labels.instance_id= " 1234567890123456789 " また、 logName フィールドは、ログエントリに必ず含まれており、デフォルトのインデックスが作成されていますので、検索対象のログを絞る際に有用です。 protoPayload.serviceName= " cloudsql.googleapis.com " AND logName= " projects/sugimura/logs/cloudaudit.googleapis.com%2Factivity " logName フィールドの値の例は、以下のとおりです。 ログの種類 値 説明 Cloud Audit Logs 管理アクティビティ監査ログ projects/(PROJECT_ID)/logs/cloudaudit.googleapis.com%2Factivity リソースに対する更新系操作 Cloud Audit Logs データアクセス監査ログ projects/(PROJECT_ID)/logs/cloudaudit.googleapis.com%2Fdata_access データに対する更新系・読取系操作 Cloud Audit Logs ポリシー拒否監査ログ projects/(PROJECT_ID)/logs/cloudaudit.googleapis.com%2Fpolicy VPC Service Controls のアクセス拒否 Cloud SQL for PostgreSQL データベースログ (postgres.log) projects/(PROJECT_ID)/logs/cloudsql.googleapis.com%2Fpostgres.log Cloud SQL for PostgreSQL のログ Cloud Run 標準出力 (postgres.log) projects/(PROJECT_ID)/logs/run.googleapis.com%2Fstdout Cloud Run や Cloud Run functions の標準出力 時間帯を絞る ログ検索対象の時間帯を可能な限り絞ることで、検索時間を速くすることができます。 ログエクスプローラ画面の UI を使って時間帯を絞ってもいいですし、クエリ文の中で timestamp フィールドを使って時間帯を絞っても構いません。 部分一致よりもイコール 検索対象の文字列が分かっている場合は、グローバル制限（グローバル検索）よりも : （has）のほうが、またそれよりも =~ （正規表現）の方が高速です。しかし、最も高速なのは = （イコール）です。 -- グローバル検索だとすべてのフィールドが検索対象になる " password authentication failed " -- こちらのほうが高速 textPayload : " password authentication failed for user \ " postgres\ "" -- さらに高速 textPayload =~ " .* password authentication failed for user \ " postgres\ " .* " -- 最も高速 textPayload= " 2025-02-24 00:27:33.651 UTC [12345]: [1-1] db=postgres,user=postgres FATAL: password authentication failed for user \ " postgres\ "" また、フィールドを指定した検索では SEARCH() 関数も有用です。正規表現を用いなくても、検索文字列がトークン化されて効率的な検索が可能です。ただし、単語が途中で切れていたりすると、望む結果が得られないことに注意してください（前述の「SEARCH 関数」の見出しを参照）。 SEARCH(textPayload, " password authentication failed " ) 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen のバロキです。この記事では Vertex AI を使って、Anthropic 社の Claude モデル を呼び出す方法と、セットアップから最初の推論（inference）までのステップについて解説します。 はじめに Claude とは Vertex AI 上で Claude を使うメリット 利用可能な Claude モデル一覧 事前準備 Notebook インスタンスの作成 Claude のストリーミング応答を利用する curl での呼び出し例 次のステップ はじめに Claude とは Claude は、Anthropic 社によって開発された大規模言語モデル（LLM）のファミリーです。Constitutional AI という設計原則に基づき、「有用で・無害で・正直である」ことを目指して作られました。 Claude 3 系列の中でも最新の Claude 3.7 Sonnet は、ハイブリッド・リースニング（Hybrid Reasoning）を備えており、即時的な応答と段階的な深い思考のバランスを取ることが可能です。 Claude は以下のようなタスクに活用できます。 テキストの要約 コード生成やデバッグ マルチモーダルな画像処理 チャットボットやリアルタイム会話 深い分析や推論の自動化 Vertex AI 上で Claude を使うメリット Google Cloud の Vertex AI は、Claude モデルをネイティブに提供しています。Claude を Vertex AI から呼び出すことには、以下のようなメリットがあります。 サーバーレス であること。インフラの管理が不要です。 API 経由の簡単な呼び出し が可能であること。API へリクエストを送るだけで利用できます。 ストリーミング対応 していること。応答をリアルタイムに表示できます。 従量課金またはスループット指定 が可能であること。用途に応じた柔軟な価格設定が可能です。 このように、Vertex AI を使うと、研究者や開発者が簡単に Claude を使い始められます。 利用可能な Claude モデル一覧 以下は、2025年5月現在、Vertex AI から呼び出し可能な Claude モデルの一覧です。 モデル名                 モデル ID                          特徴                     Claude 3.7 Sonnet    claude-3-7-sonnet@20250219     高度な推論、エージェント的タスクに最適です。     Claude 3.5 Sonnet v2 claude-3-5-sonnet-v2@20241022 複雑なドキュメント理解やコーディングに適しています。     Claude 3.5 Haiku     claude-3-5-haiku@20241022     最速の応答性能を持ち、チャット用途に向いています。       Claude 3 Opus        claude-3-opus@20240229         高度な研究用途や複雑なタスクに適しています。         Claude 3 Haiku       claude-3-haiku@20240307       画像を含むマルチモーダル処理に対応しています。         Claude 3.5 Sonnet    claude-3-5-sonnet@20240620     高性能なコーディング支援とカスタマーサポートに役立ちます。 参考 : Use Anthropic's Claude models 事前準備 Claude を Vertex AI から使うためには、以下の準備が必要です。 課金が有効な Google Cloud プロジェクト aiplatform.googleapis.com API の有効化 パートナーモデル（Claude）の使用権限 Python、Jupyter Notebook の基本的な知識 以下のコマンドで SDK をインストール pip install --upgrade anthropic google-cloud-aiplatform Notebook インスタンスの作成 Vertex AI Workbench にアクセスし、「インスタンスを作成」をクリックします。 「Python 3（最新） + JupyterLab」を選択します。 インスタンスタイプ（例 : e2-standard-4）を選びます。 Notebook 上で以下のコードを実行します。 from anthropic import AnthropicVertex client = AnthropicVertex(project_id= "your-project-id" , region= "us-east5" ) message = client.messages.create( model= "claude-3-7-sonnet@20250219" , max_tokens= 1024 , messages=[ { "role" : "user" , "content" : "Explain the concept of extended thinking." } ], ) print (message.model_dump_json(indent= 2 )) Claude のストリーミング応答を利用する ストリーミング応答を利用することで、より自然で即時的な体験が可能です。 with client.messages.stream( model= "claude-3-7-sonnet@20250219" , max_tokens= 1024 , messages=[ { "role" : "user" , "content" : "Tell me a story about a dragon and a forest." } ], ) as stream: for text in stream.text_stream: print (text, end= "" , flush= True ) curl での呼び出し例 gcloud コマンドで取得したアクセストークンを使い、curl で直接呼び出すことも可能です。 curl -X POST \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " Content-Type: application/json " \ https://us-east5-aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/us-east5/publishers/anthropic/models/claude-3-7-sonnet@20250219:streamGenerateContent \ -d ' { "instances": [{"messages": [{"role": "user", "content": "Vertex AI を使って何ができますか？"}]}], "parameters": {"maxTokens": 512, "stream": true} } ' 次のステップ Claude は Vertex AI を通じて、インフラ管理の必要がなく、安全かつスケーラブルに利用できます。 さらなる詳細は、以下のドキュメントを参考にしてください。 参考 : Claude on Vertex AI（公式ドキュメント） 参考 : Anthropic API ドキュメント 参考 : Claude 3.7 Sonnet 紹介ページ ハサナル・バロキ (記事一覧) クラウドソリューション部 クラウドサポート課。インドネシア北スマトラ州ビンジャイ市出身。 YKK株式会社での金型設計を経て IT 業界へ転身。AI／システムエンジニアとしての経験を積み、現在は G-gen にてクラウドサポートに従事。 趣味は水泳と RAG チャットボット開発（OpenAI・Gemini・Vector Search 等）。好きな食べ物はラーメンと寿司。

G-gen の杉村です。BigQuery では、Cloud Storage 上の CSV 形式や JSON 形式のファイルをテーブルに読み込ん（ロード）だり、外部テーブル定義によって直接クエリすることができます。日付を含むファイルをロードしたりクエリしようとした際に発生したエラーについて、対処法を解説します。 前提 事象 1. LOAD の際のエラー 2. 外部テーブルへのクエリの際のエラー 原因 対処法 1. date_format オプションを指定する 2. STRING 型として取り込む 3. スキーマの自動検知を利用する 4. 取り込む前にファイルを前処理する 前提 Cloud Storage バケットに以下の CSV を配置し、BigQuery から LOAD ステートメントを実行して、テーブルに取り込もうとしました。 2025/06/07,2025/06/07 08:30:00,2025/06/07 17:30:00,helloWorld1 2025/06/08,2025/06/08 09:00:00,2025/06/08 17:30:00,helloWorld2 2025/06/09,2025/06/09 10:00:30,2025/06/09 19:00:30,helloWorld3 なおテーブルのスキーマは CSV のフィールドどおりの順番で、以下を想定しています。 列名 型 col_date DATE col_datatime DATETIME col_timestamp TIMESTAMP col_string STRING また別の用途のため、上記のテーブルとは別に、同じファイルに対して外部テーブル定義をして、直接ファイルをクエリできるようにしたいと考えています。 事象 1. LOAD の際のエラー Cloud Storage バケット上の CSV ファイルを BigQuery テーブルに取り込むため、以下の LOAD 文を実行しました。 LOAD DATA INTO `my-project.my_dataset.sample_table` ( col_date DATE , col_datetime DATETIME , col_timestamp TIMESTAMP , col_string STRING ) FROM FILES ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); すると、以下のエラーが発生しました。 Error while reading data, error message: Unable to parse; line_number: 1 byte_offset_to_start_of_line: 0 column_index: 0 column_name: "col_date" column_type: DATE value: "2025/06/07" File: gs://my-bucket/datetime_test/test_dateformat.csv Error while reading data, error message: Unable to parse; 2. 外部テーブルへのクエリの際のエラー 次に、CREATE EXTERNAL TABLE 文で同じファイルに対して外部テーブル定義を試みました。 CREATE OR REPLACE EXTERNAL TABLE `my-project.my_dataset.sample_external_table` ( col_date DATE , col_datetime DATETIME , col_timestamp TIMESTAMP , col_string STRING ) OPTIONS ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); 外部テーブル作成は成功しましたが、この外部テーブルに SELECT 文を実行した際に以下のエラーメッセージが表示されました。 Error while reading table: my-project.my_dataset.sample_external_table, error message: Unable to parse; line_number: 1 byte_offset_to_start_of_line: 0 column_index: 0 column_name: "col_date" column_type: DATE value: "2025/06/07" File: gs://my-bucket/datetime_test/test_dateformat.csv Error while reading table: 〜 error message: Unable to parse; 原因 BigQuery の DATE 型や DATETIME 型、TIMESTAMP 型では、文字列をキャストする際に、日付部分が YYYY-mm-dd というハイフン区切りの形式であれば自動的に日付として認識されます。 今回は、CSV ファイル内の文字列の日付部分が、「2025/06/07」とスラッシュ区切りのため上記の形式に一致しておらず、LOAD に失敗したり、外部テーブルとしてのクエリが失敗しました。 対処法 1. date_format オプションを指定する LOAD や CREATE TABLE 文において、 date_format オプション、 datetime_format オプションを使うことで、日付にパースする文字列のフォーマットを指定することができます。 参考 : Load statements in GoogleSQL 以下は、その例です。 LOAD DATA INTO `my-project.my_dataset.sample_table` ( col_date DATE , col_datetime DATETIME , col_timestamp TIMESTAMP , col_string STRING ) FROM FILES ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ], time_zone = " Asia/Tokyo " , date_format = ' YYYY/MM/DD ' , datetime_format = ' YYYY/MM/DD HH24:MI:SS ' ); なお上記の例では、 time_zone オプションでタイムゾーンを指定することで、タイムゾーンを意識する TIMESTAMP 型の列に、任意のタイムゾーンで値を格納しています。 クエリ SELECT * FROM `my-project.my_dataset.sample_table`; クエリの結果 col_date col_datetime col_timestamp col_string 2025-06-07 2025-06-07T08:30:00 2025-06-07 08:30:00 UTC helloWorld1 2025-06-08 2025-06-08T09:00:00 2025-06-08 08:30:00 UTC helloWorld2 2025-06-09 2025-06-09T10:00:30 2025-06-09 10:00:30 UTC helloWorld3 上記の結果では、 2025/06/07 17:30:00 という日本時間の時刻を格納した文字列が、col_timestamp 列に 2025-06-07 08:30:00 UTC として正しく格納されていることがわかります。 また、CREATE EXTERNAL TABLE でも、同じように date_format オプション、 datetime_format オプションが使えます。 time_zone オプションも解釈され、外部テーブルへのクエリ時に正しくタイムゾーンが設定されます。 参考 : Data definition language (DDL) statements in GoogleSQL - CREATE EXTERNAL TABLE statement CREATE OR REPLACE EXTERNAL TABLE `my-project.my_dataset.sample_external_table` ( col_date DATE , col_datetime DATETIME , col_timestamp TIMESTAMP , col_string STRING ) OPTIONS ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ], time_zone = " Asia/Tokyo " , date_format = ' YYYY/MM/DD ' , datetime_format = ' YYYY/MM/DD HH24:MI:SS ' ); 他に、時刻のフォーマットを指定する time_format オプションや、タイムスタンプのフォーマットを指定する timestamp_format オプションもあります。 2. STRING 型として取り込む CSV の文字列を、いったん STRING 型の文字列として取り込み、後から ELT（データ変換）やビューで任意の型に変換することができます。 LOAD DATA INTO `my-project.my_dataset.sample_table` ( col_date STRING, col_datetime STRING, col_timestamp STRING, col_string STRING ) FROM FILES ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); また、外部テーブルの場合は以下のようになります。 CREATE OR REPLACE EXTERNAL TABLE `my-project.my_dataset.sample_external_table` ( col_date STRING, col_datetime STRING, col_timestamp STRING, col_string STRING ) OPTIONS ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); このようにしてできたテーブルや外部テーブルに対して、以下のように PARSE_* 関数を使ってクエリすることで、文字列を日付型等に変換することができます。 SELECT PARSE_DATE( " %Y/%m/%d " , col_date) AS col_date, PARSE_DATETIME( " %Y/%m/%d %H:%M:%S " , col_datetime) AS col_datetime, PARSE_TIMESTAMP( " %Y/%m/%d %H:%M:%S " , col_timestamp, " Asia/Tokyo " ) AS col_timestamp, col_string, FROM `my-project.my_dataset.sample_table` 参考 : Date functions 参考 : Datetime functions 参考 : Timestamp functions 3. スキーマの自動検知を利用する 以下のようにスキーマ（列名、型）を指定せずに LOAD すると、スキーマが自動判断されてロードされます。スラッシュ区切りの日付文字列も、DATE 型等として判断されます。 LOAD DATA INTO `my-project.my_dataset.sample_table_auto` FROM FILES ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); 外部テーブル定義の場合は、以下のようになります。 CREATE OR REPLACE EXTERNAL TABLE `my-project.my_dataset.sample_external_table` OPTIONS ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); この方法だと、列名や型を指定することができません。上記の方法で作成されたテーブルや外部テーブルを SELECT すると、いずれも以下のような結果となりました。 date_field_0 timestamp_field_1 timestamp_field_2 string_field_3 2025-06-07 2025-06-07 08:30:00 UTC 2025-06-07 17:30:00 UTC helloWorld1 2025-06-08 2025-06-08 09:00:00 UTC 2025-06-08 17:30:00 UTC helloWorld2 2025-06-09 2025-06-09 10:00:30 UTC 2025-06-09 19:00:30 UTC helloWorld3 CSV の2列目と3列目のフィールドはいずれも TIMESTAMP 型として解釈され、タイムゾーンは UTC として解釈されました。 この方法では任意の列名や型を指定できない点に留意が必要です。 4. 取り込む前にファイルを前処理する 上記の方法のほか、BigQuery からファイルを読み込む前の前処理として、ファイル自体を加工する（ELT ではなく ETL）という方法も検討できます。 この場合は BigQuery の機能だけでは取り込みを完結できません。ファイルの前処理のためのアーキテクチャを検討する必要があります。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの福井です。BigQuery Data Transfer Service のイベントドリブン機能の設定手順を紹介します。 イベントドリブン転送の概要 BigQuery Data Transfer Service とは ユースケース アーキテクチャ 制限事項 料金 事前準備 API の有効化 サービスアカウントの作成とロールを付与 設定手順 データの格納先をCloud Storageに作成 データの転送先をBigQueryに作成 BigQuery Data Transfer Serviceで転送構成を作成 動作確認 イベントドリブン転送の概要 BigQuery Data Transfer Service とは BigQuery Data Transfer Service は、Google Cloud 内外のデータソースから BigQuery へのデータロードを自動化する、フルマネージドなサービスです。これまでも、決まったスケジュールで定期的にデータ転送を実行する機能が提供されていました。 2025年6月、BigQuery Data Transfer Service で新しく イベントドリブン転送 （Event-Driven Transfers）がサポートされたことで、Cloud Storage にファイルが配置されたことをトリガーに、 BigQuery へデータを転送できます。 当記事では、このイベントドリブン転送の概要から、実際のコンソール画面を用いた具体的な設定手順、そして動作確認までをステップバイステップで解説します。 参考 : BigQuery Data Transfer Service とは 参考 : イベント ドリブン転送 ユースケース イベントドリブン転送は、データが発生してから分析に利用できるまでのリードタイムを短縮したい場合に特に有効です。具体的なユースケースとしては、以下のようなシナリオが挙げられます。 ユースケース 概要 アプリケーションログの分析 Web サーバーなどから出力されるログファイルを Cloud Storage に集約し、障害検知や利用状況の分析のために BigQuery へ取り込む。 外部システムとのデータ連携 パートナー企業や SaaS からファイル形式で提供される販売データや顧客データを、Cloud Storage に配置されたタイミングで速やかに取り込む。 アーキテクチャ イベントドリブン転送は、Cloud Storage、Pub/Sub、そして BigQuery Data Transfer Service の3つのサービスを連携させて実現します。 全体の処理の流れは以下の通りです。 ユーザーまたはアプリケーションが、監視対象の Cloud Storage バケット にファイルをアップロードします。 ファイルの作成イベントを検知した Cloud Storage は、あらかじめ設定された Pub/Sub トピック に通知メッセージを送信します。 BigQuery Data Transfer Service は、その Pub/Sub トピックを購読 (Subscribe) しており、メッセージを受け取ります。 メッセージをトリガーとして、Data Transfer Service の転送ジョブが実行され、指定されたファイルを BigQuery のテーブル にロードします。 制限事項 イベントドリブン転送を使用するには、いくつかの制限事項があります。 制限事項 詳細 同一サブスクリプションの再利用不可 同じ Pub/Sub サブスクリプションを、複数のイベントドリブン転送構成で再利用することはできません。 ランタイムパラメータの非対応 転送元となる Cloud Storage のURI（データパス）に、実行時の動的なパラメータを埋め込むことはサポートされていません。 参考: ランタイム パラメータ イベントの待機時間 一度転送がトリガーされると、BigQuery Data Transfer Serviceは次のトリガーまで最大10分間待機することがあります。 参考 : イベント ドリブン転送 - 制限事項 料金 イベントドリブン転送の使用にあたり、BigQuery Data Transfer Service 自体には追加の料金はかかりません。ただし、連携する以下の各サービスにおいて、それぞれの利用量に応じた料金が発生します。 サービス 課金対象 備考 BigQuery Data Transfer Service - サービス自体の利用は無料です。 Cloud Storage ・ストレージ料金 ・オペレーション料金 ファイルの保管と読み書きに対して発生します。 参考: Cloud Storage の料金 Pub/Sub ・メッセージング料金 Cloud Storageからの通知メッセージ量に応じて発生します。 毎月最初の10GBまでは無料枠が適用されます。 参考: Pub/Sub の料金 BigQuery ・ストレージ料金 ・分析料金 ロードされたデータの保管と、そのデータに対するクエリ実行時に発生します。 参考: BigQuery の料金 事前準備 API の有効化 はじめに、以下の API を Google Cloud プロジェクトで有効化します。 サービス名 API 名 Pub/Sub pubsub.googleapis.com BigQuery bigquery.googleapis.com BigQuery Data Transfer Service bigquerydatatransfer.googleapis.com 　 Google Cloud コンソールの API とサービスの画面で、[+ API とサービスを有効にする] を選択します。 API とサービスを有効にするを選択 API とサービスを検索に pubsub.googleapis.com を入力し、検索します。 API 名で検索 検索結果が複数表示されるため、以下を選択します。 pubsub.googleapis.com の場合 pubsub.googleapis.com の選択 bigquery.googleapis.com の場合 bigquery.googleapis.com の選択 bigquerydatatransfer.googleapis.com の場合 bigquerydatatransfer.googleapis.com の選択 [有効にする] を選択します。 API を有効にするを選択 サービスアカウントの作成とロールを付与 BigQuery Data Transfer Service を実行するためのサービス アカウントを作成します。 Google Cloud コンソールの IAM と管理の画面で、[サービス アカウント] > [サービス アカウントを作成] を選択します。 サービス アカウントを作成を選択 サービス アカウント名に sv-event-driven-bq-data-transfer を入力し、[作成して続行] を選択します。 サービス アカウント名を入力すると、サービス アカウントIDは自動で設定されます。 サービス アカウントの作成 ロールに Storage オブジェクト閲覧者 （roles/storage.objectViewer）を入力し、[続行] を選択します。 サービス アカウントに権限付与 [完了] を選択します。 サービス アカウントの設定完了 設定手順 データの格納先をCloud Storageに作成 Google Cloud コンソールの Cloud Storage 画面で、[バケット] > [作成] を選択します。 バケットを作成を選択 バケット名に g-gen-blog-event_driven_bq_data_transfer 、ロケーション タイプに Region と asia-northeast1 (東京) を入力し、[作成] を選択します。 バケット名は、世界中で重複しない名前にする必要がありますので、ご自身の環境に合わせて適宜変更してください。 バケットの作成 データの転送先をBigQueryに作成 Cloud Storage から転送されたデータを格納するための、BigQuery のデータセットとテーブルを作成します。 今回は、以下のような簡単なスキーマを持つテーブルを例として作成します。 カラム名 データ型 name STRING value INTEGER 　 データセットの作成 Google Cloud コンソールの BigQuery 画面で、[スタジオ] > [エクスプローラ] のプロジェクト ID 横の [⋮] > [データセットを作成] を選択します。 データセットを作成を選択 データセット ID に event_driven_bq_data_transfer 、ロケーション タイプに リージョン と asia-northeast1 (東京) を入力し、[データセットを作成] を選択します。 データセットを作成 テーブルの作成 作成したデータセットの横にある [⋮] から [テーブルを作成] を選択します。 テーブルを作成を選択 テーブルに from_gcs 、スキーマの [フィールドを追加] リンクを選択し、以下の項目を追加します。追加が完了した後に [テーブルを作成] を選択します。 フィールド名 種類 name STRING value INTEGER テーブルを作成 BigQuery Data Transfer Serviceで転送構成を作成 Google Cloud コンソールの BigQuery 画面で、[データ転送] > [転送を作成] を選択します。 転送を作成を選択 ソースに Google Cloud Storage 、 表示名に event-driven-from-gcs 、スケジュール オプションの繰り返しの頻度に イベント ドリブン 、Pub/Sub サブスクリプションから [サブスクリプションの作成] を選択します。 転送の作成情報を入力（1/3） サブスクリプションを作成画面の [作成] ボタンを選択します。 サブスクリプションを作成 データセットに event_driven_bq_data_transfer 、Destination table に from_gcs 、Cloud Storage URI の [バケットの選択] を選択します。 転送の作成情報を入力（2/3） 前の手順で作成したバケット g-gen-blog-event_driven_bq_data_transfer を選択し、ファイル名に sample-file-*.csv を入力し、[選択] を選択します。 ここで指定したファイル名に一致したファイルが、データ転送の対象となります。 Cloud Storage URI の選択 サービス アカウントに前の手順で作成したサービスアカウント sv-event-driven-bq-data-transf@⋯ を選択し、 [保存] を選択します。 取り込み対象ファイルのフォーマット（File format）やファイル内の区切り文字（Field delimiter）など、取り込み対象のデータ形式に合わせて設定値は適宜変更してください。 転送の作成情報を入力（3/3） 動作確認 全ての設定が完了したので、実際にファイルをアップロードして、データが自動的に BigQuery へ転送されることを確認します。 サンプルCSVファイルの作成 ローカルのPCに、 sample-file-1.csv という名前で以下の内容のファイルを作成します。 BigQuery Data Transfer Service の転送作成時に、 Header rows to skip の値を 0 に設定したため、ヘッダー行は設けません。 "name-1",1 "name-2",2 "name-3",3 CSVファイルを Cloud Storage へアップロード 作成した sample-file-1.csv を、Cloud Storage バケットにアップロードします。 CSV ファイルを Cloud Storage へアップロード BigQueryでのデータ確認 ファイルがアップロードされると、イベントがトリガーされ、最大 10 分間待機した後に転送が実行されます。 今回の確認では、Cloud Storage にファイルが作成された時間（ 8:56:42 ）から転送が開始（ 9:01:44 ）されるまでに、約5分かかっています。 転送の実行履歴 BigQuery 内の登録データ 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進

G-gen の中川です。本記事では、Google Workspace ユーザーが他のドメインの Google Workspace グループアドレスを送信元としてメールを送信するための、設定手順を解説します。 はじめに 事前準備 Google グループの作成 別組織のユーザーの Google アカウントの設定 別組織のユーザーの Gmail の設定 グループメンバーによる確認 メール送信時の差出人設定 はじめに 別組織のユーザーが Google Workspace グループアドレスを送信元としてメールを送信したいという要件があります。例えば、外部の協力会社のユーザーが、自分たちのドメインとは異なるドメインの Google Workspace グループのメールアドレスを送信元としてメールを送りたいというケースがあります。 本記事では、そのような要件を実現するための手順と注意点について解説します。 なお、同じ組織のユーザーでグループアドレスを送信元として追加する方法は、以下の記事を参照してください。 blog.g-gen.co.jp また当記事の情報は、2025年5月時点における当社の検証に基づくものであり、公式ドキュメントには記載されておりませんため、仕様が変更になる可能性がある点にはご留意ください。 事前準備 当記事では、メインの Google Workspace ドメインを @example.co.jp 、別組織側のドメインを @different-domain.com として解説します。 なお、当記事では両ドメインとも Google Workspace のメールアドレスで検証を行いますが、当記事の手順により、個人向けの Google アカウント ( @gmail.com ) でも Google Workspace グループアドレスを送信元として追加できます。 まず、別組織 ( @different-domain.com ) の Google Workspace の管理コンソールで、以下の設定が有効になっている必要があります。 2 段階認証プロセス メールドメインの外部でホストされている「送信元」アドレスを設定した場合に、ユーザーに外部の SMTP サーバーを経由したメールの送信を許可 詳細は以下の公式ドキュメントを参照してください。 参考 : 2 段階認証プロセスを導入する 参考 : ユーザーごとの送信ゲートウェイの許可 Google グループの作成 送信元としたい Google グループ ( group@example.co.jp ) を作成します。 具体的な方法は上記で紹介した以下の記事の「設定1 : Google グループ作成」をご参照ください。 参考 : Google Workspace で問い合わせ対応システムを作成する方法 #2 (Google グループ設定) - G-gen Tech Blog - 設定1 : Google グループ作成 既にグループを作成済みの場合は、アクセスタイプの「投稿できるユーザー」が「外部」になっているかを確認します。 別組織のユーザーの Google アカウントの設定 送信を行う別組織のユーザー ( user@different-domain.com ) の Google アカウントの設定をします。 2 段階認証プロセス が有効になっていない場合は 2 段階認証プロセスを設定します。アプリ パスワードの作成には、2 段階認証が有効になっている必要があります。 参考 : 2 段階認証プロセスを有効にする 次に アプリ パスワード を作成します。 任意の名前を「アプリ名」(送信用グループアドレス)に入力し「作成」をクリックします。 生成されたアプリ パスワードを控えてください。このパスワードは、Gmail の SMTP 設定で使用します。 参考 : アプリ パスワードでログインする 別組織のユーザーの Gmail の設定 別組織のユーザー ( user@different-domain.com ) の Gmail にアクセスします。 右上の歯車アイコンをクリックし、「すべての設定を表示」を選択します。 上部のタブから「アカウント」または「アカウントとインポート」を選択します。次に、「他のメールアドレスを追加」をクリックします。 表示されたウィンドウに、以下の情報を入力します。 設定項目 設定値 名前 任意のグループ名 (送信用グループアドレス) メール グループアドレス ( group@example.com ) エイリアスとして扱います。 有効 「次のステップ」をクリックします。 「SMTP サーバー経由で送信」を選択し、以下の情報を入力します。 設定項目 設定値 SMTP サーバー smtp.gmail.com ユーザー名 別組織のユーザーのメールアドレス ( user@different-domain.com ) パスワード 作成したアプリ パスワード ポート 587 TLS を使用したセキュリティで保護された接続（推奨） 選択 「アカウントを追加」をクリックします。 グループメンバーによる確認 グループのメンバー宛に確認メールが送信されます。 グループのメンバーは、受信した確認メール内のリンクをクリックしてリクエストを承認します。 確認メールが見当たらない場合は、Google グループの「スレッド」をご確認ください。 メール送信時の差出人設定 上記の手順が完了すると、Gmail でメールを作成する際に、「差出人」の項目で追加したグループのメールアドレスを選択できます。これにより、受信者にはグループアドレスからのメールとして表示されます。 中川 涼介 (記事一覧) クラウドソリューション部 クラウドサポート課 2024年11月、G-genに入社。Google Cloudを日々勉強中。 最近は怪談の動画にハマってます。

G-genの杉村です。Google の AI を活用したリサーチ・ライティングアシスタントである NotebookLM の各エディション（無償版、Pro 版、Enterprise 版）の違いについて詳しく解説します。 NotebookLM とは NotebookLM のエディション エディションの比較 どのエディションを選ぶべきか 選択の基準 機能差 セキュリティと統制 コスト その他の注意点 新機能の展開 ノートブックの共有可否 アクセス URL NotebookLM とは NotebookLM は、ユーザーがアップロードしたドキュメントやデータ（ソース）に基づいて、AI が質問応答、要約、アイデア生成などを行うリサーチ・ライティングアシスタントです。従来の検索エンジンや Gemini アプリとは異なり、NotebookLM はユーザーが提供した情報源のみに基づいて回答を生成するため、情報の信頼性をコントロールしやすい点が特徴です。 NotebookLM には無償版、Pro 版、Enterprise 版の3エディションがあります。当記事ではそれらの違いを解説します。 参考 : https://notebooklm.google.com/ 参考 : NotebookLM の詳細 - NotebookLM ヘルプ 参考 : NotebookLM Plusを使ってみた - G-gen Tech Blog NotebookLM NotebookLM のエディション NotebookLM には、2024年6月現在、以下の3つのエディションがあります。 名称 説明 NotebookLM（無償版） 基本的な機能を無料で使える個人ユーザー向けエディション。Google アカウント（Gmail アカウント）を作成すれば利用できる。 NotebookLM in Pro 利用上限が緩和された有償エディション。Google Workspace に付帯。個人でも Google AI Pro サブスクリプションを購入することで利用可能。旧称 NotebookLM Plus NotebookLM Enterprise 企業向けにセキュリティ、管理機能、サポートを強化した有償エディション。Google Cloud 上で提供される。 これらのエディションは、利用できる機能、扱えるデータ量、料金、セキュリティ機能などに違いがあります。以下で各エディションの詳細と比較を解説します。 なお、NotebookLM in Pro は以前（2025年5月頃）まで NotebookLM Plus と呼ばれていました。個人向けサブスクリプションのプラン名が Google AI Pro に変更されたのに伴い、NotebookLM Plus は NotebookLM in Pro へと改名 されました。 エディションの比較 各エディションの主な違いを以下にまとめます。以下の表は、2025年6月現在の英語版公式ドキュメントの情報に基づいています。 参考 : Learn about Pro capabilities in NotebookLM 参考 : Upgrade NotebookLM to the Pro plan 参考 : NotebookLM Enterprise とは 比較観点 NotebookLM (無償版) NotebookLM in Pro NotebookLM Enterprise 料金 無料 Google Workspace のほとんどのエディションに付帯。 もしくは個人向けサブスクリプションである Google AI Pro に付帯 1ユーザーあたりの月額有償ライセンス (年間コミットあり) 主な対象ユーザー 個人 ・企業や組織 ・制限なしで NotebookLM を使いたい個人 企業や組織 最大ノートブック数 100 個 500 個 500 個 ノートブックあたりソース数 50 個 / ユーザー 300 個 / ユーザー 300 個 / ユーザー 処理回数制限 チャットクエリ : 50回 音声概要生成 : 3回 チャットクエリ : 500回 音声概要生成 : 20回 チャットクエリ : 500回 音声概要生成 : 20回 サポートするファイル形式 Web サイト、PDF、テキストファイル、Markdown、Google ドキュメント、Google スライド、YouTube、音声ファイル、画像ファイル、Microsoft Word ファイル (docx) 等 無償版と同様 無償版と同じファイル形式に加えて Microsoft PowerPoint (pptx)、Excel ファイル (xlsx) データ保護 モデルのトレーニングには使用されない。フィードバックを提供することを選択した場合、人間の審査担当者が内容を確認し、サービス改善に利用する場合がある。 どのような場合でもモデルのトレーニングには使用されない。人間のレビュワーにも閲覧されない。 どのような場合でもモデルのトレーニングには使用されない。人間のレビュワーにも閲覧されない。顧客データは顧客 Google Cloud プロジェクト内で管理される。 アクセス管理 個人アカウント Google Workspace アカウント (Google AI Pro サブスクリプションの場合個人アカウント) Google Workspace アカウントもしくは Entra ID など外部 IdP アカウント セキュリティ 標準的なアクセス制御 Google Workspace 管理画面で組織部門ごとに利用許可・禁止 ・IAM によるアクセス制御 ・VPC Service Controls によるきめ細かいアクセス制御 ノートブックの共有 個人 Google アカウントまたはインターネット全体に共有可能 同じ組織の Google アカウントまたはグループに共有可能（個人アカウントで Google AI Pro サブスクリプションを契約している場合は、個人 Google アカウントに対してのみ共有可能。またインターネット全体に共有可能） 同じ Google Cloud プロジェクトの NotebookLM Enterprise ユーザーにのみ共有可能 新機能の展開 最速 次点 最後 どのエディションを選ぶべきか 選択の基準 上の表で見たように、各エディションで利用回数やノートブック数、データソース数の上限や、セキュリティ機能、共有可能な範囲に違いがあります。 概ねの判断として、 個人ユーザー であれば NotebookLM（無償版）または NotebookLM in Pro（Google AI Pro サブスクリプション経由で購入）を選び、 企業等のユーザー であれば、統制が効く NotebookLM in Pro または NotebookLM Enterprise を選択します。 企業等の組織が、NotebookLM in Pro と NotebookLM Enterprise のどちらかを選ぶかについては、実施したい 機能差 、 セキュリティと統制の度合い 、 コスト などを考えます。 機能差 重要な点として、NotebookLM に新機能が展開される場合、まずは無償版（コンシューマー版）、次に in Pro 版（Google Workspace 版）、最後に Enterprise 版と展開されるため、 NotebookLM Enterprise では最新機能が使えないケース もある点に留意してください。 詳細は後述の「新機能の展開」の項を参照してください。 ただし、NotebookLM Enterprise では、無償版では読み取り不可能な Microsoft PowerPoint ファイルや Excel ファイルの読み取りが可能であるなど、一部の機能差異も存在します。 セキュリティと統制 無償版の NotebookLM は、 エンタープライズグレードのデータ保護 が適用されず、また管理者による統制機能が存在しないため、企業での利用には不適切です。 NotebookLM in Pro（Google Workspace 版）はエンタープライズグレードのデータ保護が適用される他、管理者による一部の挙動制御が可能です。 参考 : ユーザーに対して NotebookLM を有効または無効にする - NotebookLM の機能とアクセス権（Workspace エディション別） NotebookLM Enterprise は Google Cloud と統合されていることで最も統制機能が充実しており、IAM による詳細なアクセス制御や、VPC Service Controls を用いた IP アドレスベースの制御など、追加の統制機能が提供されています。 参考 : NotebookLM Enterprise とは コスト NotebookLM in Pro はほとんどすべての Google Workspace エディションに追加コストなしで付帯しているため、安価に NotebookLM の機能を使用したい場合に選択肢となります。 参考 : Google Workspace Business エディションの AI 機能と料金改定 一方の NotebookLM Enterprise は、 Gemini Enterprise （横断検索および AI エージェントを提供する Web サービス）と統合されたライセンスが購入可能です。生成 AI をフル活用した業務改善を行う際は、NotebookLM Enterprise は有力な選択肢となります。 参考 : Gemini Enterpriseを徹底解説！ - G-gen Tech Blog その他の注意点 新機能の展開 NotebookLM に新機能が追加される際、最も先に展開されるのは、無償版の NotebookLM です。無償版で一般消費者が十分に機能を利用して、フィードバックや利用傾向に関する情報が得られてから、機能は次に NotebookLM in Pro（あるいは Google Workspace 版）に展開されます。 NotebookLM Enterprise に機能が展開されるのは 最も遅く 、数カ月のラグがある場合もあります。この展開時期に関する公開情報はありません。 まずは無償版あるいはコミュニティ版の製品に新機能を展開し、次いでよりミッションクリティカルな業務に製品を利用しているであろうエンタープライズ版に機能が展開されていくような傾向は、Linux ディストリビューションなどでも見られ、ビジネスインパクトのコントロールや関連機能の十分な整備のためには合理的な流れです。 ノートブックの共有可否 個人アカウントで NotebookLM（無償版）もしくは NotebookLM in Pro を使っている場合は、個人アカウントに対してのみ、ノートブックの共有が可能です。Google Workspace の組織に所属するアカウントに対しては、 ノートブックを共有できません 。 Google Workspace アカウントを使っているユーザーは、 同じ組織 （Google Workspace ドメイン）で NotebookLM in Pro を使っているユーザに対してのみ、ノートブックの共有が可能です。 NotebookLM Enterprise のユーザーは、同じ Google Cloud プロジェクトに紐づく NotebookLM Enterprise のユーザーに対してのみ、ノートブックの共有が可能です。また、共有先のユーザーは同じ Workforce Identity Pool（IdP 間連携の設定）に所属している必要があります。 無償版、in Pro、Enterprise のノートブックは相互に共有することはできません。 参考 : Create a notebook in NotebookLM - NotebookLM Help 参考 : Share notebooks - NotebookLM Enterprise また、ノートブックをインターネットに公開できるのは、2025年10月初旬現在、無償版 NotebookLM と、個人アカウントで Google AI Pro サブスクリプションを購入している場合の NotebookLM in Pro のみです。 アクセス URL 無償版と in Pro の NotebookLM は、いずれも https://notebooklm.google.com/ からアクセスします。この URL にアクセスすると、無償版の Google アカウントでログインしている個人ユーザーであれば NotebookLM（無償版）が開き、Google Workspace ユーザーや Google AI Pro サブスクリプションのユーザーであれば、NotebookLM in Pro が開きます。 一方で、NotebookLM Enterprise はアクセス URL が異なります。NotebookLM Enterprise へのアクセス方法は2つあります。 Gemini Enterprise の画面から遷移する 専用のアクセス URL へアクセスする 1つ目の Gemini Enterprise の画面から遷移する方法は、Gemini Enterprise の左側のメニューから NotebookLM をクリックするだけです。 Gemini Enterprise の画面から遷移 2つ目の方法である NotebookLM Enterprise のアクセス専用 URL は、管理者によって Google Cloud コンソールから発行できます。Google Cloud コンソールで、検索テキストボックスに「NotebookLM」と入力するとサジェストされる「NotebookLM for Enterprise」画面に遷移すると、URL を発行できます。 URL がうまく発行できないときのトラブルシューティングについては、以下の記事末尾の「トラブルシューティング・参考情報」の見出しを参照してください。 参考 : Gemini Enterpriseを徹底解説！ - G-gen Tech Blog - NotebookLM Enterprise アクセス用 URL が発行できない 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の川村です。この記事では NotebookLM の マインドマップ 機能の活用方法を解説します。 NotebookLM とは マインドマップ機能とは 事前準備 ソースの追加 マインドマップの使い方 マインドマップ生成 操作方法 共有 活用シーン 1. 複雑な情報や大量の資料の全体像把握 2. 投影資料活用 3. 情報整理・可視化 4. 会議のネクストアクション整理 5. アイデア発想とブレインストーミングの促進 注意点 NotebookLM とは NotebookLM とは、Google ドキュメント、PDF、音声、YouTube 動画などをソースとして指定し、その情報を基に要約・FAQ・メモを生成できる Google 提供の AI ノートサービスです。 一般的な生成 AI チャットアプリと異なり、回答の出典をユーザーが明示的に制御できるため、業務利用において高い信頼性が確保されます。 無償版で利用できる NotebookLM、有償版の NotebookLM in Pro（旧 NotebookLM Plus）、より企業向けの機能を強化した NotebookLM Enterprise があり、それぞれの機能の違いや活用ユースケースについては以下ブログをご参照ください。 blog.g-gen.co.jp マインドマップ機能とは NotebookLM の マインドマップ機能 は簡単なクリック操作で、資料を「マインドマップ」形式に自動で整理し可視化する機能です。 本来の「マインドマップ」とは、中心となるテーマから関連するキーワードやアイデアを放射状に広げて整理する図のことで、思考や情報の構造を視覚的に捉えるための手法です。 従来、作成に多くの時間と手間を要しましたが、AI を活用することでこのプロセスを自動化し即座に整理できます。 参考 : Use Mind Maps in NotebookLM - NotebookLM ヘルプ マインドマップは、以下のようなシーンで役立ちます。 概要理解 : 大量の情報を要点ごとに整理し、学習や資料分析に活用 アイデア拡大 : 関連語や連想が促され、新しい発想を促進 記憶定着 : 視覚的に構造化され、記憶の定着に効果的 思考整理 : 複雑な情報も関係性ごとに可視化 事前準備 ソースの追加 NotebookLM に対象となるソースを追加します。 [ソース] からデータソースを追加するだけで準備完了です。（メインパネルに [マインドマップ] ボタンが表示されます） 参照 : Add or discover new sources for your notebook - Computer - NotebookLM ヘルプ マインドマップの使い方 マインドマップ生成 メインパネルの [マインドマップ] ボタンをクリックするとマインドマップが生成されます。 生成されたマインドマップをクリックすると、全画面に表示されます。 ソースで指定した資料の主要トピックと概要、またその関連性を視覚的にマインドマップ形式で自動整理、可視化されていることが確認できます。 今回は例として、金融庁が公開している PDF ファイルをソースとして指定しています。 参考 : https://www.fsa.go.jp/policy/nisa2/about/nisa2024/guidebook_202307.pdf 操作方法 マインドマップは静的な図としての利用だけでなく、動的な操作や機能が特徴です。 ズームとスクロール : マインドマップを拡大・縮小し、俯瞰的もしくは部分的に情報整理します。 ブランチの展開／折りたたみ : ノード（トピック）横のブランチで詳細なトピックの表示・非表示を切り替えられます。 ノードを選択して質問 : ノード（トピック）をクリックし、 NotebookLM に質問や出典元へ即座にアクセスできます。 ダウンロード、その他 : 開いている画面で画像（PNG形式）としてダウンロードや、マインドマップの最小化、終了ができます。 共有 NotebookLM で作成したマインドマップは、他ユーザーと共有できます。 参照 : Create a notebook in NotebookLM - NotebookLM ヘルプ 方法1 : ノートブックごと共有する マインドマップを作成したノートブック右上の「共有」からユーザーやグループに共有し、共有先の相手も同じマインドマップを Studio パネル（NotebookLM の右画面）から利用できます。ただしグループの追加は、無償版 NotebookLM では利用できません。 方法2 : マインドマップをダウンロードして共有する マインドマップウィンドウの右上にある「↓」よりダウンロードし、そのファイルをメールやチャットなどで送信し共有できます。 活用シーン 1. 複雑な情報や大量の資料の全体像把握 膨大な資料（学術論文や専門書）や学習教材などをマインドマップ化することで、情報間の階層構造や関連性が視覚的に示されるため、テキストよりも図解で全体像を掴みたい場合に有効です。 複雑な情報群の全体構造を、大項目から小項目まで直感的に理解できます。 また、出典元を確認したり復習したい項目がある場合は、ノードをクリックします。 その後、NotebookLM の回答からソースをクリックすることで、元の情報を確認できます。 2. 投影資料活用 セミナーやブログなどのコンテンツ配信の参考資料として活用できます。 例えば研修や教育の場でも、複数のトピックを順序立てて説明したり、視覚的に関係性を整理しながら解説することで受け取り手の理解を促進します。 3. 情報整理・可視化 ①管理コンソールの組織一覧をひと目で把握 Google Workspace の組織構造を一目で把握したい場合にも役立ちます。 以下手順でユーザー一覧のデータを整形し、マインドマップとして組織に展開できます。 Google Workspace 管理コンソールからユーザー情報をダウンロードし、Google ドライブでスプレッドシートに変換 必要な列 ( ユーザー名、組織、部署、役職列 ) のみ残して部署列でソートし、CSV 形式でダウンロード データを TXT ファイルへ変換後、 NotebookLM のソースに追加し [マインドマップ] ボタンをクリック ②顧客フィードバックとサービス改善点の発見 顧客サポート記録やアンケート結果をマインドマップで整理すると、未整理の内容も AI で自動で分析・カテゴライズ し、「ポジティブ」と「改善要望」のようにノードを分けて表示します。 頻出する要望やクレームの種類、特定の機能への評価などが可視化され、具体的なサービス改善点の発見に役立ちます。 4. 会議のネクストアクション整理 会議の音声ファイルや議事録をアップロードしマインドマップ機能を利用すると、会議内容（主な議題、決定事項、担当者、期限など）が視覚的に整理されます。 これにより、関連課題の抜け漏れやネクストアクションの明確化が期待でき、課題整理やアイデア創出に役立ちます。 5. アイデア発想とブレインストーミングの促進 マインドマップは自由な連想を促し、新たなアイデアや視点を見つけたり複数のアイデアを組み合わせたりすることができます。 例えば、自身の経歴や実績、関心事などを記述した文章をソースとしてマインドマップを作成します。 これにより、「職務経験」で培ったスキルと「個人的な興味」が将来の「目標」達成にどう結びつくかなど、要素間の意外な繋がりや相乗効果を発見できる可能性があります。 これは、新たな視点の発見やモチベーション向上にもつながるでしょう。 注意点 以下の注意点に留意してください。ただし、今後のアップデートにより変更される可能性があります。 NotebookLM モバイルアプリは現在この機能をサポートしていません。 現時点ではマインドマップの修正は行えません。 川村真理 (記事一覧) クラウドソリューション部 クラウドサポート課 美容業界からITへ転身。Google Workspace 専任サポートから Google Cloud にも興味が湧き日々奮闘中。海外旅行が大好きで11カ国突破、これからも更新予定

G-gen の min です。データポータル（英名 Data Studio、旧称 Looker Studio）レポートに表示するデータを、閲覧者のメールアドレスに基づいて動的に制限する方法を解説します。 概要 設定方法 検証 データソースへのアクセスを許可した場合 データソースへのアクセスを許可しない場合 概要 データポータルで作成したレポートを複数のユーザーで共有する際に、同じレポートでありながら、閲覧するユーザーのメールアドレスに応じて表示されるデータを出し分けたいという要件があります。例えば、営業担当者ごとに自身の売上データのみを表示する、といったケースです。 データポータルでは、データソースに「 メールアドレスでフィルタ 」を設定することで、このような行レベルのデータセキュリティを実現できます。この機能を利用すると、レポート閲覧時に自身のデータソースへのアクセス許可を求めるダイアログが表示されます。閲覧者がアクセスを許可すると、データソースはそのメールアドレスに関連付けられたデータのみを返します。 参考 : メールアドレスでフィルタする 設定方法 以下に、データソースにメールアドレスフィルタを設定する手順を説明します。 メニューから [リソース] > [追加済みのデータソースの管理] を選択します。 対象のデータソースから [アクション] > [編集] をクリックします。 データソースエディタ画面の上部にある [メールアドレスでフィルタ] をクリックします。 「閲覧者のメールアドレスでデータをフィルタリングする」というダイアログが表示されます。[閲覧者のメールアドレスでデータをフィルタ] というチェックボックスをオンにします。 ※このとき、以下のようなガイドが表示され、データソースへのアクセス許可を求められます。許可します。 [メールアドレス項目] のプルダウンメニューから、データセット内で閲覧者のメールアドレスが格納されているフィールド（例: 担当者Emailアドレス フィールド）を選択します。このフィールドのデータ型はテキストである必要があります。 右上の [完了] をクリックします。 上記の設定により、このデータソースを使用するすべてのレポートで、メールアドレスによるフィルタが有効です。 検証 メールアドレスによるフィルタが設定されたレポートを、異なるメールアドレスを持つユーザーが閲覧した際の動作を検証します。 前提として、基になるデータセットには、レポートにアクセスする各ユーザーの完全なメールアドレスが含まれている必要があります。 ここでは、以下の2つのユーザーアカウントで検証します。 ユーザー A : user-a@example.com ユーザー B : user-b@example.com データソースには、各ユーザーのメールアドレスと関連するデータ「各担当者の売上成績サンプル」が含まれています。 レポートを閲覧しようとすると、まず以下のようなダイアログが表示され、データソースへのアクセス許可を求められます。 データソースへのアクセスを許可した場合 ユーザーが [許可] をクリックしてメールアドレスへのアクセスに同意すると、レポートにはそのユーザーのメールアドレスに関連付けられたデータのみが表示されます。 例えば、ユーザー A（user-a@example.com）がレポートを閲覧すると、データソースは user-a@example.com に紐づくデータのみを返すため、ユーザーAに関連する情報だけが表示されます。 同様に、ユーザー B（user-b@example.com）が同じレポートを閲覧すると、ユーザー B に関連する情報だけが表示されます。 このようにして、単一のレポートでユーザーごとに表示データを切り替えられます。 なお、一度同意した場合でも、ユーザーは後からその同意を取り消せます。同意の取り消しは、データポータルのトップページ（ https://datastudio.google.com/ ）の、右上の設定アイコンから行えます。 [同意を取り消す] > [すべて取り消す] を選択します。 参考 : メールへのアクセス権を取り消す データソースへのアクセスを許可しない場合 ユーザーがデータソースへのアクセス許可を求めるダイアログで [許可しない] をクリックした場合、またはダイアログを閉じた場合、データソースはメールアドレスによるフィルタリングを行えません。 その結果、データソースに基づくレポートのコンポーネント（グラフや表など）には、「このコンポーネントはデータを読み込むにあたりお客様の同意を必要としています。」といったメッセージが表示され、実際のデータは表示されません。 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。