Claude Codeに指示してみたのに、思っていた出力と全然違う——そんな経験はありませんか。
「なんか意図が伝わっていない気がする」「修正を頼んだら余計に複雑になった」という感覚の多くは、プロンプトの書き方を少し変えるだけで解消できます。
この記事では、実際にClaude Codeを使いながら試行錯誤の末に気づいた7つのコツを解説します。
- プロンプトがうまく機能しない根本的な原因
- すぐ使える7つの書き方のコツ
- CLAUDE.mdと組み合わせた効率化の方法
- よくある質問への回答
Claude Codeプロンプトが「なんとなく」では通じない理由
Claude Codeは会話AIと違い、コードを書いてファイルを操作してコマンドを実行する「エージェント」です。そのぶん、指示の曖昧さが直接、出力のブレに繋がります。
「いい感じに直して」は最も危険な指示
「いい感じにリファクタリングして」という指示を出したとき、Claude Codeはどう動くでしょうか。
変数名を変える場合もあれば、関数を分割する場合も、コメントを追加するだけの場合もあります。「いい感じ」の定義が曖昧なまま任せると、意図とまったく異なる方向に進んでしまいます。
Claude Codeに限らず、AIエージェントへの指示で「曖昧さ」は最大のリスクです。
Claude Codeプロンプトが迷子になる3つのパターン
実際によく遭遇する、Claude Codeが意図通りに動かないパターンは主に3つあります。
- タスクの範囲が広すぎる:「このアプリを完成させて」など、複数の作業を一度に頼む
- 前提が伝わっていない:どんな環境・どんなコードベースかの説明がない
- 出力形式が未指定:「説明して」だけでは、コード付きか文章だけかが不明
これらのパターンを意識するだけで、プロンプトの書き方がかなり変わります。
Claude Codeプロンプトのコツ①〜③:土台の整え方
Claude Codeプロンプトの精度を高めるには、まず土台となる3つの要素を押さえることが重要です。ここを丁寧にするだけで、出力の質が一段変わります。
コツ① タスクは1つに絞る
1つのプロンプトには、1つのタスクだけを書く——これが最も効果的なルールです。
「ログイン機能を作って、あとバリデーションも追加して、エラーメッセージも日本語にして」と一度に頼むと、Claude Codeはそれぞれを処理しながら整合性を保とうとして、かえってミスが増えます。
まずログイン機能だけ作る。確認してから、バリデーションを追加する。この順番を守るだけで、修正の手間が大きく減ります。
コツ② 背景(コンテキスト)を必ず添える
Claude Codeは、あなたのプロジェクトの文脈を自動でわかってくれるわけではありません。関連するファイルや今の状況を都度、一緒に伝える必要があります。
たとえばこんな形で渡すと伝わりやすくなります。
- 「このReactプロジェクトで、`src/components/Auth.tsx` のログイン処理を修正してほしい」
- 「現在 `users` テーブルには `id`・`email`・`password_hash` の3カラムがある」
- 「Node.js 20系・TypeScript使用。テストはJestを使っている」
背景を渡すことで、Claude Codeは「このプロジェクトでの正解」を判断できるようになります。
コツ③ 出力形式を明示する
「この関数を改善して」という指示に対して、Claude Codeが出力するのはコードのみか、説明付きか、それともテストコードまで含めるかは、あなたが指定しない限り一定しません。
「コードのみ・コメントなし・TypeScript形式で」のように出力形式を先に明示しておくと、余計な部分が混入せず、すぐ使える出力が得られます。
Claude Codeプロンプトのコツ④〜⑦:精度を上げる応用技
土台が整ったら、次はより精度を高める4つの応用技を取り入れていきます。Claude Codeプロンプトの可能性をさらに引き出す工夫です。
コツ④ 「やってほしくないこと」を先に書く
ポジティブな指示だけでなく、ネガティブな制約を明示することで、出力が格段に安定します。
「既存のテストを壊さないように」「`main` ブランチには直接コミットしないで」「外部ライブラリを追加しないで」——こういった制約を最初に書いておくと、後から「そこは変えないでほしかった」という事態を防げます。
やることを増やすより、やらないことを先に定義するほうが、出力の安定感は上がります。
コツ⑤ CLAUDE.mdで繰り返し指示を省く
毎回同じことをプロンプトに書いているなら、それはCLAUDE.mdに書くべき内容です。
「TypeScriptを使う」「コメントは日本語で書く」「テストは必ずJestで書く」といった常時適用したいルールは、Claude Code CLAUDE.mdの書き方に従ってファイルに記述しておくと、プロンプトをシンプルに保てます。
プロンプトが「今やるタスク」に集中できるようになるため、指示の精度も自然と上がります。
コツ⑥ 段階的に確認を挟む
長い処理を一気にやらせるより、途中で確認ポイントを設けるほうが安全です。
「まず設計だけ提案して。OKなら実装に進んで」という形で指示すると、方向性がずれたまま大量のコードが生成されるリスクを減らせます。
特に新機能の実装や、既存コードの大幅な変更を依頼するときに効果的です。
コツ⑦ うまくいかなかったプロンプトを育て直す
プロンプトは一発で完成するものではありません。意図した出力にならなかったとき、「なぜ通じなかったか」を分析して次の指示に活かすことで、精度が徐々に上がっていきます。
よくある改善ポイントはこの3つです。
- コンテキスト不足:前提となるファイルや状況を追加する
- タスクの粒度が大きすぎた:手順をより細かく分解する
- 制約が未定義:「やってほしくないこと」を明示する
失敗したプロンプトをそのまま捨てず、原因を把握して書き直す習慣をつけると、プロンプトの質は着実に上がります。
実際に使ってわかった:プロンプト設計で気づいた3つのこと
ここからは、実際にClaude Codeを使ってきた中で気づいた、マニュアルには載っていないポイントを3つ紹介します。
「長いプロンプト」が必ずしも良いわけではない
丁寧に書こうとするあまり、プロンプトが長くなりすぎることがあります。
情報量が多すぎると、Claude Codeがどこに集中すべきかを見失うことがあります。「必要な情報を過不足なく」が基本で、タスク1つに対して5〜10行程度が扱いやすい目安です。
英語と日本語はどちらでも問題ない
プロンプトを英語で書くべきか日本語で書くべきか悩む場合もあるかもしれませんが、どちらでも動作の精度に大きな差はありません。
ただし、コードベースが英語のコメント・変数名で構成されている場合は、英語プロンプトのほうが整合性の取れた出力になることがあります。プロジェクトの主言語に合わせるのが自然です。
エラーが出たらそのままコピペして渡す
エラーが発生した場合、エラーメッセージをそのままプロンプトに貼り付けるのが最速の対処です。「なんかエラーが出た」ではなく、スタックトレースごと渡すことで、Claude Codeは原因を正確に特定して修正案を出してくれます。
エラー対処の詳しい方法はClaude Codeエラー対処法でも解説しています。
Claude Codeプロンプトに関するよくある質問
Claude Codeのプロンプトについて、よく寄せられる質問をまとめました。
Q:プロンプトの長さはどのくらいが適切ですか?
A:タスク1つに対して5〜10行が目安です。背景・タスク内容・出力形式の3要素を含めつつ、余分な情報は省くことを意識してください。長すぎるプロンプトはClaude Codeが焦点を絞りにくくなる場合があります。
Q:日本語と英語どちらで書けばいいですか?
A:どちらでも精度に大きな差はありません。ただしコードベースの言語(コメントや変数名)と揃えると、整合性の取れた出力になりやすいです。迷うならプロジェクトの主言語に合わせてください。
Q:同じプロンプトを効率よく使い回す方法はありますか?
A:繰り返し使うルールはCLAUDE.mdに書いておくのが最も効果的です。また、よく使うプロンプトをテキストファイルとして手元に保存してコピペする方法もシンプルで使いやすいです。CLAUDE.mdの活用についてはClaude Code CLAUDE.mdの書き方を参照してください。
Claude Codeプロンプトのコツをまとめる
Claude Codeのプロンプトで大切なのは、「AIが迷わないように設計する」という意識です。
- タスクは1つに絞り、背景を添えて、出力形式を明示する(土台の3つ)
- 「やってほしくないこと」「段階的な確認」「CLAUDE.mdの活用」で精度を上げる(応用の4つ)
- 失敗したプロンプトは捨てずに分析して育て直す
プロンプトを書く力は、練習で確実に上がります。うまくいかない経験を積み重ねながら少しずつ磨いていくと、Claude Codeとのやり取りがぐっとスムーズになります。
Claude Codeの業務での活用事例に興味がある方は、Claude Code業務効率化の実例もあわせてご覧ください。

0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。