既存プロジェクトをClaude Codeで開くとき、最初に迷うのは「何を頼めばいいのか」です。 小さなHTMLファイルを作るだけなら依頼しやすいですが、すでにファイルがたくさんあるプロジェクトでは話が変わります。
いきなり「直して」と頼むと、Claude Codeはコードを読み、必要そうなファイルを探し、修正案まで進めようとします。 便利ですが、初心者のうちは変更内容を追いきれません。
最初の目的は修正ではありません。 既存コードでは、まず「読むだけ」に絞るのが安全です。
この記事では、Claude Codeに既存コードを読ませるときの基本を整理します。 ファイル構成を説明してもらい、主要な処理を追い、分からない点を質問する。 そのあとで、必要なら修正に進む。 この順番を覚えると、知らないプロジェクトでも落ち着いて扱いやすくなります。
既存コードを扱う最初の依頼では、ファイル編集をさせないことが大事です。読むだけ、調査だけ、説明だけ、と先に伝えてから始めます。
既存コードは、まず読ませるだけでいい
いきなり修正させると確認が追いつかない
Claude Codeは、コードベースを読み、ファイルを検索し、必要に応じてコマンドを実行できます。 だからこそ、最初の一言が雑だと、作業範囲が広がりやすいです。
たとえば、次のように頼むと危ないです。
このプロジェクトを見て、悪いところを直してください。この依頼だと、Claude Codeは「悪いところ」を探すところから始めます。 どのファイルを見るのか、何を直すのか、どこまで変更してよいのかが曖昧です。 結果として、読者が理解する前に編集が進む可能性があります。
最初は、修正ではなく説明を頼みます。
このプロジェクトの構成を読み、概要を説明してください。
まだファイル編集はしないでください。
コマンドを実行する必要がある場合は、実行前に理由を説明して確認してください。このくらい絞るだけで、作業の入口がかなり安全になります。
「変更しないで」と明示する
Claude Codeに既存コードを読ませるときは、最初の依頼文に禁止事項を入れます。 とくに初心者のうちは、次の表現を入れておくと安心です。
- まだファイル編集はしないでください
- 調査と説明だけをしてください
- コマンド実行が必要なら、実行前に確認してください
- 不明点は推測で進めず、質問してください
- 変更が必要そうでも、まず変更案だけ出してください
「そこまで書く必要ある？」と思うかもしれません。 でも、既存コードではこの一言が効きます。 読むだけのつもりなら、編集しない条件を必ず先に書いてください。
tomo既存プロジェクトは、見えているファイルより裏側のつながりが多いです。最初から直させるより、まず地図を描いてもらうくらいの感覚で始めるほうが安全です。
最初に聞くのはファイル構成
プロジェクト全体をざっくり説明してもらう
最初に知りたいのは、細かい関数の意味ではありません。 どこに何があり、どのファイルから読み始めればよいかです。
次のように聞きます。
このプロジェクトのファイル構成を確認して、初心者向けに説明してください。
知りたいことは次の通りです。
- 主要なフォルダの役割
- アプリの入口になっていそうなファイル
- 設定ファイルの種類
- 依存関係を確認するファイル
- 最初に読むとよさそうなファイル
まだファイル編集はしないでください。
分からない点は、推測で断定せず「不明」と書いてください。この依頼なら、Claude Codeはファイルを探しながら構成を整理できます。 読者は、いきなりコードの細部に入らず、プロジェクトの地図を受け取れます。
重要そうなファイルを挙げてもらう
プロジェクトに慣れていないと、全部のファイルが重要に見えます。 でも、最初から全部読む必要はありません。 まずは入口になるファイルを絞ります。
このプロジェクトを理解するために、最初に読むべきファイルを3〜5個に絞ってください。
それぞれについて、次の形式で説明してください。
- ファイル名
- そのファイルの役割
- なぜ最初に読むべきなのか
- まだ読まなくてよい関連ファイル
ファイル編集はしないでください。最初に読むファイルを3〜5個に絞ると、説明を受けたあとに自分でも確認しやすくなります。 数十個のファイルを一気に説明されても、初心者には残りません。
次に主要な処理の流れを追う
画面やAPIの入口からたどる
ファイル構成が分かったら、次は処理の流れを追います。 このときも、プロジェクト全体を一気に説明してもらうより、入口を決めたほうが分かりやすいです。
Webアプリなら、画面やルーティングからたどります。 APIなら、エンドポイントからたどります。 CLIツールなら、コマンド入口からたどります。
たとえば、Webアプリならこう頼みます。
トップページが表示されるまでの処理を追ってください。
知りたいことは次の通りです。
- 最初に呼ばれるファイル
- ルーティングを定義している場所
- 画面コンポーネントが置かれている場所
- データ取得があれば、その呼び出し元
- 読む順番
説明だけでよいです。ファイル編集はしないでください。APIなら、対象をもう少し狭めます。
ログインAPIの処理を入口から追ってください。
次の順番で説明してください。
- リクエストを受け取るファイル
- 入力値を確認している場所
- 認証処理を呼び出している場所
- 成功時と失敗時の返し方
- 関連して読むべきファイル
まだ修正はしないでください。処理の順番を文章で説明してもらう
初心者にとってつらいのは、ファイル名だけを並べられることです。 router.ts、controller.ts、service.ts と言われても、どの順番で読めばいいのか分かりません。
そこで、Claude Codeには「処理の順番」を文章で説明してもらいます。
この処理を、初心者が追えるように順番で説明してください。
形式は次のようにしてください。
1. どのファイルから始まるか
2. どの関数が呼ばれるか
3. 次にどのファイルへ進むか
4. どこでデータを読み書きするか
5. どこで画面やレスポンスに戻るか
説明には、根拠にしたファイル名も添えてください。この聞き方なら、読む順番が見えます。 コードを読むのが苦手な人でも、「次にどこを見るか」が決まりやすくなります。
質問は小さく分ける
大きすぎる質問は答えがぼやける
「このプロジェクトを全部説明して」と頼むと、説明は広くなります。 広い説明が悪いわけではありません。 ただ、具体的な理解にはつながりにくいです。
質問は、対象を小さく切ったほうが使いやすくなります。
| 広すぎる質問 | 絞った質問 |
|---|---|
| このアプリを説明して | ログイン後の画面表示までの流れを説明して |
| コードを全部見て | 最初に読むべきファイルを5個に絞って |
| バグがないか見て | 入力値チェックの処理だけ確認して |
| 設計を教えて | データ保存の処理がどのファイルに分かれているか説明して |
質問を小さくすると、Claude Codeの答えも具体的になります。 自分が確認する範囲も狭くなるので、説明の正しさを見直しやすくなります。
そのまま貼れる質問例
既存コードを読むだけなら、次の依頼文から始めると使いやすいです。
このプロジェクトを初めて読みます。
まずは調査と説明だけをお願いします。
やってほしいこと:
- ファイル構成を確認する
- 主要なフォルダの役割を説明する
- アプリの入口になっていそうなファイルを挙げる
- 最初に読むべきファイルを3〜5個に絞る
- 分からない点や追加で確認したほうがよい点を質問として出す
やらないでほしいこと:
- ファイル編集
- 新規ファイル作成
- 不要なコマンド実行
- 推測だけでの断定
コマンドを実行する必要がある場合は、実行前に理由を説明して確認してください。この依頼文のポイントは、やってほしいことと、やらないでほしいことを分けている点です。 Claude Codeは自然文で頼めますが、既存コードでは条件を分けたほうが誤解が減ります。
tomo「読むだけ」の依頼文は、少し堅いくらいでちょうどいいです。最初に範囲を狭めておけば、あとから安心して深掘りできます。
説明を信じすぎず、根拠ファイルを見る
ファイル名と行番号を出してもらう
Claude Codeの説明は便利ですが、説明だけで終わらせないほうがいいです。 とくに既存コードでは、どのファイルを根拠にした説明なのかを確認します。
次のように頼みます。
説明の根拠にしたファイル名を添えてください。
可能なら、関係する関数名や行番号も出してください。
説明だけで分からないところは、どのファイルを見れば確認できるかも書いてください。ファイル名が出てくると、自分でも開いて確認できます。 行番号まで出ていれば、説明とコードを照らし合わせやすくなります。
分からない単語はその場で聞く
既存コードを読むと、知らない単語が次々に出ます。 ルーティング、ミドルウェア、ORM、スキーマ、フック、コンポーネント、サービス。 分からない単語をそのまま流すと、後半の説明が全部ぼんやりします。
聞き返すときは、遠慮しなくていいです。
今の説明に出てきた「ミドルウェア」が分かりません。
このプロジェクト内では、どのファイルで使われていますか。
一般的な意味と、このプロジェクトでの役割を分けて説明してください。分からない単語を放置しないことが、既存コードを読む近道です。 一度止まって聞いたほうが、結局は早く進みます。
修正に進む前に確認すること
何を理解できたかをまとめさせる
ある程度読めたら、Claude Codeに理解した内容をまとめてもらいます。 これは、自分の理解を確認するためにも役立ちます。
ここまで読んだ内容を整理してください。
次の形式でお願いします。
- 分かったこと
- まだ不明なこと
- 追加で読むべきファイル
- 修正に進むなら先に決めるべきこと
まだファイル編集はしないでください。このまとめを見ると、修正に進める状態かどうかが分かります。 「まだ不明なこと」が多いなら、そこで止まって追加で質問します。
変更範囲を決めてから進む
修正に進むときも、いきなり「直して」と言わないほうがいいです。 読んだ内容をもとに、変更範囲を先に決めます。
修正に進む前に、変更案だけ出してください。
知りたいこと:
- 変更するファイル
- 変更しないファイル
- 変更理由
- 想定される影響範囲
- 修正後の確認方法
まだ実際の編集はしないでください。ここまで確認してから編集に進むと、変更内容を追いやすくなります。 Claude Codeに任せる場面でも、何を変えるのかを人間が先に理解しておくことが大事です。
既存コードで怖いのは、壊れたことそのものより、どこを変えたのか分からなくなることです。修正前に対象ファイルと確認方法を決めてから進めてください。
まとめ
既存コードをClaude Codeに読ませるとき、最初の目的は修正ではありません。 まずはファイル構成を見てもらい、主要な処理を追い、分からない点を質問する。 その流れを作るだけで、知らないプロジェクトへの不安はかなり減ります。
要点は次の通りです。
- 最初は「読むだけ」「調査だけ」と明示する
- ファイル構成から聞く
- 最初に読むファイルを絞る
- 画面やAPIの入口から処理を追う
- 説明には根拠ファイルを添えてもらう
- 修正前に変更範囲と確認方法を決める
Claude Codeは、既存コードを読む相手としてかなり頼れます。 ただし、最初から編集まで任せる必要はありません。 まず読ませる。 説明を聞く。 根拠ファイルを見る。 そのあとで、必要なら小さく修正に進む。
この順番を守るだけで、Claude Codeは「勝手に触るもの」ではなく、コード理解を手伝ってくれる相手として使いやすくなります。
