Claude Codeで既存コードを読む最初のプロンプト7選 | 初心者が迷わない始め方

Claude Code を入れたあと、多くの人が最初に開くのは新規アプリではなく既存の業務リポジトリです。
ただ、いきなり「このバグ直して」と投げると、調査範囲が広すぎて返答もぼやけます。私も最初はここで失敗しました。

既存コードで最初にやるべきことは、実装を急がせることではありません。
先に「どこを読むか」「何を要約してほしいか」「どの粒度で答えてほしいか」を固定することです。

この記事では、既存コードを安全に読み始めるための最初のプロンプトを7個に絞って紹介します。すべてコピペ前提です。
Claude Code の導入がまだなら、先に Claude Codeの始め方ガイド を読むと流れがつかみやすくなります。

この記事のゴール

この記事を読み終わるころには、次の状態を目指します。

• Claude Code に既存コードを読ませる順番がわかる
• いきなり大きな修正を依頼しないようになる
• 曖昧な質問を、答えやすいプロンプトに分解できる
• 無料PDFで基本を確認しつつ、必要ならテンプレートや相談につなげられる

先に結論: 最初の30分はこの順番で使う

既存コードに入るときは、次の順番が扱いやすいです。

1. 全体像を聞く
2. 入口ファイルを聞く
3. 特定機能の流れを追わせる
4. 変更候補と影響範囲を聞く
5. そのあとで小さな修正を依頼する

逆に、最初から「全部レビューして」「最適化して」「リファクタして」は重すぎます。
コードベースの見方そのものを整理したいなら、Claude Codeでコードベースを素早く把握する方法 も相性がいいです。

プロンプト1: まず全体像を3行で要約させる

最初の一手は、細部ではなく全体像です。
「このリポジトリは何をするものか」「主要なディレクトリはどこか」「自分が最初に読むべき場所はどこか」を短く返させます。

このリポジトリの目的を初心者向けに3行で説明してください。
そのうえで、重要なディレクトリを最大5個まで挙げて、
「何が入っているか」を1行ずつ説明してください。
最後に、最初に読むべきファイルを3個だけ選んでください。

これが効く理由

Claude Code は質問が広いほど情報を盛りがちです。
最初に「3行」「5個」「3個」と上限を入れると、概要の解像度が一気に上がります。

失敗例

このプロジェクトを詳しく説明して

これだと長い説明が返りやすく、初心者ほど読み切れません。
最初は短く、選ばせるのがコツです。

プロンプト2: 入口ファイルだけを特定させる

全体像が見えたら、次は「どこから起動しているか」です。
Web アプリ、API、CLI では入口が違います。

このプロジェクトの実行入口を特定してください。

- Webアプリならルーティングの起点
- APIならサーバー起動の起点
- CLIならエントリーポイント

を探して、関係するファイルだけを挙げてください。
各ファイルについて「役割」と「次に読むべき理由」を1行で説明してください。

この質問をすると、読む順番がはっきりします。
「何となく src/ を眺める時間」が減るので、最初の体験がかなり良くなります。

プロンプト3: 1機能だけの処理フローを追わせる

既存コードで一番効果が出やすいのは、機能を1個だけ指定して流れを追わせることです。
たとえばログイン、検索、問い合わせ、決済などです。

「ユーザー登録」機能だけに絞って、
画面 -> バリデーション -> API呼び出し -> DB更新
の流れを追ってください。

次の形式で答えてください。
1. 関係するファイル一覧
2. データの流れ
3. ここを直すと影響が出る場所
4. 初心者が読み飛ばしてよい補助ファイル

このプロンプトの良いところは、読むべきファイルと読まなくてよいファイルが分かれることです。
既存コードで迷う人は、読む量が多すぎるのではなく、優先順位がないことが原因です。

ここでのCTA

既存コードを読む質問は毎回似てきます。
毎回ゼロから考えたくないなら、Claude Code プロンプトテンプレート集 50選 のような定型文を持っておくと、初動がかなり速くなります。

プロンプト4: 用語を初心者向けに翻訳させる

既存コードがつらい理由の半分は、コードそのものよりチーム固有の言葉です。
service、usecase、adapter、presenter のような設計用語も、プロジェクトによって意味が微妙に違います。

このプロジェクトで使われている用語を、初心者向けに翻訳してください。

- service
- repository
- usecase
- adapter
- hook

それぞれについて、
「一般的な意味」と「このプロジェクト内での意味の違い」を分けて説明してください。
分からないものは推測せず、分からないと書いてください。

ここで「推測せず」と入れておくのが重要です。
曖昧な用語を自信ありげに説明されると、その後の理解が全部ずれます。

この手のルールは CLAUDE.md のベストプラクティス にまとめておくと、毎回説明しなくて済みます。

プロンプト5: 変更前に影響範囲だけを出させる

初心者が一番避けたいのは、直したつもりで別の場所を壊すことです。
そこで、修正を依頼する前に影響範囲だけ出させます。

「プロフィール編集画面の表示項目を1つ増やす」修正を想定して、
実装前に影響範囲だけを洗い出してください。

次の観点で整理してください。
- UI
- API
- バリデーション
- 型定義
- テスト
- ドキュメント

まだコードは変更しないでください。

この一文だけで、Claude Code が勝手に編集を始める事故を減らせます。
「まだコードは変更しない」は、初心者ほど付けておいた方が安全です。

失敗例

プロフィール編集画面に電話番号を追加して

これでも直せることはありますが、既存コードでは危険です。
フォームだけ変わって API や型定義がずれたまま、という事故が起こりやすくなります。

プロンプト6: 調査結果をそのままタスク化させる

調査の次に詰まりやすいのは、「で、何から手を付けるのか」です。
ここは Claude Code に優先順位まで切らせると進みやすくなります。

ここまでの調査内容をもとに、
初心者が安全に進められるタスクへ分解してください。

条件:
- 30分以内で終わる粒度
- 1タスクごとに変更ファイルを限定する
- 先にやる順で並べる
- 各タスクに「完了条件」を付ける

この形にしておくと、1つずつ終わらせやすくなります。
特に「変更ファイルを限定する」は重要です。ファイル数が増えるほど、判断コストが急に上がります。

プロンプト7: 最後に小さい実装だけ依頼する

ここまで来たら、ようやく実装です。
ただし最初の依頼は1ファイルか2ファイルで終わる小ささに絞ります。

では最初のタスクだけ実装してください。

対象:
- src/components/ProfileCard.tsx
- src/lib/formatDate.ts

要件:
- 日付表示を yyyy-mm-dd から yyyy年m月d日 に変更
- 既存の props は変えない
- テストが必要なら最小限だけ追加
- 変更内容を最後に3行で要約

最初の成功体験は、派手な機能追加より「安全に小さく直せた」が正解です。
その積み重ねで、既存コードへの怖さが消えていきます。

既存コードで最初にやらない方がいい依頼

逆に、導入直後は次の依頼を避けた方が無難です。

• プロジェクト全体の大規模リファクタリング
• テストがない状態での横断修正
• セキュリティ要件が絡む変更の断定的な実装
• 本番データや本番設定に触る自動化
• 複数サービスをまたぐ改修

特に権限設定が曖昧なまま進めるのは危険です。
.claude/settings.json の考え方は Claude Code 権限設定ガイド を先に見ておくと事故が減ります。

無料PDF・テンプレート・相談の使い分け

「どこまで無料情報で進めるか」「いつ有料に進むか」が分かると迷いません。

無料PDFが向いている人

• まず基本コマンドだけ確認したい
• 初回の触り方を短く復習したい
• メール登録して後でまとめて見返したい

テンプレート集が向いている人

• 毎回プロンプトを考えるのが面倒
• 既存コード読解、レビュー、調査を型化したい
• そのままコピペして試したい

導入相談が向いている人

• 自社コードベースでどこから使うべきか決めたい
• 権限設定や運用ルールを先に固めたい
• 記事や無料PDFでは足りず、業務フローに落とし込みたい

社内導入や業務自動化まで含めて整理したいなら、導入相談ページ から相談内容を送るのが早いです。
「何を相談すればいいかわからない」段階でも問題ありません。

まとめ

既存コードで Claude Code を使い始めるときは、最初から実装を急がないことが大事です。
先に全体像、入口、1機能の流れ、影響範囲を押さえてから、小さな実装に入るだけで失敗率は大きく下がります。

今日の最初の一手としては、次の3つだけで十分です。

1. この記事のプロンプト1を試す
2. 1機能だけ流れを追わせる
3. 影響範囲を確認してから小さな修正を1個だけやる

まずは記事下の無料PDFで基本コマンドを確認しつつ、すぐ使える型がほしい場合は プロンプトテンプレート集 を使ってみてください。
チーム導入や既存コードベースへの乗せ方まで含めて詰めたい場合は、導入相談 で個別に整理できます。