こんにちは、ソリューションアーキテクトの宇佐美です。 2026年7月15日(水) に開催された「Neuron Community – 2026 Vol.1」の様子をレポートします。このイベントは、2025年3月に立ち上げられた「Neuron Community」の協力のもと開催しました。 今回は、 AWS Summit Japan 2026 開催後ということもあり、AWS Summit Japan の振り返りや、AWS Neuron のアップデート情報が多めの内容となっています。 Neuron Community とは AWS では、機械学習のトレーニングと推論のための高性能で費用対効果の高い機械学習アクセラレータ（ AWS Trainium 、 AWS Inferentia ）、および深層学習と生成 AI ワークロードを実行するために使用される SDK の AWS Neuron を提供しています。「Neuron Community」は、ユーザー間で AWS Trainium / AWS Inferentia / AWS Neuron の知見共有を促進する場として発足しました。 「Neuron Community」は、主に Discord を使用して運営されています。興味を持っていただいた方は、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq オープニング：Neuron Community の成り立ちとカラクリ社での Trainium 取り組み紹介 中山 智文 氏（カラクリ株式会社 取締役 CPO) 資料：後日公開 オープニングセッションでは、カラクリ株式会社の中山氏より発表していただきました。カラクリ株式会社は、2023年より一貫して AWS Trainium を利用し続けており、Neuron Community の立ち上げにも大きな貢献をしていただいています。この発表では、Neuron Community の始まりについて紹介していただきました。また、カラクリ株式会社の AWS Trainium に関する2つの取り組みについても紹介していただきました。1つ目の取り組みは、Amazon EKS 上に構築された 「Neuron 分散学習プラットフォーム」 です。このプラットフォームを構築することで、インフラ関連の知識が十分ではないメンバーでも分散学習を実行できる環境の整備を進めているそうです。2つ目の取り組みは、AWS Trainium の NKI カーネル開発を促進するための 「カーネル開発エージェント」 です。この AI エージェントにより、NKI カーネル開発をエージェントが自律的に進められるようになるということです。最後に、今後の Neuron Community の活動について、よりオープンな場にしていきたいという発信をしていただきました。 AWS Summit Japan 振り返り① セッションダイジェスト「⼤規模学習から AI エージェントの推論まで ~ コスト効率と性能が両⽴する AWS Trainium の全貌 ~」 澤 亮太 (Amazon Web Services Japan G.K.) 資料： “AI エージェントの推論から⼤規模学習まで” コスト効率と性能が両⽴する AI インフラ ̶ AWS Trainium の全貌 Amazon Web Services Japan G.K. の澤からは、 AWS Summit Japan 2026 の振り返りとして、「”AI エージェントの推論から大規模学習まで” コスト効率と性能が両立する AI インフラ ー AWS Trainium の全貌」のセッションを、15 分のダイジェスト版で紹介しました。このダイジェストでは、AWS Trainium の典型的な使い方として、 “A. コードはそのままで学習コストを下げたい” 、 “B. 性能を最適化したい” 、 “C. 推論コストを固定化したい” の3点に注目して説明しました。 A. では、 Native PyTorch support（ベータ版） を使い、GPU向けPyTorchコードのデバイス指定を cuda から neuron に変更して、AWS Trainium 上で学習を実行する方法を紹介しました。デモでは、GPT-2 の学習スクリプトを実行しました。B. では、 NKI (Neuron Kernel Interface) により AWS Trainium のハードウェア命令セットに直接アクセスして AI カーネルの最適化が可能であることを紹介しました。また、性能最適化とデバッグのワークフローを支援する Neuron Explorer、NKI の開発を AI エージェントで加速するためのオープンソースツールキットの “Neuron Agentic Development” についても紹介し、Neuron Agentic Development のデモを見ていただきました。C. では vLLM on Trainium を使うことで、オープンウェイトモデルをAWS Trainium 上でサービングできます。ここでは、openai/gpt-oss-20b モデルを AWS Trainium 上でサービングするデモを見ていただきました。 AWS Summit Japan 振り返り② ブース展示紹介「⽣成 AI を⽀えるインフラ技術」 赤澤 Toshinobu (Amazon Web Services Japan G.K.) Amazon Web Services Japan G.K. の赤澤からは、 AWS Summit Japan 2026 の振り返りとして、ブース展示「生成AIを支えるインフラ技術」について紹介しました。この展示は、複数のマルチモーダルモデルを Amazon EC2 trn2.48xlarge でサービングする様子を見ていただくもので、マルチモーダルモデルで画像の編集を行います。音声で画像編集の指示をすると Whisper Large v3 で音声認識を行い、Qwen3-VL-8B-Instruct で元になる画像を編集するための指示を生成します。指示は Qwen-Image-Edit-2511 に渡され、画像が編集されます。編集された画像は、Qwen3-VL-8B-Instruct を使って指示通りに編集できているかを講評し、XTTSv2 で音声出力します。この発表では、３匹の子猫のイラストを、4匹に増やすという画像編集の様子を見ていただきました。 また、このデモを実現しているアーキテクチャについての説明も行いました。4つのモデルのtrn2.48xlarge の 64 論理コアへのアロケーションや、モデルのデプロイフローなども説明しています。 AWS Trainium / Inferentia / Neuron SDK 最新アップデート 常世 大史 (Amazon Web Services Japan G.K.) 資料： Neuron Communit 2026 Vol.1 AWS Trainium / Neuron 最新アップデート Amazon Web Services Japan G.K. の常世からは、ちょうどイベント前日にテレビ東京の WBS（ワールドビジネスサテライト）で AI 向けアマゾン独自の半導体開発が特集 されたことに触れ、自身が所属するアマゾン内のチップ開発部隊「アンナプルナラボ」について紹介しました。Anthropic との共同プロジェクト Project Rainier では、これまでに 140 万個超の Trainium 2 および Trainium 3 チップが稼働中であること（WBS 内の特集にて紹介）、 OpenAI が 2GW 規模での Trainium 採用を発表 したこと、また従来のチャットボット型 AI からエージェント型 AI へとシフトする中で、AI チップに加え AWS Graviton プロセッサの重要性が増している点を紹介しました。 Meta が数千万の Graviton コアで Agentic AI をスケールしている事例 にも触れました。 次に、澤のセッションでも紹介された AWS Trainium 向けの SDK「AWS Neuron」のアップデートとして、ライブラリのネイティブ化（Native PyTorch、Native vLLM）の最新状況を紹介しました。 また、7 月 7 日にリリースされた最新の Neuron 2.31 では、性能最適化の要である NKI（Neuron Kernel Interface）と NKI Library に大きなアップデートがあった点、さらに NKI カーネル開発用のエージェントコーディング機能 Neuron Agentic Development によるカーネル自動最適化ループへの注力を紹介し、セッションを締めくくりました。 ※ イベント開催後の 2026年7月20日(月) に vLLM Neuron Beta がパブリックリリースしました！ さいごに 通算3回目の Neuron Community は、カラクリ株式会社での AWS Trainium への取り組みの発表や、AWS Summit Japan 2026 の振り返り、AWS Neuron 関連の最新アップデート情報の紹介と、充実した内容となりました。AWS Summit Japan 2026 のセッション動画は、 AWS Summit Japan の Web ページ に登録いただくことでオンデマンド視聴が可能です。ご興味のある方は、ぜひ登録してみてください。 発表後には今後の Neuron Community についてのディスカッションも行われ、約 1 年ぶりの開催となったことを踏まえ、より高い頻度で開催していこうという声が挙がりました。AWS としても積極的に支援していきます。 今後の Neuron Community も、Discord を中心に募集や告知を行っていきます。興味を持っていただいた方は、ぜひ、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者について 宇佐美 雅紀 (Usami Masanori) 製造業のお客様を担当するソリューションアーキテクトです。 製造業のお客様のクラウド活用を支援しています。 常世 大史 (Tokoyo Hiroshi) AWS Annapurna Labs のソリューションアーキテクトです。 Annapurna Labs が提供する AWS Trainium、Inferentia の技術支援に注力しています。  

みなさん、こんにちは。AWS Japan ソリューションアーキテクトの瀧澤ロナンです。 スマートファクトリーが進展し、製造現場でのOT とクラウドを連携する事例が最近増えています。こうしたアーキテクチャ変更は効率化を促進する一方、システム間の接続やデータ流通の拡大に伴い、考慮すべきセキュリティ境界も増えます。そのため、OT側とクラウド側のそれぞれについて、リスクに応じたセキュリティ要件を明確にすることが重要です。 この課題に対応する上で重要な標準が、 ISA/IEC 62443 です。ISA/IEC 62443は、製造、エネルギー、公共インフラなどで利用される産業用オートメーションおよび制御システム（IACS）のサイバーセキュリティに関する国際規格シリーズであり、製造現場のシステム全体にわたるリスク管理とセキュリティ対策の枠組みを提供しています。本記事では、製造業のお客様が OT をクラウドに接続する際に特に重要となるISA/IEC 62443 の様々な概念を、AWS サービスを使ってどのように実現するのかをご紹介します。お客様は、AWS サービスを活用した製造現場向けのクラウドアーキテクチャを構成することで、ISA/IEC 62443 に沿ったクラウド側のセキュリティ対策を実装できます。 なお、本記事では、ISA/IEC 62443 でのOT とクラウドの接続に関係するゾーンとコンジット、7つの基礎的要件（FR）、可用性を考慮した設計、および関係者間の責任分担を取り上げ、シリーズ全体を解説するものではありません。ISA/IEC 62443 でのリスク評価、セキュリティレベル、個別のシステム要件、セキュリティライフサイクルなどは本記事の対象外であり、詳細については同シリーズの各規格をご確認ください。 AWS における ISA/IEC 62443 のゾーンとコンジット ISA/IEC 62443 における重要な概念の一つが、ゾーンとコンジットです。ゾーンとコンジットとはISA/IEC 62443でのシステム全体をセキュリティ要件に基づいて分割する考え方です。こちらの図ではAWS上のゾーンとコンジットの設計例を表しています。 ISA/IEC 62443 に基づくシステム設計では、共通のセキュリティ要件を持つシステム部分をグループ化し、グループごとに必要なセキュリティ境界を定義します。このグループを「ゾーン（Zone）」と言い、ISA/IEC 62443は、システム部分を具体的にどのゾーンへ分割するかを固定的に規定しておらず、製造事業者はシステムの要件に応じてどのシステム部分を含めるかを決定します。AWSクラウドに繋いでいる製造現場ではPLC やセンサーを含む制御ゾーン、データヒストリアンや生産実行システム（ MES ）を含む製造運用ゾーン、AWS IoT Core によるクラウド側の取り込みゾーン、 Amazon S3 と Amazon Athena による分析・保存ゾーンに分けることができます。ここでいうクラウド側のゾーンは、必ずしも VPC やサブネットと一致するものではなく、共通のセキュリティ要件を持つ AWS リソースをまとめた論理的な境界です。 続いてゾーン間の制御された通信経路を「コンジット（Conduit）」と呼びます。 AWS Site-to-Site VPN や AWS Direct Connect などの通信経路そのものがコンジットになるのではなく、通信経路と、その経路に適用する認証、暗号化、アクセス制御などを合わせてコンジットとして扱います。AWSクラウドにコンジットを設計する際は、例えばAWS IoT Core が入るOT側とクラウド側の取り込みゾーンの間に制限のある通信経路設けることができます。具体的な制限としてAWS IoT Core にMQTT over TLSを使用して通信を暗号化、X.509証明書による相互認証、及びAWS IoTポリシーによるMQTTトピックへのPublish操作の制限などを組み合わせることによってクラウドに適切なコンジットが設計できます。また、インターネット経由のアウトバウンド接続を許容しないシステム要件や、帯域、遅延、可用性などの要件がある場合には、暗号化を利用したAWS Site-to-Site VPN や AWS Direct Connectをコンジットの伝送手段として選択できます。 AWS Network Firewall も複数のネットワークや VPC を横断する集中検査がセキュリティ要件で必要とされた場合にコンジット内に導入できます。 最後にOT とIT／クラウドの接続ではDemilitarized Zone(DMZ)という独立したゾーンを配置することも一般的に行われ、両者を直接接続せずに必要最小限の通信だけをコンジットとして中継するネットワーク領域を立てることができます。AWS では、 AWS IoT Greengrass を実行するエッジゲートウェイをDMZ に配置して、OTとクラウド間の境界ゲートウェイとして構成することができます。 AWS で ISA/IEC 62443 の7つの基礎的要件を充足する 7つの基礎的要件（FR：Foundational Requirement）も、ISA/IEC 62443 に欠かせない概念です。ISA/IEC 62443での7つの基礎的要件は、製造現場のシステムが満たすべき技術的特性をまとめたものです。次の表は、7つの基礎的要件と、それらを支援する代表的なAWS サービスを対応付ける一例です。これらのサービスは ISA/IEC 62443 との適合に必須ではなく、また利用するだけで ISA/IEC 62443への適合が達成されるわけでもありません。システムが該当する要件を満たしているかどうかを判断し、実証する責任は、製造事業者にあります。設計が基礎的要件を満たしているのかは、実際の製造現場システムを確認して評価する必要があります。 FR 要件の概要 FR を支援する代表的なAWSの機能 FR1 – 識別と認証管理 （Identification and Authentication Control） 利用者（人、ソフトウェアプロセス、機器）を正しく識別・認証する。 AWS IAM 、AWS IoT Core（デバイスごとの X.509 証明書）、 AWS Private CA 、 IAM Identity Center。 FR2 – 利用管理（Use Control） 利用者が許可された操作のみを実行するよう強制し、その実行を監視する（最小権限）。 AWS IoT Core の IoT ポリシーと MQTT トピック、IAM ポリシー／SCP、セッション制御、 AWS CloudTrail （監査）。 FR3 – システム整合性（System Integrity） 状態を意図した範囲内に保ち、改ざんや意図しない遷移を防ぐ。 AWS Systems Manager （構成・パッチの完全性）、 Amazon Inspector 、AWS IoT Device Defender、AWS Signer（エッジ／クラウドにデプロイするコードの署名）。 FR4 – データ機密性（Data Confidentiality） 通信中および保存時のデータの秘密性を保護する。 MQTTS（相互 TLS）など通信中の暗号化、 AWS KMS （鍵管理）、Amazon S3 のサーバー側暗号化。プライベート接続が必要な場合はAWS Site-to-Site VPN、または暗号化の構成を追加した AWS Direct Connect。 FR5 – データフロー制限（Restricted Data Flow） ゾーンとコンジットでセグメント化し、不要なトラフィックを防ぐ。 AWS IoT Core の IoT ポリシーと MQTT トピック。プライベート接続や集中検査が必要な場合は、 Amazon VPC 、セキュリティグループ、 AWS PrivateLink 、AWS Network Firewall。 FR6 – イベントへの適時対応（Timely Response to Events） 事象を検知・振り分け・トリアージし、証拠を保全して、対応を推進する（手順化、自動化）。 AWS IoT Device Defender、AWS IoT Core のログ、 Amazon GuardDuty （AWS 環境の脅威検知）、 AWS Security Hub （セキュリティ検出結果の管理）、 Amazon CloudWatch （監査）、保護されたログストレージと組み合わせた AWS CloudTrail（証拠保全）。完全な対応には、引き続き人による手順とオーナーシップが必要。 FR7 – 可用性（Resource Availability） 必須サービスの可用性を維持し、障害後の復旧を可能にする。 障害発生時の復旧に使用：AWS IoT Greengrass のローカル処理とバッファリング、AWS IoT Core や Amazon S3 などのマネージドサービス、必要に応じた接続経路の冗長化。 AWS Backup とAmazon S3 Object Lock は障害発生の回復時間に使用。 AWS における OT 可用性優先の設計 クラウドに接続した製造現場でISA/IEC 62443を実現する際、OTでの可用性優先も抑えておく必要があります。IT と OT は両方ともサイバーセキュリティの優先順位を整理するために、CIA三原則（機密性・完全性・可用性）の考え方を用いますが、それぞれの優先順位は異なります。IT では一般に機密性を最優先するのに対し、OT では可用性を最優先する場合が多く、その理由は制御の停止が、生産、安全、環境に影響を及ぼす可能性があるからです。OT では主に可用性を優先するため、クラウド接続が失われてもプラントは稼働を継続しなければならないという設計が多く見られます。 AWS Well-Architected の「 Modern Industrial Data Technology レンズ 」も、この可用性を重視した考え方に対応しています。「Modern Industrial Data Technology レンズ」のレジリエンスのベストプラクティス項目 MIDAREL02-BP01 では、クラウド接続が失われても重要な生産活動を継続できるよう、ローカル処理、データのバッファリング、自動復旧を求めています。 AWS IoT Greengrass は、この設計の実現に役立つサービスの一つであり、クラウドとの接続が失われた場合も、エッジでローカル処理を継続できます。データをローカルにバッファリングし、接続回復後に対応する AWSサービスへ転送するには、AWS IoT Greengrass の Stream Manager コンポーネントを使用し、ストレージ容量、保持期間、転送先などを要件に応じて構成します。 ISA/IEC 62443 と AWS における責任のマッピング 最後にISA/IEC 62443 における重要な概念はロールに基づく責任分担です。本規格シリーズでは、責任分担は役割により振り分けられ、各役割の責任と担当範囲はゾーンと違い固定的に定められています。ISA/IEC 62443 では、製造現場のセキュリティを扱う際の 4 つの役割として、資産保有者（Asset Owner）、構築サービスプロバイダー（Integration Service Provider）、保全サービスプロバイダー（Maintenance Service Provider）、製品サプライヤー（Product Supplier）を定めています。資産保有者はシステムを所有・運用し、主要な責任を担います。構築サービスプロバイダーはソリューションを設計・構築し、保全サービスプロバイダーは導入後の保守を担い、製品サプライヤーは機器や製品を提供します。これらの役割は製造現場の長期的サイバーセキュリティ維持全体に関わり、資産保有者が要件とリスクを評価し、構築サービスプロバイダーが実装し、保全サービスプロバイダーが運用・保守するという役割を果たします。 一方でISA/IEC 62443 の各役割と、AWS とお客様の間の AWS 責任共有モデル は、異なる責任分担を表しているため、1 対 1 で対応付けることはできません。AWS責任共有モデルは、セキュリティに関する責任を AWS とお客様の二者つの領域に分担するモデルです。AWSの責任領域は、AWS サービスを稼働させるインフラストラクチャを含む「クラウドのセキュリティ（security of the cloud）」に責任を負います。お客様の領域ではAWS上で使用するAWSサービスの選択と設定に加え、データ、アプリケーション、ID、アクセス権限などを管理する責任を負います。このように、ISA/IEC 62443の責任分担とAWS 責任共有モデルは異なるため、製造現場がAWSを利用する際にはどの領域が責任担当になるのは明確ではありません。この責任分担の明確化に役立つのが、先ほど紹介したAWS Well-Architected の「Modern Industrial Data Technology レンズ」です。このレンズでは、AWS 責任共有モデルを前提に、クラウド、IT、OT の各ステークホルダーの責務を分け、ワークロードに合わせた責任分担を定義することを推奨しています。このレンズを活用することで、AWS 責任共有モデルを土台としながら製造現場に応じてクラウド、IT、OT に関わる各責任者の担当範囲を具体的に定義することができ、責任分担を明確化することができます。 まとめ 本記事では、ISA/IEC 62443 の主要な概念を用いて、OT とクラウドを接続する際に保護すべき対象と必要となるセキュリティ対策を整理しました。そのうちクラウドに接続された領域における技術的対策と実装はAWSのサービスにより実現することができます。AWSサービスは、ゾーンとコンジットの設計に加え、7つの基礎的要件（FR1〜FR7）に関連するクラウド側の技術的対策や、可用性を重視した現場とクラウドの接続設計を支援します。ISA/IEC 62443 に基づいてAWS サービスを適切に活用することで、OTセキュリティ上のリスクを低減しながらクラウドを導入し、製造現場のデジタル変革を進めることができます。実際の検討を始める際は、まず対象システムの範囲、資産、データフローを可視化し、リスク評価に基づいてゾーン、コンジット、セキュリティ要件、および関係者間の責任分担を定義することをお勧めします。そのうえで、要件に適した AWS サービスと構成を選択し、設計した対策が期待どおりに機能することを検証すれば、OTセキュリティ上のリスクを管理しながら、製造現場におけるクラウド活用を進めることができます。 執筆者について 瀧澤ロナン / Ronan Takizawa 2026 年 4 月入社のソリューションアーキテクト ISA/IEC 62443 の全資格（Fundamentals, Risk Assessment, Design, Maintenance, Expert）を保有 お客様のOT セキュリティとクラウド活用の支援を目指している

はじめに 2026 年 6 月 25 日(木)、26 日(金)の 2 日間にわたって幕張メッセで開催された AWS Summit Japan 2026 では、AWS Expo の Industry Zone に「AWS for Telecom」として通信業界に関する展示ブースを出展しました。 本ブログでは、株式会社NTTドコモ、KDDI株式会社、ソフトバンク株式会社の各社と共に展示した全 7 ブースの内容をご紹介します。通信領域では NW 設計・構築から運用保守まで、非通信領域ではスマートシティやコンタクトセンターの領域で Agentic AI が通信業界をどう変えつつあるのか を、各社の最新の取り組みからご覧いただけます。 展示一覧 カテゴリ ブース ID 出展社 テーマ 通信領域 A063 株式会社NTTドコモ Agentic AI で AWS 上に 5G コア構築・運用開始 A064 KDDI株式会社 AI 駆動開発で加速する RAN 自動制御と品質改善 A067 株式会社NTTドコモ ネットワーク保守 AI エージェント A068 ソフトバンク株式会社 Amazon Neptune で実現する NW トポロジー可視化 A069 AWS エージェンティック AI が実現する自律運用 非通信領域 A065 KDDI株式会社 KDDI が創る、未来のスマートシティ A066 AWS AI で変革する通信業界の顧客体験 A063：Agentic AI で AWS 上に 5G コア構築・運用開始（株式会社NTTドコモ） ＊ 資料ダウンロード NTTドコモは AWS 上に 5G コアを構築し、国内初となるハイブリッドクラウド環境での商用サービスを開始しました。 この AWS 上の 5G コア構築は、 世界初となる Agentic AI と GitOps を組み合わせた設計・構築自動化 によって実現されています。膨大な過去コンフィグやドキュメントの確認、相互依存する複数コンフィグ間の整合性担保、手動作業によるデプロイ完了までの長期間化の課題がありましたが、AI エージェントが自律的にドキュメントを参照しながら設定ファイルを自動生成し、Git を介した CI/CD パイプラインで自動デプロイする仕組みへと変革することで、従来から 80% のリードタイム短縮と自動化による品質向上をを実現しました。 本展示では、この取り組みの概要や効果、技術要素をご紹介しました。 ポイント： 国内初：AWS 上での 5G コア商用構築・運用開始 世界初：AI × GitOps による 5G コアの設計・構築自動化 Amazon Bedrock AgentCore 上のオーケストレータエージェントが複数の専門 AI エージェントを統括 A064：AI 駆動開発で加速する RAN 自動制御と品質改善（KDDI株式会社） ＊資料ダウンロード 説明 | デモ画面抜粋 KDDI は、無線ネットワーク（RAN）の自動制御に向けて、O-RAN 標準インタフェースに準拠した基地局制御の共通基盤（SMO: Service Management and Orchestration）と、その上で動作するネットワーク制御アプリ（rApp）を AWS 上で内製開発しています。その開発において、 AWS が提唱する AI-DLC（AI-Driven Development Life Cycle）を導入 しました。 AWS が公開している AI-DLC ワークフロー（ aidlc-workflows ）をそのまま使うのではなく、社内のガイドラインやセキュリティ要件に合わせてカスタマイズしています。具体的には、開発スコープ・技術制約・質問事項を整理して議論のたたき台を作る事前フェーズの追加や、社内ルール対応のための Claude Code スキル化などを実施しました。 AI-DLC を取り入れた結果、要件定義からデプロイまでの開発期間を 70％ 削減しました。 この取り組みで開発した新 rApp により、 基地局パラメータの全国展開期間を約 50% 短縮 しています。 この展示内容については、 KDDI Tech note でも紹介されています。 ポイント： AI-DLC は導入して終わりではなく、社内要件に合わせて継続的にカスタマイズ コード生成だけでなく設計・レビュー・ドキュメントまで、開発ライフサイクル全体への AI 適用 要件定義からデプロイまでの開発期間を 70% 削減、パラメータ全国展開期間も約 50% 短縮 A067：ネットワーク保守 AI エージェント（株式会社NTTドコモ） ＊ 資料ダウンロード NTTドコモは、RAN からコアネットワークまで 世界最大級の 100 万台超の通信機器データを分析し、 ネットワークの保守運用を効率化する AI エージェントの商用利用を開始 しました。 本展示では、AI が自律的に異常を検知し、複雑な障害の原因特定から復旧手順の提案を行うまでの一連の動作をご紹介しました。本技術により 障害復旧時間を 50% 以上短縮 し、通信インフラの安定稼働および早期の異常復旧に貢献することで、お客様の通信をつなぎ続けます。 ポイント： 100 万台超の通信機器データをリアルタイム分析 異常検知 → 原因特定 → 復旧手順提案まで自律的に実行 障害復旧時間 50% 以上短縮を商用環境で実現 A068：Amazon Neptune で実現する NW トポロジー可視化（ソフトバンク株式会社） ＊資料配布はございません ソフトバンクは、ネットワークにおける障害検知から復旧までのプロセスを運用者の手を介さず自動で完結させるクローズドループの取り組みを紹介しました。また、この取組みのさらなる拡張のため、 Amazon Neptune を用いたトポロジーの時系列化 のアプローチを紹介しました。 即時性の高いトポロジー把握はネットワーク運用に有用ですが、ネットワークは計画作業に伴う変動に加え、障害起因の突発的な変動も発生します。そのため、設計情報や config 等の静的データに加え、実際のネットワークの状態変化を示す動的データを継続的に収集し、トポロジー情報へ反映することも重要です。トポロジーの時系列情報を扱うことができれば、障害調査の際にリアルタイムの状態だけでなく障害前後のトポロジー情報を原因の特定や迂回可否判断に活用できます。 ポイント： 静的データ＋ 動的データを取り込み Digital Twin と実ネットワークとの同期精度を向上 Amazon Neptune によるグラフデータベースでトポロジーを時系列管理 クローズドループをさらに拡張し、状態追従性、判断根拠の鮮度、判断の迅速性を向上 A069：通信ネットワーク運用の未来 — エージェンティック AI が実現する自律運用（AWS） ＊ 資料ダウンロード エージェンティック AI が通信事業者のネットワーク運用を自律的に監視・分析・実行し、 リアクティブからプロアクティブへ 変革するオペレーションセンターのデモを展示しました。すべて Amazon Bedrock AgentCore 上のマルチエージェントで実現し、専門エージェントが協調して RAN〜Transport〜Core の E2E 運用を担います。デモ全体のコンセプトは、 AI が分析・事項を行い、人間は戦略的な意思決定に集中 することです。 本展示では、来場者の関心に応じて4つのデモをご覧いただきました。 ① データ統合基盤の構築 ：4つのソースに分散したデータを AWS Glue で正規化・時刻同期・トポロジー相関付けし、Amazon DynamoDB・Amazon Timestream・Amazon Neptune・Amazon Bedrock Knowledge Bases に格納。エージェントが自律判断できる土台を整えます。 ② 障害の自動検知・復旧 ：バックホール回線の物理故障をアラームスパイクから検知し、グラフ解析で真因と巻き添えを切り分け。バックアップルート起動から故障機器の交換手配まで、人手の判断を待たずに数分で完結します。 ③ 予測に基づく最適化 ：Amazon SageMaker が大規模イベント時の需要急増を事前に予測し、サービス・インフラ・トランスポートの3層にまたがる最適化戦略を自動立案。人間の承認後にエージェントが並列実行します。 ④ 顧客別のプロアクティブ対応 ：障害の影響を SLA やビジネスインパクトで把握し、影響の大きいお客様を優先。代替経路への自動切替と、状況に応じたパーソナライズ通知の自動生成までを実行します。 いずれも最終判断は人間が行う Human in the Loop を前提とし、受動的な運用から AI 主導のプロアクティブな運用への変革をご体感いただきました。 ポイント： Amazon Bedrock AgentCore 上のマルチエージェントが、データ統合基盤から障害復旧・予測最適化・顧客対応までを自律実行 障害検知から復旧までを数分で完結し、需要急増は事前に予測して予防（リアクティブからプロアクティブへ） 重要な実行判断は人間が担う Human in the Loop——「AI が分析・実行、人間は戦略に集中」 A065：KDDI が創る、未来のスマートシティ（KDDI株式会社） ＊資料配布はございません KDDI は「つなぐチカラ」で、都市の価値を最大化するスマートシティを推進しています。「100年先の心豊かなくらしのための実験場」を掲げる TAKANAWA GATEWAY CITY では、JR東日本と共創し、都市OS「TAKANAWA GATEWAY URBAN OS」を核としたサービスを展開しています。 本展示では、この都市OS 上で動く 2 つのサービスをご紹介しました。 来街者向け：TAKANAWA GATEWAY CITY アプリ 都市OS のリアルタイムデータを活用し、街で働くワーカーや来街者に、街の中での“快適さ”を提供するアプリです。駅改札やオフィス入館ゲートとの連動で来街タイミングを捉えたレコメンドを実現し、Amazon Bedrock でコンテンツ訴求文章を自動生成しています。 事業者向け：「データダッシュボード」で街の状況を可視化するサービス 街の有事（防災・警備）と平時（マーケティング・イベント計画）を同一機能で可視化・分析するダッシュボードです。3D 人流シミュレーションやリアルタイム可視化に加え、Amazon Bedrock による AI 分析でイベントの成果や改善策を把握できます。 ポイント： JR東日本との共創による都市型デジタルツイン URBAN OS を核としたリアルタイムデータ連携 来街者と事業者それぞれに最適化された体験の提供 A066：AI で変革する通信業界の顧客体験 — Amazon Connect で実現する自律的な顧客支援（AWS） ＊ 資料ダウンロード 通信業界の顧客サポートを、AI エージェントで リアクティブからプロアクティブへ 、そしてコ ストセンターと捉えられがちなコンタクトセンターを収益に貢献するバリューセンターへ変革 するソリューションを、コンタクトセンターとデバイスの両面から実現する 2 部構成のデモでご紹介しました。 前半：コンタクトセンターの自律型顧客応対エージェント（日本語デモ） Amazon Connect 上の AI エージェントが、携帯電話料金の問い合わせを 日本語 で自律対応する様子をご覧いただきました。意図認識から本人確認、請求明細の取得、最適なプランの提案、プラン変更の実行まで、 Amazon Bedrock AgentCore Gateway（MCP） で業務システムと連携し、回答だけでなく手続きまでを一気通貫で完結します。人手が必要な場面では会話の文脈を引き継いで有人対応へシームレスにつなぎ、AI が担当者を支援します。 後半：Agentic AI で実現するコネクテッドデバイスケア デバイスを起点に、問題が起きる前に対応する体験もご覧いただきました。お客様の許可のもと、デバイス上の SDK が多数の診断テストでバッテリー劣化などの予兆を検知し、デバイス上で動く Agentic AI の音声エージェント（ Amazon Nova Sonic ）がプロアクティブに連絡してその場で解決します。解決しない場合も文脈を引き継いだまま有人対応へつなぐため、お客様が同じ説明を繰り返す必要はありません。海外の通信事業者での導入実績をもとにした発展形で、課題解決を起点に最適な料金プランや端末下取りといった次の提案（＝「ケアをコマースへ」）にもつなげられます。 ポイント： 前半：Amazon Connect の AI エージェントが日本語で自律対応し、Amazon Bedrock AgentCore Gateway（MCP）連携で手続きの実行まで完結（必要時は文脈を保ったまま有人へ） 後半：予測 AI と Amazon Nova Sonic による、デバイス起点のプロアクティブなケア リアクティブからプロアクティブへ、コンタクトセンターを収益に貢献するバリューセンターへ（＝「ケアをコマースへ」） まとめ 今回の AWS Summit Japan 2026 AWS Expo「AWS for Telecom」展示では、通信業界における Agentic AI の活用が、ネットワークの設計・構築から運用保守、顧客体験、さらにはスマートシティまで、幅広い領域で商用レベルで活用されていることをお伝えしました。 AWS は今後も通信業界の皆さまと共に、ネットワークの自律化と新たなサービス創出に向けた取り組みを加速してまいります。 著者 神谷 拳四郎 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第二ソリューション部 ソリューションアーキテクト 川岸 基成 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第一ソリューション部 ソリューションアーキテクト 小林 新一 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第一ソリューション部 ソリューションアーキテクト