定期預金システム開発は、業務ルールを整理する段階から始まり、方式を選び、設計と開発を経て、テスト・移行・リリースへ進みます。金融業務では、後工程のテストや移行の条件を前工程で決めておくことが、手戻りを減らし安全な稼働につながります。
▼全体ガイドの記事
・定期預金システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
定期預金システムの全体像
定期預金システムは、預入から満期までの取引条件を一貫して管理します。預入金額や満期日、適用金利が中心になりますが、利息や税金、継続条件も同じ仕組みで扱います。
導入の形は大きく2つあります。預金機能を勘定系に組み込む形と、既存の勘定系につなぐ周辺システムとして作る形です。
周辺システムは商品管理やチャネル、事務支援を担うため、預金元帳まで新設する場合とは範囲が違います。この違いを先に決めておかないと、同じ名称でも費用や期間が大きく変わってしまいます。
定期預金システムに必要な主な機能
中核になるのは商品・金利マスタです。期間は、1か月や3か月のような短いものから、6か月や1年の長いものまで登録します。
固定金利や変動金利に加えて、最低預入額、満期時の扱い、キャンペーン金利も同じマスタに持たせます。そのうえで、受付時点の条件を各取引に紐付けます。
- 受付：窓口、ATM、インターネットバンキング、アプリ、営業店端末のすべてに共通ルールを適用
- 預金管理：元金・利息の計算から満期処理、自動継続、中途解約、普通預金への振替まで
- 案内と記録：満期案内と税金計算、帳票出力、計算ルールのイベント履歴
チャネルごとに異なる入力を許すと、受付の判定がそろいません。そこで、共通の商品判定と受付ルールを用意します。
利息計算では、日付の境界や営業日、うるう年の扱いを先に決めておきます。日割りと単利・複利の扱い、端数処理、金利改定日も確定させます。計算に使った金利とルールの履歴は、問い合わせや監査の説明で役立ちます。
勘定系・会計・AMLとの境界
企画の段階で、定期預金のロジックと元帳の責任範囲を決めます。構成によって違いが大きいため、場合ごとに整理しておきます。
- 既存勘定系を使う場合：残高と仕訳は既存側を正とし、新システムは商品定義や受付、満期予定などを担い、APIかファイルで連携
- 預金元帳を新設する場合：取引の整合性や二重計上の防止、締め処理、障害時の再実行まで含む基幹システムの刷新
- 周辺システムと連携する場合：連携先は、顧客情報（CIF）や総勘定元帳、会計、税務、資金繰り、全銀・内国為替、本人確認、認証、通知、AML/CFTの検知基盤など
AML/CFTは定期預金の機能だけでは完結しません。そのため、大口預入や不自然な分割預入、短期解約などを検知システムに渡せるよう、データ項目と連携の時点を決めておきます。
FISCの安全対策基準・解説書は、2026年3月に第14版が公表されています（出典：金融情報システムセンター、2026年）。金融機関向けの案件では、対象とする版と適用範囲を提案依頼書に明記しておくと、見積の前提がそろいます。
定期預金システム開発の進め方
工程は、構想と要件定義から始まり、方式の選定、設計と実装を経て、テスト・移行・リリースへと進みます。特に金融業務では、後工程のテストや移行の条件も前工程で定義しておく必要があります。
満期集中日や中途解約といった例外処理を後から考えると、手戻りが大きくなります。このため、代表的な取引シナリオを早い段階で作ります。
1. 構想と要件定義での業務ルールの整理
まず対象範囲を決めます。商品管理と受付だけに絞るか、預金元帳を含む勘定系モジュールまで広げるかは、発注側が判断します。
- 現状資料：機能一覧や商品規程、金利表、帳票、日次・月次のバッチ、外部接続
- 品質と運用：SLAや監査要求、稼働時間、目標とする復旧時間
- 計画条件：対象の商品とチャネル、処理量、移行対象、段階的に導入する条件
集めた資料から、現状とあるべき姿の差を整理します。そのうえで、企画書に対象範囲と処理量を書き込みます。
次に、取引の流れを時系列で並べます。預入から満期、継続、中途解約までの基本に加えて、取消や訂正、相続、差押えも対象にします。満期日に休日が重なる場合は、処理日と案内日を決めておきます。
休日を前営業日扱いにするか翌営業日扱いにするか、資金移動日と案内日を分けるかどうかも決めます。金利と利息、税、端数の計算表では、入力値と期待結果、根拠規程を対応付けます。その内容は、発注側の業務責任者が承認します。
2. 方式の選定と設計・開発
基本となる方式は三つあります。既存勘定系につなぐパッケージ・モジュール、APIで組み合わせるクラウド・コンポーザブル型、独自要件を実装するスクラッチです。
- パッケージ：標準機能で期間と保守の負担を抑えやすい一方、アドオンを積み上げると複雑になる
- クラウド型：商品とサービスを疎結合にしやすい反面、責任共有やデータ所在などの要件を整理する必要がある
- スクラッチ：独自要件に合わせて個別に設計できる一方、期間と費用が増えやすい
クラウドを選ぶ場合は、責任共有モデルとデータの所在を先に整理します。委託先の管理や監視、バックアップと災害復旧も、自社の要件に落とし込みます。
設計では、商品と金利のマスタをパラメータで設定できるようにし、元帳と商品定義は疎結合にします。APIには冪等性キーを持たせ、再送による二重預入や二重解約を防ぎます。
バッチでは、処理対象日と処理件数、成功と失敗の件数を記録します。さらに、再実行の方法も記録し、途中で止まった後も安全に再開できる設計にします。
操作ログと取引ログは分けて持ち、誰が、いつ、どの権限で、どの値を変えたかを追跡できる構成にします。
3. テスト・移行・リリースの反復
金融システムは、単体テストだけでは稼働させられません。そこで、業務シナリオで検証すべき主な条件を、観点ごとに整理します。
- 日付と金利：日付の境界やうるう年、金利改定日の前後、満期集中日
- 障害と処理：大量の同時処理や二重送信、通信断、取消、障害後の再実行
- 計算と照合：中途解約の利息の再計算や税の端数、勘定系残高、会計仕訳、通知、監査ログ
照合では、計算の結果と、それを受け取る側の記録が食い違っていないかを突き合わせます。食い違いが見つかったときに原因を追える状態にしておくことも必要です。
移行の対象には、口座番号や顧客番号、元金を含めます。加えて、預入日と満期日、適用金利が必要です。さらに、継続区分や変更履歴、税情報も移行します。
移行の前後では、件数と残高、利息の見込額を照合します。
本番切替の前には、リハーサルを複数回行います。切替の判定基準や並行稼働の期間、戻し方を決めてから、リリースします。問い合わせ窓口と、障害時の経営報告ルートも決めておきます。
開発期間の目安は、小規模な周辺システムで6〜12か月、勘定系連携を含む刷新で12〜24か月です。ただし、商品数や移行量によって変わります。
定期預金システムの費用相場とコストの内訳
費用は機能の数だけでなく、範囲で決まります。範囲には、元帳や会計、顧客情報の連携に加えて、チャネルや移行、金融向けのテストも入ります。
ここでの金額は、2026年の受託開発単価と金融システム固有の工数を組み合わせた、予算取り用の推定です。
定期預金システム単体の一律の価格を示す公開情報は、ほとんどありません。正式な価格ではないため、RFPで前提条件をそろえてから比べてください。
スコープ別の初期費用と開発期間
構成別の費用と期間は、元帳を新設するかどうかや、連携の範囲によって変わります。予算取りでは、構成ごとに次の幅を目安にできます。
- 小規模構成：既存勘定系に接続して商品・金利・満期を管理する。1,000万〜3,000万円、6〜12か月
- 銀行内モジュール刷新：会計やCIF、複数チャネル、AML、移行を含む。3,000万〜1億5,000万円、12〜24か月
- 共同利用・勘定系移行：複数行対応などを含み、1億〜数億円、2〜4年程度
- 全面刷新：預金や融資、為替、元帳を含み、数億〜数十億円以上、3〜5年以上
小規模構成の推定は、元帳を新設せず、商品数やチャネル、連携先を絞り込んだ前提で立てています。金融向けのテストと監査対応も含みます。
共同利用やオープン勘定系への移行では、複数行への対応や基盤の更改が加わります。並行稼働や移行リハーサル、運用訓練も必要になります。そのため、定期預金機能の価格として一括で比べると、見積の差を説明できません。
人件費・パッケージ・テスト・移行の内訳
見積は、工程と導入後の作業に分けて、金額を見ていきます。
- 人件費：要件定義と業務分析、管理、設計と開発、テスト
- 導入費：データ移行、インフラやDR、セキュリティ監査
- 稼働準備：リリース、教育、パッケージ、ライセンス
2026年の受託開発では、人月単価を60万〜200万円程度とする場合があります。金額は、金融業務に詳しいPMやアーキテクト、業務アナリストの比率によって変わります。契約形態や地域、難易度でも差が出ます。
単価だけで比べず、人数と期間、稼働率、成果物も確かめます。パッケージを導入する場合は、商品マスタの移行や画面・帳票の差分、API接続も必要です。加えて、権限設定と総合テスト、教育、保守も見込みます。
NECが2025年に公表した「NEC APIサービス for しんきん」は、パッケージ価格が税別200万円です。ただし、別途SI費用と月額保守料が必要だと明記されています（出典：日本電気、2025年）。
この事例は、公開されたパッケージ価格と導入の総額を分けて考える必要があることを示しています。
保守運用・クラウド・制度変更の費用
稼働後の費用は、保守体制やクラウドの利用量、制度変更の扱いによって増減します。契約の前に、次の内訳を決めておきます。
- 保守運用：監視や障害・脆弱性への対応、バックアップ、災害復旧訓練、問い合わせ
- クラウド：コンピュートやDB、ログ、バックアップ、通信、監視、DR環境
- 変更対応：金利や税率、商品規程、制度変更を、契約内に含めるか都度見積にするか
概算では、初期開発費の年5〜15％程度を保守運用費とする場合があります。ただし、24時間365日対応かどうかや、待機体制、SLAで変わります。クラウドの利用量やライセンス更新でも変動します。
金融庁は2026年5月、フロンティアAIによる脅威の変化を踏まえた、短期の対応を求める要請を公表しています。
こうした要請を受けて、認証やアクセス権、ログ監視の予算に加え、委託先管理やインシデント対応の予算も検討します（出典：金融庁「金融分野におけるサイバーセキュリティ対策について」、2026年）。
定期預金システムの見積もりを取る際のポイント
見積もりの精度を上げるには、業務ルールやデータ量、連携先を開発会社に示すことが基本です。さらに、品質基準と移行条件まで伝えておきます。
「満期処理」とだけ書くと、満期案内や自動継続まで含むのかが分かりません。休日処理や継続後の金利を明確にし、元利金の振替と失敗時の再処理も定めておきます。要件が曖昧なまま安い見積を選ぶと、追加費用や納期の延長が起きやすくなります。
RFPに入れるべき要件と受入基準
RFPでは、機能だけでなく、性能や運用、監査の条件も具体的に書きます。記載する情報は、次の項目に分けて整理します。
- 業務範囲：対象の商品とチャネル、月間と日次の取引件数、ピーク時の同時処理
- 稼働・復旧：稼働時間と停止可能な時間、目標とする復旧時間
- 管理と連携：マスタの変更権限や帳票、通知、外部連携、監査ログ、保管期間
本人確認やAML/CFTが別のシステムにある場合は、連携の仕様も指定します。送受信項目と連携方式、タイムアウト時の扱いに加えて、再送の条件も書きます。
受入基準は、画面の表示ではなく業務の結果で書きます。たとえば、元利金の継続後の満期日と金利、元金の継続時の利息振込、中途解約時の利率と税の再計算を、業務の結果として定義します。
各基準は、入力値と期待結果の組で書きます。加えて、旧システムとの残高照合や、ログの検索、障害後の再実行も、受入の条件に含めます。
2〜3社の同条件での比較
見積は2〜3社から取り、同じRFP、サンプルデータ、テスト条件のもとで比べます。価格差の理由が分かるよう、見積の項目は分けてもらいます。
- 開発範囲：要件定義や設計、開発、パッケージ、ライセンス、APIの範囲
- 導入・運用：移行やテスト、セキュリティ、教育、保守、クラウド、予備費
- 契約条件：含む範囲と含まない範囲、前提、変更単価、納期、支払、再委託
金融機関向けの実績の数だけでなく、定期預金に固有の仕様を説明できるかも確かめます。
特に、休日処理や利息の再計算、二重送信の防止を、どのように説明できるかを見ます。さらに、再処理や移行後の残高照合の進め方も、確認の対象にします。
提案の時点で、FISCや金融庁の要求に対する資料も確かめておきます。クラウドの事例として、ソニー銀行は2025年5月に、富士通とAWS上の次世代デジタルバンキングシステムを稼働させました。クラウドでは、疎結合化と運用設計を一体で確かめます（出典：ソニー銀行、2025年）。
見積漏れになりやすいリスク
見積の抜けは、追加費用や運用上の課題につながります。特に、移行と運用、セキュリティ、契約まわりの抜けに注意します。
- 移行と切替：データの整備やリハーサル、並行稼働、旧システムの停止と保管
- 検証と監査：受入試験や障害訓練、監査対応、リリースの判定
- セキュリティ：認証と認可、特権ID、暗号鍵、脆弱性診断、ログ監視、バックアップ、委託先と再委託先の管理、インシデント報告
- 契約と責任：成果物や受入基準、障害の責任、仕様変更、再委託、データの返却
過去の金利変更や中途解約の履歴を移行するには、項目の変換以上の作業が要ります。移行できないデータの扱い、手作業で補正したときの承認者、補正ログの保存期間も、費用と成果物に反映します。
FISC第13版は、金融庁のサイバーセキュリティガイドラインとの対応関係を整理しており、第14版へ更新されています。自社の適用基準を決めないまま「FISC対応」とだけ書くと、追加で対応する範囲があいまいになります。
チェック項目ごとに、対応方法と証跡、担当、費用を書いてもらいます。契約では、準委任と請負の使い分けや瑕疵対応を見ます。秘密保持と終了時の移行支援も、契約に含まれているかを確かめます。
要件が固まっていない構想や業務分析は準委任、仕様と成果物を確定した開発は請負など、工程に合う形を検討します。
発注側に商品規程と計算仕様の責任者を置いておくと、ベンダー任せにせず進められ、成功の確率が高まります。
よくある質問（FAQ）
企画の段階で寄せられやすい疑問に、順に答えます。費用や期間は対象の範囲によって変わるため、ここでの数字は予算取りの目安として考えてください。
定期預金システムの開発費用はいくらですか？
既存勘定系に接続して商品・金利・満期を管理する場合は1,000万〜3,000万円、銀行内モジュールの刷新は3,000万〜1億5,000万円が推定の幅です。
元帳を含む全面刷新や共同利用では、1億〜数億円以上になることがあります。パッケージ価格とSI費用は別々に見積もってもらいます。テストと移行、保守、クラウドも、項目ごとに切り分けます。
開発期間はどのくらいかかりますか？
小規模な周辺システムでは6〜12か月、複数システムの連携や移行を含む刷新では12〜24か月が目安です。
共同利用や勘定系全体の更改では2〜4年、全面刷新では3〜5年以上になることがあります。期間を左右するのは、商品数やチャネル、仕様書の有無です。移行データの品質や並行稼働期間によっても変わります。
工程表は、要件定義の結果を踏まえて確定させます。
定期預金システムをクラウドで開発しても問題ありませんか？
クラウドでも構築できます。金融機関のリスク管理に沿って、データの所在やアクセス権、暗号鍵を定義します。監視やバックアップ、災害復旧を決め、委託先管理と障害時の責任分界も定めます。
ソニー銀行は2025年5月、AWS上にコンテナを活用した次世代デジタルバンキングシステムを稼働させています。見るべきは、業務継続や監査証跡、復旧テストまで実装し、運用できるかどうかです。
パッケージとスクラッチはどちらを選ぶべきですか？
標準的な商品や事務を早く安定して導入したい場合は、パッケージが候補になります。一方で、独自の金利商品や特殊な業務を競争力にしたい場合は、スクラッチが候補です。
既存勘定系の周辺にパッケージを接続し、独自の部分だけを追加開発する方法もあります。その場合は、適合度やアドオンの保守、制度変更への対応を比べます。金利や税の変更、データの返却や終了時の移行支援も、確かめる項目です。
まとめ
定期預金システムの開発では、まず周辺システムにとどめるのか、預金元帳を含む勘定系の刷新まで広げるのかを切り分けます。
商品と金利、満期と継続、中途解約の条件を、業務のイベント単位で定義します。利息と税も、同じ単位で決めます。さらに、会計や顧客、AMLとの連携を含めて、監査ログと障害復旧も定めます。
テストケースや移行照合、受入基準を、運用体制も含めて要件定義の段階から見積と合わせて作ることが、成功への近道です。
スコープによる費用と期間の違い
予算取りでは、小規模構成を1,000万〜3,000万円、金融機関内のモジュール刷新を3,000万〜1億5,000万円と見ておきます。共同利用や勘定系移行は、1億〜数億円を検討する範囲です。
これらは公開価格ではなく、人月単価や金融向けの検証、移行と監査、DRを組み合わせた推定です。複数の会社から、同じ条件で見積を取ります。
初期費用に加えて、保守やクラウドまで比べます。制度変更や障害訓練の費用も、比較の対象に入れます。
最初に作るべき資料と次の一歩
まずは、現行の商品一覧や金利表、満期と中途解約の規程を集めます。そのうえで、連携先と処理量、移行データの項目を整理し、監査とセキュリティの要件と合わせて一つの資料にまとめます。
満期日が休日の場合と金利変更の場合について、期待する結果を例示データにします。通信断や同じ依頼の重複が起きた場合の結果も、例示データとして示します。資料をもとに2〜3社へRFPを配布すれば、価格や業務理解、実装・運用の現実性を比べられます。
▼全体ガイドの記事
・定期預金システムの完全ガイド
▼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を創業。