ICカード乗車券については、本連載では過去に言及したことがある。

もともと鉄道の運賃支払においては、先に「どこからどこまで行くか」を決めて対価を支払い、それを証明する券片(すなわち乗車券)を受け取って持ち歩くのが基本だった。ところが、ICカード乗車券の導入は、そうした伝統的な考え方から脱却してチケットレス化を図るものだ。

指定席券になると話が難しくなる

ただ、乗車券が対象であれば、「事前にチャージ」「乗車駅で情報を読み取ってデータを記録」「降車駅でチャージ額から運賃を差し引き」という流れで済むが、指定席が関わってくると、話がややこしくなる。「何月何日の」「どの列車の」「何号車の」「席番が○○」という情報を管理しなければならないからだ。紙の指定席券であれば、券面にこれらの情報を書き込んで発券するので、駅員も乗務員も、それを見れば正しい指定席券かどうかを確認できる。

飛行機では、最初に搭乗したら後は降機するだけで途中での出入りがないから、搭乗の際にチェックすれば済む。これなら話は難しくないし、チケットレス化もやりやすい。搭乗ゲートで席番を記した券片を渡せば済む話である。ところが鉄道では途中停車駅があり、同じ列車の同じ席を区間によって複数の乗客が使い分けることがあるから、その度に確認作業が必要になる。

これが座席車ならまだしも、先日に筆者が利用した寝台特急「あけぼの」では、同じ寝台で利用者が途中交代した。潜水艦なら同じ寝床を複数の乗組員が共用する「ホット・バンク」の事例は少なくないが、夜行列車ではあまり多くないかも知れない。と、閑話休題。

とにかく、途中で乗客が入れ替わる可能性がある以上、、駅で改札を通る際のチェックだけでなく、車中で乗務員がチェックする仕組みも必要になる理屈である。列車や席番、ヘタをすると日付を間違えている可能性もあるからだ。特に夜行列車は複数の日をまたいで走るから、発券を頼む際に日付の指定を間違える可能性が高くなる。

席番の情報をどこでどう持つか

つまり、チケットレス化したときに、「何月何日の」「どの列車の」「何号車の」「席番が○○」という情報をどこでどう持つか、という話になるわけだ。

折から、携帯電話に内蔵したFelicaチップ、あるいは専用のICカードによるチケットレスサービスが普及してきているが、それを具現化する際の手法は、大きく分けると二種類ある。

ひとつは、携帯電話内蔵のICチップに指定席の情報を書き込む方式である。この場合、専用アプリをインストールして、それを使って予約・購入を行った上で、情報をICチップに書き込んでおく。この方法だと、座席指定に関する情報は端末の画面に表示できるので、乗務員による確認が必要になったときには、それを見せればよい。

もうひとつの方法は、ICカードには固有識別のためのIDだけを持たせる方法である。利用者登録の際に、そのICカードごとのIDと利用者情報を紐付けておく。そして、利用者がユーザー認証を受けて指定席の予約・購入を行った時点で、さらに日付・列車・号車・席番の情報も紐付けておく。

この場合、所要の情報はセンター側で持っているわけだから、利用者が自分の携帯電話の画面を見ても、何も出てこない。それでは困ってしまうし、まさか「予約時の記憶に頼って着席してください」というわけにも行かない。そこで現実的な解決策としては、自動改札機を通る際に座席指定に関する情報を印刷・発行することになる。

携帯電話の端末機やICカードとは別に、座席指定に関する情報を印刷した紙を持ち歩く必要があって面倒そうだが、携帯電話と専用アプリを必須としない利点がある。筆者のように「携帯電話が通話専用のガラケー」という人でも、別途ICカードを発行してもらえば、それで対応できるわけだ。

鉄道ではなくて飛行機の話だが、JALのチケットレスサービスは後者の仕組みを利用しているようだ。だから、ICチップ内蔵のマイレージ用会員カードを搭乗ゲートでタッチすると、席番などを印字した紙が出てくる。マイレージ会員としてログインしてフライトを予約すれば、マイレージの会員IDと紐つける形で座席予約情報をセンター側で持つことができるので、こういう動作になるわけだ。

重要なのは設計・運用思想の違い

この2種類の方式、どちらが正しいということを論じるのが本稿の目的ではない。どの事業者にしても、さまざまな要素を勘案した上で、どういう形でチケットレスサービスを導入するのかを決めているからだ。そして、お家の事情や思想が違えば最適な選択肢も違う。それだけの話である。

注意したいのは、同じ「チケットレス化」という目的を実現するのでも、考え方やインフラの違いによって複数のアプローチがあるよ、というところだ。そして、自分のところの事情に応じてどちらのアプローチが最適なのかを決めなければならない。

それによって、サービス実現のためのソフトウェアやシステム、サービス利用のためのユーザー・インタフェースにも違いが生じる。システム開発に従事する人は、こういった課題を一つ一つ解決してサービスインに持って行かなければならない。しかも、いったんサービスインしたものを後からコロコロ変えるのは好ましくないから、事前にどれだけ徹底的に、慎重に検討するかが大事である。

執筆者紹介

井上孝司

IT分野から鉄道・航空といった各種交通機関や軍事分野に進出して著述活動を展開中のテクニカルライター。マイクロソフト株式会社を経て1999年春に独立。「戦うコンピュータ2011」(潮書房光人社)のように情報通信技術を切口にする展開に加えて、さまざまな分野の記事を手掛ける。マイナビニュースに加えて「軍事研究」「丸」「Jwings」「エアワールド」「新幹線EX」などに寄稿しているほか、最新刊「現代ミリタリー・ロジスティクス入門」(潮書房光人社)がある。