本ブログは dSPACE Japan 様と アマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 1. はじめに 自動車分野で行われている自動運転技術の開発では、データ駆動型アプローチの重要度が高まっています。膨大な実走行データを体系的に整備・活用することで多様な運転環境への対応が可能になり、モデルの汎化性能と信頼性を継続的に向上させることができます。 しかし、自動運転システムが生成するデータ量は膨大であり、その管理と活用には大きな課題が伴います。データ収集から学習、検証、デプロイ、モニタリングまでを統合管理する「MLOps」の導入が不可欠です。 本記事では、30 年以上にわたり車両開発ツールを提供してきた dSPACE 社の製品と、AWS クラウドサービスを統合した MLOps ソリューションをご紹介します。 2. 自動運転開発における課題 自動運転技術の進展に伴い、AI を活用した認識・判断アルゴリズムの高度化が急速に進んでいます。一方で、実際の車両開発・量産適用を見据えると、単なるモデル精度の向上だけでは解決できない、複合的な課題に直面されているのではないでしょうか。 膨大かつ多様なセンサーデータの管理と活用 先進的な自動運転システムでは、1 時間あたり 1 テラバイトを超えるカメラデータに加え、LiDAR、Radar、GPS など多種多様なセンサーデータが生成されます。これらのデータは地理的にも分散して収集されることが多く、効率的な保存・検索、シナリオや条件に基づくデータ抽出、開発・検証フェーズ間での一貫したデータ利用を実現することが大きな課題となっています。 学習精度と車両環境での挙動の乖離 クラウド環境で学習した AI モデルが高い認識精度を示していても、リアルタイム実行制約、センサー同期誤差やノイズ、車載ハードウェア上での実行条件といった要因により、実車両環境では期待通りに動作しないケースが少なくありません。このため、学習結果をそのまま車両に適用するのではなく、車両環境を考慮した検証・評価プロセスを MLOps と連携させることが不可欠となります。 検証と学習の分断による改善サイクルの停滞 自動運転の安全性は、まれなエッジケースや特定シナリオへの対応によって大きく左右されます。しかし多くの開発現場では、クラウドを中心とした AI 開発・MLOps チームと、SIL (Software-in-the-Loop)／HIL (Hardware-in-the-Loop)／実車評価を担う車両開発チームが、異なるツールやプロセスで作業しています。この分断により、どのシナリオで性能低下が発生したのか、その原因となるデータをどのように再学習へ反映させるのかといった情報がチーム間で共有されず、検証結果を効率的に再学習へフィードバックする仕組みが整っていないケースが多く見られます。検証結果と学習データを結び付け、継続的な改善サイクルを回すことが大きな課題です。 再現性・説明責任の確保と検証コストの増大 自動運転 AI の開発では、使用したデータ、学習条件、モデル構成、検証環境を後から正確に説明・再現できることが求められます。しかし、実験管理、検証条件、車両構成情報が個別に管理されることで、結果の再現性やトレーサビリティの確保が困難になり、社内レビューや将来的な認証・法規対応を見据えた際に重大なリスクとなります。さらに、データ駆動型開発ではモデル更新が頻繁に行われるため、そのたびに同等レベルの検証を実施することは大きな負担となります。すべてを再検証するのではなく、モデル変更の影響範囲を見極め、効率的に検証を行う仕組みが必要とされています。 これらの課題を解決するためには、クラウド MLOps のスケーラビリティと、車両開発・検証を熟知したツールチェーンを統合し、データ収集から学習、検証、デプロイ、モニタリングまでを一貫して管理できる基盤が求められます。次章では、こうした課題に対応する dSPACE と AWS による統合 MLOps ソリューションについて詳しく説明します。 3. ソリューション： dSPACE と AWS による自動運転向け統合 MLOps アーキテクチャ 自動運転 AI 開発における効率化を実現するため、dSPACE と AWS はそれぞれの強みを活かし、AI モデルの学習から SIL/HIL での検証、さらに実運用を見据えた評価・改善までをつなぐ統合 MLOps 環境を共同で提供します。本ソリューションでは、データ駆動開発（DDD）で扱うデータ収集・整備・検証の流れ（左側）と、MLOps で扱う学習・追跡・デプロイの流れ（右側）を接続します。これにより、学習と検証が分断されがちな自動運転 AI 開発において、改善サイクルを一貫したパイプラインとして回すことを目指します。 本アーキテクチャの特徴は、dSPACE 製品と AWS サービスがシームレスに連携できる点にあります。 図1: AWS サービスと dSPACE 製品の統合アーキテクチャ Data Collection：後工程で“使える形”を前提にしたデータ収集 本パイプラインの起点は、走行試験、評価ベンチ、シミュレーションなど多様なソースから得られるデータの収集です。自動運転開発ではデータ量の多さだけでなく、どの条件・どのシナリオで取得されたかが重要となるため、後工程での検索・抽出・学習・検証に耐えうる形で蓄積することが求められます。 この Data Collection フェーズでは、 RTMaps を活用することで、カメラ、Radar、LiDAR など複数センサのデータをリアルタイムに扱いながら、システム全体としての振る舞いを意識したデータ取得が可能となります。さらに、RTMaps を用いたデータ収集は、後続の検証や SIL/HIL を含むシステム統合試験でも同一の処理構成を再利用できるため、データ取得と検証の分断を抑えたパイプライン設計につながります。こうして収集されたデータは、次の Data Preparation フェーズにおいて IVS に引き渡され、タグ付けや検索、データセット化といった処理へとスムーズに接続されます。 Data Preparation：IVS によるデータマネジメントとデータセット管理 収集したデータは、学習にそのまま利用できるとは限りません。Data Preparation フェーズでは、 dSPACE IVS (Intempora Validation Suite) を用いて、データの自動タグ付け、検索、変換を行い、学習に適したデータセットとして整理します。 重要なのは、単にデータを整えるだけでなく、どの条件で抽出・加工されたデータセットなのかを後から辿れることです。本パイプラインでは、IVS を介してデータセット定義と証跡（トレーサビリティ）を管理し、以降の学習・検証フェーズと一貫して結び付けます。 Training：AWS を活用した学習の自動化と実験・モデル管理 整備されたデータセットは、AWS のクラウドサービスへシームレスに受け渡され、大規模な学習処理が実行されます。本構成では、 Amazon SageMaker AI を中心とした学習基盤を活用し、必要な計算リソースを柔軟に利用することで、効率的なモデル学習を実現します。 SageMaker Training Jobs は、学習ジョブごとに GPU インスタンスを自動的にプロビジョニングするため、高価な GPU リソースを学習実行時のみ使用でき、コスト効率に優れています。また、学習コードをコンテナイメージとして Amazon ECR に格納し、学習データを Amazon S3 に配置するアーキテクチャにより、「コード・データ・環境」の三要素が分離され、実験の再現性が担保されます。さらに、実験管理には SageMaker AI のマネージド MLflow を用い、学習条件、評価指標、生成されたモデルを一元的に管理します。これにより、モデルの品質担保に必要な履歴情報を体系的に蓄積し、後工程の検証や将来の説明責任に対応します。 Validation / System Integration & Testing（SIL/HIL）：学習成果を車両開発レベルで検証し、信頼性を高める 学習によって得られた AI モデルは、SIL や HIL を活用して、自動運転システムとしての機能検証や統合試験へと進みます。 dSPACE の SIL/HIL ソリューション は、制御ソフトウェアや AI モデルを実車に近い条件で段階的に評価できる点が特長です。SIL では、アルゴリズムやソフトウェアの論理的な正しさや機能挙動を早期に確認でき、モデル更新による影響を効率的に洗い出すことができます。さらに HIL では、実際の ECU (Electronic Control Unit) として AI モデルを接続することで、リアルタイム性やインタフェース、システム全体としての振る舞いを含めた検証が可能となります。 検証フェーズで得られた結果は、データ条件やモデル情報とひも付けて管理され、Data Preparation フェーズへフィードバックされます。これにより、SIL/HIL で顕在化した課題を起点に学習データセットを見直し、再学習へつなげるといった、検証起点の改善サイクルを回すことが可能となります。結果として、モデル開発と車両開発・検証を分断することなく、品質向上と開発効率化の両立を支援します。 4. 開発環境「Kiro」を活用した開発効率化 MLOps 開発プロセスをさらに効率化するためには、AWS が提供する開発環境「 Kiro 」を利用することが考えられます。 Kiro は Spec 駆動開発を特徴とし、要件定義・設計・実装タスクを構造化されたドキュメントとして管理しながら、エージェント機能によるコード生成を行うことで、開発者が本質的なアルゴリズム設計に集中できる環境を提供します (図 2 参照)。 図 2: Kiro による MLOps 開発ワークフローの効率化 ここでは、MLOps 開発において Kiro がどのように活用できるか、いくつかの例をご紹介します。 ハイパーパラメータ最適化スクリプトの生成 エージェント機能に最適化要件を伝えることで、2 フェーズアプローチの最適化スクリプトを生成できます。Phase 1 (粗探索) でパラメータ範囲を広く設定し、ランダムに 20 組をサンプリングして並列・短時間で完了させ、Phase 2 (細探索) で Phase 1 の結果を基に最良パラメータ周辺を詳細に探索するといった、重要なパラメータを体系的に調整するスクリプトの生成が可能です。 学習データ品質チェックの自動化 学習データの品質チェックスクリプトの生成にも活用できます。データセット構造チェックでは必要なディレクトリ構成や設定ファイルを検証し、PIL (Python Imaging Library) を使った画像破損チェック、YOLO フォーマットのラベル形式検証、画像-ラベル対応関係チェックにより、不整合を検出します。破損画像や不正確なアノテーションを学習前に自動検出することで、無駄な学習実行を防止できます。 このほか、train.py や Dockerfile などのボイラープレートコード生成、SageMaker ジョブ投入スクリプトの雛形作成など、MLOps 開発における定型的な作業にも Kiro を活用することで、開発者が本質的なアルゴリズム設計に集中でき、開発サイクルの短縮が期待できます。 5. まとめ 本記事では、自動運転 AI 開発における課題と、dSPACE と AWS による統合 MLOps ソリューションをご紹介しました。RTMaps と IVS によるデータ収集・整備から、Amazon SageMaker AI と MLflow を活用した学習・実験管理、さらに SIL/HIL による車両レベルでの検証までを一貫したパイプラインとして接続することで、学習と検証の分断を解消し、検証起点の改善サイクルを回すことが可能となります。加えて、開発環境「Kiro」を活用することで、ハイパーパラメータ最適化やデータ品質チェックといった定型作業を自動化し、エンジニアが本質的なアルゴリズム設計に集中できる環境を実現します。 自動運転 AI 開発の効率化や継続的改善を検討されている方にとって、本記事がソリューション選定の一助となれば幸いです。ご質問やご相談は、dSPACE および AWS の担当者までお気軽にお問い合わせください。 著者について 丹羽 伸二 AWS Japan のシニアソリューションアーキテクトとして自動車業界のお客様を担当。自動車業界で15年以上の経験を持ち、主にプロダクトエンジニアリング領域におけるモダナイゼーションや AI 活用の取り組みを支援しています。 村山 哲也 dSPACE Japan 株式会社 CX 技術部 Business Prototyping グループリーダー。データドリブン開発や開発環境のプラットフォーム化などのクラウド系ソリューション、および自動車開発に関わる AI 活用に関するプロトタイピング活動とエンジニアリングをリードしています。 宮本 敬丈 dSPACE Japan 株式会社 CX 技術部 Business Prototyping グループ AI チームリーダー。データサイエンティストとして、製造業、自動車領域における AI 活用、MLOps 基盤構築、エンジニアリングプロセスの自動化に従事。AWSを含むクラウドアーキテクチャの構想や生成 AI、RAG、MCP を活用した業務高度化に取り組んでいます。  

はじめに Turingのインフラチームで、クラウドGPUクラスタの構築・運用を担当している大戸（おおど）です。前回の記事を書いた当時はMLOpsチームに所属していましたが、兼務期間を経て、現在はインフラチームの専任になりました。 Google Cloud Next Tokyo 26では、CTOの山口が「End-to-End 自動運転開発を加速するデータ - セントリックな GPU 計算基盤」を発表しました。そこで紹介したのが、Google Cloud上に構築したA3 Ultra（NVIDIA H200 × 8）30ノード、合計240 GPUのSlurmクラスタです。2026年3月に構

このブログは、東海旅客鉄道株式会社（以下、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 です。