レガシーコードの仕様をAIに読み解かせる｜仕様復元の進め方
「この機能、仕様書ありますか？」 「……たぶん、ないです。書いた人ももういなくて」
引き継いだ古いシステム。コメントはほとんどなく、変数名は flg2 や tmp。それでも、来週にはここに手を入れないといけない。読んでも読んでも、頭に入ってこない。
そんなとき、AIに全部貼りつけて「仕様書にして」と頼みたくなりますよね。 実際、AIはコードを読むのが得意です。うまく使えば、この途方もない作業をかなり軽くしてくれます。
ただ、丸ごと投げて出てきた「それらしい仕様書」を、そのまま信じるのは少し危ない。 AIは、書かれていないことまで「たぶんこうだろう」で埋めてしまうからです。
この記事は、レガシーコードの仕様をAIに読み解かせる進め方の型をまとめたものです。長く見えますが、全部は要りません。まず効く所から拾えば回ります。
30–60秒のファストパス（最低ライン）
- 範囲を絞る：いきなり全体でなく、今週触る1関数・1画面・1バッチだけをAIに渡す（30秒）
- 聞き方を変える：「仕様書にして」ではなく「このコードが何を入力に、何を出力し、どんな分岐で挙動が変わるかを、箇条書きで」（10秒）
- 印をつける：AIの答えのうちコードに根拠がある所と、推測で埋めた所を自分で区別する（20秒）
※機密（接続情報・個人情報・社内URL・鍵）が混ざっていたら消してから貼る。迷ったら一旦保留でOK。
結論：レガシーコードの仕様は、AIに「復元してもらう」ものではなく、AIと一緒に「仮説を立てて確かめる」もの。まず効くのは、①範囲を今週触る所だけに絞る → ②「入力・出力・分岐条件」の3点を箇条書きで出させる → ③AIが推測で埋めた所に印をつける → ④その仮説を現物のコードやログ・実データで1つずつ裏取りする。AIは読解を速める相棒であって、仕様を保証する人ではありません。
AIに頼るのは、手を抜くためではありません。 古いコードの前で固まる時間を減らして、「本当にそうか」を確かめる作業に集中するためです。
なぜレガシーの仕様復元は、AIと相性がよく・同時に危ういのか
AIは、目の前のコードから「何をしているか」を読み取るのは得意です。分岐、計算、ループ、入出力——ここは書いてある通りに拾ってくれます。
問題は、レガシーコードの本当のつらさが「書いていないこと」の側にあることです。
- なぜそうしたか（意図）：一見おかしな分岐が、実は昔の障害対応の名残だったりする
- 暗黙の前提：「この値は必ず正の整数」といった、コードに書かれていない約束事
- 外の世界とのつながり：別システムやバッチ、手作業の運用と噛み合って初めて成立する挙動
- もう使われていない部分：動いてはいるが、実は誰も通っていないデッドコード
AIは、こうした「書かれていない空白」を、もっともらしい説明で埋めてしまいます。それらしい仕様書ができあがるほど、埋められた推測に気づきにくくなる。ここが、いちばん危ういところです。
裏を返せば、「事実」と「推測」を分けて扱うとAIは一気に頼れる相棒になります。次から、その進め方です。
AIに渡す前の下ごしらえ——範囲を絞る
丸ごと貼るのをやめて、まず「どこを読み解きたいのか」を自分で決めます。ここを絞るだけで、AIの答えの精度も、自分の確認しやすさも大きく変わります。
①今週触る範囲だけに絞る
システム全体の仕様書を一度に作ろうとしないこと。 今回手を入れる1関数・1クラス・1画面・1バッチ——それだけをAIに渡します。範囲が小さいほど、AIは推測で埋める余地が減り、あなたも答えを検証しやすくなります。
②機密を外してから貼る
古いコードには、接続文字列・APIキー・個人情報・社内URLが直書きされていることが少なくありません。外部AIに貼る前に、そこは伏せ字にするかダミーに置き換えます。ここは急ぐときほど飛ばしやすいので、先に一手間かけておくと安心です（→社内データをAIに渡すときの線引き）。
③関連する周辺情報も少しだけ添える
その関数が呼ぶ定数、参照するテーブルの列名、呼び出し元——分かる範囲で一緒に渡すと、AIが空白を推測で埋める量が減ります（→既存コードベースにAIを馴染ませる文脈の渡し方）。
仕様を読み解かせる4つの手順
手順1：入力・出力・分岐条件の3点を出させる
いきなり「仕様書にして」ではなく、事実に近い3点から聞きます。
このコードについて、次の3つを箇条書きで教えてください。推測が入る場合は「推測」と明記してください。
1. 入力（引数・参照する外部データ・前提となる状態）
2. 出力（戻り値・副作用・書き込み先）
3. 挙動が変わる分岐条件（if/switch で何がどう分かれるか）
「推測なら推測と書いて」と一言添えるのがポイントです。これだけで、事実と推測の線引きがだいぶ見えるようになります。
手順2：AIが推測で埋めた所に印をつける
返ってきた答えを、自分で色分けするつもりで読みます。コードの行を指させる所は「事実」、指させない所は「推測」。「おそらく」「〜と思われる」「一般的には」といった言葉は、推測のサインです。ここに後で裏取りする印をつけておきます。
手順3：分からない所を「質問」に変えさせる
推測で埋まった空白は、そのまま放置せず、確認すべき問いに変えてもらいます。
このコードで、仕様として確定できない・元の意図が読み取れない箇所を、確認すべき質問のリストにしてください。
「なぜこの分岐だけ例外処理が違うのか」「このマジックナンバー 86400 は何の値か」——こうした問いが、そのまま元担当者への確認事項や、調査の入口になります。
手順4：仮説を現物で1つずつ裏取りする
最後は、AIの外に出て確かめます。ここを省くと、レガシーの罠にそのまま足を突っ込むことになります。
- 分岐条件は、実際のコードの該当行を自分の目で追う
- 「この値は正の整数」といった前提は、実データやDBの制約で確かめる
- 通らないはずの分岐は、ログや簡単なテストで本当に通らないか見る
1つでも「AIの説明と現物が食い違う」ものが見つかったら、その周辺の仕様はいったん全部疑ってかかると安全です。
AIが復元した仕様を鵜呑みにしないために
読み解きが進むと、AIの説明はどんどん滑らかになります。滑らかさは、正しさとは別物です。最後に、次の点だけ確かめておくと事故を防げます。
- 存在しない関数・設定を、それらしく挙げていないか（もっともらしい誤り＝ハルシネーション。→AIのハルシネーションの見抜き方）
- 「たぶん使われていない」を鵜呑みにして消していないか（デッドコードの判断は、呼び出し元とログで裏を取ってから）
- 古い言語・フレームワークの前提でズレていないか（AIが新しい版の挙動で説明していないか）
- 意図の説明を、事実として書き換えていないか（「なぜ」は基本、推測だと構えておく）
ここまで来たら、AIと確かめた内容を短い仕様メモに残しておくと、次に触る人（未来の自分を含む）がずっと楽になります。完璧な仕様書でなくていい。「入力・出力・分岐・未確認の問い」の4項目を箇条書きで残すだけで十分です。
そのまま使えるチェックリスト
- 全体を一度にではなく、今週触る1関数・1画面・1バッチに絞ったか
- 接続情報・鍵・個人情報を伏せてから貼ったか
- 「入力・出力・分岐条件」の3点を、推測明記つきで出させたか
- AIの答えを「事実（行を指させる）」と「推測」に分けて印をつけたか
- 埋まらない空白を、確認すべき質問のリストに変えたか
- 分岐条件を、実際のコードの該当行で自分の目で追ったか
- 「この値は必ず〜」という前提を、実データやDB制約で裏取りしたか
- 「使われていない」の判断を、呼び出し元とログで確かめたか
- 確定した内容を、短い仕様メモ（入力・出力・分岐・未確認の問い）に残したか
明日やること
いきなり全体を読み解こうとしなくて大丈夫です。 明日は、今週いちばん触るのが怖い1関数だけを選んで、手順1の「入力・出力・分岐条件を出させる」から始めてみてください。それだけでも、正体不明だったコードの輪郭が、少し見えてきます。
レガシーの読み解きは、一度で全部を明らかにする仕事ではありません。 今日ひとつ範囲を絞って、AIと一緒に仮説を立てて、現物で確かめる。その積み重ねで、いつの間にか「触れる範囲」が広がっていきます。焦らなくて大丈夫です。