勘定系は、預金・為替・融資を扱う金融機関の基幹システムです。刷新では、技術者、コスト、自行の独自性を見て方式を選び、フルスクラッチ・オーダーメイドは限られた場合に選ばれます。
経営層やシステム部門が方式を判断する際の材料として、共同化への移行の背景、費用とリスク、製品、次世代の勘定系を取り上げます。
▼全体ガイドの記事
・勘定系システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
フルスクラッチからパッケージ・共同化へ移行した背景
勘定系が各行のオーダーメイドから共通基盤の共同利用へ移った背景には、技術、コスト、規制の環境変化があります。
地方銀行の約8割が共同化を選んでおり、変化の大きさを示しています。
技術者の枯渇（2007年問題）とフルスクラッチ維持の困難
共同化へ移る動きでは、技術者の枯渇が最大の要因です。自行で開発・維持し続けるには、古い言語と自行独自の業務ロジックを知る人材が必要です。
- 古い言語の担い手：COBOLやPL/Iの技術者が高齢化し、数が減っています。
- 自行での維持：専門人材を継続して確保するのが難しくなっています。
- 共同化の選択：複数行で技術者を共有でき、人材面で合理的です。
「2007年問題」に象徴される状況のなかで、自行独自の複雑な業務ロジックも理解する人材を、長期にわたって確保する必要があります。
人材確保が年々難しくなるなか、専門ベンダーのパッケージや、複数行で技術者を共有する共同化へ移る動きが進みました。
技術者が減ると、自行に最適化したシステムも維持できなくなり、フルスクラッチから離れる動きが強まります。
開発・保守コストの負担と法規制対応の負荷
単独で開発する場合は固定費がかさみ、外部環境の変化への対応負荷も無視できません。制度改修の負担がこれに重なり、共同化への移行を後押ししました。
- 開発・保守費：複雑な金融ロジックを各行で開発・維持すると、固定費が膨らみます。
- 制度対応：法令や決済制度の変更に伴い、改修の負担が重くなります。
- 共同対応：共通の改修をまとめて進め、各行の負担を抑えられます。
複数行でシステムを使い、ベンダーに使用料を支払う形なら、開発・保守コストを分け合えます。たとえば、個人情報保護法や日本版SOX法への対応、新しい決済制度への接続などが、勘定系の改修の具体例です。改修は年々増えています。
各行が改修を自前で続ける負担は大きく、共同化センターやパッケージベンダーなら業界共通の対応を行えます。
技術者不足、費用、規制対応の負荷が重なり、共通基盤の利用が広がりました。
フルスクラッチとパッケージ・共同化のコスト・リスク比較
両方式は、費用だけでなくリスクの性質と自行の裁量も異なります。方式を選ぶには、それぞれの特徴を押さえておく必要があります。
フルスクラッチのコスト規模とリスク
フルスクラッチは業務に適合する一方、巨額の費用と長期の開発リスクを伴います。
- 開発費：勘定系は、費用の次元が一般的な大規模業務システムとは異なります。
- 開発期間：数年から10年単位に及び、仕様変更が遅延につながる場合があります。
- 検証工数：金融特有の処理や外部接続の検証に工数がかかります。
大規模業務システムの開発費は、一般に数千万円から1億円以上とされています。
みずほ銀行の全面刷新「MINORI」には4,000億円超が投じられ、金額だけでなく開発リスクの性質も特殊です。
開発中に法制度や経営環境が変わると、仕様変更が致命的な遅延を招くリスクがあります。これに加えて、金融特有の複雑な処理を作り込むため、外部システムとの接続検証にも莫大な工数が必要です。
パッケージ・共同化のFit to Standardとロックインリスク
標準機能に業務を合わせれば費用を抑えやすい一方、自行の裁量や企画・開発力に影響します。
- 標準機能の活用：独自開発を減らし、期間とコストを抑えます。
- 柔軟性の低下：標準機能から外れる独自要件を実現しにくくなります。
- ベンダー依存：自社のシステム企画・開発力が低下するおそれがあります。
パッケージや共同化は、自行の業務を標準機能に合わせる「Fit to Standard」が基本です。業務を標準に寄せてカスタマイズを減らすことで、開発期間とコストを大幅に抑えられます。
業務のやり方をシステムに合わせる必要があるため、仕様変更の柔軟性も下がります。また、企画・開発をベンダーや共同化センターに委ね続けると、ベンダーロックインにつながる可能性があります。
コスト削減と引き換えに、自行の裁量や技術力を失う可能性がある点は、押さえておく必要があります。
主要な勘定系パッケージと共同化システムの全体像
主要ベンダーは特色のあるパッケージを展開し、多くの金融機関が共同で利用しています。選定の前に、製品と共同化システムの全体像を押さえておく必要があります。
主要ベンダーの勘定系パッケージ・フレームワーク
日本の金融機関で稼働する勘定系パッケージやフレームワークは多岐にわたり、各社の対応基盤や採用先には特色があります。
- NTTデータ：「BeSTA」「PITON」などがあります。
- BIPROGY・日本IBM：「BankVision」「BANKSTAR」「Chance」「NEFSS」が挙げられます。
- 日立・富士通・NEC：「NEXTBASE」「OpenStage」「PROBANK」「BankingWeb21」を提供しています。
勘定系アプリケーションは複数のプラットフォームに対応しており、移行支援用のミドルウェアを使えば、Linuxなどのオープン基盤へ移れます。
BeSTAは、横浜銀行など5行が参加する「MEJAR」のほか、「地銀共同センター」「STELLA CUBE」でも広く採用されています。
BIPROGY（旧日本ユニシス）の「BankVision」は、百五銀行などが採用した世界初のWindowsベースのフルバンキングシステムです。また、無店舗型ネット銀行向けの「BANKSTAR」は、セブン銀行やauじぶん銀行などに提供されています。
日本IBMは、三菱UFJ銀行主導の地銀共同化システム「Chance」と、Javaベースの「NEFSS」を手がけています。NEFSSは、住信SBIネット銀行などで稼働しています。
日立製作所は「NEXTBASE」を展開するほか、静岡銀行のシステムをベースにしたLinux稼働の次世代勘定系「OpenStage」も手がけています。富士通は「PROBANK」、NECは「BankingWeb21」を提供しており、金融機関は規模や方針に合わせて選びます。
「共同利用型パッケージ」としての地銀共同化システム
共同化では、複数行が共通基盤を使い、コストと改修負荷を分担します。
- 共同利用：共通パッケージを複数の金融機関で運用する形です。
- 負担の分担：単独では難しいシステムや法改正への対応も、共同で進められます。
- 参加時の調整：独自要件は反映されにくくなります。
MEJAR、地銀共同センター、Chanceなどは、複数の地方銀行が参加し、共通パッケージを土台にしている例です。
パッケージ導入と共同化が融合した形態は「共同利用型パッケージ」ともいえます。フルスクラッチが減るなかで、勘定系開発の受け皿として定着しています。
参加行は費用を持ち寄って高度なシステムを利用でき、法改正への対応も分担できます。一方で、参加行の業務プロセスを標準化する調整が必要になります。
参加先の選定は、業務の進め方や他行との協調も含めて考える、経営レベルの意思決定です。
クラウドネイティブな次世代勘定系の登場
従来のフルスクラッチやパッケージに加えて、パブリッククラウドでの稼働を前提に設計した次世代勘定系が登場しています。クラウドの柔軟性とスケーラビリティを生かし、勘定系開発の新たな潮流を形づくっています。
AWS・Google Cloud・Azure上の次世代勘定系の事例
大手クラウド3社のそれぞれで、次世代勘定系の稼働事例があります。
- AWS：「次世代バンキングシステム」が、福島銀行と島根銀行で稼働しています。
- Google Cloud：「MAINRI」「AiTHER」などの稼働例があります。
- Microsoft Azure：「BankVision on Azure」の稼働先は北國銀行です。
その開発は、SBI地方創生バンキングシステムとフューチャーアーキテクトがゼロから共同で担いました。設計では、フルオープンAPIとマイクロサービスを採用しています。
SBI新生銀行も、このシステムを使って刷新する予定です。
「MAINRI」はアクセンチュアが開発し、みんなの銀行が採用しました。この導入は、国内初のフルクラウド勘定系として行われたものです。
新規参入のデジタルバンクや、大規模な刷新を目指す銀行も、クラウド前提の次世代勘定系を採用しています。
マイクロサービス・フルオープンAPIという新しい設計思想
次世代勘定系は、外部サービスとの連携を前提に設計します。
- 機能の分割：独立したサービスとして構成し、個別の改修や拡張を進めます。
- API連携：外部サービスとつなぎ、新しいビジネスモデルに展開できます。
- 共通基盤の活用：クラウドや共通部品を使う、中間的な開発形態です。
従来のメインフレーム勘定系は、巨大な一枚岩（モノリシック）構造で、内部を一体的に作り込んでいました。次世代勘定系はマイクロサービスを採用し、機能を小さな独立サービスの集合体として構成します。
そのため、一部の機能だけを改修・拡張でき、変化への対応を速められます。フルオープンAPIにより、フィンテックや非金融事業者との連携も容易になり、組込型金融にも広げられます。
ゼロから作る点ではフルスクラッチに近いものの、実際にはクラウド基盤やパッケージ的な共通部品も使います。つまり、完全な自前開発とも既製品の導入とも違うスタイルです。
新設のデジタルバンクでもAPI連携を前提としたクラウドパッケージの採用が強まり、勘定系開発の選択肢は多様化しています。
フルスクラッチ・オーダーメイドが選ばれる稀なケース
多くの中小金融機関やネット銀行は、パッケージやクラウド基盤を共同で利用します。一方で、自社主導の開発が選ばれる場合もあり、その条件を知ることは自行の方針を考えるうえで役立ちます。
ここでのフルスクラッチには、それに近い大規模な自社専用開発も含めて考えます。
規模が巨大でパッケージに収まらないメガバンク
メガバンクは事業規模が大きく、地方銀行向けのパッケージには収まりきりません。
- 取引量・口座数：膨大な規模への対応が必要です。
- 複雑な業務：地銀向けパッケージでは能力が足りない場合があります。
- 開発体力：巨額の費用とリスクを引き受けられることが前提です。
三菱UFJ、三井住友、みずほなどは、1980年代から続く第三次オンラインシステムを基に、独自の拡張を続けています。
合併時には、一方の行のシステムへ寄せる「片寄せ統合」を行う方法もあります。
みずほ銀行の「MINORI」のように、数千億円をかけて実質的にフルスクラッチで新規開発するケースもあります。規模の経済による共同化の利点が当てはまりにくく、そのため自前で作り込む事情があります。
新しい金融ビジネスモデルで競争優位を持たせたい場合
業務ロジック自体を競争力にする場合は、自社主導の開発が選択肢に上がります。
- 独自モデル：標準パッケージでは実現できない仕組みが必要です。
- 差別化：他行と共通のパッケージでは実現しにくい場合があります。
- 中間的な方式：共通基盤に独自性を加える選択肢も広がっています。
既存の金融機関とはまったく異なる金融ビジネスモデルや、特殊なデジタルバンクを一から設計する場合が該当します。
近年は、新設のデジタルバンクでも、API連携を前提とするクラウドパッケージや次世代勘定系基盤の採用が強まっています。
純粋なフルスクラッチが選ばれる場面は狭まりつつあります。そのため、自前で作る範囲と共通基盤に乗せる範囲の配分が、これからの中心的な論点になります。
まとめ
勘定系は、フルスクラッチ中心からパッケージ・共同化中心へ移りました。地方銀行の約8割が共同化を選ぶ背景には、COBOL技術者の枯渇（2007年問題）、開発・維持の固定費、法規制対応の負荷があります。
フルスクラッチは、みずほ銀行のMINORIに象徴される巨額の費用と長期のリスクを伴います。
パッケージ・共同化は、Fit to Standardでコストを抑える一方、柔軟性の低下やベンダーロックインのリスクがあります。
BeSTA/PITON、BankVision、Chance、OpenStageなどの共同利用に加え、AWS・GCP・Azureの次世代勘定系も広がっています。マイクロサービスやフルオープンAPIを備えた方式も登場しています。
フルスクラッチは、メガバンクや独自モデルを目指す場合などに限られます。自前で開発する範囲と共通基盤を使う範囲の設計が、勘定系開発の鍵です。
本記事が、勘定系システムの開発方式を見極める際の一助となれば幸いです。
▼全体ガイドの記事
・勘定系システム開発の完全ガイド
▼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を創業。