クレジットカード番号の一部保存のリスク見積もり
クレジットカード番号の「先頭6桁と下4桁」は、PCI DSS で画面への表示が認められている形で、通販システムでもよく保存されています。 2026年10月には、BASE の子会社 Eストアーの「ショップサーブ」から約 210 万人分のこの形の番号が、名義・有効期限とともに漏れたと発表されました。
このツールは、番号の一部から全部の数字を復元しようとすると何通りになるのかを計算します。 PCI DSS で認められている保存の規定が安心できるものか確認してみましょう。 また、保存する桁を減らすと候補がどれだけ増えるかを確かめ、その桁を本当に保存する必要があるかを考えてみましょう。
保存する桁を選ぶ
桁を押すと、保存する（数字）と隠す（*）が切り替わります。
番号全体から絞り込むと
* BIN の件数について
- 公開の BIN データベース（binlist）の件数を目安にしたもので、正確ではない可能性があります。
- 16 桁の番号を前提にしています。15 桁（American Express）など 16 桁以外の番号は使われている BIN が少ないため、実際の組み合わせはこの数より少なくなります。
- BIN の一部だけが漏洩したときの件数は、見えている桁 1 つごとに 10 分の 1 にした単純な計算です（例: 先頭 1 桁だけが見えていれば 34万 ÷ 10 = 3.4万件）。実際の BIN は先頭の数字ごとに偏っていて（4 は Visa、5 は Mastercard など）、見えている数字によって、この数より多くも少なくもなります。
ほかの秘密との比べ方
入力した形の候補の数を、推測されにくさの目安になるものと並べます。
| もの | 候補の数 | 情報量 |
|---|
推測されにくいパスワードは、パスワード生成で作れます。サイトの条件（文字数・文字種・使える記号）に合わせて、Web ブラウザの中だけで作ります。
計算のしかた
- 隠れた桁が n 桁あれば、数字の並びは 10n 通りです。
- クレジットカード番号の最後の 1 桁は、ほかの桁から計算するチェックディジット（Luhn）です。下 4 桁を保存すると、チェックディジットも見えていることになります。
- チェックディジットが見えていると、番号全体がこのチェックを満たす並びに限られます。それは隠れた桁の並びのうちちょうど 10 分の 1 で、候補の数は 10n−1 通りになります。隠れた桁のどれか 1 つを 0〜9 と動かすと、チェックの合計の下 1 桁も 0〜9 を 1 回ずつ取るためです。
- 絞り込みは 10 分の 1 で止まります。チェックディジットは番号の誤入力を見つけるためのもので、1 桁分の情報しか持たないからです。
- チェックディジットも隠れている形（先頭の桁だけを保存するなど）では、チェックディジットはほかの桁から決まるので、やはり 10n−1 通りです。
- つまり候補の数は、どの桁を見せるかではなく、何桁を見せるかで決まります。チェックディジットを見せても、チェックディジット以外の 1 桁を見せても、候補は同じく 10 分の 1 になります。チェックディジットが見えていることで、リスクが上がるわけではありません（下のコラムで詳しく説明します）。
- チェックディジットの無い番号（銀聯の一部）では絞り込まれず、10n 通りのままです。
- 先頭の 6 桁または 8 桁は BIN（IIN）で、ブランドと発行会社を表します。先頭の 1 桁は業種を表す番号（MII）で、ブランドの見当もつきます（4 は Visa、5 は Mastercard など）。使われている BIN は限られるため、BIN を隠しても候補は 106 倍ではなく、使われている BIN の件数（約 34万）倍にとどまります。また、ブランドや発行会社の見当がつく相手には、BIN を隠しても効きません。計算の「BIN を推測された場合」はこの見方での数です。
- BIN が隠れていれば、隠れた BIN の並びのうち、使われている BIN の割合を掛けます（BIN がすべて隠れていれば 34万/106）。
- BIN の後ろの桁も、発行会社ごとの割り当て方で偏ることがあります。ここで数えた候補の数は多めの見積もりです。
コラム
チェックディジットが漏れると、リスクは高まるか
「先頭 6 桁と下 4 桁」には、最後の 1 桁のチェックディジットが含まれています。 チェックディジットが分かれば、隠れた桁を補った番号が正しい形かどうかを確かめられます。 それなら、チェックディジットを隠して、代わりにその手前の桁を見せたほうが安全なのでしょうか。
答え: 見せる桁の数が同じなら、リスクは変わりません。
チェックディジットの式
番号の各桁を、右端（チェックディジット）から順に r0, r1, r2, … と呼びます。右から数えて偶数番目の桁（r1, r3, …）だけを 2 倍し、2 けたになったら 9 を引きます。
S = r0 + f(r1) + r2 + f(r3) + r4 + …
f(x) = 2x（x ≦ 4）、2x − 9（x ≧ 5）
正しい番号 ⇔ S が 10 の倍数
f は 0〜9 を 0〜9 に一つずつ対応させます。同じ値に移る数字はありません。
| x | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|---|---|---|---|---|---|---|---|---|---|---|
| f(x) | 0 | 2 | 4 | 6 | 8 | 1 | 3 | 5 | 7 | 9 |
このため、ほかの桁をすべて決めると、残る 1 桁は 0〜9 のうちちょうど 1 つに決まります。2 倍する位置の桁でも、2 倍しない位置の桁でも同じです。
2 つの見せ方を比べる（16 桁）
- 8888-88**-****-8888（チェックディジットを見せる）
- 隠れた 6 桁の並びは 106 通り。 そのうち 5 桁を自由に決めると、S が 10 の倍数になる残りの 1 桁は 1 つだけ。 候補は 105 通りです。
- 8888-88**-***8-888*（チェックディジットを隠し、手前の 4 桁を見せる）
- 隠れた 6 桁のうち、チェックディジットはほかの 15 桁から計算で決まります。 自由に決められるのは真ん中の 5 桁で、候補は 105 通りです。
どちらも 10 桁を見せていて、候補は同じ 105 通りです。 後者でも、候補の 105 通りはすべてチェックを満たす番号です。前者で「確かめられる」ことと、後者で「計算できる」ことは、同じ 1 つの式を両側から見ているにすぎません。
一般の式
チェックディジットのある L 桁の番号で、どれか k 桁（k < L）を見せたときの候補の数は、どの桁を選んでも次のとおりです。
候補の数 = 10L − 1 − k
正しい番号の全体は、チェックディジットの分だけ少ない 10L − 1 通りです。そこから、見せた 1 桁ごとに 10 分の 1 になります。 チェックディジットは、ほかの桁と同じく 1 桁分の情報しか持っていません。チェックディジットを見せるのも、ほかの 1 桁を見せるのも、候補を減らす効果は同じです。
保存の判断への当てはめ
保存する桁を減らしたいなら、チェックディジットかどうかは気にせず、見せる桁の数を減らします。 たとえば下 4 桁を下 3 桁にすると、候補は 10 倍になります。チェックディジットを隠して手前の桁を見せる形にしても、候補は変わりません。 また、チェックはよくある打ち間違いを見つけるためのもので、満たしても、その番号が実在して使えるかどうかは分かりません。
候補の数だけでは決まらないこと
保存してよいかは、候補の数のほかに、次の点も合わせて判断します。
- 何のために保存するか。 利用者への表示や問い合わせの照合なら、下4桁だけで足りることが多いです。先頭の桁（ブランドや発行会社が分かる部分）が要る理由がなければ、保存しないほうが候補は大きく増えます。
- 一緒に保存しているもの。 名義・有効期限・住所・メールアドレスと一緒に漏れると、クレジットカード会社を装った連絡が本物らしく見える材料になります。番号の一部と個人情報を別の場所に分けて持つことも考えます。
- セキュリティコード。 決済の承認の後に保存することは PCI DSS で禁じられています。
- トークン。 決済代行会社のトークンで足りる用途なら、番号の一部も持たずに済みます。
PCI DSS は v4.0 の要件 3.4.1（表示のマスキング）と 3.3.1（認証データの保存の禁止）を参照しています。保存（切り捨て）の形式はクレジットカードのブランドごとに定めがあるため、実際の運用ではブランドと決済代行会社の基準を確認してください。