東京の原宿駅。2020年に供用開始された新駅舎の入り口。晴天に恵まれたせいもあるが、表参道や竹下通りは多数の外国人観光客で賑わっていた JR東日本が2023年5月27日以降に順次「センターサーバー方式を採用した新しいSuica改札システム」を導入するのに際し、前回の記事で「SuicaのID化」についてまとめた。同記事は別誌に筆者が寄稿した「なぜ? 『Suica』がサーバ型に移行する理由 25年近く稼働する“安全神話”の象徴に何が」で書き切れなかった部分を補足したものだが、読者からの質問や筆者が何度か読み返してみて疑問に思った部分をJR東日本に対して質問状として投げかけてみた。
先方からは非常に丁寧に回答をいただくなかで、筆者が分からなかった部分や勘違いしていた部分もある程度クリアになったため、2回連続で同じネタにはなるが、「次期Suica」の実際についてまとめてみたい。
改札は新しくなっても「Suica」の仕組みはそのまま
前回の記事では「SuicaのID化」としていたので、「Suicaというカードがまったく別物に変わる」と誤解を与えてしまった方もいるかもしれない。ただ、JR東日本だけでなく日本全国で相互乗り入れを行なっている他の交通事業者や交通系ICカードが今後も利用でき、その互換性を保つため、Suicaのカードはそのままに「改札機にのみ変更を加える」というのが今回の対応だ。
センターサーバー方式は、運賃計算などの処理をセンターサーバ―で行なうものとなります。Suicaへの読み込み・書き込みは改札機で実施しています。(JR東日本広報)
つまり、従来Suicaの読み書きや運賃計算をすべて改札機のローカル処理でまかなっていたが、運賃計算のみをサーバー側に移管したというのが新システムの仕組みとなる。
「センターサーバー方式を採用した新しいSuica改札システム」の概念図(出典：JR東日本) ここで気になるのは「コスト」の話だ。電子マネーの決済の世界では、決済端末の処理負荷を軽減して端末自体のコストを削減するために、FeliCaの通信で発生する暗号化処理をクラウド上のサーバーに任せてしまい、決済端末は暗号化状態のデータをパススルーする仕組みが存在する。
それが先日Suicaでの決済トラブルを起こしたJ-Mupsなどでも利用されている仕組みだが、「処理に多少時間がかかってもいいから決済端末導入コストを安く仕上げたい」というニーズに応えて自販機や店舗での電子マネー決済でよく採用されている。
もし、今回導入されたSuicaのセンターサーバー方式が「コスト削減」を主眼に置いたものなら、機能的には従来の改札機の機能をそのまま包含する新システムは「それほどコスト削減効果につながらない」ことになる。これは、新システムの障害時の対応としてJR東日本が「一時的にセンターサーバ方式から従来のローカル処理方式に切り替えることも可能」とJ-Castが報じていたことが気になって筆者も質問してみたものだが、次のような回答が戻ってきた。
「センターサーバー方式」の導入により自動改札機のIC処理機能は軽くなりますが、一方で、自動改札機にはICカードの処理のほかに、磁気乗車券の処理やお客さまへのご案内機能など様々な機能があるため、現時点におけるコスト効果は限定的になります。
今後サービス開始を予定しているQR乗車券サービスなどの活用も踏まえて、将来的には、更に改札機の処理を削減するなどし、コスト低減に取り組みたいと考えています。(JR東日本広報)
将来的には分からないものの、少なくとも移行期間を含めてしばらくはローカル処理も可能なセンターサーバー方式対応の改札機が残るということになる。
ただ、今回の新システムで大きなコスト削減効果が期待できる部分がある。それが「ソフトウェア改修時の作業」だ。
本システムの導入により、新サービス開始時に必要となるソフトウェア改修作業は効率的になります。また、本年5月27日に「Suica」を使った出改札サービスを開始する北東北3エリアに導入する改札機は、本年夏以降に首都圏・仙台・新潟エリアに順次導入を予定している新型自動改札機と同じ機種となります。(JR東日本広報)
センターサーバー方式の導入で新型自動改札機へのリプレイスが完了することで、従来までであれば作業員が対象駅の改札を走り回って行なっていたソフトウェアアップデートや改修作業が、センターサーバーへの集中化により一気に軽減されることになる。
みんなが気にする「処理速度」は“ほぼそのまま”
Suicaの特徴といえばお馴染みの「200ミリ秒」での高速処理だが、これにまつわる処理のトリックは以前の記事でも触れた通りだ。
今回センターサーバー方式へと移行することで、Suicaの処理は改札機内でのローカルで完結するものから、いったんセンターサーバーへの問い合わせが発生するため、どうしても通信の往復時間(RTT：Round Trip Time)が発生する。詳細は公開されていないが、JR東日本は自前の通信網を抱えており、一般的なインターネット通信に比べるとはるかに高速で短いRTTを実現できると考えられるが限界はある。
それでも「200ミリ秒」の処理時間を維持することは可能なのか?
現行の改札機では処理能力に限界があり、複雑な利用パターンなどを計算する場合に時間を要している現状があります。センターサーバー方式では、高速なサーバーを導入することで、運賃計算などの処理に要する処理時間が短縮可能となり、今まで以上に複雑な計算についても高速に処理することが可能になります。
なお、運賃計算などにかかる処理時間は短縮されるが、新たにネットワーク通信による時間が追加となるため、ICカード処理全体の時間(タッチしてから処理が完了するまで)は現在と概ね変わらない見込みです。
複雑な計算処理の例としては、お客さまのご利用経路(定期券の有効区間をまたがってご利用いただく場合など)が複雑な場合があげられます。着駅経路間の運賃計算処理が複雑となり、処理時間が若干長くなる場合があります。その他、今後に向けては、他サーバーシステムと連携したサービスを行なう場合などを想定しています。(JR東日本広報)
JR東日本の一部駅で導入が始まっている新型改札機 よく引用される「200ミリ秒」という数字は「200ミリ秒以内に完了させる」という意味であり、最も時間がかかった場合の最大の猶予時間だ。それより短時間で完了するケースは多数あり、最大時間である「200ミリ秒」が続くことを想定しても「1分間に60人」という通過人数の目安は達成できることになる。
おそらく、これまで短く済んでいた処理はより時間がかかる可能性があるが、それでも「200ミリ秒」という基準を超えることはない。また逆に、従来までは「200ミリ秒」の限界時間に近かった処理は、新システムの導入により処理負荷が軽減されることから逆にその部分がプラスに働き、トータルでは通信で発生する時間的なペナルティと合わせて結局「200ミリ秒」を達成できるという流れだ。
ちなみに筆者が勘違いしていた部分だが、今回の新システムはあくまで「改札機向けのもの」だ。「物販向けにクレジットカードの都度オーソリのようなことが可能か?」という質問を先方に投げたところ、次のような形で訂正を受けた。
運賃計算処理をセンターサーバーで実施することを目的としており対象は改札機となります。Suicaの物販利用において今回導入するシステムを使用する予定はございません。(JR東日本広報)
また、ここで触れておくが、障害時のシステムの可用性については下記のような回答を得ている。以前の記事では過去の事例に照らし合わせて「最終的に改札の全開放という判断に至る可能性はあるか?」と書き、その旨を確認する質問を送ったが、基本的には多重化と24時間365日の監視体制で臨みたいとしている。
サーバー障害時にもサービス提供の継続を可能とするため、サーバーを複数台で構成し障害時に自動で切替わる冗長化の対策を実施しています。また、システムの稼働状況については、24時間365日体制で監視を行い、万が一事象が発生した場合に迅速な対応ができる体制をとる予定です。
また、ネットワーク障害時にもサービス提供の継続を可能とするため、駅の規模やご利用者数などを勘案し、ネットワーク回線の冗長化などの対策を実施します。(JR東日本広報)
「エリアまたぎ」対策はまだ検討中の段階
Suicaを使っていて普段は気にしないものの、たまの遠出で直面するのが「エリアまたぎ」の問題だ。
具体的には首都圏、新潟、東北などのJR東日本管内のSuica利用可能エリアをICカードのみで移動することは基本的にできず(例外は新幹線を利用した場合など)、磁気切符との併用や個別精算が求められることになる。
理由の1つとしては運賃計算のベースになる経路処理のテーブルが非常に複雑になることで、ローカル処理では実装できなかった部分となる。ゆえに、センターサーバー方式で複雑な計算処理も短時間で可能になれば、「エリアまたぎ」に関する問題は解決する可能性があり、これが新システム導入時における期待の1つともなっていた。特に、システムが先行導入される東北3エリア(青森、秋田、岩手)の3エリアはその実験ができる絶好の機会とも考えていた。
ただJR東日本にこの点を確認したところ、次のような回答が戻ってきた。
本年5月27日に開始する「Suica」を使った出改札サービスにおいて、北東北３エリアをまたいでSuicaをご利用することはできません。エリア統合につきましては検討中の内容であり、実施時期含めて詳細は決まっておりません。(JR東日本広報)
JR東日本管内全域に新システムが行き渡ったことを想定して、将来的な可能性について質問したところ、次の回答を得られた。
センターサーバー方式では運賃計算などの処理をサーバー化することにより処理スピードが向上するため、技術的にはエリアまたぎが可能となります。Suicaエリアの統合につきましては検討中の内容であるため、実施時期含めて詳細は決まっておりません。(JR東日本広報)
将来的に「エリアまたぎ」が可能になれば、新幹線なしで関東から東北までSuicaのタッチだけで移動可能になるかも? 残念だが、検討事項ではあるとのことで、将来に期待したい。また、移行期間中はすべての駅に一斉に導入されるわけではなく、徐々に展開が進んでいく形となる。「当該の駅がセンターサーバー方式に対応したかどうかの判断は、駅の改札機が新型に置き換わったことをもって判断していいのか？」という質問を投げたときの回答は次のようになる。
センターサーバ―方式の導入には、自動改札機の老朽取替のほか、ネットワークの増強などが必要な場合もあり、リプレイスのタイミングをもって一律に判断できるものではありません。(JR東日本広報)
移行期間中は前述のように「対応駅」と「非対応駅」が混在することになる。「エリアまたぎ」をもし実施する場合には、両者を行き来することで出場時にエラーが発生する可能性が高い。この点について質問してみると、当然ながら次のような返答だった。
Suicaエリアの統合につきましては検討中の内容であるため、実施時期含めて詳細は決まっておりませんが、現時点では旧型改札と新型改札が混在した状態での実施は想定しておりません。(JR東日本広報)
「新しいSuicaサービス」の実際
最後に、前回の「SuicaのID化」の話でも大きなテーマだった「Suicaを使った応用サービス」の話題で締める。
現行のSuicaにはいくつか弱点があり、「2万円という残高上限からくる小額決済以外での使いにくさ」「取り消し処理ができないことによるチャージバックの難しさ」「プリペイド方式しか存在しないため、“チャージ”操作が必ず必要とされること」といった事象が挙げられる。究極解はセンターサーバー方式を利用した「ポストペイ」の導入だが、JR東日本は現在のところSuicaの新システムを物販に拡大する意図はないようで、先方からの回答も次のようになる。
現時点において、ポストペイ方式の導入について検討しているものはございません。(JR東日本広報)
また、プレスリリースでもうたわれていた企画券(Season Ticket)との組み合わせによる新サービスについても、現時点ではまだ決定事項はなく、詳細な仕組みを語れる段階でないとの回答で、こちらも決定しだい正式に発表していくとしている。
おそらくは新システムが行き渡らないと利用可能エリアが限られるため、これら新サービスが発表されるタイミングも全駅でのリプレイスが完了する2-3年単位での先の話になると推察する。QRコード改札展開の話と合わせ、もうしばらくのお楽しみということになりそうだ。
「新しいSuica サービス」のご利用イメージは、今後提供を目指すサービスのイメージ例を記載したものであり、詳細な仕組みについては決定しておりません。鉄道チケットシステムの詳細につきましては、決定次第お知らせします。(JR東日本広報)
ここまで、現時点で分かっているすべての情報を整理したが、また続報が入りしだいレポートしていきたい。
JR東日本がセンターサーバー方式の新システムで示した「Suicaの新サービスとして実現できるもの」の例だが、まだ検討中の事項があり、実現までの時間は多少かかりそうだ(出典：JR東日本) 
