清算システムの発注は、業務範囲と責任分界を整理し、委託方式と契約を選び、RFPと見積で前提を揃える流れで進みます。
試験・移行・運用まで設計しておくと、納期遅延や追加費用を抑えやすくなります。全体像は完全ガイドでも確認できます。
▼全体ガイドの記事
・清算システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
清算システム開発の発注前に押さえる全体像
清算システムは、画面や計算機能にとどまらず、取引受付から結果報告までの一連の処理を範囲に含みます。
その中には、照合や債権・債務の計算、ネッティングが入ります。担保・証拠金管理や決済指図も、同じ流れに含まれます。
各工程のデータと障害対応を、どの会社が担うかも合意しておきます。
発注範囲と責任分界をそろえることが、委託設計の出発点になります。
清算と決済の境界の確定
清算では、成立した取引から参加者間の債権・債務を確定し、相殺後に受け払う金額や証券数量を算出します。
決済は、日銀ネット、証券保管振替機構、全銀システムなどを通じて、資金や証券を受け渡す領域です。
自社システムが決済ゲートウェイまで担当するか、決済指図を外部機関へ渡すかによって、接続仕様、障害時の責任、費用が変わります。
発注者側で定める参加者と清算ルール
発注前には、清算の対象と適用するルールを、次のように整理しておきます。
- 参加者と対象：銀行、証券会社、決済事業者、加盟店、カストディアン等と清算対象・締め時刻
- 参加者別の条件：権限、手数料、担保、限度額、資金不足時の扱い
- 計算と締め：商品別計算式、マルチラテラル・ネッティングの単位、訂正・取消の締め時間
- 破綻時の対応：参加者の破綻に伴うポジション移管を業務ルールに含める
ここまで決めておけば、仕様をベンダー任せにせずに済みます。
清算システムの発注形態の選び方
発注形態は、パッケージやクラウド・マネージドサービス、受託開発、組み合わせ型から選びます。
まず、清算ルールの独自性と外部接続数を比べます。さらに、取引量、停止許容時間、社内に残す運用能力も確認します。
技術方式を先に固定せず、これらの条件から選定します。
パッケージ導入における標準機能と差分の見極め
清算・決済・取引管理の標準機能を使えば、開発期間や制度変更対応の負担を抑えられます。
実績のある機能を利用できる点も利点です。
一方で、独自のネッティングや担保モデル、参加者制度、既存メインフレームとの連携を大量に改修すると、利点が薄れます。RFPでは、標準機能と設定対応で足りる範囲と、追加開発が必要な範囲、対象外を分けます。また、製品ロードマップとサポート期間も確認します。
クラウドやマネージドサービスとの責任の分け方
クラウド等を使う範囲と、どこまでをサービス提供者が受け持つかを整理します。
- 効率化：環境構築、監視、性能拡張、パッチ適用の一部を委託できる
- リソース調整：取引量やピーク時間に合わせて増減しやすい
- 契約前の確認：データ所在地、暗号鍵、監査ログ、回線、障害復旧、再委託、終了時の返却
金融庁のガイドラインも、外部委託先やクラウド提供者を管理対象として扱います（出典：金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」、2025年改正）。
利用企業との責任は、RFPで具体化します。
スクラッチとハイブリッドの使い分け
独自性の高い清算ルール、厳しい性能要件、特殊な基幹連携が競争力に直結する場合は、スクラッチ開発が候補です。
ただし、コア計算をすべて個別実装すると、業務知識の属人化やテスト増加につながります。制度改定時の改修負担も大きくなります。
清算コアや参加者管理にはパッケージを使い、接続アダプターと社内基幹連携、照会・報告だけを個別開発する構成も有効です。
RFPと要件整理に盛り込む内容
RFPは開発会社への要望書であり、発注者が業務の前提を揃える資料でもあります。
「清算機能を作ってほしい」という依頼では、各社が想定する範囲がまちまちになり、見積を比較できません。
RFPには、対象業務やデータ、性能・障害対応、移行・保守を、同じ粒度で記載します。
業務範囲とデータ状態の記載
RFPには、業務処理と処理条件、データ要件、例外時の運用を分けて記載します。
- 対象処理：取引受付、照合、清算計算、ネッティング、担保・証拠金、決済指図
- 周辺業務：未決済管理、返却・再送、取消、会計連携、規制報告、監査証跡
- 処理条件：各処理の入力、判定条件、出力、締め時間、訂正権限、担当部署
- データ管理：取引IDの一意性、参加者・商品コード、口座、通貨、評価時点、タイムゾーン、状態遷移
Excelや手作業による処理、メール承認と例外時の電話連絡も対象に含めると、稼働後に残る業務を把握できます。
再送による二重計上を防ぐ冪等性、通信断後の再実行、訂正前後を追うイベントログも定義します。特に、これらは画面要件より先に決める項目です。
非機能要件の数値と試験方法
非機能要件は、試験できる条件にまで落として書きます。
- 性能：1日平均でなくピーク時の取引件数、同時接続数、応答時間、締め処理完了時刻
- 継続性：稼働率、RTO、RPO、データ保存期間、監視、バックアップ
- 情報管理：アクセス権限と暗号化の方式を定める
「高性能」「止まらない」といった言葉は、そのままでは試験で確かめられません。たとえば、ピーク時に毎秒何件を処理し、何分以内に返すかを決め、試験条件へ落とし込みます。
金融庁の指針は、業務継続やシステムリスク、参加者破綻への対応、担保管理を評価項目にしています。
振替機関向けには、不可欠な情報システムを停止から2時間以内に再開し、障害当日中に決済を完了する目標も示されています（出典：金融庁「清算・振替機関等向けの総合的な監督指針」、2025年）。
自社が同じ監督対象でなくても、停止許容時間を考える参考になります。
RFP段階で用意するPoCと受入基準
不確実な清算ルールや接続仕様は、本開発前のPoCと具体的な受入基準で確かめます。
- 機能検証：代表データで照合、相殺、担保計算、決済指図を試す
- 異常系検証：再送、タイムアウト、部分失敗、重複送信後の残高や状態を確かめる
- 成果物・試験：納品物、テスト計画、移行リハーサル、利用者受入、性能・セキュリティ試験を定める
- 引き継ぎ：マニュアル、教育、保守引き継ぎ、件数・計算・時間・ログ等の受入条件
異常系で残高やステータスがどう戻るかを先に確かめておくと、後工程での追加費用を抑えられます。また、受入基準は「動くこと」で終わらせず、再実行、障害通知、権限別操作も確認できる形にします。
請負・準委任など契約形態の使い分け
要件と完成条件を固定できる工程は請負、調査や要件定義など変更が多い工程は準委任が基本です。清算システムでは、業務ルールや外部機関の仕様確認に時間がかかります。そのため、全工程を最初から固定価格の請負にすると、変更管理が複雑になりやすくなります。
請負契約の成果物と検収条件
請負契約では、受託者が合意した成果物を完成させ、発注者が検収します。そのため、契約時に清算エンジン・接続アダプター・管理画面・帳票・テスト仕様書・移行ツールなどを成果物として特定します。
成果物ごとの機能や性能、データ精度、受入試験・納期・瑕疵対応を契約書や個別仕様書に記載します。さらに、機能追加や外部仕様変更時の依頼と見積、承認、納期再設定の手順も定めます。
準委任契約が向く要件整理とPoC
準委任契約では、専門家が一定期間にわたり調査や設計、助言、開発作業を行います。現行業務の洗い出しや清算ルールの整理、接続方式の検討、PoCと移行計画・運用改善に適しています。
完成義務を負わせにくいため、月次成果物と会議体、担当者を合意します。あわせて、次の項目も取り決めておきます。
- 稼働時間
- 課題一覧
- 意思決定事項
- 次月のゴール
混合契約と再委託の条件の管理
契約は工程ごとに分け、再委託先と発注者の管理責任も明確にします。
- 契約の分担：要件定義・PoCは準委任、仕様確定後の清算・照合は請負、稼働後は保守契約
- 契約間の整理：著作権・利用権、仕様書更新、障害責任、検収済み範囲、引き継ぎデータ
- 再委託管理：別会社・海外拠点の名称、情報アクセス、監査権、事故連絡、終了時の引き継ぎを確認
金融庁の監督指針は、外部委託先が自社実施と同等の要件を満たすかの確認を重視しています（出典：金融庁「清算・振替機関等向けの総合的な監督指針」、2025年）。
委託後も発注者の責任は残ります。そのため、判断・承認・監査・緊急対応の権限を発注者側に整理します。
清算システム開発の費用相場
清算システムの標準価格表はほとんど公開されていません。そのため、以下は2025〜2026年の発注検討用に、金融・決済特有の接続・高可用性・規制対応・異常系試験を加味した推定レンジです。
金額は税別の初期費用です。外部サービス料や接続料・ハードウェア・クラウド利用料・運用費は、別の場合があります。
個別案件の正式見積ではないため、予算取りの起点とし、RFPで前提を揃えてください。
スコープ別の初期費用の幅（300万円から30億円以上まで）
調査・PoC・要件定義から市場インフラ級まで、スコープごとの初期費用は次のように想定されます。
- 調査・PoC・要件定義：300万〜1,500万円程度
- 周辺清算・照合：パッケージやクラウド利用で3,000万〜1.5億円
- 個社・大規模基盤：中規模は1億〜5億円、大規模な証券・銀行バック基盤は5億〜30億円以上
- 市場インフラ級：30億〜100億円超も想定
市場インフラや共同利用型の中核システムでは、複数参加者・24時間運用・DR・制度改定・段階移行が加わります。
金額の差は、画面数よりも接続先数や取引量、清算ルールの複雑さによって生じます。担保・証拠金、DVP、停止許容時間の扱いも影響します。異常系試験やデータ移行も条件になり、監査対応や運用時間も見積に影響します。
要因が増えるほど、業務アーキテクトや金融業務SEに加え、インフラ担当とテスト担当が必要になります。見積では、要因を工程別に確認します。
工程・機能・運用の3方向で見る見積の分解
見積は、開発費だけでなく継続費用も比較できるように分けておきます。
- 工程：調査、要件定義、基本・詳細設計、開発、接続、テスト、移行、教育、リリース支援、保守
- 機能：清算計算、参加者・商品・口座マスタ、照合、担保、決済連携、報告、権限、監査ログ
- 運用：クラウド、監視、有人対応、障害訓練、制度改定、脆弱性対応、バックアップ、DR、月額費用と年間保守、性能増強を含む3〜5年の総保有コスト
周辺機能の月額費用は50万〜500万円程度、金融機関向け専用運用は月500万〜数千万円程度を想定できます。取引量やSLAの条件、有人監視やDRサイトの有無、接続先数によって変わります。
年間保守は初期開発費の15〜25％程度を見込みます。さらに、「開発一式」は内訳を分解表へ戻し、初期見積に隠れた費用を確認します。
公開事例の使いどころ（規模と要件の参考）
類似する決済基盤の公開事例は価格換算に使わず、要件の重さを知る材料にします。
- 取扱規模：SBペイメントサービスは2024年度に年間9.8兆円、5億5,011万件超を処理
- 刷新効果：バッチ処理は24時間から約10分、オンライン応答時間は70％以上短縮
この事例は日本オラクルの2026年2月の発表によるものです（出典：日本オラクル「SBペイメントサービスの基幹システム事例」、2026年）。
公開事例は、清算システムの価格を示すものではなく、取引量やピーク性能、移行と無停止運用、災害対策が発注条件を左右する参考例です。
清算システムの委託先選定と見積比較のポイント
知名度や最安値だけでなく、清算業務と外部接続、異常系への対応、稼働後の運用を担えるかで委託先を比べます。
大手SIerや金融業務の専門会社、パッケージベンダー、クラウド運用会社では得意分野が異なります。そこで、同じRFPで提案を比較します。
金融・決済の業務実績と接続経験の確認
実績は件数だけでなく、業務領域や外部接続、説明できる証拠、将来変更への対応力で見ます。
- 業務経験：清算、担保、DVP、参加者管理、照合、障害復旧の担当範囲
- 接続実績：日銀ネット、証券保管振替機構、全銀系、SWIFT、ISO 20022
- 実績の説明：匿名構成図、担当工程、ピーク件数、SLA、障害訓練、移行方法
- 変更対応：将来の電文変更を吸収する接続層やデータモデル
全銀ネットは2026年3月、資金決済システムの将来像に関する検討結果を公表しました。そのうえで、2026年度以降も新たな決済システムの構築を検討する方針です（出典：一般社団法人全国銀行資金決済ネットワーク「資金決済システムの将来像に関するスタディグループにおける検討結果」、2026年）。
日本銀行も、日銀ネットで使うISO 20022電文のバージョン改訂を進めています。
見積書の前提条件と除外項目
金額を比べる前に、各社の前提と見積の範囲を揃えます。たとえば、各社の差額は、接続費の扱いだけでも数千万円になる場合があります。
- 前提条件：取引件数、参加者数、接続先、商品、環境、テストデータ、移行件数
- 運用条件：稼働時間、RTO・RPO、利用者教育、保守時間
- 費用範囲：要件定義、性能・障害・参加者受入試験、移行リハーサル、監査、マニュアル、運用引き継ぎ
- 追加負担：「一式」等の追加費用条件と、発注者が出すデータ・人員・環境
制度改定対応や再委託管理に加え、「一式」「想定外」「別途協議」といった追加費用の条件も明記してもらいます。
提案の読み方（体制とリスク対応）
提案体制と、障害時の責任・対応手順の具体性を確かめます。
- 担当体制：責任者、業務アーキテクト、清算、接続・インフラ、テスト、運用の各担当
- 実行力：設計・開発・運用担当が営業説明を再現できるか確認
- 再委託・海外拠点：情報アクセス、品質、時差、障害時の指揮系統を確認
具体的には、候補会社に同じ障害シナリオを示し、決済先への送信後に応答が消えた場合の対応を説明してもらいます。
説明の中では、二重決済を防ぐ再送方法と手動確認への切替を見ます。さらに、参加者通知や復旧後の照合、監査証跡も確かめます。特に、失敗時の責任を明確にできる会社が適しています。
発注後の進め方と失敗を防ぐ管理
発注後は、責任者を置いたうえで、要件定義から運用安定化までを段階的に進めます。各段階で、発注者が決める事項と委託作業を分けます。
- 発注者側での業務ルールと受入基準の確定
- 設計、開発、テスト、移行、リリースの段階的な管理
- 運用安定化までの責任者による判断の継続
業務ルールの確定から運用安定化まで判断を続けることが、納期遅延や追加費用を防ぐ基本になります。
意思決定者と変更管理の明確化
清算業務は複数の部署にまたがり、商品と法務、リスク、決済が関わります。さらに、会計や情報システム、監査も関わります。そのため、経営判断や業務ルールの承認、技術仕様、受入試験、それぞれの責任者を置きます。
週次では、課題や変更要求、未決事項のほか、予算と納期も確認します。また、変更は口頭で済ませず、影響範囲と追加費用、納期、テスト範囲を記録して承認します。
本番前に繰り返す異常系と移行リハーサル
本番前に異常系を試し、移行後の差異への対応を決めます。
- 取引・通信：重複、順序逆転、電文欠落、通信断、タイムアウト、部分約定
- 例外・障害：資金・担保不足、時刻ずれ、締め後訂正、参加者破綻、災害切替
- 移行準備：クレンジング、コード変換、残高照合、履歴・権限移行、並行稼働、切替判定
- 切替判断：新旧計算結果を一定期間突合し、中止基準と旧環境への復帰手順を決める
失敗後に確定したデータと再処理できるデータ、承認者を確認しておかないと、稼働後の手作業が増えます。また、新旧システムで差異が出た場合は、その原因を説明できるようにします。
契約に残す運用・監査・制度改定の条件
契約と設計に残す条件は、次のように整理します。
- 運用手順：監視項目、アラートの優先度、一次切り分け、エスカレーション、再処理権限、証跡保管
- 保守条件：脆弱性対応、バックアップ、災害訓練、参加者への連絡、問い合わせ時間、障害の重要度別の目標復旧時間
- 契約条件：制度改定、軽微改修の上限、休日対応、再委託先の変更通知
- 外部変化：2026年以降の新決済システム検討やISO 20022電文改訂の可能性
- 変更への備え：電文変換層、版管理、回帰試験、影響調査を設計に入れ、将来変更への対応費用と責任分界を保守契約やSLAに定める
特定の電文にデータモデルを固定しすぎない設計にすると、毎回の大規模改修を避けやすくなります。
清算システム開発の発注・外注に関するよくある質問（FAQ）
一般的な業務システムと同じ感覚で見積を取ると、接続や異常系、監査、運用の条件が抜けやすくなります。よくある疑問を順に取り上げます。
小規模な清算システムでも外注できますか？
外注できます。取引照合と債権・債務の集計、帳票、決済サービスとのAPI連携などに範囲を絞ると、PoCや要件定義から委託できます。
金融機関や複数参加者を扱う場合は、小規模でも二重計上の防止と権限、監査ログ、障害時の手作業を要件に含めます。
RFPが完成していなくても開発会社へ相談できますか？
相談できます。対象商品・参加者・取引量、現行システムや困っている業務、希望時期があれば、初回相談は可能です。
前提が会社ごとに違うまま正式見積を頼むと比較できません。相談後は、業務フローやデータ項目を整理したうえで、接続先と非機能要件、受入条件を揃えます。そのうえで、同じ資料を使い、複数社へ提案を依頼します。
一番安い会社に発注すればよいですか？
最安の会社が最適とは限りません。接続・試験・移行、保守・再委託・障害対応が見積の外にあると、契約後に費用や発注者の負担が増えます。
合計金額に加え、同じ障害シナリオへの対応や工程別の成果物、担当者の経験、3年から5年の総保有コストを比較します。
請負と準委任を同じプロジェクトで併用できますか？
併用できます。業務整理・要件定義・PoCは準委任、仕様確定後の開発と検収は請負、稼働後の監視や改善は保守契約に分けられます。
成果物・知的財産・変更管理、障害責任、引き継ぎ範囲が、契約間で矛盾しないようにします。
まとめ：業務・契約・運用を一体で設計する清算システムの発注
清算と決済の境界・参加者・対象商品・締め時間・取引量・停止許容時間を整理します。次に、パッケージ・クラウド・スクラッチ・ハイブリッドを比べます。
RFPには、機能・接続・非機能・異常系・移行・保守の条件を記載します。
発注者が保持する業務ルールと受入基準
委託先に任せきりにせず、発注者が清算ルールとデータ定義・責任分界・受入基準・障害時の判断を保持します。
請負と準委任を工程に応じて使い分け、再委託・クラウドの責任・制度改定・運用引き継ぎを契約に定めます。
同じ条件での見積比較と段階導入
費用はPoC・要件定義の300万〜1,500万円程度から、市場インフラ級の30億〜100億円超まで幅があります。そのため、相場だけでなく、見積条件と進め方を判断材料にします。
- 見積比較：工程・機能・接続・試験・移行・保守・運用の内訳と除外項目を照合
- 段階導入：難所をPoCで検証し、照合や周辺連携から着手して業務停止リスクを抑える
段階的に進めれば、予算の不確実性も抑えられます。
▼全体ガイドの記事
・清算システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。