インターネットバンキングシステム開発の発注/外注/依頼/委託方法について

インターネットバンキングシステムの発注・外注では、画面を作るだけでなく、勘定系との接続、認証、不正取引の検知、監査ログ、24時間365日の運用までを一つの事業継続要件として委託先と合意することが重要です。

インターネットバンキングは、残高照会や振込を提供する顧客接点である一方、裏側では勘定系、為替、カード、本人確認、通知、監視など多くの仕組みが連携しています。本記事では、発注形態の選び方、RFPと要件整理、請負・準委任の使い分け、2026年時点の費用相場、委託先と見積書を比較するポイントを、発注担当者の実務に沿って解説します。

▼全体ガイドの記事
・インターネットバンキングシステム開発の完全ガイド

インターネットバンキングシステムの発注・外注とは何ですか？

インターネットバンキングシステムの発注・外注とは、金融機関やサービス事業者が、自社だけで開発するのではなく、金融SIer、パッケージベンダー、クラウド事業者、専門会社などへ企画支援から開発・運用の一部または全部を委託することです。大切なのは、作業を外部へ出すことと、事業上の判断や顧客保護の責任まで外部へ丸投げすることを分けて考えることです。

インターネットバンキングは、Webサイトやスマートフォンアプリの画面だけを指すものではありません。一般的には、顧客接点、APIゲートウェイ、認証基盤、インターネットバンキング業務サーバー、勘定系・為替・カードとの連携、不正検知、通知、監視、問い合わせ対応が連動して成立します。最終的な残高や取引結果をどのシステムが正本として持つのかを決めないまま発注すると、二重計上や照合不一致の責任分界が曖昧になります。

そのため、発注前に「今回作る部分」「既存のまま使う部分」「APIやファイルで接続する部分」を構成図に分けます。勘定系を刷新せず、チャネルと認証をAPI中心に段階的に更新する方法も現実的です。新しい画面を早く提供したい場合でも、照会系と更新系、同期処理と非同期処理、タイムアウト時の再送ルールを整理する必要があります。

外注範囲には、現行業務の調査、事業要件の整理、方式比較、RFP作成支援、要件定義、基本設計、詳細設計、開発、API接続、セキュリティ試験、データ移行、リリース、監視、保守、利用者サポートがあります。自社に金融業務の知識がある場合は、RFP作成を内製して性能試験や移行リハーサルだけを委託する方法もあります。

反対に、デジタルサービスを新しく立ち上げる事業者や、社内に勘定・決済の専門家が少ない企業は、企画段階から金融システムに詳しい会社へ相談する方が安全です。ただし「開発一式」と書くと、移行データの範囲、脆弱性診断、運用訓練、障害対応、制度改定が見積もりから抜けやすくなります。対象外の作業、納品物、受入基準を最初から明示します。

発注形態はパッケージ・クラウド・スクラッチのどれを選びますか？

発注形態は、金融向けパッケージ・共同利用型、クラウド・SaaS型、既存基盤と周辺開発を組み合わせるハイブリッド型、独自に作り込むスクラッチ型に分けて比較します。初期費用の安さだけでなく、標準機能に業務を合わせる負担、将来の制度改定、接続先の追加、障害時の責任分界、契約終了時の移行性を含む5年程度の総保有コストで評価します。

残高照会、入出金明細、振込・振替、通知など標準化しやすい機能を、実績のある運用手順とともに導入したい場合は、パッケージや共同利用型が候補になります。自社単独でセンター設備やソフトウェアを持つ負担を抑えやすく、共同利用型サービスの中には新機能を共通基盤へ追加しやすいものもあります。

NTTデータのANSERは、残高照会や入出金明細、振込・振替などを扱い、公式情報では全国500以上の金融機関に利用されていると説明されています（出典: 株式会社NTTデータ「ANSER」、2026年確認）。一方で、独自の顧客体験や特殊な業務フローは標準機能の制約を受けます。追加開発、接続先追加、データ移行、ライセンス更新、契約終了時のデータ返却を見積条件に含めます。

クラウド・API中心の構成は、勘定系を安定稼働させたまま、顧客向け画面、認証、通知、データ分析、外部サービス連携を段階的に更新したい案件に向いています。ピーク時の利用量に合わせて拡張しやすく、チャネル側の改修を勘定系から分離しやすい点がメリットです。

ただし、クラウドを採用すれば自動的に安くなるわけではありません。データ保存場所、暗号鍵の管理、特権アクセス、バックアップ、監視、可用性、障害時の切替、利用料の上限、再委託先、契約終了時のデータ返却を確認します。2025年1月には、複数の地域金融機関が参加するChance地銀共同化システムで、2025年から2032年までの金融ハイブリッドクラウド・プラットフォーム採用が公表されました（出典: 日本IBMニュースリリース、2025年）。共同利用とクラウドは実用段階にありますが、移行と運用設計の責任が消えるわけではありません。

独自の商品計算、特殊な決済、独自の顧客体験、既存業務との深い整合性、固有の性能要件を優先する場合は、スクラッチ開発が選択肢になります。しかし、自由度が高い分、設計、例外系の試験、監査証跡、制度改定、技術者の確保、長期保守を自社と委託先で担います。

標準的な残高照会や振込までゼロから作るのではなく、中核の取引処理は実績ある基盤に置き、差別化したい顧客体験やAPI、申込ワークフローへ投資する考え方もあります。スクラッチ部分を切り出す場合は、取引ID、処理結果の正本、再送・再処理、ログ、障害時の責任分界をRFPへ記載します。

RFP・要件整理では何を決めてから発注しますか？

RFPは、機能一覧を渡して価格を競わせるだけの資料ではありません。背景と目的、対象顧客、取引範囲、既存システム、非機能、セキュリティ、移行、運用、契約条件を同じ前提にそろえ、提案内容と見積書を比較するための発注基準です。業務部門、システム部門、リスク管理、法務、経理、監査、運用の代表者がレビューします。

現行調査では、ログイン、残高照会、明細照会、振込・振替、限度額変更、定期預金、ローン申込、各種届出、問い合わせ対応までを業務フローにします。顧客数、口座数、1日取引件数、ピーク時の同時接続数、夜間バッチ、休日カレンダー、保存年数、障害時の手作業も棚卸しします。法人向けであれば、利用者・承認者・管理者の権限、総合振込、給与振込、会計やERPとの連携も分けて整理します。

RFIでは、候補会社に対応可能な方式、標準機能と追加開発の境界、類似案件の対象範囲、既存勘定系との接続経験、移行方法、24時間運用、再委託の有無を質問します。確定価格を求めるよりも、実現方式と大きな前提条件を比較する段階です。候補を3〜5社程度へ絞ってから、同じRFPを配布すると提案差が見えやすくなります。

機能要件は、ログイン、MFA、残高・明細照会、振込・振替、登録先変更、限度額、通知、利用者管理、取引履歴、問い合わせ、管理者操作に分けます。法人向けなら、複数ユーザー、職務分掌、申請・承認・再鑑、電子証明書、ファイル取込、API連携、組戻しも加えます。正常系だけでなく、名義不一致、残高不足、二重依頼、タイムアウト、通信断、振込先変更、処理片側成功の結果もシナリオにします。

非機能要件は、稼働時間、目標稼働率、ピーク時の応答時間、同時処理数、RTO、RPO、バックアップ頻度、ログ保存期間、障害受付、復旧目標、切替訓練、アクセシビリティを数値や手順で指定します。「安全」「高可用性」といった形容詞だけでは提案を比較できません。測定方法、試験環境、合格基準を同じ欄に置きます。

認証はID・パスワードだけでなく、パスキーやFIDO2などフィッシングに耐性のある多要素認証、電子証明書、取引内容を確認する認証、端末や挙動を使うリスクベース認証を比較します。金融庁の監督指針は、重要な操作へのフィッシング耐性のある多要素認証、代替認証、ログイン通知、異常な挙動の検知、ログ保存などを着眼点として示しています（出典: 金融庁「中小・地域金融機関向けの総合的な監督指針」、2026年確認）。対象金融機関では、コンプライアンス部門と代替手段や解除率の扱いまで合意します。

FISCは2026年3月に第14版の「金融機関等コンピュータシステムの安全対策基準・解説書」を公表し、AI、サイバーセキュリティ、耐量子計算機暗号、システム障害事例などを改訂へ反映しています（出典: 金融情報システムセンター、2026年）。RFPでは「FISC準拠」とだけ記載せず、対象項目、設計書、委託先の確認、脆弱性診断、ペネトレーションテスト、監査証跡、改善期限へ分解します。

移行では、抽出、変換、クレンジング、名寄せ、コード変換、過去明細、匿名化、移行リハーサル、残高突合、取引件数照合を別の作業として見積もります。旧システムと新システムで残高、取引履歴、限度額、通知状態が一致することを確認し、切戻しの条件と手順も用意します。移行を本番直前の一度だけにすると、欠損や処理時間の問題を発見したときに日程を戻せなくなります。

契約形態は請負と準委任をどう使い分けますか？

契約形態は、成果物と完成条件が固まっているか、要件変更がどの程度見込まれるか、発注者側に判断できる人材がいるかで決めます。最初からすべてを一つの契約にまとめるより、現行調査・要件定義と設計・開発・移行で契約を分ける方が、リスクと責任を管理しやすいケースがあります。

請負契約は、合意した成果物を完成させ、検収を受ける責任を委託先が負う契約です。基本設計書、ソースコード、テスト結果、移行ツールなどの対象と合格条件を固めやすい、設計・開発・移行の一部に向いています。契約書には、仕様、納期、検収、契約不適合への対応、再委託、知的財産、秘密保持、個人情報、損害の扱いを明記します。

ただし、業務ルールが未確定なまま請負で価格と納期を固定すると、委託先が不確実性を価格へ上乗せするか、後から変更契約が増えます。「開発一式」ではなく、機能、接続先、性能、試験、移行回数、運用資料、教育を成果物単位に分けます。受入テストの合格基準と重大障害の判定も、発注前に合意します。

準委任契約は、一定の業務を専門家が遂行する契約で、現行調査、PMO、RFP作成支援、要件定義、アジャイル開発、運用改善など、作業内容が変化しやすい工程で使いやすい形態です。完成したシステムの結果だけでなく、月次の稼働、成果物、課題、意思決定事項、品質指標を確認する運営が必要です。

現実的には、現行調査と要件定義を準委任で進め、仕様と検収条件が固まった設計・開発・移行を請負にする組み合わせが考えられます。すべてを準委任にすると完成責任や予算上限が見えにくくなり、すべてを請負にすると未確定要件の変更費用が膨らみやすくなります。工程ごとの契約目的を明確にします。

仕様変更は、要望をそのまま承認せず、影響する機能、データ、連携、テスト、納期、費用、セキュリティを評価します。変更要求票に変更前後の仕様、追加工数、予算、承認者、リリース時期を記録し、RFPの対象外だったのか、設計不足だったのかも区別します。法令・制度改定の対応を保守費へ含める範囲と、個別見積もりにする範囲も決めます。

再委託先については、会社名、担当工程、データへアクセスできる範囲、所在国、セキュリティ確認、事故時の責任、監査方法を明らかにします。契約終了時には、顧客・口座・取引データを標準形式で返却できるか、設計書やAPI仕様を受け取れるか、移行支援を何か月受けられるかを定義します。出口戦略は、ベンダー変更のためだけでなく、事業継続のために必要です。

インターネットバンキングシステムの費用相場はいくらですか？

インターネットバンキングシステムは、金融機関向けの一律公開価格が少ないため、以下は機能範囲、接続先、利用者数、ピーク性能、移行、試験、運用を前提にした2026年時点の推定レンジです。一般的なシステム開発でも、費用は人件費と諸経費に分けて考え、要件定義を曖昧にしたまま進めないことが重要だと説明されています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年）。銀行向けでは、この一般論へ金融固有の試験・監査・運用を上乗せして考えます。

共同利用型やクラウド型パッケージを採用し、標準的な残高照会・明細照会・振込を既存勘定系へ接続する場合は、初期費用3,000万〜8,000万円、期間3〜9か月が一つの目安です。初期設定だけでなく、接続、画面調整、試験、移行を含む想定で、月額利用料や従量課金は別途になることがあります。

個人向けインターネットバンキングを既存勘定系と連携し、MFA、不正検知、通知、性能試験、脆弱性試験、24時間運用まで含める場合は、5,000万〜1億5,000万円、6〜12か月程度です。法人向けで、総合振込、給与振込、承認ワークフロー、電子証明書、API・ERP連携、移行まで実装すると、1億〜3億円、9〜18か月程度へ広がります。

複数チャネル、大量口座、独自業務、勘定系の改修、全国規模の切替、遠隔地DRを含むスクラッチ型は、3億〜10億円以上、18〜36か月以上になる可能性があります。これらは公定価格ではなく、銀行規模、口座数、ピーク取引、接続数、データ量、RTO・RPO、試験範囲によって大きく変わる発注前の予算レンジです。最初の概算では、含む範囲と含まない範囲を必ず併記します。

見積書は、要件定義・業務設計、UI・UX、アプリ・Web開発、API・勘定系接続、認証・不正検知、インフラ、データ移行、単体・結合・総合・性能試験、脆弱性診断、リリース支援、運用設計、教育へ分けます。さらに工程ごとの人月、単価、外部ライセンス、クラウド、テスト環境、移行回数、休日・夜間対応を分けてもらうと比較できます。

要件定義・業務設計は全体の5〜15%、設計・開発が大きな割合を占め、性能・脆弱性試験、移行・リリース、PM・監査・教育にも費用がかかるという分解をたたき台にします。ただし、これは固定の統計ではなく、予算を分解するための参考値です。「移行一式」「テスト一式」「運用支援一式」と書かれた項目は、対象データ、回数、担当者、完了条件を質問します。

ランニングコストには、クラウド・サーバー、ライセンス、監視、バックアップ、ログ保管、認証・SMS、脆弱性対応、24時間365日の受付、障害復旧、制度改定、保守要員、DR訓練、問い合わせ対応が含まれます。一般的な受託開発の解説では、運用保守費を新規開発費の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と契約を整えることが、品質と費用の両方を安定させます。

▼全体ガイドの記事
・インターネットバンキングシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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