勘定系では決済を止められないため、PoC（概念実証）やプロトタイプ、モックアップの開発は一般的な開発と進め方が異なります。
基本は、新技術を本体で直接試さず、API基盤やBaaSを介した周辺で安全に検証することです。そのうえで、非機能要件を段階的に確かめ、本番へ進みます。
▼全体ガイドの記事
・勘定系システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
勘定系におけるPoC・検証の特殊な位置づけ
一般的な開発では、PoCやプロトタイプを作って試し、成果を広げていきます。ただし勘定系は前提が異なり、決済制度の根幹を守るため、検証にもリスクを封じ込める設計が求められます。勘定系の本体を直接試せないのは、決済制度の存続に関わるため、高可用性と高信頼性が何より優先されるからです。そこで金融機関は、本体を守りながら、その周辺で検証する考え方を取っています。
「絶対に止まらない」勘定系で新技術を直接試せない理由
勘定系は決済制度の存続に関わるため、高可用性と高信頼性が何より求められます。障害が起きれば、預金の引き出しや振込が止まり、金融機関の信用を損ねます。
- 障害の波及：決済制度全体に広がるシステミック・リスクへつながるおそれがあります。
- 本体での試行：新技術やアーキテクチャを本体で直接検証・実装すると、大きなリスクを伴います。
- 本番での試行：Webサービスでは本番の一部でカナリアリリースを使える場合もあるものの、勘定系では許容されにくいです。
「試したいが、本体では試せない」という制約があるため、勘定系の検証は特殊になります。金融機関は、この制約のなかで安全に検証する方法を工夫してきました。
「守り」と「攻め」を分離して検証するアプローチ
このジレンマを解くため、金融機関は「守り」と「攻め」の領域を明確に分けています。両者は連携基盤を介して接続します。
- 守りの領域：預金・為替・融資を担う本体で、極力手を加えない部分。
- 攻めの領域：新しいデジタルサービスや技術を本体から切り離して検証します。
攻めの領域で検証中に問題が起きても、遮断して本体へ影響が及ばないようにできます。PoCやプロトタイプの成果が固まった後に、本体との連携や本番反映へ慎重に進みます。
「本体を守りながら、その周辺で試す」分離設計が、ミッションクリティカルな領域で新技術を扱う基本戦略です。
API基盤・BaaSを介した新技術の検証アプローチ
「守り」と「攻め」を分ける仕組みとして、金融機関はAPI基盤やBaaS（Banking as a Service）を使います。これらは本体に触れずに機能を安全に外部へ開放し、新技術やフィンテックサービスとの連携を検証する橋渡し役です。
オンラインデータ連携基盤・API基盤による安全な検証
レガシー化した本体には手を加えず、周辺にオンラインデータ連携基盤やAPI基盤を構築する方法が広く採用されています。これらは、外部サービスや新技術との接続に使われます。
- 接続する対象：スマートフォンアプリ、データ分析サービス、フィンテック企業のサービスなど。
- 確かめる内容：データ連携が想定どおりか、性能やセキュリティに問題がないか。
PoCでは、連携基盤が「試すための安全な窓口」として働きます。問題がないと確認できてから、本格展開へ進みます。
本体をブラックボックスのまま保ち、その外側に検証と拡張の層を設ける設計は、老朽化した基幹システムを抱える金融機関にも現実的です。
BaaS・オープンAPIによる組込型金融の検証環境
BaaSは、勘定系の機能をAPIとして外部に開放する仕組みです。例として、NTTデータの「Open Service Architecture」や「BeSTA-BaaS」があります。
- 利用する事業者：非金融業のプレイヤーやスタートアップ企業。
- 試せるサービス：口座開設や決済などの銀行機能を組み込んだ、自社ブランドのデジタルバンク。
APIを介した組込型金融基盤は、短期間でアイデアを試作・検証するサンドボックスの役割を果たします。そのため、勘定系をゼロから作らなくても、サービスのプロトタイプを組み立てられます。
検証は自行内にとどまらず、外部の事業者と新サービスを試す形にも広がっています。BaaSは、その土台となる中核的な環境です。
クラウド移行判断のための段階的検証
勘定系のクラウド移行では、本体を一度に移さず、リスクの低い領域から検証して知見を積み上げます。クラウドが求められる水準を満たすかを段階的に見極める点で、PoCに相当する進め方です。
周辺システムから本体へ進む4ステップの検証（MEJAR）
横浜銀行など5行の共同利用システム「MEJAR」では、勘定系本体のクラウド化に向け、4段階で基盤を検証・移行する計画です。
- 第1ステップは、人事総務系やイントラネットなど、勘定系との結びつきが弱い非結合システムです。
- 第2ステップは、各種業務系システムなどの疎結合システムです。
- 第3ステップは、CRM（顧客管理）、SFA、融資審査システム、統合データベースなどの密結合システムです。
- 第4ステップは、オープン基盤化の成功を前提として、次期更改で勘定系本体のクラウド化を検討する段階です。
まず第1ステップでクラウド運用のノウハウを蓄積し、勘定系との結合度を上げながら適用範囲を広げていきます。第4ステップは、2030年度予定の次期更改で検討する計画です。
リスクの低い外側から内側へ、実績を確認しながら進める設計は、勘定系のクラウド移行を検証する進め方の一例です。
段階的に非機能要件を確認する意義
段階的な検証では、移行する量を少しずつ増やしながら、各段階で金融機関に必要な非機能要件を確認します。要件には、セキュリティ、24時間365日の無停止運用、障害時の迅速な復旧体制があります。
- 次段階へ進む条件：セキュリティや可用性がクラウド環境でも確保できること。
- 懸念が見つかった場合：その段階で止まり、対策を講じるか計画を見直すこと。
非結合システムで運用に慣れ、要件を満たすことを確かめてから、勘定系に近い密結合システムへ進みます。こうした段階ごとの確認が、リスク管理の要になります。
本番投入前に不確実性を減らすというPoCの目的に照らすと、この段階的検証は勘定系におけるPoCといえます。
検証で担保すべき非機能要件の重さ
勘定系の検証では、機能が動くかだけでなく、金融機関に必要な非機能要件を満たすかを確かめることが中心になります。そのため、一般的な開発より検証工程の負担が大きくなります。
テスト工程30%超と外部接続検証・移行リハーサル
一般的な開発では、テスト工程は全体の15%から30%程度です。一方、勘定系では品質確保のため、プロジェクト全体の30%以上の工数をテストに投じます。
- 外部接続検証：全銀システム、CAFIS、日銀ネットとの相互接続を確かめる。
- 移行リハーサル：現行の勘定元帳から新システムへ、誤差ゼロでのデータ移行。
社会インフラ級の接続先は、あらゆるパターンで連携を確かめます。移行では一円の狂いも許されないため、本番と同じ条件で通しのリハーサルを繰り返します。
PoCで機能面の目処が立っても、外部接続検証と移行リハーサルを終えなければ本番には進めません。非機能検証には、膨大な時間がかかります。
金融特有の複雑処理とセキュリティ標準の検証
非機能要件の検証では、金融分野ならではの二つの観点を重視します。勘定系は多額の資金と膨大な個人情報を扱うため、最新のセキュリティ標準への準拠が必要です。
- セキュリティ：検証段階で、最新標準の要件を満たしているか。
- 処理の正確性：利息計算や日付をまたぐ処理が、あらゆる条件下で正しく動くこと。
うるう年、月末、年度替わりなどの境界条件でも、計算が狂わないかを確認します。新しい構成で金融特有の処理を正確かつ安全に扱えるかが、検証の範囲になります。
技術的に動くことと、金融システムとして正しく安全に動くことは別です。両方を検証で担保しないと、本番移行で想定外の問題が起こり得ます。
PoC倒れ・本番移行の壁とその乗り越え方
新しいアーキテクチャや技術を検証できても、本番環境で稼働させる本番移行には大きな壁があります。PoCが成功しても勘定系の移行でつまずく場合があるため、その要因を理解しておくことが大切です。
事務品質（現場の習熟度）の壁
第一の壁は事務品質、つまり現場の習熟度です。日本銀行の調査報告も、システムが正常に動いていても、銀行員が新しい事務処理に習熟しているとは限らないと指摘しています。
- 見落としやすい場面：月末の繁忙期やイレギュラーな取引など、異例時の事務処理。
- 移行前の準備：現場担当者を含めた訓練とリハーサル、習熟度の移行判断への組み込み。
異例時に新システムで正しく処理できるかは、動作確認とは別の課題です。習熟度を測る指標がないまま移行日を迎え、稼働直後に現場が混乱するケースもあります。
操作訓練では異例時の対応まで確認し、現場が習熟したかどうかを判断基準に明記します。また、技術と同じように、人と業務の準備も検証することが成否を分けます。
コンティンジェンシープラン・切り戻し計画の壁
第二の壁は、コンティンジェンシープラン（緊急事態対応計画）の不足です。日本銀行の調査は、テストの想定や網羅性を十分に確かめないまま移行日を迎えるリスクを指摘しています。
- 切り戻しの設計：旧システムへ戻す方法と、外部接続先との整合の検討。
- 実行可能性の確認：判断基準、手順、タイムリミットを明文化して、リハーサルで試す。
フォールバックプランがない、または外部接続先との整合が取れていない場合、移行当日の障害に対応できない恐れがあります。移行時間が限られるなかで停止が長引けば、社会的影響も大きくなります。
そのため、検証段階から失敗時の安全な戻し方を設計し、切り戻しを実際に行えるかを確かめます。成功のシナリオだけでなく、撤退のシナリオも含めることが移行の鍵です。
まとめ
勘定系のPoC・プロトタイプ・モックアップは、止められない特性から、一般的な開発とは位置づけが異なります。
本体を直接試さず、「攻め」の周辺でオンラインデータ連携基盤やAPI基盤、BaaSを介して安全に検証し、「守り」の本体を保つ設計が基本です。
クラウド移行はMEJARの4ステップのように、リスクの低い周辺から本体へ進め、各段階で非機能要件を確かめます。
テストには全体の30%以上の工数をかけ、外部接続、誤差ゼロの移行、金融特有の処理とセキュリティを確かめます。技術の検証が済んでも、現場の習熟と切り戻し計画という壁を越えてから、本番へ移行します。
失敗時の撤退まで含む検証設計が、勘定系の新技術導入を成功に導きます。
▼全体ガイドの記事
・勘定系システム開発の完全ガイド
▼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を創業。