TECH PLAY

株式会社G-gen

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

全767件

Compute Engine VMのgce_workload_cert_refreshプロセスで404エラー
Compute Engine (GCE) VM に Ops エージェントのインストールを試みた際、 gce_workload_cert_refresh というプロセスから HTTP 404 エラーがログに出力され Ops エージェントのインストールが失敗する事象について、その原因と対処法を解説します。本記事ではまず Ops エージェントについて簡単に触れ、その後に具体的なエラーと対処法を説明します。 Ops エージェントとは 事象 原因 対処法 Ops エージェントとは Ops エージェント （Ops Agent）は、Compute Engine インスタンスやオンプレミスサーバーからログと指標（メトリクス）を収集し、Google Cloud の Cloud Logging と Cloud Monitoring に送信するための統合エージェントです。主な機能は以下の通りです。 ログ収集 アプリケーションログ、システムログなど、様々なソースからログを収集し、Cloud Logging へ送信します。これにより、ログの一元管理、検索、分析、アラート設定などが可能になります。 指標収集 メモリ使用量、ディスク I/O といったシステム指標や、Apache、MySQL、Nginx などのサードパーティアプリケーションの指標を収集し、Cloud Monitoring へ送信します。これにより、システムのパフォーマンス監視、ダッシュボード作成、アラート設定などができます。 Ops エージェントを利用することで、オブザーバビリティ（可観測性）の向上に繋がり、システム運用における問題の早期発見や原因究明を効率化できます。 参考 : Ops エージェントの概要 事象 Compute Engine VM（Debian 系、2024 年 6 月当時の OS イメージ）に Ops エージェントのインストールを試みた際、以下のようなエラーログが繰り返し出力され、Ops エージェントのインストールが失敗しました。 gce_workload_cert_refresh[PID]: YYYY/MM/DD hh:mm:ss: Error getting config status, workload certificates may not be configured: HTTP 404 このエラーは、 ⁠gce_workload_cert_refresh というプロセスが、ワークロード証明書の設定ステータスを取得しようとして失敗していることを示しています。 原因 このエラーの原因は、Ops エージェントのインストール時に有効化される gce-workload-cert-refresh.timer という systemd ユニットが、VM 上で ワークロード間の認証機能 の設定状況を確認しようとすることにあります。 具体的には、このタイマーは定期的に（デフォルトでは 10分ごと）、インスタンスメタデータサーバーの特定のエンドポイント（ http://metadata.google.internal/computeMetadata/v1/instance/gce-workload-certificates/config-status ）にアクセスします。しかし、 ワークロード間の認証機能 が VM で有効になっていない場合、このメタデータエンドポイントは存在しません。そのため、メタデータサーバーは HTTP ステータスコード 404（Not Found）を返します。これがエラーログとして記録されます。 実際に、影響を受けている VM から以下のコマンドを実行すると、404 エラーが返されることが確認できます。 curl " http://metadata.google.internal/computeMetadata/v1/instance/gce-workload-certificates/config-status " -H " Metadata-Flavor: Google " レスポンス例 <!DOCTYPE html> < html lang = en > < meta charset = utf-8 > < meta name = viewport content = "initial-scale=1, minimum-scale=1, width=device-width" > < title > Error 404 (Not Found)!!1 </ title > < style ></ style > （中略） < a href = //www.google.com/ >< span id = logo aria-label = Google ></ span ></ a > < p >< b > 404. </ b > < ins > That’s an error. </ ins > < p > The requested URL < code > /computeMetadata/v1/instance/gce-workload-certificates/config-status </ code > was not found on this server. < ins > That’s all we know. </ ins > ワークロード間の認証機能 （正式には「Compute Engine 間の認証に mTLS を使用する」などと呼ばれる機能）は、VM インスタンス間で相互 TLS（mTLS）認証を確立するためのものです。 この機能は、記事執筆時点（2025年5月）では pre-GA ステージ（プレビュー）として提供されています。 そのため、明示的にこの機能を有効化していない限り、多くの環境ではこのエラーが発生する可能性があります。 参考 : ワークロード間の認証のトラブルシューティング 参考 : Compute Engine 間の認証に mTLS を使用する 対処法 ワークロード間の認証機能を利用する予定がない場合、エラー出力を停止するために、systemd ユニット gce-workload-cert-refresh.timer を停止し、無効化することが最も簡単な対処法です。具体的には、以下の systemctl コマンドを VM 上で実行します。 sudo systemctl stop gce-workload-cert-refresh.timer sudo systemctl disable gce-workload-cert-refresh.timer この対処により、 gce-workload-cert-refresh プロセスによる定期的なメタデータサーバーへのアクセスがなくなり、結果として HTTP 404 エラーログの出力も停止し、エージェントがインストールできるようになります。 前述の通りワークロード間の認証機能は pre-GA ステージであり、特定のユースケースでのみ利用される機能のため、このタイマーを無効化しても Ops エージェントの基本的な監視機能や他の VM の動作に影響はありません。 将来的にワークロード間の認証機能を利用する必要が生じた場合は、該当ユニットを再有効化できます。 sudo systemctl enable gce-workload-cert-refresh.timer sudo systemctl start gce-workload-cert-refresh.timer G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。
アバター株式会社G-gen
メダリオンアーキテクチャ2.0とGoogle CloudのAIエージェント活用
G-genの杉村です。当記事では、AI エージェント時代に対応する次世代データ基盤アーキテクチャとして「メダリオンアーキテクチャ 2.0」と、その中核をなす「プラチナレイヤー」をGoogle Cloudで実現する方法を解説します。 はじめに 概要 メダリオンアーキテクチャとは AI エージェント時代のメダリオンアーキテクチャ アーキテクチャ メダリオンアーキテクチャ（従来） メダリオンアーキテクチャ 2.0 実装 プラチナレイヤー セマンティックレイヤー ナレッジグラフ マルチモーダルデータ 追加インターフェイス リアルタイムデータ 情報のシェア・販売 ガバナンス補強 メタデータ管理 データリネージ データのプロファイリング 自動データ品質 AI エージェント 4つのデータエージェント Data Engineering Agent Data Science Agent Data Governance Agent Conversational Analytics Agent 独自エージェントの実装 データの民主化へ ユーザーへのデータ解放 スプレッドシートと AI プラチナレイヤーとデータの民主化 はじめに 概要 当記事では、AI エージェント時代のデータ基盤の新たなあり方として、従来のメダリオンアーキテクチャを進化させた「 メダリオンアーキテクチャ 2.0 」というコンセプトについて、筆者の視点から再整理し、その具体的な実装方法と共に論じます。 そして、その中核となる「 プラチナレイヤー 」の概念と、Google Cloud でどのように実現するかを解説します。 メダリオンアーキテクチャ 2.0 は、Google Cloud Japan 公式の Zenn Publication（ブログ）の記事「AIエージェントが真価を発揮するデータ基盤へ -メダリオンアーキテクチャ 2.0 と "プラチナレイヤー" を考える」で提唱されました。当記事では、このアーキテクチャのうちリアルタイムデータやガバナンスなどの責務を分離して再定義したうえで紹介しています。 zenn.dev メダリオンアーキテクチャとは メダリオンアーキテクチャ は、データレイクハウス内のデータを3つの論理的な層（レイヤー）で段階的に処理し、品質と価値を高めていくアプローチです。 メダリオンアーキテクチャを提唱したのは米国の Databricks 社です。同社の製品である Databricks は、クラウド型の統合データプラットフォーム製品であり、データの変換・保存・管理・可視化・分析などを総合的に扱うことができます。2013年に Databricks 社が設立されて以降、データ分析基盤の構築にあたり高い存在感を持っています。 参考 : メダリオンアーキテクチャ (Medallion Architecture) このアーキテクチャでは、基盤に保存されるデータを3つの抽象的なレイヤーに分類します。 1. ブロンズレイヤー 未加工データを保存するレイヤー。ソースシステムのデータをそのまま保管する。後のレイヤーのためにデータを加工しても、ブロンズレイヤーには生のデータを保持しておく。 2. シルバーレイヤー ブロンズレイヤーのデータを変換・抽出してある程度の整備を施したもの。顧客マスタ、店舗マスタ、重複排除済みのトランザクションデータなど。アドホックな分析や機械学習への利用などが可能。 3. ゴールドレイヤー シルバーレイヤーのデータにさらに加工を施したもの。より非正規化され、キュレート（目的に応じて整備）されており、より多くのユーザーから利用される準備ができている。 レイヤーが進むごとにデータの価値が向上する様を、ブロンズ、シルバー、ゴールドといったメダルになぞらえていることから「メダリオン（Medallion）」アーキテクチャと名付けられています。 なおこれらのレイヤーは、書籍等では以下のように呼称されることもあります。呼び名が異なっても、ほとんど同じ概念と捉えることができます。 ブロンズレイヤー -> データレイク層 シルバーレイヤー -> データウェアハウス層 ゴールドレイヤー -> データマート層 Databricks では、Cloud Storage（Google Cloud）や Amazon S3（AWS）などのクラウドストレージサービスと連携しながら、Apache Spark 等を基盤技術として、上記のレイヤーを実現しています。 AI エージェント時代のメダリオンアーキテクチャ 2022年末ころに ChatGPT がブームになってから2025年7月の現在に至るまで、生成 AI は日常業務レベルにまで発展・普及しました。最近では、AI が人間の代わりにタスクを行う AI エージェント の活用が盛んに論じられるようになっています。AI エージェントは早晩、日常業務で人間を助けるようになっていくでしょう。 AI エージェントは人間の指示に基づき、データを読み込んでコンテキストとして利用したり、あるいは SQL や API リクエストを生成してデータを取得し、 自動で分析 したり、 人間にデータを提供 するようになっていきます。AI エージェントはデータ分析基盤に存在する前述の各レイヤーからデータを取得して、利用したり、人間のためにデータを提供することになります。 AI エージェントの発展に伴い、前掲の Google Cloud Japan 公式の Zenn Publication（ブログ）で公開された以下の記事では、AI が自律的にデータを活用しやすくなるよう、第4のレイヤーである プラチナレイヤー を提唱しています。 参考 : AIエージェントが真価を発揮するデータ基盤へ -メダリオンアーキテクチャ 2.0 と "プラチナレイヤー" を考える 今回は、このプラチナレイヤーを深堀りし、前述の記事が提唱する新しいアーキテクチャである「 メダリオンアーキテクチャ 2.0 」を論じます。 アーキテクチャ メダリオンアーキテクチャ（従来） まず、Google Cloud を主な基盤としてメダリオンアーキテクチャを実現した場合の一例を以下の図に示します。 メダリオンアーキテクチャ（従来） 多くの組織では、元データを持つシステムはオンプレミス、Amazon Web Services（AWS）、Google Cloud など、複数のプラットフォームに分散しています。よってブロンズレイヤーは、Amazon S3、Cloud Storage、BigQuery などに分散している可能性があります。これらの分散したデータを1つの抽象レイヤーとして管理するには、サードパーティ製品や、Dataplex Universal Catalog（旧称 Dataplex Data Catalog）でメタデータを管理しつつ、OIDC/SAML を用いた認証情報の連携などが必要になります。 シルバーレイヤーとゴールドレイヤーは、BigQuery で構成します。 各レイヤー間のデータ移送、変換は、Dataform と呼ばれる Google Cloud ネイティブな SQL ベースのワークフローツールや、サードパーティのワークフロー管理ツールなど、様々な候補が挙げられます。 また、Amazon S3 から Cloud Storage や BigQuery へのデータ移送には、BigQuery Data Transfer Service を用いたり、BigQuery Omni（ただし東京・大阪リージョンの Amazon S3・BigQuery には未対応）などを用いることができます。 参考 : BigQuery Data Transfer Service とは 参考 : BigQuery Omni の概要 このようなメダリオンアーキテクチャ型のデータ分析基盤は、2010年代以降、多くの組織で Google Cloud を使って実装されてきました。 メダリオンアーキテクチャ 2.0 前述の記事「AIエージェントが真価を発揮するデータ基盤へ -メダリオンアーキテクチャ 2.0 と "プラチナレイヤー" を考える」では、従来型のメダリオンアーキテクチャにプラチナレイヤーを加え、このレイヤーに以下のような機能を持たせています。 機能名 概要（前述記事からの引用） セマンティックレイヤー 「売上」「利益」「顧客数」といったビジネス指標とその計算方法、データ間の関係性を定義した「意味の辞書」 ナレッジグラフ（データの相関関係） データ同士の「関係性」をグラフ構造で表現したもの ガバナンス AI エージェントの自律的なデータ利用を、安全かつ透明性の高い形で実現するためのガードレール マルチモーダルデータ 契約書（PDF）、議事録（Docs）、画像、音声、動画などの非構造化・半構造化データ リアルタイムデータ 顧客の行動、IoTセンサー、ログデータといったストリーミングデータのリアルタイムな取り込み 上記は、AI エージェントからデータを利用するにあたり有用です。しかしながら当記事では、メダリオンアーキテクチャの各層の命名の意味合いに鑑みて、以下のように整理しなおしました。 セマンティックレイヤー 、 ナレッジグラフ 、 マルチモーダルデータ => プラチナレイヤー リアルタイムデータ => ブロンズレイヤー の 追加インターフェイス ガバナンス => 全レイヤーの ガバナンス補強 セマンティックレイヤー、ナレッジグラフ、マルチモーダルデータについては、ゴールドレイヤーのデータに価値を付加するという意味において、プラチナレイヤーと呼称するにふさわしいと考えます。 リアルタイムデータについては、加工前の生データとして最初にデータ基盤へ流入することが多いため、ブロンズレイヤーの責務としました。 ガバナンスはデータの発生から活用までのライフサイクル全体で一貫して適用されるべき原則であり、特定のレイヤーに限定されるものではないため、横断的な機能として捉え直しました。 当記事では上記の考えに基づき、先行記事で論じられたメダリオンアーキテクチャ 2.0 を捉え直します。 これを構成図に反映すると、以下のようになります。 メダリオンアーキテクチャ 2.0 図に掲載されているサービスを、かならずしもすべて実装する必要はありません。必要に応じて追加の実装を行い、データの入口を追加したり、プラチナレイヤーを実装すればよいことになります。 実装 プラチナレイヤー セマンティックレイヤー セマンティックレイヤーの実装に当たっては、Google Cloud のデータプラットフォームおよびデータ分析・可視化ツールである Looker を使うことができます。 Looker で定義されたディメンションやメジャー（指標）を、AI 等から利用できるようにします。Looker に付帯の Gemini for Looker では、自然言語の指示により、AI がデータを可視化したり、AI にデータを分析させることができます。 Looker の大きな特徴は、 LookML という仕組みにより共通のディメンションやメジャーを定義できる点です。「売上」「粗利」「営業利益」「顧客数」といった指標の意味を LookML で集中管理することで、データの解釈に齟齬がでないように統一できます。 参考 : GoogleのBIツール、LookerとLooker Studioを比較してみた - G-gen Tech Blog Looker のディメンションやメジャー、また Gemini in Looker には、API 経由でアクセスすることができます。これにより、AI エージェントから、セマンティックレイヤーを経由してデータにアクセスさせることが可能になります。 ナレッジグラフ ナレッジグラフは、データの相関関係を管理する仕組みです。Google Cloud サービスを使った、いくつかの実装が考えられます。 BigQuery Graph Analysis BigQuery Graph Analysis は、BigQuery 上のデータに対して GQL（Graph Query Language）と呼ばれるグラフクエリ言語を実行できる機能です。2025年7月現在、まだ利用可能になっておらず、将来リリースされる予定です。 これによりデータ間の関係性を可視化することができ、関係性の情報を保持しておくことで、AI がデータ間の関係性を理解して適切なインサイトを提供するのに役立ちます。 参考 : YouTube - Unleashing graph analytics in BigQuery BigQuery Contribution Analysis BigQuery では、簡単に 貢献度分析 （Contribution Analysis）が可能です。この機能では、BigQuery ML を使って貢献分析を行う機械学習モデルをトレーニングし、ある多次元データにおいて主要な指標が変化した際に、どういったデータがその変化に貢献したのかを分析することができます。 これによりデータ間因果関係という関係性を可視化するのに役立ち、ナレッジグラフの構成に繋がります。 参考 : 貢献度分析の概要 BigQuery Knowledge Engine BigQuery Knowledge Engine は2025年7月現在、未公開ですが、将来のリリースが予告されています。BigQuery knowledge engine は、複数テーブルにまたがるクエリの提案や、自然言語による質問への回答などにより、複数のデータセットやテーブルの間の関係性を可視化し、把握するための機能です。エンティティ間の関係性をグラフで表現し、データ間の繋がりを可視化したり、テーブルをまたいだクエリをサジェストできます。 この機能では、テーブル間の意味的な関係性を可視化し、ナレッジグラフを構成することに繋がります。 参考 : BigQueryの新発表を解説（Google Cloud Next '25速報） - G-gen Tech Blog - BigQuery knowledge engine マルチモーダルデータ BigQuery オブジェクトテーブル BigQuery にはオブジェクトテーブルと呼ばれるタイプのテーブルがあります。BigQuery のテーブルにあたかも動画、画像、音声などの非構造化データを格納したかのように扱い、分析したり、BigQuery ML で機械学習のトレーニングや推論に使うことができます。実際にはテーブルには非構造化オブジェクトのメタデータが格納されており、データの実体は Cloud Storage バケットに格納されます。 参考 : オブジェクト テーブルの概要 BigQuery multimodal tables BigQuery multimodal tables は、前述のオブジェクトテーブルよりもさらに構造化データと非構造化データの統合を推し進めたものです。 ObjectRefs 型の値をテーブルに持つことで、非構造化データを BigQuery の標準テーブルに持たせることができます。こちらも、データの実体は Cloud Storage に格納されます。標準テーブルに非構造化データを統合できるため、構造化データと組み合わせた分析や BigQuery ML からの利用、Python ライブラリである BigQuery DataFrames からの利用など、より分析の利便性が向上します。当機能は、2025年7月現在、Preview 公開です。 参考 : Analyze multimodal data in BigQuery BigQuery Auto Discovery BigQuery Auto Discovery は、Cloud Storage 上の非構造化データを自動で検出して、BigQuery オブジェクトテーブルを作成する機能です。バックエンドでは Dataplex が使われています。 参考 : Cloud Storage データを検出してカタログ化する 追加インターフェイス リアルタイムデータ Pub/Sub の BigQuery サブスクリプション Pub/Sub は、フルマネージドのメッセージキューサービスです。BigQuery サブスクリプション機能を使うと、Pub/Sub に発行（パブリッシュ）されたメッセージを、直接 BigQuery に書き込むことができます。メッセージを受け取って BigQuery に書き込むプログラムは必要ありません。 blog.g-gen.co.jp Pub/Sub の Cloud Storage サブスクリプション Pub/Sub の Cloud Storage サブスクリプション機能を使うと、Pub/Sub に発行（パブリッシュ）されたメッセージを、直接 Cloud Storage に書き込むことができます。こちらも、メッセージを受け取って Cloud Storage に書き込むプログラムを作成する必要はありません。 blog.g-gen.co.jp BigQuery の Continuous Queries（継続的クエリ） BigQuery の Continuous Queries（継続的クエリ）を使うと、BigQuery テーブルに到着したデータ（レコード）に対して決まった処理（SQL）を実行することができます。BigQuery ML を使った推論を行わせることもできます。これにより、スケジュール実行でクエリを実行するよりも少ない考慮事項（どこまで処理したか、バックフィルなど）で継続的処理を実装できます。 blog.g-gen.co.jp 情報のシェア・販売 BigQuery Sharing BigQuery Sharing（旧称 Analytics Hub）は、BigQuery のデータセットを、他の組織に安全に共有したり、販売して収益化するための機能です。従来は Analytics Hub と呼ばれていましたが、2025年4月に改名されました。データクリーンルーム機能により、きめ細かいアクセス制御を設定することができます。また Google Cloud Marketplace を通じて、データを販売して収益化することができます。 参考 : BigQuery Sharing の概要  |  Google Cloud Documentation Stream sharing with Pub/Sub Stream sharing with Pub/Sub は、Pub/Sub トピックを異組織間でシェアするための仕組みです。リアルタイムデータを別の組織に共有したり、逆に共有を受けることができます。基盤として BigQuery Sharing（旧称 Analytics Hub）の仕組みを利用しています。 参考 : Pub/Sub を使用したストリーム共有 ガバナンス補強 メタデータ管理 Dataplex Universal Catalog （旧称 Dataplex Catalog）は、BigQuery や Cloud Storage などの Google Cloud サービス、およびサードパーティのストレージに格納されたメタデータを管理するフルマネージドサービスです。 BigQuery のデータセットやテーブルの説明（Description）、Pub/Sub トピックの情報などは自動的に収集され、Dataplex Universal Catalog の画面から検索・表示可能です。 さらに Dataplex Universal Catalog は、Cloud Storage 内のデータを検出して外部テーブルや BigLake テーブル、オブジェクトテーブルなどとして定義する Data Discovery 機能も備えています。 blog.g-gen.co.jp メタデータの自動生成 を使うと、BigQuery テーブルやそのカラムに対して、AI によりメタデータを自動生成できます。メタデータの整備は人間にとって重要であることに加えて、AI がデータを適切に取得して分析手法を確立するために必須です。 参考 : Generate data insights in BigQuery - Generate table and column descriptions 参考 : BigQueryのメタデータ自動生成を解説 - G-gen Tech Blog BigQuery のメタデータ自動生成 データリネージ Google Cloud プロジェクトで所定の API を有効化するだけで、BigQuery の データリネージ を記録・可視化することができます。BigQuery テーブルに対して実行された COPY、CREATE、INSERT SELECT、MERGE、UPDATE などが自動的に記録され、リネージグラフとして表示可能です。 参考 : データリネージについて データリネージ データのプロファイリング Dataplex Universal Catalog を使って BigQuery のテーブルに対して データプロファイリング を行うと、null 値の割合、近似値の割合、平均値や標準偏差、最小値など、テーブルの統計的な情報を簡単に生成できます。 この情報は AI がデータの特性を把握するために重要になります。 参考 : データ プロファイリングについて データプロファイリング 自動データ品質 Dataplex Universal Catalog の自動データ品質機能は、定義済みのルールに基づきデータのスキャンを自動化し、データの品質要件を満たさない場合にはアラートを記録・発報する機能です。 AI が正しいデータに基づいて分析ができるよう、可能な限り品質担保を自動化することができます。 参考 : 自動データ品質の概要 AI エージェント 4つのデータエージェント メダリオンアーキテクチャ 2.0 は、AI エージェントがデータを活用できるように、従来型のメダリオンアーキテクチャに追加の実装を施したものです。 前述の記事では、データ基盤を利用する AI エージェントとして以下を紹介しています。 Data Engineering Agent Data Science Agent Data Governance Agent Conversational Analytics Agent これらは、2025年4月に米国ラスベガスで行われた Google Cloud Next '25 でもコンセプトが紹介されました。 メダリオンアーキテクチャ 2.0（再掲） Data Engineering Agent Data Engineering Agent は、データエンジニアのタスクを代替したり、支援したりするエージェントです。自然言語の指示に基づいて、データパイプラインを生成したり、開発を支援します。 この実装の1つとして、BigQuery data preparation があります。BigQuery data preparation では、GUI 操作と自然言語での AI への指示により、容易に ELT パイプラインを構築できます。 BigQuery data preparation 参考 : BigQuery データの準備の概要 Data Science Agent Data Science Agent は、データサイエンティストを支援したり、あるいはビジネスユーザーが容易にデータ分析を行えるように支援するエージェントです。 実装の1つとしては、BigQuery データキャンバスがあります。自然言語で AI に指示を出すと、AI が BigQuery データセットの中から必要なテーブルを結合してクエリし、可視化までを行います。 BigQuery データキャンバス 参考 : BigQuery データ キャンバスで分析する blog.g-gen.co.jp Data Governance Agent Data Governance Agent はデータガバナンスを強化するエージェントです。これに関しては Google Cloud ネイティブの機能としてはまだ実装途中です。実装済みのものとして、前述のメタデータ自動生成などが挙げられます。また、BigQuery のデータ分析情報（Data insights）の生成には、Gemini が使われています。 参考 : BigQuery でデータ分析情報を生成する Conversational Analytics Agent Conversational Analytics Agent は、AI との自然言語での対話を通じてデータを分析するエージェントです。 BigQuery の Conversational Analytics （対話型分析）機能を使うと、BigQuery のテーブルに対して、自然言語を使ってクエリや可視化、分析を行うことができます。 blog.g-gen.co.jp また、Looker や Looker Studio Pro に付帯する Gemini in Looker でも、 Conversational Analytics 機能が使用可能です。対話的にエージェントに指示を出して、データの可視化や分析を行わせることができます。 参考 : Gemini in Looker 参考 : 会話分析: 自然言語でデータにクエリを実行する 独自エージェントの実装 前述の4つのデータエージェントは、Google Cloud Next などで繰り返し謳われているものの、まだいずれもコンセプチュアルなものです。また製品化しても、多くの場合でまずは英語版がリリースされ、日本語対応版は数カ月の遅れをもってリリースされます。 早期に日本語に対応した、あるいは自社特有の業務ドメインに対応した AI エージェントを実装したい場合、私たちユーザーは、以下のような Google Cloud サービスを利用することができます。 Vertex AI 経由で提供される Gemini や Claude などのサードパーティモデル マルチエージェント開発のための Python フレームワークである Agent Development Kit （ADK） エージェントをホストするフルマネージドプラットフォームである Vertex AI Agent Engine や Cloud Run 上記のようなサービスを使い、Google Cloud のエコシステムに閉じて AI データエージェント開発を行うことで、エージェントからデータへの認証機構がシンプルになるほか、データ転送料金やネットワークレイテンシを抑えることができます。以下の記事も参考にしてください。 参考 : 全Geminiプロダクトを徹底解説！ - G-gen Tech Blog - Generative AI on Vertex AI 参考 : Agent Development Kitでエージェントを開発してAgent Engineにデプロイしてみた - G-gen Tech Blog 参考 : 入門！Cloud Runのススメ - G-gen Tech Blog データの民主化へ ユーザーへのデータ解放 生成 AI ブーム以前から、 データの民主化 というキーワードは謳われてきました。Google Cloud には、これを強力に後押しする機能が多数備わっています。 BigQuery（ゴールドレイヤー、プラチナレイヤー）に保存されているテーブルデータへの直接クエリはもちろん、今回プラチナレイヤーに分類した Looker の Explorer 機能を用いたオンデマンドなデータ探索は、データの民主化に繋がります。 また、Google Workspace のアプリの1つである Google スプレッドシートには、 コネクテッドシート と呼ばれる機能があります。これは、スプレッドシートと BigQuery を接続し、BigQuery テーブル内のデータをスプレッドシートに吸い上げ、処理可能にする機能です。SQL の知識がないビジネスユーザーでも、使い慣れた Excel ライクなインターフェイスでデータを可視化できます。 blog.g-gen.co.jp このように Google Workspace は、ゴールドレイヤーやプラチナレイヤーのデータへのユーザーインターフェイスになり得ます。 スプレッドシートと AI さらに、スプレッドシートに組み込みの AI 関数 を用いることで、スプレッドシート上のデータに対して 生成 AI モデル Gemini による推論・生成 を実行できます。 このように Google 製品を組み合わせることで、データの民主化や AI の民主化の助けになるといえます。 参考 : Use the AI function in Google Sheets 公式ドキュメント「 Google ドキュメント エディタ ヘルプ 」より引用 プラチナレイヤーとデータの民主化 プラチナレイヤーを整備することで、AI エージェントがデータを解釈しやすくなり、AI エージェントを利用する人間の利便性向上に繋がります。 当記事で解説したメダリオンアーキテクチャ 2.0、特にAIが意味を理解し自律的に活用できるプラチナレイヤーを整備したり、メタデータ整備を始めとするデータガバナンスを強化することで、単なるデータやツールの解放に留まらず、人と AI エージェントの協働による、進化したデータの民主化を実現する鍵となると考えられます。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it
アバター株式会社G-gen
Google CloudのMarketplace Channel Private Offer（MCPO）を解説
G-gen の向井です。当記事では、Google Cloud Marketplace のサードパーティ製ソフトウェアを、G-gen のような販売パートナー経由で購入できる Marketplace Channel Private Offer （MCPO）を解説します。 Google Cloud Marketplace とは プライベートな購入方法 プライベートオファーとは Marketplace Channel Private Offer とは 得られるメリット 請求の一元化 ディスカウント 付加価値 柔軟な契約 プロセス MCPO のプロセス オファーの承諾手順 Google Cloud Marketplace とは Google Cloud Marketplace とは、Google Cloud 上で利用できるサードパーティ製のソフトウェアやサービスを Google Cloud 上で購入できるオンラインストアです。 例えば、CDN / WAF サービスの Fastly、アプリケーション監視ツールの Datadog、運用データベースの Oracle Database など、多くのエンタープライズ向けソフトウェアが Google Cloud Marketplace で提供されています。これらを Marketplace から購入することで、Google Cloud の利用料金と請求を一本化できるなどのメリットがあります。 提供されるソリューションの形態は、Compute Engine VM イメージ、コンテナイメージ、SaaS、API など様々です。 参考 : Google Cloud Marketplace の概要 プライベートな購入方法 プライベートオファーとは Google Cloud Marketplace では、公開されている価格表通りに製品を購入するだけでなく、 プライベートオファー （Private Offer）という仕組みを利用できます。 これは、ソフトウェアを提供しているサービス提供ベンダー（ISV、独立系ソフトウェアベンダーとも呼ばれる）が、特定の顧客に対して、個別の価格や利用条件を提示できる機能です。お客様はベンダーと直接交渉し、合意した価格やカスタムのエンドユーザーライセンス契約（EULA）で製品を購入できます。 オファーは、特定の請求先アカウントに対して発行され、お客様は Google Cloud コンソール上でそのオファーを承諾または拒否します。 参考 : プライベート オファーについて Marketplace Channel Private Offer とは Marketplace Channel Private Offer （MCPO）は、前述のプライベートオファーを、G-gen のような販売パートナー（リセラー）を介して利用する仕組みです。MCPO は、単に Channel Private Offer と呼ばれる場合もあります。 通常のプライベートオファーがサービス提供ベンダーと顧客の2者間の取引であるのに対し、MCPO は、サービス提供ベンダー、販売パートナー、顧客の3者間で取引が行われます。 参考 : Google Cloud Marketplace now lets customers buy ISV solutions from channel partners 参考 : ISV から Cloud Marketplace プロダクトを再販する MCPO の仕組み この仕組みにより、顧客は日頃から取引のある販売パートナーを通じて、Marketplace の製品を有利な条件で購入できます。 Fastly、Datadog など、多くの Marketplace 製品が MCPO に対応しています。対応状況や詳細は、サービス提供ベンダーまたは販売パートナーにご確認ください。 得られるメリット 請求の一元化 Marketplace 製品の利用料を、普段の Google Cloud 利用料と合わせて、G-gen のような単一の販売パートナーから発行される請求書で支払うことができます。 これにより、外貨建てのクレジットカード払いを避けて、日本円での請求書払いができます。 ディスカウント 販売パートナーがサービス提供ベンダーと交渉することで、標準価格よりも有利な価格で購入できる可能性があります。 付加価値 販売パートナーが提供する導入支援、技術サポート、コンサルティングなどの付加価値サービスとセットで製品を契約できます。 柔軟な契約 契約期間や支払いサイトなど、企業の購買プロセスに合わせた柔軟な条件で契約できる場合があります。 プロセス MCPO のプロセス MCPO の基本的な流れは以下の通りです。 顧客は、購入したい Marketplace 製品と必要なライセンス数量などを販売パートナーに伝える 販売パートナーは、顧客の要望に基づき、サービス提供ベンダーと価格や条件を交渉する サービス提供ベンダーは、交渉結果に基づき、販売パートナーに対してプライベートオファーを作成する 販売パートナーは、サービス提供ベンダーから受け取ったオファーに、自社の利益や付加価値サービス分の価格を反映して、顧客向けの新しいプライベートオファーを作成して提示する 顧客は、販売パートナーから提示されたオファーの内容を確認して Google Cloud コンソール上で承諾する 承諾後、Marketplace 製品の利用料金は、Google Cloud の他のサービス利用料と同様に販売パートナーに請求される。販売パートナーは、顧客へ請求書を発行する このプロセスにより、お客様は直接サービス提供ベンダーとやり取りすることなく、販売パートナーを介してすべての手続きを完了できます。MCPO を利用することには、顧客にとってコストメリットや調達プロセスの簡略化などのメリットがあるといえます。 オファーの承諾手順 顧客が MCPO を承諾する際の具体的な手順は、以下の通りです。 販売パートナーが顧客向けにオファーを作成すると、顧客の担当者宛てにメールが発行される 顧客の担当者は、メール内のリンクまたは販売パートナーから共有されたプライベートリンクにアクセスする Google Cloud コンソール上に表示される、オファーの詳細（製品名、プラン、契約期間、価格など）を確認する 内容に問題がなければ、対象の請求先アカウントやプロジェクトを選択して「承諾」ボタンをクリックする 承諾が完了すると、契約が有効になり、Marketplace 製品が利用できるようになる 上記のように、プロセスは非常にシンプルであり数クリックで完了します。 向井 健二 (記事一覧) 事業開発部 カスタマーサクセス課 課長 2022年3月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2024, 2025に選出。熊本在住。
アバター株式会社G-gen
Looker Studioでフィルタを適用したレポートを共有する方法
G-genの min です。Looker Studio には、フィルタや期間などを適用した特定の表示状態を URL として保存・共有する機能があります。本記事では、特定の表示状態を保存・共有するための「 レポートの現在のビューにリンクする 」と「 カスタム ブックマーク リンク 」という2つの機能について、設定方法から利用例まで解説します。 概要 レポートの現在のビューにリンクする（手動生成） 概要 設定方法 カスタム ブックマーク リンク（自動更新） 概要 設定方法 カスタム ブックマーク リンクの応用 URL パラメータの構文 レポート間のドリルスルー 注意事項 概要 用途に応じて以下の2種類の方法があります。 機能 URL生成方法 設定 レポートの現在のビューにリンクする 共有 メニューから都度、手動で生成 事前の設定は必要なし カスタム ブックマーク リンク URL が自動更新され、アドレスバーからコピー可能 レポート編集者が事前に有効化する必要あり 以降で、それぞれの機能について詳しく解説します。 レポートの現在のビューにリンクする（手動生成） 概要 「レポートの現在のビューにリンクする」とは、レポートの編集者や閲覧者が、 その時点での表示状態 をキャプチャし、その状態を反映した URL を手動で生成する機能です。 フィルタや期間設定はもちろん、グラフのドリルダウンやクロスフィルタリングといったインタラクティブな操作結果も URL に含められます。特定の分析結果を一時的な共有リンクとして利用するのに適しています。 この URL を受け取ったユーザーは、共有者が意図した表示状態でレポートを閲覧できます。また、閲覧者自身がこの URL をブックマークすることで、いつでも同じ表示状態でレポートにアクセスできます。 参考 : レポートへのリンクを取得する 設定方法 レポートを表示または編集モードで開きます。 共有したい表示状態になるように、フィルタや期間、グラフのドリルダウンなどを操作します。 画面右上の 共有 ボタンの横にある下矢印をクリックし、 レポートへのリンクを取得 を選択します。 ダイアログで レポートの現在のビューにリンクする のチェックボックスをオンにします。 リンクをコピー をクリックして URL を取得し、共有します。 カスタム ブックマーク リンク（自動更新） 概要 レポートの設定で カスタム ブックマーク リンク を有効にすると、レポートの閲覧者がフィルタなどを操作するたびに、その設定が URL の末尾にパラメータとして 自動的に付与されます 。 この設定を有効にすると、閲覧者がフィルタなどを操作するたびに URL が自動で更新されます。ブラウザのアドレスバーから直接 URL をコピーして共有やブックマークができます。 参考 : レポートの設定を含むカスタム ブックマーク リンクを作成する 設定方法 この設定には、レポートの編集権限が必要です。 レポートを編集モードで開きます。 メニューから ファイル > レポート設定 を選択します。 レポート設定パネルの カスタム ブックマーク リンク で、 閲覧者の設定をレポートのリンクで有効にする のチェックボックスをオンにします。 カスタム ブックマーク リンクの応用 「カスタム ブックマーク リンク」機能は、URL パラメータの仕組みを理解することで、さらに応用ができます。 URL パラメータの構文 カスタム ブックマーク リンク機能を有効にしたレポートでフィルタなどを操作すると、URL は以下のような構造になります。 https://lookerstudio.google.com/reporting/REPORT_ID/page/PAGE_ID?params=クエリパラメータ params= 以降の クエリパラメータ 部分に、フィルタの値などの表示状態が JSON 形式で格納されます。この JSON 部分を理解し、手動またはプログラムで生成することで、高度な利用が検討できます。 レポート間のドリルスルー 例えば、サマリーレポート（例 : エリア別売上サマリー）から、特定の項目で絞り込んだ状態を維持したまま、詳細レポート（例 : 店舗別売上）へ遷移させることができます。 これを実現するには、サマリーレポートの表に、パラメータを付与した詳細レポートへの URL をリンクとして埋め込みます。 具体的には、Looker Studio の計算フィールドで HYPERLINK 関数と CONCAT 関数を使い、選択したディメンション（例ではエリア名）を含むパラメータ付きの URL を動的に生成します。この URL には「エリア」での絞り込み情報を含めることができます。これにより、ユーザーはエリア名をクリックするだけで、そのエリアに絞り込まれた詳細な分析へ深掘りできます。 注意事項 表示モードでのみ有効 「カスタム ブックマーク リンク」機能は、レポートの 表示モード でのみ機能します。編集モードでは URL にパラメータは自動付与されません。 URL の文字数制限 非常に多くのフィルタ値を設定すると URL が長くなり、ブラウザの上限（通常 2,000 文字まで）を超えると、設定が正しく反映されません。レポートはデフォルト設定で表示されます。 アクセス制御には利用不可 URL パラメータは手動で編集が可能なため、特定のデータへのアクセスを制御する目的には利用できません。データアクセス制御には、データソース側での行レベルセキュリティなどの方法を利用する必要があります。以下の記事も参考にしてください。 blog.g-gen.co.jp 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。
アバター株式会社G-gen
Looker Studioの「レポートの公開設定」でバージョンを管理する方法
G-gen の min です。Looker Studio の レポートの公開設定 は、レポートに加えた変更が閲覧者に表示されるタイミングを制御する機能です。この機能を利用して、レポートのバージョンを管理する方法を解説します。 概要 使用方法 公開設定を有効にする 変更内容を公開する 下書き版と公開版を切り替えて表示する バージョンの仕組み バージョン履歴との連携 レポートコピー時の挙動 概要 レポート作成時、デフォルトの状態では、編集者がレポートに加えた変更はほぼリアルタイムで閲覧者にも表示されます。これは個人での利用には便利ですが、複数人での共同編集を行う場合、編集中途の不完全なレポートが閲覧者に表示されてしまう可能性があります。 レポートの公開設定を有効にすると、レポートが「 公開版 」と「 下書き版 」の2つのバージョンに分離されます。閲覧者には常に安定した「 公開版 」が表示され、編集者は「 下書き版 」で作業を続けることができます。そして、下書き版の編集が完了したタイミングで、内容を公開版に反映（公開）できます。 参考 : レポートの公開設定 使用方法 公開設定を有効にする レポートの公開設定を有効化する手順は以下の通りです。 1. Looker Studio でレポートを編集モードで開きます。 2. メニューから [ ファイル ] > [ 公開設定 ] を選択します。 3. 表示されたダイアログで [ レポートの公開 ] のトグルスイッチをオンにして、[ 保存 ] をクリックします。 この設定を有効にすると、その時点のレポートが「 公開版 」として保存され、以降の編集はすべて「 下書き版 」に対して行われます。 変更内容を公開する 下書き版で行った変更を公開版に反映させる手順は以下の通りです。 1. レポートの編集画面の右上にある [ 公開 ] ボタンをクリックします。 2. 確認ダイアログが表示されるので、再度 [ 公開 ] をクリックします。 これにより、下書き版の内容が公開版に上書きされ、閲覧者が見るレポートが更新されます。 下書き版と公開版を切り替えて表示する 編集者は、表示モードで「 下書き版 」と「 公開版 」を自由に切り替えて確認できます。閲覧者は公開版しか見ることはできません。 1. Looker Studio でレポートを編集モードで開きます。 2. レポート名の右横に表示される [ 下書き版 ] > [ 変更履歴を表示 ] をクリックします。 3. 表示したいバージョンを選択します。 これにより、キャンバス画面上で下書き版と公開版の表示を切り替え、公開前に変更点を確認できます。 バージョンの仕組み バージョン履歴との連携 レポートの公開設定は、Looker Studio の標準機能である「 バージョン履歴 」と連携して動作します。バージョン履歴からは、過去に保存された任意のバージョンを「公開」または「この版を復元」できます。この2つの操作は似ていますが、挙動が異なるため注意が必要です。 操作 影響を受けるバージョン 説明 公開 公開版 閲覧者が見る 公開版 が、指定したバージョンに置き換わります。現在の 下書き版は変更されません 。 この版を復元 下書き版 編集中の 下書き版 が、指定したバージョンで上書きされます。現在の 公開版は変更されません 。 例えば、「昨日の状態にレポートを戻したいが、現在編集中の内容は破棄したくない」という場合は「公開」を選択します。一方で、「編集していた内容を破棄して、昨日の状態からやり直したい」という場合は「この版を復元」を選択します。 参考 : 公開設定とバージョン履歴 レポートコピー時の挙動 公開設定がオンになっているレポートをコピーする場合、コピーするユーザーの権限によって挙動が異なります。 コピーするユーザー コピーされる内容 コピー後の公開設定 編集者 下書き版 と 公開版 の両方 オン のまま 閲覧者 公開版 のみ オフ 編集者がレポートをコピーすると、公開設定を含めたすべての状態が複製されます。閲覧者がコピーした場合は、その時点の公開版のみがコピーされ、通常の（公開設定がオフの）レポートとして扱われます。 レポートをコピーするための操作は、下記をご参照ください。 参考 : レポートをコピーするには 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。
アバター株式会社G-gen
Cloud Run worker poolsを徹底解説！
G-gen の佐々木です。当記事では、Google Cloud のサーバーレス コンテナサービスである Cloud Run の機能の1つ、 Cloud Run worker pools について解説します。 Cloud Run worker pools とは 概要 ユースケース Cloud Run services と共通の仕様 リビジョン単位の管理 CPU、メモリ容量の制限、GPU の使用 ボリュームマウント機能 Secret Manager へのアクセス VPC へのプライベート接続 サイドカーコンテナの使用 pull 型の実行モデル スケーリング ワーカープールのデプロイ 料金 Cloud Run worker pools とは 概要 Cloud Run worker pools とは、サーバーレスなクラウドインフラでコンテナを実行することができる Cloud Run の実行モデルのうちの一つです。 Cloud Run には他にも Cloud Run services 、 Cloud Run jobs 、 Cloud Run functions （旧称 Cloud Functions）といった実行モデルがありますが、これらはいずれも HTTP リクエストの受信や API 経由の手動実行、Cron によるスケジュール実行など、外部からの何かしらのトリガーによりコンテナ化したアプリケーションを実行するものです。 Cloud Run worker pools はこれらの実行モデルと異なり、Pub/Sub や Kafka のようなメッセージキューなどに対して、アプリケーションが能動的にメッセージやタスクの取得を行う pull 型 のワークロードを実行するモデルとなっています。 参考 : Deployment options and resource model - Cloud Run worker pools Cloud Run worker pools 後述しますが、Cloud Run worker pools は実行形態が他のモデルとは異なるものの、サービスの仕様は Cloud Run services と共通する箇所が多くなっています。Cloud Run services については以下の記事もご一読ください。 blog.g-gen.co.jp ユースケース Cloud Run worker pools では、以下のような pull 型ワークロードをサーバーレスで実現することができます。 Pub/Sub の pull サブスクリプションからメッセージを取得して処理を実行する Kafka キューからタスクを取得して処理を実行する GitHub Actions の Runner をホスティングしてワークフローを実行する このようなワークロードを Google Cloud で実現する場合、GKE や Compute Engine など、ユーザー側でインフラをある程度管理する必要があるサービスを利用する必要がありました。 Cloud Run worker pools を使用することで、インフラ管理が不要かつ、垂直・水平方向のスケーリングを容易に行えるといったサーバーレスのメリットを享受することができます。 Cloud Run services と共通の仕様 リビジョン単位の管理 新規作成や構成の変更など、Cloud Run worker pools でワーカープールをデプロイするたびに リビジョン （バージョン）が作成されます。 このリビジョンを使用することで、新しいリビジョンへの段階的な移行や、新旧リビジョンのインスタンスを一定の割合で起動するインスタンス分割、リビジョンのロールバックなどを容易に行うことができます。 新旧リビジョンで一定割合数のインスタンスを起動する（インスタンス分割） 参考 : Manage worker pool revisions CPU、メモリ容量の制限、GPU の使用 Cloud Run ではコンテナインスタンスに割り当てる CPU 数、メモリ容量について、上限・下限が存在します。 以下のように、CPU の数に応じて、割り当てることができるメモリ容量の幅が決まります。 CPU（個） メモリ容量 1 512 MiB ~ 4 GiB 2 512 MiB ~ 8 Gib 4 2 GiB ~ 16 GiB 6 4 GiB ~ 24 GiB 8 4 GiB ~ 32 GiB CPU、メモリの設定値は Cloud Run の利用料に直結する要素であり、ワークロードの実行に必要な量を適切に見積もる必要があります。 デフォルトでは、1 vCPU、メモリ容量512 MiB がワーカープールに設定されます。 また、worker pools でも GPU を使用することが可能です。Cloud Run における GPU の利用については以下の記事をご一読ください。 blog.g-gen.co.jp 参考 : Configure memory limits for worker pools 参考 : Configure CPU limits for worker pools 参考 : GPU support for worker pools ボリュームマウント機能 ボリュームマウント機能により、Cloud Storage バケット、NFS ボリューム、インメモリボリュームなどの外部のボリュームを、ワーカープールのコンテナインスタンスにマウントすることができます。 マウントしたボリュームは、コンテナ内のディレクトリとしてローカルファイルシステム同様にアクセスすることができます。 参考 : Configure Cloud Storage volume mounts for worker pools Cloud Run におけるボリュームマウントについては以下の記事もご一読ください。 blog.g-gen.co.jp Secret Manager へのアクセス アプリケーションが使用する API キー、パスワードのような機密情報は、Secret Manager で作成したシークレットに保存することで、Cloud Run から簡単に利用することができます。 Cloud Run が Secret Manager のシークレットにアクセスする方法として、以下の2種類があります。 シークレットの読み込み方法 特徴 Cloud Run の環境変数として読み込む プログラムから環境変数を読み取ることでシークレットの値にアクセスできる。 シークレットの値はコンテナインスタンス起動時に環境変数として読み込まれるため、 シークレットの更新は起動中のコンテナインスタンスに反映されない 点に注意が必要。 シークレットのバージョンを latest ではなく特定のバージョンで固定することで、コンテナインスタンスごとに異なる値が参照されないようにすることが推奨される。 Cloud Run のボリュームとしてマウント シークレットをコンテナインスタンスにボリュームとしてマウントし、ファイルシステム経由で値を読み込む。 シークレットの値は、起動中のインスタンスであっても常に最新のものが読み込まれる。 参考 : Configure secrets for worker pools VPC へのプライベート接続 Cloud SQL データベースへの読み書きを行う場合など、ワーカープールのコンテナインスタンスから VPC 内のリソースにアクセスする必要がある場合は、 Direct VPC Egress や サーバーレス VPC アクセス を使用することで、プライベート IP アドレスによる接続を実現することができます。 参考 : Direct VPC egress with a VPC network Cloud Run における VPC へのプライベート接続については、以下の記事をご一読ください。 blog.g-gen.co.jp サイドカーコンテナの使用 Cloud SQL Auth Proxy や AlloyDB Auth Proxy、ログやメトリクスのエージェントなど、サイドカーコンテナが必要となるユースケースでは、マルチコンテナ機能により複数のコンテナイメージをリビジョンに設定することができます。 参考 : Deploy worker pools to Cloud Run - Deploy multiple containers (sidecars) to a worker pool pull 型の実行モデル Cloud Run worker pools には実行をトリガーするためのエンドポイント、URL がありません。Pub/Sub や Kafka などのメッセージキューに対して処理を行うために、コンテナインスタンスは常に起動されています。 したがって、HTTP リクエストの受信をトリガーとする Cloud Run services と異なり、デプロイするコンテナがポートでリクエストをリッスンする必要がありません。 参考 : Deployment options and resource model - Cloud Run worker pools スケーリング 他の実行モデルとの重要な違いとして、Cloud Run worker pools には 自動スケーリング機能がありません。 基本的にコンテナインスタンスの数は手動で調整する必要があり、 インスタンス数が0のときはワーカープールが無効になります。 また、インスタンス数はリビジョン単位ではなくワーカープール単位で設定されるため、インスタンス数の変更により新たなリビジョンが作成されることはありません。 参考 : Manual scaling for worker pools ワーカープールの自動スケーリングを行いたい場合は、pull 対象（Pub/Sub や Kafka など）やワーカープールをモニタリングし、API 経由でインスタンス数を自動で変更するような仕組みが必要となります。 このような外部指標に基づいた自動スケーリングのためのツールとしては、Google Cloud 公式よりオープンソースツールである Cloud Run External Metrics Autoscaling（CREMA）が提供されています。 参考 : Autoscale worker pools with external metrics ワーカープールのデプロイ ワーカープールはコンテナレジストリにあるコンテナイメージ、もしくはソースコードからそのままデプロイすることができます。 コンテナレジストリは Google Cloud のサービスである Artifact Registory の利用が推奨されます。それ以外には Docker Hub のイメージも利用できるほか、Artifact Registry のリモートリポジトリ機能を用いることで、様々なパブリック/プライベートリポジトリを利用することができます。 参考 : Deploy worker pools to Cloud Run 参考 : Create remote repositories ソースコードからのデプロイでは、Google Cloud が提供している buildpacks を使用して、ワーカープールとしてデプロイされるコンテナイメージが自動で作成されます。 使用言語や依存関係などが自動で検出され、Google 管理の安全なベースイメージを用いてコンテナイメージのビルドが行われます。Dockerfile を使用しないため、ビルドの細かいカスタマイズはできない点に注意が必要です。 参考 : Deploy worker pools from source code 参考 : Google Cloud's buildpacks Cloud Run worker pools のデプロイ方法については、以下の記事もご一読ください。 blog.g-gen.co.jp 料金 Cloud Run worker pools では、コンテナインスタンスが使用する CPU、メモリの実行時間ぶんの料金が発生します。Cloud Run services とは異なり、コンテナインスタンスがアクティブであってもアイドル状態であっても同様の料金が発生します。 また他の実行モデルとは異なり、外部からのリクエストによる実行ではないため、リクエスト単位の料金はありません。 以下は、2025年7月現在の東京リージョン（asia-northeast1）における料金表です。 CPU メモリ 無料枠 毎月最初の 240,000 vCPU 秒 毎月最初の 450,000 GiB 秒 通常料金 $0.000011244 / vCPU 秒 $0.000001235 / GiB 秒 FlexCUD（1年） $0.00000809568 / vCPU 秒 $0.0000008892 / GiB 秒 FlexCUD（3年） $0.00000607176 / vCPU 秒 $0.0000006669 / GiB 秒 vCPU 秒 : vCPU が 1 つのインスタンスを 1 秒間 実行すること GiB 秒 : メモリ容量が 1 GiB のインスタンスを 1 秒間実行すること 例えば、通常料金で 1 vCPU、メモリ1 GiB、コンテナインスタンス1つのワーカープールを実行する場合、1ヶ月（30日=2592000秒）あたりの料金は以下のようになります。 項目 計算式 CPU 料金 $0.000011244 * (2592000秒 - 無料枠240000秒) = $26.45/月 メモリ料金 $0.000001235 * (2592000秒 - 無料枠450000秒) = $2.65/月 参考 : Cloud Run pricing なお、料金表に記載されている FlexCUD については以下のドキュメントを参照してください。 参考 : Compute flexible committed use discounts 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805
アバター株式会社G-gen
Looker StudioとBigQuery連携で予想外のコスト増加の原因となる2つの挙動
G-gen の min です。Looker Studio から BigQuery をデータソースとして利用する際、意図しない挙動により BigQuery の利用料金が高額になるケースがあります。本記事では、特に CURRENT_DATE() のような非決定性関数を使用した場合のキャッシュの扱いや、プルダウンリストのコントロールによるクエリ発行時に注意が必要な挙動がありました。その共有と対策を解説します。 コスト増の原因になる挙動 1. CURRENT_DATE() 使用によるキャッシュ無効化 2. プルダウンリストのコントロールによるクエリ増加 具体的な対策 対策 1-1 : 非決定性関数の除外 対策 1-2 : テーブル関数の使用 対策2 : コントロール用データソースの分離とクロスフィルタリング 対策の検証 検証環境の構築 テーブル定義 サンプルデータ 分析用ビュー（問題のあるケース） 挙動確認 対策 1-1 の適用 対策 1-2 の適用 対策2 の適用 BigQuery の費用と追加のコスト最適化策 コスト増の原因になる挙動 Looker Studio レポートから BigQuery テーブルをデータソースとして使用しているとき、BigQuery の利用料金が想定を超えて高くなる原因として、2つの挙動を例示します。 これらの挙動は、予期せぬスキャン量の増加やコスト発生につながることがあります。 1. CURRENT_DATE() 使用によるキャッシュ無効化 BigQuery に対して実行されるクエリで CURRENT_DATE() のような 非決定性関数 （実行されるたび出力が変わる関数）を使用していると、BigQuery のクエリキャッシュが適用されません。 参考 : クエリのキャッシュの例外 例えば、以下のケースでは、クエリが毎回再実行されます。 CURRENT_DATE() を使用して「今日から過去〇日間」のデータを取得するテーブルを作成 そのテーブルを Looker Studio のデータソースとして使用 こういったケースでは、レポートの再表示やフィルタ操作を行うたびにスキャンが発生し、キャッシュが利用されないため、BigQuery 利用料金の増加につながります。 2. プルダウンリストのコントロールによるクエリ増加 Looker Studio のレポートに配置する プルダウンリストのコントロール は、以下のタイミングで BigQuery にクエリが発行されます。 フィルタの選択肢を表示するためのデータ取得時 ユーザーがフィルタの値を変更したとき 例えば、表グラフが 1 つ、プルダウンリストのコントロールが 4 つある構成のレポートについて考えます。レポートを開いたりフィルタを操作したりするたびに、合計 5 件以上のクエリが一度に実行されます。 このケースでは、グラフやプルダウンリストのコントロールが参照しているデータリソースに対するデータスキャン量とそれに伴うコストが増加します。 具体的な対策 BigQuery のスキャン量とコストを削減するための具体的な対策を以下に説明します。 対策 1-1 : 非決定性関数の除外 最も直接的な対策は、クエリから CURRENT_DATE() のような非決定性関数を削除することです。ただし、この方法ではデータの取得期間が固定されるため、動的な期間指定には別の工夫が必要です。 対策 1-2 : テーブル関数の使用 ビューを使用する場合、BigQuery の テーブル関数 （Table Valued Function、TVF）を検討します。テーブル関数はパラメータを受け取ることができ、ビューのように振る舞います。さらに、動的な条件に基づいてデータをフィルタリングできるため、動的な期間指定が行えます。 Looker Studio のカスタムクエリからこのテーブル関数を呼び出し、その際に @DS_START_DATE と @DS_END_DATE といった Looker Studio の標準パラメータを関数に渡すことで、動的にパーティションテーブルへクエリすることで、 BigQuery のスキャン料金を削減することができます。 詳細は、後述の検証結果を参照してください。 参考 : テーブル関数 参考 : カスタムクエリでパラメータを使用する 対策2 : コントロール用データソースの分離とクロスフィルタリング プルダウンリストのコントロール専用の軽量なデータソースを作成し、Looker Studio の クロスフィルタリング 機能を使用します。ユーザーがプルダウンリストのコントロールで値を選択すると、クロスフィルタリング機能によって、その選択がメインのグラフに適用され、その際に必要なクエリが発行されます。 こちらの対策も、検証結果を後述します。 参考 : グラフのクロスフィルタリング 対策の検証 具体的な挙動と対策の効果を確認するため、検証環境を構築します。以降の SQL サンプルコードでは、プロジェクト ID とデータセット名を your-project.your-dataset と記述します。ご自身の環境の値に置き換えてご使用ください。 検証環境の構築 テーブル定義 まず、以下のスキーマで 3 つのテーブルを作成します。 売上ファクトテーブル ( sales_fact ) sales_date でパーティション分割します。 CREATE OR REPLACE TABLE `your-project.your-dataset.sales_fact` ( sales_date DATE , -- 売上日 store_id INT64, -- 店舗ID product_id INT64, -- 商品ID amount INT64 -- 売上金額 ) PARTITION BY sales_date; 商品マスタ ( product_master ) CREATE OR REPLACE TABLE `your-project.your-dataset.product_master` ( product_id INT64, product_name STRING, category STRING -- 商品カテゴリ ); 店舗マスタ ( store_master ) CREATE OR REPLACE TABLE `your-project.your-dataset.store_master` ( store_id INT64, store_name STRING, -- 店舗名 region STRING -- 地域 ); サンプルデータ 各マスタテーブルに 10 件程度のマスタデータを投入します。 sales_fact テーブルには、過去 3 年分、約 250 万件のトランザクションデータ（約75MB）を投入します。データ投入の具体的な SQL は長くなるため、ここでは割愛します。 分析用ビュー（問題のあるケース） 次に、 CURRENT_DATE() を使用して直近 2 年間のデータを集計するビューを作成します。これが問題を引き起こす可能性のあるビューです。 CREATE OR REPLACE VIEW `your-project.your-dataset.sales_summary_problematic` AS SELECT FORMAT_DATE( ' %Y-%m ' , f.sales_date) AS sales_month, sm.store_name, sm.region, pm.category, COUNT ( DISTINCT f.product_id) AS product_count, SUM (f.amount) AS total_sales FROM `your-project.your-dataset.sales_fact` f JOIN `your-project.your-dataset.product_master` pm ON f.product_id = pm.product_id JOIN `your-project.your-dataset.store_master` sm ON f.store_id = sm.store_id WHERE f.sales_date BETWEEN DATE_SUB( CURRENT_DATE ( ' Asia/Tokyo ' ), INTERVAL 2 YEAR) AND CURRENT_DATE ( ' Asia/Tokyo ' ) GROUP BY sales_month, sm.store_name, sm.region, pm.category; 挙動確認 上記で作成した sales_summary_problematic をデータソースとして Looker Studio レポートを作成し、年月や地域を選択するプルダウンリストのコントロールを配置します。 このレポートを表示すると、1回の表示操作で、BigQuery のジョブ履歴には以下のようなクエリが4件記録されました。 このクエリのスキャン量（課金されるバイト数）は、1件ごとに、約 50 MB でした。 SELECT clmn0_ FROM ( SELECT t0.region AS clmn0_ -- region, sales_month, store_name, category に対して1件ずつ FROM ( SELECT * FROM `your-project.your-dataset.sales_summary_problematic` ) AS t0 ) GROUP BY clmn0_ ORDER BY clmn0_ DESC LIMIT 2000001 ; さらに、1回の表示操作で、BigQuery のジョブ履歴には以下のようなクエリが1件記録されました。 このクエリのスキャン量（課金されるバイト数）は、約 65 MB でした。 SELECT clmn0_, SUM (clmn4_) AS t0_qt_xxxxxxxxid, clmn1_, clmn2_, clmn3_ FROM ( SELECT t0.category AS clmn0_, t0.region AS clmn1_, t0.sales_month AS clmn2_, t0.store_name AS clmn3_, t0.total_sales AS clmn4_ FROM ( SELECT * FROM `your-project.your-dataset.sales_summary_problematic` ) AS t0 ) GROUP BY clmn0_, clmn1_, clmn2_, clmn3_ ORDER BY t0_qt_xxxxxxxxid DESC LIMIT 2000001 ; この5件のクエリは、ブラウザのリロードにより、レポートを再表示するたびに、同じスキャン量で同じ数のクエリが発行されました。 このように、ビュー内で CURRENT_DATE() を使用し、かつそのビューをプルダウンリストのコントロールで参照すると、一定期間内に同一ユーザーによる同一フィルタ条件の操作であっても、キャッシュが利用されないクエリが発行され、スキャン量が増加します。 対策 1-1 の適用 ビュー定義から CURRENT_DATE() のような非決定性関数を削除してみます。 CREATE OR REPLACE VIEW `your-project.your-dataset.sales_summary_cached` AS SELECT FORMAT_DATE( ' %Y-%m ' , f.sales_date) AS sales_month, sm.store_name, sm.region, pm.category, COUNT ( DISTINCT f.product_id) AS product_count, SUM (f.amount) AS total_sales FROM `your-project.your-dataset.sales_fact` f JOIN `your-project.your-dataset.product_master` pm ON f.product_id = pm.product_id JOIN `your-project.your-dataset.store_master` sm ON f.store_id = sm.store_id -- WHERE -- f.sales_date BETWEEN DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 2 YEAR) AND CURRENT_DATE('Asia/Tokyo') GROUP BY sales_month, sm.store_name, sm.region, pm.category; このビュー ( sales_summary_cached ) を使用すると、同じレポート表示条件（ブラウザのリロード）でのクエリ結果はキャッシュされました。 ただし、ビュー側では全期間のデータを集計しているため、Looker Studio 側でフィルタを適用するまでのクエリは全期間のデータに対して行われ、表テーブルの初回スキャン量は約 65 MB でした。 対策 1-2 の適用 BigQuery のテーブル関数を使用してみます。 CREATE OR REPLACE TABLE FUNCTION `your-project.your-dataset.sales_summary_tf`( target_date_from DATE , target_date_to DATE ) AS ( SELECT FORMAT_DATE( ' %Y-%m ' , f.sales_date) AS sales_month, sm.store_name, sm.region, pm.category, COUNT ( DISTINCT f.product_id) AS product_count, SUM (f.amount) AS total_sales FROM `your-project.your-dataset.sales_fact` f JOIN `your-project.your-dataset.product_master` pm ON f.product_id = pm.product_id JOIN `your-project.your-dataset.store_master` sm ON f.store_id = sm.store_id WHERE -- パラメータで期間を指定することでパーティションのプルーニングが適用されます f.sales_date BETWEEN target_date_from AND target_date_to GROUP BY sales_month, sm.store_name, sm.region, pm.category ); Looker Studio でこのテーブル関数をデータソースとして使用するには、データソースの接続設定で「カスタムクエリ」を選択し、以下のように記述します。 SELECT * FROM `your-project.your-dataset.sales_summary_tf`(PARSE_DATE( ' %Y%m%d ' , @DS_START_DATE), PARSE_DATE( ' %Y%m%d ' , @DS_END_DATE)) Looker Studio の標準の期間パラメータである @DS_START_DATE と @DS_END_DATE をテーブル関数の引数として渡します。 これにより、Looker Studio の期間コントロールで指定された期間がテーブル関数に渡され、 sales_fact テーブルの sales_date パーティションを効果的に利用できます（パーティションのプルーニングが適用されます）。 参考 : 日付パラメータを使用して、基になるクエリに期間を渡す Looker Studio の「年月」のプルダウンリストのコントロールを「期間設定」のコントロールに変えます。 このレポートを表示すると、1回の表示操作で、BigQuery のジョブ履歴には以下のようなクエリが3件記録されました。（「期間設定」のコントロールに対してのクエリは発行されていませんでした。） SELECT clmn0_ FROM ( SELECT t0.region AS clmn0_ FROM ( SELECT * FROM `your-project.your-dataset.sales_summary_tf`(PARSE_DATE( ' %Y%m%d ' , @DS_START_DATE), PARSE_DATE( ' %Y%m%d ' , @DS_END_DATE)) ) AS t0 ) GROUP BY clmn0_ ORDER BY clmn0_ DESC LIMIT 2000001 ; さらに、1回の表示操作で、BigQuery のジョブ履歴には以下のようなクエリが1件記録されました。 SELECT clmn0_, SUM (clmn4_) AS t0_qt_xxxxxxxxid, clmn1_, clmn2_, clmn3_ FROM ( SELECT t0.category AS clmn0_, t0.region AS clmn1_, t0.sales_month AS clmn2_, t0.store_name AS clmn3_, t0.total_sales AS clmn4_ FROM ( SELECT * FROM `your-project.your-dataset.sales_summary_tf`(PARSE_DATE( ' %Y%m%d ' , @DS_START_DATE), PARSE_DATE( ' %Y%m%d ' , @DS_END_DATE)) ) AS t0 ) GROUP BY clmn0_, clmn1_, clmn2_, clmn3_ ORDER BY t0_qt_xxxxxxxxid DESC LIMIT 2000001 ; そしてこの4件のクエリは、対策1-1 と同じ条件（同じレポート表示条件（ブラウザのリロード）であっても、2 回目以降はスキャン量が0Bでした。 対策2 の適用 プルダウンリストのコントロール用のデータソースを作成し、Looker Studio のクロスフィルタリング機能を使用してみます。 プルダウンリストのコントロール用データソースの追加 「地域」「店舗名」フィルタ用データソースは your-project.your-dataset.store_master テーブルを参照します。 「商品カテゴリ」フィルタ用データソースは your-project.your-dataset.product_master テーブルを参照します。 レポート設定 Looker Studio レポートで、メインの表は対策 1-2 で作成したテーブル関数 ( sales_summary_tf ) を参照するデータソースを使用します。 「地域」「店舗名」プルダウンリストのコントロールは、上記で作成した store_master を参照するデータソースを使用するように変更します。 同様に「商品カテゴリ」プルダウンリストのコントロールも product_master を参照するデータソースを使用するように変更します。 メインの表を選択し、[表のプロパティ] > 下部にある [グラフ インタラクション] セクション >「クロスフィルタリング」のトグルがオンとなっていることを確認します。 これにより、ユーザーがプルダウンリストのコントロールで値を選択すると、クロスフィルタリング機能によって、その選択がメインのグラフ（テーブル関数を参照しているデータソース）に適用され、その際に必要なクエリが発行されます。 このレポートを表示すると、1回の表示操作で、BigQuery のジョブ履歴には以下のようなクエリが1件記録されました。 このクエリのスキャン量（課金されるバイト数）は、10 MB でした。 SELECT clmn0_ FROM ( SELECT t0.category AS clmn0_ FROM `your-project.your-dataset.product_master` AS t0 ) GROUP BY clmn0_ ORDER BY clmn0_ DESC LIMIT 2000001 ; さらに、BigQuery のジョブ履歴には以下のようなクエリが2件記録されました。 このクエリのスキャン量（課金されるバイト数）は、1件ごとに、10 MB でした。 SELECT clmn0_ FROM ( SELECT t0.region AS clmn0_ --region, store_name ごとに1件ずつ FROM `your-project.your-dataset.store_master` AS t0 ) GROUP BY clmn0_ ORDER BY clmn0_ DESC LIMIT 2000001 ; BigQuery の費用と追加のコスト最適化策 BigQuery のオンデマンド料金モデルは、クエリによってスキャンされたバイト数に基づいて課金されますが、留意点があります。 BigQuery のオンデマンド料金には、 最小データ処理量 という概念があります。公式ドキュメントには、最小データ処理容量について次のように記載されています。 料金は MB 単位のデータ処理容量（端数は切り上げ）で決まります。クエリが参照するテーブルあたりのデータ最小処理容量は 10 MB、クエリあたりのデータ最小処理容量は 10 MB とします。 参考 : オンデマンド コンピューティングの料金 つまり、非常に小さなテーブルを参照するクエリや、結果データが小さいクエリであっても、最低 10 MB 分の料金が発生します。 したがって、クエリのスキャン量を減らすことと同時に、不要なクエリの発行回数を削減することがコスト最適化につながります。 INFORMATION_SCHEMA.JOBS を使用したクエリ調査方法や、その他のコスト最適化策については、以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。
アバター株式会社G-gen
2025年6月のイチオシGoogle Cloudアップデート
G-gen の杉村です。2025年6月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Pub/Sub に Single Message Transforms（SMTs）機能が登場 BigQuery へのロード時に日付形式、タイムゾーンが指定可能に Google Workspace（Gmail） Googleドライブで "Catch me up" 機能が追加 Gemini アプリで GitHub リポジトリをインポート可能に Gemini 2.5 Pro の最新プレビュー版が利用可能に Oracle Database@Google Cloud が東京リージョンで利用可能に Model Armor が日本語を含む多言語対応 Google Vids における動画生成が音声付きに（Veo 3利用） Google フォームに Gemini が組み込み 新サービス Cloud Location Finder が登場 Looker で継続的インテグレーション（CI）機能がプレビュー公開 Looker（Google Cloud Core）で Code Interpreter in Conversational Analytics Cloud Run jobs で GPU が利用可能（Preview） Gemini 2.5 Flash/Pro が一般公開（GA） Google スプレッドシートの Gemini 分析が日本語に対応 Google フォームに新しいアクセス制御設定が追加 Google Meet で字幕スタイルをカスタマイズできるように BigQuery でメタデータの自動生成が可能に（Preview） 組織レベルで VPC Flow Logs が設定できるように（Preview） Cloud Armor で組織レベルのアドレスグループが作成可能に Gemini Code Assist が大幅パワーアップ Gemini CLI がリリース Artifact Registry で Generic レポジトリが GA Google スプレッドシートで AI 関数が一般公開 新しい Google Workspace アドオン「Google AI Ultra for Business」登場 Cloud Run で worker pools が利用可能に サイドパネルでの画像生成が Imagen 4 を使うように変更 Cloud Armor で階層型セキュリティポリシーが利用可能に（Preview） Security Command Center でリスクレポートを PDF ダウンロード Gemini アプリでスケジュール実行が利用可能に はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Pub/Sub に Single Message Transforms（SMTs）機能が登場 Single Message Transforms (SMTs) overview (2025-06-02) Pub/Sub に Single Message Transforms（SMTs）機能が登場。 Pub/Sub 内でメッセージに対して軽微な変換を直接実行。機密情報をマスク、タイムスタンプ形式を揃える、新しいフィールド作成など。トピックおよびサブスクリプション内のメッセージを対象にできる。 以下の記事も参照。 blog.g-gen.co.jp BigQuery へのロード時に日付形式、タイムゾーンが指定可能に BigQuery release notes - June 02, 2025 (2025-06-02) BigQuery の CREATE EXTERNAL TABLE と LOAD DATA で以下オプションが利用可能（Preview）。 time_zone date_format datetime_format time_format timestamp_format これまで DATE 型としてはロードできなかった「YYYY/mm/dd」といった日付形式をそのままロードできるようになる。従来は、自動スキーマ検知では取り入れることができたが、型を明示するとエラーになった。従来は、STRING 型でいったん取り込むなどしていた。 以下の記事も参照。 blog.g-gen.co.jp Google Workspace（Gmail） Gmail に Jira のアドオンが登場 Integrate Jira with Gmail to create, update, and track work items directly in your inbox (2025-06-02) Gmail に Jira のアドオンが登場。 Gmail から直接 Jira に issue の作成・閲覧などが可能。 Googleドライブで "Catch me up" 機能が追加 Stay up to date on the latest changes to your files in Drive using “Catch me up” (2025-06-03) Googleドライブで "Catch me up" 機能が追加。 最後に閲覧したときからのファイルの変更点を AI がまとめて表示してくれる。ただし現在のところ、アカウント設定を英語にする必要あり。順次ロールアウト。 Gemini アプリで GitHub リポジトリをインポート可能に Upload code folders or import your GitHub repositories directly into the Gemini app (2025-06-04) Google Workspace 付属の Gemini アプリで、GitHub リポジトリをインポートできるようになった。 リポジトリ内のコードを前提にして新たなコードを生成、修正したり、説明させたりできる。 Gemini 2.5 Pro の最新プレビュー版が利用可能に Vertex AI release notes - June 05, 2025 (2025-06-05) Gemini 2.5 Pro の最新プレビュー版 gemini-2.5-pro-preview-06-05 が利用可能に。 基本機能に違いはなく、精度が向上。 Oracle Database@Google Cloud が東京リージョンで利用可能に Regional availability (2025-06-05) Oracle Database@Google Cloud が東京リージョンで利用可能に。利用可能リージョンは以下のとおり。 asia-northeast1（Tokyo, Japan） us-east4（Northern Virginia） us-west3（Salt Lake City） europe-west2（London） europe-west3（Frankfurt） Model Armor が日本語を含む多言語対応 Security Command Center release notes - June 08, 2025 (2025-06-08) Model Armor が日本語を含む多言語対応。 「責任ある AI」および「プロンプトインジェクションとジェイルブレイクの検出」機能において、以下の言語が対応。 日本語 英語 スペイン語 フランス語 イタリア語 ポルトガル語 ドイツ語 中国語（北京語） 韓国語 以下の記事で検証結果を掲載。 blog.g-gen.co.jp Google Vids における動画生成が音声付きに（Veo 3利用） Generate video clips with sound using Veo 3 in Google Vids (2025-06-09) Google Workspace に付属の動画編集ツール Google Vids における動画生成が音声付きに。 新モデル Veo 3 を使って8秒間の動画クリップを生成。順次ロールアウト。なお現在のところ、動画生成はアカウントを英語設定にしないと使えない。 Google フォームに Gemini が組み込み Use Gemini in Google Forms to summarize form responses (2025-06-10) Google フォームにも Gemini が組み込まれる。 フォームへの回答をサマリ。回答者の回答だけでなくフォームのタイトル、説明、質問もコンテキストとして使われる。順次ロールアウト。 新サービス Cloud Location Finder が登場 Cloud Location Finder overview (2025-06-11) Google Cloud に新サービス Cloud Location Finder が登場。 指定の Google Cloud、AWS、Azure、OCI のリージョン・ゾーン間で、最もレイテンシや二酸化炭素排出量や小さい場所を検索できる。現在は gcloud または REST API のみ Looker で継続的インテグレーション（CI）機能がプレビュー公開 Looker Continuous Integration (2025-06-11) Looker で継続的インテグレーション（CI）機能がプレビュー公開。 プルリク時に「SQL や LookML のバリデーション」「Assert」「ダッシュボードのエラーチェック」などのバリデーションが走る。本番環境への展開前に各種チェックが可能。 Looker（Google Cloud Core）で Code Interpreter in Conversational Analytics Conversational Analytics Code Interpreter (2025-06-11) Original 版 Looker に続いて Google Cloud Core 版でも Code Interpreter in Conversational Analytics がプレビュー公開。 AI が自然言語の指示を Python に書き換えて、分析や可視化をしてくれる。デフォルトでオフだが管理ページから有効化できる。現在、以下のプラットフォームで利用可能。 Looker Studio Pro Looker（original） Looker（Google Cloud core） Cloud Run jobs で GPU が利用可能（Preview） Configure GPUs for Cloud Run jobs (2025-06-16) Cloud Run jobs で GPU が利用可能に（Preview）。 これで、Cloud Run services と jobs の両方で GPU が利用可能になった。24 GB の GPU メモリ（VRAM）を搭載した NVIDIA L4 GPU を1つ、コンテナインスタンスにアタッチ可能。 Gemini 2.5 Flash/Pro が一般公開（GA） Vertex AI release notes - June 17, 2025 (2025-06-17) Gemini 2.5 Flash/Pro が一般公開（GA）。 これまでの Preview 版は 2025-07-15 には使用不可になるので注意。同時に以下も利用可能に。 低レイテンシモデルである Gemini 2.5 Flash-Lite（Preview） 双方向の音声・動画やりとりができる Live API（申請が必要な Private GA） Gemini 2.5 Flash の価格帯は Preview 時から変更 thinking output は安価に、non-thinking output は高価に。 Google スプレッドシートの Gemini 分析が日本語に対応 Generate charts and valuable insights using Gemini in Google Sheets in additional languages (2025-06-17) Google スプレッドシートで、Gemini サイドパネルにおけるデータ分析が日本語に対応。 自然言語で指示すると裏で Python コードに変換し実行、スプシのデータから洞察や図表を生成してくれる。Business/Standard Enterprise以上のプラン等で利用可能。 Google フォームに新しいアクセス制御設定が追加 Adding new admin settings to control Google Form responses (2025-06-17) Google フォームに新しい管理者設定が追加。以下を管理画面から制御できるようになった。 組織のアカウントが組織外のフォームに回答できるかどうか 組織のアカウントが作ったフォームを組織外に共有できるかどうか Google Meet で字幕スタイルをカスタマイズできるように Google Meet now offers customizable caption styling (2025-06-17) Google Meet で字幕（caption）のスタイルをカスタマイズできるようになった。 サイズ、フォント、色を変更可能。順次ロールアウト。 BigQuery でメタデータの自動生成が可能に（Preview） Generate data insights in BigQuery (2025-06-18) BigQuery で Gemini によりテーブルと列の説明（Description）を自動生成可能に（Preview）。 Data insightでテーブルの分析情報を生成すると Description も生成。テーブル、外部テーブル、ビューで利用可。Google Cloud Next で発表されたメタデータ自動生成の実装。生成されるメタデータは、現在は英語のみ。 BigQuery のメタデータ自動生成 組織レベルで VPC Flow Logs が設定できるように（Preview） Enable VPC Flow Logs for an organization (2025-06-18) 組織レベルや VPC ネットワークレベルで VPC Flow Logs が設定できるように（Preview）。 これまではサブネットレベルや VLAN アタッチメントごとに有効化する必要があった。組織レベルで証跡管理の統制を取る際に有用。 Cloud Armor で組織レベルのアドレスグループが作成可能に Organization-scoped address groups (2025-06-24) Cloud Armor で組織レベルのアドレスグループが作成可能に（Preview）。 組織レベルで IP アドレスのグループを定義して、許可リストや拒否リストとして使い回すことができるようになった。これまではプロジェクトレベルで都度作成する必要があった。 Gemini Code Assist が大幅パワーアップ Gemini Code Assist release notes - June 25, 2025 (2025-06-25) Google のコーディング支援ツール「Gemini Code Assist」が大幅パワーアップ。 エージェントモード（複数ステップタスクの提案と実行） プロジェクト全体コンテキストへの理解 複数ファイルにまたがる編集 Google Cloud Next で発表された「Gemini Code Assist Agents」の一部が実装されたもの。 Gemini CLI がリリース Gemini CLI: your open-source AI agent (2025-06-25) Gemini CLI がリリース。Node.js ベースの CLI。 Gemini Code Assist と連携しており AI コーディングのインターフェイスとして利用可能。無料版および Gemini Code Assist Standard/Enterprise 付帯版。Google検索グラウンディングや MCP での拡張も対応。 Gemini CLI 起動直後 以下の記事も参照。 blog.g-gen.co.jp Artifact Registry で Generic レポジトリが GA Work with other artifact formats (2025-06-25) Artifact Registry で Generic レポジトリが GA。 特定フォーマットでなくバイナリや zip、YAML、PDF、テキスト、メディアファイルなど何でも格納できる。 Google スプレッドシートで AI 関数が一般公開 Generate data with Gemini in Google Sheets (2025-06-25) Google スプレッドシートで AI 関数が一般公開。テキスト生成、要約、分類などがスプシ上の関数だけで実現できる。 =AI("プロンプト") のように使う。Business/Enterprise Standard 以上などのエディションで利用可。2025-06-25から順次ロールアウトされていく。 新しい Google Workspace アドオン「Google AI Ultra for Business」登場 Introducing Google AI Ultra for Business: Providing Access to Advanced AI Features and Next-Gen tools (2025-06-26) Google Workspace に新しい AI アドオンライセンス「Google AI Ultra for Business」が登場。 Gemini アプリで動画生成の上限緩和 映像生成ツール Flow 画像生成ツール Whisk Project Mariner へのアクセス ... 等 2025-06-26 から Business/Enterprise エディションのアドオンとして購入可能。 Cloud Run で worker pools が利用可能に Deploy worker pools to Cloud Run (2025-06-26) Cloud Run で新しいデプロイモデルである worker pools が利用可能になった。 メッセージキューから Pull してタスクを処理していくための Cloud Run モデル。services と同様、リビジョンの概念あり。以下の記事も参照。 blog.g-gen.co.jp サイドパネルでの画像生成が Imagen 4 を使うように変更 Google Workspace Updates Weekly Recap - June 27, 2025 (2025-06-27) Googleドキュメント、スライド、Google Vids での画像生成が最新モデル Imagen 4 を使うようになった。 日本語にもすでに対応。従来よりプロンプト遵守の精度が上がったり、画像内のテキストの精度があがる等している。 Cloud Armor で階層型セキュリティポリシーが利用可能に（Preview） Hierarchical security policies overview (2025-06-27) Google Cloud のフルマネージド WAF である Cloud Armor で、階層型セキュリティポリシーが Preview 公開。 プロジェクト内だけでなく、組織で使い回せる。使用するには Cloud Armor Enterprise ティアの登録が必要。従来ポリシーと併用可能で先に階層型ポリシーが評価される。 Security Command Center でリスクレポートを PDF ダウンロード Hierarchical security policies overview (2025-06-27) Security Command Center（Enterprise/Premium）でリスクレポートを PDF ダウンロードできるようになった（Preview）。 ハイリスクリソースの分析 攻撃者のエントリポイント 問題ある設定の組み合わせ ... など Gemini アプリでスケジュール実行が利用可能に Gemini アプリでアクションのスケジュールを設定する (2025-06-29) Gemini アプリでスケジュール実行が利用可能になった。プロンプトでやらせたいアクションを指示すると、定期的に実行してくれる。 未読メールまとめ To Do 管理 ... など 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it
アバター株式会社G-gen
Gemini CLIを解説
G-genの杉村です。Google が公開するオープンソースの AI エージェント Gemini CLI について解説します。 概要 Gemini CLI とは 料金 初期設定 インストール 認証 Cloud Shell での利用 リモートサーバー等での利用 使い方 対話型実行 非対話型実行 プロジェクトごとのコンテキスト設定 Gemini Code Assist との連携（エージェントモード） プライバシーポリシーとデータ保護 Gemini モデルに関するデータ保護 Gemini CLI の統計情報 概要 Gemini CLI とは Gemini CLI とは、ターミナルから直接 Gemini の機能を利用できる、オープンソース（Apache 2.0 ライセンス）の AI エージェントです。 gemini コマンドを介して、自然言語でコーディング、デバッグ、情報検索、各種タスクの自動化などを実行できます。 主に開発者による利用が想定されている CLI ツールであるといえます。 Gemini CLI は、ローカルのファイルシステムを直接読み書きしたり、シェルコマンドを実行したり、Web 検索を行ったりできます。これにより、単なるコード生成に留まらず、プロジェクト全体にわたるリファクタリングや、定型的な開発タスクの自動化といった、より実践的なワークフローに Gemini を組み込むことが可能になります。 Gemini CLI は Google の最新モデルである Gemini 2.5 Pro などをモデルとして利用しており、100 万トークンという広大なコンテキストウィンドウを活用できます。 参考 : Gemini CLI: your open-source AI agent 参考 : Gemini CLI  |  Gemini Code Assist  |  Google for Developers 参考 : GitHub - google-gemini/gemini-cli 2025年9月現在、Gemini CLI は Preview 段階と位置づけられています。 料金 Gemini CLI は、使用方法によっては 無料 で利用できます。Gemini CLI 自体はオープンソースであるため、利用料金はかかりません。しかし、背後で動作する LLM（Gemini）の利用料金を考慮する必要があります。 個人の Google アカウントでログインすると、1分あたり 60 リクエスト、1日あたり 1,000 リクエストまで無料でモデルを呼び出すことができます。 より多くのリクエストが必要な場合、使用量ベース課金の Google AI Studio （API Key）または Google Cloud の Vertex AI、あるいは有償版の Gemini Code Assist Standard / Enterprise ライセンスを利用することも可能です。 参考 : GitHub - docs/quota-and-pricing.md 参考 : Quotas and limits  |  Gemini Code Assist  |  Google for Developers また Gemini Code Assist Standard / Enterprise ライセンスで Gemini CLI を利用すると、利用量の制限が緩和されるほか、Gemini Code Assist と連携して VS Code で Gemini Code Assist エージェントモード が利用可能になります。 参考 : Gemini CLI - Gemini Code Assist agent mode Google Workspace アカウントでも Gemini CLI を利用可能です。後述する Login with Google の方法で Google Workspace アカウントを使って認証する場合、 Google Cloud プロジェクト ID の指定が必須 です。ただしこの方法を使って認証する場合、どのような利用規約が適用されるのか、また料金が発生するかどうかについて、Google は明確なドキュメントを用意していません。Google Workspace アカウントをお使いの方が業務等で Gemini CLI を利用する場合、後述の「初期設定 > 認証」の後で紹介するように、Google Cloud の Vertex AI で認証、あるいは Gemini Code Assist の有償プランを使って認証することが推奨されます。 初期設定 インストール Gemini CLI は npm パッケージとして配布されています。Node.js v18 以降がインストールされている環境で、以下のコマンドを実行してインストールします。 # npm コマンドによるインストール npm install -g @google/gemini-cli # もしくは以下のコマンド npx https://github.com/google-gemini/gemini-cli インストール後、 gemini コマンドを実行すると、Gemini CLI が起動します。 gemini Gemini CLI 起動直後 認証 初めてこのコマンドを実行するときは、文字への色付けなど見た目の設定に続いて、自動的に認証フローが開始されます。 Gemini CLI の認証 Login with Google を選択すると、新しいブラウザウインドウがポップアップして、Google アカウントによる認証が走ります。Gemini CLI の無償版や Gemini Code Assist 有償プランと連携したいときは、この認証方法を選択します。 参考 : GitHub - google-gemini/gemini-cli/docs/cli/authentication.md export GOOGLE_CLOUD_PROJECT = " my-google-cloud-project " Gemini API Key は、Google AI Studio の API キーを指定して認証するときに選択します。モデルの呼び出しが Google AI Studio 経由になります。これを選択することで、呼び出し量制限が緩和された従量課金になります。 Vertex AI を選択すると、モデルの呼び出しが Google Cloud の Vertex AI 経由になります。この方法で認証するには、事前に Vertex AI API（ aiplatform.googleapis.com ）を有効化した Google Cloud プロジェクトを用意しておく必要があります。その後、環境変数または .env ファイルで、プロジェクト ID やリージョンなどを指定します。 export コマンドで事前に以下のような環境変数を定義しておくか、 .env と名付けたファイルをコマンド実行ディレクトリに配置することで、設定が読み込まれます。 .env ファイル（環境変数）の例 GOOGLE_GENAI_USE_VERTEXAI = " true " GOOGLE_CLOUD_PROJECT = " my-google-cloud-project " GOOGLE_CLOUD_LOCATION = " global " Google Cloud をすでに利用中であれば、この認証方法を選択することで、呼び出し量制限が緩和された従量課金になります。また、入力したプロンプトや出力されたレスポンスは、Google Cloud の規約に従って保護され、再トレーニングなどには使われません。 なお Vertex AI 経由の認証の場合、事前に gcloud auth application-default login コマンドを実行して、Gemini CLI が Google Cloud へ認証できるようにする必要があります。 Cloud Shell での利用 Google Cloud の Web コンソールには、 Cloud Shell と呼ばれる仮想 Linux ターミナル環境が付属しています。この Cloud Shell 環境でも、Gemini CLI が利用できます。 Cloud Shell にはデフォルトで Gemini CLI がインストールされており、 追加のセットアップは必要ありません 。 参考 : Gemini CLI なお認証については、Gemini CLI を Cloud Shell 環境で起動すると、 Use Cloud Shell user credentials が選択肢として表示されます。これを選択すると、Gemini CLI は自動的に Cloud Shell 環境にログインしているユーザーアカウントの認証情報を使って認証を行います。 Cloud Shell 環境では Use Cloud Shell user credentials が選択できる Cloud Shell 環境における開発に関するその他の情報については、以下の記事も参考にしてください。 blog.g-gen.co.jp リモートサーバー等での利用 リモートのサーバー上で Gemini CLI を認証するときなどには、Login with Google の認証方法を選択すると、操作の途中で処理が止まってしまうことがあります。この認証方法を選択した場合、認証フローの中でブラウザウインドウがポップアップし、ログイン操作後に localhost にリダイレクトして戻って来る挙動があることに由来します。リモートサーバーは localhost とは別のプラットフォームで動作していますので、ブラウザからのリダイレクト時に Gemini CLI まで情報を戻すことができないことが原因です。 参考 : GitHub - google-gemini/gemini-cli/docs/cli/authentication.md 認証プロセスの途中でスタックする このような場合には、 NO_BROWSER という名前の環境変数に値を設定してから Gemini CLI を起動することで、ブラウザのポップアップとリダイレクトをしない方法で認証を行うことができます（Gemini CLI の v0.1.11 以降で利用可能）。 参考 : GitHub - google-gemini/gemini-cli - Release v0.1.11 まず、 NO_BROWSER という名前の環境変数に何らかの値をセットします。 export NO_BROWSER =true その後、Gemini CLI を起動します。以前の認証方法から変更する場合、 /auth を実行します。 環境変数 NO_BROWSER を設定後、Login with Google を選択 すると CLI の再起動を促され、CLI が終了します。再度、gemini コマンドを実行して CLI を起動します。すると、以下のように認証用 URL が発行されるため、この URL にブラウザでアクセスします。 認証用 URL が発行される ブラウザ上で Google アカウントでログインすると、認証コードの文字列が発行されます。この文字列をコピーし、ターミナル上で貼り付けて Enter を入力すると、認証が完了します。 認証コードが発行される 使い方 対話型実行 ターミナルで gemini コマンドを引数なしで実行すると、対話型モードで Gemini CLI が起動します。 gemini プロンプトが表示されたら、自然言語で指示を入力します。 引数を2つ取って、足し算をする Python ライブラリを作ってください。 テストもしたいです。 すると、Gemini は思考プロセスや作業の内容を表示します。 ローカルへのファイル作成とコマンド実行（1） ローカルへのファイル作成とコマンド実行（2） シェルコマンドの実行やファイルを作成するときなどには、ユーザーに実行の許可を求めます。 次のタスクを実行 プロンプトでテストの実行も依頼していたことから、テストコードも作成してくれました。単一タスクではなく、指示に基づいて複数ステップのタスクを行っていることがわかります。 作成されたコードの実行（1） 作成されたコードの実行（2） 最後に、テストコードの実行まで行い、タスクが完了しました。 非対話型実行 パイプや引数を使って、ワンショットでタスクを実行することもできます。これは、シェルスクリプトに処理を組み込む際に便利です。 --prompt オプションをつけると、対話型でなく、ワンショットの処理を行ってくれます。 $ cat calculator.py | gemini --prompt " このコードを説明して " このPythonコードは `add` という名前の関数を定義しています。 この関数は `a` と `b` の 2 つの引数（数値）を受け取り、それらを足し算した結果を返します。 例えば、 `add ( 2 , 3 ) ` のように呼び出すと、 ` 5 ` が返ってきます。 プロジェクトごとのコンテキスト設定 プロジェクトのルートディレクトリに GEMINI.md という名前の Markdown ファイルを配置することで、そのプロジェクト専用のシステムプロンプトを設定できます。 例えば、 GEMINI.md に以下のように記述しておくと、Gemini はこの指示を常に念頭に置いて応答するようになります。 # プロジェクト概要 このプロジェクトは Python で記述されています。 コーディング規約は pep8 のスタイルガイドに従います。 # ルール .... Gemini Code Assist との連携（エージェントモード） Gemini Code Assist のライセンス（無償版、Standard、Enterprise）で Gemini CLI の認証を行うと、VS Code で Gemini Code Assist エージェントモード （agent mode）が使えます。 エージェントモードでは、単なる自然言語に従った生成に留まらず、計画、実行、検証、反復的な修正など、複数のステップを含む複雑なタスクをこなすことができます。 参考 : Gemini CLI - Gemini Code Assist agent mode 参考 : Use the Gemini Code Assist agent mode  |  Google for Developers エージェントモードでは、以下のような機能が利用可能です。MCP サーバーの利用や、ユーザーの承認を得ずにすべてのタスクを Gemini CLI が実行できる Yolo モード、その他のツールなどが利用可能になります。 Model Context Protocol（MCP）servers Gemini CLI commands（ /memory 、 /stats 、 /tools 、 /mcp ） Yolo（You Only Look Once）mode built-in tools（ grep 、 terminal 、 file read or file write ...） Web search Web fetch プライバシーポリシーとデータ保護 Gemini モデルに関するデータ保護 Gemini CLI の「Terms of Service and Privacy Notice」は以下で公開されています。なお、当記事の記載内容は2025年9月中旬現在の情報に基づいていますので、最新情報は必ず以下の規約ドキュメントを確認してください。 参考 : GitHub - google-gemini/gemini-cli/docs/tos-privacy.md Gemini CLI で Gemini モデルを使用した際に、どのようなプライバシーポリシーが適用され、収集されたデータ（プロンプト、回答、コード）がどのように扱われるかは、 認証方法に依存 します。 連番 認証方法 概要 利用規約 プライバシーポリシー 1 Login with Google かつ Gemini Code Assist 有償プラン なし データは Google のサービス改善やモデル改善に使われる可能性が ある Google Terms of Service Gemini Code Assist Privacy Notice for Individuals 2 Login with Google かつ Gemini Code Assist 有償プラン あり データは Google のサービス改善やモデル改善には使われ ない Google Cloud Platform Terms of Service Gemini Code Assist Privacy Notice for Standard and Enterprise 3 Gemini API Key（無償版） データは Google のサービス改善やモデル改善に使われる可能性が ある Gemini API Terms of Service - Unpaid Service Google Privacy Policy 4 Gemini API Key（有償版） データは Google のサービス改善やモデル改善には使われ ない Gemini API Terms of Service - Paid Service Google Privacy Policy 5 Vertex AI データは Google のサービス改善やモデル改善には使われ ない Google Cloud Platform Service Terms Google Cloud Privacy 上記から、データが保護される（入力したプロンプトや AI からのレスポンスなどが Google のサービス改善や再トレーニングに使われ ない ことを指します）ための条件は、以下のとおりです。 Gemini Code Assist の有償プラン（Standard / Enterprise）のライセンスと紐づいた Google アカウントで認証している（表の2） Gemini API Key（Google AI Studio）の有償版で認証している（表の4） Google Cloud の Vertex AI で認証している（表の5） 上記以外のケースでは、個人 Google アカウントか Google Workspace アカウントかに関わらず、入出力データは Google に再利用される可能性があります。 なお、2025年7月初頭ころの Terms of Service and Privacy Notice ドキュメントでは、Google Workspace ユーザーであれば、無条件でデータが保護されるように解釈できる記載がありました。しかし2025年7月中旬ころにこの記載が改められ、上記に要約したとおりの記載となっています。 参考 : GitHub - google-gemini/gemini-cli/docs/tos-privacy.md - 8957ad7 前述したように、 Login with Google の方法で Google Workspace アカウントを使って認証する場合、どのような利用規約が適用されるのか、また料金が発生するかどうかについて、Google はドキュメントに明記していません。Google Workspace アカウントをお使いの方が業務等で Gemini CLI を利用する場合、Vertex AI で認証、あるいは Gemini Code Assist の有償プランを使って認証することが推奨されます。 Gemini CLI の統計情報 前述の表は、Gemini モデル側のデータの扱いを示しています。一方、Gemini CLI 自体も 利用統計 （Usage Statistics）という情報を収集しています。利用統計の収集は、 オプトアウト （無効化）することができます。 参考 : GitHub - google-gemini/gemini-cli/docs/cli/configuration.md - Usage Statistics 利用統計では、ツールの呼び出しや API リクエストの記録、CLI の設定情報などが収集対象です。一方で、プロンプトやレスポンス、氏名やメールアドレス、ファイルの内容などは収集されません。よって、オプトアウトする、しないに関わらず、プロンプトやレスポンスが保護されるかどうかは、前述の規約に依存します。 前述の表の1と3では、利用統計をオプトアウトしたとしても、停止されるのは上記の統計情報の収集のみであり、依然としてプロンプトやレスポンスなどは Google に収集され、サービス改善や再トレーニングに使用される可能性は残ります。 よって、Gemini CLI で機微な情報を扱う場合は、前述の表の 2、4、5 のいずれかを選択することが望ましいといえます。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it
アバター株式会社G-gen
異なるリージョンのBigQuery MLリモートモデルでデータを処理するパイプラインを実装してみた
G-gen の堂原です。本記事では Google Cloud（旧称 GCP）の BigQuery において、データセットとリモートモデルが異なるリージョンに存在する場合の、AI データ処理パイプラインを紹介します。 はじめに 本記事の趣旨 ML.GENERATE_TEXT 関数と Gemini 2.0 の対応リージョン 概要 今回用いるデータ テーブル構成と処理概要 留意点 実装 1. us-central1 へ転送するデータ抽出 2. データセット「tokyo_from_tokyo_to_us」のテーブルをデータセット「us」にコピー 3. リモートモデル「gemini-model-20-flash」を用いてテーブル「daily-feedback」を処理 4. データセット「us_from_us_to_tokyo」のテーブルをデータセット「tokyo」にコピー 5. 評価済みデータの整形 処理結果 はじめに 本記事の趣旨 本記事では、BigQuery データセット・テーブルと BigQuery ML のリモートモデルが異なるリージョンに存在する状況下における、データ処理パイプラインについて紹介します。 具体的には、 BigQuery Data Transfer Service を用いて、処理の対象となるデータをリモートモデルが存在するリージョンにコピーし、コピーしたデータに対して処理をします。 参考 : BigQuery の AI と ML の概要 参考 : BigQuery Data Transfer Service とは ML.GENERATE_TEXT 関数と Gemini 2.0 の対応リージョン BigQuery ML の ML.GENERATE_TEXT は、SQL クエリから直接大規模言語モデル（LLM）を呼び出し、テキスト生成や分類などのタスクを実行できる関数です。これにより、データの前処理から LLM による推論までを一貫して BigQuery で完結させることができます。 参考 : ML.GENERATE_TEXT 関数を使用してテキストを生成する  |  BigQuery  |  Google Cloud BigQuery ML の制約として、テーブルとリモートモデルは同一のリージョンに存在する必要があります。一方、2025 年 5 月現在、Gemini 2.0 や Gemini 2.5 は東京リージョン（asia-northeast1）で利用できず、東京リージョンに保存されている BigQuery のデータを直接処理できません。 参考 : Gemini 2.0 Flash  |  Generative AI on Vertex AI  |  Google Cloud 参考 : Gemini 2.5 Pro  |  Generative AI on Vertex AI  |  Google Cloud 概要 今回用いるデータ 今回使用するデータは、架空のスマートフォンに寄せられたユーザーフィードバックです。以下のスキーマを持つテーブルを想定しています。 フィールド名 型 説明 timestamp TIMESTAMP フィードバックを受けた日時 userEmail STRING ユーザーのメールアドレス userFeedback STRING ユーザーのフィードバックメッセージ 以下にサンプルデータを示します。 timestamp userEmail userFeedback 2025-05-24 09:20:00 UTC user_gg@example.com サポートセンターの対応が迅速で丁寧でした。これからも応援しています！ 2025-05-23 21:55:00 UTC user_ee@test.jp 通知音が小さくて気づかないことが多いです。もっと大きくしてください。マナーモードでも振動が弱いです。 テーブル構成と処理概要 当記事では、架空のスマートフォンに寄せられたユーザーフィードバックを、Gemini 2.0 Flash を使って「ポジティブ」「ネガティブ」「ニュートラル」に分類するパイプラインを構築します。 まず、登場する複数のデータセットとテーブルの関係性を図に示します。 パイプラインは以下の5つのステップで構成され、それぞれスケジュールされた時間で実行されます。 ステップ リージョン コンポーネント 開始時間 処理内容 1 asia-northeast1 スケジュールドクエリ 毎日 01:00 us-central1 へ転送するデータ抽出（「daily-feedback」テーブル更新） 2 us-central1 Data Transfer Service 毎日 01:30 データセット「tokyo_from_tokyo_to_us」のテーブルをデータセット「us」にコピー 3 us-central1 スケジュールドクエリ 毎日 02:00 リモートモデル「gemini-model-20-flash」を用いてテーブル「daily-feedback」を処理（「evaluation-of-daily-feedback」テーブル更新） 4 asia-northeast1 Data Transfer Service 毎日 02:30 データセット「us_from_us_to_tokyo」のテーブルをデータセット「tokyo」にコピー 5 asia-northeast1 スケジュールドクエリ 毎日 03:00 評価済みデータの整形（「evaluation-of-feedback」テーブル更新） 留意点 単純化するため、当記事ではスケジュールドクエリと Data Transfer Service の設定を個別に行い、30 分ごとに実行するようにしていますが、実際には Cloud Workflows などのオーケストレーションツールを用いて一連のパイプラインとして統合することが推奨されます。 また、本パイプラインでは、異なるリージョン間でデータを転送するため、BigQuery のデータ転送料金が発生します。同一リージョン内で処理を完結させる場合に比べて追加の費用がかかる点にご留意ください。詳細な料金については、Google Cloud の公式ドキュメントをご確認ください。 参考 : Data extraction pricing 実装 1. us-central1 へ転送するデータ抽出 asia-northeast1 に存在するフィードバックデータ「product-feedback」から、当日に処理したいデータを抽出します。この抽出結果は、一時的にデータセット「tokyo_from_tokyo_to_us」のテーブル「daily-feedback」に格納されます。 これは、Data Transfer Service によるデータ転送時の課金対象データ量を削減するためです。 -- 挿入先のテーブルを空に TRUNCATE TABLE `tokyo_from_tokyo_to_us.daily-feedback`; -- データ挿入 INSERT INTO `tokyo_from_tokyo_to_us.daily-feedback` SELECT * FROM `tokyo.product-feedback` WHERE DATE ( timestamp , " Asia/Tokyo " ) = DATE (@run_time, " Asia/Tokyo " ) - 1 ; この SQL は、BigQuery のスケジュールドクエリとして毎日午前 1 時に実行されるように設定します。 @run_time パラメータは、スケジュールドクエリの実行時に自動的に現在のタイムスタンプが渡されます。 2. データセット「tokyo_from_tokyo_to_us」のテーブルをデータセット「us」にコピー 次に、ステップ 1 で抽出したデータを asia-northeast1 から us-central1 へコピーします。これには Data Transfer Service を使用します。 Data Transfer Service の設定は以下の通りです。 送信元データセット : tokyo_from_tokyo_to_us (asia-northeast1) 送信先データセット : us (us-central1) オプション Overwrite destination table : 有効 このデータ転送は、毎日午前 1 時半に実行されるようにスケジュールします。 3. リモートモデル「gemini-model-20-flash」を用いてテーブル「daily-feedback」を処理 us-central1 にコピーされたデータに対して、BigQuery ML の ML.GENERATE_TEXT 関数を用いてフィードバックの評価を行います。評価結果は、データセット「us_from_us_to_tokyo」内の「evaluation-of-daily-feedback」テーブルに格納されます。 -- プロンプト DECLARE prompt_template STRING; SET prompt_template = """ スマートフォン「ryu-do phone」に対する、ユーザーからのフィードバックを与えます。そのフィードバックが以下の評価のうち、どれに最も当てはまるかを回答してください。: - ポジティブ - ネガティブ - ニュートラル # フィードバック UIが直感的でとても使いやすいです。 # 評価 ポジティブ # フィードバック 指紋認証の精度が悪く、なかなか認識してくれません。ストレスが溜まります。 # 評価 ネガティブ # フィードバック __feedback__ # 評価 """ ; -- 挿入先のテーブルを空に TRUNCATE TABLE `us_from_us_to_tokyo.evaluation- of -daily-feedback`; -- Geminiによるフィードバックの評価 INSERT INTO `us_from_us_to_tokyo.evaluation- of -daily-feedback` SELECT timestamp , userEmail, ml_generate_text_llm_result AS evaluation FROM ML.GENERATE_TEXT( MODEL `us.gemini-model -20 -flash`, ( SELECT REPLACE (prompt_template, " __feedback__ " , userFeedback) AS prompt, * FROM `us.daily-feedback` ), STRUCT( 0 AS temperature, 8192 AS max_output_tokens, TRUE AS flatten_json_output ) ); この SQL は、BigQuery のスケジュールドクエリとして毎日午前 2 時に実行されるように設定します。 4. データセット「us_from_us_to_tokyo」のテーブルをデータセット「tokyo」にコピー ステップ 3 で処理された評価結果を、再び asia-northeast1 へコピーします。これも Data Transfer Service を使用します。 送信元データセット : us_from_us_to_tokyo (us-central1) 送信先データセット : tokyo (asia-northeast1) オプション Overwrite destination table : 有効 このデータ転送は、毎日午前 2 時半に実行されるようにスケジュールします。 5. 評価済みデータの整形 最後に、asia-northeast1 にコピーされた評価済みデータを、元のフィードバックデータと結合し、最終的な形式に整形します。この整形結果は、分析用テーブル「evaluation-of-feedback」に格納されます。 -- データの重複を防ぐため、同一期間のデータを削除 DELETE FROM `tokyo.evaluation- of -feedback` WHERE DATE ( timestamp , " Asia/Tokyo " ) = DATE (@run_time, " Asia/Tokyo " ) - 1 ; -- 処理内容を挿入 INSERT INTO `tokyo.evaluation- of -feedback` SELECT evaluation. timestamp , evaluation.userEmail, feedback.userFeedback, evaluation.evaluation[f:id:ggen-sugimura:20250627090010p:plain] FROM `tokyo.evaluation- of -daily-feedback` AS evaluation INNER JOIN `tokyo_from_tokyo_to_us.daily-feedback` AS feedback ON evaluation. timestamp = feedback. timestamp AND evaluation.userEmail = feedback.userEmail; この SQL は、BigQuery のスケジュールドクエリとして毎日午前 3 時に実行されるように設定します。 処理結果 上記のパイプラインを実行することで、テーブル「evaluation-of-feedback」には以下のようなデータが格納されます。 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara
アバター株式会社G-gen
Cloud RunからCloud SQLへセキュアに接続してみた
G-genの福井です。Cloud Run から Cloud SQL に対し、内部通信と IAM データベース認証を使用してセキュアに接続する手順を紹介します。 はじめに 当記事の概要 内部通信での接続 IAM データベース認証 事前準備 API の有効化 環境変数の設定 環境構築 ネットワーク環境の構築 Cloud SQL インスタンスの作成 アプリケーションの準備 ディレクトリ構成 アプリケーションソース Cloud Run へのデプロイ サービスアカウントの作成と権限付与 Cloud SQL ユーザーとしてのサービスアカウント登録 Cloud Run にデプロイ 動作確認 はじめに 当記事の概要 当記事では、Google Cloud のフルマネージドなコンテナ実行環境である Cloud Run から、同じくフルマネージドなリレーショナルデータベースサービスである Cloud SQL へセキュアに接続する手順について解説します。 blog.g-gen.co.jp 具体的には、以下2点の方法でセキュアな接続を実現します。 内部通信での接続 当記事では、Cloud SQL インスタンスに外部 IP アドレスを付与せず、VPC ネットワーク内の閉じた経路で Cloud Run から接続します。これにより、セキュリティリスクを低減します。 また、Cloud Run から VPC ネットワークへのアクセスには、 Direct VPC Egress を利用します。 参考 : パブリック IP を無効にする 参考 : Cloud RunのDirect VPC Egressを解説 - G-gen Tech Blog IAM データベース認証 Cloud SQL のデータベースユーザーとパスワードでの認証の代わりに、サービスアカウントを利用した IAM データベース認証 を使用します。これにより、パスワード管理の煩雑さから解放され、アクセス制御を IAM で統一管理できるため、よりセキュアにデータベースへのアクセスが実現できます。 参考 : IAM 認証 事前準備 API の有効化 Cloud Run、Cloud SQL、VPC ネットワーク、およびコンテナイメージの保存に必要な Artifact Registry などの API を有効化します。 gcloud services enable \ sqladmin.googleapis.com \ compute.googleapis.com \ servicenetworking.googleapis.com \ artifactregistry.googleapis.com \ cloudbuild.googleapis.com \ run.googleapis.com 環境変数の設定 以降の手順で繰り返し使用する Google Cloud プロジェクト ID やリージョンなどの情報を環境変数に設定します。 ご自身の環境に合わせて、以下のコマンドで環境変数を設定してください。 # Google Cloud プロジェクト ID # ※ ご自身の Google Cloud プロジェクト ID に置き換えてください export PROJECT_ID = " your-project-id " # プロジェクトのデフォルトリージョン export REGION = " asia-northeast1 " # Cloud SQL インスタンス名 export SQL_INSTANCE_NAME = " my-postgres-instance " # Cloud Run サービス名 export RUN_SERVICE_NAME = " my-app-service " # VPC ネットワーク名 export VPC_NETWORK_NAME = " my-vpc-network " # サブネット名 export SUBNET_NAME = " my-subnet " # Cloud SQL が使用するプライベート IP アドレス範囲名 export PRIVATE_IP_RANGE_NAME = " my-ip-range " # Cloud Run で使用するサービスアカウント名 export RUN_SA_NAME = " run-sa-for-sql " # Cloud SQL のデータベース名 export DB_NAME = " postgres " 環境構築 ネットワーク環境の構築 Cloud Run と Cloud SQL が安全に通信するためのプライベートなネットワーク環境を構築します。 VPC ネットワークの作成 Cloud Run サービスが Cloud SQL インスタンスへプライベートにアクセスするための基盤となる、VPC ネットワークを作成します。 この VPC ネットワークを通じて、Cloud Run と Cloud SQL 間の安全な通信経路を確立します。今回は、サブネットの IP アドレス範囲を自分で定義できるカスタムモードで作成します。 gcloud compute networks create $VPC_NETWORK_NAME \ --subnet-mode custom サブネットの作成 作成した VPC ネットワーク内にサブネットを作成します。 このサブネットは、Cloud Run サービスから VPC ネットワーク内への通信（Direct VPC Egress）における経由点となります。 gcloud compute networks subnets create $SUBNET_NAME \ --network = $VPC_NETWORK_NAME \ --range = 10 . 0 . 0 . 0 / 24 \ --region = $REGION プライベートサービスアクセスのための IP アドレス範囲の作成 Cloud SQL などの Google マネージドサービスを VPC ネットワークにプライベート接続するためには、それらのサービス専用の IP アドレス範囲を VPC ネットワーク内に予約する必要があります。 以下のコマンドで、VPC ネットワークに名前付きの IP アドレス範囲を作成します。この範囲は、Cloud SQL インスタンスが VPC ネットワーク内で使用する IP アドレスのプールとなります。 gcloud compute addresses create $PRIVATE_IP_RANGE_NAME \ --global \ --purpose = VPC_PEERING \ --prefix-length = 24 \ --network = $VPC_NETWORK_NAME プライベートサービスアクセスの構成 作成した IP アドレス範囲を使用して、VPC ネットワークと Google Cloud のサービスプロデューサーネットワークとの間にプライベートサービスアクセスの接続を確立します。 gcloud services vpc-peerings connect \ --service = servicenetworking.googleapis.com \ --network = $VPC_NETWORK_NAME \ --ranges = $PRIVATE_IP_RANGE_NAME 参考 : Google Cloud サービスへのプライベートサービスアクセス Cloud SQL インスタンスの作成 Cloud Run サービスから接続する Cloud SQL for PostgreSQL インスタンスを作成します。 インスタンスの作成 以下のコマンドで、PostgreSQL インスタンスを作成します。重要なポイントは以下の通りです。 パラメータ 説明 --network 先ほど作成し構成した VPC ネットワークを指定します。これにより、Cloud SQL インスタンスがこの VPC ネットワークに関連付けられます。 --no-assign-ip インスタンスに外部 IP アドレスが割り当てられないようにし、内部 IP アドレスのみを持つようにします。これにより、VPC ネットワーク外部からの直接的なアクセスを防ぎ、セキュリティを向上させます。 --database-flags=cloudsql.iam_authentication=on IAM データベース認証を有効にします。これにより、データベースユーザー名とパスワードの代わりに、IAM プリンシパルを使用して認証できます。 gcloud sql instances create $SQL_INSTANCE_NAME \ --database-version = POSTGRES_16 \ --region = $REGION \ --tier = db-custom-1-3840 \ --edition = ENTERPRISE \ --network = $VPC_NETWORK_NAME \ --no-assign-ip \ --database-flags = cloudsql. iam_authentication =on アプリケーションの準備 ディレクトリ構成 今回開発する Python アプリケーションのディレクトリ構成は以下のとおりです。 cloud-sql-sec-connect-demo-app |-- requirements.txt |-- Dockerfile |-- main.py アプリケーションソース Cloud SQL に接続して簡単な情報を取得する Python のウェブアプリケーションを作成します。 Cloud SQL への接続では、 Cloud SQL Python Connector を使用します。Cloud SQL Python Connector は、IAM データベース認証などの安全な接続を容易に実現するためのライブラリです。 requirements.txt Flask==3.1.1 gunicorn==23.0.0 Werkzeug==3.1.3 SQLAlchemy==2.0.41 cloud-sql-python-connector[pg8000]==1.18.2 Dockerfile FROM python:3.12-slim WORKDIR /usr/src/app COPY requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 7860 CMD [ " python ", " ./main.py " ] main.py import os from flask import Flask, jsonify from google.cloud.sql.connector import Connector, IPTypes import sqlalchemy from sqlalchemy import text app = Flask(__name__) INSTANCE_CONNECTION_NAME = os.environ[ "INSTANCE_CONNECTION_NAME" ] DB_USER = os.environ[ "DB_USER" ] DB_NAME = os.environ[ "DB_NAME" ] connector = Connector() engine = sqlalchemy.create_engine( "postgresql+pg8000://" , creator= lambda : connector.connect( INSTANCE_CONNECTION_NAME, "pg8000" , user=DB_USER, db=DB_NAME, enable_iam_auth= True , ip_type=IPTypes.PRIVATE, ), ) @ app.route ( "/" ) def index (): with engine.connect() as conn: version = conn.execute(text( "SELECT version()" )).scalar() current_db = conn.execute(text( "SELECT current_database()" )).scalar() current_user = conn.execute(text( "SELECT current_user" )).scalar() return jsonify({ "postgres_version" : version, "current_database" : current_db, "current_user" : current_user }) if __name__ == "__main__" : app.run(debug= True , host= "0.0.0.0" , port= int (os.environ.get( "PORT" , 7860 ))) Cloud Run へのデプロイ サービスアカウントの作成と権限付与 Cloud Run サービスが Cloud SQL インスタンスへ安全に接続し、IAM データベース認証を利用するためには、専用のサービスアカウントを作成し、必要な IAM ロールを付与します。サービスアカウントを使用することで、個人の認証情報ではなく、アプリケーション固有の認証情報で Google Cloud サービスを認証できます。 サービスアカウントの作成 gcloud iam service-accounts create $RUN_SA_NAME \ --display-name =" Cloud Run Service Account for SQL " サービスアカウントへの権限付与 # Cloud SQL インスタンスに接続するためのロール gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: $RUN_SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/cloudsql.client " # IAM データベース認証を使用して Cloud SQL インスタンスにログインするためのロール gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: $RUN_SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/cloudsql.instanceUser " # Cloud Run サービスが Cloud Logging にログを書き込むためのロール gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: $RUN_SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/logging.logWriter " Cloud SQL ユーザーとしてのサービスアカウント登録 前の手順でサービスアカウントに必要な IAM ロール（ roles/cloudsql.instanceUser など）を付与しましたが、それだけでは IAM データベース認証は完了しません。実際にデータベースにログインできるようにするには、このサービスアカウントを Cloud SQL インスタンスのユーザーとして登録する必要があります。 以下のコマンドを実行して、先ほど作成したサービスアカウントを Cloud SQL インスタンスに IAM 認証ユーザーとして追加します。 重要な点として、 --type=CLOUD_IAM_SERVICE_ACCOUNT を指定し、ユーザー名にはサービスアカウントのメールアドレスから末尾の .gserviceaccount.com を除いた部分を指定します。 gcloud sql users create $RUN_SA_NAME @ $PROJECT_ID .iam \ --instance = $SQL_INSTANCE_NAME \ --type = CLOUD_IAM_SERVICE_ACCOUNT Cloud Run にデプロイ Dockerfile が存在するディレクトリで、以下の gcloud コマンドを順次実行します。 gcloud run deploy $RUN_SERVICE_NAME --source . \ --region = $REGION \ --allow-unauthenticated \ --port 7860 \ --memory = 1Gi \ --min-instances = 0 \ --max-instances = 1 \ --service-account = $RUN_SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com \ --network = $VPC_NETWORK_NAME \ --subnet = $SUBNET_NAME \ --vpc-egress = private-ranges-only \ --set-env-vars = INSTANCE_CONNECTION_NAME = $PROJECT_ID : $REGION : $SQL_INSTANCE_NAME , DB_USER = $RUN_SA_NAME @ $PROJECT_ID .iam, DB_NAME = $DB_NAME 動作確認 Cloud Run サービスのデプロイが完了したら、実際にサービスにアクセスして、Cloud SQL インスタンスへ正しく接続できているかを確認します。 gcloud run deploy コマンドの実行が成功すると、コンソールに Service URL: としてデプロイされたサービスの URL が表示されます。この URL にウェブブラウザでアクセスするか、 curl コマンドでリクエストを送信してください。 # デプロイ時に表示された Service URL に置き換えてください curl https://my-app-service-XXXXX.asia-northeast1.run.app 正しく設定されていれば、以下のような JSON 形式のレスポンスが返ってきます。表示される内容は、ご自身の環境や PostgreSQL のバージョンによって若干異なる場合があります。 { " current_database ": " postgres ", " current_user ": " run-sa-for-sql@your-project-id.iam ", " postgres_version ": " PostgreSQL 16.9 on x86_64-pc-linux-gnu, compiled by Debian clang version 12.0.1, 64-bit " } 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進
アバター株式会社G-gen
Google Workspaceのライセンス自動割り当て設定と注意点
G-gen の岡田です。当記事では、Google Workspace ライセンスの自動割り当ての設定方法と注意点についてご紹介します。 はじめに Google Workspace ユーザーとライセンスの割り当て ライセンスの自動割り当てとは 手動でのライセンス割り当て ライセンスの自動割り当ての設定手順 自動割り当ての注意点 はじめに Google Workspace ユーザーとライセンスの割り当て Google Workspace でユーザー（アカウント）を作成した後、ライセンスを割り当てたり、割り当てを解除することができます。たとえば、あるユーザーには Google Workspace Enterprise Plus のみを割り当てて、別のユーザーにはそれに加えて Chrome Enterprise Premium のライセンスを割り当てる、などの設定が可能です。 当記事では、ライセンスの自動割り当ての設定方法と注意点を解説します。 参考 : ライセンスの割り当て、削除、再割り当て 管理画面でのライセンスの割り当て ライセンスの自動割り当てとは ライセンスの自動割り当て とは、現在ライセンスが割り当てられていないユーザーと、これから新規に作成されるユーザーに、ライセンスが自動的に割り当てられる機能です。自動割り当ては サブスクリプション （ライセンスの購入単位）ごとに設定できます。 この設定は、ユーザー作成のたびに手動でライセンスを付与する手間の削減や、割り当て漏れの防止に役立ちます。 なお、自動割り当ての設定について、オン・オフを変更できるのは、複数のサブスクリプションを契約している場合のみです。単一のサブスクリプションのみ（例として Google Workspace の特定エディションのみ等）の場合、自動割り当ては デフォルトでオン です。 手動でのライセンス割り当て まずは、手動でのライセンス割り当て作業の手順を説明します。「ライセンスの自動割り当て」が無効の場合、ユーザーを作成しただけではライセンスは自動的に付与されませんので、以下の手順でライセンスを付与する必要があります。 Google Workspace の管理コンソール（ https://admin.google.com ）にログイン [ディレクトリ] > [ユーザー] > [新しいユーザーの追加] へ移動 ユーザー情報を入力し、「新しいユーザーの追加」をクリックしてユーザーを作成 作成が完了したら、作成したユーザーをクリックし [ユーザーの詳細] > [ライセンス] からライセンスを割り当て 参考 : 管理コンソールにログインする 参考 : ユーザーの追加方法 ライセンスの自動割り当ての設定手順 以下の手順でライセンスの自動割り当てを設定すると、ライセンスが自動的に割り当てられるようになります。 Google Workspace の管理コンソール（ https://admin.google.com ）にログイン [お支払い] > [ライセンスの設定] へ移動 対象の組織部門を選択し、自動で割り当てたいライセンスを選択して [自動ライセンス] を「オン」に設定し、保存 自動割り当ての注意点 年間プランを契約している場合、購入済みのライセンス数が不足していると、追加のユーザーにはライセンスが付与されません。 ライセンスの自動割り当てが「オン」の場合、個々のユーザーのライセンス割り当てを個別に解除することはできません。 契約しているのが単一のサブスクリプションのみの場合、自動割り当てはデフォルトで「オン」に固定され、設定を変更することはできません。 あとからサブスクリプションを追加した場合、はじめに契約していたサブスクリプションは自動割り当てがデフォルトで「オン」になり、あとから契約したサブスクリプションは「オフ」になります。 岡田 海里 (記事一覧) クラウドソリューション部 クラウドサポート課 2021年4月にG-genに入社。
アバター株式会社G-gen
Cloud Run Worker Poolsを使ってみた
G-gen の佐々木です。当記事では、Cloud Run の新しい実行モデルである Cloud Run Worker Pools を、実際に使ってみます。 はじめに Cloud Run Worker Pools とは 想定ユースケース 当記事の構成 Pub/Sub の作成 Cloud Run Worker Pools の作成 使用するコード（Go） コンテナイメージの作成 Cloud Run Worker Pools のデプロイ コンソールから確認 動作確認 はじめに Cloud Run Worker Pools とは Cloud Run は Google Cloud のサーバーレス コンテナ コンピューティングサービスです。HTTP リクエストベースでコンテナを実行する Cloud Run services 、スケジュールやワークフローベースのバッチ実行に特化した Cloud Run jobs 、そして HTTP リクエストやイベントベースで関数を実行する Cloud Run functions （旧 : Cloud Functions）といった実行モデルがあります。 Cloud Run Worker Pools は、Google Cloud Next '25 で発表された Cloud Run の新たな実行モデルであり、外からのリクエストを受けて実行される従来の実行モデルとは異なり、タスクやメッセージを能動的に取得する Pull ベース の実行モデルとされています。 参考 : Deployment options and resource model - Cloud Run worker pools Cloud Run Worker Pools の実行モデル サービスの詳細については、以下の記事で解説しています。 blog.g-gen.co.jp また、Cloud Run の基本については、以下の記事をご一読ください。 blog.g-gen.co.jp 想定ユースケース Cloud Run で Pull ベースの実行モデルが利用可能になると、従来の実行モデルでは実装が難しかった以下のようなユースケースが Cloud Run で実現できます。 Pub/Sub の pull サブスクリプションからメッセージを取得して処理を実行する Kafka キューからタスクを取得して処理を実行する GitHub Actions の Runner をホスティングしてワークフローを実行する 従来、このようなユースケースでは GKE で Kubernetes クラスタ上にワーカーを展開するケースなどが一般的でしたが、Cloud Run Worker Pools の登場により、サーバーレスのメリットを享受しながらワーカーを展開することができます。 GKE 上のワーカーで Pub/Sub のメッセージを Pull するケースについては、以下の記事で紹介しています。 blog.g-gen.co.jp 当記事の構成 当記事では、Pub/Sub から Pull したメッセージの処理を行う Cloud Run Worker Pools を作成します。 当記事で解説する内容は、記事を執筆した2025年6月25日当時（Preview 版）のものです。Cloud Run Worker Pools は2026年4月に一般公開（GA）されました。 Pub/Sub の作成 gcloud CLI で Pub/Sub のトピックと pull サブスクリプションを作成します。 当記事ではトピック名を worker-pools-topic 、サブスクリプション名を worker-pools-sub とします。` # Pub/Sub トピックの作成 $ gcloud pubsub topics create worker-pools-topic # Pub/Sub サブスクリプションの作成 $ gcloud pubsub subscriptions create worker-pools-sub --topic = worker-pools-topic Cloud Run Worker Pools の作成 使用するコード（Go） Cloud Run Worker Pools にデプロイするコンテナイメージを用意します。 以下のコードでは、Pub/Sub の Streaming Pull API を使用してメッセージを Pull し、メッセージの内容をログ出力します。 package main import ( "context" "fmt" "io" "log" "os" "cloud.google.com/go/pubsub" // Pub/Sub クライアントライブラリ ) // メッセージを StreamingPull する関数 func pullMessages(w io.Writer , c context.Context, projectId, subId string ) error { // Pub/Sub Client client, err := pubsub.NewClient(c, projectId) if err != nil { return fmt.Errorf( "pubsub.NewClient: %v" , err) } defer client.Close() // サブスクリプションの参照 sub := client.Subscription(subId) // メッセージを Pull し続ける err = sub.Receive(c, func (_ context.Context, msg *pubsub.Message) { fmt.Fprintf(w, "%v \n " , string (msg.Data)) // メッセージを標準出力に出力 msg.Ack() }) if err != nil { return fmt.Errorf( "sub.Receive: %v" , err) } return nil } func main() { ctx := context.Background() // 環境変数からプロジェクト ID と PubSub トピック ID を取得 projectId := os.Getenv( "PROJECT_ID" ) subId := os.Getenv( "SUBSCRIPTION_ID" ) err := pullMessages(os.Stdout, ctx, projectId, subId) if err != nil { log.Fatal(err) } } 参考 : Pull subscriptions - StreamingPull API コンテナイメージの作成 当記事では Dockerfile を使用せず、Cloud Build で Buildpack を使用してコンテナイメージをビルドします。 # Cloud Build で Buildpack を使用してコンテナイメージをビルド $ gcloud builds submit --pack image = < Artifact Registory のパス > 参考 : Google Cloud's buildpacks Cloud Run Worker Pools のデプロイ ベータ版の API を使用して、Cloud Run Worker Pools をデプロイしていきます。 2025年6月26日現在では、 gcloud beta run worker-pools deploy を使用して Cloud Run Worker Pools をデプロイすることができます。 # Cloud Run Worker Pools のデプロイ $ gcloud beta run worker-pools deploy hello-worker-pools \ --region = asia-northeast1 \ --image =< Artifact Registory のパス > \ --set-env-vars = PROJECT_ID = < Pub/Subがあるプロジェクト ID > , SUBSCRIPTION_ID =worker-pools-sub \ --scaling = 3 当記事では、 hello-worker-pools という名前で Cloud Run Worker Pools を作成します。 --image には先ほど作成したコンテナイメージを指す Artifact Registory のパスを指定し、環境変数（ --set-env-vars ）としてプロジェクト ID と Pub/Sub のサブスクリプション ID（当記事では worker-pools-sub ）を設定します。 最後にスケーリングの設定（ --scaling ）ですが、現在 Cloud Run Worker Pools では手動スケーリングのみサポートされているため、起動するインスタンス数をここで決定します。 当記事では Pub/Sub のメッセージが複数のコンテナインスタンスで分散処理されるかを確認するため、コンテナインスタンス数を 3 に固定して進めていきます。 参考 : gcloud beta run worker-pools deploy コンソールから確認 2025年6月26日現在、Google Cloud コンソール上には Cloud Run Worker Pools の画面が存在していますが、サービスの作成や更新はできず、CLI でデプロイしたサービスの表示と削除のみが可能になっています。 他の実行モデル同様に、デプロイした内容が リビジョン 単位で管理されていることがわかります。 Cloud Run Worker Pools の詳細画面（コンソール） 動作確認 Pub/Sub にメッセージを送信し、Cloud Run Worker Pools がメッセージを処理できるかを確認してみます。 Pub/Sub トピックのコンソール画面から、100個の Hello, Worker Pools!! というメッセージをトピックにパブリッシュします。 トピックにメッセージをパブリッシュする パブリッシュ後、Cloud Run Worker Pools のログを確認してみると、Cloud Run 側からメッセージを能動的に取得（Pull）できていることがわかります。 Cloud Run Worker Pools のログ 今回はコンテナインスタンス数を3に設定しているため、各コンテナインスタンスでメッセージが分散処理されているかを確認してみます。 ログエクスプローラから、以下のクエリで Cloud Run Worker Pools のログを検索します。 resource.type = "cloud_run_worker_pool" resource.labels.worker_pool_name = "hello-worker-pools" resource.labels.location = "asia-northeast1" textPayload="Hello, Worker Pools!!" ログの label.instanceId フィールドにログを出力した（=メッセージを処理した）コンテナインスタンスの ID が記録されているため、以下のようにクエリに追加することで、各コンテナインスタンスで処理したメッセージ数を確認できます。 resource.type = "cloud_run_worker_pool" resource.labels.worker_pool_name = "hello-worker-pools" resource.labels.location = "asia-northeast1" textPayload="Hello, Worker Pools!!" labels.instanceId="<インスタンスIDの値>" 当記事では3つのコンテナインスタンスのそれぞれで、38件、34件、28件のメッセージが処理されていました。起動しているコンテナインスタンス間でメッセージがある程度分散されていることがわかります。 各コンテナインスタンスごとのメッセージの処理数を確認する 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805
アバター株式会社G-gen
GoogleカレンダーとGoogle ToDoリストを活用した業務効率化のすすめ
G-gen の横澤です。本記事では、Google Workspace の標準機能である Google カレンダーと Google ToDo リストの概要、および連携による業務効率向上のための設定方法や利用例を解説します。 Google カレンダー Google カレンダーとは 活用術 1 : 業務時間と勤務場所の設定 活用術 2 : 業務時間分析 Google ToDo リスト Google ToDo リストとは 活用術 1 : タスクの整理 活用術 2 : 定期的なタスクの登録 活用術 3：他サービスとの連携 活用術 4 : タスク管理の Tips Google カレンダーと Google ToDo リストの連携 Google カレンダー Google カレンダーとは Google カレンダー は、Google が提供する オンラインカレンダーサービス です。個人の予定管理に加え、チームメンバーとのスケジュール共有、会議の招待、Google Meet を使用したビデオ会議へのアクセスなど、多岐にわたる機能を備えています。 Google カレンダーには、以下の特徴があります。 クラウドベースでのアクセス 直感的なインターフェースによる容易な予定作成・編集 他のユーザーとのカレンダー共有による円滑な予定調整 予定前のリマインダー通知による意図しない予定の見逃し防止 Gmail、Google Meet など、他の Google サービスとのシームレスな連携 参考 : カレンダーでできること 活用術 1 : 業務時間と勤務場所の設定 Google カレンダーには、単に予定を登録するだけでなく、より効率的にスケジュールを管理するための機能があります。その一つが 「業務時間と勤務場所」 の設定です。 設定手順 Google カレンダーを開き、画面右上の設定アイコン（歯車マーク）から「設定」を選択します。 次に、左側のメニューから「全般」セクション内の「業務時間と勤務場所」をクリックし、「業務時間を有効にする」のチェックボックスをオンにして各曜日の勤務時間を設定します。必要に応じて、日ごとの勤務場所（例 : オフィス、自宅、出張先）も設定できます。 メリット 設定を実施することにより業務時間外に会議が提案された場合、予定を作成するユーザーにその旨が通知されるため、自身の勤務時間外や外出中での会議設定を効果的に回避できます。 次に、どのように働いているか 社員の勤務環境を可視化 することもできます。昨今、オフィス勤務だけでなく自宅でのリモートワークやサテライトオフィス、コワーキングスペースなどハイブリッドな形式で業務をすることも多いかもしれません。そのような環境でチームメンバーや関係者に対し、現在の働き方（例 : オフィス勤務、リモートワーク）を知らせることができます。 Web会議で参加するのか、もしくはオフィスでオフライン形式で会議に参加できるのかをカレンダー上に表記することで、会議や共同作業も簡単にスケジュールを調整できます。 参考 : Google カレンダーで業務時間と業務場所を設定する 活用術 2 : 業務時間分析 自身の業務で何にどれくらい時間がかかっているのかを把握したい場合、Google カレンダーの 「時間の分析情報」 機能が有効です。この機能により、時間の使い方を分析できます。 「時間の分析情報」では、主に、週単位や月単位で会議に費やした時間、頻繁に会議を行う相手や会議が多い曜日・時間帯といった会議の傾向、会議が予定されていない時間などを分析できます。 手順 Google カレンダーの左側パネルにある 「時間の分析情報」 をクリックし、表示されたダッシュボードで時間の内訳や会議の傾向などを確認します。 ラベルの活用 より詳細な分析には、カレンダーの予定に 「ラベル」 を付与することを推奨します。例えば、「プロジェクトA」「資料作成」「顧客対応」といったラベルを作成し、各予定に割り当てることで、それぞれの活動に費やした時間を具体的に把握できます。 参考 : 会議に割いた時間を確認する Google ToDo リスト Google ToDo リストとは Google ToDo リストは、シンプルで直感的な タスク管理ツール です。Gmail や Google カレンダーのサイドパネルからアクセスでき、タスクの作成、ステータス管理、期日設定が可能です。 また、Google カレンダー上の切り替えボタンを押すことで全画面で Todo リストを確認することができます。 特徴 シンプルで直感的な操作性 Gmail のメールからの直接的なタスク作成、Google カレンダーへのタスク期日表示など、Google サービスとの連携 タスクへの期日設定とリマインダー通知機能 活用術 1 : タスクの整理 手順 Google ToDo リストを開き、画面上部（または下部）に表示されている現在のリスト名（例 : マイタスク）をクリックした後、「新しいリストを作成」を選択し、リスト名を入力します。 活用例 リストは、例えば以下のように分類して利用できます。 プロジェクト別（例 : 「プロジェクトX」「新機能開発」「マーケティングキャンペーン」） 業務内容別（例 : 「資料作成」「会議準備」「雑務」） リストを分けることでタスクが整理され、優先すべき作業に集中しやすくなります。 参考 : リストを整理する 活用術 2 : 定期的なタスクの登録 毎週月曜日の定例報告や毎日の日報作成など、定期的に発生するタスクは「繰り返し設定」の使用が効果的です。 手順 タスクを作成または編集する際に日付（期日）を設定し、日付の下に表示される「繰り返し」（時計マークのアイコン）をクリックして、繰り返しの頻度（毎日、毎週、毎月、毎年など）、間隔、終了日などを設定します。 効果 登録作業の削減（一度の設定でタスクが自動的に作成されます） タスク実行漏れの防止（定期的な業務の確実な遂行を支援します） 習慣化の促進（日常的に行いたい学習や運動などの習慣も、繰り返しタスクとして登録することで継続しやすくなります） 参考 : タスクを追加または編集する 活用術 3：他サービスとの連携 Google ToDo リストは、他の Google サービスと連携することで利便性が向上します。 Gmail からのタスク追加 受信したメールを開き、上部にある「ToDo リストに追加」アイコン（チェックマークにプラスが付いたアイコン）をクリックすることで、そのメールに関連するタスクを容易に作成できます。メールへのリンクも自動的にタスクに紐づけられるため、後から詳細を確認する際に便利です。 参考 : タスクを追加または編集する カレンダーでのタスク表示 Google ToDo リストで期日を設定したタスクは、Google カレンダー上にも表示されます（カレンダーの左側パネルで「ToDo リスト」カレンダーのチェックボックスをオンにする）。これにより、予定とタスクを一元的に把握できます。 参考 : タスクを追加または編集する 活用術 4 : タスク管理の Tips Google ToDo リストでは、タスクの下にサブタスクを作成できます。この機能を用いて大きなタスクを作成した後、具体的な行動レベルまで分割しサブタスクとして登録します。 これにより、着手すべき点が明確になり、達成感も得やすくなります。 また、全てのタスクが同じ重要度とは限りません。Google ToDo リストの「スター」機能で重要なタスクに印を付けたり、リスト内でタスクをドラッグアンドドロップして並び替えたりすることで、優先度の高いタスクから着手できます。 さらに、具体的な期日を設定することで、タスクへの意識が高まり、計画的な進行ができます。Google ToDo リストでは、各タスクに期日と時刻を設定できます。 Google カレンダーと Google ToDo リストの連携 Google カレンダーは 「時間軸の管理」 、ToDo リストは 「タスクの実行管理」 を担います。この2つを組み合わせることで、以下のような相乗効果が期待できます。 タスクの視覚的リマインド Google ToDo リストで期日を設定したタスクは、Google カレンダーの終日予定のセクションや指定した日時に表示されます。これは視覚的なリマインダーとして機能し、日々の予定の中でいつそのタスクに取り組むべきかを把握しやすくします。 タスク実行時間の確保 重要なタスクや集中して取り組みたいタスクがある場合、そのための時間をGoogle カレンダーに予定として確保（例 : 「資料作成集中タイム」など）し Todo リストに対してもタスクとして登録することで、該当タスクへの集中を促し、より確実にタスクを遂行できます。 横澤 綜一 (記事一覧) 事業開発部カスタマーサクセス課 英文学科からITの世界へ。Google Workspace 専任サポートから Google Workspace のカスタマーサクセスへロールが代わり日々奮闘中。週5でジムに通う。
アバター株式会社G-gen
AppSheet CoreとEnterprise Plusの違い
G-gen の松本です。この記事では Google Workspace の AppSheet Core と AppSheet Enterprise Plus の違いについて解説します。 概要 AppSheet とは AppSheet のサブスクリプションプラン AppSheet Core Google Workspace に無料付帯 テンプレートから簡単にアプリ作成 Google Workspace アプリとの連携 管理コンソールでの制御 AppSheet Enterprise Plus 最上位プラン Google グループを利用したユーザーのアクセス制御 多様なデータソースとの連携 OCR 機能 チームへのリソース共有 組織全体のガバナンス強化 外部IDプロバイダ （IdP）との連携による高度な認証 詳細な監査ログと利用状況モニタリング Gemini との統合 概要 AppSheet とは AppSheet とは、Google が提供するノーコード開発プラットフォームです。プログラミングの知識不要で、業務アプリケーションを開発できます。その中でも AppSheet Core プランは、Google Workspace のサービスの一部として提供されています。 AppSheet を使うと、専門的なプログラミング知識がなくても、スプレッドシートなどの既存のデータソースを活用して、チェックリスト・在庫管理・日報・顧客管理などのカスタム業務アプリを簡単に作成できます。 AppSheet Core については、以下の記事も参照してください。 blog.g-gen.co.jp AppSheet のサブスクリプションプラン AppSheet には Free、Starter、Core、Enterprise Plus の計4つのサブスクリプションプランがあります。 AppSheet Free は、個人利用やプロトタイプ開発、テスト、個人間の共有など、特定の用途に限り無料でAppSheetの機能を利用できるプランです。 AppSheet Starter は、AppSheet 無料プランの上位プランであり、無料プランに比べてより多くのユーザーでの利用、基本的な自動化機能を備えています。主に個人事業主や小規模チームでの運用や、基本的な業務効率化アプリケーション開発に適したプランです。 AppSheet Core は、AppSheet Starter の上位プランであり、AppSheet Starter に比べてより高度なアプリ機能、自動化機能、セキュリティ機能を備えています。主に中小規模の組織での運用や、より実用的なビジネスアプリケーション開発に適したプランです。 AppSheet Enterprise Plus は、AppSheet Core の上位プランであり、AppSheet Core に比べてより高度な機能、管理機能、セキュリティ機能を備えています。大規模な組織での運用や、複雑なアプリケーション開発に適したプランです。また Gemini とも統合されており、強力な生成 AI 機能を備えたアプリを開発できます。アプリに生成 AI 機能（画像からの文字読み取りやテキストの分類など）を組み込みたい場合は、AppSheet Enterprise Plus を選びます。 参考 : サブスクリプションの選び方 参考 : AppSheet を無料で使用する（プロトタイプと個人用） AppSheet Core Google Workspace に無料付帯 AppSheet Core ライセンスは、主要な Google Workspace エディションでコアサービスとして登録されており、追加のサブスクリプションの登録不要で利用できます。 参考 : 組織で AppSheet を管理する AppSheet Core が利用可能な Google Workspace エディションは以下の通りです。 Business Starter Business Standard Business Plus Enterprise Starter Enterprise Standard Enterprise Plus Education Standard Education Plus Enterprise Essentials Plus Frontline Starter Frontline Standard Frontline Plus Google Workspace for Nonprofits テンプレートから簡単にアプリ作成 AppSheet では、プログラミングの知識が無くてもドラッグ＆ドロップ操作で直感的にアプリを開発できます。また、用途別に様々なテンプレートも用意されているので、それらを利用して開発することもできます。 AppSheet のテンプレート選択画面 Google Workspace アプリとの連携 AppSheet は、Gmail、Google Calendar、Google スプレッドシートなどの Google Workspace コアアプリをデータベースとして連携ができます。既存のデータを活用してアプリを構築できるため、手軽に業務の効率を高められます。 以下は、Googleの各種サービスと連携して実現できるアプリの例です。 Gmail との連携 例として、AppSheet の顧客管理アプリで設定したアクション（例：商談成立、見積もり提出後）に応じて、顧客へのお礼メールやフォローアップメールを Gmail で自動送信できます。 顧客との関係性を強化しつつ、人的ミスによるフォロー漏れを防ぎ、顧客満足度の向上に貢献します。 Google スプレッドシートとの連携 タスク名、担当者、期日、進捗状況などを Google スプレッドシートで管理し、AppSheet で担当者ごとのタスク表示、進捗更新、期日管理などの機能を持つアプリが作成できます。 各メンバーのタスク状況やプロジェクト全体の進捗を一目で把握でき、タスクの遅延防止に繋がります。 Google カレンダーとの連携 会議、セミナー、ワークショップなどのイベント情報を AppSheet で作成・管理し、その予定を Google カレンダーに自動的に登録・同期。参加者への招待、出欠確認なども AppSheet 上で完結できます。 イベントに関する情報を AppSheet で集約し、Google カレンダーでスケジュールとして可視化することで、情報管理の効率化に貢献します。 管理コンソールでの制御 管理者は、以下の操作を有効化または無効化できます。 外部のアプリユーザーとの間での AppSheet のアプリとデータベースの共有 外部アプリデータへの接続 外部の宛先に送られる自動化メール アプリの API を使用した外部統合 Webhook 機能 参考 : AppSheet へのアクセスを管理する AppSheet Enterprise Plus 最上位プラン AppSheet Enterprise Plus は、AppSheet Core の最上位プランです。より高度な機能、管理機能、セキュリティ機能を備えており、大規模な組織での運用や、複雑なアプリケーション開発ができます。 また、Enterprise Plus には Gemini for App Creation 、 Gemini for AppSheet Solutions といった AI 機能も備わっており、生成 AI 補助のもとアプリを開発したり、AI 機能を使ったアプリを開発することができます。 その他にもバージョン管理、Active Directory や OpenID Connect との認証連携、チーム機能など、エンタープライズグレードの AppSheet 利用のための機能が充実しています。 参考 : サブスクリプションの選び方 Google グループを利用したユーザーのアクセス制御 AppSheet ではデフォルトですべてのユーザーでアプリの作成ができますが、Google グループを使用することでアプリの作成を行うユーザーを限定できます。 Google グループで「アプリ作成を許可する」メンバーが所属するグループを作成し、AppSheet に統合することで Google Workspace 内でアプリの開発者/利用者を分けて運用できます。 参考 : Google グループを使用してユーザーのアクセスをコントロールする 多様なデータソースとの連携 複数のクラウドベースのデータソースや大規模なデータベースと接続することで、大量のデータを活用したアプリを開発できます。 AppSheet で Google スプレッドシートをデータソースとして使用する場合、サポートされる行数は最大100,000行です。しかし、AppSheet Enterprise Plus ライセンスでは以下の大規模データソースと接続できるため、より大規模なデータセットを利用できます。 Apigee AppSheet API AWS DynamoDB BigQuery MariaDB MySQL OData オンプレミス データベース Oracle PostgreSQL Salesforce SQL Server 参考 : サブスクリプションの選び方 OCR 機能 光学文字認識 （OCR） 機能を利用し、画像データや手書き文字から文字情報を読み取り、テキストデータとして抽出できます。例えば、複数の名刺や請求書をカメラで撮影し、抽出したデータをフォームに入力することなどができます。 AppSheet の OCR 機能を使用すると画像からフォームに自動的に入力できるため、データ入力にかかる時間を短縮できます。 参考 : 光学式文字認識（OCR） チームへのリソース共有 AppSheet Enterprise Plus では、組織で作成したサンプルアプリの共有ができます。チーム内で共有することで開発時間の短縮や、作成するアプリの品質向上に繋がります。 また、AppSheet Enterprise Plus では MySQL などのクラウドデータベースや、Google スプレッドシートなどへの接続設定を共有できます。チーム全体が同じデータソースを利用することで、データソースの設定時間を削減でき、接続情報を管理できるためセキュリティの向上に繋がります。 参考 : リソースをチームと共有する 組織全体のガバナンス強化 AppSheet Enterprise Plus では、組織全体の AppSheet 利用に関する詳細なルール （ガバナンスポリシー）を管理者が一元的に設定できます。AppSheet Core でも一部の制御は可能ですが、Enterprise Plus ではより細かな設定が可能です。 例として、組織として許可したデータソース （特定のデータベースやクラウドストレージのフォルダなど）以外への接続を禁止し、接続可能なデータソースを制限できます。 これにより、情報漏洩リスクが低減できます。 参考 : ガバナンス ポリシーを定義する 外部IDプロバイダ （IdP）との連携による高度な認証 AppSheet Enterprise Plus では、Okta や Azure AD （Active Directory） など、企業で既に利用している外部のIDプロバイダ（IdP）と連携したシングルサインオン（SSO）環境を構築できます。 AppSheet Core でも Google Workspace アカウントでの認証が基本ですが、Enterprise Plus を利用することで、従業員は普段利用しているIDとパスワードで AppSheet アプリにアクセスでき、 IdP側で設定されている多要素認証を AppSheet 利用時にも適用できます。 これらにより、ユーザーの利便性を損なうことなく、企業全体の認証ポリシーに準拠した強固なアクセス管理が可能です。 参考 : Active Directory を使用してユーザー アクセスを制御する 参考 : Okta を使用してユーザーのアクセスを制御する 参考 : OpenID Connect を使用してユーザーのアクセスを制御する 詳細な監査ログと利用状況モニタリング AppSheet Enterprise Plus では、アプリの利用状況やデータ変更に関する詳細な監査ログを取得し、管理者が確認・分析できます。これにより、いつ、誰が、どのような操作を行ったかを追跡し、セキュリティインシデント発生時の原因究明や不正アクセスの検知に役立ちます。 具体的には、以下のような情報が記録されます。 アプリの起動、同期、データ変更（追加・更新・削除）の履歴 自動化の実行履歴 エラーの発生状況 これらの監査ログは、Google Cloud の BigQuery にエクスポートしてより長期間の保管や高度な分析を行うこともできます。AppSheet Core でも基本的なエラーログなどは確認できますが、Enterprise Plus ではより詳細な確認が可能です。 参考 : Audit History を使用してアプリのアクティビティをモニタリングする 参考 : チーム監査ログを BigQuery にエクスポートする Gemini との統合 AppSheet の Enterprise Plus エディションは、Google の生成 AI モデルである Gemini と統合 されています。 Gemini for App Creation は、AI 補助のもとアプリを開発できる機能です。自然言語でアプリのアイデアやビジネスプロセスの説明をするだけで、推奨されるテーブルと列を提案するなど、アプリ開発を AI が補助します。 Gemini for AppSheet Solutions は、アプリの中で AI を利用できる機能です。Gemini for AppSheet Solutions を使うと、画像から情報を抽出したり、PDF ドキュメントを処理したり、情報を分類したりできます。つまり、生成 AI の協力な機能を備えたアプリをノーコードで開発できます。 なお、前者の Gemini for App Creation は、Enterprise Plus エディションだけでなく、AppSheet Core とその他の有料ライセンスで使用可能です。 一方で後者の Gemini for AppSheet Solutions を使うには、AppSheet の Enterprise Plus エディションが必要です。画像からの文字読み取りや、テキストを分類させたりするなどの生成 AI 機能をアプリに組み込みたい場合は、AppSheet Enterprise Plus エディションのライセンスを購入してください。 参考 : Gemini in AppSheet を使用する 参考 : サブスクリプションの選び方 松本 迅人 (記事一覧) クラウドソリューション部 クラウドサポート課 栃木県出身。6年間製造関係の会社に在籍し、その後IT業界にシフト。 現在は Google Workspace を中心にカスタマーサポートに従事。 趣味はキャンプ、カメラ、エレキベース、バイク
アバター株式会社G-gen
Cloud Loggingのクエリ言語の構文を徹底解説
G-gen の杉村です。Google Cloud のログ収集、保管、閲覧サービスである Cloud Logging のクエリ言語を徹底解説します。 クエリ言語 Logging クエリ言語とは クエリ言語のその他の用途 基本的な使い方 クエリの仕方 例文 ログエクスプローラでの生成 ブール演算子 AND、OR 括弧 NOT 比較演算子 =、!=（equal、not equal） :（has） フィールドの存在確認 正規表現 =~、!~（正規表現） 正規表現の記述 検索のスピード 文字列の検索 グローバル制限（単純な検索） SEARCH 関数 時間の指定 ログエクスプローラでの指定 クエリ言語での指定 コメント 高速な検索 インデックスの利用 時間帯を絞る 部分一致よりもイコール クエリ言語 Logging クエリ言語とは Google Cloud のログ収集、保管、閲覧サービスである Cloud Logging は、Google Cloud コンソールの ログエクスプローラ 画面で、 Logging クエリ言語 （Logging query language）という独自のクエリ言語を使ってログを自在にフィルタし、閲覧することができます。Logging クエリ言語は、ログエクスプローラのほか、gcloud コマンドや Cloud Logging API へのリクエストにも使うことができます。 Logging クエリ言語の構文（文法）は以下のドキュメントに記載されています。当記事では、重要な構文の書き方を解説します。 参考 : Logging のクエリ言語 クエリ言語のその他の用途 Cloud Logging では ログルーター （シンク）を用いて、ログを任意のログバケットや BigQuery に転送、保管できます。ログルーターには、転送対象のログを指定するための含有フィルタや除外フィルタを記述します。 このフィルタの記述にも、Logging のクエリ言語が使われます。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - ログルーティングとログの保存 また、Cloud Logging のログに基づいてメールなどを発報するためのログベースのアラートやログベースの指標などにおいても、対象のログを指定するために Logging クエリ言語が使われます。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - ログ監視 このように、Logging クエリ言語は Cloud Logging に関わる多くの場面で使われます。 基本的な使い方 クエリの仕方 Logging クエリ言語は、Google Cloud コンソールの「ロギング」 > 「ログ エクスプローラ」の画面で使用します。 もしクエリを書き込む検索ボックスが表示されていない場合は、「クエリを表示（①）」を押下します。検索ボックス（②）にクエリを記載し、「クエリを実行（③）」を押下することで、検索が実行されます。 クエリ言語の使い方 例文 Logging クエリ言語を使ったクエリの例文を、いくつか紹介します。 Google Kubernetes Engine（GKE）クラスタのログで、重要度が ERROR のログ resource . type = " k8s_cluster " AND severity= " ERROR " インスタンススケジュールによる Compute Engine VM の起動・停止ログ ( protoPayload.methodName= " v1.compute.instances.stop " OR protoPayload.methodName= " v1.compute.instances.start " ) AND protoPayload.authenticationInfo.principalEmail= " service-1234567890@compute-system.iam.gserviceaccount.com " アカウント john.doe@g-gen.co.jp によって実行された BigQuery テーブル my_table へのクエリのログ protoPayload.authenticationInfo.principalEmail= " john.doe@g-gen.co.jp " AND protoPayload.methodName= " jobservice.insert " AND protoPayload.serviceData.jobInsertResponse. resource .jobStatistics.referencedTables.tableId= " my_table " ログエクスプローラでの生成 Logging クエリ言語には、当記事で紹介するような多数の構文がありますが、ほとんど覚える必要がないともいえます。 ログエクスプローラで、検索したいログと類似のログを見つけたあと、対象のフィールドの値（①）をクリックして表示されたプルダウンメニューから「一致エントリを表示」または「一致エントリを非表示」を選択（②）すると、その値を検索するようなクエリが検索ボックス（③）に追加されます。 クエリ言語はコンソールで生成できる このようにして追加されたクエリ言語を、部分的に修正して、目当てのログを探すためのクエリを作成することができます。 Logging クエリ言語の文法を詳細に覚えなくても、基本的な文法と概要を理解していれば、類似のログから検索クエリを生成して、目当てのログへたどり着くことができます。 ブール演算子 AND、OR AND と OR は、Logging クエリ言語を使う上で最も重要な演算子です。 AND と OR は、必ず 大文字 で書く必要があります。小文字で書くと、検索キーワードとして解釈され、後述のグローバル制限（グローバル検索）が行われてしまいます。 protoPayload.methodName= " v1.compute.instances.stop " OR protoPayload.methodName= " v1.compute.instances.start " 上記のクエリでは、メソッド名が "v1.compute.instances.stop" または "v1.compute.instances.start" であるログを抽出しています。上記のようなクエリで、 AND を使うことはありえません。メソッド名が "v1.compute.instances.stop" であり、 かつ "v1.compute.instances.start" であるログはありえないからです。 OR を使うことで、"v1.compute.instances.stop" または "v1.compute.instances.start" に当てはまるログがすべて抽出されます。 なお、 AND は省略することができます。2つの以上のステートメント（個々のクエリの記述のこと）を記載したとき、結合方法は AND になります。以下の2つのクエリは、同じ意味を持ちます。 protoPayload.methodName= " v1.compute.instances.stop " AND resource .labels.instance_id= " 1234567890123456789 " protoPayload.methodName= " v1.compute.instances.stop " resource .labels.instance_id= " 1234567890123456789 " 括弧 OR や AND は括弧でくくることができます。以下のクエリでは、メソッド名が "v1.compute.instances.stop" であり、かつインスタンス ID が "1234567890123456789" または "0987654321098765432" であるログが抽出されます。 protoPayload.methodName= " v1.compute.instances.stop " AND ( resource .labels.instance_id= " 1234567890123456789 " OR resource .labels.instance_id= " 0987654321098765432 " ) NOT NOT は、 AND と OR の意味を反転します。以下のクエリでは、メソッド名が "v1.compute.instances.stop" であり、かつインスタンス ID が "1234567890123456789" ではない ログが抽出されます。 NOT も、必ず大文字で書く必要があります。 protoPayload.methodName= " v1.compute.instances.stop " AND NOT resource .labels.instance_id= " 1234567890123456789 " また、 NOT の代わりに - （マイナス記号）を使うこともできます。以下のクエリは、上記のクエリと同じ意味です。 protoPayload.methodName= " v1.compute.instances.stop " - resource .labels.instance_id= " 1234567890123456789 " 比較演算子 =、!=（equal、not equal） = や != はその見た目のとおり、一致していること、または一致していないことを指します。 以下の2つのクエリは同じ意味を持ちます。 protoPayload.methodName= " v1.compute.instances.stop " AND NOT resource .labels.instance_id= " 1234567890123456789 " protoPayload.methodName= " v1.compute.instances.stop " AND resource .labels.instance_id!= " 1234567890123456789 " = や != の前後には、スペースを入れても入れなくても構いません。 protoPayload.methodName = " v1.compute.instances.stop " AND resource .labels.instance_id != " 1234567890123456789 " :（has） : は has と呼ばれ、指定した文字列を含むログを抽出します。 以下のログでは、 protoPayload.authenticationInfo.principalEmail に "@g-gen.co.jp" という文字列が含まれているログを抽出します。 protoPayload.authenticationInfo.principalEmail : " @g-gen.co.jp " AND protoPayload.methodName= " jobservice.insert " また、 : では括弧を使って複数の条件を指定することができます。 protoPayload.authenticationInfo.principalEmail : ( " @g-gen.co.jp " OR " @example.co.jp " ) AND protoPayload.methodName= " jobservice.insert " また、 : を使ったクエリでは、大文字と小文字は区別されません。以下のクエリは、1つ前のクエリと同じ結果を返します。 protoPayload.authenticationInfo.principalEmail : ( " @G-GEN.CO.JP " OR " @EXAMPLE.CO.JP " ) AND protoPayload.methodName= " jobservice.insert " フィールドの存在確認 :* を使うと、値を問わず、そのフィールドが存在しているログエントリを抽出できます。 protoPayload.serviceName= " iap.googleapis.com " protoPayload.authenticationInfo.principalEmail:* 正規表現 =~、!~（正規表現） =~ は、正規表現を使うための比較演算子です。Logging クエリ言語では、 RE2 と呼ばれる Google が定義する正規表現構文を使います。 以下のクエリでは、メソッド名が "v1.compute.instances." で始まるログを抽出します。 protoPayload.methodName=~ " ^v1\.compute\.instances\..+ " ^ は文字列の先頭を意味します。 . はそのままだと任意の文字列を意味するメタ文字なので、 \ でエスケープします。末尾の .+ は、任意の文字列が1文字以上繰り返されることを意味します。 !~ は、 =~ とは逆に、正規表現に一致しないログを抽出します。 resource .labels.instance_id = " 1234567890123456789 " AND protoPayload.methodName !~ " v1.compute.instances.get " なお、正規表現では大文字と小文字は区別されます。以下の2つのクエリでは、結果が異なります。 protoPayload.methodName=~ " ^v1\.compute\.instances\..+ " protoPayload.methodName=~ " ^V1\.COMPUTE\.INSTANCES\..+ " 正規表現の記述 正規表現はプログラマーにとっては使い慣れたツールですが、正規表現の文法に慣れていない人もいるでしょう。日本語で指示して Gemini アプリ（ https://gemini.google.com ）などの生成 AI に正規表現を記述させるのも有用です。 ただし、無償版 Google アカウントで利用する Gemini アプリに投入したプロンプトなどは、Google によってモデルの再トレーニングに利用される場合があることに注意してください。Google Workspace アカウントでログインした状態で Gemini アプリを使っている場合、データは保護されます（エンタープライズグレードのデータ保護）。 参考 : Gemini for Google Workspace に関するよくある質問 - Gemini for Google Workspace ではどのようにデータが保護されますか？ 検索のスピード 以下の2つのクエリの意味はほとんど同じですが、 : を使ったクエリよりも、 =~ を使った正規表現によるクエリのほうが 高速 です。 protoPayload.authenticationInfo.principalEmail : " @g-gen.co.jp " protoPayload.authenticationInfo.principalEmail =~ " .+@g-gen\.co\.jp " 文字列の検索 グローバル制限（単純な検索） 以下のように単純に文字列をダブルクォーテーションで囲って検索ボックスに入力し、クエリすることで、その文字列を含むログを抽出できます。 " password authentication failed " このような文字列による単純な検索を、グローバル制限（global restriction）またはグローバル検索といいます。グローバル制限は、以下のように AND や OR を使うことができます。 ( " password authentication failed " AND ( " postgres " OR " mysql " ) ) グローバル制限による検索では、暗黙的に : （has）が使われています。グローバル制限による検索では、ログエントリのすべてのフィールドを : で検索するため、結果が返ってくるのが遅くなる可能性があります。 SEARCH 関数 前述のグローバル制限による単純な文字列検索では、結果が返ってくるまで時間がかかる場合があります。Logging クエリ言語の組み込み関数である SEARCH() 関数を使うと、検索対象のフィールドを指定できます。 SEARCH(textPayload, " password authentication failed " ) SEARCH() 関数は、フィールドを指定しないで検索に使うこともできます。このとき、前述の単純な検索との違いは、検索時に文字列が「トークン化」されることです。 例えば、大文字と小文字が区別されなかったり、スペースで空けた複数の文字列は順序が区別されません。以下の2つのクエリは同じ結果を返します。 SEARCH( " hello world " ) SEARCH( " World hello " ) 大文字と小文字や、文字列の順序を区別させたい場合は、文字列をバッククォートで囲みます。以下の2つのクエリは、返ってくる結果が異なります。 SEARCH( " `hello world` " ) SEARCH( " `world hello` " ) SEARCH() 関数では、部分的なテキストは区別されてしまいます。以下のクエリでは、world という単語が途中で切れているので、 hello world という文字列は抽出されません。 SEARCH( " `hello wor` " ) なお、以下の1つ目のクエリのように文字列をダブルクォーテーションで囲わずに検索ボックスに入力してそのまま検索すると、 SEARCH() 関数を使った検索になります。以下の2つのクエリは同じ意味です。 password authentication failed SEARCH( " password authentication failed " ) 時間の指定 ログエクスプローラでの指定 ログエクスプローラでは、ログの検索対象とする時間を指定できます。 できるだけ検索対象の時間帯を絞ることで、クエリの結果が返ってくるまでのスピードを向上させることができます。 ログエクスプローラで時間帯を指定 クエリ言語での指定 クエリ内で時間帯を指定することもできます。Cloud Logging のログエントリには以下のように timestamp フィールドが必ず含まれていますので、このフィールドを使ってログを絞り込みます。 timestamp >= " 2025-02-24T09:40:00+09:00 " AND timestamp <= " 2025-02-24T09:50:00+09:00 " タイムスタンプの末尾を +09:00 とすれば日本のタイムゾーンになります。末尾を Z とすれば UTC です。 コメント -- で始まる行はコメントであり、無視されます。 -- このクエリは、Compute Engine VM に対するすべてのメソッドの実行を抽出します protoPayload.methodName=~ " ^v1\.compute\.instances\..+ " 高速な検索 インデックスの利用 Cloud Logging のログエントリには、 インデックス が存在します。インデックスは、物理的な書籍でいう索引や、ページに貼られた付箋のようなものと理解することができます。フィールドにインデックスが作成されることによって、そのフィールドに対する検索が高速化します。 参考 : ログエントリの迅速な検索 参考 : カスタム インデックスを構成する ログバケットに対して、ユーザーが任意のフィールドにカスタムインデックスを指定することもできるほか、すべてのログバケットで、 デフォルトで 以下のフィールドにインデックスが作成されています。 resource.type resource.labels.* logName severity timestamp insertId operation.id trace httpRequest.status labels.* split.uid これらのフィールドに対して検索をかけると、高速な検索が可能です。 例えば、検索したいログの対象となっているインスタンス ID が分かっている場合は、ID を指定することで検索が高速になります。 resource.labels.* にはデフォルトのインデックスが作成されているからです。 protoPayload.methodName= " v1.compute.instances.stop " AND resource .labels.instance_id= " 1234567890123456789 " また、 logName フィールドは、ログエントリに必ず含まれており、デフォルトのインデックスが作成されていますので、検索対象のログを絞る際に有用です。 protoPayload.serviceName= " cloudsql.googleapis.com " AND logName= " projects/sugimura/logs/cloudaudit.googleapis.com%2Factivity " logName フィールドの値の例は、以下のとおりです。 ログの種類 値 説明 Cloud Audit Logs 管理アクティビティ監査ログ projects/(PROJECT_ID)/logs/cloudaudit.googleapis.com%2Factivity リソースに対する更新系操作 Cloud Audit Logs データアクセス監査ログ projects/(PROJECT_ID)/logs/cloudaudit.googleapis.com%2Fdata_access データに対する更新系・読取系操作 Cloud Audit Logs ポリシー拒否監査ログ projects/(PROJECT_ID)/logs/cloudaudit.googleapis.com%2Fpolicy VPC Service Controls のアクセス拒否 Cloud SQL for PostgreSQL データベースログ (postgres.log) projects/(PROJECT_ID)/logs/cloudsql.googleapis.com%2Fpostgres.log Cloud SQL for PostgreSQL のログ Cloud Run 標準出力 (postgres.log) projects/(PROJECT_ID)/logs/run.googleapis.com%2Fstdout Cloud Run や Cloud Run functions の標準出力 時間帯を絞る ログ検索対象の時間帯を可能な限り絞ることで、検索時間を速くすることができます。 ログエクスプローラ画面の UI を使って時間帯を絞ってもいいですし、クエリ文の中で timestamp フィールドを使って時間帯を絞っても構いません。 部分一致よりもイコール 検索対象の文字列が分かっている場合は、グローバル制限（グローバル検索）よりも : （has）のほうが、またそれよりも =~ （正規表現）の方が高速です。しかし、最も高速なのは = （イコール）です。 -- グローバル検索だとすべてのフィールドが検索対象になる " password authentication failed " -- こちらのほうが高速 textPayload : " password authentication failed for user \ " postgres\ "" -- さらに高速 textPayload =~ " .* password authentication failed for user \ " postgres\ " .* " -- 最も高速 textPayload= " 2025-02-24 00:27:33.651 UTC [12345]: [1-1] db=postgres,user=postgres FATAL: password authentication failed for user \ " postgres\ "" また、フィールドを指定した検索では SEARCH() 関数も有用です。正規表現を用いなくても、検索文字列がトークン化されて効率的な検索が可能です。ただし、単語が途中で切れていたりすると、望む結果が得られないことに注意してください（前述の「SEARCH 関数」の見出しを参照）。 SEARCH(textPayload, " password authentication failed " ) 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it
アバター株式会社G-gen
Vertex AI経由でClaudeモデルを使ってみた
G-gen のバロキです。この記事では Vertex AI を使って、Anthropic 社の Claude モデル を呼び出す方法と、セットアップから最初の推論（inference）までのステップについて解説します。 はじめに Claude とは Vertex AI 上で Claude を使うメリット 利用可能な Claude モデル一覧 事前準備 Notebook インスタンスの作成 Claude のストリーミング応答を利用する curl での呼び出し例 次のステップ はじめに Claude とは Claude は、Anthropic 社によって開発された大規模言語モデル（LLM）のファミリーです。Constitutional AI という設計原則に基づき、「有用で・無害で・正直である」ことを目指して作られました。 Claude 3 系列の中でも最新の Claude 3.7 Sonnet は、ハイブリッド・リースニング（Hybrid Reasoning）を備えており、即時的な応答と段階的な深い思考のバランスを取ることが可能です。 Claude は以下のようなタスクに活用できます。 テキストの要約 コード生成やデバッグ マルチモーダルな画像処理 チャットボットやリアルタイム会話 深い分析や推論の自動化 Vertex AI 上で Claude を使うメリット Google Cloud の Vertex AI は、Claude モデルをネイティブに提供しています。Claude を Vertex AI から呼び出すことには、以下のようなメリットがあります。 サーバーレス であること。インフラの管理が不要です。 API 経由の簡単な呼び出し が可能であること。API へリクエストを送るだけで利用できます。 ストリーミング対応 していること。応答をリアルタイムに表示できます。 従量課金またはスループット指定 が可能であること。用途に応じた柔軟な価格設定が可能です。 このように、Vertex AI を使うと、研究者や開発者が簡単に Claude を使い始められます。 利用可能な Claude モデル一覧 以下は、2025年5月現在、Vertex AI から呼び出し可能な Claude モデルの一覧です。 モデル名                 モデル ID                          特徴                     Claude 3.7 Sonnet    claude-3-7-sonnet@20250219     高度な推論、エージェント的タスクに最適です。     Claude 3.5 Sonnet v2 claude-3-5-sonnet-v2@20241022 複雑なドキュメント理解やコーディングに適しています。     Claude 3.5 Haiku     claude-3-5-haiku@20241022     最速の応答性能を持ち、チャット用途に向いています。       Claude 3 Opus        claude-3-opus@20240229         高度な研究用途や複雑なタスクに適しています。         Claude 3 Haiku       claude-3-haiku@20240307       画像を含むマルチモーダル処理に対応しています。         Claude 3.5 Sonnet    claude-3-5-sonnet@20240620     高性能なコーディング支援とカスタマーサポートに役立ちます。 参考 : Use Anthropic's Claude models 事前準備 Claude を Vertex AI から使うためには、以下の準備が必要です。 課金が有効な Google Cloud プロジェクト aiplatform.googleapis.com API の有効化 パートナーモデル（Claude）の使用権限 Python、Jupyter Notebook の基本的な知識 以下のコマンドで SDK をインストール pip install --upgrade anthropic google-cloud-aiplatform Notebook インスタンスの作成 Vertex AI Workbench にアクセスし、「インスタンスを作成」をクリックします。 「Python 3（最新） + JupyterLab」を選択します。 インスタンスタイプ（例 : e2-standard-4）を選びます。 Notebook 上で以下のコードを実行します。 from anthropic import AnthropicVertex client = AnthropicVertex(project_id= "your-project-id" , region= "us-east5" ) message = client.messages.create( model= "claude-3-7-sonnet@20250219" , max_tokens= 1024 , messages=[ { "role" : "user" , "content" : "Explain the concept of extended thinking." } ], ) print (message.model_dump_json(indent= 2 )) Claude のストリーミング応答を利用する ストリーミング応答を利用することで、より自然で即時的な体験が可能です。 with client.messages.stream( model= "claude-3-7-sonnet@20250219" , max_tokens= 1024 , messages=[ { "role" : "user" , "content" : "Tell me a story about a dragon and a forest." } ], ) as stream: for text in stream.text_stream: print (text, end= "" , flush= True ) curl での呼び出し例 gcloud コマンドで取得したアクセストークンを使い、curl で直接呼び出すことも可能です。 curl -X POST \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " Content-Type: application/json " \ https://us-east5-aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/us-east5/publishers/anthropic/models/claude-3-7-sonnet@20250219:streamGenerateContent \ -d ' { "instances": [{"messages": [{"role": "user", "content": "Vertex AI を使って何ができますか？"}]}], "parameters": {"maxTokens": 512, "stream": true} } ' 次のステップ Claude は Vertex AI を通じて、インフラ管理の必要がなく、安全かつスケーラブルに利用できます。 さらなる詳細は、以下のドキュメントを参考にしてください。 参考 : Claude on Vertex AI（公式ドキュメント） 参考 : Anthropic API ドキュメント 参考 : Claude 3.7 Sonnet 紹介ページ ハサナル・バロキ (記事一覧) クラウドソリューション部 クラウドサポート課。インドネシア北スマトラ州ビンジャイ市出身。 YKK株式会社での金型設計を経て IT 業界へ転身。AI／システムエンジニアとしての経験を積み、現在は G-gen にてクラウドサポートに従事。 趣味は水泳と RAG チャットボット開発（OpenAI・Gemini・Vector Search 等）。好きな食べ物はラーメンと寿司。
アバター株式会社G-gen
BigQueryからCloud StorageのCSVを読み込む際に日付列がUnable to parse
G-gen の杉村です。BigQuery では、Cloud Storage 上の CSV 形式や JSON 形式のファイルをテーブルに読み込ん（ロード）だり、外部テーブル定義によって直接クエリすることができます。日付を含むファイルをロードしたりクエリしようとした際に発生したエラーについて、対処法を解説します。 前提 事象 1. LOAD の際のエラー 2. 外部テーブルへのクエリの際のエラー 原因 対処法 1. date_format オプションを指定する 2. STRING 型として取り込む 3. スキーマの自動検知を利用する 4. 取り込む前にファイルを前処理する 前提 Cloud Storage バケットに以下の CSV を配置し、BigQuery から LOAD ステートメントを実行して、テーブルに取り込もうとしました。 2025/06/07,2025/06/07 08:30:00,2025/06/07 17:30:00,helloWorld1 2025/06/08,2025/06/08 09:00:00,2025/06/08 17:30:00,helloWorld2 2025/06/09,2025/06/09 10:00:30,2025/06/09 19:00:30,helloWorld3 なおテーブルのスキーマは CSV のフィールドどおりの順番で、以下を想定しています。 列名 型 col_date DATE col_datatime DATETIME col_timestamp TIMESTAMP col_string STRING また別の用途のため、上記のテーブルとは別に、同じファイルに対して外部テーブル定義をして、直接ファイルをクエリできるようにしたいと考えています。 事象 1. LOAD の際のエラー Cloud Storage バケット上の CSV ファイルを BigQuery テーブルに取り込むため、以下の LOAD 文を実行しました。 LOAD DATA INTO `my-project.my_dataset.sample_table` ( col_date DATE , col_datetime DATETIME , col_timestamp TIMESTAMP , col_string STRING ) FROM FILES ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); すると、以下のエラーが発生しました。 Error while reading data, error message: Unable to parse; line_number: 1 byte_offset_to_start_of_line: 0 column_index: 0 column_name: "col_date" column_type: DATE value: "2025/06/07" File: gs://my-bucket/datetime_test/test_dateformat.csv Error while reading data, error message: Unable to parse; 2. 外部テーブルへのクエリの際のエラー 次に、CREATE EXTERNAL TABLE 文で同じファイルに対して外部テーブル定義を試みました。 CREATE OR REPLACE EXTERNAL TABLE `my-project.my_dataset.sample_external_table` ( col_date DATE , col_datetime DATETIME , col_timestamp TIMESTAMP , col_string STRING ) OPTIONS ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); 外部テーブル作成は成功しましたが、この外部テーブルに SELECT 文を実行した際に以下のエラーメッセージが表示されました。 Error while reading table: my-project.my_dataset.sample_external_table, error message: Unable to parse; line_number: 1 byte_offset_to_start_of_line: 0 column_index: 0 column_name: "col_date" column_type: DATE value: "2025/06/07" File: gs://my-bucket/datetime_test/test_dateformat.csv Error while reading table: 〜 error message: Unable to parse; 原因 BigQuery の DATE 型や DATETIME 型、TIMESTAMP 型では、文字列をキャストする際に、日付部分が YYYY-mm-dd というハイフン区切りの形式であれば自動的に日付として認識されます。 今回は、CSV ファイル内の文字列の日付部分が、「2025/06/07」とスラッシュ区切りのため上記の形式に一致しておらず、LOAD に失敗したり、外部テーブルとしてのクエリが失敗しました。 対処法 1. date_format オプションを指定する LOAD や CREATE TABLE 文において、 date_format オプション、 datetime_format オプションを使うことで、日付にパースする文字列のフォーマットを指定することができます。 参考 : Load statements in GoogleSQL 以下は、その例です。 LOAD DATA INTO `my-project.my_dataset.sample_table` ( col_date DATE , col_datetime DATETIME , col_timestamp TIMESTAMP , col_string STRING ) FROM FILES ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ], time_zone = " Asia/Tokyo " , date_format = ' YYYY/MM/DD ' , datetime_format = ' YYYY/MM/DD HH24:MI:SS ' ); なお上記の例では、 time_zone オプションでタイムゾーンを指定することで、タイムゾーンを意識する TIMESTAMP 型の列に、任意のタイムゾーンで値を格納しています。 クエリ SELECT * FROM `my-project.my_dataset.sample_table`; クエリの結果 col_date col_datetime col_timestamp col_string 2025-06-07 2025-06-07T08:30:00 2025-06-07 08:30:00 UTC helloWorld1 2025-06-08 2025-06-08T09:00:00 2025-06-08 08:30:00 UTC helloWorld2 2025-06-09 2025-06-09T10:00:30 2025-06-09 10:00:30 UTC helloWorld3 上記の結果では、 2025/06/07 17:30:00 という日本時間の時刻を格納した文字列が、col_timestamp 列に 2025-06-07 08:30:00 UTC として正しく格納されていることがわかります。 また、CREATE EXTERNAL TABLE でも、同じように date_format オプション、 datetime_format オプションが使えます。 time_zone オプションも解釈され、外部テーブルへのクエリ時に正しくタイムゾーンが設定されます。 参考 : Data definition language (DDL) statements in GoogleSQL - CREATE EXTERNAL TABLE statement CREATE OR REPLACE EXTERNAL TABLE `my-project.my_dataset.sample_external_table` ( col_date DATE , col_datetime DATETIME , col_timestamp TIMESTAMP , col_string STRING ) OPTIONS ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ], time_zone = " Asia/Tokyo " , date_format = ' YYYY/MM/DD ' , datetime_format = ' YYYY/MM/DD HH24:MI:SS ' ); 他に、時刻のフォーマットを指定する time_format オプションや、タイムスタンプのフォーマットを指定する timestamp_format オプションもあります。 2. STRING 型として取り込む CSV の文字列を、いったん STRING 型の文字列として取り込み、後から ELT（データ変換）やビューで任意の型に変換することができます。 LOAD DATA INTO `my-project.my_dataset.sample_table` ( col_date STRING, col_datetime STRING, col_timestamp STRING, col_string STRING ) FROM FILES ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); また、外部テーブルの場合は以下のようになります。 CREATE OR REPLACE EXTERNAL TABLE `my-project.my_dataset.sample_external_table` ( col_date STRING, col_datetime STRING, col_timestamp STRING, col_string STRING ) OPTIONS ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); このようにしてできたテーブルや外部テーブルに対して、以下のように PARSE_* 関数を使ってクエリすることで、文字列を日付型等に変換することができます。 SELECT PARSE_DATE( " %Y/%m/%d " , col_date) AS col_date, PARSE_DATETIME( " %Y/%m/%d %H:%M:%S " , col_datetime) AS col_datetime, PARSE_TIMESTAMP( " %Y/%m/%d %H:%M:%S " , col_timestamp, " Asia/Tokyo " ) AS col_timestamp, col_string, FROM `my-project.my_dataset.sample_table` 参考 : Date functions 参考 : Datetime functions 参考 : Timestamp functions 3. スキーマの自動検知を利用する 以下のようにスキーマ（列名、型）を指定せずに LOAD すると、スキーマが自動判断されてロードされます。スラッシュ区切りの日付文字列も、DATE 型等として判断されます。 LOAD DATA INTO `my-project.my_dataset.sample_table_auto` FROM FILES ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); 外部テーブル定義の場合は、以下のようになります。 CREATE OR REPLACE EXTERNAL TABLE `my-project.my_dataset.sample_external_table` OPTIONS ( format = ' CSV ' , uris = [ ' gs://my-bucket/datetime_test/test_dateformat.csv ' ] ); この方法だと、列名や型を指定することができません。上記の方法で作成されたテーブルや外部テーブルを SELECT すると、いずれも以下のような結果となりました。 date_field_0 timestamp_field_1 timestamp_field_2 string_field_3 2025-06-07 2025-06-07 08:30:00 UTC 2025-06-07 17:30:00 UTC helloWorld1 2025-06-08 2025-06-08 09:00:00 UTC 2025-06-08 17:30:00 UTC helloWorld2 2025-06-09 2025-06-09 10:00:30 UTC 2025-06-09 19:00:30 UTC helloWorld3 CSV の2列目と3列目のフィールドはいずれも TIMESTAMP 型として解釈され、タイムゾーンは UTC として解釈されました。 この方法では任意の列名や型を指定できない点に留意が必要です。 4. 取り込む前にファイルを前処理する 上記の方法のほか、BigQuery からファイルを読み込む前の前処理として、ファイル自体を加工する（ELT ではなく ETL）という方法も検討できます。 この場合は BigQuery の機能だけでは取り込みを完結できません。ファイルの前処理のためのアーキテクチャを検討する必要があります。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it
アバター株式会社G-gen
BigQuery Data Transfer Serviceでイベントドリブンにデータを取り込む方法
G-genの福井です。BigQuery Data Transfer Service のイベントドリブン機能の設定手順を紹介します。 イベントドリブン転送の概要 BigQuery Data Transfer Service とは ユースケース アーキテクチャ 制限事項 料金 事前準備 API の有効化 サービスアカウントの作成とロールを付与 設定手順 データの格納先をCloud Storageに作成 データの転送先をBigQueryに作成 BigQuery Data Transfer Serviceで転送構成を作成 動作確認 イベントドリブン転送の概要 BigQuery Data Transfer Service とは BigQuery Data Transfer Service は、Google Cloud 内外のデータソースから BigQuery へのデータロードを自動化する、フルマネージドなサービスです。これまでも、決まったスケジュールで定期的にデータ転送を実行する機能が提供されていました。 2025年6月、BigQuery Data Transfer Service で新しく イベントドリブン転送 （Event-Driven Transfers）がサポートされたことで、Cloud Storage にファイルが配置されたことをトリガーに、 BigQuery へデータを転送できます。 当記事では、このイベントドリブン転送の概要から、実際のコンソール画面を用いた具体的な設定手順、そして動作確認までをステップバイステップで解説します。 参考 : BigQuery Data Transfer Service とは 参考 : イベント ドリブン転送 ユースケース イベントドリブン転送は、データが発生してから分析に利用できるまでのリードタイムを短縮したい場合に特に有効です。具体的なユースケースとしては、以下のようなシナリオが挙げられます。 ユースケース 概要 アプリケーションログの分析 Web サーバーなどから出力されるログファイルを Cloud Storage に集約し、障害検知や利用状況の分析のために BigQuery へ取り込む。 外部システムとのデータ連携 パートナー企業や SaaS からファイル形式で提供される販売データや顧客データを、Cloud Storage に配置されたタイミングで速やかに取り込む。 アーキテクチャ イベントドリブン転送は、Cloud Storage、Pub/Sub、そして BigQuery Data Transfer Service の3つのサービスを連携させて実現します。 全体の処理の流れは以下の通りです。 ユーザーまたはアプリケーションが、監視対象の Cloud Storage バケット にファイルをアップロードします。 ファイルの作成イベントを検知した Cloud Storage は、あらかじめ設定された Pub/Sub トピック に通知メッセージを送信します。 BigQuery Data Transfer Service は、その Pub/Sub トピックを購読 (Subscribe) しており、メッセージを受け取ります。 メッセージをトリガーとして、Data Transfer Service の転送ジョブが実行され、指定されたファイルを BigQuery のテーブル にロードします。 制限事項 イベントドリブン転送を使用するには、いくつかの制限事項があります。 制限事項 詳細 同一サブスクリプションの再利用不可 同じ Pub/Sub サブスクリプションを、複数のイベントドリブン転送構成で再利用することはできません。 ランタイムパラメータの非対応 転送元となる Cloud Storage のURI（データパス）に、実行時の動的なパラメータを埋め込むことはサポートされていません。 参考: ランタイム パラメータ イベントの待機時間 一度転送がトリガーされると、BigQuery Data Transfer Serviceは次のトリガーまで最大10分間待機することがあります。 参考 : イベント ドリブン転送 - 制限事項 料金 イベントドリブン転送の使用にあたり、BigQuery Data Transfer Service 自体には追加の料金はかかりません。ただし、連携する以下の各サービスにおいて、それぞれの利用量に応じた料金が発生します。 サービス 課金対象 備考 BigQuery Data Transfer Service - サービス自体の利用は無料です。 Cloud Storage ・ストレージ料金 ・オペレーション料金 ファイルの保管と読み書きに対して発生します。 参考: Cloud Storage の料金 Pub/Sub ・メッセージング料金 Cloud Storageからの通知メッセージ量に応じて発生します。 毎月最初の10GBまでは無料枠が適用されます。 参考: Pub/Sub の料金 BigQuery ・ストレージ料金 ・分析料金 ロードされたデータの保管と、そのデータに対するクエリ実行時に発生します。 参考: BigQuery の料金 事前準備 API の有効化 はじめに、以下の API を Google Cloud プロジェクトで有効化します。 サービス名 API 名 Pub/Sub pubsub.googleapis.com BigQuery bigquery.googleapis.com BigQuery Data Transfer Service bigquerydatatransfer.googleapis.com 　 Google Cloud コンソールの API とサービスの画面で、[+ API とサービスを有効にする] を選択します。 API とサービスを有効にするを選択 API とサービスを検索に pubsub.googleapis.com を入力し、検索します。 API 名で検索 検索結果が複数表示されるため、以下を選択します。 pubsub.googleapis.com の場合 pubsub.googleapis.com の選択 bigquery.googleapis.com の場合 bigquery.googleapis.com の選択 bigquerydatatransfer.googleapis.com の場合 bigquerydatatransfer.googleapis.com の選択 [有効にする] を選択します。 API を有効にするを選択 サービスアカウントの作成とロールを付与 BigQuery Data Transfer Service を実行するためのサービス アカウントを作成します。 Google Cloud コンソールの IAM と管理の画面で、[サービス アカウント] > [サービス アカウントを作成] を選択します。 サービス アカウントを作成を選択 サービス アカウント名に sv-event-driven-bq-data-transfer を入力し、[作成して続行] を選択します。 サービス アカウント名を入力すると、サービス アカウントIDは自動で設定されます。 サービス アカウントの作成 ロールに Storage オブジェクト閲覧者 （roles/storage.objectViewer）を入力し、[続行] を選択します。 サービス アカウントに権限付与 [完了] を選択します。 サービス アカウントの設定完了 設定手順 データの格納先をCloud Storageに作成 Google Cloud コンソールの Cloud Storage 画面で、[バケット] > [作成] を選択します。 バケットを作成を選択 バケット名に g-gen-blog-event_driven_bq_data_transfer 、ロケーション タイプに Region と asia-northeast1 (東京) を入力し、[作成] を選択します。 バケット名は、世界中で重複しない名前にする必要がありますので、ご自身の環境に合わせて適宜変更してください。 バケットの作成 データの転送先をBigQueryに作成 Cloud Storage から転送されたデータを格納するための、BigQuery のデータセットとテーブルを作成します。 今回は、以下のような簡単なスキーマを持つテーブルを例として作成します。 カラム名 データ型 name STRING value INTEGER 　 データセットの作成 Google Cloud コンソールの BigQuery 画面で、[スタジオ] > [エクスプローラ] のプロジェクト ID 横の [⋮] > [データセットを作成] を選択します。 データセットを作成を選択 データセット ID に event_driven_bq_data_transfer 、ロケーション タイプに リージョン と asia-northeast1 (東京) を入力し、[データセットを作成] を選択します。 データセットを作成 テーブルの作成 作成したデータセットの横にある [⋮] から [テーブルを作成] を選択します。 テーブルを作成を選択 テーブルに from_gcs 、スキーマの [フィールドを追加] リンクを選択し、以下の項目を追加します。追加が完了した後に [テーブルを作成] を選択します。 フィールド名 種類 name STRING value INTEGER テーブルを作成 BigQuery Data Transfer Serviceで転送構成を作成 Google Cloud コンソールの BigQuery 画面で、[データ転送] > [転送を作成] を選択します。 転送を作成を選択 ソースに Google Cloud Storage 、 表示名に event-driven-from-gcs 、スケジュール オプションの繰り返しの頻度に イベント ドリブン 、Pub/Sub サブスクリプションから [サブスクリプションの作成] を選択します。 転送の作成情報を入力（1/3） サブスクリプションを作成画面の [作成] ボタンを選択します。 サブスクリプションを作成 データセットに event_driven_bq_data_transfer 、Destination table に from_gcs 、Cloud Storage URI の [バケットの選択] を選択します。 転送の作成情報を入力（2/3） 前の手順で作成したバケット g-gen-blog-event_driven_bq_data_transfer を選択し、ファイル名に sample-file-*.csv を入力し、[選択] を選択します。 ここで指定したファイル名に一致したファイルが、データ転送の対象となります。 Cloud Storage URI の選択 サービス アカウントに前の手順で作成したサービスアカウント sv-event-driven-bq-data-transf@⋯ を選択し、 [保存] を選択します。 取り込み対象ファイルのフォーマット（File format）やファイル内の区切り文字（Field delimiter）など、取り込み対象のデータ形式に合わせて設定値は適宜変更してください。 転送の作成情報を入力（3/3） 動作確認 全ての設定が完了したので、実際にファイルをアップロードして、データが自動的に BigQuery へ転送されることを確認します。 サンプルCSVファイルの作成 ローカルのPCに、 sample-file-1.csv という名前で以下の内容のファイルを作成します。 BigQuery Data Transfer Service の転送作成時に、 Header rows to skip の値を 0 に設定したため、ヘッダー行は設けません。 "name-1",1 "name-2",2 "name-3",3 CSVファイルを Cloud Storage へアップロード 作成した sample-file-1.csv を、Cloud Storage バケットにアップロードします。 CSV ファイルを Cloud Storage へアップロード BigQueryでのデータ確認 ファイルがアップロードされると、イベントがトリガーされ、最大 10 分間待機した後に転送が実行されます。 今回の確認では、Cloud Storage にファイルが作成された時間（ 8:56:42 ）から転送が開始（ 9:01:44 ）されるまでに、約5分かかっています。 転送の実行履歴 BigQuery 内の登録データ 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進
アバター株式会社G-gen
外部ドメインのGmailグループアドレスを送信元としてメールを送信する方法
G-gen の中川です。本記事では、Google Workspace ユーザーが他のドメインの Google Workspace グループアドレスを送信元としてメールを送信するための、設定手順を解説します。 はじめに 事前準備 Google グループの作成 別組織のユーザーの Google アカウントの設定 別組織のユーザーの Gmail の設定 グループメンバーによる確認 メール送信時の差出人設定 はじめに 別組織のユーザーが Google Workspace グループアドレスを送信元としてメールを送信したいという要件があります。例えば、外部の協力会社のユーザーが、自分たちのドメインとは異なるドメインの Google Workspace グループのメールアドレスを送信元としてメールを送りたいというケースがあります。 本記事では、そのような要件を実現するための手順と注意点について解説します。 なお、同じ組織のユーザーでグループアドレスを送信元として追加する方法は、以下の記事を参照してください。 blog.g-gen.co.jp また当記事の情報は、2025年5月時点における当社の検証に基づくものであり、公式ドキュメントには記載されておりませんため、仕様が変更になる可能性がある点にはご留意ください。 事前準備 当記事では、メインの Google Workspace ドメインを @example.co.jp 、別組織側のドメインを @different-domain.com として解説します。 なお、当記事では両ドメインとも Google Workspace のメールアドレスで検証を行いますが、当記事の手順により、個人向けの Google アカウント ( @gmail.com ) でも Google Workspace グループアドレスを送信元として追加できます。 まず、別組織 ( @different-domain.com ) の Google Workspace の管理コンソールで、以下の設定が有効になっている必要があります。 2 段階認証プロセス メールドメインの外部でホストされている「送信元」アドレスを設定した場合に、ユーザーに外部の SMTP サーバーを経由したメールの送信を許可 詳細は以下の公式ドキュメントを参照してください。 参考 : 2 段階認証プロセスを導入する 参考 : ユーザーごとの送信ゲートウェイの許可 Google グループの作成 送信元としたい Google グループ ( group@example.co.jp ) を作成します。 具体的な方法は上記で紹介した以下の記事の「設定1 : Google グループ作成」をご参照ください。 参考 : Google Workspace で問い合わせ対応システムを作成する方法 #2 (Google グループ設定) - G-gen Tech Blog - 設定1 : Google グループ作成 既にグループを作成済みの場合は、アクセスタイプの「投稿できるユーザー」が「外部」になっているかを確認します。 別組織のユーザーの Google アカウントの設定 送信を行う別組織のユーザー ( user@different-domain.com ) の Google アカウントの設定をします。 2 段階認証プロセス が有効になっていない場合は 2 段階認証プロセスを設定します。アプリ パスワードの作成には、2 段階認証が有効になっている必要があります。 参考 : 2 段階認証プロセスを有効にする 次に アプリ パスワード を作成します。 任意の名前を「アプリ名」(送信用グループアドレス)に入力し「作成」をクリックします。 生成されたアプリ パスワードを控えてください。このパスワードは、Gmail の SMTP 設定で使用します。 参考 : アプリ パスワードでログインする 別組織のユーザーの Gmail の設定 別組織のユーザー ( user@different-domain.com ) の Gmail にアクセスします。 右上の歯車アイコンをクリックし、「すべての設定を表示」を選択します。 上部のタブから「アカウント」または「アカウントとインポート」を選択します。次に、「他のメールアドレスを追加」をクリックします。 表示されたウィンドウに、以下の情報を入力します。 設定項目 設定値 名前 任意のグループ名 (送信用グループアドレス) メール グループアドレス ( group@example.com ) エイリアスとして扱います。 有効 「次のステップ」をクリックします。 「SMTP サーバー経由で送信」を選択し、以下の情報を入力します。 設定項目 設定値 SMTP サーバー smtp.gmail.com ユーザー名 別組織のユーザーのメールアドレス ( user@different-domain.com ) パスワード 作成したアプリ パスワード ポート 587 TLS を使用したセキュリティで保護された接続（推奨） 選択 「アカウントを追加」をクリックします。 グループメンバーによる確認 グループのメンバー宛に確認メールが送信されます。 グループのメンバーは、受信した確認メール内のリンクをクリックしてリクエストを承認します。 確認メールが見当たらない場合は、Google グループの「スレッド」をご確認ください。 メール送信時の差出人設定 上記の手順が完了すると、Gmail でメールを作成する際に、「差出人」の項目で追加したグループのメールアドレスを選択できます。これにより、受信者にはグループアドレスからのメールとして表示されます。 中川 涼介 (記事一覧) クラウドソリューション部 クラウドサポート課 2024年11月、G-genに入社。Google Cloudを日々勉強中。 最近は怪談の動画にハマってます。
アバター株式会社G-gen

コンテンツ

トップイベントブロググループに関するお問い合わせ