1億5,000万ステップの巨大システムに潜む、構造的なギャップ
構造面での見直し対象を絞り込むと、チャネル・ビジネスフロント層はUI／UXのトレンドに合わせて自然に更新され続ける一方、連携基盤とバックエンドには構造的な課題が集中する。連携基盤の層は、構築当時（2000年代前半）に主流だったサービス指向アーキテクチャ（SOA）を軸としており、SOAP連携についてはJavaの標準機能（JDK）から外れる懸念が技術的な課題として浮上した。結果として、外部ライブラリーとしてAPIが提供され続けていることが確認でき、この懸念自体は解消できているという。
バックエンドの勘定系コア機能は、第3次オンライン以来、営業店端末やATM向けに最適化されたチャネル専用プログラムに、ダイレクトバンキングやアプリ、外部事業者対応といった機能をアドオンで継ぎ足す形で成長してきた。鈴木氏はこの規模感を、プログラムのステップ数で具体的に示した。内製主体で開発している約160システムだけで、総数は約1億5,000万ステップ。中でも最大なのは外為業務の約1,300万ステップで、SWIFTネットの規約やマネーロンダリング対策のルールを取り込むたびに肥大化してきた結果だという。国内の勘定系ホストも約570万ステップに達しており、一般的な1システムあたりの規模感（約50万〜300万ステップ）と比べると、いずれも突出して巨大なシステムであることがわかる。
さらに開発面では、採用言語であるPL/Iの人口低下と有識者不足、TSOなどレガシーな開発環境の利用が、若手開発者の参入や人材の高齢化という懸念につながっていた。鈴木氏はこれらを「メインフレーム継続性」「複雑・肥大化（アーキテクチャ）」「人材・開発スタイル（開発）」という3つの本質的課題に整理した。
すべてを刷新せず、改修頻度30％の領域だけをコンテナ基盤へ移す
メインフレーム継続性については、鈴木氏はIBM本社を訪問して直接確認したロードマップを踏まえ、悲観的な見方を明確に否定した。IBMは常に最新モデルから3世代先までの投資・研究開発を継続しており、2022年発表のz16にはオンチップでAI推論を行うTelumプロセッサーが、2025年発表のz17ではその複数コア版とSpyreアクセラレーターカードが搭載され、大規模言語モデル（LLM）の実行まで視野に入っている。「メインフレームは単に残す対象ではなく、信頼性・高可用性・高性能が求められる領域では、これからも使い続けるプラットフォームだ」と鈴木氏は位置づけ、論点は「残すか捨てるか」ではなく「どの機能をどのプラットフォームに再配置するか」だと語った。
その具体策が、性能・可用性に優れたメインフレームと、柔軟性・拡張性に優れたコンテナ基盤を組み合わせるハイブリッドアーキテクチャだ。既存プログラムをすべて捨てて作り直すのはリスクとコストの両面で非現実的だとして、過去15年分の業務アプリケーションの改修頻度を分析。改修頻度の高い機能プログラムだけをリアーキテクト・リファクタリングしてコンテナ基盤へリフトアップする方針を取った。分析の結果、改修頻度の高いプログラムは全体の約30％に収まっており、「第3次オンラインの設計思想がしっかりしていたからこそ、改修すべき範囲は限定的だった」と鈴木氏は振り返る。この方針に基づく分散・コンテナ基盤への移行は、すでに昨年8月から勘定系フロント機能の一部で本番稼働を開始しているという。
