オーソリシステム開発の完全ガイド

オーソリシステムは、カード決済の要求をリアルタイムに審査し、承認・拒否を返す中核基盤であり、決済APIの接続からカード・決済基幹の刷新まで、対象範囲によって開発費が大きく変わります。

「オーソリとは何か」「どの方式で開発すべきか」「費用はいくらか」「発注時に何を確認すべきか」を、加盟店・決済事業者・カード発行事業者のいずれにも役立つように整理します。正常な承認処理だけでなく、タイムアウトや二重送信、障害時の切り替え、カード情報の保護まで含めて、2026年時点で検討すべき全体像を解説します。

▼関連記事一覧
・オーソリシステム開発の進め方
・オーソリシステム開発でおすすめの開発会社6選と選び方
・オーソリシステム開発の見積相場・費用
・オーソリシステム開発の発注・外注・委託方法

オーソリシステムとは何ですか？

オーソリシステムとは、カードやキャッシュレス決済の要求を受けた瞬間に、カード・口座・加盟店・取引の状態を確認し、承認または拒否の結果を返すリアルタイム処理基盤です。日本語では信用照会、与信照会、利用承認などと表現されることがあります。

一般的な流れは、店舗のPOSやECサイトから加盟店サーバーまたは決済代行サービスへ要求を送り、国内決済ネットワークや国際ブランド網を経由して、アクワイアラ側またはイシュア側の処理基盤が判定する形です。判定では、カードの有効性、利用停止、加盟店や端末の状態、利用可能枠、残高、取引種別、不正利用の兆候などを確認します。通常時の応答時間は案件ごとに設計しますが、約2秒級の応答を意識するケースもあります（出典: NotebookLMリサーチノート、2026年）。実際のSLAは通常時・ピーク時・障害時に分けて定義する必要があります。

オーソリと、売上確定・清算・請求・加盟店への入金は同じ処理ではありません。オーソリで承認された後に売上を確定し、後続処理で清算や請求を行います。また、EMV 3-Dセキュアは本人認証、不正検知はリスク評価を担う仕組みであり、オーソリ判定と連携しますが、同一機能ではありません。ここを混同すると、API連携だけで十分な案件に大規模な基幹開発を計上したり、逆に必要な与信・残高・監査機能を見落としたりします。

オーソリシステムの種類と役割をどう分けますか？

オーソリシステムは、誰の業務を支えるか、どの接続先を持つか、どこまで自社で保有するかによって構成が変わります。まずは加盟店側のゲートウェイ、アクワイアラ側の処理、イシュア側の与信・利用枠管理を分けて考えることが重要です。

アクワイアラ側は、加盟店・端末・決済チャネルから受けた要求を適切なカード会社やネットワークへ振り分け、応答を返すゲートウェイ機能が中心です。一方、イシュア側はカード会員の利用可能枠、残高、利用停止、取引履歴、不正リスクなどを参照して判定する必要があります。発注前には「加盟店の決済導入」「決済事業者の接続基盤」「カード発行会社のオーソリ刷新」のどれに該当するかを明確にします。

実装では、決済要求の受信・送信、ルーティング、ISO 8583などの電文変換、国内ネットワークや国際ブランド網との仕様差異の吸収が重要です。さらに、承認、拒否、取消、リバーサル、再送、部分承認、重複取引、タイムアウト後の遅延応答を、取引状態として一貫して管理します。単にHTTP APIを1本つなぐだけでは、再送時に二重承認や残枠の不整合が起きるため、取引ID、冪等性キー、相関ID、監査ログを設計段階から決めます。

判定層にはカード有効性、利用枠、残高、加盟店・端末、取引頻度、地域やデバイスなどのリスクルールが含まれます。保護層にはトークン化、PANのマスキング、暗号鍵とHSMの管理、アクセス権、脆弱性対策が含まれます。継続運用層には24時間365日の監視、障害通知、再処理、スタンドインと呼ばれる代行承認、東西2センターなどのBCPが含まれます。売上確定や返金、会員残高との照合・消込まで含めるかは、システム境界として明示します。

開発方式はPSP・パッケージ・クラウド・スクラッチのどれを選びますか？

最適な方式は、カード情報を自社環境で扱う必要があるか、独自の与信や利用枠を持つか、接続先がいくつあるか、どの程度の取扱量と可用性が必要かで決まります。最初から全機能を内製するのではなく、標準化できる部分と競争力に直結する部分を分けると、費用と開発期間を抑えやすくなります。

ECサイトやアプリに決済手段を追加する目的なら、既存のPSPや決済代行APIを利用する方式が候補になります。カード情報をトークン化して自社環境に置かない構成を取りやすく、承認・取消・返金・Webhookなどの標準機能を短期間で導入しやすい点が特徴です。ただし、自社独自の利用枠、複雑なカード発行業務、独自のリスク判定、複数事業の残高統合まで担う方式ではないため、将来要件を確認してから採用します。

パッケージやプロセッサを導入すると、電文、ブランド接続、会員・利用枠、標準的な判定、監視機能を活用しやすくなります。設定で対応できる範囲と追加開発になる範囲、製品の保守期限、仕様変更の費用、データ移行の方法を確認することが重要です。

クラウド方式では、APIゲートウェイ、ロードバランサー、コンテナ、分散データベース、メッセージング、キャッシュ、HSM、監視などを組み合わせ、ピーク時の拡張や段階的な開発を行えます。2025年に公開された決済処理の参照構成では、暗号化、トークン化、リスクチェック、ISO形式の電文、アクワイアラ側とイシュア側の処理を分けた設計が示されています。毎秒数千件へ拡張できる構成例もあります（出典: 公開された決済処理プラットフォームの参照構成、2025年）が、これは特定案件の性能保証ではないため、実際のピークTPSと応答時間は自社データで試験します。

自社独自のカード商品、与信モデル、利用枠、リアルタイム不正判定、複数事業の残高管理が競争力になる場合は、スクラッチ開発や段階的なモダナイズが候補になります。一方で、電文ゲートウェイ、トークン化、暗号鍵管理、標準的なネットワーク接続まで全てを自社開発すると、監査と運用の負担が急増します。既存メインフレームを残しながらAPI化する、リスク判定だけ分離する、低リスクのチャネルから並行稼働するなど、全置換以外の移行計画も比較します。

オーソリシステム開発はどのように進めますか？

開発は、画面やAPIの一覧から始めるのではなく、処理範囲、接続先、性能、判定ルール、セキュリティ、BCP、運用の順に要件を固めると進めやすくなります。特にオーソリは、後から例外処理や障害対応を追加すると設計変更が大きくなるため、正常系と異常系を同時に定義します。

最初に、イシュア側、アクワイアラ側、加盟店向けゲートウェイのどこを作るのかを図にします。次に、月間取扱件数、ピーク時のTPS、平均・最大応答時間、同時接続数、目標承認率、稼働率、RTO、RPO、監査ログの保存期間を数値化します。接続先は国内決済ネットワーク、国際ブランド網、PSP、本人認証、不正検知、会員・与信・請求基幹に分け、データ項目と責任分界を一覧化します。

基本設計では、承認、拒否、保留、取消、リバーサル、再送、タイムアウト、遅延応答、障害時代行という状態を定義します。要求がタイムアウトした後に再送された場合、相手側では承認済み、自社側では未完了という状態が起こり得るため、取引IDと冪等性を使って二重処理を防ぎます。カード情報を保持する箇所、トークンを利用する箇所、鍵を管理する箇所を分離し、誰が監視・復旧・監査対応を担うのかをRACIや責任分界表に記載します。

テストは正常な承認確認だけで終わらせず、ピーク負荷、ネットワーク分断、接続先停止、HSM障害、重複送信、遅延応答、リバーサル、利用枠の戻し、誤検知、ログ欠落まで再現します。性能試験では平均値ではなく、p95やp99の応答時間、ピークTPS、エラー率、キュー滞留を確認します。移行は低リスクなチャネルから並行稼働し、シャドートラフィック、カナリアリリース、日次照合、ロールバックを組み合わせ、切替訓練と障害訓練を本番前に実施します。

▶ 詳細はこちら：オーソリシステム開発の進め方

オーソリシステムの費用相場とコストの内訳は？

オーソリシステムには公開された一律の定価がないため、以下は取扱量、接続先、既存基幹、二重化、監査範囲、24時間運用の有無を踏まえた2026年時点の企画初期推定です。オーソリ本体の公的な相場ではなく、決済API連携やゲートウェイ、カード基幹刷新に関する近接領域の公開情報を基にした目安として扱います。

既存のPSPや決済代行APIに接続し、1つの決済手段で承認・取消・返金・Webhookまでを実装する範囲なら、300万円〜1,000万円、期間は2〜4か月程度が企画上の目安です。国内決済ネットワークとのゲートウェイ接続、電文変換、接続試験、障害時再送まで含めると、1,000万円〜3,000万円、4〜8か月程度が目安になります。

パッケージやクラウド型プロセッサを導入し、会員・利用枠、不正判定、複数ブランド、既存基幹との連携を設定・追加開発する場合は、2,000万円〜8,000万円、6〜12か月程度が目安です。自社オーソリ基盤を新規構築し、複数ブランド、トークン、監視、BCPまで含める場合は5,000万円〜3億円、12〜24か月以上となる可能性があります。カード基幹のレガシー移行、複数センター、API公開、請求・清算まで含めると、数億円〜数十億円以上となり、要件によっては100億円規模の計画もあり得ます。

経済産業省の2026年のカード分野API連携検討資料では、API未対応事業者の初期投資や、既存対応済み事業者が接続先を追加する場合の費用分類が検討されています（出典: 経済産業省「クレジットカード分野に係るAPI連携の推進に係る検討会」、2026年）。資料はオーソリシステム全体の価格表ではありませんが、既存基盤を活用できるか、接続先追加で済むか、新しい共通基盤を構築するかによって投資規模が変わることを示す参考情報です。詳しくは経済産業省のAPI連携検討資料を確認します。

運用開始後は、クラウド・ネットワーク・データベース・メッセージング・HSMなどのインフラ費用、監視・障害対応費用、脆弱性診断やペネトレーションテスト、PCI DSS対応、接続料、証明書、鍵管理、不正検知サービスの費用が発生します。企画初期の推定では、インフラは月額数十万円〜数百万円以上、24時間365日の監視・運用は年間500万円〜5,000万円程度と置くことがありますが、これは公開標準値ではなく、性能・拠点数・運用体制で変わる試算です。

さらに、ブランド仕様変更、本人認証仕様、APIバージョン、OSやミドルウェア更新、障害訓練、監査支援、データ移行の保守費用も必要です。初期費用の10〜20％程度を年間の改修枠として仮置きする場合がありますが、3〜5年のTCOを作るときは、契約書や見積書に記載された実額へ置き換えます。

見積書では、要件定義・基本設計、電文と接続、判定ロジック、周辺基幹連携、テスト環境と性能試験、セキュリティと監査、移行・監視・運用訓練を分けて記載してもらいます。「オーソリ機能一式」とだけ書かれている場合、HSM、3-Dセキュア、不正検知、障害時の代行、切り戻し、ブランド仕様変更が別費用になりやすいため、含むものと含まないものを確認します。

費用を下げるには、独自開発を減らすだけでなく、カード情報の非保持化、接続先の優先順位付け、標準機能の採用、段階移行によって対象範囲を明確にすることが有効です。最安値だけでなく、承認率、停止時間、障害時の損失、将来の仕様変更費用まで含めて投資対効果を評価します。

▶ 詳細はこちら：オーソリシステム開発の見積相場・費用

開発会社・サービスはどのように選びますか？

開発会社やサービスは、知名度や提案書の見栄えだけで決めず、担当できる役割と実績を確認します。オーソリ本体の判定基盤を作れるのか、国内ネットワークや国際ブランドとの接続が得意なのか、不正検知や可用性基盤を補完するのかによって、比較対象は変わります。

「決済実績があります」という説明だけでは不十分です。CAFISやCARDNETなどの国内網、国際ブランド網、PSP、3-Dセキュア、不正検知、HSM、トークン、既存メインフレームのどこまで経験があるかを確認します。さらに、実案件でのピークTPS、平均・最大応答時間、障害時の切替時間、年間停止時間、承認率への影響を、可能な範囲で数値や試験結果として提示してもらいます。

PCI DSSの対象範囲、カード情報を保持する場所、トークンの発行・返却、暗号鍵とHSMの責任、脆弱性対応、ログ監査、アクセス権、インシデント発生時の連絡時間を確認します。開発会社が認証を取得しているかだけでなく、自社と委託先のどちらがどの要件を満たすのかを責任分界表に落とします。2024年に公表されたPCI DSS v4.0.1は、要件の誤記修正や明確化を含む改訂です。最新版はPCI Security Standards Councilの公式文書一覧で確認します。

本番移行では、データ移行、並行稼働、照合、切り戻し、利用者や加盟店への影響、障害時の連絡体制が成否を左右します。提案段階で、切替リハーサル、テストデータの準備、日次照合、障害訓練、監視引き継ぎ、ブランド仕様変更への対応方法を確認します。契約終了時にトークンやログをどの形式で返却できるかも、将来のロックインを避ける重要な質問です。

▶ 詳細はこちら：オーソリシステム開発でおすすめの開発会社6選と選び方

発注・外注で失敗しないRFPのポイントは何ですか？

RFPでは、機能一覧だけでなく、取引量、ピーク性能、障害時の状態、セキュリティ責任、移行条件、運用時間まで具体化します。要件が曖昧なまま複数社へ見積を依頼すると、各社が想定する範囲が違うため、金額だけでなく納品物や運用負担も比較できなくなります。

最低限、対象業務をイシュア・アクワイアラ・加盟店ゲートウェイに分け、承認、拒否、取消、売上確定、返金、照合の範囲を記載します。月間件数、ピークTPS、p95やp99の応答時間、同時接続数、承認率、稼働率、RTO・RPO、2センターの有無、障害時代行の条件も明記します。接続先、電文形式、本人認証、不正検知、会員・与信・請求基幹、テスト環境の条件を添えると、見積の前提がそろいます。

準委任、請負、ライセンス、マネージドサービスでは、成果物、責任範囲、変更管理、障害対応の考え方が異なります。請負であっても、接続先の仕様変更、性能要件の追加、カード情報の保持範囲の変更、法令やブランド仕様の改定が追加費用になる場合があります。納品判定、受入試験、瑕疵対応、SLA、再委託、秘密保持、監査協力、契約終了時のデータ・トークン返却を契約書で確認します。

提案書の評価では、画面数や機能数よりも、タイムアウト後の再送、二重送信、リバーサル、カード会社停止、ネットワーク分断、誤判定、データ不整合をどのように扱うかを確認します。可能であれば、サンプル電文や状態遷移図、障害時のシーケンス、性能試験の条件、切替と切り戻しの手順を提示してもらいます。開発完了後に運用担当者が自走できるよう、監視項目、アラート基準、エスカレーション、鍵更新、脆弱性対応、監査証跡も成果物に含めます。

▶ 詳細はこちら：オーソリシステム開発の発注・外注・委託方法

セキュリティと可用性はどのように設計しますか？

オーソリシステムは、カード情報を扱うセキュリティと、決済を止めない可用性を同時に満たす必要があります。安全対策を後工程に回すと、カード情報の流れやログの取り方を変更できず、PCI DSSの対象範囲や監査コストが膨らみます。

カード番号などのPANを自社で保存・処理・伝送するのか、トークン化して非保持化するのかを最初に決めます。保持する場合は、暗号化、鍵管理、HSM、マスキング、アクセス制御、脆弱性管理、監査ログ、バックアップ、委託先管理の対象が広がります。保持しない場合でも、決済ページ、API、管理画面、ログ、ブラウザや端末の脆弱性対策が不要になるわけではありません。

経済産業省は2025年3月に「クレジットカード・セキュリティガイドライン」を改訂し、カード会社、加盟店、PSPなどの関係事業者が漏えいと不正利用の防止に取り組む実務上の指針を示しています（出典: 経済産業省「クレジットカード・セキュリティガイドライン」、2025年）。EMV 3-Dセキュアや不正ログイン対策を含むため、オーソリ単体ではなく決済経路全体で確認します。詳細は経済産業省のセキュリティガイドライン改訂案内を参照します。

決済を止めないためには、東西2センターや複数AZの冗長化、ネットワーク経路の分離、データベースの複製、監視、フェイルオーバー、バックアップ、切替訓練を組み合わせます。ただし、二重化すれば自動的に安全になるわけではなく、二重送信や重複承認を防ぐ整合性設計が必要です。障害時に承認を続けるスタンドインを採用する場合は、承認上限、対象取引、リスクルール、後続照合、復旧後のリバーサルまで定義します。

運用開始後は、承認率、拒否率、タイムアウト率、p95・p99応答時間、ピークTPS、キュー滞留、再送件数、リバーサル件数、障害復旧時間、照合差異を継続的に監視します。数値の変化を追えるように、取引ID、相関ID、ルール判定、外部応答、再処理履歴を監査ログに残します。ログにはカード情報を直接出さず、必要な情報だけをマスキングして保存します。監視の通知先、一次対応、二次対応、経営報告の基準も運用設計書に記載します。

オーソリシステムに関するよくある質問

最後に、企画や発注時に特に多い疑問へ回答します。自社が決済APIを追加したいのか、決済基盤そのものを刷新したいのかを整理すると、必要な機能と費用を判断しやすくなります。

同じものではありません。オーソリシステムは、決済要求に対して承認・拒否を返す信用照会の基盤です。売上確定、清算、請求、入金、返金、本人認証、不正検知などは関連しますが、処理主体や目的が異なります。発注時には決済全体のうち、どこまでを対象にするかを明記します。

既存の決済代行APIへ接続するだけなら、企画初期の目安は300万円〜1,000万円程度です。ただし、これは標準的な承認・取消・返金などに対象を絞った場合の推定で、独自の利用枠、複数ブランド、国内網接続、2センター、24時間運用、PCI DSS対応を含めると大きく上がります。金額だけで判断せず、含まれる接続、テスト、運用、保守、仕様変更を確認します。

クラウドを採用するだけで自動的にPCI DSS準拠になるわけではありません。クラウドの認証範囲を確認したうえで、自社が管理するアプリケーション、設定、アクセス権、カード情報の流れ、ログ、脆弱性対策、委託先管理を含めて評価します。カード情報をトークン化して対象範囲を小さくする方法はありますが、決済画面やAPIの安全対策が不要になるわけではありません。

過去12か月の取扱件数と時間帯別の実績を集め、キャンペーンや繁忙期の増加率、将来の事業計画を加えてピークTPSを設定します。平均応答時間だけでなく、p95やp99、タイムアウト率、同時接続数、外部接続先の制約も確認します。試験環境で通常時・ピーク時・障害時を再現し、性能目標をSLAと受入条件に結び付けることが重要です。

まず、決済のどの立場にいるか、対象チャネル、接続先、月間件数、ピークTPS、必要な応答時間、カード情報の保持範囲、既存基幹、稼働時間、障害時の目標を1枚に整理します。次に、承認・拒否だけでなく、取消、リバーサル、再送、返金、照合、切り戻しの業務フローを作ります。この資料があれば、開発会社やサービスへ同じ条件で相談でき、見積の比較と方式選定が進めやすくなります。

まとめ

オーソリシステムは、カード決済の要求に対して承認・拒否を返すリアルタイム基盤です。決済API接続、加盟店向けゲートウェイ、アクワイアラ側の処理、イシュア側の与信・利用枠管理では必要な機能が異なるため、最初に対象範囲を分けることが重要です。

方式選定では、PSP・決済代行API、パッケージ、クラウド、スクラッチを、自由度だけでなくPCI DSSの対象範囲、接続実績、性能、可用性、移行難易度、3〜5年のTCOで比較します。費用は300万円〜1,000万円程度のAPI接続から、数億円以上のカード基幹刷新まで幅があるため、見積を「一式」で受けず、機能、接続、性能、セキュリティ、BCP、移行、運用に分解します。

開発を始める前に、対象業務、接続先、取扱件数、ピークTPS、応答SLA、カード情報の扱い、RTO・RPO、障害時の代行、移行・切り戻し、保守時間を整理します。正常系だけでなく、タイムアウト、二重送信、リバーサル、ネットワーク分断、監査ログ、契約終了時のデータ返却まで確認しておくと、後からの手戻りを抑えられます。

▼関連記事一覧
・オーソリシステム開発の進め方
・オーソリシステム開発でおすすめの開発会社6選と選び方
・オーソリシステム開発の見積相場・費用
・オーソリシステム開発の発注・外注・委託方法