G-genの菊池です。Looker におけるデータモデリングにおいて、複雑な分析や集計を効率化する 派生テーブル （Derived Tables）について、その機能分類と選定の基準を解説します。 Looker の派生テーブルとは 定義方法による分類 概要 ネイティブ派生テーブル SQL ベースの派生テーブル データの保持方法による分類 概要 一時的な派生テーブル 永続的な派生テーブル（PDT） 永続性戦略 概要 トリガーベースの戦略 保存期間ベースの戦略 データベースが管理する戦略（マテリアライズドビュー） 増分 PDT 概要 利用するための必須条件 Looker 派生テーブルの選定基準 概要 定義方法の選定基準 データの保持方法の選定基準 PDT の永続性戦略や増分 PDT の選定基準 Looker の派生テーブルとは Looker の 派生テーブル とは、LookML 内で定義したクエリ結果を、データベース内の実際のテーブルのように使用できるようにする機能です。 派生テーブルを使用することで、複数の種類のデータを事前結合したり大量のデータを集計したりした結果を、あたかも1つのテーブルであるかのように扱うことができます。 例えば、顧客が行った注文の数や初回注文日時など、顧客ごとの集計値を事前に計算した派生テーブルを作成することで、データベース内の他のテーブルと同じようにデータ探索ができます。 参考 : Lookerの派生テーブル 定義方法による分類 概要 派生テーブルは定義に方法に応じて「ネイティブ派生テーブル」「SQL ベースの派生テーブル」に分類することができます。 参考 : Lookerの派生テーブル - ネイティブ派生テーブルとSQLベースの派生テーブル ネイティブ派生テーブル ネイティブ派生テーブル は、LookML を使用して定義される派生テーブルです。既存の Explore （エクスプローラ）の定義を再利用して作成します。 ネイティブ派生テーブルの大きなメリットとして、まずデータモデルの可読性と保守性が向上します。ネイティブ派生テーブルは、LookML 内ですでに定義されているディメンションやメジャーを参照して定義されます。そのため、SQL を直接記述するアプローチと比較して、データをモデル化するときの読みやすさと理解しやすさが向上します。 また、コードを記述する手間を大幅に削減できるという利点があります。Looker の Explore 機能の画面上で派生テーブルとして表示したいデータの形を整えた後、そこからネイティブ派生テーブル用の LookML を自動生成してコピーできるため、一から手動でコードを記述する手間を省くことができます。 Explore 機能で表示データ作成 ネイティブ派生テーブルの LookML を取得 さらに、フィルタ機能の簡単な適用とシームレスな連携が可能です。豊富なフィルタ機能をLookMLの構文で直接適用できることに加え、 bind_filters や bind_all_filters といった機能を使用することで、元の Explore でユーザーが設定した日付などのフィルタ条件を、派生テーブル側のクエリにも簡単に連携させることができます。 ネイティブ派生テーブルの注意点として、ネイティブ派生テーブルは LookML の構文に依存しているため、複数ステップの処理を必要とする SQL 構文やカスタム DDL（データ定義言語）が必要なケースには対応できません。 さらに、既存の LookML モデルへの依存度が高い点も挙げられます。ネイティブ派生テーブルは既存の Explore（エクスプローラ）の定義をベースに構築されるため、参照したいテーブルや結合関係が LookML 上にまだ定義されていない場合は、まずその基礎となるデータモデリングから始める必要があります。 SQL ベースの派生テーブル SQL ベースの派生テーブル は、標準的な SQL クエリを直接記述して定義する派生テーブルです。 SQL ベースの派生テーブルの大きなメリットとして、まず既存の SQL 資産を手軽に流用できる点が挙げられます。Looker の「SQL Runner」機能で作成・テストした SQL クエリを、そのまま派生テーブルの定義へと簡単に変換できるショートカット機能が用意されています。これにより、すでに動作確認済みの SQL や、データアナリストが書き慣れた SQL クエリを素早く Looker のデータモデルに組み込むことができます。 SQL Runner 機能で SQL クエリ作成 SQL ベース派生テーブルの LookML を取得 また、ネイティブ派生テーブル（LookML）では表現が難しい、高度で複雑な処理を実現できる点も重要な強みです。単一の SQL ステートメントでテーブルを作成できず複数ステップの処理が必要な環境や、BigQuery ML のようなデータベース固有のカスタム DDL コマンドを実行したいといった、極めて高い柔軟性が求められるケースに対応できます。 ただし、保守性や運用面においては注意が必要です。SQL ベースの派生テーブルは、基盤となるデータベースのスキーマで列の追加や削除などがされた際、エラーを防ぐために手動で SQL の記述を修正しなければなりません。そのため、基本的には可読性やメンテナンス性が高いネイティブ派生テーブルの利用を第一に検討し、どうしても SQL の直接記述や特殊な機能が必要な場面に限って SQL ベースの派生テーブルを採用することが推奨されます。 データの保持方法による分類 概要 派生テーブルは「ネイティブ派生テーブル」「SQL ベースの派生テーブル」という分類のほかに、データの保持方法に応じて「一時的な派生テーブル」「永続的な派生テーブル（PDT）」にも分類できます。 それぞれの組み合わせで、4種類の派生テーブルがあり得ることになります。 参考 : Lookerの派生テーブル - 一時的な派生テーブルと永続的な派生テーブル 一時的な派生テーブル 一時的な派生テーブル は、データベースに物理的なテーブルとして書き込まれない派生テーブルです。 ユーザーが Explore などでデータをリクエストするたびに、Looker が派生テーブルの定義を使用して SQL クエリを構成し、都度データベースに対して新しいクエリを実行します。 ただし、有効なキャッシュが存在する場合はそれが使用されます。 データベースに実際のテーブルを作成しないため、Looker 用の書き込み権限や専用のスキーマを事前に準備する必要がありません。 また、リクエストのたびにクエリが実行されるため、常にベースとなるテーブルの最新のデータ状態を反映した結果を得ることができます。そのため、一時的な派生テーブルは、常に最新データを取得したい場合や、実行速度が速くデータベースに過度な負荷をかけない軽量なクエリに向いています。 一方で、クエリの実行に長時間を要する重い処理の場合は、パフォーマンスの低下を避けるために永続的な派生テーブル（PDT）を使用します。 永続的な派生テーブル（PDT） 永続的な派生テーブル （Persistent Derived Tables、略称 PDT）は、定義されたクエリの実行結果をデータベース上の スクラッチスキーマ （書き込み用の一時スキーマ）に実際のテーブルとして書き込み、指定したスケジュール（永続性戦略）に基づいて再構築する派生テーブルです。 一時的な派生テーブルがクエリのたびに都度計算されるのに対し、PDT は計算済みのデータをデータベース内に保持する仕組みを持っています。 PDT の最大のメリットは、頻繁に実行されるクエリの結果を保持することで、実行速度を向上させ、データベースへの負荷を大幅に削減できる点です。 特に、大量のデータや複数種類のデータを扱う場合（例：初回注文日を基準に顧客をコホート別に分類するなど）に有効で、リアルタイムで実行すると重い処理を事前に1度だけ計算し、その結果を PDT として再利用できます。 さらに、開発を効率化できる点も魅力です。データベース管理者（DBA）のサポートがなくても、Looker 上でインデックスやソートキーなどの最適化オプションを自らテストし、パフォーマンスの向上を確認してから DBA に本番環境への適用を依頼することができます。 永続性戦略 概要 永続性戦略 とは、永続的な派生テーブル（PDT）の再構築タイミングを決める設定のことです。PDT はデータベース上に実テーブルとして書き込まれることになるため、データを最新化するタイミングが重要になります。 特定の値が変化したことなどを検知するトリガーベースの戦略、時間経過をきっかけとする保存期間ベースの戦略、データベースが管理する戦略（マテリアライズドビュー）があります。 参考 : Lookerの派生テーブル - 永続性戦略 トリガーベースの戦略 データグループ（ datagroups ）を使用する、最も推奨される戦略です。 データベースの特定の値を監視する SQL クエリ（ sql_trigger ）を定義し、その値が変化したとき（例として ETL 処理の完了を示すフラグが立ったとき）に PDT を再構築します。これにより、ソースデータの更新に合わせて効率的にテーブルを更新できます。 保存期間ベースの戦略 persist_for パラメータを使用して、PDT を保持する時間を指定します。 指定した時間が経過した後にクエリが実行されると、PDT が再構築されます。厳密な更新タイミングを必要としない場合や、設定の簡略化を優先する場合に使用します。 データベースが管理する戦略（マテリアライズドビュー） Google Cloud の BigQuery など、データベース側の マテリアライズドビュー 機能を利用する戦略です。 LookML で materialized_view: yes を指定することで、Looker の PDT 管理ロジックではなく、データベース側の自動更新ロジックに委ねることができます。 増分 PDT 概要 増分 PDT （Incremental PDTs）は、PDT をすべて作り直すのではなく、新しく追加されたデータのみを既存のテーブルに追加する機能です。 通常の PDT は再構築のたびにテーブル全体を削除して作成し直しますが、増分 PDT では increment_key （日付やタイムスタンプなど）を基準に、新しいデータのみを取得して追加します。 これにより、テーブルの再構築にかかる時間とデータベースのリソース消費を大幅に削減できます。 参考 : 増分 PDT 利用するための必須条件 増分 PDT を導入する際には、システム上必須となる条件（必須条件）と、パフォーマンスに影響する推奨条件の2つがあります。 まず、増分 PDT を有効にするための必須条件について説明します。 増分 PDT は、再構築のタイミングを制御する「永続性戦略」において、必ずトリガーベースの戦略を採用していなければなりません。保存期間をベースとする戦略では、Looker の仕様上サポートされていないためです。 また、新しいデータの追加範囲を Looker に認識させるため、照会期間を定義する increment_key パラメータの設定が不可欠です（SQL ベースの場合はさらに Liquid フィルタの追加も必要になります）。 加えて、派生テーブルの定義方法にも制約があります。SQL ベースで定義する場合、必ず標準の sql パラメータを使用する必要があります。複雑なカスタム DDL ステートメント（ sql_create など）を利用すると、Looker が正確な増分作成に必要なコマンドを判別できなくなり、構築に失敗してしまうためです。 また、制約として、接続先のデータベース自体が増分更新に必要な操作に対応している（行の削除や挿入を行う DDL コマンドをサポートしている）必要があります。これらを一つでも満たしていない場合、増分 PDT という機能を利用することができません。 一方、システム的な必須条件ではないものの、実運用において強く求められる推奨条件が存在します。 それは、元のソーステーブルに対して、時間ベースのクエリに向けた最適化（パーティショニングやインデックス、並べ替えキーの付与など）を施しておくことです。 増分 PDT はテーブルを更新するたびに、まずソーステーブルに対してクエリを実行し、増分キーの「最新値」を調べるという仕様になっています。もしソーステーブルが最適化されていないと、この最新値を探し出す処理そのものに膨大な時間とコストがかかってしまいます。つまり、この条件を満たしていなくても増分 PDT を構築すること自体は可能ですが、構築時間を短縮するという本来のメリットが失われ、かえって非効率になってしまうため、事前の最適化が強く推奨されています。 Looker 派生テーブルの選定基準 概要 基本的には、メンテナンス性の高いネイティブ派生テーブルかつ、データベースに負荷をかけない一時的な派生テーブルから構築を始めるのが第一選択です。 その後、クエリの重さに応じて一時的なテーブルを使うか、PDT を使うか検討します。 さらにデータ量が多く再構築コストが高ければ全体の再構築を伴う PDT ではなく、増分 PDT を使用することを判断します。 このように、パフォーマンス要件に合わせて最適な設定を選択するのが、Looker の派生テーブルのベストプラクティスです。 詳細を、以下に記載します。 定義方法の選定基準 派生テーブルのクエリをどのように記述するかによる分類です。基本的にはメンテナンス性の高いネイティブ派生テーブルを第一選択とします。 分類 定義 有用なケース 向いていないケース ネイティブ派生テーブル LookML （Explore やフィールド参照）を使用して定義する派生テーブル 既存の LookML 指標を再利用したい場合。データモデルの読みやすさと理解しやすさ（保守性）を高めたい場合 単一のSQLで完結しない処理やカスタムDDLが必要な場合など、特殊なSQL構文を要するケース SQL ベースの派生テーブル 標準的な SQL クエリを直接記述して定義する派生テーブル LookMLだけでは表現が難しい特殊な処理や複数ステップの処理が必要な場合。SQL Runner でテスト済みのクエリをそのまま流用したい場合 スキーマ変更の影響を受けやすいため、保守性を重視する場合。既存の LookML 指標を参照したい場合 データの保持方法の選定基準 クエリ結果をデータベースに物理的に保存するかどうかの分類です。絶対に不可欠になるまでは一時的な派生テーブルを使用し、パフォーマンス要件に応じて PDT 化を検討するのがベストプラクティスです。 分類 定義 有用なケース 向いていないケース 一時的な派生テーブル リクエストのたびにデータベースで都度クエリが実行され、物理的に保存されない派生テーブル 実行速度が速くデータベースへの負荷が低いクエリの場合。常に最新のデータ状態を反映した結果を得たい場合。データベースが読み取り専用の環境である場合 クエリの実行に長時間を要する重い処理や、頻繁に実行される複雑な事前集計の場合 永続的な派生テーブル（PDT） クエリの結果をデータベースの専用スキーマに実際のテーブルとして書き込み、保持する派生テーブル 大量のデータの事前結合や集計が必要な重い処理を1度だけ計算し、結果を再利用してパフォーマンスを向上させたい場合 パフォーマンス上の問題がなく常に最新のデータが必要な場合。ストレージやリソースコストの消費が許容できない場合 PDT の永続性戦略や増分 PDT の選定基準 PDT を使用する場合、永続性戦略や（再構築のタイミング）や増分 PDT を使用するか否かも選定する必要があります。 分類（戦略・種類） 定義 有用なケース 向いていないケース トリガーベースの戦略 指定したデータグループや時間間隔等に基づき自動的に再構築する戦略 複雑な重い処理で、ユーザーにクエリ完了の待機時間を発生させたくない場合（構築中も古いデータを返すため） ユーザー属性やテンプレートフィルタを使用するクエリ（サポート対象外） 保存期間ベースの戦略 最初にクエリを実行したタイミングで構築され、指定期間保持された後に削除される戦略 常に最新である必要はなく、一定期間結果を保持して再利用できれば十分な場合 期限切れ後にクエリを実行するユーザーに待機時間を発生させたくない場合。増分 PDT を利用したい場合 データベース管理 （マテリアライズドビュー） データベース側のマテリアライズドビュー機能を利用してテーブル更新を管理する戦略 データベース側で新しいデータが検出されるたびに更新されるため、リアルタイムなデータが必要なシナリオ データベース側が非対応な場合。マテリアライズドビューに関する高度な知識がない環境 増分 PDT 全体を再構築するのではなく、新しいデータ（増分）のみを追加して構築する設定 データ量が膨大で、テーブル全体の初期構築や再構築に大きなコストや時間がかかる場合 ソーステーブルの時間ベースの列がクエリ用に最適化（パーティショニング等）されていない場合。保存期間ベースの戦略を採用している場合 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。

G-gen の杉村です。当記事では、Google Cloud を管理・運用していくうえで必須となる 課金レポート の基本的な見方について、またコスト分析と対策を効率的に行うためのテクニックについて解説します。 課金レポートとは 課金レポートの基本 アクセス方法 基本的な見方 グループ化条件とフィルタ サービス単位での表示の限界 SKU とは グループ条件を SKU に設定する 表示対象の絞り込み その他のコスト分析テクニック 料金スパイクの原因を調査 特に料金が発生しているプロジェクトの特定 異常検知（Anomaly Detection） クレジット（割引）を考慮した分析 想定外の Google AI Studio 利用を発見 想定外のリージョン利用を発見 Tips レポート表示のタイムゾーンは PST レポート表示は約1日遅れ コスト予測の表示 カスタマイズしたレポートを保存・共有 BigQuery エクスポート 課金レポートとは Google Cloud の 課金レポート （請求レポートまたは Billing report とも呼称）は、Google Cloud の利用料金を確認したり、詳細な分析をするための画面です。Google Cloud コンソールで提供されています。 参考 : Analyze billing data and cost trends with Reports 課金レポートは 請求先アカウント ごとに表示できます。Google Cloud 再販パートナー経由で Google Cloud を利用している場合、課金レポートが閲覧できるかどうかはパートナーによりますが、例として株式会社 G-gen の顧客の場合、請求先アカウント管理者（ roles/billing.admin ）や閲覧者（ roles/billing.viewer ）の権限を持つことができるため、課金レポートを閲覧できます。請求先アカウントの概念については、以下の記事を参照してください。 参考 : Google Cloudの請求の仕組みを徹底解説！ - G-gen Tech Blog 課金レポート レポート画面では、期間の指定、サービスのフィルタリング、コストのグルーピングなどが自由に行えます。しかし、各種フィルタの使い方を理解しなければ「どのリソースがコスト高の原因なのか」を正確に突き止めることはできません。 当記事では、課金レポートの基本的な見方と、フィルタやグループ条件を使いこなして課金の状況を深掘りするコツを紹介します。 なお、当記事内の手順やスクリーンショットは、記事を執筆した2026年4月現在のものです。 課金レポートの基本 アクセス方法 課金レポートへアクセスする手順は、以下のとおりです。 Google Cloud コンソール（ https://console.cloud.google.com/ ）にログイン 検索ボックスに「レポート」と入力 サジェストされた「レポート / プロダクト ページ・課金」をクリック プルダウンリストから請求先アカウントを選択 「レポートページに移動」ボタンをクリック サジェストされた「レポート / プロダクト ページ・課金」をクリック 手順 4. で目当ての請求先アカウントを選択するには、該当の請求先アカウントに対して少なくとも「請求先アカウント閲覧者（ roles/billing.viewer ）」ロールが必要です。権限が不足している場合、プルダウンリストの中に請求先アカウントが表示されません。 プルダウンリストから請求先アカウントを選択してレポートに移動 ロールを付与するには、該当の請求先アカウントに「請求先アカウント管理者（ roles/billing.admin ）」ロールを持っている人に依頼をして、ロールを付与してもらう必要があります。 なお、もし請求先アカウントの ID（ 01230A-12A3B4-AB123C のようにハイフンで区切られた英数字）が分かっている場合、以下の形式の URL に接続することで、課金レポートにクイックにアクセスできます。 https://console.cloud.google.com/billing/01230A-12A3B4-AB123C/reports この場合でも、権限が不足している場合は、エラーメッセージが表示されます。 基本的な見方 課金レポート画面にアクセスすると、初期状態では、当月の1日から現在までの課金状況が表示されます。グラフの上部には各種フィルタパネルが表示されており、グルーピングの方法や、対象サービスや SKU のフィルタリング、表示対象の期間などをコントロールできます。これらのフィルタパネルを駆使して、コスト分析を進めることになります。 課金レポート 表示されている料金は、請求先アカウントに紐づくすべての Google Cloud プロジェクトの合算値です。棒グラフは、初期状態だとサービス（BigQuery、Cloud Storage、Compute Engine、Vertex AI など）ごとに色分けされており、その内訳は棒グラフの下部に表形式で表示されます。 初期状態では「サービス」でグルーピングされている なお、該当の請求先アカウントに紐づく Google Cloud プロジェクトの一覧は、左部ペインの最下部の「アカウント管理」を押下することで確認できます。この画面の右ペインでは、この請求先アカウントにロールを紐づけられているプリンシパル（アカウント、グループ等）の一覧を確認できるほか、ロールの追加も可能です。 プロジェクトの一覧。右ペインでは請求先アカウントのロールを管理可能 グループ化条件とフィルタ サービス単位での表示の限界 課金レポート画面にアクセスすると、初期状態では、「グループ条件」フィルタで「サービス」が選択されています。「サービス」単位の表示では、BigQuery、Cloud Storage、Compute Engine といったサービスごとの合計金額が表示されます。 この表示方法では、各サービス内で「なぜ」課金が発生しているのかを理解することができません。 例えば BigQuery の料金を節約したいと考えたとき、スキャン量に対する課金が多いのか、あるいはストレージ料金が多いのかを区別しなければ、適切な対策を打つことができません。 例えば以下のスクリーンショットでは、「Networking」「Compute Engine」「Vertex AI」で特に課金が大きいことは分かりますが、「何に使っているのか」「誰が使っているのか」はわからない状態です。 この表示方法では情報が足りない SKU とは 「何に使っているのか」を理解するのに重要になるのが、 SKU （Stock Keeping Unit）単位での表示です。SKU とは、Google Cloud における課金単位です。 例えば BigQuery であれば、以下のような SKU があります。 SKU name SKU ID 説明 Analysis (asia-northeast1) 82D5-BCCE-5431 東京リージョンにおけるオンデマンドクエリのスキャン料金 Active Logical Storage (asia-northeast1) 709C-E503-30BF 東京リージョンにおけるアクティブなストレージ料金 レポートを SKU 単位で表示することで、コスト削減に向けた具体的な打ち手を検討できるようになります。 参考 : SKU Groups - BigQuery 参考 : SKU Groups グループ条件を SKU に設定する 左上の「グループ化」フィルタで「SKU」を選択すると、グラフの凡例が SKU ごとに細分化されます。 以下のスクリーンショットの例では、「Networking」という大まかな分類で示されていた内訳が、SKU 単位で表示されるようになったことで、「Cloud Load Balancing」と「Cloud Armor ポリシー」の課金であることがわかるようになりました。 SKU にグループ化条件を変更すると内訳が詳細化する なお、グループ条件には SKU のほかにも以下のような項目が指定可能です（一部抜粋）。 プロジェクト : プロジェクトごとのコストを表示 プロジェクト階層 : 組織、フォルダ、プロジェクトの構造に基づいた表示 ロケーション : リージョンやマルチリージョンごとのコストを表示 ラベル : リソースに付与したラベルのキーごとのコストを表示 表示対象の絞り込み フィルタを設定することで、特定の SKU だけを表示対象として絞り込むことができます。 先程のスクリーンショットの続きの作業として、特に課金が大きかった「Cloud Load Balancer Forwarding Rule Minimum Global」という SKU が、どのプロジェクトで発生しているのかを調査してみます。上部の「SKU」フィルタで「Cloud Load Balancer Forwarding Rule Minimum Global」のみを選択し、他は表示対象外とします。これで、この SKU に関する課金だけがレポートに表示されるようになります。次に、「グループ化」フィルタで「プロジェクト」を選択します。特定の SKU だけに絞られた表示が、プロジェクトごとにグルーピングされるようになりました。 特定の SKU の課金がどのプロジェクトで発生しているか判明 該当のプロジェクトの管理者を特定することで「誰が使っているのか」が判明します。管理者に SKU 情報などを連絡することで、検証用の Cloud Load Balancer の削除などの対策を打つことができます。 このように、グループ条件（切り口）とフィルタ（絞り込み）を交互に切り替えることで、課金データの中からボトルネックを特定できます。次に、その他のコスト分析テクニックの例をいくつか挙げます。 その他のコスト分析テクニック 料金スパイクの原因を調査 ある月で、Google Cloud 利用料金が意図せず高額になった（スパイクした）とします。以下のようにしてスパイクした SKU を特定し、さらにその SKU の課金が発生したプロジェクトを特定します。これは、当記事内の前述の例で示したものと同じ手法です。 グループ条件を「SKU」に変更 特に料金のかかっている SKU を特定 「SKU」フィルタで、特定した SKU だけに表示を絞り込む グループ条件を「プロジェクト」に変更 特にその SKU が多く発生しているプロジェクトを特定 該当プロジェクトの担当者と連携して、技術的に原因を調査 課金レポートを開いてすぐは、デフォルトでグルーピングが「サービス」になっており、スパイクの原因を直接的に特定しづらい状態です。まずはグループ条件を SKU にして、発生した課金の正体を特定することが重要です。 特に料金が発生しているプロジェクトの特定 組織全体で同じ請求先アカウントを使っているようなケースで、組織のクラウド管理者や情報システム部門が、特に料金が高いプロジェクトを特定して、担当者に改善を促すようなケースでは、以下の手順が参考になります。 グループ条件を「プロジェクト」に変更 特に料金のかかっているプロジェクトを特定 「プロジェクト」フィルタで、特定したプロジェクトだけに表示を絞り込む グループ条件を「SKU」に変更 これにより該当プロジェクトで特に料金が高い SKU を特定 該当プロジェクトの担当者に、情報提供しつつ対策を指示 先に紹介した例だと、まず SKU を絞ってからプロジェクトでグルーピングしていますが、この例では順序が逆です。SKU（課金の要素、原因）に先に注目するか、プロジェクト（誰が課金を発生させているか）に先に注目するかの違いです。 異常検知（Anomaly Detection） Google Cloud の請求先アカウントには、過去の利用傾向から逸脱した課金が発生した際に自動で検知する 異常検知（Anomaly Detection） 機能が備わっています。 意図しない設定ミスや、想定外のトラフィック急増などによるコストスパイクを早期に発見するために有効です。異常が検知されると、詳細画面から「どのサービス、どの SKU が原因か」といった根本原因分析（RCA）の結果を確認できます。 参考 : 費用の異常を表示して管理する 参考 : Google Cloud請求先アカウントの異常検知（Anomaly Detection）を解説 - G-gen Tech Blog クレジット（割引）を考慮した分析 課金レポート上部のフィルタパネルにある「コスト削減」フィルタを使うことで、費用ベースの確約利用割引（CUD）やプロモーション用クレジット、無料枠の適用状況をコントロールできます。 「特定のサービスの利用量そのものが増えているか」を調べたいときはクレジットを除外し、「最終的にいくら支払うのか」を調べたいときはクレジットを含める、といった使い分けができます。 想定外の Google AI Studio 利用を発見 以下の記事では、Gemini API の不正利用に警戒する目的から、Google AI Studio（Gemini API）の使用有無を、課金レポートを使って特定する手順を紹介しています。 blog.g-gen.co.jp 想定外のリージョン利用を発見 セキュリティガバナンスやデータ主権の観点から、利用リージョンを制限している場合に役立つテクニックです。意図しないリージョンでのリソース作成は、シャドー IT の発見やコスト最適化のヒントになることが多くあります。 グループ条件を「ロケーション」に設定 リストの中から、利用を許可していないリージョン（例: us-east1 ）が含まれていないか確認 想定外のリージョンがあれば、まず「ロケーション」フィルタで該当のリージョンのみを選択して表示をフィルタリングする 次にグループ条件を「プロジェクト」に変更して、どのプロジェクトで課金が発生しているか特定 Tips レポート表示のタイムゾーンは PST 課金レポートの表示日付のタイムゾーンは PST （太平洋標準時、UTC-8）です。JST（日本標準時、UTC+9）とは マイナス17時間 の時差があります。 例えば、実際に課金が発生したのが日本時間の「2026年5月11日（月）10:00」だとしても、レポート上は「2026年5月10日（日）」の課金として表示されます。以下の記事も参照してください。 blog.g-gen.co.jp レポート表示は約1日遅れ Google Cloud プロジェクトで課金が発生してから、それが課金レポートの表示に反映されるまで、 1日間程度の遅れ があります。 注意が必要なのは、前述のとおりレポート表示のタイムゾーンは PST なので、レポート上で2026年5月11日の課金として表示される課金が実際に発生したのは、日本時間2026年5月11日 17:00 から2026年5月12日 16:59 の間ということになります。そのため、レポートの日付だけに注目すると、以下のスクリーンショットのように1日以上遅れて見えることになります。 レポートを閲覧しているのは5月4日の午前 上記のスクリーンショットのレポートを閲覧しているのは5月4日の午前10時ころです。毎日7,000円以上の課金が発生しているのが通常なのに、まだ5月3日の分が1,000円程度しかレポートに反映されていないところを見ると、一見、5月3日の午前3時ころまでしかレポートが反映されておらず、反映が31時間ほど遅れているように感じます。しかし実際には、レポートのタイムゾーンは PST ですので、5月3日の午前3時（PST）は5月4日の午後8時（JST）です。14時間程度の遅延で済んでいることがわかります。 参考 : Analyze billing data and cost trends with Reports - Why are my usage date costs different than my invoice month costs? Typically, your cost details are available within a day, but can sometimes take more than 24 hours. （通常、料金の詳細は1日以内に確認できるようになりますが、場合によっては24時間以上かかることもあります。） コスト予測の表示 期間フィルタで指定する期間に将来の日付が含まれていると、過去の利用傾向に基づいた機械学習による予測値が、グラフ上に薄いグレーの棒として表示されます。予算超過の兆候を早めに察知するために便利です。 カスタマイズしたレポートを保存・共有 フィルタやグループ条件を細かく設定したレポートは、他人に共有できます。レポート上部の「共有」ボタンを押下すると、フィルタの設定情報を含んだ共有用 URL が発行されます。 また、レポートは「保存済みレポート」として名前を付けて保存することもできます。 BigQuery エクスポート 課金データを BigQuery へエクスポートすることで、SQL で詳細な分析を行ったり、データポータル（英名 Data Studio、旧称 Looker Studio）でオリジナルのコスト可視化ダッシュボードを作成できます。 参考 : Cloud Billing データを BigQuery にエクスポートする BigQuery エクスポートを初めて有効にすると、前月の1日の課金データまで遡って BigQuery にエクスポートされます。最初のデータのエクスポートが完了するまで5日ほどかかりますが、それ以降は1日1回、課金データがエクスポートされます。前月の1日以前のデータをエクスポートすることはできません。 参考 : BigQuery 内の Cloud Billing データテーブルについて - データの可用性 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では、Google Cloud の AI エージェント開発プラットフォームである Gemini Enterprise Agent Platform の概要を解説します。 Gemini Enterprise Agent Platform とは Studio 概要 Agent Studio Agents - Build 概要 Agent Garden（プレビュー） Agent Development Kit MCP サーバー RAG Engine（プレビュー） Vector Search Agent Search Agents - Scale 概要 Agent Runtime セッション メモリバンク Code Execution Agents - Govern 概要 Agent Registry（プレビュー） ポリシー（プレビュー） Agent Gateway（プレビュー） セキュリティ Agents - Optimize 概要 オブザーバビリティ（プレビュー） エージェントの評価（プレビュー） Example Store（プレビュー） Models 概要 Model Garden 使用オプション モデルのチューニング Gen AI Evaluation Service Model Registry エンドポイント バッチ推論 Models - その他のサービス 概要 データセット Feature Store トレーニング Experiments ML メタデータ Pipelines モデルモニタリング Notebooks 概要 Colab Enterprise Agent Platform Workbench Gemini Enterprise Agent Platform とは 2026年4月に開催された Google Cloud Next '26 で、AI エージェントを構築・運用するための統合プラットフォームとして Gemini Enterprise Agent Platform （旧称 : Vertex AI、以下 Agent Platform と記載）が発表されました。 Agent Platform は、これまで Vertex AI が提供してきた機械学習基盤を組み込みつつ、エージェント中心のコンポーネントを新たに統合したサービスです。 Agent Platform はエージェントのライフサイクルを Build 、 Scale 、 Govern 、 Optimize の4領域で整理し、それらを横断する開発環境として Studio 、モデル基盤として Models 、開発作業環境として Notebooks を提供します。 当記事では、Agent Platform を構成する各コンポーネントを概要レベルで紹介します。記事内のカテゴリは、基本的には2026年5月現在の Google Cloud コンソールで選択できる項目に対応しています。また2026年5月現在、 asia-northeast1 （東京リージョン）においてプレビュー提供となっているコンポーネントについては、見出しに（プレビュー）と付記しています。 カテゴリ コンポーネント 概要 Studio Agent Studio エージェント開発の作業を一元化したコラボレーションワークスペース Agents - Build Agent Garden 事前構築済みエージェントサンプルを提供する厳選ライブラリ Agents - Build Agent Development Kit エージェントの構築・デバッグ・デプロイ用のオープンソースフレームワーク Agents - Build MCP サーバー Google Cloud サービスをリモート MCP 経由で AI アプリに接続する仕組み Agents - Build RAG Engine 検索拡張生成（RAG）を容易にするデータフレームワーク Agents - Build Vector Search ScaNN を基盤とするセマンティック検索エンジン Agents - Build Agent Search Google 品質のセマンティック検索と生成 AI を組み合わせた検索基盤 Agents - Scale Agent Runtime エージェントを HTTP サーバーとしてホストするマネージドランタイム Agents - Scale セッション ユーザーとエージェント間のやり取り履歴を保持する機能 Agents - Scale メモリバンク エージェントとの会話に基づいて長期記憶を動的に生成・管理するマネージドサービス Agents - Scale Code Execution エージェントが生成したコードを隔離サンドボックスで安全に実行する機能 Agents - Govern Agent Registry エージェント・MCP サーバー・エンドポイントを管理する統合カタログ Agents - Govern ポリシー Agent Gateway が用いる IAM 許可ポリシーとセマンティック ガバナンス ポリシーの総称 Agents - Govern Agent Gateway エージェントインタラクションを保護・管理するネットワーキング基盤 Agents - Govern セキュリティ デプロイ済みエージェントを継続監視し検出結果を確認する機能 Agents - Optimize オブザーバビリティ エージェントと MCP サーバーのパフォーマンス・健全性監視 Agents - Optimize エージェントの評価 エージェントのパフォーマンス・安全性・品質を測定する評価機能 Agents - Optimize Example Store Few-shot サンプルを保存・動的に取得するマネージドサービス Models Model Garden Google・パートナー・OSS の各モデルを横断的に扱うモデルライブラリ Models 使用オプション 生成 AI モデルの5種類の課金・提供方式の体系 Models モデルのチューニング Gemini をラベル付きデータセットで特定タスクに適応させる機能 Models Gen AI Evaluation Service 生成 AI モデルを客観的・データドリブンに評価するツール Models Model Registry ML モデルのライフサイクルを管理する中央リポジトリ Models エンドポイント オンライン推論用にモデルを関連付ける物理リソース Models バッチ推論 大規模データ向け非同期・高スループット・低コストの推論サービス Models - その他のサービス データセット AutoML やカスタムモデル用ソースデータの一元管理サービス Models - その他のサービス Feature Store 機械学習で使う特徴量を一元管理する特徴管理サービス Models - その他のサービス トレーニング 独自 ML モデルを学習させる機能群（AutoML / カスタムトレーニング / Ray on Agent Platform） Models - その他のサービス Experiments モデル開発のプロセスを追跡・比較・分析する実験管理ツール Models - その他のサービス ML メタデータ ML システムが生成するメタデータとアーティファクトの記録管理サービス Models - その他のサービス Pipelines ML ワークフローをサーバーレスでオーケストレーションするマネージドサービス Models - その他のサービス モデルモニタリング 本番環境のモデル品質劣化を検出・追跡するモニタリングサービス Notebooks Colab Enterprise チーム利用に最適化されたマネージド Jupyter ノートブック環境 Notebooks Agent Platform Workbench VM インスタンス上で動作するカスタマイズ性の高い JupyterLab 環境 参考 : Agent Platform の概要 参考 : Introducing Gemini Enterprise Agent Platform, powering the next wave of agents Studio 概要 このカテゴリでは、Build / Scale / Govern / Optimize の各ライフサイクルを横断する開発環境である Agent Studio が提供されています。モデル探索からシステム指示の改良、プロンプト最適化、Web アプリケーションとしてのデプロイまでを一元的に行える開発フロントエンドとして位置づけられています。 Agent Studio Agent Studio は、エージェント開発に必要な作業を一元化した、Google Cloud コンソール内のコラボレーションワークスペースです。コードの編集とプレビューを並行して行える「インタラクティブキャンバスビュー」を備え、自然言語での対話を起点にプロンプトとシステム指示を組み立てていきます。 モデルの探索においては、後述の Model Garden を経由して候補となるモデルを選び、同じ入力に対する挙動を Agent Studio 上で並列に比較できます。システム指示も Agent Studio に自動生成させたうえで、複数バージョンを並べて結果を見比べることで素早く改良できます。 チャットインターフェースを用いたモデルの挙動比較 外部知識の取り込みも幅広く、Google 検索 / Google マップによるリアルタイムグラウンディングのほか、後述の RAG Engine や Agent Search、Elasticsearch などを介して自社データを参照させられます。あわせて、思考レベル、構造化出力、安全フィルタといったモデル挙動の細かな制御もコンソールから調整できます。 仕上げたプロンプトはそのまま Web アプリケーションとして本番環境にデプロイでき、Google Cloud エコシステム全体と統合された API・デプロイ経路を経由してエージェントを公開することができます。 参考 : Agent Studio の概要 Agents - Build 概要 このカテゴリでは、エージェント本体とその周辺機能を構築するためのコンポーネント群を扱います。事前構築済みのエージェントサンプルを提供する Agent Garden 、エージェントのオープンソースフレームワークである Agent Development Kit 、Google Cloud サービスへの接続口となる MCP サーバー 、エージェントの知識基盤となる RAG Engine / Vector Search / Agent Search が含まれ、エージェントのロジックとデータソースの両方をカバーします。 Agent Garden（プレビュー） Agent Garden は事前構築済みのエージェントのサンプルを提供するライブラリです。2026年5月現在はプレビュー提供となっています。 サンプルエージェントは RAG Engine、ベクトル検索、Gemini モデルなど他のコンポーネントとシームレスに連携できるように構成されており、ドキュメントに基づくカスタマーサポートや業種特化の調査統合といった、特定タスクに合わせた素早い立ち上げを支援します。 また、GitHub に公開されているサンプルエージェントのソースコードにアクセスし、ロジックを独自にカスタマイズすることもできます。 Agent Garden では多数のサンプルエージェントが提供される Agent Garden からサンプルエージェントをデプロイする 参考 : Agent Garden Agent Development Kit Agent Development Kit （以下、ADK）は、オープンソースの AI エージェント開発用フレームワークであり、エンタープライズ規模の信頼性の高いエージェントの構築・デバッグ・デプロイを容易にします。 単純なタスクを処理するエージェントから、複数のエージェントが協働して複雑なタスクを処理するマルチエージェントシステムまで、柔軟に設計・実装できます。 開発したエージェントは、後述の Agent Runtime や Vertex AI、Cloud Run、Google Kubernetes Engine（以下、GKE）など、マネージドな実行環境にデプロイすることができます。 参考 : Agent Development Kit ADK を使用したエージェントの開発、ユースケースについては、以下の記事カテゴリで取り上げています。 blog.g-gen.co.jp MCP サーバー Google Cloud MCP servers は、Google および Google Cloud が提供するフルマネージドのリモート MCP サーバーです。 Google および Google Cloud の各サービスを、エンタープライズレベルのガバナンス・セキュリティ・アクセス制御を備えたリモート MCP サーバー経由で利用することができます。IAM でユーザーアクセスを制御し、専用の HTTP エンドポイントを通じて Gemini CLI などの AI クライアントからすぐに使い始めることができます。 リモート MCP サーバーは Google が管理するインフラストラクチャ上で動作するため、ユーザーによる運用管理は不要です。また、Apigee や Cloud Run を使用することで、独自に実装した MCP サーバーを公開することもできます。 参考 : Google Cloud MCP servers overview Google Cloud が提供するリモート MCP サーバーについては、以下の記事で解説しています。 blog.g-gen.co.jp RAG Engine（プレビュー） RAG Engine は、検索拡張生成（Retrieval-Augmented Generation、以下 RAG）を容易にするためのコンポーネントです。2026年5月現在はプレビュー提供となっています。 ローカルファイル、Cloud Storage、Google Drive など複数のデータソースから取り込んだデータを、変換・インデックス化のパイプラインを通じて コーパス （検索用に最適化されたデータのインデックス）として整備します。エージェントの応答生成時にコーパスを検索して LLM のコンテキストに独自のデータを加えることで、ハルシネーションを抑制します。 コーパスは検索対象のデータの論理的な単位であり、データの実体が保存されるベクトルデータベースが別途必要となります。ベクトルデータベースのインフラは2つのモードから選択することができ、インフラ管理を完全に抽象化した サーバーレスモード と、専用の Cloud Spanner インスタンスを使用し、高いカスタマイズ性を実現できる Spanner モード が存在します。 RAG Engine は、2026年5月現在 us-central1 などいくつかのリージョンでは GA となっていますが、 asia-northeast1 を含む多数のリージョンではプレビュー提供となっています。最新のリリース状況については以下のドキュメントを参照してください。 参考 : Gemini Enterprise Agent Platform RAG Engine の概要 Vector Search Vector Search は、Google Research が開発した ScaNN アルゴリズムを基盤とするセマンティック検索エンジンで、Google 検索、YouTube、Google Play と同じ技術スタックを利用したエンタープライズ向けのベクトル検索基盤を利用できます。 ユーザー側で用意した埋め込みベクトルを Cloud Storage に保存し、それを元にインデックスを作成します。作成したインデックスはエンドポイントとしてデプロイすることで、アプリケーションからエンドポイント経由でベクトル検索を使用することができます。 検索方式は、意味の近さで探す 高密度エンベディング検索 、キーワード一致を重視する スパースエンベディング検索 、両者を組み合わせた ハイブリッド検索 の3方式に対応しています。 参考 : ベクトル検索 Agent Search Agent Search （旧称 : Vertex AI Search）は、前述の Vector Search 同様、Google 品質のセマンティック検索（意味論検索）機能をフルマネージドで利用できるコンポーネントです。過去には Generative AI App Builder、Vertex AI Search and Conversation、Vertex AI Agent Builder、AI Applications など複数のブランド名を経てきた経緯があります。 Vector Search が埋め込みベクトルの類似検索エンジンに特化しているのに対し、Agent Search はドキュメントの取り込み・パース・自然言語理解・要約までを内包したフルマネージドの検索ソリューションとなっており、 検索 と レコメンデーション を2本柱の主軸機能として提供します。 データソースとして Cloud Storage や BigQuery に保存した構造化・非構造化データのほか、一般公開ウェブサイトのデータもインデックスとして登録できます。自然言語クエリによる検索とレコメンデーションに加えて、検索結果の要約生成やフォローアップ質問を踏まえたマルチターンの回答生成といった LLM 機能も内蔵しており、外部 LLM のグラウンディングソースとしても利用できます。 汎用のカスタム検索のほかに、映画・動画・音楽向けの メディア検索 や、FHIR 形式の医療データ向けの ヘルスケア検索 といった業種特化ソリューションも提供されています。 参考 : Agent Search の概要 Agent Search の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp Agents - Scale 概要 このカテゴリでは、構築したエージェントを本番ワークロードとして提供するための実行基盤群を扱います。エージェントをマネージドにホストする Agent Runtime 、ユーザーとエージェント間のやり取りを保持する セッション 、会話に基づいて長期記憶を生成・管理する メモリバンク 、生成コードを隔離されたサンドボックスで実行する Code Execution が組み合わさり、ステートを伴うエージェントの安定運用を支えます。 Agent Runtime Agent Runtime （旧称 : Agent Engine）は、開発した AI エージェントをリモートからアクセス可能な HTTP サーバーとしてホストするフルマネージドの実行基盤です。 ADK をはじめ、LangChain や LangGraph といった様々なエージェントフレームワークのデプロイを容易にするテンプレートが提供されており、テンプレートに適合しない場合でもカスタムエージェントとして構築できます。ただし、2026年5月現在、Agent Runtime にデプロイできるエージェントは Python で開発されたもののみとなっています。 自動スケーリング機能、モニタリング、ロギングなど、エージェントの運用に必要な機能を組み込みで利用することができるほか、後述のセッションやメモリバンクと連携して記憶や履歴を伴うマルチターンのエージェントの会話を容易に実現できます。 参考 : エージェントをデプロイする Agent Runtime の詳細については以下の記事もご一読ください。 blog.g-gen.co.jp セッション セッション （Sessions）は、ユーザーとエージェント間のやり取りの履歴を保持し、エージェントが会話のコンテキストを参照するための機能です。 セッションは「ユーザーとエージェントシステム間の一つの会話の流れにおけるメッセージとアクション（イベント）の時系列」と定義され、イベントには会話の内容のほか関数呼び出しなどエージェントが実行したアクションが保存されます。 コアコンセプトとして、現在の会話中のみに関連する一時データを表す「状態」と、特定のユーザーの複数のセッションでアクセスできるパーソナライズされた情報を表す「記憶」が分離されている点が特徴です。記憶の保存・参照が必要な場合は後述のメモリバンクを使用します。 単一セッション内の会話の状態を管理する ADK で開発したエージェントを Agent Runtime にデプロイした場合、セッション管理はデフォルトで使用されます。その他のフレームワークで開発したエージェントの場合は、API を使用してセッション管理を行うことができます。 参考 : Agent Platform セッションの概要 メモリバンク メモリバンク （Memory Bank）は、ユーザーとエージェントの会話に基づいて長期記憶を動的に生成・管理するマネージドサービスです。 メモリバンクは内部的に LLM を用いて、セッションのイベント（会話履歴）からユーザーの嗜好や事実を抽出・要約し、ユーザー単位で保存します。これにより、エージェントとの会話（セッション）を一度中断しても、後の会話でユーザーごとにパーソナライズされた応答を返すことができるエージェントを構築できます。 不変のドキュメントを根拠とする RAG とは異なり、メモリバンクはユーザーごとに進化していく動的なコンテキストを扱う点が特徴です。 セッションとメモリバンクは独立した機能ですが、併用できます。セッションが単一会話内の状態（短期記憶）を、メモリバンクが複数セッションを跨ぐ長期記憶を担うため、両者を組み合わせることで、会話中の文脈維持と、過去の会話を踏まえたパーソナライズを両立できます。 メモリバンクを使用してユーザーごとの記憶を生成・管理する ADK では組み込みの機能として VertexAiMemoryBankService が提供されており、エージェントのツールおよびコールバックとして組み込むだけでメモリバンクとの連携を実現できます。その他のフレームワークで開発したエージェントの場合、セッション同様に API が提供されています。 参考 : Agent Platform メモリバンク 以下の記事では、ADK で開発したエージェントを Agent Runtime で実行する際にメモリバンクを利用する方法を解説しています。 blog.g-gen.co.jp Code Execution Code Execution は、エージェントが生成したコードを、エージェント本体とは隔離された安全なマネージドサンドボックス上で実行できる機能です。2026年5月現在は us-central1 リージョンに限定したプレビュー提供となっています。 LLM が苦手な厳密な数値計算・データ処理・可視化などをコード実行で補強する用途に向き、財務計算やデータサイエンスワークフロー、ユーザー入力由来の信頼できないコードの隔離実行といったユースケースで利用されます。サンドボックスはファイルシステムが制限され外部ネットワークへのアクセスも遮断されているうえ、VPC Service Controls にも対応しているため、エンタープライズのセキュリティ要件下でも安全にコード実行を組み込めます。 なお、公式ドキュメントのページによっては Agent Sandbox と記載されている場合があり、今後この名称に変更される可能性があります。 参考 : Code Execution Agents - Govern 概要 このカテゴリでは、エージェントの動作と通信を統制するためのガバナンスコンポーネント群を扱います。MCP サーバー / ツール / エージェントを一元管理する Agent Registry 、認証・認可と自然言語ベースの統制を担う ポリシー 、ネットワーク境界を保護する Agent Gateway 、Security Command Center 連携でリスクを可視化する セキュリティ機能 、プロンプトとレスポンスを検査する Model Armor で構成されます。 Agent Registry（プレビュー） Agent Registry は、Google Cloud 内のエージェント、MCP サーバー、エンドポイントを保存・検出・管理できる、一元化された統合カタログです。2026年5月現在はプレビュー提供となっています。 Agent Registry が備える主要機能は以下のとおりです。 機能 説明 カタログ機能 エージェント、MCP サーバー、エンドポイントを登録する 検索 / 検出機能 レジストリへのクエリで利用可能な機能を特定する メタデータ管理機能 エージェントの「スキル」や MCP サーバーの「ツール」を抽出する Agent Registry では、エージェント（ Agent ）、MCP サーバー（ McpServer ）、エンドポイント（ Endpoint ）の3種類を サービス （ Service ）としてカタログに登録します。Agent Runtime にデプロイしたエージェントや、Google Cloud が公式で提供するエージェント、MCP サーバーなどは自動で登録され、外部リソースや A2A プロトコルを実装していないエージェントなど、自動検出がサポートされていないものは手動で登録できます。 サービスの種類 説明 エージェント ユーザーが開発、もしくは Google Cloud が提供する自律的な AI エージェント MCP サーバー ユーザーが開発、もしくは Google Cloud やサードパーティが提供する MCP サーバー エンドポイント エージェントがアクセスする外部ターゲット URL を管理可能なリソースとして抽象化したもの 登録されているエージェントと他のサービス（エージェント、MCP サーバー、エンドポイント）との間で バインディング （ binding ）を確立することで、エージェントから他サービスへの呼び出し関係をカタログ上にマッピングできます。サービスの利用に認証が必要な場合は、エージェントと認証プロバイダとのバインディングを作成し、認証情報を委任することができます。なお、呼び出しの実際の可否は後述の Agent Gateway と IAM 許可ポリシーで制御されるため、バインディング自体はアクセス制御の主体ではない点に注意してください。 このように、サービスを1つのカタログで一元管理することで、AI ワークロードでありがちな「ツールアクセスの断片化」「データの分離」「冗長なサービス」といった課題を解決します。A2A や MCP といったオープンプロトコルと密接に連携することで、既存スキルやツールの再利用、統合の簡素化を実現しています。 参考 : Agent Registry の概要 参考 : バインディングを管理する ポリシー（プレビュー） ポリシー （Policies）は、後述の Agent Gateway がエージェントと他のサービス間の通信を安全に管理するために用いる、 IAM 許可ポリシー と セマンティック ガバナンス ポリシー の総称です。2026年5月現在は非公開プレビュー（Private Preview）となっています。 IAM 許可ポリシーは IAM ベースの静的な権限管理で、Identity-Aware Proxy（以下、IAP）を用いた認証と認可を実現します。Agent Registry の各サービスに「読み取り専用」、「破壊的変更の許可」といった条件を指定したポリシーを紐づけることで、エージェントがサービスを介して行える操作を制限します。 セマンティック ガバナンス ポリシーは、エージェントのプロンプトや MCP ツール呼び出しの「内容」を監視・制御するための制約であり、エージェントの振る舞いがユーザーの意図と組織の制約の両方に適合するように制御します。Agent Gateway は実行時に各エージェントのプロンプトとツール呼び出しの内容を分析し、制約に基づいてアクションを決定します。 参考 : ポリシーの概要 参考 : セマンティック ガバナンス ポリシーを構成する 参考 : セマンティック ガバナンス ポリシーを構成する - セマンティック ガバナンスの例 Agent Gateway（プレビュー） Agent Gateway はユーザーとエージェント、エージェントとツール、エージェント同士など、すべてのエージェントインタラクションを保護・管理するネットワークコンポーネントです。2026年5月現在は非公開プレビュー（Private Preview）で、利用にはアクセス申請が必要です。 Agent Gateway は Client-to-Agent （クライアントからエージェントへの内向き）と Agent-to-Anywhere （エージェントから任意の宛先への外向き）という2つのモードで動作します。 動作モード 説明 Client-to-Agent（内向き） Agent Gateway がエージェントのフロントエンドとして機能し、クライアント（Gemini CLI、Claude Code など）と Google Cloud 上で実行されているエージェント（およびツール）間の通信を保護する Agent-to-Anywhere（外向き） Google Cloud 上で実行されているエージェントと、任意の場所で実行されているエージェント、ツール、API などの外部サービスとの間の双方向の通信を保護する この2種類の通信に対して、先述の IAM 許可ポリシー、セマンティック ガバナンス ポリシーを適用することで、一元的なアクセス制御を実現します。また、Agent Gateway を経由するプロンプトとレスポンスは後述の Model Armor で検査・サニタイズでき、プロンプトインジェクションや機密情報の漏洩といったリスクを一元的に低減できます。 Agent Gateway はネットワークレイヤですべてのエージェントインタラクションのテレメトリを生成し、Cloud Logging や Cloud Trace に連携できるため、後述のオブザーバビリティ機能と組み合わせてセキュリティ調査やパフォーマンス分析を行えます。 Agent Gateway の動作モードのイメージ Agent Gateway を利用するには、対象のエージェントを Agent Registry に登録しておく必要があります。Agent Runtime と Gemini Enterprise のトラフィックは自動的に Agent Gateway 経由でルーティングされる一方、それ以外のデプロイ先（Cloud Run や GKE など）からのトラフィックを Agent Gateway 経由とする手順は2026年5月現在の公式ドキュメントには明示されていません。そのため現時点では、Agent Runtime と Gemini Enterprise が主な利用対象となります。 参考 : Agent Gateway の概要 参考 : ゲートウェイで Model Armor を構成する セキュリティ Agent Platform の セキュリティ タブでは、デプロイ済みの AI エージェントを継続的に監視し、セキュリティ検出結果（findings）を確認できます。 Security Command Center（Premium / Enterprise）との連携により、AI Protection、エージェントの脆弱性評価、センシティブデータの検出、AI Discovery、攻撃パスシミュレーションといったセキュリティ監視・分析を行うことができます。 セキュリティタブには、Security Command Center の検出結果を集約した総合リスク指標、コンプライアンスステータス、アクティブな脅威数が表示されます。 また、重大度別の AI リスク（脆弱性、構成ミス、有害な組み合わせ）、AI 脅威（異常な IAM 権限付与、マルウェア、ラテラルムーブメント）、過剰な権限を持つエージェント、業界セキュリティ基準への適合状況、コンテンツ違反などをウィジェット形式で確認できます。 参考 : セキュリティに関する検出結果を表示する Agents - Optimize 概要 このカテゴリでは、デプロイ済みエージェントの品質と動作を継続的に改善するためのコンポーネント群を扱います。実行のパフォーマンスや健全性、トポロジを可視化する オブザーバビリティ 、エージェントのパフォーマンス・安全性・品質を測定する エージェントの評価 、Few-shot サンプルを保存・動的に取得して回答品質を改善する Example Store により、本番運用後のモニタリングと改善サイクルを担います。 オブザーバビリティ（プレビュー） オブザーバビリティ （Observability）では、デプロイされたエージェントと MCP サーバーのパフォーマンス、動作、健全性を包括的に監視・分析できます。2026年5月現在はプレビュー提供となっています。 主要な指標のモニタリング、実行パスのトレース、マルチエージェントシステムのトポロジの可視化によって、問題を診断し、リソース消費を最適化し、エージェントの信頼性を向上させることができます。 これらの分析を行うためには、エージェントから OpenTelemetry 形式でテレメトリーデータを Google Cloud Observability（Cloud Monitoring / Cloud Logging / Cloud Trace）に送信するように構成する必要があります。送信されたテレメトリーデータは、Agent Registry のコンソール上で以下の3種類のシグナルとして確認することができます。 シグナル 主な内容 メトリクス トークン使用量、レイテンシ（p50 / p95 / p99）、エラー率、セッション統計、ハルシネーション率、CPU・メモリ使用量 トレース 実行パス（スパン）、入出力の有向非巡回グラフ、エージェント間呼び出し ログ プロンプト・レスポンス、エラー、フィルタ可能なエージェント生ログ 参考 : オブザーバビリティの概要 エージェントの評価（プレビュー） エージェントの評価 （Agent Evaluation）は、エージェントのパフォーマンス、安全性、品質を測定して改善するための評価機能です。2026年5月現在はプレビュー提供となっています。 エージェントの評価では以下のような機能が利用できます。既存のテストデータがなくても初期評価スイートを構築できる点が特徴です。 機能 説明 シナリオ生成 / ユーザーシミュレーション エージェントのシステム指示とツール定義に基づいて多様なマルチターンの合成テストシナリオを自動生成する 環境シミュレーション ツール呼び出しをインターセプトしてカスタム動作やシミュレートされたエラーを挿入する マルチターン評価 会話履歴全体を自動的に評価する プロンプト最適化 洗練されたシステム指示をプログラムで生成・検証する 評価プロセスは「評価ケース定義 → 評価ケース実行 → トレース生成 → 指標の計算 → 指標の分析 → エージェント最適化」の6つのステップで構成され、ローカル開発でのイテレーションと、デプロイ済みエージェントに対する評価の両シナリオで利用できます。 また、評価指標に対してしきい値を設定し、超過時に自動通知を送る 品質アラート （Quality Alerts）も提供されています。タスクの成功スコアやツール使用品質といった指標を Cloud Monitoring 経由で監視し、しきい値超過時に Slack、メール、Cloud Pub/Sub への通知を発信することで、基盤モデルが変わっていなくても、ユーザーの行動やデータパターンの変化に起因するエージェントの品質低下を早期に検知できます。 参考 : エージェントの評価 参考 : 品質アラートを構成する Example Store（プレビュー） Example Store は、エージェントが LLM に渡すプロンプトに含めるための Few-shot サンプル（少数ショットの例）を保存・動的に取得できるマネージドサービスです。2026年5月現在はプレビュー提供となっています。 LLM に期待する回答パターンを提示することで、類似のクエリに対する応答の品質、精度、整合性を向上させることができます。プロンプトに直接サンプルを書き込む場合と異なり、プロンプトの内容に応じてストアから関連性の高いサンプルだけが動的に取り出されるため、プロンプトサイズや複雑性を抑えながらより多くのユースケースをカバーできます。 ADK で開発したエージェントの場合は、事前に Example Store インスタンスを指定しておくことで、プロンプトの内容に応じてサンプルが自動的に取得され LLM へのリクエストに含められます。それ以外のフレームワークで開発したエージェントの場合は、API を介して手動でサンプルを検索・取得します。 参考 : Example Store の概要 Models 概要 Models は、Agent Platform で生成 AI / ML モデルを取り扱うための基盤コンポーネント群です。これまで Vertex AI として提供されてきた生成 AI / 機械学習関連のサービスが、当カテゴリ配下に集約されています。具体的には、Google・パートナー・OSS のモデルを横断的に発見できる Model Garden 、5種類の課金・提供方式を体系化した 使用オプション 、 Gemini のチューニング 、 Gen AI Evaluation Service による評価 、ML モデルのライフサイクル管理を担う Model Registry 、 オンライン推論用のエンドポイント 、 大規模データ向けのバッチ推論 といった、モデルの選定からサービングまでを担う機能を扱います。 Model Garden Model Garden は、Google、パートナー、OSS が提供するモデルやアセットを探索、テスト、カスタマイズ、デプロイするための AI / ML モデルライブラリです。 2026年5月現在、Model Garden で扱えるモデルのカテゴリごとの詳細と、具体的なモデルの例を以下に示します。 カテゴリ 説明 モデルの例 基盤モデル 事前学習済みのマルチタスク大規模モデル。後述のモデルのチューニング機能や、システム指示・RAG などによるカスタマイズで特定タスクに適応できる Gemini、Anthropic Claude、Mistral、Grok ファインチューニング可能なモデル ノートブックやパイプラインで自前でファインチューニングできるモデル Gemma、Llama、DeepSeek、Qwen タスク固有のソリューション 画像・動画・音楽・音声・翻訳など特定タスク向けの構築済みモデル。多くは独自データでカスタマイズ可能 Imagen、Veo、Lyria、Chirp 後述のモデルのチューニング機能、Gen AI Evaluation Service、エンドポイントといった Agent Platform の他機能と統合されており、モデルの選定から本番サービングまでを一貫したワークフローで扱えます。 また、組織のポリシー（ vertexai.allowedModels 制約）を使用すると、組織・フォルダ・プロジェクト単位で特定のモデルへのアクセスを制御でき、組織で承認したモデルだけを使用させる運用ができます。 参考 : Model Garden の概要 参考 : Model Garden モデルへのアクセスを制御する 使用オプション Agent Platform では、Gemini などの生成 AI モデルを利用する際の課金・提供方式として5種類の 使用オプション が体系化されています。デフォルトでは Standard PayGo が適用されます。各オプションは課金方式、スループット保証の有無、リクエスト処理の優先度といった観点で性質が異なり、ワークロードの特性に応じて使い分けます。 使用オプション 特徴 主な用途 プロビジョンドスループット 1週間〜1年のコミットで容量とスループットを予約。固定料金制で超過料金なし SLA 必須の定常ワークロード チャットボット・エージェントなど一貫したユーザー体験が求められる本番用途 Priority PayGo（プレビュー） Standard PayGo より優先的に処理される従量課金 Standard 以上の信頼性が求められるケース プロビジョンドスループット容量超過分のスピルオーバー先としても使用可能 Standard PayGo 前払い不要の従量課金（デフォルト） トラフィックが変動する日常的な用途 Flex PayGo（プレビュー） Standard PayGo より処理の優先度が低く、割安な従量課金 コスト優先でレイテンシが許容できるユースケース バッチ推論 非同期・高スループットの大量処理 結果が比較的長期で必要な大規模ジョブ プロビジョンドスループットは Gemini や Veo などの Google 製モデルに加えて、一部のパートナーモデル・OSS モデルにも対応しています（対応モデルの詳細は参考ドキュメント参照）。本番ワークロードでは、プロビジョンドスループットでベースラインの容量を確保し、超過分は Priority PayGo で処理する組み合わせも選択できます。 参考 : 使用オプション 参考 : プロビジョンド スループットの概要 参考 : プロビジョンド スループットでサポートされているモデル モデルのチューニング モデルのチューニング 機能は、Gemini モデルをラベル付きデータセットで特定タスクに適応させる、Agent Platform のマネージドチューニング機能です。プロンプト設計だけでは難しい複雑なタスクや、特定のドメイン知識をモデルに獲得させたい場合に利用します。 モデルのチューニングでは、以下の2種類の手法が提供されます。 手法 説明 教師ありファインチューニング ラベル付きの入出力ペアでモデルに目的の動作を模倣させる、最も標準的な手法 プリファレンスチューニング 人間によるフィードバックデータを使って、教師ありファインチューニングだけでは定義しにくい主観的な好みを学習させる手法 運用上のオプション機能として、チューニング途中の状態を保存して複数の状態を比較・選択できる チューニングチェックポイント と、既存のチューニング済みモデルやチェックポイントを起点に追加データで学習を続けられる 継続的チューニング が提供されます。 2026年5月現在、対象モデルは Gemini 2.5 Pro、Gemini 2.5 Flash、Gemini 2.5 Flash-Lite で、チューニング用データセットはテキスト・画像・動画・音声・ドキュメントなど複数モダリティに対応しています。 参考 : チューニング Gen AI Evaluation Service Gen AI Evaluation Service では、生成 AI モデルを客観的・データドリブンに評価するツールが提供されます。モデルの移行やプロンプト最適化などの開発タスクを支援します。 モデルの評価方法として、以下の4つが提供されています。推奨とされている 適応型ルーブリック はソフトウェア開発の単体テストに似た位置づけで、プロンプトごとに pass/fail を判定することで、さまざまなタスクでモデル品質を客観的に評価できます。 評価方法 説明 適応型ルーブリック（推奨） 評価用データセットの各プロンプトごとに評価項目を動的に生成して採点する方式 静的ルーブリック 評価用データセットの全プロンプトに固定の評価基準を適用する方式 計算ベース指標 ROUGE や BLEU などの指標を用いて、参照テキストとの一致度を数値で算出する方式 カスタム関数 Python で独自の評価ロジックを実装する方式 生成 AI モデルだけでなく、エージェントの評価や予測 AI モデルの評価にも対応しており、Google / サードパーティモデルの直接比較、ファインチューニング品質評価、プロンプト最適化、モデルバージョン間の比較といった用途で使われます。 参考 : Gen AI Evaluation Service の概要 Model Registry Model Registry は、ML モデルの整理・バージョン管理・本番デプロイを一元化する中央リポジトリです。 モデルのバージョン管理、後述の エンドポイント へのデプロイや バッチ推論 の実行、モデルの性能評価・パフォーマンス指標の閲覧といった機能を備えます。 対応するモデルタイプは、後述の トレーニング 機能で作成したカスタム学習モデルや AutoML モデル、BigQuery ML モデルです。これらに加えて、外部で学習したモデルについてもアーティファクトを Cloud Storage に配置することでインポートして登録できます（フレームワーク・形式の要件あり）。 参考 : Model Registry の概要 参考 : Model Registry へのモデルのインポート エンドポイント エンドポイント （Endpoint）は、学習済みモデルを用いてオンライン推論を実行するための物理リソースです。モデルをエンドポイントにデプロイすると、推論を実行するマネージド推論ノードがプロビジョニングされ、推論リクエスト用のサービス URL が提供されます。 1つのエンドポイントには複数のモデルやモデルバージョンをデプロイでき、各モデルへのトラフィック比率を指定する トラフィック分割 によって、新旧モデルを段階的に置き換えるローリングデプロイができます。 推論ノードは同時リクエスト数に応じて 自動スケーリング するため、負荷に応じたコスト効率と応答性能を両立できます。 パブリックエンドポイント（共有・専用）、Private Service Connect エンドポイント、プライベートサービスアクセスエンドポイントの3種類があり、ネットワーク要件に合わせて選択できます。 参考 : エンドポイントにモデルをデプロイする バッチ推論 バッチ推論 は、大規模データ処理向けの非同期・高スループット・低コストの推論サービスです。オンライン推論と異なりエンドポイントへのモデルデプロイが不要で、入力データをまとめて投入するだけで実行できます。 入力ソースは Cloud Storage と BigQuery に対応し、リアルタイム応答ではなく非同期処理として動作します。 バッチ推論では、前述の Model Registry に登録したカスタム学習モデル、AutoML モデル、BigQuery ML モデル、インポートモデルに加えて、各種 Gemini モデルが使用できます（対応モデルの詳細は参考ドキュメント参照）。 コンテンツ生成、データ分類・アノテーション、要約・抽出・翻訳といったオフライン分析など、緊急性の低い大規模タスクに最適な選択肢です。 参考 : Gemini を使用したバッチ推論 参考 : カスタム トレーニング済みモデルからバッチ推論を取得する Models - その他のサービス 概要 Models に含まれるその他のサービスとして、生成 AI 系サービスの登場以前から Vertex AI として提供されてきた機械学習サービスが統合されています。 データセット データセット （Datasets、別名 : マネージドデータセット）は、後述の AutoML やカスタムトレーニングで使うソースデータを Agent Platform 上で一元管理する機能です。AutoML モデルの学習では使用が必須となっています。 データの実体は Cloud Storage に保管されます。データセットのメタデータは Knowledge Catalog に統合されており、プロジェクトやリージョンを横断して検索できます。 また、コンソール上でアノテーションセットを作成し、画像データへのラベル付けを行うこともできます。 参考 : Gemini Enterprise Agent Platform でのマネージド データセットの作成の概要 Feature Store Feature Store は、機械学習で使う特徴量（Feature）を一元管理し、トレーニングと推論の両方に提供するための特徴管理サービスです。 ユーザー行動ログなどから集計する特徴量（例 : ユーザーの過去30日の購入回数）は計算コストが高く、推論リクエストごとに作るとレイテンシが破綻します。Feature Store は事前計算した特徴量を保管し、推論時に即座に取り出せるようにする基盤です。トレーニングと推論で同じ特徴量定義を共有できるため、両者で特徴量の中身が食い違う training-serving skew も防げます。 データソースは BigQuery で、Feature Store 自体は BigQuery テーブルを Feature View として登録するだけで、データを物理コピーせずに参照できます。オンライン推論向けには Bigtable をバックエンドとしたオンラインサービングが用意されています。 Knowledge Catalog と連携して特徴メタデータを追跡できるため、トレーニングや再トレーニングでの再利用が容易です。また 特徴モニタリング 機能では、登録済みの特徴データを定期ジョブで監視し、特徴ドリフト（Feature drift）の検出ができます。 参考 : Gemini Enterprise Agent Platform での特徴管理の概要 参考 : Agent Platform Feature Store について トレーニング Agent Platform は、独自の機械学習モデルを学習させる機能群を提供します。学習結果はモデルアーティファクトとして Cloud Storage に保存され、前述の Model Registry に登録できます。 目的とコード制御の必要度に応じて以下の3つの方式から選択できます。 方式 概要 AutoML トレーニング用のコードを書かずに、データ準備・モデル選択・ハイパーパラメータ調整・デプロイまでを全て自動化する方式。表形式（分類・回帰・予測）と画像（分類・物体検出）データに対応 カスタムトレーニング ユーザー自身が書いたトレーニング用のコードを Agent Platform のマネージドインフラ上で実行する方式。任意の ML フレームワークを使用できる Ray on Agent Platform OSS の分散処理フレームワーク Ray を Agent Platform 上でマネージド提供する方式。分散トレーニングや並列処理が必要な ML ワークフローに向く カスタムトレーニングでは、トレーニング用のコードをコンテナイメージとしてパッケージ化して実行します。TensorFlow / PyTorch / scikit-learn など任意の ML フレームワークを使用でき、標準的なフレームワーク向けには事前構築済みコンテナが提供されているほか、特殊な依存関係がある場合は独自のカスタムコンテナを使用することもできます。実行環境の特性に応じて、以下の2つの方式から選択できます。 実行方式 概要 サーバーレストレーニング コードをカスタムジョブとして投入するサーバーレス実行方式。インフラはオンデマンドで起動・解放される トレーニングクラスタ A100 / H100 などの高性能アクセラレータを専用クラスタとして予約してカスタムジョブを実行する方式 Ray on Agent Platform は既存の OSS Ray コードを最小限の変更でそのまま動かせる点が特徴で、BigQuery や前述のエンドポイントといった Google Cloud サービスとシームレスに連携します。 データ処理・評価・デプロイなど複数ステップの本格的な MLOps ワークフローが必要な場合は、後述の Pipelines を使用するのが推奨されます。 参考 : 独自のモデルをトレーニングして使用する 参考 : トレーニング方法を選択する 参考 : Agent Platform での Ray の概要 Experiments Experiments は、機械学習モデル開発のプロセスを追跡・比較・分析するための実験管理ツールです。モデル選択やトレーニングの最適化に役立ちます。 前処理・トレーニングといった手順、入力パラメータやアルゴリズム、出力されたモデルやチェックポイント、評価指標などをまとめて記録できます。複数のモデルや構成をテスト実行（Run）単位でグループ化して比較でき、ハイパーパラメータやアーキテクチャの違いによる性能差を検証できます。 後述の ML メタデータと統合してアーティファクトのリネージを追跡できるほか、TensorBoard との統合により学習過程の時系列指標を可視化できます。 後述の Pipelines と組み合わせれば、パイプライン実行を Experiments の Run として記録でき、構成の異なるパイプラインを Run 単位で横断比較する用途にも使えます。 参考 : Gemini Enterprise Agent Platform Experiments の概要 ML メタデータ ML メタデータ （ML Metadata）は、機械学習システムが生成するメタデータとアーティファクトを記録・管理するサービスです。 データセットや学習済みモデルといったアーティファクト、トレーニングや評価といった実行、それらを束ねるコンテキストをノードとし、ノード間の入出力関係をエッジとして表現するメタデータグラフを保持します。各ノードには、モデルの精度や再現率などのメトリクスやプロパティを Key-Value で付加できます。 「データセット → モデル → 予測結果」のような依存関係をリネージとして追跡できるため、本番 ML システムの実行分析、ハイパーパラメータの効果比較、ワークフロー再実行時の同一条件での再現、監査・ガバナンス対応といった用途で利用されます。 前述の Experiments や後述の Pipelines と密接に連携する基盤となるコンポーネントです。 参考 : Gemini Enterprise Agent Platform ML メタデータの概要 Pipelines Pipelines は、ML ワークフローをサーバーレス実行基盤でオーケストレーションするサービスです。 ML パイプラインは MLOps ワークフローを移植可能・拡張可能な形で記述したもので、複数のパイプラインタスクを有向非巡回グラフ（DAG）の形式で結び、依存関係に従って実行します。 パイプラインの記述には Kubeflow Pipelines または TensorFlow Extended（TFX）の SDK を利用でき、定義 → コンパイル（YAML 生成） → 実行 → モニタリングというライフサイクルで運用します。 前述の ML メタデータと連携してアーティファクトのリネージを追跡できるため、再現性とガバナンスを保ちながらデータ前処理・モデルトレーニング・デプロイを統合的に自動化できます。 継続的な再トレーニングや本番 MLOps の自動化基盤として中核となるコンポーネントです。 参考 : Gemini Enterprise Agent Platform Pipelines の概要 Pipelines の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp モデルモニタリング モデルモニタリング （Model Monitoring）は、本番環境にデプロイされた機械学習モデルの品質劣化を検出・追跡するためのモニタリングサービスです。顧客 LTV 予測のように入力データの分布が時間とともに変わるシナリオで特に有効です。 入力特徴量や推論結果の分布のドリフト、特徴アトリビューション（各特徴量のモデルに対する寄与度）の変化といった観点でモデルの状態を継続的に監視し、これらの指標がしきい値を超えるとアラートを発することができます。 ベースラインとターゲットのデータセットの分布を重ね合わせて可視化できるため、差異を視覚的に把握して再評価や再トレーニングの要否判断に役立てられます。 参考 : モデル モニタリングの概要 Notebooks 概要 Notebooks は、生成 AI ワークフローやデータサイエンス・ML プロジェクトの構築・テスト・開発に使うマネージドノートブック環境の総称で、目的に応じて Colab Enterprise と Agent Platform Workbench の2つのソリューションから選択できます。 参考 : ノートブック 参考 : ノートブック ソリューションを選択する Colab Enterprise および Agent Platform Workbench の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp Colab Enterprise Colab Enterprise は、チーム利用に最適化されたマネージド Jupyter ノートブック環境で、Google グループや Google Workspace ドメイン単位でのノートブック共有と、複数ユーザーでのリアルタイム共同編集に強みがあります。 2026年5月現在、Gemini によるコード補完・生成、エラーの説明と修正、データサイエンスエージェント、ノートブック内容についてのチャットといった AI アシスタンス機能がプレビューで提供されており、SQL セルや可視化セルなどの機能と組み合わせて、協業とデータ分析を重視するシナリオに適しています。 参考 : Colab Enterprise の概要 参考 : Gemini in Colab Enterprise Agent Platform Workbench Agent Platform Workbench は、VM インスタンス上で動作する JupyterLab 環境で、TensorFlow や PyTorch といったディープラーニング用フレームワークのプリインストールと GPU 構成への対応により、機械学習向けのノートブック環境をすぐに整えられます。 conda 環境によるカーネル拡張、ユースケースに合わせた独自のコンテナでのインスタンス作成など、開発環境を細かく作り込みたいケースに向いており、高いカスタマイズ性を備えています。また、Workforce Identity 連携によるサードパーティ ID プロバイダ認証にも対応しています。 参考 : Agent Platform Workbench の概要 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では、Agent Development Kit（ADK）で開発した AI エージェントで Agent Runtime（旧称 : Vertex AI Agent Engine）の Memory Bank 機能を使用することで、セッション間で情報を保持できるエージェントを構築していきます。 構成 当記事で使用するもの Agent Development Kit（ADK） Agent Runtime Memory Bank Cloud Run Memory Bank を使用するエージェントの開発 エージェントの概要 ディレクトリ構成 プロジェクトの準備 エージェントのソースコード（agent.py） Agent Runtime にエージェントをデプロイ Google Cloud の認証と設定 .env ファイルの作成 Agent Runtime へのデプロイ 動作確認（ADK Web） フロントエンドの構築 フロントエンドの概要 チャットボットの開発 ディレクトリ構成 プロジェクトの準備 app.py Dockerfile OAuth 同意画面の構成 Cloud Run へのデプロイ サービスアカウントの作成 デプロイ 動作確認 Memory Bank のカスタマイズ カスタマイズの概要 カスタマイズ用スクリプト（update.py）の作成 カスタマイズの適用 カスタマイズ後の動作確認 構成 当記事では、 Agent Development Kit （ADK）で定義した AI エージェントを Agent Runtime にデプロイし、また、フロントエンドとしてエージェントとやり取りを行うチャットボットを Cloud Run に構築していきます。 エージェントは、Agent Platform の Memory Bank 機能を使用するように構築します。これにより、一度チャットボットとの会話を終了した後でも、前の会話内容の一部を長期記憶として Memory Bank に保存しておくことができます。 また、Cloud Run では Identity-Aware Proxy （IAP）を有効化することで、Google アカウントで認証されたユーザーのみがチャットボットを利用できるようにします。その上で、IAP が付与する認証済みユーザーのメールアドレスを user_id として Memory Bank に送信することで、ユーザーごとの記憶を Memory Bank に蓄積できるようにします。 Memory Bank 機能を使用する Agent Runtime とチャットボットの構成 当記事で使用するもの Agent Development Kit（ADK） Agent Development Kit （ADK）は、Google Cloud が提供する AI エージェント構築のためのオープンソース フレームワークであり、単純なタスクをこなすエージェントから複数のエージェントが協働する複雑なワークフローまで容易に実装できます。 ADK には、Memory Bank と連携するための PreloadMemoryTool や、セッションイベントを Memory Bank に送信するための add_events_to_memory() といったユーティリティが標準で組み込まれており、長期記憶を扱うエージェントを少ないコードで実装できます。 参考 : Agent Development Kit 参考 : Agent Development Kit の概要 Agent Runtime Agent Runtime は Gemini Enterprise Agent Platform （旧称 : Vertex AI、以下 Agent Platform と記載）で提供されるサービスの1つであり、AI エージェントの実行基盤を提供するフルマネージドサービスです。 Agent Runtime では、エージェントとのマルチターン会話を実現するための組み込みの セッション機能 を利用することができるほか、Memory Bank のように、エージェントの機能拡張に必要な様々な機能が提供されています。 Agent Runtime の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Memory Bank Memory Bank は Agent Platform が提供する 長期記憶 を実現するための機能です。Agent Runtime のセッション機能が一連の会話の中での短期的な記憶を扱うのに対し、Memory Bank はセッションをまたいで利用できる記憶を蓄積します。 Memory Bank は内部的に LLM を用いて、セッションのイベント（会話履歴）からユーザーの嗜好や事実を抽出・要約し、エージェントが認識しているユーザー ID（ user_id ）単位で保存します。これにより、エージェントとの会話（セッション）を一度中断しても、後の会話でユーザーごとにパーソナライズされた応答を返すことができるエージェントを構築できます。 エージェント側から以下の2つの操作を行うことで Memory Bank を利用できます。 記憶の生成・保存 : セッション中のイベントを Memory Bank に送信し、長期記憶として抽出・保存させる 記憶の参照 : 新しいセッションの開始時や会話中に、Memory Bank から関連する記憶を取得し、プロンプトに含めて LLM に渡す ADK ではこれらの操作を簡単に行うための add_events_to_memory() や PreloadMemoryTool といったユーティリティが提供されており、エージェントのコールバックやツールとして組み込むだけで Memory Bank を利用できます。 参考 : Agent Platform メモリバンク Cloud Run Cloud Run は Google Cloud のマネージドなコンテナ実行環境でアプリケーションを実行できる、サーバーレス コンテナコンピューティング サービスです。 当記事ではユーザーがエージェントとやり取りするためのフロントエンドとして使用します。 Cloud Run の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Memory Bank を使用するエージェントの開発 エージェントの概要 当記事では、コーヒーに関する質問に回答する「コーヒーエージェント」を ADK で構築していきます。エージェントを Memory Bank と連携できるように実装することで、ユーザーごとの嗜好や過去のやり取りを長期記憶として蓄積できるようにします。 Agent Runtime を使用してエージェントを構築する ディレクトリ構成 最終的なディレクトリ構成は以下の通りになります。 coffee_agent ディレクトリで AI エージェントを実装していきます。 . ├── coffee_agent │ ├── agent.py │ ├── .env │ └── __init__.py ├── pyproject.toml # 自動で作成 └── uv.lock # 自動で作成 ADK ではエージェントのパッケージ（ここでは coffee_agent ディレクトリ）内に agent.py を配置し、そこにツール関数とエージェント定義を実装します。 プロジェクトの準備 エージェント開発用のディレクトリでプロジェクトを初期化します。 # uv プロジェクト初期化 $ uv init --no-readme # パッケージの追加 $ uv add " google-adk>=1.29.0 " 次に、エージェント用のパッケージディレクトリ（ coffee_agent ）を作成し、ADK がパッケージとして認識できるように __init__.py を配置します。 __init__.py では agent モジュールをインポートしておくことで、 adk コマンドからエージェントを参照できるようになります。 # エージェントのパッケージディレクトリを作成 $ mkdir coffee_agent # __init__.py を作成 $ cat <<EOF > coffee_agent/__init__.py from . import agent EOF エージェントのソースコード（agent.py） 当記事では、Google 検索でコーヒーに関する情報を調べるサブエージェントをツールとして内包するエージェントを構築し、Memory Bank との連携機能を組み込みます。 Memory Bank と連携するために、以下の2つの仕組みを利用しています。 PreloadMemoryTool : ADK が標準提供するツールで、エージェントの実行開始時に Memory Bank から user_id に紐付く記憶を取得し、プロンプトに自動で挿入します。エージェントは過去の会話の文脈を踏まえた応答が可能になります。 after_agent_callback : エージェントの応答が完了した直後に呼び出されるコールバックです。 callback_context.add_events_to_memory() を通じて、直近のセッションイベントを Memory Bank に送信し、記憶として抽出・保存させています。 generate_memories_callback では callback_context.session.events[-5:-1] のように直近のイベントをスライスして送信しています。これにより、応答完了時の最終イベントを除外しつつ、ユーザーの発話とエージェントの応答を含む直近のやり取りのみを Memory Bank に送信します。 from google.adk.agents import Agent from google.adk.tools import google_search from google.adk.tools.agent_tool import AgentTool from google.adk.agents.callback_context import CallbackContext from google.adk.tools.preload_memory_tool import PreloadMemoryTool # 記憶を Memory Bank に保存するコールバック関数 async def generate_memories_callback (callback_context: CallbackContext): # イベント単位で Memory Bank に送信する await callback_context.add_events_to_memory( events=callback_context.session.events[- 5 :- 1 ]) return None # Web 検索用エージェント search_agent = Agent( name= "search_agent" , model= "gemini-2.5-flash" , description= "Google検索でコーヒーに関する情報を調べるエージェント" , instruction= "ユーザーの質問に対してGoogle検索を使って情報を収集し、日本語で回答してください。" , tools=[google_search] ) # ルートエージェント root_agent = Agent( name= "coffee_agent" , model= "gemini-2.5-flash" , description= "コーヒーに関する情報を収集するエージェント" , instruction= """あなたはコーヒーの専門家アシスタントです。 ユーザーからの質問に対して、search_agentを活用しながらコーヒーに関する正確で有益な情報を提供してください。 対応できるトピックの例: - コーヒー豆の産地・品種・特徴 - 抽出方法（ドリップ、エスプレッソ、フレンチプレスなど） - 焙煎度合いと味わいの違い - カフェやコーヒーショップの情報 - コーヒーの健康効果や歴史 - ラテアートやバリスタの技術 回答は日本語で、わかりやすく丁寧に行ってください。""" , tools=[ AgentTool(agent=search_agent), PreloadMemoryTool() ], after_agent_callback=generate_memories_callback ) 参考 : Agent Development Kit によるクイックスタート Agent Runtime にエージェントをデプロイ Google Cloud の認証と設定 デプロイの前に、Google Cloud CLI での認証を行っておきます。 # プロジェクト ID を環境変数にセット $ export PROJECT_ID = < プロジェクトID > # 認証 $ gcloud auth login $ gcloud auth application-default login # プロジェクトの設定 $ gcloud config set project $PROJECT_ID .env ファイルの作成 エージェントの実行時に Gemini Enterprise Agent Platform （旧称 : Vertex AI、以下 Agent Platform と記載）を利用するための環境変数を、 coffee_agent ディレクトリ配下の .env ファイルに設定します。ADK は実行時にこのファイルを自動で読み込みます。 # coffee_agent/.env を作成 $ cat <<EOF > coffee_agent/.env GOOGLE_GENAI_USE_VERTEXAI=1 GOOGLE_CLOUD_PROJECT= $PROJECT_ID GOOGLE_CLOUD_LOCATION=asia-northeast1 EOF GOOGLE_GENAI_USE_VERTEXAI : 1 を指定することで、Gemini API ではなく Agent Platform 経由で Gemini モデルを利用します GOOGLE_CLOUD_PROJECT : エージェントをデプロイする Google Cloud プロジェクト ID GOOGLE_CLOUD_LOCATION : Agent Runtime およびモデルを利用するリージョン Agent Runtime へのデプロイ adk deploy コマンドを使用して、Agent Runtime にエージェントをデプロイします。 # Agent Runtime にエージェントをデプロイ $ uv run adk deploy agent_engine \ --project = $PROJECT_ID \ --region = asia-northeast1 \ --display_name =" Coffee Agent " \ coffee_agent デプロイが成功すると、以下のように Agent Runtime のリソース名が出力されます。 ✅ Created agent engine: projects/ < プロジェクト番号 > /locations/asia-northeast1/reasoningEngines/ < エージェント固有の数字 > このリソース名は、後続の動作確認やチャットボットのデプロイ時に使用するため、シェル変数にセットしておきます。 # 環境変数にリソース名をセット $ export RESOURCE_NAME =projects/ < プロジェクト番号 > /locations/asia-northeast1/reasoningEngines/ < エージェント固有の数字 > なお、すでにデプロイ済みの Agent Runtime を更新する場合は、 --agent_engine_id オプションでリソース名を指定して同じ adk deploy コマンドを実行します。 # 既存の Agent Runtime を更新する場合 $ uv run adk deploy agent_engine \ --project = $PROJECT_ID \ --region = asia-northeast1 \ --agent_engine_id = $RESOURCE_NAME \ --display_name =" Coffee Agent " \ coffee_agent 参考 : ADK CLI documentation - deploy 動作確認（ADK Web） ローカルで ADK Web UI を起動し、Memory Bank と連携した状態でエージェントの動作を確認します。 --memory_service_uri オプションに Agent Runtime のリソース名を指定することで、ローカルの Web UI から Agent Runtime の Memory Bank をエージェントの長期記憶ストアとして利用できます（エージェントはローカルで実行し、Memory Bank 用途でのみ Agent Runtime にアクセスしている状態）。 # Memory Bank を指定して ADK Web UI を起動 $ uv run adk web --memory_service_uri = agentengine:// $RESOURCE_NAME ブラウザで http://localhost:8000 を開き、チャットでエージェントと会話します。 adk web から起動した場合、Memory Bank には user という固定のユーザー ID で記憶が保存されていきます。 まず最初のセッションでは、コーヒーの好み（例: 「私は酸味の強いコーヒーが好きです。おすすめのコーヒー豆はありますか」）をエージェントに伝えます。 最初のセッションでエージェントに好みを伝える Agent Runtime のコンソールから Memory Bank の中身を確認することができます。ADK Web のユーザー（ user ）に関する記憶として、「私は酸味の強いコーヒーが好きです。」という情報が記録されています。 Memory Bank に好みに関する情報が記録されている その後、ADK Web UI 上で新しいセッションを開始し、「私の好みに合う抽出方法を教えて」などと質問することで、Memory Bank に保存されている個人的な好みに関する情報を踏まえた応答が返ってくることを確認できます。 最初のセッションで伝えた好みに関する情報が新しいセッションに引き継がれている 参考 : ADK CLI documentation - web フロントエンドの構築 フロントエンドの概要 機械学習モデルのデモ用 Web UI を容易に作成できる Gradio という Python ライブラリを使用してチャットボットを実装します。 チャットボット Cloud Run にデプロイし、Web サービスとして公開できるようにします。Cloud Run では Identity-Aware Proxy（IAP）を有効化し、Google アカウントで認証されたユーザーのみがアクセスできるようにします。 IAP による認証つきのチャットボットを構築する 参考 : Gradio チャットボットの開発 ディレクトリ構成 フロントエンドはエージェントとは別のディレクトリで構築します。最終的なディレクトリ構成は以下の通りになります。 app.py にチャットボットを実装していきます。 . ├── app.py ├── Dockerfile ├── pyproject.toml # 自動で作成 └── uv.lock # 自動で作成 プロジェクトの準備 エージェントとは別のディレクトリで uv プロジェクトを初期化します。 # uv プロジェクト初期化 $ uv init --no-readme # パッケージの追加 $ uv add " google-cloud-aiplatform[agent-engines]>=1.142.0 " " gradio>=5.29 " app.py app.py では以下の処理を実装しています。 vertexai.init() で Agent Platform に接続し、 agent_engines.get() で Agent Runtime にデプロイしたエージェントを取得 IAP が付与するリクエストヘッダ（ x-goog-authenticated-user-email ）からユーザーのメールアドレスを取り出し、Agent Runtime のセッションおよび Memory Bank の user_id として使用 Agent Runtime のセッション機能（ create_session ）を使い、ユーザーごとにマルチターンの会話を管理 agent.stream_query() でエージェントにメッセージを送信し、ストリーミングで応答を受信 gr.Blocks で Gradio のチャット UI を構築 Memory Bank の記憶は user_id ごとに分離して保存されるため、 user_id の決め方がそのままユーザーごとのパーソナライズの単位となります。ここでは IAP が付与する認証済みメールアドレスをそのまま user_id として用いることで、ブラウザやデバイスをまたいでも同一ユーザーであれば一貫した記憶を参照できる構成にしています。 import os import gradio as gr import vertexai from vertexai import agent_engines AGENT_ENGINE_ID = os.environ[ "AGENT_ENGINE_ID" ] # Identity-Aware Proxy (IAP) が認証済みユーザーのメールアドレスを付与するヘッダ IAP_EMAIL_HEADER = "x-goog-authenticated-user-email" def get_agent (): vertexai.init( project=os.environ.get( "GOOGLE_CLOUD_PROJECT" ), location=os.environ.get( "GOOGLE_CLOUD_LOCATION" ), ) return agent_engines.get(AGENT_ENGINE_ID) agent = get_agent() # IAP から渡されるリクエストヘッダを元にユーザーを一意に特定する def get_user_id (request: gr.Request) -> str : # IAP は "accounts.google.com:user@example.com" の形式で付与するため、 # プレフィックスを除去してメールアドレス部分のみを取り出す raw = request.headers.get(IAP_EMAIL_HEADER, "" ) return raw.split( ":" , 1 )[ 1 ] if ":" in raw else raw def chat (message: str , history: list , session_state: dict , request: gr.Request) -> tuple [ str , dict ]: # IAP で認証されたユーザーのメールアドレスをそのまま Agent の user_id として利用する user_id = get_user_id(request) if not user_id: raise gr.Error( "IAPからユーザー情報を取得できませんでした。" ) session_state[ "user_id" ] = user_id session_id = session_state.get( "session_id" ) if not session_id: session = agent.create_session(user_id=user_id) session_id = session[ "id" ] session_state[ "session_id" ] = session_id response_text = "" for event in agent.stream_query( message=message, user_id=user_id, session_id=session_id, ): if event.get( "content" ) and event[ "content" ].get( "parts" ): for part in event[ "content" ][ "parts" ]: if part.get( "text" ): response_text += part[ "text" ] yield response_text, session_state with gr.Blocks( title= "コーヒーエージェント" , fill_height= True , css= """ .title-row { text-align: center; margin-bottom: 0; } .caption-row { text-align: center; margin-top: 0; color: #666; font-size: 0.9em; } .input-row { position: sticky; bottom: 0; background: var(--background-fill-primary); padding: 10px 0; } """ , ) as demo: gr.Markdown( "<h1 class='title-row'>☕ コーヒーエージェント</h1>" "<p class='caption-row'>コーヒーに関するあれこれをお答えします</p>" ) session_state = gr.State(value={}) chatbot = gr.Chatbot( show_label= False , scale= 1 , avatar_images=( None , "https://em-content.zobj.net/source/google/412/hot-beverage_2615.png" ), placeholder= "質問を入力すると、ここに会話が表示されます" , ) with gr.Row(elem_classes= "input-row" ): textbox = gr.Textbox( placeholder= "コーヒーについて質問してください（例: エスプレッソとドリップの違いは？）" , show_label= False , container= False , scale= 7 , ) def respond (message, history, session_state, request: gr.Request): history = history + [ { "role" : "user" , "content" : message}, ] yield history, session_state, gr.update(value= "" , interactive= False ) assistant_text = "" for text, updated_state in chat(message, history, session_state, request): assistant_text = text session_state = updated_state yield ( history + [{ "role" : "assistant" , "content" : assistant_text}], session_state, gr.update(interactive= False ), ) yield ( history + [{ "role" : "assistant" , "content" : assistant_text}], session_state, gr.update(interactive= True ), ) textbox.submit( respond, inputs=[textbox, chatbot, session_state], outputs=[chatbot, session_state, textbox], ) if __name__ == "__main__" : port = int (os.environ.get( "PORT" , 8080 )) demo.launch(server_name= "0.0.0.0" , server_port=port) Dockerfile Cloud Run にデプロイするためのコンテナイメージを定義します。uv の公式イメージからバイナリをコピーし、依存パッケージのインストールとアプリケーションの起動を行います。 FROM python:3.14-slim COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/ WORKDIR /app COPY pyproject.toml uv.lock ./ RUN uv sync --frozen --no-dev COPY app.py . EXPOSE 8080 CMD [ " uv ", " run ", " python ", " app.py " ] OAuth 同意画面の構成 Cloud Run で IAP を有効化すると、Cloud Run 上のサービスへのアクセス時に Google アカウントでのログインが求められるようになり、許可されたユーザーのみがチャットボットを利用できます。 プロジェクトで OAuth 同意画面の構成をまだ行っていない場合、以下のドキュメントを参照して実施してください。 参考 : OAuth 同意画面を設定し、スコープを選択する Cloud Run へのデプロイ サービスアカウントの作成 Cloud Run 用のカスタムサービスアカウントを作成し、Agent Runtime へのアクセスに必要な Agent Platform ユーザー （ roles/aiplatform.user ）ロールを付与します。 # サービスアカウントの作成 $ gcloud iam service-accounts create coffee-agent-frontend \ --display-name =" Coffee Agent Frontend " # Agent Platform User ロールの付与 $ gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount:coffee-agent-frontend@ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/aiplatform.user " デプロイ gcloud run deploy コマンドで Cloud Run にデプロイします。 --source オプションを指定すると、Cloud Build によるコンテナイメージのビルドとデプロイが自動で行われます。 --no-allow-unauthenticated と --iap を指定することで、IAP で認証されたユーザーのみがアクセスできるようにしています。 --service-account で先ほど作成したカスタムサービスアカウントを指定します。また、 --set-env-vars でデプロイ済みの Agent Runtime のリソース名を環境変数として渡します。 $ gcloud run deploy coffee-agent-frontend \ --source . \ --region asia-northeast1 \ --set-env-vars " GOOGLE_CLOUD_PROJECT= $PROJECT_ID ,GOOGLE_CLOUD_LOCATION=asia-northeast1,AGENT_ENGINE_ID= $RESOURCE_NAME " \ --service-account coffee-agent-frontend@ ${PROJECT_ID} .iam.gserviceaccount.com \ --cpu 1 \ --memory 1Gi \ --no-allow-unauthenticated \ --iap 動作確認 デプロイが完了したら、Cloud Run サービスの URL にブラウザでアクセスします。 # デプロイ後に出力されるサービス URL Service URL: https://lawapi-frontend- < プロジェクト番号 > .asia-northeast1.run.app IAP が有効化されているため、Google アカウントでのログインが求められます。 IAP で保護されたウェブアプリ ユーザー （ roles/iap.httpsResourceAccessor ）ロールが付与されたユーザーでログインします。 Google アカウントでログインする まず最初のセッションでは、普段飲むコーヒーについての情報（例: 「私は中浅煎りのコスタリカをよく飲みます。おすすめの抽出方法を教えてください」）をエージェントに伝えます。 最初のセッションで普段飲んでいるコーヒー豆についての情報をエージェントに伝える Memory Bank の中身を確認すると、IAP でログインしたユーザーのメールアドレスを user_id として、「私は中浅煎りのコスタリカをよく飲みます。」という情報を保持する記憶が作成されていることがわかります。 IAP でログインしたユーザーのメールアドレスを user_id として記憶が作成される 再度、別ブラウザから同じユーザーを使用してチャットボットにログインして、「私の好みに合うコーヒー豆を探してください」と伝えてみます。前回伝えたコーヒーの好みが Memory Bank に記憶されているため、その情報を元にした回答が返ってきます。 ユーザーごとに保存された好みに関する情報が別のセッションに引き継がれている Memory Bank のカスタマイズ カスタマイズの概要 Memory Bank はデフォルト設定でもユーザーの嗜好などを自動的に抽出して長期記憶として保存してくれますが、実際にエージェントとやり取りを繰り返してみると、思うように抽出されない場合もあります。 Memory Bank では、カスタマイズ設定を適用することで、抽出する情報の種類や挙動をユースケースに合わせて調整することができます。 Memory Bank では主に以下の項目をカスタマイズできます。 項目 説明 トピック Memory Bank が保存すべきと判断する情報の種類を定義します。Google Cloud が提供する managed トピック （ USER_PERSONAL_INFO 、 USER_PREFERENCES 、 KEY_CONVERSATION_DETAILS 、 EXPLICIT_INSTRUCTIONS ）と、ラベルと抽出指示を自分で定義できる custom トピック の2種類があります。 生成モデル 記憶の生成に使用する LLM を指定できます（デフォルトは gemini-2.5-flash ）。 埋め込みモデル 記憶の検索や統合の判定に使用する埋め込みモデル（embedding model）を指定できます（デフォルトは text-embedding-005 ）。日本語など英語以外の会話を扱う場合は、 gemini-embedding-001 や text-multilingual-embedding-002 といった多言語対応モデルを指定することで検索品質を向上できます。 有効期限（TTL） 生成・更新された記憶の有効期限を自動設定するルールを定義できます。 Few-shot Examples 抽出してほしい記憶の例をいくつか与えることで、Memory Bank の抽出挙動を調整できます。 カスタマイズ項目の詳細については、以下のドキュメントを参照してください。 参考 : メモリバンク 用に Agent Platform インスタンスを構成する カスタマイズ用スクリプト（update.py）の作成 adk コマンドからは Memory Bank のカスタマイズを直接適用することはできないため、Agent Platform SDK を使用するスクリプトで、デプロイ済みの Agent Runtime インスタンスを更新します。 ここではコーヒーエージェントのユースケースに合わせて、コーヒーに関する情報を重点的に抽出するための custom トピックを定義します。具体的には、以下の5つのトピックを Memory Bank に登録します。 トピック 種類 抽出対象 USER_PREFERENCES managed ユーザーの一般的な嗜好 coffee_taste_preferences custom 好む / 苦手な味わいの傾向（酸味・苦味・フレーバーノート・焙煎度合いなど） brewing_methods custom 普段使用している抽出方法と器具 favorite_beans_and_origins custom 好みの豆の産地・品種・銘柄・ロースター coffee_habits_and_restrictions custom 飲用習慣やカフェイン制限などの制約 また、日本語での会話における検索の品質を高めるため、 similarity_search_config で多言語対応の埋め込みモデル gemini-embedding-001 を指定します。 スクリプトの内容は以下のようになります。 client.agent_engines.update() に context_spec.memory_bank_config.customization_configs を渡すことで、デプロイ済みの Agent Runtime インスタンスに対してカスタマイズ設定のみを反映できます。 import os import vertexai from vertexai.types import ( MemoryBankCustomizationConfig as CustomizationConfig, MemoryBankCustomizationConfigMemoryTopic as MemoryTopic, MemoryBankCustomizationConfigMemoryTopicCustomMemoryTopic as CustomMemoryTopic, MemoryBankCustomizationConfigMemoryTopicManagedMemoryTopic as ManagedMemoryTopic, ManagedTopicEnum, ) client = vertexai.Client( project=os.getenv( "PROJECT_ID" ), location=os.getenv( "LOCATION" , "asia-northeast1" ), ) # Memory Bank に保存する記憶のトピック定義 memory_topics = [ # ユーザーの好み（managed トピック） MemoryTopic( managed_memory_topic=ManagedMemoryTopic( managed_topic_enum=ManagedTopicEnum.USER_PREFERENCES ) ), # 味わいの好み MemoryTopic( custom_memory_topic=CustomMemoryTopic( label= "coffee_taste_preferences" , description=( "ユーザーが好む / 苦手なコーヒーの味わいの傾向。" "酸味・苦味・甘み・ボディ感、フレーバーノート（フルーティ、" "ナッティ、チョコレートなど）、焙煎度合い（浅煎り / 中煎り / 深煎り）。" ), ) ), # 抽出方法・器具 MemoryTopic( custom_memory_topic=CustomMemoryTopic( label= "brewing_methods" , description=( "ユーザーが普段使っている、または興味のあるコーヒーの抽出方法と器具。" "ハンドドリップ、エスプレッソ、フレンチプレス、エアロプレス、サイフォンなど、" "および使用しているグラインダーやドリッパーなどの器具情報。" ), ) ), # 好みの豆・産地 MemoryTopic( custom_memory_topic=CustomMemoryTopic( label= "favorite_beans_and_origins" , description=( "ユーザーが好む / 過去に飲んだコーヒー豆の産地・品種・銘柄・ロースター。" "例: エチオピア イルガチェフェ、ゲイシャ、ブルーマウンテン、特定のロースター名など。" ), ) ), # 飲用習慣・カフェイン制限 MemoryTopic( custom_memory_topic=CustomMemoryTopic( label= "coffee_habits_and_restrictions" , description=( "ユーザーのコーヒーの飲用習慣（1日の杯数、飲む時間帯）、" "カフェイン制限の有無、デカフェ志向、乳製品アレルギーや代替ミルクの好みなど。" ), ) ), ] customization_config = CustomizationConfig(memory_topics=memory_topics) # 類似性検索に使用する埋め込みモデル（多言語対応の gemini-embedding-001 を指定） project = os.getenv( "PROJECT_ID" ) location = os.getenv( "LOCATION" , "asia-northeast1" ) embedding_model = ( f "projects/{project}/locations/{location}/publishers/google/models/gemini-embedding-001" ) # 既存の Agent Runtime を Memory Bank カスタマイズ付きで更新 resource_name = os.environ[ "RESOURCE_NAME" ] agent_engine = client.agent_engines.update( name=resource_name, config={ "context_spec" : { "memory_bank_config" : { "customization_configs" : [customization_config], "similarity_search_config" : { "embedding_model" : embedding_model, }, }, }, }, ) print ( "Memory Bank customization applied." ) print (f "Resource Name: {agent_engine.api_resource.name}" ) カスタマイズの適用 スクリプトを実行する際は、デプロイ済みの Agent Runtime のリソース名（ projects/<プロジェクトID>/locations/<ロケーション>/reasoningEngines/<エージェントID> ）を環境変数 RESOURCE_NAME にセットしておきます。 # 環境変数のセット $ export PROJECT_ID = < プロジェクトID > $ export LOCATION =asia-northeast1 $ export RESOURCE_NAME = < エージェントのリソース名 > # カスタマイズの適用 $ uv run python update.py スクリプトの実行が成功すると、Agent Runtime インスタンスに Memory Bank のカスタマイズ設定が反映されます。 コンソールからは、類似性検索に使用する埋め込みモデルが gemini-embedding-001 に更新されていることが確認できます。 類似性検索に使用するモデルが変更されている カスタマイズ後の動作確認 Cloud Run にデプロイしたチャットボットにログインし、「私は酸味が美味しいコーヒーが好きで、コスタリカ、パナマ、ケニア、エチオピアが特に好みです。ハンドドリップで1日に4杯ほど飲みます。好みに近いおすすめの豆を教えてください」のような内容でメッセージを送信してみます。 Memory Bank を確認すると、設定したトピックごとに記憶が作成されていることがわかります。 設定したトピックごとの記憶が Memory Bank に記録される 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の荒井です。当記事では、Google Cloud Next '26 で発表された Google Workspace に関する新機能について、公式の投稿記事およびセッションの内容をもとに紹介します。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp はじめに Keynote Features Workspace Intelligence（GA） Rapid Enterprise Migration（GA） Drive & Document Editor New Gemini capabilities in Sheets, Docs, and Slides（Preview） Ask Gemini in Drive（GA） Third-party data in Sheets（Preview） Collaboration Ask Gemini in Chat（Preview） AI Inbox and AI Overviews in Gmail（Preview） Help from Gemini in every meeting（Preview） AI Features Workspace skills（Coming Soon） Custom Avatars in Vids（GA） Auto browse with Gemini in Chrome（GA） Workspace MCP Server（Developer Preview） Gemini Enterprise app Workspace capabilities in the Gemini Enterprise app（Private Preview） Management Simplified agent governance（GA） New sovereign controls and client-side encryption（Coming Soon） はじめに 以下の Google 公式投稿および実際に現地で行われたセッションを参考に、Google Cloud Next '26 で発表された Google Workspace に関する新機能を紹介します。なお、当記事で紹介する機能の提供ステータス（GA / Preview / Coming Soon）は 2026年4月29日現在の情報です。 参考 : 10 more announcements from Google Workspace at Cloud Next ‘26 参考 : 260 things we announced at Google Cloud Next '26 – a recap Keynote Features Workspace Intelligence（GA） 1日目のキーノートで発表された Workspace Intelligence は、Google Workspace における発表の中で最も重要なアップデートです。 新しいアプリケーションや操作ボタンとして表示されるものではなく、Google Workspace 内の抽象化されたセマンティックレイヤーとしてバックグラウンドで稼働する仕組みです。 公式投稿から引用 Workspace Intelligence は、Google Workspace の各種アプリケーションに保存されたファイルや、Gmail および Google Chat のメッセージ、インターネット上の情報からコンテキストを収集し、ユーザーの立場や業務内容を分析します。これにより、ユーザーが求めるアウトプットを的確に理解し、Gemini がパーソナライズされた回答を生成します。主要な機能は以下のとおりです。 情報収集 Google Workspace およびインターネットの情報から様々なコンテキスト情報を収集します。 状況認識 Gemini の推論技術を用いることで、今ユーザーにとって何が最も重要かを理解し、重要なタスクを把握します。 パーソナライゼーション 過去の仕事やコミュニケーションパターンを学習し、独自の仕事スタイル、話し方、書式設定の好みを理解し、パーソナライゼーションしたアウトプットを行います。 参考 : Google Cloud Next '26速報レポート - キーノート（1日目） - G-gen Tech Blog 参考 : Introducing Workspace Intelligence 参考 : Workspace
Intelligence Contextual AI for the enterprise 参考 : Introducing Workspace Intelligence, with admin controls Rapid Enterprise Migration（GA） 同じく1日目のキーノートで発表された Rapid Enterprise Migration については、キーノート内での詳細な発表はありませんでしたが、ブレイクアウトセッション「Fast-track to Google Workspace: Smooth migration, adoption, and interoperability」にて具体的な内容が紹介されました。 「Fast-track to Google Workspace: Smooth migration, adoption, and interoperability」のセッション内容は以下の記事を参照してください。 参考 : Fast-track to Google Workspace: Smooth migration, adoption, and interoperability（Google Cloud Next '26速報） - G-gen Tech Blog 実質的には、従来より提供されていた Data Import 機能に該当します。Data Import は従来「データ移行（新規）」という名称でしたが、管理コンソールやドキュメントも Data Import と名称が変更されています。 参考 : Introducing data import: An easier, faster, and higher-fidelity migration to Google Workspace at no additional tool cost 参考 : データ インポート ツールについて データ移行ツールは Data Import に集約され、Microsoft 365 から容易にデータ移行を行えます。スライド内で言及されている「データ移行速度が5倍」という点については、従来 Google Workspace に実装されていたデータ移行ツールに比べて速度が速くなったことを意味しています。 当機能は「データ移行（新規）」として既にプレビューで実装されていた機能です。当社による検証結果は、以下の記事で公開しています。 参考 : Microsoft OneDriveからGoogle ドライブへのデータ移行を検証してみた - G-gen Tech Blog 参考 : Microsoft TeamsからGoogle Chatへのデータ移行を検証してみた - G-gen Tech Blog 参考 : Microsoft SharePoint OnlineからGoogle ドライブへのデータ移行を検証してみた - G-gen Tech Blog 参考 : DropboxからGoogleドライブへのデータ移行を検証してみた - G-gen Tech Blog Drive & Document Editor New Gemini capabilities in Sheets, Docs, and Slides（Preview） 自然言語を用いてドキュメント（スプレッドシートやスライド）の作成や編集ができます。サイドパネルの Gemini に自然言語で指示をするだけで、複数枚のスライドやデータに基づいたインフォグラフィックの作成、コメントのフィードバックに基づいた編集が実行できます。作成されたスライドは編集可能な状態を維持するため、後日資料の再編集もできます。 さらに、企業ブランドを反映したテンプレートを参照しドキュメント作成をすることもできるため、ブランドテンプレートへ変換する手間がなくなります。 参考 : New ways to create faster with Gemini in Docs, Sheets, Slides and Drive 参考 : New Gemini capabilities in Google Docs help you go from blank page to brilliance 参考 : Build and edit complex spreadsheets with Gemini in Google Sheets 実際の動作イメージについては、Google から公開されている以下の動画を参照してください。 youtu.be Ask Gemini in Drive（GA） Ask Gemini in Drive を使用することで、自然言語で探したい情報を素早く検索し要約を作成できます。またソースとなるデータも列挙されるため確実な情報を瞬時に入手することができます。 情報検索時はユーザーのアクセス権限を越えた検索はできません。またコピーや複製は行われないため、安全に使用できます。 参考 : New ways to create faster with Gemini in Docs, Sheets, Slides and Drive 参考 : Ask Gemini in Drive now generally available 参考 : AI Overviews in Drive now generally available Third-party data in Sheets（Preview） HubSpot や Salesforce などのアプリからサードパーティデータを Google スプレッドシートにインポートできるようになりました。 また、スプレッドシートの表から、ダッシュボードやヒートマップ、かんばんボードといった簡易アプリを作成できます。アプリ内のデータはソースとなる表のデータとリアルタイム接続されており、リアルタイムに情報が更新されます。生成したアプリはチームメンバーと共有できます。 表データからアプリを生成するデモンストレーションは、以下の動画で確認できます。 youtu.be Collaboration Ask Gemini in Chat（Preview） Google Chat 内に Ask Gemini が追加され、Workspace Intelligence によりパーソナライズ化された Gemini と会話を行うことができます。 重要タスクの確認やメールの検索、ドキュメントの作成など網羅的に業務支援を行います。 参考 : Get started with Ask Gemini in Google Chat Ask Gemini in Chat を用いてスライドを作成するイメージについては、以下の動画を確認してください。 youtu.be AI Inbox and AI Overviews in Gmail（Preview） Gmail に AI Inbox というトレイが追加されます。受信したメールに対して、 AI を使用した以下の機能を提供します。 To-Do リストの作成 返信が必要なメールを探す キーワードではなく、自然言語でのメール検索 受信メールやスレッドの要約 参考 : Search faster and smarter with AI Overviews in Gmail search Help from Gemini in every meeting（Preview） Google Meet の Gemini 機能により、対面での会議でも、Gemini が音声を記録し、議事録を作成できます。また他社の Web 会議ツールを使用していてもデバイスのマイク機能から議事録の作成ができます。Gemini が会議内容やアクションアイテムを記録することで、ユーザーはより一層会話に集中することができます。 参考 : 対面会議で「自動メモ生成」を使用する 当機能についてはブレイクアウトセッション「Transform meetings into outcomes using Google Workspace with Gemini」でも一部言及されています。以下のセッションレポートも参照してください。 blog.g-gen.co.jp AI Features Workspace skills（Coming Soon） Workspace Studio 内で繰り返しタスクを自動化し、Skill として登録できます。Skill は組織に共有可能であり、Google Workspace 内のあらゆる Gemini からその Skill を起動できるようになります。 Custom Avatars in Vids（GA） Nano Banana 2 の機能により、Google Vids のアバターにブランディング要素を追加できます。企業ロゴをアップロードすることで、アバターにロゴを反映できます。アバターの T シャツにロゴを挿入するなどの編集が、簡単にできます。 参考 : Create custom branded avatars in Google Vids with Nano Banana 2 Auto browse with Gemini in Chrome（GA） 当機能は米国の Google Workspace ユーザーにおけるアップデートです。日本のユーザーは、まだ対応していません。 Chrome Enterprise ライセンスを保有する場合、Gemini の自動ブラウジング機能を有効化できます。Web サイトやアプリを横断し複数ステップのタスクを実行します。Workspace のエンタープライズグレードのセキュリティ機能が適用されるため、機密情報は保護されます。 参考 : The new era of browsing: Putting Gemini to work in Chrome Workspace MCP Server（Developer Preview） Workspace MCP Server を使用することで、ドキュメント作成や Gmail の返信の作成など、高度な Workspace 機能を AI アプリケーションやエージェントに組み込むことができます。 参考 : Google Workspace MCP サーバーを構成する Gemini Enterprise app Workspace capabilities in the Gemini Enterprise app（Private Preview） Gemini Enterprise app から Google Workspace の各種アプリケーションへアクセスし、シームレスに作業を進めることができます。Google カレンダーから会議をスケジュールしたり、ドキュメントやスライドを作成・編集できます。 Management Simplified agent governance（GA） Google Workspace 管理コンソールに AI 関連の制御を包括的に管理できる AI コントロールセンター が導入されました。Workspace 内のデータへのエージェントアクセスを監視、制御、監査することで、AI 活用に関するセキュリティリスクを軽減できます。 New sovereign controls and client-side encryption（Coming Soon） Google Workspace の一部エディションではデータの保管場所を米国および EU に限定することができます。 参考 : データの地理的な保管場所を選択する 今後はドイツやインドなど、さらに多くの国がサポートされる計画が発表されました。 また機密性の高いデータについては、クライアント暗号化により、Google を含む様々なエンティティからのアクセスを禁止するセキュリティ機能が実装されます。 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 / 2026 ・Google Cloud 認定資格 7冠 ・Jagu'e'r エバンジェリスト Follow @arapote_tweet

G-gen の杉村です。2026年4月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud Next '26 の開催 プロダクトの名称変更 概要 Looker Studio → Data Studio（和名: データポータル） Dataplex Universal Catalog → Knowledge Catalog Cloud Composer → Managed Service for Apache Airflow BigLake → Google Cloud Lakehouse Dataproc → Managed Service for Apache Spark Vertex AI → Gemini Enterprise Agent Platform Google Cloud のアップデート オープンモデル Gemma 4 がリリース Cloud Armor に match condition builder が登場（Preview） Google の動画生成 AI モデル Veo 3.1 Lite が Preview 公開 Google Cloud の VPC で Hybrid Subnets が使用可能に Google Cloud コンソールでも Load Balancer 作成時に Certificate Manager 証明書アタッチが可能に Pub/Sub で AI Inference Single Method Transform （SMT）機能が一般公開 BigQuery に AI.AGG 関数が登場（Preview） Cloud SQL でストレージの縮小ができるように すべての Google Cloud 認定資格で日本語版が受験可能に BigQuery Graph が Preview 公開 Privileged Access Manager（PAM）で将来の IAM 権限付与を予約できるように Colab Enterprise で visualization cells が使えるように Cloud Run woker pools が Preview 版 → 一般公開（GA） Google Cloud〜AWS間のPartner Cross-Cloud Interconnectが一般公開（GA） Gemini Enterprise 用の専用 IAM ロールが登場 データポータルで BigQuery の Conversational Analytics が使用可能に Cloud Run でエフェメラルディスクが Preview 公開 Gemini Cloud Assist のサイドパネルが強化 Gemini Enterprise app でカスタム MCP サーバーが接続可能に BigQuery の CDC テーブルからマテリアライズドビューを作成可能に Compute Engine、GKE、Cloud Storage で「AI Zone」が公開 Google SecOps が VPC Service Controls に対応 VPC Service Controls の ingress/egress ルールで IAM ロールが使用可能に Google Workspace のアップデート Google Vids から YouTube への直接エクスポートが可能に Chrome 拡張機能 Google Vids Screen Recorder が登場 Gemini アプリの macOS 版ネイティブデスクトップアプリが登場 Gemini アプリで会話結果から Docs や PDF を生成可能に Google Meet の Take notes for me（自動議事録）のカスタマイズが可能に はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud Next '26 の開催 Google Cloud の旗艦イベントである Google Cloud Next が、米国ネバダ州ラスベガスにおいて4月22日（水）から24日（金）までの3日間、開催された。 Agentic（エージェンティックな、自律的な）をテーマに、数多くの新機能が発表された。発表された機能の中には、既に一般公開（GA）されているもの、Preview 公開されているもの、まだ使用可能になっていないものなどが混同している。 主要な発表がされたキーノート（基調講演）については、以下の記事を参照されたい。 blog.g-gen.co.jp blog.g-gen.co.jp また G-gen では、現地に派遣したエンジニアや日本からリモートで情報収集するエンジニアが、各種セッションレポートを公開している。以下のカテゴリ一覧から、Google Cloud Next '26 の関連記事にアクセスできる。 blog.g-gen.co.jp プロダクトの名称変更 概要 2026年4月には以下のように、プロダクトの名称変更が相次いだ。 旧名称 新名称 Looker Studio Data Studio（和名: データポータル） Dataplex Universal Catalog Knowledge Catalog Cloud Composer Managed Service for Apache Airflow BigLake Google Cloud Lakehouse Dataproc Managed Service for Apache Spark Vertex AI Gemini Enterprise Agent Platform Gemini Enterprise Gemini Enterprise app Looker Studio → Data Studio（和名: データポータル） Data Studio returns as new home for Data Cloud assets (2026-04-11) Looker Studio は Data Studio（和名: データポータル）に名前が再変更された。昔の名前に戻ったことになる。経緯は以下のとおり。 もともとは「英名: Data Studio / 和名: データポータル」という名称だった 日本では商標の関係で「Data Studio」という名称が使えないため「データポータル」と表記される 2022年10月の Google Cloud Next '22 で「Looker Studio」に名前が変更され、Looker ブランドに統一された。Looker と Looker Studio の2つの製品が存在する状態になり、混乱を呼んだ 2026年4月に「英名: Data Studio / 和名: データポータル」に戻った システム的には以下の変更がされた。 UI 上の表記が「データポータル（Data Studio）」になった 従来の URL（ lookerstudio.google.com ）にアクセスすると、新しい URL（ datastudio.google.com ）にリダイレクトされる Dataplex Universal Catalog → Knowledge Catalog Knowledge Catalog release notes - April 10, 2026 Dataplex Universal Catalog は Knowledge Catalog に改名された。 フルマネージドのデータカタログサービス。今回で4回目の名称変更となる。名称の変遷は以下のとおり。 Data Catalog → Dataplex Catalog → BigQuery universal catalog → Dataplex Universal Catalog → Knowledge Catalog Cloud Composer → Managed Service for Apache Airflow Cloud Composer release notes - April 15, 2026 Cloud Composer は Managed Service for Apache Airflow に改名された。 フルマネージドの Apache Airflow であり、データパイプラインの実装等に使われるマネージドサービス。 BigLake → Google Cloud Lakehouse What is Google Cloud Lakehouse? (2026-04-20) BigLake が Google Cloud Lakehouse に改称。 Google Cloud Lakehouse は、Apache Spark、Apache Flink、Trino といったオープンソースのクエリエンジンとの互換性を持つ、レイクハウスフレームワーク。BigQuery を基幹技術とする。 Dataproc → Managed Service for Apache Spark Managed Service for Apache Spark cluster deployment overview (2026-04-22) Dataproc が Managed Service for Apache Spark に改称。 Managed Service for Apache Spark はその名のとおり、フルマネージドの Apache Spark クラスタ。 Vertex AI → Gemini Enterprise Agent Platform Vertex AI to Gemini Enterprise Agent Platform naming changes (2026-04-22) Vertex AI は、Gemini Enterprise Agent Platform と改名された。これに伴い、これまで Gemini Enterprise と呼ばれていた Web サービスは、Gemini Enterprise app と改名された。また Vertex AI プロダクト群は、以下のように名称が変更となる（一部のみ抜粋）。 旧称 旧名称 Vertex AI Gemini Enterprise Agent Platform Gemini Enterprise Gemini Enterprise app Generative AI on Vertex AI Generative AI Vertex AI Studio Agent Studio Vertex AI API Agent Platform API Vertex AI Agent Engine Agent Runtime Vertex AI Search Agent Search Vertex AI Search for Commerce Agent Search for Commerce Vertex AI Conversation Agent Conversation Vertex AI Vector Search Vector Search Vertex AI Training Agent Platform Managed Training Vertex AI Pipelines Agent Platform Pipelines Google Cloud のアップデート オープンモデル Gemma 4 がリリース Gemma 4 モデルの概要 (2026-03-31) オープンモデル Gemma 4 がリリース。商用利用可。以下の種類がある。 E2B / E4B : モバイル、エッジ、ブラウザ向け 31B : より高密度 26B A4B : 高スループットで高度な推論向け Cloud Armor に match condition builder が登場（Preview） Use the match condition builder (2026-03-31) フルマネージド WAF である Cloud Armor に match condition builder が登場（Preview）。 CEL 文を書く時の UI 補助ツール。ルールを書く負担が軽減される。 Google の動画生成 AI モデル Veo 3.1 Lite が Preview 公開 Veo 3.1 Lite Generate Preview (2026-04-02) Google の動画生成 AI モデル Veo 3.1 Lite が Preview 公開。 Veo 3.1 < 3.1 Fast < 3.1 Lite の順で生成秒数あたりの料金単価が安く、Lite が最も安価なモデルとなる。 Google Cloud の VPC で Hybrid Subnets が使用可能に About migrating to Google Cloud with Hybrid Subnets (2026-04-03) Google Cloud の VPC で Hybrid Subnets が使用可能になった。 クラウド側サブネットにオンプレと同じ CIDR を持たせ、IP アドレスを変えずにサーバーをクラウドへ移行できる。オンプレ側ルーターに Proxy ARP の設定が必要であり、またクラウド側のルーティングも少しトリッキーになる。 Google Cloud コンソールでも Load Balancer 作成時に Certificate Manager 証明書アタッチが可能に Google Cloud release notes - April 05, 2026 (2026-04-05) Cloud Load Balancer 作成時に Certificate Manager 証明書のアタッチが Google Cloud コンソールでもできるようになった。 従来は DNS 認証した証明書だと gcloud コマンド等を使う必要があった。今後は証明書マップを UI 上で選択できる。 Pub/Sub で AI Inference Single Method Transform （SMT）機能が一般公開 AI Inference SMT (2026-04-06) Pub/Sub で AI Inference Single Method Transform （SMT）機能が一般公開。Pub/Sub トピックまたはサブスクリプション内のメッセージを Gemini 等の AI モデルで加工。以下のような用途がある。 メッセージに対してリアルタイムで AI モデルによる推論結果を追加（エンリッチメント） アプリケーション側の処理のオフロード 以下の記事も参照。 blog.g-gen.co.jp BigQuery に AI.AGG 関数が登場（Preview） The AI.AGG function (2026-04-06) BigQuery に AI.AGG 関数が登場（Preview）。Cloud Storage 上の非構造化データ（画像またはテキスト）に対して Gemini を使い「意味的な集計」のような処理ができる。感情分析、コンテンツ要約、ログ分析など。 Cloud SQL でストレージの縮小ができるように About storage shrink (2026-04-06) Cloud SQL でストレージの縮小ができるようになった。従来は拡大はできたが縮小はできなかった。インスタンスの再起動が必要。 プライマリインスタンスとリードレプリカの両方で可能。 すべての Google Cloud 認定資格で日本語版が受験可能に Google Cloud 認定資格の一覧を解説。全部で何個ある？難易度は？ (2026-04-08) これまで日本語版しか提供されていなかった以下の2試験の日本語版が公開された。 Professional Security Operations Engineer Professional Cloud Database Engineer これをもって、14種類すべての Google Cloud 認定資格が、日本語で受験可能になった、 以下の記事も参照。 blog.g-gen.co.jp BigQuery Graph が Preview 公開 Introduction to BigQuery Graph (2026-04-09) BigQuery Graph が Preview 公開。 Graph Query Language（GQL）を使ってデータ間の関係性を可視化できる。CREATE PROPERTY GRAPH 文でノードテーブル・エッジテーブルを事前に定義。 Privileged Access Manager（PAM）で将来の IAM 権限付与を予約できるように Grant scheduling (2026-04-13) Privileged Access Manager（PAM）で将来の IAM 権限付与を予約できるようになった。最大7日後の予約が可能。 Colab Enterprise で visualization cells が使えるように Use visualization cells (2026-04-13) Colab Enterprise で visualization cells が使えるように。データフレームに入れた値を基にチャート（図表）を簡単に UI で作成できる。BigQuery → df → 可視化を UI 上で簡単に行える。 Colab Enterprise の visualization cells Cloud Run woker pools が Preview 版 → 一般公開（GA） Deploy worker pools to Cloud Run (2026-04-14) Cloud Run woker pools が Preview 版 → 一般公開（GA）。 Pub/Sub などに対してタスクを取得する pull 型ワークロードを実行するためのフルマネージドのコンテナ基盤。高いコスト効率でコンテナのジョブを実行できる。 Google Cloud〜AWS間のPartner Cross-Cloud Interconnectが一般公開（GA） Partner Cross-Cloud Interconnect for AWS overview (2026-04-14) Google Cloud と AWS を容易に専用線接続できる Partner Cross-Cloud Interconnect が一般公開（GA）。 VPC ピアリングまたは Network Connectivity Center 経由で接続できるため、かなり手軽に Google Cloud 〜 AWS 間で専用線確立が可能。 最短で当日中に接続を確立できる。帯域は1Gbps〜100Gbps。 Gemini Enterprise 用の専用 IAM ロールが登場 IAM roles and permissions (2026-04-15) Gemini Enterprise 用の専用 IAM ロールが登場。 Gemini Enterprise 管理者（ roles/discoveryengine.agentspaceAdmin ） Gemini Enterprise ユーザー（ roles/discoveryengine.agentspaceUser ） これまでは事前定義ロールとして「ディスカバリー エンジン管理者（ roles/discoveryengine.admin ）」および「ディスカバリー エンジン ユーザー（ roles/discoveryengine.user ）」が存在していた。 なお2026年4月現在、これらのロールはそれぞれ名称が違うだけで、含まれている権限が全く同一である。 Gemini Enterprise 管理者 <=> ディスカバリー エンジン管理者 Gemini Enterprise ユーザー <=> ディスカバリー エンジン ユーザー データポータルで BigQuery の Conversational Analytics が使用可能に Data agents in Data Studio (2026-04-16) データポータル（先日、Looker Studio から改名した）の画面から、BigQuery の Conversational Analytics（会話型分析）を使用できるようになった。 データポータル Proライセンスは不要。BigQuery でデータエージェントを作成して、一般従業員にエージェントを配ることが容易になった。 データポータルから BigQuery のデータエージェントを使用する Cloud Run でエフェメラルディスクが Preview 公開 Configure an ephemeral disk for Cloud Run services (2026-04-20) Cloud Run でエフェメラルディスクが Preview 公開。 ext4 フォーマットの一時ディスク。インスタンス停止で消去される。 service、job、worker pool いずれでも使用可。従来の /tmp はインメモリのためメモリ料金を消費したが、今後は一時ディスクに逃がせる。 Preview 公開されている2026年4月現在、料金の表記はない。 Gemini Cloud Assist のサイドパネルが強化 Gemini Cloud Assist release notes - April 22, 2026 (2026-04-22) 日本語でも使える 表示させているコンソール画面をコンテキストとして読み取る グラウンディング有無を設定 カスタムインストラクション など。その他にも Private Preview で MCP への対応など。 Gemini Cloud Assist のサイドパネルが強化 Gemini Enterprise app でカスタム MCP サーバーが接続可能に Set up your custom MCP server data store (2026-04-22) Gemini Enterprise app でカスタム MCP サーバーをデータストアとして接続できるようになった（Preview）。 認証は OAuth。MCP 準拠の外部システムや社内データに Gemini Enterprise app からアクセスできる。 BigQuery の CDC テーブルからマテリアライズドビューを作成可能に Tables with active change data capture (2026-04-28) BigQuery の CDC（change data capture）適用テーブルをベーステーブルとして、マテリアライズドビューを作成可能になった。 ストリーミングデータを受け取るテーブルをベースに、自動更新のマテビューを作成でき、運用負荷の軽減になる。 Compute Engine、GKE、Cloud Storage で「AI Zone」が公開 AI Zones (2026-04-27) Google Cloud で「AI Zone」が公開。Compute Engine、GKE、Cloud Storage が対応。 us-south1-ai1b のような名称の特殊なゾーン。GPU や TPU が優先的に提供される代わりに一部サービスは提供されない。オランダ、テキサス、アイオワのリージョンで使用可能。地理的に隔離されているため、通常ゾーンとのレイテンシは比較的大きい。 Google SecOps が VPC Service Controls に対応 Configure VPC Service Controls for Google SecOps (2026-04-30) Google SecOps の VPC Service Controls 対応が一般公開（GA）。Google SecOps は Google の SIEM 製品。VPC Service Controls による IP アドレス制御や、コンテキストアウェアなアクセス制御が可能になった。 VPC Service Controls の ingress/egress ルールで IAM ロールが使用可能に Configure IAM roles in ingress and egress rules (2026-04-30) VPC Service Controls の ingress/egress ルールで、IAM ロールを使用した許可設定が可能に（Preview → GA）。 これまでプリンシパルやメソッドの指定ができたが特定の IAM ロールを持っている場合のみアクセス許可するよう設定できるようになった。以下の記事も参照。 blog.g-gen.co.jp Google Workspace のアップデート Google Vids から YouTube への直接エクスポートが可能に Export Google Vids directly to YouTube (2026-04-02) Google Vids から YouTube への直接エクスポートが可能に。 MP4 で一度エクスポートする必要がない。限定公開動画のエクスポートも可能。 Chrome 拡張機能 Google Vids Screen Recorder が登場 Record your screen directly from Chrome with the Google Vids Screen Recorder Chrome Extension (2026-04-02) Chrome 拡張機能「Google Vids Screen Recorder」が登場。ブラウザ画面を録画して直接 Google Vids に記録できるため編集や共有が容易になる。 Google Workspace でも個人アカウントでも利用可能。 Gemini アプリの macOS 版ネイティブデスクトップアプリが登場 Gemini アプリが Mac に登場 (2026-04-15) Gemini アプリの macOS 版ネイティブデスクトップアプリが登場。 Web 版にない機能として、画面共有して Gemini に質問する機能などがある。 Gemini アプリで会話結果から Docs や PDF を生成可能に Move from conversation to creation with file generation in Gemini (2026-04-27) Gemini アプリで会話結果から Google ドキュメント、スプレッドシート、Microsoft Word（.docx）、Microsoft Excel（.xlsx）、PDF などのファイルを直接、生成可能になった。その他の対応フォーマットは以下のとおり。 Google Workspace files (Docs, Sheets, and Slides) PDF file Microsoft Word (.docx) Microsoft Excel (.xlsx) CSV file (.csv) LaTeX (.tex) Plain Text (.txt) Rich Text Format (.rtf) Markdown (.md) Gemini アプリで会話結果から Docs や PDF を生成可能に Google Meet の Take notes for me（自動議事録）のカスタマイズが可能に New ways to customize AI-generated meeting notes (2026-04-30) Google Meet の Take notes for me（自動議事録）のカスタマイズが可能に。メモの長さや決定事項を入れるかどうかなど。 ただし、一部機能は英語にしか対応していない。詳細なカスタムプロンプトを入れられるわけではない。2026年4月30日から15日間かけて段階的ロールアウト。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の高宮です。当記事は、Google Cloud Next '26 in Las Vegas の 3 日目に行われたブレイクアウトセッション「 Accelerate CI/CD with coding agents 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 ソフトウェア開発の加速と CI/CD の課題 Google CI/CD Extension の概要と特徴 Google CI/CD Extension を用いたデモ 1. Cloud Run への自動デプロイとシークレットスキャン 2. 複数ステージの CI/CD パイプライン設計 3. Terraform による Infrastructure as Code の生成 セッションの概要 本セッションでは、Google の Haroon Chaudhry 氏（Software Development Manager）と Yeshwanth Gunasekaran 氏（Software Engineer）が登壇しました。 セッションでは、生成 AI を用いてコードを記述した後、本番環境へデプロイするまでの CI/CD パイプライン構築に関する課題と、それを解決するための新しい拡張機能である Google CI/CD Extension が発表され、デモを交えて紹介されました。 ソフトウェア開発の加速と CI/CD の課題 2026年4月現在、生成 AI の普及により、開発者の 90% が日常的に AI を使用しています。しかし、AI によって生成されたアプリケーションを本番環境へデプロイする際、約 60% の開発者が課題に直面していると語られました。安全な CI/CD パイプラインを構築するには、単にスクリプトを生成するだけでなく、多様なツールが混在する複雑な環境全体を適切に制御する必要があるからです。 複数の CI/CD プラットフォームの利用、DevSecOps ツールの統合、インフラストラクチャとコードの連携などの課題により、AI の CI/CD 領域での採用率は 27% に留まっています。AI エージェントは単なるコード生成ツールから、インフラストラクチャ全体を統合するオーケストレーターへと進化する必要があることが強調されました。 Google CI/CD Extension の概要と特徴 この課題を解決するため、Gemini エージェントを統合オーケストレーターとして機能させる Google CI/CD Extension が発表されました。 この拡張機能は、 Gemini CLI の拡張機能および Claude Code プラグインとして利用可能であり、オープンソースとして提供されます。 Cloud Run や Google Kubernetes Engine （GKE）などのランタイムに対応しており、自然言語を用いて CI/CD パイプラインの設計、構築、デプロイを行うことができます。 参考 : Gemini CLIを解説 - G-gen Tech Blog 参考 : GitHub Repository : Gemini CLI Extension for CI/CD Google CI/CD Extension は、以下の 4 つのコンポーネントで構成されています。 コンポーネント 説明 Skills CI/CD パイプラインの設計やデプロイに関する事前定義されたワークフローと知識。 Local MCP Server ユーザーの認証情報で実行され、Google Cloud の CI/CD ツールを管理するローカルの Model Context Protocol サーバー。 Grounding through knowledge base CI/CD のベストプラクティスやデプロイメントパターンをパッケージ化したナレッジベース。 Offline Evals オープンソースや独自開発のプロジェクトにおける設計・デプロイパターンをテストする評価システム。 Google CI/CD Extension を用いたデモ 1. Cloud Run への自動デプロイとシークレットスキャン 最初のデモでは、Cloud Code を用いて Python の Flask アプリケーションを Cloud Run にデプロイする様子が示されました。エージェントはアプリケーションの構成を理解し、 Buildpacks を使用してコンテナイメージを構築します。 参考 : Google Cloud の Buildpack 注目すべき点として、コンテナイメージをクラウド上にプッシュする前に、ハードコードされた認証情報がないかを確認するシークレットスキャンが、拡張機能の組み込みチェックとして自動的に実行されました。安全性が確認された後、ユーザーがリージョンや公開設定を指定すると、Cloud Run へのデプロイが完了しました。 2. 複数ステージの CI/CD パイプライン設計 2 つ目のデモでは、Gemini CLI を使用して、 Cloud Build と Cloud Deploy を使用した複数ステージのパイプライン設計が行われました。 参考 : Cloud Build の概要 参考 : Cloud Deploy の概要 以下のプロンプトで指示すると、エージェントは自律的なパイプライン構築ステップを開始しました。 アプリケーション向けに、ステージング環境と本番環境を含む CI/CD パイプラインを設計してください。失敗時に自動ロールバックを行い、Cloud Build と Cloud Deploy を使用してください。 CI/CD パイプライン構築のステップは以下のとおりです。 No 概要 内容 1 要件定義と計画 専用の Skills（ google-cicd-pipeline-design 、 google-cicd-release-orchestration ）を使用し、Google のベストプラクティスに基づいた計画を立案。 2 デプロイパイプライン構成生成 各環境の Cloud Deploy 構成ファイルを生成。承認ゲートや自動ロールバックルールを自動で組み込み。 3 インフラセットアップ Developer Connect による GitHub 接続、 Artifact Registry 作成、最小権限の IAM ロールを付与したサービスアカウントを準備。 4 ビルド構成の実装 Cloud Build 構成ファイルを作成。リポジトリへのプッシュをトリガーとしたエンドツーエンドのフローを完成。 参考 : google-cicd-pipeline-design 参考 : google-cicd-release-orchestration 参考 : 構成スキーマ リファレンス 参考 : ビルド構成ファイルを作成する 3. Terraform による Infrastructure as Code の生成 最後のデモでは、設計された CI/CD パイプラインのインフラストラクチャを、 Terraform を用いたコードとして生成する様子が披露されました。元のプロンプトに 「Terraform を生成して。」 の1文を追加するだけで、エージェントは専用の Skills google-cicd-terraform を呼び出し、必要な設定ファイルを出力します。 参考 : google-cicd-terraform 生成されたファイルには、Artifact Registry、Cloud Build、Cloud Deploy の設定に加え、専用のサービスアカウントや厳格な IAM ロールの付与までがコード化されており、本番環境レベルのパイプライン構築が対話のみで完結することが示されました。 高宮 怜 (記事一覧) クラウドソリューション部クラウドエクスプローラ課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya

G-gen の河野です。当記事では、 Gemini Enterprise と Agent Development Kit （ADK）を組み合わせて、Google Workspace のリソースを操作する独自の AI エージェントを開発しデプロイする手順を解説します。 はじめに Gemini Enterprise とは Agent Development Kit（ADK）とは 当記事について 背景と構成 なぜ独自開発が必要なのか エージェントの構成 ADK エージェントの実装 ディレクトリ構成 agent.py requirements.txt __init__.py .env Agent Engine へのデプロイ デプロイコマンドの実行 Gemini Enterprise との接続 Google Sheets API の有効化 OAuth クライアント作成 Gemini Enterprise アプリの作成 エージェントの接続設定 動作確認 はじめに Gemini Enterprise とは Gemini Enterprise は、組織内に分散しているデータを横断的に検索し、情報の発見を手助けする生成 AI サービスです。対話型のアシスタント機能や、AI エージェントのプラットフォームとしての機能を備えています。 Gemini Enterprise の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Development Kit（ADK）とは Agent Development Kit （以下、ADK）は、Google によって開発された AI エージェント構築用のフレームワークです。ADK を使用することで、エージェントへの関数処理組み込みや外部ツールの使用、マルチエージェントの実装が行えます。 以下の記事カテゴリも参照してください。 blog.g-gen.co.jp 当記事について 当記事では、Gemini Enterprise の標準機能だけでは実現が難しい「Google Workspace リソースへの複雑な操作」を、ADK を用いて実装する方法を解説します。 当記事で実装したのは、ユーザーがアップロードした議事録ファイルからタスクを抽出し、指定した Google スプレッドシートに自動で登録する AI エージェントです。 背景と構成 なぜ独自開発が必要なのか Gemini Enterprise には、 Google Workspace と連携するための標準コネクタが用意されています。しかし、標準コネクタでできることは、Google ドライブや Gmail などに対する横断検索や、カレンダーの予定作成、Gmail の送信といった一部の操作に限定されています。 参考 : Connect a Google data source - Supported actions 標準のコネクタでは実行できない操作や、複数の Google Workspace リソースを連携させた複雑な処理を実現したい場合などには、独自のエージェントの開発が必要です。 エージェントの構成 ユーザーが Gemini Enterprise の画面から Google ドキュメントで書かれた議事録を送信すると、 Vertex AI Agent Engine 上で稼働する ADK エージェントが、タスク管理表に抽出するべきタスクを抽出します。 その後エージェントは、ユーザーの権限（OAuth 認証で取得したアクセストークン）を使用して Google Sheets API を呼び出し、スプレッドシートのタスク管理表に、抽出したタスクを追記します。 構成図 ADK エージェントの実装 ディレクトリ構成 以下の構成で、ファイルを作成します。 agent_folder（任意のフォルダ名） ├── agent.py ├── requirements.txt ├── .env └── __init__.py agent.py agent.py は、議事録からタスクを抽出してスプレッドシートに書き込むための AI エージェント本体です。Python 用の ADK を用いてコーディングされています。 コード内の {auth_id} には、任意の値を設定してください。この値は、後述の Gemini Enterprise の設定で使用するので、控えておいてください。 {スプレッドシートID} と {シート名} はタスクの出力先となるスプレッドシートの情報に置き換えてください。 from typing import List, Dict from google.adk.agents.llm_agent import Agent from google.adk.tools.tool_context import ToolContext from google.oauth2.credentials import Credentials from googleapiclient.discovery import build def write_tasks_to_sheet (tool_context: ToolContext, tasks: List[Dict]) -> str : """ 抽出されたタスクのリストを受け取り、スプレッドシートに書き込む Args: tasks: 書き込むタスクのリスト。各タスクは「タイトル」「詳細」「担当者」「期限」のキーを持つ辞書。 Returns: 処理結果を文字列として返す。 """ # Gemini EnterpriseでのOAuth認証で得たアクセストークンを取得 access_token = tool_context.state.get( "{auth_id}" ) if not access_token: return "エラー: アクセストークンが使用できません。認証設定を確認してください。" # アクセストークンを使用して、スプレッドシートを操作するインスタンスを作成 creds = Credentials(token=access_token) service = build( 'sheets' , 'v4' , credentials=creds) # スプレッドシートに書き込む values = [[ task.get( 'タイトル' , '' ), task.get( '内容' , '' ), task.get( '担当者' , '' ), task.get( '期限' , '' ) ] for task in tasks] service.spreadsheets().values().append( spreadsheetId= "{スプレッドシートID}" , range = "{シート名}!A1" , valueInputOption= 'USER_ENTERED' , insertDataOption= 'INSERT_ROWS' , body={ 'values' : values} ).execute() return f "{len(tasks)} 件のタスクを正常に記録しました。" root_agent = Agent( model= 'gemini-2.5-flash' , name= 'root_agent' , description= '入力された議事録を分析し、タスクをスプレッドシートに記録するエージェント' , instruction=( "入力された議事録を分析し、タスクをスプレッドシートに記録するエージェント" "ユーザーからテキストまたはファイルにて議事録を受け取った場合、以下の手順で処理してください: \n " "1. 議事録のテキストを読み取り、内容を分析し、具体的なアクションアイテムを抽出します。 \n " "2. 各タスクを「タイトル」「内容」「担当者」「期限」のフィールドを持つJSONオブジェクトに変換します。" "不明なフィールドは「不明」とします。 \n " "例: {'タイトル':'タスク名','内容':'詳細','担当者':'名前','期限':'YYYY/MM/DD'} \n " "3. 抽出・変換したタスクのJSON配列を 引数`tasks`として、`write_tasks_to_sheet` ツールを呼び出します。" ), tools=[write_tasks_to_sheet], ) 上記のソースコードは、大きく分けて「AI エージェントの定義」と「スプレッドシートへの書き込み処理」の2つのパートで構成されます。 AIエージェントの定義（43~57行目） エージェントにおける AI の推論部分を担います。 instruction （システムプロンプト）の中で、AI に対して「議事録を受け取ったらタスクを抽出し、指定のフォーマットに整形してツールを呼び出す」ように手順を指示しています。 tools=[write_tasks_to_sheet] と定義することで、関数 write_tasks_to_sheet （抽出したタスクをスプレッドシートへ書き込む処理を行う）の呼出しができます。 スプレッドシートへの書き込み処理（9~41行目） 議事録から抽出したタスクのリストを受け取り、Google Sheets API を使って指定のスプレッドシートに追記する処理を担います。 引数 tool_context からユーザーが Gemini Enterprise 上で行った OAuth 認証のアクセストークンを取得し、安全にユーザー権限でスプレッドシートを操作します。 ADK において、ソースコードの Docstring（関数の説明文）は LLM がツールの用途を正しく理解するための重要な要素となるため、適切に記述することが推奨されます。 requirements.txt 必要なライブラリを定義します。2026年4月時点での最新バージョンを指定しています。 google-adk== 1.28 . 1 # ADKのフレームワーク google-auth== 2.49 . 1 # OAuth認証用 google-api-python-client== 2.193 . 0 # スプレッドシートAPI用 __init__.py エージェント起動時に agent.py が読み込まれるようにするためのファイルです。 from . import agent .env エージェント起動時に読み込まれる環境変数を定義します。 GOOGLE_GENAI_USE_VERTEXAI = 1 GOOGLE_CLOUD_PROJECT = { 自身のプロジェクトID } GOOGLE_CLOUD_LOCATION =us-central1 Agent Engine へのデプロイ デプロイコマンドの実行 ターミナルで agent_folder ディレクトリに移動し、ソースコードを Agent Engine にデプロイします。 ※ ライブラリ google-adk がインストールされた環境で実行して下さい。 cd agent_folder adk deploy agent_engine \ --project = 自身のプロジェクトID \ --region = us-central1 \ --display_name =" TaskCreateAgent " \ . デプロイ完了後、Google Cloud コンソールの [Vertex AI] > [Agent Engine] 画面で、エージェントがデプロイされていることを確認します。 後の手順で使用するため、デプロイされたエージェントの リソース名 を控えておきます。 Gemini Enterprise との接続 Google Sheets API の有効化 Google Cloud コンソールで「Google Sheets API」を検索し、有効化します。 OAuth クライアント作成 Google Cloud コンソールの [Google Auth Platform] > [クライアント] から、以下のパラメータで「OAuth クライアント ID」を作成します。以下の表に記載が無いパラメータについては、未入力でも問題ありません。 設定項目 設定値 アプリケーションの種類 ウェブ アプリケーション 名前 任意の名前 承認済みのリダイレクト URI https://vertexaisearch.cloud.google.com/oauth-redirect 承認済みのリダイレクト URI とは、認証後に取得したアクセス権をGemini Enterprise上で使用することを許可する設定です。 OAuth クライアントの作成後、表示される「クライアント ID」と「クライアント シークレット」を控えておきます。 Gemini Enterprise アプリの作成 Gemini Enterprise でエージェントを稼働させるためのアプリを作成します。アプリを作成するユーザーには、以下の IAM ロールが必要になります。 ディスカバリー エンジン管理者（ roles/discoveryengine.admin ） 以下の手順でアプリを作成します。 Google Cloud コンソールの [Gemini Enterprise] > [アプリ] から [アプリを作成する] を選択します。 アプリ名に任意の値を入力し、場所は global を選択して作成します。 global 以外のロケーションを利用する場合、機能制限があるため、今回は global を選択しました。 参考 : マルチリージョンの制限事項 エージェントの接続設定 デプロイした Agent Engine のエージェントを、作成した Gemini Enterprise のアプリに接続します。 1.アプリの管理画面から [エージェント] > [エージェントを追加] をクリックし、「Agent Engine によるカスタム エージェント」を選択します。 2.「承認」の設定画面にて、以下のパラメータで「承認を追加」します。 設定項目 設定値 認証名 任意の値 認証ID agent.pyで入力した{auth_id}の値 クライアント ID 控えておいたOAuth クライアント ID クライアント シークレット 控えておいたOAuth クライアント シークレット トークン URI https://oauth2.googleapis.com/token 承認 URI https://accounts.google.com/o/oauth2/v2/auth?scope=https%3A//www.googleapis.com/auth/spreadsheets&include_granted_scopes=true&response_type=code&access_type=offline&prompt=consent&client_id={クライアントID} 設定値の トークン URI とは、Google提供のAPIを使用する際の「アクセストークン」を発行してくれる窓口です。 承認 URI とは、OAuth認証画面において承認するスコープ等を定義したURIです。今回はスプレッドシートを操作するスコープ（ googleapis.com/auth/spreadsheets ）を設定しています。 {クライアントID} の部分は実際のOAuthクライアントIDに置き換えて下さい。 参考： ウェブサーバー アプリケーションに OAuth 2.0 を使用する 3.「構成」の設定画面で、以下のパラメータで構成を「保存」します。 設定項目 設定値 エージェント名 任意の名前 エージェントの説明 エージェントの説明 Agent Engine 推論エンジン 控えておいたAgent Engine のリソース名 動作確認 以下の手順で、エージェントの動作確認を行います。 Google ドライブ上に、Google ドキュメントで議事録ファイルを、Google スプレッドシートでタスク管理用シートを作成します。 Gemini Enterprise で、エージェント一覧から、作成したエージェントを選択します。 アシスタントに、議事録ファイルを Google ドライブから追加したうえで「タスクを登録して」と入力します。 タスク管理用シートに、抽出されたタスクが登録されたことを確認します。 河野 利紀 (記事一覧) クラウドソリューション部 デジタルワークプレイス課 2025年10月にG-genに入社。 神奈川在住で、Google Cloud をマスターするため日々エンジニアとして修行中。

G-gen の高宮です。当記事は、Google Cloud Next '26 in Las Vegas の1日目に行われたブレイクアウトセッション「 Transform cloud operations and management with generative AI 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 ソフトウェア開発の加速と運用側の課題 Gemini Cloud Assist の進化 Gemini Cloud Assist の新しい特徴 エージェントの内部構造 プロアクティブなエージェントと自律化 MCP サーバーによるエコシステム連携 Gemini Cloud Assist を用いたデモ 1. ホリデーセールを想定した負荷テスト環境の構築 2. 既存環境のコンテキスト理解とプロビジョニング 3. 稼働状況の確認と調査の提案 4. インフラとアプリケーションコードの統合分析 5. 修復プランの提示と実行 Replit 社における活用事例 セッションの概要 本セッションでは、Google の Deepak Kallakuri 氏（Group Product Manager）、 Mark Church 氏（Group Product Manager）、そして Replit 社の Scott Kennedy 氏（VP of Engineering）が登壇しました。 セッションでは、生成 AI の普及によって爆発的に増加するアプリケーションを管理するために、 Gemini Cloud Assist がどのように進化し、プロアクティブかつ自律的なクラウド運用を実現するのかについて、デモを交えて紹介されました。 ソフトウェア開発の加速と運用側の課題 生成 AI とエージェントの登場により、ソフトウェア開発の障壁が下がり、かつてないスピードで新しいソフトウェアが生み出されています。しかし、その裏側で運用チームは、急速に開発されるアプリケーションを安全かつ確実にデプロイし、管理するという課題に直面しています。 生成 AI やエージェントを使用して開発されたアプリケーションには、従来のマニュアルが通用しない課題（品質、トレース、ハードウェア要件など）があります。 Gemini Cloud Assist を使用して運用チームがこの状況を解決するためには、単なる「対話型のエージェント」以上の、ワークフローを自動化するエンタープライズグレードの「自律的なエージェント」が必要であると語られました。 Gemini Cloud Assist の進化 Gemini Cloud Assist の新しい特徴 Gemini Cloud Assist はマニュアルなワークフローから、プロアクティブなクラウドライフサイクル管理へと進化しました。主な強化ポイントは以下の通りです。 カテゴリ 概要 詳細・特徴 Design & Deploy インフラ設計とデプロイ Terraform における YAML を用いたインテント駆動型設計。セキュリティ設計。 Operate & Manage リソース操作の代行 gcloud と kubectl、bq コマンドの連携。Human-in-the-Loop を伴うコマンドの実行。 Investigate 調査・トラブルシューティング プロアクティブな調査。サポートケースの作成と引継ぎ。 Optimize コストの分析と最適化 プロアクティブなコスト分析。コスト異常の検出。 参考 : Gemini Cloud Assist overview 参考 : Gemini Cloud Assist Investigationsを解説。AIエージェントでトラブルシューティング - G-gen Tech Blog エージェントの内部構造 Gemini Cloud Assist を支えるエージェントの内部構造として、大きく以下の3つの要素が追加・強化されたことが解説されました。 機能 概要 詳細・特徴 Reasoning loop 推論ループ ユーザーのプロンプトや解決すべき課題について推論し、ツールの呼び出しを実行。以前の実行結果に基づいて次の呼び出しを調整し、複雑なトラブルシューティングの際には複数の推論ループを並行して実行することが可能。 Agent Session History エージェントのセッション履歴 ユーザーのセッションを理解し、コンソール画面やプロジェクト内のリソースからコンテキストを取得。 Long-term memory 長期記憶 環境やユーザーの好みを長期的に学習することで、時間の経過とともにより的確な回答を返すように進化。 プロアクティブなエージェントと自律化 Proactive agents は、アラートが発生した際にエージェントが自律的に調査を開始する機能です。これまではアラートが発生してから人間が調査を開始していましたが、この機能により、深夜にアラートが発生しても、エージェントが自動的に関連するアラートをグループ化し、調査を実行して根本原因と修正案を作成しておきます。運用担当者が確認したときには、すでに解決の準備が整っているという、プロアクティブな運用への転換を実現します。 参考 : Set up Proactive Mode 参考 : Automate actions based on Proactive Agent results MCP サーバーによるエコシステム連携 Gemini Cloud Assist が Model Context Protocol （以下、 MCP ）をサポートしました。これにより、 Gemini CLI や Claude Code 、あるいは自作のカスタムエージェントから、 Gemini Cloud Assist の調査機能やコスト分析機能をツールとして呼び出せるようになります。Google Cloud の専門知識を持つエージェントの能力を、既存の開発ワークフローにシームレスに組み込むことが可能です。 参考 : Integrate Gemini Cloud Assist with third-party tools using MCP 参考 : MCP Reference: geminicloudassist.googleapis.com 参考 : Google Cloud MCP Serversを解説 - G-gen Tech Blog Gemini Cloud Assist を用いたデモ 1. ホリデーセールを想定した負荷テスト環境の構築 セッションでは、強化された各機能を活用し、チャットアプリケーションの負荷テスト環境の構築から、それに伴う障害の調査と解決までを一気通貫で行うデモが披露されました。 デモのシナリオとして、チャットベースのアプリケーション（Chatly）に対してホリデーセールをシミュレーションするために、擬似的にトラフィックを生成するジェネレータを追加する状況が示されました。 Gemini Cloud Assist に対して、自然言語で「トラフィックジェネレータを追加して」と指示を出します。 2. 既存環境のコンテキスト理解とプロビジョニング 指示を受けたエージェントは、プロジェクト内の既存リソースの状態を理解し、必要なインフラ構成を推論します。この際、すでに別のトラフィックジェネレータが存在していることを検知すると、「すでに存在しますが、新しく作成しますか？ それとも更新しますか？」とユーザーに確認を求めました。 これは、エージェントが単に指示を実行するだけでなく、環境のコンテキストを理解して重複作業を回避する能力を示しています。運用担当者が実行を承認（ Human-in-the-loop ）すると、エージェントがユーザーの権限を代理行使してトラフィックジェネレータをデプロイしました。 3. 稼働状況の確認と調査の提案 負荷テストの実行後、アプリケーションのトラフィック、レイテンシ、エラー率などを尋ねると、エージェントは Cloud Monitoring などから情報を収集し、それらを包括的に提示しました。ロードバランサから 503 エラーが返され、レイテンシが悪化していることを検知したエージェントは、自発的に「詳細な調査を実行しましょうか？」とユーザーに提案し、トラブルシューティングのフェーズへとスムーズに移行しました。 4. インフラとアプリケーションコードの統合分析 デモ環境は、フロントエンドおよびバックエンドの Cloud Run と、永続化層の Cloud SQL で構成される3層アプリケーションです。 Gemini Cloud Assist が調査を開始すると、複数の仮説を並行して検証しました。高い CPU 使用率や、ログに出力された OOM（Out of Memory）メッセージなどのインフラストラクチャのシグナルを収集します。 さらに、ソースコードのデプロイメントと連携し、アプリケーションのコードベースまで踏み込んだ調査を行いました。結果として、「アプリケーションコード内に、150万個の辞書オブジェクトを生成する非効率なループ処理が存在し、それが設定されたメモリ上限を超過させている」という根本原因を特定しました。 5. 修復プランの提示と実行 開発チームにコードの修正を依頼してデプロイを待つ間にもシステムを復旧させるため、 Gemini Cloud Assist は暫定的な修復プランとして「 Cloud Run のメモリ割り当てを 2GB に増やす」ことを提案しました。運用担当者が提案内容を確認し、実行を承認すると、エージェントが迅速に設定を変更し、障害を解消させました。 Replit 社における活用事例 Replit 社の Scott Kennedy 氏からは、同社のプラットフォーム上で稼働する 120 万以上の公開アプリを支えるために AI がいかに不可欠であるかが語られました。 Replit では、ユーザーがアプリを公開した後に直面する「運用の罠（コスト、信頼性、セキュリティの不安）」を解決するために、 Gemini Cloud Assist を活用しています。ワンクリックで稼働状況の調査、原因特定、そして修正の適用までを自律的に行える環境を構築しています。将来的には、AI が第 1 次オンコール担当となり、人間はより複雑なアーキテクチャの設計に集中できるようになると展望を述べました。 高宮 怜 (記事一覧) クラウドソリューション部クラウドエクスプローラ課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya

G-gen の山崎です。当記事は、Google Cloud Next '26 in Las Vegas の3日目に行われたライトニングトークセッション「 Humanoid robots in pediatric care 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 現在の高齢化社会における課題 ケアワーカーの人員不足 小児医療の現場における課題 高齢者介護の現場における課題 ヒューマノイドロボット Miroki の特徴 人中心のデザインと導入要件 ハードウェアインターフェースと安全性 医療および介護現場での導入事例 小児医療での利用 高齢者介護施設での利用 Google の AI 技術との統合 質疑応答 質問1 : 物理的な力が必要なタスクへの対応 質問2 : 感情の知覚 質問3 : ロボットのデザイン 質問4 : システム構築における課題 ブースでの実機レポート セッションの概要 Enchanted Tools 社の Firas Farraj 氏により、小児医療および高齢者介護の現場で活躍するヒューマノイドロボット「 Miroki 」と Google の AI 技術との統合について紹介されました。 現在の高齢化社会における課題 ケアワーカーの人員不足 現在の高齢化社会において、介護および医療業界は深刻な負担を強いられています。 高齢者、子供をケアするケアワーカー（介護・医療従事者）への負担は増大し続けており、2030年までに世界中で現在より 2,000万人 のケアワーカーが必要になると予測されています。 施設は人材の採用に苦労しており、人員不足の解決が急務となっています。 小児医療の現場における課題 小児医療の現場に目を向けると、毎年 40万人 の子供たちががんと診断されており、そのうちの 3分の1以上 が放射線治療を必要としています。 これまで経験したことのない新しい状況と慣れない環境での治療は、子供たちに大きな恐怖を与えます。 彼らには、時間をかけてそばに寄り添い、守ってくれるケアワーカーの存在が必要です。しかし、ケアワーカーは日々の膨大な業務に追われており、一人ひとりの子供に対して十分な時間を割くことは困難です。 高齢者介護の現場における課題 高齢者介護の現場においても状況は同様であり、高齢者介護施設のスタッフは毎年 40% が離職しているという事実が示されました。この高い離職率は、施設運営における知識の喪失や採用コストの増加など、ビジネスにとって非常に厳しい影響を及ぼします。 このような業界の課題を解決するため、ロボットが実行可能なタスクを担い、ケアワーカーを支援するアプローチが求められています。 ヒューマノイドロボット Miroki の特徴 人中心のデザインと導入要件 Enchanted Tools 社が開発しているヒューマノイドロボット Miroki は、これまでの産業用ロボットとは全く異なるコンセプトで設計されています。Firas Farraj 氏は、人の生活空間にロボットを導入するためには、以下の3つの要素が不可欠であると述べました。 信頼（Trusted） ロボットが常に安全に稼働し、100%の確率でタスクを遂行する。 有用性（Useful） 単に見た目が良いだけでなく、実際に現場で役立つ機能を持っている。 愛着（Loved） 利用者が「そばにいてほしい」と感じるデザインである。 もしロボットが威圧的なデザインや、70 kg もある巨大な機械であった場合、子供や高齢者のそばに置いておきたいと思う人は多くありません。 そのため Miroki は、魅力的で親しみやすいキャラクターとしてデザインされています。単なる実用性だけでなく、人を中心とした環境においては感情的なつながりを作り出すことが必要です。 ハードウェアインターフェースと安全性 ロボットが環境内のあらゆる物体を100%の成功率で操作することは、2026年4月現在のロボット工学の技術レベルにおいては困難です。 この課題を解決し、ロボットに何ができて何ができないかを利用者に明確に伝えるため、Enchanted Tools 社はロボット専用のハンドルとアクセサリーのエコシステムを開発しました。 Miroki は、この専用ハンドルが取り付けられた物体のみを安全に操作できるように設計されています。これにより、利用者はハンドルの有無を見るだけで、Miroki ができることを直感的に理解できます。 また、特殊な移動システムを採用しており、柔軟かつ静音性が高く、人のすぐそばで安全に稼働できるように設計されています。 医療および介護現場での導入事例 小児医療での利用 フランスのモンペリエにあるがん研究所では、小児がんの放射線治療において Miroki が導入されています。放射線治療室は地下壕のような構造になっており、治療中は患者以外は立ち入ることができません。治療自体に痛みはありませんが、巨大な機械が患者の周囲を動き回る空間は、子供たちにとって非常に恐ろしいものです。 これまで、恐怖心を和らげるために子供たちには事前に鎮静剤が投与されていました。そのため、本来は 10分 で済む治療プロセスが 1時間以上 かかっていました。 現在では、事前に子供と Miroki の間に関係性を築いた上で、治療室に Miroki が同席する取り組みが行われています。Miroki がそばにいることで子供たちは安心し、鎮静剤を使用せずに治療を受けることができるようになりました。この結果、1回のセッション時間が 50分 から 25分 へと半減し、同じ時間枠で2倍の数の子供たちをケアできるようになりました。 高齢者介護施設での利用 高齢者介護の環境において、Miroki はケアワーカーの業務を多角的に支援しています。具体的なタスクとしては、受付、高齢者向けの朝の体操の進行、記憶力ゲームの実施、食事トレイの運搬補助、グループ活動全般の支援などです。 Miroki がこれらの業務をサポートし、スタッフに寄り添うことで、スタッフと入居者双方の生活の質を向上させています。初期の導入結果では、スタッフと入居者の間で 80% の満足度が得られています。スタッフの満足度を高く保つことは定着率の向上につながり、課題である40%という高い離職率を低下させるための重要な要素です。 Google の AI 技術との統合 Enchanted Tools 社は、Google DeepMind 社と緊密に連携し、ロボットのアーキテクチャに Gemini を統合しています。 参考 : Google DeepMind 音声認識および対話機能には Gemini Live の音声機能が使用されており、自然なコミュニケーションを実現しています。また、周囲の環境を認識し理解する機能には Gemini Robotics が使用されています。 参考 : Gemini Live 参考 : Gemini Robotics セッション内のデモ動画では、利用者が「メガネをなくしてしまった」と伝えると、Miroki がエリアをスキャンしてメガネを発見し、さらに本を読むための居心地の良い場所を提案する様子が紹介されました。音声だけでなく状況を視覚的に捉え、複数のタスクを連続して支援する能力が示されました。 質疑応答 本セッションの後半では、参加者と登壇者による質疑応答が行われました。 質問1 : 物理的な力が必要なタスクへの対応 質問 高齢者介護において、患者や入居者を持ち上げたり移動させたりするような、物理的な力が必要なタスクへの対応はどのようになっているか。 回答 2026年4月現在、まだその段階には到達していないが、現在の技術の加速を考慮すると、2〜3年のタイムラインで物理的タスクにも対応できるようになると予測している。技術の進歩に合わせてケアワーカーを全面的に支援できるように機能を拡張していく方針だ。 質問2 : 感情の知覚 質問 誰かが怒っている、悲しんでいるといった感情の知覚についてどこまで進んでいるのか。 回答 感情の検出には、視覚分析、声のトーンや表現方法の分析、そして発話されるテキストの分析という3つのモダリティを使用している。Gemini のマルチモーダル機能により、人が感情を表現している場合は十分に把握可能となる。人が感情を表現していない場合は、非言語的なシグナルを読み取る必要があるため、難易度が高い。 質問3 : ロボットのデザイン 質問 なぜロボットがキツネのような見た目をしているのか。 回答 ロボットのデザインを人の外見に近づけすぎてしまうと、人ができることはすべてできるはずだと利用者が認識する可能性があるため、人とペットの中間のような、これまでにない新しいキャラクターをデザインした。 質問4 : システム構築における課題 質問 システムに Gemini を組み込むことによって直面した課題はあるか。 回答 Google DeepMind 社の素晴らしい働きにより、モデルのパフォーマンスに関する課題は発生していない。一方で、モデルをクラウド上で実行するため、ネットワークの通信環境が悪い環境下では課題が残っている。将来的にはオフライン環境下においても十分なパフォーマンスを発揮できるようにしたい。 ブースでの実機レポート セッション終了後、会場内の Enchanted Tools 社の展示ブースに立ち寄り、Miroki の実機を見ることができました。 展示ブースでは、スムーズに移動しながら展示ブースに訪れた人々と自然な会話を行う姿を見ることができ、ハードウェアの工夫と AI 技術の統合が実用的なレベルに達しつつあることを感じました。 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 13 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の荒井です。当記事は Google Cloud Next '26 in Las Vegas の3日目に行われたブレイクアウトセッション「 Transform meetings into outcomes using Google Workspace with Gemini 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 会議が抱える課題と Gemini による解決 会議における課題 会議の効率化とその実態 Gemini を活用した会議効率化の具体例 日程調整の自動化 会議中メッセージの自動保存 移動中の安全な会議参加 Take notes for me による議事録作成の自動化 Ask Gemini in Meet による言語の壁の排除 成果物の強化とチャットの継続 顧客事例 Air Liquide 社における導入成果 セッションの概要 当セッションでは、日々の業務における「会議」に焦点を当て、Google Workspace と Gemini がどのように会議を効率化し、より価値のあるアウトプットを生み出せるかが紹介されました。 会議が抱える課題と Gemini による解決 会議における課題 会議は業務で必要不可欠な一方、あらゆる課題が発生しています。当セッションでは会議における課題を以下表のように整理しました。 フェーズ 主な課題 会議前 カレンダーの重複による日程調整の負担、連続する会議による準備不足、事前情報の欠如。 会議中 議論からの逸脱や割り込み、議事録作成の負担、遅刻者への対応による議論の停滞。 会議後 決定事項やネクストステップの共有漏れ、会話内容消失からの再検討。 ハーバード・ビジネス・レビュー（Harvard Business Review）の調査によると、シニアマネージャーの 71% が「 会議は非効率である 」と回答しています。さらに、Atlassian の調査では従業員の 77% が「 会議は明確な結果を出さずに終わっている 」と報告しています。 会議の効率化とその実態 会議の効率化を促進するために、既存のインフラに後付けで AI ツールを導入する試みもありますが、これは結果的に ツールの断片化による管理コストの増加 と ライセンスコストの増加 を招きます。対して Google Workspace は、ユーザーが日常的に使用するツールに直接 AI を組み込んでいます。 Hypothesis Group の調査データによると、Gemini を統合した Google Workspace を使用している組織には以下のような効果が現れています。 全体的な生産性において 10% の優位性 競合他社（Microsoft 365）と比較して AI 投資に対する ROI が 15% 向上 Workspace ユーザーの 82% が AI 機能に価値を感じている Google Workspace 内のデータと連動するため、管理者が追加のセキュリティ設定を行わずとも、アクセス権限やデータ損失防止（DLP）ポリシーがそのまま維持される点も大きなメリットです。 Gemini を活用した会議効率化の具体例 日程調整の自動化 会議前の煩わしい作業を排除するため、Gemini を利用します。Google カレンダーでは参加者の予定を分析して最適な時間を提案できます。さらに、Gmail の Help me schedule 機能を使用すれば、メールのやり取りの中から直接カレンダーを参照し、インラインで会議の候補枠を提示・送信できます。 参考 : Gemini in Gmail で会議の時間を提案する 会議中メッセージの自動保存 会議が設定されると Continuous meeting chat 機能により、会議専用のチャットスペースが Google チャットに自動で立ち上がります。会議が始まる前にアジェンダや関連資料を共有しておくことで、参加者全員がコンテキストを理解した状態で議論をスタートできます。 参考 : Google Meet で Chat を使用する方法を学習する 移動中の安全な会議参加 移動中であってもシームレスに会議へ参加できるよう、Google Meet が車載システムに対応することが発表されました。 すでに Apple CarPlay には対応しており、近日中に Android Auto にも対応予定です。これにより、スマートフォンから車載のダッシュボードへ会議をシームレスに引き継ぎ、運転中もハンズフリーで安全に音声ベースの会議に参加できるようになります。 Take notes for me による議事録作成の自動化 会議中の最も大きな負担のひとつである議事録の作成も、Gemini に任せることができます。 Take notes for me 機能を開始するだけで、発言内容が Google Docs に自動的に整理され、サマリーやネクストステップが抽出されます。この機能は過去 1 ヶ月で 1億1000 万人のユーザーに利用されており、前年比 8.5 倍の成長を記録しています。 参考 : Google Meet の自動メモ生成 さらに議事録取得機能は Google Meet だけではなく、Android 向けの Google Meet アプリを開き、ホーム画面から Take notes for me をタップすることで、対面ミーティングや、他社ツール（Zoom や Microsoft Teams など）を使用したオンライン会議の音声であっても、端末のマイクを通じて録音し、Gemini に議事録を作成させることができます。 参考 : 対面会議で「自動メモ生成」を使用する Ask Gemini in Meet による言語の壁の排除 会議中に個人のアシスタントとして機能するのが Ask Gemini in Meet です。会議に遅れて参加した場合や、一瞬聞き逃してしまった場合に、「ここまでの議論の要点は何ですか？」と質問することで、他の参加者の議論を止めることなく状況をキャッチアップできます。 参考 : Google Meet の Gemini に相談 また Speech translation （リアルタイム翻訳）機能も提供されます。発言者の言語をリアルタイムで翻訳するだけでなく、発言者の「声のトーン」を維持したまま翻訳音声を生成するため、自然なコミュニケーションができます。 なお2026年4月現在、リアルタイム翻訳はまだ日本語に対応していません。 参考 : 音声翻訳について 成果物の強化とチャットの継続 会議が終了すると、Gemini は自動的に議事録のドキュメントを参加者全員にメールで共有します。今後のアップデート（2026年4月現在、アルファ版として提供）として、この議事録にはテキスト情報だけでなく、 会議中に画面共有された「プレゼンテーションスライドのスクリーンショット」も含まれる ようになります。これにより、会議を欠席したメンバーの視覚的な理解度が大幅に向上します。 また、会議前に作成された Continuous meeting chat は会議後も存続するため、決定事項に基づく後続のコミュニケーションをそのまま継続できます。 顧客事例 Air Liquide 社における導入成果 セッションの後半では、65,000 人以上の従業員を擁する産業ガスメーカー Air Liquide 社の CTO、Jeremy Gibbons 氏が登壇し、具体的な活用事例を共有しました。 同社はコンセンサスを重視する文化であり、Gibbons 氏自身も週に 35〜45 回の会議に参加しています。Gemini の導入による期待効果として、以下のような事例が挙げられました。 期待効果 詳細 全メンバーの会議参加 議事録の作成担当者が不要になったため、実質的に「会議に参加できる人数が1人増えた」ことと同義になり、全員が議論に集中できるようになりました。 多言語環境での意思疎通 グローバル企業において、全社員が英語に堪能とは限りません。 リアルタイム翻訳機能 が円滑なコミュニケーションの架け橋となっています。 業務プロセスの大幅な短縮 複数部門が妥協点を探る複雑な業務プロセス策定会議において参加者に徹底的に議論をさせた後、Gemini にその議論の要約とプロセス図の生成を依頼することで、数ヶ月に及ぶドキュメント作成期間を削減できました。 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 / 2026 ・Google Cloud 認定資格 7冠 ・Jagu'e'r エバンジェリスト Follow @arapote_tweet

G-gen の武井です。当記事では、Google Cloud Next '26 in Las Vegas のブレイクアウトセッション「 Built-in defense: The next evolution of Security Command Center for AI-era 」について、速報レポートをお届けします。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 プラットフォームネイティブなセキュリティの考え方 シフトダウン プリエンプティブなセキュリティとは何か SCC の新しい提供形態 SCC Standard 2.0（GA） SCC の6つの方針 開発者向けのセキュリティ機能 Day 0 と Day N の二軸で捉える Secure-by-Design Application-Centric AI・エージェント向けのセキュリティ機能 Built-in AI and Agent Security Agents are the new Insider Threat Built-in Security for Gemini Enterprise Agent Platform Model Armor によるインタラクションの保護 Google Cloud 全体のセキュリティ機能 Security & Compliance Gemini Cloud Assist による修復 セッションの概要 本セッションでは、 Security Command Center （以下、SCC）を中心とした Google Cloud のプラットフォームネイティブなセキュリティの進化と、AI・エージェント時代に向けた新機能が発表されました。 登壇者は Google Cloud の Abhishek Hemrajani 氏と Nav Jagpal 氏の2名です。前半で Abhishek 氏が「組み込み型プラットフォームセキュリティ」の考え方と新機能群を概観し、後半で Nav 氏が実際のコンソール画面を使ったデモを披露する構成でした。 参考 : Security Command Center overview プラットフォームネイティブなセキュリティの考え方 シフトダウン セッション冒頭で Abhishek 氏が打ち出していたのは、「 We must shift security left — actually, down 」というメッセージでした。 長らく語られてきたシフトレフトの発想を踏まえつつ、より的確に表現するなら、セキュリティを開発者の手前に寄せる（左に寄せる）のではなく、 プラットフォーム側に組み込むのが本質 であり、AI とエージェントの時代において、これまでのようにセキュリティをシステム開発の工程に組み込むアプローチではスケールしないと説明されていました。 プリエンプティブなセキュリティとは何か Abhishek 氏はセキュリティの成熟度を以下の3段階で整理していました。 段階 概要 Reactive （事後対応） 復旧や根本原因の特定を優先 Proactive （事前対応） インシデント化する前にリスクを特定・緩和 Preemptive （先制） 発生前にシステム自体を安全に設計し、問題を最小化 この発想を突き詰めたのが、SCC が目指す プリエンプティブなプラットフォームネイティブ・セキュリティ です。具体的な特徴として以下の3点が挙げられていました。 特徴 概要 Cloud Constructs Cloud IAM とポリシー構成要素を活用し、クラウドセキュリティ管理をシンプルにする Embedded Detections クラウドの挙動を継続的に監視する、専門的かつ組み込み型の検出テクノロジー No Daemons / Probes コレクター・デーモン・プローブ・ログ取り込みコストを排除し、TCO と運用の複雑さを削減 SCC の新しい提供形態 SCC Standard 2.0（GA） 新たに SCC Standard 2.0 が GA（一般公開）となりました。以下3点がハイライトとして示されています。 特徴 概要 すぐに使えて無料 すぐに利用可能。 SCC Premium の 30 日間無料トライアル もワンクリックで有効化できる 必須セキュリティがデフォルト有効 Data Security および Compliance に加えて、 AI とクラウドの必須セキュリティ がデフォルトで有効に コンテキスト内での検出結果表示 Cloud Hub ダッシュボードや Compute Engine、Google Kubernetes Engine（以下、GKE）などのコンソールに、セキュリティ検出結果が直接表示される SCC の6つの方針 SCC は、以下の6つ方針に沿って整理されています。すべての機能がコンテキストとアプリケーションを認識するよう設計されており、AI・エージェント型アプリとクラウドワークロードの双方をカバーします。 # 項目 概要 1 Identify （特定） Google Cloud アセットと IAM ポリシーのリアルタイムインベントリ、AI アセット（モデル、データ、エージェント、ツール、MCP サーバー）の自動探索、Cloud Run や GKE 上のエフェメラルワークロード検出 2 Prevent （防御） 175 以上の組み込みクラウドディテクター、構成の継続的検証、Mandiant CVE 情報と相関させた脆弱性可視化、過剰権限の特定と最小権限への移行 3 Detect （検出） 暗号資産マイニング、マルウェア、データ持ち出し、ネットワーク異常、不審なバイナリ、ID 関連リスク、攻撃ツール検出、ルートキット、バックアップ／DR の問題など、アクティブな脅威を検出 4 Find （発見） セキュリティグラフで既知リスクのコンテキストを相関、仮想的なレッドチーミングと攻撃パスシミュレーションで未知のリスクを発見 5 Discover （データ保護） 機密データの発見・分類、リテンションと暗号化を含むデータポスチャ管理、違反の自動監視と監査証跡の生成 6 Monitor （コンプライアンス監視） クラウド環境全体、選択リソース、主要プロジェクトでのコンプライアンス強制、標準への準拠状況の継続的な監視とレポート、監査証跡の生成 開発者向けのセキュリティ機能 Day 0 と Day N の二軸で捉える Abhishek 氏の整理では、開発者向けセキュリティは「 Day 0 で設計時にセキュリティを組み込み、Day N ではアプリケーションを認識した運用を行う 」というライフサイクルで捉えられていました。 Secure-by-Design Secure-by-Design がプレビュー公開されました。具体的には以下の3点が特徴として挙げられていました。 Application Design Center、App Hub、SCC に統合 アプリケーション設計ワークフロー内で プリエンプティブなセキュリティ評価 を直接実行 検出結果から実際のコード行までのリネージを追跡し、 SDLC （Software Development Life Cycle）全体でのセキュリティトレーサビリティを実現 なおセッションでは、プラットフォームチームと開発者がそれぞれ Application Design Center 上でフレームワーク適合状況を確認し、不合格項目に対して Gemini が修正案を自動生成してデプロイ前に対処する、という一連の流れがデモで示されていました。 参考 : Application Design Center overview Application-Centric SCC に Application-Centric が GA となりました。従来はインフラレベルで優先順位付きリストが提示されていましたが、脆弱性・ID・データ・AI セキュリティ・脅威のすべてを、重要アプリケーションのコンテキストで可視化できるようになります。 App picker : 脆弱性、ID、データ、AI セキュリティ、脅威の各画面をアプリケーション単位で切り替え App-aware nodes : 攻撃パスシミュレーションにアプリ認識ノードが加わり、アプリケーションとリソースを関連付けて分析 改善されたトレーサビリティ : アプリケーションアーキテクチャの設計意図が破られたときに追跡可能 アプリケーション中心の SCC がもたらす価値として、Abhishek 氏は以下の3点を挙げていました。 ビジネスインパクトによる優先順位付け : ビジネス優先度に基づいて、重要なアプリケーションのセキュリティリスクを切り分けて優先する 影響範囲の可視化 : アプリケーションと基盤リソースのつながりを可視化し、問題発生時にどこまで影響が及ぶかを把握できる 設計意図との整合性維持 : 検出結果のリネージを活用し、ランタイムで発見された問題の原因をソースコードまで遡って追跡できる AI・エージェント向けのセキュリティ機能 Built-in AI and Agent Security AI・エージェント向けセキュリティの中核となる柱として、以下の3点が整理されていました。 Agent Security Posture : Google が推奨するコントロールに基づく、Secure-by-Design で構築されたエージェント型アプリ Agent Asset Discovery : AI エージェント、アセット、機密データに関する組織全体インベントリ Agent Vulnerability Scanning : エージェントパッケージや Skills の脆弱性を特定 Agents are the new Insider Threat 以下のスライドを使い、 Agents are the new Insider Threat （エージェントは新たな内部脅威である）というメッセージが強調されていました。 人間が内部脅威になる理由は、悪意・強い不満・アカウント乗っ取りのいずれかですが、エージェントの場合はそのどれもなくても望ましくない挙動を取り得る、というのがその理由です。Abhishek 氏は、この課題に対処するアプローチとして以下 3 つを挙げていました。 領域 概要 Anomaly Detection エージェントの挙動と推論プロセスを分析し、リスクを特定して信頼を確立 Reputation and Fraud Defense AI を悪用した巧妙な不正や乱用への防御 Model Armor 入力プロンプトと出力レスポンスを審査し、モデルとのインタラクションを保護 Built-in Security for Gemini Enterprise Agent Platform Gemini Enterprise Agent Platform 向けの組み込みセキュリティが Preview 公開されました。SCC を基盤としており、以下 5 つの機能が提供されます。 コンプライアンスコントロールによるアセスメント エージェントと MCP ツールのエージェントレスな自動探索 イメージの脆弱性スキャンと設定ミス検出 ランタイムおよびコントロールプレーンの脅威検出 セキュリティグラフに基づくトキシックコンビネーション検出 Model Armor によるインタラクションの保護 Model Armor は、アプリケーションコードを一切変更せずに、AI モデルとのインタラクションをインラインで保護できる機能です。ユーザーから Agent、Agent から AI Model など、エージェントを中心としたすべてのインタラクションパスをカバーします。 また、現在 GA で利用できる検出器と、今後追加される予定の検出器は以下の通りです。 提供状況 検出器 概要 GA Content safety model 危険・有害なコンテンツ（性的、憎悪など）をブロック GA Sensitive data service テンプレートベースで PII データをマスキングもしくはブロック GA Prompt safety model プロンプトインジェクションやジェイルブレイクの試行を検出 GA Google AV and SafeBrowsing 悪意のあるファイルや安全でない URL をブロック Coming Soon Custom topics 組織のポリシーに基づくカスタムトピック検出器の作成 Coming Soon Allow/Deny lists 許可リストを使った false positive 管理 Coming Soon Custom rules engine プロンプトインジェクション／ジェイルブレイク検出用のカスタムルール 参考 : Model Armor overview なお、セッション内のデモでは、組織全体の AI アセットを俯瞰するインベントリ画面や、Cloud Run や GKE 上で開発者が独自に構築したエージェントの自動検出、サプライチェーン脆弱性やパイプライン侵害、Jupyter Notebook 内の認証情報漏洩といった AI 固有のリスクに対する攻撃パス可視化も紹介されました。 Google Cloud 全体のセキュリティ機能 Security & Compliance Cloud Hub で利用できる Security & Compliance がプレビュー公開されました。オブザーバビリティ、アプリケーションランタイム、信頼性、セキュリティのシグナルを一枚の画面で相関させられるため、クラウド環境全体の状況を横断的に把握できます。 Gemini Cloud Assist による修復 検出結果の修復を支援する Gemini Cloud Assist も紹介されていました。なお Gemini Cloud Assist は、Google Cloud に組み込まれた Gemini による補助機能です。コーディング補助サービスである Gemini Code Assist とは名称が似ていますが異なるものですので注意してください。 Nav 氏のデモでは、パブリック公開された Compute Engine インスタンスに OS 脆弱性が存在するトキシックコンビネーションを題材に、Gemini Cloud Assist が問題の詳細と攻撃パスを解説し、外部 IP の削除や VM の停止、外部トラフィックの制限といった修復オプションを提示する流れが披露されました。gcloud コマンドの実行と Terraform コードの出力の両方に対応しており、コマンドはログイン中のユーザーの IAM 権限で実行されるため、既存のアクセス制御をバイパスしない点も特徴です。 最終的には、攻撃パスの遮断、脆弱性の緩和、リスクスコアの低下、優先順位の更新までが数分以内に完結しました。Abhishek 氏は 「検出結果の 80% 以上は Gemini で修復可能」 という数字も紹介しており、修復作業のトイル（労力）削減への期待が強調されていました。 参考 : Gemini Cloud Assist overview 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

G-gen の荒井です。当記事は Google Cloud Next '26 in Las Vegas の1日目に行われたブレイクアウトセッション「 Fast-track to Google Workspace: Smooth migration, adoption, and interoperability 」の速報レポートをお届けします。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 データ移行の課題と新しいアプローチ 従来のデータ移行における課題と役割分担 Data Import の概要と利点 今後のロードマップ ロードマップの概要 Office 編集モード Google ドキュメント Google スプレッドシート Google スライド Google Apps Script（GAS） ドライブと SharePoint Chat、Meet、Teams 戦略の転換 パワーユーザー層へのアプローチと5つのユーザー層 Foundational（一般ユーザー） Analyst（分析者） Executive（経営層） Legal（法務） Ecosystems（エコシステム） セッションの概要 当セッションでは Google Workspace へスムーズに移行するための新しいアプローチとツールが紹介されました。具体的には、インフラストラクチャを必要としない新しいデータ移行ツール「 Data Import 」や、Gemini を活用した Microsoft Office ファイルの 相互運用性の向上 、そしてレガシーな マクロの変換機能 について解説されました。 これらの機能により、移行にかかるコストと時間を大幅に削減し、ユーザーの生産性を早期に高めることが期待できます。 参考 : データ インポート ツールについて  |  Data migration  |  Google Workspace Help データ移行の課題と新しいアプローチ 従来のデータ移行における課題と役割分担 従来のシステムから Google Workspace へ移行する際、移行作業は大きな障壁となります。従来のデータ移行プロセスにおいて直面しやすい主な課題は以下の通りです。 課題 詳細 時間とコスト 従来のオンプレミス型データ移行ツールでは移行ツールのライセンス費用や移行ツールを稼働させるインフラ基盤の費用が発生し、データ移行が高額になる傾向があります。 移行速度の遅延 移行は数ヶ月に及ぶプロセスとなることが多く、そのタイムラインからビジネスオペレーションに支障をきたす可能性があります。 エラーデータ 完璧な移行ツールは存在しないため、データ損失のリスクも発生します。また不完全なデータが存在する場合、パートナーや顧客が独自のスクリプトを作成したり手動で対応したりしなければならないケースもあります。 また移行プロジェクトを進めるにあたり、以下関係者による協力が不可欠です。 関係者 役割 お客様 プロジェクトの監督およびデータ移行作業だけでなく、新しいツール導入に関する運用ルールの策定やユーザー教育を主導。 パートナー 導入計画の策定やシステム設計などプロジェクトの管理。 Google 移行を容易にするガイダンス、テクニカルサポート、および包括的なデータ移行ツールの提供。大規模で複雑な移行には、Google のプロフェッショナルサービス組織が技術的監督やアーキテクチャ支援でパートナーをサポート。 Data Import の概要と利点 Google は、クラウドネイティブな新しいデータ移行システム「 Data Import 」を発表しました。仮想マシンやクラウドインフラの構築、インストールが不要なため、従来のデータ移行に比べコスト負荷が低減されます。 特徴 詳細 ゼロコスト クラウドネイティブツールであり、仮想マシンなど追加インフラコストなしで利用可能です。 包括的なデータ移行 メール、カレンダー、連絡先などのコアデータに加え、Outlook のルール、カレンダー設定、暗号化されたコンテンツ、Microsoft Teams などの多様なデータソースやメタデータも単一のツールで移行可能です。 管理性 管理コンソールに組み込まれ、シームレスにデータ移行を実行できます。 高速な移行 特に Exchange Online からの移行において、従来のデータ移行ツールの5倍の速度を実現します。 移行計画 ソースデータ（アカウント）のスキャンからデータに基づいた正確な予測に置き換えることが可能です。また移行完了までに必要な時間の見積り（タイムライン）を算出できます。 高いスケーラビリティ 1バッチあたり最大5,000ユーザー、最大10バッチを並行して実行でき、計50,000ユーザーの同時移行が可能です。 参考 : Google Workspace Updates: Introducing data import: An easier, faster, and higher-fidelity migration to Google Workspace at no additional tool cost 今後のロードマップ ロードマップの概要 Data Import は2026年4月現在、Exchange Online からの移行において一般提供されています。今後はさらにサポート対象を拡大し、より包括的なデータ移行を実現する予定です。 今後のロードマップは以下の通り計画されています。 Q2 （4月〜6月） Exchange Online への機能追加（In-place archives、グループメールボックス、タスク、暗号化 E メール等） OneDrive と Microsoft Teams がベータ版公開 Q3 （7月〜9月） OneDrive と Microsoft Teams が一般公開 SharePoint Online のベータ版および一般公開 GCC High 環境への対応 Office 編集モード Gmail での Office 編集 （Q2 にベータ版公開予定） Gmail 上で直接 Office ファイルを編集・返信できます。 Google ドキュメント 法務向けなどの機能強化 キャプション、相互参照、行番号、スモールキャップスなどをネイティブにサポートします。 Google スプレッドシート パフォーマンスとスケール向上 セルの制限数が従来の2倍（2,000万セル）に拡張されます。 高度な分析機能 ピボットテーブルやチャート機能が強化されます。 Google スライド 埋め込みメディアサポート （2026年6月頃にベータ版公開予定） PowerPoint からインポートした際の埋め込みオーディオやビデオをサポートします。 パフォーマンス向上 （2026年6月頃にベータ版公開予定） スライドの容量制限が従来の5倍に拡張されます。 Google Apps Script（GAS） 自然言語による VBA 変換 （2026年6月頃にアルファ版公開予定） 自然言語の指示でレガシーな Excel マクロを Google Apps Script（GAS）に変換し、Google スプレッドシートで使用できるようにします。 GAS のコアサービス化 （2026年6月頃に一般公開予定） GAS が Google Workspace のコアサービスに認定され、エンタープライズグレードの信頼性、セキュリティ、コンプライアンスを満たせるようになります。 自然言語でのデバッグ （2026年6月頃にアルファ版公開予定） GAS のエラー修正が、自然言語による対話形式で可能になります。 ドライブと SharePoint 承認機能 （2026年6月頃に一般公開予定） アプリを横断したワークフローを可能にする、軽量な承認機能が搭載されます。API も実装される予定です。 Workspace Studio （一般公開済み） AI ネイティブな自動化やエージェント作成が可能であり、Microsoft Power Automate の代替手段となり得ます。 Chat、Meet、Teams Meet ハードウェア相互運用性 （一般公開済み） 1タッチで Microsoft Teams や Zoom の会議に直接参加できます。 Chat のゲストアカウント （一般公開済み） 外部ユーザーをフル機能で Chat に招待しつつガバナンスを維持できます。 戦略の転換 パワーユーザー層へのアプローチと5つのユーザー層 これまで Google は「大多数のユーザーが使いやすいこと」を重視し、一部の高度な機能を使う「パワーユーザー」は Microsoft Office などの他社製品を利用し続ける傾向にあると分析していました。 しかし、Gemini の登場によって、この考えは大きく変わりました。パワーユーザー向けの機能開発において、Google は投資をこれまでの5倍に増やし、パワーユーザーが必要とするすべての機能を Google Workspace で提供する方針へと転換しました。 単に Microsoft の機能をそのまま真似るのではなく、 変更履歴 や グラフ作成 といった基本機能から根本的に作り直しています。具体的には、以下の5つのユーザー層に向けて機能を強化していく想定が述べられました。 Foundational（一般ユーザー） Analyst（分析者） Executive（経営層） Legal（法務） Ecosystems（エコシステム） Foundational（一般ユーザー） メールで Office ファイルを共同編集するにあたり「Outlook と Word」よりも「Gmail と Google ドキュメント」の組み合わせが一番使いやすい状態を目指します。 Analyst（分析者） Google スプレッドシートのパフォーマンスを向上させ、分析者や財務部門が求める高度なデータ分析を可能にします。 パフォーマンスとスケール セルの制限数を従来の2倍（2,000万セル）に拡張（2026年4月現在、ベータ版公開済み）。さらに将来的に再度2倍にする計画があります。 高度な分析機能 ピボットテーブルやチャート機能を強化します。 Executive（経営層） Google スライドを強化し、経営層が求めるレベルの高いプレゼンテーション資料の作成に対応します。 スライドの容量制限の拡張 スライドの容量制限を従来の5倍に拡張します。 埋め込みメディアサポート Microsoft PowerPoint からインポートした際の埋め込みオーディオやビデオをシームレスにサポートします。 Legal（法務） Google ドキュメントで、法務部門に必須の厳格な文書フォーマットを完全に再現できるようにします。 法務向けフォーマット キャプション、相互参照、行番号、スモールキャップスなどをネイティブにサポートし、Word ファイルとの完璧なラウンドトリップ（Google ドキュメントで編集したデータを Microsoft Word で開いても、データやレイアウトが損なわれないことを指す）を保証します。 変更履歴の再設 2026年末までに、Microsoft Word との相互運用性を損なうことなく、変更履歴機能を根本的に再設計します。 Ecosystems（エコシステム） 外部システムと直接連携できるようにし、Microsoft 365 から Google Workspace に移行しても、これまでの業務フローを変えずに作業できるようにします。 SAP、Oracle、Litera、ServiceNow、Workday などのサードパーティ製エコシステムに、Google ドキュメント、スプレッドシート、スライドを直接組み込みます。 これらの進化により、組織の Google Workspace への移行と定着、そして新しい働き方へのトランスフォーメーションがこれまで以上に加速することが強調されました。 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 / 2026 ・Google Cloud 認定資格 7冠 ・Jagu'e'r エバンジェリスト Follow @arapote_tweet

G-gen の武井です。当記事は Google Cloud Next '26 in Las Vegas のブレイクアウトセッション「 One tool to rule them all: Extending and customizing the Gemini CLI 」について、速報レポートをお届けします。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 AI 開発ツールが抱える 3 つの課題 Gemini CLI と拡張ポイント Gemini CLI とは 拡張ポイントの全体像 John のジャーニーで見る Gemini CLI 拡張デモ 1. 組み込みツールによるコードベースの探索 2. Agent Skills で専門知識をパッケージ化する 3. Sub-agents でコンテキストを分離する 4. Extensions でカスタマイズをチームに共有する Extensions Gallery によるコミュニティ連携 セッションの概要 本セッションでは、ターミナル上で動作する AI エージェント Gemini CLI を、開発者個人のワークフローに合わせてカスタマイズし、さらにそのカスタマイズをチームやコミュニティへ共有するための拡張ポイント（Agent Skills、Sub-agents、Hooks、Extensions）について解説していました。 登壇者は Google Cloud の Aishanee Shah 氏と Abhi Patel 氏の2名です。座学だけでなく、John という架空の開発者が Gemini CLI のコードベースをキャッチアップし、得られた知見を共有可能なパッケージにまでまとめ上げるジャーニーを題材に、ライブデモを交えて段階的に紹介する構成です。 参考 : Gemini CLI - Google Cloud Gemini CLI の詳細な解説については、以下の記事を参照してください。 blog.g-gen.co.jp AI 開発ツールが抱える 3 つの課題 近年の AI モデルはコーディング、コードベース探索、リサーチに非常に強くなった一方、その周辺ツール（Web 上の AI チャット、IDE、CLI ツールなど）が急増した結果、開発者がそれらの間を伝書鳩（messenger pigeons）のようにつないでいる現状が指摘されました。 Abhi 氏自身、Chrome チームに在籍していた頃、エラーやスタックトレースを Web の Gemini チャットへコピー＆ペーストし、結果をまた IDE に戻す、という非効率な作業に多くの時間を費やしていたとのことです。 セッションでは、こうした現状から派生する課題が 3 つに整理されていました。 1つ目は テクノロジーの孤島 （tech islands）です。Web アプリ、IDE、CLI ツールが乱立しているなかで、それらをいかに効果的に組み合わせるかという問題を指します。 2つ目は 認知的過負荷 （cognitive overload）です。プロンプトの構造設計や適切なコンテキストの収集を、ユーザー側が常に意識しながら組み立てる必要があるという課題です。 3つ目は 車輪の再発明 （reinventing the wheel）です。完璧なプロンプトやワークフローを構築できたとしても、それをチームや組織全体で共有・再利用する手段がなければ、各々が同じ努力を繰り返すことになります。 これらの課題を解決する鍵として、複数のツールとコンテキストを束ねる オーケストレーター が必要であり、その役割を担うのが Gemini CLI である、というのがセッションの出発点として提示されました。 Gemini CLI と拡張ポイント Gemini CLI とは Gemini CLI は、ターミナル上で動作するオープンソースの AI エージェントです。最先端の Gemini モデルへの軽量かつ直接的なアクセスを提供し、開発者が指定したゴールに向けてコンテキストを収集・維持しながらタスクを実行します。詳細は以下を参照してください。 参考 : Gemini CLI - Google Cloud 参考 : Gemini CLIを解説 - G-gen Tech Blog 拡張ポイントの全体像 セッションでは、Gemini CLI を自分のワークフローに合わせて深くカスタマイズする手段として、以下 4 つの拡張ポイントが紹介されました。 Agent Skills （エージェントスキル） : 専門知識・手続きワークフロー・関連リソースをひとまとめにしたモジュール Sub-agents （サブエージェント） : 特定タスクに特化した独立エージェント。コンテキストとツール選択をメインエージェントから分離する Hooks （フック） : エージェントのライフサイクル上の任意のタイミングに介入するための設定可能なポイント Extensions （エクステンション） : Skills、Sub-agents、Hooks、コマンド、MCP サーバー、コンテキストファイルなどを 1 つの共有可能なパッケージにまとめる仕組み Aishanee 氏は「2026 年の開発者は、こうしたカスタマイズの作り込みとメタワークフローの構築に多くの時間を使っている」と述べ、AI 時代の開発者の作業の重心が、自らコードを書くことから、エージェントツール群の設計・編成へとシフトしていることを強調していました。 John のジャーニーで見る Gemini CLI 拡張デモ 1. 組み込みツールによるコードベースの探索 John はまず、Gemini CLI のリポジトリをクローンしたうえで、ターミナルから Gemini CLI を起動し、自然言語で「サブエージェントの委譲（sub-agent delegation）がどう動くのか理解したい」と尋ねます。 ここで Gemini CLI は 思考モード （thinking mode）に入り、組み込みツールを使って必要なファイルを段階的に読み込みます。1つ目のファイルを読んで把握、必要な情報を絞り込んで次のファイルを読む、という形で探索を進め、最終的に Markdown 形式の要約を返しました。 John は視覚的に理解したいタイプなので、続けて「フローチャートに変換して」と依頼します。すでに直前の探索で十分なコンテキストを集めているため、追加のファイル読み込みなしに、ターミナル内に ASCII アートのフローチャートが描画されました。 ここまでが、 組み込みツールだけで実現できる「単発の探索」 です。一度きりのコードリーディングや、ざっと全体像をつかみたい場面には十分強力ですが、生成された図をチームメイトと共有したい・設計ドキュメントに貼り付けたい、といった次の段階には不向きです。 2. Agent Skills で専門知識をパッケージ化する そこで登場するのが Agent Skills （エージェントスキル）です。Agent Skills は、専門知識・ワークフロー・スクリプトをまとめたモジュール式の自己完結パッケージで、エージェント向けの作業手順書のような位置づけのものです。Agent Skills の構造は単純で、以下のようなディレクトリで成り立ちます。 skill.md : 必須ファイル。YAML フロントマターでスキルの name と description を定義し、Markdown 本文にエージェントへの指示を記述する references/ : 補助的な参考資料を置く任意ディレクトリ scripts/ : 検証や変換などに使うスクリプトを置く任意ディレクトリ 特に重要なのは skill.md の description フィールドです。これは カタログ上の説明文 として機能し、メインエージェントは多数のスキルの中からこの description を読んでどれを呼び出すか判断します。 スキルが実際に呼び出されたタイミングではじめて、Markdown 本文の指示や参照ファイルの中身がコンテキストにロードされる仕組みです。これによりメインエージェントのコンテキストを過剰に汚染することなく、必要な専門知識を ジャストインタイム で投入できる点が肝になります。 デモでは、John があらかじめ用意していた Mermaid 作図用のスキルを、Gemini CLI に再ロードさせて使用します。直前の探索で集めたコンテキストはセッションに残っているので、John が「Mermaid の図を作って」と指示するだけで、エージェントはカタログから Mermaid スキルを発見・起動し、ファイルを生成しました。 ここで興味深いのが、Mermaid スキルには png ファイルへの変換スクリプトと生成されたファイルが破損していないかを検証するスクリプトまでバンドルされていた点です。スキル単体で Mermaid ソースの生成 > png ファイルへの変換 > 検証 までを完結させており、最終的には共有可能な2つのファイルを得ることができました。 Aishanee 氏はこの設計について、 自分がすでに解いた問題に毎回トークンを消費させるのではなく、一度作って・バンドルして・再利用する という思想を強調していました。 3. Sub-agents でコンテキストを分離する スキルは強力ですが、ワークフローが長く・複雑になるにつれて限界も見えてきます。スキルを呼び出すたびに、その参照ファイルや手順がメインエージェントのコンテキスト（記憶）に挿入されるため、複数のスキルをまたぐ作業では情報が断片化し、過負荷に陥ってしまうのです。たとえば「Mermaid 図の生成と検証」のような専門タスクの細部がノイズとなり、本来の目的である探索タスクの邪魔をしかねません。 そこで真価を発揮するのが Sub-agents （サブエージェント）です。 サブエージェントは、特定のタスクに専念する独立したエージェントです。メインエージェントとは明確に分離された「独自のコンテキスト」と「専用のツールセット」を持ちます。タスクが完了すると、サブエージェントは「最終結果」と「次に繋がる最も価値の高い情報」だけを抽出してメインエージェントに返却します。これにより、 メインのセッションを常にクリーンな状態に保つ ことができます。 サブエージェントを構成する中核要素は、特定の役割を与える「 ペルソナ （システムプロンプト）」と、それに最適化された「 ツールセット 」の2つです。Abhi 氏も紹介しているように、CLI には組み込みのサブエージェントとして Codebase Investigator などが用意されています。これは、新機能の調査時などに発生する「長大なコードベースの探索」という重い処理を、メインの思考プロセスから切り離し、独立したコンテキストに閉じ込めるために生まれたものです。 カスタムサブエージェントにはローカル型とリモート型の2種類があります。ローカル型は Gemini CLI の組み込みツール（read、grep、skills など）を直接利用するもので、リモート型は A2A プロトコルに対応した既存エージェントへ接続するもので、クラウド側のエージェントを呼び出す用途に有効です。 サブエージェントの定義ファイルは、設定を記述するフロントマター（YAML 形式など）と、システム指示を記述する Markdown 本文から構成されます。フロントマターには name、description、tools（許可するツールのリスト）、model（使用するLLM）などを定義します。 ここで最も重要なのが description の質 です。メインエージェントは、この説明文を頼りに「 暗黙的な呼び出し （Implicit invocation）」を行います。説明が貧弱だと、メインエージェントは「いつ、どのタスクを委譲すべきか」を正しく判断できないため、役割と発動条件を明確に記述することがサブエージェントを使いこなす最大の肝となります。 また、サブエージェントごとにツールを厳格に制限できるのも大きな利点です。例えば「Codebase Investigator」では、ファイルを意図せず書き換えないよう、許可ツールを読み取り系（Read-only）のみに絞り込んでいます。 さらに発展的な設計として、サブエージェントの定義内に MCP（Model Context Protocol）サーバーをインライン化することも可能です。たとえば、50を超える機能を持つ Google Workspace の MCP ツール群を特定のサブエージェント内に閉じ込めることで、メインエージェントのコンテキストを汚染せずに高度な外部連携を実現できます。Abhi 氏はこのアーキテクチャの利点を「メインエージェントを context rot （コンテキストの腐敗。不要な情報やツールによってコンテキストが劣化すること）から守る手段」と強調していました。 デモでは、John が Mermaid スキルとアーキテクチャ図作成を1つにまとめた architect-visualizer というサブエージェントを事前に作成しておき、 @architect-visualizer のように @ 構文で呼び出していました。 新規セッションから始めても、サブエージェントは自身のシステム指示に従って Mermaid スキルをアクティブにし、必要に応じて何度もコードベースを読み返しながら 正確性を担保するためのダブルチェック を行います。これらのファイル読み込みはサブエージェントのコンテキストに閉じ込められ、メインエージェントには ASCII の図と最終ファイルの場所だけが返却されました。 4. Extensions でカスタマイズをチームに共有する ここまでで作成した Skills と Sub-agents は、いまだ John の手元のローカルにあるだけです。チームに展開し、社内全体で再利用するためには Extensions （拡張機能）でパッケージ化します。 Extensions は、Skills、Sub-agents、Hooks、コマンド、MCP サーバー、コンテキストファイル（ gemini.md 、 claude.md 、 agents.md など）を一括で 1 つの共有可能なディレクトリにまとめる仕組みです。最低限、以下が揃っていれば成立します。 gemini-extensions.json （マニフェストファイル） 共有したい Skills / Sub-agents / Hooks / コマンド / MCP サーバーの定義 エージェント側に「いつ・どう使うか」を伝えるためのコンテキストファイル なお Hooks は、エージェントのライフサイクルにおける任意の介入ポイントを設定する仕組みで、Google 社内でも独自機能を解放する目的で使用されているとのことでした。 ドキュメントを読み込んでマニフェストを手書きするのは煩雑です。そこでデモでは、Gemini CLI に同梱されている組み込みサブエージェント cli_help agent を @ 構文で呼び出し、対話的に Extension を組み立てるという画期的なアプローチが紹介されました。 cli_help agent は、ドキュメントを参照してマニフェスト構造を理解した上で、組み込みの ask user ツール（ユーザーに質問を投げかける機能）を使用します。これにより、「どんな拡張機能を作るか」「どのスキルを含めるか」「どのサブエージェントから呼び出すか」を順番に確認してくれます。 ユーザー（John）は、「Mermaid スキルとアーキテクチャ図のサブエージェントを含む architecture-visualizer 拡張を作りたい」といった自然言語で答えるだけでよく、必要な JSON やコンテキストファイルはすべて自動で生成されました。 完成した Extension の配布方法は、ユースケースに応じて使い分けられます。誰でも利用できる形で公開する場合は、パブリックな Git リポジトリで配布します。一方、機密性の高いプロンプトや MCP サーバーを社内限定で配布したい場合は、プライベートリポジトリやローカル共有フォルダを使った セキュアディストリビューション を取ります。Abhi 氏は、Google 社内では各チームが独自の Extension を作成し、それを社内に広く共有する文化が根付いていると紹介していました。 Extensions Gallery によるコミュニティ連携 最後に紹介されたのが、コミュニティ全体で Extension を発見・共有できる Extensions Gallery です。2026年4月現在、数百規模の Extension が公開されており、Googler が開発した BigQuery や Google Workspace の Extensions から、サードパーティ企業が自社製品向けに公開している Extensions まで、幅広く利用できます。 ここで強調されていたのは、ギャラリー内の各 Extensions も、本セッションで紹介された仕組みの組み合わせに過ぎないという点でした。同じ部品を組み合わせて掛け算的にスケールさせ、コミュニティ全体で共有していく、というのが Gemini CLI の Extensions の構想の本質と言えそうです。 参考 : Extensions - Gemini CLI 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

G-gen の佐々木です。当記事では、Google Cloud Next '26 で発表された Google Cloud のデータベースに関する新機能について、公式の投稿記事「 What’s new with Databases: Powering the agentic future 」の内容をもとに紹介します。 はじめに Embed AI into every layer of the data stack AI Studio とのバイブコーディング連携（GA） データエージェント向けツール（Preview） Database Onboarding Agent / Database Observability Agent（Preview） AlloyDB AI-Powered Search at Scale（Preview） AlloyDB の AI 関数の追加と最適化（Preview） データベース向けマネージドリモート MCP サーバー（GA / Preview） MCP Toolbox for Databases 1.0（GA） Break down walled gardens with lakehouse integrations AlloyDB の Lakehouse Federation（Preview） BigQuery から AlloyDB への Reverse ETL（Preview） Datastream による継続レプリケーション（GA） Knowledge Catalog（旧称 : Dataplex Universal Catalog）（Preview） Spanner Columnar Engine（GA） Database Center の BigQuery サポート（Preview） Commitment to open data and multi-cloud flexibility Spanner Omni（Preview） Bigtable In-Memory（Preview） Memorystore for Valkey 9.0（GA） Oracle AI Database@Google Cloud の拡張 Compute Engine からマネージドサービスへの移行機能（Preview） Firestore の全文検索 / 地理空間検索（Preview） はじめに 以下の Google 公式投稿を参考に、Google Cloud Next '26 で発表された Google Cloud のデータベース製品に関する新機能を紹介します。なお、当記事で紹介する機能の提供ステータス（GA / Preview / Coming Soon）は 2026年4月23日現在の情報です。 Google Cloud Next '26 では、AI モデル、データ分析、運用データベースを単一の AI ネイティブ基盤に統合するアーキテクチャとして Agentic Data Cloud が提唱されました。当記事では以下の公式投稿の内容に沿って、データベースに関する新機能を紹介します。 参考 : What’s new with Databases: Powering the agentic future 他の Google Cloud Next '26 の関連記事は、Google Cloud Next '26 カテゴリの記事一覧から参照してください。 blog.g-gen.co.jp Embed AI into every layer of the data stack AI Studio とのバイブコーディング連携（GA） Google AI Studio とデータベースの統合が GA となり、自然言語プロンプトから、データベースと接続済みで即座に動作するアプリケーションを数秒で生成できるようになりました。現時点では Firestore との接続が GA で提供されており、Cloud SQL for PostgreSQL のサポートも近日提供予定とされています。 プロトタイピングから本番運用まで、エージェント主導の自動化ワークフローとデータベースをシームレスに接続できる点が特徴です。 参考 : From prompt to production: Build full-stack apps faster with Google AI Studio and Firebase データエージェント向けツール（Preview） AlloyDB、Cloud SQL、Spanner で、データエージェントから使えるツール群が Preview 提供となりました。その中核となる QueryData ツールは、自然言語から SQL を生成する text-to-SQL を扱う機能で、公式ブログでは「ほぼ100%の精度」と説明されています。 QueryData は、 コンテキストセット と呼ばれる JSON 形式のナレッジベースを利用する点が、従来の汎用的な text-to-SQL との違いです。開発者があらかじめ監査・整備したコンテキストセットを参照してクエリを組み立てるため、LLM に自由生成させる方式と比べて、実データや業務要件に即したクエリを安定して生成できます。 また QueryData からデータへのアクセスは、 パラメータ化セキュアビュー （Parameterized Secure Views）を介して行われます。パラメータ化セキュアビューは、 PostgreSQL のセキュアビューの拡張機能であり、行レベルセキュリティやフィルタ条件をビュー側にあらかじめ組み込んでおける機能です。エージェントが自然言語から組み立てたクエリであっても、ログインユーザーに許可された範囲のデータだけが参照される状態を保つことができます。 カスタマーサポートの自動化、e コマースのショッピングアシスタントなど、定型的な問い合わせが大量に発生するユースケースでの利用が想定されています。 参考 : QueryData helps agents turn natural language into queries for AlloyDB, Cloud SQL and Spanner 参考 : QueryData の概要 参考 : パラメータ化されたセキュアなビューの概要 Database Onboarding Agent / Database Observability Agent（Preview） データベースの導入と運用を支援する2つのエージェントが Preview 提供となりました。 Database Onboarding Agent は、小規模システムからエンタープライズ要件まで、要件に応じた最適なデータベースを選択し、プロビジョニング作業をガイドするエージェントです。 Database Observability Agent は、AlloyDB、Bigtable、Cloud SQL、Spanner のパフォーマンスを監視し、潜在的な問題の根本原因の特定や、改善策の提示を行うエージェントです。運用中のデータベース群の観測と改善を自動化する機能となっています。 AlloyDB AI-Powered Search at Scale（Preview） AlloyDB のベクトル検索基盤に、Google が開発した ScaNN インデックスを活用した大規模ベクトル検索機能が Preview 提供となりました。最大100億ベクトルまでスケールし、標準 PostgreSQL の HNSW インデックスとの互換性を実現しながら6倍高速なベクトルクエリを実現します。また、カラム型エンジンによる高速化により、HNSW を使用する場合でも標準 PostgreSQL の4倍高速になります。 加えて、キーワード検索とベクトル検索を組み合わせたハイブリッド検索を可能にする BM25 のネイティブサポートも近日追加予定です。BM25 は Elasticsearch をはじめとする主要な検索エンジンで広く採用されている、単語の一致を基準に関連度を算出するキーワード検索のランキングアルゴリズムです。固有名詞や厳密な語句一致が得意な BM25 と、意味の近さを捉えるベクトル検索を1つのデータベース上で組み合わせられる点が特徴です。 参考 : ベクトルインデックスの概要 参考 : Okapi BM25 - Wikipedia AlloyDB の AI 関数の追加と最適化（Preview） AlloyDB に、SQL から直接 LLM を呼び出せる新しい AI 関数が Preview 提供となりました。 新規に ai.analyze_sentiment （感情分析）、 ai.summarize （要約）が追加され、既存の ai.if 、 ai.rank 、 ai.generate 、 ai.forecast についても最適化が施されています。各関数の用途とユースケースを以下にまとめました。 AI 関数 用途 ユースケース例 ai.if 自然言語による条件判定（インテリジェントフィルタリング） 振る舞いパターンから不正の疑いがある取引を検出 ai.rank ベクトル検索結果の再ランク付け 文脈に即して検索結果を並べ替え ai.generate コンテンツ生成、データフォーマット変換 生のサーバーログを解析しやすい JSON へ変換 ai.analyze_sentiment テキストの感情（ポジティブ / ネガティブ / ニュートラル）を分類 商品レビューから顧客満足度を評価 ai.summarize 長文テキストの要約 議事録から決定事項やアクションアイテムを抽出 ai.forecast TimesFM による時系列予測 過去の売上データから将来の在庫需要を予測 参考 : AI 関数の概要 参考 : AI 関数を使用してインテリジェントな SQL クエリを実行する データベース向けマネージドリモート MCP サーバー（GA / Preview） Google Cloud の各データベースで、 Model Context Protocol （MCP）に対応したフルマネージドのリモート MCP サーバーが提供開始となりました。Gemini をはじめとする MCP 準拠のクライアントが、データやインフラストラクチャと安全にやり取りするためのインターフェースを提供します。 参考 : Powering the next generation of agents with Google Cloud databases MCP サーバーの提供ステータスはサービスにより異なるため、最新のステータスは以下の公式ドキュメントの原文（英語）をご確認ください。 参考 : Supported products Google Cloud が提供している MCP サーバーの詳細については、以下の記事を参照してください。 blog.g-gen.co.jp MCP Toolbox for Databases 1.0（GA） MCP Toolbox for Databases は、AI エージェント、IDE、アプリケーションといった MCP クライアントからデータベースに直接接続するための、オープンソースの MCP サーバーです。Gemini CLI や Claude Code などの MCP 準拠クライアントから、Google Cloud のマネージドデータベースに加え、PostgreSQL、MySQL、Oracle、MongoDB、Redis、Snowflake など、合計40以上のデータベースを扱えるようにします。 テーブル一覧の取得（ list_tables ）や SQL 実行（ execute_sql ）といった汎用ツールがデフォルトで利用できるほか、独自のロジックをカスタムツールとして定義することで、エージェントが実行可能な操作をあらかじめ限定できます。 参考 : googleapis/mcp-toolbox（GitHub） Break down walled gardens with lakehouse integrations AlloyDB の Lakehouse Federation（Preview） AlloyDB から BigQuery や Apache Iceberg のライブデータを、PostgreSQL のインターフェースで直接照会できる Lakehouse Federation が Preview 提供となりました。 AlloyDB Studio の UI から BigQuery や Iceberg のテーブルを探索でき、フィルタや集計は BigQuery 側にプッシュダウンされます。データを移動せずに、オペレーショナルデータと分析データのライブ結合が可能です。 BigQuery から AlloyDB への Reverse ETL（Preview） BigQuery で算出したインサイト（顧客セグメント、レコメンドスコア、需要予測など）を、AlloyDB にワンクリックで同期できる Reverse ETL 機能が Preview 提供となりました。 アプリケーションから BigQuery を直接参照するのは、レイテンシや同時実行数、コストの観点で現実的でないケースが少なくありません。あらかじめ BigQuery で計算しておいたインサイトを AlloyDB に戻しておけば、アプリは普段通り AlloyDB を参照するだけで、分析結果を画面表示やレコメンドなどのリアルタイム機能に組み込めます。 同期先の AlloyDB は、読み取りを高速化するカラム型エンジンと高速キャッシュによって、多数の同時リクエストに低レイテンシで応答できるアプリケーションバックエンドとして機能します。 参考 : AlloyDB にデータをエクスポートする（リバース ETL） Datastream による継続レプリケーション（GA） Datastream を介して、AlloyDB から BigQuery や Apache Iceberg テーブルへ 継続的レプリケーション を行える機能が GA となりました。 Datastream はサーバーレスで動作し、特に AlloyDB から BigQuery へのストリームには無料枠が提供されます。リアルタイムの ML 特徴量生成など、分析側との連携を前提としたユースケースに適しています。 参考 : ストリームの作成 Knowledge Catalog（旧称 : Dataplex Universal Catalog）（Preview） データガバナンス サービスである Dataplex Universal Catalog が、 Knowledge Catalog へ名称変更されました。Dataplex Universal Catalog は、BigQuery のテーブルや Cloud Storage 上のファイルなど Google Cloud 上のデータ資産に対して、メタデータ、データ品質、リネージ、アクセス制御を一元的に扱えるサービスです。 名称変更に合わせ、AI エージェントがデータの業務的な意味を踏まえて動けるようにするための「コンテキストエンジン」としての機能が Preview 提供となりました。Google Cloud の製品だけでなく、パートナーのデータプラットフォームやサードパーティカタログからも情報を取り込み、組織横断のデータガバナンスの起点として機能します。 Knowledge Catalog の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Spanner Columnar Engine（GA） Spanner Columnar Engine が GA となりました。行ベースのストレージと並行して列指向フォーマットでデータを保持し、複数行をまとめて処理するベクトル化実行を組み合わせることで、稼働中のトランザクションデータに対する集計・分析クエリのスキャンを最大200倍高速化するとされています。 また、Iceberg テーブルのサポートや、BigQuery からの継続的な Reverse ETL、フェデレーションクエリの高速化にも対応したことで、Spanner を単独で HTAP （Hybrid Transactional/Analytical Processing）的に使える範囲が広がりました。HTAP は、トランザクション処理（OLTP）と分析処理（OLAP）を、ETL を介さずに1つのデータベースで兼ねるアーキテクチャを指す用語です。 参考 : Spanner カラム型エンジンの概要 Database Center の BigQuery サポート（Preview） Database Center は、Google Cloud のデータベースサービスを横断して、フリート全体の健全性、パフォーマンス、セキュリティ、コンプライアンスを一元的に可視化・管理する管理コンソールです。 この Database Center での BigQuery サポートが Preview 提供となりました。これにより、Google Cloud のマネージドデータベースや Compute Engine 上で運用しているデータベースに加えて、BigQuery も一元的に扱えるようになります。 Gemini によるフリートアナリティクスによってパフォーマンス改善の余地を検出できるほか、メトリクスをサードパーティツールへ連携するための API とマネージド MCP サポートも提供されます。 参考 : Database Center の概要 Commitment to open data and multi-cloud flexibility Spanner Omni（Preview） Spanner Omni が Preview 提供となりました。Spanner Omni は、従来 Google Cloud 上でのみ提供されていた Spanner を、自社データセンター、他クラウド、エッジなど任意の場所で稼働できるダウンロード可能なエディションです。 Spanner のスケーラビリティ、高可用性、強整合性、エンタープライズセキュリティ、マルチモデル機能を、自社データセンターや他クラウドなどの環境でも利用できるようになります。 参考 : Spanner Omni を発表：あらゆるインフラで Google のイノベーションを活用 参考 : Spanner Omni の概要 Bigtable In-Memory（Preview） Bigtable に、1ミリ秒未満の読み取りレイテンシを実現する新しい インメモリ階層 が Preview 提供となりました。Bigtable は2026年4月から Enterprise と Enterprise Plus の2つのエディションを提供しており、このインメモリ階層は Enterprise Plus エディションの一部として提供されます。 インメモリ階層は Bigtable ノードの一部として統合されており、RAM / SSD / HDD のハイブリッド ストレージアーキテクチャによって、頻繁にアクセスされるホットデータをメモリに、長期保管データを低コストストレージに置く、といった使い分けが透過的に行えます。 参考 : エディションの概要 参考 : インメモリ階層の概要 Memorystore for Valkey 9.0（GA） Memorystore for Valkey が Valkey バージョン 9.0 に対応しました。Memorystore 以外で独自に運用している Redis や Valkey を Memorystore へ移行するためのパスも提供されます。 また、選べるノードサイズに小型と大型が加わり、ワークロードの規模に応じて性能とコストのバランスを取りやすくなりました。ブルームフィルタを提供する valkey-bloom 、JSON ドキュメントをネイティブに扱える valkey-json といったモジュールへの対応や、ACL、トークンベース認証、柔軟な認証局設定などのエンタープライズレベルのセキュリティ機能も整備されています。 参考 : Memorystore for Valkey の概要 Oracle AI Database@Google Cloud の拡張 Oracle AI Database@Google Cloud の提供が20リージョンまで拡大しました。なお、東京リージョンは2025年6月に対応済みです。 加えて、 Oracle GoldenGate Service のサポートが追加され、Oracle DB から BigQuery へのニアリアルタイムなデータレプリケーションが可能になります。さらに、前述の Knowledge Catalog（旧称 : Dataplex Universal Catalog）および Database Center との統合も発表されました。 参考 : Oracle Database@Google Cloud overview Compute Engine からマネージドサービスへの移行機能（Preview） Compute Engine 上で自前運用している PostgreSQL などのデータベースを、Cloud SQL や AlloyDB といったマネージドサービスへ移行できる機能が Preview 提供となりました。移行フローは Database Center にネイティブに統合されており、Database Center の画面からそのまま移行を開始できます。 PostgreSQL 向けにはネットワーキングとレプリケーションが自動化されており、最小限の作業とダウンタイムで移行できる点が特徴です。 Firestore の全文検索 / 地理空間検索（Preview） Firestore で 全文検索 および 地理空間検索 機能が Preview 提供となりました。これまで別サービスと組み合わせる必要があった検索機能が、Firestore 単体でサーバーレスに提供され、キーワード / フレーズ / 地理空間クエリに対して高い関連度で応答できます。 参考 : Use text searches 参考 : Use geo queries 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の佐々木です。当記事では、Google Cloud Next '26 で発表された BigQuery に関する新機能について、公式の投稿記事「 What’s new in BigQuery: Powering the Agentic Era 」の内容をもとに紹介します。 はじめに Open, cross-cloud lakehouse Managed Iceberg Tables（GA） Iceberg REST Catalog の読み書き相互運用性（Preview） Cross-Cloud Lakehouse（Preview） Catalog Federation（Preview） リアルタイムデータレプリケーション（GA / Preview） Graph-based reasoning for enterprise agents BigQuery Graph（Preview） BigQuery Graph におけるメジャーのネイティブサポート（Preview） BigQuery Conversational Analytics におけるグラフサポート（Preview） BigQuery Graph と Looker の統合（Preview） BigQuery Studio での視覚的なモデリング機能（Preview） Native AI processing to unlock structured and unstructured data AI.PARSE_DOCUMENT（Preview） TabularFM（Preview） ObjectRef（GA） AI 連携関数の最適化モード（Preview） BigQuery ネイティブの Gemma エンベディング（Preview） 自律型エンベディング生成（GA） BigQuery Hybrid Search（Preview） Python UDF（GA / Preview） コネクテッドシートにおける TimesFM モデルの利用（GA / Preview） Geospatial Analytics Datasets（Preview） Agentic experiences BigQuery における Conversational Analytics（GA / Preview） Proactive Agentic Workflows（Preview） BigQuery Agent Analytics（GA / Preview） BigQuery Studio の新機能群（GA / Preview） データサイエンスエージェント（GA） Colab Data Apps（Preview） BigQuery Remote MCP Server（GA） BigQuery ADK Toolset（GA） Google Cloud Data Agent Kit（Preview） Unparalleled performance and scale Fluid Scaling（GA） 高度なランタイム、小規模クエリ、履歴ベースの最適化（GA） 新しいワークロード管理機能（GA / Preview） 可観測性の向上（GA / Preview） はじめに 以下の Google 公式投稿を参考に、Google Cloud Next '26 で発表された BigQuery の新機能を紹介します。なお、当記事で紹介する機能の提供ステータス（GA / Preview / Coming Soon）は 2026年4月23日現在の情報です。 参考 : What’s new in BigQuery: Powering the Agentic Era 他の Google Cloud Next '26 の関連記事は、Google Cloud Next '26 カテゴリの記事一覧から参照してください。 blog.g-gen.co.jp Open, cross-cloud lakehouse Managed Iceberg Tables（GA） Google Cloud Lakehouse （旧称 : BigLake ）は、 Apache Iceberg などのオープンテーブル形式と Google Cloud のマネージドストレージを組み合わせた、オープンデータレイクハウス向けのストレージエンジンです。 Google Cloud Lakehouse における Managed Iceberg Tables は、OSS である Apache Iceberg のマルチエンジン互換性と BigQuery の高度な機能を組み合わせたマネージドな Iceberg テーブルで、自動テーブル管理、Iceberg パーティショニング、マルチテーブルトランザクション、変更データキャプチャ（CDC）、強化されたベクトル化（Enhanced Vectorization）、履歴ベースの最適化（History-based Optimizations）を提供します。 参考 : Google Cloud Lakehouse とは 参考 : Apache Iceberg テーブル Iceberg REST Catalog の読み書き相互運用性（Preview） Iceberg REST Catalog は、BigQuery、Spark、その他 OSS / サードパーティエンジンの間で Iceberg テーブルを共有するためのカタログです。 カタログ上での Iceberg テーブルに対する 読み書きの相互運用性 （Read/Write Interoperability）により、複数の Iceberg 互換エンジン（Apache Spark、Trino など）から Iceberg テーブルを作成 / 更新 / クエリできるようになります。 参考 : Openness without compromises for your Apache Iceberg lakehouse Cross-Cloud Lakehouse（Preview） Cross-Cloud Lakehouse は、AWS や Azure など Google Cloud 以外のクラウド上のデータに対して、データ移行や ETL を行うことなく BigQuery の分析機能や AI 機能をそのまま適用できる機能です。たとえば、Amazon S3 Iceberg 上のデータに対して Gemini Enterprise のエージェントや BigQuery の AI 関数などを実行できます。 Iceberg REST Catalog によるオープンスタンダードなテーブル共有と、 Cross-Cloud Interconnect によるクラウド間の高帯域幅ネットワークを組み合わせることで実現されています。 参考 : クロスクラウド レイクハウスについて 参考 : The future of data lakehouse: Open and interoperable for the agentic era 基盤技術である Cross-Cloud Interconnect については以下の記事をご一読ください。 blog.g-gen.co.jp Catalog Federation（Preview） Catalog Federation は、外部のメタデータカタログを BigQuery 側でフェデレーションする機能です。 AWS Glue、Databricks、SAP、Salesforce、Snowflake のカタログに対応しており、Confluent Tableflow についても2026年後半に提供予定です。データの発見、分析、ゼロコピー共有を、複数のカタログをまたいで実現できます。 リアルタイムデータレプリケーション（GA / Preview） Spanner 、 AlloyDB 、 Cloud SQL から BigQuery へのリアルタイムレプリケーション（GA）と、Iceberg テーブルへのレプリケーション（Preview）が提供されます。これにより、データベースの変更をリアルタイムに分析基盤側へ反映でき、レプリケーションパイプラインを別途整備する必要がなくなります。 Graph-based reasoning for enterprise agents BigQuery Graph（Preview） BigQuery Graph は、BigQuery 上でデータをグラフとしてモデル化 / 分析 / 可視化できるグラフ分析機能です。SQL の CREATE PROPERTY GRAPH 文で既存の BigQuery テーブルに対してエンティティ（ノード）と関係性（エッジ）を直接定義でき、データの移動や重複を伴わずにグラフ分析を行えます。 従来の SQL では「友達の友達の友達」のような多段階の関係性分析に複数の JOIN を入れ子にする必要があり、SQL の記述・読解が難しいうえ、データ規模が大きくなるとパフォーマンスが急激に低下する点が課題でした。グラフ分析では、データをノードとエッジの集合としてモデル化することで、こうした多段階の関係性を直感的に記述でき、深い探索もスケーラブルに実行できます。 BigQuery Graph はこうしたグラフ分析を BigQuery 上でネイティブに実行できる基盤として、不正検知、Customer 360、サプライチェーン分析、ソーシャルネットワーク分析などのユースケースに対応します。 参考 : BigQuery Graph の概要 参考 : BigQuery Graph のご紹介 : データに潜む関係性を明らかに BigQuery Graph におけるメジャーのネイティブサポート（Preview） メジャー （売上や解約率といった集計値を再利用可能な形で定義したもの）が BigQuery Graph 上でネイティブサポートされるようになりました。 これにより、メジャーとエンティティ間のリレーションシップを1つのガバナンスされた定義に統合でき、AI エージェントは単なる検索や集計に留まらず、あるビジネスイベントが他の指標にもたらす影響をマルチホップで辿るような構造的推論を行えるようになります。 参考 : メジャーを使用する BigQuery Conversational Analytics におけるグラフサポート（Preview） 自然言語データ分析の Conversational Analytics が BigQuery Graph と連携できるようになりました。会話分析エージェントが生テーブルではなくグラフ上のエンティティと関係を辿って推論するため、回答の精度が向上します。メジャーを用いて正確な KPI を計算すると同時に、関係性を辿ることで「なぜその数字になっているか」を発見できます。 BigQuery における Conversational Analytics の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp BigQuery Graph と Looker の統合（Preview） BigQuery Graph と Looker の統合により、BigQuery Graph をそのまま Looker のビューとして公開でき、定義した指標をデータスタック全体で再利用できます。 逆方向のユースケースとして、Looker 側で BigQuery Graph を定義することもできます。これにより、Looker が標準で備えるバージョン管理（Git 連携）や検証機能を、グラフ定義の変更管理にそのまま適用できます。 BigQuery Studio での視覚的なモデリング機能（Preview） BigQuery Studio 上で、BigQuery Graph のエンティティ、リレーションシップ、ビジネスロジックを視覚的に構築 / 管理できる新しいインターフェースが追加されました。グラフスキーマの設計を SQL の CREATE PROPERTY GRAPH 文だけでなく UI 上からも進めることができます。 Native AI processing to unlock structured and unstructured data AI.PARSE_DOCUMENT（Preview） マネージド AI 関数の1つである AI.PARSE_DOCUMENT は、OCR（光学文字認識）、レイアウト解析、チャンク分割を自動化する SQL 関数です。複雑なドキュメント処理ワークフローを別途のパイプラインを構築せずに簡素化でき、非構造化ドキュメントの取り込みを SQL で完結できます。 TabularFM（Preview） TabularFM は、表形式データに対する高品質な回帰・分類機能を提供する基盤モデルです。事前学習済みのモデルとして提供されるため、特徴量選択、チューニング、モデルトレーニング、デプロイ後のモデル管理といった工程を経ずに、SQL から直接呼び出して予測結果を得られます。 従来の BigQuery ML では、表形式データに対する分類・回帰モデルをユースケースごとに用意する必要があり、本格的に運用するまでに一定のセットアップコストがかかっていました。TabularFM はこれを共通の基盤モデルに置き換え、典型的な分類・回帰タスクをモデル開発の工程を踏まずに試せるようにします。 ObjectRef（GA） ObjectRef 値 は、SQL や Python から非構造化データと構造化データを並行して扱うための値です。以下のフィールドを持つ STRUCT として表現されます。 フィールド 型 モード 説明 uri STRING REQUIRED Cloud Storage オブジェクトの URI version STRING NULLABLE オブジェクトのバージョン authorizer STRING NULLABLE 委任アクセス用の BigQuery 接続 ID。直接アクセスの場合は NULL details JSON NULLABLE オブジェクトのメタデータや処理時のエラー情報などが入る ObjectRef 値を操作するための SQL 関数として、以下の4種類がサポートされています。 関数 用途 OBJ.FETCH_METADATA URI のみが埋まった ObjectRef 値に Cloud Storage 上のメタデータを取り込み、完全な ObjectRef 値を返す OBJ.GET_ACCESS_URL ObjectRef が指す Cloud Storage オブジェクトへのアクセス URL（読み取り / 読み書き）を JSON 値で返す（委任アクセスが必要） OBJ.GET_READ_URL ObjectRef が指す Cloud Storage オブジェクトの読み取り用 URL を STRUCT（ url 、 status ）で返す（URL は45分で失効、委任アクセスが必要） OBJ.MAKE_REF Cloud Storage URI などから ObjectRef 値を生成する 参考 : ObjectRef functions 参考 : ObjectRef 値を操作する AI 連携関数の最適化モード（Preview） Optimized Mode により、 AI.CLASSIFY や AI.IF などの SQL から呼び出せる AI 関数で、タスク固有のモデルをクエリ実行時に動的にトレーニングして利用できます。これにより、従来の行単位でモデルを呼び出す場合と比較して、トークン消費量を230分の1に削減できます。 BigQuery ネイティブの Gemma エンベディング（Preview） Gemma ベースの組み込みテキストエンベディングモデル embeddinggemma-300m が、 AI.EMBED 関数および AI.SIMILARITY 関数で利用できるようになりました。エンベディング生成には BigQuery のスロットがそのまま使われるため、GPU 環境を別途用意することなく、検索や RAG 向けのエンベディングパイプラインを構築できます。 参考 : The AI.EMBED function 参考 : The AI.SIMILARITY function 自律型エンベディング生成（GA） Autonomous Embedding Generation （自律型エンベディング生成）は、テーブルのテキスト列（STRING 列）から生成するベクトルエンベディングをフルマネージドで維持する機能です。エンベディングモデルが生成したベクトルを自動メンテナンスし、ソース列のデータが追加・更新されるたびに自動で再生成されます。これにより、煩雑になりがちなエンベディング作成・更新ジョブの運用を簡素化できます。 参考 : 自律型エンベディング生成 BigQuery Hybrid Search（Preview） BigQuery Hybrid Search はセマンティック検索と全文検索を単一の関数に統合する検索機能で、RAG や複雑な探索系ユースケースにおいて、単独の検索よりも高い精度を実現します。 Python UDF（GA / Preview） Python UDF は、Python で独自実装したスカラー関数を BigQuery で利用する機能です。データの拡張・変換・クリーニングなどが行え、コンテナを用いたサーバーレス実行環境により数百万行規模まで自動スケールします。 以下の機能が新たに Preview 提供となり、Python UDF は今後数週間にわたって段階的に GA となる見込みです。 Apache Arrow の RecordBatch インターフェースを使ったベクトル化 Python UDF を作成でき、行単位の呼び出しと比べてパフォーマンスを改善できる CPU 使用率、メモリ使用率、インスタンスごとの最大同時リクエスト数などのメトリクスを Cloud Monitoring にエクスポートできる CREATE FUNCTION 文に追加された container_request_concurrency オプションで、Python UDF のコンテナインスタンスごとの最大同時リクエスト数を制御できる イメージストレージのバイト数（プロジェクト・リージョンごとに 10 GiB）とミューテーションレート（プロジェクト・リージョンごとに1分あたり30回）の新しいクォータが適用される INFORMATION_SCHEMA.JOBS ビューの external_service_costs 列、および Job API の ExternalServiceCosts フィールドから Python UDF のコストを確認できる 参考 : Python のユーザー定義関数 コネクテッドシートにおける TimesFM モデルの利用（GA / Preview） コネクテッドシート は、BigQuery のスケールを Google スプレッドシート上で利用できる機能です。アップデートにより、組み込みの時系列予測モデル TimesFM を使った予測（GA）と異常検知（Preview）に対応し、業務担当者がスプレッドシートから大規模データに対する予測や異常検知を行えるようになります。 参考 : コネクテッド シートの使用 参考 : TimesFM モデル コネクテッドシートの利用方法については、以下の記事をご一読ください。 blog.g-gen.co.jp Geospatial Analytics Datasets（Preview） Geospatial Analytics Datasets は、 Google Maps Platform 由来のデータセットと Earth Engine のラスターデータおよび解析機能を BigQuery 上で直接扱えるようにする機能です。地理空間データの取得・前処理を自前で組まなくても、BigQuery の他のデータセットと同じ感覚で参照できます。 提供されるデータセットは以下の4種類です。 データセット 内容 Imagery Insights ストリートビューの画像 Places Insights Google マップ上のビジネス / スポットの集約データ Roads Management Insights 道路ネットワークの交通流・混雑状況 Earth Engine in BigQuery Earth Engine の衛星画像・ラスターデータと解析機能 参考 : Power up your BigQuery analysis with Google's new geospatial datasets Agentic experiences BigQuery における Conversational Analytics（GA / Preview） BigQuery の Conversational Analytics （対話型分析）は、自然言語を用いて BigQuery 上のデータに対する質問を生成 AI に投げかけ、分析を行うことができる機能です。予測分析や、構造化・非構造化データを横断した推論もサポートします。 BigQuery Studio および API 経由での利用は GA、データポータル（英名 : Data Studio、旧称 : Looker Studio）および Gemini Enterprise からの利用は Preview 提供となっています。 参考 : BigQuery の会話型分析 BigQuery の対話型分析機能の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Proactive Agentic Workflows（Preview） Proactive Agentic Workflows は、エージェントが単なる対話型の質問応答を超えてプロアクティブに動作する機能です。指標の変化を検知して根本原因分析を行い、定期的な調査レポートをメールで直接配信するといったユースケースに対応します。 BigQuery Agent Analytics（GA / Preview） BigQuery Agent Analytics は、AI エージェントのアクティビティ（イベント）を BigQuery に記録し、分析できるようにする機能です。エージェントのトラブルシューティング、最適化、定量評価に活用できます。 エージェント向けのプラグインとして、 Agent Development Kit （ADK）向けのプラグインは GA、 LangGraph 向けのプラグインは Preview として提供されています。 BigQuery に記録されるイベントの種類は、以下のようなものがあります。 イベントの種類 内容 LLM interactions LLM へのプロンプト、モデル出力、エラーに関するイベント トークン使用量、生成にかかった時間なども記録される Tool usage ツール呼び出しの開始、完了、エラーに関するイベント ツールの呼び出し元（ tool_origin ）も記録される State Management エージェントの内部状態の変更に関するイベント Agent lifecycle & Generic Events エージェントの起動、実行完了、ユーザー入力の受信などのイベント Human-in-the-Loop (HITL) Events ユーザー認証情報の要求、ユーザーへの確認要求、ユーザーからの入力要求などの割り込みイベント 参考 : Use BigQuery agent analytics 以下の記事では、BigQuery Agent Analytics の ADK 向けプラグインの使い方を紹介しています。 blog.g-gen.co.jp BigQuery Studio の新機能群（GA / Preview） BigQuery Studio は BigQuery の各種機能を Google Cloud コンソールに統合した BigQuery 向けのワークスペースです。今回のアップデートで複数の機能が追加されました。 機能 ステータス 内容 コンテキスト認識型アシスタント Preview リソース探索やトラブルシューティングを支援 SQL Cells GA SQL と DataFrames を統合 Visualization Cells GA ノートブック内で直接ビジュアルを作成 Files Explorer GA フォルダ形式でコード資産を整理・共有・管理 Git Integration and Workflows Preview GitHub、GitLab、Bitbucket、Azure DevOps に対応した Git 連携 参考 : BigQuery 分析の概要 - BigQuery Studio データサイエンスエージェント（GA） データサイエンスエージェント （Data Science Agent）は、Colab Enterprise ノートブック上で動作する AI エージェントです。自然言語で目標を述べるだけで実行計画を自動生成し、データのロード、クリーニング、ビジュアライゼーションを自動で進めます。内部的には BigQuery ML、DataFrames、Spark を組み合わせて利用しています。 Colab Enterprise のほか、BigQuery Studio 上で Colab Enterprise ノートブックを開くことでも、データサイエンスエージェントを利用することができます。 参考 : BigQuery で Colab Enterprise データ サイエンス エージェントを使用する データサイエンスエージェントの詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Colab Data Apps（Preview） Colab Data Apps は、BigQuery Studio のノートブックで作成したデータ分析を、Python 製のインタラクティブアプリに変換できる機能です。アプリは BigQuery のスロットを使用してフルマネージドな環境で実行されます。 アプリの公開・共有はデータポータル側で行い、エンドユーザーはコードを編集することなく、UI 上で日付範囲やフィルタなどのパラメータを変更してデータを操作できます。 参考 : BigQuery とデータポータルで Colab Data Apps を使用する BigQuery Remote MCP Server（GA） BigQuery Remote MCP Server は、 Model Context Protocol （MCP）対応のリモートサーバーをマネージドで提供するものであり、AI エージェントが MCP を介して BigQuery を操作できるようになります。 参考 : Use the BigQuery MCP server Google Cloud が提供している MCP サーバーについては、以下の記事をご一読ください。 blog.g-gen.co.jp BigQuery ADK Toolset（GA） BigQuery ADK Toolset は、Agent Development Kit（ADK）を用いて構築したエージェントが BigQuery 上のデータを閲覧・操作するためのツールセットです。 参考 : BigQuery tool for ADK Google Cloud Data Agent Kit（Preview） Google Cloud Data Agent Kit は、IDE、ノートブック、ターミナルといった開発環境を問わずに利用可能な、エージェントによるデータ活用を支援する一連の機能を提供するスイートです。VS Code 拡張機能、MCP サーバー、Gemini CLI / Codex / Claude Code 向けのスターターパックといった複数の形態で提供されます。 エージェントは BigQuery、AlloyDB、Cloud SQL（MySQL / PostgreSQL）、Spanner、Cloud Storage などの Google Cloud 上のデータソースに接続し、以下のような作業を支援します。 Python や SQL でのクエリ実行、および自然言語による問い合わせを介したデータの検出・探索 Managed Service for Apache Spark や BigQuery でのデータエンジニアリングパイプラインの構築・テスト・デプロイ データの探索・クリーンアップから ML モデルの学習・デプロイまでを行う AI / ML 開発 組み込みの AI スキルやツールを使った反復的なタスクの自動化 参考 : VS Code 用 Data Agent Kit 拡張機能の概要 参考 : Data Agent Kit Starter Pack（GitHub） Unparalleled performance and scale Fluid Scaling（GA） Fluid Scaling は、変動の大きいワークロードに対して、コストとパフォーマンスのトレードオフを必要としない BigQuery 向けのオートスケーリング機能です。秒単位課金により細かい粒度でスケールでき、最大34%のコスト削減が可能です。 高度なランタイム、小規模クエリ、履歴ベースの最適化（GA） BigQuery のクエリエンジンに、 高度なランタイム 、 小規模クエリの最適化 、 履歴ベースの最適化 が適用されました。これらは BigQuery ネイティブテーブルと Iceberg テーブルの双方のワークロードに対して、コードやスキーマの変更なしに自動で適用されます。これにより、前年比でクエリ速度を35%向上させつつ、クエリ処理コストを40%削減しています。 新しいワークロード管理機能（GA / Preview） reservation groups （GA）、 flexible dynamic assignments （Preview）、 プロジェクトレベルのスロット / 同時実行制御 （Preview）といった新しいワークロード管理機能が追加され、きめ細かなコスト配分と価格性能比の制御ができるようになりました。さらに、 宣言型・ルールベースのワークロード管理 （Preview）により、これらの管理を簡素化できます。 可観測性の向上（GA / Preview） ミッションクリティカルなワークロード向けに、 Enhanced Observability （GA）、 Intersection Routing （Preview）、 Agent-Ready Security Center （Preview）といった可観測性・ディザスタリカバリ・セキュリティ関連の機能が追加・強化されました。さらに、 Agent-Powered Observability （Preview）により、AI エージェントによるターンキーなトラブルシューティングで運用を簡素化できます。 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の山崎です。当記事は、Google Cloud Next '26 in Las Vegas の2日目に行われたライトニングトークセッション「 8 Tips to Agentic Security Operations in 18 Minutes 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 AI を利用したセキュリティ運用における8つの Tips Tips 1: AI 推論の下に決定論的ルールを階層化する Tips 2: エージェントが必要とするデータを事前に計算する Tips 3: エージェントの権限を明示的に制限する Tips 4: ツールの出力は人間のためではなくエージェントのコンテキストウィンドウに合わせて設計する Tips 5: プロビナンスとリネージを通じてエージェントの決定に対する信頼を構築する Tips 6: 完璧な実行ではなくグレースフルデグラデーションを設計する Tips 7: 単体テストだけでなくシナリオハーネスを用いてシステムをテストする Tips 8: すべての要素、特にトークン使用量とアップストリームのレイテンシを観察する セッションの概要 Insight 社の John Giglio 氏と Hayden Holland 氏により、セキュリティ運用における AI エージェントの利用に関する実践的な8つの Tips が紹介されました。 セッションでは、AI を単なる確率論的な推論ツールとしてではなく、決定論的なシステムと組み合わせて安全かつ効率的に運用するための設計思想が語られています。 AI を利用したセキュリティ運用における8つの Tips Tips 1: AI 推論の下に決定論的ルールを階層化する エージェントの開発において、柔軟な AI の推論と、決定論的なルールベースの処理を組み合わせることが重要となります。AI の推論は確率論的であり、常に同じ結果を返すとは限りません。一方、決定論的なシステムは常に同じ結果を保証します。 セキュリティ領域においては、不確実性のある AI だけで環境に変更を加えることは大きなリスクを伴います。そのため、Insight 社では Site Reliability Engineering （以下、SRE）の手法に倣い、AI エージェントをデータのパターン認識や意思決定の補助として使用し、実際の実行部分は Python や Go 言語などで記述された決定論的なコードに委ねるアーキテクチャを採用しています。 SRE のマインドセットでは、運用業務を定期的に自動化して減らしていくことが求められますが、AI エージェントを使用することで、このプロセスをスピード感を持って対応することができます。 YAML や JSON スキーマ言語を多用してステップを定義し、期待される結果とそうでない結果を明確にしながらシステムを構築することで、AI エージェントは未知の脅威を探索する能力を提供し、決定論的なルールはシステムの安全な基盤を提供します。このように階層化することで、高い探索能力と耐久性のある実行の両立を実現できます。 Tips 2: エージェントが必要とするデータを事前に計算する Large Language Model （以下、LLM）を使用する推論やツール呼び出しには、多くのトークン消費とレイテンシが伴います。セキュリティ調査のたびに AI エージェントにあらゆる情報を探索させると、運用コストが膨大になり、回答を得るまでの時間も長くなります。 例えば、 MCP （Model Context Protocol）を使用して多数のツールをエージェントに接続し、すべてを自律的に推論させようとすると、処理が空回りし続ける可能性があります。この課題に対処するためには、エージェントにすべてを推論させるのではなく、エージェントが必要とするであろうデータを事前に計算し、準備しておくことが有効です。 エージェントには、明確に定義されたシステムプロンプトと、「この IP アドレスはウェブ環境で何をしているのか」といった特定のセキュリティのユースケースに特化した小さなスキル（skills）のみを使用させることが推奨されます。事前に与えられる情報が多いほど、エージェントの出力の精度は向上し、高価な LLM の呼び出し回数を最小限に抑えることができます。 参考 : What is the MCP and how does it work? 参考 : What is the Model Context Protocol (MCP)? Tips 3: エージェントの権限を明示的に制限する 現在、エージェントに自律的な意思決定をさせ、環境への変更権限を与えることには依然として高いハードルがあります。AI エージェントに対する完全な信頼が確立されていない段階では、エージェントの権限を明示的に制限するガードレールが不可欠です。コンテキストウィンドウ内に「何も編集しないで」という指示を含めたとしても、AI がそれを完全に遵守する保証はありません。 そのため、データを変更する可能性のあるツールの呼び出しについては、実行前に現在の権限レベルをチェックし、拒否ブロックを設ける必要があります。コンテキストウィンドウに指示を含めるだけでは、確実な保証は得られません。 2026年4月現在、多くの組織は「すべてを閲覧する」という読み取り専用の権限でエージェントを運用し、 Security Information and Event Management （SIEM）などのデータを通じて、エージェントの推論の精度を統計的に評価している段階とされています。 Tips 4: ツールの出力は人間のためではなくエージェントのコンテキストウィンドウに合わせて設計する エージェント間でデータを受け渡す際、ツールの出力結果はエージェントのコンテキストウィンドウに最適化されている必要があります。人間が見やすい形式で大量のデータをエージェントに渡すと、コンテキストウィンドウの上限に達し、重要な情報が無視されるなどの問題が発生します。システムは人間のためではなく、エージェントのために設計されなければなりません。 例えば、500件のファイアウォールルールのデータをそのまま返すよりも、関連性の高い上位10件の調査結果に絞り込み、「次に特定のルールについて詳細をクエリする」といったヒントを付与する方が効果的となります。エージェントは人間以上の情報を処理できる能力を持ちますが、コンテキストウィンドウの限界に配慮し、処理効率とのバランスを取る設計が求められます。適切なデータ量を提供することで、エージェントの能力を最大限に引き出すことができます。 Tips 5: プロビナンスとリネージを通じてエージェントの決定に対する信頼を構築する セキュリティチームがエージェントの自律的な意思決定を信頼するためには、ブラックボックスを排除し、推論の過程を検証できる仕組みが必要です。セッション内では、これを メタ可監査性 （Meta-auditability）と呼んで説明されています。 エージェントが導き出したすべての結論について、どのようなデータに基づき、どのような推論過程を経てそのツール呼び出しが行われたのかを遡って確認できるプロビナンスとリネージを設計に組み込む必要があります。セキュリティ担当者は本質的に懐疑的であり、証跡を直接確認できなければシステムを信頼しません。 運用の中でエージェントの行動パターンを継続的に監視・分析し、何十回も実行を繰り返す中で意思決定の傾向を把握します。この継続的な可視化を通じてのみ、少しずつシステムへの信頼を構築していくことができます。 Tips 6: 完璧な実行ではなくグレースフルデグラデーションを設計する システムの障害時に全体を停止させるのではなく、機能を縮小して稼働を継続する グレースフルデグラデーション の概念を、エージェントの設計にも取り入れることが推奨されます。 セキュリティ運用において、完璧な回答を待って時間がかかる、あるいは処理が失敗して何も情報が得られない状況は避けるべきであり、部分的でも正しい答えが得られるように出力結果に対してガードレールを設けることで、信頼性の高いシステムを目指すべきであると述べられました。 Tips 7: 単体テストだけでなくシナリオハーネスを用いてシステムをテストする エージェントをシステムとして本番環境に導入する前には、厳密なテストが不可欠です。しかし、単体テストや、結合テストによる検証だけでは不十分です。 AI エージェントが正しいセキュリティの意思決定を下すことを検証するためには、実際の運用に即したシナリオハーネスを使用する必要があります。サンドボックス環境を用意し、エージェントが予期せぬ挙動を示して制御不能に陥らないか、特定のシナリオにおいて適切なアクションを選択できるかを検証することが重要と語られました。 Tips 8: すべての要素、特にトークン使用量とアップストリームのレイテンシを観察する システムに対する信頼を維持するためには、エージェントの動作を継続的に観察し、可視化することが不可欠です。エージェントがどのような操作を行っているかを監視するだけでなく、トークン消費量やレイテンシの推移も把握する必要があります。 また、エージェントが機能しているように見えても、コンテキストが腐敗し、低品質な結果を出力し始めている可能性があります。コンテキストウィンドウの限界に近づいた際に見られる異常な応答やパフォーマンスの低下を検知するために、エージェントが行っているすべてを観察するという考え方を受け入れることが、安全な運用に繋がると述べられました。 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 13 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の武井です。当記事では、Google Cloud Next '26 in Las Vegas のセッション「 Secure what's next: AI-driven defense for the enterprise 」について、速報レポートをお届けします。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp はじめに AI がサイバーセキュリティにもたらす変革 変化する3つの軸 AI 自体を狙う新たな攻撃と、守るべき領域の拡大 Google が持つ可視性とフルスタックの AI インフラ 圧倒的な可視性 フルスタックの AI インフラと共同開発の優位性 Mandiant の最前線の知見 自律型防御に向けた新機能 human-led から human-on-the-loop へ Triage and Investigation Agent Threat Hunting Agent と Detection Engineering Agent Dark Web Intelligence Wiz による開発者起点のクラウドセキュリティ 垂直サイロ型から水平型への転換 Morgan Stanley の導入事例 AI 時代に向けた Wiz の進化 3 つのエージェントによる水平・エージェント型モデル クラウドネイティブから AI アプリケーション保護プラットフォームへ 2 つの方向への拡張 包括的なコードセキュリティの全体像 おわりに はじめに 本セッションでは、AI がサイバーセキュリティのあらゆる領域にもたらしている変化と、それに対抗するための 自律型サイバー防御 （Agentic defense）が紹介されました。 Google Cloud の COO 兼セキュリティ製品担当プレジデントである Francis deSouza 氏を中心に、脅威インテリジェンス、自律型セキュリティエージェント、Wiz を活用したクラウドセキュリティ、そして顧客事例まで、幅広い内容が扱われた密度の高いセッションでした。 AI がサイバーセキュリティにもたらす変革 変化する3つの軸 Google Cloud の Sandra Joyce 氏からは、AI が脅威状況（threat landscape）に与えるインパクトが Scale （規模）、 Speed （速度）、 Sophistication （巧妙化）の3つの軸で整理されて紹介されました。 1つ目の Scale について、攻撃者は AI を単なるアドバイザーとして使う段階から、完全に自律したエージェントを投入する段階へと移行しつつあります。これまで SOC は false positive（誤検知）の多さに悩まされてきましたが、今後は 大量の true positive によって捌ききれなくなる SOC へと変わっていくという指摘が印象的でした。 2つ目の Speed については、攻撃者が Gemini をはじめとする大規模言語モデル（以下、LLM）で公開スクリプトを武器化し、アジア・アフリカ・ヨーロッパのメールシステムに対して大規模な悪用を展開している事例が紹介されました。攻撃者はすでに人間の速度ではなくマシンの速度で動いており、防御側も同じ速度で応戦しなければならないというのが Sandra 氏のメッセージです。 3 つ目の Sophistication に関しては、ロシアの軍事情報機関に紐づくサイバースパイグループ APT28 が、オープンソースの LLM をその場で呼び出してコマンドを生成し、静的検知を回避するマルウェアを展開している事例が取り上げられました。また、Mandiant の最新 M-Trends レポートでは、脆弱性の悪用までの平均時間（Mean Time to Exploit）が マイナス 7 日間 であったことが紹介されました。Time to Exploit は「ベンダーが脆弱性を公開した日」または「パッチをリリースした日」を起点（0日）としますので、平均の Time to Exploit がマイナス値であることは、パッチが公開される前に悪用が行われているケースが常態化していることを意味します。 攻撃者側も進化しており、WormGPT や HexStrike AI MCP といったツールを連鎖させることで、セキュリティに詳しくない犯罪組織でも高度なエージェント型攻撃を組み立てられるようになっています。 AI 自体を狙う新たな攻撃と、守るべき領域の拡大 AI 時代には、攻撃の手口だけでなく、守るべき対象そのものも変わります。 プロンプトインジェクション 、 モデル抽出 、 データポイズニング 、 モデル蒸留 といった AI 固有の攻撃が観測されている一方、既存の攻撃も AI で強化されています。例えば、ディープフェイク動画とメールを組み合わせたマルチモーダルフィッシングは、成功率を底上げする典型的な手法として紹介されていました。 同時に、組織が守るべき領域も拡大しています。モデル、エージェント、プロンプト、データパイプラインといった AI インフラ全体 が新たな保護対象となり、加えて従業員が独自に導入した シャドー AI 、サプライチェーン経由で組織に入り込む外部 AI コンポーネントまで、可視化と管理の対象が広がっています。 Google が持つ可視性とフルスタックの AI インフラ 圧倒的な可視性 Francis 氏は、Google がこの脅威状況に対して独自の可視性を持っていると強調していました。 Google は世界で 40 億台以上のデバイスとユーザーを保護しており、VirusTotal には 500 億を超えるファイルが蓄積されています。さらに Google Play 経由で毎日 2,000 億を超えるファイルがスキャンされているそうです。 こうした観測結果は、Google Threat Intelligence が四半期ごとに発行する AI Threat Tracker レポートとしてコミュニティへ公開されています。最新版では、モデル蒸留や AI の敵対的利用の継続的な統合といったテーマに加え、Gemini 以外の非 Google 製ツールに関する知見も含まれています。 参考 : GTIG AI Threat Tracker: Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use フルスタックの AI インフラと共同開発の優位性 Google はデータセンター間を結ぶ約 200 万マイル（約320万キロメートル）規模の光ファイバー網を自社で運用しており、各レイヤを軍事グレードのセキュリティで保護しています。AI モデル自体の保護についても、 Model Armor や Agent Gateway を通じて、プロンプトインジェクション・ツール汚染・機密データ漏洩を防ぐ取り組みが進んでいます。 Francis 氏が特に強調していたのは、Google がセキュリティ製品を AI インフラと 共同開発 （co-engineering）している点でした。 一般的なセキュリティベンダーは新モデルが公開された当日に初めて中身を理解し始めるため、製品に新モデルを組み込むまで半年から 1 年のタイムラグが生じます。これは AI のタイムラインでは「1〜2 世代遅れ」を意味します。 Google の場合は新モデルのリリース初日から最新機能をセキュリティ製品に取り込めるため、攻撃者と同じ世代の AI で対抗できるという主張です。 Mandiant の最前線の知見 最前線の侵害対応で得られる知見を製品に還元している点も、Google の強みとして繰り返し強調されていました。 現在進行中の重大な侵害事案の多くに Mandiant が関与しており、そこで直面する最も複雑な攻撃手口が、将来の攻撃検知のために Google Cloud のインフラへ組み込まれています。 参考 : Mandiant 自律型防御に向けた新機能 human-led から human-on-the-loop へ Google のアプローチは、従来の「human-led（人間主導）」や「human-in-the-loop（人が都度関与する）」から、「 human-on-the-loop （エージェントが主体で人は監督する）」へと移行しつつあります。エージェント群が重労働を担い、人間はポリシー策定と全体の監督に集中するというモデルです。 Triage and Investigation Agent Google SecOps の自律型セキュリティエージェントである Triage and Investigation Agent が一般提供（GA）となりました。 このエージェントはすでに 500 万件を超えるアラートをトリアージした実績があり、従来は人手で約 30 分かかっていた調査を 60 秒程度で完結 できるとのことです。false positive が増え続ける環境下で迅速な判断が求められる SOC にとって、インパクトの大きい機能といえます。 参考 : Use Triage and Investigation Agent to investigate alerts Threat Hunting Agent と Detection Engineering Agent Triage and Investigation Agent に加え、以下 2 つのエージェントが Preview 公開となりました。いずれも Mandiant の第一線の専門家による検証を経たものです。 # エージェント名 説明 1 Threat Hunting Agent Google の脅威インテリジェンスとベストプラクティスに基づき、環境内の新興脅威を継続的かつ大規模に探索する 2 Detection Engineering Agent 検知カバレッジのギャップを特定し、発見内容に基づいて新たな検知ルールを自動生成・展開する これらの即利用可能なエージェントに加え、カスタムワークフローを構築・ホストするための Google SecOps MCP Server （GA）も提供されています。 Dark Web Intelligence Dark Web Intelligence が Preview 公開となりました。Gemini を基盤としてダークウェブを自律的に探索し、組織のプロファイリングを行ったうえで関連する外部脅威を抽出する機能です。 従来のダークウェブ調査ツールは誤検知が多いことが課題でしたが、Dark Web Intelligence では 98% の精度 で外部脅威を特定できると紹介されました。Forrester の調査によれば、Google のアプローチを採用することで侵害リスクとコストを 17% 削減できるという結果も示されていました。 参考 : Bringing dark web intelligence into the AI era Wiz による開発者起点のクラウドセキュリティ 垂直サイロ型から水平型への転換 ここからは、Wiz の VP of Product Marketing である Jiong Liu 氏のパートです。 クラウドの普及により、多くの企業の開発チームはアイデアを数日から数週間でコードに変え、クラウドへ展開できるようになりました。開発が水平（horizontal）かつアジャイルになった結果、セキュリティにも開発者と同じ速度で動くことが求められています。 しかし、多くのセキュリティ組織は依然として垂直（vertical）にサイロ化されたままです。アプリケーションセキュリティチームはコードスキャナー、DevOps チームはパイプラインスキャナー、クラウドセキュリティチームはランタイム向けツール、SecOps チームはまた別のスタック、といった具合にチーム・ツール・プロセスが分断されています。結果として、サイロごとに大量のアラートが発生し、本当のリスクが見過ごされ、開発とセキュリティの間には摩擦が生じます。 Wiz は、コード・パイプライン・クラウド・ランタイムといったライフサイクル全体のコンテキストを、単一の セキュリティグラフ （Security Graph）に統合します。そこから、悪用されれば事業に重大な損害を与え得るアタックパス（攻撃経路）を特定する、というのが基本的な設計思想です。 アタックパスという形で可視化されると、開発者も「どこを、なぜ、優先して直すべきか」を直感的に理解できるため、セキュリティと開発が同じ土俵でリスクを潰していけるようになります。Jiong 氏は、Wiz の顧客のうち 50% 以上が「クリティカル課題ゼロ」を達成している と紹介していました。 Morgan Stanley の導入事例 続いて、Morgan Stanley の Global CISO である Alonzo Ellis 氏が登壇し、同社のセキュリティモデルの転換について語りました。 同社では従来、アプリケーション・クラウド・オペレーションの各セキュリティが垂直にサイロ化されており、マルチクラウド環境におけるシグナル収集の限界、アラート過多と優先度判断の難しさ、セキュリティとエンジニアリング間の摩擦といった課題が顕在化していたそうです。 Wiz の導入により、クラウドとランタイムのコンテキストが単一のグラフに統合され、個別の指摘ではなく、 完全なアタックパス としてリスクを把握できるようになったといいます。優先順位付けも、単純な深刻度スコアではなく「どれだけ露出しているか」「クラウンジュエル（最重要資産）にどれだけ近いか」で行えるようになりました。 Morgan Stanley からは、具体的な成果として以下のような数字が共有されていました。 Wiz CSPM と Wiz Sensor で、クラウド環境内の 65,000 ワークロード・170 万アセット を保護中。Wiz Code も全社展開を進めている マルチクラウド環境における検知・対処速度が、従来の 約 45 分（手動の対応ワークフロー込み） から、検知はミリ秒単位、対処は 90 秒未満に短縮。MTTD は 99.99% 減、MTTR は 98% 減 Wiz のコンテキストにより、これまで可視化できていなかった 16 件のクリティカルリスクを特定し、ゼロまで低減 買収対象企業のセキュリティアセスメントにかかる期間を、従来の数カ月から 2 週間未満 に短縮 Alonzo 氏は AI 時代のセキュリティについて、「AI を採用するかどうかが課題ではなく、自社のセキュリティモデルが AI の導入速度に追随できるかどうかが課題だ」と述べていました。エージェントによってスケール・速度・自律性が高まるぶん、エージェント型の攻撃も従来より速く進化するため、防御側もマシン速度で動く必要があるという主張です。 AI 時代に向けた Wiz の進化 3 つのエージェントによる水平・エージェント型モデル Alonzo 氏のパートを受けて、Jiong 氏は Wiz 自身の進化について説明しました。「AI 時代にもう一度 Wiz をゼロから作り直すとしても、何も変えないだろう」という発言が印象的で、コンテキストエンジンとして設計された Wiz は、人間のセキュリティチームだけでなく AI エージェントが推論を行う基盤としても最適である、という自信が語られました。 Wiz が提示したのは、「水平かつエージェント型（horizontal, agentic）」のセキュリティアーキテクチャです。中核を担うのは、以下3種類のセキュリティエージェントです。 Red Agent : 環境に対する継続的なペンテスター（ホワイトハッカー）として機能し、アタックサーフェイス（攻撃対象領域）のあらゆる露出ポイントを自律的にプロービングして、リスクが実際に悪用可能かを判定する Blue Agent : 発生中の脅威をリアルタイムに調査する Green Agent : 完全な修復計画を自律的に作成する。リスクを作り込んだ正確なコード行を特定し、修正を開発者または開発者が使うコーディングエージェントに直接プッシュする これにより、検知と同じスピードで修復まで進められるようになります。これまでリスクのトリアージは環境内の最大のボトルネックでしたが、そのボトルネックを取り除くのが狙いです。 クラウドネイティブから AI アプリケーション保護プラットフォームへ Wiz はこのタイミングで、従来のクラウドネイティブなセキュリティプラットフォームから、 AI アプリケーション保護プラットフォーム （AI application protection platform）へと進化したことを発表しました。 コード・クラウド・ランタイムを横断して AI アプリケーションとクラウドアプリケーションを保護するもので、パブリッククラウドだけでなくプライベートクラウドやオンプレミスにも対応します。 2 つの方向への拡張 Google Cloud Next '26 のタイミングで、Wiz は対応範囲を 2 つの方向に拡張することも発表しました。 1 つ目は「あらゆるプラットフォーム、あらゆる AI」への対応拡大です。以下の領域が新たにカバー範囲に加わります。 データプラットフォーム : Databricks、Snowflake エンタープライズ AI 基盤 : Gemini Enterprise Agent Platform、AWS AgentCore、Microsoft Copilot Studio、Salesforce の Agentforce のような SaaS クラウド境界 : Cloudflare、Akamai、Apigee、Vercel からのコンテキスト取り込み 2 つ目は、AI ネイティブな開発ライフサイクルへの入り込みです。コーディングエージェントへの可視性を獲得するだけでなく、従来にはなかった地点にセキュリティを組み込めるようになる、という点が強調されていました。 Prevention （予防） : Wiz hooks や Wiz skills を通じて、コーディングエージェントに「セキュリティの脳」を注入する。開発者がコーディングエージェントにコードを書かせた直後に、Wiz がそのコードとデプロイ内容を評価し、組織のポリシーに沿って修正までかける。開発者が翌朝 PC の前に座ったときには、すでにセキュアなコードが仕上がっている状態を目指す。 Backlog Burn-down （既存バックログの消化） : 事前構築済みの Wiz セキュリティスキルを IDE に直接取り込み、Green Agent の洞察をもとにコードベースの自己修復（self-healing）を進める。 包括的なコードセキュリティの全体像 Francis 氏は、Wiz・Google SecOps・Mandiant・ CodeMender を組み合わせた包括的なコードセキュリティの構想を次のように整理していました。 Wiz : 環境のマッピングとクリティカルリスクの修正 CodeMender : AI ベースでコードベースをスキャンし、コードレベルで修正を実行 Mandiant : 脆弱性対応の成熟度（vulnerability readiness）を高める知見の提供 Google SecOps : 継続的な検証と保護 Google Threat Intelligence がこれら全体を下支え Wiz でコードセキュリティ戦略を立て、CodeMender・Wiz・Mandiant で環境内の脆弱性を特定・優先度付けし、修復ワークフローを起動する。さらに Mandiant で継続的な要件の評価を行い、Google SecOps で監視を続ける、というフルスタックの構成です。 おわりに 本セッションを通じて繰り返し語られていたのは、 AI vs AI の時代において、防御側にも同じ世代の AI と、マシン速度で動くエージェント群が必要 、というメッセージでした。 Google の強みは、脅威状況に対する圧倒的な可視性、AI インフラとセキュリティ製品の共同開発、そして Mandiant の最前線の知見を Google Unified Security として集約している点にあります。 そこへ Wiz が加わったことで、開発者起点のクラウドセキュリティから SOC の自律運用、さらにはコードレベルの自動修復までを一気通貫で扱えるプラットフォームへと進化しつつある、というのが今回の発表全体から伝わる方向性でした。 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

G-gen の杉村です。当記事では、Google Cloud Next '26 in Las Vegas の、2日目の開発者向けキーノートに関する速報レポートをお届けします。 Developer Keynote イベントの概要 キーノートの概要 技術的な概要 Google が強調したかったこと 全体像 Build agents with Agent Platform Creating multi-agent systems Enhancing agents with memory Debugging agents at scale Intent to infrastructure with Gemini Cloud Assist Build and share no-code agents Securing agents 関連記事 Developer Keynote イベントの概要 Google Cloud Next は、1年に1回開催される、Google Cloud の旗艦イベントです。2026年は、ラスベガスのマンダレイ・ベイにおいて4月22日（水）から24日（金）までの3日間で開催されます。 参考 : Google Cloud Next 2026 - Las Vegas Conference 例年、2日目の「開発者向け基調講演（ Developer Keynote ）」では、Google が開発者やデータサイエンティスト、機械学習エンジニアなど技術者向けに伝えたい主張や新サービスの発表などが行われます。当記事では、Google Cloud Next '26 の2日目の開発者向け基調講演を、特に注目すべき発表にフォーカスして紹介します。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp Developer Keynote キーノートの概要 Google Cloud Next '26 の初日に行われたオープニングキーノート（基調講演）では、Google Cloud の新機能の発表や、顧客事例が紹介されました。また、AI/ML や生成 AI 向けの開発プラットフォームである Vertex AI が Gemini Enterprise Agent Platform に改名されリブランディングされたことも示されました。 blog.g-gen.co.jp 当記事で紹介する、2日目の開発者向けキーノート（Developer Keynote）では、ラスベガスでのマラソン大会を計画・シミュレーションするデモ AI エージェントを題材に、エージェントの開発、デバッグ、インフラ構築、セキュリティ強化をウォークスルーで紹介する体裁が取られました。 チーフエバンジェリストの Richard Seroter 氏と、Developer Relations Engineer の Emma Twersky 氏のコンビが全体をファシリテーションします。AI エージェント開発を7つのデモにわけて、各デモでスペシャリストが登壇して紹介しました。 Richard Seroter 氏と Emma Twersky 氏 7つのデモは、以下のとおりです。 Build agents with Agent Platform（ Agent Platform でエージェントをビルドする ） Creating multi-agent systems（ マルチエージェントシステムを作成する ） Enhancing agents with memory（ メモリでエージェントを強化する ） Debugging agents at scale（ エージェントを大規模にデバッグする ） Intent to infrastructure with Gemini Cloud Assist（ Gemini Cloud Assist を使用してインテントからインフラストラクチャを構築する ） Build and share no-code agents（ ノーコードエージェントを構築して共有する ） Securing agents（ エージェントをセキュアにする ） これを通じて、Google Cloud と AI を活用すると、いかに素早く簡単にエージェント開発が進められるかを強調しました。 7つのデモ 技術的な概要 このキーノートで紹介されたマラソン大会計画エージェントは マルチエージェント 、すなわち複数の AI エージェントが協調してタスクを行うエージェントです。このマルチエージェントの開発をウォークスルーする形で、様々な技術がプレゼンテーションされました。 エージェントの開発は、AI エージェント開発用ライブラリである Agent Development Kit （ADK）を用いて行います。 開発されたエージェントは、 Agent Runtime （旧称 Vertex AI Agent Engine）にデプロイされます。Agent Runtime はフルマネージドの AI エージェント向けコンピュートプラットフォームであり、組み込みのセッション管理機能とメモリ管理機能などを備えています。 別々にデプロイされた複数のエージェント間の通信は A2A などの標準プロトコルが担い、ガバナンスは Gemini Enterprise Agent Platform に含まれる Agent Registry や Agent Gateway 、 Agent Identity といった機能が担保します。また、 Wiz はソースコードと環境をエージェントがスキャンすることで、セキュリティリスクを高度に可視化し、対処法を提示できます。 また開発作業や運用は、 Agent Observability や Gemini Cloud Assist を組み合わせることで、使い慣れた IDE（統合開発環境）から AI の補助を借りつつ迅速に行うことができます。 Google が強調したかったこと 前述のように、Google Cloud そのエコシステムには AI エージェントの開発、デプロイ、保守を効率的に、かつセキュアに行う手段が揃っています。Google Cloud とそのエコシステムを使って AI エージェントを開発、デプロイ、保守することで、 セキュリティとガバナンスを保ちつつ高速に AI エージェント開発ができる ことを、Google が改めて示した形になります。 また、リブランディングされた Gemini Enterprise Agent Platform が、組織が 統制を効かせつつ AI エージェントを活用する ためのプラットフォームであることも強調されました。多数のエージェントがさまざまな部署によってデプロイされても、重複開発を防ぎつつ、エージェント同士が相互に連携しあい、タスクを自律的に行っていくのが理想です。 そのうえでセキュリティを担保するには、組織が適切なプラットフォーム上で統制を効かせることが不可欠です。Gemini Enterprise Agent Platform には、そのようなサービスが揃っています。 公式ガイド Agent Platform overview から引用 全体像 開発者向けキーノートでは、ラスベガスでのマラソン大会を計画するマルチエージェントを開発します。エージェントの構成は以下のようなものです。 Planner agent : skills と tools を使って走行ルートを決める Evaluator agent : ビジネス要件や地域ルールに従って走行ルートを評価する Simulator agent : 街への影響を見るため、走行ルート上でランダムな振る舞いをする人々をシミュレーションする このような 複数のエージェントが相互に協調 し、マラソン大会の計画というタスクを実行していきます。 開発するマラソン大会計画エージェント Build agents with Agent Platform 走行ルート計画を立てる Planner agents の開発は、Gemini Enterprise Agent Platform の Agent Designer を使って行われました。UI 上で自然言語でエージェントの振る舞いを定義して、Get code ボタンを押すと、AI エージェント開発用ライブラリである Agent Development Kit （ADK）で記述された Python コードが自動生成されました。初期のプロトタイプは、このようにして Agent Designer で生成できます。 Agent Designer Planner agents は内部的に instructions、skills、tools で構成されています。 instructions はエージェントの振る舞いを決めるテキストプロンプトです。 skills は、LLM が自身の知識だけで完結せず、外部ツールや API 等と連携して作業できるように部品化された「実行可能な拡張機能」または「テキストのプロンプト」のことです。Google に特有な言葉ではなく、近年の AI エージェントツールにおいてよく用いられる用語です。タスクを進める中で適切な振る舞いができるように、Google Maps や Geographic Information System（GIS）、レース監督といった Skills が定義されています。 skills からは tools を呼び出すこともできますし、別途配置された Python スクリプトを呼び出すことなども可能です。 tools は、AI エージェントが外部のアプリケーションや API を「道具」のように呼び出すための定義のことです。ここでは、 Google Cloud MCP server for Google Maps が Tools として定義されています。Google Cloud MCP server は、Google Cloud が提供するフルマネージドのリモート MCP サーバーです。Skills で定義された振る舞いにより、MCP server tools が呼び出され、エージェントはマップ情報を手に入れることができます。 instructions、skills、tools こうして構築された Planner agents は、 Agent Runtime （旧称 Vertex AI Agent Engine）にデプロイされます。Agent Runtime はフルマネージドのエージェント用コンピュートプラットフォームです。セッション、メモリ、モニタリングなどのエージェント用機能がネイティブに備わっています。 Creating multi-agent systems 次に、他のエージェントも考えます。ルートを評価する Evaluator agent は Planner agent のサブエージェントとして配置します。一方で街への影響をシミュレーションする Simulator agent は、別の Agent Runtime インスタンスにデプロイされており、Planner agent とは A2A プロトコルを使って通信します。A2A プロトコルは、エージェント間の通信を標準化するプロトコル（あるいはフォーマット）です。 参考 : Agent2Agent (A2A) Protocol マルチエージェントのアーキテクチャ A2A プロトコルでは、各エージェントは Agent card と呼ばれる情報を持ち、自らの役割や能力を広告（advertise）します。これにより、エージェント同士は、呼び出すべき他のエージェントの情報を知ることができます。 Agent card またここでは、エージェントは Gemini Enterprise Agent Platform の Agent Registry という共通レジストリに登録されます。Agent Registry はインターネットにおける DNS のようにイメージできます。エージェントは他のエージェントについて Agent Registry に問い合わせ、必要な能力を持つ他のエージェントを探し出すことができます。Agent Runtime にデプロイされたエージェントは Agent Registry に登録され、相互に発見可能になります。エージェント同士の通信は A2A に基づいて行われるので、複雑な API コントラクトを定義する必要がありません。 参考 : Agent Registry overview Agent Registry に登録されたエージェント一覧 Agent Registry を使ったアーキテクチャ またエージェントが効果的にグラフィカルなユーザーインターフェイスを生成するための標準規格である A2UI も紹介されました。これにより AI が動的に UI を生成できるため、フロントエンドの作り込みにかかる時間が軽減されます。 参考 : a2ui.org A2UI の one-shot prompting A2UI で生成された UI（右ペイン） Enhancing agents with memory Planner agent は、 セッション と メモリ を使います。セッションは、1回の処理内での短期的な記憶であり、メモリはセッションをまたいで記録される長期的な記憶です。どちらの記憶領域も Agent Runtime に標準で備わっており、ADK 上の実装でも少量のコードで済みます。メモリ機能により、Planner agent は過去に策定された計画を覚えておくことができます。 参考 : Agent Platform Sessions overview 参考 : Agent Platform Memory Bank メモリとセッションを定義するソースコード また Planner agent が適切な走行ルートを策定するためには、州や市の定めるルールなどを知っておく必要があります。PDF などの非構造化データをエージェントが参照できるようにするために、ここでは RAG（Retrieval-Augmented Generation）を用います。RAG 構成のためには、非構造化データをエンベディング情報に変換してデータベースに格納する必要があります。 メモリ、セッション、RAG デモでは Google Cloud のデータエンジニアリングエージェントを使い、エンベディング情報を生成するデータパイプラインを簡単に開発できるとされました。Lightning Engine for Apache Spark を使って PDF を読み取り、チャンク化して AlloyDB のテーブルに格納します。本来であれば、チャンク化されたテキストはパイプラインによって、または手動でエンベディング情報に変換される必要があります。しかしここでは、AlloyDB の Auto vector embeddings 機能が使用されました。これにより、テーブルに格納されたデータが、自動的にベクトル化されます。 参考 : Generate and manage auto vector embeddings for large tables AlloyDB に格納された自治体ルールは、tools を通じて呼び出されます。この tools は Google Cloud から提供されている AlloyDB のリモート MCP サーバーを使って、AlloyDB のベクトル化情報をクエリします。 AlloyDB に格納されたチャンクとエンベディング Debugging agents at scale 大量のエージェントが運用されている状況下では、モニタリング、デバッグ、および障害対応の負担が増大します。Gemini Enterprise Agent Platform にはこの状況に対応するための機能が用意されています。 Agent Observability は、Agent Runtime にデプロイされたエージェントのモニタリングを行います。 Gemini Cloud Assist は、Google Cloud における開発や運用を AI で補助する機能の総称です。 参考 : Agent observability 開発者や運用者は、使い慣れた IDE や CLI ツールから、MCP 経由で Gemini Cloud Assist を呼び出し、Agent Observability の情報を自然言語で取得できます。これにより、大規模な AI エージェント運用環境でも、情報取得、障害の解決法の示唆、修正コードの適用などを、すべて 自然言語により 行えることが示されました。 自然言語による AI アプリケーション運用 Agent Observability では、エージェントの動作のトレース情報を確認できます。 AI アプリケーションのトレース情報 また、Gemini Cloud Assist の一部である Gemini Cloud Assist Investigations を使うと、AI がトレース情報やログなどを読み取り、障害の root-cause analysis（RCA、根本原因分析）を行ってくれます。 参考 : Gemini Cloud Assist Investigationsを解説。AIエージェントでトラブルシューティング - G-gen Tech Blog Gemini Cloud Assist Investigations また、任意の IDE から MCP 経由で Gemini Cloud Assist を呼び出すこともできます。自然言語でエラーの原因を問い合わせると、MCP 経由で情報が取得されます。Agent Observability の情報や GitHub 上の issue の情報が収集され、原因や解決方法、修正コードまでもが AI により回答されます。わずか数分で、エラーを解消できました。 IDE からのソースコード改修 Intent to infrastructure with Gemini Cloud Assist Simulator agent は、マラソンランナーをシミュレーションする必要があります。ランナーをシミュレーションするためのサブエージェントである Runner agent を、ここでは Google Kubernetes Engine（GKE）上で稼働させ、またモデルとしては Gemma 4 を用います。Gemma は、Google が提供するオープンモデルです。ローカル環境や GKE のようなプラットフォーム上で動作できます。インフラとして GKE を、モデルとして Gemma を使うことで、Agent Runtime と Gemini のようにフルマネージドな組み合わせよりも、より細かいカスタマイズを行うことができます。 参考 : Gemma モデルの概要 GKE と Gemma デモでは、Simulator agent はもともと Cloud Run service にデプロイされていました。この Cloud Run の定義ファイルを自然言語による指示で GKE に変換します。IDE から MCP 経由で Gemini Cloud Assist を呼び出し、この変換を実環境に適用します。Gemini Cloud Assist が人間と Google Cloud の間の翻訳者として動作したことで、自然言語を使ってインフラをデプロイできました。 Google Cloud と Gemini の統合により、ソースコード開発だけではなくインフラ構築や運用も、自然言語で行えることが示されました。 自然言語で Cloud Run から GKE へ移行する Build and share no-code agents 次に、ここまでで開発した ハイコードエージェント （または フルコードエージェント ）と、Gemini Enterprise app で構築するノーコードエージェントの連携が示されます。飲み物や食料、仮設トイレなどのロジスティクスまわりを計画する Supply chain agent を、ノーコードエージェントとして構築します。 ハイコードエージェントとノーコードエージェントの協調 Agent Runtime にデプロイされたエージェントは、 Gemini Enterprise アプリ からも呼び出し可能になります。Gemini Enterprise アプリは、かつては単に Gemini Enterprise と呼ばれていた、エンタープライズ従業員向けの AI ツールです。 参考 : Gemini Enterpriseを徹底解説！ - G-gen Tech Blog Gemini Enterprise アプリから Planner agent を呼び出すと、A2UI によって動的に生成された UI が反映されています。開発したハイコードエージェントは、カスタムアプリの UI から使用できることはもちろん、Gemini Enterprise アプリからも使用できることが示されています。 ハイコードエージェントを Gemini Enterprise アプリから呼び出す 続いて、ロジスティクス周りの業務を行う追加のエージェントを構築するため、Gemini Enterprise アプリのノーコードエージェント構築機能を使います。Gemini Enterprise アプリの Agent Designer では、ノーコードエージェントを視覚的な UI で構築できます。また Agent Designer は、自然言語で指示することで、自動的にノーコードエージェントを構築してくれます。 Agent Designer Gemini Enterprise アプリの Agent Designer で開発したノーコードエージェントも Agent Registry に登録されるため、他のエージェントから呼び出すことが可能です。 続けて、Gemini Enterprise アプリの UI から Planner agent に「ロジスティクス計画を含めた、総合的な計画を策定して」と指示すると、Planner agent から Supply chain agent が呼び出され、総合的なマラソン大会計画が策定できることが示されました。つまり、フルコードで Agent Runtime にデプロイされているエージェントと、Gemini Enterprise アプリのノーコードエージェントとして構築したエージェントが A2A プロトコルを通じて連携し、タスクを実行した ことになります。 ハイコードエージェントからノーコードエージェントが呼び出された Securing agents マルチエージェント環境のセキュリティを向上するための施策も紹介されました。 Agent Gateway は、エージェント間のプロキシといえます。エージェント間の通信に Identity and Access Management（IAM）ポリシーを適用し、エージェントがどこから使用可能かを制御します。 参考 : Agent Gateway overview Agent Gateway はエージェント間のプロキシ Agent Registry に登録されたエージェントには、自動的に固有の Agent Identity が付与されます。汎用的なサービスアカウントは複数のワークロードに付与できてしまう可能性がありますが、Agent Identity は 必ずエージェントごとに一意 であるため、監査可能性とセキュリティの面で優れています。 Agent Identity Agent Gateway はこの Agent Identity をアクセス制御に使用します。Agent Gateway の Egress Agent Policy は、エージェントから他のエージェントや tools などへのアウトバウンド通信を制御し、ガードレイルの役割を果たします。エージェントからインターネットへの通信を制御することもできます。 Egress Agent Policy デモの環境ではアクセスが厳密に制御されていたため、Planner agent から予算情報を取得するための Finance MCP Server へのアクセスを許可するために、Agent Gateway 上で IAM Allow ポリシーを追加します。ポリシーには条件（conditions）を付与することもでき、ReadOnly のみ、といった指定が可能です。 IAM Allow Policy の追加 続いて、クラウド向けのセキュリティソリューション Wiz が紹介されました。Google は2026年3月に、Wiz の買収完了を発表しました。 Wiz は AI アプリケーションの ソースコードとクラウドの実環境をスキャン して、セキュリティグラフを生成します。また Wiz は、アタックサーフェイス（Attack surface）を検査してリスクを見つけだす Red agent や、根本対処の方法を提示する Green agent など、AI エージェントを用いています。 Wiz と AI アプリケーション デモでは、Planner agent とそのモデル、tools などが可視化されている Wiz の UI が示されました。インターネットからサービスアカウントを通じて Cloud SQL（データベース）に到達できてしまう可能性があることなどが、可視化されています。 セキュリティグラフ Red agent はこのような攻撃経路を評価してリスクを提示するので、ソースコードの静的評価などよりも優れています。 Red agent のリスク提示 Green agent はこれらに対する対策を提示します。デモでは Claude Code の skills を使って Green agent に対処法を提示させ、環境に適用させました。 Green agent の対処法提示（1） Green agent の対処法提示（2） このように、Wiz を使って AI アプリケーションのリスクとその対処法を提示させて、使い慣れた CLI ツールや IDE から自然言語で対処する方法が示されました。これは、開発スピードを遅延させずにセキュリティを確保できることを意味しています。 関連記事 Google Cloud Next '26 の関連記事は、以下の記事一覧を参照してください。開催期間中は、記事が随時公開されます。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の山崎です。当記事は、Google Cloud Next '26 in Las Vegas の1日目に行われたブレイクアウトセッション「 Real-time multimodality: Building seamless experiences with the Gemini Live API 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 Gemini Live API の概要と特徴 自律的エージェントのプラットフォーム Gemini Live API を支える3つの柱 Affective dialog とコンテキストの記憶 Gemini Live API の新機能の紹介 Live Avatar（2026年4月現在、プライベートプレビュー） Live Avatar のデモ 企業の導入事例 Shopify : サポートアシスタント「Sidekick」 Citibank : 次世代金融ウェルスアドバイザー Otto : e コマースにおける対話型アドバイザー スクウェア・エニックス : 「真の相棒」としての AI セッションの概要 本セッションでは、 Gemini Live API のプロダクトリードを務める Fabien Mathey 氏や Google の Wendy Yin 氏が登壇し、Gemini Live API の基本機能や、新機能である 「Live Avatar」 の発表を行いました。 さらに、事例紹介として、Shopify、Citibank、ドイツの e コマース大手 Otto、そして株式会社スクウェア・エニックスの取り組みが紹介されました。特にスクウェア・エニックスからは「ドラゴンクエスト」シリーズの生みの親である堀井 雄二氏が登壇し、ゲームと AI の融合がもたらす未来のビジョンについて語られました。 Gemini Live API の概要と特徴 自律的エージェントのプラットフォーム 2026年4月現在、Gemini Live API は Gemini Enterprise Agent Platform 上で稼働しています。このプラットフォームは、単に AI に「指示」を出す段階から、タスクを「委任」する段階への移行を促すものです。 AI が知能を持つだけでなく、真の自律性を持つエージェントとして機能し、チームメンバーと同等の独立性と信頼性をもって行動するためには、人間が AI と対話するための全く新しい手段が必要であり、それを実現するのが Gemini Live API です。 参考 : Introducing Gemini Enterprise Agent Platform, powering the next wave of agents Gemini Live API を支える3つの柱 Gemini Live API は、以下の3つの特徴があります。 オーディオ（音声） 高品質で双方向の音声通話を提供します。会話が流暢であるだけでなく、ユーザーが AI の発言を途中で遮る（ Barge-in ）ことも可能です。これにより、人間同士が対話しているかのような自然な会話が実現します。 ビジョン（視覚） Gemini Live API は、画像、ライブビデオストリーム、画面共有など、AI に提供された視覚情報をリアルタイムで処理し、状況を理解します。 エンタープライズ対応 本番環境にアプリケーションを展開するために不可欠な、高いセキュリティ、スケーラビリティ、そして信頼性を提供します。 Affective dialog とコンテキストの記憶 セッション内では、Gemini Live API の リアルタイム処理能力 を示すデモが行われました。最初のデモでは、AI に英語で詩を読ませている途中で発言を遮り、「フランス語で教えて」と要求しました。AI はユーザーから主導権を奪うことなく、瞬時に言語をフランス語に切り替えて詩を読み上げました。 続いて Affective dialog のデモが披露されました。ユーザーが「来週は私の誕生日で、100人の友達を招待したから盛大なパーティーになる」とワクワクしたトーンで話しかけると、AI も明るい声で応じます。しかし直後に、ユーザーが「実は全員に断られて一人になってしまった」と悲しそうなトーンで伝えると、AI はその声のトーンの変化を途中で検知し、瞬時に共感を示すようなトーンへと変化しました。リアルタイムの会話に応じて感情的なトーンを調整するこの機能は、AI との対話をより人間らしいものにします。 さらに、 コンテキストの記憶 機能についても紹介されました。会話の冒頭でカメラを通じてユーザーが提示した配送ラベルを AI が視覚的に認識します。その後、カメラからラベルを外した状態で「先ほどの配送ラベルの番号は何だったか」と尋ねると、AI は正確な番号を回答しました。Gemini Live API は、単に音声を聞くだけでなく、ビデオストリーミングを通じて得た視覚情報をセッション全体を通して記憶に留めることができます。 Gemini Live API の新機能の紹介 Live Avatar（2026年4月現在、プライベートプレビュー） 本セッションで、ライブビデオ生成機能を備えた Gemini 3.1 Live API が紹介されました。 このアップデートにより、新たに Live Avatar 機能が追加され、高品質な音声対話のエクスペリエンスに加えて、リアルタイムでユーザーを見つめ、流暢で自然な表情で反応するエージェントを構築することができます。 Live Avatar のデモ ジョンソン・クリニックという仮想の診療施設の予約受付を行う Live Avatar のデモが行われました。 アバターは仮想の受付担当者として振る舞い、患者のフルネームや生年月日を正確に聞き取ります。その後、対面か遠隔診療かの希望、症状、希望する医師といった条件をヒアリングし、空いている予約枠を提示し、予約を完了させました。 企業の導入事例 Shopify : サポートアシスタント「Sidekick」 E コマースプラットフォームを提供する Shopify は、加盟店向けのアシスタントである「Sidekick」を Gemini Live API で強化しました。 デモでは、加盟店がドメイン設定タスクを実行するにあたって、Sidekick に音声で質問すると、AI が画面の UI をベースに手順を段階的に音声で案内し、加盟店の作業をリアルタイムにサポートしました。 Citibank : 次世代金融ウェルスアドバイザー 金融機関である Citibank は、Gemini Live API と Live Avatar を搭載した次世代のウェルスアドバイザー・モバイルアプリ「Citi Sky」を発表しました。 デモでは、顧客の譲渡性預金が来週満期を迎えるという状況下で、アプリ内の Live Avatar が、複数の選択肢を音声と画面で提示し、顧客からの回答を受けると、その場で更新手続きを完了させました。 Otto : e コマースにおける対話型アドバイザー ドイツの e コマース大手 Otto からは、プロダクト責任者の Richard Brunner 氏が登壇しました。 Otto は「Otto, good decision（Otto、良い決断）」というブランドポジショニングを掲げており、オンラインショッピングでの検索を「顧客にシステムを理解させる」ものから、「システムが顧客のコンテキストやニーズを理解し、良い決断を支援する」ものへと再定義しました。 デモでは、「完璧なコーヒーメーカーを探している」と話しかけたユーザーに対して、AI が「手早く淹れたいか、淹れる過程を楽しみたいか」といったユーザーが求める条件を自然な会話で深掘りし、ユーザーの好みに合った商品を提案する様子が示されました。 Otto はテキストベースのチャットボットも並行して構築を行い、そのテスト結果によると、テキストベースのチャットボットではシステムとユーザーの間の平均対話ターン数が「4回」であったのに対し、音声対話では「11回」に増加しました。 これは、音声対話によるエンゲージメントの飛躍的な向上を示しており、より深いアドバイザリー体験の提供に成功したと述べました。 スクウェア・エニックス : 「真の相棒」としての AI セッションの最後には、株式会社スクウェア・エニックスより「ドラゴンクエスト」シリーズの生みの親である堀井 雄二氏が登壇しました。 堀井氏は「人生はロールプレイングゲーム（RPG）である」という哲学を持ち、画面の向こうにいる一人一人の顔を浮かべながら、どうすれば面白いと思ってもらえるか、どうすれば驚いてもらえるか、そればかりを考えてきたと語りました。そして今、AI という新しい魔法の道具に巡り合い、ゲームと AI を融合させることで、ユーザー1人1人の言葉や行動に AI が心をあるかのように寄り添い、理解し合える世界が作れるのではないかと述べました。 デモ映像では、ドラゴンクエストの代表的なモンスターをベースとした「スラミィ」が登場し、プレイヤーからの問いかけに答える様子や、画面上のプレイヤーの外見をスラミィが視覚的に認識し、自発的に話しかける姿が披露されました。 堀井氏は、AI との冒険の旅が、あなたの人生の本当の力になるとし、それこそが、堀井氏が Google Cloud、ゲームを愛する全ての人と一緒に作り上げたい新しいロールプレイングゲームの姿であると語りました。 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 13 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit