当座預金システム開発の発注/外注/依頼/委託方法について

当座預金システムの発注・外注では、口座残高を記録するだけでなく、決済可否、不渡り、当座借越、移行時の突合までを含む業務責任とシステム責任を明確に分けることが成功の条件です。

当座預金システムをこれから開発・刷新する金融機関や決済事業者に向けて、発注形態の選び方、RFPと要件整理、契約方式、費用相場、委託先の選定、見積書の比較ポイントを順番に解説します。2026年時点の制度動向も踏まえ、安さだけで外注先を決めて決済事故や追加費用を招かないための実務的な進め方を紹介します。

▼全体ガイドの記事
・当座預金システム開発の完全ガイド

当座預金システムの全体像を理解してから発注します

発注前に必要なのは、画面や帳票の一覧を作ることだけではありません。当座預金は決済に使われるため、取引が成立する条件、保留される条件、取り消せる条件、障害後に再処理する条件を業務ルールとして定義し、そのルールを元帳・連携・運用へ落とし込む必要があります。

最低限、口座開設と顧客属性、取引権限、入出金、振込、口座振替、手形・小切手の取立と支払、決済時点の利用可能残高、不渡り、当座借越、組戻し、取消しを整理します。さらに、融資システム、総勘定元帳、AML/CFT、インターネットバンキング、営業店端末、ATM、外部決済機関との接続も対象になります。

とくに「残高」は一つの項目として発注書に書かないことが重要です。帳簿残高、利用可能残高、予約・保留額、当座借越の利用枠、決済予定額、未処理の手形・小切手を区別し、同時に複数の支払依頼が来ても二重支払いや誤った不渡り判定が起きない状態を定義します。

普通預金にも残高や入出金の管理はありますが、当座預金は企業間決済や手形・小切手など、支払先との決済成立を前提にした処理が加わります。当座借越の契約限度額を参照して支払可否を決める場合は、預金元帳と融資元帳の整合性も必要です。また、決済用預金に該当する当座預金は無利息・要求払い・決済サービス提供の要件を満たす商品として扱われます。

（出典：金融庁「預金保険制度」）金融庁は、当座預金や利息の付かない普通預金などの決済用預金を全額保護の対象と説明しています。これは預金者向けの制度説明ですが、発注者が商品区分と利息計算の有無を要件化する際にも関係します。普通預金の機能を複製する感覚で見積を依頼すると、必要な業務制御が抜けるため注意が必要です。

（出典：全国銀行協会「電子交換所」）2026年8月現在、全国銀行協会は2027年3月31日をもって電子交換所における手形・小切手の交換を廃止すると案内しています。金融機関によっては2026年9月30日を最終振出期限としており、2026年10月1日以降に振り出された手形・小切手は原則として当座勘定から支払えない場合があります。

そのため、新しい当座預金システムに紙の交換処理をそのまま移すのか、既存取引の移行期間だけ残すのか、振込・口座振替・電子記録債権などへ案内するのかを企画段階で決めます。廃止日だけでなく、自社の顧客が利用できる最終日、未決済分の保管年限、不渡り履歴の照会期間までRFPに書くと、後からの追加開発を抑えやすくなります。

当座預金システムの発注形態はどれを選びますか？

発注形態は、パッケージや共同利用を採用するか、クラウド上で周辺機能を組み合わせるか、独自開発するかで大きく変わります。正解は金融機関の規模や現行資産、内製力、独自事務の多さで異なるため、技術の好みではなく「どこを標準化し、どこを自社の業務ルールとして保持するか」で選びます。

預金、融資、元帳などの標準機能をパッケージや共同利用型サービスで採用すると、制度改定や共通運用をベンダー側に集約しやすくなります。一方で、独自の事務処理を無理に合わせると、現場の手作業や例外処理が増えます。標準機能、設定で対応する機能、追加開発が必要な機能、業務を変更する機能を提案段階で分けて確認します。

（出典：日本電気「NEC APIサービス for しんきん」）公開価格がある例として、NECは2025年3月、全国230を超える信用金庫が共同利用する勘定系システムの内部APIと連携する「NEC APIサービス for しんきん」を税別200万円で提供開始しました。これはAPI連携パッケージの価格であり、別途SI費用と月額保守料が必要です。当座預金システム全体の開発費と混同せず、部品化によって周辺連携の費用を抑える参考として使います。

照会画面、APIゲートウェイ、帳票、分析、周辺バッチなどをクラウドで構築し、既存勘定系を正の元帳として残す方式は、段階移行を進めやすい選択肢です。ピーク時の処理能力や開発環境の準備を柔軟にしやすい反面、クラウドを採用すれば安全になるわけではありません。データ所在地、暗号鍵、監査ログ、バックアップ、復旧目標、障害時の連絡、サービス終了時のデータ返却を契約とRFPの両方に記載します。

2025年7月4日一部改正の金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」は、経営陣の関与や重要業務の把握、セキュリティ・バイ・デザインを求めています。外注する場合も、セキュリティ責任を委託先へ丸投げできるわけではありません。自社が承認するリスク、委託先が実装・監視する対策、第三者サービスの再委託範囲を分けて評価します。

独自の残高判定や不渡り処理を保持する必要が大きい場合は、スクラッチ開発やホスト更改が候補になります。ただし、自由度が高いほど、業務知識、テスト資産、障害対応手順を発注者側にも残す必要があります。ソースコードの納品だけでなく、データモデル、API仕様、ジョブ定義、テストデータ、運用設計書、設計判断の記録を成果物に含めます。

全面刷新を一度に行うのではなく、既存勘定系を正としたまま照会・API・帳票から切り出し、残高突合が安定した範囲から移行する方法もあります。限定顧客や限定取引でのカナリア移行、新旧並行、夜間リハーサルを組み合わせると、切替日に全口座を一度に賭けるリスクを下げられます。

当座預金システムの発注・外注はどの順番で進めますか？

外注の成否は、提案依頼を出す前の業務整理でほぼ決まります。発注者が業務ルールと優先順位を決め、委託先が設計・実装・テスト・運用を担う境界を先に作ると、提案内容と見積条件を同じ土俵で比較できます。

最初に、口座数、日次取引件数、ピーク時の秒間件数、センターカットの締め時刻、オンライン利用時間、許容停止時間、RTO、RPO、データ保存年限を把握します。次に、口座開設から入金、支払、保留、取消し、不渡り、組戻し、解約までを業務イベントとして並べます。例外処理を後回しにすると、通常処理だけで作った見積が本番前に膨らみます。

要件定義書では、機能要件だけでなく、残高の状態遷移、権限分離、監査証跡、再処理、照合、障害時の手動運用、性能、セキュリティ、移行、受入条件を記載します。発注者が判断できない業務ルールは、ベンダーへの質問事項として残すのではなく、業務部門・リスク管理部門・システム部門で決裁する論点にします。

RFPには、背景と目的、対象業務、対象外業務、現行システム構成、口座数と取引量、外部接続、移行対象、希望スケジュール、予算の考え方、セキュリティ基準、SLA、成果物、体制、再委託、保守、契約終了時のデータ返却を含めます。とくに「当座預金を開発する」とだけ書かず、当座借越、不渡り、手形・小切手、センターカット、元帳連携を個別の業務範囲に分解します。

提案依頼先には同一の業務シナリオとサンプルデータを渡し、口座残高が不足する支払、借越枠内の支払、借越枠を超える支払、同時刻の複数決済、日跨ぎ、取消し、障害復旧を説明してもらいます。製品カタログの機能数ではなく、シナリオごとの処理結果、ログ、再処理方法、担当者の操作まで確認すると、実装後の認識差を見つけやすくなります。

要件が固まっていない構想・要件定義は準委任契約、仕様と成果物が確定した開発部分は請負契約というように、工程ごとに契約を分ける方法があります。すべてを請負にすると、未確定の業務ルールや制度変更のリスクが発注者と受託者の争点になりやすく、すべてを準委任にすると、完成責任や予算上限が曖昧になりやすいです。

契約書と個別仕様書には、成果物の一覧、検収方法、欠陥の定義、変更管理、遅延時の扱い、障害の重大度別対応時間、再委託の承認、知的財産権、秘密情報、監査協力、データ返却、契約終了後の移行支援を定めます。受入条件は「問題なく動く」ではなく、残高突合率、処理時間、復旧時間、未処理件数、監査ログの保存、操作権限の分離など測定できる形にします。

単体テストと結合テストだけでは、当座預金の本番リスクを確認できません。総合テスト、性能テスト、セキュリティテスト、障害訓練、営業店やコールセンターを含む業務リハーサル、利用部門のUATを計画し、残高・不渡り・借越・取消し・日跨ぎ・大量一括引落しのシナリオを繰り返します。

移行では、口座基本情報、残高、借越契約、未決済取引、不渡り履歴、顧客権限、監査ログを対象にし、件数と金額の両面で突合します。旧システムの抽出、新システムへの変換、取込、再計算、照合、差異の承認、切戻しまでを一つの手順書にします。移行リハーサルを見積から除外すると、切替前の夜間作業や追加要員が別費用になりやすいため、必ず委託範囲へ入れます。

当座預金システムの費用相場とコスト内訳

当座預金単体の公開見積は限られるため、以下は金融系のミッションクリティカル開発の作業量とリサーチ結果をもとにした推定レンジです。口座数、取引量、現行勘定系、移行範囲、24時間運用、規制対応、SLAによって大きく変わるため、金額だけを相場として断定せず、対象範囲と期間をセットで比較します。

既存勘定系に接続する残高照会、入出金、API、ファイル連携などの小規模な周辺機能であれば、初期費用は1,000万〜3,000万円、期間は4〜8か月が一つの目安です。口座・残高・権限、当座借越連携、会計・融資連携、監査ログ、バッチ、照合を含む中規模のサブシステムでは、3,000万〜1億円、9〜18か月程度が推定レンジになります。

複数金融機関や大量口座を対象に、ホスト移行、全チャネル、災害対策環境、電子交換所や周辺決済まで含める大規模刷新では、1億〜数十億円以上、24〜48か月以上になる可能性があります。出典は本記事のリサーチノートと金融系ミッションクリティカル開発の作業量分析です。これらは公開された当座預金単体の実績価格ではなく、要件と作業量から置いた推定です。

見積書は、要件定義・業務分析、アーキテクチャ・基本設計、実装・設定、テスト・性能試験・障害訓練、データ移行・切替、プロジェクト管理、監査・文書化に分けてもらいます。目安として、要件定義は全体の15〜25％、設計は10〜15％、実装は20〜30％、テストは20〜30％、移行は10〜20％程度ですが、プロジェクトの前提によって変わります。

人月単価を比較する場合も、単価だけで判断しません。リサーチでは、PMが月66万〜152万円、アーキテクトが月68万〜156万円、アナリストが月76万〜142万円、開発者が月51万〜90万円という参考値が整理されています。金融実績、勤務地、夜間切替、規制対応、担当範囲によって変動するため、職種別の人数・期間・成果物を並べて確認します。

初期開発費とは別に、クラウド利用料、ライセンス、監視、バックアップ、災害対策環境、24時間の障害対応、制度改定、セキュリティ診断、教育、保守を確認します。保守費は初期費用の5〜15％程度と説明されることがありますが、月額か年額か、何時間までの問い合わせを含むか、制度改定が別契約かで意味が異なります。見積書では「保守一式」とせず、費目と対応時間を分解します。

追加費用が発生しやすいのは、現行データの品質不足、固定長ファイルの仕様不明、外部機関との接続条件の変更、移行リハーサルの追加、夜間作業、性能不足への増強、監査指摘への対応、制度変更です。予備費を別枠で置き、変更要求が出た際の単価・承認手順・納期への影響を契約に定めると、予算管理がしやすくなります。

委託先の選定と見積比較で確認するポイント

委託先は、知名度や提示価格だけでなく、当座預金に近い決済業務を安全に扱えるか、既存システムとデータをつなげられるか、切替後も運用を続けられるかで評価します。大手SI、パッケージベンダー、クラウド事業者、金融業務に強い開発会社を同じRFPで比較し、担当範囲を提案書に明記してもらいます。

候補会社には、預金・融資・決済の実績、既存ホストやAPI・固定長ファイルとの連携、口座・残高・未決済データの移行、残高突合、FISC基準や金融庁ガイドラインを踏まえた安全対策、クラウドと災害対策、24時間運用の体制を質問します。「金融機関向け」と書かれていても、当座預金の決済判定や不渡りまで担当したのか、周辺画面だけなのかを分けて聞くことが大切です。

出典は金融情報システムセンター「金融機関等コンピュータシステムの安全対策基準・解説書 第13版」です。FISC第13版は2025年3月に発行され、経済安全保障、オペレーショナル・レジリエンス、金融庁のサイバーセキュリティ指針、AIの安全対策、システム障害事例などを反映しています。提案評価では、規格名を列挙するだけでなく、リスク評価、監視、演習、復旧、報告を誰がどの手順で実施するか確認します。

見積を比較するときは、各社の金額をそのまま横に並べるのではなく、機能、工数、期間、体制、成果物、除外条件、保守条件を同じ項目に変換します。例えば、A社が移行費を含み、B社が別途としている場合、A社のほうが高く見えても総額では逆転する可能性があります。クラウド利用料を初年度だけ含む提案や、テストデータ作成を発注者作業とする提案にも注意します。

評価表では、業務適合性、移行・切替、非機能要件、セキュリティ、運用体制、価格、将来拡張、契約条件に点数を付けます。価格の配点を高くしすぎると、安いが移行や障害訓練を含まない提案が有利になります。最終候補には、残高不足、当座借越、同時決済、不渡り、再処理を実際に説明してもらい、質問への回答の具体性も評価します。

障害が起きたとき、勘定系、API基盤、ネットワーク、クラウド、外部決済機関のどこに原因があるかを短時間で切り分けられる体制が必要です。監視対象、一次受付、エスカレーション、復旧判断、顧客への通知、金融当局や関係機関への報告、事後検証の担当をRACIなどで整理し、平時だけでなく夜間・休日の連絡先も契約に含めます。

また、特定ベンダーだけが理解できるデータ形式や運用手順を残すと、次回の更改や委託先変更で高額な移行費が発生します。データモデル、インターフェース仕様、テスト資産、運用手順、構成情報、ログの取り出し方法、第三者監査の結果を発注者が利用できる状態にし、契約終了時のデータ返却と移行支援の単価まで確認します。

よくある質問

当座預金システムの外注では、価格以外にも契約、移行、制度、運用について質問が寄せられます。ここでは、発注前に確認しておきたい代表的な疑問へ直接回答します。

既存勘定系に接続する周辺機能なら1,000万〜3,000万円、中規模のサブシステムなら3,000万〜1億円、大規模な勘定系刷新の一部なら1億〜数十億円以上が推定レンジです。ただし、当座預金単体の公開実績価格ではないため、口座数、取引量、移行範囲、SLA、テスト・運用の前提をそろえて見積を取る必要があります。

実装やテスト、監視を外注することはできますが、商品設計、残高の定義、決済可否、不渡り、当座借越、リスク許容度、受入判断まで委託先に丸投げするのは避けます。発注者が業務ルールと承認基準を持ち、委託先には設計・開発・運用の責任範囲を明確に依頼する形が安全です。

周辺機能やAPI、照会、分析、バッチから段階的にクラウド化する方法は検討できます。元帳や決済処理を含める場合は、データ所在地、鍵管理、アクセス権、監査ログ、バックアップ、RTO・RPO、障害時の代替運用、サービス終了時の出口戦略を要件と契約に入れ、金融機関側のリスク評価と承認を経て判断します。

当座預金の決済業務、既存基盤との連携、データ移行、障害訓練、切替後の運用を一貫して説明できることを重視します。提示価格よりも、見積に含まれる範囲、除外条件、責任分界、制度改定と保守の扱い、発注者へ残る設計・テスト資産を確認し、同じシナリオで複数社を比較することが大切です。

まとめ

当座預金システムの発注・外注では、最初に業務範囲と残高の状態を整理し、パッケージ、クラウド、スクラッチ、段階移行のどれを組み合わせるかを決めます。そのうえで、RFPに口座数、取引量、決済ルール、当座借越、不渡り、外部連携、移行、SLA、セキュリティ、保守、契約終了時のデータ返却を記載します。

費用は、周辺連携で1,000万〜3,000万円、中規模サブシステムで3,000万〜1億円、大規模刷新の一部で1億〜数十億円以上という推定レンジを目安にできます。ただし、移行、テスト、障害訓練、監視、制度改定、クラウド、保守を分離して比較しなければ、安い見積が後から高くなる可能性があります。

最初のアクションは、現行システムの構成図、業務イベント、残高の定義、口座数と取引量、未決済データ、外部接続、希望時期、許容停止時間を一枚にまとめることです。発注者が決める業務ルールと、委託先に求める設計・開発・移行・運用の範囲を切り分け、同じシナリオで複数社へ提案を依頼すると、当座預金システムの安全性と費用の妥当性を比較しやすくなります。

手形・小切手の電子化、金融庁のサイバーセキュリティ指針、FISC基準の更新も前提条件に反映し、完成後の運用まで含めて発注計画を作成します。業務とITの両方を理解できるパートナーと早い段階から論点を整理することで、追加開発や切替リスクを抑えながら、将来の制度変更にも対応しやすいシステムを目指せます。

▼全体ガイドの記事
・当座預金システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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