G-gen の荒井です。当記事では Google Workspace のアプリケーションのみ使用してお問い合わせシステムを作成する方法をご紹介します。 はじめに ご紹介すること 記事の構成 設定作業概要 Google フォーム作成 Google フォーム詳細設定 設定1 : Google フォーム作成 設定2 : Google フォーム詳細設定 回答の保存先を選択 フォーム設定 次の記事 はじめに ご紹介すること 当記事では問い合わせ対応システムで使用する Google フォーム の作成や設定方法をご紹介します。 Google フォームを使うことで、用意した項目を指定形式でユーザーに入力してもらうことができるため、問い合わせシステムを作成する際は必要不可欠なアプリケーションです。 記事の構成 問い合わせ対応システムの開発方法は、以下の通り、連載記事としてご紹介します。記事を順に確認することで、問い合わせ対応システムが完成します。 No タイトルとリンク 1 Google Workspace で問い合わせ対応システムを作成する方法 #1 (システム概要) 2 Google Workspace で問い合わせ対応システムを作成する方法 #2 (Google グループ設定) 3 ※ 当記事 Google Workspace で問い合わせ対応システムを作成する方法 #3 (Google フォーム設定) 4 Google Workspace で問い合わせ対応システムを作成する方法 #4 (Google App Script 設定) 5 Google Workspace で問い合わせ対応システムを作成する方法 #5 (業務フロー解説) 6 ※ 準備中 Google Workspace で問い合わせ対応システムを作成する方法 #6 (機能拡張案) 設定作業概要 Google フォーム作成 Google フォームを作成します。 Google フォームはお問い合わせ窓口の入力フォームであり、ユーザーの目に最初に触れるものです。質問項目やその説明、入力形式などが、ユーザーにとってわかりやすいものである必要があります。 当記事では、最低限の項目で、汎用的に使用できるフォームの作成方法をご紹介します。 Google フォーム詳細設定 詳細設定では、回答内容のエクスポート先となるスプレッドシートを選択したり、フォーム全体のセキュリティ設定を行います。 回答の保存先を選択 フォーム設定 回答のコピーを回答者に送信 信頼できる組織のユーザーに限定する 確認メッセージ 結果の概要を表示する 設定1 : Google フォーム作成 Google フォーム のトップページから、 空白のフォーム を選択して、フォームの作成を開始します。 ご自身のユースケースに近いものがある場合は、テンプレートを使って作成を開始することも可能です。 当記事では、お問い合わせフォームに必要最低限の質問項目をご紹介します。 Google フォーム作成に関する詳細は以下を参考にして、適宜、質問項目の追加やテーマを設定します。 参考 : Google フォームで最初のフォームを作成する - Google Workspace ラーニング センター 参考 : How to use Google Forms - Computer - Google Docs Editors Help 質問項目 : 氏名 設定項目 設定値 質問のタイトル 氏名 質問の形式 記述式 必須 有効 質問項目 : 会社名 設定項目 設定値 質問のタイトル 会社名 質問の形式 記述式 必須 有効 質問項目 : 電話番号 設定項目 設定値 質問のタイトル 電話番号 質問の形式 記述式 必須 有効 質問項目 : メールアドレス 設定項目 設定値 質問のタイトル メールアドレス 質問の形式 記述式 必須 有効 質問項目 : お問い合わせタイトル 設定項目 設定値 質問のタイトル お問い合わせタイトル 質問の形式 記述式 必須 有効 質問項目 : お問い合わせ内容 設定項目 設定値 質問のタイトル お問い合わせ内容 質問の形式 段落 必須 有効 質問項目 : 個人情報の取り扱い 設定項目 設定値 質問のタイトル 個人情報の取り扱い 説明 株式会社XXXX のプライバシーポリシーに同意します。 ※ 「プライバシーポリシー」部分に自社 Web サイトのプライバシーポリシーページへのリンクを挿入 質問の形式 チェックボックス 選択肢 ・同意する 必須 有効 設定2 : Google フォーム詳細設定 回答の保存先を選択 Google フォームで入力された内容は [回答] タブから確認できますが、 Google スプレッドシートにエクスポートする ことも可能です。 Google スプレッドシートにエクスポートすることで、関数を利用したり、Google Apps Script（GAS）を使って回答内容を別の業務へ繋げるなど、データの二次利用性が高まります。当記事では、回答内容をスプレッドシートにエクスポートする設定を行います。 参考 : フォームの回答の保存先を選択する - Google ドキュメント エディタ ヘルプ [回答] タブ内の [スプレッドシートにリンク] をクリック [新しいスプレッドシートを作成] を選択し、ファイル名を入力し [作成] をクリックします。 留意事項 [新しいスプレッドシートを作成] を選択した場合、スプレッドシートは Google フォームと同じ場所にファイルが作成されます。 スプレッドシートに個人情報などセンシティブな情報が記録される場合は、格納場所（Google ドライブ）のアクセス権を正しく設定してください。 参考 : Google ドライブのファイルを共有する - パソコン - Google ドライブ ヘルプ スプレッドシートの格納場所を変更する場合、Google ドライブの「ファイル移動」機能を使用してください。もし「コピー > 貼り付け > 元ファイル削除」などでファイルを複製してしまうと、ファイルの URL が変わってしまい、Google フォームとのリンクが解除されてしまうため、再設定が必要となります。 参考 : Google ドライブのファイルを整理する - パソコン - Google ドライブ ヘルプ フォーム設定 [設定] タブから、Google フォームの設定を変更することができます。 ご紹介する機能は一般的な問い合わせシステムを想定した内容です。実際に構築する場合、以下リンクをご確認の上、実運用に沿った設定をしてください。 参考 : フォームを共有して回答を収集する - Google ドキュメント エディタ ヘルプ 回答 > 回答のコピーを回答者に送信 ユーザーがフォームに入力した回答を自動的にユーザーのメールアドレスに自動返信する機能です。今回開発するシステムでは同等の機能を次記事の GAS で実装するため今回は「オフ」にしておきます。 回答 > 信頼できる組織のユーザーに限定する Google アカウントを持たないユーザーでも問い合わせできるようにする場合、設定を無効にします。 表示設定 > 確認メッセージ フォーム送信後、ユーザーにメッセージを表示させたい場合メッセージを設定します。 例） お問い合わせありがとうございます。 担当者にて内容確認後、ご回答させていただきます。今しばらくお待ちください。 お問い合わせいただきました内容を確認のためご入力いただきましたメールアドレスに自動返信させていただきました。メールの返信がない場合メールアドレス入力間違いの場合がございます。メールが届かない場合、再度お問い合わせフォームの入力をお願いいたします。 自動返信メール、ご回答メールは [ @xxxxxx.co.jp ] ドメインよりメールが送信されます。メールが受信できるよう設定をお願いいたします。 よろしくお願いいたします。 ■ お問い合わせ窓口 対応時間：9:00〜17:00（土日祝日・弊社指定休日を除く） 表示設定 > 結果の概要を表示する 当機能はユーザーに過去の回答結果を表示する機能になります。他のユーザーの問い合わせ内容が見えてしまうため、当記事では「オフ」にします。 次の記事 Google Workspace で問い合わせ対応システムを作成する方法 #4 (Google App Script 設定) 荒井 雄基 (記事一覧) クラウドソリューション部 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。 Google Cloud 認定資格 7冠 現在は Google Workspace を中心に企業の DX 推進をサポート。 最近頑張っていることは、子どもがハマっている戦隊モノの踊りを踊れるようになること。

G-gen の奥田梨紗です。当記事では、オンプレミスや他のクラウドサービス上にあるデータベースを Google Cloud の Cloud SQL に移行するメリットや、移行方法を紹介します。 はじめに Google Cloud のデータベース オンプレミスからクラウドへの移行 メリット メリット1. TCO の削減 メリット2. Google Cloud エコシステムとの連携強化 メリット3. 生成 AI によるデータベース運用の自動化 移行方法 1. Database Migration Service（DMS） 2. レプリケーション 3. ダンプファイルを利用 はじめに Google Cloud のデータベース Google Cloud では様々なデータベースが利用できます。データベースの特徴やユースケースに応じて、移行先のデータベースを検討してください。 ユースケース 移行先サービス名 MySQL、PostgreSQL、SQL Server をクラウド移行したい Cloud SQL PostgreSQL 互換の高性能データベースを使いたい AlloyDB for PostgreSQL 高水準の可用性とスループットが必要 / 利用者が複数リージョン Spanner 分析用データベースを利用したい BigQuery クエリパターンが NoSQL データベースに適している Firestore 、 BigTable オンプレミスからクラウドへの移行 オンプレミスからクラウドへ移行する場合のメリット・デメリット、及び判断ポイント等については下記で紹介しています。 blog.g-gen.co.jp メリット 既存のデータベースを Google Cloud へ移行するメリットは、以下が挙げられます。 1. TCO の削減 2. Google Cloud エコシステムとの連携強化 3. 生成 AI によるデータベース運用の自動化 それぞれ具体的に説明します。 メリット1. TCO の削減 クラウドへの移行は、 TCO の削減 に繋がります。 TCO （Total Cost of Ownership）とは総所有コストのことです。情報システムの導入や、管理維持に関わるすべてのコストの総額のことを指します。 月額利用料金だけを単純に試算してしまうと、オンプレミスのほうが安価になる場合が多くあります。それでもクラウドが選ばれる理由は、新たなリソース（サーバーや CPU、メモリ、ストレージなど）の追加がボタン1つ（コマンド1つ）で可能という 俊敏性 にあります。物理基盤の調達とセットアップ、維持・管理に必要な工数と比べると、クラウドで必要な工数は圧倒的に小さくなります。これが、TCO の削減の大きな部分を締めています。 またオンプレミスへのサーバー設置は、機器台だけでも初期費用として数十万円〜数百万円かかります。一方のクラウドは従量課金制であり、初期費用は不要です。 また Google Cloud の場合、「 無料プログラム 」が用意されており、一定の利用ボリュームまでは無料で利用できます。以下は、無料枠の例です。これらを活用することで、TCO の削減を図ることができます。 サービス名 用途 無料枠の例 Compute Engine 仮想サーバー 指定リージョン、指定サイズのインスタンスが一定時間、無料で利用可能 Cloud Storage オブジェクトストレージ US リージョンの Regional Storage を利用した場合、 5GB まで無料 メリット2. Google Cloud エコシステムとの連携強化 データベースを Google Cloud に移行することで、データを Google Cloud のエコシステムと連携し、 ビジネス上の価値を増幅 したり、 運用工数を削減 することが可能です。 エコシステム とは、ここでは「高度に連携しあうことでメリットを生み出す、一連のサービス群」のような意味合いです。 Google Cloud の優れたエコシステムとして、以下が挙げられます。 モダンなクラウドインフラ（コンテナ、サーバーレス、フルマネージド） 高度なデータ分析（BigQuery） 利用が容易な AI/ML（人工知能/機械学習）サービス Google Workspace による ID 管理 Google Cloud には Google Kubernetes Engine （GKE）や Cloud Run といったモダンな IT インフラサービスが揃っています。このようなサービスにアプリケーションをホストすることで、アプリケーション開発の俊敏性が増すことでビジネススピードが向上したり、ビジネスをスモールスタートすることができるようになります。また、運用コストが低いため、TCO のさらなる削減に繋がります。 また、 BigQuery をはじめとする高度なデータ分析サービスがあります。Cloud SQL や AlloyDB からは、シームレスに BigQuery にデータを複製することができ、タイムリーに複雑で大規模なデータ分析を行うことができます。また、無料で使えるダッシュボードツールである Looker Studio や、高度な可視化と分析からの後続アクションへの接続を得意とする Looker など、Google Cloud にはデータの上流から下流までを扱うことができるサービスが揃っています。 BigQuery に格納したデータは、そのまま AI/ML（人工知能/機械学習）の活用に繋げることができます。SQL で機械学習モデルのトレーニングや推論が可能な BigQuery ML や、 Vertex AI 、 Colab Enterprise など、Google Cloud にデータが存在しさえすれば、一連のパイプラインがシームレスに繋がります。 そして、これらを利用するための ID は Google Workspace で統合管理されています。クラウド上で別途、アカウント（ID）を管理する必要はありません。 このような優れた Google Cloud のエコシステムを利用することで得られるビジネス上のメリットは、クラウドへのデータベース移行の初期コストを遥かに上回るものになります。 メリット3. 生成 AI によるデータベース運用の自動化 Google が開発したマルチモーダル生成 AI モデル「Gemini」を利用した、データベースの開発・管理ツールである Gemini in Database により、開発・運用コストを低減できます。 参考: Gemini in Databases overview | Gemini for Google Cloud Gemini in Database は、2024年4月にラスベガスで開催された Google Cloud Next ‘24 で発表されました。記事を執筆した2024年5月時点で、以下の機能が発表されています。 自然言語で SQL コードを作成・要約（Database Studio） データベースの安全性を向上（Database Center） パフォーマンスの調査・改善（Query Insights） セキュリティ強化 データベースの移行支援 以下の記事で、「1. 自然言語で SQL コードを作成・要約」を実際に行ってみた流れを紹介していますので、ご参照ください。 blog.g-gen.co.jp 移行方法 本記事ではオンプレミス（あるいは他クラウド）のデータベースを Google Cloud に移行する方法を3つ、ご紹介します。 1. Database Migration Service（DMS） 2. レプリケーション 3. ダンプファイル メリットとデメリットは、以下の表のとおりです。 手法名 メリット デメリット 1. DMS ダウンタイムなし 事前調査と準備が必要 2. レプリケーション ダウンタイムなし 事前調査と準備が必要 3. ダンプファイル 安全で確実 ダウンタイムが発生 1. Database Migration Service（DMS） Data Migaration Service（DMS） Database Migration Service （DMS）はオンプレミスや他のクラウドにあるデータベースから、Google Cloud の Cloud SQL や AlloyDB for PostgreSQL にデータを移行するためのサービスです。Amazon Web Service（AWS）にも同名の類似サービスがあります。 参考 : Overview of Database Migration Service DMS は 連続的なデータ同期 により移行を実現します。そのため ダウンタイムを設けることなく 、移行の最中にも移行元データベースを稼働できることがメリットです。 安全にデータ同期を実現するには 安定的なネットワーク帯域 が必要ですし、移行元データベースの リソースもある程度消費 します。さらに、DMS の利用には 確実な事前準備と事前検証 が必要な点がデメリットであると言えます。 DMS では、Oracle Database から Cloud SQL for PostgreSQL や AlloyDB for PostgreSQL への異種データベース間移行もサポートされていますが、特に入念な準備とテストが必要です。また SQL の方言が異なるため、アプリケーション側の修正も必要になります。このような異種間移行の場合に、生成 AI モデル Gemini による支援を受けることもできます（2024年5月現在、Private Preview） Google Cloud Next ‘24 の Keynote での発表では、Oracle Database から AlloyDB for PostgreSQL へ移行する際に必要となる、ストアドプロシージャの構文の変換を Gemini がサポートする様子などがデモンストレーションされました。 画像は Google Cloud 公式ブログ より引用 2. レプリケーション レプリケーション (画像は 公式ドキュメント より引用) レプリケーション とは、ここではデータベースエンジンに備え付けの機能を使い、データの内容を継続的に複製することを指しています。MySQL、PostgreSQL、Microsoft SQL Server のいずれもネイティブなレプリケーション機能を持っていますが、Cloud SQL でサポートされているのは MySQL と PostgreSQL のみです。 参考 : 外部サーバーからのレプリケーションについて - MySQL 参考 : 外部サーバーからのレプリケーションについて - PostgreSQL メリットとデメリットは、DMS を使う場合と同様です。データを継続的にレプリケーションするため ダウンタイムを抑える ことができるメリットがある一方で、移行元・先データベースでの 事前作業 が必要だったり、 安定したネットワーク帯域 が必須です。 3. ダンプファイルを利用 ダンプファイルを用いたデータ移行 データベースの中身をダンプファイルとしてエクスポート（出力）し、ファイルを Google Cloud の Cloud Storage へアップロードしてから、Cloud SQL 等へインポート（取り込み）することで移行が実現できます。 Cloud SQL でサポートされている MySQL、PostgreSQL、Microsoft SQL Server のいずれも、 Cloud Storage 上のダンプファイルのインポート が可能です。また、AlloyDB for PostgreSQL でも、 pg_dump ツールで作成された PostgreSQL のダンプファイルをインポートできます。 参考 : SQL ダンプファイルを使用したエクスポートとインポート - MySQL 参考 : SQL ダンプファイルを使用したエクスポートとインポート - PostgreSQL 参考 : SQL ダンプファイルを使用したエクスポートとインポート - SQL Server 参考 : Import a DMP file - AlloyDB for PostgreSQL この手法のメリットは、手順が シンプル であること、また 確実 な（原則的に差分なく）データの移行ができることです。 一方のデメリットは、移行元データベースからダンプファイルをエクスポートした時点から、移行先の Cloud SQL が本番稼働するまでデータベースの更新を止める必要があり、 ダウンタイム が発生することです。ダンプファイルはエクスポートを実行した時点のデータの内容を保持していますので、その後に更新された内容は移行先に反映されないためです。後述の手順の 1. から 6. までの数時間程度（データ量により日単位）がダウンタイムとなり得ます。 おおまかな移行手順は以下のようになります。 アプリケーションを停止（移行元データベースの更新を停止） 移行元データベースからダンプファイルをエクスポート ダンプファイルを Cloud Storage にアップロード 移行先データベースにダンプファイルをインポート アプリケーションから移行先データベースへ参照先を変更 アプリケーションを再開 奥田 梨紗 (記事一覧) クラウドソリューション部クラウドデベロッパー課 前職はベトナムのIT企業。 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。日々修行中です！

G-gen の杉村です。2024年5月のイチオシ Google Cloud アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに AppSheet の Organization（組織）機能が使えるように BigQuery で Managed disaster recovery が公開（Preview） Cloud IAP で Workforce Identity を使った認証が可能に（Preview） Google Workspace で二段階認証を設定する際に電話番号が不要に Google スプレッドシートで「テーブル」が使えるように IAM の PAM（Privileged Access Manager）が Preview 公開 Gemini API で Google 検索によるグラウンディングが GA 生成 AI API 関係で複数のアップデート（Google I/O に伴い） Managed private network でS3 -> Cloud Storageの転送コストを大幅減 BigQuery の Search Index で INT64 型と TIMESTAMP 型がサポート Google Meet でハウリングを防止する Adaptive audio 機能 BigQuery から AlloyDB への Federated query が可能に（Preview） Google Chat スペースにEメールを送れるように BigQuery ML の ML.GENERATE_TEXT() で Google 検索グラウンディング Gemini 1.5 Pro/Flash が Vertex AI 上で GA Connected Sheetsでデータ抽出制限が50,000行から500,000行に BigQuery のテーブルあたりパーティション数制限が 4,000 から 10,000 に はじめに 月ごとの Google Cloud アップデートのうち、特にイチオシなものをまとめています。 ある程度の事前知識が必要な記載となっています。サービスごとの前提知識は、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp またリンク先の公式ガイドは英語版にしないと最新情報が反映されていない場合がありますためご注意ください。 AppSheet の Organization（組織）機能が使えるように Introducing AppSheet Organizations (2024-05-02) Google Cloud Next '24 で発表された AppSheet の Organization（組織）機能が使えるように。 Google Workspace 利用中かつ AppSheet Enterprise ライセンスであれば、営業担当者に連絡することで有効化できる。 BigQuery で Managed disaster recovery が公開（Preview） Managed disaster recovery (2024-05-06) BigQuery で Managed disaster recovery が Preview 公開。 複数リージョン間でデータをレプリケーションしたり、スロット予約とクエリをフェイルオーバーできる。Enterprise Plus エディションのみで使用可能。Google Cloud Next '24 で発表されていた。 Cloud IAP で Workforce Identity を使った認証が可能に（Preview） Configure IAP with Workforce Identity Federation (2024-05-06) Cloud Identity-Aware Proxy（IAP）で Workforce Identity を使った認証が可能に（Preview）。 Okta や Entra ID（Azure AD）などの外部 IdP から、OIDC や SAML 2.0 などで IAP の認証ができるようになった。Cloud Run などの独自アプリへの認証が容易に実装できる。 Google Workspace で二段階認証を設定する際に電話番号が不要に A simplified experience for Workspace users to add 2-Step Verification (2SV) methods (2024-05-06) Google Workspace で二段階認証を設定する際に電話番号が不要に。 従来は Google Authenticator 等の OTP アプリの登録の前に、必ず電話番号の登録が必要だったが、今後は最初から OTP アプリの登録が可能になった。 Google スプレッドシートで「テーブル」が使えるように New ways to quickly format and organize data with tables in Google Sheets (2024-05-08) Google スプレッドシートで「テーブル」が使えるように。Excel のテーブル化機能にもあるような機能に加え、列の型を指定したり、GROUP BY が可能。 IAM の PAM（Privileged Access Manager）が Preview 公開 Privileged Access Manager overview (2024-05-14) Google Cloud で、IAM の PAM（Privileged Access Manager）が Preview 公開。 承認者による承認を通ると、時限付きの IAM ロール付与ができる。つまり、時限付きの特権管理ができるようになる仕組み。Google Cloud Next '24 で発表されていた機能。以下の記事も参照。 blog.g-gen.co.jp Gemini API で Google 検索によるグラウンディングが GA Write queries with Gemini assistance (2024-05-14) Gemini API で Google 検索によるグラウンディングが GA。 Webサイトから情報を検索してきて根拠づけし、テキストを生成してくれる。2024年5月の発表時点でサポートされる言語は以下の通り。 English (en) Spanish (es) Japanese (ja) 生成 AI API 関係で複数のアップデート（Google I/O に伴い） Vertex AI release notes - May 14, 2024 (2024-05-14) Google I/O の開催に伴い、Vertex AI 経由の Gemini 等基盤モデルにおいて、以下のアップデート Gemini 1.5 Flash (gemini-1.5-flash-preview-0514) が使えるように（Preview => 2024-05-24 に GA） Gemini バッチ推論（非同期ジョブ）（Preview） Gemmaのライトウェイト版「PaliGemma」 新しいエンべディング用のモデル「text-embedding-004」と「text-multilingual-embedding-002」がGA Managed private network でS3 -> Cloud Storageの転送コストを大幅減 Transfer from Amazon S3 to Cloud Storage (2024-05-17) Storage Transfer Service を使って Amazon S3 から Cloud Storage にデータを転送する際、Managed private network オプションが使えるように。 AWS 側の Egress コストが発生しなくなり、Google 側で $0.03 /GB が発生。大幅なコスト減が可能。転送コストは以下の通り（2024年5月現在）。 AWS 側の Egress コスト 最初の10TB （バージニア北部） : 0.09USDGB 最初の10TB （東京） : 0.114USD/GB Managed private network オプション $0.03 /GB BigQuery の Search Index で INT64 型と TIMESTAMP 型がサポート CREATE SEARCH INDEX statement (2024-05-20) BigQuery の Search Index で、INT64 型と TIMESTAMP 型がサポートされるように（Preview）。 これまでは STRING や JSON に対応していた。Search Index は、BigQuery テーブルのカラムにインデックスを張り、検索を高速化する機能。以下の記事も参照。 blog.g-gen.co.jp Google Meet でハウリングを防止する Adaptive audio 機能 Introducing adaptive audio in Google Meet: creating ad-hoc meeting spaces with multiple laptops (2024-05-22) Google Meet のビデオ会議で、自動的に音声を調整し、ハウリングを防止する Adaptive audio 機能がリリース。 ハイブリッドワーク時代に、会議室が少ないために、近い距離で複数の PC から Meet 会議に入ることを考慮した機能。 Gemini for Google Workspace と AI Meetings and Messaging アドオンが必要。 BigQuery から AlloyDB への Federated query が可能に（Preview） Introduction to federated queries (2024-05-22) BigQuery から AlloyDB for PostgreSQL への Federated query が可能に（Preview） 分析用データベースである BigQuery から、業務用データベースである AlloyDB に直接クエリをかけられるようになる。分析のためにわざわざデータを移送・複製する必要がなくなる。 ただしリソース消費に注意（AlloyDB 側の CPU、メモリ、ストレージ IO）。 BigQuery からの Federated query 対応データベースは以下のとおり。 Cloud SQL Spanner SAP Datasphere（Preview） AlloyDB for PostgreSQL（Preview） Google Chat スペースにEメールを送れるように Send emails to spaces in Google Chat (2024-05-22) スペースにEメールアドレスを生成して、そこにメールを送信すると、スペースにメール内容が表示される。Slack にも類似機能あり。 BigQuery ML の ML.GENERATE_TEXT() で Google 検索グラウンディング The ML.GENERATE_TEXT function (2024-05-23) BigQuery ML で ML.GENERATE_TEXT() を使って Gemini を使う際に Google 検索によるグラウンディングが使えるように。 ground_with_google_search 引数を付与することで実行可能。 Gemini 1.5 Pro/Flash が Vertex AI 上で GA Vertex Generative AI release notes - May 24, 2024 (2024-05-24) Gemini 1.5 Pro / Flash が Vertex AI 上で Preview => GA。 Gemini 1.5 Pro 100万トークンのロングコンテキスト Gemini 1.5 Flash 100万トークンのロングコンテキストは同様で、レスポンスがクイックで軽量 Connected Sheetsでデータ抽出制限が50,000行から500,000行に Google Workspace Updates Weekly Recap - May 24, 2024 (2024-05-24) Connected Sheets（GoogleスプレッドシートからBigQueryデータを取得・利用可能な機能）で「データの抽出」機能の制限が 50,000行から、10倍の 500,000行に。 Connected Sheets では、スプレッドシートを使って BigQuery のデータを取得。スプレッドシートの操作感で、データを可視化したり、集計できる。以下の記事も参照。 blog.g-gen.co.jp BigQuery のテーブルあたりパーティション数制限が 4,000 から 10,000 に BigQuery release notes - May 29, 2024 (2024-05-29) BigQuery のテーブルあたりの最大パーティション数制限が 4,000 から 10,000 に増量。 日次で切られるパーティションなら約11年→約27年に。以下は、時間ベースの場合の10,000パーティション計算例。 10,000 時間 = 約416日 = 約13ヶ月間 10,000日 = 約322ヶ月 = 約27年 10,000か月 = 約833年 以下の記事もご参照ください。 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 からインターネットアクセスを行う際に使用されるパブリック IP アドレスを固定する方法を解説します。 Cloud Run から Cloud NAT を使用してインターネット接続を行う はじめに サーバーレス VPC アクセスを使用する方法 Direct VPC Egress を使用する方法（当記事で解説） 手順 シェル変数の設定 VPC とサブネットの作成 Cloud NAT の作成 Cloud Run サービスのデプロイ 使用するコード ソースコードから Cloud Run をデプロイする 動作確認 Cloud Run から Cloud NAT を使用してインターネット接続を行う はじめに 当記事の内容は Cloud Run service、Cloud Run jobs の両方を対象としているため、それぞれを区別せずに「Cloud Run」と記載しています。 なお、当記事で解説する手順では Cloud Run services を使用しています。 サーバーレス VPC アクセスを使用する方法 Cloud Run では、コンテナインスタンスを起動する際にパブリック IP アドレスが動的に割り当てられ、インターネットにアクセスする場合はこの動的 IP アドレスが使用されるようになっています。 Cloud Run でインターネットアクセスに使用するパブリック IP アドレスを固定したい場合、静的 IP アドレスを紐付けた Cloud NAT を経由してインターネットアクセスを行うように設定する必要があります。 従来の方法では、Cloud NAT が存在する VPC に サーバーレス VPC アクセス を構成し、サーバーレス VPC アクセスコネクタを使用して Cloud Run から VPC に接続する必要がありました。 IPアドレスの固定にサーバーレスVPCアクセスを使用する場合の構成 サーバーレス VPC アクセスを使用する方法については、以下の記事で詳細な手順を解説しています。 blog.g-gen.co.jp Direct VPC Egress を使用する方法（当記事で解説） 2024年3月に Direct VPC Egress で Cloud NAT が使用できるようになったことで、サーバーレス VPC アクセスを構成することなく、Cloud Run が使用するパブリック IP アドレスを固定できるようになりました。 Direct VPC Egress では、サーバーレス VPC アクセスとは異なり、常時起動のコネクタインスタンスを経由する必要がないため、より安価かつ高速に VPC に接続することができます。 IPアドレスの固定にDirect VPC Egressを使用する場合の構成 Direct VPC Egress の解説、およびサーバーレス VPC アクセスとの詳細な比較については、以下の記事をご一読ください。 blog.g-gen.co.jp 手順 シェル変数の設定 当記事では gcloud コマンドを使用して各種リソースを作成していきます。 コマンド内で何度か使用する値は、以下のようにシェル変数として設定しておきます。 PROJECT 変数の値にはリソースを作成するプロジェクトを、 LOCATION 変数の値にはリージョンを設定してください。残りの変数は各種リソースの名前を指定する際に使用します。 PROJECT =myproject LOCATION =asia-northeast1 NETWORK =vpc-direct-vpc-egress SUBNET =subnet-direct-vpc-egress ROUTER =router-direct-vpc-egress ADDRESS =address-direct-vpc-egress NAT =nat-direct-vpc-egress VPC とサブネットの作成 Cloud Run から接続する Cloud NAT を配置するための VPC を作成します。 # VPC の作成 $ gcloud compute networks create ${NETWORK} \ --project= ${PROJECT} \ --subnet-mode=custom 作成した VPC にサブネットを作成します。Cloud Run から Direct VPC Egress を使用して VPC に接続する際、このサブネットに設定された IP アドレス範囲の IP アドレスが使用されます。 # サブネットの作成 $ gcloud compute networks subnets create ${SUBNET} \ --project= ${PROJECT} \ --network= ${NETWORK} \ --range=192.168.101.0/24 \ --region= ${LOCATION} サブネットのアドレス範囲は、最低でも /28 の CIDR 範囲で指定する必要があります。 Cloud Run がスケールアウトすると、ここで指定したアドレス範囲の IP アドレスが消費されます。使用できる IP アドレスが枯渇していると Cloud Run のスケールアウトが阻害されてしまうため、サブネットには十分なアドレス数を確保するようにアドレス範囲を設定する必要があります。 アドレス数の目安は、Cloud Run に設定された 最大コンテナインスタンス数の4倍 となっています。また、Cloud Run jobs を使用する場合は少なくとも1,024個の IP アドレスを確保しておく必要があります。 参考： Cloud RunのDirect VPC Egressを解説 - 制限事項 Cloud NAT の作成 作成した VPC に Cloud NAT を作成していきます。Cloud NAT は VPC 内の Cloud Router に関連付ける必要があるため、Cloud Router を先に作成しています。 # Cloud Router の作成 $ gcloud compute routers create ${ROUTER} \ --project= ${PROJECT} \ --network= ${NETWORK} \ --region= ${LOCATION} # Cloud NAT 用のパブリック IP アドレスを予約 $ gcloud compute addresses create ${ADDRESS} \ --region= ${LOCATION} # Cloud NAT の作成 $ gcloud compute routers nats create ${NAT} \ --router= ${ROUTER} \ --region= ${LOCATION} \ --nat-all-subnet-ip-ranges \ --nat-external-ip-pool= ${ADDRESS} Cloud Run サービスのデプロイ 使用するコード 当記事では Cloud Run のクイックスタート のサンプルコードをベースに、Cloud Run のコンテナインスタンスがインターネットアクセスに使用している IP アドレスをブラウザ上に表示するだけの Web アプリケーションを実装します。 インターネットアクセスに使用している IP アドレスは「 https://inet-ip.info/ip 」から取得します。 // main.go package main import ( "fmt" "log" "net/http" "os" ) func main() { log.Print( "starting server..." ) http.HandleFunc( "/" , ipCheck) // Determine port for HTTP service. port := os.Getenv( "PORT" ) if port == "" { port = "8080" } // Start HTTP server. log.Printf( "listening on port %s" , port) if err := http.ListenAndServe( ":" +port, nil ); err != nil { log.Fatal(err) } } // インターネットアクセスに使用される IP アドレスを確認する func ipCheck(w http.ResponseWriter, r *http.Request) { // https://inet-ip.info/ip にアクセスし、自身の IP アドレスを取得する resp, err := http.Get( "https://inet-ip.info/ip" ) if err != nil { log.Fatal(err) } defer resp.Body.Close() // レスポンスボディを読み込む buf := make ([] byte , 32 ) n, err := resp.Body.Read(buf) if err != nil { log.Fatal(err) } // ブラウザに IP アドレスを表示する fmt.Fprintf(w, string (buf[:n])) } ソースコードから Cloud Run をデプロイする main.go と go.mod ファイルがあるディレクトリで以下のコマンドを実行し、Cloud Run サービスをデプロイします。 # Cloud Run サービスのデプロイ $ gcloud run deploy ipcheck \ --source . \ --project= ${PROJECT} \ --region= ${LOCATION} \ --network= ${NETWORK} \ --subnet= ${SUBNET} \ --vpc-egress=all-traffic \ --allow-unauthenticated このデプロイコマンドでは、Cloud Run で Direct VPC Egress を使用するために、以下のフラグを使用しています。 フラグ 設定する値 説明 --region VPCの名前 Direct VPC Egress で接続する VPC の名前を指定する。 --subnet サブネットの名前 Direct VPC Egress で接続する VPC のサブネットの名前を指定する。 --vpc-egress all-trafic すべての Egress トラフィックを VPC で送信する場合 all-trafic を指定する。プライベート IP アドレスへの通信のみ VPC 経由にしたい場合は private-ranges-only を指定する。（ 参考 ） Cloud Run からのインターネットへのアクセスを Cloud NAT 経由にする場合、 --vpc-egress フラグの値は必ず all-trafic を指定します。 ここで private-ranges-only を指定した場合、インターネットへのアクセスには Cloud Run インスタンスの動的なパブリック IP アドレスが使用されてしまいます。 なお、コンソールから Direct VPC Egress を設定する場合は、以下のスクリーンショットのように設定します。 Cloud Runのコンソール上でDirect VPC Egressを設定する場合 動作確認 gcloud コマンドによる Cloud Run サービスのデプロイが完了すると、標準出力の Service URL: の行にサービスの URL が表示されています。 Building using Buildpacks and deploying container to Cloud Run service [ ipcheck ] in project [ myproject ] region [ asia-northeast1 ] ✓ Building and deploying new service... Done. ✓ Uploading sources... ✓ Building Container... Logs are available at [ https://console.cloud.google.com/cloud-build/builds/2aa331ab-11aa-46bd-976b-xxxxxxxxxxxx?project = xxxxxxxxxxxx ] . ✓ Creating Revision... ✓ Routing traffic... ✓ Setting IAM Policy... Done. Service [ ipcheck ] revision [ ipcheck-00001-k2j ] has been deployed and is serving 100 percent of traffic. Service URL: https://ipcheck-ai4xxxxxxx-an.a.run.app ブラウザでサービスの URL にアクセスすると、Cloud Run のコンテナインスタンスが起動し、コンテナインスタンスがインターネットアクセスに使用した IP アドレスが表示されます。 Cloud Runがインターネットアクセスに使用したIPアドレスが表示される ブラウザに表示された IP アドレスが、Cloud NAT に設定された静的パブリック IP アドレスと一致するかを確認します。 以下のコマンドを使用するか、コンソール上で Cloud NAT の IP アドレスを確認します。 # Cloud NAT に紐づけた静的パブリック IP アドレスを確認 $ gcloud compute addresses describe ${ADDRESS} | head -n 1 Cloud NAT に紐づけた静的パブリックIPアドレスを確認（コンソール） 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の荒井です。当記事では Google Workspace のアプリケーションのみ使用してお問い合わせフォームを作成する方法をご紹介します。 はじめに ご紹介すること 記事の構成 設定作業概要 Google グループ作成 Google グループ設定 グループアドレスを送信元とする設定 設定1 : Google グループ作成 設定2 : Google グループ設定 設定3 : グループアドレスを送信元とする設定 次の記事 はじめに ご紹介すること 当記事では問い合わせ対応システムで使用する Google グループ の作成や設定方法をご紹介します。 Google グループを使うことで、複数人で1つのメールアドレス（代表メールアドレスや問い合わせ用メールアドレスなど）を運用することができます。 記事の構成 問い合わせ対応システムの開発方法は、以下の通り、連載記事としてご紹介します。記事を順に確認することで、問い合わせ対応システムが完成します。 No タイトルとリンク 1 Google Workspace で問い合わせ対応システムを作成する方法 #1 (システム概要) 2 ※ 当記事 Google Workspace で問い合わせ対応システムを作成する方法 #2 (Google グループ設定) 3 Google Workspace で問い合わせ対応システムを作成する方法 #3 (Google フォーム設定) 4 Google Workspace で問い合わせ対応システムを作成する方法 #4 (Google App Script 設定) 5 Google Workspace で問い合わせ対応システムを作成する方法 #5 (業務フロー解説) 6 ※ 準備中 Google Workspace で問い合わせ対応システムを作成する方法 #6 (機能拡張案) 設定作業概要 Google グループ作成 Google グループを作成します。 Google グループは、グループアドレスとして機能します。Google グループにメンバーの追加やアクセス設定などを行うことで、チームの全員がメールを受信できるようになります。 Google グループ設定 Google グループで次の機能を有効にし、複数人での運用が円滑にできるようにします。 共同トレイの有効化 ラベル機能の有効化 メールの from アドレスのデフォルトをグループアドレスに設定 グループアドレスを送信元とする設定 今回開発する仕組みでは、問い合わせ対応システム側から送信するメールの「from」がグループアドレスとなるように設定します。from が個人のメールアドレスになってしまうと、次の返信でお客様が個人アドレスにメールを送信してしまうケースも発生し、やりとりをチームで確認することが難しくなってしまうためです。 そのため個人アドレスからメールを送信した場合でも、送信元をグループアドレスとする設定を行います。これにより Google Apps Script（GAS）を使用して個人アドレスからメールを送信する際でも、送信元をグループアドレスとすることが可能です。GAS の設定は #4 の記事で行います。 設定1 : Google グループ作成 管理コンソール にログインし、 グループ設定画面 から「グループを作成」をクリックします。 グループの詳細画面でグループの情報を入力します。 設定項目 設定内容 区分 グループ名 グループの表示名、識別しやすい名称を設定 必須 グループのメールアドレス グループのメールアドレス、お客様がわかりやすいメールアドレスを設定 必須 グループの説明 グループの用途などを入力 任意 グループのオーナー グループのオーナーを設定 任意 ラベル (メーリング) 有効 強制 ラベル (セキュリティ) 無効 (運用に必要であれば有効化) 任意 参考 : 組織内にグループを作成する - Google Workspace 管理者 ヘルプ 参考 : 閲覧、投稿、管理できるユーザーを設定する - Google グループ ヘルプ 参考 : セキュリティ グループでセンシティブ データへのアクセスを制御する - Google Workspace 管理者 ヘルプ アクセスタイプを設定します。 今回は組織外の方からメールを受診できるグループとしたいため「投稿できるユーザー」は必ず 外部 で設定します。 それ以外の項目は任意で設定を行います。 参考 : メンバーとコンテンツを管理する権限を設定する - Google Workspace ラーニング センター セキュリティ設定は、設定を行わなくても問題ありません。 参考 : 動的グループを使用してメンバーを自動的に管理する - Google Workspace 管理者 ヘルプ [完了] ボタンが表示されますが、そのままメンバーの追加画面へ繊維したいため [(グループ名) へのメンバーの追加] をクリックします。（本画面が表示されれば、グループの作成は完了しています） [メンバーを追加] をクリックします。 グループに追加したいメンバー（問い合わせ対応を行うメンバー）を検索し [グループに追加] をクリックします。 参考 : グループ メンバーを追加、管理する - Google Workspace 管理者 ヘルプ 設定2 : Google グループ設定 グループの詳細設定を行います。 グループ設定画面 から、作成したグループの [登録] が「メッセージごとにメール」になっているか確認します。 ※ 「メッセージごとにメール」になっていない場合、新規問い合わせ時にメール通知が発生しない場合があります。 グループ名をクリックして、グループを展開します。 [人脈 > メンバー] の [登録] が「メッセージごとにメール」になっているか確認します。 ※ 「メッセージごとにメール」になっていない場合、新規問い合わせ時にメール通知が発生しない場合があります。 [グループ設定] で以下の設定を行います。 下記記載項目以外は、参考ドキュメントを確認し運用に沿った設定をします。 設定項目 パラメータ 説明 追加の Google グループの機能を有効にする 共同トレイ : 有効 グループ内の会話 (スレッド) に担当者を割り当てられる 共有ラベル このグループで共有ラベルを有効にする : 有効 グループ内の会話 (スレッド) にラベルを付与できる メタデータを管理できるユーザー グループメンバー 共同トレイ機能を使用できるユーザーを設定 グループとして投稿できるユーザー グループメンバー グループアドレスで送信できるユーザーを設定 デフォルトの差出人 グループアドレス グループから送信されるメールアドレス (from) の初期値 参考 : グループの設定を更新する - Google Workspace ラーニング センター グループアドレスにテストメールを送信し、受信したメール（会話・スレッド）で以下のようにユーザーの割当やラベルアイコンが表示されていることを確認します。 設定3 : グループアドレスを送信元とする設定 本設定は、後工程で GAS を実行するユーザー（サポート窓口管理者が推奨）で行います。 基本的には以下のドキュメント内容の手順となります。 参考 : Gmail でグループをメールアドレスとして追加する - Google グループ ヘルプ GAS 実行ユーザーで Gmail にログインし [設定 > すべての設定を表示] をクリックします。 [アカウントとインポート > 他のメールアドレスを追加] をクリックします。 以下の通り設定し、[次のステップ] をクリックします。 設定項目 パラメータ 名前 メール受信者に表示される名称 メール アドレス 今回作成した Google グループのグループアドレス [確認メールの送信] をクリックします。 下記画面が表示されたら、 グループ画面 に遷移し「確認メール」を確認します。 「確認メール」の内容を確認し、許可されたユーザーからのリクエストであれば URL をクリックして許可します。 [確認] をクリックします。 確認完了画面が表示されます。 GAS 実行ユーザーで Gmail にログインし、メールの新規作成画面で差出人を変更できるようになっていれば設定完了です。 次の記事 Google Workspace で問い合わせ対応システムを作成する方法 #3 (Google フォーム設定) 荒井 雄基 (記事一覧) クラウドソリューション部 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。 Google Cloud 認定資格 7冠 現在は Google Workspace を中心に企業の DX 推進をサポート。 最近頑張っていることは、子どもがハマっている戦隊モノの踊りを踊れるようになること。

今回、Gemini 1.5 Pro を活用して、ビジネス心理テストであるストレングスファインダーで自身の強みを分析し、AI によるマネジメントやメンタリングが可能か、試してみました。本記事では、その取り組みの詳細をご紹介します。 ストレングスファインダーとは Strength Mentor Bot の作成 Gemini 1.5 Pro を使った実装 34の資質を JSON 形式で抽出 BigQuery への保存と分析 チームビルディングへの応用 ストレングスファインダーとは まず、ストレングスファインダーについて説明します。 ストレングスファインダーは、個人の強みを特定し、それを活かすための評価ツールです。クリフトンという心理学者によって開発され、現在はギャラップ社が提供しています。 34の資質（強み）を測定し、個人の弱みではなく強みに焦点を当てることで、より良いパフォーマンスと幸福度の向上を目指す思想の元作られています。 34の資質は、行動の原動力となる思考や感情のパターンを表しており、以下のようなものがあります。 アレンジ : 物事を最適な状態に整える 運命思考 : 自分の人生には使命があると信じている 回復志向 : 問題の解決を急がない 活発性 : 新しい活動をすぐに始める 個別化 : 個人の長所や短所をよく観察する 規律性 : 秩序あるルーティーンを作る （全34項目は割愛） これらの資質は生まれつきのものであり、環境によって変化しにくいと考えられています。自分の強みを知ることで、それを伸ばし活かすことができます。 以下が私のレポートになりますが、目標志向、達成欲、自我などが上位に来ており、共感性や社交性、慎重さは下位でした。 トップ5の資質については日本語訳書籍の付録にクーポンコードがついているので、それを使って Web テストを受験し、レポートをダウンロードして確認できます。 34の資質まで知りたくなるので、その際は公式 Web サイトから追加のクーポンを購入することで、すべて見ることができます。 参考 : ストレングス・ファインダー 参考 : さあ、才能(じぶん)に目覚めよう　最新版 ストレングス・ファインダー2.0 Strength Mentor Bot の作成 ストレングスファインダーの結果は非常に興味深いものでしたが、これを実際のマネジメントやメンタリングにどう活かせるのか考えてみました。 自分の強みを理解するだけでなく、部下や同僚の強みを把握し、適切なアドバイスができたら素晴らしいですよね。 そこで私は、自分のストレングスファインダーの結果を理解した上で、メンタリングしてくれる AI ボットを作ってみました。 ユーザーが「私の強みを教えてください。」と問いかけると、私のレポートをもとに、適切な回答を返してくれます。以下はその一例です。 ボットの回答を見ると、私の上位資質である「目標志向」、「戦略性」、「学習欲」を踏まえて、データ分析プロジェクトでその強みを活かすにはどうしたらいいかの示唆を提示してくれています。 Gemini 1.5 Pro を使った実装 このボットの実装には、Gemini 1.5 Pro を使用しました。以下のようなシンプルなコードで実現できます。 # Vertex AI ライブラリをインポート import vertexai from vertexai.generative_models import GenerativeModel, Part # プロジェクトIDを設定 project_id = "your_project_id" vertexai.init(project=project_id, location= "us-central1" ) # 質問のプロンプトを設定 prompt = "神谷の強みを教えてください" # 入力として使用するPDFファイルのパスを指定 file_path = "path_to_your_pdf_file" # PDFファイルをPart objectとして読み込み pdf_file = Part.from_uri(file_path, mime_type= "application/pdf" ) # プロンプトとPDFファイルをリストに格納 contents = [pdf_file, prompt] # 生成モデルのパラメータを設定 generation_config = { "temperature" : 0 , # 生成時の多様性を制御。0に近いほど確定的な出力になる "top_p" : 0.95 , # top-p サンプリングの閾値。高いほど多様な出力になる "top_k" : 40 , # 考慮する最高確率のトークンの数 "candidate_count" : 1 , # 生成する候補の数 "max_output_tokens" : 8192 , # 出力トークンの最大数 } # 使用する生成モデルを指定し、GenerativeModelオブジェクトを作成 model = GenerativeModel( "gemini-1.5-pro-preview-0409" , generation_config=generation_config) # モデルにプロンプトとPDFを渡して応答を生成 response = model.generate_content(contents) # 生成された応答のテキストを出力 print (response.text) Part.from_uri 関数で PDF を読み込み、プロンプトと一緒に contents 配列に入れるだけです。あとはそのまま Gemini 1.5 Pro に渡すだけで、PDF の内容を理解した上で質問に答えてくれます。 以前は Gemini 1.0 を使っており、PDF の分割やチャンクごとのエンベディング抽出、類似ベクトル検索などの前処理が必要でしたが、Gemini 1.5 Pro ではそれらが不要になり、実装が非常にシンプルになりました。これにより、開発者は本質的なタスクに集中できるようになります。 34の資質を JSON 形式で抽出 さらに、Gemini 1.5 Pro を使えば、PDF から34の資質を JSON 形式で簡単に抽出できます。以下のサンプルコードをご覧ください。 import vertexai from vertexai.generative_models import GenerativeModel, Part import json # プロジェクトIDを設定 project_id = "your_project_id" vertexai.init(project=project_id, location= "us-central1" ) # Google Cloud StorageのPDFファイルのパスを指定 file_path = "gs://xxx/Gallup_Analytics_and_Reporting.pdf" # PDFファイルをPart objectとして読み込み pdf_file = Part.from_uri(file_path, mime_type= "application/pdf" ) # 34の資質とユーザー名を抽出するプロンプトを設定 prompt = """ 以下のPDFから34の資質とその順位をJSON形式で抽出してください。 また、ページのヘッダーからユーザ名も抽出してください。 フォーマットは以下の通りです。 [ { "user_name": "ユーザ名", "strength_item": "資質名", "rank": 順位 }, ... ] """ # プロンプトとPDFファイルをリストに格納 contents = [pdf_file, prompt] # 生成モデルのパラメータを設定（JSON形式のレスポンスを指定） generation_config = { "temperature" : 0 , "top_p" : 0.95 , "top_k" : 40 , "candidate_count" : 1 , "max_output_tokens" : 8192 , "response_mime_type" : "application/json" # レスポンスのMIMEタイプをJSONに設定 } # 使用する生成モデルを指定し、GenerativeModelオブジェクトを作成 model = GenerativeModel( "gemini-1.5-pro-preview-0409" , generation_config=generation_config) # モデルにプロンプトとPDFを渡してJSON形式の応答を生成 response = model.generate_content(contents) # 生成されたJSON文字列をパースして、Pythonのデータ構造に変換 strengths = json.loads(response.text) # 抽出された資質情報を整形してコンソールに出力 print (json.dumps(strengths, indent= 2 , ensure_ascii= False )) プロンプトで34の資質とその順位を JSON 形式で抽出するように指示し、なおかつリクエストパラメータで "response_mime_type": "application/json" を指定します。 レスポンスとして生成されたテキストを json.loads でパースすることで、簡単に構造化されたデータを取得できます。 出力結果は以下のようになりました。 [ { "user_name" : "乗治 神谷" , "strength_item" : "目標志向" , "rank" : 1 }, { "user_name" : "乗治 神谷" , "strength_item" : "達成欲" , "rank" : 2 }, { "user_name" : "乗治 神谷" , "strength_item" : "自我" , "rank" : 3 }, -- 省略 -- { "user_name" : "乗治 神谷" , "strength_item" : "収集心" , "rank" : 32 }, { "user_name" : "乗治 神谷" , "strength_item" : "回復志向" , "rank" : 33 }, { "user_name" : "乗治 神谷" , "strength_item" : "共感性" , "rank" : 34 } ] 1位から34位まですべての資質が正確に抽出できています。 BigQuery への保存と分析 抽出した34の資質を BigQuery や Google Sheet に保存することで、メンバーの類似性や組織的傾向を定量的に分析したり、可視化することができます。以下は、BigQuery にデータを保存するサンプルコードです。 from google.cloud import bigquery # BigQueryクライアントを作成 client = bigquery.Client(project= "your_project_id" ) # テーブルIDを指定 table_id = "gemini_ocr_sample.strengths" # BigQueryのスキーマを定義 job_config = bigquery.LoadJobConfig( schema=[ bigquery.SchemaField( "user_name" , "STRING" ), # ユーザー名のカラム（文字列型） bigquery.SchemaField( "strength_item" , "STRING" ), # 資質名のカラム（文字列型） bigquery.SchemaField( "rank" , "INTEGER" ), # 順位のカラム（整数型） ], write_disposition= "WRITE_TRUNCATE" , # テーブルが存在する場合は上書きする ) # JSONデータをBigQueryにロード job = client.load_table_from_json(strengths, table_id, job_config=job_config) job.result() # ロードジョブが完了するまで待機 # ロードされた行数を出力 print (f "Loaded {len(strengths)} rows to {table_id}" ) BigQuery に保存されたデータを使って、以下のような分析や可視化が可能です。 組織全体での各資質の平均順位を算出し、組織の強みや弱みを特定する 上位の資質は組織の強みと言えるので、それを全面に打ち出していく 下位の資質は組織の弱みと言えるので、補強策を検討する 部署ごとの資質の分布を比較し、部署間の特性の違いを明らかにする 営業部門は社交性や適応性が高い、開発部門は分析思考や着想が高い、など 各部署の特性を活かした役割分担や、不足している資質を補うための人員配置を検討できる メンバー間の資質の類似度を計算し、類似するメンバーをクラスタリングする 類似度の高いメンバー同士は価値観や行動特性が似ているので、相性が良いチームを作れる 逆に類似度の低いメンバー同士は多様な視点を持ち寄れるので、イノベーティブなチームを作れる このように、構造化されたデータを活用することで、個人の強みの理解だけでなく、組織全体の特性や傾向を把握することができます。 実際に、弊社 G-gen メンバー7人の平均的な資質を可視化したグラフからは、最上志向、達成欲、学習欲などが上位に来ており、ベンチャー企業らしい傾向が見て取れました。 G-gen メンバーの上位資質 以下のようにユーザ別の資質をヒートマップ化することで、より詳細な分析をすることができます。 ユーザ別各資質のヒートマップ チームビルディングへの応用 Gemini 1.5 Pro の強力な機能の一つは、複数の PDF を同時に処理できることです。これを利用して、複数のメンバーのストレングスファインダーの結果を分析し、チームビルディングに活かすことができます。 例えば、以下のようなプロンプトを与えることで、2人のメンバーの資質を比較し、潜在的な対立点を予測することができます。 import vertexai from vertexai.generative_models import GenerativeModel, Part import json # プロジェクトIDを設定 project_id = "your_project_id" vertexai.init(project=project_id, location= "us-central1" ) # 2人のユーザーの資質を比較し、衝突する可能性があるケースを尋ねるプロンプトを設定 prompt = "「大津 和幸」さん（最初のPDF）と「宣之 渡邉」さん（2つめのPDF）の資質を比較し、彼らがぶつかるとしたらどういったケースが有るか教えてください。上位5資質だけの比較で良いです" # 1人目のユーザーのPDFファイルをPart objectとして読み込み pdf_file_1 = Part.from_uri( "gs://ohtsu.pdf" , mime_type= "application/pdf" ) # 2人目のユーザーのPDFファイルをPart objectとして読み込み pdf_file_2 = Part.from_uri( "gs://norry.pdf" , mime_type= "application/pdf" ) # プロンプトと2つのPDFファイルをリストに格納 contents = [prompt, pdf_file_1, pdf_file_2] # 生成モデルのパラメータを設定 generation_config = { "temperature" : 0.2 , # 生成時の多様性を制御。0.2は比較的確定的な出力を生成 "top_p" : 0.95 , # top-p サンプリングの閾値。高いほど多様な出力になる "top_k" : 20 , # 考慮する最高確率のトークンの数 "candidate_count" : 1 , # 生成する候補の数 "max_output_tokens" : 1024 , # 出力トークンの最大数 "response_mime_type" : "text/plain" # レスポンスのMIMEタイプをプレーンテキストに設定 } # 使用する生成モデルを指定し、GenerativeModelオブジェクトを作成 model = GenerativeModel( "gemini-1.5-pro-preview-0409" , generation_config=generation_config) # モデルにプロンプトと2つのPDFを渡して応答を生成 response = model.generate_content(contents) # 生成された応答のテキストを出力 print (response.text) ここで注目すべきは、 contents 配列に複数の PDF とプロンプトを一緒に詰め込んでいる点です。Gemini 1.5 Pro の API は、PDF やテキスト、音声、動画などの異なるデータフォーマットを、マルチモーダルなオブジェクトとして同じ配列で扱うことができます。 これにより、開発者は様々なデータ型を気にすることなく、シームレスに処理を行うことができます。 出力結果は以下の通りです。 ## 大津さんと宣之さんの資質比較と衝突の可能性 大津さんと宣之さんの上位5資質を比較し、衝突の可能性について考察します。 **大津さんの上位5資質** 1. **社交性:** 初対面の人とも打ち解けやすく、人脈作りが得意。 2. **アレンジ:** 物事を整理・組織化し、柔軟性も備えている。 3. **学習欲:** 常に学び向上することに意欲的で、新しい知識やスキルの習得を楽しむ。 4. **コミュニケーション:** 自分の考えを言葉で表現することが得意で、プレゼンテーション能力も高い。 5. **包含:** 他者を受け入れ、輪から外れている人を気遣う。 **宣之さんの上位5資質** 1. **最上志向:** 優れたものを最高レベルに引き上げようと努力し、品質を重視する。 2. **着想:** 独創的で、新しいアイデアや概念を生み出すことを楽しむ。 3. **個別化:** 個人のユニークな資質に関心を持ち、それぞれに合った対応をする。 4. **適応性:** 状況に合わせて柔軟に対応し、変化を楽しむ。 5. **学習欲:** 大津さんと同じく、常に学び向上することに意欲的で、新しい知識やスキルの習得を楽しむ。 **衝突の可能性** 大津さんと宣之さんは、どちらも「学習欲」が高い点は共通していますが、他の資質には違いが見られます。 * **スピード感の違い:** 大津さんは「アレンジ」の資質から、効率性やスピード感を重視する可能性があります。一方、宣之さんは「最上志向」の資質から、品質を重視し、時間をかけて完璧を目指そうとする傾向があります。このため、プロジェクトの進め方や納期に関して意見が対立する可能性があります。 * **計画性 vs 柔軟性:** 大津さんは「アレンジ」の資質から、計画的に物事を進めることを好む可能性があります。一方、宣之さんは「適応性」の資質から、状況に合わせて柔軟に対応することを好みます。このため、計画の変更や予期せぬ事態への対応について、意見が合わない可能性があります。 * **全体 vs 個人:** 大津さんは「社交性」や「包含」の資質から、チーム全体を重視し、調和を保とうとする傾向があります。一方、宣之さんは「個別化」の資質から、個人の能力や個性に注目し、それぞれに合った対応をしようとします。このため、チーム運営や個人の評価について、意見が分かれる可能性があります。 * **アイデアの実現性:** 大津さんは「分析思考」の資質は上位ではないため、宣之さんの「着想」から生まれた斬新なアイデアに対し、実現可能性や論理的な裏付けを求める可能性があります。宣之さんは、実現可能性よりもアイデアの面白さや独創性を重視するため、衝突が起こる可能性があります。 **衝突を避けるためには** * **お互いの資質を理解し尊重する:** お互いの強みと弱みを理解し、尊重することが重要です。 * **コミュニケーションを密にする:** 意見が異なる場合は、しっかりと話し合い、お互いの考えを理解するように努めることが重要です。 * **役割分担を明確にする:** それぞれの資質を活かせるような役割分担をすることで、衝突を避け、お互いの強みを活かすことができます。 大津さんと宣之さんは、異なる資質を持つからこそ、お互いに補完し合い、より良い結果を生み出す可能性を秘めています。お互いの違いを理解し、尊重することで、衝突を避け、協力して目標達成を目指せるでしょう。 異なるユーザ（PDF）それぞれの上位資質と順位を正確に抽出できており、なおかつユーザ同士の共通点や相違点をもとにして、回答が生成されていました。 このようにして得られた知見を活用することで、以下のようなチームビルディングが可能になります。 メンバーの資質の組み合わせを考慮したチーム編成 類似した資質を持つメンバーでチームを組むことで、得意分野に特化した高い生産性を発揮できる 異なる資質を持つメンバーでチームを組むことで、多様な視点からの議論を活発化できる メンバー間の対立を未然に防ぐためのコミュニケーション改善 お互いの強みや特性を理解し合うことで、相手の言動の真意を汲み取れるようになる 対立が起きそうな場面では、第三者の視点から調整役を務められる 個人の強みを活かすためのタスクアサイン 各メンバーの強みに合ったタスクを割り当てることで、モチベーションとパフォーマンスを最大化できる 苦手な分野のタスクは、得意なメンバーにサポートしてもらうことで、互いの成長にもつながる このように、ストレングスファインダーの結果を Gemini 1.5 Pro で分析することで、個人の強みを活かしつつ、チームとしての総合力を高めることができます。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-gen の杉村です。Google Cloud と GCP（Google Cloud Platform）、どちらの呼び名が正しいの？という疑問をよくお聞きします。結論からいうと、正式名称は Google Cloud です。 正式名称は「Google Cloud」 GCP と呼んではいけないの？ Google Cloud と Google 正式名称は「Google Cloud」 Google が提供するクラウドプラットフォームである Google Cloud 。インターネット上には「Google Cloud」「Google Cloud Platform」「GCP」と複数の呼び名が見られます。どの名称で呼ぶべきなのでしょうか。 現在では、正式名称は「 Google Cloud 」です。 「Google Cloud Platform」およびその略称である「GCP」は旧称であり、2022年6月に「Google Cloud」に名称変更されています。以下の公式ブログで、その旨が記載されています。 参考 : Google Cloud の新しくなったホームページのご紹介 お客様のエクスペリエンスをシンプルにし、プロダクト間の一貫性を保つために、Google Cloud Platform は Google Cloud という名称になりました。さらに、モバイルアプリ名（旧 Cloud Console アプリ）は、Google Cloud アプリという名称に変更されました。この変更はほとんどのウェブサイトやドキュメントに反映されています。 GCP と呼んではいけないの？ GCP という名称は、原則的にはもう使わないことになっています。 ただし、一般的なユーザーは、以前から親しまれてきた GCP という略称を使っているケースがあります。GCP という言葉の知名度が高いことや、同じくクラウドプラットフォームである AWS（Amazon Web Services）と同じく3文字で略せること、また新名称である Google Cloud を単純に略すと、「GC」となり一般的には同じく IT 用語であるガベージコレクションと捉えられてしまうことなどから、「GCP」の語は日常的に目にします。 Google Cloud 専業インテグレーターである G-gen は、原則的には GCP の語を使いませんが、G-gen Tech Blog では Google Cloud（旧称 GCP） のように併記する場合があります。 また、Google の提供するクラウド製品の利用規約ページには「Google Cloud Platform」の名称が残っています。これは、Google が提供する Google Workspace や Google Maps など、他のクラウドサービスと明確に区別をするためと考えられます。ブランディングの背景では Google Cloud Platform は使われませんが、このように一部の公式ドキュメントや Web コンソール画面では、まだ使われているケースがあります。 参考 : Google Cloud Terms Directory Google Cloud と Google 日本においては、Google Cloud は「グーグル・クラウド・ジャパン合同会社」が販売しています。また、利用者が Google Cloud の利用規約に同意する際、グーグル側の契約主体となるのも同社です。なおグーグル・クラウド・ジャパン合同会社は、Google Workspace や Google Maps などの販売活動も行っています。ただし、Google Workspace に関しては、日本の顧客に対する契約主体は Google Asia Pacific Pte. Ltd. となっているなど、契約の観点では、すこし複雑になっています。 参考 : Google Contracting Entity また、「Google 広告」「YouTube」など多くの Google サービスは日本では「グーグル合同会社」が販売主体となっており、Google Cloud や Google Workspace 等と他の Google 製品は、扱いが少し異なることが分かります。 一般的なユーザーの目線ではあまり意識する必要はないといえますが、契約を扱ったり、法的な視点が必要な方は、意識するタイミングがあるかもしれません。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。組織のポリシーでリソースロケーションに制約のあるプロジェクトで gcloud builds submit (Cloud Build のビルドコマンド) を実行したところ、 HTTPError 412 エラーが出力され Docker イメージのビルドに失敗する事象が起きました。 当記事では、事象の原因と対策をご紹介します。 事象 構成 実行内容 エラーの詳細 原因 調査 判明した原因 対処法 その他 事象 構成 今回問題のあった環境は、組織 example.co.jp のツリー構造に属するプロジェクトの一つです。 組織レベルで constraints/gcp.resourceLocations を下図のように設定し、組織全体でリソースロケーションを 東京リージョン (asia-northeast1) と 大阪リージョン (asia-northeast2) に制限しています。 参考 : リソース ロケーションの制限 参考 : 組織のポリシーを解説 - G-gen Tech Blog 実行内容 以下のソースコードを用いて gcloud builds submit コマンドを以下の通り実行したところエラーが発生しました。 この際、API の有効化、Cloud SDK の認証、ならびに実行ユーザーや Cloud Build サービスアカウントの IAM 設定等に不備はありませんでした。 参考 : gcloud builds submit 参考 : コンテナ イメージをビルドします 参考 : サービスの有効化と無効化 参考 : Cloud Build サービス アカウント 参考 : gcloud auth loginとgcloud auth application-default loginの違いとは？ - G-gen Tech Blog # ソースコード一覧 $ tree . ├── image_build.sh └── source ├── cloudbuild.yaml ├── Dockerfile ├── go.mod ├── go.sum └── main.go # image_build.sh #!/bin/bash # 変数定義 project_id = $( gcloud config get-value project ) location = " asia-northeast1 " repository_name = " image-build-test " image_name = " test " # APIがまだ有効でない場合はチェックして有効化する services = ( artifactregistry.googleapis.com cloudbuild.googleapis.com ) for service in " ${services[ @ ]} " ; do if gcloud services list --enabled --filter= " name: ${service} " --format= " value(name) " | grep " ${service} "; then echo " Service ${service} is already enabled. " else echo " Enabling service ${service} ... " gcloud services enable " ${service} " fi done # コンテナイメージ用のリポジトリを確認 if gcloud artifacts repositories describe " $repository_name " --location= $location &> /dev/null ; then echo " Artifact repository $repository_name already exists, skipping creation. " else # 存在しない場合は作成 gcloud artifacts repositories create " $repository_name " \ --location $location \ --repository-format " docker " echo " Artifact repository $repository_name created. " fi # イメージビルド gcloud builds submit ./ source \ --config=./source/cloudbuild.yaml \ --region= $location \ --substitutions=_LOCATION= $location , _REPOSITORY = $repository_name , _IMAGE = $image_name # cloudbuild.yaml # 変数は`image_build.sh`の`gcloud builds submit --substitutions`から動的に渡される steps: - id: docker build and push name: ' gcr.io/cloud-builders/docker ' args: [ ' build ' , ' -t ' , ' ${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest ' , ' . ' ] images: - ' ${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest ' # Dockerfile # Goのバージョン1.22.2を使用 FROM golang:1. 22 . 2 as builder # 作業ディレクトリの設定 WORKDIR /app # 依存関係のコピーとダウンロード COPY go.mod go.sum ./ RUN go mod download # ソースコードのコピー COPY main.go ./ # アプリケーションのビルド RUN CGO_ENABLED = 0 GOOS =linux go build -o main . # 実行環境の設定 # Distroless base image を使用 FROM gcr.io/distroless/base-debian10 WORKDIR / # ビルドしたバイナリを実行環境にコピー COPY --from=builder /app/main . # コンテナ起動時のコマンド CMD [" /main "] エラーの詳細 エラーメッセージは ERROR: (gcloud.builds.submit) HTTPError 412: 'us' violates constraint 'constraints/gcp.resourceLocations' でした。出力の詳細は以下のとおりです。 # 実行ログ $ ./image_build.sh Your active configuration is: [ cloudshell-1976 ] projects/ 111111111111 /services/artifactregistry.googleapis.com Service artifactregistry.googleapis.com is already enabled. projects/ 111111111111 /services/cloudbuild.googleapis.com Service cloudbuild.googleapis.com is already enabled. Artifact repository image-build-test already exists, skipping creation. ERROR: ( gcloud.builds.submit ) HTTPError 412: ' us ' violates constraint ' constraints/gcp.resourceLocations ' 原因 調査 'us' violates と示されていることから、 gcloud builds submit コマンド実行時に何らかのリソースが US マルチリージョン に作成されようとした結果、エラーが発生したのではないかと推察しました。 判明した原因 以下の公式ドキュメントを確認したところ、以下のような記載がありました。 Cloud Build はデフォルトで、ビルドを実行するロケーションとは異なる Google 指定リージョンにビルドログを保存します。 つまり、US マルチリージョンにビルド実行ログ保存用の Cloud Storage バケットを作成しようとした際、リソースロケーションの制約に違反してエラーが発生したことがわかりました。 参考 : ユーザー所有のリージョン化されたバケットへのビルドログの保存 対処法 gcloud builds submit コマンドに --default-buckets-behavior="regional-user-owned-bucket" を付与して実行します。 これにより、ビルドログ保存先リージョンを US からビルド実行先 (今回で言えば東京リージョン) に変更してリソースロケーションの制約を回避します。 # image_build.sh (修正後、gcloud builds submit 部分のみ記載) gcloud builds submit ./ source \ --config=./source/cloudbuild.yaml \ --default-buckets-behavior= " regional-user-owned-bucket " \ --region= $location \ --substitutions=_LOCATION= $location , _REPOSITORY = $repository_name , _IMAGE = $image_name # 実行ログ (image_build.sh 修正後) $ ./image_build.sh Your active configuration is: [ cloudshell-772 ] projects/ 111111111111 /services/artifactregistry.googleapis.com Service artifactregistry.googleapis.com is already enabled. projects/ 111111111111 /services/cloudbuild.googleapis.com Service cloudbuild.googleapis.com is already enabled. Artifact repository image-build-test already exists, skipping creation. Creating temporary archive of 5 file ( s ) totalling 19 . 7 KiB before compression. Uploading tarball of [ ./source ] to [ gs://yutakei-test-prj_asia-northeast1_cloudbuild/source/ 1714488853 .161679-ce5f2b25b04146be8f8bd54f8d053851.tgz ] Created [ https://cloudbuild.googleapis.com/v1/projects/yutakei-test-prj/locations/asia-northeast1/builds/48b469e7-243e-4fc6-b490-ec43c1403414 ] . Logs are available at [ https://console.cloud.google.com/cloud-build/builds ; region = asia -northeast1/48b469e7-243e-4fc6-b490-ec43c1403414?project = 111111111111 ] . Waiting for build to complete . Polling interval: 1 second ( s ) . ---------------------------------------------------------------- -- REMOTE BUILD OUTPUT ------------------------------------------------------------------ starting build " 48b469e7-243e-4fc6-b490-ec43c1403414 " ※ 途中省略 Step 10 / 10 : CMD [" /main "] Running in dae2b25a7765 Removing intermediate container dae2b25a7765 2b7d07a95edc Successfully built 2b7d07a95edc Successfully tagged asia-northeast1-docker.pkg.dev/yutakei-test-prj/image-build-test/test:latest PUSH Pushing asia-northeast1-docker.pkg.dev/yutakei-test-prj/image-build-test/test:latest The push refers to repository [ asia-northeast1-docker.pkg.dev/yutakei-test-prj/image-build-test/test ] 89648652935c: Preparing 91f7bcfdfda8: Preparing 05ef21d76315: Preparing 91f7bcfdfda8: Layer already exists 05ef21d76315: Layer already exists 89648652935c: Pushed latest: digest: sha256:03a23554f16b2ed46c7125d6eafbce97e8d7582a4a29d3c8d759891c58174f49 size: 950 DONE --------------------------------------------------------------------------------------------------------------------------------------------------------- ID: 48b469e7-243e-4fc6-b490-ec43c1403414 CREATE_TIME: 2024-04-30T14:54:14+00:00 DURATION: 2M1S SOURCE: gs://yutakei-test-prj_asia-northeast1_cloudbuild/ source / 1714488853 .161679-ce5f2b25b04146be8f8bd54f8d053851.tgz IMAGES: asia-northeast1-docker.pkg.dev/yutakei-test-prj/image-build-test/ test ( + 1 more ) STATUS: SUCCESS リソースロケーションの制約を守りつつDockerイメージの作成に成功 --default-buckets-behavior="regional-user-owned-bucket によりビルドログ保存バケットが US ではなくビルド実行先リージョンに作成された その他 今回記事にしたCloud Build ですが、サービスアカウントとして使われていた <PROJECT_NUMBER>@cloudbuild.gserviceaccount.com の仕様が 2024年4月29日から変更 されます。 詳しくは当社の記事で解説しています。ぜひご確認ください。 blog.g-gen.co.jp 武井 祐介 (記事一覧) 2022年4月にジョイン。クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2024 に選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei

G-gen の荒井です。当記事では Google Workspace のアプリケーションのみを使用して、問い合わせ対応システムを作成する方法をご紹介します。 はじめに ご紹介すること 記事の構成 留意事項 本問い合わせ対応システムの特徴 メリット デメリット 期待する効果 システム構成 アプリケーション システム構成図 次の記事 はじめに ご紹介すること Google Workspace には、Gmail、Google フォーム、Google スプレッドシートなど、日常業務で利用できるアプリケーションが数多く用意されており、アプリケーション間はシームレスに（垣根なく）連携することができます。適切に組み合わせて使用することで、単体での利用に比べて大きな効果を発揮します。 今回は複数のアプリケーションを組み合わせ、問い合わせ対応システムを作成します。 記事の構成 問い合わせ対応システムの開発方法は、以下の通り、連載記事としてご紹介します。記事を順に確認することで、問い合わせ対応システムが完成します。 No タイトルとリンク 1 ※ 当記事 Google Workspace で問い合わせ対応システムを作成する方法 #1 (システム概要) 2 Google Workspace で問い合わせ対応システムを作成する方法 #2 (Google グループ設定) 3 Google Workspace で問い合わせ対応システムを作成する方法 #3 (Google フォーム設定) 4 Google Workspace で問い合わせ対応システムを作成する方法 #4 (Google App Script 設定) 5 Google Workspace で問い合わせ対応システムを作成する方法 #5 (業務フロー解説) 6 ※ 準備中 Google Workspace で問い合わせ対応システムを作成する方法 #6 (機能拡張案) 留意事項 管理者権限 問い合わせ対応システムを作成するうえで、Google グループの作成が必要になります。組織のポリシーとしてグループ作成に特権管理者（グループ管理者）が必要になる場合があります。 ご自身が権限を保持していない場合、社内のシステム担当者様にご依頼をお願いします。 GAS 実行アカウント 自動化プログラムの実行に利用する Google Apps Script（GAS）の実行者がご自身のアカウントで設定されるため、当該アカウントが削除された場合、GAS が実行できなくなります。 本問い合わせ対応システムの特徴 メリット コスト Google Workspace の標準機能のみで作成するため、Google Workspace を導入していればシステム導入コスト “ゼロ” で問い合わせ対応システムを作成できる メンテナンス性 自社でシステム構築を行うため、フォームの項目を追加・削除する場合でも業者に依頼せず即時に対応することができる。 履歴管理 過去の問い合わせ履歴を一つのデータベース（スプレッドシート）に集約することができる。今後問い合わせデータを分析したいと考えた場合、分析用データベースとしても使用することが可能。 デメリット デザイン 利用者が最初に目にする Google フォームは、決まったデザインの中で色味を変更する程度となるため、凝ったデザインを実現することが難しい。 データの保管場所 Google Workspace はデータの保管場所（リージョン）を任意に設定することができない。そのため「問い合わせ内容（履歴データ）を日本国内で保管する」といった社内ポリシーがある場合、対応できない。 問い合わせ履歴の上限数 Google スプレッドシートでは、シートに入力できる上限が 1,000 万セルまで。問い合わせフォームの項目が10項目程度の場合、データベースには100万件程度の問い合わせを上限として記録することができる。 問い合わせ件数が非常に多く、上記の仕様を超える規模の場合、Google スプレッドシートでの実現はできない。 期待する効果 本問い合わせ対応システムを作成することで、以下のような期待効果が見込まれます。 複数人で問い合わせ対応を行う際に、誰がどのケースを担当しているかすぐにわかる フォームの項目を作り込むことで、ヒアリング漏れがなくなり効率的なケース対応ができる フォーム受付と同時にメールが自動返信されるため、初動対応にタイムラグがなくなる 問い合わせ履歴がデータベースにまとまるため、過去履歴の検索が用意になる システム構成 アプリケーション 今回のシステムで使用する Google Workspace アプリケーションは以下のとおりです。 アプリケーション 説明 Google フォーム ユーザーから問い合わせを受け付けるフォーム（インターフェース）として使用します。 Google スプレッドシート 問い合わせフォームの履歴管理用のデータベースとして使用します。また当スプレッドシートに GAS を設定します。 Google グループ 問い合わせフォームの対応を複数人で対応するために使用します。 Google App Script (GAS) 問い合わせ受付時にメールを自動返信する機能を作成します。 システム構成図 今回の問い合わせ対応システムは、以下のような構成となります。 次の記事からは、実際にアプリケーションの設定手順をご紹介します。 次の記事 Google Workspace で問い合わせ対応システムを作成 #2 (Google グループ設定) 荒井 雄基 (記事一覧) クラウドソリューション部 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。 Google Cloud 認定資格 7冠 現在は Google Workspace を中心に企業の DX 推進をサポート。 最近頑張っていることは、子どもがハマっている戦隊モノの踊りを踊れるようになること。

G-gen の佐々木です。当記事では、Google Cloud でマネージドな Jupyter ノートブック環境を利用できる、2種類のノートブックソリューション（Colab Enterprise / Vertex AI Workbench）を解説します。また、Colab Enterprise と Vertex AI Workbench の違いや、選定の基準についても簡単にご紹介します。 Colaboratory と Google Cloud のノートブックソリューション Colaboratory Google Cloud のノートブックソリューション Colab Enterprise Colab Enterprise とは ランタイムとランタイムテンプレート ランタイム ランタイムテンプレート ランタイムテンプレートの共有 デフォルトのランタイム アイドルシャットダウン IAM によるアクセス制御 ノートブックへのアクセス制御 ランタイムテンプレートに対するアクセス制御 ノートブックから Google Cloud API に対するアクセス制御 VPC Service Controls の使用 生成 AI によるコード補完 BigQuery Studio との統合 料金 料金の基本 デフォルトランタイム使用時の料金例 Vertex AI Workbench Vertex AI Workbench とは Vertex AI Workbench インスタンスとは カーネルの追加 ノートブックのスケジュール実行 アイドルシャットダウン IAM によるアクセス制御 VM へのアクセス JupyterLab インターフェースに対するアクセス制御 VPC Service Controls の使用 他の Google Cloud サービスとの統合 Cloud Storage BigQuery Dataproc GitHub への接続 料金 Colab Enterprise と Vertex AI Workbench の比較 Colab Enterprise と Vertex AI Workbench の違い 選定基準 Colaboratory と Google Cloud のノートブックソリューション Colaboratory Colaboratory は、Google が提供しているブラウザベースの Jupyter ノートブック環境です。Colaboratory は Google のサービスではありますが、Google Cloud のサービスではありません。 Colaboratory には以下のような特徴があり、ユーザーによる環境の構築が不要で、手軽にノートブック環境を利用することができます。 無料で利用することができる（有料プランもあり）。 pandas、NumPy、TensorFlow、PyTorch などの、データ分析や機械学習に必要なパッケージがプリインストールされている。 GPU や TPU を使用して処理を実行することができる。 ノートブックを共同編集できる。 Google Drive と連携してノートブック、データを保存できる。 Colabotatory はブラウザで Jupyter ノートブック環境を利用できる Google Cloud のノートブックソリューション Colab Enterprise と Vertex AI Workbench は、Colaboratory と同様、環境構築不要のノートブック環境を提供する Google Cloud のサービスです。 これらのサービスは Colaboratory のように無料で利用することはできませんが、Google Cloud のサービスとして、IAM を使用したアクセス制御や、データの保存先となるリージョンの指定など、企業利用の場合に要求されるセキュリティ機能、コンプライアンス機能が提供されます。 また、BigQuery や Cloud Storage などの他のサービスと連携することにより、ノートブック環境を拡張することができます。 Colab Enterprise Colab Enterprise とは Colab Enterprise は、Google Cloud 上に事前構築されたマネージドなノートブック環境を提供するサービスです。 Colab Enterprise では、ノートブック環境をホストするインフラストラクチャ（ ランタイム ）を ランタイムテンプレート として構成しておくことで、ノートブックを使用するときだけ、テンプレートで構成した環境を自動的に起動します。ランタイムは、ノートブック未使用時はシャットダウンすることができます。 ランタイムとランタイムテンプレート ランタイム ランタイムは、ノードブック環境を実行するための Google マネージドの VM です。 後述の Vertex AI Workbench と異なり、Colab Enterprise ではユーザーが VM の管理を意識することはないため、当記事では Colab Enterprise の実行環境のことを指す場合はランタイムと記載します。 ノートブックを実行する際に、その実行環境となるランタイムに接続する必要があります。 ノートブックからランタイムに接続する ランタイムテンプレート マシンタイプやディスクタイプ、ディスクサイズなどのランタイムの構成は、ランタイムテンプレートとして事前定義しておき、このテンプレートを使用してランタイムを起動します。 ランタイムテンプレートでは、以下のような項目を定義できます。 項目 説明 リージョン テンプレートを保存するリージョン マシンタイプ テンプレートから起動されるランタイムの VM が使用する マシンタイプ アクセラレータ 使用する GPU の種類と数（GPU が使用できるマシンタイプの場合に設定可能） ディスク ランタイムにアタッチする 永続ディスクの種類 と、ディスクの容量 アイドルシャットダウン アイドルシャットダウン（後述）を有効化するかどうか アイドルシャットダウンまでの時間 ネットワーク ランタイムを起動する VPC とサブネット パブリック IP の割り当て ランタイムにパブリック IP を紐付けるかどうか エンドユーザー認証情報 ランタイムが Google Cloud の API にアクセスする際、ノートブックを利用しているユーザーの認証情報を使用できるかどうか（後述） 参考： Runtimes and runtime templates ランタイムテンプレートの共有 ランタイムは、そのランタイムを作成したユーザー専用の環境であり、他のユーザーが使用することはできません。ノートブックを他のユーザーに共有する場合、そのユーザー専用のランタイムを起動して接続し、ノートブックを実行する必要があります。 作成したランタイムテンプレートを他のユーザーと共有することで、他のユーザーも同一の構成でランタイムを実行することができます。 ランタイムテンプレートからユーザー専用のランタイムを作成する デフォルトのランタイム プロジェクトごと、リージョンごとにデフォルトのランタイムテンプレートが存在します。これを利用することで、自分でランタイムテンプレートを作成しなくても、すぐにランタイムを実行することができます。 デフォルトのランタイムテンプレートは以下のように構成されています。 項目 設定値 マシンタイプ e2-standard-4 アクセラレータ なし アイドル シャットダウン 有効 ネットワーク デフォルト VPC パブリック IP の割り当て 有効 エンドユーザー認証情報 有効 また、デフォルトのランタイムは作成から18時間後に自動で削除されます。 アイドルシャットダウン アイドルシャットダウンは、一定時間非アクティブ状態が継続したランタイムを自動でシャットダウンする機能です。Colab Enterprise ではランタイムの起動時間だけ料金が発生するため、これを有効化することで、ランタイムを使用していない時間の料金を節約することができます。 アイドルシャットダウンを有効化した場合、以下の条件がすべて満たされるとランタイムがシャットダウンされます。 アイドルシャットダウンで指定した時間、カーネルの操作がない。 ランタイムがノートブックに接続されていない（すべてのノートブックが閉じられている） シャットダウンまでの非アクティブ時間は、10分~1440分の任意の時間を設定することができます。 なお、Colab Enterprise のランタイムは手動で停止することができません。 アイドルシャットダウンによりランタイムが停止している 参考： Idle shutdown IAM によるアクセス制御 ノートブックへのアクセス制御 プロジェクトまたはノートブックの単位で、特定の Google アカウントやグループに対して、ノートブックのアクセス権を付与することができます。 参考： Manage access to a notebook ランタイムテンプレートに対するアクセス制御 特定の Google アカウントやグループに対してランタイムテンプレートに対するアクセス権を付与することで、ユーザー間で同一のテンプレートを使用してランタイムを起動することができるようになります。 参考： Manage access to a runtime template ノートブックから Google Cloud API に対するアクセス制御 ノートブック内のコードから他の Google Cloud の API にアクセスする場合、次のいずれかの方法を使用します。 ランタイムで「エンドユーザー認証情報」を有効化し、ノートブックを使用しているユーザーの認証情報で Google Cloud API にアクセスする。 ノートブック上で !gcloud auth application-default login コマンドを使用して、ユーザーの認証情報ファイル（ローカル ADC ファイル）を作成する。 ローカル ADC ファイルを使用する場合、ファイルはランタイム内に保存されます。 参考： Access Google Cloud services and APIs VPC Service Controls の使用 Colab Enterprise は、VPC Service Controls のサービス境界内で使用することができます。 VPC Service Controls の詳細は以下の記事を参照してください。 blog.g-gen.co.jp サービス境界内で Colab Enterprise を使用すると、ランタイムはサービス境界の影響を受けます。 ランタイムに対するアクセス制御に IAM 以外の要素（IP アドレス範囲など）を設定することができ、またノートブックからアクセスできる Google Cloud サービスを制限することができます。 Use VPC Service Controls 生成 AI によるコード補完 Colab Enterprise のノートブックでは、Google の生成 AI モデルである Gemini を使用したコード補完機能がサポートされています。 たとえば、以下のスクリーンショットのように、ノートブックのセルに「import p」と入力すると、コード補完によって「import pandas as pd」が提案される場合があります。この状態で Tab キーを押すと、提案されたコードがセルに自動で入力されます。 Gemini によるコード補完 また、セル内のコメントでプロンプトを入力すると、プロンプトの内容に応じたコードが提案されます。 プロンプトを使用したコード補完 参考： Write code in a Colab Enterprise notebook with Gemini assistance BigQuery Studio との統合 Colab Enterprise は、BigQuery Studio と UI が統合されています。BigQuery の UI 上でノートブックを開き、Colab Enterprise のランタイムを使用してノートブックを実行することができます。 これにより、BigQuery のデータをノートブック上で分析したい場合など、BigQuery と Colab Enterprise の UI を行き来する必要がなくなります。 BigQuery Studio からランタイムを使用してノートブックを実行する また、ノートブックは BigQuery DataFrames が組み込みでサポートされているため、BigQuery にあるデータを pandas、scikit-learn ライクに操作する処理を、BigQuery のコンピュートリソースで実行することができます。 BigQuery DataFrames の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp 参考： Introduction to notebooks 料金 料金の基本 Colab Enterprise の料金は、CPU、メモリ、GPU、ディスクの利用量に対して発生します。リージョンやマシンタイプ、ディスクタイプによって料金単位が異なるため、詳細は公式ドキュメントを参照してください。 課金単位 料金の計算方法 備考 CPU マシンタイプに応じた料金 * CPU 数 * ランタイムが起動している時間 メモリ マシンタイプに応じた料金 * メモリ容量 * ランタイムが起動している時間 GPU GPU タイプに応じた料金 * ランタイムが起動している時間 ランタイムが GPU を使用する場合のみ ブートディスク SSD 永続ディスク100GB の料金 ディスクの種類、容量は固定 データディスク ディスクの種類に応じた料金 * ディスク容量 * ランタイムが存在する時間 ランタイム停止中も料金が発生 アイドルシャットダウン機能を活用することで、ディスク容量以外の料金を節約することができます。 参考： Colab Enterprise の料金 デフォルトランタイム使用時の料金例 ランタイムを明示的に指定しなかった場合、 デフォルトランタイム が使用されるため、 e2-standard-4 マシンタイプと、ブートディスクとして SSD 永続ディスク100GiB 、データディスクとして 標準永続ディスク100GiB 相当の料金が発生します。 2026年1月時点の料金で、デフォルトランタイム（GPU なし）の利用時の料金を計算してみます（東京リージョンの場合）。計算の簡略化のため、各料金単位の小数点第6位以下を四捨五入しています。 CPU : $0.03363 * 4CPU = $0.13452 メモリ : $0.00449 * 16GiB = $0.07184 ブートディスク : $0.00036 * 100GiB = $0.036（SSD 永続ディスク） データディスク : $0.00009 * 100GiB = $0.009（標準永続ディスク） 合計 : $0.25136 / 時間 また、 アイドルシャットダウン 機能があり、ランタイムがシャットダウンしている間はコンピューティング料金（CPU・メモリ）は発生しません。したがって、デフォルトランタイムのシャットダウン期間の料金は以下のようになります。 ブートディスク : $0.00036 * 100GiB = $0.036（SSD 永続ディスク） データディスク : $0.00009 * 100GiB = $0.009（標準永続ディスク） 合計 : $0.045 / 時間 デフォルトランタイムでは、ランタイムを使用していない期間（アイドル時間）が3時間続くとアイドルシャットダウンが行われる設定になっています。 例として、デフォルトランタイムを8時間連続で利用した場合の1日あたりの料金は以下のようになります。 ランタイム利用時間 : $0.25136 * 8時間 = $2.01088 シャットダウンまでのアイドル時間 : $0.25136 * 3時間 = $0.75408 シャットダウン期間 : $0.045 * 13時間 = $0.585 合計 : $3.34996 / 日 Vertex AI Workbench Vertex AI Workbench とは Vertex AI Workbench は Colab Enterprise 同様、Google Cloud マネージドの Jupyter ノートブック環境を提供するサービスです。 2024年5月現在、Vertex AI Workbench には、インスタンスタイプとして以下3種類が用意されていますが、そのうち2種類は非推奨のものとなっています。 Vertex AI Workbench インスタンス Vertex AI マネージド ノートブック （非推奨） Vertex AI ユーザー管理ノートブック （非推奨） 当記事では、 Vertex AI Workbench インスタンス についてのみ解説していきます。 Vertex AI Workbench インスタンスとは Vertex AI Workbench インスタンス は、JupyterLab で事前にパッケージ化され、TensorFlow や PyTorch などの深層学習フレームワークがプリインストールされた VM を利用できるサービスです。 Colab Enterprise と比較すると、インフラストラクチャとして使用する VM のカスタマイズ性が高いことが特徴です。 以下は、Vertex AI Workbench インスタンスの VM 作成時に設定することができる項目の抜粋です。 項目 説明 リージョンとゾーン Vertex AI Workbench の VM を配置する VPC とサブネット バージョン Vertex AI Workbench インスタンスの バージョン マシンタイプ VM のマシンタイプ GPU 使用する GPU の種類と数（GPU が使用できるマシンタイプの場合に設定可能） アイドルシャットダウン アイドルシャットダウンを有効化するかどうか アイドルシャットダウンまでの時間 ディスク VM にアタッチする 永続ディスクの種類 と、ディスクの容量 ディスクの暗号化 ディスクの暗号化に使用する鍵 Google 管理の暗号鍵（デフォルト）と顧客管理の暗号鍵のどちらかを選択 ネットワーク VM を起動する VPC とサブネット パブリック IP の割り当て VM にパブリック IP を紐付けるかどうか ユーザー JupyterLab インターフェースにアクセスできるユーザー（後述） サービスアカウント VM に紐付けるサービスアカウント 環境の自動アップグレード インスタンスのバージョンを 自動でアップグレード するかどうか このほか、 Shielded VM や Cloud Monitoring との連携 、VM に付与する ネットワークタグ など、様々な項目を設定することができます。 カーネルの追加 Jupyter ノートブックにおける カーネル は、ノートブック内のコードの実行、結果の出力、状態の保持などを行う機能です。 Vertex AI Workbench では、カーネルの管理に conda が使用されています。conda 環境を新たに追加することで、新しいカーネルが JupyterLab のインターフェース上に表示されます。 JupyterLab のインターフェース（デフォルト） JupyterLab からターミナルを開き、 conda create コマンドで conda 環境を追加して、任意の conda パッケージをインストールすることで、新しいカーネルを使用することができます。 例えば、以下のようなユースケースがあります。 R や Apache Beam などの環境を使用する。 Python や TensorFlow、PyTorch の古いバージョンを使用する。 R のカーネルを利用したい場合は、以下のように conda 環境を追加します（ 参考 ）。 $ conda create -n r $ conda activate r $ conda install -c r r-essentials $ DL_ANACONDA_ENV_HOME = " ${DL_ANACONDA_HOME} /envs/r> " $ python -m ipykernel install --prefix " ${DL_ANACONDA_ENV_HOME} " --name r --display-name r $ rm -rf /opt/conda/envs/ r /share/jupyter/kernels/python3 R 環境が JupyterLab の Launcher 上に表示される 参考： conda 環境を追加する ノートブックのスケジュール実行 Vertex AI Workbench Executor を使用することで、ノートブック内のコードをスケジュール実行することができます。 スケジュールは、JupyterLab のインターフェースから設定します。ノートブックを1回だけ実行するか、定期的に実行するかを選択することができます。 Vertex AI Workbench Executor を使用してノートブックをスケジュール実行する ノートブックの実行は Vertex AI Training のジョブとして実行されるため、VM がシャットダウンされている場合でも、ノートブックはスケジュール通りに実行されます。 なお、VPC Service Controls を使用する場合、Vertex AI Workbench Executor の使用はサポートされていません。 参考： ノートブックの実行スケジュールを設定する アイドルシャットダウン Colab Enterprise 同様、Vertex AI Workbench でも VM の非アクティブ時のアイドルシャットダウンを設定することができます。シャットダウンされている間は、コンピュートリソース（CPU、メモリ、GPU）の使用時間あたりの料金が発生しません。 アイドルシャットダウンにより VM が停止している また、Colab Enterprise と異なり、Vertex AI Workbench の VM は 手動でシャットダウン することもできます。 参考： アイドル状態でのシャットダウン IAM によるアクセス制御 VM へのアクセス VM へのアクセスは、プロジェクトもしくは VM 単位で設定することができます。VM の起動、停止、アップグレードなどの権限を Google アカウント、グループに付与することができます。 また、VM に対する完全なアクセス権を持っていたとしても、JupyterLab インターフェースを使用する権限は付与されません。 参考： インスタンスへのアクセスを管理する JupyterLab インターフェースに対するアクセス制御 JupyterLab インターフェースに対するアクセスは VM とは別に設定します。VM 作成時に アクセスモード として以下の2種類から選択します（アクセスモードは変更不可）。 アクセスモード JupyterLab インターフェースにアクセスできるユーザー シングルユーザーのみ VM 作成時に指定したユーザーアカウント のみ サービスアカウント VM に紐付いたサービスアカウントに対する サービス アカウント ユーザー ロール（ roles/iam.serviceAccountUser ）をもつユーザー 参考： インスタンスの JupyterLab インターフェースへのアクセスを管理する VPC Service Controls の使用 Colab Enterprise 同様、Vertex AI Workbench でも VPC Service Controls を使用することができます。 参考： Use an instance within a service perimeter 他の Google Cloud サービスとの統合 Cloud Storage Cloud Storage インテグレーションにより、VM に Cloud Storage バケットをマウントし、JupyterLab インターフェースからバケット内のファイルにアクセスすることができます。 テキストファイルやノートブックファイルなど、JupyterLab と互換性のあるファイルは編集することが可能です。 参考： JupyterLab で Cloud Storage バケットとファイルにアクセスする BigQuery ノートブック上から BigQuery のデータにアクセスするには、以下の方法があります。 %%bigquery マジックコマンドを使用する。 BigQuery のクライアントライブラリを使用する。 BigQuery インテグレーションを使用する。 BigQuery インテグレーションを使用すると、JupyterLab インターフェースから BigQuery に保存されているデータに対してクエリを実行することができます。 BigQuery インテグレーションを使用して BigQuery のデータにアクセスする 参考： JupyterLab 内から BigQuery 内のデータにクエリを実行する Dataproc Dataproc は、Google Cloud マネージドの Apache Spark / Hadoop クラスタを利用してデータを処理することができるサービスです。 Vertex AI Workbench インスタンスのバージョン M113 以降の VM には、 Dataproc JupyterLab プラグイン がプリインストールされています。これを使用することで、Apache Spark ノートブックを Dataproc クラスタ、もしくは Dataproc Serverless で実行することができます。 参考： Dataproc が有効になっているインスタンスを作成する GitHub への接続 Vertex AI Workbench インスタンスの VM に GitHub リポジトリのクローンを作成することで、リポジトリにノートブックファイルを保存し、また他の環境からリポジトリ内のノートブックを使用することができます。 GitHub リポジトリをクローンしてファイルを編集する 参考： ノートブックを GitHub に保存する 料金 Colab Enterprise 同様、Vertex AI Workbench でも、CPU、メモリ、GPU、ディスクの利用量に対して料金が発生します。こちらもリージョンやマシンタイプ、ディスクタイプによって料金単位が異なるため、詳細は公式ドキュメントを参照してください。 課金対象 説明 CPU、メモリ ランタイムの実行時間に応じて料金が発生します。 GPU ランタイムで GPU を使用している場合、ランタイム実行時間に応じて料金が発生します。 ディスク容量 ランタイムの実行状態に関わらず（停止していても）、確保したディスク容量ぶんの料金が発生します。 Vertex AI Workbench では、アイドルシャットダウン機能や手動での VM 停止により、ディスク容量以外の料金を節約することができます。 参考： Vertex AI の料金 - Vertex AI Workbench Colab Enterprise と Vertex AI Workbench の比較 Colab Enterprise と Vertex AI Workbench の違い ここでは、Colab Enterprise と Vertex AI Workbench の違いや、選定の基準についてご紹介します。 Colab Enterprise と Vertex AI Workbench の関係は、Google App Engine（GAE）のスタンダード環境とフレキシブル環境の違いに似ています（ GAE参考 ）。 どちらもマネージドなノートブック環境を提供するサービスですが、Colab Enterprise のほうが環境の管理負荷（運用コスト）が低く、その代わり Vertex AI Workbench のほうが環境を柔軟にカスタマイズすることができます。 以下の表は、これらのサービスで仕様が異なる点を簡単にまとめたものです。 比較の観点 Colab Enterprise Vertex AI Workbench ユーザーによる環境（ランタイム / VM）の管理 不要 一部で必要（バージョンアップなど） 環境のカスタマイズ ランタイムテンプレートの範囲で可能 柔軟にカスタマイズ可能 手動シャットダウン 不可 可 ディスクの暗号化に顧客管理の暗号鍵（CMEK）の使用 不可 可 GitHub への接続 不可 可 1つの環境を複数ユーザーで使用 不可 可 ノートブックの共同編集 可 不可 生成 AI によるコード補完の使用 可 不可 ノートブック内のコードから他の Google Cloud サービスの認証方法 ユーザーのアカウントを使用 VM のサービスアカウントを使用 選定基準 Colab Enterprise と Vertex AI Workbench のどちらを利用するか検討する際は、「まずは Colab Enterprise の機能が自分のユースケースに対して十分であるかどうかを確認する」「十分であれば Colab Enterprise を選択し、不十分であれば Vertex AI Workbench を選択する」という順番で検討するのがよいでしょう。 また、複数のユーザーがそれぞれで個別のノートブック実行環境を利用したい場合、同一の環境を用意するために、Colab Enterprise では同一のテンプレートからランタイムを作成するだけでよいですが、Vertex AI Workbench では Terraform（IaC）を用いるなどの工夫が必要です。この観点では Colab Enterprise のほうが利用しやすいと言えるでしょう。 料金については、Colab Enterprise、Vertex AI Workbench ともに、コンピュートリソース（CPU、メモリ、GPU）の使用時間、確保したディスク容量が課金単位となっており、同じような使い方をしていれば大きな差はありません。 ただし、ノートブックの実行に大量のコンピュートリソースが必要になるケースでは、1時間あたりの使用料金が大きくなるため、アイドルシャットダウンを待たずに手動で VM を停止することができる Vertex AI Workbench のほうが、運用によって料金を節約しやすいと言えるでしょう。 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

本記事では「Google Cloud モバイルアプリ」を利用してスマートフォンから Google Cloud を操作する方法を紹介します。 移動時など、パソコンが使えない時におすすめです。 Google Cloudモバイルアプリのメリット Google Cloudモバイルアプリのダウンロード方法 Google Cloud公式アプリでできること 『ダッシュボード』タブ 『リソース』タブ 起動中のCompute Engine のステータス確認 Compute Engine SSH接続 『運用』タブ インシデントのプッシュ通知 『権限』タブ 『お支払い』タブ Cloud Shell バケットの作成 バケットの削除 その他(設定など) Google Cloudモバイルアプリのメリット Google Cloudモバイルアプリを使うことで、スマートフォンから Google Cloud の 簡単な運用作業 や 通知の確認 を行うことができます。 例えば、外出先でもふと気になった時に利用料金を確認できます。また通知設定を有効にすることで、障害等が発生した際に、通知を確認できます。 さらに Cloud Shell でコマンドを実行したり、一部のサービスのリソース作成や設定値変更が可能です。 Google Cloudモバイルアプリのダウンロード方法 公式サイトよりダウンロード可能です。 Google Cloud アプリ Android play.google.com iOS Google Cloud Google Productivity Free apps.apple.com Google Cloud公式アプリでできること Google Cloud 公式アプリでは7つのタブがあります。 ダッシュボード リソース 運用 権限 お支払い Cloud Shell その他( 設定など ) それぞれの機能について紹介します。 なお、当記事の検証では iOS 版を利用しています。 『ダッシュボード』タブ 一言でいうと、 『 Google Cloud コンソールの簡易版 』 です。 課金状況と Google Cloud のステータスを確認できます。 記事執筆時は Cloud Composer で問題が発生しており、『 Google Cloudのステータス 』をタップすると詳細を確認できました。 『ダッシュボード』タブとステータス詳細 『リソース』タブ 『 リソース 』タブでは一部のサービスに対し、スマートフォンを操作することで機能を利用できます。 記事執筆時点（2024/04現在）、下記サービスに対応しております。 App Engine Compute Engine Kubernetes Engine Cloud Storage Cloud SQL Compute Engine の2つの事例について紹介します。 起動中のCompute Engine のステータス確認 「リソース」から「VM インスタンス」を選択、スマートフォン上で操作したいインスタンスを選択します。 CPU 利用率やインスタンスのステータスを確認できます。 『 リソース 』タブにて VM インスタンスのステータスを確認する手順 Compute Engine SSH接続 インスタンスのステータス画面より右上の3つの棒をタップした後、「 SSH へ接続 」をタップします。 Compute Engine の SSH 接続 の手順 接続後、警告文が表示されるので、「 y 」を入力します。 SSH 接続後の警告文 Compute Engine へ接続できました。 SSH 接続後のCloud Shell また、モバイルアプリ以外での Compute Engine の SSH 接続については、以下の記事で解説しています。 blog.g-gen.co.jp 『運用』タブ 『 運用 』では下記機能を利用できます。 インシデント ログ Personalized Service Health Dashboard トレース Error Reporting 稼働時間チェック 一部の機能について紹介します。 インシデントのプッシュ通知 通知設定を許可することで、自分のプロジェクトでインシデントが発生した時にモバイルアプリから通知を受け取ることができます。 インシデント通知の設定方法 『権限』タブ 『 権限 』ではプロジェクト内部に付与した権限一覧を確認することができます。 モバイルアプリ上で下記操作が可能です。 ロールの追加 ロールの変更 例えば新たなロールを作成する場合、右下の「＋」ボタンをタップし、メールアドレス、追加したいロールを入力することで作成可能です。 Google Cloud アプリで新規ロールを作成する手順 『お支払い』タブ ダッシュボードより詳細費用を確認できます。 『 お支払い 』タブ Cloud Shell ウェブ上の Google Cloud コンソールと同様に Cloud Shell を利用することができます。 今回は gcloud コマンドを利用し『 risa-mobile-test 』というバケットを作成しました。 バケットの作成 モバイルコンソール上に下記のコマンドを入力しました。 gcloud storage buckets create gs://risa-mobile-test --default-storage-class=standard --location=asia-northeast1 --uniform-bucket-level-access Cloud Shellでバケットを作成→結果 コンソール上でもバケットが作成されたことが確認できました。 バケットの削除 gcloud storage rm --recursive gs://risa-mobile-test 無事、バケットを削除できました。 本記事ではモバイルアプリを試すという趣旨のため簡単なコマンドを利用しましたが、gcloud コマンドについて詳しく知りたい方は下記を参考にしてください。 blog.g-gen.co.jp その他(設定など) Google アカウントの顔アイコンをタップすることで設定変更やアカウントの切り替え等ができます。 Google Cloud アプリの設定画面 奥田 梨紗 (記事一覧) クラウドソリューション部クラウドデベロッパー課 前職はベトナムのIT企業。 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。日々修行中です！

本記事では、Google のノーコード開発ツールである AppSheet の管理者向けに、導入戦略のベストプラクティスをご紹介します。 はじめに AppSheet とは 当記事について 開発モデルの選択 集中開発 ハイブリッド開発 市民開発 ガバナンスモデルの策定 導入企画のステップ 1. ステークホルダーを特定する 2. 実行チームを組織する 3. 目標と優先順位を決定する 4. ゴールを定義し、追跡する指標を決定する 5. ガバナンス戦略に合わせて、導入ステップを計画する 役割の設計 ガバナンスポリシーの設計 はじめに AppSheet とは AppSheet は、Google が提供するノーコードのアプリ開発プラットフォームです。 プログラミング不要で、スプレッドシートなどのデータを基に、モバイルアプリや Web アプリを作成できます。特に興味深い点は、業務担当者などが開発出来るという点です。例えば次のようなアプリを、比較的短い開発期間で作成することが出来ます。 タスク(案件)管理アプリ ワークフロー 在庫管理アプリ 勤怠管理アプリ（シフト管理アプリ） AppSheet では豊富なテンプレートが用意されているのも特徴です。以下のリンクから、多くのテンプレートが取得できます（2024年5月現在は英語のみの提供です）。 参考 : AppSheet - Templates また、G-gen Tech Blog の過去の AppSheet 関連記事では、具体的なユースケースや開発手法をご紹介していますので、ぜひご参照ください。 blog.g-gen.co.jp 当記事について 当記事では導入戦略のベストプラクティスを記述します。当記事でご紹介するベストプラクティスは、Google Cloud が公式でオンラインハンズオンを提供するサイトである Google Cloud Skills Boost のプログラム「AppSheet Administration」にもとづいています。 以下のリンクから、当該プログラムを実体験していただくことが可能です。 参考 : Google Cloud Skills Boost - AppSheet Administration Google Cloud Skills Boost は、2024年4月に行われた旗艦イベント「Google Cloud Next '24」で、法人向けの無償化が発表されました。詳細は、Google Cloud もしくは G-gen のような販売パートナーのセールス担当へご連絡ください。 参考 : クラウドへの移行を加速するために設計された新しい Google Cloud コンサルティング プログラム 開発モデルの選択 AppSheet 導入における最初の重要なステップが開発モデルの選択です。 AppSheet の開発モデルは、次の3つが考えられます。 集中開発モデル ハイブリッド開発モデル 市民開発モデル 集中開発 少数の開発者ですべてのアプリを開発するモデルです。従来通りのシステム開発をイメージに近いといえます。 メリット: ガバナンスと品質管理が容易 デメリット: 相対的に開発速度が遅く、敏捷性に欠ける ハイブリッド開発 中核となる開発チームがトレーニングとサポートを行い、市民開発者によるアプリ開発を促進するモデルです。 市民開発 とは、プログラミング経験のない現場の業務担当者などが、ノーコード・ローコードツールを活用して、必要なアプリケーションを自ら開発していくことです。 アプリ開発の中心は市民（業務担当者など）が行い、開発チームはその支援を行っていく点が特徴です。 メリット: 相対的に開発速度が速く、柔軟性が高い デメリット: ガバナンスと品質管理が難しい 市民開発 完全に市民開発者のみでアプリを開発します。自由に開発出来るため柔軟性が高い一方で、品質管理やガバナンスの難しさがあります。 メリット: 開発速度が最も速い、イノベーションを起こしやすい デメリット: ガバナンスと品質管理が最も難しい ガバナンスモデルの策定 ガバナンスモデルとは、組織の中で AppSheet アプリの開発や運用を統制する方式のことです。 AppSheet には、以下の2つのガバナンスモデルがあります。 スタンダードモデル : 3種類の権限（ルート管理者、チーム管理者、チームメンバー）を持つシンプルなモデル 組織モデル : 4種類の権限（組織管理者、ルート管理者、チーム管理者、チームメンバー）を持つ、より細かく制御可能なモデル 組織モデルは、以下の両方に該当する場合に選択します。それ以外のケースでは、スタンダードモデルを選択してください。 複数のユーザーグループを作成し、個別にポリシーを割り当てたい。 上記のポリシー管理を含めた、AppSheet 管理権限をグループごとに権限移譲したい。 導入企画のステップ 1. ステークホルダーを特定する まず、AppSheet 導入に関わるステークホルダー（関係者）を特定します。これは、経営者、IT部門、業務部門など、様々な立場の人々が含まれます。 このステップでは、それぞれのステークホルダーが、AppSheet 導入に対してどのような期待を持っているのかを把握しましょう。 2. 実行チームを組織する 次に、AppSheet 導入を推進するチームを組織します。このチームは、プロジェクトリーダー、IT担当者、業務担当者などで構成されます。 IT担当者や業務担当者は、採用するガバナンス戦略に応じて人数を検討してください。例えば、集中開発の場合はIT担当者の数が多くなるかもしれません。 3. 目標と優先順位を決定する AppSheet 導入の目的と目標を明確にし、優先順位を決定します。例えば「どういった使い方をするか」、「どういったユースケースを優先するか」を明確します。 ステークホルダーやガバナンス戦略を踏まえて、「何を達成するために AppSheet を導入するのか」を検討しましょう。 4. ゴールを定義し、追跡する指標を決定する AppSheet 導入の成果を測定するためのゴールと指標を定義します。 # ゴール例 指標例 1 アプリの開発数をX件にする 四半期ごとの開発アプリの数 2 アプリの利用者数をY人に増やす 四半期ごとのアプリ利用者累計数 3 アプリの利用時間をZ時間に増やす 四半期ごとのアプリ累計利用時間 5. ガバナンス戦略に合わせて、導入ステップを計画する ガバナンス戦略に基づいて、具体的な導入ステップを計画します。 導入ステップの検討は採用するガバナンス戦略や会社の規模、取り組む状況に応じて様々な選択肢がありますので、本記事では解説を割愛します。 役割の設計 具体的には、以下の役割を定義する必要があります。 ルート管理者 : AppSheet 環境全体を管理する権限を持つユーザー 組織管理者 : 組織全体のポリシーを管理する権限を持つユーザー（組織モデルのみ） チーム管理者 : チーム内のポリシーを管理し、ユーザーを管理する権限を持つユーザー チームメンバー : AppSheet を利用してアプリを作成するユーザー ガバナンスポリシーの設計 事前定義されたポリシーを活用し、自社の利用に合わせたポリシーを設計します。 ガバナンスポリシーを設定することでガードレールが設定され、安心して市民開発を推進することが出来ます。 参考 : 事前定義ポリシー テンプレート - AppSheet ヘルプ 三木宏昭 (記事一覧) クラウドソリューション部 HROne→ServerWorks→WealthNavi→G-gen。AWS 11資格、Google Cloud認定全冠。Google Cloud Partner Top Engineer 2024。最近の悩みは中年太り。Twitter では クラウド関連のことや副業、その他雑多に呟いています。（頻度少なめ） Follow @cloudeep_miki

G-gen の杉村です。Google Cloud における負荷テスト（負荷試験）について、参考情報をご紹介します。当記事では、負荷テストの手順や試験設計に関する Tips 等ではなく、Google Cloud において負荷テストをする場合の考慮点や関連ドキュメントをご紹介します。 負荷テストは申請不要 割り当てと上限 負荷テスト前の確認 割り当て（Quota）とは 上限（Limit）とは 割り当てと上限に関するドキュメント Google との連携 公式ドキュメントの確認 ペネトレーションテスト（脆弱性診断） 負荷テストは申請不要 Google Cloud における負荷テストでは、Google に対する事前申請は 不要 です。 ただし、Apigee においては事前にサポートチケットを提出することが求められています。 参考 : ストレステスト、負荷テスト、ペネトレーション テストのリクエスト かつて Amazon Web Services（AWS）で、負荷テスト前に AWS に対する事前申請が必要だったことを覚えている方は、Google Cloud でも同様に申請が必要かどうか心配されるケースがありますが、Apigee を除いてその必要はありません。 なお、2024年現在では AWS でも、特定条件に当てはまる場合を除いて、申請は必要ありません。 参考 : Amazon EC2 Testing Policy 割り当てと上限 負荷テスト前の確認 負荷テストの実施前に、Google Cloud のプロジェクトの 割り当て と 上限 を確認し、これらの値に抵触するおそれがないか確認することが推奨されます。また、必要に応じて割り当ての緩和申請を行います。 参考 : Cloud Quotas overview Google Cloud コンソールの「割り当てとシステム上限」ページ 割り当て（Quota）とは 割り当て （Quota）とは、Google Cloud の API やリソースに設定された上限値のことです。割り当てはプロジェクトごとに設定されており、種類によっては値の緩和を Google に申請することができます。 割り当てには例として「Compute Engine の CPU コア数（リージョンごと / マシンタイプごと）」「Cloud Run のコンテナインスタンス数（リージョンごと）」などがあります。 新しいプロジェクトにおける割り当ての初期値は、請求先アカウントの利用履歴から動的に設定されたり、リージョンによって異なる場合などがあります。 割り当ての増量リクエストは、Google Cloud コンソール画面から行うことができます。 参考 : 割り当ての表示と管理 上限（Limit）とは 上限 （Limit もしくは System limit）とは、割り当てと同じく Google Cloud の API やリソースに設定された上限値ですが、システム上の制約であり、原則的に変更が不可能なものです。 上限も、割り当てと同様に、原則的に Google Cloud プロジェクトごとに存在します。また、種類によってはリージョンごとに値が異なるものがあります。 上限には例として「Cloud Run のサービス数（リージョンごと）」などがあります。 割り当てと上限に関するドキュメント 各 Google Cloud サービスの公式ドキュメントには、割り当てと上限の説明ページがあります。以下に、代表的なサービスの割り当てと上限に関するドキュメントのリンクを例示します。 プロダクト ドキュメント名とリンク Cloud Run Cloud Run Quotas and Limits Google Kubernetes Engine（GKE） Quotas and limits Compute Engine Compute Engine quota and limits overview Cloud Load Balancing Quotas and limits Cloud Storage Quotas & limits BigQuery Quotas and limits Google との連携 非常に大規模な緩和申請を行う場合などには、Google Cloud カスタマーケアにサポートケースを起票（ただし有償契約がある場合に限る）したり、緩和申請をしたうえで必要に応じて Google Cloud や Google Cloud パートナー（代理店）のセールス担当者に連絡を取りましょう。 参考 : Google Cloud カスタマーケア 公式ドキュメントの確認 各サービスの公式ドキュメントには、負荷テストにあたってのベストプラクティスが記載されている場合があります。これらのドキュメントも確認しましょう。 プロダクト ドキュメント名とリンク Cloud Run 負荷テストのベスト プラクティス Google Kubernetes Engine（GKE） Google Kubernetes Engine を使用した負荷分散テスト Cloud Load Balancing アプリケーション ロードバランサを使用したバックエンド サービスの負荷テストに関するガイドライン ペネトレーションテスト（脆弱性診断） 類似の話題として、ペネトレーションテストや脆弱性診断を行う際に、Google Cloud に申請をする必要があるかどうか、気にする方もいるかもしれません。 ペネトレーションテストや脆弱性診断も、負荷試験と同様に、Google に対する事前申請は 不要 です。 ただし、以下のドキュメントにあるように、影響範囲が他の Google Cloud 利用者に及ばないようにする必要があります。万一、Google 製品の脆弱性を発見した場合は、脆弱性報奨金プログラムから報告しましょう。 参考 : クラウドのセキュリティに関するよくある質問 参考情報ですが、負荷試験と同様、かつての AWS ではペネトレーションテストにあたり事前申請が必要でしたが、2024年現在では不要になっています。 参考 : ペネトレーションテストの AWS カスタマーサポートポリシー 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの山崎です。Google Cloud（旧称 GCP）の Privileged Access Manager （PAM）を用いた権限管理について解説します。 Privileged Access Manager（PAM） とは PAM の利用方法 利用資格 利用資格とは 付与する IAM ロール 権限を付与する最大時間 申請者と承認者 通知設定 監査ログ PAM の利用自体への権限管理 概要 管理者（特権管理の仕組みを作る人） 申請者（権限を付与される人） 承認者（権限を承認する人） 利用手順 ステップ１．利用資格の作成（管理者） PAM 画面への遷移 利用資格の詳細 リクエスト元の追加 承認者の追加 通知を追加 ステップ２．利用申請（申請者） 権限の事前確認 権限付与のリクエスト ステップ３．申請の承認（承認者） 申請の承認 権限の確認 監査ログの確認 Privileged Access Manager（PAM） とは Privileged Access Manager （以降、PAM）は、Google Cloud（旧称 GCP）の Cloud IAM の1機能であり、承認者による 承認フロー を経由して、 一時的な IAM 権限付与 をすることができる仕組みです。当機能の名称は、コンソール画面等では「特権アクセスマネージャー」とも表現されています。 フルマネージドのため基盤の管理やプログラムの開発は不要なうえ、無料で利用することができます。 この機能は、特権管理における ジャストインタイム（JIT）アクセス というコンセプトに基づいています。ユーザーに対して一時的に必要な特権を付与することで、不必要な特権の濫用や、情報漏洩のリスクを低減させることができます。 PAM では承認ワークフローを用いた特権付与ができるため、 不正な特権の付与を未然に防ぐ こともできます。 また、過去のワークフローの内容は監査ログから確認ができるため、 権限付与の妥当性の検証 も簡易に実施できます。 参考 : Privileged Access Manager overview 参考 : ジャストインタイムの特権アクセス管理の概要 参考 : Move from always-on privileges to on-demand access with new Privileged Access Manager PAM の利用方法 PAM は、以下の3ステップで利用することができます。 ステップ ステップ名 実施者 ステップ1 利用資格の作成 管理者（特権管理の仕組みを作る人） ステップ2 利用申請 申請者（権限を付与される人） ステップ3 申請の承認 承認者（権限を承認する人） ステップ1の「利用資格の作成」では 利用資格 （entitlements）という PAM のオブジェクトを作成します。これは「特権管理の承認フローの作成」と言い換えることができます。利用資格には「付与する IAM ロール」「権限を付与する最大時間」「誰が権限をリクエストできるか」「誰がリクエストを承認できるか」「誰が通知を受け取るか」などを定義できます。一度、利用資格を作成すると、利用資格は何度でも再利用することができます。 ステップ2では、IAM 権限を必要とする申請者が、利用資格の一覧から選択して、権限をリクエストします。リクエストは承認者に通知されます。 ステップ3で承認者がリクエストを承認すると、IAM ロールが申請者に付与されます。設定した最大時間が経過すると、IAM ロールは自動的に剥奪されます。 利用資格 利用資格とは 利用資格 （entitlements）は PAM のオブジェクトであり、承認フローと言い換えることもできます。利用資格には「付与する IAM ロール」「権限を付与する最大時間」「誰が権限をリクエストできるか」「誰がリクエストを承認できるか」「誰が通知を受け取るか」などを定義できます。 参考 : Create entitlements in PAM 付与する IAM ロール 「 付与する IAM ロール 」で定義した IAM ロールは、組織、フォルダ、プロジェクトに付与することができます。 IAM ロール付与先のリソースは、利用資格が存在するレベルによって決まります。つまり、プロジェクトに IAM ロールを付与する利用資格を作りたい場合は、利用資格をそのプロジェクトに作成します。組織に IAM ロールを付与する利用資格を作りたい場合は、利用資格をその組織のルート（根）レベルに作成します。 権限を付与する最大時間 「 権限を付与する最大時間 」を過ぎると、IAM ロールは自動的に剥奪されます。コンソール画面からの設定では、1時間から24時間の間で選択することができます。ただし、API 経由での設定の場合、秒単位での設定が可能です。 参考 : REST Resource: projects.locations.entitlements 申請者と承認者 「 誰が権限をリクエストできるか 」「 誰がリクエストを承認できるか 」はそれぞれ、申請者と承認者のプリンシパルを定義します。 プリンシパルとは、ここでは Google アカウントや Google グループを指します。ドメイン全体（組織の誰でも申請/承認できる）を指定することもできます。 通知設定 「 誰が通知を受け取るか 」を定義することで、E メール通知を設定できます。申請が行われたタイミングや、実際に権限付与が行われたタイミングなど、それぞれのイベントごとに、受信者を設定できます。通知を行わないことも可能です。 ただし、ここに明示的に設定しなくても、申請者や承認者には自動的に通知が行われます。 通知の E メールは pam-noreply@google.com から送信されるので、メール設定では、このアドレスからのメールがブロックされないように許可する必要があります。 監査ログ PAM で行われた権限リクエストや承認の履歴は、Cloud Audit Logs の仕組みで Cloud Logging に記録されます。 デフォルトでは管理アクティビティログとして「利用資格の作成、削除、更新」「リクエストの承認、否認」「PAM による権限の付与、剥奪」などが記録されます。 オプショナルでデータアクセス監査ログを有効化すると、利用資格の一覧取得や閲覧なども記録されます。 監査ログは Cloud Logging から確認可能なほか、PAM の管理画面の「監査ログ」タブからも確認できます。 参考 : Audit entitlement and grant events in PAM 参考 : Audited operations PAM の利用自体への権限管理 概要 PAM の利用自体にも、IAM による権限管理が可能です。 前述の「PAM の利用方法」では、PAM を利用する人の3つの役割（特権管理の仕組みを作る人、権限を付与される人、権限を承認する人）を示しました。その役割ごとに、異なる IAM 権限を付与する必要があります。 参考 : PAM permissions and setup 管理者（特権管理の仕組みを作る人） 管理者（特権管理の仕組みを作る人）、すなわち利用資格を作成したり、編集したりする人は、利用資格を作成するリソース（組織、フォルダ、プロジェクト）に対して「特権アクセス マネージャー管理者（ roles/privilegedaccessmanager.admin ）」を持っていることに 加え 、リソースのレベルに応じて以下のいずれかの IAM ロールが必要です。 セキュリティ管理者（ roles/iam.securityAdmin ） フォルダ IAM 管理者（ roles/resourcemanager.folderIamAdmin ） Project IAM 管理者（ roles/resourcemanager.projectIamAdmin ） 申請者（権限を付与される人） PAM の利用資格を通じて権限をリクエストする人（= 権限を付与される人）は、「特権アクセス マネージャー閲覧者（ roles/privilegedaccessmanager.viewer ）」が必要です。 利用資格が存在するリソース（組織、フォルダ、プロジェクト）において、この IAM ロールが付与されている必要があります。 承認者（権限を承認する人） 権限リクエストを承認する人が必要な IAM 権限は、申請者と同じ「特権アクセス マネージャー閲覧者（ roles/privilegedaccessmanager.viewer ）」です。 必要な IAM ロールは申請者と同じであり、承認する権限があるかどうか自体は、利用資格の定義で決まります。 こちらも、利用資格が存在するリソースにおいて、この IAM ロールが付与されている必要があります。 利用手順 ステップ１．利用資格の作成（管理者） PAM 画面への遷移 最初に、利用資格を作成します。これは、申請/承認ができるユーザが誰で、どのロールを付与するかを設定します。この設定は、 特権を付与したいユースケース単位 で実施します。 まず、Google Cloud コンソールメニューの「IAMと管理」＞「PAM」を押下します。 初期設定として、APIの有効化や、PAM のサービス アカウントへのアクセス権の付与を実施後、以下の画面が表示されます。 この画面の「CREATE」を押下すると、利用資格の新規作成画面が表示されます。 利用資格の詳細 利用資格の詳細では、権限を付与するロールと権限を付与する期間を設定します。 リクエスト元の追加 利用申請を行う、プリンシパルを設定します。 「リクエスト元の正当な理由が必要」のチェックをオンにすると、利用申請時に、申請理由の入力が必須となります。 承認者の追加 申請の承認を行う、プリンシパルを設定します。 「承認者の正当な理由が必要」のチェックをオンにすると、申請承認時に、承認理由の入力が必須となります。 また、「承認なしでアクセスを有効化」のチェックをオンにすると、申請の承認のフローを踏まず、利用申請を実施するだけで、権限の付与が可能となります。 通知を追加 最後に、以下の状態になった時に、通知を行うかの設定を行います。 利用資格が使用可能となった時 利用申請が行われ、承認待ちの状態となった時 申請が承認され、リクエスト元に権限が付与された時 なお、ここに設定しなくても申請者と承認者には、必ず通知メールが送信されます。 ステップ２．利用申請（申請者） 権限の事前確認 まず、現在の状態で、申請者にBigQuery のデータ編集権限がないことを確認します。 権限付与のリクエスト PAM のヘッダの「利用資格」を押下し、ステップ1で登録した利用資格が表示されていることを確認します。該当行の「権限付与をリクエスト」を押下します。 権限を付与する期間と、申請理由を入力し、「権限付与をリクエスト」を押下します。 ステップ３．申請の承認（承認者） 申請の承認 承認者にて、PAM のヘッダの「権限付与を承認」を押下し、ステップ2で登録した申請内容が表示されていることを確認します。該当行の「承認／拒否」を押下します。 承認理由を入力し、「承認」を押下します。 権限の確認 申請者にて、PAM のヘッダの「権限付与」を押下し、申請した権限のステータスが「Active」となっていることを確認します。 また、BigQuery に対して、データ更新ができることを確認します。 監査ログの確認 今までステップ1〜3で実施した内容は、履歴として保存されており、PAM のヘッダの「監査ログ」を押下すると、詳細を確認することができます。 前述の通り、監査ログは Cloud Audit Logs の仕組みで Cloud Logging に記録されているため、この画面のほか、Cloud Logging のログエクスプローラーからも確認できます。 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud 全 11 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

こんにちは、G-gen の荒井です。日々の業務で使用する Google Workspace では、利用の規模に比例して、障害も数多く発生します。当記事では、そんなときに役立つトラブルシューティング方法をご紹介します。 情報システム部門や、技術サポート窓口に依存することなく、皆さん自身でトラブルシューティングができるようになりましょう。 なぜ自分でトラブルシューティングをするのか 返答までに時間がかかることがある ほとんどの技術仕様は公開されている 簡単な原因切り分け作業で解決する問題も多い 原因の切り分け 影響範囲の確認 ブラウザの確認 端末の確認 ユーザーアカウント設定の確認 ネットワーク環境の確認 アプリケーション別の確認 Google Workspace 全体設定の確認 なぜ自分でトラブルシューティングをするのか システムでわからないことがあったら、ベンダーのテクニカルサポート窓口に問い合わるのが当たり前。そう考えている方も多いと思います。Google Workspace に限りませんが、テクニカルサポートへの起票が、一概に解決への最短ルートとは言えません。その理由は以下のとおりです。 返答までに時間がかかることがある 障害や不明点が発生したらサポートに問い合わせることはもちろん可能ですが、Google Workspace は利用ユーザーが非常に多いサービスです。そのため問い合わせも多く順番待ちとなってしまい、解決まで時間がかかってしまうケースも多くあります。 また順番が回ってきても状況確認や設定変更依頼が何度か発生するため、想像以上に早期解決が見込めない可能性もあります。 そのため問題の早期解決を目指すのであれば、自分自身である程度トラブルシューティングのできるスキルを持っておくことが早期解決の近道です。 ほとんどの技術仕様は公開されている トラブルシューティングでは、どんな機能が存在しているかなど技術仕様の確認作業も行います。 Google Workspace はサポートエンジニアなど特定のメンバーしか見れない技術情報はあまりなく、ほとんどの技術情報はユーザーからもかんたんに確認することが可能です。しかもドキュメントは英語ではなく日本語翻訳されています。 技術仕様がわかれば、自身で解決できる障害も多くなります。 公式ドキュメントは、以下から確認することが可能です。 参考 : Google Workspace Admin Help 参考 : Google Workspace ラーニング センター 簡単な原因切り分け作業で解決する問題も多い サポート窓口の担当者は皆さんの IT 環境を知らないうえ、原則的には皆さんと同じ画面を見ることができないので、何度もヒアリングや実施した操作方法の確認が発生します。 仮にメールが送れない障害が発生した場合、以下のような簡単な原因切り分け作業で障害原因が特定できることもあります。まずは自身の環境で原因の切り分けを行い、一次対応をしてみましょう。 宛先を変更してメールを送信してみる 添付ファイルを削除してメールを送信してみる PCではなく、スマホなど端末を変更してメールを送信してみる 上記のように、まずはご自身で簡単な原因の切り分けを行い、トラブルシューティングを試みた後に、サポートへ起票するのがより早い障害解決の道筋です。 原因の切り分け トラブルシューティングの基本的な流れは「 1. 原因の切り分け 」「 2. 原因の排除 」「 3. 動作確認 」です。 障害が発生したらまずは原因の切り分けを行い、どこに原因があるか確認しましょう。原因が分かりさえすれば、その原因を取り除くことができます。また、原因の切り分けを通じて得た情報をもとに、サポート窓口へ問い合わせをすることもできます。 以下のような作業を行うことで、障害原因を切り分けることができます。 影響範囲の確認 発生している障害が 全社で発生している事象 か 自身の環境だけ発生している事象 か確認しましょう。 ■ 確認項目例 障害が発生する操作を組織内の別ユーザーで実施する 障害が発生する操作を会社外のネットワーク環境（テザリングなど）で実施する ■ 対応方法例 全社で発生している事象の場合、システム全体の設定やネットワーク環境が原因と考えられます。システム管理者の方に問い合わせを行いましょう。 自分の環境だけで発生している事象の場合、自身の環境が障害の原因です。自身の環境にスポットを当ててトラブルシューティングを進めましょう。 ブラウザの確認 Google Workspace をはじめとする SaaS サービスは Web ブラウザを使用してサービスを利用します。Web ブラウザに原因があるか確認しましょう。 ■ 確認項目例 普段使用している Web ブラウザ以外を使用して、同じ操作を行う Web ブラウザの例 : Google Chrome、Firefox、Microsoft Edge、Safari すべてのアドオンを無効にして、同じ操作を行う シークレットウインドウを使用して、同じ操作を行う ■ 対応方法例 アドオンの無効化や普段使用しているブラウザ以外で障害が発生しない場合、普段使用しているブラウザに原因があると考えられます。 キャッシュのクリアなどを実施してみましょう。 参考 : キャッシュと Cookie の消去 - パソコン - Google アカウント ヘルプ 端末の確認 Google Workspace ではなく、端末自体の障害が発生している場合でも Google Workspace の操作ができないケースがあります。 ■ 確認項目例 別端末（隣の席のPC、スマートフォン）を使用し、同一ユーザーアカウントでログインし同じ操作を行う ■ 対応方法例 別端末で障害が発生しない場合、普段使用している端末に原因がある場合があります。端末管理者の方に問い合わせをしましょう。 ユーザーアカウント設定の確認 ユーザーアカウント単位での環境設定に関する障害も考えられます。違うアカウントでは同様の操作ができるか確認しましょう。 ■ 確認項目例 他の方のアカウントで同様の作業を実施いただき、障害が発生するか確認をします。 ■ 対応方法例 他のアカウントでは作業ができる場合、自身のアカウント設定に障害原因があります。直近行ったアカウントに対する設定変更を元に戻してみましょう。 心当たりがない場合、詳細な事象をシステム管理者の方に伝えて対応方法を仰ぎましょう。 ネットワーク環境の確認 普段使用しているネットワーク環境でのみ障害が発生する場合、ネットワーク環境に原因があると考えられます。ネットワーク環境に障害原因がある場合、全社・拠点規模で障害が発生していることが多いです。 ■ 確認項目例 別のネットワーク環境で操作した際に障害が発生するか確認する 別のネットワーク環境例 : テザリング環境、有線LAN環境、無線LAN環境 ■ 対応方法例 システム管理者の方に詳細な事象をお伝えいただき、トラブルシューティング・復旧作業を行っていただきましょう。 アプリケーション別の確認 Google Workspace アプリケーション内での設定・操作を変えることで障害が解決するケースもあります。以下例を参考に、アプリケーション内での設定（操作）を変更して切り分けを進めてみましょう。 Gmail 宛先を変更してメールの送信テストをする 一度添付ファイルを削除してメール送信する 別のユーザーに向けてメールを送信してもらい、受信できているか確認する Google ドライブ 閲覧方法を変更する（Web ブラウザ → パソコン版ドライブ） フォルダやファイルのアクセス権を確認する ログインしている Google アカウントを確認する Google Meet Meet に入り直す オーディオデバイスやビデオデバイスを端末に再接続する また、アプリケーションごとにトラブルシューティング用のドキュメントが用意されているものもあります。 Google Workspace 管理者ヘルプ で「 Gmail トラブルシューティング」といったキーワードで検索してみましょう。 参考 : Gmail でのメールの受信に関する問題のトラブルシューティング - Google Workspace 管理者 ヘルプ 参考 : メールの送信に関する問題のトラブルシューティング - Gmail ヘルプ 参考 : Google ドライブに関する一般的な問題を解決する - Google ドライブ ヘルプ 参考 : ログイン時の本人確認、2 段階認証プロセス、ログインに関する問題のトラブルシューティング - Google Workspace 管理者 ヘルプ Google Workspace 全体設定の確認 ここまでの切り分け作業で原因が特定できない場合、Google Workspace 全体のアプリケーション設定が障害原因と考えられます。 システム管理者の方に実施したトラブルシューティング内容を連絡し、システム設定を確認してもらいましょう。システム管理者の方は、公式ドキュメントを確認し Google Workspace の管理コンソールから設定を確認しましょう。 荒井 雄基 (記事一覧) クラウドソリューション部 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。 Google Cloud 認定資格 6冠 現在は Google Workspace を中心に企業の DX 推進をサポート。 最近頑張っていることは、子どもがハマっている戦隊モノの踊りを踊れるようになること。

G-genの山崎です。 Google Cloud (旧称 GCP) の Cloud Storage でフォルダ単位での権限管理が可能となるマネージドフォルダを用いた権限管理方法について、解説します。 Cloud Storage とは フォルダを用いたオブジェクトの管理 シミュレートされたフォルダとは マネージドフォルダとは マネージドフォルダでの権限管理 マネージドフォルダの使い方 マネージドフォルダでの権限管理による留意事項 Cloud Storage とは Cloud Storage は、データ容量が無制限、かつ耐久性の高いストレージサービスで、略称として GCS とも呼称されます ( G oogle C loud S torage の略) 。 Cloud Storage は、上記の特性から以下のような様々な用途で利用することができます。 システム間のデータ授受 データ分析における、未加工データ（データレイク） 各種データのバックアップ Cloud Storage 上、各種ファイルは、 バケット と呼ばれるデータを入れる箱の中に、 オブジェクト として、保存されます。 Cloud Storage の全体像について確認する場合は、以下の記事を参照いただければと思います。 blog.g-gen.co.jp フォルダを用いたオブジェクトの管理 Cloud Storage は以下の2種類のフォルダを用いて、オブジェクトを管理することができます。 シミュレートされたフォルダ マネージドフォルダ 明示的に指定しない場合、マネージドフォルダは作成されず、シミュレートされたフォルダが作成されます。それぞれのフォルダの違いについて、以降で述べていきます。 シミュレートされたフォルダとは シミュレートされたフォルダは「シミュレート」という名の通り、 Cloud Storage バケット内にフォルダの実体は存在しない 、仮想的なフォルダです。 例えば、以下のような形でオブジェクトを作成したとします。 bucket/folder1/file1.txt bucket/folder1/folder1-1/file1-1.txt bucket/folder2/file2.txt この場合、Google Cloud コンソール上は、以下のような階層構造で表示されます。 folder1の配下にfile1.txtとfolder1-1が存在する folder2の配下にfile2.txtが存在する これは、実体として「folder1」「folder2」といったフォルダが作成されている わけではなく 、オブジェクトのパスの中に 「/」 が含まれているため、Google Cloud コンソール上、 あたかもフォルダが存在するかのように表示 されているだけです。 参考 : フォルダの概要 シミュレートされたフォルダは、あたかもフォルダが存在するかのように表示されているだけであり、実体は存在しません。そのため、 フォルダ単位での権限管理を行うことはできません 。 フォルダ単位での権限管理を行いたい場合は、マネージドフォルダを使用する必要があります。 マネージドフォルダとは マネージドフォルダは、シミュレートされたフォルダと異なり、 リソースとしての実体が存在 します。また、 フォルダ単位での権限管理 が可能です。 ただし、マネージドフォルダを使用する際は、フォルダの命名や、フォルダの階層に制約が発生するため、公式ドキュメントで制約を確認の上、作成することを推奨します。 参考 : マネージド フォルダ マネージドフォルダでの権限管理 マネージドフォルダに対する権限付与は、バケットやプロジェクトに対して付与していた権限をフォルダに置き換えて実施していただければ、基本的には問題ありません。 権限の継承も通常の権限の付与と同様に行われるため、 権限を付与した マネージドフォルダ配下のオブジェクトに対しても権限が適用 されます。 なお、権限の継承の考え方については、以下の記事を参照いただければと思います。 blog.g-gen.co.jp マネージドフォルダでの権限管理での注意点は、マネージドフォルダに関する IAM 権限（フォルダ作成、削除、閲覧等）は、バケットやオブジェクトとは別であるという点です。マネージドフォルダに関する IAM 権限には、以下のようなものがあります。 storage.managedFolders.create storage.managedFolders.delete storage.managedFolders.get storage.managedFolders.list storage.managedFolders.getIamPolicy storage.managedFolders.setIamPolicy しかし、事前定義ロール（Storage オブジェクト閲覧者、Storage オブジェクト ユーザー 等）を用いてバケットやオブジェクトに対する権限管理をしている場合、それらのロールは、マネージドフォルダに関する権限も含んでいます。たとえば、「Storage オブジェクト閲覧者」ロールには storage.managedFolders.get と storage.managedFolders.list の権限が含まれています。 そのため、「シミュレートされたフォルダをマネージドフォルダに変更したら、フォルダが見えなくなった」といったトラブルの発生頻度は低いと考えてよいでしょう。 参考 : 事前定義ロール 参考 : マネージドフォルダの権限 マネージドフォルダの使い方 実際に、「folder1」をマネージドフォルダ化し、あるユーザーに対して、「folder1」配下に対して参照権限を付与した場合の挙動を確認していきます。 「folder1」の「︙」を押下し、「アクセス権の編集」を押下します。 アクセス権の編集を押下 マネージドフォルダの作成の確認ポップアップに対して、「マネージドフォルダをアタッチします」を押下します。 マネージドフォルダをアタッチ 「folder1」に対するアクセス権の編集ポップアップに対して、「プリンシパルを追加」を押下し、権限を付与したいアカウントに対して、権限を付与します。 アクセス権の編集 アカウントに対して権限付与 権限の付与が完了した後に、権限が付与されたユーザーで、権限が付与されたフォルダのURLを用いて、Google Cloud コンソールを確認したところ、「folder1」のみ参照ができ、「folder2」は表示されないことが確認できました。 権限が付与されたユーザーでの画面表示 folder1 また、「folder1-1」に移動すると、その配下の「file1-1.txt」の表示が確認でき、「folder1」に付与した権限が、配下のフォルダに対して、継承されていることが確認できます。 権限が付与されたユーザーでの画面表示 folder1-1 マネージドフォルダでの権限管理による留意事項 マネージドフォルダを用いることで、一つのバケットの中で、フォルダ単位で権限管理を行うことができるようになります。 一方で、バケットよりも細かい単位での権限管理となると、運用管理者からすると、管理が煩雑となる可能性もあります。 そのため、バケットやオブジェクトを誰と共有するかを整理の上、バケット単位での権限管理とするか、マネージドフォルダでの権限管理とするかを検討するプロセスを踏むことが重要となります。 参考 : おすすめのアクセス制御方法 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の武井です。Kubernetes（kubectl）がインストールされた環境で apt-get update （パッケージ更新情報取得コマンド）を実行したところ no longer has a Release file というエラーが発生しました。当記事で事象の原因と対策を説明します。 事象 状況 エラーの詳細 原因 推察 調査結果 対処方法 最後に 事象 状況 以下の環境で apt-get update コマンドを実行したところエラーが発生しました。GKE クラスタを管理するため kubectl がインストールされています。 # 環境情報 $ cat /etc/os-release PRETTY_NAME = " Debian GNU/Linux 11 (bullseye) " NAME = " Debian GNU/Linux " VERSION_ID = " 11 " VERSION = " 11 (bullseye) " VERSION_CODENAME =bullseye ID =debian HOME_URL = " https://www.debian.org/ " SUPPORT_URL = " https://www.debian.org/support " BUG_REPORT_URL = " https://bugs.debian.org/ " $ which kubectl /usr/bin/kubectl エラーの詳細 エラーメッセージは E: The repository 'https://apt.kubernetes.io kubernetes-xenial Release' no longer has a Release file. でした。 出力の詳細は以下のとおりです。 # 実施内容 $ sudo apt-get update Hit:2 https://download.docker.com/linux/debian bullseye InRelease Hit:3 https://deb.debian.org/debian bullseye InRelease Hit:4 https://deb.debian.org/debian bullseye-updates InRelease Hit:5 https://deb.debian.org/debian-security bullseye-security InRelease Hit:6 https://deb.debian.org/debian bullseye-backports InRelease Hit:1 https://packages.microsoft.com/repos/code stable InRelease Hit:8 https://packages.cloud.google.com/apt cloud-sdk InRelease Ign:7 https://packages.cloud.google.com/apt kubernetes-xenial InRelease Ign:9 https://storage.googleapis.com/cros-packages/ 123 bullseye InRelease Err:10 https://packages.cloud.google.com/apt kubernetes-xenial Release 404 Not Found [ IP: 142 . 250 . 206 . 238 443 ] Hit:11 https://storage.googleapis.com/cros-packages/ 123 bullseye Release Reading package lists... Done E: The repository ' https://apt.kubernetes.io kubernetes-xenial Release ' no longer has a Release file. N: Updating from such a repository can ' t be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details 原因 推察 エラーメッセージには apt.kubernetes.io リポジトリが存在しないと記されていることから、 apt-get update コマンド実行時にリポジトリに接続できなかったことが原因だと推察できます。 調査結果 エラーメッセージに記載のリンク ( https://apt.kubernetes.io ) を確認したところ、 apt.kubernetes.io および yum.kubernetes.io (legacy package repositories) が 2024年3月4日 に削除され、新たに pkgs.k8s.io に置き換わったとの記載がありました。 4th March 2024: The legacy package repositories have been removed. It's not possible to install Kubernetes packages from the legacy package repositories any longer 参考： Kubernetes Legacy Package Repositories Will Be Frozen On September 13, 2023 対処方法 以下のドキュメントにあるとおり、 /etc/apt/sources.list.d/kubernetes.list に記載のあるリポジトリを pkgs.k8s.io に変更することで解消します。 参考： How to migrate to the Kubernetes community-owned repositories? 参考： What are significant differences between the Google-hosted and Kubernetes package repositories? # 変更前 $ cat /etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main # 変更後 $ cat /etc/apt/sources.list.d/kubernetes.list deb [ signed-by = /etc/apt/keyrings/kubernetes-apt-keyring.gpg ] https://pkgs.k8s.io/core:/stable:/v1. 28 /deb/ / # 再実行 $ sudo apt-get update Hit:1 https://deb.debian.org/debian bullseye InRelease Get:3 https://deb.debian.org/debian bullseye-updates InRelease [ 44 . 1 kB ] Get:4 https://download.docker.com/linux/debian bullseye InRelease [ 43 . 3 kB ] Get:5 https://deb.debian.org/debian-security bullseye-security InRelease [ 48 . 4 kB ] Get:6 https://deb.debian.org/debian bullseye-backports InRelease [ 49 . 0 kB ] Get:2 https://packages.microsoft.com/repos/code stable InRelease [ 3 , 590 B ] Ign:8 https://storage.googleapis.com/cros-packages/ 123 bullseye InRelease Get:7 https://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1. 28 /deb InRelease [ 1 , 189 B ] Hit:9 https://packages.cloud.google.com/apt cloud-sdk InRelease Hit:10 https://storage.googleapis.com/cros-packages/ 123 bullseye Release Get:11 https://packages.microsoft.com/repos/code stable/main arm64 Packages [ 17 . 5 kB ] Get:12 https://packages.microsoft.com/repos/code stable/main amd64 Packages [ 16 . 8 kB ] Get:13 https://packages.microsoft.com/repos/code stable/main armhf Packages [ 17 . 4 kB ] Get:14 https://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1. 28 /deb Packages [ 13 . 9 kB ] Fetched 255 kB in 1s ( 259 kB/s ) Reading package lists... Done 最後に kubernetes をはじめ、apt のリポジトリは以下のファイルで管理されています。 今回のようにリポジトリに起因するエラーが発生した場合、まずはファイルに記載のリポジトリに接続できること、リポジトリが存在することをご確認ください。 # /etc/apt/sources.list ファイル $ cat /etc/apt/sources.list # Generated by distrobuilder deb https://deb.debian.org/debian bullseye main deb https://deb.debian.org/debian bullseye-updates main deb https://deb.debian.org/debian-security/ bullseye-security main # /etc/apt/sources.list.d ディレクトリ配下のファイルの例 $ pwd /etc/apt/sources.list.d $ ls -l total 20 -rw-r--r-- 1 root root 125 Apr 17 15:57 cros.list -rw-r--r-- 1 root root 131 Dec 15 17:30 docker.list -rw-r--r-- 1 root root 106 Oct 13 2023 google-cloud-sdk.list -rw-r--r-- 1 root root 108 May 7 19:50 kubernetes.list -rw-r--r-- 1 root root 203 Dec 13 18:37 vscode.list 武井 祐介 (記事一覧) 2022年4月にジョイン。クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2024 に選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei

G-gen の杉村です。Amazon Web Services（AWS）の Amazon S3 に対する EDoS 攻撃 の手法が話題になりました。同様に、Cloud Storage バケット名を知っていれば、EDoS 攻撃を仕掛けられるのでしょうか？ 背景 記事の内容と課金の原因 Cloud Storage では未認証リクエストは課金されない 課金が発生する設定状況 静的ウェブサイトホスティングを利用している データアクセス監査ログを有効化している 背景 2024年5月ころ、SNS で、Amazon Web Services（AWS）の Amazon S3 に対する EDoS 攻撃 の手法が話題になりました。EDoS とは Economic Denial of Service の略であり、意図的にクラウド利用料金を肥大化させるオペレーションを外部から仕掛ける攻撃のことです（現在では課金の仕様が修正され、この問題は起きなくなっています）。以下が、問題の記事のリンクです。 参考 : How an empty S3 bucket can make your AWS bill explode Google Cloud（旧称 GCP）において、Amazon S3 と同じ立ち位置である Cloud Storage（略称 GCS）では、バケット名を知ってさえいれば、この記事と同様の手法で EDoS 攻撃を仕掛けられるのでしょうか？ 結論からいうと、Cloud Storage の場合、記事で言及されたような未認証リクエストに対するリクエストという手法では 課金が発生しません 。ただし、課金が発生する可能性のある別の設定状況が存在します。当記事では、これらについて解説します。 記事の内容と課金の原因 前掲の参考記事によると、Amazon S3 バケットの名称を知ってさえいれば、同バケットに対してファイルの書き込みリクエストを投入することで、適切な権限がない場合でも、バケット所有者の AWS アカウントにリクエスト料金が発生していました。 2024年5月現在、スタンダードストレージの S3 バケットへのリクエストは、PUT リクエスト等が1,000回あたり$0.005、GET リクエスト等が1,000回あたり$0.0004（いずれもバージニア北部リージョン）です。同記事の場合は、1日に約1億の PUT リクエストがあったため、多額の課金が発生してました。 参考 : Amazon S3 の料金 この問題が明らかになってから2週間程度で、AWS はリクエスト数に対する課金の仕様を修正し、403（Access Denied）などのエラーになったリクエストは課金されなくなりました。つまり、現在ではもう、Amazon S3 のこの問題は発生しません。しかし同記事が発表された当時は、403 エラーとなったリクエストも課金対象でした。 参考 : Amazon S3 will no longer charge for several HTTP error codes 同記事の場合、とあるオープンソースツールでバックアップデータを S3 バケットに保存する設定になっており、バケット名を指定する箇所のデフォルト値が、同記事の著者の所有するバケット名でした。設定値をデフォルトから変えずにツールをデプロイしようとした人のリクエストは、認証エラーになるものの、すべて同著者のバケットに対して行われたことになります。 Amazon S3 の場合、認証が失敗したリクエストも課金対象 Cloud Storage では未認証リクエストは課金されない Google Cloud のオブジェクトストレージサービスである Cloud Storage ではどうでしょうか。Cloud Storage は、バケットに対するリクエスト数に応じた課金が存在する点で、課金体系が Amazon S3 と非常によく似ています。 Cloud Storage の場合、未認証リクエストに対するリクエストは 課金されません 。公式の料金ページに、以下のような記述があります。 注: 通常、307、4xx、5xx レスポンスを返すオペレーションは課金されません。ただし、ウェブサイトの構成が有効になっていて、NotFoundPage プロパティが一般公開オブジェクトに設定されているバケットが返す 404 レスポンスを除きます。 参考 : Cloud Storage の料金 つまり、前掲の記事と似た状況で、IAM での認証・認可が失敗している場合、リクエストは 4xx となりますので、課金は発生しません。 Cloud Storage の場合、認証が失敗したリクエストに課金は発生しない しかしながら、次に示すように、例外的に課金が発生する可能性のある状況は存在しえます。 課金が発生する設定状況 静的ウェブサイトホスティングを利用している Cloud Storage で静的ウェブサイトホスティングを利用している場合で、リクエストが 404 Not found となった際に表示するエラーページのファイルを明示的に指定している場合、このリクエストに対しては課金が発生します。これは、先程の料金ページからの引用部分の2文目が示しています。 注: 通常、307、4xx、5xx レスポンスを返すオペレーションは課金されません。ただし、ウェブサイトの構成が有効になっていて、NotFoundPage プロパティが一般公開オブジェクトに設定されているバケットが返す 404 レスポンスを除きます。 静的ウェブサイトホスティングとは、Cloud Storage に HTML ファイル等を配置し、ウェブサイトとして公開するための機能です。 参考 : 静的ウェブサイトをホストする このような公開サイトに対する大量アクセスは、手前の Cloud Load Balancing にフルマネージドの WAF である Cloud Armor を設置することで防ぐことができます。以下の記事もご参照ください。 blog.g-gen.co.jp データアクセス監査ログを有効化している Cloud Audit Logs において データアクセス監査ログ を明示的に有効化すると、Cloud Storage のオブジェクトに対する読み取り系のログも記録されるようになります。Cloud Storage のデータアクセス監査ログは、デフォルトでは記録されません。 blog.g-gen.co.jp データアクセス監査ログを有効にし、ログバケットへの取り込み量が月の無料枠である 50 GiB を超えると、$0.50/GiB（2024年5月現在）の「取り込み料金」が発生します。また、ログバケットへのログ保管期間が30日を超えると、$0.01/GiB/月の「保持料金」が発生します（デフォルトではデータアクセス監査ログは _Default ログバケットに保管され、保管期間が30日間となっているため、保持料金は発生しない ）。Cloud Audit Logs（Cloud Logging）の料金の仕様については、以下の記事を参照してください。 blog.g-gen.co.jp つまり、データアクセス監査ログが明示的に有効されている場合は、大量のアクセスにより Cloud Logging 料金が肥大化する可能性はあります。 ただし、手元の検証によると Cloud Storage バケットへの PERMISSION_DENIED ログの1エントリあたりのサイズは、概ね1.5KB〜2KBでした。1億回の PERMISSION_DENIED ログが出力された場合、概ね190GiBとなり、これは約$95.4であり、日本円にして14,310円です（150円換算）。この金額が事業継続の観点からクリティカルとなり得るかどうか、データアクセス監査ログの有効化を検討する際は、リスクの1つとして考慮に入れてもよいでしょう。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。当記事では Cloud Run のコールドスタートについて整理した結果や、対処方法についてご紹介します。 Cloud Run の概要 コールドスタートについて理解する コールドスタートとは Cloud Run のスケールイン・アウト コールドスタートが発生する理由 コールドスタートへの対策法 1. コンテナイメージや初期化処理を軽くする 2. 起動時の CPU ブースト 3. 最小インスタンス 4. 実行環境の選択 5. スケジュールベースでスケーリングを設定する Cloud Run の概要 Cloud Run とは、コンテナとしてパッケージされたアプリケーションを簡単に実行できる Google Cloud のフルマネージド型のサーバーレスプラットフォームサービスです。 インフラの管理はほぼ必要で、コンテナを実行するインスタンスは負荷に応じて自動的にスケールアウトし、処理をしていないときはインスタンス数を 0 までスケールインさせることも可能です。 その他 Cloud Run の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp コールドスタートについて理解する コールドスタートとは コールドスタート とは、新しいインスタンスが起動する際に実行される 初期化プロセスに伴う遅延 のことです。 初期化プロセスとは、「コンテナイメージのダウンロード」「アプリケーションの起動」「必要なライブラリのロード」といった、アプリケーションの起動に必要な一連のプロセスを指します。 コールドスタートは、Cloud Run が ゼロからスケーリング（スケールアウト）する際 や、リクエストの増加により コンテナインスタンスがスケールアウトする際 に発生します。コールドスタートが発生すると、ユーザーへのレスポンスが遅延し、体験の悪化に繋がります。 Cloud Run のスケールイン・アウト Cloud Run はリクエスト負荷に応じて、自動的に スケールイン と スケールアウト を行います。 ただし、すべてのリクエストを処理し終わった場合でも、インスタンスをすぐにシャットダウンすることはしません。これはコールドスタートの影響を最小限に抑えるための設計思想であり、一部のインスタンスを最大で 15 分間 、アイドル状態で確保することで、その後のリクエストに最小限の遅延で応答きるよう考慮されています。 参考： インスタンスをアイドル状態にしてコールド スタートを最小限に抑える コールドスタートが発生する理由 ゼロスケール状態で新たにリクエストを受け付けたり、リクエストの増加によりコンテナインスタンスのスケールアウトが起こると、コールドスタートが発生します。 コンテナが新たに起動され、「コンテナイメージのダウンロード」「アプリケーションの起動」「必要なライブラリのロード」といった処理が発生するためです。 コールドスタートへの対策法 1. コンテナイメージや初期化処理を軽くする コールドスタートによる遅延の長さは、コンテナの起動の初期化処理の長さに依存します。以下のような改善を検討することで、初期化処理を短くすることができます。 コンテナイメージに含まれるライブラリや依存関係を最小限にし、イメージサイズを小さくする グローバルスコープでの重い処理を避け、実際に必要になったタイミングで初期化する（遅延初期化） 参考 : 全般的な開発のヒント ‐ パフォーマンスの最適化 2. 起動時の CPU ブースト 起動時の CPU のブースト 機能は、インスタンスの起動時間中とインスタンス開始後の 10 秒間に追加の CPU を提供するもので、コールドスタートによる遅延軽減に有効です。 設定も簡単で、以下の公式ガイドに沿って設定するだけで起動時の CPU ブーストを利用可能です。CPU ブーストを使うと、最長で10秒間分の追加料金が発生します。 参考： 起動時の CPU ブーストを設定する 詳細は以下の記事で解説していますので、あわせて参照してください。 blog.g-gen.co.jp 3. 最小インスタンス Cloud Run は、リクエストを処理していないインスタンス（アイドル状態）を最大15分経過後に削除します。 最小インスタンス を 1 以上 の数で設定すると、アイドル状態のインスタンスを常に確保してゼロスケール状態になるのを防ぐため、コールドスタートの改善が見込めます。 ただし、アイドル状態のインスタンスに対しても、Cloud Run の料金が発生しますので、事前に料金の見積もりが必要です。 参考： 最小インスタンス数（サービス） 参考： サービスレベルの最小インスタンス数の設定と更新 4. 実行環境の選択 Cloud Run の実行環境には 第1世代 と 第2世代 があり、前者は後者に比べ、コールドスタートの遅延が短い傾向にあります。 ただし各世代にはそれぞれ適切なユースケースがあり、例えば NFS ボリュームのマウントは、第1世代では対応していません。 参考 : サービスの NFS ボリューム マウントを構成する 第1世代で問題ないユースケースでは、コールドスタートによる遅延軽減が見込めます。 参考： 実行環境の選択方法 参考： 実行環境の設定と更新 5. スケジュールベースでスケーリングを設定する Cloud Run の最小インスタンス数を、特定の時間帯で自動的にスケーリングさせる処理を実装していきます。 Cloud Scheduler と Cloud Run functions を用いて、リクエスト数が増加すると見込まれる時間帯に最小インスタンス数を増やし、リクエストが減ると考えられる時間帯に最小インスタンス数を減らすことで、コストを最適化したまま、コールドスタートによる遅延の発生を抑止することができます。 詳細は以下の記事を参照してください。 blog.g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2025 選出。 趣味はロードレースやサッカー観戦、あとはゴルフと筋トレ。 Follow @ggenyutakei

G-gen の佐々木です。当記事では、Cloud Run の最小インスタンス数を、特定の時間帯で自動的にスケーリングさせる処理を実装していきます。 前提知識 Cloud Run について Cloud Run のコールドスタート サービスレベルの最小インスタンス数の設定 構成 スケーリングの対象となる Cloud Run サービスのデプロイ 各種ファイルの準備 作成するファイルについて Cloud Run functions にデプロイするファイル ディレクトリの作成 main.py requirements.txt Cloud Scheduler で使用するファイル scaleout.json scalein.json 各種サービスの作成 シェル変数の設定 Pub/Sub トピック サービスアカウント Cloud Run functions 用サービスアカウント Pub/Sub 用サービスアカウント Cloud Run functions Cloud Scheduler ジョブ 作成するジョブについて スケールアウト用ジョブ スケールイン用ジョブ 動作確認 前提知識 Cloud Run について Cloud Run には Cloud Run services と Cloud Run jobs、そして Cloud Functions から統合された Cloud Run functions の3種類がありますが、当記事における Cloud Run は Cloud Run services を指すものとし、また Cloud Run functions についてはそのまま Cloud Run functions と記載します。 当記事は Cloud Run の応用的な使い方を解説するため、Cloud Run そのものに関する解説はしません。 Cloud Run の解説については以下の記事をご一読ください。 blog.g-gen.co.jp Cloud Run のコールドスタート 最小インスタンス数を0に設定した Cloud Run では、リクエストを受信するとコンテナインスタンスが起動し、処理を行います。 このように最小インスタンス数が0の場合、リクエストがない間は CPU、メモリなどのコンピュートリソースを使用しないため、リソース使用量に応じた料金が発生せず、コストを非常に安く抑えることができます。 その反面、常にコンピュートリソースを使用する場合と比べて、インスタンスを起動する時間だけレイテンシが発生します。これを コールドスタート といいます。 Cloud Run におけるコールドスタート Cloud Run で実行しているアプリケーションでコールドスタートによるレイテンシが許容できない場合、最小インスタンス数を 1以上 に設定し、リクエストを処理できるコンピュートリソースを常に確保しておきます。 この場合、当然ながらコンピュートリソースの料金は、最小インスタンスの数だけ常に発生してしまいます。 最小インスタンス数が0の場合と1以上の場合のコンピュートリソース使用料 また、コールドスタートを回避できるのは、最小インスタンス数として設定した数のコンテナインスタンス（常時起動されているインスタンス）だけです。 リクエストの増加によりコンテナインスタンスのスケールアウトが起こると、新たに起動したコンテナインスタンスに送信されたリクエストはコールドスタートの影響を受けます。 したがって、多くのリクエストを処理しなければならない、かつコールドスタートが許容できないアプリケーションでは、予測されるリクエストの規模に応じて最小インスタンス数を調整する（もしくは Cloud Run を使用しない）ことになります。 このように、Cloud Run におけるコストの削減とコールドスタートの回避はトレードオフの関係にあり、アプリケーション実行基盤として Cloud Run を選択する際のノックアウトファクターとなり得ます。 参考： Cloud Run pricing サービスレベルの最小インスタンス数の設定 従来の Cloud Run では、最小インスタンス数はリビジョンレベルで設定を行い、最小インスタンスを変更するたびに新たなリビジョンをデプロイする必要がありました。 リビジョンレベルで最小インスタンス数を更新する しかし、2024年3月のアップデートにて、 サービスレベルの最小インスタンス数の設定 として、新たなリビジョンをデプロイすることなく最小インスタンス数の設定を変更できるようになりました。 サービスレベルで最小インスタンス数を更新する 参考： Minimum instances (services) 構成 当記事では、Cloud Run の最小インスタンス数に対して、スケジュールベースの自動スケーリングを行う処理を実装していきます。 ユースケースとして、特定の時間帯にリクエストが増加することがわかっているサービスを想定します。 リクエストが増加する時間帯は Cloud Run の最小インスタンス数を増加させることでコールドスタートの影響を無くし、リクエストが少ない時間帯は最小インスタンス数を0にしてコストを節約します。 当記事では、以下のように時間帯によって最小インスタンス数を変更するようにします。 この場合、スケールアウトは 12:00 、スケールインは 19:00 に行います。 時間帯 最小インスタンス数 0:00~12:00 0 12:00~19:00 3 19:00~0:00 0 実装には、以下のサービスを使用していきます。 Cloud Scheduler Cloud Pub/Sub Cloud Run functions 使用するサービスと構成図 スケーリングの対象となる Cloud Run サービスのデプロイ まず、スケジュールベースのスケーリングを設定する対象となる Cloud Run サービスを作成します。 当記事では、このサービス自体の処理内容は重要ではないので、Google Cloud が提供するサンプルのコンテナイメージを使用してデプロイします。 # スケーリングの対象となる Cloud Run サービスを作成 $ gcloud run deploy hello \ --image us-docker.pkg.dev/cloudrun/container/hello \ --region = ${LOCATION} \ --allow-unauthenticated このコマンドでサービスをデプロイした場合、サービス名は hello となります。 最小インスタンス数は、デフォルトで0に設定されています。 各種ファイルの準備 作成するファイルについて 当記事では、ワーキングディレクトリに以下のファイルを作成していきます。 . ├── scalein.json ├── scaleout.json └── src ├── main.py └── requirements.txt Cloud Run functions にデプロイするファイル ディレクトリの作成 Cloud Run functions にデプロイする各種ファイルを配置するディレクトリを作成します。 ディレクトリ名はなんでもよいですが、当記事では src とします。 # src ディレクトリを作成 $ mkdir src main.py 当記事では Python 3.12 を使用していきます。 # Python のバージョン $ python -V Python 3 . 12 . 0 src ディレクトリ内に main.py ファイルを作成します。 ファイルの中身は以下のようにします。 # src/main.py from google.cloud.run_v2.services.services import ServicesClient import functions_framework import base64, json client = ServicesClient() @ functions_framework.cloud_event def update_service (cloud_event): # Cloud Scheduler から送信されてきたメッセージを処理 data = json.loads(base64.b64decode(cloud_event.data[ "message" ][ "data" ]).decode()) project_id = data[ "project_id" ] location = data[ "location" ] service_name = data[ "service_name" ] min_instance_count = int (data[ "min_instance_count" ]) # スケーリング対象の Cloud Run サービスの情報を取得 service = client.get_service(name=f "projects/{project_id}/locations/{location}/services/{service_name}" ) # Cloud Run サービスの最小インスタンス数を更新 service.scaling.min_instance_count = min_instance_count # リビジョンを更新せず、サービスに対して最小インスタンス数を設定 # Cloud Run サービスの更新 client.update_service(service=service) main.py には、Cloud Scheduler から（Pub/Sub を介して）スケーリング対象の Cloud Run サービスの名前や、スケーリング後の最小インスタンス数などの情報を受け取り、それを元に最小インスタンス数を変更する処理を実装します。 requirements.txt src ディレクトリ内に requirements.txt を作成し、使用する外部ライブラリを記載します。 当記事では以下のライブラリを使用していきます。 # src/requirements.txt functions-framework== 3.5 . 0 google-cloud-run== 0.10 . 5 Cloud Scheduler で使用するファイル Cloud Scheduler のジョブを作成する際に使用する、Cloud Run functions に送信するメッセージを記述したファイルを作成します。 最小インスタンス数のスケールアウトとスケールインのそれぞれに対応したファイルを作成していきます。 scaleout.json ワーキングディレクトリ内に scaleout.json を作成し、以下のように記述します。 { " project_id ":" {Cloud Runが存在するプロジェクトID} ", " location ":" asia-northeast1 ", " service_name ":" hello ", " min_instance_count ":" 3 " } このメッセージを受信した Cloud Run functions は、対象となる Cloud Run サービスの最小インスタンス数を 3 に変更します。 scalein.json ワーキングディレクトリ内に scalein.json を作成し、以下のように記述します。 { " project_id ":" {Cloud Runが存在するプロジェクトID} ", " location ":" asia-northeast1 ", " service_name ":" hello ", " min_instance_count ":" 0 " } このメッセージを受信した Cloud Run functions は、対象となる Cloud Run サービスの最小インスタンス数を 0 に変更します。 各種サービスの作成 シェル変数の設定 シェル変数として、 PROJECT 変数にサービスを作成するプロジェクト、 LOCATION 変数にサービスを作成するリージョンを設定しておきます。 当記事では asia-northeast1 リージョンを使用していきます。 PROJECT =myproject LOCATION =asia-northeast1 Pub/Sub トピック Cloud Scheduler からのメッセージを中継する Pub/Sub のトピックを作成します。 当記事では topic-run-scaler という名前で作成します。 # Pub/Sub トピックの作成 $ gcloud pubsub topics create topic-run-scaler サービスアカウント Cloud Run functions 用サービスアカウント Cloud Run functions に紐付けるサービスアカウントを作成します。 当記事では sa-run-scaler という名前で作成します。 # Cloud Run functions 用サービスアカウントの作成 $ gcloud iam service-accounts create sa-run-scaler サービスアカウントに対して、Cloud Run の設定を変更するための roles/run.developer ロールを設定します。 # サービスアカウントに Cloud Run の編集権限を付与 $ gcloud run services add-iam-policy-binding hello \ --region = ${LOCATION} \ --member =" serviceAccount:sa-run-scaler@ ${PROJECT} .iam.gserviceaccount.com " \ --role =" roles/run.developer " また、Cloud Run functions のコードからサービスアカウントの認証情報を取得できるように、 roles/iam.serviceAccountUser ロールも設定します。 # サービスアカウントにサービスアカウントユーザー権限を付与 $ gcloud projects add-iam-policy-binding ${PROJECT} \ --member =" serviceAccount:sa-run-scaler@ ${PROJECT} .iam.gserviceaccount.com " \ --role =" roles/iam.serviceAccountUser " Pub/Sub 用サービスアカウント Cloud Scheduler と Cloud Run functions を中継する Pub/Sub 用のサービスアカウントを作成します。 このサービスアカウントには Cloud Run を呼び出すための権限を付与しますが、対象の Cloud Run がまだ作成されていないので、一旦は作成だけしておきます。 当記事では sa-run-scaler-trigger という名前で作成します。 # Pub/Sub 用 サービスアカウントの作成 $ gcloud iam service-accounts create sa-run-scaler-trigger Cloud Run functions src ディレクトリ内のファイルを使用して Cloud Run functions の関数をデプロイします。関数の名前は run-scacler とします。 関数のトリガーとして先ほど作成した Pub/Sub トピックを設定し、Pub/Sub 用に作成したサービスアカウントも --trigger-service-account として指定します。 # Cloud Run functions のデプロイ $ gcloud functions deploy run-scaler \ --gen2 \ --runtime = python312 \ --entry-point =" update_service " \ --region = ${LOCATION} \ --source = ./src \ --run-service-account =" sa-run-scaler@ ${PROJECT} .iam.gserviceaccount.com " \ --trigger-topic = topic-run-scaler \ --trigger-service-account =" sa-run-scaler-trigger@ ${PROJECT} .iam.gserviceaccount.com " Cloud Run functions のデプロイが完了したら、Pub/Sub 用のサービスアカウントに Cloud Run functions を呼び出す権限を付与します。 gCloud Run functions add-invoker-policy-binding コマンドを使用することで、必要な権限を付与することができます。 # サービスアカウントに Cloud Run functions の起動元権限を付与 $ gcloud functions add-invoker-policy-binding run-scaler \ --region = ${LOCATION} \ --member =" serviceAccount:sa-run-scaler-trigger@ ${PROJECT} .iam.gserviceaccount.com " Cloud Scheduler ジョブ 作成するジョブについて Cloud Run functions のトリガーとなる Cloud Scheduler ジョブを作成していきます。 スケールアウトとスケールインで異なる設定値が必要になるため、ジョブは2つ作成します。 Cloud Run functions は Cloud Scheduler から送信されたメッセージの内容に応じた処理を行うため、各ジョブは同一の Pub/Sub を経由して、同一の Cloud Run functions 関数にメッセージを送ります。 スケールアウト用ジョブ スケールアウト用のジョブは scaleout.json ファイルに記述したメッセージを送信するように設定します。 このメッセージを受信した Cloud Run functions は、対象となる Cloud Run サービスの最小インスタンス数を 3 に変更します。 ジョブの実行タイミングは --schedule に unix-cron 文字列形式で設定します。 当記事では、毎日12時（ 0 12 * * * ）のタイミングでスケールアウトを実行するようにします。 # Cloud Run のスケールアウト用のジョブをトリガーするスケジュール $ gcloud scheduler jobs create pubsub schedule-run-scaler-scaleout \ --location = ${LOCATION} \ --schedule =" 0 12 * * * " \ --topic = topic-run-scaler \ --message-body-from-file = ./scaleout.json \ --time-zone =" Asia/Tokyo " スケールイン用ジョブ スケールイン用のジョブは scalein.json を使用して作成します。 このファイルに記述したメッセージを受信した Cloud Run functions は、対象となる Cloud Run サービスの最小インスタンス数を 0 に変更します。 ジョブの実行タイミングは、毎日19時（ 0 19 * * * ）に設定します。 # Cloud Run のスケールイン用のジョブをトリガーするスケジュール $ gcloud scheduler jobs create pubsub schedule-run-scaler-scalein \ --location = ${LOCATION} \ --schedule =" 0 19 * * * " \ --topic = topic-run-scaler \ --message-body-from-file = ./scalein.json \ --time-zone =" Asia/Tokyo " 動作確認 Cloud Run のコンソールから「コンテナ インスタンス数」の指標を確認すると、設定した時間にジョブが実行され、Cloud Run サービスの最小インスタンス数の変更が行われていることがわかります。 コンテナインスタンス数の推移 12:00 にスケールアウトのジョブが実行され、最小インスタンス数が3に設定されています。 3つのコンテナインスタンスが常に idle もしくは active になっており、この3つで処理できるリクエスト量であれば、コールドスタートの影響を受けることはありません。 19:00 にスケールインのジョブが実行され、翌日の 12:00 までは最小インスタンス数が 0 になります。 idle もしくは active 状態のインスタンスがないときにリクエストがあると、そのリクエストに対する処理はコールドスタートの影響を受けますが、コンピュートリソースの使用コストを最小限に抑えることができます。 「課金対象のコンテナ インスタンス時間」の指標を確認すると、最小インスタンス数が3（1以上）になっている時間帯のみ、インスタンスのリソース使用料が発生し続けていることがわかります。 最小インスタンス数が1以上の時間帯のみインスタンスが課金対象となっている 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805