実世界における COBOL のモダナイゼーションから学んだこと

現在、AI がメインフレームアプリケーションのモダナイゼーションを可能にすることについて、大きな期待が寄せられています。企業の取締役会は注目しています。CIO はプランを求められています。AI は COBOL のモダナイゼーションを加速する真のアクセラレーターです。しかし、確かな結果を得るには、ソースコードだけでは提供できない追加のコンテキストが必要です。400 社を超える企業顧客と一緒に仕事をした経験から私たちが学んだことは、メインフレームのモダナイゼーションには 2 つのまったく異なる側面があるということです。前半はリバースエンジニアリングで、既存のシステムが実際に何をするのかを理解します。後半は、新しいアプリケーションを構築するフォワードエンジニアリングです。

メインフレームプロジェクトが生き残るか死ぬかは前半で決まります。一方、コーディングアシスタントが本当に優れているのは後半だけです。明確で検証済みの仕様を提供すれば、モダンなアプリケーションを素早く構築できます。

COBOL のモダナイゼーションを成功させるには、決定論的にリバースエンジニアリングを行い、検証済みで追跡可能な仕様を生成し、それらの仕様をフォワードエンジニアリング用の AI 搭載コーディングアシスタントに流し込むことができるソリューションが必要である、ということを私たちは学びました。モダナイゼーションを成功させるには、リバースエンジニアリングとフォワードエンジニアリングの両方が必要です。

メインフレームのモダナイゼーションを成功させるために必要なこと

対象範囲内の全てを含む完全なコンテキスト

メインフレームアプリケーションは大規模です。実に大きい。1 本のプログラムが何万行のこともあり、システム全体で共有しているデータ定義を取り込んだり、他のプログラムを呼び出したり、環境全体にわたる JCL を介してオーケストレーションされている場合があります。現在、AI が一度に処理できるコードの量は限られています。1 本のプログラムを生成 AI に入力しただけでは、そのプログラムから参照されるコピーブック、呼び出されるサブルーチン、共有ファイル、これら全てを結び付ける JCL があっても、関連するコード一式を生成 AI が見に行くことはできません。対象のコードに対して一見妥当に見える出力が生成されますが、不可視だった依存関係は見逃されます。お客様との共同作業では、まず暗黙の依存関係をすべて決定論的に抽出し、対象範囲内で必要なものすべてを特定済の完全なものとして AI に供給することで、この問題を解決します。そうすれば、AI は実際には見えていない関連性を推測で補おうとしなくても良くなり、得意なこと (ビジネスロジックの理解、仕様の生成) に集中できます。

各プラットフォームに固有のコンテキスト

同じ COBOL ソースコードでも、実行するコンパイラおよびランタイムによって動作が異なり、驚くことがあります。数値が四捨五入される仕組み、データがメモリー内にどのように配置されるか、プログラムがミドルウェアと通信する方法。これらはソースコードには書かれていません。これらは、コードをビルドする特定のコンパイラと、デプロイ先の特定のランタイム環境によって決まります。ハードウェアとソフトウェアの組み合わせで何十年にもわたって実行されてきた結果は、別のプラットフォームにコードを移動するだけで単純に再現できるものではありません。AI は、プラットフォーム固有の動作が既に解決済の場合に最も効果を発揮することがわかりました。クリーンで、プラットフォームを意識したインプットを AI に提供すれば、それが実現します。生のソースコードをそのまま生成 AI にインプットすると、一見正しく見えても、元のアウトプットと異なる結果が生成されることがあります。金融システムでは、四捨五入の差は見かけ上の問題ではありません。これは重大な誤差です。

トレーサビリティの基礎

銀行、保険、政府関係者の場合、規制当局からある質問を受けることになります。それは、何も見落としていないことを証明できるか、ということです。ビジネスロジックを抽出し、規制当局が受け入れ可能な文書を生成するには、AI だけでは不十分です。規制遵守のためには、すべてのアウトプットが元のシステムに正式かつ監査可能な形で結び付けられている必要があります。AI によるソースコードの読み取りだけからトレーサビリティが得られないことは、早い段階で学びました。正確で特定の単位にコードを構造化することで、AI に何が入るかを正確に把握し、すべての出力をそのソースまで追跡できるようになります。規制の厳しい業界のお客様にとって、これは多くの場合、プロジェクトが進むか行き詰まるかの分かれ目になります。

AI をどのように設定したことで AWS Transform が成功したか

私たちは、大規模なメインフレームアプリケーションをモダナイズするために AWS Transform を構築しました。アイデアは単純明快です。AI に適切な基盤を提供すれば、お客様はトレーサブルで正確かつ完全な結果を得て、本番環境に持ち込むことができます。AWS Transform は、まずアプリケーションの完全で決定論的なモデルを構築することから始めます。システム全体 (一度に 1 本のプログラムではなく、対象のコード一式) のコード構造、実行時の動作、データ間の関連を、専門的に特化したエージェントが抽出します。これにより、実際のコンパイラのセマンティクスに沿った依存関係グラフを構成し、AI が関与する前に、プログラム間の依存関係、ミドルウェアのやり取り、プラットフォーム固有の動作をキャプチャします。そこから、大規模なプログラム群は、処理可能な単位にグループ化されます。プラットフォーム固有の動作は決定論的に解決されます。AI が効果的に処理できるよう、各グループに上限サイズを設定できます。次に AI がビジネスロジックを自然言語で抽出し、既に抽出済の決定論的なエビデンスと、すべての出力を照らし合わせて検証します。スペック(仕様)は元のコードにマッピングされます。規制当局の「何か見落としはありましたか?」という問いに対して、検証可能な答えがあります。このように明解に言い切ることができるのは、AI の動作に透明性があるためです。AI によるすべての処理単位には、既知のインプットと期待されるアウトプットがあるため、何が戻されるか検証することができます。メインフレームモダナイゼーション市場において、生成 AI でこのようなクローズドループを実現するアプローチは、他にありません。出力されるのは、あらゆるモダンな開発環境に対応する、検証済みでトレーサブルな技術仕様一式です。モダナイゼーションで難しいのは、現在存在しているものを理解することです。それを正確な仕様で把握できれば、AI 搭載の IDE は自信を持って新しいアプリケーションを構築することができます。

エンタープライズトランスフォーメーションのための end-to-end のプラットフォーム

単一のアプリケーションだけをモダナイズする人はいません。AWS のお客様は、何百、何千もの相互に接続されたアプリケーションのポートフォリオに注目していますが、必要としているのは分析の支援だけで無く、それ以外にもあります。AWS Transform は、分析、テスト計画、リファクタリング、reimagine といったライフサイクル全体を自動化します。これら全て。そしてその中でも、アプリケーションが異なれば、モダナイゼーションで辿る経路も異なります。中にはゼロから reimagine されるものもあります。Java へのクリーンで決定論的な変換だけが必要なものもあります。中には、まずワークロードをデータセンターから出すことを優先して、その後でモダナイズする企業もあります。一部はメインフレームに残るものもあります。それらをすべて同じように扱うとプロジェクトが爆発するということを私たちは苦労の末に学びました。ポートフォリオの決定 (どのアプリケーション、どのパス、どの順序) は、テクノロジーと同じくらい重要です。私たちの経験では、これが企業のモダナイゼーションを実際に完了する唯一の方法です。単一のソリューションで全てを解決しようとするアプローチこそが、これらのプロジェクトが失敗する理由です。もう 1 つ見過ごされがちなのは、テストデータです。リアルな本番データとリアルなシナリオがなければ、モダナイズされたアプリケーションが機能することを証明することはできません。チームがコード変換を最後までやり遂げたのに、誰もデータキャプチャを計画していなかったため行き詰まるのを目撃したこともあります。そこで、私たちはテスト計画を作成し、オンプレミスデータのキャプチャと移行先プラットフォームへの取り込みを初日から構築し始めました。最後のクリーンアップ作業ではありません。実際にうまく行った時は、このような感じです。End-to-end の自動化、各アプリケーションに適したパス、検証を視野に入れた機能が組み込まれています。

うまく行う方法

問題は「COBOL のモダナイゼーションに AI を使うべきか」ということではありません。もちろんそうすべきです。規制当局のトレーサビリティや、プラットフォーム固有の動作の適切な処理、アプリケーションポートフォリオ全体の一貫性、数百の相互接続されたプログラムにまで適用を広げることなど、AI をどのように設定して実現するかということが問題なのです。それこそが、私たちが AWS Transform を構築するときに考え出したことです。基礎としての決定論的分析。アクセラレータとしての AI。あらゆるモダナイゼーションパターンをカバーする AWS サービス。

そして、これらの工夫が実際に機能しています。

BMW Group はテスト時間を 75% 短縮し、テスト対象範囲を 60% 拡大したことで、モダナイゼーションのスケジュールを加速させながらリスクを大幅に軽減しました。

Fiserv は、29 か月以上かかったメインフレームモダナイゼーションプロジェクトを、わずか 17 か月で完了しました。

Itau はメインフレームアプリケーションのディスカバリー時間とテスト時間を 90% 以上削減し、チームは以前の手作業よりも 75% 速くアプリケーションをモダナイズできるようになりました。

著者