G-gen の杉村です。Google が提供するブラウザベースの IDE である Cloud Shell エディタや、コーディング支援 AI ツールである Gemini Code Assist を使い、Chromebook 上で開発環境を整備してみました。 はじめに 当記事について Cloud Shell エディタとは Gemini Code Assist とは ブラウザベースの IDE ブラウザ版 VS Code で開発する Cloud Shell エディタで開発する Cloud Code との統合 Gemini Code Assist の利用開始 利用開始手順 サブスクリプションの購入 ライセンスの割り当て Google Cloud プロジェクトで Gemini for Google Cloud API を有効化 Cloud Shell エディタで Gemini Code Assist を使う 有効化 コード生成 コード補完 スマートアクション チャットでの指示 その他 はじめに 当記事について G-gen では一部の部署を除き、従業員の作業端末として Chromebook を採用しています。Chromebook は、ChromeOS を搭載したノート型パソコン製品です。 ChromeOS とは、Google が開発した軽量な OS です。Linux カーネルをベースとしており、Google Chrome ブラウザを主なユーザーインターフェースとした、いわばブラウザベースの OS です。 Chromebook はブラウザベースの OS であることから、ローカルにインストールできるアプリケーションは限定的です。そのため当社のエンジニアは、Web アプリベースの IDE や、組み込みの Linux ターミナルを利用して開発を行っています。 当記事では、ブラウザから利用可能な Cloud Shell エディタや、Chromebook 上で生成 AI によるコーディング支援ツールである Gemini Code Assist などを活用しつつ、ソフトウェア開発のための環境整備を行う試みについて紹介します。 参考 : G-genの流儀。クラウドネイティブな10の働き方とは？ Chromebook Cloud Shell エディタとは Cloud Shell エディタ は、Google Cloud コンソールに組み込みの、Web ブラウザベースの IDE です。仮想的な Linux 環境である Cloud Shell と連携しており、Cloud Shell で管理されるファイルやコードベース、バイナリなどと連携したソースコード開発が可能です。Cloud Shell と連携しているため Google Cloud（旧称 GCP）との連携も容易であり、特に Google Cloud と関連する開発に力を発揮します。 Cloud Shell エディタは Code OSS をベースにしています。Code OSS は Microsoft が開発したオープンソースの IDE であり、VS Code はこれをベースにしています。つまり Cloud Shell エディタは、VS Code ライクなインターフェイスを備えていると言えます。 参考 : Cloud Shell エディタを起動する Cloud Shell エディタ Gemini Code Assist とは Gemini Code Assist は、Google が提供するコーディング支援 AI ツールです。VS Code、JetBrains IDE（IntelliJ、PyCharm など）、Cloud Workstations、Cloud Shell エディタなどに対応しており、Bash、C++、C#、Go、Java、PHP、Python、Ruby、SQL など多くのプログラミング言語に対応しています。英語はもちろん、日本語にも対応しており、コード補完やコメントからのコード生成、デバッグ支援、ドキュメント化支援などを行います。 Gemini Code Assist には Standard と Enterprise の2ティアがあり、使用可能な機能と料金に差があります。 参考 : Gemini Code Assist の概要 また、Gemini Code Assist には無償プランもあり、基本的なコーディング補助であれば一定の制限のもとで無料で使うことができます。 参考 : Gemini Code Assist: AI coding assistance for any language ブラウザベースの IDE ブラウザ版 VS Code で開発する ブラウザベースで利用可能な最も有名な IDE として、 ブラウザ版 VS Code があります。 https://vscode.dev/ にアクセスするだけで起動します。ローカルのファイルシステムとも連携可能であり、Chromebook 上で起動する Linux ターミナルのファイルを閲覧、編集できます。 参考 : https://vscode.dev/ ブラウザ版 VS Code はデスクトップ版と比較して一部の機能が制限されており、対応していない拡張機能（Extensions）も多いです。例として GitHub Copilot や Gemini Code Assist は、ブラウザ版 VS Code では利用できません。 ブラウザ版 VS Code Cloud Shell エディタで開発する 当記事では前述のとおり、Cloud Shell エディタを主なエディタとして利用します。 Cloud Shell エディタは、Google Cloud の一部として提供されています。Cloud Shell エディタを起動するには、Google アカウントにログインした状態で Google Cloud コンソール（ https://console.cloud.google.com/ ）を開き、右上の Cloud Shell ターミナルボタンを押下してターミナルを開いたうえで、「エディタを開く」ボタンを押下します。 Cloud Shell ターミナルを開き、エディタを開く Cloud Shell エディタが開いたところ 「新しいウインドウで開く」ボタンを押下することで、Google Cloud コンソールとは独立して、単一のウインドウ（タブ）としてエディタを起動することもできます。このとき、Cloud Shell エディタと Cloud Shell コンソールを同一ウインドウ内に表示したり、片方を非表示にすることができます。 「新しいウインドウで開く」ボタン エディタとターミナルを1画面に表示。片方を非表示にもできる また Cloud Shell エディタ（ https://ide.cloud.google.com/ ）と Cloud Shell コンソール（ https://shell.cloud.google.com/ ）のそれぞれの URL からアクセスすることで、Cloud Shell エディタと Cloud Shell コンソールをそれぞれ別のウインドウで開くこともできます。 参考 : Cloud Shell エディタのインターフェースの概要 Cloud Code との統合 Cloud Shell エディタはデフォルトで Cloud Code と統合されています。Cloud Code は Google が提供する IDE 用プラグインであり、Google Cloud での開発を支援するツール群です。IDE のエディタ画面の中から Cloud Run、Google Kubernetes Engine（GKE）、BigQuery データセット、Secret Manager などのリソースをブラウジングしたり、これらのリソースに対するデプロイの支援がされます。 参考 : Cloud Code and Gemini Code Assist IDE Plugins Gemini Code Assist の利用開始 利用開始手順 生成 AI による開発支援ツールである Gemini Code Assist の利用開始手順も見ていきましょう。Cloud Shell Editor には、Gemini Code Assist の無料枠が付帯しています。Cloud Shell Editor 上では、 週に50時間まで無料 で Gemini Code Assist を利用できます。 参考 : Gemini Code Assist: AI coding assistance for any language - Prototype with a no-cost environment from Google Cloud もし有償版を購入したい場合、サブスクリプションを購入してユーザーに割り当てます。Gemini Code Assist はユーザーごとに課金される月額または年額のサブスクリプション形式を取っています。2025年1月現在、Standard ライセンスの月額費用は $22.8 / ユーザー です。 参考 : Gemini Code Assist pricing overview ライセンスの費用は、Google Cloud の 請求先アカウント に紐づきます。ライセンス購入作業を行うには、請求先アカウントに対して請求先アカウント管理者（ roles/billing.admin ）ロールもしくは Consumer Procurement Order 管理者（ roles/consumerprocurement.orderAdmin ）ロールが必要です。請求先アカウントの詳細は以下の記事を参照してください。 blog.g-gen.co.jp ここからは、実際の利用開始手順を解説します。当記事で紹介する手順やスクリーンショットは2025年1月現在のものです。ユーザーインターフェイスは変更される可能性がありますので、最新の手順については以下の公式ドキュメントを参照してください。 参考 : Gemini Code Assist ライセンスを管理する サブスクリプションの購入 Google Cloud コンソールで「Gemini の管理」＞「GEMINI CODE ASSIST を管理」に遷移して、「サブスクリプションを管理」ボタンを押下し、サブスクリプションの管理画面へ遷移します。そこで、サブスクリプションのティアとライセンスの購入数を決定できます。この画面で、ライセンス費用の試算も確認できます。 参考 : サブスクリプション内の Gemini Code Assist ライセンス数を変更する サブスクリプションの購入画面 ライセンスの割り当て サブスクリプションの管理から、購入したライセンスをユーザー（Google アカウント）に割り当てます。ライセンスの自動割り当てを有効にすることもできます。自動割り当てが有効な場合、ライセンスの残数がある限り、新規ユーザーが Gemini Code Assist にアクセスした際にライセンスが自動的に割り当てられます。また指定した日数の間、非アクティブだったユーザーからは自動的にライセンスが剥奪されます。 参考 : Gemini Code Assist ライセンスを個々のユーザーに手動で割り当てる 参考 : Gemini Code Assist ライセンスを自動的に割り当てる ライセンスを割り当てられたユーザーはこれ以降、Gemini Code Assist を利用できます。 ユーザーへのライセンス割り当て画面 Google Cloud プロジェクトで Gemini for Google Cloud API を有効化 次に、Google Cloud プロジェクトで Gemini for Google Cloud API を有効化します。 Google Cloud コンソールで、 Gemini for Google Cloud の API 管理画面 に遷移します。画面左上のプロジェクトセレクタで対象のプロジェクトが選択されていることを確認して、「有効にする」ボタンを押下します。 参考 : Google Cloud プロジェクトで Gemini for Google Cloud API を有効にする Cloud Shell エディタで Gemini Code Assist を使う 有効化 Cloud Shell エディタで Gemini Code Assist の機能を使い始めるには、まず有効化作業が必要です。 最初に、Cloud Code の機能により、エディタと Google Cloud プロジェクトをリンクします。 ライセンスを割り当てたユーザーで Cloud Shell エディタを開き、画面下部の雲のマークの横に「Cloud Code - Sign in」と表示されている箇所をクリックします。Google Cloud API への認証を求められたら、「承認」を押下します。 次に、画面右下の Gemini マーク（星型のマーク）をクリックし、プルダウンメニューから「Gemini Code プロジェクトを選択」して Gemini for Google Cloud API を有効化したプロジェクトを選択します。斜め線が入っていた星型マークから、斜め線が消えたら準備完了です。 参考 : Gemini Code Assist によるコード Cloud Shell での Gemini Code Assist 有効化 コード生成 ソースコードに、実装したい処理を説明するコメントを入力し、Enter で改行した後に、Control + Enter を押下します。コードの提案がグレーの文字で表示されるので、提案を採用する場合は tab キーを押下します。 コメントでプロンプトを与えるコード生成 また、画面左側のメニューで Gemini の星型マークを選択し、チャット欄を表示させたうえで、ソースコードの特定の部分を選択して Gemini にチャットで指示を与え、新たなコードを生成させることもできます。 コード部分を選択したうえでのコード生成 コード補完 ソースコードを記述している途中に、Gemini Code Assist は自動的にコードの続きを提案します。提案を適用するには、tab キーを押下します。 自動的なコード補完 スマートアクション ソースコードの中で、該当するソースコード部分を選択すると電球マークが表示されます。この電球マークをクリックすると、「ユニットテストを生成する」など、その部分に関する様々なアクションが提案されます。 スマートアクション チャットでの指示 画面左側のメニューで Gemini の星型マークを選択し、チャット欄を表示させることで、様々な指示を与えることができます。ソースコードを説明させたり、ソースコードを生成させたり、あるいはテスト環境の構築に必要な gcloud コマンドラインを生成させたりすることもできます。 チャットで Gemini に指示を与える その他 その他に、Google Cloud を基盤とするアプリケーションの開発などに役立つ情報を記載します。 Google Cloud APIs をローカル PC や Cloud Shell 上から呼び出す際は、認証情報の設定が必要です。gcloud CLI を実行するときと、Python 等のクライアントライブラリを使ったプログラムを実行するときで、認証情報の設定方法が異なります。以下の記事では、自分の Google アカウントの認証情報をローカルのプログラムに設定する方法について解説しています。 blog.g-gen.co.jp Google Cloud のサーバーレスプログラム実行環境である Cloud Run functions でアプリケーションを開発する際に、 Functions Framework を使うことで、ローカル PC や Cloud Shell 上でテスト実行することができます。以下の記事では、Functions Framework の使い方について解説しています。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。当記事では Context-Aware Access の request.auth 属性を使ったアクセス制御でハマった際の顛末について解説します。 はじめに 背景 Context-Aware Access カスタムアクセスレベル request.auth 属性 事象の詳細 構成 カスタムアクセスレベルの定義と紐づけ 実際のエラー 原因と解決策 原因 解決策 当該ユーザーが利用するブラウザの Cookie を削除 Admin コンソールから当該ユーザーのログイン情報をリセット 動作確認 はじめに 背景 今回、以下の要件を満した場合に Google ドライブへのアクセスを許可するというアクセス制御を検証していました。 特定の IP アドレス からのアクセスであること Google アカウントが MFA (Multi-Factor Authentication) を有効にしていること 2段階目の認証要素に ハードウェアセキュリティキー (以降、セキュリティキー) を使用していること 実際の検証では適切なアクセスレベルを定義し、かつ、送信元の IP アドレスや MFA 要件をすべて満たしているにもかかわらず、Google ドライブへのアクセスが拒否される事象が発生しました。 Context-Aware Access Context-Aware Access （以降、CAA）とは、デバイス情報、アカウント情報、接続状況などの 背景情報 （コンテキスト）にもとづきアクセスを制御する、Google Workspace の一機能です。Frontline Standard、Enterprise Standard、Enterprise Plus、Cloud Identity Premium などのエディションで利用可能です。 CAA を設定することで、Google ドライブ、Gmail、Google カレンダー、Looker Studio などに条件付きのアクセス制御を適用できます。 参考： コンテキストアウェア アクセスの概要 カスタムアクセスレベル 今回のように、セキュリティキーによる認証をアクセス制御の条件とする場合、標準アクセスレベルではなく、 カスタムアクセスレベル を使用します。 カスタムアクセスレベルは Common Expression Language (CEL) と呼ばれる式言語で定義します。 参考： カスタムアクセスレベル 参考： CEL 言語の定義 request.auth 属性 カスタムアクセスレベルで認証要素を用いたルールを定義する場合、 request.auth 属性を使用します。 この属性は、アクセス元のプリンシパル情報や MFA における各種認証要素を指定することができます。 参考： request.auth の属性 事象の詳細 構成 今回の検証構成を図示したものが以下となります。 前述の要件を満たすユーザーのアクセスだけを許可する想定です。 セキュリティキーによる MFA は、組織部門の設定を利用して強制的に適用しています。 2段階目の認証要素はセキュリティキーを強制する組織部門を用意し、対象ユーザーを紐づけ カスタムアクセスレベルの定義と紐づけ カスタムアクセスレベルは以下のように定義しています。 # セキュリティキーによる MFA 認証と許可 IP アドレスをまとめたアクセスレベルを AND 条件で結合 request.auth.claims.crd_str.hwk == true && levels.source_ip_allow_list_test_sq7nlybc 上記のカスタムアクセスレベルで、対象の組織部門からのアクセスを制御するため、以下のように紐づけ設定をしています。 実際のエラー 上記の設定を行い、実際にアクセス確認をしたところ、 セキュリティキーによる MFA が有効なアクセスであってもアクセス拒否と判定されてしまいました。 まず、Google ドライブにアクセスするユーザーの MFA 設定は以下の通りで、セキュリティキーの登録が完了しています。 セキュリティキーによる MFA が有効な状態 解説のため一度ログアウトした状態から Google ドライブにアクセスすると、 パスワード認証 と2段階目の セキュリティキー認証 が要求されるため、指示に従い認証を実施します。 パスワード認証（1段階目） セキュリティキーによる認証（2段階目）が開始 セキュリティキーをタッチして認証を実施 セキュリティキーによる認証を行っているにもかかわらず、Google ドライブへのアクセスが拒否されました。 セキュリティキーによる認証にも関わらずアクセスが拒否される 原因については後述しますが、今回のハマりどころは、 セキュリティキーによる MFA 認証を判定するプロセス にありました。 原因と解決策 原因 エラーの原因は、 以前にログインした際のログイン情報 （ブラウザの Cookie や Google Workspace 側で持っているログイン情報） でした。 今回アクセス制御をテストしたユーザーは、組織部門移行前も MFA 自体は有効でしたが、認証要素には ソフトウェアキー を使用していました。 その際の Cookie やログイン情報が残っていたため、 カスタムアクセスレベルによる MFA 設定を判定する過程で既存のログイン情報が干渉した結果 、想定外のアクセス拒否を引き起こしていました。 解決策 以下を実施することでエラーは解消されました。 当該ユーザーが利用するブラウザの Cookie を削除 Google Chrome の場合、以下の画面遷移で Cookie を削除します。 3点アイコン > 閲覧履歴データを削除 > 全期間でCookieと他のサイトデータ (全チェックにはなっているものの、対象は Cookie) を削除 Admin コンソールから当該ユーザーのログイン情報をリセット 以下の画面遷移でログイン Cookie を無効化（リセット）します。 ディレクトリ > ユーザー > 対象ユーザー > セキュリティタブ > ログイン Cookie の [リセット] を押下 動作確認 上記の操作を行い再度アクセスすると Google ドライブが表示されました。 "Cookie をすべて削除して再度アクセスすると Google ドライブが表示された アクセス拒否だった際の認証プロセスに着目すると、以前は2段階目の認証プロセスのポップアップで 別の方法を試す を選択できる状態でした。 アクセス拒否の際はハードウェアキー以外の選択肢を選べる状況にあった しかし、アクセス許可となった際の2段階目の認証プロセスでは、認証方法を選択するポップアップは表示されず、すぐにセキュリティーによる認証が開始されました。 Cookie を削除し、ログイン情報をリセットしたことにより、2段階目の認証にセキュリティキーを用いていると正しく判定されました。 ログイン情報の削除により、パスワード認証成功後すぐにセキュリティキーによる認証が開始 武井 祐介 (記事一覧) クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2025 選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei

G-gen の三浦です。当記事では、Google Workspace の Data Loss Prevention（以下、DLP）を使用して、Google ドライブ上の機密情報が外部に漏れないようにする方法を紹介します。 概要 DLP とは 前提条件 検証内容 動作確認 DLP のルール設定（警告） 動作確認（警告） DLP のルール設定（ブロック） 動作確認（ブロック） 概要 DLP とは DLP （Data Loss Prevention、データ損失防止）は、組織内の重要情報を保護し、情報流出を防ぐための技術です。クレジットカード番号やマイナンバーなどの個人情報を自動的に検出し、保護します。 Google Workspace（以下、GWS）の DLP 機能は、Google Chat や Google ドライブに対応しており、社外秘の文書や顧客データなどの機密情報の意図しない共有や流出を防止するためのポリシーを設定できます。 参考 : DLP で機密情報を保護する 前提条件 DLP は、Google Workspace の特定のエディションで利用できます。詳細は以下のドキュメントをご参照ください。 参考 : Workspace の DLP を使用してデータの損失を防止する 検証内容 検証手順は次のとおりです。「警告」設定で動作を確認した後、「ブロック」に変更して、より強力な制御を確認します。 DLP のルール設定（警告） Google ドライブ内で「社外秘」という文字を含むファイルが社外へ共有される際に警告を表示する DLP ルールを設定します。 動作確認（警告） 条件を満たすファイルを作成し、社外共有時に警告が表示されることを確認します。 DLP のルール設定（ブロック） ルールを「社外共有時にブロック」に変更します。 動作確認（ブロック） 社外共有時にエラーが表示され、共有できないことを確認します。 動作確認 DLP のルール設定（警告） GWS の管理コンソール（URL : https://admin.google.com ）にログインします。 参考 : 管理コンソールにログインする [セキュリティ] > [アクセスとデータ管理] > [データの保護] に移動し、[ルールを管理] を選択します。 [ルールを管理] へ移動 [ルールを追加] をクリックし、[新しいルール] を選択します。 [新しいルール] を選択 ルール名を入力し、適用範囲を [全組織部門] または [特定の組織部門またはグループ] から選択します。特定の部門やグループだけを除外する設定も可能です。 ルール名と適用範囲の選択 [ドライブのファイル] を選択し、[続行] をクリックします。 アプリを選択 検出条件として、 社外秘 という文字列を含むファイルにルールが適用されるように設定します。 DLP の条件を定義 コンテキスト条件（例：社内ネットワークの IP アドレス以外から接続している場合のみ適用）も設定できます。今回は [なし] を選択し、[続行] をクリックします。 コンテキストの条件を選択 [外部との共有を警告する] を選択します。 操作を選択 通知設定を行います。 重大度レベル ：「低」「中」「高」から選択します。 アラートセンターに送信する ：有効にすることを推奨します。 通知先のメールアドレス ：通知を受け取るユーザーを設定します。 参考 : アラート センターについて アラートを選択 設定内容を確認し、[作成] をクリックします。 ルールの確認 動作確認（警告） マイドライブにテスト用の Google ドキュメントを作成します。 検知テスト用のファイル作成 作成したファイルを社外ユーザーと共有します。警告画面が表示されることを確認します。 警告の確認 管理者宛てに、DLP ルールに該当する操作の通知メールが届くことを確認します。 メール通知の確認 [セキュリティ] > [アラートセンター] へ移動し、アラートが通知されていることを確認します。 アラートセンターの通知確認 アラートを選択すると、詳細情報が確認できます。 アラートの詳細確認 参考 : ドライブの DLP ダッシュボードでインシデント、アラート、監査イベントを表示する 参考 : アラートの詳細を表示する DLP のルール設定（ブロック） [セキュリティ] > [アクセスとデータ管理] > [データの保護] > [ルールを管理] に移動し、作成したルールを選択します。 作成したルールを選択 [ルールを編集] をクリックします。 ルールを編集を選択 [操作] セクションで、条件を[外部共有をブロック]に変更します。[続行] をクリックしてルールを更新します。 条件の変更 動作確認（ブロック） 設定後、先ほど作成したファイルで社外ユーザーへの共有を試みます。エラーメッセージが表示され、共有ができないことを確認します。 ブロック確認 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の三浦です。当記事では、Google Workspace の エンドポイント管理を使用して、iPhone や Android 端末などのモバイル端末を管理する方法を紹介します。 概要 エンドポイント管理とは エンドポイント管理を使用するメリット 前提条件 基本管理と詳細管理 iOS デバイスの詳細管理 検証手順 エンドポイント設定 デバイスの登録（iOS/Android） デバイスの登録確認（iOS/Android） iOS のポリシー設定 Android のポリシー設定 動作確認 iOS の動作確認（ローカル保存不可） Android の動作確認（業務用アプリの配布） Android の動作確認（アカウントワイプ） 概要 エンドポイント管理とは エンドポイント管理 は、Google Workspace が提供するデバイス管理機能です。従業員が使用するモバイル端末やパソコンを一元的に管理し、組織のセキュリティポリシーを適用できます。 一般的に、このようなデバイス管理の仕組みは MDM （Mobile Device Management）と呼ばれます。MDM は、セキュリティポリシーの適用、アプリの配布、デバイスの監視、紛失・盗難時のデータ消去などの機能を提供するツール全般を指します。 参考 : エンドポイント管理 エンドポイント管理を使用するメリット Google Workspace のエンドポイント管理を使用すると、以下のようなメリットがあります。 メリット 詳細 Google Workspace とのシームレスな統合 アカウントと端末の管理を一元化できます。 コンテキストアウェア アクセス で Gmail や Google ドライブへの柔軟なアクセス制御も可能です。 追加費用や専用アプリ不要 Business Plus や Enterprise プランなどに標準搭載されており、 追加費用や専用アプリは不要 です。 Android ゼロタッチ登録と BYOD ゼロタッチ登録で多数の端末を簡単にセットアップできます。また個人所有デバイス（BYOD）においても業務データと個人データを分離できるようになり、セキュリティとプライバシーを両立できます。 ゼロタッチ登録 及び コンテキストアウェア アクセス の詳細な設定手順については、以下のドキュメントと記事を参照してください。 参考 : Android のゼロタッチ登録の設定 blog.g-gen.co.jp 前提条件 基本管理と詳細管理 Google Workspace のエンドポイント管理には、 基本管理 と 詳細管理 があります。Google Workspace のエディションによって、どちらの機能が利用できるかが決まります。 機能の名称 詳細 基本管理 デバイス登録、紛失時の Google アカウントリモート削除、 デバイスのセキュリティステータス（例：OS バージョン） の確認などの基本的な管理機能を提供します。 詳細管理 組織で許可されていないアプリを禁止する機能やデータ操作制限 など、より高度な制御が可能。個人所有デバイス（BYOD） やゼロタッチ登録により、柔軟にデバイスを管理できます。 参考 : モバイル管理機能の比較 iOS デバイスの詳細管理 iOS デバイスで詳細管理を行うには、Apple プッシュ証明書が必要です。この証明書は Apple Push Certificates Portal で取得できます。詳細は以下のドキュメントを確認してください。 参考 : 会社所有の iOS デバイスの管理を設定する 参考 : Apple プッシュ証明書を設定する 検証手順 以下の手順でエンドポイント管理を設定し、動作を確認します。 デバイスの登録（iOS/Android） 管理コンソールにデバイスを登録します。 iOS のポリシー設定 Google ドライブやドキュメントの業務データをローカル（例：Files アプリ）に保存できないよう制限します。 Android のポリシー設定 業務用アプリ（例：Google Gemini）をリモート配布するための設定をします。 iOS 動作確認（ローカル保存不可） 業務データが Files アプリに保存できないことを確認します。 Android 動作確認（業務用アプリの配布） 業務用アプリがインストールされ、アンインストールできないことを確認します。 Android 動作確認（アカウントワイプ） 管理コンソールから端末上の会社で使用している Google アカウントを削除します。 エンドポイント設定 デバイスの登録（iOS/Android） デバイスの Google Chrome で Google（ https://google.co.jp ）にアクセスします。 Googleにアクセス 会社で使用する Google アカウントでログインすることで、管理コンソールにデバイスが登録されます。 会社アカウントでログイン 参考 : iOS デバイスで Google Workspace を設定する 参考 : Android デバイスで Google Workspace を設定する デバイスの登録確認（iOS/Android） Google Workspace の管理コンソール（ https://admin.google.com ）にログインします。 参考 : 管理コンソールにログインする [デバイス] > [モバイルとエンドポイント] > [デバイス] へ移動し、フィルタから メールアドレス でデバイスを抽出し、登録されていることを確認します。 モバイル端末の登録確認 iOS のポリシー設定 [モバイルとエンドポイント] > [設定] > [iOS] > [データ共有] を選択します。 データ共有を選択 設定を適用する 組織部門 を選択し、[データ操作] の [編集] を選択します。 編集を選択 以下を選択し、[保存] または [オーバーライド] を選択します。 Google Workspace のデータが外部と共有される可能性のある操作を iOS で行うことをユーザーに許可しない 設定を選択 参考 : iOS デバイスでの過失によるデータ漏洩を防止する Android のポリシー設定 [モバイルとエンドポイント] > [設定] > [一般] > [全般] を選択します。 全般を選択 設定を適用する 組織部門 を選択し、[モバイル管理] の [編集] を選択します。 編集を選択 [カスタム] から Android を 詳細 に変更し、[保存] または [オーバーライド] を選択します。 設定を選択 [アプリ] > [ウェブアプリとモバイルアプリ] へ移動し、[アプリを追加] から [限定公開の Android アプリを追加] を選択します。 限定公開のAndroidアプリを追加を選択 検索バーに Gemini と入力し、リストから Google Gemini を選択し、[選択] を選択します。 Geminiアプリを選択 選択 アプリを適用する対象（全ユーザーまたは特定の組織部門や Google グループ）を選択し、[続行] を選択します。 インストール対象を選択 以下を選択し、[完了] を選択します。 自動インストール ユーザーがアプリをアンインストールできないようにする アプリへのアクセス方法を選択 参考 : 限定公開の Android アプリを Google Play で管理する 動作確認 iOS の動作確認（ローカル保存不可） Google ドキュメントアプリを起動し、会社で使っている Google アカウントを選択します。 Google ドキュメントファイルを開き、右上の […] を選択します。 ... を選択 [共有とエクスポート] > [コピーを送信] > [PDF] > [OK] を選択します。 コピーを送信を選択 ["ファイル"に保存] を選択すると、 ファイルを共有できません と表示され、ローカルに保存ができないことを確認します。 ファイルに保存を選択 ローカルへの保存失敗 Android の動作確認（業務用アプリの配布） 設定アプリから会社で使っている Google アカウントを選択し、仕事用プロファイルのセットアップを開始します。 仕事用プロファイルのセットアップ 参考 : 仕事用プロファイルの作成 以下メッセージが表示された場合、[モバイルとエンドポイント] > [デバイスの承認] から端末を選択し、[デバイスを承認] を選択します。 このデバイスは有効になっていません 管理者によるデバイスの承認が必要です。 デバイス未承認エラー モバイル端末の承認 セットアップが完了すると、設定したアプリが表示されます。業務用アプリはアプリのアイコンに鞄のアイコンが表示されます。 業務用アプリのインストール確認 業務アプリは、先の設定の通り、アンインストールしようとすると失敗します。 業務用アプリのアンインストール不可確認 Android の動作確認（アカウントワイプ） [デバイス] > [モバイルとエンドポイント] > [デバイス] から端末を選択します。 Android デバイスを選択 [その他] > [アカウントをワイプ] を選択します。 アカウントをワイプを選択 [アカウントをワイプ] を選択し、ワイプを実行します。 ワイプの実行 ワイプ後のデバイスステータス インストールした業務アプリが削除されていることを確認します。 業務アプリの削除確認 参考 : デバイスから企業データをワイプする 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の佐々木です。当記事では BigQuery 上で機械学習モデルを作成、評価、実行するための機能である BigQuery ML について解説します。 概要 BigQuery とは BigQuery ML とは BigQuery ML の使用方法 ユーザーインターフェース BigQuery Editions クエリのドライラン BigQuery ML でサポートされるモデル 内部モデル 外部モデル インポートされたモデル リモートモデル ユーザーが Vertex AI でデプロイしたモデル Google の生成 AI モデル タスク固有のソリューション 基本的な SQL ステートメント・関数 CREATE MODEL ステートメント ML.EVALUATE 関数 ML.PREDICT 関数 特徴量の前処理 自動前処理 手動前処理（TRANSFORM ステートメント） モデルのモニタリング BigQuery ML の料金 オンデマンド料金 BigQuery Editions の料金 外部モデルの料金 リモートモデルの料金 他の機械学習系プロダクトとの統合 Vertex AI Colab Enterprise 概要 BigQuery とは BigQuery は、Google Cloud のフルマネージド分析用データベース（データウェアハウス）サービスです。インフラ管理不要の分析用データベースを従量課金で使用できます。 当記事では BigQuery 自体の説明は割愛します。プロダクトの全容については以下の記事をご一読ください。 blog.g-gen.co.jp blog.g-gen.co.jp BigQuery ML とは BigQuery ML とは、BigQuery 上で機械学習モデルのトレーニングや予測、評価を行うことができる機能です。BigQuery で使われる標準 SQL 準拠の GoogleSQL を使用し、BigQuery 上のデータを使った機械学習が容易に実現できます。 通常、機械学習モデルの開発には、機械学習フレームワークに対する高度な知識とプログラミング技術が要求されます。そのような専門的スキルを持つメンバーの確保が難しい場合であっても、BigQuery ML では SQL の知識があればモデルの開発を行うことができます 。 BigQuery ML では、モデルのトレーニングや予測で使用するデータは BigQuery 自体に格納されているものをシームレスに使用することができ、 データの蓄積・モデルの学習・予測の実行が BigQuery 内で完結します。 これにより、モデル開発のための習熟が必要なツールが減り、また大量のデータ移動による時間・料金などのコストを抑えることができます。 参考： BigQuery の AI と ML の概要 BigQuery ML の使用方法 ユーザーインターフェース BigQuery ML は、以下のユーザーインターフェースで利用することができます。 Google Cloud コンソール bq コマンドライン ツール BigQuery REST API BigQuery に統合された Colab Enterprise ノートブック Jupyter ノートブックやビジネス インテリジェンス プラットフォームなどの外部ツール Google Cloud コンソールから使用すると、BigQuery で通常の SQL を実行するときと同様の使用感で BigQuery ML の機能を利用することができます。 5番目の Jupyter ノートブックを使った方法について、以下の記事では、フルマネージドの Jupyter ノートブック環境である Vertex AI Workbench から、マジックコマンド %%bigquery で BigQuery ML を使用する例が示されています。 blog.g-gen.co.jp BigQuery Editions BigQuery の課金モードとして オンデマンド を選択している場合、BigQuery ML を従量課金で使用することができます。 課金モードとして BigQuery Editions を選択している場合、BigQuery ML は Enterprise ティアおよび Enterprise Plus ティアでのみ使用することができます（Standard ティアでは使用不可）。 BigQuery Editions の詳細については以下の記事をご一読ください。 blog.g-gen.co.jp クエリのドライラン BigQuery ML に限らず、BigQuery ではクエリ実行前に ドライラン を行うことで、実際に処理を行う前に、処理されるデータ量やオンデマンドで発生する料金を見積ることができます。 ドライランにより、処理されるデータ量をクエリ実行前に確認できる 参考 : ドライラン BigQuery ML でサポートされるモデル 以降に紹介するのは2025年1月時点でサポートされているモデルです。最新のサポート状況については以下のリンク先を参照してください。 参考： BigQuery の AI と ML の概要 - サポートされているモデル 内部モデル BigQuery ML の組み込みのモデルとして、以下のモデルを使用して BigQuery 内部でトレーニングを行うことができます。 貢献度分析（Contribution analysis） （2025年1月現在、プレビュー） 線形回帰（Linear regression） ロジスティック回帰（Logistic regression） K 平均法クラスタリング（K-means clustering） 行列分解（Matrix factorization） 主成分分析（PCA: Principal component analysis） 時系列（Time series） モデルの作成時に使用する CREATE MODEL ステートメント（後述）の OPTIONS で、トレーニングに使用するモデルを指定できます。 外部モデル 以下のモデルは BigQuery ML の外部にあり、別の AI/ML サービスである Vertex AI を使用してトレーニングされます。 ディープ ニューラル ネットワーク（DNN: Deep neural network） ワイド＆ディープ（Wide & Deep） オートエンコーダ（Autoencoder） ブーストツリー（Boosted Tree） ランダム フォレスト（Random forest） AutoML インポートされたモデル BigQuery の外部でトレーニングされたカスタムモデルを Cloud Storage からインポートし、BigQuery ML で予測を実行することができます。Bigquery ML でインポートできるモデルの種類は以下の通りです。 Open Neural Network Exchange（ONNX） TensorFlow TensorFlow Lite XGBoost リモートモデル ユーザーが Vertex AI でデプロイしたモデル リモートモデル では、Vertex AI でデプロイした機械学習モデルを使用して予測を実行することができます。モデルが大きすぎて BigQuery にインポートできない場合などに使用します。 Vertex AI でデプロイしたモデルをリモートモデルとして使用する Google の生成 AI モデル BigQuery ML からは、 Gemini 等、Vertex AI で提供される Google の生成 AI モデル をリモートモデルとして利用できます。 以下の記事では、BigQuery ML のリモートモデルで Google 開発の大規模言語モデルである PaLM 2 を使用して、テキストの感情分析を行っています。 blog.g-gen.co.jp リモートモデルとして使用できる生成 AI モデルの最新情報については、以下のドキュメントを参照してください。 参考： Generative AI overview タスク固有のソリューション BigQuery ML から、Google Cloud が用意した、特定のタスクに特化した機械学習モデルの API（ 事前トレーニング済み API ）を利用できます。 利用可能な事前トレーニング済み API には以下のような種類があります。それぞれ GoogleSQL の関数を使用してリクエストを送信します。 タスク API の名前 GoogleSQL の関数 自然言語処理 Cloud Natural Language API ML.UNDERSTAND_TEXT 機械翻訳 Cloud Translation API ML.TRANSLATE 音声文字変換 Speech-to-Text API ML.TRANSCRIBE ドキュメント処理 Document AI API ML.PROCESS_DOCUMENT コンピュータ ビジョン Cloud Vision API ML.ANNOTATE_IMAGE 基本的な SQL ステートメント・関数 公式ドキュメントのチュートリアル を元に、BigQuery ML における基本的な SQL 文を解説します。 モデルや場面に応じてどのようなステートメント・関数が使用できるのかは、以下のドキュメントで解説されています。 参考： 各モデルのエンドツーエンドのユーザー ジャーニー CREATE MODEL ステートメント BigQuery ML では、GoogleSQL の CREATE MODEL ステートメントを使用してモデルのトレーニングを行います。 モデルの作成には CREATE MODEL の他に、データセット内に同じ名前のモデルが存在しない場合のみモデルを作成する CREATE MODEL IF NOT EXISTS や、同じ名前のモデルが存在していた場合は置き換える CREATE OR REPLACE MODEL ステートメントが利用できます。 以下は、 CREATE OR REPLACE MODEL ステートメントを使用して、 bqml_tutorial データセット内に sample_model という名前でロジスティック回帰モデルを作成する例です。 #standardSQL CREATE OR REPLACE MODEL `bqml_tutorial.sample_model` OPTIONS(model_type = ' logistic_reg ' ) AS SELECT IF (totals.transactions IS NULL , 0 , 1 ) AS label, IFNULL(device.operatingSystem, "" ) AS os, device.isMobile AS is_mobile, IFNULL(geoNetwork.country, "" ) AS country, IFNULL(totals.pageviews, 0 ) AS pageviews FROM `bigquery- public -data.google_analytics_sample.ga_sessions_*` WHERE _TABLE_SUFFIX BETWEEN ' 20160801 ' AND ' 20170630 ' 使用するモデルは OPTIONS の model_type= で設定しています。 FROM で指定したデータから、 SELECT で指定した特徴量を使用してモデルの学習を行っています。 Google Cloud コンソールや ML.TRAINING_INFO 関数を使用することで、モデルのトレーニング時の統計情報を確認することもできます。 クエリの結果としてトレーニング時の統計情報を確認できる トレーニングしたモデルの各種評価指標は、モデルの詳細からいつでも確認することができます。 作成したモデルの各種評価指標を確認する 参考： モデルの作成 ML.EVALUATE 関数 作成したモデルの評価は ML.EVALUATE 関数で行うことができます。 以下の SQL を実行することで、 ML.EVALUATE 関数の MODEL 引数で指定したモデルに対して評価を行います。 #standardSQL SELECT * FROM ML.EVALUATE( MODEL `bqml_tutorial.sample_model`, ( SELECT IF (totals.transactions IS NULL , 0 , 1 ) AS label, IFNULL(device.operatingSystem, "" ) AS os, device.isMobile AS is_mobile, IFNULL(geoNetwork.country, "" ) AS country, IFNULL(totals.pageviews, 0 ) AS pageviews FROM `bigquery- public -data.google_analytics_sample.ga_sessions_*` WHERE _TABLE_SUFFIX BETWEEN ' 20170701 ' AND ' 20170801 ' ) ) コンソール上での出力は以下のようになります。 ML.EVALUATE 関数によるモデルの評価 評価時に出力される指標はモデルの種類によって異なります。また、 ML.CONFUSION_MATRIX （混同行列）や ML.ROC_CURVE （ROC 曲線）などの関数も提供されています。 詳細は以下のドキュメントを参照してください。 参考： BigQuery ML モデルの評価の概要 ML.PREDICT 関数 作成したモデルを使用して予測を行うには、 ML.PREDICT 関数を使用します。 以下のように ML.PREDICT 関数の MODEL 引数で指定したモデルを使用して予測を行います。 #standardSQL SELECT country, SUM (predicted_label) AS total_predicted_purchases FROM ML.PREDICT( MODEL `bqml_tutorial.sample_model`, ( SELECT IFNULL(device.operatingSystem, "" ) AS os, device.isMobile AS is_mobile, IFNULL(totals.pageviews, 0 ) AS pageviews, IFNULL(geoNetwork.country, "" ) AS country FROM `bigquery- public -data.google_analytics_sample.ga_sessions_*` WHERE _TABLE_SUFFIX BETWEEN ' 20170701 ' AND ' 20170801 ' ) ) GROUP BY country ORDER BY total_predicted_purchases DESC LIMIT 10 コンソール上での出力は以下のようになります。 ML.PREDICT 関数による予測 参考： モデル推定の概要 特徴量の前処理 自動前処理 BigQuery ML では自動前処理として、モデルのトレーニング時に以下の前処理を自動で行っています。 欠損データの補完 値の変換（標準化、ワンホットエンコーディング、タイムスタンプの変換など） 自動前処理の詳細については、以下のドキュメントを参照してください。 参考： 自動特徴前処理 手動前処理（TRANSFORM ステートメント） TRANSFORM ステートメントを使用することで、前処理用の関数を使用することができます。 たとえば、以下の SQL では、 ML.QUANTILE_BUCKETIZE 関数で mother_age 列の バケット化（ビニング） を、 ML.FEATURE_CROSS 関数で is_male 列と mother_race 列の 特徴クロス を作成する前処理を行ってからモデルを作成しています。 #standardSQL CREATE MODEL `bqml_tutorial.natality_model` TRANSFORM( weight_pounds, is_male, gestation_weeks, ML.QUANTILE_BUCKETIZE(mother_age, 5 ) OVER() AS bucketized_mother_age, CAST (mother_race AS string) AS mother_race, ML.FEATURE_CROSS( STRUCT( is_male, CAST (mother_race AS STRING) AS mother_race ) ) is_male_mother_race ) OPTIONS ( model_type = ' linear_reg ' , input_label_cols = [ ' weight_pounds ' ] ) AS SELECT * FROM `bigquery- public -data.samples.natality` WHERE weight_pounds IS NOT NULL AND RAND() < 0 . 001 その他、手動前処理に使用できる関数については以下のドキュメントを参照してください。 参考： 手動での特徴の前処理 モデルのモニタリング ML.VALIDATE_DATA_SKEW 関数や ML.VALIDATE_DATA_DRIFT 関数を使用することで、トレーニングに使用したデータと、実際のモデル運用時に予測に使用されるデータ（サービングデータ）の統計情報を比較し、 データスキュー や データドリフト の発生を検知することができます。 データスキュー（Data Skew） とは、トレーニングで使用したデータの分布と、本番環境で提供されるデータの分布が大きく異なっていることにより、モデルの予測性能が下がってしまう現象のことです。トレーニングが適切に行えていない状況であると考えられます。 データドリフト（Data Drift） とは、本番環境で提供されるデータの分布が時間の経過とともに大きく変化してしまうことにより、モデルの予測性能が下がってしまう現象のことです。モデルの劣化と捉えてもいいでしょう。 モデルのモニタリングに使用できる関数の種類については、以下のドキュメントを参照してください。 参考： モデル モニタリングの概要 BigQuery ML の料金 BigQuery ML の料金の詳細および最新情報については、以下のドキュメントを参照してください。 参考： BigQuery ML pricing オンデマンド料金 BigQuery の課金モードがオンデマンドの場合、BigQuery で処理されるデータのバイト数に応じて課金が発生します。モデル作成と予測でバイト数あたりの料金単価が異なる点に注意が必要です。 たとえば、ロジスティック回帰モデルや線型回帰モデルの作成時のトレーニングでは $375/1TB 、評価・予測タスクでは $7.5/1TB の料金が発生します（東京リージョン、2025年1月時点）。 BigQuery Editions の料金 課金モードとして BigQuery Editions を利用する場合、BigQuery ML の料金は Editions の使用量に含まれます。 使用するモデルによって利用される Editions の割り当て が異なり、内部モデルの作成・予測には Editions の QUERY 割り当てが、外部モデルの利用には ML_EXTERNAL が利用されます。 外部モデルの料金 BigQuery 外部のモデルを使用してトレーニングを行う外部モデルでは、オンデマンドの料金もしくは BigQuery Editions の料金（BigQuery で処理されるぶんの料金）に加え、 Vertex AI のトレーニング料金 も発生します。 リモートモデルの料金 リモートモデルでも外部モデル同様に、 BigQuery で処理されるぶんの料金に加え、リモートモデルとして使用するサービスの料金が適用されます。 たとえば、リモートモデルとして Cloud AI Vision API を使用する場合は Cloud AI Vision API の料金 が、Vertex AI の基盤モデル（生成 AI モデル）を使用する場合は Vertex AI の料金 が追加で発生します。 他の機械学習系プロダクトとの統合 Vertex AI Vertex AI は機械学習モデルの開発に関わる様々な機能が統合されたプロダクトです。 Vertex AI には開発した機械学習モデルを集中管理するための Model Registry という機能があり、BigQuery ML で開発したモデルもここで管理することができます。 Model Registory で管理されているモデルはバージョニングや評価、デプロイを容易に行うことができます。Vertex AI の Endpoints 機能では、フルマネージドの実行環境にモデルをデプロイし、生成されたエンドポイントを使用してオンラインの予測を実行することができます。 Vertex AI の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Colab Enterprise Colab Enterprise は、Google Cloud 上に事前構築されたマネージドなノートブック環境を提供するサービスです。 Colab Enterprise のノートブックを使用して、ノートブックから BigQuery ML によるタスクを実行することができます。モデルの開発時に Python の機械学習ライブラリを使用した複雑なデータ処理が必要な場合などに活用できます。 Colab Enterprise のサービス詳細については、以下の記事をご一読ください。 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

本記事では、Eventarc と Workflows を利用して イベントドリブンに Cloud Run jobs を実行する方法をご紹介します。 概要 Cloud Run functions と Cloud Run jobs 検証の概要 Eventarc Workflows Cloud Storage の準備 Cloud Storage バケットの作成 Cloud Strage サービスエージェントへの権限付与 BigQuery テーブルの作成 Cloud Run jobs の作成 サービスアカウントの作成 Docker コンテナの作成に必要なリソースの作成 main.py requirements.txt Procfile Artifact Registry の作成 Artifact Registry にアップロード Cloud Run jobs の作成 Workflows の作成 サービスアカウントの設定 ワークフローの作成 cloud-run-job-workflow.yaml ワークフローのデプロイ Eventarc トリガーの設定 サービスアカウントの設定 Eventarc の作成 動作確認 概要 Cloud Run functions と Cloud Run jobs イベントドリブンにデータを処理するには、Cloud Run functions を使った方法などがあります。例えば、Cloud Storage にオブジェクトが格納されたら自動的に Cloud Run functions が起動するような処理を、非常に簡単に実装できます。しかし、Cloud Run functions には最大9分（イベントドリブン関数の場合）の実行時間制限があるなど、いくつかの制約があります。 当記事では、 Cloud Run jobs を使ってイベントドリブンな処理を実現する検証を行いました。Cloud Run jobs には、Cloud Run functions と比較して以下のようなメリットがあります。 最大実行時間が168時間であること（2025年1月現在では24時間を超える処理は Preview） タスクの並列実行数を明示的に指定可能であること Cloud Run jobs については以下の記事で解説していますので、ご参照ください。 blog.g-gen.co.jp また以下の記事では、Cloud Storage にテキストファイルが格納されたことを起点として Cloud Run functions を呼び出し、Vertex AI Gemini API で取得したテキストの要約結果を BigQuery に保存する処理を実装しています。 blog.g-gen.co.jp 当記事では、上記記事の Cloud Run functions の部分を Cloud Run jobs に置き換えて、イベントドリブンに Cloud Run jobs を実行する構成を実装します。 検証の概要 当記事で行った検証のアーキテクチャは以下の通りです。 ローカル PC から日報のテキストファイルを Cloud Storage にアップロード ファイルがアップロードされたことを検知して Eventarc トリガーが Workflows を起動 Workflows が受け取ったイベント情報を環境変数にセットして Cloud Run jobs を起動 Cloud Run jobs が Gemini で日報ファイルを要約し、結果を BigQuery テーブルに格納 Eventarc Eventarc は Google Cloud でイベントドリブンアーキテクチャを構築するためのフルマネージドサービスです。イベントの発生元から様々な宛先への転送を、サーバレスで容易に構築できます。 参考 : Eventarc の概要 参考 : イベント ドリブン アーキテクチャ 以下の記事では Eventarc を使ったアーキテクチャの例が紹介されていますので、ご参照ください。 blog.g-gen.co.jp Workflows Workflows （または Cloud Workflows）は Google Cloud のフルマネージドでサーバーレスなオーケストレーションサービスです。定義した順番に Cloud Run や Cloud Run functions を実行したり、BigQuery でクエリを発行するなど、様々な Google Cloud サービスを実行したり、任意の HTTP エンドポイントにリクエストを送ることができます。 参考 : ワークフローの概要 以下の記事で Workflows について解説していますので、ご参照ください。 blog.g-gen.co.jp Cloud Storage の準備 Cloud Storage バケットの作成 日報ファイルをアップロードするためのバケットを作成します。 バケット名に置き換えてください の部分を、作成されるバケット名に置き換えて、以下のコマンドを実行します。 BUCKET_NAME = " 作成されるバケット名に置き換えてください " gcloud storage buckets create gs:// ${BUCKET_NAME} --location = asia-northeast1 Cloud Strage サービスエージェントへの権限付与 Cloud Storage からのトリガーを作成する場合、Pub/Sub パブリッシャーのロールをプロジェクトの Cloud Storage サービスエージェントに付与する必要があります。 プロジェクト ID に置き換えてください の部分を、ご自身のプロジェクト ID に置き換えて、以下のコマンドを実行します。 PROJECT = " プロジェクト ID に置き換えてください " SERVICE_ACCOUNT = " $( gcloud storage service-agent --project = ${PROJECT}) " gcloud projects add-iam-policy-binding ${PROJECT} \ --member =" serviceAccount: ${SERVICE_ACCOUNT} " \ --role =' roles/pubsub.publisher ' BigQuery テーブルの作成 日報データを格納するための BigQuery テーブルを作成します。 以下のコマンドでは、 report という名前のデータセットと、 daily_report という名前のテーブルを作成します。 # データセットを作成 bq --location = asia-northeast1 mk \ --dataset \ ${PROJECT} :report # テーブルを作成 bq mk \ --table \ --schema date:DATE,name:STRING,text:STRING \ --clustering_fields date,name \ ${PROJECT} :report.daily_report name カラムと date カラムをクラスタ化してテーブルを作成することで、name カラムおよび date カラムでフィルタをかけるクエリを実行したときにスキャン量を削減して、パフォーマンスを向上させることができます。 Cloud Run jobs の作成 サービスアカウントの作成 Cloud Run jobs で使用するサービスアカウントを作成します。 Cloud Run jobs が Gemini API で文章を要約したり、BigQuery にデータを書き込んだり、ログを出力したりするために、以下のロールを Workflows で使用するサービスアカウントに付与する必要があります。 BigQuery データ編集者（ roles/bigquery.dataEditor ） BigQuery ジョブユーザー（ roles/bigquery.jobUser ） Storage オブジェクト閲覧者（ roles/storage.objectViewer ） Vertex AI ユーザー（ roles/aiplatform.user ） ログ書き込み（ roles/logging.logWriter ） 以下のコマンドを実行すると、 sa-daily-report-job という名前のサービスアカウントが作成され、その後、必要なロールが付与されます。 gcloud iam service-accounts create sa-daily-report-job gcloud projects add-iam-policy-binding ${PROJECT} \ --member = serviceAccount:sa-daily-report-job@ ${PROJECT} .iam.gserviceaccount.com \ --role = roles/bigquery.dataEditor gcloud projects add-iam-policy-binding ${PROJECT} \ --member = serviceAccount:sa-daily-report-job@ ${PROJECT} .iam.gserviceaccount.com \ --role = roles/bigquery.jobUser gcloud projects add-iam-policy-binding ${PROJECT} \ --member = serviceAccount:sa-daily-report-job@ ${PROJECT} .iam.gserviceaccount.com \ --role = roles/storage.objectViewer gcloud projects add-iam-policy-binding ${PROJECT} \ --member = serviceAccount:sa-daily-report-job@ ${PROJECT} .iam.gserviceaccount.com \ --role = roles/aiplatform.user gcloud projects add-iam-policy-binding ${PROJECT} \ --member = serviceAccount:sa-daily-report-job@ ${PROJECT} .iam.gserviceaccount.com \ --role = roles/logging.logWriter Docker コンテナの作成に必要なリソースの作成 主要な処理を Python コードで実行する main.py 、コード内で利用するパッケージをリスト化した requirements.txt 、そして Procfile を作成します。 Procfile とは、コンテナの起動時に呼び出されるプロセスを定義するファイルで、Python で Buildpack を利用する場合においては、ファイルの作成が必須になります。Buildpack を利用すれば、Dockerfile を作成せずにコードをコンテナイメージに変換することができます。 参考 : Google Cloud の Buildpack 参考 : Procfile について main.py import vertexai from vertexai.generative_models import GenerativeModel, Part, SafetySetting import os import argparse from datetime import datetime import logging from google.cloud import bigquery, storage import google.cloud.logging PROJECT_ID = os.environ.get( "PROJECT_ID" ) REGION = os.environ.get( "REGION" ) DATASET_ID = os.environ.get( "DATASET_ID" ) TABLE_ID = os.environ.get( "TABLE_ID" ) TABLE_NAME = f "{PROJECT_ID}.{DATASET_ID}.{TABLE_ID}" INPUT_BUCKET = os.environ.get( "INPUT_BUCKET" ) INPUT_FILE = os.environ.get( "INPUT_FILE" ) # Vertex AI の初期化 vertexai.init(project=PROJECT_ID, location=REGION) # Cloud Logging クライアントのインスタンス化 logger_client = google.cloud.logging.Client() logger_client.setup_logging() logger = logging.getLogger() logger.setLevel(logging.DEBUG) # Cloud Storage クライアントのインスタンス化 storage_client = storage.Client() # Cloud Storage からファイルを読んで Gemini に要約させる関数 def summarize_text_from_file () -> str : try : # Cloud Storage にあるファイルのテキストを読み取る bucket = storage_client.bucket(INPUT_BUCKET) blob = bucket.blob(INPUT_FILE) file_content = blob.download_as_string() text = file_content.decode( "utf-8" ) except Exception as e: logger.error(f "Error during reading file: {e}" ) raise try : # Gemini に要約させる model = GenerativeModel( "gemini-1.5-flash-002" ) generation_config = { "max_output_tokens" : 500 , "temperature" : 0.1 , "top_p" : 0.1 , } response = model.generate_content( f """以下の文章を要約してください: \n {file_content} \n 要約: \n """ , generation_config=generation_config ) except Exception as e: logger.error(f "Error during summarization: {e}" ) raise return response.candidates[ 0 ].content.parts[ 0 ].text # BigQuery のテーブルにデータを挿入する関数 def insert_into_bigquery (summary_text: str ): try : # ファイルの名前から日付と名前を取得する file = INPUT_FILE.split( "/" )[- 1 ] # フォルダ部分を消す date_str, name_txt = file .split( "_" ) name = name_txt.split( "." )[ 0 ] try : date_object = datetime.strptime(date_str, '%Y%m%d' ) formatted_date = date_object.strftime( "%Y-%m-%d" ) except ValueError : raise ValueError ( "Invalid filename date format. Expected YYYYMMDD." ) client = bigquery.Client(project=PROJECT_ID) table_ref = client.get_table(f "{TABLE_NAME}" ) # 重複にならないように、データを挿入する query = f """MERGE {TABLE_NAME} t USING ( SELECT CAST('{formatted_date}' AS DATE) AS date, '{name}' AS name, '''{summary_text}''' AS text) i ON t.date = i.date AND t.name = i.name WHEN MATCHED THEN UPDATE SET text = i.text WHEN NOT MATCHED THEN INSERT (date, name, text) VALUES (i.date, i.name, i.text)""" query_job = client.query(query) try : query_job.result() logger.debug(f "{INPUT_FILE} insert successful." ) except Exception as e: logger.error(f "{INPUT_FILE} insert failed: {e}" ) raise except Exception as e: logger.error(f "An unexpected error occurred while insert into bigquery: {e}" ) raise if __name__ == "__main__" : summary_result = summarize_text_from_file() insert_into_bigquery(summary_result) requirements.txt google-cloud-aiplatform== 1.73 . 0 google-cloud-bigquery== 3.25 . 0 google-cloud-logging== 3.11 . 2 Procfile Buildpacks では web プロセスを定義することが必須です。web プロセスを定義しなかった場合、 web process not found in Procfile というエラーが発生します。 ただし、今回は HTTP トラフィックを受信する必要がないので、実際には web プロセスは使用されません。 web: echo "no web" python: python Artifact Registry の作成 コンテナイメージを保存するための Artifact Registry 標準リポジトリを作成します。 以下のコマンドでは、 my-repo という名前のリポジトリを作成します。 gcloud artifacts repositories create my-repo \ --repository-format = docker \ --location = asia-northeast1 Artifact Registry にアップロード Buildpack を使用してコンテナイメージをビルドし、作成した Artifact Registry リポジトリにプッシュします。 以下のコマンドでは、ソースコードをビルドし、 my-repo リポジトリに daily-report-job というイメージ名でプッシュします。 gcloud builds submit --pack image =asia-northeast1-docker.pkg.dev/ ${PROJECT} /my-repo/daily-report-job Cloud Run jobs の作成 以下のコマンドでは、 daily-report-job という名前の Cloud Run jobs を作成します。 gcloud run jobs create daily-report-job \ --image = asia-northeast1-docker.pkg.dev/ ${PROJECT} /my-repo/daily-report-job:latest \ --command = python \ --args = main.py \ --region = asia-northeast1 \ --service-account = sa-daily-report-job@ ${PROJECT} .iam.gserviceaccount.com --set-env-vars = INPUT_BUCKET = ${BUCKET_NAME} , INPUT_FILE =input_file.txt, PROJECT_ID = ${PROJECT} , DATASET_ID =report, TABLE_ID =daily_report 環境変数 INPUT_BUCKET および INPUT_FILE は、実際には Workflows がジョブを起動する際に送られてきたイベント情報を利用してオーバーライドされます。 Workflows の作成 サービスアカウントの設定 Workflows で使用するサービスアカウントを作成します。 Workflows は環境変数をオーバーライドして Cloud Run jobs を起動し、実行結果を受け取るために、以下のロールを Workflows で使用するサービスアカウントに付与する必要があります。 Cloud Run デベロッパー（ roles/run.developer ） なお環境変数をオーバーライドして Cloud Run jobs を起動するロールとして、上記の他に「オーバーライドを使用する Cloud Run ジョブ エグゼキュータ（ roles/run.jobsExecutorWithOverrides ）」ロールがありますが、こちらだと実行結果を受け取るために必要な run.executions.get 権限が不足しているため、上記のロールとしています。 以下のコマンドを実行すると、 sa-cloud-run-job-workflow という名前のサービスアカウントが作成され、その後、必要なロールが付与されます。 gcloud iam service-accounts create sa-cloud-run-job-workflow gcloud projects add-iam-policy-binding ${PROJECT} \ --member = serviceAccount:sa-cloud-run-job-workflow@ ${PROJECT} .iam.gserviceaccount.com \ --role = roles/run.developer ワークフローの作成 Cloud Run jobs を実行するためのワークフローを、 cloud-run-job-workflow.yaml という YAML ファイルに定義します。 cloud-run-job-workflow.yaml main : params : [ event ] steps : - init : assign : - project_id : ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")} - event_bucket : ${event.data.bucket} - event_file : ${event.data.name} - job_name : daily-report-job - job_location : asia-northeast1 - run_job : call : googleapis.run.v1.namespaces.jobs.run args : name : ${"namespaces/" + project_id + "/jobs/" + job_name} location : ${job_location} body : overrides : containerOverrides : env : - name : INPUT_BUCKET value : ${event_bucket} - name : INPUT_FILE value : ${event_file} result : job_execution - finish : return : ${job_execution} ワークフローのデプロイ 以下のコマンドを実行してワークフローをデプロイします。 gcloud workflows deploy cloud-run-job-workflow \ --location = asia-northeast1 \ --source = cloud-run-job-workflow.yaml --service-account = serviceAccount:sa-cloud-run-job-workflow@ ${PROJECT} .iam.gserviceaccount.com Eventarc トリガーの設定 サービスアカウントの設定 Eventarc で使用するサービスアカウントを作成します。 Eventarc は Cloud Storage からイベントを受信して Workflows を起動するため、以下のロールを Eventarc で使用するサービスアカウントに付与する必要があります。 Eventarc イベント受信者（ roles/eventarc.eventReceiver ） ワークフロー起動元（ roles/workflows.invoker ） 以下のコマンドを実行すると、サービスアカウント sa-cloud-run-job-workflow-trigger が作成され、そのサービスアカウントに必要な権限が付与されます。 gcloud iam service-accounts create sa-cloud-run-job-workflow-trigger gcloud projects add-iam-policy-binding ${PROJECT} \ --member = serviceAccount:sa-cloud-run-job-workflow-trigger@ ${PROJECT} .iam.gserviceaccount.com \ --role = roles/eventarc.eventReceiver gcloud projects add-iam-policy-binding ${PROJECT} \ --member = serviceAccount:sa-cloud-run-job-workflow-trigger@ ${PROJECT} .iam.gserviceaccount.com \ --role = roles/workflows.invoker Eventarc の作成 以下のコマンドで、Eventarc トリガーを cloud-run-job-workflow-trigger という名前で作成します。 このコマンドでは、さきほど作成したサービスアカウント sa-cloud-run-job-workflow-trigger を指定したり、 destination-workflow オプションで宛先のワークフローである cloud-run-job-workflow を指定しています。 gcloud eventarc triggers create cloud-run-job-workflow-trigger \ --location = asia-northeast1 \ --destination-workflow = cloud-run-job-workflow \ --destination-workflow-location = asia-northeast1 \ --event-filters =" type=google.cloud.storage.object.v1.finalized " \ --event-filters =" bucket= ${BUCKET_NAME} " \ --service-account = sa-cloud-run-job-workflow-trigger@ ${PROJECT} .iam.gserviceaccount.com 動作確認 まずは、日報のテキストファイルを用意します。例として、以下のテキストが書き込まれたテキストファイル 20241231_山田太郎.txt を作成します。 今日の業務内容: 午前: 昨日取得したオンラインストアの顧客行動ログデータ(約5TB)のBigQueryへのロード作業を実施。Dataflowパイプラインを用いて、パーティショニングとクラスタリングを行い、クエリパフォーマンスの最適化を図った。ロード完了後、データの整合性を確認し、データ品質に問題がないことを検証した。ロード時間は予想通り約3時間であったが、一部データの重複が確認されたため、重複データ削除クエリを記述し実行。約1%の重複データが削除された。 午後: BigQuery上で顧客セグメンテーションのためのSQLクエリを開発・実行。購買頻度、平均購入額、最終購入日などを基に、"高頻度購入者", "低頻度低額購入者", "休眠顧客" の3つのセグメントに分類するクエリを作成した。各セグメントの人口統計データ(年齢、性別など)との関連性を分析するために、ユーザー属性テーブルと結合し分析を実施。 分析結果を可視化するために、Looker Studioを用いたダッシュボードを作成開始。本日中に主要指標の表示まで完了させた。 その他: プロジェクトXの今後の分析計画についてチームリーダーとミーティングを実施。 顧客チャーン予測モデル構築のためのデータ準備について議論し、必要なデータ項目とデータソースを特定した。来週から機械学習モデルの構築に着手する予定。 また、BigQueryの料金を監視し、コスト最適化のための検討を開始した。パーティショニングとクラスタリングの効果を検証し、更なる最適化の可能性を探る。 課題と問題点: データログに含まれる一部の顧客IDに重複が見られた。データ収集元でのデータクレンジングの必要性を指摘し、関係部署への報告を検討している。 Looker Studioダッシュボードの作成に時間がかかっている。より効率的な可視化ツールの検討が必要かもしれない。 明日の予定: プロジェクトX: 顧客チャーン予測モデル構築のためのデータ準備開始。必要なデータの抽出と前処理を行う。 プロジェクトY (準備段階): プロジェクトYの要件定義書作成に向けて、関係者との打ち合わせを行う。 コメント: 本日、プロジェクトXのデータ分析が大きく進展した。BigQueryとDataflowパイプラインを用いたデータ処理は効率的であった。しかし、データ品質に関する課題も浮き彫りになったため、関係部署との連携を強化し、データクオリティ向上に努める必要がある。 この日報ファイルを Cloud Storage にアップロードします。 gcloud storage cp 20241231_山田太郎.txt gs:// ${BUCKET_NAME} BigQuery を見ると、テーブルに日報のデータが書き込まれていることが確認できました。 以下は、要約後の文章です。 このログは、BigQueryとDataflowを用いたデータ処理に関する報告です。 **午前:** 5TBのオンラインストリームデータのBigQueryへのロード作業を実施。Dataflowパイプラインを用いてパーティショニングとクレンジングを行い、クエリの最適化を実現しました。処理時間は予想通り約3時間でしたが、一部データの欠損が確認され、1%のデータが復旧不能でした。 **午後:** BigQuery上で、課金タイプ、平均課金額、最終課金日などを基に、「高課金ユーザー」、「低課金ユーザー」、「潜在顧客」の3つのセグメントに分類するSQLクエリを作成・実行しました。各セグメントのユーザー属性（年齢、性別など）との関連性を分析し、Looker Studioで視覚化しました。 **その他:** プロジェクトXの今後の分析計画として、チャーン予測モデルとプロモーション施策のデータ整備を決定しました。BigQueryのログを監視し、コスト最適化のための改善策を検討します。パーティショニングとクレンジングのポイントを明確化し、今後のデータ品質向上に繋げます。 **課題と問題点:** 一部の顧客IDにデータ欠損が見つかりました。データの完全性確保のため、データクレンジングとモニタリングの強化が必要です。Looker Studioでのダッシュボード作成に時間がかかっています。より効率的な可視化方法の検討が必要です。 **今後の予定:** プロジェクトXでは、チャーン予測のためのデータ整備と必要なデータの抽出・前処理を行います。プロジェクトY(チャーン予測モデル)では、要件定義書を作成し、関係者との打ち合わせを行います。 全体として、データ処理は概ね成功しましたが、データ欠損や可視化の効率性といった課題が残っており、今後の改善が必要であることが報告されています。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-genの杉村です。Vertex API 経由で Gemini モデルへ API リクエストを送信する際に、エラーコード 429 で Resource exhausted, please try again later. というエラーが頻繁に発生しました。その原因と対処法を紹介します。 事象 原因 対処法 3つの対処案 グローバルエンドポイント エクスポネンシャルバックオフ Provisioned Throughput 事象 Vertex API 経由で Gemini モデルへ API リクエストを送信した際、エラーコード 429 で Resource exhausted, please try again later. というエラーが発生しました。レスポンス内の status は RESOURCE_EXHAUSTED です。 しばらくして再試行するとリクエストが成功するときがありますが、しばしば同じエラーとなります。 原因 このエラーは、処理のためのリソースが Google 側で枯渇することを防ぐため、Google によって API 利用が制限されていることを意味しています。Google は随時、物理インフラストラクチャを強化していますが、Gemini API は多くのユーザーに利用されているため、しばしばこのメッセージが表示されることがあります。 参考 : エラーコード 429 API 経由での Gemini モデルの呼び出しには、 動的共有割り当て （Dynamic shared quota、 DSQ ）という仕組みが使われています。DSQ は、通常の Google Cloud API の割り当て（クォータ）と異なり、静的ではありません。Gemini の割り当ては全ユーザーからの需要によって動的に変更されます。同じソースからのリクエストが短い時間で急増すると、優先度が調整され、 429 RESOURCE_EXHAUSTED が発生する可能性があります。時間を置いて再実行することで、再びリクエスト可能になります。 対処法 3つの対処案 次のいずれかの対処法が考えられます。 グローバルエンドポイント を利用する アプリケーションに エクスポネンシャルバックオフ （exponential backoff、指数バックオフ）を実装する Provisioned Throughput （プロビジョニングされたスループット）を購入する グローバルエンドポイント 最も単純な対策は、 グローバルエンドポイント を使うことです。グローバルエンドポイントを使用すると、リージョンエンドポイントを使うのに比べて、エラーコード429のリスクを減らすことができます。global ロケーションを指定して Gemini API へリクエストすることで、リソースが空いているリージョンにリクエストが自動的にルーティングされます。 どのリージョンでデータが処理されるかは任意に決定されるため、セキュリティ要件等でデータを処理する地域が厳密に指定されている場合は、この方法は使わないでください。 グローバルエンドポイントの URI は、以下のようになります。 https://aiplatform.googleapis.com/v1/projects/test-project/locations/global/publishers/google/models/gemini-2.0-flash-001:generateContent 参考 : Deployments and endpoints - Global endpoint エクスポネンシャルバックオフ エクスポネンシャルバックオフ （指数バックオフ）は、クラウドサービスの API リクエストを使用するアプリケーションを実装する際に一般的な手法です。 エクスポネンシャルバックオフでは、API リクエストがサーバー側エラーや一時的な障害で失敗した場合に、待機時間を1秒、2秒、4秒、8秒...のようにべき乗しながら再試行を繰り返します。 再試行を無限に繰り返さないよう、試行回数が規定の回数に達してもリクエストが成功しない場合、エラー終了させるよう実装します。このようにリトライ回数に上限を設けることを truncated exponential backoff（切り捨て型エクスポネンシャルバックオフ）とも呼びます。 参考 : 指数バックオフ アルゴリズム この手法を取ることにより、リージョンで多くのユーザーからの API リクエストが輻輳してリソースが枯渇している場合でも、しばらく待ってから再試行することで、最終的に API リクエストが成功する可能性を高められます。 Provisioned Throughput Provisioned Throughput （プロビジョニングされたスループット）とは、Gemini や Claude の API スループットを事前に予約購入しておき、固定金額で利用する月額サブスクリプションサービスです。 Provisioned Throughput は、事前にモデルとロケーション（リージョン）を指定して購入します。サポートされているモデルとして、gemini-2.5-pro、gemini-2.5-flash、imagen-4.0-generate-001、Anthropic Claude 4.5 Sonnet など、多くのモデルに対応しています。対象モデルの一覧は以下のドキュメントを参照してください。 参考 : プロビジョニングされたスループット 前述のグローバルエンドポイントの使用やエクスポネンシャルバックオフの実装は、リソース枯渇に対する根本的な対処にはなっていませんが、Provisioned Throughput を購入する方法では、従量課金利用よりもリソースが優先して確保されます。重要な本番環境アプリケーションでの Gemini の利用や、月額利用料金を固定したい場合などに利用を検討します。 Provisioned Throughput の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。当記事では IAM ポリシーを編集しようとした際に、 組織のポリシー「ドメインで制限された共有」（constraints/iam.allowedPolicyMemberDomains）が適用されています。 と表示されてエラーになったときの対処法を紹介します。 事象とメッセージ 原因 対処方法 対処手順 顧客 ID の確認 IAM 権限の確認 組織、フォルダまたはプロジェクトを選択 組織のポリシー画面へ遷移 制約の編集画面へ遷移 制約を編集 結果の確認 最後に ワークアラウンド 関連記事 事象とメッセージ Google Cloud（旧称 GCP）で、IAM ポリシーを編集し、Google アカウントに IAM ロールを紐づけようとした際に、以下のメッセージが表示され、編集が失敗しました。 組織のポリシー「ドメインで制限された共有」（constraints/iam.allowedPolicyMemberDomains）が適用されています。 IAM ポリシーの更新に失敗しました 組織のポリシー「ドメインで制限された共有」（constraints/iam.allowedPolicyMemberDomains）が適用されています。ポリシーでプリンシパルとして追加できるのは、許可されたドメインのプリンシパルのみです。プリンシパルのメールアドレスを修正して、もう一度お試しください。共有先のドメインの制限の詳細 リクエスト ID: (数字) 原因 この事象は、組織ポリシーの制約 iam.allowedPolicyMemberDomains が組織レベル、フォルダレベルまたはプロジェクトレベルで有効化されているときに発生します。 iam.allowedPolicyMemberDomains は、 許可されていない組織に所属する Google アカウントへの権限付与を禁止する制約 です。例として、 g-gen.co.jp という組織の Google Cloud プロジェクトで、 example.com （他組織）のプリンシパルに対して IAM ロールを付与しようとするケースが該当します。 参考： ドメイン別の ID の制限 この制約は、2024年初頭以降に作成された Google Cloud 組織ではデフォルトで有効化されています。それ以前に作成された組織でも、管理者が明示的にこの制約を有効化している場合は、この事象が発生します。 参考： 組織リソースに適用される組織のポリシー なお組織のポリシーとは、セキュリティや統制の向上のために、所定のルールを Google Cloud 環境全体に適用する仕組みのことです。組織のポリシーの詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 対処方法 組織ポリシーの制約 iam.allowedPolicyMemberDomains はリスト型の制約で、デフォルトでは自組織のみが許可されています。 したがって、 他組織の Google アカウントに IAM ロールを付与したい 場合はこの制約の許可リストに、 その組織を明示的に追加 する必要があります。 組織ポリシーの制約は、組織レベル、フォルダレベル、プロジェクトレベルで適用することができ、親リソースのポリシーは子リソースに 継承 されます。ただし、明示的に設定することで、子リソース側で親リソースの制約をオーバーライド（上書き）することも可能です。 よって、取り得る選択肢としては、以下のいずれかになります。 iam.allowedPolicyMemberDomains を 組織レベル で編集する iam.allowedPolicyMemberDomains を フォルダレベル でオーバーライドして編集する iam.allowedPolicyMemberDomains を プロジェクトレベル でオーバーライドして編集する 上記のうち 1. 、 2. の場合、組織全体もしくはフォルダ全体で影響が及びますが、 3. の影響範囲は当該プロジェクトのみです。 ご自身の環境構成と照らし合わせ、影響範囲を十分に理解したうえで適切なスコープで設定いただくことを推奨します。 対処手順 顧客 ID の確認 許可リストに外部組織を追加するには、その組織の 顧客 ID を把握しておく必要があります。 以下を参考に追加対象組織の顧客 ID を取得してください。 参考 : Google Workspace お客様 ID の取得 ( gcloud / API から取得) 参考 : 顧客 ID の確認 ( Admin コンソール から取得) また、以下の記事も参考にしてください。 blog.g-gen.co.jp IAM 権限の確認 当手順を実施するには、操作する Google アカウント、もしくはアカウントが所属するグループが、組織レベルで 組織ポリシー管理者 （ roles/orgpolicy.policyAdmin ）ロールを持っている必要があります。 組織ポリシー管理者を付与できる最も下位レベルのリソースは「組織」です。よって、フォルダやプロジェクトレベルで制約をオーバーライドする場合でも、組織レベルで組織ポリシー管理者ロールを持っている必要があります。 作業者の Google アカウントが必要な権限を持っていない場合は、組織レベルで IAM ロール「組織ポリシー管理者」を付与してください。 参考 : IAM を使用した組織リソースのアクセス制御 組織、フォルダまたはプロジェクトを選択 Google Cloud コンソールにログインし、プロジェクトセレクターをクリックして、制約を無効化を適用する組織、フォルダ、またはプロジェクトを選択します。 当記事の「対処方法」をよくお読みになり、制約の編集位置を決めたうえで選択してください。 組織のポリシー画面へ遷移 コンソール上部の検索ボックスに「組織のポリシー」と入力し、サジェストされた 組織のポリシー を選択します。 または、 IAM と管理 画面から直接遷移しても構いません。 制約の編集画面へ遷移 制約一覧の上部のフィルタに constraints/iam.allowedPolicyMemberDomains を入力し、フィルタ結果の中から Domain restricted sharing をクリックして編集画面へ遷移します。 制約を編集 ポリシーを管理 をクリックします。 以下の順でルールを追加し、最後に ポリシーを設定 をクリックします。 # 項目 設定値 1 ポリシーのソース 親のポリシーをオーバーライドする 2 ポリシーの適用 親と結合する ※親の設定を上書きする場合は 交換 を選択する 3 ポリシーの値 カスタム を選択する 4 ポリシータイプ 許可 を選択する 5 カスタム値 顧客ID を入力する ※ Cxxxxxxxx の形式の値。前述の 顧客 ID の確認 の見出しを参照 結果の確認 設定が完了すると、以下のような表示になります。 最後に ワークアラウンド 組織ポリシーの変更が難しい場合は、Google グループに外部組織のメンバーを追加し、そのグループに権限を付与することでドメイン制限の制約を回避することも可能です。 詳細は以下の公式ドキュメントをご確認ください。 参考 : Google グループ 関連記事 blog.g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2025 選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei

G-gen の杉村です。2024年12月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google フォームで新しい権限「Responder（回答者）」が利用可能に Vertex AI Search で gemini-1.5-flash-002-high-fidelity（Preview） Google Deepmind、大規模世界モデル Genie 2 を発表 Parameter Manager が Preview 公開 画像生成モデル「Imagen 3」が一般公開 Gemini 2.0 が発表 BigQuery のクロスリージョンデータセットレプリケーションが GA BigQuery で BigQuery Managed Disaster Recovery が GA VPC SC の Ingress/Egress rules の Google グループ指定が GA Google Workspace で NotebookLM Plus が利用可能に 新サービス Google Agentspace が発表 Compute Engine で Windows Server 2025 が利用可能に Cloud IAM で Principal access boundary policies が Preview → GA Looker Studio のデータソース編集画面でデータのプレビューが可能に 全エディションで AppSheet 管理画面が利用可能に Gemini 2.0 Flash Thinking の試験運用版が Google AI Studio で公開 Google ドライブで動画をアップロード後すぐに再生できるように はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google フォームで新しい権限「Responder（回答者）」が利用可能に Adding granular control options for who can respond to Google Forms (2024-12-03) Google フォームで新しい権限「Responder（回答者）」が利用可能に。 従来はフォームをインターネット公開するか、回答可能な人を絞るときは特定ドメインにしか限定できなかった。今後はアカウントやグループに限定して公開することが可能になった。 Vertex AI Search で gemini-1.5-flash-002-high-fidelity（Preview） High fidelity models (2024-12-04) Vertex AI Search で gemini-1.5-flash-002-high-fidelity モデルが Preview 公開。 gemini-1.5-flash-002-high-fidelity モデルとは、コンテキストベースの質問に最適化された RAG 用モデル。正確性や安全性を重視したチューニングがされている。金融、ヘルスケアなど正確性が重要な用途を想定。 Google Deepmind、大規模世界モデル Genie 2 を発表 Genie 2: A large-scale foundation world model (2024-12-04) Google Deepmind が、基盤世界モデル（A large-scale foundation world model）Genie 2 を発表した。 アクション制御可能でプレイ可能な 3D 環境を生成できる。生成したワールドは、キーボードとマウス入力を使用して、人間または AI エージェントによってプレイできる。一人称視点、アイソメトリック ビュー、三人称運転ビデオなど、さまざまな環境を生成可能。 Parameter Manager が Preview 公開 Parameter Manager overview (2024-12-06) Secret Manager の派生機能として Parameter Manager が Preview 公開。 環境設定値を集中管理する仕組み。シークレット管理も可能だが、Secret Manager には存在する「rotation schedules」が無いなどの差異がある。現在 gcloud/REST のみで提供。 シークレット情報は Secret Manager で、その他の環境固有設定値は Parameter Manager で管理することが想定される Parameter Manager から Secret Manager のシークレットを参照することもでき、ちょうど AWS Secret Manager と Parameter Store の関係に似ている。 画像生成モデル「Imagen 3」が一般公開 Imagen on Vertex AI | AI Image Generator (2024-12-10) 画像生成モデル「Imagen 3」が一般公開された。これまでは許可リスト制だったがVertex AI経由で全ユーザーが利用可能になった。以下のモデルが利用可能。 imagen-3.0-generate-001 imagen-3.0-fast-generate-001 ただし画像の編集や few-shot learning が可能な以下のモデルは引き続き、許可制。 imagen-3.0-capability Gemini 2.0 が発表 Google、「Gemini 2.0」を発表、AIモデルは”エージェント時代”に (2024-12-12) Google が生成AIモデル Gemini の最新版、Gemini 2.0 を発表。 マルチモーダル対応がさらに強化。 gemini-2.0-flash-exp が Gemini アプリや Vertex AI Studio、Google AI Studio で既に使用可能になっている。 BigQuery のクロスリージョンデータセットレプリケーションが GA Cross-region dataset replication (2024-12-11) BigQuery でクロスリージョン データセットレプリケーションが Preview → GA。 別リージョンにデータを非同期で複製し、データの堅牢性と可用性を高められる。データセットのリージョン間移行にも利用可能。 ただしプライマリリージョンが障害時、セカンダリリージョンは Read Only になる。詳細は以下の記事も参照。 blog.g-gen.co.jp BigQuery で BigQuery Managed Disaster Recovery が GA Managed disaster recovery (2024-12-11) BigQuery で BigQuery Managed Disaster Recovery が Preview → GA。 リージョン障害のときにデータのみならずコンピュートリソース予約もフェイルオーバし、書き込みを含むワークロードを継続できる。 VPC SC の Ingress/Egress rules の Google グループ指定が GA VPC Service Controls release notes - December 11, 2024 (2024-12-11) VPC Service Controls 境界で Ingress/Egress rules での Google グループ指定が Preview → GA。 従来は Google アカウントを直接指定する必要があったが、グループ指定ができるようになり、運用の煩雑さがやや解消される。 Google Workspace で NotebookLM Plus が利用可能に NotebookLM Plus now available to Google Workspace customers (2024-12-13) Google Workspace で NotebookLM Plus が利用可能に。もともと無料で利用できた NotebookLM の有償版。Plus では様々な機能、制限緩和、データの保護が追加される。 NotebookLM は自分専用のAIノートブック。データをアップロードして生成AIに読み込ませ生成テキストや自分のメモも記述しておける。分析や資料作成、情報整理などに利用できる。 要Geminiアドオンライセンス。 新サービス Google Agentspace が発表 Introducing Google Agentspace: Bringing AI agents and AI-powered search to enterprises (2024-12-14) 新サービス Google Agentspace が発表。Early accessに申込可能。以下の機能を備える。 自社データをアップロードしてAIから利用できる NotebookLM Plus コンフルや Google ドライブ、SharePoint 等から検索できるエンタープライズサーチ 人の代わりにタスクをこなすエージェント Compute Engine で Windows Server 2025 が利用可能に Windows Server (2024-12-16) Compute Engine で Windows Server 2025 が利用可能になった。EoS（イメージ廃止日）は 2034-10-10。 なおその前の Windows Server 2022 の EoS は 2031-10-14。 Cloud IAM で Principal access boundary policies が Preview → GA Principal access boundary policies (2024-12-17) Cloud IAM で Principal access boundary policies が Preview → GA。 自組織のプリンシパルがどのリソースにアクセスできるかの境界（boundary）を設けられる。アクセス先を自組織のリソースに限定したり、特定フォルダ内に限定したりできる。 Looker Studio のデータソース編集画面でデータのプレビューが可能に Preview your data (2024-12-17) Looker Studio でデータソースの編集画面でデータ内容をプレビューできるようになった。 BigQuery、Google スプレッドシート、Looker、Excel、CSV に対応。 全エディションで AppSheet 管理画面が利用可能に Now generally available: Monitor and manage AppSheet usage in your organization with the AppSheet Admin console (2024-12-18) Google Workspace の全エディションで AppSheet の管理画面が利用可能になった。 アプリの利用状況、誰がアプリをたくさん作っているか、ライセンス数、などが横断で閲覧できる管理画面。 Gemini 2.0 Flash Thinking の試験運用版が Google AI Studio で公開 Gemini 2.0 Flash の思考モード (2024-12-19) Gemini 2.0 Flash Thinking の試験運用版（gemini-2.0-flash-thinking-exp-1219）が Vertex AI（Generative AI on Vertex AI）と Google AI Studio で公開。 このモデルでは、生成結果だけでなく、生成に至った「思考」プロセスも生成して表示する。 Google ドライブで動画をアップロード後すぐに再生できるように Google Workspace Updates Weekly Recap - December 20, 2024 (2024-12-20) Google ドライブで動画をアップロード後、すぐに再生できるようになった。 これまではアップロード後に数分〜数十分、処理の時間が必要だった。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事ではコンテナ オーケストレーション ツールである Kubenretes の学習用のため、Minikube を使って Compute Engine（Google Compute Engine、GCE）仮想マシン上にローカル Kubernetes クラスタを構築していきます。 はじめに 当記事の目的 Minikube とは Compute Engine インスタンスの作成 作業の概要 シェル変数の設定 VPC・サブネットの作成 VPC の作成 サブネットの作成 インスタンスの作成 Minikube の要件について インスタンスの作成 ファイアウォールルールの設定 インスタンスに SSH 接続 コンソールからインスタンスに接続（GUI の場合） gcloud コマンドで SSH 接続（CLI の場合） Docker のインストール Minikube の driver について パッケージリストの更新 インストール APT リポジトリのセットアップ Docker のインストール Docker の動作確認 クリーンアップ Minikube のインストール APT リポジトリのセットアップ インストール Minikube の実行 Minikube 実行ユーザーを docker グループに追加 Minikube の実行 Pod の作成 Pod の公開 クリーンアップ バックアップの取得 はじめに 当記事の目的 当記事では Minikube という OSS（オープンソースソフトウェア）を使用して、Compute Engine の仮想マシン（インスタンス）上に学習用の Kubernetes クラスタ を構築する方法を紹介します。 Kubernetes はコンテナ オーケストレーション ツールのデファクトスタンダードであり、マネージドな Kubernetes クラスタを提供する Google Kubernetes Engine（GKE） は Google Cloud における代表的なサービスの一つです。 参考 : Kubernetes の基本を解説 - G-gen Tech Blog 参考 : Google Kubernetes Engine（GKE）を徹底解説 - G-gen Tech Blog Kubernetes はコンテナの運用管理のための非常に強力なツールである反面、独自の用語や設定ファイル、高頻度のバージョンアップなど、学習コストが高いことで知られています。当記事の内容は、 Kubernetes に入門するための簡易的な学習環境を、低コストで用意する ことを目的としています。 学習環境として Compute Engine を用いるメリットとして、使用しないときはインスタンスを停止して料金を節約できる点や、マシンイメージ等を使用してバックアップを取得し、必要に応じて手軽にリストアすることができる点があります。 なお、GKE では請求先アカウントにつき月額 $74.40 の無料枠が提供されています。実際の GKE クラスタを使用して学習を行いたい場合は、Autopilot クラスタでこの無料枠を利用してみるのもよいでしょう。 参考 : クラスタ管理手数料と無料枠 ただし、GKE は膨大な量のログを Cloud Logging に出力するため、Cloud Logging の料金にも注意を払う必要があります。 また、以下の記事では Terraform を使用して Autopilot モードの GKE クラスタを作成する方法を紹介していますので、参考にしてください。 blog.g-gen.co.jp Minikube とは Minikube はローカル環境で Kubernetes を実行するためのツールです。Minikube を使うと、仮想マシン上にシングルノードの Kubernetes クラスタを構築することができます。Minikube では Kubernetes の全ての機能を使用できるわけではありませんが、基本的な動作の確認や開発環境として利用することができます。 当記事では、以下の公式チュートリアルを元に Minikube をインストールし、クラスタの構築を行います。 参考 : Minikubeを使用してローカル環境でKubernetesを動かす 参考 : minikube start Compute Engine インスタンスの作成 作業の概要 Google Cloud プロジェクトに Compute Engine インスタンスを作成します。 インスタンスは VPC 内のサブネットに作成する必要があるため、それらのリソースを先に作成し、その中にインスタンスを作成します。 そして、インスタンス内で作業する際に VPC の外部から接続できるように、接続を許可するファイアウォールルールを設定しておきます。 当記事で作成する Compute Engine 環境の構成 当記事では gcloud コマンド を用いてリソースの作成を行っていきます。gcloud コマンドのインストールについては以下のドキュメントを参照してください。 参考 : gcloud CLI をインストールする また、Google Cloud コンソールから利用できる Cloud Shell （ブラウザベースのターミナル環境）には gcloud コマンドがプリインストールされているため、以降の作業をそのまま実施することができます。 参考 : Cloud Shell を使用する シェル変数の設定 コマンドで何度か使用する値をシェル変数に格納しておきます。当記事では SUFFIX の値を minikube として進めていきます。 PROJECT にはリソースを作成するプロジェクトの ID を、 REGION には asia-northeast1 などのリージョンを指定します。 SUFFIX = { 適当な値 } # 当記事では minikube PROJECT = { プロジェクトID } REGION = { リソースを作成するリージョン } VPC・サブネットの作成 VPC の作成 以下のコマンドで VPC を作成します。サブネットを手動で作成するため、 --subnet-mode フラグで custom を指定します。 # VPC を作成する $ gcloud compute networks create vpc- ${SUFFIX} \ --subnet-mode = custom \ --project = ${PROJECT} 参考 : gcloud compute networks create（コマンドリファレンス） サブネットの作成 作成した VPC を指定し、その中にサブネットを作成します。 --range フラグではサブネットに割り当てるプライベート IP アドレスの範囲を CIDR で指定します。当記事では 192.168.144.0/28 を割り当てています。 # サブネットを作成する $ gcloud compute networks subnets create subnet- ${SUFFIX} \ --network = vpc- ${SUFFIX} \ --region = ${REGION} \ --range = 192 . 168 . 144 . 0 / 28 \ --project = ${PROJECT} 参考 : gcloud compute networks subnets create（コマンドリファレンス） インスタンスの作成 Minikube の要件について 公式チュートリアル によると、Minikube のリソース要件は以下のようになっています。 2つ以上の CPU 2 GB 以上のメモリ容量 20 GB 以上のディスク領域 たとえばメモリが不足している場合、Minikube を実行しようとしても、以下のようにエラーが出て終了してしまいます。 # メモリ不足の場合、Minikube を実行できない $ minikube start --driver = docker 😄 minikube v1. 34 . 0 on Debian 12 . 7 ( amd64 ) ✨ Using the docker driver based on user configuration ⛔ Exiting due to RSRC_INSUFFICIENT_CONTAINER_MEMORY: docker only has 969MiB available, less than the required 1800MiB for Kubernetes 当記事ではメモリ容量にある程度余裕があるマシンタイプでインスタンスを作成します。 マシンタイプは簡単に変更することができるため、まずは小さめのマシンタイプで試してみて、足りなければリソースを増やしてもよいでしょう。 参考 : コンピューティング インスタンスのマシンタイプの編集 - マシンタイプを変更する インスタンスの作成 前の手順で作成した VPC とサブネットを指定し、Compute Engine インスタンスを作成します。 当記事では以下の設定値でインスタンスを作成します。 項目 gcloud コマンドのフラグ 値 備考 インスタンス名 vm-${SUFFIX} VPC --network vpc-${SUFFIX} サブネット --subnet subnet-${SUFFIX} OS イメージ --image-family --image-project debian-12 debian-cloud 以降の手順はここで指定した OS を前提とする点に注意 マシンタイプ --machine-type e2-medium 2 vCPU、メモリ4GB 必要に応じて変更可（ 参考 ） ディスクサイズ --boot-disk-size 20GB Minikube のリソース要件に準拠 ネットワークタグ --tags ssh 後で作成するファイアウォールルールをインスタンスに紐付ける際に使用 # Compute Engine インスタンスを作成する $ gcloud compute instances create vm- ${SUFFIX} \ --network = vpc- ${SUFFIX} \ --subnet = subnet- ${SUFFIX} \ --zone = ${REGION} -a \ --image-family = debian-12 \ --image-project = debian-cloud \ --machine-type = e2-medium \ --boot-disk-size = 20GB \ --tags = ssh \ --project = ${PROJECT} 参考 : gcloud compute instances create（コマンドリファレンス） ファイアウォールルールの設定 作成したインスタンスに SSH でアクセスできるように、VPC に内向きのファイアウォールルールを作成します。 --target-tags フラグでインスタンスに設定したものと同じタグを指定することで、このルールをインスタンスに紐付けることができます。 なお、当記事では便宜上 --source-ranges フラグ、つまりアクセス元の IP アドレス範囲を 0.0.0.0/0 （任意の IP アドレス）に設定していますが、セキュリティを考慮して自身の PC の IP アドレス等を設定することもできます。 # SSH を許可するファイアウォールルールを作成する $ gcloud compute firewall-rules create vpc- ${SUFFIX} -allow-ssh \ --direction = INGRESS \ --source-ranges = 0 . 0 . 0 . 0 / 0 \ --allow = tcp:22 \ --target-tags = ssh \ --network = vpc- ${SUFFIX} \ --project = ${PROJECT} 参考 : gcloud compute firewall-rules create（コマンドリファレンス） インスタンスに SSH 接続 コンソールからインスタンスに接続（GUI の場合） Minikube をインストールするため、作成したインスタンスに SSH 接続します。 Google Cloud コンソールからインスタンスに SSH 接続する場合、インスタンス一覧画面で「 SSH 」を選択します。 Google Cloud コンソールからインスタンスに SSH 接続する gcloud コマンドで SSH 接続（CLI の場合） gcloud では、以下のコマンドを使用してインスタンスに SSH 接続できます。 # インスタンスに SSH 接続する $ gcloud compute ssh vm- ${SUFFIX} \ --zone = ${REGION} -a \ --project = ${PROJECT} 参考 : gcloud compute ssh（コマンドリファレンス） Docker のインストール Minikube の driver について Minikube では動作環境（driver）として Docker や VirtualBox など、いくつかの選択肢が提供されています。 参考 : Drivers 当記事では推奨 driver の1つである Docker を使用して構築を進めていきます。 以下の Docker 公式ドキュメントの手順に沿って、Docker をインストールしていきます。 参考 : Install Docker Engine on Debian パッケージリストの更新 以降の手順については、 SSH 接続した Compute Engine VM 上でコマンドを実行 してください。 まずは、APT のパッケージを最新化しておきます。 # パッケージリストを最新の状態にする $ sudo apt update # パッケージの最新化（時間がかかる可能性あり） $ sudo apt upgrade -y インストール APT リポジトリのセットアップ まず、Docker パッケージの検証に必要な GPG Key を用意します。 # Docker のダウンロードに必要なパッケージをインストールする $ sudo apt install ca-certificates curl # keyrings ディレクトリのパーミッションを設定する $ sudo install -m 0755 -d /etc/apt/keyrings # Docker 公式の GPG Key をダウンロードして keyrings ディレクトリに格納する $ sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc # GPG Key のパーミッションを変更する $ sudo chmod a+ r /etc/apt/keyrings/docker.asc apt コマンドのパッケージ取得元のリポジトリとして Docker 関連のリポジトリを追加します。 # Docker のリポジトリを追加する $ echo \ " deb [arch= $( dpkg --print-architecture ) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \ $( . /etc/os-release && echo " $VERSION_CODENAME " ) stable " | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null Docker のインストール Docker の実行に必要なパッケージをインストールします。 # パッケージリストを更新する $ sudo apt update # Docker の実行に必要なパッケージをインストールする $ sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin Docker の動作確認 Docker で適当なコンテナを実行してみます。ここでは Docker 公式コンテナイメージの hello-world を使用します。 # hello-world コンテナの起動 $ sudo docker run --name hello hello-world -------------------- 出力例 -------------------- Unable to find image ' hello-world:latest ' locally latest: Pulling from library/hello-world c1ec31eb5944: Pull complete Digest: sha256:d211f485f2dd1dee407a80973c8f129f00d54604d2c90732e8e320e5038a0348 Status: Downloaded newer image for hello-world:latest Hello from Docker ! This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps: 1 . The Docker client contacted the Docker daemon . 2 . The Docker daemon pulled the " hello-world " image from the Docker Hub. ( amd64 ) 3 . The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading. 4 . The Docker daemon streamed that output to the Docker client, which sent it to your terminal. To try something more ambitious, you can run an Ubuntu container with: $ docker run -it ubuntu bash Share images, automate workflows, and more with a free Docker ID: https://hub.docker.com/ For more examples and ideas, visit: https://docs.docker.com/get-started/ クリーンアップ 動作確認用の hello-world コンテナと、そのコンテナイメージを削除していきます。 hello-world コンテナは停止した状態で残っています。 # コンテナ一覧を確認する $ sudo docker container ls -a -------------------- 出力例 -------------------- CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0f6492b1ab35 hello-world " /hello " 48 seconds ago Exited ( 0 ) 47 seconds ago hello また、コンテナ実行に使用されたコンテナイメージもローカルにダウンロードされているため、これを削除していきます。 # コンテナイメージの一覧を確認する $ sudo docker image ls -------------------- 出力例 -------------------- REPOSITORY TAG IMAGE ID CREATED SIZE hello-world latest d2c94e258dcb 18 months ago 13 .3kB 以下のコマンドで、停止したコンテナとコンテナイメージを削除します。 # コンテナを削除する $ sudo docker container rm hello # hello-world コンテナイメージを削除する $ sudo docker image rm hello-world:latest Minikube のインストール APT リポジトリのセットアップ まず、Kubernetes のリポジトリを APT のパッケージ取得元として登録します。 # Kubernetes のリポジトリを登録 $ echo " deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ / " | sudo tee /etc/apt/sources.list.d/kubernetes.list パッケージの検証に使用する GPG Key をダウンロードします。 # GPG Key のダウンロード curl -fsSL https://pkgs.k8s.io/core:/stable:/v1. 28 /deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg 改めてパッケージリストを更新します。 # パッケージリストを更新する $ sudo apt update 参考 : How to migrate to the Kubernetes community-owned repositories? インストール Minikube のパッケージをダウンロードし、 dpkg コマンドでインストールを実行します。 # Minikube のパッケージをダウンロードする $ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb # Minikube をインストールする $ sudo dpkg -i minikube_latest_amd64.deb -------------------- 出力例 -------------------- Selecting previously unselected package minikube. ( Reading database ... 73229 files and directories currently installed. ) Preparing to unpack minikube_latest_amd64.deb ... Unpacking minikube ( 1 . 34 .0-0 ) ... Setting up minikube ( 1 . 34 .0-0 ) ... Minikube の実行 Minikube 実行ユーザーを docker グループに追加 Minikube を実行するユーザーを docker グループに所属させます。 この手順をスキップすると、Minikube 実行時に以下のような権限エラーが発生してしまいます。 $ minikube start --driver = docker 😄 minikube v1. 34 . 0 on Debian 12 . 7 ( amd64 ) ✨ Using the docker driver based on user configuration 💣 Exiting due to PROVIDER_DOCKER_NEWGRP: " docker version --format <no value>-<no value>:<no value> " exit status 1: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get " http://%2Fvar%2Frun%2Fdocker.sock/v1.47/version ": dial unix /var/run/docker.sock: connect: permission denied 💡 Suggestion: Add your user to the ' docker ' group: ' sudo usermod -aG docker $USER && newgrp docker ' 📘 Documentation: https://docs.docker.com/engine/install/linux-postinstall/ Suggestion: の項目に記載されているコマンドを実行し、現在仮想マシンのログインに使用しているユーザーを docker グループに追加します。 # 現在のユーザーを docker グループに追加する $ sudo usermod -aG docker $USER && newgrp docker Minikube の実行 minikube start コマンドで Minikube を実行します。 --driver フラグで Docker をドライバとして設定しています。 $ minikube start --driver = docker -------------------- 出力例 -------------------- 😄 minikube v1. 34 . 0 on Debian 12 . 8 ( amd64 ) ✨ Using the docker driver based on user configuration 📌 Using Docker driver with root privileges 👍 Starting " minikube " primary control-plane node in " minikube " cluster 🚜 Pulling base image v0. 0 . 45 ... 💾 Downloading Kubernetes v1. 31 . 0 preload ... > preloaded-images-k8s-v18-v1...: 326 . 69 MiB / 326 . 69 MiB 100 . 00 % 37 . 80 M > gcr.io/k8s-minikube/kicbase...: 487 . 90 MiB / 487 . 90 MiB 100 . 00 % 46 . 45 M 🔥 Creating docker container ( CPUs = 2 , Memory = 2200MB ) ... 🐳 Preparing Kubernetes v1. 31 . 0 on Docker 27 . 2 . 0 ... ▪ Generating certificates and keys ... ▪ Booting up control plane ... ▪ Configuring RBAC rules ... 🔗 Configuring bridge CNI ( Container Networking Interface ) ... 🔎 Verifying Kubernetes components... ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5 🌟 Enabled addons: storage-provisioner, default-storageclass 💡 kubectl not found. If you need it, try: ' minikube kubectl -- get pods -A ' 🏄 Done! kubectl is now configured to use " minikube " cluster and " default " namespace by default Minikube の状態は minikube status コマンドで確認できます。 # Minikube の状態を確認する $ minikube status -------------------- 出力例 -------------------- minikube type: Control Plane host: Running kubelet: Running apiserver: Running kubeconfig: Configured 一般に Kubernetes の管理操作には kubectl コマンドを使用しますが、Minikube では minikube kubectl を使用します。 # Minikube のノードを確認する $ minikube kubectl -- get nodes -------------------- 出力例 -------------------- NAME STATUS ROLES AGE VERSION minikube Ready control-plane 11m v1. 31 . 0 毎回 minikube の部分からコマンドを入力するのは手間なので、エイリアスを設定して kubectl だけでコマンドを実行できるようにします。エイリアスは .bashrc ファイルに設定しておきます。 # エイリアスを設定する（.bashrc に追記） $ echo " alias kubectl='minikube kubectl --' " >> .bashrc # .bashrc の追記内容を反映する $ source .bashrc # エイリアスで実行できることを確認する $ kubectl get nodes -------------------- 出力例 -------------------- NAME STATUS ROLES AGE VERSION minikube Ready control-plane 13m v1. 31 . 0 Pod の作成 Minikube のクラスタを実行できたので、Kubernetes で管理できる最小単位のコンピューティング リソースである Pod を作成してみます。 vim 等のエディタを使用して、 sample-pod.yaml として以下のマニフェストファイルを作成します。この Pod は、Web サーバである nginx のコンテナを実行します。 # sample-pod.yaml apiVersion : v1 kind : Pod metadata : name : nginx labels : app : sample spec : containers : - name : nginx image : nginx:1.27 ports : - containerPort : 80 kubectl apply コマンドでマニフェストファイルをクラスタに適用します。これにより、YAML ファイルに記載した設定内容の Pod が Minikube クラスタ上で実行されます。 # マニフェストファイルをクラスタに適用して Pod を作成する $ kubectl apply -f sample-pod.yaml kubectl get pods で Pod の一覧を取得します。先程マニフェストファイルを適用した Pod が実行されています。 # Pod の一覧を取得する $ kubectl get pods -------------------- 出力例 -------------------- NAME READY STATUS RESTARTS AGE nginx 1 / 1 Running 0 2m15s Pod の公開 Service リソースとして NodePort を作成して、先程作成した Pod の nginx コンテナに Minikube クラスタの外部から接続できるようにします。 Pod 同様、Service もマニフェストファイルから作成できますが、ここでは簡易的に kubectl expose コマンドで作成します。 # NodePort を作成して Pod を公開する $ kubectl expose pod/nginx --type = NodePort --port = 80 kubectl get services コマンドで Service リソースの一覧を確認します。NodePort タイプの Service が作成されています（2行目）。 # Service の一覧を取得する $ kubectl get services -------------------- 出力例 -------------------- NAME TYPE CLUSTER-IP EXTERNAL-IP PORT ( S ) AGE kubernetes ClusterIP 10 . 96 . 0 . 1 < none > 443 /TCP 49m nginx NodePort 10 . 110 . 131 . 236 < none > 80:30134/TCP 116s minikube service nginx --url で NodePort にアクセスするための URL を取得できるため、この URL にアクセスしてみます。ここまで手順通りにリソースを作成していれば、Pod 内の nginx コンテナからレスポンスが返ってきます。 $ curl $( minikube service nginx --url ) -------------------- 出力例 -------------------- < !DOCTYPE html > < html > < head > < title > Welcome to nginx! < /title > < style > html { color-scheme: light dark ; } body { width: 35em ; margin: 0 auto ; font-family: Tahoma, Verdana, Arial, sans-serif ; } < /style > < /head > < body > < h 1> Welcome to nginx! < /h 1> < p > If you see this page, the nginx web server is successfully installed and working. Further configuration is required. < /p > < p > For online documentation and support please refer to < a href = " http://nginx.org/ "> nginx.org < /a > . < br/ > Commercial support is available at < a href = " http://nginx.com/ "> nginx.com < /a > . < /p > < p >< em > Thank you for using nginx. < /em >< /p > < /body > < /html > クリーンアップ 動作確認用に作成した各リソースを削除します。 Service リソースを kubectl delete コマンドで削除します。 # Service を削除する $ kubectl delete services nginx Pod はマニフェストファイルから作成したので、 kubectl delete コマンドで -f フラグを使用し、リソース作成時に使用したマニフェストファイルを指定します。 # Pod を削除する $ kubectl delete -f sample-pod.yaml バックアップの取得 Minikube を構築したインスタンスのバックアップを取得しておくと、学習中に環境を壊してしまった場合などに容易に復元することができます。 以下の記事で Compute Engine のマシンイメージの取得方法、およびマシンイメージからのインスタンスの復元方法を解説しているので、こちらの手順を参考にバックアップを取得しておくとよいでしょう。 参考 : Compute EngineインスタンスにPostgreSQLサーバを構築する - バックアップの取得とインスタンスの復元 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の堂原です。当記事では、 Google スプレッドシート （Google Sheets）の機能である コネクテッドシート で、 データの抽出 機能を使う際、行数制限が 10万行までしか選べない 場合の対処法を紹介します。 コネクテッドシートとは 概要 データの抽出 事象 解決方法 コネクテッドシートとは 概要 コネクテッドシート （Connected Sheets）は、 Google スプレッドシート の機能です。コネクテッドシートを用いると、Google Cloud（旧称 GCP）のデータ分析サービスである BigQuery のテーブルやビューを Google スプレッドシート上で可視化、分析できます。 詳しくは以下の記事をご参照ください。 blog.g-gen.co.jp データの抽出 データの抽出 は、BigQuery のデータを スプレッドシートに取り込む 機能です。データの抽出を行うと データの処理がスプレッドシート上で完結する ため、BigQuery の料金を抑えることが出来ます。反対にデータの抽出を行わないと、関数を用いてデータを計算するとき等に都度 BigQuery にリクエストが発行されるため、BigQuery のスキャン料金が発生します。 データの抽出機能では、 最大 500,000 行 のデータを抽出することが可能です。ただし、データサイズは 10 MB 以下、総セル数は 5,000,000 以下という制限もあります。 参考 : Analyze & refresh BigQuery data in Google Sheets using Connected Sheets > Pull data into an extract 事象 データの抽出機能は、先述の通り最大 500,000 行のデータ抽出が可能です。 しかし2024年12月現在、Google スプレッドシートの設定画面でデータの抽出を設定しようとすると、行数制限が 100,000 行までしか選択できません 。 もちろん、この状態で設定を適用しても、100,000 行までしかデータは出力されません。なお当記事の検証では kaggle で公開されている Black Friday のデータセットを用いており、レコード数は 550,068 行です。 全ての Google Workspace 環境でこのような状況が見られるかは未確認ですが、当社が所有する複数の Google Workspace アカウントでは、2024年12月現在、いずれも同様の事象が発生しました。 解決方法 問題となっている行数制限の設定箇所には、実は 直接数字を書き込むことができます 。 手動で「123,456」を書き込んだ例 そのため、 100,000 行以上のレコードを表示させたい場合は手動で数字を書き換える 必要があります。この例では直接「500,000」と書き込むことで、下図のように 500,000 行までレコードを表示させることができました。 ただし先述の通り、データサイズは 10 MB 以下、総セル数は 5,000,000 以下という制限も同時に適用されるため、どれかに抵触した場合はそれが上限となります。 セル数が 5,000,000 を超えた際のエラー 堂原 竜希 (記事一覧) クラウドソリューション部データアナリティクス課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の佐々木です。当記事では、Direct VPC Egress を経由して Cloud NAT を利用する際の注意点として、 Cloud NAT のモニタリング指標が Cloud Monitoring に記録されない仕様 について解説します。 ※当記事に記載されているモニタリングに関する仕様は執筆時点のものであり、現在はアップデートにより改善されています。 Direct VPC Egress 経由の Cloud NAT 利用 制限事項 想定される問題 対策 Cloud NAT のログを有効にする Cloud NAT のポート割り当て数に余裕をもたせる サーバーレス VPC アクセスを利用する Direct VPC Egress 経由の Cloud NAT 利用 Cloud Run や Cloud Run functions（旧称 Cloud Functiions）などのサーバーレス コンピューティング サービスでは、処理を行う際にだけ実行環境を起動し、処理をしないときは実行環境を停止することができます。このため実行環境が起動するたびに、実行環境の IP アドレスは変わってしまいます 。 これらの実行環境から、接続元 IP アドレスが制限されている外部の Web API 等へリクエストを送信する場合、実行環境の外部 IP アドレスを固定する必要がでてきます。このとき、 Cloud NAT を使用することで、外部アクセスに使用される IP アドレスを固定することができます。Cloud NAT は VPC に紐付いたリソースであるため、Cloud Run 等から VPC に接続するためには Direct VPC Egress を使用します。 参考 : Cloud NAT の概要 参考 : ダイレクト VPC 下り（外向き） Cloud Run で Direct VPC Egress を使用して Cloud NAT で外部 IP アドレスを固定する方法については、以下の記事で解説しています。 blog.g-gen.co.jp また、Direct VPC Egress の詳細については以下の記事をご一読ください。 blog.g-gen.co.jp 制限事項 Cloud Run の公式ドキュメントには Direct VPC Egress の制限事項が記載されているほか、Cloud NAT のドキュメントにも制限が記載されています。 参考 : Direct VPC egress with a VPC network - Limitations 参考 : Cloud NAT product interactions - Direct VPC egress interactions 後者のドキュメントには、以下のような制限が記載されています（2025年5月時点）。 Direct VPC Egress の Cloud NAT 指標 は Cloud Monitoring にエクスポートされない Direct VPC Egress の Cloud NAT ログには、発信元の Cloud Run サービス、リビジョン、ジョブの名前は表示されない Direct VPC Egress では プライベート NAT はプレビュー機能のみ提供 当記事ではこれらの3つの制限のうち、 1 のモニタリングに関する制限について掘り下げます。 想定される問題 前述の 1 の制限は、Direct VPC Egress 経由で Cloud Run や Cloud Run functions から Cloud NAT が利用された場合、その利用状況が Cloud Monitoring で可視化できないことを意味しています。 Direct VPC Egress経由でCloud NATを使用すると、Cloud NATのモニタリング指標が表示されない この場合、Cloud NAT に高負荷が原因で問題が生じたときの原因調査が難しくなります。たとえば以下の記事で紹介しているケースでは、Cloud Run からの全てのアウトバウンド トラフィックが意図せず Cloud NAT に向かってしまったことで、 Cloud NAT が利用できるポート数が上限に達してしまい 、接続エラーが多発する状況になりました。 blog.g-gen.co.jp このケースにおける Cloud NAT の高負荷は設定ミスによって起こったものですが、リクエストの急増により Cloud Run がスケールした場合など、通常の利用時にも発生する可能性はあります。本来 Cloud NAT のポート使用状況は Cloud Monitoring で可視化できますが、Direct VPC Egress 経由のトラフィックについては、この指標が記録されません。 対策 Cloud NAT のログを有効にする Cloud NAT のログは作成時のデフォルトでは無効になっていますが、これを有効化することで、エラーログから Cloud NAT の異常を検知できる可能性があります。 ただし、前述の制限事項に記載したように、Direct VPC Egress の Cloud NAT ログには発信元の情報が記録されない点には注意が必要です。 Cloud NATのログを有効化する Cloud NAT のポート割り当て数に余裕をもたせる Cloud NAT には利用できるポート数を動的に変更する 動的ポートの割り当て 機能があります。しかし、動的ポートの割り当てを使うと、ポート数がスケールアウトするタイミングでパケットがドロップしてしまう問題があります。 参考 : 動的ポートの割り当て 参考 : 動的ポート割り当てが構成されているときにパケットがドロップされる 動的ポートの割り当てを使用しない場合、静的にポートの割り当てが行われます。デフォルトでは 64 個のポートが利用できますが、手動で変更することができます。 参考 : 静的ポートの割り当て Direct VPC Egress を使用しているときは Cloud NAT の指標が利用できないため、適切なポート数を検討することも難しいですが、問題が起こったときにポート数を増やす選択肢があることは理解しておくとよいでしょう。 サーバーレス VPC アクセスを利用する サーバーレス VPC アクセス 経由で Cloud NAT を使用する場合、Direct VPC Egress と比較して料金やパフォーマンス面のデメリットはありますが、当記事で解説したモニタリングに関する問題は発生しません。 参考 : サーバーレス VPC アクセス Cloud Run でサーバーレス VPC アクセスを使用して Cloud NAT で外部 IP アドレスを固定する方法については、以下の記事で解説しています。 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 が開発した大規模言語モデル Gemini は、その高い性能と多岐にわたるプロダクト展開で注目を集めています。当記事では、Gemini プロダクトの全貌を網羅的に解説します。 はじめに 生成 AI 基盤モデル としての Gemini モデルとは Gemini のモデルファミリー Gemini モデルのバージョン Gemini プロダクト 1. Gemini アプリ Gemini アプリとは データ保護 Gems 2. Gemini Enterprise Gemini Enterprise とは 参考記事 3. Gemini for Google Workspace Gemini for Google Workspace とは サイドパネル Gemini for Google Workspace が Google Worksapce のコアライセンスに統合 事例 4. Gemini for Google Cloud Gemini for Google Cloud とは 機能一覧 料金 5. Generative AI on Vertex AI Generative AI on Vertex AI とは データの保護 ユースケース その他のプロダクト 料金 6. Gemini API（Google AI Studio） Gemini API とは ユースケース データの保護 料金 導入すべき Gemini プロダクト 生成 AI で社内業務を効率化したい場合 自社データを効率的に検索したり生成 AI に質問に答えさせたい場合 自社の新サービスに生成 AI を組み込む場合 システム開発を効率化したい場合 ビジネス導入における注意点 生成 AI のビジネス適用 生成 AI は確率エンジンであることを理解する 生成 AI に向いてる業務 / 向いてない業務 向いている業務 向いていない業務 セキュリティ データ保護 生成 AI アプリへの攻撃 不適切な生成コンテンツ 対策 導入事例 はじめに Gemini は、Google が開発した生成 AI 基盤モデル、およびそれを利用した生成 AI プロダクト群です。Gemini を用いたプロダクトには、以下があります。 プロダクト名 概要 Gemini アプリ ブラウザやモバイルアプリから利用な生成 AI チャットアプリ Gemini Enterprise 企業向け AI エージェント Web サービス。企業データの横断検索も可能 Gemini for Google Workspace Google Workspace に組み込まれた業務補助 AI Gemini for Google Cloud Google Cloud 上の開発を効率化するツール群 Generative AI on Vertex AI API で Gemini モデルを使用（企業向け。Google Cloud の Vertex AI API 経由） Gemini API （Google AI Studio） API で Gemini モデルを使用（個人向け。Google AI Studio の API 経由） それぞれに異なる機能や特徴があり、ビジネスシーンに合わせて最適なプロダクトを選択できます。当記事ではこれらを Gemini プロダクト と呼称して、それぞれ紹介します。 Gemini プロダクト一覧 生成 AI 基盤モデル としての Gemini モデルとは まず、機械学習における モデル とは、大量のデータからパターンやルールを学習し、特定のタスクを実行できるようになった仕組みのことを指します。 例えば画像認識モデルは、たくさんの猫の画像データから、“猫らしさ” を学習することで、人が教えることなく初めて見る猫の画像でも「これは猫だ」と認識できます。 Gemini も機械学習モデルの1つです。Gemini は マルチモーダル な生成 AI モデルです。マルチモーダルなモデルとは、テキスト、画像、音声、動画など、 複数の種類の情報を理解し、コンテンツを生成する ことができることを指します。 当記事で紹介する Gemini プロダクトは、この Gemini モデルを用いています。 Gemini のモデルファミリー Gemini モデルファミリー Gemini のモデルには複数の種類があり、それぞれ得意なタスクや能力が異なります。Gemini アプリや Gemini for Google Workspace に組み込まれているモデルや、Google Cloud から API 経由で利用できるモデルには、以下のようなものがあります。 Gemini Ultra Gemini ファミリーの中でも最も高性能なモデルです。複雑な推論や高度なコーディングなど、専門的な知識を必要とするタスクに優れています。 Gemini Pro 幅広いタスクに対応できる汎用性の高いモデルです。文章生成、翻訳、質疑応答など、様々な用途で利用できます。 Gemini Flash 高速な応答速度を誇るモデルです。レイテンシが重要なアプリケーションに最適です。 Gemini Flash Lite Flash より若干軽量・高速で、費用対効果に優れる。 Gemini Nano 最も軽量なモデル。スマートフォンなどのデバイス上で動作するように設計されており、限られた計算資源でも効率的に動作します。 これらのモデルは、Gemini プロダクトに組み込まれています。私たちユーザーから明示的にモデルの種類が選択できるプロダクトもあれば、Google が最適なモデルを選択して組み込み済みのこともあります。 Gemini モデルのバージョン 上記のモデルに加えて、Gemini には バージョン という概念があります。バージョンは頻繁にアップデートされており、モデルの改善や機能追加が行われるたびに更新されていきます。 2025年12月現在、Gemini モデルの一般利用可能なバージョンは Gemini 2.5 Pro、2.5 Flash、Gemini 2.0 Flash などです。また Gemini 3 Pro が Preview 版の位置づけで利用可能になっています。 モデルのアップデートにより、コンテキストウィンドウ（一度に処理できる情報量、単位は トークン ）がより大きくなったり、推論能力、コード生成能力が向上します。Gemini では、次々に新しいバージョンがローンチされています。 参考 : Gemini 2.5: Our most intelligent AI model 参考 : Google models モデルには ライフサイクル があります。古いモデルは順次提供が終了するため、自社開発アプリに AI モデルを組み込む際は、モデルのライフサイクルにあわせたアップデートが必要です。 参考 : Model versions and lifecycle Gemini プロダクト 1. Gemini アプリ Gemini アプリはチャットツール Gemini アプリとは Gemini アプリ （Gemini app）とは、以下の2つのチャットプロダクトの総称です。 Gemini ウェブアプリ（ gemini.google.com のこと。かつて Bard と呼ばれていた Web ブラウザ向け生成 AI チャット） Gemini モバイルアプリ（Android および iOS 向けの Gemini アプリ。ウェブアプリ版とほぼ同等の機能を備える） いずれも、Google の生成 AI 基盤モデルである Gemini を基盤としたチャットアプリケーションで、Google アカウントさえあれば 無料で利用できます 。 参考 : gemini.google.com 参考 : Gemini アプリ ヘルプ データ保護 Gemini アプリは、Google アカウントがあれば誰でも無料で利用できます。ただし、無償の Google アカウントで Gemini アプリを使う場合、入力したデータは Google によって サービス改善のために利用される 場合があります。 一方で以下のエディションの Google Workspace で管理されたアカウントであれば「 エンタープライズグレードのデータ保護 」が適用されます。この場合、データは Google によって サービス改善のために利用されることはなく 、人間のレビュワーによって見られることもありません。 Business Starter / Business Standard / Business Plus Enterprise Starter / Enterprise Standard / Enterprise Plus Essentials Enterprise Essentials / Enterprise Essentials Plus Frontline Starter / Frontline Standard Nonprofits さらに Google Workspace では、Gemini アプリを利用できるユーザーを限定したり、逆に組織全体で利用可能にするなど、利用可否のコントロールも可能です。 参考 : Gemini for Google Workspace に関するよくある質問 - Gemini アプリとは何ですか？ 参考 : Gemini アプリをオンまたはオフにする Gems Gemini アプリの機能の1つに Gems があります。Gems は Gemini ウェブアプリをカスタマイズするための機能です。2025年12月現在では、すべての Google Workspace ユーザーや、Google AI Pro ユーザーが利用可能です。 例えば、YouTube 動画の要約を表示するのに特化した Gems や、画像からテキストを抽出することに特化した Gems などを作成することができます。 詳細は以下の記事を参考にしてください。 blog.g-gen.co.jp 2. Gemini Enterprise Gemini Enterprise とは Gemini Enterprise は、Google が提供する企業向け Web サービスです。Google Workspace や Microsoft SharePoint Online、Outlook、Confluence、Jira などの企業向けサービスと接続でき、横断検索を実現できるほか、Gemini を使用したさまざまな AI タスクを実行できます。 企業や官公庁の従業員がデータを発見しやすくするのを助け、AI により業務を効率化することを助けるサービスです。 Gemini Enterprise は Google Cloud プロジェクトで管理され、ユーザーごとのライセンスを購入することで使用できます。Gemini Enterprise の利用にあたり Google Workspace の利用は必須ではなく、Entra ID などサードパーティの ID を使って Gemini Enterprise にログインできます。 参考 : Gemini Enterprise とは何ですか？ 参考記事 Gemini Enterprise の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 3. Gemini for Google Workspace Gemini for Google Workspace は業務補助ツール Gemini for Google Workspace とは Gemini for Google Workspace とは、Google Workspace にアドオンして利用する AI アシスタント機能です。Gemini の強力な生成 AI 技術が Gmail、Google ドキュメント、Google スライド、Google スプレッドシートなど、普段使い慣れた Google Workspace アプリに統合されることで、業務が効率化されます。 また Gemini for Google Workspace では エンタープライズグレードのデータ保護 が適用されており、データは Google によって サービス改善のために利用されることはなく 、人間のレビュワーによって 見られることもない ため、安心して業務に利用することができます。 現在（2025年1月16日以降）では、Gemini for Google Workspace が Business Starter や Enterprise Starter など一部のエディションを除くすべての Google Workspace コアライセンスに統合されています。つまり ほとんどの Google Workspace ユーザーは、Gemini for Google Workspace を標準で利用できます 。 参考 : Gemini for Google Workspace 参考 : Gemini for Google Workspace に関するよくある質問 参考 : Google Workspace の各エディションに追加される AI 機能 サイドパネル Gemini for Google Workspace では、 サイドパネル を通して Gemini が利用できます。 Gemini が統合されている Google Workspace アプリ（Google ドキュメント、Google スプレッドシートなど）では、Gemini アイコンが表示されます。例えば Google ドキュメントの場合、画面右上に Gemini アイコンがあります。このアイコンをクリックすると、サイドパネルにプロンプト入力画面が表示され、Gemini に指示を出すことができます。Gemini は指示を受け取ると、数秒でコンテンツを生成してくれます。 Google ドキュメント上の Gemini サイドパネル Gemini for Google Workspace が Google Worksapce のコアライセンスに統合 Gemini for Google Workspace の利用には、以前は Gemini for Google Workspace アドオンライセンスの追加購入が必要でした。しかし2025年1月16日、Google が新しい料金体系を発表し、同時に Business Starter や Enterprise Starter など一部エディションを除くすべての Google Workspace エディションで Gemini for Google Workspace が標準で利用可能になりました。以下は、改定前と改定後の料金一覧です（2025年7月現在）。 エディション 改定前（ユーザー/月） 改定後（ユーザー/月） Business Starter フレキシブル : 816円 年間契約 : 680円 フレキシブル : 950円 年間契約 : 800円 Business Standard フレキシブル : 1,632円 年間契約 : 1,360円 フレキシブル : 1,900円 年間契約 : 1,600円 Business Plus フレキシブル : 2,448円 年間契約 : 2,040円 フレキシブル : 3,000円 年間契約 : 2,500円 上記のように、改定後はライセンス料金が上がっているものの、改定後は Business Starter と Enterprise Starter を除き、アドオンなしで Gemini for Google Workspace が利用可能になっています。また、すでに Gemini アドオンライセンスを購入済みの場合、2025年1月31日以降は請求されなくなります。 既存の契約に対してこの料金改定がどのように反映されるかは、購入方法や契約の更新タイミング、購入経路によって異なります。ライセンスを Google から直接購入している場合は以下のドキュメントを参照してください。販売パートナーから購入している場合は、営業担当者にご確認ください。 参考 : Google Workspace Business エディションの AI 機能と料金改定 事例 Google Workspace に組み込みの AI 関連機能は、以下の記事で詳細に解説されています。G-gen の従業員が、ユーザーとして Gemini 関連機能を活用している事例を紹介する記事となっています。 blog.g-gen.co.jp 4. Gemini for Google Cloud Gemini for Google Cloud は開発補助ツール Gemini for Google Cloud とは Gemini for Google Cloud は、Google Cloud 上での開発に役に立つ、開発者向けの AI アシスタント機能です。ソースコードの自動生成、データ分析の効率化、セキュリティの強化などが可能です。 アプリケーション開発者はもちろん、データサイエンティストやビジネスアナリスト、セキュリティ担当者など、様々な Google Cloud ユーザーのオペレーション・開発を支援します。 参考 : Gemini for Google Cloud の概要 機能一覧 Gemini for Google Cloud には以下の機能が含まれています。 機能名 概要 Gemini in BigQuery データ分析、可視化、SQL や Python のコード生成などを支援 Gemini Code Assist IDE と連携して利用。ソースコード開発、デプロイ、トラブルシューティングを支援 Gemini in Colab Enterprise Colab EnterpriseノートブックでのPythonコード生成を支援 Gemini in Databases データベース管理、セキュリティ向上などを支援 Gemini in Looker Looker（Google Cloud コア）や Looker Studio Pro でデータ可視化や解釈を支援 Gemini in Security Command Center セキュリティに関する検索クエリ生成、ケース解釈、攻撃パス把握を支援 以下の当社記事も参考にしてください。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp 料金 Gemini for Google Cloud を利用するには、 Gemini Code Assist サブスクリプション を購入して、ユーザーに割り当てます。ライセンスを割り当てられたユーザーは、Gemini in BigQuery、Gemini in Databases、Gemini in Colab Enterprise などの機能が利用可能になります。 参考 : Set up Gemini Code Assist Standard and Enterprise Gemini Code Assist サブスクリプションには Standard と Enterprise の2エディションがあり、どちらを選ぶかによって付随する機能が異なります。以下は、2025年12月現在の価格です。最新の価格は、必ず公式ドキュメントを参照してください。 エディション 料金（月額） 料金（12ヶ月コミット） Standard $22.80 / 月 / 人 $19.0 / 月 / 人 Enterprise $54.0 / 月 / 人 $45.0 / 月 / 人 参考： Gemini for Google Cloud pricing ただし、Gemini in BigQuery のみ利用したい場合、料金は BigQuery の通常の料金に組み込まれており、 追加料金はありません 。ただし、利用する課金モード（オンデマンド課金または BigQuery Editions）によって使用可能な機能が異なることに注意してください。 Gemini in BigQuery の利用にあたっては、必ずしも Gemini Code Assist をサブスクライブする必要はありませんが、サブスクライブすると Gemini in BigQuery のすべての機能が使えることに加えて、クォータ（利用回数の制限）が緩和されます。 参考 : Gemini for Google Cloud pricing - Gemini in BigQuery Pricing Overview 5. Generative AI on Vertex AI Generative AI on Vertex AI では Google Cloud 経由で Gemini を利用 Generative AI on Vertex AI とは Generative AI on Vertex AI とは、Google Cloud の AI/ML プラットフォームプロダクトである Vertex AI の REST API を通して、Gemini などの生成 AI モデルを利用する手法のことです。アプリケーション開発者は Vertex AI API を通して Gemini モデルにプロンプトを入力し、レスポンスを得ることができます。 これにより、Gemini を自社開発のアプリケーションに組み込むことができます。 参考 : Overview of Generative AI on Vertex AI Vertex AI API は、HTTPS での呼び出しや、Python や Java などの各プログラミング言語用の公式クライアントライブラリ、また BigQuery ML などから利用できます。 Google Cloud プロダクトですので、認証・認可は IAM によって管理されており、また課金も Google Cloud 利用料として請求されます。 データの保護 Vertex AI API 経由で Gemini に入力されるプロンプトやチューニングデータは保護されており、データが Google によってサービス改善に利用されることはありません。 参考 : Vertex AI とデータの保持ゼロ ユースケース 以下の当社記事では、Vertex AI API 経由で Gemini を呼び出すことで生成 AI アプリケーションを開発した事例を紹介しています。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp その他のプロダクト Google Cloud には Vertex AI API 経由での Gemini 呼び出しのほか、Gemini を利用した各種プロダクトがあります。 Vertex AI Search は Vertex AI の派生プロダクトの1つです。Vertex AI Search により、RAG 構成（生成 AI により生成されたコンテンツをデータにより根拠づけするアーキテクチャ）を簡単に構成したり、Google クオリティの企業データ検索（エンタープライズサーチ）を容易に構築できます。 以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 料金 Generative AI on Vertex AI での Gemini 利用の料金は、入力したデータ量と出力したデータ量に応じた従量課金です。固定料金は発生しません。 以下は、料金単価の一部抜粋です。情報は2025年12月現在のものですので、必ず最新の公式ドキュメントをご参照ください。 モデル タイプ 単価 (200kトークン以下の入力の場合) Gemini 2.5 Flash 入力トークン数 $0.30 / 百万トークン Gemini 2.5 Flash 出力トークン数 (text) $2.50 / 百万トークン 参考： Cost of building and deploying AI models in Vertex AI - Google models 6. Gemini API（Google AI Studio） Google AI Studio 経由で Gemini API を利用 Gemini API とは Gemini API は、 Google AI Studio という個人・小規模開発者向けの AI 開発用プラットフォーム経由で提供されている、Gemini モデルを呼び出し可能な API です。Google Cloud の Generative AI on Vertex AI と同じく REST API やクライアントライブラリ経由で利用できます。 Gemini API（Google AI Studio）は Google Cloud の一部ではなく、別サービスとして提供されています。Gemini API は利用規約に従い、商用利用することができます。 Gemini API には無料枠があり、一定のレート制限のもと利用可能です。有償版は、リクエストや生成コンテンツのボリュームに基づいた従量課金です。 Google Cloud とは独立しているため、認証は IAM ではなく、Google AI Studio から発行する API キーで行われます。 参考 : Gemini API を使ってみる 参考 : Google AI Studio ユースケース Gemini API を提供する Google AI Studio は、 個人開発者や小規模開発、また学習者向け のプラットフォームです。これらの方々や、クイックに Gemini API を試してみたい方は、Google AI Studio 経由の Gemini API を利用します。なお、Google AI Studio の Gemini API への認証は、API キーを用いて行います。 一方で 企業による AI アプリ開発 などの用途で Gemini モデルを利用したい場合は、Google AI Studio ではなく、Google Cloud の Generative AI on Vertex AI を使うことが推奨 されます。Google Cloud（Generative AI on Vertex AI）のほうが、Model Armor などのセキュリティ機能や IAM による認証、他の Google Cloud サービスとの連携、カスタマーケアによるサポートなど、よりエンタープライズレベルの本番環境アプリケーションに適した機能を備えています。 以下の記事も参照してください。 blog.g-gen.co.jp データの保護 Gemini API を無料枠で利用する場合、入力したデータや生成されたコンテンツは、Google の サービス改善に利用されたり 、 人間のレビュワーに見られる 可能性があります。Google はこれを利用規約に明記しており、機密情報や個人情報を送信しないことを求めています。 Gemini API の有償版を利用する場合はデータが保護され、サービス改善に利用されたり、人間のレビュワーに見られることはありません。 参考 : Gemini API 追加利用規約 料金 Google AI Studio 経由での Gemini API は、入力したデータと出力したデータのボリュームに応じた従量課金です。ただし、Google Cloud の Generative AI on Vertex AI で利用する場合とは異なる料金設定がされており、文字数や画像の枚数ではなく、トークン量に応じた課金です。 参考 : 料金モデル 導入すべき Gemini プロダクト 生成 AI で社内業務を効率化したい場合 社内業務を効率化したい場合は、 Gemini アプリ や NotebookLM 、また Gemini for Google Workspace の導入を検討します。 これらのプロダクトにより、以下のような効果が期待できます。 個人やチームの生産性向上 メール、ドキュメント作成、プレゼンテーション作成、情報収集などを効率化 ほとんどの Google Workspace のエディションでは Gemini アプリがデータ保護付きで利用可能になっており、 https://gemini.google.com/ にアクセスすることですぐに業務利用することができます。NotebookLM も同様で、 https://notebooklm.google.com/ にアクセスすればすぐ利用可能です。 業務効率化のための各種 AI サービスの比較については、以下の記事も参照してください。 blog.g-gen.co.jp 自社データを効率的に検索したり生成 AI に質問に答えさせたい場合 自社の大量のドキュメント類の中から必要なデータを効率的に検索したり、生成 AI に要約させたい場合、Google Cloud プロダクトの1つである Vertex AI Search を使います。 蓄積された大量の自社データをもとに生成 AI にコンテンツを生成させたり、日本語での質問に答えさせたりすることもできます。 また、システムをまたいだ自社データの横断検索や、エージェント機能を利用できる Web サービスである Gemini Enterprise の利用も検討します。プログラムを実装することなく、サービスとして横断検索や生成 AI 機能を利用したいときに有効です。 参考 : Gemini Enterpriseを徹底解説！ - G-gen Tech Blog 自社の新サービスに生成 AI を組み込む場合 自社のアプリに生成 AI を組み込んだり、顧客へ提供するサービスに生成 AI を活用したい場合、 Generative AI on Vertex AI を使います。 自社アプリから Vertex AI 経由で Gemini を呼び出し、プロンプトを入力して、生成結果を得ることができます。システム開発の知識さえあれば、機械学習の知識がなくとも、Vertex AI や Vertex AI Search の API 呼び出しにより、高品質な検索や RAG を実現することができます。 システム開発を効率化したい場合 システム開発を効率化したい場合、コード生成補助機能などを備えた Gemini for Google Cloud を使います。 Gemini for Google Cloud の1機能である Gemini Code Assist は、月額サブスクリプション制であり、高度な開発補助機能を備えています。 ビジネス導入における注意点 生成 AI のビジネス適用 OpenAI 社が2022年11月に生成 AI チャットボット Chat GPT を公開してから、瞬く間に生成 AI ブームが巻き起こりました。2023年には多くの企業が、生成 AI のビジネス利用を試みる PoC（Proof of Concept）を行い、2024年には実際に業務で利用する企業も増えました。 生成 AI ブームに乗り遅れまいと、2025年も多くの企業が生成 AI の PoC や、業務への適用を試みるものと考えられます。しかし、生成 AI は銀の弾丸（万能薬）ではありません。以下に説明する性質を適切に理解し、ビジネスに適用することを検討してください。 生成 AI は確率エンジンであることを理解する Gemini を含む生成 AI は、大量のデータから学習し、確率的に 最もそれらしい回答を生成 する「確率エンジン」です。そのため、完璧な回答を返すとは限りませんし、毎回同じコンテンツが生成されるとも限りません。 この点を理解した上で、Gemini を活用する業務とそうでない業務を見極める必要があります。これを理解していないと、精度向上に報われない労力を注ぎ続けることになってしまいます。 参考 : The Prompt: 確率、データ、そして生成 AI に向き合うマインドセットとは 生成 AI に向いてる業務 / 向いてない業務 向いている業務 前述の性質から、生成 AI は以下のような業務領域を得意としています。 創造的な作業 新しいアイデアの創出、文章やコードの作成、デザイン、翻訳など 情報収集、分析 大量のデータの要約、トレンド分析、レポート作成など コミュニケーション 高度な正確性が求められない顧客対応、社内コミュニケーション、教育など 反復的な作業 データ入力、議事録作成、単純な質問への回答など 向いていない業務 反対に、以下のような業務には向いていません。 高度な判断や意思決定 専門知識や倫理観が求められる業務 正確性が求められる業務 医療診断、金融取引、法律相談など セキュリティ上、高度にセンシティブな業務 重要な個人情報や機密情報を含み、非常に高度なセキュリティ上の考慮が必要な業務 セキュリティ データ保護 生成 AI の業務利用では、入力したプロンプトや生成されたコンテンツが、生成 AI サービス提供事業者によってどう扱われるかに十分注意する必要があります。 多くの場合、無償の生成 AI プロダクトでは、入出力データが事業者の サービス改善のために利用されます 。これを防ぐには、有償版を購入し、 オプトアウト と呼ばれる「事業者によって入出力データがサービス改善に用いられないようにする」オプションを有効化する必要があります。 Gemini の場合、無償版の Gemini アプリや無償版の Gemini API（Google AI Studio）では、入出力データがサービス改善に利用されることが利用規約に明記されています。 一方で、Gemini for Google Workspace や Generative AI on Vertex AI（Google Cloud）では、入出力データにエンタープライズグレードのデータ保護が適用され、サービス改善などには利用されません。 この点をよく理解し、利用規約などを確認してください。 生成 AI アプリへの攻撃 特に自社アプリに生成 AI を組み込んで一般ユーザー向けに公開する場合、生成 AI の脆弱性を突く攻撃手法である プロンプトインジェクション などに十分注意する必要があります。 プロンプトインジェクションは、生成 AI に悪意を持って工夫したプロンプトを投入し、本来ユーザーがしるべきではない情報等を答えさせる手法です。これにより、機密情報やシステムの内部構造が漏洩するリスクがあります。 「アプリケーション内部構造におけるデータのアクセス権限設計」「システム側プロンプトの工夫」「レスポンスへのフィルタ設定」「生成 AI が担当する機能範囲の調整」など、適切な対処を行うことでリスクを低減することができます。 参考 : 責任ある AI 参考 : Google AI Studio - 安全に関するガイダンス 不適切な生成コンテンツ 生成 AI は確率論的な仕組みであるため、不適切な生成コンテンツが生成される可能性を否定できません。特に外部に公開する可能性のある生成 AI を組み込んだ自社アプリでは、政治、宗教、性的なコンテンツ、差別的な発言、ブランドイメージを毀損するようなコンテンツなどが生成されるリスクを低減する必要があります。 システムプロンプトを工夫することでそういった生成を抑止したり、Gemini では 安全フィルタ によってそのようなコンテンツが返答されることを防ぐことができます。 参考 : 安全性のためのシステム指示 参考 : 安全フィルタとコンテンツ フィルタ 対策 Google Cloud では、 Model Armor というサービスが提供されています。生成 AI モデルへのインプットとアウトプットを検査して、攻撃を試みるプロンプトや、不適切な出力を遮断することができます。詳細は以下の記事を参照してください。 blog.g-gen.co.jp 導入事例 業種や業態を問わず、様々な企業が Gemini を導入し、業務効率化や顧客満足度を向上しています。具体的な導入事例は、以下の記事を参考にしてください。 g-gen.co.jp g-gen.co.jp G-gen 社の提供する「Generative AI 活用支援ソリューション」では、Google Cloud のスペシャリストエンジニアが、貴社の Gemini 活用を支援します。開発を内製化する場合と、外注する場合の両方で活用いただけます。 g-gen.co.jp 米川 佐満人 (記事一覧) プラットフォームエンジニアリング本部 営業部 営業2課 兼 粉もん事業所 2022年7月にG-genにジョイン。 モットーは「クラウドで、関西を、もっと働きやすく」 課題解決に向けた提案＆お客様との伴走プロジェクトにモチベーションを感じる日々。現在 Google Cloud 全資格コンプリート目指して奮闘中（あと1つ）。ですが、本職は 光の戦士@FFXIV です。

G-gen の三浦です。当記事では2024年12月17日にベータ版として公開された Microsoft Teams から Google Chat への移行ツールの検証結果をご紹介します。 概要 Microsoft Teams からのデータ移行 とは 前提条件 制約 検証概要 検証環境 検証の流れ 設定手順 [Microsoft 365] Teams のグループ ID を確認 [Google Workspace] 移行用の csv ファイルの準備 [Google Workspace] データ移行の実施 [Microsoft 365] 移行後に、Teams で新規のメッセージを送信 [Google Workspace] 差分移行の実施 [Google Workspace] 移行を完了し、スペースを展開 概要 Microsoft Teams からのデータ移行 とは Teams からのメッセージの移行 機能は、Google Workspace の管理機能であり、Microsoft Teams（以下、Teams）のチャンネルのメッセージを Google Chat（以下、Chat）のスペースに移行することができます。 参考 : Teams からのメッセージの移行について（ベータ版） 前提条件 2024年12月現在、本機能はベータ版であり、正式リリースされていません。ベータ版機能の 本番環境での利用は非推奨 のため、テストや検証で使用してください。詳細は以下の利用規約をご確認ください。 参考 : Google Workspace サービス固有の利用規約 当機能で移行を実施するには、Google Workspace 側では特権管理者ロールが、Teams 側ではグローバル管理者ロールが必要です。 制約 当機能には以下のような制限があります。 チーム内のメッセージのみ移行可能です。ユーザー間の個別チャットやダイレクトメッセージは移行できません。 Teams の「チーム」は Chat の「スペース」に変換されます。ただし、元の権限（標準、プライベート）はすべて制限付きスペースに変換されます。制限付きスペースは後から変更可能です。 移行に関する制限の詳細は、以下公式ドキュメントをご確認ください。 参考 : チャットの移行で移行されるデータ（ベータ版） 検証概要 検証環境 検証環境は以下のとおりです。実際の移行ケースを想定し、Teams と Chat のドメインおよびユーザー情報を統一した環境で検証しました。 プラットフォーム ドメイン名 ユーザー名 ライセンス Google Workspace miurak-test.com teamstest@miurak-test.com Google Workspace Business Standard Microsoft 365 miurak-test.com teamstest@miurak-test.com Microsoft 365 Business Basic Teams のチームは以下のとおりです。 親ディレクトリ チーム名 種類 所有者 既定のディレクトリ 一般 標準 teamstest@miurak-test.com 既定のディレクトリ teams-channel-private プライベート teamstest@miurak-test.com 既定のディレクトリ teams-channel-public 標準 teamstest@miurak-test.com チーム設定 検証の流れ 以下の手順でデータの移行を実施します。 項目 作業 プラットフォーム 1 Teams のグループ ID を確認 Microsoft 365 2 移行用の csv ファイルの準備 Google Workspace 3 データ移行の実施 Google Workspace 4 移行後に、Teams で新規のメッセージを送信 Microsoft 365 5 差分移行の実施 Google Workspace 6 移行を完了し、スペースを展開 Google Workspace 設定手順 [Microsoft 365] Teams のグループ ID を確認 Microsoft Teams 管理センター（ https://admin.teams.microsoft.com ）にログインします。 参考 : Microsoft Teams 管理センターでチームを管理する [Teams] > [チームを管理] > [エクスポート] から、チーム情報を csv 形式でエクスポートします。 エクスポートを選択 エクスポートを実行 csv を確認し、 Groups Id を控えてください。 グループIDの確認 [Google Workspace] 移行用の csv ファイルの準備 Google Workspace の管理コンソール（ https://admin.google.com ）にログインします。 参考 : 管理コンソールにログインする [データ] > [データのインポートとエクスポート] > [データ移行（新規）] へ移動し、ステップ 2 の [サンプル csv をダウンロード] を選択します。 移行用のサンプル csv のダウンロード ダウンロードした csv を開き、 Source MicrosoftTeamsID の箇所に、前の手順で確認した Teams の Groups Id を入力し、保存します。 移行用の csv ファイルの編集 [Google Workspace] データ移行の実施 チャットの移行の [ステップ 1] で [Microsoft アカウントに接続] を選択し、移行ツールに権限を付与します。 Microsoftアカウントに接続 Microsoftアカウントを選択 アクセス許可内容を確認して承諾 接続を確認 [ステップ 2] の [移行マップの csv をアップロード] を選択し、前の手順で作成した csv ファイルを選択します。 作成したcsvのアップロード [ステップ 3] は、Teams と Chat のユーザー名が異なる場合のみ実施します。今回は同じため、省略します。 例: Microsoft 365 のユーザーが miura-teams@miurak-test.com で、このユーザーを Google Workspace の miura-chat@miurak-test.com に関連付けたい場合に実施します。 ユーザーIDの関連付け 参考 : ステップ 4: ID マップを作成してアップロードする（必要な場合） [ステップ 4] で以下を選択して [保存] してください。 メッセージの移行開始日：Teams のメッセージを Chat へ移行する開始日を選択します。 マッピングされていない ID：有効化 ID の移行元ドメインを保持する：Teams と Chat のドメインが同じ場合はこちらを選択 ID にターゲットドメインを使用する：Teams と Chat のドメインが異なる場合はこちらを選択 移行設定の選択 [ステップ 5] の [移行を開始] を選択します。 移行の開始 移行が完了したことを確認します。詳細は [移行レポート] または [概要レポート] をエクスポートすることで確認できます。 ※ この時点では、ユーザー側に移行したスペースは表示されません。差分を含めた移行作業をすべて完了し、最後に [スペースをロールアウト] することで表示されます。 移行完了確認 概要レポート [Microsoft 365] 移行後に、Teams で新規のメッセージを送信 データの移行後に Teams のチャンネルで新規のメッセージを送信します。 差分検知用のメッセージ [Google Workspace] 差分移行の実施 チャットの移行から [ステップ 5] の [差分移行を実行] を選択します。 差分移行を実施 処理が成功したことを確認します。 差分移行の成功 概要レポート [Google Workspace] 移行を完了し、スペースを展開 すべての移行が完了したら、[スペースをロールアウト] を選択します。 スペースのロールアウトを実施 注意事項を確認したうえで、[スペースをロールアウト] を実行します。この操作を行うと、Teams 側で新たに追加されたメッセージや変更内容は Chat に移行されません。事前に十分に確認したうえで進めてください。 注意事項を確認したうえで、[スペースをロールアウト] を実行します。特に以下の点にご注意ください この操作は、移行開始から30日以内に完了する必要があります。 30日を過ぎると、移行を最初からやり直す必要があります。 ロールアウト後、Teams 側でのメッセージや変更は再移行できません。 注意事項の確認とロールアウト実行 参考 : 手順 3: ユーザーがスペースとメッセージを利用できるようにする スペースの公開が完了したことを確認します。 公開確認 Chat を確認し、差分用のメッセージも含めて移行できることを確認します。 Google Chat でのデータ移行確認 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の三浦です。当記事では、Google ドライブのインベントリレポート機能を使ったセキュリティリスクの管理方法を紹介します。 概要 ドライブインベントリとは 前提条件 設定の概要 設定手順 [Google Cloud] BigQuery データセットの作成 [Google Workspace] インベントリレポートの有効化 [Google Cloud] レポートデータの確認 データ抽出例 サンプルクエリ①：アクセス権が「リンクを知っているインターネット上の誰もがアクセスできる」ファイルの抽出 サンプルクエリ②：特定のユーザーがオーナーとなっているファイルを抽出（マイドライブも含む） サンプルクエリ③：組織外のドメインと共有されているファイルを抽出 概要 ドライブインベントリとは Google ドライブの インベントリレポート機能 は、組織内の Google ドライブや共有ドライブの利用状況を把握し、管理者がデータを監査・管理するための機能です。 この機能を使えば、ドライブ内のファイル情報やアクセス権、更新日時を週次で BigQuery にエクスポートできます。これにより、 データ漏洩リスクの軽減 や 利用状況の可視化 が可能です。 参考 : BigQuery のドライブ インベントリ 参考 : ドライブのインベントリのエクスポート スキーマ 前提条件 ドライブインベントリレポート機能は、以下の Google Workspace エディションで使用できます。 Enterprise Standard Enterprise Plus Education Standard Education Plus Enterprise Essentials Plus Cloud Identity Premium 詳細は以下のドキュメントをご参照ください。 参考 : 組織のドライブのインベントリをエクスポートする 設定の概要 以下の手順でインベントリレポートを設定し、動作を確認します。 順番 作業場所 作業名 内容 1 Google Cloud BigQuery データセット作成 インベントリレポートをエクスポートする BigQuery データセットを作成します。 2 Google Workspace インベントリレポートの有効化 インベントリレポートを有効化します。 3 Google Cloud レポートデータの確認 BigQuery にエクスポートされたデータを確認します。 設定手順 [Google Cloud] BigQuery データセットの作成 BigQuery のデータセットを作成します。Google Workspace で データ リージョン ポリシー を使用している場合は、BigQuery のリージョンをポリシーで指定したリージョンと同一にします。 参考 : データの地理的な場所を選択する # 環境変数を設定 PROJECT_ID = " my_project " # Google Cloud プロジェクト ID を設定 BQ_DATASET = " my_dataset " # BigQuery のデータセット名を設定 BQ_LOCATION = " US " # BigQuery のリージョンを設定 GWS_USER = " admin@example.com " # Google Workspace 管理者アカウントを設定 　 # BigQuery データセットを作成 bq --project_id = $PROJECT_ID \ mk --location = $BQ_LOCATION \ $BQ_DATASET 　 # Google Workspace 管理者アカウントに BigQuery の編集権限を付与 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" user: $GWS_USER " \ --role =" roles/bigquery.dataEditor " 　 # Google Workspace 管理者アカウントに IAM の管理権限を付与 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" user: $GWS_USER " \ --role =" roles/resourcemanager.projectIamAdmin " [Google Workspace] インベントリレポートの有効化 Google Workspace の管理コンソール（ https://admin.google.com ）にログインします。 参考 : 管理コンソールにログインする [レポート] > [データ統合] へ移動し、[ドライブのインベントリのエクスポート] を選択します。 データ統合 以下を設定し、[保存] を選択します。 ドライブのインベントリ レポートの Google BigQuery へのエクスポートを有効にする： 有効化 BigQuery のプロジェクト ID： プロジェクト ID プロジェクト内の既存のデータセット： データセット名 エクスポート先の設定 エクスポートの有効化から初回のエクスポートまでは1～2週間かかります。2回目以降は週次でデータが更新されます。 参考 : 組織のドライブのインベントリをエクスポートする エクスポートが完了しない場合、管理者のログイベントを確認し、エラーの有無をご確認ください。 参考 : ドライブのインベントリのエクスポートに関連するイベント [Google Cloud] レポートデータの確認 Google Cloud コンソールからログインし、検索バーに BigQuery と入力し、[BigQuery] を選択します。 BigQuery検索 データセットアイコンを選択し、 [inventory] という名前のテーブルが表示されることを確認します。 インベントリの確認 データ抽出例 サンプルクエリ① ：アクセス権が「リンクを知っているインターネット上の誰もがアクセスできる」ファイルの抽出 想定ユースケース 誤って外部共有されているファイルの検出 データ漏洩リスクの高いファイルの特定 監査対応のための外部共有ファイルの一覧作成 SELECT id AS file_id, CONCAT ( ' https://drive.google.com/file/d/ ' , id, ' /view ' ) AS file_url, -- ファイルのURLを生成 title AS file_name, -- ファイル名 owner. user .email AS owner_email, -- オーナーのメールアドレス perm.email AS shared_with_email, -- 共有相手のメールアドレス（anyone の場合は null） perm.role AS shared_role, -- 共有役割（anyone の場合は null） perm. type AS shared_type -- 共有タイプ FROM `my_project.my_dataset.inventory`, -- データセットを指定 UNNEST( access .permissions) AS perm -- permissions を展開 WHERE perm. type = ' ANYONE ' -- 共有タイプが anyone のファイルを抽出 ORDER BY id; -- file_id でソート 実行結果 サンプルクエリ② ：特定のユーザーがオーナーとなっているファイルを抽出（マイドライブも含む） 想定ユースケース 退職者のデータ整理と引継ぎ 特定ユーザーのファイルアクセス状況の確認 重要データのユーザー単位での管理 SELECT child.id AS file_id, -- ファイルID child.title AS file_name, -- ファイル名 child.owner. user .email AS owner_email, -- オーナーのメールアドレス child.org_unit_path AS org_unit, -- 所属組織単位 parent.title AS parent_folder_name, -- 親フォルダ名 child.trashed AS is_trashed, -- ゴミ箱に入っているか (true:ゴミ箱入り) child.mime_type, -- MIMEタイプ child.size_bytes / ( 1024 * 1024 ) AS file_size_mb, -- ファイルサイズ（MB） child.create_time_micros AS created_time, -- 作成日時（マイクロ秒） child.last_modified_time_micros AS last_modified_time -- 最終更新日時（マイクロ秒） FROM `my_project.my_dataset.inventory` AS child -- データセットを指定 LEFT JOIN `my_project.my_dataset.inventory` AS parent -- 親フォルダ情報を取得するために自己結合 ON child.parent = parent.id -- 親フォルダのIDで結合 WHERE child.owner. user .email = ' user@example.com ' -- 抽出したいユーザーのメールアドレスを指定 ORDER BY child.last_modified_time_micros DESC ; -- 最終更新日時で降順ソート 実行結果 サンプルクエリ③ ：組織外のドメインと共有されているファイルを抽出 想定ユースケース 組織外とのファイル共有状況の把握 ファイル共有ポリシー違反の検出 外部ドメインとのデータ共有範囲の監視 SELECT id AS file_id, -- ファイルID title AS file_name, -- ファイル名 owner. user .email AS owner_email, -- オーナーのメールアドレス perm.email AS shared_with_email, -- 共有相手のメールアドレス perm.domain AS shared_with_domain, -- 共有相手のドメイン perm.role AS shared_role -- 共有役割 FROM `my_project.my_dataset.inventory`, -- データセットを指定 UNNEST( access .permissions) AS perm -- permissions を展開 WHERE perm.domain NOT IN ( ' example.com ' ) -- 自社ドメイン以外と共有されているファイルを抽出 ORDER BY shared_with_domain, file_name; -- ドメイン、ファイル名でソート 実行結果 上記以外にも公式ドキュメントにサンプルクエリがありますので、ご確認ください。 参考 : クエリの例 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

2024年12月17日より、Cloud Run を呼び出すための権限を持つ3つの事前定義ロールが新たに利用可能となりました。当記事ではロールの詳細や、従来から利用されてきた事前定義ロールとの違いなどを解説します。 はじめに 新たな事前定義ロール Cloud Run サービス起動元 Cloud Run ジョブ エグゼキュータ オーバーライドを使用する Cloud Run ジョブ エグゼキュータ Cloud Run 起動元ロールとの比較 権限内容の比較 Cloud Run jobs のキャンセル、オーバーライドに関して 参考リンク はじめに 2024年12月17日より、Cloud Run を呼び出すための権限を持つ以下の3つの事前定義ロールが新たに利用可能となりました。 Cloud Run サービス起動元（ roles/run.servicesInvoker ） Cloud Run ジョブ エグゼキュータ（ roles/run.jobsExecutor ） オーバーライドを使用する Cloud Run ジョブ エグゼキュータ（ roles/run.jobsExecutorWithOverrides ） 当記事ではロールの詳細や、従来から利用されてきた事前定義ロールとの違いなどを解説します。 新たな事前定義ロール Cloud Run サービス起動元 Cloud Run サービス起動元 （ roles/run.servicesInvoker 、英名 Cloud Run Service Invoker）ロールは以下の権限のみが付与された事前定義ロールで、Cloud Run services のサービス呼び出し、および Cloud Run functions の関数呼び出しを可能にします。このロールを持っていても Cloud Run jobs のジョブ実行はできません。 run.routes.invoke Cloud Run ジョブ エグゼキュータ Cloud Run ジョブ エグゼキュータ （ roles/run.jobsExecutor 、英名 Cloud Run Jobs Executor）ロールは以下の2つの権限が付与された事前定義ロールで、Cloud Run jobs のジョブ実行とジョブのキャンセルを可能にします。このロールを持っていても、Cloud Run services のサービス呼び出し、および Cloud Run functions の関数呼び出しはできません。 run.jobs.run run.executions.cancel オーバーライドを使用する Cloud Run ジョブ エグゼキュータ オーバーライドを使用する Cloud Run ジョブ エグゼキュータ （ roles/run.jobsExecutorWithOverrides 、英名 Cloud Run Jobs Executor With Overrides）ロールは以下の3つの権限が付与された事前定義ロールで、Cloud Run jobs のジョブ実行、ジョブのキャンセルのほか、 ジョブ構成をオーバーライドしたジョブの実行 が可能です。 run.jobs.run run.executions.cancel run.jobs.runWithOverrides ジョブ構成をオーバーライドした実行の詳細については以下の記事で解説しています。 blog.g-gen.co.jp Cloud Run 起動元ロールとの比較 権限内容の比較 従来、Cloud Run のサービス・関数・ジョブの実行については、 Cloud Run 起動元 （ roles/run.invoker ）ロールの使用が推奨されていました。この事前定義ロールには、以下の2つの権限が付与されています。これらの権限により、サービス・関数・ジョブのいずれも実行することができます。 run.routes.invoke run.jobs.run 新しい事前定義ロール、特に「Cloud Run サービス起動元」と「Cloud Run ジョブ エグゼキュータ」の2つは、従来からある Cloud Run 起動元 ロールの役割を分割したような形になっています。これにより、「サービス・関数の呼び出しのみができるプリンシパル」と「ジョブの実行のみができるプリンシパル」といった 最小権限の原則 を意識した権限管理ができるようになります。 Cloud Run jobs のキャンセル、オーバーライドに関して 従来の Cloud Run 起動元ロールには、Cloud Run jobs のジョブ実行をキャンセルするための権限（run.executions.cancel）や、ジョブ構成をオーバーライドするための権限（run.jobs.runWithOverrides）がありません。そのため、ジョブのキャンセルやオーバーライドを行いたい場合は Cloud Run 開発者 （roles/run.developer）ロールが必要でした。 しかし、Cloud Run 開発者 ロールは Cloud Run の作成、更新、削除の権限も持っているため、プリンシパルにジョブの実行に関することだけをさせたい場合、過剰な権限を与えてしまうことになります。 新たに追加された「Cloud Run ジョブ エグゼキュータ」および「オーバーライドを使用する Cloud Run ジョブ エグゼキュータ」ロールでは、ジョブの実行時に必要となる権限 のみ が付与されています。 そのため、たとえばワークフローから環境によって構成をオーバーライドしたジョブを実行するようなケースで、ワークフローが使用するサービスアカウントなどのプリンシパルに対して過剰な権限を持たせずに済みます。 参考リンク Cloud Run IAM roles（公式ドキュメント） 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の三浦です。当記事では Google Workspace（Cloud Identity）を使用して、Slack にシングルサインオン（以下、SSO）を設定する方法を紹介します。 基礎知識 シングルサインオン（SSO）とは SAML 認証とは SAML 認証の流れ Google Workspace の SSO 対応するアプリ Google Workspace を IdP とするメリット 対応エディション 検証の概要 検証作業 [Google Workspace] カスタム SAML アプリの作成 [Google Workspace] カスタム SAML アプリのユーザー設定 [Slack] SAML 認証設定 [Slack] Slack への直接アクセス確認 [Google Workspace] Google Workspace アプリ経由の確認 [Google Workspace] コンテキストアウェアアクセスの設定手順確認 基礎知識 シングルサインオン（SSO）とは シングルサインオン （SSO）とは、一度の認証で複数のアプリケーションやサービスを利用できるようにするための仕組みです。利用者が複数のサービスを利用するとき、通常はサービスごとに ID とパスワードを入力します。これを1度で済むようにする仕組みが SSO です。 SSO を実装することで、以下の効果が得られます。 利便性向上 ユーザーはアプリケーションごとにパスワードを入力する必要がなくなります。 セキュリティ強化 パスワードの管理が簡素化され、セキュリティリスクを軽減できます。 SAML 認証とは SSO を実現するプロトコルの一つに SAML （Security Assertion Markup Language）があります。SAML は、認証情報を安全にやり取りするための標準規格です。現在では SAML 2.0 が標準とされています。 SAML による認証情報のやりとりを理解するためには、以下の2つの役割を理解する必要があります。 IdP （Identity Provider） アイデンティティ（アカウント）を保存したり、管理する役割。SSO では認証を担う。当記事では Google Workspace が該当。 SP （Service Provider） 認証済みのユーザーが実際に利用するサービス。今回の例では Slack が該当。 SAML 認証の流れ Slack を例に取ると、ユーザーから見た認証の流れは以下のようになります。 ユーザーが Slack（SP） にアクセス Google Workspace（IdP）にリダイレクトされ、認証が行われる Slack にリダイレクトされ、ログインが完了 Google Workspace の SSO 対応するアプリ Google Workspace を IdP として利用すれば、多くのクラウドサービスで SAML 認証を使用したシングルサインオンを実現できます。 例えば、以下のようなサービスが「統合対応 SAML アプリ」としてネイティブに対応しています。 Amazon Web Services Notion ServiceNow Tableau Zendesk またネイティブに対応していないサービスでも、SAML 2.0 規格に準拠していれば、「カスタム SAML アプリ」として SSO 設定が可能です。 参考 : 統合対応 SAML アプリの一覧 参考 : カスタム SAML アプリを設定する Google Workspace を IdP とするメリット Google Workspace を IdP として利用することで、SSO の効果をさらに高める以下の利点があります。 Google アカウントの統一管理 Google アカウントを認証基盤として使用するため、複数のアカウントやパスワードを管理する必要がなくなり、ユーザーの利便性が向上。 セキュリティ強化 多要素認証（Google Authenticator やセキュリティキーの利用）やコンテキストアウェアアクセス（IP アドレスやデバイスによるアクセス制御）を活用し、企業のセキュリティ要件やリスク管理方針に応じた柔軟な認証ポリシーを設定可能。 幅広いサービスとの連携 Google Workspace を通じて、Slack などの外部サービスだけでなく、Google Workspace 内部のサービス（Google Drive、Google Meet など）へのアクセスも一元管理。 2段階認証やコンテキストアウェア アクセスについては、以下の公式ドキュメントも参考にしてください。 参考 : 2 段階認証プロセスでビジネスを保護する 参考 : コンテキストアウェア アクセスでビジネスを保護する 対応エディション Google Workspace では、Essentials Starter 以外の全エディションで、Google Workspace を IdP とした SSO を構成できます。 Cloud Identity でも同様に、Free と Premium の両エディションで、Cloud Identity を IdP とした SSO を構成できます。 参考 : Google Workspace の各エディションの比較 参考 : Cloud Identity の機能とエディションの比較 検証の概要 以下の手順で SSO を設定し、動作を確認します。 順番 作業場所 作業名 内容 1 Google Workspace カスタム SAML アプリの作成 Google Workspace 側で SAML 認証を設定 2 Google Workspace カスタム SAML アプリのユーザー設定 アプリを利用する対象（組織、グループ）を設定 3 Slack SAML 認証設定 Slack 側で SAML 認証を設定 4 Slack Slack への直接アクセス確認 Google Workspace にログインしていない状態で、SAML 認証が正しく動作するかを確認 5 Google Workspace Google Workspace アプリ経由の確認 Google Workspace のカスタム SAML アプリを利用して、SSO が正しく設定されているかを確認 6 Google Workspace コンテキストアウェアアクセスの設定手順確認 アクセス制限（IP アドレスやデバイス制御）の設定手順を確認 参考 : Google Workspace シングルサインオン 参考 : Slack クラウド アプリケーション なお前提として、Slack では Business+ または Enterprise Grid プランでのみ、SAML ベースの SSO を利用できます。Free プランや Pro プランでは利用できませんのでご注意ください。 参考 : チームに合ったプランを選択しましょう 検証作業 [Google Workspace] カスタム SAML アプリの作成 Google Workspace の管理コンソール（ https://admin.google.com ）にログインします。 参考 : 管理コンソールにログインする [アプリ] > [ウェブアプリとモバイルアプリ] > [アプリを追加] > [カスタム SAML アプリの追加] を選択します。 カスタム SAML アプリの追加 アプリ名を入力し、必要に応じてアイコンを添付します。入力が終わったら [続行] を選択します。 アプリ名の入力 管理者は、Slack 側に登録するために以下の3点を控えておき、[続行] を選択します。 SSO の URL エンティティ ID 証明書（右側のダウンロードアイコンを選択してダウンロードします） IdP 設定の確認 以下を入力し、[続行] を選択します。 ACS の URL ： https://${{Slack URL}}/sso/saml エンティティ ID ： https://slack.com 署名付き応答 ：有効化（チェックを入れる） 名前 ID ： [Basic Information] > [Primary email] Slack URL は、以下のドキュメントを参照して確認してください。 参考 : Slack URL または ID を確認する SP 設定 [マップングを追加] から以下の通りに設定し、[完了] を選択します。 [Basic Information] > [Primary email] ： User.Email [Basic Information] > [First name] ： first_name [Basic Information] > [Last Name] ： last_name 属性のマッピング [Google Workspace] カスタム SAML アプリのユーザー設定 作成したアプリの [ユーザー アクセス] を選択します。 ユーザーアクセスを選択 SAML 認証を利用する対象（ 組織全体 または 特定の組織部門 または Google グループ ）を選択し、[オン] > [保存（またはオーバーライド）] を選択します。 SAML アプリの有効化 [Slack] SAML 認証設定 管理者アカウントにて、[ワークスペース名] > [ツールと設定] > [ワークスペースの設定] を選択します。 ワークスペースの設定を選択 [認証] > [認証] から SAML 認証の [設定する] を選択します。 SAML 認証設定を選択 以下の通りに設定し、詳細設定の [開く] を選択します。 SAML 2.0 エンドポイント (HTTP) ： SSO の URL ID プロバイダ発行者 ： エンティティ ID 公開証明書 ：ダウンロードした証明書ファイルをテキストエディタで開き、その内容をコピーして貼り付けます。 SAML 認証設定1 以下を選択し、[設定を保存する] を選択します。 サービスプロバイダ発行者 ：カスタム SAML アプリで設定した エンティティ ID 署名付きレスポンス ：有効化（チェックを入れる） ワークスペースの認証が必要なメンバー ：SAML 認証が必要な対象を選択します。 SAML 認証設定2 SAML 認証設定3 SAML 認証が有効化されたことを確認します。 有効化確認 [Slack] Slack への直接アクセス確認 Google Workspace にログインしていない状態で、Slack の URL（例: https://${{Slack URL}} ）にアクセスします。 Slack URL へアクセス [SAML でサインイン] を選択します。 SAML でサインインを選択 Google のログイン画面が表示されるため、アカウント及びパスワードを入力して [次へ] を選択します。 Google ログイン 認証が完了すると Slack にリダイレクトされ、ログインできることを確認します。 ログイン確認（直接アクセス） [Google Workspace] Google Workspace アプリ経由の確認 Google Workspace にログインした状態で、[アプリ] > [カスタム SAML アプリ] を選択します。 カスタム SAML アプリを選択 Slack にログインできることを確認します。 ログイン確認（カスタム SAML アプリ） Google Workspace の管理画面から、ログを確認する方法も検証します。 [レポート] > [監査と調査] > [SAML ログイベント] から SAML 認証に関するログを確認できます。 ログ確認 [Google Workspace] コンテキストアウェアアクセスの設定手順確認 [セキュリティ] > [アクセスとデータ管理] > [コンテキストアウェアアクセス] > [アプリにアクセスレベルを割り当てる] を選択します。 アプリにアクセスレベルを割り当てる アクセスレベルを適用する対象として カスタム SAML アプリ を選択します。[割り当て] を選択することで、アクセスレベルを設定できます。 カスタム SAML アプリへの割り当て コンテキストアウェアアクセスの詳細な設定手順やアクセスレベルの作成方法については、以下の記事を参照してください。 blog.g-gen.co.jp 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の三浦です。当記事では、コンテキストアウェア アクセス（CAA）を使って Google ドライブ等の Google Workspace アプリケーションへのアクセスを制御する方法を紹介します。 コンテキストアウェア アクセスとは 前提条件 検証内容 動作確認 モニターモードの設定 動作確認（モニターモード） アクセスレベル変更（アクティブモード） 動作確認（アクティブモード） 複合条件の設定 複合条件の動作確認（アクティブモード） コンテキストアウェア アクセスとは コンテキストアウェア アクセス（以降、CAA）は、IP アドレスやデバイスの状態などのコンテキスト（背景情報）に基づいてアクセスを制御する、Google Workspace の機能です。 Google ドライブ、Gmail、Google カレンダー、Looker Studio などに条件付きでアクセス制御を適用できます。 使用例 : IP アドレス制限 : 社内ネットワークの IP アドレスからのみ Google ドライブへのアクセスを許可し、社外（自宅や公共 Wi-Fi）からの利用を禁止する。 デバイス制限 : 会社支給のモバイルデバイス（iPhone、Android）からのみ Gmail へのアクセスを許可し、私用デバイスからの利用を禁止する。 参考 : コンテキストアウェア アクセスの概要 前提条件 CAA は、Google Workspace（Cloud Identity）の特定のエディション（Frontline Standard、Enterprise Standard、Enterprise Plus、Cloud Identity Premium 等）で利用できます。 詳細は以下のドキュメントをご参照ください。 参考 : コンテキストアウェア アクセスでビジネスを保護する 検証内容 以下の手順で CAA を設定し、動作を確認します。 モニターモードの設定 社内 IP アドレスのみにアクセスを制限するルールを作成し、モニターモード（検知のみでブロックしない）で設定します。 動作確認（モニターモード） 社内外のアクセス状況を確認し、ログを確認します。 アクセスレベル変更（アクティブモード） アクティブモードに切り替え、条件外のアクセスをブロックするように設定します。 動作確認（アクティブモード） 社内 IP アドレスからアクセス可能で、社外からはブロックされることを確認します。 複合条件の設定 社内 IP アドレスに加え、多要素認証（MFA）を利用している場合のみ許可する条件を設定します。 複合条件の動作確認（アクティブモード） 条件に合致しないアクセスがブロックされることを確認します。 動作確認 モニターモードの設定 Google Workspace の管理コンソール（URL : https://admin.google.com ）にログインします。 参考 : 管理コンソールにログインする [セキュリティ] > [アクセスとデータ管理] > [コンテキストアウェア アクセス] に移動します。 コンテキストアウェア アクセスへ移動 CAA が無効な場合は、[有効にする] を選択して有効化します。その後 [アクセスレベル] を選択します。 有効化とアクセスレベルの選択 [アクセスレベルを作成] を選択します。 アクセスレベルを作成を選択 以下を設定し、[作成] を選択します。 アクセスレベル名 ：任意の名前を入力します。 条件 ：[基本] > [IP サブネット] を選択し、社内 IP アドレスを入力します。 1つ目のアクセスレベルの作成 [アプリに割り当て] を選択します。 アプリに割り当てを選択 適用する対象（ユーザーまたはグループまたは組織部門）とアプリを選択し、[割り当て] を選択します。 適用対象の選択 アクセスレベルを選択し、「監視」にチェックを入れて「続行」を選択します。 モニターモード（監視） では、アクセスレベルの影響範囲をログで確認でき、ブロックは行われません。 なおアクセスレベルは複数選択できますが、 OR 条件 で動作するため、いずれかのアクセスレベルを満たす場合は接続が許可されます。 参考 : アプリにコンテキストアウェア アクセスレベルを割り当てる アクセスレベルとモードの選択 [続行] を選択します。 続行を選択 内容を確認し、[割り当て] を選択します。 モニターモードの適用 動作確認（モニターモード） 社内および社外から Google ドライブ、Google カレンダー、Gmail にアクセスします。この段階では、どちらからもアクセス可能です。 アクセス確認 [レポート] > [監査と調査] > [コンテキストアウェア アクセスのログイベント] を選択します。 ログイベントの選択 以下の条件で検索し、モニターモードでブロックされたユーザーのログを確認します。意図しないブロックが発生していないか確認してください。 イベント 次に一致 アクセス拒否（モニターモード） アクセスレベルの適用 次の文字を含む アクセスレベル名 モニターモードのログ確認 アクセスレベル変更（アクティブモード） [セキュリティ] > [コンテキストアウェア アクセス] へ移動し、 [アプリにアクセスレベルを割り当てる] を選択します。 アプリにアクセスレベルを割り当てるを選択 アクセスレベルを適用する対象とアプリを選択し、[割り当て] を選択します。 割り当てを選択 監視 のチェックを外し、 アクティブ のチェックを入れて [続行] を選択します。 アクティブモードへの変更 [続行] を選択し、内容を確認し、[割り当て] を選択します。 続行を選択 アクティブモードの適用 動作確認（アクティブモード） 社内 IP アドレス及び社外 IP アドレスからアクセスします。社内 IP アドレスでは正常にアクセスでき、社外 IP アドレスではアクセスがブロックされることを確認します。 ブロック確認（IP サブネット） 複合条件の設定 [セキュリティ] > [コンテキストアウェア アクセス] に移動し、[アクセスレベル] > [アクセスレベルを作成] を選択します。 アクセスレベルを選択 アクセスレベルを作成を選択 以下を設定し [作成] を選択します。この条件により、 MFA 認証がされていないとアクセスがブロック されます。条件式の詳細については、以下のドキュメントを参照してください。 アクセスレベル名 ：任意の名前を入力します。 条件 ：[詳細] > request.auth.claims.crd_str.mfa == true 参考 : カスタム アクセスレベルの仕様 参考 : 詳細モードでのコンテキストアウェア アクセスの例 2つ目のアクセスレベルの作成 [終了] を選択します。 終了を選択 [コンテキストアウェア アクセス] > [アクセスレベル] へ移動し、1つ目と2つ目のルールの CEL名 を確認し、控えます。 CEL名の確認 [アクセスレベルを作成] を選択します。 [アクセスレベルを作成] を選択 以下を設定し [作成] を選択します。この条件により、 複数の条件（IP アドレス制限と多要素認証（MFA））を同時に満たす場合のみ アクセスが許可されます。 アクセスレベル名 ：任意の名前を入力します。 条件 ：[詳細] > levels.${{1つ目のアクセスレベルの CEL 名}} && levels.${{2つ目のアクセスレベルの CEL 名}} 3つ目のアクセスレベルの作成 [セキュリティ] > [コンテキストアウェア アクセス] へ移動し、 [アプリにアクセスレベルを割り当てる] を選択します。 アプリにアクセスレベルを割り当てるを選択 アクセスレベルを適用する対象とアプリを選択し、[割り当て] を選択します。 割り当てを選択 適用済みの1つ目のアクセスレベルを削除し、3つ目のアクセスレベルを選択し、 アクティブ のチェックを入れて、[続行] を選択します。 本番環境へ適用する場合は、まず [監視] のみにチェックを入れてモニターモードで影響がないことを確認した上で、アクティブモードに切り替えることを推奨します。 1つ目のアクセスレベルの削除 3つ目のアクセスレベルの選択 [続行] を選択し、内容を確認し、[割り当て] を選択します。 続行を選択 3つ目のアクセスレベルの適用 複合条件の動作確認（アクティブモード） 社内の IP アドレスかつ MFA が無効化されているアカウントからアクセスを確認し、以下画面が表示されることを確認します。 MFA が無効なアカウント ブロック確認（複合条件） [レポート] > [監査と調査] > [コンテキストアウェア アクセスのログイベント] を選択します。 ログイベントの選択 以下の条件で検索し、アクティブモードで拒否された接続ログを確認します。 アクセスレベルの不足 を確認することで、どのアクセスレベルでブロックされたかを特定できます。 イベント 次に一致 アクセスが拒否されました アクセスレベルの適用 次の文字を含む アクセスレベル名 ログの確認 アカウントのMFAを有効化後、ログアウトし、MFAを利用して再度ログインします。 ログイン時に このデバイスでは次回から表示しない を選択しないでください。選択すると、次回以降のログインで MFA 認証が省略され、CAA によってアクセスがブロックされます。 万が一選択してしまった場合は、以下のドキュメントを参照してログイン Cookie をリセットしてください。 参考 : 管理対象の Google アカウントからログアウトする MFA を利用してログイン Googleドライブにアクセスし、正常に表示されることを確認します。 アクセス確認 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の武井です。当記事では Privileged Access Manager を Terraform で管理する方法について紹介します。 はじめに 概要 Privileged Access Manager (PAM) PAM に必要な権限 利用資格の管理 利用資格の利用 (申請、承認) 全体構成 連携方式 ソースコード Direct Workload Identity および GitHub Actions ワークフロー Terraform ディレクトリ構成 env 配下 (呼び出し側) modules 配下 (モジュール) デプロイ terraform plan terraform apply リソース 動作確認 申請 承認 権限付与 権限はく奪 再申請 はじめに 概要 当記事では Google Cloud における一時的な IAM 権限付与を実現する仕組みである Privileged Access Manager (以降、PAM) を、Terraform と GitHub Actions による CI/CD で管理する方法を紹介します。 当記事で実現するのは、PAM の仕組みのデプロイです。API の有効化、サービスエージェントへの権限付与、利用資格 (entitlements) の作成などを Terraform で行うことで、デプロイ以降は PAM を使った承認フローにより、組織の IAM 権限を管理することができるようになります。 Privileged Access Manager (PAM) PAM の詳細は以下の記事で解説しています。 blog.g-gen.co.jp PAM での権限管理の仕組みを端的にまとめると、 利用資格 (entitlements) という設定情報にもとづき、一時的な権限の付与を行うものです。 利用資格（entitlements）は PAM のオブジェクトであり、承認フローと言い換えることもできます。利用資格には「付与する IAM ロール」「権限を付与する最大時間」「誰が権限をリクエストできるか」「誰がリクエストを承認できるか」「誰が通知を受け取るか」などを定義できます。 承認フローは以下のようになります。 申請者は 必要な権限、期間、その理由 を利用資格に明記し、承認者に提出する 承認者は、その妥当性を確認し申請を 承認もしくは否認 する 承認された場合、申請者に対し一定期間権限が付与される 所定の期間が経過すると、申請者に付与されていた権限は自動的にはく奪される PAM に必要な権限 PAM に必要な権限 (IAM ロール) については以下の通りです。 参考： Privileged Access Manager の権限と設定 利用資格の管理 利用資格を 管理(作成、更新、削除) するプリンシパルには、 Privileged Access Manager 管理者 ( roles/privilegedaccessmanager.admin ) が必要です。 また、利用資格を 組織ツリーの中のどこで 利用するかによって、以下のいずれかの権限が必要です。 組織全体：セキュリティ管理者（ roles/iam.securityAdmin ） フォルダ：フォルダ IAM 管理者（ roles/resourcemanager.folderIamAdmin ） プロジェクト：Project IAM 管理者（ roles/resourcemanager.projectIamAdmin ） 利用資格の利用 (申請、承認) 利用資格を用いて、権限付与を申請する、あるいは申請を承認するプリンシパルには、 Privileged Access Manager 閲覧者 ( roles/privilegedaccessmanager.viewer ) が必要です。 全体構成 当記事では利用資格を Terraform と GitHub Actions で管理します。 利用資格は 組織/フォルダ/プロジェクトレベル で設定可能ですが、今回は組織とプロジェクトレベルに PAM をデプロイします。 連携方式 Google Cloud と GitHub Actions の連携には Direct Workload Identity を使用します。 サービスアカウントキーやサービスアカウントの権限を借用する従来方式とは異なり、Workload Identity プールに必要な IAM 権限を直接付与します。 参考 : Workload Identity Federation ソースコード Direct Workload Identity および GitHub Actions ワークフロー 以下の記事で Direct Workload Identity を作成する bash スクリプトと GitHub Actions のワークフローを掲載しています。 blog.g-gen.co.jp なお、上記の記事に掲載したスクリプトで作成される Workload Identity プールに対しては、組織レベルで以下の IAM ロールを付与しており、利用資格の管理に必要な権限を包含しています。 オーナー ( roles/owner ) 組織管理者 ( roles/resourcemanager.organizationAdmin ) Terraform PAM のソースコードは以下のディレクトリ構成にもとづきます。 参考： google_privileged_access_manager_entitlement ディレクトリ構成 . ├── env │ ├── Test_Environment │ │ └── yutakei │ │ ├── backend.tf │ │ ├── locals.tf │ │ ├── main.tf │ │ └── versions.tf │ └── organization │ ├── backend.tf │ ├── locals.tf │ ├── main.tf │ └── versions.tf └── modules ├── apis │ ├── main.tf │ ├── outputs.tf │ └── variables.tf └── pam ├── main.tf ├── outputs.tf └── variables.tf env 配下 (呼び出し側) # backend.tf terraform { backend "gcs" { bucket = "common-tfstate" prefix = "terraform/organization/state" } } # locals.tf locals { organization_id = "1234567890" # 利用申請(entitlements)の設定 entitlements = { pam_org1 = { entitlement_id = "pam-organization-acm-demo" max_request_duration = "3600s" eligible_users = [ "user:demo-user01@dev.g-gen.co.jp" ] resource_type = "cloudresourcemanager.googleapis.com/Organization" resource = "//cloudresourcemanager.googleapis.com/organizations/1234567890" roles = [ "roles/accesscontextmanager.gcpAccessReader" , "roles/accesscontextmanager.policyReader" ] require_approver_justification = true approvals_needed = 1 approvers = [ "user:demo-user01@g-gen.co.jp" ] } } } # main.tf # 組織レベルでPAMを有効にするには、PAMサービスアカウントにPAMサービスエージェントロールが必要 resource "google_organization_iam_member" "pam_service_agent" { org_id = local.organization_id role = "roles/privilegedaccessmanager.serviceAgent" member = "serviceAccount:service-org-$ { local.organization_id } @gcp-sa-pam.iam.gserviceaccount.com" } module "pam" { source = "../../modules/pam" entitlements = local.entitlements parent = "organizations/$ { local.organization_id } " location = "global" } # versions.tf terraform { required_version = "~> 1.9.7" required_providers { google = { source = "hashicorp/google" version = "~> 6.6.0" } } } provider "google" { user_project_override = true } # backend.tf terraform { backend "gcs" { bucket = "common-tfstate" prefix = "terraform/yutakei/state" } } # locals.tf locals { project_id = "yutakei" apis = [ "privilegedaccessmanager.googleapis.com" , ] # 利用申請(entitlements)の設定 entitlements = { pam1 = { entitlement_id = "pam-yutakei-bigquery-demo" max_request_duration = "3600s" eligible_users = [ "user:demo-user01@dev.g-gen.co.jp" ] resource_type = "cloudresourcemanager.googleapis.com/Project" resource = "//cloudresourcemanager.googleapis.com/projects/yutakei" roles = [ "roles/bigquery.jobUser" , "roles/bigquery.dataViewer" ] require_approver_justification = true approvals_needed = 1 approvers = [ "user:demo-user01@g-gen.co.jp" ] } pam2 = { entitlement_id = "pam-yutakei-gcs-demo" max_request_duration = "3600s" eligible_users = [ "user:demo-user01@dev.g-gen.co.jp" ] resource_type = "cloudresourcemanager.googleapis.com/Project" resource = "//cloudresourcemanager.googleapis.com/projects/yutakei" roles = [ "roles/storage.admin" ] require_approver_justification = true approvals_needed = 1 approvers = [ "user:demo-user01@g-gen.co.jp" ] } } } # main.tf module "apis" { source = "../../../modules/apis" project_id = local.project_id apis = local.apis } module "pam" { source = "../../../modules/pam" entitlements = local.entitlements parent = "projects/$ { local.project_id } " location = "global" } # versions.tf 割愛 modules 配下 (モジュール) # main.tf resource "google_privileged_access_manager_entitlement" "pam" { for_each = var.entitlements entitlement_id = each.value.entitlement_id location = var.location max_request_duration = each.value.max_request_duration parent = var.parent requester_justification_config { unstructured {} } eligible_users { principals = each.value.eligible_users } privileged_access { gcp_iam_access { resource_type = each.value.resource_type resource = each.value.resource # 複数のrole_bindingsを生成 dynamic "role_bindings" { for_each = each.value.roles content { role = role_bindings.value } } } } approval_workflow { manual_approvals { require_approver_justification = each.value.require_approver_justification steps { approvals_needed = each.value.approvals_needed approvers { principals = each.value.approvers } } } } } # outputs.tf output "entitlement_ids" { description = "List of entitlement IDs created" value = [ for entitlement in google_privileged_access_manager_entitlement.pam : entitlement.entitlement_id ] } variable "entitlements" { description = "A map of entitlement configurations" type = map ( object ( { entitlement_id = string max_request_duration = string eligible_users = list ( string ) resource_type = string resource = string roles = list ( string ) require_approver_justification = bool approvals_needed = number approvers = list ( string ) } )) } # variables.tf variable "parent" { description = "Parent resource (e.g., project, folder, or organization)" type = string } variable "location" { description = "Location for the entitlement" type = string default = "global" } # main.tf resource "google_project_service" "apis" { for_each = toset (var.apis) project = var.project_id service = each.value disable_on_destroy = false } # APIの有効化には時間がかかるため、待機時間を設定 resource "null_resource" "delay" { provisioner "local-exec" { command = "sleep 180" } depends_on = [ google_project_service.apis ] } # outputs.tf output "enabled_apis" { description = "List of enabled APIs for the project" value = [ for service in google_project_service.apis : service.id ] } # variables.tf variable "apis" { description = "List of APIs to enable" type = list ( string ) } variable "project_id" { description = "The ID of the project to create resources in" type = string } デプロイ terraform plan GitHub Actions ( terraform plan ) の実行結果です。 # 組織向けのワークフロー(terraform plan) Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # google_organization_iam_member.pam_service_agent will be created + resource "google_organization_iam_member" "pam_service_agent" { + etag = (known after apply) + id = (known after apply) + member = "serviceAccount:service-org-1234567890@gcp-sa-pam.iam.gserviceaccount.com" + org_id = "1234567890" + role = "roles/privilegedaccessmanager.serviceAgent" } # module.pam.google_privileged_access_manager_entitlement.pam["pam_org1"] will be created + resource "google_privileged_access_manager_entitlement" "pam" { + create_time = (known after apply) + entitlement_id = "pam-organization-acm-demo" + etag = (known after apply) + id = (known after apply) + location = "global" + max_request_duration = "3600s" + name = (known after apply) + parent = "organizations/1234567890" + state = (known after apply) + update_time = (known after apply) + approval_workflow { + manual_approvals { + require_approver_justification = true + steps { + approvals_needed = 1 + approvers { + principals = [ + "user:demo-user01@g-gen.co.jp" , ] } } } } + eligible_users { + principals = [ + "user:demo-user01@dev.g-gen.co.jp" , ] } + privileged_access { + gcp_iam_access { + resource = "//cloudresourcemanager.googleapis.com/organizations/1234567890" + resource_type = "cloudresourcemanager.googleapis.com/Organization" + role_bindings { + role = "roles/accesscontextmanager.gcpAccessReader" } + role_bindings { + role = "roles/accesscontextmanager.policyReader" } } } + requester_justification_config { + unstructured {} } } Plan: 2 to add, 0 to change, 0 to destroy. # プロジェクト向けのワークフロー(terraform plan) Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # module.apis.google_project_service.apis["privilegedaccessmanager.googleapis.com"] will be created + resource "google_project_service" "apis" { + disable_on_destroy = false + id = (known after apply) + project = "yutakei" + service = "privilegedaccessmanager.googleapis.com" } # module.apis.null_resource.delay will be created + resource "null_resource" "delay" { + id = (known after apply) } # module.pam.google_privileged_access_manager_entitlement.pam["pam1"] will be created + resource "google_privileged_access_manager_entitlement" "pam" { + create_time = (known after apply) + entitlement_id = "pam-yutakei-bigquery-demo" + etag = (known after apply) + id = (known after apply) + location = "global" + max_request_duration = "3600s" + name = (known after apply) + parent = "projects/yutakei" + state = (known after apply) + update_time = (known after apply) + approval_workflow { + manual_approvals { + require_approver_justification = true + steps { + approvals_needed = 1 + approvers { + principals = [ + "user:demo-user01@g-gen.co.jp" , ] } } } } + eligible_users { + principals = [ + "user:demo-user01@dev.g-gen.co.jp" , ] } + privileged_access { + gcp_iam_access { + resource = "//cloudresourcemanager.googleapis.com/projects/yutakei" + resource_type = "cloudresourcemanager.googleapis.com/Project" + role_bindings { + role = "roles/bigquery.jobUser" } + role_bindings { + role = "roles/bigquery.dataViewer" } } } + requester_justification_config { + unstructured {} } } # module.pam.google_privileged_access_manager_entitlement.pam["pam2"] will be created + resource "google_privileged_access_manager_entitlement" "pam" { + create_time = (known after apply) + entitlement_id = "pam-yutakei-gcs-demo" + etag = (known after apply) + id = (known after apply) + location = "global" + max_request_duration = "3600s" + name = (known after apply) + parent = "projects/yutakei" + state = (known after apply) + update_time = (known after apply) + approval_workflow { + manual_approvals { + require_approver_justification = true + steps { + approvals_needed = 1 + approvers { + principals = [ + "user:demo-user01@g-gen.co.jp" , ] } } } } + eligible_users { + principals = [ + "user:demo-user01@dev.g-gen.co.jp" , ] } + privileged_access { + gcp_iam_access { + resource = "//cloudresourcemanager.googleapis.com/projects/yutakei" + resource_type = "cloudresourcemanager.googleapis.com/Project" + role_bindings { + role = "roles/storage.admin" } } } + requester_justification_config { + unstructured {} } } Plan: 4 to add, 0 to change, 0 to destroy. terraform apply GitHub Actions ( terraform apply ) の実行結果です。戻り値は先ほど同様のため割愛します。 リソース 組織では PAM サービスアカウントに対する IAM Policy と 利用資格 がデプロイされました。 プロジェクトでも 利用資格 がデプロイされました。 動作確認 申請 申請者のアカウントで PAM の管理画面にアクセスし、 権限付与をリクエスト をクリックします。 以下3項目を入力し、 権限付与をリクエスト をクリックすると、承認フローが承認者へと進みます。 権限付与の期間 (必須、最大時間が1時間の場合、30分/45分/1時間から選択できる) 理由 (必須) 通知の受信者 (任意、省略しても利用資格で設定した承認者にメール通知が行われる) 承認されるまでの間、当該利用資格のステータスは Approval Awaited となります。 ` 承認 承認者のアカウントで PAM の管理画面にアクセスすると、申請者からの承認フローが回ってきたことがわかります。 以下のメール通知が届きます。 承認 / 拒否 をクリックし申請内容を確認します。 コメント欄 (必須) に承認する旨を入力し、 承認 をクリックします。 権限付与 承認者には以下のメール通知が届きます。 利用資格のステータスも Approval Awaited > Active となっており、権限付与の残り時間も表示されています。 IAM Policy の管理画面を確認すると、今回利用資格の中で定義した2つのロールが PAM によって付与されたことがわかります。 権限はく奪 申請時に希望した付与時間 (今回は30分) が経過すると、先ほどまで付与されていたロールが PAM によってはく奪されていることがわかります。 再申請 利用資格のステータスが Available (申請開始前の状態) に戻っており、必要な際には再度同じ利用資格を使って申請が行えます。 武井 祐介 (記事一覧) クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2025 選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei

G-gen の武井です。当記事では Google Cloud と GitHub Actions (Terraform) を連携する Direct Workload Identity を作成する bash スクリプトを紹介します。 はじめに 概要 以前の記事との違い 制限事項 前提条件 免責事項 ソースコード スクリプトの使い方 認証 変数設定 実行 リソースの確認 Workload Identity プール・プロバイダー サービスアカウント Workload Identity プールの IAM Policy 構成 ソースコード (Terraform) Terraform ディレクトリ構成 ワークフロー (terraform.yaml) env/demo 配下 (呼び出し側) modules/apis 配下 (モジュール) プルリクエスト (terraform plan) マージ (terraform apply) はじめに 概要 当記事で紹介するのは、Google Cloud と GitHub Actions (Terraform) との連携に必要な Direct Workload Identity リソースを作成する bash スクリプトです。 以前の記事との違い 以前執筆した記事で紹介したのは、 サービスアカウントの権限を借用する形式 の Workload Identity リソースを作成するスクリプトです。 blog.g-gen.co.jp 今回ご紹介するのは、 Workload Identity プールに必要な権限 (IAM ロール) を直接付与する形式 の Workload Identity リソースを作成するスクリプトです。 この方式は、サービスアカウントの払い出しやサービスアカウントを借用するための権限付与が必要ないため、従来よりもセキュアな連携が可能で、Google Cloud、ならびに GitHub の公式ドキュメント上でも推奨されています。 参考： アクセス管理 参考： (Preferred) Direct Workload Identity Federation 制限事項 推奨される形式ではあるものの、Direct Workload Identity には 対応可能なプロダクトや機能に制限があります。 対応していないプロダクトやその機能を管理したい場合、従来形式 (サービスアカウントの権限を借用する形式) の Workload Identity をご利用ください。 参考： ID 連携: プロダクトと制限事項 前提条件 当 bash スクリプトは、 Debian GNU/Linux 12 (bookworm) 上で開発され、動作確認されています。 また、以下のソフトウェアがインストールされていることが前提です。カッコ内は開発時のバージョンです。 gcloud（ Google Cloud SDK 486.0.0 ） スクリプト実行時は、実行先のプロジェクトに対して gcloud CLI を認証する必要があります。 参考 : ユーザー アカウントを使用して認可する 参考 : サービス アカウントを使用して承認する blog.g-gen.co.jp 免責事項 当記事で紹介するプログラムのソースコードは、ご自身の責任のもと、使用、引用、改変、再配布して構いません。 ただし、同ソースコードが原因で発生した不利益やトラブルについては、当社は一切の責任を負いません。 ソースコード 前述の 免責事項 をご理解のうえ、ご利用ください。 init.sh #!/bin/bash # エラーハンドリング: エラーが発生したらスクリプトを終了 set -e # 変数の設定 PROJECT_ID = "" # プロジェクトID (ex: gha-demo-prj) PROJECT_NUMBER = "" # プロジェクト番号 (ex: 1234567890) ORGANIZATION_ID = "" # プロジェクトの組織ID (ex: 0123456789) WORKLOAD_IDENTITY_POOL = "" # Workload Identityプール名 (ex: gha-demo-pool) WORKLOAD_IDENTITY_PROVIDER = "" # Workload Identityプロバイダ名 (ex: gha-demo-provider) GITHUB_REPO = "" # GitHubリポジトリ名 (ex: gha-demo-org/gha-demo-repo) # ログ出力関数 log() { echo " [INFO] $1 " } log_error() { echo " [ERROR] $1 " >&2 } # 1. IAM Credential API を有効化 if ! gcloud services list --enabled --filter =" name:iamcredentials.googleapis.com " --format =" value(name) " | grep " iamcredentials.googleapis.com " > /dev/null 2 >& 1 ; then log " IAM Credential API を有効にしています... " gcloud services enable iamcredentials.googleapis.com --project =" $PROJECT_ID " else log " IAM Credential API は既に有効化されています " fi # 2. Workload Identity プールの作成 if ! gcloud iam workload-identity-pools describe $WORKLOAD_IDENTITY_POOL --location =" global " --project =" $PROJECT_ID " > /dev/null 2 >& 1 ; then log " Workload Identity プールを作成中: $WORKLOAD_IDENTITY_POOL " gcloud iam workload-identity-pools create $WORKLOAD_IDENTITY_POOL \ --project =" $PROJECT_ID " \ --location =" global " \ --display-name =" $WORKLOAD_IDENTITY_POOL " else log " Workload Identity プールは既に存在します: $WORKLOAD_IDENTITY_POOL " fi # 3. Workload Identity プロバイダの作成 if ! gcloud iam workload-identity-pools providers describe $WORKLOAD_IDENTITY_PROVIDER --workload-identity-pool =" $WORKLOAD_IDENTITY_POOL " --location =" global " --project =" $PROJECT_ID " > /dev/null 2 >& 1 ; then log " Workload Identity プロバイダを作成中: $WORKLOAD_IDENTITY_PROVIDER " gcloud iam workload-identity-pools providers create-oidc $WORKLOAD_IDENTITY_PROVIDER \ --project =" $PROJECT_ID " \ --location =" global " \ --workload-identity-pool =" $WORKLOAD_IDENTITY_POOL " \ --display-name =" $WORKLOAD_IDENTITY_PROVIDER " \ --issuer-uri =" https://token.actions.githubusercontent.com " \ --attribute-mapping =" google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository " \ --attribute-condition =" assertion.repository==' $GITHUB_REPO ' " else log " Workload Identity プロバイダは既に存在します: $WORKLOAD_IDENTITY_PROVIDER " fi # 4. 組織レベルでのロール付与 log " 組織レベルでのロール付与の確認 " for role in " roles/resourcemanager.organizationAdmin " " roles/owner " ; do if ! gcloud organizations get-iam-policy $ORGANIZATION_ID --flatten =" bindings[].members " --filter =" bindings.members:principalSet://iam.googleapis.com/projects/ $PROJECT_NUMBER /locations/global/workloadIdentityPools/ $WORKLOAD_IDENTITY_POOL AND bindings.role: $role " --format =" value(bindings.role) " | grep " $role " > /dev/null 2 >& 1 ; then log " $role をWorkload Identity プールに付与中: $WORKLOAD_IDENTITY_POOL " gcloud organizations add-iam-policy-binding $ORGANIZATION_ID \ --member =" principalSet://iam.googleapis.com/projects/ $PROJECT_NUMBER /locations/global/workloadIdentityPools/ $WORKLOAD_IDENTITY_POOL /attribute.repository/ $GITHUB_REPO " \ --role =" $role " else log " $role は既にWorkload Identity プールに付与されています: $WORKLOAD_IDENTITY_POOL " fi done log " Direct Workload Identity 設定が完了しました。 " スクリプトの使い方 認証 まずは実行先のプロジェクトに対して gcloud CLI の認証を通します。 # 実行先プロジェクトの確認 $ gcloud config list [ core ] account = test-user@demo.g-gen.co.jp disable_usage_reporting = True project = gha-demo-prj Your active configuration is: [ gha-demo-prj ] # gcloud CLI の認証 $ gcloud auth login ~~中略~~ You are now logged in as [ test-user@demo.g-gen.co.jp ] . Your current project is [ gha-demo-prj ] . 変数設定 7~12行目 の変数に環境情報を入力します。 ※ 当スクリプトでは、サービスアカウントの変数定義はありません。 実行 スクリプトに実行権限を付与して実行します。 ※ 当スクリプトでは、以下のリソースは作成しません。 サービスアカウント サービスアカウントを借用するための IAM Policy Workload Identity プールとサービスアカウントの紐づけ # 実行権限付与 $ chmod +x init.sh $ ls -l -rwxr-xr-x 1 test-user test-user 3784 Nov 12 14:27 init.sh # スクリプト実行 $ ./init.sh [ INFO ] IAM Credential API は既に有効化されています [ INFO ] Workload Identity プールを作成中: gha-demo-pool Created workload identity pool [ gha-demo-pool ] . [ INFO ] Workload Identity プロバイダを作成中: gha-demo-provider Created workload identity pool provider [ gha-demo-provider ] . [ INFO ] 組織レベルでのロール付与の確認 [ INFO ] roles/resourcemanager.organizationAdmin をWorkload Identity プールに付与中: gha-demo-pool Updated IAM policy for organization [ 0123456789 ] . ~~中略~~ [ INFO ] roles/owner をWorkload Identity プールに付与中: gha-demo-pool Updated IAM policy for organization [ 0123456789 ] . ~~中略~~ [ INFO ] Workload Identity 設定が完了しました。 リソースの確認 Workload Identity プール・プロバイダー 以下のように作成されます。 Workload Identity プール (1/2) Workload Identity プール (2/2)、サービスアカウントを使用していない Workload Identity プロバイダー (1/2) Workload Identity プロバイダー (2/2) サービスアカウント 前述の通り、Direct Workload Identity にサービスアカウントは不要なため、当スクリプトでは作成しません。 Workload Identity プールの IAM Policy 以下のように作成されます。 ※ IAM ロールは適用先のセキュリティポリシーに応じて調整してください。 組織レベルの IAM Policy 構成 当スクリプトで作成される Workload Identity を使い、Google Cloud プロジェクトに対する terraform plan や terraform apply を、GitHub Actions で自動化します。 ワークフローや Terraform ソースコードは次項に記載のものを使用します。 ご利用される場合は、前述の 免責事項 をご理解のうえ、ご利用ください。 ソースコード (Terraform) Terraform ディレクトリ構成 . ├── .github │ └── workflows │ └── terraform.yaml ├── env │ └── demo │ ├── backend.tf │ ├── locals.tf │ ├── main.tf │ └── versions.tf ├── modules │ └── apis │ ├── main.tf │ ├── outputs.tf │ └── variables.tf ├── .gitignore ├── init.sh └── README.md ワークフロー (terraform.yaml) 以下の値をご自身の環境で作成したリソースに置き換えてください。 38行目 ： Workload Identity プロバイダー Direct Workload Identity では、 google-github-actions/auth@v2 でサービスアカウントを定義する必要はありません。 name : terraform # main ブランチへの Pull request と Merge on : pull_request : branches : - main push : branches : - main # ジョブ (GitHUb runners で実行) jobs : terraform-workflow : runs-on : ubuntu-latest permissions : id-token : write contents : read pull-requests : write strategy : matrix : # tf_working_dir に main.tf (呼び出し側) のディレクトリを指定 tf_working_dir : - ./env/demo steps : - uses : actions/checkout@v4 name : Checkout id : checkout # Workload Identity 連携 # https://cloud.google.com/iam/docs/using-workload-identity-federation#generate-automatic - id : 'auth' name : 'Authenticate to Google Cloud' uses : 'google-github-actions/auth@v2' with : workload_identity_provider : 'projects/1234567890/locations/global/workloadIdentityPools/gha-demo-pool/providers/gha-demo-provider' # https://github.com/marketplace/actions/setup-tfcmt - uses : shmokmt/actions-setup-tfcmt@v2 name : Setup tfcmt # https://github.com/marketplace/actions/setup-github-comment - uses : shmokmt/actions-setup-github-comment@v2 name : Setup github-comment # https://github.com/actions/setup-node # https://github.com/hashicorp/setup-terraform/issues/84 - uses : actions/setup-node@v4 with : node-version : '18' - uses : hashicorp/setup-terraform@v3 name : Setup terraform - name : Terraform fmt id : fmt run : | cd ${{ matrix.tf_working_dir }} terraform fmt -recursive continue-on-error : true - name : Terraform Init id : init run : | cd ${{ matrix.tf_working_dir }} terraform init -upgrade - name : Terraform Validate id : validate run : | cd ${{ matrix.tf_working_dir }} terraform validate # main ブランチへ pull request した際に terraform plan を実行 - name : Terraform Plan id : plan if : github.event_name == 'pull_request' run : | cd ${{ matrix.tf_working_dir }} export GITHUB_TOKEN=${{ secrets.GITHUB_TOKEN }} tfcmt -var target:${{ matrix.tf_working_dir }} plan -- terraform plan --parallelism=50 github-comment hide -condition 'Comment.Body contains "No changes."' continue-on-error : true # terraform status で失敗した際に workflow を停止 - name : Terraform Plan Status id : status if : steps.plan.outcome == 'failure' run : exit 1 # main ブランチへ push した際に terraform apply を実行 - name : Terraform Apply id : apply if : github.ref == 'refs/heads/main' && github.event_name == 'push' run : | cd ${{ matrix.tf_working_dir }} export GITHUB_TOKEN=${{ secrets.GITHUB_TOKEN }} tfcmt -var target:${{ matrix.tf_working_dir }} apply -- terraform apply -auto-approve -input= false --parallelism=50 env/demo 配下 (呼び出し側) # backend.tf terraform { backend " gcs " { bucket = " gha-demo-prj-tfstate " prefix = " terraform/state " } } # locals.tf locals { project_id = " gha-demo-prj " apis = [ " artifactregistry.googleapis.com ", " cloudapis.googleapis.com ", " cloudasset.googleapis.com ", " cloudresourcemanager.googleapis.com ", " iam.googleapis.com ", " iamcredentials.googleapis.com ", " servicemanagement.googleapis.com ", " serviceusage.googleapis.com ", " sts.googleapis.com ", ] } # main.tf module " apis " { source = " ../../modules/apis " project_id = local.project_id apis = local.apis } # versions.tf terraform { required_version = " ~> 1.9.7 " required_providers { google = { source = " hashicorp/google " version = " ~> 6.6.0 " } } } provider " google " { user_project_override = true } modules/apis 配下 (モジュール) # main.tf resource " google_project_service " " apis " { for_each = toset ( var.apis ) project = var.project_id service = each.value disable_on_destroy = false } resource " null_resource " " delay " { provisioner " local-exec " { command = " sleep 180 " } depends_on = [ google_project_service.apis ] } # outputs.tf output " enabled_apis " { description = " List of enabled APIs for the project " value = [ for service in google_project_service.apis : service.id ] } # variables.tf variable " apis " { description = " List of APIs to enable " type = list ( string ) } variable " project_id " { description = " The ID of the project to create resources in " type = string } プルリクエスト (terraform plan) Direct Workload Identity でも、main ブランチへのプルリクエストをトリガーに terraform plan が実行されました。 ※ プルリクエストの場合、 terraform apply はスキップされます。 プルリクエストをトリガーに terraform plan が自動実行 マージ (terraform apply) Direct Workload Identity でも、main ブランチへのマージをトリガーに terraform apply が実行されました。 ※ マージの場合、 terraform plan はスキップされます。 マージをトリガーに terraform apply が自動実行 武井 祐介 (記事一覧) クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2025 選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei