Claude Codeに既存コードで最初に投げるプロンプト集｜コピペで使える7文

引き継いだリポジトリを開いた初日、僕は「ログイン処理を直して」とだけ打ち込みました。

返ってきた差分は11ファイル。認証ミドルウェアも、共通のエラーハンドラも、なぜか日付フォーマットの関数まで“ついでに”書き換わっていました。直したかったのは、ログインボタンの文言ひとつだったのに。

問題はClaude Codeの賢さじゃありません。最初に投げた一文が雑だっただけです。他人のコードを前にして、いきなり「直して」と言うのは、初対面の街でいきなり「近道で連れてって」と頼むようなもの。まず地図を見せてもらう、入口を聞く、行き先を絞る。順番があります。

この記事は、その「順番」をプロンプトの形で渡します。全体像のつかみ方そのものは姉妹記事の既存コードベースの地図づくりに任せて、ここではコピペでそのまま投げられる最初の7文に集中します。

この記事の要点

• 既存コードに対する最初の一手は「実装して」ではなく「まだ編集しないで、説明して」。これだけで事故が激減する。
• 効くプロンプトには型がある。「この構成を説明して」「この関数の呼び出し元は」「この変更の影響範囲は」「テストの入口は」の4系統を押さえれば足りる。
• どのプロンプトも出力形式（表・箇条書き・行数上限）を指定すると、読み物ではなく次の行動が決まる答えになる。
• 仕上げに、調査メモが揃っているかをチェックする小さなスクリプトを1本置く。コピペで動く。
• 公式のCommon workflowsも「広く聞いてから絞る」流れを推奨している。本記事はそれを日本語の実務プロンプトに落とした。

導入がまだなら先にClaude Code入門を、権限を絞ってから触りたいなら権限設定リファレンスを開いておくと安心です。

なぜ「最初の一文」で結果が変わるのか

Claude Codeはファイルを読めます。でも、あなたの優先順位は読めません。

「直して」と言われたAIは、関係しそうなファイルを広く読み、よかれと思って広く直します。本人に悪気はない。地図も行き先も渡されていないから、自分で全部やろうとするだけです。仕事のリポジトリには、請求・認証・本番データ・計測タグみたいに「軽い変更に見えて売上や信用に直結する場所」があります。そこを“ついで”に触られると、笑えない事故になります。

だから最初にやるのは、行動範囲を狭めること。具体的には次の3つを毎回プロンプトに混ぜます。

• まだ編集しないで（読むだけ、と最初に宣言させる）
• 出力の形を決める（表、箇条書き、◯個まで、と数を切る）
• 根拠ファイルを付けて（推測か事実かを区別させる）

この3点が入っているだけで、返事が「長い説明文」から「次の一手が決まる答え」に変わります。逆に言うと、プロンプトを飾る前にこの3点を入れるだけで8割は片付きます。

最初に決める5つの問い

走り出す前に、Claude Codeに聞くべきことを5つに絞っておきます。順番がそのまま読む順番になります。

順	聞くこと	何のため
1	何のアプリで、主要ディレクトリはどこか	読む順番を決める
2	画面・API・CLIの起点はどこか	迷子を防ぐ
3	登録やログインなど1機能の通り道	データの流れをつかむ
4	変更で壊れやすい場所はどこか	小さく直す
5	どのコマンドや手動確認で見るか	完了条件を固定する

この5問を、これから7つのプロンプトに割り当てていきます。1から3が「読む」、4が「影響範囲」、5が「検証」。地図の全体像をもっと丁寧に作りたい人は、先に既存コードベースの地図づくりを済ませてから戻ってくると、3以降がさらに速く回ります。

プロンプト1: この構成を説明して（地図だけ作る）

最初は実装もリファクタも頼みません。読んだ結果を、短く返してもらうだけです。

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

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

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

ここで効くのは「最大7つ」「5つだけ」という数の指定です。「詳しく説明して」と頼むと読み物としては立派になりますが、次にどこを開けばいいか分からない。既存コードでは、網羅より優先順位です。僕は自分の記事サイトの運用コードで試したとき、この一文だけで「まず開くべき5ファイル」が手に入って、無関係なCSSや生成済みファイルを延々読ませる無駄が消えました。

プロンプト2: 実行の入口はどこ（迷子を防ぐ）

地図が見えたら入口です。Webならルーティング、APIならサーバー起動、CLIならコマンド定義。ここが分かると、src/を上から順に眺める時間がまるごと要らなくなります。

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

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

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

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

「候補を2つまでに絞って」と添えるのがコツです。これがないと、AIは可能性を全部並べて長くなる。2つに絞らせると、こちらは「どっちが本命か」を1分で判断できます。

プロンプト3: この機能の流れを追って（1本だけ縦に読む）

ここからが本題に近いです。アプリ全体を見ようとせず、1機能だけ縦に読みます。初心者ほど横に広く見たがりますが、実務は1本を上から下まで追うほうが圧倒的に早い。

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

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

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

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

カギ括弧の中（ここでは「問い合わせフォーム送信」）を差し替えるだけで、SaaSの登録フロー、ブログのCTA、管理画面の検索、決済Webhookにそのまま使い回せます。テンプレとして手元に1つ持っておくと便利です。

プロンプト4: この関数の呼び出し元は（点から線へ）

機能の流れが見えると、今度は1つの関数や型に焦点が当たります。「これを変えたら、どこが連鎖して壊れる?」を知りたい場面です。呼び出し元（誰がこれを使っているか）を先に押さえると、安全に手を入れられます。

`formatUserName` 関数について調べてください。まだ編集しないでください。

1. 定義されているファイルと、引数・戻り値の型
2. この関数を呼び出している箇所をすべて列挙（ファイルと用途）
3. 戻り値を画面表示・ログ・外部APIのどれに使っているか
4. シグネチャ（引数や戻り値）を変えたとき壊れる可能性が高い順

各項目に根拠ファイルを添えてください。推測なら「推測」と明記してください。

このプロンプトが、後で出てくる「影響範囲」の土台になります。呼び出し元が3箇所なのか30箇所なのかで、変更の重さがまるで違う。先に数を知ると、見積もりを盛大に外しません。用語そのものがチーム固有で読めないときは、合わせて次のように頼みます。

このリポジトリの専門用語を初見向けに翻訳してください。

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

各語について、(1)一般的な意味 (2)このプロジェクト内での意味
(3)代表ファイル (4)誤解すると起きる失敗 を出してください。
根拠が弱い語は「推測」と書いてください。

harnessのような言葉は、ここでは「エージェントや処理を安全に動かす足場」と言い換えると一気に読みやすくなります。毎回説明する用語が固まってきたら、公式のmemoryドキュメントに沿ってCLAUDE.mdへ短い用語集として残すと、次回からの会話が短くなります。書き方の塩梅はCLAUDE.mdの原則にまとめました。

プロンプト5: この変更の影響範囲は（直す前に出す）

バグ修正や小さなUI変更の前に、影響範囲だけを先に洗い出します。ここで実装まで一気に頼むと、動いている場所まで“ついで”に変わります。

「プロフィール編集画面に表示項目を1つ追加する」修正を想定しています。
まだコードは変更せず、影響範囲だけを出してください。

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

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

「確認方法」まで一緒に出させるのがポイントです。影響範囲とセットで検証手順が手に入るので、作業前レビューがそのまま回ります。プロフィール・権限・料金・フォームは、画面だけ直したつもりでAPIや型がズレる事故が起きやすい代表格。ここを先に可視化しておくと安心です。

プロンプト6: テストの入口はどこ（完了条件を固定）

実装に入る前に、最後の問い。「これが直ったと、どうやって機械的に分かるのか」です。テストの入口（どのコマンドで、何を、どこから実行するか）を先に固定すると、完了条件が言葉ではなくコマンドになります。

このプロジェクトのテストの入口を教えてください。まだ編集しないでください。

1. テストの実行コマンド（unit / e2e があれば分けて）
2. テストファイルの置き場所と命名規則
3. 「問い合わせフォーム送信」に関係するテストはどれか
4. 今回の変更で、新しく足すべきテストの最小案

設定ファイル（package.json の scripts 等）を根拠として示してください。

入口が分かったら、ようやく小さな実装を1つだけ頼みます。対象ファイル・要件・完了後に出すもの、を先に固定するのが肝心です。

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

対象: src/components/ProfileCard.tsx / src/lib/formatDate.ts
要件:
- 日付表示を yyyy-mm-dd から yyyy年m月d日 に変更
- 既存のprops名は変えない / 既存UIの余白・クラス名はできるだけ維持
- 必要なら最小限のテストを追加

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

「最初のタスクだけ」は地味ですが効きます。AIコーディングはタスクが大きくなるほど、頼んでいない抽象化や“ついで修正”が混ざる。小さく切るほど、レビューできる差分になります。

プロンプト7: 変更を見せて（証拠で締める）

「直しました」という返事だけでは足りません。差分とテストで、意図した範囲に収まっているかを自分の目で確かめます。Claude Codeに次を実行させて、結果を貼ってもらいます。

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

差分が依頼した2ファイルに収まっているか。テストが実際に走って通ったか。文言・リンク・価格・権限・ログ出力が意図せず変わっていないか。ここまで見て初めて1サイクル完了です。会話が長くなって文脈が膨らんできたら、「何を決めたか/どのファイルを触ったか/どの確認が残っているか」を3行で要約させると、次のサイクルが軽くなります。

コピペで動く：調査メモの抜けチェック

7つのプロンプトを回したら、調査結果を1枚のメモにまとめます。次のNode.jsスクリプトは、そのメモに最低限の見出しが揃っているかを機械的に確認するだけのものです。first-pass-note.mdを作ってから実行できます。人の目だけに頼らず、抜けを門番に弾かせる発想です。

// check-first-pass-note.mjs
// 調査メモに必須セクションが揃っているか確認する小さなスクリプト
import { readFile } from "node:fs/promises";

const file = process.argv[2] || "first-pass-note.md";
const text = await readFile(file, "utf8");

// 7つのプロンプトに対応する必須キーワード
const required = ["構成", "入口", "流れ", "呼び出し元", "影響範囲", "テスト", "残ったリスク"];
const missing = required.filter((word) => !text.includes(word));

if (missing.length > 0) {
  console.error(`不足セクション: ${missing.join(", ")}`);
  process.exit(1); // CIや事前チェックで止められるよう異常終了
}

console.log(`OK: ${file} に必要な調査項目がそろっています。`);

実行はこれだけです。

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

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

よくある質問

Q. プロンプトはコピペでそのまま使えますか? A. 使えます。カギ括弧の中（機能名や関数名、ファイルパス）を自分のリポジトリに合わせて差し替えるだけです。「まだ編集しないで」「根拠ファイルを付けて」の2文は消さないでください。ここが安全装置です。

Q. なぜ最初から「実装して」と頼んではいけないのですか? A. 範囲が決まっていないと、Claude Codeは関係しそうなファイルを広く読み、広く直します。冒頭の僕の11ファイル事故がまさにそれです。読む→影響範囲→小さく実装、の順にすると差分が小さく保てます。

Q. 巨大なコードベースで、プロンプト1の答えが浅いときは? A. ディレクトリ単位で区切って同じプロンプトを投げ直すか、検索を段階化します。rg検索の絞り方や依存の追い方は巨大コードベースの読み方に手順をまとめました。

Q. 「呼び出し元」を聞いても全部拾えていない気がします。 A. 動的な呼び出しや文字列経由の参照は漏れがちです。プロンプト4に「文字列で関数名を参照している箇所も探して」と一行足すと拾える率が上がります。最後はプロンプト7のgit diffとテストで担保します。

Q. バグ修正のときも同じ順番でいいですか? A. ほぼ同じです。プロンプト3の前に「症状・期待値・再現手順」を渡すと、原因の絞り込みが速くなります。デバッグ特化の進め方はバグを潰す手順を参照してください。

実際に試した結果

冒頭の11ファイル事故のあと、僕は最初の一文を「直して」から「まだ編集しないで、この構成を説明して」に変えました。たったそれだけで、初日の差分が読みきれる量に収まるようになりました。

特に効いたのは、プロンプト4（呼び出し元）とプロンプト5（影響範囲）をセットで先に投げることです。「この関数、呼び出し元3箇所だけだから安全に変えられる」と数で判断できると、見積もりを外さない。逆に「呼び出し元が20箇所」と分かれば、その時点で慎重モードに切り替えられます。

慣れてきたら、この7文をCLAUDE.mdやチームのスニペットに移して、毎回の説明をゼロにしてください。実務で使うテンプレートをまとめて欲しい方は教材・テンプレート一覧も覗いてみてください。最初の一文を変えるだけで、既存コードとの付き合い方は驚くほど穏やかになります。