モダナイゼーション実行プレイブック

対象: PoC向け現状資料（料金CIS / 設備管理サブシステム） 作成日: 2026-06-16 ステータス: Phase 0 — 調査・戦略策定

目次

1. エグゼクティブサマリー

システム全体像・言語構成・現状分析の基本データは final-report.md セクション1-1を参照。

一文で言うと

VB6とCOBOLが9:3の比率で混在する約50万行規模のレガシーシステム。両者は直接結合しておらず Shell/BAT 経由の間接結合のみ。バージョン管理なし・共通モジュールが最大104コピー散在という構造的課題を抱えるが、仕様書カバレッジ63%と比較的ドキュメントが残存しており、段階的モダナイゼーションの条件は揃っている。

2. 現状調査の結果と所見

2.1 アーキテクチャの構造

アーキテクチャ全体像・VB6/COBOL分離の発見・主要バッチフローは final-report.md セクション1-1を参照。

2.2 サブシステム構成と結合度

サブシステム間共有テーブル（実業務データ）:

判定: 共有テーブル11件のうち、両側から書き込みが発生するのは KY110 の1件のみ。残り10件は片側書き込みまたは読み取りのみ。サブシステム間のデータ結合は想定より疎であり、独立した移行が十分可能。

2.3 共通モジュール（技術的負債の核心）

共通モジュール散在の全体像は final-report.md セクション4-1を参照。

ExeOdbc は 465行・28プロシージャ からなるデータアクセス層。46個のVB6プロジェクトが直接インクルードしている。Win32 ODBC API（SQLAllocEnv, SQLConnect, SQLExecDirect 等）を直接呼び出しており、モダンな ADO.NET / Entity Framework に相当する。

この1ファイルの移行が、モダナイゼーション全体の鍵を握る。

2.4 依存関係のホットスポット

上位プログラム（発信依存 Top 10）:

2.5 リーフプログラム（移行候補の母集団）

441本 / 596本（74%）のプログラムが他プログラムから直接呼ばれていない。

これは VB6 の各 .vbp が独立した .exe をビルドする構造と、COBOL バッチの性質を反映している。この441本は Strangler Fig パターンの「外側から刈り取る」対象として最適。

3. 5視点アセスメント — 機械的ファクトに基づく定量評価

原則: 本セクションは、ソースコード・設定ファイル・バイナリ・仕様書から 機械的に抽出したファクト のみを記載する。本番環境の実行ログ・ジョブ定義・DBスキーマ等は 現時点で未取得 であり、それらに依存する評価は「未取得」と明記した上で、データ取得後に更新する。

データ取得状況

3.1 視点1: データフロー（依存度）

取得状況: ソースコード内のSQL文を静的解析し、CRUD操作 1,332件を抽出した。ただし、本番DBのDDL（テーブル定義）は 未取得 のため、テーブルのカラム型・制約・インデックス情報は含まない。また、ファイル経由のデータフロー（DAT/TXT 169件）は未マッピングであり、プログラム間のデータ受け渡しの全体像は完全ではない。

CRUD操作の全体像

所見: SELECT が約半数を占め、UPDATE が 35%。INSERT/DELETE は比較的少なく、多くのプログラムが「読み取り + 更新」パターンであることを示す。これは段階移行において、読み取り側プログラムを先行移行できる構造。

ハブテーブル分析（依存集中度 Top 10）

最重要テーブル: RN920

• 54プログラムからアクセスされる最大のハブテーブル
• UPDATE 159件（全操作の64%）— ステータス更新が主用途
• VB6/COBOL 両方からアクセスされ、メッセージキュー的に機能
• 移行戦略: 最初に抽象化層（API）を設ける最優先候補

高リスクテーブル: KY110

• 料金CIS・設備管理両サブシステムから R/W/U/D の全操作が発生
• 11プログラムが同一テーブルにアクセス — データ整合性の確保が最重要

クロスサブシステム データフロー

判定: サブシステム間のデータ受け渡しはテーブル共有（2件: RN920, KY110）よりも、ファイル経由（DAT/TXT 169件） と BAT起動チェーン が中心。テーブル結合が疎であることはモダナイゼーション上の好材料。

3.2 視点2: 利用実態（アプリ実利用時間）

取得状況: 本視点で本来必要な 本番実行ログ・ジョブスケジューラ定義・アプリ実利用時間 は すべて未取得 である。現時点では、ソースコードのファイル種別（.bas/.cbl/.frm/.bat等）と仕様書の有無から 実行パターンの静的分類 のみを実施した。実行頻度・実利用時間・ユーザー操作ログに基づく評価は、データ取得後に本セクションを更新する。

実行パターン別プログラム分類（静的分類 — ソースファイル種別に基づく）

※「実行形態」列はファイル種別からの推定であり、本番ジョブ定義による確認は 未実施。

注目ポイント:

• GUIプログラムは10本のみ — ファイル拡張子(.frm)から判別。実際の利用頻度は 未取得
• VB.NETは6本のみ — VKN070B 1プロジェクトに集約。.NET移行の先行事例として活用可能
• 分類不能 231本 — ソースパスが不明（EXEのみ存在、または仕様書のみで紐づくプログラム）。本番環境調査で正体確認が必要

仕様書カバレッジ

判定: 63%のカバレッジは同規模のレガシーシステムとしては 比較的良好。ただし37%の仕様欠損プログラムに対しては、AI支援によるソース解析 + 業務担当者ヒアリングの併用が必要。

デッドコード候補（静的解析による暫定判定）

注意: 上記はソースコードの静的依存関係のみに基づく暫定判定である。本番ジョブスケジューラの実行ログが 未取得 のため、実際に稼働していないプログラムの確定はできていない。本番ログ取得後、デッドコードの最終判定と移行対象の絞り込みを行う。

BATオーケストレーション構造（ソースコードから抽出）

※ 実行頻度（日次/月次/随時）はジョブスケジューラ定義が 未取得 のため記載できていない。

本視点で今後取得が必要なデータ

本視点の完全な評価には以下が必須であり、現時点では いずれも未取得 である:

3.3 視点3: データ利用・参照分析（技術リスク）

取得状況: ソースコード内のODBC API呼出・DSN参照・TBDB.ini設定ファイルを静的解析し、ODBC接続構成を抽出した。ただし、各DSNの 実際の接続先サーバー/ポート情報 および テーブルのレコード数・データ量 は本番DB環境が 未取得 のため含まない。DSN名称からの用途推定は命名規則に基づく暫定的なものである。

ODBC インフラストラクチャ全体像

DSN 接続頻度（上位10 — ソースコード内の参照数）

所見: ソースコード・TBDB.ini から30の本番系DSN名を抽出した。TBFDB が最もソース内参照が多い（777件）。テスト系7 + 外部系5を含む計42のDSNが存在する。各DSNの実際の接続先サーバー・ポート情報は 本番ODBC設定が未取得のため不明。

仕様書フォーマット分析

判定: 約96%がExcel形式 — プログラムによる自動解析・仕様抽出が現実的。PDF 9件は手動確認が必要。

外部データファイル

3.4 視点4: 技術資産（技術リスク）

取得状況: ソースコードのファイル種別・行数、EXEバイナリのPEヘッダ解析、VBPファイルのバージョン情報から技術構成を抽出した。ただし、本番で稼働しているEXEとの SHA256照合は未実施（本番EXE未取得）のため、正本バージョンは未確定。COM/OCXコンポーネント依存の網羅的な抽出も未完了。

言語別コード量

所見: VB6系（.bas + .frm + .vbp）が 58%、COBOLが 40.7% で合計 98.7%。VB.NET/BAT/SQLは合わせて1.3%のみ。実質的に VB6 + COBOL の2言語システム。

ランタイム分析（144 EXE バイナリ解析）

最重要リスク: 140本のEXEが VB6 Runtime に依存。Microsoft の VB6 Runtime サポートは Windows 11 までの互換性保証 にとどまり、将来のOSで動作しなくなるリスクがある。

バージョン管理状況

バージョン重複詳細:

技術的負債指標

ODBC API / ラッパー依存度

3.5 視点5: システム分類（業務機能）

取得状況: プログラム名のプレフィックス規則と仕様書の feature_label メタデータから業務機能を 推定分類 した。ただし、業務担当者へのヒアリングや業務フロー図は 未取得 のため、分類の正確性は確認できていない。特に「その他 426本」の分類は、業務知識に基づく確認が必要である。

業務機能別プログラム分類

業務ラベル（feature_label）による詳細分類

仕様書の 97.3% (239/246件)、プログラムの 62.2% (371/596件) に業務ラベルが付与されている。

ユニーク業務ラベル数: プログラム 212種類 / 仕様書 252種類

クリティカルシステム（依存度 Top 10）

判定: EXEODBC（依存度 6,044）と VZY110（依存度 578）の2つが突出したハブ。これらを Phase 1 で API 化することが、全体移行の ゲートオープン条件。

統合候補（類似プログラムグループ）

94本の統合候補を集約することで、移行対象プログラム数を 約60本削減 できる可能性がある。

3.6 5視点 総合サマリー

3.7 Gap分析 — 完全評価に必要な追加データ

以下のデータが取得されることで、各視点の評価精度が大幅に向上する。

視点別 Gap 一覧

最優先取得データ（Phase 0 で必須）

[必須データ 優先度: 最高]

1. 本番ジョブスケジュール定義
   → 596本のうち実稼働本数を確定
   → 移行対象の最終決定

2. 本番DB DDL（全テーブル定義）
   → 645テーブルの完全な型定義
   → 移行先DBスキーマ設計の基盤

3. 本番EXE SHA256 照合
   → 144 EXE の正本バージョン確定
   → 9プログラムの複数バージョン問題の解決

4. 業務フロー図（As-Is）
   → 212業務ラベルの上位構造化
   → 移行ウェーブの最適順序決定

5. 本番実行ログ（直近3-6ヶ月）
   → デッドコード410本の精査
   → 実行頻度に基づくリスク評価

4. 追加調査が必要な情報

4.1 本番環境ログから得たい情報

4.2 本番環境から得たいシステム情報

4.3 お客様から得たい業務情報

4.4 ログ調査で特に注目すべきポイント

5. モダナイゼーション戦略

5.1 基本方針: Strangler Fig パターン

一括リプレースは 596本・約50万行のシステムではリスクが高すぎる。代わりに、依存グラフの外縁から段階的に新システムへ置換する Strangler Fig パターン を採用する。

5.2 フェーズ詳細

Phase 0: 正本確定・基盤整備（0〜3ヶ月）

目的: 「何を移行するか」を確定し、移行の前提条件を整える。

Phase 1: 共通基盤移行（3〜6ヶ月）

目的: 全プログラムの共通基盤を新アーキテクチャに置換し、段階移行の土台を作る。

[現状]                          [Phase 1 完了後]
VB6 App → ExeOdbc.bas → ODBC   VB6 App → API Client → REST API → 新DB層
                                              ↑ Strangler Facade
COBOL → EXEODBC-1.CBL → ODBC   COBOL → EXEODBC-1.CBL → ODBC (変更なし)

なぜ ExeOdbc から始めるか:

• 46プロジェクトが依存 → 1つ移行すれば全体に波及
• 465行・28プロシージャ → サイズが管理可能
• ODBC API 直接呼び出し → REST API への変換が明確
• 104コピーの解消で即座に保守性が向上

Phase 2: 機能別段階移行（6〜18ヶ月）

移行順序の原則: 依存グラフの「葉」から「幹」へ。

Phase 3: 完全移行・レガシー停止（18〜24ヶ月）

5.3 移行判定マトリクス（プログラムごとの戦略決定）

各プログラムを以下の基準で4つの戦略に振り分ける:

6. テクノロジースタック選定

6.1 推奨パターン比較

Pattern A: .NET + Azure（推奨 — VB6からの最短距離）

• Frontend: Blazor Server / WASM
• API: ASP.NET Core 10 Web API
• ORM: Entity Framework Core
• DB: Azure SQL Database
• Auth: Microsoft Entra ID
• Deploy: Azure App Service / AKS
• CI/CD: Azure DevOps

VB6→C# 自動変換ツール: GAPVelocity AI（旧 Mobilize.Net、最大99%自動変換）、gmStudio（BMW 100万行実績）

Pattern B: Java + Spring Boot + AWS

• Frontend: React + TypeScript
• API: Spring Boot 3.x (Java 21+)
• ORM: Spring Data JPA / Hibernate
• DB: Amazon RDS (PostgreSQL)
• Auth: AWS Cognito / Keycloak
• Deploy: ECS / EKS
• CI/CD: GitHub Actions

COBOL→Java 自動変換ツール: AWS Blu Age、IBM watsonx Code Assistant for Z

Pattern C: TypeScript + Next.js（BFFとして部分採用）

• Frontend: Next.js (React + TS)
• API: Next.js API Routes / tRPC
• ORM: Prisma
• DB: PostgreSQL
• Auth: NextAuth.js / Auth0
• Deploy: Vercel / AWS
• CI/CD: GitHub Actions

位置づけ: バックエンドは Pattern A or B として、フロントエンドのみ Next.js を採用する ハイブリッド構成 が現実的。

Pattern D: Python + FastAPI（分析・AI連携特化）

• Frontend: React + TypeScript
• API: FastAPI (Python 3.12+)
• ORM: SQLAlchemy / Alembic
• DB: PostgreSQL
• AI/ML: LangChain / PyTorch
• Deploy: AWS ECS / Lambda
• CI/CD: GitHub Actions

位置づけ: 分析サブシステム、AI支援機能、データパイプラインなど 特定用途のマイクロサービス として部分採用。

6.2 本案件への推奨

理由:

1. VB6 が全体の66%を占め、.NET への移行パスが最も確立されている
2. VB6→C# 自動変換ツール（GAPVelocity AI）で移行コスト大幅削減
3. COBOL 34% は Raincode .NET コンパイラで .NET 上で実行可能（段階移行中の互換性確保）
4. 既存の ODBC/SQL Server 資産と Azure SQL の親和性
5. 将来の AI/ML 連携は Python マイクロサービスで対応

代替案: COBOL が主体であれば Pattern B (Java + AWS Blu Age) を推奨。

7. 実行ステップ

7.1 全体タイムライン

7.2 Phase 0 の詳細手順

8. テスト戦略

8.1 テストの4段階

8.2 デグレード防止の核心: データ比較テスト

移行で最も重要なのは 「同じ入力に対して同じ出力が得られること」 の証明。

実装方法:

# 概念コード: データ比較テストフレームワーク
class ReconciliationTest:
    def run(self, test_case: TestCase):
        # 1. テストデータ投入
        self.setup_test_data(test_case.input_data)

        # 2. レガシーシステムで実行
        legacy_result = self.run_legacy(test_case)

        # 3. 新システムで実行
        modern_result = self.run_modern(test_case)

        # 4. 比較
        diff = self.compare(legacy_result, modern_result)

        # 5. 差分の分類
        for d in diff:
            if d.is_intentional:   # 意図的な改善（例: 精度向上）
                d.mark_as_accepted()
            elif d.is_cosmetic:    # 表示差異（例: 日付フォーマット）
                d.mark_as_known()
            else:                  # 予期しない差分 → 要修正
                d.mark_as_regression()

8.3 テストフェーズ別の詳細

単体テスト（新システム側）

機能テスト（E2E）

結合テスト

受入テスト

8.4 パラレルラン（並行稼働）戦略

Phase A: Shadow Mode (2-4週間)
  - レガシー = Source of Truth
  - 新システムは同じ入力を受けて処理するが、結果は保存しない
  - 出力を比較して差分を検出・修正

Phase B: Reverse Shadow (2-4週間)
  - 新システム = Source of Truth
  - レガシーは検証用に並行稼働
  - 差分があれば新システム側を修正

Phase C: New Mode
  - 新システムのみで稼働
  - レガシーは待機系として一定期間保持（ロールバック用）

Phase D: 完全停止
  - 十分な安定稼働を確認後、レガシーを停止

9. リスクと対策

9.1 技術リスク

9.2 プロジェクトリスク

9.3 ビジネスリスク

次のアクション

お客様の協力が必要

• [ ] 本番サーバーへのアクセス（正本EXE照合、ログ取得）
• [ ] DBスキーマのエクスポート
• [ ] 業務担当者へのヒアリング（起動条件、業務フロー）
• [ ] 移行優先度の確認（どのサブシステムから？）

判断が必要な事項

• [ ] テクノロジースタックの選定（推奨: Pattern A .NET + Azure）
• [ ] 移行スコープの確定（料金CISのみ先行 or 料金CIS+設備管理同時）
• [ ] デモの対象プログラムの確認
• [ ] 予算・体制・タイムラインの合意