レガシーシステム刷新に生成AIをどう使うか——COBOL資産と「複数の正しさ」から見えたこと

仕様書と現行の動きが違うとき、AIはどちらを信じればいいのか。

レガシーシステム刷新の現場では、こうした「正しさのズレ」に日常的に向き合うことになります。COBOL資産を題材にしたハッカソンでの実践と、8月3日に開催するイベントの内容を通じて、生成AIをレガシー刷新にどう活かせるかを考えてみます。

モダナイゼーションの本当の難しさは、コード変換ではない

仕様書と現行の動きが違うとき、何を信じればいいのか。

レガシー刷新で難しいのは、コードを変換することだけではないと思っています。本当に難しいのは、長い時間をかけて積み重なった業務知識や設計判断が、いつの間にか暗黙化され、失われていることです。

仕様書はある。でも、現行の動きとは少し違う。

コメントはある。でも、なぜそうなっているのかは分からない。

テストはある。でも、業務上どこまでを保証しているのかは曖昧。

詳しい人はいる。でも、その人の頭の中にしか判断理由が残っていない。

以前、ある基盤移行で似たことがありました。移行そのものは正しく進んでいたのですが、結果として長年残っていた不具合が解消され、利用者から見ると「仕様が変わった」ように見えた。技術的には正しい。でも、業務側から見ると「前と違う」。

ここで難しいのは、どちらが正しいかを単純に決めることではありません。

仕様書上の正しさ。コード上の正しさ。現行挙動としての正しさ。利用者が期待している正しさ。

レガシー刷新では、この複数の「正しさ」のズレを扱わないまま進めることが、一番危ないのだと思います。

そしてこの問題は、生成AIが入ってきたことで消えるどころか、むしろ重要さが増しました。

AIエージェントが崩した前提

AIエージェントが賢ければ、あとは任せられる。そう思っていた時期がありました。

Copilot Questというハッカソンに参加した際、その前提はあっさり崩れました。題材はCOBOLで書かれたレガシーシステムでしたが、実際にチームで手を動かしてみて、最初にぶつかったのはコード変換の壁でも、エージェント自体の性能でもありませんでした。

見えてきたのは、COBOLにもレガシーにも限らない、AIエージェント活用全般に通じる4つの気づきでした。チームでは、一回で完璧を狙わず、小さく試しては結果を確認し、次の回に反映するという、ループ型の進め方を採りました。その中で見えてきたものを、言葉にしてみます。

①暗黙知がないと、エージェントは意図した成果に近づきにくい

仕様書やコードだけでは伝わらない、判断の理由や運用の背景。これが渡らないままだと、エージェントは動いても、意図した成果にはなりにくい。

②何を正解とするかは、先に人が言葉にしておく必要がある

仕様、コード、現行の挙動、利用者の期待。前章で触れた、複数の「正しさ」がずれたまま進めるのが一番危ない、という話は、AIに置き換えても同じでした。エージェントに判断を委ねる前に、どれを基準にするかを人が決めて渡しておく必要があります。

③エージェントの判断範囲は、小さく区切る

一気に全体を任せるのではなく、扱う範囲、入力と出力、責任の境界をあらかじめ固定する。任せる範囲が小さいほど、検証もしやすくなります。

④一回の試行で終わらせず、学びを次に蓄積する

1周目でうまくいかなかった判断や、想定外だった挙動を、2周目以降のインプットに反映していく。ループを重ねるほど、エージェントが動ける範囲が広がっていきます。

つまり、AIに任せる前に、AIが働ける環境を育てる必要がある、ということです。

AIに任せるのではなく、AIが働ける環境を育てる

仕様書時代からあった「複数の正しさ」のズレという問題は、AIエージェントの時代になっても消えませんでした。むしろ、暗黙知・正解定義・判断範囲・学習ループという4つの形で、より具体的に姿を現したと言えるかもしれません。

だとすれば、必要なのはより賢いAIを探すことではなく、AIが正しく働ける環境を先に用意することです。

長年の運用の中で積み重なった業務知識や判断基準は、多くの場合、コードにもドキュメントにも残っていません。担当者の頭の中にだけあります。この暗黙知を、AIが読める形、AIが検証できる形に変えていく。それができて初めて、AIはレガシー刷新の現場で本当の意味で機能します。

コードからドキュメントへ、ドキュメントからコードへ。そして、人の知識をAIが活用できる資産へ。

これが、AI時代のモダナイゼーションで最初に取り組むべきことだと考えています。

8月3日のイベントでは、この考え方を思想として語るだけでなく、COBOL資産を題材に、GitHub上で実際に動かしながらお見せします。

2026年8月3日、レガシーシステム刷新×生成AIのイベントを開催します

このテーマを、1つの問いを4つのセッションで掘り下げる形のイベントとしてお届けします。

「レガシーシステム刷新を、AIでどう加速させるか。」

項目	内容
日時	2026年8月3日(月) 14:30〜17:30
会場	日本マイクロソフト品川オフィス
定員	40名程度・事前登録制
対象	大手企業のDX推進部門・IT部門

Session	登壇者	テーマ
Session1	岩松(NRI)	| Session 01 | 岩松さん(NRI) | なぜレガシーシステム刷新は進まないのか——生成AIで変えるモダナイゼーション |
Session2	柳原さん(Microsoft グローバルブラックベルト)	AI AgentでAgenticにデータを活用——GitHub CopilotとMicrosoft Fabric最新事情
Session3	萩平(NRI)	GitHub Copilot Agentを活用する開発基盤・運用ループの実践
Session4	原(NRI)	Microsoft Fabricによるセマンティック層構築とAgenticデータ分析の実践

グローバルブラックベルトとは、Microsoft社内でも特定の技術領域における最上位クラスの専門家に与えられる称号です。Session 02では、そのGBBである柳原さんから、GitHub CopilotとMicrosoft Fabricの最新動向を直接語っていただきます。

課題(なぜ進まないのか)から始まり、青写真(何が可能になるのか)、実践(どう設計して加速させるか)、そして価値(その先に何があるのか)へと、話は一本の線でつながっていきます。現場の開発ループの話(Session 03)で終わらず、その先のデータ活用基盤——Microsoft Fabric(Session 02・04)まで一気通貫で扱うのが、このイベントの特徴です。この記事の①②③でお話ししてきた内容は、Session 03の土台になっています。

こんな方におすすめです。

– COBOLなど、古い言語で書かれたシステムが残っている
– 夜間バッチや帳票、計算ロジックがブラックボックス化している
– 仕様書が古い、あるいは現行の動きと一致していない
– 保守を担う方が属人化・高齢化している
– 生成AIの活用を検討しているが、基幹システムにどう使うか迷っている
– クラウド移行、GitHub活用の余地を探している
– モダナイズの先にあるデータ活用・分析基盤の展開まで見据えている

まずは、うちのどこからAIを使えるか、考えてみませんか

いきなり全体刷新の話をするつもりはありません。

まずは、自社のレガシー資産のどこからなら、生成AIを使えるのか。それを一緒に考えるところから始めませんか。

8月3日、日本マイクロソフト品川オフィスにて。定員40名、事前登録制です。

お申し込みはこちらから