G-gen の三浦です。当記事では Cloud NGFW （旧称 Cloud Firewall）の IPS 機能について検証した結果をご紹介します。 概要 Cloud NGFW とは IPS とは 検証の概要 前提 構成図 検証の流れ EICAR ファイル 検証環境の構築 セキュリティプロファイルの作成 セキュリティプロファイルグループの作成 ファイアウォールエンドポイントの作成 ファイアウォール ポリシーの作成 攻撃検知の検証 パターン1（EICAR ファイル） パターン2（/etc/passwd ディレクトリ） ブロックの検証 IPS の設定変更 パターン1（EICAR ファイル） パターン2（/etc/passwd ディレクトリ） 概要 Cloud NGFW とは Cloud Next Generation Firewall は、Google Cloud（旧称 GCP）の Virtual Private Cloud（以下、VPC）で利用可能な、フルマネージドのファイアウォールサービスです。 サービス名は、公式ドキュメント等でも Cloud NGFW と省略されているため、当記事でも以後、Cloud NGFW と表記します。なお、Cloud NGFW はかつて Cloud Firewall という名称でしたが、2024年4月に改称され、Cloud NGFW になりました。 Cloud NGFW には無償の Essentials と有償の Standard、Enterprise の3つのティアが存在し、当記事で紹介する IPS 機能は Enterprise ティアでのみ利用可能です。 参考 : Cloud NGFW の概要 Cloud NGFW の詳細や各ティアの詳細については弊社ブログで解説しておりますのでそちらをご参照ください。   blog.g-gen.co.jp IPS とは IPS （Intrusion Prevention System）とは、ネットワークトラフィックを監視し、ネットワーク内で悪意のある攻撃を検知した際にブロックをする侵入防止システムです。 IPS という用語は Google Cloud に特有のものではなく、ネットワークセキュリティツールの一般的な名称です。 Cloud NGFW の IPS 機能は Intrusion prevention service とも表記され、日本語ドキュメントでは「 侵入防止サービス 」と表記されることがあります。IPS、Intrusion Prevention System、Intrusion prevention service、侵入防止サービスといった用語は、Cloud NGFW の背景では、同じものを指すと考えて構いません。 参考 : 侵入防止サービスの概要 なお、類似の用語で IDS（Intrusion Detection System）があります。こちらは IPS と同様に悪意のある攻撃の検知が可能ですが、ブロックはせず、検知のみです。 Google Cloud では Cloud IDS というサービスを提供しています。詳細は当社の記事で解説しています。 blog.g-gen.co.jp 検証の概要 前提 Cloud NGFW の IPS 機能を利用するためには、プロジェクトが組織（Organization）に所属している必要があります。 組織（Organization）の詳細は当社の記事で解説しているのでご参照ください。 blog.g-gen.co.jp 構成図 今回は、以下の構成図の環境で検証を行いました。 検証の流れ 検証の流れは、以下のとおりです。まず前半に、IPS の設定を「検知のみ」にし、ログ記録が行われることを確認します。後半では、実際に攻撃をブロックしたり、偽陽性トラフィックを明示的に許可する検証を行います。 検知の検証 IPS をセットアップ。拒否はせずに検知のみの設定とする クライアントから Web サーバーへ以下2パターンのアクセスを実施。Web サーバーからの応答があることを確認 パターン1 : テストファイル（EICAR）へアクセス パターン2 : /etc/passwd ディレクトリへアクセス ログを確認し、両パターンの通信が IPS で検知されていることを確認 ブロックの検証 検知したアクセスパターンを以下のように仮定する パターン1は誤検知（偽陽性）と仮定し、 明示的に許可 する パターン2は攻撃トラフィックでと仮定し、 拒否 する 重大度「中」以上の脅威（パターン2を含む）を検知した場合は「拒否」、パターン1のシグネチャを「許可」するように設定変更 再度 Web サーバーへのアクセスを試行。パターン2のみが「拒否」されることを確認 EICAR ファイル Compute Engine VM 上で Web サーバーを起動し、 EICAR ファイル （マルウェアの検出テスト用ファイル）を配置します。curl コマンドでその EICAR ファイルへのリクエストを実施することで、IPS の動作を確認します。 EICAR は無害なテキストファイルですが、各社のアンチウイルスソフト等でウイルスとして検知されるようになっています。Cloud NGFW の IPS 機能でも検知されるため、今回の検証に利用しました。 参考 : Eicar e.V. -  Institute for Computer Anti-Virus Research 検証環境の構築 セキュリティプロファイルの作成 本手順は、組織レベルで実施します。Google Cloud Web コンソールへログインし、対象の組織へ遷移します。 ネットワーク セキュリティ > 共通コンポーネント > セキュリティ プロファイルへ移動し、「プロファイルを作成」を押下します。 任意の名前を入力し「続行」を押下します。 各重大度のアクションを「アラート」に設定し、「作成」を押下します。本設定により、ブロックはせずに検知のみの設定となります。 選択可能なアクションについては、以下のドキュメントをご参照ください。 参考： 脅威防止のセキュリティ プロファイル セキュリティプロファイルグループの作成 本手順も、前項と同様に組織レベルで実施します。 ネットワーク セキュリティ > 共通コンポーネント > セキュリティ プロファイル > セキュリティ プロファイルグループ へ移動し、「プロファイル グループ作成」を押下します。 任意の名前を入力し、脅威防止プロファイルの箇所に前手順で作成した「セキュリティ プロファイル」を選択した上で「作成」を押下します。 ファイアウォールエンドポイントの作成 本手順も、前項と同様に組織レベルで実施します。 ネットワーク セキュリティ > Cloud NGFW > ファイアウォール エンドポイント へ移動し、「作成」を押下します。 以下項目を設定し、「続行」を押下します。 リージョンとゾーン：Webサーバ と同じ値を選択 名前：任意の値を入力 課金プロジェクト：対象のプロジェクトを選択 「エンドポイントの関連付けを追加」から IPS を導入するプロジェクトと VPC 名を選択し、「作成」を押下します。 作成には、20〜30分程度かかります。 ファイアウォール ポリシーの作成 本手順も、前項と同様に組織レベルで実施します。 ネットワーク セキュリティ > Cloud NGFW > ファイアウォール ポリシー へ移動し、「ファイアウォール ポリシー作成」を押下します。 任意のポリシー名を入力し、「続行」を押下します。 「ルールを追加」から、ファイアウォールルールを作成します。 優先度：一意の数値 一致したときのアクション：L7 の検査に進む（前手順で作成したセキュリティ プロファイルグループを選択） 送信元：IPv4、IP 範囲：0.0.0.0/0 「追加」を押下し、ファイアウォール ポリシーを適用する組織名を選択し、「追加」を押下します。 「作成」をクリックします。 攻撃検知の検証 パターン1（EICAR ファイル） テスト用の端末から curl コマンドを実行して、EICAR ファイルの取得を試行します。重大度のアクションが「アラート」のため、検知はされますが、実際の拒否は行われないのが想定される結果です。 $ curl -v http:// $TESTIP /eicar.com 〜省略〜 < X5O!P%@AP [ 4 \PZX54(P^)7CC) 7 } $EICAR -STANDARD-ANTIVIRUS-TEST-FILE ! $H +H* * Connection # 0 to host ***.***.***.*** left intact $ 対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、以下4点を確認します。 アラートの重大度が「MEDIUM」となっていること。 脅威の名前が「Eicar File Detected」となっていること。 脅威 ID（後続の手順で使用するため、メモしておきます。） アクションが「ALERT」となっていること。 パターン2（/etc/passwd ディレクトリ） 同様に curl コマンドを実行して、/etc/passwd ディレクトリへのアクセスを試行します。重大度のアクションが「アラート」のため、検知はされますが、実際の拒否は行われないのが想定される結果です。 $ curl -v http:// $TESTIP /etc/passwd 〜省略〜 < < !DOCTYPE HTML PUBLIC " -//IETF//DTD HTML 2.0//EN "> < html >< head > < title > 404 Not Found < /title > < /head >< body > < h 1> Not Found < /h 1> < p > The requested URL was not found on this server. < /p > < hr > < address > Apache/ 2 . 4 . 59 ( Debian ) Server at XX.XX.XX.XX Port 80 < /address > < /body >< /html > * Connection #0 to host XX.XX.XX.XX left intact $ 対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、以下3点を確認します。 アラートの重大度が「HIGH」となっていること。 脅威の名前が「HTTP /etc/passwd Access Attempt」となっていること。 アクションが「ALERT」となっていること。 ブロックの検証 IPS の設定変更 本手順は組織レベルで実施します。 ネットワーク セキュリティ > 共通コンポーネント > セキュリティ プロファイルへ移動し、前手順で作成したプロファイルを選択します。 「編集」から重大度「重大」「高」「中」のアクションを「拒否」へ変更し、「ID で署名を追加」を押下します。初回アクセス検証で確認した通り、パターン1（MEDIUM = 「中」）、パターン2（HIGH = 「高」）のため、この時点では両通信共に「拒否」されます。 本検証では重大度「低」「情報」に関しては、影響が小さいと判断し「アラート」のままとしていますが、実業務でどのような設定とするかは、以下ドキュメントをご参照の上で判断してください。 参考 : 脅威の重大度 初回アクセス検証「パターン1」で確認した脅威 ID を入力し、アクションを「許可」に設定し、「署名の追加」を押下します。 「保存」を押下します。 なお 署名 とは一般的に シグネチャ とも表現されます。シグネチャは、脆弱性、スパイウェア、ウイルス、特定の DNS クエリなどを検知するためのルールのことです。 以下ドキュメントの通り、署名に対するアクションは重大度のアクションよりも優先されるため、上記の設定を追加することでパターン1が「許可」されます。偽陽性となった特定のシグネチャを無視する際に、本機能を利用できます。 脅威 ID の一覧は、Palo Alto Networks 社のサイト「 Threat Vault 」へログインすることで確認可能です。同サイトでは、特定の CVE 番号に関連する脅威 ID の検索等も可能です。同サイトを利用するには、別途 Palo Alto Networks のアカウント作成が必要となります。これは、Cloud NGFW の IPS 機能が、バックエンドで Palo Alto 社の技術を利用していることに起因します。 参考： 脅威シグネチャの概要 参考： Threat Vault パターン1（EICAR ファイル） テスト用の端末から curl コマンドを実行して、EICAR ファイルの取得を試行します。重大度「中（MEDIUM）」のアクションを「拒否」に変更していますが、脅威 ID を「許可」に設定しているため、 ブロックされず 、 ログも記録されない のが想定結果です。 $ curl -v http:// $TESTIP /eicar.com 〜省略〜 < X5O!P%@AP [ 4 \PZX54(P^)7CC) 7 } $EICAR -STANDARD-ANTIVIRUS-TEST-FILE ! $H +H* * Connection # 0 to host ***.***.***.*** left intact $ 対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、検証時のログが存在しないことを確認します。 パターン2（/etc/passwd ディレクトリ） 同様に curl コマンドを実行して、/etc/passwd ディレクトリへのアクセスを試行します。重大度「HIGH（高）」のアクションを「拒否」に変更しているため、拒否されるのが想定結果です。 もし Web サーバーから 404エラー等の応答があった場合、設定の反映に時間がかかっている可能性があるため、5〜10分程度、時間を空けて再実行してください。 $ curl -v http:// $TESTIP /etc/passwd 〜省略〜 > * Recv failure: Connection reset by peer * Closing connection 0 curl: ( 56 ) Recv failure: Connection reset by peer $ 対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、以下3点を確認します。 アラートの重大度が「HIGH」となっていること。 脅威の名前が「HTTP /etc/passwd Access Attempt」となっていること。 アクションが「DROP」となっていること。 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。オンプレ中心のネットワークエンジニアからクラウドエンジニアへ移行。日々勉強中です・・・

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 推進をサポート。 最近頑張っていることは、子どもがハマっている戦隊モノの踊りを踊れるようになること。

G-gen の神谷です。今回、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 で分析することで、個人の強みを活かしつつ、チームとしての総合力を高めることができます。 神谷 乗治 (記事一覧) クラウドソリューション部 クラウドエンジニア。2017 年頃から Google Cloud を用いたデータ基盤構築や ML エンジニアリング、データ分析に従事。クラウドエース株式会社システム開発部マネージャーを経て現職。Google Cloud Partner Top Engineer 2023,2024、Google Cloud Champion Innovators（Database）、 著書：「GCPの教科書III【Cloud AIプロダクト編】」 　

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