G-gen の杉村です。2024年7月のイチオシ Google Cloud アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに 新サービス「Dataplex Catalog」が公開（GA） Cloud Monitoring アラートポリシーの有償化 Google Meet で文字起こしや録画を事前設定できるように Spanner で Dual-region 設定が可能に Google Docs で Markdown のインポート・エクスポートが可能に Cloud Run でデフォルト URL を無効化可能に（Preview） Vertex AI Search の answer メソッドで Multi-step retrieval for answer が GA BigQuery で CHANGES() 関数が登場（Preview） Cloud Digital Leader 認定資格の参考書が発売 BigQuery で Continuous queries が登場（Preview） Monitoring Query Language (MQL) が廃止へ VPC Service Controls がプライベート IP に対応 BigQuery でテーブルエクスプローラ（table exlorer）が Preview 公開 Cloud SQL の IAM 認証で Google グループが使えるように Google Cloud で Private Makertplace が GA BigQuery で administrative jobs explorer が利用可能に（GA） はじめに 当記事では、毎月の Google Cloud アップデートのうち特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 新サービス「Dataplex Catalog」が公開（GA） Dataplex Catalog overview (2024-07-08) 新サービス「Dataplex Catalog」が公開（GA）。GA ではあるが、順次ロールアウト。 Google Cloud 上の各種データに対するメタデータ管理ツールであり、従来の「Data Catalog」よりDataplexとの統合が強化されている。 Aspectという設定値によりメタデータを付与・管理する。 Cloud Monitoring アラートポリシーの有償化 Pricing for alerting (2024-07-11) 従来まで無料だった Cloud Monitoring のアラートポリシー（Alert policies）機能が、2025年1月7日から課金開始される。 2024年7月11日現在の公式ページに基づく課金単価は以下のとおり。 アラートポリシー内の条件（Condition）ごとに $1.50/月 条件でクエリされたメトリクスの100万個のタイムシリーズごとに $0.35 Google Meet で文字起こしや録画を事前設定できるように Pre-configure meeting notes, recordings, and transcripts from the Calendar invite (2024-07-09) Google Meet のカレンダー予定の設定で、文字起こしや録画を事前設定できるように。 管理者設定の画面から、事前に設定できる。録画忘れなどが回避できる。 Spanner で Dual-region 設定が可能に Dual-region configurations (2024-07-12) Spanner でデュアルリージョン（Dual-region）設定が可能に。 Spanner では従来、可用性 SLA 99.99% の「リージョナル（Regional）」と 99.999% の「マルチリージョナル（Multi-region）」の2種類だった。これに加え、2つのリージョンにインスタンスを設置する「デュアルリージョン（Dual-region）」が利用可能になった。 デュアルリージョン（Dual-region）では、1国内のうち、2つのリージョンにインスタンスが設置される。これにより、データレジデンシーに対応可能。可用性 SLA は 99.999%。 Google Docs で Markdown のインポート・エクスポートが可能に Import and export Markdown in Google Docs (2024-07-16) Google Docs（Google ドキュメント）で Markdown のインポート・エクスポートが可能に。 Docs へのコピー＆ペーストで Markdown が解釈される Docs の Markdown 形式でのダウンロード Markdown ファイルを Google Docs で開く 画像は公式ドキュメントより引用 Cloud Run でデフォルト URL を無効化可能に（Preview） Disable the default URL (2024-07-18) Cloud Run でデフォルト URL を無効化する機能が Preview 公開。 無効化すると Cloud Run service の起動は Cloud Load Balancing 経由のみに限定され、セキュリティ強化に。Pub/Sub や BigQuery リモート関数からの呼び出しも不可になるので注意。 blog.g-gen.co.jp Vertex AI Search の answer メソッドで Multi-step retrieval for answer が GA Vertex AI Agent Builder release notes - July 19, 2024 (2024-07-19) Vertex AI Search の answer メソッドで Multi-step retrieval for answer 機能が GA。 ユーザーからのクエリを自動的に書き換えて ReAct（Reasoning + Acting）と呼ばれる手法で生成結果に対する再クエリを行う。これにより適切な検索結果を得る。 blog.g-gen.co.jp BigQuery で CHANGES() 関数が登場（Preview） Table functions (built in) - CHANGES (2024-07-22) BigQuery で CHANGES() 関数が登場（Preview）。 指定したタイムスタンプ間でテーブルの変更履歴が取得できる。取得できるのはテーブルのタイムトラベル期間内の範囲のみ。 画像は公式ドキュメントより引用 Cloud Digital Leader 認定資格の参考書が発売 合格対策 Google Cloud認定資格 Cloud Digital Leader テキスト＆演習問題 (2024-07-22) 国内初の Cloud Digital Leader 試験のテキストが発売。リックテレコム社から。 Cloud Digital Leader 試験は Google Cloud 認定試験の中でも最も初級に位置する基本的な資格であり、エンジニアのみならずビジネスパーソンによる取得もされる。 合格対策 Google Cloud認定資格Cloud Digital Leader テキスト＆演習問題 作者: 杉村 勇馬 , 又吉 佑樹 リックテレコム Amazon BigQuery で Continuous queries が登場（Preview） Introduction to continuous queries (2024-07-23) BigQueryのContinuous queries が Preview 公開。Google Cloud Next 24で発表されていた機能。 Storage Write APIなどで継続的にBQに流入するデータをSQLで変換。BigQuery テーブル、Pub/Sub、Bigtable などに書き込む。 イベントドリブンなパイプライン、異常検知、リバースETLなどに利用。 画像は公式ドキュメントから引用 Monitoring Query Language (MQL) が廃止へ Deprecation - Monitoring Query Language (MQL) (2024-07-23) Cloud Monitoring 用のクエリ言語である Monitoring Query Language (MQL) が廃止へ。 2024-10-22には一部機能が廃止、2025-07-22にはコンソール上で利用不可・サポート停止（API では利用可能）。代替として PromQL（Prometheus Query Language）の利用が推奨へ。 VPC Service Controls がプライベート IP に対応 Announcing VPC Service Controls with private IPs to extend data exfiltration protection (2024-07-25) VPC Service Controls がプライベート IP に対応。 これまで VPC 単位でしか許可できなかったが、これによりオンプレや Shared VPC の特定セグメントだけを許可できる。より詳細なアクセス制御が可能に。 BigQuery でテーブルエクスプローラ（table exlorer）が Preview 公開 Create queries with table explorer (2024-07-25) BigQuery でテーブルエクスプローラ（table exlorer）が Preview 公開。 BigQuery Studio 上で、テーブルの列の値の count 結果を表示、一度に選択できる列は最大10。対応するクエリも生成される。ビューや外部テーブルにも適用可。以下の記事も参照。 blog.g-gen.co.jp Cloud SQL の IAM 認証で Google グループが使えるように IAM group authentication (2024-07-26) Cloud SQL の IAM 認証で、Google グループが使えるようになった。 これまではアカウント単位もしくはサービスアカウントでしか認証できなかった。今後は、グループにまとめてアクセス制御を行うことで、異動や退職に関わる権限変更の運用が効率的になる。 Cloud SQL の IAM 認証については以下の記事も参照。 blog.g-gen.co.jp Google Cloud で Private Makertplace が GA Google Cloud Private Marketplace, now GA, helps control costs and maintain governance (2024-07-30) Google Cloud で Private Makertplace が GA。 管理者がキュレートした信頼できるプロダクトだけを購入できるマケプレ。Google Cloud 上でのシャドー IT 対策になる。 BigQuery で administrative jobs explorer が利用可能に（GA） Use administrative jobs explorer (2024-07-29) BigQuery で administrative jobs explorer が利用可能に（GA）。 プロジェクトで実行されたジョブ（クエリ等）を横断で確認できる。スロット実行時間、読み取りバイトなどの各種フィルタやソート機能があり、トラシュやパフォーマンス・コスト最適化に利用できる。 Administrative jobs explorer 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen 大津です。 前回は Imagen と Gragio を使ってテキストプロンプトから新しい画像を生成するアプリを開発しました。 はじめに 当記事で開発するもの 背景生成アプリの活用例 背景生成アプリの実行イメージ 利用サービス・ライブラリ ソースコードの開発 Python のバージョン Dockerfile の作成 requirements.txt の作成 main.py の作成 Google Cloud へのデプロイ Cloud Run の使用 Cloud Run にデプロイ 動作確認 動作画面 Cloud Run のアクセス元制御について はじめに 当記事で開発するもの 本記事では、Imagen のAPIを用いて、 アップロードした画像の背景（または前景）を自動的に認識し、テキストプロンプトに沿った背景（または前景）画像を生成 するものです。 具体的には、以下の機能を提供します。 画像、パラメータ、プロンプトをセットして、Imagen 2 にリクエストを投入する アップロードした画像は Imagen 2 でマスキングを実施し、前景と背景に識別する 日本語のテキストプロンプトを受け付ける UI は日本語で表示する 一方で、以下は要件としていません。 自分でマスキング範囲を指定する 画像に文字情報を追加する 特定の画像を使ってファインチューニングする ソースコードは、Google Cloud が提供する以下の GitHub リポジトリのソースコードを元にし、一部改変しています。ソースコードは Apache 2.0 ライセンスに基づいて公開されています。 参考 : Editing with Imagen 2 and MaskMode on Vertex AI - GitHub なお、筆者の別の記事では、当記事と同じように Imagen を使って画像生成アプリを開発しました。そちらもご参照ください。 blog.g-gen.co.jp 背景生成アプリの活用例 背景画像の生成は、以下のような様々なシーンで活用することができます。 ECサイト運営者 商品画像の背景を瞬時に生成し、商品をより魅力的にアピール 季節やイベントに合わせた背景で、タイムリーな商品画像を作成 大量の商品画像を短時間・低コストで作成し、作業効率を大幅に向上 クリエイター SNS投稿のアイキャッチ画像を簡単に作成 ブログ記事のアイキャッチ画像を、記事内容に合ったデザインで生成 プレゼンテーション資料の背景を、聴衆を引きつけるデザインで作成 その他 不動産広告の物件画像の背景を変更 ゲームやVRの世界で、リアルな背景を生成 教育現場で、教材に合わせた背景画像を生成 背景生成アプリの実行イメージ アップロードした画像（左上）にテキストプロンプト（左下）を与えることで、Imagen により背景が変更された新しい画像を生成（右側）します。 以下は、本アプリを使って、背景画像を生成した実行例になります。 前回開発した画像生成アプリを使って「サッカーをするパンダ」の画像を生成、背景画像の生成アプリに、の画像（サッカーをするパンダ）とテキストプロンプト（都心の風景）を与えて、新しい画像を4種類生成しています。 本アプリで背景画像を生成した実行例 左側：上部が画像のアップロード、下部は、編集内容やテキストプロンプトなどImagenにセットする引数を指定 右側：入力情報に基づいてimagen が生成した画像を表示する 利用サービス・ライブラリ 当記事では、以下の要素を使ってアプリを開発しました。 Imagen Google が提供する画像生成 AI モデルです。 2024年7月現在、Imagen を使用するためには申請が必要となります。 参考 : Imagenを使ったシンプルな画像生成AIアプリを開発してみた Gradio 機械学習 Web アプリを容易に構築できる Python フレームワークです。 参考 : Gradio Docs - Interface Cloud Run Google Cloud の、コンテナを実行のためのフルマネージドサービス 参考 : Cloud Run を徹底解説！ ソースコードの開発 Python のバージョン 当記事では、Python 3.12.0 を使って開発しています。 $ python --version Python 3.12 . 0 ディレクトリ構成 今回開発した画像生成 Web アプリのディレクトリ構成は以下のとおりです。 imagen-app |-- main.py |-- requirements.txt |-- Dockerfile Dockerfile の作成 Cloud Run へのデプロイには Docker イメージを用意する必要があるため、Dockerfile を作成します。 FROM python: 3.12 -slim WORKDIR /usr/src/app COPY requirements.txt ./ RUN pip install --no-cache- dir -r requirements.txt COPY . . EXPOSE 10080 CMD [ "python" , "./main.py" ] requirements.txt の作成 使用するライブラリを、以下のとおり requirements.txt に定義します。 gunicorn google-cloud-aiplatform== 1.52 . 0 google-generativeai== 0.5 . 4 gradio== 4.36 . 0 main.py の作成 開発したコードの全文を以下に記載します。 変数 PROJECT_ID に定義する Your-Project-ID の部分は、ご自身が使用する Google Cloud プロジェクトの IDに置き換えてください。 ライセンス規約に基づき、改変部分が判るようにコメントを追加しています。 # Copyright 2023 Google LLC # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # https://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. import io import traceback import gradio as gr import vertexai from vertexai.preview.vision_models import Image,ImageGenerationModel,ImageGenerationResponse # 環境変数の設定 PROJECT_ID = "Your-Project-ID" # Google Cloud プロジェクトの ID LOCATION = "us-central1" # Gemini モデルを使用するリージョン vertexai.init(project=PROJECT_ID, location=LOCATION) # 画像の前処理 def get_bytes_from_pil (image: Image) -> bytes : byte_io_png = io.BytesIO() image.save(byte_io_png, "PNG" ) return byte_io_png.getvalue() # 画像の生成処理 def imagen_generate ( base_image, mask_mode: str , edit_mode: str , prompt: str , negative_prompt: str , ): # 使用するモデルの指定 IMAGE_GENERATION_MODEL = "imagegeneration@006" generation_model = ImageGenerationModel.from_pretrained(IMAGE_GENERATION_MODEL) image_pil = Image(image_bytes=get_bytes_from_pil(base_image)) generate_response: ImageGenerationResponse = generation_model.edit_image( prompt=prompt, base_image=image_pil, negative_prompt=negative_prompt, number_of_images= 4 , edit_mode=edit_mode, mask_mode=mask_mode, language= "ja" , # 日本語でのプロンプトに対応するために追加 ) return [img._pil_image for img in generate_response.images] # Update function called by Gradio def update ( base_image, mask_mode, edit_mode, prompt, negative_prompt, ): if len (negative_prompt) == 0 : negative_prompt = None print ( "prompt:" , prompt) print ( "negative_prompt:" , negative_prompt) images = [] error_message = "" try : images = imagen_generate(base_image, mask_mode, edit_mode, prompt, negative_prompt) except Exception as e: print (e) error_message = """ An error occured calling the API. 1. Check if response was not blocked based on policy violation, check if the UI behaves the same way. 2. Try a different prompt to see if that was the problem. """ error_message += " \n " + traceback.format_exc() return images, error_message # gradio の設定 iface = gr.Interface( # 使用する関数 fn=update, # 入力タイプ：テキストと画像 inputs=[ gr.Image( label= "アップロードした画像" , type = "pil" , ), gr.Dropdown( label= "マスクモード" , choices=[ "foreground" , "background" ], value= "background" , ), gr.Dropdown( label= "編集モード" , choices=[ "product-image" , "inpainting-insert" , "inpainting-remove" , "outpainting" ], value= "product-image" , ), gr.Textbox( label= "プロンプト入力" , # 日本語での表示に修正 # 日本語での説明文章に修正 placeholder= "短い文とキーワードをカンマで区切って使用する" , value= "" , ), gr.Textbox( label= "ネガティブプロンプト" , # 日本語での表示に修正 # 日本語での説明文章に修正 placeholder= "表示したくない内容を定義する" , value= "" , ), ], # 出力タイプ：画像 outputs=[ gr.Gallery( label= "Generated Images" , show_label= True , elem_id= "gallery" , columns=[ 2 ], object_fit= "contain" , height= "auto" , ), gr.Textbox(label= "Error Messages" ), ], # 日本語での説明文章に修正 title= "Image modify with Imagen on Vertex AI" , # タイトルの修正 description= """画像から背景（前景）を認識し、プロンプトの内容に沿った画像を生成します。Imagen のドキュメントについては、この[リンク](https://cloud.google.com/vertex-ai/docs/generative-ai/image/generate-images)を参照してください。 """ , allow_flagging= "never" , theme=gr.themes.Soft(), ) # # Local 起動 # iface.launch() # Cloud Run 起動 iface.launch(server_name= "0.0.0.0" , server_port= 10080 ) Google Cloud へのデプロイ Cloud Run の使用 開発した画像生成 Web アプリを、Google Cloud 上にデプロイします。 当記事ではデプロイ先のサービスとして、サーバーレス コンテナ コンピューティングサービスである Cloud Run を使用します。Cloud Run の詳細については以下の記事をご一読ください。 blog.g-gen.co.jp Cloud Run にデプロイ Dockerfile の存在するディレクトリで以下のコマンドを実行し、コンテナイメージのビルドと Cloud Run へのデプロイを同時に行います。 # Cloud Run サービスをデプロイ $ gcloud run deploy edit-imagen --source . \ --region=asia-northeast1 \ --allow-unauthenticated \ --port 10080 \ --memory=1Gi \ -- min -instances= 1 \ -- max -instances= 1 ビルドされたコンテナイメージは、指定したリージョンに自動で作成される「cloud-run-source-deploy」という名前の Artifact Registory リポジトリに格納されます。 参考 : ソースコードからデプロイする  |  Cloud Run Documentation  |  Google Cloud 動作確認 Cloud Run のデプロイが完了すると、標準出力に Cloud Run のエンドポイントが Service URL として出力されます。この URL に、ブラウザからアクセスします。 $ gcloud run deploy edit-imagen --source . --port 10080 --region=asia-northeast1 --allow-unauthenticated --memory=1Gi -- min -instances= 1 -- max -instances= 1 This command is equivalent to running `gcloud builds submit --pack image=[IMAGE] .` and `gcloud run deploy gradio-imagen --image [IMAGE]` Building using Buildpacks and deploying container to Cloud Run service [edit-imagen] in project [Your-Project-ID] region [asia-northeast1] ✓ Building and deploying... Done. ✓ Uploading sources... ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/34c8fdeb-02c3-469d-b6ed-9b589d64d759?project=ZZZZZZZZZZZ]. ✓ Creating Revision... ✓ Routing traffic... ✓ Setting IAM Policy... Done. Service [edit-imagen] revision [edit-imagen-XXXXX-XXXXX] has been deployed and is serving 100 percent of traffic. Service URL: https://gradio-imagen-XXXXXXXXX-an.a.run.app 動作画面 Cloud Run で生成されたURLにブラウザからアクセスすると、以下の Web 画面が表示されます。 背景生成アプリのの実行画面 Cloud Run のアクセス元制御について Cloud Run にデプロイした Web アプリのアクセス元制御を行いたい場合、Cloud Run の前段にロードバランサーを配置し、Identity Aware Proxy（IAP）による IAM 認証や Cloud Armor による IP アドレスの制限を実装することができます。 以下の記事もご参照ください。 blog.g-gen.co.jp 大津 和幸 (記事一覧) クラウドソリューション部 2022年4月にG-gen にジョイン。 前職まではAWSをはじめインフラ領域全般のなんでも屋。二刀流クラウドエンジニアを目指して、AWSのスキルをGoogle Cloudにマイグレーション中の日々。

G-gen の佐々木です。当記事では同一プロジェクトにある Cloud Run 間の通信をプライベートな通信経路で行う方法を解説します。 Cloud Run から Cloud Run へのアクセス方法 パブリックアクセス プライベートアクセス 構成図 事前準備 シェル変数の設定 Artifact Registry リポジトリの作成 バックエンドサービスの作成 使用するコード（Go） コンテナイメージのビルド Cloud Run デプロイ用 YAML ファイルの作成 Cloud Run サービスの作成 VPC とサブネットの作成 フロントエンドサービスの作成 サービスアカウントの作成 使用するコード（Go） コンテナイメージのビルド Cloud Run デプロイ用 YAML ファイルの作成 Cloud Run サービスの作成 疎通の確認 Cloud Run から Cloud Run へのアクセス方法 パブリックアクセス マイクロサービスなどのユースケースにおいて、Cloud Run から別の Cloud Run にアクセスするケースがあります。この場合、アクセスされる側の Cloud Run にて、設定項目である「上り（内向き）の制御」を「 すべて 」に設定することで、他の Cloud Run からアクセスすることができます。 上り（内向き）の制御を「すべて」に設定する しかし、このような設定の場合、たとえアクセスされる側の Cloud Run がインターネットに公開したくないサービスであっても、インターネットから到達できてしまう状態となっています。IAM による認証を必須にすることでアクセスをブロックすることもできますが、なるべくはアクセス元を制限し、ネットワークレイヤで制限をかけたほうが、よりセキュアです。 パブリックアクセスが可能な Cloud Run プライベートアクセス Cloud Run では、「上り（内向き）の制御」を「 内部 」に設定することで、同一プロジェクトの VPC を経由した通信のみが Cloud Run にアクセスできるように設定することができます。 上り（内向き）の制御を「内部」に設定する 「内部」に設定された Cloud Run に対して別の Cloud Run からアクセスする場合、通信は VPC を経由しなければならないため、アクセス元の Cloud Run は Direct VPC Egress もしくは サーバーレス VPC アクセス （両者の比較については こちらの記事 を参照）を使用して VPC にアクセスできるようにします。 このとき、Cloud Run から接続される VPC 内のサブネットで 限定公開の Google アクセス を有効にしておく必要があります。 VPC を経由した場合のみ呼び出し可能な Cloud Run Cloud Run の呼び出しに IAM 認証を必須にすることで、VPC を経由し、かつ IAM で許可された場合のみ Cloud Run にアクセスできるようになります。 IAM で許可されているアクセス元が VPC を経由した場合のみ呼び出し可能な Cloud Run なお、上記の方法は、Cloud Run が両方とも同一のプロジェクトに存在する場合のみ利用可能です。 Cloud Runから 別のプロジェクトにある Cloud Run への通信を「内部」で行いたい場合、VPC Service Controls や Private Service Connect を使用する必要があります。詳細については以下の記事をご一読ください。 blog.g-gen.co.jp 参考： Private networking and Cloud Run - Receive requests from other Cloud Run services, App Engine, and Cloud Functions 構成図 当記事では Direct VPC Egress を使用することで、フロントエンドとして作成した Cloud Run サービスからバックエンドの Cloud Run サービスに対して、VPC を経由したプライベートな通信経路で接続を行います。 バックエンドの Cloud Run では、上り（内向き）の通信を「内部」のみ許可するように設定することで、インターネットからのアクセスを防ぎます。また、認証を必須にすることで、VPC からの通信であっても IAM で許可されたアクセス元のみがサービスを利用できるようにします。 VPC を経由してバックエンドのサービスに内部アクセスする Cloud Run 事前準備 シェル変数の設定 当記事では gcloud コマンドを使用して各種リソースを作成していきます。 コマンド内で何度か使用する値は、以下のようにシェル変数として設定しておきます。 PROJECT 変数の値にはリソースを作成するプロジェクトを、 LOCATION 変数の値にはリージョンを設定してください。残りの変数は各種リソースの名前を指定する際に使用します。 PROJECT =my-project LOCATION =asia-northeast1 NETWORK =my-vpc # VPCの名前 SUBNET =my-subnet # サブネットの名前 REPO =my-repo # Artifact Registory リポジトリの名前 RUN_SA =run-frontend # Cloud Run（フロントエンド）に紐付けるサービスアカウントの名前 Artifact Registry リポジトリの作成 Cloud Run 用のコンテナイメージを格納するための Artifact Registory リポジトリを作成します。 # Artifact Registry リポジトリを作成する $ gcloud artifacts repositories create ${REPO} \ --repository-format = docker \ --project = ${PROJECT} \ --location = ${LOCATION} バックエンドサービスの作成 まずはアクセス対象となるバックエンドの Cloud Run サービスを作成していきます。 バックエンドのサービスは、フロントエンドの Cloud Run のみが呼び出すことができる認証付きの API 機能を想定します。サービスに対してインターネットからアクセスできないようにし、また IAM による認証を必須とします。 使用するコード（Go） 当記事では Go を使用してサービスを実装していきます。 フロントエンドからのリクエストに対して、ステータスコード 200 と「Hello from backend!」というメッセージを JSON で返却するシンプルな内容となっています。 // backend/main.go package main import ( "encoding/json" "log" "net/http" ) type Response struct { Status int Message string } func main() { log.Print( "Service is running on port 8080" ) http.HandleFunc( "/" , func (w http.ResponseWriter, r *http.Request) { body := Response{ http.StatusOK, "Hello from backend!" , } res, err := json.Marshal(body) if err != nil { http.Error(w, err.Error(), http.StatusInternalServerError) return } w.Header().Set( "Content-Type" , "application/json" ) w.Write(res) }) if err := http.ListenAndServe( ":8080" , nil ); err != nil { log.Fatal(err) } } コンテナイメージのビルド Cloud Build を使用してコンテナイメージをビルドし、Artifact Registory リポジトリにプッシュします。 当記事では Buildpacks を使用することで、Dockerfile を用意せずにコンテナイメージを作成していきます。 # Cloud Build でコンテナイメージをビルドする $ gcloud builds submit --pack image = ${LOCATION} -docker.pkg.dev/ ${PROJECT} / ${REPO} /run-backend 参考： Build container images - Build with Google Cloud's buildpacks Cloud Run デプロイ用 YAML ファイルの作成 当記事では YAML ファイルを使用して Cloud Run サービスを作成していきます。 # backend.yaml apiVersion : serving.knative.dev/v1 kind : Service metadata : name : run-backend # サービスの名前 annotations : run.googleapis.com/ingress : internal # 上り（内向き）トラフィックを内部に制限 spec : template : spec : containers : - image : asia-northeast1-docker.pkg.dev/${プロジェクトID}/$｛リポジトリ名｝/run-backend # コンテナイメージの URL 上記の YAML ファイルで重要な箇所、および変更が必要な箇所を以下のようになります。 項目 値 説明 metadata.annotations. run.googleapis.com/ingress internal Cloud Run がインターネットからのトラフィックを受信できるようにする。 spec.template.spec.containers[0].image バックエンド用のコンテナイメージ 以下のコマンドで確認できる。 $ echo asia-northeast1-docker.pkg.dev/${PROJECT}/${REPO}/run-backend 参考： Cloud Run YAML Reference Cloud Run サービスの作成 gcloud コマンドで YAML ファイルを使用して Cloud Run を作成します。 YAML ファイルを使用する場合、サービスを新規に作成する場合であっても gcloud run service replace コマンドを使用します。 # YAML ファイルを使用して Cloud Run サービスをデプロイする $ gcloud run services replace backend.yaml \ --project = ${PROJECT} \ --region = ${LOCATION} 上り（内向き）が「内部」かつ IAM 認証が必須のバックエンドサービス 参考： gcloud run services replace VPC とサブネットの作成 後ほど作成するフロントエンドの Cloud Run から接続するための VPC とサブネットを作成します。バックエンドのサービスへの通信は、限定公開の Google アクセスを有効にしたサブネットを経由することで、インターネットではなく内部からのアクセスとなります。 当記事では Direct VPC Egress を使用して VPC に接続します。Direct VPC Egress はフロントエンドの Cloud Run 作成時に同時に作成します。 # VPC の作成 $ gcloud compute networks create ${NETWORK} \ --project = ${PROJECT} \ --subnet-mode = custom サブネット作成時に --enable-private-ip-google-access フラグを指定することで、限定公開の Google アクセスを有効にします。また、Cloud Run の制限事項として、通信の宛先となるサブネットの IP アドレス範囲が 192.168.1.0/24 の場合、通信することができない点には注意が必要です（ 参考 ）。 # サブネットの作成 $ gcloud compute networks subnets create ${SUBNET} \ --project = ${PROJECT} \ --network = ${NETWORK} \ --range = 192 . 168 . 101 . 0 / 24 \ --region = ${LOCATION} \ --enable-private-ip-google-access 限定公開の Google アクセスを有効化したサブネット 参考： gcloud compute networks subnets create フロントエンドサービスの作成 バックエンドの Cloud Run サービスにアクセスするフロントエンドサービスを作成していきます。 フロントエンドのサービスは、インターネットから不特定のユーザーにアクセスされる Web サービスを想定します。そのためサービスに対しては認証なしでアクセスできるようにします。 サービスアカウントの作成 バックエンドの Cloud Run にアクセスするための権限を付与するためのサービスアカウントを作成します。 # Cloud Run（フロントエンド）用のサービスアカウントを作成する $ gcloud iam service-accounts create ${RUN_SA} --project = ${PROJECT} 作成したサービスアカウントに、バックエンドの Cloud Run サービスを呼び出すための Cloud Run 起動元（roles/run.invoker） 権限を付与します。 # Cloud Run（バックエンド）を呼び出す権限を付与する $ gcloud run services add-iam-policy-binding run-backend \ --role =" roles/run.invoker " \ --member =" serviceAccount: ${RUN_SA} @ ${PROJECT} .iam.gserviceaccount.com " \ --project = ${PROJECT} \ --region = ${LOCATION} 使用するコード（Go） フロントエンドのサービスは、 /api にアクセスすることでバックエンドのサービスにリクエストを送信し、その後バックエンドから返ってきたメッセージを表示するように実装します。 また、 / にアクセスした場合は、フロントエンドのサービスからそのまま「Hello from frontend!」というメッセージを返します。 // frontend/main.go package main import ( "context" "fmt" "io" "log" "net/http" "os" "google.golang.org/api/idtoken" ) type Response struct { Status int `json:"status"` Message string `json:"message"` } func main() { log.Print( "Service is running on port 8080" ) http.HandleFunc( "/" , func (w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Hello from frontend!" ) }) http.HandleFunc( "/api" , func (w http.ResponseWriter, r *http.Request) { targetUrl := os.Getenv( "BACKEND_URL" ) audience := targetUrl + "/" resp, err := makeGetRequest(w, targetUrl, audience) if err != nil { fmt.Fprintf(w, "Error: %v" , err) return } defer resp.Body.Close() if resp.StatusCode != http.StatusOK { fmt.Fprintf(w, "Error: %s" , resp.Status) return } }) if err := http.ListenAndServe( ":8080" , nil ); err != nil { log.Fatal(err) } } // バックエンドの Cloud Run サービスに対してリクエストを送信する func makeGetRequest(w io.Writer , targetURL string , audience string ) (*http.Response, error ) { ctx := context.Background() client, err := idtoken.NewClient(ctx, audience) if err != nil { return nil , fmt.Errorf( "idtoken.NewClient: %w" , err) } resp, err := client.Get(targetURL) if err != nil { return nil , fmt.Errorf( "client.Get: %w" , err) } defer resp.Body.Close() if _, err := io.Copy(w, resp.Body); err != nil { return nil , fmt.Errorf( "io.Copy: %w" , err) } return resp, nil } バックエンドの Cloud Run サービスは IAM 認証を必須としているため、Google APIs のクライアントライブラリから、認証用のパッケージである idtoken を使用しています。 Cloud Run で実行する場合、Cloud Run に紐付けられたサービスアカウントの認証情報が自動で使用されます。 参考： Authenticating service-to-service - Use the authentication libraries コンテナイメージのビルド バックエンドサービスと同様の手順でコンテナイメージをビルドし、Artifact Registory リポジトリにプッシュします。 # Cloud Build でコンテナイメージをビルドする $ gcloud builds submit --pack image = ${LOCATION} -docker.pkg.dev/ ${PROJECT} / ${REPO} /run-frontend Cloud Run デプロイ用 YAML ファイルの作成 フロントエンド用の Cloud Run を作成するための YAML ファイルは以下のように記述します。 # frontend.yaml apiVersion : serving.knative.dev/v1 kind : Service metadata : name : run-frontend # サービスの名前 annotations : run.googleapis.com/ingress : all # インターネットからの上り（内向き）トラフィックを許可 spec : template : metadata : annotations : run.googleapis.com/vpc-access-egress : all-traffic # 全ての下り（外向き）トラフィックを Direct VPC Egress 経由で送信 run.googleapis.com/network-interfaces : '[{"network":"${作成したVPCの名前}","subnetwork":"${作成したサブネットの名前}"}]' spec : serviceAccountName : ${作成したサービスアカウントのメールアドレス} containers : - image : asia-northeast1-docker.pkg.dev/${プロジェクトID}/${リポジトリ名}/run-frontend # コンテナイメージの URL env : - name : BACKEND_URL value : ${Cloud Run サービス（バックエンド）の URL} 上記の YAML ファイルで重要な箇所、および変更が必要な箇所を以下のようになります。 項目 値 説明 metadata.annotations. run.googleapis.com/ingress all Cloud Run がインターネットからのトラフィックを受信できるようにする。 spec.template.metadata.annotations. run.googleapis.com/vpc-access-egress all-traffic Cloud Run から送信される全てのトラフィックを VPC 経由で送信する。 spec.template.metadata.annotations. run.googleapis.com/network-interfaces Direct VPC Egress で接続する VPC とサブネットの名前 以下のコマンドの出力をそのまま記載する。 $ echo \'[{\"network\":\"${NETWORK}\"\,\"subnetwork\":\"${SUBNET}\"}]\' spec.template.spec.serviceAccountName 作成したサービスアカウントの名前 以下のコマンドで確認できる。 $ echo ${RUN_SA}@${PROJECT}.iam.gserviceaccount.com spec.template.spec.containers[0].image フロントエンド用のコンテナイメージ 以下のコマンドで確認できる。 $ echo ${LOCATION}-docker.pkg.dev/${PROJECT}/${REPO}/run-frontend spec.template.spec.containers[0].env[0].value バックエンドの Cloud Run サービスの URL 以下のコマンドで確認できる。 $ gcloud run services describe run-backend --project=${PROJECT} --region=${LOCATION} --format='value(status.url)' Cloud Run サービスの作成 gcloud コマンドで YAML ファイルから Cloud Run サービスを作成します。 # YAML ファイルを使用して Cloud Run サービスをデプロイする $ gcloud run services replace frontend.yaml \ --project = ${PROJECT} \ --region = ${LOCATION} YAML ファイルからのデプロイでは metadata.annotations.run.googleapis.com/ingress に all を設定しても「未認証の呼び出しを許可」の設定はされないので、別途 gcloud コマンドを使用して allUsers に対して Cloud Run 起動元 のロールを付与します。 # 未認証で Cloud Run サービスを呼び出せるようにする $ gcloud run services add-iam-policy-binding run-frontend \ --role =" roles/run.invoker " \ --member =" allUsers " \ --project = ${PROJECT} \ --region = ${LOCATION} これでインターネット上から認証なしでフロントエンドのサービスにアクセスすることができます。 疎通の確認 以下のコマンドでフロントエンドのサービスの URL を確認し、ブラウザや curl コマンドなどでアクセスします。 # Cloud Run サービス（フロントエンド）の URL を確認する $ gcloud run services describe run-frontend \ --project = ${PROJECT} \ --region = ${LOCATION} \ --format =' value(status.url) ' サービスの / にアクセスした場合、フロントエンドのサービスから返ってきた「Hello from frontend!」というメッセージが表示されます。 # フロントエンドのサービスからメッセージが返る $ curl https://run-frontend-ai4xxxxxxx-an.a.run.app/ Hello from frontend! サービスの /api パスにアクセスすると、IAM で許可された内部からのアクセスのみ可能なバックエンドサービスのレスポンスが表示されます。 # フロントエンドのサービスからバックエンドにアクセスする $ curl https://run-frontend-ai4xxxxxxx-an.a.run.app/api { " Status " :200, " Message " : " Hello from backend! " } 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の奥田梨紗です。本記事では BigQuery の新しい機能である「テーブル エクスプローラ」の機能やユースケースについて紹介します。 テーブル エクスプローラとは 手順 想定されるユースケース 1. データの全体像を確認 2. 特定期間で確認（パーティション分割テーブルのみ） 3. クエリ作成を簡略化 注意点 プレビュー段階である クエリ費用が発生 テーブル エクスプローラとは 2024年7月に利用可能になった、BigQuery Studio（BigQuery の Web コンソール）の機能です。 この機能では、BigQuery テーブルの各列が持つ値の一覧化したり、出現頻度を可視化したりできます。SQL を実行しなくても、テーブル内のデータを探索的に確認することが可能です。 参考 : Create queries with table explorer 手順 手順はとてもシンプルです。 対象テーブルを選択 BigQuery Studio から「テーブル エクスプローラ」のタブに遷移 表示対象の列を選択 手順2から手順3へのコンソール画面 手順3. では、複数のチェックボックスを選択することで複数列が選択できます。チェックボックスではなく列名を選択してしまうと、他の選択が解除されてしまうので注意してください。 想定されるユースケース 1. データの全体像を確認 テーブルが持つデータの性質を簡単に確認したいときに利用します。 対象の列は、最大10個まで選択できます。列を選択すると、列の持つ値とその出現頻度が、上位10個まで表示されます。 値の抽出に際しては、裏で自動的にクエリが発行されており、通常どおりの BigQuery 利用料金が発生することに留意してください（通常のクエリエディタと同じく、事前にスキャン量の見積もりが表示されます）。 10個の列を選択したテーブル エクスプローラ また、値の左隣チェックボックスをオンにして「適用」を押下することで、その値を持つ行のみにフィルタしてデータを表示することができます。このときも、BigQuery に対してクエリが発生します。 例えば、架空の購入プロダクトと顧客リストで、購入品の「Chromebook」をチェックすることで、Chromebook の購入者のみの値を表示することができました。 チェックボックスを入れた値のみ表示されたテーブル エクスプローラ 2. 特定期間で確認（パーティション分割テーブルのみ） 本機能はパーティション分割テーブルにも対応しており、 パーティショニング フィルタを適用できます 。これにより、規模が大きいテーブルに対しても、スキャン量を節約することができるほか、特定期間内のデータのみを確認できます。 パーティション分割テーブルでのフィールド選択画面 例えば、Google Cloud の利用料金をエクスポートしたテーブルに対して、パーティション範囲を指定することで、特定の日付期間でどのサービスを利用しているのかを可視化できました。 指定したパーティション期間での値が表示されたテーブル エクスプローラ 3. クエリ作成を簡略化 パーティション テーブル タブの下部には、選択中の列と、適用中のフィルタを反映した SQL が表示されます。より詳細な分析を行いたい場合は、このクエリを活用することで効率的に分析可能です。 生成されたクエリが表示されたテーブル エクスプローラ 「生成されたクエリ」のタブ右隣の「 COPY to QUERY 」を押下することで従来のクエリ画面が分割画面で表示されます。 注意点 プレビュー段階である 2024年7月時点ではテーブル エクスプローラはプレビュー版となっており、本番環境での利用は推奨されておりません。プレビュー版のサービスを使うことに関しての注意点等は、以下の記事を参照してください。 参考 : Preview版のサービスを使うとはどういうことなのか - G-gen Tech Blog blog.g-gen.co.jp クエリ費用が発生 処理するデータ量に応じてクエリ費用が発生します。 フィールド選択後、処理されるクエリの量が表示されますため、費用の目安を確認できます。 フィルタ選択後に表示されるクエリ処理量 奥田 梨紗 (記事一覧) クラウドソリューション部クラウドデベロッパー課 前職はベトナムのIT企業。 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。日々修行中です！ Follow @risa_hochiminh

G-gen の堂原と又吉です。当記事では、 Amazon Web Services （AWS）、 Microsoft Azure 、 Google Cloud （旧称 GCP）が提供するフルマネージドな RAG サービスの比較を行います。 はじめに 当記事について RAG とは 3社比較 前提条件 機能比較 料金シミュレーション 想定シナリオ AWS Azure Google Cloud 総評 AWS Azure Google Cloud 詳細の解説 Knowledge bases for Amazon Bedrock（AWS）の詳細 構成図 プロダクト一覧 Knowledge bases for Amazon Bedrock Amazon S3 Amazon OpenSearch Service できること 検索 対応データソース 料金 概要 基盤モデル利用料金 ベクトルデータベース料金 Azure OpenAI On Your Data（Azure）の詳細 構成図 プロダクト一覧 Azure OpenAI Service Azure AI Search Azure Blob Storage できること 検索 対応データソース 料金 概要 Azure OpenAI Service Azure AI Search Vertex AI Agent Builder（Google Cloud）の詳細 構成図 プロダクト一覧 Vertex AI Agent Builder（Vertex AI Search） Cloud Storage できること 検索 対応データソース 料金 まとめ Knowledge bases for Amazon Bedrock（AWS） Azure OpenAI On Your Data（Azure） Vertex AI Agent Builder（Vertex AI Search - Summarization） パートナーによる支援 事例 はじめに 当記事について 当記事では、生成 AI アプリケーションの開発や PoC（実証実験）を検討されている方向けに、大手パブリッククラウドベンダーである Amazon Web Services （AWS）、 Microsoft Azure 、 Google Cloud （旧称 GCP）の3社がそれぞれ公開している「生成 AI を活用した検索サービス」を紹介します。 生成 AI による生成結果を根拠づけするための RAG と呼ばれる技術を簡単に実装できるサービスが、各クラウドベンダーから提供されています。当記事では、生成 AI を活用した社内ドキュメント検索などのユースケースを想定して、各クラウドベンダーのサービスをご紹介します。 RAG とは RAG とは、Retrieval Augmented Generation の略称であり、生成 AI によるテキスト生成に、外部データソースを用いて情報の根拠付けを行うアーキテクチャのことです。 生成 AI が本来持っていない情報を外部から与えることで、業務に固有の情報を加味したテキストを生成させるとともに、生成 AI が誤った情報を生成してしまう「ハルシネーション」の抑制が可能となります。 3社比較 前提条件 RAG を構築するにあたり、どのベンダーのサービスでも、複数のデータソースに対応しています。また「マネージドなサービスだけの構成」、「OSS である LangChain をベースとして適宜クラウドサービスを用いる構成」など、アーキテクチャの選択肢も複数用意されています。 採用しうる複数の選択肢の中から、当記事では以下の実現を要件として比較します。 フルマネージドサービスのみで構築 ストレージサービスに格納されているファイル（主に PDF ファイル）をデータソースとする 検索クエリを与えると、関連ファイル一覧と、それらを要約した回答を生成する Web コンソール画面で検索機能のプレビューが可能（試用のためのソースコード記述が不要） 以上の要件を満たすサービスとして、以下の3サービスを選定しました。 クラウド サービス AWS Knowledge bases for Amazon Bedrock Azure Azure OpenAI On Your Data （※） Google Cloud Vertex AI Agent Builder （Vertex AI Search - Summarization 機能） （※）Azure OpenAI On Your Data は、入力されたプロンプトに対して出力を生成する際に特定のデータソースを参照する仕組みです。他の2サービスが検索機能にフォーカスしたサービスである点では性質が異なりますが、記事執筆時点では Azure で同種のサービスがフルマネージドサービスとして提供されていないため、最も性質が近いサービスを選定しました。 機能比較 以下は、各サービスの提供機能の比較です。 Knowledge bases for Amazon Bedrock Azure OpenAI On Your Data Vertex AI Agent Builder 検索結果の表示 ◎ ◯ ※1 ◎ 要約 ◎ ◎ ◎ マルチターン ◎ ◎ ◎ 対応ファイル形式 TXT, MD, HTML, DOCX, CSV, XML, PDF ( 参考 ) CSV, EML, EPUB, HTML, JSON, DOCX, XLSX, PPTX, MSG, XML, PDF, TXT, RFT ( 参考 ) HTML, PDF, TXT, PPTX, DOCX, JSON ( 参考 ) 対応データソース S3, Web ページ, SharePoint, Salesforce, Confluence Azure Blob Storage, Webページ, Elasticsearch, Azure SQL Database, Azure Database for MySQL, Azure Cosmos DB, SharePoint など Cloud Storage, Webページ, BigQuery, Cloud SQL, Spanner, Firestore, Google Drive, Slack, SharePoint, Salesforce など メタデータによるフィルタリング ◯ ◯ ◯ ◎ : プレビュー画面から利用可能 ◯ : プレビュー画面から利用不可だが API が提供されている ※1 : プレビュー画面では参照したファイルの内容は取得できるが、ファイル名の一覧取得が不可 料金シミュレーション 想定シナリオ とあるチャットボットのバックグラウンドとして、以下のような使用状況を仮定します。 24時間・365日稼働 1日あたりの問い合わせは500件 平均の入力文字数は100文字、出力は200文字 ファイルは各ストレージサービスに PDF として格納 上記の条件の下、1 ヶ月間の利用料を計算します。なお実際には API サーバ等、RAG サービス以外の料金が発生する可能性がありますが、今回は単純化のため考慮から外します。 いずれも試算に用いた単価は記事を執筆した2024年6月現在のものです。ご自身で試算する際は、必ず公式から発表されている料金表をご参照ください。また、ドル・円換算は1ドルを160円として計算しています。 AWS 1ヶ月の利用料は約32,000円です。 OpenSearch Compute Unit - Search and Query 1 OCU : 172.8 USD Cohere - Embed - Multilingual (1 文字 1.1 トークン計算) ：0.165 USD Anthropic - Claude 3 Sonnet 入力トークン (1 文字 1.1 トークン計算) : 4.95 USD Anthropic - Claude 3 Sonnet 出力トークン (1 文字 1.1 トークン計算) : 19.5 USD Azure 1ヶ月の利用料は約21,000円です。 Azure AI Search Basic プラン 1 ユニット : 73.73 USD GPT-4o 入力トークン (1 文字 1.1 トークン計算) : 8.52 USD GPT-4o 出力トークン (1 文字 1.1 トークン計算) : 51.15 USD Google Cloud 1ヶ月の利用料は約15,000円です。 Vertex AI Search Standard Edition クエリ回数 : 31 USD Vertex AI Search Basic Search LLM Add-On クエリ回数 : 62 USD 総評 AWS Knowledge bases for Amazon Bedrock の最大の特徴は、Amazon のファーストパーティの基盤モデルだけでなく、 Anthropic 社や Cohere 社など他社の基盤モデルも柔軟に選択できる点 です。 さらに2024年7月のアップデートにより、従来の S3 に加えて、対応データストアとして Web ページや SharePoint が選択可能になりました。このアップデートにより、より広範なデータソースから情報を収集できるようになっています。 また、ドキュメントのチャンク化やベクトルデータベースの選択が可能であり、全体的にカスタマイズ性が高いといえます。このため、各ユースケースに最適な環境を構築するために、 細かなチューニングが可能 です。 これらの特徴から、Knowledge bases for Amazon Bedrock は、自分でカスタマイズやコスト最適化を行いたい 中級者および上級者向け のサービスであると言えます。 Azure 全体的にカスタマイズ性が高く、特に Azure AI Search は 検索アルゴリズム や インデックスの作成方法 、 インスタンススペック など 様々な選択肢 が用意されています。 そのため、 しっかりチューニングすることで、各ユースケースに適した環境を構築できます 。 ただし、特定の検索アルゴリズムを有効にするためには複数のコンポーネントを有効化し設定する必要がある、適切なインデックスの構成やインスタンススペックをユーザが見極める必要があるなど、高度に使いこなすためにはかなりの学習時間が必要となります。 以上から、詳細なカスタマイズやコスト最適化を行いたい 上級者向け のサービスであると言えます。 Google Cloud AWS や Azure のサービスと比べると Google 側で管理されている部分が多く、 高度な知見がなくとも高品質な RAG 環境が構築でき ます。例えば検索アルゴリズムは最初から Google が提供しているアルゴリズムが用いられていたり、すべてサーバーレスであることからインスタンススペックの見極めも必要ありません。 Slack や SharePoint 等といったサードパーティツールのマネージドコネクタが豊富なのも強みの 1 つです。 また、インスタンスを常時起動しておく必要がないため、 利用されていない時間には課金が発生しません 。 以上から、ある程度の品質を Google に担保してもらいたい 初級者および中級者向け のサービスであるといえます。 ただし、もし思うような回答を得られず精度に課題が出た場合、上級者向けの選択肢として、Vertex AI Search の 各機能を個別に利用できる API も提供されています（一部は提供予定）。これを用いることで、自前で高度な RAG を構築することも可能です。 詳細の解説 Knowledge bases for Amazon Bedrock（AWS）の詳細 構成図 プロダクト一覧 Knowledge bases for Amazon Bedrock Knowledge bases for Amazon Bedrock は、AWS が提供するマネージドな RAG アプリケーションが開発できるプロダクトです。 Amazon S3 Amazon S3 は、マネージドなオブジェクトストレージサービスです。 Amazon OpenSearch Service Amazon OpenSearch Service は、検索エンジンとその可視化を行うツールである OpenSearch をマネージドで提供するサービスです。 本構成においてはベクトルデータソースとしての役割を担います。 できること 検索 Knowledge bases for Amazon Bedrock では、データソースに対して以下の検索を行うことができます。デフォルトで自動的に最適な検索方式が選択されますが、必要に応じて特定の検索方式に固定することもできます。 ハイブリッド検索 セマンティック検索 参考 : Query configurations 対応データソース Knowledge bases for Amazon Bedrock では、以下のデータソースを対象にすることができます。 Amazon S3 Confluence SharePoint Salesforce Web ページ 参考 : Data source connectors また、当記事では紹介しませんが、検索データベースとして Amazon Kendra を利用する場合は、以下のデータソースを対象にすることができます。Amazon Kendra を利用したパターンは、Web UI からの簡単な構築はできないことに加え、利用料金も比較的高価になりますが、高精度な検索を実現できます。 Aurora Amazon RDS Amazon S3 Amazon Kendra Web Crawler Box Confluence Dropbox GitHub Gmail Google Workspace Drives Jira Microsoft OneDrive Microsoft SharePoint Microsoft Teams ServiceNow Slack Zendesk 2024年7月時点では上記を代表とする30以上のデータソースに対応しています。 参考 : Data sources 料金 概要 Knowledge bases for Amazon Bedrock では、主に 2 つのサービスで費用が発生します。 　 - 基盤モデル利用料金 - ベクトルデータベース料金 基盤モデル利用料金 提供元 モデル コンテキスト 入力 (1,000 トークンあたり) 出力 (1,000 トークンあたり) Amazon Titan Text Premier 32 K $0.0005 $0.0015 Titan Text Lite 4 K $0.00015 $0.0002 Titan Text Express 8 K $0.0002 $0.0006 Anthropic Claude 3.5 Sonnet 200 K $0.003 $0.015 Claude 3 Opus 200 K $0.015 $0.075 Claude 3 Sonnet 200 K $0.003 $0.015 Claude 3 Haiku 200 K $0.00025 $0.00125 Cohere Command 4 K $0.0015 $0.002 Command-Light 4 K $0.0003 $0.0006 Command R+ 128 K $0.003 $0.015 Command R 128 K $0.0005 $0.0015 参考 : Amazon Bedrock の料金 トークン数は文章・言語によって変化するため、正確な推測を行うことが難しいですが、Claude においては Anthropic から提供されている Client SDK を用いることで確認が可能です。 次のようなほぼ日本語のみの文章だと、文字数 1,070 (改行、空白を除く) に対してトークン数は 1,117 となります。Claude 3.5 Sonnet だと 0.0034 USD となります。 サーバーワークスグループのビジョン クラウドで、世界を、もっと、はたらきやすく 私は、人生の成功とは「どれだけたくさんのモノを与えられたか？」だと考えます。 たくさんのモノを人からもらった人、奪った人、施しを受けた人のことを、わたしたちは快く思いませんし、記憶しませんし、影響も受けません。 でも、たくさんのモノを与えた人のことは、記憶し、感謝し、尊敬します。 たくさん与えてきた人は、いまわの際にあっても、本人は充実した人生の歩みに満足し、見送る人にも惜しまれる、そんな人でいられると信じます。 与えるモノとは、考え方であったり、お金であったり、献身的な活動であったりといろいろです。そうしたモノを通じて「ポジティブな影響を与える」ことこそが、私にとっての幸せであり、成功であり、目指すところであります。 私たちは、献身的な貢献を施したナイチンゲールのことを知っていますし、暴力の無力さを訴えたマハトマ・ガンジーのことを知っていますし、「I have a dream」で始まる演説で多くの人に影響を与えたマーチン・ルーサー・キングJrのことを知っています。これらの人々は、ビジネスで成功したわけでも、大金持ちになったわけでもありませんが、間違い無く、偉大な成功を収めています。 そして私はいま、ビジネスを通じて、これらの偉大な先人がなしえたような「ポジティブな影響」を世界中に広めたいと思っています。 クラウドというアイディアは、コンピューターと人間の関係を変え、私たちの働き方をかえ、人生の時間の使い方を変えるものです。 このアイディアを世界中に人々に広め、もっとはたらきやすい、もっと人生の時間を生み出せる世の中をつくる。 そんな夢を抱いています。 その想いを、この言葉に込めました。 「クラウドで、世界を、もっと、はたらきやすく」 私が、このような意見をわざわざ表明しているのは、「私と同じように考える人を増やしたい」からです。 私は「たくさん与える」という考え方が、究極的な人生の成功をもたらす最善の道だと信じています。 私が会社を成長させたいのは、同じように考える仲間を増やし、クラウドによって世界をはたらきやすくしていくというポジティブな影響を世界に拡げていきたいからなのです。 そして、サーバーワークスという会社で働くことによって、人生を豊かに、そして人生の成功に貢献できるような環境にしていきたいのです。 私たちの力で、世界にもっと大きな影響を与え、世界中の人々の人生を豊かにしていきましょう。それこそが、私たちの究極的な人生の成功、満足につながると信じています。 一方、英文だと文字数に比べてトークン数は大幅に減少します。 以下の文章では、文字数 567 (改行、空白を除く) に対してトークン数は 145 となります。Claude 3.5 Sonnet だと 0.0004 USD となります。 OpenAI's large language models (sometimes referred to as GPT's) process text using tokens, which are common sequences of characters found in a set of text. The models learn to understand the statistical relationships between these tokens, and excel at producing the next token in a sequence of tokens. You can use the tool below to understand how a piece of text might be tokenized by a language model, and the total count of tokens in that piece of text. It's important to note that the exact tokenization process varies between models. Newer models like GPT-3.5 and GPT-4 use a different tokenizer than previous models, and will produce different tokens for the same input text. ベクトルデータベース料金 Knowledge bases for Amazon Bedrock では、以下のベクトルデータベースを対象にすることができます。 Amazon OpenSearch Serverless Amazon Aurora Pinecone Redis Enterprise Cloud Amazon OpenSearch Serverless の料金は、リソースの利用料に応じて、コンピューティングとストレージが別々に従量課金されます。コンピューティングリソースの利用料は、OpenSearch Compute Units (OCU) という計算処理単位で計測され、最低でも 1 OCU (indexing: 0.5 OCU、search: 0.5 OCU) が常時稼働しています。 そのため、US East リージョンで必要最低限のスペックの Amazon OpenSearch Serverless を利用する場合、2024 年 7 月時点では月額利用料 172.8 USD となります。 参考： Set up a vector index for your knowledge base in a supported vector store 参考： Amazon OpenSearch Service の料金 Azure OpenAI On Your Data（Azure）の詳細 構成図 プロダクト一覧 Azure OpenAI Service Azure OpenAI Service は、OpenAI 社が作成した AI モデルを Azure 上で利用することができるサービスです。 GPT-4 は勿論、画像生成モデルの DALL-E 3 や GPT-4o も利用できます。 Azure OpenAI Studio という独自の GUI を持っており、プロンプト設計などを簡単に行うことができます。 さらに、Azure OpenAI On Your Data 機能を用いれば、データストアを Azure AI Search としたマネージドな RAG が構築できます。 サブスクリプションで Azure OpenAI Service を初めて利用する場合、以下の URL から利用申請をする必要があります。通常は申請後、24時間以内に利用可能となります。 https://aka.ms/oai/access Azure AI Search Azure AI Search は、マネージドな検索サービスです。Azure Blob Storage や Azure SQL Database などといった他の Azure サービスのデータを取り込み、全文検索やベクトル検索を行うことが可能です。 もちろん、RAG における検索システムとしての役割を担うことも可能です。 Azure Blob Storage Azure Blob Storage は、マネージドなオブジェクトストレージサービスです。 できること 検索 Azure OpenAI On Your Data では、データソースに対して以下の検索を行うことができます。 キーワード検索 セマンティック検索 ベクトル検索 ハイブリッド検索 キーワード検索 + ベクトル検索 ハイブリッド検索 + セマンティック検索 複数の選択肢が用意されているため、まずキーワード検索を使い、精度が十分でない場合はセマンティック検索を試すなど、Azure OpenAI On Your Data 内だけで複数の検索方法を試行することができます。 キーワード検索以外の検索アルゴリズムでは追加料金が発生する場合があることに留意してください。 参考 : Azure OpenAI On Your Data とは 対応データソース Azure OpenAI On Your Data においては以下のデータソースを対象にすることができます。 Azure AI Search Azure Cosmos DB for MongoDB Azure Blob Storage ファイルアップロード Web サイト Elasticsearch ただし Azure Blob Storage、ファイルアップロード、Web サイトは Azure AI Search が必要となります。また Elasticseach は2024年7月時点では利用申請が必要です。 参考 : Azure OpenAI On Your Data Azure AI Search は複数のデータソースに対応しているため、結果的に Azure AI Search が対応しているデータソースも Azure OpenAI On Your Data の対象にできます。 Azure SQL Database Azure Database for MySQL Azure Cosmos DB Azure Blob Storage Azure Files Azure Data Lake Storage Gen2 SharePoint 基本的には Azure のデータベースやストレージサービスが対象ですが、SharePoint を対象にすることもできます。 参考 : データ ソース ギャラリー 料金 概要 Azure OpenAI On Your Data では、主に2つの軸で費用が発生します。 Azure OpenAI Service モデル利用料金 Azure AI Search インスタンス料金 Azure OpenAI Service 言語モデルである GPT シリーズは、入出力したトークン数によって課金が発生します。2024年7月時点での利用料金は全リージョン一律で以下の通りです。 モデル コンテキスト 入力 (1,000 トークンあたり) 出力 (1,000 トークンあたり) GPT-4o 128 K $0.005 $0.015 GPT-3.5-Turbo-0125 16 K $0.0005 $0.0015 GPT-3.5-Turbo-Instruct 4 K $0.0015 $0.002 GPT-4-Turbo 128 K $0.01 $0.03 GPT-4 8 K $0.03 $0.06 GPT-4 32 K $0.06 $0.12 Claude 同様トークン数は文章・言語によって変化するため、正確な推測を行うことが難しいですが、日本語だと 1 文字 1.1 トークンほどとなります。 参考 : ChatGPT - LLMシステム開発大全 また、以下のサイトで正確なトークン数を調べることもできます。 https://platform.openai.com/tokenizer 日本語主体の文章だと文字数より少し多めのトークン数に、英語主体だとトークン数は大きく減少するという挙動は Claude と同様です。 Claude で取り扱ったサンプル文だと以下の通りです。 日本語のみの文章 トークン数 : 1,081 GPT-4o 入力料金 : 0.0054 USD 英語のみの文章 トークン数 : 141 GPT-4o 入力料金 : 0.0007 USD Azure AI Search Azure AI Search ではリクエストを処理するためのインスタンスを起動しておく必要があります。このインスタンスが起動している時間に応じて課金が発生します。 インスタンスの基本性能にはいくつかの選択肢があり、またスケーリングの設定を行う必要があります。 Azure OpenAI On Your Data を使う大半のケースでは Azure AI Search が必要となるため、このインスタンス料金が継続的に発生することとなります。 Azure AI Search には Free プランも存在しますが、Azure OpenAI On Your Data が使えるのは Basic プラン以上です。 東京リージョンで必要最低限のスペックで Azure AI Search を利用する場合、2024年6月時点での月額利用料は 98.95 USD となります。 Vertex AI Agent Builder（Google Cloud）の詳細 構成図 プロダクト一覧 Vertex AI Agent Builder（Vertex AI Search） Vertex AI Search は、生成 AI エージェントサービスである Vertex AI Agent Builder の1機能であり、マネージドな検索サービスです。データインデックスを管理するデータストアと、ユーザーからのクエリを処理するアプリの 2 つのコンポーネントから構成されています。 サーバレスで、クエリ数に応じて料金が発生するのが特徴となります。 詳しくは以下の記事をご参照ください。 blog.g-gen.co.jp Cloud Storage Cloud Storage は、マネージドなオブジェクトストレージサービスです。 blog.g-gen.co.jp できること 検索 Vertex AI Search では Google が提供する検索アルゴリズムのみを利用することができます。 この検索アルゴリズムは Google 検索で用いられているものと同等であり、高性能です。 対応データソース Vertex AI Search では、以下のようなデータを対象とすることができます。 BigQuery Cloud SQL Spanner Bigtable Firestore Cloud Storage Google Drive SharePoint Online Slack Salesforce Jira Confluence ServiceNow Google Cloud のデータベース系サービスを始め、Google Drive や SharePoint、Slack 等といったサードパーティツールも選択することが可能です。 分析用データベースである BigQuery との連携も可能であるため、組織に蓄積されたデータを RAG に活用したり、また逆に、検索に用いられたキーワードなどを BigQuery に蓄積して業務改善に活用することもできます。Google Cloud の豊富なデータ分析・AI/ML エコシステムと連携できることが強みといえます。 料金 本アーキテクチャにおいては Vertex AI Search のリクエスト回数に応じた費用が発生します。サーバーレスでフルマネージドなため、常時起動のインスタンス料金は発生しません。 Vertex AI Search の Summarization 機能を使用する場合の料金は 1,000 クエリにつき 6 USD となります。他にも追加料金が発生するオプションが存在しますが、Cloud Storage 上の PDF ファイルから要約と関連ファイルのみを取得する場合を想定しています。 Summarization に用いる モデルの種類、入出力の文字数は料金に影響しません 。 まとめ Knowledge bases for Amazon Bedrock（AWS） 細かなチューニングが可能な中級者〜上級者向けのサービスです。 コストはかかりますが Amazon Kendra を追加で構築することで、多様なデータソースとの連携が可能です。 各社の生成 AI 基盤モデルが柔軟に選択できることが強みといえます。 Azure OpenAI On Your Data（Azure） 詳細なカスタマイズやコスト最適化を行いたい上級者向けのサービスです。 SharePoint や Azure SQL Database など、Microsoft のエコシステムとの連携も実現可能です。 詳細なチューニングが可能なことが強みといえます。 Vertex AI Agent Builder（Vertex AI Search - Summarization） ある程度の品質を Google に担保してもらいたい初級者および中級者向けのサービスです。 フルマネージドかつサーバーレスであり、構築も簡単であることから、低いコストでスピーディに RAG を実現できます。なお上級者向けの選択肢として、Vertex AI Search の 各機能を個別に利用できる API も提供されており（一部は提供予定）、自前で高度な RAG を構築することも可能です。 Googleドライブや BigQuery など、Google のエコシステムとの連携も実現可能です。Google Cloud の豊富なデータ分析・AI/ML エコシステムと連携できることが強みといえます。 パートナーによる支援 大手クラウドベンダー各社の AI/ML 系サービスは進化を続けており、少ない工数でより効果的な仕組みを開発できるようになっています。しかしながら、これらのサービスの進化は非常に早く、キャッチアップに苦労するのも事実です。 各クラウドベンダーには、クラウド技術に特化したパートナーがあり、クラウド上でのシステム開発を支援しています。当テックブログを運営する G-gen は Google Cloud 専業インテグレーターであり、そのグループ会社のサーバーワークスは AWS 専業インテグレーターです。必要に応じて、パートナーに相談することで、クラウドや AI によるスピーディな価値創出につなげてください。 g-gen.co.jp www.serverworks.co.jp 事例 RAG の仕組みを使った業務改善の事例として、当社 G-gen の顧客サポート窓口での利用例をご参照ください。 blog.g-gen.co.jp 堂原 竜希 (記事一覧) クラウドソリューション部データアナリティクス課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara 又吉 佑樹 (記事一覧) クラウドソリューション部 はいさい、沖縄出身のクラウドエンジニア！ セールスからエンジニアへ転身。Google Cloud 全 11 資格保有。Google Cloud Champion Innovator (AI/ML)。Google Cloud Partner Top Engineer 2024。Google Cloud 公式ユーザー会 Jagu'e'r でエバンジェリスト。好きな分野は生成 AI。 Follow @matayuuuu

当記事では、2024年6月に GA した Vertex AI Search の最新検索方式である Answer API について紹介します。 はじめに RAG とは Vertex AI Search Answer API 概要 メリット クエリフェーズ クエリ言い換え クエリ簡素化 マルチステップ推論 クエリ分類 検索フェーズ 回答フェーズ フォローアップ検索（マルチターン検索） 概要 セッション サンプルコード コード Tips クエリ言い換えの制御 フォローアップ検索 はじめに RAG とは RAG とは、Retrieval Augmented Generation の略称であり、生成 AI によるテキスト生成に、外部データソースを用いて情報の根拠付けを行うアーキテクチャのことです。 本来生成 AI が持ち得ない情報を与えることで、組織固有の情報を加味したテキストを生成させ、また生成 AI が誤った情報を生成してしまう「ハルシネーション」の抑制が可能となります。 Vertex AI Search Vertex AI Search とは、 Google の生成 AI を利用して RAG アプリケーションを簡単に作成できる Google Cloud のマネージドサービスです。これにより、開発者は迅速に RAG アプリケーションを開発、テスト、デプロイできます。 Vertex AI Search の解説は、以下の記事をご参照ください。 blog.g-gen.co.jp Vertex AI Search は、いくつかの検索方式（API）をサポートしています。これまで Search API と Conversation API が提供されていましたが、2024年6月に新たに Answer API が GA されました。 検索方式（API） 説明 使用方法（Python Client Library） Search 検索に特化した方法（シングルターンのみ対応） SearchRequest クラス Conversation マルチターン（会話型）の検索に特化した方式 ConverseConversationRequest クラス Answer Search のほとんどの機能に加えて、Conversation のすべての機能を兼ね備えた検索方式 AnswerQueryRequest クラス Answer API 概要 Answer API は、Search API のほとんどの機能と、Conversation API のすべての機能が提供されている点から最も優れた検索方式です。これにより、ユーザーはシンプルな検索から複雑なマルチターン検索まで幅広く対応できます。初めて Vertex AI Search の開発を行う場合は、Answer API を使用することが推奨されています。 Answer API は「 1. クエリ 」「 2. 検索 」「 3. 回答 」の 3段階のフェーズ で処理を行うことで、高精度な RAG を実現します。 ただし、特定のユースケースによっては Search API や Conversation API の方が適している場合もありますので、以下公式ドキュメントより詳細を確認してください。 参考 : When not to use the answer method メリット Answer API のメリットは以下の 3 つです。 RAG の精度を高める高度な機能（Advanced RAG） マルチターンでの検索回答 検索待ち時間を短縮する機能 RAG の精度を高める高度な機能（Advanced RAG） Answer API は 1. クエリ、2. 検索、3. 回答、の3段階のフェーズで処理を行います。例えば、クエリフェーズではクエリ言い換えやクエリ分類を行い、複雑なクエリに対する検索精度を高めます。 マルチターンでの検索回答 Answer API は、マルチターン（会話形式）での検索と回答をサポートします。これにより、過去のやり取りを理解し回答精度を高めることができます。 検索の待ち時間を短縮する機能 検索メソッドと回答メソッドを別々に呼び出すことで、検索結果を先に表示し、その後に回答を表示することができます。これにより、生成AIの回答生成を待たずユーザーに検索結果を提供することが可能です。 参考： Key features of the answer method クエリフェーズ クエリ言い換え クエリ言い換え（Query rephrasing）機能は、有効化するだけでユーザーのクエリを自動的に最適な形に書き換え、検索精度を向上させる機能です。これにより、ユーザーが長文や複雑なクエリを入力しても、システムが適切に簡素化して処理します。 この機能は、裏側でいくつかの手法をサポートしてますが、その中でも特に「クエリ簡素化」と「マルチステップ推論」を紹介します。 クエリ簡素化 長いクエリを簡素化し、検索精度を向上させます。 ユーザー入力 クエリの簡素化 株式会社G-genにおけるGoogle Workspaceの請求代行サービスに関して、具体的な割引率を教えていただきたいです。さらに、Google Cloudの請求代行サービスに関する割引率についても詳細をお伺いしたいです。これらの割引率について、どのような条件で適用されるのか、具体的なパーセンテージや適用範囲などを詳しく知りたいと考えています。また、無償で提供される技術サポートについての詳細も併せてお伺いしたいです。具体的には、どのような技術サポートが無償で提供されるのか、その内容や範囲について詳しく説明していただけますでしょうか。例えば、技術サポートの対象となるサービスや、サポートが受けられる時間帯、対応可能な問題の種類など、詳細な情報を知りたいです。これらの情報をもとに、弊社の導入計画や予算の調整を行いたいと考えておりますので、お手数をおかけしますが、詳細なご回答をいただけますようお願い申し上げます。何卒よろしくお願いいたします。 G-genのGoogle WorkspaceとGoogle Cloudの請求代行サービスの割引率、および無償の技術サポート内容について詳細を教えてください。 マルチステップ推論 ReAct（考え + 行動）に基づいて、LLM が複雑なタスクに対して段階的に回答を生成する機能です。これにより、複数のステップを踏んで最終的な答えを導き出すことができます。 ユーザー入力 答えを生成するための 2 ステップ G-gen のサービスにはどのようなものがありますか？また、それぞれのサービスの割引率を教えてください ステップ 1 : [考え]: まず、G-gen の提供するサービス一覧を調べる必要がある。 [行動] 検索: G-gen サービス一覧 [検索結果を観察]: 「G-gen は、Google Cloud 請求代行サービス、Google Workspace ライセンス販売、AppSheet ライセンス販売の3つのサービスを提供しています。」 ステップ 2 : [考え]: 次に、それぞれのサービスの割引率を調べる必要があります。 [行動] 検索: G-gen サービス 割引率 [検索結果を観察]: 「これらのサービスは、Google Cloud、Google Workspace、AppSheet の利用料金を 5% 割引します。」 答え: G-gen は、Google Cloud 請求代行サービス、Google Workspace ライセンス販売、AppSheet ライセンス販売の3つのサービスを提供しています。これらのサービスは、Google Cloud、Google Workspace、AppSheet の利用料金を 5% 割引します。 クエリ分類 クエリ分類（Query classification）機能は、敵対的なクエリ( adversarial queries ) と 要約を要求しないクエリ ( non-summary seeking queries ) を識別するオプションです。これにより、特定のクエリを検索対象から除外することができます。 参考： Query classification 検索フェーズ 検索フェーズの代表的な機能例を以下に示します。 機能 説明 フィルター フィルターを適用して、検索対象を特定のドキュメントに制限します セーフサーチ 暴力やポルノなどのコンテンツを検索結果から除外します ブースト 検索によって出力されるドキュメントにブースト条件を指定することで、検索結果を昇格または降格することができます また、2024年7月現在、Vertex AI Search の検索モデルは、業界特有の用語や企業特有の言い回しに対応するためのモデルチューニングも preview でサポートしています。 参考： Search phase features 参考： Improve search results with search tuning 回答フェーズ 回答フェーズの代表的な機能例を以下に示します。 機能 説明 モデル指定 回答生成モデルを指定できます プリアンブル設定 プロンプトのコンテキストのようなもの。役割や出力形式、詳細度合いなどをカスタマイズできます 引用を含める 回答文中に出典を示す引用を取得します 関連する回答のみ表示 クエリに対し回答の関連性が低い場合、フォールバック回答を出力します。回答がクエリと関連性の低い場合は、別の処理フローに流すといった条件分岐ロジックも実装が容易になります 分類されたクエリを無視 敵対的または要約を要求しないクエリとして分類されたクエリを、回答生成時に無視します 参考： Answer phase features フォローアップ検索（マルチターン検索） 概要 フォローアップ検索とは、同じセッション内での過去のクエリと回答を考慮した検索方法で、マルチターン（会話型）検索とも呼ばれます。この機能を利用することで、各会話履歴がセッション単位で保存されます。 参考： Commands for follow-up questions セッション セッションとは、ユーザーのクエリと Vertex AI Saech が生成する回答で構成される会話履歴のことを指します。 セッションリソースには以下のデータが含まれます。 一意の名前（セッション ID） ステータス ユーザー疑似 ID 開始時間と終了時間 過去のクエリと回答のペア つまり、1つのセッションは特定のトピックに関する会話履歴を示し、ユーザーとセッションは1対多の関係となります。 サンプルコード コード Answer API を使用する方法は REST API やクライアントライブラリが用意されていますが、今回は Python Client for Discovery Engine API を用いた API リクエストのサンプルコードを紹介します。 本サンプルコードでは、以下のオプション機能を設定しています。 クエリフェーズ クエリ言い換え 検索フェーズ 検索結果の最大件数 回答フェーズ モデル指定 プリアンブル設定 引用を含める 関連する回答のみ表示 分類されたクエリを無視 import os from google.cloud import discoveryengine_v1alpha as discoveryengine from google.api_core.client_options import ClientOptions VERTEX_AI_LOCATION = "global" PROJECT_NO = os.environ.get( "PROJECT_NO" ) DATA_STORE_ID = os.environ.get( "DATA_STORE_ID" ) client_options = ( ClientOptions(api_endpoint=f "{VERTEX_AI_LOCATION}-discoveryengine.googleapis.com" ) if VERTEX_AI_LOCATION != "global" else None ) search_client = discoveryengine.ConversationalSearchServiceClient(client_options=client_options) def answer_query ( query_text: str , session_id: str = "-" ) -> discoveryengine.types.conversational_search_service.AnswerQueryResponse: # クエリの初期化 query = discoveryengine.Query() query.text = query_text request = discoveryengine.AnswerQueryRequest( serving_config=f "projects/{PROJECT_NO}/locations/global/collections/default_collection/dataStores/{DATA_STORE_ID}/servingConfigs/default_serving_config" , query=query, # （Option）クエリフェーズ query_understanding_spec=discoveryengine.AnswerQueryRequest.QueryUnderstandingSpec( # クエリ言い換え query_rephraser_spec=discoveryengine.AnswerQueryRequest.QueryUnderstandingSpec.QueryRephraserSpec( disable= False , # True に設定するとクエリ言い換えを無効化 max_rephrase_steps= 5 # 言い換えステップ数を設定（1〜5の範囲） ), ), # （Option）検索フェーズ search_spec = discoveryengine.AnswerQueryRequest.SearchSpec( search_params = discoveryengine.AnswerQueryRequest.SearchSpec.SearchParams( max_return_results = 3 ) ), # （Option）回答フェーズ answer_generation_spec=discoveryengine.AnswerQueryRequest.AnswerGenerationSpec( # モデル指定 model_spec=discoveryengine.AnswerQueryRequest.AnswerGenerationSpec.ModelSpec( model_version= "gemini-1.5-flash-001/answer_gen/v1" ), # プリアンブル設定 prompt_spec=discoveryengine.AnswerQueryRequest.AnswerGenerationSpec.PromptSpec( preamble= "箇条書きで回答してください。" ), # 引用を含めるかどうか include_citations= True , # 関連性の低いクエリを除外するかどうか ignore_low_relevant_content= True , # 分類されたクエリを無視するかどうか ignore_non_answer_seeking_query= True , ), # （Option）フォローアップ検索利用時のセッション session=f "projects/{PROJECT_NO}/locations/global/collections/default_collection/dataStores/{DATA_STORE_ID}/sessions/{session_id}" , ) # Answer API 実行 response = search_client.answer_query(request=request) return response 参考： Class AnswerQueryRequest Tips クエリ言い換えの制御 クエリ言い換えを無効にするには、 AnswerQueryRequest の query_rephraser_spec を disable=True に設定します。また、クエリ言い換えのステップ数を制御したい場合は、 max_rephrase_steps 属性を1から5の範囲で設定します（デフォルトは1）。 # オプション：クエリフェーズの設定 query_understanding_spec = discoveryengine.AnswerQueryRequest.QueryUnderstandingSpec( # クエリ言い換えの設定 query_rephraser_spec = discoveryengine.AnswerQueryRequest.QueryUnderstandingSpec.QueryRephraserSpec( disable= False , # True に設定するとクエリ言い換えを無効化 max_rephrase_steps= 5 # 言い換えステップ数を設定（1〜5の範囲） ), ) 参考： Class QueryRephraserSpec フォローアップ検索 フォローアップ検索を利用するには、 AnswerQueryRequest に session 属性を含めます。 session 属性を含めない場合はシングルターン検索になります。新規セッションを発行する場合は、session_id に半角ハイフン（‘-’）を含めることで、レスポンスに新しいセッションが払い出されます。 参考： Class AnswerQueryResponse G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-gen の佐々木です。当記事では、Cloud Run サービスの作成時に自動生成されるエンドポイント URL の無効化について解説します。 前提知識 Cloud Run サービスについて Cloud Run におけるロードバランサーの使用 デフォルト URL の無効化 URL 無効化のメリット URL を無効化する場合の注意点 手順 前提知識 Cloud Run サービスについて Cloud Run サービスとは、Google Cloud のサーバーレス コンテナ サービスである Cloud Run の種類の1つであり、HTTP リクエストをトリガーとしてアプリケーションを実行することができるサービスです。 Cloud Run、および Cloud Run サービスの詳細については以下の記事をご一読ください。 blog.g-gen.co.jp Cloud Run におけるロードバランサーの使用 Cloud Run サービスでは、サービスにアクセスするための *.run.app ドメインの URL がデフォルトで提供されています。このエンドポイントを使用することで、ユーザー側で証明書を用意することなくサービスに HTTPS アクセスすることができます。 Cloud Run サービスのデフォルトのエンドポイント URL しかし、 Cloud Run サービスで Web アプリケーションを公開するようなユースケースでは、デフォルトで提供される URL をエンドポイントとして使用せず、アプリケーションロードバランサを Cloud Run の前段に配置することが推奨されます。 ロードバランサの使用は、独自のドメインを使用したサービスの公開や、WAF である Cloud Armor を使用したセキュリティ強化、複数サービス間でパスベースのルーティングが利用できるなどのメリットがあります。 Cloud Run サービスの前段にロードバランサを配置する Cloud Run サービスに対するアクセスをロードバランサを経由した通信のみに制限したい場合、Cloud Run の設定項目である「上り（内向き）の制御」で「 外部アプリケーション ロードバランサからのトラフィックを許可する 」に設定します。これにより、インターネットから Cloud Run サービスのエンドポイント URL に対して直接アクセスすることができなくなります。 Cloud Run の「上り（内向き）の制御」設定項目 しかし、この設定でも「内部」からのアクセス、たとえば同じプロジェクトに存在する VPC からエンドポイント URL に対するアクセスはできてしまいます。このような「内部」からのアクセスはロードバランサを迂回する形となるため、ロードバランサに紐付いている Cloud Armor のセキュリティルールが適用されないなどの問題があります。 「内部」からはロードバランサを経由しないアクセスができてしまう 「内部」からのアクセスとされる通信の種類については こちらのドキュメント を参照してください。 デフォルト URL の無効化 URL 無効化のメリット サービスの作成時および更新時に、サービスのエンドポイントとなる URL を無効化することができます。 URL を無効化することで、 サービスに対するロードバランサを迂回したアクセスができなくなる ため、すべての通信に対して Cloud Armor のセキュリティポリシーを適用することができます。 アプリケーションがロードバランサを経由したアクセスのみを想定している場合、URL を無効化しておくことで想定外のルートをなくすことができます。 URL を無効化する場合の注意点 URL を無効化する場合、「内部」から Cloud Run に対する直接アクセスができなくなるため、以下のサービスからの呼び出しができなくなります。 BigQuery remote functions Cloud Scheduler Cloud Service Mesh Cloud Tasks Eventarc Firebase App Hosting Firebase Hosting Pub/Sub Workflows 合成モニタリング、稼働時間チェック 手順 コンソール、gcloud CLI、YAML ファイルを使用したサービスのデプロイ・更新時に URL の無効化を行うことができます。 CLI の場合、 gcloud run deploy コマンドで --no-default-url フラグを指定して実行してサービスをデプロイすることで、URL が無効化されます。 # URL を無効化した Cloud Run サービスのデプロイ $ gcloud run deploy ${ サービス名 } --no-default-url サービスのデプロイに YAML ファイルを使用する場合は metadata.annotations.run.googleapis.com/default-url-disabled の値を true に設定します。 試しに、以下の YAML ファイルを使用してサービスをデプロイしてみます。 # service.yaml apiVersion : serving.knative.dev/v1 kind : Service metadata : name : url-disabled-service annotations : run.googleapis.com/default-url-disabled : "true" # URL を無効化 spec : template : spec : containers : - image : us-docker.pkg.dev/cloudrun/container/hello # サンプルのコンテナイメージ YAML ファイルを使用したデプロイは、 gcloud run services replace コマンドを使用します。 $ gcloud run services replace service.yaml --region = asia-northeast1 ----- 出力例 ----- Applying new configuration to Cloud Run service [ url-disabled-service ] in project [ myproject ] region [ asia-northeast1 ] ✓ Deploying... Done. ✓ Creating Revision... ✓ Routing traffic... Done. New configuration has been applied to service [ url-disabled-service ] . URL: None 出力例の最終行を確認すると、本来 *.run.app ドメインの URL が出力される URL: の項目が None になっていることがわかります。 コンソール上からサービスを確認しても、URL の項目にエンドポイント URL が表示されていません。 URL が無効化されたCloud Runサービス 参考： Restrict ingress for Cloud Run - Disable the default URL 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

本記事では、Google Maps API から取得したラーメン店のクチコミデータに対する定量分析手法をご紹介します。 従来の BigQuery による感情分析の有用性を踏まえつつ、Gemini 1.5 Pro の導入によって可能となった、より柔軟なデータの構造化や特定タスクの実行方法を解説します。 分析の背景と目的 可視化イメージ 分析の流れとアーキテクチャ クチコミデータ取得と BigQuery への保存 API キーの取得 データ取得のサンプルコード クチコミ数の制限と緩和策 料金 感情分析とデータパイプライン Dataform の利点 Dataform を使った感情分析のパイプライン定義例 感情分析の結果解釈 ML.GENERATE_TEXT（Gemini 1.5 Pro） 関数を使用した高度な分析 ユースケースに応じた独自の評価観点によるクチコミの定量化 クチコミに対する自動返信文作成 分析の背景と目的 近年、1 to 1 マーケティングや顧客分析の重要性が高まっています。しかし、すべての顧客から直接感想を聞くのは現実的ではありません。そこで注目したのが、Google Maps に自発的に投稿されたクチコミデータです。 クチコミ分析の主な目的は以下の通りです。 目的 例 顧客満足度の向上と製品改善 ラーメン店のクチコミで「麺が柔らかすぎる」という声が多い場合、茹で時間の調整を検討。 競合分析と市場ポジショニングの最適化 競合店との比較で「価格が高い」という指摘が多い場合、価格戦略の見直しや付加価値の訴求を検討。 効果的なマーケティング施策の立案と評価 「子連れでも利用しやすい」というクチコミが増加傾向にある場合、ファミリー向けキャンペーンの強化を検討。 トレンドの早期発見と迅速な対応 「ヴィーガンメニューが欲しい」という声が急増した場合、新メニューの開発を迅速に行う。 ビジネス指標との相関分析による戦略立案 クチコミの評価が高い店舗ほど売上が高いという相関が見られた場合、優良店舗の施策を他店舗に展開。 可視化イメージ クチコミデータの感情分析やカテゴリ・キーワード分析は以前から有りましたが、生成 AI 技術の発展によって、より自由に非構造化データを構造化データに変えられ、既存の商品、営業、販売等のデータと掛け合わせて分析できる点がポイントです。 クチコミのネガポジや頻度を地図上にプロット カテゴリごとのネガポジ、クチコミスコアとレイティングの時系列比較 カテゴリごとのネガポジと感情強度 分析の流れとアーキテクチャ 今回の検証の分析の流れとアーキテクチャは以下のとおりです。 Google Maps API からクチコミデータを取得 BigQuery に保存 BigQuery のリモート関数で感情分析 & 生成 AI による多様な自然言語解析（※ Dataform でデータパイプラインを構築） BI ツール（Looker Studio 等）で可視化 分析の流れとシステムアーキテクチャ クチコミデータ取得と BigQuery への保存 Google Maps API を使用してクチコミデータを取得し、BigQuery に保存する方法を説明します。 API キーの取得 Google Map API の中から「Places API」を使用しています。Google Cloud プロジェクトで API の有効化と API キーの取得が必要なため、手順は以下を参照してください。 参考 : Places API で API キーを使用する データ取得のサンプルコード 以下は、Python を使用したサンプルコードです。（ Colab で実行可能です） 1. ライブラリのインストール !pip install googlemaps>= 4.10 . 0 google-cloud-bigquery>= 3.2 . 5 2. 認証処理 from google.colab import auth import google.auth auth.authenticate_user() credentials, _ = google.auth.default() 3. Google Map API を使って、クチコミデータを取得し、BigQuery にアップロード 以下では、「東京都千代田区（(35.68093847942352, 139.76703854373777)）」から「半径 1,000 メートル」以内で「ラーメン」という検索キーワードにマッチする場所の情報や、それに紐づくクチコミ情報を取得しています。 import googlemaps from google.cloud import bigquery from datetime import datetime import pandas as pd class GoogleMapsReviewFetcher : def __init__ (self, api_key, project_id, dataset_id, table_id): # Google Maps API クライアントの初期化 self.gmaps_client = googlemaps.Client(key=api_key) # BigQuery クライアントの初期化 self.bq_client = bigquery.Client(project=project_id) # BigQuery のデータセット ID とテーブル ID を保存 self.dataset_id = dataset_id self.table_id = table_id def fetch_reviews (self, keyword, location, radius): reviews = [] # Google Maps Places API を使用して、指定された条件で場所を検索 places_result = self.gmaps_client.places_nearby( location=location, # 検索の中心位置（緯度、経度） radius=radius, # 検索範囲（メートル） keyword=keyword, # 検索キーワード language= 'ja' # 結果の言語を日本語に設定 ) # 検索結果の各場所について詳細情報を取得 for place in places_result[ 'results' ]: # 場所の詳細情報を取得 place_details = self.gmaps_client.place(place_id=place[ 'place_id' ], language= 'ja' ) spot_name = place_details[ 'result' ].get( 'name' ) location_lat = place_details[ 'result' ][ 'geometry' ][ 'location' ][ 'lat' ] location_lng = place_details[ 'result' ][ 'geometry' ][ 'location' ][ 'lng' ] # 各場所のレビューを処理 for review in place_details[ 'result' ].get( 'reviews' , []): reviews.append({ 'spot_name' : spot_name, 'author' : review.get( 'author_name' ), 'rating' : review.get( 'rating' ), 'text' : review.get( 'text' ), 'time' : datetime.fromtimestamp(review.get( 'time' )), 'relative_time_description' : review.get( 'relative_time_description' ), 'location' : f "POINT({location_lng} {location_lat})" # 緯度経度を GEOGRAPHY 型の POINT 形式で保存 }) return reviews def save_to_bigquery (self, reviews): # レビューデータを Pandas DataFrame に変換 df = pd.DataFrame(reviews) # BigQuery のテーブル参照を作成 table_ref = self.bq_client.dataset(self.dataset_id).table(self.table_id) # BigQuery へのデータ書き込み設定 job_config = bigquery.LoadJobConfig( schema=[ bigquery.SchemaField( "spot_name" , "STRING" ), bigquery.SchemaField( "author" , "STRING" ), bigquery.SchemaField( "rating" , "FLOAT" ), bigquery.SchemaField( "text" , "STRING" ), bigquery.SchemaField( "time" , "TIMESTAMP" ), bigquery.SchemaField( "relative_time_description" , "STRING" ), bigquery.SchemaField( "location" , "GEOGRAPHY" ) ], write_disposition= "WRITE_TRUNCATE" # テーブルを上書き ) # DataFrame を BigQuery にアップロード job = self.bq_client.load_table_from_dataframe(df, table_ref, job_config=job_config) job.result() # ジョブの完了を待つ print (f "Loaded {len(reviews)} reviews into {self.dataset_id}.{self.table_id}" ) if __name__ == "__main__" : # 設定情報 API_KEY = '上記で取得した API キー' # Google Maps API キー PROJECT_ID = 'project_id' # Google Cloud プロジェクト ID DATASET_ID = 'google_maps_review_analysis' # BigQuery のデータセット ID TABLE_ID = 'reviews' # BigQuery のテーブル ID # 検索パラメータ KEYWORD = "ラーメン" # 検索キーワード LOCATION = ( 35.68093847942352 , 139.76703854373777 ) # 検索の中心位置（緯度、経度） RADIUS = 1000 # 検索範囲（メートル） # GoogleMapsReviewFetcher のインスタンスを作成 fetcher = GoogleMapsReviewFetcher(API_KEY, PROJECT_ID, DATASET_ID, TABLE_ID) # レビューを取得 reviews = fetcher.fetch_reviews(KEYWORD, LOCATION, RADIUS) # 取得したレビューを BigQuery に保存 fetcher.save_to_bigquery(reviews) BigQuery への格納結果は以下のとおりです。 クチコミデータの格納結果（BigQuery） クチコミ数の制限と緩和策 「Places API」は一つの場所で最大5件しかクチコミを取得できない制約があります。その場所のオーナーであれば、「Business Profile API」に登録することで、すべてのクチコミを取得できるとされていますが、当社では未検証です。 詳細は以下を参照してください。 参考 : すべてのクチコミの一覧を取得する 料金 API リクエストには料金が発生するため注意が必要です。筆者のサンプルコードでは、1件のクチコミで「0.87円」となりました。詳細な料金体系については以下を参照してください。 参考 : Places API の使用量と請求額 感情分析とデータパイプライン Dataform を使用して BigQuery 上にデータパイプラインを構築し、感情分析を行います。 Dataform の利点 Dataform は、BigQuery を使用したデータ分析や機械学習のワークフローを効率化するツールです。以下の点で特に有用です。 BigQuery の多様な分析機能をフル活用 BigQuery ML：従来の機械学習アルゴリズムを使用可能 リモート関数：外部サービスとの連携が容易 オブジェクトテーブル：構造化されていないデータの処理が可能 生成 AI：最新の AI 技術を BigQuery 内で直接利用可能 複雑な処理の簡素化 長いデータパイプラインや複雑な処理フローを効率的に管理 SQL ベースの操作で、複雑な処理を直感的に記述可能 コスト削減 実装コストの低減：複雑な処理を簡単に構築可能 運用保守コストの削減：一元管理による保守性の向上 開発から本番環境への円滑な移行 PoC（概念実証）段階で作成したクエリを、本番環境のパイプラインに容易に統合可能 これらの利点により、Dataform は特に複雑なデータ分析プロジェクトや中〜大規模なデータパイプラインの構築に適しています。データ分析の効率と品質を向上させたい場合に、強力なツールとなります。 詳細は弊社ブログ記事をご参照ください。 blog.g-gen.co.jp Dataform を使った感情分析のパイプライン定義例 以下は、Dataform を使った感情分析のパイプライン定義例です。 -- Dataform 設定：結果を保存するテーブルの定義 config { type : " table " , schema: " google_maps_review_analysis " , name: " reviews_sentiment " , description: " クチコミの感情分析結果 " } -- 感情分析を実行し、結果を整形 WITH analyzed_data AS ( SELECT r.*, -- 元のクチコミデータのすべての列を選択 t.ml_understand_text_result, -- 感情分析の生の結果を含む JSON_EXTRACT_ARRAY(t.ml_understand_text_result, ' $.sentences ' ) AS sentences, -- 感情分析結果の sentences 配列を抽出 -- JSON 形式の結果から感情スコアを抽出（-1から1の範囲、負の値はネガティブ、正の値はポジティブ） CAST (JSON_EXTRACT_SCALAR(t.ml_understand_text_result, ' $.document_sentiment.score ' ) AS FLOAT64) AS document_sentiment_score, -- JSON 形式の結果から感情の強さを抽出（0以上の値、大きいほど感情が強い） CAST (JSON_EXTRACT_SCALAR(t.ml_understand_text_result, ' $.document_sentiment.magnitude ' ) AS FLOAT64) AS document_sentiment_magnitude FROM ${ref( " reviews " )} AS r -- reviews テーブルを参照 JOIN ( -- BigQuery の自然言語処理モデルを使用して感情分析を実行 SELECT text_content, -- テキストデータ ml_understand_text_result -- 感情分析の生の結果 FROM ML.UNDERSTAND_TEXT( MODEL `project_id.google_maps_review_analysis.nlp`, -- 使用する自然言語処理モデル ( SELECT text AS text_content FROM ${ref( " reviews " )}), -- 分析対象のテキスト STRUCT( ' ANALYZE_SENTIMENT ' AS nlu_option) -- 感情分析オプションを指定 ) ) AS t ON r.text = t.text_content -- テキストを基準に JOIN ), -- 最終的な結果セットを選択し、中間テーブルに保存 intermediate_results AS ( SELECT r.spot_name, -- スポット名 r.author, -- 著者 r.rating, -- 評価 r.text, -- クチコミテキスト r.time, -- クチコミ投稿時間 r.relative_time_description, -- クチコミ投稿の相対時間 r.location, -- クチコミの位置情報 r.text AS `original_input`, -- 元の入力テキスト r.document_sentiment_score, -- ドキュメント全体の感情スコア r.document_sentiment_magnitude, -- ドキュメント全体の感情の強さ -- 各文のテキスト内容 JSON_EXTRACT_SCALAR(sentence, ' $.text.content ' ) AS sentence_text, -- 各文の感情スコア CAST (JSON_EXTRACT_SCALAR(sentence, ' $.sentiment.score ' ) AS FLOAT64) AS sentence_sentiment_score, -- 各文の感情の強さ CAST (JSON_EXTRACT_SCALAR(sentence, ' $.sentiment.magnitude ' ) AS FLOAT64) AS sentence_sentiment_magnitude FROM analyzed_data AS r, UNNEST(r.sentences) AS sentence -- sentences 配列を展開 ) -- 中間テーブルから最終的な結果セットを選択 SELECT * FROM intermediate_results Dataform ジョブの出力結果は以下のとおりです。 Dataform ジョブの出力結果 感情分析の結果解釈 このクエリでは、BigQuery の機械学習モデル ML.UNDERSTAND_TEXT を使用して感情分析を行っています。結果は以下の2つの値として返されます。 sentiment_score ：-1 から 1 のスコアで、感情の肯定的/否定的な度合いを表します。 sentiment_magnitude ：感情の強さを表します。 これらの値を組み合わせることで、クチコミの感情的な特徴を分析することができます。 ML.GENERATE_TEXT（Gemini 1.5 Pro） 関数を使用した高度な分析 BigQuery の ML.GENERATE_TEXT 関数は、テキスト生成や高度なマルチモーダルタスクを実行するための強力なツールです。詳細なセットアップ方法については以下をご参照ください。 参考 : ML.GENERATE_TEXT 関数を使用してテキストを生成する 以下の記事では BigQuery ML の基本を解説していますので、ご参照ください。 blog.g-gen.co.jp ユースケースに応じた独自の評価観点によるクチコミの定量化 以下は、クチコミから「味」「提供スピード」「価格」「店の雰囲気」「その他」を三段階評価で抽出するクエリです。 config { type : " table " , schema: " google_maps_review_analysis " , name: " reviews_generate_text_analysis " } -- クチコミデータを準備し、AI モデルに渡すためのプロンプトを作成する WITH review_data AS ( SELECT spot_name, -- 店名 author, -- クチコミの投稿者 text, -- クチコミの内容 rating, -- 店の評価 CONCAT ( ' 以下のラーメン店「 ' , spot_name, ' 」のクチコミに基づいて、次の情報を JSON 形式で抽出してください： ' , ' 味（良い、普通、悪い、不明）、提供スピード（速い、普通、遅い、不明）、価格（高い、普通、安い、不明）、店の雰囲気（良い、普通、悪い、不明）、その他（良い、普通、悪い、不明）。 ' , ' それぞれの観点が総合評価（ ' , rating, ' ）にどのように関連しているかも考慮してください。 ' , ' クチコミ: " ' , text, ' " ' , ' フォーマットは{"味": "良い", "提供スピード": "速い", "価格": "高い", "店の雰囲気": "不明", "その他": "良い"}。 ' ) AS prompt -- AIモデルに渡すためのプロンプト FROM ${ref( " reviews " )} ) -- AI モデルを使用して、プロンプトに基づいて情報を抽出する SELECT r.spot_name, -- 店名 r.author, -- クチコミの投稿者 r.text, -- クチコミの内容 r.rating, -- 店の評価 JSON_VALUE( REPLACE (t.ml_generate_text_llm_result, ' ```json ' , '' ), ' $.味 ' ) AS flavor_text, -- 味に関する情報 JSON_VALUE( REPLACE (t.ml_generate_text_llm_result, ' ```json ' , '' ), ' $.提供スピード ' ) AS service_speed_text, -- 提供スピードに関する情報 JSON_VALUE( REPLACE (t.ml_generate_text_llm_result, ' ```json ' , '' ), ' $.価格 ' ) AS price_text, -- 価格に関する情報 JSON_VALUE( REPLACE (t.ml_generate_text_llm_result, ' ```json ' , '' ), ' $.店の雰囲気 ' ) AS atmosphere_text, -- 店の雰囲気に関する情報 JSON_VALUE( REPLACE (t.ml_generate_text_llm_result, ' ```json ' , '' ), ' $.その他 ' ) AS other_text, -- その他に関する情報 -- 各観点に対するスコアを計算する CASE JSON_VALUE( REPLACE (t.ml_generate_text_llm_result, ' ```json ' , '' ), ' $.味 ' ) WHEN ' 良い ' THEN 3 WHEN ' 普通 ' THEN 2 WHEN ' 悪い ' THEN 1 ELSE NULL END AS flavor_score, -- 味のスコア CASE JSON_VALUE( REPLACE (t.ml_generate_text_llm_result, ' ```json ' , '' ), ' $.提供スピード ' ) WHEN ' 速い ' THEN 3 WHEN ' 普通 ' THEN 2 WHEN ' 遅い ' THEN 1 ELSE NULL END AS service_speed_score, -- 提供スピードのスコア CASE JSON_VALUE( REPLACE (t.ml_generate_text_llm_result, ' ```json ' , '' ), ' $.価格 ' ) WHEN ' 高い ' THEN 1 WHEN ' 普通 ' THEN 2 WHEN ' 安い ' THEN 3 ELSE NULL END AS price_score, -- 価格のスコア CASE JSON_VALUE( REPLACE (t.ml_generate_text_llm_result, ' ```json ' , '' ), ' $.店の雰囲気 ' ) WHEN ' 良い ' THEN 3 WHEN ' 普通 ' THEN 2 WHEN ' 悪い ' THEN 1 ELSE NULL END AS atmosphere_score, -- 店の雰囲気のスコア CASE JSON_VALUE( REPLACE (t.ml_generate_text_llm_result, ' ```json ' , '' ), ' $.その他 ' ) WHEN ' 良い ' THEN 3 WHEN ' 普通 ' THEN 2 WHEN ' 悪い ' THEN 1 ELSE NULL END AS other_score -- その他のスコア FROM review_data r LEFT JOIN ML.GENERATE_TEXT( MODEL `project_id.google_maps_review_analysis.gemini_1_5_pro`, -- 使用するAIモデル ( SELECT prompt FROM review_data), -- プロンプトをAIモデルに渡す STRUCT( 0.1 AS temperature, -- 出力のランダム性を制御する 1000 AS max_output_tokens, -- 出力の最大トークン数 0.1 AS top_p, -- ニュークリアスサンプリングのパラメータ 10 AS top_k, -- トップKフィルタリングで保持する最も高い確率の語彙トークン数 TRUE AS flatten_json_output -- JSON出力をフラットにする ) ) AS t ON r.prompt = t.prompt -- プロンプトを基にAIモデルからの生成結果を結合 生成結果は以下のとおりです。 独自の観点でクチコミを評価 クチコミに対する自動返信文作成 クチコミに対する店長からの返信文を自動生成するようにします。 config { type : " table " , schema: " google_maps_review_analysis " , name: " reviews_manager_responses " } -- Step 1: クチコミデータを準備し、AI モデルに渡すためのプロンプトを作成する WITH review_data AS ( SELECT spot_name, -- 店名 author, -- クチコミの投稿者 text, -- クチコミの内容 rating, -- 店の評価 time, -- クチコミの投稿時間 relative_time_description, -- クチコミの相対的な時間 CONCAT ( ' 以下のラーメン店「 ' , spot_name, ' 」のクチコミに対して、店長からの返信を作成してください。クチコミの内容に応じて感謝や改善点への対策などを含めてください。 ' , ' また、Google Map における店の評価（ ' , rating, ' ）を踏まえて、お客様の期待値に応えているかどうかも考慮してください。 ' , ' クチコミ: " ' , text, ' " ' , ' 返信は、以下のフォーマットでお願いします。 ' , ' {"response": " ' , author, ' 様 ' , ' \\n ' , ' 店長からの返信メッセージ"} ' ) AS prompt -- AIモデルに渡すためのプロンプト FROM ${ref( " reviews " )} ) -- Step 2: AI モデルを使用して、プロンプトに基づいて店長からの返信を生成する SELECT r.spot_name, -- 店名 r.author, -- クチコミの投稿者 r.text, -- クチコミの内容 r.rating, -- 店の評価 r.time, -- クチコミの投稿時間 r.relative_time_description, -- クチコミの相対的な時間 JSON_VALUE( REPLACE (t.ml_generate_text_llm_result, ' ```json ' , '' ), ' $.response ' ) AS response -- 生成された返信 FROM review_data r LEFT JOIN ML.GENERATE_TEXT( MODEL `project_id.google_maps_review_analysis.gemini_1_5_pro`, -- 使用するAIモデル ( SELECT prompt FROM review_data), -- プロンプトをAIモデルに渡す STRUCT( 0.3 AS temperature, -- 出力のランダム性を制御する 500 AS max_output_tokens, -- 出力の最大トークン数 0.9 AS top_p, -- ニュークリアスサンプリングのパラメータ 10 AS top_k, -- トップKフィルタリングで保持する最も高い確率の語彙トークン数 TRUE AS flatten_json_output -- JSON出力をフラットにする ) ) AS t ON r.prompt = t.prompt -- プロンプトを基にAIモデルからの返信を結合 生成結果は以下のとおりです。クチコミの内容に対して、一つずつ丁寧に返信しています。 クチコミに対する自動返信文 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-gen の荒井です。当記事では Google Workspace のアプリケーションのみ使用してお問い合わせシステムを作成する方法をご紹介します。 はじめに ご紹介すること 記事の構成 問い合わせ業務 業務フロー フロー1 : お問い合わせ受付 フロー2 : 担当者割り当て フロー3 : ラベル付与 フロー4 : 回答の送信 フロー5 : 返信の受付 フロー6 : クローズ 次の記事 はじめに ご紹介すること 当記事では、前回までの記事で開発した問い合わせ対応システムを実際に使用する業務フローと手順を解説します。 記事の構成 問い合わせ対応システムの開発方法は、以下の通り、連載記事としてご紹介します。記事を順に確認することで、問い合わせ対応システムが完成します。 No タイトルとリンク 1 Google Workspace で問い合わせ対応システムを作成する方法 #1 (システム概要) 2 Google Workspace で問い合わせ対応システムを作成する方法 #2 (Google グループ設定) 3 Google Workspace で問い合わせ対応システムを作成する方法 #3 (Google フォーム設定) 4 Google Workspace で問い合わせ対応システムを作成する方法 #4 (Google App Script 設定) 5 ※ 当記事 Google Workspace で問い合わせ対応システムを作成する方法 #5 (業務フロー解説) 6 ※ 準備中 Google Workspace で問い合わせ対応システムを作成する方法 #6 (機能拡張案) 問い合わせ業務 本システムを使用したお問い合わせ業務フローを図示すると、以下のようになります。 業務フロー フロー1 : お問い合わせ受付 お客様からお問い合わせがあると、Google グループの機能で、グループ内のメンバーにメールが配信されます。 メンバーはそのメールを確認しだい、対応を開始します。 フロー2 : 担当者割り当て Google グループ 画面にアクセスし、お問い合わせ用グループを選択し、表示されるスレッド一覧から対象のスレッドを開きます。 次に、担当者の割り当てを行います。割り当てられたメンバーには、メールで通知されます。 参考 : 会話を引き受ける、割り当てる - Google グループ ヘルプ フロー3 : ラベル付与 ケースの対応状況がわかりやすくなるよう、スレッドにラベルを付与します。ラベルは事前に作成しておく必要があります。 ラベルを付与する際は、ラベルを選択した後に [申請] ボタンをクリックする必要があります。申請ボタンの押下は忘れがちですので、注意しましょう。 参考 : グループと投稿を見つけやすくする - Google グループ ヘルプ フロー4 : 回答の送信 回答の文章を作成します。 作成する際、スレッド最下部の「全員に返信」ボタンから回答メールを作成して、メッセージを投稿します。 このとき、件名を変更してしまうと Google グループ内のスレッド（問い合わせ履歴）がひとまとまりにならず、別スレッドとして扱われてしまう場合があるため、件名は編集しないようにします。 参考 : メッセージを作成する、メッセージに返信する - Google グループ ヘルプ フロー5 : 返信の受付 送信した回答にお客様が返信を行った場合、その返信は Google グループ（もしくはユーザーの Gmail）が受信します。 内容を確認し、再度対応が必要な場合 フロー4 へ戻ります。クローズしても良い場合 フロー6 へ進みます。 フロー6 : クローズ お問い合わせ内容が解決してクローズできる状態となったら、フロー4のメール送信と同様の手順で、お客様へクローズする旨のメールを送信してお問い合わせを終了します。 最後に、対応状況がわかるよう、Google グループのスレッドでラベルの変更を行います。 参考 : グループと投稿を見つけやすくする - Google グループ ヘルプ 次の記事 [準備中] Google Workspace で問い合わせ対応システムを作成する方法 #6 (機能拡張案) 荒井 雄基 (記事一覧) クラウドソリューション部 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。 Google Cloud 認定資格 7冠 現在は Google Workspace を中心に企業の DX 推進をサポート。 最近頑張っていることは、子どもがハマっている戦隊モノの踊りを踊れるようになること。

G-gen の西島です。当記事では、Google Cloud（旧称 GCP）が提供するデータ ウェアハウスである BigQuery で、誤って削除したデータセットを復元する方法をご紹介します。 BigQuery データセットの復元方法 UNDROP SCHEMA の使用（データセットを丸ごとリストア） 概要 必要な権限 SQL でのリストア API でのリストア タイムトラベルの使用（テーブルを1つずつリストア） 概要 必要な権限 リストア対象のテーブルをリストアップ データセットを作成 テーブルのリストア バックアップによる対策 BigQuery データセットの復元方法 削除された BigQuery データセットの復元方法には、以下の2種類があります。 UNDROP SCHEMA の使用 （データセットを丸ごとリストア） タイムトラベルの使用 （テーブルを1つずつリストア） データセットごと復元する場合は、原則として前者の UNDROP SCHEMA を使用します。テーブルごとに復旧したい場合や、制限事項に抵触している場合は、後者のタイムトラベルからの個別復旧を使用します。 UNDROP SCHEMA の使用（データセットを丸ごとリストア） 概要 こちらの手法は、データセットをまるごと復元する方法です。ただし、復元できるのは タイムトラベル期間内に削除されたデータセットのみ です。 また、以下のドキュメントの「制限事項」を読み、注意点について確認してください。 参考 : 削除されたデータセットを復元する 必要な権限 こちらの手順を実施するには、以下の権限が必要です。 プロジェクトに対する bigquery.datasets.create データセットに対する bigquery.datasets.get これらの権限は、以下の事前定義ロールに含まれています。以下のロールを、プロジェクトレベルで操作者の Google アカウント / グループに付与することで、当作業を行うことができるようになります。 BigQuery ユーザー（ roles/bigquery.user ） SQL でのリストア BigQuery コンソール等で以下の SQL を実行することで、データセットを中身のテーブルごとリストアできます。 -- DATASET_ID は、削除を取り消すデータセットに置き換える UNDROP SCHEMA `DATASET_ID`; DATASET_ID は、ご自身の環境にあわせて変更してください。 参考 : UNDROP SCHEMA ステートメント API でのリストア BigQuery API の datasets.undelete メソッドを使用します。以下は、cURL コマンドで API を直接呼び出す例です。 curl -X POST \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ https://bigquery.googleapis.com/bigquery/v2/projects/ { projectId } /datasets/ { datasetId } :undelete コマンドライン上の {projectId} や {datasetId} はご自身の環境にあわせて変更してください。 参考 : Method: datasets.undelete  |  BigQuery  |  Google Cloud Documentation タイムトラベルの使用（テーブルを1つずつリストア） 概要 こちらの手法では、BigQuery のシステムビューである INFORMATION_SCHEMA の TABLE_STORAGE_TIMELINE ビューを確認することで復元対象のテーブルをリストアップしたあと、 タイムトラベル 機能を使って、テーブルを1つ1つ復元します。 タイムトラベル機能では、削除されたり変更されたデータにアクセスすることができます。デフォルトでは過去7日分のデータが保管されます。 参考 : INFORMATION_SCHEMA の概要 参考 : タイムトラベルとフェイルセーフによるデータの保持 必要な権限 こちらの手順を実施するには、以下の権限が必要です。 プロジェクトに対する bigquery.tables.get プロジェクトに対する bigquery.tables.list プロジェクトに対する bigquery.datasets.create これらの権限は、以下の事前定義ロールに含まれています。これらのロールを、プロジェクトレベルで操作者の Google アカウント / グループに付与する必要があります。 BigQuery データ閲覧者（ roles/bigquery.dataViewer ） BigQuery データ編集者（ roles/bigquery.dataEditor ） BigQuery ジョブユーザー （ roles/bigquery.jobUser ） リストア対象のテーブルをリストアップ はじめに、削除されたデータセットに含まれていたテーブルのリストアップを行います。 データセットを削除した場合、Cloud Audit Logs には google.cloud.bigquery.v2.DatasetService.DeleteDataset というメソッドのログにデータセット ID が記録されますが、そのデータセットに含まれていた テーブルの名称は記録されません 。 参考 : BigQuery audit logs overview  |  Google Cloud Documentation つまり、監査ログから削除されたテーブルの一覧を取得することはできません。そこで INFORMATION_SCHEMA の TABLE_STORAGE_TIMELINE ビューを確認します。このビューには過去のある時点のストレージ使用状況が記録されており、そこから間接的に、その時点で存在していたテーブルの名前を確認することができます。 削除されたデータセットのテーブル名を特定する SQL は、以下のとおりです。 SELECT DISTINCT project_id, table_schema AS dataset, table_name, deleted FROM `region-asia-northeast1`.INFORMATION_SCHEMA.TABLE_STORAGE_TIMELINE WHERE project_id = ' xxxxx ' AND deleted = true AND timestamp >= ' 2024-03-21 ' ORDER BY 1 , 2 , 3 , 4 FROM 句の region-asia-northeast1 の部分は、データセットの存在したリージョンを指定してください。US マルチリージョンであれば region-us 、 東京リージョンであれば region-asia-northeast1 です。 WHERE 句の timestamp は、データセットを削除してしまった日付・時刻を含むよう、範囲を指定してください。 参考 : TABLE_STORAGE ビュー  |  BigQuery  |  Google Cloud Documentation データセットを作成 削除されたデータセットと同じ名前、同じリージョンのデータセットを新規作成します。 データセットは、BigQuery コンソール画面や bq コマンドで作成できます。 参考 : データセットの作成  |  BigQuery  |  Google Cloud Documentation テーブルのリストア 新規作成したデータセット内に、テーブルをリストアします。 テーブルをリストアする bq コマンドは、以下のとおりです。 # UNIX タイムスタンプ（ミリ秒単位）の取得 date -d '2024-06-27 17:00:00' +%s000 # テーブルの復元 bq cp dataset.table1@1719471634000 dataset.table1 上記の date コマンドは、人間にわかりやすい日付・時刻の文字列を、UNIX タイムスタンプ形式で表示するものです。 その次の bq コマンドは、UNIX タイムスタンプ で 1719471634000 （2024-06-27 10:00:00 UTC+0900）の時点の dataset.table1 という BigQuery テーブルを復元するものです。 コマンドライン上の Unix タイムスタンプとテーブル名は、ご自身の環境にあわせて変更してください。 バックアップによる対策 本記事では、 誤って削除したデータセットに含まれるテーブル復元方法を紹介しましたが、紹介したどちらの方法でも、タイムトラベル期間内でしか復元することができません。設定可能な最長のタイムトラベル期間は7日間です。 7日間以上の RPO が求められる場合、BigQueryのスナップショット機能や Cloud Storage へのエクスポート、BigQuery Data Transfer Service 等によるバックアップの実施を検討することも必要です。 スナップショット機能については、以下の記事もご参照ください。 blog.g-gen.co.jp 西島 昌太 (記事一覧) カスタマーサクセス課 データエンジニア 2023年4月に新卒入社。 元はフロントエンド開発を主戦場に、現在はデータエンジニアリングを勉強中。何でも屋さんを目指して、日々邁進。 休日は大体プログラムを書いてる人

G-gen の武井です。当記事では GitHub Actions を使って Docker イメージをビルド&プッシュして Cloud Run Jobs を更新するパイプランについて説明します。 GitHub Actions 概要 ワークフロー 構成 ワークフローの概要 ソースコード 概要 dev.yaml 処理内容 ファイル定義 build-and-push.yaml 処理内容 ファイル定義 インフラ構成 Workload Identity Artifact Registry 動作確認 条件 main ブランチへのマージとワークフローの起動 後続のワークフローの起動 Docker イメージのビルドとプッシュ Cloud Run Jobs の更新 関連記事 GitHub Actions 概要 GitHub Actions とは、ソースコード管理ツールである GitHub に包含される機能の一つで、リポジトリで管理されるソースコードをもとに CI/CD (継続的インティグレーション / 継続的デリバリー) を実現します。 参考： GitHub Actions の概要 ワークフロー GitHub Actions で自動化したい処理とその内容・条件を定義したものを ワークフロー と言います。 定義ファイルは YAML 形式 で記述して .github/workflows ディレクトリ に格納すれば利用可能です。 参考： ワークフローについて 構成 当記事で解説するパイプラインと環境構成は下図のとおりです。 Artifact Registry と Cloud Run Jobs は異なるプロジェクトで管理されるため、 プロジェクトごとに Workload Identity を設定して GitHub Actions と連携 します。 # プロジェクト 説明 1 demo-app-common-repo Artifact Registry でアプリが使用するイメージを一元管理 2 sand1-demo-app-dev Cloud Run Jobs でアプリを実行 3 sand2-demo-app-dev Cloud Run Jobs でアプリを実行 ワークフローの概要 今回ワークフローで定義した処理の概要は以下のとおりです。(詳細は後述) main ブランチへのマージをトリガーにワークフローが起動 指定のパス (アプリのソースコードが格納されたパス) の変更有無を確認 指定のパスに変更があった (アプリに更新があった) 場合、Docker イメージをビルドして Artifact Registry にプッシュ Cloud Run Jobs のイメージを更新する ソースコード 概要 ソースコードは以下の形で構成されます。 .github/workflows ディレクトリにはワークフローの定義ファイル、 cloud_run_jobs_code ディレクトリにはアプリごとのソースコードを格納します。 (アプリ名と Cloud Run Jobs のジョブ名は統一しています) # アプリのソースコードの詳細は割愛 . ├── .github │ └── workflows │ ├── build-and-push.yaml │ ├── dev-cd.yaml │ └── release.yaml ├── cloud_run_jobs_code │ ├── demo-app-1 │ │ ├── Dockerfile │ │ ├── main.py │ │ ├── poetry.lock │ │ ├── poetry.toml │ │ └── pyproject.toml │ └── demo-app-2 │ ├── Dockerfile │ ├── main.py │ ├── poetry.lock │ ├── poetry.toml │ └── pyproject.toml └── README.md dev.yaml 処理内容 このワークフローでは、以下のモジュールを使用してアプリのソースコードが格納されたパスを指定し、それらの変更有無を確認します。 参考： dorny/paths-filter 指定したパスに格納されるソースコード (アプリ) に変更があった場合は build-and-push.yaml で処理を継続しますが、アプリに変更がない場合、ワークフローはここで終了します。 その他詳細は以下のとおりです。 # 行数 説明 1 3〜7行目 main ブランチへのマージをトリガーに指定 2 9〜11行目 ワークフローの権限定義 3 13〜29行目 パスの指定、ならびに指定したパスの変更有無を確認 4 31〜37行目 変更があれば後続処理にアプリ名 (demo-app-1) を appName として渡す 5 39〜45行目 変更があれば後続処理にアプリ名 (demo-app-2) を appName として渡す ファイル定義 name : Deploy to GCP development env on : push : branches : - main workflow_dispatch : permissions : id-token : write contents : read jobs : check-paths : runs-on : ubuntu-latest outputs : demo-app-1-changed : ${{ steps.filter.outputs.demo-app-1 }} demo-app-2-changed : ${{ steps.filter.outputs.demo-app-2 }} steps : - uses : actions/checkout@v4 - uses : dorny/paths-filter@v3 id : filter with : list-files : shell filters : | demo-app-1 : - 'cloud_run_jobs_code/demo-app-1/**' demo-app-2 : - 'cloud_run_jobs_code/demo-app-2/**' demo-app-1 : needs : check-paths if : >- needs.check-paths.outputs.demo-app-1-changed == 'true' uses : ./.github/workflows/build-and-push.yaml with : appName : 'demo-app-1' demo-app-2 : needs : check-paths if : >- needs.check-paths.outputs.demo-app-2-changed == 'true' uses : ./.github/workflows/build-and-push.yaml with : appName : 'demo-app-2' build-and-push.yaml 処理内容 このワークフローは dev.yaml から appName が渡された (アプリに変更があった) 場合にのみ起動します。 そして、以下のモジュールを使用して各プロジェクトと Workload Identity で連携してタグ付き Docker イメージのビルド & プッシュと Cloud Run Jobs の更新を行います。 参考： google-github-actions/auth 参考： google-github-actions/deploy-cloudrun その他詳細は以下のとおりです。 # 行数 説明 1 3〜8行目 appName のインプットをトリガーに指定 2 10〜26行目 ランナーのセットアップ 4 28〜30行目 環境変数の定義 4 32〜58行目 demo-app-common-repo との WI 連携、Docker イメージのビルド&プッシュ 5 60〜71行目 sand1-demo-app-dev との WI 連携、Cloud Run Jobs の更新 5 60〜71行目 sand2-demo-app-dev との WI 連携、Cloud Run Jobs の更新 ファイル定義 name : Build and push to GCP development env. on : workflow_call : inputs : appName : required : true type : string jobs : sdk : runs-on : ubuntu-latest steps : - name : 'Set up Cloud SDK' uses : 'google-github-actions/setup-gcloud@v2' with : version : '>= 363.0.0' build-and-push : runs-on : ubuntu-latest timeout-minutes : 300 needs : [ sdk ] permissions : id-token : write contents : read env : REPO : 'demo-app-common-repo-dev' GAR : 'asia-northeast1-docker.pkg.dev/demo-app-common-repo' steps : - uses : actions/checkout@v4 - uses : google-github-actions/auth@v2 with : project_id : demo-app-common-repo workload_identity_provider : 'projects/1111111111/locations/global/workloadIdentityPools/demo-app-github-actions/providers/demo-app-github-actions' service_account : 'github@demo-app-common-repo.iam.gserviceaccount.com' - name : 'Set up app dir name' run : echo "APP_DIR=cloud_run_jobs_code/${{ inputs.appName }}" >> $GITHUB_ENV - name : 'Set up short sha' run : echo "SHORT_SHA=$(echo ${{ github.sha }} | cut -c1-8)" >> "$GITHUB_ENV" - name : 'Set up app name variable' run : echo "IMAGE_NAME=${{ inputs.appName }}" >> "$GITHUB_ENV" - name : Build and Push image to Google Cloud Artifact Registry run : | gcloud auth configure-docker asia-northeast1-docker.pkg.dev --quiet docker build --platform linux/amd64 -t "${REPO}/${IMAGE_NAME}" ${APP_DIR} docker tag "${REPO}/${IMAGE_NAME}:latest" "${GAR}/${REPO}/${IMAGE_NAME}:latest" docker push "${GAR}/${REPO}/${IMAGE_NAME}:latest" docker tag "${REPO}/${IMAGE_NAME}:latest" "${GAR}/${REPO}/${IMAGE_NAME}:${SHORT_SHA}" docker push "${GAR}/${REPO}/${IMAGE_NAME}:${SHORT_SHA}" - uses : 'google-github-actions/auth@v2' with : project_id : sand1-demo-app-dev workload_identity_provider : 'projects/2222222222/locations/global/workloadIdentityPools/demo-app-github-actions/providers/demo-app-github-actions' service_account : 'github@sand1-demo-app-dev.iam.gserviceaccount.com' - name : Deploy to Cloud Run (sand1-demo-app-dev) uses : 'google-github-actions/deploy-cloudrun@v2' with : job : ${{ env.IMAGE_NAME }} image : ${{ env.GAR }}/${{ env.REPO }}/${{ env.IMAGE_NAME}}:latest region : 'asia-northeast1' - uses : 'google-github-actions/auth@v2' with : project_id : sand2-demo-app-dev workload_identity_provider : 'projects/3333333333/locations/global/workloadIdentityPools/demo-app-github-actions/providers/demo-app-github-actions' service_account : 'github@sand2-demo-app-dev.iam.gserviceaccount.com' - name : Deploy to Cloud Run (sand2-demo-app-dev) uses : 'google-github-actions/deploy-cloudrun@v2' with : job : ${{ env.IMAGE_NAME }} image : ${{ env.GAR }}/${{ env.REPO }}/${{ env.IMAGE_NAME}}:latest region : 'asia-northeast1' インフラ構成 Workload Identity 今回の構成では、GitHub Actions との連携に Workload Identity を用いています。 設定方法の説明は割愛しますが、以下の記事の Workload Identiry 連携の設定 にならい同様の設定をします。 blog.g-gen.co.jp その際、Workload Identity に紐づけるサービスアカウントには以下の権限を付与します。 # プロジェクト 付与する権限 1 demo-app-common-repo Artifact Registry 書き込み 2 sand1-demo-app-dev Cloud Run デベロッパー 3 sand2-demo-app-dev Cloud Run デベロッパー 参考： Artifact Registry の事前定義ロール 参考： Cloud Run の事前定義ロール Artifact Registry 今回の構成では、Artifact Registry と Cloud Run Jobs が異なるプロジェクトに配置されています。 他のプロジェクトの Docker イメージをデプロイする場合、以下にならい Cloud Run サービス エージェント に対して権限を付与します。 参考： 他の Google Cloud プロジェクトからイメージをデプロイする サービスエージェントについては以下の記事で説明しています。 blog.g-gen.co.jp 動作確認 条件 demo-app-1 と demo-app-2 のソースコードを編集して main ブランチにマージした際の動作を確認します。 main ブランチへのマージとワークフローの起動 main ブランチにマージをするとワークフロー ( dev.yaml ) が起動します。 demo-app-1 と demo-app-2 を更新したため、 check-paths ジョブで変更を検知して後続の build-and-push.yaml にアプリ名を渡しています。 main ブランチにマージ パスの変更有無を確認するジョブ 2つのパスで変更を確認 後続のワークフローの起動 アプリ名が渡され、次のワークフロー ( build-and-puysh.yaml ) が起動します。 今回は2つのアプリが更新されたので、それぞれのアプリイメージをビルド&プッシュし、各プロジェクトの Cloud Run Jobs を更新するフローが走ります。 Docker イメージのビルドとプッシュ demo-app-1 と demo-app-2 の Docker イメージ (タグ付き) がビルドされリポジトリにプッシュされました。 demo-app-1 の Docker イメージ (タグ付き) Artifact Registry demo-app-2 の Docker イメージ (タグ付き) Aritifact Registory Cloud Run Jobs の更新 Docker イメージがリポジトリにプッシュされると、各プロジェクトで稼働する Cloud Run Jobs が gcloud run jobs deploy コマンドで最新のタグ付きイメージに更新されました。 両プロジェクトの Cloud Run Jobs (demo-app-1) が更新 両プロジェクトの Cloud Run Jobs (demo-app-2) が更新 Cloud Logging にも google.cloud.run.v1.Jobs.ReplaceJob メソッドにより Cloud Run Jobs が更新された旨が記録されていました。 Cloud Logging からも確認可能 関連記事 blog.g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2025 選出。 趣味はロードレースやサッカー観戦、あとはゴルフと筋トレ。 Follow @ggenyutakei

G-gen の杉村です。VMware 資産を Google Cloud へリフトするにあたり重要な選択肢となる、Google Cloud VMware Engine（GCVE）を解説します。 概要 Google Cloud VMware Engine（GCVE）とは VMware ライセンス メリット 基本的な構成 ノード数と PoC 他社の類似サービス 料金 GCVE ノード サードパーティライセンス 非機能要件 セキュリティ 責任共有モデル データの暗号化 ネットワーク 可用性 拡張性 VMware コンポーネント 概要 ESXi vCenter vSAN NSX HCX ネットワークの概要 概要図 オンプレミスとの接続 Google Cloud のネットワーク GCVE のネットワーク GCVE のノード ネットワークの詳細 DNS 構成 インターネットとの通信 ネットワークポリシー 外部アクセスルール VM の移行 代表的な移行手法 HCX を使った移行 運用・保守 バックアップ 標準のバックアップ Backup and DR Service サードパーティによるバックアップ モニタリング メンテナンス 物理的なメンテナンス ソフトウェア的なメンテナンス 監査ログ 概要 Google Cloud VMware Engine（GCVE）とは Google Cloud VMware Engine （以下、GCVE）とは、Google Cloud（旧称 GCP）で VMware プラットフォームを運用できるマネージドサービスです。 VMware プラットフォームが稼働するための物理マシンは Google Cloud によって提供され、管理されます。私たちユーザーは、物理レイヤをほとんど意識することなく、VMware 関連サービスを利用することができます。障害が発生したハードウェアは自動的に交換され、管理プレーンの運用は Google によって行われます。 GCVE 環境は物理的には Google Cloud のデータセンターに存在しています。そのため GCVE の VM と、BigQuery や AI/ML 関係サービスなどの Google Cloud エコシステムは容易に、また低いレイテンシで連携することができ、データ活用の推進にも繋がります。 GCVE には vSphere、vCenter、vSAN、NSX、HCX などが含まれており、これらは既存の VMware プラットフォームと互換性があります。つまり、GCVE を採用すれば、VMware 資産や運用体制をほとんど変えずに、VM をクラウドに移行できることを意味しています。 GCVE は2024年7月現在、日本国内では東京リージョンで利用可能であり、大阪リージョンには対応していません。 参考 : Google Cloud VMware Engine 参考 : 機能、メリット、ユースケース 概要図 VMware ライセンス 2023年11月、米 Broadcom Inc. が VMware, Inc を買収しました。これに伴い、VMware 製品のライセンス体系が大きく変わりました。 従来、VMware の各製品のライセンスは、買い切り型ライセンスとして製品ごとに単体購入が可能でした。しかしながら経営体制の変更に伴い、買い切り型ライセンスは廃止され、様々な製品がバンドルされた「VMware Cloud Foundation（VCF）」や「VMware vSphere Foundation（VVF）」といった、サブスクリプション型ライセンスに切り替わりました。 このライセンス体系の変更により、一部の VMware ユーザー企業はライセンスコストが増加します。一部のユーザー企業は、ライセンスコスト増加を避けるため、クラウドへの移行を検討しています。 当記事で紹介する Google Cloud VMware Engine（GCVE）は、 利用料金に VMware 製品のライセンス費用も包含 されています。このことから、GCVE は VMware 仮想サーバー資産の移行先の有力な候補と考えることができます。 メリット GCVE へ VMware 仮想マシンを移行することで、物理機器の調達、セットアップ、増強などの管理や VMware ライセンスの管理工数が削減できます。これらはすべて、Google によって管理されるからです。これはすなわち、 TCO （Total Cost of Ownership、総所有コスト） の削減 に繋がります。 また、VM 資産をまずはいったん GCVE 環境にそのままの形で移行し、オンプレミスの物理機器を撤去したあとで、徐々にコンテナやフルマネージドサービス、サーバーレスなどのクラウドらしい近代的なアーキテクチャに移行（ モダナイズ ）するという中長期的な戦略を立てることにも繋がります。このように、一度は移行工数の少ない形で IT 資産をクラウドに移行し、その後でモダナイズする2段階の戦略のことを Lift & Shift と呼びます。 リフト＆シフト（2段階の移行戦略） 2段階の移行戦略をとる場合でも、Lift の段階で VM 群は Google Cloud の豊富なエコシステムと連携 できるようになります。つまり、BigQuery などの高性能なデータ分析サービス、生成 AI を含む先進的な AI/ML（人工知能・機械学習）サービスなどと、VM 上のデータを容易に連携できるようになります。 すなわち GCVE の利用は、「コスト削減」「クラウド化の第一歩となる」「データの活用推進」などの観点でメリットがあるといえます。 参考 : Google Cloud サービスの使用 基本的な構成 GCVE は Google Cloud VMware Engine プライベートクラウド と呼ばれる、他の GCVE 利用者とは分離された仮想領域に展開されます。その中で、 ノード と呼ばれるベアメタルハードウェアが割り当てられます。ノードは GCVE 利用の基本単位であり、複数ノードで vSphere クラスタを構成することができます。 ノードは ve1-standard-72 と ve2-standard-128 の2種類から選ぶことができますが、後者は限られたリージョンでしか利用できません。東京リージョンを含めた多くのリージョンでは、前者のみ利用可能です。 ve1-standard-72 のスペックは、以下のとおりです。 CPU メモリ ストレージ キャッシュ 2x - 2.6 GHz (3.9 GHz Turbo), 36 cores, 72 hyperthreaded cores 768 GB 19.2 TB NVMe 3.2 TB NVMe 参考 : VMware Engine プライベート クラウド Google Cloud VMware Engine プライベートクラウドの構成 ノード数と PoC GCVE は、原則的に 3ノード から利用できます。ただし、PoC（概念実証）やテストの目的で、限定的な期間のみ、単一ノードのプライベートクラウドを利用することが可能です。 単一ノードのプライベートクラウドはあくまで一時的な環境という扱いであり、SLA も適用されません。単一ノード環境は、 60日間で自動的に削除 されます。ただし60日以内に3ノード以上に増加することで、本番環境扱いになり、削除されず、SLA が適用されるようになります。 参考 : 単一ノードのプライベート クラウド 他社の類似サービス 他社の類似サービスとして Amazon Web Services（AWS）の VMware Cloud on AWS や Microsoft Azure の Azure VMware Solution が挙げられます。 なお AWS の VMware Cloud on AWSは、2024年4月30日以降、新規販売が停止されています。 参考 : VMware Cloud on AWS - FAQs 料金 GCVE ノード GCVE は、ノード数に応じた課金が発生します。課金方法には複数のオプションがあり、以下のリストの下に行くほど安価に利用できます。 オンデマンド（コミット・前払いともに無し） 1年コミットメント・月次支払い 1年コミットメント・前払い 3年コミットメント・月次支払い 3年コミットメント・前払い このノード料金には、vSphere、vSAN、NSX、HCX などの料金も含まれています。 このノード数に応じた料金のほか、構成によっては、Google Cloud から外に出るデータのトラフィック量に応じた課金（Egress traffic）や、専用線（Cloud Interconnect）、IP Sec VPN（Cloud VPN）の料金が発生する可能性があります。 参考 : Google Cloud VMware Engine pricing サードパーティライセンス VM 上で Windows Server を利用する場合、SPLA 形態で Google Cloud より提供されるライセンスを利用する必要があります。詳細は以下のドキュメントを参照してください。 参考 : About Microsoft Services Provider Licensing Agreement Microsoft 社のライセンスであるか否かにかかわらず、クラウドへのソフトウェアライセンス持ち込みには複雑なルールが定められている場合があります。ソフトウェアライセンスに関しては、ライセンス提供元や Google Cloud の営業担当者と密に相談のうえ、検討を進めてください。 非機能要件 セキュリティ 責任共有モデル GCVE では、通常の Google Cloud サービスと同様に、 責任共有モデル の考え方が適用されます。 物理レイヤのセキュリティは、Google Cloud の責任です。テナント間でハードウェアが共有されることはありません。また、データセンター設備のセキュリティ、物理マシンのファームウェアなども、Google がメンテナンスを行います。 NSX によるネットワーク構成、そして VM 上の OS やソフトウェアに関するセキュリティは、ユーザーの責任となります。 参考 : Google Cloud における責任の共有と運命の共有 参考 : 責任の共有 / 専用ハードウェア データの暗号化 GCVE では、保存中のデータは vSAN ソフトウェアベースの暗号化が行われます。その際に使われる暗号鍵は、デフォルトでは Google が提供する鍵管理システム（Cloud KMS）によって自動的に管理されます。これによりデータはユーザーから見て透過的に暗号化され、ストレージの物理的な盗難や不正な物理アクセスなどに対処することができます。 転送中のデータについては、必要に応じてアプリケーション側で暗号化する必要があります。 また、物理マシンの安全な廃棄などは、規約に定められた安全な方法で廃棄されます。 参考 : データ セキュリティ ネットワーク GCVE は、Google Cloud 内の安全な物理ネットワークインフラ上にあり、論理的には完全に独立しています。 ユーザー側では、仮想ネットワーク構成、後述するネットワークポリシー、外部アクセスルール（ファイアウォールルール）などによってアクセス制御を行います。 参考 : ネットワーク セキュリティ 可用性 GCVE では、障害が発生した ESXi ノードは自動的に交換されます。 また、NIC 障害やディスク障害、ラック単位での障害などに関しても、GCVE の機能と VMware の各種機能を組み合わせることで対応しており、高い可用性が維持されます。 参考 : 可用性と冗長性 オプショナルで VMware Engine 拡張プライベートクラウド を設定することで、複数の Google Cloud ゾーンにまたがるクラスタを構成し、可用性をより高めることができます。 拡張プライベートクラウドではクラスタが2つのゾーンにわたって拡張されます。ゾーン間は物理的に 10km 以上離れていますが、レイテンシ（RTT）は 5 ms 以下です。拡張プライベートクラウドの各ゾーンは、総容量の半分のキャパシティを持たせます。これにより、片方のゾーンが停止しても、もう片方のゾーンで業務を継続できます。さらに、2つのゾーンと別に監視用のゾーンを1つ利用します。この監視用のゾーンや監視ノードは Google によって管理されるため、我々は意識する必要がありません。 ただし、2024年7月現在の東京リージョンでは GCVE を利用できるゾーンが1つだけですので、拡張プライベートクラウドは利用できない点にご留意ください。 参考 : VMware Engine 拡張プライベート クラウド 拡張性 GCVE プライベートクラウドでは、コンソール画面からすぐにノードを追加したり、削除することができます。ノード追加の回数制限はありません。ただし、1つのクラスタのノードの最大数は32、1つのプライベートクラウドあたりのノードの最大数は96です。 参考 : vSphere クラスタの上限 ノードには ESXi の実行に必要な CPU、メモリ、ストレージが含まれており、ユーザー側での複雑なセットアップは必要ありません。 また、GCVE プライベートクラウドに新規のクラスタを追加することも容易です。クラスタには vSAN ディスクグループ、VMware HA、Distributed Resource Scheduler（DRS）などが含まれています。 参考 : プライベート クラウドのリソースとアクティビティを管理する VMware コンポーネント 概要 GCVE プライベートクラウドには多くの VMware アセットが含まれており、その利用料金はノードの利用料金に含まれています。また、各コンポーネントは Google Cloud コンソールから GCVE プライベートクラウドを作成する際に、ほぼ自動的にデプロイされます。 参考 : プライベート クラウド VMware コンポーネント 当記事では、以下の代表的なコンポーネントの概要のみを紹介します。 ESXi vCenter vSAN NSX HCX ESXi VMware ESXi は、ノード上で稼働するハイパーバイザです。GCVE では2024年7月現在、7.0 Update 3o（vSphere Enterprise Plus ライセンス）バージョンがデプロイされます。 GCVE では、ESXi はノードにインストール済みの状態で利用可能です。 各 ESXi ホスト（ノード）はデフォルトで クラスタ として構成されます。そして、最初のクラスタに各種管理コンポーネントがデプロイされます。 vCenter vCenter Server Appliance は、プライベートクラウドの vSphere 環境を一元管理するための仮想アプライアンスです。単に vCenter、または VCSA と呼ばれることもあります。GCVE では2024年7月現在、7.0 Update 3p（vCenter Standard ライセンス）バージョンがデプロイされます。 vCenter は vSphere クラスターに対する認証、管理、オーケストレーション（統合管理）の機能を提供します。プライベートクラウドを作成する際に、vCenter は自動的にデプロイされます。また、GCVE ではノードを追加した場合、自動的に vCenter にもノードが追加されます。 vSAN vSAN はストレージ機能です。 Software-defined（ソフトウェア定義）で物理的なストレージリソースを効率的に管理し、VM から利用可能にするための仕組みです。GCVE では2024年7月現在、7.0 Update 3o（Advanced + select vSAN Enterprise features ライセンス）バージョンがデプロイされます。 GCVE ではノードに接続されたローカル SSD を vSAN が統合管理します。 GCVE では vSAN の機能である 重複除去 （重複排除）と 圧縮 がデフォルトで有効になっており、効率的にストレージリソースを利用することができます。 また、vSAN の ストレージポリシー により、許容障害数（Failures to tolerate または FTT）と障害の許容方法（Failure tolerance method）を定義できます。例えば FTT が1の場合、RAID 1（ミラーリング）によって、すべてのデータには2つのコピーが作成されます。FTT を2にすると、すべてのデータには3つのコピーが作成されます。ただしこれには5台以上のノードが必要です。 このように FTT と障害の許容方法（RAID）をストレージポリシーで指定することで、データの堅牢性とストレージリソースの効率性のバランスを取ることができます。 参考 : Using Deduplication and Compression NSX NSX はネットワーク仮想化とセキュリティのためのコンポーネントです。仮想ネットワーク構築とセグメンテーション、ルーティング、ファイアウォール、NAT、VPN（L2 / L3）、LDAP 認証などの機能を備えています。GCVE では2024年7月現在、3.2.3.1.hp バージョンがデプロイされます。 VM 用のネットワークは、この NSX を利用して構築することになります。 HCX HCX はオンプレミスとクラウドの間での移行を実現するための機能です。GCVE では2024年7月現在、4.6.2（Enterprise ライセンス）バージョンがデプロイされます。 HCX により、 vMotion を使って無停止で VM を移行したり、レプリケーション機能により効率的にデータのコピーを実現できます。また、HCX による L2 延伸を利用することにより、IP アドレスを変更せずに VM を移行することも可能です。その他にも移行プロセスを自動化するための多くの機能を備えています。 HCX で実現できる移行方法として、L2 延伸とセットで利用することで仮想マシンを無停止で移行できる vMotion 、レプリケーション機能で事前にデータを移行先に複製しておき、最終切り替え時に vMotion を利用することで大容量ディスクを持つ VM でも無停止移行を実現できる Replication Assisted vMotion （RAV）、最終切り替えのタイミングで VM 停止を伴うが多数の VM の同時移行が可能な Bulk Migration 、VM を停止した状態で安全に移行を行う Cold Migration などが挙げられます。 HCX のライセンス料金は GCVE に含まれていますので、オンプレミス側にデプロイするにあたり、追加の料金を支払う必要はありません。 ネットワークの概要 概要図 GCVE プライベートクラウドのネットワーク構成は、以下のようになっています。 参考 : VMware Engine の VLAN とサブネット 参考 : VMware Engine ネットワークについて ネットワーク構成の概要図 オンプレミスとの接続 図の左端は、ユーザーの既存のオンプレミス環境を示しています。オンプレミス環境は、専用線サービスである Cloud Interconnect や、IPSec VPN である Cloud VPN を使って Google Cloud と接続することができます。vMotion などを利用することで、これらのネットワーク接続経由で既存の VMware VM を移行することも可能です。 Google Cloud のネットワーク 図左端のオンプレミス環境は、Cloud Interconnect や Cloud VPN で Google Cloud と接続されます。接続はユーザーの VPC ネットワーク（図左部分の Customer VPC network ）で終端されます。これは GCVE 以外の通常の Google Cloud ユーザーが用いる構成と同じです。 そして Customer VPC network は、図の中央左寄り部分に示したように、VPC network peering という仕組みで VMware Engine のマネージドな VPC network と接続されます。VPC network peering は Google Cloud の内部的なネットワーク接続の仕組みであり、仮想的なものです。 このような仕組みにより「オンプレミス環境」「Google Cloud の VPC」「GCVE プライベートクラウド」の3環境が、相互に L3 レイヤで接続され、Private IP アドレスで通信できるようになります。 GCVE のネットワーク 図の右寄り部分には、GCVE プライベートクラウド内のネットワークが示されています。 NSX によりサブネットを作成し、仮想マシン（VM）用の仮想ネットワークが構成できます（図右上部「 NST-X overlay networks 」）。このオーバーレイネットワーク上に、VM が配置されます。 参考 : サブネットの構成と管理 その VM 用ネットワークとは別に、プライベートクラウドに1つ、管理用ネットワークが作成されます（図右中央部「 Management networks 」）。これは Management VLAN とも呼ばれ、各種の管理用トラフィックのために使用されます。 また、図中に表現されていないものとして、HCX の各種サブネットやサービスサブネットと呼ばれる各種アプライアンス向けのサブネットも存在します。 参考 : VMware Engine の VLAN とサブネット これらのネットワークの IP アドレスレンジを設計するには、公式ドキュメントに記載されている各種要件を考慮に入れる必要があります。 参考 : ネットワーキングの要件 GCVE のノード GCVE では、各ノードは4つの物理ネットワークインターフェイスを持ちます。vSphere distributed switch（vDS）がデフォルトで作成され、各インターフェイスを接続します。 参考 : プライベート クラウド VMware コンポーネント - ESXi ネットワークの詳細 DNS 構成 GCVE は、Google Cloud のフルマネージドの DNS サービスである Cloud DNS と統合されています。管理アプライアンスの名前解決は、Cloud DNS を用いて行われます。Cloud DNS は VM の名前解決にも利用できます。また、一部のドメインの名前解決をオンプレミスの DNS に転送することも可能です。以下は、実現できる DNS 構成の例です。 プライベートな DNS ゾーンを Cloud DNS で保持し、VM から名前解決させる VM からの特定のドメイン名の名前解決クエリを、オンプレミスの DNS サーバーに転送する VM からのすべての名前解決クエリを、オンプレミスの DNS サーバーに転送する オンプレミスからの名前解決クエリを Cloud DNS で受け付ける また、vCenter Server、NSX Manager、HCX などの管理アプライアンスの DNS 名を解決するための 管理 DNS ゾーン も存在し、ユーザーの VPC とバインド（紐付け）することで、Google Cloud やオンプレミスから名前解決をすることができるようになります。 詳細は以下のドキュメントを参照してください。 参考 : DNS バインディングを構成する 参考 : プライベート クラウド用に管理 DNS を構成する 参考 : 管理アプライアンス アクセス用オンプレミス DNS の構成 インターネットとの通信 VM とインターネットとの通信を実現するには、Google Cloud 上に作成する エッジ （あるいは ゲートウェイ ）経由か、あるいはオンプレミス経由で通信させることで実現できます。 エッジは最大 2 Gbps の帯域を確保できる、インターネットへの出入り口です。後述の「ネットワークポリシー」を設定することで定義できます。最小でも /26 の、他のネットワークと重複しない IP アドレス範囲が必要です。 Google Cloud 上のエッジではなく、オンプレミス経由でインターネットへアクセスさせるには、オンプレミスから専用線等経由で Google Cloud へ 0.0.0.0/0 の経路を広報したうえで、ネットワークポリシーにおいて GCVE の外部 IP アドレスサービスやインターネットアクセスサービスを無効化します。 参考 : ワークロード VM のインターネット アクセスを構成する ネットワークポリシー GCVE のネットワークには ネットワークポリシー が設定可能です。以下のような事項を制御できます。 設定項目 説明 インターネットアクセスサービス 有効化すると VM からインターネットへのアウトバウンド（外向き）トラフィックを許可する 外部 IP アドレスサービス 有効化すると VM に Public IP アドレスを持たせることができるようになり、インバウンド（内向き）トラフィックを受け付けられる。インターネットアクセスサービスが有効である必要がある エッジサービスのアドレス範囲 VMware Engine パブリック IP ゲートウェイ（エッジ）が使用する IP アドレス範囲 参考 : ネットワーク ポリシーの作成と管理 外部アクセスルール 外部アクセスルール は外部 IP アドレスとインターネットの間のアクセス制御を司る、ファイアウォールルールのことです。 ルールには、送信元/先 IP アドレス、送信元/先ポート番号、インターネットプロトコル、優先度などを設定可能です。 参考 : 外部アクセスルール VM の移行 代表的な移行手法 既存 VMware 資産たる VM を移行するには、いくつかの方法があります。代表的なものを以下に挙げます。 手法名 概要 VMware HCX を利用したオンライン移行 前述した HCX を使います。方法によっては無停止・IP アドレス変更なしの移行が可能です。 オンプレミス側に HCX をインストールするための余剰リソースが必要です。HCX のライセンスは GCVE に含まれているため、追加調達は必要ありません。 Backup and disaster recovery tools の利用 リストア先として GCVE を指定します。 VMware PowerCLI の利用 移行先として GCVE を指定します。 ISO ファイルとテンプレートの利用 GCVE に ISO ファイルをアップロードし、vSphere コンテンツライブラリで公開されている VM テンプレートを使用して、新しい VM を作成 参考 : ワークロード VM の移行 参考 : VMware HCX を使用した VMware VM の移行 HCX を使った移行 HCX を用いた L2 レイヤでのネットワーク延伸（以下、 L2 延伸 ）と vMotion を用いたライブマイグレーション（無停止移行）は、最も低い工数で迅速に移行を実現できる方法です。 ただし、既存の VMware 上に HCX をインストールする必要があります。その際は余剰リソースと、vSphere バージョンの互換性に注意してください。2024年7月現在の GCVE でデプロイされる HCX は、バージョン 4.6.2 です。このバージョンの HCX では、 vSphere（ESXi）7.0 以上 がサポート対象です。 参考 : Product Interoperability Matrix また、HCX で L2 延伸を利用するには、オンプレミス側 vSphere 環境の仮想スイッチは vDS （vSphere Distributed Switch、分散スイッチ）である必要があります。vDS の利用には、vSphere Enterprise Plus ライセンスを要します。 参考 : Requirements for Network Extension このように HCX を使った移行には一定の要件があるため、場合によっては既存環境への構成変更が必要な場合があります。現行環境への影響を最小限にしたい場合、オンプレミスの余剰リソースを利用して移行用の「踏み台」となる vSphere 環境を構築するという手法も考えられます。この方法では VM を移行元環境からいったん踏み台環境に vMotion（通常の vCenter の機能）で無停止移行します。この踏み台環境は HCX の要件を満たしているので、踏み台環境から GCVE へは、HCX を使った L2 延伸と vMotion で移行を実現できます。 なお、L2 延伸はあくまで VM 移行のために一時的に実現 するネットワーク構成であり、永続的なものとするべきでない点には十分ご留意ください。 運用・保守 バックアップ 標準のバックアップ GCVE では、標準では以下がバックアップされ、Google Cloud のオブジェクトストレージである Cloud Storage に保存されます。 vCenter、PSC、DVS rule（夜間に増分バックアップ） NSX の構成 vCenter native API VMware 管理系ソフトウェアのアップグレード前の自動バックアップ ただし、上記には VM とそのデータが含まれていません。VM とデータをバックアップするには、後述する Backup and DR などを使います。 参考 : プライベート クラウドのメンテナンスと更新 参考 : データのバックアップ Backup and DR Service GCVE では、VM とデータをバックアップする機能が、Google Cloud サービスである Backup and DR Service （バックアップと DR サービス）によって提供されます。 Backup and DR Service によるバックアップでは、VM イメージが増分バックアップされます。最初のバックアップ時に各ディスクの VMDK snapshot が作成され、2回目以降は増分バックアップになります。 ユーザーの VPC にバックアップ用アプライアンスが Compute Engine VM として配置され、データをバックアップ・転送します。Backup and DR Service では、バックアップデータは Cloud Storage に保存されます。Cloud Storage は、容量無制限で堅牢、フルマネージドなオブジェクトストレージサービスです。 参考 : ワークロード VM のバックアップ ソリューション 参考 : Configure Google Cloud VMware Engine for Backup and DR protection Backup and DR Service なおこの方法では、VM のディスク単位のスナップショットが採取されるため、VM 上で稼働する固有のソフトウェアの考慮はされません。オプショナルで、エージェントを使ったバックアップを設定すると、Oracle Database、Microsoft SQL Server、PostgreSQL などのデータベースエンジンのバックアップ機能とエージェントが連動して、安全にバックアップを取得することが可能です。 Backup and DR Service のエージェントを使ったバックアップを検討する際は、エージェントの対応 OS や追加料金に注意してください。 参考 : About the Backup and DR agent 参考 : Usage measurement for agent-based backup サードパーティによるバックアップ Backup and DR Service を使う方法の他には、Dell EMC Data Protection Solution、Veeam Backup & Replication、Commvault Backup & Recovery などのサードパーティ製品により、バックアップを実現することも可能です。 参考 : サポートされているバックアップ ソリューション モニタリング GCVE の VM 監視には、vCenter monitoring tools や VMware を対象とする従来のサードパーティツールの利用が可能です。また、マルチクラウド向けの管理プラットフォーム製品 VMware Aria の一部である VMware Aria Operations を利用することもできます。適切なモニタリング手法の選択については、以下の記事を参照してください。 参考 : VMware Engine モニタリングの概要 また Google Cloud のネイティブなモニタリングサービスである Cloud Monitoring を利用することも可能です。スタンドアロンエージェントを VM にインストールすることで、指標を Cloud Monitoring に送信すると、Google Cloud コンソールで各種パフォーマンス情報が閲覧可能になります。また Cloud Monitoring の アラート 機能を用いると、指標がしきい値を超えた場合などに通知を発報することができます。 Cloud Monitoring については、以下の記事を参照してください。 blog.g-gen.co.jp GCVE ノード、vCenter、NSX、HCX の重要な障害は Cloud Logging にログエントリとして送信されるため、これをログベースのアラート機能で通知することも可能です。 Cloud Logging やログベースのアラート機能については以下の記事を参照してください。 blog.g-gen.co.jp メンテナンス 物理的なメンテナンス 可用性の項目でも記載したとおり、GCVE では、障害が発生した ESXi ノードやディスクなどは自動的に交換され、VM に影響が出ないようになっています。その他の Google Cloud が管理する物理インフラストラクチャのメンテナンスも、ほとんどの場合はユーザーが意識しないところで行われ、VM に影響は出ません。 ただし、月1回程度の GCVE のコントロールプレーンの更新時などに、一時的に GCVE ポータル（GCVE 用の Google Cloud コンソール画面）のダウンタイムが発生する場合があります。このような場合には事前に通知が行われます。ポータルのダウンタイムの間でも、VM 自体に影響はありません。 参考 : プライベート クラウドのメンテナンスと更新 ソフトウェア的なメンテナンス ESXi、vCenter、PSC、NSX などの VMware 系ソフトウェアのパッチやアップデートは、Google Cloud とメンテナンス時間枠を調整のうえ、実施されます。VMware からメジャーバージョンがリリースされてから、概ね6か月程度で適用されると説明されています。 参考 : 更新とアップグレード 監査ログ GCVE は Cloud Audit Logs と統合されており、監査ログが出力・保管されます。ただしここで記録されるアクションは、VMware の世界のアクションではなく、Google Cloud のレイヤのアクションが記録されます。例えば、以下のようなものです。 GCVE クラスタの追加、削除 GCVE ノードの追加、削除 ネットワークポリシーの作成、変更、削除 外部 IP アドレスの作成、変更、削除 また、人間のオペレーターやサポート担当者の操作に関するログも出力・保管されます。 前述のとおり、Cloud Audit Logs によって取得されるのは Google Cloud のレイヤのアクションのみです。VM 上で稼働するワークロードに関するログは、ユーザー側の責任で、適切に出力・保管する必要があります。 参考 : VMware Engine の監査ロギング情報 Cloud Audit Logs については、以下の記事も参照してください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。2024年6月のイチオシ Google Cloud アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに BigQuery の Slot Recommender が Preview => GA Cloud SQLでメンテナンスの最大5週間前に通知を受け取れるように Gemini in Colab Enterprise が Preview 公開 Vertex AI Studio が Google アカウントなしで試用できるように Google Cloud で Oracle がサポート Compute Engine で C4 マシンシリーズが登場（Preview） Vertex AI AutoML for Text が廃止、Gemini prompts and tuning に統合 Cloud Source Repositories の新規利用が停止に Gemini 公式 note がスタート Gemini 1.5 Pro の入力トークン数が100万→200万に Cloud Composer 3 が登場（Public Preview） Claude 3.5 Sonnet が Model Garden から使用可能に Cloud SQL のインプレイス・アップグレードで PostgreSQL 16 が利用可能に BigQuery JupyterLab plugin が登場（Preview） Gemini 1.5 Pro で出力を JSON フォーマットに固定できるように Google スプレッドシートの計算速度が2倍に はじめに 月ごとの Google Cloud アップデートのうち、特にイチオシなものをまとめています。 ある程度の事前知識が必要な記載となっています。サービスごとの前提知識は、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp またリンク先の公式ガイドは英語版にしないと最新情報が反映されていない場合がありますためご注意ください。 BigQuery の Slot Recommender が Preview => GA View edition slot recommendations (2024-06-05) BigQuery の Slot Recommender が Preview => GA。 過去30日間のスロット使用料に基づき、適切な Baseline/Max 設定やコミットメント購入のレコメンデーションを生成。また、月額費用の試算も提供してくれる。 Slot Recommender Cloud SQLでメンテナンスの最大5週間前に通知を受け取れるように About maintenance on Cloud SQL instances (2024-06-10) Cloud SQLでメンテナンスの最大5週間前に通知を受け取れるように。 メンテナンスとは、強制的なパッチ適用などを指し、Enterprise edition の場合、30秒程度のダウンタイムが発生する。従来は90日間の「メンテナンス拒否期間」や同一リージョン内インスタンスの「更新順序」は指定できた。今後は通知後、何週間で適用するかを指定可能になった。 Gemini in Colab Enterprise が Preview 公開 Write code in a Colab Enterprise notebook with Gemini assistance (2024-06-10) Gemini in Colab Enterprise が Preview 公開。 Colab Enterprise とは、フルマネージドの Jupyter notebook。 今回のアップデートで、コーディング中に生成 AI 基盤モデル「Gemini」がコード生成・補完してくれる。Preview 期間中は無料。 Vertex AI Studio が Google アカウントなしで試用できるように Vertex AI Studio console experiences (2024-06-10) Vertex AI Studio（Google Cloud の生成 AI モデルを試用できる Web コンソール）が Google アカウントなしでも利用できるように。 機能制限はあるが、無料で Gemini 1.5 Pro などを試用できる。 Vertex AI Studio の試用画面 Google Cloud で Oracle がサポート Accelerating cloud transformation with Google Cloud and Oracle (2024-06-12) Google Cloud で Oracle がサポートされるようになった 従来は Oracle は Google Cloud を Certify しておらず、原則的に Oracle Database を使うことが不可能だった。今後は以下のようになる。 Oracle Database を Compute Engine VM で稼働可能に Google Cloud Marketplace から Oracle Autonomous Database、Oracle Exadata Database を調達可能に Private Service Access で接続のイメージ Google Cloud と OCI のネットワーク接続が Cross-Cloud Interconnect で実現 以下は、Oracle 側の発表。 記事 : Oracle and Google Cloud Announce a Groundbreaking Multicloud Partnership 資料 : Licensing Oracle Software in the Cloud Computing Environment Authorized Cloud Environments として記載 詳細は Google Cloud 営業 / Oracle 代理店等と密に連携を。 Compute Engine で C4 マシンシリーズが登場（Preview） C4 machine series Compute Engine で C4 マシンシリーズが登場（Preview）。 第5世代 Intel Xeon Scalable processors（Emerald Rapids）を搭載。ドキュメント上の分類は Compute-optimized ではなく General-purpose。 Vertex AI AutoML for Text が廃止、Gemini prompts and tuning に統合 Vertex AI release notes - June 18, 2024 (2024-06-18) 2024-09-15以降、Vertex AI AutoML for Text の classification、entity extraction、sentiment analysis のモデルトレーニングが不可に。機能は Vertex AI Gemini prompts and tuning に移行される。 既存モデルも2025-06-15に使用不可に。 Cloud Source Repositories の新規利用が停止に Cloud Source Repositories release notes - June 17, 2024 (2024-06-17) 2024-06-17 をもって Cloud Source Repositories（Google CloudのマネージドのGitレポジトリ）の新規利用が停止。 これまでにAPIを有効化したことがない組織では新規に有効化ができなくなる。ただし既存ユーザーや、組織内で一度でもAPIを有効化したことがあれば、影響はない。 Gemini 公式 note がスタート Google の AI 「Gemini」、公式 note はじめます (2024-06-17) Google が、生成 AI 基盤モデル「Gemini」の公式 note を開始。 note は日本のサービスで、テキストを中心とした記事公開のためのメディアプラットフォーム。 Gemini 1.5 Pro の入力トークン数が100万→200万に Google models (2024-06-17) Gemini 1.5 Pro の最大入力トークンが100万→200万になった。 これにより、より多くのインプットができるようになった。 Cloud Composer 3 が登場（Public Preview） Comparison of Cloud Composer versions (2024-06-20) Cloud Composer 3 が登場（Public Preview）。 Cloud Composerとは、Google Cloudが提供するマネージドのApache Airflow。「3」では従来、プロジェクト内に見えたGKEクラスタが見えなくなりフルマネージドに。性能向上、シンプルなNW構成など、より利便性が増した。 Claude 3.5 Sonnet が Model Garden から使用可能に Vertex AI release notes - June 20, 2024 (2024-06-20) Claude 3.5 Sonnet が Model Garden から使用可能に。Vertex AI 経由で Claude を利用可能。 Claude 3.5 Sonnet は、Anthoropic 社が2024年6月21日に発表した最新の生成 AI 基盤モデル。Haiku < Sonnet < Opus ... 左は高速軽量、右は高精度だが高コスト。 なお、Amazon Bedrock でも同日に利用可能になっている。 Vertex AI API 経由での生成 AI モデルの利用 Cloud SQL のインプレイス・アップグレードで PostgreSQL 16 が利用可能に Upgrade the database major version in-place (2024-06-21) Cloud SQL for PostgreSQL のインプレイス・アップグレードで PostgreSQL 16 が利用可能に。 インプレイス・アップグレードでは IP アドレスや他の設定を変更することなく、メジャーバージョンのアップグレードができる。 BigQuery JupyterLab plugin が登場（Preview） Use the BigQuery JupyterLab plugin (2024-06-25) BigQuery JupyterLab plugin が登場（Preview）。 このオープンソースのプラグインでは、以下が実現できる。 JupyterLab から BigQuery のデータセット/テーブルを閲覧 BigQuery DataFrames により pandas / scikit-learn ライクに BQ のデータを操作 Cloud Composer へのデプロイ Gemini 1.5 Pro で出力を JSON フォーマットに固定できるように Control generated output (2024-06-25) Gemini 1.5 Pro で出力を JSON フォーマットに固定できるようになった。 従来は、プロンプトの中でフォーマットを指示していたが、確実にフォーマットを指定できるようになった。生成 AI アプリの開発に大きなアドバンテージ。 以下は、公式ドキュメントから引用した Python ソースコード。リクエスト時に MIME タイプを指定している。 response_schema = { "type" : "array" , "items" : { "type" : "object" , "properties" : { "recipe_name" : { "type" : "string" , }, }, "required" : [ "recipe_name" ], }, } model = GenerativeModel( "gemini-1.5-pro-001" ) response = model.generate_content( "List a few popular cookie recipes" , generation_config=GenerationConfig( response_mime_type= "application/json" , response_schema=response_schema ), ) Google スプレッドシートの計算速度が2倍に Doubling calculation speed and other new innovations in Google Sheets (2024-06-26) Google スプレッドシートの計算速度が2倍になった（公称）。 関数計算、ピボットテーブル、条件付き書式などの処理が高速になる。Google Chrome と Microsoft Edge ブラウザが対象。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の奥田梨紗です。オープンソースの Looker 拡張機能である Looker Dashboard Summarization を使い、Looker のダッシュボードを生成 AI が自然言語で説明する機能を実装しました。本記事ではその機能の紹介や、実装手順について紹介します。 はじめに 前提知識 Looker とは Looker 拡張機能と拡張フレームワークとは Gemini とは Looker Dashboard Summarization できること 料金 1. グラフの説明 2. 数値の特徴を説明 3. 次のアクションの提案 デモンストレーション動画 実装 構成 実装の手順 実装時の注意点 日本語で返答させるには はじめに 当記事では、Looker 拡張機能である Looker Dashboard Summarization を使い、生成 AI によって Looker のダッシュボードを自然言語で解説させる方法をご紹介します。 Looker Dashboard Summarization とは、Looker のダッシュボードに対して、生成 AI 自然言語での解説を提供する拡張機能です。オープンソースとして公開されており、Looker にアドオンとして組み込むことができます。 この拡張機能を導入することにより、以下のようなメリットが得られます。 初めてダッシュボードを閲覧する人や、統計に関する知識がない人でも内容を理解できる Slack や Google Chat への共有機能が存在し、情報共有を効率的に行うことができる なお配布されているソースコードでは、生成 AI 基盤モデルとして gemini-1.0-pro-001 （ Gemini ）が指定されています。 参考 : looker-open-source / dashboard-summarization 前提知識 Looker とは Looker は、ビジネスデータを探索、分析、可視化するためのクラウド型ビジネスインテリジェンス （BI）プラットフォームです。 参考 : Looker Looker には以下のような特徴があります。 データを保持しない（データベースから 常に最新の情報を取得 ） 独自言語 LookML により構成されるセマンティックレイヤで データガバナンス を実現 ダッシュボードによる可視化に留まらず マーケティングアクションへシームレスに連携 なお Looker と名称が似た製品に Looker Studio がありますが、これらは別製品です。以下の記事をご参照ください。 blog.g-gen.co.jp Looker 拡張機能と拡張フレームワークとは Looker 拡張機能 （Looker extension）は、Looker プラットフォームの機能を拡張するためのアドオン機能です。Looker 拡張機能を開発することで、Looker の基本機能を補完することができます。開発は、JavaScript で行います。 JS バンドル（JavaScript ファイルをまとめたパッケージ）を Looker にアップロードし、ホストさせることができるほか、別のサーバーや CDN にデプロイした JavaScript ファイルを URL で参照させることも可能です。 拡張機能はユーザーが自ら開発するほか、Looker Marketplace でニーズに合った拡張機能を見つけることもできます。 Looker 拡張フレームワーク （Looker extension framework）は Looker 拡張機能を開発するためのフレームワークです。 拡張フレームワークを使用すると、UI 実装のほか、認証・認可やアクセス制御、Looker API やサードパーティ API へのリクエストなどの実装を簡便化できます。 Looker Dashboard Summarization でも、Looker 拡張フレームワークが利用されています。 参考 : Looker 拡張機能の概要 参考 : Looker 拡張フレームワーク Gemini とは Gemini は Google が開発した生成 AI 基盤モデルです。テキスト生成、翻訳、音声処理、画像生成、コード生成など、幅広いタスクをこなせます。 現在では、以下のリンクから、Google Cloud の利用なしで、Gemini 1.5 Pro などを試用できます。 参考 : Vertex AI Studio - free trial 以下の記事もご参照ください。 blog.g-gen.co.jp Looker Dashboard Summarization できること Dashboard Summarization Looker Dashboard Summarization では、Looker ダッシュボード上で Gemini を呼び出し、以下を実現できます。 グラフの説明 数値の特徴を説明 次のアクションの提案 今回は架空の EC サイトの売上を分析するダッシュボードに Looker Dashboard Summarization を導入し、デモンストレーションしてみました。 なお、バックエンドのプロンプトを変更することで日本語による返答が可能です。 料金 当拡張機能の利用には、追加のライセンス費用は必要ありません。 自然言語での説明を指示した際に、Google Cloud の Vertex AI 経由で、Gemini API へのリクエスト料金が発生します。料金は、Google Cloud の請求先アカウントに課金されます。 料金単価は、以下の公式ページをご参照ください。 参考 : Vertex AI pricing 1. グラフの説明 架空 EC サイトの月別売上グラフに対する説明 ダッシュボード上の各グラフを 自然言語 （人間が使う言語）で説明し、 データの要点を分かりやすく説明 します。これにより、ユーザーはグラフの意味を直感的に理解しやすくなります。たとえば、売上の推移や顧客の購買傾向を視覚的に説明することで、重要なデータポイントをすばやく把握することができます。 上記の架空 EC サイトの月別売上グラフを用いた検証例では、以下のように説明しています。 このクエリは、過去3年間の月別の 総売上高を示しています。 2. 数値の特徴を説明 「カテゴリ別オーダー数」のグラフの数値的な特徴 データの数値的な特徴 を強調し、 特に注目すべきデータポイントを抽出 します。これにより、データの詳細な分析が可能です。例えば、売上のピークや低迷時期、特定の商品カテゴリーのパフォーマンスなど、ビジネス上重要なインサイトを得ることができます。 本検証では架空 EC サイト「商品カテゴリ別のオーダー数の積み上げグラフ」に関して、人気のある商品、人気の無い商品のカテゴリと件数だけでなく、EC サイトオーナーが関心を持ちそうな内容である曜日別の分析なども行ってくれました。 Shorts のオーダー数が最も多く、期間中の総オーダー数は741件です。 2位は Fashion Hoodies & Sweatshirts で、期間中の総オーダー数は689件です。3位は Sweaters で、期間中の 総オーダー数は650件です。最もオーダー数が少なかったのは Accessories で、期間中の総オーダー数は476件でした。 3. 次のアクションの提案 架空EC サイトの「ユーザー特質プロフィール」の円グラフに対する次のアクション Looker ダッシュボードを読み取り、 次のアクションを提案 します。これにより、データに基づいた意思決定が容易になります。たとえば、売上が低下している場合、その原因を分析し、在庫管理やマーケティング戦略の見直しなど、具体的な改善策を提示します。 本検証では、架空 EC サイトの「ユーザー特質プロフィール」を分析し、Webマーケティングのパフォーマンスを評価しました。そして、コンバージョン率を向上させるための戦略を立て、具体的なアクションを提案しました。 ・Search からのトラフィックが多い理由を 分析し、このチャネルへの投資を強化する。 ・Display からのトラフィックが少ない理由を調査し、改善策を検討する。 ・男女間の購買行動の違いを分析し、それぞれに最適化されたマーケティング 戦略を立案する。 デモンストレーション動画 こちらの動画では、操作手順をわかりやすく解説しています。さらに詳しい情報や実際の操作方法を知りたい方は、ぜひご覧ください。 ※当動画では Gemini の精度を確保するため英語でテストしてます www.youtube.com 実装 構成 今回実装した Looker Dashboard Summarization の構成図は、以下のとおりです。 システム構成図 データの流れは、以下のようになっています（以下の項番は、図中の数字①〜⑥と対応しています）。 データソース（今回は BigQuery）に格納されたデータが Looker から読み取られダッシュボード上に表示されている。ユーザーがダッシュボード上のボタンを押下する Looker 拡張機能からの HTTP リクエストにより Cloud Run が起動 Cloud Run が Looker の Query API を呼び出してデータを取得 Cloud Run が Vertex AI の Gemini API を呼び出して推論を実行 Cloud Run が取得した推論結果（生成されたテキスト）を Looker 拡張機能へ返す 生成されたテキストがダッシュボード画面上に表示される 実装の手順 実装の流れを簡単にご紹介します。 公開リポジトリをクローン（ GitHub レポジトリ ） ソースコードを改修 ソースコードをローカル PC でテスト Looker 拡張機能をセットアップ デプロイ 実装時の注意点 基本的には配布されているソースコードに添付されている README.md に沿って実装を行います。 特に注意が必要なのは、手順2-5. の Now log in to Looker and create a new project. です。ここでは、デプロイ前に lkml ファイルを書き換える 必要があります。 ローカルにおけるテスト時とデプロイ後では 参照すべき JavaScript ファイルの場所が異なる ためです。 環境 参照先の JavaScript ファイルの場所 ローカルでのテスト時 http://localhost:8080 デプロイ後 Looker インスタンス 当記事では、以下のように書き換えました。 ローカルでのテスト時 ローカルでのテスト時の manifest.lkml ファイル デプロイ後 デプロイ後の manifest.lkml ファイル 日本語で返答させるには GitHub で公開されているソースコードをそのまま使うと、説明文が英語で生成されます。日本語で回答するようにプロンプト内で指示することで、テキストを日本語で生成させることもできます。 以下の通りにソースコードを修正して、デプロイしてください。 修正するファイル dashboard-summarization/websocket-service/src/index.js 修正箇所 111行目の定数 queryPrompt に代入するテキスト 修正内容 Be sure to translate your response into Japanese language. を先頭に挿入 参考スクリーンショット 注意事項 ここでご紹介した方法は、あくまで生成 AI 基盤モデルに与えるプロンプトを変更しただけであり、確実に日本語で回答させられるわけではありません。想定通りに挙動しない場合、プロンプトを調整してください。 奥田 梨紗 (記事一覧) クラウドソリューション部クラウドデベロッパー課 前職はベトナムのIT企業。 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。日々修行中です！ Follow @risa_hochiminh

G-gen の大津です。当記事では、Google が提供する画像生成 AI モデル Imagen と、Web UI 用の Python フレームワークである Gradio を使用した、シンプルな画像生成 Web アプリの開発手順を紹介します。 はじめに Imagen Gradio 当記事で開発するもの ソースコードの開発 Python のバージョン requirements.txt main.py 動作確認 ローカルでの実行 画像生成 Web アプリを使用した画像生成 Google Cloud へのデプロイ Cloud Run の使用 ディレクトリ構成 コードの修正 Dockerfile の作成 Cloud Run にデプロイ 動作確認 Cloud Run のアクセス元制御について はじめに Imagen Imagen は、Google が提供する 画像生成 AI モデル です。Imagen は、Google Cloud の AI/ML 統合開発ツールである Vertex AI 経由で利用可能です。Vertex AI の Web コンソールや REST API 経由でテキストプロンプトを渡すことで、画像を生成することができます。 Imagen では以下のことが可能です。 テキストから新しい画像を生成する アップロードまたは生成された画像をテキストプロンプトで編集する 特定のオブジェクト（ハンドバッグや靴など）でモデルをファインチューニングし、画像を生成する 2024年6月現在、Imagen を使用するためには、申請フォームからの申請が必要となります。現在の Imagen 2 が「Generally Available with allowlist（許可リスト付きの一般公開）」という、制限付きの公開であるためです。 詳細は以下のドキュメントをご参照ください。 参考 : Imagen on Vertex AI | AI Image Generator Imagen の利用申請は、以下の申請フォームから行ってください。 参考 : Imagen on Vertex AI Access Request（申請フォーム） Gradio Gradio は、機械学習 Web アプリを容易に構築できる Python フレームワークです。 当記事では、Gradio の Interface() クラスを使用して web アプリを構成しています。 参考 : Gradio Docs - Interface 当記事で開発するもの 本記事では、以下を機能を持つ Web アプリケーションを開発しました。 Imagen 2 に対してパラメータ（サイズやアスペクト比など）をセットしてリクエストを投入し、画像を生成する 日本語のテキストプロンプトを受け付ける UI は日本語で表示する 一方で、以下は要件としていません。 アップロードした画像をプロンプトとして別の新しい画像を生成する 画像の一部を編集する（マスキング等） 特定の画像を使ってファインチューニングする ソースコードは、Google Cloud が提供する以下の GitHub リポジトリのソースコードを元にし、一部改変しています。ソースコードは Apache 2.0 ライセンス に基づいて公開されています。 参考 : Using a Gradio app and Vertex AI for image generation ソースコードの開発 Python のバージョン 当記事では、Python 3.12.0 を使って開発しています。 $ python --version Python 3 . 12 . 0 requirements.txt 使用するライブラリを、以下のとおり requirements.txt に定義します。 gunicorn google-cloud-aiplatform==1.52.0 google-generativeai==0.5.4 gradio==4.36.0 main.py 開発したコードの全文を以下に記載します。 変数 PROJECT_ID に定義する Your-Project-ID の部分は、ご自身が使用する Google Cloud プロジェクトの IDに置き換えてください。 ライセンス規約に基づき、改変部分が判るようにコメントを追加しています。 # Copyright 2023 Google LLC # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # https://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. import gradio as gr import traceback import vertexai from vertexai.preview.vision_models import ImageGenerationModel # 環境変数の設定 PROJECT_ID = "Your-Project-ID" # Google Cloud プロジェクトの ID LOCATION = "us-central1" # Gemini モデルを使用するリージョン vertexai.init(project=PROJECT_ID, location=LOCATION) def imagen_generate ( model_name: str , prompt: str , negative_prompt: str , sampleImageSize: int , aspect_ratio: str , # アスペクト比を指定できるように追加 sampleCount: int , seed= None , ): model = ImageGenerationModel.from_pretrained(model_name) generate_response = model.generate_images( prompt=prompt, negative_prompt=negative_prompt, number_of_images=sampleCount, guidance_scale= float (sampleImageSize), aspect_ratio=aspect_ratio, # アスペクト比を指定できるように追加 language= "ja" , # 日本語でのプロンプトに対応するために追加 seed=seed, ) images = [] for index, result in enumerate (generate_response): images.append(generate_response[index]._pil_image) return images, generate_response # Update function called by Gradio def update ( model_name, prompt, negative_prompt, sampleImageSize= "1536" , aspect_ratio= "1:1" , # アスペクト比を指定できるように追加 sampleCount= 4 , seed= None , ): if len (negative_prompt) == 0 : negative_prompt = None print ( "prompt:" , prompt) print ( "negative_prompt:" , negative_prompt) # Advanced option, try different the seed numbers # any random integer number range: (0, 2147483647) if seed < 0 or seed > 2147483647 : seed = None # Use & provide a seed, if possible, so that we can reproduce the results when needed. images = [] error_message = "" try : images, generate_response = imagen_generate( model_name, prompt, negative_prompt, sampleImageSize, aspect_ratio, sampleCount, seed # アスペクト比を指定できるように追加 ) except Exception as e: print (e) error_message = """An error occured calling the API. 1. Check if response was not blocked based on policy violation, check if the UI behaves the same way. 2. Try a different prompt to see if that was the problem. """ error_message += " \n " + traceback.format_exc() # raise gr.Error(str(e)) return images, error_message # gradio の設定 iface = gr.Interface( fn=update, inputs=[ gr.Dropdown( label= "使用するモデル" , choices=[ "imagegeneration@002" , "imagegeneration@006" ], # 最新モデルを使用する用に修正 value= "imagegeneration@006" , # 最新モデルを使用する用に修正 ), gr.Textbox( label= "プロンプト入力" , # 日本語での表示に修正 # 日本語での説明文章に修正 placeholder= "短い文とキーワードをカンマで区切って使用する。たとえば「昼間, 上空からのショット, 動いている鳥」など" , value= "" , ), gr.Textbox( label= "ネガティブプロンプト" , # 日本語での表示に修正 # 日本語での説明文章に修正 placeholder= "表示したくない内容を定義します" , value= "" , ), gr.Dropdown( label= "出力イメージサイズ" , # 日本語での表示に修正 choices=[ "256" , "1024" , "1536" ], value= "1536" , ), gr.Dropdown( # アスペクト比を指定できるように追加 label= "アスペクト比" , # 日本語での表示に修正 choices=[ "1:1" , "9:16" , "16:9" , "3:4" , "4:3" ], value= "1:1" , ), gr.Number( label= "表示件数" , # 日本語での表示に修正 # 日本語での説明文章に修正 info= "生成される画像の数。指定できる整数値: 1～4。デフォルト値: 4" , value= 4 ), gr.Number( label= "seed" , # 日本語での説明文章に修正 info= "必要に応じて結果を再現できるように、可能であればシードを使用してください。整数範囲: (0, 2147483647)" , value=- 1 , ), ], outputs=[ gr.Gallery( label= "Generated Images" , show_label= True , elem_id= "gallery" , columns=[ 2 ], object_fit= "contain" , height= "auto" , ), gr.Textbox(label= "Error Messages" ), ], title= "Image Generation with Imagen on Vertex AI" , # タイトルの修正 # 日本語での説明文章に修正 description= """テキストプロンプトからの画像生成。Imagen のドキュメントについては、この[リンク](https://cloud.google.com/vertex-ai/docs/generative-ai/image/generate-images)を参照してください。 """ , allow_flagging= "never" , theme=gr.themes.Soft(), ) # Local 起動 iface.launch() 動作確認 ローカルでの実行 以下のコマンドにより、ローカルホスト（127.0.0.1）のポート 7860 で Web アプリが起動します。 $ python3 main.py Running on local URL: http:// 127.0 . 0.1 : 7860 画像生成 Web アプリを使用した画像生成 ローカルで起動した Web アプリの URL（ http://127.0.0.1:7860 ）にブラウザでアクセスして、画像生成 Web アプリに接続します。 画像生成 Web アプリの UI から適当なテキストプロンプトを送信（Submit）してみます。送信（Submit）したテキストプロンプトの後に、Imagen モデルが生成した画像が表示されます。 テキストプロンプト：一生懸命ブログを執筆する男性, ジブリ風 画像生成におけるプロンプトの開発指針は、以下の Google Cloud 公式ドキュメントもご参照ください。 参考 : プロンプトと画像属性のガイド Google Cloud へのデプロイ Cloud Run の使用 開発した画像生成 Web アプリを、Google Cloud 上にデプロイします。当記事ではデプロイ先のサービスとして、サーバーレス コンテナ コンピューティングサービスである Cloud Run を使用します。Cloud Run の詳細については以下の記事をご一読ください。 blog.g-gen.co.jp ディレクトリ構成 今回開発した画像生成 Web アプリのディレクトリ構成は以下のとおりです。 imagen-app |-- main.py |-- requirements.txt |-- Dockerfile コードの修正 main.py 末尾の launch() の引数を、以下のように修正します。 iface.launch(server_name= "0.0.0.0" , server_port= 10080 ) Dockerfile の作成 Cloud Run へのデプロイには Docker イメージを用意する必要があるため、Dockerfile を作成します。 FROM python:3.12-slim WORKDIR /usr/src/app COPY requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 10080 CMD [ "python", "./main.py" ] Cloud Run にデプロイ Dockerfile の存在するディレクトリで以下のコマンドを実行し、コンテナイメージのビルドと Cloud Run へのデプロイを同時に行います。 # Cloud Run サービスをデプロイ $ gcloud run deploy gradio-imagen --source . \ --region = asia-northeast1 \ --allow-unauthenticated \ --port 10080 \ --memory = 1Gi \ --min-instances = 1 \ --max-instances = 1 ビルドされたコンテナイメージは、指定したリージョンに自動で作成される「cloud-run-source-deploy」という名前の Artifact Registory リポジトリに格納されます。 参考 : ソースコードからデプロイする  |  Cloud Run Documentation  |  Google Cloud 動作確認 Cloud Run のデプロイが完了すると、標準出力に Cloud Run のエンドポイントが Service URL として出力されます。この URL に、ブラウザからアクセスします。 $ gcloud run deploy gradio-imagen --source . --port 10080 --region = asia-northeast1 --allow-unauthenticated --memory = 1Gi --min-instances = 1 --max-instances = 1 This command is equivalent to running `gcloud builds submit --pack image = [ IMAGE ] .` and `gcloud run deploy gradio-imagen --image [ IMAGE ] ` Building using Buildpacks and deploying container to Cloud Run service [ gradio-imagen ] in project [ Your-Project-ID ] region [ asia-northeast1 ] ✓ Building and deploying... Done. ✓ Uploading sources... ✓ Building Container... Logs are available at [ https://console.cloud.google.com/cloud-build/builds/34c8fdeb-02c3-469d-b6ed-9b589d64d759?project = 858711621705 ] . ✓ Creating Revision... ✓ Routing traffic... ✓ Setting IAM Policy... Done. Service [ gradio-imagen ] revision [ gradio-imagen-00002-frp ] has been deployed and is serving 100 percent of traffic. Service URL: https://gradio-imagen-XXXXXXXXX-an.a.run.app ローカルで実行したときと同様に、Web アプリの UI にテキストプロンプトを送信（Submit）してみます。 テキストプロンプト：一生懸命ブログを執筆する女性, ジブリ風 Cloud Run のアクセス元制御について Cloud Run にデプロイした Web アプリのアクセス元制御を行いたい場合、Cloud Run の前段にロードバランサーを配置し、Identity Aware Proxy（IAP）による IAM 認証や Cloud Armor による IP アドレスの制限を実装することができます。 以下の記事もご参照ください。 blog.g-gen.co.jp 大津 和幸 (記事一覧) クラウドソリューション部 2022年4月にG-gen にジョイン。 前職まではAWSをはじめインフラ領域全般のなんでも屋。二刀流クラウドエンジニアを目指して、AWSのスキルをGoogle Cloudにマイグレーション中の日々。

G-gen の荒井です。当記事では Google Workspace のアプリケーションのみ使用してお問い合わせシステムを作成する方法をご紹介します。 はじめに ご紹介すること 記事の構成 設定作業概要 GAS 設定 GAS コード解説 GAS トリガー設定 テスト 設定1 : GAS 設定 設定2 : GAS コード解説 関数名 変数の定義 自動送信メールのオプション設定 自動送信メールの件名設定 自動送信メールの本文設定 メールの定義 プロジェクトの保存 設定3 : GAS トリガー設定 設定4 : テスト 次の記事 はじめに ご紹介すること 当記事では問い合わせ対応システムで使用する Google App Script （以下、GAS）の設定方法やサンプルコードをご紹介します。 Google App Script を使うことで、メールの送信や Google Workspace ユーザーの情報取得など、手作業で行っていた業務を自動化することができます。 当記事では、顧客が問い合わせ内容を Google フォーム経由で送信した際に、 顧客のメールアドレスへ自動返信メールを送信する ための設定方法とサンプルコードを解説します。 記事の構成 問い合わせ対応システムの開発方法は、以下の通り、連載記事としてご紹介します。記事を順に確認することで、問い合わせ対応システムが完成します。 No タイトルとリンク 1 Google Workspace で問い合わせ対応システムを作成する方法 #1 (システム概要) 2 Google Workspace で問い合わせ対応システムを作成する方法 #2 (Google グループ設定) 3 Google Workspace で問い合わせ対応システムを作成する方法 #3 (Google フォーム設定) 4 ※ 当記事 Google Workspace で問い合わせ対応システムを作成する方法 #4 (Google App Script 設定) 5 Google Workspace で問い合わせ対応システムを作成する方法 #5 (業務フロー解説) 6 ※ 準備中 Google Workspace で問い合わせ対応システムを作成する方法 #6 (機能拡張案) 設定作業概要 GAS 設定 前回の記事で作成したスプレッドシートに、GAS の設定を行います。 GAS コード解説 GAS のサンプルコードを解説します。 コードを書いたことがない方は、自社環境向けにコードを修正することに少し苦戦するかもしれません。まずは当記事で紹介するサンプルコードを把握してください。 GAS トリガー設定 GAS の実行条件となる、トリガー設定を行います。 テスト 実際に GAS を動作させ、期待通りの動作となっているか確認します。 設定1 : GAS 設定 前回の記事で作成した Google フォームの [回答] タブから、回答内容のエクスポート先となるスプレッドシートを開きます。 [ 拡張機能 > Apps Script ] から GAS の設定画面を開きます。 GAS 設定画面が開いたら、プロジェクト タイトル を設定します。 プロジェクト タイトル は他の GAS プロジェクトと区別しやすい名称を設定しましょう。 設定2 : GAS コード解説 今回使用するサンプルコードです。 function sendMail ( e ) { //フォームの回答から変数を定義 let timeStamp = e . namedValues [ "タイムスタンプ" ][ 0 ] ; let userName = e . namedValues [ "氏名" ][ 0 ] ; let userNameRubi = e . namedValues [ "氏名 (フリガナ)" ][ 0 ] ; let company = e . namedValues [ "会社名" ][ 0 ] ; let tel = e . namedValues [ "電話番号" ][ 0 ] ; let mailAddress = e . namedValues [ "メールアドレス" ][ 0 ] ; let title = e . namedValues [ "お問い合わせタイトル" ][ 0 ] ; let question = e . namedValues [ "お問い合わせ内容" ][ 0 ] ; //自動送信されるメールのオプションを設定（fromアドレス、送信者名称、Bcc） let option = { bcc : "otoiawase@XXXXXX.co.jp" , from : "otoiawase@XXXXXX.co.jp" , name : "お問い合わせ窓口" } ; //自動送信されるメールの件名を作成 let subject = "お問い合わせ受付メール [" + title + "]" ; //自動送信されるメールの本文を作成 let body = company + "\n" + userName + " 様" + "\n" + "\n" + "お問い合わせありがとうございます。" + "\n" + "\n" + "本メールはお問い合わせ内容をご確認いただくための【自動返信】メールとなります。" + "\n" + "お問い合わせ内容については担当者アサイン後メールを送付させていただきますため、恐れ入りますが今しばらくお待ちください。" + "\n" + "\n" + "■ お問い合わせ内容" + "\n" + "\n" + "【会社名】" + "\n" + company + "\n" + "\n" + "【担当者名】" + "\n" + userName + "\n" + "\n" + "【電話番号】" + "\n" + tel + "\n" + "\n" + "【メールアドレス】" + "\n" + mailAddress + "\n" + "\n" + "【お問い合わせタイトル】" + "\n" + title + "\n" + "\n" + "【お問い合わせ内容】" + "\n" + question + "\n" + "\n" + "■ お問い合わせ窓口" + "\n" + "対応時間：10:00〜19:00（土日祝日・弊社指定休日を除く）" + "\n" + "Mail : otoiawase@XXXXXX.co.jp" + "\n" + "\n" + "\n" + "Send Time" + "\n" + timeStamp + "\n" + "\n" ; // 送信先アドレス、件名、本文、オプション をまとめて1通のメールとして定義 GmailApp . sendEmail ( mailAddress , subject , body , option ) ; } 関数名 関数名を記述します。ここで決めた関数名は、後述するトリガー設定で使用します。プログラムの実行内容がわかりやすい名称を付与します。 function sendMail ( e ) { 今回はメール自動送信のため「sendMail」としています。 変数の定義 お問い合わせフォームで入力された内容を自動返信メールに記載するため、フォームに入力された内容を変数として定義します。 let timeStamp = e . namedValues [ "タイムスタンプ" ][ 0 ] ; let userName = e . namedValues [ "氏名" ][ 0 ] ; let userNameRubi = e . namedValues [ "氏名 (フリガナ)" ][ 0 ] ; let company = e . namedValues [ "会社名" ][ 0 ] ; 〜以下略〜 "氏名" や "会社名" となっている部分は、Google フォームの「質問のタイトル」に対応しています。フォームに入力された内容を、変数 "userName" や "company" に代入しています。 let 変数名 = 値 により、変数の定義と値の代入を同時に行っています。これによりフォームに入力された値をプログラムの中から利用できるようになります。また、変数名は キャメルケース という法則に従い、先頭は小文字にし、単語のつなぎ目を大文字としています。 Google フォームの「質問のタイトル」をカスタマイズしている場合、それに応じてコードを修正してください。 自動送信メールのオプション設定 自動送信されるメールの bcc や from アドレス、受信者に表示される送信者の名称を定義します。 let Option = { bcc : "otoiawase@XXXXXX.co.jp" , from : "otoiawase@XXXXXX.co.jp" , name : "お問い合わせ窓口" } ; bcc は、「 #2 設定1 : Google グループ作成 」で作成したグループアドレスを入力します。 Google グループにもメールを送ることで、グループに会話が追加され、Google グループで対応することが可能になります。 from も同様にグループアドレスを設定します。 name は、受信者に表示される送信者の名称を設定します。 自動送信メールの件名設定 自動送信されるメールの件名を設定します。文字列は " （ダブルクォーテーション）で囲みます。それ以外の文字列は + で結合します。 let subject = "お問い合わせ受付メール [" + title + "]" ; title という名称の変数を使用しており、フォームの「お問い合わせタイトル」に入力された値が件名に挿入されます。 自動送信メールの本文設定 自動送信されるメールの本文を設定します。 let body = company + "\n" + userName + " 様" + "\n" + "\n" + "お問い合わせありがとうございます。" + "\n" + "\n" + "本メールはお問い合わせ内容をご確認いただくための【自動返信】メールとなります。" + "\n" + "お問い合わせ内容については担当者アサイン後メールを送付させていただきますため、恐れ入りますが今しばらくお待ちください。" + "\n" + "\n" + "■ お問い合わせ内容" + "\n" + "\n" + "【会社名】" + "\n" + company + "\n" + "\n" + 〜以下略〜 件名同様、文字列部分をダブルクォーテーションで囲ったり、定義した変数を使用して、送信するメールの本文を作成します。 メールの定義 それぞれ設定した件名や本文、オプションを組み合わせて、1通のメールを送信する命令を記述します。 GmailApp . sendEmail ( mailAddress , subject , body , option ) ; プロジェクトの保存 コードを変更した際は、都度「プロジェクトの保存」を行う必要があります。コードの修正が完了したら、プロジェクトを保存します。 設定3 : GAS トリガー設定 記述したコードが実行されるきっかけとなる、 トリガー を設定します。今回は、 フォームに問い合わせが送信されたタイミング で実行されるよう設定します。 GAS 設定画面左メニューより [トリガー] をクリックします。 [ + トリガーを追加] をクリックします。 以下の通りパラメータを設定し、[保存] をクリックします。 設定項目 パラメータ 実行する関数を選択 sendMail イベントの種類を選択 フォーム送信時 GAS を実行するユーザーを選択します。「 #1 設定3 : グループアドレスを送信元とする設定 」で設定を行ったユーザーを指定します。 GAS が実行アカウントを使用し、Gmail の送信などができるよう設定するため [Allow] をクリックします。 トリガー画面に、作成したトリガーが表示されればトリガー設定は完了です。 これで、新規フォームが送信されたタイミングで関数「sendMail」が実行され、メールが自動送信されます。 設定4 : テスト 実際にコードが動作させ、テストします。Google フォームに値を入力して、メールが届くかどうかを確認してください。自動返信メールはフォームの「メールアドレス」に入力したアドレスと「作成した Google グループ」に送信されます。 期待した挙動とならなかった場合、エラーログを確認します。 GAS 設定画面左メニューより [実行数] をクリックします。GAS のコードが原因の場合、エラーログにコメントと、コードの失敗箇所（ファンクション名/何行目/何文字目）が表示されるのでコードを再確認します。 次の記事 Google Workspace で問い合わせ対応システムを作成する方法 #5 (業務フロー解説) 荒井 雄基 (記事一覧) クラウドソリューション部 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。 Google Cloud 認定資格 7冠 現在は Google Workspace を中心に企業の DX 推進をサポート。 最近頑張っていることは、子どもがハマっている戦隊モノの踊りを踊れるようになること。

G-gen の佐々木です。当記事では、Cloud Run のドメインマッピング機能で設定したカスタムドメインが削除できない事象について、解決方法を解説します。 前提知識 事象の詳細 解決方法 削除時に Cloud Storage に関するエラーが発生する場合 余談：特定リージョンにおけるカスタムドメインの使用について 前提知識 Cloud Run では ドメインマッピング 機能を使用することで、Cloud Run サービス（以下、 サービス と呼びます）に対してカスタムドメインをマッピングすることができます（2024年6月時点ではプレビュー機能）。 この機能を使用することで、カスタムドメインの設定に必要な Cloud Load Balancing や HTTPS 接続用の Google マネージド証明書が自動的に作成されるため、手軽にサービスに対してカスタムドメインをマッピングすることができます。 事象の詳細 一度設定したドメインマッピングの設定を削除するためには、サービスの「統合」タブから設定を削除する必要があります。 しかし、ドメインマッピングを削除する前に対象のサービスを削除してしまった場合、Cloud Run コンソール上にドメインマッピングの設定が残り続けてしまいます。 削除したサービスのドメインマッピングが残っており削除できない こうなってしまった場合、コンソールや CLI を使用してドメインマッピングを削除することができなくなってしまいます。 解決方法 ドメインマッピングを設定していたサービス（削除したサービス）と 同名のサービス を 同一リージョン 作成すると、残っていたドメインマッピングの設定が自動的に適用されます。 削除したサービスと同名のサービスにカスタムドメインが自動で設定される 同名のサービスを作成したあと、「統合」タブからカスタムドメインの設定を削除することができます。 「統合」タブからカスタムドメインを削除する 削除時に Cloud Storage に関するエラーが発生する場合 サービスの「統合」タブからカスタムドメインを削除しようとすると、以下のようなエラーが発生する場合があります。 Invalid resource state for "gs://runapps_default-xxxxxx/terraform/configs/default-cd10ccbc-01bc-48af-b4cc-b67ee5bb4a4d/": Failed to write to "gs://runapps_default-xxxxxx/terraform/configs/default-cd10ccbc-01bc-48af-b4cc-b67ee5bb4a4d/". Ensure that the resource exists and is writable by the deployment service account. Cloud Storage バケットのリソースに書き込みできない旨のエラーメッセージ ドメインマッピングの設定は裏で Terraform が使用されているようで、Terraform の state ファイルを保存するための Cloud Storage バケットがプロジェクト内に存在しない場合、このエラーが発生します。 エラーメッセージに表示されているバケット名（エラーメッセージの「 runapps_default-xxxxxx 」の部分）を使用して、Cloud Run と同じリージョンにバケットを手動で作成することで、この問題を解決することができます（空のバケットでよい）。 余談：特定リージョンにおけるカスタムドメインの使用について Cloud Run の既知の問題（2024年6月時点）として、 asia-northeast1 もしくは us-east4 リージョンに存在する、カスタムドメイン機能を使用している Cloud Run サービスに対するリクエストは、レイテンシが非常に大きくなる場合があります。 該当リージョンの Cloud Run にカスタムドメインを設定したい場合は、Cloud Run のドメインマッピング機能を使用せず、別途 Cloud Load Balancing を作成して サーバーレス NEG を構成したほうがよいでしょう。 参考： Cloud Run の既知の問題 - 一部のリージョンからの呼び出し時にカスタム ドメインでリクエスト レイテンシが増加する 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では、Gemini Pro に長文のリクエストを送信した際に発生することがある ResponseValidationError について解説します。 当記事で使用する環境 事象 原因と解決方法 原因 原因の詳細 解決方法 当記事で使用する環境 当記事では、以下の記事で作成した Gradio の UI を使用するチャットボットの画面を用いて説明を進めます。 blog.g-gen.co.jp このチャットボットは、ユーザーが入力した文章を加工せずに Gemini Pro の API に送信し、レスポンスをそのまま UI 上に表示するものとなっているため、Gemini Pro が入出力するメッセージの内容は Google Cloud コンソールや CLI などで Gemini Pro を利用する場合と同じものになります。 また当記事では、モデルは Gemini 1.5 Pro を使用しています。 事象 チャットボットに長文メッセージを処理させるため、 先ほど引用した記事 の本文をすべて英訳するようにリクエストを送信します。 記事の内容をすべて英訳するようにリクエストを送る リクエスト送信後、チャット欄には以下のようなメッセージがレスポンスとして表示されます。これはあらかじめボットに設定しておいたエラーメッセージであり、 ResponseValidationError が返ってきたときに表示するようにしてあります。 チャットボットに設定したエラーメッセージが返ってくる エラーログを確認すると、以下のように、実際に ResponseValidationError が発生していることがわかります。 ResponseValidationError: The model response did not completed successfully. Finish reason: 2 . Finish message: . Safety ratings: [ category: HARM_CATEGORY_HATE_SPEECH probability: NEGLIGIBLE probability_score: 0 . 147210672 severity: HARM_SEVERITY_NEGLIGIBLE severity_score: 0 . 0915427357 , category: HARM_CATEGORY_DANGEROUS_CONTENT probability: NEGLIGIBLE probability_score: 0 . 100023173 severity: HARM_SEVERITY_NEGLIGIBLE severity_score: 0 . 187433839 , category: HARM_CATEGORY_HARASSMENT probability: NEGLIGIBLE probability_score: 0 . 236804441 severity: HARM_SEVERITY_NEGLIGIBLE severity_score: 0 . 0960960239 , category: HARM_CATEGORY_SEXUALLY_EXPLICIT probability: NEGLIGIBLE probability_score: 0 . 147182867 severity: HARM_SEVERITY_NEGLIGIBLE severity_score: 0 . 121138074 ] . To protect the integrity of the chat session, the request and response were not added to chat history . To skip the response validation, specify `model.start_chat ( response_validation =False ) ` . Note that letting blocked or otherwise incomplete responses into chat history might lead to future interactions being blocked by the service. 原因と解決方法 原因 ここで発生した ResponseValidationError は、Gemini Pro からの レスポンスのトークン数 が、 リクエストを送信するときに指定した maxOutputTokens パラメータの値を超過していることに起因します。 maxOutputTokens は、生成 AI モデルがレスポンスとして生成できるトークンの最大数です。1トークンは約4文字、100トークンは約60~80語とされています（ 参考 ）。 原因の詳細 当記事で例として使用しているチャットボットの 解説記事 では、Gemini モデルが不適切なコンテンツを生成し、それがブロックされたため ResponseValidationError が発生していました。 もちろん、今回送信したリクエストでも同様の原因でエラーが発生する可能性があります。しかし、以下に抜粋したエラーログを見てみると、レスポンスの内容が不適切なものである確率を評価する各 category の probability が、いずれも「NEGLIGIBLE」になっており、レスポンスの内容が問題ないと判断されていることがわかります（ 参考 ）。 Safety ratings: [ category: HARM_CATEGORY_HATE_SPEECH probability: NEGLIGIBLE probability_score: 0 . 147210672 severity: HARM_SEVERITY_NEGLIGIBLE severity_score: 0 . 0915427357 , category: HARM_CATEGORY_DANGEROUS_CONTENT probability: NEGLIGIBLE probability_score: 0 . 100023173 severity: HARM_SEVERITY_NEGLIGIBLE severity_score: 0 . 187433839 , category: HARM_CATEGORY_HARASSMENT probability: NEGLIGIBLE probability_score: 0 . 236804441 severity: HARM_SEVERITY_NEGLIGIBLE severity_score: 0 . 0960960239 , category: HARM_CATEGORY_SEXUALLY_EXPLICIT probability: NEGLIGIBLE probability_score: 0 . 147182867 severity: HARM_SEVERITY_NEGLIGIBLE severity_score: 0 . 121138074 ] . クライアントライブラリの FinishReason クラス を確認すると、 Finish reason の値によってエラーの原因が分類されているようです。 レスポンスに不適切な内容が含まれていた場合、Finish reason の値は 3（ SAFETY (3) ）となります。 # クライアントライブラリから引用 class FinishReason (proto.Enum): r"""The reason why the model stopped generating tokens. If empty, the model has not stopped generating the tokens. Values: FINISH_REASON_UNSPECIFIED (0): The finish reason is unspecified. STOP (1): Natural stop point of the model or provided stop sequence. MAX_TOKENS (2): The maximum number of tokens as specified in the request was reached. SAFETY (3): The token generation was stopped as the response was flagged for safety reasons. NOTE: When streaming the Candidate.content will be empty if content filters blocked the output. RECITATION (4): The token generation was stopped as the response was flagged for unauthorized citations. OTHER (5): All other reasons that stopped the token generation BLOCKLIST (6): The token generation was stopped as the response was flagged for the terms which are included from the terminology blocklist. PROHIBITED_CONTENT (7): The token generation was stopped as the response was flagged for the prohibited contents. SPII (8): The token generation was stopped as the response was flagged for Sensitive Personally Identifiable Information (SPII) contents. """ 今回のエラーメッセージの2行目を見てみると、Finish reason の値は 2（ MAX_TOKENS (2) ）となっています。したがって、Gemini Pro が扱うことのできるトークン数に起因したエラーであることがわかります。 ResponseValidationError: The model response did not completed successfully. Finish reason: 2 . 解決方法 Gemini Pro に対してリクエストを送信する際に指定する maxOutputTokens パラメータの値を増加させることで、当該事象を解決できる可能性があります（ 参考 ）。 モデルごとに設定できる maxOutputTokens の値は ドキュメントのモデル一覧 を参照してください。今回使用している Gemini 1.5 Pro では 8,192 が最大値となっています。 当記事で使用しているチャットボットでは、いくつかのパラメータを動的に調整してリクエストを送信できるようにしてあるので、先ほどエラーが発生したリクエストと同じ内容を maxOutputTokens を 8,192 にしてから送信してみます。 maxOutputTokens の値を 8,192 にしてから再度リクエストを送信する リクエスト内容によっては maxOutputTokens が最大値であっても超過してしまう可能性があるため、これでもエラーが発生する可能性がありますが、今回は問題なくレスポンスとして記事の英訳が表示されました。 エラーが発生せずに記事の英訳が返ってくる maxOutputTokens の最大値はモデル側で制限されているため、根本的な解決が難しくなっています。今回のような事象に対しては「リクエストの内容を変えてください」等のメッセージをチャットボットに表示するように例外処理を実装しておくのが無難な対処となるでしょう。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-genの杉村です。Google Cloud（旧称 GCP）で、組織の「組織 ID」や「顧客 ID」を調べる方法について紹介します。 組織 ID、顧客 ID とは 組織 ID の確認方法 プロジェクトセレクタで確認する Resource Manager 管理画面 gcloud コマンド 顧客 ID の確認方法 gcloud コマンド Google Workspace の管理画面 組織 ID、顧客 ID とは Google Cloud において、 組織 （Organization）はドメイン名の他に、 組織 ID （別名、組織リソース ID）と 顧客 ID （別名、お客様 ID）を持っています。 そもそも組織とはなにか、については以下の記事をご参照ください。 blog.g-gen.co.jp 組織 ID は10桁〜13桁程度の数字で表されます。Google Cloud の組織リソースとしての ID です。 顧客 ID は、9文字程度の英数字で表され、Google Workspace（Cloud Identity）のテナントの ID である、という性質があります。 これらの ID は、組織ポリシーの制約「 ドメイン別の ID の制限 （英名「Restricted Domain Sharing」、ID は iam.allowedPolicyMemberDomains ）」を利用する際に、許可対象の組織を指定するときに必要になります。 この組織ポリシーを使っている Google Cloud 環境では、許可した組織以外に属する Google アカウント等が IAM 権限を持てないようになります。信頼する組織のアカウントだけが IAM 権限を持てるようになるので、環境のセキュリティを高める効果が期待できます。 この組織ポリシーで許可対象の組織を指定するときは、組織 ID もしくは顧客 ID で指定する必要があります。なお、制約のカスタム設定値にこれらの ID を指定する際は、顧客 ID はそのまま入力できますが、組織 ID は principalSet://iam.googleapis.com/organizations/(組織 ID) の形式で入力する必要があります。 参考 : ドメイン別の ID の制限 これらの ID の取得手順は以下のような公式ドキュメントに記載がありますが、ドキュメントが複数あるため、当記事では公式ドキュメントの内容をまとめることに加え、独自の情報とあわせて、ID の取得手順をご紹介します。 参考 : 組織リソース ID の取得 参考 : Google Workspace お客様 ID の取得 参考 : 顧客 ID の確認 組織 ID の確認方法 プロジェクトセレクタで確認する 最も簡単な確認方法です。 Google Cloud の Web コンソール（ https://console.cloud.google.com ）にログインし、画面上部のプロジェクトセレクタをクリックします。 プロジェクトセレクタ 次に、スクリーンショットの①部分をクリックし、ID を取得したい組織名を選択します、次に、タブ「すべて」（②）クリックします。最後に、対象の組織のドメイン名の行の、ID 列（③）を確認します。この部分に表示されている数字が、組織 ID です。 組織 ID（組織リソース ID）を確認 なお、組織ポリシーの制約「ドメイン別の ID の制限（iam.allowedPolicyMemberDomains）」にこの値を指定する際は、 principalSet://iam.googleapis.com/organizations/(組織 ID) の形式で入力する必要があります。 もし①で組織を選択できない場合、組織に対する resourcemanager.organizations.get 権限が足りないことが想定されます。この権限を得るには、組織レベルで以下のようなロールのいずれかを持っている必要があります（例として代表的なロールのみを挙げています）。 組織の管理者（ roles/resourcemanager.organizationAdmin ） 閲覧者（ roles/viewer ） 参照者（ roles/browser ） Resource Manager 管理画面 Resource Manager 管理画面でも、組織 ID を確認できます。 Google Cloud の Web コンソール（ https://console.cloud.google.com/ ）で「IAM と管理 > リソースの管理」へ遷移するか、直接 https://console.cloud.google.com/cloud-resource-manager へアクセスします。 組織、フォルダ、プロジェクトなどのリソース一覧が表示されます。対象の組織のドメイン名の横にある ID 列に、組織 ID が表示されています（自分が get 権限を持っているすべての組織の情報が表示されます）。 リソースマネージャーのツリー画面で組織 ID を表示 組織名が表示されない場合は、適切な権限を持っていないことが原因です。 プロジェクトセレクタで確認する の項で書いたとおり、適切な権限を付与された Google アカウントで確認する必要があります。 繰り返しになりますが、組織ポリシーの制約「ドメイン別の ID の制限（iam.allowedPolicyMemberDomains）」にこの値を指定する際は、 principalSet://iam.googleapis.com/organizations/(組織 ID) の形式で入力する必要があります。 gcloud コマンド gcloud CLI が実行可能な環境で、以下のコマンドを実行してください。 gcloud organizations list 実行アカウントに適切な権限があれば、以下のように、組織 ID と顧客 ID の両方が表示されます（自分が get 権限を持っているすべての組織の情報が表示されます）。 $ gcloud organizations list DISPLAY_NAME: hogehoge.co.jp ID: 123456789012 DIRECTORY_CUSTOMER_ID: C01abc123 DISPLAY_NAME: fugafuga.co.jp ID: 98765432109 DIRECTORY_CUSTOMER_ID: C00123abc ID: のあとに表示されているのが組織 ID、 DIRECTORY_CUSTOMER_ID: の後に表示されているのが顧客 ID です。 コマンドがエラーとなった場合は権限不足が疑われます。 プロジェクトセレクタで確認する の項の末尾を確認してください。 顧客 ID の確認方法 gcloud コマンド Google Cloud 管理者にとって、顧客 ID を調べる最も簡単な方法は gcloud コマンドです。 前述の、組織 ID を調べるための「gcloud コマンド」の項にて説明したとおり、 gcloud organizations list コマンドを実行すると組織 ID と同時に、顧客 ID が表示されます。掲載したコマンド出力例の DIRECTORY_CUSTOMER_ID の後に表示されているのが顧客 ID です。 組織に get 権限を持っていれば、この方法で簡単に顧客 ID を調べることができます。 Google Workspace の管理画面 Google Workspace、もしくは Cloud Identity の管理画面からも、顧客 ID を調べることができます。ただし、この方法で顧客 ID を確認するには、管理者ロールにて適切な「管理コンソールの権限」を持っている必要があります。 まず、Google 管理コンソール（ https://admin.google.com ）にログインします。 次に、「アカウント > アカウント設定 > プロファイル」に画面遷移します。 「顧客 ID」の項に、自組織の顧客 ID が表示されています。 Google Workspace の管理コンソールで顧客 ID を表示 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の三浦です。当記事では Cloud NGFW （旧称 Cloud Firewall）の IPS 機能について検証した結果をご紹介します。 概要 Cloud NGFW とは IPS とは 検証の概要 前提 構成図 検証の流れ EICAR ファイル 検証環境の構築 セキュリティプロファイルの作成 セキュリティプロファイルグループの作成 ファイアウォールエンドポイントの作成 ファイアウォール ポリシーの作成 攻撃検知の検証 パターン1（EICAR ファイル） パターン2（/etc/passwd ディレクトリ） ブロックの検証 IPS の設定変更 パターン1（EICAR ファイル） パターン2（/etc/passwd ディレクトリ） 概要 Cloud NGFW とは Cloud Next Generation Firewall は、Google Cloud（旧称 GCP）の Virtual Private Cloud（以下、VPC）で利用可能な、フルマネージドのファイアウォールサービスです。 サービス名は、公式ドキュメント等でも Cloud NGFW と省略されているため、当記事でも以後、Cloud NGFW と表記します。なお、Cloud NGFW はかつて Cloud Firewall という名称でしたが、2024年4月に改称され、Cloud NGFW になりました。 Cloud NGFW には無償の Essentials と有償の Standard、Enterprise の3つのティアが存在し、当記事で紹介する IPS 機能は Enterprise ティアでのみ利用可能です。 参考 : Cloud NGFW の概要 Cloud NGFW の詳細や各ティアの詳細については弊社ブログで解説しておりますのでそちらをご参照ください。   blog.g-gen.co.jp IPS とは IPS （Intrusion Prevention System）とは、ネットワークトラフィックを監視し、ネットワーク内で悪意のある攻撃を検知した際にブロックをする侵入防止システムです。 IPS という用語は Google Cloud に特有のものではなく、ネットワークセキュリティツールの一般的な名称です。 Cloud NGFW の IPS 機能は Intrusion prevention service とも表記され、日本語ドキュメントでは「 侵入防止サービス 」と表記されることがあります。IPS、Intrusion Prevention System、Intrusion prevention service、侵入防止サービスといった用語は、Cloud NGFW の背景では、同じものを指すと考えて構いません。 参考 : 侵入防止サービスの概要 なお、類似の用語で IDS（Intrusion Detection System）があります。こちらは IPS と同様に悪意のある攻撃の検知が可能ですが、ブロックはせず、検知のみです。 Google Cloud では Cloud IDS というサービスを提供しています。詳細は当社の記事で解説しています。 blog.g-gen.co.jp 検証の概要 前提 Cloud NGFW の IPS 機能を利用するためには、プロジェクトが組織（Organization）に所属している必要があります。 組織（Organization）の詳細は当社の記事で解説しているのでご参照ください。 blog.g-gen.co.jp 構成図 今回は、以下の構成図の環境で検証を行いました。 検証の流れ 検証の流れは、以下のとおりです。まず前半に、IPS の設定を「検知のみ」にし、ログ記録が行われることを確認します。後半では、実際に攻撃をブロックしたり、偽陽性トラフィックを明示的に許可する検証を行います。 検知の検証 IPS をセットアップ。拒否はせずに検知のみの設定とする クライアントから Web サーバーへ以下2パターンのアクセスを実施。Web サーバーからの応答があることを確認 パターン1 : テストファイル（EICAR）へアクセス パターン2 : /etc/passwd ディレクトリへアクセス ログを確認し、両パターンの通信が IPS で検知されていることを確認 ブロックの検証 検知したアクセスパターンを以下のように仮定する パターン1は誤検知（偽陽性）と仮定し、 明示的に許可 する パターン2は攻撃トラフィックでと仮定し、 拒否 する 重大度「中」以上の脅威（パターン2を含む）を検知した場合は「拒否」、パターン1のシグネチャを「許可」するように設定変更 再度 Web サーバーへのアクセスを試行。パターン2のみが「拒否」されることを確認 EICAR ファイル Compute Engine VM 上で Web サーバーを起動し、 EICAR ファイル （マルウェアの検出テスト用ファイル）を配置します。curl コマンドでその EICAR ファイルへのリクエストを実施することで、IPS の動作を確認します。 EICAR は無害なテキストファイルですが、各社のアンチウイルスソフト等でウイルスとして検知されるようになっています。Cloud NGFW の IPS 機能でも検知されるため、今回の検証に利用しました。 参考 : Eicar e.V. -  Institute for Computer Anti-Virus Research 検証環境の構築 セキュリティプロファイルの作成 本手順は、組織レベルで実施します。Google Cloud Web コンソールへログインし、対象の組織へ遷移します。 ネットワーク セキュリティ > 共通コンポーネント > セキュリティ プロファイルへ移動し、「プロファイルを作成」を押下します。 任意の名前を入力し「続行」を押下します。 各重大度のアクションを「アラート」に設定し、「作成」を押下します。本設定により、ブロックはせずに検知のみの設定となります。 選択可能なアクションについては、以下のドキュメントをご参照ください。 参考： 脅威防止のセキュリティ プロファイル セキュリティプロファイルグループの作成 本手順も、前項と同様に組織レベルで実施します。 ネットワーク セキュリティ > 共通コンポーネント > セキュリティ プロファイル > セキュリティ プロファイルグループ へ移動し、「プロファイル グループ作成」を押下します。 任意の名前を入力し、脅威防止プロファイルの箇所に前手順で作成した「セキュリティ プロファイル」を選択した上で「作成」を押下します。 ファイアウォールエンドポイントの作成 本手順も、前項と同様に組織レベルで実施します。 ネットワーク セキュリティ > Cloud NGFW > ファイアウォール エンドポイント へ移動し、「作成」を押下します。 以下項目を設定し、「続行」を押下します。 リージョンとゾーン：Webサーバ と同じ値を選択 名前：任意の値を入力 課金プロジェクト：対象のプロジェクトを選択 「エンドポイントの関連付けを追加」から IPS を導入するプロジェクトと VPC 名を選択し、「作成」を押下します。 作成には、20〜30分程度かかります。 ファイアウォール ポリシーの作成 本手順も、前項と同様に組織レベルで実施します。 ネットワーク セキュリティ > Cloud NGFW > ファイアウォール ポリシー へ移動し、「ファイアウォール ポリシー作成」を押下します。 任意のポリシー名を入力し、「続行」を押下します。 「ルールを追加」から、ファイアウォールルールを作成します。 優先度：一意の数値 一致したときのアクション：L7 の検査に進む（前手順で作成したセキュリティ プロファイルグループを選択） 送信元：IPv4、IP 範囲：0.0.0.0/0 「追加」を押下し、ファイアウォール ポリシーを適用する組織名を選択し、「追加」を押下します。 「作成」をクリックします。 攻撃検知の検証 パターン1（EICAR ファイル） テスト用の端末から curl コマンドを実行して、EICAR ファイルの取得を試行します。重大度のアクションが「アラート」のため、検知はされますが、実際の拒否は行われないのが想定される結果です。 $ curl -v http:// $TESTIP /eicar.com 〜省略〜 < X5O!P%@AP [ 4 \PZX54(P^)7CC) 7 } $EICAR -STANDARD-ANTIVIRUS-TEST-FILE ! $H +H* * Connection # 0 to host ***.***.***.*** left intact $ 対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、以下4点を確認します。 アラートの重大度が「MEDIUM」となっていること。 脅威の名前が「Eicar File Detected」となっていること。 脅威 ID（後続の手順で使用するため、メモしておきます。） アクションが「ALERT」となっていること。 パターン2（/etc/passwd ディレクトリ） 同様に curl コマンドを実行して、/etc/passwd ディレクトリへのアクセスを試行します。重大度のアクションが「アラート」のため、検知はされますが、実際の拒否は行われないのが想定される結果です。 $ curl -v http:// $TESTIP /etc/passwd 〜省略〜 < < !DOCTYPE HTML PUBLIC " -//IETF//DTD HTML 2.0//EN "> < html >< head > < title > 404 Not Found < /title > < /head >< body > < h 1> Not Found < /h 1> < p > The requested URL was not found on this server. < /p > < hr > < address > Apache/ 2 . 4 . 59 ( Debian ) Server at XX.XX.XX.XX Port 80 < /address > < /body >< /html > * Connection #0 to host XX.XX.XX.XX left intact $ 対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、以下3点を確認します。 アラートの重大度が「HIGH」となっていること。 脅威の名前が「HTTP /etc/passwd Access Attempt」となっていること。 アクションが「ALERT」となっていること。 ブロックの検証 IPS の設定変更 本手順は組織レベルで実施します。 ネットワーク セキュリティ > 共通コンポーネント > セキュリティ プロファイルへ移動し、前手順で作成したプロファイルを選択します。 「編集」から重大度「重大」「高」「中」のアクションを「拒否」へ変更し、「ID で署名を追加」を押下します。初回アクセス検証で確認した通り、パターン1（MEDIUM = 「中」）、パターン2（HIGH = 「高」）のため、この時点では両通信共に「拒否」されます。 本検証では重大度「低」「情報」に関しては、影響が小さいと判断し「アラート」のままとしていますが、実業務でどのような設定とするかは、以下ドキュメントをご参照の上で判断してください。 参考 : 脅威の重大度 初回アクセス検証「パターン1」で確認した脅威 ID を入力し、アクションを「許可」に設定し、「署名の追加」を押下します。 「保存」を押下します。 なお 署名 とは一般的に シグネチャ とも表現されます。シグネチャは、脆弱性、スパイウェア、ウイルス、特定の DNS クエリなどを検知するためのルールのことです。 以下ドキュメントの通り、署名に対するアクションは重大度のアクションよりも優先されるため、上記の設定を追加することでパターン1が「許可」されます。偽陽性となった特定のシグネチャを無視する際に、本機能を利用できます。 脅威 ID の一覧は、Palo Alto Networks 社のサイト「 Threat Vault 」へログインすることで確認可能です。同サイトでは、特定の CVE 番号に関連する脅威 ID の検索等も可能です。同サイトを利用するには、別途 Palo Alto Networks のアカウント作成が必要となります。これは、Cloud NGFW の IPS 機能が、バックエンドで Palo Alto 社の技術を利用していることに起因します。 参考： 脅威シグネチャの概要 参考： Threat Vault パターン1（EICAR ファイル） テスト用の端末から curl コマンドを実行して、EICAR ファイルの取得を試行します。重大度「中（MEDIUM）」のアクションを「拒否」に変更していますが、脅威 ID を「許可」に設定しているため、 ブロックされず 、 ログも記録されない のが想定結果です。 $ curl -v http:// $TESTIP /eicar.com 〜省略〜 < X5O!P%@AP [ 4 \PZX54(P^)7CC) 7 } $EICAR -STANDARD-ANTIVIRUS-TEST-FILE ! $H +H* * Connection # 0 to host ***.***.***.*** left intact $ 対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、検証時のログが存在しないことを確認します。 パターン2（/etc/passwd ディレクトリ） 同様に curl コマンドを実行して、/etc/passwd ディレクトリへのアクセスを試行します。重大度「HIGH（高）」のアクションを「拒否」に変更しているため、拒否されるのが想定結果です。 もし Web サーバーから 404エラー等の応答があった場合、設定の反映に時間がかかっている可能性があるため、5〜10分程度、時間を空けて再実行してください。 $ curl -v http:// $TESTIP /etc/passwd 〜省略〜 > * Recv failure: Connection reset by peer * Closing connection 0 curl: ( 56 ) Recv failure: Connection reset by peer $ 対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、以下3点を確認します。 アラートの重大度が「HIGH」となっていること。 脅威の名前が「HTTP /etc/passwd Access Attempt」となっていること。 アクションが「DROP」となっていること。 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。オンプレ中心のネットワークエンジニアからクラウドエンジニアへ移行。日々勉強中です・・・