NTTドコモビジネス株式会社（以下、ドコモビジネス）は、日本最大級のネットワーク展示会である「Interop Tokyo 2026（会場：幕張メッセ、会期：2026年6月10日〜12日）」において構築されるShowNet 1 にContributorとして参加し、docomo business SIGN™を活用したモバイル回線・セキュリティ・データ利活用に関する取り組みを行いました。 本記事では、ShowNet管理網へのセキュアなリモートアクセス環境の構築、脅威検知・フローログを活用したセキュリティ機能の評価、およびMEC 2 /SDPF 3 クラウドサーバーやクラウドサービスと連携したテレメトリデータの収集・可視化についてご紹介します。また、それらの構成や検証内容、検証を通じて得られた知見についても解説します。 はじめに ShowNet 2026におけるdocomo business SIGN™の役割 取り組み①: セキュアなリモートアクセス環境 取り組み②: 脅威検知機能の検証 〜キーサイト・テクノロジー様のThreat Simulatorを用いて〜 取り組み③: データ利活用基盤 ShowNet 2026での知見を踏まえた機能リリース フローログ可視化機能のリリース フレキシブルデータ変換機能（スクリプト変換）のリリース 今後の展望 セキュリティ機能の高度化 データ利活用基盤の強化 おわりに はじめに こんにちは、IoT&フィジカルAIサービス部の小林です。 ドコモビジネスは、「Interop Tokyo 2026」にContributorとして参加し、docomo business SIGN™を活用したセキュアなモバイル基盤とIoT脅威検知およびデータ利活用への取り組みを行いました。 ShowNet エクスターナル図 Copyright (c) Interop Tokyo 2026 ShowNet NOC Team Member and NANO OPT Media, Inc. All rights reserved.引用元： https://www.interop.jp/2026/assets/img/shownet/concept/external-pop-2026-web.pdf ShowNet 2026におけるdocomo business SIGN™の役割 docomo business SIGN™は、モバイル回線・セキュリティ・データ利活用を一体で提供するサービスです。SIGNでは用途に応じて複数の回線メニュー(Value/Advanced) が用意されており、脅威検知をはじめとするセキュリティ機能や、アプリケーション接続機能・MECといったデータ利活用機能を組み合わせて利用できます。 ShowNet 2026では、回線・セキュリティ・データ利活用の機能を組み合わせ、会場のネットワーク構築・運用を支えました。 本記事では、その取り組みの中から、「①セキュアなリモートアクセス環境」「②脅威検知機能の実証」「③データ利活用基盤」という3つのテーマに沿ってその裏側をご紹介します。 取り組み①: セキュアなリモートアクセス環境 1つめの取り組みは、ShowNet管理網に対するセキュアなリモートアクセス環境の提供です。 ShowNetでは、構築期間から会期中にかけて、NOC (Network Operations Center) やSTM (ShowNet Team Member) が多数のネットワーク機器やサーバーの設定変更、監視、障害対応をします。 会場内の機器に常に物理的にアクセスできるとは限らないため、遠隔からでも安全かつ簡単に管理網へ接続できるリモートアクセス環境が求められます。 そこで、遠隔地からでも安全に管理網へ接続し、迅速に運用作業を実施できる環境を提供しました。 今回は、docomo business SIGN™ Valueの閉域SIMを活用し、LTE USBドングルをPCへ接続するだけでShowNet管理網へアクセスできる環境を提供しました。 利用者には、あらかじめ設定済みのSIGN SIM入りUSBドングルを配布しました。 一般的なVPN接続のように専用アプリを起動するといったことが必要なく、USBドングルを挿すだけで、物理的にインターネットから隔離された安全なネットワークへ即座に接続できる構成としています。 「インターネットを通らない強固な閉域性」と「デバイス側の設定が不要な利便性」を両立できる点は、docomo business SIGN™ Valueならではの大きな特長です。 ShowNetでは、運用担当者の利便性を損なうことなく、安全なネットワーク運用を支える基盤として活用しました。 さらに、この環境では、閉域接続に加えて、脅威検知機能とフローコレクター機能も組み合わせました。 脅威検知機能では、不審な通信を検知した際にメールやSIGNコンソールで確認でき、必要に応じて指定した回線の通信を停止することも可能です。 フローコレクター機能では、通信の流れを記録できるため、通信状況の把握やインシデント発生時の調査に活用できます。実際に会期後にはフローログを用いて通信状況を分析したところ、構築期間から会期中にかけてShowNet管理網の利用が増加していたことに加え、利用されていたアプリケーションやプロトコル、通信先などを把握できました。 加えて、構築期間から会期中までの通信傾向を時系列で追跡できたことから、フローログが通信実態の把握や障害・セキュリティインシデント発生時の分析基盤として有効であることも確認できました。 利用者からは、「USBドングルを接続するだけで簡単に利用できた」「通信も安定していた」といった評価をいただいています。 取り組み②: 脅威検知機能の検証 〜キーサイト・テクノロジー様のThreat Simulatorを用いて〜 SIGNの脅威検知機能については、キーサイト・テクノロジー様のThreat Simulatorを用いて、実環境に攻撃トラフィックを流す形での検証にも取り組みました。 これは単なる机上評価ではなく、実際に攻撃トラフィックを発生させた環境で検知性能を確認するという、ShowNetならではの検証です。 Threat Simulatorでは、マルウェアダウンロード通信や既知の脆弱性攻撃を含む疑似攻撃トラフィックを生成し、SIGNによる検知可否を評価しました。 検証の結果、マルウェアダウンロード通信などの不審通信について90%以上の検知を確認でき、実運用環境に近い条件下でもSIGNの脅威検知機能が有効であることを確認できました。 Threat Simulatorで生成した攻撃トラフィックの例 Threat Simulatorで生成した攻撃トラフィックに対するSIGNの脅威検知結果 このように、閉域接続によるセキュアな通信、脅威検知によるリスク対策、フローログによる通信の見える化を組み合わせることで、ShowNetのような実運用に近い環境においても、安全性と運用性を両立したモバイル基盤を提供できることを確認しました。 取り組み③: データ利活用基盤 3つめの取り組みは、モバイル回線直結のIaaS基盤を活用したデータ利活用です。 ShowNetでは、ネットワーク機器や分散GPU基盤から出力されるログやメトリクスを収集し、運用状況の把握や展示での可視化で活用しました。 今回の構成では、SIGN Advanced SIM、MEC/SDPFクラウドサーバー、SIGNのアプリケーション接続機能を利用し、ShowNet網内のテレメトリデータを、SDPFクラウドサーバー上のログ分析基盤へ転送・保存できる環境を構築しました。 また、Splunk製のログ分析基盤がMEC/SDPFクラウドサーバー上で安定して動作することも確認しています。 さらに、AI-Grid 4 の取り組みと連携し、分散GPU基盤の利用率や消費電力をクラウド上で可視化しました。 SIGN Advanced SIMとアプリケーション接続機能を活用することで、個別開発や複雑な接続設定を最小限に抑えながら、短期間でデータ収集・可視化基盤を構築できたことも成果の1つです。 あわせて、パロアルトネットワークス様のPA-415-5GやION-1200-C5G-EXP、フォーティネットジャパン様のFortiGate-51G-5Gといった5G対応機器で、SIGN SIMを用いた接続確認も実施しました。複数ベンダーの機器が混在する環境においても相互接続性を確認でき、新たな活用に向けた知見を得ることができました。 今回の検証を通じて、モバイル回線、MEC/SDPFクラウドサーバー、ログ分析基盤、クラウドサービスを組み合わせることで、ShowNet内のデータを収集・可視化・分析に活用できることを確認しました。 ShowNet 2026での知見を踏まえた機能リリース ShowNet 2026では、実際の運用環境に近いネットワーク上で、モバイル回線・セキュリティ・データ利活用の各機能を検証しました。 その中で、サービスの有効性だけでなく、実運用における課題や改善の方向性も見えてきました。 こうした知見をもとに、Interop会期後にはいくつかの機能をサービスへ反映しています。 フローログ可視化機能のリリース ShowNetでは、フローコレクター機能によって収集したフローログを活用し、SIMごとの通信量分析や通信先分析、時系列分析などを実施しました。 その結果、構築期間から会期中にかけての通信傾向や利用実態を把握できることを確認しました。 一方で、こうした分析にはログの集計や可視化が必要となり、利用者自身が実施するには一定の知識や作業を要することも分かりました。 そこで、これらの課題を踏まえ、Interop会期後にはフローログ可視化機能をリリースしました。 SIGNコンソール上で回線ごとの通信量や通信先、時間帯ごとの通信傾向などを確認できるようになり、ネットワーク利用状況の把握や異常通信の早期発見、トラブル発生時の原因調査に活用できます。 これにより、利用者自身が個別に分析環境を準備することなく、通信状況をより手軽に把握できるようになりました。 フレキシブルデータ変換機能（スクリプト変換）のリリース データ利活用の検証では、SIGN Advanced SIMやアプリケーション接続機能を活用することで、短期間でデータ収集・可視化基盤を構築できることを確認しました。 一方で、複数ベンダーの機器やクラウドサービスと接続する中で、デバイスごとに出力されるテレメトリデータの形式が異なり、データ連携時に変換処理が必要となるケースがありました。 こうした課題に対応するため、Interop会期後にはフレキシブルデータ変換機能（スクリプト変換）をリリースしました。 この機能により、ネットワーク側でデータ形式を柔軟に変換できるようになり、多様なデバイスやクラウドサービスとの連携を容易に実現できるほか、データ活用開始までの工数削減も期待できます。 今後の展望 ShowNet 2026では、実運用に近い環境でモバイル回線、セキュリティ、データ利活用の各機能を組み合わせて検証したことで、サービスの有効性だけでなく、実運用における課題や改善の方向性についても多くの知見を得ることができました。 今後は、今回得られた知見をもとに、セキュリティ機能とデータ利活用機能の両面で、より実運用に寄り添った機能強化を進めていきます。 セキュリティ機能の高度化 セキュリティ面では、脅威検知機能のシグネチャ強化や分析機能の拡充を進めていきます。 今回の検証では、マルウェアダウンロード通信などの不審通信に対する有効性を確認できただけでなく、IoT機器特有の通信傾向を活用した検知の可能性も見えてきました。 IoT機器は通信先や通信パターンが比較的固定的であるため、挙動ベースの分析と組み合わせることで、さらなるセキュリティ強化につなげられると考えています。 データ利活用基盤の強化 データ利活用の面では、構築・連携にかかる負荷のさらなる低減と、多様なデータソースへの対応を進めていきます。 今回のShowNetでは、Splunkによるモニタリング基盤構築や各種クラウドサービスとの接続設定を通じて、データ利活用の導入負荷低減が今後の課題であると認識しました。 そこで、IoTカタログ 5 の拡充やデータ連携パターンのテンプレート化を進め、データ活用をより短期間で開始できる環境の実現を目指しています。 おわりに 今回のShowNet 2026では、docomo business SIGN™を活用し、「セキュアなリモートアクセス環境」「脅威検知機能の実証」「データ利活用基盤」という3つの取り組みに挑戦しました。 実運用に近い環境での検証を通じて、サービスの有効性を確認できただけでなく、実運用上の課題や改善の方向性についても多くの知見を得ることができ、その一部は実際のサービス改善にも反映されています。 今後もShowNetのような実証の場で得られた知見をサービスへ反映しながら、現場の機器やクラウドサービスをより安全に、より簡単につなげられる環境づくりに取り組んでいきます。 docomo business SIGN™についてはこちら ShowNetは、最新のネットワーク技術・ネットワーク機器などを相互に接続し、「5年後、10年後に必要となるネットワークの姿」を示すというビジョンのもとに構築するコンセプトネットワークです。 最先端のアーキテクチャを動態展示するネットワークであり、 同時に来場者や出展社にインターネット接続性を提供するネットワークでもあります。 ↩ MEC（Multi-access Edge Computing）は、利用者やデバイスに近いネットワークのエッジでデータ処理やアプリケーション実行をするコンピューティング技術です。クラウドと比べて低遅延での処理が可能であり、リアルタイム性が求められるIoTや映像分析、AIアプリケーションなどで活用されています。 ↩ SDPF（Smart Data Platform）は、NTTドコモビジネスが提供するデータ利活用プラットフォームです。クラウド、ネットワーク、セキュリティなどの各種サービスを統合的に提供し、企業のシステム構築やデータ収集・蓄積・分析を支援します。 ↩ AI-Gridは、地理的に分散したGPUなどのコンピューティング資源をネットワークで相互接続し、統合的にオーケストレーションするAIインフラストラクチャの概念です。ShowNet 2026では、モバイルネットワークを介して、全国に分散配置されたGPU搭載MEC基盤などと連携しました。 ↩ IoTカタログは、docomo business SIGN™において、IoT環境構築に必要なモバイル回線、ネットワーク接続、データ利活用基盤（Things Cloud、MAXIV等）を組み合わせて提供するサービスメニュー群です。お客さまの用途に応じて必要な構成を選択できます。 ↩

みなさん、こんにちは。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日に幕張メッセで開催された AWS Summit Japan 2026において、AIエージェントによる建設機械のフリート管理デモ「産業機械の自律診断とリアルタイム安全監視」を展示しました。本記事では、このデモの技術的な構成と考え方を解説します。 建設機械や産業機械の保全業務では、機械の異常をいかに早く検知し、いかに早く適切な対処につなげるかが稼働率を左右します。また、日本をはじめ多くの国で熟練技術者の高齢化と労働力不足が進行しており、保全業務の担い手の確保は年々困難になっています。フリート運用の現場では、機械の情報が現場や機体ごとに分散して全体状況が把握できないこと、故障対応が熟練者の経験に依存することが課題となり、結果として復旧に時間と人手がかかります。センサーデータに基づく予知保全はこの課題への代表的なアプローチですが、従来の機械学習による異常検知には「異常が起きていることは分かるが、なぜ起きているのか、何をすべきかまでは分からない」という限界がありました。異常スコアを受け取った保全担当者は、結局マニュアルを調べ、過去の類似事例を探し、対処方針を自分で組み立てる必要があります。 本デモはこの課題に対し、IoT による遠隔監視で分散した情報を集約して機械の状態を可視化し、生成 AI エージェントが異常の一次分析と情報収集を自動で行うことで、保全担当者が判断と対処に集中できる環境を作る構成としています。エージェントが原因候補と対処手順をあらかじめ提示することで、経験の浅い担当者でも初動対応に着手しやすくなり、熟練者は高度な判断が求められる場面に集中できます。人手による報告、古典的な機械学習、そしてエージェント型の予知保全という3 つのアプローチを同一のフリートに対して並べて体験できる構成とし、それぞれの特性の違いが分かるようにしています。さらに、検知した異常に対する診断、チケット起票、オペレーターへの音声通知、実機の遠隔操作までを含めたエンドツーエンドのデモとして構築しました。 デモ概要紹介の動画は こちら からご覧いただけます。 デモの全体像 デモのシナリオは、建設機械メーカーのアフターサービス部門が、顧客先で稼働する 20 台の掘削機を遠隔監視し、サポートを提供するという設定です。東京エリアの各現場に散らばる掘削機はエンジン温度、エンジン回転数、油温、油圧、冷却水温度、クーラント残量、燃料残量といったテレメトリを送信しており、ダッシュボードではフリート全体の状態を一覧できます。 フリートマップは Amazon Location Service で構築しており、各機体の位置と状態 (Operational / Warning / Critical / Offline)を地図上に表示します。展示では、20 台のうち 19 台が正常に稼働し、1 台が異常状態にあるというシナリオを用いました。異常機体の存在を把握しマシン一覧に進むと、該当機体のエンジン温度と油温が異常に高いことをテレメトリから確認できます。分散していた機体の情報が一画面に集約されているため、異常の発見から状況の把握までがダッシュボード上で完結します。 Analytics 画面ではエンジン温度、エンジン回転数、油圧、燃料残量などの時系列チャートをリアルタイムに描画します。 デモ全体のアーキテクチャは、実機・エッジ・クラウドの 3 層で構成されています。実機側には ESP32 を搭載した掘削機の模型と、NVIDIA Jetson Orin Nano とカメラを組み合わせたエッジ推論環境があり、クラウド側では AWS IoT Core 、 AWS IoT SiteWise 、 AWS Lambda 、 Amazon DynamoDB を中心としたデータ基盤の上に、 Amazon Bedrock AgentCore と Strands Agents によるエージェント層を構築しています。詳細は後述します。 設計の考え方 デモの各機能を紹介する前に、設計にあたって重視した 2 つの考え方を説明します。なお、本デモの考え方は AWS Summit Japan 2026 のセッション「情報を集め、判断し、行動する時代へ:データ基盤・AI エージェント・エッジ AI で変わる製造現場」(IND327) でも解説しています。セッション資料は こちら からダウンロード可能です。 データにコンテキストを付与する センサーから届く生データは、センサー ID、タイムスタンプ、値、単位といった情報しか持ちません。「75.3 ℃」という値だけでは、それがどの現場の、どの機体の、どの部品の温度なのかが分からず、AI はもちろん人にも意味のある判断ができません。どの機体か、どの部位か、どの機種かといったコンテキストをデータに付与 (エンリッチ) して初めて、その値を「この機種の冷却系としては高すぎる」と解釈できるようになります。データの質と流れが AI の判断力を決める、というのが本デモの土台にある考え方です。本デモでは AWS IoT SiteWise のアセットモデルで機体・部位と計測値の関係を構造化し、エージェントが参照するテレメトリに機体のコンテキストが伴う状態を作っています。 人間と AI の役割分担を設計する AI を組み込んだシステムには、ルールベースの自動化、AI による支援、ゴール駆動型エージェントとの協働、完全自律型のエージェントというように、自律性の異なる段階があります。どの段階を採用するかは、対象業務のリスクと複雑性に応じて設計するものであり、既存のプロセスを単に AI に置き換えれば良いわけではありません。本デモの 3 種類のアラート(人手・古典的 ML・エージェント)は、後半に向けて自立度が高くなります。またデモ全体を通して、異常の検知や分析に必要な情報収集はエージェントが担い、機械を止めるか、現場に作業員を派遣するかといった判断は人間が行う、という役割分担で設計しています。 予知保全の 3 つのアプローチ 本デモの中心は、同じフリートに対する 3 つの異常検知アプローチの比較です。 人手による報告(Alerts – Human Driven) 最も基本的な形態として、現場の作業者が観察した異常を手動で報告するフォームを用意しました。機械、深刻度、タイトル、詳細を入力して起票します。人の観察は「油圧ポンプから変な音がする」といった、センサーには現れにくい定性的な情報を含む点で価値がありますが、報告のタイミングと粒度が人に依存し、状態を定量的に捉えて比較・追跡することができません。フリートが大きくなるとスケールしないという限界もあります。 古典的な機械学習(Alerts – Classical PM) 次の段階として、Amazon SageMaker AI 上に構築した古典的な機械学習パイプラインによる異常検知を実装しました。このパイプラインは、正常運転時のテレメトリから学習したモデルで各機体を継続的にスコアリングし、平常時からの逸脱が大きいときにアラートを発報します。デモの画面では、フリート 20 台それぞれの異常スコアと、予測値と実測値の乖離をチャートで確認できます。異常が進行している機体では、エンジン温度の実測値がモデルの予測レンジから外れていく様子が見て取れます。このアプローチはスケールし、人の観察より早く統計的な逸脱を捉えられます。一方で、アラートに含まれるのは異常スコアという数値だけで、原因や対処までは示されません。異常が起きていることは検知できても、なぜ起きているのかは説明できない。この点が古典的な機械学習による予知保全の限界であり、次のエージェント型アプローチが価値を発揮するところです。 エージェント型予知保全(Alerts – Agentic PM) エージェント型の予知保全では、Amazon Bedrock AgentCore と Strands Agents で構築した AI エージェントがテレメトリを監視し、異常を検知した際に原因分析と推奨アクションを含むアラートを生成します。たとえばデモでは「エンジン温度 95.2 ℃ と油圧低下 48.5 PSI の組み合わせはエンジン故障が差し迫っているリスクを示している。ただちに掘削機を停止し、点検を実施すること」といった、複数のテレメトリを組み合わせた解釈と具体的な対処指示を含むアラートが発報されます。単一メトリクスの閾値超過ではなく、エンジン温度と油圧の同時異常からオイルシステムの問題を推定するといった、保全担当者が行う推論に近い分析が行われる点が古典的 ML との違いです。アラートを受け取った担当者は、原因の調査から始めるのではなく、提示された分析と対処の妥当性を確認するところから対応を始められます。 もうひとつの特徴は、アラートルールの管理を自然言語で行える点です。「エンジン温度が 90 ℃ を超えたら警告して」「燃料レベルのアラートを無効化して」といった指示を入力すると、エージェントが予知保全モニターの使用するルールを更新します。閾値の調整のたびに設定画面を操作したりコードを変更したりする必要がなく、運用者の意図を直接ルールに反映できます。アラートの感度調整は運用を続けながら繰り返し行う作業であるため、この調整を運用者自身で完結できることは運用負荷の軽減につながります。 検知から対処までをエージェントで支援 異常の検知は保全業務の入口にすぎません。本デモでは、検知の後工程である診断、起票、通知、対話までをエージェントで支援する構成としました。 チケットの起票と AI 分析 アラートが発報された後のチケット起票は、人間が行います。担当者はアラート画面からエージェントに原因と対応策の分析を指示します。アラートはアラート画面で管理しますが、メールや SMS で通知することも可能です。人間から指示を受けた後、エージェントはマニュアルやテレメトリデータを自動で収集し、原因の特定と現場作業員向けの作業指示を作成します。チケットサービスはデモ内に MCP 経由で接続されており、担当者は分析結果を確認したうえで、アラート画面からそのままチケットを起票できます。起票されたチケットには、エージェントの分析結果が日本語で付与されます。たとえば「掘削機 001 はエンジン冷却水温度が 94.7 度と高く、C62 および C65 のオーバーヒート関連の故障診断コードが検知されています」といったように、テレメトリの値と診断コードを突き合わせた診断が記載されます。 異常の検知と、分析に必要な情報の収集はエージェントが行い、現場に作業員を派遣するかどうかの判断とチケット起票は人間が行う — このように分担することで、複雑な現場保全を効率的に進められます。分析にあたってエージェントは、後述する Knowledge Base を検索し、機器マニュアルや診断コードの定義を参照します。テレメトリ (定量データ) と技術文書 (定性情報) を組み合わせて、状況を総合的に判断させています。チケットには深刻度とステータスが付与され、Ticketing 画面で一覧・検索できます。診断コードの意味をマニュアルで調べるという一次診断と、機体名やテレメトリ値の転記が不要になるため、担当者の作業は分析内容の確認と派遣の判断に絞られます。また分析結果が日本語で記載されるため、現場の担当者がそのまま読んで対応に移れます。 Knowledge Base による技術文書の検索 Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless で、機器マニュアル、診断コード一覧、保守手順書を検索できるナレッジベースを構築しました。「掘削機のオーバーヒートに関する診断コードは何か」「油圧ポンプの交換手順は」「緊急停止の手順は」といった質問に、文書に基づいた回答を返します。このナレッジベースは、チケット起票時の AI 分析と、次に述べる音声通知の両方から参照されます。 Amazon Connect による音声通知 検知と診断の結果を現場のオペレーターに届ける手段として、 Amazon Connect による架電機能を実装しています。エラーコードを指定すると、エージェントが Knowledge Base からトラブルシューティング手順を検索し、その要約を Text-to-Speech で読み上げる電話をオペレーターにかけます。同じ内容はメールでも送付されます。ダッシュボードを見ていない現場の担当者にも、異常の内容と初動手順が音声で届くという体験です。 双方向の音声対話 通知にとどまらず、AI エージェントとオペレーターがリアルタイムに双方向で会話する音声対話も実装しています。エージェントは対象機体のライブテレメトリと診断結果のコンテキストを保持した状態で通話するため、オペレーターからの質問に答え、トラブルシューティングを対話的にガイドし、必要に応じてエスカレーションできます。一方向の読み上げと異なり、手順の途中で生じた疑問にその場で答えられるため、担当者への折り返し確認を減らせます。音声対話の基盤には Amazon Nova Sonic を利用しています。 AI Assistant これらの機能とは別に、フリート全体を対象としたチャット形式の AI Assistant も用意しています。Strands Agents によるマルチエージェント構成で、「フリートの状態は?」「掘削機-001 を診断して」「掘削機-003 のテレメトリを読んで」といった問い合わせに対し、フリート状態の照会、機体診断、ドキュメント検索を担当するエージェントが連携して回答します。現場の作業員はタブレットやスマートフォンからこのアシスタントを利用でき、展示ではエンジン温度が異常に高い機体への対応方法を質問する流れを紹介しました。診断コードやマニュアルの知識を持つ熟練者でなくても、その場で対応方法を引き出せることがこの機能の狙いです。 エッジと実機 クラウド側の機能に加えて、実機とエッジ推論を組み合わせた構成も実装しています。なお、今回の展示ではこの部分のデモフローは割愛しました。以下では、実装した構成を紹介します。掘削機の模型には ESP32 を搭載し、モーター、センサー、LED を MQTT で AWS IoT Core に接続しています。掘削機制御画面からは走行、キャビン旋回、アームの上下、非常停止(E-STOP)を遠隔操作でき、掘削機の状態は Unreal Engine で構築した 3D デジタルツインに反映されます。エッジ推論としては、NVIDIA Jetson Orin Nano 上で YOLO による物体検出と VLM(Vision Language Model)を組み合わせ、映像から安全に関わる状況をエッジ側で判定する構成を実装しました。また、 Amazon Kinesis Video Streams 03:06 PM と WebRTC による低遅延のライブ映像配信の上で、Amazon Bedrock による映像分析を行う構成も実装しています。「機材の近くに人が近づいたら通知して」のように監視条件を自然言語で定義でき、条件に合致するイベントが検出されると指定の方法で通知されます。この構成では、人の接近検知のような安全に関わる即時判断を Jetson 上のエッジ推論が担い、フリート全体の分析や診断をクラウド側のエージェントが担う分担を想定しています。 アーキテクチャ詳細 最後に、デモ全体のアーキテクチャを整理します。 データ基盤の層では、掘削機のアセット情報を AWS IoT SiteWise で管理し、実機からのテレメトリは MQTT で AWS IoT Core に取り込み、機体状態を Amazon DynamoDB に保持します。アラート、チケット、チャット履歴もそれぞれ DynamoDB のテーブルで管理し、生成・更新の処理は AWS Lambda と AWS Step Functions で実装しています。 エージェント層は Strands Agents で実装しています。アシスタント、シナリオ、ナレッジベース検索、チャット履歴といったエージェントは AWS Lambda(コンテナ)上で稼働し、音声対話エージェントは Amazon Bedrock AgentCore 上で稼働させています。エージェントから AWS IoT SiteWise などの OT/IT システムへのアクセスは MCP(Model Context Protocol) サーバーを介して行い、エージェントは目標に応じて必要なツールを自律的に選択・実行します。AgentCore はランタイム管理、認証、メモリ、可観測性といった、エージェントを本番運用するための基盤機能を提供します。ナレッジベースは Amazon Bedrock Knowledge Bases と Amazon OpenSearch Service で構成し、音声対話には Amazon Nova Sonic を利用しています。音声通知は Amazon Connect、メール等の通知は Amazon SNS が担います。 フロントエンドは Amazon CloudFront と AWS WAF を通じて配信し、認証には Amazon Cognito を利用しています。リアルタイム性が求められるテレメトリ配信には Amazon API Gateway の WebSocket API を、その他の操作には REST API を使い分けています。映像系は Amazon Kinesis Video Streams、地図表示は Amazon Location Service です。 まとめ 「産業機械の自律診断とリアルタイム安全監視」デモでは、建機フリートの予知保全を題材に、人手による報告、古典的な機械学習、生成 AI エージェントという 3 つのアラート発火のアプローチを比較できる形で実装しました。古典的な機械学習が「異常の検知」を担い、エージェントが「原因の分析と対処の提示」、さらに「起票・通知・対話」までを担うという役割分担は、製造業や建設業における保全業務の実務に近い形で生成 AI を組み込む際のひとつの参考になると考えています。さらに、検知後に人が担っていた調査・起票・連絡といった作業をエージェントに任せることで、担当者は判断と実際の対処に集中できるようになります。 本記事で紹介した構成の多くは、標準的な AWS サービスの組み合わせで実現しています。自社の設備データへの適用をご検討の際は、ぜひ AWS の担当ソリューションアーキテクトにご相談ください。 著者 新澤 雅治(Niizawa Masaharu) — IoT Specialist Solutions Architect。製造業、IT 企業を経て AWS に入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様の Industrial IoT 関連案件の支援に携わる。 深澤 真愛(Fukasawa Mana) — Solutions Architect。入社以来、製造業を中心に、様々な業界のお客様の AI 活用やデータ活用の技術的支援に携わる。