コンテンツにスキップ
🛠️
Whiz Tools

メキシコCLABEジェネレーター & バリデーター | 無料テストツール

ソフトウェアのテスト用に有効なメキシコのCLABE番号（18桁の銀行口座識別番号）を生成する無料ツール。銀行コード、支店コード、チェックディジットを正しい規則で計算し、既存のCLABE番号が有効かどうかの検証も即座に行える。決済システムの開発やQAテストに登録不要ですぐ利用できる。

メキシコCLABEジェネレーター

ソフトウェアテストや既存のものの検証のための、有効なメキシコCLABE（標準銀行コード）番号を生成します。

ローディング計算機...
📚

ドキュメンテーション

メキシコCLABE生成ツール（テスト用）

はじめに

メキシコのCLABE（Clave Bancaria Estandarizada、標準化された銀行コード）は、メキシコの銀行システム全体で電子送金を標準化するために使用される18桁の数値コードです。支払いシステムや金融アプリケーションを構築する際、テスト用の有効なCLABEナンバーを持つことが絶対に重要であることがすぐにわかるでしょう。

このツールが価値のある理由は次の通りです：メキシコ銀行協会（ABM）によって確立された正確な形式と検証ルールに従う、構造的に有効なCLABEを生成します。生成された各番号には、標準検証アルゴリズムを通過する適切に計算されたチェックディジットが含まれています。簡単な単体テストに1つのCLABEが必要な場合でも、包括的な統合テストに100の異なる番号が必要な場合でも、テスト環境で実際のCLABEのように動作する適切にフォーマットされたコードを取得できます。

CLABEナンバーの理解

CLABEとは

CLABE（Clave Bancaria Estandarizada）は、メキシコの電子送金システム内で使用される標準化された銀行コードです。2004年にSPEI（Sistema de Pagos Electrónicos Interbancarios）リアルタイム決済システムと共に導入され、CLABEは大きな問題を解決しました：導入以前は、各銀行が異なる口座番号形式を使用していたため、銀行間送金はエラーが起こりやすく遅いものでした。現在では、すべてのメキシコの銀行口座に、すべての金融機関で一貫して機能する固有の18桁のCLABEが存在します。

CLABE構造

すべてのCLABEは、4つの重要な要素に分かれた正確に18桁の数字で構成されています：

  1. 銀行コード（1〜3桁目）：メキシコの特定の銀行を識別
  2. 支店コード（4〜6桁目）：銀行の特定の支店を識別
  3. 口座番号（7〜17桁目）：固有の口座識別子（11桁）
  4. チェックディジット（18桁目）：特定のアルゴリズムで計算される検証数字
CLABEナンバー構造 メキシコの18桁CLABE番号構造の視覚的表現 銀行コード 3桁 支店コード 3桁 口座番号 11桁 チェックディジット 1桁

例：012 345 01234567890 1

例えば、CLABEナンバー012345678901234567では：

  • 012は銀行コード（BBVA Bancomer）
  • 345は支店コード
  • 67890123456は口座番号
  • 7はチェックディジット

CLABEナンバーの生成方法

銀行コード

CLABEの最初の3桁は銀行コードを表し、メキシコの特定の金融機関を識別します。これらのコードはメキシコ銀行協会（ABM）によって標準化され、割り当てられています。当社のジェネレーターには、以下のような主要な銀行を含むメキシコ金融システムのすべての公式銀行コードが含まれています：

  • 002 - BANAMEX
  • 012 - BBVA BANCOMER
  • 014 - SANTANDER
  • 021 - HSBC
  • 072 - BANORTE

支店コード

次の3桁（4〜6桁目）は支店コードを表します。実際の支店コードは銀行の特定の物理的な場所に対応していますが、テスト目的のため、当社のジェネレーターは、ランダムで有効な形式の支店コードを作成します。

口座番号

7〜17桁目には11桁の口座番号が含まれます。本番システムでは、これらの番号は各銀行口座に固有のものです。当社のジェネレーターは、適切な形式に従うランダムな口座番号を作成しますが、実際の口座には関連付けられていません。

チェックディジット計算

18桁目はウェイト付きモジュロ10アルゴリズムを使用して計算されるチェックディジットです。この検証メカニズムは、転置された数字や入力ミスなどの一般的なデータ入力エラーを検出します。

以下がその仕組みです：

  1. 最初の17桁の各桁は、対応するウェイト値を掛けられます
  2. ウェイトは3, 7, 1, 3, 7, 1, ... のパターンに従います（すべての位置で繰り返されます）
  3. 各乗算結果の最後の桁のみが使用されます
  4. これらの桁が合計されます
  5. チェックディジットは (10 - (合計 mod 10)) mod 10 として計算されます

このアルゴリズムの興味深い点は、強力なエラー検出を提供することです。誰かが2つの桁を誤って入れ替えたり、1桁を誤って入力したりした場合、チェックディジットの検証は失敗し、不正な送金を防ぎます。これが、銀行APIがトランザクションを処理する前にチェックディジットが無効なCLABEを拒否する理由です。

1function calculateCheckDigit(clabe17) {
2  // 各位置のウェイト
3  const weights = [3, 7, 1, 3, 7, 1, 3, 7, 1, 3, 7, 1, 3, 7, 1, 3, 7];
4  
5  // ウェイト付き合計を計算
6  let sum = 0;
7  for (let i = 0; i < 17; i++) {
8    const digit = parseInt(clabe17[i], 10);
9    const product = digit * weights[i];
10    sum += product % 10; // 乗算結果の最後の桁のみが使用されます
11  }
12  
13  // チェックディジットを計算
14  const mod = sum % 10;
15  const checkDigit = (10 - mod) % 10; // modが0の場合、チェックディジットは0
16  
17  return checkDigit;
18}
19

CLABEジェネレーターツールの使用

このツールは、一般的なテストワークフロー向けに3つの主要な機能を提供しています：

1. 単一CLABEの生成

クイックユニットテストや特定のケースを手動で検査する際に最適です。以下が可能です：

  • 特定の銀行を選択（銀行固有のロジックをテストする際に便利）、またはツールにランダムに選択させる
  • 生成されたCLABEを1クリックでクリップボードにコピー
  • 銀行コード、支店コード、口座番号、およびチェックディジットを示す詳細な内訳を表示

使用するタイミング: クイックデバッグセッション、PostmanやcURLなどのツールを使用した手動APIテスト、またはチームメンバーにCLABE構造を説明する際。

2. 複数CLABEの生成

包括的なテストシナリオに不可欠です。以下が可能です：

  • 数量を指定（一度に最大100 CLABEs）
  • オプションで特定の銀行にすべてのCLABEをロック、またはランダムに銀行を混在
  • 個々のCLABEをコピー、またはカンマ区切りリストとして全セットを取得
  • 各CLABEはバッチ内で一意であることが保証されます

使用するタイミング: テストデータベースへのシーディング、支払いAPIの負荷テスト、QA自動化のための多様なテストデータセット作成、または複雑な複数ユーザーテストシナリオの設定。

3. CLABEの検証

既存のCLABE番号を公式の書式ルールに照らして検証します：

  • 検証したい18桁のCLABEを入力
  • ツールは3つのチェックを実行：書式検証（18桁）、銀行コード検証（公式ABMレジストリ）、チェックディジット検証（重み付きモジュロ10アルゴリズム）
  • 有効なCLABEはコンポーネントの完全な内訳を表示
  • 無効なCLABEは、何が失敗したかを説明する具体的なエラーメッセージを表示

使用するタイミング: 銀行APIがCLABEを拒否した理由のデバッグ、外部ソースから受け取ったCLABEの検証、チームメンバーにCLABE検証を教える、または独自の生成ロジックが正しいチェックディジットを生成することの確認。

CLABEの検証プロセス

CLABEを検証する際、当ツールは以下のいくつかのチェックを実行します：

  1. フォーマットチェック：入力が正確に18桁であることを確認
  2. 銀行コード検証：最初の3桁が実際のメキシコの銀行に対応していることを確認
  3. チェックディジット検証：チェックディジットを再計算し、提供されたものと比較
1def validate_clabe(clabe):
2    # CLABEが18桁であることを確認
3    if not re.match(r'^\d{18}$', clabe):
4        return {"isValid": False, "errors": ["CLABEは正確に18桁でなければなりません"]}
5    
6    # コンポーネントの抽出
7    bank_code = clabe[0:3]
8    branch_code = clabe[3:6]
9    account_number = clabe[6:17]
10    provided_check_digit = clabe[17]
11    
12    # 銀行コードの検証
13    if bank_code not in MEXICAN_BANKS:
14        return {"isValid": False, "errors": ["無効な銀行コード"]}
15    
16    # チェックディジットの検証
17    calculated_check_digit = calculate_check_digit(clabe[0:17])
18    if int(provided_check_digit) != calculated_check_digit:
19        return {"isValid": False, "errors": ["無効なチェックディジット"]}
20    
21    # すべてのチェックをパスした場合
22    return {
23        "isValid": True,
24        "bankCode": bank_code,
25        "bankName": MEXICAN_BANKS[bank_code],
26        "branchCode": branch_code,
27        "accountNumber": account_number,
28        "checkDigit": provided_check_digit
29    }
30

CLABEジェネレーターの実践的なユースケース

ソフトウェア開発とテスト

決済システム統合: Conekta、OpenPay、または直接銀行APIなどのメキシコの決済ゲートウェイと統合する際、本番システムに影響を与えずにテストするための有効なCLABEが必要です。一般的なシナリオ：メキシコの銀行口座に送金する機能を構築している場合、ステージング環境で生成されたCLABEを使用することで、APIコールの書式が正しいか、検証ロジックが機能するか、エッジケースのエラー処理が正しく動作するかを確認できます。実際の送金リスクなしにテストできます。

フォーム検証テスト: CLABEを受け入れるWebフォームを構築する場合、有効な番号のバッチを生成してフロントエンドの検証をテストします。次に、意図的に破損させて（桁を変更したり、長さを変更したり）、エラーメッセージが正しく表示されることを確認します。プロのヒント：異なる銀行のCLABEでテストし、検証が特定の銀行の形式を偏って扱わないことを確認します。

データベースシーディング: メキシコの顧客データを現実的に埋めるテストデータベースを作成する際、ランダムに生成されたCLABEにより、テストデータが本物らしく見えます。これは、顧客が代表的なデータを確認する必要があるデモ環境で特に役立ちます。テスト環境であることを明確にすることを忘れないでください。

負荷テスト: 決済処理システムをストレステストする必要がある場合、100の一意のCLABEを生成し、同時実行のトランザクションをシミュレートします。これにより、単一のテストアカウントでは表面化しない可能性のある競合状態やデータベースロックの問題を特定できます。

金融アプリケーションテスト

クロスボーダー決済システム: メキシコへの送金プラットフォームや国際決済サービスを構築する場合、クライアント側の検証、サーバー側のチェック、最終的に銀行APIレベルでCLABE検証に遭遇します。有効なテストCLABEを用意することで、本番稼働前にアプリケーションが完全なフローを正しく処理できることを確認できます。

エラー処理シナリオ: 繰り返し見られる間違い：開発者は有効なCLABEでのみ「ハッピーパス」をテストします。ユーザーが17桁や19桁を入力したらどうなりますか？ダッシュやスペースが含まれていたら？このツールを使用して有効なCLABEを生成し、次に無効なバリエーションを作成して、エラー処理を徹底的にテストします。明確で役立つエラーメッセージを提供する代わりに一般的な失敗を表示するアプリでは、ユーザーは感謝しないでしょう。

コンプライアンスと監査テスト: 金融アプリケーションは多くの場合、トランザクション検証の監査証跡を必要とします。生成されたCLABEにより、実際の顧客データを公開せずに、検証ロジックがコンプライアンス要件を満たしていることを示す包括的なテストログを作成できます。

教育およびトレーニング目的

メキシコの銀行標準の学習: メキシコの金融システムで作業する人にとって、CLABE構造を理解することは不可欠です。このツールを使用して例を生成し、そのコンポーネントを分析し、チェックディジットアルゴリズムが実際にどのように機能するかを理解します。

フィンテックトレーニングプログラム: メキシコの決済システムに関する新しい開発者をトレーニングする際、すぐに利用できる有効なCLABEがあると、ワークショップがより効果的になります。参加者はテストデータの取得に苦労する代わりに、ビジネスロジックの理解に集中できます。

重要な制限と考慮事項

CLABEジェネレーターは、標準的な検証チェックを通過する技術的に有効な番号を作成しますが、理解すべき重要な境界があります：

実際の口座に接続されていない: これは重要です - 生成されたCLABEは構造的に有効ですが、実際の銀行口座にリンクされていません。存在しない住所に正しく書式設定されたアドレスと考えてください。フォーマット検証は通過しますが、それらに送金することはできません。銀行APIは、口座データベースを照会する際に、これらの番号を実際の取引処理中に拒否します。

テスト環境のみ: これらのCLABEは、開発、ステージング、QA環境でのみ使用してください。生成されたテストCLABEを本番コードや設定ファイルにハードコーディングしないでください。一般的な間違いは、本番設定にテストCLABEを残すことで、システムが実際の送金を試みる際に静かに失敗する可能性があります。

銀行コードの通貨: メキシコ銀行協会は、金融機関の合併、リブランド、または新しいライセンス取得に伴い、公式の銀行コードを時折更新します。私たちは銀行コードリストを定期的に更新していますが、短い遅延がある可能性があります。特定のメキシコ銀行のタイムセンシティブなプロジェクトに取り組んでいる場合は、メキシコ銀行の公式CLABE文書に対して銀行コードを確認してください。

セキュリティテストの境界: 生成されたCLABEは機能テストに使用できますが、適切なセキュリティテストに置き換えるべきではありません。例えば、SQLインジェクション保護のテストには、フォーマット的に有効なCLABEとは異なるテストデータが必要です。また、生成されたCLABEをログに記録する際は注意が必要です - それらは偽のものですが、セキュリティ監査中の混乱を防ぐために明確なラベル付けが重要です。

地域の変動: メキシコの銀行システムには、他のラテンアメリカ諸国とは異なる特定のルールがあります。CLABE検証ロジックがブラジルのPIXキー、アルゼンチンのCBU番号、その他の地域の支払い識別子で機能すると想定しないでください。各国には独自の基準があります。

CLABEの代替手段

CLABEはメキシコの銀行間送金の標準ですが、金融の世界には他の識別システムも存在します：

  1. IBAN（国際銀行口座番号）：主にヨーロッパおよび一部の国で使用されますが、メキシコでは使用されていません。

  2. SWIFT/BICコード：国際送金に使用され、メキシコへの送金の際はしばしばCLABEと併用されます。

  3. ABAルーティング番号：アメリカ合衆国の銀行システムで使用されます。

  4. 口座番号：CLABEの標準化された形式のない単純な銀行口座番号。

メキシコの金融システムを特に検証する場合、CLABEが必要な標準となります。

メキシコのCLABEの歴史

CLABEシステムは、2004年にメキシコ銀行協会（Asociación de Bancos de México, ABM）によって導入され、メキシコの銀行間の電子送金を標準化するために設立されました。CLABE以前は、各銀行が独自の口座番号システムを持っていたため、銀行間送金は複雑で誤りが発生しやすいものでした。

CLABEの導入は、メキシコの中央銀行であるバンコ・デ・メヒコが運営する即時グロス決済システム（Sistema de Pagos Electrónicos Interbancarios, SPEI）の開発と同時に行われました。

導入以来、CLABEはメキシコのすべての銀行間電子送金で必須となり、メキシコの銀行システムの効率性と信頼性を大幅に向上させました。

CLABEでのテストにおけるベストプラクティス

テストデータライブラリの作成: テストごとにCLABEをその場で生成するのではなく、テストフィクスチャに既知の良好なテストCLABEのセットを維持します。これにより、テストの再現性とデバッグが容易になります。テストが失敗した場合、問題を引き起こした正確なCLABEを調査できます。

複数の銀行でのテスト: 1つの銀行のCLABEのみでテストしないでください。異なる銀行は、APIで異なる検証の癖を持つ可能性があります。BBVA Bancomer、Banamex、Santander、Banorteなど、少なくとも3〜4の主要なメキシコの銀行からCLABEを生成し、統合がすべてのケースを処理できることを確認します。

テストCLABEソースの文書化: チームメンバーとテスト環境を共有する際は、どのCLABEがテスト生成されたものか、サンドボックス銀行APIから取得されたもの（もしあれば）を明確に文書化します。これにより、統合テスト中の混乱を防ぎ、サンドボックス資格情報を本番データとして誤って扱うことを避けられます。

適切なモックレスポンスの実装: アプリケーションでCLABE検証をテストする際は、成功した検証だけでなく、現実的なエラーレスポンスもモックします：無効なチェックディジット、不明な銀行コード、不適切な形式の入力。実際の銀行APIは、各障害タイプに対して特定のエラーコードを返します。

テストデータのバージョン管理: 回帰テストに特定のCLABEセットを使用する場合は、バージョン管理にコミットします。これにより、すべての開発者とCI/CDパイプラインが同一のテストデータを使用でき、ビルド障害を再現可能にします。

よくある間違いを避ける

CLABEナンバーをアプリケーションで扱う際は、以下の一般的なエラーに注意してください：

フォーマット文字を含むCLABEの受け入れ: ユーザーは、スペースやダッシュを含むCLABE（例：「012-345-67890123456-7」または「012 345 67890123456 7」）を入力することがよくあります。バリデーションでは、これらの文字を拒否するのではなく、バリデーション前に削除する必要があります。実際のメキシコの銀行アプリは、読みやすさのために、フォーマットされた入力を許可しています。

銀行コードの変更の無視: 銀行は合併、リブランド、または買収されることがあります。例えば、スコシア銀行がメキシコのグループ・フィナンシエロ・INGを買収した際、銀行コードが変更されました。アプリケーションが銀行コードをキャッシュしている場合、リフレッシュメカニズムを実装しないと、新たに有効なCLABEを拒否してしまいます。

不十分なチェックディジット検証: チェックディジットアルゴリズムは特定のものであり、譲歩の余地はありません。計算されたチェックディジットが0の場合（アルゴリズムは10ではなく0を返す）のエッジケースをテストしてください。また、合計が10で正確に割り切れる場合のモジュロ10演算を正しく処理できることを確認してください。

すべての18桁の数字がCLABEであると仮定すること: すべての18桁の数字が有効なCLABEではありません。常に、銀行コードを公式レジストリに対して検証し、チェックディジットを確認してください。ランダムな18桁の数字が適切なCLABEバリデーションを通過する確率は0.1％未満です。

銀行名のハードコーディング: 銀行コードは安定していますが、銀行名はリブランディングにより変更されることがあります。銀行コードはデータベースに保存しますが、ユーザーに表示する際は、更新された参照またはAPIから現在の銀行名を取得してください。

本番環境での完全なCLABEのログ記録: テストCLABEが実際のものではなくても、適切な慣行を確立することが重要です。本番システムでは、財務データ保護規制に準拠し、プライバシー基準を維持するために、CLABEの一部（最初の6桁と最後の2桁）のみをログに記録してください。

よくある質問

CLABEナンバーは何に使用されますか？

CLABEナンバーは、電子送金のためにメキシコの銀行システム内の銀行口座を識別するために使用されます。正しい銀行と支店に確実に送金されるようにします。

CLABEがどの銀行のものかをどうやって判断できますか？

CLABEナンバーの最初の3桁が銀行を識別します。例えば、012はBBVAバンコメル、072はバノルテ、002はバナメックスを示します。

生成されたCLABEナンバーは実際の口座に接続されていますか？

いいえ。このツールで作成されたCLABEナンバーは構造的に有効ですが、実際の銀行口座には接続されていません。テスト目的でのみ使用してください。

CLABEナンバーが有効かどうかをどのように知ることができますか？

有効なCLABEは3つの重要なチェックをパスします：

  1. 長さの検証：正確に18桁（それ以上でもそれ以下でもない）
  2. 銀行コードの確認：最初の3桁がABMに登録された公式のメキシコ銀行コードと一致すること
  3. チェックディジットの検証：18桁目が重み付けモジュロ10アルゴリズムで計算された値と一致すること

検証ツールはこれら3つの基準すべてをチェックします。これは構造と形式を検証するものであり、銀行の実際のデータベースに口座が存在することを確認するものではないことに注意してください。

これらの生成されたCLABEを実際の取引に使用できますか？

いいえ。これらはテスト用のCLABEのみであり、実際の金融取引に使用してはいけません。実際の口座にルーティングされることはありません。

銀行コードはどのくらいの頻度で更新されますか？

銀行コードデータベースは、公式のメキシコ銀行協会（ABM）レジストリと四半期ごとに同期されますが、主要な変更（新銀行、合併、買収）は数日以内に反映されます。銀行コードの変更は比較的まれで、メキシコは数年間ほぼ同じ主要な金融機関セットを維持しています。特定のメキシコ銀行と統合する必要があり、最新の銀行コード情報が絶対に必要な場合は、メキシコ銀行の公式CLABE文書で相互参照してください。

なぜ銀行アプリは、このツールが有効と言っているCLABEを拒否するのですか？

このツールは構造的な有効性を検証します - 正しい長さ、有効な銀行コード、適切なチェックディジット計算。しかし、銀行アプリケーションは追加のチェックを実行します：口座がデータベースに存在するか、口座がアクティブ（凍結されていないか、閉鎖されていないか）、権限を確認します。構造的に完璧なCLABEは、実際の口座に接続されていないため、これらの現実世界のチェックに失敗します。これは予期された動作であり、これらがテスト専用のCLABEである理由そのものです。

特定の銀行のCLABEを生成できますか？

はい、このツールでは、CLABEを生成する際に特定の銀行を選択でき、銀行コード部分が選択した金融機関と一致するようにできます。

チェックディジットはどのように計算されますか？

チェックディジットは、公式のCLABE標準で定義された重み付けモジュロ10アルゴリズムを使用します。最初の17桁の各桁は、繰り返しの重みパターン（3、7、1、3、7、1、...）で乗算され、各積の最後の桁のみが保持されます。これらの桁が合計され、チェックディジットは（10 - （合計 mod 10））mod 10として計算されます。このアルゴリズムは強力なエラー検出を提供し、最も一般的なデータ入力ミスである単一桁のエラーとほとんどの転置エラーを捕捉します。

一度に生成できるCLABEの数に制限はありますか？

ツールは1バッチあたり最大100のCLABEを生成でき、ほとんてのテストシナリオに対応できます。大規模な負荷テストのために数千のCLABEが必要な場合は、ジェネレーターを複数回実行するか、チェックディジットアルゴリズムをテストデータファクトリに直接統合してください。アルゴリズムはテストフレームワークに直接実装するのに十分シンプルです。

参考文献

  1. メキシコ銀行（Banco de México）. 「CLABE - 標準銀行コード」 https://www.banxico.org.mx/servicios/clabe-estandarizada.html

  2. メキシコ銀行協会（ABM）. 「信用機関コードカタログ」 https://www.abm.org.mx/

  3. 銀行間電子決済システム（SPEI）. 「運用規則」 https://www.banxico.org.mx/sistemas-de-pago/servicios/sistema-de-pagos-electronicos-interbancarios-spei/

  4. 国家銀行証券委員会（CNBV）. 「信用機関に適用される一般的な規定」 https://www.gob.mx/cnbv

メキシコの決済統合の準備はできていますか？このCLABEジェネレーターを使用して、実際のメキシコの銀行で使用される正確な形式と検証ルールに一致する有効なテストデータを作成できます。迅速なテストのために単一のCLABEを生成したり、包括的なテストシナリオのために最大100個のCLABEをバッチ作成したり、既存のCLABEを検証して、検証に失敗する理由を理解したりできます。

本番システムでは、すべてのテストCLABEを、メキシコの銀行パートナーから提供された実際の口座番号、または公式サンドボックス環境から取得した口座番号に置き換えることを忘れないでください。これらの生成された番号は、実際の銀行口座に接続せずに現実的なテストデータが必要な開発およびQA環境専用に設計されています。