Claude Codeで既存コードを読む最初のプロンプト7選｜初心者向け安全手順

既存コードにClaude Codeを入れるとき、最初にやるべきことは「実装して」ではありません。 まず、どこを読めばよいか、どこを触ってはいけないか、何を確認すれば安全かを言語化します。 ここを飛ばすと、Claude Codeは便利な道具から、変更範囲の広い作業者に変わってしまいます。

この記事では、初心者が既存リポジトリで迷わずClaude Codeを使い始めるための、最初のプロンプト7つを紹介します。すべてコピーして使える形にしてあります。公式のCommon workflowsでも、知らないコードを理解するときは広い質問から始め、そこから特定機能へ絞る流れが推奨されています。この記事では、その考え方を日本語の実務プロンプトに落とし込みます。

Claude Code自体の導入がまだなら、先にClaude Code入門ガイドを読んでください。チームで毎回同じ指示を使いたい場合は、CLAUDE.mdの書き方ガイドとClaude Code権限設定ガイドも合わせて確認すると、初回だけでなく2回目以降も安定します。

最初の30分で決めること

既存コードでClaude Codeを使うときは、最初の30分で次の5点を決めます。

項目	Claude Codeに聞くこと	目的
全体像	何のアプリで、主要ディレクトリはどこか	読む順番を決める
入口	画面、API、CLIの起点はどこか	迷子を防ぐ
1機能	登録、ログイン、検索など1つの流れ	データの通り道を理解する
影響範囲	変更時に壊れやすい場所はどこか	小さく直す
検証	どのコマンドや手動確認で見るか	完了条件を固定する

この5点を先に出すだけで、依頼の品質が大きく変わります。Claude Codeはファイルを読めますが、あなたの優先順位までは知りません。特に仕事のリポジトリでは、請求、認証、本番データ、広告タグ、問い合わせフォームのように、軽い変更に見えても売上や信用に関わる場所があります。

概念図にすると、最初の動きは次の順番です。

flowchart LR
  A["全体地図"] --> B["入口ファイル"]
  B --> C["1機能の流れ"]
  C --> D["影響範囲"]
  D --> E["小さな実装"]
  E --> F["検証メモ"]

プロンプト1: まず全体地図だけを作る

最初は、実装もリファクタリングも依頼しません。読んだ結果を短く返してもらいます。

このリポジトリを初めて読みます。まだファイルは編集しないでください。

次の形式で、初心者にも分かるように整理してください。

1. このアプリが何をするものかを3行で説明
2. 主要ディレクトリを最大7つまで列挙し、それぞれの役割を1行で説明
3. 最初に読むべきファイルを5つだけ選ぶ
4. 触ると危なそうな領域を、根拠ファイル付きで列挙
5. 不明な点は推測で断定せず「未確認」と書く

ここで重要なのは「最大7つ」「5つだけ」のように数を決めることです。「詳しく説明して」と頼むと、読み物としては長くなりますが、次の行動が決まりません。既存コードでは、網羅より優先順位が大切です。

プロンプト2: 入口ファイルを特定する

全体像が見えたら、次は入口です。Webアプリならルーティング、APIならサーバー起動、CLIならコマンド定義を探します。

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

対象:
- Web画面のルーティング
- APIハンドラまたはサーバー起動処理
- CLIやバッチ処理があればその入口

出力形式:
| 種類 | ファイル | 役割 | 次に読む理由 |
| --- | --- | --- | --- |

まだコードは変更しないでください。分からない場合は候補を2つまでに絞り、判断に必要な追加ファイルを教えてください。

入口が分かると、src/全体を順番に眺める時間が減ります。Masaが記事サイトの運用コードで試したときも、最初にルーティングとコンテンツ読み込みの入口を出してもらうだけで、不要なCSSや生成済みファイルを読ませる回数が減りました。

プロンプト3: 1機能だけ流れを追う

ユースケース1は、ログイン、問い合わせ、検索、購入導線など、1つの機能だけを追う場面です。初心者ほど「アプリ全体」を見ようとしますが、実務では1機能を縦に読むほうが早く理解できます。

「問い合わせフォーム送信」機能だけに絞って、画面から保存または送信完了までの流れを追ってください。

次の順番で回答してください。

1. 関係するファイル一覧
2. ユーザー操作からデータ保存・外部送信までの流れ
3. バリデーション、エラー表示、ログ出力の場所
4. 変更すると影響が出る場所
5. 初心者が読まなくてよい補助ファイル

根拠になったファイル名を必ず添えてください。まだ編集しないでください。

このプロンプトは、SaaSの登録、ブログのCTA、管理画面の検索、決済Webhookなどにも使えます。言葉だけ「問い合わせフォーム送信」から変えれば、ほぼそのまま使えます。

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

既存コードが読みにくい理由は、構文よりもチーム固有の言葉にあります。adapter、repository、usecase、harnessのような言葉は、プロジェクトによって意味が変わります。harnessは、ここでは「エージェントや処理を安全に動かす足場」と言い換えると理解しやすくなります。

このリポジトリで使われている専門用語を、初心者向けに翻訳してください。

対象語:
- service
- repository
- usecase
- adapter
- harness
- worker

各語について、次を出してください。
1. 一般的な意味
2. このプロジェクト内での意味
3. 代表ファイル
4. 間違って理解すると起きる失敗

根拠が弱い場合は「推測」と書いてください。

この依頼は、Claude Code memory公式ドキュメントで説明されるCLAUDE.md運用とも相性がよいです。毎回説明する用語が決まってきたら、短い用語集としてCLAUDE.mdへ残すと、次回以降の会話が短くなります。

プロンプト5: 変更前に影響範囲だけ出す

ユースケース2は、バグ修正や小さなUI変更の前に、影響範囲を洗い出す場面です。ここで急に実装させると、動いている場所まで変わることがあります。

「プロフィール編集画面に表示項目を1つ追加する」修正を想定しています。

まだコードは変更せず、影響範囲だけを出してください。

観点:
- UIコンポーネント
- APIまたはserver action
- バリデーション
- 型定義
- テスト
- 翻訳や文言
- 計測イベントやCTA

出力は、変更が必要な可能性が高い順に並べてください。
各項目に「根拠」「リスク」「確認方法」を付けてください。

この形式だと、作業前レビューがしやすくなります。特にプロフィール、権限、料金、フォームは、画面だけ直したつもりでAPIや型がずれる失敗が起きがちです。

プロンプト6: 小さなタスクへ分解する

ユースケース3は、調査結果をそのまま実装に進めず、30分以内のタスクに分ける場面です。

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

条件:
- 1タスク30分以内
- 1タスクの変更ファイルは最大2つ
- 先にやる順で並べる
- 各タスクに完了条件を付ける
- 各タスクに確認コマンドまたは手動確認を付ける
- 本番データ、認証、決済、削除処理には触らない

出力はMarkdownのチェックリストにしてください。

このプロンプトを挟むと、Claude Codeへの依頼が「大きなお願い」から「レビュー可能な作業」に変わります。チームで導入するなら、このチェックリストの作り方を標準化しておくと、レビューの粒度がそろいます。実務向けテンプレートをまとめて使いたい場合はClaudeCodeLabの商品一覧も参考になります。

プロンプト7: 最初の実装だけ依頼する

最後に、ようやく小さな実装を依頼します。ポイントは、対象ファイル、完了条件、検証方法を先に固定することです。

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

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

要件:
- 日付表示を yyyy-mm-dd から yyyy年m月d日 に変更
- 既存のprops名は変えない
- 既存UIの余白とクラス名はできるだけ維持
- 必要なら最小限のテストを追加

完了後に出すもの:
1. 変更したファイル
2. 変更理由
3. 実行した確認コマンド
4. 残ったリスク

「最初のタスクだけ」と書くのは地味ですが効きます。Claude Codeに限らず、AIコーディングではタスクが大きくなるほど、意図しない抽象化やついでの修正が混ざります。

失敗例と落とし穴

落とし穴1は、最初から「このアプリをリファクタして」と頼むことです。範囲が広すぎるため、Claude Codeは多くのファイルを読み、変更候補も広くなります。解決策は、まず「まだ編集しないで」「5ファイルだけ」「1機能だけ」と制限することです。

落とし穴2は、権限を広げすぎることです。公式のpermissionsドキュメントでは、allow、deny、askのようにツール利用を制御できます。初心者のうちは、削除、push、.env読み取り、本番設定変更を自動許可しないほうが安全です。

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(npm run test *)",
      "Read"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(rm -rf *)",
      "Read(.env)",
      "Read(**/.env)"
    ],
    "ask": [
      "Bash(npm run build *)",
      "Write(src/**)"
    ]
  }
}

落とし穴3は、実装後の証拠を見ないことです。「修正しました」という返答だけでは足りません。git diff、テスト、画面確認、手動チェックのどれかで、意図した変更だけかを見ます。

git status --short
git diff -- src/components/ProfileCard.tsx src/lib/formatDate.ts
npm test -- --runInBand

落とし穴4は、会話が長くなりすぎたまま続けることです。文脈が膨らんだら、何を決めたか、どのファイルを触ったか、どの確認が残っているかを短くまとめます。公式のCLI referenceにはセッション継続や権限関連のオプションも整理されているので、運用前に一度見ておくと安心です。

検証メモを残す小さなJS

記事や社内手順として使うなら、最後に確認メモを残すと再現性が上がります。次のJavaScriptは、Claude Codeの初回調査メモに最低限の見出しがあるかを確認するだけの小さなスクリプトです。first-pass-note.mdを作ってから実行できます。

const fs = require("node:fs");

const file = process.argv[2] || "first-pass-note.md";
const text = fs.readFileSync(file, "utf8");
const required = ["全体像", "入口", "影響範囲", "検証", "残ったリスク"];
const missing = required.filter((word) => !text.includes(word));

if (missing.length > 0) {
  console.error(`Missing sections: ${missing.join(", ")}`);
  process.exit(1);
}

console.log(`OK: ${file} has the minimum first-pass sections.`);

使い方は次の通りです。

node check-first-pass-note.js first-pass-note.md

大事なのは、このスクリプト自体の高度さではありません。Claude Codeに「最後に何を残すか」を明確にすることです。メモの型があると、次の担当者や翌日の自分が、同じ調査を繰り返さずに済みます。

実務での3つの使いどころ

ユースケース1は、新しく参加したプロジェクトのオンボーディングです。READMEだけでは分からない入口、チーム固有用語、危険な領域を短時間でつかめます。新人にいきなり実装を任せるより、まず地図を作らせるほうが安全です。

ユースケース2は、小さなバグ修正です。現象、期待値、制約、確認方法を渡してから、影響範囲、原因候補、最小修正へ進めます。特にフォーム、検索、日付表示、文言修正のような小粒の変更で効果が出ます。

ユースケース3は、記事サイトや教材サイトの収益導線チェックです。本文、無料PDF、商品一覧、相談ページへの導線が切れていないかを、実装前に確認できます。このサイトのように記事から教材・テンプレート一覧やClaude Code研修・導入相談へつなぐ場合、CTAのリンク切れや文脈違いはそのまま機会損失になります。

公開前に見るチェックポイント

既存コードでClaude Codeを使ったあと、最後に人間が見るべきポイントも固定しておきます。まず、変更ファイルが依頼した範囲に収まっているかを見ます。次に、テストや手動確認が実際に行われたかを確認します。最後に、読者やユーザーが触る文言、リンク、フォーム、価格、権限、ログ出力が意図せず変わっていないかを見ます。

記事サイトなら、本文の品質だけでなく、内部リンク、公式外部リンク、heroImage、CTAの自然さも確認対象です。Claude Codeに「SEOを良くして」とだけ頼むと、タイトルや見出しだけが変わり、導線や検証メモが薄いまま残ることがあります。公開前レビューでは、検索意図、初心者向け説明、失敗例、実務ユースケース、検証結果、収益導線の6点を順番に見ると漏れが減ります。

チームで使う場合は、このチェックをPRテンプレートやCLAUDE.mdに短く残します。長い理念ではなく、「変更範囲」「検証」「危険領域」「リンク」「残リスク」を書く欄だけで十分です。Claude Codeの出力を信用するかどうかではなく、毎回同じ観点で確認できる状態を作ることが、既存コード運用では一番効きます。

まとめ

既存コードでClaude Codeを使うコツは、最初から書かせないことです。全体地図、入口、1機能の流れ、影響範囲、タスク分解、最小実装、検証メモの順番にすると、初心者でも作業を小さく保てます。慣れてきたら、この7つのプロンプトをCLAUDE.mdやチームのチェックリストに移し、毎回の説明を減らしてください。

実際に試した結果、Masaの手元では「まず読んで、まだ編集しないで」と明示したセッションのほうが、いきなり修正を頼んだセッションより差分確認が楽でした。特に記事サイトのCTA修正では、/products/と/training/のリンクを先に調べさせてから1ファイルだけ直す流れにすると、余計なリファクタや文言の置き換えが混ざりにくくなりました。