レガシーモダナイゼーション：メインフレーム、ERP、ニッチ言語向けエージェント

AIエージェントによるレガシーモダナイゼーション：メインフレーム、ERP、ニッチコード

現代の企業は、COBOL（メインフレーム）、SAP ABAP、PL/SQL、VB6といった言語で書かれた数十年前のソフトウェアに依存していることがよくあります。これらの古いシステムは変更が難しく、維持費用が高いのが現状です。幸いなことに、新しいAIコーディングエージェントと設計パターンにより、レガシーシステムを段階的に最新化することが可能になりました。この記事では、AI駆動型ツールが古いコードの解析と書き換えにどのように役立つかを探り、レガシー機能を段階的に置き換えるための実績のあるパターン（インターフェースファサード、「ストランディング」アプローチ、自動テスト）について説明します。また、データリネージ、リスク管理、ロールバック計画、そして現実世界でのROIと落とし穴についても触れます。初心者でも始めることができます。AIはレガシーコードを理解しやすいドキュメントや新しいコードに変えることでコーディングを「解き放つ」ため、誰でも古いシステムの最新化に向けて最初の一歩を踏み出すことができます。

レガシーコードのためのAIコーディングエージェント

AIコーディングエージェントは、機械学習（多くの場合、大規模言語モデル）を使用してコードを読み取り、分析し、さらには書き換えるツールです。これらは、チーム内の誰もが十分に知らないレガシー言語を扱うことができます。例えば、富士通の新しいKozuchi AIツールは、COBOLプログラムを分析し、人間が読める設計書を瞬時に生成できます（global.fujitsu）。IBMのWatsonX Code Assistant for Zは、AIを使用してCOBOL機能を高品質のJavaに変換し、開発者を各ステップでガイドします（www.ibm.com）。また、MicrosoftのオープンソースLegacy Modernization Agents（GitHub上）は、Azure OpenAIとGitHub Copilotを使用してCOBOLを解析し、同等のJavaまたは.NETサービスを生成します（github.com）。これらのエージェントは、古いコードに隠されたビジネスロジックとデータフローを捕捉し、それらを基盤として新しいコンポーネントを構築するのに役立ちます。

AIエージェントの主な魅力は、誰でも使い始められることです。コードを手書きする必要はなく、プロンプトを発行するか、専用ツールを使用します。例えば、初心者は小さなCOBOLまたはVB6ルーチンをChatGPTにコピーし、平易な英語での要約や疑似コードを依頼することができます。エージェントはコード構造を「理解」し、現代的な同等物を示唆することができます。これにより、モダナイゼーションが民主化され、非専門家でも手動でのコードレビューなしにレガシーロジックを探索できます。多くのベンダーがAIエージェントを使いやすいプラットフォームに統合しています。CapgeminiのSAPモダナイゼーションソリューションは、生成AIを使用してABAPコードを自動的に文書化し、テストスクリプトと変換にかかる労力を半減させています（www.sap.com）。重要な注意点は人間による監視です。エージェントは作業を高速化しますが、開発者は出力を検証する必要があります。要するに、AIコーディングエージェントはレガシーシステムの発見とマッピングを加速し、数週間の手動分析を数日または数分に短縮します（blog.naitive.cloud）（global.fujitsu）。

インターフェースマッピング：アダプター、ファサード、オーバーレイ

モダナイゼーションの課題の一つは、新しいコンポーネントとレガシーコア間のインターフェースをマッピングすることです。一般的な解決策は、インターフェースアダプターまたはファサード層を使用することです。例えば、ERPシステムは「記録システム」として残ることが多いため、新しいUIやサービスはクリーンなAPIを介してそれらと通信する必要があります。オーバーレイアーキテクチャ（または「エクスペリエンス層」）は、ユーザーと古いERPの間に位置します。これは、現代的な呼び出しを古いシステムのインターフェースに、またはその逆に変換します（sysgraft.com）（sysgraft.com）。このアダプター層は、データマッピング、認証変換、エラー処理、バッファリングを処理します（例えば、レガシーフィールド名を新しいドメインモデルにマッピングしたり、古いシステムが遅いときに書き込みをキューに入れたり、エラーコードを標準化したりするかもしれません）。このコードを分離することで、ファサードの背後にあるERPを後で書き換えたり置き換えたりしても、フロントエンドを変更する必要がありません。このパターンにより、改善された画面やサービスを段階的に展開でき、アダプターが異なる世界間の変換を行います（sysgraft.com）（aws.amazon.com）。

もう一つのアプローチは、エントリーポイントとしてAPIゲートウェイまたはファサードを使用することです。AWSは、オンプレミスシステム向けのストランディングパターンでこれを説明しています。レガシーアプリケーションの前にAPIゲートウェイを配置し、その背後に新しいマイクロサービスを作成します。すべての呼び出しは同じAPIファサードを通過し、リクエストがまだ古いモノリスによって処理されているか、新しくデプロイされたサービスによって処理されているかに関わらず一貫性が保たれます（aws.amazon.com）（aws.amazon.com）。これにより、システムの各部分が古いモノリスを「締め付ける」間も、顧客に対して一貫したインターフェースが維持されます。時間とともに、より多くのエンドポイントが新しい実装にリダイレクトされます（例えば、最初は古いシステムからデータを読み取るだけで、後で新しいサービスに新しいデータを書き込むなど）。

実際には、インターフェースマッピングはこれらのアイデアを組み合わせることが多く、レガシーシステムの前にアダプター層を展開し、新しいAPIまたはWeb UIを公開します。新しいモジュールは、レガシーデータベーステーブルや画面に直接話しかけるのではなく、アダプターを呼び出します。これにより、古い部分と新しい部分が分離され、呼び出しのリダイレクトが容易になります。新しいサービスがまだ準備できていない場合、アダプターはトラフィックをレガシーコードにプロキシします。新しいサービスが失敗した場合、トラフィックは古いシステムに戻すことができます（ロールバックについては後述）。この「シム」を構築することで、すべてを壊すことなく、一度に一つの機能のまとまりを最新化できます（martinfowler.com）。

ストランディング・フィグ移行パターン

関連する高レベルのパターンは、移行のためのストランディング・フィグ（絞め殺しのイチジク）アプローチです。マーティン・ファウラーによって提唱されたこのパターンは、徐々に木を包み込み、最終的に木を置き換えるツタに例えられます（martinfowler.com）（aws.amazon.com）。一度に大規模な書き換えを行うのではなく、古いシステムの機能を段階的に新しいものに置き換えます。初期段階では、レガシーコードと並行して（またはその上で）実行される個別のサービスとして、小さな機能強化を追加します。時間が経つにつれて、これらの新しいサービスはより多くのビジネスロジックを吸収し、最終的に古いシステムは例外処理のみを行うようになります。新しい機能、さらには古い機能の一部も新しいコードに移行され、古いモノリスはついに引退できます（martinfowler.com）（martinfowler.com）。

ファウラーは、ストランディングによるモダナイゼーションの4つのステップを概説しています：（1）望ましい結果を理解する。（2）問題を細分化する。（3）各部分を成功裏に提供する。（4）それを維持するために組織を変更する（martinfowler.com）。実際には、これは主要なビジネス機能（例えば、受注入力）を特定し、それを新しいサービス（Node.js、.NETなど）で再構築し、アダプターコードを記述して、注文の呼び出しがレガシープログラムではなく新しいサービスに入るようにすることを意味するかもしれません。部分的に行われるため、リスクは軽減されます。各新しいピースはすぐに稼働し、価値を提供できます（martinfowler.com）。例えば、AWSの事例研究では、最初に新しいAPIファサードを介してシンプルな「読み取り専用」クエリのみを処理し、その後、一部のユーザー向けに書き込み操作を追加したアプリケーションがありました（sysgraft.com）。すべての段階で、システムはユーザーのために機能し続けました。

AIコーディングエージェントは、これらの新しいコンポーネントを迅速に作成またはリファクタリングすることで、ストランディング移行を支援します。例えば、エージェントは「従業員ボーナス計算」に関するレガシーCOBOLロジックを読み取り、同等のJavaまたはPython関数を生成できます。そして、それをストランディングパターンに基づいてサービスとしてデプロイします。成功の鍵は、移行が完了するまでのみ存在するコードである過渡的なインターフェースを構築することです。多くのチームは、新旧をつなぐ余分な「無駄な」コードに抵抗しますが、この過渡的なロジック（ルーティング、データ同期など）こそが、低リスクで段階的な移行を可能にするものです（martinfowler.com）（aws.amazon.com）。

レガシーコードのための自動テストハーネス

移行の失敗から得られる教訓の一つは、認識されていないエラーが書き換えを麻痺させる可能性があることです。安全に最新化するには、レガシーシステムの周りに包括的な自動テストハーネスが必要です。実際には、これは複数のレベルでテストを記述し、ビルドパイプラインに統合することを意味します。

単体テスト（Unit tests）： 個々の関数またはモジュールを検証します。レガシーコードでは、ビジネスロジックが大きなルーチンに隠されている場合があります。エージェントは単体テストを提案することで役立ちます。例えば、AIエージェントにレガシー関数に対する入出力例を提案するように依頼するなどです。ツールやフレームワーク（例：最新のCOBOLまたはPL/SQLテストランナー）は、これらのテストに対してレガシーコードを実行できます。
結合テスト（Integration tests）： モジュールが正しく連携するかどうかを確認します。例えば、新しいオーバーレイがERPデータベースに書き込む場合、結合テストはエンドツーエンドのフロー（UIでの入力からERPでの更新まで）がまだ機能することを確認します。エージェントは、インターフェース定義の解釈に基づいてリクエストを自動生成することで支援する場合があります。
エンドツーエンド（E2E）テスト： 完全なユーザーワークフローをシミュレートします。移行前に、操作の黄金シーケンス（ログイン、請求書の作成など）を確立します。Cypress/Playwrightのようなクローラーやフレームワークは、これらのフローに対するGUIまたはAPI呼び出しを自動化できます。これは非常に重要で、単体テストでは捕捉できない問題を検出します。
回帰テスト（Regression tests）： 安全ネットです。機能をリファクタリングまたは切り替えるたびに、スイート全体を実行して、他の何も壊れていないことを確認します。特性評価テスト（古典的なレガシー手法）は特に役立ちます。これは、特定の入力に対するレガシーコードの現在の出力を記録し、新しいコードがその動作と一致することをアサートします（eden-technologies.eu）。言い換えれば、テストはコードが実際に何をするかを捕捉するため、なぜそれをするのかを知る必要はありません。

専門家は、回帰テストが最も重要な層であると強調しています（polcode.com）。変更を行う前に、コア機能がカバーされているテストがあることを確認してください。まず、ミッションクリティカルなフロー（注文、請求、承認など、収益やコンプライアンスに直接関連するもの）を保護することから始めます（teamvoy.com）。次に、脆弱な領域や変更の多い領域（過去に多くのバグがあったモジュール）にテストを拡大します。一度にすべてを行う必要はありません。スイートを反復的に構築してください。例えば、テスターがバグを発見したら、そのシナリオを中心に新しいテストを作成します。数ヶ月間の継続的な努力により、骨組みだけのスイートでも、主要な回帰を捕捉するのに十分なまでに成長させることができます（polcode.com）（eden-technologies.eu）。

AIはテストの側面も自動化できます。例えば、AIテストプラットフォーム（一部のCI/CDツールなど）は、自然言語仕様から意図ベースのエンドツーエンドテストを生成できます（polcode.com）。エージェントはレガシーコードとドキュメントをスキャンし、テストケースを提案できます。SAPのモダナイゼーションでは、Capgeminiのツールはテストスクリプトの生成を自動化し、約40%の労力削減を約束しています（www.sap.com）。そして、Naitiveの業界分析によると、テストの作成はレガシープロジェクトの40〜50%を占めることが多いものの、AIによって大幅に削減できるとされています（blog.naitive.cloud）。概念的には、COBOLジョブログやレガシーUIフローをLLMに供給して、テストのためのアクションのサンプルシーケンスを取得することができます。いずれにせよ、人間はAIの提案を検証する必要があります。目標は、再統合前に新しいコードが古い動作と一致するという確信を得ることです。

データリネージとリスク管理

レガシーモダナイゼーションはコードだけではありません。データも移動または一貫性を保つ必要があります。データリネージとは、すべてのデータ要素がどこから来たのか、どのように変換されたのかを追跡することです。明確なリネージがなければ、移行されたシステムが正確でコンプライアンスに準拠していることを保証することはほとんど不可能です。例えば、メインフレームのデータ（しばしばEBCDIC形式）がモダンなプラットフォームに移動される際、企業はフォレンジックハッシュマッピングとカストディチェーンプロセスを要求します（www.solix.com）（www.solix.com）。実際には、これは各段階でデータの暗号化ハッシュを計算し、改ざんされていないことを証明できるようにすることを意味します。また、すべてのETLステップ（すべての抽出、変換、ロード）が監査可能であることをログに記録することも意味します。これがなければ、監査人や規制当局は新しいシステムを信頼しないかもしれません。

データ品質は大きなリスク領域です。現代のガイドでは、ほとんどの失敗したレガシーデータ移行はテクノロジーによるものではなく、「汚い」データがそのままコピーされたことによるものだと警告しています（www.taleofdata.com）。重複レコード、サイレントなフィールド削除、または古いシステムに忍び込んだ一貫性のない形式は、対処しないと新しいシステムを台無しにする可能性があります。バイトを移動するだけのETLツールに頼るのではなく、移行前にデータプロファイリングとクレンジングを実行することが不可欠です。チームは次の質問をすべきです。重複する顧客レコードを特定し、それらをどのようにマージするかを決定しましたか？ すべての「重要な」フィールド（めったに使用されないものも含む）が新しいスキーマにマッピングされますか？ 後で移行エラーを発見した場合に備えて、明確なロールバック計画はありますか？ （www.taleofdata.com）。

リスク管理は、各ステップでデータを検証することから始まります。管理されたバッチで移行します。例えば、まず5年分の取引履歴を移動し、レポートの正確性を確認してから、残りを進めます。照合スクリプトを使用します。各バッチの後、行数とチェックサムが一致することを確認します。不一致が発生した場合は、先に進むのではなく、一時停止してデータをクリーンアップします。失敗したバッチを再実行することなく元に戻せるように、ソースデータのバックアップ（またはトランザクションログ）を維持します。高リスクのケースでは、新しいシステムが完全に確認されるまで、ソースとターゲットをしばらく並行して実行（デュアルライト）し、すべての新しい更新が両方のシステムに送信されるようにすることさえあるかもしれません。基本的に、本番環境で行うようにガードレールを構築します。監視、アラート、迅速なロールバックトリガーなどです（www.solix.com）（www.taleofdata.com）。

ロールバック戦略

綿密な計画にもかかわらず、移行では問題が発生する可能性があります。影響を限定するために、明確なロールバック戦略は不可欠です。正確なアプローチは、リスク許容度とダウンタイムウィンドウによって異なります。一般的なオプションを以下に示します。

フェイルセーフレプリケーション： 古いデータベースを新しいシステムと同期させ続けます。例えば、双方向の変更データキャプチャ（CDC）を使用します。切り替え後も、新しいシステムから古いシステムへのレプリケーションを継続します。問題が発生した場合、書き込みを失うことなく古いシステムを即座に再起動できます（www.cockroachlabs.com）。これはクラウド移行（例：AWS DMS、CockroachDBフェイルバック）で使用されます。
デュアルライトまたは並行実行： 試用期間中、すべてのトランザクションをレガシーシステムと新しいシステムの両方に書き込むようにアプリケーションコードを変更するか（または統合ミドルウェアを使用します）（www.cockroachlabs.com）。新しいシステムが失敗した場合、クライアントをレガシー環境にリダイレクトするだけです。デュアルライトはロールバック時に新しいデータが失われないことを意味しますが、書き込みオーバーヘッドと複雑さが2倍になります。
手動切り替え + スナップショット： リスクが非常に低いケースでは、レガシーデータベースの最終スナップショットを取得し、ユーザーを新しいシステムに切り替え、問題が発生した場合は手動でのデータ照合に頼ります。これは、潜在的な不整合を許容でき、それらを修正する時間がある場合にのみ許容されます。
機能フラグ / 部分的な切り替え： ストラングラーアプローチでは、設定を通じて新しいものと古いものへの処理を制御します。新しいコンポーネントで問題が発生した場合、それをオフに切り替える（リクエストをレガシーにルーティングする）ことができ、コードのロールバックは不要です。これは、APIレベルでの非常にきめ細かいロールバックのようなものです。

方法に関わらず、ロールバック基準とランブックを事前に定義します（www.cockroachlabs.com）。例えば、「エラー率がXを超えた場合、または重要なデータがチェックに失敗した場合、ロールバック手順を開始する」などです。最近のレビューでは、ロールバックの複雑さをニーズに合わせることが強調されています。データ損失ゼロが重要である場合、双方向レプリケーションまたはデュアルライトを実装します。 軽微な損失が許容できる場合は、手動フォールバックで十分かもしれません（www.cockroachlabs.com）。重要なのは、本番切り替え前にロールバック手順をテストし、チームがプレッシャーの下でそれを実行する方法を知っていることです。

モダナイゼーションのROI

モダナイゼーションのコストを心配するのは当然です。しかし、現実世界の事例では、ROIは非常に高いことが示されています。レガシーシステムは、古いコードの保守だけでIT予算の60〜80%を消費することがよくあります（blog.naitive.cloud）（blog.naitive.cloud）。この継続的な負担と比較すると、一度のアップグレードは迅速に元が取れます。業界分析によると、AIアシストによるモダナイゼーションは、プロジェクトコストを**約70〜80%**削減できるとされています。例えば、5万行のアプリケーションを手動で変換すると24万ドルの費用がかかる可能性がありますが、AIツールを使用すると5.7万ドルに下がる可能性があります（約76%の削減）（blog.naitive.cloud）（blog.naitive.cloud）。この計算には、人件費、品質保証、ツール費用が含まれます。実際には、多くの企業が200〜400%の5年間ROIを報告しており、多くの場合1〜2年で損益分岐点に達しています（blog.naitive.cloud）（blog.naitive.cloud）。

具体的な成功事例は豊富にあります。デロイトは、米国のある州が、COBOLの養育費システムにおける2億ドル、10年間の書き換えを、クラウド上でJavaへの自動リファクタリングを使用することで回避したと説明しています（www2.deloitte.com）。彼らは代わりに18ヶ月で完了し、新しいサービスの予算を確保しました。オランダの保険会社NN Groupは、1000万行以上のCOBOLコードをJavaに変換し、ITプラットフォームコストを80%削減し、3年未満で投資を回収しました（blog.naitive.cloud）。小規模なケースでも、AIアシスタントは発見とコーディングを加速できます。あるベンチマークでは、レガシー移行がエージェントを使用することで8〜11ヶ月から約2ヶ月に短縮され、5万行のコードベースで人件費が約18.3万ドル削減されたと引用されています（blog.naitive.cloud）（blog.naitive.cloud）。

もちろん、ROIは継続的な保守費用の削減、ダウンタイムの減少、新機能の「機会費用」といった要因に依存します。AIエージェントが単純作業を自動化することで、熟練した開発者は古いシステムを管理するのではなく、新しい製品を構築することに専念できます。また、AIがレガシーロジックを処理できるため、COBOLやVB6の専門家を慌てて探す企業が少なくなり、人材リスクも軽減されます。総合的に見て、組織はフルスタックのモダナイゼーションをこれまでよりも手頃で迅速に行えるようになっています。特に段階的に行う場合です。

落とし穴と学んだ教訓

AIとパターンには利点がありますが、注意すべき点もあります。第一に、AIのハルシネーションとエラーは現実のものです。生成ツールは、もっともらしく見えるが間違っているコードやドキュメントを作成することがあります。富士通のソリューションは、独自のナレッジグラフオーバーレイを使用して、設計ドキュメント生成時のハルシネーションを削減することでこれに対処しています（global.fujitsu）。プロジェクトでは、AIの出力を既知の参照やサンプル実行に対して常に検証してください。

第二に、テストは依然としてボトルネックです。コード変換が速くても、テストはスケジュールの40〜50%を占めることがよくあります（blog.naitive.cloud）。多くのチームはこれを過小評価しています。堅牢なCIパイプラインと、場合によってはAIアシストによるテスト生成に時間を割く必要があります。テストカバレッジで手を抜かないでください。レガシーコードは本質的に脆く、不十分なテストは失敗の一般的な原因です。

第三に、データの問題がプロジェクトをしばしば頓挫させます。前述のとおり、データ品質が悪い場合、技術的な移行の成功は無意味です。データのプロファイリングとクレンジングを怠ると、多くの移行で新しい壊れたシステムが生成されました（www.taleofdata.com）（www.taleofdata.com）。データチェックリストに投資してください。重複排除し、すべてのフィールドをマッピングし、ビジネスステークホルダーを含めて「クリーンな」データが何を意味するかを定義します（www.taleofdata.com）。稼働前に照合レポートを作成し、早い段階で間違いを捕捉できるようにします。

第四に、スコープクリープと機能の不一致はチームを驚かせることがあります。レガシーシステムには、隠れたビジネスロジックやハックが組み込まれていることがよくあります。古いシステムの動作が完全に理解されていると仮定しないでください。特性評価テスト（前述）を使用して現在の動作を捕捉し、ドメインエキスパートを巻き込んで珍しいケースを説明してもらいます。UIやAPIを移行する際は、新しいインターフェースが同等であることが証明されるまで古いインターフェースが残るフォールバックを計画してください。

最後に、人とプロセスの変化が重要です。ストランディングのようなパターンには、組織的な賛同が必要です。移行期間中に新旧が共存できるように、チームは新しいアジャイルプラクティスやチーム構造を採用しなければなりません（martinfowler.com）。ビジネス部門が段階的な展開を受け入れ、テスターが新しいツールを学ぶことは、コードと同じくらい重要です。ファウラーが指摘するように、文化的な変化がなければ、新しいシステムは古いシステムと同じくらい混乱してしまう可能性があります（martinfowler.com）。

始めるための第一歩

AIモダナイゼーションを自分で試したい読者のために、実践的な始め方をご紹介します。

小さなモジュールを棚卸しする。 独立した機能（例：単一のCOBOLプログラム、ABAPファンクショングループ、またはVB6フォーム）を選びます。そのソースコードとサンプル入力を収集します。
AIに説明させる。 ChatGPTやAIコードアシスタントのようなツールを使用します。コード（または主要な抜粋）を貼り付け、要約または疑似コードを要求します。例えば、「このCOBOLコードのビジネスロジックを説明してください：…」。エージェントはループ、計算、データ使用を平易な言葉で強調します。これにより、人間の理解とレガシー構文の間の橋渡しができます。
テストまたはドキュメントを生成する。 そのコードのテストケースを作成するようにエージェントにプロンプトを出します。または、そのモジュールが行うことの図やAPIスキーマを出力するように依頼します。初期の単体テストや設計ドキュメントを無料で手に入れることができます。
ハーネスを構築する。 テスト入力で古いコードを呼び出し、出力をチェックする単純なスクリプトでも、ベースラインを確立できます。エージェントが出力を提供した場合、それが実際のプログラムと一致するかどうかを確認します（このチェックは、AIのエラーを発見する訓練にもなります）。
新しいインターフェースを計画する。 この機能が新しいアーキテクチャでどのように存在するかを決定します。RESTマイクロサービスになりますか？クラウド関数になりますか？データコントラクトをスケッチします（エージェントに「このレガシー出力をJSONフィールドに変換してください。」と依頼できます）。
サンプル移行ツールを使用する。 例えば、MicrosoftのLegacy-Modernization-Agentsリポジトリには、COBOL用のデモエージェントが含まれています。または、PhoenixCode（Delphi、PowerBuilder、VB6などをサポート）のようなツールの試用版を試して、お使いの言語の自動変換を確認してください。
チームを巻き込む。 AIの出力を同僚やビジネスアナリストと共有します。ドメインエキスパートと検証します。「この翻訳は正しいですか？」 反復を続けます。

最初の次のステップは、単なる実験です。重要でないレガシーコードの一部を選び、AIツールにかけてみてください。意味のある変換や説明が得られるまでプロンプトを試してみてください。この低リスクの実験は、これらのエージェントの可能性と癖の両方について洞察を与えます。そこから、正式なストランディングフェーズに拡大できます。最初に「絞め殺す」機能を定義し、必要なアダプターコードを記述します。

結論： レガシーシステムのモダナイゼーションは、もはや懐中電灯で40年前のCOBOLを読むことや、希少な専門家を雇うことを意味しません。AIコーディングエージェントとスマートなアーキテクチャパターンは、初心者でも進歩できる道を開きました。漸進的な手法（APIファサード/オーバーレイとストランディング移行）を使用し、強力な自動テスト（特性評価テストを含む）を構築し、データ検証とロールバックを計画することで、組織は古いシステムを安全に変換できます。研究が示すように、コストが半分以下になるなど、ROIは劇的である可能性があります。鍵となるのは規律を守ることです。AIの出力を検証し、ビジネスユーザーを巻き込んで正しさを定義し、テストやロギングのような「配管」をスキップしないことです。小さく始めて、反復し、最新化する各部分から学びましょう。これらのツールとプラクティスがあれば、30年前のシステムも俊敏で将来に対応できるものに進化し、次の担当者が自信を持って新しい最新化されたシステムを連携させることができるでしょう。