IoTの活用が広がる中で、本格的にビジネス活用に取り組む企業が増えています。 しかし、いざ構築・運用を始めると、遠隔デバイスの管理やセキュリティ確保に課題を感じるケースも多いのではないでしょうか。本記事では、NTTドコモビジネスが提供するIoT向けネットワークプラットフォーム「docomo business SIGN™」の機能の中から、運用に役立つ「デバイスアクセス」と「フローコレクター」を実際に試した様子をご紹介します。 はじめに docomo business SIGN™とは docomo business SIGN™におけるデバイスアクセスとフローコレクター デバイスアクセス フローコレクター デバイスアクセスを試してみる 手順 結果 フローコレクターを試してみる 手順 結果 まとめ はじめに はじめまして、NTTドコモビジネス IoT&フィジカルAIサービス部の篠沢と申します。普段は「docomo business SIGN™」の販売推進を担当しております。 今回はdocomo business SIGN™の機能のうち、「デバイスアクセス」と「フローコレクター」を実際に試してみました。その様子を画面も交えながら分かりやすくご紹介します。 docomo business SIGN™とは まずdocomo business SIGN™について簡単にご紹介します。 セキュリティ機能を標準搭載したIoT向けのNaaS(Network as a Service)である「docomo business SIGN™」は、IoT環境を安全かつスムーズに構築・運用できるネットワークプラットフォームサービスです。ドコモの高品質なネットワークと連携し、デバイスの認証、通信の暗号化、リモート管理などをまとめて提供します。 開発者にとっては、煩雑になりがちなネットワークインフラの設計・構築から解放される点が大きなメリットです。その分アプリケーションの開発やデータの利活用といった本来注力すべき領域に集中できます。 docomo business SIGN™におけるデバイスアクセスとフローコレクター 「デバイスアクセス」と「フローコレクター」は、docomo business SIGN™の中でも特に運用効率化の観点で重要な役割を担っている機能です。今回はこの2つの機能を実際に試してみました。 デバイスアクセス 「デバイスアクセス」は、遠隔地にあるIoTデバイスに対して、オフィスや自宅などのリモート環境からセキュアに接続できる機能です。 IoTシステムでは、現場に多数のデバイスが分散して設置されるケースも多く、トラブルシュートや設定変更のたびに現地対応するのは非効率です。そのため、リモートからデバイスにアクセスできる仕組みは、実運用において不可欠といえます。 ただし、リモート接続の仕組みは便利である一方、セキュリティ面の配慮が欠かせません。 「デバイスアクセス」では、アクセス権限や利用期間を制御できるため、運用効率とセキュリティを両立したデバイス管理を実現できます。 フローコレクター 「フローコレクター」は、docomo business SIGN™内の「脅威検知システム」にて、ネットワーク上を流れる通信データのうち宛先IPアドレスやポート番号などの基本情報をリアルタイムに収集・蓄積する機能です。どのデバイスが、いつ、どこへ、どの程度の通信をしたかを可視化できます。 これにより、異常な通信パターンの早期検知はもちろん、障害発生時にも「どこまで通信できているか」を基点に、問題箇所の切り分けを効率的に進めることが可能になります。 デバイスアクセスを試してみる まずは「デバイスアクセス」機能を試してみます。今回は、自宅の手元のPCから会社に設置された検証用IoTゲートウェイへアクセスすることをゴールとします。 手順 docomo business SIGNコンソールへのログインと対象SIMの選択 SIGNコンソールから、アクセスしたい対象のデバイスに挿してあるSIMを選択します。 デバイスアクセス機能の有効化 セキュリティ確保のために接続元IPアドレスやデバイスアクセス可能な期間、アクセスするポート番号（今回はIoTゲートウェイへSSH接続するためのTCP/22番）を設定し、デバイスアクセス機能を有効化します。 接続用情報の払い出し 設定が完了すると、SIGNコンソールからデバイスにアクセスするための接続情報(URLとポート番号)が発行されます。 結果 発行された接続情報を使い、自宅のPCから接続してみました。 無事にIoTゲートウェイにSSH接続し、ゲートウェイのログを確認できました。要した作業としてはSIGNコンソールで数クリックの設定をしただけです。 これだけで、アクセス元や期間を区切ったセキュアな形で遠くにあるデバイスへとアクセスし、ログの確認や設定変更などの保守作業を行うことができます。 レスポンスもインターネット上のWebサーバーに接続する際と大きな差はなく、快適に操作できました。 フローコレクターを試してみる 次に「フローコレクター」を試してみます。 手順 今回は、契約時の設定でフローコレクターを有効化済みのSIMを使用します。設定さえしておけば、docomo business SIGNコンソールからいつでもフローを確認できます。 SIGNコンソールからフローを確認する対象のSIMと期間を選択します。 結果 検索すると、すぐに次のような表が表示されました。 画面には、指定したSIMのトラフィック一覧が表示されました。 一覧では、このSIMのフロー観測時刻、送信元／宛先アドレス、送信元／宛先ポート、プロトコル、上り・下りの通信量を確認できました。これにより、たとえば「SIMから外部宛ての通信は発生しているか」「想定外の宛先に通信していないか」「特定ポートの通信が継続しているか」といった観点で、一次切り分けに使える強力な情報源だと感じました。 まとめ 今回は docomo business SIGN™の「デバイスアクセス」と「フローコレクター」を実際に試してみました。 遠隔地のIoTデバイスへセキュアにアクセスしたり、通信データを可視化したりする仕組みを自前で構築しようとすると、踏み台サーバーの用意やファイアウォールの設定、コレクターサーバーの構築など、どうしても多くのインフラ作業がかかります。こうした準備には手間と時間がかかり、運用負荷の増加にもつながります。 しかし、 docomo business SIGN™を利用することで、これらの環境を数クリックで立ち上げることができ、スムーズに機能を利用開始できました。 本記事でご紹介しきれなかった機能も多数提供しています。興味を持っていただけた方は、ぜひサービス紹介サイトをご覧ください。 docomo business SIGN™についてはこちら

このブログは、東海旅客鉄道株式会社（以下、JR 東海）中央新幹線推進本部 リニア開発部 藤原 海渡氏と、アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションマネージャー 西部 信博、プロフェッショナルサービス本部 正村 雄介、森田 和真による共著です。 1. はじめに JR 東海では、中央新幹線の保守・運用として、山梨リニア線において超電導リニアの電気設備保守の省力化・高度化を進めています。本活動の一環として、状態監視保全（Condition Based Maintenance、以下 CBM）の実現を目的に、AWS 上に IoT プラットフォームを段階的に構築してきました。機械学習の運用（MLOps）も IoT と切り離さず、この IoT プラットフォームの中に統合する方針としています。変電所・開閉所・トンネル区間など設置環境が多様な拠点に、エッジコンピュータやセンサデバイスといった種類の異なる IoT 機器が分散して設置される中で、構成情報を継続的に把握し遠隔から運用していくことが、保守業務の品質を左右する重要なテーマになっています。 本記事では、IoT プラットフォームの概要と構築にあたっての工夫点や得られた知見についてご紹介します。 2. 全体像 2-1. 本システムで実現したいこと（論理アーキテクチャ） IoT プラットフォームで実現したいのは、現地に出向かなくても設備の状態をデータで捉え続けることです。具体的には、次の能力を備えることを目指しました。 機器のメーター情報をデジタル化して取り込み 動作音や電流値をもとにした設備状態の数値化 メーター情報や各種計測情報を統合した状態把握 2-2. 構築した AWS アーキテクチャ（物理アーキテクチャ） 電気設備保守における IoT プラットフォームでは、多様な拠点に設置された IoT デバイスから設備のデータを取得し、エッジで処理した結果と必要なデータのみをクラウドに連携する構成としています。 エッジとクラウドにまたがる IoT システムでは、現場での即時処理とクラウドでの一元管理を両立させる構成が鍵になります。本アーキテクチャでは、 AWS IoT Greengrass がエッジ側の処理ランタイムとして現場固有の推論・前処理を担い、 AWS IoT Core がそのエッジとクラウドをつなぐ通信のハブとなります。クラウド側では AWS IoT SiteWise が設備データをモデル化して時系列で管理し、 Amazon SageMaker AI がエッジ推論向けの異常検知モデルの学習を担います。これらのマネージドサービスを組み合わせることで、通信・運用基盤そのものの開発を最小化し、設備保守の本質的な作り込みに集中できる構成になっています。 この IoT プラットフォームの設計思想は、「処理はできる限りエッジに寄せ、設備も機器も同じ階層モデルで構造化し、その構成を一元的に運用し続ける」 という点に集約されます。以降の 3 つの工夫は、いずれもこの思想を具体化したものです。 3. 工夫①：エッジ処理を中心とした状態監視システムの構築 実装に落とすうえで、まず向き合ったのがデータ取得と通信の制約です。電気設備の状態を正しく捉えるには高いサンプリングデータ・カメラ画像・動作音などが必要ですが、これらをそのままクラウドへ転送すると、通信回線の制約・通信コスト・クラウド側の処理負荷のいずれもが課題となります。 通信量の最適化（3-1）とエッジでの機械学習推論（3-2）という 2 つのアプローチで、この課題に取り組みました。 3-1. エッジ処理と通信量の最適化 Greengrass のコンポーネントとして、カメラ画像からのメーター値読み取り、動作音の特徴量抽出、機械学習モデルによる異常推論などを実装し、クラウドには集計値・推論結果と必要最小限の分析用データだけを送る構成としています。 また、標準コンポーネントに加え、現場固有の処理（カメラ機種ごとの画像切り出しやノイズ除去など）をプライベートコンポーネントとして実装することで、デバイスや設置環境ごとに柔軟な処理を実現しました。 3-2. 機械学習モデルの構築とエッジへのデプロイ 状態監視の中核は、設備の異常検知モデルをエッジ上で推論実行することです。モデルを Amazon SageMaker AI で学習・構築し、オープンソースの ONNX （Open Neural Network Exchange）形式へ変換したうえで、 Greengrass コンポーネントとしてエッジにデプロイしています。これによりモデルを軽量化し、計算資源の限られたエッジコンピュータ上でも無理なく推論を実行できる構成を実現しました。 4. 工夫②：多様な拠点・設備・機器のモデル化 中央新幹線では、監視対象となる拠点・設備が多様であり、それを監視するエッジ構成（IoT 機器やネットワーク）もまた多様になります。そこで 、これらの多様な設備や機器群を共通の構造（モデル）に落とし込み、保守員が一貫した方法で管理できるようにすることを目指しました。 4-1. 拠点・設備のモデル化 拠点・設備は、 AWS IoT SiteWise の Asset Model を活用し、「エリア」→「拠点」→「設備」という階層構造でモデル化しています。これにより、保守員は監視ダッシュボード上で拠点や設備種別を横断して状態を俯瞰したり、特定の設備にドリルダウンしたりといった操作を、共通の枠組みで行えるようになりました。 4-2. エッジ構成のモデル化 エッジ構成は、ネットワーク機器・コンピュータ・センサといった種別に分類したうえで、各機器のハードウェア構成（CPU・メモリや、NIC・USB などの外部接続インターフェース）を共通の属性としてモデル化しています。ネットワーク構成についても、NIC や USB を介した機器間の接続関係としてモデル化し、物理配置は階層的な属性（エリア／拠点／ゾーン／フロア／詳細位置）として表現しています。 5. 工夫③：IoT 機器と機械学習モデルの一元管理・自動運用 拠点とデバイスの数が増えるにつれ、運用上の最大の課題となったのが、モデル化した構成を実体に合わせて正確に把握し続けることです。 以下のようなオペレーションを行うには、正確な構成情報が不可欠です。 ソフトウェアの一括更新 機器のリプレース IP アドレス管理 新規拠点の構築 こうした情報を台帳と現場の作業記録に頼って管理すると、機器が増えるほど負担も増し、台帳と実機の乖離も広がっていきます。そこで 、これらの構成情報を一元管理する仕組みを新たに構築しました。 5-1. 構成情報の自動収集と一元管理 IoT 機器の構成を、実値で最新化し続ける仕組みとして IoT 構成管理システムを構築しました。エッジの構成情報を自動で集約し、機器の物理配置情報も紐付けることで、一元管理を実現しました。 IoT 構成管理システムのアーキテクチャ IoT 構成管理システムは Web アプリケーションとして実装しました。バックエンドは AWS AppSync による GraphQL API と Amazon DynamoDB で構成し、フロントエンドは Next.js で実装して AWS Amplify Hosting でホスティングしています。サーバーレスのマネージドサービスと、Next.js をはじめとする既成のフレームワーク・コンポーネントを最大限に活用したことで、少ない実装コストで素早く立ち上げられました。インフラの運用負荷を抑えられる点も、少人数での継続運用に寄与しています。 エッジ構成の自動収集 構成管理で主となる課題は、機器の構成を実体に合わせて常に同期し続けることです。OS バージョン、 Greengrass の外で動くネイティブアプリケーション、ネットワーク情報まで含めてエッジの構成全体を収集対象としたのが特徴です。これらを集める「構成情報収集機能」を Greengrass コンポーネントとして実装し、 AWS IoT Core 経由でクラウドへ送信して構成管理データベースを定期的に最新化することで、エッジの構成を一元的に把握できるようにしました。これにより、保守員は台帳と実機の乖離を心配することなく運用できます。 5-2. 機械学習モデルのビルド自動化と運用効率化 電気設備の異常検知では、設置環境によってデータの特性が異なるため、設備ごとに特化したモデルの方が精度を得やすい一方、運用面では多数のモデルのライフサイクル管理が新たな課題となります。 そこで 、 Amazon SageMaker Pipelines による学習パイプラインと、 AWS Step Functions による Greengrass コンポーネントへのビルドパイプラインを組み合わせ、学習から配信までの各作業を自動化しています。学習 – ONNX 化 – コンポーネント化 – 配信までを一連の流れとしてスムーズに回せるようにしました。 また、学習済みモデル自体を Greengrass コンポーネントとして扱うことで、IoT 機器のソフトウェア構成管理の枠組みにそのまま乗せられるようにし、IoT と機械学習を別管理にしない運用を実現しています。 6. Professional Services との伴走による内製化の推進 本取り組みは、リニア開発部と AWS Professional Services が伴走する形で進めてきました。週次のスプリントで要件整理・設計・プロト開発・QA を協働で行うことで、リニア開発部のメンバーが IoT・機械学習・Web アプリケーションそれぞれの実装ノウハウを段階的に獲得することができ、開発スピードと内製化の両立につながっています。 リニア開発部自身が運用と改善を主導できる体制を作るうえで、伴走型の開発スタイルは非常に有効でした。 7. まとめ JR 東海では、中央新幹線の将来運用を見据えた電気設備保守の高度化に向け、IoT プラットフォームを段階的に構築・拡充してきました。この取り組みは、次の 3 つの柱に支えられています。 エッジ処理を中心とした状態監視システムの構築（通信量最適化＋エッジでの機械学習推論） 多様な拠点・設備・機器のモデル化（設備データ＋機器／ネットワーク／接続関係） IoT 機器と機械学習モデルの一元管理・自動運用（構成管理＋MLOps） 今後は、将来の営業線運用に向けて、生成 AI を活用した開発・運用ナレッジの継承支援機能追加を検討しています。IoT と機械学習を横断する高度な専門知識を組織に定着させ、現場作業や障害対応の場面で必要なナレッジに素早くアクセスできる環境を整えることを目指しています。 おわりに 本ブログでご紹介した JR 東海の取り組みや関連する AWS サービスに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。 著者について 東海旅客鉄道株式会社 藤原 海渡 (Kaito Fujiwara) 中央新幹線推進本部 リニア開発部 在来線の電気設備保守、リニア電気設備の運用・保守・開発、営業線システムの検討を経て、現在は AWS を活用した IoT プラットフォームと MLOps の推進を担当しています。 アマゾン ウェブ サービス ジャパン合同会社 西部 信博 (Nobuhiro Nishibe) カスタマーソリューションマネージャー カスタマーソリューションマネージャーとして、エンタープライズのお客様を中心に、技術・非技術問わずクラウドジャーニーにおける課題の特定から解決までをご支援しています。好きな AWS サービスは Kiro と AWS IoT シリーズです。 正村 雄介 (Yusuke Shomura) プロフェッショナルサービス本部 IoT コンサルタントとして、製造業や鉄道事業者のお客様を中心に、IoT・生成 AI を活用したシステムの構築をご支援しています。通信分野の研究者を経て AWS に入社しました（工学博士）。好きな AWS サービスは AWS IoT Core と Amazon Bedrock です。趣味は読書とコーヒーです。 森田 和真 (Kazuma Morita) プロフェッショナルサービス本部 アソシエイトデリバリコンサルタントとして、金融や鉄道事業者のお客様をはじめとして、クラウド基盤・生成 AI 基盤に関連したご支援を中心に行っています。好きな AWS サービスは Kiro と Amazon Bedrock AgentCore です。

こんにちは！製造業のお客様を中心に技術支援をしているソリューションアーキテクトの伊藤ジャッジです。だんだん梅雨らしい気候になってきましたね。この時期といえば今年も  AWS Summit Japan 2026  です！今年も IoT の展示の出展はもりだくさんで、 こちら のブログに概要を掲載しています。ぜひ遊びに来てください。このブログでは IoT 展示内の ロボットの遠隔テレオペレーションの ブースの展示について紹介します。 背景 2026 年のものづくり白書 には、政府主導の AI ロボティクス戦略がその中にありました。AI で賢くなったロボットが、これまで自動化が難しかった市場を広げる「フィジカル AI 時代」を見据えた戦略の発表となりました。政府主導のロボティクス推進方針が明確になったことはロボットを製造する側にも使う側にも喜ばしいことですが、一方で、AI の学習に必要なデータがなければ、どんなに性能の良いロボットでも、AI を使って期待した動作をしてもらうことができません。また、学習には高品質なデータが必要となります。幸いなことに日本の産業ロボットの製造業における活用は世界でも最高水準です。そのため、産業ロボットの動作データは潤沢に存在します。政府も日本の強みとして、産業用ロボット、部品・素材、高品質な現場データを土台に、「まず社会実装してデータを取り、モデルを改善し、他分野へ横展開」という循環を確立することを勝ち筋として、上述のものづくり白書で提案しています。 データが必要ということは理解できますが、このデータ収集において大きな壁があります。実は、ロボット開発では、センサー・モーター・カメラなど多数のハードウェアを組み合わせる必要があります。しかし今までは、ロボットメーカーごとにインターフェースが異なり、各社それぞれのロボット制御言語を使用してきました。そのため、ロボットを新規導入する際は、あるロボット向けに書いたソフトを別機種に移植することはできず、一から動作、通信制御、またはデータ連携を作り込むことになり、膨大な開発コストがかかっていました。この状態は各種ロボットが連携する将来を見据えたロボットの動作データの収集という観点では、障壁と言えるでしょう。 このサイロ化したロボット開発環境の問題を解決するため、ROS が登場しました。ROS（Robot Operating System）は、上記の課題を解決するオープンソースの共通フレームワークです。標準化された通信の仕組みとツール群を提供し、開発者はハードウェアの違いを意識せずにロボットの機能開発に集中できます。さらに、ROS2 の登場をきっかけに近年では産業用ロボットメーカーも ROS2 のサポートを発表する機会が増えてきました。 デモの内容 デモのタイトルにある「遠隔テレオペレーション」（テレオペ）とは、離れた場所にあるロボットや機械を、人間がリアルタイムに操作する技術です。オペレーターは手元のコントローラーやモニター映像を通じて現場の状況を把握し、ロボットに動作指示を送ります。ロボット側のカメラやセンサーの情報がネットワーク経由でオペレーターに返されることで、あたかも現場にいるかのように作業できます。この技術により危険な環境（災害現場、高所、有害物質のある場所）や、人がすぐに行けない遠隔地での作業を安全に行えています。 このテレオペのデモでは AWS の IoT サービスを利用し、 Web の UI を見ながらゲームコントローラーを操作することで、クラウド経由でロボットを操作します。 このデモで利用している実機のロボットは、世界中の生産現場でも利用されているセイコーエプソン株式会社製の高速・高精度な垂直多関節（6軸）ロボット( CX4-A601S )を利用しています。セイコーエプソン株式会社では自社のロボットに対応した ROS2 パッケージ を公開しており、デモでは ROS2 経由で操作しています。 このデモでは同時にデジタルツインとしての Amazon EC2 上で実行されている NVIDIA Isaac SIM にも情報が送られるため、カメラの映像だけではなく、シミュレーション環境上でもロボットの動作を確認することができます。 セイコーエプソン株式会社の ROS2 パッケージ では実機を利用せず、Rviz (3D 可視化ツール)で動かすモードも用意されているため、シミュレーション環境の中だけで動かすこともできます。それゆえ、ロボットの操作に不慣れな人でも安心して操作することが可能です。 このデモでは操作時のデータを rosbag 形式 (ROS2 上でやり取りされるメッセージを記録し、後で利用できる) に保存することも可能で、作成された rosbag は記録後にクラウドに保存されます。このデータを使うことで、クラウド上のシミュレーション環境で、同じ様に再現することもできます。また、保存された操作データは、Physical AI で利用される VLA（Vision-Language-Action）モデルの模倣学習データとして活用することができます。 今回のデモの全体の構成は下記となっています。 ぜひ、 6 月 25 日、26 日に幕張メッセで開催される AWS Summit に来場いただき、実際にご自身の手でコントローラーを操作 し、Physical AI の時代に必須となるロボット動作データ生成と収集を体験しに来てください！ デモは AWS Expo の AWS for Industries Zone に展示しています。 伊藤ジャッジ向子 (Ito, Judge Sakiko) 米国での開発者経験を経て、AWSのサポートに入社し、異動しエンタープライズ事業本部でソリューションアーキテクトとして製造業のお客様をご支援しています。趣味は山登り、クラッシックバレエと愛犬のお世話です。 Muhammad Fikko Fadjrimiratno（ふぃっこ） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 不動産・建設業界のお客様を中心に、AWS 利用をご支援しているソリューションアーキテクトです。好きな領域はロボットとIoTと機械学習であり、最近はロボット分野での生成AIの活用にチャレンジしています。趣味はフライトシミュレーター、冬はスノーボードです。 市川 純 プロトタイピングソリューションアーキテクト AWS では IoT に関連するプロトタイピングを支援する、ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。