AIを使って一度も触ったことのないレガシーサービスを解明した方法

3週間前、私は一度も開いたことのないサービスに関するサポートエスカレーションを引き継ぎました。それは約4年前のNode.jsマイクロサービスで、すでに退職した2人のエンジニアによって書かれていました。意味のあるREADMEはなく、テストは数ヶ月間CIで実行されておらず、Slackスレッドには「このサービスはブラックボックスだ」という2年前からの愚痴が溢れていました。

バグは実際に顧客に影響を与えていました。私は1日で状況を把握する必要がありました。

そのサービスはAPIゲートウェイとサードパーティのフルフィルメントプロバイダーの間に位置していました。リクエスト変換ロジックが断続的にフィールドを欠落させていましたが、特定のリクエスト形状と負荷の組み合わせでのみ発生していました。出力は間違っており、ログは役に立たず、コードは14ファイル・3200行に分散し、3層のミドルウェアにロジックが分割され、関心事の分離が明確ではありませんでした。

通常、このような状況では、半日かけてconsole.logによる発掘作業を行い、やっとテストに値する仮説を立てることができます。しかし今回は別の方法を試しました。

最初の直感はメインハンドラーをAIチャットに貼り付けて「これは何をする？」と尋ねることでした。表面的な要約は得られましたが、間違ってはいないものの有用ではありませんでした。コードが言っていることは教えてくれましたが、システムの文脈における意味は教えてくれませんでした。

本当に突破口となったプロンプトパターンは、AIを検索エンジンではなく、チームに新しく加わったエンジニアとして扱うことでした。コアファイルを順番に与え、特定の役割と目標を設定しました：「あなたはこのチームに加わった新しいバックエンドエンジニアです。レガシーマイクロサービスのコアファイルを1つずつ見せます。各ファイルの後で、実行中のリストを更新してください：1）このファイルの責務、2）見える前提や暗黙の契約、3）このコードに触れる前に答えたい質問。コードを要約しないでください。負荷のかかるロジックを特定し、壊れやすいと思われるものをフラグしてください。」

3ファイル後、AIは私が見逃していたものを浮かび上がらせました：入力が期待される形状に一致しない場合に静かにundefinedを返すフィールド変換関数です。エラーもログもなく、単に下流でフィールドが欠落していました。それがバグであり、コードベースに4年間存在していました。

理論ができた後、修正コードを1行も書く前に、2つ目のプロンプトでストレステストを行いました。関数とペイロード例を示し、すべてのコードパスを辿り、出力が静かに欠落またはundefinedになる可能性があるかを尋ねました。5つのパスを分析し、2つがundefinedを生成する可能性を指摘し、断続的な障害パターンに最も関連するパスを正しく特定しました。

全体として：根本原因特定まで約90分（通常半日以上）、手動で読んだファイルは4/14、修正コードは11行、その後AI支援で回帰テストを1つ作成しました。鍵はAIが仕事を代わりにすることではなく、構造化された思考パートナーとして機能し、私が診断の主体性を保持することでした。

馴染みのないレガシーコードに放り込まれたら、AIに説明を求めないでください。役割を与え、ファイルを段階的に入力し、システムの実行モデルを維持するように依頼してください。その出力は要約よりもはるかに有用です。