実世界でのCOBOL近代化から得られた教訓
AWSは、COBOL現代化においてAIコードアシスタントだけでは不十分であり、逆エンジニアリングによる完全なコンテキスト抽出とプラットフォーム固有の動作理解が不可欠であると指摘し、両者の組み合わせが必要だと述べている。
キーポイント
現代化の二つの段階とAIの限界
メインフレーム現代化は「逆エンジニアリング（既存システムの理解）」と「順エンジニアリング（新アプリケーション構築）」に分けられ、現在のAIコードアシスタントは後者のみに強く、前者の文脈欠如では失敗する。
限定された完全なコンテキストの必要性
単一プログラムでは共有データやJCLなどの依存関係が見えないため、AIに渡す前に暗黙的な依存関係を決定論的に抽出し、完全な単位で提供することが精度向上に不可欠である。
プラットフォーム固有の動作への対応
同じCOBOLコードでもコンパイラやランタイム環境によって動作（丸め処理など）が異なるため、AIにはプラットフォーム固有の挙動を解決したクリーンな入力を提供し、機密性の高い金融システムでの誤差を防ぐ必要がある。
追跡可能な基盤の構築
成功する現代化には、検証可能で追跡可能な仕様書を生成し、それをAIコードアシスタントに流し込む統合的なソリューションが必要である。
影響分析・編集コメントを表示
影響分析
本記事は、単にAIコード生成ツールを導入するだけではメインフレーム現代化が失敗することを警告し、従来の逆エンジニアリング技術と最新のAI技術を組み合わせる必要性を強調している。これは、金融や政府などレガシーシステム依存度の高い業界において、AI導入戦略の見直しを促す重要な示唆であり、実務レベルでのAI活用における「文脈の質」の重要性を浮き彫りにしている。
編集コメント
レガシーシステム現代化において、AIは「実装者」であって「設計者」ではないという認識が重要であり、人間の専門知識とAIの処理能力をどう統合するかが競争力の源泉となる。
現在、AIがメインフレームアプリケーションのモダナイゼーションを可能にすることについて多くの興奮があります。取締役会が注目しています。CIOには計画を求められています。AIはCOBOLモダナイゼーションの真の加速装置ですが、結果を得るためには、AIにはソースコードだけでは提供できない追加のコンテキストが必要です。400社以上の企業顧客との協業から学んだことは次の通りです：メインフレームモダナイゼーションには大きく異なる2つの側面があります。前半はリバースエンジニアリング（reverse engineering）で、既存システムが実際に何を行っているかを理解することです。後半はフォワードエンジニアリング（forward engineering）で、新しいアプリケーションを構築することです。
前半がメインフレームプロジェクトの成否を分けます。しかし、コーディングアシスタントは真に優れているのは後半だけです。明確で検証済みの仕様を与えれば、彼らは現代的なアプリケーションを迅速に構築します。
成功するCOBOLモダナイゼーションを実現するには、決定論的にリバースエンジニアリングを行い、検証可能で追跡可能な仕様を生成し、それらの仕様がフォワードエンジニアリングのためのAI駆動のコーディングアシスタントに流れ込むのを支援するソリューションが必要であることを学びました。成功するモダナイゼーションには、リバースエンジニアリングとフォワードエンジニアリングの両方が必要です。
成功するメインフレームモダナイゼーションに必要なもの
境界が明確で完全なコンテキスト
メインフレームアプリケーションは巨大です。本当に巨大です。単一のプログラムが数万行に及び、システム全体から共有データ定義を引き込み、他のプログラムを呼び出し、全体の環境にまたがるJCL（Job Control Language）を通じてオーケストレーションされます。現在、AIは一度に限られた量のコードしか処理できません。1つのプログラムを入力しても、コピーブック（copybooks）、呼び出されるサブルーチン、共有ファイル、すべてを結びつけるJCLを見ることはできません。AIは見えるコードに対しては合理的な出力を生成しますが、見せられなかった依存関係を見逃します。顧客との協業では、まずすべての暗黙的な依存関係を決定論的に抽出し、その後、必要なものがすべて解決済みの境界が明確で完全な単位をAIに与えることでこの問題を解決しています。これにより、AIは得意なこと（ビジネスロジックの理解、仕様の生成）に集中し、見えない接続を推測する必要がなくなります。
プラットフォームを意識したコンテキスト
人々を驚かせる事実があります：同じCOBOLソースコードでも、コンパイラとランタイムによって動作が異なります。数値の丸め方、メモリ内でのデータの配置、プログラムとミドルウェア（middleware）の通信方法などです。これらはソースコードには記載されていません。コードが構築された特定のコンパイラとランタイム環境によって決定されます。数十年にわたるハードウェアとソフトウェアの統合は、単にコードを移動するだけでは再現できません。プラットフォーム固有の動作が既に解決されている場合に、AIは最高の仕事をすることがわかりました。クリーンでプラットフォームを意識した入力をAIに与えれば、AIは成果を出します。生のソースコードを与えると、見た目は正しいが元のものとは異なる動作をする出力を生成します。金融システムでは、丸めの違いは見た目の問題ではありません。重大な誤りです。
追跡可能な基盤
銀行、保険、政府機関にいる場合、規制当局は一つの質問をします：何も見逃していないことを証明できますか？ビジネスロジックを抽出し、規制当局が受け入れる文書を生成するには、AIだけでは不十分です。規制遵守には、すべての出力が元のシステムに正式に監査可能な形で接続されている必要があります。追跡可能性は、AIがソースコードを読むことからは得られないことを早い段階で学びました。コードを正確で境界が明確な単位に構造化し、AIに入力されるものを正確に把握し、すべての出力をそのソースまで追跡できるようにすることで得られます。規制産業の顧客にとって、これはプロジェクトが前進するか停滞するかを分けることが多い違いです。
AWS TransformでAIを成功に導く方法
AWS Transformは、メインフレームアプリケーションを大規模にモダナイズするために構築しました。考え方は単純です：AIに適切な基盤を与え、顧客が本番環境に持っていける追跡可能で正確で完全な結果を得られるようにします。AWS Transformは、アプリケーションの完全で決定論的なモデルを構築することから始めます。専門的なエージェント（agents）が、システム全体にわたるコード構造、ランタイム動作、データ関係を抽出します。一度に1つのプログラムではなく、全体の環境を対象とします。これにより、AIが関与する前に、実際のコンパイラセマンティクスに沿った依存関係グラフが生成され、プログラム間の依存関係、ミドルウェアの相互作用、プラットフォーム固有の動作が捕捉されます。そこから、大きなプログラムは境界が明確で処理可能な単位に分解されます。プラットフォーム固有の動作は決定論的に解決されます。単位はAIが効果的に処理できるサイズに調整されます。その後、AIが自然言語でビジネスロジックを抽出し、すべての出力は既に抽出した決定論的証拠に対して検証されます。仕様は元のコードにマッピングされます。規制当局が「何か見逃しましたか？」と尋ねたとき、検証可能な答えがあります。これを際立たせているのは、AIが決して暗中模索で動作しないことです。処理するすべての単位には既知の入力と期待される出力があるため、返ってきたものを検証できます。市場の他のアプローチはこのループを閉じていません。出力されるのは、検証済みで追跡可能な技術仕様のセットであり、あらゆる現代的な開発環境に組み込むことができます。モダナイゼーションの難しい部分は、今日存在するものを理解することです。一度それを正確な仕様に取り込めば、AI駆動のIDE（Integrated Development Environment）は自信を持って新しいアプリケーションを構築できます。
企業変革のためのエンドツーエンドプラットフォーム
誰も1つのアプリだけをモダナイズしません。私たちの顧客は、数百または数千の相互接続されたアプリケーションのポートフォリオを見つめており、分析支援以上のものを必要としています。AWS Transformは、分析、テスト計画、リファクタリング（refactoring）、再構想（reimagination）という完全なライフサイクルにわたって自動化します。すべてをです。その中で、異なるアプリは異なる道筋を必要とします。一部はゼロから再構想されます。一部は単にJavaへのクリーンで決定論的な変換が必要です。一部はまずデータセンターから脱却し、後でモダナイズする必要があります。一部はメインフレーム上に残ります。すべてを同じように扱うことがプロジェクトが破綻する原因であることを苦労して学びました。ポートフォリオの決定（どのアプリを、どの道筋で、どの順序で）は技術と同じくらい重要です。私たちの経験では、これが企業のモダナイゼーションが実際に完了する唯一の方法です。万能なアプローチがこれらのプロジェクトが失敗する理由です。常に見落とされるもう一つの点：テストデータです。実際の本番データと実際のシナリオなしでは、モダナイズされたアプリが動作することを証明できません。私たちは、チームがコード変換をすべて完了した後、データ取得の計画が誰も立てていなかったために停滞するのを見てきました。そこで、テスト計画とオンプレミスデータ取得を初日からプラットフォームに組み込みました。最後のクリーンアップ作業ではありません。これが実際に機能するときの姿です。エンドツーエンドの自動化、各アプリに適した道筋、組み込まれた検証です。
これを正しく行う方法
問題は「COBOLモダナイゼーションにAIを使うべきか？」ではありません。もちろん使うべきです。問題は、AIをどのように設定して、規制当局への追跡可能性、プラットフォーム固有の動作の正しい処理、アプリケーションポートフォリオ全体での一貫性、数百の相互接続されたプログラムへのスケーラビリティを実現するかです。それがAWS Transformを構築する過程で私たちが理解したことです。決定論的分析を基盤として。AIを加速装置として。あらゆるモダナイゼーションパターンをカバーするAWSサービスです。
そして、それは機能しています。
BMW Groupはテスト時間を75%削減し、テストカバレッジを60%向上させ、リスクを大幅に低減しながらモダナイゼーションのタイムラインを加速しました。
Fiservは、29ヶ月以上かかっていたメインフレームモダナイゼーションプロジェクトをわずか17ヶ月で完了しました。
Itauはメインフレームアプリケーションの発見時間とテスト時間を90%以上削減し、チームが以前の手動作業よりも75%速くアプリケーションをモダナイズできるようにしました。
著者について
Dr. Asa Kalavade
AsaはAWS Transformを率い、顧客のインフラストラクチャ、アプリケーション、コードの移行とモダナイゼーションを支援しています。以前は、AWSのGo-to-Marketツール変革を率い、生成AI機能を組み込みました。また、ハイブリッドストレージとデータ転送サービスも管理しました。2016年にAWSに加わる前に、Asaはベンチャーキャピタルから資金調達した2つのスタートアップを創業し、現在もボストンのスタートアップのメンタリングに積極的に関わっています。カリフォルニア大学バークレー校で電気工学とコンピュータサイエンスの博士号を取得し、40以上の特許を保有しています。
原文を表示
There’s a lot of excitement right now about AI enabling mainframe application modernization. Boards are paying attention. CIOs are getting asked for a plan. AI is a genuine accelerator for COBOL modernization but to get results, AI needs additional context that source code alone can’t provide.Here’s what we’ve learned working with 400+ enterprise customers: mainframe modernization has two very different halves. The first half is reverse engineering, understanding what your existing systems actually do. The second half is forward engineering, building the new applications.
The first half is where mainframe projects live or die. However, coding assistants are genuinely good at only the second half. Give them a clear, validated spec and they’ll build modern applications fast.
We have learned that delivering successful COBOL modernization requires a solution that can reverse engineer deterministically, produce validated and traceable specs, and help those specs flow into any AI-powered coding assistant for the forward engineering. A successful modernization requires *both* reverse engineering and forward engineering.
What a successful mainframe modernization requires
Bounded, complete context
Mainframe applications are big. Really big. A single program can run tens of thousands of lines, pulling in shared data definitions from across the system, calling other programs, orchestrated through JCL that spans the entire landscape. Today, AI can only process a limited amount of code at a time. Feed it one program and it can’t see the copybooks, the called subroutines, the shared files, or the JCL that ties everything together. It will produce output that looks reasonable for the code it can see but miss dependencies it was never shown. In working with customers, we solve this by extracting all implicit dependencies deterministically first, then feeding AI bounded, complete units with everything it needs already resolved. That way AI focuses on what it’s great at (understanding business logic, generating specifications) instead of guessing at connections it can’t see.
Platform-aware context
Here’s something that surprises people: the same COBOL source code behaves differently depending on the compiler and runtime. How numbers get rounded, how data sits in memory, how programs talk to middleware. These aren’t in the source code. They’re determined by the specific compiler and runtime environment the code was built for. Decades of hardware-software integration can’t be replicated by simply moving code. We found that AI does its best work when platform-specific behavior has already been resolved. Feed AI clean, platform-aware input, and it delivers. Feed it raw source code, and it’ll generate output that looks right but behaves differently than the original. In financial systems, a rounding difference isn’t a cosmetic issue. It’s a material error.
A traceable foundation
If you’re in banking, insurance, or government, your regulators will ask one question: can you prove you didn’t miss anything? AI on its own isn’t enough to extract business logic and generate documentation that regulators will accept. Regulatory compliance requires every output to have a formal, auditable connection back to the original system. We learned early that traceability doesn’t come from AI reading source code. It comes from structuring the code into precise, bounded units so we know exactly what goes into the AI and can trace every output back to its source. For customers in regulated industries, this is often the difference between a project that moves forward and one that stalls.
How we set AI up for success in AWS Transform
We built AWS Transform to modernize mainframe applications at scale. The idea is straightforward: give AI the right foundation, and customers get traceable, correct, and complete results they can take to production. AWS Transform starts by building a complete, deterministic model of the application. Specialized agents extract code structure, runtime behavior, and data relationships across the entire system — not one program at a time, but the whole landscape. This produces a dependency graph aligned with the actual compiler semantics, capturing cross-program dependencies, middleware interactions, and platform-specific behavior before AI gets involved. From there, large programs get decomposed into bounded, processable, units. Platform-specific behavior is resolved deterministically. The units are sized for AI to process effectively. Then AI extracts business logic in natural language, and every output gets validated against the deterministic evidence we’ve already extracted. Specs map back to the original code. When a regulator asks “did you miss anything?”, there’s a verifiable answer. What sets this apart is that AI never operates in the dark. Every unit it processes has known inputs and expected outputs, so we can validate what comes back. No other approach on the market closes that loop. What comes out is a set of validated, traceable technical specifications that plug into any modern development environment. The hard part of modernization is understanding what exists today. Once you’ve captured that in precise specs, AI-powered IDEs can build the new application with confidence.
An end-to-end platform for enterprise transformation
Nobody modernizes one app. Our customers are staring at portfolios of hundreds or thousands of interconnected applications, and they need way more than analysis help. AWS Transform automates across the full lifecycle: analysis, test planning, refactoring, reimagination. The whole thing. And within that, different apps need different paths. Some get re-imagined from scratch. Some just need a clean, deterministic conversion to Java. Some need to get out of the data center first and modernize later. Some will remain on the mainframe. We learned the hard way that treating them all the same is how projects blow up. The portfolio decision (which app, which path, what order) matters as much as the tech. In our experience, this is the only way enterprise modernization actually finishes. One-size-fits-all approaches are why these projects fail. One more thing that gets overlooked constantly: test data. You can’t prove the modernized app works without real production data and real scenarios. We’ve watched teams get all the way through code conversion and then stall because nobody planned for data capture. So, we built test planning and on-prem data capture into the platform from day one. Not a cleanup exercise at the end. That’s what this actually looks like when it works. End-to-end automation, the right path for each app, validation baked in.
How to get this right
The question isn’t “should we use AI for COBOL modernization?” Of course you should. The question is how you set AI up to deliver: traceability for regulators, platform-specific behavior handled correctly, consistency across your application portfolio, and the ability to scale to hundreds of interconnected programs. That’s what we figured out building AWS Transform. Deterministic analysis as the foundation. AI as the accelerator. An AWS service that covers the full range of modernization patterns.
And it’s working.
BMW Group reduced testing time by 75% and increased test coverage by 60%, significantly lowering risk while accelerating modernization timelines.
Fiserv completed a mainframe modernization project that would have taken 29+ months in just 17 months.
Itau cut mainframe application discovery time and testing time by more than 90%, enabling teams to modernize applications 75% faster than with previous manual efforts.
About the authors
Dr. Asa Kalavade
Asa leads AWS Transform, helping customers migrate and modernize their infrastructure, applications, and code. Previously, she led the AWS go-to-market tools transformation, incorporating generative AI capabilities. She also managed hybrid storage and data transfer services. Before joining AWS in 2016, Asa founded two venture-backed startups and remains active in mentoring Boston startups. She holds a PhD in electrical engineering and computer science from UC Berkeley and more than 40 patents.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み