公開2026.07.26更新2026.10.01 開発

決済トークンとは？トークナイゼーションの仕組みと暗号化との違い・実装方式を開発視点で解説

決済トークンとは、クレジットカード番号の代わりにシステム間で受け渡す、それ自体には意味のない値です。カード番号を別の値へ置き換えて保護する手法をトークナイゼーション（トークン化）と呼び、決済トークンはその成果物にあたります。この記事では定義から一歩踏み込み、トークンボールトの仕組み、ワンタイムトークンと保存用トークンの違い、よく混同される暗号化との設計上の違い、加盟店側トークン化とネットワークトークナイゼーションという2つの方式、ボールト型とボールトレス型の実装、そしてPCI DSS準拠範囲の縮小や割賦販売法の非保持化まで、開発者・技術選定者が導入可否を判断できる粒度で整理します。読み終えると、どこまで内製し、どこから受託開発に委ねるかを判断できる内容です。

まとめ｜決済トークナイゼーションの仕組みと採用判断の要点

トークナイゼーションは、カード番号などの生データを保持せず、代わりに無意味なトークンだけをシステムで扱う設計です。元データとトークンの対応はトークンボールトと呼ばれる保護された領域で管理し、決済や返金など元の値が必要な場面だけボールトを経由して取り出します。トークンが漏えいしても、そこから元のカード番号を算出できないため、被害を抑えられる点が最大の狙いです。

「決済トークン」と呼ばれる値は、寿命の異なる3種類に分かれます。決済画面で受け取る1回限りのトークン、顧客に紐づく保存用トークン、カードネットワークが発行するネットワークトークンです。

決済領域では方式が大きく2つに分かれます。加盟店やゲートウェイ側で行うトークン化は、自社サーバーがカード番号に触れない構成にしてPCI DSSの準拠範囲を縮小するのが主目的です。もう一方のネットワークトークナイゼーションは、カードネットワーク（EMVCo）がトークンを発行し、Apple PayやGoogle Payのようなモバイル決済で使われ、カード再発行時の自動更新や承認率の改善といった付加価値を持ちます。採用判断の分岐点は「準拠負担の軽減が目的か、決済体験や承認率の改善まで狙うか」で、要件が複雑になるほど決済システム全体の設計や受託開発を挟む価値が出ます。

ただしトークン型でも、決済ページを改ざんされればカード番号は抜かれます。

トークナイゼーションとは何か｜決済のカード情報を守る基本の考え方

トークナイゼーションは、守りたい機密データそのものをシステム内に残さないという発想の技術です。暗号化のように「守りながら持つ」のではなく、「そもそも持たない」ことでリスクの総量を下げます。決済に限らず個人情報やマイナンバーの保護にも使われますが、実務での主戦場はクレジットカード番号の保護です。

トークナイゼーションの定義とトークンボールトが果たす基本的な役割

トークナイゼーションの中核は、機密データ（決済ならカード番号PAN）を、それ自体に意味のないトークンへ置き換える処理です。元データとトークンの対応関係は、トークンボールトと呼ばれる厳重に保護された専用領域だけが保持します。業務システムやアプリケーションはトークンだけを保存・伝送し、実際のカード番号が必要になる決済・返金といった場面でのみ、ボールトを経由して元の値を取り出す構成になります。カード番号の保管点をボールト1か所に集約できるため、守るべき範囲を絞り込めるのが設計上の利点です。トークンは元データと同じ桁数・書式を保つ「書式保持型」にもでき、既存システムの改修を小さく抑えられます。

クレジットカード決済でトークン化が広く使われるようになった背景

カード情報を扱う事業者は、漏えい時の被害と法令・業界基準への対応という二重の負担を抱えます。トークン化が決済で選ばれるのは、この両方を同時に軽くできるからです。国際的なカードデータ保護基準であるPCI DSSは、トークン化を準拠範囲を縮小する手段として位置づけ、専用のPCI DSS Tokenization Guidelines（2011年8月版）も公開しています。日本でも改正割賦販売法（2018年6月施行、概要は経済産業省のクレジット取引のページ）でカード情報の適切な管理が加盟店の義務となりました。実務指針のクレジットカード・セキュリティガイドラインは2026年10月時点で6.1版（2026年3月）が最新で、トークン化はその非保持化を実現する代表的な手段です。

決済トークンとは何か｜ワンタイムと保存用・ネットワークの3種を整理

「決済トークン」が指す値は文脈で変わります。発行者と寿命で切り分けます。

JavaScript型（トークン型）で発行されるワンタイム決済トークンの役割

国内のECで「トークン決済」と言えば、多くはJavaScript型を指します。ガイドライン6.1版は非保持化の方法を「通過型」と「非通過型」に分け、非通過型の例に「リダイレクト（リンク）型」と「JavaScript型（トークン型）」を挙げています。JavaScript型は、決済画面に組み込んだPSPのJavaScriptがカード番号をPSPへ直接送り、引き換えにトークンを受け取る方式です。

サーバーはこのトークンをPSPのAPIへ渡して決済を依頼します。StripeのTokens APIも、カード情報を顧客から直接収集し、代わりにトークンをサーバーへ返す処理としてトークン化を説明しています。この種のトークンは多くのPSPで使い切りです。ただし二重送信は二重課金の入口になるため、冪等キーによる二重課金の止め方と組み合わせます。

顧客に紐づける保存用トークンとネットワークトークンの寿命と扱いの差

カードを再入力させないために、PSPは顧客ごとに保存用トークン（Stripeならcus_の顧客とpm_のPaymentMethod）を発行します。長期間有効で、何度でも課金に使えます。

種類	発行者	寿命の目安	漏えい時の影響
ワンタイム決済トークン	PSP	1回の決済で消費	再利用はほぼ不可
保存用トークン	PSP	顧客の削除まで	秘密鍵と組で課金可能
ネットワークトークン	カードブランド	カード更新で継続	加盟店や端末に限定

急所は表の2行目です。PCI SSCのガイドラインは、それ自体で取引を起こせるトークンを「high-value token」と呼び、不正検知の追加統制を求めています。保存用トークンもPSPのシークレットキーと揃えば課金できる。だからキーはAWS KMSのような鍵管理サービスやシークレットストアに置き、トークンを保存するDBとは権限を分けます。定期課金での使い方はサブスクリプション課金とオフセッション決済の実装で扱っています。

トークナイゼーションと暗号化の違い｜復号できるかどうかで見分ける

トークン化と暗号化はどちらもデータ保護技術ですが、設計思想は根本的に異なります。両者を混同すると、準拠範囲の見積もりや事故時の影響評価を誤りかねません。違いの核心は「元データへ戻す方法」にあります。

復号できる暗号化とマッピングで元に戻すトークン化の設計上の差

暗号化は、鍵とアルゴリズムを使って元データを別の値へ変換する可逆的な処理です。正しい鍵があれば復号して元データに戻せるため、暗号文と鍵が揃えば元の値を算出できます。共通鍵と公開鍵の違いは暗号化とは何かで体系的に整理できます。一方トークン化は、元データとトークンの間に数学的な関係を持たせず、ボールト内の対応表（マッピング）を照合してはじめて元の値に戻す仕組みです。トークン単体をいくら解析しても元のカード番号は導き出せないため、復号を前提とする暗号化より、漏えい時に元データへたどり着かれにくい性質を持ちます。PCI SSCもスコープ外の条件に「トークンからPANの復元が計算上不可能」を挙げています。

暗号化とトークン化を使い分ける判断の基準と実務での組み合わせ方

実務では、両者を排他ではなく役割分担で組み合わせます。トークン化は、カード番号のように「決まった書式で、参照はするが演算はしない」データの保護に向き、保管点を絞って準拠範囲を縮小したい場面で力を発揮します。暗号化は、通信経路の保護（TLS）や、復号して処理する必要がある大量の文書・ファイルの保護に向く技術です。決済システムでは、通信路をTLSで暗号化しつつ、保存するカード情報はトークン化する、というように層で使い分けるのが定石です。「戻して使うか、参照だけか」「保管点を1か所に集約したいか」を基準に選ぶと、判断を取り違えません。

決済トークナイゼーションの2つの方式と目的別の使いどころの違い

決済のトークン化は、誰がトークンを発行するかで性格が分かれます。準拠負担の軽減を狙う加盟店側の方式と、決済体験そのものを底上げするネットワーク側の方式です。両者は競合ではなく、目的に応じて併用します。

加盟店側トークン化とカードオンファイルでの再利用の基本の流れ

加盟店やゲートウェイ（決済代行）側で行うトークン化は、カード番号を自社サーバーに通さない構成をつくり、PCI DSSの準拠範囲を縮小するのが主目的です。典型的な流れでは、ブラウザやアプリから入力されたカード情報をゲートウェイへ直接送ってトークン化し、自社サーバーはトークンIDだけを受け取って決済を実行します。このトークンを顧客に紐づけて保存しておけば、次回以降はカード番号を再入力させずに決済できる「カードオンファイル」が実現し、定期課金やワンクリック購入の基盤になります。Stripeなどの決済プラットフォームでは、この加盟店側トークン化が標準の実装パターンです。与信枠の確保と売上確定を分ける処理はオーソリ（決済オーソリゼーション）の考え方と組み合わせて設計します。

ネットワークトークナイゼーションとモバイル決済での仕組みと利点

ネットワークトークナイゼーションは、Visa・Mastercard・JCB・American Express・Discover・UnionPayで構成されるEMVCoが策定したEMV Payment Tokenisationの仕様に基づき、カードネットワーク側がトークンを発行する方式です。Apple PayやGoogle Payでスマートフォンに登録するのは実カード番号ではなく、デバイス固有のトークン（DPAN）で、元の資金元カード番号（FPAN）はネットワークとトークンサービスプロバイダが保護します。ネットワークトークンは、加盟店・ドメイン・デバイスといった利用文脈にバインドされるため、仮に流出しても他の文脈では使えません。さらに、カードの有効期限切れや再発行時にトークンが自動更新されるため定期課金の失敗が減り、承認率の改善や3Dセキュア2.0での認証の摩擦低減といった効果も見込めます。本人認証はEMV 3-Dセキュア2.0の認証フローを参照してください。準拠範囲の縮小に加えて決済成功率や体験まで底上げしたい場合に選ぶ方式です。

トークナイゼーションの実装アーキテクチャと生成方式選択の要点

方式を決めたら、次はトークンをどう生成し、どこに置くかという実装設計です。ここでボールトの持ち方を誤ると、後から可用性や運用負荷の問題として跳ね返ります。フロー・API呼び出し・生成方式を押さえます。

決済トークン化の基本的な処理フローとシステム連携の設計の要点

トークン化の処理は、次の流れで組み立てます。カード番号を自社の業務ロジックに一切通さないことが、準拠範囲を小さく保つ設計の要点です。

取得と送信：入力されたカード情報を、業務サーバーを経由させずトークン化サービスへ送ります。
トークン生成：サービスがカード番号をボールトへ格納し、対応するトークンを発行して返します。
保存と利用：業務システムはトークンだけを保存し、注文・顧客・課金の各データに紐づけて扱います。
元データの参照：決済や返金で実カード番号が必要なときだけ、認可された処理がボールトを経由して元の値を取り出します。

設計時は、ボールトへのアクセスをどのサービスに許可するかというアクセス制御と、ボールト障害時のフォールバックを必ず織り込みます。ボールトは決済の生命線となるため、可用性と監査ログの設計が運用品質を左右する要素です。既存の基幹システムや会計との連携までを見据えるなら、トークンをキーにしたデータ設計を初期段階から固めておくと、後戻りを避けられます。非同期の結果通知は決済Webhookの署名検証と冪等な注文確定を参照してください。

Stripeのテスト用トークンで決済を作るcurlとトークン保存テーブル例

サーバーがカード番号を見ずに決済できることは、テスト環境ですぐ確かめられます。Stripeのテストカードのページは、テストコードではカード番号でなくpm_card_visaのようなPaymentMethodを使うよう案内しています。次はPaymentIntent作成APIにテスト用トークンを渡して、1,000円の決済を即時確定させる例です。

# テスト環境のシークレットキー（sk_test_ で始まる値）を環境変数に置く
export STRIPE_SECRET_KEY=sk_test_xxxxxxxxxxxxxxxx

# カード番号の代わりに、テスト用の決済トークン pm_card_visa を渡す
curl https://api.stripe.com/v1/payment_intents \
  -u "${STRIPE_SECRET_KEY}:" \
  -d amount=1000 \
  -d currency=jpy \
  -d payment_method=pm_card_visa \
  -d confirm=true \
  -d "automatic_payment_methods[enabled]=true" \
  -d "automatic_payment_methods[allow_redirects]=never"

円は小数のない通貨なのでamount=1000が1,000円です。応答のstatusがsucceededなら、トークンだけで決済が完了しています。本番では決済画面から受け取ったトークンがここに入ります。

保存テーブルはトークンと表示用の値だけを持たせます（PostgreSQL）。

CREATE TABLE customer_payment_methods (
  id                  BIGSERIAL    PRIMARY KEY,
  customer_id         BIGINT       NOT NULL REFERENCES customers(id),
  psp_customer_id     VARCHAR(64)  NOT NULL,  -- 例: cus_xxxx
  psp_payment_method  VARCHAR(64)  NOT NULL,  -- 例: pm_xxxx（保存用トークン）
  card_brand          VARCHAR(20),            -- visa / mastercard / jcb など表示用
  card_last4          CHAR(4),                -- 下4桁のみ
  exp_month           SMALLINT,
  exp_year            SMALLINT,
  card_fingerprint    VARCHAR(64),            -- 同一カードの重複登録を検知する値
  created_at          TIMESTAMPTZ  NOT NULL DEFAULT now(),
  UNIQUE (customer_id, card_fingerprint)
);
-- カード番号・セキュリティコードを入れる列は作らない

ブランドや下4桁はPaymentMethodオブジェクトのcard属性から取得できます。カード番号の列を最初から作らなければ、「念のため保存」は紛れ込みません。

ボールト型とボールトレス型のトークン生成方式の選び分けの基準

トークンの生成方式は、対応表を保持するボールト型と、保持しないボールトレス型に大別されます。ボールト型は、元データとトークンの対応をデータベース（ボールト）に記録する方式で、任意のランダム値をトークンにできる反面、ボールトの規模が大きくなるほど検索性能と可用性の設計が問われる方式です。ボールトレス型は、書式保持暗号（FPE）などのアルゴリズムでトークンを生成し、大きな対応表を持たずに元データへ戻せる方式で、スケールしやすい一方でアルゴリズムと鍵の管理が安全性の中心になります。FPEはNIST SP 800-38G（2016年3月）がFF1とFF3を定めていますが、2025年2月のRev.1第2次公開草案でFF3は削除されました。自前で組むならFF1が前提です。処理量が読みやすく監査要件が厳しいならボールト型、大量・高スループットで拡張性を優先するならボールトレス型、と要件から選ぶのが実務的です。多くの決済代行サービスは、この選択を自社基盤内に隠蔽して提供しています。

PCI DSSの準拠範囲を縮小するトークン化の効果と導入判断の軸

ここからは判断を言い切ります。トークナイゼーションは万能ではなく、正しく組めば準拠負担を大きく下げますが、組み方を誤ると効果が出ません。導入判断の軸を具体化します。

カード情報の非保持化とPCI DSSの準拠範囲を縮小する仕組み

トークン化の最大の実務効果は、カード番号を「保持・伝送しない」状態をつくり、PCI DSSの準拠範囲（スコープ）を縮小できる点にあります。PCI DSSは、カード会員データを扱うシステムを対象に12要件の対策を求める国際基準で、2026年10月時点の現行版はv4.0.1系です（PCI SSC Document Library）。カード番号を直接扱う場合、Stripeのセキュリティガイドによれば300を超える管理策が対象になりえます。カード番号をゲートウェイ側でトークン化し、自社がトークンしか持たない構成にすれば、自社環境の多くをスコープ外へ寄せられます。要件の全体像と準拠レベルはPCI DSSとは何かで確認が可能です。ただし、トークン化サービスへの連携部分やボールトへのアクセス経路はスコープに残るため、「トークン化すれば対応ゼロ」ではない点に注意が必要です。国内では改正割賦販売法が求める非保持化の実現手段としても、この構成が標準になっています。

トークン型でも漏えいが起きる失敗パターンと自社導入を見送る場面

トークン型にしたのにカード情報が漏れる。ガイドライン6.1版は、非保持化を実現した加盟店でも脆弱性対策の不備による漏えいが発生していると明記しています。典型は、決済画面のJavaScriptを書き換え、PSPへ送る前のカード番号を横取りする手口です。トークン化は入力画面の改ざんを防げません。

失敗パターンを重い順に並べます。

決済画面や管理画面の改ざんを検知できない
保存用トークンとPSPのキーが同じ権限で読める
「通過型」の旧実装が管理画面などに残っている
カード番号の入力値をログへ出力している

逆に、自前のトークンボールト構築は見送ってよい場面がはっきりあります。物販や定期課金の標準的な決済だけを扱い、カード会社やPSPからカード情報の還元を受ける要件がないなら、ボールトを自社で持つ理由はありません。還元を受けて自社で保存・処理・通過を行えば「保持」となり、PCI DSS準拠が必要になるからです。浮いた工数は決済画面の改ざん対策へ回します。

内製での実装と受託開発を分ける判断軸と外注が向く具体的な局面

内製と受託開発の分岐点は「決済フローに独自要件がどれだけあるか」です。決済代行が提供する加盟店側トークン化に素直に乗り、標準的なカードオンファイルで済むなら、実装は内製で十分に回せます。一方で、複数事業者への売上分配、既存の基幹システムや会計とのトークン連携、ネットワークトークンを使った承認率改善の作り込み、ボールトの可用性・監査要件までが絡むと、初期の設計品質がその後の事故率と改修コストを大きく左右する局面になります。ここは決済とシステム連携の設計経験がある体制で固めたほうが安全です。要件が重い決済・サブスクリプションの構築は決済・サブスクリプションシステムの受託開発で設計から相談でき、内製で走り出しつつ難所だけ外部の設計を挟む進め方も有効です。

トークナイゼーション導入でよくある質問｜暗号化との違いや安全性

決済トークンとトークナイゼーションの検討でよく挙がる質問に、開発・準拠・セキュリティの観点から簡潔に答えます。

トークナイゼーションと暗号化は何が違うのですか？

暗号化は鍵で元に戻せる可逆的な変換で、暗号文と鍵が揃えば元データを算出できます。トークン化は元データとの数学的な関係を持たず、ボールト内の対応表を照合しないと元に戻せません。そのためトークン単体からは元のカード番号を導けず、漏えい時に元データへたどり着かれにくいのが違いです。実務では通信路の暗号化と保存データのトークン化を層で組み合わせます。

トークン化すればPCI DSSの対応は不要になりますか？

不要にはなりませんが、対象範囲を大きく縮小できます。カード番号をゲートウェイ側でトークン化し、自社がトークンしか保持しない構成にすれば、自社環境の多くをスコープ外へ寄せられます。ただしトークン化サービスとの連携部分やボールトへのアクセス経路は準拠範囲に残るため、その部分の要件対応は引き続き必要です。決済画面の改ざん対策など、非保持化後も残る脆弱性対策も同様です。

決済トークンとは何ですか？ネットワークトークンとは違うのですか？

決済トークンは、カード番号の代わりに決済処理で受け渡す値の総称です。決済代行が発行するワンタイムトークンと保存用トークンは、主に自社の準拠範囲を縮小する目的で使います。ネットワークトークンは、EMVCoの仕様に基づきカードネットワークが発行し、Apple PayやGoogle Payで使われ、カード再発行時の自動更新や承認率の改善といった付加価値を持ちます。両者は排他ではなく、目的に応じて併用する関係です。

トークナイゼーションは自社で実装できますか？

標準的な用途なら、決済代行が提供する加盟店側トークン化に乗って内製で実装できます。ボールトを自前で構築する選択もありますが、可用性・監査・鍵管理の負担が大きいため、多くの事業者は決済代行の基盤を利用します。分配や基幹連携など独自要件が重い場合は、設計段階で受託開発を挟む判断が現実的です。

トークンが漏えいしても本当に安全なのですか？

トークン単体からは元のカード番号を算出できないため、そのままでは不正利用につながりにくい設計です。ネットワークトークンは利用文脈にバインドされるため、別の加盟店やデバイスでは使えません。保存用トークンはPSPのキーと揃えば課金できるため、キーの保管場所は分けます。ボールトへのアクセス経路やトークンと決済処理の連携部分も守るべき対象として残るので、アクセス制御や監査ログと組み合わせて運用します。