Luhn チェック — クレジットカード番号・IMEI 検証

クレジットカード番号が持つ直接的な金融リスク

クレジットカード番号 (PAN: Primary Account Number) は、決済プロセスの根幹をなす情報であり、カード番号・有効期限・CVV の組み合わせで不正決済が可能になります。Luhn チェックは番号の形式的な妥当性を確認するものですが、この検証操作が発生する文脈は、バックエンドの決済ロジック開発・フロントエンドのフォームバリデーション実装・既存データの品質チェック・不正番号のフィルタリングです。これらの場面では実際のカード番号や、少なくともカード番号に近い形式のテストデータが扱われます。

特に注意が必要なのは、CSV エクスポートから Luhn チェックをかける作業です。決済システムの開発・テスト環境では、実際のカード番号に近いテストデータや、場合によっては本番データのサブセットが扱われます。これらをオンラインの Luhn チェッカーに貼り付けることは、決済情報を外部サーバーに送ることになります。

オンライン Luhn チェッカーにカード番号を送るリスク

「luhn check online」「credit card number validator」で検索して出るサービスは、入力番号をサーバーで処理します。PCI DSS (Payment Card Industry Data Security Standard) は、カード会員データの保護を求める標準で、カード番号を扱う環境に厳格な要件を課しています。本番のカード番号を第三者サービスに送信することは PCI DSS 違反になりえます。

テスト用の番号 (Luhn は通るが実在しないカード) であっても、外部サービスへの送信を習慣にすることは、実番号との区別が曖昧になる状況を生みます。「どうせテスト番号だから」という感覚で外部ツールを使い続けると、本番データを誤って送信するリスクが高まります。

BigInt による Mod 10 計算をブラウザ内に閉じる

Luhn アルゴリズム (Mod 10) は純粋な整数演算です。右端のチェックデジットから左に向かって偶数位置の桁を 2 倍し、2 桁になったら桁和を取り、全桁の合計が 10 の倍数なら Valid です。このツールは JavaScript で実装した Luhn アルゴリズムをブラウザ内で実行します。IIN (Issuer Identification Number) プレフィックスと桁数によるブランド判定 (Visa・MasterCard・Amex・Discover・JCB・Diners・UnionPay・Maestro) も静的テーブルとの照合でブラウザ内に完結します。

入力した番号はページメモリにのみ存在し、ネットワーク送信はありません。本番データ・テストデータを問わず、カード番号形式のデータを外部に出すことなく検証できます。

決済システム開発での安全な使い方

フロントエンドの入力バリデーション実装時に、テストケースとして使える Valid / Invalid 番号のリストをブラウザ内で確認できます。CSV エクスポートした顧客データの番号列の品質チェック、既存データの中から Luhn が通らない無効番号を特定するクリーニング作業にも使えます。Valid のみ / Invalid のみのコピーで次の処理に渡す、CSV ダウンロードで結果を記録する、という一連の作業がブラウザ内で完結します。フォーム入力サニタイズの正規表現を磨きたい場合は regex-test を、請求書のメールアドレスを並行して検証したい場合は email-validate を続けて使えます。

Luhn アルゴリズムの数学的位置づけと ISO/IEC 7812 によるカード番号構造

Luhn アルゴリズム (別名 modulus 10 / mod 10) は IBM のハンス・ペーター・ルーン (Hans Peter Luhn) が 1954 年に考案し 1960 年に米国特許 (US Patent 2,950,048) として登録された、パブリックドメインのチェックサムアルゴリズムです。設計目的は「キーパンチ作業の入力ミス」を機械的に検出することで、(a) 単一桁の誤入力、(b) 隣接 2 桁の入れ替え (transposition、ただし 09 ⇔ 90 を除く) を 100% 検出します。一方で同じ桁の置換 (22 → 55 のように違うチェックサム差で偶然合致するケース) や、3 桁以上の入れ替えは検出できない既知の弱点があります。CRC のような暗号学的強度はなく、改竄の検出ではなく単純な打ち間違いの捕捉が目的です。

クレジットカード番号自体は ISO/IEC 7812 によって構造化されており、(a) 先頭 1 桁の MII (Major Industry Identifier、業界識別子: 4=Visa を含む金融、5=金融、6=Maestro/Discover など)、(b) IIN/BIN (Issuer Identification Number、発行者識別番号、先頭 6〜8 桁) でカードブランドと発行銀行を識別、(c) 残りの桁が個別アカウント番号、(d) 最後の 1 桁が Luhn チェックサム、という構成です。本ツールの IIN プレフィックス判定はこの ISO/IEC 7812 構造に従い、Visa は 4 で始まる 13/16/19 桁、Amex は 34 / 37 で始まる 15 桁、JCB は 35 で始まる 16/19 桁、といったルールを静的テーブルで突合しています。

Luhn では「合っている」だけ — その他の検証ロジックとの組み合わせ

Luhn が通る = 実在するカード番号、ではありません。Luhn が通っても (a) その IIN を持つ発行銀行が存在しない、(b) 発行されたがすでに解約されている、(c) 有効期限が切れている、(d) アクティブだが該当のオーソリ要求を断る、というケースは普通にあり得ます。本物のカード番号として通用するか判定するには、決済ゲートウェイ (Stripe / Adyen / PayPay) に Authorize API でゼロ円もしくは 100 円程度のテスト認証 (authorization hold) を投げる必要があり、これは本ツールの範囲外です。

逆に「Luhn が通らない」のに本物のカードである、というケースもまれにあります。IMEI (国際移動体装置識別番号、TAC 8 桁 + シリアル 6 桁 + Luhn 1 桁の 15 桁) は ETSI TS 123 003 で Luhn 必須ですが、特定キャリアの管理コードや海外端末で例外があることが知られています。カナダの社会保障番号 (SIN: Social Insurance Number) も Luhn 必須ですが、9 で始まる番号は一時就労者向けで通常の Luhn ロジックとは別管理 — 本ツールは標準的な Luhn ルールだけ実装しているので、これらの例外を扱うシステムでは追加のドメインルールが必要です。Luhn は「最初のゲート」として使い、その先に IIN ホワイトリスト・有効期限・3D セキュア・トークン化を重ねる多層検証が決済システムの標準です。