レガシー再生の現場：LLMで旧システムを読み解く
「動いているが、誰も触れない」旧システムを、LLM でコード解析し、リプレイスまたは引き継ぎ可能な資産に再生する実務の連載。仕様書のないコードの読み解き、塩漬けと作り直しの投資対効果、段階移行まで。読者リアクションに応じて拡充していきます。
仕様書のない旧システムを LLM で読み解く ── コード考古学の6ステップ
「動いているが、誰も触れない」システムを前に、いきなり作り直してはいけない。まず必要なのは、失われた仕様と依存関係を掘り起こす“コード考古学”だ。LLM を使って旧コード・ストアド・バッチを読み解き、挙動を特性化テストで固定し、投資判断に繋げるまでの6ステップを、現場の順序でまとめる。
巨大コードベースを LLM で要約する ── チャンキングとプロンプト設計
数十万行のレガシーは、コンテキストウィンドウに丸ごと入らない。ファイル・関数単位でどう刻み、どの順番で読ませ、要約をどう束ねて全体像にするか。溢れ対策・幻覚を減らす検証プロンプト・要約のナレッジベース化まで、実装の勘所を現場の順序で整理する。
特性化テストを自動で採取する ── 本番の入出力を安全に固定する
仕様書のないコードに安全網を張るには、まず「今の挙動」を固定する。手作業ではなく本番の入出力を自動採取して特性化テストにする現場のやり方を、匿名化・非決定性・CI組み込みまで含めて書く。
塩漬けか、作り直しか ── 移行方針を経営に説明する試算の作り方
旧システムを維持するか作り直すかは、技術の良し悪しではなく投資判断です。塩漬けの隠れコストと刷新リスクを同じ土俵に並べ、6R フレームで選択肢を整理し、経営が意思決定できる「1枚サマリー」に落とすまでを解説します。
ストラングラーパターンで止めずに移行する ── 旧新並行運用の実装
止められない基幹システムを、動かしたまま1機能ずつ新へ移す。ルーティングでの段階切替、旧新の二重書き込みと整合性チェック、フィーチャーフラグでの即時ロールバック、そして「どこまで移せば旧を退役させてよいか」の判断まで、並行運用の実装を現場の順序で書く。
履歴データをどう移すか ── 初期移行とスキーマ変換の設計
並行運用の前に、過去のデータを移す作業があります。何年ぶんを移すのか、壊れた古いデータをどう扱うのか。移行そのものより、判断のほうが難しい領域です。
誰がこのシステムを呼んでいるか ── 外部連携の棚卸し
移行の計画が崩れる最大の原因は、想定していなかった連携先です。誰が、いつ、どこから呼んでいるのか。記録から機械的に洗い出す方法を扱います。
メインフレーム資産の読み解き ── LLM が効くところ、効かないところ
COBOL や JCL は、いまの言語から距離があります。LLM である程度は読めますが、限界もはっきりしている。何を任せ、何を人が押さえるかを整理します。
移行を止めるのは技術ではない ── 合意形成という本丸
計画も設計もできているのに進まない。原因はたいてい技術の外にあります。誰が決めるのか、誰が反対しているのか、何を恐れているのか。構造として整理します。
いつ電源を切るか ── 退役の条件と、戻れる版の残し方
移行が終わっても旧システムは止まりません。「念のため」で動き続け、費用だけが発生する。止める条件を先に決め、止めたあとに戻れる形を用意する方法を扱います。
5年後に同じ状況にしない ── 再レガシー化を防ぐ設計
作り直したシステムも、放っておけば同じ道を辿ります。レガシーになるのは古いからではなく、触れなくなるから。何が触れなくするのかを構造として整理します。
まずは、現状を聞かせてください。
要件が固まっていなくて大丈夫です。現状診断と方針提案までを無料でお手伝いします。