考古学者とその副操縦士：MalykhinがJava 1.5でLLMを disciplina

Nik Malykhinは最新のハードウェア上でJava 1.5のベースを動かす必要があった。彼のLLMからの最初の回答はもっともらしく見えたが、リポジトリにうまく適合しなかった。解決策：彼の言葉を鵜呑みにせず、証拠に基づいて説明させること。

平易な言葉で

レガシーコードにLLMを投入すると、正しそうな回答が返ってくるが、実際のプロジェクトには合わないことがある。効果的な方法は、LLMにコード、テスト、成果物といった証拠に基づいて作業させることだ。

考古学者のような作業

2026年7月16日、martinfowler.comでNik Malykhinは、Java 1.5のコードベースを最新環境に移行した経験を語った。特殊な状況下での作業だった。最新の解析・リファクタリングツールはJava 1.5を苦手とし、多くは受け付けない。Malykhinの最初の試みは、直接LLMに修正を依頼することだったが、その結果は「plausible」な回答でありながら「did not hold up in the codebase」だった。見た目は良いJava 1.5のコードだが、実際のリポジトリには合わなかった。

転機は方法論にあった。MalykhinはLLMを執筆者としてではなく、解析者・検証者として活用した。各ステップをリポジトリに根ざして進めた：既存コードの丁寧な読み込み、テストや実行トレースに基づく仮説の検証、コード自体が示す以上の早急な判断を拒否する。記事のメッセージはシンプルだ：レガシーの近代化にLLMを使っても、考古学者のように速くは進まない。しかし、その過程で証明の穴は少なくなる。

中身の話

このパターンは現代のエージェントツールではevidence-first prompting、grounded reasoning、retrieval-firstなど複数の名前で呼ばれるが、共通するルールがある：LLMの主張は必ずリポジトリの成果物（ファイル、行、テスト）に紐づけなければならない。この制約がないと、レガシーにLLMを使った際の最もコストのかかる「偽陽性」を生む：ターゲットバージョンより後のAPI、存在しないメソッド、架空のインポートなどだ。

結論

レガシーコードに取り組むチームにとって、LLM「コパイロット」は書くためのツールではなく、見つけるためのツールだ。真の生産性はLLMに読ませることで得られ、推測させることではない。CTOにとっての教訓：AI支援による近代化プロジェクトの良い指標は「生成された行数」ではなく、「コード自体によって否定された仮説の数」だ。この違いは、成功するレガシープロジェクトと、再び負債を抱えるプロジェクトの分かれ目となる。