G-gen の武井です。本記事は Google Cloud Next '24 in Las Vegas の1日目に行われた Breakout Session「 Build an integrated DevSecOps solution with GitLab and Google Cloud 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Better Together: Benefits and Features Workload Identity Federation Demonstration 関連記事 セッションの概要 本セッションでは GitLab と Google Cloud による DevSecOps ソリューションの紹介が一部デモを交えて紹介されました。 Better Together: Benefits and Features セッションの冒頭では、GitLab と Google Cloud との親和性の高さや利便性、双方が連携するうえでのセキュリティの高さを紹介していました。 Workload Identity Federation CI/CD パイプラインを構成して一連のジョブを実行するアプリケーション GitLab runner では、Google Cloud との連携にサービスアカウントキーを必要としないセキュアな連携手法 Workload Identity Federation が利用可能であると紹介されました。 Demonstration セッションでは以下についてデモを交えた紹介がありました。 GitLab と Google Cloud の Workload Identity 連携 GitLab runner によるリソースデプロイ 公式ドキュメント やセットアップスクリプトに加え、コンソール画面上から簡単な操作でセットアップ可能なメニューも揃っており、どなたでも簡単にご利用いただけるのではないかという印象を受けました。 関連記事 blog.g-gen.co.jp 武井 祐介 (記事一覧) 2022年4月にジョイン。クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2024 に選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei

G-gen 又吉です。本記事は Google Cloud Next '24 in Las Vegas の1日目のキーノートで発表された Vertex AI Agent Builder (Vertex AI Agents) を触ってみたのでご紹介します。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 概要 Agent とは Vertex AI Agent Builder とは 料金 概要 試算例 Vertex AI Agents 概要 Agents の構成要素 Goal Instructions Examples Tools 概要 Built-in tools OpenAPI tools Data store tools 触ってみた 関連記事 概要 Agent とは 生成 AI アプリケーションにおける Agent とは、人間の代わりに生成 AI が、目的を達成するために様々な機能 (ツール) を用いて情報を収集しアクションを実行することができるシステムのことを指します。 例えば、「Google 検索を実行できるツール」と「社内情報を検索できるツール」を持った Agent を例にみてみましょう。 通常 LLM は、過去のトレーニングデータで学習されているため最新情報に回答することはできませんが、「今の日本の総理大臣は？」というユーザーからの質問が来たことを想定してみます。 Agent は適切な回答を生成するために、どのツールを用いた方がいいのか自ら考え実行し回答を生成します。今回の場合ですと、最新情報に回答するために「Google 検索を実行できるツール」を用いて 最新情報を取得し回答を生成 することができます。 Agent 使用例 Agent を応用することで、今まで人が介入していた複雑な処理を生成 AI アプリで代替していくことが期待できます。 Vertex AI Agent Builder とは Vertex AI Agent Builder では、このような Agent 開発をサポートするサーバーレスかつフルマネージドなサービスです。また、ノーコード・ローコードで Agent 開発ができる点も大変魅力的です。 Vertex AI Agents では、Agent の開発からテスト、デプロイはもちろんのこと、会話履歴の管理や Agent のバージョン管理まで、Agent 開発をスムーズに進められる環境が多数揃っています。 Vertex AI Agent Builder は、旧来は「Vertex AI Search and Conversation」と呼ばれていました。しかし 2024 年の Google Cloud Next のタイミングで Vertex AI Agent Builder と改称されました。Vertex AI Agent Builder の中に、エンタープライズサーチを実現する Vertex AI Search と、エージェントを実現する Vertex AI Agents の2機能が内包されています。 Vertex AI Agent Builder の名称の変遷 当記事では主に Vertex AI Agents の内容を紹介します。それ以外を含む Vertex AI Agent Builder の詳細な解説記事は、以下をご参照ください。 blog.g-gen.co.jp 料金 概要 Vertex AI Agent Builder の料金は、公式ページだと Agent に対して $12/1000クエリ と記載されています。ただし、プレビュー期間中の料金については以下の注意書きもあるため、さっそく触ってみたいと考えている方は確認したほうが良いかも知れません 2024年4月現在、Vertex AI Agents の課金はプレビューとなってますため、詳細は Google 担当営業にお問い合わせ下さい。 Vertex AI Agent Builder - Pricing 試算例 Vertex AI Agent Builder で作成した Agent アプリに対し、一月あたり 10,000 クエリのリクエストが発生することを想定します。尚、ツールは Vertex AI Search のみが設定され、すべてのクエリに対しツールを1回利用することを想定します。 # Agent 月額コスト 10,000 クエリ × ($12 / 1,000 クエリ) = $120 # ツール月額コスト 10,000 クエリ/月 × ($2 / 1,000 クエリ) = $20 # 月額合計 $120 + $20 = $140 Vertex AI Agents 概要 Vertex AI Agents とは、Agent の開発はもちろん、テスト、デプロイができる Agent に特化した統合開発環境のようなツールです。 ユーザーインターフェイスとしては、以下のような機能を提供しています。 機能名 説明 Agents Agent の構成要素を管理 Tools Agent が利用するツールを管理 Test cases シミュレータで作成されたテストケースの管理・実行 Conversation history Agent の会話履歴を管理 Integrations Slack や Google Chat 等のインテグレーション管理 Prebuilt agents 人気のある Agent のサンプル集 Change history Agent の変更履歴 Agent settings Agent アプリ名、ロケーション、LLM のモデル、ログ等の設定を管理 参考： User interface Agents の構成要素 Goal Goal (目標) では、Agent が達成すべき目標を定義します。複雑に書くより簡潔な目標であることが望ましいです。 Instructions Instructions (手順・指示) では、目標達成のために実行する必要があるプロセスを定義します。ユーザーの問題を解決するための 段階的なアプローチ を記述します。 Examples Examples (例)では、サンプル入出力例を定義します。一般的には few-shot prompt のようなものです。 少なくとも 1 つ以上の Example が必要ですが、4 つ以上の Examples があると Agent の動作精度が向上します。逆に言うと、Agent の動作精度を上げたい場合、この Examples を増やしてみたり、既存の Examples を改善してみるといいでしょう。 参考： At least one example for each playbook 参考： Agent の構成要素 Tools 概要 Tools (ツール)とは、Agent が外部システムに接続するための機能です。Agent 複雑なタスクを効率的に処理するためにツールを使用します。つまり、Vertex AI Agents を構成するために、Agent と同じくらいツールは重要になってきます。 参考： Tools Built-in tools Built-in tools は、 Google によってホストされたマネージドなツールで、すぐに利用可能です。現在は、Code Interpreter のみが対応しています。 Code Interpreter とは、自然言語から Python コードを自動で生成および実行することで、データ分析や可視化、複雑な計算処理などの様々なタスクを実行できるツールです。 OpenAPI tools OpenAPI tools は、 OpenAPI のスキーマを定義することでユーザー独自のツールが作成できるツールです。スキーマの記述はもちろん、外部 API を呼び出す際の認証周りなどユーザー側で定義する必要がありますが、汎用的な API 実行が可能となります。 クライアント側からは実行できるが OpenAPI tools からアクセスできない場合は、 Function tools などを用いて、API 実行をクライアント側で行い、Agent 側では API 実行結果を受け取るような工夫が必要です。 Data store tools Data store tools は、Vertex AI Search のように社内ドキュメントや指定した Web サイトに対し検索をかけたり、検索要約を取得したりできるツールです。つまり、Vertex AI Search のような機能をツールとして利用できる機能です。 データストアのタイプは以下のいずれかがサポートされています。 PUBLIC_WEB：Public Web コンテンツを含むデータストア UNSTRUCTURED：非構造化データを含むデータストア STRUCTURED: 構造化データを含むデータストア 触ってみた 今回は非常にシンプルな Agent アプリを構築していきます。 Agent アプリの構成としては、ユーザーの質問が計算問題だったら Code Interpreter を使用し、そうでなければツールを使わず直接 LLM による回答を生成させる構成です。 複雑な計算問題を得意としない LLM の場合、このような Agent を構成することでグラウンディングが実装できます。 構成例 Google Cloud コンソールから [Agent Builder] > [アプリ] > [新しいアプリを作成] を押下します。 Vertex AI Agent Builder コンソール画面① アプリの種類で [Agent] を選択、表示名とリージョンを設定し作成を押下します。 Vertex AI Agent Builder コンソール画面② しばらく待つと、Agent Demo App が作成できます。デフォルトで「Default Generative Agent」という名前の Agent が作られます。 Agent App コンソール画面① Default Generative Agent のパラメータをいくつか変更します。 Goal を以下に変更します。 You are an general agent. Support customer. Instructions を以下に変更します。 - if the customer asks for calculations, - Use ${TOOL: code-interpreter} - else, - Answer with a general answer. 変更したら [Save] を押下します。 Agent App コンソール画面② それでは、画面右のプレビュー画面で動作確認を行います。 まずは、「4x 3 -2x+1 を微分して」というプロンプトを実行してみます。 すると裏側では Agent が以下の処理フローを実行してユーザーへの回答を生成しています。 Agent は、ユーザーのプロンプトが計算問題だと判断し、Code Interpreter のツールを使用 Code Interpreter により Python コードが生成および実行され、正確な回答結果が得られ LLM に渡されます 最後に LLM は、ツールの回答結果をもとにユーザーへの回答文を生成してレスポンスとして出力 動作確認① 次に、「BigQuery について教えて」というプロンプトを実行してみます。 すると、計算問題ではないのでツールを使わずに一般的な回答を生成していることが確認できました。 動作確認② 関連記事 blog.g-gen.co.jp 又吉 佑樹 (記事一覧) クラウドソリューション部 はいさい、沖縄出身のクラウドエンジニア！ セールスからエンジニアへ転身。Google Cloud 全 11 資格保有。Google Cloud Champion Innovator (AI/ML)。Google Cloud Partner Top Engineer 2024。Google Cloud 公式ユーザー会 Jagu'e'r でエバンジェリストとして活動中。好きな分野は AI/ML。 Follow @matayuuuu

G-gen の奥田です。この度 Google Cloud Next '24 in Las Vegas で発表された Gemini in BigQuery の データキャンバス 機能を試してみたので手順等をご紹介します。 はじめに データキャンバスとは 試したこと 自然言語でクエリするためのその他の手法 利用料金 BigQuery キャンバスを作成 Gemini in BigQuery を用いて SQL やグラフを作成 例1: 特定の数値でデータを分類する 例2: 分類分け 例3:グラフを作成 はじめに データキャンバスとは Gemini in BigQuery とは、Google Cloud Next '24 で発表された、Gemini for Google Cloud シリーズの一部であり、BigQuery での分析を生成 AI が補助する機能の総称です。 当記事では、Gemini in BigQuery の1機能であるデータキャンバスを解説しています。Gemini in BigQuery の全容やその他の機能については、以下の記事を参照してください。 blog.g-gen.co.jp データキャンバス （Data canvas）は、この Gemini in BigQuery に含まれる機能の1つです。当機能では、自然言語（人間が普段話す言葉）をプロンプトに入力することで SQL や Python のコードが生成されます。これにより、コーディングの時間を短縮し、データサイエンティスト等が分析や可視化を行うリードタイムを短縮することができます。 また、作成したノートブックはクエリの実行履歴などを表で分かりやすく確認することができるため、引き継ぎが多く有るプロジェクトなどでもデータを視覚化しやすくなります。 本記事で作成したデータキャンバス 参考： Gemini で Google Cloud を強化 | Google Cloud 公式ブログ 参考： Google Cloud Next '24 in Las Vegas 速報レポート（キーノート・1日目） - G-gen Tech Blog なお、 BigQuery とは、様々なデータを蓄積、統合、クエリできる Google Cloud（旧称 GCP）の分析用データベースです。様々な記事で、BigQuery に関して解説しています。 参考： BigQuery カテゴリーの記事一覧 - G-gen Tech Blog 試したこと 試した使い方はシンプルであり、以下の通りです。 1. Google Cloud 側へ利用申請を行う 　 →2024年5月以降申請不要 BigQuery キャンバスを作成 Gemini in BigQuery を用いて SQL やグラフ を作成 参考： Set up Gemini in BigQuery  |  Google Cloud Documentation 自然言語でクエリするためのその他の手法 BigQuery に対して自然言語でクエリする手法は、データキャンバスの他にも、数多く用意されています。以下の記事を参考にしてください。 blog.g-gen.co.jp 利用料金 Gemini in BigQuery は、オンデマンドモードと、すべての BigQuery Editions で利用可能です。ただし、Standard エディションの場合のみ、以下の2機能が利用できません。 データインサイト メタデータの自動生成（Automated metadata generation） Gemini in BigQuery 機能を利用しても、通常の BigQuery 料金以外の料金は発生しませんが、前月の BigQuery 利用ボリュームに応じて、翌月の Gemini in BigQuery の利用回数に制限（Quotas）がかかります。前月のスキャン量やスロット量に応じて、翌月の1日あたりの実行可能回数が決定します。詳細は以下を参照してください。 参考 : Gemini in BigQuery Pricing Overview 参考 : Quotas and limits - Quotas for Gemini in BigQuery BigQuery キャンバスを作成 『 BigQuery キャンバス 』 を作成します。 キャンバスの作成のためには既存のテーブルが必要となるため別途作成する必要があります。 サンプルデータとして架空の企業リストを利用しました。 Number CompanyName Industory EstablishYear Employee GS00001 株式会社アルファネクスト 情報通信 2020 60 GS00002 ブルーバードテクノロジーズ株式会社 サービス 2016 15 … … … … … 各フィールドの種類は下記の様に設定しました。 フィールド名と型 テーブル作成後にホームタブ隣の『 ▼ 』を押下、『 データキャンバスを作成 』を押下します。 『 Get started by selecting a data source 』、に利用したいテーブル名を入力し、『 ADD TO CANVAS 』を押下します。 選択したクエリのスキーマが表示されたら、左下の『 <>クエリ 』を押下し、クエリ用のプロンプト作成ウインドウを表示します。 プロンプトを入力できるテキストボックスが表示されました。 Gemini in BigQuery を用いて SQL やグラフを作成 テキストボックス上に作成したいクエリを自然言語で入力します。 今回試した3つの事例を紹介します。 例1: 特定の数値でデータを分類する プロンプトに入力した内容は下記です。 1995年以前に設立された社員数50名以上の会社を教えてください。 右端の『 ▶ 』を押下することでSQLが作成されます。 『 ▶ 』を押下する前 『 ▶ 』を押下した後 作成された SQL を実行する際は、プロンプト文の下の『 実行 』を押下します。 プロンプトの下にクエリ結果が表示されました。 例2: 分類分け クエリ結果に対して追加でクエリを実行することが出来ます。 例1の結果の左下にある、『 これらの結果に対してクエリを実行する 』を押下するとプロンプトが新たに表示されます。 プロンプトに入力した内容は下記です。 企業を下記の様に分類してください。社員数が1-50名、51名-100名、100名-150名、150名-300名、300名以上。分類した後、それぞれの項目が何社ずつあるのか教えてください プロンプト入力画面（プロンプトの内容は途中で途切れてしまう様です） 例1と同様に右端の『 ▶ 』を押下することで SQL が作成され、 作成された SQL を実行するために、プロンプト文の下の『 実行 』を押下します。 クエリ実行結果 クエリを実行することで、より具体的に分析が出来ました。 例3:グラフを作成 例2の結果の中央下にある『 可視化 』を押下します。 どの種類のグラフを作成するか選択できます。今回は『 棒グラフの作成 』を押下します。 棒グラフが作成できましたが、できればX軸の従業員数は1-50名、51名-100名...といったように値を調整したいので、左下の『 EDIT 』を押下します。 作成したグラフ(1回目) EDIT 押下後、プロンプトの内容を編集できるようになったので下記を入力しました。 上記の結果に対して棒グラフを作成してください。横軸は従業員数、縦軸は企業数の合計です。横軸のレンジは下記の順番でお願いします。 1. 1-50 2. 51-100 3. 101-150 4. 151-300 5. 300以上 その結果、横軸が整理され視覚的にも確認しやすいデータとなりました。 作成したグラフ(2回目) Risa (記事一覧) クラウドソリューション部クラウドデベロッパー課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資格保有。日々修行中です！ Follow @risa_hochiminh

G-gen の武井です。本記事は Google Cloud Next '24 in Las Vegas の1日目に行われた Breakout Session「 What's new in Cloud network security 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Cloud NGFW 概要 Intrusion Prevension TLS Inspection Cloud NGFW Dashboard Cloud Secure Web Proxy 概要 Inline Network DLP SWP as a PSC Service Attachment Cloud NAT 概要 NAT for Hybrid Connections Private Inter-VPC NAT Hitless DPA Cloud Armor 概要 Cloud Armor Enterprise Per Service ML Models Cloud Armor for Internal App Load Balancing Custom Security Policies Deep Protocol Inspection 関連記事 セッションの概要 本セッションではCloud network security に関するプロダクトの最新機能が紹介されました。 Cloud NGFW 概要 Cloud NGFW (Next Generation Firewall) は、Google Cloud ワークロードを広範囲かつ高度な機能で保護する完全分散型のファイアウォール サービスです。 本セッションでは以下の機能について発表がありました。 Intrusion Prevension Palo Alto Networks 社の脅威保護技術を使用して、脆弱性、マルウェア、およびコマンド&コントロール攻撃から保護する新しい IDPS 機能が GA となります。 TLS Inspection 暗号化されたトラフィックを復号化したうえで検査する組み込み型の TLS 検査機能が GA となります。 Cloud NGFW Dashboard プロジェクトと組織の両方のスコープで、ファイアウォールのデプロイ、構成の問題、運用ステータス、および脅威監視の包括的なビューが GA となります。 Cloud Secure Web Proxy 概要 Cloud SWP (Secure Web Proxy) は下り (外向き) の Web トラフィックをモニタ、保護するゲートウェイサービスです。 本セッションでは以下の機能について発表がありました。 Inline Network DLP 将来的に、Broadcom 社の DLP (Data Loss Prevention) テクノロジーと統合して、偶発的なデータの持ち出しや悪意のあるデータ侵害から機密データを保護できるようになります。 SWP as a PSC Service Attachment ハブアンドスポーク方式で SWP を一元化することで、VPC peering の制限を気にすることなく、接続された VPC の各種ワークロードの下り (外向き) トラフィックに対してきめ細かなアクセス制御が可能な機能が GA となります。 Cloud NAT 概要 Cloud NAT (Network Address Translation) とは VPC やインターネット向けの下り (外向き) 通信のアドレス変換を提供するサービスです。 本セッションでは以下の機能について発表がありました。 NAT for Hybrid Connections Private NAT を拡張した Hybrid destinations (VPN と Cloud Interconnect に対応) が Preview リリースとなります。 Private Inter-VPC NAT プライベート IP から別のプライベート IP への変換 (リージョン内またはリージョン間の異なる VPC に存在する 2つのプライベート IP アドレス変換) が GA となります。 Hitless DPA 既存の接続を切断せずに静的ポート割り当てから動的ポート割り当てへの切り替え機能が GA となります。 Cloud Armor 概要 Cloud Armor とは、分散型サービス拒否（DDoS）攻撃、クロスサイト スクリプティング（XSS）、SQL インジェクション（SQLi）といったアプリケーションレイヤに対する脅威から Google Cloud 上のワークロードを保護する WAF (Web Application Firewall) サービスです。 本セッションでは以下の機能について発表がありました。 Cloud Armor Enterprise 高度な ML Powered DDoS からの保護に加え、脅威インテリジェンスや非 Web DDoS を備えた Cloud Armor のプレミアムティアサービスが GA となります。 Per Service ML Models サービス固有のトラフィックベースラインを作成し、マイクロサービスアーキテクチャによる小規模なサービスの攻撃や移行の検出に関する機能が GA となります。 Cloud Armor for Internal App Load Balancing Internal Application Load Balancer の背後にデプロイされたワークロードに対するサービスレート制限が Preview リリースとして提供されます。 Custom Security Policies IPアドレス、GEO (Geolocation)、ASN に基づいてトラフィックを監視またはブロックするセキュリティポリシーを作成する機能が GA となります。 Deep Protocol Inspection カスタムプロトコルの検査機能が Preview リリースされます。 関連記事 blog.g-gen.co.jp 武井 祐介 (記事一覧) 2022年4月にジョイン。クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2024 に選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei

G-gen の杉村です。当記事では、Google Cloud Next '24 in Las Vegas のキーノート（1日目）に関する速報レポートをお届けします。セッションレポートなど、Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 Google Cloud Next '24 in Las Vegas 概要 AI Hypercomputer Google Axion Gemini 1.5 Pro 等の生成 AI モデル Vertex AI でのグラウンディング「Enterprise Truth」 Vertex AI Agent Builder プロンプト開発と精度計測の補助 生成 AI による開発補助 生成 AI によるデータ活用 生成 AI とセキュリティ Google Workspace と生成 AI 関連記事 Google Cloud Next '24 in Las Vegas 2024年4月9日(火)から11日(木)までの3日間、米国ネバダ州のラスベガスで、Google Cloud Next '24 が行われました。 会場はラスベガス有数のカジノ・リゾートホテルであるマンダレイ・ベイ。120エーカー（東京ドーム約10個分）の広大な敷地を持ちます。 会場となるマンダレイ・ベイ 重要な新発表は初日のキーノート（基調講演）で行われます。また会場内の複数の会議室で、新機能の発表や、今後の Google Cloud 活用に関する示唆に富んだセッションが行われました。 G-gen 社からも11名のメンバーが現地へ赴き、その熱気を感じてきました。その様子は、本記事や、他のセッションレポートでお知らせします。関連記事は、 Google Cloud Next '24 カテゴリ の記事一覧でご覧いただけます。 本投稿では、Google Cloud Next '24 のキーノート（基調講演）で行われた、特に注目すべき技術的な発表にフォーカスして共有します。 概要 Google Cloud Next の開幕を飾るキーノート（基調講演）では、Google Cloud の CEO である Thomas Kurian や、各プロダクトの VP（Vice President）が、Google Cloud の最近の機能改善や、顧客事例を紹介しました。 全体を通して生成 AI プロダクトにフォーカスされていた点は、昨年8月に行われた Google Cloud Next '23 in San Francisco と同様でしたが、今回は「〇〇 Agent（エージェント）」という言葉が強調されていたのが印象的でした。 ここでいう Agent とは、生成 AI が「テキストや画像、動画の生成」に留まらず、人間から自然言語による指示を受けて、さまざまなタスクを行う仕組みを指します。基調講演では、Customer Agent、Employee Agent、Creative Agent、Data Agent、Security Agent、Code Agent など、さまざまな Agent が登場し、人間から文字入力や電話による音声で自然言語による指示を受けて、商品の購入処理を完了させたり、データベースに入っているデータの可視化を行う様子がデモされました。 ここからは、基調講演の中で発表された技術的な新発表をご紹介します。 キーノート会場 参考 : Welcome to Google Cloud Next ‘24 参考 : Day 1 at Next ’24 recap: AI agents for everyone AI Hypercomputer 機械学習のフレームワークやオープンソースに特化したスーパーコンピューティングのアーキテクチャである AI Hypercomputer が発表されました。 AI Hypercomputer には、NVIDIA H100 Tensor Core GPU を搭載した Compute Engine VM である A3 Mega VM や、 Hyperdisk ML などの AI ワークロードに特化したストレージソリューション、新しい TPU である TPU v5p などが含まれます。 TPU v5p（写真は別のセッションから） また従来から存在する Google Distributed Cloud（略称 GDC。オンプレミスへ Google Cloud を拡張するソリューション）での AI 活用も示唆されました。 NVIDIA GPUs to GDC 、 GKE on GDC 、 AlloyDB Omni for Vector Search （AlloyDB Omni はオンプレミスにインストールできる AlloyDB）、また最も厳格な規制業界にも対応する Sovereign Cloud の概念も発表されました。 Google Distributed Cloud（写真は Expo 会場より） 参考 : What’s new with Google Cloud’s AI Hypercomputer architecture Google Axion Thomas Kurian がことさら誇らしげに発表したのが、Google が独自開発した CPU である Google Axion です。 Google Axion は Arm ベースの CPU であり、「従来の x86 ベースのインスタンスと比べ、50%のパフォーマンス改善、60%のエネルギー効率改善」が期待できるとしています。 また、Compute Engine の General Purpose VM（一般用途 VM）として N4 シリーズと C4 シリーズが利用可能になります。これらは第5世代 Intel Xeon プロセッサを搭載しており、General Purpose VM、すなわち特定の用途に特化していない、汎用的なマシンシリーズです。 参考 : Introducing Google Axion Processors, our new Arm-based CPUs 参考 : What’s new in Google Cloud’s workload-optimized infrastructure Gemini 1.5 Pro 等の生成 AI モデル これまで Limited Preview（一部の許可されたユーザーのみ利用可能なプレビュー）だった Google の生成 AI 基盤モデル Gemini 1.5 Pro の Public Preview が発表されました。これまでできなかった、音声付き動画ファイルの処理も可能になっています。 Anthropic 社の Claude 3 （Sonnet / Haiku）の Vertex AI からの利用も GA（一般公開）されました。 ほかに、「オープンモデル（オープンソースと近い概念の生成 AI モデル）」の位置づけである Gemma のコード生成用モデルである CodeGemma 、自然言語から画像や動画を生成する Imagen 2.0 も紹介されました。Imagen 2.0 で生成された画像には、従来から発表されている Digital Watermarking （電子透かし）が入ります。 参考 : Google Cloud announces updates to Gemini, Imagen, Gemma and MLOps on Vertex AI Vertex AI でのグラウンディング「Enterprise Truth」 Vertex AI 経由で利用する生成 AI から利用するグラウンディング（生成 AI の誤った生成を補強するために外部情報を利用すること）の データ取得先として Google Search が利用可能に なります（Preview）。これにより、インターネット上の最新情報を、生成されたコンテンツの補強に使うことができるようになり、より生成 AI の汎用性が向上すると考えられます。 また、企業内のデータをグランディング先として利用する場合、AlloyDB や BigQuery といった Google Cloud 上のデータベース、Workday、Salesforce、ServiceNow、Hadoop、Confluence、JIRA などのサードパーティアプリケーションを利用することができます。 講演では、これらのように Web 経由の情報や企業内の情報を組み合わせてグランディングを行うことを Enterprise Truth と呼称していました。 参考 : Grounding generative AI in enterprise truth Vertex AI Agent Builder Vertex AI Agent Builder は、人間の代わりにプログラムが生成 AI の力を借りてタスクを実行する Agent（エージェント）を実装するフルマネージドサービスです。 前述の Enterprise Truth を実装する手段として、Agent Builder により Agent を開発し、Agent が Google Search やデータベースなどから必要な情報を抽出したり、必要に応じてコードを実行したりして、最終的な目的を達成します。 講演では、架空の EC サイトを模したデモ Web サイトのチャット欄に「この YouTube 動画のキーボード演奏者が着ている、チェックのシャツを買いたいです。値段と、買える場所と、いつ手に入るかが知りたい」という英語による指示と、YouTube の動画の URL を貼り付けると、ほどなくして Agent が関連商品一覧と在庫情報等を一覧で返し、会場からは驚きの声が上がりました。 講演では、これを Customer Agent という概念で表現し、顧客の要望に直接的に応える Agent として紹介されました。 参考 : Announcing Vertex AI Agent Builder: Helping developers easily build and deploy gen AI experiences G-gen のエンジニアが、Vertex AI Agent Builder をさっそく試用し、以下の記事にしています。 blog.g-gen.co.jp プロンプト開発と精度計測の補助 詳細は語られませんでしたが、 Vertex AI Prompt Management の Preview が発表されました。生成 AI 用のプロンプトを保存したり、チームで共有したりするためのツールになる見込みです。 また、生成 AI 基盤モデルの比較のための補助ツールとして Automatic side-by-side （ AutoSxS ）が GA（一般公開）されました。生成 AI の出力をスコア付けし、パフォーマンスを定量的に比較するためのツールです。 さらに、より小さいデータセットでモデルをクイックに比較するための Rapid Evaluation feature も Preview 公開されました。 参考 : Google Cloud announces updates to Gemini, Imagen, Gemma and MLOps on Vertex AI 生成 AI による開発補助 生成 AI によるアプリケーション開発補助ツールの進化も発表されました。 Gemini Code Assist は、従来は Duet AI for Developers（Gemini for Developers）と呼ばれていたもので、コード生成やコーディング補助をするツールです。Gemini 1.5 Pro が Gemini Code Assist を提供することにより、より精度が向上しました。 参考 : Ushering in a new era for app developers Gemini Cloud Assist は、Google Cloud の Web コンソール等に組み込まれた、Google Cloud の利用補助ツールです。自然言語で Google Cloud の使い方等に関する質問が可能で、設計や運用、トラブルシュートに活用できます。今回は Private preview の発表です。コンソール内のチャットに、自然言語で Google Cloud の使い方を質問すると回答してくれるほか、公式ドキュメントの案内や、gcloud CLI のコマンドラインを教えてくれます。 これまで「Gemini in Google Cloud（Duet AI for Google Cloud）」と呼ばれていたサービスは、今回 Gemini for Google Cloud として再定義され、その中には「Gemini Code Assist」「Gemini Cloud Assist」「Gemini in Security」「Gemini in BigQuery」「Gemini in Looker」「Gemini in Databases」が含まれています。詳細は、以下の記事をご参照ください。 参考 : Powering Google Cloud with Gemini 公式ブログ「Powering Google Cloud with Gemini」より引用 生成 AI によるデータ活用 Gemini in BigQuery 、 Gemini in Looker は、自然言語の指示により SQL を生成したり、データを可視化する仕組みです。 これらは前回の Google Cloud Next '23 でも発表されていましたが、より進化した BigQuery Studio などにより、更に統合が進んだ印象です。 参考 : What’s next for data analytics at Google Cloud Next ’24 また Gemini in BigQuery は申請ベースでの Preview が可能になっており、早速 G-gen のエンジニアによって試用した様子が、以下で記事になっています。 blog.g-gen.co.jp 生成 AI とセキュリティ Gemini in Threat Intelligence は、脅威に関する情報を自然言語で提供する仕組みです。 Gemini in Security Operations は、Google の提供する SIEM である Chronicle 向けの機能で、自然言語での検索やセキュリティ情報の要約を可能にします。 Gemini in Security Command Center は、従来から存在するリスク検知サービスである Security Command Center に、自然言語でのセキュリティ関連情報の検索を提供する機能です。 参考 : Make Google part of your security team anywhere you operate, with defenses supercharged by AI Google Workspace と生成 AI 昨年、英語版が GA（一般公開）となった Gemini for Google Workspace も、機能拡張が続いています。 特に強調されたのは Google Workspace の新サービスである Google Vids の発表です。Google Vids は生成 AI を使った動画編集や生成のサービスです。テーマに沿ったストーリーボードを自動生成し、ユーザーが保有する動画、画像、音声などをもとに容易な動画編集を可能にします。他の Google Workspace サービスと一貫した操作性で、ブラウザ上で完結する動画編集サービスです。2024年6月に、Workspace Labs（実験的機能のプレビューができる招待制のプログラム）で公開予定です。 ただし Google Vids は、原則的にはユーザーがすでに持っている動画や画像を活用するものであり、ストーリーボードやデザイン、スクリプト（台本）の生成はできるものの、動画自体の生成はできない、とのことです。 Google Vids の発表 AI Meetings and Messaging add-on は追加料金で利用可能なアドオンです。自動議事メモ、チャットの要約、69の言語に対応したリアルタイム翻訳などの機能を、$10/ユーザー/月間の追加料金で可能にします。 AI Security add-on は、自動的に機密ファイルの分類などのデータ保護（Data Loss Prevention）を行う機能で、こちらも$10/ユーザー/月間の追加料金です。 参考 : 5 Workspace announcements from Google Cloud Next '24 関連記事 2日目のキーノートについては、以下の記事をご参照ください。 blog.g-gen.co.jp G-gen によるその他の記事は、以下の記事一覧をご参照ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の西島です。当記事では Google Cloud Next'24 Las Vegas の「What's next for Google Cloud databases in the gen AI era」セッションの内容をいくつかピックアップして速報でお伝えします。 セクション概要 AlloyDB ScaNN index for AlloyDB AlloyDB model endpoint management Natural language in AlloyDB Parametalized secure View Firestore Bigtable 関連記事 セクション概要 このセッションでは、Google Cloud が提供するデータベースサービスの生成 AI 領域においてのアップデート情報が紹介されました。 AlloyDB PostgreSQL 互換のフルマネージドサービスの AlloyDB では、ベクトルインデックスのアルゴリズム、サードパーティやカスタムモデルのサポート、自然言語でのクエリ機能などのアップデートが発表されました。 ScaNN index for AlloyDB PostgreSQL の DB にベクトルデータを保存するための拡張機能である pgvector に互換性を持つ AlloyDB AI に、最新のベクトルインデックスアルゴリズムのScaNN(Scalable Nearest Neighbors) のサポートが プレビューで公開 されました。ScaNN は効率的なベクトル類似性探索をするアルゴリズムで、他のアルゴリズムに比べ計算時間の短縮やメモリ消費量で優位性があります。 AlloyDB model endpoint management エンべディングやテキスト生成のモデルのエンドポイントを一括で管理し、SQLを用いてモデルを利用するための機能が プレビューで公開 されました。 Vertex AI に加え、Open AI や Hugging Face のようなサードパーティや OSS で公開されているモデルも管理対象となっています。 Natural language in AlloyDB 自然言語を使って、AlloyDB のデータに対して SQL を生成しクエリを実行する機能が発表されました。 自然言語のテキストから SQL を生成する技術である Text-To-SQL は、DB のエンティティの依存関係や業務ロジックの情報を LLM に理解させる必要があるため難易度が高く、どこまでの精度がでるか気になる機能です。 Parametalized secure View エンドユーザーのコンテキストに基づいてデータを保護するための新しいビューが発表されました。セッションでは、ユーザのメールアドレスを利用してフィルタをかけるデモが紹介されていました。 Firestore Firestoreでベクトルデータベースの機能が追加されました。Firestore ならではのリアルタイム性の活用や Cloud Functions を使ったサーバレスな生成 AI アプリケーションの実装が期待できます。 Bigtable 通常の読み書きのワークロードから分離して、トランザクションデータに対して ETL 処理や分析クエリなどの読み取りのワークロードを頻繁に実行するための機能である Bigtable Data Boost が発表されました。 関連記事 blog.g-gen.co.jp 西島 昌太 (記事一覧) データアナリティクス準備室 データエンジニア 2023年4月に新卒入社。 元はフロントエンド開発を主戦場に、現在はデータエンジニアリングを勉強中。何でも屋さんを目指して、日々邁進。 休日は大体プログラムを書いてる人

G-gen の藤岡です。本記事は Google Cloud Next '24 in Las Vegas の1日目に行われた Breakout Session「 What's new with IAM 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Privileged Access Manager 過剰な権限 Privileged Access Manager の承認ベースのワークフロー 関連記事 セッションの概要 本セッションでは、Google Cloud リソースへのアクセス制御を司る仕組みである Cloud IAM のアップデートが紹介されました。当記事では、その中で2024年4月にプレビュー公開予定の「 Privileged Access Manager 」について解説します。 Privileged Access Manager 過剰な権限 セッション内ではクラウドサービスプロバイダ（CSP）全体で、95%のアカウントは、付与された権限のうちの3%しか使っていないという課題が指摘されました。 この事実からも、最小権限の原則を遵守しつつも、権限管理が如何に難しいかが伺えます。 Privileged Access Manager の承認ベースのワークフロー 権限管理が複雑化する原因として、一時的に付与した権限の剥奪を忘れたり、権限付与のプロセスが煩雑で各自が自由に権限を設定できる状況などが挙げられます。 今回発表された Privileged Access Manager （デモのコンソールでは「PAM」と表示）では、権限付与を承認ベースで行うことができます。 具体的には、以下の設定を含むエンタイトルメント（Entitlement）を作成します。 ロール ロールの付与期間 リクエスト者 承認者 リクエスト者は権限の付与を承認者に申請し、承認された場合、指定された期間（例えば障害対応のための◯時間のみ）にわたって対象の権限が付与されます。 このように権限管理を承認ベースで行うことで、不要な権限の付与を削減できます。 関連記事 blog.g-gen.co.jp 藤岡 里美 (記事一覧) クラウドソリューション部 数年前までチキン売ったりドレスショップで働いてました！2022年9月 G-gen にジョイン。ハイキューの映画を4回は見に行きたい。 Google Cloud All Certifications Engineer / Google Cloud Partner Top Engineer 2024 Follow @fujioka57621469

G-gen の堂原です。当記事では、生成 AI モデル「 Claude 3 」を Google Cloud（旧称 GCP）の Vertex AI 上で使う際のコスト・使用方法について紹介します。 はじめに 前提知識 Claude 3 Model Garden コスト コスト サンプル 使用方法 Model Garden から API を有効にする Anthropic's Vertex SDK はじめに 当記事では、Anthropic 社の生成 AI モデルである「 Claude 3 」を、 Vertex AI の Model Garden より利用する際の以下の点について紹介します。 コスト 使用方法 ※ 当記事は Claude 3 を Vertex AI 上で使い始めるまでにフォーカスしているため、Gemini Pro との性能比較は行いません。 前提知識 Claude 3 Claude 3 は Anthropic 社から提供されている生成 AI モデルで、最高レベルの性能を誇ると注目されています。 Claude 3 には以下の 3 つのモデルが含まれており、上のモデルほど性能が高く、代わりにコストが高くなっています。 Claude 3 Opus Claude 3 Sonnet Claude 3 Haiku Google 社の Gemini や OpenAI 社の ChatGPT のように、コンシューマー向けのサービスが提供されており、以下のサイトからコンソールベースで Claude 3 を使うことが可能です。 www.anthropic.com また、API も提供されている他、Google Cloud や Amazon Web Services (AWS) からも利用することが可能です。 Model Garden Vertex AI Model Garden は以下の記事で解説されている通り、Google やサードパーティより提供されている 100 以上のモデルを利用することができるサービスです。 blog.g-gen.co.jp Claude 3 についても、2024 年 3 月に Model Garden より利用可能となりました。 2024 年 4 月時点では Claude 3 Sonnet 及び Claude 3 Haiku が GA 、 Claude 3 Opus がパブリックプレビューとして利用可能です。 参考 : Google Cloud Vertex AI に Anthropic の Claude 3 モデルが登場 コスト コスト 2024 年 4 月時点で、Vertex AI における Claude 3 の利用料金は以下のとおりです。 モデル 項目 料金 Claude 3 Opus 入力トークン数 15 USD / 100 万トークン Claude 3 Opus 出力トークン数 75 USD / 100 万トークン Claude 3 Sonnet 入力トークン数 3 USD / 100 万トークン Claude 3 Sonnet 出力トークン数 15 USD / 100 万トークン Claude 3 Haiku 入力トークン数 0.25 USD / 100 万トークン Claude 3 Haiku 出力トークン数 1.25 USD / 100 万トークン 文字数ベースの課金である Gemini Pro とは異なり、Claude 3 はトークンベースとなっています。 サンプル G-gen のホームページ記載の 「代表からのメッセージ」 を題材にコストの比較を行いました。 私たちは、AWS専業インテグレーターである株式会社サーバーワークスとマルチクラウドインテグレーションを提供しているBespin Global Inc.のジョイントベンチャーとして設立された Google Cloudインテグレーターです。 サーバーワークスでは2009年からAWSに特化したインテグレーション事業を開始し、おかげさまで東証プライム市場への上場することができました。その一方でクラウド活用においては多様化が進み、様々なクラウドサービスを適切に活用していくことが今後のお客様のITシステムにおける最適解になりそうだと感じ始めています。そのなかでGoogle Cloudはデータ分析やコンテナ技術などユニークな技術を有しており、お客様の多様化するニーズに応えるために重要な役割を果たすと考えています。 私たちは全員Chromebookで業務を行い、Googleの考える新しい世界を身を持って実現していこうと取り組んでいます。Google Cloud や Google Workspaceを中心にクラウドサービスを適切に活用することにより、場所に縛られず、高セキュリティで、アジリティの高いITシステムを実現する。この世界を全てのお客様に提供することがクラウドの醍醐味ですし、その先のDXによるお客様のビジネスの成功にも必ず繋がっていくと確信しています。 Bespin Global Inc.はGoogle Cloudでアジア圏トップクラスの実績とノウハウを保持しています。そのノウハウを活用しつつ、サーバーワークスでのAWSインテグレーション経験を活かし、私たちはGoogle Cloudのプロフェッショナルとしてお客様の「クラウドで、世界を、もっと、はたらきやすく」を実現していきます。 上記はスペースを無視すると 732 文字となっています。 当該文字列が Claude 3 において何トークンになるかは Anthropic から提供されている Client SDK を用いることで確認が可能です。 from anthropic import Anthropic client = Anthropic() message = """私たちは、AWS専業インテグレーターである株式会社サーバーワークスとマルチクラウドインテグレーションを提供しているBespin Global Inc.のジョイントベンチャーとして設立された Google Cloudインテグレーターです。 サーバーワークスでは2009年からAWSに特化したインテグレーション事業を開始し、おかげさまで東証プライム市場への上場することができました。その一方でクラウド活用においては多様化が進み、様々なクラウドサービスを適切に活用していくことが今後のお客様のITシステムにおける最適解になりそうだと感じ始めています。そのなかでGoogle Cloudはデータ分析やコンテナ技術などユニークな技術を有しており、お客様の多様化するニーズに応えるために重要な役割を果たすと考えています。 私たちは全員Chromebookで業務を行い、Googleの考える新しい世界を身を持って実現していこうと取り組んでいます。Google Cloud や Google Workspaceを中心にクラウドサービスを適切に活用することにより、場所に縛られず、高セキュリティで、アジリティの高いITシステムを実現する。この世界を全てのお客様に提供することがクラウドの醍醐味ですし、その先のDXによるお客様のビジネスの成功にも必ず繋がっていくと確信しています。 Bespin Global Inc.はGoogle Cloudでアジア圏トップクラスの実績とノウハウを保持しています。そのノウハウを活用しつつ、サーバーワークスでのAWSインテグレーション経験を活かし、私たちはGoogle Cloudのプロフェッショナルとしてお客様の「クラウドで、世界を、もっと、はたらきやすく」を実現していきます。""" token_count = client.count_tokens(message) print (token_count) 上記処理の結果、上記の文章のトーク数は 640 でした。 仮に同じ文章が入力及び出力されるとした場合、料金は以下の通りです。 モデル 項目 文字数 / トークン数 料金 Gemini Pro 対する倍率 Gemini Pro 入力文字数 732 0.0000915 USD - Gemini Pro 出力文字数 732 0.0002745 USD - Claude 3 Sonnet 入力トークン数 640 0.00192 USD 20.98 倍 Claude 3 Sonnet 出力トークン数 640 0.0096 USD 34.97 倍 Claude 3 Haiku 入力トークン数 640 0.00016 USD 1.75 倍 Claude 3 Haiku 出力トークン数 640 0.0008 USD 2.91 倍 ※ 2024 年 4 月時点の情報をベースとしたものであり、最新状況は 公式サイト を確認ください。 いずれも上記の文章量程度だとほぼ料金は発生しませんが、Claude 3 は Gemini に比べるとコストは高いことがわかります。 そのため、現在の Gemini Pro と同じ感覚で使い続けると思わぬ課金が発生する可能性があるため注意が必要です。 使用方法 Model Garden から API を有効にする Vertex AI で Claude 3 を用いるには、Model Garden にて Claude 3 API を有効化する必要があります。 Claude 3 の各種モデルは Model Garden の基盤モデルに存在しています。 モデルの「詳細を表示」より詳細画面に進み、「有効にする」を押すことで設定画面に進むことが出来ます。 利用にあたってはいくつかの情報を入力する必要があります。 ただ、入力後に審査を待つなどはなく、すぐに利用することが出来ます。 有効化後、「ノートブックを開く」を押すことで Colab Enterprise を用いてサンプルコードを実行することが出来ます。 Anthropic's Vertex SDK Python でコーディングをする場合 Anthropic's Vertex SDK を用いることが出来ます。 先述したサンプルコードを確認することで基本的な使い方を学べます。 サンプルコードは全て英語となっていますが、日本語も対応しています。 from anthropic import AnthropicVertex MODEL = "claude-3-sonnet@20240229" REGION = "us-central1" PROJECT_ID = ${プロジェクト ID を記入} client = AnthropicVertex(region=REGION, project_id=PROJECT_ID) message = client.messages.create( max_tokens= 1024 , messages=[ { "role" : "user" , "content" : "貴方は料理研究家です。家に人参が余っていて消費に困っています。美味しく大量の人参を処理できるレシピを教えてください。" , } ], model=MODEL, ) print ( dict (message)[ "content" ][ 0 ].text) 上記コードを実行すると、以下のような出力となります。 人参をたくさん消費できる美味しいレシピをいくつかご紹介します。 1. 人参ケーキ しっとりとした人参ケーキは、おやつにも食事にも最適です。人参のほかにくるみやレーズンを加えると風味が更に良くなります。 2. 人参スープ クリーミーな人参スープは、寒い季節に最高の一品です。生クリームを加えてリッチな味わいに。パンとの相性も抜群です。 3. 人参グラタン 人参をスライスし、ホワイトソースとチーズをかけて焼くだけのシンプルなグラタン。副菜として優秀な一品です。 4. 人参フライ 人参を棒状に切り、卵と小麦粉につけてカラリと揚げれば、おつまみやおやつにぴったりの人参フライに。 5. 人参ジャム 人参を細かく刻んで、砂糖とレモン汁で煮詰めれば、パンに塗って食べられる人参ジャムが作れます。 6. 人参リゾット 人参をみじん切りにし、チーズと白ワインを加えて炊き上げれば、濃厚でリッチな人参リゾットに。 こうしたレシピを試していただければ、たくさんの人参を美味しく使い切れるはずです。色々アレンジを加えて楽しんでみてください。 また、公式のコードサンプルに記載されている Function Calling も実行することが出来ました。 Google Cloud サービスの各種 API と組み合わせていくことで、Google Cloud で Claude 3 を使うメリットがでてくると考えられます。 堂原 竜希 (記事一覧) クラウドソリューション部データアナリティクス課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の堂原です。本記事は Google Cloud Next '24 in Las Vegas の1日目に行われた Breakout Session「 Provide better search and generative AI experiences with Vertex AI Search 」のレポートです。 他の Google Cloud Next '24 の関連記事は Google Cloud Next '24 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Vertex AI Search Blended search Vertex AI Search を用いた RAG の構築 事例 : Forbes 社のケース 関連記事 セッションの概要 本セッションでは、Google Cloud が提供する検索プラットフォームである Vertex AI Search のアップデート及び活用例が紹介されました。 Vertex AI Search Blended search Google はかねてより Google 検索に代表される優れた検索エンジンを有しています。 生成 AI はそのような検索エンジンと組み合わせることでより便利なものとなります。 生成 AI による、検索エンジンの補強 : 複雑な情報を処理できる生成 AI を用いることで検索の性能を上げる 検索エンジンによる、生成 AI の補強 : Retrieval Augmented Generation (RAG) そんな中、Google Cloud では Vertex AI Search を用いることで、特定のドキュメントや Web サイト、サードパーティのツールから情報を検索し、生成 AI に活用することができます。 本セッションでは特に、この度 GA となった、複数のデータストアを 1 つのアプリで検索できる機能「 Blended search 」が紹介されました。 参考 : About connecting multiple data stores Blended search については実際にデモも行われ、時には Google Drive のファイルが、時には Jira のチケットが要約文とともに出力される様子が紹介されました。 また、Google Cloud のコンソール画面も映されており、そこにはデータストアの選択肢として、 Slack や Dropbpox、Box、OneDrive の名前もありました。 現時点では リリースノート や公式ドキュメントには記載無いですが、ゆくゆく選択肢として登場してくるかもしれません。 また、特定の領域に特化したデータストアについても GA が発表されました。 Vertex AI Search を用いた RAG の構築 後半ではまず、改めて RAG の定義が簡単に紹介されました。 Vertex AI Search で RAG を構築するにあたっては次の 2 つの方法が提供されています。 Vertex AI Search だけを用いたマネージドな RAG を構築する Vertex AI Search または Vertex AI の機能を一部用いながら、自前で RAG を構築する 勿論、どちらの方法を採用したとしても Vertex AI Search では以下のような便利な機能が提供されています。 また、Opening Keynote でも発表された Grounding in Google Search や、データガバナンス・セキュリティへの取り組みについても紹介されました。 事例 : Forbes 社のケース 最後に、Forbes 社の Chief Data Officer である David Johnson 氏が、オンラインサイトである「Forbes.com」での Vertex AI Search の活用例を紹介されていました。 かつてはキーワード検索で実装されていた検索エンジンが Vertex AI Search を用いた高度な検索エンジンにアップデートされるまでの様子が紹介されました。 関連記事 blog.g-gen.co.jp 堂原 竜希 (記事一覧) クラウドソリューション部データアナリティクス課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の佐々木です。当記事では GKE で新たにサポートされた バースト可能な Pod について解説します。 また、この機能のサポートに伴い、従来よりも小さい容量で Pod のリソースリクエストが可能になったので、こちらもあわせて紹介します。 Pod のバーストをサポートする GKE クラスタ Pod のバースト 小さいサイズの Pod GKE クラスタでバーストがサポートされる条件 メリット コスト最適化 パフォーマンスの向上 バーストの仕組み バーストで使用できるリソース容量 Autopilot モードのクラスタ Standard モードのクラスタ バーストによってノード内のリソースが枯渇した場合 バースト可能な Pod を使用する 当記事で使用する GKE クラスタについて 使用するマニフェストファイル burstable-pod.yaml placeholder-daemon.yaml バースト可能な Pod の作成 バースト容量を確保する Pod の作成 Pod のバーストを確認 バーストの上限を設定する burstable-pod.yaml に limits を追記 バーストが使用できるクラスタで QoS が Guaranteed の Pod を作成する 参考リンク Pod のバーストをサポートする GKE クラスタ Pod のバースト 特定の条件（後述）を満たす GKE クラスタでは、ノード上で実行する Pod で バースト を使用することができます。 バースト可能な Pod は、Pod がリクエストするリソース（CPU、メモリなど）容量を超えて、ノード内のリソースを一時的に使用することができます。 小さいサイズの Pod Pod のバーストをサポートする Autopilot モードのクラスタは、従来の Pod よりも少量のリソースリクエストで Pod を作成することができます。 従来のクラスタと、バースト可能な Pod を利用できるクラスタでリクエスト可能な CPU・メモリの最小容量は以下のようになっています。 リソース バーストをサポートするクラスタ バーストをサポートしていないクラスタ CPU (1,000m CPU = 1 vCPU) 50m CPU 250m CPU メモリ 52MiB 512 MiB なお、小さいサイズの Pod を使用する条件は「 使用する GKE クラスタでバーストがサポートされている」ことですが、小さいサイズで作成した Pod 自体がバースト可能（QoS が Burstable ）である必要はありません。 つまり、バーストしない、小さいサイズの Pod を作成することも可能です。 GKE クラスタでバーストがサポートされる条件 Autopilot モードのクラスタの場合、以下のいずれかの条件を満たした場合にバーストがサポートされます。 コンピュートクラス で Performance もしくは Accelerator が設定されている Pod （上記のコンピュートクラスを使用しない場合） 現在の GKE クラスタのバージョンが 1.29.2-gke.1060000 以降、かつ クラスタ作成時の バージョンが 1.26 以降のクラスタで実行される Pod クラスタ作成時のバージョンは以下のコマンドで確認することができます。 # クラスタ作成時の GKE のバージョンを確認 $ gcloud container clusters describe { クラスタ名 } \ --location={クラスタのリージョン} \ --format= " value(initialClusterVersion) " Standard モードのクラスタでは、GKE クラスタのバージョンを問わず、Pod のバーストがサポートされています。 メリット コスト最適化 Pod のバーストや小さいサイズの Pod を利用するメリットとして、ノードのリソースを効率よく使用することができます。 Autopilot モードのクラスタでは、Pod がリクエストした CPU・メモリの量だけ料金が発生します。つまり、リクエストしたリソースが実際にフルで使用されなくても、フルで使用したぶんの料金が発生するということです。 Pod のバーストを使用することで、ある Pod の負荷が一時的に高まったときに、その Pod のリソースリクエストを増やすことで対処するのではなく、他の Pod がリクエストして使用していないリソースを借りることができます。 パフォーマンスの向上 Pod のバーストにより、予測できないワークロード負荷に対応しやすくなります。また、スケールアウト等で新しい Pod を起動する際に、一時的にリソースを多く使用することで、Pod の起動時間を短縮することができます。 バーストの仕組み バーストで使用できるリソース容量 Autopilot モードのクラスタ Autopilot モードのクラスタでは、システム Pod や DaemonSet を含む、同一ノード上のすべての Pod のリソースリクエストの合計から、現在実際に使用されているリソース容量を引いた値がバースト可能な容量となります。 バースト可能容量（Autopilot） = ノード上のすべての Pod のリソースリクエストの合計 - 現在使用されているリソース容量 例えば、以下の図の GKE クラスタで、Node-A 上の Pod（Pod-A-1）がバーストする場合を考えてみます。 Pod-A-1がバーストする場合に追加で使用できるCPUリソース Node-A には 1~3 までの 3つの Pod があり、CPU リクエストの合計値は 1,200m CPU です。 Pod-A-1 がバーストするタイミングで、リクエストされている CPU のうち、Pod-A-1、Pod-A-2、Pod-A-3 が合計 800m CPU を使用していたとすると、バースト時に使用できる追加の CPU は 1,200 - 800 = 400m CPU となります。 Node-B 上の Pod（Pod-B-1、Pod-B-2、Pod-B-3）では合計 1,800m CPU がリクエストされており、そのうち 1,000m CPU が使用されています。したがって 800m CPU が余っている状態ですが、ノードが異なるため Pod-A-1 のバーストに使用することはできません。 バーストの最適化には、 ポッドアフィニティ を使用した Pod の配置先の調整や、 DaemonSet を使用したリソースの確保などの工夫が必要となります。 Standard モードのクラスタ Standard モードのクラスタでは、ノードとして実行されている Compute Engine VM の未使用リソースが、バーストで使用できるリソース容量となります。 バースト可能容量（Standard）= ノードの未使用リソース容量 バーストによってノード内のリソースが枯渇した場合 ノードで使用できる CPU リソースがバーストによって枯渇した場合、GKE は一部のコンテナの CPU 使用率を調整することで、すべてのコンテナが元々リクエストしていた CPU を使用できるようにします。 それに対して、ノードで使用できるメモリリソースがバーストによって枯渇した場合、GKE は コンテナを終了してメモリを再利用できるようにします。 Pod に設定された QoS が低く、リソースを大量に使用しているコンテナが優先的に終了されます。 したがって、メモリのバーストには極力依存せず、十分なメモリ容量のリクエストを設定しておくことが推奨されます。 また、バースト可能な Pod は QoS が Burstable に設定されるため、重要なコンテナを含む Pod は、より高い QoS である Guaranteed に設定しておきます。 バーストが使用できるクラスタでは、リソースリクエスト（requests）とリミット（limits）を同一の値にすることで、QoS が Guaranteed の Pod を実行することができます。 バースト可能な Pod を使用する 当記事で使用する GKE クラスタについて 当記事では Autopilot モードの GKE クラスタを使用します。 クラスタのコントロールプレーンとノードのバージョンは以下のようになっています。 MASTER_VERSION: 1 . 29 .2-gke. 1521000 NODE_VERSION: 1 . 29 .2-gke. 1521000 使用するマニフェストファイル burstable-pod.yaml このマニフェストファイルでは、バースト可能な Pod として、最小の CPU・メモリ容量をリクエストする Pod を作成します。 # burstable-pod.yaml apiVersion : v1 kind : Pod metadata : name : burstable-pod spec : containers : - name : burstable-pod image : nginx:1.25 resources : requests : cpu : 50m memory : 52Mi ephemeral-storage : 10Mi placeholder-daemon.yaml このマニフェストファイルでは、ノードのリソースをある程度リクエストしておき、実際には何もしない Pod を作成します。 この Pod の CPU・メモリリクエスト - この Pod が実際に使用している CPU・メモリ ぶんのリソースが、 burstable-pod.yaml で作成した Pod のバースト時に使用することができます。 DaemonSet として Pod を作成することで、実行されている全てのノードでバースト用のリソースを確保しておくことができます。 なお、Autopilot モードの場合は、実際にリソースが使用されていなくても、 リクエストしたリソースの料金が発生する 点は注意が必要です。 # placeholder-daemon.yaml apiVersion : apps/v1 kind : DaemonSet metadata : name : placeholder labels : app : placeholder spec : selector : matchLabels : app : placeholder template : metadata : labels : app : placeholder spec : containers : - name : placeholder image : nginx:1.25 resources : requests : cpu : 500m バースト可能な Pod の作成 GKE クラスタにバースト可能な Pod のマニフェストファイルを適用します。 # バースト可能な Pod を作成する $ kubectl apply -f burstable-pod.yaml pod/burstable-pod created Pod の作成後、QuS が Burstable になっていることを確認します。 # Pod の QuS を確認する $ kubectl describe pod burstable-pod | grep -m 1 " QoS " QoS Class: Burstable Pod のリソースリクエストの値を確認します。 バースト可能な Pod の最小値が設定できていることがわかります。 # Pod のリソースリクエストを確認する $ kubectl get pods burstable-pod -o json | jq ' .spec.containers[0].resources.requests ' { " cpu " : " 50m " , " ephemeral-storage " : " 10Mi " , " memory " : " 52Mi " } バースト容量を確保する Pod の作成 この DaemonSet で作成される Pod は何も処理を行わず、リソースをほぼ使用しません。したがって、ここでリクエストしたリソースは burstable-pod のバースト時に代わりに使用できます。 # DaemonSet を作成する $ kubectl apply -f placeholder-daemon.yaml daemonset.apps/placeholder created # burstable-pod と同じノードに Pod が作成されていることを確認する $ kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES burstable-pod 1 / 1 Running 0 2m18s 172 . 17 . 0 . 137 gk3-cluster-gke-public-129-aut-pool-2-b4bbb5d3-62bk < none > < none > placeholder-9drqb 1 / 1 Running 0 12s 172 . 17 . 0 . 138 gk3-cluster-gke-public-129-aut-pool-2-b4bbb5d3-62bk < none > < none > placeholder-bwnx2 1 / 1 Running 0 12s 172 . 17 . 0 . 202 gk3-cluster-gke-public-129-aut-pool-2-48addb14-h72h < none > < none > placeholder-qm8qj 1 / 1 Running 0 12s 172 . 17 . 1 . 14 gk3-cluster-gke-public-129-aut-pool-2-af2c9a34-qsbl < none > < none > Pod のバーストを確認 バースト可能な Pod にログインし、yes コマンドで負荷をかけることで、Pod をバーストさせてみます。 # Pod にログインする $ kubectl exec -it burstable-pod -- /bin/bash # Pod に負荷をかける root@burstable-pod:/# yes > /dev/null 別ターミナルから、Pod のリソース使用状況を確認します。 CPU リクエスト 50m の Pod がバーストし、966m が使用されていることがわかります。 placeholder-daemon.yaml で作成した Pod の CPU リクエスト（500m）、およびシステム Pod の CPU リクエストのうち、これらの Pod で現在使用されていないぶんのリソースが、バーストした burstable-pod で使用されています。 # 別のターミナルから Pod のリソース使用状況を確認する $ kubectl top pod burstable-pod NAME CPU ( cores ) MEMORY ( bytes ) burstable-pod 966m 4Mi バーストの上限を設定する burstable-pod.yaml に limits を追記 バースト可能な Pod のマニフェストファイルで resources.limits を設定することで、バーストの上限を設定することができます。 以下のマニフェストファイルでは、まず 50m CPU の Pod が作成され、バースト時には最大で 300m CPU まで CPU リソースを使用することができます。 # burstable-pod.yaml apiVersion : v1 kind : Pod metadata : name : burstable-pod spec : containers : - name : burstable-pod image : nginx:1.25 resources : requests : cpu : 50m memory : 52Mi ephemeral-storage : 10Mi limits : cpu : 300m # バーストの上限 このマニフェストファイルで作成した Pod に負荷をかけてみると、 resources.limits で指定した値までしか CPU が使用されていないことがわかります。 # Pod のリソース使用状況を確認する $ kubectl top pod burstable-pod NAME CPU ( cores ) MEMORY ( bytes ) burstable-pod 300m 3Mi バーストが使用できるクラスタで QoS が Guaranteed の Pod を作成する 最後に、バーストが使用できるクラスタで、バーストを使用しない、QoS が Guaranteed に設定された Pod を作成します。 リソースの requests と limits の値を同一にする必要があります。 この Pod は、他の Pod がバーストしたことによってノード上のメモリの枯渇が起きた際に、終了対象として選択される優先度が低くなっています。 # guaranteed-pod.yaml apiVersion : v1 kind : Pod metadata : name : guaranteed-pod spec : containers : - name : guaranteed-pod image : nginx:1.25 resources : requests : cpu : 250m memory : 512Mi limits : # requests と同一の値を設定する cpu : 250m memory : 512Mi マニフェストファイルをクラスタに適用し、Pod の QoS を確認します。 # QoS が Guaranteed の Pod を作成する $ kubectl apply -f guaranteed-pod.yaml pod/guaranteed-pod created # Pod の QuS を確認する $ kubectl describe pod guaranteed-pod | grep -m 1 " QoS " QoS Class: Guaranteed 参考リンク GKE Autopilot mode gets burstable workloads and smaller Pod sizes （Google Cloud ブログ） Configure Pod bursting in GKE （Google Cloud ドキュメント） 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では、GKE における Workload Identity Federation の、新しく追加された設定方法を解説します。 GKE における Workload Identity Federation 従来の方法 新しい方法 新しい方法の制限事項 新しい Workload Identity Federation の設定手順 当記事で使用する GKE クラスタについて ServiceAccount リソースの作成 Workload Identity Federation の設定 動作確認 参考手順 GKE における Workload Identity Federation 従来の方法 GKE クラスタ内の Pod 上で動作するアプリケーションから Google Cloud の API にアクセスする場合、認証方法として Workload Identity Federation の使用が推奨されています。 従来の Workload Identity Federation では、GKE クラスタ上に作成した ServiceAccount リソースと、Google Cloud の IAM サービスアカウントを紐づけることで利用できました。 これにより、ServiceAccount を使用する Pod が、それに紐づいた IAM サービスアカウントの権限を借用できるようになります。 従来のWorkload Identity Federation 従来の方法、また Workload Identity を使用せずに IAM 認証を行う方法の詳細は、以下の記事で解説しています。 blog.g-gen.co.jp 新しい方法 新しい方法では、GKE クラスタ内の ServiceAccount リソースを IAM のプリンシパルとして設定することで、ServiceAccount に IAM ロールを直接紐づけることができます。 GKEクラスタ内のServiceAccountをIAMのプリンシパルとして設定する この方法では紐づけ先となる IAM サービスアカウントを作成しなくてもよいため、IAM サービスアカウントの管理負荷が軽減されるほか、設定の手順が簡略化されます。 新しいWorkload Identity Federation 新しい方法の制限事項 従来の方法では、GKE クラスタ内の ServiceAccount が IAM サービスアカウントの権限借用を行う、つまり IAM サービスアカウントになりすます（impersonate） ことで、Google Cloud の API にアクセスしていました。 新しい方法ではこの権限借用が行われず、あくまでも GKE クラスタ内の ServiceAccount をプリンシパルとして API へのアクセスが行われます。 この「権限借用が行われない」ことで制限がかかるケースとして、 VPC Service Control でサービス境界を設定している場合 があります。 サービス境界の上り（内向き）と下り（外向き）のルールでは、アクセスを許可する対象として GKE クラスタ内の ServiceAccount を指定することができません。 GKE 内のアプリケーションは、IAM サービスアカウントの権限借用を介してサービス境界内のリリースにアクセスする必要があります。 したがって、このようなケースでは従来の方法で Workload Identity Federation を設定します。 参考： Identity federation: products and limitations 新しい Workload Identity Federation の設定手順 当記事で使用する GKE クラスタについて 当記事では Autopilot モードの GKE クラスタを使用します。 クラスタのコントロールプレーンとノードのバージョンは以下のようになっています。 MASTER_VERSION: 1.27.8-gke.1067004 NODE_VERSION: 1.27.8-gke.1067004 ServiceAccount リソースの作成 GKE クラスタに ServiceAccout リソースを作成します。 # GKE クラスタに ServiceAccount リソースを作成 $ kubectl create serviceaccount my-serviceaccount Workload Identity Federation の設定 さきほど作成した ServiceAccout に対して IAM ロールを紐付けます。 IAM ロールの紐づけを行う際に、IAM プリンシパルとして Workload Identity Federation 特有の文字列を指定します。 当記事では、設定に必要な情報がわかりやすいように、以下のシェル変数を設定していきます。 # シェル変数の設定 PROJECT_ID = { プロジェクトID } PROJECT_NUMBER = { プロジェクト番号 } SERVICE_ACCOUNT = { GKEクラスタに作成したServiceAccountの名前 } NAMESPACE =default もし default 以外の Namespace を使用する場合は、 NAMESPACE 変数の値も変更してください。 また、プロジェクト番号はコンソールのダッシュボード画面や、以下のコマンドを使用することで確認できます。 # プロジェクト番号を確認する $ gcloud projects describe ${PROJECT_ID} | grep projectNumber 以下のコマンドを実行し、GKE クラスタに作成した ServiceAccount に IAM ロールを紐づけます。 当記事では「Kubernetes Engine Cluster 閲覧者（roles/container.clusterViewer）」を設定します。 # ServiceAccout に IAM ロールを紐づけ $ gcloud projects add-iam-policy-binding projects/ ${PROJECT_ID} \ --role=roles/container.clusterViewer \ --member=principal://iam.googleapis.com/projects/ ${PROJECT_NUMBER} /locations/global/workloadIdentityPools/ ${PROJECT_ID} .svc.id.goog/subject/ns/ ${NAMESPACE} /sa/ ${SERVICE_ACCOUNT} 動作確認 GKE クラスタ内の Pod に ServiceAccount を紐付け、Google Cloud の API にアクセスしてみます。 以下のマニフェストファイルを使用して、gcloud コマンドがインストールされたコンテナを含む Pod をクラスタに作成します。 spec.serviceAccountName に ServiceAccount の名前を設定します。 # pod.yaml apiVersion : v1 kind : Pod metadata : name : test-pod namespace : default spec : serviceAccountName : my-serviceaccount containers : - name : test-pod image : google/cloud-sdk:slim command : [ "sleep" , "infinity" ] Standard クラスタを使用している場合は、マニフェストファイルに spec.nodeSelector フィールドを記述し、Pod が Workload Identity Federation を使用できるノードプールに配置されるようにします。 # Standard クラスタの場合の追記内容 spec : nodeSelector : iam.gke.io/gke-metadata-server-enabled : "true" Pod が実行状態になるのを待ってから、以下のコマンドで Pod 側から gcloud コマンドを実行してみます。 ここでは GKE クラスタの一覧を取得するコマンドを実行していますが、権限エラーが発生することなく GKE クラスタの一覧が取得できました。 # Pod 側で gcloud コマンドを実行 $ kubectl exec -it test-pod -- gcloud container clusters list # 出力例 $ kubectl exec -it test-pod -- gcloud container clusters list NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS cluster-sasashun-gke-public-autopilot asia-northeast1 1 . 27 .8-gke. 1067004 xx.xx.xxx.xxx e2-small 1 . 27 .8-gke. 1067004 1 RUNNING 参考手順 Authenticate to Google Cloud APIs from GKE workloads 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では GKE の Ingress リソースとして作成したロードバランサで Identity-Aware Proxy を有効化する方法を解説します。 当記事の概要 GKE クラスタにサンプルアプリケーションをデプロイ GKE クラスタの作成 Deployment リソースの作成 Google マネージド証明書の作成 静的外部 IP アドレスの作成 DNS レコードの作成 ManagedCertificate リソースの作成 アプリケーションの公開 Ingress リソースの作成 ブラウザからアプリケーションにアクセス OAuth 認証情報を格納する Secret リソースの作成 OAuth 同意画面の構成 OAuth 2.0 クライアント ID とシークレットの発行 Secret リソースの作成 IAP の有効化 BackendConfig リソースの作成 Ingress リソースの更新 IAP の動作確認 参考手順 当記事の概要 当記事では、GKE クラスタに Ingress リソースとして作成したアプリケーションロードバランサで Identity-Aware Proxy （以下、IAP）を有効化する手順を解説します。 IAP は、Web アプリケーションや仮想マシンなどのクラウドリソースに対して、アプリケーションレベルの認証機能を提供するサービスです。 IAP を用いることで、Web アプリケーションや仮想マシンにアクセスできるユーザーを、特定の IAM ロール がアタッチされた Google アカウント / グループ に制限することができます。 Ingress で IAP を使用することにより、バックエンドの Pod 上で動作するアプリケーションにアクセスする際に、IAM による認証を必須にすることができます。 IngressでIAPを有効化する Kubernetes および GKE については、以下の記事で解説しています。 blog.g-gen.co.jp blog.g-gen.co.jp また、当記事に関連して、以下の記事では Ingress リソースとして作成したアプリケーションロードバランサで Cloud Armor を使用する方法について解説しています。 GKE 上で展開するウェブアプリケーションに接続元 IP アドレス制限などをかけたい場合は、こちらもご一読ください。 blog.g-gen.co.jp GKE クラスタにサンプルアプリケーションをデプロイ GKE クラスタの作成 当記事では Autopilot モードの GKE クラスタを使用します。 使用するクラスタのコントロールプレーンおよびノードのバージョンは以下のようになっています。 MASTER_VERSION: 1.27.8-gke.1067004 NODE_VERSION: 1.27.8-gke.1067004 GKE クラスタの作成方法については 公式ドキュメント 、または Terraform を使用した以下の記事を参照してください。 blog.g-gen.co.jp Deployment リソースの作成 以下のマニフェストファイルを GKE クラスタに適用し、Deployment リソースを作成します。 この Deployment により、Google Cloud が公開している サンプルアプリケーション のコンテナイメージを使用する Pod が作成されます。 # deployment.yaml apiVersion : apps/v1 kind : Deployment metadata : name : helloweb labels : app : hello spec : selector : matchLabels : app : hello template : metadata : labels : app : hello spec : containers : - name : hello-app image : us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 ports : - containerPort : 8080 resources : requests : cpu : 200m Google マネージド証明書の作成 静的外部 IP アドレスの作成 Ingress リソースとして作成される外部アプリケーションロードバランサに紐付ける、静的外部 IP アドレスを作成します。 # 静的外部 IP アドレスを作成する $ gcloud compute addresses create helloweb-ip --global DNS レコードの作成 利用可能なドメインと、さきほど作成した IP アドレスを使用して A レコードを登録します。 当記事では Cloud DNS を使用します。 Cloud DNS では、以下のように CLI でレコードを登録することができます。 # トランザクションの開始 $ gcloud dns record-sets transaction start --zone = { DNS ゾーン名 } # A レコードを作成 $ gcloud dns record-sets transaction add { 作成した IP アドレス } \ --name = { 使用するドメイン } \ --ttl = 300 \ --type = A \ --zone = { DNS ゾーン名 } # トランザクションの終了 $ gcloud dns record-sets transaction execute --zone = { DNS ゾーン名 } ManagedCertificate リソースの作成 以下のマニフェストファイルを使用して、GKE の ManagedCertificate リソースとして Google マネージド SSL 証明書を作成します。 spec.domains には A レコードに設定したドメイン名を記述します。 # cert.yaml apiVersion : networking.gke.io/v1 kind : ManagedCertificate metadata : name : hello-managed-cert spec : domains : - { 使用するドメイン } # Aレコードで使用したドメイン 証明書の検証には20分ほどかかるため、検証待ちの間に以降の手順を実施します。 アプリケーションの公開 Ingress リソースの作成 IAP 有効化前後の動作の比較をするため、まずは IAP を有効化していない状態でロードバランサを作成し、IAM 認証なしでアプリケーションを公開します。 Ingress リソースとして、ここまでの手順で作成した静的外部 IP アドレス、Google マネージド証明書（ManagedCertificate リソース）を使用するアプリケーションロードバランサを作成します。 以下のマニフェストファイルを GKE クラスタに適用します。 # ingress.yaml apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : helloweb annotations : kubernetes.io/ingress.class : "gce" kubernetes.io/ingress.global-static-ip-name : helloweb-ip # 作成した静的外部 IP アドレスの名前 networking.gke.io/managed-certificates : hello-managed-cert # 作成した ManagedCertificate リソースの名前 labels : app : hello spec : defaultBackend : service : name : helloweb-backend port : number : 8080 --- apiVersion : v1 kind : Service metadata : name : helloweb-backend labels : app : hello spec : type : NodePort selector : app : hello ports : - port : 8080 targetPort : 8080 なお、 kubectl apply で上記マニフェストファイルを適用すると、以下のような Warning メッセージが表示されます。 $ kubectl apply -f manifests/ingress.yaml Warning: annotation " kubernetes.io/ingress.class " is deprecated, please use ' spec.ingressClassName ' instead ingress.networking.k8s.io/helloweb created service/helloweb-backend created これは、2024年3月現在、Ingress の作成時にアノテーションとして kubernetes.io/ingress.class を使用するのが Kubernetes では非推奨になっているためです。 Kubernetes では非推奨になっているものの、GKE では引き続きこのアノテーションを使用して Ingress を作成します（ 参考 ）。 ブラウザからアプリケーションにアクセス 前の手順で作成した ManagedCertificate リソースの STATUS が ACTIVE になっていることを確認します。 $ kubectl get managedcertificates -w NAME AGE STATUS hello-managed-cert 6m6s Provisioning hello-managed-cert 16m Active DNS に設定したドメイン名を使用してブラウザからアクセスすると、以下のようなサンプルアプリケーションの画面が表示されます。 GKE上のアプリケーションにアクセスする OAuth 認証情報を格納する Secret リソースの作成 OAuth 同意画面の構成 プロジェクトで OAuth 同意画面 をまだ構成していない場合は、設定を行います。 手順は こちらのブログ記事 の「OAuth 同意画面の設定」を参照してください。 OAuth 2.0 クライアント ID とシークレットの発行 Google Cloud コンソールの「API とサービス」から、OAuth 2.0 クライアント ID を作成していきます。 「OAuth クライアント ID」を選択する 以下の項目を入力し、「作成」を選択します。 項目 値 アプリケーションの種類 ウェブ アプリケーション 名前 任意の名前 「承認済みのリダイレクト URI」項目は後ほど設定するため、一旦は空欄のまま作成します。 OAuth クライアント ID を作成する 作成後、 クライアント ID と クライアント シークレット が表示されるので、この2つはメモしておきます。 クライアント ID とクライアント シークレットをメモしておく 作成したクライアント ID の編集画面を開き、「承認済みのリダイレクト URI」項目を設定します。 値には、先ほどメモしておいたクライアント ID を含む以下の URI を設定します（クライアント ID とシークレットの値は編集画面からも確認できます）。 「承認済みのリダイレクト URI」の設定値 https://iap.googleapis.com/v1/oauth/clientIds/{クライアント ID の値}:handleRedirect 「承認済みのリダイレクト URI」を設定する Secret リソースの作成 OAuth 2.0 クライアント ID を作成したときにメモしておいたクライアント ID、クライアント シークレットの値を使用して、GKE クラスタに Secret リソースを作成します。 # Secret リソースを作成する kubectl create secret generic iap-secret --from-literal = client_id = { クライアント ID の値 } \ --from-literal = client_secret = { クライアント シークレットの値 } IAP の有効化 BackendConfig リソースの作成 以下のマニフェストファイルを GKE クラスタに適用し、IAP 用の BackendConfig リソースを作成します。 spec.iap.oauthclientCredentials.secretName には、前の手順で作成した Secret リソースの名前を記述します。 # backendconfig.yaml apiVersion : cloud.google.com/v1 kind : BackendConfig metadata : name : iap-backendconfig spec : iap : enabled : true oauthclientCredentials : secretName : iap-secret Ingress リソースの更新 Ingress リソースのマニフェストファイルを更新し、先ほど作成した IAP 用の BackendConfig を紐付けます。 以下のように Service リソースに metadata.annotations.beta.cloud.google.com/backend-config を追記し、GKE クラスタに再適用します。 # ingress.yaml apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : helloweb annotations : kubernetes.io/ingress.class : "gce" kubernetes.io/ingress.global-static-ip-name : helloweb-ip networking.gke.io/managed-certificates : hello-managed-cert labels : app : hello spec : defaultBackend : service : name : helloweb-backend port : number : 8080 --- apiVersion : v1 kind : Service metadata : name : helloweb-backend labels : app : hello annotations : # この項目を追記 beta.cloud.google.com/backend-config : '{"default": "iap-backendconfig"}' # 作成した BackendConfig リソースの名前 spec : type : NodePort selector : app : hello ports : - port : 8080 targetPort : 8080 IAP の動作確認 再度ブラウザからアプリケーションにアクセスし、以下のようなログイン画面が表示されれば、IAP による認証が有効化されています（有効化には少し時間がかかります）。 IAPのログイン画面 IAM で「IAP で保護されたウェブアプリ ユーザー（roles/iap.httpsResourceAccessor）」ロールが付与されたアカウントを使用することで、ログインすることができます。 参考手順 GKE での IAP の有効化 Ingress configuration on Google Cloud 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。2024年3月のイチオシ Google Cloud アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに 放置プロジェクトに対する推奨事項が表示 AlloyDB AI が Preview => GA BigQuery で Amazon S3 に対するマテビュー等が Preview => GA IAM 事前定義ロール一覧ドキュメントの読み込みが高速化 Cloud Run の service レベルで最小インスタンス数を設定可能に 別 GWS アカウントにメールデータを移行（Open Beta） VPC で Internal ranges が Preview => GA Dataflow streaming jobs で CUD（確約利用割引）が購入可能に Vertex AI Searchで ドキュメントの「チャンク化」が利用可能に Vertex AI Search で ServiceNow と接続 (Private Preview) Cloud Run の Direct VPC egress で Cloud NAT が使用可能に Vertex AI Search で Google ドライブとの sync が可能に (Preview) 新しい組織ポリシー iam.serviceAccountKeyExposure が利用可能に 削除された BigQuery データセットを復旧できるように（Preview） 新サービス App Hub が Preview => GA Container Registry が廃止へ Cloud Run から NFS volume をマウントできるように（Preview） 新規 Google Cloud 組織でデフォルトの組織ポリシーが適用される BigQuery で Salesforce Data Cloud のデータを取り込めるように BigQuery の Incremental materialized view で対応 SQL が拡張 Cloud Loggingでintercepting aggregated sinkが利用可能に 複数の Application Load Balancer が mTLS (相互 TLS) に対応 (Preview) はじめに 月ごとの Google Cloud アップデートのうち、特にイチオシなものをまとめています。 ある程度の事前知識が必要な記載となっています。サービスごとの前提知識は、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp またリンク先の公式ガイドは英語版にしないと最新情報が反映されていない場合がありますためご注意ください。 放置プロジェクトに対する推奨事項が表示 (2024/2月末頃) Resource Manager のツリー表示から、放置プロジェクト（使われておらず放置されている Google Cloud プロジェクト）の情報が表示されるようになった。 放置プロジェクトはセキュリティホールになり得るため、削除するなどの対策が望ましい。 当機能はリリースノートに記載がなく、サイレントリリース。 AlloyDB AI が Preview => GA Build generative AI applications using AlloyDB AI (2024/02/29) AlloyDB AI が Preview => GA。AlloyDB の中から SQL で Vertex AI のモデルを呼び出せる。エンべディングインデックス作成＆クエリも可能。 BigQuery で Amazon S3 に対するマテビュー等が Preview => GA BigLake metadata cache-enabled tables (2024/02/29) BigQuery で Amazon S3 に対するマテビュー等が Preview => GA。 S3 に格納された CSV 等に対しマテリアライズドビューを作り、自動更新でデータを BigQuery に実体化。パフォーマンスや AWS 側 Egress コストの面で、通常の BigQuery Omni より優れる。 IAM 事前定義ロール一覧ドキュメントの読み込みが高速化 IAM basic and predefined roles reference (2024/03/05) 新機能ではなく、公式ドキュメントの修正。IAM の事前定義ロール一覧のドキュメントで「*」を展開できなくなる代わりに、ページの読み込みが高速化。 従来はこのページを表示しきるのに 30秒〜1分ほどかかっていたが、10秒ほどに短縮。 Cloud Run の service レベルで最小インスタンス数を設定可能に Applying minimum instances at service-level versus revision-level (2024/03/05) Cloud Run の service レベルで最小インスタンス数を設定できるように（Preview）。 従来は revision レベルでしか設定できず、設定変更いは再デプロイが必要だった。今後はサービスレベルでの設定が推奨になる。 別 GWS アカウントにメールデータを移行（Open Beta） Migrate email data from one Google Workspace account to another, available in open beta (2024/03/05) Gmail のメールデータを、ある Google Workspace アカウントから別の Google Workspace アカウントに移行可能。 同一組織内のアカウント同士、または他の組織のアカウントに対して移行可能。 一度に最大 100 ユーザーまで移行できる。 VPC で Internal ranges が Preview => GA Internal ranges overview (2024-03-07) VPC で Internal ranges が Preview => GA。 IP アドレス範囲を「Internal range」オブジェクトとして CIDR 形式で予約しておける。Internal range への権限がなければ、その IP 範囲でサブネットを作ったり他ネットワークとピアリングできない。 Dataflow streaming jobs で CUD（確約利用割引）が購入可能に Committed use discounts (2024-03-12) Dataflow streaming jobs で CUD（確約利用割引）が購入できるように。 1年 or 3年のコミットメントで20%〜40%の割引が適用される。FlexRS など適用外のリソースがあることに留意。 Vertex AI Searchで ドキュメントの「チャンク化」が利用可能に Parse and chunk documents (2024-03-12) Vertex AI Searchで ドキュメントの「チャンク化」が利用可能に。 PDF等非構造化データストアで有効化するとLLMによる回答生成の精度が向上。一方で無効化（デフォルト）だとドキュメント検索に最適化。用途により有効 or 無効を選択するとよい。 Vertex AI Search で ServiceNow と接続 (Private Preview) Connect a third-party data source (2024-03-12) Vertex AI Search で ServiceNow と接続できるように（Private Preview）。 サードパーティは他に Confluence、Jira、Salesforce に既に対応（いずれも Preview）。 Cloud Run の Direct VPC egress で Cloud NAT が使用可能に Cloud Run Release Notes - March 14, 2024 (2024-03-14) Cloud Run の Direct VPC egress で Cloud NAT (Public IP) が使えるように。 従来は Direct VPC egress 経由だと Cloud NAT は使用不可で、接続元 IP を固定したいときは「サーバーレス VPC アクセス」を使う必要があった。 Vertex AI Search で Google ドライブとの sync が可能に (Preview) Vertex AI Search and Conversation release notes - March 15, 2024 (2024-03-15) Vertex AI Search で Google ドライブとの sync が可能に（Preview with allowlist）。 Vertex AI Search のデータソースとして Google ドライブが利用可能。Google ドライブを使った RAG 構成が容易に構築できる。 Preview with allowlist なので利用には Google への申請が必要。 新しい組織ポリシー iam.serviceAccountKeyExposure が利用可能に Automatically disable exposed service account keys (2024-03-15) 新しい組織ポリシー iam.serviceAccountKeyExposure が利用可能に。 サービスアカウントキーの流出が Google に検知されたとき、キーを自動的に無効化。2024-06-16 からすべての組織においてデフォルトで有効化される。 以下の記事も参照。 blog.g-gen.co.jp 削除された BigQuery データセットを復旧できるように（Preview） Undelete datasets (2024-03-18) BigQuery で、削除してしまったデータセットを復旧できるように（Preview）。 ただし復旧できるのは、タイムトラベル期間中（デフォルト7日間）に限る。 新サービス App Hub が Preview => GA App Hub overview (2024-03-19) Google Cloud の新サービス App Hub が 2024-03-19 に Preview => GA（一般公開）。 Google Cloud リソースを論理的にグルーピングしてワークロードごとに整理するサービス。Preview 公開時は gcloud での操作のみだったが、コンソール操作もできるようになった。 Container Registry が廃止へ Container Registry deprecation (2024-03-19) Google Cloud のコンテナイメージレジストリサービスである Container Registry が廃止へ。 Artifact Registry へ移行する必要あり。今後のスケジュールは以下の通り。 2025-03-18以降、Container Registry へのイメージ書き込みが不可に 2025-04-22には、イメージの読み出しも不可 Cloud Run から NFS volume をマウントできるように（Preview） NFS volume mounts for services (2024-03-19) Cloud Run (services/jobs) から VPC/オンプレの NFS volume をマウントできるようになった。 Google Cloud のフルマネージドなファイルシステムである「Filestore」にも対応している。 新規 Google Cloud 組織でデフォルトの組織ポリシーが適用される Introducing stronger default Org Policies for our customers (2024-03-21) 2024年初頭以降に新規作成の Google Cloud 組織では、デフォルトで複数の組織ポリシーが適用されることになった。 "Disable service account key creation" や "Domain restricted sharing" などが最初から有効化されている。よりセキュアになる一方で、Google Cloud の使い始めにあたり、仕様を正しく理解していないと壁にぶつかることも想定される。 BigQuery で Salesforce Data Cloud のデータを取り込めるように Work with Salesforce Data Cloud data in BigQuery (2024-03-21) BigQuery で Salesforce Data Cloud のデータを取り込めるようになった（GA）。Salesforce Data Cloud とは、日本では2024年3月に提供開始されたクラウド型 CDP。 BigQuery Omni により SF Data Cloud 上のデータをクエリしたり、マテリアライズド・ビューで永続化できる。 BigQuery の Incremental materialized view で対応 SQL が拡張 LEFT OUTER JOIN and UNION ALL support (2024-03-21) BigQuery の Incremental materialized view が LEFT OUTER JOIN と UNION ALL をサポート（Preview）。 LEFT JOIN では左側のテーブルにレコード追加があった場合に増分(Incremental)アップデートになり、効率的にクエリが処理される。 Cloud Loggingでintercepting aggregated sinkが利用可能に Collate and route organization- and folder-level logs to supported destinations (2024-03-27) Cloud Loggingでintercepting aggregated sinkが利用可能に。組織内の親リソースでこの sink を使うと、収集されたログは子リソースのシンクでは拾えなくなる。 上流でログを集約することでログコスト肥大化を防げる。また、この intercepting aggregated sink は子プロジェクトのログルーターページからも閲覧可能。 複数の Application Load Balancer が mTLS (相互 TLS) に対応 (Preview) Mutual TLS authentication (2024-03-27) 以下の Load Balancer が mTLS (相互 TLS) に対応。従来は Global external Application Load Balancer (Classic/New) だけが対応していた。 Regional external Application Load Balancer Regional internal Application Load Balancer Cross-region internal Application Load Balancer 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では Google が提供する生成 AI モデル Gemini Pro と、Web UI 用の Python フレームワークである Gradio を使用した、シンプルなチャットボットの作り方を紹介します。 前提知識 Gemini Pro Gradio Gradio を使用して Gemini Pro のチャットボットを開発する Python のバージョン requirements.txt main.py コードの解説 Gradio の ChatInterface に渡す関数の形式について generation_config について Gemini における会話履歴の形式について 動作確認 ローカルでチャットボットを実行する チャットボットを使用する チャットボットを外部に共有する Safety Attributes の調整 ResponseValidationError Safety Attributes とは コードの修正 修正後の main.py 全文 動作確認 BLOCK_NONE に設定した場合の動作について Google Cloud 上にチャットボットをデプロイする Cloud Run を使用する コードの修正 Dockerfile の作成 Cloud Run にデプロイ 動作確認 Cloud Run のアクセス元制御について 前提知識 Gemini Pro Gemini Pro は、Google が提供する生成 AI モデル Gemini のバリエーションの1つであり、テキストや画像、動画などの複数の種類のデータを扱うことができるマルチモーダルな生成 AI モデルです。 詳細については以下の記事をご一読ください。 blog.g-gen.co.jp Gradio Gradio は、Python で機械学習 Web アプリを容易に構築できるフレームワークです。 当記事では、 Gradio の ChatInterface() を使用してチャットボットを作成しています。コードに以下の一行を記述するだけで、チャットボットに必要な機能を備えた UI を用意することができます。 gradio.ChatInterface(fn={関数名}).launch() ChatInterface ですぐに使用できる UI この UI 上でメッセージを送信（Submit）すると、 ChatInterface() に引数として渡した関数にメッセージを渡すことができます。この関数内にメッセージを処理するロジックを記述するだけで、UI を備えたチャットボットを簡単に開発することができます。 参考： How to Create a Chatbot with Gradio Gradio を使用して Gemini Pro のチャットボットを開発する Python のバージョン 当記事の内容は、 Python 3.12.0 で試しています。 $ python --version Python 3 . 12 . 0 requirements.txt 使用する外部ライブラリは以下の通りです。 google-cloud-aiplatform==1.42.1 gradio==4.19.2 main.py 使用するコードの全文を以下に記載します。 PROJECT_ID の値は、使用する Google Cloud プロジェクトの IDに置き換えてください。 import gradio as gr import vertexai from vertexai.generative_models import GenerativeModel, Content, Part # 環境変数の設定 PROJECT_ID = "myproject" # Google Cloud プロジェクトの ID LOCATION = "asia-northeast1" # Gemini モデルを使用するリージョン # Vertex AI API の初期化 vertexai.init(project=PROJECT_ID, location=LOCATION) # Gemini モデルとのチャットを行う関数 def gemini_chat (message, history, temperature, top_p, top_k, max_output_token): # Gemini モデルの初期化 generation_config = { "temperature" : temperature, # 生成するテキストのランダム性を制御 "top_p" : top_p, # 生成に使用するトークンの累積確率を制御 "top_k" : top_k, # 生成に使用するトップkトークンを制御 "max_output_tokens" : max_output_token, # 最大出力トークン数を指定 } gemini_model = GenerativeModel( model_name= "gemini-1.0-pro" , generation_config=generation_config ) # 会話履歴のリストを初期化 gemini_history = [] # 会話履歴のフォーマットを整形 for row in history: input_from_user = row[ 0 ] output_from_gemini = row[ 1 ] gemini_history.append(Content(role= "user" , parts=[Part.from_text(input_from_user)])) gemini_history.append(Content(role= "model" , parts=[Part.from_text(output_from_gemini)])) # Gemini モデルに会話履歴をインプット chat = gemini_model.start_chat(history=gemini_history) # Gemini モデルにプロンプトリクエストを送信 try : response = chat.send_message(message).text except IndexError as e: print (f "IndexError: {e}" ) return "Gemini からレスポンスが返されませんでした。もう一度質問を送信するか、文章を変えてみてください。" return response # UI に Generation Config を調整するスライダーを追加するためのリスト additional_inputs = [ gr.Slider(label= "Temperature" , minimum= 0 , maximum= 1 , step= 0.1 , value= 0.4 , interactive= True ), gr.Slider(label= "Top-P" , minimum= 0.1 , maximum= 1 , step= 0.1 , value= 1 , interactive= True ), gr.Slider(label= "Top-K" , minimum= 1 , maximum= 40 , step= 1 , value= 32 , interactive= True ), gr.Slider(label= "Max Output Token" , minimum= 1 , maximum= 8192 , step= 1 , value= 1024 , interactive= True ), ] if __name__ == "__main__" : # gemini_chat 関数を使用するチャットボットインターフェイスを起動 gr.ChatInterface( fn=gemini_chat, additional_inputs=additional_inputs ).launch() コードの解説 Gradio の ChatInterface に渡す関数の形式について コード末尾の ChatInterface(fn={関数名}).launch() で Gradio のチャットボットを起動しています。 if __name__ == "__main__" : gr.ChatInterface( fn=gemini_chat, additional_inputs=additional_inputs # ここは後ほど解説 ).launch() ChatInterface() の引数 fn に渡す関数は、ユーザーが送信したメッセージと過去の会話履歴を引数として受け取るように実装します（以下の第1、第2引数が該当）。 def gemini_chat (message, history, temperature, top_p, top_k, max_output_token): ユーザーが送信したメッセージは message に格納されます。 history には過去の会話履歴がリストとして渡されます。例えばユーザーが送信したメッセージを user_input_N 、モデルからのレスポンスを model_response_N とすると、以下のような形式で履歴が格納されます。 history = [ [user_input_1, model_response_1], [user_input_2, model_response_2], [user_input_3, model_response_3] ] 参考： How to Create a Chatbot with Gradio - Defining a chat function generation_config について Gemini 使用時にいくつかのパラメータを渡すことで、生成される回答の精度を調整することができます。パラメータの詳細については ドキュメント をご一読ください。 generation_config = { "temperature" : temperature, # 生成するテキストのランダム性を制御 "top_p" : top_p, # 生成に使用するトークンの累積確率を制御 "top_k" : top_k, # 生成に使用するトップkトークンを制御 "max_output_tokens" : max_output_token, # 最大出力トークン数を指定 } 当記事では、以下のようにしてチャットボットの UI 上にスライダーを配置し、メッセージ送信前に各種パラメータを手動で調整できるようにしています。 # UI に Generation Config を調整するスライダーを追加するためのリスト additional_inputs = [ gr.Slider(label= "Temperature" , minimum= 0 , maximum= 1 , step= 0.1 , value= 0.4 , interactive= True ), gr.Slider(label= "Top-P" , minimum= 0.1 , maximum= 1 , step= 0.1 , value= 1 , interactive= True ), gr.Slider(label= "Top-K" , minimum= 1 , maximum= 40 , step= 1 , value= 32 , interactive= True ), gr.Slider(label= "Max Output Token" , minimum= 1 , maximum= 8192 , step= 1 , value= 1024 , interactive= True ), ] if __name__ == "__main__" : # gemini_chat 関数を使用するチャットボットインターフェイスを起動 gr.ChatInterface( fn=gemini_chat, additional_inputs=additional_inputs ).launch() UI にパラメータを手動で調整するスライダーを配置する このように手動でパラメータの調整ができる機能をつける場合、メッセージ送信のたびにモデルの初期化を行う必要があります。レスポンスの速度などを気にする場合は、パラメータを固定化して Gemini モデルの初期化処理はグローバルスコープに記述します。 Gemini における会話履歴の形式について Gemini を利用する場合、過去の会話履歴は Content オブジェクトとしてモデルに渡します。 チャットボットのユーザーが送信したメッセージは role="user" 、Gemini からのレスポンスは role="model" として Content オブジェクトを作成します。 gemini_history.append(Content(role= 'user' , parts=[Part.from_text(input_from_user)])) gemini_history.append(Content(role= 'model' , parts=[Part.from_text(output_from_gemini)])) Gemini モデルとのチャットを開始する際に Content オブジェクトのリストを渡すことで、過去の会話履歴を用いたやり取りを行うことができます。 chat = gemini_model.start_chat(history=gemini_history) 動作確認 ローカルでチャットボットを実行する main.py を実行してローカルでチャットボットを起動します。 デフォルトではローカルホスト（127.0.0.1）のポート 7860 でチャットボットが起動されるため、ブラウザからアクセスします。 $ python main.py Running on local URL: http:// 127.0 . 0.1 : 7860 To create a public link, set `share= True ` in `launch()`. Gradio では gradio コマンドを使用することで、ホットリロードを使用してチャットボットを実行することもできます。 $ gradio main.py 参考： Developing Faster with Auto-Reloading チャットボットを使用する チャットボットの UI から適当なメッセージを送信してみます。 送信したメッセージの後に、Gemini Pro モデルからのレスポンスが表示されます。 ローカルで起動したチャットボットにメッセージを送信する チャットボットを外部に共有する Gradio では期限付きの外部公開 URL を発行することもできます。 この機能は、 launch() の引数に share=True を渡すことで利用できます。 gr.ChatInterface( fn=gemini_chat, additional_inputs=additional_inputs ).launch(share= True ) 発行された public URL にアクセスすると、インターネットからローカルで実行しているチャットボットにアクセスすることができます。 $ python main.py Running on local URL: http:// 127 . 0 . 0 .1:7860 Running on public URL: https://52b37dd2b7cf213999.gradio.live This share link expires in 72 hours. For free permanent hosting and GPU upgrades, run `gradio deploy` from Terminal to deploy to Spaces ( https://huggingface.co/spaces ) インターネットからローカルのチャットボットにアクセスする 参考： Quickstart - Sharing Your Demo Safety Attributes の調整 ResponseValidationError 作成したチャットボットとやり取りしていると、以下のようにエラーが発生してレスポンスが表示されない可能性があります。 チャットボットからのレスポンスでエラーが発生する このスクリーンショットはエラーを再現するための極端なメッセージ例ですが、チャットボットと普通にしりとりをしているだけであっても同じエラーに遭遇する可能性があります。 チャットボットのログには以下のように ResponseValidationError が出力されています。 これは、Gemini からのレスポンスに対していくつかの基準（後述）で検証が行われた結果、不適切な内容が含まれている可能性があると判断され、レスポンスがブロックされたことを示しています。 vertexai.generative_models._generative_models.ResponseValidationError: The model response did not completed successfully. Finish reason: 3 . Finish message: . Safety ratings: [ category: HARM_CATEGORY_HATE_SPEECH probability: NEGLIGIBLE , category: HARM_CATEGORY_DANGEROUS_CONTENT probability: NEGLIGIBLE , category: HARM_CATEGORY_HARASSMENT probability: MEDIUM blocked: true , category: HARM_CATEGORY_SEXUALLY_EXPLICIT probability: NEGLIGIBLE ] . To protect the integrity of the chat session, the request and response were not added to chat history . To skip the response validation, specify `model.start_chat ( response_validation =False ) ` . Note that letting blocked or otherwise incomplete responses into chat history might lead to future interactions being blocked by the service. このエラーメッセージでは、 HARM_CATEGORY_HARASSMENT というカテゴリで MEDIUM 、つまり中程度に不適切な可能性があるレスポンスがあったことがわかります。 Safety Attributes とは Safety Attributes とは、Gemini モデルが不適切なコンテンツを生成することを防ぐための評価カテゴリであり、このカテゴリに照らし合わせて不適切な可能性があると判断されたコンテンツは、ユーザーに返される前にブロックされます。 Safety Attributes には以下のようなカテゴリがあります。 Safety Attributes のカテゴリ 説明 Hate Speech (HARM_CATEGORY_HATE_SPEECH) 特定の属性に対するヘイトスピーチに関するもの。 Harassment (HARM_CATEGORY_HARASSMENT) 別の個人に対する嫌がらせに関するもの。 Sexually Explicit (HARM_CATEGORY_SEXUALLY_EXPLICIT) 露骨な性的表現に関するもの。 Dangerous Content (HARM_CATEGORY_DANGEROUS_CONTENT) 有害な商品、サービス、活動に関するもの。 Gemini API を使用する場合、API リクエストに Safety Settings としてブロックの閾値を設定することで、Safety Attributes のカテゴリごとにフィルターの強さを調整することができます。 何も設定していない場合は、デフォルトで BLOCK_MEDIUM_AND_ABOVE が設定されます。 閾値 説明 BLOCK_NONE レスポンスに対して Safety Attributes のフィルタを適用しない（常にレスポンスを表示する）。 BLOCK_ONLY_HIGH 不適切である可能性が高いレスポンスのみブロックする。 BLOCK_MEDIUM_AND_ABOVE デフォルトの閾値。不適切である可能性が中程度以上のレスポンスをブロックする。 BLOCK_LOW_AND_ABOVE 不適切である可能性が少程度であってもレスポンスをブロックする。 HARM_BLOCK_THRESHOLD_UNSPECIFIED デフォルトの閾値を使用する。 参考： Configure safety attributes コードの修正 Gemini モデルに対して Safety Settings を含むリクエストを送信するようにコードを修正します。 まず、 vertexai.generative_models からの import 文に HarmCategory 、 HarmBlockThreshold 、 ResponseValidationError を追記します。 from vertexai.generative_models import GenerativeModel, Content, Part, HarmCategory, HarmBlockThreshold, ResponseValidationError Safety Attributes のカテゴリごとにフィルターの強さを設定します。当記事では一律 BLOCK_ONLY_HIGH に設定します。 ここで設定できるカテゴリの種類は先ほど説明した4つに加え、不特定カテゴリ（ HARM_CATEGORY_UNSPECIFIED ）が存在します。 # 緩めの Safety Settings SAFETY_SETTINGS = { HarmCategory.HARM_CATEGORY_UNSPECIFIED: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_HATE_SPEECH: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_HARASSMENT: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT: HarmBlockThreshold.BLOCK_ONLY_HIGH, } send_message で Gemini にメッセージを送る際に、 safety_settings 引数を渡すように修正します。 また、 BLOCK_ONLY_HIGH にフィルターを緩めた後でも、不適切な可能性が高いと判定されたレスポンスは引き続きエラーが発生してしまうため、 ResponseValidationError について例外処理を実装し、フィルタに引っかかってしまった場合のユーザーへのメッセージを返すようにします。 # Gemini モデルとのチャットを行う関数 def gemini_chat (message, history): 〜〜〜省略〜〜〜 # Gemini モデルにプロンプトリクエストを送信 try : response = chat.send_message( message, safety_settings=SAFETY_SETTINGS # 引数に Safety Attributes の設定を追加 ).text except ResponseValidationError as e: # フィルタに引っかかった場合のエラー処理 print (f "ResponseValidationError: {e}" ) return "Gemini から不適切なレスポンスが返されたため、メッセージを表示できません。もう一度質問を送信するか、文章を変えてみてください。" except IndexError as e: print (f "IndexError: {e}" ) return "Gemini からレスポンスが返されませんでした。もう一度質問を送信するか、文章を変えてみてください。" return response 修正後の main.py 全文 Safety Attributes の設定を加えたコードの全文を以下に記載します。 import gradio as gr import vertexai from vertexai.generative_models import GenerativeModel, Content, Part, HarmCategory, HarmBlockThreshold, ResponseValidationError # 環境変数の設定 PROJECT_ID = "myproject" # Google Cloud プロジェクトの ID LOCATION = "asia-northeast1" # Gemini モデルを使用するリージョン # 緩めの Safety Settings SAFETY_SETTINGS = { HarmCategory.HARM_CATEGORY_UNSPECIFIED: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_HATE_SPEECH: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_HARASSMENT: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT: HarmBlockThreshold.BLOCK_ONLY_HIGH, } # Vertex AI API の初期化 vertexai.init(project=PROJECT_ID, location=LOCATION) # Gemini モデルとのチャットを行う関数 def gemini_chat (message, history, temperature, top_p, top_k, max_output_token): # Gemini モデルの初期化 generation_config = { "temperature" : temperature, # 生成するテキストのランダム性を制御 "top_p" : top_p, # 生成に使用するトークンの累積確率を制御 "top_k" : top_k, # 生成に使用するトップkトークンを制御 "max_output_tokens" : max_output_token, # 最大出力トークン数を指定 } gemini_model = GenerativeModel( model_name= "gemini-1.0-pro" , generation_config=generation_config ) # 会話履歴のリストを初期化 gemini_history = [] # 会話履歴のフォーマットを整形 for row in history: input_from_user = row[ 0 ] output_from_gemini = row[ 1 ] gemini_history.append(Content(role= "user" , parts=[Part.from_text(input_from_user)])) gemini_history.append(Content(role= "model" , parts=[Part.from_text(output_from_gemini)])) # Gemini モデルに会話履歴をインプット chat = gemini_model.start_chat(history=gemini_history) # Gemini モデルにプロンプトリクエストを送信 try : response = chat.send_message( message, safety_settings=SAFETY_SETTINGS # 引数に safety attributes の設定を追加 ).text except ResponseValidationError as e: # フィルタに引っかかった場合のエラー処理 print (f "ResponseValidationError: {e}" ) return "Gemini から不適切なレスポンスが返されたため、メッセージを表示できません。もう一度質問を送信するか、文章を変えてみてください。" except IndexError as e: print (f "IndexError: {e}" ) return "Gemini からレスポンスが返されませんでした。もう一度質問を送信するか、文章を変えてみてください。" return response # UI に Generation Config を調整するスライダーを追加するためのリスト additional_inputs = [ gr.Slider(label= "Temperature" , minimum= 0 , maximum= 1 , step= 0.1 , value= 0.4 , interactive= True ), gr.Slider(label= "Top-P" , minimum= 0.1 , maximum= 1 , step= 0.1 , value= 1 , interactive= True ), gr.Slider(label= "Top-K" , minimum= 1 , maximum= 40 , step= 1 , value= 32 , interactive= True ), gr.Slider(label= "Max Output Token" , minimum= 1 , maximum= 8192 , step= 1 , value= 1024 , interactive= True ), ] if __name__ == "__main__" : # gemini_chat 関数を使用するチャットボットインターフェイスを起動 gr.ChatInterface( fn=gemini_chat, additional_inputs=additional_inputs ).launch() 動作確認 エラーが発生したメッセージを再度送信してみると、正常なレスポンスが返ってきました。 フィルターを緩めた結果、同じ質問に対して正常にレスポンスが返ってくる また、より不適切な可能性が高いレスポンスにはフィルターが機能することも試してみます。例外処理に設定したエラーメッセージが返ってくることが確認できます。 緩いフィルターでもブロックされた場合は設定しておいたメッセージを返す エラーログを確認すると、 HARM_CATEGORY_HARASSMENT カテゴリで HIGH 、つまり高確率で不適切な内容のレスポンスがブロックされたことがわかります。 ResponseValidationError: The model response did not completed successfully. Finish reason: 3 . Finish message: . Safety ratings: [ category: HARM_CATEGORY_HATE_SPEECH probability: NEGLIGIBLE , category: HARM_CATEGORY_DANGEROUS_CONTENT probability: NEGLIGIBLE , category: HARM_CATEGORY_HARASSMENT probability: HIGH blocked: true , category: HARM_CATEGORY_SEXUALLY_EXPLICIT probability: NEGLIGIBLE ] . To protect the integrity of the chat session, the request and response were not added to chat history . To skip the response validation, specify `model.start_chat ( response_validation =False ) ` . Note that letting blocked or otherwise incomplete responses into chat history might lead to future interactions being blocked by the service. BLOCK_NONE に設定した場合の動作について ブロックの閾値を BLOCK_NONE に設定した場合、つまりフィルターを無効化した場合であっても、有害になり得る質問へのレスポンスがそもそも生成されないケースもあります。 有害なレスポンスが生成されないケース① 有害なレスポンスが生成されないケース② Google Cloud 上にチャットボットをデプロイする Cloud Run を使用する ここまでで作成したチャットボットを Google Cloud 上にデプロイしてみます。 当記事ではデプロイ先のサービスとして、サーバーレス コンテナ コンピューティングサービスである Cloud Run を使用します。 Cloud Run の詳細については以下の記事をご一読ください。 blog.g-gen.co.jp コードの修正 main.py 末尾の launch() の引数を、以下のように修正します。 if __name__ == "__main__" : # gemini_chat 関数を使用するチャットボットインターフェイスを起動 gr.ChatInterface( fn=gemini_chat, additional_inputs=additional_inputs ).launch(server_name= "0.0.0.0" , server_port= 8080 ) Dockerfile の作成 Cloud Run へのデプロイには Docker イメージを用意する必要があるため、 Docker Hub のサンプル を元に、簡単な Dockerfile を作成します。 FROM python:3.12-slim WORKDIR /usr/src/app COPY requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [ "python" , "./main.py" ] Cloud Run にデプロイ Dockerfile を作成したディレクトリで以下のコマンドを実行し、コンテナイメージのビルドと Cloud Run へのデプロイを同時に行います。 # Cloud Run サービスをデプロイ $ gcloud run deploy gradio-gemini --source . \ --region = asia-northeast1 \ --allow-unauthenticated ビルドされたコンテナイメージは、指定したリージョンに自動で作成される「cloud-run-source-deploy」という名前の Artifact Registory リポジトリに格納されます。 参考： ソースコードからデプロイする 動作確認 Cloud Run のデプロイが完了すると、 Service URL として Cloud Run のエンドポイントが出力されているので、ブラウザからアクセスします。 # デプロイ完了後のコマンド出力例 $ gcloud run deploy gradio-gemini --source . \ --region = asia-northeast1 \ --allow-unauthenticated This command is equivalent to running `gcloud builds submit --pack image = [ IMAGE ] .` and `gcloud run deploy gradio-gemini --image [ IMAGE ] ` Building using Buildpacks and deploying container to Cloud Run service [ gradio-gemini ] 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/d72a1c89-4e73-41ea-86b9-467976adfcb0?project = xxxxxxxxxxxx ] . ✓ Creating Revision... ✓ Routing traffic... ✓ Setting IAM Policy... Done. Service [ gradio-gemini ] revision [ gradio-gemini-00001-rkr ] has been deployed and is serving 100 percent of traffic. Service URL: https://gradio-gemini-ai4xxxxxxx-an.a.run.app Cloud Run 上のチャットボットにアクセスすることができました。 Cloud Run にデプロイしたチャットボットにアクセスする Cloud Run のアクセス元制御について Cloud Run にデプロイしたチャットボットのアクセス元制御を行いたい場合、Cloud Run の前段にロードバランサーを配置し、Identity Aware Proxy（IAP）による IAM 認証や Cloud Armor による IP アドレスの制限を実装します。 詳細な手順については以下の記事を参照してください。 blog.g-gen.co.jp 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では Cloud Run から VPC ネットワークに接続する際の、宛先サブネットの IP アドレス範囲に関する注意点を紹介します。 ※当記事に記載されている仕様は執筆時点のものであり、現在はアップデートにより改善されています。 宛先サブネットの IP アドレス範囲に関する既知の問題 ドキュメントの記載 代表的なケース 例外 対処法 プライベート IP アドレスを使用する場合 リソースを作り直す Compute Engine VM をプロキシとして使用する パブリック IP アドレスを使用する場合 宛先サブネットの IP アドレス範囲に関する既知の問題 ドキュメントの記載 2024年3月の時点では、Cloud Run のドキュメントには以下のような記載があります。 プライベート IP 経由でいずれかの宛先にアクセスする場合、宛先をサブネット 192.168.1.0/24 上にすることはできません。このサブネットを使用すると、Cloud Run が宛先と通信できなくなります。 これは、Cloud Run でサーバーレス VPC アクセスや Direct VPC Egress を使用して、VPC 内のリソースを宛先とする通信を行う場合に起こりうる問題です。 参考： Cloud Run の既知の問題 - VPC ネットワークの宛先にアクセスする場合のサブネットの制限 代表的なケース この問題の影響を受ける代表的なケースとして、Cloud Run から Cloud SQL、AlloyDB などのデータベースに接続するケースがあります。 Cloud Run からプライベート IP アドレスを使用して Cloud SQL（もしくは AlloyDB）インスタンスに接続する場合、以下のような構成となります。 "192.168.1.0/24" のサブネットにあるデータベースインスタンスに接続できない このとき、接続先となる Cloud SQL（AlloyDB）インスタンスのプライベート IP アドレスが 192.168.1.0/24 の場合、以下のようにデータベースへの接続に失敗してしまいます。 アプリケーションのログ 2024/03/06 22:53:45 db.Query: failed to connect to `host=192.168.1.5 user=myuser database=mydb`: dial error (dial tcp 192.168.1.5:5432: connect: no route to host) 例外 当社が2024年3月に行った検証では、Cloud Run jobs ではドキュメントの記載通り 192.168.1.0/24 の宛先に接続することができませんでしたが、Cloud Run services では接続できることを確認しました。 しかし、ドキュメントでは Cloud Run の種類を明記していないため、Cloud Run services でも引き続き接続できる保証はありません。 したがって、どちらの Cloud Run でも、接続先として 192.168.1.0/24 のサブネットを使用するのは避けたほうがよいでしょう。 対処法 プライベート IP アドレスを使用する場合 リソースを作り直す 理想的には、宛先となるリソースを作り直し、 192.168.1.0/24 以外の IP アドレス範囲をもつサブネットに接続するように Cloud Run を構成するのがよいでしょう。 Compute Engine VM をプロキシとして使用する どうしても作り直しができない状況では、 192.168.1.0/24 以外のプライベート IP アドレスをもつ Compute Engine VM にプロキシを構成し、これを経由するように接続を行います。 例として、Cloud SQL や AlloyDB に接続したい場合は、Google Cloud から提供されている Auth Proxy を Compute Engine VM で実行し、Cloud Run から Auth Proxy を経由してデータベースに接続します。 プロキシVMを経由して "192.168.1.0/24" のサブネットに接続する この方法では、Compute Engine VM の運用を考慮しなければならない点に注意が必要です。Cloud Run からデータベースに常時接続するようなケースでは、なるべくは避けたほうがよいでしょう。 パブリック IP アドレスを使用する場合 宛先が Cloud SQL や AlloyDB の場合は、Cloud Run で Auth Proxy を使用することで、パブリック IP アドレスでも安全にデータベースに接続することができます。 Cloud SQL Auth Proxy は Cloud Run の種類を問わずネイティブ機能として利用できます。 その反面、AlloyDB Auth Proxy は Cloud Run のマルチコンテナ機能を使用し、サイドカーコンテナとして実行する必要があります。 2024年3月現在、マルチコンテナ機能は Cloud Run services でしかサポートされておらず、Cloud Run jobs の場合は Cloud Run 側で AlloyDB Auth Proxy を実行することはできません。 Cloud Run から Auth Proxy を使用して Cloud SQL、AlloyDB に接続する方法については、以下の記事をご一読ください。 blog.g-gen.co.jp blog.g-gen.co.jp なお、AlloyDB におけるパブリック IP アドレスの利用は2024年3月時点でプレビュー機能である点には注意してください。 以下の記事で、Cloud Run services から AlloyDB Auth Proxy を使用して AlloyDB に接続する方法を解説しています。 blog.g-gen.co.jp 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。Google Cloud では、「 サービスアカウントキーの漏洩レスポンス （Service account key exposure response）」という組織ポリシーの制約により、サービスアカウントキーがパブリックな Git レポジトリ等に漏洩した場合でも、自動的に検知され、キーが無効化されます。当記事では意図的にキーを漏洩させた場合の検証結果をご共有します。 キーの漏洩検知・無効化の自動化 有効化 前提 設定画面へ遷移 制約を有効化 GitHub のパブリックレポジトリにキーを push 自動検知と無効化の確認 メールでの通知 WAIT_FOR_ABUSE の場合の挙動 キーの漏洩検知・無効化の自動化 サービスアカウントキーの漏洩レスポンス （Service account key exposure response）は、組織のポリシーの制約の1つであり、制約の正式な ID は constraints/iam.serviceAccountKeyExposureResponse です。 「組織のポリシー」自体の基礎については、以下の記事もご参照ください。 blog.g-gen.co.jp 「サービスアカウントキーの漏洩レスポンス」を有効化すると、サービスアカウントキー（サービスアカウントから発行された JSON 形式等の秘密鍵ファイル）が Git のパブリックレポジトリ等で公開されていることを Google が検知した際に、キーを自動で無効化してくれます。 有効化のモードとして、 DISABLE_KEY と WAIT_FOR_ABUSE の2種類があります。 モード 意味 DISABLE_KEY キーの漏洩が検知されると、自動で無効化する WAIT_FOR_ABUSE キーの漏洩が検知されても、自動で無効化しない。ただしキーが Google Cloud に悪影響を及ぼす方法で使用されている場合、無効化することがある 2024-06-16 以降、この制約は Google Cloud の すべての組織で DISABLE_KEY として有効化 されます（それ以前は無効化の状態です）。この自動的な有効化については、2024-03-19と2024-05-21にGoogle Cloud から管理者に対して Automatically disable publicly exposed Service Account keys という件名のメールで一斉配信されました。 詳細は、以下のドキュメントをご参照ください。 参考 : Automatically disable exposed service account keys 参考 : 特定のサービスの制約 有効化 前提 当作業を行うには、前提条件として、操作者の Google アカウントが、 組織レベル で 組織ポリシー管理者（roles/orgpolicy.policyAdmin） の IAM ロールを持っている必要があります。 権限を確認もしくは編集するには、「Google Cloud コンソール > IAM と管理」に遷移後、プロジェクトセレクタ（以下スクリーンショットの赤枠部分）が組織のドメイン名になるように変更してください。 なお、組織レベルの IAM を編集可能なのは、組織レベルで 組織の管理者（roles/resourcemanager.organizationAdmin） などの IAM ロールを持っている Google アカウント等だけです。もしくは、Google Workspace（Cloud Identity）の特権管理者も、同様の操作を行うことができます。 設定画面へ遷移 Google Cloud コンソールで、 IAM と管理 > 組織のポリシー に遷移します。画面上部のプロジェクトセレクタで、組織レベルが選択されていることを確認します。 制約の ID である constraints/iam.serviceAccountKeyExposureResponse でフィルタし、当該制約をクリックします。 制約を有効化 デフォルトでは「親のポリシーを継承する」になっています。これは組織レベルにおいては、デフォルト値と同等ですので、「カスタマイズ」に変更します。その下部の「ポリシーの適用」は「置き換える」を選択します。 その下部ではポリシーの値を「カスタム」に、ポリシーの種類を「許可」に、カスタム値として「DISABLE_KEY」を入力します。 最後に青いボタン「ポリシーを設定」を押下します。 GitHub のパブリックレポジトリにキーを push 検証用組織の検証用プロジェクトに作成した、サービスアカウントキーを GitHub の公開レポジトリに push します。 当検証では、安全性のため、使われていない組織に新規プロジェクトを作成し、ほとんどの API を無効化したうえで、何の権限も付けていないサービスアカウントを作成しました。実際にご自身で検証される場合、ご利用中の Google Cloud プロジェクトのサービスアカウントキーを意図的に漏洩させることは大きな危険を伴いますので、ご注意ください。 なお、 git push コマンドでリモートレポジトリにサービスアカウントキーファイルを push しようとした際、以下のような警告文が出て、push が中断されました。 GitHub の「シークレットスキャン」機能が Google Cloud のサービスアカウントキーを検知して、危険であるため push を拒否したものです。今回は検証のため、エラーメッセージ中の URL をクリックして、ロックを解除しました（なお、スクリーンショット中のレポジトリは現在では非公開に変更済みです）。 参考 : シークレット スキャンについて これで、公開レポジトリにサービスアカウントキーファイルが push され、誰でもアクセスできる状態になりました。 自動検知と無効化の確認 キーファイルを push してからわずか3分後、以下のようなログが、サービスアカウントキーの所属するプロジェクトに出力されました。 { " protoPayload ": { " @type ": " type.googleapis.com/google.cloud.audit.AuditLog ", " status ": {} , " authenticationInfo ": { " principalEmail ": " gcp-compromised-key-response@system.gserviceaccount.com " } , " requestMetadata ": { " callerIp ": " private ", " requestAttributes ": { " time ": " 2024-03-18T09:08:11.967994734Z ", " auth ": {} } , " destinationAttributes ": {} } , " serviceName ": " iam.googleapis.com ", " methodName ": " google.iam.admin.v1.DisableServiceAccountKey ", " authorizationInfo ": [ { " resource ": " projects/-/serviceAccounts/123456789012345678901 ", " permission ": " iam.serviceAccountKeys.disable ", " granted ": true , " resourceAttributes ": { " name ": " projects/-/serviceAccounts/123456789012345678901 " } } ] , " resourceName ": " projects/-/serviceAccounts/123456789012345678901/keys/xxxxx ", " request ": { " name ": " projects/-/serviceAccounts/sample-sa-exposure@sample-sa-exposure.iam.gserviceaccount.com/keys/xxxxx ", " @type ": " type.googleapis.com/google.iam.admin.v1.DisableServiceAccountKeyRequest " } } , " insertId ": " ope2zuep3w6x ", " resource ": { " type ": " service_account ", " labels ": { " unique_id ": " 123456789012345678901 ", " email_id ": " sample-sa-exposure@sample-sa-exposure.iam.gserviceaccount.com ", " project_id ": " sample-sa-exposure " } } , " timestamp ": " 2024-03-18T09:08:11.930390275Z ", " severity ": " NOTICE ", " logName ": " projects/sample-sa-exposure/logs/cloudaudit.googleapis.com%2Factivity ", " receiveTimestamp ": " 2024-03-18T09:08:12.357022232Z " } 検知と無効化が行われた際は、 gcp-compromised-key-response@system.gserviceaccount.com という Google Cloud 管理のサービスエージェントを principalEmail とするログが出力されます。 サービスアカウントキーのファイルがインターネットに公開されてから、検知・自動無効化まで3分足らずであることは、特筆すべき点でした。 メールでの通知 管理者に対して、以下のような E メールが通知されます。通知対象のメールアドレスは、エッセンシャルコンタクト（Essential Contacts）で管理が可能です。未設定の場合、組織の管理者ロール（ roles/resourcemanager.organizationAdmin ）を持つ Google アカウント等に対して通知されます。 参考 : Managing contacts for notifications WAIT_FOR_ABUSE の場合の挙動 サービスアカウントキーの漏洩レスポンス（ constraints/iam.serviceAccountKeyExposureResponse ）を WAIT_FOR_ABUSE モードにした場合の挙動は、以下のようになっています。 漏洩したサービスアカウントキーが自動的に無効になるとは限らない ただし Google Cloud に悪影響を及ぼす方法でキーが使用されている場合、無効にされることがある 漏洩が検知されても、Cloud Logging へ出力はされない 漏洩が検知されても、メール等の通知があるとは限らない もしキー漏洩に対する対策を確実にしたい場合は、 WAIT_FOR_ABUSE モードではなく、 DISABLE_KEY モードとすることが推奨されます。 なお、キーの漏洩が検知された場合、 WAIT_FOR_ABUSE モードであっても、以下のようなメールが Google Cloud から届く場合があります。ただしこれは当社の2024年3月の検証にもとづいた結果であり、今後もこの仕様が維持されるとは限りません。また、どの環境でも同じ挙動が保証されるわけではありませんため、ご留意ください。 Hello , Your Case #(ケース番号) for Google Cloud Platform has been updated. Case Subject: Leaked Credentials from Google Cloud Project (プロジェクト名) Case Comment : We have detected potentially compromised Service Account authentication credentials associated with the following Google Cloud Platform account: (サービスアカウント名)@(プロジェクトID).iam.gserviceaccount.com with key ID (Key ID) This key was found at the following URL: (GitHub のファイルリンク) Based on our investigation of the issue, we believe that you or your organization may have inadvertently published the affected Service Account credentials in public sources or websites (for instance, if credentials were mistakenly uploaded to a service like GitHub). Immediate action is required to secure your account(s). We strongly recommend that you take the following steps: --- Log in to the Google Cloud Console (cloud.google.com/console) and review the activity on your account. -- Revoke all (or listed) credentials for compromised Service Accounts. As every resource accessible to the Service Account may have been affected, it is best to revoke and reissue all credentials on potentially affected projects. For more details, review the instructions available at https://cloud.google.com/security/compromised-credentials ---Delete all unauthorized VMs or resources. ---Take immediate steps to ensure that your Service Account credentials are not embedded in public source code systems, stored in download directories, or unintentionally shared in other ways. The security of your Google Cloud Platform account(s) is important to us. You can find more information on securely using IAM at https://cloud.google.com/iam/docs/using-iam-securely and also recommend best practices for keeping service accounts keys safe at https://cloudplatform.googleblog.com/2017/07/help-keep-your-Google-Cloud-service-account-keys-safe.html. Please let us know if you have additional questions by responding to this message. Please review your case and take any actions as requested. If you have any questions or require immediate assistance, please reply to this email to contact Google Cloud Support. Thanks for choosing Google Cloud Platform. —The Google Team 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。 当記事では GitHub と Config Controller (Config Sync) を連携して Google Cloud (旧称 GCP) のリソース管理を自動化する方法について解説します。 当記事について 位置付け 前提知識 関連記事 変更点 概要 GitOps パイプラインの構成 アーキテクチャ 変更前の構成 変更後の構成 実装手順 概要 事前準備 Config Controller の設定 GitOps パイプラインの設定 source-repositories.yaml の編集 setters の定義 gitops/configsync/setters.yaml の定義 source-repo (GitHub ミラー) の手動作成 Cloud Build トリガーの手動作成 source-repo リポジトリへの Push ランディングゾーンのデプロイ 最後に 当記事について 位置付け 以前 Google Cloud のブループリントを利用してリソース管理を自動化する方法を紹介しました。 blog.g-gen.co.jp ブループリントを使用する場合、GitOps パイプライン (自動化の仕組み) におけるソースコード管理には Cloud Source Repositories が用いられます。 Cloud Source Repositories には2024年3月時点では Pull request 機能がないため、GitHub を導入して Pull request をはじめとした コラボレーション機能を補完して利便性を向上 させる意図があります。 参考： CSR GitOps Pipeline blueprint 参考： Cloud Source Repositories の特徴 参考： Pull requests 前提知識 内容の重複を避けるため、前述の過去記事で解説済みの事項は割愛しています。そのため、過去記事をお読みいただくことで当記事の理解が深まるものと考えます。 関連記事 前述の過去記事以外にも Config Controller に関する記事がございます。こちらも合わせてお読みいただけると幸いです。 blog.g-gen.co.jp 変更点 概要 今回紹介するアーキテクチャは、前述のブループリントを最大限活用しつつも、GitOps パイプラインに GitHub に導入します。 GitOps パイプラインの構成 定義ファイルの Push 先が GitHub に変わるため、Pull request や Merge といったコラボレーション機能の活用、Mergeトリガーの CI/CD (リソース管理の自動化) が実現できます。 アーキテクチャ 今回の変更を図示すると以下のとおりです。 ポイントは、 Cloud Source Repositories の source-repo を GitHub のミラーリングリポジトリに変更する点 にあります。 これにより、ブループリントを大幅に改修することなく、GitOps パイプラインの根幹にあたる Kpt によるレンダリング機能もそのまま活用できます。 変更前の構成 変更前 # コンポーネント 役割 1 source-repo ローカルから push されるファイル一式を格納するリポジトリ 2 Build トリガー 上記からレンダリングされたファイルを deployment-repo に push 3 deployment-repo レンダリングされたファイル一式を格納するリポジトリ 4 Config Sync deployment-repo に接続する GitOps サービス 変更後の構成 変更後 # コンポーネント 役割 1 source-repo (GitHub) ローカルから push されるファイル一式を格納するリポジトリ 2 source-repo (CSR) GitHub をミラーリングするリポジトリ 3 Build トリガー 上記からレンダリングされたファイルを deployment-repo に push 4 deployment-repo レンダリングされたファイル一式を格納するリポジトリ 5 Config Sync deployment-repo に接続する GitOps サービス 実装手順 概要 ここからは実装手順を解説しますが、詳細は前述の過去記事にて解説済みのため変更点を中心に解説します。 事前準備 こちらの手順は変更ありませんので詳細については過去記事をご確認ください。 参考： 事前準備 Config Controller の設定 こちらの手順は変更ありませんので詳細については過去記事をご確認ください。 参考： Config Controller の設定 GitOps パイプラインの設定 変更点のみ以降で解説します。 参考： GitOps パイプラインの設定 source-repositories.yaml の編集 過去記事には存在しない手順となります。 Cloud Source Repositories の source-repo は GitHub ミラーのリポジトリとして手動で作成するため、定義ファイルから削除します。 # 変更前 apiVersion : sourcerepo.cnrm.cloud.google.com/v1beta1 kind : SourceRepoRepository metadata : name : source-repo # kpt-set: ${source-repo} namespace : config-control # kpt-set: ${namespace} annotations : cnrm.cloud.google.com/blueprint : cnrm/gitops/v0.6.1 cnrm.cloud.google.com/project-id : project-id # kpt-set: ${project-id} --- apiVersion : sourcerepo.cnrm.cloud.google.com/v1beta1 kind : SourceRepoRepository metadata : name : deployment-repo # kpt-set: ${deployment-repo} namespace : config-control # kpt-set: ${namespace} annotations : cnrm.cloud.google.com/blueprint : cnrm/gitops/v0.6.1 cnrm.cloud.google.com/project-id : project-id # kpt-set: ${project-id} # 変更後、deployment-repo の定義だけ残す apiVersion : sourcerepo.cnrm.cloud.google.com/v1beta1 kind : SourceRepoRepository metadata : name : deployment-repo # kpt-set: ${deployment-repo} namespace : config-control # kpt-set: ${namespace} annotations : cnrm.cloud.google.com/blueprint : cnrm/gitops/v0.6.1 cnrm.cloud.google.com/project-id : project-id # kpt-set: ${project-id} setters の定義 project-id 等の値を自身の環境に合わせて修正する点については変更ありませんが、 source-repo は以下のように定義します。 参考： setters の定義 # 変更前 apiVersion : v1 kind : ConfigMap metadata : # kpt-merge: /setters name : setters annotations : config.kubernetes.io/local-config : "true" internal.kpt.dev/upstream-identifier : '|ConfigMap|default|setters' data : # This should be the project where you deployed Config Controller project-id : project-id project-number : "1234567890123" # This should be the name of your Config Controller instance cluster-name : cluster-name # You can leave these defaults namespace : config-control deployment-repo : deployment-repo source-repo : source-repo # 変更後 # cluster-name / project-id / project-number を環境固有の値に置換 # source-repo では GitHub リポジトリ `repo-owner/repo-name` の形式で定義する (GitHub リポジトリの URL から確認可能) # source-repo-meta という Key を用意し、値は `source-repo` と定義する apiVersion : v1 kind : ConfigMap metadata : # kpt-merge: /setters name : setters annotations : config.kubernetes.io/local-config : "true" internal.kpt.dev/upstream-identifier : '|ConfigMap|default|setters' data : # This should be the project where you deployed Config Controller project-id : sandbox-cc-test-prj project-number : "566560710327" # This should be the name of your Config Controller instance cluster-name : config-controller-1 # You can leave these defaults namespace : config-control deployment-repo : deployment-repo source-repo-meta : source-repo source-repo : ggenyutakei/source-repo gitops/configsync/setters.yaml の定義 GitOps パイプラインのデプロイの前に 、以下に従い configsync-dir の値を config/landing-zone に変更してください。 参考： 対処方法 source-repo (GitHub ミラー) の手動作成 過去記事には存在しない手順となります。 以下の公式ガイドを参考に、上記 setters.yaml で指定した GitHub リポジトリとミラーリングする Cloud Source リポジトリを作成してください。 参考： GitHub リポジトリのミラーリング Cloud Build トリガーの手動作成 過去記事には存在しない手順となります。 GitHub リポジトリへの Merge をトリガーにして Kpt によるレンダリング処理が実行されるよう、Cloud Build トリガーを手動で作成します。 手順は以下の公式ガイドを参照いただきつつ、パラメータについては以下に記します。 参考： ビルドトリガーの作成と管理 # パラメーター 設定値 1 イベント ブランチに push する 2 ソース 第1世代 3 リポジトリ ggenyutakei/source-repo 4 ブランチ .* 5 構成 Cloud Build 構成ファイル 6 ロケーション インライン ※詳細は以下 7 変数1 / 値1 _ADMIN_CLUSTER_NAME / config-controller-1 8 変数2 / 値2 _DEPLOYMENT_REPO / deployment-repo 9 変数3 / 値3 _SOURCE_REPO / ggenyutakei/source-repo # インラインYAML steps : - name : 'gcr.io/cloud-builders/gcloud:latest' args : - '-c' - > set -e gcloud source repos clone $_DEPLOYMENT_REPO . (git show-branch $BRANCH_NAME &>/dev/null) && (git checkout $BRANCH_NAME) || (git checkout -b $BRANCH_NAME) git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)') mkdir -p /deployment-workspace/config dir : /deployment-workspace id : Clone Deployment Repo entrypoint : /bin/sh volumes : - name : deployment-workspace path : /deployment-workspace timeout : 300s - name : 'gcr.io/kpt-dev/kpt:v1.0.0-beta.9' args : - '-c' - > set -eo pipefail SRC_DIR="." DEST_DIR="/hydrated-workspace/config" echo "Initializing kpt" kpt pkg init "$${SRC_DIR}" echo "Executing Kpt Functions..." kpt fn render "$${SRC_DIR}" --output="$${DEST_DIR}" --truncate-output= false echo "Removing local config" kpt fn eval "$${DEST_DIR}" -i gcr.io/kpt-fn/remove-local-config-resources:v0.1 id : Apply Hydration and Validation entrypoint : /bin/bash volumes : - name : hydrated-workspace path : /hydrated-workspace - name : 'gcr.io/cloud-builders/gcloud:latest' args : - '-c' - > set -e git pull origin $BRANCH_NAME || true # Ignore errors in case branch doesn't exist git rm -rf /deployment-workspace/config/* --ignore-unmatch cp -r /hydrated-workspace/config /deployment-workspace/ touch /deployment-workspace/config/.gitkeep # Configure Git to create commits with Cloud Build's service account git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)') git add -A git status if git diff --cached --exit-code; then echo "No changes" ; true ; else git commit -m "Resources from ${COMMIT_SHA}" && git push origin $BRANCH_NAME; fi printf " \n\n Latest deployment repo commit SHA: $(git rev-parse HEAD) \n " dir : /deployment-workspace id : Push Changes To Deployment Repo waitFor : - Apply Hydration and Validation entrypoint : /bin/sh volumes : - name : hydrated-workspace path : /hydrated-workspace - name : deployment-workspace path : /deployment-workspace timeout : 600s source-repo リポジトリへの Push GitOps パイプラインのデプロイに使用したファイル一式は、setters の中で指定した GitHub リポジトリ に Push してマージしてください。 CSR ではなく GitHub の source-repo に Push すること 参考： source-repo リポジトリへの Push ランディングゾーンのデプロイ 以下の手順でランディングゾーンをデプロイします。これ以外は過去記事から大きな変更はありません。 GitHub リポジトリでブランチを切る ランディングゾーンのブループリントをダウンロードして上記ブランチに配置する setters を定義して GitHub リポジトリ に push、Pull request をへて Merge する kpt によるレンダリング、 deployment-repo への push はパイプラインが行いますので、上記手順を実行するだけでランディングゾーンがデプロイされます。 参考： Landing Zone blueprint 参考： ランディングゾーンのデプロイ 最後に Config Controller は Kubernetes の仕組みを用いているため、 Reconciliation Loop に基づきリソースをあるべき状態を維持しようと作用します。 この機能は組織ポリシーや VPC Service Controls など、クラウド環境におけるセキュリティの根幹をなす 予防的統制 (ガードレール) と相性がよく、予期せぬ変更が発生した場合でも Config Controller が検知・是正してくれ、セキュリティ強化・維持、運用効率化の両方を実現します。 予防的統制機能を Config Controller で管理する方法については今後執筆予定です。 参考： Config Controller の概要 武井 祐介 (記事一覧) 2022年4月にジョイン。クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2024 に選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei

G-gen の荒井です。当記事では「データの移行（新規）」機能を使用して、Google Workspace アカウント間でメールデータを移行する方法をご紹介します。 機能の概要 仕様と制約 移行タイミングと対象データ 制約 移行手順 概要 手順1 : コンソールへアクセス 手順2 : 委任リクエストを送信 手順3 : 委任リクエストの確認 手順4 : 委任リクエストを承認 手順5 : 委任承認の確認 手順6 : csv アップロード 手順7 : 移行設定 手順8 : 移行の実行 機能の概要 「 データの移行（新規） 」は、Google Workspace を含む各種システムから Google Workspace アカウントへデータを移行するための機能です。 当機能の公開前は、メールデータ移行のための公式ツールは存在せず、ユーザーごとに個別に対応する必要がありました。 以下のようなユースケースが想定されます。 企業の合併による Google Workspace 組織の統廃合 グループ会社へ出向等による Google Workspace 組織間でのデータ移行 当機能の詳細な仕様は、以下の公式記事を参照してください。 参考 : データ移行（新規） - Google Workspace 管理者 ヘルプ 仕様と制約 移行タイミングと対象データ 当機能では、データ移行処理を実行したタイミングで保持されているメールアイテムが移行（複製）されます。 移行完了後に送受信したメールが継続的に移行されるわけではありません。 また、一度移行が完了した後に再度、移行を実行する場合、差分移行を行うことが出来ます。そのため、一度移行が完了したデータが重複して移行されることはありません。 制約 当機能では、Google Workspace 所属するアカウント間でのみ、移行が可能です。フリーの Gmail アカウントからのメールデータ移行には使用できません。 また、一度に移行できるアカウント数は移行元システムにより上限があります。詳細な仕様は、以下の公式記事を参照してください。 参考 : 新しいデータ移行サービスを使用したメールの移行について - Google Workspace 管理者 ヘルプ 移行手順 概要 移行手順は以下のとおりです。 手順1 : コンソールへアクセス 手順2 : 委任リクエストを送信 手順3 : 委任リクエストの確認 手順4 : 委任リクエストを承認 手順5 : 委任承認の確認 手順6 : csv アップロード 手順7 : 移行設定 手順8 : 移行の実行 手順1 : コンソールへアクセス 移行先組織での作業 特権管理者権限ユーザー で「データの移行 (新規)」 の画面へアクセスします。 https://admin.google.com/ac/migrate/googleworkspace 手順2 : 委任リクエストを送信 移行先組織での作業 データ移行先組織から移行元組織に接続するため、移行元組織の特権管理者へリクエストを送信します。 移行元メールアドレス と表示されいているテキストボックスに、移行元 Google Workspace 組織の特権管理者メールアドレスを入力して 承認をリクエスト をクリックしてください。 手順3 : 委任リクエストの確認 移行元組織での作業 手順2 で設定した移行元組織の特権管理者のメールボックスに届いた移行リクエストメールを確認します。 View authorization request をクリックし、管理コンソールに遷移します。 手順4 : 委任リクエストを承認 移行元組織での作業 委任リクエスト承認のダイアログボックスで 承認 をクリック 承認した内容が表示されます。 承認した内容の詳細については、ドメイン全体の委任 ページで確認することができます。 管理コンソール > セキュリティ > 概要 API の制御 > ドメイン全体の委任 > ドメイン全体の委任を管理 Data Migration (New) が今回承認したリクエストです。 手順5 : 委任承認の確認 移行先組織での作業 移行先組織では 承認を確認 ボタンが表示されているため、クリックし承認状況を確認します。 承認が確認されると 接続を解除 ボタンが表示されます。 ※ 接続を解除 はクリックしません。 手順6 : csv アップロード 移行先組織での作業 サンプル csv をダウンロードし、インポート用 csv ファイルを作成します。 作成した移行元・移行先アカウント情報を入力した csv ファイルをアップロードします。 csv ファイルは以下の通り必要情報を入力します。 項目 パラメータ Source GUser 移行元メールアカウント Target GUser 移行先メールアカウント ※ 最大 100 アカウントまで一度に移行可能です。 手順7 : 移行設定 移行先組織での作業 移行するデータのオプションを設定します。 項目 パラメータ メールの開始日 指定した日付以降のメールデータを移行します。 削除済みメールを移行する 移行元アカウントのゴミ箱に格納されたメールアイテムも移行します。 迷惑メールを移行する 移行元アカウントの迷惑メールに格納されたメールアイテムも移行します。 特定のラベルを移行対象から除外する 特定のラベルが付与されたメールアイテムを移行対象から除外します。 手順8 : 移行の実行 移行先組織での作業 移行準備が完了したら 移行を開始 をクリックし、データ移行を開始します。 移行中はステータスが表示されています。 移行完了したら、移行先メールアカウントのメールボックスを確認し移行完了です。 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 ・Google Cloud 認定資格 7冠 最近ハマっていることは、息子とのポケモンカード Follow @arapote_tweet

G-gen の荒井です。Windows OS が実行されているマシンに、 gcloud CLI をインストールする手順をご紹介します。 はじめに Google Cloud コンソール gcloud CLI 前提条件 Windows への gcloud CLI インストール手順 Powershell の起動 インストーラーのダウンロード Google アカウントによる認証 追加コンポーネントのインストール はじめに Google Cloud コンソール Google Cloud を操作するための代表的なインターフェイスとして、 Google Cloud コンソール と gcloud CLI があります。 Google Cloud コンソール は、Web ブラウザで操作可能な、Google Cloud の管理コンソールです。直感的に操作することができ、初心者から上級者まで幅広く使用されます。 このように、画面上のインターフェイスを主にマウスを使って操作する手法を GUI（Graphical User Interface）と言います。GUI の特徴として、以下が挙げられます。 直感的で操作方法がわかりやすい システムの状態が画面上に可視化されており、視覚的に把握しやすい gcloud CLI 一方の CLI （Command Line Interface）は、テキストベースの操作インターフェイスを指します。所定の構文に従ってコマンドを実行することで、システムに命令を与えます。 コマンドでの操作となるため、作業者の頭の中で操作イメージが明確になっている必要があり、中級者から上級者向けのインターフェースです。CLI の特徴として、以下が挙げられます。 同じ操作を繰り返す際などに、オペレーションミスを軽減することができる GUI 画面は頻繁に変更されるが、CLI はそれに比べて変更の頻度が低いため、手順書のメンテナンス工数が小さい 新機能は GUI よりも先に CLI でリリースされることが多い Google Cloud には gcloud と呼ばれる CLI ツールがあり、このツールを通してコマンドを実行します。 参考 : gcloud CLI の概要 また、Google Cloud コンソール上で CLI コマンドを実行可能な Cloud Shell というインターフェイスが存在します。Cloud Shell では、Web ブラウザから操作可能な仮想的な Linux 環境であり、CLI 操作を行うことができます。 参考 : Cloud Shell の仕組み 参考 : Cloud Shell を起動する 当記事では、gcloud コマンドを手元のパソコンから使用するために、gcloud CLI を Windows OS にインストールする方法をご紹介します。 前提条件 当記事では、Windows OS（PC または Windows Server）に gcloud CLI をインストールする方法をご紹介します。 gcloud CLI のインストールにあたり、以下の前提条件を満たしている必要があります。 gcloud CLI は Windows 8.1 以降または Windows Server 2012 以降で動作します インストールの際に管理者アカウントの承認が必要な場合があります Windows への gcloud CLI インストール手順 Powershell の起動 [Windows] > [Windows PowerShell] > [管理者として実行する] ※ 端末の設定により、実行ユーザーを選択してください。 インストーラーのダウンロード PowerShell で以下のコマンドを実行 (New-Object Net.WebClient).DownloadFile("https://dl.google.com/dl/cloudsdk/channels/rapid/GoogleCloudSDKInstaller.exe", "$env:Temp\GoogleCloudSDKInstaller.exe") & $env:Temp\GoogleCloudSDKInstaller.exe インストールウィザードが起動したら [Next >] をクリック 利用規約の内容を確認し [I Agree] をクリック インストールタイプを選択し [Next >] をクリック インストール先ディレクトリを選択し [Next >] をクリック インストールコンポーネントを選択し [Install] をクリック インストールの進捗バーが表示されるので、インストール完了まで待機 （10分以上かかる場合があります） インストールが完了したら [Finish] をクリック Google アカウントによる認証 gcloud CLI が起動し、 gcloud init が入力された状態となります。 " Y " を入力し、Google アカウント でログインします。 ※ ログインした Google アカウント で gcloud CLI を操作することとなります。（あとから変更が可能） Google アカウント ログイン画面がポップアップします。Googleアカウントでログインします。 Google アカウント へのアクセスリストを確認し [許可] をクリック 以下の画面が表示されたら、ログイン成功です。 参考 : gcloud CLI の認証が完了しました。 gcloud CLI に戻り、 gcloud init のセットアップを進めセットアップを完了します。 gcloud init の設定手順は以下をご参照ください。 参考 : gcloud CLI の初期化 追加コンポーネントのインストール 標準の gcloud CLI インストール手順ではインストールされないコンポーネントもあります。 gcloud CLI で gcloud components list を実行し、インストールされているコンポーネントを確認して、不足しているコンポーネントをインストールしてください。 コンポーネントの詳細については、下記をご参照ください。 参考 : gcloud CLI のコンポーネントの管理 荒井 雄基 (記事一覧) クラウドソリューション部 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。 Google Cloud 認定資格 7冠 現在は Google Workspace を中心に企業の DX 推進をサポート。 最近頑張っていることは、子どもがハマっている戦隊モノの踊りを踊れるようになること。

G-gen の武井です。当記事では VPC Service Controls のドライランモードについて解説します。 はじめに VPC Service Controls とは ドライランモード ドライランモードの仕組み ドライランモード 概要 構成 設定項目 Access Context Manager 設定 権限 アクセスレベル 境界 (ドライランモード) 実例解説 評価の流れ 実例1 ログ確認 原因の特定 詳細確認 考察と対応 実例2 ログ確認 原因の特定 詳細確認 その1 詳細確認 その2 考察と対応 最後に 関連記事 はじめに VPC Service Controls とは VPC Service Controls とは Google Cloud (旧称 GCP) 上のセキュリティ機能です。 境界 (perimeter) と呼ばれる論理的な囲いを設け、中から外、外から中の双方向で Google Cloud の各種サービス API への意図しないアクセスを防ぐことでサービスやデータへのセキュリティを強化します。 詳細は以下で解説しています。こちらもあわせてご確認ください。 blog.g-gen.co.jp ドライランモード ドライランモード (ドライラン構成) とは、設定した境界を仮想的に適用して Google Cloud 上のリソースやサービスに与える影響を評価するためのモードです。 潜在的な不備に気づかぬまま境界を実際に適用してしまうと、予期せぬアクセス拒否など、与える影響は少なくありません。 そのため、VPC Service Controls を利用する際はドライランモードで境界設定を適切に評価し、その上で実環境に適用する流れが適切と言えます。 参考： サービス境界のドライラン モード ドライランモードの仕組み ドライランモードで設定された境界は仮想的に適用されるため、アクセスが実際にブロックされることはありません。 一方 Cloud Logging にはログとして記録されます。そのため、管理者は記録されたログから潜在的な問題を特定して潰し込み、境界設定をあるべき形に導くことができます。 参考： ドライラン モードの利点 ドライランモード 概要 構成 このセクションでは以下のケースをもとに、ドライランモードによる境界設定の評価プロセスについて解説します。 検証プロジェクトにログを格納する BigQuery が存在するという前提で、境界が特定 IP アドレスからのアクセスを許可するように設定されているかを評価します。 構成イメージ 設定項目 上記構成は以下のサービスを利用しています。 # サービス 設定するもの 目的 1 VPC Service Controls 境界 (Perimeter) アクセス条件に基づき BigQuery API を保護する 2 Access Context Manager アクセスレベル (アクセス条件) コンテキスト (今回で言えばアクセス元 IP アドレス) を定義する Access Context Manager Access Context Manager はゼロトラストセキュリティを実現する BeyondCorp Enterprise のコンポーネントの一つです。 デバイス情報、アカウント情報、接続状況などの 背景情報 (コンテキスト) を定義することが可能で、VPC Service Controls に関連付けることができます。 参考： Access Context Manager の概要 参考： アクセスレベル 設定 権限 以降の設定操作を行うには、公式ドキュメントに従いプリンシパルに IAM ロールを付与する必要があります。 参考： IAM によるアクセス制御 アクセスレベル 特定の IP アドレスを送信元としたアクセスが境界内の BigQuery にアクセスできるよう、Access Context Manager で IP アドレスに基づくアクセスレベルを設定します。 アクセスレベルの設定例 設定方法は以下の公式ドキュメントを参考としています。 参考： ベーシック アクセスレベルを作成する 境界 (ドライランモード) 次に VPC Service Controls からドライランモードで境界を設定します。 以下の画像のように、 ドライランモード タブを選択した状態で 新しい境界 をクリックします。 ドライランモードで境界を設定 境界 (ドライランモード) の設定例 設定方法は以下の公式ドキュメントを参考としています。 参考： サービス境界を作成する 実例解説 評価の流れ ドライランモードによる境界設定が完了したら、以下の流れで設定を評価していきます。 エラーログの有無を確認する ログから metadata.violationReason フィールドを確認してエラーの原因を特定したうえで詳細を確認する ログ、境界設定、アクセスレベルを再確認して被疑箇所を特定して修正する 実例1 ログ確認 まずはエラーの有無をログからを確認します。 BigQuery にアクセスしたのち、Cloud Logging のログエクスプローラから以下のクエリを実行してエラーログを確認します。 図のようにエラーログが記録されていた場合は原因を特定していきます。 参考： ブロックされたリクエストの特定 境界に違反するアクセスがログとして記録 (実際のアクセスには影響しない) 原因の特定 以下は実際のエラーログです。(プロジェクト ID 等の値を一部加工しています) 46行目の metadata.violationReason (エラー原因) には NO_MATCHING_ACCESS_LEVEL と記されていることがわかります。 { " protoPayload ": { " @type ": " type.googleapis.com/google.cloud.audit.AuditLog ", " status ": { " code ": 7 , " message ": " (Dry Run Mode) Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: 9eFMI2pfYddKGBxQtFGub4I66MZpMSBV0li3aN0EkyYmGOiL6T0-Sg ", " details ": [ { " @type ": " type.googleapis.com/google.rpc.PreconditionFailure ", " violations ": [ { " type ": " VPC_SERVICE_CONTROLS ", " description ": " 9eFMI2pfYddKGBxQtFGub4I66MZpMSBV0li3aN0EkyYmGOiL6T0-Sg " } ] } ] } , " authenticationInfo ": { " principalEmail ": " yu...i@g-...p " } , " requestMetadata ": { " callerIp ": " 2.3.4.5 ", " requestAttributes ": {} , " destinationAttributes ": {} } , " serviceName ": " bigquery.googleapis.com ", " methodName ": " bigquery.datasets.get ", " resourceName ": " projects/111111111111 ", " metadata ": { " securityPolicyInfo ": { " organizationId ": " 333333333333 ", " servicePerimeterName ": " accessPolicies/596827900003/servicePerimeters/test " } , " @type ": " type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata ", " vpcServiceControlsUniqueId ": " 9eFMI2pfYddKGBxQtFGub4I66MZpMSBV0li3aN0EkyYmGOiL6T0-Sg ", " ingressViolations ": [ { " targetResource ": " projects/111111111111 ", " servicePerimeter ": " accessPolicies/596827900003/servicePerimeters/test ", " targetResourcePermissions ": [ " bigquery.datasets.get " ] } ] , " violationReason ": " NO_MATCHING_ACCESS_LEVEL ", " dryRun ": true , " intermediateServices ": [ " bigquery.googleapis.com " ] , " deviceState ": " Unknown ", " resourceNames ": [ " projects/111111111111/datasets/logdestination " ] } } , " insertId ": " 4fwkn7d1pqp ", " resource ": { " type ": " audited_resource ", " labels ": { " project_id ": " yutakei-test-prj ", " method ": " bigquery.datasets.get ", " service ": " bigquery.googleapis.com " } } , " timestamp ": " 2024-01-30T13:05:14.094591814Z ", " severity ": " ERROR ", " logName ": " projects/yutakei-test-prj/logs/cloudaudit.googleapis.com%2Fpolicy ", " receiveTimestamp ": " 2024-01-30T13:05:14.915645252Z " } 詳細確認 以下の公式ガイドを確認すると、 NO_MATCHING_ACCESS_LEVEL は以下のように記されています。 この問題は、IP アドレス、デバイス要件、またはユーザー ID が境界に割り当てられた上り（内向き）ルールまたはアクセスレベルと一致していない場合に発生します。 たとえば、監査レコードの callerIp フィールドに対応する IP アドレスが、サービス境界のアクセスレベルで定義された CIDR 範囲と一致しません。 参考： VPC Service Controls によってブロックされたリクエストのデバッグ 考察と対応 再度ログを確認すると、23行目の callerIp (呼び出し元の IP アドレス) が 2.3.4.5 となっています。 つまりこのエラーは、 アクセスレベルで定義した IP と呼び出し元 IP の不一致 が原因 (アクセスレベル設定のミス) で発生したものと考えられるため、当該設定を修正してエラーを解消します。 実例2 ログ確認 再度エラーの有無を確認します。すると先程とは異なるエラーが記録されています。 評価例1とは異なるエラーログが記録 原因の特定 以下は実際のエラーログです。(プロジェクト ID 等の値を一部加工しています) metadata.violationReason については先程同様 NO_MATCHING_ACCESS_LEVEL (アクセスレベルの不一致) とありますが、その他のフィールドで異なる特徴が見受けられます。 { " protoPayload ": { " @type ": " type.googleapis.com/google.cloud.audit.AuditLog ", " status ": { " code ": 7 , " message ": " (Dry Run Mode) Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: RmvvqAujYKJhXMxPzN-bkSzBmHGRHuIXUXvLuvR8Gbh_ZZYCtEFOlQ ", " details ": [ { " @type ": " type.googleapis.com/google.rpc.PreconditionFailure ", " violations ": [ { " type ": " VPC_SERVICE_CONTROLS ", " description ": " RmvvqAujYKJhXMxPzN-bkSzBmHGRHuIXUXvLuvR8Gbh_ZZYCtEFOlQ " } ] } ] } , " authenticationInfo ": { " principalEmail ": " service-222222222222@gcp-sa-logging.iam.gserviceaccount.com " } , " requestMetadata ": { " callerIp ": " private ", " requestAttributes ": {} , " destinationAttributes ": {} } , " serviceName ": " bigquery.googleapis.com ", " methodName ": " google.cloud.bigquery.v2.TableDataService.InsertAll ", " resourceName ": " projects/111111111111 ", " metadata ": { " @type ": " type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata ", " ingressViolations ": [ { " servicePerimeter ": " accessPolicies/596827900003/servicePerimeters/test ", " targetResource ": " projects/111111111111 " } ] , " dryRun ": true , " resourceNames ": [ " yutakei-test-prj ", " projects/222222222222 " ] , " securityPolicyInfo ": { " servicePerimeterName ": " accessPolicies/596827900003/servicePerimeters/test ", " organizationId ": " 333333333333 " } , " vpcServiceControlsUniqueId ": " RmvvqAujYKJhXMxPzN-bkSzBmHGRHuIXUXvLuvR8Gbh_ZZYCtEFOlQ ", " violationReason ": " NO_MATCHING_ACCESS_LEVEL ", " deviceState ": " Unknown " } } , " insertId ": " 3vwwvwd2hpq ", " resource ": { " type ": " audited_resource ", " labels ": { " service ": " bigquery.googleapis.com ", " method ": " google.cloud.bigquery.v2.TableDataService.InsertAll ", " project_id ": " yutakei-test-prj " } } , " timestamp ": " 2024-02-20T13:09:17.367737498Z ", " severity ": " ERROR ", " logName ": " projects/yutakei-test-prj/logs/cloudaudit.googleapis.com%2Fpolicy ", " receiveTimestamp ": " 2024-02-20T13:09:18.644856847Z " } 詳細確認 その1 20行目の principalEmail (呼び出し元アカウントの Email) を確認すると、Google アカウントではなく サービスアカウント であることがわかります。 サービスアカウントのメールアドレスは、 「@以前にプロジェクト ID、@以後にサービス名」 が含まれています。 このことから、 「 projects/2222222222222 の何らかのログシンクが、 projects/111111111111 の BigQuery API にアクセスしている」 可能性が考えられます。 参考： 書き込み ID (ログシンクのサービスアカウント) 詳細確認 その2 VPC Service Controls にはトラブルシューティングツールがあります。 47行目の vpcServiceControlsUniqueId (各違反に付与される一意の識別子) に記載の ID を VPC Service Controls のトラブルシューティングツールに入力することで、エラー原因を可視化して分析できます。 参考： VPC Service Controls のトラブルシューティングへのアクセス 以下はログに記録されていたユニーク ID RmvvqAujYKJhXMxPzN-bkSzBmHGRHuIXUXvLuvR8Gbh_ZZYCtEFOlQ を入力した際の画面です。 トラブルシューティングツールからも分析可能 前述同様、他プロジェクトで設定されたログシンクが当プロジェクトの BigQuery API に対してログをエクスポートしていることが推測できます。 考察と対応 これまでの結果から、当初の構成では不十分であることが評価の過程で判明しましたので実態に合わせて境界設定を修正します。 評価の過程で判明した実態に合わせてサービス境界を修正する 上り (内向き) ポリシー で以下のようにルールを追加して設定を保存します。 これにより、Inbound 方向で他プロジェクトのサービスアカウントが当プロジェクトのサービス境界内にある BigQuery API にアクセスできるようになります。 参考： 上り（内向き）ルールのリファレンス # 属性 項目 設定値 1 FROM ID 他プロジェクトのログシンクサービスアカウント 2 FROM ソース すべてのソース 3 TO プロジェクト 当プロジェクト 4 TO サービス BigQuery API (All methods) 上り (内向き) ポリシーの設定 サービス境界修正後、エラーログはすべて潰し込むことができました。 最後に VPC Service Controls はセキュリティを強固にしてくれる反面、潜在的な不備に気づかぬまま境界を適用してしまうとサービスに影響を与えてしまいます。 適用前にはドライランモードで設定を評価し、実際のサービスにどのような影響があるかを事前に確認することが重要です。 当記事が VPC Service Controls の適切な運用の一助になれば幸いです。 関連記事 その他 VPC Service Controls 関連記事については以下を参照ください。 blog.g-gen.co.jp 武井 祐介 (記事一覧) 2022年4月にジョイン。クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2024 に選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei