勘定系システムとは？三層構造と情報系との違い・オープン化の判断を解説

勘定系システムとは、金融機関が預金・為替・融資といった「勘定」を1件ずつ確定させ、その残高を正として保持するシステムです。銀行の基幹系のうち最も内側に位置し、外側にチャネル系と情報系が接続します。この記事では、勘定系の守備範囲、三層構造と責任分界点、基幹システムや財務会計システムとの違い、オープン勘定系・クラウドへ移った実装の変遷、共同利用型と自行専用の費用構造、そしてどんな条件なら刷新に踏み切りどんな条件なら見送るべきかまでを、公表されている事実にもとづいて整理します。

まとめ｜勘定系システムの守備範囲とオープン化を決める判断材料

勘定系が引き受けるのは、預金元帳の更新、内国為替・外国為替の授受、融資の実行と回収という、金額が動いて元帳が書き換わる処理です。ATMやインターネットバンキングは取引を受け付ける窓口にすぎず、残高を確定させるのは常に勘定系の側。履歴の分析や帳票の出力は情報系の担当で、勘定系に持ち込むと処理時間の要件が噛み合いません。

実装方式は、メインフレーム上の自行専用から、オープン系サーバへ移した「オープン勘定系」、さらにパブリッククラウド上で動かす形へと広がりました。北國銀行が2021年5月にAzure上でフルバンキングシステムを稼働させ、福島銀行が2024年7月にAWSで地銀初の全面稼働、ソニー銀行は2025年5月に勘定系全体の移行を終えています。もはや技術的な可否の議論ではありません。

立場を明確にします。刷新の目的が「運用費を下げたい」だけの銀行は、いま動くべきではありません。オープン化そのものはコストを下げず、移行後の運用体制を決めていない案件は並行稼働が長引いて総額が膨らみます。逆に、保守要員が定年で抜ける時期が見えている、制度改正への対応が数か月単位で順番待ちになっている——どちらかに当てはまるなら猶予は残っていません。共同利用型か自行専用かの分岐も、商品設計そのもので差別化する方針がない限り、共同利用型を既定に考えるほうが現実的です。

勘定系システムの定義と預金・為替・融資を担う守備範囲の全体像

まず、勘定系という言葉が何を指すのかを固めます。定義が曖昧なままだと、後述する情報系やチャネル系との切り分けが崩れます。

預金元帳を握る勘定系の中核機能と1件ごとに求められる整合性水準

勘定系の中核は、預金の残高と取引履歴を保持する元帳ファイル（原帳）です。ここに書かれた数字が、その口座の残高としての正になります。窓口端末の表示も、ATMのレシートの印字も、元をたどればこの値です。

この一点が、勘定系に他システムと違う要件を課します。1件の振込は「出金側の減算」と「入金側の加算」が必ず対で成立しなければならず、途中で落ちて片方だけが残る状態を許しません。可用性の目標も業務システム一般とは桁が違い、停止が数分続けば決済が止まって報道される種類のシステムです。

為替・融資・外国為替まで広がる勘定系の業務範囲と対外接続の位置

狭義の勘定系は預金勘定元帳の処理を指しますが、実際のパッケージが抱える範囲はもっと広く取られます。内国為替（他行宛ての振込）、融資の実行・返済・利息計算、外国為替、日銀ネットや全国銀行データ通信システム（全銀システム）との接続制御まで含むのが一般的な構成です。

対外接続を守備範囲に数える理由は、送金電文の生成と元帳の更新が同じ取引の裏表だからです。他行宛ての振込では、自行の元帳から引き落とし、全銀システムへ電文を送り、相手行の元帳へ着金する——この一連が途切れないよう制御する必要があります。後述する2023年の障害が示したとおり、接続部分は勘定系本体と同じ重さで設計すべき箇所です。

勘定系・情報系・チャネル系による三層構造と各層の責任分界点の整理

銀行の基幹系は勘定系だけで成り立つわけではありません。役割の異なる3つの層が組み合わさっており、この分け方が分かると設計の話が通じます。

チャネル系が受け付け勘定系が確定させる取引フローの通り道と時間差

チャネル系は、顧客や行員が触れる入口の層です。ATM、店舗の窓口端末、インターネットバンキング、スマートフォンアプリ、コールセンターの端末がここに入ります。

この層は取引を受け付けて画面を組み立てますが、残高そのものを持ちません。ATMで1万円を引き出すとき、機械が行うのは「引き出し要求を勘定系へ渡し、承認が返れば現金を排出する」ことだけです。「チャネル側でいったん残高を減らし、後で勘定系と同期する」構造を持ち込むと、通信断のたびに実残高と表示残高がずれます。チャネル系が持ってよいのは、表示用のキャッシュと再送のための記録まで。

情報系が引き受ける履歴分析と帳票出力という後続処理の守備範囲

情報系は、勘定系が確定させたデータを受け取って分析・帳票・報告に使う層です。過去数年分の取引履歴の蓄積、支店別の実績集計、規制対応の各種報告、顧客への提案材料の抽出などを担当します。

両者を分ける実務上の理由は、要求される応答時間が違うためです。勘定系はミリ秒単位の応答と厳密な整合性を求められる一方、情報系は一晩かかる集計でも構いません。同じ基盤に載せると、重い集計クエリが元帳の更新をブロックする事故が起きます。夜間バッチでデータを引き渡す設計が長く使われてきたのは、この住み分けの結果です。

三層の分界点を曖昧にしたときに起きる二重計上と突合作業の増加

分界点の設計を誤ると、実害は運用の現場に出ます。よくあるのが、チャネル系に金額計算のロジックを持たせるパターン。手数料の計算をアプリ側と勘定系側の双方に実装すると、料率改定のたびに両方を直すことになり、片方を直し忘れた期間の取引が突合作業として積み上がります。

情報系側にも似た罠があります。集計値を勘定系へ書き戻す設計にすると、集計の失敗が元帳へ波及する経路ができてしまう。データの流れは勘定系から情報系への一方向に限り、逆流させないのが原則です。分界点を決めるときは「誰が正を持つか」を1箇所に定め、それ以外の層は複製にすぎないと仕様書に明文化してください。この一文の有無で、5年後の改修コストが変わります。

勘定系システムと基幹システム・財務会計システムの違いと境界線

最も混乱が起きるのが、この用語の重なりです。金融機関の人と事業会社の人が同じ「基幹」という言葉で別のものを指す場面は珍しくありません。

事業会社の基幹システムと金融機関の勘定系が指す対象の食い違い

製造業や小売業でいう基幹システムは、販売管理・生産管理・在庫管理・会計・人事など、事業の中核業務を支える仕組みの総称です。対象は「自社の業務」になります。

一方、金融機関の勘定系が扱うのは「顧客の資産」です。預金者の残高という他人の財産を記録する台帳を持つ点が決定的に違い、その差が監査の厳しさ、可用性の要求水準、改修時の検証量すべてに効いてきます。金融機関も人事や購買のシステムは持っていますが、それらは勘定系とは呼びません。勘定系という語は、顧客勘定を扱う中核部分に限定して使われます。

財務会計システムとの違いを分ける誰の勘定を記録するかという観点

もうひとつ紛れやすいのが会計との関係です。「勘定」という漢字から、仕訳や決算を扱う財務会計システムと同じものだと受け取られることがあります。実際には別物です。

切り分けの基準は「誰の勘定を記録しているか」に置くと迷いません。財務会計システムが記録するのは自社の財産と損益、つまり貸借対照表と損益計算書につながる自社の帳簿。勘定系が記録するのは顧客ごとの預金残高と取引で、銀行から見れば負債側の明細です。銀行にも自行の決算を締める会計システムがあり、勘定系から日次の集計が渡されます。提案依頼書で「勘定系」という語を使うときは、顧客勘定を指すのか自社会計を指すのかを最初の1行で定義しておくと、要件定義の手戻りを避けられます。

メインフレームからオープン勘定系とクラウドへ移った実装方式の変遷

実装の選択肢は40年かけて増えてきました。出発点は1960年代の第一次オンラインで、この世代の業務ロジックの多くはCOBOLで書かれ、いまもメインフレーム上で動いています。数十年分の制度改正が織り込まれた数百万行のコードには仕様書に残っていない振る舞いが含まれ、書き直すこと自体が新規開発より難しい。COBOLがオワコンと言われながら使われ続ける理由も、言語の優劣ではなくこの置き換えコストの非対称性にあります。

オープン勘定系の登場とBankVisionやBeSTAという実装の系譜

2000年代に入って登場したのが、メインフレームではなくオープン系のサーバとOS上で勘定系を動かす方式、いわゆるオープン勘定系です。国内で名前の知られた実装に、日本ユニシス（現BIPROGY）のBankVisionとNTTデータのBeSTAがあります。BeSTAは2004年1月にサービスを開始し、地銀共同センターをはじめとする共同利用の土台になりました。

NTTデータはその後、オープン化フレームワークとしてPITONを整え、公表資料によれば2024年1月4日に地銀5行の共同システムMEJARへの適用を完了しています。2026年をめどにオープン環境へ移る、しんきん共同センターの次期勘定系にも同じ技術を用いる方針が示されました。オープン勘定系はもはや例外的な挑戦ではなく、共同利用の標準的な基盤へ位置づけが変わっています。

パブリッククラウド上の勘定系が国内で稼働するまでの実績と時期

次の段階が、パブリッククラウド上で勘定系を動かす形です。公表されている国内の主な事例を時点とともに並べます。

北國銀行の事例はBIPROGYのBankVisionをAzure上に実装したもので、パブリッククラウド環境でフルバンキングシステムが稼働したのは国内初と公表されました。メガバンク側でも部分移行が進み、みずほ銀行は計表・日計・データマートの3機能とシステム開発環境の移行を2025年度中に順次始め、2026年度に完了させる想定と報じられています。全面移行と部分移行のどちらを選ぶかは、規模と既存資産の量で分かれるところです。

共同利用型と自行専用の勘定系を分ける費用構造とカスタマイズ余地

実装方式と並んで判断が要るのが、システムを他行と分け合うかどうか。ここは費用構造が根本から変わります。

地銀共同センターやMEJARに見る共同利用型の負担構造と制約

共同利用型は、複数の金融機関が同じ勘定系パッケージと運用基盤を分け合う形です。NTTデータの地銀共同センター、地銀5行が参加するMEJAR、信用金庫向けのしんきん共同センターが代表例にあたります。

費用面の利点は、開発費と運用費を参加行で分担できる点にあります。制度改正への対応も1回作れば全行に行き渡るため、法令対応の負担が軽くなる。その代わり、自行だけの都合で画面や商品仕様を変えることは原則できません。追加開発も他行への影響評価と参加行間の調整が入り、リードタイムは自行専用より長くなります。「安いが小回りは利かない」という性格をどこまで許容できるかが判断軸です。

自行専用の勘定系を選ぶ判断が成り立つ規模と差別化余地の見極め基準

では自行専用を選ぶ判断が成り立つのはどんな場合か。条件は絞られます。商品設計そのものを競争力の源泉にしていて、勘定系の仕様変更が経営戦略の実行速度に直結する場合。あるいは預金量と取引件数が大きく、共同利用の分担金より自前運用が単価で下回る規模に達している場合です。

この2つに当てはまらない銀行が自行専用を維持すると、制度改正のたびに個別対応の見積もりが積み上がります。迷ったら、直近3年の改修費のうち「他行と共通の制度対応」が占める割合を出してみてください。その比率が高いほど、自前で持つ理由は薄くなります。

オープン勘定系へ移行すべき条件と刷新をいま見送るべき銀行の要件

ここからは判断の話です。動向の紹介ではなく、どんな条件なら踏み切り、どんな条件なら待つべきかを示します。

移行を決めてよい条件は保守要員の枯渇と制度改正の待ち行列の長さ

移行に踏み切ってよい条件は2つあります。ひとつは、メインフレームと既存言語を扱える保守要員の退職時期が具体的に見えていること。ベンダー側の要員も同時に細るため、「あと何年で誰もいなくなるか」を年単位で言えるなら、計画を後ろ倒しにする余地はありません。

もうひとつは、制度改正や新商品への対応が順番待ちになっていることです。改修依頼から本番反映まで数か月かかり、その理由がテスト工数と影響調査なら、技術的負債が経営判断の速度を縛っている状態にあたります。方式選定では全面再構築だけでなく、マイグレーションとリプレイスの違いを踏まえて段階を刻む選択肢も検討に入れてください。

見送るべき場面は目的がコスト圧縮だけで移行後の運用が未定な状態

逆に、いま動くべきでない場面をはっきり書きます。刷新の目的が運用費の削減だけで、移行後の運用体制・改修プロセス・要員計画が決まっていない案件は、着手を見送るべきです。

理由は単純で、オープン化やクラウド移行そのものはコストを下げないからです。ハードウェアの保守費は減っても、冗長構成の設計、セキュリティ統制、監査対応、移行期間中の並行稼働費が新たに乗ります。削減効果が出るのは、運用の自動化や共同利用で人手の工数構造を変えたときであって、基盤を載せ替えただけでは総額はほぼ動きません。「他行が移行しているから」という理由しか出てこない段階なら、先に現行の改修費の内訳を分解するほうが投資対効果は高くなります。

典型的な失敗は、移行判定の基準を決めないまま新旧を並行稼働させ、両方の保守費を払い続ける形です。着手前に現行システムの停止日と移行判定の合格基準を数値で確定させておけば、この状態は避けられます。金融庁が2024年7月に公表した「基幹系システム・フロントランナー・サポートハブ」の最終報告でも、経営層の関与と目標の明確化が論点に挙げられました。技術ではなく決め方の問題だ、という認識から入るのが近道です。

勘定系の周辺で外注できる領域と内製に残すべき中核業務の線引き

発注側の実務に踏み込みます。勘定系まわりのどこを外部に任せ、どこを自分たちで持つかという線引きです。

API連携やチャネル系の開発など外部委託が成立する現実的な範囲

外部委託が成立しやすいのは、勘定系本体の外側です。オープンAPIを介した外部サービスとの接続、スマートフォンアプリや法人向けポータルといったチャネル系の開発、情報系・データ基盤の構築、RPAによる後方事務の省力化あたりが該当します。

これらは元帳を直接更新せず、公開されたインターフェース越しにやり取りする構造にできるため、責任範囲を契約で切りやすい。前提は、そのインターフェース仕様が文書として存在することです。仕様が実装依存で口伝になっているなら、まず文書化から着手します。金融領域の連携開発や情報系の構築を外部に相談する段階であれば、金融システム開発の受託のように業務特有の統制要件を前提に設計できる相手を選ぶと、要件定義の往復が減ります。

勘定系本体の改修を外部へ丸ごと預けたときに生まれる責任の空白

一方、勘定系本体の業務ロジックを丸ごと外部に預ける形は避けるべきです。ここは判断を言い切ります。理由は、障害時の一次切り分けと、制度改正時の影響調査を自行でできなくなるためです。

元帳の構造と勘定処理の流れを説明できる行員がいない状態で障害が起きると、ベンダーの報告を検証できません。当局への説明責任は金融機関側に残るのに、事実関係を確かめる手段が手元にない——この空白が最も危険です。実装を任せるとしても、データモデルと業務フローを読み解ける要員は自行に残してください。

発注側が用意する体制と見積もり依頼の前に固めておく要件の粒度

見積もりを取る前に固めておきたいものは、そう多くありません。対象業務の範囲、既存システムとの接続点の一覧、想定データ量とピーク時の件数、稼働率と復旧目標の水準、監査・統制上の要求事項。この5点が欠けたまま複数社へ相見積もりを出すと、各社が異なる前提で積算するため金額を比較できません。体制面では業務部門とシステム部門の双方から意思決定できる人を1名ずつ立て、仕様の判断をその場で返せる形にしておくこと。判断待ちの滞留は、そのままスケジュール遅延と追加費用に変わります。

勘定系連携で起きた障害事例から読む接続部分の設計とテストの勘所

最後に、実際に起きた障害から設計上の教訓を引き出します。勘定系そのものより接続部分のほうが事故は起きやすい、という話です。

全銀システムの中継コンピュータ障害が示した更改作業に潜むリスク

2023年10月10日、全国銀行データ通信システムと各金融機関をつなぐ中継コンピュータ（RC）で不具合が発生し、10の金融機関で他行宛ての振込が処理できなくなりました。公表資料と報道によれば、原因はRC17シリーズからRC23シリーズへの更改作業にあります。

不具合が出たのは、仕向銀行が被仕向銀行へ支払う内国為替制度運営費を電文ごとに入力・チェックする機能でした。金融機関名を格納するインデックステーブルが破損して異常終了に至り、冗長化された2台がともに同じ不具合を抱えていたため切り替えても復旧しなかった。旧世代への切り戻しもできず、修正プログラムの作成にも手間取り、全面復旧まで丸2日を要しています。稼働50年を超える全銀システムで初めての規模の障害でした。

連携テストで再現すべき異常系と本番同等データを用意する考え方

この事例から引き出せる設計上の要点は3つあります。第一に、冗長構成は「同じ更改を同時に適用した2台」では冗長になりません。片系ずつ時間をずらして更改し、旧系を一定期間残す手順にしておけば、切り戻しの選択肢が残ります。

第二に、切り戻し手順は書類上の存在ではなく、実際に実行できる状態まで検証しておくこと。第三に、テストデータです。今回破損したのは金融機関名を保持する領域で、全金融機関分のデータが揃って初めて再現する種類の不具合でした。件数を絞ったテストでは表に出ません。連携部分の検証では本番同等の件数とバリエーションを用意し、更改直後のピーク時間帯を想定した負荷条件まで含めて実施してください。異常系の網羅に正常系の何倍もの工数がかかると見積もり段階で認めておくほうが、結果的に安く済みます。

よくある質問

勘定系システムをめぐって検索されることの多い疑問に、簡潔に答えます。

勘定系システムと基幹システムは同じ意味ですか？

同じではありません。基幹システムは事業の中核業務を支える仕組みの総称で、製造業なら生産管理や販売管理、小売なら在庫管理を指します。勘定系システムは金融機関の基幹系のうち、顧客の預金・為替・融資という勘定を記録する中核部分に限った呼び方です。基幹系は勘定系・情報系・チャネル系の三層からなり、勘定系はその最も内側にあたります。

勘定系システムと会計システムの違いは何ですか？

記録する対象が違います。会計システム（財務会計システム）が扱うのは自社の財産と損益で、仕訳を積み上げて貸借対照表や損益計算書を作ります。勘定系システムが扱うのは顧客ごとの預金残高と取引明細で、銀行から見れば預金者への負債にあたるもの。銀行は両方を持ち、勘定系から日次で集計されたデータが会計システムへ渡って自行の決算につながります。

オープン勘定系とメインフレームの勘定系はどちらが安いですか？

基盤を載せ替えるだけでは、総額はほとんど変わりません。ハードウェア保守費は下がる一方で、冗長構成の設計、セキュリティ統制、監査対応、移行期間の並行稼働費が新たに発生します。費用が実際に下がるのは、共同利用型に参加して制度改正対応を分担する、運用を自動化して人手の工数構造を変えるといった手を同時に打った場合です。

保険基幹システムも勘定系システムと呼びますか？

保険会社では一般に「保険基幹システム」と呼び、勘定系という語はあまり使いません。契約の成立から保全・収納・保険金支払までを扱う点で銀行の勘定系と同じ位置づけですが、要件は異なります。銀行が1件ごとの即時処理を重視するのに対し、保険は数十年続く契約の状態を保持し、商品改定のたびに新旧の契約条件を並存させる設計が必要になります。

勘定系システムの開発を外部に委託することはできますか？

領域によります。オープンAPIによる外部連携、スマートフォンアプリなどのチャネル系、情報系やデータ基盤の構築は、インターフェース越しに責任範囲を切りやすく、外部委託が成立しやすい領域です。一方、勘定系本体の業務ロジックを丸ごと預ける形は勧められません。障害時の一次切り分けと制度改正時の影響調査を自行でできなくなり、当局への説明責任だけが残ります。実装を委託する場合も、データモデルと業務フローを読める要員は自行に残してください。

関連記事

• 金融・公共・流通系のシステム開発とは？業界特化の要件と外注先の選び方：業界特有の要件と発注先の選び方を整理しています。
• AI・ブロックチェーンなど金融システムの最新トレンド：勘定系の外側で進む技術動向を扱っています。
• レガシーシステムとは何か、その意味・定義や歴史的背景：旧世代の資産が残り続ける構造を業界横断で解説しています。
• オンプレミス型とクラウド型の基幹システム導入形態の違いと選定ポイント：導入形態の比較軸をまとめています。