第2章　異常系の構造を整理し、設計方針を確定する

保守の制約を先に決める

異常系を網羅しようとすれば、再試行や自動修復を含む多くの実装が考えられる。

しかし、今回の目的は既存ソフトウェアの暗号方式変更であり、正常系を全面的に作り直すことではなかった。発生頻度、工数、安全性、変更範囲、保守性、アプリケーションが担う責務を前提として整理した。

仕様検討には、一つのAIだけを使わなかった。コード上の影響はGitHub Copilot、設計上の選択肢はGPT、過去資料や背景はMicrosoft 365 Copilotが参照する情報に違いがある。一つの変更についても、それぞれのContextを必要に応じて確認し、人間が統合して判断した。

安全性と保守の制約から、方針を決める

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

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

発生頻度、工数、安全性、正常動作への影響、保守性、アプリケーションの責務を前提として整理しました。暗号方式の変更が目的であり、正常処理の全面刷新には広げない基準を先に置きました。

GPTで異常時の復旧方法や停止条件の選択肢を検討しました。コードの影響や過去背景は別のAIが参照できる情報も確認し、一つの回答だけでは仕様を決めませんでした。

個別の自動修復を増やす案と、安全に停止させる案を比較しました。低頻度の異常に対して修復処理を増やすと、検証・保守の対象も増えることを考慮しました。

人が安全性・工数・保守性を比較し、不正な資格情報で処理を進めない方針を選びました。AIは比較材料を整理する役割であり、採否をAIの回答へ委ねませんでした。

上司のレビューを受け、組織の設計方針として確認しました。その方針を前提に、正常動作を維持しながら必要な停止処理をコードのどこへ入れるか調べました。

GPTで個別の復旧方法を検討したが、低頻度の異常に対して修復処理を増やすと、検証と保守の対象も増える。異常の原因を区別することと、原因ごとに自動復旧を実装することは分けて考えた。

資格情報を安全に使えない場合は処理を止め、利用者へ再インストールを案内する方針を採った。UIの表示位置のような低影響の値とは扱いを分け、外部連携へ不正な値を渡さないことを優先した。

OSやユーザープロファイルに関わる問題まで、アプリケーションが修復する構成にはしなかった。アプリケーションの責務は異常を検出し、危険な後続処理を止めるところまでとした。

この方針はAIの回答で確定したわけではない。安全性・工数・保守性を人間が比較し、上司のレビューを受けて組織の設計方針として確認した。その後、コード上のどこへ対応を入れるかを調査した。