Claude Codeへの指示の書き方｜うまくいく人が必ず書いている3つのこと

Claude Codeに指示が通らない原因を整理し、対象ファイル・完成条件・禁止事項を入れた頼み方を失敗例から身につけられます。

指示がうまい人は、うまい言い回しを知っているのではありません。毎回、同じ3つの前提を書いているだけです。「どこを直すか(対象)」「何ができたら完成か(完成条件)」「やらないこと(変更の範囲)」。この3つがそろうと、行き違いはぐっと減ります。

先にことわっておくと、この3点セットはAnthropic公式が定めた決まりごとではありません。公式ドキュメントの推奨をもとに、この記事が初心者向けに整理した「実務で使いやすい型」です。根拠になった公式ページは、記事の最後にまとめて置いています。

この記事で分かることは4つ。指示がずれる原因、毎回書くべき3点、大きい作業の進め方、失敗したときの直し方です。

指示がずれる原因は、言葉の上手さではない

自分の場合は、最初に「記事ページを見やすくして」とだけ頼みました。返ってきた画面は整っていましたが、直してほしかった記事ではなく、記事一覧のページが変わっていました。さらに色や文字まで広く変わり、元へ戻す作業も必要になりました。

Claude Codeが指示を無視したわけではありません。公式の解説によると、Claude Codeは依頼の文だけでなく、それまでの会話、読んだファイル、コマンドの実行結果といった「文脈(コンテキスト)」を使って作業します(How Claude Code works)。依頼に複数の解釈が残っていると、そのうちの一つを選んで進みます。選ばれた一つが、自分の頭の中の正解と違っていた。それだけのことです。

公式のベストプラクティスも、具体的なファイル、守ってほしい制約、参考になる既存のコードを示すよう案内しています(Best practices)。うまい言い回しを探す前に、正解を一つに絞る情報を渡します。

この考え方はClaude Codeだけに閉じたものではありません。OpenAIのCodex公式資料も、望む動作、関係するコードまたは再現手順、重要な制約、変更の検証方法を有用な依頼の要素として挙げています(Prompting Codex)。製品をまたいで共通しているのは、長い文章よりも「何を材料に、どこまで進め、何で合否を決めるか」を渡すことです。

毎回書くのは、この3つ

1つ目:対象と背景

分かるなら、触ってほしい場所を書きます。「記事を直して」ではなく、「src/pages/article.astro を直して」のように場所まで書きます(このファイル名は説明用の例です。自分のプロジェクトの実際の場所に置き換えてください)。

場所が分からなくても大丈夫です。無理にファイル名を当てにいく必要はありません。公式のQuickstartでは、Claude Code自身が関連するコードを探し、文脈を理解してから直す流れが示されています(Quickstart)。だから初心者は、症状と場面を伝えます。「記事の詳細ページで、スマホだと見出しがはみ出す。どのファイルが関係するか先に調べて、変更する前に候補を教えて」。これで十分に通じます。

バグを頼むときも同じです。公式は、症状、関係しそうな場所、そして「どうなったら直ったと言えるか」を伝える例を載せています(Best practices)。エラー文をそのまま貼るのも、立派な「背景」です。

2つ目:完成条件と確認方法

「見やすく」では、人によって答えが変わります。「スマホで見出しが画面からはみ出さず、本文が読みやすい幅になったら完成」のように、確認できる状態を書きます。

さらに一歩進めるなら、Claude Code自身が合否を確かめられる手段を渡します。公式が検証の手段として挙げているのは、たとえば次のようなものです(Best practices)。

テスト(=期待どおり動くかを自動で調べる仕組み)を実行して通す
ビルド(=公開用にファイルを組み立てる処理)がエラーなく終わる
lint(=書き方の自動チェック)に引っかからない
期待する出力と、実際の出力を見比べる
デザインと見比べるためのスクリーンショットを撮る

見た目の作業ならスクリーンショット、コードの修正ならテストやビルド、と作業の種類に合わせて選びます。すべての作業に同じ確認方法を当てはめる必要はありません。確認した結果(テストの出力や画像)まで報告してもらうと、こちらが目で確かめる手間も減ります。

3つ目:やらないことと変更範囲

「色は変えない」「ほかのファイルは触らない」「新しい道具(ライブラリ)は追加しない」と範囲を止めます。これはClaude Codeを縛るためではなく、安心して任せるための境界線です。

ただし、一つ知っておくべきことがあります。会話に書いた禁止は「行動の方向づけ」であって、機械的な強制ではありません。公式の権限ページは、プロンプトやCLAUDE.mdはClaudeが何を試みるかに影響するが、許可される操作そのものを変えるわけではない、と説明しています(Configure permissions)。編集の前に必ず計画を確認したいならPlan Mode(=調査と計画だけで、ファイルを編集しないモード)、特定の操作を厳格に禁止したいならdenyルール(=拒否の権限設定)という仕組みが用意されています。細かい設定はこの記事の範囲を超えるので、利用する時点の公式権限ページで確認してください。

3点を入れた指示は、この順で組み立てる

実際の指示は、次の形で十分です。

対象: src/pages/article.astro だけを直す（ファイル名は例）
完成条件: スマホ幅で見出しがはみ出さず、本文が読みやすい幅になる。変更前後のスクリーンショットで確認する
変更しない範囲: 色、ほかのファイル、新しい道具は変更・追加しない
報告: 変更点と確認結果を最後に説明する

対象ファイルが分からない場合は、症状と調査範囲を先に渡します。

対象: 記事詳細ページで、スマホだと見出しがはみ出す。関係するファイルを先に調べる
完成条件: 原因となるファイルと修正候補が特定できる
変更しない範囲: 調査中はファイルを変更しない
報告: 特定したファイル、原因、次に必要な修正を説明する

プロジェクト共通の指示はCLAUDE.mdの書き方、操作を許可する範囲はClaude Codeの許可設定も続けて確認できます。

順番は「対象と背景 → 完成条件と確認方法 → やらないこと → 最後に出してほしい報告」です。一文を飾る必要はありません。曖昧な頼み方との違いを、よくある3つの場面で並べます。

場面	曖昧な頼み方	3点を入れた頼み方
見た目の修正	「ページを見やすくして」	「記事詳細ページが対象。スマホで見出しが収まれば完成。色は変えない」
バグの直し	「エラーを直して」	「保存ボタンを押すと消える症状。再現手順はこれ。直ったらテストを実行して結果を見せて。関係ないファイルは触らない」
文章の修正	「記事をいい感じにして」	「この記事の導入だけが対象。3行以内に短くなれば完成。ほかの節と結論は変えない」

バグの例のように、症状と再現手順を伝えるやり方は公式も推奨しています(Best practices)。

作業後は、説明だけで終わらせず、自分でも完成条件を見ます。違っていたら「いい感じに直して」ではなく、「見出しは直った。本文の幅だけ元に戻して」と、合格した点と残りを分けて伝えます。

3点だけで足りない作業は、証拠を1つ足す

対象・完成条件・やらないことは、依頼の土台です。どんな作業でもこの3点だけで足りる、という意味ではありません。OpenAIのCodex公式資料にも、関係するコードまたは再現手順を示し、重要な制約を残し、検証方法を書くとあります(Prompting Codex)。Claude Platformの公式資料も、プロンプトを工夫する前に、成功条件と、それを実際に試す方法を決めるよう案内しています(Prompt engineering overview)。

追加する材料は、作業によって変えます。全部を盛り込むのではなく、結果を変えるものを1つか2つ選びます。

作業の種類	追加すると役立つ材料	何を防げるか
同じエラーが出る	エラー全文、再現手順、最後に正常だった操作	原因を推測だけで決めること
見た目を直す	現在の画面、参考画像、確認する画面幅	「見やすい」の解釈違い
決まった形式で出す	入力例と、期待する出力例	項目名や並び順のずれ
既存コードへ足す	手本にするファイル、使ってよい既存部品	別の書き方や新しい依存の混入
長い作業を任せる	途中の確認地点、停止条件、時間や費用の上限	失敗したまま作業が広がること

入力例と期待出力を見せる方法は、OpenAIの公式API資料でも、出力の型を伝える手段として説明されています。同じ資料は、コード変更ではテストやコマンドで確認し、ツールの「完了」という表示だけで成功と決めないよう案内しています(Prompt engineering)。

長い自律作業には不利な面もあります。Anthropicの公式エンジニアリング記事は、エージェント型の作業では処理時間と費用が増え、誤りが重なる可能性があるため、必要なときだけ複雑さを足すよう説明しています。また、作業中はテスト結果やコマンド出力など、環境から得た事実で進み具合を確かめ、反復回数の上限などの停止条件を置く例も示しています(Building effective agents)。

たとえば「エラーを直して」へ説明を10行足すより、「この操作で再現する」「このエラー全文が出る」「テストが通れば完成」「3回試して直らなければ変更を止め、原因候補を報告」と書くほうが、調査の入口と終点がはっきりします。

この型だけで進めない方がよい場合

削除、公開、購入、秘密情報の入力など、失敗したときの影響が大きい操作は、依頼文に「しないで」と書くだけで進めないほうが安全です。権限設定やPlan Modeを使い、実行前に人が確認する工程を残します。原因も対象ファイルも分からない不具合は、最初から修正まで頼まず、まず調査と再現だけを頼みます。

送信前の30秒チェック

完成した指示を上から読み直し、次の5点が見つかるか確認します。

対象: ファイル、画面、機能、または症状のどれかが書いてある
完成条件: 「直った」「見やすい」ではなく、目で見たりコマンドで確かめたりできる
変更範囲: 変えてよい場所と、変えない場所が区別されている
検証: テスト、ビルド、スクリーンショット、期待出力のどれか1つがある
証拠: 最後の報告に、変更したファイルと検証結果を含めるよう書いてある

5点のうち対象が分からないときは、ファイル名を作らず「まず関連箇所を調べる」に変えます。検証方法が分からないときは、「このプロジェクトで使える確認方法を調べ、実行して結果を示す」と頼めます。チェックの目的は、依頼を長くすることではありません。Claude Codeが自分で次の一手と終わりを判断できる状態にすることです。

大きい作業と、失敗したあとの立て直し方

大きい作業は、探索・計画・実装を分ける

小さな修正なら、上の型だけで足ります。しかし「対象がどこか分からない」「複数のファイルにまたがりそう」「そもそも仕組みを理解していない」ときは、いきなり編集させないほうが安全です。

手順はこうです。

まず探索を頼む。「この機能に関係するファイルを調べて、仕組みを説明して」
次に計画を頼む。「直す手順を先に示して。まだ編集しないで」
計画に納得してから、実装を頼む。

Plan Modeを使うと、この「編集しない」を仕組みとして守らせられます。Plan ModeのClaude Codeはファイルを読み、読み取り専用のコマンドで調査し、計画を作りますが、ソースファイルは編集しません(Configure permissions)。公式は、方針が不明なとき、複数ファイルを変えるとき、対象のコードに不慣れなときにPlan Modeが特に有効だとし、差分を一言で説明できる小さな修正なら直接頼めるとしています(Best practices)。毎回使う必要はありません。

失敗したら、指示を長くする前に前提を足す

結果がずれたとき、指示の全文を書き直す必要はありません。まず「対象」「完成条件」「やらないこと」「確認方法」のどれが抜けたかを探します。

対象が違えばファイル名か症状を足す。完成像が違えば、確認できる条件へ直す。変更が広すぎれば、触らない範囲を足す。この順で直すと、会話が長くなりにくく、次の作業にも同じ型を使えます。

同じ注意を2回書いたら、CLAUDE.mdへ移す

もう一つ大事な仕組みがあります。Claude Codeのセッション(=1回の作業の会話)は、毎回新しいコンテキストから始まります。長い会話は途中で圧縮され、最初のほうの細かい指示が失われることもあります(How Claude Code works)。だから、別の日にも同じ注意を書いている自分に気づいたら、それはCLAUDE.mdへ移す合図です。

CLAUDE.mdは、プロジェクトの決まりごとを書いておくと毎回の会話の開始時に読み込まれるファイルです。公式は、同じ訂正を繰り返しているときが追加のタイミングだと案内しています(How Claude remembers your project)。ただしこれも強制設定ではなくコンテキストなので、短く、具体的で、矛盾のない内容に保つほど一貫して守られやすくなります。「その作業だけの条件は依頼文に、毎回必要な決まりはCLAUDE.mdに」と覚えておけば十分です。

よくある質問

対象ファイルが分からないときは、どう指示すればよいですか？

ファイル名を推測して書く必要はありません。起きている症状、対象の画面や機能、再現手順を伝え、「まず関連するコードを探して、変更候補を教えて」と頼みます。公式も、Claude Codeが関連コードを特定してから直す進め方を示しています(Quickstart)。

「いい感じに直して」では、なぜ足りないのですか？

何を合格とするかが人によって変わり、Claude Codeが自分で確かめられないからです。期待する動き、通してほしいテスト、ビルドが通ること、比較する画面など、合否を判定できる条件に置き換えます(Best practices)。

「ほかのファイルは触らない」と書けば、必ず守られますか？

重要な方向づけにはなりますが、技術的な強制ではありません(Configure permissions)。編集前に確認を挟みたいならPlan Mode、操作そのものを禁止したいなら権限設定(denyルール)を併用します。

毎回Plan Modeを使ったほうがよいですか？

毎回ではありません。公式は、方針が不明なとき、複数ファイルを変えるとき、コードに不慣れなときに有効とし、小さく範囲が明確な修正では直接頼む選択肢を示しています(Best practices)。

同じ注意を毎回書く必要がありますか？

その作業だけの条件は依頼文に書きます。毎回必要なプロジェクトの決まりや、繰り返している訂正はCLAUDE.mdへ移します(How Claude remembers your project)。

指示は長いほどよいですか？

長さではなく、結果を変える情報が入っているかで判断します。関係のない背景や同じ禁止の言い換えを増やすと、重要な条件が見つけにくくなります。対象、完成条件、変更範囲を先に書き、必要なときだけ再現手順、参考ファイル、入出力例、停止条件を足します。公式資料でも、Claude Codeの文脈には会話やファイル、コマンド出力が入り、量が増えるほど管理が必要になると説明されています(Best practices)。

まとめ

次にClaude Codeへ頼みごとをするとき、この3つをやってみてください。

頼む前に「対象(分からなければ症状)・完成条件・やらないこと」の3点をメモしてから書く
完成条件には、スクリーンショットやテストなど、Claude Code自身が確かめられる方法を1つ付ける
同じ注意を2回書いたら、CLAUDE.mdへ移す

なお、Plan Modeや権限設定などの機能名・挙動は今後変わる可能性があります。細かい仕様は、利用する時点の公式案内で確認してください。

公式一次情報

確認日: 2026-07-26

Best practices for Claude Code: 具体的なファイル・制約・症状の伝え方と、テストやスクリーンショットなどClaudeに検証させる手段を案内している
Quickstart: 曖昧な依頼より具体的な症状を書くこと、変更前にClaudeへコードを探索させる進め方を初心者向けに示している
How Claude Code works: セッションが毎回新しいコンテキストで始まる仕組みと、長い会話の圧縮で初期の指示が失われうることを説明している
How Claude remembers your project: CLAUDE.mdは強制設定ではなくコンテキストであり、短く具体的な指示ほど一貫して守られやすいと説明している
Configure permissions: 権限ルールがdeny・ask・allowの順で評価されることと、プロンプトの指示は許可される操作自体を変えないことを説明している
Prompting Codex: Codexへの依頼には、望む動作、関係するコードまたは再現手順、重要な制約、検証方法を含めるよう案内している
Prompt engineering overview: プロンプト改善の前提として、明確な成功条件と、それを実際に試す方法を挙げている
Prompt engineering: 関係する文脈や入出力例を示す方法と、コード変更をテストやコマンドで検証する考え方を説明している
Building effective agents: 長い自律作業の時間・費用・誤りの増幅という不利な面と、環境から得た事実や停止条件で進行を管理する考え方を示している