よくある質問

金融機関コード・支店コードをAPIで検索・参照できるサービスです。口座入力フォームの補完、加盟店登録、SaaS・業務システムでの金融機関情報の検索・照合、取引先登録、CSV/OCR取込データの確認などに利用できます。

Search API、銀行・支店選択Widget、入力から候補を推定するResolve API βに加え、全件データを取得できるMaster Exportを提供しています。

BankcodeJP は、業務利用を想定し、継続的な監視・保守・改善を行いながら運用しています。

API へのアクセスは、DNS / ロードバランサ を通じて処理されます。また、障害や高負荷の検知、復旧対応、データ更新処理の監視を行っています。

ただし、サービスはベストエフォートで提供しており、常時稼働や特定の可用性を約束するものではありません。稼働状況は API ステータスページで確認できます。

原則ありません。データ更新やリリースは、可能な限り通常利用へ影響が出ないように実施します。

ただし、障害や緊急メンテナンス等により一時的に利用できない場合があります。その際は影響範囲の把握と並行して復旧対応を行います。

現時点では稼働率などの数値を約束するSLAは提供していません。ただし、商用利用を前提とした監視・運用・障害復旧体制を採っています。

口座入力フォーム、取引先登録、支払先登録、加盟店登録、決済・金融、SaaS、EC、バックオフィス業務など、銀行・支店情報を扱うシステムで利用されています。

個別企業名は非公開ですが、商用システムや社内業務システムへの組み込み用途でも継続的に利用されています。

金融機関コード、金融機関名、支店コード、支店名、読み、金融機関種別などをもとに金融機関・支店情報を検索できます。

銀行選択、支店選択、金融機関種別での絞り込み、金融機関コードと支店コードによる対象支店の取得などに利用できます。

通常のSearch APIプランではできません。金融機関・支店データの全件取得・大部分取得、継続的または定期的な巡回収集、複製DBやマスタデータとしての継続保存、差分同期による複製DB構築は利用規約で禁止しています。

全件データを取得し、自社システムに取り込んで利用する用途にはMaster Exportを提供しています。利用環境やSaaS/OEMの利用範囲を含め、契約で利用条件を定めます。

BankcodeJP は、全国銀行協会（全銀協）のコード体系（金融機関コード・支店コード）を基準として、各金融機関・関係機関が一般に公開している支店情報等を定期的に収集し、差分検知・正規化・検証のうえ反映しています。

提供データは、これらの公開情報を API 提供のために統合・整形した結果であり、原データをそのまま再配布するものではありません。

あります。金融機関の公開情報には表記ゆれが存在するため、BankcodeJPでは検索・照合のために一定の正規化を行います。

対象になる例： ・括弧表記（例：全角/半角の括弧、補足表記）の取り扱い ・全角/半角、スペース、記号の差 ・末尾の「支店」が省略されている/されていないケース

仕様として常に完全一致の表記を返すものではありません（実運用での検索性を優先します）。

原則として返しません。BankcodeJPの支店コードは3桁を正とし、3桁以外（例：4桁等）のコードは正規の支店コードとして扱わず、収集段階で除外または補正対象として扱います。

銀行・支店の全件データをZIPで取得し、自社のデータベースや業務システムに取り込んで利用できます。

ZIPには銀行と支店のCSV、データセット情報を記したマニフェストが含まれます。取得の手順とデータ形式はAPIリファレンスをご覧ください。

自動で取り込まれるわけではありません。ZIPの取得と自社システムへの取り込み・更新はお客様側で実装・運用します。

料金、APIのリクエスト上限、利用環境やSaaSでの利用範囲は個別契約で定めます。お客様の確定条件はOfferと管理画面の表示をご確認ください。

振込先口座登録フォームや返金先口座登録フォームに埋め込める銀行・支店選択Web Componentです。

銀行・支店を選択すると、金融機関コード、金融機関名、支店コード、支店名をhidden inputとeventで取得できます。

ありません。WidgetではAPI Keyではなく、公開前提のPublic Keyを使います。

Public Keyを使って短期access_tokenを取得し、そのaccess_tokenでWidget専用のpublic routeを呼び出します。

利用できます。WidgetはWeb Componentとして提供されるため、React、Angular、Vue、通常のHTMLフォームに組み込めます。

framework側ではDOM elementを参照し、eventはaddEventListenerで購読する形を推奨します。

name-prefix を指定すると、custom element直下のLight DOMにhidden inputを生成します。

支店まで選択されると、bcjp:select eventも発火します。

Search APIは金融機関・支店情報を検索するAPIです。Resolve API βは自由入力の候補推定と自動確定可否を返すAPIです。

Widgetは、銀行・支店選択UIそのものをフォームに組み込むためのフロントエンド部品です。

あります。銀行・支店選択ウィジェットは、Search APIとは独立して単独で利用プランを有効化できるサービスです。

利用プラン、利用上限、提供条件は料金ページで確認できます。

利用できません。Public Clientを作成していても、銀行・支店選択ウィジェットの利用プランを有効化していない場合はWidget APIの呼び出しは拒否されます。

Freeを含め、銀行・支店選択ウィジェットの利用プランを有効化する必要があります。

利用上限やレート制限を超えた場合、銀行・支店候補の取得が一時的にできなくなる場合があります。

ウィジェット上では候補取得に失敗した旨のメッセージを表示し、時間をおいて再試行していただく案内を行います。実装上は、Widget APIが HTTP 429 (Too Many Requests) を返す場合があります。

CSV・OCR・取引先マスタなどの入力から銀行コード・支店コード候補を返し、自動処理に進めるか、人が確認すべきかの判断材料を提供するAPIです。

Search APIが金融機関名・支店名・コードから検索候補を返すAPIであるのに対し、Resolve API βは、入力値の揺れや不足を含むデータから候補を推定し、decision と理由で後続処理の判断を支援します。

現在はβ提供中です。β版の終了日は未定です。

提供条件を変更する場合は、事前にお知らせします。

いいえ。needs_review はAPIの失敗ではありません。有力候補はあるものの、人による確認を推奨する状態です。

利用側では、確認画面、選択UI、バックオフィスでの確認対象抽出などに回してください。

十分な確度で候補を特定でき、自動処理候補として扱える状態です。

ただし、最終的な業務上の採用判断は、利用システム側の要件や確認フローに合わせて設計してください。

候補は存在するが、一意に判断できない、または確度が不足している状態です。候補選択、追加入力、人手確認に回してください。

候補を特定できない状態です。この場合、candidates は空配列で、best_match は返りません。

利用側では入力修正、再入力、または別手段での確認に回してください。

利用可能です。振込・支払用途では context: "payment" の利用を推奨します。

振込・支払用途では、APIの判定結果だけで処理を進めるのではなく、利用システム側の確認フローやリスク許容度に合わせて取り扱ってください。

Resolve API βは、Freeプランを含むすべての登録ユーザーが、既存のAPIキーで利用できます。

正式版の提供開始までは追加料金はかかりません。

利用上限は、アカウント単位で1日10,000リクエスト、秒間1リクエストです。

β版の終了日は未定です。提供条件を変更する場合は、事前にお知らせします。

同じではありません。Resolve API βの利用上限は、アカウント単位で1日10,000リクエスト、秒間1リクエストです。

Search APIやWidgetの料金・上限は変更ありません。

BankcodeJP は、Google Cloud 上で運用しています。

API へのアクセスは、DNS、HTTPS、ロードバランサ を経由して処理され、バックエンドの API サービスは、Google Kubernetes Engine（GKE）上の Kubernetes クラスタで稼働しています。

業務利用を想定し、リクエスト量、エラー、ログ、データ更新処理などを監視しながら運用しています。

API サービスは、単一プロセスや単一インスタンスだけに依存しない構成で運用しています。

ロードバランサ、Kubernetes クラスタ上のコンテナ実行基盤を組み合わせ、障害や高負荷を検知し、復旧対応を行いやすい構成としています。

ただし、現時点では稼働率などの数値を約束する SLA は提供していません。サービスはベストエフォートで提供しており、稼働状況は API ステータスページで確認できます。

金融機関・支店情報の更新やサービスリリースは、可能な限り通常利用へ影響が出ないように実施しています。

データ更新では、差分検知、正規化、検証を行ったうえで反映し、更新中も API レスポンスの整合性が保たれるように運用しています。

ただし、障害対応、緊急メンテナンス、外部要因などにより、一時的に利用できない場合があります。

API機能・レスポンス品質・データ内容は同一です。差分は以下のみです。 ・1日あたりのリクエスト上限 ・秒間リクエスト数（レート制限）

開発・本番ともに同一API仕様で利用できます。

無料プラン/有料プランの違いは、1日あたりの上限と秒間レート制限です。最新の上限値は料金プランをご確認ください。

初期導入費用は発生しません。料金プランに記載の月額/年額のみお支払いいただきます。

プランごとにリクエスト数とリクエストレートの上限があります。最新の上限値は料金プランをご確認ください。

無料プラン/有料プランの違いは、1日あたりの上限と秒間レート制限です。API機能・レスポンス品質・データ内容は同一です。

秒間レート制限を超えた場合、APIは HTTP 429 (Too Many Requests) を返します。一定時間待ってから再試行してください。

クライアント実装では、指数バックオフ（exponential backoff）やリトライ間隔の制御を推奨します。レート制限時のレスポンスには Retry-After ヘッダが含まれます。指定秒数待って再試行してください。

認証に失敗した場合はHTTP 401が返ります。APIキーの設定方法と有効状態を確認してください。

APIキーはダッシュボードで確認・管理できます。

以下のクレジットカードに対応しています。 ・Visa ・Master Card ・American Express ・JCB ・ダイナースクラブ ・ディスカバー

また、請求書払い（銀行振込）もご利用いただけます。請求書払いをご希望の場合は、ログイン後のダッシュボードから請求書払いを申請していただくことで、数営業日以内に設定が完了し、そのままご利用いただけます。

お支払い方法（クレジットカード / 請求書払い）によらず、毎月の請求書・領収書はメールで自動送付されます。

あわせて、ログイン後のダッシュボードからもPDF形式で請求書・領収書をダウンロードしていただけます。

2026年1月以降の請求分より、適格請求書の発行に対応しています。

請求書払いをご希望の場合は、ダッシュボードから申請してください。申請後、数営業日以内に請求書払いが有効になります。

審査では、以下の情報をもとに請求先の正当性を確認します。 ・アカウントや請求先のメールアドレスのドメイン ・入力された請求先名（法人名等） ・入力された請求先住所

支払期限は、請求書発行日から62日です。

Freeの範囲で利用している場合、料金は発生しません。

請求サイクルは、初回の有料利用プランを有効化した時点を基準に開始されます。以後は、月払いまたは年払いなど選択した支払い周期に応じて、契約の更新タイミングを基準に請求されます。

Search APIや銀行・支店選択ウィジェットなど複数のサービスを利用している場合でも、サービスごとに別々の請求サイクルが作成されるわけではありません。追加したサービスやプラン変更は、同じ契約内容に反映されます。

有料プランへの変更、サービスの追加、上位プランへの変更などは、内容によりすぐに反映される場合があります。また、契約期間の途中で変更した場合は、残り期間に応じた料金調整が行われる場合があります。

一方で、下位プランへの変更、解約、支払い周期の変更などは、現在の契約期間終了後の次回更新時に反映される場合があります。

契約変更時は、ダッシュボードの確認画面に、変更内容、反映タイミング、次回更新日、請求見込みが表示されます。最終的な契約状態、反映タイミング、請求内容は、ダッシュボード上の表示をご確認ください。

定期更新：原則として日次 臨時更新：品質改善や重要変更がある場合に随時

更新中も整合性が保たれるよう、バージョン切替方式で反映します。

BankcodeJP では、関係機関・各金融機関が公開する情報（支店一覧等）を定期的に収集し、変更差分を検知・正規化・検証したうえで反映しています。

統廃合・名称変更などの反映は、公開情報側の更新タイミングや検証状況により、一定の遅延が発生する場合があります。

BankcodeJP では、金融機関・支店情報を収集したあと、そのまま本番データへ反映するのではなく、更新前に差分や整合性を確認しています。

たとえば、追加・削除・変更件数、支店コードの重複、名称・読みなどの変更、不自然な差分がないかを確認し、想定外の変化を検知できるようにしています。

金融機関コード・支店コードは、振込先登録、入力補助、外部データ照合などの業務処理で利用されるため、データ取得だけでなく、更新前のチェックプロセスを重視しています。

通常の更新範囲を超える差分や、不自然な追加・削除・変更が検出された場合は、そのまま本番データへ自動反映しない運用としています。

取得元データの形式変更、データ欠落、金融機関側の掲載変更などにより、想定外の差分が発生する場合があるため、必要に応じて内容を確認したうえで反映します。

ただし、すべての変更内容を完全に保証するものではありません。公開情報や取得可能なデータをもとに、継続的に確認・整備しています。

金融機関の統廃合、支店の廃止、名称変更などについては、公開情報を確認し、反映対象となる変更内容を検証したうえでデータへ反映します。

事前に公表されている統廃合や支店変更については、可能な限り実施日にあわせて提供できるよう、事前に反映準備を行っています。

一方で、公開情報の更新タイミング、取得元データの反映状況、確認作業の内容によっては、APIへの反映までに遅延が発生する場合があります。

互換性や検索性のため、一定期間は旧名称や別名を補助情報として保持する場合があります。ただし、保持対象や保持期間は変更内容により異なります。

サービスの稼働状況および過去のインシデント情報は、ステータスページで公開しています。

ステータスページ：https://bankcode-jp.statuspage.io/ 過去のインシデント：https://bankcode-jp.statuspage.io/history

監視により異常を検知した場合、影響範囲の把握と並行して復旧対応を開始します。

重大障害時は、可能な範囲で状況共有と復旧を優先します。

BankcodeJPの脆弱性管理、パッチ適用、緊急時対応、責任分界に関する標準的な運用方針は、セキュリティ・脆弱性対応方針ページで公開しています。

APIキーはダッシュボードから発行・管理できます。

漏洩した可能性がある場合は、当該キーを無効化し、新しいキーを発行してください（キーのローテーションにより影響を最小化できます）。

公開フロントエンドにAPIキーを直接埋め込む構成は推奨しません。必要に応じてサーバー側で中継する構成をご検討ください。

サービスの安定運用・不正利用対策のため、アクセスログ（時刻、リクエスト量、エラー率など）を記録します。

取り扱いはプライバシーポリシーに基づき、運用改善とセキュリティ目的の範囲で利用します。詳細はプライバシーポリシーをご確認ください。

送信元IP制限に対応しています。ダッシュボードからAPIキーに対して許可IPを登録してください。

可能です。追加料金・クレジット表記義務はありません（利用規約の範囲内）。