この参考モデルの位置づけ

メインフレームのフルリプレイスは、規模と業務影響が桁違いに大きく、経営会議での意思決定が数年単位で滞ることも珍しくありません。一方、保守撤退の通告や COBOL 要員の枯渇は待ってくれず、時間だけが削られていきます。この状況で現実的な初手として使えるのが、業務の中核 (勘定系・契約系) はメインフレームに残したまま、周辺系 (帳票、分析、顧客照会、社内問い合わせ) だけを先に新基盤へ寄せる段階移行です。本記事は、この「周辺系リプレイス」の設計を、AI 駆動開発のクリエイティブスタジオが参考実装モデルとして整理したものです。

段階移行そのものの汎用手順は システムリプレイスの進め方完全ガイド と メインフレーム リプレイスの進め方と費用相場 にまとめています。本記事はその中の「初手」フェーズに絞って、技術選定・データ同期・切り戻し設計の具体的な構成に踏み込みます。

周辺系を先に切り出す 3 つの理由

周辺系を優先する理由は 3 つあります。

1 つ目は、周辺系はメインフレームからの「参照」のみで完結するため、新基盤側にデータを写して読ませるだけで動くという点です。書き戻しが要らないので、双方向同期の複雑さを避けられます。

2 つ目は、周辺系こそが業務側が日々触る画面で、体感の改善効果が大きいという点です。帳票の出力時間が数分から数秒に縮む、社内問い合わせの顧客情報照会が 5 画面遷移から 1 画面で済む、といった改善が業務側に届き、社内の刷新プロジェクトへの理解を得やすくなります。

3 つ目は、周辺系の刷新経験が、その後の中核系リプレイスに直接効くという点です。データ同期の技法、Feature Flag の運用、AI 駆動の読み解きプロセスといった要素が、周辺系で磨かれた形で中核系フェーズに引き継げます。

参考アーキテクチャの全体像

構成は次の 4 層で組み立てます。

  1. メインフレーム層 (既存): 勘定系・契約系がそのまま稼働。VSAM / DB2 for z/OS。
  2. CDC (Change Data Capture) 層: Kafka Connect の JDBC ソースコネクタ、または IBM InfoSphere Data Replication で、メインフレーム側の変更をリアルタイム抽出。片方向 (メインフレーム → 新基盤) のみ。
  3. 新基盤データ層: PostgreSQL または Amazon Aurora で、周辺系が読むためのマート DB を構築。CDC 経由でメインフレーム側の変更を反映。
  4. 新基盤アプリ層: Next.js + Hono + Prisma で、帳票・分析・顧客照会の Web アプリを構築。認証は SSO で既存の Active Directory・Azure AD に接続。

双方向同期は避ける。周辺系だけを寄せる段階では、新基盤からメインフレームへの書き戻しは発生させません。書き戻しは中核系リプレイスの後半フェーズで初めて設計します。この制約を守ることで、初手フェーズの複雑度を抑えられます。

AI 駆動での COBOL 読み解き 3 ステップ

周辺系リプレイスの前提として、対象範囲の COBOL コードから業務ルールとデータの流れを復元します。この工程は Claude Code などの AI コーディングツールを使うと、従来 3〜6 ヶ月かかっていた棚卸しが 1〜2 ヶ月に圧縮できます。

ステップ 1: 対象範囲を CICS トランザクション単位に切る

周辺系に該当する CICS トランザクションを洗い出し、それぞれのプログラム、コピー句、参照テーブル、外部連携をマトリクスにまとめます。「帳票」「分析」「顧客照会」といった業務単位で分類しておくと、次のステップの読み解きが構造化されます。

ステップ 2: プログラム単位で AI に要約させる

各 CICS トランザクションの COBOL プログラム (数百〜数千ステップ) を Claude Code に読ませ、次の 4 点を要約させます。

  1. 主たる業務ロジック (どんな入力を受けて、どんな出力を返すか)
  2. 参照するデータ (VSAM / DB2 のどのファイル / テーブル)
  3. 暗黙の業務ルール (コメントに残っていない条件分岐、外部連携の癖)
  4. 例外処理 (エラー時のリカバリ、業務側への通知経路)

全体を一度に読ませると精度が落ちるため、プログラム単位に分割するのが精度の鍵です。

ステップ 3: テストとして書き起こす

AI が出力するのは仮説です。重要な業務ルールは、新基盤側で自動テストとして書き起こし、旧側と新側で同じ入力に対して同じ出力になることを検証します。書き溜まったテストは、新基盤の生きた仕様書として残り、後任への引き継ぎ資料にもなります。AI の出力をどう検証に組み込むかは AI 駆動 TDD の考え方を応用します。

CDC の実装ポイントとよくある落とし穴

新基盤側にメインフレームのデータをリアルタイムで反映するには、CDC の設計が肝です。よくある落とし穴を 3 つ紹介します。

1 つ目は文字コード変換の抜けです。EBCDIC から UTF-8 への変換で、独自の外字や旧字体、半角カナの扱いで文字化けが発生します。ETL パイプラインの最初のステージに、文字コード変換の unit test を厚めに書いておきます。

2 つ目は COMP-3 パック 10 進数の符号解釈です。COBOL の COMP-3 形式は末尾ニブルに符号を持つため、単純にバイト列を数値カラムへ入れると、負号が反転したり、桁あふれが発生します。Kafka Connect のコンバーターに、パック 10 進数の解釈を明示的に指定するトランスフォームを噛ませます。

3 つ目は遅延許容度の設計です。周辺系の要件で「新旧のデータは常に一致していなければならない」を厳格に取ると、CDC の遅延が業務クレームの発生源になります。実際には「帳票は 1 分遅延まで許容」「顧客照会は 30 秒遅延まで許容」といった業務側の許容度を握り、そこに合わせて Kafka の設定を最適化するのが現実解です。

Feature Flag による切り戻し設計

周辺系の新基盤を段階リリースする際、業務側が問題を感じたら即座に旧側 (メインフレーム経由の画面) に戻せる仕組みを設計します。ここが、フルリプレイスと段階移行を分ける最大のポイントです。

参考実装:

  • Feature Flag ライブラリ (LaunchDarkly、Unleash、自作のシンプル実装) で「新画面を使う」「旧画面を使う」を出し分ける
  • 業務側自身が UI から切り替えられるトグルを画面右上に配置し、「新しい画面で見る」「旧画面に戻す」を選べる
  • Flag の状態はサーバー側で保持し、次回ログイン時にも維持する
  • 業務クレーム発生時は、対象部署単位で Flag を全員 OFF にする管理画面を業務側に用意

この業務側操作型 Feature Flag の設計は システム刷新・リプレイスのサービス の差別化要素にもなっており、業務停止時間を最小化する要になります。

参考期間と費用レンジ

周辺系リプレイスだけで、参考レンジは次のとおりです。

  • 期間 — 6〜10 ヶ月 (現状分析 1〜2 ヶ月、設計 1〜2 ヶ月、実装 3〜5 ヶ月、段階リリース 1〜2 ヶ月)
  • 費用 — 6,000 万〜1.5 億円 (税抜)

対象範囲を「帳票のみ」「分析のみ」に絞ればさらに小さいレンジで済みますし、周辺系全体を一気に手掛ければ上限に近づきます。中核系のフルリプレイス (5,000 万〜3 億円以上) と比べれば、初手として着手可能な現実的なレンジです。

次のフェーズへのつなぎ方

周辺系リプレイスが完了したら、次のフェーズ (中核系) では、この初手で得たものを応用します。

  • CDC のパイプラインは、中核系リプレイス時のデータ移行にそのまま流用できる
  • AI 駆動の COBOL 読み解きプロセスは、中核系の複雑なロジックに対しても同じ手順で通用する
  • Feature Flag の運用は、中核系の切り替えでも同じ設計を使い回せる

初手フェーズの目的は、この「型」を組織に定着させることです。中核系リプレイスは経営判断のハードルが高くても、周辺系の成功実績があれば、次のフェーズの意思決定がはるかに軽くなります。

メインフレーム リプレイスのご相談

「メインフレームを一気にリプレイスする予算と時間はないが、保守撤退の圧は迫っている」「周辺系だけでも先に手を打ちたいが、どこから始めるか判断できない」といった状況こそ、AI 駆動開発で読み解きと初手設計を加速できる領域です。まずは システム刷新・リプレイスのサービス内容 をご覧いただき、お問い合わせ からお気軽にご相談ください。