令和３年度「5G ソリューション提供センター（5GSC）」の構築等に係る調査検
討の請負

成果報告書

令和４年３月３１日

株式会社 NTT ドコモ

1目次
1. 調査事業概要 ............................................................. 4
1.1 目的 .................................................................... 4
1.2 実施事項................................................................. 4
1.3 実施体制................................................................. 5
1.4 スケジュール............................................................. 7
2. 5GSC サービスコンセプト/ビジネスモデル検討................................ 11
2.1 5GSC サービスコンセプト案の検討 ......................................... 11
2.1.1 5G ユースケースまとめ ................................................... 11
2.1.2 IoT 関係の取り組み ...................................................... 17
2.1.3 主要パブリッククラウド事業者の 5G に対する取り組み ....................... 21
2.1.4 5SSC のサービスコンセプト案のまとめ ..................................... 27
2.2 5GSC のサービスコンセプト案 ............................................. 28
2.2.1 5G 活用インフラの紹介支援 ............................................... 28
2.2.2 5G 活用アプリケーションの開発の支援 ..................................... 32
2.2.3 エコシステム/連携標準の提供 ............................................. 35
2.2.4 疑問解決型コンサルティングの提供 ........................................ 37
2.2.5 特化型ソリューション提供及びコミュニティ形成支援 ........................ 40
2.3 サービスコンセプト等に対するインタビューの実施.......................... 44
2.3.1 有識者へのインタビュー .................................................. 45
2.3.2 自治体へのインタビュー .................................................. 48
2.3.3 令和 3 年度ローカル 5G 実証参画事業者へのインタビュー ..................... 49
2.3.4 サービスコンセプト等に対するインタビュー結果のまとめ .................... 51

2.4 まとめ ................................................................. 52
3. 提供プラットフォームの検討 .............................................. 53
3.1 5GSC のプラットフォームに求められる要件 ................................. 53
3.1.1 基本的な考え方.......................................................... 53
3.1.2 5GSC の提供方式の検討 ................................................... 53
3.1.3 DL 型プラットフォームに求められる機能 ................................... 55
3.1.4 プラットフォームを実現するアーキテクチャ ................................ 59
3.2 プラットフォーム実証環境・システム構成の定義 ............................ 61
3.2.1 前提条件................................................................ 61
3.2.2 インフラ構成............................................................ 62
3.2.3 アプリケーション構成 .................................................... 70

3.3 本実証の実施............................................................ 74
3.3.1 本実証の実施内容と評価方法 .............................................. 74
3.3.2 本実証の検証内容 ........................................................ 782

3.4 検証結果と今後の検討課題................................................ 83
3.4.1 検証結果................................................................ 83
3.4.2 今後の課題.............................................................. 84
4. DL 型利用環境における実証実施 ............................................ 86
4.1 実証目標・手法.......................................................... 86
4.1.1 実証目標................................................................ 86
4.1.2 実証手法................................................................ 86
4.2 実証概要................................................................ 87
4.3 実証環境................................................................ 88
4.3.1 実証フィールド.......................................................... 91
4.3.2 実証システム構成の検討 ................................................. 107
4.4 実証内容・実施結果..................................................... 110
4.4.1 DL 型アーキテクチャの実装可能性 ........................................ 111
4.4.2 DL 型アプリケーションの水平展開可能性（工数削減効果）の確認............. 132
4.4.3 DL 型アプリケーションの水平展開可能性（AI 検出性能影響・リアルタイム性）
及び実用性の確認 ....................................................... 135
4.5 実証結果まとめ......................................................... 179
4.5.1 評価・試験結果の整理 ................................................... 179
4.5.2 DL 型の課題と SaaS 型検証の必要性 ....................................... 180
5. 5GSC の普及啓発活動の実施 ............................................... 182
5.1 自治体への 5GSC 取組の説明とインタビュー ................................ 182
5.2 各団体への 5GSC 事業の普及啓発活動 ...................................... 182
5.2.1 5GSC 普及の取組としての鉄道協議会の設立 ................................ 182
5.2.2 鉄道車両監視 AI の普及展開方策検討 ...................................... 184
5.3 5GMF を通じた 5GSC 調査事業の取組み状況の掲載 ........................... 185
6. 本年度実施総括 ......................................................... 187
6.1 サービスコンセプトの検討............................................... 187
6.2 提供プラットフォームの検討............................................. 188
6.3 DL 型利用環境における実証 .............................................. 190
6.4 普及啓発活動の実施..................................................... 192
6.5 今後の検討............................................................. 192
7. その他事項 ............................................................. 195
7.1 サイバーセキュリティ対策............................................... 195

3

1. 調査事業概要
1.1 目的総務省では 2030 年頃の導入が見込まれる「Beyond 5G」（6G）の実現に向けて、令和 2 年
6 月に「Beyond 5G 推進戦略 －6G へのロードマップ－」の公表を行っており、Beyond 5Gの早期かつ円滑な展開のため、5G があらゆる分野や地域において浸透し、徹底的に使いこなされている「Beyond 5G ready※」な環境の早期実現を目指している。ここでは、企業や地方公共団体等による DX 促進を図るため、ビジネスモデルやユースケースをソリューション
モデルとして低廉かつ容易に利用できるよう、イノベーションハブとしての機能を持つ「5G ソリューション提供センター（仮称）」の仕組みを構築すると述べている。
IT 人材が質・量ともに不足している中で DX 及びローカル 5G を含めた 5G の普及展開を実現するためには、「5G ソリューション提供センター（仮称）」による 5G ソリューションの円
滑な導入に対する支援及び共創環境（様々な主体を繋げるハブ機能）の構築が急務である。

図 1.1-1

5G 提供ソリューションセンター（仮称）のイメージ
出典：総務省※Beyond 5G ready： Beyond 5G の早期かつ円滑な展開のため、あらゆる分野や地域において 5G が浸透し、使いこなされている状態
本実証は、総務省の目指す「Beyond 5G ready」な環境の早期実現に資する、「5G ソリューション提供センター（5GSC）(仮称)」構想の実現に向け、5G 活用ソリューションの促進に必要な要件等を調査検討する。

1.2 実施事項
本事業では、以下 4 項目を実施した。
4

①5GSC のサービスコンセプト・ビジネスモデル検討
5G 産業用ソリューション展開のリファレンスとして、5G ユースケースの国内外での状況、
IoT ベンダー、主要 Cloud 事業者の取組み状況を調査した。
調査結果をもとに、5G の特徴である大容量、低遅延、多数同時接続を活用し、企業に役に立てるサービスとは何かを主眼に、コアになると思われる機能を分解して、サービスコン
セプトを整理した。
②提供プラットフォームの検討
前項で定義した 5GSC のサービスコンセプトを実現するのに提供プラットフォームに求められる要件を洗い出して、提供方式、機能、アーキテクチャの検討を行った。
検討したプラットフォームアーキテクチャに基づいた機能の開発・検証を行うために実証環境の構成を行い、プラットフォーム利用シーンを想定した評価項目を策定し、各機能の検証、評価を行った。
③ダウンロード型（以下、DL 型）利用環境における実証実施
本年度は 5GSC のアプリケーションの DL 型提供方式について実証システム環境を構築し、アーキテクチャに関する技術的な評価を実施した。鉄道分野ユースケースを活用し、DL 型
アプリケーションの他事業者利用可否の実効性を実証において確認した。
DL 型実証システムとして昨年度開発した「鉄道車両監視 AI システム」を用い、昨年度開発した AI 映像解析エンジンを DL 型コンテナアプリケーションとして再開発し、今年度西
日本鉄道株式会社（以下、西鉄）システム環境にダウンロード・構築を行った。
④5GSC の普及啓発活動の実施
地方自治体などの今後、5G ソリューションの普及展開を担う事業者実施主体となりうる団体に対して今年度 5GSC の調査事業の一環として 5GSC の取り組み概要やコンソーシアム
で検討されたサービスコンセプト案に対するヒアリング活動への協力をいただいた。
また、5GSC で実装するソリューションの普及展開の可能性を検討するため鉄道事業分野
で協議会を組成するなどの普及啓発活動を行った。
さらに、5GSC 調査事業の活動を継続的に実現することを目的に、本実証の取組み内容について第 5 世代モバイル推進フォーラム（5GMF）を通じて情報発信を行うなどの普及啓発活動を行った。

1.3 実施体制
本事業の実証コンソーシアムは、株式会社 NTT ドコモ(以下、ドコモ)、エヌ・ティ・ティ・
コミュニケーションズ株式会社(以下、NTTCom)、日本アイ・ビー・エム株式会社(以下、IBM)3
社により構成した。
本事業のとりまとめ等を行う代表機関は、ドコモであり、実証全体の管理、実証結果の評
価、報告書作成等を担った。
NTTCom はビジネスモデル検討・調査・ユースケースの検討、事業計画の策定、IBM は 5GSC調査事業の全体進行支援を行った。詳細な実施体制と役割は図 1.3-1 の通りである。

5

図 1.3-1

実施体制

なお、本事業の実施にあたり、図 1.3-2 に示すプロジェクト推進体制を構築した。

図 1.3-2

プロジェクト推進体制

各チームの役割は、以下のとおりである。
・プラットフォーム担当チームは 5GSC のプラットフォームのデザイン、設計、構築、運用を実施する。
・事業計画立案チームは、5GSC の事業を検討し、計画を立案、活動計画を作成し、実行
6

の戦術を作成する。
・ビジネスインキュベーションチームは、5GSC の主たる業務、5G を活用するビジネスを増やす、事業を計画している企業、諸団体の新規事業の立案計画・実行を支援する。
・5G 技術 PoC チームは、5GSC の核である、5G の高速化、高度利用を狙い様々なケースを想定し、計画を立案するとともに PoC の実行を推進する。
それぞれの役割と責任範囲については、表 1.3-1 に詳細を記載する。
表 1.3-1 プロジェクト推進体制構成組織の役割、責任範囲、主な活動等

1.4 スケジュール
全体実施スケジュールおよび、チーム活動ごとにブレイクダウンした本事業の実施スケ
ジュールは以下のとおりである。

7

図 1.4-1 全体実施スケジュール【事業計画立案チーム】
令和 3 年 11 月から令和 4 年 3 月にかけて、5GSC の役割、ビジネスコンセプトの作成、事業計画の策定を行う。
・現状把握と調査の実施
・5GSC の役割及びサービスコンセプトの作成
・事業計画の作成
・ビジネスモデルの明確化

図 1.4-2

事業計画チーム実行スケジュール

令和 3 年 12 月から令和 4 年 2 月にかけて、他チームでの実施内容結果を踏まえ、5GSC の活動内容の再検討を行い、令和 4 年 3 月にその結果を報告書に取り纏める。
【ビジネスインキュベーションチーム】
8

令和 3 年 12 月から令和 4 年 2 月にかけて、以下を実施し、令和 4 年 3 月にその結果を報告書に取り纏める。
・ビジネスモデルに関する評価・調査・検討
・5GSC の活動内容の改訂・普及啓発活動の実施

図 1.4-3

ビジネスインキュベーションチーム実行スケジュール【5G 技術 PoC チーム】
令和 3 年 11 月から 5GSC に関する技術的検討を開始し、令和 3 年 12 月中旬から令和 4 年
3 月中旬にかけて以下を実施し、令和 4 年 3 月にその結果を報告書に取り纏める。
・DL 型アーキテクチャに関する評価・検証
・鉄道車両検知 AI に対する評価・検証
・横須賀モデルの実装 ・IT 系サービス対応(技術アドバイス、PoC 環境)

図 1.4-4

5G 技術 PoC チーム実行スケジュール【プラットフォーム担当チーム】
令和 3 年 11 月から令和 4 年 1 月中旬にかけて、DL 型に対する評価・検証として以下を実施する。
・RHMP 検証・IBM Cloud Satellite 構築
9・ECL 準備
令和 4 年 1 月中旬から令和 4 年 2 月にかけて、5GSC の構築として以下を実施する。
・コンセプト定義・システム構成検討
令和 4 年 2 月上旬から令和 4 年 3 月にかけて、以下を実施する。
・5GSC 主要サービスの運用・商用想定で具備すべき機能の設計
・次年度で実装が必要となるもの企画
令和 4 年 3 月に、上記各項目の実施結果を成果報告書に取り纏める。

図 1.4-5

プラットフォームチーム実行スケジュール

10

2. 5GSC サービスコンセプト/ビジネスモデル検討
2.1 5GSC サービスコンセプト案の検討
5G が産業で活用されるには、どのようなサービスコンセプトが必要か、現状の 5G がどのようなケースで活用されているかを確認して、今後の施策の参考にすべく、ユースケース
を調査した。
また、これからの施策展開のリファレンスとして、急速に産業で拡大している IoT 関係の取り組みおよび、主要パブリッククラウド事業者の 5G に対する取り組みに関して、調査検討を行った。
2.1.1 5G ユースケースまとめ
各国の民間企業の 5G ユースケース事例について調査を行った。
活用目的は、

4K/8K/360°カメラや IoT 機器と接続し、高精細な映像・画像、音声、数値データ等
大容量データを遠隔に配信

工場や山間や車両・道路などネットワーク配線工事が困難または、広域にわたる地域
で Wi-Fi 以上の安定通信の確保

緊急治療など緊急性を要する状況での低遅延な配信など複数の IoT 機器や人との接続を目的として活用されるケースが多くみられた。
また、適用業務単位で整理した所、「検査」、「監視・セキュリティ・認証」、「遠隔・共有」、「販売」と産業を越えて幅広い業務に対して 5G が活用されており、業務を軸に多くの産業に展開・応用が可能であると考えられる。
表 2.1.1-1

適用業務別 5G ユースケース一覧（概要）
展開産業候補5G の活用目的
農業・林業、運輸 4K/8K/360°カメラや業、医療 等
IoT と接続し、高精細な映像・画像、音声、

監視・
映像や音声、数値等の 農業・林業、製造
数値データ等大容量
セキュリティ・
解析による監視（異常・ 業、建設業、電データを遠隔に配信
認証
危険検知、予測、管理含 気・ガス、医療、工場や山間や車両・道む）
小売業、サービ 
路などネットワーク

映像・画像による人物・ ス業 等
配線工事が困難/広域物体認証
な地域な地域で Wi遠隔・共有
遠隔作業指導/指示
農業・林業、製造
Fi 以上の安定通信の人による遠隔制御業、建設業、電確保

映像・音声・数値等の 気・ガス、医療、緊急治療など緊急性
情報連携
教育・学習支援 を要する状況での低事業、小売業、サ
遅延な配信ービス業 等
複数の IoT や人との販売
スマートストアによる販売 小売業、サービ 
接続
ス業 等
適用業務
検査

5G ユースケース（概要）
映像や音声、数値等の解析による検査・検品

下記に各国の民間企業の 5G ユースケース事例を示す。
11

表 2.1.1-2 適用業務別 5G ユースケース一覧（詳細）適用業務
5G ユ ー ス ケ 5G 活用目的
事例（企業名)
本社所在地
ース
日本 北米
検査
ロボットによ 
4K カメラと センチメンタル
る体調検査
接続し、高 ロ ボ ッ ト（ビデオカメ
精細映像を （ Vodafone ・ラとサーモグ
高速に通信 Intel・
ラフィをロボするため
Fivecomm
・●ットに搭載 リアルタイ Altran
・し、体温の高ムで検知す Polytechnic
い人、マスク
る必要があ University
をしていないるため、低 of Valencia）
人を検査）
遅延性が必
要なため
ロボットアー カ メ ラ と 接 続 ロボットアーム
ムの故障検知 し、高精細映像 の故障検知（日●を高速に通信す 立 製 作 所 ・るため
Ericsson）
監視・
道路監視シス 監視カメラと接 EarthCam
セ キ ュ リ テム
続し、高精細映 （ Verizon ・●ティ・
像を高速に通信 Sierra
Wireless・AT&T）
認証
するため
Smart
AI 顔認証カ メ ラ と 接 続 5G
し、高精細映像 Travel System
を高速に通信す （China Eastern
るため
Airlines,
Beijing Unicom,
Huawei Beijing）
電力系統制御 従来の 4G では 5GSA 電力スライサービスにお 様々な電力系統 ス（中国電信江
けるネットワ 制御サービスに 蘇省、中国国家
ークスライシ おいて遅延や同 電網公司（SGCC）
ング活用
一ネットワーク 南京電力供給公を使用によるネ 司、Huawei）
ットワークの干渉が発生することがあったが、超高速・低遅延・多接続と多機能な 5G に対しネットワークスライ
シングを使うことで、遅延が発生しそうな場合
12

欧州

中国

●

●

●

●

製造工程の高度化（生産性向上と製品の質担保、不要業務の削減と予防メンテナンスの実施、製造工程における機械構成の容易な変更等）

遠隔・共有

ドローンによる雑草防除に 5G の低遅延の動的な供給やネットワークの不干渉を必要最低限の 5G 機能で実現
画像・動画 5G Enabled
含む高精細Manufactur
データを高
ing
(ATS
速 に 接 続Global ・
し、リアル
Ford
・
タイムで不
HSSMI
・
具合等を検
Lancaster
知する必要
University
があり、低・TM Forum・
遅延性能がTWI・Vacuum
必要なため
FurnaceEngineerin
エッジコン
g,
ピューティ
Vodafone)
ングとハイブリッドク 
工場のセン
ラウドと接
サなどによ
るネットワ
続し、画像・
ークの負荷
動画含む高
精細データ
管
理
（NFWare）
を高速に通IBM イン ダ
信が必要な ス ト リ ーため
4.0 スタ ジAR・VR と接オ（IBM）
続し、画像・
動画を含む
高精細デー
タの高速通
信が必要な
ため

ドローンが 5G ドローンを使取得した４ った雑草防除のK などの高 デモンストレー
精細映像を ション
リアルタイ （Proximus）
ムで確認す
るため

目視外での
自律飛行に
おいても即

13

●

●

●

座 に 対 応
し、安全性
が確保する
ために超低
遅延が必要
なため
5G 対 応 工 場
で自律走行ロボット

ライブ映像配信サービス



マルチアングル映像配信サ
ービス





高精細映像
を複数ロボ
ットから取
得し、リア
ルタイムに
指示を送信
する必要が
あるため
無線で安定
通信可能な
5G が必要なため

5G 対応工場で自律走行ロボット（Ericson）

高 精 度 で360° 動 画
のストリー
ミング視聴
には超高速
性が必要な
ため
主演者と参
加者の双方
向の意思疎
通を実現す
る た め に
は、超低遅
延性が必要
なため

au
5G
（KDDI）

高精細な映
像の配信、
リアルタイ
ム性を実現
させるため
には、超高
速、超低遅
延が必要な
ため
撮影時に複
数の機材か
ら映像デー

Swipe
Video
（AMATELUS）

●

LIVE

●

14

●

タを映像編
集用サーバ
などへ配信
する際に、
多数同時接
続性が必要
なため
（救急車/病院）360 度カ
メラ・スマー
トグラス等を活用した視覚情報共有・診断・治療



技術者訓練プ
ログラム

クラウドゲー
ミングサービス
販売

患者の映像
を AR/MR ヘ
ッドセット
や
360°4K/8K
カメラを通
じて映像を
遠 隔 に 高
速・低遅延
で配信し、
病態を事前
に把握・遠
隔診断する
ため
診断時には
ビデオ通話
を使用する
場合、通話
品質向上の
ため、低遅
延が必要な
ため





5G
connected
ambulance（BT ・the
University
Hospitals
Birmingham
NHSFoundation
Trust）
Chinese
PLA
GeneralHospital（
China
Mobile ・Huawei）

AR/MR ヘッ ドセッ
トや
360°4K/8K カメラを通じて映像
を遠隔に高速・
低遅延で配信するため

技術者訓練プロ
グ ラ ム （ Booz
Allen Hamilton・
Department of
Defense (DOD)）

ユーザー側に低遅延、安定した回線と高速通信が必要なためGeForce
NOW（NVIDIA）

スマートスト ア（無人店舗、レジカート）

通常の会計
業務と同様
のスピード
で商品を認
識し、会計

This
Is
5G
Revolutionizin
g Retail onIntel (Intel)

15

●

●

●

●

●



様々な IoT と決済システムを 連 携 （ IoT
の自律型決
済）

処理を完了
させるため
に、超高速
が必要であ
るため
複数台のレ
ジで会計処
理を並行し
て実行する
ため、多数
同時接続が
必要なため

複数ある IoT と多数接続し決済を実施するために必要なため5G
tothe
Global Payments（ Verizon ・Mastercard）●------------------------------------------------------参考資料[2-1] How 5G is helping transform healthcare<https://www.vodafone.com/mobileworld-congress-2021/5G-sentinel-robot>[2-2] 米国カリフォルニア州のシリコンバレーリサーチセンターにおいて、
5G による産業用 IoT ソリューションのテストを開始<https://www.vodafone.com/mobileworld-congress-2021/5G-sentinel-robot>[2-3] EarthCam Offers World’s First 5G Multi-Network Camera
System<https://rockproducts.com/2020/11/12/earthcam-offers-worlds-first-5Gmulti-network-camera-system/>[2-4] EarthCam Announces the World's First 5G Multi-Network Camera
System<https://www.earthcam.com/press/press_details.php?id=661>[2-5] China Eastern Airlines, Beijing Unicom, and Huawei Beijing Launch 5G Smart
Travel System<https://www.huawei.com/en/news/2019/9/eastern-airline-huawei-5Gindoor-unicom>[2-6] Huawei with China Telecom and State Grid Jointly Complete the World's
First 5G SA Electricity Slice Test<https://www.huawei.com/en/news/2019/4/huaweisgcc-first-5G-sa-power-grid-slicing>[2-7] 5G Enabled Manufacturing (5GEM)< https://www.5G-em.org/>[2-8] NFWare<https://nfware.com/>[2-9] 強 い 日 本 の 生 産 現 場 力 を 、 更 に 強 化 す る イ ン ダ ス ト リ ー 4.0 戦 略<https://www.ibm.com/jp-ja/industries/industrial/industry-4-0>[2-10] How 5G, drones and AI enable a more sustainable agriculture: Proximus andpartners demonstrate 5G drone application facilitating targeted weed
control<https://www.proximus.com/news/2021/20210624-news-proximus-and-partnersdemonstrate-weed-control-via-5G.html#>[2-11] エリクソンが解説、工場内ロボット制御に向けた 5G の進化とは
16

<https://xtech.nikkei.com/atcl/nxt/column/18/01700/00015/?P=3>[2-12] DOD Selects Booz Allen to Integrate 5G
Technologies<https://www.boozallen.com/e/media/press-release/q4-2021/dodselects-booz-allen-to-integrate-5G-technologies.html>[2-13] ～au 5G 常設の「Zepp Haneda (TOKYO)」で 5G 時代のライブエンターテインメント体験を提供～<https://news.kddi.com/kddi/corporate/newsrelease/2020/03/23/4330.html>[2-14] Swipe Video<https://swipevideo.jp/case-study/>[2-15] UHB and BT demonstrate UK's First Remote Diagnostic Procedure Using a 5G
Connected
Ambulance<https://newsroom.bt.com/uhb-and-bt-demonstrate-uks-firstremote-diagnostic-procedure-using-a-5G-connected-ambulance/>[2-16] China successfully conducts first surgery over 5G on a human being with
Parkinson's<https://www.firstpost.com/tech/news-analysis/china-successfullyconducts-first-surgery-over-5G-on-a-human-being-with-parkinsons-6276641.html>[2-17] GeForce NOW Delivers Legendary GeForce Gaming With More Games on More
Networks to More Devices<https://blogs.nvidia.com/blog/2022/01/04/geforce-now-eaatt-samsung-ces/>[2-18]5GSmartRetail<https://www.intel.co.jp/content/www/jp/ja/wirelessnetwork/5G-technology/5G-retail.html>[2-19] Verizon Business and Mastercard Partner to Bring 5G to the Global Payments
Industry<https://www.verizon.com/about/news/verizon-and-mastercard-5G-globalpayments>

2.1.2 IoT 関係の取り組み
本項では IoT に取り組むベンダーがどのようなビジネスを展開し何を実現しているかを調査し、取り組みとその狙いを整理した。
IoT の登場により、センサはさまざまなデータを取得できるようになった。
温度や傾きといった定量的なデータをより多くの地点、部位で取得し利用できるようになった。
また、メガネサイズのデバイスで、フル HD の動画をクラウドにアップロードし、画像認識に使えるような仕組みも実現している。
このように、IoT は収集したデータを製造工程等に利用することで現場の高度化を実現している。
一方で、データを処理するクラウド環境については、Amazon、マイクロソフト、google、IBM などベンダー各社が「IoT クラウド」基盤をリリースしている。
5G を活用した IoT の更なる高度化は、多くの産業領域で試験、実用実験が展開されている。
・自動運転
・手術の遠隔操作
・スマートファクトリー
・インフラの管理・スマート農業・スマートハウス17

・スマートシティ
5G を活用した IoT 技術について、早期に自社戦略に取り入れビジネス展開している先行
IoT ベンダーの活動に注目し、その取り組みを調査した。
表 2.1.2-1 の通り、自社の独自の特徴や強みを生かして参入していること、自社製品の活用プラットフォームを展開していること、また、オープン化や提携等ベンダー間及び異業種での連携を進めていることが挙げられる。
このように、IoT 先行ベンダーが市場に訴求するために実施してきた、プラットフォーム
展開、オープン化、異業種連携などの戦略は、5GSC のサービスコンセプトの参考とした。

企業
GE デジタル
シーメンス

SAP
AWS

マイクロソフト

PTC

ファーウェイ

ファナック

三菱電機
コマツ

IBM
TRUMPF表 2.1.2-1 各 IoT ベンダーの取り組み
概要
産業用機器からデータを収集・分析する IoT プラットフォーム「Predix」を展開。[3-1]
センサデータをリアルタイムで収集・分析し製品や製造プロセスの最適化を可能にする製造業向けのクラウドベースのオープン IoT プ
ラットフォーム「Mindsphere」を展開。[3-2]基幹システムとデータ連携しクラウドへの反映を行い、データ分析
やアプリケーション管理が行える「SAP Cloud Platform」を提供。
IoT デバイスをクラウドアプリケーションや AWS クラウドサービス、
ネットワーク上の他のデバイスとやり取り可能にするマネージド型
クラウドプラットフォームである「AWS IoT」を提供。
IoT デバイスの接続、管理やソリューションの作成、管理等を行えるマネージド型クラウドプラットフォームである「Azure IoT」を提供。
各種デバイスの接続、ネットワーク構築、産業向けアプリケーショ
ン提供、データ解析等の機能を備えた産業用 IoT プラットフォーム
である「ThingWorx」を展開。
主軸であったスマートフォン等との連携を主としたコンシューマ向けの IoT を展開していたが低迷し、近年エンタープライズ IoT にシフト。
製造現場の様々な機器をメーカーや世代に関係なく接続可能にし、製造設備やデータの一言管理を可能とする製造業向けオープンプラ
ットフォームである「FIELD (FANUC Intelligent Edge Link &Driver System)」を展開。
Factory Automation に特化したソリューションを提供する eF@ctory を展開。
建設業務における生産プロセスに関与するすべてのもの（建機だけでなく環境、地形、資材、スタッフ等も含む）をつなぐプラットフ
ォームである「LANDLOG」を提供。
アプリケーションを構築・管理・実行するためのクラウドプラット
フォームである「Watson IoT Platform」を提供。
工作機械メーカーである特徴を生かしスマートファクトリーに特化した IoT プラットフォームを提供
18

各社の取り組みにはそれぞれ対象となる領域及び提供するサービスに企業の特徴が現れている。
 GE デジタル
GE デジタルは GE の主要ビジネスである産業用機器等の製造販売を踏まえ、航空機のエンジンや工場内の生産設備等の産業機器からデータを収集、分析するプラットフォーム「Predix」を展開した。コントローラーやセンサにインストールされた「Predix Machine」
を用いてデータを整え転送し分析を行うというものである。しかしながら規模は縮小されており、原因として自社クラウド「Predix Clouds」を運用予定だったが同時期に大規模データセンターが建設された AWS 及び Microsoft Azure との提携にシフトしたこと、自社向
けソフトウェアの延長線上であったためユーザーファーストの作りでなかったため受け入れられづらかったこと、後続するシーメンス MindSphere のシェアが高いことなどが挙げられる。[3-1]
 シーメンス
シーメンスも GE 同様に製造業を対象にした産業機器向けの IoT プラットフォームである「MindSphere」を展開している。[3-2] 機械や設備メーカーに関係なくデータを取得でき、インターフェースにオープンな標準規格である OPC Unified Architecture を利用している。
他社製の IoT プラットフォームにおいても AWS, Microsoft Azure, Alibaba Cloud に対応
しておりいずれの環境でも同一アプリを展開可能である。[3-3] SAP
SAP では基幹システムとのデータ連携やアプリケーション統合・管理を行えるプラット
フォーム基盤である「SAP Cloud Platform」[3-4][3-5]とイノベーションに必要なアプリケー
ションやソリューションに加え方法論や専門知識といった一連のサービスを提供する「SAP
Leonardo」を提供している。[3-6] Amazon Web Service(AWS)AWS の「AWS IoT」[3-7]では自社のクラウドサービスと連携して IoT のアプリケーション
及びそれをサポートするサービスを展開している。インフラ領域や AI に注力している。ミ
ドルウェア戦略を取っており Iaas 領域において Azure に先行している。
 Microsoft
Microsoft は、自社の「Azure IoT」[3-8]では自社のクラウドサービスと連携して IoT のアプリケーション及びそれをサポートするサービスを展開している。Azure は AR/VR 戦略に注力しており AWS を追う形となっている。PTC は産業向け IoT プラットフォームの「ThingWorx」[3-9]を展開し、組み立て製造業に強みを持っている。また、オートメーション
においてロックウェル[3-10]と、産業用 IoT において Microsoft[3-11]と提携を行っている。
 Huawei
Huawei はスマートフォン等の既存主軸事業の延長でコンシューマ向けの IoT サービスを展開していたがエンタープライズ向けに転換を図っている。[3-12]クラウド、5G、AI、IoT を統合しアジア太平洋地域へのサービス提供を行っている。
 ファナック
ファナックでは主軸である製造業向けの「FIELD system (FANUC Intelligent Edge Link
& Drive system)」を展開している。[3-13]オープンプラットフォームであるためサードパー
ティの開発者が自由にアプリケーションやデバイス用コンバータの開発が可能であり、他社製の CNC やロボット等の機器からも情報を収集、上位システムとの結合が可能となっている。[3-14]
 三菱電機
三菱電機は既存事業の Factory Automation 分野に注力しており IoT によりスマート工
場化を促進する「e-F@ctory」を展開している。[3-15]また、オープンなエッジコンピューテ
19ィングのソフトウェアプラットフォームである「Edgecross」に対応したソフトウェアを提供しており生産現場のデータ活用を図っている。[3-16] コマツ
コマツでは NTT ドコモ、SAP ジャパン、オプティムとともに建設業務のオープンプラッ
トフォームである「LANDLOG」を提供している。[3-17]建機以外の環境・地形・資材・スタッ
フといった建設生産に関わるすべての「モノ」から得られるデータを収集・解析する。情報の収集・蓄積・解析をオープンにすることでアプリプロバイダーの参入を容易にし、建設業に限らない異業種との連携も容易となる。[3-18]
 IBM
IBM では「Watson IoT Platform」を展開し IBM Cloud との連携によってデバイスの管理やアプリケーションのライブ・データ及び履歴データへのアクセスを可能にしている。[3-19]
IBM は Red Hat の買収によりすべてのクラウドサービスに Red Hat Open Shift が組み込まれ、クラウド事業の成長を狙っている。[3-20]
 TRUMPF(トルンプ)
TRUMPF はインダストリー4.0 に対応した産業向け IoT プラットフォームの「AXOOM」を提供している。[3-21] OPC UA や MT Connect 等の標準的な通信プロトコルに対応しており、新
たな標準に対応する場合にもコストを抑えて情報連携を可能にすることを特徴としている。
加えてアプリケーションや加工ノウハウ等を Web サイト上で販売されておりアプリケーシ
ョンの拡充を実現している。また、主軸の事業である工作機械分野だけでなく製造業、医療、農業、物販等の異業種にも適用可能としている。[3-22]
現在は、上述の先行 12 ベンダーの他にも多くの企業が IoT 関係ビジネスに参画している。2022 時点の IoT 参入企業の関連図カオスマップ(図 2.1.2-1)に示すように多くの企業がひしめき、5G/IoT の試験、実用実験例と同様、自動運転、スマートシティ、製造自動化等での連携が進んでいることがわかる。

図 2.1.2-1 IoT 関連企業カオスマップ [3-23]
これら企業の IoT の取り組みターゲットについて記載したのが図 2.1.2-2 である。これを見るとアジア圏においては政府主導の施策が、アメリカ、ヨーロッパ、日本では自動運
転やスマートシティなどのトピックが多く見られる。
20

変革
事例

政府
主導
施策

図 2.1.2-2 IoT 企業取り組みターゲット [3-23]

2.1.3 主要パブリッククラウド事業者の 5G に対する取り組み
これまで IoT 関連企業の取り組について述べたが、IoT と密接に係るクラウド事業、その大手４社 Google, Amazon, Microsoft, IBM について 5G に関する調査を行った。
４社はそれぞれの Cloud のサービスを 5G に連携できることをインフラとして、GCP 及び
AWS はプラットフォームを自社 Cloud サービス上に構築してもらうために使いやすいサービスとして展開している。また、IBM Cloud 及び Azure では 5G キャリア事業者に向けたサービスを展開しており、加えて Azure は製造業等個別ソリューションを中心に展開している。
全体の傾向として 5G は IoT とセットでアプリケーションが展開されることを想定されている。
Google Cloud Platform (GCP)の取り組み
GCP は、”自らのサービスをエッジコンピューティング/ネットワークエッジでも提供”
や”5G ユースケースの創出の促進や 5G 導入に関する標準の策定を通じて未成熟な 5G 市場の早期シェアを拡大”する狙いがあると考えられる。
表 2.1.3-1 Google Cloud Platform の 5G に関する取り組み
5G に関する取り組み
狙い概要
事例
5G 通信事業者・IoT ベンダー 
GCP 機能と MEC サービス 
5G の超高速通信を介し21

との提携し、エッジコンピューター/ネットワークエッジ
関連サービスを開発・クラウドのデータセンターとユーザ
ー拠点／端末間の通信速度強化

を連携して利用できるサービスを開発（AT&Tと共同）
Cloud RAN 開発（ノキアと共同）

ネットワークエッジに 5G 機
能を支えるワークロードや
GCP サービス、パートナー企業が構築したアプリケーションを提供するプラットフォー
ムを構築

Anthos for Telecom
30 社以上、200 を超えるアプリケーションが存在

企業にネットワークやサービスの利用を可能とする検証場
所を提供（企業とエコシステ
ムを構築）し、5G のユースケース創出を促す



5G を利用するためのアーキ
テクチャを策定

次世代のインフラストラクチ
ャを提供（Intel と共同）



GCP サービスをエッジコ
ンピューティング/ネッ
トワークエッジでも提供可能にするため
5G ユースケースの創出の促進やネットワーク
エッジを含めたサービスを導入する上での標準策定を通じて未成熟な 5G 市場の早期シェアを拡大（先行優位性を構築）するため

ネットワーク機能検証
ラボ（Intel と共同）
NVIDA 主催 AI-on-5G
lab との提携（GCP サー
ビス提供）



Amazon Web Service(AWS)の取り組み
AWS は高速通信環境、低遅延性能を求めるビジネスに向け 5G を活用する傾向がある。また、普及展開に向け、インフラ整備や外部クラウド・クラウドネットワーク間の連携を進めていることがわかる。
表 2.1.3-2 AWS の 5G に関する取り組み
5G に関する取り組み
狙い概要
事例
5G の特長である「低遅延」
DISH Network
AWS Private 5G「大容量高速接続」「同時接Corporation 社、Koch
企業の施設内の 5G ネッ
続性」を活かし、既存ニーズ社での 5G ネットワーク
トワークの導入・拡張に応えるサービスの提供
構築を支援
を数日単位で実現する
マネージドサービス【AWS Private 5G】

現状の調達プロセスの
コネクテッドカー、イAWS Wavelength
改善による迅速・低コ
ンタラクティブなライ
低遅延性能を必要とす
ストでの 5G ネットワー
ブ動画ストリーム、るアプリ向けに最適化
ク構築支援を実現する
AR/VR、スマートファク
したクラウドサービス
ため
トリー、リアルタイム

AWS コンピューティング
5G ネットワークの構築のゲームプレイ、ヘルおよびストレージサー
ニーズは存在するが、スケア向けの ML 支援診
ビスを 5G ネットワーク
それに応える調達コス断が主な UC 領域
内に組み込んで、超低ト（費用、時間、労Sportable 社とラグビー
レイテンシーアプリケ
力）が高く課題であっゲームにリアルタイム
ーションの開発、デプたのインサイトをもたら
ロイおよびスケーリン
22

グのためのモバイルエッジコンピューティン
グインフラストラクチ
ャを KDDI ネットワーク
エッジにて提供する

5G 基幹ネットワーク運用検証NEC 開発の 5G 基幹ネットワークソフトウェア
を AWS のインスタンスと NTT ドコモの自前の仮想化環境にインストールしたハイブリッド
クラウドを構成し、通信事業者の水準としての可用性や運用性を検
証









す方法を実現
Harman 社とコネクテッ
ドカーエクスペリエンスを開発
Zixi 社とソフトウェア
定義のビデオプラット
フォームを強化
AWS 開発の Arm ベースプ
ロセッサー
「Graviton2」との適用を検証
今後は AWS の外部でのデータセンター設置可
能な専用システム「AWS
Outposts」を使った構成も検証予定23【AWS Wavelength】
AWS クラウドを通信事業者のエッジに置いて 5Gの価値を高めるため
ストリーミングや AR(拡張現実)/VR (仮想現実) など、映像と情報を組み合わせた大容量のデータを遅延なく配信したいというニーズ
が AWS ユーザーより多数寄せられていた（5G
ネットワークインフラ
整備ニーズへの対応）



Microsoft Azure の取り組み
Azure は大容量高速通信や低遅延性能を求めるビジネスに向け 5G を活用する傾向がある。また、自社の強みである AR/MR を活かしたソリューションの提供を進めている。
表 2.1.3-3 Microsoft Azure の 5G に関する取り組み
5G に関する取り組み狙い概要
事例
エッジコンピューティングデ Azure Stack Edge
5G の大容量高速通信及バイスの提供び低遅延性を活かしたサービス及び環境の一ネットワーク機能管理、マー Azure Network Function
括提供
ケットプレイスの提供
Manager
リアルタイム通信が要
大容量設計データを Azure で Azure Remote Rendering
求される工業自動化
リアルタイムレンダリング、

大容量高速通信が必要
HoloLens 2(MR ゴーグル)にとなる AR/MR への 3D デストリーミングータのストリーミング
Teams と MR を統合した遠隔Microsoft Dynamics 365
指示・共同作業の実施

コンピューティング、ネット
ワーク、アプリケーションをまとめてクラウドから管理
通信事業者向けの AI を利用した運用の自動化

Remote Assist
 東京の指導医が大阪の若手歯科医を支援（ソフトバンク、大阪市の歯科医院が実施）
Azure Private Multi Access
Edge Computing
Azure for Operators

AT&T のコアネットワー
クを Azure forOperators 上で稼働

24

IBM Cloud の取り組み
IBM は仮想化基盤の統合管理や 5G 向け産業アプリ・ソリューションの開発のためのクラウド環境の提供を進めていることがわかる。
表 2.1.3-4 IBM Cloud の 5G に関する取り組み
5G に関する取り組み
狙い
概要
事例
ハイブリッドクラウドプラッ AT&T[米国の電話電信会社]と  5G 時代において、IBM
Cloud Satellite を活用
提携
トフォーム「IBM Cloud
した、ハイブリッドクラ
Satellite」を 5G ネットワー  様々な環境で実行されてウド・ソリューションでいるアプリを、実行場所
ク経由で利用可能とするための仮想化基盤の統合管理に関わらず監視するために、電話電信事業者と提携を実現するための「IBM Cloud 5G 向け産業アプリ・ソリ
Satellite」に関して、
ューションの開発・提供
AT&T の 5G ネットワークのためのクラウド環境を経由で利用できるよう協提供するため力
 規制への厳格な準拠が求められている業界の顧客に対して 5G の力をもたらし、ユーザーエクスペ
リエンスの向上や、新たな収益源の発掘、プロセスの最適化が実現される
想定
複数のサードパーティーベン
5G ネットワーク事業者をタ
ダー製品（5G 向け産業アプーゲットとした「IBM Cloudfor Telecommunications」を リ）をあらかじめ統合・サポート。パートナー企業はオー
提供
プンなハイブリッドクラウド
 「Red Hat OpenShift」「IBM Edge Application 上でエコシステムを構築する
 セキュリティ、コンピュManager」「IBM Cloudーティング、およびサー
Pak for Watson AIOps」
ビス・プロバイダー・ソなどの複数の IBM サービ
リューションを提供（シスを編成・リパッケージスコ）したもの
 ネットワーク・リソースの課金およびマネタイゼーションのための高性能
ネットワーク・アプリケーションを提供
（MATRIXX Software）

25

------------------------------------------------------参考資料[3-1]ゼネラル・エレクトリック社(GE)の失敗から学ぶデジタル・トランスフォーメーシ
ョン | 株式会社アーテリジェンス | Artelligence<https://www.artelligence.jp/blog-posts/general-electric-dx>[3-2]MindSphere | Siemens Software<https://www.plm.automation.siemens.com/global/ja/products/mindsphere/>[3-3]エッジからクラウドまでを更に連携させ、デジタルとリアルを繋ぐ シーメンス
MindSphere | IoT NEWS <https://iotnews.jp/archives/160352>[3-4]SAP Cloud Platform | PaaS & アプリの開発 | SAP<https://www.sap.com/japan/products/cloud-platform.html>[3-5]SAP Cloud Platform の基礎知識！機能やメリットを解説 | クラウド ERP 実践ポータル <https://www.clouderp.jp/blog/functions-and-benefits-sap-cloud-platform>[3-6]SAP Leonardo とは | GSLs コラム | NTT データ グローバルソリューションズ<https://www.nttdata-gsl.co.jp/related/column/what-is-leonardo.html>[3-7]AWS IoT の仕組み - AWS IoT Core
<https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/aws-iot-how-itworks.html>[3-8]Azure IoT - モノのインターネット プラットフォーム | Microsoft Azure<https://azure.microsoft.com/ja-jp/overview/iot/#solution-architectures>[3-9]ThingWorx: IIoT Platform Built to Drive Industrial Innovation | PTC<https://www.ptc.com/ja/products/thingworx>[3-10]PTC とロックウェル･オートメーションは戦略的提携を延長 | PTC<https://www.ptc.com/ja/news/2020/ptc-rockwell-automation-extend-strategicalliance>[3-11]PTC が Microsoft との提携により顧客の IoT のデジタル変革を加速 | PTC<https://www.ptc.com/ja/news/2018/ptc-partners-with-microsoft-to-help-customersaccelerate-their-digital-transformations-in-iot>[3-12]HUAWEI CLOUD がクラウド+ AI + 5G + IoT を通じてグローバル市場で地歩を築く |HUAWEI CLOUD のプレスリリース | 共同通信 PR ワイヤー
<https://kyodonewsprwire.jp/release/201909231163>[3-13]FIELD system - IoT - 商品紹介 - ファナック株式会社<https://www.fanuc.co.jp/ja/product/field/index.html>[3-14]FIELD system について - FIELD system - ファナック株式会社<https://www.fanuc.co.jp/ja/product/field/overview.html>[3-15]FA-IT 統合ソリューション e-F@ctory | ソリューション・事例 | 三菱電機 FA<https://www.mitsubishielectric.co.jp/fa/sols/index.html>[3-16]Edgecross 対応ソフトウェア | 三菱電機 FA<https://www.mitsubishielectric.co.jp/fa/products/edge/edgsw/index.html>[3-17]コマツが仕掛ける、IoT プラットフォーム「LANDLOG（ランドログ）」。その思惑と、
スマートコンストラクションの現状 －コマツ 四家氏インタビュー | IoT NEWS<https://iotnews.jp/archives/63894>[3-18]ランドログとは｜ランドログ（LANDLOG）<https://www.landlog.info/about/>[3-19]モノのインターネット - 日本 | IBM <https://www.ibm.com/jpja/cloud/internet-of-things>
26

[3-20]IBM、Red Hat OpenShift をプラットフォームに導入<https://www.redhat.com/ja/ibm-is-bringing-red-hat-openshift-to-its-platformsja>[3-21]インダストリー4.0 の世界を容易に、ドイツ発ベンチャーが描く工作機械のスマホ
化：JIMTOF2016 - MONOist<https://monoist.itmedia.co.jp/mn/articles/1612/07/news049.html>[3-22]ドイツの工作機械メーカー発の IoT プラットフォーム「AXOOM」で始める”ものづくり”の改革 ー株式会社エフエーサービス 麻生氏インタビュー | IoT NEWS<https://iotnews.jp/archives/59808#%E3%82%A4%E3%83%B3%E3%83%80%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC40%E3%81%AB%E5%AE%8C%E5%85%A8%E5%AF%BE%E5%BF%9C%E3%81%97%E3%81%9FIoT%E3%83%97%E3%83%A9%E3%83%83%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%E
3%80%8CAXOOM%EF%BC%88%E3%82%A2%E3%82%AF%E3%82%B9%E3%83%BC%E3%83%A0%EF%BC%89%E3%8
0%8D>[3-23] IoT プラットフォームとは何か？ 正しい選択をするためのたった 1 枚のスライド｜ビジネス+IT <https://www.sbbit.jp/article/cont1/33530>

2.1.4 5SSC のサービスコンセプト案のまとめ
前章までの調査結果をもとに、5G の特徴である大容量、低遅延、多数同時接続を活用し、企業に役に立てるサービスとは何かを主眼に、コアになると思われる機能を分解して、以下の 5 つのサービスコンセプトに整理した。
①5G 活用インフラの紹介支援
5G インフラレイヤーは、各社が 5G の特徴を最大化させるべくネットワークやクラウド、
エッジ環境の整備を実施しており、Cloud 提供事業者も様々なサービスを順次投入している。
一方で、提供サービスが多様化していることもあり、企業が構築するシステムに必要なイ
ンフラと Cloud を選定し、検討をするのは難しい点が挙げられる。この点が支援になると考えられる。
②5G 活用アプリケーション開発の支援
5G 活用アプリケーション開発が効率的に各企業に合わせて柔軟に行えるために、開発実施企業からライセンスを供与いただくことで流通させることが可能と考えられる。
③エコシステム/連携標準の提供
企業でのアプリケーション開発時に、他社の開発したサービスと連携を取れるようにし、オープンな共有ルールや標準を提供すれば、アプリケーション利用の活性化につながると考えられる。
④疑問解決型コンサルティングの提供
5G を活用することに興味を持った企業に対して、基本となるユースケースから、実際に導入の計画までの疑問の解決に対してガイドやコンサルティングを提供することで、5G ソ
リューション活用企業が増えると考えられる。
⑤特化型ソリューション提供及びコミュニティ形成支援
産業を超えて活用できる「業務単位」や、画像処理などの「機能単位」でのアプリケーシ
ョン提供を行い、利用企業への個別要望に対応することが可能になると考えられる。
27

表 2.1.4-1

調査結果をもとにしたサービスコンセプトの整理

2.2 5GSC のサービスコンセプト案
前項で整理した 5 つのサービスコンセプト案について、サービスコンセプトと提供機能、ビジネスモデルを詳細に検討した。
以下に、後述でのビジネスモデルの凡例を記載する。

図 2.2-1

2.2.1

ビジネスモデル凡例

5G 活用インフラの紹介支援

5G を活用する多数のアプリケーションに対応可能な 5G 活用インフラを紹介するサービス。

28

サービスコンセプト

クラウドや AI エンジンなどのインフラを提供する企業の紹介を行う。

インフラ提供企業の紹介と併せ、5G・IoT のインフラ活用に関するアドバイスを提供する。



5GSC は、事例と提供企業の紹介、アドバイスに特化し、紹介料でサービスを維持す
る。

提供機能


5G 活用インフラの案件事例の紹介



利用企業へのインフラ提供企業の紹介・相談仲介



5G 活用インフラの相談・アドバイス

図 2.2.1-1

サービスコンセプト

想定ビジネスモデル
5G 活用インフラを 5GSC が自ら提供するのでなく、様々な事業者からインフラの情報提供を受け、その相談仲介による手数料を収入とするモデルが想定される（図 2.2.1-2 参照）。
5GSC が公平中立な立場で、通信キャリア、通信機器企業、クラウド事業者等に影響されない、独立した組織として評価し紹介するサービスである。
具体的には、5GSC は、活用企業より 5G 活用インフラに関する相談を受ける。その後、活用企業の情報を、5G キャリア、L5G 提供ベンダー、パブリッククラウドベンダーなどのインフラに関わるベンダーに紹介し、紹介料を 5GSC が受け取る形態のサービスとなる。
活用企業は、5GSC を介して、必須設備、敷設工事、概要設計、などを複数ベンダー各社
より、またはその組み合わせを検討されたベンダーより提案を受ける。
29

特定ベンダーに偏らない比較検討が可能になるといった点が活用企業側のメリットである。
紹介を受ける各ベンダー側のメリットとしては、利用企業の前提、条件などを 5GSC 側
で事前判断し、標準価格等を伝達することで、営業ワークロード削減が期待できる。

図 2.2.1-2

ビジネスモデル

事業計画想定事業想定を行うにあたり想定するユーザーは、必要となるシステム導入実装を計画している企業とした。
5G 関連設備の導入とアプリケーションを Cloud で稼働させたい場合に必要となる想定である。また、アプリケーションの展開を検討している企業が、実装を前に Cloud と 5G を必要としている場合を想定している。
事業想定としては、以下の表 2.2.1-1 の通りである。
表 2.2.1-1
想定される料金体系
顧客想定
必要インフラアプリ開発費想定される必要要員

事業想定（5G 活用インフラの紹介支援）
インフラ初期費用の数％を仲介手数料として取得
5G 関連設備の導入とアプリケーションを Cloud で稼働させたい企業
相談回答の対応可能ツール不要
利用者対応、調査作業

事業成立のポイントは、サービス実行に係る初期費用と、相談/紹介する際の情報・知識の取得である。
コスト面は、Web ツールでの相談対応と調査を実施する人員など、他のモデルに比較して比較的低廉と見込まれる。
5G 活用インフラの紹介に係る相談対応業務が中核であるため、あらかじめ、5G キャリ
ア・ベンダー等の情報を取得しておき、幅広いラインナップと、相談対応能力等を効率的30に構成することなどが必須となる。

2.2.1.1 企業実践例
ヒューレット・パッカード・エンタープライズ（HPE）は、企業のチャレンジを実行する基盤として、HPE DX プラットフォームを提供している（図 2.2.1.1-1 参照）。
主なサービスとして、モバイルデバイスやセンサといった 5G・IoT ソリューション、
HPE 自身の経験に基づくベストプラクティスの提供、Edge to Cloud データパイプラインの設計・構築・運用のトータル支援といった内容を実施している（表 2.2.1.1-1 参照）。
総じて、インフラを適正サイズで利用可能にするためのサービスのポータル展開に焦点を当てており、アプリケーションの提供までは行っていない。
そのため、「クラウドを含めたインフラを利用できる仕組み」としての側面が強いサービスであると言える。

図 2.2.1.1-1 ヒューレット・パッカード・エンタープライズ「HPE DX プラットフォー
ム」概要（出典：HPE DX プラットフォーム < https://www.hpe.com/jp/ja/solutions/dxplatform.html> ）表 2.2.1.1-1 HPE DX プラットフォームの主要サービス
5G・IoT ソリューション
1. モバイルデバイスやセンサ
2. データ・インテリジェント
3. 最先端の通信、5G、Wi-Fi6、IoT 向けの省電力通信の組み合わせ
4. エンドツーエンドデータパイプラインを支える最適なネットワークの構築支援
5. セキュアなネットワークとエッジにおける高度なインテリジェンスを実現
Digital Workplace
6. HPE 自身の経験に基づくベストプラクティスの提供
7. 豊富な導入実績から得たノウハウの提供
8. デバイス、サービス、ネットワークの連携デザイン
31

「Edge to Cloud データパイ
プライン」の設計・構築・運
用

2.2.2

9. データの発生、収集、集約、蓄積、分析のプロセスを精緻化
10. コストパフォーマンスに優れた AI 開発・運用環境を実現
11. 学習モデルの開発と推論環境の運用にかかる工数を最小化

5G 活用アプリケーションの開発の支援

利用企業に対しアプリケーションの開発を実施しやすくする方法を提供するサービス。

サービスコンセプト


企業ごとに異なるニーズに柔軟に対応するため、ソリューションのコアとなるアプ
リケーションを提供する。



利用企業は提供アプリケーションの活用や提供されたアプリケーションの追加開発を行うことで、自社に適した形で 5G 活用アプリケーションを利用することができる。



5GSC は、アプリ提供の利用料金収入によりサービスを維持する。

提供機能 企業ごとに異なるニーズに柔軟に対応するため、ソリューションのコアとなるアプ
リケーションを提供する。
 利用企業は提供アプリケーションの活用や提供されたアプリケーションの追加開発を行うことで、自社に適した形で 5G 活用アプリケーションを利用することができる。

図 2.2.2-1

サービスコンセプト

想定ビジネスモデル
既に開発が完了しているアプリケーションの利用を促進することで、活用企業にとって
32

開発の費用と期間を短くする狙いを持つ。
アプリケーションを提供してもらう企業からライセンスを供与してもらい、活用企業からライセンス利用料金を収集するモデルを想定する（図 2.2.2-2 参照）。
ライセンス料金と、ダウンロードシステムの利用料金を加味し、アプリケーションの利用料金を設定する。
また、ラインナップするアプリケーションに汎用性を持たせることで追加開発による利用企業向けカスタマイズを許容する。
提供側指定企業（L5G 実証事業 SIer など）と利用企業との直接取引により、利用企業に特化したソリューションを実現する。提供側指定企業にとっても新規ビジネスチャンスとなる。
利用企業からの追加開発依頼時に、ライセンス元の L5G 実証事業主体企業等から、L5G実証事業で担当した SIer を紹介いただき、追加の開発が実施される想定で、利用企業
は、対象アプリケーションを開発した SIer から支援を受けることができることはメリッ
トになると想定している。

図 2.2.2-2

ビジネスモデル

事業計画想定想定するユーザーは、アプリケーションの実装活用を検討、計画している企業とした。
5GSC は、アプリケーションの実装活用の内容を確認しながら、対応可能なアプリケー
ションがあるか、追加開発をすれば可能か、などを活用企業とともに検討することを想定している。
開発の期間短縮と相談先を決めかねている企業を主なターゲットとして想定している。
事業想定としては、以下の表 2.2.2-1 の通りである。
表 2.2.2-1
想定される料金体系
顧客想定

事業想定（5G 活用アプリケーション開発の支援）
アプリケーションのライセンス料金
アプリケーションの実装活用を検討、計画している企業
33

必要インフラ想定

カタログ、DL システム、SaaS システム用のプラットフォーム

アプリ開発費

顧客がアプリケーションを実装活用できるようにするために必要となる開発費用

必要人員

運用対応要員、利用者対応要員

事業成立のポイントは、 契約条件、構築運用コスト、相談対応要員のスキルが挙げられる。
ライセンスでの提供条件、バグ対応を含めたメンテナンス活動の実施など提供企業との条件を詰める事が必要となる。
また、アプリケーションの受け渡しや利用を可能にするシステム、DL システムや SaaS
システムなどの構築費用とその運用費用が挙げられる。
サービスのレベルと構築費と運用費は比例するため、実用とのバランスが重要となる。
また、アプリケーションに関する相談対応の要員が必要となる。人員の確保とともに相談に対応できるスキルも必要となる。システム構築、特にプログラミングの知識が必要となる。

2.2.2.1 企業実践例
Siemens は、ソフトウェア、サービス、アプリケーション開発プラットフォームの統合
ポートフォリオとして、「Xcelerator」を提供している（図 2.2.2.1-1 参照）。
ユーザーは Xcelertor を利用することで、現実の機器から送信されるフィードバックを
デジタルモデルに反映し、PLM（製品ライフサイクル管理）を可能にする「デジタルツイン」を実現できる。
また、アプリケーション開発のためのアプローチを自社の事業計画や組織形態、従業員に合わせて柔軟に変更する「カスタム化されたアプローチ」の実行も可能となる。
Siemens のパートナーなどから構成される「オープンなエコシステム」も用意されており、これらを利用することで、ユーザーは効率的にアプリケーションの開発を行うことが
できる。

34

図 2.2.2.1-1

Siemens「Xcelerator」概要（出典：
Siemens Digital Industries Software < https://www.sw.siemens.com/en-US/> ）2.2.3

エコシステム/連携標準の提供

エコシステムや異業種連携のコミュニティ活動を支援するサービス。

サービスコンセプト


利用企業、ソリューション提供企業が開発したアプリケーション、サービスと相互に連携を取れるよう、オープンな共通ルールや標準仕様を策定し、5G を活用するソリューションの普及促進を行う。



活用企業は自社と他社のアプリケーションの連携が可能となり、アプリケーションの適用範囲の拡大につながる。



5GSC は標準化機関として機能し、会員企業からの参加費によってサービスを維持する。

提供機能 サービス・アプリ同士の連携を可能にするための API、オープン共通ルール、連携標
準を用意する。

図 2.2.3-1

サービスコンセプト

想定ビジネスモデル
5GSC が初期のオープンな共有ルールや標準等を立案し、継続してメンテナンスする。
参加する利用企業、提供企業の両方がそれらを活用し、開発を実行することや開発において協業するなど活用する想定である。
費用面に関しては、参画企業から参加費を募り、その範囲で実施することを想定して35

いる。
初期立案に参画していただく専門家等に対し、標準作成に掛かる費用を支払う。また、追加変更を年に一回程度継続して行い、修正を担当いただいた専門家に変更にかかる費用を支払いする想定とする。
オープンな共有ルールや標準の立案を、専門家、ベンダー、SIer に参画いただき検討する。

図 2.2.3-2

ビジネスモデル

事業計画概略
アプリケーションの利用を検討している企業、自社で作成したアプリケーションを他社展開して投資回収を考えている企業を想定ユーザーと見込む。
事業想定は以下の表 2.2.3-1 の通りである。
表 2.2.3-1
想定される料金体系
顧客想定
必要インフラ想定
アプリ開発費
必要人員

事業想定（エコシステム/連携標準の提供）
参加企業から年会費の形態で徴収
アプリケーションの利用を検討している企業
不要
オープンな共有ルールや標準作成に掛かる費用
事務要員

事業成立のポイントは、 標準の具体的内容の範囲と規模の規定である。
実現費用も、初期投資は実際に実施する範囲に連動する。メンテナンスも同様である。加えて、事務的な要員は必要となる想定である。

2.2.3.1 企業実践例
Siemens は、製造業を対象にクラウドベースのオープンな IoT プラットフォームである、「MindSphere」を提供している（図 2.2.3.1-1 参照）。
MindSphere では、デジタルファクトリーをはじめエネルギー管理、スマートシティ、ヘ36ルスケア、風力発電などに至るまで、多彩な分野の多様な IoT デバイスを接続できる環境を提供している。
製造現場の多様なモノ（デバイス機器など）をデジタルの世界と結びつけることが可能となり、ユーザーは、付加価値の高い産業ベースのアプリケーションやデジタルサービスの開発支援、新たなビジネスの展開支援を得ることができる。
また、MindSphere は、AWS（Amazon Web Service）などのクラウドとも連携しており、グローバルなスケーラビリティを提供している。

図 2.2.3.1-1 Siemens「MindSphere」概要（出典：MindSphere3.0 < https://siemens.mindsphere.io/en> ）2.2.4

疑問解決型コンサルティングの提供

利用企業に対し、適正な情報提供、ガイダンス、コンサルティング支援を提供するサービス。

サービスコンセプト


5G 活用手段の検討に行き詰りや導入をあぐねている企業に対して情報提供やコンサ
ルティング支援を行う。



利用企業が 5G を活用するために必要な情報、知識、手法を取得することができ、5G・IoT の利用促進が期待できる。



5GSC は情報提供料、コンサルティング費用によってサービスを維持する。

提供機能

ソリューション活用事例などの情報提供

5G 活用のためのガイダンスの提供



利用企業の個別ニーズに応じたコンサルティングの提供

37図 2.2.4-1

サービスコンセプト

想定ビジネスモデル
情報提供、ガイダンス、コンサルティングの 3 つをサービスの柱とする。
情報提供に関しては、先行経験企業から情報提供を受け、それらを活用企業に利用しや
すいよう検索等の仕組みを作る。
ガイダンスについては、ある程度のガイダンスは事前に用意をし提供するとともに、問い合わせに対応しながら、その内容を充実させる。
コンサルティングに関しては、必要となるコンサル内容を支援できる企業に参画いただ
きコンサルコースを作成・運営する。
ビジネスモデルとしては下記を想定している（図 2.3.4.2-1 参照）。
5GSC を介し、活用企業の要求に応じてそれらの提供を行い、活用企業から利用料金を集金するモデルとなる。
本ビジネスモデルにより、活用企業は、5G を含めたデジタルの知識、手段、情報の取得が可能となり、自社での 5G・デジタルの活用方法を見出すことが可能となる。
また、活用企業を増やすとともに、早期の段階から利用の可能性がある企業とコミュニ
ケーションをとることができ、5G・デジタルの利用促進の観点から重要なアプローチであると言える。

38

図 2.2.4-2

ビジネスモデル

事業計画想定想定する活用企業は、関連の知識を得て 5G の導入を検討してみたい企業、5G を活用してビジネスの変革を検討している企業とした。計画を立てたいがどのように検討すれば良いかわからない企業なども想定している。
事業想定は表 2.2.4-1 の通りとなる。
表 2.2.4-1
想定される料金体系
顧客想定
必要インフラ想定
アプリ開発費
必要人員

事業装置（疑問解決型コンサルティングの提供）
年間の利用料金の徴収
関連の知識を得て 5G の導入を検討してみたい企業、5G を活用してビジネスの変革を検討している企業
Web 会議、LMS、会場用意
コース開発費用、システム構築費用、会場費用など
作業要員、運用要員

事業成立のポイントは、検索などの利用システムとコース開発に関わる初期投資、運用要員の確保である。
検索システムは、可能な限り既存ツールを利用し、開発費用を抑える前提とする。
また、コース開発には相応の投資が必要となる。要望の多いものから実施する計画をたて
投資効率を向上させる必要がある。加えて、作業要員、運用要員を年間継続従事させる必要がある。

2.2.4.1 企業実践例
ベライゾンは、5G の利用促進に向け、「5G プラットフォーム」を提供している。
ホームページ上で、5G に関連する 3 つの知識（アプリケーション、セキュリティ、5G
ネットワーキング）に関するホワイトペーパーを掲載しており、5G を活用するにあたって39

留意すべきそれぞれの詳細な情報を提供している（図 2.2.4.1-1 参照）。
アプリケーションに関しては、リアルタイムのインタラクションとエンゲージメントを可能にする通信速度と帯域幅に関する情報や、5G の接続性とデジタル速度での処理に関する情報が取得できる。
セキュリティについては、セキュリティ確保にあたって考慮すべき重要事項が掲載されている。5G ネットワーキングに関しては、エッジコンピューティングのメリットに焦点を当て、5G の今後の技術の進展が製造業から医療関連までの産業へ与える影響について考察されている。
また、5G 活用の成功事例も掲載されており、それらを通して 5G 評価ワークショップへの参加を促し、ベライゾンのプライベート 5G ソリューションの利用を推奨している（図2.2.4.1-2 参照）。

図 2.2.4.1-1 ベライゾン「5G プラットフォーム」情報掲載例（出典：ベライゾン 5G プラットフォームソリューションとリソース <https://www.verizon.com/business/ja-jp/solutions/5G/first-steps/> ）図 2.2.4.1-2 ベライゾン「5G プラットフォーム」成功事例等掲載例（出典：ベライゾン 5G プラットフォームソリューションとリソース <https://www.verizon.com/business/ja-jp/solutions/5G/first-steps/> ）2.2.5

特化型ソリューション提供及びコミュニティ形成支援業務に特化したアプリケーションの複合的な提供およびコミュニティ形成支援サービス
40

を提供するサービス。

サービスコンセプト
 業界ではなく、業務の特徴に特化した（例：検査業務、監視・セキュリティ、遠隔・共有など）ソリューションを提供する。
 特定業務からのデジタル化を実施できるため、利用企業にとっての導入ハードルの低下が期待できる。
 同様ニーズを抱える利用企業同士のコミュニティ形成やサポート、シェアリング・
サービスを提供することで、5G 活用の活性化を狙う。
 5GSC はアプリケーション提供による利用料金収入によりサービスを維持する。
提供機能

アプリケーションを、音声処理、認証処理など機能単位で提供。（利用企業の目的・要望に応じて組み合わせ提供）

それぞれの業務実現に必要となるハードウェアの提供。

ハードウェア・ソフトウェアリソースのシェアリング提供。



業界横断の業務特化型コミュニティ形成の支援。

図 2.2.5-1

サービスコンセプト

想定ビジネスモデル
活用企業の調査を実施し、ニーズの多い適用業務を「特徴的適用業務」として選定する。
「特徴的適用業務」は、アプリケーション開発の段階でアプリケーションの機能単位のコン
ポーネント型に組み込み、コンポーネント単位で作成準備していき、複数の活用企業に提供する。
また、同時に、類似のニーズを抱える活用企業に対し、提供企業との意見交換の場、立ち上げサポート、シェアリング·サービスの提供も実施する。本ビジネスモデルは、活用企業
41

·提供企業の両社にメリットが存在するモデルといえる。
「特徴的適用業務」を処理できるアプリケーションを 5GSC で抱え、活用企業を複数募り、10 社程度集まれば、アプリケーションを作成することを基本とする。この単位で利用料金を集金する想定である。
開発は、SIer やベンチャー、専業企業にアプリケーション開発を、アプリメーカーにア
プリケーション提供を依頼する。

図 2.2.5-2

ビジネスモデル

事業計画概略
想定するユーザーは、特定の適用業務から 5G の利用を始めることを検討している企
業、同じ適用業務で実施する他企業と連携する企業とする。
活用企業には、類似のニーズを抱える活用企業に対し、意見交換の場、立ち上げサポー
ト、シェアリング·サービスが提供されるため、メリットが多い。
提供企業側も、10 社という最低限のまとまりのユーザーを確保できるため、投資計画が立てやすくなる。
事業想定は表 2.2.5-1 の通りとなる。
表 2.2.5-1 事業想定（特化型ソリューション提供及びコミュニティ形成）想定される料金体系
サービス料金
顧客想定
特定の適用業務から 5G の利用を始めることを検討している企業、同じ適用業務で実施する他企業と連携することを検討している企業など
必要インフラ想定
適用業務アプリケーション用のプラットフォーム
アプリ開発費
アプリケーション開発、更新や変更に関わる費用
必要人員
運用対応要員、活用者対応要員
事業成立のポイントは、 初期投資と更新・運用費用と要員である。
このモデルを実現するためには、初期投資として、適用業務アプリケーションの開発費用、さらに更新に毎年初期の 1/2 相当程度の費用が想定される。加えて、アプリケーショ
42

ンの更新・運用要員、活用者対応要員を準備する必要がある。

2.2.5.1 企業実践例
NVIDIA は、画像診断 AI に特化したプラットフォームである、「AI-on-5G プラットフォーム」を提供している（図 2.2.5.1-1 参照）。
AI-on-5G プラットフォームは、ソフトウェア デファインド 5G vRAN (仮想無線アクセス ネットワーク) のための「NVIDIA Aerial™ SDK」や、エンタープライズ AI アプリケーション (「NVIDIA Isaac™」 や 「NVIDIA Metropolis™」 などの SDK を含む) などから構成されている（図 2.2.5.1-2 参照）。
また、ソリューションがオンプレミスに配備され、企業が自身で管理することも、
Google Cloud のようなハイパースケーラーに管理を任せることも可能という特徴を有する。
ハイパーコンバージド NVIDIA EGX™ コンピューティング プラットフォームとして、
画像処理と AI の活用を可能にする個別活用を前提としたプラットフォームと、活用のコ
ミュニティを形成する狙いがあると考えられる（図 2.2.5.1-3 参照）。

図 2.2.5.1-1 NVIDIA「AI-on-5G プラットフォーム」概要（出典：NVIDIA AI-on 5G プラットフォーム <https://www.nvidia.com/ja-jp/edgecomputing/5G/> ）43

図 2.2.5.1-2 NVIDIA「AI-on-5G プラットフォーム」特徴（出典：NVIDIA AI-on 5G プラットフォーム <https://www.nvidia.com/ja-jp/edgecomputing/5G/> ）図 2.2.5.1-3 NVIDIA「AI-on-5G プラットフォーム」エコシステム（出典：NVIDIA AI-on 5G プラットフォーム <https://www.nvidia.com/ja-jp/edgecomputing/5G/> ）2.3 サービスコンセプト等に対するインタビューの実施
前章で策定した 5 つのサービスコンセプト案に対する客観的意見を求めるべく、有識者、
自治体、ローカル 5G 関係者へのインタビューを実施した。
(1) 5G に知見のある有識者へのインタビュー
44有識者に対して、5GSC の 5 コンセプトに対して、実施主体、実施の難しさ、追加すべきコンセプトなどに関するインタビューを実施した。
(2) 主な府県政令指定市に対するインタビュー
自治体に対して、5GSC の 5 コンセプトを実施した場合に協業/利用可否や課題などに関するインタビューを実施した。
(3) 課題解決型ローカル 5G 等の実現に向けた開発実証事業関係者インタビュー
利用想定企業、インテグレーター、アプリケーションベンダ、通信事業者に対して、
5GSC の 5 コンセプトを前提とした諸ニーズに関するインタビューを実施した。
以下に、それぞれのインタビューの概要及びインタビューの結果のまとめを記載する。

2.3.1 有識者へのインタビュー
2.3.1.1 インタビュー概要
ローカル 5G 等の情報通信システムなどに関する知見やデジタル技術を活用したビジネスモデルに関する知見を持つ有識者の方々を選定し、インタビューを実施した。
実施概要は、以下の通り。（表 2.3.1.1-1 参照）。

実施日時
ヒアリング先ヒアリング内容

実施形式

表 2.3.1.1-1 有識者インタビュー概要
第一回 2022 年 3 月 22 日
第二回 2022 年 3 月 28 日
第一回ヒアリング 東京大学 高木 聡一郎 准教授
第二回ヒアリング 東京大学 中尾彰宏 教授①5GSC 調査検討概要説明②5GSC の構想概要説明③5GSC のコンセプトモデル案およびビジネスモデル案説明④意見聴取(インタビュー)
オンライン会議にて、各回 1 時間ずつで実施

2.3.1.2 インタビュー結果のまとめ
有識者へのインタビューの結果を記載する。(具体内容は表 2.3.1.2-1

有識者インタビュー結果を参照)① 5GSC のサービスコンセプト案について
5 つのサービスコンセプトに基づく想定されるサービスに関して、その他の案の追加を必要とする意見はなかったが、それぞれのコンセプトに対しては、下記の通り 5GSC への45

期待・意見が述べられた。
② 5GSC の運営について
公平・中立な 5G 支援組織の位置付けであることが 5GSC の運営では重要であると述べられた。
また、行政として実施する内容と、それと連動した民間で提供運営するサービスを分担できる体制が必要との意見があった。公平・中立的なプラットフォームと各種支援サービスが提供できる運営体制は望ましいとの結論になった。
表 2.3.1.2-1

有識者インタビュー結果

46

47

2.3.2 自治体へのインタビュー
2.3.2.1

インタビュー概要

全都道府県・政令指定都市へ電話、メールで連絡し、対応可能との回答のあった総計 25
自治体に 5GSC に対してインタビューを実施した。実施概要は、以下の通り。（表 2.3.2.11 参照）。
表 2.3.2.1-1 自治体ヒアリングの実施要領
実施期間2021 年 12 月 20 日～2022 年 2 月 24 日
実施団体（敬称略・順不同） 栃木県、福井県、高知県、神奈川県、埼玉県、大阪府、長崎県、愛知県、宮崎県、新潟県、香川県、佐賀県、宮城県、沖縄県、福島県、愛媛県、島根県、仙台市、福岡市、千葉市、静岡市、堺市、神戸市、京都市、北九州市の計 25 自治体
ヒアリング内容
5GSC 調査検討概要説明
5GSC の構想概要
自治体の 5G/DX 活動の概要
意見聴取(インタビュー)
実施形式
オンライン会議にて、各団体 1 時間ずつで実施

2.3.2.2 インタビュー結果のまとめ
自治体へのインタビューの結果を記載する。(具体内容は表 2.3.2.2-2 自治体インタビ
ュー結果を参照)① 5GSC のサービスコンセプト案について
5 つのサービスコンセプトに基づく想定されるサービスに関して、事例共有や情報提供に関する 5GSC への期待・意見が述べられた。
表 2.3.2.2-2

自治体インタビュー結果

48

2.3.3 令和 3 年度ローカル 5G 実証参画事業者へのインタビュー
総務省が、ローカル 5G のより柔軟な運用の実現及び低廉かつ安心安全なローカル 5G の利活用の実現に向け、令和 2 年度から引き続き実施している、ローカル 5G 等を活用したソリューションを創出する「課題解決型ローカル 5G 等の実現に向けた開発実証」に係る実証事業の令和 3 年度実施企業に対しインタビューを実施した。
2.3.3.1 インタビュー概要
令和 3 年度実証 26 事業の代表企業に対しインタビューを実施した。令和 3 年度実証 26事業の代表企業にアンケート調査への回答を依頼し、24 事業の代表企業より回答が得られた。また、5GSC に興味あり、または参加意向と回答のあった企業に対し、インタビューを実施した。

2.3.3.2 インタビュー結果のまとめ
令和 3 年度ローカル 5G 実証参画事業者へのインタビューの結果を記載する。(具体内容49

は表 2.3.3.2-1

令和 3 年度ローカル 5G 実証参画事業者へのインタビュー結果を参照)① 事業者間連携やソリューション導入の参考情報の紹介・閲覧の期待事業者間や業界間での情報連携や協力関係の構築や 5G アプリケーション・ソリューシ
ョンの利活用事例を一元的に閲覧可能となることなど 5GSC への期待・意見が述べられた。
② 導入・利用コスト低廉化への期待
ローカル 5G 敷設に係るインフラや機器関連コストや 5G ソリューション導入に必要となるソフトウェアコストなどのコスト低廉化に関する 5GSC への期待・意見が述べられた。
③ 技術支援の期待ローカル 5G 設備の調整や保守管理や 5G ソリューションの利活用の専門的な技術支援に関して 5GSC への期待・意見が述べられた。
④ 提供企業におけるソリューション品質の維持、知財保護への課題
企業から提供される 5G ソリューションの知的財産権の担保に関する懸念や提供した 5G
ソリューションの利用規模増加時の運用継続への懸念など 5GSC への課題が述べられた。
表 2.3.3.2-1 令和 3 年度ローカル 5G 実証参画事業者へのインタビュー結果

50

2.3.4 サービスコンセプト等に対するインタビュー結果のまとめ

有識者、自治体、ローカル 5G 関係者へのインタビュー有識者、自治体、ローカル 5G
関係者へのインタビューより、5GSC への期待・意見をまとめたところ、いずれのサービスコンセプトに対しても賛同があった。
特に、ワンストップでたどり着ける環境、企業等連携、安価・多様なアプリ提供環境への要望があった。
表 2.3.4-1

5GSC への期待・意見についてインタビュー結果のまとめ51

2.4 まとめ5GSC サービスコンセプト/ビジネスモデルについて、国内外の状況、インタビュー結果等を元に検討を行った。
サービスコンセプト案の具体化に向けて更なる磨き込みは必要になるものの、現時点における 5GSC のサービス設計やプラットフォーム設計の際に考慮が必要なポイントとして、「ポータル機能」、「コミュニケーション機能」、「アプリケーション提供機能」の３点で整理した。
１．ポータル機能
事例情報や各種ノウハウ情報（標準も含む）を集約し、目的の情報に最短でたどり着ける
サービス/システム設計の検討
２．コミュニケーション機能
各種相談ができる問い合わせ機能、企業連携等が促進できるコミュニケーション機能の検討
３．アプリケーション提供機能
以下を包含したアプリケーション提供方式の検討①

企業単独でアプリ導入をするよりも低コスト且つ効率的に導入できるアプリケーシ
ョン提供方式②

機能単位での組み合わせ等を考慮した多様なアプリケーション提供を意識したプラットフォーム設計

52

3. 提供プラットフォームの検討
3.1 5GSC のプラットフォームに求められる要件
3.1.1 基本的な考え方
5G 活用ソリューションを容易に共用・提供できる環境を展開するにあたって、クラウドの活用は有力な手段である。
プラットフォームは、産業用ソリューションが多様なデバイスや AI などと組み合わせて実現されることを考慮しつつ、5G ネットワークの特性を最大限に活かすユースケース、構成、利用方法を提供、ガイドすることが重要である。
（1）5G アプリを容易に共用・提供できる環境
5G 普及期を迎え、その特性である大容量、低遅延、多数同時接続やそれを支える MEC、SA 等の技術により、今後、5G を活用した産業用ソリューションの創出・展開が期待される。
こうした 5G 産業用ソリューションを広く展開しようとする場合、同じソリューションの複数地域等での展開が考えられ、スクラッチ開発でなく、容易に共用し、提供できる環境の整備が重要と考えられる。
ソリューションの中核となる各種アプリケーションの共用方法として、クラウドの活用は有力な手段であるが、クラウド環境においてソリューションを展開する場合、前述の 5Gの特性を活かした形での提供が重要となってくる。

（2）5G 特性を活用したプラットフォームのあり方
5G の特性を活かしたクラウドサービスの実現においては、通信事業者が通信サービスの提供をするのみならず、通信とクラウドとの連携が重要と考えられる。諸外国でも、クラウド事業者が通信事業者と組んで取り組む例が見られている。
5G 利用を前提としたクラウドを提供する際、5G の特性をいかに活用していくか、ユース
ケース、クラウド構成（プライベートクラウド／パブリッククラウド）、コンテナ化によるダウンロード、MEC の活用等を含めて考える必要がある。
産業用ソリューションは、多様なデバイス（例：カメラ、センサー）や AI 等と組み合わせて実現されるものが多い。こうした点も加味しつつ、適切な形態を、利用者側で選択しやすいような形でアプリが提供され、情報提供がなされることが重要である。
3.1.2 5GSC の提供方式の検討
クラウドにおけるアプリケーション提供方式には、図 3.1.2-1 に示すように「IaaS」「CaaS」「PaaS」「SaaS」の 4 パターンが考えられ、それぞれには表 3.1.2-1 に示すような特徴がある。

53

図 3.1.2-1 クラウドにおけるアプリケーション提供パターン
出典：https://www.slideshare.net/jelastic/multicloud-lightweight-platform-as-aservice

表 3.1.2-1

クラウドにおけるアプリケーション提供パターンの特徴分析※CaaS、PaaS は Runtime の有無で違いがあるが、ここでは DL 型として整理。

・ IaaS 型は、カスタマイズの自由度が高いが、OS 選定や詳細な環境設計が必要となり、利用者側に求める IT スキルも高く 5G 活用ソリューションを広く展開していくためには選択が難しい。
・ SaaS 型は、利用者側で用意する環境が少なく導入の容易性は高い。また、システムの維持、運用もプラットフォーム側で行うため利用者側に求める IT スキルは高くない。しかし、カスタマイズの自由度が低く、利用方法の調整が必要となる今年度の実証での採用は難しい。
・ 今年度の実証では、映像をリアルタイムに AI 判定するソリューションを実施対象としていることから、5G ネットワークの低遅延性を活かしつつ、要件によってアプリ
ケーションを柔軟にカスタマイズでき、導入の容易性も高い DL 型での検討を行うこ
ととした。

54

3.1.3 DL 型プラットフォームに求められる機能
DL 型でソリューションを利用者に提供する場合に 5GSC として具備するべき機能に関して、「ポータル」、「アプリケーション提供」、「課金」、「利用者提供者コミュニケーシ
ョン」のカテゴリに分けて、必要となる機能を検討し、整理した。
(1)「ポータル」のカテゴリには、「認証・認可」、「アカウント管理」、「組織管理」、「ソリューションカタログ」、「ソリューションカタログ」、「ソリューション料金マスタ」、「事例検索」の各機能が含まれる。以下、それぞれの機能の概要を記載する。
・認証・認可機能：
サイトの利用者の認証、利用機能を認可する機能
・アカウント管理機能：
サイトの利用者のアカウントを管理する機能
・組織管理機能：サイトを利用する組織を管理する機能
・ソリューションカタログ機能：
利用可能なソリューションのカタログを表示する機能
・ソリューション料金マスタ機能：
カタログにあるソリューションを利用する際の料金プランを管理する機能
・事例検索機能：
カタログにあるソリューションを利用した事例を検索する機能(2)「アプリケーション提供」のカテゴリには、「レポジトリ」、「アプリアップロード」、「アプリダウンロード」の各機能が含まれる。以下、それぞれの機能の概要を記載する。
・レポジトリ機能：
アプリケーションを保管するレポジトリ機能
・アプリアップロード機能：
アプリケーション提供者がアプリケーションをアップロードする機能
・アプリケーションダウンロード機能：
サイトの利用者がアプリケーションをダウンロードする機能(3)「課金」のカテゴリには、「契約管理」、「実績収集」、「利用料計算」の各機能が含まれる。以下、それぞれの機能の概要を記載する。
・契約管理機能：ソリューションの利用開始に伴う契約情報の管理を行う機能
・実績収集機能：ソリューションを利用する際の料金プランが従量課金制の場合に、従量課金での利用実績を収集する機能
・利用料金計算機能：
55

料金プラン、利用期間などから利用料金を算出する機能(4)「利用者提供者コミュニケーション」のカテゴリには、「問い合わせ」、「利用者・提供者コミュニケーション」の各機能が含まれる。以下、それぞれの機能の概要を記載する。
・問い合わせ機能：
ソリューションの導入や利用方法に関して、利用者がソリューション提供者及び 5GSC へ問い合わせる機能
・利用者・提供者コミュニケーション機能：
掲示板やチャット等により、利用者とソリューション提供者との間でコミュニケーションが図れるようにする機能
表 3.1.3-1

DL 型 5GSC プラットフォームに求められる機能

3.1.3.1 想定業務フロー
5GSC として具備するべき機能において想定される主な業務フローに関して検討を行った。
（1）ポータル機能の業務フロー
ポータル機能における主な業務フローとしては、ソリューション提供者/利用者の新規登録、サイト利用の認証・認可、ソリューションカタログや事例の検索などがある。

56

図 3.1.3-1

提供者・利用者の新規登録フロー

図 3.1.3-2

認証・認可フロー（2）アプリケーション提供機能の業務フロー
アプリケーション提供機能における主な業務フローとしては、ソリューション提供者によるソリューションの登録・更新・削除、ソリューション利用者によるソリューションの検索、利用などがある。

57

図 3.1.3.1-3

ソリューション登録・更新・削除フロー（3）ソリューション利用者によるアプリケーションの利用
ソリューション利用者がアプリケーションを利用する場合、アプリケーションマーケッ
トプレイスのカタログ画面より目的のソリューションを検索、選択しダウンロードを行う。

図 3.1.3.1-4 ソリューション利用者によるアプリ利用

58

3.1.4 プラットフォームを実現するアーキテクチャ（1）アーキテクチャー概要
前項における検討及び整理を踏まえ、5GSC を実現するアーキテクチャ全容を図 3.1.4-1のように定義した上で、今年度の実証においては、４つのカテゴリのうち、DL 型提供におけるアプリケーションの実行とその評価を実施するため必要となる、「ポータル」「アプリ
ケーション提供」の２つのカテゴリにおける諸機能を構成することとした。
5GSC プラットフォームを実現するアーキテクチャ構築のうち、今年度実施範囲は図
3.1.4-1 の赤枠で囲った部分である。

図 3.1.4-1

5GSC プラットフォームのアーキテクチャ概要

・ 「ポータル」については、プラットフォームと提供者／利用者のタッチポイントとなるカタログサイトを構成し、「認証・認可」、「アカウント管理」、「組織管理」、「ソ
リューションカタログ」、「ソリューションカタログ」、「ソリューション料金マスタ」、「事例検索」の各機能を実装した。
・ 「アプリケーション提供」については、DL 型では、提供者がアップロードしたアプ
リケーションを利用者が用意した環境にダウンロードして稼働させるのに、提供者と利用者の間でダウンロードを実現するためのレポジトリサービスが必要となるので、アップロード機能及びダウンロード機能と共にレポジトリ機能を実装した。
・ 「課金」、「利用者提供者コミュニケーション」の各機能については、今年度の実証実施企業が一社のため、実装していないが、将来これらの機能を追加で開発することを考慮した設計としておく必要がある。

（2）カタログサイトの検討
ソリューション利用者がアプリケーションを選択し利用するためには、アプリケーションの有用性を理解しやすいようガイドすることが求められる。そのため、利活用事例を効率的に閲覧し、ソリューション、アプリケーションの選択を容易にするためのカタログサイト
59

を 5GSC のポータルサイトに配置する。
本実証では、ローカル 5G 実証事業の事業内容を掲載するサイトとして構成を検討した。
開発においては、特定の製品/ベンダーに極力依存しないようにするため開発言語にJava/Javascript を用いた。

（3）アプリケーション提供方式の検討
提供者から提供されるアプリケーションはどの利用者においても利用できることが望まれるが、一方で利用者のエッジサイトは多様であり、すべての環境にアプリケーションを対応させることは提供者の負担が大きくなり、ソリューション普及の弊害になり得る。また、
アプリケーションの利用条件に合わせて利用者が各々に環境を準備することは、利用者の負担となり、ソリューション利用の弊害となる。
アプリケーションを効率的に展開する方式として、提供者はある一定の共通環境を前提としたアプリケーションを作成し、前提条件の統一を図ることで、利用者と提供者の双方の負担が軽減できると考える。
具体的には「コンテナ技術」や「ハイパーバイザー型仮想化ソフトウェア」を使用して、アプリケーションに高い可搬性を持たせることが重要となる。
本実証においては、利用者への環境依存度がより軽微なコンテナ技術を採用する。
「ハイパーバイザー型仮想化ソフトウェア」の利用においては、ソフトウェアの導入やライブラリ、フレームワークの設定など利用者側で用意しなければならない条件が多く、提供者側もそれら条件にアプリケーションを対応させなければならないため、提供者側、利用者
側共に環境準備のための負荷が高い。
一方、コンテナ技術を利用した場合、提供者はソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化する。これによって環境やインフラストラクチャ、オペレーティングシステムに依存することなく
アプリケーションを提供することが可能となる。
また、利用者はコンテナを動作させるためのコンテナ実行環境を用意することでソリューションを実行することが可能となる。
コンテナのアプリケーションを効率良く管理・運用していくためには、コンテナオーケス
トレーションが必要となる。完全なオープンソース・ソフトウェアを採用するという観点では、コンテナオーケストレーションの代表である Kubernetes の活用による方法も考えられるが利用者がサポートなしに運用することは困難である。
本実証においては、Kubernetes 同様にオープンソースでのエンタープライズ向けコンテ
ナ・オーケストレーション・プラットフォームであり、プラットフォームのサポートを受けることが可能、且つセキュリティなどの機能が拡張された「OpenShift」環境によるコンテ
ナ実行環境を採用した。
また、利用者環境へのコンテナ実行環境の構築をサポートすることでソリューションの普及が見込まれる。IBM Cloud Satellite はエッジサイトに用意した環境にコンテナ実行環
境を用意することをサポートすることができる。本年度の実証検証においても IBM Cloud
Satellite を採用し、エッジサイトへのコンテナ実行環境の展開も見据えた検証を行うことした。
60

（4）レポジトリサービスの検討
提供者が開発したコンテナのアプリケーションを利用者がダウンロードするために、レポジトリサービスが必要となる。レポジトリサービスには、DockerHub や各クラウド事業者
によって用意されたものがあるが、本実証ではフロント機能との連携を考慮し、オープンソースで広く技術が普及し柔軟な API をもっている GitLab を採用した。

3.2 プラットフォーム実証環境・システム構成の定義
3.2.1 前提条件
前項で記載したように、5GSC を実現するアーキテクチャ全容のうち、DL 型提供におけるアプリケーションの実行とその評価の早期実施を目標とし、最低限必要となる基本機能としてカタログサイト、レポジトリサービスに関する機能の開発・検証を行うためのシステム構成とした。また、システム構成を検討するうえでプラットフォームについては、オープン
ソースや汎用的な技術を利用して本環境を構成することとした。
本実証におけるシステム構成に関しては、「ベンダー・キャリアフリー」、「サイバーセキ
ュリティ」、「サプライチェーンリスク」、「柔軟な拡張性」の各観点から検討し、システムを選定するようにした。以下、それぞれの観点の内容を記載する。
・ベンダー・キャリアフリー：
特定のベンダーやキャリアに縛られることなく、汎用的な技術やオープンソース技術を活用し、実証システム環境を構築すること。
・サイバーセキュリティ：サイバーセキュリティを確保するために、各コンポーネントにてアクセス制御/権限設定を適切に行うこと。
・サプライチェーンリスク：
輸出規制等の影響を受け、それを使ったシステム構築の不可や遅延等の可能性の無いクラウドサービスを実証システムの基盤として選定すること。
・柔軟な拡張性：初期検証に必要な最低限の資源の提供から、商用リリースを見据えた高い運用要件の充足までといったように、段階的に拡張できる柔軟性を持った基盤を選定すること。
上記の観点で検討し、選定したシステムを表 3.2-1 に、また、選定したシステムを使った本実証の 5GSC プラットフォームシステム構成を図 3.2-1 に示す。
表 3.2.1-1

本実証におけるシステム構成の検討ポイント及び選定したシステム

61

図 3.2-1 選定したシステムを使った本実証の 5GSC プラットフォームシステム構成

3.2.2 インフラ構成
本実証環境のシステム詳細構成を図 3.2.2-1 へ示す。
IBM Cloud および Enterprise Cloud を利用し、実証環境を構築した。
IBM Cloud 上ではリソース管理サービスを利用し、Enterprise Cloud 環境のリソースの62操作/管理を行う。
Enterprise Cloud 上ではアプリケーションの稼働に必要なリソースを稼働させる基盤として OpenShift Container Platform(OCP)を作成した。OCP をプラットフォームに利用することで他クラウドサービス上にも同様のサービスを展開可能であり可搬性に優れたアプ
リケーション基盤を展開・運用することが可能となる。
また、サイバーセキュリティ対策を施すため、各コンポーネントにてアクセス制御/権限
設定を適切に行う。サプライチェーンリスクを考慮し、輸出規制等の影響を受ける可能性の無いクラウドサービスを選定した。

図 3.2.2-1 5GSC システム詳細構成（1）リソース管理サービス
利用するリソース管理サービス一覧を表 3.2.2-1 クラウドサービス構成へ示す。
サイバーセキュリティ対策として、クラウド上の IAM 機能を利用し、管理者に必要な最小限の権限を付与し、アクセス制御を実施した。
表 3.2.2-1 クラウドサービス構成
スペック
用途

構成機器
IBM Cloud Satellite-

OCP の作成/管理

IBM Cloud Object Storage-

IBM Cloud Satellite 設定保存領域

IBM Cloud Monitoring with
Sysdig

段階課金制

OCP の監視用メトリクス収集

IBM Log
LogDNA

30 日間保存

OCP の監視用ログ収集

Analysis

with※OCP：OpenShift Container Platform63

図 3.2.2-2 5GSC システム構成（IBM Cloud）
IBM Cloud SatelliteEnterprise Cloud 上の仮想マシンへ役割(コントロール・プレーン/ワーカーノード)を割り当て、OpenShift Container Platform(以下、OCP)環境を構築した。各仮想マシンの状態、OCP の状態を管理する。
IBM Cloud Object Storage
IBM Cloud Satellite の定義情報を保存する。
IBM Cloud Monitoring with Sysdig
OCP 内の各ノード、稼働しているミドルウェアなどのメトリクス情報を収集する。
ダッシュボードにより OS から稼働中のプロセスの様々なメトリクス情報を得ることができ、パフォーマンスの分析、異常発生時のアラート通知機能が提供される。
IBM Log Analysis with LogDNA
OCP 内にて発生するアプリケーション、システム、およびサービスのログを収集する。
ダッシュボードによりログ・データのフィルタリング、検索、およびアラート通知の定義、アプリケーションとシステムのログをモニタするカスタム・ビュー機能が提供される。

（2）ネットワーク構成
本実証におけるクラウドのネットワーク構成、ネットワーク機器のスペックおよび、それぞれの機器の用途に関して表 3.2.2-2 ネットワーク構成へ示す。

構成機器
InternetGateway

表 3.2.2-2 ネットワーク構成
スペック
用途
100Mbps 帯域保障
Internet 接続用
64

Firewall(vSRX)

2CPU/4GB Mem

LoadBalancer(NetScaler)

2CPU/8GB Mem

・パブリック IP アドレスの払い出し
・Internet/ECL 内部 NW 間における不正アクセ
スの遮断
・構成機器へのルーティング
・パブリック IP アドレスからプライベート IP
アドレスへの NAT・Master#1-3 への負荷分散
・Worker#1-3 への負荷分散① Firewall によるアクセス制御
サイバーセキュリティ対策として、FireWall 機能を利用し、必要以外の通信は遮断することで特定のサービスのみにアクセスできるよう設定する。

図 3.2.2-3 ネットワーク構成（Firewall）

NAT 設定パブリック IP アドレスとプライベート IP アドレスを 1 対 1 で NAT することでInternet から各機器への接続を実施する。対象 IP アドレスは以下とする。
・LoadBalancer(NetScaler)・Master#1-3
・Worker#1-3
・踏み台管理 SVR(linux)
・踏み台管理 SVR(windows)
アクセス制御各機器へのアクセスを制御し、セキュリティを高める。
プロトコルは ICMP,HTTPS,SSH,RDP のみ許可する。
アクセス制御は送信元 IP アドレス、宛先 IP アドレス、宛先ポート番号を利用する。
② LoadBalancer による負荷分散
65

各ノードの負荷分散とサービス継続性確保のため LoadBalancer による負荷分散構成とした。

図 3.2.2-4 ネットワーク構成（Loadbalancer）
負荷分散：Master
OCP のコントロール・プレーンである Master ノードを 3 台に対して負荷を分散することで性能低下を防ぎ、ノードダウン時においてもサービス継続を維持する。
負荷分散方式としてはラウンドロビンを利用し、各ノードに対してリクエストを順番に振り分けることとする。
負荷分散：Worker
OCP のワーカー・ノードである Worker ノードを 3 台に対して負荷を分散することで性能低下を防ぎ、ノードダウン時においてもサービス継続を維持する。
負荷分散方式としてはラウンドロビンを利用し、各ノードに対してリクエストを順番に振り分けることとする。

（3）サーバ
サーバ機器のスペックおよび用途に関して表 3.2.2-3 サーバ構成へ示す。

構成機器
Master#1
Master#2
Master#3
Worker#1
Worker#2
Worker#3
踏み台管理 SVR
(linux)

表 3.2.2-3 サーバ構成
スペック
用途
4CPU/16GB MemOCP のコントロール・プレーン
4CPU/16GB Mem
上記同様
4CPU/16GB Mem
上記同様
4CPU/16GB MemOCP のワーカー・ノード
4CPU/16GB Mem
上記同様
4CPU/16GB Mem
上記同様
2CPU/4GB Mem
・OCP 構築時の作業端末
・OCP 操作端末
66

踏み台管理 SVR(Windows)

2CPU/8GB Mem

・OCP 管理コンソール接続
・GitLab 管理コンソール接続

FileStorage(NFS)

VolumeSize:1024GB

OCP 内で稼働するサービスのデータ保存領域

図 3.2.2-5 クラウドリソース構成（Master/Worker/FileStorage）① サーバリソース
各サーバリソースの役割と台数構成は以下のとおり。
サイバーセキュリティ対策として、サーバ機器へアクセスする際は root(管理者権限)
ユーザーでのログインを不可とし、各サーバへのアクセスするポートを標準設定から変更することによって不正アクセスを防止する。
Master
OCP の制御を担うコントロール・プレーンとして利用する。
Master ホストの台数を OCP のコントロール・プレーン最小台数要件である 3 台とし、冗長構成をとる。
Worker
OCP 上で稼働するミドルウェア/アプリケーションを配置する先として利用する。
Worker ホストの台数を OCP のワーカー・ノード最小台数要件である 3 台とし、冗長構成をとる。
FileStorage(NFS)
OCP 上で稼働するミドルウェア/アプリケーションのデータ保存領域として利用する。
② 踏み台管理サーバ
各サーバの構築・管理・メンテナンスを安全に実施するため、外部からの接続用の踏み台サーバを設ける。
67

図 3.2.2-6 クラウドリソース構成（踏み台管理 SVR）
踏み台管理 SVR(linux)
IBM Cloud Satellite を利用した OCP 構築・メンテナンス時の作業用端末として利用する。
OCP 構築完了後の操作/メンテナンス用として利用する。
踏み台管理 SVR(linux)へはセキュリティ確保の観点から ssh を利用しアクセスする。
踏み台管理 SVR(windows)
OCP の WEB 管理コンソールおよび GitLab の WEB 管理コンソールにブラウザ接続する際に利用する。踏み台管理 SVR(windows)へは Remote Desktop Protocol を利用しアクセスする。

（4）ミドルウェア
OCP 上にて稼働させるミドルウェアとそれらの用途に関して表 3.2.2-4 ミドルウェア構
成へ示す。

ミドルウェア

表 3.2.2-4 ミドルウェア構成
用途

GitLab

外部向け提供機能・webservice：GitLab 管理コンソール機能
・page：web コンテンツ機能(アプリケーション稼働)
・registry：コンテナイメージレポジトリ機能

Sysdig Agent
LogDNA AgentOCP のメトリクスを IBM Cloud へ転送
OCP のログを IBM Cloud へ転送① 外部向け提供機能68Gitlab にて構成する外部向け提供機能の構成と役割を以下に示す。

図 3.2.2-7 ミドルウェア構成（GitLab サービス）
webservice
GitLab の WEB 管理コンソールサービス機能を提供する。
page
WEB サイトコンテンツの公開機能。アプリケーションを呼び出す。
registry
ソリューションのアップロード、ダウンロード機能を提供する。
② OCP 監視サービス
OCP 内の各ノードの稼働状況の監視および、レポート機能の構成と役割を以下に示す。

図 3.2.2-8 ミドルウェア構成（OCP 監視サービス）
Sysdig Agent
OCP 内の各ノード、稼働しているミドルウェアなどのメトリクス情報を収集し IBM
Cloud Monitoring with Sysdig へ転送する。
69

LogDNA Agent
OCP 内にて発生するアプリケーション、システム、およびサービスのログを収集しIBM Log Analysis with LogDNA へ転送する。
3.2.3

アプリケーション構成

本実証環境におけるアプリケーション構成図を図 3.2.3-1 に示す。

ソリューション利用者

ソリューション提供者

画面（静的部分）

動的部分
docker login
docker push

APIコール
docker login
docker pull

CMS（GitLab）
サイトコンテンツProject

ソリューション／料金プラン
ソリューションProject
ソリューションProject
Project

GitLab Pages
公開サイト

Container Registry

HTML
ファイル

自動ビルド

サイト編集者

デプロイ
HTML
ファイル

Pages
CI Pipeline

Java EE（Open Liberty）
API
Endpoint

コンテナ
イメージ

アクセス
トークン
(提供者)

カタログアプリAPIコール

アクセス
トークン
(利用者)

File Repository

File Repository

HTML
ファイル

添付ファイル

会員登録

利用可能
ソリューション
一覧取得

・・・

・プロジェクト作成
・トークン生成・ファイルアップロード
・ファイルダウンロード

RDB（PostgreSQL）
会員

ソリューション

・・・

Storage

図 3.2.3-1 ダウンロード型実証環境のアプリケーション構成図（1）機能一覧
本実証環境における機能一覧を表 3.2.3-1 に示す。
表 3.2.3-1 機能一覧
No.
1

機能名
会員登録

概要
会員（提供者、利用者）の登録を行う

2
3
4
5

ログイン
会員情報編集退会
ソリューション
一覧照会

6

ソリューション

会員（提供者、利用者）の認証を行う
会員（提供者、利用者）の情報の変更を行う
会員（提供者、利用者）の退会を行う指定された条件のソリューション一覧を照会する想定している条件は下記の通り：•利用者が利用可能•利用者が利用中•提供者が登録済
指定されたソリューション情報を照会する
70

12

情報照会
ソリューション
利用開始
ソリューション
利用終了
ソリューション
登録
ソリューション
情報更新
料金プラン情報更新
料金プラン追加

13

料金プラン削除指定された料金プランとその利用者との紐付きの削除を行う

14

ソリューション
削除
添付ファイルダ
ウンロード
GitLab 用アクセ
ストークン再発
行指定されたソリューションとそれに紐づく料金プランを削除し、その料金プランと利用者との紐付きの削除を行う指定されたファイルのダウンロードを行う

7
8
9
10
11

15
16

指定された料金プランと利用者の紐付けを登録し、GitLab へダ
ウンロード用アクセストークンの発行を行う指定された料金プランと利用者の紐付けを解除し、GitLab へダ
ウンロード用アクセストークンの失効を行う
ソリューションの登録を行う指定されたソリューション情報の更新を行う
指定された料金プラン情報の更新を行う
指定されたソリューションに紐づく料金プランの追加を行う

指定された料金プランに対する指定された権限の GitLab 用ア
クセストークンを作成し、それまで紐付いていたアクセストー
クンの失効処理を行う
想定している権限は下記の通り：
・ダウンロード用（コンテナレジストリへの参照権限のみ）
・登録用（コンテナレジストリへの参照＋更新権限）（2）画面一覧
本実証環境における画面一覧を表 3.2.3-2 に示す。
表 3.2.3-2 画面一覧
No.
1

画面名
SC001_ホーム画面

概要
本実証環境のランディングページ

2SC002_ログイン画面
SC003_会員登録画面SC004_パスワード
再作成画面
SC005_5GSC プラッ
トフォーム紹介画
面

ログイン用の画面

3
4
5

会員登録用の画面
パスワード再作成用の画面
5GSC プラットフォームの紹介画面

71

6
7
8
9
10

11

12
13

14
15

16

17
18
19
20
21
22

SC006_L5G 実 証 事 ローカル 5G ソリューションの導入事例を表示する画面
例画面
SC007_5GDX 情報画 5G/DX 情報画面に関する情報を紹介する画面
面
SC008_業務別ソリ 業務別ソリューションの情報を参照する画面ューション画面SC009_お問い合わ お問い合わせ内容を入力し送信する画面
せ画面
SC101_利用可能ソ 利用可能なソリューションの一覧を表示する画面
リューション一覧
画面SC102_利用可能ソ 利用可能ソリューションの詳細情報を表示する画面
リューション詳細
画面
SC103_料金プラン 利用開始する料金プランを選択する画面
申込画面
SC201_利用中ソリ 利用者が利用中のソリューションの一覧を表示する画面ューション一覧画面
SC202_利用中料金 利用中の料金プランを表示する画面
プラン画面
SC301_登録済ソリ 登録済ソリューションの一覧を表示する画面ューション一覧画面
SC302_登録済ソリ 登録済ソリューションの詳細情報を表示する画面ューション詳細画面
SC303_ソリューシ ソリューションの情報を編集する画面
ョン情報編集画面
SC304_料金プラン 新規作成する料金プランの情報を入力する画面
作成画面
SC305_料金プラン 料金プランの情報を編集する画面
編集画面
SC306_ソリューシ 新規作成するソリューションの情報を入力する画面ョン新規作成画面
SC401_会員情報画 会員情報を表示する画面面
SC402_会員情報編 会員情報を編集する画面
集画面（3）画面遷移図
本実証環境における画面遷移図を図 3.2.3-2 に示す。
72

図 3.2.3-2 画面遷移図（4）データモデル
本実証環境におけるデータモデルを図 3.2.3-3、図 3.2.3-4 に示す。

図 3.2.3-3 ドメインモデル73

図 3.2.3-4 ER 図

3.3 本実証の実施
本実証の実施内容と評価方法、検証内容を以下に記す。
3.3.1 本実証の実施内容と評価方法
3.3.1.1 インフラに関する検証（1）IBM Cloud Satellite を利用した OCP 導入
利用者が準備した環境へ OCP 導入を行う、導入支援を想定し、IBM Cloud Satellite を利用し EnterPrise Cloud 環境への OCP 導入検証を実施した。
EnterPrise Cloud 環境の仮想マシンを登録し、Satellite ロケーションとして定義する。
74

登録した仮想マシンをコントロール・プレーンおよびワーカー・ノードとして定義することで OCP の導入を行う。
以下の手順にて実施した。








構成機器の準備[3.2.2 インフラ構成]に記載の構成機器を準備
Satellite ロケーションの作成
Satellite による管理対象環境をロケーションという名称で定義する。
Satellite ロケーションへ仮想マシンの登録対象ホストにて Satellite 提供のスクリプトを実行し、ロケーションへ仮想マシンを登録する。
コントロール・プレーン割り当て
コントロール・プレーン(OCP を制御するためのマシン)として登録した仮想マシンを割り当てる。
OCP の作成
仮想マシンをワーカー・ノードとして割り当て、OCP クラスタを作成する。

図 3.3.1.1-1 Satellite による OCP 作成（2）OCP 環境の監視
IBM Cloud Satellite を利用し導入した OCP 環境の監視検証を実施した。
IBM Cloud Satellite 上からの状態確認および IBM Cloud のサービスである IBM Cloud
Monitoring with Sysdig(メトリクス監視)および IBM Log Analysis with LogDNA(ログ監視)を利用した監視検証を行った。
以下の手順にて実施した。
IBM Cloud Monitoring with Sysdig インスタンス作成
IBM Log Analysis with LogDNA インスタンス作成
Sysdig Agent のデプロイ
IBM Cloud Monitoring with Sysdig インスタンス提供の Agent を OCP へデプロイする。
LogDNA Agent のデプロイ
IBM Log Analysis with LogDNA インスタンス提供の Agent を OCP へデプロイする。
75

3.3.1.2 「ポータル」、「アプリケーション提供」カテゴリの機能検証
本実証においては、前項で定義したプラットフォーム実証環境の構成を行い、実際の利用シーンを想定して評価項目及び評価方法を策定した。
具体的には、実際の利用シーンの各段階、すなわち「アプリケーションアップロード」、「利用者登録」、「提供者登録」、「アプリケーションダウンロード」、「利用者ログイン及び
アプリケーションダウンロード」、「提供者ログイン及びアプリケーションアップロード」において実施する評価項目及び評価方法である。
(1)「アプリケーションアップロード機能」における評価項目：
本実証環境へのアップロード時の機能の正常性(評価方法)
・アプリケーションをアップロードできる画面が提供されていることを確認する。
・プライベートレポジトリレポジトリを提供し、ソリューションの構成と変更の管理できる画面が提供されていることを確認する。
・プライベートレポジトリへのアクセス制御できることを確認する。
(2)「利用者登録機能」における評価項目：
利用者登録/削除機能の正常性(評価方法)
・画面より利用者の登録/削除ができることを確認する。
・登録/登録外のアクセスユーザーが制御されていることを確認する。
(3)提供者登録機能における評価項目：
提供者登録/削除機能の正常性(評価方法)
・画面より提供者の登録/削除ができることを確認する。
・登録/登録外のアクセスユーザーが制御されていることを確認する。
(4)「アプリケーションダウンロード機能」における評価項目：
DL 型実証環境から本実証環境のソリューションをダウンロードし、展開する際の機能の正常性(評価方法)
・アプリケーションのダウンロードが可能であることを確認する。
・利用者環境にアップロードする上での作業手順を表示する画面が提供されていることを確認する。
(5)「利用者ログイン及びアプリケーションダウンロード機能」における評価項目：
利用者のログイン～検索～アプリケーションダウンロードの完了までの一連の機能の正常性(評価方法)
76

・ログイン/ソリューション検索/ダウンロードがシナリオにそって完遂できることを確認する。
・ログイン画面が提供されていることを確認する。
・ソリューションを一覧表示し、検索可能な画面が提供されていることを確認する。
・ソリューションの詳細表示が可能な画面が提供されていることを確認する。
・利用者がダウンロード手順を確認できる画面が提供されていることを確認する。
・利用者がダウンロードできることを確認する。
(6)「提供ログイン及びアプリケーションダウンロード機能」における評価項目：
提供者のログイン～登録～アップロードの完了までの一連の機能の正常性(評価方法)
・ログイン/ソリューション検索/ダウンロードがシナリオにそって完遂できることを確認する。
・ログイン画面が提供されていることを確認する。
・提供者が登録済みのソリューションを一覧表示する画面が提供されていることを確認する。
・提供者がソリューションを登録可能な画面が提供されていることを確認する。
・提供者がアップロード手順を確認できる画面が提供されていることを確認する。
・提供者がアップロードできることを確認する。
表 3.3.1-1

本実証における実施内容と評価方法

77

3.3.2 本実証の検証内容
3.3.2.1 インフラに関する検証（1）IBM Cloud Satellite を利用した OCP 導入
利用者環境に OCP を作成する想定での導入検証を実施した。
利用者側では本検証における Enterprise Cloud と同等の構成機器を準備することで、コンテナ基盤となる OCP 環境を導入することが可能となる。
また、本実証環境ではクラウド上へ OCP を導入したが、利用者のオンプレミス環境においても同様の手順で導入することができる。

（2）OCP 環境の監視
IBM Cloud の WEB コンソールより Satellite ロケーションの状態および OCP の状態からホストを確認することができる。

図 3.3.2.1-1 ロケーション/OCP のサービス状態

図 3.3.2.1-2 Satellite による各ホストの状態確認
IBM Cloud Monitoring with Sysdig のダッシュボードより OCP 内のメトリクスが集約されていることを確認した。
OS の CPU/メモリ/disk/Network IO
Pod(コンテナ)レベルでの CPU/メモリ/disk/Network IO
Kubernetes リソースごとのパフォーマンス
78

コンテナ内サービスレベルでのパフォーマンス(MongoDB のリクエストカウント数など)

図 3.3.2.1-3 OCP メトリクス収集画面
IBM Log Analysis with LogDNA のダッシュボードより OCP 内のログが集約されていることを確認した。


OS より出力されたログ
Pod(コンテナ)より出力されたログ

図 3.3.2.1-4 OCP ログ収集画面
IBM Cloud Satellite 機能を利用し OCP 環境の導入をすることで、IBM Cloud の WEB コン
ソールより状態の確認およびダッシュボードよりログ、メトリクス監視ができた。
利用者向けに用意した OCP 環境を 5GSC から監視ができるともいえるが、責任分界点等を踏まえ今後の検討が必要となる。

79

3.3.2.2 「ポータル」、「アプリケーション提供」カテゴリの機能検証
本実証においては、構築したプラットフォームの「「ポータル」、「アプリケーション提供」カテゴリの機能における想定業務フローを検討し、プラットフォームの評価・検証対象とする「未登録会員」
、
「利用者」
、
「提供者」のそれぞれについてのユースケースと、3 者に共通するユースケースの動作を確認した。（図 3.3.2.2-1 参照）

図 3.3.2.2-1「ポータル」、「アプリケーション提供」カテゴリの想定業務フロー「未登録会員」については、「未登録会員に対してどのようなサービスが提供されているかを確認する。
」というユースケースを想定して、プラットフォームの評価・検証を行った。
「利用者」については、「利用者として登録し、利用したいサービスを選択し、利用を開始する。利用開始した後、画面表示手順に従いアプリケーションのダウンロードを行
い、サービスの利用を終了する。
」というユースケースを想定して、プラットフォームの評価・検証を行った。
「提供者」については、「提供者として登録し、ソリューション・料金プランの登録を行う。次に画面表示手順に従いアプリ・添付ファイルのアップロードを行って、ソリュー
ション／料金プランのステータスを公開する。」、「ソリューション／料金プランを編集・
公開ステータスを変更する、ソリューション／料金プランを削除する。」というユースケースを想定して、プラットフォームの評価・検証を行った。
3 者に共通するものとして、「自身の会員情報を編集する。」、「パスワードの再発行を行う。
」というユースケースを想定して、プラットフォームの評価・検証を行った。
表 3.3.2.2-1

5GSC プラットフォームの想定ユースケース

80構築したプラットフォームにおいて、上記の表 3.3.2.2-1 に示したユースケースごとに実施した評価・検証内容を下記に示す。
(1) 未登録会員のユースケース：
会員登録をしていないユーザーが 5GSC プラットフォーム実証環境にアクセスした際に、どの様なサービスが提供されているのか確認可能なこと。
・未登録会員であっても「情報ライブラリ画面」で、「令和 3 年度ローカル 5G 開発実証のソリューション一覧」や「ローカル 5G ソリューション導入事例（全体版･概要版）」
を確認することができた。
・「令和 3 年度ローカル 5G 開発実証」のソリューション一覧の画面から、任意のソリューションを押下することで、「利用可能ソリューション詳細画面」を表示し、選択した
ソリューションの名称・ソリューション概要・ソリューション説明等のソリューショ
ン詳細を確認することができた。
未登録会員が 5GSC プラットフォーム実証環境にアクセスした際の「情報ライブラリ画面」、「利用可能ソリューション詳細画面」を図 3.3.2.2-2 及び図 3.3.2.2-3 に示す。

図 3.3.2.2-2

情報ライブラリ画面

81

図 3.3.2.2-3 利用可能ソリューション一覧画面(2) 利用者自身の会員情報編集のユースケース：
登録済みの利用者が自らの会員情報を編集可能なこと。


登録済みの利用者が自身の会員情報を編集したい場合に、「会員情報」リンクを押下すると、「会員情報」画面が表示されることを確認した。

「会員情報」画面で「編集」ボタンを押下すると、現在登録済みの会員情報が表示され、会員情報の修正等ができることを確認した。

会員情報画面を図 3.3.2.2-4 に示す。

図 3.3.2.2-4

ユーザー管理画面(3) 利用者によるアプリケーションダウンロードのユースケース：
登録済みの利用者が利用したいアプリケーションをダウンロードできること。


登録済みの利用者が「情報ライブラリ画面」で確認した、「令和 3 年度ローカル 5G
開発実証のソリューション一覧」や「ローカル 5G ソリューション導入事例（全体版･概要版）」のなかで、興味を持ち、使ってみたいと思ったローカル 5G ソリュー
ションを表示された手順に従いダウンロードできることが確認できた。
82

ソリューション一覧から「令和 3 年度ローカル 5G 開発実証のソリューション」の一つに関するアプリケーションのダウンロード画面を図 3.3.2.2-5 に示す。

図 3.3.2.2-5

アプリダウンロード画面

3.4 検証結果と今後の検討課題
本実証における検証結果と今後の検討課題を以下に記す。
3.4.1 検証結果
今年度の本実証においては、DL 型提供におけるアプリケーションの実行とその評価を実施するため必要となる、「ポータル」「アプリケーション提供」の２つのカテゴリにおける諸機能を構成し、実際の利用シーンの各段階、すなわち「アプリケーションアップ
ロード」、「利用者登録」、「提供者登録」、「アプリケーションダウンロード」、「利用者ログイン及びアプリケーションダウンロード」、「提供者ログイン及びアプリケーションア
ップロード」における評価項目及び評価方法を策定して、検証した。
検証の結果、「ポータル機能」に関しては、利用者が情報を確認し、アプリケーション
をダウンロードし、自身の環境で実行できることを確認した。
また、「アプリケーション提供機能」に関しては、クラウドに提供者からアプリケーシ
ョンをアップロードできること及び、利用者環境へダウンロード、アプリケーションを展開できることを確認した。

83

図 3.4.1-1 5GSC「ポータル機能」「アプリケーション提供機能」検証

3.4.2 今後の課題
前項のとおり、本実証において、DL 型提供におけるアプリケーションの実行とその評価を実施するため必要となる、所定のユースケースにおける「ポータル機能」及び「アプリケーション提供機能」の動作確認はできたものの、5GSC の商用展開に向けては、課題も確認された。
具体的には、アプリケーション提供方法を多様化するために、本実証で使った DL 型ではなく、SaaS 型で提供する場合に必要となる検討事項として、どのようなアプリケーション
やサービスを選定するか、GPU などのリソース提供をどうするか、課金体系/方法、サービ
ス運用/運営体制をどうするか等がある。
また、複数企業利用を想定した場合に、プラットフォーム自体にどのような機能（例えば、ユーザー管理、課金機能、画面 UI/UX、非機能要件等）の追加が必要になるのかの検討が必要である。なお、構築にあたっては、アプリケーションに関する各種権利の所在整理、改ざん対策、セキュリティの証明などについても考慮することも必要である。
5GSC の商用展開に向けての検討すべき課題の一覧を表 3.4.2-1 に示す。
表 3.4.2-1

5GSC の商用展開に向けての検討すべき課題

84

85

4. DL 型利用環境における実証実施
4.1 実証目標・手法
4.1.1 実証目標
本調査事業における実証実験として、昨年度開発した「鉄道車両監視 AI システム」を他事業者にて利用可能か、システム導入時の工数短縮やコスト低減は期待されるのかについて、5GSC プラットフォームの DL 型のコンテナアプリケーション提供方式（以下、コンテナ
アプリケーション）で実装可能性,水平展開可能性,実用性の観点から課題分析・対処策の検討を行う。
（1）実装可能性

コンテナアプリケーションを活用した実証システムが利用者環境に構築できるか。
（2）水平展開可能性

異なるシステム環境に実証システムを展開可能であるか。



コンテナアプリケーションを活用することで工数の削減が実現できるか。



システム構成要素のコスト低減が可能であるか。
（3）実用性

実証システムを活用して実際の業務に適用できるのか。

4.1.2 実証手法
令和 2 年度「地域課題解決型ローカル 5G 等の実現に向けた開発実証に係るインフラ分野
におけるローカル 5G 等の技術的条件及び利活用に関する調査検討の請負」のうち、「遠隔・リアルタイムでの列車検査、線路巡視等の実現」事業で開発されたシステムを活用し、以下の観点で実証を行う。
（1）実装可能性

5GSC プラットフォームのポータルより DL 型コンテナアプリケーションの提供方式を用いてのシステム開発が可能であるか実証実験を通じて検討・評価を行う。

（2）水平展開可能性

異なるシステム基盤でも実証システムが狙う動作が行えるかどうかを、他事業者の環境にて動作検証する。



コンテナアプリケーションを用いた利用者環境での構築の工程の確認及び、工数の変化について検証をする。
86

NW やクラウドリソースのスペックダウンによる動作影響を確認し、システム導入コス
トの削減可否を検証する。
（3）実用性

コンテナアプリケーションで構築した実証システムを、実業務担当者にデモ、アン
ケート調査を行い業務代替可能性を確認し実用性の評価を行う。



実証システムにおける AI システムの検出性能について検証・評価する。

4.2 実証概要
昨年度開発した鉄道車両監視 AI エンジンを汎用アプリケーションとして選定し、昨年度の「鉄道車両監視 AI システム」の利用主体であった京浜急行電鉄株式会社（以下、京急）
以外の他の鉄道事業者の現場においても本システムの評価を実施するための実証システム
環境を構築した。
構築した 5GSC プラットフォーム環境に AI エンジンを提供アプリケーションとして登録の上で、汎用クラウド基盤上の利用者環境を想定した汎用クラウド環境にダウンロードし「鉄道車両監視 AI システム」を再構築した。
なお、汎用クラウド基盤は、5GSC を利用するエンドユーザーの開発環境として環境手配のコスト面やリソース調達の容易性から利用・選定されるケースが多く見込まれるパブリ
ッククラウド（Amazon Web Services※以下、AWS）を利用した。
実証に伴い、昨年度の京急での実証実験結果を基に鉄道事業者に実証協力を募り今回は西鉄に協力をいただくこととなった。
実証フィールドとして西鉄筑紫車両基地を利用し、実装可能性、水平展開可能性、実用性の観点を確認すべくシステムの性能評価・試験やデモ・アンケート調査を実施した。

図 4.2-1

令和 3 年度実証システム全体イメージ87

図 4.2-2 「遠隔・リアルタイムでの列車検査、線路巡視等の実現」実証概要
出典：総務省4.3 実証環境本実証実験を実施した課題解決システム環境や実証フィールド環境について記載をする。
今年度構築した DL 型実証システム環境のシステム構成図を記載する。

図 4.3-1 令和 3 年度 DL 型実証システム構成
88

図 4.3-2実証フィールドでの検査車両の撮影図

図 4.3-3

鉄道車両監視 AI システムの UI 画面図

89

図 4.3-4

鉄道車両監視 AI システムの異常検出対象「鉄道車両監視 AI システム」は鉄道車両の検査業務において固定の高精細 4K カメラ及びサーマルカメラで撮影した検査車両映像を 5G 経由でクラウド上システムに映像伝送し、AI 解析エンジンによって鉄道車両の台車異常を解析し、異常解析結果を検査業務拠点に設置される PC 端末等に 5G 経由で送信し表示させるシステムである。
以下に実証システムの詳細構成図を参照情報として記載する。

90

図 4.3-5

鉄道車両監視 AI システムのシステム詳細図

4.3.1 実証フィールド
4.3.1.1 実証フィールド(西鉄)
西鉄は、鉄道営業キロ 106.1km、保有車両 108 編成、309 両の鉄道会社である。

91

図 4.3.1.1-1

西鉄の営業路線・工場・車庫所在地

図 4.3.1.1-2

西鉄の保有車両

西鉄は、今年度の実証実験前より西鉄独自の試みとして、以下の列車検査業務における課
題解決の実現に向けて西鉄車両を用いた実証実験を実施していた。
・車両の走行安全性の向上
・事故故障の未然防止
92

・検査の省力化、効率化
・メンテナンスコスト削減
・要員の適切な配置
・サービスの向上
具体的な取り組みとして、図 4.3.1.1-3 に示すように、以下のような実証システムの検証を行っていた。
・車両のモニタ装置、車両制御装置で取得している様々なデータ及び空調装置に取り付けた各種センサのデータから各機器の状態監視、故障解析、寿命診断（故障予知）などが可能か検証する。
・各社の乗車率や空調装置の動作状態データから旅客動向を把握すると共に快適な社内環境の提供が可能かを検証する。

図 4.3.1.1-3

西鉄の状態監視システム実証試験概要

これらの実証実験の取り組みを経て、今回、西鉄は、「目で見る検査を AI に置き換えることで検査の迅速化・省力化ができるのではないか」「AI が検査をサポートすることで作業員の負担を軽減できるのではないか」「目では確認できない異常の発見による故障の未然の防止」実現への期待を込めて、筑紫車両基地において「鉄道車両監視 AI システム」の実証実
験に協力いただき、本システムの実装可能性についても運用事業者観点での評価を実施することとした。

93

図 4.3.1.1-4

鉄道車両監視 AI システムへの西鉄の期待実証にあたっては筑紫車両基地内の検査車庫にて、車両を低速走行させ、車台を 4K カメラ、サーマルカメラで撮影。鉄道車両監視 AI システムを用いて、車両点検業務で確認される検査項目(クラックやブレーキパッドの厚み、収容函のハンドル、車軸温度)をリアルタイ
ムで検知し、その検知精度や速度などを評価・検証した。（※検出対象はダミーを用いて瑕
疵を模擬した。
）

図 4.3.1.1-5

西鉄における実証対応項目（1）実証スケジュール
以下のスケジュールで西鉄での実証を実施した。
94

図 4.3.1.1-6 西鉄における鉄道車両監視 AI システム実証スケジュール
4.3.1.2 実証環境構築実証を行う環境構築の詳細について、以下に記載する。

4.3.1.3 鉄道車両監視 AI エンジンのコンテナ化
DL 型実証システム環境においては、DL 型として提供されるアプリケーションはコンテナイメージ化されたアプリケーションを活用することとした。図 4.3.1.3-1 に記載のとおり
DL 型で提供されるアプリケーションの利用者環境への展開時の可搬性を考慮して柔軟に対応可能なコンテナイメージでの提供方式を採用したためである。DL 型アプリケーションとして、鉄道車両監視 AI システムにおいては列車の台車異常検出に用いた鉄道車両監視 AI エ
ンジンをコンテナ動作可能なアプリケーションとすることとした。

95

図 4.3.1.3-1 コンテナ化による可搬性についてのメリット（出典：「2025 年の崖」を越えるために必須、コンテナ技術が実現する“真のクラウド化” < https://www.ibm.com/blogs/smarter-business/business/red-hatopenshift/> ）AI エンジンをコンテナでの開発対象とした選定理由は、鉄道事業分野への水平展開時において、各鉄道事業者での映像伝送システムや UI システムなどの各事業者での従来システ
ムの利用を検討されるケースが想定されることや、鉄道車両監視 AI エンジン自体が鉄道事
業者の運用監視業務にとって汎用性と有用性の高い機能であると想定したためである。
コンテナ化した対象の機能は AI エンジンのみとし、その他の鉄道車両監視 AI システムを構成する機能群（車両映像受配信・録画、AI 映像解析配信）については利用者の要件によりシステムを組み換えて利用されるケースがあることを想定しコンテナ化対象外とした。(参照 表 4.3.1.3-1）
表 4.3.1.3-1 鉄道車両監視 AI システム機能ごとのコンテナ化検討
構成機能
機能概要
コンテナ化検討
鉄 道 車 両 監 視 受信した 4K 高精細映像の AI 解析を実施 AI エンジンは解析対象などを変AI エンジン
し解析結果として検出異常位置情報・時 えることで鉄道事業分野の運用間情報等を示す矩形位置情報のデータを 監視業務にとって汎用性と有用出力する。
性が高いと考えられる。コンテ
ナ化を行うことで同エンジンを他 業 務 な ど へ の活 用 が 見 込める。
車 両 映 像 受 配 ・現場のカメラで撮影されたリアルタイ 4K 高精細映像を中継配信する機信・録画
ム映像を AI エンジン及びクライアン 能となり配信規模の規模が巨大
トへ中継配信する。
になるに応じ映像受配信システ
・現場のカメラで撮影されたリアルタイ ムを別途手配する必要があるこ96

ム映像を録画し、保存した録画映像をク
ライアントへ配信する。
AI 映像解析結果配信

リアルタイム・録画映像に AI 解析した結果の検出異常位置情報・時間情報等を示
す矩形位置情報のデータを映像に合成表示しクライアントに配信する。

とが懸念されたため拡張性の観
点 か ら コ ン テ ナ化 対 象 外 とした。
AI エンジンの出力結果をクライ
アントに配信するための機能となり利用者ごとの AI 解析結果の取扱い方法の違いなどにより都度追加開発を行うことが懸念された。汎用性の観点からコンテ
ナ化対象外とした。

図 4.3.1.3-2 コンテナ化した対象機能範囲
車両監視に用いる AI エンジンの動作概要を図 4.3.1.3-3 に示す。
4k30fps の車両ストリーミング映像を解析するにあたり、映像解析を高速に実行させる必要があり、これを実現するためにクラウド基盤上で複数リソースを並列利用させクラウド
基盤内でのデータ伝送容量の効率化（リソース最適化）を実現する構成としている。AI エンジンでの解析データの取り扱いとしては WebRTC Client から車両ストリーミング映像データを受け取る際に、ストリーミング映像をフレームごとに一度分解し、解析処理後に解析結果をフレームごとに整列したタイムスタンプとともに座標情報として出力する構成としている。
さらに AI エンジンの解析については、Front API での前処理と、Back API での後処理を97

行っており、前処理について、車両監視 AI は台車やその他の物体検知を行った上でバウン
ディングボックスの座標情報を含む画像情報を Back API に出力する。
後処理について、車両監視 AI は前処理で検知した解析対象（台車やその他対象物）に対して、さらなる精細な特徴量の解析する構成としている。

図 4.3.1.3-3

鉄道車両監視 AI エンジン動作概要

鉄道車両監視 AI エンジンについて、Front API での前処理については主に GPU 処理での解析処理を実施し、一方、Back API での後処理においては主に CPU 処理での解析処理を実行している。
コンテナ化の構成を検討する中で DL 型アプリケーションとして利用者環境における導入障壁をコスト面からも見直しを図るべく AI エンジンの消費リソースの有効活用を考慮した結果、図 4.3.1.3-4～4.3.1.3-6 に記載のとおりコンテナを起動するノードにおいてそれぞれの処理特性に応じたリソースを提供できるように Front API、Back API それぞれでコン
テナ実行ノードを分割することとして AI エンジンのコンテナイメージを設計した。

図 4.3.1.3-4

鉄道車両監視 AI エンジン
98

コンテナ配置図

図 4.3.1.3-5

鉄道車両監視 AI エンジン

コンテナ実装機能内訳（GPU インスタンス）

図 4.3.1.3-6

鉄道車両監視 AI エンジン

コンテナ実装機能内訳（CPU インスタンス）

4.3.1.4 DL 型実証システム
DL 型アプリケーション実装方式として、3 章で前述した 5GSC プラットフォーム実証環境にて用意をしたマーケットプレイスにおいて汎用アプリケーションを「コンテナ」化してイメージを配置、利用者環境を即した AWS 環境内 OpenShift 上にコンテナイメージをダウンロードし、コンテナを実行する環境を構成した。（図 4.3.1.4-1 参照）コンテナを動作させるためには利用者環境においてもコンテナ実行環境を構築する必要がある。今年度はKubernetes をベースとするコンテナ・プラットフォームの PaaS(Platform As Service)として提供されており、利用者にとってサポート面や機能面で簡便にコンテナ実行環境を運用することが可能となる OpenShift を活用した。

99

図 4.3.1.4-1

鉄道車両監視 AI エンジンの DL 型動作イメージ

4.3.1.5 実証フィールドでの環境構築実証実験では、西鉄にご協力いただき、実際の検査車両庫での走行車両を用い、かつ、キャリア 5G 環境下での鉄道車両監視 AI システムの評価・試験を実施した。西鉄に実証実験への協力を得て鉄道車両監視 AI システムの実証実験を西鉄筑紫車両基地において実施した。
現地には 5G 環境を形成するため可搬型キャリア 5G 基地局(キャリー5G)を構築し、AWS と接続するネットワーク環境を構築した。
（1）5G 環境の構築
西鉄筑紫車両基地での 5G 環境構築のため NTT ドコモキャリー5G（図 4.3.1.5-1 参照）を利用し、屋内での列車検査業務用として線路南側の検査庫内に 4.5GHz 帯キャリア 5G の基地局を１局（屋内局）構築した。
（図 4.3.1.5-2 参照）

100

図 4.3.1.5-1

可搬型 5G 基地局設置図

図 4.3.1.5-2

可搬型 5G 基地局設置図

検査庫内の 14 番線の中央付近に設置し、建屋内部に 5G エリアを展開した。
（図 4.3.1.53 参照）なお、5G 敷設にあたり、CU 装置まではダークファイバを利用し車両基地外の支柱
より光ファイバーの入線を実施し、5G 通信品質向上のために車両基地内 LTE レピータ装置を設置。アンカーバンドとなる LTE 電波の品質向上を図った。

101

図 4.3.1.5-3

5G エリア図キャリア 5G の通信速度は DL：800Mbps、UL:90Mbps 程度、5G・4G の電界強度も-70~-80dBm程度と強電界となっており、レベル/品質・スループット共に良好であった。
（図 4.3.1.5-4
参照）

102

図 4.3.1.5-4

エリア品質状況（2）鉄道車両検知 AI システムの機材設置
西鉄の筑紫車両基地車両庫内での実証実験に伴う設営機材の配置図（図 4.3.1.5-5）と機材接続構成図（図 4.3.1.5-6）を以下に示す。

図 4.3.1.5-5

機材設置図（屋内）103

図 4.3.1.5-6

機材接続構成図（3）機材類の技術的諸元
鉄道車両監視 AI システムに関する各構成要素の技術的諸元と DL 型実証システム環境の構築に使用した機器及びソフトウェアとそれらの選定理由・妥当性を以下表に示す。今年度は以下の技術諸元に基づき実証フィールドにおいて現地映像配信システムを構築した。これらの諸元は令和 2 年度の実証システムと同一諸元として設計した。

表 4.3.1.5-1 映像配信システムの構成機材及び技術的諸元
構成要素
諸元
シングルボードコンピュ ・列車検査用高精細 4K カメラ、サーマルカメラで撮影された映ータ
像をリアルタイムで HDMI または USB 経由で受信し、適切な映像フォーマットへリアルタイムに近しい高速度でのコーデッ
ク変換可能な GPU を実装していること。
・AI 解析基盤へ映像配信するアプリケーションを実装可能であること。
車両検査用高精細 4K カメ ・車両の状態を AI 解析するための元データとして、高精細映像
ラ(4K:3840*2160)が 30 フレームで撮影可能であること。
・HDMI または USB でリアルタイム出力が可能であること。
・同一車体部を高精細 4K カメラ映像とサーマルカメラ映像で撮影した映像から AI 映像解析を同時実施することにより、台車104

車両検査用サーマルカメ
ラ

のき裂等の検出、車軸の不良等よる温度上昇の検出の両面から異常検出が可能であること。
・車軸の不良による温度上昇を取得するためのデータ（物体の温度を色別表示）として、
解像度 QVGA(320＊240)〜VGA(640＊480)
が 10〜30 フレームで取得可能であること。
・HDMI または USB でリアルタイム出力が可能。
・同一車体部を高精細 4K カメラ映像とサーマルカメラ映像で撮影した映像から AI 映像解析を同時実施することにより、台車
のき裂等の検出、車軸の不良等よる温度上昇の検出の両面から異常検出が可能であること。

映像受配信サーバ・作業現場のカメラで撮影されたリアルタイム映像及び録画映像を、想定する映像コーデックで 4K・30 フレームで集配信することが可能であること。
・リアルタイム映像に、リアルタイム映像から AI 解析した結果の検出異常位置情報・時間情報等を示すバウンディングボック
スのデータを配信が可能であること。またデータベースへ同情報を格納可能であること。
・録画映像については、リアルタイム映像解析の結果として異常
位置情報・時間情報等データとしてデータベースへ格納した情報を利用し、同一録画映像と併せてバウンディングボックスのデータを配信が可能であること。

AI 解析結果表示 PC 等

・クラウド基盤上の映像配信サーバに接続して、配信要求し、解析結果を表示可能な UI（ブラウザ）を具備していること。・リ
アルタイム映像については、リアルタイム配信映像と AI 解析
した結果の異常位置を示すバウンディングボックス等を合成した映像を表示することが可能であること。
・録画映像については、AI 解析した結果の異常位置を示すバウ
ンディングボックス等を合成した映像、合成前の保存録画映像を再生することが可能であること。
・配信された映像を 4K・30 フレームで再生することが可能であること。
・5G 端末（ルータ機材）とは LAN、USB、Wi-Fi で接続可能である
こと。

5G 端末

・5G を利用して、シングルボードコンピュータからのデータを
AWS 上の AI 解析基盤にアップロード通信が可能であること。
また、シングルボードコンピュータとは LAN または USB で接続可能であること。
・AI 解析結果を遠隔監視拠点の PC 等へ広帯域なダウンロード通信が可能であること。
・AI 解析結果表示用 PC 等とは LAN、USB、Wi-Fi で接続可能であ
ること。

機器等名

表 4.3.1.5-2
選定した機材使用する機器及びソフトウェア
選定理由・妥当性
105車両検査用高精細カメラ

SONY ZV-1

・ 動 画 記 録 フ ォ ー マ ッ ト XAVC
[4K:30p(3,840x2,160/30p)]で撮影可能である・撮影条件に合わせて撮影レンズ換装が可能なこと
・HDMI 端子、USB 端子でリアルタイム出力が可能である

車両映像配信用
シングルボードコ
ンピュータ

NVIDIA Jetson
Xavier NX

・USB 端子(USB3.1)で映像をリアルタイムに受信が可能である・H.264、VP8、VP9 のエンコードに対応しており、NVIDIA Volta GPU を実装している・動画像
加工処理用のフレームワーク（Gstreamer など)やソフトウェア（ffmpeg など）を利用可能であること

ルータ機材

SH-52A

・有線 LAN(1000BASE-T)を有しておりシングルボード
コンピュータと LAN で接続が可能である
・Wi-Fi 規格、IEEE802.11a,b,g,n,ac,ax に対応している

クラウド基盤

AmazonServicesWeb・必要コンピューティングリソースの提供が可能であること・GPU インスタンスが多数準備可能であること・Openshift コンテナランタイム環境の動作実績がある基盤であること

映像受配信システム

時 雨 堂 WebRTCSFU Sora

列車検査用映像
AI 解析エンジン

高精度映像異常検出エンジン

映像配信サーバ

Web サーバ・シングルボードコンピュータへ搭載予定の WebRTC
クライアントから AI 解析システムへ映像送信可能である。
・映像を WebRTC SFU サーバ経由で配信元に代わってストリーミング配信が可能である。
・多地点からの要求に対し、WebRTC SFU サーバ経由で配信元に代わって配信が可能なシステム構成である。
・一般的な配信において高ビットレートでの配信時、映像の解像度が引き下げられてしまう場合がある
が、株式会社時雨堂が提供する WebRTC SFU sora
は、クライアントに対し上限値を引き上げるように通知することで解像度を担保した映像配信が可能である。
・高精細映像を AI 解析し、異常箇所を特定した座標情報をリアルタイムに出力することで検出座標データ配信を行う。
・AI 解析結果映像をクラウド上の録画保存インスタ
ンスへ保存することで、後からでも映像再生可能とする。
・リアルタイム映像と AI 解析した結果の異常位置を示すバウンディングボックス等を合成可能な状態でクライアントに配信することで、低遅延で配信可能である。
・また、AI 解析した結果の異常位置を示すバウンディングボックス等のデータは、映像配信サーバに106

AI 結果表示 PC

ノート PC

MQTT ブローカーを配置してクライアントに配信することで、高頻度で配信可能である。
・映像配信サーバに録画映像のデータベース及び Web
サーバを配置し、Web サーバから AI 解析結果をフ
ァイル形式で配信することで映像配信可能である。
・chrome ブラウザが動作可能な端末であり、https ア
クセスにより Web サーバへ接続することで配信要求と解析結果の表示が可能である。
・高性能グラフィック処理基盤を搭載しており 4K・30
フレームが再生可能であること。
・有線 LAN を有しており、ルータ機材と LAN で接続可能であること。

4.3.2 実証システム構成の検討
今年度は西鉄での実証を通じ、鉄道車両監視 AI システムの構成要素を見直し昨年度京急で開発した実証システムを他事業者への水平展開可能なシステムとして汎用性を高めるための検討を行った。
鉄道車両監視 AI システムに対する他事業者への水平展開可能性を高めるための検討ポイントとして、システム導入コストの削減観点から「低廉化」によりシステム構成を見直したことによる「リアルタイム性」や「AI 検出性能」への性能影響を確認した。
（1）低廉化
システムコスト面での低廉化を狙い以下のポイントを構成変更した。
①5GNW システムのバックホールを閉域接続から Internet 経由でのクラウド基盤接続構成に変更
5GNW システムのバックホール環境は昨年度の実証システム構成では NTT ドコモのク
ラウドダイレクトサービスを利用しクラウド環境（ドコモオープンイノベーションクラウド）と閉域接続を行っていた。国内事業者環境においてクラウド環境との閉域接続を行うことで NW 区間の通信遅延の緩和が図れるが、AI 解析のリアルタイム性の要求が緩和される場合は通常のインターネット経由での接続でもシステム構成可能であると仮定した。
②AI 画像解析に用いる GPU リソース数を昨年度から半減
GPU リソースについては前述した AI エンジンの動作概要よりも、複数 GPU リソースを同時並列処理させることで 4K30fps の高精細映像の解析を実施している。これらにおいても昨年度はクラウド基盤上の GPU 専有リソースを利用することで十分なマシン
パワーを活用することで解析処理性能を担保していたが、各鉄道事業者が継続的に占有 GPU リソースのランニングコストを負担することは費用負担面から現実的ではないと考える。そのため、今年度に関しては容易にリソースの拡張が可能であるクラウド基107

盤上のオンデマンドインスタンスを活用し、GPU リソースについては昨年度よりも廉価なものを複数組み合わせるシステムを構成することで同時並列処理可能な AI エンジン構成は実現しながらも GPU リソースのコストを削減することとした。

図 4.3.3-1

実証システムの構成差分（2）リアルタイム性
前述した①5GNW システム構成の変更による NW 区間の影響による NW 遅延増加や②AWS のGPU リソースの削減により AI 解析処理遅延の影響が見込まれるため、5G の NW 構成変更や
AWS の GPU リソースの削減による AI 解析処理のリアルタイム性への影響を測定した。

図 4.3.3-2 リアルタイム性の影響測定
108

（3）AI 検出性能
鉄道車両監視 AI システムについて、AI 解析に用いる GPU リソースを以下のように変更した。AI エンジンでは GPU リソース数に応じて同時並列で AI 解析処理を実行しており、GPU
リソース数が減少することにより解析可能なフレームレート(fps)が減少することで AI 解析の検出性能や処理速度に影響が生じる。
・dOIC（ドコモオープンイノベーションクラウド）
GPU インスタンス「Quadro P5000 搭載 SV」を 2 台利用
・AWS
GPU リソース「g4dn.12xlarge インスタンス」を 2 台利用

図 4.2.3-3

AI 解析に用いる GPU リソースの変更

今年度でのシステム評価・検証においては鉄道車両監視 AI システムについての GPU
リソース数の減少による AI 検出性能の比較を行うため、ベースラインとして「昨年度の京急実証結果」、パターン①「昨年度の京急車両映像を従来 AI モデルで解析した場合」、パターン②「西鉄車両映像を従来 AI モデルで解析した場合」及びパターン③「西鉄車両映像を追加学習 AI モデルで解析した場合」のパターンでのシステム評価を実施
しデータ整理・分析を行い AI 検出性能の影響を確認した。
それぞれの評価結果についての比較分析として、ベースラインとパターン①の比較
では、「DL 型実証システム環境でも昨年度実証結果レベルでの解析可能か」を確認した。
パターン①とパターン②の比較では、「西鉄車両映像が従来の AI モデルで業務活用可能なレベルで解析可能か」を確認することとし、パターン②とパターン③の比較では、「他鉄道事業者の車両映像を AI モデルに追加学習することで他鉄道事業者でも業務活用可能なレベルで解析可能か」について確認することとした。
昨年度の鉄道車両監視システムは AI の検出率・網羅率が 100%の水準ではないことから AI 検出と検査員による目視検査とのクロスチェックをすることで業務運用可能と判断されるレベルであったため本年度は同水準のシステム性能が得られるかを他鉄道事
109

業者での実証において確認することとした。

図 4.3.3-4 AI 検出性能比較パターン

4.4 実証内容・実施結果
今年度は、DL 型提供方式に関する技術検討として、実証目標に挙げた①～③の観点を確認すべく実証を実施した。
①実装可能性②水平展開可能性③実用性【実証１ DL 型アーキテクチャの実装可能性の評価・検証】
実装可能性の観点から、DL 型実証システム環境において 5GSC プラットフォームのポータルからのアプリケーションダウンロード、アップロード機能などの特徴的な機能の動作を検証し、5GSC プラットフォームの提供アプリケーションからダウンロードしたコンテナ
アプリケーションを AWS 環境に構築した場合のシステム動作正常性の確認及び録画鉄道車
両映像を用いたシステム評価・効果検証を実施した。
【実証２ DL 型アプリケーションの水平展開可能性（工数削減効果）に関する評価・検証】
水平展開可能性の観点から、DL 型提供方式によりコンテナアプリケーションを用いて構築した「鉄道車両監視 AI システム」におけるシステム環境の構築工程・工数検証を実施した。
【実証３

DL 型アプリケーションの水平展開可能性（AI 検出性能影響・リアルタイム性）

及び実用性に関する評価・検証】
110

水平展開可能性の観点から、他鉄道事業者の協力を得ながら鉄道車両監視 AI に対するシステムの評価・検証を実施し、低廉化した実証システムにおける AI システムの検出性能について「リアルタイム性」、「AI 検出性能」の性能影響を確認した。
実用性の観点から、コンテナアプリケーションで構築した「鉄道車両監視 AI システム」
を、実業務担当者にデモ、アンケート調査を行い業務代替性の評価を行った。
以下、それぞれの実証実施内容について詳述する。
4.4.1 DL 型アーキテクチャの実装可能性
4.4.1.1 前提条件
今年度においては 5GSC のアプリケーション提供方式として DL 型環境を構築しアーキテ
クチャの技術的な機能評価を実施した。

図 4.4.1.1-1

令和 3 年度の 5GSC 上の DL 型検証環境

アプリケーションの DL 型提供方式について提供者・利用者において DL 型システム導入
手法を検証するために「鉄道車両監視 AI システム」のアプリケーションを利用し、他鉄道事業者の利用者環境に実証システムを構築し性能評価試験を実施した。

111

図 4.4.1.1-2 DL 型アーキテクチャに関する実証概要

4.4.1.2 評価・検証
DL 提供型「鉄道車両監視 AI システム」を用いた実証システム環境において、DL 型アー
キテクチャに対する評価・検証における①評価・検証項目②評価・検証手法③評価・検証結果をそれぞれ以下に記載する。

（1）評価・検証項目
1）5GSC プラットフォームのアプリケーション配置・ダウンロード機能
5GSC から提供されるアプリケーションについて DL 型提供方式におけるアプリケーショ
ン提供者からの 5GSC へのアプリケーションアップロード機能、及び、5GSC から利用者環境
へのアプリケーションのダウンロード機能の動作確認を実施した。
5GSC からのアプリ配置・ダウンロード機能に関する評価・検証項目を表 4.4.1.2-1 に示す。
表 4.4.1.2-1

アプリ配置・ダウンロード機能に関する評価・検証項目

1122）DL 型実証システム評価
今年度、DL 型コンテナアプリケーションを利用し AWS に構築した鉄道車両監視 AI システ
ムの動作正常性の確認及び昨年度、京急の録画鉄道車両映像を用いたシステム評価・効果検証を実施した。評価方法としては、令和 2 年度京急実証実験での鉄道車両監視 AI システム評価試験項目の試験結果と今年度 DL 型システム環境との結果比較を行い差分分析・解析することでシステム評価を実施した。

図 4.4.1.2-1

鉄道車両監視 AI システム性能評価パターン図（2）評価・検証方法
1）5GSC プラットフォームのアプリケーション配置・ダウンロード機能
5GSC 実証環境に対して鉄道車両監視 AI エンジンのコンテナイメージのアップロードの実施、及び、5GSC の実証環境から利用者環境を模擬したパブリッククラウド環境（AWS）へのコンテナイメージのダウンロードを実施し、これらが正常に機能動作することを確認した。
表 4.4.1.2-2

アプリ配置・ダウンロード機能に関する評価・検証方法

2）DL 型実証システム評価
DL 型で構築した鉄道車両監視 AI システムを用いた場合の AI 構成面に関する机上の性能検討評価及び、京急実証実験と同様の評価検証項目を実施し昨年度との性能比較を行った。
システム性能評価を実施した試験・評価詳細項目・評価方法を以下に記載する。

113a）AI 構成面に関する評価・検証方法
DL 型実証システム環境にて用いた AI エンジンの構成面に関する評価として、DL 型実証
システム環境において AI エンジンで利用するリソースに応じて AI エンジンが処理可能なフレーム数の机上検討・計算及び、DL 型実証システム環境における解析実行時の解析可能なフレーム数について評価を実施した。
AI エンジンにおいて映像解析を行う場合には、動画を構成しているフレーム画像を用いて、車両異常解析・検知を実施する。動画を構成している単位時間あたりのフレーム画像数をフレームレートと言い、fps（1 秒間にどれだけのフレーム画像数が使われているか）という単位で表現される。AI が解析可能なフレーム数が多いほどより高精度な解析結果を得ることが可能となるが解析に利用するリソース数により解析可能なフレーム数については増減する。
表 4.4.1.2-3

AI 構成面に関する評価・検証方法b）AI 検出性能面に関する評価・検証方法
DL 型実証システム環境にて用いた AI エンジンの検出性能評価として、実際の取得映像を解析する際の機能要件を評価した。評価方法として処理時間、検出精度、検出限界速度、その他の環境要因による検出精度等への影響を確認し昨年度京急との評価結果と比較をした。
表 4.4.1.2-4

AI 検出性能面に関する評価・検証方法

114c）UI・映像伝送システム
DL 型実証システム環境にて用いた UI・映像伝送システムの評価・検証方法を表 4.3.1.25 に示す。ここでは、利用者のオペレーション観点で重要性の高いシステム機能を評価した。具体的には、対象となる機能の特性に応じて、遅延量や解析結果の表示性能などを評価した。
表 4.4.1.2-5

UI・映像伝送システムに関する評価・検証方法d）通信性能通信性能に関する評価・検証項目を表 4.4.1.2-6 に示す。
鉄道車両監視 AI システムに関する通信性能試験として、現地実証フィールドからの NW
遅延や映像伝送に影響する通信性能を、各種評価項目（スループット、遅延量、安定性など）にて評価を実施した。
表 4.4.1.2-6

UI・映像伝送システムに関する評価・検証方法（3）評価・検証結果
DL 型アーキテクチャに関する評価・検証結果について記載する。
DL 型アーキテクチャにおいては、利用者・提供者において 5GSC へのユーザー登録及びコンテナ実行環境の手配、コンテナイメージの作成などの DL 型を利用する際の前提条件などを図 4.4.1.2-2 に記載する。
115

対応者
提供者

DL 型利用のための前提条件
・5GSC へのユーザー登録（提供者）が完了していること
・開発環境から 5GSC への Internet 経由でのアクセス環境を有していること。
・外部への連携可能なレジストリに提供対象となるコンテナイメージファイル
を手配可能であること。

利用者

・5GSC へのユーザー登録（利用者）が完了していること
・利用者環境から 5GSC への Internet 経由でのアクセス環境を有していること。
・コンテナ実行環境が構築できていること。（Openshift, Kubernetes 等）
・外部との連携可能なレジストリを手配可能であること。
・コンテナ実行用の Node を手配できていること。

図 4.4.1.2-2

DL 型利用条件など

1）5GSC のアプリケーション配置・ダウンロード機能
5GSC 実証環境から鉄道車両監視 AI のアプリケーション配置・ダウンロード機能の正常動作を確認することができた。
（表 4.4.1.2-7）
今回の実証環境でのアプリケーション配置・ダウンロード実施時の実行イメージについて図 4.4.1.2-3 から図 4.4.1.2-14 に記載する。
表 4.4.1.2-7
No
1

2



ソフトウェアダウンロード機能に関する評価・検証結果

対象機能

評価項目
評価方法
試験結果
5Gソ リ ュ ーシ ョ ン 提供セ ン タ ーに 対し て 指定形式で ソ フ ト ウ ェ
5Gソ リ ュ ーシ ョ ン 提供セ ン タ ーに 対し て ソ フ ト ウ ェ ア 配置時の
ア ア ッ プ ロ ード を 実施し ア ッ プ ロ ード が正常に 完了する こ と のOK機能の正常性確認
検証を 行う 。
5Gソ リ ュ ーシ ョ ン 提供セ ン タ ーから ソ フ ト ウ ェ ア ダ ウ ン ロ ード
ソ フ ト ウ ェ ア ダ ウ ン ロ ー DL型実証環境から 5Gソ リ ュ ーシ ョ ン 提供セ ン タ ーのソ フ ト ウ ェ
を 実施し DL型実証環境のソ フ ト ウ ェ ア 保管場所に 正常に ダ ウ ンOKド
ア を ダ ウ ン ロ ード ・ 展開時の機能の正常性確認
ロ ード 完了する こ と の検証を 行う 。
ソ フ ト ウ ェ ア 配置

DL 型提供方式の提供者・利用者の利用イメージ・ アプリケーション配置（提供者）①5GSC のポータル画面から新規ソリューションを作成開始する。
116

図 4.4.1.2-3 新規ソリューション作成画面②ソリューション提供アプリとして鉄道車両監視 AI のコンテナイメージをアップロー
ドする。

図 4.4.1.2-4 イメージのアップロード画面③ポータル画面で表示されるアップロード手順に従い鉄道車両監視 AI コンテナイメー
ジをアップロードしていく。

117

図 4.4.1.2-5

イメージアップロード手順画面④アップロード手順に従い提供者開発環境からコンテナイメージをアップロードする。

図 4.4.1.2-6

提供者環境でのイメージアップロード手順実行画面⑤5GSC のポータル画面へコンテナイメージがアップロードされたことを確認する。

118

図 4.4.1.2-7

イメージアップロード完了画面

・ アプリケーションダウンロード（利用者）①利用者は 5GSC のポータル画面から鉄道車両監視 AI ソリューションの利用開始を選択する。

図 4.4.1.2-8

ソリューション選択画面②ソリューション提供アプリとして鉄道車両監視 AI のコンテナイメージをダウンロー
ドする。

119

図 4.4.1.2-9

ダウンロード画面③鉄道車両監視 AI コンテナイメージのダウンロード手順に従い、利用者環境へのアプリ
ケーションのダウンロードを実行する。

図 4.4.1.2-10

イメージダウンロード手順画面④利用者環境へのアプリケーションのダウンロードを実行する。

図 4.4.1.2-11

利用者環境でのイメージダウンロード手順実行画面⑤利用者環境へのアプリケーションのダウンロード完了を確認する。

図 4.4.1.2-12

利用者環境でのイメージダウンロード完了確認画面⑥利用者環境にてダウンロードしたアプリケーションをデプロイする。
120

図 4.4.1.2-13

利用者環境での DL イメージデプロイ実行画面⑦利用者環境のデプロイ完了後、正常に鉄道車両監視 AI システムが動作していることを確認する。

図 4.4.1.2-14

利用者環境での鉄道監視車両 AI ソリューション実行画面

2）DL 型実証システム評価a）AI 構成面に関する評価・検証結果
鉄道車両監視 AI システムについて DL 型提供方式を用いた場合に利用者環境として汎用的に利用可能な AWS でのシステム実装をすることとした。このため、AI 解析に用いる GPU
リソースについても GPU インスタンスを昨年度の実証システムから変更した。また、今年度
システム環境については導入コストの低廉化により昨年度よりも GPU リソース数を半減さ
せた。

121

図 4.4.1.2-15

鉄道車両監視 AI エンジンの GPU リソース比較

AI 映像解析には特に GPU リソースが必要となるため、AI モデルの処理性能は用意するサーバ環境の GPU リソース数に大きく依存する。鉄道車両監視 AI システムは大容量の高精細映像データをリアルタイムに受信しながら解析結果を出力することを目的としたシステムであるため、映像は AI システムの解析を待つことなく常時伝送されてくることから AI シ
ステムの解析に遅延が発生しないよう伝送されてくる映像のフレーム数を間引くことで整合性を取っている。このリアルタイムの映像伝送に対し AI システムの解析が追いつくことが可能な処理フレーム数を、昨年度、京急実証実験と同様に評価・検証することで、今年度
AI 構成面に関する評価を行った。なお、解析映像伝送のフレーム数は昨年度の京急実証実
験時と同じ 30fps とした。
机上検討の上、今年度 DL 型実証システム環境で利用する AWS インスタンスタイプ「g4dn.12xlarge」を 2 台利用した場合で机上計算した AI 解析処理可能なフレーム数は以下のとおりであった。昨年度の実証システム環境での車両検知に関する AI エンジンの理論
的な最大処理フレーム数は 20fps であったことから今年度の実証システム環境での解析可能なフレーム数については性能低下することが想定された。
表 4.4.1.2-8
解析対象

AI 解析処理可能なフレーム数
解析可能 FPS

車両検知

14.3fps

車体番号検知2.0fpsサーマル

6.7fpsAI 解析処理可能なフレーム数については以下の計算式とパラメータ（表 4.4.1.2-8）を用
いて計算をした。
解析処理可能フレームレート= 活用する API 数 ÷ 処理速度(msec) × 1 枚当たり活用する API 数
122

解析対象
車両検知

表 4.4.1.2-9 AI 解析処理可能なフレーム数算出に用いた値
活用 API 数
処理速度
1 枚当たり活用する API 数
5350msec1

車体番号検知1

500msec

1

サーマル

2

300msec1

DL 型実証において、京急の車両録画映像解析をさせた場合、AI ソフトウェア処理可能なフレーム数の確認結果として流れる映像（4k30fps）に対して、試行あたりに AI エンジン
（車両点検 AI モデル）が処理したフレーム数を計測し、その結果を図 4.4.1.2-16 に示す。

図 4.4.1.2-16

AI 解析フレーム数統計

今回の AI エンジンの理論的な最大処理フレーム数は机上計算では 14.3fps であったが、実測上の統計として AI エンジン（車両点検 AI モデル）は概ね 12fps を処理できていることが確認できた。

b）AI 検出性能面に関する評価・検証結果
鉄道車両監視 AI システムについて AI 検出性能面に関する評価・検証のため昨年度京急
久里浜工場での AI システム性能評価試験時の結果と今年度実証システムにて構築した AI
システムを用いた京急車両録画映像での AI システム性能評価試験結果の差分比較を実施し、各種システム評価項目（検出率、網羅率）についての検出性能面での評価・検証を実施した。
検知対象物は、京急実証時と同様とし車両のクラック、ハンドル開閉、ブレーキパッドの摩耗、車軸の温度異常を対象とした。
※検出率：
１回の試行あたりにシステムが出した結果を積み上げ、「システムが検出したもののう123

ち、真に正しい結果の割合」を評価した。
※網羅率：
１回の試行あたりにシステムが出した結果を積み上げ、「システムが検出すべきと定めた事物のうち、それを少なくとも１回、システムが検出した割合」を評価した。


クラック検出性能
DL 型実証システムにおいて昨年度と比較した検出性能の結果を図 4.4.1.2-17 と表

4.4.1.2-10 に示す。全体としては昨年実証実験時とほぼ同水準の検出率/網羅率であることを確認した。

図 4.4.1.2-17

クラック検出性能比較（R2 京急実証システム×R3DL 型実証システム）

表 4.4.1.2-10 鉄道車両監視 AI のクラック検出性能比較結果（R2 京急実証システム×R3DL 型実証システム）

124



ハンドル検出性能
DL 型実証システムにおいて昨年度と比較した検出性能の結果を図 4.4.1.2-18 と表

4.4.1.2-11 に示す。DL 型実証システムにおいて昨年度と同様な検出性能を得ることができたことを確認した。

図 4.4.1.2-18

ハンドル検出性能比較（R2 京急実証システム×R3DL 型実証システム）

表 4.4.1.2-11 鉄道車両監視 AI のハンドル検出性能比較結果（R2 京急実証システム×R3DL 型実証システム）

125



ブレーキパッド検出性能
DL 型実証システムにおいて昨年度と比較した検出性能の結果を表 4.4.1.2-12 に示す。

ブレーキパッドの残存割合（閾値）に応じて異常/正常を判定するが、昨年度と同様な判定
結果を得ることができたことを確認した。
表 4.4.1.2-12 ブレーキパッド検出性能比較（R2 京急実証システム×R3DL 型実証システム）

サーマルカメラ検出性能
サーマルカメラを用いた車軸異常温度の検出において、結果を表 4.4.1.2-13、4.4.1.2-

14 に示す。昨年度同様の結果として走行速度によらず、検出率・網羅率ともに 100％とな
り、高精度な検出ができたことを確認した。
表 4.4.1.2-13
検出対象

走行速度

閾値

5

10

10

10

表 4.4.1.2-14

試験回毎のブレーキパッド検出率・網羅率一覧(昨年度度検出結果)
AIが検出した対象数

AIが検出しなかった対象数

True_positive False_positive True_negative False_negative
42

42

0

0

0

0

0

0

検出率

網羅率

100%

100%

100%

100%

試験回毎のブレーキパッド検出率・網羅率一覧(DL 型実証システム検出結
果)

126

検出対象

走行速度

閾値

5

10

AIが検出した対象数

AIが検出しなかった対象数

True_positive False_positive True_negative False_negative
42

0

0

検出率

0

42
0
0
0
10
10
* 10kmで の、 カ イ ロ の検出温度が低い サン プ ルは「 正常」 で 正と し て 整理

網羅率

100%

100%

100%

100%

c）UI・映像伝送システム
UI・映像伝送システムについて、4K30fps の映像が正常表示されているかを以下の測定区
間（図 4.4.1.2-19）にて試験・評価した。
結果としては、DL 型実証システムにおいても昨年度同様のストリーミング配信映像及び録画映像についても正常に配信ができることを確認した。

図 4.4.1.2-19

UI・映像伝送システム性能測定区間

UI・映像伝送システムにおいて目的映像が適切に表示されるかを試験・評価した結果を
表 4.4.1.2-15 に示す。結果としては問題なくストリーミング配信映像、録画映像が UI 画面で再生されることを確認した。
表 4.4.1.2-15
対象UI

確認端末

映像表示確認結果

確認方法

該当映像が
再生される（〇×）

ストリーミング配信 AI解析結果表示ノートPC 該当リンクをクリックする

○

録画配信

○

AI解析結果表示ノートPC 該当リンクをクリックする

UI・映像伝送システムにおいて AI 検知箇所特定の矩形（バウンディングボックス）が適切に表示されるかを試験・評価した結果を表 4.4.1.2-16 に示す。
結果としては、矩形情報を UI 画面上に適切に表示できることを確認した。

127

表 4.4.1.2-16

矩形情報表示確認結果

対象UI
確認端末
確認方法
ストリーミング配信 AI解析結果表示ノートPC 意図的に異常状態を作り、適切な位置にバウンディング
ボックスが表示されるか
目視で確認する。

録画配信

AI解析結果表示ノートPC 意図的に異常状態を作り、適切な位置にバウンディング
ボックスが表示されるか
目視で確認する。

異常箇所数（1画像当たり）

バウンディングボックスが適切な位置に表示される（〇×）

1ヶ所
○
2か所

○

3か所

○

1ヶ所
○
2か所

○

3か所

○

UI・映像伝送システムにおいて録画映像総合シークバーによる再生指定について検証・評
価した結果を表 4.4.1.2-17 に示す。任意の場所への再生指定について映像、矩形情報との時間軸が同期されていることを確認した。
表 4.4.1.2-17

録画映像総合シークバーによる再生指定確認結果

対象UI

確認端末

録画配信

シークバーを任意の場所へ移動したとき、生映像と矩形付き映像が同じ時間軸で
AI解析結果表示ノートPC 再生されることを確認する

図 4.4.1.2-20

確認方法

時間軸の同期が取れている（〇×）シークバーによる再生指定画面

128○

UI・映像伝送システムにおいて表示映像種別の選択による正常表示動作、映像選択時のレイアウト切替り時間を試験・評価した結果を表 4.4.1.2-18 に示す。
表示映像種別ごとによるレイアウト切り替え動作及び切り替わり時間においても正常動作したことを確認した。
表 4.4.1.2-18
対象UI

確認端末

映像切替わり・レイアウト確認結果

確認方法

該当の映像種別をクリックしレイアウトが切り替わる（フェードアウトする）ことをストリーミング配信 AI解析結果表示ノートPC 確認する

録画配信

該当の映像種別をクリックしレイアウトが切り替わる（フェードアウトする）ことを
AI解析結果表示ノートPC 確認する

クリック対象の映像種別

映像が切り替わるまでの時間（ｓ）

該当の映像種別が正常に切り替る
（〇×）

1秒未満

○

ストリーミング映像

1秒未満○

サーマル映像

1秒未満

○

1秒未満

○

ストリーミング映像

1秒未満○

サーマル映像

1秒未満

○

生映像

生映像

d）通信性能鉄道車両監視 AI システムについては、現地実証フィールドからの NW 遅延や映像伝送に影響する通信性能を、各種評価項目（スループット、遅延量、安定性など）にて評価を実施した。詳細結果を以下に記載する。
実証フィールドからクラウド環境までの測定区間においては、京急実証システムの NW 構成としてドコモオープンイノベーションクラウドとの（クラウドダイレクト接続）、DL 型実証システムにおいての NW 構成としてアマゾン・ウェブ・サービス（AWS）（インターネット
経由）の伝送品質と遅延等を計測、比較した。
図 4.4.1.2-21 に示すように、アップリンクスループット、ダウンリンクスループット、
ジッタ、パケットドロップ率、遅延量を iperf、ping のツールを使って計測した結果を比較した。
昨年度実証システム（環境１）：Xavier NX（クラウドダイレクト利用）〜クラウドダイレ
クト経由〜dOIC 上インスタンスの間※昨年度実証環境での計測データ引用
DL 型実証システム（環境２）：Xavier NX（sp モード利用）〜インターネット経由〜AWS 上
インスタンスの間

129

図 4.4.1.2-21

クラウドダイレクト接続とインターネット経由接続での計測区間

それぞれの測定区間の測定結果を表 4.4.1.2-19、表 4.4.1.2-20 に示す。
高精細映像（4K 映像）の送受信に関する送信端末～クラウド上のインスタンス、同インスタンス～解析結果表示 PC を模擬した受信端末の区間における伝送品質と遅延等を計測した。送信パケットを 30Mbps と 100Mbps に設定すると、上り下りスループットともに昨年度測定時と大きく差異がなく、鉄道車両監視 AI システムにて想定している 4K カメラ、サー
マルカメラ映像伝送時の上りパケット（30Mbps）を送信するには十分な帯域を確保できていることが確認できた。
表 4.4.1.2-19 R2 実証システム環境での測定結果（R2 実証測定データ引用）

表 4.4.1.2-20
区間
Xavier NX〜インターネット〜AWS※AWS試験測定用インスタンスまで

試験
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
ping
ping
ping
ping

R3DL 型実証システム環境での測定結果

送信時間 スループット
試験区分 パケットサイズ (sec)
試験回数(Mbps)
上り
1300
180
30
上り
1300
180
30
上り
1300
180
30
上り
1300
180
30 ※avg
下り
1300
180
30
下り
1300
180
30
下り
1300
180
30
下り
1300
180
30 ※avg
上り
1300
180
100
上り
1300
180
100
上り
1300
180
100
上り
1300
180
100 ※avg
下り
1300
180
100
下り
1300
180
100
下り
1300
180
100
下り
1300
180
100 ※avg-1300
180 --1300
180 --1300
180 --1300
180 -※avg

130bandwidth jitter
lost/total min
avg
max
(ms)
(Mbits)
パケット数
(ms)
(ms)
(ms)
1
28.63
0.25
0.04 ---2
28.95
0.64
0.01 ---3
29.70
0.25
0.01 ---29.09
0.38
0.02 ---1
29.83
0.20
0.01 ---2
29.89
0.05
0.00 ---3
29.89
0.02
0.00 ---29.87
0.09
0.00 ---1
94.00
0.50
0.06 ---2
98.49
0.43
0.01 ---3
96.30
0.52
0.04 ---96.26
0.48
0.04 ---1
93.44
1.29
0.07 ---2
97.06
0.02
0.03 ---3
98.34
0.03
0.02 ---96.28
0.45
0.04 ---1 ---48.54
65.87
2 ---48.12
66.45
3 ---44.69
65.36---47.12
65.90

268.3381.52
346.92232.26

stddev(ms)-----------------

16.51
7.01
23.25
15.59



映像インプットから画面表示までの遅延量推移評価
4K カメラからの高精細映像の伝送における、一定時間経過後の遅延量推移を計測するため、送受信された映像へ映る時計の時間差を比較した。
図 4.4.1.2-22 に示すように、昨年度実証では Xavier NX に接続している 4K カメラ前に
ノート PC を配置し、ミリ秒まで表示可能なデジタル時計をデスクトップ上に表示したうえ
で、配信された映像をブラウザで受信し、同じくディスプレイ上で横並びに表示することで時計の時間差を確認した。
計測する経過時間の設定は 30 分後と 1 時間後として、各経過時間時の解像度及び、フレームレート数やリソース状況を合わせて確認したが、時間経過による影響がない点を昨年度確認したことから今年度は、図 4.4.1.2-23 に示すように同様の測定構成をとりながら計測する経過時間の設定は 30 分後のみとした。

図 4.4.1.2-22 映像インプットから画面表示までの遅延量推移評価
R2 実証システム構成

図 4.4.1.2-23 映像インプットから画面表示までの遅延量推移評価
R3DL 型実証システム構成
それぞれの測定区間の測定結果を表 4.4.1.2-21、表 4.4.1.2-22 に示す。
測定は実証環境と同じ 4k カメラ及びサーマルカメラの映像を同時に伝送した。また、各々の伝送パラメータは 4k カメラが 4k30fps 映像を 15Mbps で、サーマルカメラは VGA30fps 映
像を 2.5Mbps にて伝送した。
結果として、今年度の実証システムにおいての遅延量は 0.41ms となり、安定した低遅延の映像配信が可能であることを確認した。
131

表 4.4.1.2-21 映像インプットから画面表示までの遅延量推移評価測定結果(R2 実証システム)

表 4.4.1.2-22 映像インプットから画面表示までの遅延量推移評価測定結果（R3DL 型実証システム）区間

試験

4Kカメラ～配信サーバインスタンス~
WebRTC
ノートPC
サーマルカメラ～配信サーバインスタンス~ WebRTC
ノートPC

送信時間
試験区分 (min)

H.264
H.264

スループット(Mbps) 試験回数 30分 経過時
タイマー
遅延時間
30
30
30
30

15
15 ※avg
2.5
2.5 ※avg

1
1

0.41
0.41

Momo
CPU%

24.17
24.17
23.50
23.5

MEM%
(8GB)

Sora

0.33
0.33
2.80
2.8

GPU%

0.00
0.00
0.00
0

CPU%

Chrome
MEM%
MEM%(32GB) CPU% (32GB)
17.70 0.02
717.70 0.02
74.80 0.51
3
4.8 0.51
3

23
23
22
22

GPU%
(VideoDecode)

Chrome WebRTCデバッグ
受信デコード ドロップ
解像度
フレーム数 フレーム数 フレーム数27
3840x2160
30 54031
1027
3840x2160
30 54031101
640x480
21 3893601
640x480
21 38936
04.4.1.3 DL 型アーキテクチャの実装可能性に関する結果
DL 型アーキテクチャの実装可能性に関する評価・検証として下記の評価・試験を実施した。
・5GSC へのアプリケーションの配置・ダウンロード機能確認
・ダウンロードした鉄道車両監視 AI アプリケーションの利用者環境への構築可否確認
・鉄道車両監視 AI システムの動作確認及び、昨年度の京急実証実験時との性能比
較
上記の評価・検証の結果から DL 型アーキテクチャに関して、「鉄道車両監視 AI エンジン」をコンテナ化し DL 型提供アプリケーションとして提供・他事業者環境でも利用をすることが可能であることを実証システム環境において確認することができた。

4.4.2 DL 型アプリケーションの水平展開可能性（工数削減効果）の確認
4.4.2.1 前提条件
他鉄道事業者への水平展開可能性を確認するため、コンテナアプリケーションを用いた利用者環境での構築の工程の確認及び、工数の変化について評価・検証を行った。

132

4.4.2.2 評価・検証（1）評価・検証項目
令和 2 年度、京急での実証システム構築時と今年度、DL 型鉄道車両監視 AI システム構築
時におけるシステム構築にかかる労務工程・プロセスについて比較検討を行った。特に鉄道
車両監視 AI エンジンの DL 型アプリケーション化による AI 開発工程での工数削減効果が期待されることを想定し、利用者におけるシステム環境構築・手配の容易さが DL 型提供方式
を活用することで改善されるかを考察した。

図 4.4.2.2-1 DL 型提供方式を利用した実証システム開発工程イメージ

図 4.4.2.2-2

鉄道車両監視 AI エンジン実装工程（2）評価・検証方法
令和 2 年度、京急での実証システム構築時と令和 3 年度の DL 型鉄道車両監視 AI システ
ム構築時におけるシステム構築にかかる労務工程・プロセスなどについて必要工程を洗い出し、ぞれぞれの必要工数を整理しシステム環境の手配にかかるコストの削減効果についての分析・整理を実施した。
133

（3）評価・検証結果
1）DL 型提供方式によるシステム設計・開発工数の削減効果「鉄道車両監視 AI システム」においてコンテナアプリケーション化した鉄道車両監視 AI
エンジンを利用する場合、令和 2 年度実証システム開発時に比べて全体での開発における工数の削減効果が得られることを確認できた。
令和 2 年度ローカル 5G 課題実証での京急実証システム開発時においてはフルスクラッチ
でのシステム開発を行った。開発の流れとしては京急との協議を重ねながら実証システム
で課題解決可能な要件を整理し、システム化構想範囲と要求の定義のためシステム要件定義を実施し、システム化範囲や実装・実現方法を設計し、これらを詳細設計として各システ
ム機能開発可能なパラメータとして開発者が設計を実施しシステムの開発・テストを実施した。
今年度の実証では昨年度開発をした「鉄道車両監視 AI システム」利用者環境である汎用
クラウド・コンテナ実行環境に DL 型提供アプリケーションを展開し、利用者がシステムを開発することで検討・設計に費やす工数のうち主に「クラウド基盤構築」、「クラウドリソー
ス準備の工程」、「AI エンジンの開発」において工数削減効果が確認できた。
（図 4.4.2.2-3）
定量的な削減効果として昨年度比率で約 60%の設計開発にかかる労務工数削減を実施できたことを確認できた。

図 4.4.2.2-3 DL 型利用での開発工数の昨年度比
鉄道車両監視 AI エンジンの実装までの開発フローを図 4.4.2.2-4 に示す。DL 型提供方式を採用することで汎用アプリケーションとして利用した AI エンジンの開発工程が削減され、AI モデル構築時の「アーキテクチャ設計」で約 60~70 人日程度の工数削減、及び、AI エン
ジンの開発工程の「システム設計・評価」部分での工程で約 80 人日程度の工数削減効果を確認できた。これらの工程については従来の開発工程では AI 開発者が実証システムでのシステム要求に基づいて都度、開発をしていたポイントであった。
汎用アプリケーション化された AI モデルを利用することが利用者における開発負担の軽減にもつながることを確認できた。一方で AI エンジン開発工程におけるモデル開発やエンジン開発については鉄道車両監視の検知対象物が変化することにより追加設計、学習デー
134

タ再作成における AI 再開発やシステム評価を都度実施することが必要であり、システム導入時には AI エンジンの開発工程については継続的に必要となる工数が発生することも併せて確認をした。

図 4.4.2.2-4 鉄道車両監視 AI

開発工程の削減

2）DL 型提供方式における課題
今年度は鉄道車両監視 AI システムを昨年度構築・開発した事業者にて DL 型提供方
式でのシステム再構築を実施したためシステムへの知識がある前提での評価・試験結果となった。今後、DL 型を選択する利用者が実際に鉄道車両監視 AI システムを構築する場合において同程度の DL 型提供方式での環境手配に対するメリットを享受できるよう利用者に対して「ソリューション利用マニュアルの整備」や「アプリケーション導入・構築支援」などのサポート方法や体制を検討することが必要である。
4.4.2.3 DL 型アプリケーションの水平展開可能性（工数削減効果）に関する結果
利用者の汎用クラウド・コンテナ実行環境に DL 型提供アプリを展開し、利用者がシステムを開発することで、検討・設計に費やす工数のうち主に「クラウド基盤構築」、「クラウド
リソース準備の工程」、「AI エンジンの開発」において工数削減効果が確認できた。
特に AI エンジンの汎用アプリケーション化によりアーキテクチャ・システムの設計工程が簡略化され複雑な AI エンジン開発の開発負担軽減につながったことが工数削減効果の大きな要因であった。
事業者にとって DL 型コンテナアプリケーションの提供形態は 5G ソリューションのシス
テム環境手配を行う上で従来より簡便な手法となり水平展開可能性が上がることが期待される。

4.4.3 DL 型アプリケーションの水平展開可能性（AI 検出性能影響・リアルタイム性）
及び実用性の確認
他鉄道事業者への鉄道車両監視 AI システムの水平展開可能性、実用性に関する実証実験
135

を実施した。DL 型実証システムとして今年度開発した「鉄道車両監視 AI システム」を用い、西鉄の筑紫車両基地を実証フィールドとしてシステムの性能評価・試験を実施した。また、本システムを列車検査業務に携わる現場技術者が利用するにあたり、西鉄実務者目線での実用性に関するデモ・アンケート調査を実施した。
4.4.3.1 評価・検証
DL 型実証システム環境及び 5G 環境下での鉄道車両監視 AI システムに対する評価・検証における①評価・検証項目②評価・検証手法③評価・検証結果をそれぞれ以下に記載する。
（1）評価・検証項目
5GSC から DL 型アプリケーションとして鉄道車両監視 AI をダウンロード・展開し、令和2 年度鉄道車両監視 AI システム同一の AI エンジン、同一システム環境を AWS 上に構築した。この DL 型実証システム環境を用いて昨年度実証と同様の検証・評価をおこなうため、AI による解析対象としては西鉄車両の映像による「ブレーキパッドのすり減り」「台車の亀裂（クラック）」「収容函のハンドル角度」「車軸温度」を対象として AI 検出性能や UI/映像
伝送システム、通信性能に対するシステム評価を行った。

1）AI 解析エンジン
AI 解析エンジンについては、「AI 検出性能に関する評価・検証」を行った。
西鉄車両の映像による「ブレーキパッドのすり減り」「台車の亀裂（クラック）」「収容函のハンドル角度」「車軸温度」の AI 検出性能を確認した。また、西鉄車両での「ブレーキパッドのすり減り」「台車のき裂（クラック）」「収容函のハンドル角度」「車軸温度」の映像を AI
モデルに追加学習させ、鉄道車両 AI システムにおいて他鉄道事業者の車両を用いた場合における検出性能の差異についても評価・検証した。
評価・検証においては、既存で利用した京急車両の AI 学習モデルを流用して検出可能な範囲の確認と共に、既存 AI モデルで検出ができない検知対象物について鉄道事業者毎に使う車台の違い、検出する対象物の違いなどにより AI モデルの追加学習が必要な内容であるかを確認した。
表 4.4.3.1-1

AI 検出性能に関する評価・検証項目

1362）UI・映像伝送システム
鉄道車両監視 AI システムにおいて、利用者のオペレーション観点で重要性の高いシステ
ム機能（具体的には、対象となる機能の特性に応じた遅延量や解析結果の表示性能など）を評価・検証した。
表 4.4.3.1-2

UI・映像伝送システムに関する評価・検証項目

3）通信性能鉄道車両監視 AI システムにおいて、無線 NW 区間、クラウド基盤の変更におけるネット
ワークに関するシステム性能影響を確認するためにシステム End-to-End 間及び各区間の通信性能（スループット、遅延量、ドロップ数/率）、システム End-to-End 間及び各区間の NW
基本性能（映像インプットから画面表示までの End-to-End の遅延量、スループット、測定
間隔、解像度、フレーム、各リソース量）を評価・検証した。
表 4.4.3.1-3 通信性能に関する評価・検証項目

137

（2）評価・検証方法
1）AI 解析エンジン
AI 検出性能面に関し、以下のように評価・検証した。
1）京急車両の学習モデルでの評価・検証と、西鉄車両の追加学習モデルでの評価・検証した。昨年度、京急車両を解析した AI エンジンの学習モデルにおいて昨年度モデルで西鉄車両の AI 解析の検出精度を評価した。また、西鉄車両映像を教師データとして再学習をさせた場合においての AI 解析の検出精度の変化を評価した。
◆AI 解析の検出精度評価
AI 解 析 の 検 出 性 能 評 価 に お い て 映 像 の フ レ ー ム ご と に 検 出 精 度 を 評 価 す る
Precision/Recall の評価軸ではなく、「検出率」、「網羅率」を指標として導入した。
※検出率：
１回の試行あたりにシステムが出した結果を積み上げ、「システムが検出したもののう
ち、真に正しい結果の割合」を評価した。
※網羅率：
１回の試行あたりにシステムが出した結果を積み上げ、「システムが検出すべきと定めた事物のうち、それを少なくとも１回、システムが検出した割合」を評価した。
◆解析処理性能AI 解析において映像解析処理性能について解析可能であったフレームレートを測定した。
◆解析処理遅延AI 解析において映像インプットから処理完了までの解析遅延量について測定した。

a）AI 解析エンジン評価-1 (AI 解析検出精度)
4K 固定カメラで撮影した高精細映像の AI 解析検出精度を評価する。
138

西鉄実証実験時の車両の走行パターン及び検知対象物の模擬については、昨年度同様に
以下の走行パターン及び模擬での検出を実施した。
表 4.4.3.1-4

表 4.4.3.1-5

車台のき裂検出における擬似き裂シールのパターン

車台のき裂検出における擬似き裂シールのパターンと車両の走行速度←西鉄福岡方向

3両目

先頭台車
前側(mm)
試験
セット

ptn

1

クラック水平＋ハンドル、ブ
レーキパッド2

クラック垂直＋ハンドル、ブ
レーキパッド

1,2
共通

サーマル

5km/h
5km/h
5km/h
10km/h
10km/h
10km/h
5km/h
5km/h
5km/h
10km/h
10km/h
10km/h

走行
回数
1
2
3
1
2
3
1
2
3
1
2
3

往復
往復
往復
往復
往復
往復
往復
往復
往復
往復
往復
往復

想定
時間
5分
5分
5分
5分
5分
5分
5分
5分
5分
5分
5分
5分

5km/h
5km/h
5km/h
10km/h
10km/h
10km/h

1
2
3
1
1
3

往復
往復
往復
往復
往復
往復

5分
5分
5分
5分
5分
5分

速度

方向

亀裂
はば
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1

先頭台車
※新品ブレーキパッド

後続台車
後側(mm)

前側(mm)

後側(mm)

前側(mm)

亀裂 クラック 亀裂
長さ 方向 はば
20 ヨコ 0.1
20 ヨコ 0.1
20 ヨコ 0.1
20 ヨコ 0.1
20 ヨコ 0.1
20 ヨコ 0.1
20 タテ 0.1
20 タテ 0.1
20 タテ 0.1
20 タテ 0.1
20 タテ 0.1
20 タテ 0.1

亀裂 クラック 亀裂
長さ 方向 はば
60 ヨコ 0.1
60 ヨコ 0.1
60 ヨコ 0.1
60 ヨコ 0.1
60 ヨコ 0.1
60 ヨコ 0.1
60 タテ 0.1
60 タテ 0.1
60 タテ 0.1
60 タテ 0.1
60 タテ 0.1
60 タテ 0.1

亀裂 クラック 亀裂
長さ 方向 はば
80 ヨコ 0.2
80 ヨコ 0.2
80 ヨコ 0.2
80 ヨコ 0.2
80 ヨコ 0.2
80 ヨコ 0.2
80 タテ 0.2
80 タテ 0.2
80 タテ 0.2
80 タテ 0.2
80 タテ 0.2
80 タテ 0.2

亀裂 クラック 亀裂
長さ 方向 はば
20 ヨコ 0.2
20 ヨコ 0.2
20 ヨコ 0.2
20 ヨコ 0.2
20 ヨコ 0.2
20 ヨコ 0.2
20 タテ 0.2
20 タテ 0.2
20 タテ 0.2
20 タテ 0.2
20 タテ 0.2
20 タテ 0.2

前側車軸

後側車軸

前側車軸

後側車軸

亀裂 クラック 亀裂
長さ 方向 はば
60 ヨコ 0.2
60 ヨコ 0.2
60 ヨコ 0.2
60 ヨコ 0.2
60 ヨコ 0.2
60 ヨコ 0.2
60 タテ 0.2
60 タテ 0.2
60 タテ 0.2
60 タテ 0.2
60 タテ 0.2
60 タテ 0.2

前側車軸
サーマルカイロサーマルカイロサーマルカイロサーマルカイロサーマルカイロサーマルカイロ139

2両目

後側(mm)

前側(mm)

亀裂 クラック 亀裂
長さ 方向 はば
80 ヨコ
1
80 ヨコ
1
80 ヨコ
1
80 ヨコ
1
80 ヨコ
1
80 ヨコ
1
80 タテ
1
80 タテ
1
80 タテ
1
80 タテ
1
80 タテ
1
80 タテ
1
後側車軸

亀裂 クラック 亀裂
長さ 方向 はば
20 ヨコ
1
20 ヨコ
1
20 ヨコ
1
20 ヨコ
1
20 ヨコ
1
20 ヨコ
1
20 タテ
1
20 タテ
1
20 タテ
1
20 タテ
1
20 タテ
1
20 タテ
1

前側車軸
サーマルカイロサーマルカイロサーマルカイロサーマルカイロサーマルカイロサーマルカイロ後側(mm)

停車位置方向→1両目

後続台車※交換レベルブレーキパッド

先頭台車
前側(mm)

後続台車
後側(mm)

前側(mm)

後側(mm)

亀裂 クラック 亀裂
長さ 方向 はば
60 ヨコ
1
60 ヨコ
1
60 ヨコ
1
60 ヨコ
1
60 ヨコ
1
60 ヨコ
1
60 タテ
1
60 タテ
1
60 タテ
1
60 タテ
1
60 タテ
1
60 タテ
1

亀裂 クラック 亀裂
長さ 方向 はば
80 ヨコ
2
80 ヨコ
2
80 ヨコ
2
80 ヨコ
2
80 ヨコ
2
80 ヨコ
2
80 タテ
2
80 タテ
2
80 タテ
2
80 タテ
2
80 タテ
2
80 タテ
2

亀裂 クラック 亀裂
長さ 方向 はば
20 ヨコ
2
20 ヨコ
2
20 ヨコ
2
20 ヨコ
2
20 ヨコ
2
20 ヨコ
2
20 タテ
2
20 タテ
2
20 タテ
2
20 タテ
2
20 タテ
2
20 タテ
2

亀裂 クラック 亀裂
長さ 方向 はば
60 ヨコ
2
60 ヨコ
2
60 ヨコ
2
60 ヨコ
2
60 ヨコ
2
60 ヨコ
2
60 タテ
2
60 タテ
2
60 タテ
2
60 タテ
2
60 タテ
2
60 タテ
2

亀裂 クラック
長さ 方向
80 ヨコ
80 ヨコ
80 ヨコ
80 ヨコ
80 ヨコ
80 ヨコ
80 タテ
80 タテ
80 タテ
80 タテ
80 タテ
80 タテ

後側車軸

前側車軸

後側車軸

前側車軸

後側車軸

図 4.4.3.1-3 車台のき裂検出における擬似き裂シール添付場所

図 4.4.3.1-4

収容函ハンドルの開閉異常検知場所

図 4.4.3.1-5 ブレーキパッドすり減り検知b）AI 解析エンジン評価-2 (AI 解析検出率)
サーマルカメラで撮影した映像の AI 解析検出率等を評価する。

140

図 4.4.3.1-6

図 4.4.3.1-7

車軸の温度異常検出

車軸の温度異常検出時の温度比較場所◆評価方法
車軸ベアリングの異常温度を検出し、台車のひびや歪み等について間接的な示唆を得て、4K 固定カメラの AI 検出結果との整合性・非整合性の観点から実運用におけるサーマルカ
メラの映像の有用性を評価する。検出対象箇所は台車の車軸部分とする。映像に映り込む範囲において検査庫の床温度と車軸部分の温度差が 20℃以上ある場合に異常検知させた。
◆測定項目
「検出率」
、
「網羅率」を指標として測定した。
※検出率（再掲）：
１回の試行あたりにシステムが出した結果を積み上げ、「システムが検出したもののう
ち、真に正しい結果の割合」を評価した。
※網羅率（再掲）：
１回の試行あたりにシステムが出した結果を積み上げ、「システムが検出すべきと定めた事物のうち、それを少なくとも１回、システムが検出した割合」を評価した。

c）AI 解析エンジン評価-3 (AI 解析処理性能)
AI 解析の処理遅延を評価する。

141

図 4.4.3.1-8

AI 解析処理遅延評価方法◆評価方法
AI エンジンへ映像が到達してから、Web サーバインスタンスへ座標等情報を送出した時間の差を図り、処理遅延の評価をする◆測定項目
・列車検査のサーマルカメラのストリーミング配信映像
・列車検査の 4K 高精細ストリーミング配信映像
2）UI・映像伝送システム
UI・映像伝送システムに関しては、以下を評価する。
① AI 解析結果 Web サイトへの接続性評価
解析結果表示 PC のブラウザ画面から AI 解析結果 Web サイトへ接続し、想定した接続ができる事を評価する。
内容としては、正常接続性、接続時リードタイムなどを評価する。
② 結果表示各機能の想定動作評価
結果表示各機能について、設計想定のとおり機能動作できる事を評価する。
各機能評価は、以下のとおりとする。

142

図 4.4.3.1-9

UI・映像伝送システム評価イメージ

表 4.4.3.1-6

UI・映像伝送システム評価ポイントa）UI・映像伝送評価-1 (映像伝送)
4K30fps 映像が正常表示されているかを評価する。

143

図 4.4.3.1-10

UI・映像伝送評価方法-1◯測定区間
1：AI 解析結果表示ノート PC（Chrome ブラウザ） ※ストリーミング配信映像
2：AI 解析結果表示ノート PC（Chrome ブラウザ）※録画映像◯測定項目：
1：chrome ブラウザ上でストリーミング配信される映像品質。WebRTC デバック（解像度、フレームレート）にて確認
2：chrome ブラウザ上で再生される録画映像品質（4K30fps） WebRTC デバック（解像度、フレームレート）にて確認

b）UI・映像伝送評価-2 (ストリーミング映像配信)
目的ストリーミング映像の適切表示、AI 検知箇所特定の矩形（バウンディングボックス）の適切表示、ストリーミング映像描画までの時間を評価する。

図 4.4.3.1-11

UI・映像伝送評価方法-2
144

◯測定区間
1～3： AI 解析結果表示ノート PC（Chrome ブラウザ）◯測定項目：
1：UI 上で該当リンクをクリックした時に、ストリーミング映像が再生される。
（目視）
2：UI 上で該当リンクをクリックしてから、ストリーミング映像が再生開始されるまでの時間（ストップウォッチ計測）。
3：意図的に異常状態を作り適切な場所にバウンディングボックスが表示されるか。

c）UI・映像伝送評価-3 (録画映像配信)
目的録画映像の適切表示、総合シークバーによる再生指定、元映像と AI 検出映像の時間
同期、AI 検知箇所特定の矩形（バウンディングボックス）の適切表示、録画映像描画までの時間を評価する。

図 4.4.3.1-12

UI・映像伝送評価方法-3d）UI/映像伝送評価-4 (UI レイアウト)
表示映像種別の選択による正常表示動作、映像選択時のレイアウト切替時間を評価する。

145

図 4.4.3.1-13

UI・映像伝送評価方法-43）通信性能a）通信性能評価-1 (現地⇔クラウド区間 NW 性能測定)
AWS（インターネット経由）の伝送品質と遅延等を計測、比較する（netperf、iperf、ping）※R2 実証実験では、ドコモオープンイノベーションクラウド（クラウドダイレクト経由）環境での測定を実施。

図 4.4.3.1-14

通信性能評価方法-1〇実施環境
西鉄筑紫車両基地工場◯測定区間
Xavier NX〜インターネット経由〜AWS 上試験測定用インタンス◯測定項目：
1：上りスループット UDP（送信パラメータ：30、100Mbps）、計測：bandwidth、jitter、
lost/total パケット数 ※3 回の計測値、またその平均を用いる
2：下りスループット UDP（送信パラメータ：30、100Mbps）、計測：bandwidth、jitter、146

lost/total パケット数 ※3 回の計測値、またその平均を用いる※UDP パケットサイズは、実際の映像伝送データに近しい値を用いる。送信時間
180sec、表示インターバル 1sec
3：レイテンシ（RTT）：(サイズは映像データに近しい値)、送信時間 180sec、表示イン
ターバル 1sec、計測：min/avg/max/stddev ※3 回の計測値、またその平均を用いる

b）通信性能評価-2 (End-To-End 遅延測定)
・4K カメラ、サーマルカメラの WebRTC 伝送時、一定時間経過の遅延量推移を計測する。

図 4.4.3.1-15

通信性能評価方法-2〇実施環境
西鉄実証筑紫車両基地工場◯測定区間
・Xavier NX〜WebRTC インスタンス〜AI 解析結果表示ノート PC◯測定項目：
1：測定種別 4K カメラ、サーマルカメラ
2：コーデック：H.264
3：映像配信クライアント：WebRTC Momo
4：フレーム数：4K カメラ 30fps、サーマルカメラ 30fps
5：都度、確認内容：ノート PC 上の Chrome WebRTC デバッグ（解像度、再生中フレーム
数、受信フレーム数、デコードフレーム数、ドロップフレーム数）
6：コンピュータのリソース確認：Xavier NX（Momo）、WebRTC インスタンス（Sora）、受信
ノート PC（Chrome 動作機）
、CPU、MEM、GPU のリソース量推移
7：試験時間、回数：各項目で 30 分送信を 1 回実施。

（3）評価・検証結果
鉄道車両監視 AI システムに対する評価・検証結果を以下に記載する。
147

1）AI 解析エンジン
AI 検出性能面に関する評価・検証
AI 検出性能面に関する評価・検証は、昨年度実証と同様に検出率と網羅率を指標として結果を整理した。AI 検出性能面に関する評価・検証結果は以下の通りである。

a）従来 AI モデルでの西鉄車両の AI 検出結果


クラック検出
昨年度開発した AI モデルを利用して西鉄車両の疑似クラック（水平・垂直）の検出結果

を 走 行 速 度 （ 5km ・ 10km） ご と で 解 析 結 果 を記載 す る 。 疑 似 ク ラ ッ ク に つい て は 幅
0.1mm,0.2mm,1mm,2mm の計 4 パターンで検証を実施したがどのパターンでも検出ができな
かったことを確認した。
表 4.4.3.1-7

AI 検出性能面に関する評価・検証結果(疑似クラック)
検出率

網羅率
車両へ貼り付けた

走行速度

5km

10km

システムが検出しなかった対象のうち
真に正しい結果の数

疑似クラック数

システムが検出した対象のうち
真に正しい結果の数検知しなかった中で検知しなかった中で検知した中で正しかった数

間違っていた数正しかった数検知した中で間違っていた数

水平クラック

36

0

36

0

0

垂直クラック

36

0

36

0

0

小計

72

0

72

0

0

水平クラック

36

0

36

0

0

垂直クラック

36

0

36

0

0

小計

72

0

72

0

0

148



図 4.4.3.1-16

疑似クラック垂直貼り付け

図 4.4.3.1-17

疑似クラック水平貼り付け

ハンドル開閉状態
昨年度開発した AI モデルを利用して西鉄車両のハンドルの開閉状態の検出結果を走行速度（5km・10km）ごとで結果を記載する。ハンドルの異常開閉状態について既存 AI モデルでの検出を確認することができた。
表 4.4.3.1-8 AI 検出性能面に関する評価・検証結果(ハンドル)

149

検出率

網羅率
走行速度

対象ハンドル数

試験回数

システムが検出しなかった対象のうちシステムが検出した対象のうち

真に正しい結果の数

真に正しい結果の数検知しなかった中で正しかった数

20

5km

20

正しかった数検知した中で間違っていた数

0

3

17

2

2

0

3

17

0

3

0

3

17

2

0

9

51

4

1

0

5

15

0

2

0

5

15

2

3

0

4

16

0

0

14

46

2

小計

図 4.4.3.1-18


間違っていた数

1

小計
10km

検知しなかった中で 検知した中でハンドル異常模擬セッティング

ブレーキパッドのすり減り
昨年度開発した AI モデルを利用して西鉄車両のブレーキパッドの厚みの検出結果を走行

速度（5km・10km）ごとでの結果を記載する。検出対象となる摩耗したブレーキパッドについては既存 AI モデルでの検出を確認することができた。
表 4.4.3.1-9 AI 検出性能面に関する評価・検証結果(ブレーキパッド)

150

検出率

網羅率
走行速度

対象ブレーキパッド

試験

数

回数

システムが検出しなかった対象のうちシステムが検出した対象のうち

真に正しい結果の数

真に正しい結果の数検知しなかった中で検知しなかった中で 検知した中で正しかった数125km

間違っていた数12

検知した中で間違っていた数

1

0

2

10

0

2

0

3

8

0

3

0

2

9

1

0

7

27

1

1

0

5

5

0

2

0

5

6

1

3

0

3

9

0

0

13

20

1

小計
10km

正しかった数小計

図 4.4.3.1-19 ブレーキパッド異常模擬セッティング

車軸の温度異常（サーマル）
昨年度開発した AI モデルを利用して西鉄車両の車軸の温度異常の検出結果を走行速度（5km・10km）ごとでの結果を記載する。検出対象となる電気カイロを貼り付けた表面温度
20 度を超える車軸については既存 AI モデルでの検出を確認することができた。
表 4.4.3.1-10

AI 検出性能面に関する評価・検証結果(車軸熱)
網羅率

走行速度

サンプル数

検出率

システムが検出しなかった対象のうちシステムが検出した対象のう

真に正しい結果の数

ち

検知しなかった中で正しかった数検知しなかった中で 検知した中で間違っていた数正しかった数検知した中で間違っていた数

5km

36

0

0

36

0

10km

36

0

0

36

0

151

図 4.4.3.1-20
表 4.4.3.1-11

車軸の熱異常模擬セッティング

AI 検出性能面に関する評価・検証結果(車軸熱)152車両側情報no 試験回目
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

1
1
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
3
3
1
1
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
3
3

台車設定
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目

後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車

車軸異常
走行速度( km) カ イ ロ 有無

後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側

5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10

〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
-

153

性能評価
異常/正常
温度
閾値10度
14. 9
正常
15. 1
正常
14. 9
正常
15. 0
正常
16. 4
正常
28. 3
異常
16. 6
正常
29. 2
異常
14. 8
正常
14. 3
正常
14. 4
正常
14. 3
正常
15. 8
正常
14. 9
正常
15. 8
正常
14. 9
正常
14. 5
正常
28. 4
異常
16. 5
正常
29. 3
異常
14. 4
正常
10. 0
正常
10. 1
正常
14. 9
正常
16. 1
正常
14. 6
正常
16. 8
正常
14. 9
正常
14. 8
正常
28. 4
異常
15. 9
正常
29. 3
異常
14. 1
正常
14. 7
正常
14. 9
正常
14. 0
正常
16. 6
正常
14. 2
正常
13. 8
正常
16. 7
正常
17. 1
正常
28. 1
異常
15
正常
29. 1
異常
13. 9
正常
14. 6
正常
14
正常
14. 7
正常
14. 5
正常
14. 3
正常
14. 6
正常
15. 2
正常
14. 3
正常
28. 1
異常
14. 8
正常
28. 3
異常
14. 6
正常
14. 9
正常
14. 3
正常
14. 4
正常
14. 1
正常
14. 5
正常
14. 4
正常
15. 3
正常
13. 8
正常
28. 0
異常
14. 9
正常
29
異常
14. 4
正常
14. 6
正常
14. 6
正常
14
正常

動画情報
動画名
sec
47

47



AI 解析処理性能
AI 解析において映像解析処理性能について解析可能であったフレームレートを測定した

結果を記載する。


4K 固定カメラ映像

実証実験での解析フレームレートを集計し概ね 12FPS で処理が行われており、DL 型実証
システムの机上検討の際に計算した解析処理性能が出ていることを確認した。

図 4.4.3.1-21
AI 解析処理フレーム数（4K カメラ映像）

サーマルカメラ映像

実証実験での解析フレームレートを集計し概ね 5FPS で処理が行われており、DL 型実証
システムの机上検討の際に計算した解析処理性能が出ていることを確認した。

図 4.4.3.1-22


AI 解析処理フレーム数（サーマルカメラ映像）

AI 解析処理遅延
AI 解析において解析映像がインプットされてから解析処理が完了するまでの解析遅延量について測定した結果を記載する。
154



4K 固定カメラ映像

実証実験での 1 フレーム当たりの処理速度を集計し概ね、200msec 以内に処理が完了しており、机上検討での想定性能が出ていることを確認した。

図 4.4.3.1-23


AI 解析処理遅延（4K カメラ映像）

サーマルカメラ映像
実証実験での 1 フレーム当たりの処理速度を集計し概ね、300msec 以内に処理が完了しており、机上検討での想定性能が出ていることを確認した。

図 4.4.3.1-24


AI 解析処理遅延（サーマルカメラ映像）

既存 AI 学習モデルを利用した西鉄車両の AI 検出性能結果のまとめ「既存 AI モデル×京急車両(パターン①)」「既存 AI モデル×西鉄動画(パターン②)」との比較を行った結果、パターン①と比較して、パターン②ではクラックを検出することができなかった。
（図 4.4.3.1-25,表 4.4.3.1-12 参照）
昨年度実証実験時と比べて、155

疑似クラックの貼付け箇所や車両を撮影するカメラの画角が変わったなどの実証フィ
ールドの変更による要因も検出性能が落ちた原因と考えられる。クラック検出は AI 解
析の解析対象の中でも細かな検知対象物となり精微な画像解析・判定が必要であることから、従来の学習モデルを利用した解析では判定が難しく新たに西鉄車両の映像データを用いた AI モデルの再学習などにより AI 検出性能の改善を図ることが必要であると判定した。

図 4.4.3.1-25
表 4.4.3.1-12

AI 検出結果パターン比較グラフ pattern①×pattern②（クラック）
AI 検出結果パターン比較表 pattern①×pattern②（クラック）

ハンドルの開閉状態についても同様にパターン比較を行った結果、パターン①と比較して、検出性能は多少落ちるものの、概ね既存 AI モデルでも検出できることを確認できた。
（図 4.4.3.1-26,表 4.4.3.1-13 参照）一般に、AI モデルは、各物体の境界面(エッジ部分)
を強く認識して、学習・予測を行うため、形状が似た物体に対しては検出性能が高くなる
ことが要因と思われる。
156

図 4.4.3.1-26
表 4.4.3.1-13

AI 検出結果パターン比較グラフ pattern①×pattern②（ハンドル）AI 検出結果パターン比較表 pattern①×pattern②（ハンドル）「既存 AI モデル×京急車両(パターン①)」「既存 AI モデル×西鉄動画(パターン②)」との比較を行った結果、既存 AI 学習モデルを利用した解析では判定が難しい検知対象物が存在するため、西鉄車両の AI 検出性能を高める方法として新たに西鉄車両の映像
データを用いたモデルの再学習・追加学習により AI モデルの検出性能の改善を図ることが必要であると判定した。西鉄車両の AI モデルの再学習・追加学習を実施した場合の検出性能の改善に関する評価・試験結果について後述する。

b）追加学習 AI モデルでの西鉄車両の AI 検出結果


クラック検出西鉄車両追加学習 AI モデルを利用して西鉄車両の疑似クラック（水平・垂直）の検出結果を走行速度（5km・10km）ごとでの結果を記載する。疑似クラックについては幅
0.1mm,0.2mm,1mm,2mm の計 4 パターンで検証を実施した。クラックについては検出性能が改善されクラックが各走行速度でそれぞれ検出できたことを確認した。
表 4.4.3.1-14

AI 検出性能面に関する評価・検証結果(クラック)
157

網羅率
車両へ貼り付けた

走行速度

5km

10km



検出率

システムが検出しなかった対象のうちシステムが検出した対象のうち

真に正しい結果の数

疑似クラック数

真に正しい結果の数検知しなかった中で検知しなかった中で検知した中で正しかった数

間違っていた数正しかった数検知した中で間違っていた数

水平クラック

24

0

16

20

1

垂直クラック

24

0

12

24

0

小計

48

0

28

44

1

水平クラック

24

0

25

11

5

垂直クラック

24

0

17

19

0

小計

48

0

42

30

5

ハンドル開閉状態
西鉄車両追加学習 AI モデルを利用して西鉄車両のハンドルの開閉状態の検出結果を走行

速度（5km・10km）ごとでの結果を記載する。ハンドルの異常開閉状態については追加学習
AI モデルでも問題なく検出を確認することができた。
表 4.4.3.1-15

AI 検出性能面に関する評価・検証結果(ハンドル)
検出率

網羅率
走行速度

対象ハンドル数

試験回数

システムが検出しなかった対象のうちシステムが検出した対象のうち

真に正しい結果の数

真に正しい結果の数検知しなかった中で正しかった数

5km

20

20

検知した中で正しかった数

間違っていた数

0

0

20

2

2

0

0

20

6

3

0

0

20

2

0

0

60

10

1

0

0

20

1

2

0

0

20

3

3

0

0

20

2

0

0

60

6

小計



間違っていた数

1

小計
10km

検知しなかった中で 検知した中でブレーキパッドのすり減り
西鉄車両追加学習 AI モデルを利用して西鉄車両のブレーキパッドの厚みの検出結果を走

行速度（5km・10km）ごとでの結果を記載する。検出対象となる摩耗したブレーキパッドについては追加学習 AI モデルでも問題なく検出を確認することができた。
表 4.4.3.1-16

AI 検出性能面に関する評価・検証結果(ブレーキパッド)

158

走行速度

対象ブレーキパッド

試験

数

回数

網羅率

検出率

システムが検出しなかった対象のうち真にシステムが検出した対象のうち真に正しい

正しい結果の数

結果の数

検知しなかった中で検知しなかった中で 検知した中で正しかった数5km

12

間違っていた数

12

0

0

10

2

2

0

0

10

2

3

0

0

10

2

0

0

30

6

1

0

0

10

2

2

0

0

11

1

3

0

0

11

1

0

0

32

4

小計



間違っていた数

1

小計
10km

検知した中で正しかった数

車軸の温度異常（サーマル）
西鉄車両追加学習 AI モデルを利用して西鉄車両の車軸の温度異常の検出結果を走行速度（5km・10km）ごとでの結果を記載する。検出対象となる電気カイロを貼り付けた車軸については追加学習 AI モデルでも問題なく検出を確認することができた。
表 4.4.3.1-17

走行速度

サンプル数

AI 検出性能面に関する評価・検証結果(車軸熱)
網羅率

検出率

システムが検出しなかった対象のうち真にシステムが検出した対象のう

正しい結果の数

ち真に正しい結果の数検知しなかった中で正しかった数検知しなかった中で 検知した中で間違っていた数正しかった数検知した中で間違っていた数

5km

36

0

0

36

0

10km

36

0

0

36

0

表 4.4.3.1-18

AI 検出性能面に関する評価・検証結果(車軸熱)159車両側情報no 試験回目
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

1
1
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
3
3
1
1
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
3
3

台車設定
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目
1両目
1両目
1両目
1両目
2両目
2両目
2両目
2両目
3両目
3両目
3両目
3両目

後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車
後続台車
後続台車
先頭台車
先頭台車

車軸異常
走行速度( km) カ イ ロ 有無

後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側
後側
前側

5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10

〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
-

160

性能評価
異常/正常
閾値10度
15. 9
正常
14. 3
正常
14. 8
正常
16. 8
正常
13. 8
正常
28. 8
異常
15. 9
正常
29. 4
異常
14. 7
正常
10. 1
正常
14. 6
正常
14. 5
正常
16. 1
正常
14. 5
正常
17. 3
正常
14. 9
正常
16. 1
正常
28. 6
異常
16. 4
正常
29. 3
異常
15. 3
正常
14. 6
正常
16. 4
正常
14. 6
正常
15. 9
正常
15. 0
正常
13. 7
正常
14. 9
正常
14. 9
正常
28. 5
異常
14. 9
正常
29. 0
異常
14. 6
正常
14. 3
正常
15. 0
正常
14. 2
正常
15. 9
正常
14. 8
正常
16. 1
正常
14. 9
正常
16. 1
正常
28. 4
異常
15. 0
正常
29. 1
異常
10. 0
正常
10. 0
正常
14. 2
正常
14. 6
正常
15. 8
正常
14. 0
正常
14. 8
正常
14. 1
正常
14. 1
正常
27. 8
異常
15. 5
正常
28. 6
異常
13. 9
正常
14. 7
正常
14. 9
正常
14. 1
正常
14. 1
正常
13. 6
正常
14. 3
正常
14. 5
正常
13. 7
正常
28. 1
異常
16. 0
正常
28. 8
異常
9. 9
正常
14. 1
正常
14. 0
正常
14. 0
正常
温度

動画情報
動画名

sec
47

47

c）AI 解析処理性能
AI 解析において映像解析処理性能について解析可能であったフレームレートを測定した
結果を記載する。


4K 固定カメラ映像

実証実験での解析フレームレートを集計し概ね 12FPS で処理が行われており、DL 型実証
システムの机上検討の際に計算した解析処理性能が出ていることを確認した。

図 4.4.3.1-27


AI 解析処理フレーム数（4K カメラ映像）

サーマルカメラ映像

実証実験での解析フレームレートを集計し概ね 10FPS で処理が行われており、DL 型実証
システムの机上検討の際に計算した解析処理性能が出ていることを確認した。

図 4.4.3.1-28


AI 解析処理フレーム数（サーマルカメラ映像）

AI 解析処理遅延
161

AI 解析において解析映像がインプットされてから解析処理が完了するまでの解析遅延量について測定した結果を記載する。


4K 固定カメラ映像

実証実験での 1 フレーム当たりの処理速度を集計し概ね、250msec 以内に処理が完了しており、机上検討での想定性能が出ていることを確認した。

図 4.4.3.1-29
AI 解析処理遅延（4K カメラ映像）

サーマルカメラ映像

実証実験での 1 フレーム当たりの処理速度を集計し概ね、200msec 以内に処理が完了しており、机上検討での想定性能が出ていることを確認した。

図 4.4.3.1-30


AI 解析処理遅延（サーマルカメラ映像）

追加 AI 学習モデルを利用した西鉄車両の AI 検出性能結果のまとめ
162

「既存 AI モデル×西鉄動画(パターン②)」「追加学習 AI モデル×西鉄動画(パターン③)」との比較を行った結果、西鉄現地実証で計 5 日程度の車両映像データを追加学習させることで、検出性能の改善が確認できた。（図 4.4.3.1-31,表 4.4.3.1-19 参照）
クラックについては、垂直より水平方向に張り付けた疑似クラックの方が検出率/網羅率
共に検出精度が高いことを確認した。垂直クラック貼付箇所には車台の傷や汚れが多く見られ、クラックとそれ以外の判別が難しく、撮影条件による要因により画像解析における検出精度を落としたと推測される。全体的に目視が容易であれば(幅が広く長いクラック)検
出精度が高く、目視が困難な場合(細く短いクラック)は精度が低くなる傾向が見られた。
一部細く長いクラックにも反応していたが、今回クラックの模擬に利用したシールに反射した光に反応している様子が見られた。走行速度は、10km より 5km の場合で検出精度が高くなる傾向が見られた。10km 走行時には検出機会が少ないことに起因して精度が低下したと推測される。GPU マシンリソースを追加・増強することで、AI 解析処理可能なフレームレートを増やすことができれば、5km 時での検出精度に近づくことが見込まれる。

図 4.4.3.1-31
表 4.4.3.1-19

AI 検出結果パターン比較グラフパターン②×パターン③（クラック）
AI 検出結果パターン比較表パターン②×パターン③（クラック）

163

ハンドルの開閉状態についても同様にパターン比較を行った結果、若干の偽陽性は残るものの、追加学習により網羅率の向上が確認できた。
（図 4.4.3.1-32,表 4.4.3.120 参照）偽陽性自体は、西鉄車両映像のさらなる追加学習により改善できる見込みである。

図 4.4.3.1-32
表 4.4.3.1-20

AI 検出結果パターン比較グラフパターン②×パターン③（ハンドル）AI 検出結果パターン比較表パターン②×パターン③（ハンドル）

164

ブレーキパッドのすり減りについても同様にパターン比較を行った結果、若干の偽陽性は残るものの、追加学習により網羅率の向上が確認できた。（図 4.4.3.1-33,表
4.4.3.1-21 参照）ハンドル検出時同様、偽陽性自体は、西鉄車両映像のさらなる追加
学習により改善できる見込みである。

図 4.4.3.1-33

AI 検出結果パターン比較グラフパターン②×パターン③（ブレーキパッド）

表 4.4.3.1-21

AI 検出結果パターン比較表パターン②×パターン③（ブレーキパッド）

1652）UI・映像伝送システム
UI・映像伝送システムに関する評価・検証結果は以下の通りである。
a）UI・映像伝送評価-1 (映像伝送)
UI・映像伝送システムについて、4K30fps の映像が正常表示されているかを以下の測定区
間（図 4.4.3.1-34）にて試験・評価した。
結果としては、ストリーミング配信映像及び録画映像についても正常に配信ができることを確認した。(表 4.4.3.1-22 参照)

図 4.4.3.1-34

UI・映像伝送システム性能測定区間

鉄道車両監視システムの UI 表示画面（ストリーミング映像(図 4.4.3.1-35)、録画映像画
面(図 4.4.3.1-36）)において確認を実施した。

図 4.4.3.1-35

車両監視のストリーミング映像表示画面

166

図 4.4.3.1-36
表 4.4.3.1-22

4k30 フレーム映像が正常表示されるかの評価

4K30フレーム映像が正常表示されているかを評価する
4Kカメラ
映像配信規格
映像種別
試験対象区間
webRTCインスタンス～
AI解析結果表示ノートPC
4K30fps
ストリーミング配信

4K30fps

車両監視の録画映像表示画面

確認方法

経過時間

解像度

chromeデバック

1分後

3840x2160

30

5分後

3840x2160

30

10分後

3840x2160

30-

3840x2160

30

webサーバインスタンス～
AI解析結果表示ノートPC

録画配信

フレーム数

b）UI・映像伝送評価-2 (ストリーミング映像配信)
UI・映像伝送システムについて、目的映像が正常表示されているかを試験・評価した。結果としては、ストリーミング配信映像及び録画映像についても正常に表示・再生ができることを確認した。(表 4.4.3.1-23 参照)

表 4.4.3.1-23

目的映像が適切に表示されるかの評価

目的映像が適切に表示されるかを評価する
対象UI

確認端末

該当映像が
再生される（〇×）

確認方法

再生が開始されるまでの時間（ｓ）

ストリーミング配信 AI解析結果表示ノートPC 該当リンクをクリックする○

0.220～0.761(6回測定)

録画配信

○

13～57(9回測定)

AI解析結果表示ノートPC 該当リンクをクリックする

UI・映像伝送システムについて、AI で検知した個所の矩形位置情報（バウンディングボ
167ックス）が適切表示されているかを試験・評価した。結果としては、ストリーミング配信映
像、録画映像についても正常位置に矩形位置情報（バウンディングボックス）が表示されることを確認した。(表 4.4.3.1-24 参照)
表 4.4.3.1-24

AI 検知箇所特定のバウンディングボックスが適切に表示されるかの評価

AI検知箇所特定の矩形（バウンディングボックス）が適切に表示されるかを評価する

対象UI
確認端末
確認方法
ストリーミング配信 AI解析結果表示ノートPC 意図的に異常状態を作り、適切な位置にバウンディング
ボックスが表示されるか
目視で確認する。

録画配信

AI解析結果表示ノートPC 意図的に異常状態を作り、適切な位置にバウンディング
ボックスが表示されるか
目視で確認する。

異常箇所数（1画像当たり）

バウンディングボックスが適切な位置に表示される（〇×）

1ヶ所
○
2か所

○

3か所

○

1ヶ所
〇
2か所

〇

3か所

〇

c）UI・映像伝送評価-3 (録画映像配信)
UI・映像伝送システムについて、録画映像におけるシークバーによる再生個所の指定が可
能かを試験・評価した。結果としては、録画映像にてシークバーを任意の場所への移動したとき、正常に映像が表示されることを確認した。(表 4.4.3.1-25 参照)
表 4.4.3.1-25

録画映像総合シークバーによる再生指定の評価

録画映像総合シークバーによる再生指定
対象UI
録画配信

確認端末
確認方法
AI解析結果表示ノートPC シークバーを任意の場所へ移動したとき、生映像と矩形付き映像が同じ時間軸で再生されることを確認する

時間軸の同期が取れている（〇×）〇d）UI/映像伝送評価-4 (UI レイアウト)
UI・映像伝送システムについて、ストリーミング配信映像、録画映像におけるレイアウトの切り替わり時間について試験・評価した。結果としては、ストリーミング配信映像、録画映像にて正常に映像レイアウトの切り替わり時間が想定結果であることを確認した。(表4.4.3.1-26 参照)
まず、ストリーミング映像について、～10 分間の経過時間に応じて、遅延が重畳されることなく正常に 4k30fps の映像を表示できていることを確認した。
次に、映像表示の Web ページリンクをクリックした後、何秒後に映像を表示できるかを評168価した。このとき、ストリーミング映像はクリック後 1 秒以下で表示された。一方で、録画映像は最長 1 分程度で表示された。これは、録画映像の全編をダウンロードしてから表示する仕様であったため、時間を要している。ダウンロードと表示を同時に行う仕様に変更する
ことで、録画映像表示までのリードタイムを短くすることが可能であると考えられる。
また、本実証の映像中には複数の解析結果（バウンディングボックス）が同時に表示される必要があるため、その表示性能を確認した。結果として、異常状態の数によらず、適切に複数の異常状態を検出することができていることを確認した。
特に録画映像については、機能として、シークバーの再生操作が、複数映像に適切に作用しているかを評価した。シークバーを操作したとき、生映像、AI 解析結果映像、サーマル
カメラ映像の全てを、時刻同期させた状態で、適切な時刻に移動・再生することができることを確認した。
最後に、映像選択時の特定映像への表示切り替え機能について確認した。ライブ映像、録画映像ともに、即座の切替えが可能であることを確認した。
表 4.4.3.1-26

表示映像種別の選択による正常表示、映像選択時のレイアウト切替時間の評価

表示映像種別の選択による正常表示動作、映像選択時のレイアウト切替時間を評価する

対象UI

確認端末

クリック対象の映像種別

確認方法

該当の映像種別をクリックしレイアウトが切り替わる（フェードアウトする）ことをストリーミング配信 AI解析結果表示ノートPC 確認する

録画配信

該当の映像種別をクリックしレイアウトが切り替わる（フェードアウトする）ことを
AI解析結果表示ノートPC 確認する

該当の映像種別が映像が切り替わるまでの 正常に切り替る
（〇×）
時間（ｓ）

0.0043○

ストリーミング映像

0.0044○

サーマル映像0.0042○0.0042○

ストリーミング映像

0.0049○

サーマル映像0.0053

○

生映像

生映像

3）通信性能通信性能に関する評価・検証結果は以下の通りである。
a）通信性能評価-1 (現地⇔クラウド区間 NW 性能測定)
アップリンクのスループット、ダウンリンクのスループットは昨年度クラウドダイレク
ト接続（dOIC）とインターネット経由（AWS）の間で顕著な違いはなかった。これより 5G 環
境で適切な無線環境のもとで一定のパケットを送る場合、スループット自体はインターネ
ット経由の AWS と dOIC では同程度であると言える。一方、遅延量に関しては、クラウドダ
イレクト接続の方がインターネット経由と比較して遅延が少ない結果であった。これは、インターネット経由でのクラウド環境接続と比較して、クラウドダイレクト経由でのクラウド環境接続のほうが、より少ないノード数を経由して到達しているためであると考えられ169る。ただし、本システムの上り通信帯域要件（30Mbps）を送信するには十分な帯域を確保できていることが確認できた。
表 4.4.3.1-27
区間
Xavier NX〜インターネット〜AWS※AWS試験測定用インスタンスまで

試験
iPerf
iPerf
(train Jetson～インターネット～WebRTC) iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
iPerf
ping
ping
ping
ping

試験区分
上り
上り
上り
上り
下り
下り
下り
下り
上り
上り
上り
上り
下り
下り
下り
下り
上り
上り
上り
上り
下り
下り
下り
下り
-----

通信性能評価-1

送信時間
スループット
パケットサイズ (sec)
試験回数(Mbps)
1300
180
30
1300
180
30
1300
180
30
1300
180
30 ※avg
1300
180
30
1300
180
30
1300
180
30
1300
180
30 ※avg
1300
180
100
1300
180
100
1300
180
100
1300
180
100 ※avg
1300
180
100
1300
180
100
1300
180
100
1300
180
100 ※avg
1300
180 -1300
180 -1300
180 -1300
180 -※avg
1300
180 -1300
180 -1300
180 -1300
180 -※avg
1300
180 -1300
180 -1300
180 -1300
180 -※avg

1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3

試験回数

※avg

※avg

※avg

※avg

※avg

※avg

※avg

測定結果

bandwidth jitter(Mbits)
(ms)
1
29.92
2
30.01
3
29.90
29.95
1
28.88
2
28.50
3
29.06
28.81
1
99.20
2
99.12
3
92.16
96.83
1
85.22
2
85.28
3
84.43
84.98
1
91.88 -2
92.11 -3
88.71 -90.90 -1
234.82 -2
181.21 -3
358.42 -258.15 -1 --2 --3 -----

0.58
0.97
1.13
0.89
0.29
0.22
0.21
0.24
0.23
0.28
0.32
0.28
0.23
0.27
0.22
0.24

lost/totalminmax
stddev
パケット数
(ms)
(ms)
(ms)
0.00 ---0.00 ---0.00 ---0.00 ---0.04 ---0.05 ---0.03 ---0.04 ---0.01 ---0.01 ---0.08 ---0.03 ---0.15 ---0.16 ---0.17 ---0.16 ------------------------------------52.13 300.83-55.39 150.76-51.39 207.03-52.97 219.54

42.18
22.40
18.07
27.552b）通信性能評価-2 (End-To-End 遅延測定)
カメラ映像の伝送における、一定時間経過後の遅延量推移を計測するため、送受信された映像へ映る時計の時間差を比較した。
図 4.4.3.1-37 に示すように、Xavier NX に接続している 4K カメラ前にノート PC を配置
し、ミリ秒まで表示可能なデジタル時計をデスクトップ上に表示したうえで、配信された映像をブラウザで受信し、同じくディスプレイ上で横並びに表示することで時計の時間差を確認した。
計測する経過時間の設定は 30 分後として、各経過時間時の解像度及び、フレームレート
数やリソース状況を合わせて確認した。

図 4.4.3.1-37

通信性能評価-2

測定区間

測定結果を表 4.4.3.1-28 に示す。
測定は実証環境と同じ 4K カメラ及びサーマルカメラの映像を同時に伝送した。また、各々の伝送パラメータは 4K カメラが 4k30fps 映像を 10Mbps で、サーマルカメラは VGA30fps 映170

像を 2.5Mbps にて伝送した。
結果として、遅延量は 1.4ms となり、安定した低遅延の映像配信が可能であることが確認できた。時間の経過による遅延量の増加傾向は見られなかったことから、時間と遅延量には依存性がないことが考えられる。
表 4.4.3.1-28

区間（1）4Kカメラ（2）サーマルカメラ

試験
WebRTCWebRTCWebRTCWebRTC

通信性能評価-2

測定結果

送信時間 スループット
タイマー
試験区分 (min)(Mbps) 試験回数 遅延時間
CPU%
MEM% GPU% CPU% MEM% CPU% MEM%
H.264
30
10
1
1.4
27.5
3.08
0
17.30 0.02
26
H.264
30
10 ※avg
1.352
27.5
3.08
0
17.3 0.02
26
H.264
30
2.5
1
13.83
0.28
0.00
5.00 0.03
46
H.264
30
2.5 ※avg
13.83
0.28
0.00
5.00 0.03
46

29
29
30
30

GPU%

21
21
1
1

受信 デコード ドロップ
解像度 フレーム数 フレーム数 フレーム数
3840x2160
30 51247 2514
3840x2160
30 51247 2514
640x480
22 372260
640x480
22 37226
04.4.3.2 DL 型アプリケーションの水平展開可能性（AI 検出性能影響・リアルタイム性）に関する結果（1）AI 検出性能影響の確認
DL 型システム環境において AI モデルを昨年度モデル・今年度再学習した再開発モデル、解析する映像を昨年度の京急車両の録画データおよび、今年度の実証フィールドでの車両映像とし、それぞれのパターンでの AI システムの性能を測定、比較を行った。

図 4.4.3.2-1

AI 検出性能評価パターン

AI 解析の解析対象の中でも精微な画像解析・判定が必要であり解析の難易度が高いクラック検出において比較を行った結果を記載する。
ベースライン：昨年度実証での検出率・網羅率の水準は、AI 検出と検査員による目視検171

査とのクロスチェックをすることで業務運用可能と判断された。
パターン①：低廉化のためのシステム構成の見直しによる処理リソース削減により、AI 解析処理性能(解析可能なフレーム数)は、
昨年度 20fps から今年度は 12fps まで低下したが、5km,10km の走行速度の映像検出であれば検出性能の低下までにはならなかった。
パターン②： AI モデルが京急モデルを利用していたため、西鉄の車両の検出ができな
かった。
パターン③： AI モデルを西鉄モデルとして追加学習させた結果、昨年度の検出性能と同程度の検出を確認した。
※垂直方向のクラックの検出率が低下したが、現地の撮影条件によるもので AI エンジンに起因するものではなかった。撮影機材の性能向上や撮影環境の最適化によって改善可能なものであった。
実証システムを用いて AI 検出を実施した結果、AI の処理性能が低下したが、検査対象データの追加学習により AI 検出性能への影響は最小限に抑えることができ、昨年度同水準のアプリケーションを他社に水平展開可能であることを確認できた。

図 4.4.3.2-2 AI 検出性能評価結果（クラック検出）（2）リアルタイム性の確認
通信性能評価の試験結果より、昨年度との遅延時間差異としては 0.46 秒の増加に留まり、検査工程の観点から、秒単位での緊急性はなく本ソリューションの運用において、AI による不具合検出後、検査車両が停止してから作業員が目視で検査を行うことからリアルタ
イム性においての影響は軽微であることを確認した。

172

図 4.4.3.2-3

リアルタイム性の影響測定結果

4.4.3.3 DL 型アプリケーションの実用性評価（1）「鉄道車両監視 AI システム」 デモ・アンケートによる評価
本システムを列車検査業務に携わる現場技術者が利用するにあたり、西鉄実務者目線での実用性に関する調査を行い、その結果を示す。評価内容をユーザインタフェース（UI）の利便性、機材の有用性、導入可能性とし、アンケート調査を実施した。なお、本結果は、調査時に職員が複数人で協議しながら、筑紫車両基地工場職員としての意見を取りまとめていただいたものである。
a）ユーザインタフェースの利便性
ユーザインタフェースの利便性について、ヒアリングを行った。事前に西鉄から列車検査業務への改善期待を寄せられていたこともあり、実運用を想定したときに高い評価を得る
ことができた。次に使用した機材について、本システムに実装している機材として、4K カメラ、映像の視認性・AI 検知結果の表示確認の観点で、サーマルカメラについては、温度の視認性・AI 検知結果の表示確認の観点で、実運用に資すると評価を受けた。また、追加機材の要望としては、図 4.4.3.3-10 に示す。振動・音の検知機材など様々はセンシングデ
バイスが挙げられた。
また、本システムで検知した対象物（台車のき裂、ハンドルの開閉、ブレーキパッドの摩耗）についても、実運用を想定したときに必要性が高いことを確認でき、本システムの実用可能性を示唆する結果である。図 4.4.3.3-11 に示す通り、今回検出した対象物・ユースケース以外に何を検知したいのかを集計した結果、京急でのアンケート結果とは異なる要望が多様に確認することができた。

173b）5G-AI システムの機能
5G-AI システムの機能について、ヒアリングを行った。より一層の安全性向上に関しては高い評価を受けたものの、現場技術者の目線では、「稼働効率化について、どれだけの人員削減、あるいは他業務への有効な割り当てが想定できるかが定量的に導入効果の判断がつかないため実際にコスト削減・検査の網羅に繋がるか吟味が必要」「数分の業務低減くらいでは魅力にならない」等の意見を受けた。実運用に向けては、安全性がどの程度向上し、人のオペレーションとどのように親和していけるのか、より深い運用評価が必要であること
が西鉄実証にあたっても確認することができた。

Q1.1 Web画面のレイアウト・見た目はいかがでし
たか？
普通
30%
良い
50%

やや良い
良い

20%
やや良い

図 4.4.3.3-1

普通

やや悪い

悪い

無回答

アンケート統計グラフ（Q1.1）

Q2.1 4Kカメラについて、実運用を想定したときに、十分な映像品質だと感じましたか？
ややそう感じる
18%

そう感じる
そう感じる

ややそう感じる

図 4.4.3.3-2

普通82%
ややそう感じない

そう感じない無回答

アンケート統計グラフ（Q2.1）

174

Q2.2 サーマルカメラについて、実運用を想定したときに、十分な映像品質だと感じましたか？
無回答

あまりそう感じない

9%

9%
普通
9%

そう感じる
55%

ややそう感じる18%
そう感じる

ややそう感じる

図 4.4.3.3-3

普通

あまりそう感じない

全くそう感じない

無回答

アンケート統計グラフ（Q2.2）

Q2.3. 台車亀裂の検出の必要性について教えて
下さい。

無回答
あまりそう感じない9%

9%
ややそう感じる
9%

そう感じる
73%
そう感じる

ややそう感じる

図 4.4.3.3-4

普通

あまりそう感じない

全くそう感じない

無回答

アンケート統計グラフ（Q2.3）

Q2.3. ハンドルの開閉の検出の必要性について教
えて下さい

普通
36%

必要
46%

やや必要
必要

やや必要

18%
普通

あまり必要ない

175

全く必要ない無回答

図 4.4.3.3-5

アンケート統計グラフ（Q2.3）

Q2.3. ブレーキパッドの摩耗の検出の必要性について教えて下さい。
全く必要ない
18%

普通

必要

9%

46%

やや必要
27%
必要

やや必要

図 4.4.3.3-6

普通あまり必要ない

全く必要ない無回答

アンケート統計グラフ（Q2.3）

Q3.1 AI検知により、異常箇所を見分けやすいと感じましたか？

ややそう感じる
36%

そう感じる
64%

そう感じる

ややそう感じる

図 4.4.3.3-7

普通

あまりそう感じない

全くそう感じない

無回答

アンケート統計グラフ（Q3.1）

Q3.2 AI検知により、将来的に実業務の効率化
や、より一層の安全性向上に貢献できると感じます
無回答

か？

9%
ややそう感じる
18%

そう感じる
73%
そう感じる

ややそう感じる

図 4.4.3.3-8

普通

あまりそう感じない

全くそう感じない

無回答

アンケート統計グラフ（Q3.2）
176

Q3.4 将来的に鉄道事業（車両部門）への5G
導入可能性について教えて下さい。

無回答
36%

可能性がある46%

可能性がややある
可能性がある18%

あまり可能性はない

図 4.4.3.3-9

図 4.4.3.3-10

可能性がややある

普通

可能性は全くない

無回答

アンケート統計グラフ（Q3.4）

今後利用要望のある測定手段についての集計

177

図 4.4.3.3-11 今後利用要望のある AI 検知対象物・ユースケースについての集計 （その他フリーアンサー抜粋）
Q AI 検知により、将来的に実業務の効率化やより一層の安全性向上に貢献できると感じますか？
・判定精度を高め、様々な部位を判定すること将来的な省力化に繋げることが可能と思われるため、業務の効率化や安全性の向上に十分寄与できると思う。
・人間が絡むヒューマンエラーを極限まで回避できると思った、人間による曖昧な、個人差のある判断が無くなると思う
・現在の目視検査を AI に置き換えることで、作業者の負担軽減、作業の効率化につながると感じた
Q AI 検知システムを導入するにあたり、実業務を想定した課題を教えて下さい。
・導入コスト(設備導入費、通信費等)、AI 技術者の養成・確認する箇所が多岐に及び、固定カメラでは一部しか対応できない、車内の確認では、
固定カメラでは対応でき無さそう・AI が確実に全数をチェックしたか確認する方法の確立
Q

今回は 5G 技術を活用することで、4K 映像等を用いた AI 検知システムを構築しました。将来的に鉄道事業（車両部門）における 5G の導入可能性（領域・用途）と課題について、ご意見下さい。

・画像認識は、可能性が無限大にあり、使う側のアイデア次第で大きなメリットとなり得ると思う・どれだけの人員削減、あるいは他業務への有効な割り当てが想定できるかが課題と思う。車両保守の観点では、AI でも人でもできる内容が実際にコスト削減・検査の網羅に繋がるか吟味が必要。数分の業務低減くらいでは魅力にならないかと思う。
・5G の活用により、「自社工場内で新たにネットワークを作成する」「保管するサーバを用意する」「専門会社が来場してのソフトウェアのアップデートや不具合修正などの各178

種対応」といった AI 検知システム導入に当たっての障害が大幅に取り除かれるため、
5G を活用しない場合と比較して、非常に導入しやすいと感じる。
・現在車両のモニタ装置に集約されている各機器の状態データを地上側にリアルタイムに送信することにより故障の前兆の把握やトラブル発生時に対応の迅速化が図れると考える。今後ワンマン運転の拡大や将来的な自動運転を考えると、車内の映像をリアル
タイムに地上側で確認する必要が出てくると思われるので、大容量のデータ通信は不可欠だと考える（2）DL 型アプリケーション実用性に関する結果
本システムの鉄道事業分野への導入にあたっては、画像認識を活用したユースケースは、可能性が無限大にあり、使う側のアイデア次第で大きな業務改善メリットを生み出すとの期待が上がり、コンテナアプリケーションを用いた利用方式であれば、ニーズのあるユース
ケースに応じて各鉄道事業者に対応したアプリケーションを追加開発・柔軟に利用者環境に導入ができる可能性があることを確認できた。
導入への課題としては、AI 検知システム、5G ネットワークともに、システムの安全性・信頼性と導入時のイニシャル費用と保守管理の稼働及びランニング費用のコスト観点が挙げられる。
私鉄各社において導入費用等の課題を乗り越えるには１社の取組みではなく私鉄各社一丸となっての鉄道業界水平展開可能な課題解決システムのシェアリング利用の検討が早急に実装化に向けて必要であることが確認できた。今年度、鉄道事業分野での協議検討会を擁立しこの課題の検討を実施した結果について後述する。

4.5 実証結果まとめ「鉄道車両監視 AI システム」を用い、AI 映像解析エンジンを DL 型アプリケーションとして再開発し、今年度、他社環境でダウンロード・構築することが技術的に実装可能であることを確認するとともに、実装可能性、水平展開可能性、実用性の評価を行い、DL 型提供
によるアプリ汎用化が、利用者のシステム構築負担や利用開始までの期間短縮の効果があること、また、コスト低廉化を企図したシステム性能低減についても AI 学習によって補正が可能であることが確認できた。
4.5.1 評価・試験結果の整理評価・試験結果を以下の観点毎で結果を整理した。
(1)実装可能性(2)水平展開可能性(3)実用性179

（1）実装可能性
DL 型で提供されるコンテナアプリケーションを活用して利用者環境へのシステムが構築できることから DL 型アーキテクチャが実装可能であることを確認した。
（2）水平展開可能性
当該システムが異なる利用者環境でも NW やクラウドリソースのスペックダウンによる動作影響を確認し、AI モデルの再学習などによる性能補正の対処を行うことで、業務利用水準に至ることを確認した。
システム設計・開発フェーズにおいての工数削減効果についても AI エンジンの環境設計
工程が簡素化され開発にかかる負担の軽減を確認できた。但し、利用者のシステム導入の難
易度に課題が残る。

（3）実用性
当該システムは業務効率化や安全性向上へつながる期待が高く、DL 型コンテナアプリケーションであれば、ニーズのあるユースケースに応じて各鉄道事業者に対応したアプリケーションを追加開発・柔軟に利用者環境に導入ができるメリットがあることを確認したが、導入課題としては費用対効果面であり、実業務への活用は、定量的な効果測定をするなど、より深い運用評価を行う必要がある。
4.5.2 DL 型の課題と SaaS 型検証の必要性
図 4.5.2-1 のように導入時の課題として利用者が主体的にシステム構築・開発を進める必要がある点、DL 型提供方式で提供されるアプリケーションの利用要件が当初の想定利用要件から異なるケースでは追加開発が必要となる点などシステム導入難易度に対する課題が残ることも想定される。
これらの課題に対して提供方式として、SaaS 型のような 5GSC が用意したクラウド環境を利用者が利用するというような方式も考えられる。
DL 型の提供者に対する導入リードタイムの短縮やコスト低減等に関する有効性は良好ではあるが、提供方式として、SaaS 型のような 5GSC が用意したクラウド環境で提供者がソリューションを利用できるよう環境を準備し、利用者がこの環境を利用するというようなア
プリケーション提供方式の検討も必要と考えられる。

180

図 4.5.2-1

DL 型鉄道車両監視 AI システムにおける利用課題

4.5.2.1 SaaS 型提供の検討
導入の容易性や、費用対効果等の観点で引き続きの検討が必要であるが、さらなる利用者負担の低減を目指し、より共用部分の多い SaaS 型提供の検討を行い、協議会と連携したユースケースの具体化・共有化も進めたい。
DL 型提供方式と SaaS 型提供方式の利用者における構築範囲を比較した際には、DL 型提供方式よりも SaaS 型提供報のほうが利用者の導入負担が少ないことが想定される。
一方で 5G ソリューション提供に十分な低遅延・大容量を実現するための適切なサーバ、
ネットワーク配置、SaaS 化できない周辺ハードウェア、ソフトウェアの取扱い等、論点も多く存在し、別途 SaaS 化を進めるためには検証を行う必要がある。

図 4.5.2.1-1 「鉄道車両監視 AI システム」での SaaS 提供イメージ

181

5. 5GSC の普及啓発活動の実施
5GSC の取組について、自治体、鉄道業界への取組の説明や実施に向けたインタビュー、媒体を通しての取組に関する告知などの普及啓発活動を実施した。
5.1 自治体への 5GSC 取組の説明とインタビュー
地方自治体などの今後、5G ソリューションの普及展開を担う事業者実施主体となりうる団体に対して今年度 5GSC の調査事業の一環として 5GSC の取り組み概要やコンソーシアム
で検討されたサービスコンセプト案に対するヒアリング活動への協力をいただいた。
以下の表 5.1-1 の実施概要に示す総計 25 自治体に、5GSC 調査検討概要、5GSC の構想概要を説明すると共に、5GSC で想定されるサービスなどを説明し、協業/利用ができそうか、できる場合はどのようなものか、できない場合は何が課題かなどをヒアリングした。
また、自治体が行っている 5G 利用及び DX 推進・デジタル利活用に係る取組の実情をヒアリングし、意見交換を目的とした自治体へのインタビューを実施した。
表 5.1-1

自治体へのインタビュー実施概要

・自治体へのインタビュー結果を踏まえた次年度以降の連携の方向性
5GSC の調査検討の取り組みについて早期より認識・活動に協力をいただく団体の数が増えることで次年度以降、5GSC の調査事業への継続的な協力及び連携可能があると考える。

5.2 各団体への 5GSC 事業の普及啓発活動
5.2.1 5GSC 普及の取組としての鉄道協議会の設立
・鉄道協議会の組成、定例会議の実施
私鉄 5 社と国土交通省鉄道局専門官を加え、「5G 等を活用した遠隔・リアルタイムでの列車検査システム等の普及展開」に関する協議会を設置した。

5.2.1.1 鉄道協議会の開催
第１回協議会では、ニーズを幅広く集め、共通事項等について整理した。第２回協議会で182

は、それらのニーズ・共通事項より、共通プラットフォームであるソリューション提供セン
ターへの実装可能性について実証システムの横展開の可能性も含め議論・整理を行った。
第 2 回協議会では、西鉄における実証結果や、協議会構成員である京浜急行、東急における総務省ローカル 5G 実証の結果等について情報交換を行うとともに、共通ニーズの把握や今後事業者間の連携により、プラットフォーム化に向けての取り組みを行うことの意義・効果について意見交換を行った。また、次年度以降 5GSC の調査事業の継続に向けて協議会を継続することの方向性について確認を行った。
開催回
第１回
令和 4 年2 月 2 日（水）9:30-12:00

第２回
令和 4 年 3 月 15日（火）9:30～
12:00

議 題
【議事次第】（１）委員等紹介（２）5G ソリューションセンター（SC）及び今年度の実証について（３）鉄道事業者における鉄道ＤＸ等の取り組み関する話題提供
１）京浜急行電鉄株式会社
２）西日本鉄道株式会社
３）京阪電鉄株式会社
４）南海電鉄株式会社
５）東急電鉄株式会社【論点】○各社の取り組み状況、課題から見えてくる共通ニーズの発掘○京急、西鉄における実証システムの発展形のイメージ○鉄道事業者の共通ニーズを踏まえた、実証システム以外での課題
解決システムの可能性○鉄道事業者の横の連携による技術協力・技術開発等、第一歩の歩
みだしの可能性○共通プラットフォーム化の効果【議事次第】（１）第１回協議会の議事要旨確認（２）実証を踏まえた実装・横展開の課題について
１）西鉄におけるプラットフォーム化実証結果概要
２）京浜急行電鉄における総務省実証結果概要
３）東急電鉄における総務省実証結果概要（３）鉄道ＤＸに資する技術ニーズと事業者間連携の可能性について（４）まとめ【論点】〇第 1 回協議会を踏まえた鉄道事業者の共通ニーズ〇事業者関連携の可能性〇協議会の継続について

5.2.1.2 鉄道協議会での協議・合意内容
プラットフォーム化によるデータアセット共有や導入コスト低減など事業者間連携への可能性、車両検査ソリューションなどへのニーズが高く事業者からの協力可能性が高いこ183

となどの賛同が得られたことから、協議会を継続的に立上げて事業者間での営み連携・拡大をすることを各鉄道事業者で合意された。

図 5.2.1.2-1

協議会を通じた鉄道車両監視 AI の普及展開イメージ

5.2.2 鉄道車両監視 AI の普及展開方策検討協議会からの提言
協議会を通して、ソリューションニーズ、事業者間連携、プラットフォーム化への期待に関して提言がなされ、次年度以降の協議会の継続テーマが挙げられた。
キーワード・ニーズ
「鉄道車両監視 AI システム」などのソリューションニーズ
映像を用いた AI 画像解析・検知技術への期待値は非常に高くソリューションの導入・実装への事業者協力は得やすい状況である。



事業者間連携
複数社で協力することでより多くのセンシングデータなどを収集できる。これら活用できる共有プラットフォームや AI 解析サービスの仕組みがあれば、事業者間連携の実現可能性がある。



プラットフォーム化への期待
実証実験を行うにあたってもある程度のコストがかかるので、コストを事業者間でシェアできる仕組みが必要である。
184



協議会の継続テーマ


画像や AI 等のセンサ技術や通信技術を用いた鉄道事業の効率化・省人化・付加価値創出に向けた技術課題の解決とプラットフォーム化の取り組み



5GSC として新たな課題解決テーマでの実証等可能性の検討

5.3 5GMF を通じた 5GSC 調査事業の取組み状況の掲載
5GSC 調査事業の活動を継続的に実現することを目的に本年度実証取り組み開始時に取り組み開始の告知について、第 5 世代モバイル推進フォーラム（5GMF）を通じた情報発信を行うこととした。以下内容については、実証開始時点で今年度調査事業の開始を告知した内容
である。

185

5G ソリューション提供センターの取組
2021.11.17
総務省の「「5G ソリューション提供センター（5GSC）」の構築等に係る調査検討」に関し、株式会社 NTT ドコモが受託し、5G を活用したソリューション提供・利活用に係る企業とユーザーのマッチングプラットフォームの検討に着手されました。
本事業は株式会社 NTT ドコモのほか、日本アイ・ビー・エム株式会社、エヌ・ティ・ティ・コミュニケーションズ株式会社が参加し、5G ネットワークの利活用を促進すべく、
5G ソリューションの利用者とソリューションの提供者のマッチングプレイスの創出を企図しプラットフォーム構築を行います。
また、その市場受容性の調査、事業化に向けた課題とその解決策の調査を行うため、コンソーシアムを設立し、検討を行います。
上記環境の実現により、利用者は自社の事業を促進させる安全な 5G ソリューションを
本環境から選択・活用することが可能となり、提供者は自社が知りえない利用者との機会を通じて事業が拡大・促進できるだけでなく更なるサービスの向上に集中できる環
境を得ることが可能になります。

図：5G ソリューション提供センター（仮称）のイメージ
出典：総務省「Beyond 5G 推進戦略－6G へのロードマップ－」
また、昨年度実証が行われた「鉄道インフラのリアルタイム遠隔・自動監視システムの実証試験」のシステムを本事業のプラットフォームに実装し、鉄道会社の協力を得て、専用環境の構築ではなく、頒布可能なプラットフォーム上での実用性についての実証実験が実施されます。
※ドコモ 報道発表
5G と高速 AI ディープラーニングを活用！鉄道インフラのリアルタイム遠隔・自動監視システムの構築に成功 （nttdocomo.co.jp）（出典：5GMF <https://5Gmf.jp/local5G-kanmin/4790/> ）186

6. 本年度実施総括
6.1 サービスコンセプトの検討
サービスコンセプトの仮説、有識者・自治体・企業へのインタビューを通し、5GSC のサービスやプラットフォーム設計のポイントを整理した。

（1）サービスコンセプトの仮説
5G ユースケース、5G を先行活用している IoT ベンダーの取組および、主要パブリックク
ラウド業者の 5G 活用状況について調査を行い、5G の特徴である大容量、低遅延、多数同時接続を活用し、企業に役立てるサービスのコアコンセプト案を５つ仮説した。

（2）有識者・自治体・企業インタビューの結果仮説した５つのサービスコンセプト案に対する客観的意見を求めるため、有識者、自治体、
ローカル 5G 関係者へインタビューを実施した。
インタビュー対象は、表 6.1-1 インタビュー対象一覧にまとめる。
表 6.1-1 インタビュー対象一覧
第一回ヒアリング 東京大学 高木 聡一郎 准教授
有識者インタビュー
第二回ヒアリング 東京大学 中尾彰宏 教授
栃木県、福井県、高知県、神奈川県、埼玉県、大阪府、長崎
自治体ヒアリング県、愛知県、宮崎県、新潟県、香川県、佐賀県、宮城県、沖187

ローカル 5G 関係者

縄県、福島県、愛媛県、島根県、仙台市、福岡市、千葉市、静岡市、堺市、神戸市、京都市、北九州市の計 25 自治体
令和 3 年度実証 26 事業中、24 事業の代表企業

これらのインタビューより、5GSC への期待・意見をまとめたところ、いずれのサービ
スコンセプトに対しても賛同があった。
特に、「ワンストップでたどり着ける環境」「企業等連携」「安価・多様なアプリ提供環境」への要望があった。
以上のことから、サービスコンセプト案の具体化に向けて更なる磨き込みは必要になる
ものの、現時点における 5GSC のサービス設計やプラットフォーム設計の際に考慮が必要なポイントとして、「ポータル機能」、「コミュニケーション機能」、「アプリケーション提供機能」の３点を整理した。
１．ポータル機能
事例情報や各種ノウハウ情報（標準も含む）を集約し、目的の情報に最短でたどり着けるサービス/システム設計の検討
２．コミュニケーション機能
各種相談ができる問い合わせ機能、企業連携等が促進できるコミュニケーション
機能の検討
３．アプリケーション提供機能
以下を包含したアプリケーション提供方式の検討(ア) 企業単独でアプリ導入をするよりも低コスト且つ効率的に導入できるアプリ
ケーション提供方式(イ) 機能単位での組み合わせ等を考慮した多様なアプリケーション提供を意識したプラットフォーム設計
6.2 提供プラットフォームの検討
5G アプリを容易に共用・提供できる環境として、クラウドの活用を有力な手段と考え、
5G 特性を活用したプラットフォームのあり方として通信とクラウドの連携を重視し、カメラやセンサーといった多様なデバイス、AI 等と組み合わせたソリューションが実現可能である点を考慮して、5GSC の提供方式の検討を行った。

（1）5GSC の提供方式
今年度の実証では、映像をリアルタイムに AI 判定するソリューションを実施対象としていることから、5G ネットワークの低遅延性を活かしつつ、要件によってアプリケーション
を柔軟にカスタマイズでき、導入の容易性も高い DL 型での検討を行うこととした。

188

（2）DL 型プラットフォームに求められる機能
DL 型でソリューションを利用者に提供する場合に 5GSC として具備するべき機能として、「ポータル」、「アプリケーション提供」、「課金」、「利用者提供者コミュニケーション」のカテゴリに分けて整理を行った。
今年度の実証においては、DL 型提供におけるアプリケーションの実行とその評価を実施
するため必要となる、「ポータル」「アプリケーション提供」の２つのカテゴリにおける諸機能を構成することとした。

図 6.2-1 5GSC プラットフォームのアーキテクチャ概要（3）検証結果
5GSC の「ポータル機能」「アプリケーション提供機能」についての検証を行った。
 「ポータル機能」は、利用者が情報を確認し、アプリケーションをダウンロード
し、自身の環境で実行できることを確認した。
 「アプリケーション提供機能」は、クラウドに提供者からアプリケーションをアップロードできること及び、利用者環境へダウンロード、アプリケーションを展開できることを確認した。

189

図 6.2-2

5GSC「ポータル機能」「アプリケーション提供機能」検証（4）今後の課題
アプリケーション提供方法を多様化するために、本実証で使った DL 型だけでなく、SaaS型で提供する場合に必要となる検討事項として、どのようなアプリケーションやサービスを選定するか、GPU などのリソース提供をどうするか、課金体系/方法、サービス運用/運営体制をどうするか等がある。
また、複数企業利用を想定した場合に、プラットフォーム自体にどのような機能（例えば、ユーザー管理、課金機能、画面 UI/UX、非機能要件等）の追加が必要になるのかの検討が必要である。

6.3 DL 型利用環境における実証
昨年度開発した「鉄道車両監視 AI システム」をダウンロード型のコンテナアプリケーシ
ョン提供方式で再開発したシステムを他事業者にて利用可能か、システム導入時の工数短
縮やコスト低減は期待されるのか、について、実装可能性、水平展開可能性、実用性の観点から課題分析・対処策の検討を行った。

（1）DL 型アーキテクチャの実証概要
DL 型実証システムとして昨年度開発した「鉄道車両監視 AI システム」を用い、昨年度開発した AI 映像解析エンジンを DL 型コンテナアプリケーションとして再開発し、今年度西
日本鉄道株式会社（以下、西鉄）システム環境にダウンロード・構築を行った。
西鉄筑紫車両基地を実証フィールドとし、 実装可能性、水平展開可能性、実用性の観点を確認すべくシステムの性能評価・試験やデモ・アンケート調査を実施した。

190

図 6.3-1 DL 型アーキテクチャの実証概要（2）検証結果
R2 年度ローカル 5G 実証成果である「鉄道車両監視 AI システム」を 5GSC のプラットフォームに格納し、実証協力企業（西鉄）の環境で DL 型アーキテクチャを用いた実証を実施。
「実装可能性」「水平展開可能性」「実用性」の観点で有効性を確認できた。
①実装可能性・ダウンロード型で提供されるコンテナアプリケーションを活用して他社システム環境に「鉄道車両監視 AI システム」を構築できることを確認した。
・ダウンロード型で提供されるアプリケーションを用いてのシステム開発は利用者において導入難易度が高い点が課題となる。
②水平展開可能性
・DL 型で構築した「鉄道車両監視 AI システム」が異なる利用者環境においても動作可能であることを確認した。
・DL 型提供方式を利用することで従来方式よりシステム設計・開発フェーズでの工数削減効果を確認した。
・DL 型提供方式とすることで柔軟にリソース選択が可能であり、システム構成要素のコスト削減が可能であった。ただし、システム運用時には AI の検出性能補正などの対処などは検討が必要であった。
③実用性
・DL 型アプリケーションとして「鉄道車両監視 AI システム」の利用は、鉄道業界において業務効率化/安全性向上へつながる期待があることを確認した。
・システム導入の課題として費用対効果が挙げられ、定量的な運用効果の測定が必要であることを確認した。

（3）今後の課題
DL 型アーキテクチャの実証結果より、システム導入を行う利用者においてシステム導入
191難易度や費用対効果面の課題があり、これらの課題を解決する手法として SaaS 型アーキテ
クチャでの検証及び DL 型アーキテクチャとの比較検討が求められる。
6.4 普及啓発活動の実施
本実証では、5GSC の普及啓発活動として以下の活動を実施した。
（1）自治体への 5GSC 取組の説明とインタビュー
地方自治体に対して今年度 5GSC の調査事業の一環として 5GSC の取り組み概要やコンソーシアムで検討されたサービスコンセプト案に対するヒアリング活動への協力をいただ
いた。
総計 25 自治体に、5GSC 調査検討概要、5GSC の構想概要を説明すると共に、5GSC で想定されるサービスなどを説明し、協業/利用ができそうか、できる場合はどのようなもの
か、できない場合は何が課題かなどをヒアリングした。
また、自治体が行っている 5G 利用及び DX 推進・デジタル利活用に係る取組の実情をヒアリングし、意見交換を目的とした自治体へのインタビューを実施した。
5GSC の調査検討の取り組みについて早期より認識・活動に協力をいただく団体の数が増えることで次年度以降、5GSC の調査事業への継続的な協力及び連携可能があると考える。

（2）各団体への 5GSC 事業の普及啓発活動
5GSC 普及の取組として、私鉄 5 社と国土交通省鉄道局専門官を加え、「5G 等を活用した遠隔・リアルタイムでの列車検査システム等の普及展開」に関する協議会を設置した。
今年度、2 回にわたり開催された協議会において、プラットフォーム化によるデータアセ
ット共有や導入コスト低減など事業者間連携への可能性、車両検査ソリューションなどへのニーズが高く事業者からの協力可能性が高いことなどの賛同が得られた。
これにより、次年度も協議会を継続的に立上げて事業者間での営み連携・拡大をすることが各鉄道事業者で合意された。

（3）5GMF を通じた 5GSC 調査事業の取組み状況の掲載
5GSC 調査事業の活動を継続的に実現することを目的に本年度実証取り組み開始時に取り組み開始の告知について、第 5 世代モバイル推進フォーラム（5GMF）を通じた情報発信を行った。

6.5 今後の検討
本年度の調査事業において 5G ソリューションの展開を一元的に担うことができるプラッ192トフォームについては将来的な構築可能性があることが確認できた。
一方、今後、5G ソリューションの普及展開促進を目的とした場合には、まずは根幹となるソリューションの実装可能性を上げていくことがプラットフォームの構築実現よりも直近では優先度の高い検討事項となってくる。
5G ソリューションの普及展開促進のための検討事項としては以下が挙げられる。


コアとなる共用形態の検証を DL 型のみならず SaaS 型でも行い、SaaS 型の提供形
態によるシステム性能比較や利用者における導入容易性に関する比較を行う。



5G ソリューションの横展開に必要となる情報提供・発信の場の在り方の検討を行う。

5G ソリューションの将来展開に向けた検討として、5G 技術発展に伴う更なるソリューション事例の検討や、現状の 5G ソリューションのユースケースの汎用性を高めていき、他業種・他分野への拡大可能性を検討する。

上記の検討事項から「SaaS 型サービス提供」「カタログ共用」「将来展開に向けた検討」
を今後の検討項目とし、それぞれの検討ポイント及び検討内容に関して整理したものを以下に記載する。

（1）SaaS 型サービス提供
SaaS 型提供により利用者の 5G ソリューション導入負担を軽減する効果の検証や 5G ソ
リューションの横展開を可能とする共用形態の検討を行う。
<検討ポイント及び具体的な検討内容＞


横展開可能な共用形態の検討



オンプレミス型、DL 型、SaaS 型のそれぞれの提供方式における NW や AI 処理
性などのシステム性能や利用者のシステム導入容易性の比較のため、今年度 DL 型
で実装し実証を行った鉄道車両監視 AI システムをユースケースとして SaaS 型に実装し、複数事業者における SaaS 型システムの実証を行う。



SaaS 型提供方式におけるアプリケーションの汎用化について鉄道車両監視 AI シ
ステムを基に複数の鉄道事業者とのシステムに対する要求の検討を行う。

AI 部分における学習データの作成や検出精度調整について利用者による登録機能の実装の検討を行う。



最適な構成の検討



END to END でのシステムパフォーマンスを考慮した最適ネットワーク構成、サーバ環境の検討のために、ネットワーク構成(インターネット/閉域利用)、サーバリ
ソースの違いによるレスポンス差異の確認を行うとともに、システム全体として最適な構成の検討を行う。



SaaS 型にてアプリケーション共用を行うための、提供者側・利用者側が構築すべ
き最低限の要件定義の整理及びユースケースに応じたシステム構成の提言を行う。
193

（2）カタログ共用
5GSC プラットフォームの 5G ソリューションのカタログサイトの在り方の検討を行う。
<検討ポイント及び具体的な検討内容＞


カタログサイトの在り方の検討

5G ソリューション提供者／利用者への情報提供・発信の場として効果的な運用を行うことが必要であることから、5G ソリューションのカタログサイトの在り方の検討を行い、令和 3 年度・4 年度の調査事業結果から、カタログサイトの位置付け
や掲載情報などの整理を実施する。

（3）将来展開に向けた検討
将来的に活用が期待できる 5G 技術(5GSA や MEC 技術など)によりソリューションを展開した場合にはさらなる 5G の特性を活用したユースケースの創出が期待できることから、現時点で判明している技術的な論点の洗い出し・検討調査・検討を行うことやアプリケーシ
ョンやシステムを他業種・他分野への横断的なユースケースとして活用することを目指して、現状のユースケースにおけるシステムやアプリケーションの拡大可能性の検討を行う。
<検討ポイント及び具体的な検討内容＞


他業種・他分野への拡大可能性の検討

アプリケーションを SaaS 型で提供する場合の提供方式の検討を行う。具体的には、アプリケーションの共用化のための共通化、非共通化機能の明確化の検討を行う。

5G を使った AI ソリューションを鉄道キズ検知以外の他業種・他分野への拡大可能性の検討を行うために、5G を使った AI ソリューションが求められる業種・分野を令和 3 年度に実施した自治体・企業からのヒアリング結果、及び Beyond
5G 推進コンソーシアムにおける業界ごとの分析結果等も踏まえ、5G を使ったAI ソリューションが求められる他業種・他分野の検討を行う。
5G SA、MEC の活用による更なる低遅延ソリューションの検討

5G の特徴である低遅延性をさらに活用するため、他業種・他分野における 5Gを使った AI ソリューションの導入時に想定される課題の抽出及び 5G SA や
MEC の活用による課題解決の可能性の検討を行う。

194

7. その他事項
7.1 サイバーセキュリティ対策
本実証にて用いるキャリア 5G 設備については特定高度情報通信技術活用システムの開発
供給及び導入の促進に関する法律（令和 2 年法律第 37 号）に基づく開発供給計画認定に係る設備を用いた。
表 7.1-1 認定開発供給計画（全国 5G）
事業者名

認定省庁

開発供給計画認定番号

認定開発供給計画の概
要・備考

総務省
1 日本電気株式会社 経済産業 2020 開 1 総経第 0001 号－1
省

令和 2 年１１月１３日
認定

総務省
経済産業 2020 開 1 総経第 0002 号－1
省

令和 2 年１１月１３日
認定

2 富士通株式会社「IT 調達に係る国の物 品等 又は役務の調達方針及び調達手続に関する申合せ（2018 年
12 月 10 日関係省庁申合せ）等に基づき今回準備した検証環境の対応内容を以下の通り示
す。

No

対象環境

表 7.1-2 サイバーセキュリティ対応表
対応内容

1

IBM Cloud1) 認証制度
ISO270017 取得済み
4.1 2) 監査フレームワーク
SOC2, SOC3 取得済み
下記各基準、ガイドラインへの適合を確認済み
1)政府機関の情報セキュリティ対策のための統一基準
2)府省庁対策基準策定のためのガイドライン

2Enterprise Cloud

1) 認証制度
ISO270017 取得済み
2) 監査フレームワーク
SOC2 取得済み
https://sdpf.ntt.com/security-compliance/certificate/
政府情報システムのためのセキュリティ評価制度（ISMAP）へ登
録済み
https://sdpf.ntt.com/news/2021092101/
その他各種取り組み
https://sdpf.ntt.com/security-compliance/

195

3

AWS Cloud1) 認証制度
ISO270017 取得済み
2) 監査フレームワーク
SOC2, SOC3 取得済み

4

REDHAT Cloud

政府情報システムのためのセキュリティ評価制度（ISMAP）へ登録済み
本実証において、REDHAT Cloud 上で機密情報を含むアプリケーシ
ョン及びデータを取り扱わないため対象外

196