なぜカード番号そのものを使わなくなっているのか？PANからApple Pay、Network Tokenまで

最終確認：2026年9月22日

16桁のカード番号（PAN）は、長いあいだ「支払うための鍵」そのものでした。ところがECとスマートフォン決済が広がると、同じ番号を多くの事業者へ渡す構造自体が弱点になります。そこで決済は、PANを守るだけでなく、用途を限定できるTokenを外側へ渡す方向へ進みました。

その変化はセキュリティ技術だけの歴史ではありません。2010年代前半には、通信キャリア、Google、Apple、カードネットワーク、銀行、Walmartなどの大手加盟店が、デジタル時代の財布を誰が握るのかを競いました。

本稿ではPANからPayment Token、Apple Pay、Network Tokenまでの流れを、当時の企業発表・技術資料・米議会資料・規制当局資料からたどります。

図1　PANは「万能鍵」、Tokenは「用途を限定できる鍵」

PAN

カード口座を特定する基礎的な番号。多くの加盟店・チャネルで同じ番号を使うため、漏えいした情報が別の場所で悪用される余地がある。

Payment Token

PANの代わりに使うデジタルcredential。加盟店・端末・利用シナリオなど、利用できる範囲を限定できる。

ポイント：PANがなくなったわけではない。基礎credentialとして残しつつ、攻撃されやすい外側ではTokenへ置き換える方向へ進んだ。

PANの弱点――一度漏れると「別の場所でも使える」

PAN（Primary Account Number）は、カード口座を識別するための基本情報です。カード決済の世界では長年、店頭でもECでも同じ番号が使われてきました。

これは相互運用性の面では大きな長所でした。どの加盟店でも同じカード番号を使えるからこそ、世界規模のカードネットワークが成立します。

しかしデジタル化すると、その長所が弱点にもなります。

EC事業者が次回入力の手間をなくすためカード番号を保存し、決済代行会社、加盟店、アプリ、さまざまなシステムが同じPANを扱うようになると、どこか一か所から漏れたcredentialが、別の場所でも悪用され得ます。

前の記事で扱ったAmazon 1-ClickやStored Credentialは、「毎回カード番号を入力しない」という利便性を高めました。Tokenisationは、その利便性を維持しながら本物のPANを露出させないための次の答えでした。

2010年――最初に「スマホの財布」を取りに来たのは通信キャリアだった

Apple Payより4年前の2010年11月、AT&T Mobility、T-Mobile USA、Verizon Wirelessは共同でIsisというモバイルコマース事業を立ち上げました。

3社は当時、合計で2億人を超える米国の携帯契約者を抱えていました。決済インフラにはDiscover Network、最初の発行会社としてBarclaycard USを組み合わせる構想でした。

Isisが目指していたのは単に「携帯電話でカードをタッチする」ことではありません。公式発表は、現金や決済カードだけでなく、reward card、coupon、ticket、transit passまで携帯電話へ入れる未来を描いています。

AT&Tの2012年Annual Reportも、Isisを銀行や広告主がモバイル利用者へアクセスする新しいプラットフォームとして位置付けています。

つまりモバイル決済黎明期の争点は、最初から支払処理だけではありませんでした。誰が消費者との入口を持ち、クーポン・ロイヤルティ・広告まで束ねるのかという競争だったのです。

2011年――Google WalletはAppleより3年以上早かった

2011年5月、GoogleはCiti、MasterCard、First Data、SprintとGoogle Walletを発表しました。同年9月にはSprintのNexus S 4G向けに提供を開始します。

初期Google Walletで使えたのはCiti MasterCardとGoogle Prepaid Cardが中心でした。GoogleはNFCを使い、「tap, pay and save」という体験を掲げ、支払いだけでなくoffersやloyaltyまで一つにまとめようとしていました。

ここで重要なのがSecure Elementです。

初期のNFCカードエミュレーションでは、決済credentialを安全なチップ領域へ置く方式が重要でした。Secure Elementは端末に内蔵することも、通信キャリアが管理するSIMに置くこともできます。

ところが米国の大手通信キャリア3社は、自分たちでIsisを持っていました。

このため当時のモバイル決済は、「良いwalletアプリを作れば勝てる」という単純な市場ではありませんでした。端末、OS、SIM、Secure Element、発行会社、カードネットワーク、通信キャリアのどこか一つでも協力しなければ、消費者へ届けにくかったのです。

2012年――Googleは「カードを端末に保存する」設計を変えた

2012年8月、GoogleはWalletの設計を大きく変更します。

新しいcloud-based Google Walletでは、Visa、MasterCard、American Express、DiscoverのカードをGoogleの安全なサーバーへ保存し、端末のsecure storageにはWallet IDというvirtual card numberを置く方式へ移行しました。

Google自身は、この変更によって銀行のWallet対応を数週間で進められるようになると説明しています。

これは現在のEMV Payment Tokenと同じ仕組みではありません。しかし歴史的には重要です。本物のカード番号を端末や加盟店へそのまま渡す必要はないという発想が、モバイルウォレットの設計へ組み込まれていったからです。

2013年――AndroidはSecure Elementへの依存まで減らした

さらにAndroid 4.4ではHost Card Emulation（HCE）が導入されました。

Androidの公式技術資料によれば、HCEを使えば、物理的なSecure Elementを必須とせず、Androidアプリ自身がNFCカードをエミュレートできます。

産業構造として見ると、この変更は大きな意味を持ちます。wallet事業者が、通信キャリア管理のSIM Secure Elementなどへ必ずしも依存せずにNFCサービスを構成できる余地が広がったからです。

ただし、「HCEは通信キャリアを排除するために作られた」といった動機までは一次資料から断定できません。本稿では技術的に依存関係が変わったという事実と、その競争上の含意を分けて扱います。

図2　2010〜2015年「スマホの財布」をめぐる主導権争い

2010　AT&T / Verizon / T-Mobile → Isis
通信キャリアがwallet、coupon、loyalty、ticketまで取り込む構想。

↓

2011　Google Wallet
Google＋Citi＋MasterCard＋First Data＋Sprint。NFC walletを先行投入。

↓

2012　Google Walletをcloud型へ
カードはGoogleサーバー、端末にはvirtual card number。

↓

2013　Android 4.4 HCE
物理Secure Elementを必須としないNFCカードエミュレーション。

↓

2013　Visa / MasterCard / AmexがToken標準を提案

↓

2014　Apple Pay / VTS / MDES
Appleが端末・wallet UX、ネットワークがToken/既存railsを担う。

↓

2014　MCX / CurrentC
Walmart等の大手加盟店がQR、loyalty、merchant relationshipを自ら握ろうとする。

↓

2015　GoogleがSoftcard技術・IPの一部を取得 → Android Pay
Googleもindustry-standard tokenizationへ。

2013年10月――Visa、MasterCard、Amexが「カード番号を使わない」標準を提案

モバイルwalletの主導権争いとは別に、カードネットワーク側も動いていました。

2013年10月1日、MasterCard、Visa、American Expressは共同で、オンライン・モバイル決済向けの新しいglobal standardの枠組みを提案しました。

公式発表の副題は象徴的です。「オンラインcheckoutでaccount numberを不要にする」ことを掲げています。

提案されたのは、従来のaccount numberをdigital payment tokenへ置き換える方式でした。これによって加盟店やdigital wallet operatorなどが本物のカード番号を保存する必要を減らしつつ、既存のカード決済ネットワークを利用できるようにします。

重要なのは、Tokenが単なる「ランダムな別番号」ではないことです。誰にTokenを発行するのか、どの端末・加盟店・利用シナリオで使えるのか、どの口座と結び付くのか、紛失・再発行時にどう更新するのかというcredential lifecycleまで含めて管理する必要があります。

Target事件はTokenisationを「発明」させたわけではない

この時系列は正確に押さえる必要があります。

カード3社によるglobal token standard提案は2013年10月1日です。

Targetが大規模なカード情報への不正アクセスを公表したのは2013年12月19日。同社は、2013年11月27日から12月15日の間に米国店舗で利用された約4,000万件のcredit/debit card accountが影響を受けた可能性があると発表しました。

さらに2014年9月、Home Depotは約5,600万枚のunique payment cardがリスクにさらされたと公表しています。

したがって、Target事件を受けてTokenisationが発明されたとは書けません。標準化は事件の前から進んでいました。

一方、こうした大規模漏えいが、同じPANを多数の加盟店・システムへ露出させる構造の危険性を社会へ強く可視化したことは確かです。

2014年9月9日――Apple PayとNetwork Tokenが同じ日に表舞台へ出た

2014年9月9日、AppleはApple Payを発表しました。

開始時点からAmerican Express、MasterCard、Visaに加え、Bank of America、Capital One、Chase、Citi、Wells Fargoなど大手発行会社が参加し、Appleによればこれらの銀行は当時の米国credit card purchase volumeの83％をカバーしていました。

Apple Payへカードを追加しても、実際のカード番号はiPhoneにもAppleのサーバーにも保存されません。

代わりに固有のDevice Account Numberが作られ、Secure Elementへ保存されます。決済時にはさらに、取引ごとの動的なsecurity codeを組み合わせます。

同じ2014年9月9日、VisaはVisa Token Service（VTS）を発表しました。MastercardもApple Payの立ち上げでMastercard Digital Enablement Service（MDES）を使い、カードcredentialをデジタル端末へ安全にProvisioningする仕組みを展開しました。

ここがApple Payの産業史上の重要点です。

AppleはVisaやMastercardを排除して独自の決済ネットワークを作ったわけではありません。

AppleがiPhone、Secure Element、Touch ID、WalletのUXを握り、カードネットワーク側がToken Serviceと既存のissuer/acquirer/acceptance railsを握る。

競争しながらも、既存カードネットワークをデジタル端末の中へ組み込む分業モデルだったのです。

図3　Apple Payは「カードネットワークを置き換えた」のではない

Issuer / カード口座
PANを持つ基礎レイヤー

↓ Token provisioning

Visa Token Service / Mastercard MDES 等
PANに代わるPayment Tokenを発行・管理

↓

Apple Pay / iPhone Secure Element
Device Account Number＋dynamic security data

↓ NFC / in-app

加盟店 → Acquirer → Network → Issuer
既存のカード決済railsで処理

しかしApple Pay発表の6日前、Walmartらは別の財布を発表していた

2014年9月3日。Apple Pay発表のわずか6日前に、Merchant Customer Exchange（MCX）はCurrentCを正式発表しました。

MCXはWalmart、Target、CVS、Rite Aidなど大手加盟店が参加して作ったモバイル決済陣営です。CurrentCは最終的に11万を超える加盟店拠点で使える構想を掲げていました。

CurrentCの設計思想はApple Payとはかなり違います。

NFCだけに依存せずQRコードを使い、payment、coupon、loyalty、rewardを一度のscanへまとめる。支払手段としてpersonal checking account、merchant gift card、merchant-branded credit/debit accountなどを想定していました。

そしてMCX自身が、CurrentCによって加盟店は顧客との関係を強化し、transaction dataをよりcontrolできると説明しています。

つまりCurrentCの争点は「iPhoneかQRか」だけではありません。

顧客関係、ロイヤルティ、決済データ、手数料構造をAppleやカードネットワーク側にどこまで渡すのか。

大手小売業者は、自分たちの側に決済の主導権を残そうとしていました。

この考え方は後年の説明でも確認できます。2015年12月の米下院公聴会でMCXのJessica Deckinger氏は、CurrentCによって加盟店が消費者と直接つながり、offersやloyaltyを提供しながら顧客データを保護し、決済エコシステムに「balance」をもたらすと証言しました。技術面でもQRコードだけでなくBluetooth Low Energyやgeolocationを組み合わせ、決済時には取引ごとに生成するdynamic tokenを使うと説明しています。これはMCX側の説明ですが、CurrentCが単なるQR決済アプリではなく、加盟店主導の顧客接点・データ・決済設計を狙っていたことを示す一次資料です。

2015年――Googleは、かつて競合だったキャリア陣営の資産を取り込む

Isisはその後Softcardへ改称しました。

2015年2月、GoogleはAT&T、T-Mobile、Verizonと協力し、3社が支援していたSoftcardから一部の技術と知的財産を取得すると発表します。さらに、3社が販売するAndroid端末へGoogle Walletをpre-installする方向へ進みました。

2010年には3キャリアが独自のIsisを立ち上げ、2015年にはGoogleがそのSoftcardの技術・IPを一部取得する。

モバイルwallet黎明期の主導権争いが、5年でほぼ一周したことになります。

Android Pay――Googleも「業界標準Token」へ寄っていった

2015年5月、GoogleはAndroid Payを発表します。

Googleはここで、mobile carrier、payment network、bank、retailerと協力するopen platformを強調しました。そしてsecurityの中心として、金融機関・カードネットワークとindustry-standard security tokenizationを使うことを明記しています。

店舗には実際のcredit/debit card numberを送らず、代わりにvirtual account numberを使う。

つまりGoogleも、2011年の初期Google Walletから試行錯誤した末に、Apple Payと同じくnetwork側のToken infrastructureを利用するwalletへ近づいていきました。

AppleとGoogleはwallet UXやOSでは競争を続けます。しかし下層のcredential infrastructureでは、Network Tokenという共通レイヤーが強くなっていきます。

日本では別のルートが先行していた――おサイフケータイからApple Payへ

ここまでの流れは主に米国です。しかし、日本では「携帯電話を財布にする」という利用体験が別の技術系統で、もっと早く日常へ入り始めていました。

NTTドコモは2004年6月、iモード FeliCaの商用サービス開始を発表しました。携帯電話にFeliCa用ICを搭載し、電子マネー、交通、個人認証などを携帯電話で利用できる構想です。同年7月にはJCB、イオンクレジットサービス、NTTドコモが、後払い型の非接触決済QUICPayを共同で推進すると発表しました。

2005年11月にはNTTドコモがiDを発表し、同年12月から、おサイフケータイをかざしてクレジット決済できる仕組みを開始しました。JR東日本も2005年11月、モバイルSuicaを2006年1月28日に開始すると発表しています。

つまり日本では、Apple Pay以前から「携帯電話をかざして、交通・電子マネー・後払いクレジットを使う」というUXが実用化されていました。

ただし、ここは混同してはいけません。2004〜06年のFeliCa／おサイフケータイを、2014年以降に広がるEMV Payment TokenisationやNetwork Tokenと同じ仕組みとして扱うことはできません。前者は日本のFeliCaを軸にした非接触決済・モバイルサービスの発展で、後者はPANを用途限定のpayment tokenへ置き換え、カードネットワーク側でcredential lifecycleまで管理する別の技術系統です。

この二つが大きく交差したのが2016年でした。Appleは日本向けiPhone 7とApple Watch Series 2でFeliCaに対応し、Suica、iD、QUICPayをApple Payから利用できるようにすると発表しました。Appleは同時に、クレジットカード利用時の実カード番号を端末にもAppleのサーバーにも保存せず、固有のDevice Account NumberをSecure Elementへ保存する設計を説明しています。

同年12月にはGoogleも日本でAndroid Payを開始し、まず楽天Edyに対応しました。Googleの公式発表では開始時点で国内47万以上の楽天Edy対応店舗で利用できるとされています。

日本は「携帯電話を財布にするUX」では早く進み、2016年にFeliCaの既存acceptanceとApple／カードネットワークのtokenized walletが接続した。――米国だけを見ていると見落としやすい、日本の決済史の重要な位置づけです。

銀行も黙っていなかった――Chase Pay

2015年、JPMorgan ChaseはChase Payを発表し、MCXを主要merchant partnerとしました。

当時Chaseは、issuerとして巨大なカード会員基盤を持つ一方、merchant acquiringでも大きな処理基盤を持っていました。

Chase Payの公式発表で特に目を引くのは、加盟店向けの経済条件です。

fixed pricing、$0 Network Fees、$0 Merchant Processing Fees、$0 Merchant Fraud Liabilityを掲げ、merchant loyaltyもwalletへ直接組み込むと説明しました。

これは「銀行がwalletアプリを作った」というだけではありません。発行と加盟店処理の両側を持つChaseが、その規模を使って既存のwallet・network fee economicsを別の形へ組み替えようとした試みとして読むことができます。

図4　同じ「モバイル決済」でも、取りたい主導権が違った

陣営	強み	握りたいもの
通信キャリア / Isis	契約者・SIM・端末流通	wallet、Secure Element、顧客接点
Google	Android OS・アプリ基盤	wallet UX、OS/API、デジタル購買接点
Apple	iPhone・Secure Element・Touch ID	wallet UX、端末内credential体験
Visa / Mastercard等	issuer/acquirer/acceptance network	Token Service、credential標準、既存rails
MCX / Walmart等	店舗・顧客・loyalty	merchant relationship、transaction data、fee economics
Chase	issuer＋acquirer＋大規模顧客基盤	walletとmerchant economicsの両方

※「握りたいもの」は各社の当時の公式発表・技術設計を基にした本稿の整理であり、各社がこの表現で動機を公表したものではありません。

Network Tokenはスマホの中だけでは終わらなかった

Apple Payの登場でTokenisationは一般消費者にも見える技術になりました。しかし本当の広がりは、その後のcard-on-fileです。

Visaは2015年10月、Visa Token ServiceをVisa Checkoutだけでなく、加盟店が保存するcards-on-fileへ広げると発表しました。

Netflixのようなsubscription、ECの保存済みカード、one-click merchantなどでも、PANそのものではなくNetwork Tokenを保存する方向へ進みます。

ここでTokenの価値がもう一段大きくなります。

カードを紛失して再発行し、元のPANが新しいPANへ変わっても、Token側のlifecycle managementで裏側のcredentialを更新できる場合があります。

Visa Developerの現行資料では、Token Lifecycle Managementにactivation、suspension、reactivation、deletionがあり、カード再発行時には新PANや有効期限をToken側へ反映できる仕組みが示されています。

つまりNetwork Tokenは「カード番号を隠す」だけではありません。

同じデジタルcredentialを安全に更新し続けるためのライフサイクル管理まで含むインフラになっています。

図5　Network Tokenは「番号の置換」から「credentialのライフサイクル」へ

元のPAN
カード口座の基礎credential

↓

Token Service
用途・端末・加盟店等に応じたTokenを発行

↓

Apple Pay / Google系wallet / card-on-file加盟店
実PANではなくTokenを利用

↓

カード再発行・有効期限更新

↓

Token lifecycleを更新
条件が整えば、利用者が各サービスへ新PANを再入力しなくても継続できる

2024年――今度は「iPhoneのNFCを誰が使えるか」が競争政策の論点になった

デジタルwalletの主導権争いは終わっていません。

2024年3月、米司法省と複数州はAppleを反トラスト法違反で提訴しました。司法省は訴状で、AppleがiPhoneのNFC tap-to-pay機能への第三者walletのアクセスを制限し、Apple Walletと競合するサービスの展開を妨げてきたと主張しています。

これは司法省側の訴訟上の主張であり、本稿が独自に違法性を認定するものではありません。

同年8月、AppleはiOS 18.1から、米国、日本などで、Apple PayやApple Walletとは別のアプリにもSecure Elementを使ったNFC contactless transactionを提供できるAPIを開放すると発表しました。

ただし誰でも無条件に使えるわけではなく、Appleとのcommercial agreement、NFC/SE entitlement、関連料金、セキュリティ・規制要件などがあります。

2010年代前半に争われた「誰がSecure ElementやNFCへアクセスできるのか」という問いは、形を変えながら2020年代にも続いています。

結局、カード番号は消えたのか？

消えていません。

PANはいまもカード口座の重要な基礎credentialです。PANベースの決済も多数残っています。

変わったのは、PANをどこまで外へ出すかです。

従来は、同じ16桁番号を加盟店やさまざまなシステムへ渡し、それを厳重に守ることが基本でした。

現在は、PANをより奥に残し、外側には用途を限定できるTokenを渡す。

昔の世界を「1本の万能鍵をさまざまな店へ預ける」とするなら、Network Tokenの世界は「同じ口座につながる用途限定の鍵を、端末や加盟店ごとに配る」に近い発想です。

Tokenisationで変わったのはセキュリティだけではない

Tokenisationは、カード番号漏えいリスクを下げるためのセキュリティ技術です。

しかし歴史を追うと、それだけではありません。

通信キャリアはSIMと契約者基盤を持ち、GoogleはAndroidとアプリ基盤を持ち、AppleはiPhoneとSecure Elementを持ち、Walmartなど加盟店は店舗と顧客関係を持ち、Chaseはissuerとacquirer双方の規模を持っていました。

VisaやMastercardなどのカードネットワークがToken Serviceを標準インフラとして提供したことで、wallet事業者が変わっても、その下にあるカード口座と世界中の加盟店ネットワークをつなぐ役割は維持されました。

これは本稿の分析ですが、Tokenisationは「PANを隠す技術」であると同時に、デジタル決済時代にcredentialを誰が発行・管理するのかを再配置した技術とも見ることができます。

次にネット通販やスマートフォンでカード番号を入力せず決済が終わったとき、その裏では「番号を使わない」という巨大な決済インフラが動いているかもしれません。

本人認証側の進化はVerified by VisaからEMV 3-Dセキュアまで、保存済みcredentialの仕組みはStored Credentialとカードオンファイルで詳しく整理しています。

Featured photo: Jonas Leupe / Unsplash

\n

主な出典

関連記事

• なぜ「1クリック」で買えるようになったのか？Amazonの特許戦争と「支払いの痛み」
• カードを再発行してもサブスクが続くのはなぜ？Stored Credentialとカードオンファイルの仕組み
• なぜネット通販で本人確認するのか？Verified by VisaからEMV 3-Dセキュアまで
• SuicaとVisaのタッチは同じもの？タッチ決済が広がった理由とFeliCa・EMVの違い