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 で発表された Gemini Enterprise アプリ の新機能について、公式の投稿記事「Gemini Enterprise for the agentic task force: introducing long-running agents, agentic collaboration spaces, advanced governance, and more」の内容をもとに紹介します。 はじめに 名称変更とリブランディング 作業の自動化 強化されたエージェントデザイナー Skills が使用可能に 長時間稼働エージェント エージェント管理用受信トレイ A2UI のサポート Data Insights エージェントによる統合分析 Deep Research エージェントの強化 チームの生産性 プロジェクト Canvas の実装 エンタープライズ・エコシステム エージェントギャラリーと Marketplace の統合 Bring Your Own MCP ガバナンス 概要 Agent Identity Agent Registry Agent Gateway はじめに 以下の Google 公式投稿を参考に、Google Cloud Next '26 で発表された Gemini Enterprise アプリ の新機能を紹介します。なお、当記事で紹介する機能の提供ステータス（GA / Preview / Private Preview / Coming Soon）は2026年4月23日現在の情報です。 参考 : Gemini Enterprise for the agentic task force: introducing long-running agents, agentic collaboration spaces, advanced governance, and more 当記事では、上記の記事から画像を引用しており、引用した画像には「画像は公式投稿より引用」と付記してあります。 他の Google Cloud Next '26 の関連記事は、Google Cloud Next '26 カテゴリの記事一覧から参照してください。 blog.g-gen.co.jp 名称変更とリブランディング これまで「Gemini Enterprise」と呼ばれていた Google Cloud の生成 AI ウェブサービスは、 Gemini Enterprise アプリ という名称に変更されました。 これは、Google Cloud の AI 開発プラットフォームである Vertex AI が Gemini Enterprise Agent Platform と改称されたことに伴います。Gemini Enterprise Agent Platform という大きなブランドのもとに、Gemini Enterprise アプリや、新しく発表された AI エージェント向けサービス、そして従来からの Vertex AI サービス群が格納された形です。 Gemini Enterprise Agent Platform（画像は公式投稿より引用） 作業の自動化 強化されたエージェントデザイナー 従来より Gemini Enterprise アプリには、ノーコードエージェントを構築可能なエージェントデザイナー（Agent Designer）が付属していました。このエージェントデザイナーは、自然言語と UI 上の簡単な操作で、タスクを順次実行するノーコードエージェントを簡単に構築できるツールですが、従来は「親」と「子」の2階層のエージェントしか作れませんでした。 従来のエージェントデザイナー しかし今後、エージェントデザイナーは強化され、より複雑なノード構成を取ることができるようになります。Human in the Loop（HITL）のチェックポイントも作成できるようになり、これまでよりも充実したノーコードエージェントを構築可能になります。 当機能は2026年4月23日現在、まだ使用可能になっていません。 新しいエージェントデザイナー（画像は公式投稿より引用） Skills が使用可能に Gemini Enterprise アプリで Skills が使用可能になります。Skills は、LLM が自身の知識だけで完結せず、外部ツールや API 等と連携して作業できるように部品化された「実行可能な拡張機能」または「テキストのプロンプト」のことです。Google に特有な言葉ではなく、近年の AI エージェントツールにおいてよく用いられる用語です。 公式の投稿に掲載されたスクリーンショットからは、追加した Skills はオン・オフを切り替えることができることが示唆されています。 当機能は2026年4月23日現在、まだ使用可能になっていません。 Skills（画像は公式投稿より引用） 長時間稼働エージェント 長時間稼働エージェント （Long-running agents）は、大規模で複数のステップからなるワークフローを実行できる機能です。数時間から数日間、バックエンドで自律的に動作します。 従来の Gemini Enterprise アプリのエージェントは、ユーザーからのテキストプロンプトをきっかけに短時間動作し、同期的に回答を返すものでした。長時間稼働エージェントは、それとは一線を画すものです。 当機能は2026年4月23日現在、まだ使用可能になっていません。 エージェント管理用受信トレイ エージェント管理用受信トレイ （Inbox for agent management）は、エージェントの動作の経過や結果を受け取るためのメッセージボックスです。 メッセージは「入力が必要」「エラー」「完了」などに分類されます。長時間稼働するエージェントとの関連が深いものと想定されます。 当機能は2026年4月23日現在、まだ使用可能になっていません。 エージェント管理用受信トレイ（画像は公式投稿より引用） A2UI のサポート A2UI （Agent-to-UI）プロトコルは、エージェントが UI を動的に生成してユーザーとインタラクティブにやりとりをするための標準を定めた、オープンプロトコルです。Google が開発し、Apache 2.0 ライセンスのもとに公開しています。 参考 : a2ui.org A2UI が Gemini Enterprise アプリでサポートされるようになり、カスタムエージェントはリッチな UI を生成してユーザーとやりとりをすることができます。 当機能は2026年4月23日現在、Preview 公開されています。 参考 : Register and manage agents using A2UI and A2A Data Insights エージェントによる統合分析 Data Insights エージェント は、Gemini Enterprise アプリから利用可能な組み込みエージェントです。既にリリースされている Data Insights エージェントでは、BigQuery のデータを自然言語で問い合わせ可能でした。 Data Insights エージェントの分析対象に、ドキュメント、メール、チャットなどの非構造化データも加えることができるようになると発表されました。 新バージョンは2026年4月23日現在、まだ使用可能になっていません。 Deep Research エージェントの強化 Deep Research エージェント は、既に利用可能な Gemini Enterprise アプリの組み込みエージェントです。Web サイトや社内のデータソースに対して多段的なリサーチを行い、重厚なレポートを生成します。 発表内容は、Deep Research エージェントが強化されるというものでした。強化の内容は詳細に明かされていませんが、「バックグラウンドで何時間も動作」という説明があることから、より長時間の実行が可能になる等のものであることが示唆されています。 新バージョンは2026年4月23日現在、まだ使用可能になっていません。 チームの生産性 プロジェクト Gemini Enterprise アプリに プロジェクト 機能が追加されます。Google Workspace、Microsoft OneDrive、Teams チャットなど、さまざまなソースのコンテキストを統合して、特定のプロジェクトに特化したエキスパートエージェントを作成できる機能として説明されています。 1日目のキーノートの発表とあわせて解釈すると、これはデータソースを限定することでハルシネーションを低減するような仕組みであると想定されます。NotebookLM のように、特定のデータソースに基づいたタスクを Gemini Enterprise アプリに実行させられるものである可能性があります。 公式投稿のスクリーンショットからは、プロジェクトは複数の同僚と共有できるものであることが示唆されています。 当機能は2026年4月23日現在、まだ使用可能になっていません。 Gemini Enterprise アプリのプロジェクト（画像は公式投稿より引用） Canvas の実装 Gemini Enterprise アプリに Canvas が実装されます。Canvas は、リアルタイムの編集機能を備えたエディタであり、Google Workspace 等に付属の Gemini アプリには付属しています。 Gemini Enterprise アプリでは、Canvas がリアルタイムの共同編集機能を備えており、チームでドキュメントやスライドを共同編集できます。AI にスライドの雛形を生成させ、チームでそれを共同編集するという使い方が想定されます。この共同編集は、Gemini アプリにはない機能です。 さらに、Microsoft 365 との相互運用性も意識されており、Canvas で作成したドキュメントやスライドを一般的な Microsoft Office 形式にエクスポートできるようになります。 当機能は2026年4月23日現在、まだ使用可能になっていません。 Canvas（画像は公式投稿より引用） エンタープライズ・エコシステム エージェントギャラリーと Marketplace の統合 エージェントギャラリー は、Gemini Enterprise アプリ内で、ユーザーが使用可能なエージェントを一覧表示する画面です。備え付けの「Google が開発したエージェント」、管理者によって配布される「組織のエージェント」、自分でノーコードで作成した「マイエージェント」などがリストアップされます。 今後、エージェントギャラリーに Agent Marketplace が統合されます。Agent Marketplace ではサードパーティが販売する AI エージェントを購入し、Gemini Enterprise アプリにインストールできます。管理者の承認を経て購入されたエージェントのみが使用可能になります。 当機能は2026年4月23日現在、Preview 公開されています。 参考 : Add and manage A2A agents from Google Cloud Marketplace - Configure marketplace visibility Bring Your Own MCP Bring Your Own Model Context Protocol （BYO-MCP）の実装が発表されました。 この機能により、ノーコードエージェントが自社サーバーでホストされているツールを検出して実行できるようになり、自動化の可能性が広がるとされています。詳細の記述がないものの、Gemini Enterprise アプリに MCP を登録しておき、ノーコードエージェントから呼び出せるようになるものと考えられます。 当機能は2026年4月23日現在、まだ使用可能になっていません。 ガバナンス 概要 Gemini Enterprise Agent Platform 製品群に含まれる Agent Identity、Agent Registry、Agent Gateway といった機能により、組織内で複数の AI エージェントのガバナンスを、ガバナンスを発揮しながら相互に協働させられる世界観が示されました。 Google Cloud Next '26 の2日目に行われた Developer Keynote（開発者向け基調講演）でも、これらについては解説されました。以下の記事も参照してください。 blog.g-gen.co.jp Agent Identity Agent Identity は、AI エージェントに割り振られる、暗号化された固有の ID です。人間が使う Google アカウントや一般のアプリケーションが用いるサービスアカウントとも区別されます。コンテキストアウェアなアクセスと mTLS が前提となっており、意図しない実行環境以外では認証情報が使用できないようになっています。 Agent Identity は Gemini Enterprise Agent Platform Runtime（旧称 Vertex AI Agent Engine）および Gemini Enterprise で使用可能です。 Agent Identity は、既に一般公開（GA）されています。 参考 : Agent Identity overview Agent Registry Agent Registry は、組織内で AI エージェントや MCP サーバー、tools 等が発見されやすいよう、集約管理したり、ユーザーにキュレート（推奨して提示）したりするためのツールです。こちらも、従来からその機能の一部が Gemini Enterprise で使用可能になりました。 Gemini Enterprise アプリから Agent Registry に登録された A2A エージェントを呼び出せるほか、Gemini Enterprise アプリのエージェントデザイナーで開発したノーコードエージェントも Agent Registry に登録されます。また、独自開発したハイコードエージェント（フルコードエージェント）から、Gemini Enterprise アプリのノーコードエージェントを A2A プロトコルで呼び出すなど、 ハイコードエージェントとノーコードエージェント の相互連携も可能になります。 2026年4月23日現在、Agent Registry は Preview 公開されています。 参考 : Agent Registry overview Agent Gateway Agent Gateway は、ネットワークポリシー、データアクセス、セキュリティガードレールを一元管理できる、管理者向けソリューションです。プロンプトインジェクションなどのリスクからの保護を提供する、とされています。またコンテキストアウェアアクセスの能力を持っており、会社固有のルールを適用することで、承認されていないエンドポイントにエージェントがデータを送信してしまうことを防ぐともされています。 これらの機能は、 Model Armor 、 Identity and Access Management （IAM）、 Identity-Aware Proxy （IAP）などの既存サービスとの統合により実現されます。Access control policies によりエージェントがこれらのサービスを適切に使用するように交通整理するのが、Agent Gateway です。 2026年4月23日現在、Agent Gateway は Private Preview 公開されています。使用には Google への申請と、審査への合格が必要です。 参考 : Agent Gateway overview 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

2026年2月にNTTドコモおよびNECはAmazon Web Services（AWS）上に5Gコアネットワーク（以下、5GC）を構築し、国内初となるAWS上での5GC商用サービスを開始しました。 5GCとは、5G通信サービス全体を制御するコアネットワークを指します。加入者の認証・セッション管理からユーザーデータの転送制御に至るまで、通信事業者のサービス基盤として中枢的な役割を担うものとなります。 このAWS上の5GCを構築するにあたり、NTTドコモとNTTドコモビジネスはAI AgentとGitOpsを組み合わせた5GCの設計および構築の自動化を達成しました。 この取り組みについては3/2に ニュースリリース にて発表しておりますので、是非そちらもご参照ください。 本稿では、今回の取り組みのうち「AI Agentによる5GCの設計自動化」に焦点を当て、背景・課題・アーキテクチャを体系的にお伝えいたします。5GCに限らず、AI Agentを用いた既存設計業務の自動化をするためのノウハウ・具体的な構成の参考となれば幸いです。 背景 重厚長大な設計プロセス AI Agentを用いた解決 アーキテクチャ 統一的なインターフェースの作成 ナレッジベースを用いた既存ルールの参照 マルチエージェントによる柔軟性・拡張性の担保 MCPによるシステムとの統合 フロントエンド streamlit コンテナー AI Agentランタイム マルチエージェント実行基盤とエンドポイント管理 外部システム連携 可観測性とプロンプトチューニング チューニング システムプロンプトのチューニング ナレッジベースのチューニング 知見・ノウハウ フロントエンド AI Agent ランタイム チューニング まとめ 背景 本プロジェクトに先立ち、対象となる5GCの構築プロセスではCI/CDパイプラインの整備を実施していました。 このパイプラインではInfrastructure as Code（IaC）の原則に基づき、コードの変更を起点として、自動的にインフラの構築・アプリケーションのデプロイ・各種設定変更が実行されます。 また、すべてのインフラのコードや5GCアプリの設定、および5GCの設定値はGitリポジトリによって一元管理されており、いわゆるSingle Source of Truth（信頼できる唯一の情報源）を実現した状態にありました。 このように、5GCのシステムの状態はコードとして宣言的に記述されており、任意の時点における構成の再現・差分追跡が可能な状態となっていました。 その一方で、プロセス全体を効率化する上では、その起点となる「設計パラメータ」の正確な作成が前提条件となります。 今回の5GCのシステムでは、のべ数千にのぼるパラメータを設計する必要があり、これらは人手によって作成されていました。 加えて、デプロイ先のインフラはパブリッククラウド・プライベートクラウド・オンプレミスと多様であり、各インフラごとに異なる設計判断を要する状態でした。 この膨大かつ環境依存性の高いパラメータ設計が、プロセス全体の効率化をする上で主要なボトルネックとなっていました。 重厚長大な設計プロセス 一般的に複数チーム・複数ベンダーが協調する大規模なシステムの設計プロセスには、以下のような構造的課題が発生しえます。 設計に必要なドキュメントが多数存在し、それぞれ異なる記述方式・管理体制を持つため、設計全体の整合性を把握するためには相当の習熟を要する 各パラメータの設計ルールが別のファイルとして管理されており、仕様変更の際に関連箇所への反映漏れが生じやすい インフラ・ネットワーク・アプリケーションといった各レイヤーの設計が独立して行われており、レイヤー横断的な全体設計が困難である 長年の運用を通じて蓄積された経験則や判断基準が明文化されておらず、特定の担当者のみが知っている暗黙知が存在する 設計ドキュメントが組織やチームの境界によってサイロ化しており、担当領域外のエンジニアが必要な情報へアクセスすることが困難な場合がある 上記の課題が複合的に作用した結果、設計に時間を要し、待機時間が発生したり、レイヤー間の不整合に起因する手戻りが繰り返し生じることがあります。 さらに、システムは不定期なセキュリティのためのアップデートや機能追加があり、そのたびに設計プロセス自体の見直しと関係者間の調整が必要となるという構造になりえます。 今回取り組んだ5GCシステムにおいても例に漏れず、設計の開始から構築完了に至るまでには複数チームにわたる調整コストを含めて少なくない時間を要しており、これが新規システムやインフラの立ち上げ、構成変更を行う際の大きな制約となっていました。 AI Agentを用いた解決 これらの課題を解決するにあたり、以下の要件を満たすアプローチが必要だと考えました。 統一的なインターフェース：誰でも同じ方法で設計可能 不定期なアップデートへの耐性：ある程度システム仕様が変わっても追従できる柔軟性を保持 既存の設計ルールの保持：これまでのノウハウを捨てず活用可能 他レイヤーとの整合性：各レイヤー間の依存関係を加味した設計が可能 設計プロセスの自動化：人手によるパラメータ作成の削減 数千ものパラメータ設計プロセスを完全に自動化するシステムを1から開発することは容易ではありません。 しかし、全てを人手に頼り続けることにも限界があります。 そこで我々は「AI Agentによる自動設計」にチャレンジしました。 AI Agentで既存の設計プロセスを模擬させることができれば、自然言語で設計要件を受け取り、既存の設計ドキュメントを参照しながら、各レイヤーのパラメータを自律的に生成・調整することが期待できます。 また、設計範囲の異なる複数のAgentを組み合わせる仕組みを作ることで、レイヤーごとの設計ルールの変更や新レイヤーへの対応も柔軟に拡張できると考えました。 アーキテクチャ 上記の課題を解決するために、AI Agentを中心とした疎結合なマルチエージェントアーキテクチャを設計しました。 本アーキテクチャでは以下の構成要素にすることで課題解決を狙いました。 統一的なインターフェースの提供 ナレッジベースを用いた既存ルールの参照 マルチエージェントによる拡張性・追従性の担保 レイヤー間の整合性確認 MCPによるシステムとの統合 対象システムがAWS上に構築されていたことを踏まえ、今回はAWS上に構築された5GCの自動化から始めることとし、AI Agent実行基盤もAWS上に構築しました。 統一的なインターフェースの作成 設計者が統一されたインターフェースにて設計できるよう、Webインターフェースから自然言語で設計要件を入力できる仕組みを構築しました。 CLIの操作習熟や特定のパラメータフォーマットに関する事前知識を不要とすることで設計の敷居を引き下げることができると考えました。 ナレッジベースを用いた既存ルールの参照 既存の設計ルールを継承しながらパラメータを生成するため、これまでの手順書およびルールをナレッジベースに格納しています。 各Agentはナレッジベースを参照し、既存の設計ルールに準拠したパラメータを生成します。 新たな手順書やルールはナレッジベースのドキュメントとして追加するだけでAgentが即時に活用できるため、ナレッジの更新・管理コストも低く抑えられると考えました。 マルチエージェントによる柔軟性・拡張性の担保 不定期なアップデートへ追従可能な柔軟性と長期的な拡張性を確保するために、Agent-to-Agent（A2A）プロトコルを採用したマルチエージェントの構成にしました。 A2AとはAI Agent同士が相互に情報交換やタスク連携するための標準化されたインタフェースであり、各Agent間の直接的な依存関係を排除しつつ、疎結合な連携を可能とします。 これにより、複数のAgentが役割分担しながら協調動作するアーキテクチャを実現でき、高い拡張性および柔軟性を確保できます。 今回のアーキテクチャではインフラ層・アプリケーション層・コンフィギュレーション層といった各レイヤーに専用の設計Agentを配置し、それぞれが基本的に担当レイヤーのパラメータ設計を独立して実行しています。 特定レイヤーの対象が追加・削除された場合も、該当Agentを更新すれば対応可能であり、他Agentへの変更を最小化できる疎結合な設計となっています。 MCPによるシステムとの統合 各AgentがGitや外部システムと統一的かつ安全にやり取りするための通信基盤として、MCP（Model Context Protocol）を採用しました。 MCPはAI Agentが外部ツールおよびデータソースへアクセスするための標準化されたプロトコルであり、AI Agent とツールなどの間を疎結合にすることが可能となり、高い拡張性と再利用性を実現できます。 今回のプロジェクトではGitへのRead/Write操作や既存パラメータファイルの参照、ナレッジベースへのアクセスなどAgentがCI/CDと連携するための重要な基盤として機能しています。 各レイヤーのAgentは独立して動作しながらも、相互に通信してレイヤー間の整合性を確認しながら設計を進めます。 あるレイヤーの設計値を確定する際には、依存関係を持つ他レイヤーのAgentを協調させて動作させ、パラメータの矛盾が生じないよう調整されます。 設計済みのパラメータはGitOpsのワークフローに従ってリポジトリへ反映され、CI/CDパイプラインが自動的にデプロイを実行します。 これにより、「設計 → Gitへの反映 → 自動構築」というエンドツーエンドの自動化を実現しています。 次章では、フロントエンド、AI Agentランタイム、およびチューニングについて、具体的な内容を説明します。 フロントエンド AWS 上の Agent と人がやりとりを行う方法が必要になりますが、簡単にさまざまな人が使えるように今回は Web UI を提供することになりました。 今回、迅速に Web UI を構築し、再現性を担保するために以下の構成要素で構築しました。 Streamlit (GUI ライブラリ) コンテナー (GUI 提供サーバー) streamlit Streamlit は Agent とのやりとりをするための Web UI を簡単に構築できるようにしてくれる Python ライブラリです。 各種コンポーネントをブロックとして組み立てていくだけで簡単に Agent とやりとりするWeb UI を構築できます。 import streamlit as st # Web ページに以下の内容をレンダリング(内容は Markdown として解釈されます) # # My first app # Hello *World* st.write( """ # My first app Hello *world!* """ ) Streamlit は豊富な組み込みコンポーネントを供えているため、部品を追加・修正するだけで即座に反映を確認できます。 これによって迅速に開発を行えたため構築したいチャット Web UI をすぐに提供できました。 コンテナー Streamlit による Web UI はローカルにて開発をおこなっていました。 このアプリを AWS 上に展開していく際に AWS とローカルで環境が違うため差異を吸収する必要がありました。 その影響をなるべく少なくるすため環境差異を小さくできるコンテナー技術を採用しました。 今回は特に Docker Compose にすることでローカルでも AWS 上でも即座にアプリケーションのデプロイを行える環境を整えました。 AI Agentランタイム 本アーキテクチャにおけるAI Agentの実行基盤として、Amazon Bedrock AgentCoreを採用しました。 Amazon Bedrock AgentCoreとは、AWSが提供するフルマネージドなAI Agentを構築・実行・管理するためのランタイムおよび基盤機能を提供するサービスです。 各AgentはAmazon Bedrock AgentCore上のエンドポイントにデプロイされ、個別にバージョニング管理されています。 これにより、特定Agentのロジック変更やプロンプト改善をした場合でも、既存バージョンを維持したまま段階的な切り替えやロールバックが可能となっています。 マルチエージェント実行基盤とエンドポイント管理 Agent間の連携は、オーケストレーターAgentを中心とした制御構造を採用しています。 オーケストレーターAgentは、ユーザーからの入力を起点に、各レイヤー（インフラ・アプリケーション・コンフィギュレーション）に対応する設計Agentへタスクを分解・委譲し、各Agentからの結果を統合します。 この構成により、全体の制御フローを一元化しつつ、各Agentの独立性を維持しています。 A2AによるAgent間連携は、HTTPベースのエンドポイントにデプロイしています。 各AgentはAgentCore上に公開されたAPIエンドポイントを持ち、オーケストレーターAgentはこれらのエンドポイントに対してリクエストを送信することで、他Agentの機能を利用します。 リクエストには、以下のような情報を含める設計としています。 設計対象のコンテキスト（例：対象インフラや5GCの構成条件など） 他Agentから引き継がれた中間生成結果 実行対象タスクの種別（生成・検証・補正など） 各Agentはこれらの入力をもとに処理を行い、生成したパラメータおよびメタ情報をレスポンスとして返却します。 オーケストレーターAgentはこれらのレスポンスを統合し、必要に応じて再度別Agentへ問い合わせることで、レイヤー間の整合性を確保します。 また、Agent間通信においてはAmazon Bedrock AgentCoreのIdentity機能による認証・認可を適用し、呼び出し元Agentに応じたアクセス制御を実施しています。 これにより、意図しないAgent間の直接通信や不正な操作を防止しています。 外部システム連携 AI AgentからナレッジベースおよびGitLabなどの外部システムへアクセスする際には、Amazon Bedrock AgentCore Gatewayを経由し、AWS Lambdaを用いて処理を実行する構成としました。 これにより、Agentは外部システムの実装詳細を意識することなく、統一されたインタフェースで操作できます。 Lambda関数では主に以下の処理を担います。 ナレッジベースの検索・取得 GitLabリポジトリへのRead/Write操作、Merge requestの作成 AWS LambdaはVPCエンドポイントを介して他サービスと接続することで、外部システムとのセキュアな接続を実現しています。 可観測性とプロンプトチューニング 各Agentの実行ログおよび入出力（プロンプト・レスポンス）はAmazon CloudWatch Logsに集約され、システム全体の可観測性を担保しています。 これにより、以下のような運用が可能となります。 オーケストレーターAgentによる制御フローの追跡 各Agentの応答内容および生成結果の検証 エラー発生時の原因特定 特に後述するプロンプトチューニングにおいては、実際のログをもとに生成結果と期待値との差分を分析し、プロンプトおよびナレッジベースの改善を継続的に実施しました。 これにより、設計パラメータの生成精度と一貫性の向上を図っています。 以上のように、Amazon Bedrock AgentCoreを利用してエンドポイント管理機能やオーケストレーター中心の制御構造、A2Aによる協調実装ならびにセキュアな外部連携および可観測性基盤を統合することで、実運用に耐えうるマルチエージェント基盤として設計されています。 チューニング AI Agentが期待どおりの設計結果を出力するためには、チューニングの方針を定める必要があります。 前述のとおり、手順書やルールをドキュメントとしてナレッジベースに格納しています。 しかし、対象となるドキュメントは多種多様かつ更新頻度も高いため、闇雲に格納するだけでは期待どおりの出力は得られません。 そのため、AI Agentが適切な情報を参照できるよう、ナレッジベースの構成を整理する必要がありました。 一方で、ナレッジベースの整理だけでは AI Agent の振る舞いまでは制御できないため、これらはシステムプロンプトで制御する必要があります。 このように、「Agentに何を読ませるか」をナレッジベースで、「AI Agentにどう振る舞わせるか」をシステムプロンプトで、それぞれチューニングを行いました。 システムプロンプトのチューニング 各 AI Agent のシステムプロンプトは、汎用的な記述に留めています。 具体的には「あなたは○○レイヤーの設計を担当するAgentです」のように、担当範囲と役割を明示する程度としています。 その目的は、過度に詳細な指示を与えるのではなく、AI Agent が担当範囲内で自律的に判断・動作できる状態を実現するためです。 実際にプロンプトを汎用的な記述に留めることで、ある5GCの構成要素を複数設計するケースや異なる構成要素を新たに設計するケースなど、複数の設計パターンにシステムプロンプトの修正なしで対応できるようになりました。 ナレッジベースのチューニング ナレッジベースには、既存の設計ドキュメントに加え、これまで明文化されていなかった暗黙知もドキュメント化した上で格納しました。 ただし、暗黙知の全てをドキュメント化することは現実的とはいえませんでした。 実際の設計プロセスでは、複数のドキュメントを横断的に参照しながら必要なパラメータを選定する作業を繰り返す必要があり、ドキュメント間の表記揺れも存在したからです。 そこで、頻出する構築パターンに絞って暗黙知のドキュメント化を行い、表記揺れや横断的な参照を含むドキュメント群についてはLLMが柔軟に情報を抽出できるナレッジベースの特性を活かす構成としました。 また、ナレッジベースはレイヤーごとに分割し、各 AI Agent が自身の担当レイヤーに対応するドキュメントのみを参照する構成としています。 これにより、AI Agentが必要な情報のみを参照し、担当レイヤーに適した設計判断を行えるようになり、設計時間の短縮を達成しました。 なお、レイヤー間で依存関係を持つパラメータについては、前述のA2Aプロトコルを通じたAI Agent間の協調によって整合性を担保しています。 知見・ノウハウ フロントエンド Streamlit はコンポーネントを組み合わせればすぐに Web UI を開発できるところは非常に魅力的です。 一方、 Streamlit は以下のような特性をもつため複雑な Web UI を作っていこうとすると開発コストが増えていきます。 イベント毎に画面全体を再描画する仕組みであり、状態管理がセッションでしかおこなえない 各種コンポーネントを自由に組み合わせられず、正解となる組み合わせ方法は少なく、複雑なことができない そのため、 Proof of Concept として利用するのには非常に魅力的なライブラリでありつつ本番環境での利用には注意が必要です。 Streamlit を利用される際にはこの特性を考慮して適切な利用を心掛ける必要があります。 AI Agent ランタイム Amazon Bedrock AgentCoreを利用した知見として、AWSの各種サービス（AWS Lambda、Amazon IAM、Amazon Cloudwatchなど）とネイティブに統合されている点が挙げられます。 これにより、既存のAWS上のワークロードやアーキテクチャと親和性が高く、既存のリソースや運用設計を活かした形でAI Agentを組み込むことが可能でした。 結果として、セキュリティポリシーやネットワーク構成を維持しながらスムーズに導入できる点が、本構成における大きな利点となっています。 具体的には、外部システム連携はAWS Lambdaを通じて実装することで既存の処理ロジックやAPI連携資産をそのまま活用でき、Amazon IAMによる認証・認可を統一的に適用することでセキュリティポリシーの一貫性を維持できます。 また、ログおよび実行トレースはAmazon CloudWatch Logsに集約されるため、各Agentの挙動やプロンプト・レスポンスを一元的に可視化でき、トラブルシュートやプロンプト、ナレッジベースのチューニングを効率的に実施可能でした。 このように、Amazon Bedrock AgentCoreはAWSのエコシステムと密接に連携するようになっているため、既存環境への適用において変更適用負荷や設計変更を最小限に抑えることができました。 その結果、本プロジェクトにおいても、従来のCI/CDパイプラインやネットワーク設計、セキュリティ要件を維持したままAI Agentを組み込むことができ、スムーズかつ実用的な形での導入が実現できました。 チューニング プロンプトのチューニングにおいては、制約の強いプロンプトから段階的に汎用化していくアプローチが有効でした。 最初は汎用的なプロンプトでAI Agentに設計を進めさせていましたが、処理時間が想定以上にかかるケースがありました。 この原因がプロンプトにあるのかシステム構成にあるのかを切り分けるため、まず参照すべきドキュメントの順序や出力フォーマットを厳密に固定したプロンプトに切り替えました。 プロンプト側を固定することで、システム側のボトルネックを特定する狙いです。 その結果、Git上のパラメータファイル（約2,000行）の読み込みが処理時間増大の主要因だと分かりました。 これに対し、ファイルを固定部分と変更部分（約50行）に分離してAgentには変更部分のみを読み書きさせることで、処理時間を約15分から約5分へ短縮できました。 このように、プロンプトを固定化することは、ボトルネック早期解消に役立ちました。 汎用的なプロンプトに戻しても、処理時間が安定しました。 まとめ 本稿では、5GCの設計プロセスにおける課題に対し、AI Agentを組み合わせたアプローチにより、設計の自動化と効率化を実現したアーキテクチャについて紹介しました。 疎結合なマルチエージェント構成やナレッジベースの活用、AWSとの統合により、属人性の排除と再現性の高い設計プロセスを実現できることを示しました。 今後は、本アーキテクチャのさらなる高度化を進めるとともに、5GC以外のシステム設計や他領域への適用を視野に入れ、より汎用的かつ実用的なAI Agentの構築を実施する予定です。