第3章コード探索と人間の確認で、変更箇所と実現方法を絞る

確定した方針から、変更箇所を探す

処理を止める条件と責務を決めた後、GitHub Copilotで関連コードを探索した。文字列の一致だけではなく、暗号化・復号、レジストリの保存・読出し、値の利用先という意味から、呼出し関係と変更影響の候補を調べた。

方針を、最小限の変更箇所へ落とす

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

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

安全に止める条件と、アプリケーションが担う範囲を確認した方針です。調査対象を暗号方式の変更に絞り、OS側の修復や関係のない改修へ広げない基準にしました。

GitHub Copilotで暗号化・復号、保存・読出し、値の利用先を意味から探索しました。文字列の一致だけでなく、呼出し関係と変更影響の候補を調べました。

AIが挙げた箇所について、前後の処理、到達条件、実行順序、値の用途を人が確認しました。コード上で問題に見えても実運用で影響するとは限らないため、候補のまま採用しませんでした。

前段の処理や運用条件で問題を回避できている箇所と、今回対応すべき箇所を区別しました。AIの指摘を全部取り込まず、目的に関係する影響があるかで絞りました。

APIの戻り値を確認し、必要な位置で後続処理を停止する方法を具体化しました。正常系への変更は最小限にし、利用者への復旧案内と責務分界を先に確認した方針へ合わせました。

AIが挙げた箇所は調査候補であり、そのまま修正対象ではない。前後の処理、到達条件、実行順序、値の用途、運用条件、外部連携への影響を人間が確認し、今回の変更に関係するものを絞った。

コードだけを見れば問題に見える箇所でも、前段の処理や運用条件によって実際には問題にならない場合がある。AIの指摘をすべて取り込むのではなく、実運用で影響が生じるかを確認した。今回の目的に関係しない整理や改修は対象から外した。

AIの指摘を、改修対象にするか確かめる

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

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

AIの指摘は、関連コードと変更影響の調査候補として扱いました。設計上の粗さがあっても実際の問題とは限らないため、そのまま改修対象にはしませんでした。

到達条件、前後の処理、値の用途、実行順序、運用条件を人が調べました。今回の変更によって実際に影響が生じるかを判断するための確認です。

今回の変更に関係する影響が、実運用で生じると確認した場合です。必要なエラー処理や停止条件を、改修対象に含める判断へつなぎました。

前段の処理や運用条件によって、実際には問題にならない場合です。コードの見た目だけで問題と決めず、今回の修正範囲から外す判断につなぎました。

確認した必要箇所へ対応を追加しました。正常系を維持し、不正な値で進ませないことを基準に、変更範囲を限定しました。

今回の目的に関係しない整理や改修は対象から外しました。AIが改善案を提示できることと、この変更で採用すべきことを分けました。

AIの回答が食い違った場合も、製品の信頼順位を固定しなかった。コード上の事実にはコード全体を参照できるGitHub Copilot、設計の検討にはGPT、過去経緯にはMicrosoft 365 Copilotを重視し、問いとContextの一致度を基準に材料を選んだ。

採否は人間が決めた。

APIの戻り値を確認し、復号に失敗した値を使わず、必要な位置で後続処理を停止する構成へ絞った。利用者への復旧案内、OS側の問題との責務分界も、先に確認した方針へ合わせた。

関連箇所が分かったからといって、全体の設計を変える必要はない。正常系への変更を最小限にし、必要なエラー処理を追加する方法を具体化した。