社会インフラ業務で需要が増加しているGIS（地理情報システム）について解説します。代表的なツール（ArcGIS、QGISなど）の種類やトレンド、都市計画などの用途、活用に必要なプログラミング言語などの基礎知識をご紹介します。

本ブログは、KDDI株式会社 高山 伸也 氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 安藤 が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクトの安藤です。 位置情報データを活用した商圏分析は、小売・飲食・観光業界において出店計画や集客戦略の意思決定に広く活用されています。今回は、 KDDI株式会社 （以下、KDDI）が提供する位置情報ビッグデータ分析サービス「KDDI Location Analyzer（以下、KLA）」の新機能開発事例をご紹介します。特に Amazon Redshift Data Sharing 機能を活用することで、既存機能への影響を抑えながら新機能を追加するアーキテクチャを実現しています。 導入背景 KDDI Location Analyzer とは KDDI は au の携帯電話ネットワークから取得した GPS 位置情報データを活用した商圏分析サービス「 KDDI Location Analyzer 」を 2019 年 6 月にサービス開始しました。位置情報統計データ・GIS データを統合し、125m メッシュ単位・町丁目単位での高精度な商圏分析を実現しています。サービス開始から約7年間でのべ 1,000 以上の民間企業・自治体に利用されており、小売・飲食業界の店舗出店戦略から観光業界・地方公共団体まで幅広い分野で活用されています。インフラには、位置情報というセンシティブなデータを扱う上で KDDI 社内で利用が認定されたクラウド環境として AWS を採用しています。 新機能開発の背景 観光需要の回復と新たなニーズ 観光需要の回復を背景に、地域の魅力創出や商圏の最適化に向けたデータ活用の重要性が高まっています。行政や企業においては、定量的な人流データに基づく政策・戦略立案がこれまで以上に求められるようになりました。 特に、観光地や商業エリアでは、単なる来訪者数の把握にとどまらず、以下のようなニーズが顕在化していました。 来訪前後の行動パターンの把握・分析 宿泊エリアの分析 店舗間の回遊構造の可視化 携帯電話の GPS 位置情報は時系列でトレースできることが最大のメリットです。既存ユーザーからも「この強みをもっと活用した機能が欲しい」という要望が寄せられており、それが今回の新機能開発の直接的なきっかけとなりました。 新機能「観光動態・店舗間回遊の可視化機能」 これらのニーズに応えるため、KDDI は KLA の国内居住者版に以下の3つの新機能を追加しました。 （1）前後立ち寄り分析 都道府県・市区町村、またはジオフェンスで指定した施設に対し、「どこから来訪し、次にどこへ向かったのか」を可視化します。前後時間帯指定スライダー（最大前後 180 分）を動かすことで時系列の変遷を確認でき、スライダーの操作に応じてヒートマップや滞在者数グラフが即座に更新されます。 来訪者区分：全体 or 都道府県外 or 市区町村外（施設選択時） 集計期間： 1 日〜1 カ月、時間帯： 5 時〜29 時（30 分単位） 属性：性年代・居住者・勤務者・来街者 集計結果：周辺滞在者数グラフ（最大前後 180 分）、立ち寄り地滞在者数リスト（町丁目・市区町村・都道府県） 活用シーン：域内の観光ルート立案、店舗販促・品揃えやメニュー開発 「前後立ち寄り分析」操作画面 （2）宿泊地分析 指定した市区町村に来訪した旅行者の宿泊エリアを可視化します。 来訪者区分：旅行者 集計期間： 1 日〜 1 カ月、日にち区分：期間全体・日〜木・金・土・祝休前日 属性：性年代 集計結果：旅行者数グラフ（性年代×日にち区分、宿泊・日帰り）、宿泊施設タイプ別施設数・部屋数（市区町村別）、宿泊地ランキングリスト（市区町村×日にち区分） 活用シーン：地域の宿泊供給と旅行者ニーズを総合的に分析 「宿泊地分析」操作画面 （3）発地分析 特定期間に指定した目的地（都道府県・市区町村）へ来訪した人の出発地*を可視化します。 *：来訪前日の宿泊地または居住地（深夜滞在地） 来訪者区分：全体 or 旅行者 集計期間： 1 日〜 1 カ月、時間帯： 5 時〜 29 時（30 分単位）、日にち区分：期間全体・平日・祝休日 属性：性年代・居住者・勤務者・来街者 集計結果：発地別来訪者数グラフ（性年代・居住地別）、日にち区分別来訪者数グラフ（市区町村別）、発地別来訪者数リスト（都道府県・市区町村×日にち区分） 活用シーン：観光プロモーション施策の検討、経済圏としての強み弱みの把握とサービス改善 「発地分析」操作画面 システムアーキテクチャ 全体構成 KLA のインフラは AWS 上に構築されており、以下のような構成となっています。 KLAのアーキテクチャ ワークロードは既存機能と新機能で処理フローが異なります。 既存機能では、ユーザーのリクエストを Amazon ECS Fargate 上の Web サーバが受け取り、Amazon Redshift Serverless（既存機能の集計基盤）に直接クエリを発行して結果を返却するシンプルな同期処理です。 新機能の回遊分析は、複数地点間の時系列データを処理するため、クエリ1件あたりの実行時間が集計対象地域や集計条件によって数分程度に及ぶ重い処理です。RPU を上げることでクエリ実行時間を短縮できる可能性はありますが、KLA ではコストと UX のバランスを取った設定のもと、同期処理ではユーザーを長時間待たせてしまうため非同期処理を採用しています。Web サーバがリクエストを受け取ると Amazon SQS にメッセージを送信し、AWS Lambda がそれを受けて複数の AWS Fargate タスクを並列起動します。各タスクが Redshift にクエリを発行し、処理結果を Amazon Aurora に格納します。アプリケーションが定期的に Aurora を参照して結果をユーザーに返す非同期構成です。SQS でキューイングすることで、Fargate タスクの起動から結果の Aurora への格納までの一連の集計処理を統一的に管理しています。ユーザーには「集計中」ダイアログを表示することで処理中のタイムラグを意識させない UX を実現しています。 Amazon Redshift Data Sharing の活用 新機能の開発にあたり、2 つの課題がありました。 1 つ目はワークロード分離です。既存機能は同期処理で応答を返せるクエリである一方、新機能の回遊分析は前述の通り数分程度かかる重いクエリです。同一ワークグループで動かすと互いの処理が干渉するリスクがあるため、ワークグループを分離する必要がありました。なお、Amazon Redshift Serverless には AI 主導のスケーリングと最適化機能 があり、ワークロードパターンを機械学習で予測してクエリ実行前にコンピュートリソースを自動最適化することで、バースト的な高負荷クエリが他のクエリに影響を与えないよう対応できます。一方、ベースとなる RPU やサービス要件、クエリ特性、実行周期などが定常的に大きく異なるワークロードを扱う場合には、ワークグループを分離する構成も有効な選択肢となります。 2 つ目はテーブル設計です。新機能の回遊分析では、複数地点間の時系列データを効率的に処理するため、既存テーブルとは異なるソートキーを持つマートテーブルを新たに作成する必要がありました。まずマテリアライズドビュー（MV）の活用を検討しましたが、KLA が扱う位置情報データは約7年4か月分・数十 TB 規模で今後も増加し続けるため、初回作成に 1 日以上かかるという課題がありました。また、日次データ連携でデータが追加されるたびにリフレッシュが必要となる負荷に加え、ユーザーがエリア・期間・属性を自由に組み合わせて指定するサービス特性上、クエリパターンごとに MV を作り分けると管理が煩雑になることも懸念されました。今回の KLA のデータ規模とサービス特性には MV は適合しないと判断し、新機能のクエリパターンに最適化したソートキーを持つマートテーブルとして作成する方針を選択しました。 しかし、ワークグループを分離した上で新機能用ワークグループにもテーブルを持つ構成にすると、日次データ連携や VACUUM・ANALYZE などのテーブル管理を両方のワークグループで行う必要が生じます。この課題を解決する手段として Amazon Redshift Data Sharing を採用しました。 Data Sharing とは、データをコピーや移動することなく、異なるワークグループ・クラスター・AWS アカウント間でライブデータへの即時アクセスを可能にする機能です。データを保有する側をプロデューサー、参照する側をコンシューマーと呼び、プロデューサーが datashare（共有単位）を作成してデータベース・スキーマ・テーブル・ビューなどを公開します。コンシューマーはその datashare に接続することで、データの実体を持たずに直接クエリを実行できます。 KLA での具体的な構成は以下の通りです。プロデューサー側の既存機能ワークグループに、従来機能用と新機能用の2種類のテーブルを作成し、新機能用テーブルを Data Sharing でコンシューマー側に公開しています。コンシューマー側の新機能ワークグループはデータを持たずにこのテーブルをリアルタイムで参照するだけで済み、テーブル管理はプロデューサー側に集約されます。これにより、ワークロード分離とテーブルの一元管理を両立しています。 今後の展望 新機能のリリースに先立ち実施したユーザー向け説明会では、「前後立ち寄り機能はまさに欲しかった機能」「活用イメージが湧きやすい」といった声が寄せられ、特に民間企業からの期待が高まっています。 運用改善とさらなるパフォーマンス向上 現在も継続的な改善に取り組んでいます。 パフォーマンスの継続的な改善： 現在の構成では、プロデューサーワークグループ上でクエリ実行と VACUUM・ANALYZE などのメンテナンス処理が同時に行われるため、数十 TB 規模のデータを扱う KLA では両者が干渉するケースがあります。なお、VACUUM・ANALYZE は現在定期バッチで対応しており、Redshift のオートノミクス（自動実行）機能は利用していません。2026 年 2 月に Amazon Redshift のオートノミクス機能が強化され、 自動バキューム・自動分析などのメンテナンス処理に追加コンピューティングを割り当てることで、ユーザーワークロードへの影響を抑えながら自動実行できるようになりました 。VACUUM・ANALYZE の自動実行については、日次データ連携との実行タイミングの兼ね合いも考慮しながら、追加コンピューティング割り当て機能の活用も含めて引き続き検討を進めていく予定です。 メンテナンス作業の効率化： ⼤規模なデータ追加やテーブル変更など、Redshift に⼤きな変更が必要な場合では、サービス提供を止める時間を最小限に食い止めるため、短時間でメンテナンス作業を終わらせる必要があります。Redshift へのデータ投⼊所要時間を考慮すると、事前にスナップショットから新規 Redshift を復元して変更を加えておき、その短時間のサービス停止中に、Redshift を切り替えるという運⽤を現在取っていますが、この⽅法では、新規 namespace を作成するたびに datashare の参照先をコンシューマー側で、⼿動で変更し直す作業が発生します。2026 年 3 月、Amazon Redshift Serverless に スナップショットから同一 namespace にリストアした際に datashare のパーミッションが自動で維持される機能 が追加されました。新規 namespace への復元ではなく既存の namespace への上書きリストアに運用を切り替えることで、コンシューマー側の手動変更作業を解消できる可能性があり、今後検討を進めていく予定です。 まとめ KDDI による本取り組みは、位置情報ビッグデータ分析における Amazon Redshift Data Sharing の実用的な活用事例です。既存機能と新機能でワークロード特性が根本的に異なるという課題に対し、Data Sharing を活用してコンピューティングを分離することで、ワークグループ間のデータコピーなしに各機能に最適化したテーブル設計とリソース配分を実現しました。 従来の公的統計データでは把握できなかった「人の動き」を、GPS 位置情報データと AWS のスケーラブルな分析基盤を組み合わせることで可視化し、観光施策や商圏戦略の高度化に貢献しています。今後の展開と成果に注目していきたいと思います。 著者 高山 伸也 KDDI株式会社 パーソナル事業統括本部 システム開発本部 プラットフォームビジネス部 安藤 麻衣 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト  

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