Claudeプロンプトの書き方 — 良い指示を出す7つのコツ

Claudeへの指示で結果はどこまで変わるか

同じ依頼でも、指示の書き方で返ってくる答えの質は大きく変わります。「分析ダッシュボードを作って」とだけ送ると最低限の実装が返り、「関連する機能や操作性を盛り込んで、基本を超えた完成度に仕上げて」と条件を添えると仕上がりの密度が上がります。これはAnthropic自身が公式ガイドで挙げている実例です。

プロンプトとは、Claudeに渡す指示文そのものを指します。良いプロンプトの条件は、宛先が人間の同僚でも成立するかどうかです。文脈を知らない同僚にその文面を見せて、迷わず作業に取りかかれるなら、Claudeも同じように動けます。逆に同僚が聞き返したくなる指示は、Claudeにとっても曖昧です。

以下の7つは、公式の推奨事項とAnthropic自身のブログ記事が共通して挙げる技法を、チャットでの使い方に合わせて並べたものです。

良い指示を書く7つのコツ

1. 曖昧さを残さず具体的に伝える

「もっと良くして」ではなく、何をどう変えたいかを明示します。出力形式・文字数・対象読者といった制約は、書けば書くほど狙いに近づきます。

• 弱い指示: 「分析ダッシュボードを作って」
• 強い指示: 「分析ダッシュボードを作って。関連する機能や操作性はできる限り盛り込み、基本を超えた完成度に仕上げて」

「above and beyond」のような踏み込んだ結果が欲しいときも、Claudeの推測任せにせず、その旨を直接書くほうが確実です。手順の順序や完全性が重要な依頼では、番号付きリストで工程を並べるとさらに安定します。

2. 指示の理由や背景を添える

指示だけでなく「なぜそうしてほしいか」を一文添えると、Claudeはその意図を汎用化して応用します。

• 弱い指示: 「省略記号(…)は絶対に使わないで」
• 強い指示: 「この文章は音声合成エンジンで読み上げます。省略記号は正しく発音できないので使わないでください」

理由まで書くと、省略記号そのものだけでなく、読み上げに向かない記号全般への配慮まで汎用化されます。禁止事項を書くだけでは、その記号だけを避けて別の読みにくい記号を使ってしまうことがあります。

3. 実例を1〜2個ではなく3〜5個示す

見本を見せる指示(few-shotプロンプティング)は、出力の形式・トーン・構造を安定させる効果が高い技法です。公式ガイドは3〜5個の実例を推奨しています。実例は本物の使用場面に近く、かつパターンが偏らないよう多様にするのがコツです。実例が1つしかないと、Claudeがその1例だけに特有の癖まで正解パターンとして拾ってしまうことがあります。迷ったら、Claude自身に「この実例は用途に対して十分に多様か」と評価させ、不足分を追加生成させる使い方もできます。

4. 長い指示は塊ごとに区切る

依頼が長くなるほど、指示・背景情報・入力データが地の文で混ざり、読み違いが起きやすくなります。<instructions>や<context>のような見出しで塊を区切ると、Claudeも人間の読み手も構造を追いやすくなります。

長文の資料を貼り付けるときは、資料を先頭に置き、質問や指示を最後に置く順番のほうが精度は上がります。複数の資料を扱う場合は、資料ごとに出典名を添えて区切ると、どの資料の情報を根拠にしたかをClaudeが答えの中で示しやすくなります。

5. 役割を与えて振る舞いを絞る

「あなたはPythonに詳しいコーディングアシスタントです」のような一文を添えるだけで、語彙選びや回答の切り口が変わります。役割設定は、システムプロンプトの冒頭に置く一文でも十分に効きます。専門用語の使い方や、初心者への配慮の度合いも役割に応じて自然に調整されます。

6. 禁止形でなく肯定形で出力形式を指定する

「箇条書きを使わないで」より、「流れるような文章の段落で書いて」と伝えるほうが安定します。禁止形は「何を避けるか」しか伝わらず、Claudeが代わりに何を選ぶかは推測任せになるためです。

• 弱い指示: 「マークダウンを使わないで」
• 強い指示: 「なめらかに流れる文章の段落だけで回答して」

マークダウンの分量を抑えたいときも、見出しやコードブロックだけ残し、太字や箇条書きを避けるよう具体的に書きます。指示文自体を平文で書くと、出力もそのスタイルに寄る傾向があるため、プロンプトの見た目を理想の出力に近づけておくのも有効です。

7. 一度で完成させず、対話で磨く

最初の指示で7割の完成度に届いたら、そこから追加の指示で微調整するほうが、最初から完璧な一文を書こうとするより速く狙いに届きます。Claudeは訂正や追加条件にも柔軟に応じるため、往復を前提にしたほうが実務では効率的です。

• 1回目: 「企画書のたたき台を作って」
• 2回目: 「2枚目のグラフの説明をもっと短くして」
• 3回目: 「全体を経営会議向けのトーンに寄せて」

出力の一部分だけを直したいときは、全文を書き直させるのではなく「この段落だけ直して」と範囲を絞ると、無関係な箇所まで変わってしまう事故を防げます。

書き始める前に決めておくと近道になること

毎回同じ種類の依頼を繰り返すなら、指示を書く前に「何ができれば成功か」を自分の中で一文にしておくと、追加の往復が減ります。公式ガイドも、プロンプトを改善する作業に入る前に、成功の基準と最初のたたき台を用意しておくよう勧めています。基準が曖昧なまま指示だけ練っても、Claudeの出力を評価する物差しがぶれて、いつまでも「なんとなく違う」を繰り返すことになります。

用途別に効くコツの使い分け

7つすべてを毎回使う必要はありません。用途によって効き方が変わります。

コーディング用途は「提案にとどまるか、実際に変更するか」の差が出やすい場面です。「この関数の改善点を提案して」では提案どまりになりがちですが、「このバグを直して」と行動を明示すると変更まで進みます。Claude Code内でのプロンプト設計は、命令型・探索型など5つの構造パターンとしてより実践的にまとめています。開発作業がメインの人はClaude Codeで効くプロンプトの5パターンも参照してください。

よくあるつまずき

一言指示を毎回ゼロから書き直すのは非効率です。文体や前提を毎回説明し直すくらいなら、Projectsに前提知識を常駐させておきます。繰り返す作業はカスタムSkillとしてパッケージ化すれば、2回目以降の指示は短くて済みます。

技法を全部詰め込むのも逆効果です。役割設定・実例・XML構造化・出力形式指定を1つの指示に全部盛り込むと、かえって読みにくくなります。公式のブログ記事も、技法を無差別に組み合わせるより基本の明確さを優先するよう注意を促しています。

否定形の指示を積み重ねると、Claudeが避けるべきことは分かっても、代わりに何をすべきかが伝わりません。禁止事項を並べる前に、まず望む結果を一文で書き切れないか考えます。

例を1つしか出さないと、Claudeがその1例特有の癖まで拾ってしまうことがあります。実例は複数用意し、共通するパターンだけが伝わるようにします。

よくある質問

プロンプトエンジニアリングとプロンプトの書き方は同じですか

プロンプトエンジニアリングは、成功基準を決めて指示文を継続的に改善していく作業全体を指します。本記事で扱う「書き方のコツ」はその出発点で、まず質の良い初稿を書くための原則です。継続的な改善が必要な業務利用では、成功基準を先に決めてから指示を磨き込む進め方が公式ガイドでも推奨されています。

長い指示文を書くとClaudeは混乱しませんか

指示の長さそのものは問題ではなく、構造が混乱の原因になります。塊ごとに区切って渡せば、長い指示でも複数条件を漏らさず反映できます。逆に短くても要素が入り混じった指示は読み違えが起きやすくなります。

日本語と英語、どちらでプロンプトを書くべきですか

どちらでも解釈できますが、専門用語やコード関連の指示は英語のほうが誤解が少ない場面があります。文章のトーンや日本語特有の言い回しを扱うタスクでは、日本語で具体的に書いたほうが意図が伝わりやすくなります。

同じ指示でも毎回違う答えが返るのはなぜですか

出力形式や制約を明示していない指示は、Claudeが解釈の余地を埋める形で毎回異なる構成を選びがちです。見出しの数や箇条書きの有無まで指定すると、再現性は大きく上がります。逆に、意図的に案を広げたいブレインストーミングのような場面では、この揺らぎ自体が新しい発想の材料になります。

実例を用意する時間がないときはどうすればいいですか

実例が1つも用意できない場合は、まず具体的に指示を書き、Claudeが返した最初の出力を実例代わりに調整して伝え直す方法があります。「さっきの出力のこの部分は良いが、ここは違う」と伝えるだけでも、実例を示したのと近い効果が得られます。

まとめ

良いプロンプトは、才能ではなく型で書けます。具体性・背景・実例・構造化・役割・出力形式・反復という7つの型に沿って書けば、初めての依頼でも狙った出力に近づきます。逆に、これらを飛ばして一言だけ投げると、Claudeの推測に結果が左右されます。まずは今書きかけの指示に、この7つのうちどれが抜けているかを当てはめてみると、次の一文が変わります。用途別のコピペ例はそのまま使えるClaudeプロンプト例集にまとめています。