第5章　確認した現行仕様をAI間で渡し、仕様書へ反映する

表の認識違いを、コードへ戻って確認する

Excel仕様書のレビューで現行仕様の認識違いが見つかった。Microsoft 365 Copilotへ各行を説明し直すだけでは、処理の前後関係まで伝えるやり取りが増える。

そこで、コードを参照できるGitHub Copilotで必要な情報を整理し、GPTで動的な処理構造として表現した。

確認した仕様を、次のAIへ渡す

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

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

Excel仕様書の認識違いを確認するため、GitHub Copilotで現行コードの情報を取り出しました。次のAIへ渡すプロンプトも人が確認し、未確認の回答を自動で連結しませんでした。

GPTで呼出し順序、分岐、入出力、エラー後の停止位置を処理構造として整理しました。表の各行を全体のどこへ位置付けるか、確認できるようにするためです。

生成した処理構造を人が実コードと照合し、誤りがあれば修正しました。コードを参照できないAIの説明を、コード上の事実として確定しないための確認です。

確認した処理構造をMicrosoft 365 Copilotへ渡し、Excel仕様書へ反映しました。読出し・復号のタイミング、分岐、停止位置、外部連携の条件を修正しました。

修正後の仕様書を、コード・処理構造・設計方針と再度照合しました。AI間で形式を変えることと、人が仕様の正しさを確認することを分けました。

仕様書を組織のサブ審議へ提出し、承認を受けました。AIの出力を組織の決定と混同せず、レビュー・承認を経た仕様を実装と単体テストの前提にしました。

整理したのは、処理の開始条件、関数・モジュール間の呼出し順序、レジストリの保存・読出し、暗号化・復号API、正常系と異常系の分岐、エラー後の停止位置、外部連携までの流れである。

図を通して、表の各行を処理全体のどこへ位置づけるかを確認した。

GPTによる構造化の前には、コード調査から作ったプロンプトを人間が確認した。生成した処理構造も実コードと照合し、誤りがあれば修正した。コードを参照できないAIの説明を、コード上の事実として確定することはしなかった。

確認した処理構造をMicrosoft 365 Copilotへ渡し、Excel仕様書へ反映させた。読出し・復号のタイミング、呼出し関係、分岐条件、停止位置、連携条件を修正した後、人間がコード・処理構造・設計方針との整合を再度レビューした。

AI Aの出力をAI Bへ自動投入する方式は採らなかった。人間が確認し、必要なら修正してから次へ渡すことで、誤った前提の連鎖を防ぎ、中間成果物と判断の変化を追えるようにした。

ここで受け渡したのは、未確認の回答ではなく、次の問いに必要な確認済みの情報である。

修正した仕様書は組織のサブ審議へ提出し、承認を受けた。AI間で形式を変換する工程と、組織として仕様を確定する工程は別である。レビューと承認を経た仕様を、次のコード修正と単体テストの前提にした。