G-gen 粉もん事業所（関西在住）の米川です。当記事では Google Cloud（旧称 GCP）の利用に必要な Google アカウントについて解説します。 はじめに アカウントの概念 アカウントとは Google アカウントとは Google Cloud と Google アカウント Google アカウントの使い道 アクセス制御（認証・認可） 請求情報の管理 Google アカウントの種類 3種類の Google アカウント 個人用 Google アカウント Google Workspace アカウント Cloud Identity アカウント Google Cloud 利用開始の流れ Google アカウントの準備 支払い方法の決定 申込み セキュリティ Google アカウントの安全性 2段階認証 不正ログイン発覚時の対処を理解しておく 外部共有設定の見直し プライバシー はじめに Google Cloud の利用を始めるには Google アカウント が必要です。 初めて Google Cloud を利用する場合、「会社のグループウェアが Microsoft 365 で、Google には馴染みがなくてよく分からない」「個人の Gmail アドレスのことなのか」といった質問をよく受けるため、当記事では Google アカウントの概念から解説していきます。 Google アカウントの基本的な仕組みや、Google Cloud の利用を始める際に必要な手続き、Google アカウントのセキュリティなどについて解説します。 アカウントの概念 アカウントとは アカウントの語源は「account = 口座」ですが「Google アカウント」という言葉における「アカウント」とは、クラウドサービスや Web システムにログインするための 「ID」である とお考えください。 クラウドサービスや Web システムにログインするときは、アカウント名（ID 名）とパスワードを入力して、システムにログインすることになります。「ID 名」の部分は、メールアドレスになることも多いです。 Google アカウントとは Google アカウントとは、Google の各種サービスにログインするための ID です。 Google サービスの例として、Gmail、YouTube、Google マップ、Google Workspace、Google Cloud 等があります。さらに身近な例だと、Android スマホにログインする際にも Google アカウントを使います。 Google 以外のサードパーティのサービスでも、Google アカウントがログインに使われるケースもあります。 Google アカウントの概念 Google アカウント名は john-doe@example.com のように メールアドレスの形式 をしています。Google アカウント名がそのまま、そのアカウントのメールアドレスとなります。原則的には、 1人の人（個人、従業員）に対して1つのアカウント を発行します。 なお、Amazon Web Services（AWS）のご利用経験がある方は「AWS アカウント」という言葉をお聞きになったことがあるかもしれません。AWS アカウントは AWS を利用するための「テナント」の概念であり、Google Cloud においては「プロジェクト」という用語がそれに当たります。AWS アカウントがテナントである一方、Google アカウントは ID に当たるものですので、ご留意ください。 Google Cloud と Google アカウント Google アカウントの使い道 Google Cloud を利用するには Google アカウントが必須 です。Google Cloud において、Google アカウントは以下のように使われます。 アクセス制御（認証・認可） 請求情報の管理 アクセス制御（認証・認可） Google Cloud では、 IAM （Identity and Access Management）という認証・認可の仕組みにより、クラウド管理者がどのクラウドサービスやクラウドリソースにアクセスできるかを制御します。 たとえば「情報システム部門員のアカウントは Google Cloud プロジェクトを自由に作成することができる」「事業部門の開発者のアカウントは、自分のプロジェクトの中のリソースのみを編集することができる」のように、詳細にアクセス制御を行うことができます。 Google Cloud を利用するには、例として以下の操作が必要です。 Google Cloud プロジェクトの作成 請求情報の管理（作成、閲覧、設定変更、削除） リソース（Compute Engine VM や BigQuery テーブル）の管理（作成、閲覧、設定変更、削除） これらの操作を行うには、適切な権限を持った Google アカウントにログインしている必要があります。これらの操作のうち、誰が、どの操作を行うことができるかを定義する仕組みが、IAM だと理解してください。IAM については、以下の記事で詳細に解説しています。 blog.g-gen.co.jp 請求情報の管理 Google Cloud では、サービスを利用した分だけの料金が発生します（従量課金制）。Google Cloud の利用料金の請求先は 請求先アカウント という設定で指定することができます。「請求先アカウント」にはアカウントという言葉が使われていますが、Google アカウントとはまったく別の概念です。 請求先アカウントを Google Cloud プロジェクトに紐づけることで、その請求先アカウントに設定された請求先に対して料金が発生します。請求先アカウントとプロジェクトの紐づけを管理するには、Google アカウントが必要です。 Google Cloud の請求の仕組みについては、以下の記事も参照してください。 blog.g-gen.co.jp Google アカウントの種類 3種類の Google アカウント Google アカウントには、3つの種類があります。違いを理解して、目的に合った種類のアカウントを選択してください。以下の表は、使い分けの概要です。 種類 対象 料金 ユースケース 個人用 Google アカウント 個人 無償 ・個人で Google サービスを利用する ・個人で Google Cloud を利用する Google Workspace アカウント 組織 有償 ・組織で Google のグループウェアを利用する ・組織で Google Cloud を利用する Cloud Identity アカウント 組織 無償 (※) ・組織で Google Cloud を利用する ※ 51 アカウント以上は有償 個人用 Google アカウント 個人用 Google アカウント は、Gmail アカウントとも呼ばれます。ドメイン（@以降の文字列）は @gmail.com や @googlemail.com です。個人用 Google アカウントは無償で作成でき、Gmail や YouTube などの Google サービスにログインするために使用されます。 Google Cloud でも使用できますが、組織のセキュリティポリシー設定などの管理機能が利用できないため、企業や組織で運用するには不向きです。 Google Workspace アカウント Google Workspace アカウント は、企業や組織が従業員に提供するビジネス向けの Google アカウントです。 Google Workspace アカウントを作成するには、Google Workspace の有償プランの契約が必要になります。また、Google Workspace のテナント開設時にドメインの所有権の確認が求められるので、ドメインを購入していない場合は、お名前.com などのドメイン購入サービスで手続きをする必要があります。 Google Workspace の各プラン比較については、以下の記事で解説しています。 blog.g-gen.co.jp Cloud Identity アカウント Cloud Identity アカウント は、Cloud Identity という Google サービスで払い出したアカウントです。Cloud Identity は「Google Workspace から Google ドキュメントや Gmail などグループウェアの仕組みを取り除き、アカウント管理に特化したサービス」であるとお考えください。 例えば「Microsoft アカウントは持っているが Google Workspace の契約は持っておらず、Google Cloud に利用できるアカウントを準備したい」といった企業で、Cloud Identity が採用されます。 Cloud Identity には Free エディションがあり、無償で50アカウントまで発行できます。有償の Cloud Identity Premium にアップグレードすることで、50個以上のアカウントを発行可能になります。また Free エディションのままでも、Google に申請することで上限数が緩和される場合があります。上限緩和には Google の審査が入りますので、必ず上限緩和が可能であるとは限らない点にご留意ください。 参考 : Cloud Identity Free Edition ユーザーの上限数 Cloud Identity でも Google Workspace と同様、テナント開設時にドメインの所有権確認が求められるので、ドメインの購入が必要です。 Cloud Identity の登録手順については、以下の記事をご参照ください。 blog.g-gen.co.jp Google Cloud 利用開始の流れ Google Cloud の利用で必要な手続き Google アカウントの準備 組織（企業や官公庁）で Google Cloud を利用するには、Google アカウントを準備するために組織内への説明や稟議等に時間を要すことが多いため、まずは Google アカウントの準備を早めに着手することをおすすめします。 支払い方法の決定 Google Cloud の利用料金は、「クレジットカード払い」もしくは「請求書払い」のいずれかから選択します。 請求書払いを希望する場合は、Google Cloud のリセールパートナーのサービスを利用すれば、パートナー各社独自のサービスの恩恵を受けることができます。 リセールパートナーとしては、当記事を公開している G-gen 社が挙げられます。同社の請求代行サービスでは、独自の割引制度に加え、無償の技術サポート窓口やセキュリティ自動設定テンプレート等、いくつかの特典があります。 g-gen.co.jp 申込み Google アカウントへログインした状態で Google Cloud のコンソール画面にアクセスすることで、Google Cloud を利用開始できます。 Google との直接契約の場合は、画面の指示に従って請求先アカウントを新規で作成し、Google Cloud プロジェクトと紐づけます。 リセールパートナーを利用する場合は、サービス提供会社ごとに手続きは異なります。G-gen 社の場合、同社の請求代行サービスに申し込むと、請求先アカウントが同社から払い出されます。その請求先アカウントを Google Cloud プロジェクトと紐づけるだけで、利用を開始することができます。 セキュリティ Google アカウントの安全性 セキュリティ設定を適切に行うことで、アカウントの乗っ取りや不正アクセスを防ぎ、安全に利用することができます。Google アカウントには多様なセキュリティ設定が存在しますが、特に推奨されるのは以下です。 2段階認証プロセスを有効にする 不正ログイン発覚時の対処を理解しておく 外部共有設定の見直し 参考 : アカウントのセキュリティを強化する 2段階認証 2段階認証 では、スマートフォンや認証アプリ、携帯電話番号など2段階目の認証を追加することで、万が一パスワードが漏洩しても他者がアカウントにログインできなくなります。 現代の Web システムでは、2段階認証の設定は 必須 とされていますので、必ず設定しましょう。 参考 : 2 段階認証プロセスでビジネスを保護する 不正ログイン発覚時の対処を理解しておく Google Workspace や Cloud Identity の管理者が、 不正ログイン発覚時の対処を理解しておく ことは重要です。Google Workspace や Cloud Identity では、不正ログインが疑われるような不審なアクティビティが発生した場合、管理者にメールで通知されます。 メールを受け取る管理者を適切に設定しておき、不正ログインが疑われる場合は アカウントを一時的に停止 するなどのアクションが必要です。手順を事前に確認しておきましょう。 参考 : 不正使用されたアカウントを特定して保護する 外部共有設定の見直し Google Workspace における情報漏洩の典型は、Google ドライブの設定を誤っていたことにより、ファイルがインターネットに公開されていたり、アクセスすべきでない人がアクセスできる状態になっていたことに由来します。 Google ドライブでは、ファイルを共有できる先を詳細に制御することができます。また「ファイルを閲覧できるが、ダウンロードやコピーは禁止する」のような設定も可能です。 公式ドキュメントを確認し、情報共有先を適切に設定しましょう。 参考 : 管理者として共有ドライブを管理する 参考 : 共有を停止、制限、変更する 参考 : 組織の外部共有を管理する プライバシー Google アカウントを利用していることで Google から取得される利用者情報は多数ありますが、特に重要なものとして以下が挙げられます。 名称 概要 アカウント情報 名前、メールアドレス、パスワード、電話番号、デバイス情報など サービス利用情報 利用したアプリ、ブラウザ上で操作した内容、閲覧履歴など 位置情報 スマートフォンを持って訪れた場所など これらの履歴情報は、Google アカウントの管理画面で取得をオフにすることもできます。Google サービスのパーソナライズをしたくない場合や、業務で不要な場合はオフにする設定が可能です。 今自分が使っている Google アカウントのプライバシー設定がどうなっているかは「プライバシー診断」機能でチェックすることができます。 参考： Google アカウント データの概要の確認 参考： プライバシー診断 米川 佐満人 (記事一覧) プラットフォームエンジニアリング本部 営業部 営業2課 兼 粉もん事業所 2022年7月にG-genにジョイン。 モットーは「クラウドで、関西を、もっと働きやすく」 課題解決に向けた提案＆お客様との伴走プロジェクトにモチベーションを感じる日々。現在 Google Cloud 全資格コンプリート目指して奮闘中（あと1つ）。ですが、本職は 光の戦士@FFXIV です。

G-gen の杉村です。BigQuery には スナップショット と クローン と呼ばれる機能があり、ストレージ料金を節約しつつテーブルを瞬時に複製することができます。これらの機能について解説します。 スナップショットとクローン スナップショットとは / クローンとは 共通の性質 コピーオンライト ユースケース スナップショット クローン 料金 利用と運用 スナップショットやクローンの作成 スナップショットからの復元 定期的なスナップショット取得 制限 スナップショットとクローン スナップショットとは / クローンとは Google Cloud（旧称 GCP）のデータウェアハウスである BigQuery には、 スナップショット と クローン と呼ばれる機能があります。いずれも、ストレージ料金を節約しつつ、テーブルを瞬時に複製する機能です。 スナップショットとクローンは似た性質を持っています。スナップショットは 読み取り専用 で、クローンは 読み取りと書き込みの両方 が可能です。「スナップショットの書き込み可能版がクローン」と言うこともできます。 参考 : テーブル スナップショットの概要 参考 : テーブル クローンの概要 共通の性質 スナップショットとクローンは、以下の性質が共通しています。これは、後述のコピーオンライトという実装方法によるものです。 ベーステーブル（元となるテーブル）からのスナップショット / クローン作成は瞬時に完了する スナップショット / クローン作成直後は、ストレージ料金が発生しない ベーステーブルのデータに変更や削除が発生すると、その差分のストレージ料金が発生する（クローンでは追加した分のデータのストレージ料金も発生する） ベーステーブルへのデータが追加されても、スナップショット / クローンの料金は発生しない コピーオンライト スナップショットとクローンでは、ある瞬間のテーブルのデータをまるごと複製しているはずなのに、複製が瞬時に完了しますし、ベーステーブルに変更がなければストレージ料金が発生しません。不思議なように思われますが、これは コピーオンライト （Copy-on-Write）という実装手法のおかげです。 コピーオンライトでは、はじめにデータを複製するときに、実際にデータを複製するわけではなく、データを複製した「ふり」だけをします。複製した先のデータが誰かに参照されるときは、参照者が意識しないまま複製 元 のデータを参照させます。 しかしこれでは、複製元のデータに変更や削除があると、データは参照できなくなってしまいます。そのため複製元のデータが変更または削除されるタイミングで、実際にデータを複製します。実際の複製後は、参照者は複製先データを参照することになります。 コピーオンライト BigQuery のスナップショットやクローンで、作成が一瞬で終わったり、削除・変更があったデータのみに料金が発生するのは、このコピーオンライト手法の性質によって説明できます。 このコピーオンライト手法は、仮想記憶方式の OS のメモリ管理で利用されているほか、一般的にストレージ製品のバックアップ（スナップショット）機能などでも用いられています。 ユースケース スナップショット スナップショットのユースケースは、以下のようなものです。 論理バックアップ目的や検証目的で、ストレージ費用を最小にしつつ、テーブルの現在の時点のデータを保存しておきたい 前述の性質上、特に既存データの変更が少ないテーブルで、ストレージ費用を抑える効果が顕著に現れます。またベーステーブルにデータ追加があってもスナップショット料金には影響はありませんので、データ追加はあるが変更は少ない、というテーブルでも効果が高いといえます。 なおテーブルのある時点のデータを取っておく機能としては他にタイムトラベル機能が存在していますが、タイムトラベルは7日間までしか保管されないため、それ以上の保持期間が必要な場合にはスナップショットを検討します。 論理バックアップの目的でスナップショットを作成する場合、データセットの誤削除などにも対応できるよう、スナップショットはベーステーブルと別のデータセットに作成することが推奨されます。 参考 : タイムトラベルとフェイルセーフによるデータの保持 クローン クローンのユースケースは、以下のようなものです。 開発やテスト目的で、ストレージ費用を最小にしつつ、本番テーブルのコピーを作成して読み書きしたい こちらも、データ追加はあっても、既存データの変更が少ないテーブルで、ストレージ費用を抑える効果が顕著に現れます。 クローンはベーステーブルからは独立しているため、片方の反映がもう片方に影響を与えることはありません。 料金 前述の通り、スナップショットとクローンでは、作成直後には料金が発生しません。ベーステーブルに変更や削除があった場合に初めてストレージ料金が発生します。またクローンでは、クローンに追加したデータ分のストレージ料金も発生します。 ストレージは料金単価は、BigQuery の通常のストレージ料金単価と同様です。 参考 : BigQuery pricing - Storage pricing ただし、以下のような性質に留意が必要です。 BigQuery が列志向でデータを保持する性質上、べーステーブルへのわずかな変更により、実際に変更した分よりも大きなストレージ料金を発生させる可能性がある べーステーブルへのある程度の変更により、スナップショット（クローン）の全ストレージ分の料金が発生する場合がある。例として、ベーステーブルがクラスタリングテーブルであり、自動的な再クラスタリングによってベーステーブルのストレージブロック全体に書き換えが発生した場合などが挙げられる ベーステーブルがパーティションテーブルであれば、変更がパーティション内に閉じるため、ストレージ費用を抑えられる場合がある クラスタリングやパーティションについては、以下の記事もご参照ください。 blog.g-gen.co.jp 利用と運用 スナップショットやクローンの作成 スナップショットは、Web コンソール画面、SQL（DDL）、bq コマンド、または API 経由で作成することが可能です。クローンもほぼ同様の手段で作成できますが、2023年12月現在はコンソール画面では作成できません。 また、タイムトラベル機能を利用して、あるテーブルの過去の任意の時刻の状態のスナップショットやクローンを作成することもできます。 スナップショットは有効期限を設定でき、有効期限経過後は自動的に削除されます。 作成手順は以下の公式ドキュメントをご参照ください。 参考 : テーブル スナップショットの作成 参考 : テーブル クローンを作成する スナップショットからの復元 スナップショットから、実テーブルを生成することができます。これを 復元 （Restore）と呼びます。 コンソールではスナップショットの詳細画面から、RESTORE ボタンを押下します。 SQL では、以下のような CREATE TABLE 文を実行します。 CREATE TABLE ${project_id}.${dataset_id}.${new_table_name} CLONE ${project_id}.${dataset_id}.${snaphost_name}; また bq コマンドや API 経由でも、リストアを実行できます。詳細は以下のドキュメントをご参照ください。 参考 : テーブル スナップショットを復元する 定期的なスナップショット取得 スケジュールドクエリ機能を使い、定期的にスナップショットを作成する DDL を実行することで、定期的なスナップショット取得が可能です。 詳細は以下の公式ドキュメントをご参照ください。 参考 : スケジュールされたクエリを使用してテーブル スナップショットを作成する 制限 スナップショットとクローンでは、以下のような制限があります。 スナップショット / クローンはベーステーブルと同じ組織（Organization）下、同じリージョン内にしか作成できない ビューやマテリアライズドビューのスナップショット / クローンは作成できない 外部テーブルのスナップショット / クローンは作成できない その他の制限は、公式ドキュメントをご確認ください。 参考 : テーブル スナップショットの概要 - 制限事項 参考 : テーブル クローンの概要 - 制限事項 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の藤岡です。当記事では、Google Cloud (旧称 GCP) で 2023 年 12 月 に GA (一般公開) された 組織ポリシーのドライラン機能 の使い方を紹介します。 概要 組織ポリシー ドライラン機能 Restrict Resource Service Usage 検証 前提 ドライランポリシーの作成 ログの確認 概要 組織ポリシー 組織ポリシー (Organization Policy) は、組織やフォルダ、プロジェクトに対して、統制を効かせるためのルールを強制的に適用できるサービスです。 例えば、以下のようなルールが適用できます。 特定のリージョン (ロケーション) 以外は使わせないようにする 特定のサービス (Compute Engine 等) 以外は使わせないようにする 組織ポリシーの詳細な解説は、以下の記事をご参照ください。 blog.g-gen.co.jp ドライラン機能 組織ポリシーではカスタム制約と、一部の事前定義された制約でドライラン機能を利用できます。ドライラン機能は、実際に制約を適用する前に影響を確かめることができる機能です。制約違反があった場合、操作自体は拒否されずに、Cloud Logging へのログ出力のみが行われます。 参考: ドライランの組織のポリシーを作成する 当機能は2024年1月現在で、カスタム制約への利用のみが GA であり、事前定義された制約は Restrict Resource Service Usage への利用のみが Preview (プレビュー) 版で提供されています。 Restrict Resource Service Usage Restrict Resource Service Usage の組織ポリシーは、Google Cloud で利用できるサービス (Compute Engine や Cloud Storage など) を制限できる制約です。 参考: リソース使用量の制限をサポートしているサービス Google Cloud では複数のサービスが連携して使われます。ユーザーからは 1 サービスしか利用していないように見えても、裏側では他のサービスも併せて利用されているケースもあります。そのため、ドライラン機能を使って本番影響を事前に検証することが重要になります。 以下の記事は、Cloud Functions の裏側で多くのサービスが動作していることを示しています。 blog.g-gen.co.jp 検証 前提 当記事では以下の前提とします。 Restrict Resource Service Usage の制約でドライランを検証 組織ポリシーはプロジェクトレベルで適用 設定に必要な権限は既に付与されていること ドライランポリシーの作成 組織ポリシーの画面から Restrict Resource Service Usage を検索し、以下の画面遷移をします。 ドライランポリシーの作成① 今回は Cloud Storage (storage.googleapis.com) の利用を制限するよう設定します。 ドライランポリシーの作成② ログの確認 ドライランのため、Cloud Storage のコンソール画面の閲覧やバケット作成などの操作は、問題なく実行できました。 その一方で、Cloud Logging のログを確認すると、Cloud Storage API の操作で警告のログが出力されていました。 適用確認 ログの中身は以下のようになっています。 { " protoPayload ": { " @type ": " type.googleapis.com/google.cloud.audit.AuditLog ", " status ": { " code ": 7 , " message ": " Request is disallowed by organization's Org Policy for 'projects/012345' attempting to use service 'storage.googleapis.com'. " } , " authenticationInfo ": { " principalEmail ": " fu...a@g-...p " } , " requestMetadata ": { " callerIp ": " xxxxx ", " requestAttributes ": {} , " destinationAttributes ": {} } , " serviceName ": " storage.googleapis.com ", " methodName ": " google.storage.buckets.getIamPolicy ", " resourceName ": " projects/012345 ", " metadata ": { " checkedValue ": " storage.googleapis.com ", " @type ": " type.googleapis.com/google.cloud.audit.OrgPolicyDryRunAuditMetadata ", " liveResult ": " ALLOWED ", " dryRunResult ": " DENIED ", " constraint ": " constraints/gcp.restrictServiceUsage " } } , " insertId ": " xxxxx ", " resource ": { " type ": " audited_resource ", " labels ": { " project_id ": " xxxxx ", " method ": " google.storage.buckets.getIamPolicy ", " service ": " storage.googleapis.com " } } , " timestamp ": " xxxxx ", " severity ": " WARNING ", " logName ": " projects/xxxxx/logs/cloudaudit.googleapis.com%2Fpolicy ", " receiveTimestamp ": " xxxxx " } ドライラン機能のログは protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.OrgPolicyDryRunAuditMetadata" として記録されています。 ログの中で、 protoPayload.metadata.dryRunResult （ドライランの結果）が DENIED になっている一方、 protoPayload.metadata.liveResult （実際にアクションが拒否されたかどうか）は ALLOWED になっています。 藤岡 里美 (記事一覧) クラウドソリューション部 数年前までチキン売ったりドレスショップで働いてました！2022年9月 G-gen にジョイン。今期は「おっさんずラブ」がイチオシです :) Google Cloud All Certifications Engineer / Google Cloud Partner Top Engineer 2024 Follow @fujioka57621469

G-genの杉村です。Google の提供する最新の生成 AI モデルである Gemini は、Google Cloud 環境をお持ちであれば、すぐに試してみることができます。Gemini Pro の使い方を簡単にご紹介します。 はじめに Gemini とは Gemini の試用 料金 Gemini の使い方 Vertex AI Studio へアクセス プロンプトの入力 パラメータの調整 高度な使い方 はじめに Gemini とは Gemini とは、Google が2023年12月初旬に発表した、最新の生成 AI モデルです。テキスト、画像、動画など、複数の種類のデータを扱える「マルチモーダル」な生成 AI モデルであり、テキスト生成、動画や画像の説明、コーディングの補助など、さまざまなタスクで高いパフォーマンスを出すとされています。 2025年7月現在、Gemini には、Gemini 2.5 Pro、Gemini 2.5 Flash 等、コストやレイテンシ、精度の異なる複数のモデルが用意されており、コスト・精度・レイテンシなどのトレードオフを考慮して最適なモデルを選択できるようになっています。 Gemini は、チャットツールとして一般のコンシューマや Google Workspace ユーザーから利用できる Gemini ウェブアプリ（ https://gemini.google.com ）から利用できるほか、Google Cloud の AI 開発プラットフォーム Vertex AI から、Web API 経由で呼び出して利用することができます。利用可能な Gemini プロダクトの一覧は、以下の記事も参照してください。 blog.g-gen.co.jp Gemini の試用 Google Cloud の Web コンソール画面からアクセスできる Vertex AI Studio を使うと、Gemini などの Google の AI モデルを簡単に試用することができます。Vertex AI Studio では、パラメータを変えながらプロンプトを投入し、生成 AI モデルがどのように生成物を変化させるかを、簡単に試すことができます。 Google アカウントや Google Cloud 環境がなくても、以下のリンクから Vertex AI Studio の試用版を使うことができます。この画面では、誰でも Gemini 2.5 Pro、Gemini 2.5 Flash や Gemini 2.0 Flash などを試用できます。面倒な登録も必要なく、利用規約に同意するだけです。 参考 : Vertex AI Studio - free trial 以下は、上記リンクからトライアル版の Vertex AI Studio で Gemini 2.5 Pro を試用した際のスクリーンショットです。画面上部のテキストボックスにテキスト情報を入力したり、画像や動画をアップロードして送信すると、テキストが生成されて返答されます。 参考 : Vertex AI Studio console experiences 料金 Gemini を、課金を有効化した Google Cloud プロジェクト経由で利用すると課金が発生します。 2025年7月現在、Gemini 2.5 Pro の課金体系は以下です（20万以下のコンテキストウインドウの入力の場合）。入力した画像、動画、テキストの量と、出力された生成コンテンツの量に応じた従量課金となります。入出力のサイズは、トークンと呼ばれる単位でカウントされます。 課金軸 料金単価 入力トークン $1.25 / 100万トークン 出力トークン (テキスト) $10 / 100万トークン 最新の情報は公式ドキュメントをご参照ください。 参考 : Cost of building and deploying AI models in Vertex AI Gemini の使い方 Vertex AI Studio へアクセス まず、以下のリンクにアクセスします。Google アカウントや Google Cloud 環境がなくても、以下のリンクから試用することができます。利用規約への同意を求められたら、確認のうえ同意してください。 参考 : Vertex AI Studio - free trial プロンプトの入力 この画面で、さまざまなプロンプト（生成 AI モデルへの入力データ）を入力し、Gemini にテキストを生成させることができます。 ①のテキストボックスには、Gemini に システム指示 として渡す文字列を入力できます。役割、回答のフォーマットや方向性などを指定することで、モデルの振る舞いを指示することができます。 参考 : システム指示 ②のテキストボックスには、プロンプトとして渡す文字列を入力できます。モデルに生成させたい内容を指示します。 ①と②でプロンプトを入力した後、③の送信ボタンを押下すると、生成結果が表示されます。 ④で、生成に使うモデルを指定します。Gemini 2.5 Flash、2.0 Pro、2.0 Flash などを指定できます。 パラメータの調整 画面右部分で、細かいパラメータを調整することができます。以下に、一部のみを紹介します。 ① Structured Output を指定することで、JSON 形式で Gemini に回答を生成させることができます。また、JSON のスキーマも細かく指定できます。 参考 : 生成制御機能 ② では、Google 検索や Google Maps、Vertex AI のデータストアなどを使ったグラウンディング（根拠づけ）をさせることができます。これにより、Gemini はインターネットから情報を検索し、生成したコンテンツの正確性を高めます。モデルによって、サポートされているグラウンディング先が異なります。 参考 : グラウンディングの概要 ③ の温度（Temperture）は、生成内容のランダム度合いを制御するパラメータです。一般的にいって、より正確な生成内容を求める場合は Temperture を0に近くし、よりクリエイティブで予想外の結果を求める場合は1に近くします。また出力トークンの上限は、返答されるトークン数の上限を定めます。1トークンは概ね4文字とされています。 参考 : コンテンツ生成パラメータ 高度な使い方 当記事では、Gemini を手軽に試用する方法を紹介しました。 以下の記事では、Gemini を Web アプリに組み込んで、生成 AI アプリを開発した例をご紹介しています。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

2024年2月1日以降、個人用の Gmail アカウントに対してメールを配信する送信者に対し、新しいメール送信者ガイドラインを適用することが発表されました。その要件の1つである DMARC の Gmail への設定方法について紹介します。 送信者ガイドライン 送信者ガイドラインの概要 5,000件/日以上の送信者向けのガイドライン SPF、DKIM DMARC 設定の方針 設定手順 ポリシー none で DMARC を設定する DMARC レポートを確認する 検疫対象を徐々に増やす 最終的にすべての不合格メールを拒否する DMARC 適用後の確認手順 Google Admin Toolbox (Check MX) メール受信側での確認 送信者ガイドライン 送信者ガイドラインの概要 2024年2月1日以降、Gmail で新しい「メール送信者のガイドライン」が適用されます。 対象は「個人用 Gmail アカウントに対してメールを送信するメール送信者」となります。なお個人用 Gmail アカウントとは、末尾が @gmail.com または @googlemail.com のアカウントを指します。メールの送信先が Google Workspace のメールアドレス（企業のアカウント）である場合は、このガイドラインの対象ではありません。 このガイドラインでは、個人用 Gmail アカウントに対してメールを送信するすべてメール送信者に、以下の要件が求められるものです。 SPF と DKIM が設定されていること 送信元のドメインまたは IP に、有効な正引きおよび逆引き DNS レコードが設定されていること メールの送信に TLS 接続が使用されていること Postmaster Tools で報告される迷惑メール率が 0.10% 未満であること メールの形式が基準に従っていること（後述の公式ドキュメント参照） これらの要件を満たしていない場合、メールが拒否されたり、迷惑メールに分類されたりする可能性があるとされています。詳しくは、以下の公式ドキュメントも参照してください。 参考 : メール送信者のガイドライン 参考 : メール送信者のガイドラインに関するよくある質問 5,000件/日以上の送信者向けのガイドライン 上記に加えて、1日に5,000件以上のメールを個人用の Gmail アカウントに対して送信する送信者に対しては、以下の要件が追加されます。 DMARC メール認証が設定されていること From: ヘッダー内のドメインが、SPF ドメインまたは DKIM ドメインと一致していること マーケティング目的のメールと配信登録されたメールは、ワンクリックでの登録解除に対応しており、メッセージ本文に登録解除のリンクをわかりやすく表示していること SPF、DKIM SPF と DKIM は、いずれも E メールの送信者を認証する仕組みです。 スパムメールや攻撃目的のメールは、送信者を偽装している場合があります。メール送信者が SPF や DKIMを正しく設定している場合、メール受信者は、受け取ったメールが本当にそのドメインの所有者から送信されたものであるかを確認できるようになり、なりすましに気がつけるようになります。 当記事で紹介する DMARC を設定するには、 SPF と DKIM がすでに設定してあることが前提 となります。SPF や DKIM については当記事では細かく説明しません。以下の Gmail 公式ドキュメントをご参照ください。 参考 : SPF を使用してなりすましと迷惑メールを防止する 参考 : DKIM を使用してなりすましと迷惑メールを防止する DMARC DMARC は、メールが SPF または DKIM による認証に合格しなかった場合に、そのメールをどのように処理するか、受信したメールサーバーに指示するための仕組みです。 DMARC は送信者側のドメインの DNS に設定します。SPF と DKIM のいずれかまたは両方のチェックに合格しなかったメールは、この DMARC 設定に従って処理されます。以下の3種類のいずれかの処理方法を指示できます。 ポリシー名 処理方法 none 通常どおり配信 quarantine 迷惑メールまたは検疫として処理 reject 拒否され、配信されない 参考 : DMARC を使用してなりすましと迷惑メールを防止する 設定の方針 これまで DMARC を設定していなかったドメインで新しく DMARC を設定すると、何らかの理由で SPF や DKIM に合格しなかったメールがこれまでと違った方法で処理されることになります。そのため、始めはゆるく設定し、 徐々にポリシーを厳しくする のがベストプラクティスとなります。 Google からは、以下の方法が紹介されています。 ポリシー none で DMARC を設定する DMARC レポートを確認する 検疫対象を徐々に増やす 最終的にすべての不合格メールを拒否する まず 1. の手順で、DMARC 設定を新規に追加します。このときポリシーを none にします。この設定では、受信側のメール処理方法はこれまでと変わりませんが、送信側は DMARC レポート を受け取れるようになります。これにより 2. の手順で、SPF や DKIM に合格しなかったメールが実際にどのくらい存在するか、ポリシーを本格的に適用する前に確かめることができます。 3. の手順では、DMARC レポートで確認した結果に応じて、ポリシーを quarantine に設定します。いきなりすべてのメールを検疫扱い（迷惑メール扱い）とするわけではなく、全メールの 5%程度 を対象とすることで、万一の悪影響を予防します。対象の割合は、DNS レコードの設定で任意の値に調整できます。DMARC レポートを引き続き注視し、徐々にパーセンテージを上げていきます。 DMARC レポートで送信したメールの大多数が SPF や DKIM にパスしていることが確認できたら、最後に 4. の手順で、ポリシーを厳格な reject に設定します。 参考 : チュートリアル: DMARC のおすすめのロールアウト方法 設定手順 ポリシー none で DMARC を設定する 前述の手順 1. で、ポリシーが none の DMARC を設定する手順です。 お使いの DNS において、自組織のドメインのゾーンに、TXT レコードを追加することで DMARC を設定します。ここではお使いのドメインが example.com であると仮定して解説します。以後、 example.com はお使いのドメインに置き換えて読んでください。 example.com のゾーンに、以下のホスト名で TXT レコードを追加します。 _dmarc.example.com TXT レコードの値は、以下のようにします。 v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com ここで dmarc-reports@example.com は、実際には DMARC レポートを受け取るメールアドレスとします。このメールアドレスでは大量の DMARC レポートを受け取る可能性があるため、個人のメールアドレスは使用せず、管理用のメールアドレスまたは DMARC レポートを受け取る専用のメールアドレスを記載してください。また、DMARC レポートを受け取る専用サービスのアドレスを利用することもできます。 なお v= は DMARC のバージョンを指定するタグであり、 p= はポリシーを設定するタグです。 DMARC レポートを確認する 設定したレポート受信用メールアドレスに届く DMARC レポートを確認します。以下のような傾向がないかを確認します。 自組織から送信した正当なメールが、受信者に届くものの、迷惑メールフォルダに振り分けられる 受信者からバウンスメールまたはエラーメッセージが返される これらの問題が起きる場合は、SPF や DKIM の設定を見直したり、以下の記事を参照してください。 参考 : DMARC に関する問題のトラブルシューティング 検疫対象を徐々に増やす DMARC レポートを1週間程度確認しても問題がなければ、TXT レコードを以下のように編集して、5%のメールを迷惑メール対象にします。 v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc-reports@example.com pct= タグにより、対象メールを5%に指定しています。自組織があまり大量メールを配信していない場合は、この割合をもっと大きなものにしても問題ありません。 DMARC レポートの確認結果に応じて、この値を徐々に大きくします。 最終的にすべての不合格メールを拒否する 最終的には、以下のポリシーを設定します。 v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com p=reject; となっており、 pct= タグが省略されているため、すべてのメールが対象となります。これが最も厳格な DMARC ポリシーです。 DMARC 適用後の確認手順 Google Admin Toolbox (Check MX) Google から提供されている Google Admin Toolbox という Web ツールで、自ドメインの SPF、DKIM、DMARC が設定されているか確認することができます。 以下のリンクからツール画面に遷移し、自社のドメイン名を入力することで、設定が適切に行われているかを確認できます。 参考 : Check MX メール受信側での確認 DMARC を設定したあと（ポリシー none の状態のときを含め）、DMARC が受信側で適切に検証できるかどうかを確認するには、DMARC を設定したドメインの Gmail から、テストメールを他のドメイン宛てに送信してください。その後、受信側でメールのヘッダを確認します。 メールのヘッダに、 ARC-Authentication-Results および Authentication-Results というセクションがあります。これらの箇所に dmarc=pass と記載されていれば、受信側で DMARC 検証が成功していることになります。 メールヘッダ もし受信側も Gmail である場合、以下のスクリーンショットのように、「メッセージのソースを表示」を選択すると、検証結果がわかりやすく表示されます。 Gmail でのメールヘッダ確認方法 (1) Gmail でのメールヘッダ確認方法 (2) 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの三木です。パブリッククラウドの普及に伴い、マルチクラウドについて相談される機会が増えたと感じています。本記事では、マルチクラウドの概要とメリットや課題、よくある構成を紹介します。 目次 目次 マルチクラウドとは マルチクラウドのメリット 柔軟性と拡張性の強化 可用性と耐障害性の強化 マルチクラウドの課題と対応策 ID 運用管理の複雑化 リソース管理の複雑化 セキュリティの一貫性 運用コストの増大 マルチクラウドの例 マルチクラウドの目的 機能拡張 グローバル最適化 リスク分散 マルチクラウド構成の一例 データ分析基盤の Google Cloud + AWS ID 管理としての Azure + Google Cloud or AWS パブリッククラウドレベルの冗長化 マルチクラウドとは マルチクラウド とは、 Google Cloud や AWS 、 Azure といった複数のパブリッククラウドを組み合わせて利用することを指します。 似た用語に、「ハイブリッドクラウド」という言葉があります。文脈によって同じ意味で使われることもありますが、 「ハイブリッドクラウド」という言葉はオンプレミスとパブリッククラウドを組み合わせていることを指す場合が多いです。 名称 組み合わせ方 マルチクラウド パブリッククラウド + パブリッククラウド ハイブリッドクラウド オンプレミスまたはプライベートクラウド + パブリッククラウド マルチクラウドのメリット 柔軟性と拡張性の強化 複数のクラウドを利用することで、 それぞれのクラウドの強みを活かして柔軟なシステム構成を実現 することができます。例えば Google Cloud は分析系のサービスが強いという特徴があります。そこで通常のワークロードは AWS で運用しつつ、データレイクを Google Cloud に置くという構成などが想定されます。なお、想定されるユースケース（組み合わせ）については、後述します。 また、ビジネスの拡大や変化によってグローバル展開することもあるでしょう。こういった場合、特定の国や地域ごとに機能提供が十分にされているパブリッククラウドを選択できる点もメリットです。 可用性と耐障害性の強化 ほとんどのメリットは上記に集約されますが、複数のパブリッククラウドを利用して冗長化することで、単一のパブリッククラウドで障害が発生した場合でも、 システムの可用性と耐障害性を高める ことが可能です。 例えばメインのワークロードを Google Cloud の Google Kubernetes Engine（GKE）上で稼働させつつ、障害に備えて AWS 上でも同様のシステムを構成しておくことなどが考えられます。 ただし、実際のところパブリッククラウドレベルの大規模障害というのは発生頻度が低い上、マルチリージョンやマルチゾーン冗長化を構成してさえいれば、復旧時間も長くはかかりません。 一方でマルチクラウドで冗長構成を取ると、運用保守のコストはかなり増大します。それぞれのクラウドで異なる運用ノウハウや手順が必要になるためです。また、データベースの同期方法やフェイルオーバーおよびフェイルバックの実装においては難しい検討が必要となります。 上記を踏まえて、コストを払っても可用性向上のメリットが上回る場合に採用する手段だと考えられます。 マルチクラウドの課題と対応策 ID 運用管理の複雑化 複数のパブリッククラウドを利用する場合、 管理の複雑化 が課題となります。 まず最初の課題がID管理です。各クラウドごとにIDを発行して管理する場合、単純に管理工数がクラウドの数だけ増えることとなります。 この対策として考えられるのは、 ID 連携機能 を利用することです。 Active Directory や Entra ID 、 Google Workspace などでアカウントを集中管理し、クラウド環境に SSO できるように設定することで工数を削減することができます。 リソース管理の複雑化 利用するパブリッククラウドが増加すると、 リソース管理 が複雑化します。 どの部署がどのクラウドで何を利用しているのかの一覧性が損なわれるほか、請求書も個別に発行されることになります。 この対策として大きく3つが考えられます。 1つ目は、クラウドリソースを専任で管理監督する組織（一般に CCoE とも呼ばれます）を構築することです。管理に集中させるだけでなく、旗振り役としての機能も期待されます。 2つ目は、パートナーの活用です。クラウドに精通したパートナーにリソース管理や調査を委譲し、最終確認を内部で行うようにします。ここでは利用するクラウドに関する高度な知見を持ち、かつエンタープライズITに慣れているベンダーを選定することが重要です。ただし正社員ではないため社内調整などにおいて運用の工夫が必要となります。 3つ目は、サードパーティ管理製品の活用です。クラウド上のリソースを横断的に可視化する製品を活用することで、一覧性を高めることが期待できます。 セキュリティの一貫性 セキュリティソリューションについても各パブリッククラウド特有のソリューションが存在します。このため、 セキュリティ対策の一貫性が損なわれる 可能性があります。 AWS は AWS Security Hub を利用し、 Google Cloud は Security Command Center を利用するという構成が考えられますが、それぞれの機能に細かく差異があるため「何を基準値としているか」の定義が難しくなります。 また、各パブリッククラウドごとにセキュリティのガードレールを定める場合も同様で、「どのクラウドで何を統制しているのか」を別で取りまとめる必要があるかもしれません。 運用コストの増大 運用担当者の学習コストが増えたり、手順が異なることから、 運用コストの増大 が懸念されます。 各パブリッククラウドで大きな概念は共通していますが、細かい部分でさまざまな差異が存在します。例えば「IAM」という言葉は AWS にも Google Cloud にも登場しますが、内部構造は大きく違います。 また「VPC」という言葉も共通ですが、ゾーンに対する考え方が異なります。リソースグループは Azure 固有の概念であり、 AWS と Google Group には類似の概念がありません。 このように、各クラウドそれぞれで異なる部分が多くありますから、担当者の学習コストが膨らみます。 これの課題に対する対策として考えられるのが、クラウドに精通した パートナーの活用 です。複数のクラウドに跨った高度な知見を持っているパートナーを選定して運用をフォローしてもらうことで、担当者の学習を効率よく進めることが可能となります。金銭的コストはかかりますが、これはとても現実的な対処法だと私は考えています。 マルチクラウドの例 マルチクラウドの目的 マルチクラウド戦略を取る目的は様々に存在しますが、大きくは以下3つに区分できます。 目的 利点・特徴 機能拡張 特定の機能やサービスを提供するパブリッククラウドを追加することで、システムの機能を拡張する グローバル最適化 地域や法規制に合わせて最適なパブリッククラウドを選択できる リスク分散 複数のパブリッククラウドを利用することでリスクを分散させる 機能拡張 主として利用するパブリッククラウドには無い機能を、アドオン的に利用したい場合に選択します。例えばサービスは AWS 上で稼働させつつ、データ分析機能は Google Cloud に持たせるパターンが考えられます。 グローバル最適化 特定の国や地域において最適なクラウドを選択するために採用します。各パブリッククラウドにおいてリージョンごとに提供されるサービスや料金が異なる場合があるため、サービス展開先の状況を踏まえて最適化したい場合に採用されます。 リスク分散 特定のパブリッククラウドで大規模障害が発生した場合でもサービス停止を避けるために用いられます。メインのワークロード実行環境とは別に、障害発生時の切り替え先としてサブのワークロード実行環境を用意しておくことが想定されます。 マルチクラウド構成の一例 データ分析基盤の Google Cloud + AWS 近年、当社顧客においても最もよく見られる構成です。 メインとなるパブリッククラウドは AWS を採用し、データ分析基盤として Google Cloud（BigQuery）を採用するパターンです。 AWS は日本でもシェアが大きいこともあり、公式ドキュメント以外にも日本語の技術ブログなど情報が豊富です。また、 AWS 向けのツールやソリューションも多数開発されています。 こうした恩恵を受けるためにメインのワークロードは AWS 上で稼働させつつ、データ分析の機能は Google Cloud を活用するのがこのパターンです。 Google Cloud は主要クラウドの中でもデータ分析基盤として優秀であり、特に処理速度の速さは群を抜いています。こうしたことから、データ分析の対象としたいデータのみをエクスポートして BigQuery に取り込む構成は比較的多く見かけます。 ID 管理としての Azure + Google Cloud or AWS Entra ID（Azure AD）を認証機能として利用しつつ、メインとして利用するパブリッククラウドが Google Cloud や AWS のパターンです。これは認証やユーザ管理の機能をAzureに移譲したパターンとなります。 Entra ID を利用している企業は非常に多いため、この構成も比較的多く見かけます。ID管理が一元化できるのが一番のメリットです。 パブリッククラウドレベルの冗長化 メインのワークロードをAWSで提供しつつ、障害発生時には Google Cloud に切り替える構成です（もちろん、この逆の構成もあります）。 パブリッククラウドレベルで冗長化されるので、クラウドで大規模障害が起きた時の復旧時間が早くなるのが最大のメリットです。 しかし、CDNやDNSなどの構成を慎重に検討する必要があり、構築難易度が高くなります。またホットスタンバイする場合はコストも問題となることが注意点です。 三木宏昭 (記事一覧) クラウドソリューション部 HROne→ServerWorks→WealthNavi→G-gen。AWS 11資格、Google Cloud認定全冠。Google Cloud Partner Top Engineer 2024。最近の悩みは中年太り。Twitter では クラウド関連のことや副業、その他雑多に呟いています。（頻度少なめ） Follow @cloudeep_miki

G-gen の杉村です。2023年12月のイチオシ Google Cloud アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに PaLM 2 の Unicorn サイズのモデルが公開（GA） Generative AI on Vertex AI でグラウンディング（Preview） Googleの新生成AIモデル・Gemini（ジェミニ）が公開 Cloud Armor の Managed Protection Plus で PayGo (Preview) Cloud Monitoring のアラートポリシーで重要度を設定できるように Vertex AI Searchで多数アップデート Duet AI for Developers が GA BigQuery Omniのマテリアライズド・ビューが利用可能に（Preview） Google Workspace ですべての管理者アカウントで2段階認証が強制に 組織のポリシー (Organization policy) でドライラン機能 はじめに 月ごとの Google Cloud アップデートのうち、特にイチオシなものをまとめています。 ある程度の事前知識が必要な記載となっています。サービスごとの前提知識は、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp またリンク先の公式ガイドは英語版にしないと最新情報が反映されていない場合がありますためご注意ください。 PaLM 2 の Unicorn サイズのモデルが公開（GA） Model information (2023/11/30) PaLM 2 の Unicorn サイズのモデルが公開（GA）。 text-unicorn が Vertex AI で使用可能になった。 text-bison と比較して生成品質が向上する代わりに、料金が高価（ 料金表リンク ）。以下は2023年12月時点の単価。 text-bison : Online requests (Input) : $0.0005/1,000 characters text-unicorn : Online requests (Input) : $0.0025/1,000 characters Generative AI on Vertex AI でグラウンディング（Preview） Grounding overview (2023/12/05) Generative AI on Vertex AI でグラウンディング機能が Preview 公開。Google Cloud Next Tokyo '23 でデモされた機能。 text-bison と chat-bison でグラウンディングが可能になった。Vertex AI Search の非構造化データストアをグラウンディング先にできる。 Googleの新生成AIモデル・Gemini（ジェミニ）が公開 Introducing Gemini: our largest and most capable AI model (2023/12/06) Googleの新生成AIモデル・Gemini（ジェミニ）が公開。Vertex AI の Generative AI Studio からマルチモーダル（テキスト、画像、動画をインプットにしてテキスト生成可能）の Gemini Pro モデルが利用可能になった（Preview）。 現在 Vertex AI 経由で利用可能な Gemini Pro のマルチモーダルモデルでは、テキストのほか以下をインプットにできる。 画像 : PNG、JPEG 動画 : MKV, MOV, MP4, WEBM まだ利用可能になってはいないが、最大サイズ「Ultra」では GPT-4 を上回る性能を持つとされる。英語版 Bard では2023/12/06からすでに Gemini を使用開始。今後、Pixel などへ Google 製品にも導入予定。 Gemini で使えるようになった Functions Calling 機能は以下の記事で検証されている。 blog.g-gen.co.jp Cloud Armor の Managed Protection Plus で PayGo (Preview) Google Cloud Armor Standard versus Managed Protection Plus (2023/12/11) これまで年間契約のみだった Cloud Armor の Managed Protection Plus ティアに、月額課金のプランが登場（Preview）。 プロジェクトあたり$200/月で最大2リソースを保護、それ以上は追加課金。日割りなので試用にも使える。 Cloud Monitoring のアラートポリシーで重要度を設定できるように Structure of an alerting policy (2023/12/12) Cloud Monitoring のアラートポリシーで重要度 (Severirty) を設定できるようになった。コンソールからの設定では Critiacal, Error, Warning が設定できる。 アラートポリシーの基本的な使い方は、以下の記事も参照。 blog.g-gen.co.jp Vertex AI Searchで多数アップデート Release notes - December 13, 2023 (2023/12/13) Vertex AI Searchで多数アップデート。 メディアサーチ(Private Preview) 日本語での要約に正式対応 要約に対するプロンプト挿入 要約への脚注追加 検索結果のチューニング PDFに対するOCR (Public Preview) マルチデータソース ...など。生成AIを使った高度な検索がより容易に実現できる。Vertex AI Search の詳細は、以下の記事を参照。 blog.g-gen.co.jp Duet AI for Developers が GA Duet AI for Developers および Duet AI in Security Operations の一般提供を開始 (2023/12/14) Duet AI for Developers が GA。AI によるコード生成、コード補完、チャットによる開発支援などを実現。対応 IDEは、Cloud Shell Editor、Cloud Workstations、IntelliJ、PyCharm Visual Studio Code など。 また、2024年第2四半期にはカスタマイズ可能に（自社コードを学習させる）。 当初は無料利用可能で、2024/02/01 から課金開始。2023年12月現在では、料金は $19/user/month とされている。 BigQuery Omniのマテリアライズド・ビューが利用可能に（Preview） Materialized view replicas (2023/12/12) BigQuery Omni のマテリアライズド・ビューが Preview 公開。Amazon S3 のデータを参照するマテリアライズド・ビューが作成可能に。 Zero-ETL で S3 から BigQuery にデータを転送できるようになった。ただし、東京リージョンの Amazon S3 バケットには未対応なため注意が必要。 BigQuery Omniのマテリアライズド・ビューが利用可能に（Preview） Google Workspace ですべての管理者アカウントで2段階認証が強制に Google Workspace Updates Weekly Recap - December 15, 2023 (2023/12/15) Google Workspace のすべての管理者アカウントで2段階認証が強制になる。ドメインごとに、いつ強制が開始されるかは異なるため、Google からの通知に注意。適用の30日間前にメールで通知される。 組織のポリシー (Organization policy) でドライラン機能 Create a dry-run organization policy (2023/12/20) Google Cloud の組織のポリシー (Organization policy) にドライラン機能が追加。ドライラン中のポリシーはログに記録されるが実際には Deny されない。 ただしまだ一部のポリシーにしか対応していない点に注意。現在は Restrict Resource Service Usage (constraints/gcp.restrictServiceUsage) でのみ使用可能。これは、使用可能な Google Cloud サービスを制限する制約。 組織のポリシーについては以下の記事を参照。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では Cloud Run 利用時のよくあるトラブルとして、「認証が必要」の設定を行ったサービスにブラウザからアクセスできない事象とその原因、対処法について解説します。 事象 原因 解決策 Identity-Aware Proxy（IAP）を使用する Identity Platform を使用する Cloud Run プロキシを使用する 事象 Cloud Run にデプロイしたサービスの URL（*.a.run.app の URL）にブラウザからアクセスすると、ブラウザに以下のエラーメッセージが表示されました。 Your client does not have permission to get URL / from this server. ブラウザに表示されるエラーメッセージ 原因 Cloud Run の設定画面では、すべてのユーザーがサービスにアクセスできるようにしたい場合は「未認証を許可」、IAM でサービスに対するアクセス権限を持っているユーザーのみアクセスさせたい場合は「認証が必要」に設定する必要があるように見えます。 認証の設定画面 しかし、「認証が必要」に設定されているサービス（以下、 非公開のサービス と呼びます）は、基本的にはブラウザからサービスの URL（ *.a.run.app ）への直接アクセスができなくなります。非公開のサービスにアクセスするためには、リクエストに認証情報（ID トークン）を含める必要があるためです。 たとえば curl コマンドを使用してサービスにアクセスする場合、以下のように gcloud auth コマンドで取得した ID トークンをリクエストのヘッダーに設定します。Cloud Run 起動元（ roles/run.invoker ）ロール等を付与されたユーザーがこのコマンドを実行すれば、適切な ID トークンを取得できます。適切な ID トークンを Authorization ヘッダーに設定してリクエストすることで、非公開のサービスを起動できます。 # 非公開の Cloud Run サービスにアクセスする $ curl -H " Authorization: Bearer $( gcloud auth print-identity-token ) " { サービスのURL } また、アプリケーションから Cloud Run にアクセスする場合は、Google Cloud SDK などで API を利用して認証を行い、取得したトークンを Cloud Run へのリクエストに含めることができます。 参考 : サービス間認証 - 認証ライブラリを使用する しかし、一般的な Web ブラウザからサービスの URL に直接アクセスする場合は、上記のようなトークン取得と、ヘッダへの付与ができません。 解決策 Identity-Aware Proxy（IAP）を使用する Identity-Aware Proxy（IAP）を Cloud Run の前段に配置することで、IAP において、Google アカウントによるユーザー認証が行われます。 サービスにアクセスできるユーザーは、IAP で保護されたウェブアプリ ユーザー（ roles/iap.httpsResourceAccessor ）ロールが付与されている Google Cloud 組織内のユーザー のみに制限されます。こちらの方法は、社内向けのサービスを Cloud Run にホストする場合などで使用します。 Cloud Run に IAP を設定するには、ロードバランサーを使った方法と、Cloud Run サービスに直接 IAP を設定する方法の2通りがあります。以下の記事で設定手順などを解説しています。 blog.g-gen.co.jp blog.g-gen.co.jp Identity Platform を使用する Identiry Platform を使用する方法では、ユーザーは Identity Platform で認証を行い、取得した ID トークンを Cloud Run に送信します。 メールアドレスとパスワード、電話番号、または Google や Facebook などのソーシャルプロバイダを使用して認証を行うことができるため、エンドユーザーの認証を独自に実装したい場合は、この方法を使用します。 参考： Cloud Run でのエンドユーザー認証のチュートリアル Cloud Run プロキシを使用する テスト時など、非公開サービスに対して一時的にアクセスするだけであれば、Google Cloud CLI に含まれる Cloud Run プロキシを使用する方法があります。 Cloud Run 起動元（ roles/run.invoker ）ロール等が付与されたユーザーで以下のコマンドを実行することで、ローカルで実行されるプロキシを経由して非公開サービスにアクセスできます。 # Cloud Run プロキシの実行 $ gcloud run services proxy { サービス名 } --project { プロジェクトID } ----- 出力例 ----- Proxying to Cloud Run service [ myservice ] in project [ myproject ] region [ asia-northeast1 ] http:// 127 . 0 . 0 .1:8080 proxies to https://myservice-xxxxxxxxxx-an.a.run.app プロキシが実行されている状態でブラウザから http://127.0.0.1:8080 にアクセスすると、Cloud Run サービスが実行されます。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。この記事にたどり着いた方は、もしかしたら自社の Google Cloud（旧称 GCP）の組織に My First Project という名前のプロジェクトが大量発生していることに気がついた方かもしれません。当記事ではその原因と、対処法をご紹介します。 事象 原因 My First Project とは 原因となる IAM 権限 対処の方針 対処の手順 1. IAM ロールの削除 2. 不要プロジェクトの利用有無確認 3. 不要プロジェクトの削除 組織の運用 事象 自社の Google Cloud（旧称 GCP）の組織ツリーは、Google Cloud の Web コンソールを開いて、検索ボックスに「Manage Resources」と入力し、 リソースの管理 画面へ遷移することで確認することができます。 するとツリーの中に My First Project という名称のプロジェクトが大量に存在している場合があります。クラウド管理者からすると作成した覚えがなく、何らかの対処をすべきなのか、またどう対処するべきかがわからないケースもあります。 数十個の My First Project が乱立 原因 My First Project とは My First Project とは、Google アカウントがはじめて Google Cloud の Web コンソール画面にアクセスしたときや、何らかのチュートリアルドキュメントから Web コンソールに遷移したときなどに、自動的に生成されてしまう Google Cloud プロジェクトです。 原因となる IAM 権限 Google Cloud ではデフォルトで「組織ドメインのメールアドレスを持っているアカウントであれば誰でもプロジェクト作成できる」権限設定になっています。そのため過去に明示的にその権限を削除したことがなければ、 誰でもプロジェクトを作成できる状態 になっています。 これが原因で、組織の Google アカウントを持つ人が初めて Google Cloud コンソールにアクセスしたときなどに、 My First Project が乱立してしまうことになります。 以下のスクリーンショットでは、組織ルートレベルで プロジェクト作成者 (roles/resourcemanager.projectCreator) 請求先アカウント作成者 (roles/billing.creator) の IAM ロールが xxx.com （ドメイン全体を意味する。実際には自社のドメイン）に付与されています。これにより、 xxx.com ドメインに所属するすべての Google アカウントがプロジェクトと請求先アカウントを作成できるようになっているのです。 組織のルートレベルにプロジェクト作成者ロールが付与 対処の方針 前述の「誰でもプロジェクトを作成できる」権限を削除することで、今後は My First Project が作成されることがなくなります。 多くの場合で、会社や官公庁などの Google Cloud 組織では、プロジェクト作成権限を情報システム部門、あるいはそれ相当の部門のメンバーに限定することが望ましいといえます。乱立し放置された Google Cloud プロジェクトはセキュリティホールとなり得るためです。 そのためまず、新規プロジェクト払い出しの申請フローを整備したうえで、全員から権限を剥奪して My First Project が新規に作成されなくなる状況を作ることが望ましいです。 その後、乱立してしまった My First Project を、作成したユーザーに確認しつつ、削除していくことになります。 対処の手順 1. IAM ロールの削除 組織ルートレベルで xxx.com から、 プロジェクト作成者 (roles/resourcemanager.projectCreator) 請求先アカウント作成者 (roles/billing.creator) の IAM ロールを削除します。 この手順を実施すると、 以後は誰でもプロジェクト作成ができる状態ではなくなります 。プロジェクトの払い出し業務を情報システム相当部門に集約できている前提だとお考えください。 まず Google Cloud の Web コンソールで、上部検索ボックスに「IAM」と入力し、「IAM と管理」の画面へ遷移します。 その後、プロジェクトセレクタで組織ルートを選択します。コンソール上部のプロジェクトセレクタをクリックし、組織ルートを選択します。 組織ルートの IAM 設定を編集する プロジェクト作成者 請求先アカウント作成者 と表示されている行の右端の鉛筆マークをクリックするとロール編集画面がポップアップされるので、両方のロールをゴミ箱アイコンを押下して削除し、保存します。 これで IAM ロールは削除できたので、誰でもプロジェクトを作成できる状態は解消しました。 2. 不要プロジェクトの利用有無確認 使われていない My First Project が乱立したまま残っている状態は、セキュリティの観点から望ましくありません。 以下のいずれかの方法で、プロジェクトの作成者を確認し、削除が可能かどうかを確認します。 Cloud Logging で CreateProject メソッドの実行履歴を確認する プロジェクトレベルで オーナー (roles/owner) の IAM ロールを持っている人を確認する 上記のうち1.が最も正確な方法です。Cloud Logging のログエクスプローラーにおいて以下のクエリを実行することで、プロジェクト作成時のログを確認します。これにより、誰がいつ、プロジェクトを作成したかを確認することができます。 protoPayload.methodName="CreateProject" ログエクスプローラーの期間設定を変更することを忘れないでください。デフォルト設定では、監査ログ（Cloud Audit Logs）は過去400日まで保存されています。 ログエクスプローラーの使い方 プロジェクトが作成されたのが400日以上前である場合、誰がいつプロジェクトを作成したのか、監査ログから知ることはできません。その際は2.の IAM ロールを確認します。プロジェクトレベルで オーナー (roles/owner) のロールを持っている人は、そのプロジェクトを作成した人である可能性が高いです。なぜなら、プロジェクトを作成したアカウントには自動的に オーナー (roles/owner) ロールが付与されるからです。 あとからオーナーを追加することもできるので確実にプロジェクト作成者を突き止められるわけではありませんが、いずれにせよオーナー権限を持っているアカウントは、そのプロジェクトの実態を知っている可能性が高いと言えます。 3. 不要プロジェクトの削除 プロジェクトが不要であることを確かめられたら、そのプロジェクトを削除します。 IAM と管理の画面の左ペインに「設定」メニューがあります。 IAM と管理 > 設定 ここに遷移すると、 シャットダウン のボタンがあります。これがプロジェクトを削除するボタンです。 目的のプロジェクトが選択されていることを注意して確認してください。 プロジェクトのシャットダウン（削除） なおシャットダウン（削除）したプロジェクトは、30日以内であれば復元できる可能性があります。復元については以下のドキュメントをご参照ください。 参考 : プロジェクトの作成と管理 - プロジェクトの復元 組織の運用 適切な組織運用を行うには、Google Cloud の組織（Organization）の機能を正確に理解することが重要です。 ぜひ以下の記事をお読みいただき、組織の機能を活用してセキュアに Google Cloud 環境をご利用ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen セールスチームの溝口です。Google Cloud（旧称 GCP）の認定資格である Cloud Digital Leader 試験を受験し、合格した際に利用したサイトや勉強方法、難易度などをまとめました。 はじめに 試験について Cloud Digital Leader とは 試験概要と出題範囲 難易度 受験した感想 受験方法 テストセンター 遠隔監視オンライン試験 学習方法 STEP 1 : ITの基礎知識と頻出単語の理解 公式の試験ガイドで試験内容を把握 参考書で基礎知識を取得する STEP 2 : 試験対策と反復学習 公式の試験ガイドで試験範囲を把握 外部学習サイト（Udemy）の利用 STEP 3 : 正答の傾向を掴む 模擬試験から正解の傾向を掴む G-gen Tech Blog の利用 学習時間 まとめ はじめに 当記事では Cloud Digital Leader 試験を受験し、合格した際に利用したサイトや勉強方法、難易度などをまとめました。 IT資格を今まで取得したことがなかったり、今から手探りで勉強を始める方など、初学習者向けの記事ですので、是非参考にしてください。 Cloud Digital Leader の学習では、途中で挫折してしまわない為にも、以下の3つのステップが重要です。 STEP 1 : ITの基礎知識と頻出単語の理解 STEP 2 : 試験対策と反復学習 STEP 3 : 正答の傾向を掴む 当記事ではまず Cloud Digital Leader の試験の基本的な情報についてご紹介したあと、3つのステップに沿って学習方法をお伝えします。 試験について Cloud Digital Leader とは Cloud Digital Leader は IT 分野の基礎知識 と Google Cloud の基礎知識 が問われる資格試験です。Google Cloud に携わるために、最初に取得を目指す資格です。 合格率60%前後と言われており、初心者向けの資格試験として難易度は比較的低いと言われています。しかし「IT分野の基礎知識」が無い受験者にとっては、ハードルの高い試験に感じてしまうかもしれません。 Google の試験概要によると以下のように記載されています。 Cloud Digital Leader は、Google Cloud の中核的なプロダクトやサービスの機能と、それらが組織にもたらすメリットを明確にできます。また、Cloud Digital Leader は、一般的なビジネス ユースケースや、クラウド ソリューションが企業をどのように支えているかを説明することができます。 当試験は Google Cloud の利用経験が前提条件とされていない という点が重要です。クラウドやGoogleプロダクト利用のための知識を広く得るための第一歩になる資格といえます。 参考 : Cloud Digital Leader 試験概要と出題範囲 試験概要は以下のとおりです。 試験時間 : 90分 登録料 : $99 言語 : 英語、日本語 試験の形式 : 50 ～ 60 問の多肢選択（複数選択）式 試験範囲は公式サイトにて細かく記載されていますが、大きく分けて4つのセクションに分かれています。 Google Cloud によるデジタル トランスフォーメーション（試験内容の約 10%） データと Google Cloud によるイノベーション（試験内容の約 30%） インフラストラクチャとアプリケーションのモダナイゼーション（試験の約 30%） Google Cloud のセキュリティとオペレーションの理解（試験内容の 30%） 学習の初期段階からセクションを意識した勉強はハードルが高いので、目を通す程度で問題無いです。 合格点は開示されていないため不明ですが、約7割程度の正答率で合格する方が多い傾向にあります。 難易度 前述の通り、 一般的な IT 知識 をすでに理解されている前提で問題は構成されています。 IPA の IT パスポート や 基本情報技術者試験 を学習したことがない人にとっては、IT 基礎知識の学習から始めることになりますので、当試験の難易度は相対的に高くなります。 しかし認定ガイドに「Cloud Digital Leader の認定試験は特定の職に就いていることを条件とせず、Google Cloud の実務経験も必要ありません。」とある通り、基礎学習から進めても十分合格を目指せる資格とも言えます。 受験した感想 試験時間は、カツカツということはなく落ち着いて回答・見直しができる程度の余裕がありました。 試験終了後に仮の試験結果（合格・不合格）が表示され、後日正式に認定されるとデジタル認定証が登録メールアドレスに送付される流れです。 試験を終えてみて、無事に合格できて良かったものの、提供されている試験情報は多くありません。学習を始める取っ掛かりが乏しいことも「Cloud Digital Leader」の難しさと感じています。 受験方法 テストセンター テストセンターでの受験が、最も基本的な受験方法です。オンサイト監視試験とも呼ばれます。 後述する遠隔監視オンライン受験は部屋全体を片付けて試験官に見せなければいけない、といった準備が大変そうでしたので、私はテストセンター受験を選択しました。 遠隔監視オンライン試験 遠隔監視オンライン試験は、自宅で受験できる受験方式です。 当社の社員が実際に受験した際の体験記もご参照ください。 blog.g-gen.co.jp 学習方法 当記事に記載するのは、実際に私が合格までに勉強した方法であり、一例です。 今後の学習の一助としてください。 STEP 1 : ITの基礎知識と頻出単語の理解 公式の試験ガイドで試験内容を把握 本試験の出題内容と出題範囲を 認定試験ガイド で確認します。 学習初期ではこれらの文言のすべてを理解することは難しいかもしれません。最初のうちは試験の前提条件として目を通しておくレベルで問題ないです。 しかし、本試験がこの認定試験ガイドを元に作成されている以上、試験を受ける直前には一言一句、文章の意味を理解できるようになっておくと良いでしょう。 参考書で基礎知識を取得する 最初に手にしたのがこちらの書籍です。 図解即戦力　Google Cloudのしくみと技術がこれ1冊でしっかりわかる教科書 作者: 株式会社grasys , Google Cloud 西岡典生 , Google Cloud 田丸司 技術評論社 Amazon 書籍自体は全10章ありますので、1日に1章を読み進めることを目標に進めていきました。 読み進めるにあたってわからない単語やつまずいた文章などは必ずメモを取るようにしました。 実際のメモ（字が汚くてスミマセン） 私のようにアナログな方法でも、また Google Keep のようなデジタルで自分独自の単語帳を作ってもいいかもしれません。この際に重要なのは、 単語の意味を理解せずに読み進めないこと です。 各機能の役割や連携を完全に理解しないまま学習を進めることは、自ら知識の穴を作ることになってしまいます。 理解が難しいものや学習の手が止まった場合には、参考書を振り返る癖を付けておくと良いでしょう。 また、受験時には未発行だったものの、現在では以下の書籍「合格対策 Google Cloud認定資格Cloud Digital Leader テキスト＆演習問題」が発行されています。Cloud Digital Leader 試験の参考書であり、基礎知識をカバーできます。 合格対策 Google Cloud認定資格Cloud Digital Leader テキスト＆演習問題 作者: 杉村 勇馬 , 又吉 佑樹 リックテレコム Amazon STEP 2 : 試験対策と反復学習 公式の試験ガイドで試験範囲を把握 書籍を一通り理解できたら、公式問題にトライしましょう。Google Cloud の公式ページから 模擬試験 を受けることが可能です。 模擬試験は20問で、本番と同じく4つの選択肢から正解を選ぶ選択式になっています。 試験の最後には問題の正誤確認と共にフィードバックを確認できます。間違った問題だけでなく正解した問題もきちんと解説を読むことで、理解が進みぐっと合格へ近づくことが出来ます。 また、この模擬試験から本番試験に出題されるケースも少なくなく、選択肢に挙げられたサービスについては、最低限その概要や特徴は理解しておくと良いでしょう。 外部学習サイト（Udemy）の利用 書籍での知識学習と公式試験での出題傾向がわかった後に、外部サイト（Udemy）にて模擬試験問題集を購入し試験対策を行いました。 参考 : Google Cloud Digital Leader模擬試験問題集（6回分320問） この模擬試験は本番試験と同じく50問以上の試験が6セットあり、本試験よりも難易度が高めに設定されています。 本番試験に慣れておくことと、学習の穴を無くす為に何度も受講しました。 STEP 3 : 正答の傾向を掴む 模擬試験から正解の傾向を掴む 模擬試験の解説で、理解が足りない部分があれば書籍に戻り再学習します。 この辺りまで学習を進めていくと、 サービスに適したユースケース（使われる場面）をイメージ して学習が進められるようになっていると望ましいです。サービスや機能を利用することで「誰が」「なぜ」「どういうメリットがあるのか？」などを深く理解することが重要です。 試験での選択肢してとしても「A というサービスでも出題文の課題は解決できるが、Bというサービスを利用することが最も好ましい選択（ ベストプラクティス ）である」という場面が出てきます。 各機能の役割やメリットをしっかり学習することは本試験に役立てることができますし、のちに Google Cloud を実務で利用する場面でも、その知識が重要になります。 G-gen Tech Blog の利用 筆者の所属する G-gen 社は、 G-gen Tech Blog ですべての Google Cloud 認定資格の試験対策記事を公開しています。 ややエンジニアに向けた内容となっていますが、STEP 3 まで学習を進めた方であれば、非エンジニアの方でも以下の記事の内容を理解できるようになっているはずです。 blog.g-gen.co.jp また、Google Cloud プロダクト名を覚えるために、以下のような記事も役に立ちます。 blog.g-gen.co.jp 学習時間 個人によって学習ペースはそれぞれではありますが、一例として私の学習時間を掲載します。 私の場合、以下の表のように、合格までに費やした合計学習時間は 約60時間 でした。 実際には公式の模擬試験や Udemy などの外部模擬試験で7割程度の正答率になれば、本試験に通用する程度に理解が進んでいます。 学習項目 所要時間 内容 参考書での学習 10時間 ・各章1時間で読み進める ・わからない単語があればその都度メモを取る ・機能のイメージができない場合、前の章に戻り再度学習 メモへの転記と反復学習 10時間 ・忘れてしまう単語はスマホの待ち受けにするなど日常的に意識 ・本試験までに1日1回はメモを見返すクセを付ける 公式の模擬試験 2時間 ・1回30分程度の模擬試験を、本試験までに4回以上実施 外部学習サイトの模擬試験 30時間 ・模擬試験を20回以上実施 ・1回30分程度の模擬試験+振り返り学習30分程度 ・80％以上の正答が取れるように学習 ・フィードバック内容を正確に理解できるまで学習 試験ガイドの再確認 2時間 ・公式の試験ガイド、試験対策を再度読み込む まとめ Cloud Digital Leader は非エンジニアにとっては難易度が高く、学習量も多い試験です。しかし、Google Cloud の利用経験を前提としていないことから、しっかりと理解することで合格できる試験といえます。 学習の途中で挫折してしまわない為にも、以下の3つのステップが重要だと考えます。 STEP 1 : ITの基礎知識と頻出単語の理解 STEP 2 : 試験対策と反復学習 STEP 3 : 正答の傾向を掴む 本記事で紹介した内容が学習の手助けになれば幸いです。 溝口 直 (記事一覧) ビジネス推進部 営業2課 2023年10月よりG-gen にジョイン。 HRサービスを展開するベンチャー企業から、Google専業の営業へ。関西在住でGoogle Cloudをメインに活動中。育児と仕事のバランスを常に模索中・・

G-gen の杉村です。BigQuery では、Cloud KMS で管理する暗号鍵を使って、列レベルの暗号化を行うことができます。その仕組みと方法を解説します。 BigQuery における暗号化 ストレージ暗号化とは 列レベル暗号化とは 権限と読取可能性 暗号化方式 AEAD 暗号化とキーセット エンベロープ暗号化 BigQuery 以外でのエンベロープ暗号化 2つの暗号化関数 検証 作業の流れ 1. Cloud KMS 鍵を作成 2. 鍵セット (DEK) 格納用のテーブルを作成 3. 鍵セット (DEK) を作成 4. データ格納用テーブルを作成 5. データを暗号化してテーブルに格納 5. データを読み取る（復号なし） 6. データを読み取って復号 トラブルシューティング Incompatible CryptoKey location Query error: Permission 'cloudkms.cryptoKeyVersions.useToDecryptViaDelegation' denied Query error: deterministic_encrypt requires the keyset chain and its arguments to be constant Query error: AEAD.DECRYPT_STRING failed Query error: DETERMINISTIC_DECRYPT_STRING failed 深掘り情報 鍵セットのローテーション ローテーションの概念 影響 メモリ上の DEK BigQuery における暗号化 ストレージ暗号化とは まず BigQuery に保存されるデータは、デフォルトで透過的に暗号化されています。Google Cloud によって管理されている鍵を使い、 ストレージのレベルで暗号化 されています。そのためもし、Google のデータセンターからストレージ機器が盗まれてしまったり、悪意を持った内部犯が物理的なアクセスを試みても、データが閲覧されることはありません。これを デフォルトの暗号化 といいます。 デフォルトの暗号化では暗号鍵が Google によって管理されているため、より強固なセキュリティを要する場合はユーザー管理の鍵によってストレージを暗号化することも可能です。これは CMEK 暗号化 と呼ばれます。CMEK は Customer-managed encryption keys の略です。 しかしながらこれらはいずれも ストレージレベルの暗号化 です。対応できる脅威は、前述のようにストレージ機器の物理的な盗難や、物理的なアクセス、脆弱性を突いた非正規アクセスなどです。BigQuery テーブルへのアクセス権限を持った人が、正面玄関（通常の Web UI や API など）からアクセスすれば、データは見えてしまいます。 参考 : 保存時の暗号化 列レベル暗号化とは ここで当記事で扱う 列レベル暗号化 が登場します。列レベル暗号化では、データそのものを 暗号鍵 を使って暗号化してからテーブルに格納します。 そのため、たとえテーブル自体へのアクセス権限を持っている人でも、通常通り SELECT して取得できるのは暗号化されたバイト列だけです。データを復号するには鍵へのアクセス権限が必要です。 特に機密性が求められる情報を BigQuery テーブルに保存する際は、この列レベル暗号化を使うことで機密性を高めることができます。 参考 : Cloud KMS を使用した列レベルの暗号化 権限と読取可能性 列レベルの暗号化を使った場合、権限の考え方は「テーブル自体へのアクセス権限」と「暗号鍵へのアクセス権限」の2軸になります。以下のマトリクス表のような考え方になります。 権限マトリクス 列レベル暗号化された列であっても、テーブルへの権限さえあれば通常どおり SELECT できます。ただし、読み取られたデータは暗号化されたままです。テーブルへの権限に加えて鍵への権限を持っていれば、データを復号することができます。復号は、SQL 上の関数を使って明示的に行う必要があります。具体的な方法は後述します。 参考 : Cloud KMS を使用した列レベルの暗号化 - ユースケース 暗号化方式 AEAD 暗号化とキーセット BigQuery の SQL を使って列レベルの暗号化をする際は AEAD 暗号化 と呼ばれる方式が用いられます。Authenticated Encryption with Associated Data の略で、認証付き暗号と呼ばれます。HTTPS プロトコルでおなじみの TLS でも使われている方式です。 また、BigQuery における列レベルの暗号化に使う暗号鍵は「 鍵セット (キーセット)」と呼ばれます。鍵セットはプライマリ暗号鍵とセカンダリ暗号鍵からなる鍵の集合体であり、BigQuery の BYTES 型 のデータです。 参考 : AEAD 暗号化のコンセプト エンベロープ暗号化 列レベルの暗号化では エンベロープ暗号化 という方式を使うことができます。 この方法では「 データ暗号鍵 (Data Encryption Keys、以下 DEK)」と「 鍵暗号鍵 (Key encryption keys、以下 KEK)」の二種類の鍵を使います。前者はデータそのものを暗号化するための鍵で、後者は "DEK を暗号化するための鍵" です。 データを暗号化する鍵自体が暗号化されているので、例え DEK が漏洩しても、KEK が強固に守られていればデータ自体は安全です。 KEK と DEK BigQuery の列レベル暗号化では、先述の鍵セットが DEK にあたります。DEK は KEK によって暗号化されたあと、BigQuery のテーブル等に保存しておきます。 では KEK はどこに置いておくかというと、 Cloud KMS (フルマネージドの鍵管理サービス) の鍵がそれに当たります。Cloud KMS について詳細が知りたい方は、以下の記事もご参照ください。 blog.g-gen.co.jp たとえ BigQuery への閲覧権限を持った人によって鍵セットを保存したテーブルが読み取られてしまったとしても、鍵セット自体が暗号化されているため、そのままでは鍵としては使えません。鍵セットを復号して使えるようにするには、Cloud KMS 鍵である KEK への権限が必要です。このように二重の暗号化・二重の権限によって保護されていると言えます。 なお、Cloud KMS 鍵 (KEK) によって暗号化された鍵セット (DEK) のことを ラップされた鍵セット (Wrapped keysets) と呼びます。 よって、列レベル暗号化されたデータを読み取って復号する際は「データを読み取る」「DEK を KEK で復号」「復号された DEK を使ってデータを復号」という作業になります。大変そうですが、BigQuery にはこれを簡単に実現する SQL 関数が用意されています。書き込むときも同様です。 BigQuery 以外でのエンベロープ暗号化 エンベロープ暗号化という暗号化戦略は、BigQuery に固有のものではありません。 Cloud KMS のドキュメントにも一般的な手法としてエンベロープ暗号化に関する記載があるほか、Amazon Web Services (AWS) の類似サービスである AWS KMS でも同様の戦略が利用されており、Amazon S3 におけるサーバーサイド暗号化 (SSE-KMS) などで透過的にエンベロープ暗号化が行われています。 参考 : Cloud KMS - エンベロープ暗号化 参考 : AWS KMS の概念 - エンベロープ暗号化 参考 : AWS KMS キーによるサーバー側の暗号化 (SSE-KMS) の使用 2つの暗号化関数 列レベル暗号化に用いる関数には二種類あります。 確定的暗号化関数 (Deterministic encryption functions) と 非確定的暗号化関数 (Non-deterministic encryption functions) です。"Deterministic" は "決定論的" と訳される場合もあります。 前者は、インプットとなる平文が同じであれば、アウトプットも必ず同じになります。 後者は、インプットが同じでも、暗号化するたびに異なるアウトプットとなります。アウトプットは非確定的 (非決定論的) ではありますが、復号は問題なく可能です。 確定論と非確定論 前者の確定的暗号化であれば、データを暗号化した状態のまま、集計や結合などの分析に利用できます。例えば「顧客の氏名」という情報は暗号化すると意味を失いますが、暗号化された状態の氏名をキーにして、集計したりテーブルの結合に利用できます。 後者の非確定的暗号化は、データを暗号化すると毎回結果が異なるので、分析に利用することはできません。個人情報保護の観点等から、集計や結合に暗号化後のデータを使わせたくない場合にこちらを選択します。 検証 作業の流れ ここから、実際の SQL を交えて、列レベルの暗号化を行う方法を検証します。以下のような流れで検証します。 Cloud KMS 鍵を作成 鍵セット (DEK) 格納用のテーブルを作成 鍵セット (DEK) を作成 データ格納用テーブルを作成 データを暗号化してテーブルに格納 データを読み取って復号 当検証は、以下のドキュメントを参考にしています。 参考 : Cloud KMS を使用した列レベルの暗号化 - 鍵管理 参考 : Cloud KMS を使用した列レベルの暗号化 - 暗号化および復号 1. Cloud KMS 鍵を作成 Cloud KMS で KEK としての鍵を作成します。 Cloud KMS の鍵 ( キー ) は キーリング というまとまりで管理されます。まずキーリングを、暗号化対象のデータセットと 同じロケーション (リージョン) で作成します。鍵とデータセットのリージョンが異なると、暗号化関数から利用できませんのでご注意ください。 当検証では以下のようなキーリングを作成しました。 パラメータ名 値 説明 キーリング名 my-test-keyring ロケーションタイプ リージョン : asia-northeast1 (東京) 暗号化対象のデータセットと合わせる なお Cloud KMS ではグローバル (global) ロケーションにキーリングを作成できますが、BigQuery の列レベル暗号化ではグローバルのキーは利用できません。 そしてそのキーリングの中に、キーを作成します。一般的には以下のようなパラメータになります。 パラメータ名 値 説明 キー名 my-test-key 保護レベル ソフトウェア マネージドのハードウェアセキュリティモジュール (HSM) を選択することもできる 鍵のマテリアル 生成した鍵 自前の HSM で作成した鍵など、外部からインポートすることもできる 目的とアルゴリズム 対称暗号化 / 復号化 対称鍵 (共通鍵) を選択します 鍵のローテーション 90 日 (開始日は任意) セキュリティ要件に合わせてください 2. 鍵セット (DEK) 格納用のテーブルを作成 鍵セット (DEK) 格納用のテーブルを作成します。ここでは以下のような、シンプルなテーブルとします。 CREATE TABLE `my-project.my_dataset.my_keysets` ( id STRING, keyset BYTES ) 鍵セットを格納する列は BYTES 型 である点に注意してください。 また鍵セットには ID を持たせるようにしました。列レベル暗号化では「行ごとや特定キーごとに異なる鍵を使って暗号化する」こともできますし、「テーブルごとに1個の鍵を利用」したり「複数のテーブルで1個の鍵を利用する」こともできます。共有範囲が狭いほどセキュアです。 特定キー、例えば顧客ごとに鍵セットを分けていれば、鍵を無効化して復号不可にすることでデータを実質的に消去する「 暗号消去 (暗号シュレッディング)」が可能になります。顧客が退会したときに、顧客データが複数テーブルに分散していても、暗号鍵を無効化するだけで一度に実質的な消去ができます。 今回の検証では、ある1個のテーブルのデータを1個の鍵セットで暗号化します。 3. 鍵セット (DEK) を作成 INSERT `my-project.my_dataset.my_keysets` (id, keyset) SELECT " my_table " , KEYS.NEW_WRAPPED_KEYSET( ' gcp-kms://projects/my-project/locations/asia-northeast1/keyRings/my-test-keyring/cryptoKeys/my-test-key ' , ' DETERMINISTIC_AEAD_AES_SIV_CMAC_256 ' ) KEYS.NEW_WRAPPED_KEYSET() が新規の鍵セット (ラップされた鍵セット) を生成する関数です。第一引数に、先ほど作成した KEK として使う KMS キーの ID を指定します。ID のフォーマットは以下のとおりです。 gcp-kms://projects/ ${ プロジェクト ID } /locations/ ${ キーリングのロケーション } /keyRings/ ${ キーリング名 } /cryptoKeys/ ${ キー名 } 第二引数には、鍵の種類を記載します。確定的な関数では DETERMINISTIC_AEAD_AES_SIV_CMAC_256 を、非確定的関数で使うには AEAD_AES_GCM_256 を指定します。異なる種類の鍵では暗号化できません。 参考 : KEYS.NEW_WRAPPED_KEYSET なお id 列の値は今回の対象テーブルである my_table としています。暗号化・復号するときにこの id をもとに鍵を選ぶ想定です。 4. データ格納用テーブルを作成 実データを入れるテーブル my_table を作ります。平文テキストと暗号化後のテキストを入れる列をそれぞれ作りますが、もちろん実際の運用ではこのようなことはしません。検証用に、並べて見比べるためです。 CREATE TABLE `my-project.my_dataset.my_table` ( id INTEGER , normal_text STRING, encrypted_text BYTES ) 暗号化後のデータを入れる列は BYTES 型 である点に注意してください。 5. データを暗号化してテーブルに格納 次に、 my_table にデータを暗号化して書き込みます。なお次のサンプル SQL を Web UI の編集画面に入力すると、バリデーションで以下のように表示されるかもしれません。 Query error: deterministic_encrypt requires the keyset chain and its arguments (kms_resource_name and first_level_keyset) to be constant. at [7:1] KEYS.KEYSET_CHAIN() の第一引数に定数を入れよ、というエラーですが、無視して実行することができます。bq query コマンドで --dry_run をかけた場合も同様にエラーが返りますが、 --dry_run を外すと問題なく実行できます。 DECLARE selected_keyset BYTES; DECLARE plain_text STRING; SET selected_keyset = (SELECT keyset FROM `my-project.my_dataset.my_keysets` WHERE id = " my_table " ); SET plain_text = ' This is a classified text. ' ; INSERT `my-project.my_dataset.my_table` (id, normal_text, encrypted_text) SELECT 1 , plain_text, DETERMINISTIC_ENCRYPT( KEYS.KEYSET_CHAIN( ' gcp-kms://projects/my-project/locations/asia-northeast1/keyRings/my-test-keyring/cryptoKeys/my-test-key ' , selected_keyset ), plain_text, '' ) 鍵セットは my_keysets テーブルから引いてきています。暗号化対象の平文は This is a classified text. という文字列です。これを DETERMINISTIC_ENCRYPT() 関数で確定的暗号化します。 第一引数には、入れ子で関数 KEYS.KEYSET_CHAIN() が入っています。これはラップされた鍵セット (DEK) を Cloud KMS 鍵 (KEK) で復号して鍵セットを返す関数です。 KEYS.KEYSET_CHAIN() の第一引数には Cloud KMS 鍵を、第2引数には my_keysets から引いてきたラップされた鍵セットを指定します。 第二引数には、暗号化したい平文を指定します。 第三引数は additional_data (追加情報) を指定できます。例えば、ID 列の値などです。復号時に同じ値を指定しないとエラーになります。今回は空白としています。 参考 : DETERMINISTIC_ENCRYPT 参考 : KEYS.KEYSET_CHAIN 5. データを読み取る（復号なし） データが書き込めたので、これを読み取ってみます。 SELECT * FROM `my-project.my_dataset.my_table` 以下のような結果となるはずです。 id normal_text encrypted_text 1 This is a classified text. AWtbcFQMr21Zs (中略) ujFJ8LGS8= 暗号化が成功しています。読み取れはしましたが、 encrypted_text 列は明示的に復号していないので、意味をなさないものに見えます。 6. データを読み取って復号 次はデータを読み取り、復号してみます。次のサンプル SQL も先ほどと同じように、Web UI だと Query error: deterministic_encrypt requires the keyset chain and its arguments (kms_resource_name and first_level_keyset) to be constant. at [7:1] と出るはずですが、無視して実行可能です。 DECLARE selected_keyset BYTES; SET selected_keyset = (SELECT keyset FROM `my-project.my_dataset.my_keysets` WHERE id = " my_table " ); SELECT id, normal_text, encrypted_text, DETERMINISTIC_DECRYPT_STRING( KEYS.KEYSET_CHAIN( ' gcp-kms://projects/my-project/locations/asia-northeast1/keyRings/my-test-keyring/cryptoKeys/my-test-key ' , selected_keyset ), encrypted_text, '' ) AS decrypted_text FROM `my-project.my_dataset.my_table` DETERMINISTIC_DECRYPT_STRING() 関数により復号します。 第一引数は、暗号化のときと同じく、DEK を KEK で復号するために KEYS.KEYSET_CHAIN() を使います。 第二引数は暗号化データ、第三引数は暗号化時に指定した additional_data と同じ文字列を指定します（今回は空文字列）。 参考 : DETERMINISTIC_DECRYPT_STRING 以下のような結果となるはずです。正しく復号できたことが分かります。 id normal_text encrypted_text decrypted_text 1 This is a classified text. AWtb (中略) GS8= This is a classified text. トラブルシューティング Incompatible CryptoKey location Incompatible CryptoKey location. Resource location: us, Key location: asia-northeast1; error in KEYS.NEW_WRAPPED_KEYSET expression これは、Cloud KMS 鍵のロケーションと BigQuery データセットのロケーション（正確には、ジョブ実行ロケーション）が異なっているために表示されるエラーメッセージです。 以下のようなユースケースは実業務ではあまりありませんが、以下のように FROM 句にテーブルを指定しないクエリを実行したときも、自動的に US マルチリージョンでジョブが実行されるので、上記のメッセージが出ます（明示的にクエリ設定で KMS 鍵と同じリージョンを指定すれば実行できます）。 SELECT KEYS.NEW_WRAPPED_KEYSET( ' gcp-kms://projects/my-project/locations/asia-northeast1/keyRings/my-test-keyring/cryptoKeys/my-test-key ' , ' DETERMINISTIC_AEAD_AES_SIV_CMAC_256 ' ) AS wrapped_keyset Query error: Permission 'cloudkms.cryptoKeyVersions.useToDecryptViaDelegation' denied Query error: Permission 'cloudkms.cryptoKeyVersions.useToDecryptViaDelegation' denied on resource 'projects/my-project/locations/asia-northeast1/keyRings/key-ring-tokyo/cryptoKeys/tokyo-key' (or it may not exist).; error in DETERMINISTIC_DECRYPT_STRING expression at [5:1] これは、Cloud KMS 鍵 (KEK) に対して権限を持っていないのに復号関数を使おうとしたときのエラーです。あるいは、キー ID が間違っている可能性もあります。 Query error: deterministic_encrypt requires the keyset chain and its arguments to be constant Query error: deterministic_encrypt requires the keyset chain and its arguments (kms_resource_name and first_level_keyset) to be constant. at [7:1] もしくは Query error: deterministic_decrypt_string requires the keyset chain and its arguments (kms_resource_name and first_level_keyset) to be constant. at [5:1] これは、前述の検証作業の中でも紹介した、バリデーションのみで表示されるエラーです。BigQuery の Web UI や bq query --dry_run で表示されますが、実際にクエリを実行すると、問題なく実行できます。 DETERMINISTIC_ENCRYPT() 関数の第一引数は定数が入ることが想定されているようです。クエリパラメータ ( @〜 ) や変数定義でリテラルを指定していればこの警告は出ませんが、当記事の検証のように、SELECT 文でキーセットを取得するような処理を書くとこの現象がおきます。 Query error: AEAD.DECRYPT_STRING failed Query error: DETERMINISTIC_ENCRYPT failed: Creation of Deterministic AEAD primitive failed: Primitive type N6crypto4tink17DeterministicAeadE not among supported primitives N6crypto4tink8CordAeadE, N6crypto4tink4AeadE for type URL type.googleapis.com/google.crypto.tink.AesGcmKey; error in DETERMINISTIC_ENCRYPT expression at [7:1] もしくは Query error: AEAD.ENCRYPT failed: Creation of AEAD primitive failed: Primitive type N6crypto4tink4AeadE not among supported primitives N6crypto4tink17DeterministicAeadE for type URL type.googleapis.com/google.crypto.tink.AesSivKey; error in AEAD.ENCRYPT expression at [7:1] 暗号化関数に対応していない種類の鍵で暗号化 / 復号しようとすると、このエラーが出ます。 前述の検証作業で見たように、確定的な関数では DETERMINISTIC_AEAD_AES_SIV_CMAC_256 を、非確定的関数で使うには AEAD_AES_GCM_256 を指定して鍵セットを作成する必要があります。 Query error: DETERMINISTIC_DECRYPT_STRING failed Query error: DETERMINISTIC_DECRYPT_STRING failed: decryption failed; error in DETERMINISTIC_DECRYPT_STRING expression at [5:1] 暗号化時に指定した additional_data (追加情報) と同じものを復号化時に指定しないと、上記のエラーとなります。 深掘り情報 鍵セットのローテーション ローテーションの概念 鍵セットは SQL の KEYS.ROTATE_WRAPPED_KEYSET() 関数を使ってローテーションすることができます。 鍵セットの中身はプライマリ暗号鍵とセカンダリ暗号鍵 (群) に分かれています。鍵セットに対してローテーションをかけると、プライマリ暗号鍵がセカンダリ暗号鍵に降格し、新しいプライマリ暗号鍵が生成されます。セカンダリ暗号鍵はローテーションするたびに増えていきます。 つまり、latest な最新版の鍵がプライマリ暗号鍵であり、過去バージョンがセカンダリ暗号鍵です。セカンダリ暗号鍵は、過去に暗号化したデータを復号するために残しておく必要があります。セカンダリ暗号鍵は無効化または破棄することができ、無効化や破棄をすると、そのバージョンで暗号化されたデータは復号できなくなります。 これは Cloud KMS 鍵のバージョニングとよく似ています。鍵の定期的なローテーションにより、万一 DEK が漏洩した場合でも、攻撃者が解読可能なデータの範囲が少なくなります。 参考 : AEAD 暗号化のコンセプト - 鍵セット 参考 : AEAD 暗号化のコンセプト - 鍵のローテーション 影響 鍵セットをローテーションすると、確定的暗号関数でアウトプットされる出力結果は、 ローテーション前とは違うもの になります。 暗号化関数を使った暗号化には常にプライマリ暗号鍵が使われる仕様だからです。鍵セットをローテーションするとプライマリ鍵が新しくなるので、確定的暗号化関数の結果も異なるものになってしまいます。 一方で、復号の際は単に鍵セットを指定すれば、自動的に過去のセカンダリ暗号鍵から適切なものが使われて復号されます。 確定的暗号関数のアウトプットを集計や結合に利用している場合は、鍵セットをローテーションする際に「鍵セットをローテーションする」→「暗号化済みのデータを全て復号して新しい鍵で再度、暗号化する」というプロセスが必要になります。 また古いセカンダリ暗号鍵は無効化や破棄が可能ですが、無効化・破棄すると復号に使えなくなるので、これを行う場合は非確定的暗号化関数を使っているデータでもやはり「鍵セットをローテーションする」→「暗号化済みのデータを全て復号して新しい鍵で再度、暗号化する」というプロセスが必要です。 メモリ上の DEK 列レベル暗号化されたデータを読み取る際、SELECT 時にラップされた鍵セット (DEK) が Cloud KMS 鍵 (KEK) で復号され、一時的に DEK がメモリ上に保持されて、BigQuery はこれを使ってデータの復号を行います。 メモリ上の DEK はクエリの期間中のみメモリに保存され、その後破棄されます。 参考 : Cloud KMS を使用した列レベルの暗号化 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen 又吉です。今回は、Vertex AI Gemini API の Function Calling を触ってみたの概要を紹介します。 はじめに Gemini とは Function calling とは Function calling の仕組み Vertex AI Extensions との違い 触ってみる 実行環境 事前準備 動作確認 はじめに Gemini とは Geminiとは、Google から発表された高性能なマルチモーダルな生成 AI モデルです。テキストおよび画像、動画などの様々な種類のデータを入力、出力として扱えるモデルです。Gemini には、パラメータ規模が異なる Gemini Ultra、Gemini Pro、Gemini Nano の 3 つのモデルがあります。 2023年12月現在、Vertex AI 上では、Gemini Pro が Preview 公開されています。 参考 : 最大かつ高性能 AI モデル、Gemini を発表 - AI をすべての人にとってより役立つものに Function calling とは Function calling とは、ユーザーの入力（プロンプト）に応じて、事前に定義されたソースコード上の関数から呼ぶべき関数とその関数に渡す引数を Vertex AI Gemini API が JSON で出力してくれる機能のことです。 例えば、「沖縄の天気を教えて？」という入力に対して、通常の LLM では最新の天気予報の情報は持っていないため、正しい情報は帰ってきません。正しい回答を生成するには、地名を引数として最新の天気情報を返す関数を定義しておき、それを呼び出す必要があります。 Function calling のユースケース そこで重要となるのが、Function calling です。Function calling を用いると、プロンプトの内容から、Vertex AI Gemini API がどの関数を呼び出すべきかを判断してくれます。その判断を元に、サーバは天気情報を返す関数を実行して、ユーザーへの回答を生成することができます。 Function calling の振る舞い 事前定義の関数の例として他にも、インターネット検索ができる関数や、EC 上で決済を実行する関数など、様々なユースケースで利用が期待できます。 Function calling の仕組み Function calling を利用するには、LLM への入力にプロンプトと合わせて 事前定義した関数の情報を記載した関数宣言 (function declarations) を渡す 必要があります。 LLM はこの関数宣言から関数の目的を理解し、ユーザーのプロンプトに最適な関数を選択します。 関数宣言には以下の情報を含めます。 関数名 関数の説明 関数パラメーター (引数。 OpenAPI スキーマ と互換性がある) # 関数宣言の例 FunctionDeclaration( name= "get_current_weather" , description= "指定された場所の現在の天気を取得する" , parameters={ "type" : "object" , "properties" : { "location" : { "type" : "string" , "description" : "場所" } } }, ) 参考 : Function calling の仕組み Vertex AI Extensions との違い Function calling と Vertex AI Extensions は、似た機能ですが、ユースケースによって使い分けることが推奨されています。 例えば、Function calling と Vertex AI Extensions を実行する基盤上に認証情報を含めたくない場合には、 Function calling が適しています。なぜなら、Vertex AI Extensions はそれ自体で関数を実行しますが、Function calling では最適な関数とその引数を応答に含めるだけだからです。 また、数秒以上かかる非同期操作を実行する場合にも、疎結合アーキテクチャの Function calling が適しています。 参考 : Function calling のユースケース 触ってみる 実行環境 当記事では、 Colab Enterprise の Notebook 上で Python を実行します。Colab Enterprise は、マネージドな Notebook のためインフラストラクチャを管理せず実装に注力できます。 Colab Enterprise の Notebook 作成方法は公式ドキュメントのクイックスタートをご参考下さい。 cloud.google.com 事前準備 Notebook が立ち上がり、ランタイムと接続できましたら以下のコードを実行してライブラリのインストールを行います。 # input:[1] !pip3 install --upgrade google-cloud-aiplatform ライブラリのインストールができたら、以下を実行してランタイムを再起動します。 # input:[2] import IPython # ランタイムの再起動 app = IPython.Application.instance() app.kernel.do_shutdown( True ) # output[2] { ' status ' : ' ok ' , ' restart ' : True } 次に、Vertex AI インスタンスとモデルの初期化を行います。 # input[3] import requests import vertexai from vertexai.preview.generative_models import ( Content, FunctionDeclaration, GenerativeModel, Part, Tool, ) PROJECT_ID = {プロジェクト ID} LOCATION = "us-central1" # Vertex AI インスタンスの初期化 vertexai.init(project=PROJECT_ID, location=LOCATION) # モデルの初期化 model = GenerativeModel( "gemini-pro" ) 今回は、Function Calling の動きを理解するのが目的のため、天気を取得する関数は簡易的な関数として定義します。 # input[4] # 現在の天気を取得するダミー関数 def get_current_weather (location): if location == "東京" : return "晴れ" elif location == "沖縄" : return "曇り" else : return "雨" 最後に、Function Calling 関数を定義します。 # input[5] # 関数宣言を作成 get_current_weather_func = FunctionDeclaration( name= "get_current_weather" , description= "指定された場所の現在の天気を取得する" , parameters={ "type" : "object" , "properties" : { "location" : { "type" : "string" , "description" : "場所" } } }, ) # LLM が呼び出すツールを定義 weather_tool = Tool( function_declarations=[get_current_weather_func], ) # Function calling 関数を定義 def function_calling (prompt) -> dict : response = model.generate_content( prompt, generation_config={ "temperature" : 0 }, tools=[weather_tool], ) return response 参考 : python-aiplatform/vertexai/generative_models/_generative_models.py - GitHub 動作確認 まずは、Function callling のレスポンスを確認してみます。 「東京の天気は？」というユーザーのプロンプトに対して、Function calling によって LLM が最適な関数と引数を取得していることがわかります。 尚、レスポンスの出力結果では、日本語の文字列が utf-8 でエンコードされて出力されています。 # input[6] prompt = "東京の天気は？" response = function_calling(prompt) print (response) print ( "------" ) if response.candidates[ 0 ].content.parts[ 0 ].function_call.name: print (f "最適な関数 : {response.candidates[0].content.parts[0].function_call.name}" ) print (f "必要な引数 : {response.candidates[0].content.parts[0].function_call.args.get('location')}" ) else : print (f "最適な関数 : 何もなし" ) # output[6] candidates { content { role: " model " parts { function_call { name: " get_current_weather " args { fields { key: " location " value { string_value: " \346\235\261\344\272\254 " } } } } } } finish_reason: STOP safety_ratings { category: HARM_CATEGORY_HARASSMENT probability: NEGLIGIBLE } safety_ratings { category: HARM_CATEGORY_HATE_SPEECH probability: NEGLIGIBLE } safety_ratings { category: HARM_CATEGORY_SEXUALLY_EXPLICIT probability: NEGLIGIBLE } safety_ratings { category: HARM_CATEGORY_DANGEROUS_CONTENT probability: NEGLIGIBLE } } usage_metadata { prompt_token_count: 5 total_token_count: 5 } ------ 最適な関数 : get_current_weather 必要な引数 : 東京 続いて、Function calling に与えている関数では解決できないプロンプトを投げてみます。すると、出力には「何もなし」となり想定どおりの挙動です。 # input[7] prompt = "為替レートを教えて？" response = function_calling(prompt) print (response) print ( "------" ) if response.candidates[ 0 ].content.parts[ 0 ].function_call.name: print (f "最適な関数 : {response.candidates[0].content.parts[0].function_call.name}" ) print (f "必要な引数 : {response.candidates[0].content.parts[0].function_call.args.get('location')}" ) else : print (f "最適な関数 : 何もなし" ) # output[7] candidates { content { role: " model " parts { text: " \347\224\263\343\201\227\350\250\263\343\201\202\343\202\212\343\201\276\343\201\233\343\202\223\343\201\214\343\200\201\347\202\272\346\233\277\343\203\254\343\203\274\343\203\210\343\201\253\351\226\242\343\201\231\343\202\213\346\203\205\345\240\261\343\201\257\346\217\220\344\276\233\343\201\247\343\201\215\343\201\276\343\201\233\343\202\223\343\200\202 " } } finish_reason: STOP safety_ratings { category: HARM_CATEGORY_HARASSMENT probability: NEGLIGIBLE } safety_ratings { category: HARM_CATEGORY_HATE_SPEECH probability: NEGLIGIBLE } safety_ratings { category: HARM_CATEGORY_SEXUALLY_EXPLICIT probability: NEGLIGIBLE } safety_ratings { category: HARM_CATEGORY_DANGEROUS_CONTENT probability: NEGLIGIBLE } } usage_metadata { prompt_token_count: 5 candidates_token_count: 12 total_token_count: 17 } ------ 最適な関数 : 何もなし 最後に、天気を取得するダミー関数の実行までを行います。 # input[8] prompt = "沖縄の天気は？" response = function_calling(prompt) if response.candidates[ 0 ].content.parts[ 0 ].function_call: # 関数名を取得 function_name = response.candidates[ 0 ].content.parts[ 0 ].function_call.name # 引数に必要な location を取得 location = response.candidates[ 0 ].content.parts[ 0 ].function_call.args.get( "location" ) # 実行可能な関数 available_functions = { "get_current_weather" : get_current_weather } exec_function = available_functions[function_name] # 関数を実行 function_response = exec_function(location) print (f "「{location}」の天気は、「{function_response}」です。" ) else : print (f "最適な関数 : 何もなし" ) # output[8] 「沖縄」の天気は、「曇り」です。 又吉 佑樹 (記事一覧) クラウドソリューション部 はいさい、沖縄出身のクラウドエンジニア！ セールスからエンジニアへ転身。Google Cloud 全 11 資格保有。Google Cloud Partner Top Engineer 2024。Google Cloud 公式ユーザー会 Jagu'e'r でエバンジェリストとして活動中。好きな分野は AI/ML。 Follow @matayuuuu

G-gen の佐伯です。 前編 では PyGithub の管理タスク自動化の事前準備・導入について紹介しました。後編では新規ブランチの作成、ブランチ内ファイルの更新・削除、プルリクエストの自動化についてご紹介したいと思います。 はじめに 前編記事 当記事でやること 事前準備 データを準備 Github リポジトリを作成・main ブランチにファイルを準備 新規ブランチ作成 ファイルの新規作成 ファイルの更新 ファイルの削除 プルリクエスト プログラムの実行 ソースコード 実行結果 はじめに 前編記事 当記事では、PyGithub の利用方法を解説しています。 PyGithub は、GitHub の API を Python から利用するためのライブラリです。前提となる利用方法は前編でも解説していますので、ご参照ください。 blog.g-gen.co.jp 当記事でやること 当記事（後編）では、新規ブランチの作成、ブランチ内ファイルの更新・削除、プルリクエストの自動化として、以下の①〜④のタスクを実行します。 新規作成ブランチ（名称: stg_dev ）を作成 stg_dev ブランチ内にファイル update_contents.txt を新規作成（BigQuery から読み取ったデータを書き込み） 既存ファイル test.txt を削除 ブランチ main へのプルリクエスト 事前準備 データを準備 今回は、BigQuery に以下のようなデータを準備し、これらのカラムを update_contents.txt に書き込むことにします。 { 'id' : 1 , 'group_email' : 'google-1234@g-gen.co.jp' , 'subnet_info' : '10.0.25.0/24' , 'UPDATE_FLG' : 'DLT' , 'client_cidr' : '123.0.10.12/24' , 'use_purpose' : 'normal' } Github リポジトリを作成・main ブランチにファイルを準備 今回はGithubに以下のようなリポジトリを作成し、 main ブランチに test.txt ファイルを作成します。リポジトリ名は Osamu-Saiki/test です。 Github のシークレットアカウントの作成や PyGithub のインストール等基本的な操作手法については、前編を確認ください。 新規ブランチ作成 sha に main ブランチを指定し、新規ブランチを create_git_ref メソッドで作成します。 # 新しいブランチを作成 repo.create_git_ref(ref=f 'refs/heads/{new_branch_name}' , sha=repo.get_branch(main_branch).commit.sha) sha (Secure Hash Algorithm) はセキュアなハッシュ関数の一種で、データの一意な識別子を生成するために使用されます。 ファイルの新規作成 create_file メソッドに、ファイルパス・メッセージ・更新内容・更新ブランチをそれぞれ設定して実行します。 repo.create_file( #ファイルパス path=updatefile, #メッセージ message= "update_contents.txtファイルを作成" , #更新内容(string) content=update_data, #更新ブランチ branch=new_branch_name ) ファイルの更新 update_file メソッドに、ファイルパス・メッセージ・更新内容・更新ブランチ・sha をそれぞれ設定して実行します。 repo.update_file( # 転送元のブランチのファイルパス指定 path=updatefile, #メッセージ message=f "{updatefile}ファイルを更新" , #更新内容(string) content=update_data, # 送信先のブランチ指定 branch=new_branch_name, #shaの指定 sha=update_file_class.sha ) ファイルの削除 delete_file メソッドに、ファイルパス・メッセージ・sha・対象ブランチをそれぞれ設定します。 repo.delete_file( #ファイルパス path=deletefile, #メッセージ message=f "{deletefile}を削除" , #shaの指定 sha=delete_contents.sha, #対象ブランチ branch=new_branch_name ) プルリクエスト create_pull メソッドにプルリクのタイトル・内容・プルリク元のブランチ・マージする先のブランチをそれぞれ設定します。 pull_req = repo.create_pull( # プルリクエストのタイトル title= "modify repository" , # プルリクエストの内容 body=f "Add updated {updatefile} file" , # プルリク元のブランチを指定 head=new_branch_name, # プルリクエストをマージする先のブランチを指定 base=main_branch ) プログラムの実行 ソースコード 以下のようなソースコードを実行することで stg_dev ブランチ（新規ブランチ）が Osamu-Saiki/test リポジトリに作成され main ブランチにプルリクが出されます。 ①config_data.json { " LOG_LEVEL " : 20 , " access_token " : " ghp_************************* ", " repository_name " : " Osamu-Saiki/test ", " main_branch " : " main ", " credentials_file " : " /home/saikio/.ssh/saikio-************.json ", " project " : " saikio ", " dataset_id " : " user_regist ", " table_id " : " user_regist_list " } ②ソースコード from github import Github, GithubException from google.cloud import bigquery from google.oauth2 import service_account import traceback import logging import json with open ( 'config_data.json' , 'r' ) as f: config = json.load(f) LOG_LEVEL = config[ "LOG_LEVEL" ] logging.basicConfig( format = "[%(asctime)s][%(levelname)s] %(message)s" , level=LOG_LEVEL ) logger = logging.getLogger() logger.setLevel(LOG_LEVEL) # GitHubアクセストークンを設定 access_token = config[ "access_token" ] # GitHubリポジトリとブランチ情報を設定 repository_name = config[ "repository_name" ] main_branch = config[ "main_branch" ] # BigQueryに接続する為のサービスアカウント等の設定 credentials_file = config[ "credentials_file" ] credentials = service_account.Credentials.from_service_account_file(credentials_file) bigquery_client = bigquery.Client(credentials=credentials) # BigQueryのテーブル初期設定 project = config[ "project" ] dataset_id = config[ "dataset_id" ] table_id = config[ "table_id" ] # GitHubに接続 g = Github(access_token) # bqより編集したいidの必要なデータを取得する関数 def get_regist_data (): query = f "select " \ f "id, group_email, subnet_info, UPDATE_FLG, client_cidr, use_purpose " \ f "from `{project}.{dataset_id}.{table_id}` " \ f "where UPDATE_FLG is not null and use_purpose='normal' order by id asc" query_job = bigquery_client.query(query) # 必要なデータを収集 data_group = [] for row in query_job: _data = dict () for key, val in row.items(): _data[key] = val data_group.append(_data) return data_group # 申請内容に応じてブランチ及びproject_info.tfvarsファイルにデータを書き込みする関数 def create_branch (_res): # リポジトリを取得 repo = g.get_repo(repository_name) # 新規ブランチ名 new_branch_name = "stg_dev" # 更新ファイル(新規作成ファイル) updatefile = "update_contents.txt" # 削除ファイル deletefile = "test.txt" # 更新データ update_data = f 'subnet_info : {_res["subnet_info"]} \n ' \ f 'group_email : {_res["group_email"]} \n ' \ f 'use_purpose : {_res["use_purpose"]} \n ' \ f 'client_cidr : {_res["client_cidr"]}' try : # 新しいブランチを作成 repo.create_git_ref(ref=f 'refs/heads/{new_branch_name}' , sha=repo.get_branch(main_branch).commit.sha) except GithubException as e: if e.data[ "message" ] == 'Reference already exists' : pass else : # Error logger.error( "exceptions : {} : {}" .format(e, traceback.format_exc())) return 'NG' try : #　新規ファイル作成 repo.create_file( path=updatefile, message= "update_contents.txtファイルを作成" , content=update_data, branch=new_branch_name ) # 削除対象となるファイル全体をオブジェクトとして取得 delete_contents = repo.get_contents(path=deletefile, ref=new_branch_name) #　ファイル削除 repo.delete_file( path=deletefile, message=f "{deletefile}を削除" , sha=delete_contents.sha, branch=new_branch_name ) except GithubException as e: # 既にupdate_contents.txtファイルが存在する場合 if e.data[ "message" ] == "Invalid request. \n\n\" sha \" wasn't supplied." : update_file_class = repo.get_contents(updatefile, ref=new_branch_name) #　ファイル更新 repo.update_file( path=updatefile, # 転送元のブランチのファイルパス指定 message=f "{updatefile}ファイルを更新" , content=update_data, branch=new_branch_name, # 送信先のブランチ指定 sha=update_file_class.sha ) else : # Error logger.error( "exceptions : {} : {}" .format(e, traceback.format_exc())) return 'NG' try : # プルリクエスト(stg_devブランチからmainブランチへ) pull_req = repo.create_pull( title= "modify repository" , body=f "Add updated {updatefile} file" , head=new_branch_name, # 新しいブランチを指定 base=main_branch # プルリクエストをマージする先のブランチを指定 ) except GithubException as e: # プルリクエストが既に存在する場合 if 'A pull request already exists' in e.data[ "errors" ][ 0 ][ "message" ]: pass else : logger.error( "exceptions : {} : {}" .format(e, traceback.format_exc())) return 'NG' return 'SUCCESS' if __name__ == '__main__' : res = get_regist_data() for row in res: if row[ "UPDATE_FLG" ] == 'DLT' : res = create_branch(row) if res == 'NG' : logger.error(f 'ID:{row["id"]}のブランチの更新に失敗しました!!' ) break 実行結果 想定通り stg_dev ブランチが作成され、 update_contents.txt ファイルにデータが書き込まれ、 main ブランチにプルリクが出されています。 ①プルリク ②ファイルの更新 stg_dev ブランチ内の test.txt ファイルは削除され、 update_contents.txt ファイルにデータが書き込まれています。 ③stg_devブランチの作成 佐伯　修 (記事一覧) クラウドソリューション部 前職では不動産業でバックエンドを経験し、2022年12月G-genにジョイン。 入社後、Google Cloudを触り始め、日々スキル向上を図る。 SEの傍ら、農業にも従事。水耕を主にとする。

G-gen の佐伯です。最近の業務で GitHub のブランチ作成やブランチ内のファイルの更新・削除を自動化する機会が多かったので、ご紹介したいと思います。 はじめに PyGithub とは 当記事でやること 事前準備（アクセストークン生成） ライブラリの取得 オーナーのリポジトリ一覧を取得 特定のリポジトリ内の全ファイルのパスの一覧を取得 はじめに PyGithub とは 当記事では、PyGithub の利用方法を解説しています。 PyGithub は、GitHub の API を Python から利用するためのライブラリです。Python で GitHub の REST API をコールして、リポジトリ、Issue、プルリクエストなどの GitHub リソース管理を自動化するために使われます。 当記事でやること 当記事（前編）では、管理タスク自動化の事前準備・導入として、 リポジトリのブランチ内のファイルパスの一覧取得手法 を紹介します。 事前準備（アクセストークン生成） GitHubのアカウント設定から アクセストークン を生成します。 GitHubにログインし、ページの右上にある『Setting』をクリック 開いたページの左側のメニューから『Developer Setting』を選択 『Developer Setting』ページから『Personal access tokens』⇛『Tokens(classic)』 を選択 access tokenの名称・有効期間・権限スコープを選択（権限スコープは今回は『repo』のみ） ページの最下部の『generate token』を選択 生成されたtokenをコピーする。 トークンの漏洩はそのままレポジトリ情報の漏洩に繋がる ため、十分注意すること。 ライブラリの取得 pip を使い venv 環境に PyGithub をインストールします。 オーナーのリポジトリ一覧を取得 テストとして以下のプログラムを実行して、自分（アクセストークンを発行したアカウント）がオーナーとなっているリポジトリの一覧を取得します。 テストコードのためトークンがハードコーディングされていますが、 本番プログラムでは決して行わないでください 。 from github import Github # 上記で取得したaccess token token = 'ghp_******************************' # tokenを設定 g = Github(token) for repo in g.get_user().get_repos( type = 'owner' ): print (repo.name) 実行結果 特定のリポジトリ内の全ファイルのパスの一覧を取得 次に、上記を基に特定のリポジトリ（今回は Osamu-Saiki/test2 ）の main ブランチ内の全オブジェクトのパスの一覧を取得します。 Osamu-Saiki/test2リポジトリのmainブランチの中身 terraform/commom/** terraform/env/ terraform/modules/ 以下のプログラムを実行します。先程と同じくテストコードのためトークンがハードコーディングされていますが、 本番プログラムでは決して行わないでください 。 from github import Github # GitHubアクセストークンを設定 access_token = 'ghp_*************************' # GitHubリポジトリとブランチ情報を設定 repository_name = 'Osamu-Saiki/test2' branch_name = 'main' # GitHubに接続 g = Github(access_token) # リポジトリを取得 repo = g.get_repo(repository_name) def folder_copy (): source_branch = repo.get_branch(branch_name) source_tree = repo.get_git_tree(source_branch.commit.sha, recursive= True ) for entry in source_tree.tree: print (entry.type, entry.path) if __name__ == '__main__' : folder_copy() 実行結果 なお他にも repo.get_contents で対象のリポジトリのファイルの中身の取得、 repo.create_git_ref で新規のブランチを作成することができます。 後編では、新規ブランチの作成、ブランチ内ファイルの更新・削除、プルリクエストの自動化等をご紹介できればと思います。 佐伯　修 (記事一覧) クラウドソリューション部 前職では不動産業でバックエンドを経験し、2022年12月G-genにジョイン。 入社後、Google Cloudを触り始め、日々スキル向上を図る。 SEの傍ら、農業にも従事。水耕を主にとする。

当記事では、BigQuery に統合された Vertex AI Feature Store というベクトルストアと、テキストの意味をベクトル化できる Vertex AI Text-Embeddings API を使った活用事例をご紹介します。 当記事は Google Cloud Champion Innovators Advent Calendar 2023 の7日目の記事です。 Vertex AI Feature Store とは Vertex AI Text-Embeddings API とは 活用例 ①レコメンド ②グラウンディング サンプルアプリ アーキテクチャ 検索画面 検索結果 データの拡張 回答文 サンプルコード 他の生成 AI 事例 Vertex AI Feature Store とは Vertex AI Feature Store は、Google Cloud が提供するフルマネージドのベクトルストアです。同サービス自体は従来より存在しましたが、2023年10月に 「BigQuery 統合版」がプレビュー公開され、同年11月に GA（一般公開）となりました。以前のバージョンはレガシー（従来）版という位置づけになりました。 参考 : Vertex AI release notes - October 04, 2023 参考 : Vertex AI での特徴管理の概要 Vertex AI Feature Store はベクトルと呼ばれる機械学習の特徴量を保存する専用のデータストアです。Bigtable 等の Google のインフラを利用した高速なオンライン（リアルタイム）特徴量データストアを簡単に構築でき、自前で構築する必要がなくなります。また、今回新たに特徴量のベクトル検索機能が追加されたため、ベクトル検索エンジンとして使うことも可能になりました。 Feature Store の特徴量ストアは、 BigQuery の既存テーブルから自動的に同期できます。そのため、これまでのようにデータウェアハウス（BigQuery）、特徴量ストア、ベクトル検索インデックスのそれぞれを別々に用意する必要がありません。ベクトル検索インデックスの構築も自動的に行われます。 Vertex AI Text-Embeddings API とは LLM（大規模言語モデル）によって、テキストの意味解釈をしたベクトル（数値表現）を返す API です。ベクトル抽出用の最新版安定モデルは2023年12月時点で textembedding-gecko@002 です。 参考 : 利用可能な安定版のモデル ここで、そもそものベクトルとは何で、どう使うかの説明をします。例えば「海ぶどう」と「ラーメン」という言葉をLLMがベクトルで表現するしくみを単純化した例が以下の図になります。 この図では、横軸が「カロリー」、縦軸が「沖縄度」だとした場合に、 「海ぶどう」はカロリーが低く沖縄っぽさが高いため、（カロリー, 沖縄度）＝（0.1, 0.9）というベクトルで表現されています。 一方で、「ラーメン」はカロリーが高く沖縄というよりは万国共通の食べ物のため、（カロリー, 沖縄度）＝（0.9, 0.2）というベクトルで表現されています。 これはあくまでごく単純化した例ですが、Embeddings for Text はこのように個々の言葉や文章の意味を相対的な距離で表す768次元のベクトルを返します。あとはベクトル同士の距離を求めるだけで、近い概念の言葉を見つけることができます。 また、Embeddings for Text では個々の単語に限らず、最大3000トークンまでの文章の意味をベクトル化することも可能です。 例えば、「麺の上に豚肉がのった沖縄料理」≒「沖縄（ソーキ）そば」となりますが、Vertex AI Embeddings for Text によって、両者が近い概念であることを踏まえた数値表現を得ることができます。 ベクトルは単なる数値の集まりであり、簡単な四則演算によりベクトル同士の距離を計算できます。この距離の最も近いものが意味的にも近いものとなります。この仕組みを使い、例えばユーザーが入力した検索クエリを Embeddings for Text によりベクトル化して、それに距離の近いものを順に返すことで、意味の近さによる検索（意味検索）機能を実装できます。 つまり、Embeddings for Text で取得したベクトルをBigQueryテーブルに保存するだけで、Feature Store のベクトル検索機能を使った「意味検索」を簡単に実現できます。 ベクトル検索は、レコメンドやグラウンディングといった用途に活用できます。 活用例 ①レコメンド レコメンドの仕組みは色々あるため、すべては網羅できませんが、ここでは EC サイト等でよく見る以下の 2 つを考えてみます。 自分と似ているユーザが買った商品をおすすめされる（≒ ユーザベースレコメンド） 自分が過去に買ったものと似ている商品をおすすめされる（≒ アイテムベースレコメンド） 「1. 自分と似ているユーザが買った商品をおすすめされる」に関しては、自分と似ているユーザを探すために、ユーザ同士の類似性を割り出せれば良さそうです。同様に、「2. 自分が過去に買ったものと似ている商品をおすすめされる」に関しては、商品同士の類似性を求めれば良いことになります。 先程のベクトル検索の内容を踏まえると、ユーザにしろ、商品にしろ、一旦ベクトル化してしまえば、以下のように掛け合わせでレコメンドすることができます。この手法は「Two-Tower」モデルと呼ばれ、これまで一般的だった「誰がどの商品を何個買ったか」のような購買データのみによるレコメンドモデルではなく、ユーザ属性や商品属性といったあらゆる特徴量を活用できる拡張性があります。 参考：「 Google を支える推薦モデル「Two-Tower」とベクトル近傍検索技術 」 似たような商品ばかりおすすめされるようであれば、(2)類似アイテムに関しては、 非 類似度を見るようにしてもいいです。潜在的な商品要求にマッチする可能性があります。 ②グラウンディング ベクトル検索により生成AIで扱えるデータを拡張したりハルシネーションを抑制する手法はグラウンディングと呼ばれます。 以下のように、質問文をベクトル化し、最も類似するアイテムの情報を引っ張り出して、プロンプトによって回答文を仕上げます。 処理フローは以下の通り。 質問文をベクトル化 例：「うどんが好きなんですが、沖縄でそれと似ている食べ物について教えてください。→ (0.5, 0.9) ベクトル検索で最も類似するアイテムを検索 例：沖縄そば（0.6, 0.9） ヒットしたアイテムの情報（カラム）を変数化し、プロンプトに埋め込んで生成 AI に与える 例：「あなたは沖縄観光大使のチャットボットです。お客様からの商品問い合わせ 「 ${質問} 」 に対して、沖縄の魅力が十分に伝わるようなレコメンドをしてください。前提となる情報は、商品名となる ${名前} 、商品の概要は ${概要} 、商品の売上額は ${売上額} 、商品の売上数は ${売上数} とし、これらを統合して訴求するのです」 回答を得る 例：「オススメは 沖縄そば と言いまして、日本の・・。売上額は 10億円、売上数は・・・」 ポイントは、「概要」のような文章と、「売上額」や「売上数」のような集計情報を組み合わせることで、自社データを活用したオリジナルの生成AIによる検索サービスが作れる点です。 LLM の基盤モデルは最新情報や自社の情報は持っていないため、このようにリアル情報に「接地（＝グラウンディング）」させることで、ハルシネーション（幻覚）の問題を抑制できます。 サンプルアプリ 「活用例②：グラウンディング」のサンプルとして、Google 画像検索の仕組みを真似て、問い合わせに最もマッチする食品アイテムを表示するアプリを作ってみました。 アーキテクチャ フロント側は AppSheet というノーコードローコードでさくっとアプリケーションを作れるツールで構築しています。機能説明とアーキテクチャは以下のとおりです。 サンプルアプリの機能 アーキテクチャ 検索画面 ユーザからの入力を受け付ける画面は以下です。ここに質問を打ち込むと、生成 AI が最もマッチする商品を探して、商品説明をしてくれます。 検索画面 検索結果 「おすすめのスイーツ」という問い合わせに対して、最もマッチしたのは以下の商品です。 おすすめのスイーツ データの拡張 BigQuery のレコードとしては以下です。embedding 列は非表示にしていますが、こちらをベクトル検索に使っています。 このテーブルにある 「description」、「sales_amount」、「number_of_sales」列をさらに言語生成系の API である text-unicorn@001 にプロンプトともに入力しています。 グラウンディングにかける情報 回答文 以下は、最終的な回答結果です。概要説明だけでなく、売上額や売上数などの集計情報も自然に含まれた形になっています。 沖縄の伝統的な焼き菓子「ちんすこう」は、サクサクとした食感と優しい甘さが魅力です。主な材料は小麦粉、砂糖、ラードで、これらを練り合わせて焼き上げます。元々は王族や貴族のための菓子でしたが、今では沖縄のお土産として広く親しまれています。そのバリエーションは豊富で、プレーンタイプから、黒糖や塩、紅芋など様々なフレーバーが楽しめます。軽い食感と独特の風味が、お茶請けやおやつに最適です。 2022年度の売上額は200,000,000円、売上数は133,333食を記録しました。沖縄の魅力が詰まった「ちんすこう」を、ぜひ一度ご賞味ください。 サンプルコード 以下の処理に関してノートブックにコードをまとめました。 画像やテキストからベクトルを抽出して BigQuery に格納する（マルチモーダルモデルとテキストモデル両方のサンプルを掲載） Vertex AI Feature Store にオンラインインスタンスを立てる 問い合わせをベクトル化し、Vertex AI Feature Store で類似探索を行い、結果を表示する github.com 他の生成 AI 事例 Google Cloud を用いた生成 AI のアーキテクチャや実装例については弊社 G-gen のブログでも扱っているため、興味のある方は御覧ください。 参考 : Generative AI カテゴリの記事 参考 : Vertex AI Search and Conversation カテゴリの記事 神谷 乗治 (記事一覧) データアナリティクス準備室 室長 クラウドエンジニア。2017 年頃から Google Cloud を用いたデータ基盤構築や ML エンジニアリング、データ分析に従事。クラウドエース株式会社システム開発部マネージャーを経て現職。Google Cloud Partner Top Engineer 2023、Google Cloud Champion Innovators（Database）、 著書：「GCPの教科書III【Cloud AIプロダクト編】」 　

G-gen の杉村です。当記事では Google Cloud（旧称 GCP）をベースに、クラウド料金の見積もり方法・試算方法を徹底解説します。 はじめに 3つの性質 1. 従量課金 2. 月次請求 3. 変動する 試算方法 料金ページ 料金試算ツール リセールパートナーを頼る 割引 コミットメント制度 請求代行（リセールパートナー） 見積もり手順の例 手計算 Calculator はじめに 当記事では Google Cloud （旧称 GCP）をベースに、クラウド料金の見積もり方法（試算方法）を徹底解説します。 なおこの記事で「クラウド料金」とは Google Cloud、Amazon Web Services、Microsoft Azure のようなメガ・パブリッククラウドを指すものとします。この記事では Google Cloud を例にとって解説しますが、他のクラウドでもベースとなる考え方は同じです。 まず最初に「従量課金であること」「原則的には月次で請求されること」「毎月変動する可能性があること」という最も基本的な性質を理解していただきます。 その後、具体的な試算方法を解説します。 最後に、コスト効率よくクラウドを使うための割引の仕組みについてご紹介します。 3つの性質 1. 従量課金 クラウドは利用時間や利用ボリュームに応じた 従量課金 が原則です。使った分だけを支払う、と言い換えることもでき、英語では Pay as You Go、略して PAYG とも呼ばれます。 オンプレミスではサーバなどの物理機器を購入すると、初期導入時に大きな金額がかかりますが、クラウドでは初期費用がかからないことが一般的です。その代わりサーバを1時間起動したら、1時間分だけの料金が発生します。ですので使わない間はリソースを削除ないしは停止しておけば料金がかからなくなります。 一部にはライセンス数ごとや期間ごとのサブスクリプションなど例外もありますが、多くがこの原則に従うと考えてください。 2. 月次請求 クラウドは 月次での請求 が一般的です。従量課金によって発生した料金が、毎月末に締められ、月初の数営業日程度で請求金額が確定し、請求されます。 こちらにも一部は例外があります（年間コミットにより割引が発生する契約など）が、ほとんどの場合で月次請求です。 3. 変動する クラウドでは基本的に、 請求額が毎月変動 します。例えば4月は30日間のため、720時間である一方、5月は31日間あるため744時間であり、サービス稼働時間が異なるため請求額が異なります。 またネットワーク使用ボリュームなどは毎月細かく変動するため、微妙に請求額が変動することを想定する必要があります。 試算方法 料金ページ 基本的には、パブリッククラウドの利用料は全てインターネットで公開されています。以下のようなページです。 参考 : Compute Engine pricing 参考 : BigQuery pricing 「どの機能を」「どのスペックで」「どのくらいの時間 / ボリュームで利用すると」「いくらになる」のか、全てこの料金ページから読み取ることができます。ただし、ある程度プロダクトの仕様を理解していないと解釈が難しい場合もあります。 例として Google Cloud の Compute Engine だと、マシンタイプ、永続ディスク、そしてネットワーク通信といった意味をある程度理解している必要があります。 また、クラウド利用料金は定価が変わることがあります。常に最新版の Web ページを参照することが重要です。また Google Cloud に関しては、最新の料金体系や単価を知るには英語版のページを参照することが望ましいです（日本語版のページの翻訳が間に合っていない場合があります）。 料金試算ツール 前述のように料金ページを参照して手動計算すると、考慮漏れや計算間違いのリスクがあります。 そのようなときは、公式の料金試算ツールを活用することで、考慮漏れを防ぐことができます。埋めるべき枠を埋めていくことで、料金を算出できます。 参考 : Google Cloud Pricing Calculator Google Cloud Pricing Calculator リセールパートナーを頼る 後述のように、クラウドの請求代行を行っているリセールパートナーに見積もりを依頼するのも一手です。 リセールパートナーは料金見積もり方法を熟知しているうえ、パートナー特有の割引を受けられる可能性もあります。 当記事を執筆している 株式会社G-gen は Google Cloud のリセールパートナーです。また、AWS のリセールパートナーとしては 株式会社サーバーワークス などがあります。 割引 コミットメント制度 プロダクトによっては一定期間のコミットメント（期間を決めた利用確約）を行うことで割引を受けられる料金制度が用意されています。 例えば Google Cloud の仮想サーバ提供サービスである Compute Engine では確約利用割引（CUD、Committed Use Discounts）の仕組みがあり、1年もしくは3年の利用確約を行うことで最大で半額以上の割引を受けることができます。詳細は以下の記事もご参照ください。 blog.g-gen.co.jp 請求代行（リセールパートナー） 各クラウドのリセールパートナーの請求代行（課金代行）サービスを経由してクラウドを利用することで、パートナーが独自に用意している割引制度の恩恵を受けることができます。 例として G-gen の Google Cloud 請求代行サービスでは、5%の利用料金割引を受けられるうえ、無料の技術サポート窓口や「セキュリティスイート」など特典が多数付与されています。 g-gen.co.jp 見積もり手順の例 手計算 Compute Engine を例にして、クラウド料金の見積もりを行う手順をご紹介します。なお当記事中に紹介されている料金単価はすべて、2023年12月現在のものです。 今回は、以下のようなスペックの Compute Engine VM を利用する場合の見積もりをすると仮定します。 4 vCPU 16 GB RAM Windows Server 2022 C ドライブ : 100 GB D ドライブ : 200 GB まず、VM（インスタンス）自体の料金を見積もります。VM には、vCPU と RAM の料金が含まれます。 料金ページ「 Compute Engine pricing 」を見て、 e2-standard-4 （4 vCPU / 16 GB RAM）マシンタイプの Tokyo (asia-northeast1) の時間単価が $0.171928 であることを確かめます。 一年の中には28日ある月、30日ある月、31日ある月とが混在していますが、平均を取るとちょうど730時間ですので、ここではひと月を730時間と仮定して計算します。VM 料金は 0.171928 × 730 = $125.50744 / 月であることが分かります。 Windows Server は有償 OS ですので、 プレミアムイメージ の料金表を確認します。Windows Server の料金は $0.046 / 時間 / vCPU であることが表示されています。今回は 0.046 × 730 × 4 という計算になり、$134.32 / 月です。 ディスク料金は合計300 GB です。 永続ディスクの料金ページ を見ると、最も基本的な永続ディスクである Balanced は東京リージョンでは $0.13 / GB であると表示されています。0.13 × 300 で $39 / 月です。 最後にこれらを合計します。125.50744 + 134.32 + 39 = $298.82744 となり、日本円ではドル円140円換算で約41,836円 / 月です。 なおここでは、Compute Engine VM を起動し続けると自動的に適用される「継続利用割引」は考慮に入れていません（ 参考 ）。 また、 ネットワーク通信料金 も発生します。ネットワーク通信は VM に出入りするパケットのボリュームに応じた従量課金なのですが、事前の見積もりが最も難しい部分でもあります。便宜的に「予算では VM の利用料金に10%をかけた分を見込んでおく」のように簡易的に見積もることもあります。 Calculator 上記のように手計算を行うと、少し手間であることが分かると思います。 公式の Google Cloud Pricing Calculator を利用すると、必要な数字を入力するだけでこのような計算は一瞬で終わることになります。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

はじめに 当記事について おまけ画像 コンピューティング Compute Engine コンテナ Artifact Registry Cloud Build Cloud Deploy Google Kubernetes Engine（GKE） データ分析 BigQuery Looker Dataproc Dataflow Pub/Sub データベース Bigtable Spanner Cloud SQL Firestore Memorystore サーバーレス App Engine Cloud Run functions Cloud Run ストレージ Cloud Storage ネットワーキング Cloud Armor Cloud CDN Cloud DNS Cloud Next Generation Firewall（Cloud NGFW） Cloud Load Balancing VPC Service Controls 運用 Cloud Logging Cloud Monitoring セキュリティと ID Sensitive Data Protection Cloud Key Management Service (KMS) Secret Manager Identity and Access Management (IAM) さいごに はじめに 当記事について 当記事は、「Google Cloud（旧称 GCP）の主要サービスを、それぞれ50文字程度で解説してみる」という記事です。 「Google Cloudの主要サービス一覧がみたい」とか「概要をざっくり理解しておきたい」といったご要望にお答えできるように作成しました。以下のカテゴリ別に、私が重要だと思ったサービスを取り上げています。サービス区分は https://cloud.google.com/products?hl=ja を元にしています。複数カテゴリに所属するサービスは、どちらか一方に寄せています。 コンピューティング コンテナ データ分析 データベース サーバレス ストレージ ネットワーキング 運用 セキュリティと ID おまけ画像 当記事の内容を1枚の画像にまとめました。印刷して自然と目に入る壁に貼っていただくことで、自然と覚えられる！...かもしれません。 50文字で説明 仕様上、ブログ上ではこれ以上の画質にすることが難しそうでしたが、ご了承ください。 コンピューティング Compute Engine オンプレミスサーバーと同等の仮想マシンサービス。世界中の Google のデータセンターで提供。(48文字) コンテナ Artifact Registry コンテナイメージなどを保存するリポジトリサービス。暗号化、アクセス制御、脆弱性スキャンも可能。(47文字) Cloud Build ソースコードからコンテナイメージをビルドするサービス。ソースコードさえあれば簡単にビルドを実行可能。 (50文字) Cloud Deploy CI/CDプロセスを自動化して、コンテナイメージやバイナリファイルをアプリケーションにデプロイする。(50文字) Google Kubernetes Engine（GKE） Kubernetes クラスターを簡単に作成管理できるサービス。コンテナアプリの実行に最適。(45文字) データ分析 BigQuery 大規模なデータ分析に最適なクラウドデータウェアハウスサービス。ログデータや顧客データの分析に活用。 (49文字) Looker データの可視化・分析を統合したBIサービス。データを簡単に接続して、直感的にレポートを作成可能。(48文字) Dataproc 大規模データ処理ツール（Apache Hadoop や Apach Spark など）を提供するサービス。(47文字) Dataflow ストリーム処理サービス。センサーデータのリアルタイム分析などに活用可能。(36文字) Pub/Sub 非同期メッセージングサービス。イベント通知やアプリ連携などに活用可能。(35文字) データベース Bigtable 大規模な時系列データやログデータの格納に最適なNoSQLデータベース。低レイテンシで大量データ。(48文字) Spanner グローバル分散で高いスケーラビリティを備えたRDB。可用性99.999%と、ミリ秒単位のレイテンシ。(50文字) Cloud SQL MySQL、PostgreSQL、SQLServerをクラウド上で利用できるサービス。(43文字) Firestore ドキュメント型のデータモデルを採用し、リアルタイムでのデータアクセスが可能なNoSQL DB。(46文字) Memorystore Redis または Memcached をクラウド上で利用できる、フルマネージドのインメモリデータストア。(50文字) サーバーレス App Engine サーバーレスなアプリケーション実行環境。Web、モバイル、IoT など、様々なアプリケーションに対応。(50文字) Cloud Run functions イベントドリブンな関数実行サービス。コードをアップロードするだけで、イベントに応じて関数が実行可能。(50文字) ※2024年8月、Cloud Functions は Cloud Run functions にリブランディング（名称変更）されました。 Cloud Run コンテナアプリケーション実行サービス。コンテナをアップロードするだけで、アプリケーションが実行可能。(50文字) ストレージ Cloud Storage 高耐久性、高可用性なオブジェクトストレージ。ウェブコンテンツからログデータ保管まで幅広く活用可能。(49文字) ネットワーキング Cloud Armor DDoS 攻撃をはじめ悪意のあるトラフィックからウェブアプリケーションを保護するサービス。(44文字) Cloud CDN 世界中にキャッシュサーバーを展開し、Web コンテンツをユーザーに近い場所から配信するサービス。(47文字) Cloud DNS マネージドDNSサービス。グローバルなネットワークで、高可用性と低レイテンシを実現。(42文字) Cloud Next Generation Firewall（Cloud NGFW） VPC のネットワークトラフィックを制御。ポート、プロトコル、IPアドレス等の条件で制御可能。(47文字) Cloud Load Balancing トラフィックを複数のサーバーに分散し、アプリケーションの可用性とパフォーマンスを向上させるサービス。(50文字) VPC Service Controls Google Cloud リソースへのアクセスをIP アドレス、デバイス等の条件で制御するサービス。(50文字) 運用 Cloud Logging ログデータを収集・保存・分析するサービス。可視化・分析により、問題の早期発見と解決を支援。 (45文字) Cloud Monitoring アプリケーションやインフラのパフォーマンスや状態を監視。メトリクス、ログ、アラート等を統合的に管理。(50文字) セキュリティと ID Sensitive Data Protection 機密データの流出を防ぐためのサービス。機密データの識別、検出、保護を行い、情報漏洩リスクを低減。(48文字) ※Cloud Data Loss Prevention（Cloud DLP）は Sensitive Data Protection の一部になりました。ただし、API 名や機能名として Data Loss Prevention（DLP）が残っています。 Cloud Key Management Service (KMS) 暗号化キーの管理を提供するサービス。強固な暗号化キーを安全に管理し、データの機密性と整合性を保護。(49文字) Secret Manager パスワード、API キー、トークンといった機密情報を安全に管理するためのサービス。(40文字) Identity and Access Management (IAM) Google Cloudにおけるユーザーの認証とアクセス権の管理を提供するサービス。(41文字) さいごに 以下のリンク集には、各サービスの徹底解説記事がまとめられています。これから Google Cloud を学ぼうとしている方は、ぜひ参考にしてください！ blog.g-gen.co.jp 三木宏昭 (記事一覧) クラウドソリューション部 HROne→ServerWorks→WealthNavi→G-gen。AWS 11資格、Google Cloud認定全冠。Google Cloud Partner Top Engineer 2024。Google Authorized Trainer Follow @cloudeep_miki

G-gen の杉村です。2023年11月のイチオシ Google Cloud アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Duet AI が Cloud Logging のログを要約・説明 (GA) 復数の Duet AI 関連アップデート BigQuery で異なるユーザ間でもキャッシュが効くように BigQuery で過去〜現在のストレージ使用量を取得可能に (Preview) BigQuery で TEXT_ANALYZE 関数が登場 (Preview) Generative AI support on Vertex AI で東京含むリージョン拡大 Looker Studio Pro の Android/iOS 用アプリがリリース Cloud Spanner のパフォーマンス (読み・書き QPS) が従来の1.5倍 Network Connectivity Center で VPC スポークが GA Cloud SQL で Enterprise Plus へのインプレイス・アップグレード Cloud Spanner で Managed autoscaler が Preview 公開 Cloud Run のサイドカーコンテナが Preview => GA Duet AI in Google Workspace が2024年に日本語対応 Egress/Ingress という言葉が Data Transfer Out/In に変更 BigQuery based の Vertex AI Feature Store が Preview => GA Cloud Storage で Object Lock 機能が使えるように Cloud Armor で Network edge security polices が使えるように Google Slides で録画機能 はじめに 月ごとの Google Cloud アップデートのうち、特にイチオシなものをまとめています。 ある程度の事前知識が必要な記載となっています。サービスごとの前提知識は、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp またリンク先の公式ガイドは英語版にしないと最新情報が反映されていない場合がありますためご注意ください。 Duet AI が Cloud Logging のログを要約・説明 (GA) Summarize log entries with Duet AI assistance (2023/11/01) Duet AI が Cloud Logging のログを要約・説明してくれる機能が GA。 Cloud Logging のログエクスプローラにて、ログを選択して要約ボタンを押すと、ログの意味を自然言語で解説してくれる。 2023/11/02のリリース時点では、英語版にしないとボタンが出て来ない。 復数の Duet AI 関連アップデート Duet AI release notes (2023/11/01) 前述のログエントリの解説機能のほか、以下のアップデートも発表された。 Duet AI for Cloud Shell (コード補完) Duet AI for Cloud Workstations (コード補完) Colab Enterprise での Inline code completion with Duet AI assistance (コード補完) VPC Service Controls での Duet AI support BigQuery で異なるユーザ間でもキャッシュが効くように Cross-user caching (2023/11/01) BigQuery で異なるユーザ間でも、クエリ結果にキャッシュが効くようになった (GA)。 従来は同一プロジェクトかつ同一アカウント（ユーザ）である必要があった。当アップデートで、同一プロジェクトであればキャッシュが効くようになり、パフォーマンスとスキャン料金に良い影響がある。 ただし Enterprise または Enterprise Plus edition のみで有効。 BigQuery で過去〜現在のストレージ使用量を取得可能に (Preview) TABLE_STORAGE_USAGE_TIMELINE view (2023/11/01) BigQuery で過去〜現在のストレージ使用量を取得可能に (Preview)。 システムビュー INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE から過去状況のスナップショットを取得可能になった。過去90日間のストレージ使用量が記録されている。 INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE_BY_ORGANIZATION のほうでは組織レベルで取得可能。 BigQuery で TEXT_ANALYZE 関数が登場 (Preview) TEXT_ANALYZE (2023/11/02) BigQuery で TEXT_ANALYZE 関数が登場 (Preview)。 インプットしたテキストを単語分割したり特定条件に基づいて正規化できる。同様のオプション群が SEARCH INDEX でも使えるようになっている。 以下は出力例。 SELECT TEXT_ANALYZE( ' I like pie, you like-pie, they like 2 PIEs. ' , analyzer=> ' PATTERN_ANALYZER ' ) AS results /*----------------------------------------------------------------* | results | +----------------------------------------------------------------+ | ['like', 'pie', 'you', 'like', 'pie', 'they', 'like', 'pies' ] | *----------------------------------------------------------------*/ Generative AI support on Vertex AI で東京含むリージョン拡大 Generative AI on Vertex AI locations (2023/11/02) Generative AI support on Vertex AI の API エンドポイントを提供するリージョンが拡大。北米、ヨーロッパ、アジアの 12 リージョンで API が提供開始。 アジアでは以下リージョンで利用可能。 Tokyo, Japan Seoul, Korea Singapore Looker Studio Pro の Android/iOS 用アプリがリリース Looker Studio Pro now available for Android and iOS (2023/11/04) Looker Studio Pro の Android/iOS 用アプリがリリース。 既存のPC用レポートもダイナミックにモバイル用デザインで表示できる。 Looker Studio Pro については以下の記事も参照。 blog.g-gen.co.jp 画像は 公式ブログ より引用 Cloud Spanner のパフォーマンス (読み・書き QPS) が従来の1.5倍 Increased performance throughput (2023/11/07) Cloud Spanner のパフォーマンスが従来の1.5倍になった。追加コスト / 追加作業なしで、読み取り・書き込みの QPS (Query per second) が従来の1.5倍になる。 2023年10月に大阪リージョン等に適用されていたが、今回東京リージョンなども追加で対象になった。 Network Connectivity Center で VPC スポークが GA VPC spokes overview (2023/11/08) Network Connectivity Center で VPC 同士をフルメッシュ接続する「VPC スポーク機能」がPreview から GA に。 AWS Transit Gateway のごとく、ハブアンドスポーク構成で複数の VPC を接続できるようになった。フルメッシュで VPC peering をするよりも効率的になる。 Network Connectivity Center については以下の記事も参照。 blog.g-gen.co.jp VPC スポークによる構成と VPC peering による構成 Cloud SQL で Enterprise Plus へのインプレイス・アップグレード Introducing Cloud SQL in-place upgrade: move from Enterprise to Enterprise Plus with ease (2023/11/10) Cloud SQL で Enterprise エディションから Enterprise Plus エディションへのインプレイス・アップグレードが可能に。 これまではスナップショット → リストアする必要があったが、コマンド一発でアップグレード可能になった。IP アドレスなども変わらない。60秒未満のダウンタイムが発生する。 Cloud Spanner で Managed autoscaler が Preview 公開 Managed autoscaler (2023/11/13) Cloud Spanner で Managed autoscaler が Preview 公開。 CPU 使用率やストレージ使用率に応じてノード数が増減。ストレージのリバランスも自動的に行われる。 Cloud Run のサイドカーコンテナが Preview => GA Deploying multiple containers to a service (sidecars) (2023/11/13) Cloud Run のサイドカーコンテナが Preview => GA。 モニタリング系コンテナ、Envoy、AlloyDB Auth Proxy などサイドカーコンテナが Cloud Run service で動かせるようになった。 Duet AI in Google Workspace が2024年に日本語対応 G-gen Tech Blog - Google Cloud Next Tokyo '23速報レポート (2023/11/15) Duet AI in Google Workspace が2024年中に日本語対応することが、Google Cloud Next Tokyo '23 で発表された。 Duet AI in Google Workspace は、生成 AI で業務補助を行う Google Workspace のアドオン。以下の記事も参照。 参考 : Duet AI for Google Workspace をプレビューしてみた (Google Docs 編) 参考 : Duet AI for Google Workspace をプレビューしてみた (Gmail 編) 参考 : Duet AI for Google Workspace をプレビューしてみた (Google Slides 編) Egress/Ingress という言葉が Data Transfer Out/In に変更 FAQ: Renaming Egress to Data Transfer (2023/11/16) Google Cloud の利用明細の SKU から「Egress」「Ingress」という言葉が無くなり、「Data Transfer Out」「Data Transfer In」に変更される。 2023/12/15 から適用。SKU ID は変更なし。もし分析で SKU description でフィルタする SQL を書いている場合は、SQL の変更が必要となる。 BigQuery based の Vertex AI Feature Store が Preview => GA Vertex AI release notes - November 17, 2023 (2023/11/17) 新しい Vertex AI Feature Store が Preview => GA。従来の Feature Store と異なり、BigQuery が基盤になっている。 推論のための Online serving も可能で、こちらの機能も GA。Online serving の裏では Bigtable が稼働している。 一部機能は Preview のままのため注意が必要。 Cloud Storage で Object Lock 機能が使えるように Object Retention Lock (2023/11/21) Cloud Storage で Object Lock 機能が使えるようになった。 Object Lock 機能では、オブジェクトを指定日時まで削除・更新できなくなり write once, read many (WORM) を実現。従来からバケット単位で設定する「保持ポリシー」は存在したが、今回のobject lock (object retention) ではオブジェクト単位で設定可能。 以下の記事でも解説。 blog.g-gen.co.jp Cloud Armor で Network edge security polices が使えるように Configure network edge security policies (2023/11/21) Cloud Armor で Network edge security polices と呼ばれる新しいセキュリティポリシーが使えるようになった（申請した利用者のみ使える）。 Public IP を持つ VM などにもアタッチ可能なポリシー。アタッチ可能なフロントエンドは以下の通り。 External passthrough Network Load Balancers Protocol forwarding パブリック IP を持つ VM Network edge security polices ではソース IP、ソース ASN、地域などで制限がかけられる。VPC Firewall とできることは似ているが、今後の拡張への布石か。 Google Slides で録画機能 Create shareable video presentations in Google Slides (2023/11/28) Google Slides で録画機能が使えるようになった。 プレゼンテーションを録画でき、音声を含ませることができる。ウェビナーなどに利用可能。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の堂原です。本記事では Google Cloud (旧称 GCP) のセキュリティサービスである VPC Service Controls において、IP アドレスを許可したにも関わらずアクセスが弾かれるケースにおける見落としがちな原因について紹介します。 はじめに 事象 : IP アドレスを許可したはずがアクセス失敗 原因 : IPv6 アドレスでアクセスしていた 確認方法 解消方法 はじめに VPC Service Controls は Google Cloud が提供しているセキュリティサービスです。 「サービス境界」と呼ばれる論理的な囲いを作成し、境界を跨ぐような API コールを制限します。 VPC Service Controls については、以下の記事で解説していますのでご参照ください。 blog.g-gen.co.jp VPC Service Controls においては、 アクセスレベル を設定することで、特定の条件を満たす通信が境界の外から中にアクセスすることを許可することができます。 条件には IP アドレス範囲や地域を指定することが可能です。 事象 : IP アドレスを許可したはずがアクセス失敗 改めて、VPC Service Controls ではアクセスレベルを用いることで、特定の IP アドレス範囲から境界内へのアクセスを許可することができます。 そのためにはまずはアクセスレベルを作成し、その際に許可したい IP アドレスを設定します。 次に今しがた作成したアクセスレベルを設定したサービス境界を作成します。 以上の設定で、境界で指定したプロジェクト (上図では黒塗りしている部分に記載) の BigQuery には、アクセスレベルで許可した IP アドレスのみがアクセスできるはずです。 しかしアクセス元の通信環境次第では、アクセスレベルで IP アドレスを正しく許可したと思っても、アクセスが弾かれるケースがあります。その際以下のようなエラーメッセージが出力されますが、これだけでは「VPC Service Controls によってアクセスが拒否された」という事実しか分かりません。 VPC Service Controls: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: xxx 原因 : IPv6 アドレスでアクセスしていた もちろん、上記エラーメッセージだけだと単に IPv4 アドレス範囲の指定が誤っていたことが原因の場合もあります。 しかし、IPv4 アドレスの指定は正しいはずなのにアクセスが拒否される場合は、Google Cloud に IPv6 アドレスで アクセスしようとしていないかを確認していただきたいです。 VPC Service Controls の IP アドレス制限では、Web API の呼び出しに用いられた接続元 IP アドレスがチェックされるので、 接続元 IP アドレスが IPv6 アドレス の場合は アクセスレベルでも IPv6 アドレスを許可 する必要があります。 普段は VPC Service Controls や VPC Firewall など、IPv4 アドレスでの CIDR 指定に慣れていたことに加え、今回の作業元である自宅のインターネット回線が IPv6 対応の契約だったことを失念していたことから気が付きにくい事象でした。 確認方法 Cloud Logging を見ることで、どの IP アドレスでアクセスしようとしていたかを確認することができます。 ログエクスプローラにて、VPC Service Controls によって弾かれたアクセスのみを取得するクエリは以下の通りです。 resource.type="audited_resource" severity="ERROR" ヒットしたログの protoPayload.requestMetadata.callerIp にアクセス元の IP アドレスが記載されています。 具体的なアドレス値をマスクしているため見づらくはなっていますが、「: (コロン)」続きの形式となっていることから IPv6 アドレスでのアクセスであることがわかります。 解消方法 上記の通り、アクセスレベルで IPv6 アドレスを許可することでアクセス可能となります。 堂原 竜希 (記事一覧) データアナリティクス準備室。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @matayuuuu

G-gen の佐々木です。当記事では Google Cloud (旧称 GCP) のサーバーレス コンピューティング プロダクトの1つである Google App Engine (GAE) を解説します。 Google App Engine (GAE) とは App Engine アプリのコンポーネント アプリケーション サービス バージョン インスタンス インフラストラクチャ 可用性 ストレージ セキュリティ 他の Google Cloud サービスへのアクセス制御 カスタムドメインの使用 上り（内向き）設定 App Engine ファイアウォール モニタリング・ロギング デプロイと実行環境 アプリケーションのデプロイ 2つの実行環境 スタンダード環境 ランタイム ランタイム環境の世代について 第1世代ランタイム（レガシーランタイム） 第2世代ランタイム ランタイムのライフサイクル スケーリングタイプ スケーリングタイプとは 動的スケーリング コールドスタート ウォームアップリクエスト インスタンスクラス VPC ネットワークへの接続 フレキシブル環境 ランタイム スケーリングタイプ マシンタイプ VPC ネットワークへの接続 その他の Computing プロダクトとの比較 Google App Engine (GAE) とは Google App Engine (GAE) は Google Cloud のプロダクトの中でも最初期から提供されている PaaS（Platform as a Service）であり、アプリケーションを稼働させるためのマネージドな実行基盤を提供するサービスです。GAE とも略されますが、当記事では以降、App Engine と記載します。 App Engine ではアプリケーションのコードと設定ファイルをデプロイするだけで、Google Cloud 上でアプリケーションを実行することができます。ユーザーが VM やコンテナといった実行基盤の運用をする必要がなく、オートスケーリングや障害発生時のオートヒーリングなどの機能が提供されます。 参考 : App Engine App Engine アプリのコンポーネント アプリケーション 当記事では、App Engine にホストしたアプリケーションのことを App Engine アプリ と呼びます。 App Engine アプリを開発するには、まずプロジェクト内に アプリケーション というリソースを作成します。App Engine はこのアプリケーションを最上位のリソースとして、サービス、バージョン、インスタンスというリソースが連なる階層型のリソース構成となっています。 App Engine のリソース構成 アプリケーションはサービス以下のリソースを束ねるだけでなく、App Engine アプリの設定、認証情報、アプリケーションのメタデータのコレクションを作成、管理することができるコンポーネントであり、それらはアプリケーション作成時に指定したリージョンに格納されます。 参考： App Engine の概要 サービス アプリケーションは最低1つの サービス リソースを持ちます。App Engine アプリを単一のサービスで実行することもできますが、複数のサービスで1つのアプリを構成することで、マイクロサービスのようにアプリの機能を分離することができます。 各サービスはアプリのソースコードとそれに対応する App Engine 構成ファイルで構成されます。サービスをデプロイするたびに、サービス内に バージョン が追加されていきます。 バージョン デプロイされたサービスは バージョン リソースとしてバージョニングされており、バージョン間で トラフィック移行 を行うことで、特定のバージョンに対してトラフィックのルーティングを素早く切り替えることができます。 また、 トラフィック分割 により複数バージョンに対してトラフィックをルーティングすることもできます。これらの機能により、App Engine アプリのテストやロールバックを容易に行うことができます。 インスタンス バージョンは1つ以上の インスタンス で実行され、負荷に応じてスケーリングすることができます。 インスタンスの実行基盤は App Engine の実行環境（後述）により異なります。スタンダード環境では Google のインフラストラクチャ上で実行されるコンテナインスタンス、フレキシブル環境ではユーザープロジェクトの VPC で起動される Compute Engine 仮想マシン上の Docker コンテナで実行されます。 後述する App Engine の 実行環境 によって、インスタンスの実行基盤は異なります。 インフラストラクチャ 可用性 App Engine はリージョナルサービスであり、App Engine アプリを実行するインフラストラクチャはユーザーが指定したリージョンに配置され、自動的にリージョン内のすべてのゾーンで冗長化されます。 参考 : App Engine のロケーション ストレージ App Engine アプリは基本的にインスタンスに状態を持たない（ステートレス）設計となるため、データは App Engine の外に保存します。 リレーショナルデータベースとして Cloud SQL、NoSQL データベースとして Firestore、オブジェクトストレージとして Cloud Storage の使用が推奨されています。 参考 : データとファイルのストレージについて また、スタンダード環境では /tmp ディレクトリに対して一時ファイルの読み書きを行うことができます。このディレクトリに保存されたファイルはすべてインスタンスのメモリに格納されます。 参考 : 一時ファイルの読み取りと書き込み セキュリティ 他の Google Cloud サービスへのアクセス制御 App Engine アプリでは、バージョン単位でサービスアカウントを設定することで、他の Google Cloud サービスのアクセス権限を付与することができます。 Compute Engine 同様、 編集者（role/editor） ロールをもつデフォルトのサービスアカウントが提供されていますが、最小権限の原則に従ったユーザー管理のサービスアカウントを使用することが推奨されています。 参考 : アクセス制御の設定（スタンダード環境）]( https://cloud.google.com/appengine/docs/standard/access-control?hl=ja&tab=go ) カスタムドメインの使用 App Engine アプリでは、デフォルトで生成される appspot.com ドメインの URL を使用することで HTTPS によるアクセスを行うことができます。 また、App Engine の機能でマネージド SSL 証明書を発行することで、HTTPS アクセスにカスタムドメインを使用することもできます。 参考 : アプリのセキュリティの概要 上り（内向き）設定 以下の3種類の 上り（内向き）設定 により、App Engine アプリへのネットワークアクセスを制限することができます。 設定名 許可するアクセス元 内部 ・同一プロジェクト内の VM ・共有 VPC ・サーバーレス VPC アクセスコネクタ（スタンダード環境） 内部と Cloud Load Balancing ・ 内部の設定で許可されているもの ・外部アプリケーションロードバランサ すべて すべて デフォルトでは、インターネット上のすべてのリソースが App Engine アプリにアクセスすることができます。 参考 : 上り（内向き）設定 App Engine ファイアウォール App Engine ファイアウォール を使用することで、App Engine アプリにリクエストを送信できる IP アドレス範囲を制限することができます。 Compute Engine のファイアウォールルールと異なり、App Engine のファイアウォールは受信トラフィック（上り/内向き）に対してのみ適用されます。 対象となる IP アドレス範囲ごとに許可/拒否のルールを作成し、ルールには優先度（1 ~ 2147483647）を設定します。デフォルトでは、すべての IP アドレスからのアクセスが許可する優先度最低（2147483647）のルールのみ登録されています。 App Engine ファイアウォールについて モニタリング・ロギング App Engine は Cloud Monitoring と統合されており、コンピューティングリソースの使用率やレスポンスのレイテンシ、実行中のインスタンス数などのメトリクスがデフォルトで提供されます。 また Cloud Logging では、App Engine のログとして以下の2種類のログを収集できます。 ログの種類 説明 リクエストログ App Engine アプリに送信されるリクエストのログ。自動で収集される。 アプリログ アプリケーションのログ。アプリで使用する言語ごとに用意された方法でログエントリを作成する必要がある。 アプリログついては、 stdout または stderr にテキスト文字列を送信するだけで Cloud Logging のログエントリを作成することができます。しかし、重要度でログをフィルタリングする必要がある場合などは ログを構造化データとしてフォーマットする 必要があります。 参考 : ログの書き込みと表示 デプロイと実行環境 アプリケーションのデプロイ App Engine では、 app.yaml という設定ファイルに実行環境やランタイム、コンピューティングリソースなどの構成（それぞれ後述）を記述し、コードと一緒にデプロイすることでアプリケーションを実行することができます。 以下は Python を使用する App Engine アプリの app.yaml ファイルの例です。使用ランタイムやインスタンスクラス、リクエストの URL パターンごとの処理方法などが記述されています。 runtime : python312 instance_class : F2 env_variables : BUCKET_NAME : "example-gcs-bucket" handlers : # Matches requests to /images/... to files in static/images/... - url : /images static_dir : static/images - url : /.* secure : always redirect_http_response_code : 301 script : auto 設定ファイルの記述内容は実行環境により異なります。詳しくは以下のドキュメントを参照してください。 参考 : App Engine app.yaml リファレンス（スタンダード環境） 参考 : app.yaml 構成ファイル（フレキシブル環境） 2つの実行環境 App Engine でアプリケーションを実行する場合、 スタンダード環境 と フレキシブル環境 のどちらかを選択します。 スタンダード環境 ではサポートされる言語の種類とバージョンに制限がある代わりに、Cloud Functions や Cloud Run のようなサーバーレスの実行基盤が利用できます。アプリケーションは gvisor ベースのコンテナインスタンスで実行され、高速なスケーリングと ゼロスケーリング （インスタンス数を0にスケールインする）によるコスト削減が大きなメリットとなります。 フレキシブル環境 では、マネージドな Compute Engine 仮想マシン上で Docker コンテナとしてアプリケーションが実行されます。スケーリングの単位が仮想マシンのため、スタンダード環境のようなスケーリングのメリットはありませんが、サポートされる言語の制限がなく構成の自由度の高さがメリットとなります。 実行基盤がサーバーレスか、Compute Engine 仮想マシンかの違いにより、実行環境ごとの機能に違いがあります。 以下の表は実行環境ごとの違いを一部抜粋したものです。 機能 スタンダード環境 フレキシブル環境 インスタンスの起動時間 秒単位 分単位 リクエストの最大タイムアウト ランタイムとスケーリングタイプ（後述）によって異なる。（ 参考 ） 自動スケーリングの場合は基本的に10分 60 分 バックグラウンドプロセス × ○ SSH 接続 × ○ ゼロスケーリング ○ × ローカルディスクへの書き込み Python 2.7、PHP 5.5 以外のランタイムで /tmp ディレクトリが利用可能 VM のエフェメラルディスクを利用可能 ランタイムの変更 × ○ デプロイ時間 秒単位 分単位 Websocket × ○ 料金 インスタンス時間 vCPU、メモリ、永続ディスクの使用量 実行環境（スタンダード/フレキシブル）はサービスごとに選択することができ、1つのアプリケーションに異なる実行環境のサービスを混在させることができます。これにより、各サービスの役割に応じて適切な実行環境を選択することができます。 参考： 環境ごとの機能比較 参考： App Engine スタンダード環境ユーザーのための App Engine フレキシブル環境 スタンダード環境 ランタイム ランタイム環境の世代について スタンダード環境ではフレキシブル環境と比較して、ランタイム環境としてサポートされている言語や API、ファイルシステムへのアクセス可否などの制限があります。 ランタイム環境には第1世代と第2世代があります。これから App Engine を利用する場合は、機能が大幅に改善されている第2世代を使用することになるでしょう。 スタンダード環境の世代間比較については以下のドキュメントを参照してください。当記事では特に指定のない限り、「スタンダード環境」と記載がある場合は第2世代を指しています。 参考： App Engine スタンダード環境のランタイム 第1世代ランタイム（レガシーランタイム） 第1世代は App Engine リリース当初から存在し、 レガシーランタイム と呼ばれます。 以下のように、ランタイムとしてサポートされている言語のバージョンが古く、それぞれの言語のコミュニティで既に管理されていないバージョンが含まれています。 Python 2.7 Java 8 PHP 5.5 Go 1.11 これらのランタイムは2024年1月31日のサポート終了がアナウンスされています。公式ドキュメントでは第 2世代ランタイムへの 移行ガイド が提供されています。 参考： レガシー ランタイムのサポート 第2世代ランタイム 第2世代ランタイムでは以下の言語がサポートされており、ベースとなる OS はすべて Ubuntu となっております。 Go Java Node.js PHP Python Ruby サポートされている言語のバージョンについては、以下のページから最新の情報を確認できます。 参考 : ランタイム サポート スケジュール ランタイムのライフサイクル ランタイムは プレビュー → 一般提供（GA） → サポート終了 → 非推奨 → 廃止 のライフサイクルを辿ります。このうち一般提供（GA）の期間において、セキュリティやバグの修正などの定期的なアップデート、仕様変更の通知（リリースノート）、テクニカルサポートの提供が行われます。 サポート終了期間に入る90日前に、Google Cloud からの通知を受け取ることになります。ランタイムのサポート終了日になってもアプリケーションは引き続き実行されますが、Google Cloud によるセキュリティのアップデートが行われず、テクニカルサポートの対象外となってします。また、サポートが終了したランタイムを使用するアプリケーションは作成、更新ができなくなります。 したがって、ランタイムのアップグレードは定期的に行うことが強く推奨されています。 非推奨の期間に入って以降も基本的にはアプリケーションをそのまま実行できますが、重大なセキュリティ脆弱性が発覚した場合など、事前の通知なしに無効化される可能性があります。 参考 : ランタイム ライフサイクル スケーリングタイプ スケーリングタイプとは スタンダード環境では3種類のスケーリングタイプが提供されており、後述のインスタンスクラスによって使用できるスケーリングタイプが異なります。 以下のように、スケーリングタイプによってリクエストのタイムアウトやスケーリング方式などが異なります。動的スケーリングについては後述します。 - 自動スケーリング 基本スケーリング 手動スケーリング リクエストのタイムアウト 10分 24時間 24時間 スケーリング 動的スケーリング 動的スケーリング 構成ファイルでインスタンス数を指定 スケーリングタイプごとの詳細な比較については以下のドキュメントを参照してください。 参考 : インスタンスの管理方法 動的スケーリング 基本スケーリングもしくは自動スケーリングを使用する場合、受信リクエストの量に応じたインスタンス数のスケーリングを自動で行うことができます。 なお、動的スケーリングの仕様は基本スケーリングと自動スケーリングで異なります。 基本スケーリングでは、受信したリクエストを処理できるインスタンスがない場合にのみ新しいインスタンスが起動します。したがって、新しいインスタンスが立ち上がるまでの間、受信したリクエストを処理できない場合があります。 自動スケーリングでは、スケーリングのトリガーとして以下の3つが使用できます。 トリガー 説明 CPU 使用率 CPU 使用率の閾値を事前に設定し、それを超えたときに新しいインスタンスを起動する。 スループット スループットの閾値を事前に設定し、それを超えたときに新しいインスタンスを起動する。 同時リクエスト数 インスタンスが処理できる最大同時リクエスト数を事前に設定し、それを超えたときに新しいインスタンスを起動する。 自動スケーリングでは基本スケーリングと異なり、CPU 使用率やスループットを基準としてスケーリングをトリガーすることで、既存のインスタンスがリクエストを処理する余地を残したまま新しいインスタンスを用意することができます。 コールドスタート App Engine では、以下のような状況でリクエストに対するレイテンシが発生する可能性があります。 スケーリングによって新たなインスタンスを起動するとき サービスの別のバージョンをデプロイしたとき 基盤となるインフラストラクチャのメンテナンスが行われるとき これは、新たに起動されたインスタンスがリクエストを処理するために、アプリケーションのコードやライブラリを事前に読み込む必要があるためです。 ウォームアップリクエスト スケーリングタイプが自動スケーリングの場合のみ、 ウォームアップリクエスト を有効化することで、App Engine がスケールアウトのタイミングを事前に検知し、インスタンスが実際に必要になる前にコードの読み込みを行うことができます。 ウォームアップリクエストを有効化するには、設定ファイル（app.yaml）への追記と、コードにウォームアップリクエストを処理するハンドラを実装しておく必要があります。詳細については以下のドキュメントを参照してください。 なお、ウォームアップリクエストは常に実行されることが保証されているわけではありません。インスタンス数が0から1になるときや、リクエスト数のスパイクがあった場合などはコールドスタートが発生してしまいます。ただし、ウォームアップリクエストが有効化されている場合は、すでに実行されているインスタンスに対してリクエストを優先的にルーティングし、コールドスタートの影響をできる限り少なくするような仕様になっています。 参考 : ウォームアップ リクエストを構成してパフォーマンスを改善する インスタンスクラス スタンダード環境の App Engine では、アプリケーションを実行するインスタンスのコンピューティングリソースを App Engine 独自の インスタンスクラス で指定します。 選択できるインスタンスクラスは以下の通りで、クラスによって使用可能なスケーリングタイプが異なります。 インスタンスクラス メモリ CPU サポートされているスケーリングタイプ F1（デフォルト） 384 MB 600 MHz 自動 F2 768 MB 1.2 GHz 自動 F4 1,536 MB 2.4 GHz 自動 F4_1G 3,072 MB 2.4 GHz 自動 B1 384 MB 600 MHz 手動、基本 B2（デフォルト） 768 MB 1.2 GHz 手動、基本 B4 1,536 MB 2.4 GHz 手動、基本 B4_1G 3,072 MB 2.4 GHz 手動、基本 B8 3,072 MB 4.8 GHz 手動、基本 参考 : App Engine スタンダード環境 | インスタンスのクラス VPC ネットワークへの接続 Cloud Run や Cloud Functions と同様に、スタンダード環境のインスタンスは VPC の外側にあり、Cloud SQL、Memorystore、Cloud NAT などの VPC リソースに対するプライベート IP を用いた接続には サーバーレス VPC アクセス の設定が必要になります。 以下の図は、VPC リソースである Cloud SQL のインスタンスに接続する場合の構成です。ユーザー VPC に作成したコネクタインスタンスを経由してプライベート IP を用いた接続を行っています。 スタンダード環境の App Engine から Cloud SQL に接続する場合の構成 コネクタインスタンスは常時起動となっており、起動時間ぶんのコストが常に発生してしまいます。したがって VPC に接続する必要があるケースでは、VPC 内に App Engine インスタンスを起動することができるフレキシブル環境の利用も検討する必要があるでしょう。 参考 : VPC ネットワークへの接続 フレキシブル環境 ランタイム フレキシブル環境では以下のランタイムがサポートされています。ベースとなる OS はスタンダード環境同様に Ubuntu ですが、設定ファイル（app.yaml）でバージョンを指定することができます。 Go Java Node.js PHP Python Ruby .NET カスタムランタイム スタンダード環境よりも使用可能ランタイムの種類が多いほか、 カスタムランタイム としてユーザが用意した Docker イメージを使用することができます。 参考 : App Engine フレキシブル環境 スケーリングタイプ フレキシブル環境では自動スケーリングと手動スケーリングの2種類のスケーリングタイプを使用することができます。 スタンダード環境と異なる点として、スケーリングのたびに Compute Engine 仮想マシンが新規に起動されるためスケーリング速度が遅く、また最低1つのインスタンスを常時起動している必要があります（ゼロスケールできない）。 マシンタイプ フレキシブル環境にはスタンダード環境のようなインスタンスクラスは存在せず、設定ファイル（app.yaml）で指定した CPU とメモリの量に基づいて Compute Engine のマシンタイプが割り当てられます。 したがって、スタンダード環境よりもコンピューティングリソースの量を細かく調整することができます。 VPC ネットワークへの接続 フレキシブル環境のインスタンスは Compute Engine 仮想マシンであり、ユーザーが作成した VPC 内で起動します。したがって スタンダード環境のようにサーバーレス VPC アクセスを設定することなく VPC リソースにプライベート IP アドレスで接続することができます。 その他の Computing プロダクトとの比較 以下の記事で、Google Cloud の Computing プロダクトの比較解説を行っています。 blog.g-gen.co.jp サーバーレスな Web アプリケーション実行基盤としては、Cloud Run と比較することが多いと思われます。 比較的新しいプロダクトであり積極的にアップデートが行われている Cloud Run と比較すると、リリースから15年以上の実績をもつ App Engine はいわゆる枯れたプロダクトであると言えます。したがって、App Engine のほうがユーザーによるナレッジの蓄積が多く、アップデートによる仕様変更に振り回されにくいプロダクトであるといえるでしょう。 また、Cloud Run はコンテナの利用が必須となるため、より手軽にアプリケーションをデプロイしたい場合の選択肢となります。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805