モバイルバンキングシステム開発の発注/外注/依頼/委託方法について

モバイルバンキングシステムの発注・外注では、アプリの画面を作るだけでなく、勘定系との接続、認証、不正送金対策、監視、障害時の運用までを含めて委託範囲を決めることが重要です。企画段階でスコープと責任分界を整理できれば、初期費用だけでなく5年間の運用費まで見通しながら、開発会社を比較できます。

この記事では、モバイルバンキングシステムを発注・外注する際の進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較の順に解説します。FISCや金融庁のサイバーセキュリティ対策をRFPと受入テストへ落とし込む方法、標準サービスとスクラッチ開発の使い分け、丸投げを避ける社内体制まで具体的に確認できます。

▼全体ガイドの記事
・モバイルバンキングシステム開発の完全ガイド

モバイルバンキングシステムとは何ですか？

モバイルバンキングシステムとは、スマートフォンを顧客接点として、残高照会、振込、口座開設、本人確認、各種申込などの銀行サービスを非対面で提供するチャネルシステムです。スマートフォンアプリ単体ではなく、アプリ、APIゲートウェイ、認証基盤、勘定系・情報系システム、外部決済、管理画面、監視、不正検知、顧客サポートまでを一つのサービスとして考えます。

発注時に最初に分けるべきなのは、利用者が操作するアプリと、金融取引を安全に処理するバックエンドです。アプリにはSwift、Kotlin、Flutterなどの選択肢がありますが、残高や送金の業務ロジックをアプリへ持たせる設計は避けます。認証・認可、取引の冪等性、タイムアウトと再送、監査ログ、画面へ返すエラー情報は、API層とバックエンドで統制します。

たとえば利用者が振込ボタンを二度押した場合、同じ取引が二重に実行されない仕組みが必要です。通信が切れた場合も、取引が未実行なのか実行済みなのかを確認できなければなりません。このような業務要件をRFPに書かず、「銀行アプリを開発してください」と依頼すると、見た目は完成しても本番運用で必要な安全性と復旧性が不足します。

次に、今回のプロジェクトが「既存インターネットバンキングのアプリ刷新」なのか、「APIチャネルを新設する取り組み」なのか、「勘定系を含むデジタルバンク基盤の刷新」なのかを明確にします。残高・明細・通知だけのMVPであれば既存APIを活用できますが、口座開設、eKYC、振込、ことら送金、税公金、ローンまで一度に含めると、接続先と審査・テストの範囲が大きくなります。

成果指標はダウンロード数だけにしません。月間アクティブユーザー率、振込完了率、口座開設の申込完了率、窓口手続きの削減時間、問い合わせ件数、不正検知率、障害からの復旧時間を組み合わせます。マネーフォワードエックスの2025年発表では、BANK APPの総ダウンロード数が40万件を超え、年間平均MAU率は83％でした（出典: マネーフォワードエックス「BANK APP導入金融機関における利用実績」、2025年）。発注時点から利用継続と業務成果をKPIに入れると、納品後の評価がしやすくなります。

発注形態はどれを選ぶべきですか？

結論として、発注形態は機能の独自性だけでなく、金融機関が保有したい運用能力と変更速度で選びます。短期間で標準機能を導入するならホワイトレーベルやSaaS、既存資産と大規模な勘定系連携を重視するなら共同利用や大手SI、独自の顧客体験と内製化を重視するならスクラッチまたはクラウドネイティブが候補になります。

ホワイトレーベルは、認証、残高照会、振込、通知、各種申込などの共通機能をベンダーの基盤で提供し、金融機関のロゴや色、画面を自社ブランドとして展開する方式です。アプリをゼロから作る工数を抑えられるため、若年層向けの接点を早く整えたい場合や、複数行で共通機能を利用したい場合に適します。一方で、独自の業務ルール、特殊な商品、データ分析、画面遷移を追加するほど個別開発が増え、標準サービスの価格優位性が小さくなります。

日立は2025年、既存の「Branch in Mobile」をAWS上で運用するSaaS型サービスとして提供開始しました。金融機関側の環境構築負担を抑えつつ、対面・非対面のチャネルをつなぎ、簡易な追加・変更を金融機関側で内製化できる点が示されています（出典: 日立製作所「Branch in Mobileをクラウドサービスとして提供開始」、2025年）。提案を受ける際は、標準機能の一覧だけでなく、設定変更と個別開発の境界を確認します。

共同利用型では、複数の金融機関が共通のAPI基盤や機能を利用し、自行固有の部分だけを設定・拡張します。接続仕様、運用ノウハウ、セキュリティ対策を共有できるため、単独で全機能を構築するよりもリスクと費用を抑えやすくなります。ただし、独自要件を標準へ合わせる意思決定が必要であり、機能追加の優先順位を自社だけで決められない場合があります。

筑波銀行は2025年12月、TSUBASA FinTech共通基盤を利用した銀行アプリ刷新に着手し、サービス開始を2027年1月頃と発表しました。同基盤は外部事業者が共通仕様で銀行システムへ接続しやすくするオープンAPI基盤です（出典: 筑波銀行「TSUBASA FinTech共通基盤の利用およびスマートフォンアプリの刷新」、2025年）。このような方式を比較するときは、参加行の標準仕様に自行の業務を合わせられるかを、現行業務一覧と照合します。

スクラッチ開発やクラウドネイティブ開発は、独自のUX、商品設計、データ活用、将来の内製化を重視する場合に有効です。アプリの自由度が高い反面、認証、可用性、監査、障害対応、勘定系連携を自社が理解し続ける必要があります。外部委託を選んでも、プロダクトオーナー、業務責任者、セキュリティ責任者を銀行側に置かなければ、変更のたびにベンダーへ依存しやすくなります。

方式を一つに決めきれない場合は、残高照会と通知を標準サービスで先行し、口座開設や送金を段階的に追加する構成も現実的です。方式の比較表を作るときは、導入期間、初期費用、月額費用、独自要件への対応、データの帰属、障害時の代替手段、契約終了時の移行可否を同じ項目で並べます。

モバイルバンキングシステム発注の進め方

発注は、要件を一度に固めて開発会社へ渡す作業ではありません。現行システムと業務を調査し、MVPの範囲を決め、要件・非機能・移行・運用を文書化し、提案と見積を比較してから契約します。企画、設計、開発、テスト、移行の各段階で金融機関側の判断事項を残すことが、外注プロジェクトの品質を安定させます。

最初に、対象顧客、解決したい課題、既存インターネットバンキングとの役割分担、提供地域、取引上限、リリース時期、KPIを決めます。その後、勘定系、情報系、顧客管理、認証、ATM、外部決済、eKYC、コールセンター、監視の現状を一覧化します。APIが存在していても、参照専用なのか更新処理まで可能なのか、ピーク時の性能や障害時の振る舞いが決まっているのかで、見積は大きく変わります。

現行調査の成果物には、システム構成図、データ連携一覧、認証方式一覧、業務フロー、障害時の手作業、保守契約、OS更新の制約を含めます。既存ベンダーから情報を取得できない場合は、RFPの前提条件に「現行仕様の確認期間」を設け、調査後に見積を更新する段階契約を検討します。

RFPには、目的と対象ユーザー、対象機能、画面数、対応OS、外部連携、想定ユーザー数、ピーク取引数、可用性、認証、ログ、監査、バックアップ、災害対策、データ移行、教育、保守を記載します。機能要件だけでなく、RTO・RPO、目標応答時間、同時利用者数、障害通知の時間、脆弱性診断の範囲、再委託先の管理方法も必須項目です。

セキュリティ要件は、「安全にしてください」という表現で終わらせません。FIDOや生体認証をどの取引で使うか、端末変更時に何を再確認するか、振込限度額をどう設定するか、フィッシングや不正端末をどう検知するか、監査ログを何年間保存するかまで業務シナリオで表します。FISC第13版は2025年3月に発行され、開発・導入・運用の安全対策に加え、金融庁のサイバーセキュリティガイドラインやオペレーショナル・レジリエンスなどを反映しています（出典: 金融情報システムセンター「金融機関等コンピュータシステムの安全対策基準・解説書 第13版」、2025年）。

設計では、アプリ、BFF、APIゲートウェイ、認証、勘定系連携、通知、管理画面、監視、バックアップの責任範囲を決めます。テストは単体・結合だけでなく、実機とOSの組み合わせ、性能、長時間稼働、障害復旧、脆弱性、ペネトレーション、業務受入まで含めます。特に送金処理は、二重送信、タイムアウト、通信断、メンテナンス時間、取消・組戻しをシナリオ化します。

リリース前には、問い合わせ窓口、本人確認に失敗した場合の案内、アカウントロック解除、障害時の告知、手作業への切り替え、インシデント報告の訓練を行います。移行対象データは、移行元と移行先の項目対応、欠損時の扱い、照合件数、戻し方を決めてから実施します。リリース判定をベンダー任せにせず、銀行側の業務責任者が承認できる基準にしておくことが大切です。

RFPと要件整理で決めるべきこと

RFPは、開発会社に価格を出してもらうためだけの資料ではありません。自行が何を決め、何を委託し、何を受け入れるのかを社内で合意する文書です。候補会社から同じ粒度の回答を得るため、現状、目的、対象範囲、前提、必須要件、提案してほしい事項、評価方法、契約条件を一つの資料にまとめます。

業務要件は「振込機能が必要」と書くのではなく、「個人顧客が登録済みの振込先へ送金し、取引結果を通知で確認する」と書きます。そのうえで、初回登録、認証、限度額超過、残高不足、メンテナンス、組戻し、問い合わせまでの業務フローを定義します。口座開設なら、申込、eKYC、審査、口座番号の通知、キャッシュカード送付、本人確認失敗時の再申請までを一連の要件にします。

管理画面の要件も忘れません。お知らせ配信、ユーザー状態の確認、取引照会、操作権限、監査ログ、コンテンツ更新、障害時の告知を誰が担当するかを決めます。ここが曖昧だと、開発後に「銀行職員が自分で変更できない」「変更のたびに保守費が発生する」という問題が起こります。

非機能要件は、候補会社の提案力と見積の妥当性を分ける項目です。可用性は年間稼働率だけでなく、計画停止の扱い、冗長化の単位、切り替え時間を確認します。性能は平均応答時間だけでなく、給料日やキャンペーン時の同時利用者数、取引ピーク、負荷試験の方法を指定します。

セキュリティでは、金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」を参照し、脆弱性管理、委託先・再委託先の管理、インシデント報告、復旧訓練、ログ監視を要件化します。金融庁は2025年7月に同ガイドラインを一部改正し、組織改編に伴う技術的修正を行いました（出典: 金融庁「金融分野におけるサイバーセキュリティに関するガイドラインの一部改正」、2025年）。基準名を列挙するだけでなく、提案書で対応箇所、テストで確認する証跡、契約で負担する主体を答えてもらいます。

受入基準は、画面が表示されることだけにしません。業務シナリオが最後まで成功すること、エラー時に正しい案内が出ること、監査ログが残ること、復旧手順を実行できること、端末・OSの対象範囲で不具合がないことを基準にします。テスト結果、脆弱性診断報告書、性能試験結果、移行照合結果、運用手順書を納品物として明記します。

また、開発途中で制度改正やAPI仕様変更が起こる前提で、変更要求の受付、影響分析、見積、承認、リリースの流れを定義します。必須要件、優先要件、将来要件を分けておくと、MVPの納期を守りながら機能を追加できます。変更のたびに口頭合意を重ねるのではなく、決定ログとして残すことが重要です。

契約形態と責任分界はどう決めますか？

モバイルバンキングシステムでは、すべてを一つの契約形態に押し込めるより、工程の性質に合わせて契約を組み合わせる方が現実的です。要件が固まっていない調査・企画は準委任、仕様と成果物が明確な実装・検収は請負、標準サービスの利用はSaaS契約、認証やeKYCなど外部サービスは利用規約と個別契約を確認します。

準委任は、専門人材の稼働や調査・設計・アジャイル開発の支援を受ける場合に適します。成果物の完成責任を一括で負わせる契約ではないため、業務を一緒に探索する初期フェーズで使いやすい一方、稼働時間、担当者、報告、成果物、品質基準を別途明確にします。請負は、要件、成果物、検収条件、納期が固まった機能に向きますが、曖昧な仕様のまま締結すると、変更費用や追加納期を巡る対立が起きやすくなります。

実務では、現行調査と要件定義を準委任で行い、基本設計の完了時に見積を更新し、実装・テストを請負または段階的な契約へ移す方法があります。契約を分ける場合は、前工程の成果物の権利、次工程を受けない場合の引き継ぎ、既存ベンダーとの協力範囲を定めます。

SaaSやクラウドを利用する場合は、サービス提供時間、計画停止、障害の重要度、一次報告の時間、復旧目標、補償、バックアップ、データ所在、再委託、監査権限、脆弱性への対応期限を確認します。クラウド事業者が基盤を守っていても、認証設定、アプリの脆弱性、APIの権限、ログの確認を誰が行うかは別問題です。責任分界表を契約書と設計書の双方に添付します。

障害時には、ベンダーが金融機関へ報告するだけでなく、利用者への告知、取引の照合、二重処理の確認、監督当局や関係機関への連絡、再発防止の期限まで必要になります。インシデント対応訓練を年何回行うか、訓練結果をどのように改善へ反映するかも、長期運用を委託するなら契約条件に含めます。

外注先を選ぶときは、開発中の成果物だけでなく、契約終了時に何を返してもらえるかを確認します。ソースコード、設計書、API仕様、インフラ設定、監視ルール、テストコード、ログ、データ、アカウント情報、暗号鍵の管理責任を明記します。標準SaaSでソースコードを取得できない場合は、データを標準形式で出力できるか、移行支援の費用と期間、並行稼働の方法を定めます。

再委託先の追加、国外拠点の利用、サービスの仕様変更、料金改定、買収や事業撤退なども想定します。金融機関側で最低限の運用を継続できるよう、管理者教育とドキュメント更新を契約に含めると、ベンダーロックインのリスクを下げられます。

モバイルバンキングシステムの費用相場

モバイルバンキングシステムの費用は、公開された統一価格がほとんどないため、次の金額は2026年時点の予算策定用の推定レンジです。銀行アプリの公式定価ではなく、機能数、勘定系・API接続、認証、テスト、移行、24時間運用、災害対策をどこまで含むかで変わります。見積を比較するときは、総額だけでなく前提条件と除外項目をそろえます。

限定MVPは1,500万〜3,000万円、開発期間は6〜9か月が一つの目安です。残高・明細、ログイン、通知、生体認証、既存API連携を中心とし、送金や口座開設を後段に分ける想定です。標準的な銀行アプリは3,000万〜8,000万円、9〜15か月程度で、iOS・Android、振込・振替、管理画面、認証強化、複数API、総合テストを含めます。

口座開設・eKYC、送金・決済、ローン、不正検知、FIDOやJPKI、監視、災害対策まで含む本格的なモバイルバンキングは8,000万〜1億5,000万円超、12〜24か月程度が目安です。API基盤や勘定系・情報系まで刷新する場合は1億5,000万円から数億円以上、18〜36か月以上になる可能性があります。これらは一般的なアプリ開発費を金融案件の要件へ置き換えた推定であり、入札価格や各社の公式価格ではありません（出典: 本稿の予算策定用推定、2026年）。

見積の内訳は、要件定義・基本設計、UX・画面設計、アプリ実装、API・バックエンド、外部サービス接続、テスト、移行、リリース準備、PM、セキュリティ、運用設計に分けてもらいます。要件定義と基本設計が全体の10〜20％、実装が30〜40％、テスト・移行・リリース準備が20〜30％、PM・セキュリティ・予備費が残りという分解を一つの検討材料にします。配分は案件ごとに変わるため、比率だけで良し悪しを判断しません。

人月単価の参考として、一般的な2026年のスマートフォン開発では、iOS・Androidエンジニアが月80万〜130万円、バックエンドが月70万〜120万円、PMが月80万〜140万円程度とされます。ただし金融案件では、業務設計、セキュリティ、性能試験、監査対応、障害訓練の専門人材が必要となるため、一般アプリの単価をそのまま適用しません。安い見積ほど、専門工程が除外されていないかを確認します。

初期費用が低くても、月額利用料、クラウド、監視・SOC、脆弱性診断、OS更新、問い合わせ、制度改正、機能追加、外部認証、バックアップ、DR、教育が高ければ、長期的な負担は増えます。保守・改善費は初期開発費の年10〜20％程度を暫定予算とし、クラウド費用や24時間運用費は別建てで見積もります。金融向けの冗長化・監査・DRを含むクラウド費は、一般アプリの月額目安より上振れする前提です。

5年TCOの比較表には、初期開発、移行、ライセンス、月額・年額、保守、追加開発、監視、診断、障害対応、契約終了時の移行費を入れます。さらに、窓口業務の削減時間や紙・郵送の削減、不正被害の抑制など、費用だけでは表せない効果もKPIと金額の両面で試算すると、経営会議で説明しやすくなります。

委託先選定と見積比較のポイント

委託先は、知名度や見積総額だけで決めません。自行と似た規模・勘定系・取引量の導入実績、認証と不正対策の経験、API接続の方式、24時間運用の体制、障害時の責任分界、5年TCO、内製化支援、契約終了時の出口を同じ質問票で比較します。提案資料の華やかさより、失敗条件と前提を正直に開示しているかを評価します。

実績確認では、「金融機関への導入実績があります」という説明だけで終わらせません。どの業務を担当したのか、勘定系との接続は参照だけか更新までか、口座開設や送金の受入を経験したか、何行・何ユーザーで運用しているか、障害や制度改正にどう対応したかを聞きます。可能であれば、RFPへ回答したチームと本番運用チームが同じかも確認します。

候補には、大規模な共同利用型・勘定系連携に強いSI、クラウド型チャネルを持つ事業者、総合アプリや本人確認に強い会社、ホワイトレーベルを提供する会社、組込型金融の基盤事業者など、異なる方式を含めます。方式が違う候補を同じ条件で比較するには、必須要件と任意要件を分け、標準機能、設定変更、個別開発、外部サービス費を別々に回答してもらいます。

見積書を受け取ったら、まず対象範囲、ユーザー数、取引量、対応OS、画面数、API接続数、テスト端末、データ移行量、稼働時間を確認します。次に、要件定義、アプリ、バックエンド、外部サービス、セキュリティ、性能、移行、教育、保守、予備費を横並びにします。含まれない作業を「別途」とだけ書く見積は、実行前に作業内容と単価・上限を確認します。

評価点は、費用だけでなく、要件適合、金融・業務知識、セキュリティ、運用体制、品質管理、納期の実現性、変更への柔軟性、内製化、TCOで構成します。価格が最安でも、脆弱性診断や障害訓練がなく、リリース後に追加費用が膨らむなら、総合的には安くありません。最終候補には、同じ前提で再見積を依頼し、差額の理由を説明してもらいます。

発注後も、銀行側にプロダクトオーナー、業務責任者、システム責任者、セキュリティ責任者、法務・コンプライアンス、店舗・コールセンターの代表を置きます。ベンダーが画面やコードを作っても、どの取引をいつ提供するか、顧客へどう説明するか、障害時に誰が判断するかは金融機関の責任です。週次の課題管理と月次の経営報告を行い、未決事項を持ち越さない運営にします。

発注先の選定に迷う場合は、最初から本開発の提案を求めず、現行調査とRFP作成を支援する短期フェーズを設ける方法があります。複数社から独立した意見を得ることで、自社に必要な機能と不要なカスタマイズを分けやすくなります。その後の開発を同じ会社へ依頼する場合も、調査成果物の所有権と競争性を確保しておくと、見積比較が形骸化しません。

よくある質問

最後に、モバイルバンキングシステムの発注・外注で特に質問されやすい点を整理します。費用や期間は機能だけでなく、既存システムの状態、認証・セキュリティ、移行と運用の範囲で変わるため、自行の前提に置き換えて判断します。

限定MVPなら1,500万〜3,000万円、標準的な銀行アプリなら3,000万〜8,000万円、本格導入なら8,000万〜1億5,000万円超が2026年時点の予算策定用の推定レンジです。勘定系や共通API基盤まで刷新する場合は、1億5,000万円から数億円以上になる可能性があります。公開定価ではないため、RFPで機能、接続数、認証、テスト、移行、運用の前提をそろえて再見積します。

外注できますが、既存勘定系に安全なAPIがあり、残高・明細・振込・口座開設など必要な業務を連携できることが前提です。APIが不足する場合は、BFFやAPIゲートウェイの新設、データ連携、認証統合、障害時の照合までが追加スコープになります。最初に現行調査を行い、「アプリだけで済む範囲」と「バックエンド改修が必要な範囲」を分けて見積を依頼します。

基準をRFP、設計審査、テスト、運用訓練、監査のチェック項目へ分解して使います。たとえば認証、権限、ログ、脆弱性管理、委託先管理、バックアップ、復旧、インシデント報告について、要求事項、設計上の対応、確認する証跡、担当主体を表にします。FISCの安全対策基準は法令そのものではありませんが、金融システムの開発・導入・運用で必要な安全対策を確認する実務上の基準として活用できます。

自行と近い規模の金融機関で、同じ勘定系・認証・取引量の導入実績があるかを確認します。そのうえで、提案チームと運用チーム、障害時の体制、FIDO・eKYC・JPKIの経験、SLA、再委託管理、5年TCO、データとソースコードの帰属を比較します。最安値ではなく、見積の前提と除外項目を説明でき、契約終了時の移行まで提案できる会社を選ぶことが大切です。

まとめ

モバイルバンキングシステムの発注・外注は、アプリの制作会社を探すだけでは完了しません。まず、アプリ刷新、APIチャネル新設、勘定系を含む基盤刷新のどこまでを対象にするかを決め、ホワイトレーベル・SaaS、共同利用、スクラッチの特徴を自社の変更速度と運用能力に照らして比較します。

RFPでは機能だけでなく、認証、冪等性、監査ログ、性能、可用性、復旧、移行、再委託、障害報告、運用教育を数値と成果物で示します。契約は準委任・請負・SaaSを工程に応じて使い分け、SLA、責任分界、データ・ソースコードの帰属、契約終了時の出口を明記します。見積は初期費用だけでなく、保守、クラウド、監視、診断、制度改正、追加開発を含む5年TCOで比較します。

最初から全機能を作るのではなく、残高照会や通知などのMVPから始め、送金、口座開設、eKYC、ローンを段階的に追加する方法もあります。ただし、将来の認証、API、監査、監視、データ移行を見据えたアーキテクチャにしておくことが必要です。金融機関側に意思決定できる体制を置き、委託先と同じKPIを追いながら、利用者の安全と業務成果を確認して進めます。

▼全体ガイドの記事
・モバイルバンキングシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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