AI駆動モダナイゼーション戦略

対象: 未来明るく電力 レガシーシステム（VB6 + COBOL、約50万行、596プログラム） 作成日: 2026-06-16 位置づけ: 04-playbook.md（従来型24ヶ月計画）のAI強化版 ステータス: 調査・戦略策定

目次

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

一文で言うと

AI（Claude Code + 自動変換ツール + マルチエージェント並列処理）の活用により、従来24ヶ月の移行計画を 10-12ヶ月に圧縮し、総コストを 40-55%削減 できる。ただしAIは「下書きマシン」であり「品質保証者」ではない。人間の判断・検証・ドメイン知識は引き続き不可欠。

数字の要約

AI活用でのみ可能になること（従来手法の高速化ではない新パターン）

1. 並列変換ストリーム: VB6/COBOLの完全分離構造を活かし、4-8のワークツリーで同時変換
2. ゴールデンマスターテスト自動生成: 手動では不経済だったカバレッジ水準を実現
3. 全596本の自動解析・スコアリング: 移行難易度の定量評価を数日で完了
4. 差分検証の自動分類: Shadow Test の出力差分をAIが自動トリアージ

AIで圧縮できないもの（正直な制約）

• Shadow Test / Reverse Shadow の実行期間（2-4週間 × 2）: 実データでの検証は時間が必要
• お客様ヒアリング・業務判断: 人間のスケジュールに依存
• ExeOdbc の設計判断: システム全体の基盤は自動変換ではなく人間が設計
• 文字コード変換（CP932→UTF-8）の網羅テスト: 地道な検証が必須

2. 従来手法 vs AI駆動の構造的な違い

パラダイムの転換

従来のプレイブック（04-playbook.md）は「1チームが逐次的にWaveを進める」前提。AI駆動では作業の構造自体が変わる。

従来: 逐次実行モデル（合計 18ヶ月）

AI駆動: 並列実行モデル（合計 6-7ヶ月） — 4ストリームを同時並行

役割分担の変化

要点: AIは「実行」を加速するが、「判断」は人間に残る。

3. ゴールデンマスターテスト戦略

3.1 概要

ゴールデンマスターテスト（Characterization Testing / Approval Testing）は、Michael Feathers が "Working Effectively with Legacy Code" で定義した手法。

核心: 既存システムの入出力を記録し、変更後も同じ出力が得られることを検証する。「正しさ」ではなく「変わっていないこと」を保証する。

なぜモダナイゼーションの成否を左右するか: 70-80%のモダナイゼーションプロジェクトが失敗する最大の原因は「ビジネスロジックの微妙な変質」。ゴールデンマスターテストはその防波堤となる。

3.2 プログラム種別ごとの適用可能性

(A) COBOL バッチ処理 — 適用難易度: 低〜中（最適）

Golden Master Testing の最も得意なパターン。

[適用パターン]
入力ファイル → COBOL バッチ → 出力ファイル + DB変更

Golden Master = {
  入力ファイル（固定）,
  DB初期状態（スナップショット）,
  出力ファイル（キャプチャ）,
  DB最終状態（スナップショット）
}

具体的な実装手順:

1. テスト用DBにSQL Server データベーススナップショットを復元
2. 入力ファイルを配置
3. COBOLバッチをBAT経由で実行
4. 出力ファイルをdiffで比較
5. DBの変更をSQLでダンプし、Golden Masterと比較

カバレッジ見積もり:

• 設備管理サブシステム（133本、バッチ主体）: 60-80% カバー可能
• 料金CISサブシステム（287本）のバッチ部分: 30-40%

(B) VB6 バッチ処理（GUI なし） — 適用難易度: 中

VKNDD0B（441行）のような「引数→処理→DB更新」型。

[適用パターン]
EXE起動（引数あり） → ExeOdbc経由DB操作 → ログ出力

Golden Master = {
  コマンドライン引数,
  DB初期状態,
  DB最終状態,
  ログファイル出力
}

課題:

• ExeOdbc.bas のODBC DSN名がハードコードされている可能性
• VB6ランタイムが必要 → CI/CDにWindows VMが必須

(C) VB6 GUI フォームアプリケーション — 適用難易度: 高（最大の壁）

VB6 GUI はゴールデンマスターテストの最大の課題。

現実的な対応:

1. DBレベルのGolden Master: GUI操作は手動で行い、DB状態の変化だけをキャプチャ
2. TestComplete: VB6コントロールを直接認識可能だが、年額約$5,000/席
3. ビジネスロジック層の分離: テスト可能な関数に抽出（工数: 1プログラムあたり数日）

3.3 使用ツール

3.4 CombinationApprovals（最重要テクニック）

Llewellyn Falco が特にレガシーコードで推奨する手法。全入力組み合わせを自動生成し、出力をまとめてスナップショット保存。

// C# での使用例（移行後コードに対して）
[Fact]
public void TestAllCombinations_MeterDataProcessing()
{
    CombinationApprovals.VerifyAllCombinations(
        (ctl, id, jigyosha, kubun) => service.ProcessRecord(
            new Kndd0Record { Ctl = ctl, Id = id, Jigyosha = jigyosha, Kubun = kubun }),
        new[] { "D", "H", "T" },           // CTL: データ/ヘッダ/トレーラ
        new[] { "1", "2", "9" },           // ID
        new[] { "2903", "9999", "" },      // JIGYOSHA: 事業者
        new[] { "0", "1" }                 // KUBUN: 今回/前回
    );
    // 3 x 3 x 3 x 2 = 54通りが自動テストされる
}

3.5 非決定的要素の処理（Scrubber）

# Scrubber 実装例
import re

def scrub_output(output: str) -> str:
    # タイムスタンプ
    output = re.sub(r'\d{4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2}', '<TIMESTAMP>', output)
    # 連番の正規化
    counter = {}
    def normalize_id(match):
        val = match.group(0)
        if val not in counter:
            counter[val] = f"ID_{len(counter)+1:04d}"
        return counter[val]
    output = re.sub(r'(?<=ID=)\d+', normalize_id, output)
    return output

3.6 AI によるテスト生成の現実

LLMで可能なこと（今すぐ）:

1. VB6/COBOLソースを読み、テストケース仕様（入力/期待出力のペア）を生成
2. 移行後のC#コードに対するxUnitテストの生成
3. ExeOdbc のSQLパターンを分析し、テストデータを提案

LLMで不可能なこと（当面）:

1. VB6/COBOLコードに対して直接実行可能なテストを生成すること
2. 暗黙的なビジネスルールの完全な理解
3. DB副作用の全パターンの推定

実績データ: LLMベースのテスト生成ツールでは、生成テストの 12-42% がコンパイルエラーまたはテスト失敗 (Diffblue 2025 ベンチマーク)。人間レビューは必須。

3.7 ゴールデンマスターの位置づけ（一時的なもの）

J.B. Rainsberger の助言に従い、ゴールデンマスターテストは、「移行の橋渡し」として一時的に使用し、移行完了後はApprovalTests.Net + xUnit による本格的なテストスイートに置き換える。長期保持するとメンテナンスコストが爆発する。

3.8 工数見積もり

4. コンテキスト保全: Knowledge Graph の要否判断

4.1 結論

未来明るく電力のケースでは「本格的な Knowledge Graph（Neo4j等）」はオーバーエンジニアリング。既存の legacy_analyzer の依存マップ（JSON/SQLite）+ Claude Code で十分。

4.2 判断根拠

4.3 Knowledge Graph が必要になる条件（現時点では非該当）

• 100万行以上のコードベース
• 複数チーム（10名以上）が並行して異なるサブシステムを移行
• COBOL REDEFINES句が大量に存在し、データリネージの追跡が必要
• Phase 2以降で複雑な依存関係のデバッグが頻発した場合

4.4 推奨する中間アプローチ

[静的解析（確定的）] + [依存マップJSON] + [Claude Code（確率的）] + [人間検証]
         ↓                    ↓                    ↓                ↓
   legacy_analyzer      コンテキスト供給        コード生成        品質保証
   (既存で完了)        (ファイル単位で投入)    (70-80%自動化)    (20-30%手直し)

1. legacy_analyzer の依存マップを移行順序の決定に使用（トポロジカルソートでリーフから）
2. 各プログラム変換時に、そのプログラムの依存先リスト・テーブルスキーマ・仕様書をClaude Codeのコンテキストに含める
3. ExeOdbc.bas は人間が設計したC#データアクセス層に変換し、自動変換に頼らない

4.5 GraphRAG が効果を発揮する唯一の領域

COBOL の COPY句（copybook）の解析。同一メモリ領域が条件フラグに応じて異なるデータ型として解釈される REDEFINES 句は、LLM単体では見落とすリスクがある。

対策: COPY句を事前に確定的な静的解析ツールで展開してからLLMに渡す。LLMに任せるのではなく、確定的ツールで前処理する。

5. AI強化型 Strangler Fig パターン

5.1 従来 vs AI強化の違い

5.2 ExeOdbc を起点としたStrangler Facade

プレイブック 4.2節 Phase 1 で定義された「ExeOdbc → REST API」の移行が、Strangler Fig の最初の切り口。

Phase 1 完了後のアーキテクチャ

5.3 COM DLL ブリッジの実装

VB6から直接呼び出し可能なCOM-visible C# DLLを作成し、内部でREST APIを呼ぶ:

// ExeOdbcBridge.cs — VB6から呼べるCOM DLL
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.AutoDual)]
[Guid("A1B2C3D4-E5F6-7890-ABCD-EF1234567890")]
public class ExeOdbcBridge
{
    private readonly HttpClient _http = new();
    private const string BaseUrl = "https://api.internal/v1";

    // VB6の ExeOdbc.bas の ExecDirect に対応
    public string ExecDirect(string sql, string connectionName)
    {
        var response = _http.PostAsync(
            $"{BaseUrl}/query",
            new StringContent(
                JsonSerializer.Serialize(new { sql, connectionName }),
                Encoding.UTF8, "application/json"
            )
        ).Result;
        return response.Content.ReadAsStringAsync().Result;
    }

    // VB6の ExeOdbc.bas の BeginTrans に対応
    public string BeginTransaction(string connectionName)
    {
        var response = _http.PostAsync(
            $"{BaseUrl}/transaction/begin",
            new StringContent(
                JsonSerializer.Serialize(new { connectionName }),
                Encoding.UTF8, "application/json"
            )
        ).Result;
        return response.Content.ReadAsStringAsync().Result;
    }
}

AIによる支援の範囲:

• ExeOdbc.bas 28プロシージャの関数シグネチャ解析 → AI可能
• COM DLLインターフェースのスキャフォールド生成 → AI可能
• REST APIエンドポイントとの対応マッピング生成 → AI可能
• エラーハンドリング・タイムアウト・リトライロジック → 人間によるレビュー必須

注意: VB6 COM DLLの完全自動生成ツールは市場に存在しない。GAPVelocity AI はVB6→C#の全面変換ツールであり、ブリッジ生成には対応しない。

5.4 API Gateway によるルーティング

[API Gateway ルーティング]

/api/v1/query      → 新REST API（移行済み）
/api/v1/legacy/*   → レガシーODBC Proxy（未移行）
/api/v1/report/*   → レガシーODBC Proxy → 新REST API（段階移行中）

Kong、NGINX、Envoy のいずれかで構成。パスベースルーティングで段階的に新旧を切り替える。

6. CDC・シャドーテスト・並行稼働

6.1 CDC（Change Data Capture）構成

SQL Server CDC セットアップ:

-- DB単位で有効化
EXEC sys.sp_cdc_enable_db;

-- 最優先テーブル: 料金CIS-設備管理間共有テーブル
EXEC sys.sp_cdc_enable_table
  @source_schema = N'dbo',
  @source_name = N'KY110',  -- 両側書き込みの最高リスクテーブル
  @role_name = NULL;

優先テーブル: KY110（料金CIS-設備管理間の両側書き込み）を最初のCDC対象にすべき。残り10件の共有テーブルは片側書き込みまたは読み取りのみなので、CDCの優先度は低い。

注意点:

• Debezium SQL Server CDC Source V1 は 2026年3月31日にEOL。V2コネクタを使用すること
• CDC有効化はDBパフォーマンスに影響する。キャプチャ/クリーンアップジョブの間隔を適切に設定
• SQL Server Agent の起動必須

6.2 シャドーテスト

本システムはバッチ処理主体＋GUI操作の構成であり、Webトラフィックベースのシャドーテストツール（Diffy等）はそのままでは適用できない。

バッチ処理向けシャドーラン:

Reconciliation Loop

照合エンジン:

• DB状態A vs DB状態B → テーブル単位でdiff
• 出力ファイルA vs B → Scrubber適用後にdiff
• 差分レポート → AIが自動分類:
  • 意図的改善 → Accept
  • 表示差異 → Known
  • 予期しない差分 → Alert → 人間レビュー

6.3 並行稼働のライフサイクル

プレイブック 7.4節のShadow Mode戦略をAIで強化:

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

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

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

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

圧縮不可能な制約: Shadow/Reverse Shadow の各2-4週間は実データでの検証であり、AIでは短縮できない。ただし差分レビューの工数は90%削減可能。

6.4 インフラコスト

並行稼働期間はインフラコストが実質2倍になる。これは「リスク低減のための投資」であり、一括切り替え失敗時のビジネス損失と比較すべき。

7. 変換精度のベンチマークと正直な評価

7.1 学術研究のデータ

COBOL → Java/C#

重要な注意: 「93%」「98.4%」はファイル単位の構文正確性であり、ビジネスロジック等価性ではない。

Microsoft Azure ブログの警告: 「ベンダーが "80%の精度" と言っても、自分のコードベースで、自分の制約で、自分のリスクプロファイルで結果を見るまではマーケティングとして扱え」

VB6 → C#

7.2 未来明るく電力プロジェクトでの予測

Claude の VB6 理解精度

Claude の COBOL 理解精度

7.3 自動変換ツールとの比較

7.4 リワーク率の現実

全体のリワーク率予測:

• 単純CRUD: 10-15%
• ExeOdbc: 5-10%（インターフェース明確のため）
• 複雑業務ロジック: 25-35%
• 全体平均: 15-20%

7.5 AI変換が「正しく見えるが間違っている」パターン

最も危険な失敗モード。コンパイルは通り、基本テストも通るが、エッジケースで誤った結果を出す:

7.6 批判的な視点

Swimm社の分析: 「Claude Code がCOBOLを読めるとは言えない」

Phase Change Software: 「同じソースコードを2回解析して異なる結果が出る可能性がある確率的ツールに、ミッションクリティカルなシステムの移行を賭けられるか」

Thoughtworks: 「Claude Code は時間とコストの面では卓越しているが、正確性の次元ではまだそうではない」

本文書の立場: これらの批判は正当。だからこそゴールデンマスターテスト + Shadow Test + 人間レビューの三重防御が必須。AIは「下書きマシン」として使い、品質保証は人間が担う。

8. コスト分析と ROI

8.1 Claude API コスト

API代はプロジェクト全体コストの0.5-2%未満。コスト構造上ほぼ無視できる水準。

Claude Code Max 20x プラン（$200/月/開発者）を使用する場合、5名 × 10ヶ月 = $10,000。

8.2 商用ツール費用

8.3 総コスト比較

手動アプローチ（24ヶ月）

AI支援アプローチ（10-12ヶ月）

差分

8.4 ROI

見落とされがちなコスト: IT予算の72%がレガシー維持に消費されている現状では、「移行しないコスト」が年間数千万円単位で積み上がる。AI支援移行の費用対効果は、移行コスト単体ではなく現状維持の機会損失コストとの対比で評価すべき。

8.5 隠れコストへの注意

9. AI強化タイムライン

9.1 全体スケジュール

9.2 各フェーズの詳細

Phase 0: 調査・基盤整備（3ヶ月 → 2ヶ月に圧縮）

Claude Code で実行:

• 596本全プログラムのビジネスロジック自動解析・要約
• 仕様書292本とソースコードの突合・ギャップ分析
• 依存グラフに基づく移行難易度スコアリング
• デッドコード候補の静的解析ベース特定

Phase 1: 共通基盤移行（3ヶ月 → 2.5ヶ月に圧縮）

[ExeOdbc REST API化のAI駆動ワークフロー]

Step 1: Claude Code が ExeOdbc 28プロシージャを解析     (1日)
Step 2: REST API スキャフォールド自動生成               (1日)
Step 3: 各プロシージャのAPI化（エージェント並列）         (1週間)
Step 4: COM DLL ブリッジ生成                          (1週間)
Step 5: ゴールデンマスターテスト生成（並列）              (3日)
Step 6: 人間レビュー + 修正                           (2週間)
Step 7: Shadow Test                                 (2週間 — 圧縮不可)

Phase 2: 機能別並列移行（12ヶ月 → 6-7ヶ月に圧縮）

圧縮の鍵: Waveの並列化

VB6とCOBOLが完全分離しているため、並列実行が可能:

各Stream内でさらに 4-8ワークツリー が並列稼働（1開発者あたり）。

Phase 3: 完全移行（6ヶ月 → 2-3ヶ月に圧縮）

Shadow/Reverse Shadow の期間自体は圧縮困難だが、差分検証の自動化で人的負荷を大幅削減。

10. リスク分析（AI固有リスク含む）

10.1 AI固有のリスク

10.2 従来型リスク（プレイブック 9節から継承）

10.3 市場全体のリスク指標

対策: 小さなPoCから開始し、実測データに基づいてスケール判断。VKNDD0B + CRY413 のデモで精度を実測してから本格移行に進む。

10.4 絶対にやってはいけないこと

1. 「Claude Code で全自動変換」と約束すること — 人間のレビューは必須
2. ExeOdbc の自動変換を信用すること — システム全体の基盤は人間が設計・レビュー
3. COMP-3 演算の変換結果を検証なしで使うこと — 金額計算の誤差は致命的
4. 全596本を一括変換すること — Strangler Figで段階的に
5. VB6 Variant → C# dynamic を許容すること — 明示的な型宣言を強制
6. ゴールデンマスターテストを省略すること — 変換の安全網として必須
7. AIの出力を「正しい」と仮定すること — 常に「下書き」として扱う

11. 実行可能な次のアクション

11.1 即座に開始できること（お客様の協力不要）

11.2 お客様の協力が必要

11.3 PoC で検証すべき項目

11.4 判断ポイント

PoC結果に基づき、以下を判断:

[PoC結果による戦略分岐]

変換精度 ≥ 85% かつ テスト自動化成功
  → AI駆動戦略を採用（本文書のタイムライン）
  → 予想: 10-12ヶ月、1.5-3.5億円

変換精度 60-85% かつ テスト部分成功
  → ハイブリッド戦略（AI + 商用ツール + 手動の組み合わせ）
  → 予想: 14-18ヶ月、2-5億円

変換精度 < 60% または テスト自動化失敗
  → 従来戦略に回帰（[04-playbook.md](/docs/playbook) のタイムライン）
  → 予想: 24ヶ月、3.5-8億円

付録: 参考文献・ソース

Anthropic / Claude 公式

• Anthropic Code Modernization Playbook
• How AI helps break the cost barrier to COBOL modernization
• Introducing dynamic workflows in Claude Code
• How Claude Code works in large codebases

学術研究

• Code Reborn: AI-Driven Legacy Systems Modernization from COBOL to Java (arXiv:2504.11335)
• XMainframe: LLM for Mainframe Modernization (arXiv:2408.04660)
• A Multi-Objective Statistical Framework for Evaluating LLM-Based Code Modernization (MDPI)
• Practical Guide to Agentic AI Transition (arXiv:2602.10122)

批判的分析

• No, Claude Code can't understand COBOL applications — Swimm
• Claude Code and COBOL modernization: What's the reality? — Thoughtworks
• Why Reading Isn't Understanding — Phase Change Software
• Gartner: 40%+ Agentic AI Projects Will Be Canceled by 2027

実装リファレンス

• Microsoft Legacy-Modernization-Agents (GitHub)
• awesome-agentic-software-modernization (GitHub)
• ApprovalTests.Net (GitHub)
• TextTest
• Debezium SQL Server Connector

コスト・市場データ

• The 2026 Legacy Modernization Report — Devox Software
• AWS Mainframe Modernization Pricing
• GAPVelocity AI — VB6 to .NET
• Diffblue Cover vs AI Coding Assistants Benchmark 2025

テスト手法

• Michael Feathers: Characterization Testing
• J.B. Rainsberger: Surviving Legacy Code with Golden Master and Sampling
• Llewellyn Falco: Combination Approvals
• Google Cloud Dual Run
• Microsoft Engineering Playbook: Shadow Testing