Amazon Web Services ブログ
【開催報告】通信事業者向けカスタム AI エージェントワークショップ開催しました! ( 2026 年 4 月 23 日 ) – ネットワーク開発・運用を AI エージェントで変える
はじめに
通信業界の主要 MNO 4 社(NTTドコモ、KDDI、ソフトバンク、楽天モバイル)に NTT、ソニーを加えた通信関連事業者の皆様、121 名 / 6 グループの方々が一堂に会したワークショップを、2026 年 4 月 23 日に AWS Startup Loft Tokyo で開催しました。テーマは、ネットワーク開発・運用を変える「カスタム AI エージェント」。本記事では、Autonomous Network 実現に向けた参考アーキテクチャ、NTTドコモ/NTTドコモビジネス両社の事例、Strands Agents・Amazon Bedrock AgentCore のハンズオン、そしてユースケース議論まで、当日の内容をレポートします。「自社のどの業務に、どう適用できるか」を考えるヒントとして、お役立ていただけますと幸いです。
AWS ジャパンでは、こうしたテーマに向き合う場として 2025 年 11 月に「通信ネットワーク運用向け AI エージェントワークショップ」を開催し、参加された通信事業者の皆様から大きな反響をいただきました。今回はその第 2 回として、対象を ネットワーク開発・運用全般 に広げ、開発工程での AI エージェント活用も新たに取り上げました。
通信業界のネットワーク開発・運用では、より高品質で柔軟なサービスを継続的に提供するために、設計・構築・障害対応・改善といった多岐にわたる業務を効率化することが求められています。一方で、ネットワークの拡張や複雑化に従来のオペレーションだけで追従することは難しくなりつつあり、自動化・高度化・自律化の取り組みが加速しています。その実現手段の 1 つとして AI エージェントとデータ活用が注目されており、導入への期待が高まる一方で、AI を適用する業務ユースケースの策定、より簡単な AI エージェントの実装方法、商用運用への本格導入、といった共通の課題があります。本ワークショップは、こうした課題に対して「学ぶ・知る・触る・議論する」を 1 日に凝縮した場を提供するものです。
アジェンダ
| 時間 | セッション | 登壇者 |
|---|---|---|
| 13:00–13:10 | オープニング | Yuki Miyazaki (AWS / SA) |
| 13:10–14:15 | セッション1:複雑な開発/運用業務でAIエージェントを活用しよう | Yuki Miyazaki (AWS / SA) |
| 13:10–14:15 | 事例登壇:AIとGitOpsを用いた5Gコアネットワークの設計構築自動化への取り組み | NTTドコモ 宮本氏 |
| 13:10–14:15 | 事例登壇:ルータ統合型AIエージェントによるネットワーク開発の取り組み | NTTドコモビジネス 門脇氏 |
| 14:30–16:00 | セッション2:AWSで実現するカスタムAIエージェント(Strands Agents / Amazon Bedrock AgentCore ハンズオン) | Atsushi Okamoto (AWS / SA), Yuta Tanaka (AWS / SA) |
| 16:15–17:50 | セッション3:ネットワーク開発運用エージェントを触ってみよう(ハンズオン+ユースケース議論) | Naohito Yoshikawa (AWS / SA) |
| 17:50–18:00 | クロージング | Yuki Miyazaki (AWS / SA) |
| 18:00–19:30 | ネットワーキングパーティ | — |
セッション1:複雑な開発/運用業務でAIエージェントを活用しよう

宮崎 友貴
Solutions Architect
本セッションでは、通信業界のオペレーションの標準化団体である TM Forum が定義する Autonomous Network(自律ネットワーク)の自律レベル L4/L5 の実現に向けて、AI エージェントとデータの活用が不可欠であることを解説しました。まず、AI エージェントが自律的な行動を行えるようになった基礎技術の変遷と、ネットワークの開発者や運用者に近い動きが実現可能であることを説明し、AWS で実現する参考アーキテクチャをご紹介しました。このアーキテクチャのキーは AI エージェント × 自律的な判断に必要なデータであり、ネットワークのトポロジーや時系列データ、構成情報、設計書、手順書といったネットワークデータと AI エージェントを組み合わせることで、ネットワークの設計や構築、運用開始後の障害検知から根本原因分析といった複雑なオペレーションを自律的に行える仕組みが構築できることをお伝えしました。最後に、グローバルおよび国内の通信事業者における AI エージェントの活用事例をご紹介し、Autonomous Network が既に商用で実現しつつあることを参加者の皆様にお伝えしました。
事例登壇:NTTドコモ 「AIとGitOpsを用いた5Gコアネットワークの設計・構築自動化への取り組み」

宮本 克真 氏
株式会社 NTTドコモ コアネットワークデザイン部
AI エージェントを使ったネットワーク設計構築自動化の事例として、株式会社 NTTドコモ コアネットワークデザイン部の宮本克真氏にご登壇いただきました。NTTドコモでは、国内で初めて 5G コアネットワーク(5GC)を AWS 上に構築し、2026 年 2 月より商用サービスを開始 しています。従来の 5GC 設計・構築プロセスでは、膨大なマニュアルや仕様書の確認、多種の設定ファイル作成、煩雑な構築手順の実施に約 4〜6ヶ月を要し、需要増への迅速な追従が課題でした。
そこで AI エージェントと GitOps を組み合わせた設計・構築自動化を導入しました。AI エージェントがマニュアルや仕様書をナレッジベースとして参照し、インフラ設定・アプリ設定・5GC コンフィグなどの設定ファイルを自動生成します。生成されたファイルは Git で管理され、CI/CD パイプラインを通じて自動デプロイされます。アーキテクチャとしては Amazon Bedrock AgentCore 上のオーケストレータエージェントが、Git 担当・インフラ担当・アプリ担当・コンフィグ担当の各専門エージェントを統括する構成です。各エージェントは Strands Agents SDK で構築され、Amazon Bedrock Knowledge Base を MCP 経由で参照します。デモでは、オペレータが「5GC NF を構築して」と指示するだけで 5GC が構築される様子をご覧いただきました。
この取り組みにより設計から構築までのリードタイムを約 80% 短縮することに成功し、工数削減と共に人為ミスの低減にも繋がりました。今後は、試験自動化や保守・運用領域などへの拡大を目指しています。
事例登壇:NTTドコモビジネス「ルータ統合型AIエージェントによるネットワーク開発の取り組み」

門脇 伸明 氏
NTTドコモビジネス株式会社
ルータ連携 AI エージェントのネットワーク開発への活用事例として、NTTドコモビジネス株式会社の門脇氏にご登壇いただきました。同社では、映像伝送ネットワークサービスを提供しており、全国の専用線網にて数百台規模のルータを運用しています。従来、突発的なネットワーク設定変更(例:ファイアウォール強化)が必要な際には、エンジニアがマニュアルや仕様書を確認し、ルータの状態を手動で調査した上で設定を作成・検証し、さらにレポート資料を作成するまでに約 6 日を要していました。
そこで、ルータの MCP を活用してルータと直接連携する AI エージェントを導入しました。エンジニアが設定要件を自然言語で指示するだけで、AI エージェントがルータから必要な情報を自律的に収集し、既存の設定や環境に合わせてコンフィグを設計・生成します。さらに、コンフィグ投入後の動作確認やレポートの作成まで自動化することで、所要日数を 6 日から 1 日へと大幅に短縮しました。また、AI エージェントのメリットとして、自律的にルータから自動で必要情報を収集するため、ルータ情報をプロンプトで与えずにルータの専門知識さえあれば活用できる点と、AI エージェントの振る舞いの定義をコードではなく自然言語で記述できるため可読性が高く実装が容易である点が紹介されました。
AWS の構成としては、社内のセキュリティ規約に基づき閉域接続(AWS コンソール以外はインターネット接続なし)で構築することで安全な AI エージェント運用を実現しています。今後は、試験自動化やメーカー問い合わせの自動化など、さらなる AI エージェント活用のユースケース拡大を目指します。
セッション2:AWSで実現するカスタムAIエージェント — Strands Agents と Amazon Bedrock AgentCore
本セッションの前半では、カスタム AI エージェントを「素早く構築する」ことと「安全に大規模運用する」ことの両方を実現する AWS のアプローチとして、Strands Agents と Amazon Bedrock AgentCore を最新アップデートとともにご紹介しました。

岡本 篤志
Solutions Architect
まず AI エージェントの構成要素を、推論を担うモデル・振る舞いを定義するプロンプト・外部システムと連携するツールの 3 つに整理した上で、これを本番稼働させるにはメモリ管理やオブザーバビリティ、セキュリティ、スケーラビリティなど多くの周辺機能の実装が必要になることを示しました。Strands Agents はこの「構築」の負担を大幅に軽減するオープンソース SDK であり、わずか数行のコードでエージェントを実装できます。MCP をはじめとする多様な接続方式による外部システム連携や、エージェント同士を組み合わせるマルチエージェント構成にも対応しています。さらに、複雑なマルチステップタスクにおける再現性や品質の一貫性を確保する仕組みとして Agent SOP(自然言語で記述するワークフロー定義)を紹介し、チーム間での知見共有と品質統一が可能であることをお伝えしました。
続いて、「大規模運用」を担う Amazon Bedrock AgentCore について解説しました。任意のフレームワークやモデルで構築したエージェントを本番環境にデプロイし、会話コンテキストの維持、アクセス制御、実行トレースの可視化、品質の継続的な評価まで、エンタープライズグレードの運用基盤を包括的に提供します。下図のように、通信ネットワーク運用の文脈では、ネットワーク機器や構成管理システムとのツール連携、インシデント対応ナレッジの長期記憶としての蓄積・活用が可能であり、ネットワーク運用の自律化に向けた基盤として特にフィットすることを示しました。
その後、Strands Agents と Amazon Bedrock AgentCore の両方の実装を体験できるワークショップを実施させていただきました。

田中 優多
Solutions Architect
このワークショップでは、Strands Agents 及び Amazon Bedrock AgentCore の機能を最大限に活用した、包括的で本番環境に対応したカスタマーサポートエージェントを構築しました。単なるチャットボットではなく、複雑なカスタマーサービスのワークフローを処理し、複数の企業システムと連携し、同時に数千人の顧客にサービスを提供できるような高度なエージェントシステムです。
まずは、Strands Agents をローカル環境に実装することをご体験いただきました。幾つかの用途特化機能をツールとして定義 → 独自のデータをナレッジベースとして連携 → エージェントの役割を自然言語で定義といった簡易なステップで、AI エージェントを作成できることを確認しました。
ただしこの状態のプロトタイプには、以下のような課題がある状態でした。
- 永続的なメモリがない — エージェントは過去の会話を忘れる
- スケーラビリティがない — ローカル開発環境でのみ実行
こうした課題を解決するソリューションとして、Amazon Bedrock AgentCore の実装へと進みました。数ある AgentCore モジュール群の中でも、AgentCore Memory と AgentCore Runtime に焦点を当てて、コードベースでその設定やデプロイ方法をご体感頂きました。AgentCore Memory を実装することで、ユーザとのやり取りの記憶や好みの自動学習、長期間のコンテキスト維持が可能になります。そして AgentCore Runtime の活用により、常に変化する需要に合わせて自動的にスケールするサーバーレスソリューションが実現できます。数多くのフレームワーク、モデル、プロトコルをサポートし、開発者は最小限のコード変更でローカルプロトタイプを本番対応ソリューションに変換できます。
これらをお客様の手でカスタムで作り上げることにより、業務に即した実用性の高い AI エージェントが実装できることを、ご体感いただきました。
セッション3:ネットワーク開発運用エージェントを触ってみよう

吉川 直仁
Solutions Architect
前段のセッション2で学んだ Strands Agents と Amazon Bedrock AgentCore の知識を、通信ネットワークというドメインに当てはめるとどうなるか、を体感していただくのが本セッションの位置付けです。前回ワークショップでは保守運用業務にフォーカスしましたが、今回はそこに 開発・構築工程 のシナリオを 2 本追加し、参加者の皆様に「物理ネットワークの設計・開発者」「5G コアネットワークの設計・開発者」「ネットワーク保守運用者」の 3 つの立場を順に体験していただきました。
シナリオ ① は、複数台のルータから構成されるネットワークの Config 設定・接続確認・バグ検証の自動化です。実機の設定情報、大量のログ、仕様書を参照しながら対応する必要がある業務を、AI エージェント × ナレッジ(SOP)の組み合わせで実装します。
デモ動画:シナリオ ①(ネットワーク機器の設定・構築・検証)
オペレータが「ネットワークの状態を確認して、疎通不可の原因を調査・修正してほしい」と自然言語で指示するだけで、AI エージェントが SOP に従って ① 構成情報の確認 → ② ヘルスチェック → ③ Config 修正 → ④ レポート作成までを自律的に実行する様子をご覧いただけます。
シナリオ② コアネットワークのパラメータ設計、構築
シナリオ ② は、5G コアネットワークのパラメータ設計とデプロイです。複数の NF(Network Function)から構成されるコアネットワーク網に対するネットワークスライス追加を、Strands Agents が IaC とパラメータを生成し、Git を介してインフラ(Amazon EC2)からその上で動くアプリ、さらにアプリのパラメータ設定までを一気通貫でデプロイする流れを体験していただきました。
デモ動画:シナリオ ②(コアネットワークのパラメータ設計・デプロイ)
オペレータが「新しいネットワークスライスを追加してほしい」と自然言語で指示するだけで、AI エージェントが現在の構成を確認し、SOP に従って IaC とパラメータを生成、Git を介してインフラ(Amazon EC2)→アプリ→アプリのパラメータ設定までを一気通貫でデプロイする様子をご覧いただけます。
シナリオ ③ は前回ワークショップでもご紹介した、ネットワーク障害発生時のアラーム分析・切り分け・措置レコメンド・チケット起票です。今回はマルチエージェント構成を前回からアップデートして実演しました(構成の詳細は前回ブログをご参照ください)。
シナリオ ①/② デモアプリケーション構成図
シナリオ ①/② のデモアプリケーションは、Strands Agents で実装したエージェントを Amazon Bedrock AgentCore Runtime 上で動かし、AgentCore Memory(STM/LTM)と AgentCore Observability も統合した構成です。エージェントは利用者からの一つの指示に対し、ネットワーク機器の操作・IaC のデプロイ・Git への変更反映といった複数の外部アクションを自律的に組み合わせて実行し、本番運用を想定した記憶・観測の仕組みも合わせて体験いただけるようにしています。
通信業界では、仕様書、詳細設計書、ベンダードキュメント、手順書、パラメータ設計規則など、独自フォーマットの大量のドキュメントが存在します。本ハンズオンではこれらを SOP(Standard Operating Procedure) という形式に標準化し、Markdown ファイルとして AI エージェントに与えることで、「人間も AI も同じ手順を読み、同じ成功基準で評価できる」状態を作り出しています。SOP の生成・評価・修正自体も AI エージェントで自動化でき、エラーの有無・ポリシー順守・効率性などを別の SOP 評価エージェントで自動チェックする運用も実演しました。
ユースケース議論ワークショップ
セッション 3 のハンズオンを終えた後半 30 分は、参加者の皆様にご自身の業務に当てはめて考えていただくユースケース議論の時間としました。テーブルごとに AWS SA も加わり、模造紙と付箋を使って「AI エージェントに任せたい業務は何か」「任せるために必要なデータ・指示は何か」「自担当で導入するならどんなアーキテクチャになるか」の 3 つの問いを順に議論いただきました。
各テーブルから出てきたアーキテクチャ図と付箋を AWS 側で見渡して整理すると、参加企業・担当領域は様々であるにもかかわらず、いくつかの共通した観点が浮かび上がってきました。
1. 業務領域ごとに専門エージェントを切り出す発想は共通
多くのテーブルで、AI エージェントを 1 つの巨大な万能エージェントとして描くのではなく、業務領域ごとに専門エージェント(パラメータ設計/Config 設定/検証/監視/チケット起票など)を切り出す構成が描かれていました。配置の仕方はテーブルによって、上位のオーケストレータが束ねる階層型、業務フローに沿ったパイプライン型、業務ごとに独立した並列型と様々でしたが、「役割を分けて、それぞれに SOP を持たせる」という発想は多くのテーブルで共通していました。
2. 既存の社内ツール・データとどう接続するかが、最大の現実論点
多くのテーブルで挙がったのが「既存の社内ツールとの接続」です。チケット管理、ナレッジ共有、ログ分析、構成管理、コミュニケーション基盤、構成情報 DB ― 各社それぞれの現場で長く使われてきたツール群があり、AI エージェントをどう “そこ” に組み込むかが、ハンズオンを「自社で動くもの」にするための最大の現実論点として浮かび上がっていました。
3. AI に任せきれない判断ポイントの設計が、各社共通の論点になっていた
SOP の切り替え判断、Human-in-the-loop による承認・エスカレポイント、検証環境から商用環境への段階的適用 ― 「AI エージェントに任せきれない判断をどう設計に組み込むか」が、開発・運用業務における AI エージェント活用の論点として、複数のテーブルで共通して議論されていました。あるテーブルのホワイトボードには、エスカレポイントに 赤字で「ココが課題」 と書き込まれた付箋が貼られており、本番運用を見据えたときの設計上の難所がここに集約されていることを象徴する一場面でした。
技術を学ぶだけで終わらせず、自社・自業務への適用イメージを「絵」として描き、共通の課題感を他社の方と共有するところまで踏み込めたことが、本セッションの大きな狙いでした。各テーブルで描かれたアーキテクチャや書き出された課題の数々は、AWS として今後の支援活動を組み立てる上で、非常に貴重なインプットとなりました。
参加者の声
- 「AWS のイベントにドコモ/KDDI/ソフトバンク/楽天/ソニーと多くのネットワーク事業者が揃っていることに驚いたし、AWS が通信業界に深く浸透していることを実感した。」
- 「具体的なイメージが湧く内容でよかったです。具体化に向けて引き続きご相談させていただければと思います。」
- 「AI エージェントを作るためのハンズオンが丁寧に作られていて短時間でも内容が理解できました。」
- 「出来上がった AI Agent を体験するよりも、作る過程で AWS を使うメリットをもっと体験したかった。」
- 「テスト環境を触れる期間がもう少し長いと、チームメンバーにも共有しやすい。」
おわりに
本記事では、「通信事業者向けカスタム AI エージェントワークショップ」についてレポートしました。事例登壇・ハンズオン・ユースケース議論を通じて、参加された皆様にとってカスタム AI エージェントの活用イメージが具体化される一日となっていれば幸いです。また、各テーブルでの議論や他社・他部署の方との交流を通じて、業界共通の課題感を共有する貴重な機会にもなったのではないかと考えております。ご参加頂いた皆様、本当にありがとうございました。本ワークショップを通じて得られた知見やフィードバックは、今後の AWS の支援活動にも活かしてまいります。ネットワーク開発・運用 AI エージェントの導入に向けて、本内容が少しでも皆様の業務のお役に立てば幸いです。