第1に、データの“意味”がコード構造に埋もれている点だ。COBOLでは、データはコピー簿（copybook）と呼ばれる固定位置のメモリ構造で管理される。型やスキーマの概念はなく、フィールド名も統一されていない。同じ値であってもプログラムごとに異なる名前で定義され得る。

　問題は、プログラム間の関係が「メモリ上の位置」でしかつながっていないことだ。Pythonであれば“tax_id”のように意味を推測できるが、COBOLでは「03 WS-FIELD-01」が何を表すのか文脈なしに判断できない。AIはこの暗黙的な依存関係を解釈するのが苦手であり、データの流れを正確に追跡できない。

　第2に、学習データの不足だ。COBOLコードの大半は企業内に閉じており、公開されていない。そのため大規模言語モデル（LLM）は、COBOL特有の命名規則や実装パターンを十分に学習できていない。ベテランエンジニアが持つ「経験に基づく推測力」を再現できない状態にある。

　第3に、フィードバックループの断絶だ。現代のAIは「コードを書く、実行する、結果を評価する、修正する」というループで性能を高める。しかしCOBOLは一般的にメインフレーム上でしか動作しない。さらにJCL（ジョブ制御言語）やDB2などの周辺システムと密に結合しており、検証環境の再現も難しい。このためAIは「動かして学ぶ」ことができない。

COBOLの壁を越える2つの仕組み

　では、DevinのようなAIを活用してCOBOL刷新を成功させるための要素は何か。

コードベース全体を可視化する「DeepWiki」

　DeepWikiは各プログラムの構造を解析し、コピー簿によるメモリブロックがプログラム間でどう流れるかを追跡する。これにより、暗黙的だった依存関係をインタラクティブな図として可視化する。

　COBOLでは「同じデータが異なる名前で存在する」ことが最大の難所だが、DeepWikiはそれを横断的に結び付ける。結果として、Devinはコードに手を加える前に「システム全体の地図」を持てるようになる。

「Playbook」機能

　Playbookは、マイグレーション手順やCOBOL固有の制約（桁数制限、変数仕様など）をルールセットとして記述する仕組みである。

　特徴は、Playbookが固定的な手順書ではない点にある。セッションを重ねるごとに、Devin自身が曖昧な記述を修正し、冗長なステップを削除する。つまり、実行を通じて精度が高まる「自己改善型の運用知識」として蓄積されていく。

　COBOLの刷新が失敗する理由は、「全体像がないまま変更すること」と「検証できないこと」にある。そこでDeepWikiが、全体像がないまま変更することを解決する役割を担う。システム全体の依存関係を把握することで、変更の影響範囲を事前に特定できる。

　Playbookは検証できないことを補う役割だ。特にバッチ処理のように入力と出力が明確な領域では、Playbookに基づいて別言語で再実装し、結果を照合することでフィードバックループを再構築できる。この2つが組み合わさることで、「AIがCOBOLを扱えない理由」を実務的に回避する。

Devinが成果を出した3つの実例

　Devinは、以下の3領域で成果を上げている。

事例1．ブラックボックス化したCOBOLの可視化

　経済誌Fortuneが発表する企業の売上高ランキング「Fortune 500」に名を連ねるある医療企業では、保険請求処理に関する数百万行規模のCOBOLコードが利用されていた。そのコードは、退職済みのエンジニアが書いたものだ。社内にCOBOLを理解できる人材は残っておらず、業務部門が自社システムの仕組みを把握できないという課題に直面していた。

　同社はDeepWikiを活用し、Devinが理解できるシステム全体のマップを構築した。DeepWikiは各プログラムの構造を解析し、コピー簿を通じたメモリブロックの流れを追跡。その関係性をインタラクティブな図として可視化することで、コードベース全体の理解を可能にした。

　この全体像を前提に、Devinは各COBOLプログラムを単なるコードではなく「業務処理の一部」として分析した。どの業務課題を解決しているのか、処理フローのどこに位置するのか、どの決済システムに影響するのかといった観点で整理した。

　その過程で、あるプログラムに「システム障害後の重複取引を防ぐための回復ロジック」が存在することを特定した。このような重要な仕組みは従来可視化されておらず、監査対応でも説明が難しかった。可視化によって、財務上の重要な統制が明確になり、監査証跡として提示できる状態になった。

　同社は今後もドキュメント化を進める計画であり、コード内に埋もれていた業務知識の回収を加速させている。

事例2．バッチ処理のクラウド移行

　ドキュメント化によって知識を可視化した後、多くの企業が次に目指すのが「メインフレームからの脱却」だ。世界トップ10に入るある自動車メーカーは、約2万5000行のCOBOLで構築された通関業務のワークフローを、AWS Lambdaへ移行するプロジェクトに取り組んだ。

　この移行が成功したのは、対象が「バッチ処理」だったためだ。バッチ処理は入力と出力が明確であり、AIが結果を検証しながら改善できる。

　同社はCOBOLの入出力データをDevinに与え、内部ロジックを解析させた。その上で、同じ挙動を再現するPythonコードを生成し、仮想環境上で実行。既知の出力結果と照合しながら、不一致が解消されるまで反復的に改善した。

　このプロセスを支えたのが「Playbook」だ。Playbookは移行手順や制約条件を定義したルールセットであり、Devinは実行結果を基に「何がうまくいき、何が問題か」を分析し、手順の曖昧さを修正し、不要なステップを削除していく。

　セッションを重ねるごとにPlaybookの精度は向上し、それに伴いDevinの実行精度も安定。移行作業は加速し、最終的に数カ月で完了した。結果として、移行コストを約73％削減する成果を上げた。

事例3．大規模リファクタリングの自動化

　中南米の民間銀行であるItau Unibancoは、政府の規制変更により、企業のTax ID（税務識別番号）を数値から英数字へ変更する必要に迫られた。一見単純な変更に見えるが、COBOLでは一括の置換ができない。データは複数の形式でシステム全体に分散しており、その出現パターンは約20種類にも及んでいた。

　当初、他のAIエージェントを試したものの、COBOL特有の制約を理解できず、72文字のカラム制限を超えたり、COMP型変数を誤って処理したりする問題が発生。結果としてコードが動作せず、エンジニアが手作業で修正する必要があった。

　これに対しDevinは、銀行のCOBOL専門家が定義したPlaybookに従って処理を実行した。文字数制限やデータ型、命名規則といった制約をすべてルール化し、それを厳守した上でコードを生成した。

　さらに、複数のエージェントを並列で実行することで、数百のプログラムにまたがる変更を同時に処理。結果として、政府の期限より3カ月早く改修を完了し、本番環境でのエラーはゼロだった。