AIで既存コードを直す前に、現状の振る舞いをテストへ残す

仕様が十分に残っていない処理では、既存コードそのものを仕様書として扱うと判断を誤ります。動いている振る舞いには、守るべき業務ルール、利用者が依存している互換性、偶然残った不具合が混在し得るからです。そこで、まず「現状を再現できた」という記録と、「今後もそうあるべきだ」という要件を別の欄に置きます。AIへ修正を頼むのは、その区別を人が承認した後です。

2026年9月21日時点で、[GitHubのAI生成コードのレビュー手順](https://docs.github.com/en/copilot/tutorials/review-ai-generated-code)は、最初に自動テストと静的解析を実行し、コンパイル、テスト、警告やエラーを確認するよう案内しています。同じ資料は、プロジェクトの目的、アーキテクチャ、要件、設計パターンとの一致を確かめ、README、文書、最近のプルリクエストをAIへ渡す文脈の起点にすることも示しています。ここまでが公式のレビュー案内です。仕様不明の処理で観測用テストと変更用テストを分ける部分は、これらを実務へ落とすための提案です。

既存のテストが通るかだけでは、修正前の境界は見えません。テストがない分岐もあれば、現状と食い違う古い期待値もあり得ます。先に対象を一つの処理へ絞り、入力、設定、呼び出し元、出力、保存や通知などの副作用を固定して実行します。そこで得た結果には、まだ「正しい」と書かず、「観測した」とだけ書くのが要点です。

検討用の例として、仕様書が見つからない社員台帳CSVの取込処理を考えます。観測すると、社員コードの前後空白は除かれ、存在しない部署を含む行は拒否され、退職日が空の行は受け入れられ、同じ社員コードが重複すると後の行で上書きされました。分類方法を示すために置いた条件であり、実在する導入事例ではありません。この段階では、どの結果も業務上正しいとは断定しません。

担当者への確認で、重複した社員コードを黙って上書きする振る舞いだけは修正すると決まったとします。期待結果は「重複を検出したら取込を成立させず、対象を確認できるエラーにする」です。他の三つは正しいと認定できなくても、今回の差分では維持する扱いにできます。判断できないものを全部直すより、変更理由がある一つと、変えない三つを明示するほうがレビュー可能です。

台帳の一行には、入力・前提条件、観測した現状、扱い、変更理由、対応するテストを並べます。たとえば「社員コードに前後空白がある／空白を除いて登録／維持／今回の対象外／観測用テスト」、「同じ社員コードが複数行にある／後の行で上書き／変更／意図せぬ更新を防ぐ／変更用テスト」と記録します。部署不明と退職日空欄も同じ形式で残し、口頭の判断だけをAIへ渡さないようにします。

ここで迷うのは、上書きという現状も先に観測用テストへ固定すべきかどうかです。修正前の再現確認として一度は実行してよいものの、永続的に通す回帰テストの期待値を「上書き成功」にすると、直した瞬間に古い不具合を守るテストになります。変更対象については、修正前に失敗を再現した記録と、修正後に満たす期待結果を区別します。維持対象の観測用テストとは役割が違います。

観測用テストは、今回変えない入力に対して、修正前後で出力と副作用が同じであることを確かめます。社員コードの空白、存在しない部署、退職日空欄をそれぞれ独立したケースにし、複数の条件を一つへ詰め込みません。失敗したとき、どの観測結果が変わったかを差分から判断できる名前にします。テスト名やコメントには「現状維持」と読める表現を選び、「正しい仕様」とは書きません。後から正式な要件が判明したときに、再分類できる余地を残すためです。

変更用テストは、重複社員コードに対する新しい期待結果だけを示します。AIには、まずそのケースで修正前の実装が期待を満たさないことを確認させ、次に最小の実装差分を作らせます。このとき、既存テストの削除やスキップを修正として認めません。2026年9月21日時点のGitHub公式資料も、AI固有の注意点として、存在しないAPI、無視された制約、誤ったロジックに加え、失敗したテストが削除・スキップされていないか、見た目が妥当でも意図と一致するかを確認するよう案内しています。

修正後に両方のテスト群を実行します。変更用テストが通っても、空白除去や部署不明の扱いまで変わったなら、依頼範囲を越えた差分です。反対に、観測用テストだけが通り、重複時の期待結果を満たさなければ、不具合は直っていません。二群を分けることで、「従来どおり動く」と「直すと決めた箇所が変わる」を同時にマージ条件へ置けます。

AIによる修正は、観測用テスト、変更用テスト、実装差分、変更理由を同じプルリクエストへ置きます。2026年9月21日時点の[GitHubのプルリクエスト公式資料](https://docs.github.com/en/pull-requests/reference/pull-requests)では、説明・履歴・コメント・レビュー、コミット履歴、自動テストなどのチェック、変更差分を同じ変更単位の文脈として確認でき、マージ前の議論とレビューに利用できます。ここまでは製品仕様です。四つの材料を必須にする部分は、これらの機能を使うチーム側の運用条件です。GitHubがこのテスト手法を要求しているわけではありません。

レビュー担当者は、台帳の「扱い」とテストケースの対応を先に読みます。次に、実装差分が変更対象だけへ収まるか、維持対象のテストが通るか、失敗していた変更用テストが期待どおり通るかを確認します。AIがテストを都合よく書き換えていないかも差分で見ます。より広いブランチ運用やCIへの組み込みは、AI駆動開発の開発フロー｜レビュー・テスト・CIで人の判断を残すで確認できます。

AIに渡せるファイルや実行権限も、テストの信頼性に関わります。対象外のデータや認証情報へ触れさせず、許可する操作と人の承認が必要な操作を先に定めます。導入時の権限とデータ管理は、Claude Codeのセキュリティ｜法人導入前に決める権限とデータ管理も判断材料になります。ツール固有の機能と、自社で採用するレビュー条件を混同しないことが大切です。

業務担当者に確認できない、ログが足りない、外部連携の再現環境がない。そのような条件は「未決」として台帳に残します。AIに推測させて期待値を埋めると、もっともらしいテストが誤った要件を固定します。未決のケースは今回の修正対象から外し、対象の分岐へ変更が及ばないかを人が差分で確認します。必要なら調査タスクを分け、要件が決まってからテストへ移します。

2026年9月21日時点の[NIST SSDF Version 1.1](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf)にあるPW.8.2は、実行可能コードのテストについて、範囲設定、設計、実施、結果の文書化を行い、発見した問題と推奨修正を開発ワークフローまたは課題管理システムへ記録してトリアージすることを示しています。また、過去に報告された脆弱性のテストをテストスイートへ組み込み、エラーの再混入を防ぐことを実装例に挙げています。これはセキュア開発の公式指針です。台帳の各行を維持・変更・未決へ分類する方法は、その考え方を今回の修正判断へ適用した実務上の提案です。

完了条件はテストの本数では決まりません。対象範囲を説明でき、観測結果と期待結果が分かれ、未決事項に所有者と次の確認先があることを確かめます。仕様が不明な全挙動の保存も、AIによる一括変更も採用せず、判断できる範囲だけを変更可能な単位へ切り出します。

自社で始める条件は、仕様が完全にそろっていることではありません。対象処理を限定でき、同じ前提で現状を再現でき、維持・変更・未決を承認する責任者がいて、二種類のテストと実装差分をマージ前に確認できることです。一つでも欠けるなら、AIへ修正を任せる前に調査を続けます。とりわけ、未決の結果をAIが補完した期待値で埋めないことを停止条件にします。

社員台帳の例なら、空白除去、部署不明、退職日空欄は当面の維持対象として観測用テストへ残し、重複社員コードだけを変更用テストで新しい期待結果へ導きます。修正後は両群を実行し、テストの削除やスキップがなく、実装差分と変更理由が対応していることを人が確認します。これなら、現状を丸ごと正当化せず、不具合だけをAIの変更範囲として渡せます。

AIに正解を推測させず、人が決められる範囲を先に明らかにします。観測は証拠、維持は今回の境界、変更は承認された要件、未決は停止の印です。この区別を台帳、二種類のテスト、プルリクエストに一貫して残せることが実行条件です。満たせるチームは、仕様不明の既存コードでも修正前の確認から小さく始められます。