マガジン

初めてのリポジトリをClaude Codeで読む:全体像をつかむ質問の順番

AIを使いこなす

Claudeで執筆し、GPTで自動校閲・修正しています。

ノートにコードの構成と処理の順序を整理している手元
記事の内容をもとに制作したAI生成イメージです。実際の製品画面や検証結果の写真ではありません。

結論から言うと、順番は「①地図 → ②入口 → ③代表的な処理の流れ → ④テストの位置 → ⑤推測の仕分け」の5段階がおすすめです。広い質問から始めて、だんだん狭めていく流れです。Claude Codeの公式ドキュメントも、新しいコードベースでは全体の概要から入り、その後に特定の部品へ掘り下げる進め方を示しています(Common workflows)。 この記事では、この順番を5つの依頼文にしました。回答のどこを自分の目で確かめるかは表にまとめています。依頼文と表は編集部が組み立てた案で、特定のリポジトリで動かして確かめた結果ではありません。お手元のリポジトリで試し、言い回しを調整してください。

この記事の目次
  1. 始める前の準備:読み取りだけにする
  2. 5段階の質問文
  3. 各回答の確認ポイント
  4. 回答がずれたときの切り替え

始める前の準備:読み取りだけにする

質問を始める前に、「読むだけ」の状態を作ります。プロジェクトのルートでClaude Codeを起動し、claude --permission-mode plan で始めます。CLIでは、セッション中に Shift+Tab でモードを切り替え、画面下に ⏸ plan mode on と出る状態にできます。プランモードではファイルを読んで計画を出し、ソースファイルは編集しません。公式ドキュメントの Plan before editing には、承認後に計画を実行して編集できる手順もあるため、この記事の依頼文でも読み取りだけを明示します。

依頼文に禁止事項を書いても、それだけでは権限設定になりません。ファイルの読み取りは作業ディレクトリ内なら確認なしで行われます。プランモードでは読み取り専用のシェルコマンドを実行できますが、それ以外のシェルコマンドは権限設定に従います(Configure permissions)。「ファイル変更、パッケージのインストール、コマンド実行はしない」と頼んでも、Claude Codeの権限を上書きするものではありません。許可を求める画面が出たら、内容を読んで判断してください。

業務のリポジトリでは、APIキーや顧客データを含むファイルを読ませないよう、.env などの扱いを事前に確認します。この記事の例はすべて説明用の架空の構成です。

5段階の質問文

各依頼文は、前の回答を受けて順に貼ります。〜 の部分は自分の状況に置き換えてください。

①地図:何のリポジトリかを知る

text
このリポジトリを読み取りだけで調べてください。ファイルの変更、パッケージのインストール、コマンド実行はしないでください。
まずルート直下のファイル構成、README、依存関係を定義するファイルを読み、次の3点を答えてください。
1. 何のためのプロジェクトか(READMEの記述と、コードから分かることを分けて)
2. 主な言語とフレームワーク
3. 主要なディレクトリごとの役割(1行ずつ)
根拠にしたファイル名を毎回添えてください。

②入口:どこから動き出すかを知る

text
このプロジェクトが実行されるときの入口の候補を、ファイルパスつきで挙げてください。
(例:起動スクリプト、サーバーの立ち上げ、CLIのコマンド定義、ルーティング)
入口が複数あるなら、それぞれ何を起動するかも書いてください。見つからない場合は「見つからない」と答えてください。

③流れ:代表的な処理を1本追う

text
②で挙げた入口のうち、〜という操作(例:ユーザーの登録)が処理される流れを追ってください。
通るファイルと関数を順番に並べ、各段階で何をしているかを一文で書いてください。
実際に読んだ箇所と、名前から推測した箇所を区別してください。

④テスト:確認の足場を探す

text
テストコードの置き場所、使われているテストフレームワーク、設定ファイルを調べてください。
テストの実行コマンドの候補は、READMEや設定ファイルの記述から示してください。ただし実行はしないでください。
③で追った処理に対応するテストがあるか、なければ「見当たらない」と答えてください。

⑤仕分け:確かなことと推測を分ける

text
ここまでの回答を、次の3つに分けて整理してください。
・ファイルを読んで確認できたこと(ファイル名つき)
・推測にとどまること
・まだ読んでいない重要そうな場所(優先度の高い順に3つ)

各回答の確認ポイント

回答をそのまま信じず、次の表の観点で自分の目で確認します。確認は、エディタでファイルを開く、検索する、といった手元の操作で済みます。

  • ①地図、回答で見るところ:READMEの記述とコードからの判断が分かれているか、自分で確かめる方法:挙がったディレクトリを実際に開く、要注意のサイン:存在しないディレクトリ名が出る
  • ②入口、回答で見るところ:パスと起動の役割が対になっているか、自分で確かめる方法:該当ファイルを開き、起動処理があるか見る、要注意のサイン:入口が1つだけなのに根拠が示されない
  • ③流れ、回答で見るところ:各段階にファイル名と関数名があるか、自分で確かめる方法:関数名を検索し、呼び出し関係を確かめる、要注意のサイン:「おそらく」が続く、名前だけの説明
  • ④テスト、回答で見るところ:置き場所、フレームワーク、実行コマンド候補、自分で確かめる方法:設定ファイルを開き、候補のコマンドを確認する、要注意のサイン:実行していないのに結果を述べる
  • ⑤仕分け、回答で見るところ:確認済みと推測が混ざっていないか、自分で確かめる方法:①〜④の根拠ファイルと突き合わせる、要注意のサイン:確認済みの項目に根拠ファイルがない

回答がずれたときの切り替え

回答が広すぎるとき、またはずれたときは、依頼を細かく切り分けます。

  • 範囲が広すぎる場合:@src/components のようにディレクトリを指定します。公式ドキュメントによると、ディレクトリを参照すると中身ではなくファイル一覧が会話に追加されます(Common workflows)。そのうえで、読ませたいファイルを個別に指定します。
  • 用語が分からない場合:「このプロジェクト固有の用語を、出てきた順に用語集にしてください」と頼みます。公式の Tips にも、用語集の依頼が挙がっています。
  • 調査が長引く場合:サブエージェントを使うと、それぞれが独立したコンテキストでタスクを調査し、結果を返します。委任するには、エージェントを使える設定とタスクの説明が必要です(Delegate research to subagents)。

最後に、⑤の出力をメモとして保存しておくと、翌日に読み直す手間が減ります。公式の手順では claude --continue で直近のセッションを再開できます。ただ、メモにしておけば、別のメンバーへの引き継ぎにも使えます。

次にコードを変更する作業へ進むときは、③と④で見つけた流れとテストを手がかりに、変更範囲を絞ってから依頼してください。

出典・参考資料