G-gen の西田です。Cloud Storage にアップロードした CSV ファイルをデータソースとして、自動で更新される Looker Studio レポートを作成する手順を解説します。 はじめに 当記事の概要 構成図 サンプルデータの内容 構築手順の概要 Cloud Storage の構築 バケットの作成 CSV ファイルの保存 BigQuery の構築 データセットの作成 テーブルの作成 Looker Studio の作成 動作確認 はじめに 当記事の概要 当記事では、オブジェクトストレージの Cloud Storage 、データウェアハウスの BigQuery 、BI ツールの Looker Studio の3つのサービスを利用します。Cloud Storage に保存した CSV ファイルを BigQuery の外部テーブルとして参照し、そのデータを Looker Studio で可視化します。 ① Cloud Storage テキストや画像、動画などの非構造化データなど様々な形式のデータを、容量無制限で保存できるオブジェクトストレージサービスです。 参考 : Cloud Storage の料金 blog.g-gen.co.jp ② BigQuery BigQuery とは、Google Cloud のフルマネージドな分析用データベースです。BigQuery のデータは表形式で保存され、SQL や Web API 経由でデータを操作できます。 参考 : BigQuery の概要 blog.g-gen.co.jp ③ Looker Studio Looker Studio とは、Google Cloud が提供する完全クラウドベースのダッシュボードツールであり、当記事で取り扱う BigQuery 以外にも、Google アナリティクスや Google スプレッドシート等、様々なデータソースへ接続でき、SQL 等の専門知識がなくてもダッシュボード作成が可能です。 参考 : Looker Studio へようこそ なお名前がよく似ている Looker と Looker Studio は、それぞれ別製品ですのでご注意ください。当記事では Looker Studio を扱います。これらの2製品の違いは、以下の記事も参照してください。 blog.g-gen.co.jp 構成図 このシステムでは、ユーザーは Looker Studio レポートを通じて、Cloud Storage 上の CSV ファイルを可視化できます。システム構成は次の通りです。 データの可視化は Looker Studio レポートによって行われます。 このレポートからは、BigQuery の 外部テーブル をデータソースとして指定します。外部テーブルとは、BigQuery の外部にあるファイルを BigQuery からクエリできるようにする機能です。 この BigQuery 外部テーブルは、Cloud Storage バケットの所定のパスをデータソースとしています。このパスには、社内システムなどからエクスポートした CSV ファイルが管理者または自動ジョブによりアップロードされる想定です。 これにより、ユーザーが Looker Studio レポートへアクセスすると、Looker Studio から BigQuery 外部テーブルに SQL が発行されます。外部テーブルからは Cloud Storage 上のファイルが直接参照されるため、Cloud Storage から BigQuery へのデータ転送は不要です。また、常に最新のファイルが参照されることになります。 BigQuery の外部テーブルについては、以下の記事でも解説されています。 blog.g-gen.co.jp サンプルデータの内容 当記事では、文房具やPCサプライ品を販売する架空の会社の、販売実績や見込金額のサンプルデータを使います。データは、月ごとに別々の CSV ファイルに格納されています。 CSV ファイルのスキーマは、以下のようなものです。 customer_id customer_name stationery pc_supplies estimate industory GS00001 株式会社アルファネクスト 4,178 6,153 8,000 情報通信 GS00003 株式会社シーウェーブソリューションズ 1,790 2,623 3,000 サービス ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ 列名は、左から「顧客 ID」「顧客名」「文房具の売上」「PC サプライ品の売上」「見込金額」「業種」を示しています。 構築手順の概要 構築は以下の3ステップで完了します。 Cloud Storage : CSV ファイルを保管する環境を構築する BigQuery : Cloud Storage に保存した CSV ファイルのデータを Looker Studio で表示するための外部テーブルを構築する Looker Studio : BigQuery テーブルのデータをレポートで可視化する Cloud Storage の構築 バケットの作成 まずは、CSV ファイルを保存する Cloud Storage の準備をします。Cloud Storage では、データを バケット と呼ばれるコンテナに格納します。バケットの中にフォルダやファイルを保存できます。このバケット単位でアクセス権の制御を行うことができます。 Cloud Storage > バケット のページにアクセスして、[バケットを作成]をクリックします。 バケット名やデータの保存場所を指定して [作成] ボタンをクリックします。バケットの名称は、グローバルで一意となるようにする必要があります。 当記事では、その他の設定項目はデフォルトのままで最下部の [作成] ボタンをクリックします。 「公開アクセスの防止」というポップアップが表示された場合は、右下の [続行] ボタンをクリックします。 CSV ファイルの保存 バケットが作成できたら、CSV ファイルを保存する準備をします。 作成したバケットにアクセスし、[フォルダの作成] をクリックします。 Cloud Storage に保存した CSV データを BigQuery の外部テーブルとして扱う際、フォルダ名を Key=Value の形式（例: ym=202504 ）で作成すると、そのキー（この場合は ym ）をテーブルの列として自動的に認識させることができます。これを外部データの パーティション分割 （または Hive パーティショニング）と呼びます。当記事で扱う CSV データには年月を表す列がないため、この仕組みを利用してデータを分割します。 外部データをパーティション分割することにより、データを月別にフィルタして表示した際に、Cloud Storage 上のすべてのファイルがフルスキャンされるのではなく、特定の月のファイルのみがスキャンされることになります。これはパフォーマンス向上と、コスト効率の向上に繋がります。 参考 : 外部でパーティションに分割されたデータを使用する 作成したフォルダにアクセスし、[アップロード] をクリックし、CSV ファイルをアップロードします。アップロードは、画面にファイルをドラッグアンドドロップする方法もあります。 BigQuery の構築 データセットの作成 次に、BigQuery で先程の CSV を読み取るための、 外部テーブル を作成します。 BigQuery のテーブルは、データセットという論理的な入れ物の配下に作成します。 BigQuery のコンソール画面で、プロジェクトIDの右側にある3点リーダーをクリックし、[データセットを作成] をクリックします。 データセットIDやリージョンを指定して、[データセットを作成] ボタンをクリックします。 テーブルの作成 作成したデータセットの中に、テーブルを作成します。 設定手順は表の通りです。 [Create table from] で Google Cloud Storage を選択 [GCS バケットからファイルを選択するか URI パターンを使用します] の欄に <作成したバケット名>/* を入力 （/* をつけることで、バケット配下の全てのファイル（フォルダを含む）を対象に指定しています。） （例） sales-data-csv-mnishida-blog/* [ファイル形式] で CSV を選択 [ソースデータ パーティショニング] のチェックをオン [ソース URI の接頭辞を選択] の欄に、 gs://<作成したバケット名> を入力 （例） gs://sales-data-csv-mnishida-blog [パーティション推論モード] で [独自に指定します] を選択する [フィールドを追加] をクリックし、[フィールド名] に ym を入力 （4~7の設定で、先ほど Cloud Storage で ym=202504 のように作成したフォルダ名をパーティション列として認識させています。） [テーブル] 欄にテーブル名を入力　（例） t_sales_data [テーブルタイプ] で 外部テーブル を選択 スキーマの [自動検出] のチェックをオン 詳細オプションを開き、[スキップするヘッダー行] に 1 を入力 （CSV ファイルの1行目が見出し行であるため、データとして読み込まないように設定しています。） [テーブルを作成] ボタンをクリック Looker Studio の作成 作成したテーブルを選択し、[次で開く] の中から [Looker Studio] を選択します。 Looker Studio のレポート画面は、画面上部のメニューから任意のグラフやコントロールを追加します。 以下は、サンプルレポートの画面と設定内容です。 ① テキスト ② グラフ > スコアカード ③ グラフ > スコアカード ④ コントロール > プルダウン リスト ⑤ コントロール > プルダウン リスト ⑥ グラフ > 円グラフ ⑦ グラフ > 棒グラフ ⑧ グラフ > 表 動作確認 現時点では4月分のデータのみ保存しているため、レポートでも4月分のデータしか閲覧できません。 他の月のデータを表示するためには、Cloud Storage のバケット内に4月分のフォルダを作成した時と同様に、 ym=202505 、 ym=202506 などのフォルダを作成してファイルを保存するだけでデータの更新できます。 各月のファイルを保存した後に Looker Studio でデータを更新することで、追加した月の選択やデータの閲覧が可能となります。 西田 匡志 (記事一覧) クラウドソリューション部ソリューションアーキテクト課 美容商社→物流→情シスを経て、2025年6月G-genにジョイン。Google Cloud を通じて多くの人に貢献できるよう日々精進！

G-gen の佐々木です。当記事では、GKE で Gateway API を使用する際に、作成されたアプリケーションロードバランサーに対して Cloud Armor セキュリティポリシー と IAP を構成する方法を解説します。 はじめに GKE における Gateway API Cloud Armor とは Identity-Aware Proxy（IAP）とは 当記事の構成 GCPBackendPolicy に関する注意点 Gateway リソースに対して Cloud Armor セキュリティポリシーを構成する手順 Cloud Armor セキュリティポリシーの作成 GCPBackendPolicy の作成 動作確認 Gateway リソースに対して IAP を構成する手順 OAuth 同意画面の構成 バックエンドサービスで IAP を有効化 OAuth 2.0 クライアント ID とシークレットの発行 Secret の作成 GCPBackendPolicy の作成 動作確認 Cloud Armor セキュリティポリシーと IAP を同時に構成する手順 Ingress API を使う場合 はじめに GKE における Gateway API Gateway API は、Kubernetes でレイヤ7の高度なトラフィックルーティングを提供するための Kubernetes アドオンであり、Google Cloud では GKE で L7 ロードバランサー（アプリケーションロードバランサー）を利用したい場合に使用されます。 従来から同様の用途で使用されていた Ingress API に様々な改良が加えられたものであり、高度なルーティング（ヘッダーベース、重み付けなど）や、異なる Namespace にあるリソースへのアクセスなどがネイティブにサポートされています。 Gateway API の基本については以下の記事を参照してください。 blog.g-gen.co.jp 当記事では、この Gateway API から作成したアプリケーションロードバランサーに対して、 Cloud Armor セキュリティポリシー によるバックエンド保護と、 Identity-Aware Proxy （IAP）による IAM 認証機能を構成していきます。 Cloud Armor とは Cloud Armor は Google 製のクラウド型 WAF であり、Cloud Armor の セキュリティポリシー をアプリケーションロードバランサのバックエンドに紐づけることで、バックエンドに対するアクセス元の制限をかけることができます。 Cloud Armor の詳細については、以下の記事で解説しています blog.g-gen.co.jp Identity-Aware Proxy（IAP）とは IAP は、Cloud Run や GKE、Compute Engine 上で実行されているアプリケーションに対して、IAM による認証機能を提供するサービスです。アプリケーションにアクセスできるユーザーを特定の IAM ロールがアタッチされた Google アカウント/グループに制限することができます。 IAP の基本については、以下の記事で解説しています。 blog.g-gen.co.jp 当記事の構成 当記事では、以下の記事で作成した Gateway API リソースと nginx のバックエンドを持つ環境に対して、Cloud Armor セキュリティポリシーと IAP を追加で構成していきます。以降の手順の前提となるサンプル環境を構成するためのマニフェストファイルについては、同記事を参照してください。 blog.g-gen.co.jp 当記事で前提となるサンプル構成 GCPBackendPolicy を使用して Cloud Armor や IAP を構成する GCPBackendPolicy に関する注意点 Gateway API で作成したロードバランサーに対して Cloud Armor セキュリティポリシーや IAP を構成したい場合、Gateway API リソースの1つである Policy を使用します。 GKE で利用できる Gateway API の Policy には以下のような種類があります。 GCPGatewayPolicy GCPBackendPolicy HealthCheckPolicy Cloud Armor や IAP を利用する場合は、 GCPBackendPolicy を定義し、Gateway のバックエンド（ルーティング先）である Service リソースに紐付けます。 注意点として、GCPBackendPolicy は 1つの Service に対して1つしか紐付けることはできません。そのため、 1つの Service に対して Cloud Armor セキュリティポリシーと IAP の両方を構成したい場合、その両方の定義を1つの BackendPolicy 内に記述する必要があります。 2つの GCPBackendPolicy を紐づけると、 kubectl describe gcpbackendpolicies コマンドの出力として以下のエラーメッセージが確認できます。 Warning SYNC 14s (x2 over 63s) sc-gateway-controller Conflicted: Application of GCPBackendPolicy "default/nginx-backend-policy" failed: conflicted with GCPBackendPolicy "default/my-backend-policy" of higher precedence, hence not applied 参考 : Configure Gateway resources using Policies Gateway リソースに対して Cloud Armor セキュリティポリシーを構成する手順 Cloud Armor セキュリティポリシーの作成 ここでは、サンプル構成に対して Cloud Armor のセキュリティポリシーを適用し、許可された IP アドレスからのみ、バックエンドのサービスにアクセスできるようにします。 まず、Cloud Armor のセキュリティポリシーを作成します。 # セキュリティポリシーの作成 $ gcloud compute security-policies create my-sec-policy 作成したポリシーのデフォルトルール（優先度2,147,483,647）では全ての通信が許可されているため、デフォルトルールを更新して全てのアクセス元を拒否します。 # デフォルトルールの更新 $ gcloud compute security-policies rules update 2147483647 \ --security-policy my-sec-policy \ --action " deny-403 " 特定の IP アドレス範囲からのアクセスを許可するルールを追加します。 ルールの優先度は全拒否のデフォルトルールより高ければよいので、ここでは優先度1000で設定します。 # 許可ルールの追加 $ gcloud compute security-policies rules create 1000 \ --security-policy my-sec-policy \ --src-ip-ranges " <許可する IP アドレス範囲> " \ --action " allow " 特定の IP アドレス範囲のみ許可するセキュリティポリシー 参考 : gcloud compute security-policies create 参考 : gcloud compute security-policies update GCPBackendPolicy の作成 作成した Cloud Armor セキュリティポリシーを Gateway のバックエンドサービスに紐づけるための GCPBackendPolicy を作成します。 以下のマニフェストを使用して、バックエンドの Service リソースに対してセキュリティポリシーを紐づけます # backend-policy.yaml apiVersion : networking.gke.io/v1 kind : GCPBackendPolicy metadata : name : nginx-backend-policy spec : default : securityPolicy : my-sec-policy # Cloud Armor セキュリティポリシーの名前 targetRef : group : "" kind : Service name : nginx-service # ルールを紐づけるバックエンドの Service リソース 動作確認 Cloud Armor セキュリティポリシーで許可していない IP アドレスから、ロードバランサーに設定しているドメインにアクセスしてみます。 セキュリティポリシーにより、アクセスが拒否されていることがわかります。 セキュリティポリシーで許可されてない IP アドレスからのアクセスが拒否される 許可した IP アドレスからのアクセスは成功する このまま続けて次の IAP の構成手順に進む場合、一度 GCPBackendPolicy リソースを削除してください（Service に対して1つしか紐づけられないため）。 Gateway リソースに対して IAP を構成する手順 OAuth 同意画面の構成 使用しているプロジェクトで OAuth 同意画面 をまだ構成していない場合は、設定を行います。 手順は以下のドキュメントや記事を参照してください。 参考 : Configure the OAuth consent screen and choose scopes 参考 : GoogleAPI、OAuth2.0の有効化の手順 - サーバーワークスエンジニアブログ バックエンドサービスで IAP を有効化 Google Cloud コンソールから、バックエンドサービスに対して IAP を有効化します。 対象のサービスのトグルスイッチを ON にし、「IAP をオンにする」を選択します。 バックエンドサービスで IAP を有効化する 「IAP をオンにする」を選択 サービスへのアクセスを許可する Google アカウントに対して、 IAP で保護されたウェブアプリ ユーザー （IAP-secured Web App User）ロールを付与します。 アカウント、グループに対してサービスへの IAP 経由のアクセスを許可する OAuth 2.0 クライアント ID とシークレットの発行 Google Cloud コンソールの「API とサービス」から、OAuth 2.0 クライアント ID を作成していきます。 「OAuth クライアント ID」を選択する 以下の項目を入力し、「作成」を選択します。 項目 値 アプリケーションの種類 ウェブ アプリケーション 名前 任意の名前 OAuth クライアント ID を作成する 作成後、 クライアント ID と クライアントシークレット が表示されるので、この2つはメモしておきます。なお、メモするのを忘れてもクライアントの詳細画面から後で確認できます。 クライアント ID とクライアントシークレットをメモしておく 作成したクライアント ID の編集画面を開き、「承認済みのリダイレクト URI」項目を設定します。 値には、先ほどメモしておいたクライアント ID を含む以下の URI を設定します。 「承認済みのリダイレクト URI」の設定値 https://iap.googleapis.com/v1/oauth/clientIds/{クライアント ID の値}:handleRedirect 承認済みのリダイレクト URI を設定する Secret の作成 メモしておいた OAuth クライアント シークレットを以下のようにテキストファイルにそのまま記述します。当記事では iap-secret.txt という名前でファイルを作成します。 <クライアント シークレットの値> このテキストファイルを使用して、以下のコマンドで Secret リソースを作成します。 # Secret の作成 $ kubectl create secret generic my-secret --from-file = key =iap-secret.txt GCPBackendPolicy の作成 作成した Secret リソースと、メモしておいた OAuth クライアント ID を使用し、バックエンドの Service に紐づける GCPBackendPolicy を作成します。 マニフェストファイルは以下のようになります。 # backend-policy.yaml apiVersion : networking.gke.io/v1 kind : GCPBackendPolicy metadata : name : nginx-backend-policy spec : default : iap : enabled : true # IAP を有効化 oauth2ClientSecret : name : my-secret # 作成した Secret リソースの名前 clientID : <OAuth クライアント ID> # メモしておいた OAuth クライアント ID targetRef : group : "" kind : Service name : nginx-service # ルールを紐づけるバックエンドの Service リソース 動作確認 マニフェストファイル適用後、ロードバランサーに設定しているドメインにアクセスすると、IAP のログイン画面が表示されます。 IAP が有効化されたサービスにアクセスする IAM で許可された Google アカウントでログインすることで、サービスにアクセスすることができます。 Cloud Armor セキュリティポリシーと IAP を同時に構成する手順 先述したように、バックエンドサービスである Service に対して、GCPBackendPolicy リソースは1つしか紐づけることができません。 Cloud Armor セキュリティポリシーと IAP を同時に構成したい場合、以下のように1つのマニフェストファイルに対してそれぞれの定義をします。 # backend-policy.yaml apiVersion : networking.gke.io/v1 kind : GCPBackendPolicy metadata : name : nginx-backend-policy spec : default : securityPolicy : my-sec-policy # Cloud Armor セキュリティポリシーの名前 iap : enabled : true # IAP を有効化 oauth2ClientSecret : name : my-secret # 作成した Secret リソースの名前 clientID : <OAuth クライアント ID> # メモしておいた OAuth クライアント ID targetRef : group : "" kind : Service name : nginx-service # ルールを紐づけるバックエンドの Service リソース なお、Cloud Armor セキュリティポリシーと IAP を同時に構成した場合、 先にセキュリティポリシーによるアクセス許可/拒否が評価 され、ポリシーで許可されたアクセスに対して 後から IAP による認証 が行われます。 Ingress API を使う場合 GKE で Cloud Load Balancing のアプリケーションロードバランサーを使用する場合、従来は Ingress API を使用していました。 Ingress API を使用している場合、ロードバランサーに対して Cloud Armor や IAP を構成するには BackendConfig リソースをバックエンドの Service リソースに紐付けます。 Ingress API を使用する場合の詳細な手順については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では、Kubernetes で展開しているサービスの外部公開用 API リソースである Gateway API について、特に GKE で使用する場合における基本的な仕様を解説します。 Gateway API の概要 Ingress API との違い Ingress からの改良点 GKE における違い Gateway API のリソース リソースの構成 GatewayClass Gateway HTTPRoute Policy ReferenceGrant Gateway API を使ってみる サンプル構成 Gateway API の有効化 SSL 証明書の作成 サンプル Pod、Service のデプロイ Gateway のデプロイ DNS レコードの設定 HTTPRoute のデプロイ 動作確認 Gateway API の概要 Gateway API は、Kubernetes でレイヤ7の高度なトラフィックルーティングを提供するための Kubernetes アドオンであり、 Ingress API 同様、レイヤ7ロードバランサーをデプロイすることでバックエンドのサービスを公開することができます。 GKE における Gateway API では、GKE クラスタで使用できる Cloud Load Balancing の各種アプリケーションロードバランサーを定義、デプロイすることができます。 参考 : Gateway API（Kubernetes ドキュメント） 参考 : About Gateway API（Google Cloud ドキュメント） Ingress API との違い Ingress からの改良点 一般的に、Kubernetes では外部公開するアプリケーションにトラフィックをルーティングしたい場合、 Ingress を使用することができます。 Gateway は Ingress よりも後発の API リソースであり、以下のような改良が加えられています。 改良点 Ingress API の課題 Gateway API の特徴 ロール志向 1つのリソースにインフラの設定とアプリケーションのルーティング設定をまとめて定義する必要がある。そのため、インフラ担当者とアプリケーション開発者の責任範囲が曖昧になっている。 リソース定義を Gateway（インフラ定義）、HTTPRoute（ルーティング定義） のように分割することで、インフラ担当者とアプリケーション開発者がそれぞれの担当領域（ロール）でリソースを管理できる。 移植性・表現性 パスベース以外のルーティングなど、高度な機能はネイティブでサポートされておらず、GKE なら GKE 用の Ingress Controller が独自に定義したアノテーションを用いて実装する必要がある。 多くの高度な機能がネイティブでサポートされており、リソース定義がクラウドプロバイダーやオンプレミスなど環境に依存しない。 Namespace 間アクセス Ingress 単体の機能では、異なる Namespace にあるバックエンドサービスや Secret にアクセスすることができない。たとえばマイクロサービスごとに Namespace を割り当てている環境などで、1つの Ingress からそれぞれのサービスにルーティングするような構成ができない。 Gateway は異なる Namespace のリソースにアクセスすることができる。 参考 : Ingress の進化版 Gateway API を解説する Part 1 (シングルクラスタ編) GKE における違い GKE における Ingress では、外部アプリケーションロードバランサー向けの Ingress と、内部アプリケーションロードバランサー用の Ingress を使用することができます。前者は Cloud Load Balancing の 従来の外部アプリケーションロードバランサー を、後者は 内部アプリケーションロードバランサー をデプロイします。 後述するように、Gateway API では GatewayClass により、新しい世代の（「従来の」ではない）外部アプリケーションロードバランサーや、マルチクラスタで利用できるロードバランサーをデプロイすることができるようになっています。 Google Cloud の Cloud Load Balancing を利用する場合、ロードバランサーの各コンポーネントと Ingress API、Gateway API の関係は以下の図のようになっています。 Cloud Load Balancing の各コンポーネントと Ingress API、Gateway API の関係 参考 : GKE Ingress for Application Load Balancers Gateway API のリソース リソースの構成 Gateway API は主に以下のリソースから構成されます。 GatewayClass Gateway HTTPRoute Gateway API の基本的なリソース構成 また、以下のような補助的なリソースがあります。 Policy RefernceGrant GatewayClass Gateway から参照されるリソースで、クラスタに作成するロードバランサーのテンプレートとして機能します。GKE の場合、Google Cloud によってクラスタで利用できるロードバランサーが GatewayClass として事前定義されています。 以下は、GKE クラスタで利用可能な GatewayClass の例です。 GatewayClass の名前 対応する Cloud Load Balancing のロードバランサー gke-l7-global-external-managed グローバル外部アプリケーションロードバランサ gke-l7-regional-external-managed リージョン外部アプリケーションロードバランサ gke-l7-rilb 内部アプリケーションロードバランサ gke-l7-global-external-managed-mc マルチクラスタ用のグローバル外部アプリケーションロードバランサ gke-l7-regional-external-managed-mc マルチクラスタ用のリージョン外部アプリケーションロードバランサ gke-l7-rilb-mc マルチクラスタ用の内部アプリケーションロードバランサ 上記の GatewayClass の名前を Gateway のリソース定義で指定することで、対象のロードバランサーを作成することができます。 apiVersion : gateway.networking.k8s.io/v1 kind : Gateway metadata : name : internal-http spec : gatewayClassName : gke-l7-rilb # 内部アプリケーションロードバランサを作成する listeners : - name : http protocol : HTTP port : 80 詳細な仕様やその他の GatewayClass については、以下の公式ドキュメントもご一読ください。 参考 : GatewayClass capabilities Gateway トラフィックを処理するロードバランサーの種類（GatewayClass）、プロトコル、ポート、TLS 設定などを定義します。 apiVersion : gateway.networking.k8s.io/v1 kind : Gateway metadata : name : external-http spec : gatewayClassName : gke-l7-global-external-managed # ロードバランサーの種類（GatewayClass） listeners : # プロトコル、ポート、TLS 設定など、リスナーの設定 - name : https protocol : HTTPS port : 443 tls : mode : Terminate certificateRefs : - name : store-example-com HTTPRoute Gateway が受信したリクエストを、バックエンドの Service リソースにルーティングするためのルールを定義します。 apiVersion : gateway.networking.k8s.io/v1 kind : HTTPRoute metadata : name : store-external labels : gateway : external-http spec : parentRefs : - name : external-http # ルーティング設定を紐付ける Gateway リソースの名前 hostnames : # ルーティング設定を適用するホスト名 - "store.example.com" rules : - backendRefs : # Gateway が受信したリクエストをルーティングするバックエンドサービス - name : store-v1 # Service リソースの名前 port : 8080 Policy バックエンドサービスに対するヘルスチェックやトラフィック分散の方法、リクエストのタイムアウト、Identity-Aware Proxy や Cloud Armor バックエンドセキュリティポリシーの紐付けなどを定義します。 設定する Policy の種類によって、Policy リソースを Gateway リソースや Service リソースに対して紐付けます。 例えば以下のマニフェストファイルでは、Gateway リソースとして作成したロードバランサーに対する SSL ポリシーの紐付けが定義されています。 apiVersion : networking.gke.io/v1 kind : GCPGatewayPolicy metadata : name : my-gateway-policy namespace : team1 spec : default : sslPolicy : gke-gateway-ssl-policy # SSL ポリシーの名前 targetRef : group : gateway.networking.k8s.io kind : Gateway name : my-gateway # Policy を紐付ける Gateway リソースの名前 参考 : Configure Gateway resources using Policies ReferenceGrant Gateway や HTTPRoute が、異なる Namespace にあるバックエンドサービス、Secret などを参照できるようにするリソースです。 以下のマニフェストファイルは、 frontend Namespace の HTTPRoute から backend Namespace の Service にトラフィックをルーティングできるような ReferenceGrant を定義しています。 apiVersion : networking.gke.io/v1 kind : ReferenceGrant metadata : name : allow-frontend-to-access-backend namespace : backend # Namespace間アクセスを許可するアクセス先のNamespace spec : from : # どこからのアクセスを許可するか - group : gateway.networking.k8s.io kind : HTTPRoute namespace : frontend to : # 何に対するアクセスを許可するか - group : "" kind : Service Gateway API を使ってみる サンプル構成 当記事ではサンプル構成として、nginx をバックエンドサービスとする Gateway、HTTPRoute リソースを作成していきます。Gateway には Certificate Manager で作成した Google マネージド SSL 証明書を紐づけ、Gateway で作成されたロードバランサーに HTTPS でアクセスできるようにします。 当記事のサンプル構成 Gateway API の有効化 GKE クラスタで Gateway API が有効化されていない場合は有効化します。 # クラスタで Gateway API を有効化する $ gcloud container clusters update < GKEクラスタ名 > \ --location =< クラスタのロケーション > \ --gateway-api = standard SSL 証明書の作成 Gateway API で作成するロードバランサーで TLS を設定するために、Certificate Manager 管理の証明書を作成します。 当記事では Google マネージド SSL 証明書を使用します。 # Google マネージド SSL 証明書を作成する $ gcloud certificate-manager certificates create my-cert \ --domains =" <使用するドメイン> " \ --scope = DEFAULT # 証明書マップを作成する $ gcloud certificate-manager maps create my-cert-map # 証明書マップのエントリーを作成する $ gcloud certificate-manager maps entries create [ ENTRY_NAME ] \ --map =" my-cert-map " \ --certificates =" my-cert " \ --hostname =" <使用するドメイン> " 参考 : Manage certificates サンプル Pod、Service のデプロイ サンプルアプリケーションとして、以下のマニフェストを使用して nginx の Pod と Service をデプロイします。 # deployment.yaml apiVersion : apps/v1 kind : Deployment metadata : name : nginx-deployment spec : replicas : 2 selector : matchLabels : app : nginx-server template : metadata : labels : app : nginx-server spec : containers : - name : nginx image : nginx:latest ports : - containerPort : 80 --- apiVersion : v1 kind : Service metadata : name : nginx-service spec : selector : app : nginx-server ports : - protocol : TCP port : 80 targetPort : 80 Gateway のデプロイ ロードバランサーのフロントエンドとして機能する Gateway リソースを作成します。 以下のサンプルマニフェストでは、先ほど作成した証明書を使用するグローバル外部アプリケーションロードバランサーを作成する Gateway リソースをデプロイします。 # gateway.yaml apiVersion : gateway.networking.k8s.io/v1 kind : Gateway metadata : name : external-https-gateway annotations : networking.gke.io/certmap : "my-cert-map" # 作成した証明書マップの名前 spec : gatewayClassName : gke-l7-global-external-managed # グローバル外部アプリケーションロードバランサーを使用 listeners : - name : https-listener protocol : HTTPS port : 443 デプロイした Gateway リソースは以下のコマンドで確認できます。 # デプロイした Gateway の確認 $ kubectl get gateways NAME CLASS ADDRESS PROGRAMMED AGE external-https-gateway gke-l7-global-external-managed xxx.xxx.xxx.xxx True 74s Google Cloud コンソールを確認すると、アプリケーションロードバランサーが作成されていることがわかります。 Gateway のデプロイ後、ロードバランサーが作成されている DNS レコードの設定 使用するドメインに対して、先ほど kubectl get gateways コマンドで確認したロードバランサーの外部 IP アドレスを解決できる A レコードを作成します。 以下のスクリーンショットは、Cloud DNS を使用する場合のレコードの設定例です。 DNS で A レコードを設定する HTTPRoute のデプロイ Gateway が受信したトラフィックをバックエンドサービスにルーティングするために、HTTPRoute をデプロイします。 以下のサンプルマニフェストでは、バックエンドである nginx サービスの80番ポートにトラフィックをルーティングする HTTPRoute リソースを作成します。 apiVersion : gateway.networking.k8s.io/v1 kind : HTTPRoute metadata : name : nginx-http-route spec : parentRefs : - name : external-https-gateway # Gatewayリソースの名前 hostnames : - "<使用するドメイン>" rules : - matches : - path : type : PathPrefix value : / backendRefs : - name : nginx-service # バックエンドの Service の名前 port : 80 デプロイした HTTPRoute リソースは以下のコマンドで確認できます。 $ kubectl get httproutes NAME HOSTNAMES AGE nginx-http-route [" <使用するドメイン> "] 13s 動作確認 作成した Gateway 関連リソースは、GKE のコンソールからも確認することができます。 GKE コンソールから Gateway の設定を確認する それでは、使用しているドメインに対して、curl コマンドやブラウザから HTTPS でアクセスしてみます。 Gateway API で作成したアプリケーションロードバランサー経由で、HTTPS でバックエンドサービスにアクセスできています。 Gateway API で作成したロードバランサー経由で HTTPS アクセスができている 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の min です。BigQuery のためのデータ変換ワークフローサービスである Dataform における、「ワークスペースコンパイルオーバーライド」「リリース構成」「ワークフロー構成」という3つの機能について解説します。 はじめに 当記事について Dataform のワークフローライフサイクル 構成機能 ワークスペースコンパイルオーバーライド 機能概要 設定方法 注意点 リリース構成 機能概要 設定方法 ワークフロー構成 機能概要 設定方法 開発と管理 ライフサイクルの全体像 ベストプラクティス 必要なロール リソースの有効期限 はじめに 当記事について BigQuery のためのデータ変換ワークフローサービスである Dataform における、コンパイルと実行のライフサイクル管理について解説します。 具体的には、「 ワークスペースコンパイルオーバーライド 」「 リリース構成 」「 ワークフロー構成 」という3つの機能を用いて、開発環境と本番環境を分離し、実行を自動化する仕組みを詳しく説明します。 Dataform の基本的な概念や使い方については、以下の記事で解説しています。 blog.g-gen.co.jp Dataform のワークフローライフサイクル まず、Dataform におけるワークフローのライフサイクルを理解することが重要です。ライフサイクルは、大きく分けて「 開発 」「 コンパイル 」「 実行 」の3つのフェーズで構成されます。 1 開発 Dataform のワークスペースで SQLX ファイルを記述し、データ変換のロジックを開発します。 2 コンパイル Dataform は、ワークスペースに記述されたコードをリアルタイムで SQL にコンパイルします。このコンパイル結果は、実際に BigQuery で実行される SQL の集合体です。Dataform のコンパイルは密閉されたサンドボックス環境で行われ、毎回同じコードからは同じコンパイル結果が生成される整合性が保証されます。 3 実行 生成されたコンパイル結果を、Dataform が BigQuery 上で実行します。これにより、テーブルやビューが作成・更新されます。 この記事で紹介する機能は、主に「コンパイル」と「実行」のフェーズを、要件に合わせて柔軟にカスタマイズするためのものです。 参考 : Dataform のワークフロー ライフサイクルの概要 構成機能 Dataform で開発したデータ変換ロジックを実際の環境（開発環境、本番環境など）でどのようにコンパイルして実行するかを規定する一連の流れを「ライフサイクル」と呼びます。このライフサイクルを管理・自動化するために、Dataform では主に以下の3つの機能が提供されています。 これらの機能は、SQLX ファイルを記述するといった「開発」そのものとはレイヤーが異なり、完成したコードを本番環境へ安全にデプロイし、定期実行するための「仕組み」を構築する役割を担います。それぞれの目的と役割は以下のとおりです。 機能名 主な目的 利用フェーズ ワークスペースコンパイルオーバーライド 開発者ごとの 開発環境を分離 する 開発（手動） リリース構成 本番/ステージング用 コンパイル結果をテンプレート化 する コンパイル（自動） ワークフロー構成 コンパイル結果を スケジュール実行 する 実行（自動） これらの機能を組み合わせることで、開発者は個別のサンドボックス環境で開発を進め、完成したコードを Git 経由で本番環境へ安全にデプロイし、定期実行する、といった一連のワークフローを Dataform 内で完結できます。 ワークスペースコンパイルオーバーライド 機能概要 ワークスペースコンパイルオーバーライド は、リポジトリ内のすべてのワークスペースに適用されるコンパイル設定の上書き機能です。主に、開発者ごとに独立した 開発環境を分離する ために使用します。 この機能を使うと、 workflow_settings.yaml （または dataform.json ）で定義されたデフォルト設定を、ワークスペースでの手動実行時に限り上書きできます。上書きできる設定は以下の3つです。 Google Cloud プロジェクト テーブルの接頭辞 スキーマの接尾辞 動的変数を使用できる点が特徴です。例えば、スキーマの接尾辞に ${workspaceName} と設定すると、 msasaki という名前のワークスペースで実行した際には、スキーマ名が （デフォルトスキーマ）_msasaki となります。 これにより、各開発者は他の開発者の作業に影響を与えることなく、自分専用のスキーマにテーブルやビューを作成して開発やテストができます。 設定方法 Dataform リポジトリの [設定] > [編集] をクリックします。 [ワークスペース コンパイル オーバーライド] ペインで、プロジェクト ID や接頭辞、接尾辞を設定します。 [保存] をクリックします。 注意点 ワークスペースコンパイルオーバーライドによって生成されたコンパイル結果は、あくまで開発時の手動実行を想定したものです。そのため、このコンパイル結果を スケジュール実行（後述のワークフロー構成）の対象にすることはできません 。 参考 : ワークスペース コンパイルのオーバーライドを構成する リリース構成 機能概要 リリース構成 は、リポジトリのコンパイル結果を作成するための設定をテンプレート化する機能です。本番環境（production）やステージング環境（staging）など、特定の実行環境向けの コンパイル結果を定義する ために使用します。 リリース構成では、 production や staging といった構成の一意な名前である リリース ID を定義します。そして、コンパイルの元となる Git のブランチやコミット SHA である Git Commitish を指定し、コンパイル結果を自動で再作成する 頻度 を設定します。 必要に応じて、Google Cloud プロジェクト ID、テーブルの接頭辞、スキーマの接尾辞などの コンパイルのオーバーライド も設定可能です。 例えば、「 main ブランチの最新のコードを元に、1時間ごとに本番環境（production）用のコンパイル結果を自動生成する」といった設定が可能です。ここで生成されたコンパイル結果が、後述するワークフロー構成による定期実行の対象となります。 この仕組みは、CI/CD パイプラインにおける「ビルド」のプロセスに相当します。 設定方法 Dataform リポジトリの [リリースとスケジュール] に移動します。 [製品版 リリースの作成]（または、[カスタム リリースの作成]） をクリックします。 リリースID、Git Commitish（ブランチ名など）、頻度、各種オーバーライド設定を入力し、 [作成] をクリックします。 参考 : リリース構成を作成する ワークフロー構成 機能概要 ワークフロー構成 は、リリース構成で作成されたコンパイル結果の 実行をスケジュールする ための機能です。 ワークフロー構成では、以下の項目を設定します。 リリース構成の選択 : どのリリース構成（例: production ）のコンパイル結果を実行するかを選択 実行するアクションの選択 : すべてのアクションを実行するか、特定のタグが付いたアクションのみを実行するかなどを選択 実行スケジュール : 実行頻度（日次、週次など）とタイムゾーン これにより、「毎日午前3時に、 production リリース構成で生成されたコンパイル結果を使って、 daily タグが付いたアクションを実行する」といった定期実行を構成できます。 この仕組みは、CI/CD パイプラインにおける「デプロイ」や「ジョブ実行」のプロセスに相当します。リリース構成とワークフロー構成を組み合わせることで、追加のサービス（Cloud Scheduler や Cloud Composer など）を使わずに、Dataform 内で完結した自動実行パイプラインを構築できます。 設定方法 Dataform リポジトリの [リリースとスケジュール] に移動します。 [ワークフロー構成] セクションで [作成] をクリックします。 実行対象のリリース構成、実行するアクション、スケジュールなどを設定し、 [作成] をクリックします。 参考 : ワークフロー構成を作成する 開発と管理 ライフサイクルの全体像 ここまで解説した3つの機能を組み合わせた、一般的な開発から本番実行までの流れは以下のとおりです。 1 開発フェーズ （個人のワークスペース） 開発者は、各自の ワークスペース で SQLX ファイルを開発・編集します。 ワークスペースコンパイルオーバーライド を利用して、個別のサンドボックス環境（例: msasaki スキーマ）で手動実行し、動作を確認します。 2 リリースフェーズ （Git とリリース構成） 開発が完了したコードを、Git リポジトリの main ブランチ（本番用）や staging ブランチ（ステージング用）にマージします。 リリース構成 がスケジュールに従い、 main ブランチから本番用のコンパイル結果を、 staging ブランチからステージング用のコンパイル結果をそれぞれ自動で作成します。 3 実行フェーズ （ワークフロー構成） ワークフロー構成 が、定義されたスケジュール（例: 毎日午前3時）になると、本番用のリリース構成によって作成された最新のコンパイル結果を BigQuery 上で実行します。 このように、各機能が明確な役割を担うことで、安全で再利用性の高いデータパイプラインのライフサイクル管理が実現されます。 ベストプラクティス Dataform で開発から本番までのワークフローを管理する際は、環境を分離することがベストプラクティスとされています。 開発環境では、本番データに影響を与えないよう「ワークスペースコンパイルオーバーライド」を活用して、各開発者が個別のスキーマで作業します。 一方、本番環境やステージング環境では、「リリース構成」と「ワークフロー構成」を組み合わせ、Git の特定ブランチを元にしたコンパイルと実行を自動化します。これにより、コードの変更が自動的に本番環境へ反映される、統制の取れたパイプラインを構築できます。 詳細は公式ドキュメントをご参照ください。 参考 : 分離された実行環境のベスト プラクティス 必要なロール Dataform でこれらの構成を管理するには、リポジトリに対して適切な IAM ロールが必要です。 ロール名（ロール ID） 説明 Dataform 管理者（ roles/dataform.admin ） リリース構成やワークフロー構成の作成・編集・削除などの管理操作に必要 ロールの付与に関する詳細は、公式ドキュメントをご参照ください。 参考 : 必要なロール リソースの有効期限 Dataform によって作成されるコンパイル結果やワークフローの実行履歴（呼び出し）には、有効期限が設定されています。 ワークフローの呼び出し実行履歴は、90日後に自動で削除されます。 コンパイル結果の有効期限は、その生成方法によって異なります。ワークスペースで開発中に生成されたものは24時間で失効します。リリース構成によって生成されたものは、新しいコンパイル結果が作成されると置き換えられ、最大24時間後に失効します。ワークフロー呼び出しで使われたコンパイル結果は、その呼び出しが有効な期間（最大90日）保持されます。 参考 : ライフサイクル リソースの有効期限 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の佐々木です。当記事では Firestore におけるデータベースのクローン機能を紹介します。 Firestore データベースのクローンとは 手順 ポイントインタイムリカバリの有効化 クローン作成（Google Cloud コンソール） クローン作成（gcloud CLI） Firestore データベースのクローンとは Firestore におけるデータベースの クローン 機能では、1つのデータベースを対象に、 同じプロジェクト 、 同じリージョン にデータベースのクローン（複製）を作成します。クローンによって作成されたデータベースには、ソースデータベース内の全てのデータ、インデックスがコピーされます。 データベースのクローンには ポイントインタイムリカバリ （PITR）が使用されます。ポイントインタイムリカバリが有効化されているデータベースでは、過去7日間の任意のタイミング（分単位）のコピーを作成することができます。 また、ポイントインタイムリカバリが有効化されていない場合は、過去1時間の任意のタイミング（分単位）のクローンを作成することができます。 デフォルトの動作では、クローンされたデータベースはソースデータベースと同じ方式の暗号化が使用されます。暗号化方式はデータベースのクローン時に Google 管理の暗号鍵 （Google のデフォルトの暗号化）と 顧客管理の暗号鍵 （CMEK）のいずれかを選択することができます。 Create and manage databases - Clone a database Point-in-time recovery (PITR) overview 手順 ポイントインタイムリカバリの有効化 過去1時間よりも前のクローンが必要な場合、あらかじめデータベースでポイントインタイムリカバリを有効化しておく必要があります。 ポイントインタイムリカバリの有効化はコンソールや gcloud CLI で可能です。 # Firestoreデータベースでポイントインタイムリカバリを有効化する $ gcloud firestore databases update \ --database =< データベース名 > \ --enable-pitr なお、ポイントインタイムリカバリを有効にすると、データベースのサイズに応じてポイントインタイムリカバリの料金が追加で発生します。 参考 : Work with point-in-time recovery (PITR) 参考 : gcloud firestore databases update 参考 : Firestore pricing クローン作成（Google Cloud コンソール） クローンの作成は Google Cloud コンソールまたは gcloud CLI から可能です。 コンソールを使用する場合、クローンで作成されたデータベースの暗号化方式を、ソースデータベースの暗号化方式から変更することはできません。 コンソールから作成する場合、対象のデータベースから、[クローンを作成] を選択します。 コンソールからデータベースのクローンを作成する 「クローンの作成」で、作成されるデータベースの ID と、クローン元となるデータベースの任意の時点を分単位で選択します。どの時点まで遡ってクローンできるかは「最も古いバージョンの時刻」として表示されています。 コピーする任意の時点を選択してクローンを作成する クローン作成（gcloud CLI） gcloud CLI を使用する場合、必要に応じて、どの時点までクローンを作成できるのか（「最も古いバージョンの時刻」）を確認します。 # データベースの「最も古いバージョンの時刻」を確認する $ gcloud firestore databases describe \ --database =" (default) " \ --format =" table(earliestVersionTime) " # 出力例（UTC） EARLIEST_VERSION_TIME 2025-08-20T13:22:00Z データベースのクローンは gcloud firestore databases clone コマンドで行います。 2025年10月現在では gcloud alpha コマンドを使用する必要があります。 $ gcloud alpha firestore databases clone \ --source-database =" projects/<プロジェクトID>/databases/<ソースデータベース名> " \ --snapshot-time =< クローンする時点のタイムスタンプ（RFC3339形式） > \ --destination-database =" <作成するデータベース名> " --snapshot-time には、RFC-3339形式でクローンする時点のタイムスタンプを指定します。コンソールと異なり、CLI では UTC でタイムスタンプを指定する点には注意が必要です。 # 実行例 $ gcloud alpha firestore databases clone \ --source-database =" projects/myproject/databases/(default) " \ --snapshot-time = 2025-08-20T13:22:00Z \ --destination-database =" default-clone " クローンで作成するデータベースの暗号化方式をソースデータベースから変更したい場合、 --encryption-type で暗号化方式（ google-default-encryption or customer-managed-encryption ）を、 --kms-key-name で使用する鍵の ID を指定します。 # 暗号化方式を変更してクローンする場合の実行例 $ gcloud alpha firestore databases clone \ --source-database =" projects/myproject/databases/(default) " \ --snapshot-time = 2025-08-20T13:22:00Z \ --destination-database =" default-clone " --encryption-type =' customer-managed-encryption ' \ --kms-key-name =' projects/myproject/locations/asia-northeast1/keyRings/my-key-ring/cryptoKeys/my-key ' 参考 : gcloud alpha firestore databases clone 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-genの杉村です。Vertex AI の API 経由で Gemini を呼び出す際に、 URL context tool を使って、明示的にスクレイピングをしなくても Web サイトの内容を取得してコンテキストとして利用する方法について解説します。 概要 URL context tool とは ユースケース サポートされているモデル 使用方法 URL context tool の検証 tools 不使用時との比較 Google Search tool との比較 Google Search tool との併用 概要 URL context tool とは URL context tool とは、Vertex AI の API 経由で Gemini を呼び出す際に、Web サイトの内容を取得してコンテキストとして利用できるようになるツールです。 本来、外部 Web サイトの内容を生成 AI のコンテキストとして使うためには、Web スクレイピング（プログラムでウェブサイトからデータを取得すること）を行うソースコードを記述して、Web サイトの内容を取得してから、プロンプトとしてモデルに読み込ませる必要があります。 URL context tool を使うと、そのようなスクレイピングプログラムを記述しなくても、Gemini が自動的に Web サイトのコンテンツを取得して、コンテキストとして利用してくれます。 参考 : URL context 同機能は、2025年8月現在で試験運用版（Experimental）の扱いです。一般提供（GA）されている機能ではないため、公式のサポート対象外であるほか、予告なく仕様が変更されたり廃止になる可能性があります。 また当記事の検証結果は、2025年8月現在の試験運用版（Experimental）の API を使用した結果であり、機能改善により結果や特性が変化する場合があることにご留意ください。 ユースケース URL context tool は、以下のようなユースケースに適しています。 Web 上の記事から重要なポイントを抽出する 複数のリンク間で情報を比較したり、統合する 特定のページの内容に基づいて質問に答える 特定の目的（職務記述書の作成やテスト問題の作成など）のためにコンテンツを分析する サポートされているモデル URL context tool は、以下のモデルで使用できます。 Gemini 2.0 Flash Gemini 2.5 Flash-Lite Gemini 2.5 Flash Gemini 2.5 Pro 使用方法 URL context tool は、以下の Python サンプルコードのように、tools として UrlContext を指定することで使用できます。 from google import genai from google.genai.types import Tool, GenerateContentConfig, HttpOptions, UrlContext client = genai.Client( http_options=HttpOptions(api_version= "v1" ), vertexai= True , project= "sugimura" , location= "global" , ) model_id = "gemini-2.5-flash" url_context_tool = Tool( url_context = UrlContext ) url_1 = "https://www.city.shinjuku.lg.jp/seikatsu/seiso01_001025.html" # 新宿区のごみ分別辞典 url_2 = "https://www.city.shinjuku.lg.jp/seikatsu/file09_01_00001.html" # 新宿区の町名別のごみ収集日一覧 contents = f """ パソコンのキーボードをゴミとして出したいです。 居住地域は、新宿区の揚場町です。 ゴミの区分は何で、収集日はいつですか？ 以下の URL を参考にしてください。 * 新宿区のごみ分別辞典: {url_1} * 新宿区の町名別のごみ収集日一覧: {url_2} """ response = client.models.generate_content( model=model_id, contents=contents, config=GenerateContentConfig( tools=[url_context_tool], response_modalities=[ "TEXT" ], ) ) # Generated contents print ( "===== content.parts =====" ) for each in response.candidates[ 0 ].content.parts: print (each.text) # URLs retrieved for context print ( " \n ===== url_context_metadata =====" ) print (response.candidates[ 0 ].url_context_metadata) URL context tool の検証 前述の Python コードを実行すると、以下のような結果になりました。 ===== content.parts ===== 新宿区揚場町にお住まいの場合、パソコンのキーボードは**金属・陶器・ガラスごみ**として出すことができます。 収集日は、その月の**第2・第4水曜日**です。 ===== url_context_metadata ===== url_metadata=[UrlMetadata( retrieved_url='https://www.city.shinjuku.lg.jp/seikatsu/seiso01_001025.html', url_retrieval_status=<UrlRetrievalStatus.URL_RETRIEVAL_STATUS_SUCCESS: 'URL_RETRIEVAL_STATUS_SUCCESS'> ), UrlMetadata( retrieved_url='https://www.city.shinjuku.lg.jp/seikatsu/file09_01_00001.html', url_retrieval_status=<UrlRetrievalStatus.URL_RETRIEVAL_STATUS_SUCCESS: 'URL_RETRIEVAL_STATUS_SUCCESS'> )] この生成結果は、実際に2025年8月現在の新宿区の Web サイトの記載内容と一致しています。 url_metadata として、実際にどの Web サイトからデータを取得してコンテキストとして利用したかが記録されています。 tools 不使用時との比較 Tools を使わない場合の実行結果と比較してみます。 （略） config=GenerateContentConfig( # tools=[url_context_tool], response_modalities=[ "TEXT" ], ) （略） 上記のように、コードから tools の指定をコメントアウトして実行すると、以下のような結果になりました。 ===== content.parts ===== パソコンのキーボードを新宿区揚場町でゴミとして出す場合、以下のようになります。 1. **ゴミの区分:** パソコンのキーボードは、通常「**不燃ごみ（燃えないごみ）**」として出すことができます。 * **注意点:** ただし、縦・横・高さの合計が30センチメートルを超える場合は「粗大ごみ」扱いとなります。一般的なサイズのキーボードであれば、不燃ごみで問題ありません。 2. **収集日:** 揚場町の不燃ごみの収集日は「**第2・第4火曜日**」です。 --- **まとめ:** * **区分:** **不燃ごみ** * **収集日:** **第2・第4火曜日** ===== url_context_metadata ===== None 上記は、事実とは異なる結果となっています。Web サイトがコンテキストとして与えられていないため、ハルシネーションが発生していることがわかります。 Google Search tool との比較 次に、比較のために Tools として Google Search tool（Google 検索でグラウンディングするツール）を指定して実行してみます。 from google import genai from google.genai.types import Tool, GenerateContentConfig, HttpOptions, UrlContext, GoogleSearch # GoogleSearch を追加で import （略） # Google Search tool を定義 google_search_tool = Tool( google_search=GoogleSearch ) （略） config=GenerateContentConfig( # tools=[url_context_tool], tools=[google_search_tool], # Google Search tool を使うよう指定 response_modalities=[ "TEXT" ], ) （略） Google Search tool が優位だったケース まずは、同じプロンプト（ごみの出し方に関する質問）で実行します。結果は、以下の通りでした。 ===== content.parts ===== 新宿区揚場町にお住まいの場合、パソコンのキーボードのゴミの区分と収集日は、キーボードのサイズによって異なります。 **1. ゴミの区分** パソコンのキーボードは、その大きさによって以下のいずれかに分類されます。 * **粗大ごみ**: キーボードの一辺の長さが30cmを超える場合、粗大ごみとなります。一般的なパソコンのキーボードは、この粗大ごみに該当することが多いです。粗大ごみとして出す場合、事前申し込みと手数料が必要です。 * **金属・陶器・ガラスごみ**: キーボードの一辺の長さが30cm以下の場合は、「金属・陶器・ガラスごみ」に分類されます。ただし、「硬質で厚さが5㎜以上のもの、30cm角 以上の大きさのものは対象外」という規定もあるため、小型のキーボードであっても形状によっては注意が必要です。 **2. 収集日** * **粗大ごみとして出す場合（一辺の長さが30cm超）** 粗大ごみは事前申し込み制で有料です。収集日は申し込み時に決定されます。 * **手数料**: パソコン用キーボードは1点につき400円です。 * **申し込み方法**: * **インターネット**: 新宿区粗大ごみ受付センターのウェブサイト（https://www.shinjuku-sodai.com）から24時間申し込み可能です。 * **電話**: 粗大ごみ受付センター（電話番号: 03-5304-8080）へ連絡してください。受付時間は月曜日から土曜日の午前8時から午後7時までです（年末年始を除く）。 * **金属・陶器・ガラスごみとして出す場合（一辺の長さが30cm以下）** 揚場町における「金属・陶器・ガラスごみ」の収集日は、**毎月第2・第4水曜日**です。 収集日の朝8時までに、決められた集積所に出してください。 ===== url_context_metadata ===== None これは、実際の Web サイトの掲載内容と同じ結果が返りました。むしろ、Google Search tool を使ったほうが詳細な結果が得られました。新宿区の Web サイトは、Google 検索でも容易に発見できる内容であったためと考えられます。 URL context tool が優位だったケース 次に、URL context tool の優位性が出るケースを検証するため、もう少し Google で検索しづらい複雑な内容を生成させてみます。 （略） # G-gen Tech Blog の Google Agentspace 解説記事 url_1 = "https://blog.g-gen.co.jp/entry/google-agentspace-explained" contents = f """ Google Agentspace において、Agentspace Enterprise ライセンスでは、ノーコードエージェントを開発することはできますか？ 以下の URL を参考にしてください。 {url_1} """ （略） まずは、URL context tool ではなく、Google Search tool を使った実行結果を見てみます。 ===== content.parts ===== はい、Google Agentspace の Enterprise ライセンスでは、ノーコードエージェントを開発できます。 Google Agentspace は、企業がAIエージェントを構築、管理、導入するための単一かつ安全なプラットフォームを提供しており、個人、チーム、そして企業全体の可能性を解き放つことを目指しています。Enterprise エディションは月額25ドルから利用可能です。 特に、**Agent Designer** というノーコードツールが提供されており、技術的な専門知識がなくてもカスタムAIエージェントを作成できます。このツールは、日常業務を自動化するエージェントを構築するために、直感的な会話型インターフェースを使用します。 検索結果では、**Agent DesignerはAgentspace Enterprise Plusエディションで利用可能である**と明記されています。Agent Designerを使用すると、プログラミングを必要としない自然言語の記述を使って、カスタムAIエージェントを作成できます。これらのノーコードエージェントは、Agentspace環境内で設定されたすべてのデータソースやツールと連携してワークフローを自動化します。 Google Cloud Next 2025で発表されたAgentspaceのAgent Designerは、ノーコードツールであり、ユーザーが繰り返し発生するタスクを支援するエージェントを構築できます。 したがって、Google AgentspaceのEnterpriseライセンス、特にEnterprise Plusエディションでは、ノーコードツールであるAgent Designerを使用してノーコードエージェントを開発することが可能です。 ===== url_context_metadata ===== None 上記の生成結果は、ハルシネーションを起こしています。実際には Enterprise ライセンスではノーコードエージェントの開発を行うことはできません。また、最後の文では Enterprise ライセンスと Enterprise Plus ライセンスは別々のものであるのにも関わらず、混同しています。 次に、同じプロンプトで URL context tool を使った結果を見てみます。 ===== content.parts ===== Google Agentspace の Agentspace Enterprise ライセンスでは、ノーコードエージェントを開発することはできません。 参照した記事の「ライセンス体系」の項目にある表によると、Agentspace Enterprise ライセンスには「ノーコードエージェント」の機能が含まれていないと明記されています。 ノーコードエージェントの作成機能を含むのは、最上位プランである Agentspace Enterprise Plus ライセンスです。 Agentspace Frontline ライセンスでは、ノーコードエージェントは配布物の利用のみに制限されます。 ===== url_context_metadata ===== url_metadata=[UrlMetadata( retrieved_url='https://blog.g-gen.co.jp/entry/google-agentspace-explained', url_retrieval_status=<UrlRetrievalStatus.URL_RETRIEVAL_STATUS_SUCCESS: 'URL_RETRIEVAL_STATUS_SUCCESS'> )] 今回は、解説記事の内容を正確に参照して、正しい答えが生成されました。 特定の Web サイトのコンテンツのみ に基づいて生成させたい場合は、URL context tool が優位であると考えられます。 Google Search tool との併用 URL context tool は、Google Search tool と併用することが可能です。これにより、特定の URL に加えて、インターネットから広く情報を収集してコンテンツを生成できます。 参考 : URL context - Grounding with Google Search with URL context Python の場合、ソースコードは以下のようになります。 from google import genai from google.genai.types import Tool, GenerateContentConfig, HttpOptions, UrlContext, GoogleSearch client = genai.Client( http_options=HttpOptions(api_version= "v1beta1" ), vertexai= True , project= "sugimura" , location= "global" , ) model_id = "gemini-2.5-flash" tools = [] tools.append(Tool(url_context=UrlContext)) tools.append(Tool(google_search=GoogleSearch)) url_1 = "https://www.serverworks.co.jp/corporate/about.html" # 株式会社サーバーワークスの会社概要ページ contents = f """ 株式会社 G-gen と、株式会社サーバーワークスの関係性を教えてください。 また、両社のビジョンを比較してください。 以下の URL を参考にしてください。 {url_1} """ response = client.models.generate_content( model=model_id, contents=contents, config=GenerateContentConfig( tools=tools, response_modalities=[ "TEXT" ], ) ) # Generated contents print ( "===== content.parts =====" ) for each in response.candidates[ 0 ].content.parts: print (each.text) # URLs retrieved for context print ( " \n ===== url_context_metadata =====" ) print (response.candidates[ 0 ].url_context_metadata) ポイントは、tools に辞書型で URL context tool と Google Search tool の両方を格納している点と、Client 生成時に api_version として v1beta1 を指定している点です。これらのツールの併用は、ベータ版の API でのみ提供されている点に注意してください。 今回はプロンプトとして、株式会社サーバーワークスと株式会社 G-gen の関係性やビジョンについて質問します。参考 URL として、株式会社サーバーワークスの会社概要ページのみを与えました。 出力結果は以下のようになりました。 ===== content.parts ===== 株式会社G-genと株式会社サーバーワークスの関係性、および両社のビジョンの比較は以下の通りです。 **株式会社G-genと株式会社サーバーワークスの関係性** 株式会社G-genは、株式会社サーバーワークスがGoogle Cloud™事業へ本格参入するために、2021年8月に設立した合弁会社です。サーバーワークスはG-genの親会社にあたります。 G-genは、サーバーワークスと、アジアトップクラスのクラウドベンダーであるBespin Global Inc.とのジョイントベンチャーとして設立されました。 2024年7月1日には、株式会社G-genと株式会社トップゲート（これもサーバーワークスのグループ会社でGoogle Cloudパートナー）が合併し、新生G-genとして事業を拡大しています。 **両社のビジョンの比較** 両社は全く同じビジョンを掲げています。 * **株式会社サーバーワークス**： 「クラウドで、世界を、もっと、はたらきやすく」 * **株式会社G-gen**： 「クラウドで、世界を、もっと、はたらきやすく」 この共通のビジョンは、「より多くの企業がクラウドによって競争力を高め、そこで働く従業員が『働きやすい環境になった』と思えるような社会にすること」を目指しています。 ただし、このビジョンを実現するための主要な手段と焦点が異なります。 * **株式会社サーバーワークス**は、主に**AWS（Amazon Web Services）**に特化したインテグレーション事業とサービスの提供を通じて、このビジョンの実現を目指しています。オンプレミス環境の運用負荷やコストを軽減し、企業の働き方をクラウドで進化させることを重視しています. * **株式会社G-gen**は、主に**Google Cloud™**および**Google Workspace**を専門とするクラウドインテグレーターとして、このビジョンの実現に取り組んでいます。Google Cloudが持つ生成AIやデータ分析などのユニークな技術を活用し、場所にとらわれない、高セキュリティでアジリティの高いITシステムの提供を通じて、顧客のDX（デジタルトランスフォーメーション）とビジネス成功を支援することを目指しています。また、サーバーワークスのAWSノウハウと連携し、マルチクラウド環境でのカスタマーサクセスも提供しています。 ===== url_context_metadata ===== url_metadata=[UrlMetadata( retrieved_url='https://www.serverworks.co.jp/corporate/about.html', url_retrieval_status=<UrlRetrievalStatus.URL_RETRIEVAL_STATUS_SUCCESS: 'URL_RETRIEVAL_STATUS_SUCCESS'> )] 上記の結果には、コンテキストとして与えていない株式会社 G-gen のビジョンや沿革についての情報が含まれています。 この結果から、コンテキストとして与えた URL の情報と、Google 検索から得た情報の両方をコンテキストとして結果が生成されたことがわかります。 ここに全文は掲載しませんが、 response の全文を確認すると、URL context tool と Google Search tool の両方が使用されたことが確認できました。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの西田です。当記事では、Gemini CLI での対話だけで、To Do タスクを管理するWebアプリケーションの開発手順を紹介します。 はじめに 当記事について 開発ステップ Gemini CLI の起動 要件定義と開発計画の決定 アプリケーションの開発 開発の開始 動作確認 アプリケーションの修正 はじめに 当記事について 当記事では、Webアプリケーションの開発経験が無い方でも、Gemini CLI を利用して To Do タスクを管理するWebアプリケーションを開発する際の進め方をご紹介します。 前編では、アプリケーションの基本的な動作や画面を確認できるプロトタイプを作成することを目的として、Gemini を利用した要件定義から始めて、ローカル環境で動作確認を行うレベルの開発を実施していきます。 この記事では、Gemini CLI や Cloud Shell などを活用し、Web ブラウザだけで要件定義から開発までを一気通貫に行うことを目指します。 Gemini CLI とは、ターミナルから直接 Gemini の機能を利用できるオープンソースのコマンドラインインターフェイスです。詳しくは以下の記事をご覧ください。 blog.g-gen.co.jp Cloud Shell とは、Google Cloud コンソール上で起動する仮想的な Linux ターミナルです。コードエディタも付属しており、Web ブラウザだけで開発を完結させることができます。以下の記事も参考にしてください。 blog.g-gen.co.jp 開発ステップ Gemini CLI で開発を行う際、以下のステップを踏むことで開発をスムーズに進めることができました。 Gemini を壁打ち相手としながら、開発したいアプリケーションの要件定義を行う 壁打ちで決まった要件定義の内容と、開発計画を別のファイルに切り出して管理するよう指示する 要件定義と開発計画のファイルを参照しながらの開発を指示する。開発の進捗は開発計画ファイルに都度記録する アプリケーション画面や動作を確認し、必要があれば機能追加や修正を指示する。その際、要件定義や開発計画ファイルも更新する 開発の初心者にとって特に便利なのは、1つ目の要件定義を Gemini と相談しながら進められる点です。 要件定義に協力してほしい旨のプロンプトを入力するだけで、実装する機能や使用する技術スタックについてなど、必要な要件について質問されるので、それに答えることで要件を決めていくことができます。 また、2つ目の要件定義と開発計画をファイルに切り出して管理しておくことも有効でした。開発作業を一旦中断した後に途中から再開する場合や、最初に決めた要件を変更する際などに、これらのファイルを読み込んでからアクションを実施するように指示することができます。 いずれのステップも Gemini に「要件定義の内容をファイルに切り出して」というような自然言語の指示を出すことで処理が実行されるので、簡単に進めることができます。 Gemini CLI の起動 Google Cloud コンソールにアクセスし、アプリケーションを開発するプロジェクトを選択したら、画面右上の [Cloud Shell をアクティブにする] アイコンをクリックします。 ターミナルが起動したら、 [エディタを開く] をクリックします。 エディタ画面の左上の [Terminal] タブの中の [New Terminal] を選択します。 以下のコマンドを実行して、アプリケーション開発用のディレクトリの作成とカレントディレクトリの移動を行います。 mkdir todo-app-demo cd todo-app-demo 開発用ディレクトリの準備が完了したら、 gemini とコマンドを入力して、Gemini CLI を起動します。 以下のような画面が立ち上がれば成功です。 要件定義と開発計画の決定 アプリケーション開発の最初のステップとして、Gemini を活用して要件定義と開発計画の策定を実施します。 まずは以下のようなプロンプトを入力します。 To Do タスクの管理を行うWebアプリケーションを開発します。要件定義の壁打ち相手になってください。 アプリケーションを開発していく上で、必要な要件を抜け漏れがないように洗い出してください。 まずは画面や動作確認を実施するため、ローカルで動作する構成で開発します。 なおプロンプトは、「Type your message or @path/to/file」と記載されている入力欄から送信します。 プロンプトを送信後、基本機能や画面構成についてなどについての以下のような提案が返ってくるので、自然言語で対話しながら要件を詰めていきます。 ✦ 承知いたしました。ToDoアプリケーションの要件定義、一緒に進めていきましょう。 まずはアプリケーションに必要な最小限の機能を洗い出してみました。抜け漏れや、追加したい項目がないかご確認ください。 --- ToDoアプリケーション 要件定義（案） 1. 基本機能（タスク管理） * タスクの作成 * タスクのタイトルを入力して新しいタスクを追加できる。 * (オプション) タスクの詳細な説明メモを追加できる。 * (オプション) タスクの期限日を設定できる。 * タスクの一覧表示 * 登録したタスクが一覧で表示される。 * 各タスクの「完了／未完了」の状態がわかる。 * タスクの更新 * タスクのタイトルや詳細、期限を編集できる。 * タスクを「完了」状態に変更できる。（チェックボックスなど） * 完了したタスクを「未完了」に戻せる。 * タスクの削除 * 不要になったタスクを削除できる。 2. 画面構成 * メイン画面 * タスクの入力フォーム * タスク一覧 * (オプション) 未完了／完了済みタスクを切り替えて表示するフィルタ 3. 非機能要件（今回はローカル動作が前提） * データ永続化 * ブラウザを閉じてもタスクが消えないように、データをローカルに保存する。（例: ブラウザのローカルストレージ、ローカルファイルなど） * UI/UX * 直感的に操作できるシンプルなデザインにする。 --- いかがでしょうか？ 特に、タスクに「優先度（高・中・低など）」や「カテゴリ（仕事・プライベートなど）」といった情報を追加したい、などのご 要望はありますか？ まずはこの内容で進めて、開発の途中で必要になった機能を追加していく形でも良いかと思います。 今回は、上記の提案に対し、以下のプロンプトを返して要件定義を進めていきます。 基本機能と画面構成については、提案通りの内容で異論ありません。 データの保存については、 MySQL を使用してください。 Gemini とのやり取りを通じて要件定義の内容が固まったら、ステップの2つ目である要件定義、開発計画の内容を別ファイルに切り出します。 ファイルを切り出して記録することで、作業を途中から再開する際や、要件定義の内容を変更する場合に、これらのファイルを読み込んでからアクションをするように指示することができます。 プロンプト例は以下の通りです。 開発を進める前に、要件定義の内容と開発計画の内容を別のファイルに切り出して、出来るだけ詳細に記録してください。 また、開発計画を記録するファイルで開発作業の進捗も管理できるようにしてください。 ファイルは新しく「docs」というフォルダを作成して、その中に保存してください。 要件定義の内容がまとめられた requirements.md は以下の通りです。 # ToDoアプリケーション 要件定義書 ## 1. 概要 本ドキュメントは、ToDoタスク管理アプリケーションの要件を定義する。 このアプリケーションは、ユーザーが日々のタスクを効率的に管理することを目的とする。 ## 2. データモデル アプリケーションで扱うタスク（Todo）は、以下のデータ項目で構成される。 - **id**: ` Integer ` , 主キー, 自動採番 - **title**: ` String(200) ` , タスクのタイトル, **必須** - **description**: ` Text ` , 詳細な説明, 任意 - **due_date**: ` Date ` , 期限日, 任意 - **completed**: ` Boolean ` , 完了状態 (True: 完了, False: 未完了), デフォルト: ` False ` - **created_at**: ` DateTime ` , 作成日時, 自動記録 - **updated_at**: ` DateTime ` , 更新日時, 自動記録 ## 3. 機能要件 ### 3.1. タスク作成機能 - ユーザーはタスクのタイトルを入力して、新しいタスクを作成できる。 - タイトルは必須入力とし、空の場合は登録できず、エラーメッセージを表示する。 - オプションとして、詳細な説明と期限日を設定できる。 - タスク作成後、ユーザーはタスク一覧画面にリダイレクトされる。 ### 3.2. タスク一覧表示機能 - 登録されているすべてのタスクを一覧で表示する。 - デフォルトの表示順は **作成日時の降順（新しいものが上）** とする。 - 完了済みのタスクは、未完了のタスクと視覚的に区別できるように表示する（例: タイトルに取り消し線、背景色を変更）。 - (将来的な拡張) 「すべて」「未完了」「完了済み」の状態でタスクをフィルタリングして表示する機能。 ### 3.3. タスク更新機能 - **状態の更新**: - 一覧画面上のチェックボックスをクリックすることで、タスクの「完了」「未完了」を即座に切り替えられる。 - **内容の編集**: - 各タスクに編集ボタンを設け、クリックすると編集ページに遷移する。 - 編集ページでは、タイトル、詳細、期限日を変更できる。 - 更新後、タスク一覧画面にリダイレクトされる。 ### 3.4. タスク削除機能 - 各タスクに削除ボタンを設ける。 - 削除ボタンをクリックすると、「本当に削除しますか？」という確認ダイアログを表示する。 - 「OK」を選択した場合、タスクをデータベースから削除し、一覧画面を更新する。 ## 4. 画面仕様 ### 4.1. メイン画面（タスク一覧） - **ヘッダー**: - アプリケーションのタイトル（例: "ToDo App"）を表示する。 - **タスク追加フォーム**: - タイトル入力用のテキストフィールド ( ` <input type="text"> ` ) - 追加ボタン ( ` <button type="submit"> ` ) - **タスク一覧**: - タスクが存在しない場合、「登録されているタスクはありません」というメッセージを表示する。 - 各タスクは以下の要素で構成される: - 完了状態を示すチェックボックス - タスクのタイトル - 期限日（設定されている場合） - 編集ボタン - 削除ボタン ### 4.2. 編集画面 - 選択したタスクの現在の内容（タイトル、詳細、期限日）がフォームに設定された状態で表示される。 - 更新ボタンと、一覧に戻るためのキャンセル（または戻る）リンクを配置する。 ## 5. 非機能要件 ### 5.1. URL設計 - ` GET / ` : タスク一覧ページ - ` POST /add ` : 新規タスク作成処理 - ` POST /update/<int:id> ` : タスク完了状態の更新処理 - ` POST /delete/<int:id> ` : タスク削除処理 - ` GET /edit/<int:id> ` : 編集ページの表示 - ` POST /edit/<int:id> ` : タスク内容の更新処理 ### 5.2. データ永続化 - すべてのタスクデータは **MySQL** データベースに永続化する。 ### 5.3. ユーザビリティ - 直感的で、最小限の操作でタスク管理ができるシンプルなUIを提供する。 ### 5.4. エラーハンドリング - データベース接続失敗など、システムレベルのエラーが発生した場合は、汎用的なエラーページを表示する。 - ユーザーの入力エラー（例: タイトルが空）については、フォームの近くにエラーメッセージを表示する。 開発計画が記録される development_plan.md は以下の通りです。 # ToDoアプリケーション 開発計画書 ## 1. 進捗サマリー - [ ] フェーズ1: 基盤構築 - [ ] フェーズ2: 機能実装 - [ ] フェーズ3: 仕上げ ## 2. 技術スタック - **Webフレームワーク**: Python / Flask - **データベース**: MySQL - **DB接続ライブラリ (ORM)**: Flask-SQLAlchemy - **テンプレートエンジン**: Jinja2 - **開発環境**: Docker (MySQL), Python venv ## 3. プロジェクト構成 . ├── docs/ │ ├── development _ plan.md │ └── requirements.md ├── static/ │ └── css/ │ └── style.css ├── templates/ │ ├── base.html │ ├── index.html │ └── edit.html ├── venv/ ├── .gitignore ├── app.py ├── docker-compose.yml └── requirements.txt ## 4. 開発タスク詳細 ### フェーズ0: 計画 (完了) - [x] 要件定義 ( ` docs/requirements.md ` ) - [x] 開発計画策定 ( ` docs/development_plan.md ` ) ### フェーズ1: 基盤構築 - [ ] **1. 環境構築** - [ ] ` docker-compose.yml ` の作成 - [ ] ` requirements.txt ` の作成 - [ ] ` docker-compose up -d ` でMySQLコンテナを起動する - [ ] ` python3 -m venv venv ` で仮想環境を作成し、アクティベートする - [ ] ` pip install -r requirements.txt ` で必要なライブラリをインストールする - [ ] **2. Flaskアプリケーション初期化 (`app.py`)** - [ ] Flaskアプリのインスタンスを作成する - [ ] SQLAlchemyのデータベース接続設定を行う - [ ] SQLAlchemyのインスタンスを初期化する - [ ] **3. データモデル定義 (`app.py`)** - [ ] ` Todo ` モデルクラスを定義する - [ ] **4. データベーステーブル作成** - [ ] ` flask shell ` 等で ` db.create_all() ` を実行し、テーブルを作成する ### フェーズ2: 機能実装 - [ ] **5. HTMLテンプレートの骨格作成 (`templates/`)** - [ ] ` base.html ` の作成 - [ ] ` index.html ` の作成 - [ ] ` edit.html ` の作成 - [ ] **6. タスク一覧表示・追加機能の実装 (`app.py`, `templates/index.html`)** - [ ] ルーティング ( ` GET / ` ) の実装 - [ ] テンプレート ( ` index.html ` ) でのタスク一覧表示 - [ ] テンプレート ( ` index.html ` ) でのタスク追加フォーム作成 - [ ] ルーティング ( ` POST /add ` ) の実装 - [ ] **7. タスク状態更新・削除機能の実装 (`app.py`, `templates/index.html`)** - [ ] ルーティング ( ` POST /update/<int:id> ` ) の実装 - [ ] ルーティング ( ` POST /delete/<int:id> ` ) の実装 - [ ] テンプレート ( ` index.html ` ) での更新・削除ボタンの実装 - [ ] **8. タスク編集機能の実装 (`app.py`, `templates/edit.html`)** - [ ] ルーティング ( ` GET /edit/<int:id> ` ) の実装 - [ ] テンプレート ( ` edit.html ` ) での編集フォーム作成 - [ ] ルーティング ( ` POST /edit/<int:id> ` ) の実装 ### フェーズ3: 仕上げ - [ ] **9. スタイリングと微調整** - [ ] CSS ( ` static/css/style.css ` ) の作成と適用 - [ ] Flaskのflashメッセージ機能等でエラー表示を実装 - [ ] 総合テストとデバッグ アプリケーションの開発 開発の開始 要件定義と開発計画の確認を終えて開発の準備が完了したら、以下のようなプロンプトで開発を開始していきます。 前述の参考ステップ3の通り、要件定義と開発計画を記載したファイルを読み込ませた上で、開発作業を進めるよう指示します。 @docs/requirements.md と @docs/development_plan.md の内容に従って、アプリケーション開発を進めてください。 このように、@マークの後にファイルのパスを記述することで、Gemini に参照してほしいファイルを指示することができます。 Gemini がファイルの作成や更新を実施する前には「〇〇を作成します。よろしいですか？」といったように作業内容を確認されます。 その処理内容に対するリアクションを選択肢の中から選びます。上下の矢印キーで選択肢を切り替えて、Enterを押すことで選択できます。 以降は、Gemini が開発計画に従って処理を進めてくれるので、処理内容の確認に対して都度リアクションを行います。当記事の執筆にあたっては、Gemini から提案された作業内容に対して全て「Yes, allow once」で答えて進めています。 また作業の途中で、以下のように作業進捗を記録する指示を入力して development_plan.md を更新することで、完了した作業を記録することも効果的です。上記の開発計画の中では、各フェーズが完了するたびに、以下のプロンプトを入力しました。 ここまでの作業内容を、@development_plan.md に記録してください。 動作確認 開発計画の作業が最後まで完了したら、ローカルでアプリケーションを起動して画面や動作を確認します。 アプリケーションをローカルで起動してください。 筆者の環境では、 http://127.0.0.1:5000 にアクセスするように促されましたので、アクセスして確認を進めます。 初期画面 タスクを追加後 タスクの編集画面 完了チェックをオン To Do 管理のアプリケーションとしては、まだまだ機能追加が必要ですが、要件として定義していた最低限の機能は想定通りに動作することが確認できました。 アプリケーションの修正 今後、機能を追加する場合を想定して、以下のような指示を出してみます。 追加の機能要件として、タイトルに含まれている文言からタスクを検索する機能を加えてください。 また、その内容を @requirements.md と @development_plan.md に追記してください。 Gemini によるコード修正後、無事に検索ワードの入力欄が追加されていることと、検索ワードによるフィルタリングが機能していることが確認できました。 西田 匡志 (記事一覧) クラウドソリューション部ソリューションアーキテクト課 美容商社→物流→情シスを経て、2025年6月G-genにジョイン。Google Cloud を通じて多くの人に貢献できるよう日々精進！

G-gen の佐々木です。当記事では Cloud Run における環境変数の設定について解説します。 Cloud Run の環境変数 仕様 暗黙的な環境変数 Dockerfile と重複して定義した場合 環境変数の設定方法 コンソール gcloud CLI --set-env-vars オプション --update-env-vars オプション --env-vars-file オプション 環境変数の削除 YAML ファイル Terraform シークレットのマウント Cloud Run の環境変数 仕様 Cloud Run では、Cloud Run 側の設定項目としてコンテナに環境変数を設定することができます。 Cloud Run 側に設定した環境変数は、コンテナ上で実行するアプリケーションから利用することができます。これは、Dockerfile の ENV から設定した環境変数の挙動と似ています。 環境変数は 最大1000個 まで設定することができ、変数の最大長として 32kb の制限があります。 環境変数のキーには「空の文字列」、「 = を含む文字列」、「 X_GOOGLE_ から始まる文字列」は使用できません。 当記事では Cloud Run services を例として解説しますが、環境変数の設定に関する基本的な仕様は Cloud Run jobs 等、その他の実行モデルでも同様です。 参考 : Configure containers for services （Cloud Run services） 参考 : Configure environment variables for job （Cloud Run jobs） 参考 : Configure environment variables for worker pools （Cloud Run worker pools） 暗黙的な環境変数 Cloud Run では、コンテナに対していくつかの環境変数が自動的に設定されます。 たとえば Cloud Run services では、 K_REVISION 環境変数に実行中のリビジョンの名前が格納されています。また Cloud Run jobs では CLOUD_RUN_TASK_INDEX 環境変数に並列実行されるタスクのインデックスが格納されています。 その他、暗黙的に設定される環境変数のリストについては、以下のドキュメントを参照してください。 参考 : Container runtime contract - Environment variables 参考 : Configure environment variables for services - Best practices - Additional reserved environment variables when deploying functions Dockerfile と重複して定義した場合 前述したように、Cloud Run で設定できる環境変数は、Dockerfile の ENV で設定した環境変数と同様の方法でアクセスできますが、もし Cloud Run 側の設定項目と Dockerfile の ENV で同じキーを持つ環境変数を設定した場合、 Cloud Run 側の設定項目の値が優先 されます。 Dockerfile 側ではコンテナから使用する環境変数のデフォルト値を設定し、Cloud Run 側の設定で必要に応じて上書きするといった使い方ができます。 環境変数の設定方法 コンソール デプロイ方法を問わず、Cloud Run では作成時および更新時に環境変数を設定することができます。 コンソールの場合、コンテナの設定項目として「変数とシークレット」があるため、ここで環境変数の Key/Value を設定します。 コンソールから環境変数を設定する gcloud CLI --set-env-vars オプション gcloud CLI では、 gcloud run deploy コマンドや gcloud run services update コマンドなどで --set-env-vars オプションを使用することで環境変数を設定することができます。 # gcloud CLI で環境変数を設定する $ gcloud run deploy < サービス名 > --image < コンテナイメージ > \ --set-env-vars key1 =value1, key2 =value2 # 複数設定する場合は,（カンマ）で区切る # サービスの更新時に設定する場合 $ gcloud run services update < サービス名 > \ --set-env-vars key1 =value1, key2 =value2 --set-env-vars オプションは、指定した環境変数のリストで現在 Cloud Run に設定されている環境変数を 上書き します。したがって、Cloud Run を更新するときに、現在設定されている環境変数に加えて新たな別の環境変数を設定したい場合、 --set-env-vars オプションには「 現在設定されている環境変数 」と「 新たに設定する環境変数 」を 合わせたリスト を渡す必要があります。 たとえば、環境変数として既に key1=value1 が設定されている Cloud Run に対して新たに key2=value2 の環境変数を追加したい場合、 --set-env-vars key2=value2 ではなく --set-env-vars key1=value1,key2=value2 と記述します。 また、環境変数を複数設定するときは key=value を , （カンマ）区切りに記述しますが、もし , を環境変数の値として使用したい場合は、以下の例のように @ などの別の文字を区切り文字として使用することができます。 # 値に,（カンマ）を含む環境変数を設定する $ gcloud run deploy < サービス名 > --image < コンテナイメージ > \ --set-env-vars " ^@^key1=value1,value11,value111@key2=value2,value22,value222 " $ gcloud run deploy < サービス名 > --image < コンテナイメージ > \ --set-env-vars " ^:^key1=value1,value11,value111:key2=value2,value22,value222 " $ gcloud run deploy < サービス名 > --image < コンテナイメージ > \ --set-env-vars " ^--^key1=value1,value11,value111--key2=value2,value22,value222 " gcloud CLI でカンマを含む環境変数を設定する 参考 : gcloud run deploy 参考 : gcloud run services update 参考 : gcloud topic escaping --update-env-vars オプション 環境変数は、前述の --set-env-vars オプションの他に --update-env-vars を利用して設定することもできます。 --update-env-vars オプションでは、追加・変更したい環境変数のみを指定することができるため、あとから環境変数を追加するケースではこちらを使用したほうが安全でしょう。 $ gcloud run services update dotenv \ --update-env-vars key1 =value100 # 追加・変更したい環境変数だけ指定できる 参考 : Configure environment variables for services - Update environment variables --env-vars-file オプション Cloud Run のデプロイ時にローカルにある .env ファイルの内容を環境変数として設定することもできます。 $ gcloud beta run deploy < サービス名 > --image =< コンテナイメージ > \ --env-vars-file =< .envファイルのパス > # .env のあるパスを指定する .env ファイルは以下のような key=value の形式で記述します。 key1=value1 key2=value2 参考 : Configure environment variables for services - Set multiple environment variables using the .env file 環境変数の削除 環境変数の削除には、 --remove-env-vars オプションと --clear-env-vars オプションが利用できます。 --remove-env-vars オプションでは、指定したキーの環境変数を削除します。 # 指定した環境変数のみ削除する（カンマ区切りで複数指定も可能） $ gcloud run services update < サービス名 > \ --remove-env-vars key1 --clear-env-vars オプションでは、設定されている全ての環境変数を削除します。 # 全ての環境変数を削除する $ gcloud run services update < サービス名 > \ --clear-env-vars 参考 : Configure environment variables for services - Delete environment variables YAML ファイル YAML ファイルを使用して Cloud Run をデプロイする場合、以下のように spec.template.spec.containers の env 属性として環境変数を設定します。 apiVersion : serving.knative.dev/v1 kind : Service metadata : name : <サービス名> spec : template : spec : containers : - image : <コンテナイメージ> env : - name : key1 value : value1 - name : key2 value : value2 Terraform Terraform で環境変数を設定する場合は以下のような記述となります。 # Cloud Run services の場合 resource "google_cloud_run_v2_service" "this" { project = var.project_id name = var.name location = var.location template { containers { image = var.image # 環境変数を設定する env { name = "key1" value = "value1" } env { name = "key2" value = "value2" } } } deletion_protection = var.deletion_protection } 上記の場合、環境変数1つにつき template.containers.env を1つ記述する必要があるため、環境変数を多数設定する必要がある場合、Terraform の記述が冗長になってしまいます。 実際には、以下のように dynamic ブロックと for_each を併用するなどして、変数として渡された環境変数の数だけブロック動的に生成するとよいでしょう、 # Cloud Run services の場合 resource "google_cloud_run_v2_service" "this" { project = var.project_id name = var.name location = var.location template { containers { image = var.image # key/valueが変数として渡されている場合、渡された数だけ繰り返し設定する # 渡されていない場合は何も設定しない dynamic "env" { for_each = coalesce (var.env_vars, {} ) content { name = env.key value = env.value } } } } deletion_protection = var.deletion_protection } 上記のように記述した場合、 variables.tf に定義する変数は以下のように記述します。 # variable.tf（抜粋） variable "env_vars" { type = map ( string ) default = {} } シークレットのマウント Cloud Run では、Secret Manager に格納した機密情報（シークレット）をマウントすることで、環境変数と同様の方法でシークレットの値にアクセスすることができます。 参考 : サービスのシークレットを構成する （Cloud Run services） 参考 : ジョブのシークレットを構成する （Cloud Run jobs） 詳細は以下の記事を参考にしてください。 blog.g-gen.co.jp 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の min です。Google Workspace の Google フォームでは、回答数が上限に達するとリンク先の Google スプレッドシートへデータが同期されなくなることがあります。本記事では、その原因と対処法を解説します。 事象 原因 対処法 その他の上限 事象 本件では、Google フォームで収集した回答を、Google スプレッドシートで集計・分析していました。 フォームへの回答数が10万件を超えたあたりから、新しい回答がスプレッドシートに追記されなくなり、データが同期されない事象が発生しました。 また、同時期にフォームの管理画面で以下の警告が表示されるようになりました。 レスポンスが 10 万件を超えると、リンクされたスプレッドシートは同期されなくなります。 事象の切り分けのため、リンク先の Google スプレッドシートから古い回答データを削除したり、スプレッドシートとのリンクを一度解除して再接続したりしましたが、事象は解消しませんでした。 原因 この事象は、Google フォームに定められている 利用上限 に起因します。 Google の公式ドキュメントには、フォームの安定的な利用を担保するための上限値が記載されています。その中の一つに、スプレッドシートとの連携に関する上限があります。 フォームの回答がスプレッドシートと同期されない場合は、フォームの回答数が 100,000 件を超えている可能性があります。 参考 : フォームの回答数の上限の詳細 この上限は、リンク先の Google スプレッドシートが保持できる行数やセル数の上限とは独立した、 Google フォーム自体が保持する回答データに対する上限 です。 そのため、リンク先の Google スプレッドシートのデータを削除しても、根本原因であるフォーム側の回答データが上限に達している状態は変わらず、同期が再開されることはありません。 対処法 Google フォーム側に蓄積された回答データを削除することで、事象を解消できます。 操作の前に、失われるデータを保護するため、まず 既存の回答をエクスポートしてバックアップする ことを強く推奨します。回答データは、フォームの「回答」タブから CSV ファイルとしてダウンロードできます。 バックアップを取得したあと、以下の手順でフォームの回答を削除します。 対象の Google フォームを編集画面で開きます。 画面上部の「回答」タブをクリックします。 画面右上にある「回答のその他アイコン」（︙）をクリックします。 メニューから「 すべての回答を削除 」を選択します。 確認のダイアログが表示されるので、内容を確認して「OK」をクリックします。 この操作により、Google フォームに保存されているすべての回答データが削除され、内部的なカウンタがリセットされます。その後、新しい回答がフォームに送信されると、スプレッドシートとの同期が正常に再開されます。 なお、Google フォームではなく Google スプレッドシート自体にも、1,000 万セルまたは 1 万 8,278 列までという上限があります。 参考 : Google ドライブに保管可能なファイル 今後も同じフォームを継続して利用する場合は、回答数がフォームの上限に達する前に、定期的にデータをエクスポートし、フォーム上の回答を削除する運用をご検討ください。 その他の上限 本記事で解説した回答数の上限以外にも、Google フォームには質問数やファイルアップロード容量などの上限が定められています。詳細は以下の公式ドキュメントをご参照ください。 参考 : フォームの回答数の上限の詳細 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の高宮です。Google Apps Script（GAS）を用いた Google カレンダーの自動化について解説します。特に、土日祝日や会社休日を考慮した月の第1営業日や最終営業日といった、変則的な日付への定期的な予定追加に焦点を当てます。 はじめに 概要 Google Apps Script（GAS）とは 新しい GAS プロジェクトの作成 営業日計算処理 実装 動作確認 第1営業日のイベント登録処理 実装 動作確認 最終営業日のイベント登録処理 はじめに 概要 Google カレンダー では月ごとの繰り返しの予定を、「毎月25日」や「毎月第3金曜日」などの形式で作成することはできます。しかし、土日祝日・会社休日などを考慮した会社営業日での定期的なスケジュール作成を簡単に行うことはできません。 会社の業務では、月の第1営業日に前月の勤怠の締め作業を依頼したり、月の最終営業日に経費精算の申請をするなどのケースがあります。そのような場合に、手間をかけずに Google カレンダーに定期的な予定を作成したいです。 当記事では、GAS を使用して、土日祝日・会社休日を考慮し、月の第1営業日や最終営業日に Google カレンダーに定期的な予定を追加する具体的な方法を解説します。 Google Apps Script（GAS）とは Google Apps Script （GAS）は、Google Workspace と統合されたアプリケーションを簡単に作成できるアプリケーション開発プラットフォームです。JavaScript でコードを記述し、Gmail、カレンダーなどの Google Workspace アプリ用の組み込みライブラリを使用できます。 参考 : Google Apps Script の概要 参考 : Google Apps Script (GAS) カテゴリーの記事一覧 - G-gen Tech Blog 新しい GAS プロジェクトの作成 以下の URL にアクセスすると、 Apps Script ダッシュボードが表示されます。 https://script.google.com/ 新しいプロジェクト 作成ボタンを押下すると、新しい GAS プロジェクトを作成できます。 営業日計算処理 実装 プロジェクトにファイル date_utils.gs を作成し、第1営業日と最終営業日を計算する処理を実装します。今回の例では、土日、祝日と年末年始に休暇がある会社を想定しています。 /** * 会社休日（月/日形式の文字列配列） * この配列に、固定の会社休日を追加できます。 */ const COMPANY_HOLIDAYS = [ '12/30' , '12/31' , '1/1' , '1/2' , '1/3' , '1/4' ] ; /** * 日本の祝日カレンダーを取得します。 * 繰り返し呼び出されるのを防ぐため、一度だけ取得してキャッシュします。 */ const JAPANESE_HOLIDAY_CALENDAR = CalendarApp . getCalendarById ( 'ja.japanese#holiday@group.v.calendar.google.com' ) ; /** * 指定された日付が休日かどうかを判定します。 * @param {Date} date - 判定対象の日付オブジェクト。 * @return {boolean} - 休日の場合は true、営業日の場合は false を返します。 */ function isHoliday ( date ) { // 1. 土曜日（6）または日曜日（0）か判定 const day = date . getDay () ; if ( day === 0 || day === 6 ) { return true ; } // 2. 日本の祝日か判定 const events = JAPANESE_HOLIDAY_CALENDAR . getEventsForDay ( date ) ; if ( events . length > 0 ) { return true ; } // 3. 会社休日か判定 const month = date . getMonth () + 1 ; // getMonth()は0始まりのため+1 const dateOfMonth = date . getDate () ; const dateString = ` ${ month } / ${ dateOfMonth } ` ; if ( COMPANY_HOLIDAYS . includes ( dateString )) { return true ; } // 上記のいずれにも該当しない場合は営業日 return false ; } /** * 指定された年月の第1営業日を取得します。 * @param {number} year - 年（例: 2025）。 * @param {number} month - 月（1〜12）。 * @return {Date} - 第1営業日の日付オブジェクト。 */ function getFirstBusinessDay ( year , month ) { // 指定された月の1日を開始日として設定 const date = new Date ( year , month - 1 , 1 ) ; // 月は0始まりのため-1 // 休日でなくなるまで日付を1日ずつ進める while ( isHoliday ( date )) { date . setDate ( date . getDate () + 1 ) ; } return date ; } /** * 指定された年月の最終営業日を取得します。 * @param {number} year - 年（例: 2025）。 * @param {number} month - 月（1〜12）。 * @return {Date} - 最終営業日の日付オブジェクト。 */ function getLastBusinessDay ( year , month ) { // 指定された月の末日を開始日として設定 const date = new Date ( year , month , 0 ) ; // 翌月の0日目を指定すると、その月の末日が取得できる // 休日でなくなるまで日付を1日ずつ遡る while ( isHoliday ( date )) { date . setDate ( date . getDate () - 1 ) ; } return date ; } ここでは、Google カレンダーで提供されている「日本の祝日」カレンダーから祝日の情報を取得するため、 CalendarApp クラスを使用しています。 参考 : Class CalendarApp 動作確認 新しいファイル コード.gs に以下の処理を実装し、 main 関数を実行し営業日の計算が正常に実行できているか確認します。 /** * テスト用の対象年月のリスト */ const TARGET_YEAR_MONTH_LIST = [ { // 2024年12月 TARGET_YEAR : 2024 , TARGET_MONTH : 12 , } , { // 2025年1月 TARGET_YEAR : 2025 , TARGET_MONTH : 1 , } , ] /** * 実行テスト用のメイン関数 */ function main () { TARGET_YEAR_MONTH_LIST . forEach ( targetYearMonth => { const firstDay = getFirstBusinessDay ( targetYearMonth . TARGET_YEAR , targetYearMonth . TARGET_MONTH ) ; const lastDay = getLastBusinessDay ( targetYearMonth . TARGET_YEAR , targetYearMonth . TARGET_MONTH ) ; // 結果をログに出力 console . log ( ` ${ targetYearMonth . TARGET_YEAR } 年 ${ targetYearMonth . TARGET_MONTH } 月の第1営業日: ${ Utilities . formatDate ( firstDay , 'JST' , 'yyyy-MM-dd (E)' )} ` ) ; console . log ( ` ${ targetYearMonth . TARGET_YEAR } 年 ${ targetYearMonth . TARGET_MONTH } 月の最終営業日: ${ Utilities . formatDate ( lastDay , 'JST' , 'yyyy-MM-dd (E)' )} ` ) ; }) ; } 初回実行時には、Google アカウントを選択し、権限を付与する必要があります。 正常終了すると、以下のようなログが出力されます。 第1営業日のイベント登録処理 実装 新しいファイル create_event.gs を作成し、以下の処理を実装します。 /** * イベントを作成するカレンダーを指定します。 * デフォルトカレンダー以外を使いたい場合は、'xxxx@group.calendar.google.com' のようなカレンダーIDに書き換えてください。 */ const TARGET_CALENDAR_ID = 'primary' ; // 'primary' はデフォルトカレンダーを意味します /** * カレンダーに作成するイベントの内容をここで定義します。 */ const EVENT_TITLE = '【月次】勤怠締め作業を上長申請' ; const EVENT_DESCRIPTION = '前月分の勤怠の締め作業をシステムを使用して上長に申請する。' ; /** * イベントを作成する開始年月日と終了年月日を定義します。 */ const START_DATE = new Date ( 2025 , 6 , 25 , 0 , 0 , 0 , 0 ) ; // 2025/07/25 const END_DATE = new Date ( 2026 , 1 , 28 , 0 , 0 , 0 , 0 ) ; // 2026/02/28 /** * イベントを作成する時の開始時間と終了時間を定義します。 */ const START_TIME = new Date ( 0 , 0 , 0 , 9 , 0 , 0 , 0 ) ; // 9:00 const END_TIME = new Date ( 0 , 0 , 0 , 9 , 30 , 0 , 0 ) ; // 9:30 /** * 指定された期間内の営業日の定例イベントをGoogleカレンダーに作成します。 * @param {function} getBusinessDay - 営業日を計算する関数(第1引数：年、第2引数：月) */ const createBusinessDayEvents_ = function ( getBusinessDay ) { // 1. 設定のチェック if ( START_DATE > END_DATE ) { console . error ( 'エラー: 開始年月日は終了年月日以前の日付にしてください。' ) ; return; } if ( START_TIME > END_TIME ) { console . error ( 'エラー: 開始時間は終了時間以前の時間にしてください。' ) ; return; } if ( typeof getBusinessDay ! = 'function' ) { console . error ( 'エラー: 引数には営業日を計算する関数を設定してください。' ) ; return; } const calendar = CalendarApp . getCalendarById ( TARGET_CALENDAR_ID ) ; if ( ! calendar ) { console . error ( `エラー: 指定されたカレンダーID ( ${ TARGET_CALENDAR_ID } ) が見つかりません。` ) ; return; } console . log ( '処理を開始します...' ) ; console . log ( `対象期間: ${ Utilities . formatDate ( START_DATE , 'JST' , 'yyyy-MM-dd' )} ~ ${ Utilities . formatDate ( END_DATE , 'JST' , 'yyyy-MM-dd' )} ` ) ; // 2. 指定期間内の営業日を計算 // 月ごとにループ const recurrence = CalendarApp . newRecurrence () ; const recurrenceDaysList = [] ; let currentDate = new Date ( START_DATE ) ; while ( currentDate <= END_DATE ) { const year = currentDate . getFullYear () ; const month = currentDate . getMonth () + 1 ; // 月は1始まりに補正 // 営業日を計算 const businessDay = getBusinessDay ( year , month ) ; const formattedDate = Utilities . formatDate ( businessDay , 'JST' , 'yyyy-MM-dd' ) ; // 計算した営業日が指定期間内にある場合のみタスクを作成 if ( businessDay >= START_DATE && businessDay <= END_DATE ) { recurrence . addDate ( businessDay ) ; recurrenceDaysList . push ( businessDay ) ; console . log ( `対象をリストに追加しました: ${ formattedDate } ` ) ; } else { console . log ( `指定期間外のためスキップしました: ${ formattedDate } ` ) ; } // 次の月へ currentDate . setMonth ( currentDate . getMonth () + 1 ) ; currentDate . setDate ( 1 ) ; // 日を1日にリセット } // 3. 定期的な予定の作成 if ( recurrenceDaysList . length > 0 ) { const initialDay = recurrenceDaysList [ 0 ] ; const startDate = new Date ( initialDay ) ; startDate . setHours ( START_TIME . getHours ()) ; startDate . setMinutes ( START_TIME . getMinutes ()) ; const endDate = new Date ( initialDay ) ; endDate . setHours ( END_TIME . getHours ()) ; endDate . setMinutes ( END_TIME . getMinutes ()) ; calendar . createEventSeries ( EVENT_TITLE , startDate , endDate , recurrence , { description : EVENT_DESCRIPTION } , ) ; console . log ( '定期的な予定を作成しました。' ) ; } else { console . log ( '指定期間に対象の日付がないため、定期的な予定を作成していません。' ) ; } } ; /** * 指定された期間内の各月の第1営業日の定例イベントをGoogleカレンダーに作成します。 */ function createFirstBusinessDayEvents () { createBusinessDayEvents_ ( getFirstBusinessDay ) ; } createBusinessDayEvents_ ではまず、 CalendarApp クラスを使用し、自身の Google カレンダーの情報を取得します。 次に、 RecurrenceRule クラスを使用して、定期的な予定のルールを作成していきます。引数の営業日計算用の関数を使用して営業日の計算を行い、 addDate メソッドを使用して定期的な予定に設定する営業日を追加します。 最後に、 Calendar クラスの createEventSeries メソッドを使用して定期的な予定を登録します。 参考 : Class Calendar 参考 : Class RecurrenceRule 動作確認 createFirstBusinessDayEvents 関数を実行すると、カレンダーに定期的な予定が登録されます。以下のように、 Google カレンダーに指定した期間の予定が登録されていることが確認できます。 Google カレンダー上では登録された予定には繰り返し設定がないと表示されていますが、 スケジュールの削除を実行すると、定期的な予定の削除のダイアログが表示され、定期的な予定となっていることが確認できます。 また、2025年11月や2026年1月を確認すると、土日祝日、会社休日の設定が考慮された、第1営業日が登録されていることを確認できます。 最終営業日のイベント登録処理 最終営業日にタスクを作成したい場合は、 create_event.gs に以下のコードを実装します。 createBusinessDayEvents_ 関数に最終営業日計算用の関数を引数として渡すことで実装できます。 createLastBusinessDayEvents 関数を実行すると、最終営業日に定期的な予定を登録できます。 /** * 指定された期間内の各月の最終営業日の定例イベントをGoogleカレンダーに作成します。 */ function createLastBusinessDayEvents () { createBusinessDayEvents_ ( getLastBusinessDay ) ; } 高宮 怜 (記事一覧) クラウドソリューション部クラウドエクスプローラ課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya

G-gen の杉村です。当記事は、Google Cloud Next '25 Tokyo の2日目に行われたスポンサーセッション「 我々は、生成 AI アプリを開発するべきなのか 」のレポートです。 他の Google Cloud Next Tokyo '25 の関連記事は Google Cloud Next Tokyo '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Out-of-the-box な AI ソリューション Google Agentspace Google の AI アプリ開発用プラットフォーム 独自 AI アプリ開発へのスタンス セッションの概要 本セッションは、Google Cloud 専業インテグレーターである G-gen 社によるセッションです。 前半では Google Workspace に追加コストなしで組み込まれている生成 AI 関連ソリューション等や、Google Cloud で提供される生成 AI アプリ開発向けプロダクトなどの紹介が行われました。後半では、「我々は、生成 AI アプリを開発するべきなのか」というタイトルに対する考察が行われました。 Out-of-the-box な AI ソリューション Google Workspace には、アカウントさえあれば追加コストなしですぐに使える（ Out-of-the-box な ）AI ソリューションが多数組み込まれています。 代表的なのものは、 Gemini アプリ と NotebookLM です。 Gemini アプリは、生成 AI との自然言語による対話を通じ、質問や文章の生成、要約、翻訳、ソースコードの生成など多数のタスクを行うことができます。 NotebookLM は、アップロードしたドキュメントに基づいて質問応答や要約、アイデア生成などができる AI ノートブックです。Gemini アプリよりも限定的なデータソース、範囲を絞ったコンテキストに基づいた AI タスクを実行できます。 Gemini アプリや NotebookLM の詳細は、以下の記事も参照してください。 blog.g-gen.co.jp また Google Workspace では、Google Meet、Google ドキュメント、Google ドライブ、Google スプレッドシートといった各種アプリに Gemini が組み込まれており、これらも追加コストなしで利用できます。 これらの Google Workspace 組み込みの AI 機能の利用方法等については、以下の記事も参照してください。 blog.g-gen.co.jp Google Agentspace Google Agentspace は有償の Google サービスです。Google Agentspace は以下のような機能を備えた、AI プラットフォームといえます。 社内の複数のデータソースに対して Google 品質の横断検索 Gemini の高度な推論 自社保有データが統合されたエージェント Google ドライブや Microsoft SharePoint、Microsoft Outlook、Jira、Slack といったデータソースに対して横断検索を行うことができるほか、これらに対して AI が要約や資料作成、アイデア出しなどのタスクを実行できます。自社開発した AI エージェントも統合できるため、AI エージェントのプラットフォームとしても利用可能です。 Google Agentspace の詳細は、以下の記事も参考にしてください。 blog.g-gen.co.jp Google の AI アプリ開発用プラットフォーム Google Cloud では、AI アプリ開発用のプロダクトが多数公開されています。 Generative AI on Vertex AI、Google AI Studio、Vertex AI Search、Agent Development Kit（ADK）、Vertex AI Agent Engine、Model Armor、BigQuery ML、Vertex AI Feature Store などが紹介されました。 独自 AI アプリ開発へのスタンス 「我々は、生成 AI アプリを開発するべきなのか」というセッションタイトルへの回答としては、「この問いへの答えはケースバイケースである」とされました。 Google の Out-of-the-box な AI ツールを使う方がいいケースと、独自アプリを開発したほうがいいケース、両方のケースがあり、それらを適切に判断する判断基準を持つことが重要であるとしました。 Google などの各ベンダーが、AI ソリューションを次から次へと開発・公開している現状から、自社の業務改善などのユースケースであれば、可能な限り Out-of-the-box なツール（できあいの既製品）を使うべきであると述べられました。 一方で、自社特有の独創的なビジネスロジックが必要なケースや、自社アプリとの組み合わせ、ライセンス管理、課金などの追加実装が必要な場合、また生成 AI ではない回帰モデルなどを組み合わせたい場合などに、自社で生成 AI アプリを開発することを検討すべきとされました。 コスト最適の観点からも、まずは Out-of-the-box な既製品が利用できないかを検討し、それが不可な場合に自社アプリの開発を検討するのが望ましいと言えます。 独自アプリの開発が決断されたケースとして、「Gemini アプリ（既製品）では精度が足りないケース」「AI に複雑で多段なタスクをさせたいケース」「セキュリティ要件が厳しいケース」「コンシューマー向けのサービス」のような実例が挙げられました。 具体的な事例として、Vertex AI Search や ADK を使った実装の事例が紹介されました。 また G-gen 社の事例として、同社が提供する AI サービスである G-gen Tech Agent の事例が紹介されました。 参考 : 株式会社G-gen、新サービス G-gen Tech Suite を提供開始 同サービスのアーキテクチャについては、以下の記事で詳細に紹介されています。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の奥田です。当記事では、 Gemini CLI を利用した開発事例を紹介します。Google Cloud が提供するAPI である Virtual Try on API と、Web UI 用の Python フレームワークである Gradio を使用した、シンプルな画像生成 Web アプリの開発手順を紹介します。 はじめに Gemini CLI Virtual Try on API Gradio Gemini CLI を用いたアプリの開発 初期のディレクトリ構成 Gemini CLI による開発 Cloud Storage バケットの作成 エラー対応 ローカルでテスト Cloud Run にデプロイ 生成されたソースコード requirements.txt app.py Dockerfile はじめに Gemini CLI Gemini CLI とは、ターミナルから直接 Gemini の機能を利用できるオープンソースのコマンドラインインターフェイスです。 詳しくは以下の記事をご覧ください。 blog.g-gen.co.jp なお、Gemini CLI におけるコマンドの紹介や開発事例については以下の記事をご覧ください。 blog.g-gen.co.jp Virtual Try on API Virtual Try on API とは、試着対象の人の画像と、試着したい衣服の画像を入力することにより、着せ替えた写真を出力できる Vertex AI の API です。同機能は2025年8月現在、Preview 公開です。 人物画像と衣服の画像を Base64 エンコードしてリクエストに含ませることで、Cloud Storage バケットに画像を出力できます。使用には、Vertex AI を有効化した Google Cloud プロジェクトが必要です。 参考 : Generate Virtual Try-On Images この API と同様の技術を活用した機能として、Google は2025年5月の Google I/O で「Try It On」（バーチャル試着）機能を Search Labs 内で公開しました。 参考 : Shop with AI Mode, use AI to buy and try clothes on yourself virtually Gradio Gradio は、機械学習 Web アプリを構築するための Python フレームワークです。 参考 : Gradio Docs - Interface Gemini CLI を用いたアプリの開発 初期のディレクトリ構成 まず、アプリケーション用に新しいディレクトリを作成します。 新しいディレクトリを作ることを推奨する理由は、環境や設定を他のプロジェクトと混ざらないように安全に管理するためです。 意図しない挙動を防ぐため、空のディレクトリに公式ドキュメントに記載の Colab ソースコードを保存し、次の手順で Gemini CLI のコンテキストとして与えます。 参考 : Generate Virtual Try-On Images try-app |-- virtual_try_on.py |-- .env Gemini CLI による開発 Gemini CLI を起動し、以下のように初回プロンプトを記入しました。 こちらの Virtual Try-On API を試せる Gradio アプリを作成してください。Cloud Run へのデプロイを想定します。 ソースコードは`virtual_try_on.py`を参考にしてください。 処理の流れは以下のとおりです。 1. 人物の画像を、事前に定義した特定の Cloud Storage バケットへアップロードする。 2. 服の画像を、事前に定義した特定の Cloud Storage バケットへアップロードする。 3. 上記 2 つの画像のパスを使ってリクエストを送信し、Virtual Try-On API を実行する。 4. 生成された画像を Gradio アプリ上で表示する。ダウンロードボタンを押すとローカルにダウンロードできる。ダウンロード形式は JPEG とする。 これにより、以下のファイルが生成されました。 try-app |-- app.py |-- requirements.txt |-- README.md |-- Dockerfile Cloud Storage バケットの作成 人物画像及び服の画像を格納する Cloud Storage バケットを作成します。 export BUCKET_NAME = " risa-test-cloths " export PROJECT_ID = " my-project " export REGION = " us-central1 " gsutil mb -p $PROJECT_ID -l $REGION gs:// $BUCKET_NAME エラー対応 app.py を起動すると以下のエラーが発生しました。 Traceback (most recent call last): File "/Users/r-risa/virtual_try/app.py", line 10, in <module> from google import genai ImportError: cannot import name 'genai' from 'google' (unknown location) 生成された README.md を参照すると、現在は非推奨の google-generativeai がパッケージに含まれていました。 参考 : Google GenAI SDK に移行する gradio google-generativeai　#非推奨のパッケージ google-cloud-storage Pillow そのため、現推奨の google-genai パッケージに変更しました。 gradio google-cloud-storage Pillow google-genai　#現推奨のパッケージに変更 ローカルでテスト 環境変数をエクスポートした後、 python app.py を実行してローカルでテストします。 左上に人物の画像をアップロードし、左下に服の画像をアップロードします。 左下のオレンジ色のボタン「試着画像を生成する」をクリックすると、数秒で着せ替えた写真が出力されます。ダウンロードボタンを押下することで、ローカルにダウンロードできます。 Cloud Run にデプロイ 環境変数をエクスポートした後、以下のコマンドで Cloud Run にデプロイします。 当記事では検証環境のため未認証の呼び出しを可能としていますが、必要に応じて認証の設定をしてください。 gcloud run deploy $IMAGE_NAME \ --source . \ --image $IMAGE_TAG \ --region $REGION \ --service-account $SERVICE_ACCOUNT_EMAIL \ --set-env-vars =" GCP_PROJECT= ${PROJECT_ID} " \ --set-env-vars =" GCS_BUCKET_NAME= ${BUCKET_NAME} " \ --set-env-vars =" GCP_REGION= ${REGION} " \ --allow-unauthenticated \ --platform managed 生成されたソースコード 参考までに、最終的に生成されたソースコードを記載します。 requirements.txt gradio google-cloud-storage Pillow google-genai app.py import os import uuid import tempfile from datetime import datetime import gradio as gr from PIL import Image as PIL_Image from google.cloud import storage from google import genai from google.genai.types import Image, ProductImage, RecontextImageSource, RecontextImageConfig # --- 環境変数の設定 --- # Google CloudプロジェクトIDとロケーションを設定してください。 # Cloud Run環境では、環境変数として設定することを推奨します。 PROJECT_ID = os.environ.get( "GCP_PROJECT" ) LOCATION = os.environ.get( "GCP_REGION" , "us-central1" ) # 画像をアップロードするGCSバケット名を設定してください。 GCS_BUCKET_NAME = os.environ.get( "GCS_BUCKET_NAME" ) # --- Google Cloud クライアントの初期化 --- client = None storage_client = None try : # Vertex AI用のクライアントを初期化 client = genai.Client(vertexai= True , project=PROJECT_ID, location=LOCATION) storage_client = storage.Client() print ( "Google Cloud クライアントの初期化に成功しました。" ) except Exception as e: print (f "Google Cloud クライアントの初期化に失敗しました: {e}" ) print ( "環境変数 GCP_PROJECT と BUCKET_NAME が正しく設定されているか確認してください。" ) # --- 定数 --- VIRTUAL_TRY_ON_MODEL = "virtual-try-on-preview-08-04" def upload_to_gcs (pil_image: PIL_Image.Image, file_name: str ) -> str : """PillowイメージをGCSにアップロードし、GCS URIを返す""" if not storage_client or not GCS_BUCKET_NAME: raise gr.Error( "GCSクライアントが初期化されていないか、バケット名が設定されていません。" ) bucket = storage_client.bucket(GCS_BUCKET_NAME) # Pillowイメージをバイトデータに変換 with tempfile.SpooledTemporaryFile() as temp_byte_io: pil_image.save(temp_byte_io, "PNG" ) temp_byte_io.seek( 0 ) blob = bucket.blob(file_name) blob.upload_from_file(temp_byte_io, content_type= "image/png" ) return f "gs://{GCS_BUCKET_NAME}/{file_name}" def virtual_try_on (person_pil_image: PIL_Image.Image, clothing_pil_image: PIL_Image.Image): """Virtual Try-On APIを実行して試着画像を生成する""" if not client: raise gr.Error( "Vertex AIクライアントが初期化されていません。アプリケーションのログを確認してください。" ) if not person_pil_image or not clothing_pil_image: raise gr.Error( "人物画像と服の画像を両方アップロードしてください。" ) try : # ファイル名を一意にするためにUUIDとタイムスタンプを使用 timestamp = datetime.now().strftime( "%Y%m%d-%H%M%S" ) unique_id = uuid.uuid4().hex[: 6 ] person_filename = f "person-{timestamp}-{unique_id}.png" clothing_filename = f "clothing-{timestamp}-{unique_id}.png" # GCSに画像をアップロード person_gcs_uri = upload_to_gcs(person_pil_image, person_filename) clothing_gcs_uri = upload_to_gcs(clothing_pil_image, clothing_filename) # Virtual Try-On APIを呼び出し response = client.models.recontext_image( model=VIRTUAL_TRY_ON_MODEL, source=RecontextImageSource( person_image=Image(gcs_uri=person_gcs_uri), product_images=[ ProductImage(product_image=Image(gcs_uri=clothing_gcs_uri)) ], ), config=RecontextImageConfig( base_steps= 32 , number_of_images= 1 , safety_filter_level= "BLOCK_LOW_AND_ABOVE" , person_generation= "ALLOW_ADULT" , ), ) generated_pil_image = response.generated_images[ 0 ].image._pil_image # ダウンロード用にJPEG形式で一時ファイルに保存 with tempfile.NamedTemporaryFile(delete= False , suffix= ".jpeg" ) as temp_file: generated_pil_image.convert( "RGB" ).save(temp_file, "jpeg" ) temp_file_path = temp_file.name return generated_pil_image, temp_file_path except Exception as e: print (f "エラーが発生しました: {e}" ) raise gr.Error(f "画像の生成に失敗しました。詳細: {e}" ) # --- Gradioインターフェースの定義 --- with gr.Blocks() as demo: gr.Markdown( "# Virtual Try-On アプリケーション" ) gr.Markdown( "人物の画像と服の画像をアップロードすると、AIがその服を着用した画像を作成します。" "生成された画像は、表示後にダウンロードできます。" ) with gr.Row(): with gr.Column(): person_image = gr.Image( type = "pil" , label= "人物の画像" ) clothing_image = gr.Image( type = "pil" , label= "服の画像" ) submit_btn = gr.Button( "試着画像を生成する" , variant= "primary" ) with gr.Column(): output_image = gr.Image( type = "pil" , label= "生成された画像" ) download_file = gr.File(label= "画像をダウンロード" ) submit_btn.click( fn=virtual_try_on, inputs=[person_image, clothing_image], outputs=[output_image, download_file] ) if __name__ == "__main__" : # Cloud RunではPORT環境変数が設定される server_port = int (os.environ.get( "PORT" , 8080 )) demo.launch(server_name= "0.0.0.0" , server_port=server_port) Dockerfile # Python 3.10をベースイメージとして使用 FROM python:3.10-slim # 作業ディレクトリを設定 WORKDIR /app # 依存関係をインストールするためにrequirements.txtをコピー COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # アプリケーションコードをコピー COPY . . # Gradioアプリを起動 # Cloud RunはPORT環境変数でリッスンするポートを指定します ENV PORT 8080 CMD [ " python ", " app.py " ] Risa (記事一覧) クラウドソリューション部クラウドデベロッパー課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資格保有。日々修行中です！ Follow @risa_hochiminh

G-genの杉村です。Google Cloud の Identity-Aware Proxy （IAP）で、プロジェクトの所属組織とは異なる Google Workspace 組織の Google アカウントからのアクセスを許可する方法を解説します。 はじめに Identity-Aware Proxy（IAP）とは デフォルトの挙動と課題 カスタム OAuth クライアントの利用 注意点 設定手順の概要 OAuth 同意画面の設定 カスタム OAuth クライアントの作成 IAP にカスタム OAuth クライアントを設定 アクセス許可の設定 はじめに Identity-Aware Proxy（IAP）とは Identity-Aware Proxy （IAP）は、Google Cloud 上で稼働するアプリケーションに対して、ユーザーの ID に基づいた認証機構を提供するサービスです。アプリケーション自体に認証・認可の仕組みを実装しなくても、ロードバランサーや Cloud Run サービスなどのレベルで、安全なアクセス制御を実現します。 IAP を有効化すると、ユーザーはアプリケーションにアクセスする前に Google アカウントでの認証を求められます。認証後、IAM で付与されたロールに基づいてアクセスが許可または拒否されます。 参考 : Identity-Aware Proxy の概要 (図） また IAP は VM への SSH/RDP ログインのための踏み台としても使うことができます。以下の記事も参照してください。 blog.g-gen.co.jp デフォルトの挙動と課題 IAP を有効化すると、デフォルトでは「 Google が管理する OAuth クライアント 」が自動的に作成され、認証に使用されます。この OAuth クライアントは、認証を求めるユーザーが、その Google Cloud プロジェクトが属する Google Cloud 組織と 同じ Google Workspace（または Cloud Identity）組織に所属していることを前提 としています。 参考 : Google 管理の OAuth クライアントを使用して IAP を有効にする 例えば、 example-a.com というドメインを持つ A 社の Google Cloud 組織配下のプロジェクトで動作する Cloud Run でホストされた Web アプリケーションにおいて IAP を有効にした場合、デフォルトでは @example-a.com ドメインの Google アカウントを持つユーザーしか認証を通過できません。アプリケーションを使わせたい顧客である B 社のユーザー（ @example-b.com ）にアクセスを許可しようとしても、認証画面でエラーとなりアクセスができません。 You don't have access You don't have access. If you're signed in with multiple Google accounts, try a different account. If you should have access, please contact xxx and provide the troubleshooting info above. カスタム OAuth クライアントの利用 この事象は、IAP で使用する OAuth クライアントを、Google 管理のものではなく自前で作成した「 カスタムOAuthクライアント 」に切り替えることで解決できます。 参考 : OAuth 構成をカスタマイズして IAP の有効化 カスタム OAuth クライアントを利用することで、認証を許可する Google アカウントのドメイン（組織）に関する制約がなくなります。これにより、任意の Google アカウントを持つユーザーに対して、IAM ポリシーでアクセスを許可できるようになります。 当記事では、このカスタム OAuth クライアントを作成し、IAP に設定するまでの手順を解説します。 注意点 Cloud Run services では、サービスのレベルで IAP を設定可能です。この方法では Cloud Load Balancing を必要としませんが、認証できるのは Google Cloud プロジェクトと同じ組織に所属する Google アカウントのみです。当記事で紹介する方法は使えませんのでご注意ください。当記事の方法で外部組織のアカウントを認証するには、ロードバランサーが必要です。 参考 : Configure Identity-Aware Proxy for Cloud Run 以下の記事も参考にしてください。 blog.g-gen.co.jp 設定手順の概要 設定は大きく分けて以下の4ステップです。 OAuth 同意画面の設定 カスタム OAuth クライアントの作成 IAP にカスタム OAuth クライアントを設定 アクセス許可の設定 なお前提として、すでに Cloud Load Balancing を使い外部ロードバランサーがセットアップ済みであり、インターネット公開のアプリケーションの準備ができているものとします。バックエンドは Cloud Run でも、Compute Engine でも、種類は問いません。 OAuth 同意画面の設定 カスタム OAuth クライアントを作成する前に、プロジェクトで OAuth同意画面 を設定する必要があります。OAuth 同意画面とは、ユーザーがアプリケーションに個人情報へのアクセスを許可する際に表示される画面のことです。 Google Cloud コンソールの上部検索ボックスに「Google Auth Platform」と入力して表示されるサジェストから「Google Auth Platform」画面へ進みます。 同意画面が未設定の場合、「Google Auth Platform はまだ構成されていません」と表示されるので下部ボタン「開始」をクリックします。ここではアプリ名、連絡先のメールアドレスなどを設定します。ここで、「対象（User Type）」として「 外部 」を選択します。この設定は、OAuth 同意画面の初期設定時のほか、あとからでも変更可能です。 「外部」を選択 参考 : Manage OAuth App Branding 参考 : Manage App Audience カスタム OAuth クライアントの作成 次に、カスタム OAuth クライアントを作成します。 Google Cloud コンソールの「Google Auth Platform」から「クライアント」へ進み、「+ クライアントを作成」を押下します。クライアントは、以下のとおり作成します。 設定項目 設定値 アプリケーションの種類 ウェブ アプリケーション 名前 （任意） 承認済みの JavaScript 生成元 （何も追加しない） 承認済みのリダイレクト URI （何も追加しない） 「作成」をクリックすると、クライアント ID とクライアントシークレットが表示されます。この値は後ほど使用するため、必ず控えておきます。機微な情報のため、注意して扱ってください。 一度クライアントを作成した後、再度 そのクライアントの編集画面を開き、「 承認済みのリダイレクト URI 」を設定します。これは、Google の認証サーバーがユーザーの認証後にリダイレクトさせる宛先を指定するもので、IAP の動作において不可欠な設定です。 「承認済みのリダイレクト URI」の下部にある「URI を追加」をクリックし、以下の形式の URI を入力します。 ${CLIENT_ID} の部分は、先ほど作成した OAuth クライアントの クライアント ID に置き換えてください（クライアントシークレットではありません）。 https://iap.googleapis.com/v1/oauth/clientIds/${CLIENT_ID}:handleRedirect URI は、例えば以下のような値になります。 https://iap.googleapis.com/v1/oauth/clientIds/123456789012-abcdefghijklmnopqr.apps.googleusercontent.com:handleRedirect 設定後、「保存」をクリックします。 OAuth Client の設定 この URI 指定方法については、IAP で外部組織の Google アカウントを設定する方法としては公式ドキュメントには記載がありませんが、以下の Workforce Identity 連携と IAP の併用に関する公式ドキュメントに記載があり、Google アカウントの場合でも同様です。 参考 : Workforce Identity 連携で IAP の構成 - OAuth クライアント ID とシークレットを作成する IAP にカスタム OAuth クライアントを設定 作成したカスタム OAuth クライアントを IAP で使用するよう設定を変更します。 Google Cloud コンソールの「セキュリティ」から「Identity-Aware Proxy」へ移動します。設定を変更したいバックエンドサービスの「IAP」チェックボックスをオンにし、右側の三点リーダーをクリックすると表示されるプルダウンメニューから「設定」をクリックします。 プルダウンメニューから「設定」 OAuth クライアントの選択画面で、「 カスタム OAuth（特定の制御、ブランディング、外部ユーザー用） 」を選択します。 前の手順で控えておいた クライアント ID と クライアントシークレット を入力し、「保存」をクリックします。 カスタム OAuth を選択して ID とシークレットを入力 アクセス許可の設定 最後に、アクセスを許可したい他組織のユーザーやグループ、ドメインに対して IAM ロールを付与します。 IAP の管理画面で対象のバックエンドサービス等を選択し、右パネルの「プリンシパルを追加」をクリックします。 「新しいプリンシパル」に、アクセスを許可したい Google アカウント（ john.doe@example-b.com ）、Googleグループ（ dev-group@example-b.com ）、またはドメイン全体（ example-b.com ）を入力します。 ロールには、 IAP-secured Web App User を選択し、保存します。 プリンシパルを追加 以上で設定は完了です。許可した他組織の Google アカウントでアプリケーションにアクセスすると、Google のログイン画面が表示され、認証後にアプリケーションが利用できることが確認できます。 ログイン画面 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。BigQuery に組み込まれた AI アシスタント機能である Gemini in BigQuery を解説します。当機能では、SQL の自動生成やデータ変換、メタデータの自動生成など、データ分析の様々なタスクを効率化することができます。 はじめに Gemini in BigQuery とは データの保護 自然言語によるクエリ 料金と割り当て 利用料金 使用可能な機能 割り当て（Quota） 準備 API の有効化 IAM 権限の付与 Conversational Analytics（会話形分析） SQL コーディング補助 概要 有効化 SQL 生成ツール コメントからの自動生成 Gemini Cloud Assist による生成 コード補完 精度向上のコツ SQL の説明 Python コーディング支援 概要 有効化 コード生成と補完 データキャンバス（Data canvas） 概要 使用方法 データ準備（Data preparation） データ分析情報（Data insights） メタデータ自動生成 SQL 変換支援 はじめに Gemini in BigQuery とは Gemini in BigQuery とは、Google Cloud の生成 AI モデルである Gemini を BigQuery に統合した機能群の総称です。ほとんどの機能を原則無料で利用することができます。Gemini in BigQuery は、Google Cloud の AI 支援機能群である Gemini for Google Cloud サービスの一部として位置づけられています。 参考 : Gemini in BigQuery の Gemini の概要 Gemini in BigQuery を利用することで、自然言語による指示（プロンプト）を通じて、データ分析ワークフローの様々なタスクを自動化・効率化できます。Gemini in BigQuery の機能として、以下が提供されています。 Conversational Analytics（会話形分析）/ データエージェント SQL コーディング支援 Python コーディング支援（BigQuery ノートブック） データキャンバス（Data canvas。自然言語によるデータ分析） データ準備（Data preparation。自然言語によるデータ変換） データ分析情報（Data insights） メタデータ自動生成 SQL 変換（他方言から GoogleSQL への変換）支援 データの保護 Gemini in BigQuery に入力されるプロンプトや出力されるレスポンスは、Google Cloud の利用規約に従って保護されます。これらのデータが、Google のモデルのトレーニングに許可なく使用されるようなことはありません。 また、保存時および転送時のデータは常に、透過的に暗号化されています。 詳細は以下のドキュメントを参照してください。 参考 : Security, privacy, and compliance for Gemini in BigQuery 自然言語によるクエリ Gemini in BigQuery には、自然言語によってデータをクエリするためのいくつかの機能が含まれています。しかしながら、BigQuery に自然言語でクエリする手段は、Gemini in BigQuery だけではありません。以下の記事も参考にして下さい。 blog.g-gen.co.jp 料金と割り当て 利用料金 Gemini in BigQuery は、 原則無料 で利用できます。 ただし、どの BigQuery 料金体系を選択しているか（オンデマンドもしくは Editions）によって使用可能な機能が異なります。また、機能の呼び出し回数に制限（割り当て）があります。 参考 : Gemini for Google Cloud pricing - Gemini in BigQuery Pricing Overview BigQuery の料金体系については、以下の記事を参考にしてください。 blog.g-gen.co.jp 使用可能な機能 BigQuery ジョブを実行する Google Cloud プロジェクトの料金体系として、デフォルトの オンデマンドモード 、もしくは BigQuery Enterprise Edition 、 Enterprise Plus Edition を使用している場合、Gemini in BigQuery の すべての機能が使用できます 。ただし、機能の呼び出し回数には後述の制限（割り当て）があります。 プロジェクトで BigQuery Standard Edition を使用している場合のみ機能制限があり、データ分析情報（Data insights） とメタデータ自動生成が 使用できません 。 ただし、Gemini Code Assist の有償ライセンスを購入している場合、BigQuery の料金体系に関係なく、ライセンスに紐づいているユーザーはデータ分析情報（Data insights） とメタデータ自動生成の2機能を使用することができるようになります。 割り当て（Quota） Gemini in BigQuery では、機能の呼び出し回数に制限があります。この制限は 割り当て （Quota）と呼ばれています。 当記事の説明は2025年8月現在の英語版ドキュメントに基づいています。最新の情報や詳細な計算式などは、以下の公式ドキュメントを参照してください。 参考 : Quotas and limits 参考 : Gemini for Google Cloud pricing - Gemini in BigQuery Pricing Overview SQL・Python のコード補完・生成機能の割り当ては、以下のとおりです。割り当てはユーザーごとに適用されます。 割り当て名称 値 1秒あたりのリクエスト数 2 1日あたりのリクエスト数 6,000 データキャンバス（Data canvas）、データ準備（Data preparation）の割り当ては以下の通りです。割り当てはユーザーごとに適用されます。 割り当て名称 値 1日あたりのリクエスト数 960 一方、データ分析情報（Data insights） とメタデータ自動生成の2機能の割り当ては、 前月の BigQuery 使用ボリューム（1日あたりの平均）に応じて計算 されて決まります。割り当ては組織レベルで適用され、同じ組織に所属するすべてのプロジェクトで共有されます。 以下の表の (前月の1日あたりの平均使用量) は、オンデマンドモードの場合はスキャンデータ量の TiB 数です。BigQuery Enterprise または Enterprise Plus Edition の場合は、100スロット時間です。使用ボリュームは100スロット単位で切り上げられます。 割り当て名称 値 1日あたりのリクエスト数 (前月の1日あたりの平均使用量) × 5 ただし、Gemini Code Assist 有償サブスクリプションと紐づいているユーザーは、960回の割り当てが別で与えられます。 前月に BigQuery の使用実績がない場合は、250回/日の割り当てが適用されます。 準備 参考 : Gemini in BigQuery を設定する API の有効化 Gemini in BigQuery は、Google Cloud プロジェクトで Gemini for Google Cloud API（ cloudaicompanion.googleapis.com ）および BigQuery Unified API（ bigqueryunified.googleapis.com ）を有効にするだけで機能が使用可能になります。 2025年7月30日のアップデートにより、必要な API はほとんどのプロジェクトでデフォルトで有効になったとされています。 参考 : BigQuery release notes - July 30, 2025 もし API が有効になっていない場合は以下の方法で有効化します。 BigQuery Studio（BigQuery の Web コンソール画面）の右上部分に表示されている鉛筆マークがグレーアウトされている場合は、必要な API が有効になっていません。鉛筆マークにマウスオーバーすると、以下のような表示がポップアップします。「続行」をクリックすると表示されるガイダンスに従って操作することで、API を有効化することができます。 API の有効化 なお、上記の操作方法およびスクリーンショットは、2025年8月現在のものです。 IAM 権限の付与 API を有効化したプロジェクトでは Gemini in BigQuery が使用可能になりますが、ユーザーが適切な権限を持っている必要があります。操作者の Google アカウントがプロジェクトに対して以下の IAM ロールのいずれかを持っていると、Gemini in BigQuery の機能が使用可能です。 BigQuery Studio ユーザー（ roles/bigquery.studioUser ） BigQuery Studio 管理者（ roles/bigquery.studioAdmin ） あるいは、既にプロジェクトで BigQuery を使用する権限を持っているユーザーに対しては、以下のようなロールをプロジェクトレベルで付与することでも使用可能です。 Gemini for Google Cloud ユーザー（ roles/cloudaicompanion.user ） Conversational Analytics（会話形分析） BigQuery の Conversational Analytics （会話形分析）あるいは データエージェント 機能を使うと、自然言語で BigQuery テーブルやビューからデータを抽出できます。 チャット形式でデータに関する質問をすると、生成 AI がテキストや図表で回答してくれます。 参考 : Conversational analytics overview BigQuery の Conversational Analytics 当機能は Google Cloud の Web コンソール画面に組み込まれています。追加料金や追加ライセンス等は不要です。 事前に管理者側でデータエージェントを作成し、そこに対象テーブルやコンテキスト、システムプロンプト等を定義します。作成したデータエージェントを従業員に IAM 権限を付与することで公開するといった運用が可能です。 SQL コーディング補助 概要 Gemini in BigQuery には SQL のコーディング補助機能があり、AI による SQL の補完、生成、解説を行うことができます。 コーディング補助は、BigQuery の Web ユーザーインターフェイスである BigQuery Studio 上で使用できます。 参考 : Gemini のアシスタント機能を使用してクエリを作成する 有効化 前提として、使用するプロジェクトで、前述の手順により関連 API が有効化されている必要があります。 その後、BigQuery Studio 画面の鉛筆マークをクリックして表示されるプルダウンメニューから、「SQL クエリの Gemini」の下にある「予測入力」「自動生成」「SQL 生成ツール」にチェックマークを入れます。 SQL 生成の有効化 SQL 生成ツール 自然言語から SQL を生成させるには、SQL 編集エリアの左側に表示される鉛筆マークをクリックします。 鉛筆マーク ポップアップされたテキストエリアに自然言語で指示を記載します。以下のスクリーンショットでは、特に分析対象のテーブルを指定していません。 プロンプト入力画面がポップアップする しかしこの時は、直近でパブリックデータセットのテーブル bigquery-public-data.usa_names.usa_1910_current の詳細画面を表示していました。Gemini はそれを踏まえて、このテーブルへクエリする SQL を生成してくれました。挿入ボタンを押すと、生成された SQL がエディタに挿入されます。 生成された SQL コメントからの自動生成 ポップアップ画面を開かなくても、SQL エディタ内に コメント により自然言語で指示を記載することでも、SQL を生成できます。コメントは -- で始めても、 # で始めても構いません。「SQL 生成ツール」と同様に、テーブルを明示的に指示しなくても直近で開いたテーブルなどを踏まえて生成してくれますが、以下のスクリーンショットは明示的にテーブル ID を指定しました。 コメントを入力して改行するだけで SQL が生成されサジェストされる コメントを入力して Enter を押下して改行すると、鉛筆マークが表示される位置で、処理中を示す回転アイコンが表示されます。しばらく待つとグレー文字で SQL がサジェストされます。Tab キーを押下すると、SQL が挿入されます。 Gemini Cloud Assist による生成 画面右上の Gemini アイコンを押下すると表示される Gemini Cloud Assist のサイドパネル（チャットパネル）でも、自然言語で指示することで SQL の生成が可能です。 Gemini Cloud Assist のサイドパネル コード補完 SQL を記述していると、何もしなくても行番号の横で回転アイコンが表示され、しばらく待つと SQL がサジェストされます。 Tab キーを押下すると、提案内容が挿入されます。 SQL の続きがサジェストされる 精度向上のコツ SQL 生成の提案精度を向上させるには、以下を踏まえて指示をします。 テーブル ID はバッククォート（`）で囲む コンテキスト（背景情報）を十分指示に含ませる。列名や、列名と回答との関連性、複雑な用語などを含ませる コメントからの SQL 生成時、コメントは複数行でも可能 Gemini は BigQuery テーブルや列の説明（Description）を読み取る。説明（Description）を充実させることで精度が向上する SQL の説明 既存の SQL を、Gemini に自然言語で解説させることもできます。ただし2025年8月現在、当機能は Google Cloud コンソールの設定（Preferences）で 言語設定を英語 にしていないと使えません。 BigQuery Studio のクエリエディタ上で、説明させたい SQL を選択して、左側に表示される星型のマークをクリックして表示されるプルダウンメニューから Explain this query を選択します。 クエリを選択し、AI マークをクリックしてから Explain this query を選択 すると、画面右側に Gemini Cloud Assist のチャットパネルが開き、SQL の意味が自然言語で解説されます。 チャットパネル内で SQL が解説される 2025年8月現在は、Google Cloud コンソールの設定を英語にしないと使えませんが、コンソール設定が英語でも、解説に続いて「日本語で解説して」のように入力すると、日本語での解説が出力されます。 日本語で出力された解説 Python コーディング支援 概要 Gemini in BigQuery には Python のコーディング補助機能もあります。BigQuery ノートブック上で、AI による Python の補完、生成、解説を行うことができます。 Python コーディング補助は、BigQuery の Web ユーザーインターフェイス上で使える Jupyter ノートブックで使用できます。このノートブックは、バックエンドで Google Cloud のフルマネージドサービスである Colab Enterprise が使用されています。ノートブック上では、Python ソースコードを記述・実行できます。 参考 : Gemini のアシスタント機能を使用してクエリを作成する - Python コードを生成する 有効化 前提として、使用するプロジェクトで、前述の手順により関連 API が有効化されている必要があります。 その後、BigQuery Studio 画面の鉛筆マークをクリックして表示されるプルダウンメニューから、「Python ノートブックの Gemini」の下にある「コード補完」「コード生成」にチェックマークを入れます。 Python コード生成の有効化 コード生成と補完 ノートブック上では、Gemini アイコンを押すことでコードを生成させたり、解説させたりすることができます。 また、コーディング中に補完内容が自動でサジェストされます。Tab キーを押すと、コードが挿入されます。 SQL コーディングと同様に、Gemini Cloud Assist のサイドパネルでもコード生成が可能です。 ノートブック上でのコード生成・補完 データキャンバス（Data canvas） 概要 データキャンバス （Data canvas）は自然言語による指示と、グラフィカルなユーザーインターフェイスによってデータの検索、変換、クエリ、可視化を行う機能です。 この機能を使うことで、SQL のスキルがないユーザーでも、自然言語により BigQuery のデータをクエリすることができます。複数テーブルの結合を含むある程度複雑な質問にも答えることができます。 参考 : BigQuery データ キャンバスで分析する データキャンバス（Data canvas） データキャンバスの使い方や使用例については、以下の記事も参考になります。 blog.g-gen.co.jp 使用方法 データキャンバスを使うには、BigQuery Studio において、新しいクエリエディタのタブを開く + ボタンの 右にある逆三角形 を押して表示されるプルダウンメニューから「データ キャンバス」を選択します。 プルダウンから「データ キャンバス」を選択 以下のように、データキャンバスが開きます。まずは、対象のテーブルを選びます。最近開いたテーブルの履歴から選択したり、あるいは Search for data をクリックして対象テーブルを検索することもできます。 データキャンバスの画面 テーブルは複数個、キャンバスに追加できます。以下のスクリーンショットでは、架空の売上トランザクションデータと、架空の顧客マスタテーブルを追加しました。 複数テーブルをキャンバスに追加 左下に表示されている「 キャンバスアシスタントに聞く 」ボタンを押すと、キャンバス上のテーブルに、自然言語でクエリすることができます。キャンバス上では明示的にクエリや結合などを指示することもできますが、取っ掛かりがない場合はキャンバスアシスタントに聞くことで、ヒントを得ることができます。 キャンバスアシスタント スクリーンショットの例では、「2024年の売上を、売上チャンネル別に算出して」と指示しました。明示的にテーブルを指定していなくても、適切に「sales」テーブルへクエリが発行されました。また、クエリ結果はチャート（図表）でも表示されます。 キャンバスアシスタントが質問に応じてクエリを発行 クエリ結果はチャート（図表）でも表示される 複数テーブルの結合が必要な質問にも、適切にクエリが生成されました。テーブル間の結合が線でグラフィカルに表現されています。 複数テーブルの結合 キャンバスアシスタントを使う以外にも、柔軟な使い方が可能です。テーブルを選択して「クエリ」をクリックすると、SQL を記述できます。自然言語で指示して、Gemini にクエリを書かせることもできます。 テーブルを選択して「クエリ」をクリック テーブルを選択して「高度な分析」をクリックすると、BigQuery ノートブック（Colab Enterprise）を利用して、テーブルに Python を使った分析が実行できます。ここでも、ソースコードを Gemini に書かせることが可能です。 テーブルを選択して「高度な分析」をクリック テーブルを選択して「結合」をクリックすると、結合相手のテーブルを指定して、結合クエリを記述、または Gemini に書かせることができます。 テーブルを選択して「結合」をクリック データ準備（Data preparation） データ準備 （Data preparation）は、生成 AI を利用した簡易的なデータ準備ツールです。Gemini の補助のもと、データのプレビューを確認しながら自然言語でデータ変換のロジックを開発できます。 定義した data preparation は、オンデマンドに実行することも、スケジュールに基づいて定期的に実行することもできるので、簡易的な ELT（ETL）ワークフローとして利用可能です。 参考 : BigQuery データの準備の概要 データ準備（Data preparation） データ分析情報（Data insights） データ分析情報 （Data insights）機能を BigQuery テーブルに対して実行すると、テーブルのメタデータ（テーブルや列の説明）に基づいて、Gemini が自然言語の質問とそれに対応する SQL クエリを複数個生成します。 この機能により、テーブルに対して分析を始めるに当たっての取っ掛かりとなる問いや、それに対応する SQL を速やかに生成することができます。データ分析情報（Data insights）は、データ分析の初速を向上するための機能であるといえます。 参考 : BigQuery でデータ分析情報を生成する データ分析情報（Data insights）で生成された問いとクエリ メタデータ自動生成 メタデータ自動生成 を使うと、BigQuery テーブルとその列の説明（Description）を自動生成することができます。Gemini がテーブルデータに基づいてテーブルの性質やカラムの性質を判断して、自然言語による説明を生成してくれます。 参考 : Generate data insights in BigQuery - Generate table and column descriptions 生成された説明（Description） 詳細は以下の記事を参照してください。 blog.g-gen.co.jp SQL 変換支援 Gemini in BigQuery には、他方言の SQL を BigQuery で使う GoogleSQL へ変換する機能が備わっています。 当機能は、以下のような SQL 方言に対応しています（一部抜粋）。 Amazon Redshift SQL Apache HiveQL IBM Netezza SQL Teradata Apache Spark SQL Azure Synapse T-SQL IBM DB2 SQL MySQL SQL Oracle SQL, PL/SQL, Exadata PostgreSQL SQL PrestoSQL（Trino） Snowflake SQL SQL Server T-SQL SQLite 当機能を使用するには、BigQuery Studio のエディタを使用します。以下のように、変換元と変換後のクエリを対照させて確認できます。また変換ルールを定義することで、変換方法をカスタマイズすることもできます。 Gemini による SQL 変換支援 詳細は、以下の公式ドキュメントを参照してください。 参考 : インタラクティブな SQL トランスレータを使用してクエリを変換する 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

Google Cloud Next Tokyo '25 の「Next Tokyo イベントアンバサダー」に選出いただきました G-gen の堂原です。当記事は、Google Cloud Next '25 Tokyo の2日目に行われた ブレイクアウトセッション「 最新技術で実現する Pokémon Trading Card Game Pocket のスケーラブルな運用とコスト最適化 」 のレポートです。 他の Google Cloud Next Tokyo '25 の関連記事は Google Cloud Next Tokyo '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 全体アーキテクチャ Spanner Pre-splitting で大規模なスパイクに立ち向かう 概要 Spanner について Spanner の負荷分散の仕組みと課題 スパイクに対するこれまでの対処法 Pre-splitting C4A インスタンスへの移行 概要 C4A インスタンスとは 導入効果 セッションの概要 本セッションでは、月間アクティブユーザ数が 5,100 万人（2024 年度第 4 四半期平均）にも達するスマートフォン向けゲームアプリ Pokémon Trading Card Game Pocket （以下、ポケポケ）のアーキテクチャ及び、インフラ基盤で取り入れられている最新技術について紹介されました。 全体アーキテクチャ ポケポケのインフラ基盤は、API Server と Battle Server の 2 つの Google Kubernetes Engine（GKE） クラスタで構成されています。　API Server はプレイヤー情報の管理やマッチメイキングを行い、Battle Server では実際の対戦処理が行われます。API Server のデータベースとしては Spanner が稼働しています。 実際のアクセス数は非公表であるものの、本基盤に対して以下の規模の負荷試験を実施したとのことです。 API Server に対して 70 万 RPS（Request Per Second）以上 Spanner に対して 1,000 万 QPS（Query Per Second）以上 スパイクは 3 分間で 9 倍以上 Spanner Pre-splitting で大規模なスパイクに立ち向かう 概要 前半パートでは、Spanner を運用するにあたって考える必要があるスプリット戦略について、ポケポケで採用されている Pre-splitting という機能が紹介されました。 Spanner について Spanner （または Cloud Spanner）は Google Cloud が提供するフルマネージドデータベースであり、強整合性を保証しつつ水平スケーリングが可能なデータベースとなっています。 Spanner については、以下の記事で解説していますのでご参照ください。 blog.g-gen.co.jp Spanner の負荷分散の仕組みと課題 Spanner では、データが スプリット という単位に分割されて管理されています。Spanner の処理部である ノード が、それぞれに割り当てられたスプリットの処理を行うことで負荷分散が行われています。スプリットは負荷状況に応じて、自動で追加や削除が行われます。 参考 : スキーマの概要  |  Spanner  |  Google Cloud そんなスプリットですが、自動で追加されるまでには時間がかかるため、スパイク時には追加が間に合わずレイテンシが悪化するという課題があります。 スパイクに対するこれまでの対処法 スパイクに対してスプリットの追加が間に合わないという課題に対して、これまでは ウォームアップ を実施することで対処されていたそうです。ローンチ前にダミーデータであらかじめ負荷をかけておくことで、十分なスプリットを確保した状態でローンチするという手法となります。 ただし、この方法にも以下のような課題がありました。 ローンチ後に発生するスパイクに対しては使用できない ウォームアップ中は人が張り付いて負荷状況を調整しないといけない ミスをするとスプリットを割りすぎてコスト増加につながる Pre-splitting Pre-splitting は、特定のテーブル・インデックスのスプリットを予め設定することができる機能です。この機能により、ローンチ時など、スパイクが想定されるタイミングで事前にスプリットを増やすことができます。 本機能を使うことにより、ポケポケではスプリット不足が起因のレイテンシ悪化がほぼ無くなったとのことです。ただし、以下のような配慮すべきポイントについても紹介されていました。 スプリットポイント（どの値でスプリットを分けるか）が不適切な場合、特定のスプリットに負荷が集中する（ホットスポット） スプリット数の予測 スプリット数が少ないと、ホットスポットが発生する スプリット数が多いと、ノード数が減らせずコスト増加につながる スパイク後はノード数を減らすことでコスト削減が可能だが、1 ノードあたりのスプリット数が増えすぎるとパフォーマンスが低下する 目安として「1 ノード 50 スプリットを超える際は慎重に」と紹介されていました C4A インスタンスへの移行 概要 後半パートでは、GKE クラスタのインスタンスとして C4A インスタンス を導入した事例について紹介されました。 C4A インスタンスとは C4A インスタンスは、Google Cloud が提供する Compute Engine マシンタイプの一種です。2024 年 10 月 31 日に一般提供が開始され、Arm ベースの Axion プロセッサが搭載されています。メモリについても、均一メモリアクセス（UMA）が採用されており、一貫したパフォーマンスを提供することができます。 参考 : Compute Engine の汎用マシン ファミリー  |  Compute Engine Documentation  |  Google Cloud 導入効果 Google 公式ブログ において、x86 ベースのインスタンスと比べて費用対効果が最大 65% 向上すると記載されている C4A インスタンスですが、ポケポケ環境においては、それまで採用していた Tau T2D インスタンスと比較して以下のような費用対効果が得られました。 API Server : 73% 向上 Battle Server : 11% 向上 また、Tau T2D インスタンスではメモリアクセスに起因して発生していた CPU 性能の劣化についても、先述の通り UMA が採用されている C4A インスタンスでは発生することが無くなったそうです。 更に、セッションではマシンタイプの移行に際して以下のような利点が紹介されていました。 Tau T2D インスタンスから C4A インスタンスへの移行が容易であった C4A インスタンスは CPU 使用率に対して、比例的に許容 RPS が伸びた 他のマシンタイプの場合、ハイパースレッディングがあると CPU 使用率 50 % を境に性能の劣化が見られることがある エネルギー効率も最大 60% と高く、環境に配慮したマシンタイプとなっている 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

Google Cloud Next Tokyo '25 の「Next Tokyo イベントアンバサダー」に選出いただきました G-gen の堂原です。当記事は、Google Cloud Next '25 Tokyo の2日目に行われた ブレイクアウトセッション「 AI Agent で実現するメルカリの顧客エンゲージメント変革 」 のレポートです。 他の Google Cloud Next Tokyo '25 の関連記事は Google Cloud Next Tokyo '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 高まる期待と新たなニーズ 新たな顧客体験の創造 メルカリ社の事例紹介 概要 採用理由 導入時の障壁 デモ セッションの概要 本セッションでは、Google Cloud が提供するカスタマーサービス業務向けのプロダクト群である Customer Engagement Suite の概要と、メルカリ社での導入事例が紹介されました。 高まる期待と新たなニーズ はじめに Google Cloud 社の鈴木氏より、企業における AI 利用の進化について説明されました。 主にチャットボットから始まった AI の利用は、AI エージェントを経てより自律した、能動的に動く存在へと進化していくだろうと期待されています。 そんな中、顧客体験への期待値は大きく上がってきています。顧客ごとにパーソナライズされた顧客体験の提供や能動的な働きかけを通じて、カスタマーサービスをクロスセル・アップセルを創出するような部門にしたいという希望があるようです。 新たな顧客体験の創造 Google では、顧客体験を創造するにあたって次のようなビジョンがあると紹介されました。 プロアクティブにお客様一人ひとりに寄り添い 自然な顧客体験をお届けする そして、このビジョンを達成するための 3 つの柱が紹介されました。 高度な個別最適化（ハイパーパーソナライゼーション） 能動的な働きかけ（プロアクティブ） 人間らしい対話（ヒューマンライク） Google では上記のような顧客体験を達成するために AI を用いたプロダクトを開発しています。Customer Engagement Suite はそのようなプロダクトを束ね、エンドツーエンドでカスタマーサービス業務を形成するものとなっています。 Customer Engagement Suite は世界中で導入されており、以下のようなビジネスインパクトを与えていると説明されました。 メルカリ社の事例紹介 概要 後半パートでは、メルカリ社の宮坂氏より、メルカリ社での Customer Engagement Suite の導入事例について、具体的には採用理由や導入時の障壁、デモなどが紹介されました。 採用理由 まずメルカリ社のありたい姿と、これまでの課題について紹介されました。「困りごと」は、顧客にとっては快適なサービス利用を阻害するものでしかなく、短時間で解決することが重要である一方、従来のサポート体制では問題解決までに 50 時間程度かかることもあったそうです。 そこで次のような理由からメルカリ社では Customer Engagement Suite 採用を決めたとのことです。 24 時間、多言語での問い合わせ対応が可能 人によるサポートとなった場合、AI が事前に状況を整理し、案内作成に必要なナレッジを自動提示してくれる メルカリ社では Google Cloud をベースとしたマイクロサービスのシステムを構築しており、他の Google Cloud プロダクトとの連携がシームレス 導入時の障壁 Customer Engagement Suite 導入時は、日々アップデートされていくことによるナレッジの少なさに苦戦したとのことです。Customer Engagement Suite を知るために、また、Google Cloud の製品開発チームにメルカリ社を知ってもらうために、両者は日々コミュニケーションを行ったそうです。 デモ 最後に、実際に開発した顧客サポートシステムのデモが動画で紹介されました。以下、動画の内容を一部抜粋して紹介します。 顧客画面：担当者による対応となった際の、AI によるこれまでの要約 担当者画面：顧客の問い合わせ履歴や社内ドキュメントに基づいた、AI による回答文の提案 担当者画面：対応完了後作成する必要のあるサマリーの自動生成 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の奥田です。当記事は、Google Cloud Next '25 Tokyo の2日目に行われたブレイクアウトセッション「 Gemini CLI で実現する AI Agent 時代のプロダクト開発 」のレポートです。 他の Google Cloud Next Tokyo '25 の関連記事は Google Cloud Next Tokyo '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Gemini CLI とは Gemini CLI の機能 入力モード Context Engineering MCP サポート Gemini CLI を用いたデモ デモの内容 1. 自然言語で SQL を生成して BigQuery でデータ分析 2. ウェブサイトに追加する動画を生成 3. Cloud Run にデプロイ 関連記事 セッションの概要 本セッションでは、Gemini CLI の新機能の紹介、及び Gemini CLI を用いたデモが発表されました。 当セッションの紹介にあたり、事前の理解が必須なのが、 Gemini Code Assist という Google のソリューションです。Gemini Code Assist は AI によるコーディング支援を提供するサービスであり、バックエンドでは Gemini が使用されています。 Gemini Code Assist では、VS Code や IntelliJ といった IDE 上で、コード生成・補完、リファクタリング、コード変換、テスト作成などの開発作業をAI が支援します。 参考 : Gemini Code Assist | AI coding assistant 参考 : Gemini Code Assist の概要 2025年4月に行われた Google Cloud Next では Gemini Code Assist Agents が発表されました。 Gemini Code Assist agents は、ソフトウェア開発ライフサイクル全体を支援する エージェント機能の総称 です。その中核となるのが、Gemini Code Assist の エージェントモード （Agent mode）です。 参考 : Agent mode Gemini Code Assist の Agent mode を使うと、例えば仕様書に基づいてゼロからアプリケーションを開発するといった、包括的な作業を AI に依頼できます。詳細な事例については、以下の記事をご参照ください。 blog.g-gen.co.jp Agent mode は IDE 上で動作しますが、特に VS Code で実行される Agent mode のバックエンドでは、 Gemini CLI が使用されます。 加えて、Gemini CLI ではコマンドラインターミナル上でも、自律的にマルチステップのタスクを実行することができます。 当セッションでは、この Gemini CLI の用例などが紹介されました。 Gemini CLI とは Gemini CLI とは、ターミナルから直接 Gemini の機能を利用できるオープンソースの AI エージェントです。 組み込みツールとローカルまたはリモートの MCP サーバーを組み合わせた ReAct (React) ループを使用できます。 具体的には、以下の用途で利用します。 コード生成 ファイル管理 ツールの呼び出し 他のアプリとの連携 コンテキストの理解 blog.g-gen.co.jp Gemini CLI の機能 当セッションでは、Gemini CLI の様々な機能が紹介されました。 入力モード 入力モードは2種類あります。 1.Interactive Prompt デフォルトのモードです。 対話をしながら指示を出すモードです。 2.Non-Interactive Prompt CLI 上のコマンドとして呼び出し回答を得るモードです。 ユースケースとしては、 他のツール中心で利用する場合 や、 インテグレーション で利用します。 Context Engineering コンテキストを管理することにより、Gemini CLI の精度をコントロールできます。Gemini CLI で精度を向上するには、 コンテキストをピンポイントに提供する必要がある ことが強調されました。 ピンポイントな情報を提供することでノイズを減らし、より的確なアドバイスを提供できるためです。 以下2つの方法でコンテキストを提供できます。 1. Context file / Memory（GEMINI.md） コンテキストファイル（ GEMINI.md ）にプロジェクトの概要やツールの内容、コーディング規約、命名規則などを自然言語で記述することで、あらかじめ コンテキストを定義 できます。 また @<file_path> コマンドで複数のファイルをインポートできます。 参考 : gemini.md 2. Conversations Conversations はセッションごとに管理され、揮発性のあるコンテキストです。必要に応じて GEMINI.md ファイルに転記する等して永続化できます。 参考 : CLI Commands MCP サポート Gemini CLI は様々な Model-Centric Prompting（以下、MCP）ツールと連携できます。 MCP は、AI モデル・エージェントと外部のツールやデータソースとのやり取り（呼び出し・入出力）を標準化する、オープンなプロトコル仕様です。 settings.json ファイルで MCP や認証方法などの設定を指定できます。 参考 : modelcontextprotocol Gemini CLI を用いたデモ デモの内容 架空の通販サイトで、 Gemini CLI を用いた以下の流れが発表されました。 自然言語で SQL を生成して BigQuery でデータ分析 ウェブサイトに追加する動画を生成 Cloud Run にデプロイ アーキテクチャは以下のとおりです。 1. 自然言語で SQL を生成して BigQuery でデータ分析 /mcp コマンドで Gemini CLI が認識している MCP サーバーが一覧表示されます。 ここで認識される MCP サーバーは、あらかじめ settings.json ファイルで定義したものです。 Gemini CLI から BigQuery MCP サーバーを呼び出し、特定のプロジェクトのデータセット一覧とデータセットのテーブル一覧をリストで表示させます。 その後、自然言語で以下のように問い合わせ、評価の高い商品を特定します。 テーブルのプロダクトの中から最も評価の高い商品を探して、プロダクトのタイトル、評価値、評価数を教えて この問い合わせにより Gemini CLI が SQL を生成し、BigQuery MCP サーバーを呼び出してタスクを完了します。 2. ウェブサイトに追加する動画を生成 あらかじめ Gemini CLI で生成したプロンプトを元にウェブサイト用の動画を生成します。 はじめに、動画作成用の画像を4枚生成します。 その後、生成した画像から4つの動画を生成し、1つの動画に統合することで、ウェブサイト用の動画が数分で完成しました。 3. Cloud Run にデプロイ Gemini CLI で自然言語で指示をし、既存のウェブサイトに動画を表示させるように指示します。 Gemini CLI に入力したプロンプトは以下のとおりです。 生成した動画を、トップページの画像と入れ替えるように挿入してください。投入した動画の横幅が常にブラウザ画面の横幅 100% になるようにして、縦横比は元のまま維持されるように HTML と CSS を修正してください。なお、動画はループするように設定し、動画以外のコンテンツはレイアウトを変更しないようにしてください その後、既存の Cloud Run のリビジョンとしてデプロイするように指示します。 Artifact Registry のパスも指定し、他の設定は変更しないように指示します。 その結果、生成した動画が表示されたウェブサイトが Cloud Run にデプロイされました。 関連記事 blog.g-gen.co.jp Risa (記事一覧) クラウドソリューション部クラウドデベロッパー課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資格保有。日々修行中です！ Follow @risa_hochiminh

G-gen の杉村です。当記事では、Google Cloud Next Tokyo '25 の、2日目のキーノートに関する速報レポートをお届けします。 Google Cloud Next Tokyo '25 イベント概要 キーノートの概要 AI 時代の変革 GKE と Cloud Run における GPU 新たな野球体験 まったく新しいデジタルバンクの設立 Gemini CLI データと AI セブン&アイ・ホールディングス セキュリティと AI Google Cloud Next Tokyo 26 関連記事 Google Cloud Next Tokyo '25 イベント概要 Google Cloud の旗艦イベントである Google Cloud Next の東京版である Google Cloud Next Tokyo '25 は、2025年8月5日(火)と6日(水)の2日間で開催されます。本年は、東京ビッグサイトで開催されました。 2日目のキーノート会場の様子 2日目のキーノート（基調講演）では例年、開発者向けの技術的な内容にフォーカスした発表が行われます。本投稿では、Google Cloud Next Tokyo '25 の第2日目のキーノートの概要をお伝えします。 G-gen Tech Blog では、Google Cloud Next Tokyo '25 に関連する記事を随時発信しています。 blog.g-gen.co.jp なお、初日のキーノートのレポートは以下の記事を参照してください。 blog.g-gen.co.jp キーノートの概要 Google Cloud Next の2日目のキーノートでは、開発者やデータエンジニア、データサイエンティスト向けの様々な Google Cloud ソリューションが紹介されました。 1日目と同じく、AI にフォーカスし、Google Cloud の AI 系プロダクトが、開発者体験やデータエンジニアリング、データ分析などを効率化することができることが示されました。またセキュリティの領域についても、AI との関連性が「AI で守る」「AI を守る」の2つの視点で語られました。 また株式会社 NPB エンタープライズ、ソニー株式会社、株式会社三菱 UFJ フィナンシャル・グループ、株式会社セブン&アイ・ホールディングスが登壇し、Google Cloud を使った事例が紹介されました。 技術的な新発表としては、 Gemini CLI GitHub Actions が発表されました（Preview）。Gemini CLI GitHub Actions では、Issue の振り分け、自動的な PR レビュー、Issue や PR 内で Gemini CLI にメンションして作業を指示するなど、Gemini CLI と GitHub が高度に統合され、開発ワークフローを自動化することができます。 参考 : AI コーディングの新たなパートナー：Gemini CLI GitHub Actions を発表 AI 時代の変革 Google Cloud カスタマーエンジニアリング 技術本部長 渕野 大輔氏 Google Cloud カスタマーエンジニアリング 技術本部長 渕野 大輔氏が登壇し、当講演では「AI 時代の変革」をテーマに、以下を紹介することが述べられました。 AI インフラ アプリのモダナイズ データとセキュリティ Google Cloud は AI に最適化されたプラットフォームであり、インフラからアプリ開発まで、エンドツーエンドの一気通貫した AI ジャーニーを提供できることが「 明確な差別化ポイントである 」と述べられました。 AI 時代の変革 これを裏付けるように、2025年4月にラスベガスで開催された Google Cloud Next '25 でも発表された、新型 TPU である Ironwood や、GB200 GPU を搭載した Compute Engine マシンタイプの提供など、Google Cloud の AI 向けインフラサービスが紹介されました。 GKE と Cloud Run における GPU Google Cloud VP & GM ブラッド カルダー氏 続けて、Google Cloud の VP & GM であるブラッド カルダー氏が登壇し、GKE と Cloud Run における GPU 提供機能などについて言及しました。 AI ワークロードにおける GKE の強み Cloud Run with GPU 新たな野球体験 株式会社 NPB エンタープライズ 執行役員デジタル事業部長 丹羽大介氏 株式会社 NPB エンタープライズの執行役員デジタル事業部長、丹羽大介氏が登壇し、日本プロ野球の観戦に AI を使った新たな体験を導入しようとしていることが発表されました。 同社は2024に全12球団の球場に、HAWK-EYE と呼ばれるトラッキングカメラを導入し、その映像をもとに AI によって動画像を描画。新たな野球観戦体験を提供することを紹介しました。 AI で描画された打球軌跡 続けてこの取り組みを支援したソニー株式会社の執行役員、平位文淳氏が登壇し、技術的な背景を紹介しました。 ソニー株式会社 執行役員 平位文淳氏 このシステムは Google Cloud 上に構築されています。また開発に当たっては、Google による TAP（Tech Acceleration Program）による支援があったと述べ、強力なパートナーシップがあったことを紹介しました。 将来的には API 経由で詳細データや自動生成コンテンツへのアクセスを、放送事業者や消費者へ提供することも視野に入れています。 アーキテクチャ コンテンツ提供 まったく新しいデジタルバンクの設立 株式会社三菱 UFJ フィナンシャル・グループ 執行役常務 山本忠司氏 株式会社三菱 UFJ フィナンシャル・グループの執行役常務 リテール・デジタル事業本部長 兼 グループ CDTO の山本忠司氏が登壇し、新サービスブランドであるエムットの事例を紹介しました。 エムットは「お金のあれこれ、まるっと」をテーマにした同行の新サービスです。 エムット 金融を取り巻く変化と多様化 同氏は、同サービスの開発にあたり、同行の店舗網とプロのアドバイスという、デジタルとリアルの「いいとこ取り」を図るべく、「まったく新しいデジタルバンクの設立」を意図したと述べます。同サービスでは、勘定系システムのフルクラウド開発を Google Cloud で行っています。 参考 : Google Cloud 、三菱 ＵＦＪ 銀行が新設するデジタルバンクの勘定系システム基盤に採用 同氏は Google Cloud が採用された理由として、信頼性（堅牢なセキュリティ）、スケーラビリティと柔軟性、高可用性とデータの一貫性などを挙げました。またデータベースとして、リージョンレベルの障害があってもサービスが止まらないことと、データの不整合が発生しないことの2点を重視したポイントとして挙げ、これを満たす Spanner を採用したことを明らかにしました。 加えてコンテナ技術の成熟や、AI と機械学習の高度なエコシステムも採用にあたってプラス要素になったと述べます。 Gemini CLI 続けて、Gemini CLI についても改めて紹介されました。 Gemini CLI はコード生成やコーディング補助だけでなく、様々な用途に使うことができます。そういった用例の1つとして、Kubernetes のトラブルシューティングが挙げられました。 Gemini CLI の用例 Gemini CLI は yaml 定義ファイルから環境情報を理解し、クラスタに接続。ログを取得して状況を把握すると、関連ソースコードを特定して修正案を提示します。Gemini CLI が単なるコーディング補助ツールではなく、クラウド環境の運用にも用いることができることが示されました。 また、Gemini CLI が MCP サーバー経由で GitHub から issue を取得して修正したり、「過去1週間の Cloud Logging のログ情報をもとに Cloud Run の最適化をして」といった指示に基づいて、Cloud Run の最大・最小インスタンス数やリソース割り当ての提案などを行う様子もデモされました。 Gemini CLI の画面 さらに、新機能である Gemini CLI GitHub Actions が発表されました。Gemini CLI GitHub Actions では、Issue の振り分け、自動的な PR レビュー、Issue や PR 内で Gemini CLI にメンションして作業を指示するなど、Gemini CLI と GitHub が高度に統合され、開発ワークフローを自動化することができます。 参考 : AI コーディングの新たなパートナー：Gemini CLI GitHub Actions を発表 Gemini CLI GitHub Actions の発表 データと AI Google Cloud GM & VP アンディ ガットマンズ氏 Google Cloud の GM & VP であるアンディ ガットマンズ氏が登壇し、Google Cloud におけるデータと AI について紹介しました。 Google Cloud におけるデータと AI MCP Toolbox 経由で AI エージェントが BigQuery、AlloyDB、Cloud SQL、Spanner などの各データベースサービスに接続できることや、Spanner や AlloyDB に搭載された高度な検索機能などが示されました。 BigQuery のデータエンジニアリングエージェントやデータサイエンスエージェントについてもデモが行われました。Colab Enterprise や BigQuery Studio のノートブック上で、自然言語による指示に基づき、AI が Python ソースコードを生成し、高度な分析を行うことができます。 データサイエンスエージェント また Looker や Looker Studio に搭載された会話型分析（Conversational Analytics）エージェントと、高度な分析を実現する Code Interpreter についても紹介されました。対話型分析 API を経由することで、自社アプリケーションにこういった機能を組み込むこともできます。 Conversational Analytics セブン&アイ・ホールディングス 株式会社セブン&アイ・ホールディングス 常務執行役員 グループ DX 本部長 西村出氏 株式会社セブン&アイ・ホールディングスの常務執行役員 グループ DX 本部長である西村出氏が登壇し、全国 21,756 店舗の POS レジ情報を統合する基盤であるセブンセントラルについて紹介しました。 セブンセントラル 次世代店舗システム セブンセントラルはデータベースとして BigQuery や Spanner、AlloyDB を採用としており、1日52億件のレコードを処理し、また店舗で発生した最新データへのアクセスを1分以内に実現します。 また次世代店舗システムでは、ストアコンピューター（1店1台）をなくし、全面クラウド化を行うという野心的な計画も示されました。その実現のため、「ハードとソフトの分離」「疎結合システムで改修スピードアップ」「クラウド上のデータを有効活用」という方針が示されました。 次世代店舗システムの方針 Google Cloud 採用の理由として、「圧倒的な信頼性」「高い柔軟性」が挙げれらました。 セキュリティと AI Google は次に、AI とセキュリティの関連性を「AI で守る」「AI を守る」の2つの視点で紹介しました。 攻撃者による AI の悪用は進んでおり、自然な日本語によるフィッシングサイトなども多く観測されています。 攻撃者による AI 悪用 これに対して、Google Cloud は「AI で守る」という視点で、セキュリティ向上に AI を利用します。Google の SIEM/SOAR 製品である Google SecOps には Gemini が組み込まれており、検出事項を AI がトリアージしたり、詳細な分析や次のステップの提案を行います。 Google Cloud のセキュリティ関連スイート Google SecOps と AI 将来的な開発計画として、AI エージェント同士が連携してセキュリティ関連タスクをこなすことを視野に入れていることが述べられました。 AI エージェント同士の連携 次に、「AI を守る」という視点では、Google Cloud の AI Protection が紹介されました。AI Protection は Security Command Center と Model Armor に統合されており、Google Cloud 環境内で「AI アセットの発見」「AI アセット保護」「AI への脅威対応」などを行い、それらの統合ダッシュボードも提供します。 AI Protection グラフィカルに AI アセットを表示して対処を提案する Gemini 以外のモデルにも対応 Google Cloud Next Tokyo 26 最後に、次回の Google Cloud Next Tokyo '26 の予告が行われました。 Google Cloud Next Tokyo '26 の日程は2026年7月30日（木）〜31日（金）で、会場は2025年と同じ、東京ビッグサイトの南展示棟です。 関連記事 Google Cloud Next Tokyo '25 の関連記事は、以下の記事一覧をご参照ください。開催期間中は、記事が随時公開されます。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の高宮です。当記事は、Google Cloud Next '25 Tokyo の1日目に行われた スポンサーセッション「 Google Cloud + GitLab で作る最高のソフトウェア開発環境の作り方 」 のレポートです。 他の Google Cloud Next Tokyo '25 の関連記事は Google Cloud Next Tokyo '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 GitLab合同会社の概要 なぜ開発環境は整備すべきか 迅速に開発環境を展開 人とAIによるレビューで品質の向上 セキュリティスキャンの必須化と脆弱性への対応 快適な開発環境の構築例 開発環境の構成 チームワークを健康に保てるレビュー環境 DevSecOpsのアーキテクチャ 関連記事 セッションの概要 本セッションでは、 GitLab合同会社の小松原つかさ氏から GitLab と Cloud WorkStations を使用した快適なソフトウェア開発環境が紹介されました。 GitLab合同会社の概要 GitLab合同会社は、開発ライフサイクル全体を単一のアプリケーションで提供するDevOpsプラットフォーム GitLab の日本法人です。 GitLab は2年連続で『2024 Gartner® Magic Quadrant™ for DevOps Platforms』においてリーダーの1社として評価され、さらに「実行能力」と「ビジョンの完全性」で最上位の評価を獲得しています。 また、Google Cloud パートナー アワードの「2025 テクノロジー パートナー オブ ザ イヤー - アプリケーション開発 - DevOps」を受賞しています。 参考： GitLab named a Leader in the Gartner® Magic Quadrant™ 参考： GitLabのパートナープロフィール なぜ開発環境は整備すべきか 以下の3つの観点で開発環境を整備する必要があり、これらを満たすことで、 品質とアジリティ の向上が期待できると発表されました。 迅速に開発環境を展開 ソフトウェア開発において各開発者がローカルPCに開発環境を構築して開発をすることが多いです。その際、手順書に沿って環境を構築するケースでは、開発者のスキルによっては、独力では環境構築が完結しない場合があります。 また、複数の開発を同一の端末で行っている場合、ツールのバージョンを誤ってアップ・ダウングレードする場合があります。 環境構築がうまくいかない場合や、ツールのバージョン差異が発生した場合、開発者本人だけではなく、他の開発者の時間も奪われてしまうので、 迅速に展開可能な開発環境 の整備は重要です。 人とAIによるレビューで品質の向上 ソフトウェア開発において生成AIの利用に伴い、成果物が完成する速度は飛躍的に向上しています。そうした状況の中では、レビュワーには日々大量のレビュー依頼があり、パンクしている状況で、レビューが形骸化することがあります。また、レビューの指摘内容によっては、チームワークが悪化する可能性もあります。 このような課題に対処するために、人だけでなく、 AIも活用する ことで 高速に必ずレビューを実施できる環境 を構築することが重要です。また、コードだけでなく 実際に動作する環境 でのレビューを実施できる環境の構築も品質向上のためには必要です。 セキュリティスキャンの必須化と脆弱性への対応 セキュリティスキャンとは、アプリケーションのソースコードや実行環境を自動的に分析し、潜在的な脆弱性を検出するプロセスです。脆弱性は、攻撃者にとって格好の侵入経路となり、脆弱性を放置することは、不正アクセス、データ漏洩、サービス停止などのサイバー攻撃を招く大きなリスクとなります。セキュリティインシデントが発生すると、企業のブランドイメージや顧客からの信頼は大きく損なわれる可能性があります。また、訴訟や多額の賠償金など、法的なリスクや経済的な損失を伴う可能性があります。 このようなリスクを未然に防ぐためにも、 セキュリティスキャンジョブをスキップできない環境 と、進化する 生成AIでのコーディング支援 を使用して、脆弱性に適切に対応し修正することが重要です。 快適な開発環境の構築例 開発環境の構成 本セッションでは、快適な開発環境として、 Cloud WorkStations と GitLab を使用した構成が紹介されました。 Cloud WorkStations クラウド上で動作するフルマネージドの仮想開発環境を提供するサービスです。開発者は、ローカルPCに複雑な開発環境を構築することなく、ブラウザやローカルのIDE（統合開発環境）から、セキュアで一貫性のある開発環境にアクセスできます。 参考： Cloud Workstations の概要 Cloud WorkStations を使用し、環境をイメージ化し展開することで、全開発者で迅速に同一のセキュアな環境で開発を行うことが可能です。 また Cloud WorkStations については、以下の当社記事で詳しく解説しています。 blog.g-gen.co.jp GitLabは、Gitリポジトリ管理、CI/CD、セキュリティ、プロジェクト管理など、ソフトウェア開発のライフサイクル全体をカバーする統合DevSecOpsプラットフォームです。 GitLab を使用することでソースコード管理だけでなく、ビルド、テストとセキュリティスキャンの実施、実際に動作する環境へのデプロイも行うことが可能です。また、開発における工程管理もソースコードと連動させて行うことができます。 参考： GitLab チームワークを健康に保てるレビュー環境 チームワークを健康に保てるレビューのために、 GitLab Duo のコードレビュー機能を使用します。マージリクエストで Duo をアサインし、レビューを実施します。AI がレビューすることで、以下のメリットがあります。 必ずレビューが実施される 開発者が指摘の内容を受け入れやすい また、事前に Duo にコードレビューの観点を指示することで、人がレビューする時と近いレベルでレビューが可能になります。そうすることで、人は要件が網羅されているかなど、本質的な部分の確認に注力することが可能です。 参考： GitLab Duo 参考： Have GitLab Duo review your code DevSecOpsのアーキテクチャ 下図に示すアーキテクチャで、DevSecOps を実現します。 GKE でのアーキテクチャ Cloud Run でのアーキテクチャ ソースコードのビルド時にSAST（Static Application Security Testing）、Google Cloud へのアプリデプロイ後にDAST （Dynamic Application Security Testing）を行うことで、開発の早期の段階で脆弱性を検出し、対処することが可能です。 GitLab では、公式 CI/CD テンプレートが提供されており、特別な設定をすることなくセキュリティスキャンを有効にできます。 参考： Static Application Security Testing (SAST) 参考： Dynamic Application Security Testing (DAST) このようにして検出した脆弱性に対して、 GitLab Duo などの AI を活用し修正を行うことで、形骸化を回避し、確実に脆弱性に対処する環境を構築することができます。 関連記事 blog.g-gen.co.jp 高宮 怜 (記事一覧) クラウドソリューション部クラウドエクスプローラ課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。

Google Cloud Next Tokyo '25 の「Next Tokyo イベントアンバサダー」に選出いただきました G-gen の堂原です。当記事は、Google Cloud Next '25 Tokyo の2日目に行われた ブレイクアウトセッション「 もう手放せない！Gemini の NotebookLM、Deep Research、Canvas で思考を加速 」 のレポートです。 他の Google Cloud Next Tokyo '25 の関連記事は Google Cloud Next Tokyo '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 思考を変革する、新しい情報活用ワークフロー 概要 Deep Research NotebookLM Canvas AbemaTV のユースケースご紹介 概要 文章作成 調査業務 社内データ活用 関連記事 セッションの概要 本セッションでは、 Google の AI ツールである Deep Research 、 NotebookLM 及び Canvas の活用方法と、株式会社 AbemaTV 社での実際の活用例について紹介されました。 思考を変革する、新しい情報活用ワークフロー 概要 前半パートでは、Google Cloud 社の服部氏より、Deep Research、NotebookLM 及び Canvas を活用した新しい情報活用ワークフローが紹介されました。 業務において情報を活用するための大きなフローである 情報の収集 集約・整理・分析 アウトプット それぞれのフェーズにおける、Deep Research、NotebookLM、Canvas の有用性が紹介されました。 Deep Research Deep Research は、以下のような情報収集における必要なフローを数分で完結させることができます。 Deep Research は与えられたプロンプトをただ文字通りに検索するのではなく、その目的を理解し、調査を複数のステップに落とし込みます。そして最大 100 種類のウェブサイトを自動的に検索し、得られたデータを統合し、整合性が取れるように適宜修正します。調査結果は最終的に引用元へのリンクを含んだレポートとして出力されます。 NotebookLM NotebookLM では、議事録等といった社内データや Deep Research が出力したレポートなどの情報の集約・整理・分析をすることができます。 NotebookLM は Google Docs や Google Slide、YouTube、PDF 等といった複数のデータ形式に対応しています。また、全ての回答には適切な引用元へのリンクが付いているため、ハルシネーションが起きにくいです。更に、音声としての出力も可能という特徴も持っています。 Canvas Canvas は与えられた情報の整理を行いアウトプットとします。文章としてのアウトプットはもちろん、HTML・CSV・JavaScript によるページを作成することも可能です。 AbemaTV のユースケースご紹介 概要 後半パートでは、AbemaTV 社の上田氏より、AbemaTV 社における Google の生成 AI ツールの具体的な活用例が紹介されました。 AbemaTV 社では、文章作成や調査業務、社内データ活用といった業務において Gemini が活用されています。 文章作成 文章作成においては、メールや議事録、企画の提案資料などといった様々な文章作成を Gemini が支援しています。Gemini は資料のたたき台を瞬時に作成し、メール作成や要約・議事録作成を大幅に効率化します。また企画創案のアイデア出しも支援してくれます。 具体例として、Gmail でのメール作成支援や Gem をプレゼンテーション作成アドバイザーとして活用しているケースが紹介されました。 Gmail でのメール作成支援 Gem による、プレゼンテーション作成アドバイザー 調査業務 調査業務においては Deep Research が活用されています。市場調査や競合分析を Gemini が代行し、膨大な情報からレポートの作成を行ってくれます。 社内データ活用 社内データ活用においては NotebookLM が用いられています。 具体例として、社員の自己紹介スライドをデータソースとしたオンボーディング用 NotebookLM や、文章化されたデザインポリシーに関する FAQ システムとして NotebookLM を活用するケースが紹介されました。 オンボーディング NotebookLM デザインポリシー NotebookLM 関連記事 blog.g-gen.co.jp 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara