G-gen の杉村です。Google Cloud のトラブルシューティング AI エージェントである Gemini Cloud Assist Investigations について解説します。 Gemini Cloud Assist Investigations とは 調査開始できる画面 調査の例 Cloud Logging ログエクスプローラー Cloud Monitoring アラート Cloud Assist Investigations 利用準備 対応サービス 注意点 Gemini Cloud Assist Investigations とは Gemini Cloud Assist Investigations は、Google Cloud のトラブルシューティングを行う AI エージェントです。Google Cloud コンソール上で、Cloud Logging のログエクスプローラーや Cloud Monitoring アラートといった画面に表示される「調査」ボタンを押下するだけで、生成 AI が様々な要素を考慮に入れてトラブルの原因を調査し、原因や対策の提案をしてくれます。日本語ドキュメントでは「Cloud Assist の調査」と表記されることもあります。 当機能が行う調査は root-cause analysis（RCA、根本原因分析）と呼ばれ、ログ等の表面上から読み取れる情報だけでなく、設定情報やモニタリング指標など、さまざまな要素を統合してトラブルの原因を突き止めるものです。 対応サービスは BigQuery、Compute Engine、VPC、Cloud Run など多岐に渡ります。 参考 : Cloud Assist の調査に関するトラブルシューティング 参考 : 推測にとどまらず、徹底的に調べましょう。Gemini Cloud Assist で根本原因分析が利用可能に 2025年9月現在、当機能は Preview 中であり、料金は発生しません。また、調査結果は現在のところ英語で出力されます。 参考 : Preview版のサービスを使うとはどういうことなのか - G-gen Tech Blog 調査開始できる画面 Gemini Cloud Assist Investigations の調査は、Google Cloud コンソールの以下の画面から開始できます。 No 画面 手順 1 Cloud Assist Investigations コンソール上部の検索ボックスで Cloud Assist Investigations と入力し、専用の画面へ遷移。 + Create ボタンから新しい調査を作成。発生した事象を自然言語で入力することで、調査を開始できる 2 Cloud Logging ログエクスプローラー Cloud Logging のログエクスプローラー画面で、対応サービスに関連するエラーログのログエントリを展開し「調査」ボタンを押下して調査を開始 3 Cloud Monitoring アラート Cloud Monitoring アラートのアラート詳細画面で、対応サービスであれば表示される「調査」ボタンを押下して調査を開始 4 Gemini Cloud Assist チャットパネル Gemini Cloud Assist チャットパネルの右上の3点リーダーから「New Investigation」を押下して新しい調査を作成。発生した事象を自然言語で入力することで、調査を開始できる 5 Cloud Hub Cloud Hub の「健全性とトラブルシューティング」ページに表示される「調査を作成」ボタンを押下 6 特定のプロダクトページ内 対応サービスの場合、コンソール画面から調査を開始できる 調査の例 Cloud Logging ログエクスプローラー 以下のスクリーンショットは、Cloud Logging ログエクスプローラーから開始した、Gemini Cloud Assist Investigations の調査結果の例です。 ログエクスプローラーからの調査 Cloud Logging のログエクスプローラーで「調査」ボタンを押すと、1分ほどで Cloud Storage バケットへのアクセスが拒否されたエラーログの原因や、推奨される対策が表示されました。 バケットへのアクセスが拒否された原因として、IAM 権限の不足を示唆しており、解決方法として gcloud コマンドなどで IAM ロールをアカウントに付与することを提案しています。 Cloud Monitoring アラート オープンした Cloud Monitoring アラートのインシデント画面からも、調査を開始できます。 以下は、Cloud Monitoring アラート（ログベースのアラート）により発報したインシデントの画面です。「調査」ボタンを押すと、数分後に結果が表示されました。 Cloud Monitoring アラートのインシデント画面 調査結果の表示 Cloud Assist Investigations Cloud Assist Investigations の専用画面からも、調査を開始できます。この画面からの調査の場合、発生した事象をユーザーが自然言語で入力すると、それに基づいて AI が調査を行います。 新規調査の作成 このとき、トラブルが起きた時に行った操作や、表示されたエラーメッセージなどを、できるだけ詳細に書くことが望ましいです。また、トラブルの開始時刻や終了時刻も設定することで、AI による調査に役立ちます。 1分ほどの調査のあと、以下のように結果が出力されました。 調査結果の表示 利用準備 Cloud Assist Investigations の使用の前提として、プロジェクトで以下の API が有効化されている必要があります。 cloudaicompanion.googleapis.com cloudasset.googleapis.com cloudresourcemanager.googleapis.com geminicloudassist.googleapis.com logging.googleapis.com （推奨） monitoring.googelapis.com （推奨） また、調査を開始する操作者は、プロジェクトに対して、以下のロールが必要です。 Gemini Cloud Assist Investigation 作成者（ベータ版）（ roles/geminicloudassist.investigationCreator ） 他にも、以下のようなロールで代替することができます。 オーナー（ roles/owner ） Gemini Cloud Assist Investigation 管理者（ベータ版）（ roles/geminicloudassist.investigationAdmin ） 対応サービス 以下は、2025年9月現在の Gemini Cloud Assist Investigations の対応サービスです。 App Hub Cloud SQL Cloud Storage Compute Engine Google Kubernetes Engine Cloud Networking Cloud Run Dataproc on Compute Engine Google Cloud Serverless for Apache Spark Pub/Sub BigQuery Bigtable Cloud Composer Dataflow Spanner Memorystore for Redis Identity and Access Management Cloud Quotas 注意点 Gemini Cloud Assist Investigations は、生成 AI が調査を行い、さまざまな情報を総合して原因の推察や解決方法の提案を生成する仕組みです。 生成 AI の出力結果は常に正しいとは限らず、誤った情報を生成することもあります。例えば、存在しない組織のポリシーの制約を挙げて原因であると推察する、などの事象があり得ます。AI の出力結果を完全に信じるのではなく、人間の技術者による調査をあわせてトラブルの原因をつきとめ、対処を行ってください。 特に、環境に変更を与える可能性のある設定変更やコマンドラインの提案を受けた場合は、実行する前に、十分に人間による確認と調査を行うことが推奨されます。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では Google Cloud のジョブ自動化サービスである Workflows のユースケースとして、実行周期の異なる2つのジョブを、同一のワークフローに並列配置する方法を解説します。 はじめに Workflows とは 当記事の構成 Cloud Run ジョブの作成 使用するコード Cloud Run ジョブのデプロイ ワークフローの定義 シンプルな並列実行ワークフローの作成 ワークフロー定義 ワークフローの作成 動作確認 周期の異なる並列実行ワークフローの作成 ワークフロー定義 ワークフローの作成 動作確認 Cloud Scheduler ジョブの作成 作成するジョブ（スケジューラ）について スケジューラの作成 動作確認 はじめに Workflows とは Workflows（Cloud Workflows）は Google Cloud のジョブ自動化サービスであり、ユーザーが定義したワークフローをフルマネージドかつサーバーレスな環境で実行できるサービスです。 Workflows の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp 当記事の構成 当記事では、1つのワークフローで3つの Cloud Run jobs を実行する構成を想定します。Cloud Run jobs の各ジョブはジョブ A、ジョブ B、ジョブ C とします。 このワークフローでは、まずジョブ A が処理を行い、その後ジョブ B とジョブ C が別々に実行されます。それぞれがジョブ A の処理結果に対して異なる処理を行います。 ポイントとして、ここでは ジョブ B、ジョブ C の処理にはジョブ A の最新の実行結果が必要 という要件を想定しています。例えば、ジョブ A がデータベースから情報を取得し、加工した結果を Cloud Storage バケットに格納するようなケースです。ジョブ B、ジョブ C はそれぞれジョブ A の結果を取得して、何かしらの処理を行います。 当記事で想定している構成の例 そして、 ジョブ B は30分周期、ジョブ C は60分周期で実行しなければならない とします。したがって、ワークフロー全体は30分おきに実行されますが、60分周期のジョブ C は2回のワークフロー実行のうち1回だけ処理を行うようにする必要があります。 これを実現するために、実際の構成は以下のようにします。 2つのスケジューラからワークフローを実行し、スケジューラから渡される引数でジョブ C の実行要否を判定する この構成では、2つの Cloud Scheduler ジョブからワークフローを実行しています。ワークフローは、どちらのスケジューラから実行されたかを区別できる情報を引数として受け取ります。この引数を元に、60分周期のジョブ C を実行するかどうかを判定します。 Cloud Run ジョブの作成 使用するコード 先ほどは Cloud Storage を使用してデータのやり取りをするケースを例に挙げましたが、当記事ではワークフロー定義の方法を解説するため、各 Cloud Run ジョブの具体的な実装は省略します。 ジョブが2つのスケジューラのどちらから実行されたかを明確にするため、スケジューラからワークフローに渡された引数を、ジョブの環境変数として受け取ってログ出力します。 // 環境変数の値をログ出力するジョブ（main.go） package main import ( "log" "os" ) func main() { name := os.Getenv( "NAME" ) // 環境変数からジョブ名を取得 schedule := os.Getenv( "SCHEDULE" ) // 環境変数から実行周期を取得 log.Printf( "%s: %s \n " , name, schedule) // ログに出力 } Cloud Run jobs には、ジョブに設定した環境変数をオーバーライドしてからジョブ実行する機能があります。これを利用して、ジョブの実行ごとに、スケジューラからワークフローに渡された引数を環境変数で受け取ります。 参考 : Cloud Run jobsでジョブ構成をオーバーライドしてジョブを実行する - G-gen Tech Blog Cloud Run ジョブのデプロイ 3つのジョブ（A、B、C）をデプロイします。当記事ではジョブの詳細な実装は行わないため、同じコードを使用してそれぞれのジョブを作成します。 当記事ではコンテナイメージを事前に用意せず、ソースコードからジョブをデプロイします。 コードが存在するディレクトリ上で以下のコマンドを実行します。 # ジョブ A の作成 $ gcloud run jobs deploy wf-job-a \ --region asia-northeast1 \ --source . \ --set-env-vars = NAME = " wf-job-a " , SCHEDULE = "" # ジョブ B の作成 $ gcloud run jobs deploy wf-job-b \ --region asia-northeast1 \ --source . \ --set-env-vars = NAME = " wf-job-b " , SCHEDULE = "" # ジョブ C の作成 $ gcloud run jobs deploy wf-job-c \ --region asia-northeast1 \ --source . \ --set-env-vars = NAME = " wf-job-c " , SCHEDULE = "" 各ジョブに設定する SCHEDULE 環境変数は、ワークフローから値をオーバーライドするため空にしておきます。 参考 : gcloud run jobs deploy ワークフローの定義 シンプルな並列実行ワークフローの作成 ワークフロー定義 まずは、周期のズレを考慮せずに、ジョブ A を実行したあとジョブ B とジョブ C を単純に並列実行するワークフローを作成してみます。 wf-parallel.yaml として、以下の内容でワークフロー定義ファイル（YAML 形式）を作成します。 # wf-parallel.yaml # ジョブAの実行後にジョブB、ジョブCを並列実行するワークフロー main : params : [ args ] steps : - define_common_variables : assign : - project_id : ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")} # プロジェクトIDを取得して共通変数に設定 - location : "asia-northeast1" - results : [ "" , "" , "" ] - run_job_A : call : googleapis.run.v1.namespaces.jobs.run args : name : ${"namespaces/" + project_id + "/jobs/" + "wf-job-a" } # ジョブAの名前を指定 location : ${location} result : job_A_result - set_result_a : assign : - results[ 0 ] : ${job_A_result.metadata.name} - run_jobs_B_and_C_in_parallel : parallel : # 並列実行するジョブを定義 shared : [ results ] branches : - run_job_B_branch : # ジョブBを実行するブランチ steps : - call_job_B : call : googleapis.run.v1.namespaces.jobs.run args : name : ${"namespaces/" + project_id + "/jobs/" + "wf-job-b" } # ジョブBの名前を指定 location : ${location} result : job_B_result - set_result_b : assign : - results[ 1 ] : ${job_B_result.metadata.name} - run_job_C_branch : # ジョブCを実行するブランチ steps : - call_job_C : call : googleapis.run.v1.namespaces.jobs.run args : name : ${"namespaces/" + project_id + "/jobs/" + "wf-job-c" } # ジョブCの名前を指定 location : ${location} result : job_C_result - set_result_c : assign : - results[ 2 ] : ${job_C_result.metadata.name} - finalStep : return : job_A_execution : ${results[ 0 ]} job_B_execution : ${results[ 1 ]} job_C_execution : ${results[ 2 ]} ワークフローの作成 以下のコマンドでワークフローを作成します。 --source には先ほど作成したワークフロー定義ファイルを指定します。 $ gcloud workflows deploy wf-parallel \ --location = asia-northeast1 \ --source = ./wf-parallel.yaml 作成したワークフローは以下のような構成になります。 ジョブB、ジョブCを同じ周期で並列実行するワークフロー 参考 : gcloud workflows deploy 動作確認 ワークフローを手動で実行してみます。このワークフローではジョブ A の実行後にジョブ B、ジョブ C が並列実行され、それぞれのジョブの ID（Cloud Run jobs の実行 ID）が最終的に出力されます。 ワークフローを手動実行した結果 周期の異なる並列実行ワークフローの作成 ワークフロー定義 それでは本題として、実行周期の異なる2つのジョブ（B、C）を並列配置するワークフローを定義します。 wf-parallel-diff-cycles.yaml として、以下の内容でワークフロー定義ファイル（YAML 形式）を作成します。 # wf-parallel-diff-cycles.yaml # ジョブAの実行後にジョブB、ジョブCを並列実行するワークフロー # 引数scheduleの値によってジョブCを実行しない場合がある main : params : [ args ] steps : - define_common_variables : assign : - project_id : ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")} # プロジェクトIDを取得して共通変数に設定 - location : "asia-northeast1" - results : [ "" , "" , "" ] - run_job_A : call : googleapis.run.v1.namespaces.jobs.run args : name : ${"namespaces/" + project_id + "/jobs/" + "wf-job-a" } # ジョブAの名前を指定 location : ${location} body : overrides : # オーバーライドするジョブ環境変数 containerOverrides : - env : - name : "SCHEDULE" value : ${args.schedule} # ワークフロー実行時に渡されたschedule引数を受け取る result : job_A_result - set_result_a : assign : - results[ 0 ] : ${job_A_result.metadata.name} - run_jobs_B_and_C_in_parallel : parallel : # 並列実行するジョブを定義 shared : [ results ] branches : - run_job_B_branch : # ジョブBを実行するブランチ steps : - call_job_B : call : googleapis.run.v1.namespaces.jobs.run args : name : ${"namespaces/" + project_id + "/jobs/" + "wf-job-b" } # ジョブBの名前を指定 location : ${location} body : overrides : # オーバーライドするジョブ環境変数 containerOverrides : - env : - name : "SCHEDULE" value : ${args.schedule} # ワークフロー実行時に渡されたschedule引数を受け取る result : job_B_result - set_result_b : assign : - results[ 1 ] : ${job_B_result.metadata.name} - run_job_C_branch : # ジョブCを実行するブランチ steps : - conditional_run_of_job_c : switch : # schedule引数の値によってジョブCを実行するかどうかを判定する - condition : ${args.schedule=="00"} # schedule引数の値が"00"の場合のみジョブCを実行する steps : - call_job_C : call : googleapis.run.v1.namespaces.jobs.run args : name : ${"namespaces/" + project_id + "/jobs/" + "wf-job-c" } # ジョブCの名前を指定 location : ${location} body : overrides : # オーバーライドするジョブ環境変数 containerOverrides : - env : - name : "SCHEDULE" value : ${args.schedule} # ワークフロー実行時に渡されたschedule引数を受け取る result : job_C_result - set_result_c : assign : - results[ 2 ] : ${job_C_result.metadata.name} - finalStep : return : job_A_execution : ${results[ 0 ]} job_B_execution : ${results[ 1 ]} job_C_execution : ${if(results[ 2 ] == "" , "SKIPPED" , results[ 2 ])} # ジョブCを実行しなかった場合は"SKIPPED"を返す このワークフローでは、ワークフロー実行時の引数として schedule をキーとする値を受け取り、ジョブ C の実行ブランチで switch 文を使うことで、 schedule の値によってジョブ C を実行するかどうかを判定します。ここでは値が 00 のときだけジョブ C を実行するように定義しています。 また、当記事では schedule の値を Cloud Run ジョブの環境変数にオーバーライドし、ジョブ内でその値を処理できるようにしています。 ワークフローの作成 以下のコマンドでワークフローを作成します。 --source には新たに作成したワークフロー定義ファイルを指定します。 $ gcloud workflows deploy wf-parallel-diff-cycles \ --location = asia-northeast1 \ --source = ./wf-parallel-diff-cycles.yaml 作成したワークフローは以下のような構成になります。ジョブ C 側のブランチで、ジョブ C 実行（ call_job_C ）の前に switch による分岐ができています。 並列配置されたジョブB、ジョブCを異なる周期で実行できるワークフロー 動作確認 こちらのワークフローも手動で実行してみます。 まず、ジョブ A の実行後にジョブ B とジョブ C を並列実行するパターンを試します。以下の入力をワークフローに渡して処理を実行します。 { " schedule ": " 00 " } ジョブ B とジョブ C を並列実行するパターンのワークフロー実行 ジョブA の実行後にジョブB とジョブ C が並列で実行され、それぞれのジョブの ID（Cloud Run jobs の実行 ID）が最終的に出力されています。 ジョブ B とジョブ C が並列実行されている 次に、以下の入力でワークフローを実行してみます。 schedule 引数の値が 00 ではないため、ジョブ C の実行がスキップされる想定です。 { " schedule ": " 30 " } ワークフローを実行すると、ジョブ A の実行後にジョブ B が実行されますが、ジョブ C はスキップされていることがわかります。ジョブ C はスキップされたため、ワークフロー出力にはジョブ ID の代わりに SKIPPED という文字列を出力しています。 ジョブ B は実行されるが、ジョブ C がスキップされている Cloud Scheduler ジョブの作成 作成するジョブ（スケジューラ）について Cloud Scheduler を使用して、ワークフローを定期的にトリガーするジョブ（Cloud Run ジョブと区別するため以降は スケジューラ と記載）を作成します。 想定している要件ではジョブ B を30分周期、ジョブ C を60分周期で実行しなければならないため、ワークフローをトリガーする周期を調整した2つのスケジューラを作成します。 スケジューラ名 トリガー周期 ワークフローに渡す引数 ワークフローで実行される Cloud Run ジョブ wf-trigger-every-00m 毎時0分 {"schedule": "00"} ジョブA、ジョブB、ジョブC wf-trigger-every-30m 毎時30分 {"schedule": "30"} ジョブA、ジョブB この2つのスケジューラは1時間おきに実行されますが、それぞれ毎時0分、毎時30分に実行されます。したがって、ワークフローは30分に1回実行されることになります。 ジョブ C の実行要否を判断する引数をスケジューラからワークフローに渡すことで、 毎時0分のワークフローではジョブ C を実行し、毎時30分のワークフローではジョブ C をスキップします。 これにより、ジョブ B を30分周期で実行しつつ、同じワークフロー上のジョブ C を60分周期で実行することができます。 毎時0分のワークフロー実行ではジョブ B、ジョブ C ともに実行される 毎時30分のワークフロー実行ではジョブ C が実行されない スケジューラの作成 以下のコマンドで、ワークフローを呼び出すスケジューラを2つ作成します。当記事ではスケジューラに紐づけるサービスアカウントとして Compute Engine のデフォルトのサービス アカウント を使用していますが、本番運用する場合はワークフローの実行権限のみ付与したカスタムサービスアカウントの使用を推奨します。 # 毎時0分に実行されるスケジューラ $ gcloud scheduler jobs create http wf-trigger-every-00m \ --location = asia-northeast1 \ --schedule =" 0 * * * * " \ --uri =" https://workflowexecutions.googleapis.com/v1/projects/<プロジェクトID>/locations/asia-northeast1/workflows/wf-parallel-diff-cycles/executions " \ --message-body =" { \" argument \" : \" { \\\" schedule \\\" : \\\" 00 \\\" } \" } " \ --time-zone =" Asia/Tokyo " \ --oauth-service-account-email =" <プロジェクト番号>-compute@developer.gserviceaccount.com " # 毎時30分に実行されるスケジューラ $ gcloud scheduler jobs create http wf-trigger-every-30m \ --location = asia-northeast1 \ --schedule =" 30 * * * * " \ --uri =" https://workflowexecutions.googleapis.com/v1/projects/<プロジェクトID>/locations/asia-northeast1/workflows/wf-parallel-diff-cycles/executions " \ --message-body =" { \" argument \" : \" { \\\" schedule \\\" : \\\" 30 \\\" } \" } " \ --time-zone =" Asia/Tokyo " \ --oauth-service-account-email =" <プロジェクト番号>-compute@developer.gserviceaccount.com " 参考 : Schedule a workflow using Cloud Scheduler 参考 : gcloud scheduler jobs create 参考 : Service accounts - Compute Engine default service account 動作確認 Cloud Run ジョブのコードは、以下のようにジョブの名前とスケジューラからワークフローに渡された schedule 引数をログ出力するように実装されています。 // main.go 抜粋 func main() { name := os.Getenv( "NAME" ) // 環境変数からジョブ名を取得 schedule := os.Getenv( "SCHEDULE" ) // 環境変数から実行周期を取得 log.Printf( "%s: %s \n " , name, schedule) // ログに出力 } Cloud Logging でジョブ B、ジョブ C のログ出力を確認することで、30分周期（毎時0分と毎時30分）でジョブ B が、60分周期（毎時0分）でジョブ C が実行されていることを確認できます。 ジョブ B が30分周期で実行されている（schedule 引数が "00" と "30" のとき） ジョブ C が60分周期で実行されている（schedule 引数が "00" のとき） 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では、Spanner で利用することができる Google Cloud 提供の サンプルデータセットを紹介します。 Spanner とは Spanner のサンプルデータセット サンプルデータセットの種類 Spanner エディションによる違い サンプルデータセットを使用する Spanner インスタンスの準備 サンプルデータセットの作成 サンプルクエリ Spanner とは Spanner は、Google Cloud のフルマネージド RDB（リレーショナルデータベース）サービスです。強整合性を保証する RDB の特徴と、グローバルに水平スケーリングできる NoSQL データベースの特徴を併せ持つ、強力な分散データベースを利用することができます。 参考 : Spanner Spanner の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp Spanner のサンプルデータセット サンプルデータセットの種類 Spanner では、通常の SQL クエリやグラフデータベース機能である Spanner Graph 、および 全文検索 機能を手軽に試すことができるサンプルのデータセットが提供されています。 サンプルデータセットは、Spanner のコンソール画面から数クリックで Spanner インスタンス上のデータベースとしてインポートすることができます。 2025年9月現在、4種類のデータセットがサンプルとして提供されています。 サンプルデータセット名 作成されるデータベース名 説明 Finance graph finance-graph Spanner Graph を試すための架空の財務データ Online banking banking 全文検索機能を試すための架空の銀行データ Online gaming gaming 架空のオンラインゲームのデータ Retail retail Spanner Graph と全文検索機能を試すための架空の e コマースデータ 利用可能なサンプルデータセット 参考 : Create and manage databases - Use a sample dataset 参考 : Spanner Graph overview 参考 : Full-text search overview Spanner エディションによる違い Spanner は Spanner エディション というティアベースの料金モデルを採用しており、Standard、Enterprise、Enterprise Plus の3つのエディションが提供されています。 利用するエディションは Spanner インスタンスごとに設定することができ、エディションによってそのインスタンスで利用できる機能が決まります。 Spanner Graph および全文検索は Standard エディションでは利用できない機能のため、全てのサンプルデータセットを利用したい場合、 Enterprise エディション以上 の Spanner インスタンスを利用する必要があります。 以下は Spanner のエディションと利用できるサンプルデータセットの対応表です。 Standard Enterprise Enterprise Plus Finance graph × ○ ○ Online banking × ○ ○ Online gaming ○ ○ ○ Retail × ○ ○ 参考 : Spanner editions overview サンプルデータセットを使用する Spanner インスタンスの準備 サンプルデータセットを使用するために、Spanner のインスタンスを作成します。すべてのサンプルデータセットを使用したい場合は Enterprise エディション以上のインスタンスを作成してください。 エディションはインスタンス作成後でもアップグレード/ダウングレードすることが可能です。 すべてのサンプルデータセットを使用したい場合は Enterprise エディション以上のインスタンスを作成する 参考 : Create and manage instances サンプルデータセットの作成 サンプルデータセットを作成するには、Spanner インスタンスの概要画面から [Explore dataset] を選択します。 サンプルデータセットは [Explore dataset] から作成可能 作成したいサンプルデータセットを選択し、 [Create database] でデータベースを作成します。 作成したいサンプルデータセットを選択して [Create database] を押下する インスタンスが Standard エディションの場合、使用できないデータセットを作成しようとするとデータベースの作成に失敗します。 Spanner Graph 機能を使うサンプルデータセットのインポートに失敗した場合のエラーメッセージ Unable to create Spanner database - Feature GRAPH is not available to Instance projects/myproject/instances/sample, in Edition STANDARD. The minimum required Edition for this feature is ENTERPRISE. Please refer documentation for additional information. 全文検索機能を使うサンプルデータセットのインポートに失敗した場合のエラーメッセージ Unable to create Spanner database - Feature FULL_TEXT_SEARCH is not available to Instance projects/myproject/instances/sample, in Edition STANDARD. The minimum required Edition for this feature is ENTERPRISE. Please refer documentation for additional information. サンプルクエリ 各サンプルデータセットには、Spanner Studio から利用できるサンプルの 保存したクエリ（Saved queries） が用意されています。 データセットごとに、そのデータセットで利用できる機能のサンプルクエリが提供されています。以下のスクリーンショットでは、Retail データセットで Spanner Graph と全文検索のサンプルクエリを実行しています。 Retail データセットのサンプルクエリで Spanner Graph のクエリを実行する Retail データセットのサンプルクエリで全文検索を実行する 参考 : Create and manage saved queries 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の荒井です。当記事では Microsoft Outlook デスクトップ版から Google Workspace Migration for Microsoft Outlook （GWMMO）を使用し、Outlook のデータ移行をする方法についてご紹介します。 はじめに 概要 GWMMO とは 対象者 システム要件 移行できるデータ 移行手順 手順1 : GWMMO のダウンロード 手順2 : GWMMO のインストール 手順3 : Outlook データのバックアップ 手順4 : GWMMO の実行（認証） 手順5 : GWMMO の実行（データ移行） 2回目以降の増分メール移行作業 はじめに 多くの企業や官公庁では、Microsoft Outlook をメールだけでなく、カレンダーや連絡先の管理にも利用しています。Google Workspace へ移行する際、これらの過去データを引き継ぐことは、環境変化による業務効率の低下を防ぐうえで非常に重要です。 当記事では、Google Workspace Migration for Microsoft Outlook（GWMMO）を使用して Outlook のデータを Google Workspace に移行する手順を解説します。 概要 GWMMO とは Google Workspace Migration for Microsoft Outlook （以下、 GWMMO ）とは、Microsoft Outlook（以下、Outlook）のメール、カレンダー予定、連絡先などを Outlook アカウントまたは PST ファイルから Google Workspace アカウントに移行するための自動化ツールです。 GWMMO は Google によって公式に提供されており、実行可能なアプリケーションとして配布されています。管理者が一括で移行作業を行えるわけではなく、各ユーザーがツールをダウンロードして、データの移行作業を行います。 参考 : Outlook のコンテンツを Google Workspace に移行する - Google Workspace ラーニング センター 対象者 GWMMO を使用してデータ移行ができるのは、以下の両方に当てはまるユーザーです。 Outlook から Google Workspace にデータ移行を行いたい 後述するシステム要件を満たしている 移行作業は、 Outlook を使用しているユーザー自身で行い ます。 アプリケーションインストールの際に管理者権限を要求された場合、自社内のシステム担当者に設定を依頼してください。 システム要件 GWMMO は、以下の Windows OS および Outlook をサポートしています。 Windows OS 32 ビット版または 64 ビット版の Windows 10、11 Outlook 32 ビット版または 64 ビット版の Outlook 2016、2019、2021 Microsoft 365 デスクトップ アプリの Outlook（Web 版は対象外） 詳細は公式ドキュメントに記載があり、Windows や Office のサポート期限に伴い更新されるため、最新情報はドキュメントをご確認ください。 参考 : GWMMO の概要 - Google Workspace ラーニング センター 移行できるデータ GWMMO で移行できるデータは、主に Outlook に存在する以下のデータです。 メール、カレンダー、連絡先（すべて一度に移行、または段階的に移行） 特定の日付の前または後に送信されたメール その他詳細な仕様は、公式ドキュメントをご確認ください。 参考 : 移行されるデータ - Google Workspace ラーニング センター 移行手順 手順1 : GWMMO のダウンロード 1-1. https://tools.google.com/dlpage/gsmmo にアクセスして、インストーラーをダウンロードします。 手順2 : GWMMO のインストール 2-1. ダウンロードしたインストーラー「OutlookMigrationSetup.exe」を実行します。 2-2. インストーラー実行後は自動でインストールが始まります。 2-3. インストールが完了したら [閉じる] をクリックしてインストーラーを終了します。 手順3 : Outlook データのバックアップ 3-1. Outlook を起動し [ファイル] をクリックします。 3-2. [開く/エクスポート] > [インポート/エクスポート] をクリックします。 3-3. [ファイルにエクスポート] > [次へ] をクリックします。 3-4. [Outlook データファイル（.pst）] > [次へ] をクリックします。 3-5. 移行対象のアカウントを選択します。特定のフォルダごと移行する場合は、対象のフォルダを選択します。 サブフォルダーもすべて移行する場合、 [サブフォルダーを含む] のチェックを有効にし [次へ] をクリックします。 3-6. [参照] から保存先およびファイル名を設定し、[完了] をクリックします。 3-7. パスワードを設定し、[OK] をクリックします。 [重要] 設定したパスワードは後ほど使用するため、控えておいてください。 3-8. 手順 3-7 で控えたパスワードを入力し、[OK] をクリックします。 以上で、Outlook データのバックアップは完了です。 詳細な内容や最新の手順は、以下 Microsoft 公式ドキュメントをご参照ください。 参考 : Outlook メールをバックアップする - Microsoft サポート 手順4 : GWMMO の実行（認証） 4-1. インストールした「Google Workspace Migration for Microsoft Outlook®」を起動します。 4-2. ログイン画面が表示されるので、移行先 Google アカウントのメールアドレスを入力し [続行] をクリックします。 4-3. Web ブラウザが起動するため、移行先アカウントで認証を行います。 4-3-1. ブラウザで Google アカウントにログインしていない場合 自身の Google アカウントで認証を行います。 4-3-2. ブラウザで Google アカウントにログインしている場合 自身のアカウントを選択します。 4-4. GWMMO へのログイン確認ページで内容を確認し [次へ] をクリックします。 4-5. Google アカウントへのアクセスリクエストの内容を確認し [許可] をクリックします。 4-6. 認証が完了したら、Web ブラウザは終了して構いません。 手順5 : GWMMO の実行（データ移行） 5-1. [PST ファイルから..] を選択し「手順3 : Outlook データのバックアップ」で作成した PST ファイルを参照します。 [すべてのデータを移行] をチェックし [次へ] をクリックします。 5-2. 移行したいデータを選択し [移行] をクリックします。 5-3. 手順 3-7 で設定したパスワードを入力 ※ 手順 3-7 で「パスワードをパスワード一覧に保存」のチェックが有効になっている場合、当手順は省略される場合があります。 5-4. データ移行が始まります。 5-5. 「移行が完了しました」と表示されたら [OK] をクリックします。 5-6. 移行ステータス画面を [閉じる] をクリックします。 5-7. Gmail など Google Workspace サービスにアクセスし、データが移行されているか確認します。 移行されたメールデータには、ラベル（PST ファイル名）が付与されます。受信トレイはスキップして移行されるため、「すべてのメール」もしくは「ラベル」を選択してメールデータの確認をします。 2回目以降の増分メール移行作業 メールデータ移行実施後に送受信したメールを移行する場合（増分移行）、以下の要領で再度、移行を行うことができます。 「手順3 : Outlook データのバックアップ」以降の手順を再度実施します。 手順3-6 で、初回エクスポートした PST ファイルに上書き保存します。 手順5-1 で、上書きした PST ファイルを選択し「新しいデータのみを移行」を選択し手順を進めます。 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 ・Google Cloud 認定資格 7冠 最近ハマっていることは、息子とのポケモンカード Follow @arapote_tweet

Google Cloud プロダクトを中心としたセキュリティオペレーション担当者向けの認定資格である Professional Security Operations Engineer 試験について、合格に向けて役立つ情報をご紹介します。 試験情報 PSOE 試験とは 難易度 他の認定試験との違い 出題範囲と傾向 PSOE 試験の学習コンテンツ 英単語の読み方 SIEM、SOAR、CNAPP SIEM、SOAR、CNAPP とは セキュリティフレームワークにおける各々の役割 Security Information and Event Management（SIEM） Security Orchestration, Automation, and Response（SOAR） Google Security Operations（Google SecOps） Cloud-Native Application Protection Platforms（CNAPP） Security Command Center (SCC) アタックサーフェスとゼロ・トラスト アタックサーフェス（Attack Surface） ゼロ・トラスト（Zero Trust） 脅威ハンティング 脅威ハンティングと MITRE ATT&CK Actor と IoC Mandiant と Google Threat Intelligence（GTI） レトロハンティング その他のセキュリティ製品 VirusTotal サードパーティ製品 インシデントレスポンス SecOps 文脈でのオブザーバビリティ オブザーバビリティとセキュリティ サイレントソース検知（silent source detection） Google SecOps の詳細 パーサーと UDM パーサーの種類と拡張 サードパーティからのログ取り込み インテリジェンスとアラート YARA-L ルール IAM によるアクセス制御 その他に知っておくべき概念 試験情報 PSOE 試験とは Professional Security Operations Engineer 試験（以下、PSOE）は、セキュリティオペレーションの知識を問う Google Cloud 認定資格です。2025年7月〜8月にベータ試験が公開され、2025年9月に GA（一般公開）となりました。 Google ならびに Google Cloud が持つセキュリティオペレーション製品、特に Google Security Operations（略称 Google SecOps）と Security Command Center（SCC）を中心に、 攻撃の検知や防衛・対応に関する技術的な知識 から インシデント管理の体制 に関するものまで、包括的に問われる試験です。開発者向けというよりは、セキュリティオペレーションセンター（SOC）やネットワークオペレーションセンター（NOC）、また情報システム部のセキュリティ部門に所属しているような、セキュリティ対応を主な役割とするエンジニア向けの試験となっています。 他のプロフェッショナル資格と同じく、試験時間は120分、問題数は50〜60問の選択式です。認定の有効期間は2年間です。 当試験は、2025年9月時点で 英語版のみ が提供されています。 参考 : Professional Security Operations Engineer 難易度 PSOE 試験の難易度は、Google Cloud 認定資格の中でも 比較的高い といえます。 公式ガイドでは「3年以上のセキュリティ業界経験」「1年以上の Google Cloud におけるセキュリティツール群の利用経験」が求められると記載されています。当試験で中心的に扱われる Google のセキュリティ製品は有償のものが多く、またある程度の規模感をもつ組織でないと導入されない性質です。これらの製品を普段から業務で扱っているエンジニアは少なく、またインターネット上に情報が豊富に公開されていないことが、当試験を難しくしています。 また2025年9月現在、当試験は日本語で受験できないこともあり、セキュリティ分野に特有の英単語の語彙が必要です。 逆に言えば、SOC や NOC、情報システム部のセキュリティ部門に所属されているなど、普段からこれらの分野の製品や用語、概念に英語で触れる機会のある人であれば、Google Cloud や対象プロダクトの知識を数日〜数週間程度かけて習得することで、十分に合格が可能です。 他の認定試験との違い PSOE 試験は、Professional Data Engineer 試験（PDE）や Professional Machine Learning Engineer 試験（PMLE）と同様、その試験名に「Cloud」を含みません。このことからも分かるように、Google Cloud に閉じず、情報セキュリティ関係の広い知識が問われる試験となっています。 Professional Cloud Security Engineer 試験との違い Professional Cloud Security Engineer 試験（PCSE）では情報セキュリティの知識が問われるものの、「Google Cloud をどうセキュアに利用するか」という開発者寄りの観点が主になります。 一方で PSOE は防衛組織寄りの、「どのようにして攻撃を検知し対応するか」が主に問われます。 Google Cloud をセキュアに扱うための IAM や Cloud Audit Logs といった知識は、共通して問われます。 参考 : Professional Cloud Security Engineer 試験 - Google Cloud 参考 : Professional Cloud Security Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog Professional Cloud Network Engineer 試験との違い ネットワークに関する知識と情報セキュリティは密接に繋がります。Professional Cloud Network Engineer 試験（PCNE）でも、ファイアウォールなどのネットワーク防御機能が問われます。しかし PSOE はより深く、例えば「ファイアウォールのログに攻撃の痕跡があったらどのように対処するか」といったことが問われます。 一方で PSOE にもアタックサーフェス（攻撃対象領域、後述）に関する知識が必要となるため、ネットワーク的な知見は必要です。 参考 : Professional Cloud Network Engineer 試験 - Google Cloud 参考 : Professional Cloud Network Engineer試験対策マニュアル - G-gen Tech Blog Professional Cloud DevOps Engineer 試験との違い 「SecOps」「DevOps」という似通った表記の概念があるため、混乱する方もいらっしゃるかもしれません。さらに「DevSecOps」のような表現もあります。これらは見た目が似ているものの、それぞれ異なる分野の概念・用語です。しかしながら SRE やオブザーバビリティ（可観測性、 Observability、o11y）など、それぞれに通じるモダンな概念・指向・考え方は身につけておく必要があります。その意味では Professional Cloud DevOps Engineer 試験（PCDE）についての学習は役に立ちます。 参考 : Professional Cloud DevOps Engineer 試験 - Google Cloud 参考 : Professional Cloud DevOps Engineer試験対策マニュアル - G-gen Tech Blog 出題範囲と傾向 PSOE 試験は、以下の6つの分野から出題されます。 No. セクションタイトル 出題数 1. Platform operations （プラットフォームの操作） 約14% 2. Data management （データ管理） 約14% 3. Threat hunting （脅威ハンティング） 約19% 4. Detection engineering （検出技術） 約22% 5. Incident response （インシデント対応） 約21% 6. Observability （可観測性） 約10% 傾向として、脅威・攻撃の検出とその対応に関する問題の比率が高くなっています。全体のうち20〜25問程度がこれに関する設問です。 各セクションにおいて具体的にどのような知識を問われるのかについては、試験ガイドをご参照ください。 参考 : Professional Security Operations Engineer Exam Guide | English - Google Docs PSOE 試験の学習コンテンツ 他の Google Cloud 認定試験と同様に、公式には以下の学習コンテンツが用意されています。 オンライントレーニング（Google Skills ラーニングパス） 模擬試験 オンライントレーニング は、Google Cloud の学習プラットフォームである Google Skills （旧称：Skills Boost）で公開されています。動画とテキスト、小テストと、実際に Google Cloud の操作を行うことができる「ラボ」を組み合わせたラーニングパスで、ウェブブラウザからいつでも受講することができます。 Google が推奨するインシデント管理手法を体系的に学ぶことができるうえ、Security Command Center など実際に扱う機会が少ないサービスもラボで操作することができるため、時間はかかりますが有効なラーニングパスだと言えます。 模擬試験 は Google フォームを利用した簡易的なものですが、無料でチャレンジすることができますし、設問に対する解説や参考リンクも整備されています。出題傾向や、自分自身の不得意分野を知ることができるものになっています。 オンライントレーニングならびに模擬試験は、上述した 試験のランディングページ にあるリンクから開始できます。 当記事ではこのあと、試験の出題範囲において重要となるであろう基本的な知識を紹介します。学習を進めるうえで参考にしてください。 英単語の読み方 この記事で紹介する用語等について、一般的と考えられる読み方を紹介します。 用語 読み方 SIEM しーむ SOAR そあー CNAPP しーなっぷ MITRE ATT&CK まいたーあたっく Mandiant まんでぃあんと IEEE あいとりぷるいー SecOps せっくおぷす SIEM、SOAR、CNAPP SIEM、SOAR、CNAPP とは まず最初に、現代の IT セキュリティ戦略を語るうえで欠かせない、3つの概念について解説します。 Security Information and Event Management（ SIEM ） Security Orchestration, Automation, and Response（ SOAR ） Cloud-Native Application Protection Platforms（ CNAPP ） 上記は情報セキュリティ製品の種類を表す一般名称です。これらの名称に対応する Google Cloud ソリューションは、以下の2つです。 SIEM / SOAR→ Google Security Operations （Google SecOps） CNAPP → Security Command Center （SCC） このあと、当試験の中心となる概念とソリューションについて順に解説しますが、先に各概念がセキュリティ戦略に対してどのように対応しているかを説明します。 セキュリティフレームワークにおける各々の役割 米国国立標準技術研究所（NIST）が策定したサイバーセキュリティフレームワーク（CSF）2.0 によると、セキュリティに関する「機能（Function）」として以下の 6 種類と体系化されています。 統治（ GOVERN ） - セキュリティリスクマネジメント戦略やポリシーなど 識別（ IDENTIFY ） - 現在発生中のセキュリティリスクの識別 防御（ PROTECT ） - セキュリティ防御策・対策 検知（ DETECT ） - 攻撃や侵害の可能性（インシデント）の発見・検出と分析 対応（ RESPOND ） - 検知されたインシデントに対するアクション 復旧（ RECOVER ） - インシデントの影響を受けたリソースや業務の復旧 これらの機能のうち、一般的に、SIEM は 検知 を、 SOAR は 対応 と 復旧 を担います。CNAPP は複合的な機能を持つ製品なので単純には分類できませんが、主に 統治 ・ 識別 と 検知 を担当すると言えるでしょう。つまり検知は、SIEM と CNAPP が互いの担当範囲のもと、連携して担うことになります。 残った 防御 は通常、ファイアウォールや WAF などのプロダクトが担当しますが、クラウド領域においては CNAPP がそれらを管理します。 参考 : セキュリティ関連NIST文書について - IPA 独立行政法人 情報処理推進機構 Security Information and Event Management（SIEM） 組織内の様々な IT システムリソース・機器、アプリケーションから、膨大な量のログやデータが日々出力されています。これらのログには、IT リソースに対する攻撃の痕跡や兆候も記録されていますが、単純に1つ1つのログを閲覧するだけでは気付くことが出来ません。 Security Information and Event Management （SIEM） はこれら大量のログを一元的に収集し、リアルタイムに相関分析し、攻撃や脅威の兆候、つまり不審なアクティビティや攻撃のパターンを自動的に検出するソリューションです。 SIEM により、セキュリティ運用者は全体像の把握が容易になり、運用の効率を飛躍的に向上させることができます。 Security Orchestration, Automation, and Response（SOAR） Security Orchestration, Automation, and Response は「セキュリティオーケストレーション、自動化、レスポンス」を意味しており、通常は SOAR と略されて呼称されます。SOAR は、SIEM によって脅威が検知された後の対応プロセスを自動化・効率化するためのソリューションです。 インシデントが発生した際、アナリストは影響範囲の調査、関連情報の収集、隔離措置、関係者への報告など、多くの手作業に追われます。SOAR は、これらの定型的な作業を プレイブック （Playbook）と呼ばれる一連のワークフローとして定義し、自動で実行させることができます。 例として、以下のような作業をプレイブックにより自動化できます。 疑わしい IP アドレスやドメインのレピュテーション（評判）を外部の脅威インテリジェンスサービスに問い合わせる 不審なファイルが見つかった場合、サンドボックス環境で実行してその挙動を分析する 感染が疑われるエンドポイントをネットワークから自動的に隔離する 担当者へ Slack やメールで通知し、JIRA などのチケット管理システムにインシデントを起票する Google Security Operations（Google SecOps） Google Cloud が提供する Google Security Operations （Google SecOps）は、 SIEM と SOAR の役割を担う 製品です。かつては Chronicle と呼称されていましたが、リブランディングに伴い製品名が変更されました。 Google SecOps は Google の持つ大規模なインフラと高度な脅威インテリジェンスを基盤としており、以下のような特徴があります。 特徴 説明 ペタバイト級のスケーラビリティ クラウドネイティブなアーキテクチャにより、増え続けるログデータをコスト効率よく、高速に処理・分析 強力な検索と分析 Google のもつデータ分析基盤を活用、関連する様々な領域で生成 AI「Gemini」を統合 高品質な脅威インテリジェンス Google の脅威分析チームなどから得られる最新情報に基づき、高精度な脅威検出ルールを自動的に適用 組み込みのインシデント管理機能 チーム対応を前提としたインシデント（ケース）管理機能 RBAC による権限管理 IAM とは独立したロールベースの権限管理機能 SOAR Marketplace Playbook などを自前で開発しなくてもマーケットプレイスから調達可能 脅威インテリジェンス については後ほど詳しく解説しますが、世界中で発生しているセキュリティリスクや攻撃の情報を蓄積したナレッジベースと言い換えることができます。ユーザーは Google SecOps を通じて、Google が持つ世界屈指のナレッジベースにアクセスすることができます。 また Google SecOps は、Amazon Web Services（AWS）や Microsoft Azure などのクラウドプラットフォームや、Sentinel One などの EDR 製品など、多くのサードパーティ製品が出力するログにも広く対応しており、オンプレミスやクラウドプラットフォーム、SaaS 製品などに関するあらゆるセキュリティ情報を集約することができます。 参考 : 最新の SecOps: セキュリティ運用のモダナイズ | Google Cloud 受験にあたっては、Google SecOps で何ができるかについて、以下の記事を参考にして把握しておく必要があります。 blog.g-gen.co.jp Cloud-Native Application Protection Platforms（CNAPP） Cloud-Native Application Protection Platforms （CNAPP） とは、クラウドネイティブ アプリケーションの環境全体を保護するために設計された、統合的なセキュリティプラットフォームのことを指します。 従来のセキュリティ対策は仮想マシン（VM）が中心でした。しかし、コンテナやサーバーレスが中心となるクラウドネイティブ環境では、開発から本番稼働までのライフサイクル全体でセキュリティを確保する必要があります。CNAPP は、これまで別々のツールだった以下の機能を、1つのプラットフォームに統合します。 ツール名 説明 CSPM （Cloud Security Posture Management） クラウドの設定ミスや脆弱性を検出し、コンプライアンスを維持 CWPP （Cloud Workload Protection Platform） コンテナやサーバーレスファンクションなど、実行中のワークロードを保護 CIEM （Cloud Infrastructure Entitlement Management） 過剰な権限を持つ IAM ユーザーやサービスアカウントを検出 Security Command Center (SCC) Google Cloud では、 Security Command Center （SCC）が CNAPP の役割を担います。SCC は、Google Cloud 環境全体のアセット（資産）を自動的に検出し、潜在的なリスクや脅威を単一のダッシュボードに集約して可視化します。 参考 : Security Command Center | Google Cloud 受験にあたっては、SCC で何ができるかについて、以下の記事を参考にして把握しておく必要があります。 blog.g-gen.co.jp SCC が提供する主な機能は以下の通りです。 不審な API コールやマルウェア、暗号通貨マイニングなどの脅威をリアルタイムで検出する VM やコンテナイメージに存在する OS の脆弱性をスキャンし、優先順位をつけて管理・報告する 「ストレージバケットが意図せず公開されている」「ファイアウォールルールが緩すぎる」といった設定上の問題を特定・可視化する CIS ベンチマークなどの業界標準に準拠しているかを継続的に評価する Google SecOps と SCC は、連携することでさらに強力になります。SCC が検出した重要な脅威や脆弱性の情報を Google SecOps に送信し、SOAR プレイブックを起動させることで、検出から対応までの一連のプロセスをシームレスに自動化できます。 このように、SIEM、SOAR、CNAPP はそれぞれ異なる役割を持ちながらも、 連携することで強い効果 を発揮します。Google Cloud は、これらの機能を統合されたプラットフォームとして提供することで、複雑化するクラウド環境のセキュリティ運用をシンプルかつ効果的に実現します。 SCC には多くの検知ルールが Google によって用意されており、有効化するだけで自動的にスキャンと検知が行われます。一方で、 カスタムモジュール を構成することで、独自の検知ルールを作成することもできます。 参考 : Security Health Analytics 用のカスタム モジュールの概要 参考 : Event Threat Detection 用カスタム モジュールの概要 以下の記事も参考にしてください。 blog.g-gen.co.jp アタックサーフェスとゼロ・トラスト アタックサーフェス（Attack Surface） SIEM や CNAPP がセキュリティを確保するための手段、「道具」であるとするなら、それらの道具で管理・保護すべき対象が アタックサーフェス （攻撃対象領域、Attack Surface）です。アタックサーフェスはその名の通り、攻撃者が狙ってくる「脅威の侵入口」といえます。これは、ソフトウェアの脆弱性、設定ミス、従業員の認証情報などの要素を含みます。 アタックサーフェスは、大きく以下の3つに分類できます。 外部からアクセス可能なあらゆるデジタルリソース（Web サーバー、API、クラウドストレージなど） 物理的なアクセスによって情報を盗み出せる場所やデバイス（データセンター、業務用の PC やスマートフォンなど） 担当者など、標的となりうる人物や組織（ソーシャルエンジニアリング、フィッシングメールなど） 従来、これらのアタックサーフェスは 境界型セキュリティ で防御していました。つまり「社内と社外」「ゲートウェイ型ファイアウォールの内と外」など、「ここから先は危険」「ここからのアクセスなら安全」と、領域を分けて考えていたのです。 しかしながらクラウドが普及するにつれて、アタックサーフェスはますます拡大し、複雑化しています。攻撃側も巧妙になり、例えばまず社内 PC にマルウェアを送り込み踏み台にしてデータセンターを狙うなど段階を踏むようにもなったため、「ここは安全」と無条件に信頼することができなくなりました。 この状況には、境界型セキュリティでは対処できません。そこで、「信頼できる領域が ない ことを前提とすべき」という考え方が広まりました。 ゼロ・トラスト（Zero Trust） 先にもふれた米国国立標準技術研究所（NIST）が公開した SP800-207「 Zero Trust Architecture 」によると、ゼロ・トラストの原則（Tenet）は以下の 7 つとされています。意訳して抜粋します。 全てのデータと処理サービスは「 リソース 」とみなす 全ての「通信」は、 全ての場所で保護 する セッション単位の権限付与 を基本とする リソースへのアクセスは 動的ポリシー で認可する 企業は 全ての保有資産 の整合性とセキュリティ上の挙動を監視・計測する 全てのリソースに対する認証認可は、アクセスが許可される 前に 動的かつ厳格に処理される すべての企業は資産やネットワークに関する情報を 可能な限り 収集し、セキュリティ対策の改善に用いる Google Cloud において、これらはベストプラクティスの多くと合致します。IAM や限定公開アクセス機能などによってアタックサーフェスを如何に狭くし、残ったアタックサーフェスをどのように監視・防御するか、という観点が求められます。 参考 : NIST SP800-207 Zero Trust Architecture - NIST （PDF） 参考 : NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳 - PwCコンサルティング合同会社 境界型セキュリティ vs ゼロトラスト（ Chrome Enterprise Premium（旧BeyondCorp Enterprise）を徹底解説 - G-gen Tech Blog より引用） 脅威ハンティング 脅威ハンティングと MITRE ATT&CK 攻撃が複雑・巧妙化してきた一方、前述した SIEM など防御側が利用できる「道具」も整ってきたことで、これまで気付かなかった攻撃、技術的に見過ごさざるを得なかった攻撃も検知できるようになりました。 そこからさらに、「隠れた攻撃の痕跡」あるいは「既に潜伏している脅威」を探し出して対応することも可能になりました。 このような動きは、従来型の防御がある意味「受け身」であったことに対し、積極的に「狩り出す」という意味合いを込めて、 脅威ハンティング （Threat Hunting）と呼ばれます。 そのハンティングのための地図、あるいはハンドブックとして利用できるフレームワークが、米国の非営利団体 MITRE が運営する MITRE ATT&CK （あるいは単に「ATT&CK」）です。 参考 : MITRE ATT&CK ATT&CK は過去に観測されたサイバー攻撃を分析し、攻撃者の振る舞いを「 戦術 （Tactics）」と「 技術 （Techniques）」のマトリクスとして整理したナレッジベースです。これによりセキュリティチームは、攻撃者の「 TTPs （Tactics, Techniques, and Procedures、すなわち戦術、技術、手順）」に基づいて脅威を探すことができます。 脅威ハンティングによって「自社では、この TTPs が悪用されやすい」という知見が得られれば、その部分のアタックサーフェスを減らすための投資を強化できます。このように、予防と検知のサイクルを回し続けることで、組織は継続的にセキュリティ態勢を向上させていくことができます。 Actor と IoC 国家支援型グループやサイバー犯罪集団など、サイバー攻撃を実行する個人や組織を Actor （脅威アクター）と呼びます。攻撃手法（TTPs）のクセやツール、接続元の IP アドレスなどからプロファイリングされます。 世界中で「いま」行動中の Actor の情報を共有したり、Actor に応じた対処法を講じることが、防御や脅威ハンティングを効果的に行う近道となります。 参考 : サイバー脅威アクターとは？| CrowdStrike また Actor が活動することで残るログなどの痕跡を Indicators of Compromise （IoC、あるいは複数形で IoCs）と呼びます。直訳すると「侵害の兆候」となります。 IoC はログに含まれる単純な文字列の場合もありますが、さながら犯罪現場の遺留品や破片、足跡のように、一見見逃しそうなものでも IoC となり得ます。例えば「過去に攻撃に使われた IP アドレスやドメイン名」「既知のマルウェアのファイルハッシュ」「C&C との通信に酷似した特徴的なアクセス」などが該当します。 なお、効果的な脅威ハンティングは、やみくもにログを調べるのではなく、 仮説 （Hypothesis）を立てることから始まります。これは、「もし攻撃者が特定の技術を使ったら、ログにはこのような痕跡（IoC）が残るはずだ」と推論し、それを検証するプロセスです。 その際に役に立つのが Actor や TTPs の知識であり、ATT&CK に整理されているナレッジベースです。 Mandiant と Google Threat Intelligence（GTI） ここまで説明したような Actor や IoC は、相関性をもたせた「知識（インテリジェンス）」として使用する必要があります。 Google は独自の脅威インテリジェンスデータベースとして Google Threat Intelligence （GTI）を運用しています。Google SecOps はこの GTI と連携し、組織内に存在する既知の脅威をリアルタイムで検知します。 参考 : Google Threat Intelligence - 攻撃者を把握 | Google Cloud 一方で攻撃側も日々新しい手法やツールを考案し、既存のナレッジで検出できない攻撃を仕掛けてきます。これに対応するために、Google のセキュリティチームが世界中のネットワークを監視しています。 Mandiant サイバーセキュリティコンサルティング もそのうちの一つであり、GTI の運用だけでなく、顧客に対するセキュリティコンサルティングサービスを提供しています。 参考 : Mandiant サイバー セキュリティ コンサルティング | Google Cloud レトロハンティング レトロハンティング （retro-hunting）は脅威ハンティングの一種、あるいは亜種といえるものです。 通常の脅威ハンティングが「現在進行中の攻撃」に主眼を置いているに対し、レトロ（懐古）ハンティングは「過去」に主眼を置きます。つまり「 新たに見つかった・判明した脅威の IoC を過去のログなどから探す 」ことです。 例えば「昨日見つかったマルウェア、実は半年前から社内に潜んでいたのでは？」という問いに答えることが目的です。これにより被害範囲を洗い直したり、気づいていなかった侵入経路やアタックサーフェスを見つけ出すことができます。 レトロハンティングは対象が過去であるため、膨大な量のアーカイブ情報、ネットワークや認証などのログ情報に対して検索をする必要があります。大容量データ分析・検索能力に強みを持つ Google SecOps は、レトロハンティングも得意領域であると言えます。 その他のセキュリティ製品 VirusTotal VirusTotal は、指定されたファイルや URL がマルウェアで汚染されていないかを確認することができるウェブサービスです。また、セキュリティ研究者向けの機能や、エンタープライズ向けの有償サービスも提供しています。 Google SecOps は VirusTotal と連携しており、SecOps が発見した IoC を VirusTotal で確認・可視化することなどが可能です。 参考 : VirusTotal 参考 : VirusTotal の情報を表示する | Google Security Operations | Google Cloud サードパーティ製品 Google SecOps は多くのサードパーティ製品と連携することが可能です。PSOE 認定試験にあたりその全てを覚える必要はありませんが、著名かつ代表的なサービスについては、そのユースケースとともに押さえておきましょう。以下は例示です。 パブリッククラウドの各種サービス（AWS、Azure、Google Cloud ...） SIEM（Splunk、Exabeam ...） 運用管理（ServiceNow、JIRA ...） EDR（CrowdStrike、SentinelOne ...） インシデントレスポンス セキュリティインシデントに対しどのような組織体制を組むのか、という戦略は、インシデントの影響を最小限に抑え込むために重要です。 例えば米国の技術標準化機関のひとつである IEEE が公開しているドキュメント「Security Operations Center: A Systematic Study and Open Challenges」によると、セキュリティオペレーションセンター（SOC）のインシデント対応チームに必要なロールは以下だとされています。 Tier 1 : トリアージ スペシャリスト データの収集とアラートの確認、重要度を判定し、必要に応じて Tier 2 へエスカレーションする Tier 2 : インシデント対応者 詳細なインシデントの評価を行い、重要な問題が発生していると判断された場合にはエスカレーションする Tier 3 : 脅威ハンター 重大インシデントへの対応、各 Tier のメンバーの指導。平時には脆弱性試験などの監督やレトロハンティングを行う SOC マネージャ チーム全体の統括・マネジメント。CISO など経営トップへの説明責任を持つ 引用: FIGURE 4. Interaction of different roles within a SOC（ Security Operations Center: A Systematic Study and Open Challenges - IEEE xplore より引用） このようなチームでの動き方や、各 Tier の責任範囲など、何がベストプラクティスとされているかは押さえておくとよいでしょう。 参考 : Security Operations Center: A Systematic Study and Open Challenges もしこの領域に関する知識・経験が少ない場合は、入門として、以下のドキュメントを参考にしてください。 参考 : PagerDuty インシデントレスポンス ドキュメント - PagerDuty SecOps 文脈でのオブザーバビリティ オブザーバビリティとセキュリティ オブザーバビリティ （可観測性）という用語は多くの場合、運用監視の領域で使われることが多いのですが、その本質は「システム内で起きていることのリアルタイムでの計測と把握」であり、セキュリティ分野にも非常に関わりの深い・応用の可能な技術です。 試験ガイドの Section 6 にあるように、当試験においてはログやメトリクスの確認、アラートの設定、ダッシュボードやレポートの作成などが該当します。 サイレントソース検知（silent source detection） セキュリティにおいても運用監視においてもですが、見逃されやすいのがこの概念です。「異常があったという報告」と同レベルかそれ以上に「 来るはずの連絡がない 」というのは、非常に重要なアラートになり得ます。 一時的な報告遅延との切り分けが難しいものの、適切にケアすることが重要です。このように、来るはずのデータがこない状況を検知するための仕組みを サイレントソース検知 （silent source detection）といいます。 実装としては、Cloud Monitoring のアラート機能により、指標なし（metric-absence、data absence）を検知してアラートを発報するなどの方法が考えられます。 参考 : 指標なしのアラート ポリシーを作成する Google SecOps の詳細 パーサーと UDM Google SecOps は、Google Cloud だけでなく、数多くのクラウドサービスやソフトウェア製品のログを取り込み、分析と脅威検知ができます。 各製品のログが SecOps に送られると、 パーサー （parser）というコンポーネントでパースされ、 UDM （Unified Data Model）形式に再フォーマットされます。これにより、異なる製品の異なるフォーマットのログが1つの形式に統一され、SecOps による分析や脅威検知に利用できるようになります。 参考 : Default parser configuration and ingestion UDM のイベントやアラートは、後述の YARA-L 2.0 構文で検索することができます。 参考 : Search for events and alerts パーサーの種類と拡張 SecOps には デフォルトのパーサー （Prebuilt parser とも呼称）が多数用意されており、クラウドサービスや EDR 製品など、サードパーティ製品向けのパーサーが充実しています。デフォルトのパーサーのリストは、以下のドキュメントで確認できます。 参考 : Supported log types and default parsers デフォルトのパーサーが存在しない場合は、 カスタムパーサー を記述することができます。 参考 : Manage prebuilt and custom parsers 既存のデフォルトパーサーを拡張したい場合や、サードパーティ製品側でログのフォーマットが変更され、デフォルトパーサーの更新が追いついていない場合などは パーサー拡張機能 （Parser extensions）を使うことで、既存のパーサーをベースとしながら、フィールドを追加したりフィールド名を変更したりできます。 製品側の急な変更にできる限り小さい労力で対応 するには、この機能を使います。 参考 : Parser extensions サードパーティからのログ取り込み Google SecOps には、サードパーティの SaaS やオンプレミスのサーバー、ファイアウォール等、多様なデータソースからログを取り込む必要があります。特にサーバー類からのログ取り込みには、以下のような方法があります。 名称 説明 Forwarders Linux / Windows Server 等にインストールするエージェント Bindplane agent Linux / Windows Server 等にインストールするエージェント Ingestion APIs Google SecOps が用意するデータ取り込み用 API Google Cloud Google Cloud の Cloud Logging 経由で SecOps にログを取り込み Data feeds Amazon S3 やサードパーティ API などから直接 SecOps にログを挿入 Forwarders と Bindplane agent の違いについては、以下のようなものがあります。 Forwarders は SecOps 純正であり最もシンプル ただし Forwarders は syslog、ファイル、パケット、Splunk、Kafka など所定のフォーマットにのみ対応 Bindplane はログ収集エージェントというより「テレメトリパイプライン」であり、より柔軟な処理が可能 試験にあたっては、これらを踏まえて適切な収集方法を選択できる必要があります。 参考 : Google SecOps data ingestion インテリジェンスとアラート Google SecOps は、Mandiant、VirusTotal、Google Cloud Threat Intelligence（GCTI）などの、備え付けの脅威インテリジェンスソースによってキュレーション（推奨）された IoC を自動的に取り込む（ ingest ）ようになっています。 これらのインテリジェンスは、SecOps に取り込まれた後、UDM イベントデータの継続的な分析に使用されます。これにより、既知の悪意のあるドメイン、IPアドレス、ファイルハッシュ、URL に一致する IoC が自動的に発見 され、一致が見つかった場合はアラートが生成されます。 前述の SecOps に備え付けのインテリジェンスの他にも、MISP などのフィードを通じて 独自の IoC データを取り込む こともできます。MISP とは Malware Information Sharing Platform の略で、マルウェア情報の共有を受けられるプラットフォーム（サービス）です。 参考 : View alerts and IoCs - How Google SecOps automatically matches IoCs YARA-L ルール パーサーによって正規化され UDM となったイベントデータは、前述のとおり Google のインテリジェンスによって自動的に分析されますが、独自の検知ルールを定義したい場合は YARA-L 2.0 という構文を用いることができます。 参考 : Overview of the YARA-L 2.0 language YARA-L 2.0 は UDM に対する検索にも用いられます。また、YARA-L 2.0 の記述には Gemini の力を借りる こともできます。ルールエディタで Gemini に対して自然言語で目的などを指示することで、YARA-L ルールを記述することができます。 参考 : Generate a YARA-L rule using Gemini IAM によるアクセス制御 Google SecOps の管理画面へのアクセス制御は、Google Cloud の Identity and Access Management（IAM） で行います。 Google SecOps を紐づけた Google Cloud プロジェクトのプロジェクトレベルの IAM ポリシーにおいて、Google アカウントやグループにロールを付与します。付与するロールによって権限が異なります。読み取り専用ロールには roles/chronicle.viewer と roles/chronicle.limitedViewer の2種類があることに留意してください。 参考 : IAM を使用して機能アクセス制御を構成する - IAM での Google SecOps 事前定義ロール その他に知っておくべき概念 以下のような基本的な Google Cloud の概念については理解しておく必要があります。 Identity and Access Management（IAM） 組織（Organizations） 組織のポリシー 以下の記事も参考にしてください。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp 渡辺聖剛 (Seigo) (記事一覧) 事業開発部トレーニング課所属 Google Cloud 認定トレーナー。2025年2月にG-genにJOIN。福岡在住。オペレーションとモニタリングについて考えるのが好きな元インフラエンジニア。

G-gen の菊池です。当記事では GitHub などのリモートリポジトリに接続していない Dataform において、grep のようなファイル内検索をする手順について解説します。 はじめに Dataform とは Dataform のファイル内検索 ソースコード main.py コードの解説 実行手順 Cloud Shell の有効化 main.py の作成 クライアントライブラリのインストール main.py の実行 はじめに Dataform とは Dataform とは、BigQuery のためのデータパイプライン管理ツールです。 Dataform の基本的な概念や使い方については、以下の記事で解説しています。 blog.g-gen.co.jp Dataformでは、SQL ワークフローを構成する SQLX ファイル、JavaScript ファイル、各種設定ファイルなどを Dataform リポジトリで一元管理します。 このリポジトリは Git によってバージョン管理されており、チームでの共同開発を可能にします。Dataform が内蔵するリポジトリでは、単一の デフォルトブランチ と、複数作成できる ワークスペース と呼ばれる作業空間で、基本的なバージョン管理を行うことができます。さらに、GitHub や GitLab などの外部リポジトリと連携すれば、複数のブランチを活用した開発が可能になります。 参考： Dataform の概要 参考： コードのバージョン管理を行う Dataform のファイル内検索 Dataform に格納している SQLX ファイル内の文字列を検索したい場合、Dataform のコンソールにはそのような機能がありません。 GitHub に接続している場合は、 git grep コマンドを使用するなどして、ファイル内検索ができます。しかし、セキュリティ上の制約によりサードパーティの Git リポジトリに接続できない場合には、その手段は使用できません。 GitHub に接続していない Dataform でも、 Dataform API を使用することでファイル内のテキストを取得できます。当記事では、Python 用の Dataform 向けクライアントライブラリを使用することで、Dataform API へリクエストし、テキスト検索する方法を紹介します。 また当記事では、ローカルに Python 環境を構築する手順を省くために、Cloud Shell を使用しています。 ソースコード main.py 今回使用したコードの全文を以下に記載します。 import re from google.cloud import dataform_v1 # 定数: ご自身のプロジェクト情報に書き換えてください PROJECT_ID = "PROJECT_ID" REGION = "asia-northeast1" REPOSITORY_ID = "REPOSITORY_NAME" WORKSPACE_ID = "WORKSPACE_NAME" SEARCH_WORD = "tags:" def read_file (client, workspace_path, file_path): """指定されたDataformワークスペース内のファイルを読み取ります。""" request = dataform_v1.ReadFileRequest( workspace=workspace_path, path=file_path, ) response = client.read_file(request=request) return response.file_contents.decode( 'utf-8' ) def search_files_in_workspace (workspace_path, search_word): """ Dataformワークスペース内の.sqlxファイルを検索し、 指定された単語を含む行を特定して表示します。 """ client = dataform_v1.DataformClient() request = dataform_v1.SearchFilesRequest(workspace=workspace_path) page_result = client.search_files(request=request) pattern = f ".*{re.escape(search_word)}.*" print (f "検索ワード: {search_word} \n ---" ) for response in page_result: # 「ファイルであること」と「パスの末尾が.sqlxであること」の2つの条件をチェック if response.file and response.file.path.endswith( ".sqlx" ): file_path = response.file.path file_text = read_file(client, workspace_path, file_path) for line_num, line in enumerate (file_text.splitlines(), 1 ): if re.match(pattern, line): # パターンにマッチした行を表示 print (f "ファイルパス: {file_path}, 行番号: {line_num}, 内容: {line.strip()}" ) def main (): """スクリプトのメイン処理を実行します。""" workspace = ( f "projects/{PROJECT_ID}/locations/{REGION}/repositories/" f "{REPOSITORY_ID}/workspaces/{WORKSPACE_ID}" ) search_files_in_workspace(workspace, SEARCH_WORD) if __name__ == "__main__" : main() コードの解説 main.py では、以下のような処理でSQLXファイル内の文字列を検索しています。 # 定数: ご自身のプロジェクト情報に書き換えてください PROJECT_ID = "PROJECT_ID" REGION = "asia-northeast1" REPOSITORY_ID = "REPOSITORY_NAME" WORKSPACE_ID = "WORKSPACE_NAME" SEARCH_WORD = "tags:" 検索対象と検索ワードの指定 プロジェクトIDやDataform のリージョン、リポジトリ、ワークスペース、検索したい文字を指定します。 def main (): """スクリプトのメイン処理を実行します。""" workspace = ( f "projects/{PROJECT_ID}/locations/{REGION}/repositories/" f "{REPOSITORY_ID}/workspaces/{WORKSPACE_ID}" ) search_files_in_workspace(workspace, SEARCH_WORD) if __name__ == "__main__" : main() ワークスペースパスの作成 検索対象のDataform のワークスペースパスを作成し、検索ワードと共に引数としてsearch_files_in_workspace関数に渡します。 def read_file (client, workspace_path, file_path): """指定されたDataformワークスペース内のファイルを読み取ります。""" request = dataform_v1.ReadFileRequest( workspace=workspace_path, path=file_path, ) response = client.read_file(request=request) return response.file_contents.decode( 'utf-8' ) ファイル内容の取得 Dataform のクライアントライブラリのread_fileメソッドは、引数としてパスを渡したファイルの中身をバイト形式で返します。 それを文字コード（UTF-8）を指定して、人間が読める形式の文字列に変換します。 参考： Method: read_files | Python Client for Dataform API def search_files_in_workspace (workspace_path, search_word): """ Dataformワークスペース内の.sqlxファイルを検索し、 指定された単語を含む行を特定して表示します。 """ client = dataform_v1.DataformClient() request = dataform_v1.SearchFilesRequest(workspace=workspace_path) page_result = client.search_files(request=request) pattern = f ".*{re.escape(search_word)}.*" print (f "検索ワード: {search_word} \n ---" ) for response in page_result: Dataform のファイル一覧の取得 Dataform のクライアントライブラリのsearch_filesメソッドは、引数として渡したワークスペースパスにあるディレクトリやファイルの一覧を取得します。 参考： Method: search_files | Python Client for Dataform API # 「ファイルであること」と「パスの末尾が.sqlxであること」の2つの条件をチェック if response.file and response.file.path.endswith( ".sqlx" ): file_path = response.file.path file_text = read_file(client, workspace_path, file_path) SQLX ファイルの抽出と読み取り search_filesメソッドでは、ディレクトリとファイルでそれぞれ以下のような結果を返します。 ディレクトリの場合のresponse ファイルの場合のresponse これらの取得結果から、ファイルかつ末尾がsqlxのものを判定してread_file関数で処理します。 for line_num, line in enumerate (file_text.splitlines(), 1 ): if re.match(pattern, line): # パターンにマッチした行を表示 print (f "ファイルパス: {file_path}, 行番号: {line_num}, 内容: {line.strip()}" ) 検索ワードとの一致判定 ファイルの中身を1行ずつ判定し、検索ワードを含む場合は、ファイルのパスと該当の行を表示します。 実行手順 Cloud Shell の有効化 Google Cloud コンソール画面の右上にある「Cloud Shell をアクティブにする」ボタンをクリックします。 Cloud Shell をアクティブにする Cloud Shell API の呼び出しにユーザーの認証情報を使用する権限を付与することを承認するか確認のメッセージ画面が表示されるので「承認」をクリックします。 Cloud Shell の承認 Cloud Shell のエディタ画面が開きます。 Cloud Shell のエディタ もし、Cloud Shell のターミナル画面の方が開いた場合は、「エディタを開く」ボタンをクリックすることで、エディタ画面へ遷移します。 Cloud Shell のターミナル main.py の作成 [File] > [New Text File]を選択して、新規ファイルを開きます。 新規ファイル作成 新規ファイルの編集タブにソースコードの main.py のコードを貼り付けます。 新規ファイルにコード記載 [File] > [Save]を選択して、ファイル名に main.py と入力して、OKをクリックして保存します。 ファイルの保存 ファイル名設定 クライアントライブラリのインストール エディタ画面の「ターミナルを開く」をクリックして、ターミナル画面へ移動します。以下のコマンドを入力して、Dataform のクライアントライブラリをインストールします。 pip install --upgrade google-cloud-dataform main.py の実行 以下のコマンドを実行することで、main.py の search_word で指定した単語を含むファイルパスと該当行が表示されます。 python main.py 実行結果 菊池 健太 (記事一覧) クラウドソリューション部データエンジニアリング課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、GCPは未経験なので現在勉強中。

G-gen の min です。Looker Studio で Cloud Storage 上の非公開画像を扱う際に、BigQuery の EXTERNAL_OBJECT_TRANSFORM 関数を利用して署名付き URL を生成する方法があります。本記事ではその具体的な手順と、複数の画像を表示しようとした際に発生するレート制限エラーの原因と対処法について解説します。 事象 背景 原因 実装手順 1. Cloud Storage バケットの準備 2. BigQuery Connection API の有効化 3. 接続の作成 4. サービスアカウントへの権限付与 5. オブジェクトテーブルの作成 6. Looker Studio での設定 対処案1 : レポート側の工夫（緩和策） 対処案2 : 署名付き URL をテーブルに保存（推奨） 手順 ビューの使用について 注意点 事象 Looker Studio レポートに、Cloud Storage バケット上に配置した画像ファイルを表示する要件がありました。このバケットおよび画像ファイルは、インターネットに公開していません。 認証を経てレポートに画像を表示するために、BigQuery の EXTERNAL_OBJECT_TRANSFORM 関数を用いて、BigQuery のオブジェクトテーブルから署名付き URL を生成し、この URL を使って Looker Studio レポートに画像を表示することを試みました。 実装してみると、1つの表グラフに複数の画像を表示することは成功しましたが、レポートに2つ以上の表グラフに数十枚の画像を配置して表示・更新すると、BigQuery 側で以下のエラーが発生し、一部の画像が表示されませんでした。 Exceeded rate limits: too many concurrent queries that use EXTERNAL_OBJECT_TRANSFORM table-valued function for this project. For more information, see https://cloud.google.com/bigquery/docs/troubleshoot-quotas 一部画像が表示されない 詳細を表示すると割り当てエラーのメッセージが表示される 背景 今回のように、Looker Studio のレポートで Cloud Storage に保存されている非公開の画像（インターネットに公開せず、アクセスに認証を必要とする画像ファイル）を一部のユーザーにのみ表示するには、いくつかの方法があります。 1つ目は、Cloud Storage オブジェクトの「認証済み URL」を使用する方法です。オブジェクトが持つ認証済み URL を Looker Studio の IMAGE 関数に渡すことで、レポートに表示します。 参考 : Looker StudioでCloud Storageの画像が表示されない時の対処法 - G-gen Tech Blog 上記の方法では、画像を表示するにはレポートの閲覧者が Cloud Storage バケットもしくは画像オブジェクトに対して閲覧権限を持っている必要があります。しかし今回は、Looker Studio の レポートに対して 閲覧権限を持っている人であれば、Cloud Storage バケットやオブジェクトに対して閲覧権限を持っていないなくても、画像を表示できるようにしたい要件がありましたので、この方法は適切ではありません。 そこで今回は、2つ目の方法である BigQuery の オブジェクトテーブル から 署名付き URL （Signed URL）を生成する EXTERNAL_OBJECT_TRANSFORM 関数を用いる方法を用いました。この関数は、オブジェクトテーブルの管理対象となっている Cloud Storage オブジェクトの署名付き URL を生成します。 参考 : オブジェクト テーブルの概要 参考 : 署名付き URL この方法では、Looker Studio レポートのデータソースとして、BigQuery のオブジェクトテーブルを指定します。その上で Looker Studio のカスタムクエリにおいて EXTERNAL_OBJECT_TRANSFORM 関数を使用することで、当該テーブルへのクエリ権限を持っている人（データソースへの認証を「レポートのオーナー」または「サービスアカウント」にしている場合は、レポートへのアクセス権限を持っている人）であれば、署名付き URL を取得でき、同 URL 経由で画像へアクセスして表示することができます。 原因 公式ドキュメントによると、このエラーは、 EXTERNAL_OBJECT_TRANSFORM 関数を含むクエリの同時実行数が、プロジェクトに設定された割り当て（クォータ）を超過したことが原因です。 EXTERNAL_OBJECT_TRANSFORM 関数の呼び出しの同時実行数（リモート関数を含む同時実行クエリ）は、 プロジェクトあたり 10 と定められています。したがって、11個以上のクエリが発行されるような画像を一度に表示しようとすると、エラーが発生します。 参考 : Maximum rate of table metadata update operations limit errors 参考 : 割り当てと上限 | クエリジョブ 今回、レポート上には表グラフが4つのみ配置されていました。Looker Studio では、表グラフごとに BigQuery に対してクエリを発行しているため、ドキュメント上の上限である 10 クエリを下回っています。しかし、実際にはクォータエラーが発生しました。これは、Looker Studio の内部的な動作により、レポート上のコンポーネント数以上にクエリが発行された、あるいは非常に短い時間間隔でのクエリ集中を BigQuery 側が同時実行と見なしたことなどが原因として考えられます。 この現象から、根本的な問題は Looker Studio のカスタムクエリから EXTERNAL_OBJECT_TRANSFORM 関数を直接、かつ複数同時に呼び出していることにあると推測できます。以降で説明する対処法は、この直接呼び出しを避けるアプローチです。 実装手順 1. Cloud Storage バケットの準備 画像ファイルをアップロードするための Cloud Storage バケットを作成し、ファイルをアップロードします。 2. BigQuery Connection API の有効化 gcloud コマンドを使用して、オブジェクトテーブルの作成に必要な BigQuery Connection API を有効化します。 gcloud services enable bigqueryconnection.googleapis.com 3. 接続の作成 BigQuery が Cloud Storage にアクセスするための 接続 （Connection）を作成します。これは Google Cloud リソース接続 とも呼ばれます。 参考 : Google Cloud リソース接続 bq mk --connection \  --location =[ LOCATION ] \  --connection_type = CLOUD_RESOURCE \   [ CONNECTION_ID ] [LOCATION] には BigQuery のデータセットと同じリージョンを、 [CONNECTION_ID] には任意の接続IDを指定します。 コマンドが成功すると、この接続に関連付けられた一意のサービスアカウント ID が払い出されます。この接続で作成されたサービスアカウント ID は、次の手順で使用します。 参考 : 接続を作成する 4. サービスアカウントへの権限付与 手順3で作成されたサービスアカウントに対し、対象バケットへの ストレージオブジェクト閲覧者 （ roles/storage.objectViewer ）ロールを付与します。 gsutil iam ch \  serviceAccount: [ SERVICE_ACCOUNT_ID ] :objectViewer \  gs:// [ BUCKET_NAME ] [SERVICE_ACCOUNT_ID] には払い出されたサービスアカウントを、 [BUCKET_NAME] には対象のバケット名を指定します。 参考 : Cloud Storage の IAM リファレンス 5. オブジェクトテーブルの作成 Cloud Storage バケット上の画像をメタデータとして参照するオブジェクトテーブルを作成します。 CREATE EXTERNAL TABLE `my-project.my_dataset.my_object_table` WITH CONNECTION `asia-northeast1.my-connection` OPTIONS ( object_metadata = ' SIMPLE ' , uris = [ ' gs://my-bucket/images/*.jpg ' ] ); 参考 : リモート関数を作成する 6. Looker Studio での設定 Looker Studio でデータソースとして BigQuery を選択し、「 カスタムクエリ 」に以下のSQLを記述します。 SELECT uri, signed_url FROM EXTERNAL_OBJECT_TRANSFORM( TABLE `my-project.my_dataset.my_object_table`, [ ' SIGNED_URL ' ] ); Looker Studio のデータソースのフィールド編集画面で、 IMAGE 関数 を使用して新しい計算フィールドを作成します。この関数に signed_url フィールドを渡すことで、URL を画像として表示できます。 IMAGE(signed_url, "代替テキスト") 作成したフィールドをレポートの表などに追加すると、署名付き URL によって画像が表示されます。 参考 : IMAGE 対処案1 : レポート側の工夫（緩和策） 1つのレポートページに表示するグラフや画像の数を減らし、同時実行クォータである 10 以下に収まるように調整する方法です。 この方法は手軽ですが、表示したいレポートのレイアウトや画像の数に制約がかかるため、根本的な解決策ではありません。 対処案2 : 署名付き URL をテーブルに保存（推奨） 手順 EXTERNAL_OBJECT_TRANSFORM を含むクエリを定期的に実行し、生成された署名付き URL を別の BigQuery テーブルに保存します。Looker Studio は、この保存先のテーブルを参照するように設定します。 BigQuery のスケジュールされたクエリなどを利用して、以下のクエリを定期的に実行します。このクエリは、署名付き URL を生成し、結果を signed_url_table というテーブルに書き込みます。 CREATE OR REPLACE TABLE `my-project.my_dataset.signed_url_table` AS SELECT uri, signed_url, -- 有効期限を管理しやすくするため、生成時刻を記録 CURRENT_TIMESTAMP () AS generated_at FROM EXTERNAL_OBJECT_TRANSFORM( TABLE `my-project.my_dataset.my_object_table`, [ ' SIGNED_URL ' ] ); Looker Studio のデータソースは、この signed_url_table を直接参照するように変更します。これにより、カスタムクエリは不要になります。 ビューの使用について スケジュールされたクエリなどの定期実行ワークフローを使用しないですむよう、当初はマテリアライズドビューの使用も検討されました。しかし2025年9月現在、マテリアライズドビューでは EXTERNAL_OBJECT_TRANSFORM のようなテーブル関数を FROM 句で直接参照することがサポートされていないため、この手法は実現できません。 また論理ビューについては、クエリ結果が最大24時間キャッシュされるため、署名付き URL の有効期間（6時間）を超過してしまい、URL が無効になる可能性があります。このキャッシュを回避するには、 CURRENT_TIMESTAMP() のような非決定性関数をクエリに含める工夫が必要です。また論理ビューの場合、 EXTERNAL_OBJECT_TRANSFORM の同時実行数の問題が根本的に解決されるわけではないため、事前の検証が推奨されます。 注意点 EXTERNAL_OBJECT_TRANSFORM で生成される署名付き URL の有効期限は、 6 時間 です。スケジュールされたクエリの実行間隔は、この有効期限より短く設定する必要があります（例 : 1時間ごとに実行）。 参考 : 署名付き URL なお、Looker Studio は取得した画像を内部でキャッシュすることがあります。そのため、テーブル上の署名付き URL の有効期限が切れた後も、Looker Studio のキャッシュが有効な間は画像が表示され続ける場合があります。ただし、URL 自体は無効になっているため、リンクへ直接アクセスするとエラーが表示されます。 Looker Studio から有効期間後にリンクへ直接アクセスした場合のエラー例 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の杉村です。Cloud Run services や Cloud Run functions などでは、文字列を標準出力に出力することで、Cloud Logging にログを出力できます。その際に文字列を JSON で構造化して出力することで、Cloud Logging でログがパースされ、ログが閲覧しやすくなります。この仕組みについて解説します。 Google Cloud サービスと Cloud Logging 構造化ロギング 検証 前提条件 検証1. 単純なテキスト 検証2. JSON で構造化した出力 検証3. 複数行の出力 検証4. 複数行の出力を JSON で構造化 検証5. 辞書型変数を print 関数で出力 検証6. 様々な severity 検証7. 追加の JSON キー 検証8. Cloud Logging クライアントライブラリと Python ロガーの併用 検証9 : Python 標準ロガーのみの使用 Google Cloud サービスと Cloud Logging Cloud Run services や Cloud Run functions などでは、 文字列を標準出力や標準エラー出力に出力するだけ で、Cloud Logging にログを出力できます。 つまり、これらのサービス上で稼働するプログラムから Cloud Logging にログを出力したいときは、Cloud Logging の API リクエストを行ったり、エージェントプログラムをインストールする必要はなく、標準出力や標準エラー出力にテキストを出力するだけでよいことになります。この方法に対応しているサービスには、以下が挙げられます。 Cloud Run（services、jobs、worker pools） Cloud Run functions App Engine Google Kubernetes Engine（GKE） これらのサービスで標準出力や標準エラー出力にテキストを出力すると、ランタイムにプリインストールされている統合 Logging エージェント（integrated logging agent）により、テキストは自動的に Cloud Logging に送信されます。 参考 : Cloud Run でのログの記録と表示 - コンテナログを書き込む 参考 : GKE ログについて - Google Kubernetes Engine（GKE） 構造化ロギング 前述の仕様を使い、Cloud Logging にログを送出するとき、単に文字列を出力することでも Cloud Logging ログエントリとして記録されますが、 JSON 形式でログを構造化 することで、複数行に渡るログを見やすく表示したり、severity（重要度）を明示したり、その他の要素を構造的にログエントリに含ませてクエリしやすくしたりすることができます。 参考 : 構造化ロギング - Google Cloud Observability 構造化して出力されたログエントリ JSON で構造化したログ出力方法 log_dict = { "message" : "exp 8-2: Output with another keys" , "my_key_1" : "my_value_1" , "my_key_2" : "my_value_2" , } message_json = json.dumps(log_dict) logging.warning(message_json) 検証 前提条件 当記事で後述する検証結果はすべて、以下の条件で実行されたものです。 Cloud Run（services） ベースイメージは python:3.12-slim 検証1. 単純なテキスト 以下のようなソースコードで、単純な文字列を print 関数で標準出力に出力します。 # 検証1 : シンプルな文字列の出力（非構造化） message= "exp 1/2: hello, world" print (message) 出力結果を Cloud Logging のログエクスプローラーで閲覧すると、以下のようになります。 検証1 print 関数による出力内容は、ログエントリの textPayload として記録されています。またその内容は、ログエントリのプレビュー（画像上部の赤枠）として表示されています。 severity アイコン（画像の青枠）は DEFAULT （特に設定されていないことを意味する）が表示されています。ログエントリ内の要素としては、severity は存在していません。 severity の一覧 検証2. JSON で構造化した出力 次に、以下のようなソースコードで、JSON で構造化した文字列を print 関数で標準出力に出力します。 # 検証2 : シンプルな文字列の出力（構造化） import json log_dict = { "message" : message, "severity" : "INFO" , } message_json = json.dumps(log_dict) print (message_json) ソースコードは先程の「検証1」に続けて書かれているので、 message 変数の中身は、検証1と同様です。まずは message と severity というキーを持つ辞書型変数を作成し、それを json.dumps で JSON 型にしたものを print しています。 出力結果をログエクスプローラーで閲覧すると、以下のようになります。 検証2 検証1との違いは、severity が反映されていることです。先程のログエントリには severity 要素が存在せず、アイコン表示は DEFAULT でしたが、今回はログエントリに severity が存在し、INFO が格納されています。またログエントリのプレビューの左端にあるマーク（画像上部の青枠）もそれに応じたアイコンになっています。 検証3. 複数行の出力 次に以下のようなソースコードで、複数行の文字列を、構造化せずに print 関数で標準出力に出力します。 # 検証3 : 改行がある文字列の出力（非構造化） message= """exp 3/4/5: Here are multiple lines""" print (message) 出力結果は、以下のようになります。 検証3 文字列の各行が、改行コード区切りで別々のログエントリとして解釈されてしまい、閲覧性が悪くなっています。 検証4. 複数行の出力を JSON で構造化 次に、以下のようなソースコードで、先程と同じ複数行の文字列を JSON で構造化して出力します。 # 検証4 : 改行がある文字列の出力（構造化） log_dict = { "message" : message, "severity" : "WARNING" , } message_json = json.dumps(log_dict) print (message_json) ソースコードは先程の「検証1」に続けて書かれているので、 message 変数の中身は、検証3のままです。 出力結果は、以下のようになります。 検証4 複数行の文字列は1個のログエントリとして適切に解釈され、 textPayload に格納されています。 検証5. 辞書型変数を print 関数で出力 実験として、以下のようなソースコードで、検証4で構造化した辞書型変数を、JSON 化せずに print 関数に渡してみます。 # 検証5 : 改行がある文字列の出力（辞書型のまま） print (log_dict) 出力結果を Cloud Logging で閲覧すると、以下のようになります。 検証5 辞書型が文字列型にキャストされた結果は Cloud Logging には適切に解釈されず、severity もログエントリに反映されていません。このような出力の仕方は適切ではありません。 検証6. 様々な severity 以下のようなソースコードで、様々な severity のログエントリを出力して、ログエクスプローラーでの見え方を確認します。リスト severities の最後には、存在しない severity である MYSEVERITY を紛れ込ませてあります。 # 検証6 : 様々な Severity message = "exp 6: This is a message" severities = [ "DEFAULT" , "DEBUG" , "INFO" , "NOTICE" , "WARNING" , "ERROR" , "CRITICAL" , "ALERT" , "EMERGENCY" , "MYSEVERITY" ] for severity in severities: log_dict = { "message" : message + " with severity: " + severity, "severity" : severity, } message_json = json.dumps(log_dict) print (message_json) 出力結果は、以下のようになります。 検証6 各ログエントリに設定された severity はグラフィカルにアイコンで表示されています。存在しない severity である MYSEVERITY は正しく解釈されず、当該ログエントリの severity 要素は存在せず、アイコンは DEFAULT になっていました。Cloud Logging で使用可能な severity は以下のとおりです。 参考 : LogEntry - LogSeverity 検証7. 追加の JSON キー 以下のソースコードでは、JSON の中に message キーのほか、 my_key_1 、 my_key_2 という独自のキーも含ませています。 # 検証7 : message と追加のキー log_dict = { "message" : "exp 7: This is the main message text." , "severity" : "WARNING" , "my_key_1" : "my_value_1" , "my_key_2" : "my_value_2" , } message_json = json.dumps(log_dict) print (message_json) 出力結果は以下のようになりました。 検証7 ここまでの検証では、 message キーで渡された文字列は、ログエントリでは textPayload 要素として解釈されていました。しかし今回のようにカスタムキーが1個でも含まれると、 message キーも含めたすべてのキーが、ログエントリの jsonPayload 要素の中に格納されます。そのようなときも、 message は画像上部赤枠のプレビューで表示されています。また severity キーだけは jsonPayload から除外されて、ログエントリの最上位要素である severity として格納されます。 このように独自のキーを含ませることで、ログエントリを構造化でき、ログの閲覧のしやすさや検索性を向上できます。 検証8. Cloud Logging クライアントライブラリと Python ロガーの併用 以下では、Python の標準ライブラリである logger と、Cloud Logging のクライアントライブラリを使って、実用的な使い方を紹介します。 # 検証8 : Python のロガーを使用 import logging import os import google.cloud.logging client = google.cloud.logging.Client() client.setup_logging(log_level=logging.DEBUG) # Cloud Run 環境でなければ（ローカル環境であれば）ハンドラを追加、ログが画面出力される if not os.getenv( 'K_SERVICE' ): handler = logging.StreamHandler() formatter = logging.Formatter( '[%(asctime)s][%(name)s][%(levelname)s] %(message)s' ) handler.setFormatter(formatter) logging.getLogger().addHandler(handler) message = "exp 8-1: Output with logger." logging.info(message_json) 参考 : Python 用 Cloud Logging の設定 上記のソースコードでは、 client.setup_logging() によって Cloud Logging ハンドラを Python ルートロガーに接続しています。これにより、以下のような挙動になります。 ロガー（ここでは logging ）に JSON 形式でなく単純な文字列を渡すだけで、適切に Cloud Logging ログエントリに出力される（複数行の文字列のハンドリングなど） ロガーで指定したログレベルが Cloud Logging のログエントリの severity に反映される ログを出力したファイル、関数、ソースコードの行数がログエントリに自動的に出力される 以下は、検証8-1として出力した結果です。 検証8-1 上記のように、検証8-1では、logging に渡した引数は単純な文字列型でありながら、severity が反映されています。また、 sourceLocation がログエントリに自動的に追加されており、ログが出力されたファイル名、関数、行数などがわかるようになっています。 なお、 if not os.getenv('K_SERVICE'): からの行では、環境変数 K_SERVICE を確認しています。この環境変数は、Cloud Run service ランタイム上では自動的にサービス名が代入されます。環境変数が存在しない場合はローカル環境での実行とみなし、画面に見やすい形でログを出力するようにしています。環境変数 K_SERVICE を確認せずに無条件に StreamHandler （標準出力にログを出力するハンドラ）を追加していまうと、Cloud Run 環境で実行された場合にも標準出力にログが出力されてしまうことから、先程の Cloud Logging 用のハンドラとあわせて、2行のログエントリが重複して Cloud Logging に記録されてしまいます。 参考 : コンテナ ランタイムの契約 - サービスの環境変数 続いて以下は、検証8-2のソースコードと出力結果です。 log_dict = { "message" : "exp 8-2: Output with another keys" , "my_key_1" : "my_value_1" , "my_key_2" : "my_value_2" , } message_json = json.dumps(log_dict) logging.warning(message_json) 検証8-2 検証8-2では、logging に渡した引数は JSON です。 jsonPayload にカスタムキーを含めた要素が入っています。 最後に、以下のような検証8-3も実行します。 message = "exp 8-3: This is a message with extra fields" extra_fields = { "my_key_1" : "my_value_1" , "my_key_2" : "my_value_2" , } logging.error(message, extra={ "json_fields" : extra_fields}) ロガー（ここでは logging ）に第1引数として文字列を与え、extra として辞書型で json_fields をキーとしてカスタムフィールドを与えると、以下のような結果になります。 検証8-3 このようにして、ログの主たるメッセージを文字列で指定し、それ以外の付加的な情報を extra として辞書型で与えることができます。 検証9 : Python 標準ロガーのみの使用 以下のソースコードは、Python 標準の logging ライブラリのみを使用しています。カスタムフォーマッタを定義してハンドラにセットすることで、ロガーにテキストを渡すだけで出力が JSON 形式になり、Cloud Logging で適切に解釈されるようになります。 # 検証9 : カスタムフォーマッターを作成して JSON 化する import json import logging class FormatToJson (logging.Formatter): def format (self, log): return json.dumps({ "message" : log.getMessage(), "severity" : log.levelname, "app" : log.name, }) formatter = FormatToJson(datefmt= "%Y-%m-%dT%H:%M:%S%z" ) handler = logging.StreamHandler() handler.setFormatter(formatter) logger = logging.getLogger(__name__) logger.setLevel(logging.INFO) logger.addHandler(handler) logger.info( "exp 9: This is a message with a custom formatter." ) この方法では、Cloud Logging ログエントリは以下のようになります。 検証9 Cloud Logging クライアントライブラリを使用しないため軽量ではありますが、フォーマッタで定義されていないキーを追加できないほか、自動的にソースコードの行数がログに出力されることはありません。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。2025年8月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud Next Tokyo '25 開催 Google Agentspace が一般公開（GA） Google Agentspace で Data agent が Private Preview 開始 Cloud SQL for MySQL / PostgreSQL で AI model endpoint が Preview 公開 Vertex AI Search の回答モデルのデフォルトが gemini-2.5-flash に変更 Google Workspace で Gemini ログが BigQuery Export できるように バーチャル試着 API が利用可能に（Preview） Vertex AI Model Garden で OpenAI の gpt-oss が利用可能に Gemini アプリで学習支援機能が強化 Gemini CLI GitHub Actionsが発表（Preview） Vertex AI Search で高度なオートコンプリートが利用可能に Vertex AI でプロンプトオプティマイザが一般公開（GA） Google Meet 自動議事メモの「ネクストステップの提案」が日本語に対応 Gemini 2.5 Flash-Lite と Pro でファインチューニングが可能に コンテキストアウェアアクセスで警告モードが使用可能に BigQuery 関数の呼出時に Chained function calls が使用可能に BigQuery のクエリ結果を Cloud Storage に直接エクスポートできるように Gemini CLI が Cloud Shell でデフォルトで使用可能に Cloud Run で環境変数を .env ファイルで設定できるように（Preview） Imagen 4 が Preview -> GA AI Protection が Preview 公開 BigQuery コンソールに Reference パネルが登場 Google ドキュメントで Gemini による文書読み上げが利用可能に Google スライドで矢印キーによるオブジェクトの移動が1ピクセル単位に BigQuery のメタデータ自動生成が Preview → GA（一般公開） IPv6-only なサブネットや VM、NAT インスタンスが作成可能に Vertex AI で gemini-2.5-flash-image-preview が Preview 公開 Gemini アプリでプロンプトによる画像の編集が可能に コンテキストアウェアアクセスが OIDC アプリに適用可能に Google Vids に生成 AI 機能が複数追加 Podcast API が許可リスト制で公開 はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud Next Tokyo '25 開催 2025年8月5日(火) 〜 6日(水)、東京ビッグサイトで Google Cloud Next Tokyo '25 が開催された。Google Cloud の年次旗艦イベントである Google Cloud Next の東京版。基調講演のレポートは以下の記事を参照。 blog.g-gen.co.jp blog.g-gen.co.jp その他の関連記事は以下のリンクから参照。 blog.g-gen.co.jp Google Agentspace が一般公開（GA） Google Agentspace release notes - July 31, 2025 (2025-07-31) Google Agentspace が一般公開（GA）。 Google Agentspace は、様々なデータソースに対応した横断検索と AI エージェントのプラットフォーム。詳細は以下の記事を参照。 blog.g-gen.co.jp Google Agentspace で Data agent が Private Preview 開始 Google Agentspace release notes - August 01, 2025 (2025-08-01) Google Agentspace で Data agent が Private Preview 開始。 自然言語で質問をすると BigQuery に対してクエリを投入してくれる。Private Preview のため、利用するには Google への連絡が必要。 Cloud SQL for MySQL / PostgreSQL で AI model endpoint が Preview 公開 Register and call remote AI models in Cloud SQL overview (2025-08-04) Cloud SQL for MySQL / PostgreSQL で AI model endpoint が Preview 公開。 SQL を使い AI モデルを呼び出せる。エンベディング作成や、生成 AI モデルによる推論などをデータベースからシームレスに実行。BigQuery ML の RDBMS 版といえる。 Vertex AI Search の回答モデルのデフォルトが gemini-2.5-flash に変更 AI Applications release notes - August 04, 2025 (2025-08-04) Vertex AI Search の回答生成用モデルのデフォルトが gemini-2.0-flash から gemini-2.5-flash に変更。より高い精度での回答生成が期待される。 Google Workspace で Gemini ログが BigQuery Export できるように Export Gemini Audit logs to BigQuery (2025-08-04) Google Workspace で Gemini ログが BigQuery Export できるようになった。 先日のアップデートでは、管理コンソールと API で取得できるようになっていたが、今回、BigQuery への自動エクスポートも可能になった。監査ログの BigQuery Export は以下のエディションで可能。 Frontline Standard and Plus Enterprise Standard and Plus Education Standard and Plus Enterprise Essentials Plus バーチャル試着 API が利用可能に（Preview） Generate Virtual Try-On Images (2025-08-06) バーチャル試着 API が利用可能に（Preview）。 Vertex AI API の1つ。人物画像と衣服画像を Base64 エンコードして投入すると、その衣服を着た人物画像が Cloud Storage バケットに出力される。以下の記事も参照。 blog.g-gen.co.jp Vertex AI Model Garden で OpenAI の gpt-oss が利用可能に Vertex AI release notes - August 6, 2025 (2025-08-06) Vertex AI Model Garden で OpenAI の gpt-oss が利用可能に。 gpt-oss はツール使用、Chain of Thought、reasoning 調整などの特徴があるオープンウェイト言語モデル。ライセンス費用は無しでコンピュート費用のみ。 Gemini アプリで学習支援機能が強化 New study tools in the Gemini app to help you learn more effectively (2025-08-06) Gemini アプリで学習支援機能が強化。 Guided Learning（ガイド付き学習） Canvas でのクイズ作成で質問数や質問タイプをカスタム可能 画像、図表、YouTube 動画で学習を支援 Gemini CLI GitHub Actionsが発表（Preview） AI コーディングの新たなパートナー：Gemini CLI GitHub Actions を発表 (2025-08-06) Gemini CLI GitHub Actionsが発表（Preview）。Issue 振り分け、自動的な PR レビュー、Issue/PR 内で Gemini CLI にメンションして作業指示など。無料枠あり。 Vertex AI Search で高度なオートコンプリートが利用可能に Configure advanced autocomplete (2025-08-06) Vertex AI Search で高度なオートコンプリートが利用可能に。 クエリの最初の数文字を入力すると残りがサジェストされる。「基本」との違いは以下の通り。 Blended Search アプリに対応 データソースへのアクセス制御 候補のブースト 最近のクエリが提案される Vertex AI でプロンプトオプティマイザが一般公開（GA） Optimize prompts (2025-08-07) Vertex AIでプロンプトオプティマイザが一般公開（GA）。 zero-shot optimizer と data-driven optimizer がある。ユーザのプロンプトを自動で書き換えてモデルが理解しやすく変換してくれる。 Google Meet 自動議事メモの「ネクストステップの提案」が日本語に対応 Language expansion for “suggested next steps” when using “Take Notes for Me” (2025-08-07) Google Meetの自動議事メモ機能の「ネクストステップの提案」が日本語に対応。 次のステップ、フォローアップ事項、ネクストアクションなどを会話内容から自動的にまとめてくれる。15日間かけて順次ロールアウト。 Gemini 2.5 Flash-Lite と Pro でファインチューニングが可能に Supported models (2025-08-08) Gemini 2.5 Flash-Lite と Pro でファインチューニングが可能になった。 このアップデートにより、Pro、Flash、Flash-Lite のいずれもファインチューニングが可能になった。 コンテキストアウェアアクセスで警告モードが使用可能に Deploy Context-Aware Access levels in “Warn” mode (2025-08-11) Google Workspace のコンテキストアウェアアクセスで警告モードが使用可能に。 アクセス要件を満たしていないクライアントがアクセスすると、ブロックされず、警告が表示される。アクセス自体は可能。移行過渡期の設定周知などに用いることができる。 画像は公式ドキュメントから引用 BigQuery 関数の呼出時に Chained function calls が使用可能に Chained function calls (2025-08-11) BigQuery 関数の呼出時に Chained function calls が使用可能になった。 ネストされた関数呼び出しをドット（.）で繋いで呼び出せる。SQL の可読性の向上に繋がる。 BigQuery のクエリ結果を Cloud Storage に直接エクスポートできるように Save query results to Cloud Storage (2025-08-12) BigQuery のクエリ結果を Cloud Storage に直接エクスポートできるようになった。 CSV、JSONL、Avro、Parquet 形式に対応。これまでのエクスポート先であるローカル、Google ドライブ、スプレッドシートなどに加えて利用可能になった。 Gemini CLI が Cloud Shell でデフォルトで使用可能に Gemini CLI (アップデート時期不明) Gemini CLI が Cloud Shell（Google Cloud コンソールで利用可能な仮想 Linux ターミナル）でデフォルトで使用できるようになった。 追加セットアップは必要なし。 Cloud Shell 上のメッセージ Cloud Run で環境変数を .env ファイルで設定できるように（Preview） Set multiple environment variables using the .env file (2025-08-13) Cloud Run で環境変数を .env ファイルで設定できるようになった（Preview）。 版管理や共同開発もしやすくなる。以下の記事も参照。 blog.g-gen.co.jp Imagen 4 が Preview -> GA Vertex AI release notes - August 14, 2025 (2025-08-14) Imagen 4 が Preview -> GA。Preview 時代からある Imagen 4 に加え、Fast と Ultra が増えた。利用可能モデルは以下のとおり。 Imagen 4 Generate Imagen 4 Fast Generate Imagen 4 Ultra Generate AI Protection が Preview 公開 AI Protection overview (2025-08-15) AI Protection が Preview 公開。 Next 等でも紹介されていたソリューション。AI 関係リソースのリスクや脅威を可視化するためのツールで、Security Command Center Enterprise Tier で使用可能。Model Armor とも統合されている。 BigQuery コンソールに Reference パネルが登場 Use the Reference panel (2025-08-18) BigQuery コンソールに Reference パネルが登場。 テーブルのスキーマを確認したりクリックで列名を SQL に挿入したり中身のプレビューができる。最近見たテーブルにすぐに飛べるなど、SQL の記述が効率的になる。 Reference パネル Google ドキュメントで Gemini による文書読み上げが利用可能に Listen to your documents using Gemini in Google Docs (2025-08-18) Google ドキュメントで Gemini による文書読み上げが利用可能になる。 ただし、まずは英語のみ対応。読み上げのためのボタンも挿入可能。 Google スライドで矢印キーによるオブジェクトの移動が1ピクセル単位に Arrow keys now move an object by a pixel distance in Google Slides (2025-08-19) Google スライドで矢印キーによるオブジェクトの移動が1ピクセル単位に。 従来は細かい位置揃えには座標を手入力して微調整していた。 BigQuery のメタデータ自動生成が Preview → GA（一般公開） Generate table and column descriptions (2025-08-25) BigQuery のメタデータ自動生成が Preview → GA（一般公開）。 テーブルの中身をAIが読み取り、テーブルとカラムのビジネスメタデータ（Description）を自動生成する。 ただし現在、英語の生成のみに対応。また、コンソールで1テーブルずつ生成する必要あり。 IPv6-only なサブネットや VM、NAT インスタンスが作成可能に VPC release notes - August 26, 2025 (2025-08-26) VPC と Compute Engine で、IPv6-only なサブネットや VM、NAT インスタンスの作成が可能になった。IPv4 の枯渇に対する対応策に。 Vertex AI で gemini-2.5-flash-image-preview が Preview 公開 Vertex AI release notes - August 26, 2025 (2025-08-26) Vertex AI で gemini-2.5-flash-image-preview が Preview 公開。通称「Nano Banana」。 画像生成と編集の機能があり、参照画像をもとに新規画像を生成したり、マルチターンで画像を編集したりできる。Gemini アプリでも、プロンプトで指示するだけで簡単に使えるようになった。 Gemini アプリでプロンプトによる画像の編集が可能に Image editing now available in the Gemini app (2025-08-26) Gemini アプリでプロンプトによる画像の編集が可能になった。全ユーザーにロールアウト済。gemini-2.5-flash-image-preview、通称「Nano Banana」を使った機能。 添付画像は、Gemini アプリに G-gen のロゴ画像を与えて「ノベルティのトートバッグに印刷して」と指示して実際に生成された画像。 コンテキストアウェアアクセスが OIDC アプリに適用可能に Context-Aware Access policies can now be applied to all internal and third-party apps using OpenID Connect (2025-08-26) Google Workspace のコンテキストアウェアアクセスが、Workspace と OIDC 連携しているアプリにも適用できるようになった。 現在のところすべての OIDC アプリに同じポリシーが適用される（個別設定はできない）。順次ロールアウト。 Google Vids に生成 AI 機能が複数追加 Edit videos more easily using the transcript in Google Vids (2025-08-27) Deliver your message with AI avatars in Google Vids (2025-08-27) Convert images to video with Veo 3 in Google Vids (2025-08-27) Google Workspace 付属の動画編集ツール Google Vids に、生成 AI 機能が複数追加。 撮影した動画の文字起こしからフィラー（「えー」など）を文字で確認して、動画から削除できる（現在は英語のみ対応） AI アバターによる説明動画の生成。架空の人物が台本を読み上げて説明する動画を生成できる（現在は英語のみ対応） 画像を入力すると8秒間の動画へ変換できる。動画生成モデルVeo 3を使用 Podcast API が許可リスト制で公開 Generate podcasts (API method) (2025-08-28) Podcast API が許可リスト制で公開。利用にはGoogleへの申請が必要。 ポッドキャスト風音声がAPI経由で生成できる。テキスト、画像、音声、動画をインプットして、MP3 音声を出力。 製品ラインとしては NotebookLM Enterprise だが、NotebookLM Enterprise や Agentspace のライセンスは不要。API endpoint は以下。 https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/podcasts 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen のkiharuです。当記事では、reCAPTCHA の料金体系について解説します。 はじめに reCAPTCHA とは Classic と Enterprise 料金ティア 3つの料金ティア ティアの適用 料金単価と無料枠 料金表 無料枠 はじめに reCAPTCHA とは reCAPTCHA は、スパムや不正アクセスからウェブサイトやモバイルアプリを保護するための Google Cloud サービスです。 ログイン時などに「画像認証のクイズ」や「私はロボットではありません」といったチェックを求める形で利用されています。選択できるタイプの1つである v3 では、ユーザーの操作なしでやり取りが正当かどうかを検証できます。 参考 : reCAPTCHA のタイプを選択する 参考 : 適切な reCAPTCHA キーのタイプを選択する チェックボックスキーの例 CAPTCHA チャレンジの例 Classic と Enterprise reCAPTCHA Classic は、Google Cloud サービスではなく Google サービスとして提供されてきた、従来型のサービスです。 「以前の管理コンソール」でキーが作成されており、かつ Google Cloud プロジェクトに紐付けられていない場合は、reCAPTCHA Classic が利用されています。reCAPTCHA Classic のすべての reCAPTCHA キーは、2025年末までに使用不可となるため、Google Cloud プロジェクトへ移行する必要があります。 参考 : 以前の管理コンソール 参考 : reCAPTCHA migration overview 参考 : reCAPTCHA Classic から移行する 一方で reCAPTCHA は、Google Cloud サービスとして提供されています。2025年末以降は、こちらが唯一の提供形態です。 かつては、Google サービスとして提供される旧来サービスを「reCAPTCHA Classic」、Google Cloud サービスとして提供される新サービスを「reCAPTCHA Enterprise」と表記されていましたが、現在では 後者を指して reCAPTCHA と呼称します。 当記事では、後者の reCAPTCHA の料金体系について解説しています。 料金ティア 3つの料金ティア reCAPTCHA には以下の 3 つのティアがあります。 Essentials Standard Enterprise ティアによって料金体系が異なるほか、特に Essentials と Standard 以上では利用可能な機能も異なっています。以下は、機能差異から一部を抜粋したものです。 機能 Essentials Standard / Enterprise 有償サポート 利用不可 利用可能 WAF との統合 なし あり パスワード漏洩検出 なし あり bot スコアの粒度 4 11 iOS SDK なし あり Android SDK なし あり ログ なし あり リアルタイムの統計情報 なし あり SLA なし 可用性 99.9% SLO なし あり 参考 : reCAPTCHA の各ティア間の機能の比較 ティアの適用 reCAPTCHA に適用される料金ティアは、Google Cloud プロジェクトの請求の有効化の有無や、使用量に応じて自動的に切り替わります。 請求が有効になっていない Google Cloud プロジェクトでキーを作成すると Essentials が適用 Google Cloud プロジェクトで請求を有効にすると、 Standard が適用 100,001 件以上の評価が発生すると Enterprise が適用 ただし、事前に Google Cloud や販売パートナーに相談することで、年単位等のボリュームディスカウント契約を締結することも可能です。 ティアの自動移行の流れ 参考 : 請求の仕組み 料金単価と無料枠 料金表 以下は、2025年9月現在の料金です。最新の料金は、必ず英語版の公式ドキュメントを参照してください。 参考 : Compare features between reCAPTCHA tiers 参考 : reCAPTCHA Pricing ティア 料金体系 Essentials 無料評価枠内での利用のみ Standard 無料評価枠 (10,000 件/月) + 100,000件まで $8 Enterprise 無料評価枠 (10,000 件/月) + 100,000件まで $8 + 超過した1,000件ごとに $1 料金体系とティア自動移行のイメージ 無料枠 reCAPTCHA には無料評価枠があり、 1 か月あたり10,000件 の評価まで無料です。請求が有効化されていない Essentials ティアでは、この無料枠を超えると、新しいリクエストはエラーとして返されます。 なお、月間無料枠のカウントは Google Cloud 組織全体で共有されます。また、月の評価回数は、毎月1日にリセットされます。 kiharu (記事一覧) クラウドソリューション部 クラウドエンジニアリング課。 2024年8月G-genにジョイン。 手芸好きなエンジニアです。Follow @kiharuco_

G-gen の三浦です。当記事では Microsoft SharePoint Online から Google ドライブへの移行ツールの検証結果を紹介します。 概要 Microsoft SharePoint Online からのデータ移行とは 前提条件 制約 検証概要 検証環境 検証の流れ 設定手順 [Microsoft 365] 移行対象サイトの URL の確認 [Google Workspace] 移行先の共有ドライブ ID の確認 [Google Workspace] 移行用の CSV の準備 [Google Workspace] データ移行の実施 [Microsoft 365] 移行後に SharePoint のファイルを追加 [Google Workspace] 差分移行の実施と確認 概要 Microsoft SharePoint Online からのデータ移行とは 当機能は Google Workspace の管理機能であり、Microsoft SharePoint Online（以下、SharePoint）のデータを Google ドライブの共有ドライブにコピーできます。 参考 : Microsoft SharePoint から Google Workspace に移行する 参考 : SharePoint Online からファイルを移行する 前提条件 当機能で移行を実施するには、以下の要件があります。 Google Workspace 側では 特権管理者ロール が必要です。 Microsoft 365 側では グローバル管理者ロール が必要です。 以下の特定の Google Workspace エディションでのみ利用可能です。 対応エディション Business Starter / Business Standard / Business Plus Enterprise Standard / Enterprise Plus Education Fundamentals / Education Standard / Education Plus Essentials Starter / Essentials Enterprise Essentials / Enterprise Essential Plus Nonprofits G Suite Basic / G Suite Business / G Suite Essentials 参考 : SharePoint Online からのファイルの移行について 制約 当機能には以下のような制限があります。 一度に移行可能な SharePoint Online サイト数は 100 です。 移行先は 共有ドライブ となり、特定の Google Workspace ユーザーのマイドライブへの移行はできません。 その他の制約については、以下の公式ドキュメントを確認してください。 参考 : SharePoint Online からのファイルの移行について 参考 : SharePoint Online のファイル移行で移行されるデータ 検証概要 検証環境 検証環境は以下のとおりです。実際の移行ケースを想定し、OneDrive と Google ドライブのドメインおよびユーザー情報を統一した環境で検証しました。 プラットフォーム ドメイン名 ユーザー名 ライセンス Google Workspace miurak-test.com admin@miurak-test.com Google Workspace Business Starter Microsoft 365 miurak-test.com admin@miurak-test.com Microsoft 365 Business Basic 移行テスト用の SharePoint Online のサイトおよび移行先の共有ドライブは以下のとおりです。 サイト名 種類 配置ファイル 共有ドライブ名 管理者ユーザー gws-test-team チームサイト gws-test-team.xlsx gws-test-team-drive admin@miurak-test.com gws-test-communication コミュニケーションサイト gws-test-communication.pptx gws-test-communication-drive admin@miurak-test.com テストサイト情報1 テストサイト情報2 テストサイト情報3 検証の流れ 以下の手順でデータの移行を実施します。 項目 作業 プラットフォーム 1 移行対象サイトの URL の確認 Microsoft 365 2 移行先の共有ドライブ ID の確認 Google Workspace 3 移行用の CSV の準備 Google Workspace 4 データ移行の実施 Google Workspace 5 移行後に SharePoint のファイルを追加 Microsoft 365 6 差分移行の実施と確認 Google Workspace 設定手順 [Microsoft 365] 移行対象サイトの URL の確認 SharePoint 管理センター（ https://go.microsoft.com/fwlink/?linkid=2185219 ）にログインします。 参考 : SharePoint 管理センターのサイトを管理する [アクティブなサイト] から移行対象サイトの URL を確認し、控えておきます。 URLの確認 [Google Workspace] 移行先の共有ドライブ ID の確認 共有ドライブの管理画面（ https://admin.google.com/ac/drive/manageshareddrives ）にアクセスします。 ※ Google Workspace の管理コンソールのため、ログインが必要です。 画面を右にスクロールすることで、共有ドライブ ID が確認できるので、控えておきます。 共有ドライブIDの確認 [Google Workspace] 移行用の CSV の準備 Google Workspace の管理コンソール（ https://admin.google.com ）にログインします。 参考 : 管理コンソールにログインする [データ] > [データのインポートとエクスポート] > [データ移行（新規）] から Microsoft SharePoint Online の [移行] を選択します。 SharePoint Onlineの移行を選択 ステップ2の [サンプル CSV をダウンロード] を選択します。 サンプルCSVのダウンロード ダウンロードした CSV を開き、以下のとおりに入力し、保存します。 Source SharePoint URL : 項目1で確認した移行対象サイトの URL Target Drive FolderID : 項目2で確認した共有ドライブ ID Target GUser : 共有ドライブへ管理者権限をもつ Google Workspace ユーザーのメールアドレス ※ Target GUser のユーザーが SharePoint からコピーしたファイルの所有者となります。 移行用のCSV入力 ステップ3の [サンプル CSV をダウンロード] を選択します。 サンプルCSVのダウンロード ダウンロードした CSV を開き、以下のとおりに SharePoint と Google ドライブのアドレスの紐付け を入力し、保存します。 Source Entity : SharePoint のユーザーまたは Microsoft 365 グループ または SharePoint Online サイトグループ Destination Email : Google Workspace のユーザーまたは Google グループのメールアドレス 紐付け用のCSV入力 [Google Workspace] データ移行の実施 Microsoft SharePoint Online の移行のステップ1の [Microsoft SharePoint Online に接続] を選択し、移行ツールに権限を付与します。 SharePointへの接続とMicrosoftアカウントの選択 アクセス許可内容を確認して承諾 接続完了確認 ステップ2の[CSV をアップロード] を選択し、前の手順で作成した CSV を選択します。 CSVをアップロード CSVアップロード完了 ステップ3の[CSV をアップロード] を選択し、前の手順で作成した CSV を選択します。 CSVをアップロード CSVアップロード完了 ステップ4はステップ3の CSV でマッピングされていないアドレスの処理方法を選択します。今回は特に変更せずにデフォルトの設定とし、[移行を開始] を選択します。 移行を開始を選択 移行が完了したことを確認します。詳細は [移行レポートをエクスポート] または [サイトレポートをエクスポート] から確認できます。 移行完了確認 移行レポートサンプル サイトレポートサンプル 共有ドライブを確認し、サイト名のフォルダが新規で作成され、その配下にファイルがコピーされていることを確認します。 移行確認1 移行確認2 [Microsoft 365] 移行後に SharePoint のファイルを追加 データの移行後に、gws-test-communication サイトへ新規で Excel ファイルをアップロードします。 ファイルの追加 [Google Workspace] 差分移行の実施と確認 [差分移行を実行] を選択します。 差分移行を実行 移行が成功したことを確認します。 差分移行完了確認 移行レポートサンプル サイトレポートサンプル 共有ドライブを確認し、追加した Excel がコピーされていることを確認します。 差分移行確認 移行が完了したら、[移行を終了する] > [移行を終了して削除] を選択し、移行を終了します。 移行を終了するを選択 移行を終了して削除を選択 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の佐々木です。当記事では、GKE で Gateway API を使用して作成したアプリケーションロードバランサーに対して、HTTP リクエストを HTTPS にリダイレクトするように設定する手順を解説します。 はじめに Gateway API について アプリケーションロードバランサーの HTTPS リダイレクト機能 Gateway API における HTTPS リダイレクト機能 当記事の構成について HTTPS リダイレクト構成前の動作確認 HTTPS リダイレクト専用の Namespace を作成する Gateway リソースに HTTP 用のリスナーを記述する リダイレクト用の HTTPRoute リソースを作成する 動作確認 はじめに Gateway API について Gateway API は、Kubernetes でレイヤ7の高度なトラフィックルーティングを提供するための Kubernetes アドオンであり、Google Cloud では GKE で L7 ロードバランサー（アプリケーションロードバランサー）を利用したい場合に使用されます。 従来から同様の用途で使用されていた Ingress API に様々な改良が加えられたものであり、高度なルーティング（ヘッダーベース、重み付けなど）や、異なる Namespace にあるリソースへのアクセスなどがネイティブにサポートされています。 Gateway API の基本については以下の記事を参照してください。 blog.g-gen.co.jp アプリケーションロードバランサーの HTTPS リダイレクト機能 Google Cloud で提供されているアプリケーションロードバランサーには、ロードバランサーに対する HTTP リクエストを HTTPS にリダイレクトする（HTTPS を強制する）機能があります。 この機能では、HTTPS リクエストを処理するように構成されたロードバランサーに加えて、そのロードバランサーに対して HTTP リクエストをリダイレクトするためのロードバランサー が構成されます。この2つのロードバランサーは同一の IP アドレスを持ちます。 リダイレクト用のロードバランサーは HTTP リクエストを受信し、そのリクエストを HTTPS リクエストを処理するロードバランサーにリダイレクトする役割を持ちます。これにより、バックエンドサービスのユーザーに HTTPS の使用を強制することができます。 HTTPS リダイレクトの動作イメージ 参考 : Set up an HTTP-to-HTTPS redirect for global external Application Load Balancers Gateway API における HTTPS リダイレクト機能 GKE で Gateway API を使用してアプリケーションロードバランサーを作成する場合でも、HTTPS リダイレクト機能を利用することができます。 Gateway API で作成されるロードバランサーの種類を定義する GatewayClass と、それぞれの HTTPS リダイレクト機能のサポート状況を以下の表に示します。 GatewayClass ロードバランサーの種類 HTTPS リダイレクトのサポート gke-l7-global-external-managed グローバル外部アプリケーション ロードバランサー ○ gke-l7-global-external-managed-mc グローバル外部アプリケーション ロードバランサー（マルチクラスタ） ○ gke-l7-regional-external-managed リージョン外部アプリケーション ロードバランサー ○ gke-l7-regional-external-managed-mc リージョン外部アプリケーション ロードバランサー（マルチクラスタ） ○ gke-l7-rilb 内部アプリケーション ロードバランサー ○ gke-l7-rilb-mc 内部アプリケーション ロードバランサー（マルチクラスタ） ○ gke-l7-gxlb 従来のアプリケーション ロードバランサー × gke-l7-gxlb-mc 従来のアプリケーション ロードバランサー × 参考 : Deploying Gateways - Configure HTTP-to-HTTPS redirects 参考 : GatewayClass capabilities - Frontend security 当記事の構成について 当記事では、以下の記事で作成した Gateway API リソースと nginx のバックエンドを持つ環境に対して、HTTPS リダイレクトを追加で構成していきます。以降の手順の前提となるサンプル環境を構成するためのマニフェストファイルについては、同記事を参照してください。 blog.g-gen.co.jp 当記事で前提となるサンプル構成 HTTPS リダイレクト用の HTTPRoute リソースを追加する HTTPS リダイレクト構成前の動作確認 サンプル構成では HTTPS リダイレクトを構成しておらず、また Gateway リソースに HTTP リスナーを設定していないため、HTTP リクエストがロードバランサーを通過することはありません。 HTTPS リダイレクトを構成していない場合は HTTP でサービスにアクセスできない HTTPS リダイレクト専用の Namespace を作成する まず、HTTPS リダイレクト用の HTTPRoute を作成するための Namespace を作成します。 HTTPS リダイレクト用の HTTPRoute リソースは、 Gateway リソースと別の Namespace に作成する 必要があります。もし両方とも同じ Namespace に作成した場合、Gateway が受信した HTTP リクエストは HTTPS にリダイレクトされず、そのままバックエンドサービスにルーティングされてしまいます。 # redirect-namespace.yaml apiVersion : v1 kind : Namespace metadata : name : http-redirect labels : otherInfra : httpToHttps Gateway リソースに HTTP 用のリスナーを記述する Gateway リソースを定義している サンプル構成のマニフェストファイル（gateway.yaml） に対して、以下のように HTTP 用のリスナーを追記します。HTTP のリスナーとして、先ほど作成した HTTPS リダイレクト用 Namespace の HTTPRoute リソースを指定しておくことがポイントです。 # gateway.yaml apiVersion : gateway.networking.k8s.io/v1 kind : Gateway metadata : name : external-https-gateway annotations : networking.gke.io/certmap : "my-cert-map" spec : gatewayClassName : gke-l7-global-external-managed listeners : - name : https-listener protocol : HTTPS port : 443 - name : http-listener # HTTP 用のリスナーを追加する protocol : HTTP port : 80 allowedRoutes : kinds : - kind : HTTPRoute namespaces : from : Selector selector : matchLabels : otherInfra : httpToHttps # リダイレクト用 Namespace のラベル このマニフェストファイルを適用すると、HTTPS 用のロードバランサーとは別に、HTTP をリダイレクトするためのロードバランサーも作成されます。 リダイレクト用のロードバランサーが作成される リダイレクト用の HTTPRoute リソースを作成する HTTPS リダイレクト用の設定を定義した、新たな HTTPRoute リソースを作成します。マニフェストファイルは以下のようになります。 # http-redirect.yaml kind : HTTPRoute apiVersion : gateway.networking.k8s.io/v1 metadata : name : http-redirect namespace : http-redirect # リダイレクト用 Namespace に作成する spec : parentRefs : - name : external-https-gateway # Gateway リソースの名前 sectionName : http-listener # Gateway リソースで定義している HTTP リスナーの名前 rules : - filters : - type : RequestRedirect # リクエストをリダイレクトする設定 requestRedirect : scheme : https # HTTPS にリダイレクトする 作成した HTTPRoute リソースの設定を確認すると、 Spec.Rules にリダイレクトの設定が存在することが確認できます。 # 作成した HTTPS リダイレクト用 HTTPRoute の設定を確認する $ kubectl describe httproutes -n http-redirect Name: http-redirect Namespace: http-redirect Labels: < none > Annotations: < none > API Version: gateway.networking.k8s.io/v1 Kind: HTTPRoute Metadata: Creation Timestamp: 2025-08-31T07:47:01Z Generation: 2 Resource Version: 1756626613357455008 UID: 143532f1-8f96-4b95-bd28-8294d21e38eb Spec: Parent Refs: Group: gateway.networking.k8s.io Kind: Gateway Name: external-https-gateway Namespace: default Section Name: http-listener Rules: Filters: Request Redirect: Scheme: https Status Code: 302 Type: RequestRedirect Matches: Path: Type: PathPrefix Value: / 動作確認 まず、ブラウザから HTTP でアクセスしてみます。HTTPS でサービスに接続できていることがわかります。 HTTP リクエストが HTTPS にリダイレクトされている リダイレクトの動作を確認するため、curl コマンドで HTTP リクエストを送信してみます。 HTTP/1.1 302 Found 、 https://example.com:443/ より、リクエストが HTTPS にリダイレクトされていることがわかります。 # ロードバランサーに HTTP リクエストを送信してリダイレクトの動作を確認する $ curl -v http://example.com ----- 出力例 ----- * Trying xxx.xxx.xxx.xxx:80... * Connected to example.com ( xxx.xxx.xxx.xxx ) port 80 ( #0) > GET / HTTP/ 1 . 1 > Host: example.com > User-Agent: curl/ 7 . 88 . 1 > Accept: */* > < HTTP/ 1 . 1 302 Found < Cache-Control: private < Location: https://example.com:443/ < Content-Length: 0 < Date: Sun, 31 Aug 2025 07:53:13 GMT < Content-Type: text/html ; charset =UTF -8 < * Connection #0 to host example.com left intact 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-genの min です。本記事では、BigQuery の INFORMATION_SCHEMA に対するクエリ例を紹介します。コスト管理、開発の効率化、運用のために活用してください。 仕様 INFORMATION_SCHEMA とは 料金 必要な権限 制約事項 注意点 コスト・リソース管理 高額クエリを特定する ユースケース SQL スロット使用量の推移を分析し、ボトルネックを特定する ユースケース SQL 組織全体のストレージ使用量をプロジェクト別に把握する ユースケース SQL 開発・デバッグ効率化 テーブルのスキーマ情報を素早く確認する ユースケース SQL テーブルの DDL（テーブル作成クエリ）を取得する ユースケース SQL パーティションテーブルの情報を調査する ユースケース SQL データセット内のビュー定義を一覧で確認する ユースケース SQL クエリのエラー履歴を確認する ユースケース SQL 運用 ストアドプロシージャの実行履歴を調査する ユースケース SQL プロシージャや UDF の定義と引数を調査する ユースケース SQL 仕様 INFORMATION_SCHEMA とは INFORMATION_SCHEMA とは、BigQuery のジョブ履歴、テーブルやビューのメタデータ、ストレージ使用量などを保持するシステムビューです。 これらのビューに対して SQL クエリを実行することで、BigQuery に関するメタデータを網羅的に取得できます。コスト管理、パフォーマンスチューニングなど、データ基盤の運用にあたって INFORMATION_SCHEMA の理解は必須です。 参考 : INFORMATION_SCHEMA の概要 料金 INFORMATION_SCHEMA のビューに対するクエリは、通常のテーブルへのクエリと同様に課金対象となります。 クエリは キャッシュされない ため、同じクエリを繰り返し実行した場合でも、その都度クエリ料金が発生します。またプロジェクトの BigQuery 課金設定がオンデマンドの場合、通常のクエリと同様、 最低 10 MB が課金バイトとしてカウントされます。 参考 : INFORMATION_SCHEMA の概要 - 料金 必要な権限 INFORMATION_SCHEMA の各ビューをクエリするには、特定の IAM 権限が必要です。本記事に登場するビューとそれに必要な権限は以下の通りです。 対象ビュー スコープ　　　　　 必要な権限（Permission） 主な事前定義ロール（Role） JOBS_BY_USER プロジェクト bigquery.jobs.list BigQuery ユーザー（roles/bigquery.user） JOBS_BY_PROJECT JOBS_TIMELINE_BY_PROJECT プロジェクト bigquery.jobs.listAll BigQuery リソース閲覧者（roles/bigquery.resourceViewer） COLUMNS PARTITIONS VIEWS プロジェクト bigquery.tables.get bigquery.tables.list BigQuery データ閲覧者（roles/bigquery.dataViewer） PARAMETERS プロジェクト bigquery.routines.get bigquery.routines.list BigQuery データ閲覧者（roles/bigquery.dataViewer） TABLE_STORAGE_BY_ORGANIZATION 組織 bigquery.tables.get bigquery.tables.list BigQuery データ閲覧者（roles/bigquery.dataViewer） 組織やフォルダレベルのビューをクエリするには、権限がそれぞれのレベルで付与されている必要があります。また、これらのビューは、プロジェクトが組織に所属している場合にのみ利用可能です。 詳細については、公式ドキュメントをご参照ください。 参考 : JOBS ビュー - 必要なロール 参考 : JOBS_TIMELINE_BY_USER ビュー - 必要な権限 参考 : COLUMNS ビュー - 必要な権限 参考 : PARTITIONS ビュー - 必要な権限 参考 : PARAMETERS ビュー - 必要な権限 参考 : TABLE_STORAGE_BY_ORGANIZATION ビュー - 必要な権限 制約事項 INFORMATION_SCHEMA を用いたコスト分析にはいくつかの制約事項があります。これらの点を考慮した上で、本記事のクエリ例をご利用ください。 行レベルセキュリティ が設定されたテーブルに対するクエリでは、課金対象バイト数などの一部の統計情報が隠される場合があります。 BigQuery ML のモデル作成ジョブではモデルの種類によって料金が異なりますが、 INFORMATION_SCHEMA.JOBS ではモデルの種類を判別できないため、本記事のようなコスト計算は概算値となります。 Apache Spark プロシージャ の利用料金も INFORMATION_SCHEMA.JOBS では total_bytes_billed に含まれる場合がありますが、通常のクエリ利用と区別することはできません。 上記は INFORMATION_SCHEMA.JOBS ビューの注意点を例として挙げました。詳細は各ビューのドキュメントを参照してください。 参考 : JOBS ビュー - 制限事項 注意点 多くの INFORMATION_SCHEMA ビューは、 region-asia-northeast1.INFORMATION_SCHEMA.JOBS_BY_PROJECT のようにリージョン修飾子を付けてアクセスする必要があります。クエリを実行する際は、対象リソースが存在するリージョンを正しく指定してください。 本記事のサンプルクエリでは、 region-asia-northeast1 と記載している箇所をご自身の環境に合わせて書き換えてください。 参考 : INFORMATION_SCHEMA の概要 - 構文 コスト・リソース管理 高額クエリを特定する ユースケース 予期せぬ高額クエリ（スキャン量が多いクエリ）が実行されていないか定期的にチェックし、コストを最適化したい。 SQL 過去30日間でスキャン量が多かったクエリ TOP 20を、実行ユーザーやクエリ内容とともにリストアップします。 -- 過去30日間でスキャン量が多かったクエリ TOP 20 SELECT user_email, job_id, -- TB単位に変換 ROUND (total_bytes_billed / POW( 1024 , 4 ), 4 ) AS terabytes_billed, -- オンデマンド料金（東京リージョン: $7.5/TB）でコストを概算 ※2025年8月時点 (total_bytes_billed / POW( 1024 , 4 )) * 7.5 AS estimated_cost_usd, creation_time, -- クエリ内容を確認しやすくするために改行をスペースに置換 REGEXP_REPLACE (query, r ' \n ' , ' ' ) AS query_oneline FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE creation_time BETWEEN TIMESTAMP_SUB( CURRENT_TIMESTAMP (), INTERVAL 30 DAY) AND CURRENT_TIMESTAMP () AND total_bytes_billed > 0 AND job_type = ' QUERY ' ORDER BY total_bytes_billed DESC LIMIT 20 ; スロット使用量の推移を分析し、ボトルネックを特定する ユースケース 特定の時間帯にクエリが遅くなることがあるため、時間帯ごとのリソース（スロット）消費量の傾向を分析し、負荷の高い時間帯を特定したい。 SQL JOBS_TIMELINE_BY_PROJECT を使って、1時間ごとの合計スロット使用時間（ total_slot_ms ）を集計し、負荷の高い時間帯を特定します。 -- 過去24時間の時間帯別（1時間ごと）の合計スロット使用時間を集計 SELECT -- 時間を切り捨ててグルーピング TIMESTAMP_TRUNC(period_start, HOUR) AS usage_hour, -- スロット使用時間（秒）に変換 SUM (period_slot_ms) / 1000 AS total_slot_seconds FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT WHERE period_start >= TIMESTAMP_SUB( CURRENT_TIMESTAMP (), INTERVAL 24 HOUR) GROUP BY usage_hour ORDER BY usage_hour; 組織全体のストレージ使用量をプロジェクト別に把握する ユースケース 複数のプロジェクトをまたいで、組織全体のストレージ使用量をプロジェクト別に集計し、コスト管理に役立てたい。 SQL TABLE_STORAGE_BY_ORGANIZATION ビューを使い、組織内のプロジェクト別ストレージ使用量ランキングを作成します。 -- 組織内のプロジェクト別ストレージ使用量ランキング SELECT project_id, ROUND ( SUM (total_physical_bytes) / POW( 1024 , 4 ), 2 ) AS total_physical_tb FROM `region-asia-northeast1`.INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION GROUP BY project_id ORDER BY total_physical_tb DESC ; 開発・デバッグ効率化 テーブルのスキーマ情報を素早く確認する ユースケース 開発中に、参照したいテーブルのカラム名、データ型、NULL許容かなどをSQLエディタから離れずに確認したい。 SQL COLUMNS ビューで、特定テーブルのカラム情報を一覧表示します。 -- 特定テーブルのカラム詳細を取得 SELECT column_name, ordinal_position, data_type, is_nullable, column_default FROM `my-project.my_dataset.INFORMATION_SCHEMA.COLUMNS` WHERE table_name = ' my_table ' ; テーブルの DDL（テーブル作成クエリ）を取得する ユースケース 既存のテーブル定義を元に新しいテーブルを作成したい場合などに、テーブルの DDL（ CREATE TABLE 文）を直接取得します。 SQL TABLES ビューの ddl カラムから、特定のテーブルのDDLを取得します。 -- 特定テーブルのDDLを取得 SELECT table_name, ddl FROM `my-project.my_dataset.INFORMATION_SCHEMA.TABLES` WHERE table_name = ' my_table ' ; パーティションテーブルの情報を調査する ユースケース パーティションプルーニング が意図通りに機能しているか確認したい。また、どのパーティションにどれくらいのデータが入っているか調査したい。 SQL PARTITIONS ビューで、パーティションごとの行数やデータサイズを確認します。 PARTITIONS ビューは 2025年8月現在、プレビュー機能です。仕様が変更される可能性がある点にご注意ください。 -- パーティションテーブルのパーティションごとの情報を取得 SELECT table_name, partition_id, total_rows, -- MB単位に変換 ROUND (total_logical_bytes / POW( 1024 , 2 ), 2 ) AS logical_mb, last_modified_time FROM `my-project.my_dataset.INFORMATION_SCHEMA.PARTITIONS` WHERE table_name = ' my_partitioned_table ' -- 古いパーティションから表示 ORDER BY partition_id ASC ; データセット内のビュー定義を一覧で確認する ユースケース データセット内にどのようなビューが存在し、どのテーブルを参照しているのかを、定義 SQL（ソースコード）とあわせて一覧で確認したい。 SQL VIEWS から、ビューの定義を直接取得します。 -- 特定のデータセット内のビュー一覧とその定義を取得 SELECT table_name AS view_name, view_definition FROM `my-project.my_dataset.INFORMATION_SCHEMA.VIEWS`; クエリのエラー履歴を確認する ユースケース 「先ほど実行したクエリがエラーになったが、エラーメッセージを見失ってしまった」という状況で、エラーの原因を素早く特定したい。 SQL JOBS_BY_USER を使い、自分が実行してエラーになったクエリの履歴を遡ります。 -- 過去7日間で自分が実行し、エラーになったクエリの一覧 SELECT creation_time, job_id, error_result.reason, error_result.message, query FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_BY_USER WHERE creation_time BETWEEN TIMESTAMP_SUB( CURRENT_TIMESTAMP (), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP () AND state = ' DONE ' AND error_result IS NOT NULL ORDER BY creation_time DESC ; 運用 ストアドプロシージャの実行履歴を調査する ユースケース 特定のバッチ処理として実装されたストアドプロシージャが、いつ、誰によって実行されたか、またはエラーになっていないかを監査したい。 SQL JOBS_BY_PROJECT の query カラムをフィルタリングして、特定のプロシージャの呼び出し履歴を抽出します。 -- 特定のプロシージャの実行履歴を取得 SELECT job_id, creation_time, start_time, end_time, TIMESTAMP_DIFF(end_time, start_time, SECOND) AS execution_seconds, user_email, statement_type, -- エラーが発生した場合は理由とメッセージを表示 error_result.reason, error_result.message FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE -- 調査したいプロシージャ名でフィルタ query LIKE ' %CALL `my-project.my_dataset.my_procedure`% ' AND creation_time >= TIMESTAMP_SUB( CURRENT_TIMESTAMP (), INTERVAL 30 DAY) ORDER BY creation_time DESC ; プロシージャや UDF の定義と引数を調査する ユースケース リージョン内にどのようなプロシージャや UDF（ユーザー定義関数）が定義されているか網羅的に棚卸ししたい。また、特定のプロシージャや UDF について、その引数の詳細を調査したい。 SQL ROUTINES ビューを使うと、リージョン内のプロシージャや関数の一覧を取得できます。一方、 PARAMETERS ビューでは、特定のルーチンの引数の詳細を確認できます。 -- プロジェクト内の全データセットのプロシージャと UDF を一覧表示 SELECT routine_schema, routine_name, specific_name, -- パラメータ検索用に specific_name を取得 routine_type, -- PROCEDURE または FUNCTION data_type, -- 関数の戻り値の型 routine_definition FROM `region-asia-northeast1`.INFORMATION_SCHEMA.ROUTINES ORDER BY routine_schema, routine_name; -- 上記クエリで取得した specific_name を使い、特定の関数の引数情報を取得 SELECT parameter_name, data_type, parameter_mode -- IN, OUT, INOUT FROM `my-project.my_dataset.INFORMATION_SCHEMA.PARAMETERS` WHERE specific_name = ' my_function_name ' ; 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-genの杉村です。今回は、生成 AI に関してよくある誤解と、それに対する事実を紹介します。これらは生成 AI と AI エージェントを、組織の業務に適用していくうえで知っておくべき基本的な知識です。 生成 AI に関するよくある誤解 生成 AI は確率的にテキスト等を生成するだけ 生成 AI とは 生成 AI の学習 確率的な特性 モデルは「今」を知らない 思考/推論 誤解と事実 生成 AI モデルは1+1すらできない 計算も Web サイト読み込みもできない AI を助ける tools Gemini アプリや ChatGPT の挙動 誤解と事実 モデルは「学習しない」 モデルの使用と学習 学習に見える挙動 サービス改善に使われるデータ 精度を上げるには 誤解と事実 AI エージェントの業務適用 AI エージェントとは AI エージェントと tools AI エージェントができること ノーコードエージェント AI の業務適用 本当に AI である必要があるのか AI の業務導入 AI アプリケーションの開発 生成 AI に関するよくある誤解 以下の表に、生成 AI に関してよく聞かれる誤解と、それに対する事実をまとめました。 誤解 事実 生成 AI は思考する。 生成 AI は確率的にテキスト等を生成するだけ。 ただし思考しているかのような挙動を見せることはできる 生成 AI は複雑な問題に対処できる。 生成 AI は単体では1+1すらできない。 tools の助けが必要。 生成 AI は学習する。 生成 AI モデルは、新しいデータを学ぶことは原則的にない。 ただし AI サービス提供ベンダーが、ユーザーの使用履歴を新しいモデルの学習に利用する可能性はある。 また AI サービスの使用履歴をコンテキストとして読み込むことで、学習したかのように見えることはある。 生成 AI と AI エージェントを適切に組織の業務に適用していくためには、上記に対する適切な理解が必要です。 当記事では上記について、生成 AI に関する基本的な知識と共に解説します。 生成 AI は確率的にテキスト等を生成するだけ 生成 AI とは 生成 AI （Generative AI）とは、テキスト、画像、音声、ソースコードなど、新しいコンテンツを生成することができる人工知能の一種です。 従来の AI が主にデータの分類や予測、画像認識などを得意としていたのに対し、生成 AI は学習したデータに基づいて、これまで存在しなかった新しいコンテンツを生成する能力を持ちます。生成 AI を利用した代表的なサービスとして、Google の Gemini アプリ や OpenAI の ChatGPT などが挙げられます。 参考 : Google Gemini 参考 : ChatGPT これらの AI サービスの中核となっているのは、 大規模言語モデル （LLM）です。LLM は、膨大なテキストデータを学習し、ある単語の次にどの単語が来る確率が最も高いかを 統計的に予測 することで文章を生成します。 生成 AI の学習 前述の通り、LLM は膨大なテキストデータを学習しています。このとき、「この単語の後には、次はこの単語が来やすい」という傾向を 統計的に学習 します。また LLM は学習時に、単純に隣接した単語の関係性を学ぶだけでなく、Transformer という仕組みを使って、文章全体の文脈を「理解」します。 参考 : 大規模言語モデルの概要 - Google for Developers この学習の結果として、LLM（あるいは単に モデル ）が誕生します。代表的なモデルとして、Google の Gemini 2.5 Pro や Gemini 2.5 Flash 、また OpenAI の GPT-4o 、 GPT-5 、 GPT-5 mini などがあります。 参考 : Google models - Google Cloud 参考 : Models - OpenAI API ここで挙げたモデルの名称と、AI サービスの名称を混同しないように注意してください。Gemini 2.5 Pro、GPT-5 といったモデルを搭載し、ユーザーに AI チャットを提供するサービスの名前が、Gemini アプリや ChatGPT です。 サービス名 サービスが使うモデル名 Gemini アプリ Gemini 2.5 Pro、Gemini 2.5 Flash 等 ChatGPT GPT-5、GPT-5 mini 等 上記を模式図にすると以下のようになります。以下は Gemini アプリの例ですが、ChatGPT でも似た図になります。 AI サービスとモデルの関係 確率的な特性 人間が プロンプト と呼ばれるテキスト（あるいは時には画像、音声、動画）をモデルに渡すことで、モデルは処理を開始します。モデルは、ある単語の次にどの単語が来る確率が最も高いかを、 統計的に予測 することで文章を生成します。 以下の Google の公式記事は、生成 AI モデルは 確率エンジンである としています。あくまでモデルは、過去に学習したデータに基づいて確率的に文章を生成しているのだ、という点に注意が必要です。本質的に、そこに論理や思考は存在していません。モデルは人間のように意味を理解して対話しているわけではなく、あくまで確率に基づいた「それらしい」応答を生成しているに過ぎません。また同じ質問を複数回すると、返って来る答えが同じになるとは限りません。 参考 : The Prompt: 確率、データ、そして生成 AI に向き合うマインドセットとは この特性により、生成AIはいわゆる ハルシネーション （もっともらしい嘘）を生成することがあります。入力された情報や学習データにない事柄について質問された場合でも、モデルは最も確率の高い単語を繋ぎ合わせて、事実に基づかない情報を生成してしまう可能性が十分にあるのです。 参考 : AI ハルシネーションとは - Google Cloud 最新のモデルや AI サービスでは、生成結果の正しさを検証するプロセスが実行されたり、後述の「RAG」といった技術により正しさを補強する機能が備わったことにより、ハルシネーションを軽減する試みがなされています。とはいえ、生成された内容は必ずファクトチェック（事実確認）を行う必要があります。 モデルは「今」を知らない また、モデルは過去に学習したデータをもとに生成を行います。よってモデルは、「現在の天気」や「最新の Web ページの内容」などを知ることはできません。モデルは、 学習が行われた時期より後に起こった出来事を知らない のです。 Gemini シリーズのモデルでは、モデルがいつの時点のデータを使って学習されたかが明示されています。例えば Gemini 2.5 Pro は2025年1月時点のデータを使って学習しているので、それ以降の世の中の情報を知りません。 参考 : Google models - Google Cloud しかし、Gemini アプリや ChatGPT に、最近の時事について質問すると、適切に答えることがあります。この挙動は、後述する「tools」や「RAG」といったテクニックにより、モデルが 現実世界の新しい情報を随時取得 していることにより実現しています。モデル自体は最近のニュースを知らないため、外部から情報を取得しているのです。 思考/推論 生成 AI モデルや AI サービスの中には、あたかも思考しているかのような挙動を見せるものもあります。これらの挙動は思考（thinking）や推論（reasoning）と呼ばれ、モデルの特徴として位置づけられています。 Gemini 2.5 Pro/Flash/Flash-Lite や、GPT-5、GPT-5 mini はいずれもこれらの思考/推論の機能を備えたモデルです。 この機能の中核にあるのは、Chain-of-Thought（CoT、思考の連鎖）と呼ばれる技術です。この技術では、モデルは思考の途中プロセスをテキストとして生成し、それを次の生成へのインプットにして、また次の生成を行います。この連鎖を行うことで、多段階の思考を実現しています。 例えば、「太郎君はリンゴを5個持っていました。花子さんから3個もらい、その後2個食べました。残りは何個ですか？」という問題に対して、LLMは次のように思考を文章化します。 初期状態: 太郎君は最初にリンゴを5個持っている。 変化1: 花子さんから3個もらったので、5 + 3 = 8個になる。 変化2: その後2個食べたので、8 - 2 = 6個になる。 結論: したがって、残りのリンゴは6個である。 このアプローチは、人間が複雑な問題を解く際に、頭の中や紙の上で段階的に考えるプロセスを模倣しています。ポイントは、あくまで LLM の基本である「確率的にテキストを生成する」という挙動しか行っていないことです（途中で後述の「tools」を使うことはあります）。 誤解と事実 誤解 事実 生成 AI は思考する。 生成 AI は確率的にテキスト等を生成するだけ。 ただし思考しているかのような挙動を見せることはできる これを理解すれば、以下のような誤謬を回避することができます。 生成 AI は思考しており、「正しい」答えを導いてくれる 生成 AI は想定どおりの答えを毎回同じように回答してくれる 生成 AI は感情を持つかもしれない 上記の誤謬を避けられれば、AI の適用対象業務の選定や適用のさせ方を適切に検討できます。 生成 AI モデルは1+1すらできない 計算も Web サイト読み込みもできない 前述した「生成 AI は確率的にテキスト等を生成するだけ」という特性から、生成 AI モデルは「1+1」という 簡単な計算すら行うことはできません 。とはいえ「1+1」であれば、学習した言語的なデータに基づいてあたかも計算をしたかのような回答をすることはありますが、複雑な計算はできません。 当記事ならではの言い回しですが、「 生成 AI は根っからの文系である 」ということもできます。 同様に、以下のような作業は、いずれも生成 AI モデル単体では、正確に行うことはできません。 数値の計算や集計 URL に基づいた Web サイトの読み込み 外部のアプリケーションやデータベースとの連携 モデルが実行できるのは、 確率的にテキスト等を生成することだけである と考えればわかりやすいと言えます。 AI を助ける tools しかし、Gemini アプリや ChatGPT に数学の問題を与えると、高度な問題も解けることがあります。また難しい質問や時事に関する質問をすると、Web サイトの情報を取得してそれに基づいて回答してくれることもあります。 これが実現可能なのは、これらの Web サービスに tools という仕組みが組み込まれているからだと考えられます。 tools は、その名のとおり、生成 AI が使う道具です。その実体はいわゆる 通常のコンピュータプログラム です。通常のプログラムであれば、四則演算や Web サイトの取得などを、速く正確に行うことができます。Gemini アプリや ChatGPT などの Web サービスは、人間から与えられた指示に応じて、tools（= 外部プログラム）を呼び出し、必要な計算を行ったり、Web サイト検索を行ったりすることで、タスクを遂行しています。この tools を「いつ呼び出すか」「どのように使うか」という一見論理的な判断は、文系脳の生成 AI モデルでも行うことができます。これは、プロンプトに含まれるキーワードや文脈から、どの tool が最適かを確率的に判断しているためです。 なおモデルが tools としてプログラムを呼び出す機能のことを function calling と呼びます。例として Gemini や GPT シリーズは、function calling 機能を持っています。 参考 : Introduction to function calling - Google Cloud 参考 : Function calling - OpenAI API Gemini アプリや ChatGPT の挙動 Gemini アプリや ChatGPT といった各社が提供する AI サービスでは、以下のような処理が行われていると考えることができます。 ユーザーが「345 × 123は？」などとプロンプトを入力する モデルがプロンプトの意図を言語的に解釈する モデルが tools を選択。「これは計算が必要なタスクだ」と判断し、内蔵されている計算ツールを選択する モデルが tools を実行。モデルが計算ツールに「345 * 123」という計算を実行させ、42435 という結果を受け取る モデルが応答を生成。計算ツールから受け取った結果を基に「345 × 123 の答えは 42,435 です。」といった自然な文章を生成してユーザーに返す Gemini アプリや ChatGPT といったサービスは、単にモデルへの入出力インターフェイスではなく、様々な tools などの仕組みが組み込まれたチャット型アプリケーションである、と言えます。 誤解と事実 誤解 事実 生成 AI は複雑な問題に対処できる。 生成 AI は単体では1+1すらできない。 tools の助けが必要。 これを理解すれば、以下のような誤謬を回避することができます。 tools を用意していないのにも関わらず、生成 AI モデルに外部サイトの URL を与えて読み込ませようとする tools を用意していないのにも関わらず、生成 AI モデルに数値の計算や分析をさせようとする 上記の誤謬を避けられれば、AI エージェントや AI アプリケーションを開発する際に、適切に仕様を検討したり、Gemini Enterprise（旧称 Google Agentspace）や Dify といった AI プラットフォームやローコード/ノーコードエージェント開発ツールで、適切に開発を行うことができます。 モデルは「学習しない」 モデルの使用と学習 生成 AI に関するよくある誤解の1つとして、「Gemini アプリや ChatGPT といったサービスを使っていると、入力したデータがモデルに随時、学習される」といったものがあります。 これは、使っていくうちにモデルがユーザーのことを理解して、より使い勝手がよくなるのであるというポジティブな見方の側面もあれば、逆に顧客データや機密データを学習されてしまう、というネガティブな捉え方をしている人もいます。 しかし実際には、生成 AI モデルは入力されたデータを学習するということは ありません 。「生成 AI の学習」の項で説明したように、モデルは大量のデータに基づいた学習のアウトプットとして誕生します。そして一度誕生したモデルは、原則的に追加のデータを学習することはありません（後述のファインチューニングといった手法を除く）。よって、Gemini アプリや ChatGPT に入力したデータや、出力されたアウトプットが随時学習され、見ず知らずの他人に提供されてしまうということはありえません。 学習に見える挙動 一方で、Gemini アプリや ChatGPT がユーザーとのやり取りを学習したと思える挙動を見せることがあります。 これは、以下のいずれかの機能に由来しています。 コンテキスト メモリ コンテキスト とは、モデルが生成を行う際に、背景情報として使う情報です。Gemini アプリや ChatGPT で、会話スレッドを始めると、同じスレッド内であれば前の会話を AI が覚えていて、一貫性のある会話が成り立ちます。これは、AI が生成を行う際に、都度以前の会話をコンテキスト（背景情報）として参照して生成を行っているためです。生成の都度、コンテキストを読み込んでいるため、これは学習ではありません（モデル自体は何も変化していません。モデルへのインプットが変化しています）。 また メモリ とは、Gemini アプリや ChatGPT の Web アプリケーションに組み込まれた機能であり、過去のスレッドでの会話を AI が覚えているかのように会話が行える機能です。AI が最近の会話を自動的に参照するため、使えば使うほど AI がパーソナライズされていき、使い勝手がよくなります（Gemini アプリの場合はこの機能は「パーソナルコンテキスト」と呼ばれており、2025年12月現在、個人向けプラン・一部の地域でのみ利用可能です）。 参考 : Gemini アプリでのエクスペリエンスをパーソナライズする - Gemini アプリ ヘルプ 参考 : ChatGPT のメモリと新しいコントロール この機能は、モデルが最近の会話の内容を都度コンテキストとして使っている、もしくは RAG（後述）の対象として使用することで実現していると考えられます。 これらの手段は、モデルが学習していない、外部データを使用するため インプットを充実させる 手法であり、 モデルが学習して変化するわけではありません 。よって、データへのアクセス権限が適切に管理されている限り、これらの機能によってモデルを通じて他人にデータが漏洩してしまう心配もありません。 サービス改善に使われるデータ それでは、生成 AI サービスを使う際によく話題になる「入力したデータや出力されたデータが、サービス提供事業者によってサービスの改善やモデルの学習に使われるかどうか」という議論は、何のためのものなのでしょうか。 これは、Google や OpenAI といったサービス提供事業者が、 新しいモデルを開発 したり、Gemini アプリや ChatGPT といった AI サービスの改善にデータを利用するかどうかを指しています。つまり、ユーザーが入力したデータや AI によって出力されたデータは、直ちにそのモデルが学習するわけではありませんが、データがサービス提供事業者によって蓄積され、 新しいモデルの学習に使われる可能性 がある、ということを指しています。 これにより、新しく開発されるであろう次期モデルの学習には、無償版の AI サービスのユーザーが入力したデータ等が学習に使われる可能性が十分あります。機密データが次期モデルの学習に使われると、次期モデルではそのアウトプットに学習データが含まれる可能性がゼロではありません。これが、企業の AI 利用者がデータのプライバシーポリシーを適切に理解しなければならない理由です。 なお Google が提供するモデルに関しては、有償のサービス（Google Cloud や Google Workspace） に含まれる AI 機能について、入出力データはモデルの学習やサービス改善に使われることはない、とドキュメントや利用規約に明記されています。 参考 : 生成 AI とデータ ガバナンス - Google Cloud 参考 : Service Specific Terms - Google Cloud 参考 : Google Workspace with Gemini に関するよくある質問 - Google Workspace 管理者ヘルプ 参考 : Google Workspace の生成 AI に関するプライバシー ハブ - Google Workspace 管理者ヘルプ 一方で、個人向け・無償版の Google アカウントで使用する Gemini アプリ等では、データはサービス改善に使われる可能性があります。 精度を上げるには 既存のモデルが学習して変化するわけではないとしたら、モデルの精度を上げたり、自社の業務への適応度を向上させるにはどうすればよいでしょうか。 いくつかの方法がありますが、以下のような代替手段が考えられます。 コンテキストを与える Retrieval-Augmented Generation（RAG） ファインチューニング 上記を、順番に説明します。 1. コンテキストを与える 最も簡単な方法は、モデルへのインプットに コンテキスト （背景情報）を与えることです。AI への指示だけではなく、その指示の背景情報を含ませてプロンプトとしてモデルに与えることで、モデルは過去に学習していないデータも使用して生成を行うことができます。このように、特に背景情報として読み込ませるプロンプトのことを システム指示 （System Instruction）と呼ぶこともあります。 例えば、モデルに日報を書かせる場合は、以下のような情報をコンテキストとしてプロンプトに含ませることが有用です。 ペルソナ（どういった人物の立場から記述するか） 日報を書いている背景（誰のために、何のためになど） 日報の基になる業務履歴（メールのやりとり、カレンダーの予定、成果物等） 日報の体裁 特に Gemini はロングコンテキストモデルと呼ばれています。Gemini 2.5 Pro や Flash は100万トークンのコンテキストを受け付けることができます。 トークン とは、LLM が入出力する文字を理解するために分割した結果をカウントする単位です。Gemini の場合、英語の処理では概ね「約4文字が1トークン」「約60～80単語が100トークン」とされています。 参考 : トークンを理解してカウントする - Google AI for Developers つまりGemini は、英語でいうと80万単語ほどのプロンプトを一度に受け取ることができます。コンテキストとして十分な情報をインプットすることで、アウトプットの精度が向上します。 2. Retrieval-Augmented Generation（RAG） Retrieval-Augmented Generation （RAG）は、生成 AI モデルが外部のデータを参照するための手法、またはアーキテクチャのことです。RAG では、モデルにプロンプトとして直接情報を与えるのではなく、外部のデータベースを参照させます。例として、API 経由で Gemini を呼び出す場合、Google Cloud と組み合わせることで、Cloud Storage に格納した文書や BigQuery テーブルを RAG の対象として使用できます。 特に AI アプリケーションを開発したり、AI エージェントを開発するときに、RAG は重要です。AI が自社の業務やデータに適応した振る舞いをするには、RAG を構成することが有効に働きます。また、そのためには RAG の対象とするデータの整備が必要です。すなわち、文書が一箇所のストレージに集約されていたり、あるいはデータベースにきれいなフォーマットで格納されている必要があります。 3. ファインチューニング ファインチューニング は、モデルに追加の学習を施すことです。特定の業務に特化させたり、振る舞いを特定させることができます。この手法は前述の2つの手法と違い、実際に学習を行い、派生版のモデルを作成する作業です。しかし、前述の2つの手法よりも、より労力が大きいものになります。Gemini の場合、有意なファインチューニングを行うには、学習用データとしてプロンプトと応答のセットを数百個用意する必要があります。また一度モデルを開発すると、精度を維持するためには、継続してデータセットを準備して学習し続ける必要があるため、その労力は大きいものとなります。 参考 : About supervised fine-tuning for Gemini models - Google Cloud 参考 : Gemini の教師ありファインチューニング: ベスト プラクティス ガイド - Google Cloud 誤解と事実 誤解 事実 生成 AI は学習する。 生成 AI モデルは、新しいデータを学ぶことは原則的にない。 ただし AI サービス提供ベンダーが、ユーザーの使用履歴を新しいモデルの学習に利用する可能性はある。 また AI サービスの使用履歴をコンテキストとして読み込むことで、学習したかのように見えることはある。 これを理解すれば、以下のような誤謬を回避することができます。 ツールを使っているうちに AI が徐々に賢くなるのを期待する AI が入力情報を学習することを恐れて、業務導入に否定的になる 上記の誤謬を避けて、AI サービスのプライバシーポリシーやデータの扱いに関する規約を適切に理解しましょう。さらに、AI への適切なコンテキスト情報のインプットを図ったり、データの整備と RAG 構成を構築することにより、AI の精度を上げ、実業務に適用させることができます。 AI エージェントの業務適用 AI エージェントとは 生成 AI の業務適用を語るにあたり、 AI エージェント の概念も解説します。AI エージェントとは、特定の目標を達成するために、自律的に状況を判断し、計画を立てて、遂行するシステムのことです。特に、その思考エンジンとして生成 AI モデルを使用しているものを指します。 参考 : AI エージェントとは - Google Cloud 単にユーザーの指示に応答を返すだけの生成 AI チャットボット等とは異なり、AI エージェントは「出張の手配をする」といった曖昧な指示に対して、必要なタスク（航空券の予約、ホテルの予約、スケジュールの登録など）を自ら分解し、それぞれに対応する tools を順番に実行することで、目標を達成します。 AI エージェントと tools ここで重要なのが、前述の tools です。繰り返しになりますが、基本的にモデルが実行できるのは、確率的なテキスト生成です。生成 AI は、1+1という簡単な計算すら行うことはできません。AI エージェントは、生成 AI モデルを思考エンジンとして、tools、すなわち外部プログラムを自律的に判断して実行することでタスクを実行していきます。 また、AI エージェントは時として複数のエージェントを内包したマルチエージェントとして実装されます。以下は、 マルチエージェント として構成された AI エージェントの例です。 出張手配のためのマルチエージェント AI エージェントができること AIエージェントは、人間が行っていた定型的な業務や、複数のシステムを横断して行われる複雑なタスクを自動化することができます。例えば、以下のようなことが可能です。 情報収集と分析 : 複数のWebサイトや社内データベースから情報を収集し、レポートとして要約する タスクの自動化 : 経費精算システムへの入力、顧客情報のCRMへの登録、カレンダーへの予定登録などを自動で行う 顧客対応 : 顧客からの問い合わせ内容を解釈し、FAQデータベースを検索して回答したり、必要に応じて担当者へエスカレーションしたりする 2025年12月現在、AI エージェントはまだ多くの組織で実験段階であり、業務改善や大きな RoI に繋がった事例は限定的です。以下は、株式会社G-genが商用環境で AI エージェントを公開している事例です。 参考 : ナレッジ検索・回答AIエージェントG-gen Tech AgentをADKで開発した事例 - G-gen Tech Blog 参考 : 株式会社G-gen、新サービス G-gen Tech Suite を提供開始 - 株式会社G-gen ノーコードエージェント ソースコードを記述することなく AI エージェントを開発できるノーコードエージェントソリューションも存在します。 Gemini Enterprise のノーコードエージェント機能はその代表です。ノーコードエージェントは、Gemini Enterprise に接続された外部データソースを取得したうえで、コンテンツ生成や要約などのタスクを行わせることができます。 Gemini Enterprise のノーコードエージェント AI の業務適用 本当に AI である必要があるのか 生成 AI や AI エージェントは強力なツールですが、あらゆる課題に対する万能薬ではありません。逆説的ではありますが、AI の導入を検討する前に、その課題が本当に 生成 AI で 解決すべきものなのかを考えるべきです。 課題によっては、生成 AI を使わずに従来の技術で十分に、あるいはより効率的に解決できる場合があります。 例えば、特定のキーワードが含まれていたら定型文を返すような単純な応答であれば、ルールベースのチャットボットで十分です。また、Excel のデータを別のシステムに転記するような作業は、RPA（Robotic Process Automation）の方が精度が高い可能性があります。商品カタログからあいまいな言葉で検索をかけて、迅速に商品ページの URL を返すようなシステムでは、セマンティック検索（意味論検索）機能を備えた検索システムが適切です。 生成 AI の出力結果は、不確実性を伴うため、より単純で確実な方法がある場合はそちらを優先すべきです。ミスが許されない業務を、生成 AI で完全に自動化するのは困難です。一方で、 人間の業務時間を短縮するための便利な道具 あるいは 人間の判断等を補助するアシスタント としての用途であれば、検討の余地はあります。 また現状、例えば後述の Agent Development Kit（ADK）を使って実装した Gemini 2.5 Flash ベースの AI エージェントにおいて、2〜3のエージェントがシーケンシャル（直列）に動いた場合、クエリ開始からレスポンスまで、20秒〜40秒のレイテンシがかかります。こういった処理時間が許容できるかどうかも、生成 AI や AI エージェントを採用するかどうかの検討要素になります。 AI の業務導入 ある程度は生成 AI による効果が見込めそうだと考えられる場合、まずは Google Workspace に組み込まれている AI 機能（Gemini for Google Workspace）など、ライセンスを購入すれば開発不要ですぐに使える（Out-of-the-box な）サービスの使用を検討します。 Gemini for Google Workspace は、Gmail、Google ドキュメント、スプレッドシートなどの日常的に利用する Google Workspace アプリに組み込まれた生成 AI 機能の総称です。メールの文面作成、文書の要約、議事録の作成、関数やマクロの自動生成など、専門的な知識がなくても、誰もがすぐに生成 AI の恩恵を受けることができます。 参考 : Gemini for Google Workspace 以下の記事も参照してください。 blog.g-gen.co.jp どうしても既存サービスで実現できない独特な要件がある場合に、AI アプリケーションの独自開発を検討します。この考え方については、以下の記事も参照してください。 blog.g-gen.co.jp AI アプリケーションの開発 AI アプリケーションの開発を決断する場合、Google Cloud や OpenAI など、AI モデル提供事業者等が提供する API を、インターネット越しにアプリケーションから呼び出す形で実現します。 参考 : 全Geminiプロダクトを徹底解説！ - G-gen Tech Blog あるいは、オープンモデルと呼ばれるようなモデルを直接サーバーに配置するような実現方法もあります。どのようにモデルを呼び出すかは、扱うデータの機密性、データの所在に関する規定、許容されるレイテンシなどから判断します。 また前述の AI エージェントを実装するには、例として以下のような方式が考えられます。 1. Agent Development Kit（ADK） Agent Development Kit （ADK）は、AI エージェントの開発、デプロイ、評価を効率化するために Google が開発したオープンソースのフレームワークです。ADK を利用することで、開発者は通常のソフトウェア開発と同じような感覚で、モジュール化された再利用可能なコンポーネントを組み合わせて AI エージェントを開発できます。ADK は Google の生成 AI モデル Gemini や Vertex AI などのエコシステムに最適化されていますが、特定のモデルやデプロイ環境に依存しない設計思想を持っており、高い柔軟性と拡張性を備えています。 参考 : Agent Development Kit ADK の仕様や実装例については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 2. Gemini Enterprise - ノーコードエージェント Gemini Enterprise は、Google（Google Cloud）が提供する生成 AI サービスです。組織内に分散しているドキュメント、メール、チャット履歴などのデータを横断検索し、情報の発見を手助けします。また AI エージェント機能により、カレンダーの登録やその他のタスクなどを人間の代わりに行います。 参考 : Gemini Enterprise とは何ですか？ Gemini Enterprise の Enterprise Plus ライセンスには、 ノーコードエージェント 開発機能が搭載されています。ユーザーの1人1人が手元で、ソースコードを書くことなく、エージェントを開発できます。 例えば以下のようなエージェントを開発可能です。 Cloud Storage 上の社内規定集から情報を取得して、社内規定の質問に答えてくれるエージェント Jira から情報を取得して、指定された名称の開発プロジェクトの状況をタイムライン順に報告するエージェント Gemini Enterprise 自体は Out-of-the-box なソリューションです。その中に含まれるノーコード開発機能は、ユーザーが自らノーコードでエージェントを開発できるため、「Out-of-the-box なソリューションの利用」と「独自アプリ開発」の中間的な選択肢と言えます。以下の記事も参考にしてください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の菊池です。Looker Studio の期間のディメンションについて解説します。 期間のディメンションとは ディメンションと指標 期間のディメンションとは 期間のディメンションの用途 期間設定 期間設定とは 期間設定の適用範囲 デフォルトの期間 デフォルトの期間の設定 比較期間 期間グラフの特長 期間設定とデフォルトの期間の使用例 コントロールで期間を設定したい場合 特定のグラフはコントロールの対象外にしたい場合 期間のディメンションとは ディメンションと指標 Looker Studio では、Google スプレッドシートや BigQuery をデータソースとして使用できます。レポート上では、フィールド（列）は ディメンション と 指標 の2種類に分けられます。 ディメンション とは、データをグループ化するためのフィールドです。例として「商品名」「商品ID」「国名」などが挙げられます。これらのフィールドは、数値として集計（合計や平均、カウント等）されることはありません。 指標 とは、集計して使用するフィールドです。例として「金額」「購入数」「人数」などがあります。ディメンションでグループ化され、合計値や平均値、あるいは件数としてカウントされるフィールドです。 グラフの作成後、右側のプロパティパネルで、フィールドをディメンションまたは指標として選択し、追加します。 参考 : データをモデル化する - フィールドの種類 右側プロパティパネルでディメンションや指標を選択 期間のディメンションとは 期間のディメンションとは、グラフのデータ表示期間を絞る際に使われる日付データのディメンションです。レポート上で、 期間設定 コントロールと呼ばれるフィルタを使って表示期間を設定（例えば「2025年4月から2025年9月末までの間にデータを絞り込んで表示」など）する際などに、基準となります。 期間のディメンション 期間のディメンションとして有効なのは「年、月、日」を含む日付型のデータです。ただし、元のデータソースに完全な日付型のフィールドがなくても、計算フィールド関数で日付型に変換することで、期間のディメンションとして使用することもできます。 一部のデータソースタイプ（Google 広告や Google アナリティクスなど）では、期間のディメンションは自動的に設定されてしまうため、ユーザーが変更することはできません。 グラフを作成する際、データソースに日付データのフィールドがあれば、それが自動的に期間のディメンションとして選択されます。 参考 : レポートの期間を設定する - 期間のディメンションを選択 期間のディメンションの用途 期間のディメンションはグラフにおいて、期間を指定する際の基準になります。主に以下の用途で使われます。 期間設定コントロールをグラフに反映する グラフにデフォルトの期間を設定する 前者は前述のとおり、レポート上に「期間設定」コントロールを配置した場合に、表示期間を絞るときに使われるケースです。 後者は、グラフに「デフォルトの期間（そのグラフに常に適用される期間）」を設定するときに使われるケースです。 期間設定 期間設定とは 期間設定 コントロールは、データの表示期間を設定（例えば「2025年4月から2025年9月末までの間にデータを絞り込んで表示」など）するためのコントロールです。コントロールとは、レポートに表示するデータをフィルタできる制御 UI のことです。 期間設定コントロール 期間設定コントロールでは、カレンダー形式の画面で日付を選択することで、レポートの表示する期間を調整できます。 開始日と終了日を選択して期間を設定するだけでなく、[昨日]、[直前の 7 日間（今日を含む）]、[直前の四半期] など、事前に定義された期間を選択することも可能です。 期間設定コントロールは、レポート編集時に「コントロールの追加」から「期間設定」を選択することで追加できます。 参考 : 期間設定 期間設定の適用範囲 デフォルトでは、期間設定はページ上のすべてのグラフに適用されます。期間設定コントロールを適用する対象のグラフを制限したい場合は、次のいずれかの方法を用います。 期間プロパティを個々のグラフに設定する 期間設定とグラフをグループ化する 編集画面でグラフをクリックして選択し、プロパティパネルの「デフォルトの期間のフィルタ」の設定値を『自動』から『カスタム』に変更してグラフごとに期間設定を行うことで、期間設定コントロールによる期間設定を上書きできます。 デフォルトの期間のフィルタ また期間設定コントロールとグラフをシフトキーを押しながらクリックして2つとも選択した状態で、[配置] > [グループ] を選択することで、期間設定とグラフをグループ化できます。 グループ化 期間設定とグラフをグループ化すると、期間設定によるフィルタはグループ内のグラフにのみ適用されます。 グループ化の結果 期間設定が反映されるのは、期間のディメンションを持つデータソースで作成されたグラフのみです。期間のディメンションが設定されていないと、期間設定コントロールは機能しません。 デフォルトの期間 デフォルトの期間の設定 グラフに期間のディメンションを設定すると、デフォルトの期間のフィルタを設定する項目が表示されるようになります。 デフォルトの期間のフィルタ グラフでデフォルトの期間を設定することで、そのグラフでどの期間のデータを表示するか指定できるようになります。 この設定は後述する期間設定コントロールよりも優先されるため、個々のグラフで表示する期間をカスタマイズできます。グラフにデフォルトの期間を設定すると、期間設定コントロールは効かなくなります。 比較期間 デフォルトの期間のフィルタには、前の期間とデータを比較できる比較期間という機能があります。 比較期間は、デフォルトの期間のフィルタの下にある比較期間をオンにすることで有効になります。 比較期間を使用できるコンポーネントは期間グラフ、表グラフ、面グラフ、スコアカードです。 比較期間の設定 例えば、期間グラフで以下の設定をすると、前期間（8/12〜8/18）のデータが現在のデータとは異なる色の線として表示されます。 デフォルトの期間のフィルタ：過去7日間（今日を含む） 比較期間：前の期間 比較期間の表示 参考 : レポートの期間を設定する - 比較期間を設定する 期間グラフの特長 期間グラフは、一定期間におけるデータの変化を時系列で表示するグラフです。 レポート編集時に「グラフを追加」から「期間」と分類されているグラフを選択することで追加できます。 期間グラフの追加 横軸（X軸）が時間のディメンションで、縦軸（Y軸）が変化を表示したい指標になります。例えば、過去1ヶ月間のユーザー数の推移などを表示できます。 期間グラフ 折れ線グラフも同様の目的で使用されますが、期間グラフの主な利点は、比較期間を設定できる点です。 また、日付の間が空いていても、横軸の時系列は自動で埋められます。 参考 : 折れ線グラフと複合グラフのリファレンス - Looker Studio の折れ線グラフ 期間設定とデフォルトの期間の使用例 コントロールで期間を設定したい場合 期間設定コントロールとグラフのデフォルトの期間をどのように使い分けるか、具体例を交えて解説します。 以下の要件を実現したいとします。 レポートを開いた初期状態では、設定した期間（過去7日間）を表示 ユーザーが期間設定コントロールで任意の期間を指定した際には、指定された期間のデータを表示 上記を実現するには、以下のように設定します。 期間設定コントロール : デフォルトの期間で「過去7日間」を設定 グラフ : デフォルトの期間で「自動」を設定 この設定でレポートを開いた初期状態では、グラフは期間設定コントロールの期間（過去7日間）が表示されます。 レポートを開いた初期状態 ユーザーが期間設定コントロールで任意の期間（過去14日間）を設定すると、グラフにもその期間が表示されます。 期間設定コントロールの期間を変更 デフォルトの期間を期間設定コントロールのみに適用すれば、期間設定コントロールで指定した期間を常にレポート上のグラフに反映できます。 特定のグラフはコントロールの対象外にしたい場合 ユーザーがコントロールで任意の期間を指定したとしても、特定のグラフにその期間を反映したくない場合は、以下のように設定します。 期間設定コントロール : デフォルトの期間で「過去7日間」を設定 グラフ1 : デフォルトの期間で「自動」を設定 グラフ2 : デフォルトの期間で「今月」を設定 この設定でレポートを開いた初期状態では、グラフ1は期間設定コントロールの期間（過去7日間）が表示されますが、グラフ2はグラフで設定したデフォルトの期間（今月）が表示されます。 特定のグラフを期間設定コントロールの対象外にする（初期状態） ユーザーが期間設定コントロールで任意の期間（過去14日間）を設定すると、グラフ1はその期間（過去14日間）が表示されますが、グラフ2はグラフで設定したデフォルトの期間（今月）が表示されたままです。 特定のグラフを期間設定コントロールの対象外にする（期間変更後） グラフにデフォルトの期間を設定すれば、そのグラフだけ期間設定コントロールの対象外にできます。 菊池 健太 (記事一覧) クラウドソリューション部データエンジニアリング課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、GCPは未経験なので現在勉強中。

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

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

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

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

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