inSmartBank

AI家計簿アプリ「ワンバンク」を開発・運営する株式会社スマートバンクの Tech Blog です。より幅広いテーマはnoteで発信中です https://note.com/smartbankinc

カード番号を扱わずに決済を成立させる仕組み ── トークナイゼーション入門

Engineering

こんにちは。スマートバンク 新春エンジニア駅伝 2026の十七区走者のkurisuです。借りるチームであとばらいや決済システムの開発・運用をしております。

十六区走者は、kaoruさんによる、「続・戦略と実行を爆速でつなぐデータ活用の現在地: LLM 編」でした。私も普段の業務でAskワンバンをかなり使わせてもらっております。本当に甘やかされて仕事をしております。

blog.smartbank.co.jp

Google Payなどのモバイル端末にカードを登録すると、そのカード番号がスマートフォンに保存されると思いませんか？——実は、Google Payにカード番号（PAN）は保存されていません。

代わりに保存されているのは「トークン」と呼ばれる別の番号です。このトークンを使って決済を成立させる仕組みがトークナイゼーションです。

本記事では、カード決済を例に、トークナイゼーションの仕組みを入門編として解説します。

前提：カード決済と登場人物

用語説明

  • イシュア（Issuer）: カードを発行する会社
  • アクワイアラ（Acquirer）: 加盟店と契約し、決済を処理する会社
  • PAN（Primary Account Number） : カード番号。
  • BIN（Bank Identification Number）: カード番号の最初の6〜8桁。発行会社を識別する
  • オーソリゼーション: 加盟店がカードの有効性を確認し、決済予定金額分の利用枠（与信枠）を確保すること。ワンバンクのようなプリペイドカードの場合は、オーソリゼーションによってアプリ内の残高が、即時差し引かれる仕組みになっている。

カード決済の流れ

EMVペイメントトークンの役割を理解するために、まずはPANでのクレジットカード決済（オーソリゼーション）の流れをおさらいします。

以下の流れでオーソリゼーション処理が実行されています。

  flowchart LR
      A[加盟店] -->  C[アクワイアラ] --> D[国際ブランド<br/>ネットワーク] --> E[イシュア]

決済システムについて興味のある方は弊社の過去記事『B/43カード決済システムのしくみ（前編）』をご参照ください。

トークナイゼーションとは

カード決済におけるトークナイゼーションとは、機密性の高いPANを、別の値（トークン）に置き換える仕組みです。第三者に盗まれても復元が不可能な「無価値なデータ」となり、情報漏洩時のリスクを大幅に低減することを目的にしています。

なお、類似の概念として暗号化やハッシュ化がありますが、トークン化はこれらとは異なります。1

トークンの発行主体によって、以下３種類に分類できます。

種類 発行主体 フォーマット トークンの利用例 特徴
アクワイアラトークン アクワイアラ・加盟店 独自の値 ECサイトなど 外部ネットワークには出られない
イシュアトークン イシュア PANと同じフォーマット（イシュアのBINが付与される） バーチャルカードなど 通常のPANと大きな差分はなし
EMVペイメントトークン TSP（詳細は後述します） PANと同じフォーマット（トークンのBINが付与される） Google Payや、ECサイトなど 規格に基づいて作られた国際ブランドのトークンを「ネットワークトークン」と呼んだりする

カード決済時のPAN/トークンの変換位置を図示すると以下の通りです。

アクワイアラトークンは、加盟店・アクワイアラでトークンとPANを変換・利用しているトークンなので、決済ネットワークにはPANが流れます。 一方、EMVペイメントトークンの場合は、決済ネットワークにて、(次項で説明する)TSPがトークンとPANの変換を行います。

本記事では、これら3種のうち Google Payにも利用されている EMVペイメントトークンに焦点を当て、他の2種は位置づけの理解に留めます。

以下、EMVペイメントトークンについて紹介していきます。

EMVペイメントトークンとは

EMVペイメントトークンとは、EMV2 規格によって定義された、実際のカード番号（PAN）を置き換える13〜19桁の数値です。

このトークンを発行・管理しているのが、TSP（Token Service Provider） と呼ばれる機関です。

TSP（Token Service Provider）の役割
TSPは、トークンの発行・管理・および実際のPANとの紐付け（変換）を安全に行うための許可された事業体です。一般的には、国際ブランドや決済ネットワーク事業者がこの役割を担い、決済ネットワークの裏側で「どのトークンがどのPANに対応するか」を厳重に管理しています。

EMVペイメントトークンには、主に以下のような特徴があります。

PANとの互換性

実際のPANと同じ桁数・形式であり、クレジットカード番号の妥当性をチェックする「Luhnアルゴリズム（チェックデジット）」3も通過するため、既存の決済端末やネットワークシステムでそのまま処理することが可能です。

PANとの違い

見た目はPANに似ていますが、実際の口座番号とは異なる値であり、トークン単体では元のPANを推測することはできません。また、トークン用に指定されたBIN範囲（Token BIN Range）から発行されるため、システム上でPANと区別されます。

また、トークンは、1つのPANに対して複数発行されます。

トークンドメイン制御（Token Domain Restriction Controls)

通常PANは対面・非対面問わずどこでも使用可能ですが、トークンの場合、トークンドメイン制御機能によって、「特定のデバイス」・「特定の加盟店」・「特定の取引形態」以外では利用できないように制御されます。これにより、EMVペイメントトークンが漏洩しても許可されているドメイン外では無効となり不正利用を防ぐことができます。

以下具体例です。

flowchart TB
    %% --- TSP内部：静的な設定情報 ---
    subgraph TSP_System ["<b>TSP: トークン保管庫 (Token Vault)</b>"]
        direction TB
        Vault_Token[("<b>発行済みトークン</b><br/>Token: 5000 1234...")]
        
        subgraph TDRC_Config ["<b>TDRC設定 (制約ルール)</b>"]
            direction TB
            Rule_Merch["<b>加盟店制限</b><br/>(Merchant Specific)<br/>例: A加盟店でのみ利用可"]
            Rule_Device["<b>デバイス制限</b><br/>(Device Specific)<br/>例: 登録済みスマホAのみ"]
            Rule_Mode["<b>提示モード制限</b><br/>(Presentment Mode)<br/>例: NFC/非接触のみ"]
            Rule_Limit["<b>回数・用途制限</b><br/>(Limited Use)<br/>例: 1回限り/ゲスト購入"]
        end
        
        Vault_Token --- TDRC_Config
    end

    %% --- 決済時：動的な入力情報 ---
    subgraph Transaction ["<b>決済リクエスト (Token Processing)</b>"]
        direction TB
        Input_Token["<b>提示されたトークン</b><br/>Token: 5000 1234..."]
        
        subgraph Control_Fields ["<b>トークン・コントロール・フィールド</b>"]
            Field_Merch["<b>加盟店ID</b><br/>B加盟店(不一致)"]
            Field_Crypto["<b>トークン検証</b><br/>例: スマホBで生成 (検証失敗)"]
            Field_Mode["<b>POS入力モード</b><br/>例: Eコマース (不一致)"]
        end
        Input_Token --- Control_Fields
    end

    %% --- 検証ロジック ---
    Transaction --> Validator{"<b>トークンドメイン制御 検証実行</b>"}
    TSP_System --> Validator

    %% --- 判定結果 ---
    %% 以下の矢印ラベルをダブルクォーテーションで囲み修正しました
    Validator -- "<b>不一致 (Violations)</b><br/>・加盟店が許可リストにない<br/>・トークンの検証が無効<br/>・入力モードが異なる" --> Block["<b>× 拒否 (Decline)</b><br/>不正利用として遮断"]
    
    Validator -- "<b>完全一致 (Match)</b><br/>すべての制約条件をクリア" --> Approve["<b>○ 承認プロセスへ</b><br/>PANへ変換(De-Tokenisation)"]

    %% --- スタイル ---
    classDef vault fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
    classDef tx fill:#fff3e0,stroke:#e65100,stroke-width:2px;
    classDef rule fill:#ffffff,stroke:#333,stroke-dasharray: 5 5;
    
    class TSP_System,Vault_Token vault;
    class Transaction,Input_Token tx;
    class Rule_Merch,Rule_Device,Rule_Mode,Rule_Limit,Field_Merch,Field_Crypto,Field_Mode rule;

EMVペイメントトークンはどこに使われているか

ユーザから見るとPANでやりとりしているように見えるものが、実はトークンでやりとりされています。

対面決済（Proximity at Point of Sale）

冒頭の例にも挙げたGoogle Payを使ったモバイルウォレットでの決済です。

デバイスにはPANではなく、トークンが保存されています。

アプリ内決済（In-Application Payment）

スマホアプリの中で、外部のウォレットアプリを呼び出して支払うケースです（例：配車アプリやフードデリバリーアプリでの決済）。こちらもウォレットに保存されているトークンを利用します。

Eコマース / Card-On-File

実はGoogle Payなどのモバイル端末以外にも、普段利用しているECサイトやサービスでも利用されています。加盟店がユーザーのカード情報を保存してサブスクリプションなどで再利用するケースです。加盟店やアクワイアラがPANではなく、トークンを保持し管理します。

ゲストチェックアウト（E-Commerce Guest Checkout）

会員登録をせずに、その場限りの買い物をするケースです。

アカウントを作成せず、1回限りの取引のためにカード情報を入力します。入力されたカード情報は即座にトークン化され、決済に使用されます。

このようにトークナイゼーションの仕組みは、様々なカード決済の裏側で利用されてきています。

トークナイゼーションの流れ

トークナイゼーションの流れをご紹介します。

主な関係者

関係者 概要 特徴 具体例
Token Requestor EMVペイメントトークン発行を依頼する事業者 Token Requestorには一意のToken Requestor ID（TRID）が割り当てられ、トークン発行時に記録される Google Pay、EC加盟店など
TSP（Token Service Provider） EMVペイメントトークンの発行管理を行う。PANのトークナイゼーション・デトークナイゼーションを行う 各国際ブランドや、承認されたサードパーティが運営。 VTS(Visa Token Service)など
Card Issuer カード発行会社 ワンバンク

トークンの処理を3つに分けて説明します。

  • トークン発行
  • トークン決済
  • トークン管理

トークン発行

Google Payを例にしてみます。

  • ①：ユーザから入力されたカード情報をTokenRequestorが受け取る
  • ②：TokenRequestorがTSPにカード情報を渡しトークン発行要求を行う
  • ③：TSPからイシュアへ対象カードとデバイスに対するリスク判定を依頼
  • ④：イシュアからTSPにリスク判定の結果を返却する
  • ⑤：承認されればトークンBINからトークンを発行し、TokenRequestorにトークンを返却
  • ⑥：モバイル端末(or クラウド) にトークンを保存する

トークンは1つのPANに対して、複数のトークンを発行できます。例えば、同一カードでもAndroid端末用、EC用など、Token Requestorやデバイスごとに異なるトークンが発行されます。 そのため、同じカードを複数デバイスで発行した場合、ウォレット上では同じ表示ですが、データとしては異なるトークンのデータが表示されています。　　

トークン決済

アプリ内決済を例にします

  • ①：モバイル端末から決済を開始する。加盟店にトークンが渡される
  • ②：加盟店(+アクワイアラ)から決済ネットワークにトークンが渡される。
  • ③：決済ネットワークからTSPにトークンを送る
  • ④：TSPがトークンをPANに変換し、決済ネットワークにPANを返却する
  • ⑤：決済ネットワークからイシュアにPANが渡るので、イシュアはオーソリゼーションを処理する
  • ⑥：オーソリゼーション結果を返す

TSPが、決済ネットワークでEMVペイメントトークンとPANを透過的に変換するため、他システムから見るとPANの決済と大きな差分なくやり取りができます。

トークン管理

TSPがトークンのステータスを管理し、TokenRequestor・イシュアはそのトークンのステータスを見て処理を行います。

  • ①例：ウォレットからトークンを削除
  • ②例：物理カードが再発行されたので、トークンを新しいカードに着ける
    • この対応をイシュアが行うことでユーザーがカード情報を手動で更新する必要がなくなります
操作 説明 トリガー例
トークン更新 再発行したカードにトークンを紐づける/カード情報の更新 カード更新
トークン一時停止 一時的にトークンを無効化 デバイス紛失報告
トークン再開 停止したトークンを再有効化 デバイス発見
トークン削除 トークンを完全に無効化 カード解約、ウォレット削除

トークンとカードの取り扱いはイシュアによって異なります。「カードが一時停止でも、トークンが有効であれば決済が成功する」というようなイシュアもあったりします。ワンバンクでは、ワンバンクのカードが一時停止になっていたら基本的にはトークンも一時停止になりステータスが同期されるようになっています。

EMVペイメントトークンにおけるカード決済のメリット

EMVペイメントトークンには以下のようなメリットがあります。

セキュリティと不正防止

  • PANの秘匿化: 実際のPANの代わりにトークンを使用するため、加盟店や決済ネットワーク上でPANが露出・保存されるリスクを排除できます。
  • 利用範囲の限定 (TDRC): トークンは「特定のデバイス」「特定の加盟店」「特定のチャネル」でのみ有効になるよう制限されています。万が一トークン情報が盗まれても、攻撃者は別の環境（別の加盟店やデバイスなど）では使用できないため、不正利用のリスクが極小化されます。
  • データ侵害時の無力化: トークンは元のPANへ復号できないため、漏洩しても決済に悪用されづらいです。また、漏洩したトークンのみを無効化すれば済むため、カード番号（PAN）自体を変更・再発行する必要がありません。

ユーザー体験

  • 自動更新（Lifecycle Management）: 物理カードが紛失・盗難、あるいは有効期限切れで再発行されPANが変わった場合でも、イシュアー起因で、トークンサービスプロバイダ（TSP）が裏側で新しいPANと既存のトークンを紐付け直します。これにより、サブスクリプションなどで登録済みのカード決済において、ユーザーがカード情報を手動で更新する必要がなくなり、決済エラーによるサービス中断を防げます。
  • カゴ落ちの防止: アプリ内決済などにおいて、カード番号入力の手間を省き、スムーズな決済体験を提供することで、決済途中での離脱を減らす効果があります。

単に番号を変えるだけでなく、「漏洩しても悪用できない仕組み（TDRC）」と「カード番号変更の影響を受けない仕組み（ライフサイクル管理）」をセットで提供することで、エコシステム全体にメリットをもたらしています。

まとめ

本記事では、EMVペイメントトークンを中心に、カード決済におけるトークナイゼーションの仕組みを解説しました。

トークナイゼーションは、単にカード番号を別の番号に置き換えるだけの仕組みではありません。

  • TSPがトークンとPANを管理し、決済ネットワーク上でシームレスにPAN/トークンの変換を行う
  • トークンドメイン制御（TDRC）により、「どこで・どのように使えるか」まで制御できるため不正が低減される
  • 1つのPANに対して複数のトークンを発行でき、個別に管理できる

これらの仕組みにより、セキュリティの向上だけではなく、カード再発行時の再登録不要、端末紛失時のカード再発行不要といった体験が実現されています。

明日の駅伝第十八区走者はモバイルアプリ部部長のkanekoさんです！お楽しみに！

参考資料

  1. 暗号化・ハッシュ化・トークン化との差分は以下の表をご確認ください。

    手法 特徴 可逆性
    暗号化 鍵とアルゴリズムで変換 復号可能
    ハッシュ化 一方向関数で固定長に変換 不可逆
    トークン化 元データと無関係な値に置換し、対応表で管理 対応表を持つ者のみ復元可能
    ↩
  2. Europay/MasterCard/Visaの頭文字をとってEMVです。EuropayはMastercardと合併しました。 詳しくは、「Why EMV」をご参照ください。↩
  3. Luhnアルゴリズムについては、弊社記事の「クレジットカード番号の混入を防ぐ技術 」をご参照ください。↩
We create the new normal of easy budgeting, easy banking, and easy living.
In this tech blog, engineers and other members will share their insights.