G-gen の佐々木です。当記事では、Cloud Run の最小インスタンス数を、特定の時間帯で自動的にスケーリングさせる処理を実装していきます。 前提知識 Cloud Run について Cloud Run のコールドスタート サービスレベルの最小インスタンス数の設定 構成 スケーリングの対象となる Cloud Run サービスのデプロイ 各種ファイルの準備 作成するファイルについて Cloud Run functions にデプロイするファイル ディレクトリの作成 main.py requirements.txt Cloud Scheduler で使用するファイル scaleout.json scalein.json 各種サービスの作成 シェル変数の設定 Pub/Sub トピック サービスアカウント Cloud Run functions 用サービスアカウント Pub/Sub 用サービスアカウント Cloud Run functions Cloud Scheduler ジョブ 作成するジョブについて スケールアウト用ジョブ スケールイン用ジョブ 動作確認 前提知識 Cloud Run について Cloud Run には Cloud Run services と Cloud Run jobs、そして Cloud Functions から統合された Cloud Run functions の3種類がありますが、当記事における Cloud Run は Cloud Run services を指すものとし、また Cloud Run functions についてはそのまま Cloud Run functions と記載します。 当記事は Cloud Run の応用的な使い方を解説するため、Cloud Run そのものに関する解説はしません。 Cloud Run の解説については以下の記事をご一読ください。 blog.g-gen.co.jp Cloud Run のコールドスタート 最小インスタンス数を0に設定した Cloud Run では、リクエストを受信するとコンテナインスタンスが起動し、処理を行います。 このように最小インスタンス数が0の場合、リクエストがない間は CPU、メモリなどのコンピュートリソースを使用しないため、リソース使用量に応じた料金が発生せず、コストを非常に安く抑えることができます。 その反面、常にコンピュートリソースを使用する場合と比べて、インスタンスを起動する時間だけレイテンシが発生します。これを コールドスタート といいます。 Cloud Run におけるコールドスタート Cloud Run で実行しているアプリケーションでコールドスタートによるレイテンシが許容できない場合、最小インスタンス数を 1以上 に設定し、リクエストを処理できるコンピュートリソースを常に確保しておきます。 この場合、当然ながらコンピュートリソースの料金は、最小インスタンスの数だけ常に発生してしまいます。 最小インスタンス数が0の場合と1以上の場合のコンピュートリソース使用料 また、コールドスタートを回避できるのは、最小インスタンス数として設定した数のコンテナインスタンス（常時起動されているインスタンス）だけです。 リクエストの増加によりコンテナインスタンスのスケールアウトが起こると、新たに起動したコンテナインスタンスに送信されたリクエストはコールドスタートの影響を受けます。 したがって、多くのリクエストを処理しなければならない、かつコールドスタートが許容できないアプリケーションでは、予測されるリクエストの規模に応じて最小インスタンス数を調整する（もしくは Cloud Run を使用しない）ことになります。 このように、Cloud Run におけるコストの削減とコールドスタートの回避はトレードオフの関係にあり、アプリケーション実行基盤として Cloud Run を選択する際のノックアウトファクターとなり得ます。 参考： Cloud Run pricing サービスレベルの最小インスタンス数の設定 従来の Cloud Run では、最小インスタンス数はリビジョンレベルで設定を行い、最小インスタンスを変更するたびに新たなリビジョンをデプロイする必要がありました。 リビジョンレベルで最小インスタンス数を更新する しかし、2024年3月のアップデートにて、 サービスレベルの最小インスタンス数の設定 として、新たなリビジョンをデプロイすることなく最小インスタンス数の設定を変更できるようになりました。 サービスレベルで最小インスタンス数を更新する 参考： Minimum instances (services) 構成 当記事では、Cloud Run の最小インスタンス数に対して、スケジュールベースの自動スケーリングを行う処理を実装していきます。 ユースケースとして、特定の時間帯にリクエストが増加することがわかっているサービスを想定します。 リクエストが増加する時間帯は Cloud Run の最小インスタンス数を増加させることでコールドスタートの影響を無くし、リクエストが少ない時間帯は最小インスタンス数を0にしてコストを節約します。 当記事では、以下のように時間帯によって最小インスタンス数を変更するようにします。 この場合、スケールアウトは 12:00 、スケールインは 19:00 に行います。 時間帯 最小インスタンス数 0:00~12:00 0 12:00~19:00 3 19:00~0:00 0 実装には、以下のサービスを使用していきます。 Cloud Scheduler Cloud Pub/Sub Cloud Run functions 使用するサービスと構成図 スケーリングの対象となる Cloud Run サービスのデプロイ まず、スケジュールベースのスケーリングを設定する対象となる Cloud Run サービスを作成します。 当記事では、このサービス自体の処理内容は重要ではないので、Google Cloud が提供するサンプルのコンテナイメージを使用してデプロイします。 # スケーリングの対象となる Cloud Run サービスを作成 $ gcloud run deploy hello \ --image us-docker.pkg.dev/cloudrun/container/hello \ --region = ${LOCATION} \ --allow-unauthenticated このコマンドでサービスをデプロイした場合、サービス名は hello となります。 最小インスタンス数は、デフォルトで0に設定されています。 各種ファイルの準備 作成するファイルについて 当記事では、ワーキングディレクトリに以下のファイルを作成していきます。 . ├── scalein.json ├── scaleout.json └── src ├── main.py └── requirements.txt Cloud Run functions にデプロイするファイル ディレクトリの作成 Cloud Run functions にデプロイする各種ファイルを配置するディレクトリを作成します。 ディレクトリ名はなんでもよいですが、当記事では src とします。 # src ディレクトリを作成 $ mkdir src main.py 当記事では Python 3.12 を使用していきます。 # Python のバージョン $ python -V Python 3 . 12 . 0 src ディレクトリ内に main.py ファイルを作成します。 ファイルの中身は以下のようにします。 # src/main.py from google.cloud.run_v2.services.services import ServicesClient import functions_framework import base64, json client = ServicesClient() @ functions_framework.cloud_event def update_service (cloud_event): # Cloud Scheduler から送信されてきたメッセージを処理 data = json.loads(base64.b64decode(cloud_event.data[ "message" ][ "data" ]).decode()) project_id = data[ "project_id" ] location = data[ "location" ] service_name = data[ "service_name" ] min_instance_count = int (data[ "min_instance_count" ]) # スケーリング対象の Cloud Run サービスの情報を取得 service = client.get_service(name=f "projects/{project_id}/locations/{location}/services/{service_name}" ) # Cloud Run サービスの最小インスタンス数を更新 service.scaling.min_instance_count = min_instance_count # リビジョンを更新せず、サービスに対して最小インスタンス数を設定 # Cloud Run サービスの更新 client.update_service(service=service) main.py には、Cloud Scheduler から（Pub/Sub を介して）スケーリング対象の Cloud Run サービスの名前や、スケーリング後の最小インスタンス数などの情報を受け取り、それを元に最小インスタンス数を変更する処理を実装します。 requirements.txt src ディレクトリ内に requirements.txt を作成し、使用する外部ライブラリを記載します。 当記事では以下のライブラリを使用していきます。 # src/requirements.txt functions-framework== 3.5 . 0 google-cloud-run== 0.10 . 5 Cloud Scheduler で使用するファイル Cloud Scheduler のジョブを作成する際に使用する、Cloud Run functions に送信するメッセージを記述したファイルを作成します。 最小インスタンス数のスケールアウトとスケールインのそれぞれに対応したファイルを作成していきます。 scaleout.json ワーキングディレクトリ内に scaleout.json を作成し、以下のように記述します。 { " project_id ":" {Cloud Runが存在するプロジェクトID} ", " location ":" asia-northeast1 ", " service_name ":" hello ", " min_instance_count ":" 3 " } このメッセージを受信した Cloud Run functions は、対象となる Cloud Run サービスの最小インスタンス数を 3 に変更します。 scalein.json ワーキングディレクトリ内に scalein.json を作成し、以下のように記述します。 { " project_id ":" {Cloud Runが存在するプロジェクトID} ", " location ":" asia-northeast1 ", " service_name ":" hello ", " min_instance_count ":" 0 " } このメッセージを受信した Cloud Run functions は、対象となる Cloud Run サービスの最小インスタンス数を 0 に変更します。 各種サービスの作成 シェル変数の設定 シェル変数として、 PROJECT 変数にサービスを作成するプロジェクト、 LOCATION 変数にサービスを作成するリージョンを設定しておきます。 当記事では asia-northeast1 リージョンを使用していきます。 PROJECT =myproject LOCATION =asia-northeast1 Pub/Sub トピック Cloud Scheduler からのメッセージを中継する Pub/Sub のトピックを作成します。 当記事では topic-run-scaler という名前で作成します。 # Pub/Sub トピックの作成 $ gcloud pubsub topics create topic-run-scaler サービスアカウント Cloud Run functions 用サービスアカウント Cloud Run functions に紐付けるサービスアカウントを作成します。 当記事では sa-run-scaler という名前で作成します。 # Cloud Run functions 用サービスアカウントの作成 $ gcloud iam service-accounts create sa-run-scaler サービスアカウントに対して、Cloud Run の設定を変更するための roles/run.developer ロールを設定します。 # サービスアカウントに Cloud Run の編集権限を付与 $ gcloud run services add-iam-policy-binding hello \ --region = ${LOCATION} \ --member =" serviceAccount:sa-run-scaler@ ${PROJECT} .iam.gserviceaccount.com " \ --role =" roles/run.developer " また、Cloud Run functions のコードからサービスアカウントの認証情報を取得できるように、 roles/iam.serviceAccountUser ロールも設定します。 # サービスアカウントにサービスアカウントユーザー権限を付与 $ gcloud projects add-iam-policy-binding ${PROJECT} \ --member =" serviceAccount:sa-run-scaler@ ${PROJECT} .iam.gserviceaccount.com " \ --role =" roles/iam.serviceAccountUser " Pub/Sub 用サービスアカウント Cloud Scheduler と Cloud Run functions を中継する Pub/Sub 用のサービスアカウントを作成します。 このサービスアカウントには Cloud Run を呼び出すための権限を付与しますが、対象の Cloud Run がまだ作成されていないので、一旦は作成だけしておきます。 当記事では sa-run-scaler-trigger という名前で作成します。 # Pub/Sub 用 サービスアカウントの作成 $ gcloud iam service-accounts create sa-run-scaler-trigger Cloud Run functions src ディレクトリ内のファイルを使用して Cloud Run functions の関数をデプロイします。関数の名前は run-scacler とします。 関数のトリガーとして先ほど作成した Pub/Sub トピックを設定し、Pub/Sub 用に作成したサービスアカウントも --trigger-service-account として指定します。 # Cloud Run functions のデプロイ $ gcloud functions deploy run-scaler \ --gen2 \ --runtime = python312 \ --entry-point =" update_service " \ --region = ${LOCATION} \ --source = ./src \ --run-service-account =" sa-run-scaler@ ${PROJECT} .iam.gserviceaccount.com " \ --trigger-topic = topic-run-scaler \ --trigger-service-account =" sa-run-scaler-trigger@ ${PROJECT} .iam.gserviceaccount.com " Cloud Run functions のデプロイが完了したら、Pub/Sub 用のサービスアカウントに Cloud Run functions を呼び出す権限を付与します。 gCloud Run functions add-invoker-policy-binding コマンドを使用することで、必要な権限を付与することができます。 # サービスアカウントに Cloud Run functions の起動元権限を付与 $ gcloud functions add-invoker-policy-binding run-scaler \ --region = ${LOCATION} \ --member =" serviceAccount:sa-run-scaler-trigger@ ${PROJECT} .iam.gserviceaccount.com " Cloud Scheduler ジョブ 作成するジョブについて Cloud Run functions のトリガーとなる Cloud Scheduler ジョブを作成していきます。 スケールアウトとスケールインで異なる設定値が必要になるため、ジョブは2つ作成します。 Cloud Run functions は Cloud Scheduler から送信されたメッセージの内容に応じた処理を行うため、各ジョブは同一の Pub/Sub を経由して、同一の Cloud Run functions 関数にメッセージを送ります。 スケールアウト用ジョブ スケールアウト用のジョブは scaleout.json ファイルに記述したメッセージを送信するように設定します。 このメッセージを受信した Cloud Run functions は、対象となる Cloud Run サービスの最小インスタンス数を 3 に変更します。 ジョブの実行タイミングは --schedule に unix-cron 文字列形式で設定します。 当記事では、毎日12時（ 0 12 * * * ）のタイミングでスケールアウトを実行するようにします。 # Cloud Run のスケールアウト用のジョブをトリガーするスケジュール $ gcloud scheduler jobs create pubsub schedule-run-scaler-scaleout \ --location = ${LOCATION} \ --schedule =" 0 12 * * * " \ --topic = topic-run-scaler \ --message-body-from-file = ./scaleout.json \ --time-zone =" Asia/Tokyo " スケールイン用ジョブ スケールイン用のジョブは scalein.json を使用して作成します。 このファイルに記述したメッセージを受信した Cloud Run functions は、対象となる Cloud Run サービスの最小インスタンス数を 0 に変更します。 ジョブの実行タイミングは、毎日19時（ 0 19 * * * ）に設定します。 # Cloud Run のスケールイン用のジョブをトリガーするスケジュール $ gcloud scheduler jobs create pubsub schedule-run-scaler-scalein \ --location = ${LOCATION} \ --schedule =" 0 19 * * * " \ --topic = topic-run-scaler \ --message-body-from-file = ./scalein.json \ --time-zone =" Asia/Tokyo " 動作確認 Cloud Run のコンソールから「コンテナ インスタンス数」の指標を確認すると、設定した時間にジョブが実行され、Cloud Run サービスの最小インスタンス数の変更が行われていることがわかります。 コンテナインスタンス数の推移 12:00 にスケールアウトのジョブが実行され、最小インスタンス数が3に設定されています。 3つのコンテナインスタンスが常に idle もしくは active になっており、この3つで処理できるリクエスト量であれば、コールドスタートの影響を受けることはありません。 19:00 にスケールインのジョブが実行され、翌日の 12:00 までは最小インスタンス数が 0 になります。 idle もしくは active 状態のインスタンスがないときにリクエストがあると、そのリクエストに対する処理はコールドスタートの影響を受けますが、コンピュートリソースの使用コストを最小限に抑えることができます。 「課金対象のコンテナ インスタンス時間」の指標を確認すると、最小インスタンス数が3（1以上）になっている時間帯のみ、インスタンスのリソース使用料が発生し続けていることがわかります。 最小インスタンス数が1以上の時間帯のみインスタンスが課金対象となっている 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。2024年4月のイチオシ Google Cloud アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに BigQuery で history-based optimizations が Preview 公開 Security Command Center で Enterprise ティアが公開 (GA) Cloud Armor の Managed Protection Plus が Cloud Armor Enterprise に改称 GKE で Pod の burst（バースト）が利用できるように Google Cloud Next '24 が開催 Llama 3 が Vertex AI Model Garden から利用可能に Looker Studio Pro でチームワークスペースに閲覧者が利用可能に BigQuery で LIKE ANY（LIKE SOME）と LIKE ALL が利用可能に Verified Peering Providerが公開 Cloud Run の Direct VPC egress が GA（一般公開） Google Meet で会議に参加したままデバイス間の移動が可能に Vertex AI Search and Conversation が Vertex AI Agent Builder に改名 Chronicle Security Operations が Google Security Operations に改名 Google Sheets から直接 Looker Studio レポートを作成可能に Looker Studio で「タイムラインチャート」が使えるように Gemini での SQL 生成が、全ての BigQuery プロジェクトで有効化可能に BigQuery に Microsoft Entra で認証可能に はじめに 月ごとの Google Cloud アップデートのうち、特にイチオシなものをまとめています。 ある程度の事前知識が必要な記載となっています。サービスごとの前提知識は、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp またリンク先の公式ガイドは英語版にしないと最新情報が反映されていない場合がありますためご注意ください。 BigQuery で history-based optimizations が Preview 公開 Use history-based optimizations (2024-04-01) BigQuery で history-based optimizations（履歴ベースの最適化）が Preview 公開。 過去のクエリの実行計画に基づき、2回目以降のパフォーマンスが改善していく。ALTER PROJECT 句でプロジェクト・リージョン単位で有効化できる。 ALTER PROJECT `user_project` SET OPTIONS ( `region-us.default_query_optimizer_options` = ' adaptive=on ' ); Security Command Center で Enterprise ティアが公開 (GA) Enterprise tier (2024-04-02) Security Command Center で従来の Standard、Premium に加え Enterprise ティアが公開 (GA)。 Amazon Web Serivces（AWS）に対応しておりマルチクラウド管理。将来的には Microsoft Azure にも対応予定。Chronicle と統合され SIEM/SOAR 機能も備える。 1年間からのサブスクリプション契約が可能。 参考記事 : グーグル、新たなセキュリティサービス--AWSやAzureに対応 （ZDNET） また、以下の記事も参照。Google Cloud Next '24 では、デモ画面が公開された。 blog.g-gen.co.jp 写真はセッションレポートより Cloud Armor の Managed Protection Plus が Cloud Armor Enterprise に改称 Cloud Armor Enterprise overview (2024-04-03) Cloud Armor（Google CloudのフルマネージドWAF）の上位ティアの Managed Protection Plusが Cloud Armor Enterprise に改称。同時に、Pay as You Go（年間ではなく月払い）での支払いが GA。 Standard との差は機械学習を使った Adaptive Protection、強固な DDoS 保護、脅威インテリジェンス等。 GKE で Pod の burst（バースト）が利用できるように Configure Pod bursting in GKE (2024-04-04) GKE で Pod の burst（バースト）が利用できるように。 たとえばポッドの起動時など、一時的に高いリソースが必要なときにだけ、リソースを一時的に余分に割り当て（バースト）できる。 リソース割り当てをピークに合わせなくていいため、料金の節約に繋がる。解説は以下の記事を参照。 blog.g-gen.co.jp Google Cloud Next '24 が開催 2024年4月9日(火)から11日(木)までの3日間、米国ネバダ州のラスベガスで、Google Cloud Next '24 が開催された。当社の現地参加メンバーによる総括が、以下から閲覧できる。 blog.g-gen.co.jp また、以下の記事一覧から、セッションレポートを確認可能。 blog.g-gen.co.jp Llama 3 が Vertex AI Model Garden から利用可能に Use Llama models (2024-04-18) Meta 社が2024年4月18日に発表した新しい生成 AI 基盤モデル「Llama 3」が、Vertex AI Model Garden から利用可能に。Meta による発表と同日。 Looker Studio Pro でチームワークスペースに閲覧者が利用可能に Roles and permissions (2024-04-18) Looker Studio Pro でチームワークスペースに閲覧者（Viewer）ロールが付与できるようになった。 従来はワークスペースはあくまで共同編集用の箱であり、「投稿者」以上しか使えず、閲覧権限管理に使えなかった。 Looker Studio Pro による運用負荷軽減がさらに期待できる。 Looker Studio Pro の詳細な解説は以下の記事を参照。 blog.g-gen.co.jp BigQuery で LIKE ANY（LIKE SOME）と LIKE ALL が利用可能に Quantified LIKE operator (2024-04-18) BigQuery の SQL で LIKE ANY（LIKE SOME）と LIKE ALL が使えるように (GA)。 WHERE 句が少しシンプルに書けるほか、また、同じ構文を使える他の DB エンジンからの SQL 移行工数が削減できる。 WITH Words AS ( SELECT ' Intend with clarity. ' AS value UNION ALL SELECT ' Secure with intention. ' UNION ALL SELECT ' Clarity and security. ' ) SELECT * FROM Words WHERE value LIKE ANY ( ' Intend% ' , ' %intention% ' ); /*------------------------+ | value | +------------------------+ | Intend with clarity. | | Secure with intention. | +------------------------*/ Verified Peering Providerが公開 Verified Peering Provider overview (2024-04-23) Verified Peering Provider が公開（GA）。Google が認証した ISPにより「Google Workspace や Cloud APIs 専用のインターネットアクセス回線」を提供するためのサービス形態。従来からある Direct Peering / Carrier Peering の代替となり得るもの。 Cloud Run の Direct VPC egress が GA（一般公開） Direct VPC egress with a VPC network (2024-04-24) Preview だった Cloud Run の Direct VPC egress が GA（一般公開）。 旧機能である VPC アクセスコネクタでは「一度スケールアウトするとスケールインできず、料金がかさむ」という大きな課題があった。今回の Direct VPC egress は料金が発生しないほか、帯域やレイテンシに優れる。 以下の紹介記事も参照。 blog.g-gen.co.jp Google Meet で会議に参加したままデバイス間の移動が可能に Seamlessly transfer between devices during a Google Meet call (2024-04-24) Google Meet で、会議に参加したままデバイス間の移動が可能に。 外出中にモバイルデバイスから Meet に入り、自宅についたら PC で入り直すときなどに、抜けたり再参加しなくても、別デバイスに移動できる。 Vertex AI Search and Conversation が Vertex AI Agent Builder に改名 Vertex AI Agent Builder release notes - April 24, 2024 (2024-04-24) Vertex AI Search and Conversation が Vertex AI Agent Builder に改名。 当サービスはもともと「Generative AI App Builder」という名称であり、2023年8月の GA 時に「Vertex AI Search and Conversation」に改名され、現在の「Vertex AI Agent Builder」へと変遷。 以下の紹介記事も参照。 blog.g-gen.co.jp Chronicle Security Operations が Google Security Operations に改名 Google Security Operations release notes - April 25, 2024 (2024-04-25) Chronicle Security Operations がリブランディングして Google Security Operations （Google SecOps）に改名。 Google Security Operations は SIEM や SOAR を含む統合的なセキュリティプラットフォーム。 Google Sheets から直接 Looker Studio レポートを作成可能に Create a Looker Studio report from Google Sheets (2024-04-25) Google Sheets から直接 Looker Studio レポートを作成可能に。 Google Sheets の Extentions（拡張機能）メニューから「Create a new report」で、直接 Looker Studio レポートを作成できるようになった。 Looker Studio で「タイムラインチャート」が使えるように Timeline chart reference (2024-04-25) Looker Studio で新しい表のタイプである「タイムラインチャート」が使えるように。開始日付・終了日付があるデータを可視化するときに便利。 以下の紹介記事も参照。 blog.g-gen.co.jp Gemini での SQL 生成が、全ての BigQuery プロジェクトで有効化可能に Write queries with Gemini assistance (2024-04-29) Gemini での SQL 生成が、全ての BigQuery プロジェクトで有効化可能に（Preview）。これまでは Google に申請が必要だったがこれからは誰でも Gemini による SQL 生成が試用可能。 利用前に、必要な API を有効化する必要はある。 BigQuery に Microsoft Entra で認証可能に Access BigQuery data in Power BI with Workforce Identity Federation and Microsoft Entra (2024-04-29) Power BI から BigQuery 内のデータにアクセスする際、Microsoft Entra (旧 Azure AD を含む製品グループ) のユーザーで認証・認可できるように。 Workforce Identity Federation の仕組みを利用して、Google Cloud の IAM Role と紐づけることができる。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の山崎です。2024年4月25日に Looker Studio で タイムラインチャート が使用可能となりました。このグラフを使ってガントチャートを作成する方法を解説します。 Looker Studio とは 作成したガントチャート データソースの準備 タイムライングラフの作成 新規レポートの作成 データソースを追加 タイムラインの作成 スタイルの調整 表示の確認 注意点 Looker Studio とは Looker Studio とは Google Cloud が提供する完全クラウドベースの BI ツールで、無料で利用することができます。関連する製品として、Looker Studio Pro や Looker があります。以下の記事もご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 作成したガントチャート 2024年4月25日に Looker Studio で タイムラインチャート が使用可能となりました。 このタイムラインチャートを使って、以下のようなガントチャートを作成しました。2つのプロジェクトの工程の実施時期をグラフで表示しています。 タイムライングラフによるガントチャート Looker Studio では、適切なデータソースが準備できていれば、このようなグラフを 数クリックで作成 できます。 参考 : Timeline chart reference データソースの準備 今回は、BigQuery 上に以下のデータを用意し、Looker Studio から参照します。 データソース 参考までに当該テーブルのDDL、DML を以下に記載します。実行する際には、プロジェクトID、データセット名を変更してください。 -- DDL CREATE TABLE {{project_id}}.{{dataset_name}}.timeline( serial_number integer ,project string,process string,start_date date ,end_date date ,duration integer ,progress integer ) -- DML INSERT INTO {{project_id}}.{{dataset_name}}.timeline VALUES ( 1 , ' A案件 ' , ' 要件定義 ' , cast ( ' 2024-04-01 ' as date ), cast ( ' 2024-04-10 ' as date ), 9 , 100 ), ( 2 , ' A案件 ' , ' 設計 ' , cast ( ' 2024-04-08 ' as date ), cast ( ' 2024-04-19 ' as date ), 11 , 100 ), ( 3 , ' A案件 ' , ' 製造 ' , cast ( ' 2024-04-22 ' as date ), cast ( ' 2024-05-10 ' as date ), 18 , 60 ), ( 4 , ' A案件 ' , ' 試験 ' , cast ( ' 2024-05-13 ' as date ), cast ( ' 2024-05-24 ' as date ), 11 , 0 ), ( 5 , ' A案件 ' , ' リリース ' , cast ( ' 2024-05-27 ' as date ), cast ( ' 2024-05-29 ' as date ), 2 , 0 ), ( 6 , ' B案件 ' , ' 要件定義 ' , cast ( ' 2024-04-22 ' as date ), cast ( ' 2024-04-26 ' as date ), 4 , 80 ), ( 7 , ' B案件 ' , ' 設計 ' , cast ( ' 2024-04-30 ' as date ), cast ( ' 2024-05-10 ' as date ), 10 , 10 ), ( 8 , ' B案件 ' , ' 製造 ' , cast ( ' 2024-05-13 ' as date ), cast ( ' 2024-05-17 ' as date ), 4 , 0 ), ( 9 , ' B案件 ' , ' 試験 ' , cast ( ' 2024-05-20 ' as date ), cast ( ' 2024-05-24 ' as date ), 4 , 0 ), ( 10 , ' B案件 ' , ' リリース ' , cast ( ' 2024-05-29 ' as date ), cast ( ' 2024-05-31 ' as date ), 2 , 0 ) タイムライングラフの作成 新規レポートの作成 先ほど登録したデータソースを元に、Looker Studio でタイムライングラフを作成していきます。 Looker Studio へログインし、「空のレポート」を選択します。 データソースを追加 データソースとして、「BigQuery」を選択後、前段で作成したデータソースを選択し、「レポートに追加」を押下します。 タイムラインの作成 初期表示時に、グラフが表示されていた場合は、そのグラフを削除します。 その後、「グラフを追加」を押下し、「タイムライン」を選択します。 まず、開始日時に「start_date」、終了日時に「end_date」を設定します。 開始日時は必須 ですが、 終了日時は、期間に「duration」を設定することで代替可能 です。 参考： チャートを設定する 次に、A案件の要件定義、A案件の設計といった階層構造で表示したいため、行ラベルに「project」、バーラベルに「process」を設定します。 また、各タスクの進捗率も表示したいので、ツールチップに「progress」を設定します。 更に表示順を整えるために、「serial_number」の昇順で並び替えを行います。 スタイルの調整 最後に、工程の名前毎に色が変わる表示とするために、「スタイル」タブで配色を「Color by bar label」に設定します。 表示の確認 以上で、冒頭にお見せしたガントチャートが作成できました。 マウスをホバーすると進捗率（progress）も表示されていることがわかります。 ガントチャートの表示を確認 マウスホバー時の表示内容 注意点 今回使用したタイムラインチャートでは、プロジェクトの各工程の開始日と終了日を可視化することができましたが、 チャートから工程の進捗率を読み取るような表示をさせることはできません でした。 また、予実管理をするために実績値を持たせようとしましたが、「開始日が入力されているが終了日が入力されていないデータ」はグラフに表示されないため、 タイムラインチャートで予実管理をするのは難しい といえます。 そのためタイムラインチャートは、以下のようなユースケースが想定されます。 ある期間における各タスクの期間の妥当性、重なり度合いの検証（今回のケース） キャンペーンのような一定期間発生するイベントと、その期間の前後の売上データの推移による施策の効果測定（タイムラインチャート + 効果測定対象の日別の折れ線グラフ） 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

本記事では、Google の AI 言語モデルである Gemini の機能と Cloud SQL のデータ管理機能を組み合わせたツールである Gemini in Database について説明します。 はじめに Gemini in Database とは Database Studio とは Cloud SQL とは Preview 版のサービスに関する注意点 手順の概要 Cloud SQL インスタンス・データベースを作成 Gemini in Database を有効にする Cloud SQL Studio へ接続するためのユーザを作成 Cloud SQL Studio へ接続 自然言語でクエリを実行 テーブルの削除 関連記事 はじめに Gemini in Database とは Gemini in Database は、Google が開発したマルチモーダル生成 AI モデルである Gemini を利用して、Google Cloud（旧称 GCP）のデータベースの開発と管理を強化する新しい機能です。本機能は Google Cloud Next 24 にて発表されました。 記事執筆時点で、以下の機能があります。 自然言語で SQL コードを作成・要約 （Database Studio を利用） データベースの安全性を向上 （Database Center を使用） パフォーマンスの改善 （Query Insights を使用） セキュリティ強化 （AlloyDB for PostgreSQL 及び Cloud SQL にて対応） データベースの移行支援 参考 : Gemini in Databases overview  |  Gemini for Google Cloud 本記事では『 1. 自然言語で SQL コードを作成・要約 （Database Studio を利用）』をご紹介します。 Database Studio とは Database Studio は、データベースを管理するためのウェブベースのインターフェースです。 データベースの作成と管理、データのインポートとエクスポート、SQL クエリの実行などのさまざまな機能を提供します。 ウェブベースのため、コマンドでの操作に慣れていない方でも視覚的に操作ができます。 記事執筆時点では以下のデータベースに対応しています。 Cloud SQL AlloyDB for PostgreSQL Spanner 本記事では『 1. Cloud SQL 』での利用シーンをご紹介します。 AlloyDB for PostgreSQL 及び Spanner については詳しくは以下の記事で紹介しています。用途や目的に応じてデータベースを選定してください。 参考 : AlloyDB for PostgreSQLを徹底解説！ - G-gen Tech Blog 参考 : Cloud Spanner を徹底解説！ - G-gen Tech Blog Cloud SQL とは Cloud SQL はマネージドの RDBMS サービスです。 MySQL、PostgreSQL、SQL Server など、さまざまなデータベース エンジンをサポートしています。詳しくは以下の記事で紹介しています。 blog.g-gen.co.jp Preview 版のサービスに関する注意点 当記事を執筆した2024年4月現在では、Cloud SQL Studio はプレビュー公開であり、本番環境での利用は推奨されておりません。プレビュー版のサービスを使うことに関する注意点は以下の記事で解説しています。 blog.g-gen.co.jp 手順の概要 当記事でご紹介する試用手順は、以下の通りです。 Cloud SQL インスタンス・データベースを作成 Gemini in Database を有効にする Cloud SQL Studio へ接続するためのユーザを作成 Cloud SQL Studio へ接続 自然言語でクエリ実行 テーブル削除 Cloud SQL インスタンス・データベースを作成 今回はサンプルデータとして架空の顧客リストを利用しました。 顧客番号 氏名 性別 生年月日 年齢 居住地 累計売上高 GS00001 山田 太郎 男 1990-04-29 31 兵庫県 3704 GS00002 田中 花子 女 2005-09-30 20 兵庫県 5709 … … … … … … … 作成手順は公式ドキュメントを参考にしました。 CSV ファイルを使用したエクスポートとインポート  |  Cloud SQL for PostgreSQL  |  Google Cloud Gemini in Database を有効にする 本機能を有効にします。 利用するプロジェクトでデータベースが作成された後、「 データベースセンター 」にアクセスし、Gemini を有効にします。 Gemini in Database の有効設定画面 Gemini が有効になっていない場合、今回の自然言語での処理が実施できないのでご注意ください。 Cloud SQL Studio へ接続するためのユーザを作成 Cloud SQL Studio への接続は root ユーザーからの接続は不可能のため、ユーザーアカウントを作成します。 Cloud SQL のタブより、「ユーザー」を選択し、ユーザー名とパスワードを入力します。 パスワードは次のステップで利用するため、安全な場所に保管します。 Cloud SQL Studio へ接続 Cloud SQL のタブより、「Cloud SQL Studio」を選択します。 今回認証するデータベースを選択した後、先ほど作成したユーザー名とパスワードを入力しログインします。 自然言語でクエリを実行 クエリ記入欄左端にある、「コーディングをサポート」を押下します。 プロンプトを入力します。 プロンプトに入力した内容は下記です。 兵庫県のお客様で、売上高が 3,000円以上のお客様の数を教えてください 右下の「 Generate 」を押下するとSQL文が作成されます。 生成された SQL 文を挿入し、エディタタブの「 実行 」を押下すると SQL を実行できました。 テーブルの削除 自然言語を使って、今回の検証で利用したテーブルを削除できるか試します。 プロンプトを入力します。 Companiesテーブルを削除してください 前ステップと同様に、エディタタブの「実行」を押下することで該当のテーブルを削除することが出来ました。 この様に、Database Studio を利用することで自然言語を用いて SQL クエリを生成、データベースの管理等を行うことが出来ました。 関連記事 blog.g-gen.co.jp 奥田 梨紗 (記事一覧) クラウドソリューション部クラウドデベロッパー課 前職はベトナムのIT企業。 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。日々修行中です！ Follow @risa_hochiminh

G-gen の藤岡です。当記事では、Google Cloud (旧称 GCP) の Artifact Registry で不要になったイメージを自動削除する クリーンアップポリシー を紹介します。 前提知識 Artifact Registry 保管イメージへの課金 クリーンアップポリシー クリーンアップポリシーとは 削除ポリシーと保持ポリシー 詳細 条件 制約 ドライラン Terraform 対応 適用方法 前提 リポジトリの作成 ポリシーファイルの用意 クリーンアップポリシーの設定（ドライラン） イメージのプッシュ ログの確認 実行 結果の確認 前提知識 Artifact Registry Artifact Registry は、コンテナイメージや言語パッケージを保管するサービスです。 単体で使うほかに、Google Cloud のサービス（例 : Cloud Run、Cloud Functions 等）では自動で Artifact Registry にイメージが保管される場合もあります。 保管イメージへの課金 デフォルトでは、Artifact Registry に保管されたイメージは削除しない限り残ります。ストレージ料金は $0.10/GB/月（0.5GB 超えた場合）のため、使い方によってはストレージ料金が肥大化する可能性もあります。 クリーンアップポリシーを使うことで、保管イメージの増加によるストレージ料金の肥大化への対処が自動化できます。 クリーンアップポリシーを使わずに、自前のプログラムで過去のイメージを削除する際は以下の記事をご参照ください。 blog.g-gen.co.jp 参考: Artifact Registry の料金 クリーンアップポリシー クリーンアップポリシーとは クリーンアップポリシー とは、Artifact Registry に保存されたアーティファクト（コンテナイメージ等）を、事前に設定したポリシーにもとづいて自動で削除するための機能です。 2024年4月現在では、 Preview (プレビュー) 版として公開されています。 参考 : Configure cleanup policies 削除ポリシーと保持ポリシー クリーンアップポリシーでは、 削除ポリシー と 保持ポリシー という2種類のポリシーを定義できます。これらのポリシーは リポジトリに対して 設定します。削除ポリシーは削除するイメージの条件を、保持ポリシーは保持するイメージの条件を指定します。（条件については後述） 注意点は、 保持ポリシーのみを設定しても、保持対象外のイメージは削除されない 点です。削除ポリシーは単体で機能しますが、保持ポリシーは削除ポリシーと組み合わせる必要があります。 例として以下のクリーンアップポリシーが設定されたリポジトリの挙動は、タグの有無は問わず最新の3バージョンを保持し、それ以外のイメージは削除されます。 タグの有無を問わずイメージを削除（削除ポリシー） 最新の3バージョンのみを保持（保持ポリシー） 詳細 条件 クリーンアップポリシーの対象となるイメージには以下の条件を設定できます。 タグの状態（ tagState ）※必須条件 タグのプレフィックス（ tagPrefixes ） バージョンのプレフィックス（ versionNamePrefixes ） パッケージ名のプレフィックス（ packageNamePrefixes ） アップロードされてからの期間（ olderThan / newerThan ） 保持するバージョン数（ keepCount ）※保持ポリシーでのみ設定可能 制約 クリーンアップポリシーには以下の制約があります。 クリーンアップポリシーによる削除と保持がトリガーされるのは、1回/日 削除ポリシーによってトリガーされる削除は、リポジトリごとに最大300,000件/日 リポジトリあたりのクリーンアップポリシー数は10 ドライラン クリーンアップポリシーにはドライランモードがあります。 挙動は Cloud Logging で確認できます（ドライランのためリソースに変化はない）。このログは データアクセス監査ログ として記録されますが、デフォルトではデータアクセス監査ログが有効になっていません。 そのためドライランの結果を確認するには、Artifact Registry API のデータアクセス監査ログで データ書き込み を有効にします。 参考 : クリーンアップ ポリシーの監査ログエントリ Terraform 対応 クリーンアップポリシーは Terraform の google_artifact_registry_repository リソースでサポートされています。 参考: google_artifact_registry_repository 適用方法 前提 ここでは、前述の例で挙げた「タグの有無は問わず最新の3バージョンを保持し、それ以外のイメージは削除する」クリーンアップポリシーを適用します。 リポジトリの作成 任意のリポジトリを作成します。 fujioka@cloudshell:~ (XXX)$ gcloud artifacts repositories create test-repo \ --repository-format=docker \ --location=asia-northeast1 Create request issued for: [test-repo] Waiting for operation [projects/XXX/locations/asia-northeast1/operations/31e7a62e-11aa-4a0e-8b7a-90e0ccdbd461] to complete...done. Created repository [test-repo]. fujioka@cloudshell:~ (XXX)$ ポリシーファイルの用意 クリーンアップポリシーはコンソールからも設定できますが、JSON ファイルを作成し、コマンドラインからも実行できます。ここでは以下の policy.json という JSON ファイルを用意します。 [ { " name ": " delete-any ", " action ": { " type ": " Delete " } , " condition ": { " tagState ": " any " } } , { " name ": " keep-latest-3 ", " action ": { " type ": " Keep " } , " mostRecentVersions ": { " keepCount ": 3 } } ] クリーンアップポリシーの設定（ドライラン） ドライランで適用します。 fujioka@cloudshell:~ (XXX)$ gcloud artifacts repositories set-cleanup-policies test-repo \ --location=asia-northeast1 \ --policy=policy.json \ --dry-run Updated repository [test-repo]. Dry run is enabled. [ { "action": { "type": "DELETE" }, "condition": { "tagState": "ANY" }, "name": "delete-any" }, { "action": { "type": "KEEP" }, "mostRecentVersions": { "keepCount": 3 }, "name": "keep-latest-3" } ] fujioka@cloudshell:~ (XXX)$ コンソールでは、以下のように表示されます。 イメージのプッシュ 任意のイメージをプッシュし、5つのイメージが保存されている状態にします。 ログの確認 ドライランモード（protoPayload.request.validateOnly）で実行された結果が出力されます。 今回は「タグの有無は問わず最新の3バージョンを保持し、それ以外のイメージは削除する」クリーンアップポリシーを適用しました。 実際のリソースとしては5つのイメージがリポジトリにある状態のため、削除対象として2つのイメージが記録されています（protoPayload.request.names）。 { " protoPayload ": { " @type ": " type.googleapis.com/google.cloud.audit.AuditLog ", " authenticationInfo ": { " principalEmail ": " service-00000000000@gcp-sa-artifactregistry.iam.gserviceaccount.com " } , " requestMetadata ": { " callerIp ": " private ", " callerSuppliedUserAgent ": " stubby_client ", " requestAttributes ": { " time ": " 2024-04-02T07:27:58.171276147Z ", " auth ": {} } , " destinationAttributes ": {} } , " serviceName ": " artifactregistry.googleapis.com ", " methodName ": " google.devtools.artifactregistry.v1.ArtifactRegistry.BatchDeleteVersions ", " authorizationInfo ": [ { " resource ": " projects/XXXXXX/locations/asia-northeast1/repositories/test-repo/packages/- ", " permission ": " artifactregistry.versions.delete ", " granted ": true , " resourceAttributes ": {} } ] , " resourceName ": " projects/XXXXXX/locations/asia-northeast1/repositories/test-repo/packages/- ", " request ": { " parent ": " projects/XXXXXX/locations/asia-northeast1/repositories/test-repo/packages/- ", " validateOnly ": true , " @type ": " type.googleapis.com/google.devtools.artifactregistry.v1.BatchDeleteVersionsRequest ", " names ": [ " projects/XXXXXX/locations/asia-northeast1/repositories/test-repo/packages/hello-world/versions/sha256:5d0cc9349f2e675542decde8be21c94264714a7ece91fefdb4f722b18c544510 ", " projects/XXXXXX/locations/asia-northeast1/repositories/test-repo/packages/hello-world/versions/sha256:cb1a3c1190265153e7b50ccfde70e3683eba5326cfae8ac68632e1a6b9985573 " ] } } , " insertId ": " 1ndsju6d19n5 ", " resource ": { " type ": " audited_resource ", " labels ": { " project_id ": " XXXXXX ", " method ": " google.devtools.artifactregistry.v1.ArtifactRegistry.BatchDeleteVersions ", " service ": " artifactregistry.googleapis.com " } } , " timestamp ": " 2024-04-02T07:27:58.162187524Z ", " severity ": " INFO ", " logName ": " projects/XXXXXX/logs/cloudaudit.googleapis.com%2Fdata_access ", " operation ": { " id ": " projects/XXXXXX/locations/asia-northeast1/operations/29bfca3e-4a01-4895-8840-b7dfd92ad07c ", " producer ": " artifactregistry.googleapis.com ", " first ": true } , " receiveTimestamp ": " 2024-04-02T07:27:58.429334137Z " } 実行 ドライランモードではなく実際に削除まで行う場合は、コマンドラインで --no-dry-run をつける、またはコンソールから アーティファクトを削除 を選択します。 参考 : リポジトリにポリシーを適用する 結果の確認 クリーンアップポリシーに従い、2つのイメージが削除されました。 { " protoPayload ": { " @type ": " type.googleapis.com/google.cloud.audit.AuditLog ", " authenticationInfo ": { " principalEmail ": " service-00000000000@gcp-sa-artifactregistry.iam.gserviceaccount.com " } , " requestMetadata ": { " callerIp ": " private ", " callerSuppliedUserAgent ": " stubby_client ", " requestAttributes ": { " time ": " 2024-04-02T13:28:08.653796809Z ", " auth ": {} } , " destinationAttributes ": {} } , " serviceName ": " artifactregistry.googleapis.com ", " methodName ": " google.devtools.artifactregistry.v1.ArtifactRegistry.BatchDeleteVersions ", " authorizationInfo ": [ { " resource ": " projects/XXXXXX/locations/asia-northeast1/repositories/test-repo/packages/- ", " permission ": " artifactregistry.versions.delete ", " granted ": true , " resourceAttributes ": {} } ] , " resourceName ": " projects/XXXXXX/locations/asia-northeast1/repositories/test-repo/packages/- ", " request ": { " parent ": " projects/XXXXXX/locations/asia-northeast1/repositories/test-repo/packages/- ", " names ": [ " projects/XXXXXX/locations/asia-northeast1/repositories/test-repo/packages/hello-world/versions/sha256:5d0cc9349f2e675542decde8be21c94264714a7ece91fefdb4f722b18c544510 ", " projects/XXXXXX/locations/asia-northeast1/repositories/test-repo/packages/hello-world/versions/sha256:cb1a3c1190265153e7b50ccfde70e3683eba5326cfae8ac68632e1a6b9985573 " ] , " @type ": " type.googleapis.com/google.devtools.artifactregistry.v1.BatchDeleteVersionsRequest " } } , " insertId ": " 1h9vo9pcafo ", " resource ": { " type ": " audited_resource ", " labels ": { " service ": " artifactregistry.googleapis.com ", " project_id ": " XXXXXX ", " method ": " google.devtools.artifactregistry.v1.ArtifactRegistry.BatchDeleteVersions " } } , " timestamp ": " 2024-04-02T13:28:08.644978076Z ", " severity ": " INFO ", " logName ": " projects/XXXXXX/logs/cloudaudit.googleapis.com%2Fdata_access ", " operation ": { " id ": " projects/XXXXXX/locations/asia-northeast1/operations/7ba5387a-1dda-4390-9a4c-d100313f1c18 ", " producer ": " artifactregistry.googleapis.com ", " first ": true } , " receiveTimestamp ": " 2024-04-02T13:28:08.883393539Z " } 藤岡 里美 (記事一覧) クラウドソリューション部 数年前までチキン売ったりドレスショップで働いてました！2022年9月 G-gen にジョイン。ハイキューの映画を4回は見に行きたい。 Google Cloud All Certifications Engineer / Google Cloud Partner Top Engineer 2024 Follow @fujioka57621469

G-gen の藤岡です。Looker Studio で IMAGE 関数を利用して Cloud Storage 上の画像を表示させようとしたとき、画像が表示されない場合の原因と対処法を紹介します。 注意 当記事に記載の事象と原因は、 2024年10月29日のアップデート で対処が行われ、発生しなくなりました。当記事は参考情報として記載を残します。 前提知識 Cloud Storage のアクセス制御 IMAGE 関数 事象 原因 対処法 概要 監査ログに除外プリンシパル追加 レポート確認 注意点 サービスアカウント認証を使っていてもユーザーアカウントでアクセスする 前提知識 Cloud Storage のアクセス制御 Cloud Storage のバケットには、インターネット上の任意の場所からアクセス可能な状態（パブリック公開）と、適切な権限を持つユーザーのみがアクセスできる状態（パブリック公開の禁止）のアクセス制御をかけられます。パブリック公開の禁止を設定すると、認証無しのアクセスは拒否されます。 Cloud Storage の基本については、以下の記事を参照してください。 blog.g-gen.co.jp パブリック公開を禁止したバケットでは、オブジェクトごとに 認証付き URL を発行できます。バケットに対して適切な読み取り権限を持った Google アカウントにログインした状態でこの URL にアクセスすると、オブジェクトをダウンロードすることができます。 IMAGE 関数 Looker Studio レポートでは IMAGE 関数を使うことで、表の中に画像を表示することができます。 参考 : IMAGE IMAGE 関数による画像の表示 事象 Cloud Storage で パブリック公開の禁止を設定したバケット に置かれた画像ファイルを Looker Studio で IMAGE 関数を使って表示させようとしました。画像ファイルの 認証付き URL を指定して IMAGE 関数を設定しましたが、何も表示されませんでした。 Looker Studio の計算フィールドとディメンションは以下のように設定しました。 image_url 列にはオブジェクトの認証済み URL が格納されています。 計算フィールドの設定 ディメンションの設定 Looker Studio の認証情報には「オーナーの認証情報」を使っており、対象のユーザーには実行に必要な権限が付与されています。 参考 : データの認証情報 認証情報の設定 原因 注意 当記事に記載の事象と原因は、 2024年10月29日のアップデート で対処が行われ、発生しなくなりました。具体的には、データアクセス監査ログが認証済み URL に対応し、ログが記録されるようになりました。当記事は参考情報として記載を残します。 Cloud Storage の 認証済み URL は、データアクセス監査ログが有効化されていると使用できない という制約があります。データアクセス監査ログは、Google Cloud リソースへの読み取り系 API のアクセスログを残す機能であり、デフォルトでは BigQuery を除いてオフになっています。環境によっては、監査目的で、このログを有効化している場合があります。 この制約については、公式ドキュメントの Cloud Storage での Cloud Audit Logs の制限事項 および トラブルシューティング のページに記載されています。 今回検証を行った環境では、Cloud Storage が所属するプロジェクトでデータアクセス監査ログが有効になっていたため、IMAGE 関数で適切な権限を持ったユーザーでも画像が表示されませんでした。 このプロジェクトでは、Looker Studio 経由だけでなく、認証付き URL に対してブラウザで直接アクセスしても、 403: Forbidden としてアクセスが拒否されます。 対処法 概要 データアクセス監査ログを有効にしたプロジェクトに所属する Cloud Storage バケットに配置した画像に対して、認証付き URL を使ってアクセスするには、以下の2つの方法があります。 データアクセス監査ログの Cloud Storage で「データ読み取り」を無効にする データアクセス監査ログの Cloud Storage で除外プリンシパルを追加し、そのプリンシパルに対して「データ読み取り」を無効にする 後者のほうが、影響範囲が限定的になります。ただし、この設定を行うと、Cloud Storage へのアクセス履歴が記録されなくなるため、設定する場合は自社（自組織）のセキュリティポリシーに従い、慎重に検討してください。 当記事では、後者の除外プリンシパルを追加する方法を紹介します。 監査ログに除外プリンシパル追加 当環境では、組織レベルでデータアクセス監査ログが有効になっています。 データアクセス監査ログの設定画面 除外プリンシパルに Looker Studio を閲覧するユーザーを設定します。 除外プリンシパルを設定 レポート確認 レポートに表示されていなかった画像が、表示されるようになりました。 今回の検証時は、除外プリンシパルを追加してからレポートに画像が表示されるようになるまで、数分かかりました。 レポート画面 注意点 サービスアカウント認証を使っていてもユーザーアカウントでアクセスする Looker Studio レポートでは、データソースが BigQuery の場合に、サービスアカウント認証が利用できます。 今回、追加検証として以下のように BigQuery データソースをサービスアカウント認証に変更したうえで同サービスアカウントを除外プリンシパルとして設定しましたが、画像は表示されませんでした。 ドキュメント に従ってサービスカウント認証を設定 除外プリンシパルにサービスアカウントを設定 一方で、レポートにアクセスするユーザーアカウントを除外プリンシパルに追加すると、画像が表示されました。 つまり、Cloud Storage の認証付き URL を使って Looker Studio レポート上で画像を表示させるには、レポートを表示するユーザー全員をデータアクセス監査ログの除外プリンシパルに追加する必要があります。 Looker Studio のサービスアカウント認証については以下の記事で紹介しているためご参照ください。 blog.g-gen.co.jp 藤岡 里美 (記事一覧) クラウドソリューション部 数年前までチキン売ったりドレスショップで働いてました！2022年9月 G-gen にジョイン。ハイキューの映画を4回は見に行きたい。 Google Cloud All Certifications Engineer / Google Cloud Partner Top Engineer 2024 Follow @fujioka57621469

G-gen の堂原です。本記事では Google Cloud (旧称 GCP) において、 Google Chat API を用いて他の Google Cloud 組織配下の Google Cloud プロジェクト上にチャットボットを作成する際の 落とし穴 について紹介します。 はじめに サンプル環境 結論 出来なくなること 前提 影響 グループ A を対象にチャットボットを公開する テナント A または テナント B に属する Google アカウントのみを対象にチャットボットを公開する 対処法 はじめに Google Chat API を用いることで、Google Workspace のチャットツールである Google Chat から利用するチャットボットを開発することが出来ます。 本 API と Vertex AI Search を用いたチャットボットの作成方法についてまとめた記事がありますため、具体的な使用例については当該記事をご参照ください。 blog.g-gen.co.jp サンプル環境 本記事では Google Workspace 及び Google Cloud の用語が複数登場しややこしくなっています。 そのため以下のようなサンプル環境を用いて解説を進めていきます。 企業名 どこに存在するリソースか リソース リソース名 株式会社 A Google Workpsace Google Workpsace アカウント (テナント) テナント A Google Workspace Google アカウント アカウント A Google Workspace Google グループ グループ A Google Cloud Google Cloud 組織 組織 A Google Cloud Google Cloud プロジェクト プロジェクト A 株式会社 B Google Workpsace Google Workpsace アカウント (テナント) テナント B Google Workspace Google アカウント アカウント B Google Workspace Google グループ グループ B ※ 「テナント A」、「テナント B」については、正式は Google Workspace アカウントと呼ばれますが、アカウントという名称は Google アカウントと紛らわしいため、本記事ではテナントと表現します。 結論 本記事で伝えたいことは 1 つ、 「Google Chat API の有効化は、必ずその Google Cloud プロジェクトと同じ組織に所属する Google アカウントで行うこと」 です。 前述のサンプル環境の用語を使って説明すると 「プロジェクト A の Google Chat API はアカウント A が一番最初に有効化すること」 といえます。 一部影響を受けないユースケースもありますが、以下の 出来なくなること に当てはまる場合、 Google Cloud プロジェクトの作り直しが必要となります 。 出来なくなること 前提 まず前提として、Google Chat API で作成したチャットボットは以下の対象に公開をすることができます。 特定の Google Workspace テナントに属する Google アカウントまたは Google グループ Google Cloud プロジェクトが属する組織の Google Workspace テナントに属する Google アカウント 全ての Google アカウント 言い換えると以下のとおりです。 アカウント A 及び グループ A アカウント B 及び グループ B テナント A に属する全 Google アカウント 全ての Google アカウント 参考 : Chat アプリの公開設定と公開設定 影響 Google Cloud プロジェクトが属する組織とは別の Google Workspace テナントに属する Google アカウントが Google Chat API を有効化した場合、次のようなことが出来なくなります。 Google Cloud プロジェクトが属する組織の Google Workspace テナントに属する Google グループを対象にチャットボットを公開する 特定の Google Workspace テナントに属する Google アカウントのみを対象にチャットボットを公開する 言い換えると以下のとおりです。 プロジェクトA において、アカウント B が Google Chat API を有効化すると、以下のようなことができなくなります。 グループ A を対象にチャットボットを公開する テナント A または テナント B に属する Google アカウントのみを対象にチャットボットを公開する 本影響については、想定シーンが違うものの、次の公式ドキュメントにて示唆されています。 参考 : Google Workspace の組織を統合した後で、ドメインで共有されている Chat アプリを移行する グループ A を対象にチャットボットを公開する 正常時、Google Chat API のコンソール画面にある「公開設定」にメールアドレスを記入することで、特定の Google アカウントまたは Google グループにチャットボットを公開するが可能です。 アカウント A が Google Chat API を有効化した場合、グループ A のメールアドレスをいれると、当該グループに所属する Google アカウントは、当然 Google Chat にて当該チャットボットを見つけることができるようになります。 ただしアカウント B が Google Chat API を有効化した場合、グループ A のメールアドレスを入力したとしても Google Chat で当該チャットボットを見つけることが出来ません。 メールアドレスの入力自体は可能で、特にエラーメッセージも表示されないため、本仕様を知らないと原因特定が困難になります。 テナント A または テナント B に属する Google アカウントのみを対象にチャットボットを公開する テナントレベルでチャットボットを公開するには、 Google Workspace Marketplace SDK の設定をする必要があります。 アカウント B が Google Chat API を有効化した場合、アカウント A が Google Workspace Marketplace SDK のコンソール画面にアクセスすると以下のエラーが表示されます。 お使いのアカウントは、このクラウド プロジェクトまたはアプリと同じドメインに属していません。 公式ドキュメントには明記されていませんが、以下のような状態になってしまっていると考えられます。 プロジェクト A は テナント A に紐づいている アプリ (Google Chat API) のドメインはテナント B に紐づいている そのため、アカウント A はプロジェクト A と同じ、テナント A 配下に存在してる一方で、アプリと異なる Google Workspace テナントに属していることになるため本エラーが表示されてしまうのです。 勿論、アカウント B で本画面にアクセスしても同様のエラーが表示されます。 つまり、誰も本画面を操作できなくなります。 対処法 唯一の対処法は 「Google Chat API の有効化は、必ずその Google Cloud プロジェクトと同じ組織に所属する Google アカウントで行うこと」 だけです。 また、Google Cloud APIs は有効・無効を切り替えることができますが、Google Chat API は一度有効にしてしまうと何度有効・無効を切り替えても本事象が解決することはありません。 そのため Google Cloud プロジェクトを新たに作成するしか解決策が無くなります。 堂原 竜希 (記事一覧) クラウドソリューション部データアナリティクス課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の藤岡です。本記事は Google Cloud Next '24 in Las Vegas の3日目に行われた Breakout Session「 Serverless security like a pro 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 サーバレスサービス ソフトウェアセキュリティ Automatic Security Updates（Private Preview） ネットワークセキュリティ 構成例 サーバーレス VPC アクセスコネクタ 静的 IP アドレス Secure Web Proxy Cloud Load Balancing 高可用性と低レイテンシ 高可用性（HA） 低レイテンシ 関連記事 セッションの概要 本セッションでは、 基本的な責任共有モデルの説明から、Cloud Run や Cloud Functions などサーバレスサービスを利用する際のソフトウェア、ネットワークセキュリティについての紹介がありました。 サーバレスサービス サーバレスなアプリケーション実行環境には、Cloud Functions や App Engine、Cloud Run がありますが、最近のアップデート傾向からも読み取れるように、本セッションでも Cloud Run の利用が推奨されていました。 また Cloud Functions 第二世代の実行基盤は Cloud Run であり、別のセッションでも Cloud Run のアップデートが多く紹介されていることから、今後も新機能の追加などが期待されます。 別のセッションで発表された Cloud Run のアップデートは以下の速報記事をご参照ください。 blog.g-gen.co.jp ソフトウェアセキュリティ Automatic Security Updates（Private Preview） Cloud Run のコンテナのベースイメージの自動更新が Private Preview で発表されました。ただし、利用可能時期や、機能の詳細は未定です。 Cloud Run で最新のセキュリティパッチが適用されたベースイメージを使い続けるには、現在では最新のベースイメージを選択してコンテナを再デプロイする必要がありますが、この機能では、ダウンタイムなし・明示的な操作なしでベースイメージが自動的に更新されます。 参考 : セキュリティ更新ポリシー ネットワークセキュリティ 構成例 サーバーレス VPC アクセスコネクタ ネットワークセキュリティの部分では、サーバレスサービスの下り通信（Egress traffic）をどのように管理するか、VPC とどのように接続するのが良いのか等、構成図を元に説明がありました。 サーバレスサービスの下り通信では、 サーバーレス VPC アクセスコネクタ を使うことで、VPC 内のサービスや他のプラットフォームへ接続できます。 ただし、このサーバレス VPC アクセスコネクタは常時インスタンスが立ち上がっている状態のためコストがかかる、またスケールアウトしたインスタンスは自動スケールインしない等、利用する上での考慮点があります。 今回の Next で、これまでプレビュー版であった Cloud Run の Direct VPC Egress が一般公開（GA） が発表されました。 これによって、サーバレス VPC アクセスコネクタより柔軟に VPC内のサービスや他のプラットフォームへアクセスができるようになります。 Direct VPC Egress については以下の記事をご参照ください。 blog.g-gen.co.jp 参考 : サーバーレス VPC アクセス 参考 : サーバーレスVPCアクセスコネクタのスケールインをダウンタイムなしで行う方法 静的 IP アドレス サーバレスサービスは、デフォルトではインターネット通信時に動的 IP アドレスを使用します。 Cloud NAT を経由することで、インターネットと通信する際の IP アドレスを固定 できます。この静的 IP アドレスの利用は、他のプラットフォーム側で特定の IP アドレスからの通信のみを許可する構成をとることができるため、セキュリティの向上に役立ちます。 Cloud Run での静的 IP アドレスの使用例は以下の記事をご参照ください。 blog.g-gen.co.jp Secure Web Proxy Secure Web Proxy を使ったサーバレスサービスの下り通信を保護する方法が紹介されました。 これによって、承認されたドメインへのみ通信が可能となり、不正なアクセスやデータ漏洩のリスクを軽減します。 参考 : Secure Web Proxy Cloud Load Balancing サーバレスサービスはデプロイするとそれぞれ URL が割り当てられます。この URL へ直接アクセスすることも可能ですが、以下のような Cloud Load Balancing を介した構成にすると、より高いセキュリティを実現できます。 インターネットからの通信は外部ロードバランサ経由にすることで、WAF サービスである Google Cloud Armor を使うこともでき DDoS 攻撃などのセキュリティリスクから保護することができます。 内部ロードバランサは、VPC 内部で稼働している各サービス間の負荷分散を担い、外部のインターネットとは分離された環境で動作するため、内部的なセキュリティを向上させることができます。 高可用性と低レイテンシ 高可用性（HA） サーバレスサービスはリージョンリソースです。 つまり利用者は意識しなくても、自動的に複数のゾーンにわたってリソースが冗長化されるため、高い可用性が実現できます。 低レイテンシ Cloud Load Balancing を用いることで、複数のリージョンに配置されたサービスバックエンドへのアクセスが最適化されます。 自動的にアクセス元に近いリージョンのバックエンドにトラフィックをルーティングするため、低レイテンシを実現できます。 関連記事 blog.g-gen.co.jp 藤岡 里美 (記事一覧) クラウドソリューション部 数年前までチキン売ったりドレスショップで働いてました！2022年9月 G-gen にジョイン。ハイキューの映画を4回は見に行きたい。 Google Cloud All Certifications Engineer / Google Cloud Partner Top Engineer 2024 Follow @fujioka57621469

G-gen の神谷です。本記事では、BigQuery の機能を使って、商品を意味&ランキング検索できる ChatBot を作ってみたので、そのご紹介ができればと思います。 アプリの概要 ユースケース 背景とメリット アーキテクチャ システムアーキテクチャ RAG テーブル設計 検索処理の詳細 使っている技術と実装例 BigQuery ML のテキストエンべディング関数 BigQuery リモート関数用のコネクションオブジェクト作成 Vertex AI API を BigQuery のリモート関数として登録 テキストデータからエンベディングベクトルの抽出 BigQuery ML の類似ベクトル検索関数 入力されたテキストから類似アイテムを検索 検索高速化のためのベクトルインデックス登録 Cloud Functionsによる Google Chat アプリケーション構築 アプリの概要 このアプリは Google Chat を使って、ユーザーが入力した商品検索クエリに基づいて関連する商品を見つけ出します。 BigQuery の機能を用いて、単純なベクトル（≒意味）検索ではなく、事前に集計された売れ行きランキングデータを統合することで、ユーザーのニーズに合った人気商品を提案します。 検索の流れは以下の5つのステップで構成されています。 検索 : ユーザーがキーワードを入力して商品を検索 テキストをベクトル変換 : 入力されたテキストが Text Embeddings API を使ってベクトル表現に変換される 類似ベクトルを検索・抽出 : BigQuery を使って、商品の説明文のベクトルデータから、入力テキストのベクトルに類似したものを検索・抽出 検索結果をプロンプトに組み込み、生成 AI に渡す : 抽出された類似商品の情報が、質問応答用のプロンプトに埋め込まれ、Gemini/PaLM2 API に渡される 検索結果表示 : 生成 AI が生成した自然言語の回答が、ユーザーに返される ユースケース このアプリケーションは、ファッション用品を扱う小売店での活用を想定しています。店舗のスタッフが接客中に、お客様の要望を聞きながらチャットボットを使って、お客様のニーズに最も合致する商品を検索することができます。 このチャットボットは、自然言語処理技術を用いて、ユーザーの質問の意図を理解し、最も関連性の高い商品情報を提示します。 背景とメリット 近年、リテール業界では、店舗とECサイトを組み合わせたハイブリッド型の販売スタイルが主流となりつつあります。店舗販売の強みは、販売員が直接お客様と対面で接客し、人間の言葉で商品の魅力を伝えられる点にあります。 このような環境下では、販売員一人一人が幅広い商品カテゴリの知識を持ち、お客様の曖昧な要望から適切な商品を見つけ出せることが重要になります。加えて、それらの商品の特徴や売れ行き状況も把握しておく必要があります。 本アプリケーションを活用することで、以下のようなメリットが得られます。 ベテラン販売員しか持ち得なかった高度な商品知識を、新入社員でも手軽に利用できるようになる 組織内の知識共有が効率的かつリアルタイムに行われ、「データの民主化」が促進される お客様の要望に素早く的確に応えられるようになり、顧客満足度の向上につながる つまり、生成 AI を使ってこれまで属人化していた知識やノウハウを組織全体で共有・活用することが、本アプリケーションの目的だと言えます。 アーキテクチャ システムアーキテクチャと、RAG テーブル設計は以下の通りです。 システムアーキテクチャ ユーザインターフェースとして Google Chat を使っていますが、すでに Google Workspace を導入しているユーザであれば、Google Cloud とのインテグレーションがしやすく、さっと生成 AI アプリケーションを作るのに適しています。 このアーキテクチャ図は、Google Chat をユーザインターフェースとし、Cloud Functions で BigQuery へのクエリ発行と検索・レスポンス生成処理を行い、Google Cloud のサービスを活用する構成を示しています。 RAG テーブル設計 RAG テーブル設計には、商品名、ブランド、商品説明、ベクトル表現、類似度（ベクトル距離）、人気ランキングなどのカラムが含まれています。 RAG テーブル設計 特に重要なのは、商品説明のテキストデータが Text Embeddings API でベクトル化され、類似度検索に使われている点です。これによって、単なるキーワード検索ではなく、商品特徴を踏まえた意味検索が可能になります。 検索処理の詳細 本アプリケーションの検索処理では、以下の2つのステップを踏んでいます。 意味的に類似する商品を上位10件抽出 抽出した10件の中から売れ行きの良い順に並べ替え まず、ユーザーが入力した検索クエリのテキストを Text Embeddings API でベクトル化します。次に、そのベクトルと RAG テーブル内の各商品の説明文ベクトルとのコサイン類似度を計算し、類似度が高い上位10件を抽出します。 続いて、抽出した10件の商品について、RAG テーブル内の売れ行きランキングデータを参照し、売れ行きが良い順にソートします。 以上の処理により、検索クエリに意味的に近く、かつ人気のある商品を優先的にユーザーに提示することができます。 使っている技術と実装例 このシステムでは主に以下の技術を使っています。 BigQuery ML のテキストエンべディング関数 BigQuery ML の類似ベクトル検索関数 Cloud Functions による Google Chat アプリケーション構築 これらについて順番に詳しく説明していきます。 BigQuery ML のテキストエンべディング関数 以下の記事では BigQuery ML を詳細に解説していますので、ご参照ください。 blog.g-gen.co.jp テキストエンべディングとは、テキストデータを意味を踏まえた数値表現（ベクトル）にしたもの、またはそういったベクトルに変換する技術のことを指します。 BigQuery では、以下のようにテキストエンべディングを扱うことができます。 ベクトル列のカラムを ARRAY<FLOAT64> で定義する ML.GENERATE_TEXT_EMBEDDING 関数でテキストからエンべディングベクトルを抽出する 日本語対応モデルは textembedding-gecko-multilingual 具体的な手順は以下のようになります。 BigQuery リモート関数用のコネクションオブジェクト作成 まず、Cloud Shell 上で以下のコマンドを実行し、BigQuery から Vertex AI API に接続するためのコネクションオブジェクトを作成します。 PROJECT_ID =your-project REGION =us CONNECTION_ID =connection-test bq mk --connection --location = $REGION --project_id = $PROJECT_ID \ --connection_type = CLOUD_RESOURCE $CONNECTION_ID Vertex AI API を BigQuery のリモート関数として登録 次に、BigQuery 上で以下の SQL を実行し、日本語対応のエンベディングモデル textembedding-gecko-multilingual をリモート関数として登録します。 CREATE MODEL `your-project.sample-dataset.textembedding-gecko-multilingual` REMOTE WITH CONNECTION `your-project.us.connection-test` OPTIONS(ENDPOINT = ' textembedding-gecko-multilingual@001 ' ) テキストデータからエンベディングベクトルの抽出 これで BigQuery 上から ML.GENERATE_TEXT_EMBEDDING 関数を使ってエンベディングベクトルを抽出できるようになります。 まず、下記のようなサンプルデータを用意します。 WITH sampleData AS ( SELECT ' ランニングシューズ ハイパーX、初心者向け、赤、走りやすい ' AS target_text, 1 AS sales_rank UNION ALL SELECT ' カーボン製テニスラケット、シニア向け、ブラック、ナイキ ' , 2 UNION ALL SELECT ' 防水トレイルランニングバッグ、プーマ、キッズ、ブルー ' , 3 ) select * from sampleData サンプルデータ -- サンプルデータを定義するCTE（共通テーブル式） WITH sampleData AS ( SELECT ' ランニングシューズ ハイパーX、初心者向け、赤、走りやすい ' AS target_text, 1 AS sales_rank UNION ALL SELECT ' カーボン製テニスラケット、シニア向け、ブラック、ナイキ ' , 2 UNION ALL SELECT ' 防水トレイルランニングバッグ、プーマ、キッズ、ブルー ' , 3 ), -- テキストエンベディングを生成するCTE text_embedding_table AS ( SELECT * FROM ML.GENERATE_TEXT_EMBEDDING( MODEL `your-project.sample-dataset.textembedding-gecko-multilingual`, -- 使用するテキストエンベディングモデル ( SELECT target_text AS content FROM sampleData), -- エンベディングを生成するテキストデータ STRUCT( TRUE AS flatten_json_output) -- 出力をフラットなJSONとして返す設定 ) ) -- メインのSELECT文 SELECT main.*, -- sampleDataテーブルの全列を選択 text_embedding_table.text_embedding AS target_text_embedding -- 生成されたテキストエンベディングを追加 FROM text_embedding_table -- テキストエンベディングテーブルを結合 INNER JOIN sampleData AS main -- sampleDataテーブルに別名"main"を付けて結合 ON text_embedding_table.content = main.target_text -- エンベディングを生成したテキストデータで結合 このクエリでは、商品名などのテキストデータを持つソーステーブル sampleData に対して、 ML.GENERATE_TEXT_EMBEDDING 関数を適用しエンベディングベクトルを抽出しています。 そして抽出したベクトルを元のソーステーブルと自己結合することで、ソーステーブルの各レコードにベクトル列 target_text_embedding を追加しています。 エンべディングベクトルが付与されたテーブル クエリ結果を product_ranking_emb_table という名前で永続化テーブルに保存します。 参考： ML.GENERATE_EMBEDDING 関数を使用してテキスト エンベディングを生成する  |  BigQuery  |  Google Cloud BigQuery ML の類似ベクトル検索関数 次に、ユーザから入力された検索クエリに対して、意味的に近い商品を見つけ出す必要があります。 それには検索クエリのテキストもエンベディングベクトルに変換し、商品テーブルのエンベディングベクトルとの距離（類似度）を計算します。 入力されたテキストから類似アイテムを検索 BigQueryでは VECTOR_SEARCH 関数を使うことで、ベクトル同士の類似性（距離）を計算し、類似性の高いものから取得することができます。 具体的には以下のように書けます。 -- 検索クエリのテキストからテキストエンベディングを生成するCTE WITH embedded_text AS ( SELECT * FROM ML.GENERATE_TEXT_EMBEDDING( MODEL `your-project.sample-dataset.textembedding-gecko-multilingual`, -- 使用するテキストエンベディングモデル ( SELECT " マラソンシューズ、女性向け、初心者、ピンク " AS content), -- 検索クエリのテキスト STRUCT( TRUE AS flatten_json_output) -- 出力をフラットなJSONとして返す設定 ) ) SELECT base.target_text, -- 商品のテキスト情報 base.sales_rank, -- 商品の販売ランキング distance -- ベクトル間の距離（類似度） FROM VECTOR_SEARCH( -- ベクトル検索関数 TABLE `your-project.sample-dataset.product_ranking_emb_table`, -- 検索対象のテーブル ' target_text_embedding ' , -- 検索対象のベクトル列 ( SELECT text_embedding FROM embedded_text), -- 検索クエリのテキストエンベディング top_k => 2 , -- 上位2件の結果を返す distance_type => ' COSINE ' , -- コサイン類似度を使用 OPTIONS => ' {"use_brute_force":true} ' -- ブルートフォース検索を使用 ) ORDER BY base.sales_rank ASC -- 販売ランキングの昇順で並び替え 「意味&ランキング」検索結果 ここではまず、ユーザ入力の検索クエリ「マラソンシューズ、女性向け、初心者、ピンク」をエンべディングベクトルに変換しています。 そして商品テーブル product_ranking_emb_table の各レコードのエンベディングベクトル target_text_embedding との距離を計算し、距離が小さい（類似度が高い）上位2件を抽出しています。 最後に、商品の売れ行きランキングなどのカラム sales_rank で並び替えをすることで、検索クエリに意味的に近く、かつ人気のある商品を見つけ出すことができます。 検索高速化のためのベクトルインデックス登録 また、ベクトル検索のパフォーマンスを上げるために、エンべディングベクトル列にインデックスを作成しておくことをおすすめします。BigQuery では以下のように DDL 文でベクトルインデックスが作成できます。 CREATE OR REPLACE VECTOR INDEX test_index ON your-project.sample-dataset.product_ranking_emb_table(target_text_embedding) OPTIONS(index_type = " IVF " , distance_type = " COSINE " , ivf_options = ' {"num_lists":5000} ' ) 上記の処理では、IVF（Inverted File Index）アルゴリズムによって、 num_lists で指定した数のグループに、距離が近いベクトル同士を分割します。検索時には、一旦入力したベクトルと最も距離が近いリストを特定し、そのリスト内で更に距離が近いベクトルを検索します。このベクトルインデックス化機能により、総当たり検索に比べて、高速化を実現しています。 注意点として、num_lists は5000以上の値でないと設定できないため、レコード件数が少ないと逆に検索効率が悪くなります。また、対応しているベクトルの次元数が1000以下のため、Vertex AI で提供しているマルチモーダルエンべディング API はデフォルトで1408次元のため利用不可です。こういったケースでは、ベクトルの次元数を落としてインデックスを作ることになるため、検索精度とのトレードオフを考慮することが重要です。 参考： Manage vector indexes  |  BigQuery  |  Google Cloud マルチモーダル エンベディングを取得する  |  Generative AI on Vertex AI  |  Google Cloud Cloud Functionsによる Google Chat アプリケーション構築 最後に、Cloud Fuctions と Google Chat を連携させて、チャットボットのインターフェースを作る方法について説明します。 Cloud Functions は、HTTP リクエストをトリガーにしてサーバーレスで処理を実行できる Google Cloud のサービスです。一方で Google Chat は、HTTP リクエストを送ることでボットとの対話が可能です。 したがって、Cloud Functions で HTTP リクエストを受け取る関数を作成し、その関数内で BigQuery にクエリを発行して検索・レスポンス生成処理を行い、レスポンスを Google Chat に返せば、チャットボットが実現できます。 詳細な手順は以下のサイトを参照してください。 参考： HTTP Google Chat アプリを作成する  |  Google for Developers 当記事では、main コードのイメージを記載します。 pip install Flask = = 2 . 2 . 5 google-cloud-aiplatform == 1 . 42 . 1 google-cloud-bigquery == 3 . 12 . 0 pandas = = 1 . 5 . 3 pandas-gbq == 0 . 19 . 2 requests = = 2 . 31 . 0 tenacity = = 8 . 2 . 3 gunicorn = = 21 . 2 . 0 " functions-framework>=3.* " import flask import functions_framework from google.cloud import bigquery from vertexai.preview.generative_models import GenerativeModel from typing import Any, Mapping import os # 環境変数からプロジェクトID、ロケーション、モデル名、テキストエンベディングモデル、商品ランキングテーブルを取得 PROJECT_ID = os.environ.get( "PROJECT_ID" , "your-project" ) LOCATION = os.environ.get( "LOCATION" , "us-central1" ) MODEL_NAME = os.environ.get( "MODEL_NAME" , "gemini-1.0-pro-001" ) TEXT_EMBEDDING_MODEL = os.environ.get( "TEXT_EMBEDDING_MODEL" , "your-project.sample-dataset.textembedding-gecko-multilingual" ) PRODUCT_RANKING_TABLE = os.environ.get( "PRODUCT_RANKING_TABLE" , "your-project.sample-dataset.product_ranking_emb_table" ) # 生成モデルの設定を定義 generation_config = { "temperature" : 0.1 , "top_p" : 0.95 , "top_k" : 40 , "candidate_count" : 1 , "max_output_tokens" : 8192 , } # 生成モデルをロード model = GenerativeModel(MODEL_NAME, generation_config=generation_config) print (f "Model loaded: {model}" ) @ functions_framework.http def chat_bot (request: flask.Request) -> Mapping[ str , Any]: # リクエストからユーザーメッセージを取得 request_json = request.get_json(silent= True ) user_message = request_json[ "message" ][ "text" ] print (f "user_message: {user_message}" ) if user_message.startswith( "/search" ): # ユーザーメッセージから検索クエリを抽出 query = user_message.replace( "/search" , "" ).strip() # 商品を検索 results = search_products(query) # 検索結果からコンテキストを生成 context = generate_product_context(results) # プロンプトを作成 prompt = f "あなたは商品検索アシスタントです。以下の商品情報を参考に、ユーザーの質問「{query}」に近い商品をオススメしてください。商品の魅力が十分伝わるような文章にしてください。 \n\n {context}" # 生成モデルを使用して応答を生成 response_text = model.generate_content(prompt, stream= False ).text else : # 検索以外のメッセージに対する応答 response_text = ( "商品検索を行うには、'/search 検索クエリ' のように入力してください。" ) print (f "response_text: {response_text}" ) response = { "text" : response_text} return flask.jsonify(response) def search_products (query): # BigQueryクライアントを作成 client = bigquery.Client(project=PROJECT_ID) # 商品検索のクエリを定義 query_job = client.query( f """ WITH embedded_text AS ( SELECT * FROM ML.GENERATE_TEXT_EMBEDDING( MODEL `{TEXT_EMBEDDING_MODEL}`, (SELECT "{query}" AS content), STRUCT(TRUE AS flatten_json_output) ) ) SELECT base.target_text, base.sales_rank, distance FROM VECTOR_SEARCH( TABLE `{PRODUCT_RANKING_TABLE}`, 'target_text_embedding', (SELECT text_embedding FROM embedded_text), top_k => 2, distance_type => 'COSINE', OPTIONS => '{{"use_brute_force":true}}' ) ORDER BY base.sales_rank ASC """ ) print (f "query_job: {query_job}" ) # クエリを実行し、結果をデータフレームに変換 results = query_job.to_dataframe().to_dict( "records" ) print (f "results: {results}" ) return results def generate_product_context (results): product_info = [] # 検索結果から商品情報を抽出 for row in results: print (f "row: {row}" ) product_info.append( f "商品情報: {row['target_text']}, 販売ランキング: {row['sales_rank']}" ) # 商品情報を改行で結合 context = " \n " .join(product_info) print (f "context: {context}" ) return context chat_bot 関数では、以下のような処理を行っています。 Google Chat からのリクエストボディから、ユーザ入力テキストを取得 BigQuery クライアントを初期化 ユーザ入力テキストをエンベディングベクトル化し、商品テーブルのベクトルとの類似度検索を実行 検索結果から、レスポンス文を生成 レスポンスを Google Chat に返す 神谷 乗治 (記事一覧) クラウドソリューション部 クラウドエンジニア。2017 年頃から Google Cloud を用いたデータ基盤構築や ML エンジニアリング、データ分析に従事。クラウドエース株式会社システム開発部マネージャーを経て現職。Google Cloud Partner Top Engineer 2023,2024、Google Cloud Champion Innovators（Database）、 著書：「GCPの教科書III【Cloud AIプロダクト編】」 　

G-gen の杉村です。本記事は Google Cloud Next '24 in Las Vegas の2日目に行われたセッション「 DEI Keynote: Innovation with intention 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 DEI（Diversity, Equity & Inclusion） 多様性は強みである 組織と多様性 DEI（Diversity, Equity & Inclusion） 現地で Google Cloud Next '24 に参加した筆者の印象に残ったセッションとして、 DEI Keynote: Innovation with intention をご紹介させてください。このセッションは、クラウド技術に関するものではありません。 参考 : Diversity, Equity, and Inclusion DEI とは Diversity, Equity & Inclusion （多様性、平等性、包括性）のことであり、人種や文化、性自認、社会的出自、身体障害などに関連して、伝統的に過小評価されてきたグループに、公正で完全な社会参加を促す取り組みのことです。 同セッションは、3人の Googler が登壇し、対談形式で行われました。Chief Diversity Officer である Melonie Parker、Senior Director of Products for All である Eve Andersson、そして Research Scientist である Dimitri Kanevsky です。 Dimitri が話し始めた瞬間、筆者ははじめ、彼が英語ではない、知らない言語を話しているものと思いました。しかし実際には、彼が話しているのは英語だったのです。Dimitri は幼少期に聴力を失っており、正しい発音を知らず、いわゆる「ろう者」です。彼が発話すると、手元のスマートフォンの Live Transcribe（リアルタイムの文字起こし）アプリケーションによりそれが読み取られ、彼の発音に最適化された機械学習モデルによって、正確に文字起こしされます。 セッションでは、彼のもつスマホのアプリの画面が大型スクリーンに転写されており、参加者はそのスクリーンに表示された文字起こしを読むことによって、彼の意図を理解することができました。彼自身が他の登壇者の話を聞くときも、同様に Live Transcribe で聞き取っています。 Dimitri 自身は、自らの Identity を表現するときに、ろう者であるとは言わないといいます。彼のプロフィールを見ると、数学者としての、また約300の米国特許を持つ突出した研究者・技術者としての経歴がわかるのみです。そして彼自身、Live Transcribe の開発に関わっています。 多様性は強みである 文字起こしアプリケーションである「Live Transcribe」の開発や、どんな肌の色の人にも適切なフォトレタッチが可能な Pixel の機能「Real Tone」 は、多様性があったからこそ生み出されたものであることが語られました。 参考 : 音声文字変換のご紹介 参考 : Real Tone たとえ役に立つアプリケーションが開発されても、たとえばそれが、高い性能を持つ高価なスマートフォンでしか使えなかったら、すべての人に行き渡りません。そのアプリが広帯域なネットワークを必要とするならば、インフラの整った一部の地域でしか使うことはできません。チームに様々なバックグラウンドを持つ人が参加することは、このような課題に気がつくことに繋がります。 このように、イノベーションを生み出すにあたって、多様性は 強み である点が強調されました。 組織と多様性 ここからは、 セッションで語られた内容ではなく、筆者の私見 であることにご留意ください。 Google は多様性を組織の「強み」として捉えています。Google が生まれた米国は、その成り立ちから、伝統的に多様性を意識せざるを得なかった経緯があるはずです。その米国が現在、世界中で最も強い国家の1つであることには、重要な示唆があります。 多様性について考えるとき、筆者は以下の動画を思い出します。 www.youtube.com 2017年、米国の空軍士官学校予備校で、メッセージボードに人種差別的な言葉が書かれるという事件がありました。上記の動画は、これに対し、同校の責任者である Jay Silveria 中将が、士官候補生やスタッフの前で語った演説です。同氏も、多様性を「力（Power）」と表現しています。 統一された意志と絶対的な上意下達が必要な組織である軍隊で多様性が「力」とされることと、Google が DEI を重視していること、また同社が採用時に Culture-fit ではなく Culture add を重視すると言われていることは、無関係ではないと感じさせられました。 多様性は倫理（道徳）の問題と捉えられがちですが、 そうではなく、強さやイノベーションに繋がるものである と我々全員が合理的に理解したとき、組織や社会は次のステージへ行けるのかもしれません。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。当記事では、Google Cloud Next '24 in Las Vegas の総括（総評と、注目すべきアップデートのご紹介）をお届けします。セッションレポートなど、Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 Google Cloud Next '24 in Las Vegas 総評 生成 AI 発表ラッシュ 生成 AI だけでない、サービスの進化 注目の発表 はじめに Grounding generative AI with Google Search Vertex AI Agent Builder Multi-region services / Direct VPC Access（Cloud Run） Gemini in BigQuery（データキャンバス） BigQuery の非・生成 AI アップデート Privileged Access Manager（IAM） Cloud Service Mesh Cloud NGFW (Next Generation Firewall) Org policies（AppSheet） Google Cloud Next '24 in Las Vegas 2024年4月9日(火)から11日(木)までの3日間、米国ネバダ州のラスベガスで、Google Cloud Next '24 が行われました。 本投稿では、Google Cloud Next '24 の3日目終了時点で、現地で参加した筆者による総評と、注目すべきアップデートの紹介を行います。 当社によるセッションレポートや、1日目・2日目のキーノートに関する記事は、以下の一覧からご参照ください。 blog.g-gen.co.jp Keynote (Day 1) 総評 生成 AI 発表ラッシュ Google Cloud Next '24 は、昨年にサンフランシスコで行われた Google Cloud Next '23 と同じく、 生成 AI をフィーチャー したものになりました。 キーノート（基調講演）は多分にマーケットを意識した発表となっており、生成 AI が Google Cloud を補助して使いやすくしたり、業務スピードを向上させる機能に関する発表が目立ちました。 今回の Next では、Gemini の名称を Google Cloud ユーザーに印象付けるがごとく、「Gemini in 〇〇」「〇〇 with Gemini」の文言が繰り返し登場しました。Google Cloud は当初、 生成 AI 基盤モデルを Gemini として呼称 していましたが、その後、生成 AI による業務補助ツール群「Duet AI」や、コンシューマ向け生成 AI チャットツール「Bard」の名称を廃止し、生成 AI 関連プロダクトの 呼称を「Gemini」に統一 しました。これは、Microsoft が生成 AI による業務補助製品群を Copilot としてブランド名の統一を図ったことと似ています。 キーノートの内容は、以下の当社記事をご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 例として、Gemini in BigQuery や Gemini in Looker が挙げられます。BigQuery のユーザーや Looker のユーザーは、自然言語による指示で、SQL を自動生成してデータベースに問い合わせたり、データを可視化することができます。これまで SQL を理解するエンジニアや一部のマーケターのみのものだった BigQuery が、よりビジネスユーザーにとって身近になるといえます。 Gemini for Google Workspace では、Google Vids の発表が印象的です。動画の編集を生成 AI が補助するツールであり、自然言語による指示にもとづいて、ストーリーボードやスクリプト（台本）を生成します（あくまでユーザーが所持する既存の動画像を組み合わせるものであり、動画自体の生成はまだできるようにはならないとのことです）。また AI Meetings and Messaging add-on は、ビデオ会議において様々な言語にリアルタイム翻訳を行うものであり、直接的に業務を効率化させうるものです。 Expo エリアにおける Google Vids のデモ また Vertex AI Agent Builder や Vertex AI Prompt Management など、生成 AI 開発に関する機能拡張も発表されました。 ただし、技術者からの目線では、キーノートはコンセプチュアルな発表に留まった印象でした。講演内でモニターに映し出されたデモ画面は、架空の EC サイトや、発表された新機能を用いて開発された架空の生成 AI アプリを模した画面であり、実際の詳細な実装方法やインターフェイスの解説は、個別のブレイクアウトセッションに任されました。しかしながら、事前のセッション登録では、「どのセッションで新発表がされるか」「キーノートで発表された新機能はどのセッションでより詳しく聞けるのか」について推し量ることはできなかったため、現地での参加者は情報を効率的に得ることが難しく、これは今後の情報収集方法に関する当社の課題となります。 また、今回の発表で、かつて「Gemini for Developers」を呼ばれていたものは「Gemini Code Assist」となり、「Gemini in Google Cloud（それ以前は Duet AI for Google Cloud）」と呼ばれていたものは「Gemini Cloud Assist」を含む複数の「Gemini in 〇〇」を包括するサービスとなる、などサービス命名にゆらぎが見られたことから、名称や機能の役割分担については整理が必要です。 公式ブログ「Powering Google Cloud with Gemini」より引用 参考 : Powering Google Cloud with Gemini 生成 AI だけでない、サービスの進化 ここまでの総評や、SNS で注目されがちな情報の傾向から、今回の Next の発表は生成 AI 一色だったかのように思われるかもしれません。しかしながら、 実際には生成 AI 以外の注目すべき発表が、数多く されています。 BigQuery に関する個別セッションでは、GUI でデータ準備を行う新機能や、ビジュアライズされた簡易ワークフローツール、また BI ツールからのクエリの最適化機能が発表されました。また、BigQuery のオペレーションに関する機能の拡張も発表されており、BigQuery を使ったデータ分析基盤を運用する当社としても、オペレーションの効率化を予感しています。 Cloud Run は、マルチリージョンへのデプロイ、ベースイメージのアップデートの自動化、VPC リソースへの直接アクセスを可能にする Direct VPC Egress の GA など、注目すべきアップデートが発表されています。 Cloud Run の Multi-region services Cloud IAM においても、承認者の承認を経て時限付きの IAM ロール付与を可能にする Privileged Access Manager（PAM）が発表され、組織規模のクラウド運用をよりセキュアにすることができます。 これらの一つ一つが、基調講演でフィーチャーされていても不思議ではないアップデートです。当社では、Google Cloud 専業として、これらのアップデートが "埋もれない" ように情報の整理と発表をする必要性を感じています。 注目の発表 はじめに 当記事ではここから、当社の現地参加者が注目した技術的な発表事項を一部、ご紹介します。詳細は併記されているセッションレポート等をご参照ください。 なお、Google Cloud Next ‘24 で発表された全事項は、以下の公式記事にまとまっています。 参考 : All 218 things we announced at Google Cloud Next ‘24 – a recap ただし、中には今回のイベントが初出でない事項等もあります。上記の記事では「初出情報か・既出情報か」「初出であれば、その機能アップデートはすぐに使えるか、それとも将来の公開予告か」の区別は難しくなっています。当記事では、可能な限りその区別ができるように記載します。 Grounding generative AI with Google Search Vertex AI の Gemini API 経由でのコンテンツ生成時に、Google Search（Google 検索）でのグラウンディングを行うことができるようになります。Private Preview として、申し込みが可能になっています。 これまで、Vertex AI が対応していたグラウンディング先のデータストアは、ユーザが用意する PDF やテキストデータ（Cloud Storage）、Web サイト、BigQuery などでした。今後は、Google 検索をグラウンディングに使うことができるようになり、より汎用的な RAG 構成を実現できます。 参考 : Grounding generative AI in enterprise truth Vertex AI Agent Builder Vertex AI Agent Builder が Preview 公開されました。Vertex AI Agent Builder は、フルマネージドの生成 AI Agent です。ここでの「Agent」とは、生成 AI が人間の代わりに複雑なタスクを実行するための仕組みを指しており、これまで LangChain 等のフレームワークで実装されていました。 blog.g-gen.co.jp blog.g-gen.co.jp Multi-region services / Direct VPC Access（Cloud Run） Cloud Run において、同一サービスを複数のリージョンにデプロイする Multi-region services の Private Preview が発表されました。 また、これまで Preview 状態だった Direct VPC Egress が一般公開（GA）となりました。「一度スケールアウトするとスケールインできない」という課題があった VPC アクセスコネクタが不要になるアップデートであり、Cloud Run のネットワーク構成のベストプラクティスが変わります。 blog.g-gen.co.jp Gemini in BigQuery（データキャンバス） 自然言語による指示をすることで、BigQuery にクエリを投入したり、データの可視化を行うことができるようになります。同機能は Gemini in BigQuery による「 データキャンバス 」として Private Preview 公開されました。 フォーム から申し込み可能になっています。 blog.g-gen.co.jp BigQuery の非・生成 AI アップデート BigQuery の非・生成 AI 関連アップデートとしては、以下が注目されます。ただしいずれも、2024年4月15日現在では、使用可能になっていません。 機能名 状態 概要 BigQuery data preparation Preview GUI でのデータ変換 BigQuery workflows Preview 簡易ワークフロー BigQuery continuous queries Preview ストリーミングデータに対するクエリ実行 Cross-region disaster recovery Preview リージョンをまたいだ DR（災害対策） Query acceleration improvements GA/Preview クエリの最適化機能群 blog.g-gen.co.jp Privileged Access Manager（IAM） 承認者の承認を経て、時限付きの IAM ロール付与を可能にする Privileged Access Manager （PAM）が Preview 公開予定です。2024年4月15日現在では、使用可能になっていません。 リクエスト者が、権限の付与を承認者に申請し、承認された場合、指定された期間のみ、IAM ロールが付与されます。これにより、本番環境における特権管理で一般的な、時限付きの特権管理が可能になります。 blog.g-gen.co.jp Cloud Service Mesh マイクロサービスにおけるサービスメッシュを実現するフルマネージドサービスである Cloud Service Mesh が発表されました。公開は "this quarter" とされており、2024年の2Q（4月〜6月）が予定されています。 従来から存在する Anthos Service Mesh が発展したものとなる見込みです。 参考 : Announcing Cloud Service Mesh - the evolution of service mesh for Google Cloud Cloud NGFW (Next Generation Firewall) Cloud NGFW (Next Generation Firewall) は、従来から存在した Cloud Firewall が改名したものです。Cloud Firewall は数年をかけて機能強化とソリューションとしての再整理を続けていましたが、今回の Next を機に Cloud NGFW と改称し、料金ティアを明確にして再出発した形です。 blog.g-gen.co.jp Org policies（AppSheet） AppSheet で、組織、チーム、個人の単位でポリシーが設定可能な Org policies（組織ポリシー）が GA されます。アプリ内でのデータ削除の制限、オフライン利用の有効化等が、一律のポリシーとして設定できます。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの山崎です。 Google Cloud (旧称 GCP) の Cloud Storage のバージョニング・ライフサイクル管理設定について、代表的なユースケースを用いて解説します。 Cloud Storage とは バージョニング ライフサイクル管理 バージョニング・ライフサイクル管理設定 ケース①：オブジェクトを2世代保持したい ケース②：オブジェクトが作成されてから、10日後に削除したい ケース③：オブジェクトが非現行バージョンになってから、5日後に削除したい ケース④：オブジェクトが作成されてから5日後に現行バージョンを非現行バージョンとし、その2日後に非現行バージョンを削除したい Cloud Storage とは Cloud Storage は、データ容量が無制限、かつ耐久性の高いストレージサービスで、略称として GCS とも呼称されます ( G oogle C loud S torage の略) 。 Cloud Storage は、上記の特性から以下のような様々な用途で利用することができます。 システム間のデータ授受 データ分析における、未加工データ（データレイク） 各種データのバックアップ Cloud Storage 上、各種ファイルは、 バケット と呼ばれるデータを入れる箱の中に、 オブジェクト として、保存されます。 Cloud Storage の全体像について確認する場合は、以下の記事を参照いただければと思います。 blog.g-gen.co.jp バージョニング バージョニング とは、オブジェクトを上書きした際に、上書き前のオブジェクトを過去のバージョン（以降、非現行バージョン）として保持する機能のことを指します。 また、オブジェクトを削除した際も同様に、削除したオブジェクトを非現行バージョンとして保持することができます。 バージョニングの設定は、 バケット単位 で行うことができます。 参考： オブジェクトのバージョニング ライフサイクル管理 ライフサイクル管理 とは、オブジェクトに対して、条件（オブジェクトが作成されてから30日経過 等）を設定し、その条件に該当するオブジェクトに対して、削除やストレージクラスの変更を自動的に実施する機能のことを指します。 ライフサイクル管理の設定は、バージョニング同様、 バケット単位 で行うことができます。 参考： オブジェクトのライフサイクル管理 バージョニング・ライフサイクル管理設定 バージョニング・ライフサイクル管理の設定はどちらも、GoogleCloudコンソール、コマンドラインで実施することができます。 以降、具体的なユースケースに対し、どのように設定を行えばよいか、解説していきます。 今回使用するライフサイクルの条件、入力内容、発動条件は以下となります。 No. 条件 入力内容 発動条件 1 経過日数 （age） 日数 オブジェクトが作成されてから、入力した日数以上経過したか 2 新しいバージョンの数 （numNewerVersions） 世代数 自身のオブジェクトより、新しいオブジェクトが入力した世代数分存在するか 3 非現行になってからの日数 （daysSinceNoncurrentTime） 日数 オブジェクトが非現行バージョンになってから、入力した日数以上経過したか 4 ライブ状態 （isLive） ライブor現行以外 オブジェクトが現行バージョンか非現行バージョンか ケース①：オブジェクトを2世代保持したい 条件を設定したいバケットに対して、以下の内容を登録します。 バージョニング：オン ライフサイクル：以下のライフサイクルルールを作成 ルール アクション オブジェクト条件 1 オブジェクトを削除する 新しいバージョンの数：2 注意点 単純にオブジェクトを上書きするだけの運用であれば、現行バージョンと、最新の非現行バージョンの2世代のオブジェクトが保持されます。 しかし、現行バージョンのオブジェクトを削除した場合は、現行バージョンが存在しない状態となるため、 最新の非現行バージョンと、最新の一つ前の非現行バージョンの2世代 のオブジェクトが保持されます。 参考： numNewerVersions ケース①イメージ ケース②：オブジェクトが作成されてから、10日後に削除したい 条件を設定したいバケットに対して、以下の内容を登録します。 バージョニング：オフ ライフサイクル：以下のライフサイクルルールを作成 ルール アクション オブジェクト条件 1 オブジェクトを削除する 経過日数：10 注意点 経過日数は、あくまでもそのオブジェクトが 登録された時間を起点 として、判定されます。 そのため、もしバージョニングをオンにした状況で、現行バージョンのオブジェクトが上記条件に該当した場合、そのオブジェクトは 非現行バージョンとはならず、完全に削除 されます。 もし、現行バージョンをいきなり完全に削除するのではなく、 非現行バージョンとして、保持したい場合は、オブジェクト条件に 「ライブ状態：ライブ」を追加する必要があります。（ケース④参照） 参考： age ケース②イメージ ケース③：オブジェクトが非現行バージョンになってから、5日後に削除したい 条件を設定したいバケットに対して、以下の内容を登録します。 バージョニング：オン ライフサイクル：以下のライフサイクルルールを作成 ルール アクション オブジェクト条件 1 オブジェクトを削除する 非現行になってからの日数：5 ケース③イメージ ケース④：オブジェクトが作成されてから5日後に現行バージョンを非現行バージョンとし、その2日後に非現行バージョンを削除したい 条件を設定したいバケットに対して、以下の内容を登録します。 バージョニング：オン ライフサイクル：以下の2つのライフサイクルルールを作成 ルール アクション オブジェクト条件1 オブジェクト条件2 備考 1 オブジェクトを削除する 経過日数：5 ライブ状態：ライブ 現行バージョンの削除 2 オブジェクトを削除する 非現行になってからの日数：2 ライブ状態：現行以外 非現行バージョンの削除 注意点 現行バージョンのオブジェクトに対して、上書き、もしくは削除を実施した場合は、そのオペレーションを実施したタイミングで非現行バージョンとなります。 そのため、そのオペレーションを実施した2日後に、上記ルールの2が適用され、非現行バージョンとなったオブジェクトは、完全に削除されます。 ケース④イメージ 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 フルスタックな人材を目指し、日々邁進。

G-gen の堂原です。本記事は Google Cloud Next '24 in Las Vegas の 3 日目に行われた Breakout Session「 Vertex AI Gemini: Model selection and prompt design principles and strategies 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 生成 AI モデルの選び方について プロンプト設計における Tips 概要 Instructions Examples 区切りを明確にする 各要素の順番 実験と評価 プロンプト設計の原則 関連記事 セッションの概要 本セッションでは、Vertex AI で生成 AI を使っていくにあたってのモデルの選び方、プロンプト設計における Tips 及びその原則についての講演が行われました。 新サービスの発表等は無かったですが、Google の方からプロンプト設計についてのノウハウが聞ける貴重なセッションでした。 生成 AI モデルの選び方について 今回の Next を経て、Gemini 1.5 Pro や Gemma が Vertex AI に追加され、生成 AI モデルは更に選択肢が広くなりました。 では、プロダクトにおいてはどの生成 AI モデルを使うのが良いのでしょうか。 研究の世界においては生成 AI はベンチマークが優先され、最も良いスコアを出した 1 つのモデルが注目を集めることとなります。 しかし、プロダクトの世界においては必ずしも 1 つのモデルにこだわる必要はなく、またベンチーマークというよりかは顧客満足度や ROI が優先されます。 そのため、ユースケースに応じて 1 つまたは複数のモデルを使い分けていくことが大事となります。 セッション内ではユースケースに応じてどのモデルを使うべきかを示した決定木が紹介されていました。 必ずしも常に Gemini 1.5 Pro が優先されるわけではなく、時には Gemini 1.0 Pro、時には Imagen 2 や text-bison、text-unicorn が候補となりうるということがわかります。 プロンプト設計における Tips 概要 次にプロンプト設計を行うにあたっての Tips が紹介されました。 基本的なプロンプト設計においては、以下のコンポーネントを組み合わせていくこととなります。 そのうえで、本セッションで紹介された Tips のうち、そのいくつかを紹介します。 また、セッション内で紹介されていた以下の公式ドキュメントもご参照ください。 Prompting basics Generative AI prompt samples Instructions モデルが実際に行うタスクを記載する Instructions ですが、その内容はシンプルかつ明示的であることが望ましいです。 悪い例 : Summarize the meeting notes. 良い例 : Summarize the meeting notes in a single paragraph. Then write a markdown list of the speakers and each of their key points. Finally, list the next steps or action items suggested by the speakers, if any. 加えて、特定の振る舞いを禁止するような書き方よりは、何をしてほしいかを基本としたほうが効果的です。 また、モデルの立場（Persona）などを記載する前提条件部分についても、簡素であることが望まれます。 Examples Few-shot learning に代表されるように、モデルに入出力例を与えることはとても効果的な手法です。 ただし、Examples の数が多いことはむしろ性能の悪化に繋がる場合があります。 区切りを明確にする どこが Instructions なのか、どこが Examples なのかを明確に区切るようにしましょう。 特に <EXAMPLES> ... </EXAMPLES> といった XML タグを用いることが推奨されていました。 各要素の順番 Gemini 1.5 Pro においては、モデルに与える背景情報にあたる Documents のあとに Instructions を配置したほうが精度が良くなります。 実験と評価 プロンプト設計の Tips ではないですが、良いプロンプトを作成するためには様々なプロンプトを実験し、評価することが大事になります。 Vertex AI では、生成 AI モデルの 3 つの評価方法が提供されています。 Automated Metrics : タスク固有の何かしらのメトリクスを評価に利用 Automatic side-by-side（AutoSxS）: 2 つのモデルの比較に利用 Rapid Evaluation : クイックにモデルの評価が可能 その中でも、今回新たに登場した Rapid Evaluation を用いた場合のイメージが紹介されました。 プロンプト設計の原則 セッションの最後では、生成 AI で実際にシステムを構築していく際の原則について紹介されました。 ポイントはそのシステムにおけるユーザージャーニーを意識し、個々のプロセス毎に生成 AI モデルを呼び出すことです。 1 つのモデルとプロンプトで複雑な処理を行うとなると、とても複雑なプロンプトを設計する必要が出てきます。 しかし、プロセス毎に分解することで個々のモデルの入出力がシンプルとなり、プロンプト設計もより簡易なものとなります。 上記の例だと Gemini 1.5 Pro Text-Unicorn Vertex AI Vector Search と Gemini Pro 1.0 を組み合わせた RAG Gemma 7B という順番で、用途用途に合わせて適任なモデルが呼び出されています。 関連記事 blog.g-gen.co.jp 堂原 竜希 (記事一覧) クラウドソリューション部データアナリティクス課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の小林です。本記事は Google Cloud Next '24 in Las Vegas の2日目に行われた Breakout Session「 AppSheet: No-Code revolution powered by AI 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 AppSheet の最大の特徴 AppSheetのアップデート（3-point plan） ガバナンス戦略の定義（Define your governance strategy） 組織でのガバナンス戦略の紹介 組織ポリシー（Org policies） ユーザーの利用の促進（Drive user adoption） AppSheetの利用定着 統合コネクタの拡充 AppSheet コンソール内でのアプリ作成支援 Gemini機能による画像情報の取得 データソースとして Google Form に対応 監視、管理、成熟（Monitor, Manage & Mature） 管理コンソールの機能拡充 関連記事 セッションの概要 本セッションでは、Google Cloud が提供するノーコードアプリ開発ツールである AppSheet のアップデートおよび活用例が紹介されました。 AppSheet の最大の特徴 ノーコードアプリ開発ツールは、非開発者のビジネスユーザーが業務プロセスやワークフローの最適化をする 市民開発（Citizen development） を推進するために必要であり、AppSheet は市民開発をリードするツールであることが強調されました。 AppSheetのアップデート（3-point plan） 以下の3カテゴリーに分けた機能紹介とアップデートの発表がありました。 ガバナンス戦略の定義（Define your governance strategy） ユーザーの利用の促進（Drive user adoption） 監視、管理、成熟（Monitor, Manage, &Mature） ガバナンス戦略の定義（Define your governance strategy） 組織でのガバナンス戦略の紹介 組織でAppSheetを導入する場合、以下の3パターンいずれかの体制で導入されます。 特定の専門のアプリ開発チームで組織向けのアプリを開発 部署単位での独自のルールの下アプリを開発 組織内すべてのユーザーがアプリを開発 その上でチームの定義、適切なポリシー設定、監視を定義することが重要であると強調されました。 組織ポリシー（Org policies） 組織、チーム、個人の単位でポリシーが設定可能な Org policies （組織ポリシー）の発表がありました（一般公開）。 アプリ内でのデータ削除の制限、オフライン利用の有効化等、アプリに対する制限を組織、チーム、個人の単位で設定することが可能になりました。 ユーザーの利用の促進（Drive user adoption） AppSheetの利用定着 LIXIL 社の AppSheet 活用の紹介があり、導入の成功は全社へのトレーニングが重要であると強調されました。 統合コネクタの拡充 100以上の SaaS アプリケーションとの統合コネクタの提供や、Vertex AI を利用した Automation 機能の提供が発表されました。2024年後半に Preview 公開予定です。 AppSheet コンソール内でのアプリ作成支援 AppSheet コンソールで Gemini が利用できるようになりました。 作成したいアプリの情報を入力すると、アプリが自動的に作成される機能の発表がありました。この機能は、2024年4月に一般公開されます。 Gemini機能による画像情報の取得 AI Automation の Action 機能を利用して、画像内部の情報（数値、定量評価等）を回答する機能が発表されました。この機能は、2024年前半に Preview 公開予定です。 データソースとして Google Form に対応 AppSheet のデータソースとして、Google Form が対応することが発表されました。2024年4月に Preview 公開されます。 これまでは、データソースとして Google Form を利用する場合、回答結果をスプレッドシートに格納する必要がありました。今回のアップデートは、Form の回答内容をAppSheet へ反映するユースケースを求めているユーザーにとって、嬉しいアップデートとなります。 監視、管理、成熟（Monitor, Manage & Mature） 管理コンソールの機能拡充 管理コンソールの機能強化が発表されました。2024年前半に Preview 公開予定です。 アプリの利用状況、ユーザーごとの利用状況、ライセンスの割当状況等、デモ画面の紹介がありました。今までより管理画面が見やすくなる印象を受けました。 関連記事 blog.g-gen.co.jp 小林 あゆみ (記事一覧) クラウドソリューション部 営業チーム AWSエンジニアからGoogle Cloud営業に転向 福井からリモートワーク中 趣味はMonkey125でツーリング、Netflix鑑賞、旅行

G-gen の西島です。本記事は Google Cloud Next '24 in Las Vegas の2日目に行われた Breakout Session「 What's new with BigQuery 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 BigQuery data preparation（Preview） BigQuery workflows（Preview） BigQuery continuous queries（Preview） Cross-region disaster recovery（Preview） Query acceleration improvements（一部 GA、一部 Preview） 関連記事 セッションの概要 本セッションでは BigQuery に関連する新機能が多数発表されました。 キーワードとして「AI」と「unified（統合された）」という単語が頻出しており、BigQuery が AI に対応した単一のデータプラットフォームとして進化していることが強調されました。 BigQuery data preparation（Preview） BigQuery data preparation は、生成 AI の補助のもと、BigQuery のデータのクレンジングができる仕組みです。 ビジネス的な背景情報を考慮したうえで、生成 AI がデータ変換のレコメンデーションを提示してくれます。データ変換の SQL パイプラインのデプロイとオーケストレーション、監視も機能として組み込まれるとされています。 参考 : BigQueryを徹底解説！(基本編) - BigQuery data preparations BigQuery workflows（Preview） BigQuery workflows は BigQuery Studio（BigQuery の Web コンソール画面）組み込みのワークフロー機能です。コーディングなしに、GUI 上で、SQL スクリプトや Python notebook、データキャンバス、前述の data preparation を実行するワークフローを構築し、スケジューリングできます。さらに、ワークフローは Dataform や Composer 用にエクスポートできます。 従来から存在する Scheduled query は手軽である一方、単発の単純な SQL 実行に特化しており、複雑なワークフローを実行するには Dataform や Composer などのワークフローツールを用いる必要がありました。BigQuery workflows は、Scheduled query とこれらのワークフローツールの中間に位置するツールになると考えられます 参考 : BigQueryを徹底解説！(基本編) - BigQuery workflows BigQuery continuous queries（Preview） Continuous queries は BigQuery で継続的にクエリを実行できる機能です。ストリームデータ（連続的なデータ）に対して繰り返し、継続的に SQL を実行します。用途として「リアルタイム異常検知、感情分析、レコメンデーションなどの AI/ML 用のパイプライン」「BigQuery テーブルから他のテーブル、Pub/Sub、Bigtable などへのデータ移送「CRM 等、業務アプリケーションへのリバース ETL」などが考えられます。 リアルタイムなデータ移送は、これまで Dataflow 等を用いる必要がありました。今後は、高度な柔軟性と高いパフォーマンスが求められる場合は Dataflow を選び、学習コストの低い SQL を使ったパイプラインや BigQuery ML を用いたい場合は Continuous queries を選ぶなど、選択肢が増えることとなります。 Cross-region disaster recovery（Preview） Cross-region disaster recovery では、BigQuery でリージョンレベルの物理障害が発生した際に、セカンダリリージョンへのフェイルオーバが行われます。Enterprise Plus Edition で提供されます。コンピュート処理のフェイルオーバにより5分以下の RTO が実現されます。また、データの継続的なレプリケーションにより15分以下の RPO が実現されます。 なお、リージョン間のデータセットのレプリケーションは、2023年に 発表 されていました。今回の発表では、これにコンピュート処理のフェイルオーバが加わったことになります。クエリの向き先の変更は自動的に行われるため、SQL の書き換えは不要です。 Query acceleration improvements（一部 GA、一部 Preview） クエリのパフォーマンスや Looker Studio と BigQuery の統合に関する複数のアップデートが発表されました。 過去履歴からの実行計画の自動最適化。最大5倍の実行速度向上（Preview） 1GB 未満のスキャンを伴う小規模クエリの高速化と、複数ユーザー実行時のスループット改善（Preview） Automatic smart caching。BI engine で適応的なベクトル化が行われ、BI ツールからのクエリ実行を最適化（GA） BI ツールからの透過的なクエリ最適化。BigQuery Studio、Looker、Looker Studio、Tableau、Power BI 等に対応（GA） Looker Studio からの利用の最適化（ジョブ詳細、モニタリング、コスト追跡、クエリのキャッシュ、INFORMATION SCHEMA、マテリアライズドビュー） Looker Studio との統合に関しては、Looker Studio で実行されたクエリに関する BigQuery の INFORMATION_SHEMA （システムビュー） や Cloud Logging から取得できる機能が強化されたり、マテリアライズドビューを使ったパフォーマンス向上などが発表されました。 関連記事 blog.g-gen.co.jp 西島 昌太 (記事一覧) カスタマーサクセス課 データエンジニア 2023年4月に新卒入社。 元はフロントエンド開発を主戦場に、現在はデータエンジニアリングを勉強中。何でも屋さんを目指して、日々邁進。 休日は大体プログラムを書いてる人

G-gen の杉村です。当記事では、Google Cloud Next '24 in Las Vegas のキーノート（2日目）に関する速報レポートをお届けします。セッションレポートなど、Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 Google Cloud Next '24 in Las Vegas 概要 Build Gemini Code Assist App Hub BigQuery continuous queries Natural language support in AlloyDB Run Cloud Run application canvas GKE と Gen AI Operate Vertex AI Prompt Management Shadow API detection Confidential Accelerators for AI workloads GKE container and model preloading 関連記事 Google Cloud Next '24 in Las Vegas 2024年4月9日(火)から11日(木)までの3日間、米国ネバダ州のラスベガスで、Google Cloud Next '24 が行われました。 本投稿では、Google Cloud Next '24 の2日目のキーノート（基調講演）で行われた、特に注目すべき技術的な発表にフォーカスして共有します。 1日目のキーノートについては、以下の記事を参照してください。 blog.g-gen.co.jp 概要 Google Cloud Next '24 の2日めキーノート（基調講演）では、「Fast. Simple. Cutting edge. Pick three.」と銘打ち、アプリケーション開発者向けの発表がされました。Day 2 のキーノートでアプリケーション開発者向けの発表がされる点は、昨年サンフランシスコで行われた Google Cloud Next '23 と同様です。 開発者が日常的に行っている「build, run and operate」を AI 技術で補助することをテーマに、様々な発表が行われました。 ここからは、基調講演の中で発表された技術的な新発表をご紹介します。 キーノート（2日目） 参考 : Day 2 at Next ’24 recap: building AI agents Build Gemini Code Assist 開発者にとって、最も身近に利用する生成 AI 関連サービスは Gemini Code Assist です。Gemini 1.5 は業界最大級の100万トークンのコンテキストウインドウを処理できます。つまり、より多くの背景情報（アプリケーションや環境に関する情報、コーディング規約など）を保持して、コーディングの補助ができることになります。 また Gemini は BigQuery や Looker、他のデータベースサービスなどと統合されているため、より高度な開発体験を得ることができます。 参考 : What is a long context window? App Hub App Hub は、アプリケーションの、プロジェクトをまたいだ Google Cloud リソースの使用状況や依存関係を可視化するための仕組みです。 Gemini Cloud Assist と統合されており、AI の補助のもと、環境の可視化やトラブルシューティングに活かすことができます。 参考 : App Hub - Manage your application, forget the toil BigQuery continuous queries BigQuery continuous queries が Preview 公開されました。ストリームデータに対して、継続的な SQL を発行し、リアルタイムなデータ処理が容易に実装できます。講演では、BigQuery コンソール画面で記述した SQL に対して、continuous query のオプションを有効化するだけで、SQL がデータを継続処理するように設定できる様子がデモされました。 参考 : What’s next for data analytics at Google Cloud Next ’24 Natural language support in AlloyDB Natural language support in AlloyDB は、AlloyDB におけるベクトル検索の新しいインデキシングの仕組みである ScaNN vector indexing により、さらに高いパフォーマンスでリアルタイムなベクトル検索を実現することで、オペレーショナルデータベースで自然言語による検索がさらに実用的になることを指しています。 AlloyDB では、従来より PostgreSQL の拡張機能である pgvector を利用したエンべディングとベクトル検索が可能でしたが、今回新たに発表された ScaNN vector indexing により、パフォーマンスが向上しています。 Parameterized secure views は、User ID など特定のキーをベースに行アクセスを制御する View です。これにより、プロンプトインジェクション攻撃のリスクを下げることができます。 参考 : Natural language support in AlloyDB for building gen AI apps with real-time data 参考 : Introducing ScaNN vector indexing in AlloyDB, bringing 12 years of Google research to speed up vector search Run Cloud Run application canvas Cloud Run application canvas は、Gemini Cloud Assist の補助により、Cloud Run アプリケーションの設計やデプロイを容易に実現する仕組みです。自然言語で実現したいアプリケーションを指示すると、グラフィカルにアーキテクチャが提示され、デプロイまで簡単に行うことができます。 参考 : The container platform for the next decade of AI and beyond GKE と Gen AI Gen AI Quick Start Solutions for GKE （Python フレームワークである Ray との統合）、 Support for Gemma on GKE など、Google Kubernetes Engine（GKE）と生成 AI の統合も紹介されました。 参考 : Why GKE for your Ray AI workloads? Portability, scalability, manageability, cost 参考 : Gemma on Google Kubernetes Engine deep dive: New innovations to serve open generative AI models Operate Vertex AI Prompt Management Preview 公開となっている Vertex AI Prompt Management のデモ画面が公開されました。生成 AI 基盤モデルに投入する複数のプロンプトを保存、比較するためのインターフェエイスです。 参考 : Google Cloud announces updates to Gemini, Imagen, Gemma and MLOps on Vertex AI Shadow API detection Apigee API Management の機能として提供される Advanced API Security の新機能として、 Shadow API detection が発表されました。セキュリティインシデントの起因となるシャドウ API（中央管理者によって管理されていない API）を検知する機能です。 参考 : Introducing Shadow API detection for your Google Cloud environments Confidential Accelerators for AI workloads Confidential Accelerators for AI workloads は、情報保護の観点でセンシティブな AI ワークロードを稼働させるため、 A3 マシンシリーズで Confidential VMs を利用可能 になりました。 Compute Engine の A3 マシンシリーズは NVIDIA H100 GPU を搭載した、AI/ML や HPC（High Performance Computing）ワークロードに特化したマシンシリーズです。 Confidential VMs（Confidential Computing）は、Trusted Execution Environment（TEE）という特別なハードウェアにより、メモリ上のデータも暗号化される VM です。Google Cloud では保存されたデータ（at-rest、すなわちストレージ上のデータ）はデフォルトで暗号化されていますが、Confidential VMs ではメモリ上のデータも暗号化されており、OS やミドルウェアなどソフトウェアの脆弱性を突いた高度な攻撃等に対する、より高い耐性を持ちます。 参考 : Expanded Confidential Computing portfolio and introducing Confidential Accelerators for AI workloads 参考 : The A3 machine series 参考 : Confidential VM overview GKE container and model preloading GKE container and model preloading （GKE コンテナとモデルの先行読み込み）が Preview 公開されました。GKE の新しいノードが起動する際、あらかじめコンテナイメージや AI モデルをディスクにロードしておくことで、オートスケーリングを高速化し、機械学習推論のエンドポイントを提供するようなサービスにおいて、遅延を抑えることができます。 参考 : Use secondary boot disks to preload data or container images 関連記事 3日目終了時点での総評を、以下の記事で紹介ています。 blog.g-gen.co.jp Next では、Cloud Run の新機能など、生成 AI 以外に関する複数のアップデートも発表されています。それらの発表は、当社のセッションレポート記事もご参照ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen 又吉です。本記事は Google Cloud Next '24 in Las Vegas の2日目に行われた Breakout Session「 Build and deploy generative AI agents using natural language with Vertex AI Agent Builder 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Vertex AI Agent Builder Agent 開発のプロダクト選定 ユースケース Vertex AI agent のロードマップ デモ 関連記事 セッションの概要 本セッションでは、Google Cloud Next '24 の Day1 キーノートで発表された、Vertex AI Agent Builder のユースケースやロードマップの紹介が行われました。 Vertex AI Agent Builder Vertex AI Agent Builder とは、人間の代わりにプログラムが生成 AI の力を借りてタスクを実行する Agent（エージェント）を実装するフルマネージドなプロダクトです。 Vertex AI Agent Builder の Vertex AI agent の Web コンソール上で、Agent の開発からテスト、デプロイはもちろんのこと、会話履歴の管理や Agent のバージョン管理まで、Agent 開発をノーコード・ローコードで進められる環境が整っています。 Agent の概念や Vertex AI Agent Builder については、以下のブログでも紹介してます。 blog.g-gen.co.jp Agent 開発のプロダクト選定 Vertex AI agent の Web コンソールを使えばビジネスユーザーでもノーコード・ローコードで Agent アプリが作成できます。一方で、LangChain などのフレームワークを使ってより柔軟にカスタマイズした Agent アプリの開発を行いたい場合は、Vertex AI を使うことが推奨されます。開発者のスキルや、アプリケーションに持たせる柔軟性の度合いが、プロダクト選定のポイントとして紹介されました。 Vertex AI 上で LangChain を用いた生成 AI アプリケーションの開発やデプロイをサポートする LangChain on Vertex AI も、Google Cloud Next '24 のタイミングでプレビュー公開されています。 ユースケース Agent のユースケースが4つ紹介されました。 Customer agents : 自社商品の FAQ や e コマースの決済処理などの toC/toB 向けのサービスに統合 Enployee agents : HR や営業管理などの社内業務のサポートに利用 Knowradge agents : 特定ジャンル (法務、R&D、金融等) の知識を持った Agent の構築 Voice agents : コールセンター等の電話対応で活用し、無人化、もしくは人間の工数を削減するなど Vertex AI agent のロードマップ Vertex AI agent のロードマップの紹介では、「音声機能の追加 (Voice features)」や 「写真やファイルのアップロードに対応 (Multi-model) 」などのアナウンスもありました。 デモ セッション内では、Agent で構成されたアプリのデモがいくつか紹介されました。 以下は、Data Science Agent に対し、ユーザーが自社のデータを下に分析を依頼している様子です。 ユーザーの質問に対し、Agent は Python のコードを生成して実行し結果を出力、さらに結果を踏まえた考察まで出力していました。 関連記事 blog.g-gen.co.jp 又吉 佑樹 (記事一覧) クラウドソリューション部 はいさい、沖縄出身のクラウドエンジニア！ セールスからエンジニアへ転身。Google Cloud 全 11 資格保有。Google Cloud Champion Innovator (AI/ML)。Google Cloud Partner Top Engineer 2024。Google Cloud 公式ユーザー会 Jagu'e'r でエバンジェリストとして活動中。好きな分野は AI/ML。 Follow @matayuuuu

G-gen の藤岡です。本記事は Google Cloud Next '24 in Las Vegas の2日目に行われた Spotlight セッション「 What​​’s next for security professionals 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Security Command Center Enterprise 概要 デモ 関連記事 セッションの概要 本セッションでは、 Security Command Center Enterprise をはじめとする、セキュリティサービスの紹介やデモが行われました。 Security Command Center Enterprise 概要 セッション内では、Google Cloud 環境の構成ミス、脆弱性、脅威を特定するためのサービスである Security Command Center で2024年4月2日に一般提供（GA）が開始された Security Command Center Enterprise （SCCE）が紹介されました。 これにより、従来のスタンダードティアとプレミアムティアに加え、新たに Enterprise ティアが利用可能になります。 特筆すべき点としては、マルチクラウド環境に対応したことです。 これまで Security Command Center は Google Cloud のリソースのみを管理 していましたが、Enterprise ティアでは 他のクラウドサービスプロバイダもサポート します。 2024年4月時点では Amazon Web Services（AWS）が対応されており、今後 Azure も対応予定です。 Enterprise ティアにより、異なるクラウドサービスプロバイダのセキュリティを Google Cloud 上で一元管理できるようになり、セキュリティ体制の向上を図ることができます。 画像は 公式ブログ より引用 参考 : Enterprise tier released to General Availability デモ セッション内では、 Security Command Center Enterprise のコンソール画面での操作や、Gemini と統合され自然言語で脅威の検出結果や情報の検索のデモがありました。 Google Cloud Next '24 の1、2日目を通して参加した各セッションでは多くが Gemini との統合を発表しており、Security Command Center Enterprise も同様に Gemini との統合によってセキュリティ運用の効率化と高度化が期待されます。 関連記事 blog.g-gen.co.jp 藤岡 里美 (記事一覧) クラウドソリューション部 数年前までチキン売ったりドレスショップで働いてました！2022年9月 G-gen にジョイン。ハイキューの映画を4回は見に行きたい。 Google Cloud All Certifications Engineer / Google Cloud Partner Top Engineer 2024 Follow @fujioka57621469

G-gen の武井です。本記事は Google Cloud Next '24 in Las Vegas の2日目に行われた Breakout Session「 Cloud Run: What's new 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Volume Mounts Automatic Security Updates Deterministic URL Gemini in Cloud Run Recommendations Multi-region services New integrations Application canvas Direct VPC Egress 関連記事 セッションの概要 本セッションでは Cloud Run に関するプロダクトの最新機能が紹介されました。 ご紹介する各機能のリリース段階についてはこちらをご確認ください。 参考： プロダクトのリリースステージ Volume Mounts すでに2024年1月と3月に発表済みですが、NFS ボリュームと Cloud Storage バケットのマウントが Preview となっています。 Automatic Security Updates デプロイされたイメージに対してベースイメージのアップデートを自動実行する機能が Private Preview となります。 アップデートが行われてもダウンタイムが発生せず、イメージの再構築も必要ありません。セキュリティインシデントに対して48時間以内にパッチが自動適用されます。 Deterministic URL デプロイ時の URL にカスタムドメインを使用できる機能が Private Preview となります。また、必要に応じて‘run.app’のURLを完全に無効にすることができます。 本機能に Private Google Access と Private Service Connect が対応するのは近日中とのことです。 Gemini in Cloud Run Recommendations Cloud Run のコンソール画面に Gemini のバナーが組み込まれ、推奨事項の提示や分析を行う機能が Private Preview となります。 Multi-region services 単一のコマンドで、同一サービスを複数のリージョンにデプロイできる機能が Private Preview となります。 また、グローバル外部アプリケーションロードバランサを同時に自動作成してリクエストを最も近いリージョンにルーティングします。これにより遅延を最小限に抑えながらサービスにアクセスできます。 New integrations ワンクリックで自動的に3つのプロダクト (Cloud SQL、Firestore、VertexAI) と統合してサービス拡張が可能となる機能が Private Preview となります。 セットアップの複雑さを削減し、開発プロセスの迅速化に役立ちそうです。 Application canvas 数回のクリックと画面上の視覚的な操作でアーキテクチャを図式化してデプロイする機能が Private Preview となります。 また、Gemini (自然言語) を利用して必要なアーキテクチャを図式化してデプロイすることも可能です。 Direct VPC Egress そして最後に Direct VPC Egress です。直近アナウンスのあった 全リージョン対応 、 Cloud NAT (Public IP) 対応 を含めての GA となります。 なお、Direct VPC Egress に関する詳細は弊社ブログをご確認ください。 blog.g-gen.co.jp 関連記事 blog.g-gen.co.jp 武井 祐介 (記事一覧) 2022年4月にジョイン。クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2024 に選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei

G-gen の堂原です。本記事は Google Cloud Next '24 in Las Vegas の 2 日目に行われた Breakout Session「 Optimize your machine learning applications using BigQuery DataFrames 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 背景 BigQuery DataFrames デモ ユースケース 関連記事 セッションの概要 本セッションでは、この度 GA となった BigQuery DataFrames について、概要、デモ及びユースケースが紹介されました。 アジェンダ 背景 Next '24 内でも繰り返し述べられている通り、データ分析、特に AI・生成 AI を用いたデータ分析のための幅広いサービスが Google Cloud では提供されており、BigQuery はその代表と言えるでしょう。 さて、Python はデータアナリストやデータサイエンティスト（セッション中では「data practitioner」と称されてました）から最も人気なプログラミング言語です。 pandas や scikit-learn を用いたデータ処理、AI 分析はメジャーなデータ分析手法です。 ここで、BigQuery に蓄積されたビックデータを、これらのライブラリで分析するとき、以下のような課題に直面します。 メモリ : これらのライブラリはデータを一度ローカルのメモリに格納する必要があり、TB を超えるようなデータを分析する際、メモリ不足に直面する コンピューティング : ローカルで TB を超えるデータを処理する場合、使用している計算機のパワーが不足してしまう ガバナンス : 分析のためにはデータをローカルにコピーする必要があり、データの漏えい等のリスクがつきまとう そのため、これまでは Spark 等を用いる必要がありました。 BigQuery DataFrames BigQuery では、pandas、scikit-learn のような操作感で BigQuery 上のデータを分析することができる、 BigQuery DataFrames が提供されています。 BigQuery DataFrames を用いることで、データを BigQuery に残したまま、つまり圧倒的なスケーリング機能が担保されたまま、慣れ親しんだ方法とほぼほぼ変わらないデータ分析が可能となります。 以前からプレビュー公開されていた本機能ですが、この度、晴れて GA（一般公開）されました。 BigQuery DataFrames は、以下のブログ記事で解説している通り大きく 2 つの機能が提供されています。 bigframes.pandas bigframes.ml blog.g-gen.co.jp その上で今回、 Gemini や PaLM 2 が呼び出せる bigframes.ml.llm が機能として追加されました。 デモ 上記の機能のデモとして、商品の購入履歴を基に以下のような処理を行う様子が紹介されました。 データの前処理 k-means を用いたクラスタリング Gemini を用いた各クラスターの解析及びキャンペーンメッセージの作成 約 1.6 TB ある購入履歴テーブルに対して、メモリが 15 GB しかないインスタンス上で上記の処理がスムーズに行われていきました。 ユースケース 最後に、ユースケースとして国際的な小売企業である Carrefour 社での活用が紹介されました。 Carrefour 社では、世界各国で生成されたデータが地域レベル、グローバルレベルの BigQuery に格納されています。 Carrefour 社でも例に漏れず、データ分析チームで最も需要のある言語は Python であり、実行環境のキャパシティを気にすることなく Python での分析が可能な BigQuery DataFrames はかなり重宝されているとのことでした。 関連記事 blog.g-gen.co.jp 堂原 竜希 (記事一覧) クラウドソリューション部データアナリティクス課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara