G-gen の杉村です。Google Cloud の Dataplex を活用することで、BigQuery や Cloud Storage などで構成された データ分析基盤の権限管理を抽象化して、簡素に運用することができます。当記事では、Dataplex による権限管理の仕組みを、図を交えて解説します。 はじめに Dataplex とは Dataplex による権限管理 メリット 前提知識 IAM の基本 レイク、ゾーン、アセット、エンティティ 注意点 サンプルアーキテクチャ Google アカウントとクエリ実行プロジェクト Google アカウントと Dataplex リソース 紐付きの意味 ロールの詳細（データへのアクセス） ロールの詳細（メタデータへのアクセス） サービスエージェントとデータ保持プロジェクト 管理ユーザーインターフェイス Dataplex リソース管理 権限管理 リソースの検索（Dataplex Univeresal Catalog） Dataplex アセットの検索 その他のリソースの検索 Dataplex Universal Catalog の詳細 導入 Dataplex の初期導入 通常の IAM の権限管理からの移行 既存の BigQuery データセットへの権限調査 Tips : 列レベルのアクセス制御・行レベルのセキュリティとの併用 はじめに Dataplex とは Dataplex は Google Cloud（旧称 GCP）で提供されている、データの統合管理のためのフルマネージドサービスです。詳細は、以下の記事で紹介されています。 blog.g-gen.co.jp Dataplex の数ある機能の中でも、当記事では、BigQuery や Cloud Storage などのデータアセットに対する 権限管理 の仕組みについて解説します。 参考 : Dataplex の概要 参考 : IAM によるアクセス制御 Dataplex による権限管理 一般的に、BigQuery や Cloud Storage などの Google Cloud リソースに対するアクセス制御は、Identity and Access Management（IAM）で行われます。 しかし、データマネジメントの背景で、リソースが多くのプロジェクトに分散していたり、データ利用者の数が多数の場合、IAM を使った従来型の権限管理は煩雑になり、適切なアクセス制御のための権限管理の運用が難しくなる場合があります。 Dataplex では、レイク、ゾーン、アセットといった抽象オブジェクトを用いて、 権限管理のための仮想的な階層 を構成することで、データ分析基盤（データマネジメント基盤）の権限管理を容易にできます。データの仮想化階層を構成することで、物理的にはデータが分散していながら、論理的には適切に管理されている データメッシュ を目指すのが、Dataplex のコンセプトです。 データメッシュについての詳細は、以下の記事をご参照ください。 参考 : Dataplexを徹底解説！ - G-gen Tech Blog - データメッシュとは メリット Dataplex でデータへのアクセス権限を管理するメリットとして、以下のようなものが挙げられます。 様々なプロジェクトに分散したデータの 権限管理を集約 ユーザーにとって 意味のある単位 （レイク、ゾーン等）で 権限を付与 できる 前提知識 IAM の基本 当記事では、Google Cloud の IAM の基本的な仕組み（ IAM bindings 、 ロール 、 継承 等）が理解されていることを前提に記載しています。これらの概念については、以下の記事をご参照ください。 blog.g-gen.co.jp レイク、ゾーン、アセット、エンティティ レイク 、 ゾーン 、 アセット 、 エンティティ は、それぞれデータ管理のための仮想的な階層です。 レイクは、データのドメインやビジネスユニット（部門）によって切り分ける、論理的な管理単位です。Dataplex の管理単位としては一番大きいものです。 ゾーンは、レイクの下位階層の管理単位です。データの種類やセキュリティレベルなどによって切り分けます。 アセットは、最小の管理単位です。1つのアセットは、1つの Cloud Storage バケットまたは BigQuery データセットに対応します。アセットとして登録する Cloud Storage バケットや BigQuery データセットは、Dataplex の管理プロジェクトとは別のプロジェクトに存在していて構いません（ただし、別組織のリソースは登録できません）。 アセットに Cloud Storage バケットまたは BigQuery データセットを登録すると、中身のオブジェクトやテーブル等が自動的にエンティティとして登録されます。 参考 : Dataplex の概要 - 用語 注意点 ゾーンは 1つのレイクにしか所属できません 。 また、ゾーンの下位リソースであるアセットも、 1つのゾーンにしか所属できません 。 サンプルアーキテクチャ 当記事では、以下のような簡易的な構成を用いて、Dataplex の権限管理の仕組みを解説します。 ここでは、以下のようなプロジェクトを考えます。 プロジェクト名 概要 dptest-workload-a クエリを実行するためのプロジェクト（ユーザー dptest-user-a 向け） dptest-workload-b クエリを実行するためのプロジェクト（ユーザー dptest-user-b 向け） dptest-data-001 BigQuery データセットが配置されているプロジェクト（A 部署向け） dptest-data-002 BigQuery データセットが配置されているプロジェクト（B 部署向け） dptest-dataplex Dataplex の設定管理用のプロジェクト ユーザーとしては、それぞれ異なる部署に所属する dptest-user-a と dptest-user-b を想定します。 また、プロジェクト dptest-dataplex には、サービスエージェントである service-${プロジェクト番号}@gcp-sa-dataplex.iam.gserviceaccount.com が存在します。これは、Dataplex API を有効化すると自動的に作成される、特殊なサービスアカウントです。 上記の図に、IAM ロールの紐付きを書き加えると、以下のとおりです。 青い線とその上に書かれているロール名は、プリンシパルがリソースに対してどのロールを持っているか（IAM bindings）を表します。 ここからは、各ロール紐付き（IAM bindings）の意味について説明します。図と見比べながら、解説文をお読みください。 Google アカウントとクエリ実行プロジェクト Google アカウント（またはグループ）すなわちデータ分析基盤のユーザーは、クエリ実行用のプロジェクトに対して BigQuery ジョブユーザー（ roles/bigquery.jobUser ）ロールを持ちます。 これにより、BigQuery のコンピュートリソースを消費してジョブを実行する権限が得られます。ジョブ実行権限は、データへのアクセス権限とは関係ありません。また、BigQuery のコンピュート料金は、ジョブを実行したプロジェクトに課金されます。 BigQuery の IAM 権限については、以下の記事でも詳細に解説しています。ジョブ実行権限とデータアクセス権限の分離の概念についても解説されていますので、ご参照ください。 blog.g-gen.co.jp Google アカウントと Dataplex リソース 紐付きの意味 Google アカウントは、Dataplex のアセットに対して、Dataplex データオーナー（ roles/dataplex.dataOwner ）や Dataplex データリーダー（ roles/dataplex.dataReader ）のロールを持っています。 これにより、アセットに登録されている BigQuery データセットや Cloud Storage バケットに対してのデータアクセス権限が付与されます。 Dataplex データオーナー（ roles/dataplex.dataOwner ）であれば、データセット内のテーブルに対して読み取り、書き込み、テーブルの削除や作成の権限を持ちます。Dataplex データリーダー（ roles/dataplex.dataReader ）は、読み取りのみです。 図ではアセットにロールを紐付けていますが、レイクにロールを紐付けた場合、配下のすべてのゾーンやアセットに権限が 継承 されます。ゾーンにロールを紐付けた場合、配下のすべてのアセットに権限が継承されます。アセットの中の個々のエンティティには、直接ロールを紐付けることはできません。 なお、ゾーン、レイク、アセットには、Dataplex や BigQuery データセットとは別の組織（Organization）のアカウントでも、ロールを付与することができます。これにより、Google アカウントのドメインが異なる協力会社やグループ会社のアカウントの権限管理も、Dataplex で行うことができます。 ロールの詳細（データへのアクセス） レイク、ゾーン、アセットに紐付けられるロールは、以下の3種類です。 ロール 実行可能なアクション Dataplex データリーダー (roles/dataplex.dataReader) データとメタデータの読み取り Dataplex データライター (roles/dataplex.dataWriter) データの書き込み、変更、削除（メタデータは不可。またデータの読み取りも不可） Dataplex データオーナー (roles/dataplex.dataOwner) データとメタデータの読み取り、書き込み、変更、削除。子リソースの作成（BigQuery テーブル等） 参考 : Dataplex IAM ロール - データロール なお、2025年4月現在の当社の検証では、Dataplex データライター（ roles/dataplex.dataWriter ）だけを付与されたプリンシパルは、BigQuery テーブルへ INSERT や UPDATE を実行できませんでした。Dataplex データライター（ roles/dataplex.dataWriter ）と Dataplex データリーダー（ roles/dataplex.dataReader ）の両方を付与した場合に、INSERT や UPDATE が可能になりました。 ロールの詳細（メタデータへのアクセス） 前述の3ロールは、データそのものへのアクセス権限を付与するものです。もし、利用者には データそのものへのアクセス権限は与えず 、 メタデータだけ を閲覧したり検索したりさせたい場合などには、以下のロールも利用できます。 ロール 実行可能なアクション Dataplex メタデータ読み取り (roles/dataplex.metadataReader) ゾーンやアセットのメタデータの読み取り Dataplex メタデータ ライター (roles/dataplex.metadataWriter) ゾーンやアセットのメタデータの読み取りと書き込み、変更、削除 ただし、Dataplex Univeresal Catalog で検索を実行する場合、検索実行者は上記のロールだけでなく、Dataplex Catalog 閲覧者（ roles/dataplex.catalogViewer ）ロール等を検索実行プロジェクトに対して持っている必要があります。 例えばアカウント dptest-user-a は、自身用のクエリ実行プロジェクトである dptest-workload-a プロジェクトに対して Dataplex Catalog 閲覧者（ roles/dataplex.catalogViewer ）ロールを持ち、かつゾーン my-zone-001 に対して Dataplex メタデータ読み取り（ roles/dataplex.metadataReader ）ロールを持っているとします。 この場合、アカウント dptest-user-a は、 dptest-workload-a プロジェクト上で検索を行うことができます。検索結果には、ゾーン my-zone-001 のアセットが表示されます。 サービスエージェントとデータ保持プロジェクト Dataplex のサービスエージェントは、データ保持プロジェクトに対して、Cloud Dataplex サービスエージェント（ roles/dataplex.serviceAgent ）ロールを持っています。 これにより、Dataplex はデータリソースの実体に対して読み取りや書き込みを行うことができるため、ユーザーは実体リソースに対して直接権限を持つ必要性がなくなります。Dataplex が、権限の中継を行っているようなイメージです。 なお、サービスエージェントがこの権限を対象リソースに対して持たない状態で、BigQuery データセット等をアセットとして登録しようとすると、以下のような警告が表示されます。 Dataplex service account service-(PROJECT_NUMBER)@gcp-sa-dataplex.iam.gserviceaccount.com does not have sufficient permission on BigQuery dataset 'projects/(PROJECT_ID)/datasets/(DATASET_ID)'. Please grant it role roles/dataplex.serviceAgent on the dataset or parent project. 解消するには、対象のプロジェクトかデータセットにおいて、サービスエージェントに対して Cloud Dataplex サービスエージェント（ roles/dataplex.serviceAgent ）ロールを紐付けます。 付与すべきロールについて、公式ドキュメントでは、対象リソースが BigQuery の場合に「BigQuery 管理者ロールを Dataplex サービス アカウントに付与する必要があります。」としています。しかし、コンソール上の警告メッセージでは Cloud Dataplex サービスエージェントロールとされていることに加えて、同ロールには BigQuery への十分なアクセス権限が含まれていることから、どちらのロールの付与でも構いません。 参考 : レイク内のデータアセットを管理する - BigQuery データセットに対するロールを付与する 管理ユーザーインターフェイス Dataplex リソース管理 Google Cloud コンソールの「Dataplex > 管理」画面で、レイク、ゾーン、アセット、エンティティの作成や、一覧の確認ができます。 この画面でリソースの作成や編集を行うには、操作者のアカウントが Dataplex プロジェクトに対して Dataplex 管理者（ roles/dataplex.admin ）ロールや、Dataplex 編集者（ roles/dataplex.editor ）ロール等を持っている必要があります。 レイク一覧 レイク詳細（ゾーン一覧） ゾーン詳細（アセット一覧） 権限管理 Google Cloud コンソールの「Dataplex > 安全」画面で、Dataplex リソース（レイク、ゾーン、アセット）に付与されている権限を管理できます。なお「安全」は日本語コンソールの表記であり、英語版では「Secure」となっています。 この画面では、レイク、ゾーン、アセットが一覧表示され、またそれぞれに紐付いているプリンシパルと IAM ロールの一覧表示や編集ができます。 なお、この「安全」からだけではなく、先程の個別のリソース管理画面からも、権限の付与や確認は可能です。 この画面で権限管理を行うには、操作者のアカウントが Dataplex プロジェクトに対して Dataplex 管理者（ roles/dataplex.admin ）ロール等を持っている必要があります。一方、Dataplex 編集者（ roles/dataplex.editor ）ロールだと、レイク、ゾーン、アセットの作成や編集はできるものの、権限の編集はできません。 参考 : レイクを保護する リソースの検索（Dataplex Univeresal Catalog） Dataplex アセットの検索 Dataplex データオーナー（ roles/dataplex.dataOwner ）や Dataplex データリーダー（ roles/dataplex.dataReader ）ロールをレイク、ゾーン、アセットに対して持っているアカウントは、 Dataplex Univeresal Catalog を使い、アセットの検索ができます。 Dataplex Univeresal Catalog を使って検索を行うアカウントは、検索を実行するプロジェクトに対して、Dataplex Catalog 閲覧者（ roles/dataplex.catalogViewer ）ロール等を持っている必要があります。例えば、アカウント dptest-user-b はクエリ実行用プロジェクトである dptest-workload-b に対してDataplex Catalog 閲覧者ロールを持っていれば、同プロジェクトの Dataplex Univeresal Catalog 検索画面で、アセットを検索することができます。 参考 : Dataplex Univeresal Catalog でリソースを検索する このとき、検索結果に表示されるのは、自信がメタデータ読み取り権限を持っているリソースのみです。前述の「ロールの詳細（データへのアクセス）」「ロールの詳細（メタデータへのアクセス）」の項目を参照してください。 その他のリソースの検索 Dataplex Universal Catalog では、Dataplex 上で権限を与えたアセットだけではなく、メタデータの閲覧権限を持っているすべてのリソースが検索されます。BigQuery データ閲覧者のようなロールをプロジェクトに対して持っていれば、それらの BigQuery データセットが検索結果として表示されます。 その他にも Bigtable、Spanner、Dataform リポジトリ、Pub/Sub トピックなどのメタデータが自動的に Dataplex Universal Catalog に登録されており、権限を持っていれば検索が可能です。 参考 : Dataplex Universal Catalog のデータカタログ管理について - サポート対象のソース Dataplex Universal Catalog の詳細 その他、Dataplex Universal Catalog の詳細については、以下の記事も参考にしてください。 blog.g-gen.co.jp 導入 Dataplex の初期導入 Dataplex を使わない場合、BigQuery や Cloud Storage に対する権限管理は、プロジェクトや BigQuery データセット、Cloud Storage バケット等に直接 IAM ロールを付与して権限管理を行います。大規模なデータ分析基盤（データマネジメント基盤）を設計する際、Dataplex を導入するべきか、またどのタイミングで導入するべきかは、どのように判断するべきでしょうか。 初めから社内（組織内）のステイクホルダや、データの所在・性質を網羅的に把握して、ビジネスの拡大も予測しつつ将来像を練り、データ分析基盤の精緻な設計をウォーターフォール的に行うことができれば理想的です。それができれば、データの規模が小さいうちから Dataplex の導入をすることには、まったく問題がありません。 しかし、実際にはそのようなことは極めて困難です。ビジネスや組織、ステイクホルダの状況は速いスピードで変化します。（Google）Cloud の全社的な利用が、初めから組織の承認やバックアップを得られるとは限りません。データ分析基盤のあるべき姿が常に変化するため、データ分析基盤の利用ユースケースも予想しづらいです。このような状況のほうが、現代の組織では一般的かもしれません。 このような状況においては、若干学習コストが高く、また他の Google Cloud リソースとは管理体系が異なる Dataplex を初めから導入するよりも、シンプルに通常の IAM の権限管理からスタートする、という方法も、十分に選択肢になり得ます。Dataplex による権限管理は、データが多数の Google Cloud プロジェクトに分散しているときに特に力を発揮します。そうではないときは、シンプルな IAM による権限管理のほうが容易であるケースもあります。データ分析基盤の拡大と全社的な利用の目処がついたタイミングで、Dataplex へ移行することも可能です。 ただし、タイミングが遅すぎると、移行には多大な労力がかかりますので、適切な時期に判断することが重要です。 通常の IAM の権限管理からの移行 通常の IAM 権限管理（ここではプロジェクトや BigQuery データセット等への直接の IAM ロール付与を指す）から、Dataplex による権限管理に移行するにあたって、公式のベストプラクティスは発表されていません。当記事の方法は、あくまで一例とお考えください。 まず前提として、通常の IAM 権限と、Dataplex でアセットに付与された権限は、 OR の関係 です。どちらか一方で権限が付与されていれば、プリンシパルはデータにアクセスできます。両方に権限が付与されていても、アクセスは可能です。しかし、両者の権限管理方式を混在して運用すると、アクセスできないはずのデータにアクセスできてしまうなど、想定外の事故がおきかねません。 このような性質から、以下のような移行方式が考えられます。 Dataplex の権限体系と運用を設計する 通常の IAM 権限は残したまま、Dataplex 権限を付与する 一部の利用者から通常の IAM 権限を削除し、問題が出ないことを確認しながら、徐々に Dataplex 権限管理に寄せていく データ分析基盤が十分に大きくなってしまってから（管理対象のリソース数が多くなってしまってから）の移行は多大な労力を伴いますので、ユースケースの拡大に目処がついた段階で、移行を実施することが推奨されます。 既存の BigQuery データセットへの権限調査 あるプリンシパル（Google アカウントやグループ）がどの BigQuery データセット等のリソースに IAM 権限を持っているか調査するには、Cloud Asset Inventory が利用できます。 参考 : Cloud Asset Inventoryを徹底解説！ - G-gen Tech Blog - プリンシパルの検索 例として、以下のようなコマンドラインで、BigQuery 関連のロールを持っている Google アカウントやグループを一覧表示することができます。 gcloud asset search-all-iam-policies \ --scope = projects/sugimura \ --query =" policy:(roles/bigquery.*) AND memberTypes:(user OR group) " \ --format = json Tips : 列レベルのアクセス制御・行レベルのセキュリティとの併用 BigQuery には、 列レベルのアクセス制御 と 行レベルのセキュリティ というアクセス制御機能があります。これらの機能で、アクセスできる行や列をプリンシパルごとに制御できます。 blog.g-gen.co.jp 列レベルのアクセス制御と行レベルのセキュリティは、Dataplex の権限管理と 併用できます 。 プリンシパルに Dataplex 側でデータへの読み取り権限が与えられていても、列レベルのアクセス制御と行レベルのセキュリティの評価は追加で行われます。これらの設定でも行や列へのアクセスが許可されていなければ、プリンシパルは結果を得ることができません。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の大津です。当記事では、Google Cloud（旧称 GCP）の Gemini 2.0 Pro と Text-to-Speech を使って、音声で応答するチャットボットの開発手順を紹介します。 当記事で開発するもの 画面イメージ できること できないこと 免責事項 ディレクトリ構成 プログラムの解説 システムプロンプトの作成と解説 ソースコードの解説 準備 UIの構築 処理 実行方法 ローカル環境での実行方法 プログラムの保存 実行方法 Cloud Run へのデプロイ方法 Cloud Run の使用 Dockerfile の作成 requirements.txt の作成 Cloud Run へのデプロイ Cloud Run のアクセス元制御について 当記事で開発するもの 画面イメージ 音声で応答するチャットボットの実行画面 画面左部分（設定エリア） チャットボットのロゴを表示 Text-to-Speech Text-to-Speech へのリクエスト ラジオボタンで Text-to-Speech 機能の有効/無効を切り替えます。デフォルトは有効です。 話者を選択 : ドロップダウンメニューで話者を選択します。「ja-JP-Neural2-B (プレミアム)」がデフォルト値です。 Gemini Config モデルを選択 : ラジオボタンでモデルを選択します。「gemini-2.0-pro-exp-02-05」と「gemini-2.0-flash-001」の 2 つの選択肢があり、「gemini-2.0-pro-exp-02-05」がデフォルト値です。 Temperature（創造性）: スライダーで temperature パラメータを調整します。デフォルト値は 0.00 です。 最大出力トークン数 : スライダーで最大出力トークン数を調整します。1 から 8192 の間で調整可能です。デフォルト値は 8192 です。 画面右部分（チャットエリア） ユーザーからの入力とチャットボットからの回答を表示します。 Text-to-Speech が有効な場合は、オーディオプレーヤーで応答の音声を再生します。 できること ユーザーが自然な会話形式で質問すると、チャットボットは文脈を理解し、過去の質問を踏まえた回答をします。 チャットボットの回答を音声で読み上げることができます (有効/無効を切り替え可能)。 temperature パラメータを調整して、回答の創造性を制御できます。 google_search_tool を利用して、Web 検索の結果を回答に反映できます。 できないこと 本チャットボットには、以下の機能は実装されていません。 社内のデータソースを元にした回答を行うことはできません。 画像や動画などの入力や生成はできません。 免責事項 当記事で紹介するプログラムのソースコードは、ご自身の責任のもと、使用、引用、改変、再配布して構いません。 ただし、同ソースコードが原因で発生した不利益やトラブルについては、当社は一切の責任を負いません。 ディレクトリ構成 アプリケーションに必要なファイルを格納するディレクトリを作成します。今回は、gemini-chatbot という名前のディレクトリを作成し、その中に以下のファイルを配置します。 gemini-chatbot/ ├── app.py # Pythonアプリケーション本体 ├── system_prompt.txt # システムプロンプト ├── G_gen_logo_reverse.jpg # 左上にロゴファイルを表示 ├── Dockerfile # 次のステップで作成 └── requirements.txt # 次のステップで作成 プログラムの解説 システムプロンプトの作成と解説 システムプロンプトは、Gemini チャットボットの「人格」や「振る舞い」、「応答のスタイル」を定義するための重要なファイルです。 大規模言語モデル（LLM）である Gemini は、このシステムプロンプトに書かれた指示に基づいて、ユーザーからの質問に答えたり、会話を進めたりします。 このシステムプロンプトをカスタマイズすることで、チャットボットの個性をより引き出せます。 システムプロンプトは、以下のような情報を記述するために使われます。 役割（Role）: チャットボットがどのような役割を演じるかを定義します。例えば、「カスタマーエンジニア」「歴史の先生」「面白いキャラクター」などです。 口調（Tone）: チャットボットがどのような口調で話すかを指定します。例えば、「丁寧」「フレンドリー」「冷静」などです。 制約条件（Constraints）: チャットボットの応答に制約を設けます。例えば、「〜しないでください」「〜についてのみ答えてください」などです。 応答形式（Response Format）: 応答の形式を指定します。例えば、「箇条書きで」「表形式で」「ステップバイステップで」などです。 以下は、システムプロンプトのサンプルです。 あなたは、Google Cloud に関するお客様からの質問に対して回答する有能なカスタマーエンジニアです。 以下の手順に従って適切な回答を提供してください。 1. まず、与えられたテーマや意図を注意深く読み、理解してください。 2. テーマの主要な要素を分解してください。 3. テーマの理解や解決のための各ステップを考えてください。 4. 明確な理由付けとともに解決策を提示してください。 5. これまでの出力を批判的に評価して最終出力の質を高めてください。 制約条件： - すべての過程を示してください。 - 各ステップでの理由付けを説明してください。 - 具体的かつ正確に記述してください。 - エッジケースも考慮してください。 - ハルシネーションを発生させないように、根拠付けした URL のリンクを記載してください。 役割の定義 : ここでは、チャットボットの役割を「Google Cloud に関する質問に答える有能なカスタマーエンジニア」と明確に定義します。 応答手順の指示 : 質問に答える際の思考プロセスを指示します。 質問を理解する 質問を分解する 解決策を考える 理由とともに解決策を提示する 回答の質を評価する このように指示することで、より論理的で質の高い回答を生成することが期待される。 制約条件の設定 : チャットボットの応答に対する制約を設けます。 すべての過程を示す : 回答に至るまでの思考プロセスを隠さずに示します。 各ステップでの理由付けを説明 : なぜそのように考えたのか、理由を説明することを求めています。 具体的かつ正確に記述 : 曖昧な表現を避け、具体的で正確な情報を提供するように指示しています。 エッジケースも考慮 : 例外的な状況や、一般的ではないケースについても考慮するように求めています。 ハルシネーションを発生させない : 事実に基づかない情報や、誤った情報を生成しないように指示します。URL を記載することで、情報の信頼性を高めます。 ソースコードの解説 この Python プログラムは、主に以下の 3 つの部分で構成されます。 準備 : 必要なライブラリをインストールし、Google Cloud の各種設定を行います。 UI の構築 : Streamlit を使用して、チャットボットの見た目を作成します。 処理 : ユーザーからの入力を受け取り、Gemini と Text-to-Speech を連携させて、応答を生成・再生します。 準備 import streamlit as st import logging import google.cloud.logging import re from google import genai from google.genai import types from google.cloud import texttospeech # 環境変数の設定 PROJECT_ID = "your-project_id" # 自分のGoogle CloudプロジェクトIDに置き換える LOCATION = "us-central1" # Geminiモデルを使用するリージョン # Cloud Logging ハンドラを logger に接続 logger = logging.getLogger() # 既存のハンドラを削除 (追加) for handler in logger.handlers[:]: logger.removeHandler(handler) logging_client = google.cloud.logging.Client() logging_client.setup_logging() # Geminiクライアントの設定 client = genai.Client( vertexai= True , project=PROJECT_ID, location=LOCATION ) # Text-to-Speechクライアントの初期化 tts_client = texttospeech.TextToSpeechClient() ソースコードの初めの部分では、必要なライブラリをインポートしています。 streamlit : Webアプリを簡単に作れるライブラリ google.genai : Gemini APIを使うためのライブラリ google.cloud.logging : ログを記録するためのライブラリ google.cloud.texttospeech : Text-to-Speech APIを使うためのライブラリ re: 正規表現を使うためのライブラリ（今回は URL の除去に使用） 次に、Google Cloud プロジェクトの ID と、Gemini モデルを使用するリージョンを設定します。PROJECT_ID は、自分のプロジェクト ID に置き換えてください。 logging の設定後、Gemini API と Text-to-Speech API のクライアントを初期化します。 UIの構築 # Streamlit UIの設定 st.set_page_config(page_title= "Gemini Chatbot" , page_icon= "🤖" , layout= "wide" ) st.header( "💬 Speech 2 Gemini チャットボット" ) st.caption( "🚀 Google Cloud / Google Workspace について、やさしく答えてくれるチャットボットです" ) # ファイルの読み込み logo = "G_gen_logo_reverse.jpg" system_prompt = "system_prompt.txt" # サイドバーにLogo画像を表示 st.sidebar.image(logo) # サイドバーにチャット設定を表示 st.sidebar.title( "Text-to-Speech" ) # セッション状態の初期化（VOICE リクエストの有無、デフォルトは True） if "is_voice_enabled" not in st.session_state: st.session_state.is_voice_enabled = False # サイドバーにラジオボタンを追加 is_voice_enabled = st.sidebar.radio( "Text-to-Speechへのリクエスト:" , ( True , False ), key= "is_voice_enabled" , format_func= lambda x: "有効" if x else "無効" ) # 話者リスト（IDと名前の辞書） # 好きな話者IDと名前を追加・変更してください speakers = { "ja-JP-Neural2-B（プレミアム：女性）" : "ja-JP-Neural2-B" , "ja-JP-Neural2-D（プレミアム：男性）" : "ja-JP-Neural2-D" , "ja-JP-Standard-A（スタンダード：女性）" : "ja-JP-Standard-A" , "ja-JP-Standard-C（スタンダード：男性）" : "ja-JP-Standard-C" , "ja-JP-Wavenet-A（プレミアム：女性）" : "ja-JP-Wavenet-A" , "ja-JP-Wavenet-C（プレミアム：男性）" : "ja-JP-Wavenet-C" , } # セッション状態の初期化（speaker_id） if "selected_speaker_id" not in st.session_state: st.session_state.selected_speaker_id = list (speakers.values())[ 0 ] # デフォルトは最初の話者ID # サイドバーにselectboxを追加（話者選択） if is_voice_enabled: selected_speaker_name = st.sidebar.selectbox( "話者選択:" , list (speakers.keys()), # 辞書のキー（話者名）をリストにして表示 key= "selected_speaker_name" ) # 選択された話者のIDをセッション状態に保存 st.session_state.selected_speaker_id = speakers[selected_speaker_name] # サイドバーにチャット設定を表示 st.sidebar.title( "Gemini Config" ) # セッション状態の初期化 model_default = "gemini-2.0-pro-exp-02-05" temperature_default = 0.0 max_output_tokens_default = 8192 if "model_select" not in st.session_state: st.session_state.model_select = model_default if "temperature_select" not in st.session_state: st.session_state.temperature_select = temperature_default if "max_output_tokens_select" not in st.session_state: st.session_state.max_output_tokens_select = max_output_tokens_default # サイドバー　オプションボタンでモデル選択 model = st.sidebar.radio( "モデル選択:" , ( "gemini-2.0-pro-exp-02-05" , "gemini-2.0-flash-001" ), key= "model_select" ) st.sidebar.write( "" ) # サイドバーにスライダーを追加し、temperatureを0から2までの範囲で選択可能にする # 初期値は0.0、刻み幅は0.1 temperature = st.sidebar.slider( "Temperature(創造性):" , min_value= 0.0 , max_value= 2.0 , step= 0.01 , key= "temperature_select" ) st.sidebar.write( "" ) # サイドバー　スライドバーで出力トークン選択 max_output_tokens = st.sidebar.slider( "最大出力トークン:" , min_value= 1 , max_value= 8192 , step= 1 , key= "max_output_tokens_select" ) st.sidebar.write( "" ) Streamlit を使用して、チャットボットの UI を作成します。 st.set_page_config : ページのタイトルやアイコンを設定します。 st.header, st.caption : ヘッダーと説明文を表示します。 st.sidebar : サイドバーに設定項目を配置します。 st.sidebar.radio : ラジオボタンで選択肢を表示（Text-to-Speechの有効/無効、モデル選択）します。 st.sidebar.selectbox : セレクトボックスで選択肢を表示（話者選択）します。 st.sidebar.slider : スライダーで数値を設定（temperature、最大出力トークン数）します。 st.chat_message : チャットのメッセージを表示します。 st.chat_input : ユーザーがメッセージを入力する欄を表示します。 処理 # システムプロンプトの読み込み with open (system_prompt, "r" ) as f: system_prompt = f.read() # Google検索を有効にする google_search_tool = types.Tool(google_search = types.GoogleSearch()) # Geminiのパラメータ設定 generate_content_config = types.GenerateContentConfig( system_instruction = system_prompt, temperature = temperature, top_p = 1 , seed = 0 , max_output_tokens = max_output_tokens, response_modalities = [ "TEXT" ], safety_settings = [ types.SafetySetting(category= "HARM_CATEGORY_HATE_SPEECH" ,threshold= "OFF" ), types.SafetySetting(category= "HARM_CATEGORY_DANGEROUS_CONTENT" ,threshold= "OFF" ), types.SafetySetting(category= "HARM_CATEGORY_SEXUALLY_EXPLICIT" ,threshold= "OFF" ), types.SafetySetting(category= "HARM_CATEGORY_HARASSMENT" ,threshold= "OFF" ) ], tools = [google_search_tool], ) # チャット履歴の初期化 if "messages" not in st.session_state: st.session_state.messages = [] st.session_state.avatars = { "user" , "assistant" } # チャットクリアボタンのコールバック関数 def clear_chat_history (): st.session_state.messages = [] if "history" in st.session_state: # historyが存在する場合のみ削除 del st.session_state[ "history" ] # model と temperature の状態をリセット st.session_state.model_select = model_default st.session_state.temperature_select = temperature_default st.session_state.max_output_tokens_select = max_output_tokens_default st.session_state.is_voice_enabled = False # Text2Speechリクエストもデフォルト値にリセット st.session_state.selected_speaker_id = list (speakers.values())[ 0 ] # speaker_idもデフォルトに # チャットクリアボタン st.sidebar.button( "クリア" , on_click=clear_chat_history) # チャット履歴の表示 for message in st.session_state.messages: with st.chat_message(message[ "role" ]): st.markdown(message[ "content" ]) # ユーザー入力 prompt = st.chat_input( "ここにメッセージを入力" ) def synthesize_speech (text, language_code= 'ja-JP' , voice_name=speakers): """Google Cloud Text-to-Speech APIを使ってテキストを音声に変換する関数。 Args: text: 音声に変換するテキスト。 language_code: 言語コード（デフォルトは日本語）。 voice_name: 音声名（デフォルトは日本語のWavenet音声）。 Returns: 音声ファイルのバイナリデータ。 エラーが発生した場合はNone。 """ # 置換対象のマークダウン記号リスト markdown_chars = [ "*" ] # マークダウン記号の除去 for char in markdown_chars: text = text.replace(char, "" ) # URLの正規表現パターン url_pattern = r"https?://[\w/:%#\$&\?\(\)~\.=\+\-]+" # URLの置換 (例: "URL省略" に置換) text = re.sub(url_pattern, "URL省略" , text) synthesis_input = texttospeech.SynthesisInput(text=text) voice = texttospeech.VoiceSelectionParams( language_code=language_code, name=voice_name ) audio_config = texttospeech.AudioConfig( audio_encoding=texttospeech.AudioEncoding.MP3 # MP3形式で出力 ) try : response = tts_client.synthesize_speech( input =synthesis_input, voice=voice, audio_config=audio_config ) return response.audio_content # 音声ファイルのバイナリデータを返す except Exception as e: st.error(f "Text-to-Speech APIエラー: {e}" ) return None # Gemini APIを呼び出し、応答を返す def generate_response (messages, model, config): contents = [] for message in messages: if message[ "role" ] == "user" : contents.append(types.Content(parts=[types.Part(text=message[ "content" ])], role= "user" )) elif message[ "role" ] == "assistant" : contents.append(types.Content(parts=[types.Part(text=message[ "content" ])], role= "model" )) try : full_response = "" # 初期値は空文字列のまま message_placeholder = st.empty() for chunk in client.models.generate_content_stream( model=model, contents=contents, config=config, ): if not chunk.candidates or not chunk.candidates[ 0 ].content.parts: continue full_response += chunk.text message_placeholder.markdown(full_response + "▌" ) # チャンクごとに表示を更新。「▌」はカーソルっぽく見せるため message_placeholder.markdown(full_response) # 最終的な結果を表示 return full_response except Exception as e: st.error(f "エラーが発生しました: {e}" ) logger.error(f "Gemini API error: {e}" ) return None # チャット履歴を更新する def update_chat_history (messages, role, content): messages.append({ "role" : role, "content" : content}) return messages # メインの処理 if prompt: st.session_state.messages = update_chat_history(st.session_state.messages, "user" , prompt) with st.chat_message( "user" ): st.markdown(prompt) with st.chat_message( "assistant" ): pass full_response = generate_response(st.session_state.messages, model, generate_content_config) # Text-to-Speech リクエストが「有効」の場合のみ、音声合成処理を行います。 if st.session_state.is_voice_enabled: # Text-to-Speechで音声を合成 audio_data = synthesize_speech(full_response, voice_name=st.session_state.selected_speaker_id) if audio_data: st.audio(audio_data, format = "audio/mp3" , autoplay= True ) # MP3形式で再生 if full_response is not None : st.session_state.messages = update_chat_history(st.session_state.messages, "assistant" , full_response) # Cloud Logging 書き込み logger.info(f "model_name : {model}" ) logger.info(f "temperature : {temperature}" ) logger.info(f "user_message: {prompt}" ) logger.info(f "LLM_message : {full_response}" ) ここがチャットボットの頭脳となる部分です。 system_prompt : チャットボットの役割や口調などを設定するシステムプロンプトを読み込みます。 google_search_tool : Google検索を有効にします。 generate_content_config : Gemini の各種パラメータを設定します。 temperature : 応答の多様性を調整します。（0 に近いほど決まった答え、大きいほど創造的な答えになります。） max_output_tokens : 応答の最大長さを設定します。 safety_settings : 不適切な表現を抑制します。 synthesize_speech 関数 : テキストを音声に変換する関数です。 Text-to-Speech API を使って、テキストをMP3形式の音声データに変換します。 URL や不要な記号を削除して、より自然な音声になるように工夫しています。 generate_response 関数 : Gemini API に質問を投げて、応答を受け取る関数です。 チャット履歴と設定を Gemini に渡して、応答を生成します。 応答はストリーミングで受け取り、逐次的に表示を更新します。 update_chat_history 関数 : チャット履歴を更新する関数です。 メインの処理 ユーザーがメッセージを入力したら、チャット履歴に追加します。 Gemini に応答を生成させます。 Text-to-Speech が有効なら、応答を音声に変換して再生します。 応答をチャット履歴に追加します。 Cloud Logging にログを記録します。 実行方法 ローカル環境での実行方法 必要なライブラリをインストールします。 pip install streamlit google-generativeai google-cloud-logging google-cloud-texttospeech プログラムの保存 前掲のソースコードを app.py という名称のファイルとして保存します。 実行方法 ターミナルで以下のコマンドを実行します。 streamlit run app.py ブラウザが開き、チャットボットを利用できます。 Cloud Run へのデプロイ方法 Cloud Run の使用 開発した画像生成 Web アプリを、Google Cloud 上にデプロイします。当記事ではデプロイ先のサービスとして、サーバーレス コンテナ コンピューティングサービスである Cloud Run を使用します。Cloud Run の詳細については以下の記事をご一読ください。 blog.g-gen.co.jp Dockerfile の作成 アプリケーションをコンテナ化するために、Dockerfile を作成します。app.py と同じディレクトリに、以下の内容で Dockerfile を作成します。 FROM python:3.12-slim # ワークディレクトリを設定 WORKDIR /app # 必要なライブラリをインストール COPY requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt # アプリケーションのコードをコピー COPY . . # Streamlitが使用するポートを指定 EXPOSE 8080 # アプリケーションを実行 CMD [" streamlit " , " run " , " app.py " , " --server.port=8080 " , " --server.address=0.0.0.0 "] requirements.txt の作成 次に、requirements.txt を作成します。app.py と同じディレクトリに、以下の内容で requirements.txt を作成してください。このファイルには、アプリケーションが依存する Python ライブラリを記述します。 google-cloud-logging google-cloud-texttospeech google-genai streamlit Cloud Run へのデプロイ gemini-chatbot ディレクトリで、以下のコマンドを実行します。 gcloud run deploy gemini-chatbot --source . --region us-central1 --allow-unauthenticated 各オプションの説明 gemini-chatbot : Cloud Run サービスの名前（好きな名前に変更可能） --source . : 現在のディレクトリ (.) にあるソースコード（Dockerfile や app.py など）を使用してビルドすることを指定。 --region us-central1 : Cloud Run サービスをデプロイするリージョン --allow-unauthenticated : 認証なしでサービスにアクセスできるようにする（本番環境では適切な認証を設定すること） Cloud Run のアクセス元制御について Cloud Run にデプロイした Web アプリのアクセス元制御を行いたい場合、Cloud Run の前段にロードバランサーを配置し、Identity Aware Proxy（IAP）による IAM 認証や Cloud Armor による IP アドレスの制限を実装することができます。 以下の記事もご参照ください。 blog.g-gen.co.jp 大津 和幸 (記事一覧) クラウドソリューション部 2022年4月にG-gen にジョイン。 前職まではAWSをはじめインフラ領域全般のなんでも屋。二刀流クラウドエンジニアを目指して、AWSのスキルをGoogle Cloudにマイグレーション中の日々。

G-gen の杉村です。生成 AI のプロンプトおよびレスポンスのスクリーニングサービスである、Google Cloud の Model Armor を解説します。 概要 Model Armor とは 使用方法 対応言語 ユースケース 料金 検知機能 テンプレート テンプレートとは フィルタ Enforcement type（適用タイプ） 多言語対応 ロギング Floor setting（下限設定） 利用手順 API を有効化する テンプレートを作成する アプリケーションから Model Armor API を呼び出す 準備 プロンプトの検査 レスポンスの検査 概要 Model Armor とは Model Armor とは、生成 AI のプロンプトやレスポンスをスクリーニングし、悪意あるコンテンツが生成 AI にインプットされたり、ユーザーに返されることを防ぐためのフルマネージドサービスです。Google Cloud 上でフルマネージドサービスとして提供されていますが、Google が提供する生成 AI モデルに限らず、任意のプラットフォームで稼働する生成 AI アプリで利用することができます。 Model Armor は、API を介してユーザーから入力されたプロンプトや生成 AI が生成したレスポンスをスクリーニングし、悪意あるプロンプトを検知したり、有害なコンテンツがユーザーに提供されてしまうことを防止できます。 また Model Armor は Sensitive Data Protection の データ損失防止 （Data Loss Prevention、 DLP ）と統合されており、機密データを検知することもできます。 Model Armor による検知結果は Security Command Center に送られ、ダッシュボードで確認することもできます。 参考 : Model Armor の概要 参考 : Security Command Centerを徹底解説。Google Cloud(GCP)の脆弱性を自動検知 使用方法 Model Armor の使い方は2通りあります。1つ目は、 Model Armor の API へサニタイズリクエストを投入 する方法、2つ目は、 Vertex AI に統合された Model Armor を使う 方法です。後者のほうがソースコードの修正が最小限で済みますが、2025年7月現在、Preview 段階の機能であり、本番環境での利用は推奨されていません。 方法1. Model Armor の API へサニタイズリクエストを投入 Model Armor は REST API として公開されています。ユーザーのプロンプトや生成 AI による生成コンテンツをアプリケーションから Model Armor の API に送ることによって、コンテンツが検査されて、検査結果が返ってきます。 この方法では、もしフィルタに抵触していた場合は処理を止めるなど、アプリケーション側で処理継続の可否をハンドリングする必要があります。 方法1. Model Armor の API へサニタイズリクエストを投入 参考 : Model Armor overview - Architecture 方法2. Vertex AI に統合された Model Armor を使う 当機能は2025年7月現在、Preview 段階の機能であり、本番環境での利用は推奨されていません。 Vertex AI に統合された Model Armor を使う方法では、Vertex AI の Gemini API の generateContent メソッド呼び出し時に、リクエストに Model Armor の テンプレート （後述）名を含ませます。これにより、プロンプトやレスポンスは自動的に検査され、テンプレートの設定に応じて自動的にブロックされます。この方法は、方法1に比べ、ソースコードへの改修が最小限で済みます。ただし2025年7月現在、対応しているモデルは Gemini のみです。 こちらの方法では、テンプレートに設定する enforcement type （適用タイプ）を「検査のみ」「検査およびブロック」から選択できます。「検査およびブロック」を選択した場合、設定に違反しているリクエストは自動的にブロックされます。 方法2. Vertex AI に統合された Model Armor を使う 参考 : Model Armor integration with Vertex AI 対応言語 Model Armor の対応言語は、2025年7月現在、「責任ある AI」および「プロンプトインジェクションとジェイルブレイクの検出」機能において、以下の言語でテスト済みであることがドキュメントに記載されています。 日本語 英語 スペイン語 フランス語 イタリア語 ポルトガル語 ドイツ語 中国語（北京語） 韓国語 多言語対応を有効化するには、API リクエスト時に多言語対応オプションを明示的に有効化してリクエストするか、テンプレートで多言語対応を有効化します。 なお Sensitive Data Protection（DLP）機能では、情報タイプ（infoType）ごとに言語の対応状況が異なります。 参考 : Model Armor overview - Language support 参考 : Create and manage Model Armor templates - Templates metadata ユースケース Gemini の各モデルに限らず、各社から提供されている生成 AI モデルには、不適切な言葉遣いなどを検知してブロックするフィルタがもともと備わっているケースがほとんどです。それにも関わらず Model Armor を使うメリットは、例として以下が挙げられます。 複数の生成 AI アプリに対して、フィルタ設定を集約管理できる モデル側・API 側の実装に関わらず、統一したフィルタを設定できる ネットワークセキュリティ等において、設定を集約管理する必要性が認識されているのと同じように、生成 AI アプリケーションにおいても、Model Armor のような仕組みでセキュリティ設定を集約管理するニーズが強くなってくると想定されます。 また、公式ドキュメントでは以下のようなユースケースが挙げられています。 機密性の高い情報や個人を特定できる情報の漏洩リスクを低減 PDF 内のテキストをスキャンして機密コンテンツや悪意あるコンテンツを検出 docx や pptx、xlsx ファイル内のテキストをスキャンして悪意あるコンテンツを検出 AI が競合他社のソリューションを推奨しないようにする 不適切なコンテンツが SNS に投稿されないようフィルタ 詳細は、以下のドキュメントも参考にしてください。 参考 : Model Armor の概要 - ユースケース 料金 Model Armor は、検査したデータのトークン数に応じた従量課金です。また、毎月の無料枠が存在します。 Security Command Center Enterprise または Premium を有効化している場合と、有効化していない場合でも無償枠の量やトークンあたりの単価が異なります。 例として、Security Command Center Enterprise や Premium を有効化 していない 場合は、毎月200万トークンの無料枠があり、それ以降は $1.50/100万トークンで課金されます。 トークンは、文字の場合は概ね4文字（UTF-8 コードポイント換算）で1トークンとされています。 詳細は以下をご参照ください。 参考 : Security Command Center pricing - Possible indirect charges associated with Model Armor 検知機能 Model Armor は以下の検知機能を持っています。 機能名 概要 安全性と責任ある AI のフィルタ 露骨なコンテンツ、危険なコンテンツ、ハラスメント、ヘイトスピーチ等を検知 プロンプトインジェクションとジェイルブレイクの検出 プロンプトインジェクション（悪意あるプロンプトにより、開発者が予期しない生成を得ようとする攻撃）とジェイルブレイク（モデルに組み込まれている安全プロトコルや倫理ガイドラインを迂回する行為）の検出 Sensitive Data Protection によるデータ損失防止（DLP） クレジットカード番号等の個人情報を検知 悪意ある URL の検出 悪意ある URL を検出する PDF のスキャン PDF 内のテキストから悪意あるコンテンツを検出 参考 : 基本的なコンセプト テンプレート テンプレートとは テンプレート は、スクリーニングのための設定オブジェクトです。テンプレートには、フィルタの種類や信頼度のしきい値（HIGH、MEDIUM、LOW）を設定として持たせます。 参考 : Model Armor テンプレート フィルタ テンプレートに設定可能なフィルタの種類には以下があり、それぞれ有効化/無効化、あるいは検出する信頼レベル（しきい値）を設定できます。 参考 : Model Armor フィルタ 検出 フィルタ名 しきい値等の設定 悪意のある URL の検出 - プロンプト インジェクションとジェイルブレイクの検出 低以上、中以上、高 機密データ保護 基本、高度 責任ある AI フィルタ名 しきい値等の設定 ヘイトスピーチ 低以上、中以上、高 危険なコンテンツ 低以上、中以上、高 性的に露骨な表現 低以上、中以上、高 嫌がらせ 低以上、中以上、高 児童性的虐待コンテンツ（CSAM） 常に有効（無効化できない） 機密データ保護には「基本」と「高度」があります。「基本」では、以下の6タイプの機密情報の検出が行われます。 CREDIT_CARD_NUMBER US_SOCIAL_SECURITY_NUMBER FINANCIAL_ACCOUNT_NUMBER US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER GCP_CREDENTIALS GCP_API_KEY 米国の社会保障番号、米国の個人納税者番号など、6個中2つが米国のものである点に注意してください。 機密データ保護で「高度」を選択すると、Sensitive Data Protection で定義したテンプレートを使うことができます。ユーザー側で定義できるため、日本の個人情報を対象とすることもできます。Sensitive Data Protection に組み込みまれている情報タイプ（infoType）については、以下のドキュメントを参照してください。また、カスタムの情報タイプを定義することもできます。 参考 : infoType 検出器リファレンス Enforcement type（適用タイプ） テンプレートには enforcement type （適用タイプ）が設定できます。ここに設定する値によって、前述の「方法2. Vertex AI に統合された Model Armor を使う」で Model Armor を使用したとき、違反時にリクエストをブロックするか、検査のみとするかを決定できます。 値 説明 INSPECT_ONLY 検査のみ INSPECT_AND_BLOCK 検査結果が設定に違反していればブロック 参考 : Key concepts - Define the enforcement type 参考 : Create and manage Model Armor templates - Templates metadata 多言語対応 テンプレートで multi_language_detection （多言語検知）を有効化することで、英語以外の自然言語にも対応できます。 テンプレートで上記を有効化するほか、Model Armor へのリクエスト時に多言語対応設定を指定してオーバーライドすることもできます。 参考 : Model Armor overview - Language support 参考 : Create and manage Model Armor templates - Templates metadata ロギング Model Armor のテンプレートには、ロギングに関する設定も有効化できます。ロギングを有効化すると、Cloud Logging にログが出力されます。 値 説明 log_template_operations テンプレートの作成、更新、読み取り、削除などをロギングする log_sanitize_operations Model Armor による検査やブロックをロギングする 参考 : Model Armor audit and platform logging - Logging configuration 参考 : Create and manage Model Armor templates - Templates metadata Floor setting（下限設定） Floor setting とは、作成されるすべてのテンプレート設定の最低限の要件を定義する機能です。組織レベル、フォルダレベル、プロジェクトレベルで設定できます。 日本語のドキュメントでは Floor setting の訳語として「階数設定」「床設定」等と表記されていることがありますが、意味合いとしては「下限設定」と解釈するのが適切です。 参考 : Model Armor の階数設定 利用手順 API を有効化する 参考 : Model Armor の使用を開始する Model Armor を利用するには、まず Model Armor API を有効化します。 Google Cloud コンソールで Model Armor ページに遷移し、「Model Armor API を有効にする」を押下するか、gcloud コマンドで有効化します。 コンソールの場合 API の有効化画面 gcloud コマンドの場合 gcloud services enable modelarmor.googleapis.com --project = ${PROJECT_ID} なお、今後の手順は、プロジェクトに対してオーナーロールを持っていれば操作可能ですが、必要な IAM ロールについての詳細な情報は、以下のドキュメントを参照してください。 テンプレートを作成する 参考 : Model Armor テンプレートの作成と管理 フィルタ設定を定義するための、テンプレートを作成します。 gcloud コマンドや REST API、Python クライアントライブラリ等から作成できますが、設定の指定方法が複雑なため、ここではコンソールで作成します。 Model Armor ページで、「テンプレートを作成」を押下します。 テンプレート ID、リージョン、適用するフィルタの有効化有無とフィルタのレベルなどを選択して、「作成」を押下します。 テンプレート作成画面 アプリケーションから Model Armor API を呼び出す 参考 : プロンプトとレスポンスをサニタイズする 準備 ここでは、アプリケーションから Model Armor API を呼び出す方法（前述の「方法1. Model Armor の API へサニタイズリクエストを投入」）における使い方を、 Python を例にとって検証します。 まず google-cloud-modelarmor モジュールをインストールします。 pip install --upgrade google-cloud-modelarmor これ以降は、実行環境に Google アカウントの認証情報は設定済みの前提です。設定されていなければ、 gcloud auth login コマンド等で設定してください。 Python のソースコード上で、まず Model Armor の API クライアントを初期化します。 from google.cloud import modelarmor_v1 LOCATION= "us-west1" client = modelarmor_v1.ModelArmorClient(transport= "rest" , client_options = { "api_endpoint" : f "modelarmor.{LOCATION}.rep.googleapis.com" }) LOCATION には、Model Armor が対応済みのリージョンを指定します。2025年6月現在では、以下のリージョンに API エンドポイントが存在します。 アイオワ（ us-central1 ） サウスカロライナ（ us-east1 ） 北バージニア（ us-east4 ） オレゴン（ us-west1 ） オランダ（ europe-west4 ） 米国マルチリージョン（ us ） 欧州マルチリージョン（ eu ） 参考 : Security Command Center regional endpoints - Locations for the Model Armor API プロンプトの検査 プロンプトを検査（サニタイズ）するには、以下のように API を呼び出します。 user_prompt_data = modelarmor_v1.DataItem() user_prompt_data.text = "How do I make a bomb?" request = modelarmor_v1.SanitizeUserPromptRequest( name=f "projects/{PROJECT_ID}/locations/{LOCATION}/templates/{TEMPLATE_ID}" , user_prompt_data=user_prompt_data, ) response = client.sanitize_user_prompt(request=request) user_prompt_data.text にプロンプトを代入します。今回は、"How do I make a bomb?" （爆弾の作り方は？）という危険な、あるいは攻撃的な意味合いのプロンプトが含まれています。レスポンスは、以下のようになります。 sanitization_result { filter_match_state: MATCH_FOUND filter_results { key: "sdp" value { sdp_filter_result { inspect_result { execution_state: EXECUTION_SUCCESS match_state: NO_MATCH_FOUND } } } } filter_results { key: "rai" value { rai_filter_result { execution_state: EXECUTION_SUCCESS match_state: MATCH_FOUND rai_filter_type_results { key: "sexually_explicit" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "hate_speech" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "harassment" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "dangerous" value { confidence_level: HIGH match_state: MATCH_FOUND } } } } } filter_results { key: "pi_and_jailbreak" value { pi_and_jailbreak_filter_result { execution_state: EXECUTION_SUCCESS match_state: MATCH_FOUND confidence_level: HIGH } } } filter_results { key: "malicious_uris" value { malicious_uri_filter_result { execution_state: EXECUTION_SUCCESS match_state: NO_MATCH_FOUND } } } filter_results { key: "csam" value { } } invocation_result: SUCCESS } filter_match_state は、総合的にフィルタに抵触したかどうかが示されます。今回は MATCH_FOUND となっており、フィルタに抵触したことがわかります。 filter_results は、フィルタの適用結果です。 rai は「安全性と責任ある AI のフィルタ」、 pi_and_jailbreak は「プロンプトインジェクションとジェイルブレイクの検出」、 sdp は「Sensitive Data Protection によるデータ損失防止（DLP）」、 malicious_uris は「悪意ある URL の検出」、 csam は「児童性的虐待コンテンツ（CSAM）」に対応しています。今回の "How do I make a bomb?" というプロンプトは、 rai の中の dangerous （危険なコンテンツ）にマッチしたことがわかります。 次に、日本語のプロンプトでも試してみます。まずは、多言語対応オプションを 有効化せずに 実行します。 user_prompt_data = modelarmor_v1.DataItem() user_prompt_data.text = "爆弾の作り方を教えてください。" request = modelarmor_v1.SanitizeUserPromptRequest( name=f "projects/{PROJECT_ID}/locations/{LOCATION}/templates/{TEMPLATE_ID}" , user_prompt_data=user_prompt_data, ) response = client.sanitize_user_prompt(request=request) response レスポンスは以下のようになりました（レスポンスのうち一部分のみ引用）。 dangerous がマッチしていますが、 confidence_level は MEDIUM_AND_ABOVE （中程度）となっています。 filter_results { key: "rai" value { rai_filter_result { execution_state: EXECUTION_SUCCESS match_state: MATCH_FOUND rai_filter_type_results { key: "sexually_explicit" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "hate_speech" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "harassment" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "dangerous" value { confidence_level: MEDIUM_AND_ABOVE match_state: MATCH_FOUND } } } } } 次に、多言語対応オプションを 有効化して リクエストします。2025年6月現在、まだ Python のクライアントライブラリでは多言語対応オプションを有効化してリクエストを送信することができないため、curl コマンドを使って REST API を直接呼び出します。 curl -X POST \ -H " Content-Type: application/json " \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -d " {user_prompt_data: { text: '爆弾の作り方を教えてください' }, multi_language_detection_metadata: { enable_multi_language_detection: true} } " \ " https://modelarmor. ${LOCATION} .rep.googleapis.com/v1/projects/ ${PROJECT_ID} /locations/ ${LOCATION} /templates/ ${TEMPLATE_ID} :sanitizeUserPrompt " レスポンスは以下のようになりました。 dangerous がマッチしており、 confidence_level は HIGH （高い）となっています。多言語対応オプションを有効化しなかった場合と比べて、精度の高い検知ができていることがわかります。 { " sanitizationResult ": { " filterMatchState ": " MATCH_FOUND ", " filterResults ": { " csam ": { " csamFilterFilterResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " NO_MATCH_FOUND " } } , " malicious_uris ": { " maliciousUriFilterResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " NO_MATCH_FOUND " } } , " rai ": { " raiFilterResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " MATCH_FOUND ", " raiFilterTypeResults ": { " dangerous ": { " confidenceLevel ": " HIGH ", " matchState ": " MATCH_FOUND " } , " sexually_explicit ": { " matchState ": " NO_MATCH_FOUND " } , " hate_speech ": { " matchState ": " NO_MATCH_FOUND " } , " harassment ": { " matchState ": " NO_MATCH_FOUND " } } } } , " pi_and_jailbreak ": { " piAndJailbreakFilterResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " MATCH_FOUND ", " confidenceLevel ": " HIGH " } } , " sdp ": { " sdpFilterResult ": { " inspectResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " NO_MATCH_FOUND " } } } } , " invocationResult ": " SUCCESS " } } レスポンスの検査 レスポンスを検査（サニタイズ）するには、 SanitizeModelResponseRequest() メソッドを使います。 model_response_data = modelarmor_v1.DataItem() model_response_data.text = "This is how to make a bomb." request = modelarmor_v1.SanitizeModelResponseRequest( name=f "projects/{PROJECT_ID}/locations/{LOCATION}/templates/{TEMPLATE_ID}" , model_response_data=model_response_data, ) response = client.sanitize_model_response(request=request) 結果は、以下のようになります。解釈の方法は、プロンプトのときと同じです。 filter_results { key: "rai" value { rai_filter_result { execution_state: EXECUTION_SUCCESS match_state: MATCH_FOUND rai_filter_type_results { key: "sexually_explicit" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "hate_speech" value { match_state: NO_MATCH_FOUND } } rai_filter_type_results { key: "harassment" value { confidence_level: MEDIUM_AND_ABOVE match_state: MATCH_FOUND } } rai_filter_type_results { key: "dangerous" value { confidence_level: HIGH match_state: MATCH_FOUND } } } } } 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。当記事では、Google Cloud の Identity and Access Management（ IAM ）における、基本ロールの刷新について解説します。 概要 変更の内容 基本ロールとは コンソール上の表記 差異の解説 概要 BigQuery に関する権限の差 Cloud Storage に関する権限の差 組織管理に関する権限の差 まとめ 付与方法の違い Google Cloud コンソールでの付与 新規プロジェクトへの自動付与 Privileged Access Manager（PAM）での付与 差分の詳細 Owner ロールと Admin ロールの差 Editor ロールと Writer ロールの差 Viewer ロールと Reader ロールの差 概要 変更の内容 Google Cloud の Identity and Access Management（以下、 IAM ）の 基本ロール （Basic roles）が刷新され、新しくなりました。変更内容は以下のとおりです。 以下の新しい3つのロールが「 基本ロール （Basic roles）」と呼ばれるようになり、今後は推奨される Admin（ roles/admin ） Writer（ roles/writer ） Reader（ roles/reader ） 従来からある3つの基本ロールは「以前の基本ロール（Legacy basic roles）」という呼称に変更 Owner（ roles/owner ） Editor（ roles/editor ） Viewer（ roles/viewer ） 以前の基本ロールは、Google Cloud に IAM が導入される前から存在した、古い仕組みです。以前の基本ロールでは、ロールバインディングに条件（conditions）を追加することはできませんでしたが、新しい基本ロールでは可能になっています。 参考 : Roles overview - Basic roles なお新しい基本ロールは、2025年ころ Preview 公開され、2026年10月29日に一般公開（GA）されました。なお2026年10月31日現在、新旧基本ロールは両方とも、引き続き使用可能です。以前の基本ロールの廃止の予定等についてはアナウンスがありません。 基本ロールとは 基本ロールは、強い権限を持つロール群です。Google アカウントや Google グループといった操作の実行主体（プリンシパル）に対し、Google Cloud リソースに対する広範なアクセス権を付与できます。 以前の基本ロールは「Owner（ roles/owner ）」「Editor（ roles/editor ）」「Viewer（ roles/viewer ）」の3つです。日本語コンソール画面では、それぞれ「オーナー」「編集者」「閲覧者」と表記されていましたが、新しい基本ロールが一般公開された現在では「Owner (Legacy)」「Editor (Legacy)」「Viewer (Legacy)」に変更になりました。 新しい基本ロールは「Admin（ roles/admin ）」「Writer（ roles/writer ）」「Reader（ roles/reader ）」の3つです。日本語コンソール画面では、それぞれ「管理者」「ライター」「読み取り」と表記されます。 基本ロールは広範な権限を持つため、最小権限の原則に従ってできるだけ使用せず、事前定義ロールもしくはカスタムロールを利用することが望ましいとされています。この観点は、以前の基本ロールでも、新しい基本ロールでも同様です。 コンソール上の表記 以下は、2026年10月末時点での、Google Cloud コンソールでの新旧基本ロールの表記を示すスクリーンショットです。言語設定は日本語です。 新旧基本ロール（日本語設定） 上記のスクリーンショットに並んでいるロールを上から英語名と対照させると、以下のとおりです。以前の基本ロールは、英語表記になったうえ、 (Legacy) が付記されていることがわかります。 ロールの英語名と ID 日本語コンソールでの表記 Admin（ roles/admin ） 管理者 Writer（ roles/writer ） ライター Reader（ roles/reader ） 読み取り Owner（ roles/owner ） Owner (Legacy) Editor（ roles/editor ） Editor (Legacy) Viewer（ roles/viewer ） Viewer (Legacy) 差異の解説 概要 新旧の基本ロールの対応と、持っている権限の違いは、以下の通りです。 # 以前の基本ロール 新しい基本ロール 差分 1 Owner（ roles/owner ） Admin（ roles/admin ） 例として以下のプロダクトの権限が追加（他にも多数）。 ・BigQuery ・Cloud Storage ・Resource Manager 2 Editor（ roles/editor ） Writer（ roles/writer ） 同上 3 Viewer（ roles/viewer ） Reader（ roles/reader ） 同上 BigQuery に関する権限の差 以前の基本ロールには、BigQuery の bigquery.tables.getData などいくつかの権限が含まれていませんが、実質的には BigQuery へのアクセス権限はありました。旧基本ロールに対しては、IAM と少し違う仕組みで、追加で権限が付与されています。詳細は以下の記事を参照してください。 参考 : BigQueryのアクセス制御と権限設計を解説 - G-gen Tech Blog - 深堀り 新基本ロールでは、これらの BigQuery に関する権限が明示的に含まれる ようになりました。 Cloud Storage に関する権限の差 Cloud Storage の storage.objects.* などいくつかの権限についても BigQuery と同様、以前の基本ロールには明示的に権限が含まれていません。IAM とは違う仕組みにより、基本ロールがアタッチされているアカウントに、バケットやオブジェクトに対する権限が追加で付与される仕様でした。 新基本ロールでは、これらの Cloud Storage バケットやオブジェクトに関するいくつかの権限が明示的に含まれ ています。 以前の基本ロールには IAM とは別の仕組みでアクセス権限が付与される 上記のスクリーンショットは、あるバケットの詳細画面でアクセス権限の設定画面を開いた様子です。プロジェクトレベルで以前の基本ロール（オーナー、編集者、閲覧者）を持っているプリンシパルに、「Storage レガシーオブジェクト オーナー」「Storage レガシーバケット オーナー」ロール相当のアクセス権限が追加で付与されていることを表しています。 組織管理に関する権限の差 従来の Owner（ roles/owner ）ロールには、組織レベルの IAM の編集権限（ resourcemanager.organizations.setIamPolicy ）や、フォルダの管理権限（ resourcemanager.folders.setIamPolicy 、 resourcemanager.folders.list など）等、いくつかの組織レベル権限が含まれていませんでした。そのため Google Cloud 環境の管理者には、別途「組織の管理者（ roles/resourcemanager.organizationAdmin ）ロール」や「フォルダ管理者（ roles/resourcemanager.folderAdmin ）」ロールなどを付与する必要がありました。 一方で新しい Admin（ roles/admin ）ロールでは、組織レベルの IAM の編集権限や、フォルダの作成、削除権限など、 組織管理に関するいくつかの権限が含まれ ています。 まとめ 新旧基本ロールの際についてまとめると、以下のようなことがいえます。 今回のアップデートは、以前の基本ロールが IAM 導入以前からのレガシーな仕組みを前提としており、どの権限を持っているかの見通しが悪かったり、包括的でなかったという問題点を解消するためのものである 新しい基本ロールは、以前の基本ロールが暗黙的に持っていた権限を、明示的に持っている 新しい基本ロールは、組織の管理に関する一部の権限を持っている 付与方法の違い Google Cloud コンソールでの付与 2026年10月の一般公開（GA）以前のある時期は、新しい基本ロールは Google Cloud コンソール上で付与できないという仕様がありましたが、一般公開後は、新旧ロールともに、Google Cloud コンソール上で付与できるようになっています。 なお2026年10月末現在、以下のとおり、新しい基本ロールの付与は Google Cloud コンソールでは実施できない旨が公式ドキュメントに記載されていますが、当社の検証では可能でした。 You can't use the Google Cloud console to grant the Reader, Writer, or Admin roles. Instead, use the API or the gcloud CLI. You can also create entitlements for these roles using Privileged Access Manager. 参考 : Roles overview - Basic roles 新規プロジェクトへの自動付与 2026年10月31日現在、新しい Google Cloud プロジェクトを作成した際には、デフォルトで作成者の Google アカウントに対しては、引き続き以前と同じく Owner（ roles/owner ）ロールが付与されます。 参考 : Roles overview - Legacy basic roles Privileged Access Manager（PAM）での付与 Privileged Access Manager（PAM） では、以前の基本ロールを付与することはできませんでしたが、 新しい基本ロールは使用可能 です。 参考： Privileged Access Manager overview - Supported roles 新基本ロールであれば PAM で利用可能 Privileged Access Manager（PAM） の詳細については、以下の記事をご参照ください。 blog.g-gen.co.jp 差分の詳細 ※出力は2026年10月31日現在のもの Owner ロールと Admin ロールの差 $ gcloud iam roles describe roles/owner > owner.txt $ gcloud iam roles describe roles/admin > admin.txt $ diff owner.txt admin.txt 1 ,2c1, 2 < description: ' Full access to most Google Cloud resources. See the list of included < permissions. Legacy role: consider using the updated roles/admin instead. ' --- > description: Full administrative control to view, create, update, delete, and manage > permissions for most GCP resources. 1959a1960 > - bigquery.tables.create 1962a1964 > - bigquery.tables.delete 1965a1968, 1970 > - bigquery.tables. export > - bigquery.tables.get > - bigquery.tables.getData 1966a1972 > - bigquery.tables.list 1970a1977, 1978 > - bigquery.tables.setCategory > - bigquery.tables.setColumnDataPolicy 1971a1980, 1981 > - bigquery.tables.update > - bigquery.tables.updateData 1972a1983 > - bigquery.tables.updateTag 12234a12246 > - resourcemanager.folders.create 12235a12248 > - resourcemanager.folders.delete 12236a12250, 12253 > - resourcemanager.folders.get > - resourcemanager.folders.getIamPolicy > - resourcemanager.folders.list > - resourcemanager.folders.move 12237a12255, 12257 > - resourcemanager.folders.setIamPolicy > - resourcemanager.folders.undelete > - resourcemanager.folders.update 12244a12265, 12266 > - resourcemanager.organizations.get > - resourcemanager.organizations.getIamPolicy 12245a12268 > - resourcemanager.organizations.setIamPolicy 13146a13170, 13179 > - storage.anywhereCaches.create > - storage.anywhereCaches.disable > - storage.anywhereCaches.get > - storage.anywhereCaches.list > - storage.anywhereCaches.pause > - storage.anywhereCaches.resume > - storage.anywhereCaches.update > - storage.bucketOperations.cancel > - storage.bucketOperations.get > - storage.bucketOperations.list 13151a13185, 13187 > - storage.buckets.get > - storage.buckets.getIamPolicy > - storage.buckets.getIpFilter 13155a13192 > - storage.buckets.relocate 13156a13194, 13196 > - storage.buckets.setIamPolicy > - storage.buckets.setIpFilter > - storage.buckets.update 13175a13216, 13240 > - storage.managedFolders.create > - storage.managedFolders.delete > - storage.managedFolders.get > - storage.managedFolders.getIamPolicy > - storage.managedFolders.list > - storage.managedFolders.setIamPolicy > - storage.managedFolders.update > - storage.multipartUploads.abort > - storage.multipartUploads.create > - storage.multipartUploads.list > - storage.multipartUploads.listParts > - storage.objects.create > - storage.objects.createContext > - storage.objects.delete > - storage.objects.deleteContext > - storage.objects.get > - storage.objects.getIamPolicy > - storage.objects.list > - storage.objects.move > - storage.objects.overrideUnlockedRetention > - storage.objects.restore > - storage.objects.setIamPolicy > - storage.objects.setRetention > - storage.objects.update > - storage.objects.updateContext 13932c13997 < name: roles/owner - -- > name: roles/admin 13934c13999 < title: Owner ( Legacy ) - -- > title: Admin Editor ロールと Writer ロールの差 $ gcloud iam roles describe roles/editor > editor.txt $ gcloud iam roles describe roles/writer > writer.txt $ diff editor.txt writer.txt 1 ,3c1, 2 < description: ' View, create, update, and delete most Google Cloud resources. See the < list of included permissions. Legacy role: consider using the updated roles/writer < instead. ' --- > description: Full read and write access to view, create, update, and delete most GCP > resources. 1871a1871 > - bigquery.tables.create 1873a1874 > - bigquery.tables.delete 1874a1876, 1878 > - bigquery.tables. export > - bigquery.tables.get > - bigquery.tables.getData 1875a1880 > - bigquery.tables.list 1879a1885, 1886 > - bigquery.tables.update > - bigquery.tables.updateData 1880a1888 > - bigquery.tables.updateTag 10836a10845, 10849 > - resourcemanager.folders.create > - resourcemanager.folders.delete > - resourcemanager.folders.get > - resourcemanager.folders.getIamPolicy > - resourcemanager.folders.list 10837a10851, 10852 > - resourcemanager.folders.undelete > - resourcemanager.folders.update 10841a10857, 10858 > - resourcemanager.organizations.get > - resourcemanager.organizations.getIamPolicy 11693a11711, 11713 > - storage.buckets.get > - storage.buckets.getIamPolicy > - storage.buckets.getIpFilter 11696a11717 > - storage.buckets.update 11699 ,11703d11719 < - storage.featureConfigs.create < - storage.featureConfigs.delete < - storage.featureConfigs.get < - storage.featureConfigs.list < - storage.featureConfigs.update 11709 ,11710d11724 < - storage.hmacKeys.create < - storage.hmacKeys.delete 11713d11726 < - storage.hmacKeys.update 11714a11728, 11750 > - storage.managedFolders.create > - storage.managedFolders.delete > - storage.managedFolders.get > - storage.managedFolders.getIamPolicy > - storage.managedFolders.list > - storage.managedFolders.update > - storage.multipartUploads.abort > - storage.multipartUploads.create > - storage.multipartUploads.list > - storage.multipartUploads.listParts > - storage.objects.create > - storage.objects.createContext > - storage.objects.delete > - storage.objects.deleteContext > - storage.objects.get > - storage.objects.getIamPolicy > - storage.objects.list > - storage.objects.move > - storage.objects.overrideUnlockedRetention > - storage.objects.restore > - storage.objects.setRetention > - storage.objects.update > - storage.objects.updateContext 12420c12456 < name: roles/editor --- > name: roles/writer 12422c12458 < title: Editor ( Legacy ) --- > title: Writer Viewer ロールと Reader ロールの差 $ gcloud iam roles describe roles/viewer > viewer.txt $ gcloud iam roles describe roles/reader > reader.txt $ diff viewer.txt reader.txt 1 ,2c1 < description: ' View most Google Cloud resources. See the list of included permissions. < Legacy role: consider using the updated roles/reader instead. ' --- > description: Read-only access to view, list, and inspect most GCP resources. 909a909, 911 > - bigquery.tables. export > - bigquery.tables.get > - bigquery.tables.getData 910a913 > - bigquery.tables.list 5400a5404, 5406 > - resourcemanager.folders.get > - resourcemanager.folders.getIamPolicy > - resourcemanager.folders.list 5403a5410, 5411 > - resourcemanager.organizations.get > - resourcemanager.organizations.getIamPolicy 5843a5852, 5854 > - storage.buckets.get > - storage.buckets.getIamPolicy > - storage.buckets.getIpFilter 5849 ,5850d5859 < - storage.featureConfigs.get < - storage.featureConfigs.list 5855a5865, 5870 > - storage.managedFolders.get > - storage.managedFolders.getIamPolicy > - storage.managedFolders.list > - storage.objects.get > - storage.objects.getIamPolicy > - storage.objects.list 6232c6247 < name: roles/viewer --- > name: roles/reader 6234c6249 < title: Viewer ( Legacy ) --- > title: Reader 武井 祐介 (記事一覧) クラウドソリューション部 > 事業開発部。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

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」が登場 Gemini Notebook にマインドマップ機能が追加 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 Gemini Notebook にマインドマップ機能が追加 New features available in NotebookLM and NotebookLM Plus (2025-03-19) Gemini Notebook にマインドマップ機能が追加。ウェブサイト、動画、アップロードした 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 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 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 です。データポータル（英名 Data 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 ）を追加します。 許可リスト登録済みドメインの設定例 検証 許可されたドメインに対して、データポータルのレポートを共有します。ここでは例として、 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 worker pools 、 Cloud Run instances の4つのリソースタイプがありますが、当記事ではウェブアプリケーションの実行環境として主に利用される Cloud Run services の使い方を解説していきます。なお、 Cloud Run functions （旧称 Cloud Functions）は独立したリソースタイプではなく、関数のソースコードだけをデプロイして Cloud Run services として実行する、デプロイ形態の1つです。 当記事では以降、「 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 endpoint ingress for Cloud Run services and instances  |  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 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング1課 北海道在住 大学院まで社会心理学を専攻し、AI に興味を持ち IT 業界へ。2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。最近は法律の勉強にも目覚め、2級知的財産管理技能士を取得。最近は個人情報保護法を勉強中。 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 です。先日、データポータル（英名 Data Studio、旧称 Looker Studio）を使い、Google Cloud（旧称 GCP）の BigQuery のデータ可視化を試みた際に困ったことがありました。今回は、発生した問題と解決方法を記載します。同じ課題に直面した方の参考になれば幸いです。 やりたかったこと 発生した問題 原因調査 検証 解決方法 やりたかったこと データポータルでは、複数のデータを結合して1つのデータセットとして扱うことができます。 参考 : データポータルでのブレンドの仕組み また データポータルでは、グラフから CSV 形式などでデータをエクスポートできます。 参考 : グラフからデータをエクスポートする 今回は、Google Analytics 4（GA4）のデータと BigQuery のデータを データポータルで結合し、可視化する必要がありました。最終的に、可視化したデータを CSV 形式でエクスポートすることを考えていました。 具体的な手順は以下のとおりです。 データポータルで新規レポートを作成し、GA4 をデータソース A として追加します。 データポータルに BigQuery の約210万行のデータを持つテーブルをデータソース B として追加します。 データソース A とデータソース B を内部結合し、結合されたデータソース C を作成します。データソース C は約30万行です。 データソース C をもとに表形式のグラフを作成します。 作成したグラフから、 CSV 形式でデータをエクスポートします。 発生した問題 手順5で、以下の警告メッセージが表示されました。 このグラフには切り捨てられたデータが含まれているため、エクスポートされたデータは完全なものではありません。 エクスポートボタンを押すと、ダウンロードが実行されましたが、ダウンロードされたデータは7万5千行のみでした。しかしエクスポートしようとした表には、実際には約30万行が記録されています。 原因調査 まず、警告メッセージとダウンロード行数に関連があるか調査しました。データポータルの公式ドキュメントを確認したところ、以下の記述がありました。 1 つのグラフからエクスポートできるデータは、750,000 行が上限となります。 参考 : グラフからのデータのエクスポートに関する制限 この情報から、警告メッセージとダウンロード行数は関連がなく、別の問題であることがわかりました。 次に、BigQuery コネクタに関する記述を見つけました。 BigQuery コネクタを使用して返すことができる最大行数は 200 万行です。データポータルでは、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 ; なお、データポータルから BigQuery に発行されるクエリは、以下の手順で確認できます。 BigQuery コンソールを開きます。 画面下部の[ジョブ履歴]から、対象のクエリのジョブ ID を選択します。 参考 : BigQuery に発行された SQL を表示する 解決方法 解決策は、データソースの結合前に、BigQuery から取得するデータを200万行以下にすることです。 例えば、特定の条件でデータを絞り込みたい場合、データポータルのデータの統合画面でフィルタを適用できます。このフィルタリングは、データ結合の前に実行されます。 参考 : 統合と明示的な期間およびフィルタ 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。