本ブログは 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 を活用した業務高度化に取り組んでいます。  

本ブログは東京電力エナジーパートナー株式会社 サービスソリューション事業部 今野拓也様の監修のもと、アマゾン ウェブ サービス ジャパン合同会社 橋井雄介が執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの橋井です。 電気・ガスなど大規模なインフラを提供する企業にとって、コンタクトセンターはお客さまとの重要な接点となっています。だからこそ、その体験の質が企業への信頼に直結します。「コンタクトセンターに生成 AI を導入したいが、大規模環境で実用的な精度が出るのか」「導入後に組織として使いこなせるのか」——そんな課題をお持ちの方に向けて、 Amazon Connect Customer （旧 Amazon Connect）と Amazon Bedrock を活用した変革を推進している東京電力エナジーパートナー様（以下、TEPCO EP）の事例をご紹介します。 TEPCO EP が取り組むコンタクトセンターの課題 TEPCO EP は、電力・ガスの小売事業を担い、全国複数拠点・数千席規模のコンタクトセンターでお客さまの契約手続きや問い合わせに対応しています。サービスソリューション事業部は「人 × IT の融合により、パーソナライズされたサポートを安心と感動とともに届ける」というビジョンを掲げ、CX 向上を推進しています。 同社のコンタクトセンターでは、デジタルチャネルの比率が向上する中でも電話が約 4 割を占めており、以下の課題がありました。 IVR（Interactive Voice Response: 自動音声応答）が複雑でオペレーターに繋がるまでの導線がわかりにくい オペレータースキルと用件のミスマッチが発生しやすい 応対後の処理負荷が大きく、保留や管理者へのエスカレーションも多い 利用システムが拠点ごとに異なり、会話データの横断的な活用が困難 今回、オンプレミス環境の保守期限を迎えてシステムを刷新するタイミングで、CX 向上と業務効率化を同時に実現するプロジェクト「 SEEDS（Smart Engagement and Efficient Data System） 」を立ち上げました。 図 1 受付チャネルの現状と課題 SEEDS Phase1 で実現したこと Phase1 では、Amazon Connect Customer をベースとした新たな受電環境を構築し、全国にある拠点のうち 18 拠点の切替を完了しました。 要件整理からリリースまで約 10 ヶ月、拠点切替は約 3 ヶ月で完了しています。できる限り標準機能を活用してスクラッチ開発を最小限にしたこと、生成 AI のチューニングやオペレーター画面の構成は検討開始後、早期から実際の挙動などを確認しながら段階的に精度を高めていくアプローチをとったことが、このスピードの鍵でした。 Phase1 で導入した主な機能は以下のとおりです。 音声テキスト化 : お客さまとオペレーターの会話をリアルタイムで文字表示（課題 3, 4 に対応） 会話要約 : 生成 AI が応対内容を自動要約し、オペレーターが利用するカスタム CCP（Contact Control Panel）画面に表示（課題 3 に対応） コールリーズン分析 : 通話内容から問い合わせ理由を自動分類し、データ活用を促進（課題 4 に対応） 法令チェック : オペレーターの説明漏れ等を生成 AI で全件自動チェック（課題 3 に対応） ダッシュボード : リアルタイムの応答状況や実績データを可視化（課題 4 に対応） 図 2 会話要約の活用イメージ 図 3 コールリーズン分析・法令チェックの活用イメージ 技術ポイント: 生成 AI の活用 ここからは、SEEDS の中で技術的にチャレンジングだった要素の一つとして、生成 AI の活用について掘り下げます。 アーキテクチャ設計 Amazon Connect Customer を中心に、 AWS Lambda と Amazon Bedrock を連携させた構成です（図 4）。生成 AI の処理を Amazon Connect Customer の外部に配置し Lambda から Amazon Bedrock を呼び出す設計としたのは、AWS マネージドサービスの中で多様な AI モデルを柔軟に活用できるためです。電力・ガス事業特有の表現や複雑な業務ルールに対応するプロンプトを自由に設計・改善できる柔軟性を確保することを重視しました。また、業界知識の深い実務担当者が単独でプロンプトの修正や評価を行える環境を別途用意し、プロンプトの更新の際には直接プログラムを改修せずにプロンプトファイルの差し替えで環境に反映できる構成としています。 なお、同様のユースケースに取り組むお客さまにとっては、Amazon Connect Customer の ビルトイン AI 機能 （会話要約やテーマ検出など、日本語を含む多言語に対応）を活用し、カスタム実装なしで実現するアプローチも選択肢となります。 図 4 SEEDS Phase1 アーキテクチャ構成（ダイジェスト版） この構成には、タスクの特性に応じて 2つの処理系統 を設けています。 リアルタイム系統（会話要約） : 終話後すぐにオペレーターへ結果を返す必要があるため、通話中にストリーミングされるリアルタイム通話テキストを入力とし、高速な応答が得られる Anthropic Claude Haiku（Amazon Bedrock 上で利用可能な軽量・高速モデル）で処理します。レスポンス性を最優先とした設計です。 バッチ系統（コールリーズン分析・法令チェック・VoC 抽出） : 後続の分析処理は翌営業日以降に行われるため、終話後に確定した完全な通話テキストを入力とし、より高い推論能力を持つ Claude Sonnet（同じく Amazon Bedrock 上で利用可能な高性能モデル）で処理します。処理結果の品質を最優先とした設計です。 いずれの系統でも、Amazon Bedrock の Tool use（関数呼び出し） 機能を活用し、出力を JSON スキーマに沿った構造化データとして取得しています。自由形式のテキスト出力をパースする方式と比較して出力形式の安定性が高く、後続のデータベース保存やダッシュボード連携を一往復の API 呼び出しで確実に完結させています。 なお、基盤モデルはリリース時点では Claude 3.5 Sonnet / Claude 3 Haiku を使用していましたが、2026 年からはパフォーマンスが向上した Claude Sonnet 4.5 / Claude Haiku 4.5 に更新しています。マネージドサービスの利点として、このようなモデルの進化を迅速に取り込むことができます。 各タスクの実装ポイント 会話要約 : 終話後カスタム CCP 画面へ要約を表示します。プロンプト開発時には現場のオペレーターにヒアリングを行い、業務用途を明確にした上で出力フォーマットに反映しました。現場からは 「箇条書きで簡潔に読める」「応対後の処理業務などの参考になる」 と評価されています。要約情報はオペレーター間の通話転送時にお客さま情報を引き継ぐ用途にも活用されているほか、お客さまの声（VoC）の自動抽出も実施し、従来人手で拾いきれなかった細かなニーズやご不満の声を網羅的に収集できるようになりました。 コールリーズン分析 : 64 分類での自動判定を実現し、約 600 件のテストデータで 網羅性 95%・正解率 85% と、目標を上回る精度を達成しました。精度向上の工夫として、生成 AI の出力に対してルールベースの後処理を組み合わせ、AI 単体では解消しにくい誤分類を補正しています。分類結果は呼量分析や呼量予測の精緻化に活用され、オペレーター配置計画の改善につながっています。 法令チェック : 従来はサンプリングによるモニタリングでしたが、生成 AI により低コストで自動実行が可能になったことで、 全件の AI 自動検知 を実現しました。検知ロジックでは、プロンプト内に判断フローを定義し、生成 AI が各ステップの判断根拠を出力しながら段階的に判定を進めます。これにより、複数の条件が絡み合う複雑なルールに対しても精度の高い検知を実現し、応対品質の向上とコンプライアンス遵守の両立を図っています。 生成 AI 活用を組織に定着させる TEPCO EP にとって、コンタクトセンター業務への生成 AI 適用は参考にすべき前例がほとんどない技術チャレンジでした。業務で適切に活用できる高精度なプロンプトを作成するには、生成 AI の特性を理解した上で 業務課題と正面から向き合う 必要があります。そこで段階的に AWS の支援を活用し、生成 AI 活用を目的化せず業務課題の解消を明確に目的設定するプロセスを重視しながら、組織にノウハウを蓄積していきました。 まず、プロジェクト開始前に構築ベンダーと AWS Prototyping Team の支援のもと POC を実施しました。サーバーレスサービスを活用して最小限の MVP 構成を素早く構築し、 実務担当者を含むステークホルダーに生成 AI の使用感を早期に体感 してもらえたことで、その後の要件定義に大きく役立ちました。 次に、各ユースケースの課題定義と実現方法の検討にあたっては、 AWS 生成 AI イノベーションセンター を活用しました。「何を」「どのレベルで」実現するかという タスク設定を技術的に明確化し、評価の枠組みを整えた ことで、後続のプロンプト開発を効率的に進める土台ができました。 続いてプロンプト作成・精度評価については、 AWS Professional Services と協力して進めました。支援の前半は AWS 主導でプロンプトを開発し、後半は TEPCO EP のメンバーが主体となってプロンプト修正と結果分析の試行錯誤を繰り返す形をとりました。 データ準備の重要性やプロンプト評価の手法 など、プロジェクト全体を通じて幅広い知見を得ることができ、この過程で実務担当者 11 名が生成 AI の特性を理解した上でプロンプトを設計・評価するスキルを習得しました。2025 年 12 月の Phase1 完了以降は、 実務担当者が単独で継続的な改善を行える体制 が構築されており、今回の取り組みにより生成 AI 活用の基盤を築くことができたと考えています。 Phase2: よりエージェンティックなコンタクトセンターへ Phase1 で得られた知見をもとに、TEPCO EP では Phase2 としてさらに高度な AI 活用を推進します。Phase1 では主に課題 3・4（応対後の処理負荷、データ活用）にアプローチしましたが、Phase2 では課題 1・2（IVR の複雑さ、スキルミスマッチ）の解消にも踏み込みます。目指すのは「 オペレーター自己完結化 」、すなわちオペレーターが必要な情報に迅速にアクセスでき、応対に集中できる環境の構築です。 TEPCO EP が検討している具体的な取り組みは以下の二つです。 一次応対の自動化 : 従来の IVR を廃止し、自然な会話形式でお客さまの用件を聞き取り、適切なスキルを持つオペレーターに振り分けます。Phase1 で培ったコールリーズン分析の知見を活用し、お客さまが用件に合った窓口へスムーズに到達できるようにすることで CX 向上を図ります。 オペレーターのリアルタイム支援 : お客さまとの会話内容をリアルタイムに分析し、関連するナレッジや手続き情報を自動的に表示します。応対後の後処理についても、登録内容の自動入力や手順ガイドを提供することで、保留や管理者へのエスカレーションを削減し自己完結率を高めます。 これらの実現に向けて、技術的な選択肢を補足します。Amazon Connect Customer では Agentic AI 機能が大幅に強化されており、たとえば一次応対の自動化には自然言語による会話ボット機能が、オペレーター支援にはリアルタイムナレッジ検索やステップバイステップのガイド提供機能が、それぞれ活用できます。Phase1 で構築した Amazon Connect Customer 基盤の上に、これらの機能を段階的に追加していくアプローチが可能です。 図 5 Amazon Connect Customer の Agentic AI 機能概要 まとめ TEPCO EP の事例から、実務担当者が中心となった CX 改善の取り組みにおける重要なポイントを整理します。 CX を起点に技術を選定する : 業務課題を明確にし、それを解決する手段としてクラウドと生成 AI を位置づける マネージドサービス中心のシンプル構成 : 標準機能の活用で開発スピードと保守性を両立し、モデル更新も迅速に取り込む 実データで試行し段階的に精度を高める : 生成 AI のチューニングは実データで検証し、精度と実用性のバランスを追求する スキルを組織に定着させる : プロンプトチューニングや精度評価のスキルを内製化し、自走での改善体制を構築する コンタクトセンターの CX 向上や、Amazon Connect Customer と 生成 AI の活用にご興味のあるお客さまは、お気軽に AWS までご相談ください。 著者について 今野 拓也 東京電力エナジーパートナー株式会社 サービスソリューション事業部 副部長 2007 年東京電力入社。オール電化推進営業、顧客向け Web サイト企画・構築を経て、2019 年より新サービス関連業務・システム構築に従事。2020 年に AI コンタクトセンター（AICC）構築を担当。2025 年よりコール・チャット等運営の統括責任者として新規音声基盤の企画・構築を推進し、現在はサービスソリューション事業部 副部長としてシステム全体統括および SEEDS プロジェクト PM を務める。 橋井 雄介 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト エネルギー・ユーティリティ業界を担当するソリューションアーキテクト。お客さまのクラウド活用と生成 AI 導入を技術面から支援している。

1. はじめに 本記事は、コンサルタント個人として、AIをコンサルティング実務での成果物作成に組み込もうとするなかで見えてきた、構造的な壁と課題解決に向けた話です。 つい先月まで気づいていなかった「バイブコーディング」の威力と、その先で直面した品質の壁。 本記事では、その壁を5つの構造的要因に分解し、解決の方向性、そして5世代にわたる構造改修の概観まで示します。 ※なお、本連載は業務とは別に個人の研究テーマとして取り組んでいる試みの記録です。NTTデータ全社の取り組みとは独立した、私個人の現場ノートとして読んでいただければと思います。 2. 自己紹介 テックブログでの投稿は初めて