初見コードの全体フローと構造を把握する

コード解析をChatGPTに依頼するときによくある失敗は、大量のファイルを一度に貼り付けて「このプロジェクトを説明して」と頼んでしまうことです。返ってくるのは「注文と在庫を管理するサービスです」といった当たり前の要約ばかりで、次にどのファイルを開くべきかを決める役には立ちません。

そのため、このプロンプトでは一度にすべてを読ませず、複数回に分割して進めます。最初のリクエストではフォルダ一覧と1つのファイルだけを渡し、回答として「次に投入すべき3つのファイル」を受け取って次の質問を作ります。こうすることで入力トークンの制限に引っかからず、ターンごとに構造図が少しずつ広がっていきます。回答の末尾が次の質問の材料になるため、「次に何を聞けばいいか」と悩む必要もありません。

手順を4段階に定めていることにも意味があります。まずフォルダの役割を推測しておくことで、その後に登場する関数名がどこに属するのか位置づけが明確になり、リクエストの処理経路を線でつなぐことで、他人のコードを読み解く最大の肝である「このファイルがいつ呼ばれるのか」が把握できます。3番の「途切れているポイント」がそのまま次に読むべき場所になるため、読む順番を自力で探す手間が省けます。

制約の指示は、得られる構造図の信頼性を高めるためのものです。確信度の表示や「推測」の明記がないと、推測と確認済みの事実が同じトーンで混ざり合い、それを信じてコードを修正すると手戻りが発生します。また、資料を """ で囲むことで、コード内のコメントがプロンプトへの指示として誤認されるのを防ぎます。

情報量が多すぎるため抽象的な要約しか返ってこず、提示されていないファイルまでフレームワークの一般的な慣例から勝手に推測して、さも実在するかのように書いてしまいます。どこまでが事実でどこからが推測かの区別がつかず信用できません。次に何を読むべきかも分からないため、結局最初から自力で調査し直すことになります。回答が長くなるほど最初のファイルの文脈が薄れ、2問目以降は実在しないファイル名が混ざりやすくなります。