はじめに：AIは「魔法の杖」ではなく「強力なドリル」である
「COBOLのコードをAIに読み込ませれば、明日にはピカピカのJavaコードが出来上がっている」
もし、ベンダーからそんな夢のような提案を受けているなら、一度立ち止まって深呼吸することをお勧めします。実務の現場では、初期のAIツールによる「自動変換」を過信した結果、生成されたコードのデバッグに、手動で書く以上の時間を費やしてしまうケースが散見されます。
AIエージェント開発や業務システム設計の専門家として、そして長年開発現場で培った知見から申し上げます。生成AIはレガシーマイグレーションにおける最強の武器になり得ますが、それは使い手が「正しいプロセス」を設計できた場合に限られます。
昨今、GitHub CopilotやAmazon Q DeveloperといったAIコーディング支援ツール、あるいはIBM watsonx Code Assistant for Zのようなメインフレーム特化型サービスが急速に進化しています。これらは確かに革新的です。しかし、これらを単なる「翻訳機」として使ってしまうと、古いロジックをそのまま新しい言語に書き写しただけの、誰もメンテナンスできない「モダンなスパゲッティコード」を量産することになります。
本記事では、ツールベンダーの営業トークでは語られない、現場レベルの「泥臭い現実」と、それを乗り越えるための「AI×人間」の協調ワークフローについて、客観的なデータに基づいた実践的なノウハウを共有します。明日からのプロジェクト計画に、ぜひ役立ててください。
1. なぜ「AI×人間」のハイブリッド・ワークフローが必要なのか
「AIによる完全自動変換」の幻想と現実的な到達点
まず、期待値を正しく設定しましょう。最新のLLM（大規模言語モデル）を用いたとしても、レガシーコードの変換精度は、条件が良い場合でも80%から90%程度というのが業界の一般的な認識です。
例えば、McKinsey & Companyが2023年に発表したレポート「Unleashing developer productivity with generative AI」によると、生成AIはコード生成タスクにおいて開発者の生産性を大幅に向上させることができますが、特に複雑なタスクにおいては、依然として人間の専門知識が不可欠であると結論付けています。AIは文法的な変換（Syntax Translation）は得意ですが、文脈的な意図（Semantic Intent）を汲み取ることはまだ完全ではありません。
もし100万行のコードをAIで一気に変換し、その中に1%の論理エラーが紛れ込んだとしたらどうなるでしょうか。1万箇所のエラーを、人間が後からデバッグすることになります。これは、最初から書き直すよりも遥かに高いコストがかかる場合があります。いわゆる「パレートの法則（80:20の法則）」がここでも適用され、残りの20%の修正に、プロジェクト全体の80%のリソースが割かれることになるのです。
スピードと品質のトレードオフを解消する協調モデル
だからこそ、私たちは「AIに任せる領域」と「人間が判断する領域」を明確に分ける必要があります。
- AIの役割: 定型的なコード変換、ボイラープレート（定型コード）の生成、単体テストのドラフト作成、コメントの付与。
- 人間の役割: アーキテクチャの設計、複雑なビジネスロジックの再定義、AI生成物のレビュー、セキュリティとパフォーマンスの最終判断。
この役割分担を定義せずにプロジェクトを開始することは、地図を持たずに樹海に入るようなものです。成功するプロジェクトでは、AIを「優秀だが経験の浅い新人プログラマー」のように扱い、シニアエンジニア（人間）が適切な指示（プロンプト）とレビューを行う体制を組んでいます。
失敗プロジェクトに共通する「プロセス設計」の欠落
Standish Groupの「CHAOS Report」などで長年指摘されている通り、ITプロジェクトの失敗の多くは技術的な問題ではなく、マネジメントやプロセス設計の不備に起因します。
一般的な傾向として、失敗するプロジェクトの多くは、ツール選定には時間をかける一方で、「どうやって検証するか」というプロセス設計が欠落しています。「変換ツールを買えば何とかなる」という思考停止が最大のリスクです。リプラットフォーム（基盤刷新）の本質は、言語を変えることではなく、システムを将来にわたって維持可能な状態にすることです。ブラックボックス化したレガシーシステムを、AIを使ってさらにブラックボックス化してしまっては、元も子もありません。
2. 【準備フェーズ】移行対象の棚卸しとAI適合性評価
いきなり変換ボタンを押してはいけません。料理において下ごしらえが味を左右するように、AIマイグレーションでも準備フェーズが成否の8割を決定します。まずはプロトタイプを作り、仮説を即座に形にして検証するアプローチが有効です。
コード複雑度の可視化と難易度ランク付け（S/A/B/C）
まず行うべきは、現行資産の徹底的な棚卸しです。全てのプログラムがAI変換に適しているわけではありません。実務においては、以下の4つのランクに分類することが推奨されます。
- ランクS（手動リライト推奨）: ビジネスの中核を担う複雑なロジック、または外部システムとの密結合部分。AIによる変換リスクが高いため、仕様書ベースでの再設計を行います。
- ランクA（人間主導＋AI支援）: 重要なロジックだが、パターン化可能な部分。エンジニアが設計の主導権を握り、GitHub Copilotの最新エージェント機能などを活用します。単なるコード補完にとどまらず、Issueや仕様書から実装案を生成させたり、
@workspaceコマンドを用いてプロジェクト全体の文脈を踏まえたコーディングを任せたりします。 - ランクB（AI主導＋人間レビュー）: 定型的な帳票出力やデータ加工処理。AIモデルによる自動変換をメインとし、人間は生成されたコードのレビューとテストに徹します。
- ランクC（廃止・塩漬け）: 過去数年使われていない機能。移行対象から外します。
この分類には、客観的な指標が必要です。SonarQubeなどの静的解析ツールを用いて「サイクロマティック複雑度（循環的複雑度）」を計測してください。一般的に、複雑度が10以下のメソッドはシンプルでテストしやすく、AI変換にも適しています。一方で、複雑度が50を超えるようなモンスターメソッドは、人間が読んでも理解困難であり、AIに食わせてもまともなコードは返ってきません。このような定量的根拠に基づいて仕分けを行うことで、プロジェクト全体のリスクを可視化できます。
AI変換に適したモジュールと手動リライトすべきモジュールの選別
AIは「ロジックが閉じた」モジュールの変換は得意ですが、グローバル変数を多用していたり、データベースのストアドプロシージャと複雑に絡み合ったりしているコードは苦手です。
例えば、COBOLのGO TO文が乱立するスパゲッティコードをそのままJavaなどのモダンな言語に変換させると、AIは忠実にGO TO的な構造を再現しようとします（ラベル付きbreakや例外処理の悪用など）。これは移行先言語としては極めて低品質なコードになります。
このようなモジュールは、AIに「逐語的な変換」をさせるのではなく、処理の入力と出力（I/O）だけを定義し、中身のロジック生成をゼロから依頼するアプローチが有効です。最近のAIコーディングツールでは、「Planモード」のように、実装前に計画立案と検証を繰り返すワークフローが推奨されています。ここで無理に古い構造のまま変換しようとすると、後のテスト工程で大きな負債となります。
ドメイン知識のコンテキスト化：RAG（検索拡張生成）活用の準備
AIの精度を高めるための重要な鍵が、RAG（Retrieval-Augmented Generation）、そしてその進化形であるGraphRAGやエージェント型RAGの活用準備です。
ChatGPTやClaudeの最新モデルといった汎用的なLLMは、対象となる業務知識（ドメイン知識）を知りません。「商品コードの3桁目が'9'の場合は特別扱いする」といった独自のルールは、コードだけを見ても意図が読み取れないことが多いのです。
そこで、以下のステップでAIが参照可能なナレッジベースを整備します。
- 資料のデジタル化と構造化: 設計書、データ辞書、用語集などをデジタル化します。古い紙の仕様書がある場合、最新のマルチモーダルAIモデルを活用して高精度なOCR処理を行います。
- GraphRAGへの対応: 単なるテキスト検索だけでなく、情報の関係性を理解させるために「ナレッジグラフ」の構築を検討してください。これにより、AIは「機能A」と「データベースB」の依存関係を構造的に理解できるようになります。
- コンテキスト情報の注入とMCP連携: コード変換を指示する際に、「この変数は『在庫引当区分』を指しており、関連ルールはドキュメントAを参照」といったメタデータを注入します。最新のアプローチでは、MCP（Model Context Protocol） サーバーを介して、AIエージェントがデータベースやドキュメント管理システムに直接かつ安全にアクセスし、必要なコンテキストを自律的に取得する環境を構築することも視野に入れます。
最近のトレンドでは、単一の検索だけでなく、AIエージェントが自律的に複数のドキュメントを横断して調査し、計画・実装・検証のループを回す「Agentic Workflow」が主流になりつつあります。この準備をしておくことで、AIは単なる記号変換ではなく、ビジネスの意味を理解したコード生成が可能になります。
3. 【実行フェーズ】AIコード変換パイプラインの構築手順
準備が整ったら、いよいよ変換パイプラインを構築します。ここでは「一発変換」ではなく、継続的に品質を高めるループ構造を作ることが重要です。まずは小さく動くプロトタイプを作り、検証を重ねながらスケールさせていくのが成功の秘訣です。
プロンプトエンジニアリング：変換ルールとコーディング規約の強制
AIに対する指示（プロンプト）は、仕様書そのものです。単に「COBOLをJavaに変換して」と頼むのは、「美味しい料理を作って」と注文するのと同じくらい曖昧であり、プロの仕事ではありません。
Few-Shotプロンプティングという手法を使いましょう。これは、プロンプトの中に「変換前のコード例」と「理想的な変換後のコード例」を数パターン含める方法です。
例えば、以下のような具体的な指示を与えます。
「COBOLの
PERFORM文は、Javaではメソッド呼び出しに変換すること。変数名はスネークケースではなくキャメルケース（camelCase）に統一すること。例外処理はJava標準のExceptionではなく、プロジェクト独自のBusinessExceptionを使用すること。」
このようにルールを明文化し、実例（Shot）とともに提示することで、生成されるコードのスタイルが統一され、後のレビュー負荷が劇的に下がります。
バッチ処理による一括変換フローの設計
数千本のプログラムを手作業でチャットツールにコピペするのは非現実的です。OpenAI APIやAzure OpenAIなどを利用したバッチ処理プログラムを構築しましょう。
具体的なフローは以下の通りです。
- ソース読み込み: Gitリポジトリから対象コードを取得。
- 前処理: コメントの除去や、不要な空白の削除、文字コードの変換（EBCDICからUTF-8へ等）。
- AI変換: 構築したプロンプトとセットでLLM APIに送信。
- 後処理: 生成コードのフォーマット整形（Prettier等のLinter適用）。
- 保存: 新しいリポジトリに格納。
このフローの中で、APIのエラー（タイムアウトやトークン制限）が発生した場合は自動的にリトライする仕組みや、どのプロンプトバージョンで生成したかをログに残すトレーサビリティ（追跡可能性）を確保しておくことが重要です。
AIによる「コード解説コメント」と「単体テスト」の同時生成
ここがAI活用の最大のメリットです。コードを変換する際、同時に以下の2つも生成させましょう。
- コード解説ドキュメント: 「このロジックは何をしているのか」を自然言語で説明させる。これは後の保守担当者にとって貴重な資産になります。
- 単体テストコード（JUnitなど）: ロジックが正しいかを検証するためのテストコード。
特にテストコードの自動生成は、次の検証フェーズで強力な武器になります。AIが生成したコードが正しいかどうかを、AIが生成したテストで検証する（もちろん人間がテスト設計を監修する前提ですが）ことで、品質保証のサイクルを高速化できます。適切に導入した場合、この手法により単体テストのカバレッジを初期段階で60%以上確保できる事例もあります。
4. 【検証フェーズ】人間が介入すべきレビューと品質保証（QA）
AIが生成したコードは、あくまで「ドラフト（下書き）」です。ここからの検証プロセスが、プロジェクトの品質を決定づけます。
「AI幻覚（ハルシネーション）」を検出する自動静的解析
AIは時々、存在しないライブラリメソッドを呼び出したり、変数の型を勝手に解釈したりする「幻覚」を起こします。もっともらしい顔をして嘘をつくのです。
これを人間が目視で見つけるのは困難です。JavaであればSonarQubeやCheckstyle、SpotBugsといった静的解析ツールをCI/CDパイプライン（JenkinsやGitHub Actions）に組み込み、コンパイルエラーや明らかなバグ、セキュリティ脆弱性を自動的に検出して弾く仕組みを作ります。
「コンパイルが通る＝動く」ではありませんが、「コンパイルが通らないコード」をレビューする必要はありません。人間の時間は、もっと高度な検証に使うべきです。
新旧システムの入出力比較（現新比較）テストの効率化
マイグレーションにおいて最も信頼性が高いテストは、「同じデータを入力した時、新旧システムで同じ結果が出るか」を確認することです。これは「リグレッションテスト（回帰テスト）」の一種です。
- 現行システムから、過去のトランザクションデータ（入力）と処理結果（出力）を抽出します。
- 新システムに同じ入力を流し込みます。
- 両者の出力を比較し、差分がないか検証します。
この比較プロセス自体も、スクリプト化して自動化すべきです。AIによって変換されたロジックが、端数処理や日付計算などで微妙なズレを起こしていないか、大量のデータを使って検証します。ここで不一致が見つかれば、それはAIの変換ミスか、あるいは現行システムの潜在バグ（仕様バグ）の発見につながります。
人間によるコードレビューの重点ポイントとチェックリスト
自動テストを通過したコードに対して、最後に人間がレビューを行います。ここでは文法チェックではなく、以下の観点に集中します。
- ビジネスロジックの正当性: 仕様通りに動作しているか。特に境界値分析（Boundary Value Analysis）の観点でチェックします。
- 非機能要件: パフォーマンスは十分か、メモリリークの懸念はないか。
- 可読性: 将来の担当者が理解できる構造になっているか。
- AI特有の冗長性: 無駄なループや、過剰な例外処理が含まれていないか。
AIは「動くコード」は書けますが、「美しいコード」や「効率的なコード」を書くとは限りません。エンジニアとしての美学と経験則を発揮するのは、まさにこのレビュー工程です。
5. 運用への引き継ぎと継続的な改善サイクル
プロジェクトの終わりは、新しいシステムの始まりです。AIを活用してリプラットフォームしたシステムを、持続可能な状態で運用チームに引き継ぐためのポイントを解説します。
変換済みコードのメンテナンス体制
移行後のコードは、もはや「自動生成されたもの」として扱うのではなく、人間が責任を持つ「自社の資産」として管理しなければなりません。
よくある失敗は、「修正が必要になったら、また元のCOBOLを直してAI変換すればいい」と考えてしまうことです。これは絶対に避けてください。一度移行が完了したら、元のレガシーコードは「参照用」としてアーカイブし、修正は必ず新言語（Javaなど）側で行うというルールを徹底します。そうしなければ、いつまでたってもレガシー言語の呪縛から逃れられません。
開発チームへのスキルトランスファーとドキュメント整備
レガシー担当のエンジニアが、そのまま新システムの担当になるケースも多いでしょう。AIはここでも教育係として役立ちます。
AIに生成させた「コード解説」や、新旧コードの対比表を活用し、エンジニア向けの学習セッションを実施します。「COBOLのこの処理は、Javaではこう表現されている」という具体的な対比は、新しい言語の習得を加速させます。これはリスキリング（再教育）の良い機会でもあります。
プロジェクト完了後の技術的負債を残さないために
AIツールは日々進化しています。プロジェクト期間中に新しいモデルが登場し、より良いコードが生成できるようになることもあります。
しかし、完璧を求めて再変換を繰り返すとプロジェクトは終わりません。「現時点でのベスト」を定義し、カットオーバー（本稼働）を目指す決断力がPMには求められます。残った課題は技術的負債としてバックログに記録し、運用フェーズでのリファクタリング計画に組み込みましょう。
まとめ：AIを味方につけ、レガシーの重荷を下ろす
レガシーマイグレーションは、企業のDX（デジタルトランスフォーメーション）における最大の障壁の一つです。AIはこの壁を突破するための強力なドリルですが、それをどこに当て、どう掘り進めるかを決めるのは人間です。
- 全自動を信じない: 80%の自動化と20%の人間による高度な判断を組み合わせる。
- 準備を怠らない: コードの棚卸しとAI適合性の評価で勝負は決まる。
- 品質を保証する: プロンプトエンジニアリング、自動テスト、現新比較の3段構えでリスクを潰す。
このプロセスを適切に設計できれば、コストを抑えつつ、期間を短縮し、何より「エンジニアが扱いたくなる」モダンなシステムへと生まれ変わらせることが可能です。
しかし、実際のプロジェクトでは、個別のシステム特性に応じた微調整が必ず必要になります。「対象システムの場合、どのランクに分類すべきか？」「最適なAIツールの組み合わせは？」「セキュリティ要件をどうクリアするか？」といった具体的な疑問をお持ちの場合は、詳しくは専門家に相談することをおすすめします。
プロジェクト固有の課題に対して、最適なAI活用ワークフローを設計することが重要です。レガシーシステムの重荷を下ろし、未来への投資を加速させる第一歩を、ここから踏み出していきましょう。
コメント