『レガシー移行（モダン化）にAIを使え』という無茶ぶりに、どう立ち向かったか（そして今も戦っている話）

はじめに

この記事は、あるSIerに勤める一人のSEの個人的な体験談です。特定の顧客やプロジェクトを指すものではなく、情報を適度にぼかして記載しています。内容の大部分は、個人の感想や見解に基づいていますので、一つの読み物として楽しんでいただけますと幸いです。

対象読者

レガシーシステムのモダン化の泥沼にハマっている方

現場の事情をよそに「生成AIを使え」というプレッシャーを感じている方

生成AIを実務に導入しようとして、理想と現実のギャップに絶望しかけている方

TL;DR

「ソースコードが仕様書」 なJavaの遺跡（基幹システム）改善に「生成AIを使え」というミッションが降ってきた。正直な第一声は「うわぁ...」でした。

銀の弾丸を探しに社内外を駆け回ったが、「明確な答えは、まだ無い」 という厳しい現実を知る。

4段階のAI活用戦略を立てるも、「技術の壁（AIが賢くない）」と「人の壁（チームが疲弊）」 に阻まれ、見事な「千日手」状態に。

個人で試行錯誤した結果、AIに「手順や着眼点といった"人間の知恵"」を与えることで、ようやく一筋の光が見えた。（場合によっては元も子もないともいえる...）

今は、その属人化したノウハウをRAGやMCP、モデルの再学習といった技術で仕組み化できないか、次の戦いを模索している。

1. はじめに：それは「考古学」から始まった

今、私が担当しているのは、とある大手食品メーカーさんの基幹システムをモダン化するプロジェクトです。
そのシステム構成は、なかなかの歴史的価値を持つ、いわば"IT遺産"でした。

Java（のなかなか古いバージョン）
WebLogic
EJB (Enterprise JavaBeans)
クライアントサーバ構成のオンプレ環境

これを、AWS上の Java 17、 SpringBoot 3.x、コンテナ（ECS + ALB） というモダンな環境に移管する。言葉にすれば数行ですが、その道のりは色々大変です。

何より厳しいのが、気の利いたドキュメントなんてものは存在するが伏魔殿化し、だれも全体像を把握できていないこと。唯一信じられる真実は、目の前にあるソースコードだけ。私たちの仕事は、さながら古代遺跡を発掘する「考古学者」のようでした。スパゲッティのように絡み合った依存関係、至る所に埋め込まれたハードコーディング、もはや誰も解読できないデッドコード…。そんなコードの密林をかき分け、古代の仕様を解読する毎日でした。

そんなある日、天からのお告げのように、こんなミッションが降ってきたのです。

「このプロジェクトで、生成AIを活用して開発を効率化せよ」

……一瞬、時が止まりました。
ただでさえ目の前の遺跡発掘で手一杯なのに。正直、最初に口から漏れたのは、偽らざる本音「うわぁ…」でした。

2. 銀の弾丸を探す旅、そして誰もいなかった

とはいえ、決まったものは仕方ない。
まずは巨人の肩に乗ろうと、私たちは先人の知恵を探す壮大な旅に出ました。藁にもすがる思いとは、まさにこのことです。

社内の生成AI推進コミュニティや、専門的に研究開発しているR&D部門にヒアリング
AWS, Google, Microsoft といったメガクラウドベンダーのイベントというイベントに足繁く通い、ブースで中の人を質問攻めに
GitHub や Red Hat 等のソフトウェア、サービス系の担当者にも、食い下がるように現状を伝えてアドバイスを求めた

しかし、あらゆる専門家を訪ね歩いた末に得られたのは、ある種の「悟り」にも似た、厳しい現実でした。

「仕様駆動開発（Specification-driven development）なら事例は多いのですが…」
「大規模なソースコードをベースにしたリファクタリングは、現在の生成AIはあまり得意じゃない…」
「EJBのような古いライブラリや独自フレームワークの解析は、学習データも少なく精度が出にくいのが正直なところです…」

世の中のキラキラしたAI活用事例は、そのほとんどが「明確な仕様書」を前提としていたのです。しかし、私たちの現実はソースコードを正とする「考古学駆動開発」。根本的に、土俵が違いました。

そう、私たちのための「銀の弾丸」は、まだこの世のどこにも存在しなかったのです。

3. 無いなら作る。私たちが立てたAI活用への4ステップ

絶望していてもプロジェクトは1ミリも進まない。
私たちは、自分たちで道を作ることを決意しました。いきなりゴールを目指すのではなく、地に足の着いた戦略を、ゼロから立てることにしたのです。

まずはAIに触れる環境と「使ってみようかな」という動機付けから始め（導入期）、個人がツールを使いこなし、小さな勝ちパターンを見つけ（個人レベル適用期）、その知見をチームに広げ（チームレベル適用期）、最終的には他のプロジェクトでも使える形を目指す（普及期）。

これなら、どんな現場でも着実に進められるはずだ。計画は完璧に見えました。そう、この時点では…。

4. 立ちはだかる2つの高い壁：『技術』と『人』

意気揚々と計画を立てた私たちですが、その歩みはすぐに、そして見事に止まってしまいます。
現在地は、正直に言うと「ステップ1.5」。導入期と個人レベルの間で、もがき続けている状態です。

そこには、分厚く、高い、2つの壁が立ちはだかっていました。

壁①：技術の壁「Copilot、そこじゃないんだ…」

まず、ツールの限界です。GitHub Copilot を中心に検証を進めましたが、私たちの「考古学」の前では、AIはあまりにも無力でした。

複雑怪奇なコード:
元のコードが密結合すぎて、AIが文脈を理解しきれない。結果、平気で的外れなサジェストを連発し、それを修正するのに時間を取られてしまう。「これなら自分で書いた方が100倍早い…」となり、メンバーの心が静かに折れていく音が聞こえました。
ツールの限界:
移行元と移行先のリポジトリが別だと、Copilotは横断的にコードを読んでくれません。「あのリポジトリの過去の実装意図を汲み取って、こっちに新しい実装をしてほしい」なんていう、人間なら当たり前の指示が通じない。うーん、惜しい、そこじゃないんだ…！（場合によっては静的解析やマイグレーションつーるのがマシ？）

壁②：人の壁「それ、今やるんですか…？」

そして、技術よりも根深いのが「人」の壁でした。
私たちのチームは、私の所属組織のメンバーと、ビジネスパートナー（BP）さんで構成されています。BPさんたちはAIに興味がないわけではないですが、私たちの会社のトップダウンミッションに付き合う義理はありません。ニュートラル、という言葉が一番しっくりきます。

何より、プロジェクトの進捗は常に火を噴いている状態。
日々のタスクに追われ、心身ともに疲弊しているメンバーに、「効果が出るかわからないけど、未来のために一緒にAIの使い方を模索してほしい」なんて、とてもじゃないけど言えませんでした。

結果、チームは完璧な「千日手」状態に。
誰も反対はしない。でも、誰も積極的にやらない。むしろ、やれない。そんな重い空気が、私たちの間に漂っていました。

5. 見えてきた一筋の光：AIは"賢い部下"として育てる

チームを巻き込めないなら、まずは自分だけでも。
そう思い、一人で試行錯誤を続ける中で、本当に小さな、でも確かなブレークスルーを見つけました。

それは、AIとの「対話」の仕方です。
巷でよく言われる「あなたは〇〇の専門家です」といったペルソナ（人格）を与えるだけでは、私の現場では全く歯が立ちませんでした。もっと大事なことがあったのです。

感じたこと：AIには「手順」や「着眼点」といった"人間の知恵"を具体的に与え、対話しながら導くほうが、アウトプットの精度がやはり高い。

単に「このEJBのコードをSpringBootに書き換えて」と丸投げするのではなく、人間が後輩のコードをレビューするかのように、こちらから思考のフレームワークとポイントを提示してあげるのです。

AIを「全自動の魔法使い」ではなく、「少し経験の浅いけどポテンシャルは高い部下」として扱う。そして、対話形式で一歩ずつ、一緒に仕事を進めていく。（結構、意見や散らばった内容をまとめるとかは、対話で話した内容をまとめてもらうといい感じになります!）
このやり方で、あの古代遺跡のようだったコードの読解や、クラス設計の見直しが、少しだけ、本当に少しだけですが、楽になりました。

6. 次の挑戦："匠の技"を「特化エージェント」へ

この発見は大きな一歩でした。しかし、同時に新たな、そして本質的な課題も見えてきます。
「このやり方、めちゃくちゃ属人化するじゃないか…」

私のスキルや勘に依存していては、チームの生産性向上には繋がりません。一人のスーパーマンが生まれても意味がないのです。
そこで今、私が次に見据えているのが、この**「匠の技」を、誰もが使える「特化エージェント」として仕組み化・民主化する**ことです。

そのために、いくつかのアプローチを仮説として立て、模索を始めたところです。
※特にプロジェクトによって実装の考え方が比較的異なると思いますが、それらを例外も含めて実装方針やコード規約にまとめるのはあまり現実的ではないので、そういう意味でも現在のソースコードを効果的に探索・参照する方法という意味で以下を検討しています。

RAG (Retrieval Augmented Generation):
まずは、プロジェクト固有のソースコードや設計思想をベクトル化してAIに読み込ませ、私たちのプロジェクトに関する「記憶」を持たせる。
MCP (Model-centric Platform):
様々なモデルやプロンプトの組み合わせを体系的に管理・評価する基盤を整え、個人のノウハウを組織の資産に変えていく。
モデルの再学習 (Fine-tuning):
最終的には、私たちのコードベースや文化に特化したモデルを再学習（ファインチューニング）させ、真に「私たちのプロジェクトの専門家」であるAIアシスタントを育てる。

これらはまだ構想段階ですが、千日手の中から次の一手を探し続けることが、今の私にできる唯一のことだと考えています。

7. おわりに

レガシーシステムのモダン化に、生成AIという新しい、そして強力すぎる変数を掛け合わせる。
この挑戦は、技術的にも、そして組織的にも、本当に一筋縄ではいきません。世の中のキラキラした成功事例の裏には、きっと私たちのようにもがき苦しんでいる、泥臭い試行錯誤が無数にあるのだと思います。（更に時間の経過によって、新しいモデルやツールがどんどん出ているので陳腐化もとても早そうなコスパの悪い戦い...）

この記事に書いたのは、まだ道半ばの、うまくいっていない話ばかりです。
でも、この奮闘の記録が、同じように巨大な壁に立ち向かっている誰かの「自分たちだけじゃないんだ」という勇気や、次の一歩を踏み出すための「地図」の切れ端にでもなれば、これほど嬉しいことはありません。

私たちの戦いは、まだ始まったばかりです。

おまけ. あなたの現場の“AI導入無理ゲー度”診断

3つ以上 チェックがついたら、仲間です。まずはチャットで愚痴り合いましょう。