第12章 QAで暗号処理を調査し、人間の変更判断へつなぐ

セキュリティ要件の変更で、既存の暗号処理を調べる

QAチャットの活用を始めた直後、セキュリティ要件の強化対応が必要になった。対象には開発当時の暗号方式が残っていた。どの方式を使い、どこで処理しているかを確認し、変更方針を検討する必要があった。

従来ならコードを解析し、処理と実装箇所を探し、変更可能な範囲を調べる。既存仕様書だけでは内部仕様に到達できず、詳細な知識も共有されていなかったため、調査には数日から1週間以上掛かる可能性を想定していた。この期間は従来手順の見通しであり、比較試験で測定した値ではない。

内部構造をRAGとして整理していたため、QAで使用方式と該当する処理の位置を確認できた。さらにAIに変更候補と理由を提示させ、その理由を人間が検証した。

この対応では、半日足らずで対応方針を確定し、フィージビリティ確認へ移った。候補が出たことを仕様の確定とはせず、組織のルール、セキュリティポリシー、将来の影響も人間が確認した。

この場面では、委託先へ問い合わせず社内で調査と検討を進められた。取り組み全体では社員工数25％削減・委託費半減を目標とし、取り組みでは目標の大半を達成した。

ただし、この場面だけの実測削減率や、個々の目標の達成値は公開していない。目標をそのまま実績値へ読み替えることはできない。

ここで確認できたのは、調査結果を残したことで、次の変更で方式・処理位置・選択肢を探す起点を持てたことである。委託開発費の削減はQAチャット構築の対象外としていた領域であり、今後の検討として区別する。

この事例を通じ、古いシステムを理解する作業は、図や文書を作って終わるものではなかった。現行の処理へ到達でき、その知識を後の問い合わせや変更検討へ戻せることが必要だった。

AIは候補と理由を整理できるが、現在の状況でどれを選ぶかまで固定できるとは限らない。仕様を復元し、人とAIに適した形で参照できるようにし、採否は人間が決める。この分担が、廃止できないシステムを理解・変更できる状態へ戻す取り組みの結論である。