G-gen の武井です。当記事では、BigQuery と Git リポジトリを連携する機能である BigQuery リポジトリ を解説します。 はじめに 機能説明 リポジトリ リポジトリの利用形態 取り扱い可能なファイル バージョン管理 IAM ロール 料金 検証1（セットアップ） セットアップの概要 リポジトリの作成 ワークスペースの作成 ディレクトリの作成 SQL ファイルの作成 検証2（バージョン管理） デモの概要 commit push pull 復元 クエリ実行 検証3（GitHub リポジトリとの接続） 関連記事 はじめに BigQuery リポジトリ とは、BigQuery と Git リポジトリを連携する機能です。Google Cloud コンソールの BigQuery 操作画面である BigQuery Studio において、組み込みの Git リポジトリまたは GitHub 等の Git リポジトリと接続して、SQL ファイル等のバージョン管理をしたり、Git ワークフローを操作することができます。 これにより、以下のようなメリットを得ることができます。 Git リポジトリ上の SQL をそのまま BigQuery 上で実行できる BigQuery Studio 上で SQL のバージョン管理ができる チームでの共同作業が容易になる 当記事では、BigQuery リポジトリの機能、セットアップ方法、ならびに操作手順について説明します。 参考： BigQuery リポジトリの発表: BigQuery Studio での Git ベースのコラボレーション 参考 : Introduction to repositories なお当機能は、2025年4月時点でプレビューです。 参考 : Preview版のサービスを使うとはどういうことなのか 機能説明 リポジトリ BigQuery リポジトリでは、 組み込みの BigQuery リポジトリ を使用するか、以下の サードパーティーリポジトリ と接続可能です。 Git プロバイダ 接続方法 Microsoft Azure DevOps Services SSH Bitbucket SSH GitHub SSH または HTTPS GitLab SSH または HTTPS 参考： サードパーティのリポジトリ リポジトリの利用形態 リポジトリの利用形態は以下の2通りです。 プライベートリポジトリ リポジトリ作成者のみ利用可能 共有リポジトリ 複数のプリンシパルで共有可能 参考： リポジトリを共有する 取り扱い可能なファイル リポジトリにて取り扱い可能なファイルは以下の通りです。 SQL クエリ Python ノートブック データキャンバス データプレパレーション 上記以外のファイル 参考： ワークスペース内のファイルを操作する バージョン管理 リポジトリでは以下のバージョン管理操作が実行できます。 オプション 説明 変更 ワークスペースまたは選択したファイルのローカル変更を commit する push commit をデフォルトブランチ（main）または指定のブランチに push する pull デフォルトブランチをワークスペースに pull する 復元 ワークスペースにあるファイルを前回の commit に復元する 参考： ファイルでバージョン管理を使用する IAM ロール 共有リポジトリとワークスペースの操作に必要な権限は以下の通りです。 操作 IAM ロール 共有リポジトリの作成・管理 コードオーナー（ roles/dataform.codeOwner ） ワークスペースの作成・削除 コードエディタ（ roles/dataform.codeEditor ） ファイルの作成・変更・バージョン管理 同上 リソースの表示 コード閲覧者（ roles/dataform.codeViewer ） また、プライベートリポジトリとワークスペースの操作に必要な権限は以下の通りです。 操作 IAM ロール プライベートリポジトリの作成・管理 コード作成者（ roles/dataform.codeCreator ） ワークスペースの作成・削除 同上 ファイルの作成・変更・バージョン管理 同上 参考： 必要なロール 料金 BigQuery リポジトリの利用に料金はかかりません。 参考： 料金 検証1（セットアップ） セットアップの概要 当記事では、BigQuery Studio に BigQuery リポジトリ（標準の組み込みリポジトリ）を接続し、SQL ファイルのバージョン管理を行います。 リポジトリの作成 BigQuery Studio > リポジトリを表示 > リポジトリの追加 の順で BigQuery リポジトリを作成します。 作成時点ではプライベートリポジトリですが、 [︙]アイコン > 共有 の順で 共有リポジトリ に変更できます。（作成者以外のプリンシパルに権限を付与することができます） 参考： リポジトリを作成する 参考： リポジトリを共有する ワークスペースの作成 先ほど作成したリポジトリ名をクリックし、 ワークスペースタブ > ワークスペースを追加 の順でワークスペースを作成します。 なお、ワークスペースとは 同じリポジトリで作業している他のユーザーに影響を与えることなく、リポジトリでファイルの作成、編集、削除を行うための仮想的な作業空間 を意味します。 作成後は 開く > 確認 の順でクリックすると、BigQuery Studio にリポジトリを接続できます。 ディレクトリの作成 次に、ワークスペースにディレクトリを作成します。今回のデモでは、クエリ先の構成に合わせてディレクトリを作成します。 . └── sample ├── customers │ └── demo.sql ├── products │ └── ... └── sales └── ... [+] アイコン > リポジトリに作成 > ディレクトリ の順でディレクトリを作成します。 SQL ファイルの作成 各ディレクトリに SQL ファイルを作成し、クエリのバージョン管理を行います。 各ディレクトリの [︙] アイコン > リポジトリに作成 > SQL クエリ の順で SQL ファイル作成します。 ファイルにクエリを入力すると（変更が検知したため）、 Commit X Change と表示されました。 検証2（バージョン管理） デモの概要 先ほど作成した SQL クエリをもとに、バージョン管理操作を行います。 commit 変更を commit します。 Commit X change をクリックすると、変更内容が確認できます。commit メッセージ（必須）を入力後、 すべて（あるいは X 個）のファイルを commit をクリックします。 push 次に、先ほどの commit をデフォルトブランチ（main）に push します。 プルダウン > デフォルトブランチに push を実行すると、デフォルトブランチにマージされます。 pull 共有リポジトリにおいて、他メンバーが push した内容を取り込みたい場合、 プルダウン > デフォルトブランチから pull を実行します。 復元 変更の過程で前回の commit に戻したい場合、 プルダウン > 前回の commit に戻す を実行します。 クエリ実行 リポジトリで管理する SQL ファイルは、BigQuery Studio 上で直接実行できます。 検証3（GitHub リポジトリとの接続） GitHub リポジトリを BigQuery Studio に接続する場合、以下の準備が必要です。 GitHub リポジトリ Secret Manager HTTPS の場合は個人アクセストークン、SSH の場合は秘密鍵を格納したシークレットを作成 IAM Policy 上記にアクセスできるよう、Dataform デフォルトサービスアカウントに対し以下の IAM ロールを付与 Secret Manager シークレットアクセサー（roles/secretmanager.secretAccessor） 上記の準備が完了したら、 リポジトリの追加 から GitHub リポジトリ接続用の BigQuery リポジトリを作成し、 リポジトリの構成タブ > Git 接続を編集 の順で設定を進めると GitHub リポジトリを接続できます。 参考： HTTPS 経由でリモート リポジトリに接続する 参考： リモート リポジトリ接続を編集する 関連記事 blog.g-gen.co.jp blog.g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2025 選出。 趣味はロードレースやサッカー観戦、あとはゴルフと筋トレ。 Follow @ggenyutakei

G-gen の杉村です。2025年3月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Security Command Center Enterprise で Amazon EC2 のスキャン Vertex AI Agent Engine が Preview → GA Google スライドの Gemini サイドパネルが日本語に対応 Spanner で階層型ストレージが登場（GA） Analytics Hub の egress controls と Data clean room が全 BigQuery Edition に対応 Gemini 2.0 Flash の fine-tuning が GA Google Meet でバーチャル背景生成や画質・音質向上など生成 AI 機能 Google Meet で自動議事録およびリアルタイム音声文字起こし Deep Research と Gems が全エディションで利用可能に Cloud Storage に新機能 Anywhere Cache が登場（GA） Gemini のコンテキストキャッシュがPreview→GA Compute Engine に M4 VM が登場 BigQuery と Spanner の連携が強化 Google ドキュメントで AI 要約のビルディングブロックを作成できるように Gemini アプリに「Canvas」が登場 NotebookLM にマインドマップ機能が追加 Vertex AI Search の answer メソッドが強化 Google、マルチクラウドセキュリティソリューションの Wiz を買収 Dataform が Secret Manager と統合 BigQuery workflows が BigQuery pipelines に改名 BigQuery Studio と Git の統合が Preview BigQuery ML で Claude モデルが利用可能に（GA） Cloud Storage の管理情報閲覧ツール Storage Intelligence Cloud SQL でインスタンス削除後もバックアップを保持可能に Cloud SQL に read pools が登場（Preview） Gemini 2.5 Pro Experimental が発表 Gemini が日本語 PDF を読み込み可能に BigQuery の Search Index に column granularity 機能が追加 Cloud Run で呼び出し時の IAM チェックの無効化が可能に Google Docs の Help me create が日本語を含む追加言語に対応 BigQuery pipelines が Preview -> GA はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Security Command Center Enterprise で Amazon EC2 のスキャン Enable VM Threat Detection for AWS (2025-03-03) Security Command Center の Enterprise ティアで、Amazon EC2 のディスクのマルウェアスキャンができるようになった（Preview）。 AWS Lambda と AWS Systems Manager（SSM）を利用して、EC2 インスタンス上のマルウェアをスキャンして Security Command Center へ通知する。 Vertex AI Agent Engine が Preview → GA Vertex AI Agent Engine overview (2025-03-04) Vertex AI Agent Engine（旧LangChain on Vertex AI、Vertex AI Reasoning Engine）が Preview→GA。 Langchain、LangGraph などのフレームワークをデプロイ可能なフルマネージドの Agent プラットフォーム。 Google スライドの Gemini サイドパネルが日本語に対応 Use Gemini in the side panel of Google Slides in seven new languages (2025-03-05) Google スライドの Gemini サイドパネルが日本語を含む7言語に新たに対応。画像生成も可能になる。 日本語 フランス語 ドイツ語 イタリア語 韓国語 ポルトガル語 スペイン語 Spanner で階層型ストレージが登場（GA） Tiered storage overview (2025-03-10) Spannerで階層型ストレージが登場（GA)。 SSDとHDDから選んでデータを保存できる。デフォルトではSSDに保存されるが「ローカリティグループ」を作成してテーブル/列を指定し、時間経過したデータを HDD に自動移行。HDD はレイテンシ・スループットに劣るがサイズあたりの費用が安い。 Analytics Hub の egress controls と Data clean room が全 BigQuery Edition に対応 BigQuery release notes - March 10, 2025 (2025-03-10) Analytics Hub の egress controls と Data clean room が全 BigQuery エディションに対応（オンデマンド含む）。 従来はオンデマンドまたは Enterprise Plus エディションが必要だった。 Gemini 2.0 Flash の fine-tuning が GA Tune Gemini models by using supervised fine-tuning (2025-03-11) Gemini 2.0 Flash の fine-tuning が GA。 トレーニングデータとしてテキスト、画像、音声、PDF を使ったファインチューニングが可能。 最低100個以上のデータを用意することが推奨されている。 Google Meet でバーチャル背景生成や画質・音質向上など生成 AI 機能 More AI-powered features in Google Meet and Google Chat are coming to Google Workspace Business and Enterprise editions (2025-03-11) Google Meet で、バーチャル背景生成や、スタジオ風の画質・音質の再現などの生成 AI 機能が組み込まれる。 Business Standard 以上のエディションに2025-03-10から順次ロールアウトされる。 Google Meet で自動議事録およびリアルタイム音声文字起こし More AI-powered features in Google Meet and Google Chat are coming to Google Workspace Business and Enterprise editions (2025-03-11) Google Meet の "Take notes for me"（自動議事録）およびリアルタイムの音声文字起こしが日本語に対応する。録画した動画にも字幕を付与可能。 Business Standard 以上の Google Workspace エディションに付帯。 2025-03-12から順次ロールアウトするが、「性能と品質を注視するため、通常よりずっと遅いペースでロールアウト」される予定。 Deep Research と Gems が全エディションで利用可能に Deep Research and Gems in the Gemini app are now available for more Google Workspace customers (2025-03-13) Gemini ウェブアプリにおいて、Deep Research と Gems が、これまで提供されていなかった Business Starter、Enterprise Starter、Education、Frontline、個人無償アカウントなどでも利用可能になった。 Cloud Storage に新機能 Anywhere Cache が登場（GA） Overview of Anywhere Cache (2025-03-13) Cloud Storage に新機能 Anywhere Cache が登場（GA）。ゾーンごとに読取キャッシュを作成。 キャッシュと同ゾーンの VM からの読み取りで、読取の高速化とマルチリージョンバケットからのデータ転送料金節約に役立つ。機械学習や分析ワークロードを想定。GB/Hour ごとの課金が発生する。 Gemini のコンテキストキャッシュがPreview→GA Context caching overview (2025-03-13) Gemini のコンテキストキャッシュがPreview→GA。 システム指示プロンプトを事前にキャッシュしておき料金を節約できる。画像や長大なテキストが毎回プロンプトに含まれている場合に有用。トークン/時間ごと課金。Gemini 1.5 Pro/Flashで利用可能。 Compute Engine に M4 VM が登場 M4 machine series (2025-03-14) Compute Engine に M4 VM が登場。メモリ最適化マシンタイプの新型で最大 224 vCPUs / 3 TB RAM。 SAP HANA 等を想定。普通の Persistent Disk は使えず、Hyperdisk がサポートされる。 BigQuery と Spanner の連携が強化 BigQuery release notes - March 17, 2025 (2025-03-17) BigQuery と Spanner の連携が強化された。 External dataset（別名 Federated dataset）で Spanner の全テーブルが BigQuery から見える EXPORT DATA 文で BigQuery から Spanner へデータをリバース ETL できる Google ドキュメントで AI 要約のビルディングブロックを作成できるように Introducing a new building block that summarizes content with Gemini in Google Docs (2025-03-17) Google ドキュメントで、AI 要約のビルディングブロックを作成できるようになった。 ドキュメントの先頭に要約を載せるなどが容易になる。ドキュメントが変更されたときに要約に反映する更新オプションも設定可能。 スクリーンショットは公式ドキュメントから引用 Gemini アプリに「Canvas」が登場 Try Canvas, a new way to collaborate with the Gemini app (2025-03-18) Gemini アプリに「Canvas」が登場。生成した文章を手動で編集しつつ、Gemini に調整を指示できる UI。 生成した文章に対して、文章の長さやフォーマル具合の調整、修正の提案等を行うことができる。作成した文章は Google ドキュメントにエクスポート可能。 無償アカウント含む全 Google アカウントで、すぐに利用可能。 Canvas NotebookLM にマインドマップ機能が追加 New features available in NotebookLM and NotebookLM Plus (2025-03-19) NotebookLM にマインドマップ機能が追加。ウェブサイト、動画、アップロードした PDF など、読み込ませたデータソースを解釈して、マインドマップ式に描画してくれる。 会議の議事録やドキュメントを構造化して表示してくれるので、資料の迅速な理解や思考の整理に役立つ。 無償アカウント含む全 Google アカウントで、すぐに利用可能。 NotebookLM のマインドマップ Vertex AI Search の answer メソッドが強化 Vertex AI Agent Builder release notes - March 19, 2025 (2025-03-19) Vertex AI Search の answer メソッドが強化。 非構造化データストアから画像ファイルを取得できるように 回答内でチャート（棒グラフ、折れ線グラフ等）を生成できるように いずれも以下の注意点がある。 Preview リリースである 英語クエリのみ対応 API のみ対応 Google、マルチクラウドセキュリティソリューションの Wiz を買収 Google + Wiz: Strengthening Multicloud Security (2025-03-19) Google、マルチクラウドセキュリティソリューションの Wiz を買収。 320億ドル（約4.8兆円）、全額現金取引。Google にとって最大規模の買収とされる。従来から持つ Google SecOps や Mandiant などの「侵害後」に強いソリューションに加え、Wiz の「未然に防ぐ」強さが追加されると見られる。 Dataform が Secret Manager と統合 Use Secret Manager to store sensitive data (2025-03-20) Dataform が Secret Manager と統合。 PostgreSQL、MySQL、Oracle など、BigQuery 以外の ID/Pass を要する外部データベースと接続する際に作るコネクションプロファイルの認証情報の保存先として使える。 BigQuery workflows が BigQuery pipelines に改名 Introduction to BigQuery pipelines (2025-03-20) BigQuery workflows が BigQuery pipelines に改名された。 BigQuery workflows は、Web コンソール上で簡単に実装できるフルマネージドのパイプラインツール。現在ではまだ Preview 公開。 BigQuery workflows BigQuery Studio と Git の統合が Preview Announcing BigQuery repositories: Git-based collaboration in BigQuery Studio (2025-03-20) BigQuery Studio（BigQuery コンソール画面）と Git の統合が Preview。 BigQuery コンソール画面で GitHub、GitLab 等のリモート Git レポジトリを接続して commit、push、diff、PR 作成などができる。 画像は公式発表より引用したもの BigQuery ML で Claude モデルが利用可能に（GA） The ML.GENERATE_TEXT function (2025-03-20) BigQuery ML で Claude モデルが使えるようになった（GA）。 ML.GENERATE_TEXT 関数で Vertex AI のリモートモデルを呼び出して BigQuery のデータを使って簡単に推論できる。 Cloud Storage の管理情報閲覧ツール Storage Intelligence Storage Intelligence (2025-03-21) Cloud Storage に管理情報閲覧ツール Storage Intelligence が登場。組織やフォルダレベルで閲覧可。 加えて管理情報を BigQuery にエクスポートする Storage Insights datasets も登場。これらで利用状況を可視化し、セキュリティ向上やコスト最適化を図ることができる。 Cloud SQL でインスタンス削除後もバックアップを保持可能に Retained backups (2025-03-24) Cloud SQL でインスタンス削除後もバックアップを保持できるようになった。 従来までは、インスタンスを削除すると最高365日保存の Final Backup を残してバックアップは削除されてしまう仕様だったが、残るようになった。オンデマンドバックアップは無期限保存、自動バックアップは保持日数設定に応じて自動削除される。 Cloud SQL のバックアップの一通りの仕様は、以下の記事も参照。 blog.g-gen.co.jp Cloud SQL に read pools が登場（Preview） About read pools (2025-03-25) Cloud SQL に read pools が登場（Preview）。Cloud SQL Enterprise Plus エディション（MySQL、PostgreSQL）で利用可能。 リードレプリカの集合体であり、単一 IP アドレスをエンドポイントとして、読み取りワークロードを負荷分散。ノード数は調整可能で、最大20ノード。以前からあるリードレプリカとの違いは、読み取りエンドポイントが単一 IP アドレスであることと、プールとして一括管理できること。 Gemini 2.5 Pro Experimental が発表 Gemini 2.5: Our most intelligent AI model (2025-03-25) Google が最新版生成AIモデル Gemini 2.5 Pro Experimental を発表。 1.5 Flash Thinking と同じく思考プロセスも出力される「思考型」。当初100万トークンのコンテキストウインドウで後日200万に拡大予定。先行して Google AI Studio や Gemini ウェブアプリ（Gemini Advanced）で利用可能。 また、2025年3月28日、Google Cloudの Vertex AI でも利用可能になった。 Gemini ウェブアプリで Gemini 2.5 Pro Experimental が利用可能 Gemini が日本語 PDF を読み込み可能に Gemini in Drive PDF Viewer is now available in 20+ additional languages (2025-03-26) Google ドライブで、Gemini が日本語 PDF を読めるようになった。 Google ドライブの Gemini サイドパネルにおいて、通常の PDF やスキャンされた PDF 等を生成 AI が読み取り、要約したり、質問に答えたり、PDF 内容に基づいてメールを作成したりできる。従来の英語に加え、今回は日本語を含む20以上の言語に対応。 BigQuery の Search Index に column granularity 機能が追加 Index with column granularity (2025-03-26) BigQuery の Search Index に column granularity 機能が追加された。複数列に Search Index を作成する際、オプションで粒度を指定することでインデックスファイルに情報が付加され、検索クエリを最適化できる。 Cloud Run で呼び出し時の IAM チェックの無効化が可能に Disable the Cloud Run Invoker for services (2025-03-28) Cloud Run serivces/functions で、呼び出し時の IAM チェックの無効化が可能に。 以前は allUsers に呼び出し権限を付与してサービスを一般公開していたが、組織ポリシーで IAM のドメイン制限をしている場合はサービス公開に手間があった。この機能により、一時的に組織ポリシーを無効化するなどの対応が不要になる。 詳細は以下の記事も参照。 blog.g-gen.co.jp Google Docs の Help me create が日本語を含む追加言語に対応 Help me create in Google Docs now available in seven additional languages (2025-03-31) Google Docs の Gemini 機能、Help me create が日本語を含む追加言語に対応。 ゼロからドキュメント作成を自然言語で指示。「@(ファイル名)」で他のファイルに基づいた指示も可。文字だけでなく画像やスタイルも含めて作るのが従来との違い。 2025-03-31から15日ほどかけてロールアウト。 BigQuery pipelines が Preview -> GA Schedule pipelines (2025-03-31) BigQuery pipelines（旧称 BigQuery workflows）が Preview → GA。 また、data preparation を BigQuery pipelines から呼び出せるようになった。さらに、BigQuery Studio の「スケジュール設定」画面から、スケジュールを一覧管理できるようになった。 以下の記事も参照。 参考 : BigQueryを徹底解説！(基本編) - G-gen Tech Blog - BigQuery pipelines 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では Cloud Run における 呼び出し元 IAM チェックの無効化 について解説します。 前提知識 Cloud Run について Cloud Run 呼び出し元の IAM 認証 呼び出し元 IAM チェックの無効化 概要 ユースケース 手順 必要な IAM 権限 コンソールを使用する場合 gcloud コマンドを使用する場合 YAML ファイルを使用する場合 IAM チェック無効化を禁止する 組織のポリシーによる制御 制御されている場合の挙動（コンソール） 制御されている場合の挙動（gcloud） 前提知識 Cloud Run について Cloud Run とは、Google Cloud のマネージドなコンテナ実行環境でアプリケーションを実行することができる、サーバレス コンテナコンピューティング サービスです。 Cloud Run には Cloud Run services 、 Cloud Run jobs 、 Cloud Run functions （旧称 : Cloud Functions）の3種類がありますが、当記事の内容は HTTP リクエストベースでアプリケーションを実行できる Cloud Run services および Cloud Run functions に関するものとなります。 Cloud Run services および Cloud Run functions の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp blog.g-gen.co.jp Cloud Run 呼び出し元の IAM 認証 Cloud Run 上のアプリケーションは、Google Cloud の IAM で許可されているユーザーのみがアクセスすることができます。 具体的には、アクセスを許可したいプリンシパル（ユーザー、サービスアカウントなど）に Cloud Run 起動元 （roles/run.invoker）や Cloud Run サービス起動元 （roles/run.servicesInvoker）などのロールを付与することで、アプリケーションを呼び出すことができるようになります。 IAM を使用して、誰でもアプリケーションを呼び出すことができるようにするためには、 allUsers というプリンシパルに対して上記のロールを付与する必要があります。 「allUsers」に呼び出し権限を付与して Cloud Run を公開する（サービスの詳細画面から設定する場合） 「allUsers」に呼び出し権限を付与して Cloud Run を公開する（サービス一覧画面から設定する場合） 呼び出し元 IAM チェックの無効化 概要 Cloud Run service および Cloud Run functions では、前述の IAM 認証によるアクセス元制御（呼び出し元 IAM チェック）を 無効化 することができます。 これにより allUsers プリンシパルに対する IAM ロールの付与を行うことなく、誰でも Cloud Run 上のアプリケーションを呼び出すことができるようになります。 参考： Access control with IAM - Disable the Cloud Run Invoker for services ユースケース Cloud Run で呼び出し元 IAM チェックの無効化がサポートされる以前は、前述した allUsers プリンシパルに対する IAM ロールの付与によりアプリケーションを公開していました。すべてのプリンシパルに対してアクセス許可を行うという点においては、どちらの方法も結果は同様のものになります。 allusers を使用する手順では、プロジェクトで ドメインで制限された共有 （ iam.allowedPolicyMemberDomains ）という 組織ポリシー が有効化されている場合、IAM ロールを付与できるプリンシパルのドメインが制限されるため、Cloud Run の呼び出しを許可する IAM ロールを allusers に付与することができません。 この場合、 allusers に対してロールを付与するためには、当該組織ポリシーを一時的に無効化し、ロールを付与したあとに再度ポリシーを有効化するといった手順が必要となります。 組織ポリシー「ドメインで制限された共有」 一方で、呼び出し元 IAM チェックを無効化する場合は、プリンシパルに対する IAM ロールの付与を伴わないため、組織ポリシーを 一時的に無効化する必要がありません 。したがって、より簡易的な手順で Cloud Run を公開することができます。 参考： Restricting identities by domain 手順 必要な IAM 権限 当記事では Cloud Run services における設定手順を解説します。 呼び出し元 IAM チェックの設定を変更するには以下の権限が必要です。これらはプロジェクトの オーナー （roles/owner）や、 Cloud Run 管理者 （roles/run.admin）ロールに含まれています。 run.services.create run.services.update run.services.setIamPolicy コンソールを使用する場合 呼び出し元 IAM チェックの設定は、サービスの作成時、および更新時に「認証」項目で変更することができます。 以下のスクリーンショットは、既存のサービスを更新する場合の設定箇所を示しています。「Cloud IAM を使用して受信リクエストを認証する」のチェックボックスでチェックを外すことで、呼び出し元 IAM チェックを無効化してサービスを公開することができます。 コンソールから呼び出し元 IAM チェックを無効化する gcloud コマンドを使用する場合 CLI を使用する場合も、サービスの作成時や更新時に設定を変更することができます。 以下のコマンドでは、 --no-invoker-iam-check フラグを使用してサービスを更新することで、呼び出し元 IAM チェックを無効化します。 # Cloud Run services で呼び出し元 IAM チェックを無効化する $ gcloud run services update < サービス名 > --no-invoker-iam-check 呼び出し元 IAM チェックを有効化したい場合は、 --invoker-iam-check フラグを使用します。 # Cloud Run services で呼び出し元 IAM チェックを有効化する $ gcloud run services update < サービス名 > --invoker-iam-check 参考： gcloud run services update YAML ファイルを使用する場合 YAML ファイルでサービスを管理している場合は、 run.googleapis.com/invoker-iam-disabled アノテーションを true にすることで、呼び出し元 IAM チェックを無効化することができます。 apiVersion : serving.knative.dev/v1 kind : Service metadata : annotations : run.googleapis.com/invoker-iam-disabled : true name : <サービス名> IAM チェック無効化を禁止する 組織のポリシーによる制御 組織ポリシーである Require IAM invoker check for Cloud Run services （ run.managed.requireInvokerIam ）を組織またはプロジェクトで有効化すると、Cloud Run 呼び出し元 IAM 認証を無効化する操作を禁止することができます。 このポリシーを ドメインで制限された共有 （ iam.allowedPolicyMemberDomains ）と併せて使うことで、Cloud Run の未認証呼び出しを完全に禁止することができます。 参考 : Configure organization policy for the Cloud Run invoker IAM check 制御されている場合の挙動（コンソール） 組織のポリシー Require IAM invoker check for Cloud Run services（ run.managed.requireInvokerIam ）が有効化されていると、Google Cloud コンソールの Cloud Run 画面で、IAM チェックの有無を制御するチェックボックスを操作することができなくなります。 組織ポリシーによりチェックボックスが無効化されているケース このポリシーはデフォルトでは無効化されています。プロジェクトでポリシーを有効化した覚えがないのにも関わらず、「Cloud IAM を使用して受信リクエストを認証する」のチェックボックスがグレーアウトしている場合は、組織レベルで有効化されているポリシーがプロジェクトに継承されている可能性があります。 組織ポリシー「Require IAM invoker check for Cloud Run services」 制御されている場合の挙動（gcloud） 同様に、組織のポリシーで禁止されている場合、gcloud コマンド gcloud run services update <サービス名> --no-invoker-iam-check で Cloud Run 呼び出し元の IAM 認証を無効化しようとすると、以下のようなメッセージが表示されます（例は、2025年3月31日現在のもの）。 Update failed ERROR: (gcloud.run.services.update) FAILED_PRECONDITION: Operation denied by custom org policy: ["constraints/run.managed.requireInvokerIam": "When enforced, this constraint requires the IAM invoker check to be enabled on Cloud Run services. If this constraint is not enforced, you can set the service.invoker_iam_disabled field (v2), or the run.googleapis.com/invoker-iam-disabled annotation (v1) on Cloud Run services to True . The invoker_iam_disabled field is currently available by invitation-only and will not be broadly available until after March 21, 2025. It's still possible to achieve a similar result by granting the run.routes.invoke permission to allUsers."]. 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の min です。Looker Studio レポートの共有先のドメイン名を制限する方法を解説します。 概要 設定方法 検証 概要 Looker Studio のレポートを共有する際に、特定のドメイン（例 : g-gen.co.jp ）のユーザーに対してのみ共有を許可し、それ以外のドメインへの共有を禁止したい場合があります。 デフォルトでは、組織外のユーザーともレポートを共有できますが、Google Workspace または Cloud Identity の管理者は、管理画面の設定により、レポートを共有できるドメインを制限することができます。 参考 : Looker Studio ユーザーの共有権限を設定する 設定方法 当手順を実施するには、Google Workspace または Cloud Identity の管理者権限が必要です。 Google 管理コンソール（ https://admin.google.com/ ）にアクセスします。 [アプリ] > [その他の Google サービス] > [Looker Studio] を選択します。 [共有設定] > [許可リスト登録済みドメインがオン] を選択します。 共有を許可するドメイン名（例 : g-gen.co.jp ）を追加します。 許可リスト登録済みドメインの設定例 検証 許可されたドメインに対して、Looker Studio レポートを共有します。ここでは例として、 dev.g-gen.co.jp 組織で作成されたレポートを、 g-gen.co.jp に所属するアカウントに対して共有してみます。 g-gen.co.jp は前述の管理画面の設定で許可されているため、以下のように共有が成功しました。なお、この検証では dev.g-gen.co.jp と g-gen.co.jp のように、サブドメインの関係にあるドメイン名を使っていますが、サブドメインは異なるドメインとして認識されます。 共有先の指定 共有後のアクセス権があるユーザー一覧 一方で、管理画面で許可されていないドメイン名（例 : reseller.co.jp ）への共有を試すと、以下の警告が表示され、共有できません。 警告画面 お客様の組織では、指定されたユーザーまたはグループとの共有が制限されています。ハイライト表示された受信者を削除してからやり直すか、管理者にお問い合わせください。 なお公式ドキュメントには、許可対象のドメインの設定変更は、反映に最大で24時間かかる場合があると記載されています。検証では、1分程度で設定が反映されました。 参考 : 信頼できるドメイン外での共有を制限する 変更が反映されるまでには、最長で 24 時間ほどかかることがあります。その間は一時的に、古い設定と新しい設定の両方が適用される場合があります 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の杉村です。Google Cloud には 課金レポート （Billing Report）画面上で表記されている日付のタイムゾーンについて解説します。結論は、課金レポートのタイムゾーンは PST（太平洋標準時）です。 課金レポートのタイムゾーン 検証 結果 課金レポートのタイムゾーン Google Cloud には 課金レポート （Cloud Billing Report）画面が用意されており、利用料金を詳細に確認することができます。 参考 : Google Cloudの請求の仕組みを分かりやすく解説してみた - G-gen Tech Blog - 課金レポート 実際に課金が発生してから課金レポートに金額が反映されるまではタイムラグがあるほか、レポート上の日付と実際の日付にズレがあるようです。このズレは、タイムゾーンに起因しています。 課金レポートのタイムゾーンは、 PST （太平洋標準時）です。PST とはアメリカ西海岸地域の標準時であり、UTC（協定世界時）マイナス8時間、JST（日本標準時）マイナス17時間です。 PST = UTC-8 JST = UTC+9 PST = JST-17 時差を例示すると、以下のようになります。 PST UTC JST 2025/03/01 22:00 2025/03/02 6:00 2025/03/02 15:00 課金レポートのタイムゾーンについては、少々わかりにくいですが、以下の公式ドキュメントに記載されています。 参考 : レポートを使用して請求データと費用の傾向を分析する Cloud Billing レポートの 24 時間の期間は、米国とカナダの太平洋時間（UTC-8）の深夜 0 時から始まり、米国の夏時間への移行が適用されます。 検証 ドキュメントの解釈を確かにするために、以下の検証を行いました。 あるプロジェクトで、日本時間の 2025/03/02 15:00:00 に n2-standard-2 タイプのインスタンスを、また日本時間の 2025/03/03 1:00:00 に c3-standard-4 タイプのインスタンスを、それぞれ1時間だけ起動してから停止しました。インスタンスの起動・停止は、インタンススケジュール機能で自動化しました。 blog.g-gen.co.jp この時間帯には、同じプロジェクトで他の Compute Engine インスタンスが動作しないようにします。 課金レポートにはマシンシリーズごと、リージョンごとに SKU が用意されており、例えば C3 マシンシリーズのインスタンスがシンガポールリージョンで起動すると C3 Instance Core running in Singapore といった SKU が課金レポートに記録されます。 どのマシンシリーズの SKU が、どの日付に記録されるかを調べることで、課金レポートのタイムゾーンを知ることができます。 つまり、日本時間の 2025/03/02 15:00 に N2 タイプのインスタンスを起動したのに、課金レポート上は 2025/03/01 と表記されていた場合、課金レポートのタイムゾーンは PST であることがわかります。 タイプ PST UTC JST N2 2025/03/01 22:00 2025/03/02 6:00 2025/03/02 15:00 C3 2025/03/02 8:00 2025/03/02 16:00 2025/03/03 1:00 上記から、もし N2 の SKU が 2025/03/01 に記録されるならば、課金レポートのタイムゾーンは PST であることがわかります。2025/03/02 に記録されるならば、UTC か JST のどちらかです。確定するには、もう1台の C3 シリーズの SKU の日付を調べればよいことになります。C3 が 2025/03/03 に記録されていれば JST であることが確定します。 検証結果 レポートのタイムゾーン N2 が 3/1 に記録された場合 PST N2 が 3/2 に記録され、C3 が 3/2 に記録された場合 UTC N2 が 3/2 に記録され、C3 が 3/3 に記録された場合 JST なお、上記の3つ以外のタイムゾーンで表記されている可能性は考慮しないこととしています。 結果 検証の結果、N2 の SKU は 3/1 に記録されました。C3 の SKU は 3/2 に記録されました。 よって、課金レポートのタイムゾーンは PST（太平洋標準時）であることが確かになりました。 つまり、日本時間の 2025/03/03 1:00 に使用した Google Cloud リソースの課金は、課金レポート上は 2025/03/02（8:00）として表記されることになります。 検証結果 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の kiharu です。当記事では、Google Apps Script のトリガーイベント 「編集」と「変更」の違いについて解説します。 はじめに Google Apps Scriptとは GAS のトリガー 検知できるイベントタイプ 「編集」と「変更」の違い 検知する操作 ユーザーのアクセス 取得できる情報 使用シーンごとの使い分け 編集 変更 はじめに Google Apps Scriptとは Google Apps Script（以下、GAS） は、Google のサービス（Google スプレッドシート、ドキュメント、スライドなど）を自動化、拡張できるクラウドベースのプラットフォームです。 JavaScript ベースで、Google アプリケーションと連携したカスタム機能を簡単に作成できます。 参考 : Apps Script GAS のトリガー トリガー とは、GAS のスクリプトが実行される契機となる設定です。トリガーを設定することで、Google スプレッドシートの値が変更されたときや、特定の時刻になったときなど、指定したイベントを契機として自動的にスクリプトが実行されます。 GAS のトリガーには大きく分けて以下の2種類あります。 シンプルなトリガー インストール可能なトリガー どちらも特定のイベントに基づいてスクリプトを自動実行しますが、以下のように使い方と特徴が異なります。 table { border-collapse: collapse; } th { border: solid 1px #666666; color: #000000; background-color: #efefef; } td { border: solid 1px #666666; color: #000000; background-color: #ffffff; } シンプルなトリガー インストール可能なトリガー 使い方 用途に応じた関数名のいずれかを 使用して関数を作成する （onOpen、onEdit など） ユーザーが明示的に設定画面から 設定する 特徴 スプレッドシート等を操作しているユーザーのアカウントで実行される 常にトリガー設定時に認証したユーザーのアカウントで実行される インストール可能なトリガーでは、新規トリガーを設定する際の最初の1回だけ、認証が求められます。トリガーが起動すると、設定時に認証したユーザーのアカウントの認証情報でスクリプトが実行されます。 参考 : シンプルなトリガー 参考 : インストール可能なトリガー 検知できるイベントタイプ 「シンプルなトリガー」と「インストール可能なトリガー」では、検知できるイベントが異なります。 例えば、スプレッドシートでの「変更」イベントはシンプルなトリガーでは検知できず、インストール可能なトリガーで定義する必要があります。当記事では、その中でも「編集」と「変更」の違いについて解説します。 参考 : 使用可能なトリガーの種類 「編集」と「変更」の違い 「編集」と「変更」、この２つの言葉だけをみて具体的に使い分けるのは難しいと思います。以下に違いをまとめました。 table { border-collapse: collapse; } th { border: solid 1px #666666; color: #000000; background-color: #efefef; } td { border: solid 1px #666666; color: #000000; background-color: #ffffff; } 編集 変更 検知する操作 スプレッドシートの "値" を変更したとき スプレッドシートの "構成" を変更したとき ユーザーのアクセス 要 不要 取得できる情報 * 認証モード * トリガーが検知されたファイル * 検知したトリガーID * どのユーザー権限で実行されたか * 編集前のセル値 * 編集後のセルの値 * 編集されたセルまたは範囲 * 認証モード * トリガーが検知されたファイル * 検知したトリガーID * どのユーザー権限で実行されたか * 変更の種類（行追加、値の変更など） 参考 : イベント オブジェクト 検知する操作 「編集」イベントは、セルの値が変更されたときのみ検知されます。 一方で「変更」イベントは、スプレッドシートの様々な構成の変更（セルの値の変更に加え、行の追加、文字色の変更 など）がされたときに検知します。 ユーザーのアクセス 「編集」イベントは、ユーザーがスプレッドシートにアクセスしているときにのみ検知されます。逆に、 システムによる変更では検知されません。 「変更」イベントは、ユーザーのアクセスは必須ではありません。ユーザーによる変更と、システムによる変更のどちらも検知されます。 取得できる情報 「編集」イベントでは セルの値の変更情報 が検知されます。 一方の「変更」イベントでは、 スプレッドシートの変更情報 （セルの値の変更に加え、行の追加、文字色の変更など）を取得できます。 使用シーンごとの使い分け まず、ユーザーによる変更を検知したいか、システムによる変更を検知したいかで判断します。 さらに、検知したい変更の種類と、必要な情報の種類で使い分けると良いでしょう。 編集 「編集」イベントは、ユーザーがシート内のセルを直接編集したときに検知し、変更前後の値を取得できるため、以下のようなユースケースで使用できます。 セルの値を変更したユーザーと、値の変更内容を通知する セルの値が特定の範囲外の場合に警告を表示する ユーザーが入力した値に基づいて計算式を判別し、結果を反映する 変更 「変更」イベントは、ユーザーによる変更、外部スクリプトや他の自動化ツールによる変更のどちらでも検知するため、以下のようなユースケースで使用できます。 システムで新しくデータが追加されたことを通知する シートの名前変更を監視する システムがデータを変更したら自動で再計算し、結果を反映する kiharu (記事一覧) クラウドソリューション部 クラウドエンジニアリング課。 2024年8月G-genにジョイン。 手芸好きなエンジニアです。Follow @kiharuco_

G-gen の佐々木です。当記事では、BigQuery の 外部データセット として Spanner データベース内のテーブルを参照する方法を解説します。 前提知識 BigQuery Spanner BigQuery と Spanner の連携 2つの連携方法 連携クエリとは 外部データセットとは 連携クエリと外部データセットの比較 制限事項 BigQuery から Spanner へのリバース ETL 手順 Spanner の準備 インスタンス、データベースの作成 テーブルの作成 データの挿入 外部データセットの作成 外部データセットに対するクエリ実行 前提知識 BigQuery BigQuery は Google Cloud における代表的なサービスの1つであり、高パフォーマンスかつ自動でスケールするフルマネージドの分析用データベース（データウェアハウス）を従量課金で利用することができます。 参考： BigQuery BigQuery の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp Spanner Spanner は、Google Cloud のフルマネージド RDB（リレーショナルデータベース）サービスです。強整合性を保証する RDB の特徴と、グローバルに水平スケーリングできる NoSQL データベースの特徴を併せ持つ、強力な分散データベースを利用することができます。 参考： Spanner Spanner の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp BigQuery と Spanner の連携 2つの連携方法 BigQuery から Spanner データベース内のデータにアクセスするには、以下の2通りの方法が使用できます。いずれの方法でも、Spanner から BigQuery にデータを移動することなく、Spanner 上のテーブルに対する 読み取り専用 のアクセスが提供されます。 連携クエリ （Federated query） 外部データセット （External dataset または Federated dataset） 連携クエリとは BigQuery の 連携クエリ とは、 EXTERNAL_QUERY 関数を用いて、Spanner や Cloud SQL などの外部テーブルに SQL を実行できる機能です。Spanner、Cloud SQL、AlloyDB for PostgreSQL、SAP Datasphere（プレビュー）に対応しています。 連携クエリ を使うには、まず BigQuery で 接続 （connections）というリソースを作成し、Spanner などの外部データベースに対する接続設定を行います。クエリする際は、 EXTERNAL_QUERY 関数を使用して、テーブルを指定したクエリを実行します。 連携クエリでは、BigQuery の GUI である BigQuery Studio から Spanner 等の外部データベースのテーブル一覧やスキーマ情報は閲覧できません。 参考 : 連携クエリの概要 参考 : Spanner federated queries 外部データセットとは 当記事で紹介する BigQuery の 外部データセット とは、Spanner のデータベース全体を BigQuery と連携し、テーブル一覧やスキーマ情報の閲覧を可能にするほか、BigQuery から Spanner への読み取りクエリを可能にする機能です。 外部データセットを設定するには、まず CREATE EXTERNAL SCHEMA でステートメントで BigQuery に外部データセットを作成します。外部データセットは通常の BigQuery データセット同様に、BigQuery Studio から直接テーブルやスキーマを確認することができ、クエリを実行する際は FROM 句で直接指定することができます。 外部データセットは BigQuery Studio 上でスキーマを確認できる 参考： Create Spanner external datasets Spanner 上のデータに対するクエリは Spanner Data Boost を使用して実行されます（連携クエリの場合は任意で使用）。これにより、Spanner インスタンスのコンピュートリソースを使用することなく、つまり Spanner のパフォーマンスに影響を与えることなく BigQuery にデータを連携することができます。 参考 : Data Boost の概要 連携クエリと外部データセットの比較 連携クエリと外部データセットの違いを簡単にまとめると以下のとおりです。 連携クエリ 外部データセット 利用方法 BigQuery で 接続 を作成し EXTERNAL_QUERY 関数で Spanner データベース内のテーブルを指定してクエリを実行 BigQueryで 外部データセット を作成し FROM 句で外部データセット内のテーブルを指定してクエリを実行 必要な IAM ロール ・Cloud Spanner データベース読み取り（roles/spanner.databaseReader） ・BigQuery 接続ユーザー（roles/bigquery.connectionUser） ・Cloud Spanner Database 読み取りと DataBoost（roles/spanner.databaseReaderWithDataBoost） 使用できる SQL ・Google 標準 SQL ・PostgreSQL 互換 ※レガシー SQL は使用不可 ・Google 標準 SQL ・レガシー SQL Spanner Data Boost 任意で有効化 常に使用される GUI でスキーマ確認 ×（information_schema ビューで確認可能） ○ 料金 ・BigQuery のクエリ料金（オンデマンドの場合・ 参考 ） ・Spanner Data Boost の料金（有効化する場合・ 参考 ） ・BigQuery のクエリ料金（オンデマンドの場合） ・Spanner Data Boost の料金 外部データセットは接続リソースを作成しないため、設定方法やクエリがシンプルです。BigQuery と Spanner の連携を検討する場合、まずは外部データセットの利用を検討し、制限事項が問題となる場合に連携クエリを利用するとよいでしょう。 制限事項 連携クエリには以下のような制限事項があります。 クエリは読み取り専用。DML、DDL ステートメントはサポートされない BigQuery でサポートされていないデータ型の列を含むクエリは失敗する（サポートされているデータ型へのキャストは可能） 顧客管理の暗号鍵（CMEK）を使用する場合、BigQuery と Spanner のそれぞれに設定する必要がある 外部データセットでは上記に加えて、さらに以下の制限が追加されます。 BigQuery でサポートされていないデータ型の列にはアクセスできない 名前付きスキーマを使用する Spanner のテーブルにはアクセスできない 行レベルのセキュリティ、列レベルのセキュリティ、データ マスキングは使用できない Spanner 外部データセットのテーブルに基づくマテリアライズドビューは使用できない 詳細は、以下の公式ドキュメントも参照してください。 参考 : 連携クエリの概要 - 制限事項 参考 : Spanner 外部データセットを作成する - 制限事項 BigQuery から Spanner へのリバース ETL 外部データセットを使うことで、BigQuery から Spanner のデータを取得するだけではなく、BigQuery 上のテーブルを Spanner データベースにエクスポートすることもできます。 これにより、Spanner 外部データセットからデータを抽出して BigQuery 上で大規模な変換処理を行い、変換後のデータを Spanner に書き戻してアプリケーションから利用する リバース ETL を実現することができます。 以下のように EXPORT DATA OPTIONS ステートメントを使用することで、BigQuery から Spanner へのエクスポートを行うことができます。 /* BigQuery から Spanner へのリバース ETL */ EXPORT DATA OPTIONS ( uri= " https://spanner.googleapis.com/projects/<プロジェクトID>/instances/<Spannerインスタンス名>/databases/<Spannerデータベース名> " , format= ' CLOUD_SPANNER ' , spanner_options= """ { "table" : " <Spanner上の宛先テーブル> " } """ ) AS SELECT * FROM `<BigQuery上のソーステーブル>`; この機能は BigQuery Enterprise エディション もしくは Enterprise Plus エディション でのみ利用可能です。 参考： Export data to Spanner (reverse ETL) 手順 Spanner の準備 インスタンス、データベースの作成 まず、Spanner のインスタンスを作成します。当記事では東京リージョンを使用し、最小のコンピュートリソースである100処理ユニットでインスタンスを作成します。 # Spanner インスタンスを作成する $ gcloud spanner instances create < インスタンス名 > \ --config = regional-asia-northeast1 \ --description =" Test Instance " \ --processing-units = 100 作成したインスタンスを指定してデータベースを作成します。 データベースを BigQuery の外部データセットとして利用する場合、言語（dialect）は Google 標準 SQL にする必要があります。 # Spanner インスタンス内にデータベースを作成する $ gcloud spanner databases create < データベース名 > \ --instance =< インスタンス名 > \ --database-dialect = GOOGLE_STANDARD_SQL テーブルの作成 ここからは Google Cloud コンソールを使用して、作成したデータベースの Spanner Studio から操作を行います。 以下のクエリを実行し、Spanner データベースにテーブルを作成します。 /* テーブルを2つ作成する */ CREATE TABLE Singers ( SingerId INT64 NOT NULL , FirstName STRING( 1024 ), LastName STRING( 1024 ), SingerInfo BYTES( MAX ) ) PRIMARY KEY (SingerId); CREATE TABLE Albums ( SingerId INT64 NOT NULL , AlbumId INT64 NOT NULL , AlbumTitle STRING( MAX ) ) PRIMARY KEY (SingerId, AlbumId), INTERLEAVE IN PARENT Singers ON DELETE CASCADE; Spanner Studio でクエリを実行する データの挿入 作成した各テーブルにデータを挿入します。 /* 各テーブルにデータを挿入する */ INSERT INTO Singers (SingerId, FirstName, LastName) VALUES ( 1 , ' Marc ' , ' Richards ' ), ( 2 , ' Catalina ' , ' Smith ' ), ( 3 , ' Alice ' , ' Trentor ' ), ( 4 , ' Lea ' , ' Martin ' ), ( 5 , ' David ' , ' Lomond ' ); INSERT INTO Albums (SingerId, AlbumId, AlbumTitle) VALUES ( 1 , 1 , ' Total Junk ' ), ( 1 , 2 , ' Go, Go, Go ' ), ( 2 , 1 , ' Green ' ), ( 2 , 2 , ' Forever Hold Your Peace ' ), ( 2 , 3 , ' Terrified ' ); 外部データセットの作成 ここからは BigQuery Studio で作業を実施します。 CREATE EXTERNAL SCHEMA ステートメントを使用することで、BigQuery の外部データセットを作成することができます。 OPTIONS で参照先となる Spanner データベースを指定します。 /* BigQuery で Spanner 外部データセットを作成する */ CREATE EXTERNAL SCHEMA `<プロジェクトID>.<作成する外部データセットの名前>` OPTIONS ( external_source = ' google-cloudspanner:/projects/<プロジェクトID>/instances/<Spannerインスタンス名>/databases/Spannerデータベース名 ' , location = ' asia-northeast1 ' ); 上記のクエリを実行すると、Spanner データベースに存在する2つのテーブルを含む Spanner 外部データセットが作成されます。 Spanner データベースをソースとした外部データセット 外部データセットに対するクエリ実行 外部データセットに対するクエリを実行するには、通常の BigQuery データセットに対するクエリと同様に、FROM 句でデータセットとテーブルを指定します。 以下のクエリでは、Spanner データベース内の2つのテーブルを結合する SELECT クエリを実行します。 /* Spanner 外部データセット内のテーブルにクエリを実行する */ SELECT s.FirstName, s.LastName, a.AlbumTitle FROM `<プロジェクトID>.<外部データセットの名前>.Singers` AS s JOIN `<プロジェクトID>.<外部データセットの名前>.Albums` AS a ON s.SingerId = a.SingerId; 外部データセットに対してクエリを実行する 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

記事の移行について 当記事は移行しました Google Agentspace は、2025年10月に Gemini Enterprise に名称を変更して一般公開されました。 これに伴い、Gemini Enterprise についての解説記事は、以下のページに移行されました。 blog.g-gen.co.jp window.addEventListener('DOMContentLoaded', () => { const canonicalUrl = "https://blog.g-gen.co.jp/entry/gemini-enterprise-explained"; let canonicalLink = document.querySelector('link[rel="canonical"]'); if (!canonicalLink) { canonicalLink = document.createElement('link'); canonicalLink.setAttribute('rel', 'canonical'); document.head.appendChild(canonicalLink); } canonicalLink.setAttribute('href', canonicalUrl); }); 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では Spanner の 階層型ストレージ（tiered storage） 機能について解説します。 Spanner とは 階層型ストレージについて 概要 ストレージの選択 ローカリティグループ 階層型ストレージを使用する方法 ローカリティグループの作成 SSD のみを使用するローカリティグループ HDD のみを使用するローカリティグループ 時間経過でデータを HDD に移動するローカリティグループ 既存のローカリティグループの設定を変更する場合 ローカリティグループの紐付け データベースレベルの設定 テーブルレベルの設定 列レベルの設定 セカンダリインデックスレベルの設定 Spanner とは Spanner は、強整合性を保証する RDB（リレーショナルデータベース）の特徴と、グローバルに水平スケーリングできる NoSQL データベースの特徴を併せ持つ、フルマネージドな RDB サービスです。 参考 : Spanner Spanner の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp 階層型ストレージについて 概要 Spanner に保存されるデータは、デフォルトでは SSD（solid state drive）に保存され、高スループット、低レイテンシのデータアクセスが可能となっています。 階層型ストレージ 機能を用いると、データのアクセス頻度などに応じて、データの保存先として SSD もしくは安価なストレージである HDD （hard disk drive）を利用できるようになります。いずれの保存先を利用していても、データアクセスの方法やバックアップに影響はありません。 データ保存先のストレージタイプは、以下のレベルで設定することができます。たとえばクエリで取得する頻度の低い列に対して HDD を使用するように設定することで、データ保存のコストを節約することができます。 データベース テーブル 列 セカンダリインデックス 階層型ストレージは Spanner Enterprise エディションおよび Enterprise Plus エディションで使用できる機能です。 エディション 階層型ストレージの使用可否 Standard × Enterprise ○ Enterprise Plus ○ また、当機能は Google 標準 SQL 言語データベースと PostgreSQL 言語データベースの両方でサポートされています。 参考： Tiered storage overview ストレージの選択 階層型ストレージを利用すると、データを最初から SSD もしくは HDD に保存されるように設定できるほか、 最初は SSD に保存しておき、一定期間経過後に HDD に移動する こともできます。これは古いデータがあまりアクセスされないようなユースケースにおいてコスト節約に役立ちます。 選択できるストレージタイプには以下のような違いがあります。基本的には SSD の利用が推奨されています。 SSD HDD 特徴 秒間クエリ数（QPS）が多く、ほとんどのユースケースでパフォーマンスが高い。 費用対効果が高い。 ストレージの費用が安い。 ユースケース 書き込み、読み取りに高スループット、低レイテンシが要求されるデータセット レイテンシの影響を受けにくい大規模データセット、またはアクセス頻度が低いデータセット 単一リージョン構成時の予想スループット（ノードあたり） 読み取り：最大 22,500 QPS 書き込み：最大 3,500 QPS 読み取り：最大 1,500 QPS 書き込み：最大 3,500 QPS デュアルリージョン・マルチリージョン構成時の予想スループット（ノードあたり） リージョンあたり 読み取り：最大 15,000 QPS 書き込み：最大 2,700 QPS リージョンあたり 読み取り：最大 1,000 QPS 書き込み：最大 2,700 QPS サポートされるオペレーション 読み取り、書き込み、更新、削除 読み取り、書き込み、更新、削除 1GBあたりの料金（東京リージョンの場合） $0.00053/hour $0.00011/hour 参考： Spanner pricing - Storage ローカリティグループ 階層型ストレージを利用するには、利用するストレージタイプを指定した ローカリティグループ （Locality groups）を作成し、それをテーブルや列に紐付ける必要があります。ローカリティグループは、Spanner ストレージ内でテーブルや列のデータの分離を行うための機能で、同じローカリティグループのデータは物理的に近くに配置されます。 ユーザーがローカリティグループを作成していないデフォルトの状態では、すべてのデータが default ローカリティグループに含まれ、SSD に保存されます。 参考： Schemas overview - Schema examples - Locality groups 階層型ストレージを使用する方法 ローカリティグループの作成 階層型ストレージを利用するには、まず使用するストレージを指定したローカリティグループを作成する必要があります。ローカリティグループは CREATE LOCALITY GROUP DDL ステートメントを使用して作成することができます。 参考： Create and manage locality groups - Create a locality group 参考： GoogleSQL data definition language - LOCALITY GROUP statements 参考： PostgreSQL data definition language - LOCALITY GROUP statements SSD のみを使用するローカリティグループ SSD ストレージのみにデータを保存するローカリティグループは以下のように作成します。default ローカリティグループ同様、このローカリティグループを紐付けたテーブルや列などのデータは SSD に保存されます。 # Google 標準 SQL の場合 CREATE LOCALITY GROUP <グループ名> OPTIONS (storage= ' ssd ' ); # PostgreSQL 互換の場合 CREATE LOCALITY GROUP <グループ名> STORAGE ' ssd ' ; HDD のみを使用するローカリティグループ HDD ストレージのみにデータを保存するローカリティグループは以下のように作成します。このローカリティグループを紐付けたテーブルや列などのデータは HDD に保存されます。 # Google 標準 SQL の場合 CREATE LOCALITY GROUP <グループ名> OPTIONS (storage= ' hdd ' ); # PostgreSQL 互換の場合 CREATE LOCALITY GROUP <グループ名> STORAGE ' hdd ' ; 時間経過でデータを HDD に移動するローカリティグループ 以下のステートメントでは、 最初の10日間はデータを SSD に保存し、その後 HDD に移動する ローカリティグループを作成します。 # Google 標準 SQL の場合 CREATE LOCALITY GROUP <グループ名> OPTIONS (storage = ' ssd ' , ssd_to_hdd_spill_timespan = ' 10d ' ); # PostgreSQL 互換の場合 CREATE LOCALITY GROUP <グループ名> STORAGE ' ssd ' SSD_TO_HDD_SPILL_TIMESPAN ' 10d ' ; HDD に移動するまでの時間は最小で1時間（ 1h ）、最大で365日（ 265d ）となっています。 通常は、指定した時間から7日間の間に行われるデータの圧縮サイクル内でストレージの移行が行われるため、指定した時間が経過してもすぐに移行が行われるわけではありません。 既存のローカリティグループの設定を変更する場合 ALTER LOCALITY GROUP DDL ステートメントを使用することで、ローカリティグループの設定を変更することができます。 たとえば、以下のステートメントでは、指定したローカリティグループで使用するストレージを HDD に変更します。 # Google 標準 SQL の場合 ALTER LOCALITY GROUP <グループ名> SET OPTIONS (storage= ' hdd ' ); # PostgreSQL 互換の場合 ALTER LOCALITY GROUP <グループ名> STORAGE ' hdd ' ; ローカリティグループの紐付け CREATE TABLE または ALTER TABLE DDL を使用して、作成したローカリティグループをテーブルや列に紐付けることで、階層型ストレージを利用できるようにします。 参考： Create and manage locality groups - Set a tiered storage policy for your data データベースレベルの設定 デフォルトでは default ローカリティグループがデータベース全体に適用されており、データベース内のすべてのデータが SSD に保存されるようになっています。データベースレベルで階層型ストレージの設定をする場合、この default ローカリティグループを ALTER LOCALITY GROUP で変更します。 default ローカリティグループを指定する場合、Google 標準 SQL の場合は `default` 、PostgreSQL 互換の場合は "default" のように文字列を囲む必要があります。 # Google 標準 SQL の場合 ALTER LOCALITY GROUP ` default ` SET OPTIONS (storage = ' ssd ' , ssd_to_hdd_spill_timespan = ' 10d ' ); # PostgreSQL 互換の場合 ALTER LOCALITY GROUP " default " STORAGE ' ssd ' SSD_TO_HDD_SPILL_TIMESPAN ' 10d ' ; 上記のステートメントにより、データベース内のすべてのデータにおいて、 最初の10日間はデータを SSD に保存し、その後 HDD に移動する 設定が適用されます。 テーブルレベルの設定 CREATE TABLE ステートメントでテーブルを作成する際に、テーブル全体に対してローカリティグループを設定できます。以下の例では、Singers テーブル全体にローカリティグループを設定しています。 # Google 標準 SQL の場合 CREATE TABLE Singers ( SingerId INT64 NOT NULL , FirstName STRING( 1024 ), LastName STRING( 1024 ), SingerInfo BYTES( MAX ) ) PRIMARY KEY (SingerId), OPTIONS (locality_group = ' <グループ名> ' ); # PostgreSQL 互換の場合 CREATE TABLE Singers ( SingerId bigint PRIMARY KEY, FirstName varchar ( 1024 ), LastName varchar ( 1024 ), SingerInfo bytea ) LOCALITY GROUP <グループ名>; テーブルレベルのローカリティグループを変更する場合、 ALTER TABLE ステートメントを使用します。 # Google 標準 SQL の場合 ALTER TABLE Singers SET OPTIONS (locality_group = ' <グループ名> ' ); # PostgreSQL 互換の場合 ALTER TABLE Singers SET LOCALITY GROUP <グループ名>; 列レベルの設定 列レベルでは、 CREATE TABLE ステートメント内で列に対して個別にローカリティグループを指定します。以下の例では、Singers テーブル全体に加え、 Awards 列に別のローカリティグループを設定しています。 # Google 標準 SQL の場合 CREATE TABLE Singers ( SingerId INT64 NOT NULL , FirstName STRING( 1024 ), LastName STRING( 1024 ), Awards ARRAY<STRING( MAX )> OPTIONS (locality_group = ' <列レベルのグループ名> ' ) ) PRIMARY KEY (SingerId), OPTIONS (locality_group = ' <テーブルレベルのグループ名> ' ); # PostgreSQL 互換の場合 CREATE TABLE Singers ( SingerId bigint PRIMARY KEY, FirstName varchar ( 1024 ), LastName varchar ( 1024 ), Awards varchar [] LOCALITY GROUP <列レベルのグループ名> ) LOCALITY GROUP <テーブルレベルのグループ名>; 列レベルのローカリティグループを変更する場合、 ALTER TABLE と ALTER COLUMN を使用します。 # Google 標準 SQL の場合 ALTER TABLE Singers ALTER COLUMN LastName SET OPTIONS(locality_group = ' <グループ名> ' ); # PostgreSQL 互換の場合 ALTER TABLE Singers ALTER COLUMN LastName SET LOCALITY GROUP <グループ名>; セカンダリインデックスレベルの設定 セカンダリインデックスレベルでは、 CREATE INDEX ステートメント内でセカンダリインデックスに対して個別にローカリティグループを指定します。以下の例では、SingersByFirstLastName というセカンダリインデックスにローカリティグループを設定しています。 # Google 標準 SQL の場合 CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName) OPTIONS (locality_group = ' <グループ名> ' ); # PostgreSQL 互換の場合 CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName) LOCALITY GROUP <グループ名>; セカンダリインデックスレベルのローカリティグループを変更する場合、 ALTER INDEX を使用します。 # Google 標準 SQL の場合 ALTER INDEX SingersByFirstLastName SET OPTIONS(locality_group = ' <グループ名> ' ); # PostgreSQL 互換の場合 ALTER INDEX SingersByFirstLastName SET LOCALITY GROUP <グループ名>; 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。BigQuery の 外部テーブル （external tables）機能で Google スプレッドシートのデータを BigQuery からクエリする方法について紹介します。 外部テーブルとは スプレッドシート サンプルシートの準備 共有リンクの取得 外部テーブルの定義 SQL（DDL） 解説 シート指定の注意点 クエリ アクセス権限 Google アカウントによるアクセス プログラムからのアクセス 外部テーブルとは 当記事では、BigQuery の 外部テーブル （external tables）機能で Google スプレッドシートのデータを BigQuery からクエリする方法について紹介します。 BigQuery の 外部テーブル （external tables）とは、BigQuery の外部にあるデータを BigQuery からクエリするために定義する、仮想的なテーブルです。データを BigQuery に複製することなく、外部にあるデータをクエリすることができます。外部テーブルは以下のデータソースに対応しています。 Cloud Storage Bigtable Google ドライブ（Google スプレッドシート、CSV、Newline delimited JSON、Avro） 外部テーブルを定義することにより、BigQuery にデータを転送することなく、外部のデータを直接クエリすることができます。外部テーブルにクエリした結果を BigQuery 内部のデータと JOIN することもできます。ただし、外部ストレージからデータを読み取るオーバーヘッドがあるため、パフォーマンスの面では BigQuery 内部のデータをクエリするよりも劣る可能性があります。 参考 : 外部テーブルの概要 また、外部テーブルの拡張として BigLake テーブル があります。BigLake テーブルでは、Cloud Storage、Amazon S3、Azure Blob Storage のデータをクエリすることができます。 参考 : BigLake テーブルの概要 外部テーブルや BigLake については、以下の記事も参考にしてください。 参考 : BigQueryを徹底解説！(応用編) - G-gen Tech Blog - 外部テーブル 参考 : BigQueryを徹底解説！(応用編) - G-gen Tech Blog - BigLake スプレッドシート サンプルシートの準備 当記事では、Google スプレッドシートにある従業員名簿を BigQuery からクエリして、BigQuery 内に保存してある他のデータと JOIN するようなユースケースを想定して、手順を紹介します。 以下は、Google スプレッドシートに作成した従業員名簿です。値は生成 AI で生成した架空のものです。 サンプルの従業員名簿 共有リンクの取得 のちに外部テーブルを定義するときに必要なため、このスプレッドシートの共有リンクを取得してください。リンクは、以下のような形式になります。 https://docs.google.com/spreadsheets/d/1M-DdfRdZKLwWKxxxxx/edit?usp=sharing なお、末尾の /edit?usp=sharing は削除しても構いません。また、スプレッドシートを開いた状態でブラウザの URL 欄から URL を取得しても構いません。このときも、末尾の /edit 以降は削除して構いません。 外部テーブルの定義 SQL（DDL） 当記事では、SQL（DDL）を用いてテーブルを定義してみます。コンソール画面からでもテーブルの定義は可能ですが、SQL を作っておけば列名の試行錯誤などを楽に行うことができます。 参考 : 外部テーブルを作成する BigQuery Studio で以下の SQL を実行すると、スプレッドシートをデータソースとした外部テーブルが作成されます。プロジェクト名やデータセット名は、ご自身の環境のものに置き換えてください。 CREATE OR REPLACE EXTERNAL TABLE `my-project.my_dataset.employees` ( id INT64, name STRING, name_kana STRING, join_date DATE , email_address STRING, business_unit STRING, department STRING, division STRING, ) OPTIONS( uris=[ " https://docs.google.com/spreadsheets/d/1M-DdfRdZKLwWKxxxxx " ], format= " GOOGLE_SHEETS " , sheet_range= " 従業員名簿!A:H " , skip_leading_rows= 1 ); 解説 列名は、BigQuery のスキーマ命名ルールに則ったうえで、任意の文字列とすることができます。BigQuery には「柔軟な列名」機能があり、通常のテーブルであれば列名に記号やマルチバイト文字を使うことができますが、外部テーブルではサポートされていません。外部テーブルの列名には英字（a～z、A～Z）、数字（0～9）、アンダースコア（_）だけを使用できます。 参考 : スキーマの指定 次に、 OPTIONS の中身を解説します。 uris は、先ほど作成したスプレッドシートの URL（URI） です。末尾の /edit?usp=sharing は削除しても構いません。 format には GOOGLE_SHEETS を指定します。 sheet_range には、シート名と列範囲を指定できます。 (シート名)!(開始列):(終了列) の形式で指定します。これにより、スプレッドシートファイルに複数のシート（タブ）が含まれていても、任意のシートを取り込むことができます。 skip_leading_rows には、ヘッダなどをスキップする行数を記載します。通常は、スプレッドシートの表の最初の数行まではヘッダなどが記載されており、実データは途中から格納されているはずです。実データ以外はスキップします。 参考 : CREATE EXTERNAL TABLE statement シート指定の注意点 OPTIONS の sheet_range を省略すると、スプレッドシートのファイルの 一番左 に配置されているシートが読み取られます。日常業務でよく編集されるシートの場合、順番が入れ替わってしまう誤操作があり得ますので、シート名を明示することが望ましいといえます。 ただし、シート名が変更されてしまうと、データが読み取れなくなります。 スプレッドシート内のシート配置 また、スプレッドシートをブラウザで開いているときにブラウザの URL 欄に表示されるリンクは、開いているシートに応じたアンカー（ # ）が付与されています。ブラウザでこのアンカー付き URL を開くと任意のシートを開くことができますが、外部テーブル定義の DDL でこの URL を指定しても、任意のシートを読み取り対象とすることはできません。 sheet_range オプションでシート名で明示的に指定する必要があります。 アンカー付き URL の例 https://docs.google.com/spreadsheets/d/1M-DdfRdZKLwWKxxxxx/edit?gid=925071692#gid=925071692 クエリ 作成された外部テーブルは、通常のテーブルと同じようにクエリすることができます。BigQuery の通常のテーブルとの JOIN も可能です。 なお、スプレッドシートをデータソースとする外部テーブルに対するクエリは、常にフルスキャンとなります。パーティショニングやクラスタリングは利用できません。 SELECT * FROM `sugimura.my_dataset.employees` 外部テーブルに対するクエリ結果 アクセス権限 Google アカウントによるアクセス スプレッドシートをデータソースとする外部テーブルに対してクエリを行うには、外部テーブルとスプレッドシートの 両方に アクセス権限が必要です。 クエリを行うアカウントは、Google Cloud 側で以下のロールが必要です。 プロジェクトに対する BigQuery ユーザー（ roles/bigquery.user ）または BigQuery ジョブユーザー（ roles/bigquery.jobUser ） テーブルに対する BigQuery データ閲覧者（ roles/bigquery.dataViewer ） 加えて、対象のスプレッドシートに対して、 閲覧者 権限以上が必要です。 クエリ実行アカウントが、Google Cloud 側には権限を持っているものの、スプレッドシート側（Google ドライブ側）に権限を持っていない場合は、以下のようなエラーとなります。 Access Denied: BigQuery BigQuery: Permission denied while getting Drive credentials. アクセス権限エラー プログラムからのアクセス Cloud Run functions などで実行するプログラムからクライアントライブラリを用いて BigQuery の外部テーブルへクエリする際にも、前述のとおり、Google Cloud プロジェクト側とスプレッドシート側の両方に権限が必要です。 Cloud Run functions の関数等にアタッチしたサービスアカウントにこれらの権限を付与すれば、外部テーブルにアクセスすることができます。しかし、ソースコード内で BigQuery クライアントを生成する際に注意が必要です。 Python のクライアントライブラリから BigQuery の外部テーブルにクエリを投入する場合を例に取ります。通常、ソースコード内で BigQuery クライアントを生成する際は、以下のように記述します。 import google.cloud.bigquery client = google.cloud.bigquery.Client() しかし、この記述だと、Google Cloud プロジェクト側とスプレッドシート側の両方に正しく権限を付与しているのにもかかわらず、 403 Access Denied: BigQuery BigQuery: Permission denied while getting Drive credentials. というエラーメッセージが出力されます。 これは、クライアント生成時に認証情報のスコープが正しく設定されていないことに起因します。以下のように記述することで、 認証情報のスコープに Google ドライブが含まれる ようになり、エラーが解消します。 import google.cloud.bigquery credentials, project = google.auth.default( scopes=[ "https://www.googleapis.com/auth/drive" , "https://www.googleapis.com/auth/cloud-platform" , ] ) client = google.cloud.bigquery.Client(credentials=credentials, project=project) 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の三浦です。当記事では、 distroless という Google が提供するコンテナイメージを使って、イメージの脆弱性に対処する方法を紹介します。 distroless とは 検証の流れ 検証準備 ディレクトリ構成 Dockerfile main.py requirements.txt API の有効化 検証 Cloud Run のデプロイと脆弱性件数の確認 Dockerfile の変更（distroless 対応） Cloud Run の再デプロイと脆弱性件数の確認 distroless とは distroless は、Google が提供する Docker コンテナのベースイメージです。不要なコンポーネントを削除した最小限のイメージであり、セキュリティ上のメリットがあります。主な特徴は以下の通りです。 特徴 内容 攻撃対象領域を縮小 OS の不要なファイルやバイナリを削除することで、攻撃対象領域を小さくします。 イメージサイズを削減 イメージが軽量になり、デプロイや転送、コンテナ起動が高速になります。 セキュリティ向上 脆弱性の原因となる不要なコンポーネントを削除します。 distroless は、Ubuntu や Alpine などの汎用的なイメージと比較して、セキュリティに特化しています。 参考： distroless 検証の流れ 検証の流れは以下の通りです。 項番 項目 内容 1 検証準備 アプリケーションコードを準備し、必要な API を有効化します。 2 Cloud Run のデプロイと脆弱性件数の確認 まずは Python 3.12 slim を使用して Cloud Run にデプロイし、脆弱性があることを確認します。 3 Dockerfile の変更（distroless 対応） Dockerfile を distroless に対応するように変更します。 4 Cloud Run の再デプロイと脆弱性件数の確認 再度 Cloud Run にデプロイし、一部の脆弱性が解消されたことを確認します。 検証準備 ディレクトリ構成 ディレクトリ構成は以下の通りです。 . ├── Dockerfile ├── main.py └── requirements.txt Dockerfile 最初は、ベースイメージとして Python 3.12 slim を使用します。 # ベースイメージとして Python 3.12 slim を使用 FROM python:3.12-slim 　 # 環境変数を設定 ENV PYTHONDONTWRITEBYTECODE=1 ENV PYTHONUNBUFFERED=1 　 # 作業ディレクトリを設定 WORKDIR /app 　 # 必要な依存関係をインストール RUN apt-get update && apt-get install -y \ gcc \ && rm -rf /var/lib/apt/lists/* 　 # 必要な Python パッケージをインストール COPY requirements.txt /app/ RUN pip install --no-cache-dir -r requirements.txt 　 # アプリケーションコードをコンテナにコピー COPY . /app 　 # アプリケーションを実行 CMD [ " python ", " main.py " ] main.py 以下の Python コードを使用します。 from flask import Flask import os 　 app = Flask(__name__) 　 @ app.route ( "/" ) def hello (): return "Hello, Cloud Run!" 　 if __name__ == "__main__" : port = int (os.environ.get( "PORT" , 8080 )) app.run(host= "0.0.0.0" , port=port) requirements.txt flask API の有効化 イメージの脆弱性スキャンを行う Artifact Analysis の API と Cloud Run 等の各種 API を有効化します。 gcloud services enable \ artifactregistry.googleapis.com \ containerscanning.googleapis.com \ cloudbuild.googleapis.com \ run.googleapis.com 参考 : Artifact Analysis と脆弱性スキャン 検証 Cloud Run のデプロイと脆弱性件数の確認 環境変数を設定し、Cloud Run をデプロイします。 # 環境変数の設定 export SERVICE_NAME =test-app # イメージと Cloud Run サービス名 　 # Cloud Run のデプロイ gcloud run deploy $SERVICE_NAME --source . \ --region = asia-northeast1 \ --allow-unauthenticated Y を入力して Enter を実行すると、Artifact Registry のリポジトリ (cloud-run-source-deploy) が自動的に作成されます。 # 出力例 Deploying from source requires an Artifact Registry Docker repository to store built containers. A repository named [ cloud-run-source-deploy ] in region [ asia-northeast1 ] will be created. 　 Do you want to continue ( Y/n ) ? Y デプロイが完了したら、Cloud Run の URL にアクセスし、Web ページが表示されることを確認します。 # 出力例 Service [ test-app ] revision [ test-app-XXXXXX-XXX ] has been deployed and is serving 100 percent of traffic. Service URL: https://xxx-xxx-xxxxxx.asia-northeast1.run.app # Cloud Run の URL 表示確認（Python 3.12 slim） Google Cloud コンソールにログインし、検索バーに Artifact Registry と入力し、[ Artifact Registry ] を選択します。 Artifact Registry を選択 [cloud-run-source-deploy] > [イメージ名] へ移動し、表示されている脆弱性の件数を確認します。例では、591 件の脆弱性を確認しています。 脆弱性の件数確認（Python 3.12 slim） 名前の部分を選択し、 仮想サイズ からイメージの容量を確認します。例では、138MB です。 容量確認（Python 3.12 slim） [脆弱性]タブで、重大度に応じた件数などの詳細を確認できます。 詳細確認（Python 3.12 slim） 参考 : Google Cloud コンソールで発生を表示する Dockerfile の変更（distroless 対応） Dockerfile を以下の通りに変更します。この変更では、ビルド用のイメージと実行用のイメージを分離し、distroless イメージを使用します。 # ビルド用イメージ FROM python:3.12-slim AS builder 　 # 必要なパッケージをインストール WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir --target = /app/libs -r requirements.txt 　 # アプリケーションコードをコピー COPY main.py /app/ 　 # 実行用の Distroless イメージ FROM gcr.io/distroless/python3-debian12 　 # アプリケーションファイルをコピー WORKDIR /app COPY --from=builder /app/libs /app/libs COPY --from=builder /app/main.py /app/main.py 　 # Pythonのライブラリパスを設定 ENV PYTHONPATH=/app/libs 　 # Python実行環境をENTRYPOINTで指定し、アプリケーションファイルをCMDで指定 ENTRYPOINT [ " /usr/bin/python3 " ] CMD [ " /app/main.py " ] これは Multi-stage builds という方式であり、ビルド用途と実行環境用途で異なるベースイメージを使用しています。 参考 : Multi-stage builds 参考 : distroless / README.md Cloud Run の再デプロイと脆弱性件数の確認 初回と同様に Cloud Run をデプロイします。 gcloud run deploy $SERVICE_NAME --source . \ --region = asia-northeast1 \ --allow-unauthenticated　 Cloud Run の URL にアクセスし、Web ページが表示されることを確認します。 表示確認（distroless） イメージの脆弱性件数を確認します。例では 21 件となり、先ほどの 591 件と比較して大幅に減っています。 脆弱性の件数確認（distroless） 同様に容量を確認します。例では 20.7MB となり、先ほどの 138MB と比較して大幅に減っています。 容量確認（distroless） 脆弱性の詳細は以下の通りです。 詳細確認（distroless） 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の三浦です。当記事では、Google Workspace の Google Vault（以下、Vault）を使用して、データ管理やコンプライアンス対応に役立つ方法を紹介します。 概要 Google Vault とは 前提条件 検証内容 動作確認 事前設定 データ保持ルールの設定 案件の作成とデータの検索（Gmail、Gemini） 記録保持（リティゲーションホールド）の設定 概要 Google Vault とは Google Vault は、Gmail、Google Chat などの特定の Google Workspace サービスに含まれるデータを保持・管理するツールです。 主にデータの保持、検索、エクスポートを通じて、法的要件への対応やコンプライアンス管理をサポートします。 機能 利用例 データ保持ポリシーの設定 法的要件に基づき、全従業員のメールデータを7年間保持し、退職後も取引に関する証拠を調査可能。 検索・エクスポート機能 件名に「社外秘」を含むメールや特定の宛先のメールを検索し、情報漏洩リスクを確認し適切に対応。 参考 : Google Vault について Vault に対応しているサービスの詳細は、以下ドキュメントをご確認ください。 参考 : サポートされているサービスとデータタイプ 前提条件 Vault は、Google Workspace の以下のエディションで標準提供されています。 Frontline Standard Business Plus Enterprise Standard、Enterprise Plus、Enterprise Essentials、Enterprise Essentials Plus（ドメインの所有権証明済みのもののみ） すべての Education エディション G Suite Business 上記以外の特定エディションに関しては、 Vault アドオンライセンス を適用することで利用できます。詳細は以下ドキュメントをご確認ください。 参考 : Google Vault に関するよくある質問 検証内容 以下の手順で Vault を設定し、動作を確認します。 項番 設定内容 説明 1 事前設定 Vault を利用するための推奨設定を実施。 2 データ保持ルールの設定 Gmail の保持期間を定義するルールを作成。 3 案件の作成と検索（Gmail、Gemini アプリ） 案件を作成し、Gmail と Gemini アプリの利用状況を検索。 4 記録保持（リティゲーションホールド）の設定 訴訟や監査を想定し、Vault で管理される特定のユーザーのデータが削除されないように記録保持を適用。 動作確認 事前設定 Google Workspace の管理コンソール（ https://admin.google.com ）にログインします。 参考 : 管理コンソールにログインする [アプリ] > [Google Workspace] > [Gmail] > [コンプライアンス] へ移動します。 コンプライアンスへ移動 以下のとおりに設定し、メールデータが保持されるようにします。 メールとチャットの自動削除 ： メールとチャット メッセージを自動削除しない。 包括的なメール ストレージ ： 関連付けられているユーザーのメールボックスに、すべての送受信メールのコピーを保存します。 メールとチャットの自動削除 包括的なメールストレージ 今回は Gmail の設定を行いましたが、Google Chat や Google グループのデータを保持する場合も、同様の推奨事項があります。詳細は以下ドキュメントをご確認ください。 参考 : 組織向けに Vault を設定する データ保持ルールの設定 Vault の管理コンソール（ http://vault.google.com ）にログインします。 参考 : Vault にログインする [保持] を選択します。 保持を選択 データ保持ルールは以下の2種類があり、まずデフォルトのルールを設定します。 ルール種別 利用例 デフォルトのルール 法的要件に基づき、全従業員のメールデータを 7 年間保持。 カスタムルール 特定の部門の従業員のメールデータを無期限で保持。 カスタムルールはデフォルトのルールよりも優先されます。 参考 : 保持ルールと記録保持（リティゲーション ホールド）を管理する 参考 : データ保持の仕組み [Gmail] を選択します。 Gmailを選択 以下のとおりに設定し、[保存] を選択します。 期間 ：保持期間 日数 ：保持する日数 適用期間終了後の操作 ：保持要件に応じて以下のどちらかを選択 完全に削除済みのメールのみをパージする ：期間を過ぎた 削除済みメール または ゴミ箱のメール のみが削除 Gmail のメールボックス内のメールと完全に削除されたメールがパージされます。このルールにより下書きもパージされます。 ：期間を過ぎた 全てのメール が削除 デフォルトの保持ルール設定 内容を確認し、[承諾] を選択します。 注意事項の確認 デフォルトのルールが設定されていることを確認し、[カスタムルール] > [作成] を選択します。 デフォルトルールの設定確認 カスタムルールの作成 以下のとおりに設定し、[作成] を選択します。 ※ 本設定の場合、 miura-test という組織部門のメンバーのみメールが無期限で保持され、他部門のメンバーは、デフォルトの保持ルールで 2,555日 メールが保持されます。 サービス ：対象のサービス（今回は Gmail ）を選択 適用範囲 ：特定の組織部門を選択 条件（省略可） ：特定の期限（例. 2022/01/01～2022/12/31 ）や条件（例. 特定の宛先（ to:xxx@xxx.co.jp ））のメールのみを保持する場合に設定 期間と操作 ：無期限に保存するか、保持する期間を選択 カスタムルールの設定 案件の作成とデータの検索（Gmail、Gemini） [ホーム] > [案件] から [作成] を選択します。 案件を選択 作成を選択 以下を入力し、[作成] を選択します。 案件名 ：任意の名称を入力 説明 ：案件の説明（省略可） データ リージョン ：Vault のデータ保存地理を選択 案件の作成 [検索] で以下条件を入力し、[保存] を選択します。 サービス ：対象のサービス（今回は Gmail ）を選択 エンティティ ：すべてのアカウントか、特定ユーザーのメールアドレスを選択 送信日（省略可） ：特定の期間（例. 2022/01/01～2022/12/31 ）に送信したメールを検索する場合は選択 キーワード（省略可） ：特定の宛先（例. to:xxx@xxx.co.jp ）や件名（例. subject:社外秘 ）を指定してメールを検索する場合は選択 Gmailの検索 条件を満たした Gmail のメール情報が表示されることを確認します。[エクスポート] から検索結果のダウンロードも可能です。 Gmailの検索結果確認1 Gmailの検索結果確認2 参考 : Vault の書き出しに含まれる内容 次に、Gemini アプリの利用状況を検索します。クエリをクリアし、以下の条件で検索します。 サービス ：対象のサービス（今回は Gemini ）を選択 エンティティ ：特定の組織部門か、特定ユーザーのメールアドレスを選択 送信日（省略可） ：特定の期間（例. 2022/01/01～2022/12/31 ）の利用履歴を検索する場合は選択 Geminiの検索 Gemini アプリに入力したプロンプトと回答が表示されることを確認します。 Geminiの検索結果確認 記録保持（リティゲーションホールド）の設定 訴訟等を想定した記録保持を設定します。記録保持は、前手順で設定した データの保持ルールよりも優先される仕様 となります。 記録保持とデータの保持ルールの詳細な違いは、以下ドキュメントをご確認ください。 参考 : 記録保持（リティゲーション ホールド）と保持ルールの違いは何ですか？ [案件] > [記録保持] > [作成] を選択します。 記録保持の作成 以下条件を入力し、[作成] を選択します。 名前 ：任意の記録保持ルール名を入力 サービス ：対象のサービス（今回は Gmail ）を選択 適用範囲 ：特定の組織部門か、特定ユーザーのメールアドレスを選択 条件（省略可） ：特定の宛先（例. to:xxx@xxx.co.jp ）や件名（例. subject:社外秘 ）を満たしたメールのみを検索する場合は選択 記録保持の設定 記録保持（リティゲーションホールド）が適用されているユーザーは、[ホーム] > [レポート] から確認が可能です。 記録保持の確認1 記録保持の確認2 記録保持の確認3 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の佐々木です。当記事では、Google Cloud のサーバーレス コンテナコンピューティング サービスである Cloud Run で簡単なサービスを作成する方法を解説します。また、サービスの基本的な設定項目や、よく使用される機能や構成についても解説していきます。 Cloud Run について gcloud CLI の準備 Artifact Registry の準備 使用するコード（Python） 記事執筆時の環境について サンプルコードの構成 main.py requirements.txt Dockerfile コンテナイメージの準備 コンテナイメージの要件 ビルド環境について コンテナイメージのビルド イメージ名について ビルドとプッシュ Cloud Run サービスのデプロイ 最小限の設定でデプロイ 動作確認 「認証が必要」に設定した場合 デプロイ時のよくあるエラー デプロイ時の基本的な設定項目について 認証 Ingress CPU・メモリ・最大同時リクエスト数 最小インスタンス数 リクエストのタイムアウト サービスアカウント コンテナの環境変数 Cloud Run でよく使用される機能や構成 カスタムドメインの使用 サービスに対するアクセスの制御 機密情報の使用（パスワード・API キーなど） データベース サービスへの接続 Cloud Run が使用する外部 IP アドレスの固定 他の Cloud Run サービスへのプライベートアクセス Cloud Storage バケットのマウント Cloud Run について Cloud Run は Google Cloud のマネージドなコンテナ実行環境でアプリケーションを実行することができる、サーバレス コンテナコンピューティング サービスです。 Cloud Run には Cloud Run services 、 Cloud Run jobs 、 Cloud Run functions （旧称 : Cloud Functions）、 Cloud Run worker pools の4種類がありますが、当記事ではウェブアプリケーションの実行環境として主に利用される Cloud Run services の使い方を解説していきます。 当記事では以降、「 Cloud Run 」という記述は Cloud Run services を指します。 また、当記事の内容は、Cloud Run の基本的な使い方（始め方）に重点を置いた解説となるため、サービスの仕様に関する解説については以下の記事をご一読ください。 blog.g-gen.co.jp なお当記事は2025年3月に執筆したものであり、設定項目の名称やコンソールの画面構成は、現在のものと異なる場合があります。 gcloud CLI の準備 当記事は Cloud Run の入門記事ということで、GUI で可能な操作は Google Cloud コンソールを使用して解説を行います。 一部の操作については gcloud コマンドを使用するため、以下のドキュメントを参考に gcloud コマンドのインストールを行ってください。 参考 : Quickstart: Install the Google Cloud CLI  |  Google Cloud SDK  |  Google Cloud Documentation インストール後、以下のコマンドで、gcloud コマンドを実行する Google アカウントの認証を行ってください。 # gcloud コマンドのユーザー認証を行う $ gcloud auth login また、コマンド実行時に使用される、デフォルトのプロジェクトを設定しておきます。 # デフォルトのプロジェクトを設定する $ gcloud config set project { プロジェクトID } Artifact Registry の準備 まず、Google Cloud コンソールを使用して、Artifact Registry のリポジトリを作成します。 Artifact Registry は、コンテナイメージ等のビルドアーティファクトを管理するためのリポジトリを提供するサービスです。Cloud Run にデプロイするコンテナイメージは、Artifact Registry のリポジトリで管理されているものである必要があります。 Artifact Registry のコンソール で「リポジトリの作成」を押下します。 Artifact Registry コンソールからリポジトリを作成する 作成画面で任意の名前とリージョンを指定して、画面最下部の「作成」を押下します。当記事では myrepo という名前で asia-northeast1 リージョンにリポジトリを作成します。 リポジトリの作成画面 使用するコード（Python） 記事執筆時の環境について 当記事のサンプルコードは以下の環境を使用して動作を確認しています。 # OS $ head --l 1 /etc/os-release PRETTY_NAME = " Debian GNU/Linux 12 (bookworm) " # Python のバージョン $ python -V Python 3 . 12 . 0 # Google Cloud CLI のバージョン $ gcloud version | head --l 1 Google Cloud SDK 513 . 0 . 0 なお、当記事の内容は Python がインストールされていない環境でも実施することが可能です。 サンプルコードの構成 当記事では、 公式ドキュメント のサンプルコードを元にしたウェブアプリケーションを Cloud Run にデプロイしていきます。 サンプルコードとして、以下の3つのファイルを用意します。 . ├── Dockerfile ├── main.py └── requirements.txt main.py サンプルコードは Flask によるシンプルなウェブアプリケーションとなっています。 このアプリケーションに対して HTTP リクエストがあると、 Hello {環境変数 NAMEの値}! が返ります。環境変数が設定されていない場合は Hello World! が返るようになっています。 import os from flask import Flask app = Flask(__name__) @ app.route ( "/" ) def hello_world (): """Example Hello World route.""" name = os.environ.get( "NAME" , "World" ) return f "Hello {name}!" if __name__ == "__main__" : app.run(debug= True , host= "0.0.0.0" , port= int (os.environ.get( "PORT" , 8080 ))) requirements.txt requirements.txt は以下のように記述します。 Flask==3.1.0 gunicorn==23.0.0 Werkzeug==3.1.3 Dockerfile Cloud Run にはアプリケーションのコンテナイメージをデプロイする必要があるため、ビルド用の Dockerfile を用意します。 FROM python:3.12-slim ENV PYTHONUNBUFFERED True ENV APP_HOME /app WORKDIR $APP_HOME COPY . ./ RUN pip install --no-cache-dir -r requirements.txt CMD exec gunicorn --bind : $PORT --workers 1 --threads 8 --timeout 0 main:app なお、Cloud Run では Dockerfile を使用せず、ソースコードのみを使用してデプロイすることもできます。 この場合、裏側では Google Cloud のサーバーレス CI/CD プラットフォームである Cloud Build によってコンテナイメージのビルドが自動で行われています。 ビルドの際、ベースイメージは Google 管理の安全なものが使用されるため、ビルドの内容を細かくカスタマイズする必要がない場合は、こちらの方法を検討してみてもよいでしょう。 ソースコードからのデプロイの詳細については、以下のドキュメントをご一読ください。 参考 : Deploy services from source code  |  Cloud Run  |  Google Cloud Documentation コンテナイメージの準備 コンテナイメージの要件 ここからは、Cloud Run にデプロイするアプリケーションのコンテナイメージを作成していきます。 Cloud Run で使用できるコンテナイメージは、以下のような要件を満たしている必要があります。 コンテナイメージ内の実行可能ファイルは、Linux 64 ビット用（Linux ABI x86_64）にコンパイルする必要がある。 リクエストの送信先ポート（デフォルトのポートは 8080 ）で 0.0.0.0 のリクエストをリッスンする必要がある。 リクエストを受信してから Cloud Run のタイムアウト設定で指定された時間内に、レスポンスを返す必要がある。 その他、コンテナイメージの詳細な要件は以下のドキュメントをご一読ください。 参考 : Container runtime contract  |  Cloud Run  |  Google Cloud Documentation ビルド環境について Cloud Run にデプロイできるコンテナイメージは x86_64 アーキテクチャに対応しているため、Mac 等の arm64 アーキテクチャ環境でコンテナイメージをビルドする場合、コンテナイメージのビルド時に注意が必要です。 このような環境で docker build コマンドでイメージをビルドする場合は、x86_64 アーキテクチャを使用するように指定する必要があります。 # x86_64 アーキテクチャを明示的に指定する $ docker build --platform linux/amd64 -t { イメージタグ } . コンテナイメージのビルドに Cloud Build を使用する場合、Google Cloud のサーバーレス環境でビルドが行われます。デフォルトで x86_64 アーキテクチャが使用されるため、上記のビルド時の考慮は必要ありません。 当記事では、Cloud Build を使用する方法でビルドを行っていきます。 コンテナイメージのビルド イメージ名について Cloud Build を使用してコンテナイメージをビルドし、はじめに作成した Artifact Registry のリポジトリにプッシュします。Cloud Build を使用する場合、ビルドとプッシュは1つのコマンドで実行可能です。 コンテナイメージ名は以下のような形式にする必要があります（docker コマンドを使用する場合も同様）。 { リポジトリのリージョン } -docker.pkg.dev/ { プロジェクトID } / { リポジトリ名 } / { 任意のイメージ名 } : { タグ（省略可） } このうち、 {リポジトリのリージョン}-docker.pkg.dev/{プロジェクトID}/{リポジトリ名} の部分は、Artifact Registry のコンソールから文字列としてコピーすることができます。 イメージ名に使用するリポジトリのパスをコピーする ビルドとプッシュ Dockerfile があるディレクトリ上で、 gcloud builds submit コマンドを実行します。これにより、用意したファイルが Cloud Build に送信され、Google Cloud のサーバーレス環境上でコンテナイメージのビルドと、Artifact Registry へのプッシュが行われます。 # Cloud Build でビルドとプッシュを行う $ gcloud builds submit --tag { リポジトリのリージョン } -docker.pkg.dev/ { プロジェクトID } / { リポジトリ名 } / { 任意のイメージ名 } : { タグ（省略可） } 当記事ではイメージ名を hello 、タグを v1.0 としてイメージをビルドします。 Artifact Registry のリポジトリ myrepo は asia-northeast1 リージョンにあるため、実行するコマンドは以下のようになります（プロジェクトは仮に myproject とします）。 # コマンド実行例 $ gcloud builds submit --tag asia-northeast1-docker.pkg.dev/myproject/myrepo/hello:v1. 0 ビルド完了後、Artifact Registry のリポジトリにコンテナイメージがプッシュされていることを確認します。 Artifact Registry にコンテナイメージがプッシュされている Cloud Run サービスのデプロイ 最小限の設定でデプロイ Google Cloud のコンソールから、最小限の設定のみを行ってデプロイを行います。 GUI を仕様した Cloud Run のデプロイは、 Cloud Run のコンソール や、Artifact Registry に格納されたコンテナイメージから行うことができます。 Cloud Run のコンソールからデプロイする場合 Artifact Registry のコンソールからデプロイする場合 「コンテナイメージの URL」項目で Artifact Registry にプッシュしたコンテナイメージを指定します。デフォルトでは、コンテナイメージの名前がデプロイする Cloud Run サービスの名前になります（変更可能）。 デプロイしたコンテナイメージを選択する 「リージョン」は初期状態の europe-west1 でもよいですが、 asia-northeast1 に変更しておきます。 また「認証」項目で 公開アクセスを許可する を選択します。使用しているプロジェクトの Google Cloud 組織の制約によってはこの項目は選択できない可能性があるため、選択できない場合は一旦 認証が必要 を選択してください。 参考 : Cloud Runの呼び出し元IAMチェックを無効化してサービスを公開する - G-gen Tech Blog リージョンと認証を設定後、「作成」を押下してサービスを作成する コンソール画面最下部の「作成」を押下し、サービスをデプロイします。 動作確認 少し待つとサービスの リビジョン （デプロイごとに作成される、サービスのバージョン）が作成されます。 Cloud Run はこのリビジョンの単位でサービスのバージョン管理を行うことができ、新しくデプロイしたリビジョンに問題があるような場合に、すぐに前のリビジョンにロールバックすることが可能です。 サービスの詳細画面でサービス用に生成された HTTPS エンドポイントが表示されているので、ブラウザからアクセスしてみます。 HTTPS エンドポイントからサービスにアクセスする コンテナインスタンスが起動し、 Hello World! が返ってきます。 Cloud Run にデプロイしたウェブアプリケーションのレスポンス 「認証が必要」に設定した場合 「認証」項目で 認証が必要 を選択した場合、サービスの詳細画面に表示されている Cloud Run の HTTPS エンドポイントに直接アクセスすることができません。 以下のコマンドを使用することで、Cloud Run プロキシをローカルで実行して、プロキシ経由でサービスにアクセスすることができます。 # Cloud Run プロキシの実行 $ gcloud run services proxy { サービス名 } --project { プロジェクトID } # 実行例 $ gcloud run services proxy hello --project myproject コマンドの実行後、ローカルホスト（ http://127.0.0.1:8080 ）からサービスにアクセスしてください。 参考 : Cloud Runサービスを「認証が必要」に設定したらブラウザからアクセスできなくなった - G-gen Tech Blog デプロイ時のよくあるエラー Cloud Run のデプロイ時、以下のエラーが発生してデプロイが失敗することがあります。 デプロイ時のよくあるエラー The user-provided container failed to start and listen on the port defined provided by the PORT=8080 environment variable within the allocated timeout. This can happen when the container port is misconfigured or if the timeout is too short. The health check timeout can be extended. Logs for this revision might contain more information. Logs URL: {Cloud Logging の URL} For more troubleshooting guidance, see https://cloud.google.com/run/docs/troubleshooting#container-failed-to-start このエラーは Cloud Run の設定ではなく、コンテナイメージ側の問題でアプリケーションが正常に実行できていない可能性が非常に高いです。　　 トラブルシューティングとして、まずは Cloud Logging に出力されているエラーログや Dockerfile の記述内容を確認したり、開発環境の Docker 上でコンテナが正常に実行できるか確認したりするとよいでしょう。 デプロイ時の基本的な設定項目について ここでは、Cloud Run のデプロイ時に設定できる基本的な項目について解説します。 認証 「構成」の「認証」項目では、Cloud Run 上のサービスへのアクセス時に IAM 認証を必要とするかどうかを設定します。 サービス作成画面の「認証」項目 一般公開するサービスであれば 公開アクセスを許可する を設定しますが、Cloud Run にデプロイしたアプリケーションが他のサービスのバックエンドとして使用される場合や、特定のユーザーのみにサービスを公開したい場合（後述の「 サービスに対するアクセスの制御 」を参照）に 認証が必要 に設定することがあります。 認証の設定は、サービスの詳細画面の「セキュリティ」タブなどから変更することができます。 サービスの詳細画面から認証の設定を変更する 参考 : Allowing public (unauthenticated) access  |  Cloud Run  |  Google Cloud Documentation Ingress Ingress の設定はサービスに対してどこからアクセスできるかを大まかに設定できます。 サービス作成画面の「Ingress」項目 以下の3パターンがあるため、ユースケースに応じて設定します。 設定値 説明 すべて インターネットからサービスにアクセスする場合に設定する。 内部（外部アプリケーション ロードバランサからのトラフィックを許可する） カスタムドメインを設定する場合など、インターネットからロードバランサ経由でサービスにアクセスする場合に設定する。 内部 Google Cloud の他のサービス（例：Pub/Sub、他の Cloud Run など）からサービスにアクセスする場合に設定する。 参考 : Restrict network ingress for Cloud Run  |  Google Cloud Documentation CPU・メモリ・最大同時リクエスト数 CPU、メモリ、最大同時リクエスト数の設定は、Cloud Run のスケーリングにかかわる非常に重要な項目です。 サービス作成画面の「リソース」項目（CPU・メモリ） サービス作成画面の「リクエスト」項目（インスタンスあたりの最大同時リクエスト数） これらの設定値は、Cloud Run のコンテナインスタンス1つあたりが使用するコンピューティングリソースと、同時に処理できる最大リクエスト数を定義します。 Cloud Run では、1分間の平均 CPU 使用率と同時リクエスト数を元に、起動するコンテナインスタンスの数を制御しています。 CPU 使用率とスケーリングの関係は以下のようになっています。 各コンテナインスタンスの平均 CPU 使用率が 60% に維持されるようにインスタンス数が調整される。 これに加えて、同時リクエスト数の上限を超える場合にインスタンス数の調整が行われます。そのため、 同時リクエスト数の上限値が低い場合、CPU 使用率にまだ余裕があるにもかかわらず、コンテナインスタンスのスケールアウトが行われてしまう 可能性があります。 Cloud Run は基本的に「コンピューティングリソースの 設定値 × コンテナインスタンスの実行時間」で料金が発生するため、CPU が 20% しか使用されていないのにスケールアウトが起こってしまうと、40% ぶんの無駄が料金が発生してしまいます（スケールアウト基準値の 60% - 20%）。 したがって、設定する値は、平均 CPU 使用率が 50~60% になるちょうどよい値が理想となります。これは、サービスの初回デプロイ時に決定するのは非常に難しいため、サービス運用開始後に継続してモニタリングを行い、それぞれ調整していく必要があります。 最小インスタンス数 Cloud Run の大きな特徴として、サービスの最小インスタンスを 0 にできる点があります。この特徴は一般に「 ゼロスケール 」と呼ばれます。 ゼロスケールは、サービスに対するリクエストがないときはインスタンスが起動していないため、 料金が発生しない ことが大きなメリットとなります。 その反面、ゼロスケールのデメリットとして、最初のリクエストの処理にコンテナインスタンスの起動時間ぶんのレイテンシが発生してしまう コールドスタート があります。 コールドスタートによるレイテンシが許容できない場合は、最小インスタンス数を 1 以上にすることで、コンテナインスタンスを常に起動した状態にします。この場合、当然ながらゼロスケールの料金メリットは享受できなくなります。 サービス作成画面の「サービスのスケーリング」項目（インスタンスの最小数） また Cloud Run には、コンテナインスタンスの起動時のみインスタンスに割り当てられる CPU を一時的に増やす「 起動時の CPU のブースト 」という機能があります。最小インスタンス数を増やす前に、まずはこの機能でレイテンシが緩和されるか確認するとよいでしょう（デフォルトで有効になっている）。 「起動時の CPU ブースト」を設定する コールドスタートの詳細については、以下の記事をご一読ください。 参考 : Cloud Runのコールドスタートの解説と対処法 - G-gen Tech Blog リクエストのタイムアウト 「リクエストのタイムアウト」項目では、1つのリクエストの処理に使用できる時間を設定します。ここで設定した時間までにリクエストが完了しないと HTTP 504 エラーが返ります。タイムアウトは 1 ~ 3600（秒） で設定できます。 サービス作成画面の「リクエスト」項目（リクエストのタイムアウト） Cloud Run 側のタイムアウト設定を長くしていても、アプリケーションのフレームワーク側でタイムアウトの設定値が Cloud Run よりも短くなっている場合があるため注意しましょう。 サービスアカウント Cloud Run で実行しているアプリケーションから他の Google Cloud サービスを利用する場合、コンテナインスタンスに紐づけられた サービスアカウント を使用してサービスの認証が行われます。 デフォルトでは、「Default compute service account」というサービスアカウントが設定されています。これは Compute Engine のデフォルトのサービス アカウント と呼ばれるもので、Compute Engine や Cloud Run のようなコンピューティング サービスにおいて、デフォルト値として設定されているサービスアカウントです。 コンテナインスタンスに紐づけるサービスアカウントの設定 デフォルトのサービスアカウントは非常に強い権限を持っており、ほとんどのサービスにアクセスすることができてしまいます。そのため、最小権限の原則に従って、サービスに必要な権限のみを付与したサービスアカウントを作成することが推奨されます。 参考 : Create service accounts  |  Identity and Access Management (IAM)  |  Google Cloud Documentation 参考 : Google CloudのIAMで最小権限の原則を実現する方法 - G-gen Tech Blog コンテナの環境変数 Cloud Run では環境変数を Key-Value 形式で設定することができ、コンテナの環境変数としてコードからアクセスできます。 当記事のサンプルコードは NAME 環境変数を利用するようになっているため、サービスの編集画面から NAME をキーとする環境変数を設定してみます。 コンテナの環境変数を設定する リビジョンの再デプロイ後、ブラウザからサービスにアクセスします。環境変数が反映され、 Hello, {環境変数の値}! が返ってきます。 設定した環境変数が反映されている Cloud Run でよく使用される機能や構成 ここからは、Cloud Run でサービスを提供する際に、よく使用される機能や構成を紹介します。 カスタムドメインの使用 Cloud Run でサービスをデプロイすると、サービスにアクセスするための .run.app ドメインの HTTPS エンドポイントが2つ発行されます（ 参考 ）。 会社のドメイン等、任意のドメインを使用してサービスにアクセスできるようにするためには、Cloud Run の前段に 外部アプリケーションロードバランサ （旧称 : 外部 HTTP(S) ロードバランサ）を配置し、ロードバランサに対してカスタムドメインを構成する方法が一般的です。 カスタムドメインで Cloud Run のサービスにアクセスできるようにする 具体的な設定方法については、以下の記事の「 HTTPS Load Balancing の設定 」を参照してください。 参考 : Identity-Aware Proxy(IAP)とCloud Armorを使用してCloud Runサービスへのアクセス制御を実装する - G-gen Tech Blog サービスに対するアクセスの制御 Identity-Aware Proxy（IAP） を使用することで、許可された Google アカウントのみがサービスにアクセスできるように構成することができます。 IAP を使用してアクセス制御を行う場合、Cloud Run で直接 IAP を有効化する方法か、Cloud Run の前段にあるロードバランサで IAP を有効化する方法のいずれかを選択します。 Cloud Run に対して直接 IAP を有効化するほうがシンプルな構成となりますが、前述の通り、ロードバランサを使用する場合はカスタムドメインを設定することができます。 また、ロードバランサではクラウド型 WAF である Cloud Armor を使用することで、サービスのアクセス元 IP アドレスを制限することも可能です。 ライトなユースケースでは Cloud Run で IAP を有効化し、正式なサービスとして展開する場合はロードバランサを使用するなど、ユースケースによって使い分けるとよいでしょう。 参考 : Cloud Runでロードバランサを使用せずIdentity-Aware Proxy（IAP）を構成する - G-gen Tech Blog 参考 : Identity-Aware Proxy(IAP)とCloud Armorを使用してCloud Runサービスへのアクセス制御を実装する - G-gen Tech Blog Google アカウントやアクセス元 IP アドレスでアクセス制限を行う Workforce Identity 連携 により、Microsoft Entra ID 等の外部 ID プロバイダを利用して IAP による認証を構成することもできます。 参考 : Configure IAP with Workforce Identity Federation  |  Identity-Aware Proxy  |  Google Cloud Documentation 参考 : Configure Workforce Identity Federation with Microsoft Entra ID and sign in users  |  Identity and Access Management (IAM)  |  Google Cloud Documentation 機密情報の使用（パスワード・API キーなど） Cloud Run では、 Secret Manager に格納したデータベースのパスワードや外部サービスの API キーなどの機密情報（シークレット）を、環境変数もしくはボリュームマウントの形式で利用することができます。 具体的な仕様や設定方法については以下の記事を参照してください。 参考 : Cloud RunからSecret Managerのシークレットにアクセスする - G-gen Tech Blog データベース サービスへの接続 Google Cloud にはいくつかのデータベース サービス（ 参考 ）がありますが、そのうち Cloud SQL と AlloyDB for PostgreSQL （AlloyDB）は「パブリック IP による接続」か「VPC を経由したプライベート IP 接続」のどちらかを選択する必要があります。 パブリック IP による接続では、プロキシソフトウェアである Cloud SQL Auth Proxy および AlloyDB Auth Proxy を使用した接続が推奨されています。これらを使用することにより、TLS 1.3 を使用した安全なデータベース接続が保証されます。 Cloud SQL Auth Proxy および AlloyDB Auth Proxy を使用した接続については、以下の記事を参照してください。 参考 : Cloud SQL Auth Proxyを使用してCloud RunからCloud SQLに接続する - G-gen Tech Blog 参考 : Cloud RunからAlloyDBにパブリックIPアドレスで接続する - G-gen Tech Blog VPC を経由したプライベート IP 接続では、Cloud Run から「Cloud SQL（もしくは AlloyDB）にプライベート接続できる VPC」を経由してデータベースにアクセスする必要があります。 Cloud Run から VPC に接続するためには、 サーバーレス VPC アクセス もしくは Direct VPC Egress を使用する必要があります。それぞれの比較や利用方法については以下の記事を参照してください。 参考 : Cloud RunのDirect VPC Egressを解説 - G-gen Tech Blog Cloud Run から Cloud SQL にプライベート IP アドレスで接続する場合の構成例 Spanner や Firestore 等、その他データベース サービスについては、 Google Cloud APIs を介したアクセスとなります。 Cloud Run から Google Cloud APIs へのリクエストは Google の内部ネットワーク内にとどまることが保証されているため、VPC を経由したアクセスの設定は必要ありません（ 参考 ）。 Cloud Run が使用する外部 IP アドレスの固定 Cloud Run 上のアプリケーションから外部サービスの API を使用する場合、外部サービス側で接続元 IP アドレスが制限されるケースがあります。 デフォルトでは、Cloud Run サービスは、コンテナインスタンスごとに自動で割り当てられるパブリック IP アドレスを使用してインターネット接続を行います。この IP アドレスはコンテナインスタンスが起動するたびに変わってしまいます。 インターネット接続に使用される IP アドレスの固定には、 Cloud NAT を使用する必要があります。Cloud NAT は VPC 内に存在するため、「 データベース サービスへの接続 」で紹介したサーバーレス VPC アクセスもしくは Direct VPC Egress を構成して Cloud NAT に接続できるようにします。 サーバーレス VPC アクセス を使用するパターン Direct VPC Egress を使用するパターン それぞれの具体的な設定方法については以下の記事を参照してください。 参考 : Cloud Runから固定IPでインターネット接続する（サーバーレスVPCアクセス編） - G-gen Tech Blog 参考 : Cloud Runから固定IPでインターネット接続する（Direct VPC Egress編） - G-gen Tech Blog 他の Cloud Run サービスへのプライベートアクセス Cloud Run のサービスをフロントエンドとバックエンドで分離する場合など、サービスから他の Cloud Run サービスにアクセスする場合、かつバックエンド側（アクセスされる側）のサービスが外部に公開できない場合、バックエンド側サービスの Ingress の設定を 内部 に設定することが推奨されます。 内部からのサービスアクセスのみ許可する しかし、フロントエンド側サービスからバックエンド側サービス エンドポイントへの 直接アクセスは「内部」ではない ため許可されません。これを「内部」からのアクセスにするためには、フロントエンド側サービスを VPC に接続し、 限定公開の Google アクセス を使用してバックエンド側サービスにアクセスする必要があります。 Cloud Run から他の Cloud Run サービスへのプライベートアクセス 設定方法の詳細については以下の記事を参照してください。 参考 : Cloud Runから内部ネットワーク経由で別のCloud Runサービスを呼び出す - G-gen Tech Blog Cloud Storage バケットのマウント Cloud Run では、容量無制限のオブジェクトストレージ サービスである Cloud Storage のバケットをファイルシステムとしてマウントすることができます。 これにより、Cloud Run 上のアプリケーションで使用する静的アセットをコンテナイメージに含める必要がなくなり、静的アセットの編集が容易になります。 マウントの詳細な仕様や設定方法については以下の記事を参照してください。 参考 : Cloud RunでCloud Storageバケットをマウントする - G-gen Tech Blog 佐々木 駿太 (記事一覧) 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 ドライブの 共有リンク について解説します。また、共有リンクがファイルやフォルダの移動に際してどのような影響を受けるのかについてもあわせて紹介します。 共有リンクとは 共有リンクの取得方法 共有リンクボタンからの取得 ブラウザからの取得 共有リンクのセキュリティ 移動とコピー ファイルやフォルダの移動 ファイルのコピー 共有リンクとは Google ドライブには 共有リンク 機能があります。Google ドキュメントや Google スプレッドシート、あるいは Google ドライブのフォルダで共有リンクを取得すると、以下のような形式の URL が得られます。 https://docs.google.com/document/d/(ファイル ID)/edit?usp=sharing https://docs.google.com/spreadsheets/d/(ファイル ID)/edit?usp=drive_link https://drive.google.com/drive/folders/(フォルダ ID)?usp=drive_link このリンクにアクセスすると、そのファイルやフォルダに対して自分が持つ権限に応じて、ファイルやフォルダにアクセスすることができます。 参考 : Google ドライブのファイルを共有する 共有リンクの取得方法 共有リンクボタンからの取得 共有リンクは、Google ドライブのファイル一覧画面から取得したり、Google ドキュメントや Google スプレッドシート等のファイル編集画面、また共有権限編集画面から取得することができます。 Google ドライブのファイル一覧からの取得 ファイル編集画面からの取得 共有権限編集画面からの取得 ブラウザからの取得 ファイルへのリンクは、Google ドキュメントや Google スプレッドシート等ファイル編集画面を開いているときのブラウザの URL 欄からも取得することができます。ブラウザの URL 欄から取得した場合、共有リンク末尾の ?usp=drive_link や ?usp=sharing などのクエリ文字列の部分がありませんが、検証の結果、クエリ文字列の有無によってユーザーから見た動作に違いはありません。ただし、このクエリ文字列の意味はドキュメントに明記がありません。 ブラウザの URL 欄からの取得 またブラウザからリンクを取得する場合、Google ドキュメントの特定の見出し位置や Google スライドの特定のスライドへのリンクを取得することができます。Google スライドなどを開いている場合、URL の末尾に #slide=id.(スライド ID) のように、位置を示すアンカーが付加されています。 ファイルの特定位置へのリンク 共有リンクのセキュリティ 共有リンクを知っていても、そのファイルやフォルダに対して権限を持っていなければアクセスすることはできませんので、このリンク自体が漏洩したとしてもファイル自体の漏洩には繋がりません。 ただし、権限の設定ミスなどの可能性はゼロではありませんので、知る必要がない人には共有リンクを知らせないことが望ましいといえます。 移動とコピー ファイルやフォルダの移動 ファイルやフォルダを Google ドライブ内で移動しても、共有リンクは変更されません。同じリンクで、引き続き同じファイルやフォルダにアクセスすることができます。 また、ファイルやフォルダをマイドライブから共有ドライブに移動したり、あるいは共有ドライブから別の共有ドライブに移動するなどしても、リンクは変わりません。 移動先と移動元が違う Google Workspace 組織であっても、リンクが変わることはありません。 ファイルのコピー ファイルをコピーした場合、コピー先のファイルは新規作成した場合と同様になりますので、共有リンクは新しいものになります。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の奥田です。当記事では、Amazon Web Services（AWS）、Microsoft Azure、Google Cloud（旧称 GCP）が提供するフルマネージドな AI エージェントサービスの比較 を行います。 はじめに 当記事について AI エージェントとは ツールとは マルチエージェントシステムとは RAG と併用する効果 3社比較 前提条件 機能比較 料金シュミレーション 想定シナリオ AWS Azure Google Cloud 総評 AWS Azure Google Cloud 詳細の解説 Amazon Bedrock Agents（AWS）の詳細 構成図 プロダクト一覧 できること 対応モデル ツール 料金 Azure AI Agent Services（Azure）の詳細 構成図 プロダクト一覧 できること 対応モデル ツール 料金 Playbooks（Google Cloud）の詳細 構成図 プロダクト一覧 できること 対応モデル ツール 料金 まとめ Amazon Bedrock Agents（AWS） Azure AI Agent Service（Azure ） Vertex AI Playbooks（Google Cloud） はじめに 当記事について 本記事では、生成 AI アプリケーションの開発や PoC（実証実験）を検討している方向けに、 Amazon Web Services（AWS）、Microsoft Azure、Google Cloud の3社が提供する AI エージェントサービス を紹介します。 なお、当記事の情報は、2025年3月現在のものです。最新情報は各クラウドベンダーの公式ドキュメント等をご参照ください。 AI エージェントとは AI エージェント（AI Agent） とは、複雑な目標を自律的に遂行する AI システム のことです。これらのエージェントは、自然言語処理（NLP）、機械学習（ML）、ルールベースの意思決定などの技術を活用し、指定されたタスクを自動的に処理します。 また、AI エージェントは さまざまなツールやデータソースと連携することで、更に高度なタスクの実行が可能です。例えば、企業内のナレッジベースと統合し、社内 FAQ の自動応答を行う AI エージェントや、顧客対応を最適化する AI チャットボットなどが挙げられます。 近年では、 クラウドベンダーが提供する AI エージェントサービスを活用することで、開発コストを抑えつつ、高度なエージェントを構築することが可能 になっています。 本記事では、複数の AI エージェントを組み合わせた社内ナレッジシステムの構築をユースケースとして想定し、各クラウドベンダーのサービスの特徴や活用方法について詳しく解説します。 また、本記事で紹介するものの中には、記事を執筆した2025年3月現在でプレビュー段階のサービスも含まれています。実装の際は各クラウドベンダーの最新版ドキュメント等を参照することをおすすめします。 ツールとは ツールは、AI エージェントが外部の情報やサービスと連携するための「橋渡し」となる仕組みです。エージェントはこれらのツールを活用することで、API の呼び出しやデータの処理を行い、タスクを効率的に実行できます。 Google が発表したホワイトペーパーである「Agents」によると、ツールには以下の3種類があります。 参考 : Agents (Authors: Julia Wiesinger, Patrick Marlowand Vladimir Vuskovic) エクステンション（Extensions） API とのインターフェースを標準化し、エージェントが外部サービス（例：Google Flights API）を利用できるようにする仕組み エージェントはエクステンションを通じて、必要なパラメータや API の使用方法を学習しながら、適切に API コールを実行 ファンクション（Functions） エージェントが必要な処理を実行するために、クライアントサイドのコードを呼び出す仕組み 直接 API を呼び出すのではなく、エージェントが生成したパラメータを元に、外部システム側で関数が実行される データストア（Data Stores） ベクトルデータベースなどを活用し、エージェントが最新の情報や、構造化・非構造化データにアクセスできるようにする仕組み エージェントは訓練時の知識だけでなく、リアルタイムのデータを参照しながら回答を生成できる マルチエージェントシステムとは マルチエージェント システム（Multi-Agent System、MAS）とは、 複数の自律的なエージェントが連携し、それぞれの専門性や役割を活かしてタスクを分担・実行するシステム を指します。各エージェントは、言語モデルや外部ツール（API、データストアなど）を活用し、情報の取得や意思決定、具体的な操作を自律的に行います。これにより、単一のエージェントでは対応が困難な複雑な問題や多段階のタスクにも、協調して対処できるようになります。 例えば、1つのエージェントが市場情報を収集し、もう1つのエージェントがそのデータを分析して投資戦略を自動的に策定するといった役割に応じたエージェントを複数構築する、といったことが可能です。 RAG と併用する効果 RAG （Retrieval Augmented Generation）と併用することで、AIエージェントが、 事前に学習したデータだけでなく、外部のデータソースから情報を取得し、それに基づいて応答を生成する ことを可能にします。 各パブリッククラウドにおけるRAGの比較については、以下の記事をご参照ください。 参考 : 生成AIのRAG構成を大手3社（AWS、Azure、Google Cloud）で徹底比較してみた 3社比較 前提条件 AI エージェントを構築するにあたり、どのベンダーのサービスでも複数のデータソースや基盤モデルに対応しています。 また、RAG 構築と同様に「マネージドなサービスだけの構成」、「OSS である LangChain をベースとして適宜クラウドサービスを用いる構成」など、アーキテクチャの選択肢も複数用意されています。 当記事では以下の実現を要件として比較します。 フルマネージドサービスのみで構築 各プラットフォーム上の開発ツールを利用して開発 複数のエージェントを組み合わせるマルチエージェントを実装することが可能 上記要件を満たすサービスとして、以下の3サービスを選定しました。 クラウド サービス AWS Amazon Bedrock Agents Azure Azure AI Agent Service Google Cloud Vertex AI Agent Builder の Playbooks （※） （※）以前は「Vertex AI Agents」という名称で利用されていたサービスが該当します。 2024 年後半から 2025 年初頭にかけて、一部の製品名、機能名、コンソールに変更が行われることが発表されております。本記事では新しい名称の 「Playbooks」 で統一表記します。 参考 : Renaming and console consolidation plan 機能比較 以下は、各サービスの提供機能の比較です。 Amazon Bedrock Agents Azure AI Agent Service Playbooks マルチエージェントの実現 ◎ △ ◎ 外部データの検索 ◎ ◎ ◎ 外部ウェブサイトの検索 △ ◎ ☆ 会話履歴の保存 ◎ ◎ ◎ 評価の実施 ◎ ◯ △ コンテンツフィルタリング ◎ ◎ ◎ ◎：プレビュー画面から設定可能 ◯ : プレビュー画面から設定不可だが API や代替手段が提供されている △ : 実装する等で利用可能 or 一部のみプレビュー画面より設定可能 ☆：ドメイン所有権を確認したウェブサイトのコンテンツをソースとして設定可能 料金シュミレーション 想定シナリオ とある社内向けシステムを仮定します。 情報システム担当者の負担を軽減するため、エージェントによる自動応答とチケット発券の2つの機能を中心に構成されています。 システム要件 は下記です。 24時間、365日稼働 1日あたりの問い合わせは500件 1回の使用につき 10 件のクエリが発生 平均の入力文字数は100文字、出力は300文字 各社の独自サービスを利用する（LangChain などの OSS は使わない） 3つのエージェントで構成 本システムは マルチエージェントとなり、各エージェントはそれぞれ異なる役割を担います。以下に 各エージェントの機能概要 を示します。 1. 問い合わせ処理エージェント ユーザーからの問い合わせを受け付け、適切な応答を行う 入力内容を解析し、他のエージェントへ必要な処理を依頼する 2. ナレッジ検索エージェント 社内データベースを参照し、問い合わせに関連する情報を検索する FAQ や過去の対応履歴を基に適切な回答を提供する 3. チケット発券エージェント 解決が難しい問い合わせに対して、ユーザーに必要な情報を確認し、サポート対応のためのチケットを作成する 作成されたチケットはデータベースに保存され、後日、担当者が対応を行う 上記の条件の下、1 ヶ月間の利用料を計算します。なお実際には API サーバ等、RAG サービス以外の料金やデータストレージ料金などが発生する可能性がありますが、今回は単純化のため考慮から外します。 いずれも試算に用いた単価は記事を執筆した2025年2月現在のものです。ご自身で試算する際は、必ず公式から発表されている料金表をご参照ください。また、ドル・円換算は1ドルを150円として計算しています。 AWS 1ヶ月の利用料は約99,360円です。 Aurora Serverless v2 ： 86.4USD（※1） Anthropic - Claude 3.5 Sonnet （Amazon Bedrock Edition）入力トークン（1 文字 0.8 トークン計算）：36USD Anthropic - Claude 3.5 Sonnet （Amazon Bedrock Edition）出力トークン（1 文字 0.8 トークン計算）：540USD （※1）Amazon Aurora Serverless は自動停止時のコンピューティングコストは0USD となりますが、本システムでは24時間、365日稼働であると想定しているため1.0 ACU の Aurora Serverless v2 を730時間起動する設定で算出をしてます。 Azure GPT o1 2024-12-17 を利用した場合、1ヶ月の利用料は418,500円です。 コード インタープリター：450USD GPT o1 2024-12-17 Global 入力トークン （1 文字 0.8 トークン計算）：180USD GPT o1 2024-12-17 Global 出力トークン （1 文字 0.8 トークン計算）：2,160USD GPT o1-mini を利用した場合、1ヶ月の利用料は144,720円です。 コード インタープリター ：450USD GPT o1-mini 入力トークン （1 文字 0.8 トークン計算）：39.6USD GPT o1-mini 出力トークン （1 文字 0.8 トークン計算）：475.20USD Google Cloud 1ヶ月の利用料は約270,000円です。（※2） Playbooks クエリ：1800USD （※2）インデックス データ ストレージの価格は1ヶ月あたり10GiB までの無料割当があり、無料割当の範囲内での利用と想定します。 10GiB を超えた場合、生データ1GiB あたり月額5.00 USD が発生します。 総評 AWS Amazon Bedrock Agents は、生成AIモデルが外部ツールや Knowledge Tool と連携して、ユーザーの要求に応じて自律的に行動するシステムのことです。 また、Bedrock Agents は Amazon 自社の基盤モデル（Amazon Titan 及び Amazon Nova）だけでなく、Anthropic 社や Cohere 社が提供する基盤モデルも選択可能です。利用するモデルの種類によって、用途や性能、価格などを最適化できます。 2024年12月のアップデートにより、複数のエージェントを協調させて動作させる「マルチエージェント」機能が導入されました。これにより、異なる専門性を持つエージェントが連携して複雑なタスクを効率的に処理できます。 Amazon Bedrock Flows を利用することでローコードでの開発が可能であること、Knowledge Tool を活用することで様々な応用が効くことから 初級者から中級者向け のサービスであると言えます。 参考 : Amazon Bedrock 生成AIアプリ開発入門 [AWS深掘りガイド] Azure Azure AI Agent Service は、Microsoft のマネージドサービスと組み合わせて、エンタープライズ向けに機能拡張したサービスです。エージェントは生成AIモデルを活用し、多様なツールと連携しながらユーザーの要求に応じて自律的にタスクを実行します。 Azure AI Agent Service では、会話の状態（コンテキスト）を「Thread（スレッド）」で一元管理します。また、エージェントが処理を実行する際は「Run（ラン）」という単位でタスクを明確に分割できます。 Azure AI Agent Service は基本的な機能のみユーザーインターフェース（UI）を提供していますが、すべての機能を活用するにはコーディング知識が必要となります。 これらの理由から、Azure AI Agent Service は 上級者向け のサービスと言えます。特にエンタープライズ環境で高度なカスタマイズや詳細な管理を求める開発者や企業に最適です。 Google Cloud Google Cloud の Vertex AI Playbooks は、生成 AI 機能を新たに組み込んだ高度な会話型 AI サービスです。従来の自然言語処理（NLP）プラットフォームであるDialogflow をリブランディングしたものです。ローコードでの開発が可能なため、専門的な知識がなくても迅速に高機能なエージェントを構築できます。 Vertex AI Playbooks はリクエスト数に応じて課金される仕組みとなっており、コスト計算が明確で管理しやすいのが特徴です。Google Cloud の RAG（Retrieval-Augmented Generation）である Vertex AI Search と同様、インスタンス料金が不要であるため、利用時のコストを抑えることが可能です。 Google が提供する生成 AI モデルである Gemini を活用することで、より自然で高度な対話シナリオを実現できます。 データストアとして、 BigQuery にも対応 しています。これにより、大規模なデータセットをリアルタイムに活用する場合においても、高速かつ正確なデータアクセスを実現できます。特に大規模データを扱う企業やシステムで効果的な運用が可能となります。 明快な料金体系と視覚的に分かりやすいインターフェースのため、初級者から中級者向けのサービスであると言えます。 詳細の解説 Amazon Bedrock Agents（AWS）の詳細 構成図 プロダクト一覧 Amazon Bedrock Agents Amazon Bedrock Agents は、AWS が提供する対話型アプリケーションを構築できるサービスです。 Knowledge bases for Amazon Bedrock Knowledge Bases for Amazon Bedrock は、RAG（Retrieval-Augmented Generation） を活用し、基盤モデルと組み合わせて RAG アプリケーションを開発できるマネージドサービス です。 Amazon S3 Amazon S3（Simple Storage Service） は、スケーラブルなオブジェクトストレージサービスであり、大量のデータを安全に保存・管理できます。 AWS Lambda AWS Lambda は、サーバーレスアーキテクチャを実現するイベント駆動型のコンピューティングサービスです。 AWS Lambda は、Amazon Bedrock Agents のツールとして、外部システムとの連携やカスタムロジックの実行を担う重要な役割を果たします。具体的には、エージェントのワークフロー内で API コールを実行したり、データ処理を行ったりするためのバックエンド処理を自動化する ことができます。 本事例では DynamoDB へのデータ書き込みを実行する関数を作成します。 RDS（Aurora Serverlessクラスター） Amazon RDS（Relational Database Service） の Aurora Serverless は、オンデマンドでスケールするリレーショナルデータベースです。 本構成ではベクトルデータソースとしての役割を担います。 ベクトルデータソースは下記でも代替可能です。 Amazon OpenSearch Serverless Amazon Aurora Pinecone Redis Enterprise Cloud DynamoDB DynamoDB は、Amazon が提供するフルマネージド型の NoSQL データベースサービスです。 できること マルチエージェントの実現 Amazon Bedrock for Agents では、新たに 「マルチエージェントコラボレーション機能」 が発表されました。 従来の AI システムでは、1 つのエージェントが単独でタスクを処理するケースが一般的でした。しかし、本機能を活用することで、複数のエージェントが協力してタスクを分担し、より高度な問題解決が可能です。 参考 : Amazon Bedrock のマルチエージェントコラボレーション機能の紹介 （プレビュー） 対応モデル Amazon Bedrock エージェントは Amazon Bedrock のすべてのモデルをサポートしています。 対応モデル一覧 その中でも エージェントのアーキテクチャとの統合用に微調整されたモデル は下記となります。 Amazon Nova Pro 1.0 Amazon Nova Lite 1.0 Amazon Nova Micro 1.0 Anthropic Claude 3.5 Sonnet V2 Anthropic Claude 3.5Haiku v1 Anthropic Claude Instant v1.2 Anthropic Claude v2.1 Anthropic Claude v2 Anthropic Claude 3 Sonnet v1 ツール Amazon Bedrock Agents では、「 アクショングループ 」 を活用してエージェントの動作を設定できます。 アクショングループは Lambda 関数 または OpenAPI を用いて定義することが可能です。 今回のサンプルアプリでは、3つ目のマルチエージェントとして 「チケット発券エージェント」 を実装しました。 このエージェントは、チャットボットによるヒアリングの後、サポート対応のためのチケットを作成し、データベースに格納する役割を担います。 本サンプルアプリでは、Lambda 関数にデータを書き込むためのソースコードを記述し、エージェントがトリガーを起こすことでデータベースへの書き込みを実現しています。 参考 : Amazon Bedrock のエージェントにアクショングループを追加する 料金 概要 Amazon Bedrock Agents では主に2つのサービスで費用が発生します。 基盤モデル利用料金 ベクトルデータベース料金 基盤モデル利用料金 対応している基盤モデルのうち、記事執筆時点で 非推奨となっていない モデルの費用は下記となります。 モデル名 入力トークンあたりの料金（1,000トークン） 出力トークンあたりの料金（1,000トークン） Amazon Nova Pro 1.0 $0.0008 $0.0032 Amazon Nova Lite 1.0 $0.00006 $0.00024 Amazon Nova Micro 1.0 $0.000035 $0.00014 Anthropic Claude 3.5 Sonnet V2 $0.003 $0.015 Anthropic Claude 3.5 Haiku V1 $0.0008 $0.004 Anthropic Claude 3 Sonnet V1 $0.003 $0.015 モデルトークン数の計算は、表現方法や文脈によって異なるため、正確な推測を行うことは困難です。特に、単語の長さや特殊な記号、改行、エンコーディングの違いなどが影響を与える可能性があります。 Claude（Anthropic の AI モデル）の場合、Anthropic が提供する Client SDKs 、あるいは Google Cloud 上で count-tokens エンドポイントを使用する ことで実際のトークン数を確認することが可能です。この SDK を利用することで、トークンのカウントを正確に把握し、適切なプロンプト設計やコスト管理を行うことができます。 例えば G-gen のホームページより引用した代表メッセージは文字数953（改行を除いた文字数）となり、トークン数は688となりました。 私たちは、2006年7月に設立したトップゲートと2021年8月に設立した G-gen が合併し新生 G-gen として新たにスタートしました。両社ともに Google Cloud のプレミアパートナーでありこの合併によって Google Cloud におけるアプリケーション開発からインフラ構築まで高い技術力を持ち、お客様により高い付加価値を提供できることになりました。 また、私たちは AWS 専業インテグレーターである株式会社サーバーワークスを親会社とし、世界でマルチクラウドインテグレーションを提供している Bespin Global Inc. とのジョイントベンチャーです。 サーバーワークスでは2009年から AWS に特化したインテグレーション事業を開始し、 AWS においては国内トップクラスの技術力と実績を有しています。一方でクラウド活用においては多様化が進み、様々なクラウドサービスを適切に活用していくことが今後のお客様の IT システムにおける最適解になりそうだと感じ始めています。そのなかで Google Cloud は生成 AI やデータ分析などにおいてユニークな技術を有しており、お客様の多様化するニーズに応えるために重要な役割を果たすと考えています。この私達が持つ Google Cloud のノウハウとサーバーワークスの持つ AWS のノウハウを連携しマルチクラウド環境においても各々の経験値を活かしたカスタマーサクセスを既に提供し始めています。 G-gen では Chromebook での業務も実践し、 Google の考える新しい世界を身を持って実現していこうと取り組んでいます。Google Cloud や Google Workspace を中心にクラウドサービスを適切に活用することにより、場所に縛られず、高セキュリティで、アジリティの高い IT システムを実現します。この新しい IT システムの世界を全てのお客様に提供することが私達のミッションであり、その先の DX によるお客様のビジネスの成功にも繋がっていくと確信しています。 私たちは Google Cloud のプロフェッショナルとしてお客様の「クラウドで、世界を、もっと、はたらきやすく」を実現していきます。 ベクトルデータベース料金 Bedrock で対応する Knowledge base は下記となります。 Amazon OpenSearch Serverless Amazon Aurora PostgreSQL Serverless Amazon Neptune Analytics 今回の事例ではAmazon Aurora PostgreSQL Serverless を利用しているため、Amazon Aurora PostgreSQL Serverless に絞った説明をいたします。 Amazon Aurora Serverless の料金はAurora Capacity Unit（ACU）の利用時間に応じて発生します。 ACUは処理能力の指標で、 1 ACU は以下に相当します。 項目 性能 メモリ 約2GiB 米国東部（バージニア北部）リージョンでは、Aurora Standard の料金は1 ACUあたり0.12 USD/時間です。 Azure AI Agent Services（Azure）の詳細 構成図 プロダクト一覧 Azure AI Agent Service Azure AI Agent Service は、Microsoft Azure 上で提供される AI エージェントの開発・デプロイを支援するサービスです。企業がカスタム AI アシスタントや自動化ソリューションを構築するための基盤を提供します。 Azure Cosmos DB Azure Cosmos DB は、Microsoft Azure が提供する グローバル分散型のマルチモデル データベース サービス です。柔軟なスケーリング、低レイテンシ、99.999% の可用性を提供し、NoSQL データベースとして利用されます。 Azure AI Foundry（旧Azure AI Studio） Azure AI Foundry（旧 Azure AI Studio）は、企業向けの AI 開発環境を提供するプラットフォームです。開発者やデータサイエンティストが、AI モデルの開発、トレーニング、デプロイを一元管理できるツールセットを備えています。 できること マルチエージェントの実現 現時点で、 Azure AI Agent Service はシングルエージェントの構築をサポート していますが、下記手段によりマルチエージェントを実現可能です。 AutoGen や Semantic Kernel などのフレームワークと連携 Azure AI Agent Service の AgentTeam クラスを利用 対応モデル Azure AI Agent Service で対応可能なモデルは下記となります。 gpt-4o, 2024-05-13 gpt-4o, 2024-08-06 gpt-4o-mini, 2024-07-18 gpt-4, 0613 gpt-4, 1106-Preview gpt-4, 0125-Preview gpt-4, turbo-2024-04-09 gpt-4-32k, 0613 gpt-35-turbo, 0613 gpt-35-turbo, 1106 gpt-35-turbo, 0125 gpt-35-turbo-16k, 0613 Meta-Llama-405B-Instruct Mistral-large-2407 Cohere-command-r-plus Cohere-command-r ツール Azure AI Agents は OpenAI の Assistants API を基盤とし、LLM の能力を汎用的なプログラムによるアクションと結びつけることで、強力な自動化機能を提供します。 Azure AI Agents は、「ナレッジツール」 と 「アクションツール」 の2種類のツールを提供し、エージェントのパフォーマンスと利便性を向上させます。 ナレッジツールは以下の3つのオプションを利用可能です。 Grounding with Bing Search File Search Azure AI Search アクションツールは以下の4つのオプションを利用可能です。 Function Calling Code Interpreter OpenAPI Specified Tools Azure Functions 今回のサンプルアプリでの3つ目のマルチエージェント 「チケット発券エージェント」では、 Function Calling を利用 し、データベースに書き込むための関数を実行することで実現可能です。 料金 Azure AI Agent Service は、下記料金に基づいて算出されます。 基盤モデル利用料金 ツールに対して発生する費用 基盤モデル利用料金 対応している基盤モデルのうち、記事執筆時点で非推奨となっていないモデルの費用は下記となります。 モデル名 入力料金（100万トークンあたり） 出力料金（100万トークンあたり） gpt-4o, 2024-05-13 $5.00 $15.00 gpt-4o, 2024-08-06 $2.50 $10.00 gpt-4o-mini, 2024-07-18 $0.15 $0.60 gpt-35-turbo, 0125 $0.50 $1.50 ツールに対して発生する費用 各ツールに関係する費用に関しては各ドキュメントをご参照ください。 参考 : Assistants API 参考 : Grounding with Bing Search 参考 : Azure AI Search さらに、 Azure Logic Apps や Azure Functions など、現在利用可能または将来追加される自動化に対しても料金が発生されることが公式ドキュメントに記載されております。 Playbooks（Google Cloud）の詳細 構成図 プロダクト一覧 Playbooks（Vertex AI Agents） Playbooks とは、チャットボット用のエージェントを構築するためのフルマネージドサービスです。 構築されたチャットボットは API 経由で利用したり、Conversational Agents （旧称：Dialogflow CX）を利用することでカスタマイズすることができます。 Playbook（旧称：Vertex AI Agents） について詳しくは以下の記事をご覧ください。 参考 : Vertex AI Agent Builder（Vertex AI Search/Agents）を徹底解説！ Cloud Run functions サーバレスのコンピューティングサービスです。 2024年夏にCloud Functions から Cloud Run functions としてリブランディングされました。 詳しくは以下の記事をご覧ください。 参考 : Cloud Run functionsを徹底解説！ Firestore スケーラブルでリアルタイム同期が可能な NoSQL ドキュメントデータベースです。 Cloud Storage Cloud Storage はフルマネージドなオブジェクトストレージです。 Google Agentspace（参考） Google でマネージドで管理されるAI エージェントとなります。 Gemini の高度な推論、Google 品質の検索、自社のデータが集約されたエージェントを使用して、従業員が企業の専門知識を活用することができます。 法人利用の場合は Google Cloud 上でエンタープライズ向け Agentspace を構築することが可能です。 記事執筆時点ではプレビュー段階のサービスとなっておりますため、本記事では詳しくは取り上げませんが、詳しくは下記記事をご覧ください。 参考 : Google Agentspaceを徹底解説！ できること マルチエージェントの実現 Instruction 部分に他のエージェントを呼び出す旨を指示することで実現可能です。 対応モデル 下記モデルを利用することが可能です。 Gemini 1.5 flash Gemini 1.5 flash 002（Preview） Gemini 1.0 pro 001 ツール ツールは下記を選択可能です。 名称 組み込みツール OpenAPI ツール データストアツール Function ツール 役割 Google によって管理 OpenAPIツールを使って外部APIに接続可能 データストアからユーザの質問に回答できる クライアントコードからアクセス可能だがOpenAPI ツールからはアクセスできない機能がある場合に利用 ツール | Vertex AI Agents | Google Cloud 料金 Playbooks のリクエスト回数に応じた費用が発生します。 サーバレスでフルマネージドなため、常時起動のインスタンス料金は発生しません。 Playbooks Chat は 1,000クエリで12USD となります。 まとめ Amazon Bedrock Agents（AWS） 専門的な知識を一定程度持った初級者から中級者に適したサービスです。 様々な基盤モデルに対応しており、高度な機能をローコードで実装可能です。 Azure AI Agent Service（Azure ） エンタープライズ向けの高度なエージェントシステム構築が可能な上級者向けのサービスです。 Microsoft のマネージドサービスと連携することが可能です。高い柔軟性と機能性を持つため、一定以上の技術力を持つ開発者や企業に特に適しています。 Vertex AI Playbooks（Google Cloud） 明快な料金体系と視覚的に分かりやすいインターフェースを備えているため、初級者から中級者向けのサービスであると言えます。 従来の NLP プラットフォームである Dialogflow に生成AIを統合することで、より強力な会話型エージェントをローコードで構築可能にしています。また 高度なデータ処理能力を備え、さまざまな規模の組織やビジネスにおいて、利便性の高いサービスです。 また、大幅な名称変更の予定があり、2025年4月に開催予定の Google Cloud Next にて大きな変更が発表される可能性があります。今後のリリース情報が楽しみなサービスです。 Risa (記事一覧) クラウドソリューション部クラウドデベロッパー課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資格保有。日々修行中です！ Follow @risa_hochiminh

G-gen の min です。先日、Looker Studio を使い、Google Cloud（旧称 GCP）の BigQuery のデータ可視化を試みた際に困ったことがありました。今回は、発生した問題と解決方法を記載します。同じ課題に直面した方の参考になれば幸いです。 やりたかったこと 発生した問題 原因調査 検証 解決方法 やりたかったこと Looker Studio では、複数のデータを結合して1つのデータセットとして扱うことができます。 参考 : Looker Studio での統合の仕組み また Looker Studio では、グラフから CSV 形式などでデータをエクスポートできます。 参考 : グラフからデータをエクスポートする 今回は、Google Analytics 4（GA4）のデータと BigQuery のデータを Looker Studio で結合し、可視化する必要がありました。最終的に、可視化したデータを CSV 形式でエクスポートすることを考えていました。 具体的な手順は以下のとおりです。 Looker Studio で新規レポートを作成し、GA4 をデータソース A として追加します。 Looker Studio に BigQuery の約210万行のデータを持つテーブルをデータソース B として追加します。 データソース A とデータソース B を内部結合し、結合されたデータソース C を作成します。データソース C は約30万行です。 データソース C をもとに表形式のグラフを作成します。 作成したグラフから、 CSV 形式でデータをエクスポートします。 発生した問題 手順5で、以下の警告メッセージが表示されました。 このグラフには切り捨てられたデータが含まれているため、エクスポートされたデータは完全なものではありません。 エクスポートボタンを押すと、ダウンロードが実行されましたが、ダウンロードされたデータは7万5千行のみでした。しかしエクスポートしようとした表には、実際には約30万行が記録されています。 原因調査 まず、警告メッセージとダウンロード行数に関連があるか調査しました。Looker Studio の公式ドキュメントを確認したところ、以下の記述がありました。 1 つのグラフからエクスポートできるデータは、750,000 行が上限となります。 参考 : グラフからのデータのエクスポートに関する制限 この情報から、警告メッセージとダウンロード行数は関連がなく、別の問題であることがわかりました。 次に、BigQuery コネクタに関する記述を見つけました。 BigQuery コネクタを使用して返すことができる最大行数は 200 万行です。Looker Studio では、200 万行を超えるデータがある場合は表示されますが、行数は明示されません。 参考 : 割り当てと一般的な上限 BigQuery のデータ可視化には、200万行の制限があることがわかりました。 検証 制限を回避するために、「やりたかったこと」の手順3で、結合前にデータソース B を200万行以下になるように絞り込みました。その結果、警告メッセージは表示されなくなりました。 公式ドキュメントの「行数は明示されません」という記述が気になったため、BigQuery 単体で表形式のグラフを作成し、行数が200万行を超えた場合の挙動を確認しました。 表形グラフでは、行数の最大が「2,000,000+」と表示されました。200万行を超える行へのページ送りはできませんでした。 次に、スコアカードを使用して同様のデータを表示したところ、正確な集計値が表示されました。 これは、スコアカードが集計結果のみを取得するため、行数制限の影響を受けなかったと考えられます。 実行されたクエリを確認したところ、以下でした。 SELECT COUNT ( 1 ) AS t0_qt_kpwfrzt8pd FROM `m-sasaki.sample_dataset.sample_data` AS t0 LIMIT 2000001 ; なお、Looker Studio から BigQuery に発行されるクエリは、以下の手順で確認できます。 BigQuery コンソールを開きます。 画面下部の[ジョブ履歴]から、対象のクエリのジョブ ID を選択します。 参考 : BigQuery に発行された SQL を表示する 解決方法 解決策は、データソースの結合前に、BigQuery から取得するデータを200万行以下にすることです。 例えば、特定の条件でデータを絞り込みたい場合、Looker Studio のデータの統合画面でフィルタを適用できます。このフィルタリングは、データ結合の前に実行されます。 参考 : 統合と明示的な期間およびフィルタ 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の溝口です。この記事では NotebookLM in Pro を使い、架空の会社に存在する社内データを用いたAIアシスタントの作成方法と機能の解説をします。 はじめに NotebookLM とは NotebookLM Enterprise とは Gemini アプリとの違い 事前準備 検証方法 ケース1 : 会社説明を作成させる ケース2 : 取り扱い製品について質問する ケース3 : 人事制度について質問する Studio 機能を使う Discover、音声概要、マインドマップ はじめに NotebookLM とは NotebookLM は、Google が提供する AI リサーチアシスタントです。ユーザーがアップロードしたドキュメントに基づいて、情報の要約、質問応答、ノート作成などを支援します。Google アカウントがあれば Web ブラウザから利用でき、料金は発生しません。無償で簡単に独自の生成 AI アシスタントを用意できるのが強みです。 NotebookLM in Pro とは、NotebookLM の有料プランです。無償プランとの主な違いとして、ノートブック数やソース数、1日のクエリ数、音声生成数などの上限が挙げられます。また、高度な機能や優先的なサポートも提供されます。NotebookLM in Pro は、NotebookLM のヘビーユーザーや、ビジネスでの利用に適しています。 NotebookLM NotebookLM in Pro 料金 無料 有料もしくは、GoogleWorkspace の対象プランに組み込み ノートブック数 100 500 ノートブックあたりのソース数 50 300 1日のチャットクエリ数 50 500 高度な機能 なし ・ 回答スタイルのカスタマイズ ・ 利用状況分析 など 1日のチャットクエリ数 50 500 1日の音声概要生成数 3 20 当記事では、多数のユーザーが NotebookLM を利用するビジネスシーンを想定して、無償版の NotebookLM ではなく、Google Workspace に組み込みの NotebookLM in Pro を利用します。 参考 : NotebookLM ヘルプ 参考 : NotebookLM の Pro 機能の詳細 参考 : NotebookLM を Pro プランにアップグレードする なお、NotebookLM in Pro は以前（2025年5月頃）まで NotebookLM Plus と呼ばれていました。個人向けサブスクリプションのプラン名が Google AI Pro に変更されたのに伴い、NotebookLM Plus は NotebookLM in Pro へと改名 されました。 NotebookLM NotebookLM Enterprise とは Google Cloud と統合され、より企業向けの企業が強化された NotebookLM Enterprise も存在します。NotebookLM Enterprise は Google Cloud と統合されており、より高度なセキュリティや統制を敷くことができます。 NotebookLM Enterprise で作成されたノートブックは、無償版 NotebookLM や Google Workspace の NotebookLM in Pro に対して共有することはできません。 NotebookLM の各エディションの違いについての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp Gemini アプリとの違い Google は、NotebookLM のほかにも、 Gemini アプリ という対話型 AI ツールを提供しています。NotebookLM と Gemini アプリの違いについては、以下の記事も参照してください。 blog.g-gen.co.jp 事前準備 まずは、NotebookLM in Pro が組み込まれているエディション（Business Standard/Plus や Enterprise Standard/Plus 等）の Google Workspace アカウントにログインした状態で、NotebookLM のページ（ https://notebooklm.google.com/ ）へアクセスします。 画面右上に「PRO」の表記があれば、お使いのエディションは NotebookLM in Pro です。 PRO の表記 画面中央の「+ 新規作成」ボタンを押下して、新しいノートブックを作成します。ノートブック画面が開いたら、画面左部分の「+ ソースを追加」ボタンを押下して、データソースを追加できます。 ソースを追加 データソースとして、以下のようなものが利用できます。 PC 上のファイルの直接アップロード Google ドライブ内にあるGoogle ドキュメント、Google スライド ウェブサイトリンクや Youtube リンク クリップボード内のテキスト ファイルのアップロードの際は、フォルダの一括アップロードはできませんが、ファイルを複数選択することができます。 ソースをアップロード NotebookLM in Pro には、回答のスタイルや、長さをカスタマイズする機能もあり、生成 AI からの回答をユーザーのニーズに合わせて調整できます。これは、無償版には備わっていない機能です。 カスタマイズ画面 作成されたノートブックは同じ Google Workspace 組織に所属する他のユーザに共有することができます。これにより、同じ組織の中で、カスタマイズした AI アシスタントを共同利用することができます。Google Workspace アカウントで NotebookLM in Pro を使っている場合、無償版（個人アカウント）の NotebookLM ユーザーや、他の Google Workspace 組織のユーザーには、ノートブックを共有することはできません。 共有画面 検証方法 実際の運用されているデータに近いものをサンプルとして用意しました。本記事に登場する会社情報、値及び作成された文章はすべて生成 AI で生成した架空のものです。 サンプル商事株式会社の概要 サンプル商事株式会社は、大阪に本社を置く石油化学製品を扱う総合商社です。創業50年の歴史を持ち、国内外に多くの取引先を持つ、業界屈指の企業です。 今回は一般的な企業が所有する「就業規定」や「給与規定」などの10以上の規定の他に、主に取り扱う化学製品の Wikipedia と、Youtube に掲載のある化学製品を紹介しているページを参照元にします。 アップロード後のソース画面 ケース1 : 会社説明を作成させる プロンプト 新人研修用にわかりやすく会社概要説明をお願いします サンプル商事株式会社の新人研修向け会社概要説明： サンプル商事株式会社は、 社員の能力を最大限に引き出し、会社の発展に貢献することを目的 としています。 事業の基本方針 能力主義 経営理念や事業戦略に合う人材を能力に基づいて採用します。 能力開発 社員の能力開発を支援し、会社の成長に貢献できる人材を育成します。 人事評価 社員の能力、業績、貢献度を公正に評価する人事評価制度を設けています。評価結果は、昇進、昇格、異動、賞与、給与に反映されます。 組織活性化 社員の能力開発、キャリア形成、組織活性化のため、異動を命じることがあります。 給与 従業員の給与は、基本給、諸手当、賞与で構成されます。 会計処理 公正妥当と認められる企業会計の基準に従い、会計期間は毎年4月1日から翌年3月31日までです。 顧客関係 顧客との良好な関係を構築し、顧客満足度向上を目指します。 情報管理 情報の適切な保護と利用を図ります。 これらの情報から、サンプル商事株式会社は、 社員の成長と公正な評価を重視し、効率的で活性化された組織運営を目指している と考えられます。 与えられたデータソースから企業概要を簡潔にまとめてくれました。 ケース2 : 取り扱い製品について質問する プロンプト キシレンの有害性はトルエンとどう違いますか？ キシレンとトルエンの有害性の違いについて、ソースから得られる情報は以下の通りです。 キシレンの有害性: トルエンと比較して、 皮膚腐食性、眼刺激性、生殖毒性、全身毒性が高い 。 毒劇物取締法 の劇物に該当する。 トルエンの有害性: 毒劇物取締法 の劇物に該当する。 シンナー中毒の原因となる。中枢神経系に影響を与える。 これらの情報から、キシレンはトルエンよりも 皮膚や目への刺激性、生殖機能への毒性、全身への毒性が強い と考えられます。 取扱製品の比較と注意点を出力してくれました。 ケース3 : 人事制度について質問する プロンプト 人事評価で重視するポイントはどこですか？ 人事評価で重視するポイントは、サンプル商事株式会社の人事規定によると、社員の 能力、業績、貢献度 です。 人事評価制度に関する詳細は以下の通りです 目的 : 社員の能力を最大限に引き出し、会社の発展に寄与すること 評価制度 : 社員の能力、業績、貢献度を公正に評価するための人事評価制度を設ける 評価方法 : 目標管理制度、360度評価、その他適切な方法 評価結果の活用 : 昇進、昇格、異動、賞与、給与などに反映 サンプル商事株式会社では、 能力主義 を基本とし、社員の 能力開発 を支援し、会社の 成長 に貢献できる人材を育成することを重視しています。人事評価は、社員の 昇進・昇格 、 異動 、 賞与 、 給与 などに反映され、社員の モチベーション向上 や キャリア形成 に繋がるように設計されています。 各規定から抜粋し記述してくれました。 Studio 機能を使う NotebookLM の Studio 機能は、アップロードされたソース文書から、さまざまなコンテンツを生成するための機能です。 Studio 機能を利用することで、アップロードされた文書や音声ファイルから、以下のようなコンテンツを生成することができます。この機能により、大量の情報を効率的に把握することができます。 音声概要の生成（2人の登場人物がコンテンツについて概要を語りあう音声を AI が生成。2025年2月現在、英語のみ対応） よくある質問 学習ガイド タイムライン（計画を時系列で整理） ブリーフィングドキュメント Studio 機能 サンプル商事では、Studio 機能を利用することで、石油化学物質、プラスチックの歴史、化学に関する FAQ、用語集などの解説ドキュメントやブリーフィング用のドキュメントを作成してくれました。 作成されたドキュメント一覧 作成されたブリーフィングメモ 作成されたドキュメントは、NotebookLM のソースとして利用することができます。 Discover、音声概要、マインドマップ NotebookLM には、さらに「Discover（ソースの発見）」「音声概要」「マインドマップ」などの応用機能があります。これらの機能については以下の記事で紹介していますので、併せてご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 溝口 直 (記事一覧) ビジネス推進部 営業2課 2023年10月よりG-gen にジョイン。 HRサービスを展開するベンチャー企業から、Google専業の営業へ。関西在住でGoogle Cloudをメインに活動中。育児と仕事のバランスを常に模索中・・

G-gen の杉村です。2025年2月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに 生成 AI アプリ保護のフルマネージドサービス Model Armor が公開 Google スプレッドシートの性能が改善 OneDrive から Google ドライブへのデータ移行ツールが一般公開 Gemini 2.0 Flash が GA。2.0 Flash Lite や 2.0 Pro も利用可能に NotebookLM（Plus）が Google Workspace がコアサービスに Gemini Code Assist で50ライセンスが1ヶ月間無料 IAP でWorkforce Identity Federation を使った認証が可能に BigQuery データセットが Marketplace で購入/販売可能に Spanner で Managed autoscaler が GA Google チャットに投票機能が登場 Looker Studio のテーブルで閲覧時に複数列の並べ替えができるように VPC Service Controls で「違反ダッシュボード」が Preview 公開 Sensitive Data Protection（旧 DLP）で日本の法人番号が検知可能に Cloud Run service で手動スケーリングが Preview 公開 Compute Engine で A4X VM が Preview 公開 Data Loss Prevention が Gmail で一般公開（GA） Cloud Run API での関数（functions）のデプロイが Preview -> GA Gemini Deep Research が Google Workspace で使用可能に Cloud SQL で最終バックアップが取得可能に（GA） Cloud DNS でパブリック IP ヘルスチェックが GA VPC Service Controls violation analyzer（違反アナライザー）が登場 Gemini in Looker で複数の生成 AI 機能が Preview 公開 Gemini 2.0 Flash-Lite が 一般公開 無償版の個人向け Gemini Code Assist が Public Preview 公開 Cloud SQL for PostgreSQLでプライマリとレプリカの同時アップグレード Vertex AI Agent Builder の answer メソッドで Personalize answers Vertex AI Agent Builder の search メソッドで関連度スコアが取得可能に はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 生成 AI アプリ保護のフルマネージドサービス Model Armor が公開 Model Armor overview (2025-02-03) 生成 AI アプリ保護のフルマネージドサービス Model Armor が公開。 不快なコンテンツやプロンプトインジェクション、データ漏洩等を検知・緩和。トークン数に応じた課金だが、無料枠あり。Security Command Center Premium が必要（プロジェクトレベルの有効化で OK）。 Google スプレッドシートの性能が改善 Additional improvements to everyday actions in Google Sheets (2025-02-03) Google スプレッドシートの性能が改善。 データの表示速度やスプシ間のデータのペースト時の速度、フィルタ条件指定時の表示速度などが性能向上する。昨年にも、関数やピボットテーブルなどの速度向上のアップデートがあったが、引き続いてのアップデートとなる。 OneDrive から Google ドライブへのデータ移行ツールが一般公開 Now generally available: Easily migrate files from Microsoft OneDrive to Google Drive (2025-02-04) OneDrive から Google ドライブへのデータ移行ツールが Google から一般公開。 最大100ユーザーのデータ移行が同時に実施可能。Google Workspace の特権管理者が使用できる。 以下の記事も参照。 blog.g-gen.co.jp Gemini 2.0 Flash が GA。2.0 Flash Lite や 2.0 Pro も利用可能に Gemini 2.0 is now available to everyone (2025-02-05) Vertex AI や Google AI Studio で新しいモデルが利用可能に。 Gemini 2.0 Flash （プレビュー → 一般公開） Gemini 2.0 Flash Lite（[NEW] プレビュー） Gemini 2.0 Pro（[NEW] 試験運用版） NotebookLM（Plus）が Google Workspace がコアサービスに NotebookLM and NotebookLM Plus now available as a Google Workspace core service with enterprise-grade data protection (2025-02-05) NotebookLM と NotebookLM Plus が Google Workspace がコアサービスとして利用可能に。 エンタープライグレードのデータ保護により企業データは Google に利用されない。2025-02-05から順次リリース。 Gemini Code Assist で50ライセンスが1ヶ月間無料 Gemini Code Assist release notes - January 30, 2025 (2025-01-30) Gemini Code Assist で、初めて契約する場合に限り、50ライセンスが1ヶ月間無料。 デフォルトだと自動更新なので注意。設定で自動更新をオフにできる。 以下の記事も参照。 blog.g-gen.co.jp IAP でWorkforce Identity Federation を使った認証が可能に Configure IAP with Workforce Identity Federation (2025-02-07) Identity-Aware Proxy（IAP）でWorkforce Identity Federation を使った認証が可能に（GA）。 Okta や Entra ID、ADFS など外部 IdP から SAML や OIDC を使って、Google Cloud でホストしたアプリに認証する仕組みを簡単に実装できる。 BigQuery データセットが Marketplace で購入/販売可能に BigQuery datasets now available on Google Cloud Marketplace (2025-02-08) BigQuery データセットが Google Cloud Marketplace で購入/販売可能になった。 データは Analytics Hub を通して公開され、データを複製することなく共有できる。データの購入や販売を、Google Cloud の仕組みを通して適切に行うことができるようになった。企業が保有データをマネタイズするためのプラットフォームができあがったといえる。 Spanner で Managed autoscaler が GA Managed autoscaler (2025-02-11) Spanner で Managed autoscaler 機能が GA。 有効化すると負荷の増減に応じて自動的にスケールアップ/ダウン。CPU負荷やストレージ使用率に応じて反応。ストレージは自動的に再シャーディング。リードレプリカだけのスケールアウトも可能。 以下の記事も参照。 blog.g-gen.co.jp Google チャットに投票機能が登場 Create and vote on polls directly in Google Chat (2025-02-11) Google チャットに投票機能が登場。簡単にチャット参加者から意見を募ることができる。 Looker Studio のテーブルで閲覧時に複数列の並べ替えができるように Sort your data (2025-02-13) Looker Studio のテーブルで、レポート閲覧時に Shift キーを押しながら列をクリックすることで複数列で並べ替えができるように。 これまでは表の編集時にのみ、「サブの並べ替え」で2列まで設定できた。 VPC Service Controls で「違反ダッシュボード」が Preview 公開 Set up and view the violation dashboard (2025-02-14) VPC Service Controls で「違反ダッシュボード」が Preview 公開。 境界への違反が一覧表示できるダッシュボード。以下のブログ記事を参照。 blog.g-gen.co.jp Sensitive Data Protection（旧 DLP）で日本の法人番号が検知可能に InfoType detector reference (2025-02-14) Sensitive Data Protection（旧 Data Loss Prevention、DLP）で日本の法人番号が検知できるように。 InfoType として JAPAN_CORPORATE_NUMBER が追加された。Sensitive Data Protection とは、BigQuery や Cloud Storage 等から機密情報を検知、保護できるサービス。 Cloud Run service で手動スケーリングが Preview 公開 Manual scaling (2025-02-18) Cloud Run service で手動スケーリングが Preview 公開。 コンテナインスタンス数を手動で指定可能。Cloud Scheduler で Cloud Run API を叩くことでスケジュールに基づいたスケーリングもノーコードで実現。 以下の記事も参照。 blog.g-gen.co.jp Compute Engine で A4X VM が Preview 公開 Introducing A4X VMs powered by NVIDIA GB200 — now in preview (2025-02-20) Compute Engine で A4X VM が Preview 公開。 72 個の NVIDIA Blackwell GPU と 36 個の Arm ベースの NVIDIA Grace CPU を搭載した NVIDIA GB200 NVL72 がベース。chain-of-thought やマルチモーダルモデルなどの推論に利用。 Data Loss Prevention が Gmail で一般公開（GA） Workspace data loss protection (DLP) for Gmail is now generally available (2025-02-18) Data Loss Prevention（DLP、データ流出防止）が Gmail で一般公開（GA）。 従来から Google ドライブ、Google チャットで利用可能。本文、添付ファイル、ヘッダー、件名などから機密情報を検知してブロックまたは通知。 Cloud Run API での関数（functions）のデプロイが Preview -> GA Cloud Run functions (formerly known as Cloud Functions) release notes - February 19, 2025 (2025-02-19) Cloud Run API 経由での関数（functions）のデプロイが Preview -> GA。 ただし引き続き Cloud Functions v2 API も使用可能。今後、Cloud Run API のほうに寄せられていく可能性がある。 Google Cloud コンソールでも、Cloud Run functions の独自画面が消えて、Cloud Run に統合された（第1世代 function が存在しないプロジェクトのみの可能性あり）。 Gemini Deep Research が Google Workspace で使用可能に Gemini Deep Research and experimental models now available to Google Workspace users in Gemini Advanced (2025-02-20) Gemini Deep Research が Google Workspace で使用可能に。 Business Standard 以上のエディションで利用可能。Gemini ウェブアプリから実行できる。2025-02-20から順次リリース。 Gemini Deep Research では、AI がインターネットから情報収集してレポートを作成。業界調査、顧客調査、教育・研究などに活用できる。 Cloud SQL で最終バックアップが取得可能に（GA） Final backups (2025-02-20) Cloud SQL で最終バックアップが取得可能に（GA）。 Cloud SQL のインスタンス削除時に、最終バックアップが取得可能になった。保持期間は1日〜最長365日。 インスタンスを削除すると自動バックアップも手動バックアップもすべて削除されるので、従来までは Cloud Storage へのダンプファイルのエクスポートが必要だった。 Cloud SQL のバックアップについては以下の記事を参照。 blog.g-gen.co.jp Cloud DNS でパブリック IP ヘルスチェックが GA Introducing Cloud DNS public IP health checks, for more resilient multicloud deployments (2025-02-22) Cloud DNS でパブリック IP ヘルスチェックが GA。 パブリック IP を最も地理的に近いリージョンからヘルスチェックして、正常でない場合は別の IP アドレスに名前解決する。マルチリージョン、あるいはマルチクラウドのフェイルオーバーに使える。 VPC Service Controls violation analyzer（違反アナライザー）が登場 Diagnose an access denial event using the VPC Service Controls violation analyzer (2025-02-24) VPC Service Controlsでviolation analyzer（違反アナライザー）が登場。 境界違反ログに一意のIDであるトラブルシューティングトークン（vpcServiceControlsUniqueId）が記録され、そのIDから辿ると何が原因で拒否されたかを確認できる画面が見られる。 VPC Service Controls 違反アナライザー Gemini in Looker で複数の生成 AI 機能が Preview 公開 Looker release notes - February 24, 2025 (2025-02-24) Gemini in Looker で以下の2つの生成 AI 機能が登場（Public Preview）。 自然言語による LookML の生成 自然言語によるカスタムフォーマット生成 Looker バージョン 25.2 以降で対応。上記に加えて、対話式に分析を行える Conversational Analytics も Preview。 Gemini 2.0 Flash-Lite が 一般公開 Gemini 2.0 (2025-02-25) Gemini 2.0 Flash-Lite が Preview から一般公開に。2.0 Flash より軽量で料金が安い。料金面やスピード面で 1.5 Flash ユーザーにとってのアップグレードパスとされている。 1M のマルチモーダルインプット 8k のテキストアウトプット Gemini 系モデルの現在のリリース状況は、以下のとおり。 Gemini 2.0 Pro : Experimental（試験運用版） Gemini 2.0 Flash : GA（一般公開） Gemini 2.0 Flash Thinking : Experimental（試験運用版） Gemini 2.0 Flash-Lite : GA（一般公開） 無償版の個人向け Gemini Code Assist が Public Preview 公開 Get coding help from Gemini Code Assist — now for free (2025-02-26) 無償版の個人向け Gemini Code Assist が Public Preview 公開。 Gemini 2.0 によるコード生成、補完、修正。VSCode などの IDE で利用可能。無償版は1か月あたり最大180,000件のコード補完。 また、GitHub レポジトリのコードレビュー・修正提案も無料で利用できる。 Cloud SQL for PostgreSQLでプライマリとレプリカの同時アップグレード Include replicas in the major version upgrade (2025-02-26) Cloud SQL for PostgreSQL で、メジャーバージョンのアップグレード時に、レプリカもアップグレードできるようになった。 現状では、gcloud と REST での操作のみ。コンソールからは不可。まずプライマリインスタンスがアップグレードされ、次にレプリカインスタンスがアップグレードされる。 Vertex AI Agent Builder の answer メソッドで Personalize answers Personalize answers (2025-02-26) Vertex AI Agent Builder（Vertex AI Search）の answer メソッドで Personalize answers が利用可能に（GA）。 リクエスト時に endUserMetadata オブジェクトを渡すことで回答がパーソナライズされる。 Vertex AI Agent Builder の search メソッドで関連度スコアが取得可能に Get document-relevance score with search results (2025-02-28) Vertex AI Agent Builder（Vertex AI Search）で検索結果から関連度スコアが取得可能に（GA）。 0〜1.0の間でクエリと検索結果ドキュメントの関連度を返す。search メソッドのリクエスト時に "returnRelevanceScore": true に設定することで取得できる。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの菊池です。当記事では、Looker の 対称集計機能 について解説します。 対称集計とは 対称集計が必要になる状況 対称集計の仕組み 対称集計の使い方 必要な設定 一意の主キー（primary_key） 正しい結合関係（relationship） 対称集計とは 対称集計 は、Looker の標準機能です。Looker では、複数のテーブルを結合して利用する場合があります。結合するテーブル間の関係が「1対多」の場合、集計関数（カウント、合計、平均など）で値を求めると、一部の値が二重にカウントされる可能性があります。集計結果が誤った値にならないように、本来はテーブルを結合する段階で考慮が必要です。 しかし Looker では、ユーザーが明示的に対処しなくても、対称集計機能を用いることでデータの二重カウントを気にせずにテーブルを結合して集計できます。 参考 : 対称集計について  |  Looker  |  Google Cloud 対称集計が必要になる状況 ここでは、対称集計が必要な状況と、対象集計がない場合に発生する問題について説明します。 顧客テーブル（ customers ）と注文テーブル（ orders ）の2つのテーブルがあるとします。それぞれのテーブルは、以下の列を持っています。 顧客テーブル（ customers ） 顧客番号（ customer_id ） 名前（ name ） 訪問回数（ visits ） 注文テーブル（ orders ） 注文番号（ order_id ） 金額（ amount ） 顧客番号（ customer_id ） 1人の顧客が複数の注文をする可能性があるため、顧客テーブルと注文テーブルの関係は「1対多」です。 各テーブルで SQL を使い COUNT や SUM 演算を行うと、以下のようになります。 顧客テーブルの COUNT(*) で顧客数は 3、sum(visits) で訪問回数の合計は 8 注文テーブルの COUNT(*) で注文数は 4、sum(amount) で金額の合計は 250 顧客ごとの注文数を知るために、2つのテーブルを結合します。2つのテーブルに共通する顧客番号で紐づけて結合するのが一般的です。 1対多のテーブルを結合すると、行数が少ないテーブルの行が重複します。 例では、顧客テーブルのAmeliaは2回注文しているため、結合後のテーブルでは2行になります。 ここで、結合後のテーブルで、最初に求めたカウントと合計を計算します。 COUNT(*)=4で注文数と一致するが、顧客数とは一致しない sum(amount)=250は金額の合計と一致するが、sum(visits)=10は訪問回数の合計とは一致しない 注文テーブルの集計は結合後のテーブルでも一致しますが、顧客テーブルの集計は一致しません。 このように、1対多のテーブルを結合すると、 行数が少ないテーブルの数値が重複カウントされ、誤った集計値になり ます。 Lookerの対称集計はこのような1対多のテーブル結合による重複カウントを防ぐことができます。 対称集計の仕組み Looker では、顧客テーブル（ customers ）や注文テーブル（ orders ）を view ファイルとして保持します。また、顧客ごとの金額を算出するには、 model ファイルでテーブルの結合を定義します。 Looker では、 Explore で表示したいフィールドを選ぶと、表やグラフで結果を可視化できます。この時、Looker はバックグラウンドで SQL クエリを生成し、データベースに送信してデータを取得します。 訪問回数と金額のフィールドを表示する際、対称集計機能がないと、各列を 単純に合計する SQL が生成されます。この SQL では、前述した重複集計の問題が発生します。 しかし、Looker には標準で対称集計機能があるため、SQL クエリは以下のように自動で修正されます。 結合後のテーブルで訪問回数（ visits ）の合計を正確に集計するための対称集計の計算方法を説明します。 Looker は、MD5 ハッシュ関数で主キーごとに一意の数値を生成し、割り当てます。顧客名が Amelia の2つの行には、同じ big_unique_number が割り当てられます。 そして、正確な訪問回数を計算するために、以下の計算式を使用します。 SUM ( DISTINCT visits + big_unique_number ) - SUM ( DISTINCT big_unique_number ) 通常の SUM(DISTINCT) 関数だけで計算する場合、visits の値だけで同じ顧客のレコードかどうかを判断してしまいます。訪問回数が2回になっている3つのレコードを同じ顧客のレコードとみなした結果、訪問回数の合計は「6回」となり、誤った値になります。 ハッシュを付与する理由は、visits の値だけでは同じ顧客のレコードを特定できないためです。主キーである顧客ID（ customer_id ）ごとに一意のハッシュ値を割り当てることで、訪問回数が同じ2回のレコードでも、Amelia と Charles のレコードを区別できます。 顧客ID（ customer_id ）ごとの訪問回数+ハッシュ値の合計を算出し、そこからハッシュ値の合計を引くことで、正確な訪問回数の合計を計算します。 対称集計の使い方 必要な設定 これらの計算は Looker が自動で実行するため、ユーザーが理解したり、意識する必要はありません。 Lookerの対称集計機能は標準で有効であり、ユーザーが明示的に有効にする必要はありません。ただし、対称集計を正しく動作させるには、view ファイルと model ファイルの Explore で、以下の2つの項目を正しく定義する必要があります。 一意の主キー（ primary_key ） 正しい結合関係（ relationship ） 一意の主キー（primary_key） レコードを一意に識別できる列が主キーです。 主キーは、図のように primary_key で指定します。対称集計を有効にするには、結合するすべてのテーブルに主キーを設定する必要があります。 主キーが一意なキーとして機能しているか確認するには、テーブルのカウントと主キーのカウントが一致するかを確認します。一致しない場合は、各行を一意に識別できる列を探します。ない場合は、複数の列で一意に識別できるもの（複合主キー）を探します。 ただし、 primary_key: yes パラメータを設定できるのは view 内で1つのディメンションのみですので、複合主キーを利用する場合は、必要な列を連結して新しいディメンションを作成します。 正しい結合関係（relationship） テーブルを結合する際は、テーブル間の正しい関係を定義する必要があります。 結合関係は、図のように model ファイル内で relationship の値を設定します。 relationship には、左右のテーブルという概念があります。 join パラメータの前にあるビュー（画像では order ）を左側、 join パラメータの右にあるビュー（画像では customers ）を右側とします。 テーブル間の関係は、 relationship で以下の4つの値のいずれかを指定して定義します。 値 関係 one_to_one 1対1の関係。2つのテーブルが1対1に紐づく。 one_to_many 1対多の関係。左のテーブルの1行が右のテーブルの複数行に紐づく。 many_to_one 多対1の関係。左のテーブルの複数行が右のテーブルの1行に紐づく。 many_to_many 多対多の関係。左のテーブルの複数行が右のテーブルの複数行に紐づく。 テーブル間の関係が上記の4つのうちどれに該当するかを確認するには、データ同士の関係を文章で考えてみます。 1人の顧客は1つの注文にのみ関連付けられる 1人の顧客は複数の注文に関連付けられる 複数の顧客は1つの注文にのみ関連付けられる 複数の顧客は複数の注文に関連付けられる 今回のテーブルで実際にあり得る関係は 2. であるため、顧客と注文の関係は one_to_many です。 菊池 健太 (記事一覧) クラウドソリューション部データアナリティクス課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、GCPは未経験なので現在勉強中。

G-gen の佐々木です。当記事では、Google Cloud で新規プロジェクトを作成する際の注意点として、プロジェクト ID 重複に関する仕様について解説します。 プロジェクトの識別情報について 新規プロジェクト作成時に ID が重複していた場合の動作 コンソールからプロジェクトを作成する場合 コンソール以外からプロジェクトを作成する場合 ID の重複を事前に知ることはできない プロジェクト ID 重複エラーを想定した実装 プロジェクトの識別情報について Google Cloud のプロジェクトを識別するための情報としては、 プロジェクト名 、 プロジェクト ID 、 プロジェクト番号 の3種類があります。このうち、Google Cloud の全利用者のどのプロジェクトと重複してはいけない（ グローバルに一意 となる）ものはプロジェクト ID とプロジェクト番号の2つです。 識別情報 一意性 説明 プロジェクト ID グローバルに一意 プロジェクト作成時にユーザー側で指定できる。 プログラムからの操作時に対象プロジェクト指定に 使用されることが多い プロジェクト番号 グローバルに一意 プロジェクト作成時に自動で払い出され、ユーザー側 では指定できない。デフォルトのサービスアカウント などリソース ID の一部として使用されることがある プロジェクト名 なし 表示名（display name）と呼ばれることもある。 同じ組織、フォルダ内でも重複可能 参考： プロジェクトの作成と管理 新規プロジェクト作成時に ID が重複していた場合の動作 コンソールからプロジェクトを作成する場合 Google Cloud コンソールで新規プロジェクトを作成する場合、プロジェクト名を入力すると、プロジェクト ID が自動で決定されます。このとき「編集」を押下することでユーザー側で変更することもできます。 入力されたプロジェクト名がそのままプロジェクト ID として使用できない、つまりグローバルに一意になっていない場合は、 {プロジェクト名}-{ランダムの数字} という形式で、グローバルに一意の ID が提案されます。 プロジェクトIDが重複している場合、グローバルに一意のIDが提案される コンソール以外からプロジェクトを作成する場合 gcloud コマンドや REST API、クライアントライブラリなど、コンソール以外の方法でプロジェクトを作成する場合、任意のプロジェクト ID を指定して作成リクエストを送信しますが、 プロジェクト ID が重複している場合はエラーとなります 。 コンソールからプロジェクトを作成する場合のように、指定した ID が使用できない場合に、自動で一意の ID を使用してくれるような仕組みはありません。 たとえば、 gcloud projects create コマンドでプロジェクトを作成する際、プロジェクト ID に重複がある場合は以下のようなエラーが返ります。 $ gcloud projects create myproject ERROR: ( gcloud.projects.create ) Project creation failed. The project ID you specified is already in use by another project. Please try an alternative ID. ID の重複を事前に知ることはできない コンソール以外からプロジェクトを作成する場合、たとえばスクリプトを用いて自動でプロジェクトを作成したい場合などでは、「まず ID が現在使われていないか検索し、使われていなければその ID でプロジェクトを作成」すればよいと考えるかもしれませんが、これは上手くいきません。 プロジェクトに関する操作を行うことができる Resource Manager API のうち、特定のプロジェクトの検索に使用できるメソッドは projects.get と projects.search の2種類があります。それぞれ gcloud コマンドの gcloud projects describe と gcloud alpha projects search と対応しています。 gcloud projects describe コマンドで使用されていないプロジェクト ID を検索した場合、以下のようなエラーが返ってきます。 $ gcloud projects describe { 使用されてないプロジェクトID } ERROR: ( gcloud.projects.describe ) [ example@g-gen.co.jp ] does not have permission to access projects instance [ { 使用されてないプロジェクトID } ] ( or it may not exist ) : The caller does not have permission. This command is authenticated as example@g-gen.co.jp which is the active account specified by the [ core/account ] property エラーメッセージに does not have permission to access projects instance [{使用されてないプロジェクトID}] (or it may not exist) とあるように、「指定した ID のプロジェクトに対するアクセス権がない」ため失敗したのか、「指定した ID のプロジェクトが存在しない」ため失敗したのか判別できなくなっています。REST API を直接叩いた場合は、どちらのケースでもステータスコード 403 が返ります。 次に、 gcloud alpha projects search コマンドを使用する場合の例です。 $ gcloud alpha projects search --query =" projectId={使用されてないプロジェクトID} " （空のレスポンス） search コマンドは「コマンドを実行したユーザーがアクセスできる範囲内で検索する」仕様になっており、「アクセス権のないプロジェクトの ID を検索した場合」と「存在しないプロジェクト ID を検索した場合」のどちらも空のレスポンスが返ってきます。REST API を直接叩いた場合、どちらのケースでもステータスコード 200 が返るようになっています。 このように、あるプロジェクト ID が現在使用されているか調べようとしても、API の仕様により「その ID を持つプロジェクトが存在していてアクセス権がない」ケースと「その ID を持つプロジェクトが存在しない」ケースの識別ができません。 プロジェクト ID 重複エラーを想定した実装 スクリプトを用いてプロジェクトを払い出す仕組みを開発する場合は、ID 重複時のエラーを想定した実装にする必要があります。 たとえば以下の Python コードでは、実行時にプロジェクト ID を入力し、ID 重複によりプロジェクトの作成が失敗すると、別の ID を入力するように要求しています。 from google.cloud import resourcemanager_v3 from google.api_core.exceptions import AlreadyExists import sys, time def create_project (project_id: str ) -> bool : """ 引数の ID を元にプロジェクトを作成する Args: project_id (str): プロジェクト ID Returns: bool: プロジェクト作成の成否 """ client = resourcemanager_v3.ProjectsClient() request = resourcemanager_v3.CreateProjectRequest( project=resourcemanager_v3.Project( project_id=project_id, display_name=project_id, ) ) try : operation = client.create_project(request=request) print ( "Create project requested." ) while not operation.done(): print ( "Waiting for project creation..." ) time.sleep( 5 ) print ( "Create Project succeeded." ) return True # プロジェクト ID 重複時の例外処理 except AlreadyExists: print (f "Project ID {project_id} is already exists." ) return False except Exception as e: raise Exception (e) if __name__ == "__main__" : id = input ( "Enter new project ID: " ) try : while not create_project( id ): # プロジェクト作成が成功するまで別の ID の入力を要求する id = input ( "Enter another project ID: " ) except Exception as e: print (f "Create project failed. {e}" ) sys.exit( 1 ) print (f "Project {id} created." ) sys.exit( 0 ) このほかには、ID にランダムなサフィックスを追加して再実行したり、再実行をせずにエラー通知を行ったりといった実装が考えられます。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805