テストの分母を移行先に置くと
移していない機能は最後まで見えません

AIでのレガシー刷新を提案されている方へ

既存システムの刷新でAIを使う提案を受けていて、見積もりと進め方を判断する段階の発注側に向けて書いています。

刷新の提案書は、たいてい移した後のことが書かれています。変換率、自動生成率、削減工数。この記事で扱うのは、その裏側にある移せたかどうかをどう確かめるかです。

動いているのに、移っていない

クラスメソッドが2026年8月20日に公開した記事に、具体的な数字が出ています（AIに任せたレガシーシステムのモダナイズで、仕様の移行漏れに気づけないのはなぜか・荒木智仁）。

移行先を調べたところ、実装されているのに画面から一度も呼ばれていないAPIが数十本見つかった、という話です。作られてはいる。ただ、どこからも使われていない。逆に言えば、画面側のつなぎ込みが移っていません。

それでも移行後のシステムは動きます。だから気づけない。

AIは「読んでいない範囲」を報告しません

なぜ抜けるのか。同記事は原因をはっきり書いています。AIが何をどこまで読むかを自身で決めていて、その判断が人から見えないからです。

人が調査するときは、読んだファイルの一覧が残ります。読み切れなかった範囲も「ここは未着手」として自覚されます。AIに一式を渡して読ませると、この境界が消えます。開かれなかったファイルや、移行対象として拾われなかった処理について、AIはどこを読んでいないかを正確には報告しません。

出力は同じ体裁で返ってきます。読んだ結果としての整った要約と、読まずに書いた整った要約は、見た目で区別がつきません。

0件には2種類あります

ここが一番効く指摘です。

資料を読んだ結果として該当が0件だったのか、そもそも資料を開いていないから0件なのか。この2つが同じ見た目になります。

漏れは3か所で起きます

同記事は漏れを3つに分けています。それぞれ気づき方が違うので、分けて確認します。

3つ目が厄介です。コードの漏れはコンパイルやテストで表面化することがありますが、画面の漏れは動いてしまうぶん検出が遅れます。ボタンが1つ消えていても、残ったボタンは正しく動く。

仕様が残っていないシステムを調べる工程そのものはブラックボックス化したシステムをAIで読み解くで扱いました。あちらは移行前の調査、この記事は移行後の検収です。

分母を現行側に置く

対策の核心は1行です。テストケースを、移行先のコードからではなく現行システムから数える。

移行先を分母にすると、そこにある機能は全部テストできます。ただし、そこに無い機能はテストの対象にすらなりません。移していないものは、移行先を見ている限り永久に出てきません。分母を現行側へ移すと、はじめて「現行にあってテストが書けないもの」として浮かびます。

自動化率の高さを掲げる提案で先に確認すべき点は自動化率85%より先に決めるのは テストしない範囲ですでも書きました。あちらは合意すべきテスト範囲の話で、こちらはその範囲をどちら側から数えるかの話です。両方ずれていると、抜けは二重に見えなくなります。

現行にテストがあるかで手順が分かれます

現行にテストコードがある場合は楽です。テストコードも一緒に移行対象に含め、移行後に現行と同じケースを流します。通ったかどうかが機械的に確認できます。

現行にテストコードがない場合、ここが本番です。移行の前に、現行のソースコードから仕様を漏れなく起こしてテストを作る工程が要ります。この工程を見積もりから外したまま「AIが変換するので短くなります」と言われていたら、抜けたのは工数ではなく検収の手段です。

そしてどちらの場合も、AIに読ませる範囲は人の側で確定させます。一式を渡して選ばせるのではなく、読む対象のリストを先に固定してから読ませる。選別をAIに任せた時点で、冒頭の「見えない境界」が戻ってきます。

検収で突き合わせる項目

移行の完了報告を受け取ったときに確認してください。

移行元がメインフレームか国産スタックかで効き方が変わる話はメインフレーム撤退で期限が切られましたにまとめてあります。

動いたことは、移ったことの証明ではありません

移行後のシステムが起動して、主要な画面が開いて、代表的な操作が通る。ここまでは移していない機能があっても成立します。

刷新の提案書を読んでいる段階でしたら、お問い合わせからご相談ください。テストケースをどちら側から数える計画になっているか、見積もりの読み方からご一緒します。