G-genの杉村です。Google の生成 AI ノートブックサービスである Gemini Notebook（旧称 NotebookLM）で、Google Cloud 認定資格など、資格試験の勉強をする方法を紹介します。 はじめに Gemini Notebook とは Gemini Notebook による学習 データソース追加 テストの生成 フラッシュカードの生成 レポートの生成 音声解説 動画解説 はじめに Gemini Notebook とは Gemini Notebook （旧称 NotebookLM）は、Google の生成 AI ノートブックサービスです。ウェブサイトやテキストファイル、Google ドキュメントなど、様々なデータソースを読み込ませて、それらの情報源をベースにして生成 AI とチャットができるほか、クイズやレポートの生成、ラジオのような解説音声の生成などを行うことができます。 Gemini Notebook は、Google アカウントさえあれば無償で利用することができます。Google Workspace や有償版 Google アカウントに所属する Gemini Notebook in Pro や、Google Cloud サービスである Gemini Notebook Enterprise であれば、入力したデータは Google によって再トレーニングされないなど、データが保護されます。 Gemini Notebook 以下の記事も参考にしてください。 参考 : Gemini Notebookの情報整理と応用テクニック - G-gen Tech Blog 参考 : Gemini Notebook の「音声概要」で聴く学習を試してみたら便利すぎた - G-gen Tech Blog 参考 : Gemini Notebook無償版・Pro・Enterpriseの違い - G-gen Tech Blog 参考 : Gemini Notebook vs Gemini アプリ:業務で使い分けるための実践知識まとめ - G-gen Tech Blog Gemini Notebook による学習 Gemini Notebook の以下のような機能は、試験やスキルアップのための学習に活かすことができます。 データソースを追加することによる AI とのチャット クイズ（テスト）生成 フラッシュカード生成 レポート生成 音声解説生成 動画解説生成 当記事では、これらの機能を使い、Google Cloud 認定資格「Professional Security Operations Engineer」の勉強をした事例を紹介します。 なお、当記事で紹介する機能やスクリーンショットは、記事を執筆した2025年9月下旬現在のものです。 データソース追加 最初に行うことは、ノートブックの新規作成と、データソースの追加です。 まず、 https://notebook.google.com/ にアクセスします。Google アカウントへのログインを求められた場合、ログインします。表示されたトップ画面で「ノートブックを新規作成」をクリックします。 Gemini Notebook トップ画面 「ソースを追加」画面が表示されるので、ここにデータソースを追加します。データソースは、あとからいつでも自由に追加可能です。 データソースの追加 今回は、以下のようなデータソースを追加しました。 G-gen Tech Blog の試験対策記事（ Professional Security Operations Engineer試験対策マニュアル - G-gen Tech Blog ） 公式の試験ガイド（ https://services.google.com/fh/files/misc/professional_security_operations_engineer_exam_guide_english.pdf ） Google SecOps の公式ドキュメント（ https://cloud.google.com/chronicle/docs/secops/secops-overview?hl=en ）から、特に学習したい機能のページを抜粋して追加 社内の試験 Tips に関する Google ドキュメント なお記事を執筆した2025年9月下旬現在、アスタリスクを使用して「 https://cloud.google.com/chronicle/docs/* 」のように URL をワイルドカード形式で指定することはできず、エラーになります。 データが取り込めると、ノートブック画面が表示されます。タイトルが自動で生成されるほか、概要の文章が中央部分に表示されています。学習を進めるに当たって、さらに理解を深めたいと感じた領域については、随時、左上の「ソース」ブロックの「+ 追加」ボタンからデータソースを追加します。 ノートブック画面 テストの生成 画面右側の「Studio」ブロックにある「テスト」ボタンを押下して、Gemini Notebook にテストを作成させます。「テスト」ボタンを押すと、数分後にテストが生成されます。 生成されたテスト 生成されたテスト「セキュリティ 問題集」をクリックすると、4肢選択式のテストが始まります。 4肢選択式のテスト 「説明」をクリックすると、その問題に関する詳細な説明を AI に依頼することができます。解説文中には、引用元のデータソースへのリンクが含まれます。 AI による解説（左部分） わからないことがあれば、画面中央下のテキストボックスに質問を入力することで、AI にさらに詳細な解説を求めたり、わからない単語を説明させることができます。 フラッシュカードの生成 次に、画面右側の「Studio」ブロックにある「フラッシュカード」ボタンを押下して、Gemini Notebook にフラッシュカードを作成させます。フラッシュカードとは、学生が英単語を覚えるときに使うような、表面に質問が書いてあり、裏面に答えが書いてあるようなカードです。「フラッシュカード」ボタンを押すと、数分後に生成されます。 フラッシュカード フラッシュカードは、試験直前の知識の確認などに有用です。 レポートの生成 画面右側の「Studio」ブロックにある「レポート」ボタンを押下すると、どのようなレポートを生成するかの選択肢が表示されます。AI が提案する選択肢の中から1クリックで選べるほか、プロンプトで細かくテイストを指示することもできます。 レポート生成時の選択肢 今回は「独自に作成」を選び、以下のようなプロンプトを記述してみました。 プロンプトを記述して独自レポートを生成 Google Cloud 認定資格「Professional Security Operations Engineer」の試験勉強をしたいです。 Google SecOps や Security Command Center の各機能の詳細な解説や、SecOps 運用体制に関する説明など、試験に役立つコンセプトを詳細にまとめたレポートを作ってください。特に、技術的な解説を多めに、また詳細にお願いします。 数分後、以下のようなレポートが生成されました。 Gemini Notebook によって生成された学習用レポート 音声解説 「Studio」ブロックにある「音声解説」ボタンを押下すると、2人の人物がラジオやポッドキャストのように、データソースに関する会話をしている音声を生成できます。 移動中や家事の合間などの「ながら勉強」に利用できます。 英語の音声が生成されてしまう場合には、「音声解説」ボタンの右上に表示されている鉛筆マークを押してください。ここでは出力言語が選べるほか、どのような音声を生成するか、また音声の長さなどを詳細に指定することができます。焦点を当てるトピックを自然言語で指示することもできます。 音声概要の詳細設定画面 生成された音声はノートブック上で再生できるほか、mp4 形式でダウンロードすることもできます。今回はデフォルト設定で、約21分間の音声が生成されました。 生成された音声 動画解説 Gemini Notebook では、動画による解説を生成することもできます。「Studio」ブロックにある「動画解説」ボタンを押下します。こちらでも、鉛筆マークを押すことで、出力言語や注力するトピックなどを指定できます。 動画はスライドと、それを解説する音声で構成されており、日本語で生成することができます。生成された動画はノートブック上で再生できるほか、mp4 形式でダウンロードすることもできます。デフォルト設定のまま生成したところ、約8分間の動画が生成されました。 動画概要で生成された動画（1） 動画概要で生成された動画（2） 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。2025年9月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Podcast API が許可リスト制で公開 BigQuery の Managed disaster recovery で soft failover が実行可能に Cloud Run worker pools で GPU が使えるように Google Vids で Google スライドから動画を生成できるように GKE Enterprise 機能の一部が追加費用なしで利用可能に Cloud SQL で最終バックアップの取得有無をインスタンス単位で設定可能に AlloyDB AI natural language が Public Preview Gemini Notebook Enterprise で API によるノートブック操作が可能に Veo 3 と Veo 3 Fast が値下げ environment タグが Google Cloud コンソールのプロジェクト表記に反映 Vertex AI Agent Engine で複数アップデート Google スプレッドシートに変更履歴の「凝縮表示」が登場 Looker Studio で破壊的仕様変更 職務ごとの「事前定義ロール」が新しく登場 IAM 権限不足エラー表示がより詳細に Model Armor と Application Load Balancer が統合可能に BigQuery advanced runtime が一般公開（GA） Google Agentspace と Gemini Notebook Enterprise で Model Armor が使用可能に Googleカレンダーの予定複製時に Google Meet 会議が複製されなくなる Google Meet で Ask Gemini in Meet が一部の顧客に展開開始 Gemini アプリの Gems が他人に共有できるように Compute Engine で GPU 等を確保しやすい Flex-start VM が一般公開（GA） BigQuery から PostgreSQL-dialect の Spanner への federated queries が GA Gemini 2.5 Flash with Live API Native Audio が Preview 公開 Google スプレッドシートの AI 関数が日本語でも利用可能に Google スプレッドシートで Gemini による関数生成が強化 Gemini CLI extensions for BigQuery が公開 gemini-1.5-pro-002 と gemini-1.5-flash-002 の提供が終了 Gemini 2.5 Flash と Flash-Lite の新しいバージョンが Preview 公開 Cloud SQL でマネージドコネクションプール機能が Preview → GA BigQuery で history-based optimizations がデフォルトで有効に Dataplex でカラムレベルのリネージが利用可能に Privileged Access Manager（PAM）で複数のアップデート Google チャットのスペースのロールに「オーナー」が新設 パソコン版 Google ドライブでランサムウェア検出がベータ公開 Cloud DNS で Alias record タイプが Preview → GA 音声合成モデル Gemini-TTS が一般公開（GA） はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Podcast API が許可リスト制で公開 Generate podcasts (API method) (2025-08-28) Podcast API が許可リスト制で公開。利用にはGoogleへの申請が必要。 ポッドキャスト風音声が API 経由で生成できる。テキスト、画像、音声、動画をインプットして、MP3 音声を出力。 製品ラインとしては Gemini Notebook Enterprise だが、Gemini Notebook Enterprise や Agentspace のライセンスは不要。API endpoint は以下。 https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/podcasts BigQuery の Managed disaster recovery で soft failover が実行可能に Managed disaster recovery (2025-09-03) BigQuery の Managed disaster recovery で soft failover が実行可能に。 両リージョンが生きているときのみ使用可能。セカンダリリージョンへのレプリケーション完了を待ってフェイルオーバ・昇格する。計画的切り替えや、災対訓練などに利用可能。 Cloud Run worker pools で GPU が使えるように GPU support for worker pools (2025-09-03) Cloud Run worker pools（Preview 中）で GPU が使えるように。 NVIDIA L4 GPUs with 24 GB VRAM が使用可能。 Google Vids で Google スライドから動画を生成できるように 'Help me create' in Google Vids now includes support for Google Slides (2025-09-03) 動画編集ツール Google Vids に、Google スライドから動画を生成する機能が登場。 スライドを解説するような動画が簡単に制作できる。Business Starter以上で使えるが、まずは英語版のみ・順次ロールアウトな点に注意。 GKE Enterprise 機能の一部が追加費用なしで利用可能に GKE release notes - September 02, 2025 (2025-09-02) GKE Enterpriseで提供されていた機能の一部が、追加費用なしで GKE Standard で利用可能になった。 Fleet dashboard、Multi-team Management、Config Controller など。他の一部機能は、スタンドアロンな SKU として課金され使用可能。 Cloud SQL で最終バックアップの取得有無をインスタンス単位で設定可能に Take a final backup at instance deletion (2025-09-03) Cloud SQL インスタンスの削除時に最終バックアップを自動で取るかどうか、またその保持期間を、インスタンスの設定値として事前に設定できるようになった。 Cloud SQL for MySQL / PostgreSQL / SQL Server のいずれにも対応。 AlloyDB AI natural language が Public Preview AlloyDB AI natural language overview (2025-09-04) AlloyDB for PostgreSQL で、AlloyDB AI natural language が Public Preview。 エンドユーザーの自然言語による質問に対して SQL を自動生成。 alloydb_ai_nl.get_sql() 関数で DB 側で SQL を生成できるので、生成 AI モデルの API 呼び出しが不要。 Gemini Notebook Enterprise で API によるノートブック操作が可能に Create and manage notebooks using the API (2025-09-05) Gemini Notebook Enterprise で API 経由でノートブック作成、データソース追加、リストアップ、最近見られたノートブックの表示、削除などができるようになった。 個人版や Google Workspace 付属の Gemini Notebook ではなく、Google Cloud で提供されるEnterprise 版のみの機能であることに注意。 Veo 3 と Veo 3 Fast が値下げ Veo 3 and Veo 3 Fast – new pricing, new configurations and better resolution (2025-09-08) 動画生成モデル Veo 3 が、以下のとおり値下げ。 Veo 3 : $0.75 / second → $0.40 / second Veo 3 Fast : $0.40 / second → $0.15 / second environment タグが Google Cloud コンソールのプロジェクト表記に反映 Designate project environments with tags (2025-09-10) Google Cloud プロジェクトに environment タグを付けると、Google Cloud コンソールでプロジェクト表記の右に環境名が表示できるようになった。 オペレーションミス等の予防に少し役立つ。 Vertex AI Agent Engine で複数アップデート Vertex AI release notes - September 10, 2025 (2025-09-10) Vertex AI Agent Engine で複数アップデート。 A2A 対応 サンドボックス環境でのコード実行（Preview） 双方向ストリーミング Google Cloud コンソールで Memory Bank タブが登場 Google スプレッドシートに変更履歴の「凝縮表示」が登場 Understand changes more quickly with condensed version history in Sheets (2025-09-10) Google スプレッドシートに、変更履歴の「凝縮表示」が登場。 変更があったセルを含む行のみが表示される表示方法。順次ロールアウト。 Looker Studio で破壊的仕様変更 Looker Studio release notes - September 11, 2025 (2025-09-11) Looker Studio で、2つの破壊的仕様変更（破壊的仕様変更 = Breaking change。後方互換性を維持しない仕様変更）。 データソースへの認証が「閲覧者の認証情報」のとき、そのデータソースのディメンションの HYPERLINK() でのリンク化や画像表示がレンダリングされなくなる ただし Looker Studio Pro で、レポート作成者と閲覧者が同じチームワークスペースに所属している場合はこの制限は適用されない Explorer 機能が廃止される Explorer 機能は数年にわたり Beta 公開だった 既存の Explorer は自動でレポートに変換される 職務ごとの「事前定義ロール」が新しく登場 Predefined roles for job functions (2025-09-12) 職務ごとの「事前定義ロール」が新しく登場。以下に一例を示す。 Databases administrator（ roles/iam.databasesAdmin ） Infrastructure administrator（ roles/iam.infrastructureAdmin ） Data scientist（ roles/iam.dataScientist ） Site reliability engineer（ roles/iam.siteReliabilityEngineer ） IAM 権限不足エラー表示がより詳細に Troubleshoot permission error messages (2025-09-12) Google Cloudコンソールで IAM 権限不足エラーの際に、足りない権限を含んでいるロール一覧が表示されるようになった。 Request permissions ボタンを押してエッセンシャルコンタクトのTechnical 担当者宛てに、権限付与の依頼メールを送信することもできる。 Model Armor と Application Load Balancer が統合可能に Configure a traffic extension to call the Model Armor service (2025-09-15) Model Armor と Application Load Balancer が統合可能になった（GA）。 ALB に Service Extension を挟み込むことで、ALB を通るすべてのプロンプトとレスポンスが Model Armor で検査される。 BigQuery advanced runtime が一般公開（GA） Use the BigQuery advanced runtime (2025-09-15) BigQuery advanced runtime が一般公開（GA）。 新しいランタイム（実行環境）。2025年9月15日から2026年初頭にかけ全プロジェクトでデフォルトになるが、それまでは任意で有効化できる。以下の性能向上。 Enhanced vectorization（新しいクエリ処理モデル） Short query optimization（小規模クエリを高速化） Short query optimization については、以下の記事も参照。 blog.g-gen.co.jp Google Agentspace と Gemini Notebook Enterprise で Model Armor が使用可能に Google Agentspace release notes - September 15, 2025 (2025-09-15) Google Agentspace と Gemini Notebook Enterprise で Model Armor が使用可能に。 AI へのプロンプトとレスポンスをスクリーニングし情報漏洩や悪意ある攻撃を遮断。 Googleカレンダーの予定複製時に Google Meet 会議が複製されなくなる Enhancing meeting privacy for copied Calendar events (2025-09-16) Googleカレンダーで予定を複製したときに、Google Meet 会議は複製されなくなる。 会議のプライバシーを保つためと説明されている。順次ロールアウトで、管理者による設定でこの挙動は変更できない。 Google Meet で Ask Gemini in Meet が一部の顧客に展開開始 Ask Gemini in Meet: Your Personal Meeting Assistant (2025-09-17) Google Meet で Ask Gemini in Meet が一部の顧客に展開開始。会議中に Gemini に依頼ができる。 議論経過を要約 結論やアクションアイテムを列挙 途中参加したミーティングのこれまでの内容をキャッチアップ まずは英語のみ対応だが他の言語も追って対応予定。 Gemini アプリの Gems が他人に共有できるように Introducing Gems sharing in the Gemini app, including admin controls (2025-09-18) Gemini アプリの Gems が他人に共有できるようになった。 共有相手には Gem 一覧やドライブの共有アイテムに表示される。共有すると、Gem は Google ドライブでファイルとして管理される。共有の方式は Google ドライブファイルと同じ。 組織内・外への共有が可能であり、編集権限付与も可。 Gems の詳細は以下の記事を参照。 blog.g-gen.co.jp Compute Engine で GPU 等を確保しやすい Flex-start VM が一般公開（GA） About Flex-start VMs (2025-09-22) Compute Engine で GPU などを確保しやすい Flex-start VM が一般公開（GA）。 Flex-start VM は、最大7日間実行できる割引価格のインスタンス。Dynamic Workload Scheduler（DWS）によりスケジューリングが最適化さており、通常よりリソースを確保できる可能性が高い。 BigQuery から PostgreSQL-dialect の Spanner への federated queries が GA Spanner release notes - September 22, 2025 (2025-09-22) BigQuery から PostgreSQL-dialect の Spanner への federated queries が一般公開（GA）。 従来は GoogleSQL インスタンスのみ対応していた。クロスリージョンでもクエリ可能。 Gemini 2.5 Flash with Live API Native Audio が Preview 公開 Gemini 2.5 Flash - Live API native audio (2025-09-23) Gemini 2.5 Flash with Live API Native Audio（ gemini-live-2.5-flash-preview-native-audio-09-2025 ）が Preview 公開。 音声/テキスト/動画をインプットとして音声やテキストをアウトプット。低レイテンシで AI との自然な会話を実現する。 Google スプレッドシートの AI 関数が日本語でも利用可能に Generate data with AI function in Sheets now available in seven additional languages (2025-09-23) Google スプレッドシートの AI 関数が、日本語でも利用可能になる。 AI 関数では、セルの内容を生成 AI モデル Gemini が処理できる。 Google Workspace の管理者設定で「即時リリース」に設定してある場合、2025-09-23から15日以内にロールアウト。「計画的リリース」なら2025-10-06から15日以内にロールアウト。 Google スプレッドシートで Gemini による関数生成が強化 Gemini in Google Sheets now provides smarter, more conversational formula generation (2025-09-24) Google スプレッドシートで、Gemini による関数生成が強化された。 Google スプレッドシートではもともと、Gemini に自然言語で指示するとセル関数を生成できたが、今回の強化で「挙動をステップバイステップで詳細に解説」、「エラー修正」、「複数候補の提示」など、より便利になった。 Gemini CLI extensions for BigQuery が公開 Develop with the Gemini CLI (2025-09-24) BigQuery を自然言語でクエリ・操作できる Gemini CLI extensions for BigQuery が公開。従来より公開されていた MCP Toolbox がベース。 gemini extensions install のようにしてインストールできる。 gemini-1.5-pro-002 と gemini-1.5-flash-002 の提供が終了 Model versions and lifecycle (2025-09-24) 従前からの通告のとおり、本日から gemini-1.5-pro-002 や gemini-1.5-flash-002 の提供が終了。 これらのモデルへのリクエストは404となる。移行先は Gemini 2.0 や 2.5。 Gemini 2.5 Flash と Flash-Lite の新しいバージョンが Preview 公開 Vertex AI release notes - September 25, 2025 (2025-09-25) Gemini 2.5 Flash と Flash-Lite の新しいマイナーバージョンが Preview 利用可能。新しいモデル名は以下のとおり。 gemini-2.5-flash-preview-09-2025 gemini-2.5-flash-lite-preview-09-2025 以下の公式記事によると、精度が上がり、レイテンシは下がった。 参考 : Continuing to bring you our latest models, with an improved Gemini 2.5 Flash and Flash-Lite release - Google Developers Blog Cloud SQL でマネージドコネクションプール機能が Preview → GA Managed Connection Pooling overview (2025-09-25) Cloud SQL for PostgreSQL でマネージドコネクションプール機能が Preview → GA。 特に for PostgreSQL 版では、Preview 期間中は IAM 認証インスタンスではマネージドコネクションプールが使用できなかったが、使用できるようになった。 BigQuery で history-based optimizations がデフォルトで有効に Use history-based optimizations (2025-09-29) BigQuery で history-based optimizations がデフォルトで有効になった。 同じクエリを複数回実行することで、何もしなくてもクエリ実行時間やスロット消費が最適化される。 Dataplex でカラムレベルのリネージが利用可能に Column-level lineage (2025-09-29) Dataplex でカラムレベルのリネージが利用可能になった。 従来はテーブルレベルだったが、このアップデートにより列のレベルで、値がどこから来たか（単なる複製か、その他の依存関係か）がグラフィカルに表示できるようになった。 カラムレベルのリネージ Privileged Access Manager（PAM）で複数のアップデート IAM release notes - September 26, 2025 (2025-09-29) Privileged Access Manager（PAM）で複数のアップデート。 多段階の承認者 リクエスト時のスコープ調整 サービスアカウントを承認者として指定 権限付与の途中取り下げ ...など。PAM については以下の記事を参照。 blog.g-gen.co.jp Google チャットのスペースのロールに「オーナー」が新設 Changes to membership roles in Google Chat spaces to enable more flexible permissions (2025-09-29) Google チャットのスペースのロールに「オーナー」が増えて「マネージャー」「メンバー」とあわせて3種類になる。 既存のマネージャはオーナーになる。マネージャはオーナーとほぼ同じ権限だがスペース削除やオーナー移譲ができない。 パソコン版 Google ドライブでランサムウェア検出がベータ公開 Ransomware detection and file restoration for Google Drive available in beta (2025-09-30) パソコン版 Google ドライブでランサムウェア検出機能のベータ版が利用可能に。 ランサムウェアが検知されるとファイル同期が停止され警告が表示され、ユーザーと管理者にメールが送信される。またドライブ内に同期されたファイルなら簡単に以前のバージョンに復元できる。 Cloud DNS で Alias record タイプが Preview → GA Alias records (2025-09-30) Cloud DNS で Alias record タイプが Preview → GA。 ドメインのゾーンエイペックスに置ける、CNAME と同じ挙動をするレコード。 CNAME レコードは他の種類のレコードと重複してはいけないため、ゾーンエイペックス（example.com ゾーンにおける example.com）には CNAME を作れない。ここで ALIAS レコードが使われる。 example.com → Cloud Storage バケットのオブジェクトに飛ばす、などが可能になる。 音声合成モデル Gemini-TTS が一般公開（GA） Gemini-TTS (2025-09-30) 音声合成モデル Gemini-TTS が一般公開（GA）。 日本語を含む70以上の言語に対応し、30種類の声色がある。既存の Chirp との違いは、自然言語プロンプトでトーンやアクセントをきめ細かく指示できる点。Vertex AI Studio から試せる。 ※ TTS = Text-to-Speach 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Google Workspace では毎週、数個の機能アップデートが行われており、日々便利になり続けています。新しい機能の中には発表されてからすぐ使えるようになるわけではなく、時間をかけてロールアウト（順次リリース）されていくものがあります。そのスピードを制御する管理者設定について紹介します。 新機能のリリース設定 リリーススケジュール 即時リリースと計画的リリース 設定の変更 新機能のリリース設定 Google Workspace では、毎日のように新機能のアップデートが行われます。週に10個以上のアップデートが行われることも珍しくありません。アップデートは公式のリリースノートで確認することができます。リリースノートには日本語版もありますが、翻訳が数週間遅れるため、最新情報を確認するには英語版のサイトを見ることが推奨されます。 参考 : Google Workspace Updates 新しい機能のほとんどは、発表されてからすぐ使えるようになるわけではなく、時間をかけて順次リリースされます。この順次展開は ロールアウト （rollout）と呼ばれます。ロールアウトはすべての Google Workspace テナント（ドメイン）に同時に行われるのではなく、ある組織と別の組織では、ロールアウトされるタイミングが異なります。 また、組織ごとに、管理コンソールで リリース設定 を以下のいずれかから選択できます。 即時リリース （Rapid Release） 計画的リリース （Scheduled Release） どちらを選択するかによって、新機能がロールアウトされるタイミングや、早期一般提供（早期 GA）段階の機能を使用できるかどうかが決まります。リリース設定は、管理コンソール（ https://admin.google.com/ ）の [アカウント] > [アカウント設定] > [設定] から設定できます。 参考 : ユーザーに新機能をリリースするタイミングを選択する - Google Workspace 管理者ヘルプ リリーススケジュール ロールアウトの早さは、個々のアップデートごとに異なります。概ね以下のいずれかであり、そのアップデートがどれに該当するかは、アップデート記事に記載されています。 即時（Available now / Currently available / Already available。発表直後から利用可能） 完全に展開（ Full rollout 。起算日から1～3 日） 段階的に展開（ Gradual rollout 。起算日から最長 15 日） 長期的に展開（ Extended rollout 。起算日から15 日以上） 起算日は即時リリースと計画的リリースで異なっており、これも記事に記載されます。原則的に即時リリースのほうが起算日が早いですが、計画的リリースと同時のときもあります。 例として、「 Google スプレッドシートの AI 関数機能の日本語対応 」という機能アップデートでは、即時リリースは2025-09-23を起算日とする Gradual rollout で、計画的リリースの場合は2025-10-06を起算日とする Gradual rollout でした。 即時リリースと計画的リリース 即時リリース （Rapid Release）を選択している場合、いち早く新機能を使用することができます。 計画的リリース （Scheduled Release）では、即時リリースに1週間〜数週間遅れて機能がロールアウトされます。 公式ドキュメントでは、特に大組織においては以下のような戦略をとることを推奨しています。 本番環境ドメインでは計画的リリースを選択 テスト環境のドメインでは即時リリースを選択 テスト環境のドメインで新機能を試用したり、ユーザーからの問い合わせへの準備を整える。問題がなければ本番環境にも適用 このようにすることで、UI が変わったり新しい機能が使えるようになることでのユーザーの混乱を抑えたり、不具合の影響を抑えるなどが可能になります。しかし上記の方法は、複数の Google Workspace ドメインを保持する必要があり、管理工数や追加のライセンス費用が必要になってしまうため、運用体制の余力に応じて検討することになります。 設定の変更 リリース設定（即時リリースまたは計画的リリース）を変更するには、以下の手順を行います。この設定は、組織全体に適用されます。適用対象の組織部門等を選択することはできません。 1. 特権管理者アカウント等で管理コンソール（ https://admin.google.com/ ）にログイン 2. 左部メニューから [アカウント] > [アカウント設定] をクリック 3. [設定] をクリック [アカウント] > [アカウント設定] > [設定] 4. [新機能] をクリックし、即時リリースまたは計画的リリースを選択して保存 [新機能] なお、上記の「[新機能]」の下部に見える「新サービス」設定では、Google Workspace に新サービスがリリースされたときに、自動的に使用可能にするかどうかを選択する設定です。例えば、2024年11月には Google Vids という動画編集ツールが新サービスとしてリリースされました。 参考 : 新しいサービスをデフォルトで有効または無効にする - Google Workspace 管理者ヘルプ 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Google Cloud や Google Workspace といったクラウドサービスと、「英語」という言語の関係性について、またクラウド利用にあたっての言語の違いに関する注意点等について解説します。 クラウドと英語 Google 公式ドキュメント 生成 AI 関連機能 訳語の難しさと違い 認定資格 クラウドと英語 Google Cloud や Google Workspace といったクラウドサービスと、「英語」という言語は深い関係性を持ちます。多くのクラウドサービスで、ユーザーインターフェイスや公式ドキュメント、また新機能が 第1に対応する言語は英語 です。特に近年は生成 AI 関係のサービスや機能においては、リリース直後はまず英語のみが対応し、他の言語がそれに追随するといった状況が見られます。 その理由として、まず Google Cloud、Google Workspace、Amazon Web Services（AWS）、Microsoft Azure といった主要なパブリッククラウドサービスは、いずれもアメリカ合衆国出身の企業が開発したものであるからという点が挙げられます。開発者や、サービスを最初に利用するユーザーは、英語を母語とする人々です。 次に、市場規模も理由の1つです。英語は実質的に世界で最も多く話者を持つ言語であることから、最も優先すべき言語となります。クラウドサービスのローカライズ、特に日本語の対応は数か月遅れる場合もあります。 この状況から、クラウドサービスを利用するにあたって、日本語を母語とする人たちにとって注意すべき点が多々あります。当記事ではそのような注意点などについて解説します。 Google 公式ドキュメント Google Cloud や Google Workspace の公式ドキュメントは、主として以下のウェブサイトに公開されています。 Google Cloud 公式ガイド（ https://cloud.google.com/docs?hl=ja ） Google Workspace 管理者ヘルプ（ https://support.google.com/a/?hl=ja ） これらのドキュメントでは、 英語版のドキュメントに最も新しい情報が掲載 されており、日本語への翻訳は遅れる場合が多く見られます。同じ URL の同一ページでも、英語版に切り替えると、日本語版とは 異なる情報が表示される 場合があります。英語版と日本語版でで掲載情報が異なる場合、 正しい情報は英語版 であることに留意してください。 特に、サービスのアップデートが頻繁に行われる生成 AI 関連サービスや機能においては、最新情報や正しい情報を得るために、 可能であれば英語版ドキュメントを参照する ことが望ましいといえます。また、Preview 中だった機能が一般公開（GA）した場合なども、GA 直後は日本語版ドキュメントのみに「プレビュー」表記が残り、英語版ドキュメントからは表記が消えている、というケースもあります。日本語版ドキュメントと英語版ドキュメントでページ構成自体が異なっているケースもあります。 Google Cloud ドキュメントは、画面右上の地球儀マークから、言語を切り替えることができます。 Google Cloud ドキュメントの言語切替 Google Workspace ドキュメントは、画面の一番下までスクロールして最下部にあるセレクタで言語を切り替えることができます。 Google Workspace ドキュメントの言語切替 なお、Google Cloud・Google Workspace のいずれのドキュメントも、URL の末尾にクエリパラメータとして ?hl=en を付与すれば英語版ドキュメントが、 ?hl=ja を付与すれば日本語版ドキュメントが表示されます（クエリパラメータは、 # で始まるアンカーよりも前に書きます）。 例 # 英語版ドキュメントへの URL https://cloud.google.com/resource-manager/docs/managing-notification-contacts?hl=en # 英語版ドキュメントへの URL（アンカーがある場合） https://cloud.google.com/resource-manager/docs/managing-notification-contacts?hl=en#notification-categories 生成 AI 関連機能 Google Workspace の生成 AI 関連などでは、まず英語のみが対応し、続けて他の言語が対応する例があります。以下は、その例です。 参考 : “Take notes for me” in Google Meet now captures “next steps” 参考 : Language expansion for “suggested next steps” when using “Take Notes for Me” 最初の記事は、Google Meet のウェブ会議で Gemini が議事録を作成してくれる Take notes for me 機能に関する2025年2月18日のリリースです。次の記事は、その約半年後の2025年8月7日に、Take notes for me 機能が日本語、韓国語、フランス語、スペイン語などを含む追加の言語に対応したことを発表する記事です。 同様に、Google スプレッドシートの AI 関数機能も、機能自体の発表（ 2025-06-25 ）から3ヶ月ほど遅れて、日本語等の追加の言語の対応が発表（ 2025-09-23 ）されました。 生成 AI は特に自然言語に関するタスクを得意としますが、品質が重視されるようなサービスでは、Google が調整に時間をかけるケースがあります。上記の議事録機能のほか、画像生成などに関しても、日本語対応には時間がかかりました。これは、一歩間違えればコンプライアンスや倫理問題に繋がりかねない言語間の違いを調整するために、Google が慎重に調整を行っているためと考えられます。 Google Workspace では、日本のユーザーでも、 言語の個人設定で言語を切り替える ことで、英語版のみに対応している機能を使えるようになるケースがあります。 Google Workspace の個人の言語設定を英語に変更するには、Gmail や Google ドライブなど Google Workspace のいずれかのアプリ画面を開いてから、右上のアバター画像をクリックし、「Google アカウントを管理 > 個人情報 > ウェブ向けの全般設定 > 言語」をクリックします。表示された設定画面で、英語が存在しない場合は「+ 他の言語を追加」をクリックして英語を追加し、メイン言語に設定します。 言語設定の変更 ただし、機能によっては「米国に居住するユーザーのみ利用可能」など、居住国で制限がされるケースもあるため、このような場合には言語設定を切り替えても利用することはできません。これは、欧州連合（EU）など特に法的規制が厳しい国のユーザーに対する対策などであると考えられます。 訳語の難しさと違い Google Cloud においては、公式ドキュメントや Google Cloud コンソール（Web UI）を日本語で利用することができます。ただし、ときとして用語が日本語へ翻訳されたことで逆にわかりづらくなるようなケースもあります。 原語 日本語訳(ドキュメント) Commited use discounts（CUD） 確約利用割引（CUD） BigQuery data preparation BigQuery データの準備 Privileged Access Manager Admin 特権アクセス マネージャー管理者 また、特に IAM ロールの名称の翻訳でしばしば見られるのは、ドキュメント上の訳語と、Google Cloud コンソール上の訳語が異なるケースです。 例えば前掲の Privileged Access Manager Admin（ roles/privilegedaccessmanager.admin ）ロールは、公式ドキュメント上は「Privileged Access Manager 管理者」と記載されていますが、Google Cloud コンソール上は「特権アクセス マネージャー管理者」と表記されます。コンソール上で IAM ロールを付与しようとして「Privileged Access Manager 管理者」で検索しても、見つからないことになります。特に IAM ロールの場合、 roles/ で始まる ID を使って識別するか、コンソールの言語設定を英語版に切り替えることで対策できます。 Google Cloud コンソールの表記を英語に切り替えるには、コンソール右上の三点リーダーから「設定（英語では Preferences）」を選び、「言語と地域」を選んで表示される設定画面で、英語を選択して保存します。米国英語である English (United States) と英国英語である English (United Kingdom) がありますが、特にこだわりがなければ米国英語を選択するのが無難でしょう。 Google Cloud コンソールの言語切替 認定資格 Google Cloud 認定資格も、特に新しいものはまず英語版のみが発表されます。日本語は比較的優遇されており、英語以外の言語では日本語が最も対応している認定資格が多いです。 2025年9月下旬現在、14個の Google Cloud 認定試験のうち、10個の試験が日本語に対応しています。逆に日本語以外では、スペイン語とポルトガル語が1資格（Cloud Digital Leader）、フランス語が2個の資格（Cloud Digital Leader と Associate Cloud Engineer）で対応しているのみです。日本がマーケットとして重視されている点と、「英語が苦手」な人が多い実態が考慮されているように思われます。 Google Cloud 認定資格試験の言語の対応状況については、以下の記事も参照してください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。組織で定めた標準構成の Google Cloud プロジェクトを、Terraform を使って払い出すためのサンプル構成ファイルをご紹介します。 はじめに 標準構成のプロジェクトと Terraform 免責事項 フォルダ構成 ルートモジュール main.tf provider.tf variables.tf terraform.tfvars リソースモジュール projects.tf apis.tf iam.tf variable.tf カスタマイズ トラブルシューティング はじめに 標準構成のプロジェクトと Terraform 企業や官公庁などにおいて、複数の部署やチームが Google Cloud を利用する場合、情報システム部門等が Google Cloud プロジェクトの標準的な構成を定め、それを利用部門に対して払い出し、セキュアな利用を促すことは一般的に行われています。 Terraform などの Infrastructure as Code（IaC）ツールを用いることで、以下のような所定の構成を持つプロジェクトをミスなく、少ない工数で払い出すことができるようになります。 所定の請求先アカウントをプロジェクトに紐づけ 所定の IAM ロールを申請者に付与 決まった構成の VPC ネットワークとサブネットを作成 所定の「組織のポリシーの制約」をプロジェクトにアタッチ 当記事では、Google Cloud で IaC を実現するときのデファクトスタンダードである Terraform を用いた場合の、ファイル構成や構成ファイルのサンプルをご紹介します。 免責事項 当記事で紹介するプログラムのソースコードや構成ファイルは、ご自身の責任のもと、使用、引用、改変、再配布して構いません。 ただし、同ソースコードが原因で発生した不利益やトラブルについては、当社は一切の責任を負いません。 フォルダ構成 当記事のサンプルでは、以下のようなフォルダ構成を取ります。 environments/ └ prd 　├ main.tf 　├ backend.tf 　├ variables.tf 　└ terraform.tfvars modules/ └ projects/ 　├ apis.tf 　├ iam.tf 　├ projects.tf 　└ variables.tf この構成では、 ルートモジュール （terraform apply などを実行するディレクトリ）と、 リソースを定義するモジュール を別々のディレクトリに配置しています。このような構成は Google Cloud の公式ドキュメントでも、ベストプラクティスとして記載されています。 参考 : ルート モジュールのベスト プラクティス - Google Cloud 上記のサンプルでは environments ディレクトリに prd というディレクトリだけを用意し、ここをルートモジュールとしています。必要に応じて複数の環境のディレクトリを作成します。prd、stg、dev といった区切り方や、あるいは部署ごと、サブシステムごとといった区切り方が考えられます。適切な区切り方は、運用体制などに応じて検討します。 リソースを定義するモジュールは、 modules ディレクトリ以下に格納します。今回は projects というディレクトリを作成し、ここに標準構成のプロジェクトを定義します。これをルートモジュールから呼び出すことで、同じ構成のプロジェクトの複数の払い出しを実現します。 ルートモジュール main.tf ルートモジュールの main.tf は、以下のように記述します。 # 1個目のテナント module "tenant_test01" { source = "../../modules/projects" # テナント固有情報 tenant = { name = "my-test-project-01" folder_id = "123456789012" billing_account_id = var.common_billing_account } tenant_groups = { admin = [ "group:sys-admin@example.com" , "user:john-doe@example.com" ] developer = [ "group:dev-team-01@example.com" ] viewer = [ "user:ichiro-suzuki@g-gen.co.jp" ] } } # 2個目のテナント module "tenant_test02" { source = "../../modules/projects" # テナント固有情報 tenant = { name = "my-test-project-02" folder_id = "123456789012" billing_account_id = var.common_billing_account } tenant_groups = { admin = [ "group:sys-admin@example.com" , "user:john-doe@example.com" ] developer = [ "group:dev-team-02@example.com" ] viewer = [ "user:tom-brown@g-gen.co.jp" ] } } 今回のサンプルでは、1つの main.tf ファイルに複数のテナント（利用部署）のプロジェクトを記述しています。利用部署が増えるたびに、 module "tenant_test01" { ... } の部分を増やしていきます。 プロジェクトが所属するフォルダは、テナントごとに指定できるようにしました。一方、プロジェクトに紐づける請求先アカウントは変数を使って共通の請求先アカウント ID を指定できるようにしました。変数への値の代入は、変数ファイル（ terrafoirm.tfvars ）で行います。 また、IAM ロールの付与も実現しています。あらかじめ「admin」「developer」「viewer」という権限セットをリソースモジュール側で定義しておきます。定義に応じた IAM ロールが、ここで指定した Google グループやアカウントに付与されます。 provider.tf provider.tf では、プロバイダの情報と、state ファイルを格納するバックエンドバケットを定義します。 先述の Google のベストプラクティスのドキュメントでは、provider はリソースモジュール側で定義していましたが、ここでは統一された標準構成をすべてのテナントにデプロイする意図で、ルートモジュール側に持たせました。 # provider ・バックエンド定義 provider "google" { region = "asia-northeast1" request_timeout = "60s" } terraform { required_providers { google = { source = "hashicorp/google" version = "~> 7.3.0" } } required_version = ">= 1.5.7" backend "gcs" { bucket = "my-state-bucket" prefix = "standard-project/" } } state ファイルを Cloud Storage バケットに格納することの意義などについては、以下の記事も参考にしてください。 blog.g-gen.co.jp variables.tf このファイルでは、ルートモジュールの変数を宣言しています。今回は、組織が共通で使う請求先アカウントの ID を代入するための変数を宣言します。 # 共通の請求先アカウント variable "common_billing_account" { type = string } terraform.tfvars このファイルでは、組織が共通で使う請求先アカウントの ID を変数に代入します。これにより、同じ請求先アカウントを複数のプロジェクトに紐づけできます。 common_billing_account = "01234A-56789B-43210C" Terraform においては、Google Cloud プロジェクトに紐づける請求先アカウントは名称ではなく英数字とハイフンで構成される ID で指定することに注意してください。 参考 : google_project - Terraform リソースモジュール projects.tf このファイルでは、Google Cloud プロジェクトのみを定義します。 # プロジェクト resource "google_project" "project" { # DELETE だと terraform で削除されるとプロジェクトが削除される。"ABANDON" だと state のみ削除 deletion_policy = "ABANDON" # プロジェクト名は6~30文字、英大文字不可 name = var.tenant.name project_id = var.tenant.name folder_id = var.tenant.folder_id billing_account = var.tenant.billing_account_id # false で default VPC ネットワークを作成しない auto_create_network = false } 誤用や事故を防ぐため、プロジェクト名とプロジェクト ID は同一の値としました。またここで、所属するフォルダ ID や紐づける請求先アカウントを指定しています。 deletion_policy はメタ引数（Google Cloud リソースとしての構成には影響はないが、Terraform が管理上用いる引数）です。値を DELETE にすると、Terraform リソースが削除されたときに、実際に Google Cloud プロジェクトも削除されます。ABANDON にすると、Terraform の state からは削除されますが、実際に Google Cloud プロジェクトは削除されずに残ります。 参考 : google_project - Terraform また、 auto_create_network の値を false にすることで、本番環境では推奨されない構成であるデフォルトネットワークの作成を防いでいます。ただし、組織全体でデフォルトネットワークの作成を防ぐには、このようにリソース作成時に作成をスキップするだけでなく、組織のポリシーの制約である constraints/compute.skipDefaultNetworkCreation を用いることが推奨されます。 組織のポリシーについては以下の記事も参照してください。 blog.g-gen.co.jp apis.tf このファイルでは、プロジェクトで有効化する API を記述します。 ## プロジェクトで有効化するサービス API locals { apis = [ "compute.googleapis.com" , "cloudfunctions.googleapis.com" , "run.googleapis.com" ] } # API 有効化 resource "google_project_service" "enable_apis" { for_each = toset (local.apis) project = google_project.project.id service = each.value } 参考 : google_project_service - Terraform 有効化する対象 API は、配列形式のローカル変数で定義しています。対象の API を増やしたい場合は、ここに追加します。 iam.tf このファイルでは、IAM ロールの付与方法を定義します。ルートモジュールで「admin」「developer」「viewer」という権限セットが記述されていましたが、それぞれどのようなロールが付与されるかは、このファイルに定義されています。 ######################### # IAM 定義 - 管理者グループ ######################### # ロール : 閲覧者 resource "google_project_iam_member" "admin_viewer" { for_each = toset (var.tenant_groups.admin) project = google_project.project.id role = "roles/viewer" member = each.value } # ロール : プライベート ログ閲覧者 resource "google_project_iam_member" "admin_private_log_viewer" { for_each = toset (var.tenant_groups.admin) project = google_project.project.id role = "roles/logging.privateLogViewer" member = each.value } # ロール : Compute 管理者 resource "google_project_iam_member" "admin_compute_admin" { for_each = toset (var.tenant_groups.admin) project = google_project.project.id role = "roles/compute.admin" member = each.value } # ロール : Cloud Run 管理者 resource "google_project_iam_member" "admin_cloud_run_admin" { for_each = toset (var.tenant_groups.admin) project = google_project.project.id role = "roles/run.admin" member = each.value } ######################### # IAM 定義 - 開発者グループ ######################### # ロール : 閲覧者 resource "google_project_iam_member" "developer_viewer" { for_each = toset (var.tenant_groups.developer) project = google_project.project.id role = "roles/viewer" member = each.value } # ロール : プライベート ログ閲覧者 resource "google_project_iam_member" "developer_private_log_viewer" { for_each = toset (var.tenant_groups.developer) project = google_project.project.id role = "roles/logging.privateLogViewer" member = each.value } # ロール : Compute インスタンス管理者（v1） resource "google_project_iam_member" "developer_compute_admin" { for_each = toset (var.tenant_groups.developer) project = google_project.project.id role = "roles/compute.instanceAdmin.v1" member = each.value } # ロール : Cloud Run デベロッパー resource "google_project_iam_member" "developer_cloud_run_admin" { for_each = toset (var.tenant_groups.developer) project = google_project.project.id role = "roles/run.developer" member = each.value } ######################### # IAM 定義 - 閲覧者グループ ######################### # ロール : 閲覧者 resource "google_project_iam_member" "viewer_viewer" { for_each = toset (var.tenant_groups.viewer) project = google_project.project.id role = "roles/viewer" member = each.value } # ロール : プライベート ログ閲覧者 resource "google_project_iam_member" "viewer_private_log_viewer" { for_each = toset (var.tenant_groups.viewer) project = google_project.project.id role = "roles/logging.privateLogViewer" member = each.value } 参考 : IAM policy for projects - Terraform for_each = toset(var.tenant_groups.admin) member = each.value のように定義することで、ルートモジュールから渡されたすべての Google グループやアカウントに対して、IAM ロールが付与されるようにしています。 なお、ここでは google_project_iam_member という Terraform リソースを使用しています。その他の IAM ポリシー関係のリソースとの違いや注意点については、以下の記事を参照してください。 blog.g-gen.co.jp variable.tf このファイルでは変数を宣言します。ルートモジュールから渡されるべき変数を定義しています。 # テナント情報 variable "tenant" { type = object ( { name = string folder_id = string billing_account_id = string } ) } # 権限を付与する Google アカウント・グループのリスト variable tenant_groups { type = object ( { admin = list ( string ) developer = list ( string ) viewer = list ( string ) } ) } カスタマイズ ここまで掲載したサンプル構成ファイルをカスタマイズすることで、組織内で標準化されたプロジェクトを複数のテナントに払い出すことができます。 カスタマイズすることで、例として、払い出したプロジェクトに標準構成の VPC ネットワークを作成してそれを Network Connectivity Center ハブに接続する等も可能です。 当記事に掲載した構成ファイルはあくまでサンプルですので、実際には組織のガイドライン、運用ルール、運用体制などに準じた形の構成ファイルを記述し、使用してください。 トラブルシューティング terraform apply コマンドを実行した際に、以下のようなエラーが出力されることがあります。 Error: Provider produced inconsistent result after apply When applying changes to module.tenannt_test01.google_project_iam_member.admin_cloud_run_admin["group:non-existing-group@example.com"], provider "provider[\"registry.terraform.io/hashicorp/google\"]" produced an unexpected new value: Root resource was present, but now absent. This is a bug in the provider, which should be reported in the provider's own issue tracker. エラーメッセージには「Terraform の Google Cloud provider のバグである」旨が記述されていますが、実際にはこのエラーは、 存在しない Google グループ を IAM メンバーに指定した際に発生しました。このエラーが出力された際は、IAM ロール付与対象のプリンシパルとして指定した Google アカウントやGoogle グループの存在有無を確認してください。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の國吉です。当記事では、非エンジニアである筆者が実際に Google Vids を使用し、プロンプト入力から動画完成までの一連のプロセスをステップごとに解説します。また、その過程で見えた実用上の注意点についても触れます。 はじめに Google Vids とは Gemini in Vids データ保護の仕組み 手順 個人の言語設定の変更 Google Vids 画面への遷移 初稿の生成と編集 ナレーションの調整 ビジュアルの変更 共有 注意点 日本語での利用における注意点 編集機能の制約 AI 生成内容の調整 はじめに Google Vids とは Google Vids とは、Google Workspace に組み込まれた動画編集アプリです。Google Workspace の Business Standard 以上のほとんどのエディションに含まれており、Web ブラウザ上で利用することができます。 Google Vids では、手作業での動画作成・編集に加えて、ユーザーが入力したプロンプト（指示）や既存のドキュメントを基に、生成 AI が動画のストーリーボード、スクリプト、ナレーション、映像素材を含む初稿を自動で生成することができます。 このツールを使うことで、専門的な動画編集スキルを持たないビジネスユーザーでも、社内研修、営業提案、プロジェクトの進捗報告などのための動画を効率的に作成することができます。 参考 : Google Vids: AI 搭載の動画作成および編集ツール | Google Workspace 参考 : Google Workspace の各エディションの比較 - Google Workspace 管理者ヘルプ Gemini in Vids Google Vids に搭載された AI 関連機能を総称して Gemini in Vids と呼びます。2025年9月時点で、多くの機能が 英語対応のみ であり、日本語対応はこれからです。ただし、日本のユーザーでも、Google Workspace の個人設定で、言語設定を英語に変更すれば利用可能です。 Gemini in Vids には、以下のような機能があります。 プロンプトから動画のストーリーボード（構成案）を自動生成 AI 動画生成モデル Veo による数秒間のクリップ動画生成 AI によるナレーション生成 AI アバター（架空の人物）による説明動画の生成 データ保護の仕組み Google Vids を含む Google Workspace においては、ユーザーが作成したコンテンツ（動画、プロンプト等）の所有権は常にユーザーにあります。Google は、ユーザーのデータをモデルの再学習やサービス改善に使用することは ありません 。 参考 : Gemini in Gmail、Google Chat、Google ドキュメント、Google ドライブ、Google スプレッドシート、Google スライド、Google Meet、Google Vids でのデータ保護の仕組み 一方、無償の 個人アカウント で Google Vids 等を利用する場合、Google はサービスの改善や新機能の開発のために、そのデータを AI の学習に利用することがあります。 参考 : Google ドキュメント、スプレッドシート、スライド、Google Vids におけるプライバシーの基本を理解する 手順 個人の言語設定の変更 当記事を執筆した2025年9月現在では、AI 関連機能が日本語に対応していないため、 言語設定を英語に変更 して、AI アシスト機能を使用しました。 言語設定を英語に変更するには、Gmail や Google ドライブなど Google Workspace のいずれかのアプリ画面を開いてから、右上のアバター画像をクリックし、「Google アカウントを管理 > 個人情報 > ウェブ向けの全般設定 > 言語」をクリックします。表示された設定画面で、英語が存在しない場合は「+ 他の言語を追加」をクリックして英語を追加し、メイン言語に設定します。 言語設定の変更 Google Vids 画面への遷移 Google Vids は、Google アプリ一覧から起動できます。Gmail や Google ドライブなど Google Workspace のいずれかのアプリ画面を開いて、右上の9つの点のアイコンをクリックして表示されるアプリ一覧から Google Vids をクリックします。もしくは https://docs.google.com/videos/ にアクセスすることでも、Google Vids のスタート画面へ遷移できます。 Google アプリ一覧から起動 個人の言語設定を英語にしていると、Veo 3 によるクリップ生成やストーリーボード、AI アバターを含む、複数の動画作成の開始手順が表示されます。 英語版はじめの選択肢 一方で2025年9月現在、言語設定が日本語の場合は「録画」「アップロード」「テンプレート」「スライドを変換」基本的なスタート方法のみから選択できます。 日本語版はじめの選択肢 今回は既存のスライドをベースに動画生成をするため、 ストーリーボード を選択して、プロンプトを入力する画面に移行します。プロンプトを入力する際、 @ で Google ドライブ上のファイルを呼び出せます。2025年9月現在、日本語で作成されたファイルでもファイル名を 英語表記 にすることで読み込み可能です。 例として、プロンプトは Create a video based on this Google Slide @file_name などと指定します。 読み込みが完了すると、アウトライン編集画面 > テンプレートの選択 > デザインのサンプルを選択することで動画の下書きを自動で生成してくれます。 アウトライン編集画面 初稿の生成と編集 プロンプトを送信すると、AI が数分で動画のストーリーボード（構成案）を生成します。ストーリーボードは複数のシーンで構成されており、各シーンにはスクリプト（台本）、推奨される映像素材、ナレーションが含まれています。 今回の検証では、全61ページの Google スライドのファイル（G-gen の会社概要）を参照させたところ、3分7秒の会社紹介動画が生成されました。簡易的なプロントでしたが、合計20シーンに合った会社概要説明のスクリプト、ナレーションが自動で追加されました。スクリプトには、G-gen の「強み」「会社の遷移」「エンジニアによる資格保有」等が反映された英語のスクリプトが生成されました。 生成された動画 生成されたスクリプト この段階で、各シーンの内容を確認し、テキストを修正したり、不要なシーンを削除したり、シーンの順番を入れ替えたりすることが可能です。ドラッグ & ドロップによる直感的な操作で、動画全体の流れを簡単に調整できます。 動画の下書き ナレーションの調整 Google Vids の大きな特徴の1つが AI ナレーション 機能です。生成されたスクリプトを基に、AI が自動でナレーション音声（2025年9月現在、英語のみ）を生成します。複数の音声スタイル（AI アバター）から選択できるほか、自身の声を録音して差し替えることもできます。 スクリプトを修正すると、ナレーションも自動で再生成されるため、手作業での音声録音や編集の手間を大幅に削減できます。ただし、専門用語のイントネーションが不自然な場合などは、手動での調整や再録音が必要な場合があります。 筆者が以前、Google AI Studio で音声を生成させた際は、当社の社名である G-gen（ジージェン）の発音の指示に苦戦しましたが、Google Vids では正確な発音でナレーションが生成されました。 複数のAIアバター ビジュアルの変更 AI はスクリプトの内容に合わせて、Google が提供する高品質なストック動画や画像を各シーンに自動で配置します。しかし、より内容に即したビジュアルに変更したい場合、シーンごとに素材を変更する機能を利用します。既存の動画をクリックすると、 Veo 3 など動画生成を選べます。 自動配置されたビジュアル 動画クリップ作成 動画生成以外にも、キーワードでライブラリを検索して、最適な動画や画像を選択して差し替えたり、自身の PC から画像や動画ファイルをアップロードして使用することもできます。 共有 Google Vids の動画は、 Google ドライブ上に 保存されます。そのため、動画ファイルは Google Workspace の他のアプリケーションと同様に簡単に他人に共有できます。 共有設定画面で、共有したいユーザーやグループのメールアドレスを入力し、権限（閲覧者、編集者など）を設定します。 これにより、完成した動画をチームメンバーにレビューしてもらったり、社内ポータルに埋め込んで広く展開したりといった運用がスムーズに行えます。 注意点 日本語での利用における注意点 2025年9月現在、日本語で AI アシスト機能を使うことはできません。AI アシスト機能を使うには言語設定を英語に変える手間が都度発生します。 編集機能の制約 Google Vids は、あくまで動画作成の「アシスタント」です。細かなテロップの装飾や複雑な画面切り替え（トランジション）、詳細なエフェクトの追加といった機能は提供されていません。 AI 生成内容の調整 AI が生成する初稿は、そのままでは利用できないケースもあります。特に、自社の製品やサービスに関する固有名詞、あるいは業界特有の専門用語については、スクリプトやナレーション（発音）の修正が必要になる場合があります。 國吉 眞太郎 (記事一覧) 事業開発部 ブランド&プロモーション課。元ホテリエ経歴を持つウチナーンチュ。DX化で全員Happyになる環境作りに関わりたい！あたかも眼光が書物の紙の裏側まで見通すかのごとく、書かれた言葉の真意を深く理解するような深い読解力を有するインサイドセールスを目指す。 Follow @Kuniyoshin22

G-gen の菊池です。当記事では Looker の Dashboard Explore を使用して、モデルがどのダッシュボードで使用されているか確認する手順について解説します。 はじめに Lookerとは Lookerの構成要素 System Activity とは 環境説明 LookML Looker ダッシュボード Dashboard Explore でのモデル利用状況確認手順 Dashboard Explore の選択 ディメンションの選択 ユーザー名でフィルタ ビジュアリゼーションの指定 並び順の変更 Dashboard Explore の結果を確認 はじめに Lookerとは Looker は、エンタープライズ向けのデータプラットフォームです。開発者向けのセマンティックレイヤーとユーザー向けの BI ツールの両方の特徴を併せ持っています。 Looker 独自のモデリング言語である LookML を使用することで、分析対象のデータの構造とビジネスルールを定義するデータモデルを作成、管理できます。 Looker は、この LookML で定義されたデータモデルから自動的に SQL を生成します。そのため、SQL を知らないユーザーでも、直感的なインターフェースからデータを探索し、分析できます。 参考 : Looker Documentation 参考 : LookMLの紹介 Lookerの構成要素 LookMLは主に「モデル」「Explore」「ビュー」という3つの構造で成り立っています。 ビュー（View） ビューは、 view.lkml というファイルで定義されます。ビューは、データベースのテーブルと1対1で対応します。テーブル内の各列を ディメンション と メジャー として定義します。 ディメンション とは、日付や顧客名、商品カテゴリといったデータの属性や切り口を表します。 メジャー は売上合計やユーザー数、平均年齢といった集計値や計算したい値を表します。 Explore Explore（エクスプロア）は、 model.lkml というファイルの中で explore パラメータを使用して定義されます。ユーザーが UI 上で見る「データ探索（Explore）」画面の元となる定義です。分析の起点となるビューを一つ選び、関連する他のビューを結合させたり、範囲を定義したりします。例えば、「注文」ビューに「顧客情報」ビューや「商品情報」ビューを結合して、より多角的な分析ができます。 モデル モデルは、 model.lkml というファイルで定義されます。どのデータベースに接続するか、どの Explore をユーザーに公開するかを管理します。 参照したいデータが異なるユーザーごとにモデルを作成することで、各ユーザーに適した分析メニューを提供できます。 例えば、経営層には、財務やKPIに関する Explore をまとめた経営分析モデルを、営業チームには、顧客や商談に関する Explore をまとめた営業分析モデルを提供することで、各ユーザーが必要なデータに迷わずにアクセスできるようになります。 参考 : LookMLの用語と概念 参考 : LookML プロジェクトのファイルのタイプ System Activity とは System Activity は、Looker インスタンスの利用状況やパフォーマンスに関する情報を集約した、Lookerに組み込まれている分析機能です。デフォルトで用意されているダッシュボードと、カスタマイズ可能な Explore の2つで構成されています。 System Activity ダッシュボード Looker によってあらかじめ作成された複数のダッシュボードです。ユーザーのアクティビティ、コンテンツの利用状況、パフォーマンスなどを確認できます。データは12時間ごとに更新されます。 System Activity Explore Looker インスタンスに関する様々なデータ（ユーザー情報、閲覧履歴、クエリ履歴、ダッシュボードのパフォーマンス統計など）を確認できる複数の Explore 画面です。これらを使って独自のビジュアリゼーションを作成できます。 Dashboard Explore Dashboard Explore は、System Activity Explore の中に含まれる Explore の1つです。Looker インスタンス内に存在する「ダッシュボード」そのもののメタデータ（ダッシュボードの ID、タイトル、作成者、作成日、保存場所、設定など）を分析するための Explore です。「どのダッシュボードが存在するか」「誰がいつ作成したか」「どのフォルダにあるか」「ダッシュボードにどのようなフィルタが設定されているか」といったことを確認できます。 参考 : [System Activity] ページ 参考 : System Activity ダッシュボード 参考 : System Activity Explore 環境説明 LookML 今回の手順で使用する LookML は図のように2つのビューファイルと3つのモデルファイルが存在します。 LookMLのファイルブラウザ モデルファイルの1つ目は customers ビューを explore として定義した test_1 モデルです。2つ目は orders ビューを explore として定義した test_2 モデルです。そして3つ目は、customers ビューと orders ビューの両方を explore として定義した ecommerce モデルです。 test_1モデルファイル test_2モデルファイル ecommerceモデルファイル Looker ダッシュボード 3つのモデル（test_1、test_2、ecommerce）で定義した Explore を使用して、以下の3つのダッシュボード（sample_1、sample_2、sample_3）を作成しています。 ダッシュボードで使用しているモデル 上記の Explore を使用して作成したダッシュボードは以下のとおり、見た目では Explore の違いは分からない状態です。 sample_1ダッシュボード sample_2ダッシュボード sample_3ダッシュボード 今回は、test_1 モデルと test_2 モデルを削除して、ecommerce モデルのみを運用するケースを想定します。そのためには、test_1 モデルと test_2 モデルの Explore を使用しているダッシュボードを特定し、ecommerce モデルの Explore に切り替える必要があります。 Dashboard Explore でのモデル利用状況確認手順 Dashboard Explore の選択 Looker コンソールの左側にあるメニューから[ Explore ] > [ System Activity ] > [ Dashboard ]を選択します。Explore の検索フィールドに「System Activity」か「Dashboard」を入力して検索すると探しやすくなります。 Dashboard Explore の選択 Dashboard Explore が表示されます。 Dashboard Explore の初期画面 ディメンションの選択 左のメニューで「すべてのフィールド」タブを選択した状態で、Explore 名「Dashboard」を選択すると、フィールドの一覧が展開されます。その中から「Title」を選択すると右側のデータパネルに Title ディメンションが追加されます。 DashboardのTitleを選択 データパネル 同様の手順で以下のフィールドを選択します。 選択するフィールド フィールドピッカーの「使用中」タブを選択すると、現在選択しているフィールドのみを表示できます。 フィールド選択後のデータパネル ユーザー名でフィルタ [ User ] > [ Name ]にカーソルを合わせ、名称の右側にある「フィールドでフィルタ」マークをクリックします。 フィルタの選択 右側のフィルタパネルに User Name のフィルタが追加されるので、自身のユーザー名を選択して、右上の実行ボタンをクリックします。 フィルタの設定と探索の実行 ビジュアリゼーションの指定 探索実行後、ビジュアリゼーションパネルの上部にある「テーブル」マークをクリックすることで、表形式で結果を表示できます。 表形式のビジュアリゼーション 並び順の変更 テーブルの並び順を変更する場合は、データパネルにおいて列名の右にある上下の矢印で設定します。画像では、Dashboard Title フィールドの右側に上向きの矢印があるので、Title フィールドの昇順になっています。 テーブルの並び順 Titleの昇順 ここから、Dashboard Title、Dashboard Element Title を合わせた昇順にしたい場合は、Shift キーを押しながら、Dashboard Element Title の右側の矢印を上向きになるようにクリックします。 Shiftキーを押しながらクリックで、並び順の列を追加 複数のフィールドで並べ替え Dashboard Explore の結果を確認 ビジュアリゼーションパネルのテーブルを確認して、各ダッシュボードのタイルで、どのモデルの Explore が使用されているかを確認できます。 Dashboard Explore の結果 菊池 健太 (記事一覧) クラウドソリューション部データエンジニアリング課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、GCPは未経験なので現在勉強中。

G-gen の杉村です。Google Cloud のトラブルシューティング AI エージェントである Gemini Cloud Assist Investigations について解説します。 概要 Gemini Cloud Assist Investigations とは Preview と料金 調査開始できる画面 調査の例 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 で根本原因分析が利用可能に Preview と料金 2026年4月現在、当機能は Preview 中であり、料金は発生しません。また、調査結果は現在のところ英語で出力されます。Preview 中のプロダクトの注意点については、以下を確認してください。 参考 : Preview版のサービスを使うとはどういうことなのか - G-gen Tech Blog なお日本時間の2026年4月9日、Gemini Cloud Assist Investigations を使用する Google Cloud プロジェクトの管理者宛てに、Google から以下のような旨のメールが通知されました。 2026年4月10日から、新規の調査作成は Private Preview に移行する 移行後は、新規の調査作成はカスタマーケアの プレミアムサポート を契約している場合のみ使用可能 機能の一般提供開始時の最終的な価格や提供体系については、未決定である 作成済みの調査は、引き続き参照できる 2026年4月27日現在、プレミアムサポート未契約の環境で実際にコンソール画面を確認すると、新規の調査を作成することはできなくなっています。 参考 : Google Cloud カスタマーケア 調査開始できる画面 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年間です。日本語版と英語版の試験が提供されています。 参考 : Professional Security Operations Engineer 難易度 PSOE 試験の難易度は、Google Cloud 認定資格の中でも 比較的高い といえます。 公式ガイドでは「3年以上のセキュリティ業界経験」「1年以上の Google Cloud におけるセキュリティツール群の利用経験」が求められると記載されています。当試験で中心的に扱われる Google のセキュリティ製品は有償のものが多く、またある程度の規模感をもつ組織でないと導入されない性質です。これらの製品を普段から業務で扱っているエンジニアは少なく、またインターネット上に情報が豊富に公開されていないことが、当試験を難しくしています。 逆に言えば、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 です。データポータル（英名 Data Studio、旧称 Looker Studio）で Cloud Storage 上の非公開画像を扱う際に、BigQuery の EXTERNAL_OBJECT_TRANSFORM 関数を利用して署名付き URL を生成する方法があります。本記事ではその具体的な手順と、複数の画像を表示しようとした際に発生するレート制限エラーの原因と対処法について解説します。 事象 背景 原因 実装手順 1. Cloud Storage バケットの準備 2. BigQuery Connection API の有効化 3. 接続の作成 4. サービスアカウントへの権限付与 5. オブジェクトテーブルの作成 6. データポータルでの設定 対処案1 : レポート側の工夫（緩和策） 対処案2 : 署名付き URL をテーブルに保存（推奨） 手順 ビューの使用について 注意点 事象 データポータルのレポートに、Cloud Storage バケット上に配置した画像ファイルを表示する要件がありました。このバケットおよび画像ファイルは、インターネットに公開していません。 認証を経てレポートに画像を表示するために、BigQuery の EXTERNAL_OBJECT_TRANSFORM 関数を用いて、BigQuery のオブジェクトテーブルから署名付き URL を生成し、この URL を使って データポータルのレポートに画像を表示することを試みました。 実装してみると、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 一部画像が表示されない 詳細を表示すると割り当てエラーのメッセージが表示される 背景 今回のように、データポータルのレポートで Cloud Storage に保存されている非公開の画像（インターネットに公開せず、アクセスに認証を必要とする画像ファイル）を一部のユーザーにのみ表示するには、いくつかの方法があります。 1つ目は、Cloud Storage オブジェクトの「認証済み URL」を使用する方法です。オブジェクトが持つ認証済み URL を データポータルの IMAGE 関数に渡すことで、レポートに表示します。 参考 : Looker StudioでCloud Storageの画像が表示されない時の対処法 - G-gen Tech Blog 上記の方法では、画像を表示するにはレポートの閲覧者が Cloud Storage バケットもしくは画像オブジェクトに対して閲覧権限を持っている必要があります。しかし今回は、データポータルの レポートに対して 閲覧権限を持っている人であれば、Cloud Storage バケットやオブジェクトに対して閲覧権限を持っていないなくても、画像を表示できるようにしたい要件がありましたので、この方法は適切ではありません。 そこで今回は、2つ目の方法である BigQuery の オブジェクトテーブル から 署名付き URL （Signed URL）を生成する EXTERNAL_OBJECT_TRANSFORM 関数を用いる方法を用いました。この関数は、オブジェクトテーブルの管理対象となっている Cloud Storage オブジェクトの署名付き URL を生成します。 参考 : オブジェクト テーブルの概要 参考 : 署名付き URL この方法では、データポータルのレポートのデータソースとして、BigQuery のオブジェクトテーブルを指定します。その上で データポータルのカスタムクエリにおいて EXTERNAL_OBJECT_TRANSFORM 関数を使用することで、当該テーブルへのクエリ権限を持っている人（データソースへの認証を「レポートのオーナー」または「サービスアカウント」にしている場合は、レポートへのアクセス権限を持っている人）であれば、署名付き URL を取得でき、同 URL 経由で画像へアクセスして表示することができます。 原因 公式ドキュメントによると、このエラーは、 EXTERNAL_OBJECT_TRANSFORM 関数を含むクエリの同時実行数が、プロジェクトに設定された割り当て（クォータ）を超過したことが原因です。 EXTERNAL_OBJECT_TRANSFORM 関数の呼び出しの同時実行数（リモート関数を含む同時実行クエリ）は、 プロジェクトあたり 10 と定められています。したがって、11個以上のクエリが発行されるような画像を一度に表示しようとすると、エラーが発生します。 参考 : Maximum rate of table metadata update operations limit errors 参考 : 割り当てと上限 | クエリジョブ 今回、レポート上には表グラフが4つのみ配置されていました。データポータルでは、表グラフごとに BigQuery に対してクエリを発行しているため、ドキュメント上の上限である 10 クエリを下回っています。しかし、実際にはクォータエラーが発生しました。これは、データポータルの内部的な動作により、レポート上のコンポーネント数以上にクエリが発行された、あるいは非常に短い時間間隔でのクエリ集中を BigQuery 側が同時実行と見なしたことなどが原因として考えられます。 この現象から、根本的な問題は データポータルのカスタムクエリから 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. データポータルでの設定 データポータルでデータソースとして BigQuery を選択し、「 カスタムクエリ 」に以下のSQLを記述します。 SELECT uri, signed_url FROM EXTERNAL_OBJECT_TRANSFORM( TABLE `my-project.my_dataset.my_object_table`, [ ' SIGNED_URL ' ] ); データポータルのデータソースのフィールド編集画面で、 IMAGE 関数 を使用して新しい計算フィールドを作成します。この関数に signed_url フィールドを渡すことで、URL を画像として表示できます。 IMAGE(signed_url, "代替テキスト") 作成したフィールドをレポートの表などに追加すると、署名付き URL によって画像が表示されます。 参考 : IMAGE 対処案1 : レポート側の工夫（緩和策） 1つのレポートページに表示するグラフや画像の数を減らし、同時実行クォータである 10 以下に収まるように調整する方法です。 この方法は手軽ですが、表示したいレポートのレイアウトや画像の数に制約がかかるため、根本的な解決策ではありません。 対処案2 : 署名付き URL をテーブルに保存（推奨） 手順 EXTERNAL_OBJECT_TRANSFORM を含むクエリを定期的に実行し、生成された署名付き URL を別の BigQuery テーブルに保存します。データポータルは、この保存先のテーブルを参照するように設定します。 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 ' ] ); データポータルのデータソースは、この 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 なお、データポータルは取得した画像を内部でキャッシュすることがあります。そのため、テーブル上の署名付き URL の有効期限が切れた後も、データポータルのキャッシュが有効な間は画像が表示され続ける場合があります。ただし、URL 自体は無効になっているため、リンクへ直接アクセスするとエラーが表示されます。 データポータルから有効期間後にリンクへ直接アクセスした場合のエラー例 佐々木 愛美 (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 音声を出力。 製品ラインとしては Gemini Notebook Enterprise だが、Gemini Notebook 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 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。