令和の鉄道を安全に走させるためには不可欠なIoTの技術であるMQTTについて、初心者の方にもやさしく解説していきます！
※本ページはプロモーション（広告）が含まれています。
はじめに
今回は、令和の現代の鉄道が安全に異常な・事故もなく走るために欠かせない通信規格の一つであるMQTT（Message Queuing Telemetry Transport）について語っていきます！
通信技術に関する話ではありますが、なるべくITのマニアックな技術知識とかではなく、あくまで一般論に基づいて解説するので、どうぞ最後までご覧ください！
そもそもMQTTとは？
軽すぎる通信規格・MQTT
MQTT（Message Queuing Telemetry Transport）とは、たとえ険しい山岳地帯などに代表される少ない電力や低い通信速度であっても、何食わぬ顔で効率よくメッセージをやり取りすることができるという、まさにザ・令和な通信規格のことをいいます。
ちなみにテレメトリー（Telemetry）とは聞きなれない言葉かも知れませんが、ここでは「遠隔で異常がないかを測定すること」と思ってもらって結構です。
MQTTが、鉄道の「過酷な環境」にとても強い理由
従来に比べ、データが圧倒的に「軽い」
MQTTでは、これまでの通信規格に比べて非常にデータが小さく、例えば
- 険しい山間部だったり、
- 長いトンネルだったり、
- 降雨や深い雪に包まれているような豪雪地帯だったり…
としても、鉄道車両との通信がスムーズにすることが可能になりました。
すなわち、たとえ吹雪や大雨に見舞われて電波が弱まってしまい、通信速度が極端に落ちてしまった場所でも、MQTTではそもそものデータが小さくてスリムなので、過酷な環境の通信でも「スッ」と通り抜けることができます！
ネットワーク断絶に強い 「電波切れ」をそもそもの前提とした、賢い仕組み
例え鉄道車両がトンネルの中に入って電波が切れるのは、もはや仕方ありません。
すなわち、
- 「（電波を）切れないようにする」のではなく、
- 「たとえ切れた時でも、問題なく通信できるようにする」
という、逆転の発想から来ています。
そのため、MQTTではたとえトンネルで電波が切れたととしても、再接続が非常にスムーズにできます。
従来、トンネルの中などで電波がプツプツ切れるのは、鉄道にとって一番の悩みでした。
しかしMQTTには、それを克服するためのQoSという機能があります。
ちなみにQoS（Quality of Service）とは、通信の確実性を保証する仕組みのことをいいます。
詳しくはここでは知る必要はありませんが（それは高度なエンジニアさんたちの仕事なので…）、MQTTのQoSについては後半で少し簡単に紹介したいと思います。
リアルタイム性が高い
情報の遅延が少ないので、今の電車がどこにいるかの位置を正確に把握できます。
つまり、
- 険しい山間部における、万一土砂崩れが起きたときの検知
- 長いトンネル内における、車両の状態の把握
- 豪雪地帯における、踏切動作の監視
これらがすべて、リアルタイムでスムーズに行えるようになったのは、このMQTTという「軽くて粘り強い」技術のおかげなんですね。
すなわち、これまでの常識では「繋がらなくて当たり前」だったような過酷な環境にあった場所が、ITの力で「安全が保証される場所」に変わっていくというのは、技術の進歩を感じて本当に素晴らしいことですね！
【広告】
鉄道ファンの方におすすめ！たくさんの種類の鉄道車両が数多く網羅されています！
鉄道メンテナンスの進化：職人からデータへ
昔は「職人の五感」がすべてだった
また、MQTTが使われるようになった背景には、
というものがあります。
というのも、かつてはベテランの職人さんたちが、まさに「手探り」で異常を見抜いていました。
- 音で聴いて調べる：走行中の音のわずかな変化を聞き分ける。
- 熱を感じて察知する：軸受（車輪の回転部）を手で触れたり、匂いを嗅いだりして温度上昇を察知する。
- 目で見て確認する：小さなひび割れや、ボルトのわずかな緩みを、自らの経験によって見つけ出す。
これらはもちろん、その人の長年の経験値や苦労の積み重ねがもたらしてきた素晴らしい技術でした。
しかし、個人の経験値に頼るため、どうしても技術の継承が難しかったり、見落としのリスクがあったりしました。
「失敗が許されない世界」への変化
このように、昔は職人たちの手によって手探りで、職人の経験値によって故障や温度の上昇などを判断していた時がありました。
しかし、現在では「故障する前に治す」ことが必須になったからです。
MQTTが使われるようになったのは、それまでは「職人の勘」に頼っていた部分を「デジタルな目」に置き換え、24時間365日、休むことなく車両の健康状態を監視・測定するためなのです。
ベテランの経験をデータ化し、誰でも高い精度で安全を守れるようにした、というわけですね！
かつての職人技が、今は目に見えない電波（データ）となって空を飛び交っていると思うと、技術の進歩に胸が熱くなりますね。
過酷な環境と「モノ」のIT化（IoT）
従来のHTTPでは太刀打ちできない理由 鉄道路線の過酷な環境
鉄道は山間部を走るなどの過酷な環境にあり、 これまでのHTTPのような重いプロトコル（通信規格）では全く太刀打ちできなくなりました。
というのも、山間部や豪雪地帯などといった過酷な環境を走る鉄道にとって、これまで主流だったHTTPは、過酷な環境で通信するには少しサイズが大きすぎて「お固い」「効率の悪い」通信方式だったのです。
HTTP：Webサイトを見る時などに使われる通信のルールのこと。
「ブラウザからWebを閲覧する」といった1対1のやり取りには強いですが、不安定な場所で大量のデータを送るのには不向きです。
「モノ」が主役のインターネット（IoT）へ
昔は、そもそも「物が ITに繋がる」なんてことは考えられませんでした。
しかし、 現在ではITが進歩してゆき、単なるパソコンやルーターやサーバーなどといった機械ではなく、モノまでが IT に繋がるIoT（Internet of Things）というようになったことが、MQTTが普及するようになった 要因です。
それは主に工場の機械などはもちろん、鉄道が走るモーターや踏切などもそうです。
【広告】
新幹線車両について、とてもイメージしやすく解説・紹介されたわかりやすい本です！
鉄道や乗り物の事故を防ぐ「自動的な守り」
踏切や線路の異常と列車の連動
例えば、線路の踏切で、遮断機の降りる速度や、警告灯の電球が切れていないかについてを、遠隔でチェックします。
すなわち、わざわざ点検員さんが現地に行かなくても、事務所で「異常なし！」と確認できるようになったというわけですね。
踏切の異常検知
こうした技術があることによって、例えば
- 踏切が故障したり、
- 線路に人が入ったり、
- 踏切内で車が立ち往生したり、
などといったアクシデントが起きた場合にしても、事故が起こる前に踏切に電車が入ることがなく、事前に列車が止まるようになりました。
こうして踏切において障害物検知装置が作動したりすると、その情報が瞬時にネットワークを飛び交い、保守員の方々が瞬時にそれを察知して、現場へと駆けつけることができるようになります。
自動車や飛行機での活用
また、こうした技術は自動車や飛行機にも組み込まれており、事前に異常を察知して、事故を防いだりします。
自動車の場合（安全への応用）
自動車の場合は、ブレーキの摩耗・タイヤの空気圧・エンジンの振動などをMQTTなどを使って常に監視しています。
つまり大きな故障につながる前に「点検に来てください！」と通知が来るのは、車が常に「自ら」データを送っているからですね！
飛行機の場合（安全への応用）
また、飛行機の場合は、飛行中のエンジンデータなどは、衛星通信などを介して、地上へとリアルタイムで送られています。
そして飛行機が着陸してくる頃には、なんと既に地上の整備士が「どの部品を交換すべきか」をとっくに把握しているという、なんとも驚きのスピード感で動いているわけです。
コマツ（小松製作所）の「KOMTRAX」
また、石川県小松市に本社を置く株式会社小松製作所（コマツ）で使われている、例えばパーショベルのような重機も、多くの場合は険しい山岳地帯といった過酷な環境で作業することになります。
そのため、会社にある監視拠点のサーバに対して、保守員の皆さんがすぐに見られるように、即座に重機の「異常」「故障」などのデータを送るようになっています。
すると、保守員の方々がそれを見て、現場へといち早く駆けつけることができるようになるわけです。
そんな建設現場で働く機械たちの状態を、遠く離れた場所からでも把握できるという画期的なシステムが、小松製作所の「KOMTRAX」ということになります。
山間部の工事現場でも軽快に動くMQTTの応用
このように、MQTTの普及は、山間部という過酷な環境などにおいて通信が途切れやすい・遅くなりやすいう従来の「通信の弱点」を克服し、これまでは沈黙するしかなかった「現場のモノ」たちの声を聞き取れるようになったからだと言えます。
すなわち、従来はベテラン職人が現場を歩いて回っていた仕事を、デジタルの網が24時間体制で代行しているというようなイメージですね！
現場の過酷さと、最新のIT技術の融合。
このギャップを埋める技術がMQTTなんだと思うと、すごく合理的でかっこいい仕組みだと思いませんか？
【広告】
経済学について、基本から丁寧にわかりやすく解説された本です！
現代特有の「失敗が許されない」背景
ここまでして徹底的に事前に故障を検知したり、
- 故障してからでは遅い
- 故障する前には治す
といった考え方が浸透したのには、令和特有の現代において、
- 例え何かあるとすぐにSNSなどで炎上したり、
- 社会的な大ニュース・重大な責任を負わされるような、時代背景や風潮になった
といったことも考えられます。
「炎上」と「ブランド失墜」のリスク 情報の拡散スピード
今の時代、何かトラブルがあれば、その瞬間にSNSで拡散されてしまいます。
例えば、踏切の故障や電車の立ち往生が発生すると、数分後には動画や写真が世界中に広まってしまいます。
そうなってしまうと、
- 「なぜ未然に防げなかったのか」
- 「管理体制はどうなっているんだ」
という厳しい声が、企業に直接届くようになりました。
「壊れてから直す」では遅いという風潮の世の中に
鉄道会社や、コマツのような重機メーカー、さらには自動車メーカーにとって、「壊れてから直す」という姿勢は、今や「社会的責任を果たしていない」とみなされる風潮になったのです。
そのため、MQTTのようなテレメトリー（測定）技術を使って、世間に対して「常にきちんと監視しています」というような姿勢を見せる・アピールすることで、利用者の皆さんにも安心感を与えられ、企業を守るための武器にもなるというわけです。
MQTTについてもう少し具体的に
MQTTは、従来までは無かったパブリッシュ・サブスクライブ（Publish╱Subscribe）型という、珍しいタイプの通信方式を取っています。
出版社・漫画家・読者の「定期購読」の関係に例えるとわかりやすい（MQTT）
こう聞くとちょっと難しいですが、これは出版社と漫画家と我々読者の関係に置き換えると分かりやすいです。
- まず、読者であるA君が、とある超人気漫画家Aさんが書いた面白すぎる漫画を、
- 定期的に、1年間12ヶ月の定期購読をするとします。
- この時、読者のA君は、その漫画を読んでないと「時代遅れだ」って周りの友だちからバカにされることになってしまいます。
- そのため、A君はその漫画を一回たりとも読み逃すわけにはいきません。（←これMQTTでは重要）
- つまり、「何がなんでも1年間（12ヶ月）分の漫画読みたいです」って、出版社に対してアピールしかなくなります。
- つまり、定期購読を申し込むわけです。
- しかし漫画家の皆さんは、A君をはじめ、我々読者の存在を知りません（ていうか、知る必要性すらありません）。
- 漫画家の人たちは、我々何百万人いるかわからない読者に対して、いちいち漫画を自宅まで直接送ってくれるわけではありません。そんなことしたら、漫画家の負担が膨大になります。
- そこで、漫画家Aさんが締め切りまでに書き上げた超面白い漫画は、読者ではなく出版社に対して送られるわけです。
- その他の漫画家Bさん・漫画家Cさん・漫画家Dさんも、みんなそれぞれ出版社に対して、自分が書き上げた漫画を送ります。
- この時、漫画家たちから送られてきた漫画を受け取った出版社は、あらかじめ定期購読を申し込んでくれていたA君らそれぞれの読者の自宅に対して、マンガを送り届けるわけです。
- A君は無事に安定して今月号の漫画を受け取って読むことができ、読んでないことで友人からバカにされるという異常事態を回避することができるわけです。
ここまでの漫画の流れを、MQTTでの通信に置き換えてみる
そして、ここまでの漫画における一連の流れを、MQTTでの通信に置き換えてみると、以下のようになります。
- 漫画家が出版社に送る→Publish
- 読者A君が定期購読する→Subscribe
- このときの出版社の役割→MQTTブローカー
となります。それぞれ詳しくみていきましょう。
Publish：出版する
Subscribe：購読する
漫画家が出版社に送る→Publish
つまり、この時の漫画家が出版社に送ることを、MQTTの世界ではPublish（パブリッシュ）といいます。
鉄道の世界では、車両（漫画家）が「今のモーターの温度は80度です！」という情報を出し（原稿を書き上げ）、ブローカー（出版社）へと送るという行為を指します。
読者A君が定期購読する→Subscribe
また、この時の読者A君が、出版社から定期的に必要な情報 （つまり、絶対に読み逃してはいけない漫画）を定期購読することを、MQTTの世界ではSubscribe（サブスクライブ）と言います。
すなわち、現場に置き換えると、保守担当者（読者）が、
- 「特定の車両（漫画家）の故障情報という作品が届いたら、すぐに私に転送して！」
と、ブローカー（出版社）に対して予約しておくことですね。
出版社→MQTTブローカー（仲介人）
また、この時の出版社は、読者と漫画家の間に存在するという「仲介者」のような立ち位置になってます。
この時の出版社の役割を、MQTTの世界ではブローカーと言います。
ブローカー（Broker）は「仲介人」という意味です。
すなわち、漫画家と読者がそれぞれ直接会う（通信する）という必要がないように、真ん中に立って情報を整理し、それぞれ配布していくような役割を果たしています。
MQTTではこれにより、何万台という鉄道車両（漫画家）がいても、システムがパンクせずに済むのです。
「絶対に取り逃さない」ための定期購読
さらにこの時、A君のように「月ごとに個別に買って読む」のではなく、わざわざ一年間まとめて定期購読する人がいるのは、
- 「絶対に読み逃してはいけない」
- 「読み逃したら、周りの友だちから馬鹿にされる」
という読者にとってはクリティカルな、危機的な状況にあるからです。
つまり これはA 君にとっては（読んでないことで）「友達に馬鹿にされる」「友人の輪に入れなくなる」ことを意味しており、屈辱的であってはならないことです。
月々の購入（定期的な点検）だと「取り逃し」のリスク
もし月々に買って読むと、もし人気漫画の場合、売り切れになる可能性もあります。
鉄道や自動車や飛行機などにおいても、設備から必要な情報を確実にしっかりと受け取ってないと、発見が遅れてしまうことになります。
当然それは故障の原因になってしまい、後に取り返しのつかないことになります。
それも絶対に避けなければならないのと同じです。
プッシュ型のMQTTなら、情報の取り逃しが無くなる
保守員のみなさんがわざわざ自分で情報を取りに行かなくても（つまりPullしなくても）、定期的に送られてくる（サブスクライブされる・Pushされる）ため、情報の「取り逃し（漫画の読み逃し）」もなくなるわけです。
そのためMQTTはプッシュ型の通信とも言われてます。
それまでは「自分から情報を取りに行く」つまり「引き出す（Pull╱プルする）ことしなきゃいけなかったため、プル型の通信とも言いました。
MQTTのQoS（品質保証レベル）
MQTTの世界では、一歩間違えればクリティカルになりかねないメッセージの数々を、冒頭にも少し話したQoS（Quality of Service）でコントロールしていくことになります。
すなわち、以下のようなクリティカルな事象を回避するために、QoSは必要になるというわけです。
- 読者にとっての危機：「最新話を知らないと友達に置いていかれる（＝情報の欠落による不利益）」
- 鉄道業界にとっての危機：「ブレーキの摩耗データが届かない（＝重大な事故や故障の見逃し）」
3段階に分かれている、MQTTのQoSレベル
またMQTTのQoS（品質保証レベル）は、状況に応じて3段階に分かれています。
- QoS レベル0：何度送ってもいい、そこまで重要でない情報に対して設定しまです。例えば、通常時のモーターの温度などが挙げられます。
- QoS レベル1：最低1回は必ず送ることを保証させたい、ややクリティカルな場合に使います。また、2度送っても（重複しても）そこまで危機にはならない情報に対して使われます。例えば、モーターの温度異常などが挙げられます。
- QoS レベル2：1度受け取ったことを確信したら、2回以上はもう送ってはいけない（重複してはいけない）ような、最重要情報に使われます。例えば、100万円の入金処理やモーターの停止命令などが挙げられます。
そしてMQTTでは、QoSメッセージの種類（というか重要性）によって使い分けなければいけないことになります。
QoS レベル0 あまり重要でない日頃のデータを定期的に送る通信
まずQoS レベル0は、どんな場合に使うのかを考えていきましょう。
例えば、平常時のモーターの温度などであれば、そこまでクリティカルで重要な情報ではありません（もちろん必要な情報ではありますが）。
すなわち、こうしたそこまで重要ではない定期的な情報に対しては、もっともレベルの低いQoS レベル0が設定されます。
QoS レベル1 重複OKな「最低1回保証」通信
次にQoS レベル1は、どんな場合に使うのかを考えていきましょう。
例えばモーターの故障といった情報は、最低でも必ず1回は絶対に届かないといけません。
こういう場合には、このQoS レベル1が設定されます。
また、このモーターの故障といった情報は、たとえ重複して何度たくさん同時に届いてたとしても、そこまで問題にはならないわけです。
むしろこの場合は、重複して2回以上届くことよりも、全く届かないことの方が問題です。
つまり、たとえ2回重複して届いたとしても、保守員の人々からすれば
- 「あ、また異常の通知が来たな（それはもう知ってるよ）」
といった程度のことで済みますよね。
QoS レベル2（重複不可な超重要通信）
そしてQoS レベル2は、どんな場合に使うのかを考えていきましょう。
こちらはメッセージが重複して何度も同じ情報が届いたらまずい、クリティカルな情報に対して使うQoSレベルです。
- 「100万円の入金」が誤って2回行われて、200万円の入金になる
- もし停止指令が誤って2回実行されて、システムが「停止」と「再停止」で混乱する
- A君のもとに、同じ月号の漫画が2冊届く
っていうことになったら大変です！
漫画のケースでは、QoS レベル1で何度も再送されると重複して「マズい」
まずQoS レベル1（最低1回は届ける）に設定してしまうと、出版社はA君から「届いたという返事」が来るまで、何度でも漫画を送り直します。
また、仮にA君が返事のハガキを送ったとしても、郵便の「手違い」や「天災」などの予期せぬ事象によって届かなかった場合、出版社は「まだ届いていないんだ！」と勘違いして、同じ漫画をもう1冊送ってしまうのです。
通信の世界で「返信」「確認」が絶対に必要な理由
通信の世界において、「沈黙」は「切断」を意味する
届いたかどうかの「確信」→「再送」の判断
- 例えばトンネルや吹雪の影響で消えてしまったのか、
- ちゃんと保守員に届いたのか、
つまり、
- 「届いたよ！」という確実な返事が来ない場合、
- MQTTの通信システムでは「途中で何かトラブルがあった」というふうに（良くも悪くも）判断して、
- （良くも悪くも）もう一度送り直す
通信の世界では「返信」「確認」「再送」などのジャッジが重要になる
すなわち、
- 現実世界（漫画のケースなど）：届かなければ「まあいいか」程度の話で済む。
- MQTTの世界：届いたことを「返信」でお互いに証明し合わない限り、次の仕事に進めない。
- 険しい山の中を走る新幹線
- 過酷な環境で動く、コマツの重機
- 自動車、航空機
- 工場の機械
おわりに・まとめ
MQTTが令和の鉄道にもたらした最大の功績は、一言で言えば
- 『見えないリスク』を、『見える安心』に変えたこと
にあります。
すなわち、かつては職人の勘・経験や定期的な点検でしか把握できなかった鉄道の「健康状態」を、MQTTがデジタルな神経網としてつないだことで、安全性は異次元のレベルへと引き上げられました。
すなわち、
- 職人の技をデータで支え、
- 過酷な環境を「データの軽さ」で克服し、
- SNS時代の高い要求に対して、確実な安全で応える。
この技術があったからこそ、私たちは今日もしがない日常の中で、当たり前のように安全に目的地へ向かうことができているのですね！
これまでお話ししてきたMQTTの技術が、まさにこの「日本の安全」という巨大なパズルを完成させていると思うと、感慨深いものがありますよね。
コメント