2026AI原生时代的现代化转型报告理想愿景与质量保障理念

2第1章基幹システムを取り巻く環境の変化1.従来のモダナイゼーションの動機2.AI-Native時代における基幹システムの環境変化3.モダナイゼーションの問いの転換第2章AI-Native時代に基幹システムが目指すべき姿1.AI活用を踏まえた基幹システムの目指すべき姿2.基幹システムが満たすべき要求事項3.モダナイゼーションの方向性1.基幹システムの現状2.手法の選択肢と評価基準3.リビルドが4つの要求に構造から応えられる理由4.残されたコストの壁31.リビルド×現新比較試験による解決策の全体像2.AI-Native開発の考え方を適用したリビルド3.AI-Native開発の考え方を適用した現新比較試験第5章AI-Native時代の新たなモダナイゼーション戦略1.これまでのモダナイゼーションの現実解2.リホスト×リビルドによる2段階のモダナイゼーション3.モダナイゼーション後に始まる業務変革ループ4.モダナイゼーションの進め方への示唆1.NTTDATAの取り組み2.目指す姿への最初の一歩4付録A付録B付録A付録B参考文献5業務へのAI活用が本格化し、AIエージ者」は人からAIへ広がり、モダナイゼーシステムではなく、この4つの要求を満たしなが再設計を含む一連の工程をAIが一気通貫で実行ストを大幅に低減できる可能性が開ける。一方、このリスクには、「動いているシステムが正解で現実に立ち、現行システムを「正解」として新旧移行時の一度きりで終わらず、移行後も改修のたルドによる2段階のモダナイゼーションを提示移行の完了ではなく、品質ゲートに守られなが素早く作り変え続けられる状態の獲得であり、業務プロセスをAI前提に再設計する業務変革あわせて、目標の設定からロードマップ策定ま6第1章基幹システムを取り巻く環境の変化基幹システムの利用者と開発者が、人からAIへ広がる。問いは「いかに企業の基幹システムを最新の技術に対応させて作り変えるモダナイゼーションは、決して新しいテーマではない。本業務へのAI活用が本格化するいま、モダナイゼーションを検討する際の問いが「いかに移行するか」から「AI目指して作り変えるか」へ変わりつつある、ということである。従来のモダナイゼーションは、動機こそ多様で従来のモダナイゼーションの最も大きな動機は、の退職と更新されないドキュメントは、業務の識が特定の個人の記憶と断片的な資料に散在す断片化」も招いている。IPAのレガシーシれたIT予算の多くが現行システムの維持り組みに資金と人材を回せない。国内の調断ち切ることが、モダナイゼーションの第第二の動機は、変化への対応力、すなわちア制度改正や新商品の投入といったビジネスステム対応が数か月から年単位の律速要因の企業に共通する悩みである。変更を素早にすることが、モダナイゼーションの二つ7第三の動機は、DX(デジタルトランスフォーメーション)の土台づくりである。IPAは、DXを進めるあるデータの利活用にあるとしたうえで、足かせとなって、生成AIをはじめとする技術的負債の解消・保守コスト削減長年の運用で蓄積した技術的負債を高コスト構造を断ち切るアジリティの向上変化への対応(アジリティ)を高め、ビジネスの要請に素早く応えられるようにするデータを活用しやすい構造にすることで行後のシステムが何を可能にするかへの期ションも第一の系統と同じ「いかに移行すわれ、移行後のシステム像は「現行踏襲」断の関心はもっぱら移行プロジェクトのコ8本格化である。この2つの変化は、基幹システムの「利用者」と「開発者」を人からAIへ広げ、基幹システムつける。本稿では、このようにAIが補助的な道具ではなく業務とシステム開発の主体となり、人を前提に作第一の変化は、業務へのAI活用の本格化で通信白書によれば、生成AIを活用する方針業は2024年度で約5割に達し、前年度から約ている［3］。そして生成AIの企業利用はいった個人の作業支援にとどまらず、複数の連携して業務プロセスそのものを担う段階へこうした業務変革の取り組みが、金融、公共広い業界で始まっており、企業のAI活用の性向上から、業務プロセス自体をAIの存在を変えつつある。NTTデータグループもする開発の考え方と実践を「AI-Nativ書き換えられようとしている。この変化はする業務プロセス」を支えられることである。AIにデータと機能を提供できず、開発を担うられないシステムは、このサイクルの中で唯一クとして残る。これが、AI-Native時代に基9照し、処理を実行する主体が、人からAIエーことである。従来の基幹システムは、人が画面ることを前提に作られてきた。しかしAIエー基幹システムは、業務を遂行するための情報源ステムが業務データと機能をAIに提供できントを読み、修正する主体が、人の技術者からA従来は人が画面を操作していた基幹システムがAIエージェントにも使われるようになる人（業務担当者）•画面を操作してデータを入力確認•ソースコードやドキュメントを読んで理解•修正や機能追加を実施人AIエージェント基幹•ソースコードやドキュメントを読み解く人AIエージェント開発や改修の主体が人からAIへ広がる①利用者が変わる人ステムは、この新しい利用者と開発者のどちい。新しい「利用者」にとっての課題は、A未整備である。外部システムとの接続の仕組ていても、それは決められた相手との定型的提としたものであり、業務の単位で機能を呼て整えられてはいない。その機能が業務上何す記述も伴わないため、AIが意味を理解しなっていない。新しい「開発者」にとっての知ることは難しく、ドキュメントは実態と乖離そのものであり、アジリティの向上やデーから、移行後のシステムがどのような価値(リターン)を生むか、すなわち「何を目指して作り変えるか論へと重心を移す必要がある。本稿は、こわちAI-Native時代にモダナイゼーシJavaは国内の企業システム開発で最も広く使われているあり、メインフレーム上のCOBOL資産は日基幹システムの典型的な形態の一つである。こ降の章では、COBOLで構築されたシステムをJavるモダナイゼーションを代表例として説明する第2章AI-Native時代に基幹システムが目指すべき姿変わり始めていることを述べた。本章の主張は、その到達点が「業務を支えるAIと共に進化し続ける基幹システム」であり、それは一度の移行で完成する静的な姿ではなく、変化に合わせて作り変え続けられる動的な状態だ、ということである。基幹システムの「利用者」と「開発者」が人からAIへ広がるという前章の変化を目指す姿の中心に据えると、基幹システムが満たすべき条件はAI-Native時代に基幹システムが目指すべる。これが、第1章で立てた問い「AI-N新たな顧客価値の創出ビジネス環境の変化新たな顧客価値の創出ビジネス環境の変化基幹システムAIエージェントに業務データと機能を提供しAIの判断と実行を支える業務データの基幹システムの役割n正確で一貫性のあるデータの提供n安全で使いやすい機能の提供AIの役割AIエージェントが人と協働しながら業務プロセスを担う表裏一体の業務を支えるAI業務機能AIエージェント基幹業務データ業務データの人者」と「開発者」が人からAIへ広がるとい指す姿の中心に据えた点にある。業務を支えテムが表裏一体の関係にある、とはその言い務を支えるAIの判断と実行の質は、基幹シデータと機能の質に依存する。正確な業務デないAIは正しい判断ができず、システムのいAIは判断を実行に移せない。逆に、基幹見れば、AIと連携できないシステムは、業効果は頭打ちになり、システム側だけを刷新活用が伴わなければ投資は回収できない。と基幹システムのモダナイゼーションは、切もう一つの核心は、目指す姿が静的な完成形ではなく、動的な状態だということである。どれほど優れたアーキテクチャで作り変えても、その時点の姿は変化のスナップショットにすぎない。AIの技術進化は速く、業務へのAI適用範囲は移行後も広がり続ける。制度改正やビジネス環境の変化も止まらない。到達点は「作り終えた状態」ではなく、「変化に合わせて頻繁に手を入れ続けても壊れず、進化し続けられる状態」である。モダナイゼーションの成否は、移行直後の姿ではなく、移行の数年後にシステムがなお変化に追従できているかで測られることになる。その価値は、システムが業務変革の律速要因から外れ、AI活用による業務の改善と変革を、SOA、マイクロサービス、DevOpsAI-Native時代の議論は何が違うのか。答え従来の「変更に強いシステム」論は、人の技術者直し、人が使うことを暗黙の前提としてきた。は、システムに接続しデータと機能を使う「利スコードとドキュメントを読み修正する「開発へ広がることを前提とする。その瞬間、要求のわる。接点は人向けの画面ではなくAIが呼キュメントは人が読む資料ではなくAIが処理に、変更後の品質の確かめ方は、人のレビュー「業務を支えるAIと共に進化し続ける基幹システム」という姿を分解すると、基幹システムが満たすべき要求事項は（1）業務を支えるAIとの連携容易性、（2）AI-Native開発を前提とした変更容易性、（3）AIガバナンスを支える攻撃への耐性の4点に整理できる。これは、第1章で述べた新たな要請、すなわち基幹システムが「Aを支えられなければならないという要請を、システムが満たすべき条がりにそれぞれ対応する。（34）は、AI活用の広がりに伴う第一の要求は、業務を支えるAIエージェことである。これまでのシステムは、人がする前提で作られてきた。しかしAI-Nat一部をAIエージェントに任せる流れとなには、AIエージェントとの接点としてAと、そしてそのAPIが、業務上何を行うもできることが求められる（図4）。AIエー的な意味を手がかりに呼び出すべきAPIをタや機能に到達する。人向けの画面しか持は、AIは業務データにも機能にも到達で作を前提に設計された既存のAPIでは自の動的な振る舞いを支えられず、APIをエた形へ変革する必要があるという問題は、そしてその前提として、システムが疎結合でモジュール化たアーキテクチャであることが求められる。機能同士が密接に絡み合ったシステムでは、一部の機能だけを切り出してAPIとして公開することが難しく、APIを追加するたびに広範囲の影響調査が必要になる。AIとの連携容易性は、表面的なAPIの有無だけでなく、システムの内部構造そのもあわせて、AIエージェントに機能を開放することは、無制限の操作を許すことではない。AIエージェントは与えられたゴールから自律的に計画を立てて操作を実行するため、その操作を事前にすべて予測することは難しく、誤った操作が基幹システムに及ぼす影響は致命的になりうる。エージェントに与える権限を業務の単位で制御し、影響範囲を限定できる構造であることは、AIエージェントとの連携を安心して広げるための前提としAIAI-Native時代の基幹システムモジュール化された機能群機能 (サービス)機能 (サービス)機能(サービス)機能(サービス)・実行を担う（人が画面を操作する前提）人向けの画面中心人（利用者）AIエージェント業務の判断業務を支えるAI業務的意味API基幹システム基幹システム等業務データ業務データ画面操作API第二の要求は、変更容易性、すなわち変化AI-Native時代にはこれまで以上に速くなるAIと共に進化し続けるなら、それを支えるシさで変わり続けなければならない。変更容易性である。第1章で述べたとおり、業務の現発スタイル、すなわち第1章で触れた「AI-業務を支えるAIとの連携容易性が第一の要求だとすれば、AI-る（図5）。第一に、機能の配置がAIにとって理解しやすいことである。責務ごとに整理された見通しの良い構造であれば、AIは修正すべき箇所と影響範囲を正しく特定できる。第二に、ドキュメント資産が実態と一致していることである。仕様や設計の情報が失われ、実態と乖離したシステムでは、AIは誤った前提のまま改修を進めてしまう。第三に、そのドキュメント資産が、Markdown等のAIが読み取れる形式で維持されていることである。内容が正しくても、人が読むことだけを想定した形式のままでは、AIの改修の手がかりにならない。これを欠いたシステムでは、改修をAIに任せることができず、変化AIAIが開発可能なシステム×機能が分散し、責務が不明確×修正箇所と影響範囲の特定が困難×属人知が必要で、AIでも理解が困難×誤った前提のままAIが改修を進めてしまう×内容が正しくても、AIの改修の手掛かり修正箇所と影響範囲をAIが正確に特定正しい前提でAIが改修を進められるMarkdown等、AIが読み取りやすい形式で維持AIが改修の手掛かりとして直接参照できる③②AIが開発困難なシステム①（3）AIガバナンスを支える説明可能性（4）サイバー攻撃への耐性第三の要求は、AIが関与した処理についそれを実践するためのAIガバナンスの構築がのではなく、事業者の自主的な取組を促す指針AIの活用が広がるほど、判断の過程は人の目なり、説明可能性の確保が難しくなる。誤ったときには、それがAI自身の判断によるものかたデータによるものか、人の判断によるものか説明できなければならない。金融をはじめとすは、監督官庁がAI利活用における説明可能性幹システムの側でも、どのデータが、いつインも、検証可能性を確保するため、AIや利用時の入出力に加え、判断に用いた情ままのレガシーシステムはこうした要求に性が高く監査が容易な構造であることが求明可能性が、トラブル発生時の原因特定と可能にし、監査対応をはじめとするAIガ第四の要求は、サイバー攻撃に強いことである。生成AIの普及は、業務を効率化する一方で、攻撃側の高度化も招いている。IPAの「情報セキュリティ10大脅威2026」利用をめぐるサイバーリスク」が組織向けの脅威の上位に初めて選出され、AIの悪用によるサイバー攻撃の容易化や手口の巧妙化が指摘されている［9］。脆弱性の探索や攻撃の自動化が容易になり、攻撃の量とスピードはこれまでの想定を超えつつある。守る側の基幹システムには、一度の対策で終わるのではなく、発見された脆弱性へ迅速に対応し、塞ぎ続けここで問題になるのが、システムの構造である。古い技術で構成され、内部の見通しが利かないシステムは、脆弱性の発見も修正も難しく、最新のセキュリティ対策の適用対象からも外れていく。修正の影響範囲が読めないために、セキュリティパッチの適用そのものをためらう状況も生まれる。発見された脆弱性へ迅速に対応できる構造、すなわちセキュリティパッチの適用とその影響確認を迅速に繰り返せる構造であることが、攻撃が高度化する時代の基幹システムの要件で本章で述べたことは2つである。第一に、AI-Native時代の到達点は「業務を支えるAIと共に進化し続ける基幹システム」であり、その核心は、基幹システムの「利用者」とたものが、（1）〜（4）の4つの要求事項である。第二に、この到達点は静的な完成形ではなく、変化に合わせて作り変え続けても壊れない動的な状態である。モダナイゼーションの手法と進め方は、この動的な状態を実現し維持できるかを基準に選ばなけれでは、現状からこの到達点へは、どのような道のりがあ第3章目指すべき姿を実現するモダナイゼーション前章では、AI-Native時代の到達点を「業務を支えるAIと共に進化し続ける基幹システム」と定義し、それを構成する4つの要求事項を示した。本章の主張は、この要求に構造から応えられる最も有力な手法はリビルドであり、最も大きな課題はコストだ、ということである。多くの企業の基幹システムと4つの要求事項との間には大きな隔たりがあり、有識者の退職が進む時間の制約の下ると、リホストとリライトの限界はいずれも内部構造に手を入れないことに帰着し、内部構造に手を入れるリビルドが到達点へのば、ユーザー企業の61%がレガシーシステムを保大企業に限れば保有率は74%に達する［1］。第1の業界に限った話ではなく、日本企業に広く共通現状を前章の4つの要求事項に照らすと、体的になる。人が画面を通して操作する前提でムには、AIエージェントとの接点となる離したドキュメントゆえに、小さな変更に改修で内部構造が不透明になり、データが行システムに精通した技術者の高齢化と退職は務知識の断片化（第1章）は年々深刻になる。るほど、現行の仕様を知る手がかりは失われモダナイゼーションの契機は大規模なシスの離脱といった受動的な要因が上位を占め予見して自律的に決断する企業はまだ少な約は一層厳しいものになる。現状の確認と現状から到達点へ向かうモダナイゼーション手法（再構築手法）として、IPA「システム再構築を成功に導くユーザガイド」は、概要ハードウェアの変更をア製品のバージョンが変わる影響によりプログラムの修正が発生する場合もあるプログラムは現行と同一の言語で、原則そのまま新規プラットフォームへ移行する現行のプログラム設計書をもとに、異なる言語で新たなプログラムを実装する現行の要件定義書をもとに新規システム業務要件は変えずにアプリケーションを事実上作り変える要件定義書現行流用現行流用現行流用現行流用基本設計書/詳細設計書現行流用現行流用現行流用再設計設計書現行流用現行流用現行流用再設計現行流用再生成再生成補足ハードウェアを同一機種または後継機へ乗り換えることに伴い、OS、ミドルウェア製品のバージョンが上がることはあるが、製品の種類は変更しない語」には、たとえばメインフレームCOBOLからオープン系COBOLに変わるケースを含む——評価の基準は、前章で示した4つの要求事項である。それぞれの手法について、得られる効果と、実施後ものまま残るため、COBOL技術者の調達リアプリケーションの保守性も変わらない。内入れないため、前章の4つの要求事項のうち、性、AIを前提とした変更容易性、説明可能性基盤が最新の製品に替わる範囲では改善するション側の脆弱性の発見と修正の難しさは変ストは、基盤リスクの解消という目的には応えるが、AI-リライト:オープンな言語へ移すリライトの効果は、脱メインフレームに加えて、プログラムがJavaなどのオープンな言語になることで、OSSを中心に商ることにある。機械変換を中心とするため、リビ低コストでオープンな言語へ移せる。一見すると術者の調達リスクも解消され、脱COBOLまでまま写し取る。COBOLが持つ密結合な仕様（領域をプログラム間で共有する構造など)や、手続き的な制御の流れは、変換後のJavaにそのまま温存される。その結れるのは、Javaの文法で書かれていながらCOBOLる。JaBOLの保守にはCOBOLの知識が引き続きめ、リライトは、言語の表記と基盤こそ新しくなるCOBOLを実現できない。保守性は改善されずコラム:なぜ機械変換によるリライトは機械変換である。変換元のソースコードを構文解かじめ人が定義した変換規則、すなわち「COBは、Javaのこのソースコードに置き換える」という対機械的に適用して、別言語のソースコードを生成計」ではないことにある。Javaに対応するCOBOL固有の仕様（固定長の集団項目やデータ型、COPY句によるデータ定義の共る制御の流れなど)は、規則による単純な置き換えができな•四則演算や比較のような基本的な処理まで、Javaの•ツール独自のデータ型が全編で使われ、保守にはJavる•現行では一元管理されていたデータ定義（個々の呼び出し元に展開され、1つの定義を直•GOTO文の変換によって呼び出し関係がかる作法の両方の知識が必要になる。COBOLを解消するための言語変換が、「COBOLを理解技術者」という、より稀少な人材を前提とにある。設計から作り直すため、疎結合でモたアーキテクチャ、オープンで標準的な技術利く実装を選び直すことができる。前章の4つ造から応えられる他、長年蓄積した技術的負ため、第1章で述べた従来のモダナイゼーショ施中の企業（回答33社）が挙げる課題としての複雑さにより移行プロセスが技術的に困難」が6トの壁ゆえに、リビルドの価値は理解されな案件ではリホストやリライトが選ばれること以上の評価を、モダナイゼーションに求められる要求事項に照らして整理したのが表2である。第2章で示したAI-Natiの要求事項に加え、従来のモダナイゼーションで求められてきた3つの要求事要求事項業務を支えるAIとの連携容易性××温存）○API化と権限制御を提とした変更容易性××○設計書）AIガバナンスを支え××で追跡がかえって○サイバー攻撃への耐性△アプリケーションは現行のまま)△が構造は温存）○への迅速な対応が従来のモダナイゼーション(オープン基盤への移行）○○○オープンな言語向けのソフトウェア・ツール群の活用×○○COBOL技術者への依存の解消××COBOLの知識が引○表2からは、2つのことが読み取れる。第一に、Aうことである。リホストとリライトが応えきずれも内部構造に手を入れないことに起因す第二に、従来の要求事項まで視野を広げると純な優劣ではなく、どの要求事項に応えるか理性を持つ。どの手法を選ぶべきかという問て初めて答えが出る。ただし、COBOL次節では、第一の帰結、すなわちなぜリビルドが前節の評価が導く帰結は明快である。3手法のうち内部構造に手を入れるリビルドは、4つの要求事項に構造から応えられる。本節では、設計から作り直すことがそれぞれの要求事項にどう効くのかを業務を支える業務を支えるAIとの連携容易性の向上疎結合なアーキテクチャAI-Native開発を前提とした変更容易性の向上AIが読みやすい設計書説明可能性の向上脆弱性への迅速な対応(サイバー攻撃への耐性強化）AIが理解しやすい機能構成AIにより設計書を最新に保てるAPI化の促進ジェントとの接点となるAPI化が促進さ必要になっても、影響を局所化したまま素人の技術者だけでなく、改修を担うAIにとっさそのものである。合わせて、リビルドの過程AIが読み取りやすいテキスト形式で整備し直一致し、かつAIが読める設計書がそろうこAIエージェントを含む業務システムには、処修正すべき箇所と影響範囲を特定しやすいため、表されてからセキュリティパッチを適用す業を短くでき、影響範囲が読めないまま適（2.2節）から抜け出せる。さらに、適用後にが変わっていないことの確認は、第4章で述を常設の品質ゲートとして用いることで効る。セキュリティパッチの適用とその影響返せることが、攻撃が生成AIの普及によの、守る側の対応の中心となる。あわせてドと設計書を読み解ける状態は、平時から弱性を点検し、塞ぎ続ける予防的な運用にし、この効果が及ぶのはアプリケーションみ解く対象はアプリケーションのソースコこうして整理すると、リビルドは目指す姿への本命の道筋第4章モダナイゼーションの実現作る技術と確かめる技術の双方にAI-Native開発の考え方を適用することで大幅に低減できる可能性が開ける。確かめる技術の要である現新比較試験前章では、AI-Native時代の4つの要求事項に構造から応えられる最も有力な手法はリビルドであることの壁があることを述べた。本章の主張は、生成AIを前提に開発プロセスそのものを再設計する「AI-Native開発」の考え方をリビルドに適用することでそのコストを大幅に低減できる可能性があり、生成AIが持ち込むハルシネーションのリスクは、稼働する現行システムを「正解」とする現新比較試験によって大幅に抑制できる、ということである。作る技術と確かめる技術がそろって初解決の骨子は、「AI-Native開発」の考え方を、作る技術であるリビルドと、確かめる技術である現新比較試験の双方に適用することである。コストの壁にはAI-Native開発の考え方を適用したリビルドが応え、生成AIが持ち込むハルシネーションのリスクにものを再設計する「AI-Native開発」の考えAI-Native開発では、AIが担う範囲を段設計書やソースコードといった成果物を生成開発プロセスの透明性の提供まで担う段階(レベル3：A本章で述べるリビルドと現新比較試験は、いずれもレベル2：AI-Verified以上の段階を狙って設計する。成果物の生成をAIに置き換えるだけでは、生成量の増大に伴って人のレビューが新たなボトルネックになるからである。品質の確認までAIが担うことで、開発コストの中で大きな割合を占めてきた人手のレビュー工数を削減し、大幅な効率化によって従来のコストの問題の解消を狙う構図である。同じ考え方は品質保証の側にも及ぶ。後述の現新比較試験を阻んできたバグの原因調査の工数（4.3節で述べる)が大きい問題も、AIに置き換えることで解●●人間の役割●AIの役割ベースライン AI-Assisted AI-GeneratedAI-VerifiedAI-Explainable機能性透明性(プロセスの透明性を確保する)アカウンタビリティ組織構造実現要素技術環境基盤モデルの進化（GPT,Claude,Geminiなど)来歴追跡と検証可能性コンテキスト認識エージェント型監督来歴追跡と検証可能性コンテキスト認識 （出典：NTTデータグループ公開ホワイトペーパー「基幹システムの移行で従来から知られてきた手法節）。本稿の主張は、AIがリビルドを担う第一に、仕様の外側にある事実から仕様を検なるからである。生成AIには、事実と異なるしく生成する「ハルシネーション」と呼ばれるビルドでは、現行ソースコードの読み違えや、上流工程の誤りとして現れうる。深刻なのは、流のすべてに一貫して引き継がれることであるが作られるため、同じ仕様を基準とするテストを検知することが困難となる。仕様の外側にあち稼働している現行システムの振る舞いとの突第二に、人のレビューによる検出が現実的でないからである。大であり、その中間成果物のすべてを人がレビューして誤りを第三に、検証の結果を修正へつなげるフィードバックの仕組みに発展させられるからである。同じ入力データを現行システムも、最終的には振る舞いの差分として外形に現れる。差分の原因を遡って是正することで、現新比較試験は、ハルシネーションに起因する誤りを含むリビルドの過程の誤りを検知し、修正その構成と呼称をAI-Native開発の定義に合わせており、設計工程を「ハイレベル設計」「ローレベル設テスト(システムテスト)テスト（結合）のハルシネーションテスト(システムテスト)テスト（結合）のハルシネーションDテスト（単体）のハルシネーション要件定義要件定義ローレベル設計テストテストハイレベル設計生成AIのハルシネーション4.2AI-Native開発の考え方を適仕様復元におけるソースコードの読み解きと文書化、仕様の設する作業の多くは、言語で表現された情報を読み、変換し、生成する知的作業であり、生成AIが最も力を発揮する領域にあたる。システムが再生産されかねない。そこで本稿では、AI-Native開発のレベル2：AI-Verifiedの考え方に沿い、成果物を生成するAIエージェントと、その品質をモニタリングするAIエージェントからなるマルチエージェント構成でリビルドの工程を設計する。具成の要となる2つのタスク、すなわち生成する側の要である再設計と、モニタリングする側の要である保守性評価保守性基準変換規則保守性基準仕様復元テスト保守性評価保守性が基準に満たない場合は再設計にフィードバック※設計はハイレベル設計とローレベル設計の両者を含む図9.AI-Native開発の考え方を適は業務の要件ではない。たとえば、COBOのメモリ構造は、業務が固定長を求めてい工程である。固定長のメモリ構造を前提とする仕様造を前提とする仕様へ置き換え、共有メモの密結合を解いて、責務ごとに分離されたたまま言語の表記だけを変換するリライト（3力には揺らぎがあり、同じ方針の下でも、生成さソースコードの保守性は一定ではない。そこで、価する観点を定めておく必要がある。ソフトウェ際規格ISO/IEC25010は、保守性を製品品質の特性のではない。どの副特性を測るのか、どののか、どの値を満たせば良しとするのかはめて作り直す、という評価とフィードバック正が担ってきた役割を、明文化された基準にが果たすのであり、これはまさにレベル2：段階に相当する。基準を明文化し、評価と改組み込むことで、保守性を「担当者の力量に得られる結果」から「プロセスが保証する水保守性評価までの一連のタスクを、工程内に介在させず、AIエージェントが一気通貫として設計する。人が担うのは、品質ゴールなる成果物の確認、リスクの高い箇所の判断あり、人の役割は、作業とレビューの担い手め結果を確かめる立場へと移る。なお、再設を経て作り直されたシステムは、AIだけ読みやすい設計書とソースコードを持つ。Cル固有の知識を前提とせず、標準的なJava技術者設計がもたらす効果である。設計から作り直4.3AI-Native開発の考え方を適用し稼働している現行システムの振る舞い、それ自て新システムの出力との差分を突き合わせが直ちにバグとは限らない。実行日時やタ番の順序、出力の並び順など、仕様どおりじる差異（非バグ)が大量に混ざるからである。差分の一件一件についてバグか非バグかを人手で切りば原因箇所を調査する作業は、対象データ積に比例して膨らみ、人手では現実的に終わらない規模の負担験の段階まで到達するバグは少なくなる。バグがめったに出ないと見込まれる試験のために膨大な調査工数を投じるのは、保険としてはあまりに高くつく。その結果、現新比較試験は対象AI-Native開発の考え方の適用が狙うのは、このコスト構造の転換である。差分の検知、バグか非バグかの判定、バグの原因箇所の分析、修正の実施という、従来は人手に頼るしかなかった一連のタスクをAIが自動で実行し、差分が解消するまで検証と修正を繰り返す仕組みとして設計する。人の役割は、差分を一件ずつ切り分ける作業から、AIによる判定と修正の要否を確実施が視野に入る。検証の実行をAIに委ねられれば、人の稼働時間に縛られることなく、夜間や休日も検証を進め続ける運用も見込める。投資対効果の構図も逆転しうる。検証のコストが十分に下がれば、「バグがほとんど出ない見込みなのに高くつ析と修正の過程でAIがこの上流の誤りを是正することで、成果物の内側からはテストで検知できなかった上流工程の誤り（4.1節）を、成果物の外側にある事実に照らして一つずつ解消していく道が開ける。作る側のAIの誤りを、確かめる側のAIが、現行システムという独立した「正解」を拠り所に正す。生成AIを基幹システムのリビルドに適用する決断を支えるのは、この構図である（図10）。生成AI利用③原因分析③原因分析現行環境差分情報差分情報原因箇所差分情報差分情報原因箇所修正内容検討修正内容検討判定新環境差分情報差分情報差分情報差分情報原因箇所差分がなくなるまで繰り返し実行図10.AI-Native開発の考え方る。これは、第2章の要求（2）「AI-Nat））を現実的なコストで作る技術と、その品質を移後にも確かめ続ける技術とを、一体で確立してならない。次章では、この2つの技術を前提とし第5章AI-Native時代の新たなモダナイゼーション戦略ゼーションへ変わる。その成果は、新システムの獲得ではなく、そ前章では、リビルドを阻んできたコストの壁を、AI-Native開発の考え方を適用したリビルドと現新比較試験の組合せによって大きく低減できる可能性を示した。本章の主張は、この壁が低くなるとき、モダナイゼーションの戦略は「基本は継続利用、必要な範囲だけ手を入れる」というこれまでの現実解から、リホストで基盤起因のリスクとコストを解消しくる2段階のモダナイゼーションへ変わる、ということである。そしてモダナイゼーションの成果は、新システムの獲得そのもの壁があった時代の選択肢を整理すると、こ第3章で見たとおり、COBOLの知識なしステム(いわゆるJaBOL）を生み、目的の1つである脱ような使い分けに落ち着いてきた。第一に、安るシステムは、無理に作り変えず戦略的に継続二に、メインフレームの保守期限や維持費用がる場合は、リホストで脱メインフレームを果たのリスクとコストだけを確実に解消する。第三リティが求められる領域に限って、そこだけをビルドで部分的に作り直す。動いているシステ触らず、投資対効果の見合う範囲に投資を絞るしかし、この現実解には限界があった。頼みの綱である第三の打ち手（部分的な切り出し)が、実際には思うように機能しないのである。長年の増改築を経た基幹システムは内部が密結合になっており、切り出したい機能ほど他の機能と深く絡み合っている。小さく切り出そうとすれば、切り出しのための影響調査と改修自体に大きな労力を要し、かといって絡み合った範囲ごと大きく切り出せば、今度はリビルドのコストの壁に正面から突き当たる。手を出したくても、手を出せなわち継続利用か、リホストによる基盤刷新までに留まって問題は、そこに留まったままでは、AI-Native時代の4つの要求事項（第2章）との構造的な隔たりが解消されないことである。継続利用もリホストも、アプリケーションの内部構造には手を入れない。要求に応えないままの継続は競争力の低下を招き、その代償は業務のAI活用が広がるほど大きくなる。壁を前提とした現実解は、壁が低くなり始めた今、見直され壁が低くなり始めたことを前提とした新た第1段階は、リホストによる基盤の刷新であ第2段階は、リビルドによる構造の転換であ上に移った現行資産を、AI-Nativり変え、保守性が高くAPI化が容易な、第1段階：リホスト（基盤の刷新）第2段階：リビルド（構造の転換）業務変革ループ（終わりのない営み)メインフレームからの脱却を実現し、基盤起因のリスクとコストを先に解消COBOLCOBOL基盤オープン基盤AI-Native開発を導入したシステムを段階的に移行業務側業務側さらに改善 ②システムの作り変え側繰り返し回し続ける業務プロセスの改善のサイクルがシステム対応に律速されない業務の実行が生むデータが基幹システムに蓄積フィジカルAI）の土台になるJavaCOBOL\基盤の保守期限リスクを解消維持費用を削減保守性が高く、APIが容易な構造AI-Native時代の4つの要求事項に対応平準化せるために対象を小さな単位で切り出すしかなく幹システムではその小さな切り出し自体が大きな（5.1節）。新戦略の最大の違いは、リビルドコ低減（第4章）によって、経済性の観点から対象せざるを得なかったこの制約を緩和できる点にあ果の検討を前提としたまま、呼び出し関係やデー存関係の観点で無理なく切り出せる、絡み合った含む大きな単位を、リビルドの単位に選べるようルドは一部領域に限られた例外的な打ち手から中げうる有力な打ち手へ変わり、リホストは最終的はなく、事業継続を確保しながら段階的にリビルハードウェアの保守期限は動かせない締切であビルドの費用と期間はAI-Native開発の考え圧縮できる可能性があるものの、規模が大きい確実性というリスクは残る。先にリホストで締せて基盤リスクを確定的に解消すれば、リビルわれず、領域ごとに腰を据えて進められる。リ第二に、業務への影響を最小限に抑えられ（3.2節）、作り変えを伴うリビルドに比第三に、第2段階の品質保証の環境を用意しある。第4章で述べたとおり、リビルドの品行システムを「正解」として同じ入力デー差分を検証することにある。現行がオープいれば、この「正解」側の環境を複製して実行する検証環境を用意しやすく、検証をにも乗せやすい。第1段階のリホストが、第第四に、投資を段階化できるからである。が、それは目的の達成ではない。システムのであり、目的は、作り変えたシステムの上でとにある。DXの本質がレガシーシステムの刷を終えた基幹システムの上で、業務側へのA変革ループ」と呼ぶ。これはモダナイゼーシはなく、モダナイゼーションが整えた土台のわりのない業務側の営みである。APIを通じ能を提供できるようになった基幹システムの上APIの追加、プロセス変更への対応）も、この業務や現場の状態をデジタル空間上に再現しの作業を担うフィジカルAIといった、現実活用へも道が開ける。デジタルツイン上で業更を試してから現実の業務に実装し、フィジの実行を担い、その結果のデータが基幹シスこうして業務変革の到達範囲は、デスクワ業務データと機能をAPIで提供できる基業務変革ループが「迅速に」回ることにはる。業務と開発の双方にAIが入っているる業務側ではAIエージェントがプロセスを日々の実行の中で顕在化させる。開発側続的な品質ゲートに守られながら追従の改修来は「業務を変えたくても、システム改修がネック」だったサイクルを、大きく短縮でき第1章で述べた「AIを前提とする業務プロセスの最適化」は、いう発想は自然であり、両者を同時に行うかナイゼーション計画の古典的な論点である。る」を基本とする最大の理由は、品質保証にの品質保証は「動いている現行システムが正に立脚する（第4章）。業務要件を同時に変え現新比較試験による検証が及ばない。まず現た状態で新システムの品質を確定し、その後う方が、品質判定とプロジェクト管理を単純従来、この分離には「移行だけで体力を使い果用を圧縮し、常設の品質ゲートが変更のたびトにする（第4章）ため、この弱点は解消に表3.業務変革をリビルドと同時に行う場合と分けて行う場合の比較品質保証業務を変えた部分には比較すべき「正解」がなく、現新比較試験による検証が及ばない現行システムを「正解」とする現新比較試験で品質を固めきれるプロジェクトリスク性質の異なる難作業を一つのプロジェクトで抱えて計画が複雑化し、業務側の合意形成の遅れが移行全体の遅れに直結する移行と変革を切り離し、それぞれを小さく確実に進められる投資判断一括の大型投資になり、後戻りが難しい段階ごとに効果を確かめながら判断できるただし、これは同時実施を一律に否定するものではない。変更範囲と受入基準を明確に分離能であり、小規模なシステムであれば、リビルドと一度目の業務変革を同時に行い、仕様の正しさを人のレビ第一のステップは、目的と目標の設定であ社の経営計画を踏まえ、コストの最適化、品第二のステップは、現状の把握である。確かる。目標と現状の隔たり、現行の仕様を知る手が者、ドキュメント、テスト資産）の残存、そして依存関係である。依存関係は