はじめに 2026年6月25日（木）・26日（金）の2日間、千葉・幕張メッセにて AWS Summit Japan 2026 が開催されました。 AWS Expo エリア内の AWS Industries Zone では、流通小売・消費財・飲食業界向けブースとして「AI エージェントが業務の主役になる日」をテーマに6つのデモと2社のお客様事例を展示しました（ 事前告知ブログ ）。本ブログでは、そのうちサプライチェーン領域の展示「AI エージェントで危機対応 — 小売×消費財の混乱を AI と人が即座に解決」にフォーカスし、デモの技術的な仕組み、来場いただいたお客様の反応、そして「今日から始められる」次のステップをご紹介します。 デモで展示した内容 デモのコンセプト 台風による広域配送停止、ドライバー不足、SNS でのバイラル化による需要急増、そして石油由来製品の調達難。サプライチェーンの現場では、いつ「想定外」が起きてもおかしくありません。商品そのものだけでなく包装資材やプラスチック容器など、石油由来の原材料に依存する消費財メーカーにとって、調達コストの急変動は今まさにリアルな脅威です。従来、こうした外乱への対応は担当者の経験に依存し、検知から実行まで数時間〜数日を要していました。 本デモでは、「AI エージェントが外乱を検知し、影響を分析し、代替案を探索・提示し、人間が承認したうえで実行と通知までを一気通貫で行う」この一連のオペレーションを、ライブで実演しました。お客様の業種に合わせて、小売シナリオ（店舗の在庫不足に対する最適な振替ルートの提案）と消費財シナリオ（原材料供給停止時の代替サプライヤー探索）の2パターンをご覧いただきました。 図1: デモ画面。上部: AI エージェントの提案に対し、人間が承認・拒否を実施した結果、判断によって守ることができた売り上げ高と回避された遅延違約金を表示。下部: AI が作成した先方へのメールや発注書のドラフトなどを表示 システム構成 図2: サプライチェーン危機対応デモのシステム構成図 本デモのアーキテクチャは以下の要素で構成されています。 レイヤー サービス / コンポーネント 役割 フロントエンド Amazon S3 + Amazon CloudFront + AWS WAF + Amazon Cognito ユーザー認証とWebアプリ配信 リアルタイム通信 AWS AppSync Events AI の思考プロセス (Chain of Thought) やツールの呼び出しをリアルタイムにストリーミング可視化 エージェント基盤 Amazon Bedrock AgentCore Runtime + Strands Agents SDK マルチエージェントのオーケストレーションと実行 データアクセス MCP サーバー（各シナリオごとに6つ、計12種類のツール） 遅延出荷取得、在庫インパクト計算、財務インパクト計算、転送オーダー作成など データストア Amazon Aurora DSQL サプライチェーンデータの格納（在庫、出荷、サプライヤー、BOM等） 安全性 Amazon Bedrock Guardrails エージェントの出力に対するガードレール適用 セッション管理 Amazon S3 Human-in-the-Loop の承認状態を保持 全体の流れはシンプルです。ユーザーはフロントエンドから指示を出し、その指示をエージェント基盤上のマルチエージェントが受け取ります。各エージェントは MCP サーバーを介して Amazon Aurora DSQL 上のサプライチェーンデータ（在庫・出荷・サプライヤー・BOM など）にアクセスし、分析や提案を行います。そして、エージェントの出力には Amazon Bedrock Guardrails を適用し、安全性を最優先に担保しています。 このアーキテクチャで特に工夫したポイントが2つあります。 工夫ポイント① 人間による承認の必須化（Human-in-the-Loop） 本デモでは、AI エージェントがどれだけ優れた分析や提案を行っても、人間の明示的な承認なしには転送オーダーやワークオーダーの発行といった実行系のアクションを一切実行できない設計としています。これは「AI が勝手に発注してしまう」「意図しない振替が走る」といった現場の懸念に正面から応えるものです。 技術的には、Strands Agents SDK の Interrupt 機能を活用しています。Supervisor Agent が実行サブエージェントを呼び出す直前で Hook がセッションを一時停止（Interrupt）し、フロントエンドに承認リクエストを送信します。ユーザーが承認すればセッションを再開して実行サブエージェントを呼び出し、却下すればその呼び出しはスキップされ、対象の発注や振替アクションは実行されません。会話コンテキストは Amazon S3 上のセッションマネージャーに永続化されるため、中断・再開が可能です。なお、Supervisor Agent のプロンプトには「実行エージェントを必ず呼び出し、”pending approval” と書いてスキップすることは禁止」と明記し、AI がこの承認フローをバイパスしないよう制御しています。 工夫ポイント② 思考プロセスの可視化（Chain of Thought） AWS AppSync Events による WebSocket 通信では、今どのステップを実行中か、何を分析しているかといった AI エージェントの思考プロセスをリアルタイムにフロントエンドへストリーミングし、可視化しています。デモではこの思考プロセスのログをリアルタイムに表示することで、承認を求められた際に「なぜこの提案に至ったか」の根拠が見える状態を作り、来場者の皆さまにも納得感を持ってデモの流れを追っていただくことができました。 マルチエージェント設計 本デモでは、1つの Supervisor Agent（サプライチェーン管理エージェント）が全体のオーケストレーションを担い、4つのサブエージェントに作業を委譲する構成を採っています。 Retail シナリオ: 在庫移動分析サブエージェント — 振替元候補の探索と実現可能性の評価（分析のみ） 転送オーダー実行サブエージェント — 承認された振替の実行（実行のみ） CPG シナリオ: 代替サプライヤー探索サブエージェント — リードタイムが最短の代替を優先的に探索（分析のみ） ワークオーダー実行サブエージェント — 承認された発注の実行（実行のみ） 「分析」と「実行」を明確に分離している点がポイントです。分析エージェントは実行すべきアクション（推奨案）を生成するだけで、実際のオーダー作成は行いません。実行エージェントは、分析エージェントが提案したアクションを忠実に実行します。この分離により、Human-in-the-Loop の承認ステップを自然に挟み込むことができます。 プロンプト設計 本デモで最も多くご質問いただいたのが「AI にどうやって業界固有の制約を守らせているのか」という点です。答えは、判断ロジックをコードではなくプロンプトとデータで定義していることにあります。 ワークフローの明示的な定義 Supervisor Agent のプロンプトには、7つのステップが明確に定義されています: ステップ1: 遅延出荷の取得 ステップ2: 在庫インパクト計算 & プロモーションデータ取得（並列実行） ステップ3: 在庫移動オプション評価（並列実行） ステップ4: 財務インパクト計算（並列実行） ステップ5: 転送オーダー実行（並列実行） ステップ6: 通知生成（メール + チャット） ステップ7: サマリー 各ステップで呼び出すツール、入出力のフォーマット、並列実行のルールが具体的に記述されています。 並列実行の指示 パフォーマンスを最大化するため、独立したツール呼び出しを同一ターンで並列実行するよう明示的に指示しています: ## CRITICAL PERFORMANCE RULE — PARALLEL TOOL CALLS You MUST call independent tools in the SAME response turn so they execute concurrently. - Steps 2 and 3 are independent — call retail_calculate_inventory_impact AND get_promotion_data for ALL shipments in ONE turn. これは「互いに依存しないツールは、同じ応答ターン内でまとめて呼び出して並列実行せよ」という指示です。例に挙がっている在庫インパクト計算（retail_calculate_inventory_impact）とプロモーションデータ取得（get_promotion_data）のように、独立した処理を1度のターンで同時に走らせることで、逐次実行に比べて待ち時間を短縮しています。 業界固有制約のプロンプト化 小売・消費財業界でよくある制約条件を、プロンプト内のルールとして記述しています: コールドチェーン対応 — 温度区分（常温/冷蔵/冷凍）に合わない輸送候補を除外 賞味期限管理 — 賞味期限に対し、リードタイムが短すぎる候補を除外 コスト閾値警告 — 代替サプライヤーのコストが20%以上高い場合に警告フラグを付与 使用期限チェック — 在庫の使用期限が30日以内の場合は新規調達を優先 これらはすべてプロンプト上のルール記述とデータベースのカラムの組み合わせで実現しており、ハードコーディングは行っていません。つまり、開発者でなくても業務担当者が自然言語のプロンプトを通してルールを記述し、改善していくことが可能です。 デモを通してお客様にお伝えしたこと 既存システムへの外付けアプローチ AI を業務に取り入れるには、既存システムの大がかりな刷新が必要だと思われがちです。しかし本デモでお見せしたのは、既存の資産を活かすアプローチでした。既存のデータ（在庫・出荷・サプライヤー情報）をそのまま活用し、MCP サーバー経由でエージェントに接続するだけで、AI がシミュレーションを実行できます。既存のシステムを置き換える必要はなく、AI による分析の仕組みを「外付け」できることがこのアーキテクチャの強みです。 段階的に上げられる自動化レベル 本デモでは「AI エージェントによる自動化レベル」を5段階で定義し、レベル 1〜3 を実演しました: レベル AI に任せること 概要 1 シミュレーション データ読み取り・分析のみ。BCP訓練に活用 2 アクションプラン作成 通知・発注書を自動生成。人間が確認して実行 3 承認付き自動実行 AI が提案→人間が承認→実行。財務インパクト事前表示 4 ルールベース自動実行 ポリシー（金額閾値等）で自動承認 5 学習型自動実行 過去の承認パターンを学習し自動判断 ただし、レベル 5 が必ずしもゴールではありません。業務特性やリスク許容度に応じて最適なレベルを柔軟に選べるのがこの設計の強みで、「まずは レベル 1 のシミュレーションから始める」というのが、私たちがこのブースでのデモを通してお伝えしたかったことです。レベル 1 は既存データを AI に与えて業務影響を分析するだけなので、実業務のプロセスを変更せずに今日からでも始められます。「もし明日、台風で広域配送が5日間停止したら？」といった問いを既存データに投げかけ、避難訓練のように繰り返すことで対応プロセスの練度を上げ、効果を実感してから次のレベルに進めば良いのです。 来場いただいたお客様の反応 2日間のブース展示を通じて、多くのお客様と対話させていただきました。展示員の振り返りからいくつかの共通テーマが浮かび上がりました。 BCP 訓練という普遍的な課題 「サプライチェーンの混乱を、AI と人が即座に解決する」がこのブースのメッセージですが、いざという時に即応するには日頃の備えが欠かせず、本デモではその備えをシミュレーションから小さく始められることをお見せしました。ブースを訪れたお客様のほぼ全員が、その備えとなる危機管理や BCP 訓練を「やりたいがリソースや手段がなくてできていない」とおっしゃっていました。大雪や台風など実際に困っている企業様からは「これまで担当者が各所に何本も電話をかけて対応していた。AI が初動を担ってくれるだけでもありがたい」という声をいただきました。危機対応は業種や規模を問わず共通の悩みであり、既存の業務を止めずに試せる手軽さへの共感とともに、AI エージェントへの期待の高さを肌で感じました。 AI エージェント活用の具体的なイメージ 「AI エージェント」という言葉は浸透しつつある一方、具体的に何ができるのか、自社ではどう使えるのかをイメージできていないお客様が多くいらっしゃいました。エージェントの思考プロセスを可視化し、Human-in-the-Loop で人間が介在するポイントを示したことで、「具体的なイメージが湧いた」「エージェントの処理を見て初めて理解できた」というフィードバックを多くいただきました。 データ整備の課題への気づき 興味深いことに、本デモをきっかけに「自社には AI に渡せる整理されたデータがない」と気づかれるお客様が少なくありませんでした。データが正規化されていない、必要な情報が構造化されたDBに入っていない、といった課題です。しかし実際には、フォーマットの異なる Excel ファイルが散在しているような状態でも、AI は人間が思う以上にデータを理解・整理し、人が気づきにくいインサイトまで引き出してくれます。完璧なデータ基盤が整うのを待つ必要はなく、まずは今あるデータから始めて AI と壁打ちしながら、ワークロードの成長と並行して育てていけばよい。この考え方に共感いただけたケースも多くありました。 AgentCore のモジュラー性への評価 Amazon Bedrock AgentCore 自体をまだ触ったことがないお客様が大半でしたが、機能がモジュラーな部品として提供されている点に好意的な反応をいただきました。たとえば、さまざまな認証・認可を統合管理してくれる Amazon Bedrock AgentCore Identity や、エージェントに短期・長期の記憶を持たせる Amazon Bedrock AgentCore Memory といった部品です。特に、既存の REST API や Lambda 関数をマネージドで MCP 化してくれる Amazon Bedrock AgentCore Gateway には「すばらしい」という声が上がりました。すぐに使いたい、アセットはあるか、という質問も複数いただき、そうしたお客様には後述のハンズオンワークショップをご案内しました。 導入コストへの反応 「一回のシミュレーションでどのくらいコストがかかるのか」という質問に対しては、本デモの構成では1回あたり数百円程度でシミュレーションを実行できることをお伝えすると、想像より安いと好意的に受け止められました。 Amazon Bedrock や Amazon Bedrock AgentCore の従量課金モデルなら固定費用や初期投資なしで始められる点も、大きな安心材料になるとの反応をいただきました。「使っていない間も費用が発生するのではないか」という懸念に対しても、サーバーレスで使った分だけの課金となり、待機コストを気にせず導入できる点をご評価いただきました。コストのハードルが低いことは、まず小さく試して効果を確かめたいというニーズにも合致します。 リアルタイムなデータ連携の重要性 有事の際には代替先に各社から注文が集中するため、AI が判断に使う情報にリアルタイムでアクセスできることが重要だという、現場ならではの指摘もいただきました。だからこそ、AI が MCP サーバー経由でリアルタイムにデータを取得し、瞬時に選択肢を提示できることに価値があります。人間だけで動くよりも早く初動を打てることこそが、AI エージェントを危機対応に活用する最大のメリットです。 — これらのご意見を通じて改めて感じたのは、サプライチェーンの領域は個社ごとに商流・物流の構造や制約が異なり、画一的なソリューションでは対応しきれない複雑さがあるということです。自社の業務に合ったエージェントの在り方を見極めるには、実際に手を動かして仕組みを理解することが近道です。次のセクションでは、本デモと同じシナリオを題材にしたハンズオンワークショップをご紹介します。 おすすめのはじめ方 ハンズオンワークショップ 本デモとよく似たサプライチェーンのシナリオを題材に、Amazon Bedrock AgentCore を段階的に学べるハンズオンワークショップ「 Amazon Bedrock を使用した AI 駆動型サプライチェーン管理の構築 」を公開しています。Jupyter ノートブック形式で、約65分で実施できます。 ワークショップでは、Strands Agents SDK を使ったカスタムツールの作成から始まり、それらのツールを AgentCore Gateway にデプロイして複数エージェント間で共有する方法、MCP サーバーを介したデータベース接続、AgentCore Runtime への本番エージェントのデプロイ、そして React フロントエンドとの統合までを一通り体験できます。プロトタイプとして手元で動かしたエージェントを、システムの残りの部分を変更せずに本番グレードの基盤へ移行する流れを掴むことができます。 マネージドサービス Amazon Connect Decisions 「自社でエージェントを一から構築するのではなく、すぐに使えるサプライチェーン計画ソリューションが欲しい」というお客様には、 Amazon Connect Decisions をご紹介します。Amazon Connect Decisions は、次世代のサプライチェーン計画・インテリジェンスソリューションです。需要予測、供給計画、異常検知といった領域で AI チームメイト（AI エージェント）がチームの一員として稼働し、需要シグナルの統合からコンセンサス予測の生成、業務制約を考慮した供給計画の立案、オペレーションの継続的な監視と問題解決までを支援します。自社の業務手順やルールに適応し、担当者の判断から学習して継続的に改善していくため、導入初日から実用的な推奨を得られる点が特長です。 おわりに AWS Summit Japan 2026 の会場でお話しさせていただいた皆さま、ありがとうございました。2日間を通じて強く感じたのは、サプライチェーンの危機対応は「やりたいけれど手が付けられていない」普遍的なテーマであり、AI エージェントがその最初の一歩を後押しできるということです。ご来場いただけなかった皆さまも、本ブログでご紹介したワークショップや資料をぜひお試しください。ご質問やワークショップ、本デモに関するご相談がありましたら、ぜひ AWS の担当者までお気軽にご相談ください。皆さまの現場で AI エージェントが動き始めることを楽しみにしています。 参考リンク AWS Summit Japan 2026 事前告知ブログ — 流通小売・消費財・飲食業界向けブースのご案内 ハンズオンワークショップ — Amazon Bedrock を使用した AI 駆動型サプライチェーン管理の構築 Amazon Bedrock AgentCore Amazon Connect Decisions 著者 吉田 英史 は、東海地方を中心に小売・消費財業界のお客様を支援しているアマゾンウェブサービスのソリューションアーキテクトです。身の回りの生活に欠かせない様々なビジネスをクラウドで加速するお手伝いができることを、何より嬉しく感じています。

G-gen の佐々木です。当記事では、Google Cloud の AI エージェント開発プラットフォームである Gemini Enterprise Agent Platform の概要を解説します。 Gemini Enterprise Agent Platform とは Studio 概要 Agent Studio Agents - Build 概要 Agent Garden（プレビュー） Agent Development Kit Managed Agents API（プレビュー） MCP サーバー スキルレジストリ（プレビュー） RAG Engine（プレビュー） Vector Search Agent Search Agents - Scale 概要 Agent Runtime セッション メモリバンク サンドボックス フィードバックサービス（プレビュー） 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年8月現在の Google Cloud コンソールで選択できる項目に対応しています。また2026年8月現在、 asia-northeast1 （東京リージョン）においてプレビュー提供となっているコンポーネントについては、見出しに（プレビュー）と付記しています。 カテゴリ コンポーネント 概要 Studio Agent Studio エージェント開発の作業を一元化したコラボレーションワークスペース Agents - Build Agent Garden 事前構築済みエージェントサンプルを提供する厳選ライブラリ Agents - Build Agent Development Kit エージェントの構築・デバッグ・デプロイ用のオープンソースフレームワーク Agents - Build Managed Agents API 単一の API 呼び出しでマネージドな自律エージェントを構築・実行できるサービス Agents - Build MCP サーバー Google Cloud サービスをリモート MCP 経由で AI アプリに接続する仕組み Agents - Build スキルレジストリ エージェントの機能を拡張するスキルを一元管理する低レイテンシなプライベートリポジトリ 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 サンドボックス コード実行・ブラウザ操作などをエージェント本体と隔離された環境で安全に実行する機能群 Agents - Scale フィードバックサービス エージェントとのやり取りに対するユーザーフィードバックを収集・分析する機能 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 、単一の API 呼び出しでマネージドなエージェントを構築・実行できる Managed Agents API 、Google Cloud サービスへの接続口となる MCP サーバー 、エージェントの機能を拡張するスキルを一元管理する スキルレジストリ 、エージェントの知識基盤となる RAG Engine / Vector Search / Agent Search が含まれ、エージェントのロジックとデータソースの両方をカバーします。 Agent Garden（プレビュー） Agent Garden は事前構築済みのエージェントのサンプルを提供するライブラリです。2026年8月現在はプレビュー提供となっています。 サンプルエージェントは 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 Managed Agents API（プレビュー） Managed Agents API on Agent Platform は、単一の API 呼び出しでマネージドかつ自律的なエージェントを構築・実行できるサービスです。2026年8月現在はプレビュー提供となっています。 エージェントは Google の Antigravity ハーネスで駆動され、隔離された Linux サンドボックスの内部でコード実行、ファイル操作、Web 検索、MCP サーバー経由の外部システム連携などを自律的に行います。Antigravity ハーネスは Google 自社のエージェント製品も動作する実行基盤で、Gemini 3.5 Flash と相互に最適化されています。 ADK のようなフレームワークでロジックを記述する必要がなく、Agent Runtime へのデプロイ作業も不要なため、コード実行を伴う自律エージェントを API 呼び出しだけで素早く立ち上げたいケースに向いています。 サービスの詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp 参考 : Agent Platform の Managed Agents API の概要 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 スキルレジストリ（プレビュー） スキルレジストリ （Skill Registry）は、エージェントの機能を拡張する スキル （Skill）を一元管理するための、安全かつ低レイテンシなプライベートリポジトリです。2026年8月現在はプレビュー提供となっています。 スキルは、構造化された手順、実行可能なコード、ドキュメントをひとまとめにした自己完結型のパッケージです。スキルレジストリに登録されたスキルは、ユーザーの意図に応じて関連性の高いものをエージェントが動的に検出・読み込みでき、複数のエージェント間で同じスキルを共有・再利用することもできます。 スキルレジストリでは、表示名・タイムスタンプ・ラベルなどのメタデータとコンテンツを持つトップレベルのリソースである スキル と、そのスキルの特定バージョンを表す不変のスナップショットである スキルリビジョン （Skill Revision）の2階層でリソースが管理されます。スキル自体は可変ですが、リビジョン単位ではコンテンツが固定されるため、過去バージョンの再現性を保ちながらリビジョンを切り替えて段階的に更新していくバージョン管理が可能です。 スキルの本体は zip アーカイブで登録し、ルートに YAML フロントマターと Markdown 本文からなる SKILL.md を配置することでスキルを定義します。スキルの作成・更新時にはペイロードが非同期で自動検証され、アーカイブサイズ（10MB 以下）、解凍後の総ファイルサイズ（500MB 以下）、ファイル数（10,000 個以下）、 SKILL.md の文字数（500,000 文字以下）といった制約に違反していないかが確認されます。 参考 : スキル レジストリの概要 RAG Engine（プレビュー） RAG Engine は、検索拡張生成（Retrieval-Augmented Generation、以下 RAG）を容易にするためのコンポーネントです。2026年8月現在はプレビュー提供となっています。 ローカルファイル、Cloud Storage、Google Drive など複数のデータソースから取り込んだデータを、変換・インデックス化のパイプラインを通じて コーパス （検索用に最適化されたデータのインデックス）として整備します。エージェントの応答生成時にコーパスを検索して LLM のコンテキストに独自のデータを加えることで、ハルシネーションを抑制します。 コーパスは検索対象のデータの論理的な単位であり、データの実体が保存されるベクトルデータベースが別途必要となります。ベクトルデータベースのインフラは2つのモードから選択することができ、インフラ管理を完全に抽象化した サーバーレスモード と、専用の Cloud Spanner インスタンスを使用し、高いカスタマイズ性を実現できる Spanner モード が存在します。 RAG Engine は、2026年8月現在 europe-west3 、 europe-west4 などのリージョンでは GA となっていますが、 asia-northeast1 を含む多数のリージョンではプレビュー提供となっています。なお us-central1 、 us-east4 も GA ですが、いずれも許可リスト（allowlist）への登録が必要で、新規プロジェクトでは他のリージョンの利用が案内されています。最新のリリース状況については以下のドキュメントを参照してください。 参考 : 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 、ユーザーとエージェント間のやり取りを保持する セッション 、会話に基づいて長期記憶を生成・管理する メモリバンク 、コード実行やブラウザ操作などリスクを伴う処理を隔離環境で実行する サンドボックス 、エージェントに対するユーザーフィードバックを収集・分析する フィードバックサービス が組み合わさり、ステートを伴うエージェントの安定運用を支えます。 Agent Runtime Agent Runtime （旧称 : Agent Engine）は、開発した AI エージェントをリモートからアクセス可能な HTTP サーバーとしてホストするフルマネージドの実行基盤です。 ADK をはじめ、LangChain や LangGraph といった様々なエージェントフレームワークのデプロイを容易にするテンプレートが提供されており、テンプレートに適合しない場合でもカスタムエージェントとして構築できます。ただし、2026年7月現在、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 サンドボックス サンドボックス （Sandbox）は、エージェントの代わりに特定のタスクを実行するために起動される隔離コンピューティング環境を提供する機能群の総称です。 エージェントが生成したコードやブラウザ操作といったリスクを伴う処理を、エージェント本体とは別の短命な環境に隔離して実行することで、ホストシステムや他のエージェントへの影響を防ぎます。隔離・セキュリティ・安全性の3つを基本原則とし、コンテナベースのサンドボックス境界によって、有害なコマンドやリソースを大量に消費するループの影響範囲をサンドボックス内に閉じ込めます。 サンドボックスでは、以下の機能が提供されます。 機能 説明 Code Execution エージェントが生成したコードを隔離サンドボックス上で実行する機能。LLM が苦手な厳密な数値計算・データ処理・可視化などをコード実行で補強し、財務計算・データサイエンスワークフロー・信頼できないコードの隔離実行といったユースケースで利用される。サンドボックスは1秒未満で起動でき、ファイルシステムへのアクセスは制限され、外部ネットワークへのアクセスも遮断されている Computer Use （プレビュー） コンテナ化されたブラウザ環境を提供し、エージェントが URL ナビゲーション・要素クリック・テキスト入力・スクリーンショット取得などの操作を実行できる機能。Chrome DevTools Protocol（CDP）経由で Playwright などのブラウザ自動化フレームワークから操作することも可能 カスタムコンテナ （プレビュー） サンドボックスの実行環境としてユーザー独自の Docker イメージを持ち込める Bring Your Own Container（BYOC）機能。標準のサンドボックスでは利用できない依存ライブラリ・ランタイムバージョン・プロプライエタリツールを伴うワークロードに対応する。コンテナイメージは Artifact Registry に格納する スナップショット （プレビュー） サンドボックスの状態（インストール済みライブラリ・ファイルシステムの変更・メモリ状態など）を保存して後から復元できる機能。チェックポイントによる復旧や、同一スナップショットからの分岐実行で複数のアプローチを並行検証する用途で利用できる なお、上記のうち Computer Use、カスタムコンテナ、スナップショットの3機能は2026年8月現在プレビュー提供となっています。また、Code Execution は2026年8月現在、 us-central1 リージョンでのみ利用できます。 参考 : Sandboxes overview 参考 : Code Execution 参考 : Computer Use 参考 : Custom container sandbox overview 参考 : Manage snapshots フィードバックサービス（プレビュー） フィードバックサービス （Feedback Service）は、Agent Runtime でホストされているエージェントとユーザーのやり取りに対するフィードバックを収集・分析するための機能です。2026年8月現在はプレビュー提供となっています。 ユーザーの反応を高評価・低評価（ thumbs_up / thumbs_down ）の2値で記録できるほか、評価の理由を示すラベルと自由記述のテキストを付加できます。ラベルには accurate （正確）や helpful （有用）などのポジティブラベルと、 inaccurate （不正確）や hallucination （ハルシネーション）などのネガティブラベルが、それぞれ8種類ずつ事前定義されています。 フィードバックはセッション ID とイベント ID を指定して登録するため、前述のセッションが保持する会話のタイムラインのうち、特定の会話ターンやイベントに紐づけて管理できます。また、オプションの FeedbackContext リソースとして会話ログを添付しておくことで、元のセッションが削除された後も、分析に必要な会話のコンテキストをフィードバック側に保持できます。 フィードバックの作成・取得・更新・削除・一覧表示は REST API または Python SDK から実行でき、フィードバックの保存基盤がマネージドで提供されるため、フィードバック用のデータベースを独自に構築・運用する必要がありません。 また、Agent Runtime で Cloud Trace によるトレースを有効化している場合は、コンソール上でトレースイベントと並べてフィードバックを確認できます。 参考 : フィードバック サービスの概要 Agents - Govern 概要 このカテゴリでは、エージェントの動作と通信を統制するためのガバナンスコンポーネント群を扱います。MCP サーバー / ツール / エージェントを一元管理する Agent Registry 、認証・認可と自然言語ベースの統制を担う ポリシー 、ネットワーク境界を保護する Agent Gateway 、Security Command Center 連携でリスクを可視化する セキュリティ機能 、プロンプトとレスポンスを検査する Model Armor で構成されます。 Agent Registry Agent Registry は、Google Cloud 内のエージェント、MCP サーバー、エンドポイントを保存・検出・管理できる、一元化された統合カタログです。 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 の概要 参考 : バインディングを管理する Agent Registry については、以下の記事で詳細に解説されています。 blog.g-gen.co.jp ポリシー ポリシー （Policies）は、後述の Agent Gateway がエージェントと他のサービス間の通信を安全に管理するために用いる、 IAM 許可ポリシー と セマンティック ガバナンス ポリシー の総称です。 IAM 許可ポリシーは IAM ベースの静的な権限管理で、Identity-Aware Proxy（以下、IAP）を用いた認証と認可を実現します。Agent Registry の各サービスに「読み取り専用」、「破壊的変更の許可」といった条件を指定したポリシーを紐づけることで、エージェントがサービスを介して行える操作を制限します。 セマンティック ガバナンス ポリシーは、エージェントのプロンプトや MCP ツール呼び出しの「内容」を監視・制御するための制約であり、エージェントの振る舞いがユーザーの意図と組織の制約の両方に適合するように制御します。Agent Gateway は実行時に各エージェントのプロンプトとツール呼び出しの内容を分析し、制約に基づいてアクションを決定します。なお、2種類のポリシーのうちセマンティック ガバナンス ポリシーについては、2026年8月現在プレビュー提供となっています。 参考 : ポリシーの概要 参考 : セマンティック ガバナンス ポリシーの概要 参考 : セマンティック ガバナンス ポリシーを構成する 参考 : セマンティック ガバナンス ポリシーを構成する - セマンティック ガバナンスの例 Agent Gateway Agent Gateway はユーザーとエージェント、エージェントとツール、エージェント同士など、すべてのエージェントインタラクションを保護・管理するネットワークコンポーネントです。 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 を利用するには、対象のエージェントと、その接続先となるエンドポイントや MCP サーバーを、あらかじめ Agent Registry に登録しておく必要があります。そのうえで、Agent Runtime へのエージェントのデプロイ時、または Gemini Enterprise アプリの管理設定で使用するゲートウェイを指定すると、以降のトラフィックは自動的に Agent Gateway 経由でルーティングされます。一方、それ以外のデプロイ先（Cloud Run や GKE など）からのトラフィックを Agent Gateway 経由とする手順は2026年7月現在の公式ドキュメントには明示されていません。そのため現時点では、Agent Runtime と Gemini Enterprise が主な利用対象となります。 参考 : Agent Gateway の概要 参考 : ゲートウェイで Model Armor を構成する Agent Gateway については、以下の記事で詳細に解説されています。 blog.g-gen.co.jp セキュリティ 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 サーバーのパフォーマンス、動作、健全性を包括的に監視・分析できます。 主要な指標のモニタリング、実行パスのトレース、マルチエージェントシステムのトポロジの可視化によって、問題を診断し、リソース消費を最適化し、エージェントの信頼性を向上させることができます。 これらの分析を行うためには、エージェントから OpenTelemetry 形式でテレメトリーデータを Google Cloud Observability（Cloud Monitoring / Cloud Logging / Cloud Trace）に送信するように構成する必要があります。送信されたテレメトリーデータは、Agent Registry のコンソール上で以下の3種類のシグナルとして確認することができます。 シグナル 主な内容 メトリクス トークン使用量、レイテンシ（p50 / p95 / p99）、エラー率、セッション統計、ハルシネーション率、CPU・メモリ使用量 トレース 実行パス（スパン）、入出力の有向非巡回グラフ、エージェント間呼び出し ログ プロンプト・レスポンス、エラー、フィルタ可能なエージェント生ログ 参考 : オブザーバビリティの概要 エージェントの評価 エージェントの評価 （Agent Evaluation）は、エージェントのパフォーマンス、安全性、品質を測定して改善するための評価機能です。 エージェントの評価では以下のような機能が利用できます。既存のテストデータがなくても初期評価スイートを構築できる点が特徴です。 機能 説明 シナリオ生成 / ユーザーシミュレーション エージェントのシステム指示とツール定義に基づいて多様なマルチターンの合成テストシナリオを自動生成する 環境シミュレーション ツール呼び出しをインターセプトしてカスタム動作やシミュレートされたエラーを挿入する マルチターン評価 会話履歴全体を自動的に評価する プロンプト最適化 洗練されたシステム指示をプログラムで生成・検証する 評価プロセスは「評価ケース定義 → 評価ケース実行 → トレース生成 → 指標の計算 → 指標の分析 → エージェント最適化」の6つのステップで構成され、ローカル開発でのイテレーションと、デプロイ済みエージェントに対する評価の両シナリオで利用できます。 また、評価指標に対してしきい値を設定し、超過時に自動通知を送る 品質アラート （Quality Alerts）も提供されています。タスクの成功スコアやツール使用品質といった指標を Cloud Monitoring 経由で監視し、しきい値超過時に Slack、メール、Cloud Pub/Sub への通知を発信することで、基盤モデルが変わっていなくても、ユーザーの行動やデータパターンの変化に起因するエージェントの品質低下を早期に検知できます。 参考 : エージェントの評価 参考 : 品質アラートを構成する Example Store（プレビュー） Example Store は、エージェントが LLM に渡すプロンプトに含めるための Few-shot サンプル（少数ショットの例）を保存・動的に取得できるマネージドサービスです。2026年8月現在はプレビュー提供となっています。 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年7月現在、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年7月現在、対象モデルは 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 の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp 参考 : 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 ドメイン単位でのノートブック共有と、複数ユーザーでのリアルタイム共同編集に強みがあります。 Gemini によるコード補完・コード生成に加えて、コードセルの説明、エラーの説明と修正、ノートブック内容についてのチャットといった AI アシスタンス機能が利用でき、SQL セルや可視化セルなどの機能と組み合わせて、協業とデータ分析を重視するシナリオに適しています。なお、2026年8月現在、これらのうちコードセルの説明、エラーの説明と修正、ノートブック内容についてのチャットの3機能はプレビュー提供となっています。 参考 : Colab Enterprise の概要 参考 : Gemini in Colab Enterprise Agent Platform Workbench Agent Platform Workbench は、VM インスタンス上で動作する JupyterLab 環境で、TensorFlow や PyTorch といったディープラーニング用フレームワークのプリインストールと GPU 構成への対応により、機械学習向けのノートブック環境をすぐに整えられます。 conda 環境によるカーネル拡張、ユースケースに合わせた独自のコンテナでのインスタンス作成など、開発環境を細かく作り込みたいケースに向いており、高いカスタマイズ性を備えています。また、Workforce Identity 連携によるサードパーティ ID プロバイダ認証にも対応しています。 参考 : Agent Platform Workbench の概要 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング1課 北海道在住 大学院まで社会心理学を専攻し、AI に興味を持ち IT 業界へ。2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。最近は法律の勉強にも目覚め、2級知的財産管理技能士を取得。 Follow @sasashun0805

通信業界のネットワーク運用ではより安定した通信ネットワークを提供するために、障害の検知、要因特定、復旧を早期に対応する必要があります。一方で、近年拡張し複雑化し続けるネットワークに追従することは従来のオペレーションでは難しく、自動化、高度化、自律化が求められています。その実現手段の1つとして、AI エージェントとデータ活用が注目されており、導入への期待が高まる一方で、AI を適用する運用ユースケースの策定、より簡単な AI エージェントの実装方法、商用運用への本格導入、といった課題があります。そこで、本ワークショップでは、通信ネットワークの運用に携わる方向けに、 AI エージェントの仕組みを学び、参考アーキテクチャや事例から最新動向を知り、ハンズオンでより具体的な実装方法を学び、ネットワーク運用 AI エージェントを触って体感していただく場を提供しました。事例紹介の 1 つとして、株式会社 NTTドコモにご登壇いただきました。また、複数社による同じネットワーク運用に携わる者同士の意見交換や AI エージェント活用のためのユースケース議論を行っていただくことで、他社動向や自社の課題を浮き彫りにし、今後のアクションの参考にしていただく場も提供しました。通信ネットワーク運用に特化した業界横断イベントは、今回初めてであり今後も定期的に開催していきたいと思います。 早朝から 96 名/ 14 社のお客様に目黒オフィスまで足を運んでいただき、懇親会まで含めて大盛況なイベントとなりました。ご参加いただきました皆様、本当にありがとうございました！！ アジェンダ タイトル スピーカー 資料 AI エージェント とは – Autonomous Network の実現のために 宮崎 友貴*1 ダウンロード Strands Agents ハンズオン – AI エージェント開発を簡素化しよう 神谷 拳四郎*1 ダウンロード ランチタイム ユースケース議論 宮崎 友貴 通信ネットワーク運用 AI エージェント実践編 – 実際に作って、動かして、触ってみよう 堀場 勝広*2 ダウンロード Amazon Bedrock AgentCore 概要 – AI Agent を本番環境にデプロイおよび運用する方法を学ぼう 川岸 基成*1 ダウンロード クロージング 宮崎 友貴 ダウンロード 懇親会 – – ※1. Solutions Architect, ※2. Principal Solutions Architect AI エージェント とは – Autonomous Network 実現のために 通信業界のオペレーション標準化団体である TM Forum では、 Autonomous Network (自律ネットワーク）の自律レベルを定義しており、 近年、多くの通信事業者が L4 (高度自律ネットワーク) / L5 (完全自律ネットワーク) を目指す動きが出てきています。それを実現するためのコンポーネントの例と AWS で実現する参考アーキテクチャをご紹介しました。このアーキテクチャのキーは、AI エージェント × データであり、Autonomous Network の実現には必須要素であることをお伝えしました。そして、AI エージェントが自律的な行動を行うことができるようになった基礎技術や変遷と共に、オペレーション業務に携わるオペレータと近い動きができることを説明しました。最後に、AI エージェントの活用事例とネットワーク運用における AI エージェントの 参考ユースケース をご紹介することで、最新の業界動向と AI エージェントによる自律運用が実現可能な世界であることをインフルエンスさせていただきました。 宮崎 友貴 Solutions Architect NTTドコモ 「さらば、単純作業！AWSで実現する、”人間が人間らしく働く”ためのネットワーク運用自動化」の事例紹介 AI エージェントを使ったネットワーク運用自動化の事例として、NTTドコモ の舟山空良氏と福嶋章悟氏にご登壇いただきました。両氏は、モバイル端末と MEC 基盤を直結して通信経路を最適化することで、低遅延・高セキュリティ通信を実現するサービス docomo MEC® のオプションであるサービス「MECダイレクト®」 の開発・構築・運用を担当しており、定義済みのフローによる運用の自動化がある程度完了したことで、さなる自動化を目指し、AI の活用に挑戦しました。 株式会社 NTTドコモ 舟山 空良氏（写真左） 福嶋 章悟氏（写真右） 登壇時点では、AI エージェントによる監視措置業務の自律的な実行を実現し、アラート受信、分析、措置手順の提案までの自動化を達成され、そのソリューションとして Amazon Bedrock エージェント を使用していることをご説明いただきました (以下、システム構成図)。Bedrock エージェントの選定の理由としては、マネージドかつサーバーレスなためインフラの構築に時間をかけず迅速な開発を行うことができた点や、社内のセキュリティ承認を得るためのデータプライバシーの観点で Bedrock ではデータをモデルの学習にはしない点が評価されました。 実際の AI エージェントの開発では、参照するデータを泥臭く時間をかけて整備し、プロンプトを工夫することが精度向上には必要であることや、AI に完璧さを求めないこと、がリアルな実装のポイントとして挙げられました。将来的には、LLM 適用による維持管理業務への AI エージェントの適用を行い、AI エージェントの適用領域のさらなる拡張を進め、自律レベルの向上を目指しています。 Strands Agents ハンズオン – AI エージェント開発を簡素化しよう Autonomous Network 実現の核となる AI エージェント、それをわずか数行のコードで構築可能なオープンソース SDK である Strands Agents をご紹介しました。Strands Agents はシンプルな実装だけでなく、本番稼働に対応するためのオブザーバビリティ、モデルプロバイダーやデプロイ環境に依存しない設計思想、データを保護しながら責任を持ってエージェントを実行することを最優先とするなどの特徴があります。本パートでは実際に SDK を使って AI エージェントを構築し、Strands Agents における主要な概念と機能を探索するハンズオンを行いました。 神谷 拳四郎 Solutions Architect Autonomous Network の自律レベル向上を目指していくにあたっては、単一の AI エージェントによるタスク処理だけではなく、マルチエージェントによる協調の必要性が高まってくるでしょう。異なるスキルやモダリティをもつ、複数の専門化された AI エージェントを効果的に組み合わせるデザインパターンとして Agents as Tools、Swarm、Graph、Workflow の4つをご紹介しました。 運用業務における AI エージェントのユースケース議論 本イベントは、複数社の運用担当者にご参加いただいたので、各社混合のグループディスカッションを AWS 社員も交えて実施いただきました。議論テーマは、以下です。各社、自担当の業務をご紹介いただき、どのような業務を AI エージェントに任せられるのか、を議論いただきました。AI エージェントに任せられる業務としては、調査、分析、切り分け、オペレータの支援、ドキュメント作成、オペレーションの記録、ネットワークのエッジ側での操作、などが挙げられ、任せられない業務としては、サービス影響の出る可能性のあるオペレーションの実行、顧客対応や社内調整など対人コミュニケーション関連の業務が挙げられました。各社の AI 活用状況や運用の現場における課題の共有、活発な意見交換が行われました。 通信ネットワーク運用 AI エージェント実践編 – 実際に作って、動かして、触ってみよう 本セッションでは、「実際に触って、動かして、理解して、そして、考えてみよう」というコンセプトに、通信ネットワーク運用における AI エージェント活用の実践的なハンズオンを実施しました。参加者の皆様には、通信ネットワークの保守運用者の立場で、数千台以上の装置で構成されるトランスポート～基地局 NW 網を管理し、毎日数万件以上のアラームが発生する環境で AI エージェントを活用したネットワーク運用を体験いただきました。 堀場 勝広 Solutions Architect ハンズオンの技術アーキテクチャ 本ハンズオンでは、AWS の複数のサービスを統合した実践的な環境を構築しました。データストア層として、 Amazon Neptune をグラフ DB とベクトル DB の両方で活用し、ネットワークトポロジデータとエージェント用の知識ベースを格納しました。また、 Amazon Aurora (RDB) にはネットワークトポロジとアラーム情報を、 Amazon S3 ストレージには保守運用マニュアルや対応手順書を格納しました。 AI処理層では、Amazon Bedrock が提供する大規模言語モデル（LLM）を基盤として、複数の専用 AI エージェントを配置しました。Orchestration エージェント（全体調整）、Observability （分析）エージェント、ナレッジエージェント、チケット管理エージェント、そしてRCA （根本原因分析）エージェントが連携し、包括的なネットワーク運用支援を実現しています。さらに、外部システムとして ServiceNow ITSM と連携し、インシデントチケットの管理も可能にしました。 実践的な対話シナリオ 参加者の皆様には、AI エージェントとの対話を通じて、以下のような実践的なシナリオを体験いただきました。 ナレッジベースへのアクセス：「網内の装置にて IF 品質異常発⽣(流⼊ error )が発⽣した場合どう対処すべきか？」といった質問を通じて、保守運用マニュアルから必要な情報を即座に取得する体験をしていただきました。 アラームの分析：「 2024-0713-0900 前後 30 分間に埼玉エリアで発生したアラームから、発生していたネットワーク障害の内容をまとめて下さい」といった時系列での障害分析や、計画作業との関係性分析を実施しました。 トポロジの分析：アラーム情報とネットワークトポロジ情報を組み合わせることで、障害の根本的な原因を特定する高度な分析を体験いただきました。さらに、マニュアルに沿った対応として、「根本的な原因を解決するために必要な処理は何ですか？保守運用マニュアルに従って回答して下さい」という質問を通じて、AI エージェントが適切な対応手順を提示する様子を確認しました。 最後にチケットの起票：「障害の概要、根本原因の分析結果、対応手順を取りまとめて ServiceNow にチケット起票」と言う依頼を通じて、AI エージェントが一連の対応を外部システム( ServiceNow )に書き込み可能なことをご確認いただきました。 システムの内部構造を探る – 応用編 ハンズオンの後半では、Jupyter Notebook を使用して AI エージェントの動作をカスタマイズし、パラメータ調整による応答内容の最適化を体験いただきました。例えば、マルチエージェント構成のオーケストレーターエージェントのシステムプロンプトを変更することにより、他のエージェントの呼び出し方の変化を体験いただきました。これにより、AI エージェントが単なるブラックボックスではなく、調整可能なシステムであることを実感していただけたと考えています。 ハンズオンを経験した上でのユースケース議論 ワークショップの後半 60 分間では、グループに分かれて AI エージェントの活用方法を議論しました。参加者の皆様には、以下の5つの質問を軸に、自担当でのオペレーション業務の洗い出しから、AI エージェントに任せられる業務と任せられない業務の仕分け、その判断基準の検討、必要なデータと指示（プロンプト）の検討、そして実際の AI エージェントアーキテクチャの設計まで、包括的なディスカッションを行っていただきました。このグループワークを通じて、AI が単なるツールではなく、ネットワーク運用を変革する可能性を持つことを体感いただけたと考えています。特に、どの業務を AI に委譲できるか、どこで人間の判断が必要かという議論は、実際の業務への適用を考える上で非常に重要な示唆を与えるものとなりました。 Amazon Bedrock AgentCore 概要 – AI Agent を本番環境にデプロイおよび運用する方法を学ぼう 続いては、AI エージェントを大規模かつ安全に構築、デプロイ、運用するためのビルディングブロック Amazon Bedrock AgentCore についてのセッションです。これまでのセッションで Strands Agents を利用したエージェントを作りました。このエージェントを本番環境で運用するには、リクエスト増減に合わせてさばけるスケーラブルなコンピューティング環境、認証認可の仕組み、会話履歴などを管理する記憶領域、ツールへの接続と管理、などを考慮する必要があります。これらの課題解決に役立つのが Amazon Bedrock AgentCore であることをお伝えしました。 川岸 基成 Solutions Architect 通信ネットワーク運用というワークロードに当てはめた際の使い方や価値についてもお伝えしました。例えば、機密性の高いNW運用ワークロードでは、Runtime のセッション分離のセキュアな環境が役立つでしょう。AI Agent とのやり取りの中で発見されたインシデントパターン、解決戦略などのナレッジを Memory に蓄積・活用していくことで、より精度を高められる可能性があります。 クロージング 最後に、ワークショップ全体の振り返りながら、AI エージェントを導入するには、AI エージェントに加えてユースケースに応じたオペレーションデータを活用することが必須であることを改めて伝えさせていただきました。また、その実現に向けて AWS がどのように貢献をすることができるか、について、サービスとしてのメリットだけではなく、豊富な事例やネットワーク運用を理解した支援が可能である点をお伝えしました。本ワークショップはその支援の一つであり、ネットワーク運用に携わる方にとってより実用的な内容だったかと思います。 おわりに 本記事では、「通信ネットワーク運用向け AI エージェントワークショップ」についてレポートしました。参加頂いたお客様からは「AI エージェントの現場への導入へのイメージの確度が高めることができた」「やれる気がしてきた」「他社他部署の運用保守に携わる方と交流できた貴重な時間」「Amazon Bedrock AgentCore がサーバレスなので運用がとても楽になる」などのご評価を頂きました。ご参加頂いた皆様、本当にありがとうございました。頂いたフィードバックをもとに改善を重ねて参ります。また、ネットワークの運用 AI エージェントの導入に向けて、本内容が少しでも皆様の業務のお役に立てば幸いです。 著者 宮崎 友貴 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 神谷 拳四郎 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 川岸 基成 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 堀場 勝広 アマゾン ウェブ サービス ジャパン合同会社 Telecom Industry Business Unit プリンシパルソリューションアーキテクト