Suica 200ミリ秒：日本のIC乗車カードがサーバー往復を打ち負かした方法

東京の通勤客が駅の改札にSuicaカードをかざすたびに、認証、運賃計算、残高引き落としという完全な金融取引が200ミリ秒未満で実行される。バッテリーなし、サーバー呼び出しなし、ネットワーク依存なし。これは単なる巧妙なトリックではない。何百万人もの人々が世界で最も混雑する交通ネットワークを移動する方法を形作ってきた設計判断なのだ。

カードこそがデータベース

ほとんどの決済システムとは異なり、SuicaはカードIDと残高の両方をチップに直接保存する。改札のリーダーは電磁界を放射し、交換を完了するのに十分な時間だけカードに電力を供給する。カードとリーダーは相互認証し、新しい暗号化キーを生成し、残高を書き換える——すべてローカルで行われる。

なぜ毎回のタップで中央サーバーと同期しないのか？東京の規模では、それは壊滅的だからだ。サーバー往復はレイテンシを追加し、パケット損失、ダウンタイム、輻輳などのネットワーク障害は、ラッシュアワーに改札を停止させる。代わりに、改札はトランザクションログをリアルタイムではなく定期的に中央サーバーと同期する。

Suicaへの道：拒絶から救済へ

Suica以前、東京の駅は人間の改札係によるボトルネックだった。1987年に民営化されたJR東日本は近代化を望んだが、実証されていない非接触IC技術には懐疑的だった。ソニーは独自の非接触システムであるFeliCaを提案したが、JR東日本はノーと言った——技術が十分に速くなく、信頼性もなかったからだ。

ソニーは香港の八達通（オクトパス）カードが手を差し伸べるまで、FeliCaをほぼ放棄しかけた。ソニーは10cmの読み取り範囲と100msの応答時間を持つカードを開発し、入札に勝ち、八達通は1997年に大成功を収めて発売された。その実証がJR東日本を交渉のテーブルに戻した。

200ミリ秒の試練

JR東日本は譲れない要件を設定した：カード検出から運賃計算、残高引き落としまでの取引全体を200ミリ秒未満で完了させること。これは聞こえるよりも厳しい。八達通の100ms目標は無線通信のみをカバーしていた。エンドツーエンドの取引全体は約300msかかると報告されている。Suicaの200msはすべてをカバーしなければならなかった。

その目標を達成するために、カードとリーダーはすべてをローカルで処理しなければならなかった。改札は電磁界を放射し、カードが起動し、認証し、運賃を計算し、残高を更新する——すべてカードが範囲内にある一瞬のうちに行われる。ソニーはまた、リーダーの通信範囲を競合他社の2倍の85mmに拡張し、乗客がカードを完璧に合わせるために立ち止まることなく歩き続けられるようにした。

UI問題でほぼ頓挫

初期のプロトタイプは惨憺たるものだった。テスターのほぼ半数が改札を通れなかった。幹部は「打率20%」と不満を漏らした。経営陣はプロジェクトを中止する準備ができていた。修正点はチップではなく、リーダーのデザインにあった。平らで印のないパネルは、使い方のヒントを一切与えなかった。人々はバーコードをスキャンするように、速くスワイプしたり、高くかざしたりした。タップ動作を明確に示す再設計がプロジェクトを救った。

現代のエンジニアへの教訓

Suicaのアーキテクチャはエッジコンピューティングの教科書的な事例だ。サーバーを避けることではなく、サーバー往復がいつ負債になるかを知ることだ。低レイテンシ、高スループット、ミッションクリティカルな相互作用では、最終同期を伴うローカル処理が、スムーズな通勤と駅全体の混乱の違いを生むことがある。

IoT、決済、リアルタイムシステムを構築する際、Suicaの200ms制約は思い出させてくれる：時には最良のネットワークコールは、行わないことだ。