令和４年度
5G ソリューションの横展開に向けた共用形態の有効性に係る調査研究の請負報告書

令和 5 年 3 月 31 日

NTT コミュニケーションズ株式会社

目次

1.

調査事業概要 .............................................................................................. 1
目的 ................................................................................................................. 1
実施概要 .......................................................................................................... 72.

5G ソリューションの情報提供・情報共有に係る検証 ........................................... 10
カタログサイトの要件・設計 .................................................................................13
前提条件 .......................................................................................14
サイト設計 ......................................................................................14
検証内容 .........................................................................................................27（A）5G ソリューション提供者アンケートによる検証 ................................29（B）利用者アンケートおよび（C）利用者アクセス解析による検証 ............32
カタログサイトの有効性検証結果 .........................................................................37(A) 5G ソリューション提供者アンケート検証結果 ..................................37(B) 利用者アンケート検証結果 .........................................................42(C) 利用者アクセス解析検証結果.....................................................57
検証結果のまとめと将来的発展形態の仮説 ..........................................................60(A)5G ソリューション提供者アンケートによる検証結果 ..........................60(B)利用者アンケート、(C)利用者アクセス解析による検証結果 ...............62
将来的に必要となる情報発信等の形態、求められる情報・機能 .............64

3.

5G ソリューションの共用形態に係る検証 .......................................................... 67
検証概要・目的.................................................................................................68
SaaS 型アーキテクチャを用いた構成での実現性や課題の確認 .............69
SaaS 型での共用を行うための要素検討（汎用化検討） .........................70
実運用も含めた負荷軽減効果の確認 ................................................72
将来的な 5G 技術を活用した場合の共用形態における論点 .................73
分野横断的な 5G ソリューションの展開を見据えた共用形態の検証 .......74
5G ソリューションの選定及び検証環境の構築 .......................................................76
5G ソリューションの選定 ...................................................................76
検証する実環境の構築....................................................................76
5G ソリューションに係る検証 ............................................................................. 112
SaaS 型での活用を想定した 5G ソリューションの検証 ......................... 112
5G 特性（遅延性）を考慮した SaaS ソリューションの検証 ..................... 127
SaaS 型での活用を想定した 5G ソリューションの検証まとめ ................. 130
横展開可能な 5G ソリューションの各種検証........................................................ 131iレベル１：ネットワーク/アーキテクチャに係る汎用性評価 .................... 131
レベル２：共通コア機能関連の汎用性評価 ....................................... 138
レベル３：AI コア機能関連の汎用性評価 .......................................... 147
各レベルの取り組みによる負担軽減効果の評価 ............................... 191
横展開可能な 5G ソリューションの各種検証まとめ ............................. 194
将来的な 5G 技術を活用した共用形態の検証 .................................................... 198
評価項目 ..................................................................................... 199
評価方法 ..................................................................................... 203
評価結果 ..................................................................................... 203
分野横断的な 5G ソリューションの横展開に求められる機能の検証 ........................ 213
評価項目 ..................................................................................... 215
評価方法 ..................................................................................... 216
検証結果 ..................................................................................... 220
分野横断的な 5G ソリューションの横展開に求められる機能検証まとめ . 237
5G システム全体としての評価 ........................................................................... 248
ソリューション側のシステム評価 ....................................................... 249
共用形態・接続方式のシステム評価 ................................................ 251
システム全体の分野横断的な横展開に関するシステム評価 ................ 253
サービス提供に必要となる作業範囲における分解点の評価 ................ 256

4.

5G ソリューションの横展開「鉄道業界に向けた取り組み」 ................................. 259
鉄道協議会.................................................................................................... 260
協議会の進め方 ........................................................................... 260
参加者への事前ヒアリングの実施 .................................................... 263
協議会の開催 .............................................................................. 265

1． 第 3 回協議会の議事内容の確認 .................................................................... 284
2． 実証試験結果の報告..................................................................................... 284
3． 共通ソリューション化に係る今後の取組みに関する意見交換 ............................... 284
鉄道協議会のまとめ ...................................................................... 292
次年度以降の取組に関するまとめ・展望 ............................................................ 295

5.

本年度実施総括 ........................................................................................ 297
5G ソリューションの情報提供・情報共有に係る検証 ............................................. 298
5G ソリューションの共用形態に係る検証 ............................................................ 300
5G ソリューションに係る SaaS 型モデル実証実験 ............................... 300
将来的な 5G 技術を活用した共用形態の検証 .................................. 304
ii

分野横断的な 5G ソリューションの横展開に求められる機能の検証 ...... 306
5G ソリューションの横展開「鉄道業界に向けた取り組み」 ...................................... 311
鉄道車両監視 AI システムの共用化実現に向けた具体的方策 ............ 311
鉄道事業者の鉄道 DX に係るニーズの把握、共通ニーズの発掘 ........ 313
鉄道事業者の共通ニーズの解決に資するソリューションシステムのイメージ
具体化 ........................................................................................ 314
鉄道協議会の継続開催について .................................................... 314

iii

1.

調査事業概要目的
5G を活用したソリューションの普及展開を進めるうえで、5G ソリューションの開発が一部の大企業など、先進的な取り組みを進めている団体以外、中堅中小・地方公共団体などにおいては時間とコストを先行投資し開発を実行する余力がない点、また、5G を活用したソリューションの利用事例については具体的な活用方法が利用者から認知されておらず活用検討の段階に入れていな
いことが多い点などが課題として挙げられる。
これらの普及展開課題を解決する方法として、5G を活用したソリューションの利用事例についての具体的な活用方法などを広く利用者に展開するために必要な情報も含めた情報提供・共有の場の在り方や有効性の検討（図 1.1-1 参照）、従来開発された B2B モデルの 5G ソリューションを新たな業種・業務に横断的に活用できるように汎用化を行い、これまで 5G ソリューションの導入に至らなかった利用者への導入のハードルを下げるような共用・提供形態の方法を検討することが重要である。
5G ソリューションの汎用化・共用形態の検討は、利用者だけでなく、ソリューション提供者においてもより幅広く利用者へ展開が可能となることにつながるため市場全体の活性化につながることが期待される。
（図 1.1-2 参照）

図 1.1-1 5G を活用したソリューションに関する情報提供・共有の場の在り方や有効性の検討

1

図 1.1-2

5G ソリューションの汎用化・共用化による展開方策イメージ

5G ソリューション1の汎用化・共用方法に関する検証により多くの利用者へ有益に活用できる横展開の方法を明確化するという今年度事業の目的を設定するに先立ち、過年度の 5G ソリューションの開発や展開に向けた検討経緯について整理を行う。
令和元年 12 月に総務省により「地域ニーズや個別ニーズに応じて様々な主体が利用可能な第５世代移動通信システム」、すなわちローカル 5G の制度整備が行われた。また、「ローカル 5G」等を活用した地域課題解決を実現するための事業として令和 2 年度「地域課題解決型ローカル 5G 等の実現に向けた開発実証」（以下、令和 2 年度 L5G 実証という。）が推進され、5G ならびにローカル
5G の特性を生かしたアプリケーション、ソリューションの開発ならびにユースケースの実装に向けた取り組みが民間事業者を含めて本格的にスタートした。（図 1.1-3 参照）

1

本事業の仕様書上「5G ソリューション」は「DX を支えるローカル 5G を含めた 5G を基盤とした産業用ソリューション」と定義されている。本報告書では、その定義に則しつつ、5G の特性を活かしたソリューションは AI を活用したものが多くを占め、横展開のニーズが高いとの想定の下、共用形態の有効性を検討する対象としての「５G ソリューション」をより具体化し、「5G ネットワークを使い、AI 等を活用したアプリケーションにより諸課題を解決しようとする」
ものとして使用し、アプリケーション面、ネットワーク面を含めたものとしている。

2

図 1.1-3

令和 2 年度「地域課題解決型ローカル 5G 等の実現に向けた開発実証」概要

前述の令和 2 年度 L5G 実証事業に採択された請負者においては、ローカル 5G の特性を最大活用とすることに重きを置いて検討が行われている傾向があり、多くが SI 型2として実証が行われている。SI 型は、5G の特性活用の観点では利点がありつつも、利用するための初期コストや展開時に係る手間が課題となっていた。
令和 3 年度「5G ソリューション提供センター（5GSC）」の構築等に係る調査検討の請負」（以下、「令和 3 年度 5GSC 実証」）において、ソリューション横展開の課題解決の方法として、性能を確保しつつも、効率的に展開可能な方法を模索し、DL 型3を考案、実現性や効果等の確認について行った。これにより、性能を担保しつつもアプリケーションについては展開容易性があることを確認できたが、ネットワークインフラ、サーバインフラ等実行するインフラ基盤環境のインテグ
レーションは引き続き必要であり、コスト面や、事業会社における IT ノウハウ、対応可能な人員等の点が課題として挙げられた。
（図 1.1-4～図 1.1-5）参照）

2
3

性能最大化を目的とし、スクラッチや個別カスタマイズ、オンプレミスでのソリューション提供形態
開発アプリケーションをパッケージング（コンテナ化）し、頒布可能な状態として提供を行う形態

3

図 1.1-4

令和 3 年度 5GSC 実証事業における DL 型の効果振り返り

図 1.1-5

令和 3 年度 5GSC 実証事業で残課題とされた事項
4

そこで、本事業においては、横展開や共用をより容易にするための構成として、SaaS 型を考案する。SaaS 型4として、過去にパッケージング（コンテナアプリケーション化）した 5G ソリュー
ションを SaaS 環境で動作可能とし、その影響や実現性等について確認を行う。以上の取り組みについて、提供形態の観点で下図 1.1-6 に要約する。

図 1.1-6 ソリューション汎用化・共用形態に向けた取組遷移
また、5G ソリューションの SaaS 型による共用化を進めるうえで、併せて検討するべきポイン
トとして、以下 2 点が挙げられる。
（１）利用者環境からクラウド環境への NW 接続形態
（２）ソリューション汎用化・共用化を行ったユースケースの分野横断的な展開方策（１）利用者環境からクラウド環境への NW 接続形態
一般に 5G ソリューションで選択されるソリューションは 5G の特性（大容量、低遅延、多数同時接続）を活用されることを前提に構成されているため、従来よりもデータ通信量が多いことや、
より低遅延でのデータ処理を求められる点、またデータを送信する端末数の多さなどのソリューション特徴をあわせもつ。クラウド環境上でこのような特徴をもつ 5G ソリューションを実行する
場合には NW 接続形態の選択についてもソリューションの性能要求を達成していくために検討が必要である。
従来、一般的によく利用されるクラウド環境の NW 接続形態としてインターネットを介した公衆網経由での接続形態があるが、これらのほかに、今後、本格的な導入が期待される 5GSA や MEC 技術を活用した接続形態についても机上検証を行うことで、5G ソリューションの普及展開を推進す
る上で、これら技術の活用がどのような有用性をもたらすのか確認する。
（２）ソリューション汎用化・共用化を行ったユースケースの分野横断的な展開方策
5G ソリューションの汎用化・共用化の実現前提として、特定分野における課題解決効果が確認

4

アプリケーションだけでなく、実行環境も含めてサービス提供可能とする形態

5

されたユースケースが必要である。これらのユースケースの創出については令和 2 年度からのローカル 5G 実証事業やその他 5G ソリューション開発事業者などにおいて実証実験が行われ、鋭意、各事業分野におけるソリューション事例開発が行われ、社会実装に向けた取り組みが進められている。
一方で、これらのユースケースについては先進的な取り組みである側面が強いことや導入を進めるための初期開発コストの負担が大きいことで、条件が適う事業者のみでの広がりにとどまっており、他方、地域に根差す中小企業や地方自治体等の各産業分野の振興を担うステークホルダー
でのソリューション導入は進んでいないという事業者間での導入に関する課題が生じている。
本実証においては、5G ソリューションの普及展開方策の波及範囲として、これまで 5G ソリュー
ションの利用が、その導入障壁の高さにより敬遠されていた利用者層にも広げていくことで、5Gソリューションの社会普及につながっていくと考える。
そのためには、より広範にソリューション提供を行い、より簡便・安価に利用を広めていくた
め、従来開発を行ったユースケースの部品化、汎用化を行うことにより、汎用的な課題解決を行うコア機能を開発し、分野横断的にコア機能とそれらを効率的に横展開するための共同利用の共通機能を準備し、他分野においても同様の課題を抱える利用者に利用をしてもらう共同利用の形態をとることが、ソリューションの普及展開につながると考えられる。（図 1.1-7）
本実証においては、共用形態に関するソリューション面のほか、共同利用を進めていくために必要となる提供・利用形態、運用面、提供に必要となる技術面での検討を行い、実現性の具体化に向けた確認を行う。

6

図 1.1-7

5G ソリューションの共用形態による分野横断的な展開方策イメージ汎用化された 5G ソリューションを全国の利用者に一元的に提供するためにはプラットフォー
ムを用いた効率的なサービス提供方式への転換なども今後、構想検討が必要になると想定されるが、今年度実証においては、ソリューション共用形態に重点をおき、その課題解決について検討を行い、ソリューションの汎用化、共用方法により多くの利用者へ有益に活用できる横展開の方法を明確化することを目標とした。

実施概要
本事業では、5G ソリューションの普及・展開を目指し、5G ソリューションに係る情報提供・共有の場の構築、現実のユースケース・ソリューションを選定の上で、複数事業者の実環境に展開・導入することで、5G ソリューションの共用形態やその課題等について検証する。
具体的には、5G ソリューションに係る情報提供・共有の場として、カタログサイトの在り方を検討した上で、総務省「課題解決型ローカル 5G 等の実現に向けた開発実証」の実証ユースケースの情報を掲載するカタログサイトを構築し、その有効性を検証する。
また、5G ソリューションの共用形態に関する調査検証として、鉄道分野をユースケースとした7

SaaS 型 5G ソリューション実証システムを構築し、DL 型との比較において SaaS 型の導入効果を検証すると共に、5GSA や MEC 技術の将来活用を見据え、複数のネットワーク接続方式を用いて検討を実施する。
共用形態に係る検証結果を踏まえて、分野横断的な活用を考えた時の 5G システム全体としての評価及び SaaS 型ソリューション提供の最低限のシステム要件定義、ユースケースに応じた利用条
件を取りまとめる。
また、鉄道分野における 5G ソリューション普及の検討のために令和 2 年度 L5G 実証及び令和 3
年度 5GSC 実証において設置した鉄道協議会を、本事業でも引き続き設置し、鉄道分野における
SaaS 型 5G ソリューションの横展開可能性を検討する。（表 1.2-1 参照）

表 1.2-1

本事業における実施内容の概要

それらの成果を踏まえ、地域や中小企業等の各産業分野の振興に資する効果的な 5G ソリュー
ション等の普及展開方策を取りまとめた。（図 1.2-1 参照）

8

図 1.2-1 5G ソリューション展開案と本事業における実施範囲

9

2.

5G ソリューションの情報提供・情報共有に係る検証＜情報提供・共有の場の必要性＞
様々な事業課題を抱えた企業が課題の解決策を検索していく中で、自社の課題解決に繋がるソリューションに出会う。5G はこれらのソリューションを効率的に活用・促進する一つの手段である。
5G を活用したソリューションが普及・展開していくには、これら自社に課題を抱えた企業に向け、効率的なソリューションの活用を促すような情報が企業の手に届く場にあるべきである。ただし、5G ソリューションの導入を検討し始めた段階の事業実施主体においては、5G に関する技術
や AI/IoT などの先進的な ICT 技術に関する知見、DX による業務変革を行うための事業計画の具体化の術を有しておらず、外部の有識者や先駆者の情報・事例をもとに検討を進めていくケースが多い。
（図 2-1）このため、事業実施主体単独で 5G 活用事業モデルの具体化を進めていき、後続の導入プロセスを進めていくことは困難である。
5G ソリューションの普及・展開を進めるうえでは、上記のような初期情報収集の段階にて利用者が専門的な技術・知見を有してないことも考慮し、5G ソリューションの有用性を理解しやすい情報提供・共有の場が求められる。
しかし、5G ソリューションの情報提供・共有の場の整備状況は、5G ソリューションの情報提供・発信が限定的な一部の範囲に限られて行われているのが実態である。
また、現状発信されているユースケースに関しては、各コンソーシアムによる共同開発によりコンソーシアムごとで解決されるべき特定の課題解決内容に限定され、かつ当該コンソーシアム内
での活用を主として想定した 5G ソリューションのみとなっていた。
5G ソリューションの普及を広範に広げていくためには、多くの事業実施主体による活用事例の創出が重要であり、生み出された 5G ソリューションと共通のユースケースの存在する新たな事業分野や業種において、利用価値の転化や新たなる価値の創出が行われることが継続的なユースケース創出や普及のためには必要である。（図 2-2 参照）
そのため、複数の事業者間で広く情報提供・共有が行われる場を創出することが喫緊の課題である。

10図 2-1

5G ソリューションの情報提供の改善イメージ

図 2-2

5G ソリューションの他分野への転化イメージ＜本検証における検証目的＞
前述の通り、本実証では複数の事業者間で広く情報提供・共有が行われる場として、5G ソリュー
ションに関する情報を集約し一元的に閲覧可能なカタログサイトの構築を行った。自社の課題解決に資するソリューションの検索者に専門的な技術・知見がないことを前提とすると、自身の抱11

えている事業課題に対してソリューションに求めるニーズに気づかずに情報収集の段階で導入を頓挫させてしまう可能性がある。そのため、サイト上に掲載されているソリューションが自社の課題に紐づくものかをサイト来訪者が理解しやすく表示・表現し、潜在的なニーズに対しても応える必要がある。さらにサイト内での検索を進めるうえで、自社の抱える課題に即したソリュー
ションにたどり着くためには、業種、技術、用途といった自身と関連する情報と紐づけた検索を進められるような工夫も必要である。
これらの要件をもとに、本実証ではサイト来訪者が自社の抱える事業課題と紐づくソリューションに気付き、自身と関連する情報と紐づけたサイト内検索を進められるといった、得られる情報の探しやすさ（「情報到達性」）を担保するサイトの在り方を把握することを検証目的とした。(図2-3 参照)また、情報提供・情報共有の場が整備されたうえで、次にソリューションの提供者がサイトへの掲載に意欲的であることも、5G ソリューションの継続的な普及には必要である。そのため、ソリューションを保有する提供者がサイトへのプロモーション効果へ一定の期待を持ち、継続的な掲載を行えるような作業負担の少ない情報提供、その際の提供できる情報等についても確認した。

図 2-3

5G ソリューションの情報提供イメージ＜サイト閲覧後の 5G ソリューション導入プロセス構想＞
5G ソリューションに関する情報提供・共有の場であるカタログサイトを経由し、広範囲、かつ一元的に情報を得た利用者に対しては、ソリューションの詳細検討を経て、実証・導入プロセスへの移行が期待される。情報提供・共有の発展形態として、将来的には情報提供以降の段階の提供プロセスをシームレスに提供できるような 5G ソリューション共用プラットフォームとの連携も視野に入れて検討していくことが望ましい。
カタログサイトは単なる情報提供の場としてのみでなく、5G ソリューションの共用の初期段階
で利用者とのオムニチャネル形成にも有用となることが予測される。具体的には、5G ソリューションの導入段階において、利用者環境へのアプリケーション提供を連動して行えるアプリケーショ
ン共用プラットフォーム機能、SaaS 提供アプリケーションの拡充などの機能具備が考えられる。
（図 2-4 参照） そのため、具体的に要望される機能等についても確認した。

12

将来的に
求められるスコープ

実証スコープAtte n tio n( 認知)

I n te r e st
( 興味・ 関⼼)D e sir e( 欲求)Actio n( ⾏動)

5Gソリューションに興味がある⼈がサイトの存在を知る

サイト訪問した⼈がソリューションに興味を持つ

ソリューションに興味を持った⼈が「欲しい」と感じる

ソリューションを欲しいと感じた⼈が商品を購買する

5Gに興味がない⼈の興味を喚起する求められる機能・ソリューション検索機能
・利⽤イメージ掲載( 画像、ユースケース等)
・事例掲載
・問い合わせ機能

図 2-4

求められる機能・問い合わせ、コミュニケーション機
能の強化
・購⼊機能
・ソリューション利⽤可能なアプリ
ケーションプラットフォーム
・Sa a Sアプリケーションの拡充

5G ソリューション導入プロセスでの実証範囲

カタログサイトの要件・設計
カタログサイトの有効性の検証を進めるために検証用「カタログサイト」の設計・構築を行った。
構築するカタログサイトは、コンセプトとする「情報への到達性」を考慮したサイト設計とした。
「情報への到達性」とは、各業種・事業の 5G ソリューション利用予定者が要望する 5G ソリュー
ションに関連する情報への明確な動線を提供することを指す。
構築したカタログサイトに 5G ソリューションの特徴やユースケース等の情報コンテンツを掲載し、サイトに対する効果測定を行った。後述するカタログサイトの有効性検証の評価において、効果測定の結果も踏まえ、サイトに必要となる内容や課題を洗い出し、5G ソリューションの展開に向けたカタログサイトの有効性、将来的に必要となる情報発信等の形態、求められる情報・機能について考察した。
（図 2.1-1 参照）

13

図 2.1-1

カタログサイトコンセプト

前提条件
カタログサイト公開に伴う前提条件として、以下の要件を満たすこととした。
（１）情報掲載対象
令和４年度「課題解決型ローカル 5G 等の実現に向けたローカル 5G の電波伝搬特性やローカ
ル 5G 等の活用に関する技術的検討及び調査検討の請負」（以下「令和 4 年度 L5G 実証」という。
）において実証される 5G ソリューションの特徴やユースケース等の情報を掲載できるように令和 4 年度 L5G 実証コンソーシアムとの連携を行い、掲載可能な内容、タイミングについて協議しながら掲載準備を進める。
（２）公開範囲
インターネットを活用して広範にサイト閲覧可能となるよう構築する。

サイト設計
実証用カタログサイトの設計概要について記載する。
14

＜カタログサイト検証における要件＞■

掲載対象

前述の令和 4 年度 L5G 実証の参画団体を中心にソリューション提供を依頼した。実証段階のソリューションの掲載を行うため、掲載内容については提供可能な情報かつ、ソリューション提供者の掲載意欲を損なわないよう入力の稼働がかかりすぎるものを避けた情報とした。
具体的には、ソリューションの特徴や概要、情報到達性を高めるためのカテゴリ検索を可能とする検索タグの設定、イメージ画像、問合せ窓口など一般公開可能な内容とした。
掲載情報の提供は、情報提供可否と提供方式を令和 4 年度 L5G 実証の請負者及び実証コン
ソーシアムと協議の上で進めることとした。
■ 掲載期間2023 年 1 月 27 日～2023 年 3 月 31 日まで■ 掲載項目
掲載ソリューションの特徴・概要
検索タグの設定
利用シーンやソリューション概要を示すイメージ画像
問い合わせ窓口※問い合わせ窓口については、実証サイトのため実在の問い合わせ先ではなく、フォームに投稿された問い合わせをサイト運営事務局がソリューション提供者へ取り継ぐ運営とした。
■ 公開範囲インターネット上で一般公開することとした。

■ 設計項⽬
以下の各項目に関する設計を行った。
・サイトマップ作成
・画面設計
・コンテンツ設計
・画面デザイン・システム機能＜カタログサイト構築に向けた要件整理＞■

構造、デザイン要件

サイト利用者の行動として、サイトの認知からソリューションの購入に至るまでのフローのイメージを図 2.1.2-1 に示す。本実証ではサイトに来訪した人が探している情報にたどり着けるかという「情報到達性」の高いサイト構成を把握することを目的としているため、サイトの認知を15

促すフェーズおよびソリューションを実際に購入（導入）するかというフェーズについては分析の対象外とする。
よって、本サイトではサイトに来訪した人が直感的に情報を探し始めることができる構造、デザインを意識した作りとした。具体的には、ランディングページでカテゴリごとに検索を開始できるよう業種名、技術名での動線を設ける、余分な情報を極力除いたシンプルなデザインと色合いを設定するといった設計を行なった。

５Ｇソリューションに興味がある⼈がサイトの存在を知る

サイト訪問した⼈がソリューションに興味を持つ

ソリューションに興味を持った⼈が「欲しい」と感じる

ソリューションを欲しいと感じた⼈が商品を購買する

主たる
分析対象

主たる
分析対象

事例システムのみ分析

分析
対象外
５Ｇに興味がない⼈の興味を喚起する

図 2.1.2-1

本事業におけるカタログサイト構成イメージ■ サーバ要件
カタログサイトのコンテンツサイズや HTTPS による暗号化により変動はあるが 400PV/分程度のアクセス数を上限としたサーバを手配することとした。（表 2.1.2-1 参照）
表 2.1.2-1 サーバスペック要件■ セキュリティ要件
カタログサイトのセキュリティ対策として、以下を実施することとした。
16

・サイトのインターネット公開時の境界防御対策として、FW などの機能を利用したアクセス制
御を実施し、特定コンテンツへのアクセス制限を行う。
・サイトへの不正アクセス時の改ざん検知、及び監査ログの取得・管理を行う。
・実証期間中、サイトへの不正アクセスが認められた場合には、FW などの機能を利用したサイト閉塞対応を実施し、2 次被害の拡大を抑える。
■ 実装環境カタログサイトは、サーバ運用が軽微である点、外部公開時のセキュリティ対策機能が充足されている点から実証期間中に効率的にサイト運用が可能である、NTT コミュニケーションズのマ
ネージド仮想専用サーバ(VPS)サービスである「Biz メール＆ウェブ プレミアム」を利用することとした。
（図 2.1.2-2 参照）
上述のセキュリティ要件を満たす機能として利用した「アクセス制御機能」のイメージを図2.1.2-3、改ざん検知、ログ取得・管理機能として利用した「Web 改ざん検知機能」のイメージを
図 2.1.2-3 に示す。

図 2.1.2-2

本事業におけるカタログサイト構成イメージ

17

図 2.1.2-3

アクセス制御機能

図 2.1.2-4

Web 改ざん検知機能＜カタログサイトのコンテンツ設計＞■

カタログサイトの画面遷移図、画面デザイン、機能

前述の実証用カタログサイトの要件を踏まえ、カタログサイトの情報設計として、サイトマッ
18プ作成、画面設計、コンテンツリスト、画面デザイン、システム機能設計を行った。
（図 2.2-1～
図 2.2-2 参照 ）本実証カタログサイトのコンセプトである「情報への到達性」を考慮したサイト設計となるよう、サイトの視認性に関してのデザインや機能設計を行った。（図 2.1.2-5 参照）
情報への到達性を高める工夫として、本サイトでは「業種」「技術」「詳細検索」の 3 つの検索機能を具備した。
通常ソリューションの検索を始める際には、自社と共通の業種や関連した業種を優先的に閲覧すると考えられる。また、5G を活用したソリューションの場合、最新技術として AI や IoT、ドローンといったワードから検索を進めるケースも多くなると想定した。
サイト来訪者がランディングページから即座に検索を開始できるよう、ホーム画面に「業種で探す」、「技術で探す」、「詳細検索」を表示する構成とした。
（図 2.1.2-6：ランディングページ）。
多くのサイト来訪者が上記のようなカテゴリ別に検索、閲覧を進めることを想定しているため、業種、技術以外にもいくつか検索タグを設け、各ソリューションのサムネイルにはタイトル
やイメージ画像をはじめとし、検索タグを表示することで、サイト利用者が自社に関連のある項目をより簡易に判断できるよう配慮した。

図 2.1.2-5 画面遷移図19

図 2.1.2-6 ランディングページ
表 2.1.2-1 機能一覧20

図 2.1.2-7 ランディングページにおける新着ソリューション欄

図 2.1.2-8 ソリューション一覧ページ■

業種、技術区分の設定

ホーム画面の「業種で探す」、「技術で探す」ボタンをクリックすると、同ページの 6 区分の業種、技術名ボタンが並ぶ位置まで移動する仕様とし、来訪者がページ遷移をせずに自社に関係のある業種、技術を選択できる形とした。
（図 2.1.2-9,2.1.2-10 参照）
21図 2.1.2-9 業種での検索ページ

図 2.1.2-10 技術での検索ページ■「詳細検索」における検索タグの設定

ホーム画面の「詳細検索」ボタンをクリックすると、事前に各ソリューションに設定された検索タグ（図 2.1.2-11 参照、各タグについては後述）が表示された詳細検索ページへ遷移し、利用者が各タグをチェックボックスで選択すると該当のソリューションが検索結果として表示される形とした（図 2.1.2-12：「業種：建設業・オフィス」、「技術：AI」での検索結果画面参照）。同ペー
ジではフリーワードでの検索も可能となっており、利用シーンやサイト利用者がピンポイントで求めるワードでソリューションを検索できるよう配慮した。

22

図 2.1.2-11 詳細検索ページ

図 2.1.2-12：「業種：建設業・オフィス」、「技術：AI」での検索結果画面
23

■

各ソリューションの詳細ページにおける掲載項目

ソリューションのサムネイルをクリックすると、各ソリューションの詳細ページに遷移する（図2.1.2-13 参照）。ソリューションの「概要」、「詳細」は利用シーンや課題解決方法を明示しつつも、
画面スクロールが多くなり利用者が閲覧を止めてしまわない文量、表示を意識した構成とした。
④以降の項目はサイト利用者の情報への到達性を高める工夫として、自社に関連する項目を一目で判断できる、かつ詳細検索画面での検索ができる【検索タグ】として設定・掲載した。
①タイトル
ソリューションの利用シーンが伝わるタイトルを 30 字以内で記載する形とした。
②概要
サイトの利用者が閲覧し、自社に関係があると感じてもらうための説明文として、以下の内容を含めて、150 字以内で記載する形とした。
・ターゲットとしている業界・業種・解決できる課題
・利用されている技術（手段）③詳細
掲載企業がなぜこのソリューションを提供しているのか、ソリューションの強みや新規性などを伝え、閲覧したサイト利用者が興味を持ち、最終的には問い合わせに至ってもらうための説明文。以下の内容を含めて、300 字以内で記載する形とした。
【必須項目】
・課題とその解決方法
・導入効果・機能・既存のソリューションとの違い、強み【任意項目】
・導入事例【検索タグ】④業種（6 区分）
掲載ソリューションの業種区分を「観光・商業」、「建設業・オフィス」、「交通・モビリティ」、「農林水産・酪農/畜産」、「防災・セキュリティ、」「医療・介護」より単一で設定する形とした。
業種として設定した 6 区分は、令和 3 年度「課題解決型ローカル 5G 等の実現に向けた開発実証」
実証事業成果概要を参考に設定した。
⑤技術（6 区分）
掲載ソリューションに用いられている技術を「AI」、「IoT」、「ロボット」、「自動運転」、「ドローン」、「建設機械」より複数設定可能な形とした。技術として設定した 6 区分は、幅広い領域の事
24

例を創出している「課題解決型ローカル 5G 等の実現に向けた開発実証」ならびにその他 5G 実証の事例5を分類分けすることで設定した。
⑥掲載区分（2 区分）
今回のカタログサイトでは、ローカル 5G 実証参加団体にソリューション掲載にご協力いただいたため、掲載ソリューションの実装状況として、「実装済のソリューション」、「ローカル 5G 実証での実証段階」のいずれかを設定する形とした。
⑦無線種別（3 区分）
掲載ソリューションを提供するうえで利用されている無線種別について。
「5G」、「LTE」、「Wi-Fi」
より複数設定可能な形とした。
⑧提供会社
ソリューションの提供元を掲載した。サイト利用者によっては提供会社名がソリューション閲
覧の一要因となることも考えられる。
⑨掲載日
今回の掲載期間は実証期間中の短期ではあるものの、掲載日を表示し新規ソリューションについてはホーム画面の「新着ソリューション」欄に表示される形とした。
⑩関連 URL
ソリューション提供者の掲載意欲を高め、サイト利用者がより深く検索を進める目的で、掲載
ソリューションに関する専用ページ、プレスリリース、その他メディアでの発信等の URL を掲載した。
⑪その他
その他、ソリューション提供者からの補足情報等がある場合の掲載欄を設けた。
⑫問い合わせボタン
各ソリューションへの問い合わせボタン（後述）5

総務省 GO!5G | 第 5 世代移動体通信システムの普及と利活用(2018 年)

25図 2.1.2-13 ソリューションの詳細ページ■問い合わせフォーム
問い合わせフォームは 2 つの動線から表示可能とした。（図 2.1.2-14 参照）
1 つがメニューバーに表示された「問い合わせ」ボタン、もう 1 つが前述した各ソリューション
詳細ページの下部に表示された「問い合わせ」ボタンである。
どちらもサイト運営事務局宛に問い合わせ内容を送信する形式であり、各ソリューションへの問い合わせがあった際には、サイト運営者からソリューション提供者への問い合わせの引き継ぎを行う運営体制とした。
問い合わせフォームでは、サイト利用者に係る検証を行う目的で、サイト訪問の目的と自社の課題に対する取り組み状況をカテゴリ選択していただく形とした。それぞれ以下で補足する。
①訪問目的選択
基本的に本カタログサイトの利用者は自社に DX 課題を感じている企業を想定しているため、その仮説を検証する目的で問い合わせ時に選択する形とした。
26

・自社導入のため
・顧客提案のため②カテゴリ選択次節 2.2 で後述するサイト利用者へのアンケート調査において、利用者が自社で抱える課題に対する取り組み状況を把握する目的で、利用者が問い合わせ時に以下を選択する形とした。検証
内容については、次節で詳述する。
・決済のための見積もりが欲しい
・比較検討のための詳細な検討材料が欲しい
・自社(または顧客)の課題解決につながるか否か確認したい
・他社がどのような取り組みを行なっているか把握したい

図 2.1.2-14 問い合わせフォーム

検証内容
本実証では、当サイトが将来的に実運用された場合を見据え、5G ソリューション提供者がソリューション掲載に意欲的であり、掲載にかかる負担が許容できるものかというソリューション
提供者側の観点と、サイトへ来訪した方が求めている情報は何か、探している情報にたどり着け
るかというサイト利用者側の観点での検証を行った。
サイト利用者側の検証については、アンケートでの定性的な分析に加え、補填的に Web アクセ
27

ス解析ツールを用いた定量的な分析も実施した。それぞれの実施フローについては、図 2.2-1 に示す。
（A）5G ソリューション情報提供ベンダーへの掲載意欲及び掲載負担に関するアンケート（以下、5G ソリューション提供者アンケート）（B）カタログサイト利用者へのアンケート（以下、利用者アンケート）（C）カタログサイト利用者のアクセス解析（以下、利用者アクセス解析）（A）5G ソリューション提供者アンケートでは、掲載情報を提供いただいたベンダーが掲載したい情報を掲載できたか、掲載にかかる負担は許容できるものだったか、掲載負担に対するサイトのプロモーション効果への期待度は見合うものだったか、今後の掲載に向けた意向等をアンケー
ト調査により把握した。以下、2.2.1 で詳述する。
（B）利用者アンケートでは、カタログサイトに来訪した方が求める情報は何か、その情報にたどり着けたか、どの情報を見て自社に関連があると判断し各ソリューションを閲覧したか、今後も当サイトを活用した情報収集を行いたいか等をアンケート調査により把握した。
（C）利用者アクセス解析では、Google Analytics4(以下 GA4 と略す)を用いて、ページ遷移を追うことで閲覧したページや、サイト上で表示している業種/技術といった探し方をどれだけの利用者が活用したかといった分析を行った。以下、2.2.2 で詳述する。

28

図 2.2-1

カタログサイトの有効性検証実施フロー（A）5G ソリューション提供者アンケートによる検証（1） 情報掲載企業の選定
1）情報掲載企業の選定方法
最新の 5G ソリューションを掲載するカタログサイトとすべく、令和 4 年度 L5G 実証の参画団体
を中心とした事業者より、ソリューションの情報を収集した。
同実証の代表機関向けに Web 会議にて本実証のコンセプトのご説明、ソリューション提供の協
力依頼を実施した。各団体より提供情報の入力フォームへソリューション情報の記入依頼を行い、ソリューション情報の掲載はカタログサイト実証運営事務局側で対応する運営方法をとった。各団体から入力フォームのご記入後、サイトのプロモーション効果への期待度合いや、入力にかかった負担等についてアンケートを実施した。アンケートの内容については、2.2.1（3）にて詳述す29

る。
2）掲載企業提供されたソリューションは令和 4 年度 L5G 実証で構築したソリューションに閉じず、過年度で構築されたソリューションや実装が済んでいるソリューションについても掲載を行った。（表2.2.1-1 参照）

表 2.2.1-1 掲載企業とソリューション
提供会社
シャープ株式会社

ソリューション名
最適経路によるロボットトラクターの遠隔制御システ
ム

東日本電信電話株式会社

収穫適期判定、遠隔指導、自動収穫及び遠隔ショッピ
ングシステムNTTデータ経営研究所

ゆず生産スマート化システム

西日本電信電話株式会社

AI画像解析や見回りロボットによる高品質和牛の肥育効率化

株式会社ZTV

ブリ養殖における自動給餌システム

株式会社秋田ケーブルテレビ

洋上風力発電ブレード点検効率化ソリューション

富士通株式会社

設備点検作業の自動化・省人化

富士通株式会社

高精度映像測位ソリューション

株式会社ハートネットワーク

工場向けAIによる精製物の自動粒度判定システム

九州電力株式会社

火力発電所のスマート保安の実現

東日本電信電話株式会社

空港制限区域内ターミナル連絡バスの複数台遠隔型自動運転

西日本電信電話株式会社

港湾向けトレーラー待機場の混雑状況等可視化ソ
リューション

株式会社地域ワイヤレスジャパン

ゴルフ場におけるコース運営の効率化及び新たなゴル
フ体験の実現株式会社地域ワイヤレスジャパン

河川監視システム

株式会社地域ワイヤレスジャパン

IP映像配信によるテレビ受信障害の応急復旧システム

KDDIエンジニアリング株式会社

屋内スポーツにおける魅力的な映像コンテンツを提供するソリューション

シャープ株式会社

ドローンを用いたインフラ点検および災害現場検証ソリューション

株式会社NTTデータ関西

高精細4K映像リアルタイム伝送による防災業務ソリューション

東日本電信電話株式会社

遠隔高度医療支援サービス
30

東日本電信電話株式会社

次世代薬剤トレーサビリティ ソリューション

トランスコスモス株式会社

病院特化型映像共有ソリューション

NTTコミュニケーションズ株式会

救急搬送中患者の遠隔データ連携システム（仮称）社
株式会社アルム

救急病院間における遠隔画像伝送ソリューション

国際航業株式会社・日本電気株式

災害時のリアルタイム状況把握と迅速な応急復旧ソ会社・西尾レントオール株式会

リューション

社・電気興業株式会社
首都高速道路株式会社

電波環境の維持管理効率化ソリューション

住友商事株式会社

工場向けキズ検知ソリューション

住友商事株式会社

鉄道車両ドア閉扉判断の高度化ソリューション

住友商事株式会社

車両前方カメラによる鉄道沿線の異常検知ソリューション

アイテック阪急阪神株式会社

AI搭載・ネットワーク対応型車内防犯カメラ

ＦＣＮＴ株式会社

高画質映像ストリーミング対応小型カメラ端末

シャープ株式会社

ローカル5G対応防水・防塵・小型USBドングル端末（2） 情報提供のご依頼とアンケートの実施期間2022 年 12 月 21 日～2023 年 1 月 6 日（3） 検証内容
1）検証項目①5G ソリューション提供者はカタログサイトへのコンテンツ投稿に意欲的であるか、②カタロ
グサイトへのコンテンツ投稿の稼働負担が大きく、5G ソリューション提供者の継続的な情報アッ
プデートの意欲を損なうことがないか、という 2 つの観点から検証を行った。前述の通り、情報入力後にアンケートを実施することで将来当サイトが実運用される際に、ソリューションを提供するだけのポテンシャルを感じていただけるか、入力稼働など運用上の課題がないかといった観点でサイトの有効性を確認した。（表 2.2.1-2 参照）

表 2.2.1-2 5G ソリューション提供者向け検証項目312）アンケートにおける質問項目
各検証項目を満たす設問表として以下のアンケートを実施した。
Q2 ではソリューション提供者が、サイトへの来訪を想定している方の業種を把握する目的で設定した。Q3〜5、8、9 では将来的な実運用を見越し、当サイトへのプロモーション期待度合い、掲
載情報の提供にかかる作業量を鑑みたうえでソリューション提供者が掲載を続けるかを把握する目的で設定した。Q6、7 では今回設定した掲載情報の入力フォームの内容に関して、ソリューション提供者が掲載したい情報を充足していたかを把握する目的で設定した。足りない項目があればソリューション提供者の掲載意欲に資する可能性がある要素のため、今後の検討に加える必要があると言える。Q10、11 ではソリューション提供者目線で今後のサイトに実装することで便利にな
る機能、また掲載ソリューションが購入可能なサイトとなった場合の決済に関しての設問を設けた。（表 2.2.1-3 参照）

表 2.2.1-3 ソリューション提供者向けアンケートにおける質問内容（B）利用者アンケートおよび（C）利用者アクセス解析による検証（1） サイト公開の告知
1）サイト公開の告知先
32

カタログサイトへの情報提供を行った令和 4 年度 L5G 実証の参画団体に、公開したカタログサイトの利用および利用者アンケートへの回答依頼を行った。併せて、実証関連団体以外の一般のサイト来訪者を誘致するためにメールマガジンでサイト公開の告知、利用者アンケートへの回答依頼を行った。
2）サイト公開の告知方法
令和 4 年度 L5G 実証参加団体については、掲載ソリューションの掲載状況確認依頼と併せて、各代表機関へサイトの利用依頼と利用者アンケートの回答依頼を行った。
また、短期間で一般のサイト来訪者を誘致する手段として、幅広い属性の閲覧者（特に、ビジネスユーザ）から認知を得るために、BtoB のメールマガジンを利用した。
メールマガジンのサービスとしては、NTT コミュニケーションズのサービスとして運用している ICTBusiness Online、OPEN HUB という 2 つの媒体を用いた。双方ともに全国のビジネスパーソンの約 40 万
人がメールマガジンに登録している。特に ICT Business Online は中小企業に勤めるビジネスパーソン
を、OPEN HUB は大企業に勤務するビジネスパーソンを、それぞれターゲットとしており、ターゲットの分散を図るよう工夫した。また、メールマガジンは文面を自由に設計できるため、文面から利用者アン
ケートフォームへの動線を短縮する（閲覧～回答への歩留まりを高くする）ことができた。
表 2.2.2-1 利用したメールマガジンとその会員の属性
媒体名

会員数※

会員属性

ICT Business Online

約 40 万人主に中小企業に勤めるビジネスパーソン

OPEN HUB

約 40 万人

主に大企業に勤めるビジネスパーソン※メルマガ購読会員数（2） サイト公開の告知期間および分析対象期間
令和 4 年度 L5G 実証参加団体には 2023 年 1 月 27 日にサイト公開の告知および利用者アンケートへの回答依頼を行った。メールマガジンに関しては、配信枠の取得ができた以下の日程で配信を行った。
・ICT Business Online
2023 年 2 月 10 日（金）・OPEN HUB
2023 年 2 月 13 日（月）アンケートおよびアクセス解析の分析対象期間は、令和 4 年度 L5G 実証参加団体にサイト公開の告知を行った 2023 年 1 月 27 日から、2023 年 2 月 24 日までの約 1 か月間とした。

（3） 検証内容
1）検証項目33

①カタログサイト利用者の来訪目的は何か②来訪目的毎にカタログサイト利用者が求める情報は何か③カタログサイト利用者が閲覧するコンテンツは何か④コンテンツを閲覧した結果、カタログサイト利用者の 5G ソリューション利用意向は高まったかという 4 つの観点から検証を行った。（表 2.2.2-2 参照）
前述の通り、サイト公開後に令和 4 年度 L5G 実証参加団体については、掲載ソリューションの掲載状
況確認依頼と併せて、各代表機関へサイトの利用依頼と利用者アンケートを実施し、一般利用者へはメールマガジンの配信によりサイト公開の告知とアンケート回答を促した。
表 2.2.2-2 サイト利用者検証項目

2）（B）利用者アンケートにおける質問項目
各検証項目を満たす設問表として以下のアンケートを実施した（表 2.2.2-3 参照）。
Q1〜4 ではメールマガジンの配信によりサイトにアクセスし、アンケートに回答する層の属性を把握する目的で設定した。自社の抱える課題に対する対応状況により、サイトに求める情報が異なると仮説立てたため、Q5〜7 ではサイトにアクセスする方の来訪目的と抱える課題、その課題に対する対応状況を確認した。Q8、9、11、13、14 といった設問で、求める情報が何か、その情報にたどり着けたか、閲覧後さらに深く求める情報は何かを確認した。Q10、12 では情報到達性を高める目的で設定した業種や技術、検索タグでの検索が適しているかを確認するため、情報にたどり着きやすいか、どんな情報を見て各ソリューションのページをクリックしたかという設問を設けた。Q15 では閲覧を進めた結果、ソリューションの導入意向が高まるのかを確認した。Q16〜18 では 5G ソリューションの検索を行う媒体として、当サイトを活用してもらえるのか・有効なのかを確認するために、今後の検索に利用したい媒体とその理由といった設問を設けた。

34

表 2.2.2-3 サイト利用者アンケートにおける設問

3）（C）利用者アクセス解析における分析内容
利用者アンケートによる定性的な分析を補填する目的で、サイトへのアクセス解析を行った。アクセス解析では取得できる情報が限られているものの、アンケートに回答していないサイト来訪者の回遊を把握するため分析手法として適用した。そのため、アンケートだけではサイト利用者の特性が把握しきれない検証項目に関して、アクセス解析を用いた分析を行った。
アクセス解析ツールは GA4 を活用し、サイト利用者のページ遷移データをもとに回遊行動を取得することとした。具体的には、「レポート」や「探索」といったサイト利用者の行動が自動でグラフ化される機能を主に活用し、一部特定のページへの遷移をカウントする「カスタムイベント」機能を活用した。
表 2.2.2-4 に GA4 により分析した項目を示す。
各検証項目に対して、GA4 で計測可能な項目について以下で詳述する。
検証項目における「カタログサイト利用者の求める情報」を把握する目的でアクセス数の多い技術名を計測した。
検証項目における「カタログサイト利用者の抱える課題に則した情報であれば閲覧されるか」を把握する目的で、各ソリューションの詳細ページの閲覧率、ソリューション一覧ページからの離脱率が極端に高くないかを計測した。離脱率に関しては、ソリューション一覧ページでソリューションのタイトル
やサムネイル、検索タグとして設定した情報を見て、サイト利用者が自社に関連するソリューションだと判断し、ソリューション詳細ページへ遷移すれば、利用者の抱える課題に則した情報により閲覧されたと言える。一方で自社の課題に即した情報でないと判断されれば、ソリューション一覧ページからの離脱率が高くなると考えられる。
検証項目における「カタログサイト利用者は必要な情報にたどりつくことができたか」を確認する目的で、ソリューション詳細ページに表示された関連 URL のクリック数と、ソリューション詳細ページの滞在時間を計測した。利用者の求めるソリューションが見つかり、より詳細な情報を得るために関連 URLのリンクをクリックしたとみなす。また、滞在時間が一定以上あれば、ソリューションの閲覧を進めて35

おり、一定自社に関連する情報にたどりつけたとみなす。
検証項目における「どのようなカテゴリ区分であるとカタログサイト利用者が必要な情報にたどりつきやすいか」を把握する目的で、業種、技術、詳細検索それぞれの利用比率と、業種、技術、詳細検索
後のソリューション詳細ページの閲覧数を計測した。それぞれの利用比率については、業種、技術から探す場合の動線がサイト内に複数あるため、GA4 でカウントが可能な 1 つの動線のみを計測した。ランディングページの「業種から探す」カテゴリで、業種名をクリックし、選択した業種のソリューション
一覧ページに遷移した数を計測した。計測した動線に至る画面イメージを図 2.2.2-1 に示す。
表 2.2.2-4 サイト利用者アクセス解析における計測項目

図 2.2.2-1 ランディングページで「業種から探す」をクリックした直後の画面
36

カタログサイトの有効性検証結果
2022 年 12 月 21 日〜2023 年 1 月 6 日で回答いただいた(A) 提供者アンケートおよび、2023 年 1 月 27
日〜2023 年 2 月 24 日の期間を対象として分析を行った(B) 利用者アンケート、(C) 利用者アクセス解析の分析結果を示す。

(A) 5G ソリューション提供者アンケート検証結果
Q1. 今回カタログサイトに掲載した情報は、どのような業種の方に閲覧して欲しいですか (n=26)
掲載企業がどのような業種の方に閲覧してほしいのかを確認することを目的とした質問である。
結果として、選択肢として設定した 6 業種を回答した企業は約 75%であり、約 25%の回答者からは設定した業種とは異なる業種の回答が得られた。このことから、当初想定したよりも幅広い業種の方に閲覧して欲しいという企業が一定存在したことが分かる。よって、業種区分については再検討が必要と考えられる。その他の業種として回答されたものとして、製造業や情報通信等の業種は多く、これらの業種
は 5G ソリューションの選択軸としても一般的であると考えられるため、追加検討が必要と思われる。

Q1.今回カタログサイトに掲載した情報は、どのような業種の方に閲覧して欲しいですか(n=26)

19%

27%

15%

4%
8%
12%

15%

農林水産・酪農/畜産

交通・モビリティ

医療・介護

建設業・オフィス

防災・セキュリティ

観光・商業

その他

図 2.3.1-1 提供者アンケート「ソリューションのターゲット業種」
Q2. 当カタログサイトのコンセプトをお聞きして、サイトに多くの利用者が来訪し、貴社のプロモーションに繋がることをどの程度期待していますか (n=26)
サイトに対するプロモーションの期待度合いを確認することを目的とした質問である。結果として、やや期待している以上が 95%以上であり、サイト掲載によるプロモーション効果への一定の期待がされていることが確認できた。プロモーションとして、他業種のソリューション等と並べられることにより、
自社ソリューションが幅広い層に認知されることを期待していると考えられる。
37

図 2.3.1-2 提供者アンケート「当サイトに対する期待」
Q2-A-1. 今回の入力作業とプロモーション効果の期待度合いを鑑みて、今後も当サイトへの情報掲載をしたいと思いますか (n=25)
Q2 の質問で「非常に期待している」「やや期待している」と回答した方を対象に、今後の情報掲載の意向を確認し、掲載の障壁となる要素を確認した。
結果として、92%が今後も掲載を行いたいと回答し、概ね掲載継続の意向を維持できたと言える。一方
今後の掲載は見送りたいと回答した企業が 2 件存在した。
Q2-A-1.今回の入力作業とプロモーション効果の期待度合いを鑑みて、今後も当サイトへの情報掲載をしたいと思いま
すか (n=25)
8%

92%

1.今後も掲載したい

2.今後の掲載は見送りたい

図 2.3.1-3 提供者アンケート「継続的な情報掲載の意向」
Q2-A-2 掲載を見送りたいと判断した理由を教えてください(n=2)
Q2-A-1 の質問に「今後の掲載は見送りたい」と回答した方を対象に、その理由を確認した。
38

結果として、「実装まで足の長い事業であること」「状況を見ながら判断したい」という回答があり、実際にプロモーションとして効果を発揮する実装時まで効果が確認しづらいことや、試験的なサイトであり効果が予測できないことが掲載継続の意向を抱かない原因であると考えられる。カタログサイトの実運用時には、実装間近なものや既に販売されているソリューションの掲載が主となるため、実運用上では大きな課題はないと考えられる。
Q3. 今回の入力フォームの項目では、掲載したい情報をすべて掲載することができましたか (n=26)
ソリューションを提供・プロモーションする立場として、掲載したい情報を掲載しているのかを確認することを目的とした質問である。
結果として、73.1%が掲載したい情報を掲載できたと回答しており、概ねサイト上に掲載すべき情報を入力フォームに設定することができたと考えられる。ソリューション提供者が不足していると感じた情報については次の設問で整理する。

Q3.今回の入力フォームの項目では、掲載したい情報をすべて掲載することができましたか (N=26)

27%

73%

1.掲載したい情報を掲載できた

2.掲載したい情報を掲載できなかった

図 2.3.1-4 提供者アンケート「掲載情報量の確認」
Q3-A-1. 今回の入力フォームの項目に加えて、掲載したかった情報を教えてください (n=7)
Q3 で「掲載したい情報を掲載できなかった」と回答した企業に、不足している情報を確認することを目的とした質問である。
結果として、「動画や画像の掲載」「業種区分の不足」「特徴等の訴求」等があった。動画やより多くの画像はソリューションの説明や訴求において重要であり、カタログサイトの実運用時には対応が必要である。
業種区分の不足に関しては、
本実証では L5G 実証団体を中心にソリューションの掲載を依頼しており、ソリューション数が制限されることから掲載されない業種がないように調整を行っていた。そのため、実運用時に想定される区分よりも制限された業種区分しか存在しなかったことが、業種区分が不足して39

いると判断された原因であると考えられる。カタログサイトの実装時には、Q1 で整理した製造業等の一般的な業種区分を追加することで解決されると考えられる。
特徴等の訴求に関しては、文字数の関係上大規模な訴求を行える項目を設定していなかったことが原因と考えられる。ソリューション提供者側の入力にかかる負担度合いとサイト利用者にとって適切な文
量のバランスを考慮したうえで、文量の調整を行う必要がある。
Q4. 掲載情報の入力にかかった作業について、最も当てはまるものを以下よりお選びください (n=26)
入力作業の負担について確認することを目的とした質問である。 結果として、92.3%が「現在の入力の作業時間であれば負担には感じない」との回答であり、掲載企業の負担は少なかったと考えられる。
提供者アンケートでは Q3-A-1 で「実際の利用イメージや動画」等の情報をより多く掲載したいとの回答があった。一方、利用者アンケートでは「サービス例」「効果的な費用削減策」等の情報が求められていた。双方ともに、より多くの情報を掲載/閲覧する要望がある事と、情報量を削減したい/して欲
しいとの要望が無い事から、現状よりは情報量を増やす方向性で検討を進める必要性がある。ただし、Q3 の通り提供者が掲載に協力できる範囲での負担となるよう、最適な情報量を考慮することが求められる。

Q4.掲載情報の入力にかかった作業について、最も当てはまるものを
以下よりお選びください (n=26)

1

0%

24

20%

40%

1

60%

80%

100%

より充実した内容を掲載するために、
現在より入力の作業時間が増えても構わない

現在の入力の作業時間であれば負担には感じない
現在の入力量では作業時間がかかりすぎる

図 2.3.1-5 提供者アンケート「情報掲載の負担確認」
Q5. 掲載文と画像について、既存のプロモーションコンテンツを利用して入力できましたか(n=26)
今回設定した入力項目が、どこまで掲載企業の既存のプロモーションコンテンツと親和性があるかを確認し、実運用の際にも負担なく入力できるのか確認する目的で設定した質問である。
結果として、多くの企業が「既存のプロモーションコンテンツをやや修正する必要があった」と回答した。今回設定した文字数制限に完全にマッチする形で既存のプロモーションコンテンツを作成していた企業は少ないと考えられるため、想定していた回答結果であった。
40

実態として、Q4 でほとんどの企業が入力を負担には感じないと回答しているため、許容可能な範囲での修正であったと考えられる。一から作成が必要な項目があったと回答した企業も Q4 で入力を負担ではないと回答しており、許容可能な修正作業であった。
Q5.掲載文と画像について、既存のプロモーションコンテンツを利用して入力できましたか (n=26)

8%
31%

61%

1.既存のプロモーションコンテンツから内容を抜粋することで簡単に入力できた
2.既存のプロモーションコンテンツをやや修正する必要があった
3.一から作成が必要な項目があり、入力に時間がかかった

図 2.3.1-6 提供者アンケート「情報掲載方法の確認」
Q6. 将来当サイトにどのような機能が実装されるとより便利だと思いますか (n=14)
掲載企業側が求める機能を確認することを目的とした質問である。多様な回答をいただいており、
・「より強力な検索機能」
・「比較機能」
・「簡単見積もり機能」
・「問い合わせ等コミュニケーション機能」
・「リンク一覧」等が主であった。
より強力な検索機能は、より多くのソリューションを掲載することになるカタログサイト実装時には必要となると考える。掲載企業側が想定した用途に関連し、かつ閲覧者の目に留まる検索機能が重要となる。
比較機能は、複数の同じ目的のソリューションが掲載される際に利用者側の利便性が向上すると考えられる。一方で、どの項目を比較するのかを検討し、公平な判断を行えるようにする必要性があり、実装には十分な検討が必要である。
見積もり機能については、どこまでの役割をカタログサイトに持たせるかの検討が必要である。環境により工数が大きく変化することの多い 5G ソリューションを一律で見積もることは難しく、多くの情報を登録してもらう必要があるため、機能を具備する場合にはソリューション提供者の入力可能な項目の確認が必要となる。
問い合わせ等のコミュニケーション機能に関しては、問い合わせフォーム自体は存在するため、より高度な問い合わせ関連機能を求められている。例示されていたものでは、問い合わせが来た際に通知が来るような設計等が挙げられていた。他に検討できることとしては、チャットボット等を用いた誘導等
41

が考えられる。リンク一覧については、実装における課題は少ないが、何に関するリンクを一覧化すべきか検討する必要性がある。
Q7. 貴社のソリューションを当サイト上で購入できるようになった際の決済について、以下のどちらが望ましいと感じますか (n=26)
決済機能に関する利用意向を確認することを目的とした質問である。
結果として、申し込み機能の方が好ましく、サイト上での決済機能は求められていないことが明らかになった。周辺環境により総工費が変化する関係上一律の金額を設定することが難しくオンライン決済に向いていないことや、決済フローが既に社内で決まっており、サイト独自の決済機能を活用するにはかえって手間がかかってしまう企業が多い可能性があることなどが原因であると考えられる。

Q7.貴社のソリューションを当サイト上で購入できるようになった際の決済について、以下のどちらが望ましいと感じますか (n=26)
30

25

20

10
1
0
1.当サイト上で購入の申込と決済ができる

2.当サイト上で購入の申込ができる

図 2.3.1-7 提供者アンケート「決済機能の提供範囲確認」(B) 利用者アンケート検証結果
Q1. 回答者様の企業名を教えてください
問い合わせがあった際に突合を行う想定で実施した質問である。L5G 実証参加企業からの回答が含まれるが、多種多様な企業からの回答があった。大手企業に限らず中小企業からも回答があり、5G ソリュー
ションの導入を検討する企業は特定の領域に限られないことが示唆されている。
Q2. 回答者様の業種を教えてください(n=44)
サイト来訪者の業種を確認し、サイトに来訪する方が掲載した業種区分と概ね整合しているかを確認する目的で実施した質問である。
結果として、当初の想定よりも多様な業種の方からの回答があった。特定の業種の方のみが 5G ソ
リューションに対し関心を持っている訳ではなく、多様な業種の方からの関心があることが示唆された。

42

一方、設定した 6 つの区分に当てはまらない回答が多く、製造業、不動産、コンサルティング、放送、公務員等計 17 の業界からの回答もあり、より詳細な業種区分が必要と考えられる。掲載ソリューショ
ンは実証を行っているものを中心に掲載していたため、6 つの区分に絞って掲載を行ったが、掲載できない業種区分が多数発生することとなった。提供者アンケート分析の Q1 で前述したとおり、製造業は事前に適切な区分を設定可能だったため実運用時には設定が必要と考える。その他業種に関しては 5G
ソリューションが現在よりも幅広い業種で構築されていく中で追加していくべきだと考えられる。

Q2.回答者様の業種を教えてください (n=44)
12%
9%
6%
6%
3%

64%

建設業・オフィス

医療・介護

防災・セキュリティ

交通・モビリティ

観光・商業

農林水産・酪農/畜産

その他

図 2.3.2-1 利用者アンケート「サイト利用者の業種確認」
Q3. 回答者様の部署を教えてください (n=44)
サイト来訪者の部署を確認し、主な対象を特定する目的で実施した質問である。
結果として、経営管理や営業本部等の管理部門が最も多く、ICT 事業部等の実際にソリューション開
発や販売を行っている部署等も多く存在した。業種のみならず、部門も様々であった。このことから、当初想定したよりも幅広い属性の閲覧者を募ることができたと言える。
Q4. 回答者様の役職を教えてください(n=44)
サイト来訪者の役職を確認し、主な対象を特定する目的で実施した質問である。
結果として、管理職以上の割合が高く約 42％となった。こちらについても、部署同様当初想定したよりも幅広い属性の閲覧者を募ることができたと言える。
Q5. 当サイトに来訪した理由を教えてください(n=44)
サイト来訪者の来訪目的を確認し、当サイトの使用場面を特定する目的で実施した質問である。
結果として、約 55%が顧客への提案を目的としてソリューションの調査を行っており、残りの約 45%が自社への導入を目的としてソリューション調査を行っていることが明らかになった。当初は、自社
43

への導入を目的とする方が多くなると想定していたが、実際は顧客への提案の方が主流となっていた。これは、自社への導入を目的とした調査は特定の分野に関する調査にとどまるのに対し、顧客への提案では広く調査を行うケースがある事が原因として考えられる。

Q5.当サイトに来訪した理由を教えてください (n=44)

45%
55%

1.自社の課題解決に繋がるソリューションを探している
2.顧客に提案するためのソリューションを探している

図 2.3.2-2 利用者アンケート「サイト利用目的の確認」
Q6. 貴社(顧客)の現在抱えている課題の中で最も当てはまるものをお選びください(n=44)
サイト来訪者の課題を確認し、当サイトの掲載情報との関連性の確認を目的として実施した質問である。
結果として、業務の効率化が約 34.1%、新規顧客の開拓が約 25.0%、サービス向上が約 13.6%、働き方改革が約 11.4%となった。これらが約 85%を占めているため、5G ソリューションに興味を持つ企業の主な課題は以上 4 項目である可能性が高いと考えられる。

44

Q6.貴社(顧客)の現在抱えている課題の中で最も当てはまるものをお選びください (n=44)
16
14
12
10
8
6
4
2
0

15
11
6

5
2

2

1

2

図 2.3.2-3 利用者アンケート「解決したい課題の確認」
Q7. 抱えている課題に対する対応状況を教えてください(n=44)
サイト来訪者の課題に対する対応状況を確認し、当サイトの掲載情報で求められる内容の確認を目的として実施した質問である。
結果として、課題解決に向けて具体的な解決手段が定まってきている層が約 27%程度、技術に目途がついてきた層が 36.4%、目途が立っていない層が 36.4%となった。具体的な解決手段を見つけられていない方が多数派であると確認できた。

図 2.3.2-4 利用者アンケート「課題の検討フェーズ確認」
Q8. 当サイトで自社(顧客)の課題解決につながる情報を見つけられましたか (n=44)
サイト来訪者の課題解決に繋がったかを確認し、当サイトの掲載情報で求められる内容の確認を目的として実施した質問である。
45

結果として、約 43%が課題解決に繋がる情報を見つけることができ、約 57%が見つけることができな
かったと回答した。過半数が探している情報にたどり着けていないため、Q8-B-1 における情報にたどり着けなかった利用者が、当サイトに求めていた情報を整理することで、原因を考察する。

Q8.当サイトで自社(顧客)の課題解決につながる情報を見つけられましたか (n=44)

43%
57%

課題解決に繋がる情報を見つけることができた
課題解決に繋がる情報を見つけることができなかった

図 2.3.2-5 利用者アンケート「課題の解決に繋がったか確認」
Q8-A-1. 見つけられたものはどんな情報でしたか (n=19)
Q8 の質問に「課題解決に繋がる情報を見つけることができた」と回答した方を対象に、サイト来訪者の課題解決に繋る情報が何だったのかを確認し、当サイトの掲載情報で求められる内容の確認を目的として実施した質問である。
結果として、「IoT デバイスを用いたソリューション機器等」、「近くの同業者の情報の確認」、「L5Gを活用した様々な分野でのユースケース」等が挙げられていた。各業種における利用可能なソリュー
ションの実例を知りたいという意向が主だと考えられる。他、特定ソリューションに関する情報を回答
されているケースもあり、ピンポイントで課題解決に繋がった例であると考えられる。
Q8-A-2. 課題解決につながる情報にはたどり着きやすかったですか(n=19)
Q8 の質問に「課題解決に繋がる情報を見つけることができた」と回答した方を対象に、サイト来訪者の課題解決に繋がる情報へのたどり着きやすさを確認し、当サイトの掲載情報の掲載・表示方法が情報
到達性の高いものだったかを確認することを目的として実施した質問である。
結果として、約 74%がたどり着きやすいもしくは、どちらかといえばたどり着きやすいと回答しており、残りの約 26%がどちらともいえないとの回答であった。このことから探している情報にたどり着けた利用者にとっては、当サイトの掲載・表示方法が概ね問題ない形であったと判断できる。

46

図 2.3.2-6 利用者アンケート「情報への到達性確認」
Q8-B-1. どんな情報をお探しでしたか(n=25)
Q8 の質問に「課題解決に繋がる情報を見つけることができなかった」と回答した方を対象に、探していた情報を確認し、当サイトで掲載すべきであった情報を確認することを目的として実施した質問である。
結果として、「小売業の業務に関する情報」等の特定業界やより小規模な事業者に向けた情報を求める意見と、「オフィスの効率的な利用と利用者のモチベーションの向上」など解決したい課題に紐づく
情報を求める意見等があった。これらは、当サイトの掲載・表示方法などの情報到達性に起因するものではなく、掲載されているソリューションのバリエーション不足による意見といえる。
これらのよりニッチな業種、規模感の課題解決のできるソリューション自体が今後増えていくことに加え、ユースケースの明示、導入事例の拡充により対応可能と考えられる。
Q9. ご覧になったソリューションや実証事例を以下よりお選びください（複数選択可）(n=44)
サイト来訪者の閲覧したソリューションを確認し、当サイトの利用者の関心を確認することを目的として実施した質問である。
結果として、特定のソリューションが閲覧されないということはなく、全ソリューションが閲覧されており、今回掲載したソリューションに対する関心が確認された。利用シーンの限られるソリュー
ションよりも幅広く利用できると考えられるソリューションを閲覧される傾向が高くなっていた。

47

表 2.3.2-1 利用者アンケート「アクセスしたソリューションの確認」
ソリューション名
回答数#001 NTTコミュニケーションズ株式会社「鉄道車両監視AIシステム」
15#002 シャープ株式会社「最適経路によるロボットトラクターの遠隔制御システム」
8#003 NTTデータ経営研究所「ゆず生産スマート化システム」
5#004 西日本電信電話株式会社「AI画像解析や見回りロボットによる高品質和牛の肥育効率化」
5#005 株式会社ZTV「ブリ養殖における自動給餌システム」
4#006 株式会社秋田ケーブルテレビ「洋上風力発電ブレード点検効率化ソリューション」
3#007 富士通株式会社「設備点検作業の自動化・省人化」
13#008 富士通株式会社「高精度映像測位ソリューション」
6#009 株式会社ハートネットワーク「工場向けAIによる精製物の自動粒度判定システム」
2#010 九州電力株式会社「火力発電所のスマート保安の実現」
3#011 東日本電信電話株式会社「空港制限区域内ターミナル連絡バスの複数台遠隔型自動運転」
3#012 西日本電信電話株式会社「港湾向けトレーラー待機場の混雑状況等可視化ソリューション」
4#013 株式会社NTTデータ関西「高精細4K映像リアルタイム伝送による防災業務ソリューション」
8#014 東日本電信電話株式会社「遠隔高度医療支援サービス」
10#015 トランスコスモス株式会社「病院特化型映像共有ソリューション」
7#016 NTTコミュニケーションズ株式会社「救急搬送中患者の遠隔データ連携システム（仮称）」7#017 株式会社アルム「救急病院間における遠隔画像伝送ソリューション」
5#018 国際航業株式会社・日本電気株式会社・西尾レントオール株式会社・電気興業株式会社「災害時のリアルタイム状況把握と迅速な応急復旧ソリューション」
6#019 首都高速道路株式会社「電波環境の維持管理効率化ソリューション」
2#020 アイテック阪急阪神株式会社「AI搭載・ネットワーク対応型車内防犯カメラ」
8#021 ＦＣＮＴ株式会社「高画質映像ストリーミング対応小型カメラ端末」
8#022 シャープ株式会社「ローカル5G対応防水・防塵・小型USBドングル端末」
6#023 シャープ株式会社「ドローンを用いたインフラ点検および災害現場検証ソリューション」
7#024 株式会社地域ワイヤレスジャパン「ゴルフ場におけるコース運営の効率化及び新たなゴルフ体験の実現」
5#025 株式会社地域ワイヤレスジャパン「河川監視システム」
4#026 株式会社地域ワイヤレスジャパン「IP映像配信によるテレビ受信障害の応急復旧システム」
1#027 東日本電信電話株式会社「収穫適期判定、遠隔指導、自動収穫及び遠隔ショッピングシステム」
4#028 住友商事株式会社「工場向けキズ検知ソリューション」
3#029 住友商事株式会社「鉄道車両ドア閉扉判断の高度化ソリューション」
1#030 住友商事株式会社「車両前方カメラによる鉄道沿線の異常検知ソリューション」
4#031 KDDIエンジニアリング株式会社「屋内スポーツにおける魅力的な映像コンテンツを提供するソリューション」3

Q10. ソリューションや実証事例のどの情報を見てクリックしましたか(n=44)
サイト来訪者が何を根拠にソリューションを閲覧するのかを確認し、当サイトの利用者の判断材料を確認することを目的として実施した質問である。カタログサイトの設計においては、業種一覧（市場・ニーズ）と技術一覧（シーズ）、双方からソリューションへの動線を用意することで、閲覧者の情報収集の嗜好性を検証する狙いがあった。
結果として、業種名が 27.3%と最多であり、次いで実証段階か実装済みのソリューションかという掲
載区分 25%、タイトルから想定される利用シーン 20.5%、技術名 11.4%となった。業種、技術の 2 項目で見ると、シーズ起点より、課題解決のためのアイデアを市場・ニーズから探す傾向が示唆された。ソリューションの情報掲載においては、「利用される業種や解決する課題」を優先し、「利用される技術や構成等」は劣後させることが望ましい。

48

Q10.ソリューションや実証事例のどの情報を見てクリックしましたか(n=44)
15

10

5

0
業種名

掲載区分

タイトルから想定される

無線種別

技術名

提供会社

利用シーン

図 2.3.2-7 利用者アンケート「情報へのアクセスを決定する要素の確認」
Q11. 当サイトで問い合わせを行ったか教えてください(n=44)
カタログサイトの基本機能（問合せ機能）の実際の利用を確認する質問である。本実証では、実証事
業用のウェブサイトであることを事前周知しており、掲載内容への積極的な問い合わせは発生しない想定であった。一方、その中でも問い合わせをする閲覧者については、状況や問い合わせ事項を把握する必要があると考え、本質問を設定した。
結果として、本実証期間を通じてサイト運営事務局としては 1 件の問い合わせを受領した。内容は協業の申し出 1 件、その他サイト運営事務局以外への問い合わせ 3 件であった。
Q11-A. ご覧になったソリューションや実証事例について、問い合わせを行いより詳しく知りたいと感じた理由として最も当てはまるものを以下よりお選びください(n=3)
サイト来訪者が問い合わせを行う目的を確認し、当サイトの利用者が求める情報を確認することを目的として実施した質問である。Q11 で問い合わせを実施したと回答した方を対象とした。
結果として、「本格的な導入の検討を行いたい」が 2 件と「比較検討を行いたい」が 1 件であった。
実際に、当サイトでソリューションの情報を獲得し、導入を検討したいと考えるまでに至るケースがあることが確認できた。
Q11-B-1. ご覧になったソリューションや実証事例について、より詳しく知りたいと感じた情報はございますか。以下より最も当てはまるものをお選びください(n=41)
サイト来訪者が求めていた情報を確認し、当サイトの利用者が求める情報を確認することを目的として実施した質問である。Q11 で問い合わせを行わなかった方を対象とした。
結果として、他社導入事例を求める方が 61.0%、より詳細な機能を求める方が 17.1%となった。特に他社導入事例を求める方が多かった背景としては、導入検討時参考とする用途や、具体イメージを知るという用途での利用が多いことが想定される。

49

Q11-B-1. ご覧になったソリューションや実証事例について、より詳しく知りたいと感じた情報はございますか。以下より最も当てはまるものをお選びください(n=41)
30

25

20
7

10
1

2

1

2

6

0

3

4

その他

1.本格的に導入を検討したい /見積もりや利用条件等を知りたい
2.他ソリューションの比較検討をしたい / 機能一覧や必要な環境等を知りたい
3.機能等のより詳細な情報が知りたい / 自社の課題解決につながるか見定めたい
4.さらに多くの他社導入事例を見たい
その他

図 2.3.2-8 利用者アンケート「より深く知りたい内容の確認」
Q12. 当サイトを閲覧して、気になったソリューションや実証事例を利用したいというご意向は高まりましたか(n=44)
サイト来訪者が当サイトで利用意向が向上するかを確認し、当サイトの方向性で実際の導入促進が行えるのかを確認することを目的として実施した質問である。
結果として、高まったとやや高まった合計で 47.4%、変化なしが 50%となった。おおむね効果があったといえるが、やや低くなったとの意見も 1 件在した。

Q12.当サイトを閲覧して、気になったソリューションや実証事例を利用したいというご意向は高まりましたか(n=44)
25
20
15
10
5
0
高まった

やや高まった

変化なし

やや低くなった

低くなった

図 2.3.2-9 利用者アンケート「利用意向の変化確認」
50

Q13. 今後 5G ソリューションを調べる際に利用する情報ソースとして、以下より利用したいものをお答えください（複数選択可）(n=44)
サイト来訪者が求める情報ソースを確認し、当サイトのようなポータルサイトの需要を確認することを目的として実施した質問である。
結果として、約 71%の方が利用したいと回答しており、需要は高いと考えられる。

Q13.今後5Gソリューションを調べる際に利用する情報ソースとして、以下より利用したいものをお答えください（複数選択可）(n=44)
0

5

10

15

20

25

30

当サイトのような情報ポータルサイト

31

各社HP

20

取引関係のある企業様に聞く

12

記事・ニュース
SNS(Twitter等)・業界団体

35

21
1

図 2.3.2-10 利用者アンケート「情報源としての役割確認」
Q14. 今後最も利用したい情報ソースについて、利用したいと感じた理由を教えてください(n=26)
サイト来訪者が求める情報ソースを確認し、サイト利用者が当サイトのようなポータルサイトの役割をどう捉えているか確認することを目的として実施した質問である。
結果として、情報を広く獲得する目的等でポータルサイトを選択されることが多かった。記事やニュース、各社 HP も利用意向が高く、理由としては広く浅く情報が掲載されているポータルサイトに対し、速報性の高いニュースや客観性の高い記事、詳細な各社 HP と情報ソースごとに利用目的が異なるためだと考えられる。
Q15. 掲載ソリューションや実証事例が更新された際に、再度当サイトを利用して情報収集をしたいと思いますか(n=44)
サイト来訪者の当サイトの利用意向を確認し、当サイトのようなポータルサイトの価値を確認することを目的として実施した質問である。
結果として、「そう思う」と「どちらかといえばそう思う」合計で 81.9%となっている。そのため各社 HP やニュースと併用して当サイトも情報収集ツールとして活用される可能性が示唆された。

51

Q15.

掲載ソリューションや実証事例が更新された際に、再度当サ
イトを利用して情報収集をしたいと思いますか(n=44)
2%

16%
36%

46%

そう思う

どちらかといえばそう思う

どちらともいえない

どちらかといえばそう思わない

そう思わない

図 2.3.2-11 利用者アンケート「サイト利用意向の確認」
以下では、利用者の属性をより深く把握すること、検証項目である課題への対応状況ごとにサイトに求められる情報は何か、課題に即した情報が掲載されていればソリューションが閲覧され、ソリュー
ションの導入意向が高まるのかといった項目を確認するため、それぞれの設問のクロス集計を行った。
Q2×Q7 利用者の業種×課題と感じる項目
サイト来訪者の業種ごとの自社の抱える課題の傾向を確認した。特定の業種において課題が明確に偏ることはなかった。これは、業界によらず課題は個社別に存在することによると考えられる。

52

Q2×Q7クロス集計(業種×検討フェーズ)
0

2

1.業務の効率化
2.コストの削減

2
1

4
2

6
1

10

12

14

16

10

1

3.新規顧客の開拓

114.データに基づく意思決定15.働き方改革1

1

6.サービス向上

1

1

7.顧客ロイヤリティの向上
その他

8

3
4

2

1

1

1.観光・商業

2.建設業・オフィス

3.交通・モビリティ

4.農林水産・酪農/畜産

5.防災・セキュリティ

6.医療・介護その他.コンサルティング

図 2.3.2-12 利用者アンケート「来訪者の業種と課題に対する検討フェーズ」
Q5×Q6 自社/提案×課題 (自社側の課題：n=17)
過半数が業務の効率化を課題としており、次いでサービスの向上や働き方改革が選択された。自社の喫緊の課題として業務効率化を目的としている方が多く、それらの課題の解決に 5G ソリューションが期待されていることが明らかになった。
Q5×Q6 自社/提案×課題 (顧客への提案の課題：n=24)
顧客への提案を行う際には、主な課題を新規顧客の開拓としている企業が最も多く、業務の効率化は二番手となっている。その他、コンサルティング業種の方など顧客に提案する目的でソリューションの閲覧を行なっている方が多いため、新規顧客の開拓、サービス向上が選択される方が多かったと考えられる。

53

自社導入目的の企業の課題
5%
11%
11%
56%
17%

業務の効率化

サービス向上

新規顧客の開拓

働き方改革

コストの削減データに基づく意思決定

図 2.3.2-13 利用者アンケート「自社導入目的の企業の課題」

顧客提案目的の提案先企業の課題
8%
24%

12%

12%

4%

4%
36%

1.業務の効率化

2.コストの削減

3.新規顧客の開拓

4.データに基づく意思決定5.働き方改革6.サービス向上

7.顧客ロイヤリティの向上

図 2.3.2-14 利用者アンケート「顧客提案目的の提案先企業の課題」
二つの結果より、自社への導入を目的とする企業と顧客への提案を目的とする企業では関心を持つ課
題が異なることが明らかとなった。原因としては、業務の効率化は社内で解決可能な課題として認識されており、新規顧客の開拓は多くの企業で課題となっていると認識されている可能性が高いことが挙げ
られる。

54

Q7×Q9‘ 課題に対する対応・検討フェーズ×求める情報「1. ある程度解決手段が決まっている/導入に向けて見積もり等の具体的な準備をしている」のフェーズの方は、「製品カタログ」や「業務効率化の方向性」に関する情報を求めて来訪していた。
「2.ある程度解決手段が定まってきている / 他解決手段と機能や要件等を比較している」のフェーズの方は、「ロボット」や「カメラソリューション」に関する情報を求めて来訪していた。「3.課題解
決できそうな技術に目処がついてきている / 複数の商材から解決できるものを調査中」のフェーズの方は、「ユースケース」や「医療ソリューション」に関する情報を求めて来訪していた。「4.課題解決の目処が立っていない / 他社事例の調査中」のフェーズの方は、「製品カタログ」や「各種ソリューション」に関する情報を求めて来訪していた。傾向としては、検討が進むにつれその他に含まれる情報が増えていることから、求める情報が多様化している。

図 2.3.2-15

利用者アンケート「課題に対する検討フェーズと求める情報」

Q7×Q18 課題に対する対応・検討フェーズ×継続利用の意向
80%以上の方が継続利用したいかという問いに「そう思う」「どちらかといえばそう思う」と回答していただいている。極めて高い水準で継続利用の意向があった理由の分析として、自社の抱える課題への対応・検討フェーズが進むほどサイトの継続利用意向が高まるのかを確認した。
結果として、「課題解決できそうな技術に目途がついている/他解決手段と機能や要件等を比較している」と回答した方のうち 80%が当サイトを継続利用したいと考えている。これは、本サイトが比較する際の情報集積に適していると捉えられているからだと考えられる。

55

Q 7 × Q 1 8 ク ロ ス 集 計 （ 検 討 フ ェ ー ズ × 継 続 利 用）
1.そう思う2

2.どちらかといえばそう思う

2

3.どちらともいえない

4.どちらかといえばそう思わない

8

4

1 1 1

5

7

7

4

1

5.そう思わない

1.ある程度解決手段が決まっている / 導入に向けて見積もり等の具体的な準備をしている
2.課題解決できそうな技術に目処がついている / 他解決手段と機能や要件等を比較している
3.課題解決できそうな技術に目処がついている / 複数の商材から解決できるものを調査中
4.解決手段わからない / 他社事例の調査中

図 2.3.2-16

利用者アンケート「課題に対する検討フェーズとサイトの継続利用意向」

Q8×Q15 情報へたどり着けたか×ソリューション導入意向の変化
課題解決に繋がる情報を見つけることが 5G ソリューションの利用意向に影響を与えるかを確認した。
結果として、課題解決に繋がる情報を見つけることが出来た層は、5G ソリューションの利用意向が「高まった」と回答した方の中で 86%を占めており、利用意向と情報を見つけることが出来たかは密接に関係していると考えられる。一方、課題解決に繋がる情報を見つけることが出来なかった層は、5G 利用意向が「変化なし」「やや低くなった」に多く分布している。 注目したいのは、「課題解決に繋がる
情報を見つけることが出来なかった」方で、利用意向が「高まった」「やや高まった」が存在することである。求めていた情報ではないが、利用意向に影響する情報を見つけられたと考えられる。どの情報に触れたことが利用意向に関連するのかを明らかにすることが出来れば、より利用意向の向上に適したサイトとなる可能性がある。
Q13 での当サイトの情報源としての役割確認と Q14 での今後の情報ソースとして活用したい理由の集計結果と合わせて検討すると、ポータルサイトに求められる役割は幅広く多くの事例に関する情報の提供であることから、自社として最も欲しい情報だけではなく、同業他社の取り組みなどを提供できたことが利用意向の向上に影響した可能性がある。

56

Q8×Q15クロス集計（ た ど り 着 け た か × ソ リ ュ ー シ ョ ン の 利用 意向 の 変 化 ）86%

1.高まった(n=7)

14%

57%

2.やや高まった(n=14)

43%

23%

3.変化なし(n=22)

77%
100%

4.やや低くなった(n=1)
5 . 低 く な っ た ( n = 0 ) 0%

1.課題解決につながる情報を見つけることができた
2.課題解決につながる情報を見つけることができなかった

図 2.3.2-17

利用者アンケート「情報到達とソリューション利用意向の変化」(C) 利用者アクセス解析検証結果
分析対象期間の 2023 年 1 月 27 日から、2023 年 2 月 24 日までの約 1 か月間で当カタログサイトへの総アクセスユーザは 606 ユーザであった。
各検証項目に対して GA4 にて計測可能な項目の計測結果を以下に示す。
検証項目：カタログサイト利用者の求める情報・アクセス数の多い技術名「技術から探す」カテゴリで設定した 6 つの技術名のそれぞれのクリック数を確認した。技術から探す場合の動線がサイト内に複数あるため、GA4 でカウントが可能な 1 つの動線のみを計測した。ランディ
ングページの「技術から探す」カテゴリで、技術名をクリックし、選択した技術のソリューション一覧
ページに遷移した数を計測した。
結果として、AI のクリック数が 38%と最も多く、次いで IoT が 22%、その他 4 区分については 10%程
度と横ばいであった。

57

技術名のクリック率(n=45)
9%
9%
38%
11%

11%
22%
AI

IoT

ロボット

自動運転

建設機械

ドローン

図 2.3.3-1 利用者アクセス解析「技術名ごとのクリック率」
検証項目：カタログサイト利用者の抱える課題に則した情報であれば閲覧されるか・ソリューション詳細ページの閲覧率
ソリューション詳細ページを閲覧した利用者数の計測を行った。全体の 606 ユーザに対し、ソリュー
ション詳細ページを閲覧したユーザは 31.0％の 188 人であった。
・ソリューション一覧ページからの離脱率
ソリューション一覧ページでソリューションのタイトルやサムネイル、検索タグとして設定した情報を見て、サイト利用者が自社に関連するソリューションだと判断し、ソリューション詳細ページへ遷移
すれば、利用者の抱える課題に則した情報により閲覧されたと言える。一方で自社の課題に即した情報でないと判断されれば、ソリューション一覧ページからの離脱率が高くなると考えられる。よって、ソリューション一覧ページからの離脱率が極端に高くないかを計測した。
結果として、
サイト全体の離脱数 746 件に対し、ソリューション一覧ページから離脱した件数は 15.6％の 117 件となった。ソリューションの閲覧を終えてソリューション一覧ページを再度確認してから離脱した件数も含まれていることを加味すると、ほとんどの利用者が閲覧を進めた可能性があると判断できる。

58

図 2.3.3-2 利用者アクセス解析「ソリューション一覧ページからの離脱率」
検証項目：カタログサイト利用者は必要な情報にたどりつくことができたか
・関連 URL クリック数
利用者の求めるソリューションが見つかり、より詳細な情報を得るために関連 URL のリンクをクリッ
クしたとみなす。
結果として、ソリューション詳細ページに表示されている関連 URL のクリック数は 15 件であり、ソリューション詳細ページを閲覧した 188 人のうち約 8％がより詳細な情報を求めていることが分かる。
・ソリューション詳細ページの滞在時間
ソリューション詳細ページの滞在時間として、セッションあたりの平均エンゲージメント時間を計測した。
結果として、平均 31 秒間ソリューション詳細ページが閲覧されていることが分かった。全体で 33 ソ
リューションが閲覧されたが、うち滞在時間が極端に短いものとして 10 秒程度のソリューションが 5件ほどあったが、概ね掲載情報を閲覧し切るだけの滞在をしていたと判断できる。

59

表 2.3.3-1 利用者アクセス解析「各ソリューションページの平均滞在時間」
セッションあたりの平均エンゲージメント時間

ページ タイトルとスクリーン名
AI搭載・ネットワーク対応型車内防犯カメラ - 5GSharingSolutions

34

AI画像解析や見回りロボットによる高品質和牛の肥育効率化 - 5GSharingSolutions

32

IP映像配信によるテレビ受信障害の応急復旧システム - 5GSharingSolutions

47

ゆず生産スマート化システム - 5GSharingSolutions

27

ゴルフ場におけるコース運営の効率化及び新たなゴルフ体験の実現 - 5GSharingSolutions

25

ソリューション一覧 - 5GSharingSolutions

48

ドローンを用いたインフラ点検および災害現場検証ソリューション - 5GSharingSolutions

21

ブリ養殖における自動給餌システム - 5GSharingSolutions

32

ローカル5G対応防水・防塵・小型USBドングル端末 - 5GSharingSolutions

21

収穫適期判定、遠隔指導、自動収穫及び遠隔ショッピングシステム - 5GSharingSolutions

30

屋内スポーツにおける魅力的な映像コンテンツを提供するソリューション - 5GSharingSolutions

22

工場向けAIによる精製物の自動粒度判定システム - 5GSharingSolutions

37

工場向けキズ検知ソリューション - 5GSharingSolutions18

救急搬送中患者の遠隔データ連携システム（仮称） - 5GSharingSolutions30

救急病院間における遠隔画像伝送ソリューション - 5GSharingSolutions13

最適経路によるロボットトラクターの遠隔制御システム - 5GSharingSolutions

32

検証協力企業等一覧 - 5GSharingSolutions

19

河川監視システム - 5GSharingSolutions

9

洋上風力発電ブレード点検効率化ソリューション - 5GSharingSolutions

41

港湾向けトレーラー待機場の混雑状況等可視化ソリューション - 5GSharingSolutions

13

火力発電所のスマート保安の実現 - 5GSharingSolutions

78

災害時のリアルタイム状況把握と迅速な応急復旧ソリューション - 5GSharingSolutions

19

病院特化型映像共有ソリューション - 5GSharingSolutions

31

空港制限区域内ターミナル連絡バスの複数台遠隔型自動運転 - 5GSharingSolutions

35

設備点検作業の自動化・省人化 - 5GSharingSolutions

32

車両前方カメラによる鉄道沿線の異常検知ソリューション - 5GSharingSolutions

12

遠隔高度医療支援サービス - 5GSharingSolutions

47

鉄道車両ドア閉扉判断の高度化ソリューション - 5GSharingSolutions

38

鉄道車両監視AIシステム - 5GSharingSolutions

81

電波環境の維持管理効率化ソリューション - 5GSharingSolutions

22

高画質映像ストリーミング対応小型カメラ端末 - 5GSharingSolutions

24

高精度映像測位ソリューション - 5GSharingSolutions

28

高精細4K映像リアルタイム伝送による防災業務ソリューション - 5GSharingSolutions
平均滞在時間1130.6

検証結果のまとめと将来的発展形態の仮説構築したカタログサイト及び搭載した情報、今回検証を行った(A)5G ソリューション提供者アンケー
ト、(B)利用者アンケート、(C)利用者アクセス解析の結果を踏まえ、カタログサイトの有効性、将来的に必要となる情報発信等の形態、求められる情報・機能等について取りまとめる。

(A)5G ソリューション提供者アンケートによる検証結果
60

(A)5G ソリューション提供者アンケートでは、①カタログサイトに対し、5G ソリューション提供者にコンテンツ投稿に対して意欲的であるかを確認した。具体的にはコンテンツの投稿に意欲的か、提供するコンテンツのターゲットユーザの業種、カタログサイトに投稿したい情報は何かを把握することで意欲を確認した。また、②カタログサイトへのコンテンツ投稿への意欲が稼働負担により損なわれることがないかを確認した。具体的には既存提案資料やプロモーションコンテンツを活用して投稿ができたか、
カタログサイトへのプロモーションの期待度合いに対してコンテンツ投稿にかけた稼働が見合うもの
だったかを確認した。③カタログサイトに対し、求める機能についても確認した。これにより、本実証で構築したカタログサイトの機能は十分だったか、将来的にカタログサイトに求められる機能は何かを確認した。
以下①～③での検証結果をまとめる。

①5G ソリューション提供者のコンテンツ投稿に対する意欲
協力依頼に対しほぼ全ての企業が掲載に前向きであった。提供者アンケート Q2 でも集客効果に対し期待しているとの回答が多く、広く閲覧してほしいと考えている企業が多いと考えられる。
サイト運営側が設定する業種区分と提供者のターゲットとする業種区分に一部差があり、実証を行っている業種に限らず複数の業種に掲載を行いたい提供者や、より詳細な業種区分を求める提供者が存在する。幅広い用途で利用できるソリューションでは、業種に縛られないケースがある事などが原因であると考えられる。製造業等を含めることでより一般化した業種区分とすることが出来ると考えられる。
掲載したい情報は、70%以上の提供者が掲載できたと回答している。掲載したかったが今回掲載できなかった情報としては、「動画や画像の掲載」「業種区分の不足」「特徴等の訴求」等が挙げられており、利用者により深く理解してもらうための情報と、見つけてもらう為の情報が主であるといえる。実運用の際には、掲載可能とする情報量の調整が必要となる。

②コンテンツ投稿の稼働負担
提供者アンケート Q5 で 90%以上の提供者は既存の提案資料やプロモーションコンテンツをそのまま
もしくは一部修正して使うことが出来たと回答している。流用を行う事で、既存のプロモーションと並行してカタログサイトにも掲載するような利用方法が行われると考えられる。
プロモーション効果への期待度合いと入力作業にかかる負担のバランスについては、提供者アンケー
ト Q2-A-1 より継続掲載を行いたい企業が 90%以上となり、期待度合いが大きかった。今回の入力作業を負担に感じたかを確認した提供者アンケート Q4 と合わせて検討すると、入力作業の負担がほとんどないことから継続掲載に前向きな結果が出たと考えられる。掲載情報量を増やしたいという意見もあり、バランスを検討する必要がある。また、今回掲載したのは実証中のソリューションが中心であり、実運用時は販売されているソリューションが多くなると考えられる。ソリューション提供者の持つプロモーションコンテンツが実証時よりも充実していることが予想され、負担の軽減が見込めるケースもあると考えられる。

61

③カタログサイトに求める機能
機能要望として、「より強力な検索機能」「比較機能」「簡単見積もり機能」「問い合わせ等コミュニケー
ション機能」等が挙げられており、提供者ごとに有用と考える機能に差がある事が分かった。実運用ではソリューション数が増加することが予想され、検索機能や比較機能が求められると考えられる。見積
もり機能は 5G ソリューション環境の利用者ごとに見積条件が煩雑になる懸念があることから、汎用的に利用可能か検討が必要と考えられる。問い合わせ機能を強化する場合、提供者-利用者間のチャット機能やチャットボット等の活用が考えられる。提供者アンケート Q7 では、サイト利用者がソリューションの導入を決定した際にも、提供者としてはサイト内での決済機能が不要であることが分かった。自社で既に決済フローが決定しており、サイト内の決済機能を利用することでかえって時間がかかってしまうケースがあるためだと考えられる。

表 2.4.1-1 提供者アンケートによる検証結果と考察(B)利用者アンケート、(C)利用者アクセス解析による検証結果(B)利用者アンケート、(C)利用者アクセス解析では、カタログサイトへの需要があるのか、①カタロ
グサイトの来訪者が何を目的に来訪しているかを確認した。具体的には、自社で抱える課題を解決できるソリューションを検索しているのか、顧客等他社の課題解決ができるソリューションを検索しているのかといった来訪者属性を確認した。②来訪目的毎にカタログサイトに求める情報も確認した。これらの求める情報がカタログサイトに掲載されている場合、③利用者がカタログサイトで閲覧するコンテン
ツは何かを確認した。具体的には、利用者の課題に即した情報であれば閲覧されるのか、求めていた情報にたどり着けたのか、どのようなカテゴリで表示されていれば情報にたどり着けるのかを確認した。
④コンテンツを閲覧した結果、訪問前後でソリューションを利用したいという意向が高まったかも確認した。
以下①～④での検証結果をまとめる。
Google Analytics（GA4）によると訪問者数は計測期間の 1 ヶ月間で 606 ユーザとなり、自社・顧客に
62

課題を抱えている企業や 5G ソリューションに興味を持つ方にとって関心の高いサイトであると言える。
利用者アンケート Q2 の回答より利用者の業種も幅広く、5G ソリューションについて情報を獲得したい
ニーズは高いと言える。利用者アンケート Q13 や Q15 より今後 5G ソリューションを探す際に、当サイトのようなポータルサイトを利用したい意向が高く、各社 HP やニュースと併用することを期待していると考えられる。利用者アンケート Q7 と Q18 を合わせて分析すると、自社・顧客の課題解決に向けた調査を目下行っている方は、当サイトを継続的に利用する価値があるものだと捉えている。

①カタログサイト利用者の来訪目的
主な来訪目的としては、「顧客に提案可能なソリューションの調査」となる。一方、「自社の課題解決に繋がるソリューションの調査」も 45%程度であった。自社への導入だけでなく、顧客に提案を目的とする層がアクセスすることから、効率よく情報を伝播するためにも有効なサイトであったと考えられる。

②来訪目的毎にカタログサイト利用者が求める情報「顧客に提案可能なソリューションの調査」「自社の課題解決に繋がるソリューションの調査」ともに、追加で求めている情報として機能や項目ではなく「より多くの事例」が挙げられていることから、基本的に必要な情報は概ね問題なく掲載されていると考えられる。利用者が求めている情報はより多くの事例であり、詳細は各社 HP 等で確認するような使い方も考えられる。

③情報への到達性
利用者アンケート Q8 で過半数が求める情報にたどり着けなかったと回答した。原因を把握するため、
Q8-B-1 を確認すると小規模向けのソリューション等が求められており、当サイトの掲載・表示方法などの情報到達性に起因するものではなく、掲載されているソリューションのバリエーション不足によるものであったと言える。
利用者アンケート Q8-A-2 によると、情報にたどり着けた層の 74％がたどり着きやすかったと回答していることから、概ね情報到達性は高いサイトであったと言える。
タイトルやサムネイルをもとに求めている情報と異なると判断され、離脱しているケースがないか確認する目的で、GA4 による離脱ページの分析を行った。サイト全体の離脱数 746 件に対し、ソリューショ
ン一覧ページから離脱した件数は 15.6％の 117 件となった。ソリューションの閲覧を終えてソリュー
ション一覧ページを再度確認してから離脱した件数も含まれていることを加味すると、ほとんどの利用者が閲覧を進めた可能性があると判断できる。

④5G ソリューションの利用意向変化
利用者アンケート Q12 より、当サイトを見て 5G ソリューションの利用意向が高まった割合が約 50%であり、情報提供により一定の層に対しては利用意向を高めることが可能であると考えられる。特に、他の情報源があるにもかかわらず、当サイトで利用意向が高まった事より、詳細な情報を知るだけではな
く網羅的な情報提供による調査の第一歩の支援が求められている可能性がある。
63

表 2.4.2-1 利用者アンケート、アクセス解析による検証結果と考察

将来的に必要となる情報発信等の形態、求められる情報・機能①業種区分の充実
本実証では、掲載するソリューションを令和４年度 L5G 実証団体のソリューションに絞ったため、掲載されない業種等は省いたが、実際の運用では網羅的な業種区分の実装が求められる。利用者が閲覧するソリューション決定の際に確認する事項は利用者アンケート Q10 より、業種区分が最多である。そのため、今回の実証では掲載ソリューションがなく省かれた業種に関しても掲載を行い、わかりやすく分類することで利用者の利便性が向上すると考えられる。提供者がターゲットとしている業種および利用者の業種を加味すると、製造業や金融、通信等が一般に求められる区分であると考えられる。

②掲載文章量の調整
より多くの情報を掲載したいという提供者がいる一方、提供者の入力作業にかかる負担と利用者側から見た適切な文章量の設定が必要となる。加えて、本実証では提供者より情報を受け取り実証団体が代替して入力を行ったが、実運用では提供者が自ら投稿フォーム等を用いて情報提供を行う形式になることも考えられ、その際に負担にならないかを検討する必要がある。

③情報量の調整
文章以外の情報として、画像や動画等の掲載に関してまとめる。提供者より画像や動画を用いた情報提供を行いたいという意見があった。提供者が直接投稿できる仕組みにする際には、データアップロー
ド機能を実装し、任意項目とすることで対応は可能である。しかし、情報の量・質ともにソリューショ
ンごとのバラつきが出ることが予想され、どの内容を任意項目とするかは十分に検討が必要と考えられ64

る。

④ログイン機能（提供者）
ソリューション情報を提供者が入力する形式とする場合、提供者毎の情報管理のため必須となると考えられる。加えて、長期的に掲載を行う際には、掲載情報の更新等も必要となることが予想される。そのため、提供者が定期的に情報を更新しやすい仕組みも合わせて検討する必要がある。

⑤ログイン機能（利用者）
実運用時に問い合わせ、資料請求、ソリューションのお気に入り登録や購入等の機能を実装する際に必要となると考えられる。本実証ではアクセス解析やアンケートによる情報収集を行ったが、実装時には利用者情報を獲得する手段を用意しなければ利用者の各種要望に対する対応が困難であると考えられる。

⑥問い合わせ機能の強化
提供者より問い合わせ機能の強化を求める意見があった。問い合わせ機能には複数の手法があり、問い合わせメールの送信機能、サイト内でのチャット機能、チャットボット等が想定される。また、見積もり機能の要望もあったが、5G ソリューションの特性上、利用者環境による価格の変化等があり一律の価格を提示する仕組みはそぐわないと考えられ、チャットベースで気軽に相談が可能となるような形式が望ましいと考えられる。

⑦比較機能
利用者より類似ソリューションの比較機能を求める意見があった。本実証では、実証団体のソリュー
ションを中心とした掲載であり、ソリューション数が限られていたため問題とならなかったが、実運用時はより多くのソリューションが掲載されることが想定される。その際、同様の課題解決を目的とする
ソリューションが多数掲載されるケースが想定され、利用者が検討に適した情報を求めることが考えられる。異なるアプローチ等でも比較を行うための比較軸の検討が必要となる。

65

表 2.4.3-1 将来追加で求められる検討要素および機能

66

3.

5G ソリューションの共用形態に係る検証
1.1 節の目的でも詳述した 5G ソリューションの共用形態に係る検証を実施する経緯の概要を以下に記載する。
令和 2 年度 L5G 実証にて、鉄道事業者（京浜急行電鉄株式会社、以下「京急」）が実際に抱える課題の解決をめざした 5G ソリューションの一部として、オンプレミス型（SI 型）で「鉄道車両監
視 AI システム」を構築した。実証の結果、「鉄道車両監視 AI システム」は鉄道車両の異常検知に資することが確認できた。
「令和 3 年度 5GSC 実証」において、5G ソリューションの水平展開のユースケースを設定し、ダウンロード型（以下、DL 型）の「鉄道車両 AI システム」を構築し、西鉄の協力を得て実証した。その結果、「実装可能性」「水平展開可能性」「実用性」の観点で DL 型の 5G ソリューションの有効性を確認できた。一方で、導入側のシステム導入難易度や費用対効果面の課題があり、SaaS
型での検証および DL 型との比較検討が求められた。
今年度事業では、「鉄道車両監視 AI システム」を SaaS 型で構築し、その有効性を検証すること
で、ネットワークレベル及びアプリケーションレベルにおける 5G ソリューションの実装可能性をさらに向上させるとともに、鉄道分野及びその他の分野に横展開の可能性を検討していくこととした。
汎用化された 5G ソリューションを全国の利用者に効率的に提供するためにはプラットフォー
ムを用いた一元的なサービス提供方式への転換なども今後、構想検討が必要になると想定されるが、今年度実証においては、5G ソリューション共用形態に重点をおき、その課題解決について検討を行い、ソリューションの汎用化、共用方法の策定および、5G-SA サービスや MEC の高度化などの技術の活用により多くの利用者へ有益に活用できる横展開の方法を明確化することを目標とした。（図 3-1 参照）

67

図 3-1

ソリューション共用化に向けた取り組み

検証概要・目的
本事業においては、まず、以下の観点を主として 5G ソリューションの共用形態に関する検証を行う。
・SaaS 型アーキテクチャを用いた構成での実現性や課題確認
他提供形態（SI 型、DL 型）と比較して導入のハードルが低減される見込みの SaaS 型提供形
態であるが、アプリケーションが外部クラウド環境上に配置されるため、従来の SI 型や DL型と比較し、様々な環境要因による処理の遅延などが発生しやすいと想定される。本事業において、実地からクラウドまで含めた End To End の実証を行い、5G ネットワークの接続形
態（5G ネットワークとクラウド基盤の接続方式）やサーバやアプリケーション側における遅延緩和策などシステム・リソース要件など、今後の SaaS 型の事業者での検討に活用できる
よう SaaS 型の提供形態を採用する場合に起こりうる事象や課題について、様々な観点で実証を行い、以下、3.3 節にて結果を取りまとめる。
・SaaS 型で共用を行うための要素検証（汎用化検討）
SaaS 型の共用形態は、利用者側の負担軽減を目指すうえで有効な形態と見込んでいるが、複数のユーザによる利用を前提とするため、それに沿った機能開発やアーキテクチャの見直しが必要となる。共用のための仕組みや方策を検討し、その実現性や有用性の確認を行い、以68

下、3.4 節にて結果を取りまとめる。
・実運用も含めた負荷低減の効果の確認
SaaS 型アーキテクチャの導入並びに共用に必要な機能の開発は、実際の負荷軽減効果につながっている必要がある。本事業においては、アーキテクチャの実現性や機能検討だけでなく、実際に開発した汎用化、共用するための機能を事業会社に実際に利用いただいた上で運用した場合の負荷の確認等も行い、SI 型や DL 型と比較し、利用者観点としても効果的な 5G ソ
リューション等の普及展開方策となりうることを確認するため、検証を行い、以下、3.4.4 項
にて結果を取りまとめる。
上記を踏まえ、現実のユースケースを想定した 5G ソリューションとして令和 2 年度 L5G 実証事
業で SI 型として開発が行われ、令和 3 年度 5GSC 実証事業にて DL 型の検証もすでに検証が完了している「鉄道車両監視 AI システム」をモデルケースとして選定し、以下 3.1.1～3.1.3 までの検証に向け実際の利用者（鉄道事業者 2 社）の実環境に導入し、5G 環境にて共用形態に係る検証を行った。
また、構築・検証した共用形態（SaaS 型アーキテクチャの検証、5G ネットワークとクラウド基
盤の接続方式）を踏まえ、さらに高度化されていく 5G 技術と共用形態の親和性についても明らかにするため、5G 技術として今後活用が期待される 5GSA や MEC 技術を活用した場合における、5G
ソリューションの展開・共用に資する有効性、論点、今後必要となる検証点について以下、3.5 節にて机上検証を行った。
加えて、本事業における実証でモデルケースとして選定する 5G ソリューションで、当該ソリューションの一部コア部分または汎用化アーキテクチャ等が他分野へ展開可能であることが確認された場合、そのケースをさらに分野横断的な 5G ソリューションとして、SaaS 提供による横展開を進めていくために必要となる論点や課題を明らかにしていく必要がある。
これらの論点や課題を整理し、共用に向けた実現可能性や有効性を向上させる観点でそれらの実行を計画し遂行することが、今後、5G ソリューションを広く普及させるという目的に対して提供者が検討すべきポイントである。
以下、3.6 節において、SaaS 型でのソリューション提供を進めていくために必要となる論点として、ソリューション、共用形態で必要となる利用者/提供者での運用面の整理に関する論点や IT
サービス提供に関する技術的な課題に関する検討を行った。
3.7 節においては、SaaS 型でのソリューション提供を進めていくために必要となる論点を整理した結果を踏まえ、鉄道事業分野以外での本ユースケース活用を想定した際のシステムアーキテ
クチャの再評価および、提供形態や今後の提供に向けて必要となる検証に関して机上検証をおこなった。

SaaS 型アーキテクチャを用いた構成での実現性や課題の確認
5G ソリューションに係る検証において、実環境に導入して 5G 環境での共用形態に係る検証を69

行う前段階の作業として、選定された 5G ソリューションが、SaaS 型でも提供可能であることを確認し、5G ソリューションの構築に関する作業や課題等を明らかにする必要がある。
その確認のため、SaaS 型のソリューション提供環境を準備し、アーキテクチャ変更を行った上、SaaS 型の一般的な方式としてインターネット接続方式にて正常に動作が可能かどうかの検証を行った。
具体的には、3.1 節で本実証の選定する 5G ソリューション「鉄道車両監視 AI システム」を SaaS型として動作出来るよう設計を見直し、検証環境において SaaS 型で構築し、その環境におけるシステム性能及び正常性を確認する。DL 型から SaaS 型へ提供形態変更を行った上でも 5G ソリュー
ションが問題なく動作出来るかを実証し、選定したソリューションのアーキテクチャ変更及びリ
アルタイムの映像を用いた AI 解析を行う本ソリューションが、SaaS 型として実現可能かを確認した。
この際、特に、SaaS 型の論点となりうる観点を深掘って検証するため、DL 型で構築した場合との比較検証やクラウド上の処理リソースを変化させた際のシステム動作検証も取り入れ、SaaS 型システムで共用を行う際に論点となりうる「遅延性」の観点について、実環境を用いて影響の確認を行った。

SaaS 型での共用を行うための要素検討（汎用化検討）
本事業で選定する 5G ソリューションを一例として、機能面について、5G を活用した同種のソリューションを汎用的に利用することを想定することとした。そのため、本システムは汎用性を意識したアーキテクチャ及び検証項目を設計することとした。具体的には、現地設備から提供者
側クラウドへの接続、AI 解析の検知性能確認、処理リソースの共用利用等、複数の利用者で共用することを想定したシステム検証項目・方法を設計し、導入した。特に、DL 型との比較検証を通じて、SaaS 型の長所・短所を明確化する。
共用形態に係る検証においては、以下の汎用化レベルの定義に従い、各レベルにおける汎用化の効果の検証を行い、検証結果の分析と課題を整理した。
汎用化レベルは、下記の通り定義する。
（図 3.1.2-1 参照）


レベル 1
➢

NW/アーキテクチャ（SaaS 共用形態、接続形態）

SaaS 共用形態
汎用的な機能・アーキテクチャを用いたサービス提供形態➢

接続形態
異なる接続形態の長短所のまとめ



レベル 2
➢

共通コア機能（マルチテナント管理機能）

マルチテナント管理機能
・複数利用者のデータを独立して管理する仕組み
・複数利用者が共通のシステムを利用し、適切にリソースを活用する仕組み



レベル 3

AI コア機能（追加学習機能/特化型汎用モデル）
70

➢

追加学習機能専門家でなくても AI モデルを運用・維持管理できる仕組み➢

特化型汎用モデル
汎用性を維持しながらも、利用者ごとに特化した学習が可能な仕組み

図 3.1.2-1 汎用化検討のレベル別分類イメージ
まず、汎用化レベル 1 では、システムの NW/アーキテクチャの観点で汎用性及び利用者負担の軽減度合いを評価する。特に汎用性については、SaaS 型での共用で横展開を行う際に、NW/アーキ
テクチャが原因となり、そのシステムが今回選定した AI ソリューションのような特定分野のみに限定されるものでなく、その他の種類のソリューションにも適用可能であることを確認する。
本事業の AI ソリューション（モデルケース）は、汎用的な SaaS 型のアーキテクチャを取り入れて設計・構築する。また、クラウドへの接続形態やクラウド内部の NW 構成・リソース利用状況も明示的に評価する。これにより他の事業者は、SaaS 型 5G ソリューションを実装する際に、本事業の汎用的な知見を活用することができる。
なお、本項の評価は、3.4.1 項の検証結果に基づいて実施する。
次に、汎用化レベル 2 では、SaaS 型システム内部での分野横断的なコア機能について、汎用性及び利用者負担の軽減度合いを評価する。特に汎用性については、今回選定した AI ソリューショ
ンだけでなく、その他の種類のソリューションにも適用可能であることを確認する。
本事業の AI ソリューション（モデルケース）には、SaaS 型システムにおいて汎用的かつ効果的なコア機能を実装する。例えば、複数ユーザごとに独立したデータ格納領域を管理する機能（マ71ルチテナント管理）や、複数ユーザが同時にシステムを利用する並列処理機能等を明示的に評価する。これにより他の事業者は、SaaS 型 5G ソリューションを実装する際に、本事業の汎用的な知見を活用することができる。
なお、本項の評価は、3.4.2 項の検証結果に基づいて実施する。
最後に、汎用化レベル 3 では、SaaS 型 AI システムに関するコア機能について、汎用性及び利用者負担の軽減度合いを評価する。特に汎用性については、今回選定したソリューションだけでなく、その他の AI ソリューションにも適用可能であることを確認する。
今日、AI 技術（ディープラーニング）は、人の認知に到達する、または超越する技術として、
人間中心社会の課題解決型システムの根幹を担うトレンド技術である。特に、人口減少や少子高齢化による「担い手不足」、「技術継承」に課題を持つ業界から注目を浴びている。5G ソリューショ
ンの付加価値としても注目され、実際に令和 2 年度～4 年度総務省ローカル 5G 実証でも複数の事例が生まれている。
AI システムは、検知対象に特化した専用モデルを構築し、学習させる必要がある。そのため、汎用的なモデルを提供するだけでは、検知対象について高い検知精度が期待できず、SaaS 型での提供には不向きとされてきた。これは、AI システムの高コスト化(利用者の負担増大)に直結し、ソリューションの浸透を妨げる重大な課題である。
そこで、本事業の AI ソリューション（モデルケース）には、SaaS 型で活用するための汎用的かつ効果的なコア機能を実装する。特に、マルチテナント管理に基づいた SaaS 型での特化型汎用モデルの導入と、利用者による追加学習機能（アノテーション支援、学習機能）を提供し、評価する。これにより他の事業者は、将来的に SaaS 型で AI システムを実装する際に、本事業の汎用化の知見を活用することができる。
なお、本項の評価は、3.4.3 項の検証結果に基づいて実施する。

実運用も含めた負荷軽減効果の確認
SaaS 型でサービスを提供する主な利点は、利用者側のシステム利用に係る負担の軽減である。
提供者側インフラ環境に構築したソリューションを、複数の利用者が直接利用する形態を取ることで、これまで SI 型や DL 型では利用者側で実施する必要のあったシステム構築、特にサーバイ
ンフラや、ネットワーク設計、導入後の運用等に関する利用者側の対応負担軽減が期待される。
例えば、3.1 節で選定する「鉄道車両監視 AI システム」においては、DL 型で利用する場合は、現地設備（5G エリア、センシング機材、モニター等）に加え、利用者側でシステムを稼働する環境を整備してシステムをデプロイする必要がある。具体的には、専用のクラウド環境を設け、ダウンロードしたシステムを展開した上で、ネットワークの構築及び安定運用に向けた検証等が必要となる。利用者側がシステム構築に関する知識と経験がある場合は事業者の内製により対応可能であるが、そうでない場合は有スキル者の確保ならびに、場合によってはインフラ構築・運用のためのアウトソーシングが必要となり、利用者の負担（利用障壁）となりうる。
一方、本システムを SaaS 型で利用する場合は、利用者側は現地設備（5G 接続用回線、センシン
グ機材、モニタ等）のみ配備すればシステム利用可能となる。そのため、利用者側の負担が少な72

く、少稼働で廉価に、素早くシステムを利用することができる。
（図 3.1.3-1 参照）

システム構成要素
アプリ
ケーショ
ン

システム
基盤

コンテナ

DL型提供方式
事業者
提供

５GNW環境

事業者
提供

利用者構築
通信キャリア
構築・提供

通信キャリア
構築・提供

システム導入環境
カメラ機材類

利用者構築

特に求められるスキルレイヤ・作業•（汎用技術）

ミドル
ウェア

OS

SaaS型提供方式

利用者構築

ファシリティ

•必要な作業• システム要件定義、設計等求められるスキル• 上位レイヤ（NW・サーバ）IT専門ではない事業者には有スキル
者がおらず、対応が難しい

•
•

必要な作業
• 端末設置、接続等求められるスキル• 物理配置スキル

IT専門ではない方でも対応可能な領域が多い
一部専門性が必要な部分もマニュアルにより対応をフォローすることで実現出来る想定図 3.1.3-1 SaaS 型提供形態による利用者負担軽減イメージ

実際の負荷軽減効果については、過年度に行った結果等を参照としながら、導入負荷軽減効果を検証しつつ、前述の汎用化機能を含めた一連のシステム運用を鉄道事業者に体験頂くなど、より実態の沿った形での検証を行った。本結果は 3.4.4 項にまとめる。

将来的な 5G 技術を活用した場合の共用形態における論点
1.1 項で前述したとおり、5G ソリューションは、5G の特性（大容量、低遅延、多数同時接続）を活用されることを前提に構成されているため、従来よりもデータ通信量が多いことや、より低遅延でのデータ処理を求められる点、またデータを送信する端末数の多さなどの特徴をもつ。
クラウド環境上でこのような特徴をもつ 5G ソリューションを実行する場合には NW 接続形態の選択についてもシステム全体の性能要求を満足させるうえで検討が必要となる。
一般的に利用されるクラウド環境の NW 接続形態としてインターネットを介した接続形態があるが、これらのほかに、今後、本格的な導入が期待される 5GSA や MEC 技術を活用した接続形態についても机上検証を行うことで、5G の NW 品質向上や機能追加がより柔軟な NW 接続形態の構成につながるか、5G ソリューションの普及展開への寄与効果を確認する。本結果は、3.5 項にまとめる。

73

図 3.1.4-1 5GSA/MEC 技術の活用による共用形態での論点

分野横断的な 5G ソリューションの展開を見据えた共用形態の検証
1.1 項で前述したとおり、5G ソリューションの汎用化・共用化の実現前提として、特定分野における課題解決効果が確認されたユースケースが必要である。これらのユースケースの創出については、令和 2 年度から実施されているローカル 5G 開発実証の成果や、5G ソリューション開発
事業者などにおいて実証実験が行われ、各事業分野におけるソリューション事例開発が進められ、社会実装に向けた取り組みが検討されている。
これらのユースケースについては先進的な取り組みである側面が強いことや、導入を進めるた
めの初期開発コストの負担が大きいことで、条件が適う事業者のみでの広がりにとどまっている。
また、地域に根差す中小企業や地方自治体等の各産業分野の振興を担うステークホルダーでのソリューション導入は進んでいないという事業者間での導入に関する課題が生じている。
本実証においては、5G ソリューションの普及展開方策の波及範囲としてこれらの 5G ソリュー
ションの利用が、その導入障壁が高いことで敬遠されていた利用者層にも広がることで、5G ソ
リューションの社会普及につながっていくと考え検討を行った。
幅広い利用者層にソリューション提供を行い、より簡便・安価に利用を広めていくため、従来開発を行ったユースケースの部品化、汎用化を行うことにより、汎用的な課題解決を行うコア機
能を開発し、分野横断的にコア機能とそれらを効率的に横展開するための共同利用可能な機能を準備し、他分野においても同様の課題を抱える利用者に利用をしてもらう共同利用の形態をとることが、ソリューションの普及展開につながると考える。（図 3.1.5-1）
本実証においては、共用形態に関するソリューション面の検討のほか、共同利用を進めていく
ために必要となる提供・利用形態、運用面、提供に必要となる技術面での検討を行い、実現性の具体化に向けた確認を行う。本結果は、3.6 節にまとめる。

74

図 3.1.5-1 5G ソリューションの共用形態による分野横断的な展開方策イメージ

75

5G ソリューションの選定及び検証環境の構築
本節においては、主に前述の 3.1.1～3.1.3 の検証を行うために必要となる環境整備について述べる。

5G ソリューションの選定
検証する具体的な 5G ソリューションとしては、鉄道分野における「鉄道車両監視 AI システム」
を選定した。
「鉄道車両監視 AI システム」は、令和 2 年度 L5G 実証にて、鉄道事業者（京浜急行電鉄株式会社）が実際に抱える課題の解決をめざして開発を行ったソリューションの一部である。
本ソリューションは、令和 3 年度 5GSC 実証において、同様の課題を有する業界他社（鉄道事業分野）でのユースケースとして設定し、業界他社へ水平展開が可能であることが実証され、同一業界複数ユーザから実装化への期待やニーズが確認できている。
また、ソリューション共用形態毎（SI 型、DL 型、SaaS 型）での導入障壁の変化や実装効果の差
異の効果測定を行うにあたっては、本ソリューションは令和 2 年度 L5G 実証ではオンプレミス型（SI 型）、令和 3 年度 5GSC 実証では DL 型での実証を行っていることから、本年度 SaaS 型との比較に際し、効率的な検証を行うことが可能である。

検証する実環境の構築
SaaS 型における「鉄道車両監視 AI システム」は、各利用者環境から 5G ネットワークを介し、インターネット経由ならびに閉域網経由双方から接続可能な NTT ドコモのクラウドサービスである docomoMEC 基盤上（以下、docomoMEC という。
）に配置した。
また、SaaS 型でシステムを共用する場合、特に「遅延性」については重要な論点となると想定された。ソリューション提供上の End to End の遅延は様々な要素が複合的に影響するものであるが、本事業では特に接続方式の観点で、遅延低減が期待される技術を用いた場合での影響を検証する。その検証のために、5G ネットワークとクラウド基盤との接続方式について、複数の接続方式を準備し、接続方式が及ぼす遅延性などの影響も含めて確認を行った。
過年度実証との比較を行う上では、クラウドサービスそのものの差異や、同一サービスにおいてもリージョンの差異、実証時の通信環境の差異など、様々な変動要素があり、比較可能な環境の整備は困難である。そのため、今年度実証において、同一のクラウドサービスを利用し、複数の実環境から、前述した複数の接続方式を用いて接続し比較を行った。
5G ネットワークとクラウド基盤の接続にはインターネット経由によるパブリック接続方式（以下、インターネット接続方式）と、インターネットを介さず、キャリア網内で直接ソリューショ
ンクラウド基盤と閉域接続が可能な「MEC ダイレクト」サービスを用いた通信キャリア網内での閉域接続方式（以下、閉域接続方式）の環境を手配し、検証を行った。接続方式や提供形態について、下図に一覧としてまとめる。
76

図 3.2.2-1 クラウド環境との NW 接続形態図
表 3.2.2-1 クラウド環境との NW 接続形態一覧
接続形態

接続概要

SI 型

インターネット経由による事業者システム環境への接続

DL 型

インターネット経由による事業者 DL 型開発システム環境
への接続

SaaS 型（インターネット接

インターネット経由による SaaS 環境への接続

続方式）
SaaS 型（閉域接続方式）

通信キャリア網内経由による SaaS 環境への接続

本事業においては、令和 3 年度 5GSC 実証において、DL 型で実装された「鉄道車両監視 AI システム」の実証に関するご協力をいただいた西日本鉄道株式会社（以下、「西鉄」）、及び令和 3 年度
5GSC 実証において、鉄道協議会の参加事業者としてご協力いただいた京阪電気鉄道株式会社（以下、「京阪」）の鉄道事業者 2 社より実環境の提供を受け、docomoMEC 上に構築された鉄道車両監視
AI システムのユースケースの検証（5G ネットワークとクラウド基盤の接続方式）が SaaS 型で行える環境を構築した。
（図 3.2.2-2 参照）
77

図 3.2.2-2 SaaS 型の鉄道車両監視 AI システム構築イメージ（1） クラウド基盤における SaaS 環境の構築
前述の通り、本事業において、接続方式による特に「遅延性」に関する差異を確認するため、複数のネットワーク接続方式でクラウド基盤と接続を行う。接続方式は、遅延の低減効果が期待される方式である閉域接続方式と、一般的な方式であるインターネット接続方式の双方に対応した構成として比較検証を行う。
今回、それぞれの接続方式を実現できるクラウド基盤として「docomoMEC」を選定している。
同クラウド基盤において 仮想マシン、仮想ネットワークなどのコンピューティングリソースを提供している。また、NTT ドコモ網との直結及び全国に複数拠点配置により MEC（Multi-access
Edge Computing）の特徴を持つクラウドサービスでもある。（図 3.2.2-3～図 3.2.2-4 参照）

図 3.2.2-3 「MEC ダイレクト」サービス概要78

図 3.2.2-4 docomoMEC との NW 接続形態図

1） クラウド基盤設置拠点の選定
docomoMEC のクラウド基盤は以下種別にて、令和 4 年度時点において合計 11 拠点から選択可能であるため、サービス種別ならびに拠点の選別を行う必要がある。（図 3.2.2-5 参照）

図 3.2.2-5 docomoMEC 提供の各基盤の利用可能拠点
クラウド基盤の設置拠点の選別にあたり、本実証の閉域接続方式として利用する必要のある「MEC
ダイレクト」サービスに対応している点、過年度実証と仮想化基盤環境を同一とする観点で、OpenStack 基盤を活用した「Compute O」が利用可能である点、さらに、MEC サービスを利用する
うえでは低遅延性を重視した環境を選定する必要があるため、実証フィールドとクラウド基盤は
近接することが望ましい点も加味し、今年度の実証フィールドがそれぞれ西日本であることから、実証フィールドに近接する docomoMEC「Compute O」大阪環境を選択した。

792） マルチテナント構成の実装
今年度のシステム構成において「マルチテナント」と呼ばれる複数ユーザユーザのデータ格納
領域を定義して独立的に管理するコア機能として実装することとした。
マルチテナント管理機能は、「鉄道車両監視 AI システム」のみならず、分野横断的に多くのシステムで利用可能な汎用技術である。これにより、利用者は、他の利用者が同時に利用していることを意識すること無く、システムを共同利用することができることから SaaS 型でのシステム構成においては必須となる機能である。
令和 2 年度 L5G 実証における SI 型環境及び令和 3 年度 5GSC 実証における DL 型環境と今年度実証における SaaS 型環境とのマルチテナント管理機能に関する比較を図 3.2.2-6 に示す。

SI・DL型環境

SaaS側環境過去実証では単一ユーザ専用環境のため
ユーザ管理は実証スコープ外

ユーザのデータ・設定を管理し複数のユーザから利用可能とする必要がある

データ・設定管理
A社設定

処理機能

データ・設定管理
B社設定

処理機能

処理A
イ
ン
プ
ッ
ト

処理A

NW

X社設定

処理B

CPU

処理C

GPU

ア
ウ
ト
プ
ッ
ト

イ
ン
プ
ッ
ト

処理A

NW

HDD

処理B

処理C

処理B

処理C

処理A

処理B

処理C

CPU

GPU

HDD

ア
ウ
ト
プ
ッ
ト

共通のリソースで複数ユーザの処理を実施
負荷のかかるタイミングは不確定のため負荷発生時の影響を確認する必要がある

基本的には処理は直列、同一ユーザのため負荷のかかるタイミングはコントロール可能

図 3.2.2-6 SI 型環境・DL 型環境と SaaS 型環境の比較「鉄道車両監視 AI システム」でのマルチテナント管理機能の実証イメージを図 3.2.2-7 に示す。
AI 処理機能に関しては、複数ユーザでの並行処理を実装するために各事業者に対して AI 解析を行う際には共有 GPU リソースから処理リソースを割り当てることとした。
データ管理についてもユーザごとに作成された AI 学習モデルや解析データについては各社独立したモデル管理を行えるように保管場所を分割することとした。

80

図 3.2.2-7 SaaS 型「鉄道車両監視 AI システム」の全体イメージ（2） 鉄道事業者現地実証環境の構築
本事業において協力をいただいた西鉄、及び京阪の鉄道事業者 2 社より提供を受けた車両検査
基地において構築した実証環境について記載する。

1） 「西日本鉄道株式会社」
西鉄の筑紫車両基地において、可搬型キャリア 5G 基地局（以下、キャリー5G という。）を構築
し、SaaS 型で実装された「鉄道車両監視 AI システム」の検証を実施した。
キャリー5G とは、キャリア 5G のエリア化がされてない環境下において、一時的にキャリア 5G
エリアを構築、提供する NTT ドコモの通信サービスである。本サービスを用いることにより、常設のキャリア 5G 基地局を設置するよりも短納期で、かつピンポイントで希望する場所に一時的なキャリア 5G エリアを構築することが可能となる。
本実証では、キャリア 5G ネットワークを利用するが、実証環境として選定した西鉄の筑紫車両
基地の検車庫内（屋内）は、現状の 5G エリア構築状況では十分な受信環境を確保できない。そのため、本実証においてはキャリー5G を用いて実証期間中にキャリア 5G エリアを構築することとした。

a. 現地環境構築
西鉄筑紫車両基地（福岡県筑紫野市下見 673−3）内の検車庫で実証環境を構築した。14 番線中央部の南側にキャリー5G、及び実証機材を設置した。（図 3.2.2-8～図 3.2.2-12 参照）
81

図 3.2.2-8 西鉄筑紫車両基地での実証環境構築場所

図 3.2.2-9 筑紫車両基地内検査庫内の検証実施場所
82

図 3.2.2-10 筑紫車両基地内検査庫のキャリー5G 設置状況

図 3.2.2-11 筑紫車両基地内検査庫の機材配置状況83

図 3.2.2-12 筑紫車両基地内検査庫の車両への疑似き裂（クラックシール）貼付作業状況
西鉄の現地環境におけるシステム構成を図 3.2.2-13～図 3.2.2-14 に示す。

図 3.2.2-13 システム構成記載範囲
84

図 3.2.2-14 現地システム物理構成

85

b. 検査車両の手配
本実証では、西鉄が保有する 3000 系統の 3 両編成車両を使用し検証を実施した。
なお、検出対象物である、き裂、収容函ハンドル、ブレーキパッドの厚み、車軸温度においては検査車両に図 3.2.2-15～図 3.2.2-18 の通りダミーを用いて瑕疵を模擬した。

図 3.2.2-15 台車のき裂検出における擬似き裂シール添付場所(垂直・平行・斜め)

図 3.2.2-16 収容函ハンドルの開閉場所

86

図 3.2.2-17 新品ブレーキパッドへの交換箇所

図 3.2.2-18 車軸の温度異常検出用サーマルカイロ設置箇所

872） 「京阪電気鉄道株式会社」
京阪の寝屋川車両基地内において、キャリー5G を構築し、SaaS 型で実装された「鉄道車両監視
AI システム」の検証を実施した。本実証では、キャリア 5G ネットワークを利用するが、実証環境として選定した京阪の寝屋川車両基地の検車庫内(屋内)は、現状の 5G エリア構築状況では十分な受信環境を確保できない。そのため、本実証においてはキャリー5G を用いて実証期間中にキャリ
ア 5G エリアを構築することとした。

a. 現地環境構築
京阪の寝屋川車両基地（大阪府寝屋川市木田元宮 2-1-1）内検車庫で実証環境を構築した。検車庫内 4 番線中央部の東側にキャリー5G、及び実証機材を設置した。
（図 3.2.2-19～図 3.2.2-23 参照）

図 3.2.2-19 京阪寝屋川車両基地内検車庫での実証環境構築場所

88

図 3.2.2-20 寝屋川車両基地内検査庫のキャリー5G 状況
寝屋川車両基地内検車庫での実施場所の詳細イメージは以下のとおりである。なお、キャリー
5G 装置と、5G 受信端末やカメラ等の実証機材は数メートル以内に隣接して設置した。

図 3.2.2-21 寝屋川車両基地内検査庫内の検証実施場所
89

図 3.2.2-22 寝屋川車両基地内検車庫の実施場所詳細及び機材設置

図 3.2.2-23 寝屋川車両基地内検査庫の車両への疑似き裂（クラックシール）貼り付け作業状況

b. 現地システム構成
京阪での現地環境におけるシステム構成を図 3.2.2-24～図 3.2.2-25 に示す。

90

図 3.2.2-24 システム構成記載範囲

91

図 3.2.2-25 現地システム物理構成

c. 検査車両の手配
本実証では、京阪が保有する 10000 系統の 4 両編成車両を使用し検証を実施した。
なお、検出対象物である、き裂、収容函ハンドル、ブレーキパッドの厚み、車軸温度においては検査車両に図 3.2.2-26～図 3.2.2-29 の通りダミーを用いて瑕疵を模擬した。

図 3.2.2-26 台車のき裂検出における擬似き裂シール添付場所(垂直・平行・斜め)92

図 3.2.2-27 収容函ハンドルの開閉場所

図 3.2.2-28 新品ブレーキパッドへの交換箇所

93

図 3.2.2-29 車軸の温度異常検出用サーマルカイロ設置箇所

94

（3） 「鉄道車両監視 AI」システム機能・性能・要件
1） クラウド基盤
docomoMEC「Compute O」で提供される各インスタンスのリソース仕様を表 3.2.2-2 に示す。

表 3.2.2-2

docomoMEC「Compute O」提供インスタンスの仕様

2） ネットワーク構成・システム構成
docomoMEC 上には、図 3.2.2-30 及び表 3.2.2-3 に示す「鉄道車両監視 AI システム」を構成する各インスタンスを配置した。

95

図 3.2.2-30 SaaS 型「鉄道車両監視 AI システム」インスタンス配置図
各インスタンスでの機能要件を表 3.2.2-3 に示す。
表 3.2.2-3 インスタンス機能要件
項番
1

インスタンス名概要

WebRTCWebRTC を利用した映像配信用インスタンスを実装。
複数の実証フィールドからの映像データを受信し、各インスタン
スや監視端末へ映像の配信・録画を行う

2

Web サーバ

Web アプリケーションを実装。AI インスタンスで検出した異常検知情報を基にリアルタイム映像および、録画映像の監視 UI を提供する
映像配信アプリケーションを実装。録画映像と AI 解析結果の矩形位置情報を DB 化し、クライアントへ配信する

3

録画共有

WebRTC インスタンスで受信録画された映像を保存する機能を実装する

4

AI(車両解析)

AI 画像解析エンジンを実装した GPU インスタンス。
WebRTC インスタンスから受信した映像を基に AI 解析を行い、異常検知情報を出力する

5

AI(追加学習)AI 追加学習機能におけるアノテーション支援～学習モデル自動作成・適用機能を実装した GPU インスタンス
96

6

VPN

外部 Internet 環境から VPN 接続により内部インスタンス等を構築・開発するための VPN 接続機能を実装する

7

Proxy/NTP

クラウド基盤内部インスタンスから外部リポジトリなどへのパッチ更新などの管理通信を行う際に利用することを想定した
Proxy 機能を実装する
内部インスタンスの時刻同期を行うための NTP 機能を実装する

実証で使用するものとして選定した各種機器及びソフトウェア、そしてそれらの選定理由は表
3.2.2-4 に示すとおりである。
表 3.2.2-4 選定した使用する各種機器及びソフトウェア、それらの選定理由
機器等名選定した機材

選定理由・妥当性

車両検査用高精SONY ZV-1

・動画記録フォーマット細カメラ

XAVC[4K:30p(3,840x2,160/30p)]で撮影可能である。
・HDMI 端子、USB 端子でリアルタイム出力が可能である。

車両検査用サー

FLIR E53

マルカメラ

・-10℃～100℃の温度範囲を計測が可能である。
・USB 端子でリアルタイム出力が可能である。
・一般的なサーマルカメラは温度情報のみを出力する
ため、対象やその周辺の温度が同程度であった場合に物体の輪郭がぼやけ、対象物を確認することが困難になるが、選定機種はデジタルカメラを搭載し、熱画像と同じ画角の可視画像を同時に出力するため物体の輪郭を捕らえることが可能である。

映像配信用シンJetson・USB 端子で映像をリアルタイムに受信が可能であグルボードコン

Xavier NX

る。

ピュータ

・H.264 のエンコードに対応しており、NVIDIA Volta
GPU を実装している。
・株式会社時雨堂が提供する Apache License 2.0 のオープンソースソフトウェアとして登録されている「WebRTC Native Client Momo」を実装予定であり、動
作確認機種として本製品が公開されている。

5G 端末
（ルータ機
材）

SH-52A・アップロード時最大 480Mbps の機能を有している。
・有線 LAN(1000BASE-T)を有しておりシングルボード
コンピュータと LAN で接続が可能である。
・ダウンロード時最大 4.1Gbps の機能を有している。
97

・Wi-Fi 規格、IEEE802.11a,b,g,n,ac,ax に対応している。
5G 基地局

NTT ドコモ 5G

4.5GHz の周波数帯で通信するキャリア基地局である。

4.5GHz 基地局
クラウド基盤

NTT ドコモ・クラウド基盤として各システム機能が十分に挙動可

docomoMEC

能なリソースを提供可能なクラウドサービスである。
・GPU インスタンスが利用可能である。

映像受配信シス

時雨堂 WebRTC

・シングルボードコンピュータへ搭載予定の WebRTCテム

SFU Sora

Client Momo と互換性のあるソフトウェアであり AI 解析システムへ送信可能である。
・映像を WebRTC SFU サーバ経由で配信元に代わって配信が可能である。
・多地点からの要求に対し、WebRTC SFU サーバ経由で配信元に代わって配信が可能なシステム構成である。
・一般的な配信において高ビットレートでの配信時、映像の解像度が引き下げられてしまう場合があるが、株式会社時雨堂が提供する WebRTC SFU sora は、クライアントに対し上限値を引き上げるように通知することで解像度を担保した映像配信が可能である。

車両検査用映像・高精度映像・高精細映像を AI 解析し、異常箇所を特定した座標情AI 解析エンジン

異常検出エン

報をリアルタイムに出力することで検出座標データ配

ジン

信を行う。

・NVIDIA
QuadroP5000*8・TeslaV100*4
映像配信サーバ

Web サーバ・リアルタイム映像と AI 解析した結果の異常位置を示すバウンディングボックス等を合成可能な状態でクライアントに配信することで、低遅延で配信可能である。
また、AI 解析した結果の異常位置を示すバウンディン
グボックス等のデータは、映像配信サーバに MQTT ブ
ローカーを配置してクライアントに配信することで、高頻度で配信可能である。
・映像配信サーバに録画映像のデータベース及び Web
98サーバを配置し、Web サーバから AI 解析結果をファイル形式で配信することで映像配信可能である。
アノテーション

Web サーバ

・ブラウザ上で使用可能な WebUI（アノテーション支

支援機能・NVIDIA援ツール）が提供可能である。

Quadro P5000*8

・アノテーション支援ツールで取り扱うデータの内、・Tesla

ユーザ固有データについては、特定キーに基づき分割

V100*4

管理が可能である。
・アノテーション支援ツールで閲覧/編集可能なデータ
は、ログインユーザ単位で制御可能である。

アノテーション

Web サーバ

・複数ユーザ同時利用時でのアノテーション（教師

支援機能処理・NVIDIA

データ作成）及び AI モデル構築/反映処理が可能であサーバ

Quadro P5000*8

る。

・Tesla・AI モデル反映については、本ツールで構築した AI

V100*4モデルを車両検査用映像 AI 解析エンジンに反映可能である。

AI 解析結果表示

・ノート PC・chrome ブラウザが動作可能な PC であり、httpPC 等

・タブレット

アクセスにより Web サーバへ接続することで配信要求と解析結果の表示が可能である。
・高性能グラフィックボードを搭載しており 4K・30 フ
レームが再生可能である。
・有線 LAN を有しており、ルータ機材と LAN で接続可能である。

3） 鉄道車両監視 AI システム
SaaS 型で提供される 5G ソリューションにおいても、要求される低遅延性は様々であるものの、ミッションクリティカルなシステムで超低遅延性が必要な業務への適用も視野に入れた検証を実施する。そうすることにより、5G ソリューションの横展開をする場合の差別化ポイントにもつながる。
本事業で検証する「鉄道車両監視 AI システム」は、インフラである「5GNW 環境」、「クラウド基盤」や映像を伝送するための「映像配信システム」、AI 処理に関する「AI 解析エンジン」、「解析結果表示用 Web アプリケーション」で構成されている。また、今年度は SaaS 型でのサービス提供を実現するために、AI 処理に関する「追加学習機能（教師データ作成～学習モデル作成・適用の自動化）」、「マルチテナント管理機能（複数事業者対応の Web アプリケーション/DB のユーザ
テナントの分割管理）」の追加検討、開発を行った。
以下に、主要な機能の概要を記載する。

99

a. 映像配信システム
本実証において、実証フィールドである京阪の検車庫及び、西鉄の車両基地内の車両台車を撮影し、映像をクラウド基盤へ送信するために図 3.2.2-31 に示す構成で機材を設置する。

図 3.2.2-31 映像配信システム機能イメージ
4K カメラとサーマルカメラで車両台車を撮影し、映像データを、5GUE を用いて 5G ネットワー
クで、クラウド基盤の WebRTC インスタンスに送信する。その際、シングルボードコンピュータ上に配置する WebRTC クライアントにて映像フレームにタイムスタンプを付加してデータ送信を行う。
WebRTC インスタンスは、現地からの映像を受信し、同じく現地の（映像閲覧用）PC 閲覧要求を受けた際、ブラウザ UI を通してストリーミング映像を配信する。

b. AI 解析エンジン機能
WebRTC インスタンスから取得する現地の撮影映像に対し、AI インスタンス内の AI 解析
エンジンにより AI 解析を行う。4K カメラ映像の解析により、台車異常（き裂、収容函ハンドルの開閉、ブレーキバッドの摩耗）を検出し、検出物の座標情報を Web サーバインスタンスに送信する。サーマルカメラ映像解析では、車軸の温度異常（閾値を超過する温度上昇）を検出し、同様に Web サーバインスタンスへ送信する。（図 3.2.2-32 参照）

100

図 3.2.2-32 AI 解析エンジン機能イメージ

c. 解析結果表示用 Web アプリケーション
WebRTC インスタンスから配信されるストリーミング映像や、録画映像をブラウザ上で閲覧でき
る WebUI を提供する。Web サーバインスタンスで稼働するアプリケーションにより実現する。
生映像の他、AI 解析結果付きの映像（AI 解析エンジンのアウトプット情報より、検知対象に対して矩形を重畳させた映像）も閲覧可能とする。
また、本 UI へのアクセス・ログイン時には、アカウント/パスワード認証を実装する。マルチ
テナント構成に則し、WebUI に表示する映像（ストリーミング映像、録画映像、AI 解析結果付き映像）はログインユーザ自身に紐づくものに制御する。各映像データや AI 解析結果データなどはDB 上ユーザ単位となるよう特定のキーで分割管理する。（図 3.2.2-33 参照）

101

図 3.2.2-33 解析結果表示用 Web アプリケーション機能イメージ

図 3.2.2-34 解析結果表示用 Web アプリケーション ログイン画面

d. 追加学習機能
アノテーションとは、AI に学習させたいデータに対して意味付け（タグ付け）を行う作業のことを指す。
「鉄道車両監視 AI システム」において、カメラ映像（静止画の連続）を AI 解析し検知する対象の一つに「き裂（クラック）」があるが、AI がクラックを検知できるように学習させるた
めには、AI に対して「何がき裂（クラック）なのか」と教えるための「教師データ」が必要となる。
102

その教師データを作成することが「アノテーション」であり、本システムのような画像解析 AI
モデルの構築において不可欠なプロセスである。（図 3.2.2-36 参照）

図 3.2.2-35 AI 追加学習機能（教師データ作成～学習モデル作成・適用の自動化）

図 3.2.2-36 アノテーション作業イメージ
前述のアノテーションに関する一連のプロセスを、鉄道事業者をはじめとした事業会社でも簡素に行えるようにするための支援機能として、以下 3 つの主要機能を具備するツール「アノテーション支援ツール」（Web アプリケーション）を WebUI で提供する。（図 3.2.2-37 参照）⚫

教師データ作成（アノテーション）⚫

AI モデル構築⚫

AI エンジンにモデルを反映

103

図 3.2.2-37 AI 追加学習機能イメージ
以下に、それぞれの機能の概要や画面イメージ等を詳述する。
⚫

教師データ作成（アノテーション）

ユーザは、データセット（画像データ群）を登録し、データセットの各画像に対してアノテー
ション作業を実施する。アノテーション作業の生成物が「教師データ」を呼ばれるデータであり、本データをもとに AI モデルを構築する。
本機能の係るアノテーション支援ツールの UI イメージを図 3.2.2-38 に示す。

図 3.2.2-38 アノテーション支援・自動 AI モデル構築/反映機能イメージ⚫

AI モデル構築

アノテーションで作成する教師データセットの一覧から、モデル学習に用いるデータセットを選択し、学習を実行するとモデルが構築される。構築されたモデルに対して、モデル性能評価指104

標や、画像予測結果を参照できる機能も具備しているため構築したモデル性能を、AI エンジン反映前に確認することが出来る。
本機能に係るアノテーション支援ツールの UI イメージを図 3.2.2-39 に示す。
【AI モデル構築/モデル構築】【AI モデル構築/モデル評価】【AI モデル構築/画像予測結果】

図 3.2.2-39 アノテーション支援ツールにおける AI モデル構築の UI イメージ105⚫

AI エンジンにモデルを反映構築するモデルを AI インスタンス上の AI エンジンに反映する。
本機能に係るアノテーション支援ツールの UI イメージを図 3.2.2-40 に示す。

図 3.2.2-40 アノテーション支援ツールにおける AI エンジンへのモデル反映の UI イメージ

e. マルチテナント管理機能
マルチテナント管理機能として実装した複数事業者対応の Web アプリケーション/DB のユーザ
テナントの分割管理化についての機能概要を記載する。
【リアルタイム映像配信（車両映像）】
カメラマスタ領域より、会社コードをもとにユーザに紐づくカメラ ID を取得する。
取得したカメラ ID をもとに、ユーザに紐づく車両監視リアルタイム映像を取得し、表示する。

映像閲覧アプリケーション

Webサーバーインスタンス

DB（Webサーバインスタンス内）

会社コード
会社コード
会社コード：00000001
ユーザに紐づくカメラIDA
車両監視映像

カメラ映像A(カメラID：A001)
カメラ映像C(カメラID：B001)
カメラ映像A(カメラID：A001)
カメラ映像B(カメラID：A002)
カメラマスタ

会社コード
会社コード：00000002

会社コード

ユーザに紐づくカメラIDB

車両監視映像
カメラ映像B(カメラID：A002)
カメラ映像D(カメラID：B002)

カメラ映像C(カメラID：B001)
カメラ映像D(カメラID：B002)

106

会社コード
00000001
00000001
00000002
00000002
00000003
00000003

カメラID
A001
B001
A002
B002
A003
B003

図 3.2.2-41 ユーザ切り替え機能_リアルタイム映像(車両監視)イメージ【リアルタイム映像配信（矩形情報）】
カメラマスタ領域より、会社コードをもとにユーザに紐づくカメラ ID を取得する。
取得したカメラ ID をもとに、ユーザに紐づく車両監視の矩形データを取得し、リアルタイム映像と合成する。
映像閲覧アプリケーション

Webサーバーインスタンス

DB（Webサーバインスタンス内）

会社コード
会社コード
会社コード：00000001
ユーザに紐づくカメラID

カメラID

A

矩形A
矩形B

カメラマスタ

矩形A
矩形B

会社コード
会社コード：00000002

会社コード
物体検出情報ユーザに紐づくカメラID

会社コード00000001
00000001
00000002
00000002
00000003
00000003

カメラID
A001
B001
A002
B002
A003
B003

異常検知ID

カメラID
A001
B001
A002
B002
A003
B003

AAA
AAB
BBA
BBB
CCA
CCB

B
カメラID

異常検知ID

矩形C
矩形D

AAA
AAB
BBA
BBB
CCA
CCB

矩形C
矩形D

異常検知情報

矩形情報
矩形A
矩形B
矩形C
矩形D
矩形E
矩形F

図 3.2.2-42 ユーザ切り替え機能__矩形データ、ポリゴン(車両監視)イメージ【録画映像配信時】
カメラマスタ領域より、会社コードをもとにユーザに紐づくカメラ ID を取得する。
取得したカメラ ID をもとに、ユーザに紐づく車両監視の録画映像を取得し、表示する。
矩形データの情報に関してはリアルタイム映像同様にカメラ ID、録画映像開始時刻を元に取得し、表示する。

107映像閲覧アプリケーション

Webサーバーインスタンス

DB（Webサーバインスタンス内）

会社コード、通知録画映像開始時刻
会社コード
会社コード：00000001
ユーザに紐づくカメラID

カメラID

A

矩形A
矩形B
録画情報ディレクトリ

録画映像A/矩形A
録画映像B/矩形B(Tomca tの/us r/tomcat8/webapps/VideoVi ewingApplication/stream
下の「カメラID_通知録画映像開始時刻」)

カメラマスタインデッ クスファイ
ル

セグメント
ファイル

物体検出情報会社コード、通知録画映像開始時刻
会社コード：00000002

会社コード

ユーザに紐づくカメラID

B

異常検知情報

カメラID

会社コード
00000001
00000001
00000002
00000002
00000003
00000003

カメラID
A001
B001
A002
B002
A003
B003

異常検知ID カメラID
AAA
A001
AAB
B001
BBA
A002
BBB
B002
CCA
A003
CCB
B003
異常検知ID 矩形情報
AAA
矩形A
AAB
矩形B
BBA
矩形C
BBB
矩形D
CCA
矩形E
CCB
矩形F

矩形C
矩形D
録画情報ディレクトリ

録画映像C/矩形C
録画映像D/矩形D(Tomca tの/us r/tomcat8/webapps/VideoVi ewingApplication/stream
下の「カメラID_通知録画映像開始時刻」)

インデッ クスファイ
ル

セグメント
ファイル

図 3.2.2-43 ユーザ切り替え機能_録画映像(車両監視)イメージ

4） セキュリティ要件
実証システムのセキュリティ要件を表 3.2.2-5 に示す。

表 3.2.2-5 セキュリティ要件
項番
1

項目

要件

ユーザ認証

Web アプリケーションへのアクセス時にはユーザ認証を行い特定ユーザのみログイン可能な状態とする。

2

通信暗号化

Web アプリケーションへのアクセス時には通信経路を SSL/TLS による暗号化を行い秘匿する。

3

境界防御

クラウド基盤と外部環境との境界にはアクセス制限を行い、実証
関連ユーザ以外のアクセスを制限する。

4

機密情報の保管クラウド基盤上には個人情報を含む機密情報を保管しないこと。

108

5） 商用 5G ネットワーク
本実証において使用する商用 5G ネットワークは、制御信号に LTE を利用するノンスタンドアロ
ン方式である。(図 3.2.2-44 参照)
5G の無線アクセスネットワーク(RAN:radio Access NW)を収容するコアネットワークは、交換機、加入者情報管理装置などで構成されるネットワークであり、端末は無線アクセスネットワー
クを経由してコアネットワークとの通信を行う。
インターフェースとして、eUTRAN(LTE/LTE-Advanced の RAN)を収容する既存コアネットワーク
である EPC(Evolved Packet Core)、及び RAN-コアネットワーク間のインターフェースとして、
eUTRAN-EPC 間は S1 インターフェースを流用する構成となる。EPC では、ユーザユーザの認証、ユーザデータパケットの転送経路の設定、QoS 制御、移動制御などの機能を提供している。呼制御方式としては、常時接続である「Always-ON」コンセプトを採用し、移動端末の電源 ON と同時にIP アドレスが割り振られ、固定網と同様に通信が可能となる。

図 3.2.2-44 5G NSA 構成のイメージ（4） 無線局の免許等
本事業において実証に協力いただく鉄道事業者 2 社（西鉄、京阪）から提供されるフィールド
環境にキャリー5G を用いてエリア化した。
NTT ドコモのキャリア 5G 基地局（4.5GHz）を 九州（西鉄）、関西（京阪）それぞれのエリアで構築した。各基地局の免許申請情報は表 3.2.2-6～表 3.2.2-7 に示すとおりである（出所：総務省
電波利用ホームページ）。
109なお、次年度以降の継続的なソリューション実装に向けての 5G 基地局の設置については、利用者における接続形態の検討もおこなった上で置局要否を判断していくこととする。

表 3.2.2-6 九州（西鉄）エリアで構築する基地局の免許申請情報

表 3.2.2-7 関西（京阪）エリアで構築する基地局の免許申請情報

110（5） その他の要件
1） 国際規格等への対応
実証環境の構築にあたっては、今後の ICT の技術的発展を柔軟に取り込めるよう、国際規格やオープンな技術に依拠し、普及段階において機能拡張が可能な設計とした。
5G 基地局については、3GPP で策定作業が進められている 5G 無線アクセスの仕様の最新の標準化状況を踏まえた無線インターフェースを用いた（キャリア準拠）。

2） サプライチェーンリスク対策
本実証にて用いるキャリア 5G 設備は、特定高度情報通信技術活用システムの開発供給及び導入の促進に関する法律（令和 2 年法律第 37 号）に基づく開発供給計画認定に係る設備である。（表3.2.2-8 参照）

表 3.2.2-8 認定開発供給計画（全国 5G）
事業者名

1 日本電気株式会社

2 富士通株式会社

認定省庁

総務省
経済産業省

総務省
経済産業省

開発供給計画認定番号

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

2020 開 1 総経第 0001 号－1

令和 2 年 11 月 13 日認定2020 開 1 総経第 0002 号－1

令和 2 年 11 月 13 日認定

111

5G ソリューションに係る検証
本節では、3.1.1 項にて述べた事項を確認するため、3.2 節にて構築した環境を用いた実証を行った結果について取りまとめる。

SaaS 型での活用を想定した 5G ソリューションの検証
過年度に SI 型ならびに DL 型での検証が実施されている「鉄道車両監視 AI システム」を、SaaS型で提供可能かどうかを確認するため、SaaS 型の一般的な方式としてインターネット接続方式にてシステム動作検証を行った。具体的に本項では通信性能（クラウド接続時の通信）とシステム
性能（ソリューション構成機能）を評価した。

（1） SaaS 型におけるシステム動作検証
1） SaaS 型で構成されたシステムにおけるネットワーク性能確認
本検証の目的は、今回選定した 5G ソリューションを SaaS 型として提供するための影響、課題をネットワーク観点で確認することである。現地環境-クラウド間のネットワーク環境が正常に動作するかの確認を行い、設計・構築したアーキテクチャが SaaS 型システムとして動作上問題が生じないことを確認する。
検証の評価項目として、DL 型での検証時に実施した評価項目を踏襲し、以下を測定した。（表3.3.1-1 参照）
表 3.3.1-1 SaaS 型で構成されたシステムにおけるネットワーク性能検証内容
評価項目

測定項目

上りスループット TCP/UDP

bandwidth、jitter、lost/total パケット数※3 回の計測値、またその平均を用いる

下りスループット TCP/UDP

bandwidth、jitter、lost/total パケット数※3 回の計測値、またその平均を用いる

応答時間（RTT）

min/avg/max/stddev※3 回の計測値、またその平均を用いる

パラメータについては、以下の通り。


試験方法：iperf / ping



試験区分

：UL（上り） / DL（下り）

パケットサイズ（byte）



スループット（Mbps） ：なし / 30 / 100

送信時間（sec）

：1300
：60
112

上記のパラメータをもとに、現地から 5G ネットワークを経由したクラウド基盤までの接続区間においてネットワーク性能を測定した。
（図 3.3.1-1 参照）

図 3.3.1-1 SaaS 型で構成されたシステムにおけるネットワーク性能検証イメージ【検証結果】
本検証の結果を表 3.3.1-2 に示す。
表 3.3.1-2 SaaS 型で構成されたシステムにおけるネットワーク性能検証結果

測定区間

試験

パケット 送信時間 スループット
サイズ
(sec)
(Mbps)

上り

1300

60

-

21.07

‐

‐

‐

‐

‐

‐

下り

1300

60

-

58.00

‐

‐

‐

‐

‐

‐

上り

1300

60

30

29.44

1.27

0.04

‐

‐

‐

‐

下り

1300

60

30

29.97

0.11

0.00

‐

‐

‐

‐

UDP_100M 上り

1300

60

100

23.96

1.65

0.77

‐

‐

‐

‐

下り

1300

60

100

‐

‐

-

0.23
‐

‐

60

0.40
‐

‐

1300

76.67
‐

上り

1300

60

-

24.93

‐

‐

54.03
‐

72.34
‐

263.81
‐

28.34
‐

下り

1300

60

-

21.57

‐

‐

‐

‐

‐

‐

上り

1300

60

30

29.95

2.14

0.00

‐

‐

‐

‐

下り

1300

60

30

29.96

0.08

0.00

‐

‐

‐

‐

UDP_100M 上り

1300

60

100

36.93

0.96

0.63

‐

‐

‐

‐

下り

1300

60

100

‐

‐

-

0.18
‐

‐

60

0.11
‐

‐

1300

81.72
‐

上り

1300

60

-

13.86

‐

‐

52.67
‐

75.00
‐

435.67
‐

‐

下り

1300

60

-

42.28

‐

‐

‐

‐

‐

‐

上り

1300

60

30

28.27

1.81

0.06

‐

‐

‐

‐

下り

1300

60

30

25.31

0.26

0.16

‐

‐

‐

‐

UDP_100M 上り

1300

60

100

37.43

0.60

0.62

‐

‐

‐

‐

下り

1300

60

100

‐

‐

-

0.21
‐

‐

60

0.11
‐

‐

1300

78.63
‐

54.33

71.67

114.33-

iperf TCP
①4K Jetson（Ubuntu）

UDP_30M－WebRTCインスタンス間

ping ICMP
iperf TCP

②監視用GPUPC（Windows）－WebRTCインスタンス間

UDP_30M

ping ICMP
iperf TCP

③監視用GPUPC（Windows）－Webインスタンス間

応答時間の最応答時間の最 応答時間の標
bandwidthjitterlost/total
応答時間の平小値（ms）
大値（ms）
準偏差値(Mbps)(ms)
パケット数
均値（ms）(3回平均値)(3回平均値)（ms）(3回平均値) (3回平均値) (3回平均値)(3回平均値)(3回平均値)

試験区分

プロトコル

UDP_30M

ping ICMP

本結果より現地環境-クラウド基盤間のネットワーク性能の影響観点について、過年度検証済みのソリューションを SaaS 型アーキテクチャに変更をしても問題なく動作可能であることを確認113できた。今年度実証システムにおいては、ネットワーク性能のうち、スループットの観点として
5G を用いることで、高精細映像の伝送を行うために必要となる上りスループット（1 拠点あたり
上り 30Mbps 程度）が確保できていることを性能指標としたが、NW 帯域について、UDP プロトコル
30Mbps でのスループット測定時において現地環境からクラウド基盤間では 30Mbps 程度の帯域を確保できていることが確認できた。
応答時間の観点としては、ICMP による遅延測定結果から平均遅延時間についてはアーキテク
チャ変更による影響はみられず、問題なくシステム動作可能であることを確認出来た。

2） SaaS 型で構成されたシステムにおける映像伝送性能検証
本検証の目的は、今回選定した 5G ソリューションを SaaS 型として提供可能かを End-to-End の
映像伝送の観点で問題ないことを確認することである。映像遅延量及び映像伝送時に経由する各
コンピュータのリソース情報を測定し、SaaS 型として設計・構築したことに伴う、映像伝送品質の低下などのデメリットが特段ないことを確認する。
検証における評価項目としては、令和 3 年度 5GSC 実証システム(DL 型)に対して実施した評価
項目を踏襲し、以下を測定した。
（表 3.3.1-3 参照）
表 3.3.1-3 SaaS 型で構成されたシステムにおける映像伝送性能検証内容
評価項目

測定項目

映像遅延時間タイマーによる差分時間※3 回の計測値、またその平均を用いる

映像伝送品質情報

解像度、再生中フレーム数、受信フレーム数、デコー
ドフレーム数、ドロップフレーム数※3 回の計測値、またその平均を用いる

コンピュータリソース

CPU、MEM、GPU のリソース量の推移

対象コンピュータ：※3 回の計測値、またその平均を用いる

・試験端末
・各インスタンス

パラメータについては、下記の通り。


測定種別



スループット（Mbps）:15（4K カメラ） / 2.5（サーマルカメラ）：4K カメラ / サーマルカメラ

上記のパラメータをもとに、5G ネットワークとクラウド基盤の接続においてインターネット接続方式（キャリア 5G）を用いて、各試験結果の平均値を測定した。（図 3.3.1-2 参照）

114

図 3.3.1-2 SaaS 型で構成されたシステムにおける映像伝送性能検証イメージ【検証結果】
本検証の結果を表 3.3.1-4 に示す。
表 3.3.1-4 SaaS 型で構成されたシステムにおける映像伝送検証結果（インターネット接続方式）
各インスタンスのリソース情報

Jetson
試験区
タイマー
分
スループッ
遅延時
(コーデッ ト間
ク)
(Mbps) 試験回数 (ｍs)

測定種別
4Kカメラ

H.264
H.264
H.264

15
15
15

サーマルカメラ

H.264
H.264
H.264

2.5
2.5
2.5

1
3046
2
2000
3
2088
※avg 2378.0
1-2-3-※avg --

CPU%
29.5
26.3
26.3
27.4
16.8
18.5
24.0
19.8

MEM%
34%
34%
34%
34%
29%
29%
29%
29%

WebRTCインスタンス

GPU%
0.0
0.0
0.0
0.0
3.0
0.0
9.0
4.0

CPU%

MEM%
2.4
2.6
2.3
2.4
0.0
0.0
0.0
0.0

GPUPC

CPU%
3.1
3.1
3.1
3.1
3.0
3.0
3.0
3.0

5.0
7.0
6.0
6.0
3.0
3.0
3.0
3.0

MEM% GPU%
33.0
33.0
33.0
33.0
28.0
28.0
28.0
28.0

解像度(px)41.0 3840x2160
41.0 3840x2160
41.0 3840x2160
41.0 -2.0 320x240
3.0 320x240
3.0 320x240
2.7 --

受信フ デコードフ
ドロップフレーム
レーム数 レーム数
数(fps)
(fps)
(fps)
29.6
30.2
30.2
30.0
22.7
23.1
23.1
23.0

1262.01352.01472.01362.02235.02421.02632.02429.3

0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0

本結果より、過年度検証済みのソリューションを SaaS 型アーキテクチャへの変更による Endto-End の映像伝送の性能の観点でも問題ないことを確認出来た。
映像フレームの劣化も見られず、
End-to-End の映像伝送品質に影響を及ぼすことはなかった。これにより、令和 3 年度 5GSC 実証
システム(DL 型)を SaaS 型構成として設計・構築したことに伴う、映像伝送品質の低下などのリ
ソース観点での影響が特段ないことが確認できた。
なお、End-to-End の映像伝送の観点で影響を及ぼす機器類のリソース使用状況についても、測定が可能なポイントでモニタリングを行った。表中に記載の通り、メモリや CPU 使用率は上限値から比較的余裕のある状態で測定が行えていることが確認できており、ネットワークリソース並
びにコンピューティングリソースが最大限活用できた測定結果であることもここに補足する。

3） SaaS 型で構成されたシステムにおける映像視認性検証
本検証の目的は、今回選定した 5G ソリューションを SaaS 型として提供可能かをユーザイン
ターフェースの観点で問題ないことを確認することである。SaaS 型システムの、映像コンテンツ115閲覧におけるユーザインターフェース（以下、WebUI という。
）の挙動及び視認性が、DL 型と比較し同等であることを確認し、SaaS 型として設計・構築したことに伴う、WebUI 上の挙動や映像視認性に関するデメリットが特段ないことを確認する。
検証の評価項目としては、令和 3 年度 5GSC 実証システム(DL 型)に対して実施した評価項目を踏襲し、以下を測定した。
（表 3.3.1-5 参照）
表 3.3.1-5 SaaS 型で構成されたシステムにおける映像映像視認性検証内容
評価項目

測定項目

4K30 フレーム映像が正常表示されているか

以下の場合における解像度、フレームレート（chrome
デバッグ）
・WebUI（chrome ブラウザ）上でストリーミング配信
される映像品質・WebUI（chrome ブラウザ）上で再生される録画映像
品質

ストリーミング映像の描画＜ストリーミング映像＞

録画映像の描画・WebUI 上で該当リンクをクリックした時に、ストリーミング映像が再生されること（目視確認）
・WebUI 上で該当リンクをクリックしてから、ストリーミング映像が再生開始されるまでの時間（タイマー計測）＜録画映像＞・WebUI 上で対象リンクをクリックした時に、録画映像が再生される。画面に映った時計の日時が対象
リンクの日時と合っていること（目視確認）
・WebUI 上で対象リンクをクリックしてから、録画映像が再生開始されるまでの時間（タイマー計測）

映像に重畳する AI 解析結果（バウンディン＜ストリーミング映像/録画映像＞

グボックス）の位置

・意図的に異常状態を作り適切な場所にバウンディ
ングボックスが表示されること・WebUI 上で再生される２つの映像(元映像・AI 検出映像)が、同じ時間軸で再生されていること（目視確認）シークバーによる再生位置指定の挙動

WebUI 上で再生される録画映像がシークバーによって任意の再生位置を指定できること

映像種別ごとの画面レイアウト切り替え時

・任意で選択した映像種別のレイアウトが切り替わ間ること（目視確認）

116

・任意で映像種別を選択した際に、レイアウトが切
り替わりきるまでの時間（タイマー計測）

上記表に記載の通り、特定の画面操作を行い、評価を実施した。
（図 3.3.1-3）

図 3.3.1-3 SaaS 型で構成されたシステムにおける映像視認性検証イメージ
本検証の結果を表 3.3.1-6 に示す。

表 3.3.1-6 SaaS 型で構成されたシステムにおける視認性検証結果【4K30 フレーム映像が正常表示されているか】
測定区間

映像種別

4Kカメラ
映像配信規格

確認方法

経過時間

解像度
(px)

PC ‐ WebRTCインスタンス

ストリーミング配信映像

4K30fps

chromeデバッグ

1分後

3840x2140

25

5分後

3840x2140

25

10分後

3840x2140

25-

3840x2140

25

PC ‐ Webインスタンス

録画映像

4K30fps

フレーム数【ストリーミング配信の描画/録画映像の描画】
該当映像が再生される(○/×)

再生が開始されるまでの
時間(s)

対象UI

確認端末

確認方法

ストリーミング配信

閲覧PC

該当リンククリック

○

3.3

録画配信

閲覧PC

該当リンククリック○

3.4【映像に重畳する AI 解析結果（バウンディングボックス）の位置】
異常個所数(1画像当たり)

バウンディングボックスが適切な位置に表示される(○/×)

対象UI

確認端末

確認方法

ストリーミング配信

閲覧PC

意図的に異常状態を作 1か所
り、適切な位置にバウン
2か所
ディングボックスが表示さ3か所
れるか目視で確認△(4K)、〇(サーマル,FHD)

1か所△(4K)、〇(サーマル,FHD)

2か所△(4K)、〇(サーマル,FHD)

3か所△(4K)、〇(サーマル,FHD)

録画配信

閲覧PC

117

△(4K)、〇(サーマル,FHD)△(4K)、〇(サーマル,FHD)【シークバーによる再生位置指定の挙動】
対象UI

確認端末

確認方法

録画配信

閲覧PC

シークバーを任意の場所へ移動したとき、生映像と矩形付き映像が同じ
時間軸で再生されることを確認

時間軸の同期がとれている(○/×)○【映像種別ごとの画面レイアウト切り替え時間】
クリック対象の映像種別

該当の映像種別が正常に切り替わる(○/×)

映像が切り替わるまでの
時間(s)

対象UI

確認端末

確認方法

ストリーミング配信

閲覧PC

該当の映像種別をクリッ 生映像
クしレイアウトが切り替わる(フェードアウトする)こと 解析結果付き映像
を確認
サーマル映像

0.1

○

0.1

○

0.1

○

該当の映像種別をクリッ 生映像
クしレイアウトが切り替わる(フェードアウトする)こと 解析結果付き映像
を確認
サーマル映像

0.1

○

0.1

○

0.1

○

録画配信

閲覧PC

本検証により、過年度検証した DL 型と過不足のない WebUI 動作を示していることが確認できた。これによって、実証システムを、SaaS 型として設計・構築したことに伴う、WebUI 上の挙動や映像視認性に関するデメリットが特段ないことを確認でき、SaaS 型としてアーキテクチャを変更した結果、ユーザインターフェースの観点でも問題ないことが確認できた。
なお、4K 映像を用いた場合の評価が「△」である点を補足する。4K 解像度の場合、UI 表示上、映像と矩形表示に一定のズレが発生していたが、これは過年度実証システムにおいても発生していた事象である。また、配信映像の解像度を 4K から FHD に変更することで UI 表示も改善出来ることが判明している既知の事象であった。あくまでも UI 表示上の影響であり、内部的な AI 検知
性能自体には影響があるものではなかったが、実証見学時等快適な閲覧環境が必要な場面において、一時的に解像度の変更の運用対処を行った旨を補足する。

（2） DL 型形態と SaaS 型形態における AI エンジン性能検証
1） DL 型で構成されたシステムにおける AI エンジンと SaaS 型で構成されたシステムにおける AI エンジンの検知性能検証
本検証の目的は、今回選定した 5G ソリューションを SaaS 型として提供した場合の AI 検知性能への影響を確認することである。
DL 型と SaaS 型での比較を行い、SaaS 型の提供形態が AI ソリューション提供時にも問題ないことを確認した。
検証の評価項目として、DL 型、SaaS 型それぞれにて、一定の処理リソースを割り当てた環境における AI の検知性能（検出率・網羅率）を計測した。これにより、各構成における AI エンジン
118

の性能を確認することができる。以下に検出率・網羅率について、詳述する。
⚫

検出率：

１回の試行あたりにシステムが出した結果を積み上げ、「システムが検出したもののうち、真に正しい結果の割合」を評価する。
⚫

網羅率：

１回の試行あたりにシステムが出した結果を積み上げ、「システムが検出すべきと定めた事物のうち、それを少なくとも 1 回、システムが検出した割合」を評価する。
検知対象ごとのパラメータについては、下記のとおりである。


クラック：



収容函のハンドル開閉：角度（正常/異常）

ブレーキパッドの厚さ：（すり減り度合いを計測し、異常値を検出）



車軸の温度異常：（一部の車軸温度を上昇させ、異常値を検出）

方向（タテ・ヨコ）幅（0.1 / 0.2 / 1.0 / 2.0mm）長さ（20 / 60 / 80cm）

鉄道車両の走行速度（5km/h , 10km/h）に応じて、上記のパラメータを網羅した映像を取得
し、その映像を、実験環境にデプロイされた DL 型 / SaaS 型の各構成の AI エンジンを用いて解析することで、それぞれの環境で動作する AI 検知性能に有意な差がないことが確認した。（図3.3.1-4～図 3.3.1-10 参照）
き裂発生位置

溶接端に生じたき裂(並行き裂：P)

き裂発生位置

溶接端に生じたき裂(垂直き裂：V)

き裂長(mm)

き裂幅(mm)

き裂長(mm)

20

60

80

0.1

P-0.1-20

P-0.1-60

P-0.1-800.2

P-0.2-20

P-0.2-60

P-0.2-80

1.0

P-1.0-20

P-1.0-60

P-1.0-802.0

P-2.0-20

P-2.0-60

P-2.0-80

き裂発生位置

き裂幅
(mm)

20

60

80

0.1

Ⅴ‐0.1‐20

V-0.1-60

V-0.1-800.2

V-0.2-20

V-0.2-60

V-0.2-80

1.0

V-1.0-20

V-1.0-60

V-1.0-80

2.0

V-2.0-20

V-2.0-60

V-2.0-80

溶接端に生じたき裂(斜めき裂：D)
き裂長(mm)

き裂幅
(mm)

20

60

80

0.1

D-0.1-20

D-0.1-60

D-0.1-800.2

D-0.2-20

D-0.2-60

D-0.2-80

1.0

D-1.0-20

D-1.0-60

D-1.0-80

2.0

D-2.0-20

D-2.0-60

D-2.0-80

図 3.3.1-4 台車のき裂検出における擬似き裂（クラックシール）のパターン

119←西鉄福岡方向

停車位置方向→
3両目

2両目

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

ptn

1

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

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

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

5km/h
5km/h
5km/h
10km/h
10km/h
10km/h
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
1
2
3
1
2
3

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

1
2
3
1
1
3

速度

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

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

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

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
0.1
0.1
0.1
0.1
0.1
0.1

亀裂
長さ
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

前側車軸

1,2
共通

サーマル

後側(mm)
亀裂
はば
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1

亀裂
長さ
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

後側車軸

前側(mm)
亀裂
はば
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1

亀裂
長さ
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

前側車軸

後側(mm)
亀裂
はば
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2

1両目

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

後続台車

亀裂
長さ
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

後側車軸

前側(mm)
亀裂
はば
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2

亀裂
長さ
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

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

後側(mm)
亀裂
はば
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2

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

亀裂
長さ
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

後側車軸

前側(mm)
亀裂
はば
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

亀裂
長さ
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

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

先頭台車

後側(mm)
亀裂
はば
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

亀裂
長さ
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

前側(mm)
亀裂
はば
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

後側車軸

亀裂
長さ
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

後側(mm)
亀裂
はば
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2

前側車軸

図 3.3.1-5 西鉄現地実証における車両走行パターン

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

図 3.3.1-7 収容函ハンドルの開閉異常検知場所
120

後続台車

亀裂
長さ
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

後側車軸

前側(mm)
亀裂
はば
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2

亀裂
長さ
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

前側車軸

後側(mm)
亀裂
はば
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2

亀裂
長さ
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80

クラック
方向
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
ヨコ
タテ
タテ
タテ
タテ
タテ
タテ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ
ナナメ

後側車軸

図 3.3.1-8 ブレーキパッドすり減り検知

図 3.3.1-9 車軸の温度異常検出

図 3.2.1-10 車軸の温度異常検出時の温度比較場所
121【検証結果】
本検証の結果を表 3.3.1-7～表 3.3.1-10 に示す。

表 3.3.1-7 疑似き裂検出結果（DL 型×SaaS 型）
走行速度(km) 向き 平均 / 合計 / 検出率 平均 / 合計 / 網羅率
DL型

5km

垂直

92.3%

水平

95.8%

63.9%

94.0%

65.3%

垂直

100.0%

47.2%

水平

55.9%

52.8%

70.6%

50.0%

82.2%

57.6%

92.3%

66.7%

5 集計
10km
10 集計
DL型 集計
SaaS型

5km

垂直
水平

5 集計
10km

66.7%

垂直
水平

10 集計
SaaS型 集計

95.8%

63.9%

94.0%

65.3%

100.0%

47.2%

55.9%

52.8%

70.6%

50.0%

82.2%

57.6%

疑似き裂検出結果は、DL 型と SaaS 型で差異は見られなかった。

122

表 3.3.1-8 収容函ハンドルの開閉異常検出結果（DL 型×SaaS 型）
パターン

走行速度(km) 補足

DL型

5km

合計 / 検出率 合計 / 網羅率

異常

69%

100%

正常

82%

100%

76%

100%

異常

69%

100%

正常

84%

100%

77%

100%

76%

100%

異常

69%

100%

正常

82%

100%

76%

100%

異常

69%

100%

正常

84%

100%

77%

100%

76%

100%

5km 集計
10km
10km 集計
DL型 集計SaaS型

5km
5km 集計
10km
10km 集計

SaaS型 集計

収容函ハンドルの開閉異常検出結果は、DL 型と SaaS 型で差異は見られなかった。

123

表 3.3.1-9 ブレーキパッドすり減り検知結果（DL 型×SaaS 型）
パターン

速度(km)

DL型

5km

補足

100%

100%

正常

90%

100%

92%

100%

交換対象

100%

100%

正常

87%

100%

89%

100%

5km 集計
10km
10km 集計
DL型 集計
SaaS型

5km

90%

100%

交換対象

100%

100%

正常

90%

100%

92%

100%

交換対象

100%

100%

正常

87%

100%

89%

100%

90%

100%

5km 集計10km

合計 / 検出率 合計 / 網羅率

交換対象10km 集計
SaaS型 集計

ブレーキパッドすり減り検出結果は、DL 型と SaaS 型で差異は見られなかった。

124

表 3.3.1-10 車軸の温度異常検出結果（DL 型×SaaS 型）
DL型
検出対象
走行速度

SaaS型
検出対象
検出率

網羅率

走行速度

検出率

網羅率

5km

100%

100%

5km

100%

100%

10km

100%

100%

10km

100%

100%

車軸の温度異常検出結果は、DL 型と SaaS 型で差異は見られなかった。
本検証結果より、DL 型と SaaS 型において AI 検知性能の差異は見られなかった。そのため、DL 型から SaaS 型へシステム構成を変更したことによる AI モデル検知性能への影響はなく SaaS型の提供形態が AI ソリューション提供時にも問題ないことが確認できた。

2） DL 型で構成されたシステムにおける AI エンジンと SaaS 型で構成されたシステムにおける AI エンジンの処理性能検証
本検証の目的は、今回選定した 5G ソリューションを SaaS 型として提供した場合の AI の処理性能の面で、問題なく実現可能であることを確認することである。DL 型と SaaS 型において、AI エ
ンジンの処理性能を比較し AI ソリューションを SaaS 型で実装することで、同リソース条件下において AI エンジンの処理性能に潜在的なデメリットがないことを確認する。
検証の評価項目としては、一定の処理リソースを割り当てた各構成で、AI の処理性能（処理時間・fps6 ）を計測した。これにより、各構成における AI エンジンの処理性能を評価することができる。（表 3.3.1-11 参照）

表 3.3.1-11 DL 型/SaaS 型で構成されたシステムにおける AI エンジンの処理性能検証内容
評価項目

測定項目

AI 処理時間

4K カメラ及びサーマルカメラの映像に対し、AI エンジンへ映像が到達後の画像取得時間、及び AI 解析処理終了時間

処理フレーム数

4K カメラ及びサーマルカメラの映像に対し、AI エンジンで処理する画像フレーム数（fps）

試験データを入力し、実験環境にデプロイされた DL 型 / SaaS 型の各構成の AI エンジンを用いて解析することで、それぞれの環境で動作する AI 処理性能に有意な差がないことを確認した。

6

frames per second の略称。１秒間当たりのフレーム画像数を表す。

125

【検証結果】
本検証結果を表 3.3.1-12 に示す。
表 3.3.1-12 DL 型で構成されたシステムにおける AI エンジンと SaaS 型で構成されたシステ
ムにおける AI エンジンの処理能検証結果【DL 型（4K カメラ）
】
試行回数

fps

AI解析時間

1

25

0.170

2

25

0.170

3

25

0.170

4

25

0.170

5

25

0.170

平均

0.170

【DL 型（サーマルカメラ）】
試行回数

fps

1

14

AI解析時間
0.130

2

14

0.130

3

14

0.130

4

14

0.130

5

14

0.130

平均

0.130

【SaaS 型（4K カメラ）】
試行回数

fps

AI解析時間

1

22

0.280

2

23

0.280

3

23

0.290

4

23

0.270

5

24

0.280

平均

0.280

【SaaS 型（サーマルカメラ）
】
試行回数

fps

1

14

AI解析時間
0.130

2

14

0.130

3

14

0.130

4

14

0.130

5

14

0.130

平均

0.130

検証結果より、DL 型と SaaS 型で結果に差異は見られたが、両者の AI 処理に使用される処理リ
ソースの差異により発生したものと考えられる。AI 検出に求める性能の観点で影響のある差異は見られず、SaaS 型構成でも問題なく実現できることが確認できた。
サーマルカメラ映像については AI 処理時間及び処理フレーム数に差異は無かったが、4K カメ
126

ラ映像については SaaS 型の方が、処理フレーム数が少なく処理時間の増加が見られた。しかしながら、3.3.1(2)2)より、本検証で見られた処理時間の差異は、AI の検知性能に著しく影響を与えているとは言えず、あくまでもデータ取得時に利用されているリソースの性能差異によって処理性能も順当に差異が出たと捉えることができる。
実証システムを、SaaS 型へのアーキテクチャ変更すること自体が、AI エンジンの処理性能に有意な差を及ぼすことがないことが確認できた。

5G 特性（遅延性）を考慮した SaaS ソリューションの検証
ここでは、特に SaaS 型で構築するシステムの論点となる「遅延性」に関して、後述する 3.4.1
項 に包含される「接続方式ごとの通信性能」を除く因子について検証する。具体的には、過年度実証にて未検証である、クラウド環境において利用可能な処理リソースの多寡に応じた、ソリュー
ションの動作や応答速度を検証する。また、「ソリューション側のクラウド等のリソース」が接続方式に与える影響についても分析する。
SaaS 型のシステム構築・運用においては、クラウド環境の適切な処理リソースを設計する必要がある。なぜなら、複数の利用者が、提供者側の環境に構築されたシステムを同時に利用するため、利用者数に応じて利用可能なリソースが制限され、システムの応答速度が変化するためである。
3.1 節で選定した「鉄道車両監視 AI システム」を SaaS 型で構築した上で、複数事業者で同時利用したシーンを想定し、クラウド環境の処理リソースを変化させたときの AI 解析機能を評価することで、SaaS 型構成での 5G ソリューションの性能、特に遅延に関する影響を検証する。

（1） SaaS 型形態で構成されたシステムにおけるクラウド上の処理リソース変動に対する AI 処理性能の検証
本検証の目的は、SaaS 型構成のシステムにおいて、クラウド上の処理リソースを変動させ、AIエンジン処理性能の変化を確認することである。本検証を通じて、SaaS 型構成の場合の、GPU リ
ソースと AI 処理性能の関係性を把握し、SaaS 型ソリューションの普及展開のための「リソース要件」検討に活用する。
検証の評価には、AI 解析時間、解析可能な処理フレーム数を用いる。
表 3.3.2-1 に示す評価項目を測定し、GPU リソース変動における AI 処理性能の変化を確認した。

表 3.3.2-1 SaaS 型で構成されたシステムにおけるクラウド上の処理リソース変動に対する
AI 処理性能の検証内容
評価項目

測定項目

AI 処理時間

4K カメラ及びサーマルカメラの映像に対し、AI エンジンへ映像
が到達後の画像取得時間、及び AI 解析処理終了時間

127

4K カメラ及びサーマルカメラの映像に対し、AI エンジンで処理

処理フレーム数する画像フレーム数（fps）

パラメータについては、下記の通り。
GPU 割当リソース（GPU カード枚数）：5 / 8 / 16

上記のパラメータをもとに、評価項目を測定し GPU リソース変動における AI 処理性能の変化を確認した。
（図 3.3.2-1 参照）

図 3.3.2-1 SaaS 型で構成されるシステムにおけるクラウド上の処理リソース変動に対する AI 処理性能の検証イメージ【検証結果】
AI 解析処理可能なフレーム数については以下の計算式とパラメータ（表 3.3.2-2 参照）を用
いて机上計算結果を以下に記載する。

解析処理可能フレームレート = 活用する API 数 ÷ 処理速度(msec) × 1 枚当たり活用する API 数
表 3.3.2-2 AI 解析処理可能なフレーム数算出に用いた値（GPU 割当リソース=5 枚の時）
解析対象

活用 API 数

処理速度

1 枚当たり活用する API 数(= GPU 数)
車両検知

3350msec1

車体番号検知1

500msec

1

サーマル

1

150msec1

128

（GPU 割当リソース=8 枚の時）
解析対象

活用 API 数

処理速度

1 枚当たり活用する API 数(= GPU 数)
車両検知

5350msec1

車体番号検知1

500msec

1

サーマル

2

150msec

1（GPU 割当リソース=16 枚の時）
解析対象

活用 API 数

処理速度

1 枚当たり活用する API 数(= GPU 数)
車両検知

10350msec1

車体番号検知2500msec

1

サーマル

4

250msec1

机上での GPU 割当リソース毎のフレームレート（理論値）は以下となる。

GPU 割当

解析対象

測定種別

リソース

活用 API 数

フレームレート(= GPU 数)

（理論値）

5枚

車両検知

4K カメラ映像

3

8(内、車体番号検サーマル

サーマルカメラ映像

1

6

8枚

車両検知

4K カメラ映像

5

14(内、車体番号検サーマル

サーマルカメラ映像

2

13

16 枚

車両検知

4K カメラ映像

1028(内、車体番号検サーマル

サーマルカメラ映像

4

16

知に 1 枚)知に 1 枚)知に 2 枚)

本検証の結果を表 3.3.2-3～表 3.3.2-4 に示す。
表 3.3.2-3 SaaS 型形態で構成されたシステムにおけるクラウド上の処理リソース変動に対する AI 処理性能の検証結果（4K カメラ）
測定種別

測定区間

GPU割当リソース(GPUカード枚数)

4Kカメラ映像WebRTCインスタンス ‐ AIインスタンス

5枚

7

0.28

8枚

13

0.27

16枚

23

0.28

129

処理フレーム数
(fps)

処理速度
(sec)

表 3.3.2-4 SaaS 型形態で構成されたシステムにおけるクラウド上の処理リソース変動に対する AI 処理性能の検証結果（サーマルカメラ）
測定種別

測定区間

GPU割当リソース(GPUカード枚数)

処理フレーム数
(fps)

処理速度
(sec)

サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス

5枚

5

0.16

8枚

12

0.14

16枚

14

0.13

本測定により、SaaS 型構成において、複数事業者が同時に利用する場面を想定した遅延影響
が実際の数値として確認できた。結果としては、リソース変動が AI 検知性能面で若干の変動を及ぼすことは確認できたが、「遅延性」の観点においては、後述するソリューションの End to
End の遅延の合計値を鑑みるに非常に小さな数値であることが確認できた。このことから、適切な設計で SaaS 型構成とすることで、DL 型と比較しても遅延性の観点では、ソリューション提供に大きな影響を及ぼさないことが確認できた。
補足として、特に処理フレーム数については、実測時にも机上計算と同様の傾向が見て取れた。また、4K 映像とサーマルカメラ映像間で処理速度に差が生じているが、アルゴリズム間の違いや、処理映像サイズに起因するものである。4K カメラ映像、サーマルカメラ映像の解析を行った場合に、双方ともに GPU 割当リソース（GPU 数）の減少に伴い、処理フレーム数も併せて減少することが確認できた。割当リソースの減少に伴い、処理フレームは減少するが GPU 割当リ
ソース数から導かれる机上計算での理論値の近似値を取っていることを確認できた。また割り当てた GPU リソースの変動に対しても、解析処理速度は処理可能なフレーム数が増加することで処理にかかる時間が増加する傾向にあるが、処理速度の大幅な劣化がない点を確認できた。よって、複数事業者が同時に利用した際には検知性能面の上で処理フレーム数の考慮は必要となるが、処理速度についての影響は限定的であると言える。

SaaS 型での活用を想定した 5G ソリューションの検証まとめ
5G ソューションに係る検証において、検証環境において構築した SaaS 型での 5G ソリューションの構築に関する検証結果のまとめを記載する。
結論として、過年度 DL 型で構築したソリューションを SaaS 型として再構築した場合においてもシステムは正常動作可能であり、本事業で選定したソリューションは SaaS 型アーキテクチャにて問題なく提供可能であることを確認できた。
仮説時点の懸念として、SaaS 型にアーキテクチャを変更することにより、処理負担の大きい GPU
リソースに関して処理性能など劣化する恐れがあったが、リソース変動による性能低下は問題がないレベルであることを確認した。
残課題として、実際にサービス提供される際の GPU リソースの物理的な機種の差異による影響があるが、「鉄道車両監視 AI システム」全体で生じる遅延に対して AI での解析処理遅延が与える影響については軽微であった。詳細は、後続の「横展開可能な 5G ソリューションの各種検証」において複数事業者が本システムを利用した場合での実証試験結果にて記載する。
130

また、設計における留意事項として、「鉄道車両監視 AI システム」における AI エンジンは、解析リソース数に応じて解析性能が増減することから、解析処理遅延も、解析リソースが多い場合に処理遅延が減少し、解析リソースが少ない場合には処理遅延が増加する傾向にある。
共同利用時のリソース設計については、限られたリソースを複数ユーザに効率的に分散させていくことが重要であるため、後述する複数事業者が活用することを想定した場合での実証実験において、複数事業者でのシステム共同利用時に各事業者に割り当てを行ったリソースにおけるシステム全体の処理性能の変化、解析性能および、AI 検知結果を測定することとし、利用者単位において設計したリソース利用分に対してシステム性能の評価結果からまとめる。

横展開可能な 5G ソリューションの各種検証
本節では、3.1.2 ならびに 3.1.3 項にて述べた汎用性および、利用者負担の軽減効果を確認するため、3.2 節にて構築した環境を用いた実証を行った結果について取りまとめる。

レベル１：ネットワーク/アーキテクチャに係る汎用性評価
本検証の目的は、汎用的に利用可能なネットワーク/アーキテクチャを用いて SaaS 型形態を提供することによる汎用性を明らかにすることである。
（表 3.4.1-1 参照）なお、SaaS 型形態の共用システムにおけるネットワーク/アーキテクチャに関する汎用性とは、SaaS 型の共用システムで使用しているネットワーク/アーキテクチャが特定分野でのみ使えるものではなく、横展開可能なものであることを意味する。

表 3.4.1-1 ネットワーク/アーキテクチャに係る汎用性評価内容
評価項目

測定項目

汎用性

・汎用的な NW/アーキテクチャを活用して、SaaS 型提供形態を実現
出来るか
・本事業以外の他ソリューションにも適用可能か

ここでは、SaaS 型の「鉄道車両監視 AI システム」をもとに、他分野への 5G ソリューション展
開を見据え、SaaS 型の有効性、ソリューションの汎用化、SaaS や接続方式等の技術的課題、今後必要な検証等について取りまとめる。
今年度、実証システムとして構築した SaaS 型の「鉄道車両監視 AI システム」のネットワーク/アーキテクチャに関する汎用性について記載する。

・ ネットワーク
現地環境からクラウド環境間の 5G ネットワーク構成として国内通信キャリアが提供する 5G 商
用通信サービスを活用している。
131

また、通信キャリアが提供する 5G 商用通信サービスからクラウド環境への接続区間においては、国内通信キャリアのインターネット接続サービス経由および、通信キャリア網内での閉域クラウド接続サービスでの接続方式を活用した。
現地環境からクラウド環境間の 5G ネットワーク構成として 5G の 3GPP 仕様に準拠した 5G 商用サービスを活用しており、他ユースケースにおいても同 5G ネットワークによる接続方式を活用することが可能である。
課題としては、現地環境により 5G ネットワークエリアの形成状態がサービスを提供する通信キャリアによって異なる可能性がある。その場合は他の通信キャリアでのサービス代替を検討する。または、ソリューション利用、エリア形成が一時的な場合においては可搬型 5G 基地局の利用によるスポット的な 5G サービスの利用が可能である。
クラウド環境への接続方法は、通信キャリア網を通じたインターネット接続、通信キャリア網
内での閉域接続の双方で、全国で汎用的に利用可能である。
ただし、本ソリューションでは大きな影響とならなかったが、現地環境とクラウド環境との物
理的な設置位置の距離に依存した遅延値の増大がソリューションの性能に影響する可能性がある
点はソリューション設計時に考慮する必要がある。

・ アーキテクチャ
本実証で採用したクラウドサービス(docomoMEC)は、国内通信キャリアが提供するクラウドサービスを利用している。当該クラウドサービスで提供される汎用コンピューティングリソース
及びクラウド基盤の仮想化技術についても OSS である「OpenStack」を採用したサービスとなっている。
他分野への展開を見据えた場合に、本システムが他分野への展開が可能か汎用性の観点において評価した。
当該のクラウドサービス（docomoMEC）を活用した他分野における導入事例は複数存在しており、合わせて、鉄道車両監視 AI システムにおけるクラウドサービスの利用においてもサービスにおいて標準提供されるクラウドリソースを活用してアーキテクチャを構成したことから汎用性がある
ことが確認できた。
本システムを他分野へ展開する際には本クラウドサービスが提供する標準クラウドリソースにおいて、他分野展開時に追加実装が必要となるクラウドリソースが提供できない場合は、代替ク
ラウドサービスの利用検討及び、外部クラウドサービスとの連携によるアーキテクチャの見直しを図る必要性がある点は懸念事項となる。

132

図 3.4.1-1 docomoMEC での 5G ソリューション導入事例（遠隔支援システム7）
なお、先に述べた汎用的な技術の内、接続方式については SaaS 型で論点となる「遅延」を軽減する手段として期待の寄せられる技術（閉域接続方式）が存在する。今後の遅延低減の方策の参考とすべく、接続方式の違いが及ぼす低遅延性への影響について、以下で検証を行った。

（1） SaaS 型で提供されるネットワーク接続形態ごとの伝送性能検証
本検証では、ネットワーク接続形態毎の伝送性能を実環境で確認し、特に遅延低減効果に着目し接続方式および、接続拠点の位置との関連をネットワーク観点で確認する。
検証の評価項目として、協力鉄道事業者各社の車両基地の検車庫内に構築するキャリア 5G エリ
アにおいて、閉域接続方式、インターネット接続方式それぞれの場合において、5G 受信端末に接続される試験用 PC から、クラウド（SaaS 基盤）に構築するサーバ間で、iperf 及び ping により一定容量のデータを送信したときの所要時間、スループットを計測した。
（表 3.4.1-2 参照）
表 3.4.1-2 SaaS 型で構成されたシステムにおけるネットワーク性能検証内容
評価項目

測定項目

上りスループット TCP/UDP

bandwidth、jitter、lost/total パケット数※3 回の計測値、またその平均を用いる

下りスループット TCP/UDP

7

bandwidth、jitter、lost/total パケット数

NTT コミュニケーションズ「docomoMEC での 5G ソリューション導入事例（遠隔支援システム ）」https://www.ntt.com/business/lp/5G/column/009.html
133

※3 回の計測値、またその平均を用いる

応答時間（RTT）

min/avg/max/stddev※3 回の計測値、またその平均を用いる

パラメータについては、下記の通り。


試験方法：iperf / ping



試験区分

：UL（上り） / DL（下り）

パケットサイズ（byte）



スループット（Mbps） ：30 / 100

送信時間（sec）

：1300
：60

【検証結果】
本検証の結果を表 3.4.1-3～表 3.4.1-4 に示す。
表 3.4.1-3 ネットワーク接続形態ごとの伝送路性能検証結果（西鉄）【インターネット接続方式】
測定区間①4K Jetson（Ubuntu）

試験 プロトコル

応答時間の
応答時間の
応答時間の
応答時間の
bandwidth jitter
lost/total
最小値
最大値
パケット 送信時間 スループット
平均値
標準偏差値
試験区分
(Mbps)
(ms)
パケット数
（ms）
（ms）
サイズ (sec)(Mbps)（ms）（ms）(3回平均値) (3回平均値) (3回平均値) (3回平均値)(3回平均値)(3回平均値)(3回平均値)

iperf TCP

上り

1300

60

30

89.29

-

-

-

-

-

-

下り

1300

60

30

63.28

-

-

-

-

-

-

上り

1300

60

30

29.91

0.82

0.00

-

-

-

-

下り

1300

60

30

29.98

0.16

0.00

-

-

-

-

UDP_100M 上り

1300

60

100

99.92

0.32

0.00

-

-

-

-

下り

1300

60

100

99.42

0.77

0.01

-

-

-

-

1300

60

-

-

-

-

39.79

86.48

440.97

84.70

上り

1300

60

30

22.43

-

-

-

-

-

-

下り

1300

60

30

33.87

-

-

-

-

-

-

上り

1300

60

30

30.01

1.46

0.00

-

-

-

-

下り

1300

60

30

29.89

0.11

0.00

-

-

-

-

UDP_100M 上り

1300

60

100

70.63

0.54

0.29

-

-

-

-

下り

1300

60

100

98.66

0.23

0.01

-

-

-

-

1300

60

-

-

-

-

47.33

66.67

176.00

-

上り

1300

60

30

17.15

-

-

-

-

-

-

下り

1300

60

30

34.79

-

-

-

-

-

-

上り

1300

60

30

30.00

1.12

0.00

-

-

-

-

下り

1300

60

30

29.92

0.22

0.00

-

-

-

-

UDP_100M 上り

1300

60

100

57.16

0.72

0.38

-

-

-

-

下り

1300

60

100

99.96

0.19

0.00

-

-

-

-

1300

60

-

-

-

-

54.33

74.33

236.67-

UDP_30M－WebRTCインスタンス間

ping ICMP
iperf TCP

②監視用GPUPC（Windows）－WebRTCインスタンス間

UDP_30M

ping ICMP
iperf TCP

③監視用GPUPC（Windows）－Webインスタンス間

UDP_30M

ping ICMP

134

【閉域接続方式】

測定区間①4K Jetson（Ubuntu）

試験 プロトコル

応答時間の
応答時間の
応答時間の
応答時間の
bandwidth jitter
lost/total
最小値
最大値
パケット 送信時間 スループット
平均値
標準偏差値
試験区分
(Mbps)
(ms)
パケット数
（ms）
（ms）
サイズ (sec)(Mbps)（ms）（ms）(3回平均値) (3回平均値) (3回平均値) (3回平均値)(3回平均値)(3回平均値)(3回平均値)

iperf TCP

上り

1300

60

-

88.75

-

-

-

-

-

-

下り

1300

60

-

366.22

-

-

-

-

-

-

上り

1300

60

30

29.97

0.88

0.00

-

-

-

-

下り

1300

60

30

28.50

0.17

0.05

-

-

-

-

UDP_100M 上り

1300

60

100

98.56

0.39

0.01

-

-

-

-

下り

1300

60

100

86.46

0.58

0.14

-

-

-

-

1300

60

-

-

-

-

38.41

59.91

179.23

18.12

上り

1300

60

-

24.30

-

-

-

-

-

-

下り

1300

60

-

41.60

-

-

-

-

-

-

上り

1300

60

30

29.74

1.08

0.01

-

-

-

-

下り

1300

60

30

29.64

0.16

0.01

-

-

-

-

UDP_100M 上り

1300

60

100

89.96

0.77

0.10

-

-

-

-

下り

1300

60

100

96.85

0.19

0.03

-

-

-

-

1300

60

-

-

-

-

38.33

57.67

209.00

-

上り

1300

60

-

22.96

-

-

-

-

-

-

下り

1300

60

-

42.01

-

-

-

-

-

-

上り

1300

60

30

29.38

1.67

0.02

-

-

-

-

下り

1300

60

30

29.83

0.18

0.00

-

-

-

-

UDP_100M 上り

1300

60

100

90.14

0.76

0.10

-

-

-

-

下り

1300

60

100

98.90

0.29

0.01

-

-

-

-

1300

60

-

-

-

-

39.33

56.33

190.67-

UDP_30M－WebRTCインスタンス間

ping ICMP
iperf TCP

②監視用GPUPC（Windows）－WebRTCインスタンス間

UDP_30M

ping ICMP
iperf TCP

③監視用GPUPC（Windows）－Webインスタンス間

UDP_30M

ping ICMP

表 3.4.1-4 ネットワーク接続形態ごとの伝送路性能検証結果（京阪）【インターネット接続方式】
測定区間①4K Jetson（Ubuntu）

試験 プロトコル

応答時間の
応答時間の
応答時間の
応答時間の
bandwidth jitter
lost/total
最小値
最大値
パケット 送信時間 スループット
平均値
標準偏差値
試験区分
(Mbps)
(ms)
パケット数
（ms）
（ms）
サイズ (sec)(Mbps)（ms）（ms）(3回平均値) (3回平均値) (3回平均値) (3回平均値)(3回平均値)(3回平均値)(3回平均値)

iperf TCP

上り

1300

60

-

134.76

-

-

-

-

-

-

下り

1300

60

-

470.32

-

-

-

-

-

-

上り

1300

60

30

29.94

0.81

0.00

-

-

-

-

下り

1300

60

30

28.26

0.03

0.06

-

-

-

-

UDP_100M 上り

1300

60

100

99.92

0.32

0.00

-

-

-

-

下り

1300

60

100

90.49

0.03

0.10

-

-

-

-

1300

60

-

-

-

-

28.58

50.47

82.10

9.12

上り

1300

60

-

29.68

-

-

-

-

-

-

下り

1300

60

-

38.43

-

-

-

-

-

-

上り

1300

60

30

30.00

0.35

0.00

-

-

-

-

下り

1300

60

30

29.47

0.04

0.02

-

-

-

-

UDP_100M 上り

1300

60

100

99.99

0.32

0.00

-

-

-

-

下り

1300

60

100

96.18

0.12

0.03

-

-

-

-

1300

60

-

-

-

-

44.67

58.33

86.00

-

上り

1300

60

-

27.68

-

-

-

-

-

-

下り

1300

60

-

33.76

-

-

-

-

-

-

上り

1300

60

30

29.92

0.37

0.00

-

-

-

-

下り

1300

60

30

29.84

0.04

0.00

-

-

-

-

UDP_100M 上り

1300

60

100

100.01

0.91

0.00

-

-

-

-

下り

1300

60

100

99.90

0.08

0.00

-

-

-

-

1300

60

-

-

-

-

46.33

63.67

81.33

-

UDP_30M－WebRTCインスタンス間

ping ICMP
iperf TCP

②監視用GPUPC（Windows）－WebRTCインスタンス間

UDP_30M

ping ICMP
iperf TCP

③監視用GPUPC（Windows）－Webインスタンス間

UDP_30M

ping ICMP135

【閉域接続方式】

測定区間

試験 プロトコル

応答時間の
応答時間の
応答時間の
応答時間の
bandwidth jitter
lost/total
最小値
最大値
パケット 送信時間 スループット
平均値
標準偏差値
試験区分
(Mbps)
(ms)
パケット数
（ms）
（ms）
サイズ (sec)(Mbps)（ms）（ms）(3回平均値) (3回平均値) (3回平均値) (3回平均値)(3回平均値)(3回平均値)(3回平均値)

iperf TCP

上り

1300

60

-

129.53

-

-

-

-

-

-

下り

1300

60

-

489.05

-

-

-

-

-

-

上り

1300

60

30

29.78

0.12

0.01

-

-

-

-

下り

1300

60

30

28.41

0.04

0.05

-

-

-

-

UDP_100M 上り

1300

60

100

97.35

0.22

0.03

-

-

-

-

下り

1300

60

100

90.23

0.05

0.10

-

-

-

-

1300

60

-

-

-

-

25.43

39.47

171.85

18.18

上り

1300

60

-

41.79

-

-

-

-

-

-

下り

1300

60

-

62.55

-

-

-

-

-

-

上り

1300

60

30

29.47

0.46

0.02

-

-

-

-

下り

1300

60

30

29.84

0.06

0.00

-

-

-

-

UDP_100M 上り

1300

60

100

97.25

0.50

0.03

-

-

-

-

下り

1300

60

100

99.31

0.08

0.00

-

-

-

-

1300

60

-

-

-

-

25.33

44.00

196.67

-

上り

1300

60

-

42.97

-

-

-

-

-

-

下り

1300

60

-

62.94

-

-

-

-

-

-

上り

1300

60

30

29.83

0.20

0.00

-

-

-

-

下り

1300

60

30

29.81

0.04

0.00

-

-

-

-

UDP_100M 上り

1300

60

100

97.49

0.34

0.02

-

-

-

-

下り

1300

60

100

99.10

0.14

0.01

-

-

-

-

1300

60

-

-

-

-

29.33

44.67

163.67-①4K Jetson（Ubuntu）

UDP_30M－WebRTCインスタンス間

ping ICMP
iperf TCP
UDP_30M②監視用GPUPC（Windows）－WebRTCインスタンス間

ping ICMP
iperf TCP
UDP_30M③監視用GPUPC（Windows）－Webインスタンス間

ping ICMP

本結果より、接続方式の違い、利用拠点とクラウドとの距離が、遅延性能（平均応答時間）に影響があることが確認できた。その他指標（bandwidth 等）の差異は測定時の誤差程度であり、各接続方式を利用する上での大きな差は認められない。
3.3.1(1)1)での事前検証、上記の西鉄での現地実証、京阪での現地実証の各検証を実施した日時、5G 基地局設置状況が異なっているため、帯域（bandwidth）等の測定結果にバラつきがあるものの、それぞれのケースにおいて、インターネット接続方式と閉域接続方式を比較すると、閉域接続方式のほうがインターネット接続方式よりも平均応答時間が小さくなり閉域接続方式のほうがインターネット接続方式よりもリアルタイム性が求められる伝送において優位といえる。
また、西鉄と京阪の平均応答時間を比較すると、京阪の平均応答時間が総じて小さい。これは、本実証において構築したクラウド環境が大阪に立地するため、・西鉄：

福岡（現地）←→ 大阪（クラウド）・京阪：

大阪（現地） ←→ 大阪（クラウド）の距離の差による影響と考えられる。
今後、MEC が推進され、クラウドとの接続拠点が全国に拡大していくと、利用拠点と 5G ソリュー
ションを提供するクラウドとの遅延性能の向上、安定が期待される。

（2） SaaS 型提供を構成するアーキテクチャ観点での汎用性の評価
本実証で採用したクラウドサービス(docomoMEC)のアーキテクチャとしての汎用性を評価する。
当該クラウドサービスで提供されるコンピューティングリソース及びクラウド基盤の仮想化技
術は OSS である「OpenStack」が採用されている。
他分野への展開を見据えた場合に、本システムが他分野への展開が可能か汎用性の観点におい136

て評価した。
当該のクラウドサービス（docomoMEC）を活用した他分野における導入事例は複数存在しており、合わせて、鉄道車両監視 AI システムにおけるクラウドサービスの利用においてもサービスにおいて標準提供されるクラウドリソースを活用してアーキテクチャを構成したことから汎用性がある
ことが確認できた。
本システムを他分野へ展開する際には本クラウドサービスが提供する標準クラウドリソースにおいて、他分野展開時に追加実装が必要となるクラウドリソースが提供できない場合は、代替ク
ラウドサービスの利用検討及び、外部クラウドサービスとの連携によるアーキテクチャの見直しを図る必要性がある点は懸念事項となる。

（3） レベル１検証まとめ
汎用化レベル 1 では、システムのネットワーク/アーキテクチャの観点で汎用性を評価した。
本事業の AI ソリューション（モデルケース）は、他のソリューションに展開をする際に制約がある技術やサービスは利用しておらず、本システムのネットワーク/アーキテクチャは、今回、選定した鉄道車両監視 AI システムだけでなく、その他の種類のソリューションにも本アーキテク
チャを適用可能であることを確認した。
課題として、他のユースケースにおいてシステム要求に差異が生じる場合、同様のネットワー
ク/アーキテクチャを活用する場合に性能要求が本アーキテクチャを構成する標準サービスで満たせない際に、代替サービスやリソースの増強を検討する必要があるなど個別要求への対応の点が挙げられる。
クラウドとのネットワークの接続方式による遅延性の差異についても、5G 基地局設置状況、接続する docomoMEC の拠点までの物理距離等バラつきがあるものの、各検証結果が示す通り、閉域
網接続のほうがインターネット経由接続よりも概ね遅延時間が短くなり、リアルタイム性が求められる伝送において優位であることが確認できた。
（図 3.4.1-3）また、NW 接続方式によるソリュー
ション全体への影響としては、本事業で選定している 5G ソリューションにおいては、End to Endで発生する遅延の中で NW の接続形態に関する影響は、限定的であった。他ユースケースに展開する際において、より低遅延性を要求された場合には、今回検証を行った結果からも NW 接続形態を
閉域接続方式とすることが遅延低減策の一つとして効果が発揮できる。

137

図 3.4.1-3 ネットワーク接続形態での遅延量の差異

レベル２：共通コア機能関連の汎用性評価
本検証の目的は、今回選定した 5G ソリューションを事例として、SaaS 型にて 5G ソリューショ
ンを提供する場合に必要となる機能として、仮説設定し新たに開発を行った「共用コア機能」について、動作の正常性や有意性を確認し、SaaS 型提供形態における共用コア機能の知見を汎用化することである。共通コア機能として、複数ユーザのデータ格納領域を定義して独立的に管理する機能等を搭載し、SaaS 共用における有効性を検証した。（図 3.4.2-1 参照）
マルチテナント管理機能は、「鉄道車両監視 AI システム」のみならず、分野横断的に多くのシステムで利用可能な汎用技術である。
SI 型や DL 型では、利用者毎にシステムパッケージを構築、またはデプロイして運用することが前提であり、システムを同時に共用する設計思想とはなっていなかったが、SaaS 型で共用を行
う上では必須の機能である。SaaS 型提供形態として本機能を実装することで、利用者は、他の利用者が同時に利用していることを意識すること無く、システムを利用することができる。
複数の利用者が同一のシステムを共用する場合、技術的には並列的な処理と独立したデータ管理が必要となる。そこで、ここではマルチテナントの並列的な処理とデータ格納領域の定義について検証する。その上で、実際に現地設備と SaaS 型システムを連動させる実証試験を通じて、複数系統の並列処理性能を検証する。

138

SI・DL型環境

SaaS側環境過去実証では単一ユーザ専用環境のため
ユーザ管理は実証スコープ外

ユーザのデータ・設定を管理し複数のユーザから利用可能とする必要がある

データ・設定管理
A社設定

処理機能

データ・設定管理
B社設定

処理機能

処理A
イ
ン
プ
ッ
ト

処理A

NW

X社設定

処理B

CPU

処理C

GPU

ア
ウ
ト
プ
ッ
ト

イ
ン
プ
ッ
ト

処理A

NW

HDD

処理B

処理C

処理B

処理C

処理A

処理B

処理C

CPU

GPU

HDD

ア
ウ
ト
プ
ッ
ト

共通のリソースで複数ユーザの処理を実施
負荷のかかるタイミングは不確定のため負荷発生時の影響を確認する必要がある

基本的には処理は直列、同一ユーザのため負荷のかかるタイミングはコントロール可能

図 3.4.2-1 マルチテナント構成のイメージ
マルチテナント管理機能により、提供者側の同一のクラウド環境内で複数利用者のデータを独立して扱うことができる。これにより、処理リソースを有効活用するだけでなく、利用者は他の利用者を意識せずにシステムを利用することができる。（表 3.4.2-1 参照）
利用者負担軽減効果については、3.4.4 項にてレベル毎の評価を取りまとめる。

表 3.4.2-1 共通コア機能関連の汎用性評価内容
評価項目

測定項目

汎用性

・本事業以外の他ソリューションにも適用可能か

利用者負担軽減効果

・運用時のコスト削減効果（リソース効率化等）（1） 並列処理機能の正常性確認
本検証の目的は、マルチテナント管理機能を用いて実装する鉄道車両監視 AI システムについて、考案した設計で問題なく動作出来ることを AI 処理性能の観点で確認することである。複数利用者が共用する際のシステム挙動を確認し、マルチテナント構成が設計仕様に準拠した性能を発揮することが推察される。マルチテナント構成により、複数ユーザでの利用（複数映像インプット）に対して、それぞれ並列的に AI 解析が実行されることを確認する。
検証として、以下の評価項目に対し測定を行った。
（表 3.4.2-2 参照）139

表 3.4.2-2 並列的な処理機能の検証項目
評価項目

測定項目

複数系統（1 / 2 / 3 系統の 3 通りを模

4K カメラ及びサーマルカメラの映像に対し、AI擬）からの映像インプット時の AI 処理時エンジンへ映像が到達後の画像取得時間、及び間

AI 解析処理終了時間※各映像インプット単位

複数系統（1 / 2 / 3 拠点の 3 通りを模

4K カメラ及びサーマルカメラの映像に対し、AI擬）からの映像インプット時の処理フレーエンジンで処理する画像フレーム数（fps）

ム数※各映像インプット単位設定するインプット系統のパラメータについては、下記のとおりである。


測定種別：4K カメラ / サーマルカメラ



拠点数:1 / 2 / 3

上記パラメータをもとに、複数拠点からのインプット構成を実験環境下に構築し、マルチテナ
ント構成におけるシステム挙動を測定した測定を実施した。（図 3.4.2-2 参照）

図 3.4.2-2 並列的な処理機能の検証イメージ

本検証の結果を表 3.4.2-3 に示す。

140

表 3.4.2-3 並列的な処理機能の検証結果
拠点数

割当GPU枚数 インプット系統(/拠点)(チャネルID)

測定種別

16

1 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

23

0.28

2 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

14

0.13

1 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

13

0.27

2 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

12

0.14

3 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

10

0.38

4 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

10

0.14

1 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

7

0.28

2 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

5

0.16

3 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

6

0.39

4 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

5

0.16

5 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

7

0.25

6 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

5

0.17

1
2

8

3

5

測定区間

処理フレーム数
(fps)

処理速度
(sec)

検証結果より、想定通りに並列処理が行え、考案した設計が問題なく実装可能であることがわかった。
拠点数が増加するにつれて、インプット系統単位で見た時の処理フレーム数は減少しているが、処理速度は系統ごとに一律の値となっている。拠点数＝ユーザ数と見た時に各ユーザ間で 4K カメラ映像とサーマルカメラそれぞれの処理フレーム数及び処理速度に著しい差異は見られないため、マルチテナント構成によって適切にリソースが分散され並列に AI 処理されていることが分かる。
また、本検証ではリソースは有限であることから複数ユーザにリソース分散する際は AI 解析の処
理速度を一定に保つこととし、その分処理フレーム数が減少する仕様としており、設計通りの挙動を示していると言える。

（2） データ格納領域の独立性確認
本検証の目的は、マルチテナント管理機能を用いて実装する「鉄道車両監視 AI システム」について、考案した設計で問題なく動作出来ることをデータ保存処理の観点で確認することである。
本機能は、複数利用者が共用する状況下において、利用者ごとのデータを独立した格納領域で管理し、WebUI の表示内容を連動的に制御する。そこで、本検証では、マルチテナント管理に基づく
利用者ごとのデータ管理及び WebUI 表示内容の切り替えについて確認する。
検証として以下の評価項目に対し測定を行った。（表 3.4.2-4 参照）
表 3.4.2-4 データ格納領域の正常性検証項目
評価項目

測定項目

複数系統（1 / 2 / 3 拠点の 3 通りを模擬） 以下のデータが、ユーザ毎に格納領域が分割されるからの映像インプット時のデータ格納

形でデータベースに格納されていること。
・録画映像データ
・AI 解析結果（矩形座標、車両番号、時間情報）

複 数 ユ ー ザ同 時 利 用時 の 、各 ユ ー ザの

複数ユーザが同時に、以下が可能であること。

WebUI 表示内容

・WebUI に同時アクセス可能である

141

・WebUI 上の操作が可能である
ログインユーザに紐づく以下データが UI に表示さ
れること
・生映像
・解析結果付き映像
・録画映像

システムのデータベース領域における、複数系統のデータ格納状況を確認した。
また、複数利用者で同時にログインし、特定の画面操作を行い、WebUI で利用者ごとに閲覧可能なデータが切り替わることを確認した。
（図 3.4.2-3 参照）

図 3.4.2-3 データ格納領域の正常性検証イメージ【検証結果】
本検証の結果を表 3.4.2-5 に示す。

142

表 3.4.2-5 データ格納領域の正常性検証結果【マルチテナント時の DB 確認】

インプット系統数 チャネルID
3

測定種別
1 4Kカメラ映像
サーマルカメラ映像
2 4Kカメラ映像

測定区間

確認方法

WebRTCインスタンス ‐ AIインスタンス(台車)

DBにアクセスし、チャネルID単位で所定のDBディレ
クトリにデータが格納されていることを確認

WebRTCインスタンス ‐ AIインスタンス(サーマル)
WebRTCインスタンス ‐ AIインスタンス(台車)サーマルカメラ映像
3 4Kカメラ映像

DBにアクセスし、チャネルID単位で所定のDBディレ
クトリにデータが格納されていることを確認

WebRTCインスタンス ‐ AIインスタンス(サーマル)
WebRTCインスタンス ‐ AIインスタンス(台車)サーマルカメラ映像

録画ファイルが正常 AIアウトプット情報(座標、に所定のDBディレク 車両番号、タイムスタンプ)がトリに格納されている 適切に所定のDBディレクトリ
こと(○/×)に格納されていること(○/×)

DBにアクセスし、チャネルID単位で所定のDBディレ
クトリにデータが格納されていることを確認

WebRTCインスタンス ‐ AIインスタンス(サーマル)

○

○

○

○

○

○

○

○

○

○

○

○

【マルチテナント時の UI 確認】
インプット系統数 チャネルID
3

測定種別
1 4Kカメラ映像
サーマルカメラ映像

ログインユーザに紐づ ログインユーザに紐づく解析 ログインユーザに紐づく録画
く生映像しか見れな 結果付き映像しか見れない 映像しか見れないこと(○/いこと(○/×)こと(○/×)
×)

測定区間

確認方法

WebRTCインスタンス ‐ AIインスタンス(台車)UIにアクセスし、ログインユーザに紐づくチャネルIDのデータしか表示・参照できないことを確認

WebRTCインスタンス ‐ AIインスタンス(サーマル)

2 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)サーマルカメラ映像

UIにアクセスし、ログインユーザに紐づくチャネルIDのデータしか表示・参照できないことを確認

WebRTCインスタンス ‐ AIインスタンス(サーマル)

3 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)サーマルカメラ映像

UIにアクセスし、ログインユーザに紐づくチャネルIDのデータしか表示・参照できないことを確認

WebRTCインスタンス ‐ AIインスタンス(サーマル)

インプット系統数 チャネルID
3

確認方法

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

同時アクセス・操作が可能なこと(○/×)

1 複数ログイン時、各ユーザ操
作・機能利用が相互に影響を及ぼすことなく適切に可能であることを確認○

2 複数ログイン時、各ユーザ操
作・機能利用が相互に影響を及ぼすことなく適切に可能であることを確認○

3 複数ログイン時、各ユーザ操
作・機能利用が相互に影響を及ぼすことなく適切に可能であることを確認○

検証結果より、データ保存処理の観点でも、考案した設計で問題なく動作出来ることを確認できた。システムのデータベース領域における、複数系統のデータが格納され、また、複数利用者
で同時にログインし、特定の画面操作を行い、WebUI で利用者ごとに閲覧可能なデータが切り替わ
り、マルチテナント構成が設計仕様に準拠した性能を発揮することが確認できた。

（3） 複数系統の並列処理性能確認
本検証の目的は、マルチテナント管理機能を用いて実装する鉄道車両監視 AI システムについて、考案した設計で複数系統での並列処理が問題なく行えるか、実フィールド含む複数拠点から143

同時にクラウドリソースにアクセスしたときの AI エンジンの処理性能を確認することである。AI
のシステム処理性能は、複数系統での同時処理において、各系統に一定の処理リソースを割り当てたとき、系統数に応じて変化しないことが期待される。これにより、SaaS 基盤として複数の利用者による同時利用が可能であることを確認する。
参考として、前述した複数拠点から同時にクラウドリソースにアクセスした場合の、AI のシス
テム処理性能（処理時間・fps）を表 3.4.2-6 に再掲する。

表 3.4.2-6 共通コア機能（マルチテナント管理機能等）の有効性検証結果（ラボ）【複数系統の確認：ラボでの事前検証（再掲）
】
拠点数
1
2

3

割当GPU枚数 インプット系統(/拠点)(チャネルID)

測定種別

16

1 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

23

0.28

2 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

14

0.13

1 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

13

0.27

2 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

12

0.14

3 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

10

0.38

4 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

10

0.14

1 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

7

0.28

2 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

5

0.16

3 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

6

0.39

4 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

5

0.16

5 4Kカメラ映像

WebRTCインスタンス ‐ AIインスタンス(台車)

7

0.25

6 サーマルカメラ映像

WebRTCインスタンス ‐ AIインスタンス(サーマル)

5

0.17

8

5

処理フレーム数
(fps)

測定区間

処理速度
(sec)

本結果はあくまでもすべて実映像の配信ではなく、録画映像のストリーミングによる検証であるため、実環境からの映像配信も含む実現性を以下にて確認を行った。SaaS 型システムを連動させる実証試験を通じて、複数系統の並列処理性能を検証するため、鉄道事業者の現地環境とラボ
環境を組み合わせた場合にも同様に AI のシステム処理性能を計測した。
本検証の結果を表 3.4.27 に示す。
表 3.4.2-7 共通コア機能（マルチテナント管理機能等）の有効性検証結果(現地＋ラボ)【複数系統の確認：現地（西鉄/京阪）＋ラボでの検証】
4K カメラ＠西鉄
No.

fps

開発拠点

現地

1

9

1系統

西鉄 1系統

0.24

2

8

1系統

西鉄 1系統

0.25

3

10

1系統

西鉄 1系統

0.24

4

11

1系統

西鉄 1系統

0.26

5

11

1系統

西鉄 1系統0.24

負荷1系統 西鉄1系統 平均

0.25

144

AI解析時間

No.

fps

開発拠点

現地

1

7

2系統

西鉄 1系統AI解析時間
0.26

2

7

2系統

西鉄 1系統

0.26

3

7

2系統

西鉄 1系統

0.26

4

7

2系統

西鉄 1系統

0.25

5

7

2系統

西鉄 1系統0.27

負荷2系統 西鉄1系統 平均0.26

サーマルカメラ＠西鉄
No.

fps

開発拠点

現地

AI解析時間111

1系統

西鉄 1系統

0.13

2

11

1系統

西鉄 1系統

0.13

3

13

1系統

西鉄 1系統

0.13

4

12

1系統

西鉄 1系統

0.13

5

13

1系統

西鉄 1系統0.13

負荷1系統 西鉄1系統 平均

0.13

No.

fps

開発拠点

現地

AI解析時間152系統

西鉄 1系統

0.17

2

4

2系統

西鉄 1系統

0.19

3

3

2系統

西鉄 1系統

0.19

4

4

2系統

西鉄 1系統

0.16

5

4

2系統

西鉄 1系統0.18

負荷2系統 西鉄1系統 平均0.18

4K カメラ＠京阪
No.

fps

開発拠点

1

9

1系統

京阪

1系統

0.38

2

9

1系統

京阪

1系統

0.39

3

9

1系統

京阪

1系統

0.38

4

9

1系統

京阪

1系統

0.36

5

9

京阪

1系統

0.36

京阪1系統

平均

0.37

1系統
負荷1系統

現地

AI解析時間

No.

fps

開発拠点

1

4

2系統

京阪

1系統

0.39

2

4

2系統

京阪

1系統

0.40

3

4

2系統

京阪

1系統

0.40

4

4

2系統

京阪

1系統

0.41

5

4

2系統

京阪

1系統

0.41

京阪1系統

平均

0.40

負荷2系統

現地

145

AI解析時間サーマルカメラ＠京阪
No.

fps

開発拠点

1

10

1系統

京阪

1系統

0.15

2

10

1系統

京阪

1系統

0.14

3

10

1系統

京阪

1系統

0.14

4

10

1系統

京阪

1系統

0.14

5

10

1系統

京阪

1系統

0.14

京阪1系統

平均

0.14

負荷1系統

現地

AI解析時間

No.

fps

開発拠点

1

5

2系統

京阪

1系統

0.17

2

5

2系統

京阪

1系統

0.17

3

5

2系統

京阪

1系統

0.16

4

5

2系統

京阪

1系統

0.16

5

5

京阪

1系統

0.17

京阪1系統

平均

0.17

2系統
負荷2系統

現地

AI解析時間

検証結果より、実環境でも複数系統での並列処理が考案した設計にて概ね想定通りに行えることが確認できた。AI のシステム処理性能に関して、複数系統での同時処理において、各系統に一定の処理リソースを割り当てたとき、系統数に応じて一律の解析時間を要することが確認でき、これにより、SaaS 基盤として複数の利用者による同時利用においても利用者ごとでの解析処理時間の差分が生じさせずに AI システムを共同利用できることが確認できた。

（4） レベル２検証まとめ
共通コア機能として検証したマルチテナント管理機能の検証結果をまとめる。
並列処理機能については、共有のリソースを各社に対して分散利用する設計としたことでリソースを１社占有で活用した際よりも処理性能は落ち込んだ点は机上の想定通りであった。
また、複数系統での同時処理においては、各系統に一定の処理リソースを割り当てたとき、系統数に応じて一律の解析時間となることが確認でき、事業者が SaaS 型ソリューションを利用する
際に必要となる複数系統での同時並列処理が想定通りに動作することが確認できた。
データ格納領域の定義についても、複数ユーザのデータ格納領域を新規に定義して独立的に管理する機能等を搭載することで、各社で独立したデータ保管領域をもち、それらをユーザ ID などの利用者を判別する個社判別情報と紐づけを行いデータの入出力を行うことでシステム共同利用時においても利用者ごとのデータ保存の独立性を担保可能であることを確認できた。
アプリケーション処理のリソース分散設計や並列処理での同時利用、データの独立性の担保の手法については、「鉄道車両監視 AI システム」のみならず、分野横断的に多くのシステムでも転用可能な汎用技術として活用することが可能である。
今後の論点として、導入後の運用も見据えたマルチテナント管理手法としては、より効率的なリソース活用を行うために常時、クラウド基盤のリソースを過不足なく効率的に稼働させていく
こと、また、リソースに不足が見込まれる場合にはその予兆を検知し、柔軟にクラウド基盤のリ
146

ソースを提供し利用者のサービス利用を途絶えさせることなくサービスを継続させるように管理・計画を立案していく必要がある。

レベル３：AI コア機能関連の汎用性評価
ここでは「特化型汎用モデルの導入」「利用者による追加学習機能」に関する汎用性及び利用者負担の軽減度合いを検証する。
（表 3.4.3-1 参照）
利用者負担軽減効果については、3.4.4 項にてレベル毎の評価を取りまとめる。
表 3.4.3-1 AI コア機能関連の汎用性評価内容
評価項目

測定項目

特化型汎用モデルの導入

汎用性（他の AI システムへの適用可能性）があること（システム評価、アンケート）
・機能面
・運用面
・コスト面
利用者負担が軽減されること（机上検証、アンケート）・稼働・コスト・システム習熟度等

利用者による追加学習機能

汎用性（他の AI システムへの適用可能性）があること（システム（アノテーション支援機能等）

評価、アンケート）
・機能面
・運用面
・コスト面
利用者負担が軽減されること（机上検証、アンケート）・稼働・コスト・システム習熟度等

SaaS 型で AI ソリューションを提供するにあたり、AI を複数の利用者が同時に利用（共用）する場合は、以下の観点で慎重に取り扱う必要がある。
⚫

AI の運用観点

AI は、日々の追加学習プロセスなどアップデートやメンテナンスが必要であり、その作業にはシステムの一時停止が必要である。AI を複数の利用者が共用する場合、システムの一時停止が複147

数の利用者のサービスを停止し、利便性の低下につながる。また、不具合発生時のロールバックなどの処理手順が複雑化するなどの影響も想定される。
⚫

AI の機能観点

過年度実証では京急、西鉄の車庫での実証を行ったが、2 社のシステム利用環境（照度等）はか
なり異なり、同じ検出対象物でもそれぞれの利用者ごとに特化して AI を学習させる必要があった。これにより、微細な検知対象であってもより正確に検知することができる。もし、各社で共通化した学習データが混在した状況で AI を学習させると、各社の学習データが他社の AI 検知精度に影響を及ぼすこととなる。クオリティコントロール（QC）の観点から、AI は利用者ごとに特化した学習をさせることが望ましい。
上述の通り、AI 共用においては、運用面と性能面を両立するための検討が必要であり、本項においては、これらを踏まえた解決方法の検討や実現性及びその有用性について確認する。
「特化型汎用モデルの導入」
AI のモデルについては、ベースとなるモデル（汎用モデル）を用意し、利用者ごとに特化して学習させる「特化型汎用モデル」の方式を導入する。これにより、汎用的に AI モデルを活用しながらも、高い検知精度を実現することができる。
これまで、AI ディープラーニングのシステムは、その高い検知精度を得るために検知対象に特化したモデル構築・学習が必要とされた。そのため、一般的には複数利用者によるシステム共用は困難であり（後述、※補足１参照）、システム構築・運用の高コスト化（利用者負担の増大）につながっていた。
そこで、本事業では、共通的な汎用モデルを構築し、それを利用者ごとに特化して学習させる
ことで、高い検知精度と汎用性を実現したい。具体的には、汎用モデルを利用者ごとに学習させ、同一環境内で複数の AI エンジンを並列利用する設計を考案した。これにより利用者は、SaaS 型
でシステム共用しながらも、高い AI 検知性能を享受することができる。
（図 3.4.3-1 参照）

148

検知精度

各社領域

本事業
専用モデル

クラウド環境
A社

特化型
汎用モデル
解析

B社

✎
学習

解析

X社

✎
学習

解析

✎

特化型
汎⽤モデル

学習

利用者ごとに特化型の学習

✕

共通領域

汎用モデル

✎

学習

汎⽤モデル

汎用性

図 3.4.3-1 AI コア機能の工夫点：特化型汎用モデルの並列利用※補足１：AI ディープラーニングの学習について「学習」とは、学習用のデータ（検知対象の正解を示すデータ）基づき、多面的に特徴量を分解し、正否判定に係る数値的な重みを、システムを構成する数千〜数万のノードに自動反映していく作業である。これは、学習データ（正解データ）から逆算的にノードの数値（重み）を改正するため、バックプロパゲーション（逆伝搬）と呼ばれる典型的な学習プロセスである。
例えば、A 社の特徴量を学習することで、（指定しなければ）すべてのノードの数値が改正される。もし、同システムが B 社の専用モデルであった場合、B 社の専用で構築したシステムのノードの数値が改正されてしまうため、B 社の検知精度に影響を及ぼすことから、一般的に共同利用が困難となる。
「利用者による追加学習機能」
特化型汎用モデルに関して、利用者の都合にあわせた低コストな追加学習（チューニング）が可能となる。これにより、通常の汎用モデルでは実現不可能な、継続的な機能向上を見込んだ運用が可能となり、高機能な AI システムを汎用的に利用するために不可欠な機能である。
一般的に、AI ディープラーニングのシステムは、実運用を通じて定期的な改善プロセス（追加学習）を適用する。これにより、より AI 検知の誤りや漏れをなくし、より的確に対象を検知できるように性能を向上させていく。なお、追加学習は、一般的にシステム提供会社が行い、追加コストが必要となる。そのため、ユースケースに応じて、その頻度（サイクル）は年に０回〜多くても数回程度となることが多い。
本来は、利用者が、AI 検知の誤りや漏れに気づいた場合、すぐにでも学習データを生成して、追加学習させることが望ましい。しかし、学習データの生成や追加学習プロセスは、システム提供会社に依存することやコスト増の影響もあり、対応が後手に回ることが多い実情がある。
149

そこで、本事業では、利用者自身が、利用者の特化型モデルを追加学習できる機能を構築する。
これにより、SaaS 型システムの設計思想（利用者負担の軽減）に寄り添った、共同利用型 AI ソ
リューションを提供する。（図 3.4.3-2～図 3.4.3-4 参照））

図 3.4.3-2 アノテーション支援ツールによる成長性のある AI のイメージ(再掲)

図 3.4.3-3 アノテーション支援ツール利用による追加学習 AI モデルの構築フロー

図 3.4.3-4 アノテーション支援ツール利用による検出動作の改善イメージ150

（1） 「特化型汎用モデルの導入」に関する検証
本検証の目的は、共用における運用面、機能面での課題を解消すべく本事業にて考案した「特化型汎用モデル」が正常に動作できるか、正常動作した上で性能に影響はないか等を確認し、AIを共用する上での必要機能となりうるかを確認することである。
汎用モデルをベースに利用者に特化して学習（チューニング）する「特化型汎用モデル」を導入することで、汎用的に AI モデルを活用しながらも、検知精度も上げられることも確認する。
そのために、過年度検証を行った、複数社の教師データが学習済みの「混濁モデル」と特化型
汎用モデルで検知性能を比較した。
（表 3.4.3-2 参照）

表 3.4.3-2 実証で利用したモデルの定義

まず、新たに構築したモデル（特化型汎用モデル）が正常に動作することを、ラボ環境で確認する。その際に併せて、過年度構築したモデル（混濁モデル）との差分も確認を行う。
本検証の評価項目として、事業者毎に特化型汎用モデルとしてモデルを分岐し、正常動作でき
るかとともに、混濁モデル、特化型汎用モデルの両モデルに対する AI の検知性能（検出率・網羅率）を計測した。
検知対象ごとのパラメータについては、下記の通り。（No4 と同様）


クラック：



収容函のハンドル開閉：角度（正常/異常）

ブレーキパッドの厚さ：（すり減り度合いを計測し、異常値を検出）



車軸の温度異常：（一部の車軸温度を上昇させ、異常値を検出）

方向（タテ・ヨコ）幅（0.1 / 0.2 / 1.0 / 2.0mm）長さ（20 / 60 / 80cm）

鉄道車両の走行速度（5km/h , 10km/h）に応じて、上記のパラメータを網羅した映像を用いて測定を実施した。
【検証結果】
本検証結果を表 3.4.3-3～表 3.4.3-11 に示す。

151

表 3.4.3-3 混濁モデルの評価結果（疑似き裂）

走行速度(km)

向き 平均 / 合計 / 検出率

5km

垂直

92.3%

66.7%

水平

95.8%

63.9%

94.0%

65.3%

垂直

100.0%

47.2%

水平

55.9%

52.8%

10km 集計

70.6%

50.0%

混濁モデル 集計

82.2%

57.6%

5km 集計10km

平均 / 合計 / 網羅率

表 3.4.3-4 混濁モデルの評価結果（収容函ハンドルの開閉異常）

走行速度(km)
5km

補足

合計 / 検出率 合計 / 網羅率

異常

69%

100%

正常

82%

100%

76%

100%

異常

69%

100%

正常

84%

100%

10km 集計

77%100%

混濁モデル 集計

76%

100%

5km 集計10km

152

表 3.4.3-5 混濁モデルの評価結果（ブレーキパッドすり減り）

速度(km)
5km

補足

合計 / 検出率 合計 / 網羅率

交換対象

100%

100%

正常

90%

100%

92%

100%

交換対象

100%

100%

正常

87%

100%

10km 集計

89%

100%

混濁モデル 集計

90%

100%

5km 集計10km

153

表 3.4.3-6 混濁モデルの評価結果（車軸の温度異常）
混濁モデル
検出対象
走行速度

検出率

網羅率

5km

100%

100%

10km

100%

100%

表 3.4.3-7 特化型汎用モデルの評価結果（疑似き裂）
走行速度(km)

向き 平均 / 合計 / 検出率

5km

垂直

92.6%

69.4%

水平

96.2%

69.4%

94.3%

69.4%

垂直

100.0%

50.0%

水平

52.8%

52.8%

10km 集計

68.5%

51.4%

特化型汎用モデル 集計

81.3%

60.4%

5km 集計10km

154

平均 / 合計 / 網羅率

表 3.4.3-8 特化型汎用モデルの評価結果（収容函ハンドルの開閉異常）
走行速度(km)
5km

補足

合計 / 検出率 合計 / 網羅率

異常

69%

100%

正常

82%

100%

76%

100%

異常

69%

100%

正常

84%

100%

10km 集計

77%

100%

特化型汎用モデル 集計

76%

100%

5km 集計10km

表 3.4.3-9 特化型汎用モデルの評価結果（ブレーキパッドすり減り）

速度(km)
5km

補足

合計 / 検出率 合計 / 網羅率

交換対象

100%

100%

正常

90%

100%

92%

100%

交換対象

100%

100%

正常

87%

100%

10km 集計

89%

100%

特化型汎用モデル 集計

90%

100%

5km 集計10km

155表 3.4.3-10 特化型汎用モデルの評価結果（車軸の温度異常）
特化型汎用モデル
検出対象
検出率
走行速度

網羅率

5km

100%

100%

10km

100%

100%

表 3.4.3-11 混濁モデルと特化型汎用モデルの比較検証結果
モデル

混濁

特化型汎用

混濁

特化型汎用

混濁

特化型汎用

混濁

特化型汎用

検知
対象物
ク
ラ
ッ
ク

ハ
ン
ド
ル

ブ
レ
ー
キ
パ
ッ
ド
車
軸
温
度
上
昇

検出率

網羅率

82%

57%

81%

60%

76%

100%

76%

100%

90%

100%

90%

100%

100%

100%

100%

100%

この結果から、考案した「汎用特化型モデル」は、問題なく動作し、検知が行えていることが確認できた。また、鉄道事業者 2 社（西鉄、京急）のデータを学習した混濁モデルと鉄道事業者
1 社（西鉄）のデータを学習した特化型汎用モデルにおいて、西鉄車両映像に対してそれぞれ AI
解析を行った際の検出率及び網羅率は、特化型汎用モデルのほうがクラック検知において若干良いことが確認できた。その他、検知対象物での比較では差異が見られなかった。
次に、ラボ環境ではなく、複数の鉄道事業者の現地環境からリアルタイムで伝送される映像においても問題なく検出ができるかを確認する。その際に併せて、過年度構築したモデル（混濁モデル）との差分も確認を行う。

156

検証内容としては、両モデルに対する AI の検知性能（検出率・網羅率）を計測した。
検知対象ごとのパラメータについては、下記の通り。


クラック：



収容函のハンドル開閉：角度（正常/異常）

ブレーキパッドの厚さ：（すり減り度合いを計測し、異常値を検出）



車軸の温度異常：（一部の車軸温度を上昇させ、異常値を検出）

方向（タテ・ヨコ）幅（0.1 / 0.2 / 1.0 / 2.0mm）長さ（20 / 60 / 80cm）

鉄道車両の走行速度（5km/h , 10km/h）に応じて、上記のパラメータを網羅した映像を現地で取得し測定を実施した。
本検証結果を表 3.4.3-12～表 3.4.3-19 に示す。

表 3.4.3-12 西鉄環境における特化型汎用モデルの評価結果（疑似き裂）
走行速度(km)

向き 平均 / 合計 / 検出率

5km

垂直

69.2%

50.0%

水平

88.9%

44.4%

77.3%

47.2%

垂直

73.9%

47.2%

水平

92.9%

36.1%

10km 集計

81.1%

41.7%

特化型汎用モデル(西鉄) 集計

79.0%

44.4%

5km 集計10km

157

平均 / 合計 / 網羅率

表 3.4.3-13 西鉄環境における特化型汎用モデルの評価結果（収容函ハンドルの開閉異常）

走行速度(km)
5km

補足

合計 / 検出率 合計 / 網羅率

異常

100%

100%

正常

100%

100%

100%

100%

異常

100%

100%

正常

100%

100%

10km 集計

100%

100%

特化型汎用モデル(西鉄) 集計

100%

100%

5km 集計10km

表 3.4.3-14 西鉄環境における特化型汎用モデルの評価結果（ブレーキパッドすり減り）
速度(km)
5km

補足

合計 / 検出率 合計 / 網羅率

交換対象

100%

100%

正常

88%

100%

92%

100%

交換対象

100%

100%

正常

83%

100%

10km 集計

89%

100%

特化型汎用モデル(西鉄) 集計

90%

100%

5km 集計10km

158

表 3.4.3-15 西鉄環境における特化型汎用モデルの評価結果（車軸の温度異常）
特 化 型 汎 用 モ デ ル (西 鉄 )
検出対象
検出率
網羅率
走行速度
5km

100%

100%

10km

100%

100%

表 3.4.3-16 京阪環境における特化型汎用モデルの評価結果（疑似き裂）
走行速度(km)

向き 平均 / 合計 / 検出率

5km

垂直

56.3%

水平

100.0%

52.8%

72.5%

51.4%

85.7%

33.3%

5km 集計10km

垂直
水平

平均 / 合計 / 網羅率
50.0%

94.4%

47.2%

10km 集計

90.6%

40.3%

特化型汎用モデル(京阪) 集計

79.5%

45.8%

表 3.4.3-17 京阪環境における特化型汎用モデルの評価結果（収容函ハンドルの開閉異常）

走行速度(km)
5km

補足

合計 / 検出率 合計 / 網羅率

異常

100%

100%

正常

100%

100%

100%

100%

異常

100%

100%

正常

100%

100%

10km 集計

100%

100%

特化型汎用モデル(京阪) 集計

100%

100%

5km 集計10km

159

表 3.4.3-18 京阪環境における特化型汎用モデルの評価結果（ブレーキパッドすり減り）

速度(km)

補足

5km

合計 / 検出率 合計 / 網羅率

交換対象

100%

100%

正常

84%

100%

85%

100%

交換対象

100%

100%

正常

82%

100%

10km 集計

83%

100%

特化型汎用モデル(京阪) 集計

84%

100%

5km 集計10km

表 3.4.3-19 京阪環境における特化型汎用モデルの評価結果（車軸の温度異常）
特 化 型 汎 用 モ デ ル (京 阪 )
検出対象
検出率
網羅率
走行速度
5km

100%

100%

10km

100%

100%

160

本結果より、特化型汎用モデルを利用することで、複数の事業者の環境下から実際に伝送される車両映像を検知出来ることを確認できた。なお、検知対象物ごとの検知性能の差異として、ハンドルやブレーキパッドのような大きく、かつ、形状が類似の「汎用的な物体」については、追加学習前の状態でもある程度検知が出来ており、アノテーション時の参考とすることも出来た。
今回、京阪車両のブレーキパッドは人の検査でチェックする箇所がカメラの画角からは隠れている為、すり減り具合の検知が出来ないという懸念があったが、検証結果では西鉄同様の精度となった。(AI 解析を行った解析画像においてブレーキパッドが一部認識できる部分において摩耗の影響があり、AI による判断が可能であった。)
一般に、教師データの量や多様性に比例してモデルの精度が向上していくことが知られているが、特化型汎用モデルは混濁モデルに対して教師データが少ないにもかかわらず同等以上の精度となった。よって、他事業者の学習データを追加することによる精度の向上は示せず、特化型汎用モデルによる運用の実現可能性が期待される。
なお、一部き裂（クラック(特に細いもの)）等に若干の検知性能影響が本データ上は見られるが、ラボ環境（録画映像）では問題なく検出出来ていることから、モデルの影響ではなく、実証
当日の天候条件やカメラの設定等、外部要因に大きく左右されたことによる差分と考えられる。
この観点については、後述する「アノテーション支援機能」等を利用し、利用者側で追加学習を継続的に行うことで外部要因の影響を軽減できると想定される。
また、補足として上記検証の追加学習は同一人員にて行っており、混濁モデル構築時のデータ
品質は事業者間にて差が少なくなるよう努めた。実際に複数事業者で同一モデルへ学習を行った
場合、発生しうる事象として低品質な教師データによる学習等が考えられるが、学習の癖や低品
質な教師データによる学習が与える影響を実際に確認するため、以下についての検証も行った。
・追加検証パターン
混濁モデルを想定した際、複数事業者の教師データが混在することになるため、リスクとして特定事業者にとって意図せず低品質となる教師データが学習されてしまう可能性がある。その場合、特定事業者における混濁モデルの AI 検知性能は悪化すると考えられるため、この仮説が正しいか検証する。
・検証方法
混濁モデルに対し意図的に低品質な教師データを学習させた「混濁モデル(低品質)」を構築
し、特化型汎用モデルと検知性能を比較する。
低品質な教師データを作成する際のアノテーション例を図 3.4.3-5 に示す。

161

対象物に対して広く囲む

対象物と枠がずれている

クラックではない所に付けている

図 3.4.3-5 低品質なアノテーション例
・評価方法
評価指標には検出率、網羅率を用い、「車両の走行速度:5km」「タテクラック」の場合を取り上げ評価する。
・評価結果

表 3.4.3-20 特化型汎用モデルと混濁モデル(低品質)の AI 検知性能の比較結果

162

No.

変数3

備考

特化型汎用モデル

混濁モデル(低品質)

検出率

検出率

対象物

変数1

変数2

1

5 クラック

方向 タテ

幅 0.1mm

長さ 20mm 西鉄のみ

100

100

2

5 クラック

方向 タテ

幅 0.1mm

長さ 60mm 西鉄のみ

100

100 -

3

5 クラック

方向 タテ

幅 0.1mm

長さ 80mm 西鉄のみ

60

100

4

5 クラック

方向 タテ

幅 0.2mm

長さ 20mm 西鉄のみ

5

5 クラック

方向 タテ

幅 0.2mm

長さ 60mm 西鉄のみ

100

67

6

5 クラック

方向 タテ

幅 0.2mm

長さ 80mm 西鉄のみ

100

100 -

7

5 クラック

方向 タテ

幅 1mm

長さ 20mm 西鉄のみ

8

5 クラック

方向 タテ

幅 1mm

長さ 60mm 西鉄のみ

100

100

0

0

9

5 クラック

方向 タテ

幅 1mm

長さ 80mm 西鉄のみ

100

100

100

66

10

5 クラック

方向 タテ

幅 2mm

長さ 20mm 西鉄のみ

11

5 クラック

方向 タテ

幅 2mm

長さ 60mm 西鉄のみ

100

67

100

33

12

5 クラック

方向 タテ

幅 2mm

長さ 80mm 西鉄のみ

100

33

100

33

走行速度 (km/h)

網羅率

-

網羅率
0

0

100

33

100

33

0

0-

-

0
0

0-

-

0

0-

0

表 3.4.3-20 に示す簡易検証の結果より、混濁モデル(低品質)の方は全体的に検出率、網羅率ともに下がってしまうことが確認できた。このことから、SaaS 型構成で事業者が共通のモデルを利用した場合の懸念については、実際に発生しうることが確認できた。
もう１つの補足検証として、学習の癖や低品質な教師データによる学習が与える影響がない状
況で、令和２年度の京急、今年度の西鉄と京阪の２事業者を合わせた３事業者の混濁モデルによる AI 検知性能の検証を行った。
・追加検証パターン
混濁モデルを想定した際、複数事業者の教師データが混在することになるため、２事業者の混濁モデル、３事業者の混濁モデル、１事業者の特化型汎用モデルとの間で AI 検知性能の比較を行う。事業者数が増えることによる混濁モデルの AI 検知性能の変化と特化型汎用モデルとの AI 検
知性能との差を確認する。
・検証方法
２事業者の混濁モデルに対し３事業者目の教師データを学習させた「混濁モデル」を構築し、特化型汎用モデルと AI 検知性能を比較する。（表 3.4.3-21 参照）

表 3.4.3-21 補足検証で利用したモデルの定義

163

表 3.4.3-22 特化型汎用モデルと混濁モデル(２事業者、３事業者)の AI 検知性能の比較結果
No.

混濁モデル(R3)
西鉄、京急

特化型汎用モデル(R4)
西鉄

3事業者混濁モデル
西鉄、京阪、京急

検出率

検出率

対象物

変数1

変数2

変数3

備考

1

5 クラック

方向 タテ

幅 0.1mm

長さ 20mm

西鉄のみ

100%

100%

100%

100%

100%

100%

2

5 クラック

方向 タテ

幅 0.1mm

長さ 60mm

西鉄のみ

100%

100%

100%

100%

100%

100%

3

5 クラック

方向 タテ

幅 0.1mm

長さ 80mm

西鉄のみ

60%

100%

60%

100%

60%

100%

4

5 クラック

方向 タテ

幅 0.2mm

長さ 20mm

西鉄のみ

0%

0%

0%

0%

0%

0%

5

5 クラック

方向 タテ

幅 0.2mm

長さ 60mm

西鉄のみ

100%

67%

100%

100%

100%

67%

6

5 クラック

方向 タテ

幅 0.2mm

長さ 80mm

西鉄のみ

100%

100%

100%

100%

100%

100%

7

5 クラック

方向 タテ

幅 1mm

長さ 20mm

西鉄のみ

0%

0%

0%

0%

0%

0%

8

5 クラック

方向 タテ

幅 1mm

長さ 60mm

西鉄のみ

100%

100%

100%

100%

100%

100%
100%

走行速度 (km/h)

検出率

網羅率

網羅率

網羅率

9

5 クラック

方向 タテ

幅 1mm

長さ 80mm

西鉄のみ

100%

100%

100%

100%

100%

10

5 クラック

方向 タテ

幅 2mm

長さ 20mm

西鉄のみ

0%

0%

0%

0%

0%

0%

11

5 クラック

方向 タテ

幅 2mm

長さ 60mm

西鉄のみ

100%

100%

100%

100%

100%

100%

12

5 クラック

方向 タテ

幅 2mm

長さ 80mm

西鉄のみ
平均

100%
72%

33%
67%

100%
72%

33%
69%

100%
72%

33%
67%

表 3.4.3-22 に示す簡易検証の結果より、今回の検証では、事業者が２社の混濁モデルと事業者が３社の混濁モデルとの間で AI 検知性能の差は確認できず、特化型汎用モデルの方は事業者が２社の混濁モデル及び３社の混濁モデルよりも若干 AI 検知性能が高いことが確認できた。
今回の簡易検証では事業者が２社の混濁モデルと事業者が３社の混濁モデルとの間で AI 検知
性能の差は確認できなかったが、SaaS 型構成で事業者が共通のモデルを利用する事業者の数が増えるに従い、AI 検知性能が少しずつ下がっていくのではないかと推測される。特化型汎用モデルの方は事業者が２社の混濁モデル及び３社の混濁モデルよりも若干 AI 検知性能が高いことが確認できており、SaaS 型構成で共通のモデルを利用する事業者の数が増えるに従い、この特化型汎用モデルの優位性はさらに高まっていくものと想定される。

（2） 「利用者による追加学習機能」に関する検証◆追加学習機能・アノテーション支援ツールの機能検証
本検証の目的は、利用者の負担軽減や AI システムの汎用性向上を実現するために考案した追加
学習機能・アノテーション支援ツールについて、各機能が設計通りに動作することを確認することである。
評価項目として、以下を測定した。（表 3.4.3-23 参照）
表 3.4.3-23 追加学習機能/特化型汎用モデルの有効性検証項目
評価項目

測定項目

アノテーション機能確認

以下機能の処理時間
・教師データ作成
・AI モデル構築
・AI エンジンにモデルを反映

マルチテナント時の処理性能確認

以下機能の処理時間
・教師データ作成
・AI モデル構築
・AI エンジンにモデルを反映

164

マルチテナント時の DB 確認

アノテーション支援ツールの生成データが、ロ
グインユーザに紐づき DB で管理されていること。

マルチテナント時の UI 確認

複数ユーザの同時アクセス、及び WebUI 上の操作が可能であること。

マルチテナント時の同時アクセス・操作

ログインユーザは自身の ID に紐づく情報のみ表

性確認示されること。

パラメータについては、下記の通り。


機能 ：教師データ作成 / AI モデル構築 / AI エンジンにモデルを反映GPU 割当リソース（GPU カード枚数）：0（教師データ作成） / 1（AI モデル構築） /0（AI エンジンにモデルを反映）


データ枚数



同時使用ユーザ：50※機能「AI エンジンにモデルを反映」は除く：3

上記パラメータをもとに、追加学習機能・アノテーション支援ツールの各機能が設計どおり動作することを確認した。
本検証の結果を表 3.4.3-24 に示す。

表 3.4.3-24 追加学習機能・アノテーション支援ツールの機能検証結果【アノテーション機能確認】
確認

機能

測定区間

GPU割当リソース(GPUカード枚数)

データ枚数

処理時間
(sec)

アノテーション

教師データ作成

PC Webインスタンス ‐ AIインスタンス(アノテーション)

0枚

50枚

50分前後

機能確認

AIモデル構築

PC Webインスタンス ‐ AIインスタンス(アノテーション)

1枚

50枚

9分30秒

AIエンジンにモデルを反映

PC Webインスタンス ‐ AIインスタンス(アノテーション)

0枚

-

10sec

【マルチテナント時の処理性能確認】
確認
マルチテナント

拠点数
3

インプット系統(チャネルID)

測定区間

データ枚数

処理時間
(sec)

1 教師データ作成

PC Webインスタンス ‐ AIインスタンス(アノテーション)

50枚

50分前後

AIモデル構築

PC Webインスタンス ‐ AIインスタンス(アノテーション)

50枚

9分30秒

機能

AIモデル構築エンジンに PC Webインスタンス ‐ AIインスタンス(アノテーション)
モデルを反映10sec

2 教師データ作成

PC Webインスタンス ‐ AIインスタンス(アノテーション)

50枚

50分前後

AIモデル構築

PC Webインスタンス ‐ AIインスタンス(アノテーション)

50枚

9分30秒

AIモデル構築エンジンに PC Webインスタンス ‐ AIインスタンス(アノテーション)
モデルを反映10sec

3 教師データ作成

PC Webインスタンス ‐ AIインスタンス(アノテーション)

50枚

50分前後

AIモデル構築

PC Webインスタンス ‐ AIインスタンス(アノテーション)

50枚

9分30秒

AIモデル構築エンジンに PC Webインスタンス ‐ AIインスタンス(アノテーション)
モデルを反映165

10sec

【マルチテナント時の DB 確認】

確認

拠点数

インプット系統(チャネルID)3

機能
1 ・教師データ作成

測定区間

確認方法

PC Webインスタンス ‐ AIインスタンス(アノテーション)

DBにアクセスし、チャネ
ルID単位で所定のDBディレクトリにデータが格納されていることを確認 〇PC Webインスタンス ‐ AIインスタンス(アノテーション)

DBにアクセスし、チャネ
ルID単位で所定のDBディレクトリにデータが格納されていることを確認 〇PC Webインスタンス ‐ AIインスタンス(アノテーション)

DBにアクセスし、チャネ
ルID単位で所定のDBディレクトリにデータが格納されていることを確認 〇・AIモデル構築
・AIモデル構築エンジンにモデルを反映マルチテナント

2 ・教師データ作成
・AIモデル構築
・AIモデル構築エンジンにモデルを反映DB確認

3 ・教師データ作成

アノテーション支援
ツールの生成データが適切に所定のDB
ディレクトリに格納されていること(○/×)

・AIモデル構築
・AIモデル構築エンジンにモデルを反映【マルチテナント時の UI 確認】
確認

拠点数

インプット系統(チャネルID)

3

測定種別
1 ・教師データ作成

測定区間

確認方法

PC Webインスタンス ‐ AIインスタンス(アノテーション)

UIにアクセスし、ログイン
ユーザに紐づく情報しか表示・参照できないことを確認〇

PC Webインスタンス ‐ AIインスタンス(アノテーション)

UIにアクセスし、ログイン
ユーザに紐づく情報しか表示・参照できないことを確認〇

PC Webインスタンス ‐ AIインスタンス(アノテーション)

UIにアクセスし、ログイン
ユーザに紐づく情報しか表示・参照できないことを確認〇

・AIモデル構築
・AIモデル構築エンジンにモデルを反映マルチテナント

2 ・教師データ作成
・AIモデル構築
・AIモデル構築エンジンにモデルを反映

UI確認

3 ・教師データ作成

ログインユーザに紐づ
く情報しか表示されないこと(○/×)・AIモデル構築
・AIモデル構築エンジンにモデルを反映【マルチテナント時の同時アクセス・操作性確認】
確認

拠点数

ログインユーザID
3マルチテナント

確認方法

同時アクセス・操作が可能なこと(○/×)

複数ログイン時、各ユー
ザ操作・機能利用が相互に影響を及ぼすことなく適切に可能であることを
1 確認〇
複数ログイン時、各ユー
ザ操作・機能利用が相互に影響を及ぼすことなく適切に可能であることを
2 確認〇
複数ログイン時、各ユー
ザ操作・機能利用が相互に影響を及ぼすことなく適切に可能であることを
3 確認〇

検証結果より、追加学習機能・アノテーション支援ツールの各機能が設計通りに動作することが確認できた。１ユーザが操作した場合と複数ユーザが操作した場合で追加学習機能・アノテーション支援ツールの各機能にかかる処理時間がすべて同じであることが確認できた。また、各ユー
ザ固有のデータは DB 上分割して管理されることが確認できた。
◆追加学習機能・アノテーション支援ツールの UI/UX
本検証の目的は追加学習機能・アノテーション支援ツールの UI/UX が設計通りに実装されてい166

ることを確認することである。
検証内容は、実験環境としてクラウド上に SaaS 型構成のシステムを構築し、追加学習機能・アノテーション支援ツールにアクセスし、測定項目に沿って画面を操作した。これにより、利用者向けの画面構成や挙動、体感を評価する。（表 3.4.3-25 参照）

表 3.4.3-25 追加学習機能/アノテーション支援ツールの UI/UX 検証項目
評価項目

測定項目

画面レイアウト・文言・ボタンアクショ

設計通りであることン
画面遷移

設計通りであること

測定項目を評価するにあたり、追加学習機能/アノテーション支援ツールの設計内容を図 3.4.36 に示す。
【画面一覧】
画面一覧
機能
ログイン
データセット管理
アノテーション管理
モデル管理
ユーザ管理

内容
ログイン画面
データセット一覧画面
画像一覧画面アノテーション画面
モデル構築状況一覧画面
予測結果一覧画面
予測結果プレビュー画面
ユーザー一覧画面【画面遷移図】

図 3.4.3-6 追加学習機能・アノテーション支援ツールの設計内容
167

項番
1
2
3
4
5
6
7
8

本検証の結果を表 3.4.3-26 に示す。

表 3.4.3-26 追加学習機能・アノテーション支援ツールの UI/UX 検証結果
確認

対象UI

確認端末

アノテーションUI/UX確認

アノテーション

閲覧用PC

レイアウトが設計どおりであること(○/×)

文言やタイトルが設計ど その他
おりであること(○/×)

〇

〇

〇

検証結果より、アノテーション支援ツールの利用者向けの画面構成や挙動、体感が設計どおりであることが確認できた。画面構成や各画面及びボタン、アイコンの文言、ボタンアクション時の挙動（画面遷移やサーバ内データ格納等の処理）が設計通りであることが確認できた。
◆追加学習機能・アノテーション支援ツールの学習効率
本検証の目的は、追加学習機能・アノテーション支援ツールによる追加学習、AI モデル生成が実現できることを確認することである。
検証内容として、「鉄道車両監視 AI システム」において従来、AI の検出対象物として検出する
べきと利用者が設定した事物において検出を見逃していた検出対象物を追加学習させ、AI 検知性能の向上傾向を確認し、これまでの開発会社の技術者による学習方法と比較検証した（表 3.4.327 参照）

表 3.4.3-27 追加学習機能・アノテーション支援ツールの学習効率検証項目
評価項目

測定項目

モデル性能

AP 値（Average Precision）※※AP 値
AP 値は、物体検出 AI モデルを評価する際に一般的に活用される指標で、アノテーション画像
168

(正解画像)と AI モデル予測結果を比較し、予測結果がどの程度一致しているかを表すものである。 0~1 の範囲を取り数字が高いと精度が高いことを示します。高精度/低精度の目安はケースによる為,既存モデルとの比較での評価が推奨される。

本検証結果を表 3.4.3-28 に示す。
表 3.4.3-28 追加学習機能・アノテーション支援ツールの学習効率検証結果
業務プロセス

アノテーション支援ツールを使用する際の機能
測定区間

教師データ作成

教師データ作成

PC Webインスタンス ‐ AIインスタンス(アノテーション)

AIモデル構築

AIモデル構築

PC Webインスタンス ‐ AIインスタンス(アノテーション)

AIエンジンにモデルを反映

AIエンジンにモデルを反映

PC Webインスタンス ‐ AIインスタンス(アノテーション)

学習データ枚数

所要時間(ツール利用時)

AIモデル性能(AP値)(ツー 所要時間(ツール未利用
ル利用時)
時)

100分前後(1枚辺り1分)

100

18分30秒AIモデル性能(AP値)(ツー
ル未利用時)

100分前後(1枚辺り1分)

0.67

10sec

約40分

0.68

10sec

アノテーション支援ツールを利用した疑似き裂の検出改善を行った場合での各プロセスの所要時間と、アノテーション支援ツールを使用せずに行った場合の所要時間の比較結果から、AI モデ
ル構築に要する時間はアノテーション支援ツールを利用した場のほうが半分以下となる結果とな
り、AP 値もほぼ同じで、モデル性能は同様の性能となることが確認できた。
検証結果より、「追加学習機能・アノテーション支援ツール」による追加学習、AI モデル生成が実現できることを確認できた。また、追加学習機能・アノテーション支援ツールを使った追加学
習による AI 検知性能がこれまでの AI 開発会社の専門家、有スキル者による学習方法と遜色がな
く、かつ、追加学習にかかる所要時間短縮も可能であったため、アノテーション支援ツールが AI
システムの追加学習に関する利用者の利便性向上に貢献できることが確認できた。
一定の学習データ枚数に対し、追加学習機能・アノテーション支援ツールを使った追加学習による AI 検知性能がこれまでの開発会社の技術者による学習方法とほぼ差異がないことが確認できた。
（AP 値の比較）。また、モデル学習（モデル構築）の所要時間は、技術者が従来通り実施した場合に対し本機能・ツール利用した場合は半分以下に削減されたことが確認できた。
◆追加学習機能・アノテーション支援ツールの有効性（利用者調査）
本検証の目的は運用時に実作業を行う利用者（鉄道事業者の現場作業者）が、アノテーション
支援ツールを用いて実際に追加学習を行うことができるかを確認することである。
検証として、鉄道事業者（西鉄、京阪）に事前に準備したマニュアルを用いてアノテーション
支援ツールの説明を行い、アノテーション支援ツールを使った追加学習操作を実施いただいた。
アンケート項目は、以下のとおり導入容易性、導入可能性、改善点を観点とする項目とした。
（表 3.4.3-29 参照）

169

表 3.4.3-29 追加学習機能・アノテーション支援ツールの有効性検証項目

アノテーション支援ツールに関し、アンケートを行い、アノテーション支援ツール利用による追加学習の有用性を確認した。
（図 3.4.3-7 参照）

170

図 3.4.3-7 アノテーション支援ツールに関するアンケート
鉄道事業者（西鉄、京阪）でのアノテーション支援ツールのマニュアルを使った説明を聞いていただき、アノテーション支援ツールを使った追加学習による AI 検知性能の向上のトライアルをしていただいた後のアンケート結果が示す通り、アノテーション支援ツールが AI システムの追加
学習に関する利用者の利便性向上貢献できるそうであることが確認できたとともに、機能改善等
様々なコメントもいただいた。以下で、「UI/UX の使いやすさ」「導入の可能性・期待値」「導入・運用に向けて」のそれぞれのカテゴリ別に詳述する。
◆追加学習機能・アノテーション支援ツールの UI/UX（利用者調査）
本検証の目的は、UI/UX の観点でツールが使いやすいこと、ならびに使いやすくするための改善点を確認することである。現地で追加学習機能・アノテーション支援ツールを利用した利用者（鉄道事業者）から、UI/UX に関するアンケートを通じてフィードバックを得ることで、追加学習機
能・アノテーション支援ツールに関する UI/UX 面の改善・要望や今後の導入に向けた課題などを確認した。
検証として、鉄道事業者（西鉄、京阪）に事前に準備したマニュアルを用いてアノテーション
支援ツールの説明を行い、アノテーション支援ツールを使った追加学習操作を実施いただいた。
なお、操作体験では実際の追加学習も行い、これまで検出できなかった対象物が検出可能になることも併せて確認いただいた。アンケート項目は、以下のとおりレイアウト・見た目、使用感、改善点の観点とする項目とした。
（表 3.4.3-30 参照）

171表 3.4.3-30 追加学習機能・アノテーション支援ツールの UI/UX（利用者調査）項目
評価項目

測定項目

レイアウト・見た目・タイトルやボタン文言・大きさ、配色、レイアウトは分かり
やすいか

使用感

・画面遷移やボタンのレスポンスはストレスないか
・メニューから目的の作業に移る導線は分かりやすいか

改善点

・改善点や要望はあるか

本検証の結果を表 3.4.3-31 に示す。
１．ユーザインターフェースの利便性
Q1．
「ユーザ管理」機能
【西鉄】

172

【京阪】

Q2．
「データセット管理」機能
【西鉄】

173

【京阪】

（フリーアンサー抜粋）
Q 上記を選択された理由・気になる点等についてご意見ください。
・ボタンやアノテーションタイプの選択表記は日本語にして欲しい。

Q3．
「アノテーション管理」機能
【西鉄】

174

【京阪】

（フリーアンサー抜粋）
Q 上記を選択された理由・気になる点等についてご意見ください。
・ 画面が荒く範囲選択が大変に感じた。
・ 拡大縮小やドラッグ等で、マウスの作業が手間なので写真をデスクトップ全体に表示できれば見た目も良くなり、作業しやすくなると思う。
・ 別の画像をアノテーションする場合に、都度アノテーションタイプを選択し直す手間が省けると操作性が良くなると感じた。

175

Q4．
「AI モデル管理」機能
【西鉄】

【京阪】

図 3.4.3-8 追加学習機能・アノテーション支援ツールの UI/UX に関する利用者
アンケート調査結果（西鉄、京阪）
176

アノテーション支援ツールの「UI/UX の使いやすさ」に関するアンケート結果を以下にまとめる。
UI については、画面レイアウトの見やすさや各アイコンが大きく操作しやすい点などが挙げられ、概ね問題なく利用できると評価いただいた。一方、現状だと同一の対象物の追加学習時に別の画像をアノテーションする際、都度アノテーションタイプの選択（「ポリゴンタイプ」を選択した後、”wheel”, “break pad”, “crack”, “handle”のいずれかを選択）する必要があるため改善してほしいという意見もあったためこれを改善することでより操作性の向上に期待できると考えられる。
マニュアルについては各鉄道事業者ともマニュアルを参考に操作可能であるといった意見が多かった。また、マニュアルを用いたアノテーション支援ツールの操作説明の実施後に、各鉄道事業者の代表者に実際に操作してもらったが、概ね問題なくマニュアル通りに作業可能であることを確認することができた。
以上より、アノテーション支援ツールの UI/UX が、実際に利用する鉄道事業者の現場作業員の観点からも使い勝手に問題はなく、運用できうるものであることが確認できた。
さらに、アノテーション支援ツールの「導入可能性・期待度」に関するアンケートを行った。

177

図 3.4.3-9 アノテーション支援ツールの導入可能性・期待度に関するアンケート

２．導入可能性・期待度について
【西鉄】

【京阪】

（フリーアンサー抜粋）
Q 上記を選択された理由・気になる点等についてご意見ください。
・今回対象検知物とした項目以外にも実作業にて点検箇所が多くある為、項目を適宜追加でき
れば作業効率化に期待できる。
・現場で頻繫に追加学習の実施は難しいため、追加学習作業を行う専任の担当者がいれば実現可能だと思う。

178

【西鉄】

【京阪】

（フリーアンサー抜粋）
Q 上記を選択された理由・気になる点等についてご意見ください。
・想定している以上に追加学習すれば効果は大きいと思うが、作業するには時間が必要。
・消耗品の減り等は日常的に確認しやすいため効果が期待できる。
【西鉄】

•

【京阪】

（フリーアンサー抜粋）

Q 上記を選択された理由・気になる点等についてご意見ください。
・ブレーキパッドや収納箱のハンドルについては現状の精度でも十分利用可能と思われる。
サーマルカメラによる確認については他の部位（モータなどの回転機器）にも活用できそうである。
・検査項目を事業者側で追加できる仕組みが望ましい。
・事前準備、故障再現して追加学習するには時間と人がどれだけ必要か未知数なため、どちらともいえない。
・追加学習させるサンプルが少ない枚数で対応できるようになればよい。
以下に、アノテーション支援ツールの「導入可能性・期待値」についてのアンケート結果をまとめる。
導入可能性については、特に追加学習後に、これまで検出出来ていなかった特徴が異なるクラッ
クを検知出来るようになった結果から効果的であり、導入可能性があるという評価であった。
導入した場合の期待値としては、車両点検の作業効率化が挙げられた。実際に車両点検の際は、
今回検知対象物とした項目以外にも多く点検箇所がある、かつ、各車両の台車ごとに点検箇所が179異なる為、アノテーション支援ツールを用いることにより、より日常の車両点検の効率化が図れることが想定され、そのためにも検知対象物の対応品目を追加する機能拡張が必要とされていることがわかった。
一方、アノテーション支援ツールを使った追加学習を導入するには、現在の仕様では、ある程度の学習データ枚数の手動による１枚ごとの登録が必要になることから、登録作業実施者の負担軽減のためにもより少ない枚数で十分検知ができるようにしてほしいといった意見も挙がった。
そのため、導入後の負荷軽減が図れるように学習データの枚数を少なくするなどの対応も必要であることがわかった。
以上のように、アノテーション支援ツールの効果としては概ね一定の満足度はあり、実導入の可能性や期待値が高いものの、目視での点検業務も含めた点検作業全体の作業フローを含めて鉄道事業者で再検討し、その一部を自動化するためのパーツとして本ツールを位置づけ、必要とされる機能を、鉄道事業者と連携して検討していく必要性が有ることがわかった。
最後に、アノテーション支援ツールの「導入・運用に向けて」に関するアンケートを行った。
３．導入・運用に向けて
【西鉄】

【京阪】

（フリーアンサー抜粋）
Q 上記を選択された理由・気になる点等についてご意見ください。
・追加学習のための画像を取集するのが大変だと感じる。
・導入する際の条件（カメラ画角・天気・気温・明暗）などが多いため、カメラ設置場所について検討が必要である。
・実際に台車等でき裂を発見した場合、何度も車両を走行させることはしないので、走行しての画像ではなく静止状態の画像で追加ができることが望ましい。

180

【西鉄】

【京阪】

【西鉄】

【京阪】

（フリーアンサー抜粋）
Q 上記を選択された理由・気になる点等についてご意見ください。
・マニュアルを見ながら作業回数をこなさないと覚えられないと思う。
・操作方法のレクチャーも必要だが、モデルの精度をどうやって高めていのかシステムの概要も含めて理解するにはある程度の時間を要す。
Q 今回のレクチャー内容及び使用したマニュアル等を参考にして、今後現場の他メンバーに対するレクチャーを実施していただくことにより、本ツール活用スキルの横展開をしていくことは可能だと感じますか？
・マニュアルを活用すれば可能だと思う。
・通常業務と併用しなければ習熟しなければならないため横展開には時間が掛かりそう。

181

Q 本ツールの導入・運用により、皆様に AI モデルを随時更新していただき、車両基地以外の車両状態もまとめて学習させることによって、車両検査作業の効率化につなげていくことは可能だと感じますか？
・全く同じ台車形式であれば可能だと思うが、それ以外の形式では非常に難しいと思われる。一方で、車両メーカーが同じであれば、各社多少の違いはあっても、各社の最新の台車形式を採用していることから、可能だと思われる。
・初期学習の作業が大変そうなことを除くと、最終的には作業効率化を図れることが期待できそう。
「導入・運用に向けて」に関するアンケート結果を以下にまとめる。
運用を想定した質問についてはマニュアルを用いることで現場での運用及び作業者へのレクチャーが可能であるという意見が多く挙げられたが、前述の結果同様に運用を想定すると少ない
データ枚数で学習ができることが要望として挙げられている。また、撮影データに関しては車両走
行時の画像ではなく静止状態の画像でアノテーション作業を実施できれば、撮影のために車両走行を都度実施せずにより効率よく運用ができるのではないかという意見もあった。
その他、今後追加学習させたい検知対象物についての集計結果を表 3.4.3-32 に、また、導入にあたり障壁となる可能性のある要素についての集計結果を表 3.4.3-33 に示す。

表 3.4.3-32 今後追加学習させたい検知対象物についての集計
検知対象

選定理由

パンタグラフ摺板

・消耗品として毎回点検する箇所であるため

回転機系やモーター等の温度検知

・他機器と比較し、劣化や故障の早期発見につながるラッチやフック、コックのかけ忘れ検知

・点検時の際、戻し忘れを防ぐ為

落下物検知

・部品の落下による車両点検の効率化

隙間調整

・目視にてブレーキパッドと車輪の隙間確認を実施しているため

車輪・車輪の偏摩耗を振動計などで測定し知らせることで異常振動、異音を防止する

ターンバックルの定位・点検時に触るので戻し忘れを防ぐ為

排障器の傾き・障害物と接触があったことの確認が可能

182

表 3.4.3-33 導入にあたり障壁となる可能性のある要素についての集計
要素

理由

機材設置場所

・検車庫の道が狭くカメラを複数台置くと作業に支障をきたす場合がある
・屋根上や床下の点検ができるカメラを設置するのが難しい

コスト

・初期導入費用ならびに維持管理費
・費用対効果が未知数

撮影データの保管

・すべての車両となると膨大なデータを保管しなければならなくなるので管理が大変

現場運用

・運用していくにあたりシステムを理解した技術者の育成が必要

追加学習・車系、台車形式毎にデータ収集する必要があるため撮影及び作業量が多い【検証結果】
本検証の結果より、アノテーション支援ツールの導入可能性があり、導入への期待値も高いことを確認した。一方、具体導入に向けてはアンケート結果が示す通り課題も挙げられ、挙げられた課題に対し、今後改善に向け対策を検討していく必要があるが、以下に検討例を示す。
・ユーザインターフェースの操作性の改善。および、利用者へのトレーニング方法やマニュアル
類のコンテンツの拡充によるユーザへの導入容易性を高める施策が必要である。
・より検査頻度が多い検知対象物へのツール適用を期待される声が鉄道事業者より上がっている
ため検知対象物の対応品目を追加する機能拡張の検討が必要である。
・学習データの収集については利用者によりデータを取得する手間が大きいため、より学習デー
タの枚数を抑える方式や現地の撮影データのアセスメントを行うサポート機能などの対応も望まれる。
上記記載の通り、今後具体導入に向けては利用者（鉄道事業者）が利用しやすいツールへと改善していく必要があることが確認できた。
◆追加学習機能・アノテーション支援ツールの学習効率（利用者調査）
本検証の目的は、鉄道事業者が追加学習機能・アノテーション支援ツールを用いて、精度を担保したモデルを生成できるか、ならびにそれに係る負荷を確認することである。追加学習する際、そのために、ツール操作にかかる時間等を確認し、学習後の AI モデルを活用して解析性能を評価し、運用上問題ないかどうかを確認する。
検証内容は、鉄道事業者（西鉄、京阪）にアノテーション支援ツールのマニュアルを使った説
明を聞いていただき、アノテーション支援ツールを使った追加学習による AI 検知性能の向上のト
ライアルを実施いただいた。また以下項目にて評価を行った。

183

表 3.4.3-34 追加学習機能・アノテーション支援ツールの学習効率検証項目
評価項目

測定項目

実稼働時間

利用者がツール操作している時間

AI モデル性能

鉄道事象者と AI 専門事業者がそれぞれ作成する AI モデルの・AP 値（Average Precision）【検証結果】
本検証の結果を表 3.4.3-35 に示す。

表 3.4.3-35 追加学習機能・アノテーション支援ツールの学習効率検証結果
追加学習：１回目
実施者
鉄道事業者

機能

学習データ枚数

教師データ作成

AIモデル構築所要時間

モデル性能（AP値）

200分前後(1枚辺り2分)-

18分30秒

0.67

10sec

-

100枚

AIエンジンにモデ
ルを反映

本検証の結果より、アノテーション支援ツールを用いて追加学習をさせたとしても、一定のモデル性能は担保できることがわかった。本来 AI 開発事業者が開発ツールを用いて行う追加学習作
業を、所要時間を要するが利用者が行うことができるのは、システムの実運用を行う上で内製化によるコスト削減効果が期待できる。削減効果の詳細については、3.4.4 項に詳述する。
次に、学習後の AI モデルを活用して解析性能の評価を行った。評価方法として、鉄道事業者に新たな検知対象物として疑似き裂として「ナナメクラック」を追加学習していただき、その後構築した AI モデルにおいて「ナナメクラック」が検知可能であるか確認した。
評価項目は追加学習した AI モデルの検知性能（検出率・網羅率）で検知対象ごとのパラメータは下記の通りである。


クラック：

方向（タテ・ヨコ・ナナメ）幅（0.1 / 0.2 / 1.0 / 2.0mm）長さ（20 / 60

/ 80cm）


収容函のハンドル開閉：角度（正常/異常）

ブレーキパッドの厚さ：（すり減り度合いを計測し、異常値を検出）

鉄道車両の走行速度（5km/h , 10km/h）に応じて、上記のパラメータを網羅した映像を現地で取得し測定を実施した。
184

本検証の結果を表 3.4.3-36～3.4.3-41 に示す。

表 3.4.3-36 西鉄における特化型汎用モデル（追加学習）の評価結果（疑似き裂）
走行速度(km)向き

平均 / 合計 / 検出率

5km

ナナメ

52.4%

91.7%

垂直

76.2%

44.4%

水平

100.0%

36.1%

5km 集計10km

平均 / 合計 / 網羅率

63.9%

57.4%

ナナメ

56.9%

80.6%

垂直

92.9%

36.1%

91.7%

30.6%

10km 集計

水平

68.8%

49.1%

特化型汎用モデル(追加学習)(西鉄) 集計

66.1%

53.2%

表 3.4.3-37 西鉄における特化型汎用モデル（追加学習）の評価結果（収容函ハンドルの開閉異常）
走行速度(km)補足

5km

合計 / 検出率 合計 / 網羅率

異常

100%

100%

正常

100%

100%

100%

100%

異常

100%

100%

正常

100%

100%

10km 集計

100%

100%

特化型汎用モデル(追加学習)(西鉄) 集計

100%

100%

5km 集計10km

185

表 3.4.3-38 西鉄における特化型汎用モデル（追加学習）の評価結果（ブレーキパッドすり減り）
速度(km)

補足

5km

合計 / 検出率 合計 / 網羅率

交換対象

100%

100%

正常

92%

100%

94%

100%

交換対象

100%

100%

正常

67%

100%

10km 集計

78%

100%

特化型汎用モデル(追加学習)(西鉄) 集計

86%

100%

5km 集計10km

表 3.4.3-39 京阪環境における特化型汎用モデル（追加学習）の評価結果（疑似き裂）
走行速度(km)

向き

5km

ナナメ

62.5%

69.4%

垂直

51.9%

38.9%

水平

平均 / 合計 / 網羅率

85.7%

33.3%

63.8%

47.2%

ナナメ

69.2%

50.0%

垂直

62.5%

13.9%

水平

5km 集計10km

平均 / 合計 / 検出率100.0%

38.9%

10km 集計

77.1%

34.3%

特化型汎用モデル(追加学習)(京阪) 集計

68.8%

40.7%

186

表 3.4.3-40 京阪における特化型汎用モデル（追加学習）の評価結果（収容函ハンドルの開閉異常）
走行速度(km)補足

5km

合計 / 検出率 合計 / 網羅率

異常

100%

100%

正常

100%

100%

100%

100%

異常

100%

100%

正常

100%

100%

10km 集計

100%

100%

特化型汎用モデル(追加学習)(京阪) 集計

100%

100%

5km 集計10km

187

表 3.4.3-41 京阪における特化型汎用モデル（追加学習）の評価結果（ブレーキパッドすり減り）
速度(km)
5km

補足

合計 / 検出率 合計 / 網羅率

交換対象

100%

100%

正常

84%

100%

85%

100%

交換対象

100%

100%

正常

84%

100%

10km 集計

85%

100%

特化型汎用モデル(追加学習)(京阪) 集計

85%

100%

5km 集計10km

本検証の結果より、鉄道事業者（西鉄、京阪）での追加学習機能・アノテーション支援ツールを利用した特化型汎用モデル（追加学習）を用いて、ナナメクラックを検出させた結果、追加検知対象物の検出は可能であった。
追加学習後、ナナメクラックの検知性能は向上したが、タテ・ヨコクラックの検知性能が低下した。クラックに対して新たなパターンの画像(タテ・ヨコ箇所に何もない画像や、タテ・ヨコ箇
所以外の箇所にクラックがある画像)が追加されたことで、予測確率が低めに出力されるようになった(自信を失ったモデル)と想定される。
本事象は学習データを増やしていくことで、安定した予測確率を出力するモデルとなり検知改
善されることが推察される。

（3） レベル３検証まとめ
AI 共用における解決方法の検討や実現性及びその有用性についての検証結果をまとめる。
「特化型汎用モデルの導入」
AI 共用におけるモデル構築・管理における汎用実現可否の検証結果を記載する。
今年度、考案した「特化型汎用モデル」は、問題なく動作し、各鉄道事業者の車両検知が行え
188

ていることが確認できた。また、混濁モデルと特化型汎用モデルでの検知性能の比較においては、特化型汎用モデルのほうが精微な検出パターンにおいて若干ではあるが、検知性能が良いことが確認できた。
この結果を基に、特化型汎用モデルについてさらに西鉄、京阪での現地環境での車両検出においても過年度の実証実験における検知性能の比較を行った。
検知性能としては、少ない教師データを学習させて構築した特化型汎用モデルで、より多くの教師データを学習させていた過年度、混濁モデルと比較しても同等程度の性能は発揮できることがわかった。
また、上述した通り、混濁モデルと特化型汎用モデルでの検知性能の比較においては、特化型汎用モデルのほうが精微な検出パターンにおいて検知性能が高いことが確認できている。
教師データの学習量、すなわちモデル作成における作業量が少なくとも、検知性能が確保できる特化型汎用モデルの構築をまず検討すべきであることがわかった。
混濁モデルにおいては、より多くのバリエーションに富んだ教師データを学習させ続けること
でモデルの検知性能向上が期待される。ただし、複数事業者で共用を行った場合、運用の過程で教師データ追加を行う際、各社の検知対象物の特徴量に大きくばらつきが生じることで AI の判定基準に影響を及ぼし検知性能が劣化する可能性がある。また、各事業者によって、車台形状に非常に多くのバリエーションがあることがわかっており、個々の車台によって検知対象物の位置なども大きく異なっていることがヒアリングにより判明した。このことから、複数事業者の教師デー
タをまとめて学習させる混濁モデルは、検出性能の維持、向上にあたって優位とはいえない。
ゆえに、特化型汎用モデルの構築を検討すべきことが一層裏付けられる。
学習モデルの機能面や性能面において、今年度、混濁モデルと特化型汎用モデルにおいて顕著な機能差分は発生しなかったが、システム導入後の共同運用を各事業者が相互にモデルを構築・運用することを想定した時の影響を想定し、特化型汎用モデルでの運用がより汎用性が高く実用性も高くなると判断できる。
なお、今年度の特化型汎用モデルでの検出結果において、一部クラック(特に細いもの等)等に
若干の検知性能影響が本データ上は見られるが、ラボ環境（録画映像）では問題なく検出出来ていることから、AI モデルの影響ではなく、実証当日の天候条件やカメラの設定等、外部要因に大きく左右されたことによる差分と考えられた。
この観点については、現地の撮影協環境において照度の調整や、カメラの撮影条件などのチュー
ニングにより改善を図る点も効果的な対処ではあるが、併せて、利用者側で追加学習を継続的に行うことで AI モデルの高度化においても影響を軽減できる。

表 3.4.3-42 特化型汎用と混濁モデルでの機能/運用面での評価
観点

利用パターン①

特化型汎用モデル

利用パターン②

混濁モデル

１つの AI モデルに対して各事業者が共同
機能面

各社の目的や環境に特化した AI 学習が可能

で追加学習を行うため、AI モデルの状態を管理する機能が追加で必要となる

189

運用面

コスト

リスク

AI 機能改修時、対象の事業者のみ利用停止

AI 機能改修時、全利用事業者の利用を停止

して更新作業を行うため、各社の希望するして更新作業を行う必要があるため、頻繁タイミング・頻度で改修作業を行えるに改修作業を行うことができないモデルの管理/運用コストは各社の運用頻利用事業者が多くなる分、不具合発生リス度により決定するためコストを抑えること

クを加味して監視・対応コストを加算する

が可能

必要がある

AI 機能起因の不具合発生時の影響範囲が小AI 機能起因の不具合発生時の影響範囲がさい（１利用事業者に影響あり）

大きい（全利用事業者に影響あり）「利用者による追加学習機能」
利用者自身が、利用者の特化型汎用モデルを追加学習できる機能を新たに鉄道車両監視 AI シス
テムに機能を実装した。
従来 AI 開発事業者において事業者の開発環境において実行されていた AI 追加学習プロセスをシステム機能設計とユーザインターフェースの定義などから追加機能開発を行い、実装された機能が正常動作することを確認できた。
追加機能の有効性および、導入可能性を確認するため、今年度、鉄道事業者２社において実際に各社における追加学習ケースとして、「検出すべきと設定していたが、AI が検出を見逃して検知
対象物の検出改善」のパターンを設定し、追加学習機能のデモ・アンケート評価を行った。
まず、追加学習機能のデモについては、定量的に検出ができていなかった検知対象物の学習デー
タ 100 枚を本機能により追加学習させることで、検知性能の改善および、利用者においても AI 開発者と同程度の AI モデルの学習精度を達成することができ、本ツールの有効性を確認できた。
また、利用者における本ツール導入時には、初学者でも作業可能とするためにツール操作マニュ
アルと１時間ほどの利用トレーニングを行い利用者に実際に本機能を利用してもらいアンケート
によるツールの評価を行った。
ツールの利用者からの評価結果については、本ツールを利用することで利用者での追加学習は可能であることが期待される結果を得ることができた。
一方で、本ツールを導入することに対して今後の課題として挙げられたことから、今後必要とされる検討方針を以下に記載する。


ユーザインターフェースの操作性の改善。および、利用者へのトレーニング方法やマニュ
アル類のコンテンツの拡充によるユーザへの導入容易性を高める施策が必要である。

より検査頻度が多い検知対象物へのツール適用を期待される声が鉄道事業者より上がっているため検知対象物の対応品目を追加する機能拡張の検討が必要である。



学習データの収集については利用者によりデータを取得する手間が大きいため、より学習
データの枚数を抑える方式や現地の撮影データのアセスメントを行うサポート機能などの対応も望まれる。
190



追加学習後、追加学習させた対象物の検知性能は向上したが、それまで高い精度で検出できていた対象物の検知性能が低下した。新たなパターンの画像が追加されたことで、一時的に予測確率が低めに出力されるようになったと想定され、本事象は学習データを増やしていくことで、安定した予測確率を出力するモデルとなり検知改善されることが推察される。

図 3.4.3-10 AI 追加学習プロセス

各レベルの取り組みによる負担軽減効果の評価
共用形態に係る検証において、汎用化レベルの定義に従い、各レベルにおける汎用化の効果の検証を行い、その有効性を確認した。合わせて、SaaS 型でソリューションを提供する主な利点となる利用者側のシステム利用に係る負担の軽減効果として、本項では、SaaS 型での初期導入や導入後の運用等に関する利用者側の対応負担軽減効果について各レベルでの検証結果を記載する。

■レベル１ ネットワーク/アーキテクチャ関連本実証で、汎用的な SaaS 型のアーキテクチャを取り入れて設計・構築した環境においては、従来 SI 型や DL 型と異なり、SaaS 型環境の開発・利用に係るコストについては開発や運用の総コストを利用者それぞれが按分した形で負担することになる。
今回、鉄道事業者への SaaS 型提供での負担軽減効果を試算するために利用者企業が見込まれた
場合でのコスト削減効果についても試算を行う。
（試算に当たっては、簡易な試算のため、環境依存となる運用コストなどは含まず計算を行う）
SaaS 型の「鉄道車両監視 AI システム」の初期開発コストを仮に 5,000 万円とし、本システムを利用する利用事業者を今年度、鉄道協議会に参加した共用形態での利用に意欲的な私鉄 10 社を利用者として想定する。
利用者である私鉄各社の車両基地などのシステム適用環境については 1 社あたり 2 拠点での導入、システム遠隔監視拠点に関しては各社 1 拠点用意することを想定した。
また、システム利用環境に設置するシステム構成は本年度実証に用いた各拠点の現地構成と同様とする。
総拠点数 ：システム適用環境（10 社×2 拠点）＋遠隔監視拠点（10 社×1 拠点）＝30 拠点
初期開発コスト：SaaS 型「鉄道車両監視 AI システム」開発コスト
191※5GNW 調達、現地システム類の調達コストは除く。
従来形態であれば、利用 1 社において開発コストは全負担をする必要であるが、SaaS 型の場合は、開発コストについては、各社でそのコスト按分をすることになるため、単純計算において、初期開発コストを 10 社で按分した場合、9 割のコスト負担軽減が期待されることから、従来形態よりも導入の敷居が下がる点は明白である。
コスト構造においての課題として、利用者の拠点数が増加するにつれてクラウドリソース費用などの提供者側の運用コスト負担が増加するため、実際には利用者の拠点数増加に応じてコスト負担率を加算して按分を検討する必要がある。
実際の運用にあたっては、例として 10 拠点ごとに開発コストの 5%程度の追加開発コストを組み込む必要がある場合において、それらを一律利用者への負担増とするか、利用頻度の多いユー
ザに従量負担するかなど、共同利用の事業継続性の観点で初期開発コストだけでなく、運用コス
ト面も含めた収支計画の検討を行う必要性がある。
また、現地における環境構築について、ソリューションをパッケージモデル化できることから
現地での機器構成の設計や選定の稼働低減が期待できる。
その他、汎用的な SaaS 型のアーキテクチャを取り入れて設計・構築する場合においては、各社
でクラウドリソースを分散して利用することで以下のような負担軽減効果を享受することが期待される。
・各社で個社環境を構築する手間・稼働の削減
初期導入の段階で、従来必要であったアプリケーションを実行するインフラ環境を各社個別で設計・調達・開発を行う工程が不要となり、これらにかかっていた利用者での稼働コストの削減が見込まれる。
・システム利用開始のリードタイムの短縮
各社がクラウド上のアプリケーションを利用する形態をとることで、初期導入時のシステム開発にかかる時間を削減することができ、より早く現場でのアプリケーション利用を行うことが可能となる。

■レベル２ 共通コア機能関連
本実証では、システム構成において「マルチテナント管理」と呼ぶ複数ユーザのデータ格納領域を定義して独立的に管理する仕組みをコア機能として実装した。
マルチテナント管理機能は、「鉄道車両監視 AI システム」のみならず、分野横断的に多くのシステムで利用可能な汎用技術である。
これにより、利用者は、他の利用者が同時に利用していることを意識すること無く、システムを共同利用することができることから SaaS 型でのシステム構成においては必須となる機能である。
SaaS 型利用における「マルチテナント管理」によって、各社でクラウドリソースを分散して利192

用することで以下のような負担軽減効果を享受することが期待される。

・ システム利用の頻度が増えてきた場合の柔軟なリソース追加
利用者は、提供者が手配する各種コンピューティングリソースを共同利用することになり、
従来、リソース追加に必要であった調達・基盤への組み込み工程が利用者単位での対応不要となり、システムの利用頻度に応じて柔軟にクラウドリソースを増減することが可能となる。必要なときに、必要なだけリソースを使用することができるため、従来のような固定費の削減が見込める。

図 3.4.4-1 マルチテナント管理によるリソース共用■レベル３ AI コア機能関連
AI システムの高コスト化(利用者の負担増大)に直結する課題であった AI システムの汎用化について、本事業の AI ソリューション（モデルケース）においては、SaaS 型で活用するためのマル
チテナント管理に基づいた「特化型汎用モデル」の導入と、「利用者による追加学習機能」（アノテーション支援・学習機能）を実装した。
「特化型汎用モデル」の採用によって、利用者は各社専用の学習モデルに対して「アノテーショ
ン支援・学習機能」を活用し、より精度の高い AI システムを各社で汎用的に活用可能となる。
本項においては、AI システムの汎用化におけるコスト削減効果についての検証結果を記載する。
今年度、3.4.3(2)で評価を行った「アノテーション支援・学習機能」（追加学習）を利用した疑似き裂の検出改善を行った場合での各プロセスの所要時間と、従来、AI 開発事業者が同様の疑似き裂の検出改善を開発事業者の環境、手法で行った場合の所要時間の比較を図 3.4.4-2 に記載する。
比較結果から、従来 AI 開発事業者が行った作業に対して、本実証では、追加学習機能を利用者において実施した場合には、学習データのアノテーションに要する時間は利用者のほうが２倍必要となる結果となった。合計所要時間に関しても利用者が開発者に対して 1.56 倍のとなったが、モデル性能は双方同様の性能となる学習結果となった。
193

この結果から、従来、利用者が AI システムの追加学習を行うために AI 開発事業者にアウトソー
スしていたコストに関して利用者で代替えが可能であることが確認された。また、利用者において AI の専門性がない場合にはアノテーション作業の所要時間が AI 開発事業者で行うよりも効率が悪いように見受けられるが、モデル追加学習の所要時間は半分程度となるため、アノテーショ
ン作業者の作業の熟練度向上や UI の改善によりアノテーションに必要となる合計所要時間は軽減されていくこと期待され、コスト対効果については改善されることが予想される。
従来の AI 開発事業者において専門性が高く、工数がかかる作業を利用者で内製対応することで継続的な運用コスト低減が期待される。

図 3.4.4-2 AI 追加学習プロセスの所要時間比較

横展開可能な 5G ソリューションの各種検証まとめ
5G を活用した同種のソリューションを汎用的に利用するために、ロールモデルとした 5G ソ
リューションにおける汎用性を意識したアーキテクチャの検討及び検証のまとめを記載する。
共用形態に係る検証においては、以下の汎用化レベルの定義に従い、各レベルにおける汎用化の効果の検証を行い、検証結果の分析と課題を整理した。
汎用化レベルは、下記の通り定義する。
（図 3.4.5-1 参照）


レベル 1
➢

NW/アーキテクチャ（SaaS 共用形態、接続形態）

SaaS 共用形態
汎用的な機能・アーキテクチャを用いたサービス提供形態➢

接続形態
異なる接続形態の長短所のまとめ



レベル 2
➢

共通コア機能（マルチテナント管理機能）

マルチテナント管理機能
・複数利用者のデータを独立して管理する仕組み
194

・複数利用者が共通のシステムを利用し、適切にリソースを活用する仕組み


レベル 3
➢

AI コア機能（追加学習機能/特化型汎用モデル）

特化型汎用モデル
汎用性を維持しながらも、利用者ごとに特化した学習が可能な仕組み➢

追加学習機能専門家でなくても AI モデルを運用・維持管理できる仕組み

図 3.4.5-1 5G ソリューションの汎用レベル毎の作業結果
レベル 1 では、システムのネットワーク/アーキテクチャの観点で汎用性を机上で評価した。
本事業の AI ソリューション（モデルケース）について、他分野にソリューションを展開する際に制約がある技術やサービスは利用しておらず、本システムの NW/アーキテクチャは、今回選定した「鉄道車両監視 AI システム」だけでなく、その他の種類のソリューションにも同じアーキテク
チャを適用することが可能であることを確認した。
展開時の課題として、他ユースケースにおいてソリューションに対してのシステム要求が異なる場合、同様のネットワーク・アーキテクチャを活用する場合にシステム性能要求が今回のアーキテクチャを構成する標準サービスで満たせない場合には、代替サービスやリソースの増強を検討する必要があるなど個別要件への対応が必要となる。
クラウドとの NW の接続方式による遅延性の差異についても、5G 基地局設置状況、接続するクラウド基盤までの物理距離等バラつきがあるものの、各検証結果が示す通り、閉域網接続のほうがインターネット経由接続よりも概ね所要時間が短くなり、リアルタイム性が求められる伝送において優位であることが確認できた。（図 3.4.5-2）
NW 接続方式によるソリューション全体への影響としては、本事業で選定している 5G ソリュー
ションにおいては、End to End で発生する遅延の中で NW の接続形態に関する影響は、限定的で
195

あった。
他ユースケースに展開する際において、より低遅延性を要求された場合には、今回検証を行った結果からも NW 接続形態を閉域網経由での接続形態を選択することが遅延低減策の一つとして効果が発揮できる。

図 3.4.5-2 ネットワーク接続形態での遅延量の差異
レベル 2 では、共通コア機能として「マルチテナント管理機能」を評価した。
並列処理機能については、共有のリソースを各社に対して分散利用する設計としたことでリソースを１社占有で活用した際よりも処理性能は落ち込んだ点はあるが、一定の処理リソースを割り当てたとき、系統数に応じて一律の解析時間であることが確認でき、事業者が SaaS 型ソリューションを利用する際に必要となる複数系統での同時並列処理が想定通りに動作することが確認できた。
データ格納領域の定義についても、複数ユーザのデータ格納領域を新規に定義して独立的に管理する機能等を搭載することで、各社で独立したデータ保管領域をもち、それらをユーザ ID などの利用者を判別する個社判別情報と紐づけデータの入出力を行うことでシステム共同利用時においても利用者ごとのデータ保存の独立性を担保可能であることを確認できた。
アプリケーション処理のリソース分散設計や並列処理での同時利用、データの独立性の担保の手法については、鉄道車両監視 AI システムのみならず、分野横断的に多くのシステムでも転用可
能な汎用技術として活用することが可能である。
また、今後の論点としては、導入後の運用も見据えたマルチテナント管理手法として、より効
率的なリソース活用を行うために、常時クラウド基盤のリソースを過不足なく安定・効率的に稼働させていくこと、また、リソースに不足が見込まれる場合にはその予兆を検知し、柔軟にクラウド基盤のリソースを提供し利用者のサービス利用を途絶えさせることなくサービスを継続させるように管理・計画を立案していく必要がある。これら達成していくための SaaS システムの可用性向上に関する検討として、可用性向上に向けたアーキテクチャ設計とクラウド環境のサービス
動作監視・スケーリングに関する検討が必要となる。
可用性向上に向けたアーキテクチャ検討としては、SaaS 型による利用者増加が見込まれる際に、よりサービス停止時間を短くする検討が必要である。このためには、クラウド基盤環境内のアプ196

リケーション並列設置および、負荷分散の検討、クラウド基盤の分散設置などの設計が有効である。
また、クラウド環境のサービス動作監視・スケーリングに関する検討としては、提供している
システムが正常に動作していることを監視するためにログ統合監視の機能設計および、サービス
動作状態に異常が見受けられる場合にリソースを動的にスケーリングする機能が必要となる。

図 3.4.5-3 システム可用性向上に向けた今後の検討
レベル３では、AI 共用における解決方法の検討や実現性及びその有用性について評価した。
「特化型汎用モデルの導入」
今年度、考案した AI 共用において性能向上を考慮した「特化型汎用モデル」は、効果的に動作し、各鉄道事業者の車両検知が行えていることが確認できた。
併せて、利用者の AI 共同利用においては特化型汎用モデルでの運用がより汎用性が高く実用性が高くなると判断された。（表 3.4.5-1）

表 3.4.5-1 特化型汎用と混濁モデルでの機能/運用面での評価
観点

利用パターン①

特化型汎用モデル

利用パターン②

混濁モデル

１つの AI モデルに対して各事業者が共同
機能面

各社の目的や環境に特化した AI 学習が可能

で追加学習を行うため、AI モデルの状態を管理する機能が追加で必要となる

運用面

AI 機能改修時、対象の事業者のみ利用停止

AI 機能改修時、全利用事業者の利用を停止

して更新作業を行うため、各社の希望するして更新作業を行う必要があるため、頻繁タイミング・頻度で改修作業を行えるに改修作業を行うことができない

197

コスト

リスク

モデルの管理/運用コストは各社の運用頻利用事業者が多くなる分、不具合発生リス度により決定するためコストを抑えること

クを加味して監視・対応コストを加算する

が可能

必要がある

AI 機能起因の不具合発生時の影響範囲が小AI 機能起因の不具合発生時の影響範囲がさい（１利用事業者に影響あり）

大きい（全利用事業者に影響あり）「利用者による追加学習機能」
利用者自身が、特化型汎用モデルを追加学習可能とする機能を新たに鉄道車両監視 AI システムに実装し、動作正常性を確認することができた。
追加学習機能の利用者からの評価結果については、本実証で開発したツールを利用することで利用者での追加学習は有効であるという結果を得ることができた。
一方で、事業化フェーズにおいて利用者による追加学習機能を導入することに対して今後継続的に必要とされる検討方針を以下に記載する。
（１） ユーザインターフェースの操作性の改善。および、利用者へのトレーニング方法やマニュアル類のコンテンツの拡充によるユーザへの導入容易性を高める施策が必要である。
（２） より検査頻度が多い検知対象物へのツール適用を期待される声が鉄道事業者より上がっているため検知対象物の対応品目を追加する機能拡張の検討が必要である。
（３） 学習データの収集については利用者によりデータを取得する手間が大きいため、より学習データの枚数を抑える方式や現地の撮影データのアセスメントを行うサポート機能などの対応も望まれる。

将来的な 5G 技術を活用した共用形態の検証
本実証で構築・検証する共用形態（SaaS 型、5G ネットワークとクラウド基盤の接続方式）を踏まえ、さらに高度化されていく 5G 技術と共用形態の親和性について明らかにする。5G SA、MEC 技術を活用した 5G ソリューションの展開・共用を想定し、5G SA、MEC 構成とした場合での有効性、論点、課題、今後必要な検証等について取りまとめる。
（図 3.5-1 参照）

198

図 3.5-1

クラウド環境との NW 接続形態図

評価項目
本実証で構築した SaaS 型のソリューションを SA/MEC 技術を活用し提供する場合の有効性などを検証するにあたって評価項目を整理する。
(1) 評価項目の整理
それぞれの技術遷移として、5G NSA から 5G SA への変遷、および MEC(Multi-access Edge Computing)
技術を活用しないケースから MEC 技術を活用するケースへの変遷により、SaaS 型のソリューションが得られる効果、影響の観点を整理する。
図 3.5.1-1 に示すように現在の 5G 提供状態は 4G コアネットワークにより 4G の基地局と 5G の基地局を連携させて動作させる NSA（Non Stand Alone）方式が中心であり、5G の特性の中で高速大容量のみが担保されている。各移動体通信事業者は今後、4G のコアネットワークとは独立した 5G のコアネット
ワークにより基地局を単独で動作させる SA（Stand Alone）方式に順次切り替えを進めていく方針である。5GSA では、5G 特性である超高速大容量通信・超低遅延性・同時多数接続の性能が十分に活用できるようになる点が特徴である。
199

図 3.5.1-1 4G から 5G への移行
出展：総務省「5G（SA 方式）時代におけるネットワーク提供に係る課題の検討」
また、MEC 技術については、ユーザエンド端末の近くで分散処理を行うサーバを設置する内容を指す。
通常、5G のユーザエンド端末から基地局、基地局から移動体通信事業者のコアネットワークを経由しク
ラウドサーバへと通信を行う事が一般であるが、通信を行うユーザエンド端末の近くにサーバを配置す
る MEC(Multi-access Edge Computing)技術の導入を各移動体通信事業者やシステムインテグレータな
どがサービスとして提供を開始し始めている。これにより、ネットワークホップ数が多くなるデメリッ
トのある従来サーバ通信形式と比較し、物理的な通信距離が短いことや介在する中継機器が少ないこと
により遅延性の改善や外部ネットワークとの接続点がなくなることでセキュリティ面の向上が見込まれる点が本技術の特徴として挙げられる。

図 3.5.1-2 MEC サーバの位置と遅延性の関係
出展：5G（SA 方式）時代におけるネットワーク提供に係る課題の検討
200上述より、5GSA に関しては、5G 特性である超高速大容量通信・超低遅延性・多数同時接続が 5G ソリュー
ションの利用に対し与える影響や、セキュリティ面への影響を確認することとした。
MEC 技術に関しても、接続形態によるソリューションの遅延性やセキュリティ面への影響を確認することとした。

(2) 期待される効果の整理
また、本項で、1)ソリューション利用に際し 5G NSA、MEC 技術を活用しないケースにおける現状の課題を整理し、2)実際のユースケースで 5G ソリューションに求められる性能を確認することで、各通信技術の機能面に関して期待される効果の目標値を整理した。

1） 5G NSA および MEC 技術を活用しないケースにおける現状の課題(A) 5G NSA の課題
5G NSA は 4G・LTE と比較し、高速大容量での利用に対応したが、課題として、超低遅延や多数同時接続に対応できないこと等が挙げられる。とりわけ取り立てて挙げられる課題としては、NSA 型
では 4G コアを用いた通信を行うため、5G コアを用いた通信に比べ超高速大容量の通信が行えない
こと、遅延が一定量発生すること、特定の地域で許容量以上の通信が行われた際に輻輳を防ぐことが出来ないこと等がある。
そのため、クラウド上に現地 5G 環境からのデータ通信を行うアーキテクチャとなる SaaS 型ソリューションでの利用ケースにおいて、5G NSA を用いる場合、通信量の制限、接続台数の制限、遅延や切断に備える必要がある。例えば、医療用ロボットのリアルタイム遠隔操作のような遅延や切断等が致命的となる活用領域では利用そのものが困難となることや、また、高精細の監視カメラ映像をリアルタイムにクラウドに映像配信するようなケースでも通信帯域により映像画質の制限を余儀なくされるといった課題が挙げられた。

(B) MEC 技術を活用しない場合の課題
MEC 技術を活用しない方式では、センシングデバイスなどの現地端末から処理を実行するサーバまでの物理的な距離や通信経路上のインターネットを中継する区間においてネットワーク全体の遅延量が増加する課題がある。クラウド上でのサーバ利用を前提とする SaaS 型ソリューションのアーキテクチャにおいては、遅延量の度合いにより利用困難な用途が存在する。具体的には、人間がリアルタイムで介入するような用途において、ネットワークの遅延により操作のリアルタイム制
御が困難となる飛行ドローン、ロボットの遠隔操作等が例として挙げられた。
201

2） 5G NSA から 5G SA への移行および MEC の利用で期待される機能面の目標値
5G ソリューションについて期待される NW 性能の目標値について各実証ユースケースの活用例を踏まえて記載する。
①

超高速での利用

超高速通信に関して、複数のカメラデバイスを利用し AI を活用して映像解析を行うケースなどが想定される。令和二年の情報通信白書8によると、「河川等に設置した固定の高精細カメラやドローンに搭載したカメラからの高精細映像を、5G でリアルタイムに伝送することで、災害状況や遭難状
況の把握が可能になり情報行動の効率化等を図ることができる。
」とされており、千葉県では 30 河川 41 箇所に監視カメラが設置されているような事例9もある。この事例において、監視カメラを一律 4K カメラで実装するとした場合、一台当たりに必要となる通信帯域を 25Mbps（※4K30fps 相当
での配信を想定）と仮定すると、映像アップロードに必要となる通信帯域の合計は約 1Gbps 程度が必要となってくる。
②

超低遅延での利用

低遅延性に関して、医療用ロボット等の制御を遠隔で行うケースにおいて、国立保健医療科学院の公表している遠隔手術ガイドラインの検討10では、「操作の遅延が 70msec を超えると、誤操作が生じる比率が高くなることが明らかとなった。」とされており、ネットワーク全体で遅延時間が70msec 以下の遅延性に優れたネットワークが求められるということが示唆されている。
③

多数同時接続

多数同時接続に関して、スタジアム等の局所的に大量の端末が同時に通信を行うケースにおいて、
5G 基地局一台あたりに対しユーザエンド端末や IoT 機器類なども含めると数千台～数万台の接続が求められるケースも生じる。2018 年に行われた国立研究開発法人情報通信研究機構の実証11では、多数同時接続に関する確認が行われ、「100 台程度の端末であっても一斉に接続を試みると接続できなくなる場合があること」も確認されていた。

(A) 5G SA の目標値
「IMT ビジョン勧告（M.2083）」12によれば、5G SA の発展により見込まれる通信性能の向上として、3.5.1 で評価項目としても設定した以下 3 点の期待・目標値が述べられている。
①

超高速通信（eMBB）

総務省令和２年度情報通信白書より引用
千葉県雨量・河川水位・河川映像の情報提供 河川監視カメラについて
10
厚生労働行政推進調査事業費補助金 遠隔手術ガイドラインの検討(2018 年)
11
国立研究開発法人情報通信研究機構 5G 実証試験において端末約 2 万台の同時接続を確認
12
総務省 5G の利用シナリオと主な要求条件より引用
202
8
9

4G においては、通信速度が下りで最大 1Gbps 程度、上りで最大数百 Mbps 程度であったのに対し、5G の要求条件では、下りで最大 20Gbps 程度、上りで最大 10Gbps 程度となっており、4G の10 倍以上の速度となることが見込まれている。4G 以上の高速大容量通信によって、4K/8K などの高精細映像をはじめとした大容量コンテンツであっても高速に伝送されることが期待される。
②

超低遅延通信（URLLC）
5G における遅延は 1msec 程度とされており、4G の 10 分の 1 程度に短縮されることが見込まれている。これにより、4G では安全性の観点から実現が難しいとされていた自動運転や遠隔でのロボット操作（リアルタイムでの操作やミッションがクリティカルなものなど）も 5G では実現可能性が高まり、様々な産業・分野において移動通信システムの用途が広がっていくことが期待される。
③

多数同時接続（mMTC）
4G においては、1 ㎢あたり 10 万台程度の端末が同時に接続できるとされていたのに対し、5Gでは 1 ㎢あたり 100 万台程度の端末が同時に接続できるようになることが見込まれている。IoT
時代において膨大な数のセンサーや端末が存在する場合（例：スマート工場、スマートメーター、
インフラ維持管理）であっても、通信に支障が生じないことが期待される。

評価方法
(1)

SaaS 型ソリューションにおける MEC 利用形態の検討

5G ソリューションは MEC サーバの設置場所や提供形態による影響を受ける（3.5.3(1)にて詳述）。こ
こでは、主に MEC サーバの設置場所による影響と、提供形態の 2 点について評価を行い、SaaS 型でのソリューション提供を踏まえて最も適した形式を机上検討した。

(2)

SaaS 型ソリューションにおける SA/MEC 活用評価

5G SA や MEC 技術活用が SaaS 型の 5G ソリューションに寄与する事項や程度について評価を行った。

評価結果
(1)

SaaS 型ソリューションにおける MEC 利用形態の検討
1） MEC 活用事例の特徴

5G SA、MEC 技術が 5G ソリューションを SaaS 型で提供していくうえでどのような影響を与えるかを確
203

認するにあたり、各移動体通信事業者が現在提供している 5G SA および MEC 技術を活用した接続形態を整理した。それぞれの接続形態の主要な設備や機材といった構成要素、各接続形態の特徴を確認し、SaaS
型ソリューションへの活用可能と想定される事項を抽出した。
各接続形態の特徴として具体的には、5G 通信の利用が可能か、MEC 技術活用のエリアカバレッジを捉えるための MEC サーバのリージョン数、クラウド基盤がユーザにとって使い慣れたものか、外部システ
ムとの連携が容易かといった観点でのクラウド基盤の柔軟性を確認した。MEC 接続可能なクラウドサー
ビスの種類は各サービス内容に準拠するが、システムを導入する際には MEC 接続を行うクラウドサービ
スの選択はアーキテクチャの設計を行う上で重要なポイントになる。提供者としてクラウドサービスで提供されるリソースやサービスの仕様に応じて機能開発の柔軟性が取れる点やエンドユーザとなる利用者のシステム基盤や外部のサービス基盤との連携性の高さについてもクラウドサービスを活用した
5G ソリューションを設計する中で重要である。
A) NTT 東日本「地域エッジクラウド」
NTT 東日本の提供する接続形態の特徴として、MEC サーバの拠点数の多さが挙げられる。後述するが、MEC サーバの設置位置および距離はネットワークの遅延性に影響するため、全国に満遍なく MEC 接続環境が展開された当サービスのような MEC 接続サービスの利用は全国的なソリューションの普及・展開に影響を与えるものだと考えられる。
現時点（2022 年 7 月 25 日）では当サービスにおいて、キャリア 5G での MEC 接続形態を提供していないように見受けられるが、現地拠点から MEC サーバまでの区間を有線接続することで低遅延かつセキュアな通信を提供している点もポイントであると考えられる。
クラウド基盤についても国内でも広く利用されユーザにとって、より馴染みの深い「Microsoft Azure」の活用によりクラウド基盤の柔軟性を持たせているものと考えられる。パブリッククラウドサービスを活用することで、利用者としては自社の従来クラウド環境とのギャップが少なく、開発難度が下がることにつながると想定される。

図 3.5.3-1 NTT 東日本

MEC 接続形態B) NTT ドコモ「docomoMEC」
NTT ドコモの提供する docomoMEC の接続形態の特徴として、5G SA の利用が可能かつ MEC サーバの拠204

点数も全国主要都市に展開されており比較的多いと言え、MEC 接続可能なエリアカバレッジも担保されている点が特徴である。

図 3.5.3-2 NTT ドコモ

5G SA、MEC 接続形態

C) KDDI「AWS Wavelength」
KDDI の提供する接続形態の特徴として、5G 通信の利用が可能であり、NTT 東日本同様パブリッククラ
ウドサービスである「Amazon Web Services」を活用しているため、クラウド基盤の柔軟性を持たせているものと考えられる。一方で、現状 MEC サーバの拠点は東京、大阪リージョンのみに限定されている。

図 3.5.3-3 KDDI 5G SA、MEC 接続形態

205

表 3.5.3-1 各社 5G SA、MEC 接続形態一覧
モデル名

構成要素

NTT東日本 MECダイレクトモデル

NTTドコモ MECダイレクトモデル

KDDI MECダイレクトモデル

閉域NW,データセンター、ネットワー
基地局、AWS Wavelength Zone、
基地局、5Gデータ端末、MECダイレ
ク接続基盤、地域エッジクラウド基盤
AWS VPC、キャリアGW、モバイルGW
クト、ドコモNW設備、クラウド基盤、サービス、仮想マシン、マネージドデ、AWS AZ、インスタンス、KDDIモ
インターネットスク
バイル網(au 5Gネットワーク)

構成

企業名（サービス名）

NTT東日本 (地域エッジクラウド)

Docomo(docomoMEC)

KDDI (AWS Wavelength)

5G対応

×

○

○

エリアカバレッジ（リージョン数）

37

9

2

Azure

docomoMEC

AWS

クラウド基盤
参考URL

https://www.ntteast.co.jp/release/detail/20220725 https://www.mec.docomo.ne.jp/_01.html

https://biz.kddi.com/5g/aws_wav
elength/

前述の通り、各社の接続形態での違いは、5G 通信の利用可否、MEC サーバの拠点数、クラウド基盤の柔軟性がポイントとなる。
（表 3.5.3-1）ソリューション利用時にネットワークの遅延性への影響要因として挙げられる MEC サーバの設置位置に関しては、各社で大きな違いは見られなかった。

2） MEC の設置検討
市場で提供されているサービスも踏まえて SaaS 型ソリューションでの MEC サーバの設置パターンについて以下に記載する（図 3.5.3-5 参照）。

206

図 3.5.3-4 MEC サーバの設置位置のパターン＜①エンドユーザのネットワーク内(閉域網)に MEC サーバを設置する場合＞
物理的な距離が近く、目的に即したシステム構成を行えるため最も遅延量の削減等が期待できる。しかし、利用者毎にオンプレミスで MEC サーバおよびアプリケーションの実装を行うことが基本となることから、複数事業者での共同利用が行えず、利用者毎に機材を設置するため導入コストが高くなる傾向がある。また、基本的にシステム保守・運用を利用者自身が行うことになり、運用面での負担も大きくなると考えられる。
＜②移動体通信事業者のネットワーク内に MEC サーバを設置する場合＞
従来では、エンドユーザのネットワーク内もしくはインターネット上にサーバを設置する必要があったが、通信事業者のネットワーク内に設置することで遅延を最低限に抑えつつ、コストの削減を行う事が可能となった。インターネット上に設置するケースでは、インターネットの速度が律速となるのに対し、通信事業者のネットワーク内に設置するケースでは閉域網で接続することで、5G 回線のみで通信を行う事が可能となる。
＜③MEC サーバを設置しない場合＞
実績もあり従来の SaaS 型アーキテクチャは多くの場合、この形式での接続形態を採用している。し207

かし、インターネットを利用するため、遅延の発生やセキュリティリスクが比較的高くなる課題が存在した。
SaaS 型システムの共用という観点で考えた際、最も適した形は上記 2 点目で紹介した移動体通信事業者のネットワーク上に MEC サーバを設置する形式であると考えられる。
①エンドユーザのネットワーク内(閉域網)に MEC サーバを設置する場合のように利用者自身で導入から保守・運用が必要となる点は SaaS 型のコンセプトとは相違がある。
また、③MEC サーバを設置しない場合においても、従来、ネットワークの遅延やセキュリティに課題を抱える点が残置される。これらの点を踏まえ、クラウド上の MEC サーバへの閉域接続が可能であり、ネッ
トワークの低遅延性、セキュリティ面でのメリットがある②移動体通信事業者のネットワーク内に MEC
サーバを設置する方式を選択していくことが SaaS 型ソリューションでの接続形態においては優位性が
ある。

(2)

SA/MEC のソリューションへの影響評価

以下で、実際に 5G SA や MEC 技術の活用が SaaS 型 5G ソリューションに寄与する事項や程度について評価する。
1） 5G SA の利用による改善①

超高速大容量での利用
現在主流となっている NSA 型では、超高速大容量での利用に対応できない事が課題となる。例えば、複数の監視カメラを利用するケースにおける接続台数の増加や高精細映像を用いたアプリケーションとの連携によるソリューションの高度化による点などが考えられる。
5G SA の導入により NTT ドコモでは現段階(2023 年 2 月 7 日時点)で下り最大 4.9Gbps/上り最大 480Mbpsの通信サービスを提供している。5G ソリューションの普及にはより高速大容量での利用に耐える必要性があるが、現状でも実用に耐えるユースケースも多数開発されている。
また、性能面以外でも NSA では行えなかったネットワークスライシング13技術の導入等により、用途に応じた帯域の設定により高速大容量等への対応が行われる。
今後、高速大容量化に関して導入が検討される見通しのある主な技術を以下に示す。最も大きな変化として考えられるものは、上述した用途別に帯域を分けることが可能となるネットワークスライシングである。重要な通信に対しより帯域を多く割り当てることにより高速大容量に適した環境を作り出すことに繋がる。また、従来利用されていた技術である、帯域をまとめて利用するキャリアアグリゲーショ

ネットワークスライシング：「低遅延・高信頼・高セキュリティ等、様々な要求条件が求められる 5G において、ネットワークを仮想的に分割（スライス）することで、お客さまが利用するサービスの要求条件に合わせて効率的にネットワークを提供する技術」。単純化すると、用途別にネットワークを分割し、目的に適したネットワークを提供する技術である。
13208

ン14や複数のアンテナで通信を行い通信可能なデータ量を増やす MIMO15等を 5G SA で活用することも検討されている。
これらの技術の発展後もなお残る課題としては、高画質である 4K/8K 等に対応した監視カメラの利用
等では接続台数などの利用条件により、5G SA の通信量でも不足が想定される。この対策については、
スライシング技術の活用により NW 帯域がひっ迫するタイミングにおいて、帯域を制限し配信ビットレー
トを落とすような制御方法の検討・導入が有効であると考えられる。また、現状では 5GSA が利用可能な地域が少ないことが課題として存在するが、今後、移動体通信事業者のサービス提供が加速されることで利用可能な地域も拡大されると考えられる。

図 3.5.3-5 ネットワークスライシングの模式図
出展：総務省「5G（SA 方式）時代におけるネットワーク提供に係る課題の検討」

キャリアアグリゲーション：「複数のキャリアを用いて同時に送受信することにより、既存の LTE とのバックワードコンパチビリティを保ちながら広帯域化を行い、高速伝送を実現する技術」。単純化すると、
複数の帯域を束ねて利用することで、見かけ上の帯域を広げ高速伝送を実現する技術である。
15
MIMO(Multi-Input Multi-Output)：「同一時間、同一周波数において、複数の送受信アンテナを用いて信号の伝送を行い、通信品質および周波数利用効率を実現する信号伝送技術」。単純化すると、複数のアンテナを用いて通信を行う事で、情報欠損を防ぎつつより多くの通信を行う技術である。5G 通信では、特に超多素子アンテナを用いる Massive MIMO を用いることで、「伝搬損失補償により通信可能なエリアを拡大できることに加えて、各ユーザに異なるビームを向けることで多数ユーザを同時接続させるユーザ多重により、高周波数帯セルのシステム容量を増大させる」ことが検討されている。
209
14

②

超低遅延での利用
NSA 型では、一定の遅延が発生することが課題となっている。例えば、医療用ロボット等の制御を遠隔で行うケースなどである。NSA 型で遅延が発生する要因は大きく 2 つある。一つ目は、通信開始時に端末-基地局間で通信許可を求め、基地局からグラントの発行が行われるステップを踏む必要があること。二つ目は、低遅延の少ないネットワークの構築が行われていないこと。
一つ目のグラント発行による通信のロスに関しては、グラントの発行を行わないグラントフリーのシ
ステムの導入が検討されており、初期通信のロスが発生しない改善が見込めると考えられている。（図3.5.3-6 参照）
二つ目に関しては、ネットワークスライシング技術の導入により、低遅延の通信に適したネットワー
クを提供可能となり、より効率的な通信が実現される見込みである。具体的には、QoS により優先的な通信を分離することで他通信処理の存在による遅延を排除する事や、スライスされた通信のネクスト
ホップを通常インターネットに送信するものをエッジデータセンタにローカルブレークアウトさせる事が考えられる。
残る課題としては、5G 区間内は 1msec の遅延での通信が完了されることになるが、システム全体での遅延に関しての設計考慮は継続して対応が必要である。

図 3.5.3-6 グラントフリーの模式図③

多数同時接続での利用
NSA 型では、多数同時接続の需要拡大に対応しきれないことが課題となっている。例えば、スタジア

ムでのイベント等で大量のカメラの接続が行われると、通信インフラ側が対応しきれず通信に失敗する
ようなケースが挙げられる。2018 年に行われた国立研究開発法人情報通信研究機構の実証(5G 実証試験において端末約 2 万台の同時接続を確認 | NICT-情報通信研究機構)では、「100 台程度の端末であっても一斉に接続を試みると接続できなくなる場合があること」が確認されている。
5G SA 環境では前述のグラントフリーやネットワークスライシングの導入が検討されており、同時接続数の向上も期待されている。グラントフリーでは初期通信での事前承認が不要になることで、接続数が増加することは上記の実証で示されており、2 万台の端末からの通信を 70 秒程度で処理可能であったとされている。また、ネットワークスライシングは特定の通信を切り分けることが出来るため、通信が集中した場合でも接続に失敗しないように優先制御のスライシングを構築可能となると考えられてい210る。また、複数のアンテナを利用して通信を行う MIMO の導入により、接続数の増加を目指す研究も進んでおり、より多くの端末の接続が実現される見込みである。

2） MEC 技術の活用による改善①

低遅延での利用
MEC 技術を活用しないケースでは、利用現場からデータセンターやデータ処理サーバまでの通信が必要であり、遠方の場合に遅延が発生することが課題となっていた。
その解決策として、MEC サーバを各地に設置するケースが増えている。利用現場から最も近い MEC サーバに接続することにより、距離的な課題が軽減され、遅延の減少につながる。NTT ドコモでは 5G 通信網と MEC をダイレクトに接続することで、遅延を減らす工夫等もなされている。
残る課題としては、現地と MEC 環境の物理的距離が遠い場合については、遅延の軽減効果が限定的になるケースも存在すると考えられる。
②

セキュリティ性の向上
MEC 技術を活用しないケースでは、基本的にインターネット経由で通信が行われるため、セキュリティ

リスクが課題となっている。具体的には、インターネットを経由するため機密情報の送信等を行う際に傍聴、攻撃のリスクが存在した。
MEC 技術の活用により、閉域網を利用することで通信区間が外部から傍聴、中間攻撃を受ける可能性が減少する。そのため、クラウド環境を利用する場合のセキュリティリスク低減につながると考えられる。

(3)

5G SA、MEC 技術の有効性の評価まとめ

今後 SaaS 型でのソリューション提供において有効性の評価をまとめる。
・

SA 技術の有効性

SA 型となることによる性能の向上と SA 型となることで利用が増加する技術による変化については、
ネットワークスライシング技術の実装によって、用途に適したネットワークを提供可能となる。これにより、従来提供が困難であったサービスに対し SaaS 型のソリューション提供が行われる可能性がある。
従来利用が困難であった画像認識 AI を用いたソリューション等に対し、ネットワークスライシングで高速大容量に適したネットワークや低遅延に適したネットワーク、多数同時接続に適したネットワーク
等を提供することで対応し利用促進に繋がると考えられる。多数同時接続が課題とされているケースは確認できなかったが、より多くの多数同時接続が実現されることにより利用の幅は広がると考えられる。
例えば、スマートファクトリーにおける全機器の情報連携、スタジアムでの大量の IoT デバイスの通信等が挙げられる。

211

現状
公共サービス

安定性を優先したい

I oTサービス

同時多数接続に対応したい

ブロードバンドサービス

⾼速⼤容量を優先したい

防災インフラNW
I oT通信ネット ワークを共⽤

N W は共⽤なので個別最適化は困難

⼀般通信

ネット ワークスライシングによるN W の最適化
安定性を重視し、バランスの良い設定
災害時等混雑する回線を回避し安定した接続を提供可能

公共サービス

防災インフラ

遅延が少なくリアルタイムで扱える回線を切り分けているので災害時でも使えるのが良い

同時多数接続に対応して、速度は落とした設定

NW

I oTサービス

同時多数接続に不安がなくなった
通信速度はそこまで重視しないのでこれでよい

I oT通信サービスに応じてネット ワークを仮想的に
切り分け
⼀般通信

細かな通信を⼤量に扱うことを想定した接続を提供可能

速度を重視し、同時多数接続はしない設定
ブロードバンド
サービス

⽤途に合わせたネット ワークの提供が可能

個⼈向けに動画閲覧に適した接続を提供可能
速度は⼗分、同時多数接続は数台以上は⾏わないので⼗分

図 3.5.3-7 ネットワークスライシングの活用イメージ・

MEC 技術の有効性

MEC 技術の活用により、従来発生していた遅延の軽減が予想されており、遅延が課題となりオンプレミ
ス環境で利用されていたソリューションの SaaS 化が促進されると考えられる。また、インターネット
を経由しないことから、セキュリティ性の向上も見込まれている。遅延等の理由から人間のリアルタイムでの操作が必要な医療用ロボット等の用途では利用が制限されていたが、ネットワークスライシングで低遅延に適したネットワークを提供する事や、MEC を利用することで低遅延化することによっても利用範囲が広がると考えられる。

図 3.5.3-8 MEC の活用イメージ
212

・

今後の課題
新規の 5G 技術により性能面の向上は行われているが、実際に利用されていくためには、技術の活用

事例がより利用者層に認知される必要性がある。現在は、先進的なユースケースに取り組んだ事例が先進事業者から共有されていく必要がある段階と考えられる。

分野横断的な 5G ソリューションの横展開に求められる機能の検証
これまで総務省の「課題解決型ローカル 5G 等の実現に向けた開発実証」の中では、単一事業者や特定の現場での利用に閉じた 5G ソリューションの実証実験が行われてきた。これらの先進的な 5G ソ
リューションが、他分野共通の用途・業務において、幅広い現場、分野で共用されていくことが、5G ソ
リューションの普及・展開の方策として必要となる。今年度実証を行った SaaS 型ソリューションを具体的な分野・業種に横展開していく際に生じる論点として、ソリューション面での論点のほか、ソリュー
ションを共同利用する際における必要な作業（分界点や運用、提供する基本機能など）の検討が必要である。
上記を踏まえ、以下で分野横断的な 5G ソリューションの横展開を見据えて今後、共用形態に求められる機能に関する評価項目、評価方法、アウトプットのそれぞれについて詳述する。
鉄道車両監視 AI システムをモデルケースとしたソリューション側のシステム評価結果、SaaS 型共用
形態のシステム評価結果を踏まえ、鉄道事業分野以外の分野での活用を想定した際のシステム全体評価を行う。
（図 3.6-1 参照）

図 3.6-1

分野横断的な共用形態の検証イメージ

5G ソリューションでよく利用される技術の区分としては、AI、IoT、ビッグデータ解析や XR（Cross
Reality)などが挙げられるが、IoT を単体で利用されるケースは少なく、膨大な IoT データを分析できるビッグデータ分析基盤と AI 技術は併用されるため、実態としては IoT に関連するソリューションはAI ソリューションの中に内包されて利用されるものとも考えられる。このため、5G の特性を活かした213

ソリューションは AI を活用したものが多くを占めると想定される。XR についても、スポーツやエンタ
メ等一部の業界・業種に利用されるが、より多分野に共用可能性が高いのは、AI ソリューションであると想定される。
⼯場・発電所

農業・林業

医療・
ヘルスケア

⽂化・
スポーツ

鉄道・道路

その他

調査対象範囲

AI

I oT

XR

その他

図 3.6-2 業界×5G ソリューション分類図
AI アルゴリズムの分類には画像認識 AI、音声認識 AI、予測 AI、姿勢推定 AI、言語処理 AI など多くの分類が存在するが、本実証で構築された鉄道車両監視 AI システムでも用いられた画像認識 AI は点検、
顔認証、従業員の安全行動サポート、生鮮食品の品質把握、路面情報の取得といった数多くの利用シーンが想定され、AI ソリューションの中でも特に共用可能性が高いアルゴリズムである。実態として、令和 2-4 年度における総務省の「課題解決型ローカル 5G 等の実現に向けた開発実証」でも画像認識 AI を構築された実証が多い。
（表 3.6-1 参照）
表 3.6-1 令和 2-4 年度 L5G 開発実証における業界ごとの実証ソリューションの内訳
業界
工場・発電所
農業/林業
医療・ヘルスケア
文化・スポーツ
鉄道・道路
防災・減災
スマートシティ
空港・港湾

実証対象ソリューション
XR
画像認識AI 音声認識AI IoT
9
2
13
1
7
0
11
2
3
0
8
0
2
0
7
0
9
0
5
0
5
0
6
0
2
0
7
1
3
0
4
0

計
25
20
11
9
14
11
10
7

AI ソリューションのニーズが見込める市場として、表 3.6-2 に示す 5G デバイス・ソリューションの需要が見込めるエネルギー、製造、公共サービス、ヘルスケア、公共交通といった業界が想定される。
例として、製造業界では工場の製造ラインで製造された機械・部品・タイヤなどを、目視により品質を管理していた従来の業務から画像認識 AI での置き換えを行うといったケースや、公共インフラの維214

持管理における点検業務において目視や人の手で確認がなされていた従来の方法を画像認識 AI で置き換えるといったケース、公共交通での顔認証による決済などの利用シーンでの活用が期待される。
本検証の中で、以下 3.6.1 にて詳述する評価項目により、共用可能性が高い業界の検討・考察を行う。
表 3.6-2 国内 5G デバイス・ソリューション市場予測（単位:千億円)
出典:KPMG コンサルティング「5G がもたらす B2B2X 市場の将来予測」
業種
エネルギー
製造
公共サービス
ヘルスケア
公共交通
自動車
金融
メディア・放送
小売・流通
ゲーム・スポーツ

2020
3.4
2.3
2.5
2.7
2.3
1.3
1.1
1.0
1.0
0.6

2021
3.9
2.8
2.9
3.0
2.6
1.5
1.2
1.1
1.1
0.7

2022
4.8
3.6
3.5
3.6
3.1
1.9
1.5
1.3
1.3
0.8

2023
6.1
4.8
4.4
4.4
3.9
2.4
1.9
1.6
1.5

0.9

2024
8.0
6.6
5.7
5.6
5.1
3.2
2.4
2.1
1.8
1.2

2025
10.8
9.4
7.7
7.4
6.8
4.3
3.2
2.7
2.2
1.5

2026
14.6
13.3
10.4
9.8
9.1
5.9
4.3
3.6
2.6
1.9

評価項目
前述の通り、5G ソリューションでよく利用される技術として、画像認識 AI がより多くの分野でのユー
スケースに対応できるものと考えられるため、横展開のニーズが高いと想定できる。分野横断的な共用を進める上での各業界の制約や課題、それら課題に対する共用化を進めるための工夫、ソリューション
に求められる性能面の評価、ソリューションを運用していく上で発生する作業などサービス提供面の評
価といった項目を整理する。
これらの情報を整理したうえで、ソリューションの提供に際して検討すべき事項を検証項目として設定した。
（表 3.6-2 参照）検証項目の大分類については、独立行政法人情報処理推進機構の非機能要求グ
レード16を一部参照し、「信頼性・可用性」、「性能・拡張性」、「移行性」、「運用・保守性」、「セキュリティ」、「導入効果」の 6 分類を設定した。これらの大分類を、5G ソリューションが共用されるうえで検討が必要な項目として、分解したものを中分類として設定した。

16

独立行政法人情報処理推進機構 非機能要求グレード 2018 利用ガイド[解説編]より一部引用
215

表 3.6.1-1 分野横断的な 5G ソリューションの評価項目

評価方法(1) ヒアリングの実施
分野横断的に 5G ソリューションが普及・展開していくために、各業界のユースケースや課題感、ソ
リューションの導入に際して検討・配慮が必要となる観点についてまとめる。実際にソリューションを構築している団体・ベンダーであれば、エンドユーザの要望を最前線で聞いており、ソリューション導入においての検討事項を把握していると考え、ヒアリングを実施して情報を整理することとした。
ヒアリングシートについては 3.6.2（2)にて詳述する。

(2)

ヒアリングの協力団体

ヒアリングは以下の 2 つの団体に協力を依頼した。
a. 令和 2、3 年度 L5G 実証参加団体
b. 各業界において導入実績の豊富な AI ベンダー

a. 令和 2、3 年度 L5G 実証参加団体へのヒアリング
各業界で 5G ソリューションの導入に向けた現地実証を行なっている令和 2 年度、3 年度「課題解決型
ローカル 5G 等の実現に向けた開発実証」（以下、令和 2、3 年度 L5G 実証）参画経験のある団体にヒアリングを実施した。
実証参加団体は特定の現場におけるユーザの要望を確認し、システム要求を整理したうえでソリュー
ションを構築しているため、業界のユースケースや課題感を把握しており、ソリューション構築・導入に際する検討・配慮をヒアリングできると考えた。前述の通り画像認識 AI が多くの分野での用途・業務でのニーズに応える技術であることから、画像認識 AI を用いたソリューションを構築された団体を216

中心にヒアリングを実施した。また、過年度の実証報告書内で他業種や他業務への横展開を検討しているという言及があった団体を中心に、各業界から 1 団体ずつにヒアリングを実施した。
上記に該当する団体の中で、他業種よりも他業務への横展開を検討しているケースの共用可能性は高いと判断した。
「他業務への横展開」は、ユースケースが異なる場合でも展開できることを意味し、単に業務が共通・同様のユースケースで横展開ができる「他業種への横展開」よりも共用できるシーン・現
場数が多いと考えられるためである。
例えば、画像認識 AI を用いた適用業務を製造ラインにおける検品と人流予測に用いているようなユー
スケースを「他業務への横展開」としている。
令和 2、3 年度 L5G 実証参加団体のうち、ヒアリングを実施した実証参加団体・企業を図 3.6.2-1 に示す。空港・港湾の分野では、協力依頼を行ったもののスケジュールの都合上ヒアリングの実施ができなかった。よって、後述する AI ベンダーへのヒアリングを行うことで業界におけるユースケースや要件に関する情報を補填する形とした。
表 3.6.2-1 ヒアリングを実施した令和 2、3 年度 L5G 実証団体一覧
業界

ヒアリングの協力企業

工場・発電所

住友商事株式会社

農業・林業

株式会社エヌ・ティ・ティ・データ経営研究所

医療・ヘルスケア

トランスコスモス株式会社

文化・スポーツ

株式会社電通九州、株式会社電通国際情報サービス

鉄道・道路

清水建設株式会社

防災・減災

中央復建コンサルタンツ株式会社

スマートシティ

株式会社長大、パナソニック コネクト株式会社

空港・港湾

―

ヒアリング項目を図 3.6.2-2 に示す。
設問 1「ソリューション利用対象」については、各団体が過年度で構築したソリューションを単一事業者のみが利用することを想定していたか、もしくは複数の事業者が利用することを想定した設計を行ったかを確認した。
設問 2「他業種・他分野へのソリューション横展開への想定状況」では、そのソリューションを横展開できる可能性があるかを確認した。想定している場合には、どんな用途・業務が共通であるために共用可能性があるのかを把握する目的で、具体的にどの業種・分野への展開を想定しているか、その業種・分野への展開が考えられる理由を確認した。また、その業種・分野へ展開する際に課題となる事項についても追加で確認した。
設問 3「システム実装形態」では、ソリューションがオンプレミスで構築されたものか、クラウド上に構築されたものかを確認した。現場の特性や業界特有の制約により、その構築形態が選択された理由があると考え、それぞれの構築環境を選択した背景も追加で確認した。特定の業界によってはクラウド
上へのデータのアップロードが難しいといった制約や、セキュリティ性に不安があるといったユーザの217

意見もあるかと考え、クラウド上への構築の場合にはインターネットでの公衆回線での接続か専用線などでの閉域回線での接続かについても確認した。また、ソリューション構築にかかる稼動や共用部分を把握する目的で、実証内で独自で開発した部分と既存システムを活用して構築されている部分についても確認した。
設問 4「現在のソリューション横展開や事業展開などの実装に向けた営み」では、実証完了後から現在にかけて継続した横展開可能性の検討を行なっているかを確認し、よりユーザに受け入れられるための汎用性向上に向けた工夫点についても確認した。
設問 5「横展開、事業展開において、機能・非機能要件といった要件を設定するうえでの観点や課題」
では、設問 4 からさらに詳細な課題や要件をお聞きする目的で、システム機能面・サービス提供面双方での課題や検討・配慮が必要な事項について確認した。
表 3.6.2-2 令和 2、3 年度 L5G 実証団体へのヒアリング項目

b. 各業界において導入実績の豊富な AI ベンダーへのヒアリング
令和 2、3 年度 L5G 実証参加団体でのソリューション導入は実証段階であり、特定の現場や単一事業者への個別最適なソリューション開発が行われている最中である。一方でソリューションが社会実装されており、実際に多くのユーザにソリューションの導入が進んでいる企業にもヒアリングを行うことで、業界における幅広い課題感や要件を把握できると考えた。また、令和 2、3 年度 L5G 実証の中で各業界の課題、社会実装の障壁として挙がった事項に対しても、実証の段階から社会実装に至るうえでの検討
観点について示唆が得られると考え、ヒアリングを実施した。
令和 2、3 年度 L5G 実証参加団体同様、画像認識 AI ソリューションを構築している企業にヒアリングを実施すべく、以下に該当する企業に協力を依頼しヒアリングを実施した。特に、売上規模が大きい企
業や国や自治体などの協力を得ているソリューションは、より幅広い事業者向けに開発が行われている
218

と想定されるため、企業・ソリューション検索の際に留意した。
各業界において導入実績の豊富な AI ベンダーのうち、ヒアリングを実施した企業およびヒアリング
対象のソリューション名を図 3.6.2-3 に示す。スマートシティ分野においては、社会実装されているソリューションの検索段階で、スマートシティ分野は様々やユースケース、ソリューションが集合する分野であり、スマートシティならではのユースケースや要件が存在するわけではなく、それぞれのユース
ケースは他分野で挙げられているものと同様または類似していることが分かった。そのため、他分野でのヒアリングを通して得られる情報により共用形態を検討することとした。
表 3.6.2-3 ヒアリングを実施した AI ベンダー一覧
業界

ヒアリングの協力企業

対象ソリューション/サービス

工場・発電所株式会社フツパー

メキキバイト

農業・林業

1 社（企業名非公開）

非公開（AI を活用した空撮ドローン、営農ソリューション等）

医療・ヘルスケア

エルピクセル株式会社

EIRL

文化・スポーツ株式会社 NTTSportict

スポーツ映像ソリューション

鉄道・道路

DataRobot Japan 株式会社

DataRobot

防災・減災株式会社 SpecteeSpectee Pro

スマートシティ

―

―

空港・港湾

丸紅ネットワークソリューション

TRASCOPE-AI

ズ株式会社
ヒアリング項目を表 3.6.2-4 に示す。
設問 1「他業種・他分野へのソリューション横展開への想定状況」では、そのソリューションを横展開できる可能性があるかを確認した。想定している場合には、どんな用途・業務が共通であるために共用可能性があるのかを把握する目的で、具体的にどの業種・分野への展開を想定しているか、その業種・分野への展開が考えられる理由を確認した。
設問 2「システム実装形態」では、ソリューションがオンプレミスで構築されたものか、クラウド上に構築されたものかを確認した。現場の特性や業界特有の制約により、その構築形態が選択された理由があると考え、それぞれの構築環境を選択した背景も追加で確認した。業界によってはクラウド上へのデータのアップロードが難しいといった制約や、セキュリティ性に不安があるといったユーザの意見もあるかと考え、クラウド上への構築の場合にはインターネットでの接続か専用線での接続かについても確認した。
設問 3「汎用的に利用されるソリューションを構築するために工夫した点」では、ソリューションの導入を進めるための工夫、運用上での工夫等を確認した。本設問では、令和 2、3 年度 L5G 実証団体へのヒアリングを通して、各団体共通で挙げられていた収益性確保や運用保守の観点等を、実際に複数のユーザにソリューションを提供する中で把握していると想定し確認した。
219

設問 4「5G インフラ普及により期待できるサービスの発展性について」では、5G 通信基盤が進歩、普及・展開することで、享受できる大容量、低遅延性、多数同時接続の実現によってサービスがアップデー
トされ、さらに共用が進むケースが考えられるかという点を確認した。
表 3.6.2-4 AI ベンダーへのヒアリング項目

検証結果(1) 各社ヒアリング結果
a.令和 2 年、3 年度 L5G 実証参加団体と b.各業界において導入実績の豊富な AI ベンダーに対して、分野横断的に 5G ソリューションが普及・展開していくために、各業界のユースケースや課
題感、ソリューションの導入に際して検討・配慮が必要となる内容を確認した結果を以下に示す。
a. 令和 2、3 年度 L5G 実証参加団体へのヒアリング
問 1,2 に関する各社の回答を表 3.6.3-1 にまとめる。
問 1：ソリューション利用対象
問 2：他業種・他分野へのソリューション横展開への想定状況

220表 3.6.3-1 令和 2、3 年度実証団体へのヒアリング回答内容
問 1「ソリューション利用対象」、
問 2「他業種・他分野へのソリューション横展開への想定状況」

問 3 に関する各社の回答を図表 3.6.3-2 にまとめる。
問 3：システム実装形態

221

表 3.6.3-2 令和 2、3 年度実証団体へのヒアリング
問 3「システム実装形態」

222

問 4,5 に関する各社の回答を表 3.6.3-3 にまとめる。
問 4：現在のソリューション横展開や事業展開などの実装に向けた営み
問 5：横展開、事業展開において、機能・非機能要件といった要件を設定するうえでの観点や課題

223

表 3.6.3-3 令和 2、3 年度実証団体へのヒアリング
問 4「現在のソリューション横展開や事業展開などの実装に向けた営み」、問 5「横展開、事業展開に
おいて、機能・非機能要件といった要件を設定するうえでの観点や課題」

224

225

b. 各業界において導入実績の豊富な AI ベンダーへのヒアリング

問 1 に関する各社の回答を表 3.6.3-4 にまとめる。
問 1：ソリューション展開状況

226表 3.6.3-4 各業界において導入実績の豊富な AI ベンダーへのヒアリング回答内容
問 1「ソリューションの展開状況」

問 2 に関する各社の回答を表 3.6.3-5 にまとめる。
問 2：システム実装形態

227

表 3.6.3-5 各業界において導入実績の豊富な AI ベンダーへのヒアリング回答内容
問 2「システム実装形態」

問 3 に関する各社の回答を表 3.6.3-6 にまとめる。
問 3：汎用的に利用されるソリューションを構築するために工夫した点

228

表 3.6.3-6 各業界において導入実績の豊富な AI ベンダーへのヒアリング回答内容
問 3「汎用的に利用されるソリューションを構築するために工夫した点」

229

問 4 に関する各社の回答を表 3.6.3-7 にまとめる。
問 4：5G インフラ普及により期待できるサービスの発展性について230

表 3.6.3-7 各業界において導入実績の豊富な AI ベンダーへのヒアリング回答内容
問 4「5G インフラ普及により期待できるサービスの発展性について」(2) ヒアリング結果の整理および各社の傾向
a.令和 2 年、3 年度 L5G 実証参加団体と b.各業界において導入実績の豊富な AI ベンダーに対して、分野横断的に 5G ソリューションが普及・展開していくために、各業界のユースケースや課
題感、ソリューションの導入に際して検討・配慮が必要となる内容を確認した。以下では、ヒアリング結果を整理、および各社の傾向をまとめる。
a. 令和 2、3 年度 L5G 実証参加団体へのヒアリング問 1. ソリューション利用対象
ヒアリングを実施した 8 団体中 7 団体が「複数の事業者がソリューションを利用することを想定した。
」と回答。
「単一事業者のみが利用することを想定。」と回答した 1 団体に関しても、実証中事業の中で費用対効果が実証された場合は複数の事業者に展開していきたいという意向を持つ。
上記より、複数事業者での共用化を見込む団体を対象としてヒアリングができたと言える。
問 2. 他業種・他分野へのソリューション横展開への想定状況
想定する業種・分野は各団体のソリューション毎に様々であったが、他業種、他分野への展開方法として、大きく以下の 3 パターンに分けられた。
A.同業種への横展開
B.他業種、同用途への横展開231

C.ステークホルダー内の他業種への横展開（病院→消防など）
問 3. システム実装形態
ヒアリングを実施した団体のソリューションの 14 個のうち、9 ソリューションがオンプレミスでの実装であった。
オンプレミスを選択した理由として、以下が挙げられた。
・実装コスト
・運用性
・L5G の低遅延性を活かす構成
・クラウドにした場合の従量課金コストへの懸念
一方で、クラウドを選択した 5 つのソリューションについて、クラウド実装を選択した理由として以下が挙げられた。
・将来の機能拡充のしやすさ
・利用者が大幅に拡大することを想定した際のコストメリット
・利用者側の環境整備負担低減
問 4. 現在のソリューション横展開や事業展開などの実装に向けた営み
5G ソリューションとして、インフラ〜アプリケーションまでのシステム全体の展開に向けた営みを継続できているのは、14 個のソリューションうち、1 ソリューションという結果となった。
一方、アプリケーションもしくは、アプリケーション内の 1 パーツの有効性が認められ、横展開に向けた営みを継続できているものであれば、14 個のソリューションうち、10 ソリューションとなった。
横展開の営みが継続されているソリューションの傾向をまとめると以下となる。
・クラウド形態でサービスが実装されており、API を活用して他システムと連携しやすい形態で提供されている（電通九州：姿勢推定）
・映像伝送、双方向でのコミュニケーション 等のシンプルかつあらゆる用途での利用が見込めるアプ
リケーション（トランスコスモス、電通九州：多視点映像、遠隔指導、パナソニック）
問 5. 横展開、事業展開において、機能・非機能要件といった要件を設定するうえでの観点や課題◆横展開における課題
横展開、事業展開をしていく中で課題となる事項は、大きくソリューションの提供を行う際に起きる
課題と、通信インフラに関わるものの 2 つに大別された。
＜ソリューション提供＞
ソリューションを提供していくうえでの課題として、以下 3 点が挙げられた。
・画像認識の性能に関するもの
232

・SaaS 型にすることによるもの
・セキュリティの観点
画像認識については、異なる現場環境（天候や日照条件、デバイス、人の判断基準）への柔軟な対応の必要性が高い点を挙げる団体が多かった。また、AI の精度が発現し、実運用開始に至るまでに膨大な
AI の学習データが必要であることも課題として挙げられた。
SaaS 型でソリューションを提供していく際に、大容量データの保存、処理にかかる従量課金の費用が大きくなってしまうことも課題として挙げられた。
セキュリティ性の担保の観点では、機密情報の保全が重要であり、その要件が事業者ごとに異なる点も留意する必要があるとの回答があった。また、特に画像認識をするケースでは第三者が写り込む可能性のある場所での運用に留意しなければならないという回答もあった。
＜通信インフラ＞
通信インフラに関する観点として、以下 3 点が挙げられた。
・現状 L5G のコストが高いため、コストに見合うだけの必要性もしくは、多目的での利用が必要となる。
・現場での取り回しの悪さ（現場に 5G の無線技術を理解したエンジニアが必要）
・通信の不安定さ
L5G のインフラ整備コストについては、単独のユースケースに対して通信インフラを構築するには、価格が見合わないこともあり、L5G の通信インフラ上で活用するソリューションを可能な限り集積し、
複数のユースケースに対応可能とすることによるコスト低減の方策が必要であるという回答があった。
通信インフラを課題解決の現場に構築することにより、インフラ機材の故障やトラブルが起きた際に事業者自身でトラブルシューティングすることが難しいことが課題として挙げられた。仮に、この運用・保守を続ける場合には 5G 通信インフラを理解したエンジニアの運用支援が必要になるという回答があった。
通信の不安定さについては、画像認識や映像伝送などのデータ通信を行う場合に無線区間のスルー
プットが安定せず、映像のフレームレートが一定にならないことも課題として挙げられた。特に、リア
ルタイム性が求められるシーンでは映像の乱れが影響してくるため、特に留意が必要な点と考えられる。
◆横展開させるために行った工夫
横展開を進めていくうえでの工夫点として、以下の項目が挙げられた。
・直感的な UI
・あらゆるデバイスに対応できる接続性
・Web ブラウザ等の汎用的なデバイスで利用できるアプリにする
233

・Web API を公開することで他社のソリューションと連携して使用できるサービス形態とする・システム全体としてではなく、特定のアプリケーション毎の機能強化・精度向上に取り組む
・アプリケーションの要求品質を落とすために、解析画像の画質、フレームレートを落として細切れ画像で解析。これにより、トランザクションとトラフィック量を落とし、基盤側のランニングコストを低減する仕組みをとる
ユーザビリティや汎用性を高める工夫として、直感的な UI、あらゆるデバイスへの互換対応、Web ブ
ラウザ等での利用対応といったものが挙げられた。アプリケーションそのものの機能だけでなく、UI/UX
への配慮もソリューションを展開していくうえで重要な要素であると捉えられる。また、高解像度の俯瞰映像に対する基本的な操作（ズーム、移動、巻き戻し）や、絵や文字の書き込み等の付加価値のある機能を実装することで、さらなる価値向上が見込めるものと想定する。
Web API の公開や、特定のアプリケーションの機能強化については、インフラも含めたシステム全体の横展開として捉えるのではなく、利用が見込まれる機能から徐々に展開を進めていくというアプロー
チである。
コスト面については、アプリケーションの要求品質を落とし、インフラ側のトランザクション量を軽減していくという手法が見られた。この際、ユーザのニーズを充足する範囲内で品質を落とすことが重要である。

b. 各業界において導入実績の豊富な AI ベンダーへのヒアリング問 1. ソリューションの展開状況
ヒアリングを実施した AI ベンダーの中には、以下 3 パターンの AI ソリューションの提供方法が見られた。提供形態によって他業種・他分野への展開のしやすさが異なっていることが読み取れた。それぞれのモデルの特徴を表 3.6.3-8 に示す。
A：複数の利用者に対して一つの共通のモデルを展開する
B：利用者毎に個社毎のモデルを構築する
C：利用者のモデル構築を支援する
A のモデルの場合、現在展開中の分野内での利用拡大を目標としている回答者が多く見られたことか
ら、多分野への展開し難い方法と考えられる。一方で、大規模事業者に限らず、小規模な事業者にも展開を進めている回答者も存在していることから、利用者側の費用面及び、稼働面の導入負担を減らすことに適している提供方法であると考えられる。AI の判断基準に利用者毎の差異がないことが条件での展開になる。
B のモデルは、本実証で構築した鉄道車両監視 AI と同様の提供スキームである。当モデルに該当する
234

企業は、フツパー1 社のみであったが、製造業を利用者の中心としつつ、物流、第一次産業等において、人の目による判断を置き換えるという汎用性の高い用途で利用されている実績がある。このことから、同用途に限定されるものの、A の提供方法と比較すると多分野に展開しやすい方法と考えられる。当モ
デルの場合、仮に学習データとなる教師データが少ないケースでも学習が可能なベースモデルの構築が求められる。A と比較すると、モデルの導入後は利用者独自の追加学習が可能であることから、AI の判
断基準のカスタマイズ性は高いものと言える。
C のモデル該当する企業としては、DataRobot1 社のみであったが、既に多数の業界での導入実績を有していることから、A と B の提供方法と比較すると最も多分野への展開がしやすい提供方法であると考えられる。ただし、利用者自身がモデルを構築することが求められるため、A、B と比較すると利用者側の稼働・費用負担は大きくなりやすい傾向にあると考えられる。そのため、提供者側がより手軽にモデルを構築できるような体制作りを促していくことが求められる。利用者独自のモデルとなるため、3 つの提供方法のうち最も AI の判断基準のカスタマイズ性が高い。
表 3.6.3-8 各モデルの特徴

問 2. システム実装形態
ヒアリングを実施した 7 社の AI ベンダーのうち、6 社はクラウド環境での構築に対応していた。残り
1 社のフツパーに関しては、クラウドとオンプレミスを併用する形態で提供しているとの回答であった。
7 社中 4 社はエンドユーザの希望によってはオンプレ環境での構築が可能な柔軟性を持たせた上で提供されているということもわかった。
これらの結果から、汎用的なソリューションを提供する際にはクラウド環境で構築することが一般的であると考えられる。
クラウド環境でソリューションを提供することについては、概ねどの業界においても可用性、セキュ
リティ性の観点で受け入れられることがわかった。ただし、エルピクセルの回答より、病院向けに提供する場合は、病院内のデータを院外に出さないような仕様を求められることが多く、オンプレミスでの構築や、エッジ側に AI モデルを配置する構成が必要となることが想定される。
235

また、可用性、セキュリティ性の観点で受け入れられている状況にありながらも、オンプレ環境を選択可能としているベンダーが多い理由として、処理結果をリアルタイムに出力することと、クラウド
サーバの利用にかかる従量課金費用を抑えることの 2 点が挙げられる。フツパーがクラウド環境とオン
プレ環境を併用している理由も同様であった。
問 3. 汎用的に利用されるソリューションを構築するために工夫した点
ヒアリング結果を大きく分類すると、以下 3 点について言及されている傾向にあった。
①利用者側の環境に合わせたソリューション構築を速やかに行うこと②短期間で利用者がソリューションを使いこなせる簡便性を備えていること③安心して利用してもらえる提供体制を整えること①については、利用者側・ベンダー側双方に負担をかけないで環境構築を行うための工夫と、異なる環境、要望に対して柔軟に対応するための工夫の 2 つのアプローチがヒアリングから確認できた。
利用者側・ベンダー側双方に負担をかけないで環境構築を行うための工夫については、SaaS 型で導入時の負担を低減して提供することや、少ない学習データで識別精度を上げる仕組み（フツパー）、モデル構築を自動化する仕組み（DataRobot）等があった。
異なる環境、要望に対して柔軟に対応するための工夫については、多種多様なデータから分析可能なデータに整えるための工夫と、システムが対応可能なデータの範囲を広げる工夫の 2 つのアプローチが見られた。
分析可能なデータに整えるための工夫については、収集されたデータに対して人間の手やシステムによってデータクレンジングを行うことや、収集されるデータを均質化するために、センシングデバイスの設置・設定までをベンダー側の専門家が担当する等の取り組みが挙げられていた。システムによるデータクレンジングについては、取得した画像を鮮明化する処理を行うことや、データクレンジング
ツールをベンダー側が提供する等の対応が確認できた。
システムが対応可能なデータの範囲を広げる工夫については、画像、位置情報、音声、テキスト等複数のデータ形式に対応可能なようにシステムを構築することや、あらかじめブレのあるデータ（画像等）
を AI に学習させることで、多少の環境条件の変動によるデータの差分にも対応可能な AI モデルを構築する等の対応が確認できた。
②については、直感的な操作感を持たせることと、利用者側が行う範囲を限定することの 2 つのアプ
ローチがヒアリングから確認できた。
直感的な操作感を持たせることについては、説明書を読まずとも利用者が迷わないシンプルなユーザ
インターフェースを整えることや、利用者が使い慣れたデバイスやアプリケーション上で動作するように設計すること等が挙げられていた。
利用者側が行う範囲を限定することについては、利用者側が AI の学習、設定に関わる必要がないよう、ベンダー側が一元的にこれらの作業を行う提供方法や、導入時の機器設置・設定についても事業者側が請け負うことができるようにサービス設計を行う等の工夫が見られた。ヒアリング回答者の 7 社中
236

5 社、がベンダー側で AI の学習、設定を一元的に行う形態を取っていることからも、利用者側が行う範囲を限定するという点は汎用的に利用されるソリューションを構築する上で重要な要素であると考えられる。利用者が AI の学習、設定を行う提供方法を選択しているフツパーと DataRobot の 2 社においても、自動でモデルが構築される仕組みや、ノーコードで追加学習ができる仕組み等、利用者側を補助する工夫が施されている。
③については、利用者のセキュリティ性・可用性に関する要望に柔軟に対応するために SaaS 型と DL
型の方法に対応するという工夫と、ソリューション導入後の運用時かかる利用者側の負担を軽減するための仕組みを整えるという工夫の 2 つのアプローチが見られた。
ソリューション導入後の運用時にかかる利用者側の負担を軽減するための仕組みとしては、システムの死活監視や、不具合発生時のオンサイトでの駆けつけサポート、運用中の AI モデルの精度監視シス
テム等が挙げられている。
また、SLA を設定し公開することや、外部機関によるセキュリティ認証を取得することも利用者に安心して導入してもらうために行なっているということが確認できた。
問 4. 5G インフラ普及により期待できる貴社サービスの発展性について
ヒアリングした AI ベンダーからは、5G インフラの普及に対して、大別すると以下 2 通りの期待の声を聞くことができた。
a.これまで収集することができなかった新たなデータの取得が可能となることによって、AI を活用できる用途がさらに広がることに期待する。
b.大容量データの低遅延での伝送が可能となることによって、クラウドサーバ側の膨大なリソースを活用した複雑なデータ処理が可能となることに期待する。
例として、道路上の運搬車に設置したセンサーからデータを取得し、クラウド側のビッグデータと掛け合わせて解析を行うことや、工場内のあらゆる機器にセンサーを設置し、取得するデータを横断的に分析することによって、不具合発生時に発生原因の追及と対策を AI が自動で行うこと等が挙げられていた。

分野横断的な 5G ソリューションの横展開に求められる機能検証まとめ(1) 5G ソリューションの汎用化に向けた課題整理
令和 2、3 年度 L5G 実証参加団体へのヒアリングを通して得られた、5G ソリューションの普及展開に向けた課題を整理すると、5G ソリューションそのものが利用者から求められている機能要件及び、非機能要件を満たすことができているかという点と、5G ソリューションの導入により得られる効率化の効果
が、導入費用を上回っているかという点に大別できる。

237

＜機能要件/非機能要件＞
5G ソリューションそのものが利用者から求められている機能要件及び、非機能要件を満たすことができているかという点においては、以下のような課題が挙げられていた。
機能要件としては、2 点あり、実運用開始までに膨大な AI の学習データが必要になる点と、天候、日
照条件、デバイス毎の差異等の変化への柔軟な対応という声が多くあった。
非機能要件については、信頼性・可用性、セキュリティ性、運用保守性といった要素に分解しつつ、課題の整理を行なった。信頼性・可用性としては、L5G での無線区間でのスループットが安定しにくいという回答が見られた。セキュリティ性に関しては、機密情報の保全体制と、第三者が映り込む可能性のある場所での運用の仕組みの 2 点が挙げられた。運用保守性に関しては、現場での取り回しの悪さが課題として挙げられていた。（表 3.6.4-1 参照）＜費用対効果＞
5G ソリューションの導入により得られる課題解決効果が、導入費用を上回っているかという点においては、大容量データの保存、処理にかかるクラウドサーバの従量課金費用が高くなりやすいという課題と、ローカル 5G のインフラ構築・運用コストが高額になりやすいという課題が挙げられていた。
表 3.6.4-1 令和 2、3 年度 L5G 実証参加団体より挙げられた課題
大分類
信頼性・

要件
L5G 無線区間のスループットが安定しにくい

可用性
セキュリティ 機密情報の保全
第三者が写り込む可能性のある場所での運用の仕組み
性能・異なる現場環境（自然環境、デバイス、人の判断基準）への柔軟な対応

拡張性

実運用開始までに膨大な AI の学習データが必要

移行性

実運用開始までに膨大な AI の学習データが必要

運用・

現場での取り回しの悪さ（現場に 5G の無線技術を理解したエンジニアが必要）

保守性
導入効果

大容量データの保存、処理にかかる従量課金費用
ローカル 5G の構築・運用コストが高額になりやすい(2) 分野横断的に利用可能な 5G ソリューションを開発するための要件
前項で整理した 5G ソリューションの普及展開に向けた課題に対して、令和 2、3 年度 L5G 実証参加団
体、各業界において導入実績の豊富な AI ベンダー（以降、AI ベンダー）へのヒアリングを通して得られた知見をもとに、（A）にて課題の解決策を検討する。AI ベンダーからは、課題に対する対策以外にも、汎用的に利用されるソリューションを構築するための工夫点をヒアリングすることができたため、後述
238

の（B）AI ベンダーの取り組みから普及展開に向けて活かせる工夫点では、AI ベンダーの取り組みから普及展開に向けて活かせる工夫点もまとめて記載する。

（A）課題への対応＜機能要件/非機能要件＞
利用者から求められる機能要件及び、非機能要件を満たすために挙げられた課題については、以下のような対策を講じることが有効ではないかと考えられる。（表 3.6.4-2 参照）◇信頼性・可用性における L5G のスループットが安定しない
この課題に対しては、AI ベンダーからの対策手法が上がらなかった。
机上検討に留まるが、・無線通信区間を経由する通信系統を冗長系統とし、NW の品質劣化時の可用性を向上する。
・データ欠損時の再送処理や欠損部分の補完処理をアプリケーション側で機能実装する。
などの解決策が考えられる。
また、将来的な観点としては、5GSA が広く利用できる状況となった場合には、5GSA のもつネットワー
クスライシング技術の活用によってスループットの安定が図れる可能性が考えられる。この点について
は、ネットワーク提供事業者の実装にも依存する仕様となるため、今後の実装状況を確認しながら、適用の検討を行うべきである。
◇セキュリティ性における機密保全や、第三者が写り込む可能性のある場所での運用の仕組み
この課題に対しては、以下のような対策が考えられる。
・各認証機関が掲げるセキュリティ認証を取得し、セキュリティ水準を担保すること。
・利用者によってセキュリティ要件が異なる場合に対応するべく、クラウドを活用する SaaS 型と現地および利用者の手元で利用するオンプレミス環境に対してアプリケーションを配布する DL 型の双方を備えておくこと。
・利用者のセキュリティ要件が厳しい場合には、AI の学習モデルをエッジデバイス上に構築しクラウド
上へのデータアップロードは最小限とする 。
・5GSA で実装が予定されているセキュリティ技術を活用してネットワークレイヤーのセキュリティを担保する。この点については、各ネットワーク提供事業者の 5GSA の機能向上の進捗を確認しながら、実装可能性を検討することが必要と考える。
◇性能・拡張性において異なる現場環境（自然環境、デバイス、人の判断基準）への柔軟な対応が必要であること、実運用開始までに膨大な AI の学習データが必要となる。
この点に対しては、以下のような対策が考えられる。
・AI での処理・解析を行う前に色調調整などの画像鮮明化処理を施す。
239

・カメラの種類の選択・設置・調整を利用者にアドバイス/コンサルティングする。
・モデル構築の際に、学習データの収集・整理にかかる負担を軽減する仕組みを整える。
・あらゆるデバイスに対応できる接続モジュールとすることで、利用者の選択したデバイスによって使用不可となるケースを減らす。
◇移行性における実運用開始までに膨大な AI の学習データが必要となる点
この点については、少ない学習データで効率良く検知精度を高められるベースモデルを構築することにで、新規利用者に導入する際の双方の稼働負担を抑えることができると考える。
◇運用・保守性における現場での取り回しの悪さ（現場に 5G を理解したエンジニアが必要）
この点について、以下のような対策が考えられる。
・ソリューションの構築～設定までをベンダー側で実施する。仮に利用者が行う場合でも、設定の補助となる機能を具備する。
・死活監視、モデルの精度監視といったシステム異常の際のアラートが即座に出せるような保守性の担保を行う。
表 3.6.4-2 非機能要件に対する対策例
大分類

課題

対策

信頼性・

L5G 無線区間のスルー ・無線区間を経由する場合は複数系統での冗長/バックアップを行

可用性

プットが安定しにく う。
い・アプリケーションによりデータ再送制御や欠損補完の品質制御機能を実装する。

セキュリ

機密情報の保全・セキュリティ認証を取得。

ティ性

第三者が写り込む可 ・利用者のセキュリティ性・可用性に関する要望に柔軟に対応す
能性のある場所での るために SaaS 型と DL 型の双方に対応。
運用の仕組み・セキュリティ要件の厳しい利用者の場合は学習モデルをエッジ側に構築可能とする。

性能・異なる現場環境（自然 ・AI での処理を行う前に色調調整の処理を通しておくことや、カ

拡張性

環境、デバイス、人の メラの選択、設置、調整の部分をコンサルすることで識別精度を判断基準）への柔軟な 安定させる工夫を行なう。
対応

・AI のモデル構築を行う際に、学習データ収集、整理にかかる利実運用開始までに膨 用者側の稼働負担を軽減するような仕組みを整える。
大な AI の学習データ ・あらゆるデバイスに対応可能な接続モジュールを設計する。
が必要
移行性

実運用開始までに膨 ・少ない学習データで効率良く検知精度を高められるベースモデ
大な AI の学習データ ルを構築することにより、新規利用者に導入する際の双方の稼働が必要

負担を抑える。
240

運用・

現場での取り回しの ・ソリューションの構築、設定までベンダー側で行う（利用者が行保守性悪さ（現場に 5G の無 う場合は機能的なサポートを加える）
線技術を理解したエ ・運用部分もシステム的にカバーする（死活監視、モデルの識別精
ンジニアが必要）度監視）＜費用対効果＞
・費用の削減費用対効果に関する課題について、費用を削減しつつ、導入効果をより大きくしていくというアプ
ローチが必要であると考えられる。費用を削減するという点においては、費用を構成する要素に分解し、構成要素毎に作業の効率化もしくは、より効率化している企業へのアウトソーシングを検討することで、削減できる要素がないかを探る。
5G ソリューションを構成する要素としては、大まかに、システム基盤、5G インフラ、利用者側システ
ム導入環境、運用保守サービスが考えられる。ただし、5G インフラに関しては、通信キャリアが提供することが一般的であり、ソリューションベンダーの立場からはより安く提供している通信キャリアを選定するといった費用削減方法に限られるため、ここではシステム基盤、利用者側システム導入環境、運用保守サービスについてのみ費用削減の方法を検討することとする。
システム基盤と利用者側システム導入環境については、ハードウェア費用や、ソフトウェアのライセ
ンス料等も要素として挙げられるが、これらの費用に関しては他社から購入しているものであるため、大幅な削減は見込みにくい。対して、費用削減に取り組みやすい要素としては、システムの構築費用があり、これは「エンジニアの時給×稼働時間」で大まかに算出することができる。また、運用保守サー
ビスに関しても同様に、「エンジニアの時給×稼働時間」で大まかに算出することができる。エンジニアの時給の削減と、稼働時間の削減によってシステム基盤、利用者側システム導入環境、運用保守サービスの費用削減を検討することとなるが、エンジニアの時給を削減する方法に関しては、人事領域の施策となり、本報告書の目的と異なるため、今回は取り扱わないものとする。
よって、システム基盤、利用者側システム導入環境、運用保守サービスにかかる稼働時間の削減について、以下で検討を行う。
システム基盤の構築については、大きく要件定義、基本設計、詳細設計、開発、テスト、リリースの6 段階のフェーズに分かれており、提供するソリューションを都度全て自前で構築すると、膨大な時間が必要となってしまう。そこで、既に他社が実装している機能と共通する部分については、新たに自前で構築するのではなく、他社から提供を受け、パーツとしてシステム内に組み込むことによって、新たに構築が必要な箇所を減らすという工夫が考えられる。
利用者側システム導入環境の構築についても、システム基盤の構築と同様に大きく 6 段階のフェーズに分かれている。利用者側システム導入環境の構築については、SaaS 型としてシステム基盤を構築する
ことで、利用者毎に独自のシステム導入環境を構築する必要がなくなり、この工程自体をほとんど省略241

することができる。
運用保守サービスに関しては、大まかには定常時の監視、運用業務と、非常時の障害対応の業務があるが、いずれにしてもシステムへのアクセスを行なった上で作業することが必要である。システムがオンプレミス環境で構築されており、外部からのアクセスが許可されていない場合や、ハードウェアに対して問題が発生している場合は現地への駆けつけが必要となり、移動時間が発生することとなる。SaaS型としてシステム基盤を構築する場合、すべての利用者の運用保守サービスを一元的に行うことができ、移動も伴わないため、大幅な稼働削減に繋がることが見込まれる。さらには、サーバ自体の運用も、より安価に安定的に運用が可能なクラウドサーバ事業者側に委託することが可能なため、効率化が可能である。より効率的に運用保守サービスを行う場合は、機器の死活監視等の仕組みを組み込むことや、負荷に応じてクラウドサーバ側のリソースを自動で可変するオートスケーリングの仕組みを組み込むことでも運用保守の稼働時間削減に効果があると考えられる。
・効果の向上
導入効果を高めるという点においては、利用者にとってより重要度の高い課題を解決することによって導入効果を高める方法と、複数の課題を 5G ソリューションにより解決することで導入効果を高める
方法とが考えられる。
しかしながら、現状の 5G インフラの導入コストに対して費用対効果を創出しようとすると、重要度の高い課題であっても、単一の用途で費用対効果を発揮することは難しく、ヒアリングした多くの実証
参加ベンダーが複数用途での 5G インフラの共用が必要であると回答している。そのため、複数用途で
5G インフラを共用していくことが求められるということが改めて確認された。
また、実用可否の面での要点とも関連するが、「利用者にとってより重要度の高い課題を解決する用途」においては、高い安定性、高い精度を求められる傾向にあり、実用可能と認められるまでに技術的な検証、運用面での検証、運用ルールの策定等、長期間を要することが考えられる。
そのため、上記 2 点を踏まえ、5G ソリューションを普及展開させる際には、ファーストステップとして、実用化までのハードルが低い用途での汎用ソリューションを複数開発・実装することにより 5G イ
ンフラ上において利用可能なソリューションの数を増やす。次にセカンドステップとして、ファーストステップにて開発したソリューションを高い安定性、高い精度が求められる用途に横展開した上で安定性に問題がないことを確認する。その後、サードステップとして、より導入効果の高い用途での汎用ソリューションの新たな開発を進めることが有効ではないかと考えられる。
ファーストステップでは、以下の条件を満たすソリューションの開発が考えられる。
・5G ならではの特徴を活かせる
・多業種・多分野で汎用的に活用されることが期待できる・高い安定性、高い精度が必ずしも必要とされない用途
242

ソリューション例：― 高画質カメラでの俯瞰映像配信― 複数カメラでの多視点映像配信
セカンドステップでは、以下の条件を満たすソリューションの開発が考えられる。
・5G ならではの特徴を活かせる
・多業種・多分野で汎用的に活用されることが期待できる・高い安定性、高い精度が求められる用途
ソリューション例：― 医療現場での高画質カメラでの俯瞰映像配信― 建設現場での俯瞰映像配信― スポーツ、エンタメ領域での俯瞰および多視点映像配信
サードステップでは、以下の条件を満たすソリューションの開発が考えられる。
・ビジネスインパクトの大きな用途（稼働時間が大きい、人が不要になる、危険が伴う）
・5G ならではの特徴を活かせる
・多業種・多分野で汎用的に活用されることが期待できる
ソリューション例：― 鉄道現場での運行中車両の無人点検― 建設現場での建設機械自動操縦― 医療現場での遠隔手術

図 3.6.4-1 5G ソリューションの導入効果を発現する 3 ステップ

243

（B）AI ベンダーの取り組みから普及展開に向けて活かせる工夫点
利用者側のソリューションに求める機能要件、非機能要件を満たすという点については、利用者毎に細かな要件は異なるものの、実証ベンダー7 社、AI ベンダー7 社へのヒアリングを通して、複数業界で共通して求められる要件の抽出を行なうことができた。
表 3.6.4-3 複数業界で共通して求められる要件
大分類

要件

信頼性・ ・SLA の設定、公開
可用性・システム負荷に合わせたリソース調整の自動化
・いずれの業界でも SaaS を利用することは可能＜推奨要件＞
・利用者ごとに設定されている独自の社内規定に柔軟に対応するため、SaaS 型と合わせてDL 型での提供にも対応ができることが好ましい
セキュリ ・外部機関によるセキュリティ認証の取得
ティ・いずれの業界でも SaaS を利用することは可能＜推奨要件＞
・利用者ごとに設定されている独自の社内規定に柔軟に対応するため、SaaS 型と合わせて DL 型での提供にも対応ができることが好ましい
・セキュリティ要件の厳しい利用者にも対応可能とする場合には学習モデルをエッジ側にも構築可能とすることが好ましい
性能・・あらゆるデバイスに対応可能な入出力モジュールの構築

拡張性
・画像、位置情報、音声、テキスト等複数のデータ形式に対応可能な AI エンジンの実装
・説明書を読まずとも利用者が迷わないシンプルなユーザインターフェース
・利用者側で簡易に追加学習を行える仕組みの構築＜推奨要件＞
・学習データの収集・整理にかかる稼働を減らすための支援ツールの提供
244

・高解像度の俯瞰映像や、多視点映像を伝送する機能の構築
・高解像度の俯瞰映像や多視点映像に対する基本的な操作（ズーム、移動、巻き戻し）を行う機能の構築
・撮影時の外部環境による検知性能への影響を抑えるための画像鮮明化処理を加える機
能の構築
・Web ブラウザやメール、チャットアプリ等、利用者が使い慣れているアプリケーション
やデバイス上で動作する仕組み
移行性・SaaS 型でのサービス提供
・API の公開＜推奨要件＞
・少ない学習データで効率良く検知精度を高められるベースモデルの構築

運用・・遠隔地からの機器の死活監視や、トラブル発生時の問題箇所の切り分けを行う仕組み

保守性

の構築
・センシングデバイスの設置、設定までをベンダー側の専門家に委託可能な仕組みの提供

また、既に有償でサービスを展開している AI ベンダーに対してヒアリングを行なったことで、実証実
験段階では顕在化しにくい課題に対する工夫点についてもいくつか確認することができた。これらの観点も加え、要素としては、導入プロジェクトを成功に導くためのプロジェクトマネジメント方法、利用者への学習コンテンツの提供の 2 点が挙げられる。
導入プロジェクトのマネジメントについては、利用者が AI を活用したいと考えている課題が、本当に自社の AI ソリューションを活用すべき課題なのかをよく見極めた上で取り組み始めるという進め方の工夫について、DataRobot と、フツパーより言及があった。
両者とも、AI の識別精度が何%であったらビジネスに実装可能かをプロジェクトの関係者と明確に定める等、ゴールを明確化した上で、乗り越えるべき壁を洗い出し、ゴールまでの実施スケジュールを計画するという点において共通していた。
利用者への学習コンテンツの提供については、利用者にわかりやすいサービス設計にすることは多くのベンダーが工夫していた点であったが、その上で、利用者により有効にソリューションを活用してもらうためのレクチャーや、学習コンテンツを提供しているベンダーも一部で見られた。ソリューション
が広く普及展開された際には、利用者企業内の様々な関係者がソリューションを利用することになるが、その際に問い合わせへの対応稼働が逼迫する可能性もあり、利用者に広く活用方法を伝えるためのレク245

チャーや、e-learning 等の学習コンテンツをあらかじめ準備しておくことも有効であると考えられる。

（C）普及展開可能な 5G ソリューションを開発するための要件普及展開を阻む課題として、費用対効果が創出しにくいという点と、利用者側がソリューションに求める機能要件、非機能要件を満たせていないという問題があることが前項で整理された。
これらの課題解決方法を検討し、整理することによって、普及展開可能な 5G ソリューションの要件として取りまとめを行う。
◇費用対効果を創出しやすくするための取り組みとして、SaaS 型でソリューションを提供すること、他社が既に開発している機能をパーツとしてソリューションに組み込むことによって開発工数を削減することで費用を抑えた開発・運用を行うこと、複数用途で 5G インフラを活用することにより導入効
果を高めることを解決方法として述べた。また、複数の 5G ソリューションを実装するための方法として、実用化ハードルの低い用途にて複数のソリューションを開発した後に、徐々に利用者にとって重要度の高い用途に対応するソリューションを開発していくという開発ステップをまとめた。
利用者側のソリューションに求める機能要件、非機能要件を満たすという点については、利用者毎に細かな要件は異なるものの、
実証ベンダー7 社、シェアの高い AI ベンダー7 社へのヒアリングを通して、複数業界で共通して求められる要件を抽出し、要件表としてまとめた。
これらの条件を全て満たした上でソリューションを提供することができれば普及展開の可能性は高まると考えられるが、各ベンダーが各々で複数の利用者を集め、複数のアプリケーション構築を進める
ことは難易度が高いように考えられる。
そこで、各ベンダーが個別に SaaS 型ソリューションを構築するのではなく、1 つの SaaS 共用基盤を構築し、その基盤上に複数のベンダーがアプリケーションを共用可能な形で公開することによって、単体のベンダーでは難しかった 5G ソリューションの普及展開の実現に近づけることができると考えられる。
その際に SaaS 共用基盤に求められる要件と、基盤上に構築するアプリケーションに求められる要件を以下にまとめる。
＜SaaS 共用基盤に求められる要件＞
普及展開可能な 5G ソリューションに求められる要件に対応するために、必要な要素を押さえた上でSaaS 共用基盤を構築することにより、基盤上に構築するアプリケーションが要件を満たすために意識・対応しなければならないポイントを減らし、開発工数を削減することが期待できる。
そのため、信頼性・可用性、セキュリティ性に関する要素は SaaS 共用基盤側で要件を満たしつつ、ア
プリケーション開発ベンダーが流用できる形で公開することが重要である。また、性能・拡張性において推奨要件として記載してあるポイントについて、SaaS 基盤側にて構築し、アプリケーション開発ベン
ダーがパーツとしてそれらを利用できる形で公開することにより、アプリケーションの開発工数をさら246

に削減することが期待できる。
表 3.6.4-4 ソリューションの共用のために SaaS 共用基盤に求められる要件
大分類
信頼性・

要件
・SLA の設定、公開

可用性・システム負荷に合わせたリソース調整の自動化
セキュリ・外部機関によるセキュリティ認証の取得

ティ性＜推奨要件＞
・セキュリティ要件の厳しい利用者にも対応可能とする場合には学習モデルをエッジ側にも構築可能とすることが好ましい

性能・・あらゆるデバイスに対応可能な入出力モジュールの構築

拡張性

・画像、位置情報、音声、テキスト等複数のデータ形式に対応可能な AI エンジンの実装＜推奨要件＞
・学習データの収集・整理にかかる稼働を減らすための支援ツールの提供
・高解像度の俯瞰映像や、多視点映像を伝送する機能の構築
・高解像度の俯瞰映像や多視点映像に対する基本的な操作（ズーム、移動、巻き戻し）を行う機能の構築
・撮影時の外部環境による検知性能への影響を抑えるための画像鮮明化処理を加える
機能の構築

移行性

・主要なサービスと簡易に連携可能な API モジュールの提供

運用・・遠隔地からの機器の死活監視や、トラブル発生時の問題箇所の切り分けを行う仕組

保守性

みの整備

＜基盤上に構築するアプリケーションに求められる要件＞
SaaS 共用基盤側が普及展開可能な 5G ソリューションに求められる要件に対応するために必要な要素を押さえた上で構築されている場合、基盤上に構築するアプリケーション側が要件を満たすために意識しなければならないポイントを減らすことが期待できる。
信頼性・可用性、セキュリティ性の要件を満たすための稼働を削減し、性能・拡張性、移行性、運用・保守性といった、利用者の利便性向上に繋がりやすい要素に稼働を集中させることができる。
表 3.6.4-5 ソリューションの共用のためにアプリケーションに求められる要件
大分類
信頼性・

要件
・SLA の設定、公開

可用性・システム負荷に合わせたリソース調整の自動化
247

セキュリ

・外部機関によるセキュリティ認証の取得

ティ性＜推奨要件＞
・セキュリティ要件の厳しい利用者にも対応可能とする場合には学習モデルをエッジ側にも構築可能とすることが好ましい

性能・・あらゆるデバイスに対応可能な設計とする

拡張性

・画像、位置情報、音声、テキスト等複数のデータ形式に対応する・説明書を読まずとも利用者が迷わないシンプルな UI（ユーザインターフェース）
・利用者側で簡易に追加学習を行える仕組みの整備＜推奨要件＞
・学習データの収集・整理にかかる稼働を減らすための支援ツールの提供
・高解像度の俯瞰映像や、多視点映像を伝送する機能の構築
・高解像度の俯瞰映像や多視点映像に対する基本的な操作（ズーム、移動、巻き戻し）を行う機能の構築
・撮影時の外部環境による検知性能への影響を抑えるための画像鮮明化処理を加える機
能の構築
・Web ブラウザやメール、チャットアプリ等、利用者が使い慣れているアプリケーショ
ンやデバイス上で動作する仕組み

移行性・SaaS 型でのサービス提供
・API の公開＜推奨要件＞
・少ない学習データで効率良く検知精度を高められるベースモデルの構築

運用・・遠隔地からの機器の死活監視や、トラブル発生時の問題箇所の切り分けを行う仕組み

保守性

の構築
・センシングデバイスの設置、設定までをベンダー側の専門家に委託可能な仕組みの提供5G システム全体としての評価
5G ソリューションの汎用化等の検討の結果、SaaS 型にて 5G ソリューション共用を行うための、提供者及び利用者が構築すべき最低限のシステム要件定義（汎用的・分野横断的に使えるかもしれないという部分を活用したい場合に利用者が整備しないといけない最低限のシステム要件）を整理するとともに、
ユースケースに応じたシステム構成の提言を行う。

(1) 評価項目
3.3 節ならびに 3.4 節項で得られた検証結果等より、SaaS 型を使うためのシステム全体の総括評価（SaaS を使うための最低限のシステム要件とユースケースに応じた要件）を行う。
（表 3.7.11 参照）248

表 3.7.1-1 5G システム全体の評価項目
No.

評価項目

評価項目の詳細

1

SaaS 型コア機能・アプ

機能：当該ユースケースにて、SaaS 型提供形態で求められるシ

リケーションでのシスステム構成の妥当性評価

テム評価

性能：当該ユースケースで求められる性能を発揮出来る SaaS 型
提供形態のシステム構成、スペック等の評価

2共用形態・接続方式の機能：本実証で定義した汎用化レベルごとに、当該ユースケー

システム評価スの汎用化に必要な機能の要件、システム構成、実現方法の妥
当性の評価
性能：本実証で定義した汎用化レベルごとに、3.4.1 で検証を行う要素の性能評価
接続方式：当該ユースケースにて求められるソリューション全体の遅延性評価及び接続方式による遅延性への影響評価
導入効果：本実証で定義した汎用化レベルごとに、共用形態実現における機能の導入効果、運用上の必要性等の評価

3
4

システム全体の横展開

当該ソリューションにおいて、SaaS 型提供形態でのソリューに関するシステム評価

ション横展開の難易度、事業者での導入効果等の評価

サービス提供上の分解

SaaS 型提供形態において、それぞれの構成要素の適切なモ点の評価

ジュール/機能提供者、導入作業者、運用保守実施者等の評価

ソリューション側のシステム評価
SaaS 型での提供時に必要となるシステム機能、性能に関する評価を行う。
今年度、SaaS 型ソリューションのロールモデルとした鉄道車両監視 AI システム（図 3.7.1-1）
において、3.4 節で汎用化レベルを定義しシステム評価を行った結果を基に、SaaS 型ソリューショ
ンのシステム構成としての妥当性評価、性能スペック評価を行った結果を表 3.7.1-1 に記載する。

249

図 3.7.1-1 SaaS 型での鉄道車両監視 AI システム
表 3.7.1-1 5G ソリューションの汎用レベル毎の作業結果
No.

評価項目

評価結果

1

ソリューション機能・当該ユースケースにて、複数事業者での利用に求められるシ
ステム機能として、従来機能に加えて、複数事業者での AI シ
ステムの共同利用に必要となるマルチテナント管理機能と AI
追加学習機能を実装し、複数事業者での実証実験において本
ユースケースが共同利用可能となったことを確認した。

2

ソリューション性能

・複数事業者（3 社）での同時利用時において今年度のシステ
ム構成では過年度と同程度の AI 検知性能を確認することができた。
・１事業者に必要となる性能/リソースを確認することができたことから今後のリソースの増設時の指標として活用可能である。

以下、SaaS 型での提供時に必要となるシステム機能、性能に関するする提言をまとめる。
今年度、SaaS 型ソリューションのロールモデルとした鉄道車両監視 AI システムの構成として、仕様の制限などなくクラウド基盤を用いて複数事業者が AI ソリューションを活用することが可能なベースの形態となった。
今後多種のケースに応対するために提供者としては、同種の環境を提供する際に利用者との要件を決める際に、本アーキテクチャの流用が可能か、例として、以下のような点をヒアリングして確認するべきである。
・利用事業者数
・利用拠点数・AI 解析対象物の選定
・検知対象物の検知性能目標
250

・システム利用時間帯
これらの要件を基に、今回のマルチテナント管理機能や、AI モデルの共用化についても構成・機能に変更なく流用できるか、または、クラウドアーキテクチャの拡張性やその他の機能、非機能要件の検討が再度必要であるかを決める必要がある。

共用形態・接続方式のシステム評価
SaaS 型での提供時における共用形態、接続方式に関する評価を行う。
3.4.1 項で評価した汎用化レベルごとでの汎用性の評価結果をもとに、鉄道車両監視 AI システ
ムでのユースケースの汎用化に必要な機能の要件、システム構成、実現方法の妥当性の評価、当該ユースケースにて求められるソリューション全体の遅延性評価及び接続方式による遅延性への影響評価を行った。また、導入効果の観点でも共用形態実現における機能の導入効果、運用上の必要性等の評価を行った。
それぞれの評価結果を表 3.7.2-1 に記載する。

図 3.7.2-1 5G ソリューションの汎用レベル毎の作業結果（再掲）表 3.7.2-1 汎用化に必要な機能要件の評価結果
汎用化

機能

接続方式

レベル

251

導入効果

レベル

・当該ユースケースにて、 ・ NW 接 続 方 式 に よ る ソ

・複数事業者での

１

SaaS 型提供形態で求められ リューション全体への影システム利用におるシステム機能の汎用性を 響としては、本事業で選定

いては導入コスト

確認でき、分野横断的に本 している 5G ソリューショの低減効果としシステム構成をベースとし ンにおいては、End to Endて、従来ソリューたアーキテクチャが活用可 で発生する遅延の中で NWション提供形態で能である。

の接続形態に関する影響ある SI 型、DL 型のは、限定的であった。

ような個社環境手・他ユースケースに展開す配を必要とする形

る際において、より低遅延態に比べて SaaS 型性を要求された場合には、 は利用者間での導今回検証を行った結果か

入コストの按分可らも NW 接続形態を閉域網能である点でコス

遅延低減策の一つとしてト負担面でのメ効果が発揮できる。

リットが大きい。

-

SaaS 型を採用する

レベル

当該ユースケースにて、

２

SaaS 型提供形態において必ことで、各社で個須となるマルチテナント管社環境を構築する

理機能において、各アプリ

手間・稼働の削減

ケーション処理のリソース

や、システム利用

分散設計や並列処理での同開始時のリードタ

時利用、データの独立性のイムの短縮以外に担保の手法について確認しも、運用段階におた。これらは、分野横断的にいてもシステム利

転用可能な汎用技術として用の頻度が増えて活用することが可能であきた場合に柔軟にる。

リソースの追加が可能となり、柔軟な利用形態が利用
者のメリットとな
る。

252

レベル

当該ユースケースにて、-特化型汎用モデル

３

SaaS 型提供形態で求められを利用者においてる AI の共用手法として特化

追加学習機能を用

型汎用モデルおよび、追加

いた AI モデルの継学習機能を用いる有効性を続運用が可能とな確認できた。これらの技術ることで、利用者を活用することで SaaS 型にの内製による AI 運

おいても高精度な AI 解析シ用の実現、および、ステムを共同利用可能であ

運用コストの削減る。

効果が期待される。

以下、SaaS 型での提供時における共用形態、接続方式に共用形態・接続方式に関するレベルごとの提言をまとめる。
（レベル１）
NW 接続形態および、クラウド環境を確定させる必要がある。現在どこかのクラウト環境を使っている場合に、5G システムを構築する際に他のクラウド環境への変更が可能か、また、NW 接続形態がそれに合わせて代替できるかについても決める必要がある。
とくに、MEC 環境を用意する場合において、利用されるユーザ拠点の環境数や位置関係により提供可能なクラウド環境は考慮して設定をしていくべきである。
これらは業種や業界に応じて条件が異なるため、利用者への提供環境の説明事項として盛り込むべきである。
（レベル２）
マルチテナント管理機能については、テナント・ユーザ数の要件設定、および、各社に割り当て
るテナント領域の確定のためにデータ保持期間などを要件として設定する必要がある。
本実証においては、検証を行っていないが、実運用の際には、機密データのクラウド保管可否やログイン認証方法について２要素認証を求めるか、情報の保持期間などセキュリティ面での要件を把握することも必要である。
（レベル３）
AＩ共用形態については、初期汎用モデルの構築に必要となる学習データの収集を行うこと、および、現地導入時の運用に関して AI 追加学習機能を利用するユーザにむけてのトレーニング要否やスポットでのトラブルシューティングの必要性を利用者の運用体制に応じて要件を設定することが重要である。

システム全体の分野横断的な横展開に関するシステム評価
SaaS 型にて提供する鉄道車両監視 AI システムを複数の鉄道事業者にて共用することについては、汎253

用化レベル 1〜3 それぞれにおいて共用可能であることが実証された。
ここでは、3.6 節「分野横断的な 5G ソリューションの横展開を見据えた共用形態の検証」において検証を行なった結果と、鉄道車両監視 AI システムを汎用化レベル毎に照らし合わせることによって、鉄道車両監視 AI システムの多業種・多分野への展開可能性を評価する。（表 3.7.3-1 参照）
汎用化レベル 1 の範囲においては、3.6.4 項で普及展開可能な 5G ソリューションの要件として設定した項目と照らし合わせると、以下の内容について今後追加検討が必要になると考えられる。
・可用性・安定性の観点から、SLA の設定、公開が必要となると考えられる。
・セキュリティ性の観点から、ISO 等のセキュリティ認証の取得が求められる。
・性能・拡張性の観点から、キズ検知以外の用途での活用に向け、あらゆるデバイスに対応可能な入出力モジュールが求められる。具体的には、駅構内の俯瞰映像の取得や、多視点での安全確認、音声による指示の入出力等。
・運用保守性の観点から、遠隔地からの機器の死活監視や、トラブル発生時の問題箇所の切り分け等も必要になると考えられる。
・さらには、他社のソリューションと連携しやすくするために API を公開することについても汎用化に向けて検討が必要になると考えられる。
表 3.7.3-1 汎用化レベル 1： NW/アーキテクチャ関連
汎用化・共用化結果

共用ヒアリング結果を踏まえた考察

鉄道車両監視 AI システムは汎用的に利用 今回調査を行なったいずれの業界でも汎用的なアーキテ
可能なアーキテクチャを用いた上で、 クチャを用いた SaaS 型 AI ソリューションは実用化されてSaaS 型システムとして実装可能であっ いた。鉄道車両監視 AI システムで構築したアーキテクチャ
た。

は多業界での共用が可能であると考えられる。
ただし、ヘルスケア領域の病院へのソリューション導入の際は、クラウドサービスの利用が制限される病院も存在す
ることが確認された。

Internet 経由、MEC による閉域経由双方 今回調査を行なったいずれの業界でも SaaS 型 AI ソリュー
ともに SaaS 型での NW 接続形態に活用可 ションへの NW 接続形態は Internet 経由が基本の接続方法能である。現地からクラウドへのデータ であった。ただし、製造業界、ヘルスケア業界においては、
送信・処理について低遅延性が要求され 利用者によってはセキュリティ性・遅延性の観点から AI にる場合においては、MEC 接続形態を選択す よる処理をエッジ側で行うシステム構成が求められる場
ることが望ましい。

合があることが確認されている。MEC よる閉域経由の接続形態を用いることでもセキュリティ性・遅延性を改善することが可能なため、エッジ側で AI の処理を行うシステム
構成以外の選択肢として活用が期待できる。

汎用化レベル 2 の範囲においては、普及展開可能な 5G ソリューションの要件として設定した項目と同様の内容が検討されていることが確認できた。（表 3.7.3-2 参照）254

表 3.7.3-2 汎用化レベル 2：共通コア機能関連
汎用化・共用化結果

共用ヒアリング結果を踏まえた考察

複数事業者（３事業者）において、「鉄道車両監視 各業界において導入実績の豊富な AI ベンダーへのAI システム」の共同利用を行うことが可能であ ヒアリング対象として選出したソリューションは、り、各事業者において AI 解析処理～Web アプリ いずれも SaaS 形態をとっており、マルチテナント
ケーションによる出力結果の表示までを並列で 管理に関して利用者側から懸念が示される等の言処理可能であることを確認した。

及はなかったため、SaaS 形態が認められる利用者
においてはマルチテナント管理についても受け入・システム性能上限についての課題

れられると考えられる。

AI 解析結果の検出総量が過剰となった場合に、現 システム性能上限の課題については、シェアの高い状のアーキテクチャにおいて Web アプリケーショ AI ベンダーからは、クラウドサーバ側に用意されンでの受信処理上限超過により検出結果が正し ているオートスケールの仕組みを活用し、システム
く表示されなくなる(※録画映像配信における) 負荷に合わせたリソースの調整を自動化すること動作影響が発生した。

によって解消しているとの回答が多く見られた。そ各システム性能上限到達時における今後の対策 の他には、処理を行う場所をエッジ側に移し、クラについては、検討を行っていく必要がある。シス ウドリソースにかかる負荷を分散させる手法を
テム性能上限についての今後の検討ポイントと とっているとの回答も見られた。
して、共用形態をとるうえではサービスの稼働状
況および各社への適切なリソースの配備が挙げられる。SaaS 提供の実装検討に向けてはこれらの実現方法を継続課題として検討する必要がある。
AI 検知性能についての改善

AI 検知性能が外的環境要因によって影響を受けて①過年度と同様に画像解析として精微なクラッ しまうという問題は、実証参加ベンダー、シェアのクについては外的環境要因での検知性能への影 高い AI ベンダー双方にて、多くのヒアリング回答
響が大きい。

者から確認された。対策方法としては、鉄道実証結②この事象を改善するには、果の考察と同様のアプローチに加え、画像鮮明化

・劣悪環境のデータも含んだ形での AI 追加学 （画像加工の前処理）を加えるという方法も行われ習による改善ていた。

・現地撮影環境の安定化の実現がポイントとなる。

汎用化レベル 3 の範囲においては、普及展開可能な 5G ソリューションの要件として設定した項目と同様の内容が検討されていることが確認できた。
表 3.7.3-3 レベル 3：AI 機能関連
汎用化・共用化結果

共用ヒアリング結果を踏まえた考察
255

利用者ごとに特化可能な汎用型学習 ヒアリングを実施した各業界において導入実績の豊富な AI ベ
モデルの導入は、AI の検知性能を向 ンダー7 社において、利用者ごとに特化した学習モデルを構築上させることに有効であった。

しているベンダーは 2 社であった。

その際に必要となる追加学習の稼働 利用者ごとの学習モデルを構築している 2 社については、両社については、アノテーション支援ツー とも追加学習をノーコードで行える仕組みが整えられていたルを活用することにより、利用者側で ため、利用者ごとに特化した学習モデルを構築する場合は、簡自ら行うことが可能であることが確 易に利用者側で追加学習を行える環境を整えることが重要で認できた。

あると考えられる。

追加学習機能に関する課題

鉄道車両監視 AI システムの課題として挙げられている点につ学習データの収集にかかる利用者側 いては、ヒアリング回答企業ではそれぞれ以下のような対応がの稼働負担や、ユーザインターフェー なされていた。
スの操作性、マニュアル類のコンテン 学習データ収集の稼働負担を減らすための取り組みとして、ツ拡充が課題として確認された。

データクレンジングツールの提供や、少ない学習データで識別精度を上げられる AI の学習方法等が挙げられていた。
ユーザインターフェースの操作性を高めることについては、利用者が使い慣れたデバイスやアプリケーション上でシステムが動作するように設計することや、説明書を読まずとも利用者が迷わないシンプルなユーザインターフェースを整えるといった工夫が多く挙げられた。
マニュアル類のコンテンツ提供については、ソリューションの複雑さにもよるが、e-learning のコンテンツを用意する、導入時にレクチャーを行う等の対応を行なっているベンダーも見られた。

サービス提供に必要となる作業範囲における分解点の評価
多業種・多分野に普及展開可能な 5G ソリューションのあり方として、SaaS 型で提供することが鉄道分野においても、その他の業界においても有効であるという結果が見えてきた。ここでは、SaaS 型で 5G
ソリューションを展開する際に、ソリューションベンダー側と利用者側との間でどこまでをそれぞれの実施責任範囲とすべきかを検討、評価する。
鉄道分野における実証を通じて得られた示唆としては、当初利用者側の実施範囲として想定していた、「現地環境の手配、運用」についても鉄道事業者側が対応しきれない作業が多いということがあった。
現地設営や、システムの運用、トラブルシューティング、作業負担に関して懸念の声が上がった。これらについては、提供者側でも一定の導入時のフォローアップを行う、または、アウトソースとして SaaS
256

での提供外の運用保守スコープを提供者側にて請け負う形も考えられた。

シ ステ ム構成要素

D L型提供⽅式

Sa a S型提供⽅式

Sa a S型提供⽅式（ 当初仮説）（ 検証後考察）

事業者提供（ 汎⽤技術）

事業者提供（ 汎⽤技術）通信キャ リ ア
構築・ 提供通信キャ リ ア
構築・ 提供

アプリケー
ション
事業者提供
システム
基盤

コンテナ
ミドル
ウェア
利⽤者構築
OS
通信キャ リ ア
構築・ 提供5GNW環境システム導⼊環境

事業者提供
カメラ機材類

利⽤者構築

利⽤者構築

ファシリティ

利⽤者構築図 3.7.4-1 SaaS 型提供形態による利用者負担軽減イメージ
令和 2、3 年度 L5G 実証参加団体、各業界において導入実績の豊富な AI ベンダーへのヒアリングを行なった際の結果についても鉄道実証における結果と同様であり、利用者側でシステム導入環境を構築することは難しいため、ベンダー側で設置・設定まで請け負っているというケースが多く見られた。その中でも特に課題となっていたのが、カメラ機材類の設置、設定であった。カメラの種類や、撮影位置によって、AI が判断に利用する画像にブレが生じてしまい、検知精度が落ちてしまうという問題が発生するため、AI が本来持つ検知精度を発揮するためには、ベンダー側がカメラの設置、設定を行うことが好ましいと考えられる。

257

Sa a S基盤
A 社モデル現地環境

AI モデル管理
B 社モデル

データ管理
A 社データ B 社データ X 社データ

X 社モデル

事業者A

A社拠点
カメラ
映像送信

B社拠点

5
G
N
W

学習・検出

学習・検出

映
像

検
出
結
果
保
管

検
出
結
果
出
⼒

X 社拠点

各社モデルによる検出結果

映像データ
カメラ
映像送信

結
果
描
画
処
理

出
⼒

各社検出結果データ
を映像データに描画

U I に描画済み
コンテンツを出⼒

キ
ャ
リ
ア
網
等

事業者B

事業者X

クラウドリソース
NW

双⽅実施範囲当範囲における役割分担イメージ

W e b D B アプリケーション

学習・検出

UI

カメラ
映像送信

A I 処理機能

CPU

GPU

HDD

ベン ダー実施範囲

利⽤者実施範囲
当範囲における役割分担イメージ（ ） 内は利⽤者の要望に応じて対応

ベ ・センシングデバイスの設置位置、設定等のコンサルティング
ン ・センシングデバイスの死活監視
ダ （ ・センシングデバイスの選定、調達）

ベ ・問い合わせ対応
ン ・アノテーション⽀援ツール提供
ダ ・マニュアル等学習コンテンツの提供

利 ・設置環境の保全
⽤ （ ・センシングデバイスの選定、調達）者 （ ・センシングデバイスの設置、設定）

利・出⼒結果の閲覧⽤・ツールを⽤いた追加学習者

図 3.7.4-2 ソリューションの共用を進めるうえでの利用者作業・責任範囲イメージ

258

4.

5G ソリューションの横展開「鉄道業界に向けた取り組み」
鉄道業界におけるソリューションの横展開の議論は、令和 2 年より 3 か年にわたり実施しており、すでに鉄道事業者を交えた議論の場を形成している点で、他業界に先駆けた取り組みを実施しているといえる。
昨年度実施した鉄道協議会では、鉄道事業者の抱える課題が相当程度共通のものであること、列車検査システムをはじめとする鉄道事業者が共同で利用できるソリューションを開発することへの需要を確認した。そこで、今年度は過年度より参加いただいている鉄道事業者に加え、新たな事業者にも参加を呼びかけ、より多くの事業者を交えて議論を実施した。
今年度の議論では、各鉄道事業者の課題やニーズの中から共通のニーズを把握することに加え、課題を解決するためのソリューションの検討や各社で共有するためのスキーム等を議論することで今後の進め方の方法性を見出した。SaaS 共用ソリューションの実証を足掛かりとした今年度の議論を踏まえ、令和 5 年度以降の継続した事業者間での議論の場の運営、「事業実施主体との共同開発スキーム」の立ち上げを念頭に置く。

図 4-1

今年度の事業における「5G ソリューションの横展開『鉄道業界に向けた取り組み』の位置づけ

259

鉄道協議会
令和 3 年度の協議会の継続として、本事業においても鉄道協議会を設置し、継続検討を行った。
今年度の協議会は、参画する鉄道事業者の数を 5 社から 10 社に増やし、昨年度に引き続きより幅広く鉄道事業者の鉄道 DX に係るニーズや各鉄道事業者の取組状況を把握した。
令和 2 年度より取組んでいる鉄道車両監視 AI システムについて、今年度の実証において SaaS型で共同利用が可能なシステムを構築することから、この共用形態を複数の鉄道事業者で具体的にどのように運用可能か、共同開発・運用のスキーム、費用負担の考え方等について議論した。
また、昨年度の協議会にて、鉄道事業者より鉄道 DX に資する様々なニーズ及び事業者間連携への期待が示されたことを踏まえ、鉄道車両監視 AI システム以外にも、鉄道事業の効率化や省人化に向けての共通のニーズを見出し、共用化が効果的な具体的なシステムの仕様イメージを共有するとともに、システムの開発段階から複数の鉄道事業者により共同開発を行う場合の共同開発ス
キームについても、議論した。

協議会の進め方鉄道 DX 協議会実施の全体像を下図に示す。
本協議会では、①過年度までの検討結果を踏まえた鉄道車両監視 AI システムの実証試験と②鉄道事業者の共通ニーズを踏まえた共通ソリューション化に関する検討の２つを柱に議論した。

260

協議会の開催目的の設定

協議会参加者の決定
鉄道車両監視AIシステムの実証計画の検討

第
1
回
協
議
会

参加者への事前ヒアリングの実施

鉄道事業者における鉄道DX等に係る取組・課題、新技術への期待等の発表※広島電鉄のみ第2回で実施

実証システムの説明

鉄道DX等に係る共通課題や新技術活用の可能性に係る意見交換
参加鉄道事業者の共通ニーズの抽出

第
2
回
協
議
会
第
3
回
協
議
会
第
4
回
協
議
会

深度化テーマに係る具体的なソリューションシステムのイメージ
実証計画の概要
共通ソリューション化に関する議論

実証試験結果の速報

共通ソリューション化のスキームに関する意見交換

実証試験結果の報告

共通ソリューション化に係る今後の取組みに関する意見交換

図 4.1.1-1 協議会の進め方

261

（1） 開催目的
令和 3 年度の協議会の継続として、本事業においても鉄道協議会を設置し、継続検討を行った。
開催目的は以下のとおりである。
①鉄道車両監視 AI システムの共用化実現に向けた具体的方策の議論②様々な鉄道事業者の、鉄道 DX に係るニーズの把握、共通ニーズの発掘③鉄道車両監視 AI システム以外の、鉄道事業者の共通ニーズの解決に資するソリューションシ
ステムのイメージ具体化（2） 参加者
昨年度協議会に参加した私鉄 5 社と国土交通省鉄道局専門官（オブザーバ）に加え、他の鉄道事業会社にも参加を働きかけ、合計私鉄 10 社に参画いただいた。
なお、本協議会の目的を踏まえて、参画事業者の地域に極力偏りがないように（関東、東海、
関西、中国、九州地方から事業者を選定）、また、事業規模の比較的小さい事業者を含めて幅広い事業者に参画いただくことを念頭に置いて、以下の鉄道事業者を選定した。
①委員○鉄道事業者
西日本鉄道株式会社（昨年度委員、今年度実証実施）
京阪電気鉄道株式会社（昨年度委員、今年度実証実施）
京浜急行電鉄株式会社（昨年度委員）
東急電鉄株式会社（昨年度委員）
南海電気鉄道株式会社（昨年度委員）
近畿日本鉄道株式会社
伊豆急行株式会社
泉北高速鉄道株式会社
静岡鉄道株式会社
広島電鉄株式会社②オブザーバー
総務省情報流通行政局地域通信振興課デジタル経済推進室
国土交通省鉄道局技術企画課 技術開発室（3） 開催概要
協議会の開催概要は下表のとおりである。

262

表 4.1.1-1 協議会開催概要
協議会

開催日時

開催形態

第 1 回協議会

2022 年 12 月 21 日(水)Web

第 2 回協議会

2023 年 1 月 26 日(木)Web

第 3 回協議会

2023 年 2 月 16 日(木)対面＋Web

第 4 回協議会

2023 年 3 月 15 日(水)Web

参加者への事前ヒアリングの実施
本年度の鉄道協議会では、本年度実証を実施した 5G を使った鉄道車両監視 AI システムの共用化の発展形、その他の共通ニーズの解決に資するソリューションシステムの共用化に係るイメージの具体化を図るため、各鉄道事業者の抱えている課題やニーズを把握し、共通のニーズを抽出することが必要であった。そのため、計４回の協議会を円滑に進める観点から、第１回協議会開
催前に各鉄道事業者に事前ヒアリングを行った。

（1） DX に係る課題・共通ニーズを把握するための事前ヒアリング
各鉄道事業者の DX に係る取組みの現況、課題・ニーズを把握するために実施した事前ヒアリン
グの概要を以下に示す。

1） ヒアリング方法
対面でのヒアリングを基本とした。（状況に応じて WEB でもヒアリングを実施）

2） 対象事業者
鉄道協議会への参加を承諾済み及び参加検討中であった以下の鉄道事業者 10 社を対象に、複数回ヒアリングを実施した。
表 4.1.2-1 ヒアリング対象事業者及びヒアリング実施日
ヒアリング対象事業者

ヒアリング実施日

伊豆急行株式会社

11/7、12/5

近畿日本鉄道株式会社

11/7、12/20

京阪電気鉄道株式会社

11/15、12/12

京浜急行電鉄株式会社

11/8

静岡鉄道株式会社

11/9、12/15

泉北高速鉄道株式会社

11/10、12/8

東急電鉄株式会社

10/24、12/16

南海電気鉄道株式会社

9/6、11/10、12/8

西日本鉄道株式会社

11/30、12/15263

広島電鉄株式会社

10/31

3） ヒアリング内容
各鉄道事業者への事前ヒアリングでは、主に鉄道 DX に係る取組みの現状（研究開発、具体的取組み事例など）、鉄道事業の抱える課題、効率化や省人化に係るニーズなどについて、会社全体としてだけではなく、土木、軌道、運転、車両、駅務、電気、その他の分野ごとに関しても可能な限り把握することに努めた。
■鉄道事業者に対するヒアリング事項
・鉄道 DX 等の取組み状況（研究開発・具体的取組み事例など）
・鉄道事業の抱える課題・効率化や省人化に係るニーズ4） ヒアリング結果
各鉄道事業者に対する事前ヒアリングにより把握した課題及び DX に係る現状の取組みを以下に示す。
なお、これらの現状の取組みについては、分野に関わらず、基本的には将来の働き手不足を見据えた施設・設備の維持管理の省力化・省人化、労働環境の改善などの課題の解決に資する取組みであることを確認した。
表 4.1.2-2 事前ヒアリング結果のまとめ
現状の課題

・鉄道収入の減少
・人手不足

現状の

土木分野

取組

・橋梁支承部の点検のドローン活用
・高所等の立ち入りにくい箇所の点検のドローン活用

軌道分野

・車載カメラ映像による軌道巡視の前方監視（山間部の樹木等、バラスト劣化、AI での落下物検知）
・ドローンを活用した軌道の巡視（バラスト劣化・振動など）

運転分野

・自動運転に資する前方監視

車両分野

・列車検査の画像、映像による異常の AI 判定
・カメラによる車内監視

駅務分野

・白杖者・車いす利用者の察知
・軌道転落者検知

電気分野

・ドローン・車載カメラを活用した電車線点検業務
・鋼索線の無人運転化(車掌の無人化)
264

・踏切内の立ち入りの確認
その他

・新入社員の確保

協議会の開催
第１回協議会では、実証システムである鉄道車両監視 AI システムの概要や SaaS 型による 5G ソ
リューションの共用化の概要について説明するとともに、鉄道事業者各社の鉄道 DX に係るニーズを幅広く集め、共通ニーズ等について整理した。
第 2 回協議会以降は、鉄道車両監視 AI システムの共用化、共同開発・運用に関する具体化の議論を進める一方で、鉄道業界への横展開に向け、鉄道事業者の共通ニーズを踏まえた他の開発テー
マについても、ソリューションシステムのイメージの具体化や共同開発のあり方について議論した。
（表 4.1.3-1～表 4.1.3-4 参照）（1） 第 1 回鉄道協議会での主な内容
1） 目的、議題および資料
第１回協議会の主な目的、議題及び資料は以下のとおりである。
■主な目的①5G ソリューションの共用形態に係る本年度の実施概要の共有②鉄道事業者における鉄道 DX 等に係る取組・課題、新技術等への期待等の共有・意見交換③鉄道 DX 等に係る共通課題や新技術活用の可能性等を踏まえた共通ニーズの抽出・選定

表 4.1.3-1 第 1 回鉄道協議会（2022 年 12 月 21 日開催）

2652） 鉄道事業者における DX 等に係る取組・課題、新技術等への期待等の共有・意見交換
各鉄道事業者から鉄道 DX 等に係る取組・課題、新技術等への期待などについて紹介があり、その内容を踏まえて意見交換を行った。主な意見交換等の内容を以下に示す。
各鉄道事業者の取組みや抱える課題のうち、特に画像・AI を用いた列車検査、車載カメラを用いた軌道巡視、GPS を用いた列車見張員の支援に対して複数の鉄道事業者から興味が示された。
➣カメラ（画像・映像）
・AI を用いた列車検査について➤車両の検査業務の省力化・高度化を図るために、CBM（状態基準保全）への移行は必要不可欠。
➤遠隔監視のために多数のセンサー類が必要になることや、摩耗部品については遠隔状態監視が困難という課題がある。そのため、遠隔状態監視だけではなくて、AI による車両
監視システムの導入が、省力化・安全性向上のために必要だろう。
➤可能な限りデータを活用した検査に置き換えることによって、人材不足による作業効率の低下を補えるだろう。また、データの蓄積等によって、技術伝承や若い世代の作業補
助・教育にも活用できるのではないか。
➣車載カメラを用いた軌道巡視（線路巡視）について➤車載カメラを用いた線路設備や電気設備の点検は、省人化・省力化の観点から興味がある／検討中である。
（複数の鉄道事業者が検討中）➤ローカル 5G は通信速度の速さやデータ伝送の安定性が魅力である一方、導入コストの高さが課題。そのため、5G のアンテナ類を鉄道施設に取り付ける鉄道工事についても、システムの構成を可能な限りシンプルにして、かつ安価に取り付けられるような工事方法に見直すなど、環境構築に関わる全体的なコストの低廉化を検討する必要がある。
➤車載カメラを用いたソリューションは、すぐに検査周期を延長したり、運用を変えたりはできない。AI が導いた結果が合っているかどうか確認しながら、合っていない場合は教え込むという作業を継続的に実施して、AI を育てていくという意気込みで実運用の中で精度を高める必要があるだろう。
➣GPS を用いた列車見張員支援システムについて➤列車見張員の安全確保の支援の観点から興味がある。（複数の鉄道事業者が興味あり）

3） まとめ
第１回協議会の主な目的に対する結果は以下のとおりである。

a. 5G ソリューションの共用形態に係る本年度の実施概要の共有
今年度事業では、各社が開発・保有している 5G を活用したソリューション事例を多くの利用者へ有益に活用できる横展開の方法として、ソリューションの汎用化、共用方法について具体的な検討を行うことを主目的として、過年度から実施してきた鉄道車両監視 AI システムに対して SaaS
共用実証実験を行い、5G ソリューションの情報提供・情報共有に係る検証及び 5G ソリューショ
266

ンの共用形態に係る検証を実施することを共有した。

b. 鉄道事業者における鉄道 DX 等に係る取組・課題、新技術等への期待等の共有・意見交換
各鉄道事業者が計画もしくは実施している鉄道 DX 等に係る取組み、抱える課題や新技術等への期待などについて共有した。
その結果、様々な取組みや課題のうち、特に以下の事項については複数の鉄道事業者が取り組んでおり、共通のニーズであることを確認できた。
■土木分野➤構造物（橋りょう、トンネル）の点検におけるドローンの活用■軌道分野➤軌道巡視（バラスト劣化・振動など）に対するドローンの活用➤車載カメラ映像による軌道巡視の前方監視➤保守作業時の列車接近情報の把握■車両分野➤車両検査のデジタル化➤列車検査の画像、映像による AI の異常判定➤パンタグラフのすり板摩耗の検知➤異音検知➤車両モニタリングデータの取得（常時監視）➤カメラによる車内監視■駅務分野➤白杖者・車いす利用者の捕捉➤軌道転落者の検知■電気分野➤電車線点検業務に対するドローン・車載カメラの活用➤鋼索線の無人運転化（車掌の無人化）➤踏切内の立ち入り監視■その他➤新入社員の確保による人材確保
各鉄道事業者が抱えるニーズのまとめを次頁に示す。

267

表 4.1.3-2 鉄道事業者における現状の取組み内容及びニーズのまとめ
凡例

分野ごとの取組状況やニーズのまとめ表

実証試験等、取組中・検討中
関心あり

取組中・検討中または関心のある鉄道事業者の数

各鉄道事業者のニーズ
1
橋梁支承部の点検のドローン活用
トンネル部の点検のドローン活用
高所等の立ち入りにくい箇所の点検のドローン活用
災害時の被災箇所特定のドローン活用

土木（LPWAを用いた）河川水位の監視
橋脚の振動数による劣化判定
地図上に土砂災害危険箇所をマッピング
インフラドクターを活用したトンネル点検
軌道点検のデジタル化
総合検測車への点検集約
飛来物検知
ドローンを活用した軌道の巡視（バラスト劣化・振動など）

軌道

車載カメラ映像による軌道巡視の前方監視（山間部の樹木等、バラスト劣化、AIでの落下物検知）
建築限界支障の検知

保守作業時の列車接近情報

保守作業時の列車接近情報
線路設備管理システムの構築（俯瞰画像で保線と電気設備のプラットホーム化）

運転

自動運転に資する前方監視
車両検査のデジタル化→備品管理のデジタル化
列車検査の画像、映像による異常のAI判定
パンタグラフのすり板摩耗の検知

車両

屋根上落下物の検知
異音検知（台車、加速度計）
前方監視による部品欠落車の特定車両モニタリングデータの取得(常時監視)
カメラによる車内監視→切符レス（ICやQRの活用）
駅員代替として遠隔対応、中央集約
駅の集金業務の削減
拾得物の様式の統一化（電子化）駅務

ホーム監視要員の代替
白杖者・車いす利用者の察知
軌道転落者検知
駅清掃ロボットの導入
ドア開閉の監視
変圧器故障検知
変電所故障検知

電路、変電、電気機器
LPWAを用いた電車線の張力監視

電気

ドローン・車載カメラを活用した電車線点検業務
鋼索線の無人運転化(車掌の無人化)

信号、通信、踏切

踏切内の立ち入りの確認
列車無線の5G回線適応

その他

人材
WEBページ

新入社員の確保
HP上のAIチャットボットの導入

268

2

3

4

5

6

7

8

9

c. 鉄道 DX 等に係る共通課題や新技術活用の可能性等を踏まえた共通ニーズの抽出・選定
前述したとおり、参画した鉄道事業者は多分野において様々なニーズを抱えており、複数の鉄道事業者に共通したニーズも複数あることを把握できた。開催回数が限られた中で、ソリューションシステムに関する具体的なイメージをもとに、鉄道分野におけるソリューションの共有化を図るためのスキーム等の議論を充実させるため（ソリューションシステムの横展開を図るための検討の具体化を図るため）、第２回以降でモデルケースとして取り上げるテーマ（深度化テーマ）を各社のニーズが特に高いテーマに絞ることとした。
具体的には、複数の鉄道事業者に共通したニーズのうち、ソリューションシステムの開発や実証試験が既に進んでおり、その目的や技術的な内容が明確である「車載カメラを用いた軌道巡視システム」及び「GPS を用いた列車見張員支援システム」、本年度に実証試験を実施した列車検査
システムの発展形（本年度は台車周りを対象としていたが、対象範囲を屋根上等に拡大したシステム）の３つのテーマを選定した。
■第１回協議会で抽出・選定した共通ニーズ（深度化テーマ）
・車載カメラを用いた軌道巡視システム
・列車検査システムの発展形（台車周り以外へのシステムの拡大）
・GPS を用いた列車見張員支援システム

269

（2） 第 2 回鉄道協議会での主な内容
1） 目的、議題および資料
第２回協議会の主な目的、議題及び資料は以下のとおりである。
■主な目的①5G ソリューションの共用形態に係る本年度の実証計画の共有②深度化テーマ（共通ニーズ）に係る具体的なソリューションシステムのイメージの共有・意
見交換③ソリューションシステムの共通化に関する意見交換
表 4.1.3-3 第 2 回鉄道協議会（2023 年 1 月 26 日開催）

2） 鉄道事業者における DX などに係る共通課題や新技術活用の可能性に係る意見交換
第２回から参画した鉄道事業者から鉄道 DX 等に係る取組・課題、新技術等への期待などについて紹介があり、その内容を踏まえて意見交換を行った。主な意見交換等の内容を以下に示す。
➣鉄道区間と軌道区間の両方を保有している事業者は、列車の検査基準は、鉄道と軌道で別々に申請しているが、鉄道の検査基準の方が厳しいため、鉄道の検査基準に合わせている。ただし、自動運転の場合は、併用軌道は安全管理上の基準が鉄道と異なるため、鉄道技術の運用が難しく、センサー類・機器類を変える必要がある。

270

3） 深度化テーマ（共通ニーズ）に係る具体的なソリューションシステムのイメージの共有・
意見交換
第１回協議会において深度化テーマ（共通ニーズ）として取り上げることとなった３つのテーマに対して、今後、ソリューションの共有化を図るためのスキーム等を議論するため（ソリュー
ションシステムの横展開を図るための検討の具体化を図るため）、各ソリューションシステムの技
術的な内容を中心に情報共有・意見交換を行った。
各ソリューションシステムの概要及び意見交換の内容を以下に示す。

a. 車載モニタリングシステム(東急電鉄)に係る意見交換について
車載モニタリングシステムは、車載モニタリングカメラと AI を活用して異常を自動検知し、線路内目視検査・巡視の負担を軽減することで、鉄道設備メンテナンス業務を高度化するものである。

資料：東急電鉄より提供

図 4.3.1-1

車載モニタリングシステムシステムについて
271

➣セマンティックセグメンテーションという技術の汎用性に関して➤架線への樹木接近に関して、セマンティックセグメンテーション(ディープラーニング
式)を使った理由は、対象物が樹木であるため、異常な状態、画像で見える状態が常に同じではないことから、教師データを事前に覚え込ます方式は適合しないだろうと判断。
➤実証実験の実施の目的の１つは、架線に対する樹木の距離を見て、架線と樹木の接触の可能性を判断する際に、ディープラーニング式によって画像から架線への樹木の接近状態を検知できるか確認すること。
➤架線に対する空や周辺建物との識別は。現時点で検知の精度が低い。精度を上げていく方法は検討の余地あり。
➣東横線での今後の取組みについて➤来年度の予定は、検知対象項目を増やすことと、精度を向上することに対して実用化までどの程度近づくのかを確認するために、東横線での実証実験を 1 年間通して実施
して、データの蓄積・解析やアノテーション機能を社員に使用してもらうことを検討。また、武蔵小杉駅と渋谷駅において自前でローカル 5G の環境を構築して、渋谷駅～横浜駅間で営業列車を使った試験を行うことを検討。
➤再来年度の予定は、他の事業者と実際に連携することの具体化を検討。車両に搭載する機器は、今回の実証試験で使っている機器のみのため、他の事業者の路線に実際に持ち込み、1 回撮影してもらうことを検討。
➤東急電鉄としては、ローカル 5G の使用を前提にしているが、必ずしも、ローカル 5Gが必須ではなく、各事業者の判断に委ねる。

272

b. 列車検査システムの発展形(事務局)に係る意見交換について
列車検査システムの発展形は、列車検査の効率化・省人化や作業環境の改善・安全性向上を目的として、過年度まで実証試験の対象としていた台車周りだけでなく、列車検査項目のうち、現状の車外目視検査に対象を拡大して、カメラ（画像・映像）と AI を用いて遠隔点検、異常検知を行うものである。

図 4.1.3-2

列車検査システムの発展形について

273

➣省力化・省人化に関して➤将来の働き手の減少に対応するために、10 日周期の列車検査を人による検査、AI 等での状態監視による検査を交互に実施することで、実作業量を減らすことを検討。
➤屋根上の検査を対象に、システムを導入するにあたっては、絶対に必要な作業とそうでない作業(屋根上に上がるので、ついでに行っている作業)を今後明確に線引きすることが必要。
➤台車亀裂の検知のみのシステムだと費用対効果の面で導入が難しいと考えていたが、全方位にカメラを設置して、車両を状態監視する最終形のイメージであれば、検査項
目を増やすことができ、非常に有効になるだろう。
➣各事業者間の連携に関する意見に関して➤共通ソリューションの観点からは、事業者間で話し合い、最終的なゴールを決めないと、方向性を定められないだろう。
➤AI による画像解析のためには、教師データを大量に取得する必要があり、複数の事業者が共同で時間をかけて開発していくものである、と考えている。
➣今後への期待について➤これまで鉄道業界では、国鉄規格に則って、製品開発を行っていたため、大量製造でコストの面でメリットがあり、初期トラブルの早期解決を図ることができていた。製品に関しても今後そのような動きになっていけば良い。

274

c. 列車見張員支援システム(静岡鉄道)に係る意見交換について
列車見張員支援システムは、列車見張員の支援をすることを目的に、列車と列車見張員に携帯させたスマートフォンにより双方の位置を測位し、鳴動により退避を補助するものである。

資料：静岡鉄道より提供

図 4.3.1-3

GPS を用いた列車見張り員支援システムについて➣技術的な内容に関して➤列車見張員支援システムでは、列車接近の距離を見ている。一方、列車速度の計測は検討していない。
➤同システムでは、作業場所によって列車接近の通知が必要なタイミングが変わること
から、距離(50m～300m)を任意に設定することが可能になっている。例えば、駅の真横で作業している場合、早めに通知が来てしまうと作業時間が減ってしまうため、作業場所に応じて列車通知の距離を調整できるように設定している。
➤同システムでは、車両側・作業員側でスマートフォンが 1 台ずつ＋スマートウォッチ 1台の構成である。2 つの機器を利用する理由は、App Store のスマートウォッチ用のアプリ開発に移行すると手間がかかるからである。スマートフォンとスマートウォッチを連携させることは、通信の時間差もそれほど発生せずに通知がくることが確認されたため、2 つの機器の利用の有効性に関して示せた。
➤列車に載せるスマートフォンは列車の電源から充電し、スマートフォンの背面から充電する形式で検討中である。
➤App Store からインストール可能とするのは、弊社(静岡鉄道)の社員のみの予定として、全体公開する予定はない。ただし、お問い合わせいただいた事業者に対しては、限定的に提供することを検討している。
➤スマートフォンの通信はキャリアの LTE 等の回線を使用している。スマホ熱の問題は現時点でない。
➤キャリア回線の通信障害が発生した場合も、見張員が目で確認しているため、安全は担保している。

275

➣複々線区間では、列車方向を識別することは可能だが、2 本ある同方向の線路のどちらかを認識することは精度の面から保証できない可能性が高い。

4） ソリューションシステムの共通化に関する意見交換
共通ニーズに対する課題解決に資するソリューションシステムの共通化を図るために、各鉄道事業者が今後取り組むことが必要と考える事項、解決しなければならない課題などを明確にすることを目的として、事務局が目指しているソリューションの共通化の方法の１つとして考えられる共同開発スキームのコンセプト及び導入イメージを提示した上で、鉄道事業者との意見交換を行った。
共同開発スキームのコンセプト及び導入イメージを以下に示す。

図 4.1.3-4 共同開発スキーム

276

コンセプト

図 4.1.3-5 共同開発スキーム

導入イメージ➣ソリューションの共用化もしくは導入にあたっての費用対効果の効果に関する各社の意見➤投資に対してどの程度コスト削減を図れるかに尽きる。そのため、コスト縮減をどの程度図れるかを見極めていくことが必要である。
➤列車検査システムは、検査を人から機械に代替するので、人件費相当が費用対効果の効果になる一方、列車見張員支援システムは、見張員が減るわけではなく、安全に関わることであるため、納得できる費用であれば導入するという判断を検討する。
➤働き手不足という課題を解決できれば、必ずしも人件費見合いである必要はないという考えである。加えて、技術継承ができる、職場環境が改善する、安全性が向上するなどの定性的な面も考慮して費用対効果を把握する予定である。
➤列車見張員支援システムは、既存システムに上乗せする支援システムとして考えた場
合、1 つのシステムだけでは費用対効果が見込めない可能性があるが、3 つ程度のシステムを載せることで企業価値を高めることを推進したい。

2775） まとめ
第２回協議会の主な目的に対する結果は以下のとおりである。

a. 5G ソリューションの共用形態に係る本年度の実証計画の共有
本年度の鉄道車両監視 AI システムの実証計画の概要を共有した。
本年度の実証試験は、対象とする検査項目（ブレーキパッドのすり減り、台車の亀裂、収容函のハンドル角度、車軸温度）や実施内容（検査車庫において、4K カメラ・サーマルカメラで台車を撮影し、AI システムを用いて対象物を検知し、その検知精度や速度などを評価・検証する）は昨年度の実証試験の継続であるものの、新たな取組みとして SaaS 構成でのシステム構築、特化型
汎用モデルの構築、アノテーション支援ツールの追加を行うことを共有した。

b. 深度化テーマ（共通ニーズ）に係る具体的なソリューションシステムのイメージの共有・
意見交換
第１回協議会で深度化テーマ（共通ニーズ）として選定した車載モニタリングシステム、列車検査システムの発展形、列車見張員支援システムについて、今後のソリューションの共有化を図るためのスキーム等を議論するため、技術的な内容を中心に情報共有・意見交換を実施した。
車載モニタリングシステムについては、セマンティックセグメンテーション（ディープラーニング式）による架線への樹木接近検知のように、必ずしも教師データを事前に覚え込ませた上で
AI 検知する方式が最適ではない検知対象物があることを共有した。
列車検査システムの発展形については、検査対象物を拡大し車両を状態監視することに対しては、費用対効果の面からも有効なシステムになるとの見解があった。
列車見張員支援システムについては、スマートフォン３台のみの簡易なシステム構成であり、技術面・費用面での導入が比較的容易なシステムである一方で、複々線区間での各列車の識別精度が低いと想定されることなど、他の鉄道事業者への横展開を図るためには課題があることを確認した。

c. ソリューションシステムの共通化に関する意見交換
ソリューションシステムの共通化もしくは導入に関しては、省人化を図れる人件費相当が効果になるといった費用対効果が判断基準になるという見解が複数の鉄道事業者から示された。一方、将来の働き手不足の課題を解決できる場合は、必ずしも削減可能な人件費が効果としての判断基
準ではなく、技術継承が可能になること、職場環境が改善すること、点検作業の安全性が向上することなどの“定性的な面”も含めた費用対効果を考慮するという意見もあった。

278

（3） 第 3 回鉄道協議会での主な内容
1） 目的、議題および資料
第３回協議会の主な目的、議題及び資料は以下のとおりである。
■主な目的①5G ソリューションの共用形態に係る実証試験結果の速報の共有②深度化テーマ（共通ニーズ）に係る共通ソリューション化のスキームに関する意見交換
表 4.1.3-3 第 3 回鉄道協議会（2023 年 2 月 16 日開催）
議題

１．第 2 回協議会の議事内容の確認
２．実証試験結果の速報
３．共通ソリューション化のスキームに関する意見交換
・車載モニタリングシステムについて・共同開発スキームについて（列車検査システムの発展形）
・列車見張員支援システムについて

資料

資料 3‐1：5G 等を活用したソリューションの普及展開に関する協議会名簿
資料 3‐2：第 2 回協議会 議事録（案）資料 3‐3：実証試験結果の速報
資料 3‐4：ソリューションシステムの共用化に向けて
資料 3‐5：車載モニタリングシステムについて
資料 3‐6：ソリューションシステムの共用化に向けて～共同開発スキーム～
資料 3‐7：鉄道技術開発費補助金について279

2） 5G ソリューションの共用形態に係る実証試験結果の速報の共有
鉄道車両監視 AI システムの実証試験結果の速報を行い、AI での検出結果の一部を共有するとともに、本試験の目的の１つである SaaS 型利用については、３拠点からの同時利用を想定して、リアルタイム映像伝送・AI 解析処理が並列で行われるシステム構成で利用可能と確認したことを報告した。
また、本年度新たに追加したアノテーション支援ツール、及びソリューションの共有化にあたり AI モデルについて、以下の意見があった。
➣アノテーション支援ツールについて➤アノテーション支援ツールは、マニュアルに沿って容易に扱えた。
➤実際の運用に導入した際には、台車の種類が多いことと、雨や汚れなどが実証時に比べて劣悪な環境であり、その環境下において亀裂等が検知できるかが課題。台車の種類の多さは、AI に覚え込ませるための教師データが多く必要になることから、この点について改善できれば、より使いやすくなるだろう。
➤アノテーション支援ツールの半自動化は、今の技術では実現は難しいが、現場の負担を軽減するためには必要な要素であると考えている。
➣AI モデルについて➤AI モデルを汎用化し、シェアリングすることでコストダウンが図れるのではないか、と考えている。
➤昨年度は、京急、西鉄の混濁モデルで実証を実施。今年度は、混濁モデルと特化型汎用(西鉄)モデルの精度の比較を検討。
➤AI モデルとクラウドシステムの両面からコスト縮減に関しての検証を検討。

3） 深度化テーマ（共通ニーズ）に係る共通ソリューション化のスキームに関する意見交換
a. 車載モニタリングシステム(東急電鉄)に係る意見交換について
車載モニタリングシステムについて、業務効率化の観点から鉄道事業者共通の課題を解決する
ソリューションを開発・シェアする仕組みや他事業者への展開といった将来構想コンセプトや事業モデル案が共有され、鉄道事業者から以下の意見があった。
➣東急の現時点の事業モデル案(SaaS 事業)に関しての各事業者の導入形式について➤参画事業者が増えると、導入コストが安価になると想定されることや、データが増え学習させることで AI が賢くなることにニーズがあること、また、アップデートが行われることを踏まえると、買い切り型よりサブスクリプション型が優位ではないか。
➣サブスクリプション型の利用料に関して➤事業者によって求める内容が異なることから、それぞれに合った形で提供できれば、280

会社規模を問わず導入可能だろう。
➤路線延長や設備数、検知対象物やカメラの台数など利用環境(都市型路線・山岳路線)に応じて価格設定するやり方を検討することが考えられる。また、AI やクラウドサー
バ等の利用状況に応じて重み付けすることで、導入のハードルは下がるだろう。
➤機能ごとに価格が設定されていると分かりやすい。
➣東急の現時点の事業モデル案(SaaS 事業)の今後の展開について➤東急電鉄との乗り入れ事業者を対象に Phase1 として広げていく計画である。
➤東急電鉄と乗り入れしていない事業者が参画する場合、Phase2 の 2027 年度からの参画が目安である。

b. 共同開発スキーム:列車検査システムの発展形(事務局)に係る意見交換について
列車検査システムの発展形について、今後のソリューションシステムの開発にあたっての課題や方向性に関して、鉄道事業者等から以下の意見があった。
➣システム全体に係る事項について➤データの取得方法に関しては、ヘルメットにカメラを付けるのも一案だが、スマートグラスなどで足回りのデータを取るなど他にも工夫しようがあるのではないか。
➤今回初めて実証実験した中で、台車の亀裂は列車検査においては、付加価値の機能だと考えている。一方で、制輪子の摩耗は、検査項目であり代替は可能であるが、限度値以下であると交換作業が生じることは変わりない。
➣パンタグラフや高所での検査について➤パンタグラフのすり板は手間がかかっている検査である。パンタグラフのすり板検査は製品化されているが、ニーズがあるため、開発していく余地がある。
➤パンタグラフのすり板の素材は合金素材やカーボン素材など複数種類があることから、それらを判別して異常を検知するシステムが必要である。
➤CBM 関係で台車にセンサーを付けて異常を感知させ、効率的なメンテナンスを図ろうとしているため、車両のパンタグラフすり板摩耗の検知は、優先順位はまだ低い。カメラや AI 等で確認したとしても、作業がなくなるわけではないため、どの程度省力化、効率化が図られるかが大切である。
➤ある程度 AI が検査できるようになり、10 日に 1 回のカメラを用いた屋根上の検査を AIと人で交互に実施することができるようになるのが理想である。
➤社内の当該部門において屋根上の高所作業が点検の中でどの程度の比重を占めているのかの確認を今後実施。
➤現在パンタグラフのモニタリングとして駅にカメラを設置しているものの、人員削減には繋がっていない。AI 検知の実現で人員削減や検査の精度向上に繋がるだろう。
➣列車点検の現状について
281

➤列車点検に関しては、点検票のデジタル化など主に事務作業の効率化を進めている。
➤作業環境はピット線で実施しており、空調等はなく夏場は特に過酷。
➣今後の進め方や意義について➤新技術の開発は本社のメンバーで対応することが多いが、実運用を見据えると、開発段階から現場の社員を巻き込むことで早く運用に落とし込むことができるだろう。
➤将来的に、現在かけているマンパワーをどこまで維持できるかという課題がある。現
在の主力である 50 代付近の年齢層が抜けたときに、全般検査等の大きい検査は人が実施せざるを得ないものの、列車検査等の短い周期の検査をどこまで AI で対応できるかと思っている。

c. 列車見張員支援システム(静岡電鉄)に係る意見交換について
列車見張員支援システムについて、現状の報告があった。主な内容は以下のとおりである。
➣システム開発の現状について➤2 月にテストを行い、仕様を変更。これまでは、列車が設定の距離まで近づいた際に、一度のみ通知を送るシステムとしていたが、複数回通知を送るように仕様を変更。今回のテストでは、作業員と列車の距離が 100m～80m の間に一定間隔で複数回通知される仕様とした。
➣システムの横展開について➤他鉄道事業者への展開は、現在ベンダーと契約書をまとめている。横展開ができるように進める予定である。

d. 共通ソリューション化に関する議論について
ソリューションシステムの共用化または円滑な導入にあたっての課題やコスト以外の観点からの留意事項等に関して、以下の意見があった。
➤システムを共有化した際に、システムによる故障やエラーが生じた場合にどこが悪いか
誰が悪いかといった責任問題が生じる可能性があり、システムの運用を具体化する際には、リスク面のフォローが必要であるだろう。
➤団塊世代の大量退職を見据えた作業効率化が課題である。
➤将来的な人員確保を見据えて、技術職以外の人でも対応できるような精度・確度で判定できれば良いだろう。
➤導入が進まない理由は、安全性向上等の出口戦略が明確になっていないからだろう。将来の絵姿が見えていない中で技術だけ進歩している状態であり、ロードマップが見えてくると各事業者の合意が図れて、進めていけるのではないか。
➤導入にあたっては、コストや従業員の満足度などが重要である。
➤悪いところを見つけるだけではなく、周期予測等も複数のデータを分析できれば対応できるような CBM の観点から更に良くなるのではないか。
282

➤高所作業の削減は、安全性の確保および職場改善となることから、離職率低下に繋がるのではないか、と期待している。
➤将来の人手不足を考えると、単独でも進める必要があるくらいだと認識。
➤共同で開発するメリットは、1 社で行うことより早く実現できることが期待されることと、他社の知見・ノウハウを得ながら進められることと、複数事業者のデータを基に、より安全性が担保できれば社内での意思決定も図りやすくなることの 3 点が考えられる。
➤共通ソリューションは、コスト、品質、納期が良ければ使っていくことになるだろう。
➤検査の精度が一定数を超えており、外部的に認められていると意思決定が図りやすい。サンプルでお試しができると、意思決定のハードルが下がるのではないか。

4） まとめ
第３回協議会の主な目的に対する結果は以下のとおりである。

a. 5G ソリューションの共用形態に係る実証試験結果の速報の共有
本年度の鉄道車両監視 AI システムの実証試験結果の速報を共有した。
この鉄道車両監視 AI システムにおいて本年度新たに追加したアノテーション支援ツールに関しては、鉄道事業者から、マニュアルに沿って容易に扱えたといった好意的な意見があった一方で、実証環境と比較して実際の環境が劣る（雨天により車体が汚れている等）ことによる影響や実運用では教師データが膨大になることが想定されるという懸念が示された。

b. 深度化テーマ（共通ニーズ）に係る共通ソリューション化のスキームに関する意見交換
深度化テーマのうち、車載モニタリングシステムに関しては、他の鉄道事業者への横展開を図る事業モデル案が示された中、導入型式としては、コストや今後のシステム更新の面から買い切
り型ではなく、サブスクリプション型が優位であるとの見解が示された。また、サブスクリプショ
ン型の利用料については、鉄道事業者によって路線環境が異なることから、各事業者の利用環境に応じた価格設定をすることで、導入のハードルが下がるとの意見があった。
列車検査システムの発展形については、台車周りだけではなく、屋根上など対象範囲を拡大する発展形への期待は示された一方で、部品交換などの画像や AI による代替が不可能な作業は残ることから、人による検査周期の延長など省力化・効率化がどの程度図られるかを明確にする必要があるとの見解が示された。また、同システムの円滑な導入にあたっては、実運用を見据えて、開発段階から現場作業員の意見を反映させることが必要との意見があった。
列車見張員支援システムについては、他の鉄道事業者への横展開を図る意向が示された。
上記の深度化テーマのようなソリューションシステムの共用化または円滑な導入にあたっては、
コスト面でのメリットだけではなく、将来の労働力不足を見据えて、労働環境の改善や安全性の向上などのメリットや複数事業者が共同で進めることによる早期の導入に対する期待が示された。
283

また、複数事業者のデータにより安全性が担保されること、将来のロードマップが明確にされることなどが事業者の意思決定のハードルを下げるために必要であるとの意見があった。

（4） 第 4 回鉄道協議会での主な内容
1） 目的、議題および資料
第４回協議会の主な目的、議題及び資料は以下のとおりである。
■主な目的①5G ソリューションの共用形態に係る実証試験結果の共有②共通ソリューション化に係る今後の取組みに関する意見交換
表 4.1.3-5 第 4 回鉄道協議会（2023 年 3 月 15 日開催）
議題

1．第 3 回協議会の議事内容の確認
2．実証試験結果の報告
3．共通ソリューション化に係る今後の取組みに関する意見交換

資料

資 料 4‐1 ： 5G 等 を 活 用 し た ソ リ ュ ー シ ョ ン の 普 及 展 開 に 関 す る 協 議 会 名 簿（2023.3.15 現在）
資料 4‐2：第 3 回協議会 議事録
資料 4‐3：5G ソリューションの共用形態に係る調査事業～実証結果～

2） 5G ソリューション共用形態に係る実証試験結果の共有
鉄道車両監視 AI システムの実証試験結果を共有した。
検知対象物によって検出率・網羅率に差異が見られたこと、単独モデルと混濁モデルでの検知精度に有意な差が見られなかったこと、AI 画像解析の共通部と AI モデル構築との違いなどについて、以下の意見交換があった。
➣台車き裂の検知について➤弊社では超音波探傷検査やカラーチェックなどを用いた検査を行っており、き裂を目視で確認できる状態に至るまでに検知する努力をしている。一方で、そのような検査をす
り抜けて、新幹線の台車亀裂のように目視できる亀裂まで進展するケースもあり、重大な問題となることがある。日常の点検ではカメラ画像（目視）で確認できないき裂に対して探そうとしていることから、この実証試験のシステムは最悪の状態を見つけようと
284

するものと感じた。
➤カメラで確認することは目視での確認と同じであるという指摘はそのとおりだと思う。
また、台車の内側等のカメラ（目視）で確認ができない部分に対しては、マルチモーダ
ルの方法（カメラ画像以外のものと組み合わせる）で検査するシステムを構築する可能性については今後も検討していきたい。
➣台車き裂とその他の対象物での検出率・網羅率に違いがあることについて➤台車き裂とその他の対象物（ハンドルレバー、ブレーキパッド）で検出率・網羅率に大きな差がある。AI は形があるモノを判別するのは得意であるが、一部の変化を発見するのは不得意であるというイメージを持った。将来的にブレーキパッドに対しては残存率だけでなく欠損の有無も判定したいと考えており、仮に一部の変化を発見することが不得意である場合は、このシステムの課題になると思った。
➤詳細については分析中であるが、検出率・網羅率に対してはカメラ画像全体に対する対象物の大きさや見分けやすさが影響していると考えている。今回の実証試験の場合、ハンドルレバーは画像に占める領域が大きい一方で、台車亀裂は画像に占める大きさが小さく、目視でも見分けづらい。このことが、今回の検出率・網羅率の結果に繋がっていると想定している。ブレーキパッドの欠損も同様に、欠損の大きさによって検出精度に差が生じると想定する。
➣アノテーション支援ツールを用いた対象物の拡大について➤列車検査システムの発展形として、今後は対象物を台車周りだけでなく、パンタグラフ
等へ展開していくとのことであり、それは複数の事業者で共同利用することをイメージされているとのことだが、もし新たに検知対象物を増やしたい時には、アノテーション
支援ツールを用いて、各事業者で対象物を増やすことはできるのか。
➤アノテーション支援ツールはベースとなる AI モデルに対して追加学習させていくツールである。そのため、教師データを用いて AI に覚え込ませていない、全く別の対象物については、新たに AI に覚え込ませてモデルを構築する必要があり、現在の仕組みではそれを事業者で行うことはできない。
➣特化型汎用モデルと混濁モデルで検知精度に有意な差が見られなかったことについて➤実証に使用した台車の種類は様々であり、素人の目でも明らかに異なる台車を使用していた。異なる事業者でも同じメーカーの台車を使用している場合もあり、特化型汎用モ
デルは、最適なモデル構築の観点では、事業者単位ではなく、台車単位でも考えられる
可能性がある。地域によっては車両の標準化も進んでいることから、似たような台車で
AI モデルを構築することも考えられる。
➤弊社では古い車両から新しい車両まで、様々な形式・構造の台車を使用しているので、全く外見が異なる台車であっても特化型汎用モデルと混濁モデルで性能に大きな差がな
かったことは有意義な結果だと考えている。
285

➣ AI 画像解析の共通部と個社の AI モデル構築との違い・仕切り線について➤AI 画像解析の共通部と個社の AI モデル構築との違い・仕切り線について、共通部は AIを動かす部分を共有するイメージである。共有化するシステム全体の利用料金を低減するという観点では、個社モデルではない、共通部が影響すると思う。
➤複数事業者におけるシステムの共用化にあたっては、AI の個別最適と共通化・共用化
する部分は考える必要がある。個別の最適化はアノテーション等を用いて行い、AI モデ
ル構築の範囲内でも共通でモデル構築できる部分は共通化する、ということについては
今後検討していくべき課題である。
➤今回の実証試験結果は、過年度の京急電鉄モデルに西日本鉄道のデータを追加して構築した AI モデルと西日本鉄道のみのデータで構築したモデルを比較した結果、検知精度に有意な差がない結果となっている。今回の実証試験では、データを多く集めることが課題でもあった。今後、画像の枚数、取り込む鉄道事業者数の増加に応じて、特化型汎用モデルと混濁モデルでの差がより大きくなることも想定されるが、今後その検証をしていきたい。また、特化型汎用モデル・混濁モデルで差異が大きくなかった理由として、画像を AI に学習させる人やクラック形状が同じであり、これらにバラつきがなかったこともあると考えている。
➤弊社で取り組んでいる軌道巡視システムについて、現時点までは、弊社内のデータのみを用いてモデル構築し、弊社内路線を対象に実証試験を行っている。今後、このモデル
を他事業者の路線で試験した際の検知精度はどうか、他事業者のデータを追加して構築したモデルを他事業者で試験した場合に検知精度はどうか、更にそれを弊社内で試験した場合の検知精度はどうか、ということを比較していきたい。今回の実証試験結果により、複数事業者の画像データを用いて構築したモデルが、単独事業者のデータを用いて構築したモデルよりも、検知精度が劣る可能性があるという認識をした。
➤単独事業者で学習させたモデルに他事業者の画像を追加学習させた場合、一度精度は低下するものの、更に画像の量を追加し、他事業者の画像も追加していくと最終的には検知精度が向上する可能性はあるのか、逆に、他事業者の画像枚数を追加していくほど、検知精度は下がる一方になるのかについては今後の検討課題である。
➤必要な機能の範囲内での汎用性をどこまで持たせるかのスタンスによっても異なると思う。また、マルチモーダルと言われる複数のモノを同時に検知する AI も研究・開発が進んでおり、将来的にはこの活用可能性を含めて今後も検討が必要と考える。
➤検知する対象及び特徴によって詳細な部分は異なることが考えられるが、共通化が図れる部分については最大限に共通化し、それに個社最適が必要な部分は追加することによって、システム全体としてのトータルコストを抑えるシステムを検討することが目指す方向性なのではないか。

286

3） 共通ソリューションに係る今後の取組みに関する意見交換
3 つの深度化テーマについて、第 3 回協議会の共通ソリューション化のスキームの議論や事務局で実施した意向調査の結果を踏まえて、今後の取組みに関する意見交換を実施した。

a. 車載モニタリングシステムについて
事務局で実施した車載モニタリングシステムに関する意向調査の結果を受けて、次年度のシス
テム開発の進め方や協議会との連携について以下の意見等があった。
➤第 3 回協議会を受けて、事務局より車載モニタリングシステムに関する意向調査を実施した結果、多数の事業者が興味を持たれているとのことであった。東急電鉄の取組みに対しては本協議会参画事業者の注目度が高い印象である。
➤事務局より実施した意向調査では、来年度の総務省の実証事業に対して共同エントリーの意向がある事業者はいなかった一方、興味がある等の前向きな意向を持つ事業者が多くあったので、引き続き情報交換・意見交換をお願いさせていただきたい。主に保線部門ではあるが、この協議会を通して他社と意見交換ができるようになった。来年度の実証事業については、協業の可能性を他事業者に声掛けしている状況ではあるが、実証計画を具体化して実証を継続していきたいと考えている。
➤来年度も本協議会の活動は継続したいと考えており、可能な範囲で情報共有いただきたい。また、参画する他事業者を増やせるような場として活用いただきたい。

b. 列車検査システムの発展形について
列車検査システムの発展形について、事務局より今後の進め方を共有した。
➤具体的なシステム内容や費用感を示す予定としていたが、現時点で詳細な説明ができる
ような段階に至っていない。今後、興味のある事業者と議論・意見交換しながら、効率的かつ安価なソリューションシステム構築に向けて提案していく予定。
➤これまで台車周りを中心としていたシステムからパンタグラフを含む屋根上等に広げてシステムを発展されていくことに関しては、技術的な観点からの検討を引き続き進めた
いと思っている。その際には、鉄道事業者にとって有用なシステムを構築できるように、事業者と意見交換・議論しながら内容を詰めていきたいと考えている。

c. 列車見張員支援システムについて
列車見張り員支援システムについて、以下の現状報告があった。
➤今年度末までの導入に向けて、システムの最終調整中である。具体的には、列車が接近してきた際に、設定した一定区間を列車が走行中は、通知が鳴り続け、列車見張員が端末機器を操作すると通知が消える等の仕様変更を実施している。
287

➤他事業者への横展開は、現時点ではベンダーとの具体的な検討をできていないが、基本
的には横展開していく方向性で検討している。電波を含めて路線環境は事業者によって異なると思うが、何らかの形で活用は可能ではないかと想定している。

d. 共通ソリューション化に係る今後の取組みに関する意見交換
3 つの深度化テーマに関する今後の取組みに関して、鉄道事業者等から以下の意見があった。
また、今後の共通ソリューション化を見据えて、本年度の協議会で選定した 3 つの深度化テーマ
以外に、共通ニーズ（テーマ）として検討が考えられるテーマに関して鉄道事業者から以下の意見があった。
➣車載モニタリングシステム（東急電鉄）に係る今後の取組みに関する事業者の意見➤コンソーシアムに参画していることもあり、今後も引き続き協力していきたい。
➤来年度の参画は難しいが、今後いずれ必要となるシステムであると感じており、重要なテーマと考える。
➤人手不足解消の糸口になるのではないかと感じた。
➣列車検査システムの発展形に係る今後の取組みに関する事業者の意見➤弊社の保有車両の種類が幅広い（異なる年代の車両、直通運転しているＪＲの車両がある）ことから、共通化が難しいかもしれないと感じた。
➤今後実現していきたい内容である。今年度の実証試験では、台車亀裂やハンドルレ
バー、ブレーキパッドを対象としていたが、今後は、事務局から提案のあったとおり、
パンタグラフを含めた列車検査全てをカメラや AI を用いた点検に置き換えることができれば、更なる省力化が見込めると感じている。今年度の協議会で参画事業者との繋がりができたので、今後もこの協議会の場で、引き続き情報交換できればと考えている。
➤列車検査システムを導入することで人による検査周期を延ばす等の検査の省人化・省力化に繋がるのであれば、実際の導入も考えられると思うが、現時点での状況を踏まえると、実際の導入までにはもう少し時間を要するのではないかと感じている。ただ、今後の人手不足に対して、AI を活用したソリューションは非常に有用であると感じている。
➤台車亀裂の検査等、技術が必要であるとともに時間が取られるので、省力化が図れるのであれば将来的には有用だと考えているため、今後も引き続き取り組まれるのであれ
ば、情報共有等をお願いしたい。
➤本協議会の開催前から、車両の状態監視を通して列車検査の省力化を図る取組みをしてきたが、目視による検査が必要であることが課題だった。そのため、今回の列車検査シ
ステムはその課題解決に繋がると感じている。
➤将来の人手不足への対策が切実な課題である。本年度の実証試験では側面からの検査を対象としていたが、これに加えて打音や高解像度の映像を含めて、どこまで人による検査を代替できるのかということに対して期待をしている。このような取組みについては
288

自社単独では実現が難しいため、本協議会のような情報共有の場があれば非常に助かる。
➣列車見張員支援システムに係る今後の取組みに関する事業者の意見。
➤横展開も検討されているということだったため、その際には、お声がけいただきたいと考えている。
➤横展開の可能性があるとのことだったので期待している。
➤弊社では列車見張員の高齢化・人数不足の問題があり、工事の繁忙期は見張員の取り合いが生じ、工事を行いたいタイミングでできない状況も生じていることから、このようなシステムを導入することで補完・支援できるのであれば良いと思った。
➣今年度取り上げた３つの共通ニーズ以外に、本協議会で取り上げることを期待するテー
マに関する事業者の意見➤弊社では、ドローンや３次元点群データを用いた構造物の点検に関する取組みを行っている。土木構造物は事業者間で大きな差があるものではないため、共通項が多く、ソリューションの共有化も図れる可能性があると感じている。
➤ホーム上及び踏切の安全が考えられる。ホーム柵設置が費用面等で難しい路線などに対して、AI 画像処理を用いたソリューションがあれば助かるのではないか。今後の検討に加えてもらえればと思う。
➤ AI やカメラを用いたホーム上・踏切の安全確認についても、省人化・省力化にどの程度効果があるかわからないが、鉄道会社として安全確保は重要事項であり、追加のテーマとして良いのではないか。
➤土木構造遺物、ドローンでの点検が挙げられるのではと思う。弊社でも土木構造物の検査のために、現場へのドローン配備、操縦者の教育を開始したところであるが、今後は、取得画像の活用方法が課題となると想定され、AI・画像処理による検知がその解決策の１つになるのではないかと感じた。
➤将来の人手不足への対策が大きなテーマと考えている。事業者同士で、どのようなことを機械に代替させれば省力化に繋がるのかを話し合い、方向性を定めることで本協議会のような取組みが前に進むのではないかと思っている。今後も本協議会のような意見交換等ができる場があれば参加させてもらいたい。

e. 今年度の協議会の振り返り
本年度の協議会活動及び次年度以降の協議会の継続開催に関して、鉄道協議会・オブザーバー
から以下の意見があった。
➣今年度の協議会での活動を振り返った事業者・オブザーバーの意見➤協議会参加前は、係員による列車巡視を AI 画像処理に置き換えられると良いと感じていた一方、AI 画像処理では係員の暗黙知が表れにくく、列車巡視全体を考えた時に AI
画像処理へ置き換えることのゴール設定が難しいと思っていた。本協議会に参加したこ
289

とで、例えば、列車検査の項目の一つを AI 画像処理に置き換えられるのであれば、その分の作業工数が減少し、省力化が図られる。全体のうち１つずつ置き換えていくことで効果があるということを学んだ。
➤今後も本協議会の参画事業者とは、様々なソリューションに関して意見交換させていただきたい。
➤コロナ禍で利用者減少の影響が大きく、車両や機器などが高額で人件費を含めた固定費がかかるということを改めて実感している。技術を上手く活用して、固定費を下げるよ
うなことができないか、数年前から社内でも取り組んできたところではあるが、単独ではシステムの導入コストが高く、日常の業務で手一杯で新たな取組みに人を充てることができないような状況で、新たな技術の導入には至っていない。ただ、このような協議会の場で複数の鉄道事業者と情報交換をすることで、単独でやるよりも導入がしやすくなると考えている。このような協議会などの情報交換の場を通じて、鉄道業界全体で利益を生み出せるような、固定費を下げられるような取り組みができればよいと考えている。
➤軌道巡視システムや列車検査システム（実証試験）に関しては、これまでそのような着眼点を持って考えたことがない分野であったので、大変勉強になっている。列車見張員
支援システムについては、弊社でも同じような課題を感じていたので、今後進展があれば情報共有いただきたい。AI・システムを育てることは、人を育てるのと変わらず、時間や労力がかかるものであると感じた。このようなテーマに対しては、弊社も腰を据えて取り組む必要があり、そのような際に本協議会のような事業者間での情報共有の場があればよいと感じた。
➤鉄道事業者には共通のニーズ・課題があるものの、これらの課題解決等の取組みに関しては、各社が個別に検討をしてきたのがこれまでの状況であった。また、鉄道事業は固定費比率が高い事業であるが、コロナ禍を契機に利用者数の減少による減収のダメージを受け、設備の維持がより難しい状況となり、技術を活用してより少ない人数で現行の鉄道運行を維持するという考え方は各鉄道事業者が共通に持っていると思う。そのため、今後は鉄道事業者共通の課題は鉄道事業者間で協力して新しい技術等に挑戦していくことは必要だと感じている。この協議会などを通して、意見交換だけでなく、時には協力して活動していく場を提供いただければありがたい。
➤この協議会を通じて他の事業者も似たような課題・ニーズがあることがわかり、また幅
広く情報収集できて勉強になった。本協議会の開始前に、社内で各部署から課題・ニーズを収集したが、困ったことや課題はあるかという聞き方であった。本協議会でも議論の話題となったが、将来の人手不足は明らかである。次年度もこの協議会のような場に恵まれるのであれば、10～20 年後の職場環境を見据えた時に、省力化が必要な業務は何か等の聞き方をして、社内での意見聴取をしたい。
➤本協議会を通して、現状の技術や技術的な課題がわかったので勉強になった。
➤人口減少に伴う人手不足、コロナ禍による経営状況の悪化などに起因した各社の課題を横串する本協議会の活動内容は、本来であれば国が行うべきことであり、線路巡視や列290

車検査等のテーマに対して本協議会で各事業者が主体的に議論してもらい、勉強させていただいた。本日の意見交換の中でも、各社の抱えるニーズを捉えるという言及があったが、その点に関しては当課でも協力できると思う。また、列車検査システムは、今後も引き続き検討されるとのことであったので、技術開発費補助金、各社への声掛けな
ど、協力できることがあれば協力したい。

4） まとめ
第４回協議会の主な目的に対する結果は以下のとおりである。

a. 5G ソリューションの共用形態に係る実証試験結果の共有
本年度の鉄道車両監視 AI システムの実証試験結果を共有した。
単独事業者のデータにより構築した単独モデルと複数の事業者のデータにより構築した混濁モ
デルでは検知精度に有意な差が確認できなかったことに関して、事業者によっては様々な形式・構造の台車を使用していることから、これらのモデルで性能に大差がないことは有意義な結果であること、異なる事業者でも同じメーカーの台車を使用している場合もあり、事業者単位ではな
く、台車単位でのモデル構築も考えられることなどの意見があった。
一方、今回の実証試験では教師データの量に限りがあったことや少人数により画像を AI に学習させたことから、教師データの量や学習させる人数が増えた場合に、単独モデルと混濁モデルの検知精度に差が生じる可能性があるとの意見もあった。
また、アノテーション支援ツールを活用した AI モデルに対する追加学習は、現時点では事業者で実施できないこと、長期的な使用により AI が学習するデータ量に応じて検知精度が向上するか否かなどについて検討課題であるとの見解があった。

b. 共通ソリューション化に係る今後の取組みに関する意見交換
3 つの深度化テーマに対しては、その開発・活用の必要性があるとの見解が鉄道事業者から示された。また、車載モニタリングシステム及び列車見張員支援システムに関しては、開発事業者
により今後の横展開の検討の意向が示された。列車検査システムの発展形についても、複数の鉄道事業者による共通化を図るために、今後も継続的に検討を進める意向が示された。
本年度の深度化テーマ以外に、共通ニーズとして検討が考えられるテーマとしては、土木構造
物（橋梁やトンネル）点検に対するドローンの活用やホーム上・踏切での安全対策が鉄道事業者
より挙げられた。

c. 今年度の協議会の振り返り
本年度の協議会の活動に対しては、他の鉄道事業者が抱える課題・ニーズ、課題解決のための技術やそれら技術の課題などの把握・共有ができたとの意見があり、情報提供・共有の場としての意義・必要性を再認識した。
291

また、協議会の場を活用することで、他の鉄道事業者と協力できることや複数の鉄道事業者が協力することで、課題解決に資するソリューションシステムの開発・導入へのハードルが下がるなどの意見があり、複数の鉄道事業者が協力して取り組むこと、ソリューションシステムの共有化を図ることの意義・必要性を確認するとともに、協議会がこれらの取組みを促進する有効な場であることを確認した。

鉄道協議会のまとめ
本年度の鉄道協議会の開催目的等を踏まえた、活動結果のまとめを以下に示す。

（1） 鉄道車両監視 AI システムの共用化実現に向けた具体的方策
鉄道車両監視 AI システムに関しては、検知対象範囲を台車周りだけではなく、現状の列車検査
項目のうち、主に目視による検査項目を対象に範囲を拡大させていくことに対して、鉄道事業者
から以下の期待が示された。
・将来の人手不足への対策として、画像・AI を活用することで、各検査項目の作業の効率化、省人化・省力化とともに、人による列車検査周期の延長の可能性がある。
・高所作業の削減は、安全性の確保および職場改善となることから、離職率低下に繋がる可能性がある。
・AI モデルを汎用化し、シェアすることでコストダウンが図れる。
・共同開発することで、1 社で行うことより早く実現できる可能性がある、他社の知見・ノウ
ハウを得ながら進められる、複数事業者のデータを基により安全性が担保できれば社内での意思決定も図りやすくなる。
・検知する対象及び特徴によって詳細な部分は異なることが考えられるが、共通化が図れる部
分については最大限に共通化し、それに個社最適が必要な部分は追加することによって、システム全体としてのトータルコストを抑えるシステムにできる可能性がある。
一方、この鉄道車両監視 AI システムの共用化を実現するにあたっては、鉄道事業者から以下の課題・懸念事項が示された。
・パンタグラフのすり板の素材や台車の型式・構造などは多種類あることから、多種類ある検査対象物に対して検知精度を確保するシステムとする必要がある。
・部品交換など画像・AI による代替ができない作業もあることから、システムを導入することによる作業の効率化、検査の省力化・省人化に対してはより具体的な、もしくは定量的な効果を把握することが重要である。
・実運用へ円滑に移行するためには、開発段階から現場との協働が大切である。
・システム導入後のアップデート（検知対象物の拡大など）を事業者で実施できるとより有効なシステムとなる。
・検査対象物によって検出率・網羅率が異なるため、対象物によってはシステムによる検査・
292

異常検知が難しい可能性がある。
以上のことを踏まえて、鉄道車両監視 AI システムの共用化実現に向けた今後の検討課題を以下に示す。
・鉄道事業者が導入の意思決定をするためには、コスト面での効果（省力化・省人化・作業の効率化）を定量的に把握し、費用対効果を示すことが必要
・定量的な効果の把握、検査対象物の拡大を図るためには、鉄道事業者との意見・交換を継続して、実態把握・検討の深度化が必要
・長期的な観点での検知精度向上及び汎用性の確認のため、単独モデル・混濁モデルの比較検討の深度化が必要
・低コストでの共通ソリューション化、モデルの最適化を図るため、AI 画像解析の共通部の最大化や、共通部・個別最適部の差別化に係る検討の深度化が必要（2） 鉄道事業者の鉄道 DX に係るニーズの把握、共通ニーズの発掘
本年度の鉄道協議会は、約４カ月間で計４回の開催であったことから、複数の鉄道事業者の共通ニーズのうち、車載モニタリングシステム、列車検査システムの発展形、列車見張員支援シス
テムの３つを深度化テーマとして選定し、ソリューションの共用化等について議論した。
一方で、鉄道事業者の鉄道 DX に係るニーズは、深度化テーマだけではなく、多岐の分野にわたって複数の共通ニーズがあることを把握できた。
具体的に、共通ニーズとして考えられる項目は以下のとおりである。
■土木分野➤構造物（橋りょう、トンネル）の点検におけるドローンの活用■軌道分野➤軌道巡視（バラスト劣化・振動など）に対するドローンの活用➤車載カメラ映像による軌道巡視の前方監視➤保守作業時の列車接近情報の把握■車両分野➤車両検査のデジタル化➤列車検査の画像、映像による AI の異常判定➤パンタグラフのすり板摩耗の検知➤異音検知➤車両モニタリングデータの取得（常時監視）➤カメラによる車内監視■駅務分野➤白杖者・車いす利用者の捕捉
293

➤軌道転落者の検知■電気分野➤電車線点検業務に対するドローン・車載カメラの活用➤鋼索線の無人運転化（車掌の無人化）➤踏切内の立ち入り監視■その他➤新入社員の確保による人材確保
これらの共通ニーズについては、鉄道事業者の現状の取組みや既往技術などを踏まえながら、
課題解決に資するソリューションシステムとしての共用化を検討することが考えられる。特に、土木構造物の点検に関しては、事業者によって点検項目等に大きな差異がないと想定されることから、共通ソリューション化を図ることで、より汎用性の高いシステムにできる可能性があるとともに、より多くの鉄道事業者にとってメリットがあると考えられる。

（3） 鉄道事業者の共通ニーズの解決に資するソリューションシステムのイメージ
具体化
鉄道車両監視 AI システム（列車検査システムの発展形）以外の鉄道事業者の共通ニーズの解決に資するソリューションシステムについては、複数の鉄道事業者から興味が示され、共通ニーズとして考えられたことやソリューションシステムの開発や実証試験が既に進んでおり、その目的・技術的な内容が明確であったことから、車載モニタリングシステム（軌道巡視システム）と列車見張員支援システムの２つを本年度の協議会では選定した。
車載モニタリングシステムについては、自社路線でのデータ取得による AI モデル構築及び自社路線での実証試験から、他事業者の路線での実証試験、他事業者でのデータを取り込んだ AI モデ
ル構築（混濁モデル）及び自社路線での実証試験、混濁モデルを活用した他事業者の路線での実証試験と、段階的なモデル構築・実証試験を通じて、同システムの実運用を目指す方向性が示された。また、他事業者への導入型式としては、導入後のシステム更新等を考慮して、買い切り型ではなく、サブスクリプション型が望ましいとの見解が多数の事業者から示された。サブスクリ
プション型を想定した場合の価格設定に対しては、事業者によって路線環境・利用環境（路線延長、設備数、検知対象物など）が異なることから、これらの環境及び AI やクラウドサーバ等の利用状況に応じて価格設定することや、システム内の個別機能ごとに価格設定することなどの意見があった。
列車見張員支援システムについては、開発事業者の路線環境や低コストでの導入ニーズにより、簡易なシステム構成となっており、複々線区間での列車検知が想定されていないことなど、開発事業者による他事業者への横展開は検討されているものの、他事業者への汎用性には課題がある
ことを確認した。
また、上記のソリューションシステム以外にも、土木構造物の点検へのドローンの活用やホー294

ム上・踏切での安全対策への AI 検知の活用などが共通ニーズとして考えられるとの鉄道事業者からの意見があった。
以上のことを踏まえて、車載モニタリングシステム及び列車見張員支援システムに関しては、
今後も協議会を活用して鉄道事業者間の情報共有を図り、複数事業者への横展開の取組みを促進
するとともに、その他のテーマについても、より具体的な実態・ニーズの把握に努め、共有化を見据えたソリューションシステムの具体化を進めることが考えられる。

（4） 鉄道協議会の継続開催について
本年度の協議会では、過年度から参画事業者数を増やすことで、鉄道事業者が抱える様々な課
題やニーズを把握することができたとともに、他事業者の課題・ニーズや DX に係る取組みの現状を共有できたことに対して鉄道事業者から好意的な意見が多数あり、鉄道協議会が情報提供・共有の場として意義・必要性があることを確認した。
また、事業者が単独でソリューションシステムを開発・導入することのハードルは高いが、他の事業者と協力することで、これらのハードルが下がるとの意見や、これらの取組みを進める上で協議会のような場の提供への期待が鉄道事業者から示された。
このことから、本年度の鉄道協議会は、次年度以降も継続して開催することとし、引き続き、共通ニーズの発掘や共通ソリューション化を見据えたソリューションシステムのイメージの具体化並びに複数の鉄道事業者で協働するスキーム等の検討を進めることで合意した。

次年度以降の取組に関するまとめ・展望
本事業の成果として、SaaS 型システム構成での共通システムの運用可能性や課題を明確化するとともに、鉄道 DX 協議会参加の複数の鉄道事業者の協力を得ながら、鉄道業界の課題解決に係る共通システムの共同開発スキーム（仮称「鉄道 DX 共同開発スキーム」）の実現性を確認した。
「鉄道 DX 共同開発スキーム」では、複数事業者による共同出資・共同での外部資金調達を行う
ことで、鉄道業界の課題解決に係るシステムを低コストに開発し、共同で利用することを想定する。この枠組みより、鉄道業界の DX を推進し、業界全体の課題を持続的に解決する、鉄道 DX 推
進の起爆剤となることが期待される。（図 4.2-1 参照）

295

図 4.3-1

鉄道 DX 共同開発スキーム（仮称）のイメージ

今年度の鉄道協議会参加鉄道事業者を中心に他の鉄道事業者の参加も見据え、次年度以降も鉄道協議会を継続開催し、鉄道車両監視 AI システムの共用化の発展形、あるいはそれ以外にも鉄道事業者が共用形態で利用できるソリューションの共同開発に向けて、連携していくこととした。

296

5.

本年度実施総括
今年度事業では、大きく 3 つの検討・検証にフォーカスして調査検討を行った。
（１）情報提供・共有の検証
5G ソリューションの情報提供・情報共有に係る検証として、情報の提供方法、共有の方法としてカタログサイトの活用による実施手法の検証および、その効果の調査検討を行った。
（２）5G ソリューションの共用形態に係る検証
5G ソリューションの共用形態として、SaaS 型での提供モデルの技術検討を行った。
検証の軸となるソリューションについては、令和 2 年度から 5G ネットワークを活用したソリューションとして実証を重ねている「鉄道車両監視 AI システム」を SaaS 型共用モデルとして再設計し、鉄道会社 2 社の協力を得ながらフィールドでの実証を行った。
（３）将来的な 5G 技術を活用した共用形態・分野横断的な 5G ソリューションの横展開の検討（２）で検討した SaaS 型提供モデルについて、5GSA と MEC などこれから普及展開を見据える技術を活用した展開・共用を想定し、5GSA、MEC 構成とした場合での有効性、論点、課題、今後必要な検証等について調査、検討を行った。
また、5G ソリューションの分野横断的な横展開について、共用形態で必要な作業、課題、今後必要となる検討・検証等、サービス提供に関する論点に関して検討を行った。
（図 5-1 参照）
以降の項では、今年度、検証をおこなった各実証内容の結果をとりまとめ、今年度の実証に対する統括を記載する。

図 5-1

今年度実証でフォーカスされたポイント
297

5G ソリューションの情報提供・情報共有に係る検証
自社に課題を抱えた企業が課題の解決策を検索していく中で、自社の課題解決に繋がるソリューションに出会う。5G はこれらのソリューションを効率的に活用・促進する一つの手段である。
5G ソリューションが普及・展開していくには、これら自社に課題を抱えた企業に向け、効率的なソリューションの活用を促すような情報が企業の手に届くべきである。5G ソリューションの導入を検討し始めた企業においては、5G に関する技術や AI/IoT などの先進的な ICT 技術に関する知見、DX による業務変革を行うための事業計画の具体化の術を有しておらず、外部の有識者や先駆者の情報・事例をもとに検討されるケースが多い。そのため、事業実施主体単独で 5G 活用事業
モデルの具体化を進めていき、後続の導入プロセスを進めていくことは困難である。
5G ソリューションの導入を検討し始めた企業において、企業単独で 5G 活用事業モデルの具体化を進める最初の段階での情報収集の場の整備として、本実証では、以下の 2 点に注目し、5G ソ
リューションの展開に向けた情報提供・情報共有を行う場としてのカタログサイトの有効性を実証し、将来的に必要となる情報発信などの形態、求められる情報、機能などについて机上検討・考察をおこなった。
①

5G ソリューションの情報提供・発信を行うカタログサイトの有効性の確認
サイトで掲載するコンテンツに求められる機能や情報、また情報到達への簡素さ
情報収集の効率性の確認②

今後必要となるカタログサイトの発展形態の検討
情報提供、発信を行うのみにとどまらず、より 5G ソリューションの導入に寄与するようなポ
イント、課題、今後求められる機能などのアーキテクチャの仮説を検討。
以下に、その調査・実証の結果サマリを記載する。
（１） カタログサイトの設計コンセプト
・情報提供・共有を行うために必要となる要件、機能について、利用者にとって有益となるコンテンツ内容の表示方法、情報の粒度の整理および、サイト閲覧時の情報への到達性にも留意し、サイト内の回遊性、情報到達動線を意識した設計を行った。
（２） カタログサイトの公開
・カタログサイトは、令和 4 年度ローカル 5G 開発実証ソリューションに関する情報コンテンツの掲載をおこない、インターネット上に一般公開した。
・実証期間中のアクセス向上を図るため、メールマガジンなどの媒体を用いてサイト誘導を実施した。

298

サイト訪問者・情報提供者の分析
・サイトの利用者・情報提供者に対して、アンケート取得及び、サイト閲覧時のアクセス分析を合わせて行い、利用者・提供者観点でのサイトの有効性に関する評価を行った。
◇カタログサイト利用者
・来訪目的として、「顧客に提案可能なソリューションの調査」「自社の課題解決に繋がるソリュー
ションの調査」の２つが大半を占め、自社の課題解決だけでなく、顧客への提案を目的とする層からの期待が大きいことが確認された。
・半面、より多くの事例がほしいという要望も高く、本実証で掲載した情報以外にも掲載件数の増加と共に、掲載するジャンルの多様化も求められる内容であった。
・また、本カタログサイトの閲覧を通し、5G ソリューションの導入を検討したくなったというポ
ジティブな反応が多数あり、このような情報提供サイトの存在が求められている状況であることが確認された。
◇情報提供者
・情報提供をいただいた各社からは、今後、当該サイトのようなものがサービス化された際には、情報の掲載を行いたいという声が多く、カタログサイトへの期待を感じる結果となった。
・提供者による情報掲載手順の負担については、負担は少なかった、適切である。というポジティ
ブな反応が多く、情報掲載に関する情報の種類、粒度について、情報提供者への負担は適切であることが確認できた。ただし、利用者の声として掲載ジャンルの多様化などを求められる点を考慮すると、ジャンル情報の入力方法など、負担とのバランスを考慮した検討が引き続き必要と考えられる。
・本実証では、適切な掲載ジャンルが無いというご指摘もいただいた。これは、カタログサイト
設計時の情報ソースの絞り込み不足に起因しているものである。サービス化を目指す際には、業種や業態の網羅性について再考する必要がある。
このようなカタログサイトの利用状況の分析および、利用者・提供者へのアンケート結果を踏まえ、サービス化を進めるにあたっては、下表のような点を考慮して、検討を行う必要があると考える。

表 5.1-1 将来追加で求められる検討要素および機能（再掲）299また、冒頭で触れたように企業による 5G ソリューションの普及展開に寄与するためには、
・幅広くカタログサイトの存在、情報共有の場が認知されてコミュニティとして活性化がされること・また、情報収集以降の導入検討プロセスに対して円滑につながっていくための仕組み作りが将来的に必要となる。
これらが、事前に想定した情報提供・共有の場の課題に対しての改善の一助になることが期待される。

5G ソリューションの共用形態に係る検証
5G ソリューションに係る SaaS 型モデル実証実験
5G ソリューションの普及・展開を目指し、地域や中小企業等の各産業分野の振興に資する効果
的な 5G ソリューション等の普及展開方策を検討するにあたり、鉄道事業分野における「鉄道車両監視 AI システム」をロールモデルとして SaaS 型提供モデルを構築し、検証を行った。
令和 2 年度 L5G 実証において、オンプレミス型（SI 型）で構築した 5G ソリューション「鉄道車両監視 AI システム」の検証では、鉄道車両の異常検知に資することが確認できたものの、個別環境の構築及び利用等にかかるコストの大きさが課題とされた。
この課題を解決する可能性のあるものとして DL 型で構築した 5G ソリューション「鉄道車両監
視 AI システム」の検証及び SI 型との比較検討が求められた。
令和 3 年度 5GSC 実証において、DL 型で構築した 5G ソリューション「鉄道車両 AI システム」の検証では、「実装可能性」「水平展開可能性」「実用性」の観点で DL 型の 5G ソリューションの有効性が確認できたが、導入側のシステム導入難易度や費用対効果の面で課題があることが確認さ300れた。それらを解決する可能性のあるものとして「鉄道車両監視 AI システム」を SaaS 型で構築
し、5G ソリューションの共用形態に係る検証および DL 型との比較検討を行うことが求められた。
そのため、今年度はさらに、利用者にとってよりシステムの導入ハードルを低くするという観点で SaaS 型による、5G ソリューションのアーキテクチャの汎用化や複数事業者による共用化に関するシステム実証実験を行った。
この実証実験の目的を「5G ソリューションの汎用化・共用化」を行った場合に生じる技術的な課題をまとめることと、実証実験では、まず３つの汎用化レベルを定義した上で、それぞれの汎用化レベルに対応した実証スコープを設定し、検証を実施した。

図 5.2.1-1 汎用化検討のレベル別分類イメージ（再掲）301図 5.2.1-2

SaaS 型「鉄道車両監視 AI システム」の全体イメージ（再掲）■レベル１ 「システムアーキテクチャ」の検証結果「汎用技術のみで構成可能か」という観点で実施したレベル１の検証結果は以下のとおり。
・クラウド上のアプリケーションを実行するうえで今年度構築した SaaS 型システムアーキテ
クチャと過年度の DL 型システムアーキテクチャと比較しての動作検証は問題なく完了。
・クラウドと現地環境の NW 接続形態については、ロールモデルにおいては双方の接続形態での活用が可能であることが確認され、より低遅延性を求められるユースケースでの活用時においては、MEC による接続形態をとることが望ましい。
■レベル２ 「システムの汎用化」の検証結果「共用するため」や「利用効率を向上することが可能か」という観点で実施したレベル２の検証結果は以下のとおり。
・マルチテナント管理機能を実装した結果、複数事業者による同時利用が可能であった。
・複数事業者利用時における AI 検知性能について、SaaS 型に改修をおこなったことによる大きな課題は発生しなかった。ただし、過年度 DL 型システムアーキテクチャでの検証時と同様に撮影環境や映像伝送の乱れなどの外的要因により、AI 検知性能が落ち込むという継続課題やリソース共有による解析性能を１事業者あたり制限した場合において描画性能が制限を受ける点については、引き続き検討が必要である。
・クラウドでのデータ保管管理や、複数事業者によるデータ処理に関するリソース設計について問題なく動作することを確認できた。
・今年度アーキテクチャでは、クラウドリソースをあらかじめ確保して各社で共通リソースとしてシステム処理を行った。このため、リソースで処理可能なシステム性能の上限を超過する場合においてはシステム動作に影響を生じるケースがあった。
・このケースについては、事業者あたりのシステム性能要求を明らかにし、システム性能条件をシステム構築者にて設定し、この条件を超過する場合に対して、リソースの増設計画と合わせて可用性に関するアーキテクチャの見直しおよび、リソースのモニタリングによる稼働状況の可視化、など共用形態としてシステムのアーキテクチャを発展させる際のポイントが明瞭になった。
■レベル３ 「固有機能」の検証結果「AI 処理などの汎用性を持たせながらも各社に特化する内容についての検討」という観点で実施したレベル３の検証結果は以下のとおり。
・システムを複数事業者で共同利用する際に検討が必要となる、AI 学習モデルの管理に関して、特化型汎用モデルとして、「事業者毎にモデルを管理する」点が「複数事業者で共有のモデル管理をする」ことよりも望ましい。
※事業者毎に学習モデルに入力する画像データ内の検出対象物の分類や判定する範囲、位置などが異なることもあるため、これら複数事業者のパラメータ差異を含んだ学習モデルでは、検302

知対象物の検知性能劣後が同一モデルを利用した利用者全体で発生する可能性があるため。
・学習モデルの在り方として、各社ごとにモデル管理を行い、学習データを事業者毎に特化させて検知性能を改善させていくチューニングを行えることが望ましい。そのため、「AI の追加学
習プロセス」に関し、従来 AI システム開発者で実施をしていた内容をツール化（アノテーショ
ン支援・学習ツール）し、利用者におけるツールを用いた「AI の追加学習プロセス」の実行による自社の環境に合わせた特化モデル化が可能かを実証した結果、鉄道事業社によるツールの
デモ、レクチャーを経ての実施により、有効に機能することが確認できた。
また、利用者負担軽減効果の観点からは、以下の点の効果を確認した。
■レベル１ ネットワーク/アーキテクチャ関連本実証で、汎用的な SaaS 型のアーキテクチャを取り入れて設計・構築した環境においては、従来 SI 型や DL 型と異なり、SaaS 型環境の開発・利用に係るコストについては開発や運用の総コストを利用者それぞれが按分した形で負担することになる。
今回、鉄道事業者への SaaS 型提供での負担軽減効果を試算するために利用者企業が見込まれた
場合でのコスト削減効果についても試算結果より、SaaS 型の場合、開発コストについては、各社
でそのコスト按分をすることになるため、従来形態よりも導入の敷居が下がる。
コスト構造においての課題として、利用者の拠点数が増加するにつれてクラウドリソース費用などの提供者側の運用コスト負担が増加するため、実際には利用者の拠点数増加に応じてコスト負担率を加算して按分を検討する必要がある。
実際の運用にあたっては、共同利用の事業継続性の観点で初期開発コストだけでなく、運用コ
スト面も含めた収支計画の検討を行う必要性がある。
■レベル２ 共通コア機能関連
SaaS 型利用における「マルチテナント管理」によって、各社でクラウドリソースを分散して利用することで以下のような負担軽減効果を享受することが期待される。

・ 各社で個社環境を構築する手間・稼働の削減
初期導入の段階で、従来必要であったアプリケーションを実行するインフラ環境を各社個別で設計・調達・開発を行う工程が不要となり、これらにかかっていた利用者での稼働コストの削減が見込まれる。
・ システム利用開始のリードタイムの短縮
各社がクラウド上のアプリケーションを利用する形態をとることで、初期導入時のシステ
ム開発にかかる時間を削減することができ、より早く現場でのアプリケーション利用を行うことが可能となる。
・ システム利用の頻度が増えてきた場合の柔軟なリソース追加
利用者は、提供者が手配する各種コンピューティングリソースを共同利用することになり、
従来、リソース追加に必要であった調達・基盤への組み込み工程が利用者単位での対応不303

要となり、システムの利用頻度に応じて柔軟にクラウドリソースを増減することが可能となる。必要なときに、必要なだけリソースを使用することができるため、従来のような固定費の削減が見込める。

図 5.2.1-3 マルチテナント管理によるリソース共用■レベル３ AI コア機能関連
従来、利用者が AI システムの追加学習を行うために AI 開発事業者にアウトソースしていたコストに関して、本実証で用いた追加学習機能を利用することで利用者にて代替可能であることが確認できた。従来の AI 開発事業者において専門性が高く、工数がかかる作業を利用者で内製対応することで継続的な運用コスト低減が期待される。

図 5.2.1-4 AI 追加学習プロセスの所要時間比較

将来的な 5G 技術を活用した共用形態の検証
304

5GSA、MEC など、これから普及展開を見据える技術を活用した 5G ソリューションの展開・共用を想定し、5GSA、MEC 構成とした場合での有効性、論点、課題、今後必要な検証等について調査・検討を行った。
各事業者で提供される 5GSA,MEC サービスや、5GSA、MEC を活用した実証事例やレポートなどの情報より、期待される課題解決効果と内容を確認した。
■5GSA による課題解決効果
5GSA は、ネットワークスライシング技術により、5GNSA より柔軟な通信環境が構築でき、アプリ
ケーション利用用途に合わせた通信経路の分割が可能となることで利用者にとっては業務利用時におけるメリットがある。
遅延やロスが許容されない重要な通信については、帯域を他通信と分離させることで通信経路を優先することや、ソリューション利用拠点であるエッジで処理したデータをリアルタイムにクラウド環境にアップロードしたい場合において、データ送信の大きさ（スライス）を小さくすることでデータの送信完了のリードタイムを短縮することも可能である。
■MEC による課題解決効果
MEC 技術は、クラウドの機能を分散し、ソリューションを利用する現地環境により近い立地条件にクラウドを配置することで、低遅延性とセキュリティを担保する効果が期待される。
遠隔操作など、低遅延が求められるようなソリューションにおいて、現地のデバイスと MEC の位置関係は、より近い位置に置かれたほうが効果的である。
すでに MEC を導入しているソリューション利用者のケースでは、MEC を利用しているにも拘らずソリューションの演算処理はデバイス上での処理や、現地に設置したサーバにおいて行われているケースが多い。
これは、現状のクラウド／ネットワーク事業者が提供している MEC サービスでは全国に複数のMEC 拠点が設置されているものの、その立地は十分ではなく、地方都市のユーザからみると、MECのメリットを享受できない状況にあることが原因である。
メリットを享受するためには、エッジの接続環境によらず全国一律で利用拠点から近い MEC サー
バでのエッジデータ処理がされるような MEC 拠点の立地の多様化が望まれる。
また、MEC 環境で処理されたデータが MEC 拠点間やクラウド上などの２次データ処理場においてさらにデータ加工、アプリケーション処理として連携されるようなケースも想定されるため、MEC間を接続するバックボーン NW についても日本全国で各事業者間が構築されている広域網を活用された接続形態であることが望ましい。
上記のような SA,MEC の将来の活用形態を踏まえ、本実証の鉄道車両監視 AI システムをユースケースとして考えると以下のような活用があると考える。
◇5GSA の活用
・ネットワークスライシング技術の活用により、リアルタイム性を優先したスライシング構成する。
・複数の 5G 利用業務システムが現地で共存される点を考慮して、通信の分離を行うなどの活用が考えられる。
305

◇MEC 技術の活用
本実証の実施環境よりもさらに近接した環境を選定することで描画遅延の緩和やより高精細な画像による画像認識の実装が可能となる。また、MEC 拠点の増加により、現状では SaaS 型での画
像認識 AI などのソリューションの利用が難しかった地方の事業者などで、システムの導入可能性を検討するうえで、現地環境と MEC 環境の立地を考慮する必要性がなくなるなど、ソリューショ
ンの選択肢、構成の柔軟さに寄与できることが期待される。

分野横断的な 5G ソリューションの横展開に求められる機能の検証
分野を問わず、5G ソリューションの横展開を図っていくために、SaaS 型サービスを展開する上で生じる論点として、ソリューション面での論点のほか、共用形態で必要な作業、課題、今後必要となる検討・検証等、サービス提供に関する論点に関して検討を行った。
A)分野横断的な 5G ソリューション検討のためのヒアリング
分野横断的に活用できる 5G ソリューションに必要となる観点について、5G ソリューションを実装していくために生じていく課題、それらを解決する手法について以下の２つの属性の事業体・企業からヒアリングを行った。
① 特定ユースケースでの社会実装を目指す段階の L5G ソリューション実証コンソーシアム② 既に社会実装されている事例を持ち、今後分野拡張が見込まれるサービスをもつ AI ベンダー
これらのヒアリング結果から 5G ソリューションを分野横断的に開発する要件として、以下が挙げられる。
（１） 機能要件に対する対策案
機能要件に対する対策案としては、・実運用開始までに膨大な AI の学習データが必要になる点-

AI での処理・解析を行う前に色調調整などの画像鮮明化処理を施す。

-

モデル構築の際に、学習データの収集・整理にかかる負担を軽減する仕組みを整える。

・天候、日照条件、デバイス毎の差異等の変化への柔軟な対応が必要である。
-

カメラの種類の選択・設置・調整を利用者にアドバイス/コンサルティングする。

-

あらゆるデバイスに対応できる接続モジュールとすることで、利用者の選択したデバイスによって使用不可となるケースを減らす。

があげられた。
（２） 非機能要件に対する共通の対策案
非機能要件に対する対策としては、ソリューションによらず共通的に解決すべき課題が多く、それら課題に対する対策案について、ヒアリングの結果から下表のとおりまとめた。
306

表 5.2.3-1 非機能要件に対する対策案（再掲）
大分類

課題

対策

信頼性・

L5G 無線区間のスルー ・無線区間を経由する場合は複数系統での冗長/バックアップを行

可用性

プットが安定しにく う。
い・アプリケーションによりデータ再送制御や欠損補完の品質制御機能を実装する。

セキュリ

機密情報の保全・セキュリティ認証を取得。

ティ性

第三者が写り込む可 ・利用者のセキュリティ性・可用性に関する要望に柔軟に対応す
能性のある場所での るために SaaS 型と DL 型の双方に対応。
運用の仕組み・セキュリティ要件の厳しい利用者の場合は学習モデルをエッジ側に構築可能とする。

性能・異なる現場環境（自然 ・AI での処理を行う前に色調調整の処理を通しておくことや、カ

拡張性

環境、デバイス、人の メラの選択、設置、調整の部分をコンサルすることで識別精度を判断基準）への柔軟な 安定させる工夫を行なう。
対応

・AI のモデル構築を行う際に、学習データ収集、整理にかかる利実運用開始までに膨 用者側の稼働負担を軽減するような仕組みを整える。
大な AI の学習データ ・あらゆるデバイスに対応可能な接続モジュールを設計する。
が必要
移行性

実運用開始までに膨 ・少ない学習データで効率良く検知精度を高められるベースモデ
大な AI の学習データ ルを構築することにより、新規利用者に導入する際の双方の稼働が必要

負担を抑える。

運用・現場での取り回しの ・ソリューションの構築、設定までベンダー側で行う（利用者が行保守性悪さ（現場に 5G の無 う場合は機能的なサポートを加える）
線技術を理解したエ ・運用部分もシステム的にカバーする（死活監視、モデルの識別精
ンジニアが必要）度監視）（３）費用対効果に対する課題への対応案
費用対効果に対する課題については、◇システム基盤の構築◇利用者側システム導入環境の構築◇運用保守サービスに大別される。詳細については、3.6.4 節でまとめているが、いずれの課題についても SaaS 型のような共用形態をとることにより、共通部分を持たせること、各事業者で独自に構築をするのではなく、共同の SaaS 基盤とすることで、ソリューションを構成するパーツレベルのアプリケー
ションを共同利用できる形にするなどの工夫で、大きく費用の圧縮が期待できることを確認した。

307

（４）その他ヒアリングに協力いただいた事業者からの普及展開への工夫
上述企業へのヒアリングを通して下表のような複数業界で共通して求められる要件の抽出を行なうことができた。

表 5.2.3-2 複数業界で共通して求められる要件（再掲）
大分類

要件

信頼性・ ・SLA の設定、公開
可用性・システム負荷に合わせたリソース調整の自動化
・いずれの業界でも SaaS を利用することは可能＜推奨要件＞
・利用者ごとに設定されている独自の社内規定に柔軟に対応するため、SaaS 型と合わせてDL 型での提供にも対応ができることが好ましい
セキュリ ・外部機関によるセキュリティ認証の取得
ティ・いずれの業界でも SaaS を利用することは可能＜推奨要件＞
・利用者ごとに設定されている独自の社内規定に柔軟に対応するため、SaaS 型と合わせて DL 型での提供にも対応ができることが好ましい
・セキュリティ要件の厳しい利用者にも対応可能とする場合には学習モデルをエッジ側にも構築可能とすることが好ましい
性能・・あらゆるデバイスに対応可能な入出力モジュールの構築

拡張性
・画像、位置情報、音声、テキスト等複数のデータ形式に対応可能な AI エンジンの実装
・説明書を読まずとも利用者が迷わないシンプルなユーザインターフェース
・利用者側で簡易に追加学習を行える仕組みの構築＜推奨要件＞
・学習データの収集・整理にかかる稼働を減らすための支援ツールの提供

308

・高解像度の俯瞰映像や、多視点映像を伝送する機能の構築
・高解像度の俯瞰映像や多視点映像に対する基本的な操作（ズーム、移動、巻き戻し）を行う機能の構築
・撮影時の外部環境による検知性能への影響を抑えるための画像鮮明化処理を加える機
能の構築
・Web ブラウザやメール、チャットアプリ等、利用者が使い慣れているアプリケーション
やデバイス上で動作する仕組み
移行性・SaaS 型でのサービス提供
・API の公開＜推奨要件＞
・少ない学習データで効率良く検知精度を高められるベースモデルの構築

運用・・遠隔地からの機器の死活監視や、トラブル発生時の問題箇所の切り分けを行う仕組み

保守性

の構築
・センシングデバイスの設置、設定までをベンダー側の専門家に委託可能な仕組みの提供

これらの対策や工夫を組み合わせることで、既存、あるいは新規に開発される 5G ソリューションを一業種・事業体向けソリューションとせず、共通機能や基盤を活用することで、多様な分野に横断したソリューションの横展開の実現が可能と考える。
B) システム全体の横展開に関する評価
本実証において、開発、実証実験を行った鉄道事業分野における、「鉄道車両監視 AI システム」において、確認された横展開における観点について以下にまとめる。
（１）汎用化作業により整理されたアーキテクチャの評価
SaaS 型共用を進める上での汎用化作業に基づいて構成されたシステムで実施した実証実験により、事業化を検討する際には、可用性のポイントにおいて、リソース管理やモニタリングなどのアーキテクチャの見直しが発生すること確認された。
（２）分野横断的に活用できる 5G ソリューションに必要要件に基づく評価
分野横断的に活用できる 5G ソリューションの必要要件表を本ユースケースに当てはめて評価を行った。
・外部システムとの連携として API や他アプリケーションとの接続インターフェースをもたせるべき。
309

・実運用を考慮すると、継続的に開発やメンテナンスを行うための開発環境を設置することを考慮する必要がある。
など、現状のシステム共用形態では未検討・未検証な点が確認された。
これらの評価による観点は今後の事業化に当たって考慮していく必要のある点である。
とはいえ、当初からすべてを組み込むことを進めるのではなく、コアとなるアプリケーションの開発を軸として、拡張する機能やそれに付随して必要となる共用形態として必要となる機能をつ
ど検討を行い事業規模、利用者数などビジネス面の判断をもって開発計画を立てることが望ましい。
Ｃ）サービス提供上の分界点
共用形態を提供するうえで、当初想定した利用者においての導入負担を軽減する効果としてコスト削減効果については確認することができた。
この場合、サービス提供分界点はクラウド上のアプリケーションを提供者にて提供を行い、現地のデバイス準備やシステムの業務運用については利用者において担当をすることを想定した。
一方で、分野横断的なソリューションにおけるヒアリングを行った結果では、分界点の考え方は、導入時や、運用フェーズにおいてクラウド上のアプリケーションのみではなく、システム導入のコンサルティング支援における立ち上げの支援、導入時の現地環境の構築支援・人材トレーニング
支援、運用後のシステムの運用保守のアウトソージングのサービスを提供されているケースもあった。
SaaS としての提供範囲を設定するとともに、ソリューション自体の導入～運用までの各フェーズが滞りなく進めることができるように、導入を進める際には実行体制の検討および、システムの運用を想定した場合に不足となる部分についての解消手段についてもコストとして想定し、全体のビジネスモデルを規定することが求められる。

310

5G ソリューションの横展開「鉄道業界に向けた取り組み」
鉄道業界における 5G ソリューションの横展開の議論は、令和 2 年度 L5G 実証時から 3 か年にわたり実施しており、すでに令和 2 年度 L5G 実証及び令和 3 年度 5GSC 事業に参画していただいた鉄道事業者を含む複数の鉄道事業者（私鉄 5 社）を交え、それぞれの実証事業において得られた知見や明らかになった課題を踏まえた議論の場を形成している点で、他業界に先駆けた取り組みを実施しているといえる。
昨年度 5GSC 事業実施時に開催した鉄道協議会では、鉄道事業者の抱える課題が相当程度共通のものであること、列車検査システムをはじめとする鉄道事業者が共同で利用できるソリューションを開発することへの需要を確認した。そこで、今年度は過年度より参加いただいている鉄道事業者に加え、新たな事業者にも参加を呼びかけることにより、より多くの事業者（今年度は私鉄 10 社）を交えて幅広い意見交換を行うこと、また、鉄道協議会を 4 回開催することにより、より深堀した議論を実施す
ることを目指した。さらに、鉄道協議会参加の複数の鉄道事業者に鉄道協議会開催に先立ちヒアリン
グを実施し、鉄道協議会で検討するテーマとなる鉄道事業者に共通する課題をある程度絞り込むことにより、鉄道協議会で活発な議論が行われることを目指した。
本年度の鉄道協議会の開催目的等を踏まえた、活動結果のまとめを以下に示す。

鉄道車両監視 AI システムの共用化実現に向けた具体的方策
鉄道車両監視 AI システムに関しては、検知対象範囲を台車周りだけではなく、現状の列車検査
項目のうち、主に目視による検査項目を対象に範囲を拡大させていくことに対して、鉄道事業者
から以下の期待が示された。
・将来の人手不足への対策として、画像・AI を活用することで、各検査項目の作業の効率化、省人化・省力化とともに、人による列車検査周期の延長の可能性がある。
・高所作業の削減は、安全性の確保および職場改善となることから、離職率低下に繋がる可能性がある。
・AI モデルを汎用化し、シェアすることでコストダウンが図れる。
・共同開発することで、1 社で行うことより早く実現できる可能性がある、他社の知見・ノウ
ハウを得ながら進められる、複数事業者のデータを基により安全性が担保できれば社内での意思決定も図りやすくなる。
・検知する対象及び特徴によって詳細な部分は異なることが考えられるが、共通化が図れる部
分については最大限に共通化し、それに個社最適が必要な部分は追加することによって、システム全体としてのトータルコストを抑えるシステムにできる可能性がある。
一方、この鉄道車両監視 AI システムの共用化を実現するにあたっては、鉄道事業者から以下の課題・懸念事項が示された。
・パンタグラフのすり板の素材や台車の型式・構造などは多種類あることから、多種類ある検査対象物に対して検知精度を確保するシステムとする必要がある。
・部品交換など画像・AI による代替ができない作業もあることから、システムを導入すること311

による作業の効率化、検査の省力化・省人化に対してはより具体的な、もしくは定量的な効果を把握することが重要である。
・実運用へ円滑に移行するためには、開発段階から現場との協働が大切である。
・システム導入後のアップデート（検知対象物の拡大など）を事業者で実施できるとより有効なシステムとなる。
・検査対象物によって検出率・網羅率が異なるため、対象物によってはシステムによる検査・
異常検知が難しい可能性がある。
以上のことを踏まえて、鉄道車両監視 AI システムの共用化実現に向けた今後の検討課題を以下に示す。
・鉄道事業者が導入の意思決定をするためには、コスト面での効果（省力化・省人化・作業の効率化）を定量的に把握し、費用対効果を示すことが必要
・定量的な効果の把握、検査対象物の拡大を図るためには、鉄道事業者との意見・交換を継続して、実態把握・検討の深度化が必要
・長期的な観点での検知精度向上及び汎用性の確認のため、単独モデル・混濁モデルの比較検討の深度化が必要
・低コストでの共通ソリューション化、モデルの最適化を図るため、AI 画像解析の共通部の最大化や、共通部・個別最適部の差別化に係る検討の深度化が必要

312

鉄道事業者の鉄道 DX に係るニーズの把握、共通ニーズの発掘
本年度の鉄道協議会は、約４カ月間で計４回の開催であったことから、複数の鉄道事業者の共通ニーズのうち、車載モニタリングシステム、列車検査システムの発展形、列車見張員支援シス
テムの３つを深度化テーマとして選定し、ソリューションの共用化等について議論した。
一方で、鉄道事業者の鉄道 DX に係るニーズは、深度化テーマだけではなく、多岐の分野にわたって複数の共通ニーズがあることを把握できた。
具体的に、共通ニーズとして考えられる項目は以下のとおりである。
■土木分野➤構造物（橋りょう、トンネル）の点検におけるドローンの活用■軌道分野➤軌道巡視（バラスト劣化・振動など）に対するドローンの活用➤車載カメラ映像による軌道巡視の前方監視➤保守作業時の列車接近情報の把握■車両分野➤車両検査のデジタル化➤列車検査の画像、映像による AI の異常判定➤パンタグラフのすり板摩耗の検知➤異音検知➤車両モニタリングデータの取得（常時監視）➤カメラによる車内監視■駅務分野➤白杖者・車いす利用者の捕捉➤軌道転落者の検知■電気分野➤電車線点検業務に対するドローン・車載カメラの活用➤鋼索線の無人運転化（車掌の無人化）➤踏切内の立ち入り監視■その他➤新入社員の確保による人材確保
これらの共通ニーズについては、鉄道事業者の現状の取組みや既往技術などを踏まえながら、
課題解決に資するソリューションシステムとしての共用化を検討することが考えられる。特に、土木構造物の点検に関しては、事業者によって点検項目等に大きな差異がないと想定されることから、共通ソリューション化を図ることで、より汎用性の高いシステムにできる可能性があるとともに、より多くの鉄道事業者にとってメリットがあると考えられる。

313

鉄道事業者の共通ニーズの解決に資するソリューションシステムのイメージ具
体化
鉄道車両監視 AI システム（列車検査システムの発展形）以外の鉄道事業者の共通ニーズの解決に資するソリューションシステムについては、複数の鉄道事業者から興味が示され、共通ニーズとして考えられたことやソリューションシステムの開発や実証試験が既に進んでおり、その目的・技術的な内容が明確であったことから、車載モニタリングシステム（軌道巡視システム）と列車見張員支援システムの２つを本年度の協議会では選定した。
車載モニタリングシステムについては、自社路線でのデータ取得による AI モデル構築及び自社路線での実証試験から、他事業者の路線での実証試験、他事業者でのデータを取り込んだ AI モデ
ル構築（混濁モデル）及び自社路線での実証試験、混濁モデルを活用した他事業者の路線での実証試験と、段階的なモデル構築・実証試験を通じて、同システムの実運用を目指す方向性が示された。また、他事業者への導入型式としては、導入後のシステム更新等を考慮して、買い切り型ではなく、サブスクリプション型が望ましいとの見解が多数の事業者から示された。サブスクリ
プション型を想定した場合の価格設定に対しては、事業者によって路線環境・利用環境（路線延長、設備数、検知対象物など）が異なることから、これらの環境及び AI やクラウドサーバ等の利用状況に応じて価格設定することや、システム内の個別機能ごとに価格設定することなどの意見があった。
列車見張員支援システムについては、開発事業者の路線環境や低コストでの導入ニーズにより、簡易なシステム構成となっており、複々線区間での列車検知が想定されていないことなど、開発事業者による他事業者への横展開は検討されているものの、他事業者への汎用性には課題がある
ことを確認した。
また、上記のソリューションシステム以外にも、土木構造物の点検へのドローンの活用やホー
ム上・踏切での安全対策への AI 検知の活用などが共通ニーズとして考えられるとの鉄道事業者からの意見があった。
以上のことを踏まえて、車載モニタリングシステム及び列車見張員支援システムに関しては、
今後も協議会を活用して鉄道事業者間の情報共有を図り、複数事業者への横展開の取組みを促進
するとともに、その他のテーマについても、より具体的な実態・ニーズの把握に努め、共有化を見据えたソリューションシステムの具体化を進めることが考えられる。

鉄道協議会の継続開催について
本年度の協議会では、過年度から参画事業者数を増やすことで、鉄道事業者が抱える様々な課
題やニーズを把握することができたとともに、他事業者の課題・ニーズや DX に係る取組みの現状を共有できたことに対して鉄道事業者から好意的な意見が多数あり、鉄道協議会が情報提供・共有の場として意義・必要性があることを確認した。
また、事業者が単独でソリューションシステムを開発・導入することのハードルは高いが、他の事業者と協力することで、これらのハードルが下がるとの意見や、これらの取組みを進める上314

で協議会のような場の提供への期待が鉄道事業者から示された。
このことから、本年度の鉄道協議会は、次年度以降も継続して開催することとし、引き続き、共通ニーズの発掘や共通ソリューション化を見据えたソリューションシステムのイメージの具体化並びに複数の鉄道事業者で協働するスキーム等の検討を進めることで合意した。
冒頭で記したように、鉄道業界における 5G ソリューションの横展開の議論は、令和 2 年度 L5G
実証時から 3 か年にわたり実施しており、すでに令和 2 年度 L5G 実証及び令和 3 年度 5GSC 事業に参画していただいた鉄道事業者を含む複数の鉄道事業者を交え、それぞれの実証事業において得られた知見や明らかになった課題を踏まえた議論の場を形成し、それを今年度事業においてさらに拡大、深化させている点で、他業界に先駆けているとはいえ、鉄道業界に共通したニーズに対応した共用形態の 5G ソリューションを共同開発、共同利用していくフェーズに持って行くま
でには様々な課題を解決していく必要が確認された。
しかし、3 ヵ年にわたる鉄道協議会での議論を通じ、それに向けたステップは明確になってきており、次年度以降も鉄道協議会を継続開催し、共同開発、共同利用を目指すテーマを絞り込み、その実現に必要なシステムを設計するとともに、必要な応募可能な実証事業への参画及び応募可
能な補助などの活用により、そのテーマに関するソリューションを実現することが可能となる。
まず、鉄道業界に共通する１つのテーマに関する共同開発。共同利用の成功モデルを作り、それを積み重ねるとともに、鉄道業界以外の業界にもそのノウハウを横展開することで、5G ソリュー
ションの分野横断的な普及に貢献できるものと考えている。

315