【完全ガイド】金融機関 勘定系・営業店端末 レガシーシステム刷新：STELLA-CUBE・FNS・MARK・Banks・OpenCanvas からの移行戦略

地方銀行・信金信組・第二地方銀行・農協系の勘定系・営業店端末システムは、業界共同センター方式（NTT データ STELLA-CUBE / FNS、日立 MARK / Banks、富士通 OpenCanvas）が圧倒的シェアを占める独自市場。これらは 1990〜2000 年代に構築され、コア部分は 30 年近い運用実績を持つ。本稿は、金融機関の勘定系・営業店端末の刷新で、現場で実際に発生する論点を整理する。

1. 国内勘定系システムの市場構造

国内の地方銀行・信金信組の勘定系は、大手 SI ベンダの共同利用センター方式が市場の 9 割を占める。複数の金融機関が同じシステムを利用し、開発・運用コストを分担する仕組み。

2. 営業店端末システムの構成

勘定系の上に乗る営業店端末システムは、フロント業務（窓口・営業店）の業務システム。

• 窓口業務：預金入出金、振込、両替、税公金収納。
• 融資業務：与信判定、契約書作成、保証会社連携。
• 営業店外回り：タブレットでの営業活動、顧客訪問記録。
• 本部承認フロー：高額取引・例外取引の本部承認。
• 顧客情報管理：CIF（Customer Information File）の一元管理。

3. レガシー勘定系の刷新が進まない理由

金融機関の勘定系刷新は 5〜10 年単位の大規模プロジェクトになる。みずほ銀行の事例（複数行統合の困難）、地方銀行の合併に伴う統合の苦労が示すように、刷新の難易度は他業界と桁違い。

• 業務影響の大きさ：勘定系停止は経済機能の停止と同義。失敗の影響が国レベル。
• 規制対応の累積：30 年の運用で積み重なった金融規制への対応。新システムでも同等以上の対応が必須。
• カスタマイズの蓄積：金融機関ごとの独自業務（特殊な与信判定、地域固有の取引慣習）が、既存システムに深く組み込まれている。
• 人材の希少性：勘定系開発を担える SE が業界全体で枯渇。COBOL・PL/I の経験者の高齢化。
• 金融庁・日銀・所管庁との折衝：システム変更には監督官庁への報告・承認が必須。

4. 共同センターの再編と次世代勘定系の動向

2025〜2030 年代に向けて、国内勘定系の再編が本格化している。

• 共同センターの統合：複数の共同センターが、コスト効率化のために統合する動き。NTT データの主要センター統合、日立・富士通の連携強化。
• クラウドネイティブ化：従来のメインフレーム + ホスト言語から、AWS / Azure / Google Cloud + 現代的なアーキテクチャへ。
• マイクロサービス化：モノリシックな勘定系を、業務単位のマイクロサービスに分解する設計。
• API ファースト：オープン API による FinTech 連携の前提。
• BankAPI（電子決済等代行業者向け API）：法律で義務化された API の本格運用。

5. 規制対応の継続的な負担

金融機関のシステム選定では、以下の規制対応が前提条件。

• FISC 安全対策基準：金融機関標準。
• 金融庁監督指針：業態別の監督指針（銀行・証券・保険）。
• 反社チェック：暴排条例・反社会勢力との取引排除。
• マネロン・テロ資金対策：FATF 勧告・犯罪収益移転防止法・KYC。
• 個人情報保護法 金融分野ガイドライン：厳格な管理。
• BCM（事業継続管理）・BCP：金融機能停止の経済影響の大きさを反映。
• SOX 対応：上場金融機関の財務報告内部統制。

6. デジタルバンキング・FinTech 対応

勘定系刷新と並行して、デジタルバンキング・FinTech 対応のシステム整備が進む。

• インターネットバンキング：個人・法人向け Web/アプリでのオンライン取引。
• API 連携：BankAPI、参照系・更新系 API 経由での FinTech 事業者との連携。
• QR 決済：J-Coin Pay、はまPay、ご当地ペイなど、地域密着型の QR 決済。
• サブスクリプション収納：継続的な口座振替の最適化。
• CRM・MA：顧客データ分析、提案の自動化。
• 営業店端末のタブレット化：窓口業務の効率化、ペーパーレス化。

7. 移行プロジェクトの進め方

1. Phase 1（6〜12 ヶ月）：現状業務分析、刷新方針合意。経営層・IT 部門・現場・監督官庁との合意形成。
2. Phase 2（12〜24 ヶ月）：周辺系システム（CRM・MA・インターネットバンキング）の先行刷新。
3. Phase 3（24〜48 ヶ月）：勘定系・営業店端末の段階的刷新。並行運用 6〜12 ヶ月。
4. Phase 4（48 ヶ月以降）：完全カットオーバー、安定化。継続的な機能追加。

8. 勘定系刷新の判断：4つの問いで共同センター継続／別センター移行／独自構築を決める

地方銀行・信金信組の勘定系は、NTT データ STELLA-CUBE・日立 MARK/Banks・富士通 OpenCanvas・BIPROGY BankVision・しんきんシステム等の共同センターが市場の9割を占める。共同センターを継続するか、別センターへ移行するか、独自構築を目指すかは、自行の戦略・経営体力・差別化方針で決まる。

問1：差別化したい業務領域はどこか

• 勘定系本体の差別化：共同センターでは難しい。独自構築または共同センター＋差別化レイヤーのハイブリッド構成が必要。投資は数百億円規模。
• 顧客接点の差別化（インターネットバンキング・モバイル・営業店端末）：共同センターを継続しつつ、顧客接点層を独自で構築するパターンが現実解。差別化効果と投資のバランス。
• 融資・営業の高度化：CRM・MA・与信判断 AI 等の周辺系強化。勘定系本体は維持。
• 差別化を目指さない：共同センターの標準機能の範囲で完結。コスト効率重視。

問2：経営体力と投資余力

• 独自勘定系の構築余力あり（年間IT投資100億円超）：独自開発の選択肢あり。みずほ銀行の事例から学びつつ、リスク管理を厳格化。
• 中堅地方銀行（年間IT投資30〜100億円）：共同センター＋差別化レイヤーが現実解。共同センターの選定で長期投資効率を高める。
• 信金信組（年間IT投資10〜30億円）：共同センター標準利用が中心。しんきんシステム・SCAW 等の特化センターを活用。
• 小規模信組（年間IT投資10億円未満）：共同センターへの集約・統合参加で経営効率を確保。

問3：共同センター再編・統合への対応

• 現行センターの統合計画あり：統合先センターでの自行業務の継続性を確認。データ移行・運用体制の変化への対応。
• 現行センターを継続利用：センター側の長期投資計画・新機能ロードマップを確認。継続利用のリスク評価。
• 別センターへの移行：移行プロジェクトの工期・コスト・リスク。3〜5年規模の長期プロジェクトとして組成。

問4：クラウド対応の方針

• フルクラウド移行：FISC・ISMAP 対応のクラウド（AWS Financial Services・Azure 等）への移行。共同センター側のクラウド対応スケジュールに依存。
• ハイブリッド構成：勘定系本体はオンプレ・共同センター、周辺系はクラウドの組合せ。段階的な移行。
• オンプレ継続：当面のクラウド移行は見送り。共同センターの方針に沿う。

9. AML/CFT 体制構築：FATF 対日相互審査後の実務対応

2021年の FATF 対日相互審査の結果を受け、金融庁はマネー・ローンダリング及びテロ資金供与対策に関するガイドラインの運用を継続的に強化している。地方銀行・信金信組も、リスクベース・アプローチに基づく体制構築・KPI 管理が経営上の重要テーマ。

取引時確認（KYC）の高度化

• eKYC の活用：マイナンバーカード公的個人認証、運転免許証＋顔写真照合、口座照合等の組合せ。来店不要のオンライン口座開設の標準化。
• 継続的顧客管理（CDD）：取引パターン変化・職業変更等のモニタリング。リスク再評価の継続実施。
• 実質的支配者の確認：法人取引での実質的支配者（25%超議決権保有自然人）の確認。記録の継続管理。
• PEPs 対応：外国 PEPs との取引のリスク評価。継続モニタリング。
• 住所変更・職業変更等への対応：顧客情報の定期更新・変更検知。

取引モニタリングと疑わしい取引の届出

• モニタリングシステムの選定：日々の取引データを継続分析。シナリオベース＋AI 検知の組合せ。
• 検知シナリオの最適化：自行の取引特性に応じたシナリオ調整。誤検知（False Positive）率の継続改善。
• 調査・分析の業務フロー：検知 → 一次分析 → 追加調査 → 届出判断 → 経営層承認 → 届出のフロー管理。
• 業界共有データの活用：JAFIC・銀行協会等の情報共有データベース。最新の脅威情報への対応。

AML/CFT 体制の KPI 管理

制裁対象者・反社チェックの運用

• リストの最新化：OFAC・国連制裁・外為法のリストを継続最新化。
• 取引前スクリーニング：新規取引・新規口座開設時の自動スクリーニング。
• 継続的モニタリング：既存顧客への継続スクリーニング。新規追加対象への対応。
• 取引拒絶・契約解除：制裁対象者・反社確認時の手順の社内周知。

10. オープンバンキング API 戦略：参照系／更新系／BaaS の優先順位

銀行 API は2017年の銀行法改正で制度化されて以降、地方銀行・信金信組も対応が進む。FinTech 事業者との連携、新規収益モデル構築、顧客体験の高度化のため、API 戦略の優先順位設定が経営テーマ。

API 戦略の3段階

• Stage 1：参照系 API の本格対応：口座残高・取引履歴の照会 API。家計簿アプリ・会計ソフト等の FinTech 事業者との接続。基本的な対応として全行が取り組み中。
• Stage 2：更新系 API での新規収益：振込・支払指図 API。決済サービス事業者との連携。API 利用料の収益化。
• Stage 3：BaaS（Banking as a Service）展開：銀行機能の組込提供。非金融事業者への決済・送金・口座開設機能の提供。エンベデッドファイナンスへの展開。

BankAPI 公式仕様への対応

• 全銀協公式仕様への準拠：業界標準への準拠で、FinTech 事業者の接続障壁を低減。
• OAuth 2.0 認証の実装：API 利用時の認証・認可。電子決済等代行業者・利用者・銀行の3者認証。
• API ハブの活用：複数 FinTech との接続を一元化する API ハブの活用。直接接続コストの削減。
• サンドボックス環境の提供：FinTech 事業者向けの接続テスト環境。エコシステム構築の支援。

全銀システム次世代化への対応

• 全銀システム 2027年問題：現行システムの更改計画。加盟金融機関側のシステム対応スケジュール。
• ことら送金：個人間少額送金プラットフォーム。地方銀行・信金信組の参加判断。
• 振込手数料の動向：他行宛振込手数料の引下げ競争。低コスト送金手段との競争。
• 24時間365日決済：休日・夜間も含めた即時送金。顧客利便性向上。

API 収益化のビジネスモデル

• API 利用料：FinTech 事業者からの API 利用料徴収。参照系は低単価・大量、更新系は高単価。
• BaaS パートナーシップ：非金融事業者との収益分配契約。EC・モバイルアプリへの組込提供。
• エンベデッドファイナンス：パートナのサービスに組込まれた金融機能の提供。新規顧客接点の獲得。
• API マーケットプレイス：複数 FinTech・金融機関の API を集約する基盤への参加。

11. クラウド移行の段階アプローチ：FISC・ISMAP 対応とリスク管理

金融機関のクラウド利用は、金融庁ガイドラインの改訂と FISC 安全対策基準の運用により段階的に拡大。コスト効率・新サービス展開の柔軟性と、規制対応・リスク管理のバランスが、クラウド戦略の核心。

クラウド移行の3段階

• Stage 1：周辺系のクラウド化：CRM・MA・社内システム等の周辺系から開始。Salesforce Financial Services Cloud 等の業界向け SaaS の活用。
• Stage 2：顧客接点のクラウドネイティブ化：インターネットバンキング・モバイルアプリのクラウドネイティブ実装。マイクロサービス化・コンテナ化。
• Stage 3：勘定系のクラウド対応：勘定系本体のクラウド対応。共同センター側のクラウド化スケジュールに依存。

クラウド事業者の選定軸

• 金融機関向けクラウドサービス：AWS Financial Services・Azure for Banking・GCP for Financial Services 等の業界向けサービス。
• 国内リージョン：個人情報・取引データの国内保管。海外アクセスの制限。
• 監査権の確保：金融庁・日銀の立入検査への対応。クラウド事業者との契約条項。
• サービス停止時の対応：障害・停止時の対応・補償の契約条項。
• データ可搬性：将来のクラウド事業者変更を想定した可搬性。

ゼロトラスト・サイバーセキュリティの並行整備

• ID・認証の強化：MFA・SSO・特権アカウント管理（PAM）。
• マイクロセグメンテーション：ネットワークの細分化・通信制御。
• エンドポイント保護：EDR/XDR による継続監視。
• ZTNA：VPN 代替の次世代リモートアクセス。
• SIEM/SOAR：セキュリティイベントの統合監視・自動対応。

サイバーレジリエンス強化

• ランサムウェア対策：バックアップの確保、定期復旧テスト、感染時の対応手順。
• BEC（ビジネスメール詐欺）対策：標的型攻撃メール訓練、メールセキュリティ強化。
• サプライチェーン攻撃対策：委託先・ベンダのセキュリティ評価・継続監視。
• CSIRT 体制：CSIRT の設置・運用、定期訓練。
• 業界連携：Financials ISAC Japan 等への参加。攻撃情報・対策の共有。

段階的なリスク管理体制の構築

金融機関のシステム刷新は、規模・経営戦略・規制対応・サイバーリスクの複合要因の中で、5〜10年スパンの戦略投資判断が必要。共同センターと独自構築の使い分け、AML/CFT 対応、API 戦略、クラウド移行の各領域での意思決定が、長期的な競争力と安定性を支える。