いまでは、クレジットカードやスマートフォンを改札へかざして、そのまま電車やバスに乗れる都市が増えています。
しかし、交通のタッチ決済は最初から銀行カードで始まったわけではありません。
香港のOctopus、ロンドンのOyster、日本のSuica。大規模に成功した初期の交通ICは、いずれも交通事業者が管理するclosed-loop型の専用credentialから始まりました。
なぜ、世界共通のVisaやMastercardではなく、わざわざ専用カードが必要だったのでしょうか。
理由は単純な「古い技術」ではありません。
改札では、数百ミリ秒の遅れがラッシュ時の人流へ直結します。入場時点では運賃が確定しない場合があり、乗車履歴をまとめて最安運賃を計算する必要もあります。通信障害やカード残高不足、未回収運賃への対応も必要です。
交通事業者が最初にclosed-loopを選んだのは、速度、運賃計算、risk、resilienceを自分たちで制御する合理性があったからです。
その後、一般のcontactless cardが普及し、カードnetwork側も交通向けにauthorizationやaggregationを変えたことで、既存のbank cardをそのまま使うopen-loop transitが可能になりました。
この記事では、closed-loopからopen-loopへの変化を「専用カードが古くなって置き換えられた歴史」ではなく、交通固有の処理をback officeへ移し、general-purpose credentialを追加できるようになったmigrationとして整理します。
- 結論：Open-loopは「改札で普通のカード決済をする」仕組みではない
- 1990年代――Closed-loopは「未熟」だったのではない
- 2001年――Suicaは424駅を最初から用意した
- Oysterも最初から完成形ではなかった
- なぜ普通のbank cardでは難しかったのか
- 2012年――ロンドンはまずバスから始めた
- 交通向けOpen-loopは「後払いのまとめ決済」に近い
- Mobile WalletでClosed-loopとOpen-loopが同じスマホに入った
- Open-loopは専用交通カードを「不要」にしたのか
- なぜ20年かかったのか
- 一般店舗のタッチ決済と交通決済の違い
- まとめ
- 主な一次資料
- 関連記事
結論：Open-loopは「改札で普通のカード決済をする」仕組みではない
一般の小売店では、商品金額が決まってからカードをタッチし、authorizationを取るのが基本です。
交通は違います。
入場時点では最終運賃が決まらないことがあります。1日に何度も乗れば、daily capやweekly capを適用した方がよい場合もあります。改札はラッシュ時でも高速に人を通さなければなりません。
そこでopen-loop transitでは、改札でcredentialの有効性を確認し、乗車履歴をback officeへ送り、後から運賃を計算・集約し、必要に応じてdeferred authorizationやdebt recoveryを行う仕組みが使われます。
つまり、VisaやMastercardを改札で使えるようにするには、通常の小売決済をそのまま持ち込むだけでは足りません。
交通側とpayment industryの両方を変える必要がありました。
1990年代――Closed-loopは「未熟」だったのではない
香港では、主要交通事業者5社が1994年にCreative Starというjoint ventureを作り、1997年にOctopusを開始しました。
これは、交通事業者が共通のcredentialとacceptanceを自分たちで整備する方式です。
closed-loopには明確な利点があります。
- 加盟店網を一つずつ開拓しなくてよい
- 改札の処理速度を自分たちで設計できる
- 運賃体系を独自に実装できる
- 残高、利用停止、障害時対応を事業者側で管理できる
- 毎日の通勤・通学という強いanchor useがある
一般小売の決済ネットワークではconsumerとmerchantを同時に集める必要があります。
交通では、operatorがacceptance sideを先に一括整備できます。
closed-loopは、ネットワークをゼロから立ち上げるための合理的なbootstrapping architectureだったと見ることができます。
2001年――Suicaは424駅を最初から用意した
JR東日本は2001年11月18日、東京近郊424駅でSuicaを開始しました。
サービス開始後191日目の2002年5月27日には、Suica利用者は401万人に達しています。
JR東日本は、ケースから出さずに使えること、事前チャージで券売機に並ぶ必要を減らせること、乗り越し精算を自動化できることなどを利便性として説明しています。
さらにJR EAST Technical Reviewでは、Suica改札の処理仕様として0.2秒以内、改札1通路あたり毎分60人を目標とする設計が示されています。
交通決済にとって、「決済できる」だけでは不十分です。
決済しても人の流れを止めないことが、システム要件そのものです。
Oysterも最初から完成形ではなかった
ロンドンのOysterは2003年6月30日にpublic launchしました。
しかし、現在のようなPay As You Goやcappingがすべて同時に始まったわけではありません。
TfLの公式chronologyでは、
- 2003-06-30: Oyster public launch
- 2004-01-04: London UndergroundでPre Pay開始
- 2004-05-16: bus / tramへPAYG拡大
- 2005-02-27: daily capping開始
- 2010-01-02: Oyster PAYGを多くのNational Railへ拡大
という段階導入でした。
2006年のTfL資料では、Oyster利用者は改札を毎分40人通過でき、磁気券より15人多いと説明されています。
専用カードは単なる「囲い込み」ではありません。
高速改札、複雑なfare rule、段階的な機能追加を、operatorの管理下で実現するための基盤でもありました。
なぜ普通のbank cardでは難しかったのか
open-loop transitで最も分かりにくいのは、タッチの瞬間に金融authorizationが完了しなくてもよい場合があることです。
EMVCoのTransit use caseでは、entry時にcredentialの真正性を確認してturnstileを開き、entry/exit情報を結び付けてfareを算出した後に、Token ProcessingやPAN Authorizationへ進む例が示されています。
ここでOffline Data Authentication（ODA）を「オフラインで金融承認すること」と理解してはいけません。
ODAはcredential dataの真正性確認であり、最終的なpayment authorizationとは別です。
VisaのMass Transit Transaction（MTT）モデルも、tap時点ではfinancial transactionを起こさず、back officeでdeferred authorizationやdeny-list managementを行う構造を説明しています。
一般小売とは違い、改札を先に通して、金融処理を後ろへずらす設計が必要になるわけです。
2012年――ロンドンはまずバスから始めた
TfLは2012年12月13日、ロンドンのbusでcontactless bank cardによるsingle journeyを開始しました。
いきなりTube全体へ導入したわけではありません。
busは運賃体系が比較的単純で、open-loopの最初の適用先として合理的でした。
その後2014年9月16日、Tube、DLR、Overground、tram、Oysterが使える多くのNational Rail区間へ拡大します。
この段階ではdaily capだけでなくweekly capも含め、Oysterに近いfare experienceを一般のbank cardへ提供する設計になりました。
重要なのは、Oysterを廃止したのではないことです。
closed-loopとopen-loopは共存しました。
交通向けOpen-loopは「後払いのまとめ決済」に近い
open-loop transitでは、1回のtapごとにその場で1件の小売決済を作るとは限りません。
Mastercard Gatewayの交通向けdocumentationでは、運賃が最初のtapで決まらない場合、複数tripのtap dataを集約し、travel periodの終わりにtotal fareを計算して請求するモデルが示されています。
TfLも、contactlessのjourney dataをback officeで処理し、1日の終わりにfareをfinaliseする仕組みを説明しています。
もし支払いがdeclineされた場合には再試行し、未払いが解消されるまでそのcardをtransport useからblockする仕組みもあります。
つまりopen-loop transitで重要なのはreaderよりも、むしろその後ろの、
**aggregation
fare calculation
deferred authorization
deny list
debt recovery
capping**
です。
Mobile WalletでClosed-loopとOpen-loopが同じスマホに入った
スマートフォンが普及すると、closed-loop / open-loopの違いはさらに見えにくくなります。
たとえばWalletの中には、
1. Suicaのようなclosed-loop transit credential
2. VisaやMastercardなどopen-loop payment credential
の両方を入れることができます。
AppleのExpress Modeでは、対応credentialを使う場合、Face ID、Touch ID、passcodeでの毎回の認証や、端末のwake/unlockを省いて改札を通過できます。
これは単なる便利機能ではありません。
交通は「本人確認を毎回丁寧に行うこと」よりも、「安全性を維持しながら大量の人を止めずに通すこと」が重要です。
mobile walletも交通固有のUXへ合わせて変化しています。
Open-loopは専用交通カードを「不要」にしたのか
いいえ。
closed-loopとopen-loopにはそれぞれ強みがあります。
| 観点 | Closed-loop | Open-loop |
|---|---|---|
| credential | 専用交通カード | 既存のbank card / wallet |
| consumer friction | 発行・チャージが必要 | 既に持つカードを使える |
| operator control | 高い | scheme / issuer / acquirerとの協調が必要 |
| fare/risk logic | operator内で設計 | back officeでpayment railと統合 |
| interoperability | 地域・事業者中心 | 国際カードnetworkを利用 |
| migration | 専用基盤を構築 | 既存交通基盤へlayerとして追加可能 |
SuicaやOysterが「古くなったからVisaへ置き換わる」という歴史ではありません。
むしろ、
closed-loopで先に交通ネットワークを完成させ、その上へopen-loop credentialを後から追加した
と見る方が正確です。
なぜ20年かかったのか
2001年のSuica開始から、open-loop transitが世界の多くの都市で現実的な選択肢になるまでには長い時間がかかりました。
必要だったのはcontactless readerだけではありません。
- general-purpose contactless cardの普及
- EMVの相互運用
- issuer/acquirer/network側の交通向けrule
- back-office fare engine
- deferred authorization
- aggregation
- debt recovery
- mobile wallet
- tokenization
- consumer familiarity
が必要でした。
交通がgeneral-purpose payment railを使うには、決済側が交通へ近づく必要があった。
それがopen-loop transitの歴史です。
一般店舗のタッチ決済と交通決済の違い
FeliCaとEMV Contactlessの違いに加え、交通決済では、運賃の計算や改札の処理速度、未回収運賃への対応を考える必要があります。
交通決済の歴史を理解するうえで、中心になるのは次の問いです。
なぜ交通はclosed-loopから始まり、後にbank cardを直接受け入れられるようになったのか
これは、カードの読み取り方式だけでなく、決済システムの設計と移行の問題です。
まとめ
交通決済の歴史を見ると、closed-loopは「open-loop以前の未熟な仕組み」ではありません。
交通事業者が速度、運賃、risk、resilienceを自分で管理し、密度の高いacceptanceと毎日の利用を先に作るための合理的なarchitectureでした。
その後、一般のbank cardとpayment networkが十分普及し、交通向けにauthorizationやfare processingを変えられるようになったことで、open-loopを重ねられるようになりました。
普及した技術を捨てるのではなく、既存のinstalled baseを残したまま新しいcredentialを追加する。
LondonのOysterとcontactlessの共存は、決済技術のmigrationが成功する一つの形を示しています。
主な一次資料
- Octopus Cards Ltd., official history（1994 JV / 1997 launch / 取得 2026-09-27）
出典リンク - JR東日本「2001年11月18日 Suicaデビュー」（2001-09-04 / 424駅 / 取得 2026-09-27）
出典リンク - JR東日本「Suica利用者400万人」（2002-05-28 / day 191 / 取得 2026-09-27）
出典リンク - JR EAST Technical Review No.16（2006 / ≤0.2 sec / 60 people per minute / 取得 2026-09-27）
出典リンク - TfL, Oyster / ticketing official history and release（2003–2010 chronology / 取得 2026-09-27）
出典リンク - TfL / DfT, Oyster gate throughput（2006 / 40 people/min / 取得 2026-09-27）
出典リンク - GLA MD1318（2014 / London contactless expansion / 取得 2026-09-27）
出典リンク - Mastercard Gateway, transit transaction documentation（current / aggregation & deferred authorization / 取得 2026-09-27）
出典リンク - TfL Contactless Conditions of Use（current / charging, retry, blocking / 取得 2026-09-27）
出典リンク - EMVCo, EMV Payment Tokenisation — A Guide to Use Cases v2.2.1（2019–2023 / transit use case / 取得 2026-09-27）
出典リンク - Visa, Transforming Urban Mobility（date not shown / MTT / <500ms / 取得 2026-09-27）
出典リンク - Apple, Apple Pay Coming to the UK（2015-06-08 / TfL support / 取得 2026-09-27）
出典リンク
