re:Invent 2025: MphasisのAgentic AIフレームワークによるCOBOLレガシーモダナイゼーション
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Driving modernization using Mphasis’ Agentic AI framework (MAM219)
この動画では、Mphasis.aiのCTO Anup NairとSenior Partner Bharatが、レガシーモダナイゼーションのためのAgentic AIフレームワークを紹介している。従来のCOBOLメインフレームシステムは技術的負債を生み、イノベーションを阻害する課題がある。Mphasisは単なるコード変換ではなく、レガシーシステムからインテリジェンスを抽出しデータに変換するアプローチを採用。NeoZeta、NeoSaba、NeoRena、NeoCruxという4つの自律的・半自律的エージェントと、エンタープライズナレッジグラフOntosphereを構築した。NeoZetaはコードから知識を抽出し、NeoSabaはユーザーストーリーを生成、NeoRenaはターゲットアーキテクチャを定義、NeoCruxはコードを生成する。実際のデモでは、ポストトレード処理のCOBOLコードをJava Flinkアーキテクチャへ変換し、GPU活用による大幅な性能向上を実証。5000万行のコードを持つモダナイゼーションプログラムの期間を7年から大幅に短縮する成果を達成している。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
レガシーシステムの課題とMphasisのアプローチ：インテリジェンスをデータに変換する
私の名前はAnup Nairです。Mphasis.aiのCTOを務めています。そして私はBharatです。Mphasis.aiのSenior Partnerです。 本日は、レガシーモダナイゼーションと、レガシーモダナイゼーションのためのMphasisのAgentic AIフレームワークについてお話しします。これが今日のテーマです。このプレゼンテーションの一部として、いくつかのエキサイティングなデモもご用意していますので、気に入っていただけると嬉しいです。もし何か質問がありましたら、お気軽にオフラインで声をかけてください。ここでは質問を受け付けていないと思いますが、まあ、いいですよね?
まず最初に、少し背景をお話しさせてください。まず問題提起から始めましょう。過去25年間、私が会ってきたすべてのCIOが、この問題を抱えていました。レガシープラットフォームに触れるのはリスクが高すぎるため、十分に速くイノベーションを起こせないという問題です。 皆さんも同じような状況でしょうか? 実際、あるCIOは私にこう言いました。COBOLメインフレーム上に構築された49のコアシステムがあり、そのうちの1つに触れると、残りの48すべてにも触れなければならないと。これが私たちが解決しようと決めた問題です。
Mphasis.aiは、これらの問題を解決するために、さまざまなAgentic AIソリューションを構築してきました。Mphasisは、長年にわたってレガシーアプリケーションの構築とモダナイゼーションの経験を持っています。これについてお話ししますが、それ以上に重要なのは、私たちのソリューションの起源を本当に理解するために、そしてソリューション自体を本当に説明するために、もう少し問題を深掘りしたいと思います。
レガシーシステムの問題は、企業が何年もこれらのシステムに縛られているということです。 これらのシステムには、何年もの間、コードとビジネスロジックがコード内に埋め込まれているんです。何かをしようとするたびに、エンジニアが必要になります。 これはCOBOLで書かれていたり、Javaで書かれていたり、あるいはNaturalやAdabas、さらにはAssemblerかもしれません。そういったあらゆる種類のシステムである可能性がありますが、これを扱うには専門のエンジニアが必要なんです。
こういったエンジニアは簡単には見つかりません。市場にいないんです。 彼らは今、労働力から外れてしまっています。そのため、車輪の再発明を始め、継続的に車輪の再発明を続けることになり、大量の技術的負債を生み出し始めます。 そして今や、どんな変更もコストがかかりすぎます。なぜなら、10か所で同じことをやっているからです。そして、実際に何が起こっているのかわからないため、問題を解決するために何層も何層も何層も作り続けているのです。
さて、これについて考えてみて、その上にAIを載せることにしたとします。Agentic AIですね。イノベーションを推進するには、エージェントを配置する必要がありますよね？それが保険金請求に関するエージェントであれ、引受業務に関するエージェントであれ、あるいはどのようなエージェントを上に載せたいとしても、それがどうなるか考えてみてください。これらすべてのレガシーシステムは非常に深くモノリシックであるため、どのエージェントも生産性を提供することが極めて困難なのです。ですから、皆さんのAgentic AIの目標やゴールは、これがあるというだけで台無しになってしまうのです。これが、モダナイゼーションが必要な理由であり、あらゆるイノベーションがこれほど遅い理由なのです。なぜなら、そこにあるすべてのものに手を加えなければならないからです。
私たちMphasisでは、これについて考えて、こう言いました。これは本当に技術的なモダナイゼーションだけの問題ではないと。COBOLをJavaに、NaturalをJavaに、あるいはCやC++を何か新しいものにモダナイズするだけではないのです。それがポイントではありません。レガシーシステムからインテリジェンスを取り出して、それをデータに変換することが目標であるべきなのです。単にコードをAからBにモダナイズするのではなく。それがまさに私たちが採用したアプローチなのです。
Agentic AIフレームワークの全体像：NeoZetaからOntosphereまでの5つのエージェント
これをどのように解決できるのか、もう少しお話ししましょう。しかしその前に、通常どのようにモダナイズするのでしょうか？皆さん、これに同意されますか？まず、レガシーシステムから再学習し、それから再構想し、それから再設計し、それから再コーディングし、そして実行を開始します。これがやり方です。COBOLを取ってJavaに変換するのです。
そしてまた管理を始めます。約3年後には、それがまたレガシーになります。これが通常のやり方ですよね？そこで私たちが行ったのは、ここで少し異なるアプローチです。私たちは、自律的および半自律的なagentic AIエージェントを構築しました。人間をループに入れています。なぜなら、すべてが100%自律的だと言う人がいたら、それは冗談です。そうではありません。
そこで私たちは、ドキュメントとコードを取り、NeoZetaと呼ばれるエージェントを構築しました。このエージェントは実際にすべてを読み取り、すべてを人間が理解できる知識に変換します。どうやってそれを行うのか？ドメイン知識、ドメイン知識を重視して、それを実現します。なぜなら、私たちはそれらをエンコードしたからです。私たちはナレッジグラフを作成しました。そして考えました。今、ナレッジグラフがあるけれど、これを使って新しいシステムを作るにはどうすればいいのか？何をすればいいのか？そこからユーザーストーリーを生成するのです。
そこで私たちは別のエージェントを作成しました。NeoSabaと呼んでいます。このエージェントは、学習したすべての内容を取り込み、ユーザーストーリーに変換し、ガバナンスに焦点を当て、コンプライアンスに焦点を当て、プロセス、ビジネスプロセスに焦点を当てます。SABAはsemi-autonomous business analyst、つまり半自律型ビジネスアナリストの略です。これを使ってビジネスアナリストに作業してもらいます。そして、ここから作成したものをすべて変換し、ナレッジグラフに戻します。
では、次のステップは何でしょうか?再アーキテクト方法を再構想します。私たちは別のエージェントを作成し、NeoRenaと名付けました。これは学習したすべての内容を取り込み、ターゲット状態のアーキテクチャを定義するのを支援するエージェントです。このターゲット状態のアーキテクチャは、お客様、クライアント向けにカスタマイズ可能です。そして、ここから作成するすべてのものは、エンタープライズ標準に準拠します。カスタマイズ可能な理由は、エンタープライズ標準に確実に準拠させる必要があるからです。
それを作成したら、すべてのアーキテクチャが完了します。それを取り込んで、書き直します。私たちはNeoCruxというエージェントを作成しました。これはすべてを取り込み、プロンプトを可能にし、企業内で利用可能なコーディングエージェントを使用して、そこからコードを書き始めます。運用まで継続しますよね?なぜやらないのでしょうか?すべてを構築し、本番環境に投入し、Cruxなどを通じてテストしました。今、本番環境に投入し、運用も実行することになります。
しかし、これらすべてを通じて、私たちは結合組織を構築しました。全体から知能を抽出し、エンタープライズナレッジグラフを作成しました。このエンタープライズナレッジグラフは単なるデータベースではありません。ナレッジグラフはデータベースですが、これは単なるデータベースではありません。意味を持っています。お客様のドメインに接続されているため、エンタープライズの意味を持っています。私たちはこれをOntosphereと呼んでいます。そして、その上にレイヤーを使用して全体をオーケストレーションし、可能な限り自律的にできるようにしました。これがMphasisのモダナイゼーションへのアプローチです。
さて、それらのいくつかは自律的で、いくつかは半自律的であることがわかるでしょう。AIが進歩し、コンテキスト能力が成長するにつれて、これはますます自律的になり、本質的に企業のライブインテリジェンスを作成することになります。それでは、今日デモでご覧いただくものですが、NeoZetaがコードから知能を抽出するのをご覧いただきます。NeoSabaがビジネスユーザーにユーザーストーリーを作成させるのをご覧いただきます。NeoRenaをご覧いただき、NeoCruxをご覧いただきます。そして、AI opsは時間が足りなかったのでご覧いただけませんが、Ontosphereも少しご覧いただけます。つまり、5つのものをご覧いただきます:Zeta、Saba、Rena、Crux、そしてOntosphereです。
実践デモンストレーション：COBOLからJava Flinkへのモダナイゼーション事例
それでは、デモに切り替えて、Bharatに一連の機能全体をご説明いただきます。まず最初にOntosphereについてお話しします。なぜなら、ここが情報の中核となる場所だからです。システム内のすべての知識、それがコードであれドキュメントであれ、このOntosphere上のデータに取り込まれることになります。
現在、私たちは金融業界、保険業界、その他の業界向けに構築されたいくつかのドメインオントロジーを使用しています。また、エージェントを通じて機能するいくつかのエンジニアリングオントロジーも導入しています。これが、システムへの多くのモデリングが行われる基盤となります。
最初のエージェント、NeoZetaに移りましょう。ご覧のように、プログラムを選択し、ケイパビリティを選択しました。私たちは、ポストトレード処理という非常に複雑なケイパビリティを取り上げました。なぜなら、ここでは4時に停止するプロセスがあるからです。数百万件のトレードを処理し、連邦当局にファイルを送信しなければなりません。私たちはこの問題を取り上げ、これを解決する唯一の方法は、レガシーCOBOLでコーディングされたこれらの各プロセスから多くのインテリジェンスを取得することだと考えました。これがお見せしているCOBOLの例です。そして、それをリバースエンジニアリングし、エージェントを使用してFIBOベースのアーキテクチャへのモダナイゼーションを支援します。CPUとGPUの両方でどのように実行し、パフォーマンスがどのように変化するかをお見せします。
デモを続けます。ケイパビリティを選択しました。ドキュメントや異なるアセットであるファイルをアップロードする機能があります。COBOLコピーブックをアップロードし、ご覧のように、ここにドメインモデルもアップロードしました。これらが表示されているプログラムで、これがRelearnエージェントを使用してアップロードしたドメインモデルです。実際に、すべてのプログラムまたはケイパビリティ全体を再学習しています。ご覧のように、実際にQUANTILESというプログラムをコピーブックと一緒に選択し、それをリバースエンジニアリングしています。データディクショナリを生成する機能があります。さて、私たちは何も情報を入力していませんが、システムから相当量の情報を引き出しており、実際の機能属性とのマッピングを開始しているのがわかります。
また、生成されるドキュメントもお見せしています。ドキュメントには特定のフォーマットがあります。サマリーを生成し、次に各ビジネスルールごとに、多くのデータ要素を提供し始めます。ご覧のとおりです。ロジック、インプット、影響を受けるデータを提供し、さらに特定のコードを再学習する際に必要となる他の多くの処理要素を提供します。
さて、最も重要な部分は、システムが非常に正確にそれを実行したことをどのように検証するかということです。私たちはLLM as a Judgeと呼ばれるものを導入しており、これはリバースエンジニアリングされたすべてのルールに対して信頼度スコアを提供してくれます。ご覧のように、ルールの1つが平均カバレッジ85パーセントを獲得していることがわかります。私たちにとって85パーセントは平均的です。95パーセント以上のものが、より良いものとしてカウントされます。 ここにはhuman-in-the-loopインターフェースがあります。ここで修正を行うことができます。最初の10万行のコードは通常このような修正が必要ですが、その後の100万行のコードについては、Relearnエージェントから95パーセントの精度が得られる自動化された方法となります。
データディクショナリを作成し、ビジネスルールを作成し、ビジネスルールの検証もご覧いただきました。3番目の部分は、すべてをOntosphereに変換することです。これはナレッジグラフですが、それをデモンストレーションさせてください。 これはLLM as a Judgeからのいくつかの属性をお見せしているだけです。今からナレッジグラフに移ります。実際には、ナレッジグラフに行く前に、機能全体に関する情報も生成されています。 プログラムごと、または機能全体を扱うモデルがあります。通常、実行中の大きなジョブがあり、 その中に複数のプログラム、複数のプロセスがある場合、すべてのインテリジェンスを引き出すという観点から、このようなビューを見たいと思うでしょう。
最後に、3番目のステップはそれをナレッジグラフに変換することです。ご覧いただくと、リバースエンジニアリングされたプログラムの1つを選択しており、それに関連付けられているドメインモデルが表示されています。関数、属性、情報をダブルクリックすることができ、これはSMEが検証目的で使用できるものです。基本的に、先ほどご覧いただいたすべては最初のエージェントでした。ここが情報が2番目のエージェントに来る場所です。
すべての情報はビジネスプロセスの一部として配置されます。これは先ほどご覧いただいたグラフとまったく同じものです。今、ビジネスワークフローアイテムとして表示されており、これを活用して見ることができ、上部セクションに表示されるアプリケーションの再構想を始めることができます。ビジネスルールを選択し、複数のビジネスルールを組み合わせて、新しいルールを作成することもできます。そのような機能を提供しています。
上部に表示されているのは、基本的にアプリケーションの全体的なアジャイルリモデリングです。完全に再構想しています。私たちが持っているのはリフトアンドシフトモデルではありません。定義しており、BSAがエピック、フィーチャー、ユーザーストーリーを定義するのを支援しています。そして、すべてのユーザーストーリーに対して、INVESTスコアを通じてユーザーストーリーの品質に関する評価が行われ、さらに受け入れ基準を生成し、より多くの情報を生成できるプロンプトメカニズムがあります。ここにGherkin出力が表示されています。実際にこの時点でBDDを作成しているので、品質は基本的にこの時点から始まります。これは、INVEST基準を満たさない場合に、さまざまなルールにさらに分解できる形式で情報を生成できるプロンプトです。
それでは、時間の都合上、3番目のエージェントに移ります。3番目のエージェントの観点から、ここで重要なのは再設計またはリアーキテクトすることです。 ここで必要なのは3つ、実際には2つのことです。1つはリバースエンジニアリングの観点から実行すべきステップに関するプレイブック、そして2つ目は使用する標準です。両方を入力として与えており、これをどのように行うかお見せしますが、 論理モデルであれ物理モデルであれ、シーケンス図であれ、 活用すべきオブザーバビリティパターンであれ、すべての情報を提供し始めました。標準として入力されたすべてのものが、Rainaという3番目のエージェント、Anoopが話していたエージェントによって引き出されています。 そうですね。
この特定のエージェントの仕事は、全体のコンテキストを構築し、 開発の観点から次のエージェントのためにプロンプトを準備することです。ご覧のように、今生成しています。Java Flinkモデルを使用して生成する必要があるという情報を入力しました。時間の都合上、実際にどれだけ速くできるかというステップをお見せしました。新しいデザインを作成しようとしており、 プレイブックと使用すべき標準の両方を与えています。データエンジニアリングアーキテクチャを使用しています。 Flink用の標準のプレイブックを与えて、全体のコンテキストを生成しています。つまり、すべての情報が その観点からほぼ生成されます。
次に4番目のエージェント、コード生成エージェントに移ります。このエージェントはすべての情報を取得し、Java Flinkアーキテクチャの観点からコードを生成します。ご覧いただいているのは、これがGPU上で実行された場合と CPU上で実行された場合の例です。タイミングの面で大きな違いがあることがわかります。複数のトレードセットに対してモデル化した場合、例えば20,000トレードから100,000トレードに増やした場合、CPUの観点とGPUの観点でコストがどうなるかを示し、ジョブごとの判断を支援します。これがお見せしたかったものの1つです。デッキに戻りましょう。
皆さん、これがこれまで見てきたものです。結果の観点から、これを達成しました。 約5000万行のコードを持つ典型的なモダナイゼーションプログラムは約7年かかります。私たちはこのような進捗を達成しました。最後の無限大マーク、それが何か分かりますか？それは、すべてのインテリジェンスがデータに移行し、永遠にあなたと共に存在するという事実です。もうレガシーを持つことはありません。そういうことです。これが 私たちが他の誰とも違う点をまとめた方法です。AからBに移行する人はたくさんいますが、インテリジェンスを抽出して、もうレガシーを持たない状態を提供できる人はほとんどいません。それが私たちがカバーしたかったことです。
私たちのエージェントは実際にDatabricks上で動作しています。ですから、かなり高いスケールアップが可能です。その観点から常に測定し、監視してきました。ありがとうございました。以上が私たちの内容でした。時間になりました。本当に ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion