鈴木淳也のPay Attention
第77回
Apple Payが日本にやってくるまでの話
2020年12月25日 14:15
今回は少しだけ昔話をしたい。振り返ると2014年10月、同年9月に発表されたApple Payのサービスが米国でスタートした。「決済の仕組みをモバイル端末に入れて、街角でもネット上でも自由に買い物ができて、公共交通機関での行き来ができる」という、今日ではごく当たり前の仕組みが端末上のサービスとして標準搭載され、“本格的な”普及を始めた画期的なサービスだと筆者は考えている。
おそらくAppleだからこそ実現でき、かつタイミングもほぼ理想的なタイミングでのサービスインだったのだと思う。
この分野を取材し始めて10年が経過するが、思えば2010年は「NFC(Near Field Communication)」の仕組みが本格的に立ち上がり、モバイル端末に決済や“鍵”の機能を入れてサービスとすべく、メーカーやキャリア、そして金融機関をはじめとするさまざまな集団がこの分野に集結し、思い思いのサービスや製品を市場に投入していた。
モナコを生誕地としてスタートしたNFCの試みは2010年には「NFC対応スマートフォン」として結実し、2011年にはNFCの先行サービスイン地域として実際にフランスのニースやリトアニアのビリニュスに出向いて、現地のNFC事情を取材した。現在から考えると非常に原始的な仕組みやサービスではあるものの、この分野で一旗揚げてやろうと世界中から集まった人々が国際会議や展示会に集結して盛り上がっていた。
だが2013年頃にはそうした人々はフェードアウトし始め、2014年春に米ワシントンDCで開催された国際会議では、千人単位で収容が可能な講演会場に筆者含めて片手で数えるほどの聴講者しかいなかったことが記憶に残っている。
盛り上がっていた人々は消え、そこには停滞ムードと諦めしか残っていなかった。Apple Payの登場は、消えかかったランタンに再び火をともすものだったのだ。
なぜApple Payが画期的だったのか
Apple Payが画期的だった理由は2つある。
1つは政治的側面、もう1つは技術的側面だ。
Apple Pay登場までモバイルNFC分野を停滞させた原因は前者にある。
よく「セキュアエレメント(SE)論争」などと呼ばれるが、取材を開始した2010年からApple Pay登場までの2014年まで、SE論争は一貫して国際会議の主要なテーマだった。SIMカードの保護領域(SE)に決済に必要な情報を携帯キャリアが管理する「SIM方式」、モバイル端末にSEを入れて利用を促す「eSE方式」の間での綱引きだ。
最も有名なエピソードが2011年秋にリリースされた「Galaxy Nexus」で、Samsung Electronicsが開発したこの端末にGoogleは「Google Wallet」という決済アプリをプリインストールし、「Galaxy Nexusと(指定の)クレジットカードさえあれば、すぐにでもNFCを使って店舗決済ができる」という触れ込みで市場投入しようとした。だが、Galaxy Nexusのローンチパートナーだった米Verizon WirelessはWalletアプリが入った状態での端末の取り扱いを拒否し、GoogleはWalletアプリを提供できない状態でGalaxy Nexusを販売しなければならなかった。
当時、モバイルの世界では最大のプラットフォーマであるGoogleの存在は非常に警戒されており、SE論争においてSIM方式誘導を妨げる原因にしかならないeSE推進派の出すGalaxy Nexusの仕組みはまかりならんというわけだ。
このSE論争について「フェイクストーリーだ」と反論するコメントを散見しているが、携帯キャリアとメーカーの両サイドから取材を続けていた筆者は、実際にどのような論争があったのかの裏のストーリーを把握している。
例えばNFCの標準規格を策定するNFC Forumに対し、携帯キャリア側はSIM方式で重要となるNFCアンテナとSEを結びつける仕組みである「SWP(Single Wire Protocol)」の採用を必須化するよう圧力をかけている。SWPはGemalto(現在はThales Groupの一部)が開発して同社がライセンスしている規格だが、実質的にSIM方式への誘導を意図したもので、ライセンス条件を巡って後々駆け引きの材料にされることをForum側では警戒していた。最終的に交渉は物別れに終わり、標準化団体がメーカー系とキャリア系に分裂するきっかけとなった。
同様に、GoogleがGalaxy Nexusの件を経てSEの実装方式での論争に不毛さを感じ、SEの搭載なしでインターフェイス上は同様の仕組みを実現する「HCE(Host Card Emulation)」をAndroidに標準採用したときもキャリア側は大きく抗議し、結果としてAndroid Pay(後のGoogle Pay)の提供遅延につながったという話も聞いている。
Apple Payが登場するまでの5年近く、両陣営は表に裏に激しい争いを繰り広げてきた。一方で、キャリア側が提供するモバイル決済サービスも各種登場したが、実際にサービスインまでこぎつけた、あるいは継続提供されたものは非常に限られている。
例えば2012年のロンドン五輪に合わせてモバイルウォレットサービスを提供予定だった英Vodafoneは、協議期間が終わってからの一般向けサービス開始ができず、最終的に1年以上の追加準備期間が必要だった。理由としてはセキュリティ上の問題があり、カード会社側が当初の仕様でのサービス提供に難色を示したからとされている。
ICチップ入りカードとして銀行が直接完成品を提供できるクレジットカードに比べ、モバイル決済の世界では途中に管理主体としてのキャリアが存在し、TSM(Trusted Service Manager)を通じてモバイル端末上のSEにアクセスする必要がある。サービス事業者側から見れば、端末上の決済情報に直接アクセスできないうえ、管理をキャリアに委ねなければいけない。このあたりの不満も取材の過程でたびたび聞かれたことだ。
つまり、Apple Payはこうした政治的な駆け引きの多くをクリアし、さらに多くのカードイシュア(銀行)を説得してセキュリティ上の懸念を払拭する形で管理システムを作り上げた点で画期的なサービスだったというわけだ。
同時に、決済用のカードを端末上で呼び出す方法としてアプリではなく、OSそのものに実装することで、画面ロック解除なしでスリープ状態から直接支払うことを可能にした。PINコードの代わりにTouch IDを安全な本人確認手段としてイシュアに認めさせ、さらに簡単に支払い用に複数登録したカードから好きな物を選んですぐに使えるユーザーインターフェイスも整備した。
今日でこそモバイルウォレットでは当たり前の仕組みだが、この「カード選択」というUIを自然な形で採用したのはApple Payが初だと筆者は考える。実際、以後はApple Payに近い形でウォレットの実装が行なわれることが多く、今日あるモバイル決済の「ひな型」とも呼べるサービスになった。これが技術面で画期的だったと評価するポイントだ。
そして日本へ……
Apple Payは2016年秋に日本にやってきた。プロジェクト自体が米国での正式発表のころにはすでに走っており、2年ほどの準備期間があったことを把握している。ただ、現在のApple Pay提供形態になるまでにはいろいろ紆余曲折あったようで、当初関係者からの話として聞いていたのは「米国同様にType-A/B形式で国内パートナーを増やす」というものだった。当時の日本ではEMV非接触決済に対応する店舗はほぼ皆無で、2015年に全国でも数カ所の拠点でようやく対応したというレベルだった。
「対応クレジットカードを登録することでiDまたはQUICPayが利用できる」という現在の方式が採用されたのは、2016年のリリースの割と直前、おそらく2015年だったのではないかと、複数の証言を基に筆者は考えている。
きっかけの1つはApple Payに東日本旅客鉄道(JR東日本)が参加してきたことで、この時点で「iPhoneにFeliCaを載せる」という方向が確定したとみられる。なぜならJR東日本を含む日本の交通サービスの利用にはSuicaが必須であり、そのためのFeliCaサポートが必須だからだ。
複数の関係者の話によると、AppleとJR東日本ともにこのプロジェクトには非常に前のめりで、トントン拍子で話が進んでいったという。ただし、リリースまでの準備期間が非常に短く(1年なかったといわれる)、ある関係者によれば、JR東日本のシステム開発を担当するJR東日本メカトロニクス(JREM)がプロジェクトに難色を示したという。そこでヘルプとして入ってきたのがフェリカネットワークスで、最終的にApple PayのFeliCaまわりのシステムは同社が構築、運用する形となった。
だが複数の関係者の証言で、フェリカネットワークスはシステム構築を行なったもののプロジェクトを推進していた2社からの支払いはなく、実質的にほぼ無償で作業していた状態だったという。そこで以後のシステム運用の問題もあり、ドコモ、KDDI、ソフトバンクの3社が持ち出しの形で資金拠出を行なった。つまり、現在Apple PayのFeliCaまわりの運用費用はこの3社が分担で受け持っていることになる。
そうして構築された日本のApple Payは、諸外国と比較してやや特殊なものとなった。Apple Pay対応カードをiPhoneなどに登録すると、自動的にiDまたはQUICPayの割り当てが行なわれ、店頭でのタッチ決済ではこのいずれかでの支払いが可能になる。
一方で、Webサイトやアプリ上での決済では、もともとのクレジットカードの持っていた国際ブランドとそのカード番号での決済が行なわれる。1枚のカードに対して2つの「DAN(Device Account Number)」が割り当てられる形となるが、これは日本独自のものだ。
さらにこれとは別に、Suicaのカードも登録可能であり、日本では他国にはないiD、QUICPay、Suicaという3種類の決済規格がApple Pay上に実装されることになった。
ここで2つほど問題が発生した。
その1つが今日に続く「Apple Payが日本でVisaをサポートしない」問題で、国際カードブランドで唯一VisaカードだけがApple Payに登録しても“Visaとしての機能”を利用できない状態になった。カードを発行するイシュアがApple Payに対応していれば、iDまたはQUICPayとしては利用できるものの、Webサイトやアプリでの決済には利用できない。Visaの決済ネットワークの通過を拒否しているため、iPhone 8以降でサポートされた「日本発行のクレジットカードならFeliCaでもType-A/Bでも両方利用できる」という仕組みも利用できない。
これに関してVisaは沈黙を貫いているが、複数の関係者の証言によれば日本のApple PayにおけるFeliCa共存の独自仕様を嫌っているのが原因だという。特にVisaは東京五輪スポンサーということもあり、日本国内で「Visaタッチ」が使える加盟店を増やすべくさまざまな施策を展開している最中で、「日本ではiDまたはQUICPay」という仕様は普及の妨げ要因にしかならない。また「Visaで支払い」といえばシンプルに済む決済が、(店員が操作して決済方法を決めるという)おサイフケータイ風の流儀により煩雑なものとなる。Visaはカードに複数の決済ブランドが同居する仕組みにも難色を示しているといわれ、このあたりがAppleとの交渉のポイントになっているとされる。
問題のもう1つは、iDとQUICPayへの対応だ。日本でApple Payが展開された当初、カードの割当先の数でQUICPayが圧倒的に多いという状況があった。Apple Payではそれまで日本では馴染みのなかった「(カードの)即時発行」という仕組みが要求されており、前述のように準備期間もほとんどなかったことから、Apple Pay対応を目指すカード各社が対応に追われる形となった。
ある関係者によれば、iDは手数料率が低いもののインテグレーションの作業が必要で、対するQUICPayでは手数料率の関係でイシュアの利益はほとんどないものの、システムはSaaS形式で非常に導入が容易だったという。JCBがApple Pay導入用のパッケージをイシュア各社に売り込んでいたこともあり、準備期間のほとんどかからないQUICPayに多くの会社が食いつく形となった。これにより、それまで利用の少なかったQUICPayがApple Pay開始直後に倍々ペースで利用されるようになり、JCBを潤すことになった。
これで割を食ったのがiDサイドで、ドコモとともに同規格を推進する三井住友カードではJCBとの仲が一時険悪になり、JCBにiDのアクワイアリングの新規停止を通告するなどの措置が採られた。また、2018年に三井住友カードはドコモとの資本提携を解消し、ドコモは後にみずほ系列のUCカードとの提携を発表しているが、これもiD普及に業を煮やした三井住友カードが戦略再構築の一環として決定したものとなる。ドコモはdカードの発行にあたり、三井住友カードの番号帯を使用しているが、今後いずれかのタイミングでUCのものに切り替えていく形になる。結果として、Apple Payが日本のカード業界の慣習を変え(即時発行対応)、業界再編を促したことになる。
交通系IC対応にみる独自仕様とオープンループ
前段のストーリーをみると、日本のApple Payだけが世界の理から外れた独自仕様のようにも思えるが、カナダ独自のデビットカードであるInteracがApple Payで利用できることからも分かるように、このサービスそのものは各国に密着したローカライズが行なわれているのが特徴だ。最近、日本でもPASMOがApple Pay対応されたことをはじめ、Suica以外の交通系IC対応がApple Payでも増えている。代表的なものが、中国本土でのT-Unionカード(北京含む)、上海交通カード、香港の八達通、米シカゴのVentra、米ロサンゼルスのTAP、米ポートランドのHop Fastpass、米ワシントンDCのSmarTripといった具合だ。八達通のみFeliCaだが、ほかはMifare(Type-A/B)ベースの独自の交通系ICカードとなっている。アジアを除けば、国内で交通系ICカードが統一されているケースは少なく、都市ごとに異なるカードが存在するのが一般的なので、Apple Payは今後もある程度は対応カードを増やしていく必要があるのだろう。
それと同時に、英ロンドンのTfLや米ニューヨークMTAのOMNYにみられるように、普段使いのクレジットカードを“かざす”ことでそのまま交通系サービスが利用できる「オープンループ」の仕組みも増えている。この最新トレンドや技術的な特徴は別誌の連載で紹介しているが、今後は対応カードを増やす一方ではなく、Apple Payとしてオープンループを積極的にプッシュしていくことになるだろう。実際、Visaによれば世界で500以上のオープンループ導入プロジェクトが走っており、iPhoneさえあれば世界中の都市で新たにカードなどを購入する必要なく、ある程度自由に移動できる日もそう遠くないと考えている。
また、この話は後日改めてまとめる予定だが、「オープンループは遅い」という誤解について少しだけ触れたい。JR東日本の積極的な宣伝もあり、「Suicaのスピードは世界一！」という話が割と浸透している。
一方で、「SuicaではないType-A/Bのオープンループなんて日本に採用したらラッシュの交通渋滞で大変なことになる」という話もよく聞こえてくる。SuicaというかFeliCa至上主義みたいなものだが、個人的意見でいえば現状のFeliCaとMifare(Type-A/B)の通信速度はともに424キロビット秒で差がない。SuicaそのものはJR東日本が改札通過を1分間に60人程度ということで仕様を担保しているが、このあたりは運行事業者のシステム設計ポリシーやチューニングによる差が大きいと考える。
例えば、Suicaでは改札の反応速度を200ミリ秒以下と定めているが、ロンドンのTfLはOysterカードでのクローズドループの反応速度を250ミリ秒以下としており、数字上の差は実はそれほど大きくない。
オープンループについても、TfLでは500ミリ秒以下としており、これはEMVCoでも交通サービスでの改札通過の標準時間として定義している。「500ミリ秒以下」とはいうものの、実際にはそれよりかなり短い時間で通過できるようになっている。「クレジットカードの処理にいつも時間がかかるが、同じことを改札でやったら通過に時間がかかるだけだろう」という声も聞く。だが区間運賃を設定する改札システムの場合は、入場時にカード番号取得とネガチェックだけを行ない、一番時間のかかるオーソリの部分は移動中に処理してしまう。出場時に運賃が決定されるため、すでに準備ができている決済を完了させて運賃徴収は終わりという流れだ。
この移動の時間差を利用した仕組みが実現できるのも、クレジットカードの“与信”を交通システムに応用したためで(デビットでも利用できる)、Apple Payもまたその恩恵によって世界の交通システム利用が容易になっている。
