Luhnアルゴリズムの仕組み：クレジットカード番号の入力ミスを送信前に見つける方法
クレジットカード番号の末尾1桁は、実はランダムな数字ではありません。それより前の桁から計算されたチェックディジットで、番号全体にLuhnアルゴリズムという式を当てはめると、桁の打ち間違いのほとんどをその場で検出できます。銀行に問い合わせる前、決済ネットワークに送信する前の時点で弾けるのが最大の利点です。
Luhnアルゴリズムの計算ルール
手順は4つだけです。
- 右端の桁を1番目として、右から数えて偶数番目の桁だけを2倍にする。
- 2倍した結果が10以上になったら、その結果から9を引く（2桁になった数字を1桁ずつ足すのと同じ結果になる）。
- 2倍・調整した桁と、手を付けていない桁をすべて合計する。
- 合計が10の倍数であれば、その番号はチェックに合格。10の倍数でなければ不合格。
これだけの単純な式ですが、1桁の打ち間違いや隣り合う桁の入れ替えの大半を検出できます。
実際の番号で検証してみる
Visaの公開テスト番号としてよく知られる 4111 1111 1111 1111（実在の顧客のカードではなく、開発者向けに公開されているテスト用の番号です）で計算してみます。16桁なので、最左端の桁（右から数えて16番目）も偶数番目にあたり、2倍の対象になります。
| 右からの位置 | 桁の値 | 処理 | 結果 |
|---|---|---|---|
| 16（最左端） | 4 | 2倍（4×2=8） | 8 |
| 15 | 1 | そのまま | 1 |
| 14 | 1 | 2倍 | 2 |
| 13 | 1 | そのまま | 1 |
| 12 | 1 | 2倍 | 2 |
| 11 | 1 | そのまま | 1 |
| 10 | 1 | 2倍 | 2 |
| 9 | 1 | そのまま | 1 |
| 8 | 1 | 2倍 | 2 |
| 7 | 1 | そのまま | 1 |
| 6 | 1 | 2倍 | 2 |
| 5 | 1 | そのまま | 1 |
| 4 | 1 | 2倍 | 2 |
| 3 | 1 | そのまま | 1 |
| 2 | 1 | 2倍 | 2 |
| 1（最右端） | 1 | そのまま | 1 |
2倍の対象になった8つの桁（4と、1が7個）を合計すると8+14=22、そのままの8つの桁（1が8個）を合計すると8。全体の合計は22+8=30です。30は10の倍数なので、このチェックに合格します。実際に 4111111111111111 はVisaが公開している有効なテスト番号なので、計算結果と現実が一致していることになります。
1桁の間違いがなぜ弾かれるのか
同じ番号の末尾だけを打ち間違えたケースを見てみます。4111 1111 1111 1111 の最後の1を2に変えて 4111111111111112 と入力してしまった場合です。
最右端の桁（右から1番目）は2倍の対象ではないので、そのままの値が合計に加わります。もとの番号ではここが1で合計に1を足していましたが、打ち間違えた番号では2になり、合計に足す値も2になります。差はちょうど1で、合計は30から31に変わります。31は10の倍数ではないため、この番号はチェックに落ちます。決済ネットワークに問い合わせるまでもなく、入力欄を離れた瞬間にエラーだと分かる仕組みです。
主要ブランドのテスト用カード番号
決済フォームのテストでよく使われる、公開されているサンプル番号です。StripeやPayPalなどのサンドボックス環境のドキュメントにも同じ番号が載っています。いずれも実在の顧客のカードではなく、開発・QA用に公開されている番号です。
| ブランド | テスト番号 | 桁数 |
|---|---|---|
| Visa | 4111 1111 1111 1111 | 16 |
| Visa（別パターン） | 4012 8888 8888 1881 | 16 |
| Mastercard | 5555 5555 5555 4444 | 16 |
| American Express | 3782 822463 10005 | 15 |
| Discover | 6011 1111 1111 1117 | 16 |
決済フォームの実装中にテスト送信が弾かれたとき、原因がフォーム側のバグなのか、単に打ち込んだ番号がLuhnチェックを満たしていないだけなのかは、この表の番号をそのまま貼り付けて切り分けられます。
自分の番号で試す
入力した番号のカードブランドとLuhnチェックの結果をその場で確認できます。
Luhnチェックが証明しないこと
Luhnチェックに合格しても、それが証明するのは「番号の並びが数学的に正しい形式を持っている」ということだけです。そのカードが実在するか、有効期限内か、利用停止されていないか、残高や与信枠が足りているかは、この計算では一切分かりません。実際に決済できるかどうかを確認できるのは、カードを発行した銀行やカードネットワークのシステムだけです。開発中のフォームでLuhnチェックを通った番号を使ってテスト決済が成功しなくても、それは別の理由(有効期限やCVV、3Dセキュアなど)を疑うべきサインです。
よくある勘違いと注意点
Luhnチェックがすべての入力ミスを検出できると思い込むこと。 ほとんどの単純な打ち間違いや隣接する桁の入れ替えは検出できますが、例外が1つあります。隣り合う2つの桁が0と9の組み合わせだった場合、その2つを入れ替えても合計は変わりません。0を2倍すると0のまま、9を2倍して調整しても9のまま(9×2=18、18-9=9)なので、この2つの桁だけはどちらが2倍の対象になっても同じ値を返します。試しに 1234567890 と、末尾の 90 を 09 に入れ替えた 1234567809 を計算すると、どちらも合計は43になり、Luhnチェックの結果は変わりません。実務でこの組み合わせに当たる頻度は高くありませんが、Luhnチェックを万能だと思わないための一番分かりやすい例です。
スペースやハイフンを含んだまま計算してしまうこと。 カード番号は4桁区切りで表示されることが多いですが、Luhnアルゴリズムは純粋な数字の並びに対して計算するものです。区切り文字を取り除かずに計算すると、桁の位置がずれて正しい結果になりません。
Luhnチェックの合格をカードの有効性の証明だと思うこと。 前述の通り、証明できるのは形式だけです。カード番号ジェネレーターが吐き出す番号もLuhnチェックには合格しますが、そのほとんどは実在しない番号です。
よくある質問
Luhnアルゴリズムとは何ですか。 クレジットカード番号などの末尾のチェックディジットを検証するための計算式です。右から数えて偶数番目の桁を2倍し、必要に応じて9を引いてから全桁を合計し、その合計が10の倍数になるかどうかで番号の形式が正しいかを判定します。1954年にIBMのHans Peter Luhnが考案し、現在はISO/IEC 7812でクレジットカード番号の標準的なチェック方式として採用されています。
なぜクレジットカード番号にチェックディジットが含まれているのですか。 決済ネットワークに送信する前の時点で、単純な入力ミスを機械的に検出するためです。1枚ずつ人間が目視で確認しなくても、末尾の1桁があるおかげで大半のタイプミスやスキャンミスをその場で弾けます。
Luhnチェックに合格したら、そのカード番号は使えますか。 使えるとは限りません。合格が証明するのは番号の形式が正しいことだけで、そのカードが実在するか、有効期限内か、利用可能な残高があるかは別の話です。実際に決済できるかどうかは発行銀行のシステムでしか確認できません。
Luhnアルゴリズムはどのカードブランドでも共通ですか。 はい。Visa、Mastercard、American Express、Discoverなど、主要な決済ネットワークはいずれもISO/IEC 7812に沿ってLuhnアルゴリズムを使っています。ブランドによって違うのは番号の桁数や先頭の数字(BINレンジ)であって、チェックディジットの計算方法自体は共通です。