複数AIを使い分けるレガシー保守

暗号方式の変更を、保守工程全体の問題として捉える

CRA対応に伴うセキュリティ要件の強化を契機に、既存システムの暗号処理と異常系を見直した。対象はパスワードを暗号化してレジストリへ保存し、利用時に読み出して復号する仕組みだった。

CNG APIおよびDPAPIを利用する方式へ変更すると、暗号APIのエラー処理が必要になる。レジストリ値の欠落・破損・読出し失敗も整理しなければならない。

コードを書き換える前に、どこで異常を検出し、どこで止め、何を復旧対象にするかを決める必要があった。

この問いに答える情報は、一つの場所に揃っていなかった。コード上の実装、過去資料に残る背景、仕様として検討すべき条件をつなぐため、複数AIを利用した。

製品の順位ではなく、問いに必要な情報から選ぶ

GitHub Copilotはコード全体や変更影響の調査に、Microsoft 365 CopilotはOffice文書・過去資料・背景事情の確認に利用した。

GPTには、人間が与えた条件や調査結果を基に、問題整理、仕様検討、設計上の選択肢の比較を担わせた。

これは「調査AI・実装AI・文書AI」という固定分担ではない。その問いに必要なContextへ、どのAIがアクセスできるかが出発点だった。

仕様を検討するときも、必要に応じてすべてを利用した。現行コードへの影響、設計としての妥当性、過去にそうなった背景は、それぞれ別の情報にあるためである。

全体のつなぎ方と、人間が確認する位置を次の図に示す。

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

どこでAIを使い、どこで人が判断するかを示しています。

詳しい説明

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

調べることを決める

人が問い合わせや変更の課題を整理し、何を調べるか決めました。コード・仕様の検討・過去背景など、必要な情報へどのAIがアクセスできるかを基準に使い分けました。

仕様を調べる

GPTで制約、要件、異常時の選択肢を整理しました。仕様の検討では他のAIから得たコード上の事実や過去背景も必要に応じて合わせ、一つのAIの回答だけで方針を決めませんでした。

コードを調べる

GitHub Copilotで関連コード、呼出し関係、変更影響を調べました。AIが挙げた候補は人が実際の処理と運用条件を確認し、今回の変更へ含めるかを判断しました。

過去資料を調べる

Microsoft 365 Copilotで過去資料やOffice文書・メールの背景を確認しました。コードだけでは分からない経緯を補い、検討結果をExcel仕様書へ集約する際にも利用しました。

調査結果をまとめる

仕様の検討、コード調査、過去背景を組み合わせ、レビューできる形へ整理しました。複数AIの結果を人が確認して次へ渡し、誤った前提がそのまま連鎖しないようにしました。

人が確認して直す

人がコード・処理構造・仕様書の整合を確認し、必要なら修正しました。AIの回答が食い違った場合は、その問いに必要な情報を参照できるAIの材料を重視し、採否は人が決めました。

人が決めて進める

人のレビューと組織の承認を経た仕様を基に、実装・確認・単体テストを進めました。AIへ判断責任を移さず、コード調査だけでなく仕様検討や過去背景の確認まで支援範囲を広げました。

自動復旧を増やす前に、止める条件と責務を決める

人間側で、正常系への影響を抑えること、安全側へ停止すること、発生頻度の低い異常に過大な改修工数を掛けないことを前提に置いた。GPTとの対話では、原因ごとの復旧処理を増やす案も比較したが、複雑化と将来の保守負担が残る。

そこで、復号できない値は利用せず、正常性を確認できない場合は後続処理へ進ませない方針とした。

利用者向けの基本的な復旧はアンインストール・再インストールへ共通化し、OSやWindowsユーザープロファイルなど、ソフトウェア単体で制御できない領域は責務外とした。

保存情報の重要度も区別し、UIの表示位置を暗号化パスワードと同じ扱いにはしなかった。

方針は人間が選び、上司レビューで承認を得た。その後、コードを参照できるGitHub Copilotで変更候補を探し、人間が実コードと運用条件から必要な変更へ絞った。

AI間の受け渡しで、前提を確認し直す

検討結果をMicrosoft 365 CopilotでExcel仕様書へ集約すると、処理順序や呼出し関係の誤りが見つかった。コードと照合する中で、人間自身の現行仕様に対する理解も一部修正した。

Excelを一行ずつ直すだけでは、処理全体の関係を伝えるやり取りが増える。

そこでGitHub Copilotでコード上の情報を整理し、GPTで処理構造の図へ変換した。人間が実コードと照合した内容をMicrosoft 365 Copilotへ渡し、Excelへ反映した。

AI Aの出力をAI Bへ無条件で直結したわけではない。人間が確認し、必要に応じて修正し、次へ渡してよいかを決めた。これはレビューを最後に一度だけ置く方法ではなく、異なる情報をつなぐたびに前提を確認する工程だった。

回答が食い違った場合も、常に同じAIを優先しなかった。実装ならコードに近い情報、過去経緯なら背景資料、仕様の検討なら整理された条件を重視する。問いと参照情報の一致度で確認の起点を変え、採否は人間が決めた。

承認した仕様を、小さな変更単位で実装する

修正した仕様はサブ審議で承認を得た。

実装では全体像を共有してから、関数単位でGitHub Copilotの修正案を扱い、人間がレビューと単体テストを行った。既存の正常系を不用意に変えず、必要な異常系を追加する範囲へ限定した。

コード生成だけを切り出すのではなく、要件、コード上の事実、確認済みの仕様、承認、実装を接続した。AIが案を作る工程と、組織として確定・実行する工程の間には、人間の確認を残した。

コード支援から、一連の保守業務へ適用範囲を広げた

今回の対応は、要件整理から仕様書作成、コード修正、単体テストまでを内製で進め、従来必要だった外部委託を不要にした。開発期間は、当初想定していた期間との比較で約7割短縮した。

これは既存の公開実績であり、各AIや各工程だけの効果を切り分けた値ではない。

重要だったのは製品数ではなく、コード調査、変更影響分析、仕様検討、過去背景の確認、実装支援まで情報をつなげたことである。

一つのAIだけなら、そのAIが参照できる範囲に支援も寄りやすい。異なる情報源を組み合わせることで、人間が判断責任を持ったまま、AIを使える保守業務の範囲を広げた。

この事例から得たこと

AIの選択と回答の扱いは、製品への固定的な信頼順位では決められなかった。必要な情報に近い回答を確認の起点にし、人間がコード・仕様・背景を統合する構成が必要だった。

成果物を渡す工程にも意味がある。処理構造の図やExcelは出力形式にとどまらず、別のAIへ前提を伝え、人間が内容を確認する媒体になった。

ただし、今回の対象は変更範囲を限定できる完全化保守だった。広範なアーキテクチャ変更でも同じ進め方が成立するとは限らない。詳しい実装手順と成立条件は各章で扱う。