G-gen の三浦です。当記事では、 Chrome Enterprise Premium を利用して Web ブラウザのセキュリティを強化する方法を紹介します。 概要 Chrome Enterprise Premium とは Core と Premium 検証手順 URL フィルタリングの検証 設定手順 動作確認 DLP の検証 設定手順 動作確認 概要 Chrome Enterprise Premium とは Chrome Enterprise Premium （旧称 BeyondCorp Enterprise）は、Google が提供する Chrome ブラウザのセキュリティを強化するサービスです。 組織のポリシーに応じて、 ゲーム などのカテゴリに対する URL フィルタリング や、 データ損失防止（DLP） 機能を設定し、機密情報のアップロードなどを制御できます。 詳細やその他の機能については、以下の記事および公式ドキュメントをご参照ください。 参考 : Chrome Enterprise Premium でブラウザの セキュリティ を強化 blog.g-gen.co.jp Core と Premium Chrome Enterprise は、 Core（無償） と Premium（有償） の2つのプランに分かれています。 Core では、Chrome ブラウザの基本的な管理機能（ポリシー管理、拡張機能の管理など）を利用できます。 一方、 Premium は DLP による情報漏えい対策や、ブラウザ経由のマルウェア対策など、より高度なセキュリティ機能を使用できます。 両プランの詳細な機能差分については、以下の公式ドキュメントをご参照ください。 参考 : Chrome Enterprise Premium でブラウザの セキュリティ を強化 検証手順 検証手順は次のとおりです。 項番 内容 説明 1 URL フィルタリングの設定 カテゴリ「写真・動画共有」へのアクセスをブロックするルールを設定します。 2 URL フィルタリングの動作確認 YouTube へアクセスし、ブロックされることを確認します。 3 DLP の設定 「社外秘」という文字列を含むファイルのアップロードをブロックするルールを設定します。 4 DLP の動作確認 条件を満たすファイルを Google Cloud の Cloud Storage バケットにアップロードし、ブロックされることを確認します。 URL フィルタリングの検証 設定手順 Google Workspace の管理コンソール（ https://admin.google.com ）にログインします。 参考 : 管理コンソールにログインする [Chrome ブラウザ] > [レポート] > [セキュリティ インサイト] に移動し、[有効にする] を選択します。 有効にするを選択 参考 : 組織内部のリスクとデータ損失のモニタリング 内容を確認し、[有効にする] を選択します。 有効にするを選択 [セキュリティ] > [アクセスとデータ管理] > [データの保護] に移動し、[ルールを管理] を選択します。 ルールを管理を選択 [ルールを追加] > [新しいルール] を選択します。 新しいルールを選択 以下を設定し、[続行] を選択します。 名前：任意のルール名 範囲：ルールの適用範囲を選択（ 組織全体 か 特定の組織部門 、 Google グループ から選択） ルール作成1 以下を設定し、[続行] を選択します。 Chrome ： アクセスした URL ルール作成2 [条件を追加] > [URL のカテゴリ] > [カテゴリを選択] から対象のカテゴリを選択します。 ルール作成3 ルール作成4 内容を確認し、[続行] を選択します。 ※ コンテキストの条件 から、コンテキストアウェアアクセスで指定した条件（例 : 会社所有の端末からのアクセス）を満たした場合のみ、ルールを適用させることができます。使用例として、特定の端末のみ、カテゴリ クラウド ストレージ に該当する URL へのアクセスを許可すること等ができます。 ルール作成5 以下のとおりに設定し、[続行] を選択します。 操作 Chrome： ブロック アラート 重大度： 高 アラートセンターに送信する： 有効化 し、送信者を指定 ルール作成6 ルール作成7 設定内容を確認し、[作成] を選択します。 ルール作成8 動作確認 Chrome ブラウザで YouTube（ https://www.youtube.com ）にアクセスし、ページが表示されないことを確認します。 ブロック確認（URLフィルタリング） [レポート] > [監査と調査] > [Chrome のログイベント] から以下条件で検索することで、ブロック時のログを確認できます。 イベントの結果 次に一致 ブロック中 ブロック時のログ確認1 ブロック時のログ確認2 DLP の検証 設定手順 [セキュリティ] > [アクセスとデータ管理] > [データの保護] に移動し、[ルールを管理] を選択します。 ルールを管理を選択 [ルールを追加] > [新しいルール] を選択します。 新しいルールを選択 以下を設定し、[続行] を選択します。 名前：任意のルール名 範囲：ルールの適用範囲を選択（ 組織全体 か 特定の組織部門 、 Google グループ から選択） ルール作成1 以下を設定し、[続行] を選択します。 Chrome ： アップロードされたファイル ルール作成2 検出条件として、 社外秘 という文字列を含むファイルにルールが適用されるように設定し、[続行] を選択します。 ルール作成3 以下のとおりに設定し、[続行] を選択します。 操作 Chrome： ブロック アラート 重大度： 高 アラートセンターに送信する： 有効化 し、送信者を指定 ルール作成4 ルール作成5 設定内容を確認し、[作成] を選択します。 ルール作成6 動作確認 テスト用のファイルを準備します。 テストファイル Cloud Storage のバケットへファイルをアップロードします。 Cloud Storageへのアップロード 警告が表示され、アップロードに失敗することを確認します。 アップロード動作確認1 アップロード動作確認2 URL フィルタリングと同様に [レポート] > [監査と調査] > [Chrome のログイベント] から以下条件で検索することで、ブロック時のログを確認できます。 イベントの結果 次に一致 ブロック中 ブロック時のログ確認1 ブロック時のログ確認2 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の佐々木です。当記事では AlloyDB for PostgreSQL の停止・起動および再起動オペレーションについて解説します。 前提知識 AlloyDB for PostgreSQL とは AlloyDB の料金の基本 インスタンスの停止・起動 停止・起動の仕様 Activation policy 停止・起動の影響 読み取りプールインスタンスやセカンダリクラスタがある場合の注意点 インスタンスの停止オペレーション インスタンスの起動オペレーション インスタンスの再起動 再起動の仕様 インスタンスの再起動オペレーション 各オペレーションの記録 前提知識 AlloyDB for PostgreSQL とは AlloyDB for PostgreSQL （以下、AlloyDB） は、Google Cloud の高性能な PostgreSQL 互換のフルマネージドサービスです。 AlloyDB は Cloud SQL 同様に、リレーショナル データベースを提供するサービスですが、パフォーマンス、可用性、スケーラビリティの面で優れています。 また独自のストレージ機構により、標準の PostgreSQL と比較してオンライン分析処理（OLAP）のパフォーマンスが非常に高いという特性があります。 AlloyDB の詳細については以下の記事をご一読ください。 blog.g-gen.co.jp AlloyDB の料金の基本 AlloyDB は従量課金制であり、以下の軸で料金が発生します。 コンピューティングリソース（CPU/メモリ） ストレージ（バックアップ含む） ネットワーク（リージョン間の egress のみ） このうち、主にコンピューティングリソースの利用料金がインスタンスの停止・起動による影響を受けます。 参考 : AlloyDB for PostgreSQL pricing インスタンスの停止・起動 停止・起動の仕様 AlloyDB クラスタのプライマリインスタンスや読み取りプールインスタンスは、停止・起動・再起動が可能です。 停止したインスタンスに対しては、コンピューティング料金が発生しません。このため、開発環境インスタンス等の料金の節約に繋がります。ただし、停止してもストレージ料金は引き続き発生します。 参考 : Start, stop, or restart instances Activation policy AlloyDB は、Activation policy という設定値を用いてデータベース インスタンスの状態を操作します。 Activation policy の設定値として以下の2種類があります。 設定値 説明 ALWAYS インスタンスが稼働している状態を指す。 NEVER インスタンスが停止し、データベース接続を受け入れていない状態を指す。 この状態ではコンピューティングリソース料金が発生しない。 停止・起動の影響 インスタンスの停止・起動を行うと、以下のような影響があります。 インスタンスを停止すると、インスタンスのコンピューティング料金が発生しない（ストレージ料金は引き続き発生）。 インスタンスを停止すると、自動アップデートが停止される（自動バックアップは引き続き行われる）。 停止しているインスタンスを起動すると、データベースの最新のマイナーバージョンが適用される。このバージョン適用はメンテナンスの拒否期間を無視して行われる。 また、インスタンスでパブリック IP アドレスを有効化している場合、停止・起動オペレーションによってパブリック IP アドレスが変わることはありません。この場合、インスタンスの停止中も静的 IP アドレスの料金が発生します。 インスタンスのプライベート IP アドレスについても停止・起動によって変化することはありません。 参考 : External IP address pricing 読み取りプールインスタンスやセカンダリクラスタがある場合の注意点 インスタンスの停止・起動オペレーションは、AlloyDB の プライマリインスタンス 、 読み取りプールインスタンス のどちらでも行うことができます。 プライマリインスタンスを停止する前に、必ず読み取りプールインスタンスを停止する必要があります。読み取りプールインスタンスが起動している状態でプライマリインスタンスの停止オペレーションを行うと、以下のようなエラーが発生します。 ERROR: (gcloud.alloydb.instances.update) FAILED_PRECONDITION: Invalid resource state for "projects/<プロジェクト番号>locations/asia-northeast1/clusters/<クラスタ ID>/instances/<インスタンス ID>": activation policy for primary instance can only be updated to NEVER only when all read instances are stopped, found read instance test-reader in READY state 停止とは逆に、起動オペレーションでは必ずプライマリインスタンスから起動する必要があります。プライマリインスタンスが停止している状態で読み取りプールインスタンスの起動オペレーションを行うと、以下のようなエラーが発生します。 ERROR: (gcloud.alloydb.instances.update) FAILED_PRECONDITION: Invalid resource state for "projects/<プロジェクト番号>/locations/asia-northeast1/<クラスタ ID>/test/instances/<インスタンス ID>": The parent cluster contains a PRIMARY instance "projects/<プロジェクト番号>/locations/asia-northeast1/clusters/<クラスタ ID>/instances/<インスタンス ID>", but it is not in a READY state (got state: STOPPED) また、クラスタに セカンダリクラスタ （クロスリージョンレプリケーション クラスタ）がある場合は、プライマリインスタンスを停止することができません。停止のためにはセカンダリクラスタを昇格もしくは削除する必要があります。 セカンダリクラスタがある状態でプライマリインスタンスの停止オペレーションを行うと、以下のようなエラーが発生します。 ERROR: (gcloud.alloydb.instances.update) FAILED_PRECONDITION: Invalid resource state for "projects/<プロジェクト番号>/locations/asia-northeast1/clusters/<クラスタ ID>/instances/<インスタンス ID>": activation policy for primary instance can only be updated to NEVER only when there is no CRR enabled なお、セカンダリクラスタのインスタンスを停止することはできません。 インスタンスの停止オペレーション インスタンスの停止・起動オペレーションは、コンソールや gcloud CLI 等から行うことができます。 停止オペレーションは以下のコマンドで実行することができます。クラスタの更新オペレーションで Activation policy を NEVER に設定することがポイントです。 # AlloyDB インスタンスを停止する $ gcloud alloydb instances update < 停止対象インスタンスの ID > \ --region =< クラスタのリージョン > \ --cluster =< クラスタの ID > \ --activation-policy = NEVER 読み取りプールインスタンスを停止する場合は、 <停止対象インスタンスの ID> に読み取りプールインスタンスの ID を指定します。 インスタンスの停止時間の参考として、作成したばかりの最小サイズのインスタンスで停止に5分ほどかかりました。 インスタンスの起動オペレーション インスタンスの起動オペレーションは以下のコマンドで実行することができます。起動の場合は Activation policy を ALWAYS に設定することがポイントです。 # AlloyDB インスタンスを起動する $ gcloud alloydb instances update < 起動対象インスタンスの ID > \ --region =< クラスタのリージョン > \ --cluster =< クラスタの ID > \ --activation-policy = ALWAYS インスタンスの起動時間の参考として、作成したばかりの最小サイズのインスタンスで起動に8分ほどかかりました。 インスタンスの再起動 再起動の仕様 インスタンスの再起動を行うと、再起動が完了して準備が整うまでインスタンスの接続がすべて中断されます。 インスタンスの再起動によるプライベート IP アドレスおよびパブリック IP アドレスの変化はありません。 セカンダリインスタンスやリードプールインスタンスの個別ノードは、停止・起動はできず、起動中のインスタンス・ノードの再起動のみが可能です。 インスタンスの再起動オペレーション インスタンスの再起動も、コンソールや gcloud CLI 等から行うことができます。 再起動オペレーションは以下のコマンドで実行することができます。停止・起動オペレーションと異なり、専用の restart コマンドがあります。 # AlloyDB インスタンスを再起動する $ gcloud alloydb instances restart < 再起動対象インスタンスの ID > \ --region =< クラスタのリージョン > \ --cluster =< クラスタの ID > \ [ --async ] 再起動中に AlloyDB Studio からクエリを試したところ、再起動中であってもクエリを実行することができました。 再起動中にクエリを実行した場合、結果が返ってくる場合もある しかし、クエリの成功は保証されていないため、基本的には再起動であってもデータベースを使用しない時間帯に行うことが推奨されます。 インスタンスの再起動時間の参考として、作成したばかりの最小サイズのインスタンスで再起動までに13分ほどかかりました。 各オペレーションの記録 オペレーションの実行記録はコンソールから確認することができますが、停止・起動オペレーションは「インスタンスの更新」としてまとめられてしまうようです。 停止・起動オペレーションは「インスタンスの更新」にまとめられている 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では Pub/Sub の Single Message Transforms（SMTs） 機能によるメッセージの変換処理について解説します。 前提知識 : Pub/Sub とは Single Message Transforms（SMTs）とは SMTs の基本 SMTs のユースケース UDF による定義 SMTs の注意事項 当記事の構成 宛先 BigQuery テーブルの作成 SMTs を設定した Pub/Sub トピックの作成 SMTs を設定した Pub/Sub サブスクリプションの作成 users テーブルに書き込むサブスクリプション scores テーブルに書き込むサブスクリプション メッセージの送信 前提知識 : Pub/Sub とは Pub/Sub は、Google Cloud のフルマネージドなメッセージングサービスです。 Pub/Sub を始めとしたメッセージングサービスの詳細やユースケースについては、以下の記事をご一読ください。 blog.g-gen.co.jp Single Message Transforms（SMTs）とは SMTs の基本 Single Message Transforms （以下、 SMTs ）は、Pub/Sub を使用したストリーミング パイプラインにおける単純なデータ変換を実現する機能です。 SMTs では Pub/Sub 自体にデータの変換処理を実装することで、Pub/Sub の前後で（Dataflow や Cloud Run functions などを使用して）データ変換処理を行うような、パイプラインの複雑化を回避することができます。 SMTs によるデータ変換処理は、Pub/Sub の トピック と サブスクリプション のそれぞれに対して設定することができます。 SMTs の設定箇所 変換処理のタイミング ユースケース トピック メッセージがトピックに永続化される前に変換が行われる。 ・サブスクリプションが複数ある場合に、共通の変換処理を行う。 ・後続の処理に渡すメッセージのデータ量を削減する。 ・無効なメッセージを検証してパブリッシュを抑制する。 サブスクリプション メッセージがサブスクリプションに配信される前に変換が行われる。 ・サブスクリプション特有の変換処理を行う。 ・無効なメッセージをデッドレタートピックに書き込んでアーカイブする。 SMTs はトピックとサブスクリプションに設定することができる SMTs は対象ごとに最大5個まで設定することができ、上に設定したものから順番に実行されます。 SMTs を複数設定すると上から順に実行される（順番は変更できる） 参考 : Single Message Transforms (SMTs) overview 参考 : Choose topic or subscription SMTs SMTs のユースケース SMTs のユースケースを以下に示します。 文字列操作、日付の書式変換、数値計算など、単純なデータ変換 異なるシステム間で互換性を担保するためのデータ形式の変換 クレジットカード番号や個人情報（PII）などのデータのマスキング・編集 不要なメッセージの破棄（フィルタリング） メッセージのフィルタリングについては Pub/Sub 組み込みのフィルタリング機能で実現することもできますが、SMTs ではより複雑な条件でフィルタリングを行うことができます。 参考 : Filter messages from a subscription UDF による定義 SMTs は、JavaScript による User-Defined Function（UDF） を使用して実装します。 SMTs で使用する UDF は、単一のメッセージを message 引数として受け取り、処理の結果を返します。 function <関数名 > ( message , metadata ) { // ここに処理内容を記述 return message ; // 戻り値は `null` も可能 } メッセージのペイロードは message.data 、メッセージ属性の KeyValue ペアは message.attributes で取得できます。UDF の戻り値を null とした場合、処理対象のメッセージは破棄されます。 なお、UDF でエラーが発生した場合は、トピックの SMTs であればパブリッシャーにエラーを返し、サブスクリプションの SMTs であればメッセージを否定応答（nack）します。 SMTs における UDF の詳細については以下のドキュメントを参照してください。 参考 : User Defined Functions (UDFs) overview SMTs の注意事項 SMTs を使用する際の注意事項を以下に示します。 SMTs はトピックおよびサブスクリプションのそれぞれに対して 最大5つ まで設定可能 SMTs は単一のメッセージに対して動作するものであり、複数のメッセージを集約するような処理はできない 順序付けが有効になっているメッセージ に対する SMTs の処理がエラーとなった場合、後続のメッセージは配信されない。この場合、 デッドレタートピック を使用してエラーが発生したメッセージをバッグログから削除する必要がある また、UDF の実行には以下の制限があります。 UDF あたりのコード量は最大20KB メッセージごとの UDF の最大実行時間（タイムアウト）は500ミリ秒 外部 API の呼び出しは不可 外部ライブラリのインポートは不可 これらの制限に抵触するような処理を実行したい場合は、Dataflow や Cloud Run functions を用いた実装を検討するとよいでしょう。 当記事の構成 当記事では BigQuery サブスクリプション を使用し、トピックとサブスクリプションに SMTs を設定して、変換後のメッセージを BigQuery テーブルに書き込む処理を試してみます。 トピックとサブスクリプションの両方で SMTs によるメッセージ変換を行い、2つのテーブル（users, scores）に異なるデータを挿入してみます。 トピックとサブスクリプションで SMTs を使用するサンプル構成 まず、トピックの SMTs では、メッセージのペイロード内の id フィールドの値を、int 型から string 型に変換します。 そして、トピックで変換したメッセージを各サブスクリプションの SMTs で処理します。 BigQuery サブスクリプションを2つ用意して、一方では score フィールドを削除して users テーブルに書き込み、もう一方では name フィールドを削除して scores テーブルに書き込みます。 BigQuery サブスクリプションの詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp 宛先 BigQuery テーブルの作成 まず、BigQuery サブスクリプションの宛先となるテーブルを2つ作成します。 1つ目の users テーブルは以下のスキーマで作成します。 フィールド名 種類 id STRING name STRING users テーブルのスキーマ 2つ目の scores テーブルは以下のスキーマで作成します。 フィールド名 種類 id STRING score INTEGER scores テーブルのスキーマ SMTs を設定した Pub/Sub トピックの作成 パブリッシャーからメッセージを受け取るトピックを作成します。 トピック作成画面の「変換」項目で、トピックで実行される SMTs を設定することができます。 関数名に convertIdToString と入力し、以下の UDF を記述します。 // convertIdToString 関数 function convertIdToString ( message , metadata ) { const data = JSON . parse ( message . data ) ; data [ 'id' ] = String ( data [ "id" ]) ; message . data = JSON . stringify ( data ) ; return message ; } この UDF により、メッセージペイロード（data）の id フィールドが int 型から string 型に変換され、 id フィールド変換後のメッセージ全体が後続のサブスクリプションに送信されます。 SMTs によるメッセージ変換を行うトピックを作成する SMTs を設定した Pub/Sub サブスクリプションの作成 users テーブルに書き込むサブスクリプション users テーブルに id と name のデータを書き込む BigQuery サブスクリプションを作成します。 まず、サブスクリプション作成画面の「配信タイプ」項目で「BigQuery への書き込み」にチェックを入れ、 users テーブルを指定します。 そして、メッセージペイロードのフィールド名をテーブルの列名と対応づけるため、「スキーマ構成」項目で「テーブル スキーマを使用する」にチェックを入れます。 BigQuery の users テーブルへの書き込み設定 「変換」項目で、サブスクリプションで実行される SMTs を設定することができます。 関数名に deleteScore と入力し、以下の UDF を記述します。 // deleteScore 関数 function deleteScore ( message , metadata ) { const data = JSON . parse ( message . data ) ; delete data [ 'score' ] ; message . data = JSON . stringify ( data ) ; return message ; } この UDF により、メッセージペイロードの score フィールドが削除され、削除後のメッセージが BigQuery の users テーブルに書き込まれます。 users テーブルに書き込むサブスクリプションの SMTs を設定する scores テーブルに書き込むサブスクリプション 先ほどと同様に、今度は scores テーブルに書き込むサブスクリプションを作成します。 BigQuery の scores テーブルへの書き込み設定 「変換」項目にて、関数名に deleteName と入力し、以下の UDF を記述します。 // deleteName 関数 function deleteName ( message , metadata ) { const data = JSON . parse ( message . data ) ; delete data [ 'name' ] ; message . data = JSON . stringify ( data ) ; return message ; } この UDF により、メッセージペイロードの name フィールドが削除され、削除後のメッセージが BigQuery の scores テーブルに書き込まれます。 scores テーブルに書き込むサブスクリプションの SMTs を設定する メッセージの送信 SMTs を設定したトピック、サブスクリプションの準備が完了したので、動作確認を行います。 トピックの詳細画面から「メッセージ」タブを開き、「メッセージをパブリッシュ」を押下します。 「メッセージ本文」に以下のメッセージを記述し、「公開」を押下してメッセージをパブリッシュします。 { " id ": 1001 , " name ":" sasashun ", " score ": 100 } このメッセージの id フィールドの値は int 型であり、対応する BigQuery テーブルの id 列は STRING 型であるため、トピックの SMTs で型の変換を行います。 その後、 users テーブルに書き込むサブスクリプションでは scores フィールドを、 scores テーブルに書き込むサブスクリプションでは name フィールドを、それぞれ SMTs を使用して削除します。 テストメッセージのパブリッシュ メッセージのパブリッシュ後、BigQuery の各テーブルを確認してみます。 users テーブルには、最初にトピックで id フィールドの値を int 型から string 型に変換し、次にサブスクリプションで score フィールドが削除された結果のデータが挿入されています。 users テーブルの SELECT クエリ結果 scores テーブルには、最初にトピックで id フィールドの値を int 型から string 型に変換し、次にサブスクリプションで name フィールドが削除された結果のデータが挿入されています。 scores テーブルの SELECT クエリ結果 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。当社 G-gen では、Google の生成 AI サービスを積極的に業務で利用しています。本記事では、Gemini API や Gemini for Google Workspace を G-gen の従業員がどのように利用しているか、具体的な事例を交えて紹介します。 はじめに 本記事について G-gen の業務環境と Gemini Gemini の進化 データの保護 Gemini アプリ Gemini アプリとは 生成や解説、要約 Gems を利用した特定タスクの効率化 ブログ記事・ドキュメントの草案作成 レビュー・アイデア出し ソースコード生成 Deep Research による調査レポート NotebookLM NotebookLM とは 個人ドキュメントの整理・要約 ポッドキャスト風音声の生成 FAQ 作成 Google Meet Google Meet と Gemini 発言内容の文字起こし 会議の要約とアクションアイテム抽出 Google ドキュメント Google ドキュメントと Gemini 文章の生成・修正 ドキュメントの要約 Gmail Gmail と Gemini メールの下書き作成 文章の推敲 予定の作成 和英・英和翻訳 Google スライド Google スライドと Gemini 画像生成 テキストコンテンツの草案作成 スピーカーノートの作成 Google スプレッドシート Google スプレッドシートと Gemini テンプレートの作成や関数の生成 データ整理と分析のアイデア出し Gemini Code Assist Gemini Code Assist とは コード生成・補完 コードの説明・レビュー コードレポジトリとの連携 Generative AI on Vertex AI Vertex AI と Gemini 議事録作成を効率化 技術サポート窓口やブログ記事のナレッジ活用 Slack チャットボット 最新技術アップデートの要約 はじめに 本記事について 本記事では、G-gen 社内における具体的な Gemini の活用事例を紹介します。生成 AI の業務利用を意図している方や、Gemini の導入やさらなる活用を検討している企業の方の参考情報となることを目的としています。 G-gen の業務環境と Gemini 株式会社 G-gen は、Google Cloud・Google Workspace 専業のクラウドインテグレーターです。Google Cloud を使った開発やインフラ構築、顧客環境のセキュリティ強化、コスト削減など、さまざまな業務を行っています。また、Google Cloud・Google Workspace の請求代行サービスをご利用の場合、割引料金が適用されます。 G-gen は、社内に物理的なサーバーを一切保有せず、全従業員がリモートで勤務しています。そのため、日常業務のほぼすべてが Google Workspace 上で行われています。 このような当社環境において、Google Workspace に統合された AI 機能である Gemini for Google Workspace は、従業員の生産性向上に役立っています。Gemini for Google Workspace は、ほとんどの商用 Google Workspace エディション（Business Standard、Business Plus、Enterprise Standard、Enterprise Plus など）に 追加料金なし で含まれており、特別なセットアップなしで利用を開始できます。 参考 : Google Workspace の料金 参考 : Gemini for Google Workspace 以前は、Google Workspace で生成 AI 機能を利用するには、Gemini アドオンライセンスが必要でした。しかし2025年1月16日以降、アドオンライセンスが不要になり、 ほとんどすべてのエディションにデフォルトで Gemini が組み込まれ ました。 参考 : Google Workspace Business エディションの AI 機能と料金改定 Gemini の進化 2025年4月、 Gemini 2.5 Pro の登場により、日本語の長文読解や生成、要約の精度が大幅に向上し、より多くの業務シーンで Gemini が利用されるようになりました。 参考 : Gemini 2.5: Our most intelligent AI model 早い段階で Gemini を試した方の中には、日本語の文章の生成や読解に不満を覚えた方もいるかもしれません。しかし Gemini 2.5 では精度が大幅に向上しており、業務レベルで利用可能になったといえます。G-gen でも、これまでよりも Gemini の活用の幅が広がっています。 また、Gemini for Google Workspace の各機能は、リリース当初は日本語に対応していない場合がありましたが、2025年5月現在ではほとんどの機能が日本語に対応しています（一部は Alpha 版）。 データの保護 Gemini for Google Workspace や、Gemini アプリ、Google Cloud の Gemini API などでは、入力されたプロンプトや出力されたコンテンツ、アップロードされたデータなどは、 適切に保護 されます。 これらの情報が、Google によってモデルのトレーニングに利用されたり、外部に流出することはありません。 参考 : Gemini for Google Workspace に関するよくある質問 - Google Workspace with Gemini ではどのようにデータが保護されますか？ 参考 : Gemini in Gmail、Google Chat、Google ドキュメント、Google ドライブ、Google スプレッドシート、Google スライド、Google Meet、Google Vids でのデータ保護の仕組み 参考 : 生成 AI とデータ ガバナンス Gemini アプリ Gemini アプリとは Google Workspace 統合機能に加え、スタンドアロンの Gemini アプリ （旧 Bard）も広く利用されています。Gemini アプリは、Web ブラウザやモバイルアプリでアクセスできる対話型 AI サービスです。自由な形式での質問応答、文章生成、アイデア出し、アプリ開発などに利用できます。 参考 : Gemini アプリ 参考 : Gemini でのアプリの利用と管理 Gemini アプリでウェブアプリを開発（Canvas 機能） 特に G-gen では、ブラウザからアクセスして利用する Gemini ウェブアプリが多用されています。Google Workspace の場合、管理コンソールから従業員の Gemini の利用状況が確認できます。G-gen 社内では、Gemini for Google Workspace の各機能の中で Gemini アプリが最も利用頻度が高く、半数以上の従業員が日常的に利用しています。 参考 : 組織での Gemini の使用状況を確認する 生成や解説、要約 Gemini アプリに自然言語で指示をすると、文章の生成や解説、要約などが可能です。また、画像を生成させることもできます。知らない単語の意味を掴むためにも有用です。 Gemini アプリへの質問 和英翻訳や英和翻訳も可能です。英語の技術情報を解釈したり、海外の相手にメールを送る時などにも利用できます。特に、英語でのビジネスメールに慣れていない日本語話者にとっては、失礼がなく自然に見える文章の生成に役立ちます。 Gemini による翻訳 また Google スライドや Google ドキュメントなど、Google ドライブ上のファイルを指定して、それらに基づいた生成を行うこともできます。 スピーカーノートを Gemini アプリに生成させる Gems を利用した特定タスクの効率化 Gemini アプリの Gems 機能を利用して、特定のペルソナやタスクに特化した指示（カスタム指示）をあらかじめ作成しておき、繰り返し行う作業を効率化できます。Gems は、特定の役割（例 : 翻訳アシスタント、コードレビュアー、ブログ記事のレビュアー）や目的に合わせた指示を保存しておき、ワンクリックで Gemini をそのモードで起動できる機能です。 blog.g-gen.co.jp Gemini アプリの Gems 機能 Gems の編集画面 以下は、Gems の利用例です。 和英・英和翻訳 Gem 日本語の技術文書やメールの下書きを、自然な英語表現に翻訳するための Gem を作成し、海外パートナーとのコミュニケーションに利用しています。「英語が入力されれば日本語に、日本語が入力されれば英語に翻訳。必ず複数案を提示する」のようなプロンプトをあらかじめ登録しておくことで、このシステム指示を毎回入力する必要性がなくなります。 技術アップデート解釈 Gem Google Cloud や Google Workspace の新機能リリースノートを読み込ませ、「このアップデートの重要な点は何か」「G-gen の顧客にどのような影響があるか」といった観点で要約・解釈させる Gem を利用し、最新情報のキャッチアップを効率化できます。 ブログ下書きレビュー Gem 社内の執筆ガイドラインに沿っているか、技術ブログの下書きをレビューさせます。Gemini アプリは長大なプロンプトを読み込ませることができるので、体裁ルールを指示するほか、模範的な記事の全文を1個、システム指示プロンプトに組み込んでおくことで、精度の高いレビューや訂正が可能です。 議事録整備 Gem Google Meet では、Web 会議で発言された言葉を Google ドキュメントに文字起こしできます。この内容を整理して、議事録を作成する Gem を作成できます。「えーと」「あー」といったフィラーを削除したり、規定の形式に整理できます。 ブログ記事・ドキュメントの草案作成 G-gen Tech Blog の記事執筆や、新しい技術に関する調査レポート作成の初期段階で、Gemini アプリにテーマと構成案を伝え、草案を作成させることがあります。生成された内容を基に、エンジニアが専門的な知見や G-gen としての視点を加えて、記事を仕上げます。 前述の「ブログ下書きレビュー Gem」と同様に、体裁ルールや模範的な記事原稿をプロンプトに入れることで、精度が高い生成が可能です。なお模範的な記事をプロンプトに組み入れることは、一種の Few-shot prompting（プロンプトに少数の例を含めることで、精度を向上させるプロンプトエンジニアリング手法）といえます。 参考 : 少数ショットの例を含める レビュー・アイデア出し 作成した文章やソースコード、設計案などを Gemini に提示し、改善点や別のアイデアがないか、壁打ち相手として利用します。客観的な視点からのフィードバックを得ることで、品質向上につなげます。 ソースコード生成 Python、Bash、SQL、Terraform などのソースコードを、自然言語の指示に基づいて Gemini が生成します。特定の作業で一時的に必要になる gcloud コマンドラインなども、生成させてすぐ利用することが可能です。 また Gemini アプリの Canvas 機能を使うと、生成 AI と対話しながら生成物を修正したり、JavaScript のソースコードの実行をブラウザ上でプレビューすることができます。Canvas の詳細は、Gemini の公式 note アカウントの以下の記事を参照してください。 参考 : Gemini の新機能 「Canvas」入門： アイデアをカタチにする活用法をわかりやすく徹底解説！ - Gemini - Google の AI Canvas でウェブアプリを開発 Deep Research による調査レポート Gemini アプリの Deep Research は、複雑なトピックを掘り下げて理解することを支援する強力な機能です。Gemini がユーザーに代わって数十のウェブサイトを検索して、その内容を AI が分析し、長大なレポートを作成します。 Deep Research は、市場調査、顧客の現状調査、競合調査、技術情報の調査などに利用できます。 最近のアップデートでは、 インフォグラフィック の生成などが可能になりました。指示したトピックに関する図表を含む HTML が生成され、多くのデータや複雑な概念を視覚的に分かりやすく提示することできます。 Gemini の Deep Research で作成したインフォグラフィック NotebookLM NotebookLM とは NotebookLM は、アップロードしたドキュメントに基づいて質問応答や要約、アイデア生成ができる AI ノートブックです。G-gen では、個人のナレッジ整理や情報収集に利用されています。 参考 : NotebookLM NotebookLM Google Workspace のほとんどのエディションには、無償版の NotebookLM と比較して各種制限が緩和されたり、組織的な機能が追加された NotebookLM in Pro が付帯しています。 参考 : NotebookLM Plusを使ってみた - G-gen Tech Blog 個人ドキュメントの整理・要約 複数のドキュメントや Web サイト、PDF 資料などを NotebookLM にアップロードし、特定のテーマに関する情報を横断的に検索したり、全体像を要約させたりします。これにより、散在していた知識を効率的に整理できます。 NotebookLM を使うと情報ソースを固定化して生成を行うことができるため、ハルシネーション（AI が事実と異なる内容を生成すること）も低減できます。 また マインドマップ 機能を使うと、ドキュメントがマインドマップ形式で整理されます。議事録や技術ドキュメントを構造化して理解するのに役立ちます。 NotebookLM のマインドマップ ポッドキャスト風音声の生成 NotebookLM では、日本語でポッドキャスト風音声を生成させることができます。アップロードしたデータソースについて、2人の話者がラジオやポッドキャストで対談しているような音声を、数分で生成できます。 「高校生でもわかりやすいように解説」などの指示を与えることで、語彙や論調をコントロールし、例えば英語の論文をアップロードして解説させることで、内容の把握に役立ちます。 参考 : 音声概要 - NotebookLM ヘルプ FAQ 作成 特定の製品マニュアルや社内規定などをアップロードし、それに関する想定問答集（FAQ）を生成させるといった利用方法もあります。 Google Meet Google Meet と Gemini Google Meet は、オンラインでのビデオ会議やウェビナー開催に利用されるツールです。 Google Meet において Gemini は、自動的な議事録作成や、Web 会議体験の向上に役立ちます。また、バーチャル背景の生成や、カメラ映像の画質向上、同じ部屋から複数人が Meet に参加しているときのハウリング防止など、ウェブ会議の質を向上させるための複数の AI 機能が利用可能です。 参考 : Google Meet の「自動メモ生成」 参考 : Enhance your video & audio with Gemini in Google Meet 参考 : Meet でアダプティブ オーディオを使用する 参考 : Create background images with Gemini in Google Meet 発言内容の文字起こし Google Meet では、日本語で行われた会議を文字起こしすることができます。 文字起こしした内容は Google ドキュメントに書き出されます。そのままだと、いわゆるフィラー（「えーと」「あのー」など）も文字起こしされてしまいますが、この内容を先述の Gemini アプリの Gems などで整形することで、体裁を保った議事録を簡単に作成することができます。 参考 : Geminiアプリのカスタマイズ機能「Gems」を徹底解説 - G-gen Tech Blog - カスタム Gem の例 会議の要約とアクションアイテム抽出 Gemini は会議の会話内容を分析し、要約を自動生成したり、決定事項や担当者などのアクションアイテムを抽出したりできます。これにより、会議に参加できなかったメンバーが内容を素早く把握したり、議事録作成の手間を削減したりするのに役立ちます。 Google ドキュメント Google ドキュメントと Gemini Google ドキュメント は、議事録、企画案、メモ、ブログ記事の下書きなど、G-gen の業務における中心的なドキュメント作成ツールです。 Google ドキュメントにおいて、Gemini はドキュメント作成の様々なフェーズで利用されています。 参考 : Gemini in Google ドキュメントを活用する 文章の生成・修正 画面右側の Gemini サイドパネル を利用して、文章のアイデア出し、構成案の作成、表現の洗練などを行います。このサイドパネルは、ドキュメントを開いたまま Gemini の機能（要約、ブレインストーミング、文章作成支援など）を呼び出せるインターフェースです。 例えば、新しいサービスの概要説明文を作成する際に、箇条書きで要点を入力して Gemini に指示するだけで、自然な文章を生成させることができます。 Gemini サイドパネル また、既存の文章を選択し、「より簡潔に」「より詳細に」「より丁寧に」といった指示を与えることで、文章のトーンを調整することも可能です。ドキュメント上で該当のテキストをマウスで選択し、表示される鉛筆マークをクリックして表示されるメニューから、修正方法を選択します。 Gemini による文章の校正 修正後の文言に対してさらに指示を与えて好みの文章に整えた後、またドキュメントに挿入できます。 ドキュメントの要約 長文のドキュメントを読む時間を短縮するため、Gemini サイドパネルの 要約 （概要生成）機能が利用されています。特に、他のメンバーが作成したドキュメントの内容を素早く把握したい場合や、過去の議事録から重要な決定事項を確認したい場合に有効です。 Gemini によるドキュメントの概要説明 長大な 英語の契約書や利用規約 などを 日本語で要約 させることも可能です。テキスト形式であれば、PDF も対象にできます。 英語の規約や契約書を日本語で要約 Gmail Gmail と Gemini Gmail は、Google Workspace に組み込まれたメール機能です。G-gen では、顧客やパートナーとの主要なコミュニケーション手段として利用されています。ここでも、Gemini はメール作成の効率化と品質向上に貢献しています。 参考 : Gemini in Gmail を活用する メールの下書き作成 メール作成画面で Gemini アイコンをクリックして Gemini サイドパネルを開き、簡単な指示（例：「〇〇社 △△様へ、□□の件に関する打ち合わせのお礼と、決定事項の確認メールを作成」）を与えるだけで、メールの草案を生成できます。これにより、定型的なメール作成にかかる時間を大幅に削減できます。 文章の推敲 作成したメール本文を選択し、Gemini に表現の改善や誤字脱字のチェックを依頼します。特に、重要な顧客へのメール送信前には、より丁寧で正確な表現にするために Gemini を利用する場面が多く見られます。 予定の作成 先方からのメールに書いてあるミーティング予定の日付を抽出して、Google カレンダーの予定を作成することができます。 Gmail からカレンダーを作成 和英・英和翻訳 海外の相手とメールのやりとりをする際、英語を日本語に、あるいは自分の書いた日本語を英語に翻訳することができます。英語のネイティブ話者から読んでも失礼にならず、自然な英語になるように推敲させることも可能です。 Gmail における和英・英和翻訳 Google スライド Google スライドと Gemini Google スライド は、プレゼンテーション資料作成に利用されます。Google スライドにおいて Gemini は、コンテンツ作成の補助や、画像など視覚要素の生成に役立ちます。 画像生成 Gemini の画像生成機能を利用して、スライドに適したオリジナルの画像を生成します。例えば、LT（ライトニングトーク）のタイトルスライドや、特定のコンセプトを視覚的に表現したい場合に、「〇〇をイメージした抽象的な背景画像」「△△をしているキャラクター」といった指示で画像を生成し、資料の品質を高めます。 画像の生成 テキストコンテンツの草案作成 スライドの各ページで伝えたい内容の要点を Gemini に指示し、説明文や箇条書きの草案を作成させます。これにより、資料作成の初期段階での時間短縮につながります。 Google ドキュメントなどと同じように、箇条書きの要点を伝えるだけでスライドの文章を生成させたり、元となる Google ドキュメントを指定することで、文章を作成させることもできます。 参考 : Gemini in Google スライドを活用する スピーカーノートの作成 スピーカーノート（トークスクリプト。話すときの台本）の生成にも、Gemini が利用できます。Google スライドの Gemini サイドパネルに生成させることもできますし、Gemini アプリで Google スライドを指定して、ノートを作成させることもできます。 スピーカーノートを Gemini アプリに生成させる Google スプレッドシート Google スプレッドシートと Gemini Google スプレッドシート は、表計算やデータ管理に広く利用されるツールです。G-gen では、見積もりの作成、WBS、社員名簿など、さまざまな情報の整理にスプレッドシートを使っています。 Google スプレッドシートにおいて Gemini は、表の構成案作成、テンプレート生成、データ整理のアイデア出しなどを通じて、作業の効率化を支援します。 参考 : Gemini in Google スプレッドシートを活用する テンプレートの作成や関数の生成 Gemini に目的を伝えることで、特定の用途に合わせたスプレッドシートのテンプレートを作成させることができます。例えば、「プロジェクト計画用のガントチャート」「イベントの予算管理表」といった指示で、基本的な表の構造や項目を含んだテンプレートを生成し、シート作成の手間を省きます。 また、Gemini サイドパネルで、自然言語の指示に基づいて関数を生成できます。Gemini サイドパネルを使えば、複雑な関数も容易に生成可能です。 データ整理と分析のアイデア出し 既存のデータやこれから扱いたいデータについて、どのように整理・分析すればよいか Gemini に相談できます。「この売上データをどのように分析すれば傾向が掴めるか？」「顧客リストをセグメント分けするアイデアは？」といった質問を通じて、データ活用のヒントを得ることができます。 また、表の近くに「このデータを分析」ボタンが表示され、クリックするだけでデータから得られる示唆を生成したり、チャート（図表）を生成したりできます。 「このデータを分析」ボタン 出力された分析結果 Gemini Code Assist Gemini Code Assist とは Gemini Code Assist は、コーディングを補助したり、自然言語による対話に基づいてソースコードを生成したりするソリューションです。開発業務においては、Gemini Code Assist がコーディングの高速化と品質向上に貢献しています。 参考 : Gemini Code Assist Standard and Enterprise 参考 : Gemini Code Assistを使ってChromebookで開発環境を整えてみた - G-gen Tech Blog Gemini Code Assist には無償版が存在するほか、有償版は、Google Cloud の請求先アカウントに紐づける形で、Google Cloud コンソールから 簡単にライセンスを購入 できます。オフラインオーダー（書面での申し込み等）は不要です。料金は、Google Cloud 料金と一緒に請求されます。 コード生成・補完 IDE（統合開発環境）内で、コメントや既存コードに基づいて、必要なコードスニペットを生成・補完させます。定型的なコードや、あまり慣れていない言語・ライブラリを使用する際の開発効率が大幅に向上します。 コメントでプロンプトを与えてコードを生成 コードの説明・レビュー 既存のコードブロックを選択し、その処理内容を自然言語で説明させたり、潜在的なバグや改善点を指摘させたりします。コードレビューの補助や、他者が作成したコードの理解促進に役立ちます。 チャットで Gemini に指示を与えてコードを説明 コードレポジトリとの連携 Gemini Code Assist と GitHub、GitLab などのレポジトリを連携させることで、既存のソースコード群を踏まえたコーディングスタイルや、独自ライブラリ、非公開 API などを踏まえたコード生成が可能です。 参考 : Gemini Code Assist のコード カスタマイズを構成する Generative AI on Vertex AI Vertex AI と Gemini ここまで紹介したのは、Google が提供する AI ソリューションの活用事例でした。これらのソリューションには Gemini が組み込まれており、ユーザーは開発を一切行うことなく、AI サービスを利用できます。 しかし、Google Cloud の AI 開発プラットフォームである Vertex AI を使うと、Gemini を API 経由で呼び出して、ユーザー独自のアプリを開発することもできます。 参考 : Overview of Generative AI on Vertex AI 参考 : Gemini カテゴリーの記事 - G-gen Tech Blog 議事録作成を効率化 以下の記事では、G-gen のエンジニアが独自のチャットボットを開発し、Google Meet の自動文字起こし機能と組み合わせて、議事録作成を効率化した事例が紹介されています。 blog.g-gen.co.jp 同様の機能は Gemini アプリでも実現できますが、独自アプリを開発し、API 経由で Google の AI モデルを利用することで、音声の読み上げなど追加の機能を実装しています。 技術サポート窓口やブログ記事のナレッジ活用 G-gen では、Google Cloud・Google Workspace 請求代行サービスに付帯して、無償の技術サポート窓口を提供しています。また、エンジニアは案件で得た知見を G-gen Tech Blog の記事として一般に公開しています。 エンジニアが技術的な問題に直面したり、営業担当者が顧客から質問を受けた時は、過去に対応したサポートケースやブログ記事の検索を行いますが、文字列一致では検索にコツが必要でした。 これを解消するため、G-gen では社内検索システム「G-gen Tech Search」を開発しました。Gemini を使って過去のサポートケースやブログ記事を構造化し、BigQuery テーブルに格納します。さらに、AI Applications（旧称 Vertex AI Agent Builder）の1機能である Vertex AI Search を使い、簡易的な検索 UI を作成することで、文字列一致の検索ではなく、セマンティック検索（意味論検索）で過去のナレッジにアクセスできるようにしました。 社内向け検索ツール 社内向け検索ツールのアーキテクチャ Slack チャットボット 社内で日常のコミュニケーションに利用しているチャットツール Slack から、bot を呼び出して前述の G-gen Tech Search での検索ができるようにしました。Slack で質問を投げると、bot が過去ケースやブログ記事を検索し、要約した回答と関連リンクを返答します。 Slack bot 経由での利用 また、過去ケースや記事検索に留まらないより汎用的な AI ボットとして、キャラクター性を持たせた Slack bot に気軽に相談できるようにもなっています。過去情報に基づいた一問一答的な質問は G-gen Tech Search bot に投げ、それに留まらないより一般的な質問はキャラクター bot に、という使い分けです。G-gen Tech Search bot のバックエンドは Vertex AI Search、キャラクター bot のバックエンドは Gemini API となっています。 キャラクター性を持たせた bot 最新技術アップデートの要約 Google Cloud では、毎日のように機能アップデートが公開されています。アップデート情報はリリースノートページで公開されているほか、BigQuery のパブリックデータセット（誰でもアクセス可能なデータセット）として構造化データ化されて公開されています。 参考 : Google Cloud release notes G-gen は Google Cloud 専業のインテグレーターとして、これらの情報にいち早くキャッチアップする必要があります。 G-gen では、アップデート情報が公開されたらすぐ生成 AI によりこれらの情報を要約させ、Slack に投稿されるようになっています。また G-gen Tech Blog の関連記事もセマンティック検索でリストアップされます。これにより、過去の記事をできるだけ最新化することに役立ちます。 Slack にアップデートの要約情報や関連記事が自動投稿される この仕組みは、バックエンドに Cloud Run（フルマネージドのコンテナサービス）を使っており、Cloud Run 上のプログラムから Vertex AI 経由で Gemini API を呼び出したり、Vertex AI Search を呼び出したりすることで実現されています。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。当記事では、Google Cloud のセキュリティサービスである Security Command Center の機能の1つ、Event Threat Detection の カスタムモジュール について解説します。また、あわせてミュートルールの作成方法についても触れます。 概要 Event Threat Detection とは カスタムモジュールとは 料金 カスタムモジュールの定義 テンプレート モジュールのレベル カスタムモジュールの実装 特定の API 呼び出しの検知 モジュールの定義 動作確認 検知事項の詳細 ミュートルールの作成 ミュートすべき検知事項 フォルダの CreateProject 検知の抑止 概要 Event Threat Detection とは Event Threat Detection は、Google Cloud の Cloud Logging に記録されるログを分析し、脅威を検出するサービスです。Event Threat Detection は Security Command Center の プレミアムティア および エンタープライズティア で利用可能な機能です。 参考 : Security Command Centerを徹底解説。Google Cloud(GCP)の脆弱性を自動検知 - G-gen Tech Blog - Event Threat Detection 参考 : Event Threat Detection の概要 Event Threat Detection は、マルウェア、クリプトマイニング、不正な権限昇格、データ抜き取りの試みなど、さまざまな脅威を検出するための 組み込みモジュール （プリセットの検知事項）を提供しています。これらのモジュールは Google の脅威インテリジェンスに基づいて継続的に更新されます。 カスタムモジュールとは 全ての組織のセキュリティ要件が組み込みモジュールだけで満たされるわけではありません。組織固有のポリシーや、特殊な利用パターンに対する脅威を検出したい場合、標準の脅威検出ルールでは不十分な場合があります。 そこで役立つのが、Event Threat Detection の カスタムモジュール 機能です。カスタムモジュール（Custom modules）は、ユーザーが独自の脅威検出ロジックを定義し、Event Threat Detection に組み込むことができる機能です。 これにより、組織固有のセキュリティポリシー違反や、組み込みモジュールでカバーしきれないニッチな脅威シナリオに対応できます。カスタムモジュールは、Cloud Logging に集約されるさまざまなログソース、例として Cloud Audit Logs（監査ログ）、Cloud DNS ログ、VPC フローログなどを分析対象とすることができます。 参考 : Event Threat Detection 用カスタム モジュールの概要 カスタムモジュールを作成することで、以下のようなメリットがあります。 組織固有の脅威やコンプライアンス違反を検出できる 検知事項は Security Command Center と統合される カスタムモジュールを使用しなくても、Cloud Logging のログアラート機能を用いることで、特定の監査ログが出力された際にメールや Slack 等へ発報することができます。しかし、カスタムモジュールを使うと、検知事項は Event Threat Detection の検知事項としてリストアップされるため、他の脆弱性や脅威と共通の管理ができます。無効化やミュート、ミュートルールなどを用いたり、Pub/Sub 経由で SIEM へ所定のフォーマットで通知するなどの設定が可能なため、セキュリティ運用を統一化できます。 参考 : Security Command Centerを徹底解説。Google Cloud(GCP)の脆弱性を自動検知 - G-gen Tech Blog - 運用 料金 Event Threat Detection のカスタムモジュール機能の利用は、Security Command Center プレミアムティアやエンタープライズティアの料金に含まれており、 追加料金はありません 。 参考 : Security Command Center の料金 カスタムモジュールの定義 テンプレート Event Threat Detection カスタムモジュールは、Security Command Center のコンソール画面、もしくは gcloud コマンドと JSON 形式の定義ファイルを使って定義します。 テンプレートが Google によってあらかじめ用意されており、これらを編集してカスタムモジュールを作成します。以下は、用意されているテンプレートの例です。 テンプレート名 説明 予期しない Cloud API 呼び出し 指定したメソッド、プリンシパル、リソースで API リクエストが行われたら検知 想定外のロールの付与 指定されたロールがユーザーに付与されたら検知 禁止されている権限があるカスタムロール 指定された IAM 権限を含むカスタムロールが作成または更新されたら検知 ブレークグラス アカウントの使用 指定したブレークグラスアカウント（緊急アクセス用アカウント）が使用されたら検知。 想定外の Compute Engine インスタンス タイプ 指定していないインスタンスタイプや CPU、GPU、RAM 構成の VM が起動されたら検知 構成可能な不正ドメイン 指定されたドメイン名への接続を検知 構成可能な不正 IP 指定された IP アドレスへの接続を検知 参考 : Event Threat Detection 用カスタム モジュールの概要 ‐ カスタム モジュールとテンプレート モジュールのレベル Event Threat Detection カスタムモジュールは、組織、フォルダ、またはプロジェクトのレベルで作成できます。 親リソースで作成したモジュールは、子リソースへ継承されます。組織全体で検知を有効化したい場合は、組織の最上位ノードでカスタムモジュールを作成します。 カスタムモジュールの実装 特定の API 呼び出しの検知 当記事では、例としてテンプレート「 予期しない Cloud API 呼び出し 」を使った実装を紹介します。組織内にプロジェクトが作成された場合に、検知されるようにします。会社や組織によっては、情報システム部や CCoE にあたる部署が Google Cloud プロジェクトの払い出しを統合管理しており、ユーザーが独自にプロジェクトを作成することを禁止していますが、ユーザーが意図せずプロジェクト作成権限を持ってしまい、このルールに違反したような場合に検知することを想定しています。 当記事では、テンプレート「予期しない Cloud API 呼び出し」を使い、メソッド CreateProject を検知することで実現します。なお当記事では設定しませんが、同様の方法でメソッド名を DeleteProject とすることで、プロジェクトが削除された場合の検知も設定できます。 モジュールの定義 当記事では、Google Cloud コンソールを用いてモジュールを定義します。当記事に掲載されているスクリーンショットは、Security Command Center のエンタープライズティアのものです。プレミアムティアでは画面の体裁が異なる場合がありますので、ご注意ください。 まず、Google Cloud コンソールにログインし、Security Command Center 画面へ遷移します。操作する Google アカウントには、モジュールを作成する組織・フォルダまたはプロジェクトのレベルでセキュリティセンター管理者（ roles/securitycenter.admin ）ロールなどが必要です。 画面左上部のプロジェクトセレクタで、モジュールを作りたいリソース（組織、フォルダ、プロジェクト）が選択されていることを確認したら、左部ペインの「設定」ブロックにある「SCC の設定」をクリックします。 「SCC の設定」をクリック 「Event Threat Detection」のカードの中の「設定を管理」をクリックします。 「Event Threat Detection」の「設定を管理」をクリック 「モジュール」タブをクリックします。この画面では、規定の組み込みモジュールのほか、カスタムモジュールが一覧表示されています。「モジュールを作成」をクリックします。 「モジュールを作成」をクリック テンプレートを選択します。今回は「API 呼び出し」をクリックし、表示された「選択」ボタンをクリックします。 「API 呼び出し」の「選択」ボタンをクリック 次の画面で、モジュールの設定を定義します。 モジュール設定（1） モジュール名は、検知一覧で検出カテゴリとして表示されます。先頭は英小文字である必要があり、記号はアンダースコアのみが使用できます。検知事項一覧では、アンダースコアがスペースに置き換わり、google_cloud といった単語は Google Cloud と表示されます。モジュール名を例のように google_cloud_project_created とすると、検知一覧では Unexpected cloud API call: Google Cloud project created と表記されます。 「プリンシパルに関するアラート」では、どのプリンシパルによって行われた API リクエストを検知するかを定義します。定義は、RE2 正規表現で記述します。正規表現に慣れていない方は、Gemini アプリ（ https://gemini.google.com/ ）などを利用してもよいでしょう。ここでは、 .* として、すべてのプリンシパルによるプロジェクト作成を検知します。 「メソッドに関するアラート」では、検知対象の API メソッドを定義します。ここでは CreateProject を指定します。 「リソースに関するアラート」では、検知対象のリソースを定義します。ここでは正規表現で .* として、プロジェクトがどのような ID で作成されても検知されるようにします。 「次へ」を押下して、次の設定に移ります。 モジュール設定（2） 「重大度」「説明」「次のステップ」を定義します。 重大度は、検知事項のフィルタリングなどに用いる重大度の設定です。「説明」「次のステップ」は、検知事項の詳細画面に表示されます。セキュリティ運用者が適切な対処を取れるよう、わかりやすい説明や対処方法を入力しておきます。 動作確認 プロジェクトを実際に作成して、検知されるかどうかを確認します。組織に detect-me-0001 という ID のプロジェクトを作成しました。作成後、Security Command Center コンソール画面の「検出結果」画面へ遷移します。 カスタムモジュールによる検知事項だけを表示するには、「検出結果」画面の左下部分のフィルタで、「ソースの表示名」ブロックのフィルタで「Event Threat Detection Custom Modules」だけにチェックマークを入れます。ソース名が省略されている場合は、マウスオーバーすることで確認できます。 「Event Threat Detection Custom Modules」にチェック なお、以下のスクリーンショットのように検知事項の一覧表のカラム名部分が縦に引き伸ばされてしまい表が見づらい場合、「Affected runtime resources > Count」「Attack exposure > Score」「有害な組み合わせ > 有害な組み合わせスコア」などのチェックを外せば、カラムが省略され、テーブルが正しく見えるようになります（2025年5月現在、エンタープライズティア）。 表の見出し（カラム名）のエリアを小さくする 今回は、以下の4つの検知事項が確認されました。リソースの表示名が「detect-me-0001」となっているのが、今回検知したかったプロジェクトです。 検知事項 検知事項の詳細 検知された項目名をクリックすると、詳細が表示されます。カスタムモジュールで定義された重大度、説明、次のステップなどが表示されています。 検知事項の詳細 また、JSON タブを選択すると、検知事項の詳細を JSON 形式で確認できます。この中に含まれている sourceProperties.properties という要素には、カスタムモジュールにより検査される値が含まれています。この値が正規表現に当てはまると、検知が行われます。 sourceProperties.properties ミュートルールの作成 ミュートすべき検知事項 先の検証結果では、目的のプロジェクト以外にも3つの検知が行われていました。リソースの表示名が「sugimura_fld」となっているのは、新規作成した「detect-me-0001」プロジェクトを格納するフォルダ名です。 これは、プロジェクトの作成操作を行って CreateProject メソッドが実行される際、「プロジェクト ID をリソース名とする監査ログ」と「フォルダ ID をリソース名とする監査ログ」の2つが必ず出力されてしまう仕様に起因します。1つのプロジェクトの作成に対して2つのログが出力されてしまうため、検知事項も2つ生成されてしまいます。このとき、後者のログはノイズとなり得ますので、抑止することが望ましいです。 また、リソースの表示名が「sys-82688xxx」「apps-script」となっている検知事項は、Google Apps Script（GAS）スクリプトを作成した際に自動作成されるプロジェクト、およびそれを格納するフォルダの検知です。検証の前後で、組織内の誰かが GAS スクリプトを作成したために検知されたものです。これらのプロジェクトの作成時も、先と同じ理由で2つの検知事項が生成されてしまいます。これらの GAS による自動作成プロジェクトの検知も、ノイズとなり得ます。 これらのノイズを抑止するため、 ミュートルール を利用することができます。ミュートルールを作成することで、所定のルールに基づいて、自動的に検知事項をミュートできます。 フォルダの CreateProject 検知の抑止 検知事項の詳細画面を開き、「ミュートオプション」メニューから「これに類似する検出結果をミュート」を選択します。 「これに類似する検出結果をミュート」 ミュートルール ID を命名し、説明を追加します。重要なのは、 検出クエリ です。ミュート対象とする検知結果の条件を Cloud Logging クエリ言語で記述することができるほか、「フィルタを追加」ボタンから GUI で選択できます。 GUI でフィルタルールを定義 今回は、検知結果のリソースタイプがフォルダである場合に検知結果をミュートするよう定義します。検出クエリは以下のようになります。 category= " Unexpected Cloud API Call: google_cloud_project_created " AND resource . type = " google.cloud.resourcemanager.Folder " また、別のミュートルールを新規作成し、GAS による自動作成プロジェクトも検知対象外とします。GAS のプロジェクトは、Google の管理するサービスアカウント appsdev-apps-dev-script-auth@system.gserviceaccount.com によって作成されるため、このサービスアカウントによって作成された場合はミュート対象とします。なお、先ほどと同じミュートルールの中に、以下の access.principal_email 条件を OR でつなげて記載しても構いません。 category= " Unexpected Cloud API Call: google_cloud_project_created " AND access .principal_email= " appsdev-apps-dev-script-auth@system.gserviceaccount.com " 動作確認のため、プロジェクト「detect-me-0002」を作成します。以下のように、新たに検知されたリソース表示名がフォルダの検知事項は表示されなくなりました。なおフィルタでミュートステータスが MUTED のものを表示させることで、ミュート済みの検知事項を再表示することができます。 新しく表示された検知事項は1つのみ ミュートルール作成前に検知された検知事項は新たにルールを作ってもミュートされないため、手動でミュートします。検知事項を選択し、「ミュートのオーバーライドを適用」をクリックすることで、検知事項を手動でミュートできます。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。2025年5月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Vertex AI Search が値下げ Gemini 1.5 Pro/Flash の廃止日に注意 Gemini API（Vertex AI）でグローバルエンドポイントが利用可能に Gemini API（Vertex AI）で Elasticsearch を使ったグラウンディング Cloud Composer 1（Airflow 2）から Composer 3 への移行が可能に Cloud CDN でキャッシュタグによるキャッシュ無効化が Preview→GA Google Vids で Veo 2 を使った動画生成が可能に Gemini アプリで音声概要が日本語対応 SCC の Compute Engine 関連検知事項ダッシュボード（Preview） BigQueryの実行グラフ画面にクエリが表示（Preview） Googleスプレッドシートで Gemini を使った様々な操作が可能に BigQuery で GROUP BY ALL、GROUP BY STRUCT、GROUP BY ARRAY BigQuery universal catalog でメタデータのバルクエクスポート Snowflake から BigQuery へのデータ転送（Preview） BigQuery でリージョンをまたいだデータの LOAD や EXPORT AppSheet で Gemini in AppSheet Solutions が公開 IAM ロールと権限（permission）のリファレンスドキュメントが刷新 BigQuery で「継続的クエリ」が Preview → GA Vertex AI API 経由での Gemini に新機能が多数追加 Gemini アプリの Canvas 機能がアップデート Microsoft SharePoint Online からの移行ツールが Open Beta Gemini Code Assist のバックエンドモデルが Gemini 2.5 に 組織のポリシーのカスタム制約が BigQuery で利用可能に BigQuery の Optional job creation mode が GA Gemini Code Assist に Context Drawer が登場 Google ドライブで Gemini による動画の要約が可能に AlloyDB インスタンスが停止・起動可能に Cloud Storage とBigQuery 間の Event-Driven Transfers が利用可能に（GA） Google スライドで「画像の背景削除」が日本語版にも対応 Associate Cloud Engineer の資格対策書籍が出版 はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Vertex AI Search が値下げ AI Applications pricing (2025-05-01) Vertex AI Search が2025年5月1日から値下げ。 無料利用枠の導入 請求先アカウントごとに毎月10,000クエリまでが無料に Standard Edition の値下げ 料金が 1,000 クエリあたり $2 から $1.50 に引き下げ Enterprise Edition への Core Generative Answers（AI モード）搭載 追加費用なしで、検索結果に加えて AI 生成による回答とフォローアップを利用可能に LLM アドオンの機能強化と価格設定 従来、LLM アドオンは $4/1000 クエリの「基本」と $10/1000クエリの「Advanced」があった。従来は Advanced 版にのみ含まれていたフォローアップの提案、複雑なクエリ処理、マルチモーダル機能などの高度な機能が、基本版で利用可能に。基本版の料金に変更はなし。Advanced 版は廃止。 Gemini 1.5 Pro/Flash の廃止日に注意 Model versions and lifecycle (2025-05-01) Gemini 1.5 Pro/Flash の廃止日に注意。廃止されたモデルへの API リクエストは 404 になる。 「*-001」等は 2025年5月24日に廃止 gemini-1.5-pro-001 gemini-1.5-flash-001 textembedding-gecko@003 textembedding-gecko-multilingual@001 「*-002」は 2025年9月24日に廃止 gemini-1.5-pro-002 gemini-1.5-flash-002 新規プロジェクトや過去に利用がないプロジェクトでは既に使用不可になっている。 Gemini API（Vertex AI）でグローバルエンドポイントが利用可能に Global endpoint (2025-05-02) Gemini API（on Vertex AI）でグローバルエンドポイントが利用可能に（GA）。 自動的に空いているリージョンの API を使ってくれるので、Google 側のリソース枯渇を示す resource exhausted（429）のリスクを減らせる。ただしバッチ推論やコンテキストキャッシングなど一部の機能は利用不可。また、データの所在地に関連する規制要件等にも注意が必要。 Gemini API（Vertex AI）で Elasticsearch を使ったグラウンディング Grounding with Elasticsearch (2025-05-05) Gemini API（on Vertex AI）で Elasticsearch を使ったグラウンディングが可能に（GA）。Google 検索や Vertex AI Search データソースへのグラウンディングとも併用可能。 なお同時に Vertex AI Search データソースへのグラウンディングも Preview → GA された。 Cloud Composer 1（Airflow 2）から Composer 3 への移行が可能に Migrate to Cloud Composer 3 from Cloud Composer 1 (Airflow 2) (2025-05-05) Cloud Composer 1（Airflow 2）から Composer 3 へ、スナップショットを使って移行できるように。まずは限定したリージョンで対応、のちに全リージョンへロールアウトされる。 Cloud CDN でキャッシュタグによるキャッシュ無効化が Preview→GA Invalidation by cache tags (2025-05-05) Cloud CDN でキャッシュタグによるキャッシュの無効化（Invalidation）が Preview→GA。 レスポンスの Cache-Tag の値に応じて、狙い撃ちしてキャッシュを invalidation できる。 Google Vids で Veo 2 を使った動画生成が可能に Generate custom video clips in Google Vids with Veo 2 (2025-05-06) Google Vids で、Veo 2 による AI 動画生成が可能に。AI が8秒間の動画クリップを生成。追加費用なしで利用できる。ただし、1日に20回までの上限あり。 Google Vids とは、Google Workspace に付帯の動画編集ツール。Veo 2 とは、Google の動画生成 AI モデル。 Gemini アプリで音声概要が日本語対応 Google Workspace Updates Weekly Recap - May 9, 2025 (2025-05-09) Geminiアプリで、ドキュメントやスライド、生成した Deep Research レポートなどに対して NotebookLM と同じような音声概要（ポッドキャスト風音声）を生成できる機能が、日本語にも対応予定。これまでは英語のみだった。 SCC の Compute Engine 関連検知事項ダッシュボード（Preview） Monitor security risks with Security Command Center (2025-05-09) Google Cloud コンソールで、Security Command Center の Compute Engine に関わる検知事項を表示するダッシュボードが登場（Preview）。Compute Engine 画面から遷移できる。 BigQueryの実行グラフ画面にクエリが表示（Preview） Monitor security risks with Security Command Center (2025-05-09) BigQuery の実行グラフ画面に、クエリが表示されるように。ステップに関連する箇所がハイライト表示され、詳細も付記される。クエリチューニング時の深い理解に役立つ。 Googleスプレッドシートで Gemini を使った様々な操作が可能に Use Gemini in Google Sheets to quickly add dropdowns, pivot tables, filters, and more (2025-05-13) Googleスプレッドシートで Gemini を使い「ドロップダウン」「条件付き書式」「ピボットテーブル」「フィルタリング」「並べ替え」などの編集ができるようになる。 操作手順を知らなくても自然言語の指示で編集が可能に。 BigQuery で GROUP BY ALL、GROUP BY STRUCT、GROUP BY ARRAY BigQuery release notes - May 13, 2025 (2025-05-13) BigQuery で GROUP BY ALL、GROUP BY STRUCT、GROUP BY ARRAY が使えるように。SQL の簡素化に繋がる。 BigQuery universal catalog でメタデータのバルクエクスポート Export metadata (2025-05-13) BigQuery universal catalog（旧 Dataplex Catalog）でメタデータのバルクエクスポート（Cloud Storage へ）が可能に。 BigQuery のメタデータをエクスポートして、サードパーティで利用・処理・分析したり、プログラマブルに処理したりできる。 Snowflake から BigQuery へのデータ転送（Preview） Schedule a Snowflake transfer (2025-05-14) BigQuery Data Transfer Service で Snowflake から BigQuery へのデータ転送が Preview 公開。 Snowflake の AWS ホスト版のみ対応。マネージドな仕組みで自動・定期的な転送が可能。 Amazon S3 バケットを経由するため AWS アカウントと IAM User Credentials が必要。 BigQuery でリージョンをまたいだデータの LOAD や EXPORT BigQuery release notes - May 14, 2025 (2025-05-14) BigQuery でリージョンをまたいだデータの LOAD や EXPORT（to Cloud Storage、Pub/Sub等）が可能に。 bq load、LOAD DATA、bq extract、EXPORT DATA などで可能。リージョン間データ転送料金に注意。 AppSheet で Gemini in AppSheet Solutions が公開 Extract and categorize data in AppSheet with the power of Gemini (2025-05-14) ノーコード開発ツール AppSheet で Gemini in AppSheet Solutions が公開。以下のような、AI を使ったアプリ開発が可能になる。 写真から文字の抽出 PDF の解析 情報の分類 ...など Enterprise Plus エディションで利用可能。 IAM ロールと権限（permission）のリファレンスドキュメントが刷新 IAM roles and permissions index (2025-05-15) Google Cloud の IAM ロールと権限（permission）のリファレンスドキュメントが刷新され、見やすく＆読み込みが高速に。 ロールと権限のリファレンスが統一され、どちらでも検索できる。かつサービスごとのページに再構成された。IAM 権限を運用する人や、開発・構築時に権限を調べるときに、かなり楽になった。 BigQuery で「継続的クエリ」が Preview → GA Introduction to continuous queries (2025-05-19) BigQuery で「継続的クエリ」が Preview → GA。 テーブルに追加されたレコードに対して数秒〜数十秒の遅延でニアリアルタイムに SQL による加工ができる。BigQuery ML で AI による推論も可能。以下の記事も参照。 blog.g-gen.co.jp Vertex AI API 経由での Gemini に新機能が多数追加 Vertex AI release notes ‐ May 20, 2025 (2025-05-20) Google I/O（5/20〜21）で、Gemini に関する対数の発表あり。 Gemini 2.5 Flash の Live API（リアルタイムで音声インプット・アウトプット） Gemini 2.5 Pro の Deep Think（強化推論モード。複雑な数学やコーディング） Thought summaries（思考経緯をサマリ） 新モデル Veo 3・Imagen 4・Lyria 2（それぞれ動画、画像、音楽生成） 新バージョン gemini-2.5-flash-preview-5-20 Gemini アプリの Canvas 機能がアップデート More ways to create with Canvas (2025-05-20) Personalize learning with Quizzes, available through Canvas in the Gemini app (2025-05-20) Gemini アプリの Canvas で追加の機能が登場。 Web ページ作成 インフォグラフィックス クイズの作成 音声概要 Microsoft SharePoint Online からの移行ツールが Open Beta Available in Open Beta: Migrate files from Microsoft SharePoint Online to Google Drive (2025-05-21) Google Workspace で Microsoft SharePoint Online から Google ドライブへの移行ツールが Open Beta 公開。 ドキュメントライブラリ、フォルダ、ファイル、権限などを移行できる。追加・更新されたファイルの差分転送も可能。 Gemini Code Assist のバックエンドモデルが Gemini 2.5 に Gemini Code Assist release notes ‐ May 22, 2025 (2025-05-22) Gemini Code Assist が Gemini 2.5 を使うようになった。 コード生成・修正、チャットのバックエンドモデルが最新化。Google I/O で発表されていた内容がリリースノートに載った形。 組織のポリシーのカスタム制約が BigQuery で利用可能に Manage BigQuery resources using custom constraints (2025-05-22) 組織のポリシーのカスタム制約が BigQuery で利用可能に。ユーザー独自の制約を定義できる。 統制のため使用リージョンや命名規則など一定のルールを強制的に課したいときに使える。 BigQuery の Optional job creation mode が GA Optional job creation mode (2025-05-27) BigQuery の Short query optimized mode が名称変更し Optional job creation mode として GA。 クエリ実行時に有効化すると適用可能な場合に同期的にジョブを実行し、レイテンシが改善。探索的なクエリやダッシュボードに使う想定。 blog.g-gen.co.jp Gemini Code Assist に Context Drawer が登場 Manage files and folders in the Context Drawer (2025-05-28) AI コーディング補助サービス Gemini Code Assist で、Context Drawer が登場。 ファイルやフォルダをドラッグ＆ドロップすると明示的にコンテキストに含めてくれる。VS Code 版、IntelliJ 版で利用可能。 Google ドライブで Gemini による動画の要約が可能に Understand your videos much faster using Gemini in Google Drive (2025-05-28) Google ドライブで、Gemini を使って動画を要約できるように。 サイドパネルで「動画の要約」「ネクストアクションのリストアップ」「ハイライトを教えて」などが可能。長い動画や会議の録画をぜんぶ見直さなくてもよくなる。本日より、順次ロールアウト（最長1ヶ月程度）。 AlloyDB インスタンスが停止・起動可能に Start, stop, or restart instances (2025-05-29) AlloyDB でプライマリインスタンスやリードプールインスタンスを停止・起動・再起動できるように。 停止中のインスタンスはコンピュート料金が課金されない。また、停止/再起動してもパブリック IP アドレスは変更されない 。 Cloud Storage とBigQuery 間の Event-Driven Transfers が利用可能に（GA） Event-Driven Transfers (2025-05-29) BigQuery Data Transfer Service で、Cloud Storage と BigQuery 間の Event-Driven Transfers が利用可能に（GA）。 バケットにデータが到着すると自動で転送を実行。最短10分間隔。コスト効率よく、小さい遅延でデータを BigQuery にロードできる。 Google スライドで「画像の背景削除」が日本語版にも対応 Google Workspace Updates Weekly Recap - May 30, 2025 (2025-05-30) Google スライドで「画像の背景削除」が日本語版にも対応。 背景透過画像をボタン1つで作成できてかなり便利。これまでアカウント設定を英語にしていないと利用できなかった。他に Google Vids や Google Drawing でも同様の機能が利用可能。 透過前 透過後 Associate Cloud Engineer の資格対策書籍が出版 合格対策 Google Cloud認定資格Associate Cloud Engineer テキスト＆演習問題 - Amazon (2025-05-30) G-gen のエンジニアによる Associate Cloud Engineer の資格対策書籍「合格対策 Google Cloud認定資格Associate Cloud Engineer テキスト＆演習問題」が出版決定。 合格対策 Google Cloud認定資格Associate Cloud Engineer テキスト＆演習問題 作者: 杉村 勇馬 , 佐々木 駿太 , 藤岡 里美 リックテレコム Amazon 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の荒井です。Google Cloud 認定資格はテストセンターで受験する他、オンラインで自宅からでも受験することが可能です。当記事ではオンライン受験前の準備や、受験時のポイントを紹介します。 はじめに Google Cloud 認定資格 オンライン受験のメリット・デメリット 試験の予約 CertMetrics での予約 試験言語 試験種別 予約日時 環境の準備 家族へ試験日時の連絡 端末の準備 Web カメラの準備 マイクの準備 セキュリティブラウザのインストール 受験する部屋の片付け 身分証の用意 OS アップデート 受験当日の準備 受験する部屋の片付け スマートフォンの通知設定 ファイアウォール設定 アンチウイルスソフト設定 アプリケーション（プログラム）の終了 試験当日 トラブル事例、注意点 インターネット接続が途切れた チェックイン中のカメラ・マイクトラブル PC トラブル セッションの切断 スマートフォンの通知（バイブ音） 花粉症のティッシュ 考え中は目を閉じる はじめに Google Cloud 認定資格 当記事では、Google Cloud 認定資格をオンラインで受験する場合の準備や、受験時のポイントを紹介します。 Google Cloud 認定資格の詳細については、以下の当社記事を参考にしてください。 blog.g-gen.co.jp オンライン受験のメリット・デメリット オンライン受験にはメリットとデメリットがあります。それぞれ確認して、オンライン受験がご自身にとってメリットがあるかどうか確認してください。 メリット 場所を選ばずに受験できる 試験日時の選択肢が広い 移動時間や交通費が削減できる 慣れた環境でリラックスして受験できる 予約変更・キャンセルが比較的容易にできる デメリット 部屋の片付けなど、場所を用意する必要がある 自身でPCなどの設備を用意する必要がある ネットワークトラブルなどのリスクがある テスト開始まで試験官との確認時間が長く、すぐに開始ができない メリットの中で特に大きいのが「 場所を選ばずに受験できる 」点です。テストセンターは首都圏などには多くありますが地方都市では限られていますし、テストセンターがない都道府県もあります。そのためオンライン受験は地方都市在住の受験者にとって、心強い選択肢です。 大きいデメリットとして「 部屋の片付けなど、場所を用意する必要がある 」が挙げられます。オンライン試験の受験前には、デスク周りや部屋を、試験に適した状態にするよう試験官から要求されます。また試験中、受験者の顔や部屋の様子は Web カメラで監視されます。デスク周りの物品や部屋のレイアウトを、適した状態に変更する労力が必要になります。 試験の予約 CertMetrics での予約 CertMetrics にログインして、試験予約を行います。予約時は以下について注意してください。 試験言語 試験予約時、試験の言語を選択することが可能です。任意の言語を選択してください。認定資格の種類によっては日本語が選択できない試験もあります。詳細は以下の記事を参照してください。 blog.g-gen.co.jp 試験種別 試験予約画面では、オンライン試験だけでなくオンサイト試験の予約も可能です。試験種別を間違えないよう、予約時はしっかり確認をしてください。 予約日時 オンライン受験は前述した通り柔軟に日時設定が可能であり、深夜でも受験することができます。予約の際は、AM・PM の時間指定を間違えないように気をつけます。 環境の準備 家族へ試験日時の連絡 自宅でオンライン受験する場合、受験中に家族が部屋に入ってくるなどのトラブルも発生しかねません。家族には予め試験日程を伝えたり、部屋の外に貼り紙などをして試験日時を家族に伝えてください。また試験中にインターホンなど鳴らないよう、通販の荷物到着日や訪問者の予定を確認してください。 試験中に上記のような事態が発生した場合、試験が停止してしまう場合があります。 端末の準備 オンライン受験を行うには、PC が必要です。PC は、Windows、Macintosh、Chromebook（機種指定あり） のいずれかでなければなりません。 PC は会社所有ではなく、個人所有など業務に関係のない端末の使用が指定されています。会社所有端末ではシステム設定やネットワーク設定についてポリシー管理されているケースがあるため、オンライン試験に必要な設定ができない場合があります。 参考 : Online Testing Requirements: What You Need to Know PC の筐体について指定はありませんが、Web カメラ付きのノートパソコンが推奨されます。 詳細は後述しますが、受験時に部屋の中を Web カメラで撮影するステップがあります。その際 Web カメラを移動させたり色々な方向に向ける必要があります。デスクトップ PC で有線の Web カメラを使用していると、ケーブルの長さの制限により、試験官が指定した場所の撮影ができず進行に支障が出ることがあります。 Web カメラの準備 Web カメラを用意します。Web カメラが内臓されているノートパソコンの場合、そのまま使用して問題ありません。また実際に起動できるか、事前にWeb カメラのテストも行ってください。 普段使用しないため Web カメラの機能をオフにしている場合、システム設定だけでなく、筐体横などにある物理スイッチの確認も行いましょう。デスクトップ PC での受験を考えている方は、外付け Web カメラのケーブルが十分に引き出せるか確認します。試験開始時に Web カメラを持って部屋の中を投影する必要があります。 参考 : オンライン監督付き (OLP) 試験にはどのようなカメラとカメラ設定が必要ですか? 参考 : Online Proctored Dual Camera Requirement マイクの準備 マイクを用意します。PC がノートパソコンの場合、内臓されているケースが多いです。実際にマイクが使えるか事前にテストを行っておきましょう。デスクトップ PC での受験を考えている方は、外付けマイクの用意をします。 セキュリティブラウザのインストール 試験を受ける際は、LockDown Browser というセキュリティブラウザを使用する必要があります。CertMetrics から Webassessor にログインし、LockDown Browser をインストールします。 参考 : How do I install LockDown Browser? – Respondus Support 受験する部屋の片付け 受験を行う部屋の片付けは最重要ポイントであり、要件が厳しく指定されています。片付けるポイントは、以下のとおりです。 受験時に着席する場所から、手の届く範囲に不要なものがないこと デスク周りのペンやバッグに注意 ディスプレイなどは見えないよう覆います ホワイトボードは消すか覆います 壁やデスクにある付箋などのメモを取り除きます 生活の都合上どうしても片付けが難しい場合、不要なものが少ない風呂場などで受験するケースも見られます。どうしても受験環境が構築できない場合、テストセンターでの受験を検討します。 参考 : オンライン試験の事前チェックの準備方法 身分証の用意 受験開始時に身分証の提示を要求されるため、身分証も用意します。運転免許証でも問題ありませんが、試験官は日本人でない場合が多いため、英語の記載があるパスポートが推奨されます。 参考 : テストセンターにはどのような身分証明書を持参する必要がありますか? OS アップデート 受験当日に、再起動を伴う OS アップデートなどが発生した場合、予約時間に試験を開始できない場合があります。アップデートは受験日までにすべて済ませておきましょう。 受験当日の準備 受験する部屋の片付け 受験当日は、最後の片付けを行います。不要なものがある場合、試験が開始できません。改めて以下のポイントを確認し片付けを行います。 受験時に着席する場所から、手の届く範囲に不要なものがないこと ペン立てがある場合、ペンを抜いておきます デスクの下などにバッグがある場合、移動します 何も入っていなくても、コップは移動します ディスプレイなどは見えないよう覆います ホワイトボードは消すか覆います 壁やデスクにある付箋などのメモを取り除きます 手の届かない場所であれば（背面側の壁など）、書籍などがあっても問題ありません 以下は、筆者が受験した際の環境です。参考にしてください。 こちらは、普段のデスクです。 こちらが、受験時のデスクです。ディスプレイやガジェットは紙で覆って見えなくしています。 コップは中身がなくても指摘されます。試験エリア外に除外します。 ペンも全て抜いて、試験エリア外に除外します。 バッグはデスクの内側にあった際、指摘がありました。可能な限り、試験エリア外に除外します。 スマートフォンの通知設定 試験中はスマートフォンの使用は禁止ですが、チェックイン（当日の試験開始プロセス）の際にスマートフォンが必要となります。チェックイン後にスマートフォンをテストエリアから除外できればよいのですが、そうでない場合試験エリア内で手の届かない場所にスマートフォンを置いておく必要があります。 スマートフォンの通知音（バイブレーション含む）が頻繁に鳴ると試験が中断されてしまう場合があるため、やむを得ず試験エリアにスマートフォンを置いておく場合、通知が鳴らない設定にしておきましょう。 ファイアウォール設定 PC でファイアウォールが有効になっている場合、試験前に無効にします。ファイアウォールが有効になっている場合、意図しない通信制限が発生し、試験要件を満たせず受験できない場合があります。 参考 : ファイアウォールを無効にする-Mac-Windows アンチウイルスソフト設定 OS のファイアウォール以外にも、アンチウイルスソフトでファイアウォールが有効になっている場合があります。試験前にアンチウイルスソフトのファイアウォールも無効にします。 アプリケーション（プログラム）の終了 試験用 PC を起動したら、すべてのアプリケーションを終了します。LockDown Browser 起動時、他のアプリケーションを終了を促すプロンプトが表示されます。ここからアプリを終了すると、強制終了となってしまうため、事前に終了しておきます。 主に気をつけるべきアプリケーションは以下のとおりです。 ブラウザ以外で開いているアプリケーション 常駐アプリケーション（以下例） アンチウイルス メッセンジャーツール クラウドストレージのデスクトップアプリ 試験当日 試験時間になったら、Webassessor の「アセスメント」より試験開始ボタンをクリックし試験に臨みます。ウィザードが開始されるので、ウィザードに沿って受験環境を確認します。 チェックイン（試験開始プロセス。受験環境の確認などを行う）は以下の項目を1つずつ確認するため、20分〜40分程度かかります。要点を書き出しますので、事前に確認をしてスムーズにチェックインできるように準備をします。 デバイス状態の確認 PC の電源が接続されているか プログラムがすべて終了されているか テスト環境の確認 帽子、ヘッドホン、上着のフードは着用していないか 時計、ブレスレッド、ストラップ、ネックレスは着用していないか テストエリアは適切な明るさが確保されており、背景は明るすぎないか（逆光になっていないか） LockDown Browser の起動 規約の確認 生体認証の説明と確認 メガネやマスクは外す テスト環境は暗くないか 認証・機器のテスト 生体認証（顔認証） インターネット接続テスト マイクテスト（テスト録音） カメラテスト（テスト撮影） 上記テストは、生体認証以外であれば事前に確認することができます。環境に不安がある場合、下記の「System Check」より事前に確認します。 参考 : System Check - Kryterion 参考 : How to Launch an Online Proctored (OLP) Exam チェックイン スマートフォンで QRを読み込むか、URL を入力しチェックイン画面にアクセスしチェックイン作業を行う 自身の顔を撮影 身分証を撮影 部屋の四方を撮影 正面 正面右 正面左 左の壁 右の壁 背面の壁 テストエリア（ PC 配置場所） 待機時間 待機時間はミニゲームと待機人数が表示されます。 オペレーターとチャット 待機時間が終了するとオペレーターとチャットが開始され、最終確認を行います。オペレーターからのチャットは機械翻訳されたような日本語で送られてきます。もし英語で送られてきた場合「日本語でお願いします」と入力すると日本語に変換されチャットが送られてきます。 試験中は休憩ができないことの確認 試験前にトイレに行くか否かの確認 部屋の全体を Web カメラで投影 規約の確認 試験開始 チェックイン時間は、試験時間に含まれません。 トラブル事例、注意点 インターネット接続が途切れた 試験中、インターネット接続が不安定になった事例があります。その際は、試験が一時停止されたことを示すメッセージが表示されました。 その後、インターネット接続環境が回復すると、メッセージが消えて試験が再開されました。落ち着いて画面のメッセージを確認してください。 チェックイン中のカメラ・マイクトラブル ファイアウォールの停止忘れにより、チェックイン中にカメラやマイクが動作しなかった事がありました。ファイアウォールの停止は、一度チェックインのプロセスから離脱しなければなりませんが、既にチェックインで数十分かかってしまっていたため、試験プロセスが中止になってしまわないか、不安もありました。 しかし、チェックインを中断したところ、試験時間が再設定された旨のメールが届いており、そこから無事、チェックインを再開できました。 試験官とのチャットにたどり着くまでは、運営側とのコミニュケーション手段はメールになります。落ち着いてメールを確認してください。 PC トラブル チェックイン中にPCトラブルで強制シャットダウン（ブルースクリーン）が発生し、試験が開始できなかったことがありました。数回発生し時間経過してしまったため、Webassessor の「アセスメント」から試験開始ができなくなってしまいました。 メールを確認すると「Kryterion サポートから問い合わせを行ってください」という旨の連絡がありました。 https://support.kryterion.com/lang/ja/ にアクセスし、右下のピンクのアイコンからサポート担当者に問い合わせを開始し試験の再開ができました。 万が一事情によりメールが届かない場合、Kryterion のチャットサポートから問い合わせを行うことが出来ます。問い合わせの際は以下情報を用意しておくと、問い合わせがスムーズにできます。 メールアドレス 氏名 試験名称 セッションの切断 なんらかの事情で、チェックイン中にセッションが切断されてしまったことがありました。セキュリティブラウザ自体はそのまま起動しており、ポップアップ画面で「[✕] ボタンでブラウザを閉じてください。」とのメッセージが表示されましたためセキュリティブラウザを [✕] で閉じようとしましたが反応しませんでした。 Windows 端末のため、ブラウザを強制終了すべく [Ctrl + Alt + Delete] からタスクマネージャーを表示しようと思いましたが、これも反応しませんでした。 最終的に、画面内に「試験終了」というボタンがあったためそれをクリックすることでセキュリティブラウザが閉じました。ブラウザ自体が反応しない場合 PC のハードスイッチで強制終了しか手段がありませんが、セキュリティブラウザを閉じる際は「試験終了」から終了します。 スマートフォンの通知（バイブ音） 試験中、スマートフォンの通知が多く発生し、バイブが断続的に鳴り続けてしまったことがありました。 その際、試験画面に「テストエリアに不要なものがあります。クリアにしてください。」といったメッセージが表示されました。スマートフォンの操作を行ってしまうと、カンニングの疑いがかかると考え、近くにあった柔らかい布の上にスマートフォンを置いてバイブ音を軽減しました。 試験画面のメッセージはしばらくしたら消え、試験を再開することが出来ました。スマートフォンの通知には気をつけましょう。 花粉症のティッシュ 春先に試験を受けた際、花粉症で鼻水が止まらないことがありました。試験官にチェックインのチャットで相談したところ、ティッシュ数枚であれば承認を得た後持ち込みが可能でした。 ただしティッシュは箱や袋から出して、不正がないよう1枚ずつカメラに投影してチェックする必要がありました。テストエリアへの不要な物品の持ち込みは禁止ですが、やむを得ず必要となるものがある場合、試験官に相談してください。 考え中は目を閉じる 試験官とのチャットで案内もありますが、テスト中はカンニングを疑われないよう、目線を上下左右に逸らすことは避けます。目の疲労を感じた場合は、目を閉じて休憩してください。 その他オンライン受験に関する情報は下記ページに集約されています。事前に確認してからオンライン試験に臨んでください。 参考 : オンライン監督ガイダンス 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 ・Google Cloud 認定資格 7冠 最近ハマっていることは、息子とのポケモンカード Follow @arapote_tweet

G-gen の福井です。当記事では、Cloud Run 上で動作する Python アプリケーションのパフォーマンス分析に焦点を当て、Google Cloud の Cloud Trace を用いてリクエスト処理のボトルネックを特定・可視化する手順を紹介します。 はじめに Cloud Trace とは トレースとスパン トレースコンテキスト サンプリング 事前準備 Cloud Trace API の有効化 サービスアカウントの作成とロールを付与 アプリケーションへのトレース実装 ディレクトリ構成 必要なライブラリのインストール OpenTelemetry の設定と使用 Cloud Run へのデプロイ Dockerfile の準備 Cloud Run にデプロイ 動作確認 Cloud Trace で処理時間を確認 トレースリストの表示 トレースリストの見方 パフォーマンスのボトルネックを特定 トレース詳細の表示 トレース詳細の見方 はじめに Cloud Trace とは Cloud Trace は、Google Cloud が提供する 分散トレーシングシステム です。アプリケーションに対するリクエストが、システム内の複数のサービスやコンポーネントをどのように経由していくかを追跡し、各処理ステップでのレイテンシ（遅延時間）を収集・可視化します。特にマイクロサービスアーキテクチャのように、一つのリクエストが複数のサービスにまたがる場合に、パフォーマンスのボトルネックを特定するのに役立ちます。 参考: Cloud Trace の概要 Cloud Trace を理解する上で重要な、以下の基本概念について説明します。 トレースとスパン トレース （Trace）は、特定のリクエストがアプリケーション内で一連の処理を完了するまでの全体の流れを示すものです。このトレースは、一つ以上の「スパン」から構成されます。 スパン （Span）は、トレース内で行われる個々の作業単位を表します。例えば、特定の関数呼び出し、外部 API へのリクエスト、データベースクエリなどが一つのスパンに対応します。各スパンは、開始時刻、終了時刻、名前、一意の ID、そして親子関係を示す情報（どのスパンから呼び出されたか）などを持ちます。トレース全体を包含する最初のスパンを ルートスパン と呼びます。 参考: トレースとスパン トレースコンテキスト 分散システムにおいて、リクエストがサービス境界を越えて伝播する際に、トレース情報をどのように引き継ぐかが重要です。 トレースコンテキスト （Trace Context） は、このトレース ID や現在のスパン ID などの情報をサービス間で伝播させるための標準化された方法です。一般的には、HTTP ヘッダー（例: traceparent ）などを用いて情報を伝達します。これにより、複数のサービスにまたがる処理を単一のトレースとして正しく紐付けることができます。 参考: トレース コンテキスト サンプリング 常にすべてのリクエストのトレースデータを収集すると、特に高トラフィックなシステムでは、データ量やパフォーマンスへのオーバーヘッド、コストが大きくなる可能性があります。そのため、 サンプリング （Sampling）という手法を用います。これは、一定の割合のリクエストのみをトレース対象とする仕組みです。 Cloud Trace は、計装ライブラリ（今回使用する OpenTelemetry など）と連携し、設定されたサンプリングレートに基づいてトレースデータを収集します。どのようなサンプリング戦略（常にサンプリングする、一定割合でサンプリングする、など）を取るかは、アプリケーション側で設定します。 参考: トレース サンプリング 事前準備 Cloud Trace API の有効化 アプリケーションがトレースデータを Google Cloud に送信するためには、プロジェクトで Cloud Trace API を有効にする必要があります。 gcloud services enable cloudtrace.googleapis.com 参考: Cloud Trace の設定 サービスアカウントの作成とロールを付与 以下の gcloud コマンドを順次実行します。 なお、以下のコマンド内で使用されている環境変数 PROJECT_ID の your-project-id の部分は、ご自身の Google Cloud プロジェクト ID に置き換えてください。 # 環境変数の設定 PROJECT_ID =your-project-id SA_NAME =sv-cloud-trace-demo-app # サービスアカウント作成 gcloud iam service-accounts create $SA_NAME \ --description =" Cloud TraceでCloud Runの処理時間を計測するサービスアカウント " \ --display-name =" Cloud TraceでCloud Runの処理時間を計測するサービスアカウント " # サービスアカウントへ権限付与 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: $SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/cloudtrace.agent " gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: $SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com " \ --role =" roles/logging.logWriter " アプリケーションへのトレース実装 Python アプリケーションにトレースデータを収集・送信するコードを追加します。ここでは、テレメトリデータ（トレース、メトリクス、ログ）を生成・収集するためのオープンソースのオブザーバビリティフレームワークである OpenTelemetry を使用します。 ディレクトリ構成 今回開発する Python アプリケーションのディレクトリ構成は以下のとおりです。 cloud-trace-demo-app |-- main.py |-- requirements.txt |-- Dockerfile 必要なライブラリのインストール OpenTelemetry 関連の Python ライブラリをアプリケーションの依存関係に追加します。 requirements.txt # Webフレームワーク flask>=2.0 # OpenTelemetry Core opentelemetry-api==1.32.1 opentelemetry-sdk==1.32.1 # Cloud Trace Exporter opentelemetry-exporter-gcp-trace==1.9.0 # Automatic Instrumentation opentelemetry-instrumentation-flask==0.53b1 opentelemetry-instrumentation-requests==0.53b1 # Logging opentelemetry-instrumentation-logging==0.53b1 google-cloud-logging==3.12.1 OpenTelemetry の設定と使用 アプリケーションコードに OpenTelemetry の設定と、トレース（スパン）生成のための実装を追加します。 以下は、Flask アプリケーションに、OpenTelemetry の初期化、自動計装の適用、および手動でのスパン作成を組み込んでいます。 main.py import logging import time import google.cloud.logging import requests from flask import Flask from opentelemetry import trace from opentelemetry.exporter.cloud_trace import CloudTraceSpanExporter # OpenTelemetry 自動計装ライブラリ from opentelemetry.instrumentation.flask import FlaskInstrumentor from opentelemetry.instrumentation.logging import LoggingInstrumentor from opentelemetry.instrumentation.requests import RequestsInstrumentor # OpenTelemetry SDK コンポーネント from opentelemetry.sdk.resources import Resource from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import BatchSpanProcessor # -------------------------------------------------------------------------------- # --- OpenTelemetry SDK の初期化と設定 # -------------------------------------------------------------------------------- # リソースの定義: トレースに紐付けるサービス名などを設定 resource = Resource(attributes={ "service.name" : "my-python-cloudrun-service" }) # TracerProviderの作成: リソース情報を紐付け provider = TracerProvider(resource=resource) # CloudTraceSpanExporterの作成: トレースデータを Google Cloud Trace に送信 trace_exporter = CloudTraceSpanExporter(resource_regex= "^service\.name$" ) # BatchSpanProcessorの作成: スパンをまとめて効率的にエクスポート trace_processor = BatchSpanProcessor(trace_exporter) provider.add_span_processor(trace_processor) # グローバルなTracerProviderとして設定: アプリケーション全体で使用可能に trace.set_tracer_provider(provider) # -------------------------------------------------------------------------------- # --- Python標準loggingとOpenTelemetry Logging計装の設定 # -------------------------------------------------------------------------------- # LoggingInstrumentorの有効化: ログレコードにトレースID/スパンIDを自動付加 # set_logging_format=True で、ログ形式にトレース情報が追加される LoggingInstrumentor().instrument(set_logging_format= True ) # Google Cloud Logging クライアントの初期化と設定 client = google.cloud.logging.Client() client.setup_logging(log_level=logging.INFO) logger = logging.getLogger(__name__) # -------------------------------------------------------------------------------- # --- OpenTelemetry Tracer の取得 # -------------------------------------------------------------------------------- # アプリケーションコード内で手動スパンを作成するためにTracerを取得 tracer = trace.get_tracer(__name__) # -------------------------------------------------------------------------------- # --- Flaskアプリケーションの初期化と自動計装 # -------------------------------------------------------------------------------- app = Flask(__name__) # FlaskInstrumentorの適用: Flaskリクエストの自動トレース FlaskInstrumentor().instrument_app(app) # RequestsInstrumentorの適用: requestsライブラリによるHTTPコールの自動トレース RequestsInstrumentor().instrument() # -------------------------------------------------------------------------------- # --- 手動スパン作成を含む各種処理関数 (例) # -------------------------------------------------------------------------------- @ tracer.start_as_current_span ( "step_1_initial_setup" ) # この関数実行を1つのスパンとして計測 def initial_setup (input_val): current_span = trace.get_current_span() # 現在アクティブなスパンを取得 current_span.set_attribute( "input.value" , str (input_val)) # スパンに属性を追加 logger.info( f "Executing initial_setup for: {input_val}" , extra={ "json_fields" : { "tags" : [ "setup" ], "input_data" : input_val}}, ) time.sleep( 1 ) result = f "Setup_{input_val}" current_span.set_attribute( "output.value" , result) return result @ tracer.start_as_current_span ( "step_2_data_validation" ) # この関数実行を1つのスパンとして計測 def validate_data (data_to_validate): time.sleep( 2 ) return len (data_to_validate) > 3 @ tracer.start_as_current_span ( "step_3_main_processing_logic" ) # この関数実行を1つのスパンとして計測 def main_processing_logic (valid_data): current_span = trace.get_current_span() logger.info(f "Starting main processing for: {valid_data}" ) # 特定のコードブロックを計測するためのネストしたスパン with tracer.start_as_current_span( "internal_process_A" ) as span_a: logger.debug( "Executing internal_process_A" ) # DEBUG レベルのログ例 time.sleep( 3 ) result_a = "Result_A_from_main_processing" span_a.set_attribute( "process_a.status" , "completed" ) # 別のコードブロックを計測するためのネストしたスパン (外部呼び出しを含む) with tracer.start_as_current_span( "call_dependent_microservice" ) as span_b: logger.info( "Calling dependent microservice (simulated via httpbin)" ) # このrequests呼び出しはRequestsInstrumentorにより自動トレースされる response = requests.get( "https://httpbin.org/get?service_call=true" , params={ "id" : "internal_B" }) span_b.set_attribute( "http.status_code" , response.status_code) result_b = response.json().get( "args" , {}) logger.info( "Dependent microservice call successful, args: %s" , result_b) final_result = f "{result_a} & {result_b}" current_span.set_attribute( "final_result.summary" , final_result[: 30 ]) logger.info( "Main processing completed." ) return final_result @ tracer.start_as_current_span ( "step_4_skip" ) # この関数実行を1つのスパンとして計測 def skip_loggic (): pass @ tracer.start_as_current_span ( "step_5_final_aggregation" ) # この関数実行を1つのスパンとして計測 def final_aggregation (data_from_main): current_span = trace.get_current_span() logger.info( "Aggregating final results." ) time.sleep( 5 ) aggregated_result = { "main_output" : data_from_main} current_span.set_attribute( "aggregation.items_count" , 2 ) logger.info( "Final aggregation complete." , extra={ "json_fields" : { "aggregated_keys" : list (aggregated_result.keys())}} ) return aggregated_result # -------------------------------------------------------------------------------- # --- Flask ルート定義 # -------------------------------------------------------------------------------- @ app.route ( "/" ) def main_request_handler (): # このリクエスト処理全体を包括する親スパンを手動で作成 with tracer.start_as_current_span( "main_request_flow" ) as parent_span: parent_span.set_attribute( "http.request.path" , "/" ) # スパンの属性にリクエストパスを追加 parent_span.set_attribute( "user.id" , "example_user_123" ) # スパンの属性にユーザー情報を追加 logger.info( "Main request handler started for user: %s" , "example_user_123" ) # step_1 setup_result = initial_setup( "Request_Payload_Data" ) # step_2 is_data_valid = validate_data(setup_result) # step_3 main_processed_data = main_processing_logic(setup_result) if is_data_valid: parent_span.add_event( "DataValidationSkipped" , { "reason" : "Invalid data" }) logger.warning( "processing skipped due to invalid data." ) else : # step_4 skip_loggic() # step_5 final_output = final_aggregation(main_processed_data) parent_span.set_attribute( "response.content_type" , "application/json" ) logger.info( "Main request handler completed successfully." ) return final_output # -------------------------------------------------------------------------------- # --- アプリケーション起動 # -------------------------------------------------------------------------------- if __name__ == "__main__" : app.run(debug= True , host= "0.0.0.0" , port= 7860 ) Cloud Run へのデプロイ Dockerfile の準備 アプリケーションをコンテナ化するための Dockerfile を作成します。 Dockerfile FROM python:3.12-slim WORKDIR /usr/src/app COPY requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 7860 CMD [ " python ", " ./main.py " ] Cloud Run にデプロイ Dockerfile が存在するディレクトリで、以下の gcloud コマンドを順次実行します。 なお、以下のコマンド内で使用されている環境変数 PROJECT_ID の your-project-id の部分は、ご自身の Google Cloud プロジェクト ID に置き換えてください。 # 環境変数の設定 PROJECT_ID =your-project-id REGION =asia-northeast1 SA_NAME =sv-cloud-trace-demo-app # Cloud Run サービスをデプロイ gcloud run deploy cloud-trace-demo-app --source . \ --region = asia-northeast1 \ --allow-unauthenticated \ --port 7860 \ --memory = 1Gi \ --min-instances = 0 \ --max-instances = 1 \ --service-account = $SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com \ --set-env-vars = PROJECT_ID = $PROJECT_ID , LOCATION = $REGION 動作確認 Cloud Run のデプロイが完了すると、標準出力に Cloud Run のエンドポイントが Service URL として出力されます。この URL に、ブラウザからアクセスします。 $ gcloud run deploy cloud-trace-demo-app --source . \ --region = asia-northeast1 \ --allow-unauthenticated \ --port 7860 \ --memory = 1Gi \ --min-instances = 0 \ --max-instances = 1 \ --service-account = $SA_NAME @ $PROJECT_ID .iam.gserviceaccount.com \ --set-env-vars = PROJECT_ID = $PROJECT_ID , LOCATION = $REGION Building using Dockerfile and deploying container to Cloud Run service [ cloud-trace-demo-app ] in project [ your-project-id ] region [ asia-northeast1 ] \ Building and deploying... Uploading sources. \ Uploading sources... OK Building and deploying... Done. OK Uploading sources... OK Building Container... Logs are available at ・・・ OK Creating Revision... OK Routing traffic... OK Setting IAM Policy... Done. Service [ cloud-trace-demo-app ] revision [ cloud-trace-demo-app-00003-tdv ] has been deployed and is serving 100 percent of traffic. Service URL: https://cloud-trace-demo-app-XXXXXXXX.asia-northeast1.run.app アクセスすると、以下の画面が表示されます。 アクセス後のブラウザ画面 Cloud Trace で処理時間を確認 トレースリストの表示 Google Cloud コンソールの Cloud Trace エクスプローラ画面を表示します。 以下の画面は、Cloud Run アプリケーションへ連続して数回アクセスした後の画面です。 トレースリスト トレースリストの見方 サービス名（①） プログラムで指定したサービス名で、関連するスパンを絞り込めます。 main.py におけるサービス名の指定箇所 スパン名（②） プログラムで指定したスパン名で、関連するスパンを絞り込めます。 main.py におけるスパン名のアノテーション例（関数） main.py におけるスパン名の指定例（コードブロック） ヒートマップ（③）と一覧（④） ヒートマップでスパンの実行時間や処理時間を可視化し、一覧でスパン詳細を確認できます。 パフォーマンスのボトルネックを特定 ヒートマップでは、処理時間が長いスパンが上に表示され、呼び出し数が多いと色が濃く表示されます。ヒートマップ上で対象を選択するとスパン一覧が絞り込まれ、パフォーマンスのボトルネックとなっているリクエストを特定できます。 スパン一覧では、スパンごとに処理時間（列：期間）が表示されているため、処理時間の降順で並び替えることで、リクエスト内のより詳細なパフォーマンスのボトルネックとなっている箇所を特定できます。 トレース詳細の表示 トレースリストのスパン一覧からスパン ID のリンクを選択し、トレース詳細画面を表示します。 トレース詳細 トレース詳細の見方 タイムライン（①） トレース（単一のリクエスト）内における全スパンの実行の流れを時系列で示したものです。それぞれの横棒が個々のスパンを表し、棒の左端が処理の開始時刻、右端が終了時刻を示し、その長さが処理時間（レイテンシ）を意味します。スパンは親子関係に基づいて階層的に構成され、呼び出し元のスパンの下に、呼び出された処理のスパンがインデントされて表示されます。リクエスト全体の処理時間は、一番上に位置するルートスパンの長さとして示されます。 属性（②） タイムライン上のスパンを選択すると、選択したスパンに紐づくプログラムで指定したキーと値の属性情報が表示されます。 属性 main.py における属性の指定例 ログ（③） タイムライン上のスパンを選択すると、選択したスパンに紐づくプログラムで出力した Cloud Logging のログ情報が表示されます。 ログ main.py におけるログの指定例 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進

G-genの杉村です。Google ドライブのファイル共有は非常に便利ですが、設定を誤ると意図せず情報が公開されてしまう可能性があります。本記事では、Google ドキュメント、Google スプレッドシート、Google スライドなどを安全に共有するための設定方法と注意点を解説します。 Google ドライブのファイル共有とは 共有設定の種類と注意点 3種類の共有状態 リンクを知っている全員 制限付き （組織部門名） 安全なファイル共有方法 インターネット公開を禁止する Google ドライブのファイル共有とは Google ドライブに保存されている Google ドキュメント、Google スプレッドシート、Google スライドなどのファイルは、他の Google Workspace ユーザーや、無償の Gmail アカウントを持つユーザーに簡単に共有できます。ファイルを開いた状態で画面右上に表示される「共有」ボタンから設定を行います。 Google ドライブのファイルの共有設定 共有設定では、誰がファイルにアクセスでき、どのような操作（閲覧のみ、コメント可、編集可）を許可するかを、細かく制御できます。 参考 : Google ドライブのファイルを共有する - Google Drive ヘルプ 共有設定の種類と注意点 3種類の共有状態 ファイル共有設定画面の「一般的なアクセス」項目では、「 リンクを知っている全員 」、「 制限付き 」、「（ 組織部門名 ）」の選択肢があります。 ※（ 組織部門名 ）は、スクリーンショットでは「G-gen デモ用」と表示されています。 3つの共有設定 リンクを知っている全員 「リンクを知っている全員」を選択すると、そのファイルのリンクを知っている人であれば、Google アカウントでログインしていなくても誰でもファイルにアクセスできるようになります。 リンクを知っている全員 また、ファイルにアクセスできる人に与えたい権限に応じて、「閲覧者」、「閲覧者（コメント可）」、または「編集者」を選択できます。 この設定は、不特定多数の人にファイルを公開したい場合（例: Webサイトで公開する資料など）には便利ですが、大きな注意点があります。「リンクを知っている全員」は、 ファイルをインターネットに公開している状態 です。 このリンクが意図しない経路で第三者に渡ってしまった場合、本来アクセスを許可するつもりのなかった人にもファイルの内容が閲覧されてしまうリスクがあります。ファイルの共有状態を「リンクを知っている全員」にすると、情報漏洩に繋がる可能性があるため、極めて慎重に判断する必要があります。 制限付き 「 制限付き 」は、明示的にアクセス権を付与されたユーザーのみがファイルにアクセスできる設定です。ファイルを共有したい相手の Google アカウント（メールアドレス）を個別に追加し、それぞれのユーザーに対して「閲覧者」、「閲覧者（コメント可）」、または「編集者」の権限を設定します。 これが、ファイルを特定の相手とのみ共有したい場合の 推奨される設定 です。 制限付き （組織部門名） 「一般的なアクセス」項目で、Google Workspace に設定されている組織部門の名称を選択すると、同じ組織部門に所属する Google アカウントに対して、ファイルを共有できます。最上位の組織部門に共有することで、同じ Google Workspace ドメインに所属する全従業員へ共有できます。 組織部門への共有 組織部門に対して共有する際も、「閲覧者」、「閲覧者（コメント可）」、または「編集者」のうち、いずれかの権限を設定できます。また、ユーザーが Google ドライブ上で検索したときに、検索結果に表示するか、あるいは検索結果には表示させず、リンクを明示的に知っている人のみにアクセスを限定するかも選択できます。 組織部門への共有（詳細） 安全なファイル共有方法 ファイルを意図しない相手に公開したくない場合は、以下の手順で共有設定を行います。 1. 「一般的なアクセス」を「制限付き」にする ファイル共有設定画面で、「一般的なアクセス」の項目が「制限付き」になっていることを確認します。もし「リンクを知っている全員」になっていたら、「制限付き」に変更します。 2. 共有したい相手を個別に追加する 「ユーザーやグループと共有」の入力欄に、共有したい相手の Google アカウントのメールアドレスを入力します。 共有対象アカウントのメールアドレスを入力 3. 適切な権限を設定する 追加したユーザーごとに、以下のいずれかの権限を選択します。 閲覧者 : ファイルの閲覧のみ可能。変更やコメントはできない 閲覧者（コメント可） : ファイルの閲覧とコメントの追加が可能。編集はできない 編集者 : ファイルの閲覧、コメント、編集が可能 4. 通知とメッセージ （任意） 必要に応じて「通知」チェックボックスを有効にすると、共有相手に通知を送信し、メッセージを送信できます。 5 . 「送信」または「保存」をクリック 設定が完了したら、「送信」（新規共有の場合）または「保存」（既存の共有設定変更の場合）をクリックします。 権限選択、メッセージの追加、送信 インターネット公開を禁止する Google Workspace の管理者は、Google ドライブのファイルの共有状態を「リンクを知っている全員」にすることを禁止できます。インターネット公開を禁止するには、以下の手順を行います。 参考 : 組織の外部共有を管理する 管理コンソールにログインし、「アプリ > Google Workspace > ドライブとドキュメント」を開きます。 アプリ > Google Workspace > ドライブとドキュメント 「共有設定」をクリックします。 共有設定 「共有オプション」をクリックします。 共有オプション 「（組織部門名）の外部との共有が許可されている場合、（組織部門名）内のユーザーは、リンクを知っているすべてのユーザーに対して、ファイルおよび公開済みのウェブ コンテンツを公開することができます」の横にあるチェックボックスを外します。 ※（ 組織部門名 ）は、スクリーンショットでは「G-gen」と表示されています。 チェックボックスを外す 忘れずに、右下の「保存」ボタンを押下します。 保存ボタンを押下 なお、この設定をユーザーの所属する組織部門に設定した場合、ユーザーの マイドライブのファイル を「リンクを知っている全員」にすることができなくなります。 共有ドライブのファイルを「リンクを知っている全員」にすることを禁止するには、 共有ドライブに組織部門を割り当て 、その組織部門で上記の設定をする必要があります。 片方の設定だけでは、すべてのインターネット公開を禁止することはできませんので、注意してください。 参考 : さまざまなユーザーに設定を適用する 参考 : 特定の共有ドライブのデータポリシーを管理する 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の川村です。この記事では NotebookLM の 音声概要 機能にフォーカスした活用方法を解説します。 NotebookLM とは 音声概要とは 事前準備 言語設定 ソースの追加 音声概要の使い方 音声概要の生成 カスタマイズ機能 音声概要のダウンロード インタラクティブモード（ベータ版） 活用シーン 1. 通勤・移動中の情報収集を効率化 2. 目的別に学習を最適化 3. 複雑な資料の理解を促進 4. 参加型の対話モードでリアルタイムに情報整理 5. 多言語学習 注意点 NotebookLM とは NotebookLM とは、Google ドキュメント、PDF、音声、YouTube 動画などをソースとして指定し、その情報を基に要約・FAQ・メモを生成できる Google 提供の AI ノートサービスです。 一般的な生成 AI チャットアプリと異なり、回答の出典をユーザーが明示的に制御できるため、業務利用において高い信頼性が確保されます。 無償版で利用できる NotebookLM、有償版の NotebookLM in Pro、より企業向けの機能を強化した NotebookLM Enterprise があり、それぞれの機能の違いや活用ユースケースについては以下の記事を参照してください。 blog.g-gen.co.jp 音声概要とは NotebookLM の 音声概要 （Audio Overviews）とは、指定したソースに基づいて、 AI が2人の人間の自然な対話形式で内容を要約・解説する機能です。 2025年4月末から日本語を含む 50 以上の言語に対応し、日本語でも実用的なレベルで利用できるようになりました。Google 公式の紹介動画でも AI 生成と思えないような流暢な会話であることが確認できます。 youtu.be なお、利用回数制限は以下のとおりです。 NotebookLM : 3回/日 NotebookLM in Pro : 20回/日 参考 : NotebookLM の Pro 機能の詳細 参考 : NotebookLM を Pro プランにアップグレードする 事前準備 言語設定 まず、NotebookLM の出力される言語設定を行います。 [ 設定 ] 画面から[ 言語設定 ]を選択します。 Google アカウントの言語設定がデフォルトで設定されていますが、明示的に [日本語] を選択できます。 ソースの追加 続いて、NotebookLM に対象となるソースを追加します。 [ソース] からデータソースを追加後、[Studio] パネルの [音声概要] セクションの [生成] ボタンをクリックすると、音声概要が生成されます。 参照 : ソース 音声概要の使い方 音声概要の生成 今回は Google Cloud 資格の過去問題をまとめた資料（Google ドキュメント）をソースとして指定した例です。 [音声概要] セクションの [生成] ボタンを押すと、音声概要が生成されます。 生成には、数分かかります。生成完了後に再生ボタンを押すと、対話式の音声が再生されます。 実際に生成された音声はこちらです。 www.youtube.com 「試験のポイントとか、実践的な知識をギュッと抽出するのが目標です」 「〜っていうのはもう必須の知識ですよね」 「最後に 1 つだけあなたにも考えてみて欲しいことがあるんです」 このように対話には AI ホストによるソースの解釈に基づいて自然な相槌やコメント、さらには聞き手に対する問いかけもあります。まさにラジオ感覚で情報を耳から受け取りやすくなり内容の整理にも役立ちます。 カスタマイズ機能 [カスタマイズ] ボタンをクリックすると、トピックや話し方のスタイルを指定できます。最大 500 文字まで入力可能です。 聞きたい内容やスタイルに沿ったラジオ番組のような音声を生成するために、以下のような具体的な指示を入力します。 入力例 : 「VPC & Network Security」項目の内容を重点的に、且つ IT 初心者にもわかりやすい解説にして www.youtube.com 「特に Network Security のところをちょっと深掘りしてみようかなと」 「ファイアーウォールはネットワークの門番みたいなものです」 「これ単なる『ログ』っていうよりは、ネットワークの「健康診断の記録」みたいなものですね」 先程生成した網羅的な音声と比べると、よりユーザーの意図（特定トピックに絞った内容且つ、 IT 初心者に向けの解説）に沿った音声概要が生成されます。 音声概要のダウンロード 生成された音声は三点リーダーをクリックすると表示されるプルダウンメニューからダウンロードできます。 音声ファイルはスマートフォンで再生したり、NotebookLM のソースとして再アップロードすることで、要約・メモに再利用することも可能です。 インタラクティブモード（ベータ版） 2025年5月現在は英語版のみでの提供となりますが、再生中にユーザーが AI ホストに質問できる インタラクティブモード も試験提供されています。 再生中に「参加」ボタンを押すと AI ホストから声がかかり、アップロードされたソースに基づいて回答が得られます。質問への回答後、元の音声概要の再生が再開されます。（ユーザーの声ややりとりは保存されません） 公式動画での利用イメージは以下となります。 www.youtube.com 参考 : 音声概要 活用シーン 1. 通勤・移動中の情報収集を効率化 移動中や作業をしながら、耳で情報をインプットすることで効率的に学習や情報収集ができます。 ニュース記事やブログ記事、会議の議事録などを音声概要化し、移動時間や作業中も情報収集に充てる ダウンロードした音声ファイルでオフライン環境や、端末（パソコンやスマートフォンなど）を選ばず再生可能 NotebookLM モバイルアプリから、いつでもどこでも学習を開始 ※ 5月20日リリース 参照 : Google launches official NotebookLM mobile app 2. 目的別に学習を最適化 カスタマイズ機能 で、解説してほしい内容や焦点を当てるべきトピックを指定し学習を効率化します。 目的に合わせて学習トピックを絞り学習を効率化 以下のような指示で音声の内容・口調を調整し理解を深める 「セキュリティに関する側面を解説して」 「小学生にもわかるように説明して」 「合格までのステップを 5 つ以内で簡潔に解説して」 3. 複雑な資料の理解を促進 難解で複雑な内容の資料（研究論文、専門記事、長文レポートなど）も音声概要を利用することで、手軽且つ効率的に理解を深めることができます。視覚情報よりも聴覚情報の方が頭に入りやすいと感じる方にも有効です。 膨大な資料（300 ページの書籍 PDF など）を深く読み込む前に、音声で概要を掴み情報整理を支援 視覚（テキスト）では難解な内容を、聴覚（AI ホストの対話形式）で情報の背景や文脈をストーリーとして理解促進 4. 参加型の対話モードでリアルタイムに情報整理 2025年5月現在、英語のみでの提供ですが、インタラクティブモードを利用することで、ソースに対する AI ホストとの会話に参加できます。 再生中、疑問点が浮かんだ際にその場で解消 対話を通じて理解を深め、発想の幅を広げる 5. 多言語学習 50 を超える言語に対応しているため、多言語の学習にも大いに役立ちます。英語やフランス語など、さまざまな言語学習を効率的に行えます。出力言語の言語設定をすることで、任意の言語での生成を行うことができます。 英語で音声概要を生成・ダウンロードし、リスニング力を高める インタラクティブモードで AI ホストと対話し、スピーキング力を高める 生成した英語の音声ファイルをソースとして追加・テキスト化して、シャドーイングや単語学習に利用 プロンプト例 この音声をセリフごとに分割し、それぞれの英語文と日本語訳を表で一覧化してください。 注意点 音声概要機能は便利ですが、以下の点にご注意ください。 利用回数制限あり（無償版は 1日3回、NotebookLM in Pro は1日20回まで） 漢字の誤読あり（ふりがなや指示で回避可能） 自動生成のため誤情報を含む可能性あり（ソースに基づいた生成のためハルシネーションが起こりにくいが、ファクトチェック推奨） 生成中はブラウザを閉じない事を推奨（生成に時間がかかる） 削除・再生成した音声は再生不可（必要であればダウンロード推奨） インタラクティブモードは現状英語のみ対応 現状日本語音声は10分弱となり、長編音声は未対応（英語のみ 30 分以上対応） なお、今後のアップデートにより上記内容は改善される可能性があります。 川村真理 (記事一覧) クラウドソリューション部 クラウドサポート課 美容業界からITへ転身。Google Workspace 専任サポートから Google Cloud にも興味が湧き日々奮闘中。海外旅行が大好きで11カ国突破、これからも更新予定

G-gen の川村です。この記事では Google 提供の AI 支援ツールである NotebookLM について、特徴や Gemini アプリとの違いに触れながら、業務における具体的な活用方法を紹介します。 前提知識 NotebookLM とは Gemini アプリとは Gemini アプリとの違い NotebookLM の主要活用パターン 1. ドキュメント・ナレッジ統合管理 2. 資料要約・差分分析 3. 音声・動画から要点自動抽出 4. FAQ・クイズ自動生成 実務で活きる NotebookLM ユースケース 1. ナレッジの構造化と共有 2. 資料の要約・比較による意思決定支援 3. 音声・動画データの情報抽出 4. 教育・トレーニング支援 5. 簡易的なチャットボット NotebookLM vs Gemini アプリの使い分け 前提知識 NotebookLM とは NotebookLM とは、Google ドキュメント、PDF、音声、YouTube 動画などをソースとして指定し、その情報を基に要約・FAQ・メモを生成できる Google 提供の AI サービスです。 一般的な生成 AI と異なり、回答の出典をユーザーが明示的に制御できるため、業務利用において高い信頼性が確保されます。 NotebookLM や NotebookLM in Pro（旧称 NotebookLM Plus）の基本機能については以下ブログをご参考ください。 blog.g-gen.co.jp Gemini アプリとは Gemini アプリ とは、Web ブラウザやモバイルアプリでアクセスできる対話型 AI サービスです。自由な形式での質問応答、文章生成、アイデア出しなどに利用できます。 また、PC 等の Web ブラウザでアクセスする Gemini アプリを Gemini ウェブアプリ、スマートホンなどのモバイル向けの Gemini アプリを Gemini モバイルアプリと呼びます。 参考 : 全Geminiプロダクトを徹底解説！ - G-gen Tech Blog - Gemini アプリ Gemini アプリとの違い NotebookLM と Gemini アプリは、どちらも Google の生成 AI ソリューションですが、特徴・用途が異なります。以下の比較表にその違いをまとめます。 比較項目 NotebookLM Gemini アプリ 参照範囲 指定した資料を「ソース」として固定し、その範囲内で回答 インターネット上知識や最新情報を広範に参照 出典の明示 指定資料に基づき、出典を明示可能 ソースに基づく回答に加え、学習知識からの推論が可能 出力の特性 限定された情報に基づく高精度な出力 創造性と網羅性を両立した出力 得意なシーン 議事録要約、社内 FAQ、資料整理などの再構成 アイデア創出や自由形式の企画支援 モデルの選択 なし Gemini 2.5 Pro、Gemini 2.5 Flash などから選択可能。Deep Research も実行可能 NotebookLM は「 手元資料の正確な再利用 」に、Gemini アプリは「 自由な発想と表現 」に、それぞれ最適なツールです。 目的とシーンに応じて、両者を併用することで業務全体の生産性が大きく向上します。 NotebookLM の主要活用パターン NotebookLM は、業務に埋もれていた「データ」を「知識」に変換し、組織の生産性を一段引き上げるツールです。主な活用パターンは以下のとおりです。 1. ドキュメント・ナレッジ統合管理 散在していた資料や議事録などをノートブック単位で統合管理し、社内用チャット Bot を即座に構築、共有できます。 2. 資料要約・差分分析 複数資料から共通点や差異を抽出し、迅速で正確な意思決定を支援します。 3. 音声・動画から要点自動抽出 会議録音や動画をテキスト化・要約することで、非構造データも業務資産として活用可能となります。 4. FAQ・クイズ自動生成 社内規定やガイドラインから FAQ や確認用クイズを自動生成し、教育・オンボーディングを加速します。 ここからは、各ユースケースの具体例を紹介します。 実務で活きる NotebookLM ユースケース 1. ナレッジの構造化と共有 例 : 営業部での提案書作成 参考 : NotebookLM ヘルプ 特定分野の資料なデータをソースとして設定し、部署やチーム毎のチャット Bot を作成し、業務の属人化を防ぐことできます。 以下手順でソースの設定から行います。 [ソースを追加] から対象資料の形式（Google ドキュメント、PDF 等）を選択してアップロード ファイルのアップロード ※ 当記事のソースは架空のサンプルデータを使用 ※ Google スプレッドシートは直接指定できないため、CSV 形式でダウンロード後に txt ファイルに変換して [ファイルを添付] より追加（2025年5月現在） ソースの追加が完了したら営業部で必要な提案書の叩き台を作成するため、以下のようなプロンプトを送信します。 プロンプト例 : 顧客「石井 亮」様のニーズに合致する物件を「物件リスト」から2つほどピックアップしてください。 また、「【サンプル】営業提案書」を参考にそれぞれの提案書を3ページほどにまとめてください。 AI への質問 このように、顧客ニーズに合った物件の抽出と、テンプレートを参考に提案書が生成されます。 生成された提案書はメモとして保存をしたり、画面下のコピーアイコンからドキュメントに貼り付けも可能です。 右上の「共有」から、グループを追加して部門やチーム間でノートブック自体の展開もできます。 ノートブックの共有 2. 資料の要約・比較による意思決定支援 例 : 競合企業の決算書を比較し、強みと戦略を分析 複数社の決算資料をソースとして PDF ファイルで追加し、以下のようなプロンプトで要約と比較が可能です。 プロンプト例 : 3社の決算書について簡潔に要約してください。 また、それぞれの決算書を元に、各社の強みと企業戦略について比較してください。 AI への質問 計 100 ページ以上の PDFを瞬時に要約・比較が行われ、意思決定に必要なポイントが抽出されます。 アウトプット横の番号をクリックすると、該当ソースへのハイライト確認も可能なため調査時間が短縮します。 ソースの表示 3. 音声・動画データの情報抽出 例① : Youtube 動画を読み込み、機能比較や消費者レビューをレポート化 Google Cloud Next '25 のキーノートなどの YouTube 動画をソースとして追加します。 参考 : www.youtube.com YouTube 動画のデータソース追加 データソースの追加後、2 時間弱にもわたるの長編動画が即座にテキスト化、要約されます。 YouTube 動画の要約 以下のようなプロンプトで、一覧表などの構造化データでの回答も可能です。 プロンプト例 : 紹介されたサービスと機能の一覧を表でまとめてください。 表での要約 また、NotebookLMは 多言語対応のため、ソースが英語動画でも日本語出力されます。 このように従来ブラックボックス化していた非構造データも、検索・活用できるソースとして変換できます。 例② : 音声や動画データから瞬時に議事録を作成 音声や動画データさえあれば、精度の高い議事録を NotebookLM が作成します。 対象データをソースとしてアップロード後、以下のようなプロンプトで会議の要約とタスク整理が可能です。 プロンプト例 : 会議の内容の要約とタスクを箇条書きにした議事録作成を行ってください 会議内容の要約 先ほどと同様、瞬時に音声データをテキスト化し、要点やタスクをまとめた議事録を作成します。 議事録は AI に任せることで、参加者は会議に集中できます。 4. 教育・トレーニング支援 例 : 社内規定やマニュアルから学習ガイドとクイズを自動生成 社内規定やマニュアル等をソースに追加し、［Studio］パネルの［学習ガイド］をクリックすると自動でメモが生成されます。 学習ガイド 学習ガイドの内容 1 クリックでメモを自動生成してくれるので、オンボード用の資料も瞬時に作成できます。 他 Studio 機能を活用することで、以下の自動作成が容易となります。 音声概要 : 会話形式での内容読み上げ　（日本語で生成可能） 学習ガイド : 重要ポイントや理解を深める質問の提案 よくある質問 :想定される質問と回答の生成 タイムライン : 内容の時系列整理 ブリーフィング : 要点を凝縮したメモ作成 中でも最近日本語対応となった 「音声概要」 の精度は高く、AI 生成とは思えないような 2 人のリアルな会話形式でソース内容について議論します。 移動中や作業中にオーディオで内容を把握したい場合に非常に便利です。機能やユースケースの詳細については以下ブログをご参照ください。 blog.g-gen.co.jp 5. 簡易的なチャットボット 例 : 社内規定をノートブックに読み込ませて社内向けの簡易的なチャットボットとして利用 簡易的なチャットボット ノートブックを作成して、社内に閲覧者権限で共有することで、簡易的なチャットボットとして利用できます。 上記のスクリーンショットは今日時にコンテンツを「チャットのみ」とした場合の表示例です。一方で「ノートブックすべて」とすることで、データソースのファイルや生成した音声概要なども含めて共有することができます。 共有コンテンツの選択 NotebookLM vs Gemini アプリの使い分け 既存の業務資料がある程度蓄積されている環境の場合、NotebookLM を導入することで知識活用を加速できます。 NotebookLM と Gemini アプリの以下特徴を理解し柔軟に活用することで、さらなる業務のスピードと精度を両立できます。 NotebookLM は、手元の資料から正確に情報を引き出して再活用するために使う。例 : 議事録の要約、社内FAQの作成、既存資料の再構成、簡易チャットボットなど Geminiアプリ は、既存資料を活かしながら、新しい表現やアイデアを抽出するために使う。例 : 企画書の初稿作成、自由な発想が求められる問いへの回答、クリエイティブな業務支援など 川村真理 (記事一覧) クラウドソリューション部 クラウドサポート課 美容業界からITへ転身。Google Workspace 専任サポートから Google Cloud にも興味が湧き日々奮闘中。海外旅行が大好きで11カ国突破、これからも更新予定

G-gen の佐々木です。当記事では Google Cloud の機械学習ワークフローオーケストレーションツールである Vertex AI Pipelines を解説します。 MLOps と ML パイプラインの必要性 Vertex AI Pipelines パイプラインの定義 2種類のインターフェース Kubeflow Pipelines SDK TensorFlow Extended SDK パイプライン コンポーネント コンポーネントの基本 Google Cloud パイプライン コンポーネント 概要 Google Cloud パイプライン コンポーネントの例 パイプラインの例 カスタムコンポーネント パイプライン テンプレート パイプラインの実行 手動実行 scheduler API によるスケジュール実行 モデルの品質低下をトリガーとした実行 その他 Vertex AI ツールとの連携 料金 料金の基本 billing ID を使用したコスト分析 MLOps と ML パイプラインの必要性 MLOps（Machine Learning Operations） とは、サービスのデリバリー速度や信頼性の向上、関係者間のオーナーシップ構築を目的とする DevOps を、機械学習（ ML ）システムに適用する取り組み・手法です。 ML モデルは、データの収集、加工、トレーニングなどの過程を経て構築され、本番環境でサービングされます。この開発サイクルは通常のソフトウェア開発と異なり、以下のような特性があります。 ML モデルの開発にはデータ加工の手法、アルゴリズム選択、パラメータ構成などの試行錯誤を伴う実験的な性質があり、モデルのトレーニングとテストは 繰り返して行われる ML モデルが予測対象とする世界は絶えず変化し続けており、モデルの予測精度を維持するためには、変化をモニタリングし、必要に応じて新しいデータでモデルを 再トレーニング する必要がある ML パイプラインの必要性 そのため、ML モデルの開発・運用においては DevOps の要素でもある CI/CD のほかに、MLOps 特有の要素である 継続的なモデルのトレーニング （ Continuous Training 、CT）を実現する必要があります。 ML パイプライン は、ML モデルの開発サイクルの各要素を一連のステップとした、CT を実現するための 再利用可能 なパイプラインです。 ML モデルの開発サイクルを内包した再利用可能なパイプライン 参考 : DevOps 参考 : MLOps: Continuous delivery and automation pipelines in machine learning Vertex AI Pipelines Vertex AI は Google Cloud における ML サービスの統合プラットフォームであり、ML ワークロードを展開するための様々なツールが提供されています。 Vertex AI Pipelines は Vertex AI で提供されるツールの1つであり、Google Cloud 上で複雑な ML ワークフローを実行するパイプラインを構築・実行することができます。 ML パイプラインの実行はサーバーレスな環境で実行されるため、ユーザー側でインフラストラクチャの管理やスケーリングの実装をする必要がありません。 また、他の Vertex AI ツールとの連携により、パイプラインのスケジュール実行や、パイプラインで生成されたアーティファクト（加工したデータやモデル、モデルの評価など）の管理・分析、開発したモデルのデプロイなどをシームレスに行うことができます。 参考 : Introduction to Vertex AI Pipelines 参考 : Architecture for MLOps using TensorFlow Extended, Vertex AI Pipelines, and Cloud Build パイプラインの定義 2種類のインターフェース Vertex AI Pipelines では、 DAG （有向非巡回グラフ）としてワークフローを記述し、YAML 形式にコンパイルされたファイルを使用することで、定義された ML パイプラインを実行します。 Vertex AI Pipelines による ML パイプラインのグラフ（公式ドキュメントより） このパイプラインを定義するための Python SDK インターフェースとして、 Kubeflow Pipelines SDK （KFP） と TensorFlow Extended SDK （TFX）の2種類が提供されています。 TensorFlow Extended SDK はテラバイト単位の大規模な構造化データまたはテキストデータを処理する際に推奨されており、それ以外のユースケースではシンプルな記述で柔軟なタスクを処理できる Kubeflow Pipelines SDK の利用が推奨されています。 参考 : Interfaces for Vertex AI Pipelines Kubeflow Pipelines SDK Kubeflow Pipelines SDK は、任意のコンテナイメージや関数をパイプラインの要素（ コンポーネント ）として定義することができるインターフェースです。 TensorFlow や PyTorch、scikit-learn など、様々な ML フレームワークを使用した独自のコンポーネント（カスタム コンポーネント）を開発、管理することができます。 また、Google Cloud パイプライン コンポーネントとして、他の Google Cloud サービスを利用する事前定義済みコンポーネントをパイプライン定義に組み込むこともできます。 参考 : Kubeflow Pipelines - Overview TensorFlow Extended SDK TensorFlow Extended SDK は、スケーラブルかつ高いパフォーマンスを必要とするタスク向けの ML パイプラインを定義するインターフェースです。 TensorFlow、Keras を使用した開発に最適化されており、TensorFlow Data Validation（データ検証）や TensorFlow Transform（前処理）、TensorFlow Model Analysis（モデル評価）といった、典型的な ML タスクを実行する標準コンポーネントを利用することができます。 参考 : The TFX User Guide パイプライン コンポーネント コンポーネントの基本 Vertex AI Pipelines では、データの抽出や加工、モデルのトレーニングやデプロイなどの ML ワークフローの各ステップを コンポーネント として定義し、それを組み合わせることでパイプラインを構成します。 コンポーネントを組み合わせてパイプラインを定義する コンポーネントはデータセットやモデル、ハイパーパラメータなどの入力を受け取って処理を行い、その出力を次のコンポーネントの入力として渡すことができます。 Google Cloud パイプライン コンポーネント 概要 Google Cloud パイプライン コンポーネントは Google によって事前定義されたビルド済み Kubeflow Pipelines コンポーネントであり、Vertex AI の各種ツールや BigQuery、Dataflow といった他の Google Cloud サービスの操作をパイプラインに組み込むことができます。 参考 : Introduction to Google Cloud Pipeline Components Google Cloud パイプライン コンポーネントの例 以下は、Google Cloud パイプライン コンポーネントとして提供されている事前定義コンポーネントの一例です。 コンポーネント 説明 BigqueryQueryJobOp BigQuery でクエリを実行する。 TabularDatasetCreateOp Cloud Storage や BigQuery をデータソースとして、Vertex AI で使用できる表形式データセットを作成する。 AutoMLTabularTrainingJobRunOp AutoML で表形式データセットを使用したトレーニング ジョブを実行する。 BigqueryCreateModelJobOp BigQuery ML によるモデルの作成ジョブを実行する。 CustomTrainingJobOp Vertex AI のカスタム トレーニング ジョブを実行する。 DataflowPythonJobOp Apache Beam Python SDK で記述されたジョブを Dataflow で実行する。 WaitGcpResourcesOp Google Cloud リソースの実行が完了するまで待機する（2025年5月現在、Dataflow ジョブに対してのみ有効）。 DataprocSparkBatchOp Apache Spark のバッチジョブを Dataproc で実行する。 ModelUploadOp モデルを Vertex AI Model Registry にアップロードする。 EndpointCreateOp Vertex AI Endpoints のエンドポイントを作成する。 ModelDeployOp Vertex AI Endpoints のエンドポイントにモデルをデプロイする。 ModelBatchPredictOp 指定したモデルを使用して、Vertex AI Batch Predictions によるバッチ予測を行う。 参考 : Google Cloud Pipeline Components list パイプラインの例 パイプライン定義は Jupyter Notebook 等の開発環境を使用して記述します。 以下は、Google Cloud パイプライン コンポーネントを使用する Kubeflow Pipelines SDK による ML パイプラインの例です。 このパイプラインでは、公開されているデータソースから画像データセットを作成し、AutoML で画像分類モデルのトレーニングを行ったあと、作成したモデルを Vertex AI Endpoints のエンドポイントにデプロイする一連のステップが定義されています。 # Kubeflow Pipelines SDK, Vertex AI Python SDK のインポート import kfp from google.cloud import aiplatform # Google Cloud パイプライン コンポーネントのインポート from google_cloud_pipeline_components.v1.dataset import ImageDatasetCreateOp from google_cloud_pipeline_components.v1.automl.training_job import AutoMLImageTrainingJobRunOp from google_cloud_pipeline_components.v1.endpoint import EndpointCreateOp, ModelDeployOp project_id = "myproject" pipeline_root_path = "gs://mybucket/pipeline-root/path/" # パイプライン定義の例 @ kfp.dsl.pipeline ( name= "automl-image-training-v2" , pipeline_root=pipeline_root_path) def pipeline (project_id: str ): # データセットを作成するコンポーネント ds_op = ImageDatasetCreateOp( project=project_id, display_name= "flowers" , gcs_source= "gs://cloud-samples-data/vision/automl_classification/flowers/all_data_v2.csv" , import_schema_uri=aiplatform.schema.dataset.ioformat.image.single_label_classification, ) # AutoML によるトレーニングを実行するコンポーネント training_job_run_op = AutoMLImageTrainingJobRunOp( project=project_id, display_name= "train-iris-automl-mbsdk-1" , prediction_type= "classification" , model_type= "CLOUD" , dataset=ds_op.outputs[ "dataset" ], model_display_name= "iris-classification-model-mbsdk" , training_fraction_split= 0.6 , validation_fraction_split= 0.2 , test_fraction_split= 0.2 , budget_milli_node_hours= 8000 , ) # Vertex AI Endpoints のエンドポイントを作成するコンポーネント create_endpoint_op = EndpointCreateOp( project=project_id, display_name = "create-endpoint" , ) # エンドポイントにモデルをデプロイするコンポーネント model_deploy_op = ModelDeployOp( model=training_job_run_op.outputs[ "model" ], endpoint=create_endpoint_op.outputs[ 'endpoint' ], automatic_resources_min_replica_count= 1 , automatic_resources_max_replica_count= 1 , ) トレーニングとモデルのデプロイを行うパイプラインの例 パイプライン定義は、以下のように YAML 形式にコンパイルし、Vertex AI Pipelines で実行可能な状態にします。 from kfp import compiler compiler.Compiler().compile( pipeline_func=pipeline, # 定義したパイプライン package_path= 'image_classif_pipeline.yaml' ) YAML ファイルにはパイプラインの実行に必要な情報がすべて含まれます。以下はこの例で作成できる YAML ファイルの一部抜粋です。 # PIPELINE DEFINITION # Name: automl-image-training-v2 # Inputs: # project_id: str components : comp-automl-image-training-job : executorLabel : exec-automl-image-training-job inputDefinitions : artifacts : base_model : artifactType : schemaTitle : google.VertexModel schemaVersion : 0.0.1 description : Only permitted for Image Classification models. If it is specified, the new model will be trained based on the `base` model. Otherwise, the new model will be trained from scratch. The `base` model must be in the same Project and Location as the new Model to train, and have the same model_type. isOptional : true dataset : artifactType : schemaTitle : google.VertexDataset schemaVersion : 0.0.1 description : The dataset within the same Project from which data will be used to train the Model. The Dataset must use schema compatible with Model being trained, and what is compatible should be described in the used TrainingPipeline's [ training_task_definition ] [ google.cloud.aiplatform.v1beta1.TrainingPipeline.training_task_definition ] . For tabular Datasets, all their data is exported to training, to pick and choose from. # 以下省略 参考 : Build a pipeline カスタムコンポーネント Kubeflow Pipelines SDK では、ユーザーが記述した処理を カスタムコンポーネント としてパイプラインに組み込むことができます。 以下の例では、入力された2つの数値を加算するコンポーネントと、入力された数値をログに出力するコンポーネントの2つを作成し、それらを順に実行するパイプラインを定義しています。 from kfp import dsl pipeline_root_path = "gs://mybucket/pipeline-root/path/" # 入力された2つの数値を加算するカスタムコンポーネント @ dsl.component ( base_image= 'python:3.12' , # コンポーネントを実行するコンテナイメージ packages_to_install=[ 'google-cloud-storage' ] # 必要に応じてライブラリを追加できる（この例では使用しない） ) def add_numbers ( num1: float , # 入力パラメータ1 num2: float # 入力パラメータ2 ) -> float : # 2つの数値を加算する print (f "Adding {num1} and {num2}" ) result = num1 + num2 print (f "Result: {result}" ) return result # 計算結果を出力として返す # 入力された数値を出力するカスタムコンポーネント @ dsl.component ( base_image= 'python:3.12' ) def print_result ( result_value: float # 入力パラメータ ): # 受け取った数値を表示する print (f "The final result is: {result_value}" ) # パイプライン定義 @ dsl.pipeline ( name= 'custom-component-pipeline-sample' , description= 'A simple pipeline using custom components.' , pipeline_root=pipeline_root_path ) def my_custom_pipeline ( input1: float = 10.5 , # パイプラインの入力パラメータ (デフォルト値) input2: float = 5.2 ): # ステップ 1: add_numbers コンポーネントを実行 add_task = add_numbers(num1=input1, num2=input2) # ステップ 2: print_result コンポーネントを実行 # 前のステップ (add_task) の出力を、次のステップの入力として渡す print_task = print_result(result_value=add_task.output) Build your own pipeline components パイプライン テンプレート Kubeflow Pipelines SDK で定義されたパイプラインは、 パイプライン テンプレート として Artifact Registry リポジトリにアップロードすることができます。 アップロードしたテンプレートは複数のユーザー、パイプラインが再利用することができます。 Kubeflow Pipelines テンプレートを管理するリポジトリを作成する 以下のコードでは、Google Cloud パイプライン コンポーネントの例で作成した YAML ファイルを、パイプライン テンプレートとしてアップロードしています。 from kfp.registry import RegistryClient # テンプレートのアップロード先リポジトリの指定 client = RegistryClient(host=f "https://asia-northeast1-kfp.pkg.dev/myproject/vertexai-pipelines-template" ) # テンプレートのアップロード templateName, versionName = client.upload_pipeline( file_name= "image_classif_pipeline.yaml" , tags=[ "v1" , "latest" ], extra_headers={ "description" : "This is an example pipeline template." }) リポジトリにアップロードしたテンプレートは、パイプラインの実行時に指定することができます。 テンプレートを使用してパイプラインを実行する また、 テンプレート ギャラリー には Google が作成したパイプライン テンプレートが用意されており、一般的なユースケースのパイプラインをそのまま実行したり、独自のパイプラインに組み込んで利用したりできます。 Google が作成したパイプライン テンプレートを使用する 参考 : Create, upload, and use a pipeline template 参考 : Use a prebuilt template from the Template Gallery パイプラインの実行 手動実行 パイプラインは Vertex AI SDK for Python や Google Cloud コンソールを使用して実行することができます。 以下のコードは、Google Cloud パイプライン コンポーネントの例で作成したパイプラインを、Jupyter Notebook から実行しています。 import google.cloud.aiplatform as aip aip.init( project= "myproject" , location= "asia-northeast1" , ) # 実行するパイプラインの設定 job = aip.PipelineJob( display_name= "automl-image-training-v2" , template_path= "image_classif_pipeline.yaml" , # コンパイルした YAML ファイル pipeline_root=pipeline_root_path, parameter_values={ 'project_id' : project_id } ) # パイプラインの実行 job.submit() パイプラインの実行は Google Cloud コンソールからモニタリングすることができます。 パイプラインのモニタリング画面 scheduler API によるスケジュール実行 scheduler API を使用することで、ML パイプラインの実行をスケジューリングすることができます。 これにより、モデルの再トレーニングを定期的に実行し、ドリフトによるモデルの品質低下などの問題に対処することができます。 パイプラインのスケジュール実行は、 Vertex AI SDK for Python や Google Cloud コンソールを使用して設定できます。 コンソールからパイプラインのスケジュール実行を設定する 参考 : Schedule a pipeline run with scheduler API モデルの品質低下をトリガーとした実行 Vertex AI Model Monitoring を使用すると、Vertex AI Endpoints 等で運用中のモデルに対してモニタリングを行うことができます。 モニタリングの例として、予測の際に入力された特徴データや、予測の結果をベースラインのデータ分布と比較し、分布の変化（ドリフト）があった場合にアラート通知を行うことができます。 分布の変化が閾値を超えた場合、Cloud Logging にログとして出力されます。これを Pub/Sub、Cloud Run Functions に連携することで、ドリフトによるモデルの品質低下をトリガーとしたパイプラインの実行を実現することができます。 参考 : Introduction to Vertex AI Model Monitoring その他 Vertex AI ツールとの連携 Vertex AI で提供されている各種ツールは、Vertex AI Pipelines と連携し、ML パイプラインを中心とする MLOps の実現に役立てることができます。 Vertex AI の各ツールが Vertex AI Pipelines とどのように連携されるかを以下に示します。 ツール 説明 Vertex AI Feature Store ML モデルのトレーニングや予測で使用する 特徴データを一元管理 するツール。 BigQuery をデータソースとする特徴データを ML パイプラインやデプロイ済みのモデルに対して効率的にサービングすることができる。 Vertex ML Metadata ML パイプラインで入力されたパラメータや出力されたアーティファクト、指標などを記録することができる。 パイプラインの実行ごとの分析や、アーティファクトの リネージの追跡 のほか、記録されたパラメータを使用してパイプラインを再実行したい場合などに使用できる。 Vertex AI Experiments ML モデル開発における実験プロセスを追跡・比較するための 実験管理 のためのツール。 試行錯誤的に実行される ML パイプラインを追跡・記録することで、最適なモデルを作り出すパイプラインを特定するための分析を行うことができる。 Vertex AI TensorBoard 実験プロセスで記録された各指標を 可視化 するためのツール。 ML モデルのトレーニング時に記録される損失や精度などの評価指標や、モデルの重み、バイアスなどパラメータの変化をリアルタイムに可視化することができる。 Vertex AI Model Registry ML パイプラインで構築したモデルを バージョン管理 するリポジトリとして使用する。 リポジトリで管理されているモデルはバッチ予測に直接使用したり、Vertex AI Endpoints にデプロイしたりできる。 Vertex AI Batch Predictions トレーニング済みのモデルを使用して、非同期の バッチ予測 を実行することができる。 Vertex AI Endpoints モデルをエンドポイントにデプロイし、 オンライン（リアルタイム）予測 を実行できるようにする。 エンドポイントはパイプラインから直接作成することができる。 Vertex AI Model Monitoring 運用中のモデルに対するモニタリングを実行するツール。モデルのトレーニング時のデータ分布をベースラインとし、入力されたデータの分布や予測結果の分布が異なる ドリフトを検出 できる。 Cloud Logging、Pub/Sub と連携することでモデルの品質低下のアラートを発行することができる。 Vertex AI Pipelines と他ツールの連携イメージ 料金 料金の基本 Vertex AI Pipelines では、メインの課金要素として、 各コンポーネントから使用するリソースの使用量に応じた料金 が発生します。また、ML パイプラインの実行ごとに $0.03 の実行料金が発生します。 例えば、パイプラインのコンポーネントとして AutoML のトレーニングを実行した場合は AutoML の料金が発生します。Vertex AI 以外のサービスでも、BigQuery や Dataflow のジョブをコンポーネントから実行した場合は、ジョブ実行に伴う料金が発生します。 このように、パイプラインの実行に伴う料金は Vertex AI 以外の複数のサービスに対して発生する可能性があり、Cloud Billing からパイプライン全体の料金を把握するのが若干難しいことに注意が必要です。 参考 : Vertex AI pricing billing ID を使用したコスト分析 Vertex AI Pipelines は、パイプライン実行時に一意の billing ID を生成します。この ID をコンポーネントから使用される Google Cloud リソースのラベルとして紐づけることができます。 ラベルが付与されたリソースの利用料金は、Cloud Billing の課金レポートでフィルタして確認することができます。 また、Cloud Billing から請求情報を BigQuery にエクスポートし、billing ID を使用してクエリを実行することで、パイプライン実行ごとの料金を確認することができます。 ラベルは、Google Cloud パイプライン コンポーネントから作成されたリソース（Dataflow リソースを除く）に対して自動で付与されます。Dataflow リソースや、カスタムコンポーネントから作成されたリソースに対しては、ラベルを紐づけるための記述をコンポーネント定義に含める必要があります。 参考 : Understand pipeline run costs 参考 : Resource labeling by Vertex AI Pipelines 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では、 従来の Application Load Balancer （classic Application Load Balancer）リソースを、新しい Application Load Balancer である グローバル外部 Application Load Balancer に安全に移行する方法を解説します。 前提知識 Application Load Balancer の比較 基本的な違い グローバル外部 Application Load Balancer でサポートされる機能 グローバル外部 Application Load Balancer ではサポートされない機能 移行の手順 当記事で使用する環境 バックエンド サービスの移行 移行の準備 移行のテスト 移行の実施 バックエンド バケットの移行 転送ルールの移行 移行の準備 移行のテスト ロールバック ロールバックの概要 転送ルールのロールバック バックエンド バケットのロールバック バックエンド サービスのロールバック 前提知識 外部 Application Load Balancer の基本については、以下の記事をご一読ください。 blog.g-gen.co.jp Application Load Balancer の比較 基本的な違い 従来の Application Load Balancer （classic Application Load Balancer）と新型である グローバル外部 Application Load Balancer は、どちらも Google Front End（GFE）と呼ばれる Google 管理のインフラストラクチャ上で動作するマネージドなロードバランサー機能です。 グローバル外部 Application Load Balancer ではデータプレーンに OSS の Envoy プロキシを採用しており、このデータプレーンの違いによって、従来型と比べてイベントに対する応答などが異なる場合があります。 たとえば、ロードバランサーのバックエンドにあるサービスのステータスがすべて正常ではない場合、従来の Application Load Balancer ではステータス 502 が返されますが、グローバル外部 Application Load Balancer ではステータス 503 が返されるようになっています。 以下のドキュメントにデータプレーンによる動作の違いがまとまっているため、従来型からの移行を行う場合は目を通しておきましょう。 参考 : Increasing Resiliency with Load Balancers グローバル外部 Application Load Balancer でサポートされる機能 グローバル外部 Application Load Balancer は以下のような機能を利用することができます。 ホスト、パス、ヘッダー、リクエストパラメータなどに基づくトラフィックのインテリジェントなルーティング リクエストベース、レスポンスベースのアクション（リダイレクト、ヘッダー変換など）の実行 リクエストミラーリングなどの高度な負荷分散アルゴリズム 機能の詳細については、以下のドキュメントをご一読ください。 参考 : Traffic management overview for global external Application Load Balancer グローバル外部 Application Load Balancer ではサポートされない機能 グローバル外部 Application Load Balancer では利用できず、従来の Application Load Balancer でしか利用できない機能としては、以下のようなものがあります。 Standard ティアのネットワーク（リージョナル ロードバランサー） GKE Ingress Controller これらを利用したい場合、従来の Application Load Balancer を引き続き使用します。 なお、GKE でグローバル外部 Application Load Balancer を利用したい場合は、Ingress の変わりに Gateway リソースを使用することができます。 参考 : Network Service Tiers overview 参考 : About the Gateway API ただし、従来の Application Load Balancer は今後、機能アップデートがされなくなったり、廃止になる可能性がゼロではありません。可能な限り、新しいグローバル外部 Application Load Balancer の使用を検討したほうが望ましいといえます。 移行の手順 当記事で使用する環境 当記事は、以下の記事と同様の構成、つまり Cloud Run のフロントエンドとして Application Load Balancer を構成している環境を利用します。 blog.g-gen.co.jp この環境では、バックエンド サービスに Cloud Armor のセキュリティポリシーを紐づけ、また Identity-Aware Proxy（IAP）による認証機能を利用できるようにしています。 ロードバランサーの移行により、これらの機能の紐づけが維持されるかどうかも確認してみます。 当記事で使用する環境 移行対象となる従来の（クラシック）Application Load Balancer バックエンド サービスで Cloud Armor セキュリティポリシーと IAP を利用している バックエンド サービスの移行 移行の準備 ロードバランサーの移行は Google Cloud コンソールと gcloud CLI で実施することができます。当記事では基本的にはコンソールから操作を行っていきます。 ロードバランサーの移行手順として、バックエンド サービスの移行と転送ルールの移行をそれぞれ行う必要があります。まずはバックエンド サービスの移行を行っていきます。 ロードバランサーの詳細画面にある「移行」タブから、対象バックエンド サービスの「移行を管理」を選択します。 「移行」タブで対象バックエンド サービスの「移行を管理」を選択する 「準備」にチェックがついているので、そのまま「保存」を選択します。 「準備」にチェックが入った状態で「保存」を選択する ロードバランサーの更新が行われ、バックエンド サービスのステータスが「テスト準備完了」となります。 移行のテスト バックエンド サービスのステータスが「テスト準備完了」となっている状態で、「移行を管理」を再度選択します。 ステータスが「テスト準備完了」のバックエンド サービスの「移行を管理」を選択する 移行のテストは、「割合を指定してテスト」と「すべてのトラフィックをテスト」の2種類を選択することができます。 「割合を指定してテスト」では、任意の割合のトラフィックを新しいバックエンド サービスにルーティングすることで、従来のロードバランサーのバックエンド サービスで引き続きトラフィックを処理しつつ、一部のトラフィックのみで新しいバックエンド サービスのテストを行うことができます。 当記事では、10%のトラフィックを新しいバックエンド サービスにルーティングしてテストを行います。「割合を指定してテスト」にチェックを入れ、「テストの割合」に 10 を入力して「保存」を選択します。 10%のトラフィックで新しいロードバランサーのテストを行う ロードバランサーの更新が行われ、バックエンド サービスがテスト中の状態になります。新しいバックエンド サービス（EXTERNAL_MANAGED）に10%のトラフィックがルーティングされる状態になっています。 バックエンド サービスが「テスト中」のステータスになる トラフィックの割合はテスト中に変更することができます。ここでは「すべてのトラフィックをテスト」に変更してみます。 すべてのトラフィックを新しいバックエンド サービスにルーティングしてテストを行う 新しいバックエンド サービスにすべてのトラフィックがルーティングされる状態になりました。 「すべてのトラフィックをテスト」を選択した場合 サービスの URL にアクセスしてみると、移行先のバックエンド サービスでも IAP による認証が機能していることがわかります。 新しいバックエンド サービスにルーティングされても IAP の認証画面が表示される また、Cloud Armor のセキュリティポリシーが機能しているかどうかも確認してみます。 当記事の構成ではアクセス元の IP アドレスを制限していますが、許可されていない IP アドレスからサービスにアクセスすると、セキュリティポリシーによってアクセスが拒否されます。 新しいバックエンド サービスでもセキュリティポリシーが機能している 移行の実施 トラフィックが新しいロードバランサーで正しく処理されていることを確認したら、バックエンドの移行を行います。 対象バックエンド サービスの「移行を管理」から、「移行」にチェックを入れて「保存」を選択します。 バックエンド サービスの移行を行う ロードバランサーが更新され、バックエンド サービスのステータスが「移行済み」になります。 バックエンド サービスのステータスが「移行済み」になる バックエンド サービスが複数ある場合は、ここまでの手順を繰り返し行います。 バックエンド バケットの移行 ここまででバックエンド サービスの移行を行いましたが、ロードバランサーでバックエンド バケットを使用している場合、転送ルールの移行の前にバックエンド バケットの移行を行う必要があります。 2025年5月現在、バックエンド バケットの移行はコンソールから行うことができず、gcloud CLI を使用する必要があります。詳細なコマンドについては以下のドキュメントを参照してください。 参考 : Migrate resources from classic to global external Application Load Balancer - Migrate the backend bucket 転送ルールの移行 移行の準備 バックエンド サービス同様に、転送ルールでも「準備」→「テスト」→「移行」の流れで作業を行っていきます。 対象の転送ルールの「移行を管理」を選択します。 対象の転送ルールの「移行を管理」を選択する 「準備」にチェックがついているので、そのまま「保存」を選択します。 「準備」にチェックがついている状態で「保存」を選択する 移行のテスト 転送ルールのステータスが「テスト準備完了」になるので、再度「移行を管理」を選択します。 転送ルールのステータスが「テスト準備完了」になったら再度「移行を管理」を選択する バックエンド サービスの移行と同様に、移行のテストは「割合を指定してテスト」と「すべてのトラフィックをテスト」の2種類を選択することができます。 当記事では、ここでは最初から「すべてのトラフィックをテスト」を選択してテストを行います。 実施するテスト方法にチェックを入れて「保存」を選択する 転送ルールのステータスが「テスト中 / すべてのトラフィックをテスト中」になったら、サービスに対してアクセスしてみます。 転送ルールのステータスが「テスト中 / すべてのトラフィックをテスト中」になっている バックエンド サービスのテスト時同様、サービスに正常にアクセスすることができ、かつ IAP や Cloud Armor が機能していることを確認します。 転送ルールの移行テスト中でも IAP が機能している 転送ルールの移行テスト中でも Cloud Armor のセキュリティポリシーが機能している 問題なければ、再度「移行を管理」を選択します。 「移行」にチェックを入れて「保存」を選択すると、転送ルールの移行が実施されます。 転送ルールの移行を行う これでバックエンド サービスと転送ルールの両方が移行済みとなり、従来の Application Load Balancer からグローバル外部 Application Load Balancer への移行は完了となります。 ロードバランサーの移行が完了している状態 ロードバランサーの種類が従来（クラシック）ではなくなっている 移行後も Cloud Armor セキュリティポリシーや IAP の設定が維持されている ロールバック ロールバックの概要 移行から90日以内 であれば、従来の Application Load Balancer へのロールバックを行うことができます。 ロールバックは移行とは逆の順番（「転送ルールのロールバック」→「バックエンド バケットのロールバック」→「バックエンド サービスのロールバック」）で行います。 参考 : Roll back migrated resources to classic Application Load Balancer 転送ルールのロールバック 2025年5月現在、転送ルールのロールバックは gcloud CLI で実施する必要があります。以下のコマンドでロールバックを行います。 # 転送ルールのロールバック $ gcloud compute forwarding-rules update { 転送ルールの名前 } \ --load-balancing-scheme = EXTERNAL \ --global バックエンド バケットのロールバック バックエンド バケットがある場合は、こちらも gcloud CLI でロールバックを行う必要があります。 ロールバックは「テスト」→「移行」のステップで行います。詳細なコマンドは以下のドキュメントを参照してください。 参考 : Roll back migrated resources to classic Application Load Balancer - Roll back the backend bucket バックエンド サービスのロールバック バックエンド サービスのロールバックは「テスト」→「移行」の順に行います。 転送ルールのロールバックが完了していると、コンソールではバックエンド サービスで「元に戻す」が選択できるようになっています（gcloud CLI でもロールバック可能）。 コンソールからロールバックする場合、転送ルールのロールバック後にバックエンド サービスの「元に戻す」を選択する まず、「元に戻す」から「すべてのトラフィックでテストする」にチェックが入っている状態で「保存」を選択します。この時点ではまだトラフィックの移行は行われず、移行後（ロールバック前）のバックエンド サービスにトラフィックがルーティングされています。 バックエンド サービスのロールバックの準備をする まだトラフィックは移行されていない（ロールバックされていない） 6分程度待ってから、バックエンド サービスの「移行を管理」を選択します。 ロールバック前に、トラフィックの割合を指定したテストを行います（※「すべてのトラフィックをテスト」では移行後のバックエンド サービスにトラフィックがルーティングされるため注意）。 テストの割合を指定するとき、指定する割合が 移行後（ロールバック前）のバックエンド サービス にルーティングする割合である点に注意します。たとえば移行前（ロールバック後）のバックエンド サービスに10%のトラフィックをルーティングしたい場合は 90 を入力します。 ロールバック前にテストを行う テストの割合を90に指定した場合 注意点として、6分程度待つことなくテストや移行を実行すると、以下のエラーが発生してしまう場合があります。 Invalid value for field 'resource.externalManagedMigrationState': 'TEST_BY_PERCENTAGE'. External managed migration state cannot be change to TEST_BY_PERCENTAGE yet. Please allow at least 6 minutes for previous change to propagate. 6分程度待たずにテスト / ロールバック を実行しようとするとエラーが発生する ここからさらに6分程度待ち、バックエンド サービスが問題なく動作しているかを確認します。 その後、「移行を管理」からテストの割合を 0 に設定することで、移行前（ロールバック後）のバックエンド サービスにすべてのトラフィックをルーティングします。 すべてのトラフィックを移行前のバックエンド サービスにルーティングする この時点で、ロードバランサーの種類は従来の（クラシック）Application Load Balancer にロールバックされています。 従来の（クラシック）ロードバランサーにロールバックされている しかし、この状態ではバックエンド サービスの移行状態が「テスト中」のままとなります。 ロールバックは完了しているが、移行状態が「テスト中」のままになっている このままでもロードバランサー全体の動作に影響はありませんが、gcloud CLI で移行状態を元に戻します。 まず、バックエンド サービスのステータスをテスト前の状態である「テスト準備完了」にします。 # バックエンド サービスの移行状態を「テスト準備完了」にする $ gcloud compute backend-services update { バックエンド サービスの名前 } \ --external-managed-migration-state = PREPARE \ --global バックエンド サービスのステータスを「テスト準備完了」に戻す 6分程待ってから、バックエンド サービスのステータスを移行作業を始める前の「未開始」に戻します。 # バックエンド サービスのステータスを「未開始」にする（移行前の状態） $ gcloud compute backend-services update { バックエンド サービスの名前 } \ --clear-external-managed-migration-state \ --global これで、「移行」タブの情報がロードバランサーの移行を実施する前の状態に戻ります。 「移行」タブの情報が移行前の状態に戻っている 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の荒井です。当記事では、Gmail におけるメール送受信のトラブルシューティング観点を解説します。 はじめに メールの仕組み（送受信経路） トラブルシューティングの観点 トラブルの原因は自社システムだけではないことを理解する どこまで到達しているか確認する ログからアクションを確認する トラブルシューティング方法 すべてのメールを確認 エラーメールの調査 メールログの調査 DNS レコード設定の確認 メール送信者のガイドラインの確認 社内ネットワークやパソコンの設定確認 その他トラブルシューティング はじめに メールのトラブルシューティングを行う上で最も重要なのは、メールのシステムや仕組みを正しく理解することです。仕組みを理解することで、障害箇所の特定やトラブルの解決を素早く行うことができます。 当記事では、まずメール送受信の仕組み、および経由するネットワークやシステムについて解説します。次に、トラブルシューティングの観点やトラブルシューティング方法を紹介します。 メールの仕組み（送受信経路） メールの送受信経路はおおまかに、以下のとおりです。 メール送信者がメールソフト（Web メール）でメールを新規作成し送信 メールサーバー（送信側）を中継し、DNS サーバーへ問い合わせを行い MX レコードから宛先メールサーバーを特定 メールサーバー（送信側）からインターネット経由でメールサーバー（受信側）へ送信 受信側メールサーバーにメールが到達 メール受信者がメールサーバーに届いたメールを閲覧 このように、メールはインターネットを含め各社ネットワークやシステムを経由して送信者から受信者へ届きます。この送受信経路を踏まえて、トラブルシューティングを行う必要があります。 トラブルシューティングの観点 トラブルの原因は自社システムだけではないことを理解する メールは送信側ネットワークやシステムから送信され、インターネットを超えて受信側ネットワークやシステムに届きます。 メールは自社システムだけで完結しない 点が重要です。したがって、メールに関するトラブルシューティングは、自社システムだけで解決できない場合があります。 トラブルシューティングの際は、メール送受信経路全体を捉え、送信側と受信側両方のネットワークやシステムを調査します。 どこまで到達しているか確認する 前述の通り、メールはインターネット、送信側ネットワーク、受信側ネットワークといったネットワークを経由します。到達している箇所により、調査実施者や対応方法は異なります。そのため、メールがどこまで到達しているか把握できれば、対応方針や対策の判断材料となります。 例 : 送信側メールサーバーから送信されているか否か（送信が成功していれば、受信側メールサーバーの調査が必要） 例 : 受信側メールサーバーで受信しているか否か（受信ログがない場合、送信側メールサーバーの調査が必要） ログからアクションを確認する メールが到達した箇所でどのようなアクションが実行されたかを確認できれば、対応方針を決定できます。送信側で確認できるのは送信メールサーバーのログまでです。メールが問題なく送信された場合、受信側での状況（ログを含む）を確認するため受信側への依頼が必要です。送信側から受信メールサーバーのログを直接確認することはできません。 まずは送信側メールサーバーログから、メールに対してどのようなアクションが行われたかを確認します。 例 : 送信側メールサーバーで送信制限ポリシーがあり、送信されていない（送信できていないため、送信側メールサーバーの調査が必要） 例 : 受信側メールサーバーで迷惑メール判定がされている（受信は出来ているため、受信側メールサーバーの調査が必要） トラブルシューティング方法 すべてのメールを確認 メールが届かないトラブルで最もよくあるのは、受信したメールが 迷惑メール に分類されている、または フィルタ で仕分けされ受信トレイに入っていないケースです。 Gmail のフィルタでは受信トレイをスキップし、ラベルを付与して整理することができます。そのため意図せず受信メールにフィルタが適用され受信トレイに入らないケースがあります。こうした場合 Gmail では すべてのメール または 迷惑メール を確認します。 すべてのメールにはフィルタされた受信メールや送信メールなど、そのメールアドレスで送受信したメールすべてが入ります（迷惑メールに分類されたメールはすべてのメールに含まれません）。次に迷惑メールフォルダを確認します。 メールが届かない場合 Gmail ではまず、 すべてのメール と 迷惑メール を確認するのが基本です。 参考 : Gmail のメールが見つからない - パソコン - Gmail ヘルプ エラーメールの調査 メールが正常に送信されなかった場合、エラーメールが配信されることがあります。エラーメールにはエラーコードが含まれている可能性が高いです。エラーコードがある場合、エラーコードから詳細内容を確認して対応します。 参考 : SMTP エラー メッセージについて - Google Workspace 管理者 ヘルプ 参考 : Gmail の SMTP に関するエラーとコード - Google Workspace 管理者 ヘルプ またエラーメールは英語で配信される場合もあります。Gmail には翻訳機能があるため、まず翻訳機能を使用して内容を確認します。原因がすぐに判明することがあります。 翻訳前 翻訳後 参考 : Gmail のメッセージを翻訳する - パソコン - Gmail ヘルプ メールログの調査 メールログの確認は、トラブルシューティングの基本です。Gmail 管理者はメールログから 「いつ」「誰が」「どこへ」「メールを送信・受信」「成功・失敗」 を確認できます。 メールのトラブル報告を受けた場合、Gmail 管理者はまずメールログを確認します。調査できるメールログは、自社が管理するメールサーバーのものだけです。相手側メールサーバーのログを確認するには、相手方へ依頼する必要があります。 Gmail ではメールログ検索を使用してメールログを確認します。 詳細なログ調査手順は、公式ドキュメントを参照してください。 参考 : メールログ検索を使用してメールを検索する - Google Workspace 管理者 ヘルプ Google Workspace の Enterprise Plus エディション や一部 Education エディション では、より詳細なログとして Gmail のメール や Gmail のログイベント を検索できます。対象エディションでは、トラブルシューティング時にこれらログの確認を推奨します。 それぞれのログではメールログ検索に比べ、ヘッダー情報やメッセージの内容を確認できます。 参考 : Gmail のメール - Google Workspace 管理者 ヘルプ 参考 : Gmail のログイベント - Google Workspace 管理者 ヘルプ DNS レコード設定の確認 受信者までメールは届くが、受信者側で迷惑メールフォルダに入ってしまう、または証明書の警告が表示される。といった事象が発生した場合は、自社ドメインを管理している DNS サーバーの設定を確認します。 SPF レコードや DKIM レコードが設定されていない場合、こうした事象が発生することがあります。 blog.g-gen.co.jp メール送信者のガイドラインの確認 特にメールの送信先が個人用 Gmail アカウント（ @gmail.com など）である場合は、 メール送信者のガイドライン を確認します。 Google が指定する要件を満たしていない場合、メールが拒否されたり、迷惑メールに分類されたりする可能性があります。 詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 社内ネットワークやパソコンの設定確認 Gmail 以外の観点として、社内ネットワークやパソコンの設定でもメールトラブルは発生します。 例 : パソコンや社内ネットワークのファイアウォールで Gmail サービスやメール通信が制限されている 例 : メールソフトのプロファイル設定（接続設定）が誤っている こうした場合メールの送受信はもちろん失敗しますが、社内ネットワークやパソコンの設定が原因でメール送受信が失敗するため、メールサーバーまでメールが到達しません。 送信したのにメールサーバーにログが残っていない、メールサーバーでは受信ログがあるのにメールソフトでは受信ができない。といった事象が発生した際は、社内ネットワークやパソコンの設定を確認してください。 その他トラブルシューティング Gmail ではトラブルシューティングに関する公式ドキュメントが豊富に準備されています。関連ドキュメントを確認し、心当たりがある場合は詳細ページを参照してください。 参考 : Gmail に関する問題 - Google Workspace 管理者 ヘルプ Gmail を含む Google Workspace のトラブルシューティングに関する他の情報は、以下の記事を参照してください。 blog.g-gen.co.jp 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 ・Google Cloud 認定資格 7冠 最近ハマっていることは、息子とのポケモンカード Follow @arapote_tweet

G-gen の荒井です。当記事では Google Cloud および Google Workspace で障害が発生した際のサービスステータス確認方法や、関連コミュニティの活用方法について解説します。 はじめに サービスステータス 責任共有モデル 1. Google サービスのステータス確認 概要 Google Cloud Google Workspace 特定範囲の障害情報 SNS 情報の確認 2. サポート窓口へ問い合わせ 概要 Google Cloud Google Workspace コミュニティの活用 概要 Google Cloud Google Workspace 非公式コミュニティ G-gen Tech Blog での情報収集 はじめに サービスステータス Google Cloud と Google Workspace（以下、Google サービス）を利用中に障害が発生した場合、技術的なトラブルシューティングを行う前に、まず サービスステータス （サービスの提供状況）を確認することが推奨されます。平時から、サービスステータスの確認方法を把握しておくことが重要です。 また、公式の障害情報では確認できないものの、実際に障害が発生しているケースもあります。このような公式情報にない事象については、コミュニティで他ユーザーの障害情報を検索することが有効です。またバグの問題提起や機能リクエストを行うツールも用意されているため、こちらも合わせて説明します。 責任共有モデル Google Cloud では OS やアプリケーションなど自社管理の仕組みは自社で障害特定を進める必要があります。当記事では、これらのレイヤの調査方法やトラブルシューティングの解説は割愛します。 Google Cloud で、クラウド提供事業者（Google）とユーザーの責任分界点を示すモデルである 責任共有モデル は、以下のドキュメントに記載されています。なお Google Cloud では従来の責任共有モデルを一歩推し進め、 運命の共有 （shared fate）という考え方を採用しています。 使用するクラウド サービスの種類（IaaS、PaaS、SaaS、FaaS）を確認し、 顧客の責任 （Customer responsibility）として示されている領域は、自社で対応する必要があります。 参考 : Google Cloud における責任と運命の共有  |  Cloud Architecture Center 1. Google サービスのステータス確認 概要 障害ステータス調査の基本は、まずはじめに公式情報を確認し、Google サービスのクラウド基盤で障害が発生しているか確認することです。 Google サービスには公式で Service Health ページが用意されています。 Google Cloud Google Cloud に関するステータス情報は Service Health に集約されています。全ロケーション、全プロダクトの重要な障害が確認できます。 Service Health は RSS フィードに対応していますが、メールで新着情報を受信することはできません。 参考 : Google Cloud Service Health Service Health には広範囲かつ重要な障害が記載されますが、すべての障害情報を網羅しているわけではありません。また自身が運用しているプロダクトの障害情報だけを知りたいケースも多くあります。そういった場合、 Personalized Service Health を使用して、障害情報をパーソナライズ化します。 参考 : Personalized Service Health の概要  |  Google Cloud Personalized Service Health の詳細については、以下の記事を確認してください。 blog.g-gen.co.jp Google Workspace Google Workspace に関するステータス情報は Google Workspace ステータス ダッシュボード に集約されています。コアサービスに関する障害情報はすべて確認ができます。 Google Workspace ステータス ダッシュボード は RSS フィードに対応していますが、メールで新着情報を受信することはできません。 参考 : Google Workspace Status Dashboard コアサービスの詳細は以下のドキュメントから確認できます。Google App Script や API などはコアサービスではないため、 Google Workspace ステータス ダッシュボード には情報がありません。 参考 : サポート範囲 - Google Workspace 管理者 ヘルプ 参考 : Google Workspace 利用規約 - Google Workspace 特定範囲の障害情報 Service Health や Google Workspace ステータス ダッシュボード では、重大なインシデントを中心に情報が掲載されます。そのため特定のリソースや一部ユーザーにのみ影響がある障害は情報がない場合があります。 そうした場合、 Google Cloud サポートポータル （システム ステータス）から特定範囲の障害情報を確認できる場合があります。 参考 : Google Cloud Service Health のインシデントをモニタリングする  |  Support Documentation 参考 : Google Cloud サポート ポータル SNS 情報の確認 障害がサービス基盤全体の障害か、自身の環境のみで発生しているかどうか切り分けるには SNS を確認するのも有効な手段の一つです。 Downdetector では、SNS の情報から障害情報を可視化しているため、他ユーザーの障害状況も確認できます。 なお Downdetector は公式情報をデータソースとしておらず、あくまで SNS をデータソースとしているため、情報が正確ではない可能性があります。参考情報として捉えてください。 参考 : Downdetector 2. サポート窓口へ問い合わせ 概要 「1. Google サービス基盤のステータス確認」で障害情報が確認できない場合、Google のサポート窓口に問い合わせを行うことで、詳細な情報確認を行うことができる場合があります。 なお Google Cloud や Google Workspace のパートナー企業は、優先的に障害情報を得られていない場合も多くあります。そのため、障害によるビジネス影響が大きい場合は、パートナー企業のサポート窓口より先に Google のサポート窓口に直接問い合わせることが、障害情報取得の最短経路となる場合もあります。 サポート窓口から素早く回答をもらうためのコツについては、以下の記事を確認してください。 blog.g-gen.co.jp Google Cloud Google Cloud の公式の技術サポート窓口は カスタマーケア と呼ばれます。パートナー企業と請求代行サービスを契約しているユーザーは、契約についてパートナー企業へ確認してください。 参考 : Google Cloud カスタマーケア Google Workspace Google Workspace では、 Google Workspace スタンダード サポート がライセンスに付帯しています。Google Workspace 利用ユーザーは実質無償で Google サポート窓口へ問い合わせができます。 しかしながらその性質上 P1 レベルの問い合わせ以外は SLA がなく、回答までに時間を要する場合があります。 参考 : Google Workspace サポート サービス - Google Workspace 管理者 ヘルプ コミュニティの活用 概要 公式の障害情報では確認できないものの、実際に障害が発生している場合は、コミュニティプラットフォームの情報を確認することで、障害情報や付帯情報を取得できる場合があります。 またコミュニティでは、問題提起や機能リクエストの投稿ができます。障害情報を共有し、より良いサービスになるよう貢献できます。 Google Cloud IssueTracker は、既知の問題や機能リクエストを投稿できる公式コミュニティです。機能リクエストは賛同（Vote）が多くなることで採用される可能性が高まります。 参考 : Sign in - Google Accounts 参考 : Google Issue Tracker  |  Google for Developers 参考 : Issue Tracker にアクセスする  |  Google Issue Tracker  |  Google for Developers Google Workspace Google Workspace では Google Workspace Admin Community というコミュニティが用意されており、Google エンジニアやユーザーが障害情報の共有や技術情報のディスカッションをしています。 参考 : Google Workspace Admin Community また Google Workspace の機能リクエストは Feature Ideas というサイトで投稿できます。調査の結果、障害ではないが今後必要と思われる機能があった場合はこちらから投稿します。Google Cloud 同様、賛同（Upvotes）が多くなることで採用される可能性が高まります。 参考 : Feature Ideas - Google Cloud Community 参考 : Google Workspace に関する提案を投稿する - Google Workspace 管理者 ヘルプ 非公式コミュニティ 技術情報に関する非公式コミュニティとして、 スタック・オーバーフロー （Stack Overflow）があります。スタック・オーバーフローでは、主に開発者が技術情報に関する投稿をしています。 Google App Script や API について Google サポート窓口に問い合わせた際、コアサービスではないためスタック・オーバーフローへの投稿を促される場合もあります。 参考 : スタック・オーバーフロー G-gen Tech Blog での情報収集 障害ステータスの確認とは少し性質が異なりますが、G-gen Tech Blog ではトラブルシューティングに関する記事があります。下記の記事はトラブルシューティング関連記事の例です。障害時に確認することで障害対応に役立ちます。 blog.g-gen.co.jp blog.g-gen.co.jp 記事はタグで分類されているため、 トラブルシューティング タグで検索することで、必要な記事が見つかる場合があります。以下リンクは、 トラブルシューティング タグが付いた記事の一覧です。 blog.g-gen.co.jp 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 ・Google Cloud 認定資格 7冠 最近ハマっていることは、息子とのポケモンカード Follow @arapote_tweet

G-gen の杉村です。Google Cloud（旧称 GCP）の認定資格である Generative AI Leader 資格の試験対策情報を紹介します。 基本的な情報 Generative AI Leader とは 難易度 出題傾向 試験対策 生成 AI の基礎 生成 AI と基盤モデル データタイプ 学習方法 生成 AI ソリューションのレイヤー エージェント エージェントとは 種類 ユースケース ツール 推論ループ Google Cloud の生成 AI サービス Vertex AI Vertex AI とは Model Garden Model Registry Vertex AI Search Vertex AI Pipelines Gemini Gemini と関連サービス Gemini を使った開発 Gemini 系プロダクト Gemini Enterprise（旧称 Google Agentspace） NotebookLM 画像・動画生成 オープンモデル 特定タスク向け AI/ML サービス Customer Engagement Suite セキュリティとガバナンス データ基盤との連携 AI モデルの出力改善テクニック プロンプトエンジニアリング パラメータ調整 グラウンディング ハルシネーション 生成 AI ソリューションのビジネス戦略 導入アプローチ ライフサイクルにおける考慮事項 ビジネス上のメリット 責任ある AI ユースケースの選定と導入戦略 基本的な情報 Generative AI Leader とは Generative AI Leader 試験は、Google Cloud（旧称 GCP）の認定資格の一つです。当試験は、2025年5月14日（米国時間）に一般公開されました。 当試験は Foundational レベル（最初級）の資格であり、 生成 AI に関する基礎的な知識 や、 Google Cloud や Google Workspace の生成 AI 関連サービス・機能の知識 が問われます。また、Google Cloud 認定資格でありながら、非技術系のビジネスパーソンも対象としています。 試験時間は90分、問題数は50〜60問です。 日本語版 と 英語版 の試験が提供されています。認定の有効期間は3年間です。 この試験取得に向けて、Google は無料のオンライントレーニングコースを提供しています。当試験の合格に向けて有用なほか、ビジネスにおける生成 AI 活用のために重要な知識を学ぶことができます。 参考 : Generative AI Leader 参考 : Google Cloud announces first-of-its-kind generative AI leader certification 難易度 Generative AI Leader 試験の難易度は、他の認定試験と比較して、 比較的低い といえます。 当試験はエンジニア向けというよりも、Generative AI Leader という試験名称のとおり、組織で生成 AI の活用をリードするようなビジネスパーソンに向けたものです。技術的に難しい内容は出題されず、コーディングの知識も必要ありません。 必要とされるのは、生成 AI の仕組みや振る舞いに関する基本的な知識や、ビジネスユースケースに応じて適切に Google Cloud や Google Workspace の生成 AI 関連サービス・機能を選定できる知見です。 生成 AI の基本的なキーワード （基盤モデル、プロンプトエンジニアリング、RAG など）や、Vertex AI、Gemini といった Google Cloud の主要な生成 AI 関連サービスについて理解していれば、合格を狙えるといえます。 出題傾向 当試験では、大きく分けて以下の4つの分野から出題されます。 No. セクション 出題数 1. 生成 AI の基礎 （Fundamentals of gen AI） 約30% 2. Google Cloud の生成 AI サービス （Google Cloud’s gen AI offerings） 約35% 3. AI モデルの出力改善テクニック （Techniques to improve gen AI model output） 約20% 4. 生成 AI ソリューションのビジネス戦略 （Business strategies for a successful gen AI solution） 約15% それぞれのセクションで出題される内容の詳細は、以下の公式試験ガイドを参照してください。また、当記事では各セクションごとに必要となる知識を整理しています。 参考 : Generative AI Leader Certification exam guide 試験対策 以下の勉強方法はあくまで一例であり、最適な方法は、受験者の予備知識や経験によって異なるものとご了承ください。 試験ガイド を確認する Google の 無料オンライントレーニング を受講する Generative AI Leader Study Guide を確認する 公式の 模擬試験 を受ける 当記事で復習する オンライントレーニングは、 Skillsboost と呼ばれる Google Cloud の学習プラットフォームで公開されています。動画とテキスト、小テストを組み合わせたコースで、ウェブブラウザでいつでも受講することができます。試験問題はこの学習コースから出題されます。2025年5月現在、トレーニングコースの全編は英語ですが、動画では自動翻訳の日本語字幕を利用することができます。2025年5月現在は受験可能言語は英語のみなので、よく使われる英単語や表現に慣れておくことを推奨します。 また当記事ではこれ以降、試験の出題セクションごとに必要となる基本的な知識を紹介します。まずは公式トレーニングを受講することが推奨されますが、既にある程度知識のある方は、当記事をすぐに参考にすることも可能です。 生成 AI の基礎 このセクションでは、生成 AI に関する基本的な概念や用語について解説します。 生成 AI と基盤モデル 生成 AI （Generative AI）とは、文章、音声、画像、動画などのコンテンツを生成することに特化した AI（人工知能）のことです。特に、文章の理解や生成に特化した生成 AI モデルは Large Language Model （LLM）と呼ばれ、Google 社の Gemini や、Open AI 社の ChatGPT などが有名です。 基盤モデル とは、テキスト、画像、音声など、多様な形式の膨大なデータセットで事前トレーニングされた大規模な AI モデルであり、特に生成 AI の文脈で使われます。特定のタスクに特化せず、ファインチューニングやプロンプトエンジニアリングを通じて、翻訳、要約、質問応答、コンテンツ生成など、様々な下流タスクに対応できる 汎用性が特徴 です。 基盤モデルは、 ファインチューニング （微調整のための追加のトレーニング）を通じて、特定のタスクに特化させることもできます。 参考 : Large Language Models powered by world-class Google AI - Google Cloud 生成 AI と基盤モデル データタイプ AI モデルのトレーニングや利用においては、様々な種類のデータが扱われます。 まず、 構造化データ （Structured Data）は、行と列を持つ表形式のデータ（例: データベースのテーブル、CSV ファイル）を指し、スキーマが明確に定義されている点が特徴です。 次に、 非構造化データ （Unstructured Data）は、テキスト文書、画像、音声、動画など、特定の構造を持たないデータです。E コマースサイトのユーザーレビュー（自由記述テキスト）などがこれに該当します。 また、データの特性によっても分類されます。 ラベル付きデータ （Labeled Data）は、データに対して人間が付与した正解ラベルやタグが付与されたデータです。例えば、画像に「猫」「犬」といったラベルが付いているデータセットが該当し、主に教師あり学習で利用されます。 一方、 ラベルなしデータ （Unlabeled Data）は、正解ラベルが付与されていないデータであり、教師なし学習や自己教師あり学習で利用されます。 学習方法 AI モデルをトレーニングする方法は、データの種類や目的に応じて異なります。 教師あり学習 （Supervised learning）では、ラベル付きデータを用いて、入力と出力の関係性を学習します。これは、 分類 （例: スパムメール判定）や 回帰 （例: 株価予測）などのタスクに用いられます。 教師なし学習 （Unsupervised learning）では、ラベルなしデータを用いて、データに内在するパターンや構造を学習します。 クラスタリング （例: 顧客セグメンテーション）、 異常検知 （例: 工場機器のセンサーデータからの異常検出）、次元削減などに用いられ、データの「自然な集まり（natural groupings）」を見つけるようなタスクに適しています。 強化学習 （Reinforcement Learning）は、エージェントが環境と相互作用（interact）し、試行錯誤を通じて得られる報酬（フィードバック）を最大化するように行動を学習する方法です。ゲーム AI やロボット制御などに用いられます。 生成 AI ソリューションのレイヤー Google の定義では、生成 AI ソリューションはいくつかのレイヤーで構成されます。このレイヤーを俯瞰して全体を見ることを、Google は Landscape（景観、展望、特質）と表現しています。 生成 AI ソリューションのレイヤー（Google による） インフラストラクチャ （Infrastructure）レイヤーは、モデルのトレーニングや推論に必要な計算リソースを提供します。これには物理サーバー、CPU などに加えて、GPU や TPU といった AI に最適化されたハードウェアが含まれます。 モデル （Models）レイヤーは、AI ソリューションの頭脳にあたる部分です。Gemini のような生成 AI モデル（LLM）などが該当します。 プラットフォーム （Platform）レイヤーは、モデル開発、管理、デプロイのためのツールやサービスを提供し、Vertex AI やデータマネジメントツールなどが該当します。 エージェント （Agents）レイヤーは、モデルレイヤーを利用して複雑なタスクを行います。エージェントは周囲の環境に働きかけたり、情報を収集して、実行するアクションを決定し、実行します。 生成 AI アプリケーション （Gen AI applications）レイヤーは、エンドユーザーが直接利用する AI アプリケーションであり、ユーザーインターフェイスを提供します。 エージェント エージェントとは エージェント （Agents）とは、与えられた目標を達成するために、自律的に 推論 （Reasoning）し、 ツール （Tools）を使用して 行動 （Acting）する AI システムです。この一連のプロセスは 推論ループ （Reasoning Loop）と呼ばれることもあります。 なお、日本語では reasoning は「思考」や「推論」と訳されます。AI モデルがインプットに基づいてアウトプットを出力する処理を一般的に inference と呼びますが、この語も「推論」と訳されます。特に生成 AI の背景で、LLM が inference を繰り返し実行して論理的なタスクを行うことが reasoning であるといえます。 エージェントは、旅行予約サイトで飛行機やホテルを予約したり、カスタマーサポートで顧客との受け答えを行うなど、従来は人間が行っていたタスクを代わりに実行します。 エージェントは内部的に生成 AI（LLM）を利用しており、タスクを実行するときには ツール （Tools）と呼ばれるプログラムを呼び出して、タスクを実行します。一般的にはツールはプログラミング言語で書かれており、プログラムのロジックに従って計算を行ったり、外部 API へリクエストしてカレンダー予定の作成、メール送信、宿泊の予約などを行います。 エージェント 種類 エージェントにはいくつかの種類や概念があります。 マルチエージェント （Multi-agent）は、複数のエージェントが協調して、より複雑なタスクを分担・実行するシステムです。Google は、特にこのマルチエージェントの考え方を推し進めています。 会話型エージェント （Conversational agents）は、テキストや音声による人間との会話を通じて、会話を理解し、質問に答えたり、タスクを実行します。 ワークフローエージェント （Workflow agents）は、人間の仕事を合理化（streamline）し、また自動化するエージェントです。人間が書いた申請書に基づいて、複数のシステムに対して入力を行ったり、また人間の代わりに様々な情報をインターネットから調査してレポート化したりします。 いずれのエージェントも、内部では生成 AI モデルを利用し、推論（Reasoning）を行い、ツール（Tools）を呼んでタスクを実行しています。 ユースケース エージェントは、ユースケース別にも分類することができます。 Code Agent は、自然言語による指示に基づいて、ソースコードの生成、デバッグ、レビューなどを行うエージェントを指します。 Data Agent は、データに関するタスク（取得、分析、可視化など）を支援します。 Security Agent は、セキュリティに関するタスク（脅威検出、脆弱性分析など）を支援するエージェントです。 Customer Service Agent は、顧客からの質問への回答、問題解決、パーソナライズされた推奨事項の提供などを行うエージェントを指します。 Employee Productivity Agent は、従業員の情報検索、タスク管理、ワークフローの自動化などを支援するエージェントです。 Creative Agent は、新しいアイデアの生成、画像や動画などのコンテンツ作成、言語翻訳などを行うエージェントを指します。 ツール エージェントは、目標達成のために様々な ツール （Tools）を利用します。ツールは以下のような種類に分類できます。 Extentions（APIs） は、外部の API と連携するためのツールです。例えば、旅行予約 API を叩いて予約を行う Extension などが考えられます。 Functions は、特定のロジックを実行するためのツールです。例として、特定のロジックで料金計算を行う Function が考えられます。 Data Stores は、リアルタイムデータ、履歴データ、ナレッジベースなど、エージェントに情報を提供するためのツールであり、顧客データベースや天気予報の取得などが該当します。 Plugins は、外部システムと連携し、エージェントに新しいスキルを与えるツールです。例として、カレンダーアプリと連携して予定を作成したり、支払いシステムと連携して取引を成立させるなどの Plugin が考えられます。 推論ループ エージェントは、「 Reasoning （ツール選択）→ Acting （ツール実行）→ Observation （結果確認）→ Iteration （繰り返し）」というサイクルを通じて、ツールを駆使しタスクを遂行します。 このようなループを 推論ループ （Reasoning loop）といったり、 ReAct サイクル （reasoning and acting cycle）と呼んだりします。 例えば、庭園リフォームコンサルタントの予約を行うエージェントを例に取ると、以下のようになります。ユーザーがコンサルの依頼をエージェントに投げかけると、以下のような処理が実行されます。 1. Reasoning コンサルの空き時間を見つけるために、スケジューリングの Plugin を選択。 2. Acting スケジューリング Plugin を使って、コンサルの空き時間を確認。また顧客情報データベースから、予約希望者の情報を取得。 3. Observation スケジューリング Plugin が返した予約候補時間を確認。 4. Iteration エージェントが予約希望者に、候補時間を返答。希望者と時間をすり合わせて、予約が完了するまでやりとりを続ける。 Google Cloud の生成 AI サービス このセクションでは、Google Cloud が提供する主要な生成 AI 関連サービスについて解説します。 Vertex AI Vertex AI とは Vertex AI は、機械学習モデルの開発、トレーニング、デプロイ、管理を行うための統合プラットフォームであり、Google Cloud で提供されています。 Vertex AI はトレーニング、推論、開発ツール、パイプライン管理など、MLOps のための包括的な機能を提供します。そのため、各ステップで個別のプラットフォームを選定する必要がありません。また、Google Cloud サービスであるため、Google の基盤モデルへのアクセスが容易なほか、オープンソースモデルやサードパーティのモデル（Claude や Llama など）へのアクセスも提供します。 このように、Google は オープンなプラットフォーム を提供することを意識しています。Google Cloud（Vertex AI）では特定の会社が開発した AI モデルだけが利用可能なのではなく、さまざまな出自のモデルが利用可能です。 参考 : Vertex AI の概要 Model Garden Model Garden は、Google やパートナー、オープンソースコミュニティによって開発された多様な基盤モデルや事前トレーニング済みモデルを発見、探索、試用できるカタログです。ここからモデルを選択し、Vertex AI 上でファインチューニングやデプロイを行うことができます。 Gemini のような、Google のファーストパーティモデルは Vertex AI にネイティブに統合されている（組み込まれている）ので、Model Garden から呼び出す必要はありませんが、Claude や Llama のような他社の（サードパーティの）モデルを使いたいときは、Model Garden 経由でモデルをデプロイします。 参考 : Vertex AI の Model Garden Model Registry Model Registry は、トレーニング済みの機械学習モデルを一元的に管理、バージョニング、デプロイするためのリポジトリです。モデルのライフサイクル管理を効率化し、本番環境への安全なデプロイを支援します。モデルのバージョン管理機能により、必要に応じて過去のバージョンに戻す（ロールバック）ことも可能です。このようなモデルのバージョン管理戦略は、 モデルバージョニング （Model Versioning）と呼ばれます。 参考 : Vertex AI Model Registry の概要 Vertex AI Search Vertex AI Search は、ウェブサイトや非構造化・構造化データソースに対して、高度な セマンティック検索 （意味論検索）やチャットボットなどを迅速に構築できるサービスです。EC サイトの商品検索精度向上などに活用できます。 なお、Vertex AI Search は AI Applications（旧称 Vertex AI Agent Builder）という Google Cloud プロダクトの1機能です。 参考 : AI Applications とは Vertex AI Search では、企業が持つデータを ベクトル化 （エンベディング）し、データストアに格納します。これにより、文字列一致ではなく、意味による検索を可能にします。 以下の記事も参考にしてください。 blog.g-gen.co.jp Vertex AI Pipelines Vertex AI Pipelines は、機械学習ワークフローを自動化、管理、監視するためのサービスです。モデルのトレーニング、評価、デプロイといった一連のステップをパイプラインとして定義し、再現性のある ML プロセスを構築できます。 試験で細かく問われることはありません。上記のように、AI モデルの開発ライフサイクル全体をカバーするプラットフォームであることを理解しましょう。 参考 : Vertex AI Pipelines の概要 Gemini Gemini と関連サービス Gemini は、Google が開発したマルチモーダルな（テキスト、画像、音声、動画などを扱える）基盤モデルファミリーです。様々なサイズと能力のモデルが提供されており、ユースケースに応じて選択できます。Gemini は、以下のように、さまざまなサービスに組み込まれています。 Gemini in Google Workspace は、Gmail、ドキュメント、スプレッドシートなどの Workspace アプリケーションに組み込まれ、文章作成支援、要約、データ分析などを支援します。セールスチームがメール作成や顧客対応を効率化するなどのユースケースが考えられます。 参考 : Gemini for Google Workspace を使ってみる Gemini アプリ は、一般ユーザー向けの対話型 AI アシスタントです。パソコンの Web ブラウザから使う Gemini ウェブアプリや、スマートフォンから利用する Gemini モバイルアプリがあります。また、有償版である Gemini Advanced では、より高性能なモデルや追加機能が利用できます。 参考 : Gemini アプリ Gems は、特定のタスクや目的に合わせて Gemini アプリをカスタマイズできる機能です。無償版の Gemini アプリには付属しておらず、有償版である Gemini Advanced で利用することができます。 参考 : Geminiウェブアプリのカスタマイズ機能「Gems」を徹底解説 - G-gen Tech Blog これらのように Google がユーザー向けサービスとして提供している AI ソリューションを利用していれば、将来的に AI モデルが新しくなったときにも Google が随時、 最新のモデルに更新 してくれます。これは、API 経由でモデルを呼び出すような独自の AI アプリをユーザーが開発するのに比べて、メリットとなります。 Gemini を使った開発 ユーザーは前述のように Gemini が組み込まれているサービスを利用できますが、開発者が Gemini モデルを使用して、独自のアプリケーションを開発することができます。開発者向けのプラットフォームとして、以下のようなものがあります。 Google AI Studio は、個人開発者や学生、研究者向けの、ウェブベースの開発ツールです。難しい設定をすることなく、すぐに Gemini モデルが試用できるほか、パラメータを変更して生成コンテンツの変化を確認することができます。 一方で、会社などの組織が Gemini を用いて開発する場合は、Google Cloud と統合された Vertex AI を使うことが望ましいといえます。Vertex AI の中の Vertex AI Studio を使うと、簡単に Gemini モデルを試用したり、パラメータ調整を試したり、プロンプトを保存して再利用することができます。 参考 : Google AI Studio 参考 : Vertex AI Studio - エンタープライズ対応の生成 AI のテスト、チューニング、デプロイ 参考 : Gemini Proを使ってみた。Googleの最新生成AIモデル - G-gen Tech Blog Gemini 系プロダクト 上記のように、Gemini と名のつくプロダクトは多数あります。以下の記事では、それぞれの詳細が解説されています。 blog.g-gen.co.jp Gemini Enterprise（旧称 Google Agentspace） Gemini Enterprise （旧称 Google Agentspace）は、企業のデータを横断検索する機能と、検索結果をもとに AI が要約を生成したりコンテンツを生成する機能、また他システムに働きかけて人間の代わりにタスクを行うエージェント機能を備えた、Google の SaaS です。Gemini Enterprise を、Microsoft 365 の SharePoint や Teams に接続したり、Box や Google ドライブといったストレージサービスに接続することで、データを横断検索したり、活用することができます。 企業は、Gemini Enterprise を導入することで、従業員が散在するデータを活用できるようになり、コラボレーションが促進されます。 詳細は、以下の記事も参照してください。 blog.g-gen.co.jp NotebookLM NotebookLM は、「パーソナライズされた AI リサーチパートナー」であると位置づけられている Google の AI サービスです。 ユーザーが独自のドキュメントや画像などを NotebookLM にアップロードすることで、AI が要約、分析、コンテンツの生成を行うことができます。Gemini アプリが、生成 AI の学習データやインターネット上のデータに基づいてタスクを行うのに対して、NotebookLM はユーザーの独自データに基づいてタスクを行うことができます。 NotebookLM には、無償版のほか、有償版の NotebookLM Plus、企業向けの NotebookLM Enterprise が存在しています。 NotebookLM の基本や使い方については、以下の記事も参照してください。 blog.g-gen.co.jp 画像・動画生成 画像や動画の生成に特化したモデルやサービスもあります。 Imagen は、テキストの説明から高品質な画像を生成するモデルです。 Veo は、テキストや画像から高品質な動画を生成するモデルです。 Google Vids は、Google Workspace アプリとして提供される、AI を活用した動画編集ツールです。カスタムアバターやナレーション生成機能があり、既存の動画や写真、音声などの素材から、簡単に完成度の高い動画を編集できます。Google Workspace のエディションに組み込まれているため、 追加の費用を払うことなく 、動画を作成したい場合に適しています。 Chirp は、テキストから自然な読み上げ音声を生成（いわゆる Speech-to-Text）できるモデルです。 参考 : Vertex AI の Imagen | AI 画像生成ツール 参考 : Veo 2 参考 : Google Vids 参考 : Chirp: ユニバーサル音声モデル 各モデルの役割が試験で問われる可能性がありますので、以下のように覚えましょう。 画像生成 → Imagen 動画生成 → Veo 動画編集 → Google Vids 音声生成 → Chirp オープンモデル Gemma は、Google が開発した、軽量で高性能なオープンモデルファミリーです。研究者や開発者が自由に利用・カスタマイズでき、要約やレポート草稿作成などのタスクに活用できます。 通常の Gemini が API 経由でリモートから呼び出して使うのに対して、Gemma はモデル自体を Google Kubernetes Engine（GKE）のようなプラットフォームに搭載するため、データが外部に出ません。これにより、機密性やレイテンシの面でメリットがあります。 参考 : Gemma 特定タスク向け AI/ML サービス Google Cloud は、特定のタスクに特化した学習済み API やサービスも提供しています。これらは、機械学習の専門知識が少ない組織でも容易に AI を活用できる選択肢となります。 Document AI は、PDF や画像などのドキュメントからテキストや構造化データを抽出する AI サービスです。保険申込書の PDF から情報を自動入力するなど、手作業のデータ入力を効率化できます。 Natural Language API （Natural Language AI）は、テキストデータの感情分析、エンティティ抽出、構文解析などを行う API です。 Vision AI は、画像内のオブジェクト検出、ラベル付け、顔検出、OCR などを行う API です。 参考 : Document AI 参考 : Natural Language AI 参考 : Vision AI Customer Engagement Suite Customer Engagement Suite （with Google AI）は、AI 補助により、カスタマーセンター業務を補助するサービススイート（サービス群）です。Customer Engagement Suite には、以下の機能が含まれています。 機能名 説明 Conversational Agents 自然言語を理解し、自動応答を行う会話型 AI（チャットボット、ボイスボット）を構築するためのプラットフォーム Agent Assist 人間のオペレーターに対して、リアルタイムで関連情報を提供したり、応答文案を提案したりすることで、顧客対応を支援するツール Contact Center as a Service (CCaaS) 電話、チャット、メールなど、複数のチャネルを統合管理し、AI による自動応答や分析機能を提供する包括的なコンタクトセンタープラットフォーム Customer Engagement Suite というサービススイート名と、上記の3つの機能名については、名前と概要、ユースケースを覚えておき、試験で答えられるようにしてください。 イメージとしては、「AI が顧客対応をするのが Conversational Agents」「人間のオペレーターを補助するのが Agent Assist」「コンタクトセンター業務を包括的に支援するのが Contact Center as a Service（CCaaS）」と覚えてください。 参考 : Customer Engagement Suite with Google AI セキュリティとガバナンス AI 活用におけるセキュリティとガバナンスも重要です。 Identity and Access Management （IAM）は、Google Cloud リソースへのアクセス権限を管理するサービスです。生成 AI モデルや関連リソースへのアクセス制御にも IAM を使用し、最小権限の原則に従うことが重要です。適切な人が、適切なリソースにのみ、アクセスできることを担保するのが、この IAM です。 参考 : IAM の概要 参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog Secure AI Framework （SAIF）は、Google が提唱する、AI システムを安全に設計、開発、運用するためのフレームワークです。開発者は、AI アプリケーションのセキュリティを確保するためのベストプラクティスとして、SAIF を参照できます。AI アプリケーションをセキュアに設計するための道しるべであると覚えてください。 参考 : Google のセキュア AI フレームワーク（SAIF） Secure-by-Design は、Google のインフラストラクチャやサービスが、設計段階からセキュリティを組み込む原則に基づいて構築されていることを示す原則です。企業の経営層が、Google Cloud の安全性について知りたいときは、Google 製品や Google Cloud が Secure-by-Design 原則に基づいて設計されていることを示します。 参考 : Secure by Design at Google データの保護 に関して、Gemini for Google Workspace や Vertex AI などの有償の Google サービスでは、顧客データがモデルのトレーニングに許可なく使用されることはありません。また、転送中および保管中のデータはデフォルトで暗号化されます。 参考 : 生成 AI とデータ ガバナンス - Generative AI on Vertex AI 参考 : Gemini for Google Workspace に関するよくある質問 - Google Workspace with Gemini ではどのようにデータが保護されますか？ データ基盤との連携 生成 AI はデータ基盤との連携により真価を発揮します。 BigQuery は、フルマネージドのデータウェアハウスであり、構造化データ、半構造化データ（JSON など）、ストリーミングデータなどを格納・分析できます。BigQuery ML を使用すれば、SQL だけで機械学習モデルを構築・利用できます。 Cloud Storage は、スケーラブルで耐久性の高いオブジェクトストレージで、非構造化データ（画像、動画、ログファイルなど）の格納に適しています。 Pub/Sub は、スケーラブルな非同期メッセージングサービスであり、ストリーミングデータの取り込みに適しています。 これらのサービスを組み合わせることで、多様なデータを収集・処理し、生成 AI モデルのトレーニングや推論に活用する基盤を構築できます。例えば、Pub/Sub でストリーミングデータを受け取り、Cloud Storage や BigQuery にデータを格納することができます。そのデータを AI モデルのトレーニングや、RAG（後述）に活かすことができます。 AI モデルの出力改善テクニック 生成 AI モデルの出力を意図通りに制御し、質を高めるためのテクニックについて解説します。 プロンプトエンジニアリング プロンプトエンジニアリング とは、モデルへの指示（プロンプト）を工夫することで、出力結果を改善する手法です。 Zero-shot Prompting は、モデルにタスクの例を一切示さずに、タスクの説明だけで指示する方法です。モデルが持つ汎用的な知識だけで対応できる場合や、事前データがほとんどない新しい分野での探索に適しています。 One-shot Prompting は、タスクの例を 1 つだけ示して指示する方法です。 Few-shot Prompting は、タスクの例をいくつか (2〜5個程度) 示して指示する方法です。これにより、モデルにタスクのパターンや期待する出力形式をより明確に伝えられます。例えば、メールを指定されたラベル（例: バグ報告、技術的な質問）に分類するようなタスクでは、ラベルごとの分類例を示す Few-shot Prompting が有効です。 Role Prompting は、モデルに特定の役割（例:「あなたは親切なカスタマーサポート担当者です」）を与えることで、出力のトーンやスタイルを制御する方法です。モデルの再トレーニングなしに、より顧客に寄り添った応答を生成させたい場合に有効です。 Prompt Chaining は、一つの複雑なタスクを複数の単純なプロンプトに分割し、前のプロンプトの出力を次のプロンプトの入力として連鎖させる方法です。チャット形式で過去のやり取りを踏まえた応答を得ることもこれに含まれます。 参考 : プロンプトの概要 パラメータ調整 モデルの生成プロセスを制御するパラメータを調整することで、出力の特性を変えることができます。 Temperature （温度）は、出力のランダム性を制御します。値を高くすると、より多様で創造的な出力になりますが、一貫性が失われる可能性もあります。設定値としては、0〜1 の範囲が一般的です。生成されるデザインの幅を広げたり、独創性を高めたい場合などは、Temperature を上げることを検討します。 Output Length （Max output tokens）は、生成されるテキストの最大長（トークン数）を指定します。 Top-K は、次の単語を選択する際に、確率の高い上位 K 個の候補からランダムに選ぶ方式です。 Top-P （Nucleus Sampling）は、次の単語を選択する際に、確率の合計が P を超えるまでの上位候補からランダムに選ぶ方式です。いずれも、ランダム性を増やしたい場合は数字を大きくします。 参考 : パラメータ値を試す グラウンディング グラウンディング （Grounding）とは、モデルの知識を外部の信頼できる情報ソースで補強し、出力の正確性や信頼性を向上させる手法です。これは、モデルが事実に基づかない情報を生成する ハルシネーション を抑制するのに有効です。 Google Search によるグラウンディング では、モデルの回答生成時に Google Search を利用して最新情報や信頼性の高い情報を参照させます。インターネット上の最新ニュースを収集・要約するような機能に適しています。 独自データによるグラウンディング は、企業内のドキュメントやデータベースなど、特定のデータソースを検索し、そこで見つかった関連情報をプロンプトに含めてモデルに渡すことで、そのデータに基づいた回答を生成させます。これにより、データソースにある最新の情報や内部情報に基づいた出力を得られます。 サードパーティデータによるグラウンディング では、市場調査レポートや業界ニュースなど、信頼できる外部データソースを活用して回答の根拠づけを行います。 生成 AI アプリケーションにおいて、外部データに基づいたグラウンディングを行うアーキテクチャを、 RAG （Retrieval-Augmented Generation）と呼びます。ハルシネーションを抑制するには、RAG を実装し、外部のデータや最新のデータを参照して、生成 AI に生成を行わせることが重要です。RAG を構成しない場合、生成 AI モデルは、過去に学習した大量のデータに基づいてのみ生成を行うため、古いデータをもとに、事実と異なる生成を行ってしまう可能性があります。 参考 : グラウンディングの概要 参考 : 検索拡張生成（RAG）とは ハルシネーション モデルが、学習データに含まれていない、または事実と異なる情報を、あたかも真実であるかのように生成してしまう現象を ハルシネーション と呼びます。イベントの要約はできるが、詳細情報になると不正確な内容を出力し始める、といった場合にハルシネーションが疑われます。対策としては、前述のグラウンディングが有効です。 生成 AI ソリューションのビジネス戦略 生成 AI をビジネスに導入し、成功させるための戦略や考慮事項について解説します。 導入アプローチ Google は、生成 AI の導入において、トップダウン（経営層主導）とボトムアップ（現場主導）の両方を組み合わせた双方向（ Multi-directional ）なアプローチを推奨しています。経営層が ビジョン を示し、現場が 具体的なユースケースや課題を特定 することで、効果的な導入が促進されます。 また、検討段階においては、どのツールを使うかなどの手段に着目するの ではなく 、投資対効果（RoI）やビジネスインパクトに着目することが重要です。 ライフサイクルにおける考慮事項 AI アプリケーションの開発ライフサイクル全体を通じて、様々な点に注意が必要です。 データ収集（Gathering）段階 収集するデータの品質と量を確保します。 データのプライバシーとセキュリティを保護し、適切なアクセス制御を行います。 データの偏り（バイアス）に注意します。 モデルトレーニング（Training）段階 トレーニングデータのセキュリティを確保し、不正なアクセスや改ざんを防ぎます。 モデルの性能評価指標を定義し、定期的に評価します。 過学習（トレーニングデータに過剰に適合し、未知のデータに対する汎化性能が低下すること）を防ぐための対策を講じます。 デプロイ・運用（Deploy、Operation）段階 モデルの性能を継続的にモニタリングします。 ユーザーからのフィードバックを収集し、モデル改善に役立てます。 モデルの挙動（特に予期せぬ出力やバイアス）を監視します。 ビジネス上のメリット 生成 AI は様々なビジネス上のメリットをもたらします。 効率化と生産性向上 として、レポート作成、メール作成、コード生成などの定型業務を自動化できます。 顧客体験の向上 の面では、パーソナライズされたレコメンデーション、24 時間対応のチャットボットなどを提供できます。EC サイトにベクトル検索を導入し、顧客が目的の商品を見つけやすくすることで、顧客満足度向上と売上増加に繋がる可能性があります。 新しいインサイトの発見 として、大量のデータから人間では気づきにくいパターンやインサイトを抽出できます。 イノベーションの加速 にも繋がり、新製品やサービスのアイデア創出、研究開発のスピードアップを支援します。 責任ある AI AI を倫理的かつ社会的に責任ある方法で開発・利用するための原則と実践が 責任ある AI （Responsible AI）です。Google は責任ある AI の原則に注意深く従って、AI ソリューションを開発しています。また、それらのソリューションを利用したり、モデルを使って開発を行う我々ユーザーも、この原則に従うことが重要です。 バイアス （Bias）は、モデルが学習データに含まれる偏見（例: 性別、人種などに関するステレオタイプ）を学習・増幅し、不公平または差別的な結果を生み出すことです。採用候補者のスクリーニングで、過去のデータに基づき特定の属性（例: 男性）を不当に有利に扱ってしまうなどが該当します。 データ依存 （Data Dependency）は、モデルの出力が、トレーニングに使用された特定のデータセットに強く依存してしまうことです。学習データが古かったり、特定の時期や状況に偏っていたりすると、現在の状況に合わない分析結果を出力してしまう可能性があります（例: 古い顧客の声データで学習したモデルが、現在の分析基準と合わない）。 説明可能性 （Explainable AI / Interpretability）は、モデルがなぜそのような予測や判断を行ったのかを人間が理解できるようにすることです。特に金融（ローン審査）や医療など、判断根拠の説明責任が求められる分野で重要です。ユーザーがモデルの判断（例: ローン審査の拒否）に不満を持つ場合、判断理由を説明できることが重要になります。 透明性 （Transparency）は、AI システムの動作、機能、限界について、情報を明確かつアクセス可能な形で提供することです。 公平性 （Fairness）は、AI システムが、特定のグループに対して不当な不利益を与えないようにすることです。 プライバシーとセキュリティ は、ユーザーデータや機密情報を適切に保護することです。 Human-in-the-Loop （HITL）は、AI の判断プロセスに人間が介在し、最終的な意思決定や品質チェックを行うアプローチです。例えば、口コミの文章における皮肉の表現のような AI が苦手とするニュアンスの解釈や、重要な判断において、人間の介入が有効です。 参考 : Google AI - AI Principles 参考 : Vertex Explainable AI の概要 ユースケースの選定と導入戦略 生成 AI の導入にあたっては、適切なユースケースの選定と戦略が重要です。 適切なユースケース の選定においては、生成 AI が創造的なタスクやパターン認識に優れている一方で、 厳密なルールベースの判断や計算が求められるタスク には必ずしも 適していない 点を考慮する必要があります。住宅ローンのように、厳密に定義されたルールに基づいて承認・拒否を決定するプロセスには、従来のプログラムの方が適している場合があります。 初期段階でのフォーカス としては、新しい AI 機能を導入する際は、まずその機能がエンドユーザーにどのような価値（メリット、ポジティブな体験）をもたらすかを明確にすることが重要です。技術的な実現可能性やインフラ投資の前に、ビジネス価値を検証します。 組織における役割 も、AI 導入にあたって重要になります。 経営層 は、的確なビジョンを示し、AI 導入が中長期的に見てビジネスにどのようなインパクトを与えるかを検討します。 中間管理職 （Mid-level managers）は AI 導入によって最もインパクトがありそうな業務プロセス（workflow）を特定し、具体的な課題を明確化する役割を担います。一方、 従業員 は新しい AI ツールを活用し、日々の業務を効率化することが期待されます。 生成 AI の導入は、単なる技術導入ではなく、ビジネスプロセスや組織文化の変革を伴います。明確な目標設定、適切なユースケース選定、そして責任ある AI の原則に基づいた慎重な導入が成功の鍵となります。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の松尾です。当記事では、 Gemini Enterprise と Salesforce を連携し、顧客情報の問い合わせを行う検証方法について解説します。 はじめに Gemini Enterprise とは Salesforce を連携するメリット Salesforce セットアップ エディションの確認 接続ユーザーの準備 CORS の設定 接続アプリケーションの設定 接続アプリケーションのポリシー設定 OAuth および OpenID Connect 設定の有効化 データストア作成に必要な情報の取得 Gemini Enterprise セットアップ Gemini Enterprise への認証 アプリを作成する Salesforce コネクタを作成する 検証 はじめに Gemini Enterprise とは Gemini Enterprise （旧称 Google Agentspace）は、Google Cloudが提供する企業向けの AI エージェントプラットフォームです。企業の様々なシステムやアプリケーションに散在する情報を横断的に検索し、 AI を利用して情報に基づいたタスクの実行や自動化を支援することを目的としています。 詳細は、以下の記事を参考にしてください。 blog.g-gen.co.jp Salesforce を連携するメリット Salesforce は多くの企業で顧客管理（CRM）や営業支援（SFA）のシステムとして利用されています。Salesforce が保持する顧客データや営業活動、サービス履歴などの重要な情報を、Gemini Enterprise の AI 検索機能やエージェント機能を利用して、より効果的に利用できます。 Gemini Enterprise の統合検索機能により、Salesforce 内に存在する顧客情報、商談履歴、ケース情報などを、他の社内システム（Google Drive、SharePoint、Jira など）の情報と合わせて、横断検索できます。また、Salesforce 専用のインターフェースを開くことなく、Gemini Enterprise の Web インターフェースから自然言語で問い合わせることができます。 これにより、 Salesforce に保存された顧客情報や商談情報に迅速にアクセスし、情報の活用が促進されることが期待できます。 Salesforce セットアップ エディションの確認 Salesforce は、 Enterprise エディションまたは Developer エディションが必要です。トライアルアカウントでは、Gemini Enterprise と連携することができません。 参考 : Salesforce Editions ‐ Salesforce 参考 : Connect Salesforce ‐ Before you begin ‐ Gemini Enterprise 接続ユーザーの準備 Gemini Enterprise から Salesforce に接続するための専用ユーザーアカウントを作成するか、既存のユーザーを使用します。 このユーザーには、Gemini Enterprise がアクセスする必要がある Salesforce オブジェクト（例: Account、Case、Contact など）への読み取り権限が必要です。また、API アクセスが許可されている必要があります。 ContentDocument を連携対象に含める場合は、接続ユーザーの [すべてのファイルをクエリ] 権限を有効にします。 参考 : User Permissions ‐ Salesforce 参考 : Administrator users unable to query All ContentNote and ContentDocument ‐ Salesforce CORS の設定 Gemini Enterprise のような外部アプリケーションから Salesforce のデータにブラウザを介してアクセスする場合、Salesforce 側で OAuth エンドポイントに対する CORS （Cross-Origin Resource Sharing）の設定が必要です。 [設定] で、[クイック検索] ボックスに「CORS」と入力して、[CORS] を選択 https://console.cloud.google.com を CORS 許可リストに追加 [クロスオリジンリソース共有 （CORS）ポリシー設定] セクションで、[編集] をクリック [OAuth エンドポイントの CORS を有効化] を選択 参考 : OAuth エンドポイント用の CORS の有効化 接続アプリケーションの設定 [設定] で、[クイック検索] ボックスに「アプリケーション」と入力し、[アプリケーションマネージャー] を選択 [新規接続アプリケーション] をクリック [接続アプリケーション]を作成 接続アプリケーションの名前、連絡先メールを入力 [OAuth 設定の有効化] を選択 [コールバック URL] に https://vertexaisearch.cloud.google.com/console/oauth/salesforce_oauth.html を入力 接続アプリケーションに適用する OAuth 範囲を選択します。Full Access（full）と Perform request at any time（refresh_token, offline_access）を追加 [クライアントログイン情報フローを有効化] を選択 [認証コードおよびログイン情報フローを許可] を選択 [認証コードおよびログイン情報フローの POST 本文でユーザーログイン情報を要求] を選択 [クライアントログイン情報フロー] の [別のユーザーとして実行] で、接続ユーザーを選択。このユーザーは、コネクタがデータを抽出したいすべてのエンティティに対して読み取り権限を持っている必要がある 参考 : Configure Basic Connected App Settings - Salesforce 参考 : Enable OAuth Settings for API Integration - Salesforce 参考 : Configure a Connected App for the Authorization Code and Credentials Flow - Salesforce 接続アプリケーションのポリシー設定 作成した接続アプリケーションのポリシーを編集します。 作成した接続アプリケーションを見つけ、「編集」をクリック [IP 制限]を [IP 制限の緩和] に設定 [更新トークンポリシー] を [更新トークンは取り消されるまで有効] またはより厳格な設定を選択 [許可されているユーザー] を [すべてのユーザーは自己承認可能] に設定 参考 : Manage OAuth Access Policies for a Connected App - Salesforce なお、組織全体の設定で「すべての要求でログイン IP アドレスの制限を適用」が有効な場合 、接続アプリケーションで [IP 制限の緩和] を設定しても IP 制限は解除されません 。IP 制限を適用したい場合は、「ネットワークアクセス」の信頼済み IP 範囲で Google Cloud の IP アドレスを許可リストに追加する必要があります。IP アクセス制限を無効にする場合は、「すべての要求でログイン IP アドレスの制限を適用」のチェックを外してください 参考 : Set Trusted IP Ranges for Your Org - Salesforce OAuth および OpenID Connect 設定の有効化 [OAuth および OpenID Connect 設定] を選択 [認証コードおよびログイン情報フローを許可] を有効化 [OAuth ユーザーエージェントフローを許可] を有効化 [OAuth ユーザー名パスワードフローを許可] を有効 データストア作成に必要な情報の取得 Gemini Enterprise でデータストア（Salesforce へのコネクタ）を作成する際に必要な情報を、Salesforce 側で取得します。 Instance URL 「私のドメイン」を確認します。Instance URL の値は https://[私のドメイン].my.salesforce.com です。 参考 : What Is My Domain? - Salesforce クライアント ID（Client ID） / クライアント シークレット（Client Secret） [アプリケーションマネージャー] で作成した アプリケーションの「参照」をクリック 接続アプリケーションの設定画面で「コンシューマの詳細を管理」をクリック このとき、メールアドレスの検証が求められる場合があります 「コンシューマ鍵」（Client ID）と「コンシューマの秘密」（Client Secret / Client Key）をメモ Gemini Enterprise セットアップ Gemini Enterprise への認証 Gemini Enterprise へのログインは、 Google Identity （Google Workspace や Cloud Identity で管理された Google アカウントでログインする）または、 Third-party identity provider （Entra ID や Okta など外部 IdP から OIDC や SAML 2.0 で認証連携をしてログインする）の2種類から選択できます。 まず、このセットアップを行い、ユーザーが Gemini Enterprise にログインできるように設定します。 参考 : Configure identity provider Gemini Enterprise は、接続されたデータソースが持つ既存のアクセス制御リスト（ACL）に従って、検索結果に対するアクセス制御を行います。これにより、Gemini Enterprise にログインしているユーザーがアクセス権を持っているコンテンツのみが、検索結果として表示されます。 アプリを作成する Google Cloud コンソールで、 AI Applications 画面に遷移します。 ナビゲーション メニューで、[アプリ] をクリックします。 [作成するアプリの種類]で Gemini Enterprise の下部の「作成」をクリックします。 [構成] で任意のアプリ名、会社名または組織名を入力します。 アプリのロケーションは制限事項を考慮し、特にデータの所在等に関する要件がない場合は global が推奨されます。 参考 : Gemini Enterprise locations 階層の選択は [検索 + アシスタント] を選択します。 Salesforce コネクタを作成する データストアの設定画面で、[データストアを作成]をクリックします。サードパーティのソースの Salesforce を選択します。 [認証の設定] で、先ほど確認した Client ID、Client Secret、Instance URL を入力します。 [詳細オプション] の [Enable Static IP Addresses] では Salesforce 側で IP アドレスの制限をしていないため、オフのままにします。 [同期するエンティティ] は任意のエンティティを選択します。今回の検証では、全てのエンティティを同期します。 コネクタ作成後に、[データの取り込みアクティビティ] を確認します。ステータスが成功していれば完了です。 参考 : Connect Salesforce 検証 ナビゲーション メニューで、[プレビュー]をクリックします。 この画面から、Salesforce に作成したテスト用顧客データを参照できるか、実際に問い合わせてみます。 プロンプトに「顧客情報を教えてください」と入力すると、Salesforce のテスト用顧客データを参照できました。 松尾 和哉 (記事一覧) クラウドソリューション部クラウドデベロッパー課 これまで主にAWSを活用する企業でインフラエンジニアとして従事していました。Google Cloudに魅力を感じてG-genにジョイン。アウトプットを経てコミュニティへの還元や自己研鑽をしたいと思っています。

G-genの福井です。Google Cloud の Document AI を使い、独自 OCR モデルを開発する手順を紹介します。 はじめに 当記事の概要 Document AI とは カスタム エクストラクタとは 事前準備 サンプルレシート画像の準備 カスタム エクストラクタの作成 プロセッサの作成 ラベルの定義 データセットの準備とインポート アノテーション作業 デプロイ・テスト 基盤モデルの新しいバージョンを作成 デプロイ テスト API 呼び出し はじめに 当記事の概要 当記事では、Google Cloud が提供する Document AI の カスタム エクストラクタ 機能を使用して、買い物のレシートから特定の情報を抽出する独自 OCR モデルを開発します。 買い物レシートからは、以下の項目を抽出します。 店舗名 購入日時 商品名 商品の値段 合計金額 Document AI とは Document AI は、Google Cloud（旧称 GCP）が提供するドキュメント処理プラットフォームです。スキャンされた書類や PDF ファイルなど、非構造化データから構造化された情報を抽出、分類、分析できます。請求書、領収書、身分証明書など、様々なドキュメントタイプに対応した事前トレーニング済みのモデルが用意されているほか、独自のドキュメントに合わせてモデルをカスタマイズ（カスタム エクストラクタ機能）することも可能です。 Document AI に関する詳細は、以下の記事も参照してください。 blog.g-gen.co.jp カスタム エクストラクタとは カスタム エクストラクタ は、特定のドキュメントタイプや抽出したい項目に合わせて、ユーザーが独自にトレーニングできる Document AI の機能です。事前トレーニング済みモデルでは対応できない、独自の帳票や特定のレイアウトを持つドキュメントからの情報抽出を実現します。 カスタム エクストラクタには、主に以下の 2 種類があります。 基盤モデル（生成 AI） 抽出したいフィールドを定義するだけで、大規模言語モデル（LLM）が自動的に情報を抽出するため、アノテーション作業は基本的に不要です。 より柔軟なドキュメント形式に対応できますが、精度はドキュメントの質やフィールドの定義に依存します。 0〜50 件以上のドキュメントでモデルが作成できます。 カスタムモデル 抽出したいテキストの箇所と、それに対応するラベル（例 : 「店名」「合計金額」）を手動でアノテーション（教師付け）してモデルをトレーニングします。 生成 AI を使用せずに、固有のドキュメントに沿った独自のモデルを構築できます。 10〜100件以上のドキュメントでモデルが作成できます。 　 今回は、 基盤モデル（生成 AI） のカスタム エクストラクタを作成します。 参考 : 生成 AI を使用したカスタム フィールド抽出 | Google Cloud 参考 : ラベルベースのカスタム フィールド抽出 事前準備 サンプルレシート画像の準備 基盤モデル（生成 AI）のトレーニングとテストに使用するレシート画像を準備します。今回は、レシートを 10枚程度 用意し、スキャンまたは写真で撮影して JPEG 形式で保存します。 今回準備した画像ファイルは、トレーニング用とテスト用にフォルダを分けて管理します。 フォルダを分けずに管理した場合でも、ドキュメントをインポートする際に、Document AI の機能でトレーニング用とテスト用に自動分割することが可能です 参考 : サポートされているファイル カスタム エクストラクタの作成 プロセッサの作成 Google Cloud コンソールの Document AI 画面で、[カスタム プロセッサ] > [Custom Extractor] の [プロセッサを作成] を選択します。 Custom Extractor のプロセッサを作成を選択 プロセッサ名に AICustomExtractor と入力し、[作成]を選択します。 プロセッサの作成を選択 ラベルの定義 抽出したい情報を示す「ラベル」を定義するため、プロセッサの画面で [開始] > [フィールドを新規作成] を選択します。 フィールドを新規作成を選択 新しいラベルを作成 以下の項目を順番に追加します。 名前 親ラベル データ型 オカレンス 説明 shop_name No 書式なしテキスト 必須の1回 店舗名 purchase_datetime No 日時 必須の1回 購入日時 total_amount No 通貨 必須の1回 合計金額 item Yes - 必須の複数回 商品 作成した [item] フィールドの [子を追加 フィールド] を選択し、以下の項目を順番に追加します。 名前 親ラベル データ型 オカレンス 説明 name No 書式なしテキスト オプションの1回 商品名 price No 通貨 必須の1回 商品の値段 ラベル一覧 データセットの準備とインポート トレーニング用のドキュメントを取り込むため、プロセッサの画面で [ビルド] > [ドキュメントのインポート] を選択します。 ドキュメントのインポートを選択 以下を選択し、[インポート] を選択します。 [Google Cloud Storage からドキュメントをインポートする] を選択 転送元のパス : 事前準備でトレーニング用のサンプルレシート画像を格納したフォルダを指定 データ分割 : トレーニング ドキュメントのインポート アノテーション作業 定義したラベルを、実際のドキュメント上のテキストに対応付ける作業（アノテーション）するため、プロセッサの画面で [ビルド] > [ラベル付けを開始] を選択します。 ラベル付けを開始を選択 定義したラベルが、トレーニング用ドキュメントのテキストに対応付けされた状態で表示されます。 生成AIがラベル付けしたドキュメント アノテーションが正しくない場合は、手動での調整が可能です。 今回の場合、以下の項目が正しくないため手動で調整します。 項目名 現状の値 期待値 shop_name デランシー・ケータリング 東京ディズニーシー デランシー・ケータリング price（一例） ¥2,500軽 2,500 total_amount ¥2,750 2,700 アノテーションを手動で調整する場合は、レシート画像の紫色の BOX を選択し、図形描画の拡大・縮小の操作で、期待値となるよう紫色の BOX を変更します。変更が完了した後に、[CONFIRM] を選択します。 調整対象のアノテーションを選択した状態 アノテーションの調整を行った状態 すべてのアノテーション調整が完了した後、[ラベル付きとしてマーク] を選択します。 すべてのアノテーションの調整が完了した状態 ラベル付きとしてマークすることで、ドキュメントに対するアノテーションが確定します。アノテーションを確定させると次のドキュメントに切り替わるため、トレーニング用ドキュメントに対して、この確認と調整を繰り返します。 すべてのドキュメントに対してアノテーションを行った状態 デプロイ・テスト 基盤モデルの新しいバージョンを作成 学習させたモデルの新しいバージョンを作成するため、プロセッサの画面で [ビルド] > [基盤モデルを呼び出す] の [新しいバージョンを作成] を選択します。 基盤モデルの新しいバージョンを作成を選択 バージョン名、ベースのバージョンを選択し、[作成] を選択します。 基盤モデルの新しいバージョンを作成 参考 : カスタム エクストラクタ モデルのバージョン デプロイ 作成したバージョンを使用するため、プロセッサの画面で [デプロイと使用] > [作成したバージョン] の [︙] の [バージョンをデプロイ] を選択します。 バージョンをデプロイを選択 [デプロイ] を選択します。 バージョンのデプロイ テスト 作成したバージョンのテストするため、プロセッサの画面で [評価とテスト] > [バージョン] から作成したバージョンを選択します。 テスト対象のバージョンを選択 [テスト ドキュメントをアップロード] からテスト対象のドキュメントを選択します。 テスト対象のドキュメントを選択 期待通りの結果が取得できました。 テスト結果 API 呼び出し 作成したモデルは、Document AI の API 経由で利用できます。ここでは、 curl コマンドを用いて API を呼び出し、レシート画像の推論を実行します。結果は JSON 形式で返却されるため、自社システムへの組み込みも容易です。 以降に記述するコマンドは、Cloud Shell で実行します。実際に試す際は、ご自身の環境に合わせてコマンドを適宜変更してください。 OCR 対象とするドキュメントを Base64 文字列にエンコードします。 base64 -w 0 my_document.jpg > encoded_content.txt API に送信するリクエストの内容を記述した JSON ファイルを作成します。 以下の内容を request.json に記述します。 mimeType は処理するファイルの種類に合わせてください。 content には、一つ前の手順で生成した Base64 文字列を貼り付けます。 { " skipHumanReview ": true , " rawDocument ": { " mimeType ": " image/jpeg ", " content ": " ここに encoded_content.txt の中身を全て貼り付けてください " } } curl コマンドを実行して Document AI API を呼び出します。 # ご自身のプロジェクト ID に置き換えてください PROJECT_ID = " YOUR_PROJECT_ID " # プロセッサがデプロイされているリージョン（例: us, eu）に置き換えてください LOCATION = " us " # 使用するプロセッサの ID に置き換えてください PROCESSOR_ID = " YOUR_PROCESSOR_ID " # API エンドポイント URL を組み立て API_ENDPOINT = " https:// ${LOCATION} -documentai.googleapis.com/v1/projects/ ${PROJECT_ID} /locations/ ${LOCATION} /processors/ ${PROCESSOR_ID} :process " # Document AI API を呼び出し curl -X POST \ -H " Authorization: Bearer $( gcloud auth application-default print-access-token ) " \ -H " Content-Type: application/json; charset=utf-8 " \ -d @request.json \ " ${API_ENDPOINT} " API 呼び出しの結果を一部抜粋して記載します。 { " type ": " item ", " confidence ": 1 , " id ": " 10 ", " properties ": [ { " textAnchor ": { " textSegments ": [ { " startIndex ": " 193 ", " endIndex ": " 203 " } ] } , " type ": " name ", " mentionText ": " カチューシャ フリー ", " confidence ": 1 , " pageAnchor ": { " pageRefs ": [ { " boundingPoly ": { " normalizedVertices ": [ { " x ": 0.3859127 , " y ": 0.33556548 } , { " x ": 0.48214287 , " y ": 0.33556548 } , { " x ": 0.48214287 , " y ": 0.35069445 } , { " x ": 0.3859127 , " y ": 0.35069445 } ] } } ] } , " id ": " 11 " } , { " textAnchor ": { " textSegments ": [ { " startIndex ": " 205 ", " endIndex ": " 210 " } ] } , " type ": " price ", " mentionText ": " 1,900 ", " confidence ": 1 , " pageAnchor ": { " pageRefs ": [ { " boundingPoly ": { " normalizedVertices ": [ { " x ": 0.58928573 , " y ": 0.34573412 } , { " x ": 0.6362434 , " y ": 0.34573412 } , { " x ": 0.6362434 , " y ": 0.35912699 } , { " x ": 0.58928573 , " y ": 0.35912699 } ] } } ] } , " id ": " 12 " } ] } 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進

G-genの杉村です。当記事では、Google Cloud の Gemini モデルなどの旧バージョンの廃止に関する注意点、そして組織内で該当モデルが使用されているかを確認する方法について解説します。 Gemini モデルのライフサイクルと廃止 廃止対象モデルとスケジュール 廃止予定モデルの使用状況確認方法 概要 課金レポートからの確認 データアクセス監査ログでの確認 推奨される対応 Gemini モデルのライフサイクルと廃止 Google Cloud の Vertex AI では、生成 AI モデルが継続的にアップデートされ、新しいバージョンが提供されます。モデルにはライフサイクルが設定されており、古いバージョンは 将来的に廃止 （retire）されます。 モデルの廃止は、通常、事前に告知期間が設けられます。しかし、この期間を過ぎると対象モデルは利用できなくなるため、利用中のモデルのライフサイクル情報を常に把握し、計画的に新しいバージョンへ移行することが重要です。 参考 : Model versions and lifecycle 廃止対象モデルとスケジュール 2025年12月現在、Google Cloud の公式ドキュメントに記載されている生成 AI モデルの廃止スケジュールのうち、一部を以下に示します。これらの情報は、今後のモデル廃止の参考としてご確認ください。最新情報や、実際に利用しているモデルについては、常に最新の公式ドキュメントを確認するようにしてください。 モデル名 廃止日（Retirement date） gemini-2.5-flash-preview-09-25 (※1) 2026-01-15 gemini-2.0-flash-001 2026-03-03 gemini-2.0-flash-lite-001 2026-03-03 gemini-2.5-pro 2026-06-17 gemini-2.5-flash 2026-06-17 gemini-2.5-flash-lite 2026-07-22 (※1) ドキュメントに記載はないが Google Cloud 管理者宛てにメール配信された なお、最新情報を得るためには、以下のリンクから英語版のドキュメントを参照するようにしてください。 参考 : Model versions and lifecycle 「廃止日」を迎えると、そのモデルへの API リクエストは 404 Not Found エラーとなります。これらのモデルを利用している場合、廃止日までに後継のモデルへの移行を完了させる必要があります。 また、廃止日前のある時期（1ヶ月程度前）から、廃止予定のモデルは、新規作成される Google Cloud プロジェクトや、過去にこれらのモデルを使ったことのないプロジェクトでは利用不可になります。 廃止予定モデルの使用状況確認方法 概要 廃止予定のモデルが、自組織の Google Cloud 環境で使用されているかを調査するには、以下の方法があります。 課金レポートでの確認 データアクセス監査ログでの確認 前者の 課金レポートでの確認 では、ある請求先アカウントに紐づくすべてのプロジェクトで、特定のモデルが使われているかどうかを確認できます。課金情報から確認するので、全体的な使用ボリュームや、組織の中のどのプロジェクトで利用されているかを把握できます。 後者の データアクセス監査ログでの確認 では、プロジェクトのレベルで、どのクライアントから API が呼び出されているか、どの時間帯で利用されているか、などの詳細を確認できます。ただし、プロジェクトや組織でデータアクセス監査ログが有効化されている必要があります。組織レベルで監査ログを集約している場合は、組織全体の利用状況を確認することもできます。 課金レポートからの確認 Google Cloud の課金レポートを参照することで、利用しているサービスとその SKU（Stock Keeping Unit）を確認できます。廃止対象のモデルを利用している場合、そのモデル名を含む、あるいは関連する SKU が課金レポートに表示される可能性があります。 確認手順の概要は以下の通りです。 1. Google Cloud コンソールの「課金」ページに遷移（上部検索ボックスで「課金」と入力し、サジェストされる「課金」を選択等） 2. 「リンクされた請求先アカウントに移動」を押下、もしくは「請求先アカウントを管理」から対象の請求先アカウントを選択 3. 左部メニューから「レポート」を選択 4. 右部フィルタで、グループ条件を「プロジェクト」に変更 右部フィルタで、グループ条件を「プロジェクト」に変更 これにより、グルーピングの条件がプロジェクトになり、プロジェクトごとの料金が表示されます。 5. 右部フィルタで、SKU を「Gemini 2.0」などで絞り「フィルタされた結果の数」の横のチェックボックスを押下して全選択 右部フィルタの SKU SKU を廃止予定モデル名などで絞り「フィルタされた結果の数」の横のチェックボックスを押下して全選択 これにより、各プロジェクトで Gemini 2.0 と名前のつく課金 SKU がどれだけ発生しているかが確認できます。SKU の名称は、モデルの種類や利用方法（例: Prediction、Training）によって異なるため、詳細はご自身の課金レポートをご確認ください。また、生成 AI 関連の SKU の一覧は、以下のドキュメントに記載されています。 参考 : SKU Groups - Gen AI この画面では、プロジェクトを絞ったり、グルーピング条件を SKU にするなどして、どのプロジェクトでどの課金がどれだけ発生しているかを確認できます。 この方法により、同じ請求先アカウントに紐づくすべてのプロジェクトの請求状況を横断して確認できるので、廃止予定のモデルが組織内のどのプロジェクトでどれだけ使われているか、 横串で確認 することが可能です。 参考 : レポートを使用して請求データと費用の傾向を分析する データアクセス監査ログでの確認 廃止予定モデルを使っているプロジェクトが確認できたら、次はプロジェクトレベルで、どのモデルが呼び出されているかをより詳細に確認することができます。 Cloud Audit Logs のデータアクセス監査ログを利用することで、呼び出し元クライアントの情報、日時、認証情報などが確認できます。この方法を利用するには、 API 呼び出しに先んじて 、プロジェクトで Vertex AI API の データアクセス監査ログが有効化 されている必要があります。データアクセス監査ログは、デフォルトでは無効になっているため、設定を確認し、必要に応じて有効化してください。 Cloud Audit Logs やデータアクセス監査ログの詳細については以下の記事を参照してください。 blog.g-gen.co.jp データアクセス監査ログが有効な場合、Cloud Logging のログエクスプローラで以下のようなクエリを実行することで、特定のモデルの呼び出しログを抽出できます。 protoPayload.resourceName:( " gemini-2.0-flash-001 " OR " gemini-2.0-flash-lite-001 " ) このクエリは、 protoPayload.resourceName フィールドに指定されたモデル名が含まれるログエントリを検索します。 resourceName には、呼び出された Vertex AI エンドポイントやモデルリソース名が含まれるため、これによって廃止対象モデルの利用状況を確認できます。 推奨される対応 廃止対象のモデルを利用していることが確認された場合は、以下の対応を検討します。 後継モデルの調査と選定 Google Cloud のドキュメントを参照し、廃止対象モデルの機能や特性をカバーできる後継の安定版モデルや、より新しいバージョンのモデルを選定 移行計画の策定 アプリケーションコードの修正、テスト、デプロイメントスケジュールを含む移行計画を策定 段階的な移行とテスト 可能であれば、一部のトラフィックから新しいモデルに移行し、動作検証を十分に行った上で全面的な移行を実施 情報収集の習慣化 Vertex AI のリリースノートや、Google Cloud からの通知を定期的に確認し、利用中サービスのライフサイクル情報を常に最新の状態に保つ モデルの廃止は、セキュリティの向上、パフォーマンスの改善、新機能の提供といったメリットを享受するために必要なプロセスです。計画的な対応を心がけることで、サービスへの影響を最小限に抑えることができます。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の溝口です。この記事では NotebookLM を使った情報整理と「Discover（ソースの発見）」「音声概要」「マインドマップ」などの応用機能を使った活用テクニックについて解説します。 NotebookLM とは Discover によるソース検索 音声概要の生成 マインドマップ NotebookLM とは NotebookLM とは、Google が提供している、AI を活用したリサーチ・ライティングのアシスタントツールです。無償の Google アカウントで利用できる NotebookLM の他に、Google Workspace に付帯している NotebookLM in Pro（旧称 NotebookLM Plus）があります。 NotebookLM と NotebookLM in Pro の主な違いとして、ノートブック数やソース数、1日のクエリ数、音声生成数などの上限の違いや、サポートの提供有無が挙げられます。NotebookLM in Pro は、NotebookLM のヘビーユーザーや、ビジネスでの利用に適しています。 参考 : NotebookLM無償版・Pro・Enterpriseの違い - G-gen Tech Blog 当記事では、技術イベントである Google Cloud Next '25 のイベントの情報収集を題材にして、NotebookLM を使った情報整理と「 Discover （ソースの発見）」「 音声概要 」「 マインドマップ 」などの応用機能を使った活用テクニックについて解説します。 NotebookLM in Pro の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Discover によるソース検索 まずは、調べたい情報を選定します。今回は 2025年4月下旬にラスベガスで開催された Google Cloud Next '25 で発表された公開情報を収集し、NotebookLM 上で整理・活用することを目的とします。 NotebookLM では通常、ユーザーがデータソースを選択しアップロードする必要がありますが、 Discover （ソースの発見）と呼ばれる機能を使うと、Web で公開されている関連ページが自動で検索・提案されます。 ソースを追加する画面で、[追加] ボタンの隣にある [検索] を選択すると、提供元を検索するウィンドウが立ち上がります。 ソース追加画面 ([検索] ボタン) 今回は「2025年にラスベガスで行われた Google Cloud Next で発表された内容について興味があります」と検索します。 ソースの検索ウィンドウ キーワードに基づいて、関連する Web ページがソース候補として表示されました。画面下の [インポート] をクリックすると、これらの Web ページが NotebookLM のソースとして追加されます。 検索結果画面 以前はソースとなる Web ページを追加する際、URL を一つずつ指定する必要がありましたが、この機能により操作が容易になりました。 今回は10件のソースを選出してくれましたが、データソースをさらに増やすために、Gemini アプリの Deep Research も併せて利用しました。Deep Research が探し出した複数の Web サイトを、手動で追加します。 参考 : Gemini Deep Research — your personal research assistant 検索結果がソースとして追加された状態 音声概要の生成 ソースの準備ができたら、NotebookLM の Studio 機能を利用して 音声概要 を作成します。 NotebookLM の音声概要機能では、AI が音声コンテンツを生成します。この音声では、2人の登場人物がソースの内容について対話形式で概要を説明します。 デフォルトでは、音声概要は英語で生成されます。画面右上の「設定」ボタンを押下すると表示されるプルダウンメニューから「出力言語」を選択し、出力言語として日本語を選択してください。 出力言語の変更 日本語を選択 次に、NotebookLM の画面右側の Studio エリアにある [生成] をクリックします。 Studio 機能の [生成] ボタン 数分待つと、音声概要が生成されました。この音声は再生速度を変えて再生したり、ダウンロードすることもできます。 日本語で生成された音声概要 音声概要の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp マインドマップ 情報を視覚的に整理したい場合は、 マインドマップ 機能も利用できます。 Studio 機能の [マインドマップ] 画面中央部のチャットエリアにある「マインドマップ」を押下すると、選択したソースの情報に基づいて、NotebookLM が自動でカテゴリを分類し、マインドマップ形式で表示します。 作成されたマインドマップ マインドマップのノードを展開した状態 溝口 直 (記事一覧) ビジネス推進部 営業2課 2023年10月よりG-gen にジョイン。 HRサービスを展開するベンチャー企業から、Google専業の営業へ。関西在住でGoogle Cloudをメインに活動中。育児と仕事のバランスを常に模索中・・