オーソリシステムの発注・外注は、決済APIをつなぐだけなら数百万円から、自社のカード基幹まで刷新するなら数億円以上になるため、最初に開発範囲と発注形態を分けて整理することが成功のポイントです。
本記事では、オーソリシステムを外部へ委託する際の進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積比較、障害時の責任分界まで順番に解説します。2026年時点で公表されている決済基盤の事例や制度も踏まえ、初期費用だけで判断しないための実務的な確認ポイントをまとめます。
▼全体ガイドの記事
・オーソリシステム開発の完全ガイド
オーソリシステムを外注する前に知っておきたい全体像

オーソリシステムは、カード決済の要求を受けた時点で、カードや会員、加盟店、利用可能枠、リスク情報などを確認し、承認または拒否を返すリアルタイム処理基盤です。売上確定、清算、請求、加盟店への入金までを一つの仕組みで指す言葉ではないため、外注の最初に「何を作るのか」を定義する必要があります。
オーソリと決済全体を分けて発注範囲を決めます
一般的なカード取引では、店舗やECの端末から加盟店サーバー、決済代行会社、CAFISやCARDNETなどの国内決済ネットワーク、国際ブランド網を経由して、アクワイアラまたはイシュアの処理基盤に要求が届きます。そこでオーソリ判定が行われ、応答が加盟店側へ戻ります。NTTデータのCAFISセンタ間接続も、加盟店や決済代行事業者の決済サーバーとCAFISを接続し、カード会社への与信照会をオンライン処理するサービスとして説明されています。出典は株式会社NTTデータ「CAFISセンタ間接続」(2026年確認)です。
この流れのうち、加盟店向けのゲートウェイだけを外注するのか、カード会社側の利用可能枠や残高を持つイシュアプロセッシングまで作るのかで、必要な専門性と費用が大きく変わります。3-Dセキュアは本人認証、不正検知はリスク判断、売上確定は承認済み取引を後続処理へ送る機能です。オーソリと関連しますが、同じ機能として見積にまとめないことが大切です。
イシュア側かアクワイアラ側かで必要な要件が変わります
カードを発行するイシュア側では、会員情報、利用可能枠、残高、利用停止、分割や継続課金などの判定を正確に扱う必要があります。加盟店契約を管理するアクワイアラ側では、加盟店、端末、決済チャネル、ブランドごとの接続や、複数の仕向先へのルーティングが中心になります。両方を接続する場合は、データ項目の責任分界と障害時の連絡経路もRFPに書きます。
さらに、承認と拒否だけでなく、タイムアウト、再送、重複取引、取消、リバーサル、部分承認、ネットワーク分断、カード会社の休止を扱う状態設計が欠かせません。通常時の応答が速くても、タイムアウト後に同じ取引を二重計上すれば、加盟店や会員への返金対応が発生します。発注前に正常系と例外系を一枚の状態遷移図へ落とし込みます。
オーソリシステムの発注形態はどれを選ぶべきですか?

結論として、既存PSPを使える加盟店の決済導入は決済代行API連携、独自の与信やカード発行を持つ事業者はパッケージやプロセッサ、競争力のある判定ロジックを内製したい事業者はクラウドまたは段階的なスクラッチ開発が候補です。最初から全機能を自社開発するのではなく、差別化したい部分と標準化できる部分を分けて選びます。
PSP・パッケージ・クラウドを使う発注
PSPや決済代行APIを利用する方式は、カード情報を自社環境に保持しない構成を取りやすく、短期間で導入しやすい方式です。既存の会員・注文システムに承認、取消、返金、Webhookを組み込む案件なら、オーソリ判定コアや国内網接続を自社で持つ必要がありません。ただし、独自の利用枠、複雑なカード発行、リアルタイムのリスク判定を自社競争力にする場合は、APIの制約やデータ取得範囲を先に確認します。
パッケージやプロセッサは、電文、カードブランド接続、会員・利用枠、標準判定、監視機能を活用しやすい方法です。標準機能で対応できる範囲が広ければ開発期間を抑えられますが、標準外の変更が多いと追加開発と製品ロックインが膨らみます。クラウドは、API Gateway、コンテナ、分散データベース、ストリーミング、キャッシュ、HSM、監視を組み合わせてピーク時の拡張を行いやすい方法です。
スクラッチ開発と段階的なモダナイズ
スクラッチ開発は、独自のカード商品、与信、利用枠、不正判定、承認率改善などを自社の競争力にしたい場合に適しています。一方で、国際ブランドや国内網との接続、ISO 8583などの電文変換、HSM、監査ログ、24時間365日の運用を一から整備する必要があります。技術的に作れることと、金融取引を止めずに運用できることは別の評価軸です。
既存のメインフレームや会員・請求基幹を残し、電文ゲートウェイ、リスク判定、残高・枠照会、管理画面などを分けて順次移行する方法もあります。TISとKort Valutaは、AWSジャパンの技術支援を受け、オーソリゼーションシステムのクラウド化と運用内製化に向けた共同開発を2025年に開始しました。2026年8月時点で、これはクラウド型オーソリ基盤へ移行する事例として参考になりますが、個別案件にそのまま適用できる価格やSLAを示すものではありません。出典はTIS株式会社「TISとKort Valuta、決済システムの内製化に向けた共同開発を開始」(2025年)です。
RFPと要件整理はどのように進めますか?

RFPは、機能一覧だけを並べる文書ではありません。自社がどの取引を、どのチャネルで、どの性能と可用性で処理したいのかを同じ条件で比較するための文書です。オーソリ本体、周辺基幹、外部接続、運用、セキュリティ、移行を分けて書くと、見積の抜けとベンダーごとの前提差を見つけやすくなります。
対象範囲・取扱量・性能を数値で書きます
まず、イシュア側、アクワイアラ側、加盟店向けゲートウェイのどこが対象かを明記します。続いて、月間取引件数、通常時とピーク時のTPS、同時接続数、平均と最大の応答時間、承認率、接続するブランドや国内網、取消・返金・継続課金の有無を書きます。「高速」「大量処理」ではなく、例えばピーク時TPS、95パーセンタイル応答時間、年間停止許容時間のように測定できる項目にします。
可用性では、RTOとRPO、東西2センターの構成、フェイルオーバーの条件、スタンドイン承認の範囲、復旧後の再処理と照合方法を指定します。NTTデータはCAFISについて東京・大阪の2センター構成と、カード会社センターの休止や故障時の代行処理を案内しています。自社が同等の仕組みを持つのか、外部サービスに任せるのかを切り分け、責任分界をRFPに残します。
セキュリティと例外処理を要件に含めます
カード番号を自社で保存・処理・伝送するのか、トークン化して非保持化するのかで、PCI DSSの対象範囲が変わります。PANのマスキング、暗号鍵、HSM、アクセス権、監査ログ、脆弱性診断、ペネトレーションテスト、委託先の監査報告を要件化します。PCI Security Standards Councilの文書ライブラリでは、PCI DSS v4.0.1が掲載されているため、採用する版と準拠確認の方法を発注書類に記載します。出典はPCI Security Standards Council「PCI DSS Document Library」(2026年確認)です。
例外処理は、タイムアウトした取引を再送してよい条件、重複を識別するキー、二重承認を防ぐ仕組み、リバーサルで利用枠を戻すタイミング、外部の不正検知が遅れたときの扱いまで決めます。テスト項目に「承認された」だけを入れると、実運用で起きる障害を見落とします。正常系、拒否系、遅延系、切替系を分けた試験計画を提案依頼に含めます。
納品物と発注者側の役割も明記します
RFPには、要件定義書、基本設計書、電文仕様書、API仕様書、データモデル、セキュリティ設計書、運用設計書、テスト計画書、移行計画書、障害対応手順書を納品物として挙げます。発注者が提供する既存仕様、テストデータ、接続先の契約情報、業務判断ルール、承認基準も明確にします。納品物が曖昧なまま開発を始めると、完成判定の基準が作れません。
また、発注者のプロダクト責任者、決済業務担当、セキュリティ担当、運用担当がどの会議に参加するかも決めます。ベンダーだけで要件を決めると、現場で必要な返金や照合の運用が抜けることがあります。週次の課題管理、変更承認、エスカレーション、受入試験の責任者を最初から決めておくと、後工程の手戻りを抑えられます。
オーソリシステムの契約形態はどう選びますか?

契約は、開発の不確実性、成果物の定義、運用の継続性を見ながら組み合わせます。要件が固まっていないのに全工程を請負契約へ入れると、追加変更の交渉が増えます。一方、稼働後の監視やブランド仕様変更を準委任だけで曖昧にすると、障害時の対応時間や費用で認識差が生まれます。
準委任契約は要件整理や伴走支援に向いています
準委任契約は、発注者と受託者が合意した業務を遂行し、要件定義、現状調査、アーキテクチャ検討、PMO、PoC、運用支援などを進める場合に向いています。オーソリの対象範囲や接続先が未確定な初期段階では、まず準委任で調査と要件整理を行い、成果物と受入条件が固まった工程から請負へ移す方法が現実的です。
ただし、準委任だから成果物が不要という意味ではありません。会議体、稼働時間、担当者、調査項目、作成する要件書、意思決定の期限、前提条件を契約書や個別契約書に残します。性能の実測や接続試験など、受託者の作業結果を確認する方法も決めておくと、次工程の見積精度が高まります。
請負・ライセンス・マネージドサービスを分けます
請負契約は、決められた成果物を納期と金額に基づいて完成させる方式です。基本設計、実装、テスト、移行など、要件と受入条件が明確な工程に適します。何が仕様変更で、何が受託者の瑕疵対応か、性能未達や障害の修補期限をどうするかを契約に定めます。特にピークTPS、応答時間、重複防止、切替試験は、納品後に測れる形で記載します。
パッケージやプロセッサを使う場合は、開発契約とは別にライセンス、接続料、保守、バージョンアップ、ブランド仕様変更の費用が発生します。クラウド型やマネージドサービスでは、利用料、データ転送、監視、障害対応、バックアップ、ログ保管、鍵管理の範囲を確認します。契約終了時のトークン、設定、監査ログ、移行支援の扱いも、導入時から決めておく必要があります。
SLAとセキュリティ責任分界を契約に入れます
SLAでは、稼働率だけでなく、通常時とピーク時の応答時間、障害検知時間、一次回答時間、復旧目標、計画停止、再処理の期限を決めます。オーソリは数秒の遅延でも加盟店の離脱や承認率の低下につながるため、「システムが稼働している」だけでは十分ではありません。CAFISの案内では、加盟店決済サーバーからカード会社等を経由して戻る時間を2秒程度と説明していますが、机上値であり、自社案件のSLAへそのまま転記しないことが重要です。
セキュリティでは、カード情報を扱う環境、暗号鍵とHSM、脆弱性対応、アクセス権、ログ、インシデント報告、監査対応の担当を分けます。経済産業省は2025年3月にクレジットカード・セキュリティガイドラインを改訂し、同ガイドラインを割賦販売法に基づくセキュリティ対策の実務上の指針と位置付けています(出典: 経済産業省「『クレジットカード・セキュリティガイドライン』が改訂されました」、2025年)。委託先の準拠証明だけでなく、自社側に残る責任も確認します。
オーソリシステムの費用相場はいくらですか?

オーソリシステムの公開された一律価格はほとんどないため、以下は2026年時点の企画初期に使える推定レンジです。PSP接続なら300万〜1,000万円、CAFISやCARDNETなどへのゲートウェイ接続なら1,000万〜3,000万円、パッケージやクラウド型プロセッサの導入なら2,000万〜8,000万円、自社オーソリ基盤の新規構築なら5,000万円〜3億円が目安です。複数ブランド、2センター、既存基幹移行、24時間運用まで含めると、数億円から数十億円以上になります。
方式別の初期費用と開発期間を比較します
既存PSPへのAPI連携は、会員・注文基盤があり、承認、取消、返金、Webhookを組み込む範囲なら2〜4か月程度が目安です。国内決済網との接続や電文変換、接続試験、再送処理まで含めると4〜8か月程度、パッケージやクラウド型プロセッサを基幹へ連携する場合は6〜12か月程度を見込みます。自社オーソリ基盤の新規構築は、12〜24か月以上を想定し、移行や並行稼働まで含めるとさらに長くなります。
費用差の理由は、画面数ではなく、接続先、取引量、状態管理、可用性、セキュリティ、試験、移行、運用にあります。経済産業省の2026年API連携検討資料でも、API未対応事業者の初期対応は接続先や仕様によって数億円規模、オープンAPIでは数十億円から100億円規模という意見が示されています。一方、API対応済み事業者が接続先を追加する場合は、前提によって1社あたり数十万〜数千万円という整理です(出典: 経済産業省「第3回クレジットカード分野に係るAPI連携の推進に関する検討会」、2026年)。これはオーソリ本体の定価ではありませんが、既存基盤の活用可否が費用の桁を左右する近接領域のベンチマークです。
ランニング費用を含む3〜5年TCOで判断します
初期開発費とは別に、クラウド、ネットワーク、データベース、メッセージング、HSM、ログ保持、バックアップ、監視の費用が発生します。規模によって月額数十万〜数百万円以上となり、ピークTPS、データ転送量、ログの保管期間、冗長化方式で変動します。24時間365日の監視、障害対応、運用訓練は年間数百万円から数千万円規模になることがあり、専任体制や複数拠点を組む場合はさらに上がります。
PCI DSS対応、脆弱性診断、ペネトレーションテスト、監査支援、ブランド仕様変更、3-Dセキュアや不正検知エンジンの更新、OS・ミドルウェアの保守、データ移行支援もTCOに含めます。見積書には、要件定義、電文・接続、判定ロジック、基幹連携、性能試験、セキュリティ、移行、監視、保守を別行で記載してもらいます。「オーソリ機能一式」だけの見積は、比較するには情報が不足しています。
委託先の選定と見積比較で見るべきポイント

委託先は知名度や単価だけでなく、担当できる役割で比較します。大手SIは大規模基幹と運用統合、決済専門会社は電文・国内網接続、クラウド事業者は拡張性とマネージドサービス、不正検知事業者は判定精度や運用改善に強みがあります。オーソリ本体を受託できるのか、ゲートウェイや不正検知など周辺機能が中心なのかを確認します。
接続実績と性能の裏付けを確認します
候補会社には、CAFIS、CARDNET、国際ブランド、PSP、3-Dセキュア、不正検知、HSMのどこに接続実績があるかを聞きます。イシュアとアクワイアラのどちらを担当した経験があるか、ピークTPS、応答SLA、承認率、2センター構成、フェイルオーバー、スタンドイン、障害訓練の実績も確認します。実績紹介の会社名だけでなく、対象範囲、取扱量、稼働年数、現在の保守体制まで聞くことが重要です。
提案段階では、正常系のデモだけで判断しません。タイムアウト後の再送、二重送信、リバーサル、遅延した外部判定、カード会社停止、通信断、センター切替、復旧後の照合をどのように設計するかを質問します。性能試験の環境、データ量、負荷条件、測定方法、結果の提出時期を見積条件へ入れると、数字の根拠を比較できます。
見積は同じ前提・同じ分解で比較します
複数社へRFPを配布する際は、取引件数、ピークTPS、応答時間、接続先、既存基幹、カード情報の保持方針、2センター、監視時間、受入試験の条件を統一します。各社の前提条件、対象外、追加費用の発生条件、再見積のトリガーを一覧化します。安い提案でも、性能試験、移行、監視、ブランド仕様変更が対象外なら、実際のTCOは高くなる可能性があります。
見積比較表では、初期開発、ライセンス、接続、クラウド、HSM、セキュリティ、テスト、移行、教育、24時間運用、保守、仕様変更、終了時の移行支援を分けます。価格だけでなく、発注者側に残る作業量と、ベンダー交代時に持ち出せる設計書・テスト資産・トークンの範囲も評価します。契約期間中の変更単価や最低利用期間も確認します。
移行・運用・終了時まで見て選びます
既存基盤から移行する場合は、会員、カード、利用可能枠、加盟店、端末、取引履歴、トークン、監査ログのどれを移すかを決めます。シャドートラフィック、カナリアリリース、並行稼働、日次照合、ロールバック、切戻し条件を移行計画に入れます。切替当日に問題が出た場合、誰が停止を判断し、どのデータを正とし、どの取引を再処理するかを事前に訓練します。
運用では、監視項目、アラートの閾値、エスカレーション先、鍵更新、脆弱性対応、ブランド仕様変更、障害訓練、監査証跡の保管を確認します。契約終了時には、トークンを別環境へ移行できるのか、データをどの形式で返却するのか、消去証明を出せるのかも重要です。導入時の安さだけでなく、5年後に選択肢を残せる委託先を選びます。
2026年時点で外注時に確認したい最新動向

オーソリシステムは、カード情報を守りながら、決済量の増加や新しい接続方式へ対応する必要があります。発注者は「クラウドだから安全」「PCI DSS準拠の会社だから自社の対応は不要」と決めつけず、データの所在、責任共有、監査証跡、障害時の代替処理を確認します。
クラウド化とAPI連携は責任分界まで確認します
AWSが2025年に公開したクレジットカード決済処理のリファレンスでは、アクワイアラ側とイシュア側の両方について、API Gateway、ストリーミング、コンテナ、分散データベース、キャッシュ、HSM、暗号化を組み合わせる構成が紹介されています。毎秒数千件へ拡張する構成例も示されていますが、これは特定クラウドの参照アーキテクチャであり、導入案件の性能保証ではありません。候補会社には、自社の取引量と応答要件で実測した結果を提出してもらいます。出典はAmazon Web Services「AWSでのクレジットカード決済処理プラットフォームの構築」(2025年)です。
経済産業省の2026年API連携検討では、カードデータの連携を進める方向性や課題、工程が整理されています。API対応を進める場合も、既存のメインフレーム、会員・請求基幹、決済網との接続を一度に置き換える必要はありません。外部API、電文ゲートウェイ、会員照会、判定エンジンを分離し、どこから移行するかを提案に求めると、段階的な発注がしやすくなります。
ガイドラインとPCI DSSの適用範囲を分けます
経済産業省のクレジットカード・セキュリティガイドラインは、カード情報の漏えいと不正利用を防ぐため、カード会社、加盟店、決済代行会社などの関係事業者が実施すべき対策を整理したものです。PCI DSSは国際的なカード会員データのセキュリティ基準であり、どのシステムがカード会員データ環境に該当するかを設計で確認します。二つを同じものとして扱わず、契約、監査、報告の要求を分けます。
経済安全保障の基幹インフラ制度についても、対象事業者や設備の条件があるため、すべてのオーソリシステム開発へ一律に事前審査が必要と断定しないことが大切です。自社が対象となる可能性、委託先の再委託、設備の導入・維持管理、データ所在を法務・セキュリティ担当と確認します。制度対応の有無を見積条件に含める場合は、対象判断の前提を文書化します。
オーソリシステムの発注・外注でよくある質問

オーソリシステムの外注では、費用、開発期間、委託先の専門性、セキュリティ責任の質問が多くなります。ここでは、発注前に特に確認されやすい質問へ直接回答します。
オーソリシステムの外注費用は最低いくらですか?
既存PSPのAPI連携だけなら、要件や既存基盤の状態によって300万〜1,000万円程度が企画初期の目安です。国内網接続や独自のオーソリ判定、2センター、移行、24時間運用まで含めると、1,000万円台から数億円以上へ広がります。公開定価ではなく、取引量、接続先、性能、セキュリティ、運用の前提で変わる推定レンジとして扱います。
オーソリシステムは内製と外注のどちらがよいですか?
独自の与信やリスク判定を競争力にしたい場合は、コアの内製と外部の専門支援を組み合わせる方法が適しています。国内網接続、電文変換、HSM、監視、24時間対応などをすべて内製するには、専門人材と継続的な運用体制が必要です。PSPやパッケージで標準部分を外部化し、判定ルールやデータ活用に集中する段階的な方式も有力です。
委託先にはどのような実績を確認すべきですか?
CAFISやCARDNET、国際ブランド、イシュア・アクワイアラのどちらに接続した経験があるかを確認します。さらに、ピークTPS、応答SLA、2センター、スタンドイン、タイムアウトやリバーサルの試験、PCI DSSの責任分界、移行と切戻し、稼働後の監視・保守を聞きます。会社名や導入件数だけでなく、自社の取引量と要件に近い実績かを見極めることが重要です。
RFPが未完成でも見積を依頼できますか?
依頼できますが、未確定の範囲を明示して、要件整理や現状調査を先行する提案を求めることが大切です。取引量、接続先、対象範囲、性能、カード情報の扱い、可用性の前提が未定のまま総額だけを比較すると、後から追加費用が発生しやすくなります。まず準委任で要件定義を行い、その成果をもとに開発工程を請負または別契約にする方法を検討します。
まとめ

オーソリシステムの発注・外注では、まずオーソリ判定、決済ゲートウェイ、3-Dセキュア、不正検知、売上確定、清算、請求の範囲を分けます。そのうえで、イシュア側かアクワイアラ側か、PSP・パッケージ・クラウド・スクラッチのどこを選ぶかを判断します。RFPには取扱量、ピークTPS、応答SLA、RTO・RPO、接続先、例外処理、PCI DSS、移行、運用を数値と成果物で書きます。
初期費用ではなく運用まで含めて比較します
費用は、PSP接続の300万〜1,000万円から自社基盤の5,000万円〜3億円、大規模刷新の数億円以上まで幅があります。これは公開定価ではなく、接続先、取扱量、既存基幹、二重化、セキュリティ、移行、監視を含むかで変わる推定値です。複数社の見積を同じ分解で比較し、3〜5年のTCO、障害時の対応、契約終了時のデータ移行まで確認します。
最初の相談では要件整理から始めます
候補会社へ相談する際は、決済チャネル、取引件数、ピーク時間帯、現在の基幹構成、接続先、カード情報の保持方針、必要な稼働時間、困っている障害や運用課題を整理しておくと、提案の精度が高まります。オーソリシステムは承認を返すだけの機能ではなく、承認率、顧客体験、不正利用、事業継続を同時に支える基盤です。自社に必要な範囲を明確にしてから、発注形態と委託先を選びます。
▼全体ガイドの記事
・オーソリシステム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。
