テスト用IBANとは？
テスト用IBANは、ソフトウェアの動作を確認するために作る合成の国際銀行口座番号（IBAN）です。決済フォーム、国選択、入力の正規化、API fixture、ブラウザテスト、画面例、研修、技術文書で使えます。選択した国の形式に合う長さと文字種を持ち、コードが必要とする数学的checksumを通過する場合があります。
重要なのは「テスト用」であることです。生成された文字列から実口座、受取人、銀行の登録状況を見つけることはできません。IBAN一括生成ツールは合成行を作り、IBANチェッカーは入力文字列を検査しますが、どちらも銀行へ接続しません。
- 適切な用途：フォーム検証、パーサー、QA fixture、回帰テスト、デモ、技術文書。
- 不適切な用途：送金、口座振替、受取人登録、所有権の主張、口座探索。
- fixtureの目的、環境境界、削除担当をデータの近くに記録する。
合成データは実際の銀行口座ではありません
合成値は形式を試すために作ります。国コード、固定長、BBANの文字クラス、MOD-97の余り1を満たすようにできます。しかし、これは「選択した国のルールに対して文字列が構造的に整合するか」という限定的な技術検査です。
銀行発行のIBANは、口座、銀行、支店、通貨、決済経路、名義人、現在の状態などと結び付きます。文字列だけのローカル検査ではそれらを証明できません。
| 確認したいこと | テスト用IBANでできること | 証明できないこと |
|---|---|---|
| 国のルールに合うか | 国コード、固定長、BBANの大まかな文字パターン | 銀行が発行したこと |
| checksumに合うか | MOD-97とエラー処理のテスト | 口座が存在し送金を受けられること |
| フォームが保存できるか | 空白、小文字、コピー、API、DB長のテスト | 入力された名義人が所有者であること |
| 決済が成功するか | 対応するsandboxの模擬フロー | 本番の到達性、審査、決済完了 |
テスト用IBANを3つのレイヤーで検証する
有用なfixtureは単なるランダム文字列ではありません。まず登録された国別形式を選び、失敗を別々に検査します。IBAN対応国一覧で長さとBBANの大まかな構造を確認し、IBANデコーダーで完成値の見える部分を確認できます。
最初に国コードと全体の長さ、次にBBANの数字・英字・英数字パターン、最後に国際MOD-97-10を確認します。合格例だけでなく意図的な失敗例も含めると、エラー処理をテストできます。
- 1. 国と長さ対応国を選び、その国の固定長と国コードを確認します。
- 2. 文字パターン国内フィールドが必要とする数字・英字・英数字を確認します。
- 3. MOD-97チェックサムアルゴリズムを実行し、余りが1になるか確認します。
- 4. 業務境界構造的に有効なだけであり、所有権や決済を示さないと記録します。
- 長さエラーとchecksumエラーを分け、利用者が最初に直すべき問題を表示する。
- 有効なfixtureのchecksum数字を1つだけ変え、明確な失敗を確認する。
- 数字欄に英字を入れるケースは、意図した負のテストとしてラベル付けする。
安全なQA fixtureの作成フロー
テスト用IBANは他の合成fixtureと同じように扱います。目的を決め、既知の国別ルールで生成し、検証し、ラベルを付け、必要な環境だけに隔離します。数学的に有効な文字列でも、本番seed、顧客出力、請求書、実際の受取人リストへ混ざれば危険です。
少数ならホームの生成器で作れます。回帰スイートやマトリクスには一括生成ツールでCSVまたはJSONを出力し、国、期待長、期待結果、テスト目的、削除担当を自分のfixtureファイルに追加してください。
- 定義国、入力動作、期待結果、fixtureの目的を書きます。
- 生成国別ルールで合成値を作り、顧客口座情報はコピーしません。
- 検証長さ、文字パターン、MOD-97の期待結果を保存します。
- 隔離と削除テスト専用データセットに置き、実行後に削除またはローテーションします。
1つの成功例ではなくIBANテストマトリクスを作る
1つの合格値だけでは十分な検証になりません。国別の長さ、印刷形式と電子形式、空白、小文字、変更したchecksum数字、短すぎる値、長すぎる値を含めます。支払プロバイダー独自のsandbox値がある場合は、そのドキュメントに従い、汎用fixtureとは分離してください。
国、期待結果、表示形式、エラー理由をfixtureに保存し、正しい値だけでなく失敗時のUIも再現できるようにします。
- 期待結果をfixtureと一緒に保存し、バリデーター変更をレビューできるようにする。
- iban-de-length-22-validのような説明的なIDを使う。
- 実在する氏名、カード、請求書、銀行明細を合成ケースへ入れない。
| ケース | 確認すること | 期待結果 |
|---|---|---|
| 短い国別形式 | 長さとBBANの配置 | ルールとchecksumが合えば受理 |
| 長い国別形式 | 最大幅とAPI/DBの保存 | 切り捨てや隠れ空白なし |
| 印刷形式 | 4文字区切りと正規化 | 表示空白を除いて検証 |
| 小文字入力 | 英字フィールドの大文字化 | 安全に正規化または明確に拒否 |
| checksum数字を1つ変更 | エラー表示 | 数学的不整合として拒否 |
| 1文字不足または超過 | 長さエラーの優先順位 | 誤った成功表示の前に拒否 |
| 本番seedへの混入 | CIの環境ガード | デプロイ前にブロック |
よくある誤用と実務上の限界
fake IBANという表現を支払いに使える安全な値と誤解するのが典型的な失敗です。ソフトウェア開発では、test IBAN、synthetic IBAN、合成fixtureという呼び方を優先してください。実際の送金情報は、自分の銀行や決済サービスから取得します。
チェッカーを銀行照会と考えるのも誤りです。ブラウザツールは文字列を説明できますが、口座の稼働、所有者、制裁審査、決済到達性は知りません。
- 合成値を公式、安全な支払い先、割当済み、所有者確認済みと呼ばない。
- 氏名、カード番号、国内口座番号、画像からIBANを推測しない。
- 合成fixtureを請求書、返金指示、給与ファイル、口座振替へ掲載しない。
- 合成ケースに実在する氏名、カード、請求書、銀行明細を含めない。
テスト用IBAN — よくある質問
テスト用IBANとは何ですか？
フォーム、パーサー、エラーメッセージ、fixture、ブラウザテスト、文書を試す合成値です。銀行発行の口座情報ではありません。
テスト用IBAN番号は実際のIBANと同じですか？
同じではありません。国別形式とMOD-97に合格しても、未割当であったり、支払いに使えなかったりします。テストデータとしてだけ扱います。
checksumに合格すれば口座が存在しますか？
いいえ。checksumは数学的な整合性だけを示し、銀行発行、口座状態、名義、所有権、送金可能性を示しません。
テスト用IBANを本番で使えますか？
使えません。開発、QA、staging、デモ、文書、研修に限定し、fixtureが本番へ昇格しないガードを追加してください。
テストマトリクスには何を入れますか？
複数国の長さとBBANパターン、印刷・電子形式、小文字、変更したchecksum、短すぎる値、長すぎる値、正規化、productionデータへの混入防止を含めます。
QAテストマトリクスには何を含めますか？
複数の国別長さ、印刷・電子形式、小文字、変更したチェック数字、短い値と長い値、正規化、運用データへの混入を止めるガードを含めます。
まとめ
テスト用IBANは、顧客の銀行情報を開発へコピーせずに、国別の決済フィールドを試すために役立ちます。合成値を生成し、構造とchecksumを検証し、期待結果を記録し、fixtureを隔離するのが安全な流れです。
有効に見える文字列も、文字列以上のものではありません。実際の決済には、銀行や決済プロバイダーが発行した情報を使ってください。
形式とテストの参考資料
- SwiftのIBAN登録簿 — 国別の登録形式とIBAN登録の背景。
- PayPalのIBAN生成器 — sandboxとテスト用の値を生成する一次資料の例。
- Rapydのテスト用IBAN番号 — プロバイダー固有のsandboxルールを使う理由。
- テスト用IBAN番号 — 第三者のテスト参考資料。実口座情報としては使いません。