インターネットバンキングの発注は、現行業務と責任範囲を整理し、方式・要件、契約・運用の順に決めていく流れで進みます。この順で決めておくと、顧客保護と事業継続につながります。発注形態、要件と契約、費用、委託先選定の観点で見ていきます。
▼全体ガイドの記事
・インターネットバンキングシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
インターネットバンキングシステムの発注・外注の意味
発注・外注とは、金融機関やサービス事業者が企画支援から開発・運用の一部または全部を外部へ委託することです。委託先には金融SIer、パッケージベンダー、クラウド事業者、専門会社などがあります。
作業の委託と、事業上の判断や顧客保護の責任は、分けて考えます。責任まで委託先に任せると判断の所在があいまいになるため、発注者が判断する範囲を契約前に決めておきます。
顧客チャネルと勘定系の分け方
発注する範囲は、顧客接点から取引処理までの構成と、既存設備との接続方法を整理して決めます。
- 顧客接点：Web・アプリ、APIゲートウェイ、認証基盤、業務サーバー
- 周辺機能：勘定系・為替・カード接続、不正検知、通知、監視、問い合わせ
- 構成図：新規開発、既存利用、API・ファイル接続の範囲を分けて示す
- 段階更新：勘定系を残し、チャネルと認証をAPI中心に更新する方法もある
- 接続条件：照会・更新の別、同期・非同期、タイムアウト時の再送の扱い
残高や取引結果の正本を、どのシステムが持つかも決めておきます。正本を決めないまま発注すると、二重計上や照合の不一致が起きたとき、どこまでの責任が誰にあるかがあいまいになります。
外注する範囲の決め方
外注する範囲は、自社の金融業務の知識と社内の専門人材を確認したうえで決めます。委託する作業は、おおむね次の工程に分けて選べます。
- 企画・設計：現行調査、事業要件、方式比較、RFP作成支援、要件定義、基本・詳細設計
- 開発・移行：開発、API接続、セキュリティ試験、データ移行、リリース
- 運用：監視、保守、利用者サポート
金融業務に詳しい社内の人材がいれば、RFPの作成は自社で行い、性能試験や移行リハーサルだけを委託する形もとれます。一方で、専門家が少ない新規事業者は、企画の段階から金融システムに詳しい会社へ相談すると安全です。
「開発一式」で発注すると、移行データや脆弱性診断が見積もりから抜けることがあります。運用訓練や障害対応、制度改定も、抜けやすい作業です。そこで、対象外の作業、納品物、受入基準を明示します。
パッケージ・クラウド・スクラッチから選ぶ発注形態
方式は、金融向けパッケージ・共同利用型、クラウド・SaaS型、既存基盤と周辺開発を組み合わせるハイブリッド型、スクラッチ型から比べます。初期費用だけでなく、5年程度の総保有コストで評価します。
比較の条件には、標準機能に業務を合わせる負担や制度改定への対応、障害時の責任分界も含めます。接続先の追加と、契約終了時の移行性も、同じ条件で比べます。
パッケージ・共同利用型が向く案件
標準化しやすい照会・取引・通知を導入する場合は、実績ある運用手順を含むパッケージや共同利用型が候補になります。
- 照会機能：残高照会、入出金明細
- 取引機能：振込・振替
- 通知機能：標準化できる通知
自社単独でセンター設備やソフトウェアを持つ負担を抑えられるのが、この方式の利点です。共同利用型の中には、新しい機能を共通基盤へ追加しやすいサービスもあります。
NTTデータのANSERは、残高照会、入出金明細、振込・振替などを扱います。公式情報では、全国500以上の金融機関に利用されていると説明されています（出典：株式会社NTTデータ「ANSER」、2026年確認）。
独自の顧客体験や業務フローは、標準機能の制約を受けます。
見積もりの条件には、追加開発と接続先の追加を含めます。データ移行やライセンス更新、契約終了時のデータ返却も、条件として書き出します。
クラウド・API中心のハイブリッド型の評価
クラウド・API型は、適用範囲と運用条件を整理してから評価します。
- 適用範囲：勘定系を保ち、画面、認証、通知、分析、外部連携を段階更新
- 拡張性：ピーク利用に合わせて拡張し、チャネル改修を勘定系から分離
- データと権限：保存場所、暗号鍵、特権アクセスの扱い
- 運用継続：バックアップ、監視、可用性、障害時の切替、利用料の上限
- 契約条件：再委託先の扱いと、終了時のデータ返却
2025年1月、複数の地域金融機関が参加するChance地銀共同化システムの採用が公表されました。採用期間は2025年から2032年までです（出典：日本IBMニュースリリース、2025年）。
共同利用やクラウドは実用段階にありますが、移行と運用設計の責任は残ります。ただし、クラウドを採用しても、それだけで費用が自動的に下がるわけではありません。
スクラッチ開発を選ぶケース
独自の商品計算や特殊な決済、独自の顧客体験を優先する場合は、スクラッチが候補になります。既存業務との深い整合性や固有の性能要件が必要な場合も、候補に入ります。
自由度と引き換えに、設計や例外試験、監査証跡を含め、担う範囲が広がります。制度改定への対応や人材確保、長期保守も、継続して必要になります。
また、標準的な残高照会や振込は実績ある基盤へ置き、差別化する顧客体験やAPI、申込ワークフローへ投資する方法もあります。スクラッチ部分では、取引IDと処理結果の正本を決めたうえで、再送・再処理、ログ、障害時の責任分界をRFPに記載します。
RFP・要件整理で決めておくこと
RFPは、価格を比べるための機能一覧にとどまらず、提案と見積もりを同じ基準で比べる発注基準になります。背景や目的、対象顧客、取引範囲を前提として示し、既存システムの状況も添えます。非機能やセキュリティ、移行、運用、契約条件は、各社が同じ前提で答えられるように書きます。
レビューには、業務とシステムの代表者に加えて、リスク管理と法務、経理の代表者も入ります。監査と運用の代表者も加わると、部門間で前提をそろえやすくなります。
現行調査とRFIの確認事項
現行調査とRFIでは、必要な業務やシステム規模を把握し、候補会社の前提をそろえます。調査対象は、次の観点で分けて整理します。
- 業務フロー：ログイン、照会、振込・振替、限度額、定期預金、ローン、届出、問い合わせ
- 規模と運用：顧客・口座数、1日取引数、ピーク接続、夜間バッチ、休日、保存年数、障害時の手作業
- 法人業務：権限、総合振込、給与振込、会計・ERP連携
- RFIの質問：方式、標準・追加開発、類似案件、勘定系接続、移行、24時間運用、再委託
- 候補選定：確定価格より方式と前提を比べ、3〜5社程度に同じRFPを配布する
機能要件と非機能要件の具体化
機能要件では、利用者と取引の機能を列挙し、正常系と例外系のシナリオを定めます。法人向けの追加機能と、確認すべき異常ケースも整理します。
- 個人向け：ログイン、MFA、照会、振込・振替、登録先、限度額、通知、取引履歴、問い合わせ、管理者操作
- 法人向け：複数利用者、職務分掌、申請・承認・再鑑、電子証明書、ファイル取込、API連携、組戻し
- 例外系：名義不一致、残高不足、二重依頼、タイムアウト、通信断、振込先変更、片側処理成功
非機能要件では、稼働時間と目標稼働率、ピーク時の応答時間と同時処理数を指定します。RTO・RPOや復旧目標、障害受付の体制も含めます。
バックアップ頻度やログ保存期間も、要件として並べます。切替訓練とアクセシビリティも、同じ要件に入れます。
「安全」「高可用性」といった言葉は、測定方法や試験環境、合格基準まで落とし込んで初めて比較に使えます。
認証・不正対策・移行の要件化
認証方式は、ID・パスワードに加えて、パスキーやFIDO2などを比べます。電子証明書や取引認証、端末や挙動を使うリスクベース認証も、比較の対象になります。
金融庁の監督指針は、重要な操作へのフィッシング耐性のある多要素認証を示しています（出典：金融庁「中小・地域金融機関向けの総合的な監督指針」、2026年確認）。代替認証とログイン通知も着眼点になり、異常な挙動の検知やログ保存も確認の対象になります。
対象金融機関は、コンプライアンス部門と代替手段や解除率の扱いを合意しておきます。FISCは2026年3月、第14版「金融機関等コンピュータシステムの安全対策基準・解説書」を公表しました。同版は、AIやサイバーセキュリティ、耐量子計算機暗号などに加え、システム障害事例も反映しています（出典：金融情報システムセンター、2026年）。
RFPでは「FISC準拠」を、対象項目、設計書、委託先確認に分けて書きます。残りの項目は、脆弱性診断やペネトレーションテスト、監査証跡、改善期限になります。
- 抽出、変換、クレンジング、名寄せ、コード変換を見積もる
- 過去明細、匿名化、移行リハーサルを対象に含める
- 旧新の残高・取引件数、履歴、限度額、通知状態を照合する
- 切戻し条件と手順を定め、本番前に検証する
本番直前に一度だけ移行すると、欠損や処理時間の問題が見つかっても、日程を戻せません。
契約形態の使い分け（請負と準委任）
契約は、成果物と完成条件、要件変更の見込み、発注者側で判断を担える人材を踏まえて選びます。現行調査と要件定義、設計・開発・移行で契約を分けると、リスクと責任を管理しやすい場合があります。
請負契約が向く工程
請負契約では、合意した成果物を完成させ、検収を受ける責任を委託先が負います。成果物と完成条件が明確な工程に向いており、そのうえで契約条件や変更時の注意点を確認します。
- 向く工程：成果物と合格条件を定めやすい設計、開発、移行の一部
- 成果物例：基本設計書、ソースコード、テスト結果、移行ツール
- 契約条件：仕様、納期、検収、契約不適合、再委託、知的財産、秘密保持、個人情報、損害
- 成果物の範囲：機能、接続先、性能、試験、移行回数、運用資料、教育ごとに範囲を決める
- 受入条件：テストの合格基準と重大障害の判定を、事前に合意しておく
業務ルールが決まらないまま価格と納期を固定すると、不確実性の上乗せや変更契約の増加につながります。そこで、「開発一式」とせず、成果物単位に分けて発注します。
準委任契約が向く工程
準委任契約は、専門家が一定の業務を遂行する契約です。作業内容が変わりやすい現行調査やRFP支援、要件定義に使いやすい形態です。PMOやアジャイル開発、運用改善にも向きます。
完成したシステムだけでなく、月次の稼働や成果物、課題を確認します。意思決定事項や品質指標も見ます。現行調査と要件定義を準委任とし、仕様確定後の設計・開発・移行を請負にする方法もあります。
すべてを準委任にすると、完成責任や予算上限が見えにくくなります。一方、すべてを請負にすると、未確定の要件の変更費用が膨らみやすくなります。そこで、工程ごとに目的を明確にして契約を選びます。
仕様変更・再委託・契約終了の管理
仕様変更、再委託、契約終了は、それぞれ記録と確認項目を決めて管理します。
- 変更影響：機能、データ、連携、試験、納期、費用、セキュリティを評価する
- 変更記録：変更前後、追加工数、予算、承認者、リリース時期を残す
- 変更区分：当初対象外か設計不足か、制度改定の保守内か個別見積もりかを分ける
- 再委託：会社名、工程、データアクセス、所在国、安全確認、事故時の責任、監査方法を確認
- 契約終了：顧客・口座・取引データの標準形式返却、設計書、API仕様、終了後の移行支援期間を定義する
出口戦略は、ベンダー変更だけでなく、事業継続のためにも必要です。
インターネットバンキングシステムの費用相場
金融機関向けの一律の公開価格は少ないため、ここで示すのは2026年時点の推定レンジです。前提には、機能範囲と接続先、利用者数とピーク性能を置き、移行、試験、運用も含めて考えます。
一般的な開発費も人件費と諸経費に分け、要件を曖昧にしないことが重要と説明されています（出典：SIA株式会社「システム開発の費用・相場 2026年版」、2026年）。銀行向けでは、金融固有の試験や監査、運用も加味して考えます。
規模別の費用相場と期間
規模別の予算レンジは、機能や接続先、移行・運用の範囲によって変わります。次に示すのは、発注前の目安です。
- 共同利用型・クラウド型パッケージ：初期費用3,000万〜8,000万円、3〜9か月
- 個人向け、MFA・不正検知・24時間運用を含む：5,000万〜1億5,000万円、6〜12か月
- 法人向け、承認ワークフロー・電子証明書・API連携を実装：1億〜3億円、9〜18か月
- 大規模なスクラッチ型：3億〜10億円以上、18〜36か月以上
共同利用型・クラウド型パッケージの案は、標準的な残高照会・明細照会・振込を既存勘定系へ接続する想定です。初期設定から試験、移行までを含みます。月額利用料や従量課金は、別途になることがあります。
個人向け案は、既存勘定系との連携とMFA、不正検知を含む想定です。通知や性能・脆弱性試験、24時間運用も、想定に入っています。法人向け案には、総合振込と給与振込、承認を含みます。電子証明書やAPI・ERP連携、移行も入ります。
大規模案では、複数チャネルや大量口座、独自業務を含む可能性があります。勘定系の改修や全国規模の切替、遠隔地DRが入ることもあります。
金額は公定価格ではなく、銀行規模や口座数、ピーク取引で変わります。接続数やデータ量、RTO・RPO、試験範囲も金額を左右します。そのため、概算には含む範囲と含まない範囲を併記します。パッケージ案では、初期設定から移行までの条件も明記します。
見積書の内訳の分け方
各社の対象範囲を比べるため、インターネットバンキングの見積もりは工程と費目ごとに分けてもらいます。
- 設計・開発：要件、業務設計、UI・UX、アプリ・Web、API・勘定系接続
- 安全・基盤：認証、不正検知、インフラ、脆弱性診断
- 移行・試験：データ移行、単体・結合・総合・性能試験、リリース支援
- 導入・運用：運用設計、教育、PM、監査
人月と単価は、費目ごとに分けます。外部ライセンスやクラウド、テスト環境に加えて、移行回数や休日・夜間対応も分けて示してもらいます。
要件定義・業務設計は、全体の5〜15%を参考に分解できます。設計・開発の割合は大きく、性能・脆弱性試験や移行・リリースにも費用がかかります。さらに、PM・監査・教育にも費用がかかります。
この比率は固定統計ではなく、予算を分解するための参考値です。「移行一式」「テスト一式」「運用支援一式」と書かれた項目は、対象データや回数、担当、完了条件を確認します。
初期費用以外のランニングコスト
運用費には、基盤や監視・保全、安全対策、運用対応の費用が含まれます。
- 基盤：クラウド・サーバー、ライセンス
- 監視・保全：稼働状況の見守り、バックアップ、ログ保管、DR訓練
- 安全対策：認証・SMS、脆弱性対応
- 運用対応：24時間365日の受付、障害復旧、制度改定、保守要員、問い合わせ
一般的な受託開発では、運用保守費を新規開発費の15〜25%程度とする目安もあります（出典：SIA株式会社「受託開発費の相場と9つの決定要素」、2026年7月更新）。金融向けでは、クラウドの従量費や不正検知の取引量課金も分けて、5年総額で確認します。
費用を抑えるには、チャネルや商品を段階的に導入する方法や、標準機能を採用する方法、勘定系を残して周辺を分離する方法を比べます。ただし、試験や移行は削らない前提で考えます。
監視や制度改定、障害対応が別料金かどうかを確認します。データ返却や再委託管理も、確認の対象です。
委託先選定と見積比較の要点
委託先は、知名度や提示価格より先に、金融業務の経験や類似規模の実績で見極めます。そのうえで、勘定系や為替との接続、認証と不正検知、移行と性能試験を確認します。さらに、監査や24時間運用、障害対応、進行管理も見ます。
「銀行向けの実績がある」というだけで終わらせず、どの会社がどの工程を何年間担当したかまで聞きます。責任者や実務担当の経験も確かめます。
委託先の金融実績の確認項目
類似案件の範囲と、委託先の実務体制を確認します。
- 類似案件：金融機関名、担当範囲、利用者規模、取引量、勘定系接続、移行件数、切替方法、稼働後の保守、障害時の連絡時間
- 提案体制：可能であれば、プロジェクト責任者、アーキテクト、移行責任者、セキュリティ責任者の参加を確認
- 試験担当：脆弱性診断やペネトレーションテストを担当する人
- 委託・監査体制：再委託先、データへアクセスする国・拠点、監査資料の提出周期
- 対応力：実績件数より、自社に似た課題への対応と改善を担える体制
見積書の比較条件
相見積もりでは、要件と見積項目を共通条件にそろえて、各社の対応方法を比べます。
- 共通条件：同じRFP、利用者数、ピーク取引数、稼働時間、RTO・RPO、試験範囲
- 見積区分：機能ごとに標準、設定、追加開発、外部サービス、対象外を確認
- 評価項目：機能適合、方式、安全、非機能、移行、運用、契約、体制、費用、日程
- 配点例：費用30点、金融・業務適合性20点、安全・非機能20点、移行・運用15点、体制・契約15点
- 選定判断：同じ要件を効率よく満たすかを見て、追加費用や各社の前提も確認
金額だけで選ぶと、後から必要になる試験や運用の追加費用を見落としがちです。配点は、社内で優先する項目に合わせて調整します。
発注後に起きやすいリスクと防ぎ方
発注後に起きやすいリスクは、要件の追加や勘定系との仕様差、ピーク性能の不足です。認証利用率の低さや移行不一致、連絡遅れ、再委託先の把握不足も、リスクになります。その管理には、次の活動を組み込みます。
- 進行管理：週次の課題管理、月次の経営報告、変更要求票
- 品質確認：設計レビュー、性能試験、移行リハーサル、セキュリティ検査
- 継続訓練：障害対応の演習と、対応手順の確認
金融庁はインターネットバンキングを非対面取引特有のリスク領域とし、分析や対策、効果検証、見直しを重視します（出典：金融庁「中小・地域金融機関向けの総合的な監督指針」、2026年確認）。そのため、外注後も、発注者はサービス全体のリスクを把握します。顧客説明、被害時の連絡と補償、再発防止は、自社の管理項目に残します。
インターネットバンキングシステムの発注・外注でよくある質問
外注では費用だけでなく、責任分界、顧客保護、運用継続性も確認します。発注前によくある疑問に答えます。
インターネットバンキングシステムはどこまで外注できますか？
企画や現行調査から、RFP作成、要件定義までを委託できます。設計・開発や接続、試験も委託の対象です。移行、運用設計、監視、保守まで委託できます。
ただし、サービス範囲やリスク許容度、予算は発注者に残ります。契約方針や障害時の判断、顧客説明も、発注者が担います。
作業を委託する範囲と、責任を委託する範囲を分けて契約します。責任分担は、契約時に明文化しておきます。
クラウド型へ外注しても金融システムを運用できますか？
運用はできますが、クラウドを採用するだけでは要件を満たせません。要件を満たすには、発注の段階で条件を決めておく必要があります。データの所在や暗号鍵、権限、バックアップを発注条件として書きます。監視や可用性、復旧、委託先・再委託先、契約終了時の移行も、条件に入れます。
銀行などの金融機関は、FISCや金融庁の考え方を、自社のリスク評価や設計、試験に反映します。そのうえで、運用責任と確認方法も決めておきます。
見積もりは何社から取れば比較できますか？
RFIでは3〜5社程度に方式と実績を確認し、RFPでは2〜4社程度へ同条件で提案を依頼します。ただし、社数を増やしすぎると、質疑や評価の負担が増えます。
金融実績、接続方式、移行、運用体制で候補を絞り、同じ評価表を使います。そうすると、条件がそろわない価格比較を避けられます。
費用を抑えるために削ってはいけない項目は何ですか？
認証や不正検知、監査ログは、費用を理由に削らない方がよい項目です。性能試験や脆弱性診断、移行突合も、削らないでおきたい項目です。バックアップ復元やDR切替、障害訓練も同じ扱いです。
そのうえで、費用を抑えるなら、チャネルや商品を分けて段階的にリリースし、標準機能を採用します。後から追加する範囲を明確にします。省略する場合は、リスクと代替策を経営・リスク管理部門が承認します。
まとめ：発注前に決めておく責任分界と5年TCO
発注では、顧客チャネルと勘定系の範囲を分け、標準機能か独自機能かを決めます。そのうえで、認証や不正対策、監査、移行、運用を要件に落とし込みます。共同利用、クラウド・API型、スクラッチ型は、5年TCOと変更しやすさで比べます。
発注前にそろえる資料
まず、目的とKPI、対象顧客、機能一覧、業務フロー、構成図をそろえます。接続先や利用者数、ピーク取引数も、資料に添えます。
非機能・セキュリティや移行、運用の条件を記載します。予算と希望時期、対象外も書き添えます。
候補会社には、標準・追加開発・対象外の区分と、見積前提を提示してもらいます。リスクや再委託先、終了時の移行方法も、併せて示してもらいます。こうして条件をそろえると、提案を比較できます。
迷った場合の段階発注
要件が未確定なら、大規模な請負契約を結ばず、現行調査とRFP作成支援を先に発注します。
発注者は、方式と対象範囲を固めてから、開発契約へ進む段階発注を選べます。
- 現行調査とRFP支援で方式と発注範囲を固める
- 残高・取引結果の正本、顧客保護、障害時の判断者、データ・ログの管理者を決める
- 条件をそろえて提案価格と契約内容を比べ、開発契約へ進む
金融システムは、稼働後も不正対策や制度改定、障害対応が続くサービスです。監査や利用者支援も続きます。発注者の判断を保ちつつ、委託先の専門性を活かす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を創業。