既存コードの調査をAIに任せる前に：Sourcegraphから考える、検索結果と変更判断の境界

A&Aの考え方

既存システムを調べる実装者に、A&Aが勧めるのは、変更案と一緒に「その案を支える範囲」を返してもらうことです。今回なら、項目を書き出す場所、そこへ入る経路、受け取り側の条件を調べます。説明が自然であることと、影響範囲を確かめたことを別に扱います。読むファイルを増やすこと自体ではなく、変更判断に残る穴を明らかにするのが目的です。

A&Aの考え方

ここから得る視点は、回答に必要な材料を、目の前のコード片だけで決めないことです。ただし、コードベースを参照できる機能があるだけで、自分の依頼に必要な経路をすべて読んだとは判断しません。以下の調査記録は、この視点をA&Aが実装作業へ当てはめた提案です。Sourcegraphが同じ記録様式を使った、障害を減らした、という主張ではありません。

A&Aの考え方

まず、対象リポジトリとコミット、調べる動作、読める範囲を固定します。「CSVの項目削除の影響を調査。今回はコード変更なし。根拠はファイル・関数・該当箇所へ戻れる形で返す」と依頼できます。検索結果には、使った語句と対象範囲も添えます。ヒットしなかったときは「この範囲では見つからない」と書き、利用箇所が存在しないという結論に置き換えません。

A&Aの考え方

根拠の表には、確認できた関係、その根拠、未確認点と次の確認先を並べます。コードを読んで分かったことと、実行して観測したことも区別してください。本番設定を読めないなら、その制約を残します。調査のために秘密情報や顧客データを無断でAIへ渡す必要はなく、まず承認済みのコードと架空の入力で確認できる範囲を進めます。

A&Aの考え方

実行時の設定で経路が変わる可能性を疑うなら、設定を含む確認が次の仕事になります。確認できない場合は「この経路に限った変更案」として止めます。調査を終えたことと、変更を実装して公開できることは別の状態です。この例の調査結果に期待するのは、修正ファイルの断定ではなく、どの経路なら説明でき、何を確かめれば実装へ進めるかです。

A&Aの考え方

A&Aの提案では、既存テストが何を確かめているかを先に読みます。CSVを作れるだけのテストなら、受信先で正しく読み込めるかは別に確認します。期待値は変更後の出力を写して決めず、合意した入出力例から置きます。変更前の状態でも失敗していたテストは記録を分け、今回の変更で直した、または壊したと早合点しません。

A&Aの考え方

調査の受け取りでは、別の担当者が根拠の箇所へ戻って経路を説明できるかを確かめます。未確認の経路が残っても、誰が何を調べるかが明確なら引き継げます。一方、呼び出し元も利用側も見通せる局所的な変更では、大きな調査表を作る必要はありません。変更の大きさではなく、見えていない依存関係に合わせて記録を増減させます。

A&Aの考え方

試すなら、過去に影響確認で迷った小さな変更を選び、従来の調査記録と比べます。根拠をたどり直す時間、見落とした利用経路、未確認のまま実装へ進んだ箇所を見ます。AIの回答速度だけでなく、実装者の確認時間、ツール費用、索引や設定情報を新しい状態に保つ負担も含めます。速く答えられても、別の担当者が同じ調査をやり直すなら、引き継ぎは改善していません。

A&Aの考え方

返却物は「対象の版」「確認した経路と根拠」「未確認の依存先」「次に必要な確認」「実装案が成り立つ条件」を短くまとめれば始められます。A&Aに既存システムの改修を相談する場合も、コード全体の説明より、この変更で守りたい動作と不明な利用先が出発点になります。実装後の到達確認については、関連記事「AIが『完了』と言ったあと、業務の成果をどう確かめるか」で扱っています。