オーソリシステム開発の発注/外注/依頼/委託方法について

オーソリシステムの発注は、対象範囲を決め、発注方式と契約形態を選び、性能や運用の条件を指定したうえで、必要な基盤を段階的に組み立てる流れで進みます。最初に範囲を定めておくと、委託先ごとの見積も同じ前提で比べやすくなります。

▼全体ガイドの記事
・オーソリシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

オーソリシステムを外注する前に知っておきたい全体像

オーソリシステムは、カード決済の要求を受けて、カードや会員、加盟店、利用可能枠、リスク情報を確認し、承認または拒否を返すリアルタイム処理基盤です。

なお、オーソリは、売上確定、清算、請求、加盟店への入金までを指す言葉ではありません。そのため、外注の前に、構築する範囲を定めておく必要があります。

オーソリと決済全体の発注範囲の切り分け

発注範囲を決めるには、一般的なカード取引がどの経路を通り、どこで機能を分担しているかを押さえておく必要があります。

1. 一般的な取引では、店舗やEC端末から加盟店サーバー、決済代行会社へ要求が送られます。
2. CAFISやCARDNETなどの国内網と国際ブランド網を経由します。
3. アクワイアラまたはイシュアの基盤で判定し、応答を加盟店側へ返します。

たとえば、NTTデータのCAFISセンタ間接続は、加盟店や決済代行事業者のサーバーとCAFISをつなぎ、カード会社への与信照会をオンラインで処理するサービスです（出典：株式会社NTTデータ「CAFISセンタ間接続」、2026年確認）。

加盟店向けゲートウェイだけを対象にするか、利用可能枠や残高を持つイシュアプロセッシングまで含めるかで、必要な専門性と費用が変わります。

3-Dセキュア、不正検知、売上確定は、本人認証、リスク判断、承認済み取引の後続処理をそれぞれ担います。そのため、オーソリとは分けて見積もります。

イシュア側とアクワイアラ側で変わる必要要件

発行側と加盟店契約側では扱う業務が異なるため、必要な要件もそれぞれ分けて整理します。

• イシュア側：会員、利用可能枠、残高、利用停止、分割や継続課金を判定します。
• アクワイアラ側：加盟店、端末、決済チャネル、ブランド接続、仕向先へのルーティングを扱います。
• 両側の接続：データ項目の責任分界と、障害時の連絡経路をRFPに記します。
• 例外処理：タイムアウト、再送、重複、取消、リバーサルを設計します。部分承認、ネットワーク分断、カード会社の休止への対応も含めます。

たとえば、タイムアウト後に同じ取引を二重計上すると、加盟店や会員への返金対応が発生します。そのため、発注前に正常系と例外系を一枚の状態遷移図にまとめておきます。

オーソリシステムの発注形態の選び方

既存のPSPを使う加盟店はAPI連携が、独自の与信やカード発行を持つ事業者はパッケージやプロセッサが候補になります。

これに対して、判定ロジックを競争力にする事業者は、クラウドや段階的なスクラッチ開発を検討します。

差別化する部分と標準化できる部分を分けて選ぶことで、全機能を自社開発せずに済みます。

PSP・パッケージ・クラウドを使う発注

選択の目安は、既存基盤や自社で持ちたい機能によって異なります。

• PSP・決済代行API：会員・注文基盤へ承認、取消、返金、Webhookを組み込む案件に向きます。
• パッケージ・プロセッサ：電文、ブランド接続、会員・利用枠、標準判定、監視を活用する方式です。
• クラウド：API Gateway、コンテナ、分散データベースを組み合わせます。ストリーミング、キャッシュ、HSM、監視も含めて構成します。

PSPは、カード情報を自社環境に保持しない構成を取りやすく、短期間で導入できる方式です。一方で、独自の利用枠、複雑なカード発行、リアルタイム判定を競争力にしたい場合は、APIの制約とデータ取得範囲を先に確かめる必要があります。

パッケージは、標準機能で対応できる範囲であれば期間を抑えられます。ただし、標準外の変更が増えると、追加開発と製品へのロックインが膨らみます。

クラウドは、ピーク時に拡張しやすいのが特徴です。一方で、基盤費はTPS、転送量、ログ保管期間、冗長化によって変わります。

スクラッチ開発と段階的なモダナイズ

独自機能を競争力にしたい場合と、既存基盤を段階的に移行したい場合とで、開発の進め方が変わります。

• スクラッチ開発：独自カード商品、与信、利用枠、不正判定、承認率改善を自社の強みにできます。
• 運用基盤の整備：国際ブランド・国内網接続、ISO 8583電文変換、HSM、監査ログ、24時間365日運用も必要です。
• 段階的な移行：既存メインフレームや会員・請求基幹を残し、機能を順に分けて移します。

たとえば、TISとKort ValutaはAWSジャパンの技術支援を受け、オーソリゼーションシステムのクラウド化と運用内製化に向けた共同開発を2025年に始めています（出典：TIS株式会社「TISとKort Valuta、決済システムの内製化に向けた共同開発を開始」、2025年）。

段階移行では、電文ゲートウェイ、リスク判定、残高・枠照会、管理画面を順に分けて移せます。ただし、開発の可能性と、金融取引を止めずに運用できるかは、別々に評価します。

上記の移行事例は、2026年8月時点で参考になるものですが、個別案件に適用できる価格やSLAを示すものではありません。

RFPと要件整理の進め方

RFPは、取引、チャネル、性能、可用性を同じ条件で比べるための文書です。オーソリ本体、周辺基幹、外部接続、運用、セキュリティ、移行を分けて書くと、見積の抜けや前提の違いに気づけます。

対象範囲・取扱量・性能の数値化

対象範囲、取扱量、応答性能、可用性は、測定できる条件で記します。

• 対象と取扱量：イシュア側、アクワイアラ側、加盟店向けの別、月間件数、通常・ピークTPS、同時接続数を示します。
• 性能と接続：平均・最大応答時間、承認率、ブランド・国内網、取消・返金・継続課金の有無を明記します。
• 可用性：RTO・RPO、東西2センター、切替条件、スタンドイン、復旧後の再処理と照合を定めます。

「高速」といった表現では判断できないため、ピークTPS、95パーセンタイル応答時間、年間停止許容時間など、測定可能な値で定めます。

NTTデータはCAFISの東京・大阪2センター構成と、カード会社センターの休止・故障時の代行処理を案内しています。このように、外部の仕組みを使う場合は、自社と外部の担当を分けてRFPに残します。

セキュリティと例外処理の要件化

カード情報の扱いと障害時の動きは、要件として条件を明記しておきます。

• 情報保護：PANのマスキング、暗号鍵、HSM、権限、監査ログ、脆弱性診断を要件に含めます。
• 準拠確認：PCI DSS v4.0.1の採用版と確認方法を、発注書類に記します。
• 例外試験：再送、重複防止、リバーサル、遅延判定を含めた試験計画を求めます。

PCI DSSの対象範囲は、カード番号を保存・処理・伝送するか、トークン化して非保持化するかで変わります。また、委託先の監査報告やペネトレーションテストも確認します。

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：稼働率、応答時間、検知・一次回答時間、復旧目標、計画停止、再処理期限を定めます。
• 情報保護：カード情報環境、暗号鍵、HSM、脆弱性対応、権限、ログの担当を分けます。
• 事故・監査：事故報告や監査対応を定め、委託先と自社の責任範囲を確認します。

数秒の遅延も、加盟店の離脱や承認率の低下につながります。CAFISは、加盟店の決済サーバーからカード会社などを経て戻る時間を2秒程度と案内しています。ただし、この机上値を自社のSLAにそのまま転記しないようにします。

委託先の準拠証明を受け取るだけでは足りず、自社に残る責任も確認します。

オーソリシステムの費用相場

一律の公開価格はほぼないため、次に示すのは2026年時点の企画初期向けの推定レンジです。PSP接続は300万〜1,000万円、国内網ゲートウェイは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は数十億円から100億円規模との意見が示されています。

対応済みの事業者が接続先を追加する場合は、前提によって1社あたり数十万〜数千万円と整理されています（出典：経済産業省「第3回クレジットカード分野に係るAPI連携の推進に関する検討会」、2026年）。

これらは既存基盤を活用できるかで変わる近接領域の参考値で、オーソリ本体の定価ではありません。

ランニング費用を含む3〜5年TCOでの判断

初期費用だけでなく、3〜5年の運用・保守費を加えたTCOで比べます。

• 基盤費：クラウド、通信、DBの費用が発生します。メッセージング、HSM、ログ、バックアップ、監視も対象です。
• 運用費：24時間365日監視や障害対応は、年間数百万円から数千万円規模の場合があります。
• 更新・監査費：PCI DSS、脆弱性・侵入診断、監査支援、ブランド変更を含めます。3-Dセキュア、不正検知、OS・ミドルウェア保守、移行支援も対象です。

基盤費は月額で数十万〜数百万円以上になり、TPS、転送量、ログ保管期間、冗長化によって変わります。また、専任体制や複数拠点を設けると、運用費はさらに上がります。

見積は、要件定義、接続、判定ロジック、基幹連携の項目を別行で記載してもらいます。性能試験、安全性、移行、監視、保守も、項目ごとに分けてもらいます。

「オーソリ機能一式」とだけ書かれた見積では、比較の材料が足りません。

委託先の選定と見積比較で見るべきポイント

委託先は、知名度や単価よりも、担当できる役割で比べます。たとえば、大手SIは大規模基幹と運用統合、決済専門会社は電文と国内網接続に強みがあります。

クラウド事業者は拡張性とマネージドサービス、不正検知事業者は判定精度と運用改善を得意とする傾向があります。また、オーソリ本体を担うのか、周辺機能なのかも確かめます。

接続実績と性能の裏付け

実績を確認するときは、接続先と担当範囲、障害時の設計、性能試験の根拠を見ます。

• 接続先：CAFIS、CARDNET、国際ブランド、PSPとの接続を確認します。3-Dセキュア、不正検知、HSMの接続も見ます。
• 処理実績：イシュア・アクワイアラの経験、TPS、SLA、承認率、二重化を確認します。
• 運用経験：フェイルオーバー、スタンドイン、障害訓練、稼働年数、保守体制を聞きます。

会社名よりも、対象範囲や取扱量、自社要件との近さを確かめます。

提案では、正常系のデモに加えて、タイムアウト再送、二重送信、リバーサル、遅延判定、カード会社停止、通信断をどう扱うかを質問します。

加えて、センター切替と復旧後の照合方法も確かめます。

性能試験の環境、データ量、負荷条件、測定方法、結果の提出時期を見積条件に入れておくと、数値の根拠を比べられます。

同じ前提・同じ分解による見積比較

複数の会社に同じ条件を示し、対象外や追加費用の条件まで並べて比べます。

• 前提条件：件数、ピークTPS、応答時間、接続先、既存基幹、カード情報の扱いをそろえます。
• 費用内訳：開発、ライセンス、接続、クラウドを分けて示してもらいます。HSM、安全性、試験、移行、教育も項目ごとに分けます。
• 継続条件：運用、保守、仕様変更、最低利用期間、終了時の移行支援を確認します。

2センター、監視時間、受入試験の条件もそろえておきます。なお、性能試験や移行が対象外になっている安価な提案は、TCOが高くなる可能性があります。

発注者側の作業量と、交代時に持ち出せる設計書・テスト資産・トークンの範囲も評価します。さらに、変更単価も確認しておきます。

移行・運用・終了時までの確認

移行対象と切替手順、稼働後の保守、契約終了時の引き継ぎを確かめます。

• 移行対象：会員、カード、利用枠、加盟店を移す対象として決めます。端末、履歴、トークン、監査ログも対象に含めます。
• 切替計画：シャドートラフィック、カナリア、並行稼働、日次照合、ロールバックと切戻し条件を含めます。
• 運用・終了：監視、鍵更新、障害訓練、トークン移行、データ返却、消去証明を確認します。

切替当日に備えて、停止を判断する人、正とするデータ、再処理する取引を事前に訓練しておきます。

監視の閾値と通知先、脆弱性対応、ブランド仕様変更、監査証跡の保管も確かめておきます。そのうえで、5年後も選択肢を残せる委託先を選びます。

2026年時点で外注時に確認したい最新動向

オーソリ基盤は、カード情報を守りながら、決済量の増加や新しい接続方式に対応する必要があります。そのため、データの所在、責任の共有、監査証跡、障害時の代替処理を確認します。

クラウド化とAPI連携の責任分界

クラウドの参照構成やAPIの段階導入は、見積の条件に照らして評価します。

• 性能確認：自社の取引量と応答要件で測った結果を、候補会社に求めます。
• 段階移行：外部API、電文ゲートウェイ、会員照会、判定エンジンの移行順を提案させます。
• 責任分界：クラウド事業者、委託先、自社のどこまでを担うかを、項目ごとに確認します。

AWSの2025年のリファレンスでは、両側の処理にAPI Gateway、ストリーミング、コンテナを組み合わせています。分散DB、キャッシュ、HSM、暗号化も構成に含まれます。

毎秒数千件へ拡張する構成例もありますが、これは特定のクラウドの参照構成であり、性能を保証するものではありません（出典：Amazon Web Services「AWSでのクレジットカード決済処理プラットフォームの構築」、2025年）。

経済産業省の2026年API連携検討は、カードデータ連携の方向性、課題、工程を整理しています。既存の基幹や決済網を、一度に置き換える必要はありません。

接続や判定の機能を分けて移行する提案を求めれば、段階的な発注がしやすくなります。

ガイドラインとPCI DSSの適用範囲の区分

制度や基準ごとに対象範囲と確認先を分けて、委託の条件に反映させます。

• セキュリティ指針：関係事業者が行うカード情報漏えい・不正利用対策を確認します。
• PCI DSS：設計上のカード会員データ環境を特定し、契約・監査・報告を分けます。
• 基幹インフラ制度：対象可能性、再委託、設備、データ所在を担当者と確認します。

経済産業省は2025年3月にガイドラインを改訂し、割賦販売法に基づく対策の実務指針と位置付けています（出典：経済産業省「『クレジットカード・セキュリティガイドライン』が改訂されました」、2025年）。

経済産業省のガイドラインとPCI DSSは、別々の枠組みです。両者を同じものとは扱わず、それぞれの要求を個別に確かめる必要があります。

経済安全保障の基幹インフラ制度は、対象となる事業者や設備に条件があります。すべての開発に一律の事前審査が必要だとは言い切れないため、対象かどうかを判断する前提を文書に残します。

オーソリシステムの発注・外注でよくある質問

外注の場面では、費用、期間、委託先の専門性、セキュリティの責任について質問が多く寄せられます。発注前によく確認される質問に、順に答えます。

オーソリシステムの外注費用は最低いくらですか？

既存PSPのAPI連携だけであれば、企画初期の目安は300万〜1,000万円程度です。金額は、要件や既存基盤の状態によって変わります。

国内網接続、独自判定、2センター、移行、24時間運用まで含むと、1,000万円台から数億円以上になります。公開されている定価ではなく、前提に応じた推定レンジです。

オーソリシステムは内製と外注のどちらがよいですか？

独自の与信やリスク判定を競争力にするなら、中核部分は内製し、外部の専門支援を組み合わせる方法が適しています。

国内網、電文変換、HSM、監視、24時間対応を内製するには、専門人材と継続的な体制が必要です。一方で、標準機能を外部に任せ、判定ルールやデータ活用に集中する方法もあります。

委託先にはどのような実績を確認すべきですか？

CAFIS、CARDNET、国際ブランドへの接続経験と、イシュア・アクワイアラの担当実績を確かめます。

ピークTPS、応答SLA、二重化、スタンドインについて聞きます。例外試験、PCI DSSの責任分界、移行、保守も、あわせて聞きます。

会社名や件数よりも、自社の取引量と要件に近い実績を見ます。

RFPが未完成でも見積を依頼できますか？

依頼できます。未確定の範囲を示したうえで、要件整理や現状調査を先行させる提案を求めます。

件数、接続先、対象範囲、性能、カード情報、可用性が未定のまま総額を比べると、追加費用が生じやすくなります。

準委任で要件定義を行い、その成果をもとに、開発を請負にするか別契約にするかを検討します。

まとめ

まず、オーソリ判定、ゲートウェイ、3-Dセキュア、不正検知の範囲を分けます。売上確定、清算、請求は別に扱い、そのうえで発注形態を決めます。

イシュア側かアクワイアラ側かを整理したうえで、PSP、パッケージ、クラウド、スクラッチから選びます。

RFPには、取扱量、ピークTPS、応答SLA、RTO・RPO、接続先を記しておきます。

例外処理、PCI DSS、移行、運用も、数値や成果物と合わせて指定します。

初期費用だけでなく運用まで含めた比較

方式別の推定額と運用条件を合わせて比べ、契約終了後に移行できる余地も確かめます。

• PSP接続：300万〜1,000万円が目安です。
• 自社基盤：5,000万円〜3億円が目安です。
• 大規模刷新：数億円以上となる場合があります。

金額は公開定価ではなく、推定値です。接続先、件数、既存基幹、二重化の条件や、安全性、移行、監視の範囲によって変わります。

同じ内訳にそろえて複数社を比べ、3〜5年のTCO、障害対応、契約終了時のデータ移行を確かめます。

最初の相談で整理する要件

相談時に共有する情報を整理し、必要な範囲を決めてから、発注先を選びます。

• 決済の現状：チャネル、取引件数、ピーク時間、基幹構成、接続先をまとめます。
• 運用条件：カード情報の扱い、必要稼働時間、障害や運用上の課題を伝えます。
• 選定の判断：承認率、顧客体験、不正利用、事業継続に必要な範囲を明確にします。

共有する情報が具体的であるほど、提案を自社の条件に合わせて評価しやすくなります。

▼全体ガイドの記事
・オーソリシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

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