第6章　全体像を共有しながら、コード生成と単体テストを進める

全体像を共有してから、関数単位へ分ける

承認済み仕様を基に、GitHub Copilotへ処理全体の構造や関数間の関係、必要なUI情報を共有した。関数だけを切り出すと、入力の前提や後続処理への影響が抜けやすい。

ただし、情報を渡したことをもってAIが全体を完全に理解したとは扱わなかった。

関数ごとに、生成・レビュー・試験を進める

＋の付いた項目を選ぶと、詳しい説明が下に表示されます。

気になる項目を選ぶと、その役割や判断理由を確認できます。

承認済み仕様と、処理全体の構造・関数間の関係・必要なUI情報をGitHub Copilotへ共有しました。関数だけを切り出すと入力の前提や後続への影響が抜けやすいためです。

対象関数の役割と追加するエラー条件を確認しました。正常動作を維持し、関係のない名前変更や依存関係の変更へ広げない基準を置きました。

GitHub Copilotで関数単位の修正案を生成しました。承認済み仕様を前提に必要な異常系対応へ絞り、生成できたことだけで採用を決めませんでした。

人がコードをレビューし、ビルドと単体テストで確認しました。APIの成功・失敗、レジストリ値がない場合、既存の正常動作を見て、期待結果も仕様から人が確かめました。

問題があれば修正案を見直し、再生成したコードもレビュー・ビルド・単体テストで確認しました。修正後の確認を省略せず、既存動作への影響と修正範囲を確かめました。

確認した関数から次の対象関数へ進めました。対象が残っていれば同じ確認を繰り返し、生成したコードの採否と期待結果の判断は人に残しました。

対象関数の役割と追加するエラー条件を確認し、関数単位で修正案を生成した。人間がコードをレビューし、ビルドと単体テストで確認してから次の関数へ進んだ。問題があれば修正案を見直し、再生成したコードも再度レビュー・試験した。

今回の目的に関係しないリファクタリング、名前の変更、依存関係の変更は広げなかった。正常系を維持し、異常時に必要な位置で止まることを、変更範囲を限定する基準にした。

APIの成功・失敗、レジストリ値がない場合、既存の正常動作などを確認した。AIに試験案を出させても、その期待結果が承認済み仕様と合っているかは人間が確認する。コードが生成できたことと、変更を採用できることは分けて扱った。

この反復により、異常系への対応を実装しながら、既存動作への影響と修正範囲を確認した。