公式から学ぶ❗️Claude・Claude Codeのプロンプトのコツ
Anthropic公式ドキュメントを参照
KEITOのメルマガは皆さまの支援によって成り立っています。今後の配信も見逃さないために無料購読をお願いいたします。また有料購読でのご支援もご検討ください。
Anthropic公式ドキュメント『プロンプトのベストプラクティス』を参考にClaude・Claude Codeのプロンプトのコツをまとめていきます。
Claudeのプロンプトは「いい感じにお願いする」よりも、業務指示書として書く のが一番安定します。
Claudeはかなり賢いAIですが、空気を読ませるよりも、
何をしてほしいのか
なぜそれをやるのか
どんな素材を使うのか
どんな形式で出してほしいのか
何を守ってほしいのか
どんな例に近づけてほしいのか
ここまで渡した方が、明らかに精度が上がります。
Anthropic公式でも、Claudeは優秀だけど「新入社員」のようなものだと説明されています。つまり、いきなり雑に仕事を投げるよりも、背景やルール、目的をちゃんと共有した方が良い結果になるということです。
Claudeプロンプトの基本形
Claudeに依頼するときは、以下のような形がかなり使いやすいです。
<role>
あなたは〇〇の専門家です。
</role>
<context>
今回の目的は〇〇です。
対象読者は〇〇です。
なぜこれが重要かというと〇〇だからです。
</context>
<task>
以下の入力をもとに、〇〇を作成してください。
</task>
<input>
ここに素材・文章・データを入れる
</input>
<requirements>
・〇〇の形式で出力
・トーンは〇〇
・初心者にもわかるように
・不要な前置きはなし
・結論から書く
</requirements>
<output_format>
見出し：
本文：
補足：
</output_format>
<examples>
<example>
入力例：
出力例：
</example>
</examples>
ClaudeはXMLタグとの相性が良いので、<context>、<task>、<input>、<requirements> のように情報を分けて書くと、かなり理解しやすくなります。
人間に仕事を頼むときも、資料、目的、条件、納品形式がバラバラだと混乱しますよね。Claudeも同じで、情報の置き場所を整理してあげるだけで、出力のブレがかなり減ります。
Claudeプロンプトで大事な7つのポイント
1. 何をしてほしいかを具体的に書く
悪い例はこれです。
この文章をいい感じにしてこれだと、「いい感じ」の定義がClaude任せになります。
良い例はこうです。
この文章を、X投稿用に短くリライトしてください。
トーンは自然で、少し熱量がある感じ。
文字数は140〜180字。
煽りすぎず、でも読みたくなる文章にしてください。かなり細かいですが、これくらい書いた方が実務では安定します。
Claudeに限らず、AIへの指示で大事なのは「センスに任せすぎないこと」です。
ふわっと頼むと、ふわっと返ってきます。
2. 「なぜやるのか」も伝える
Claudeは背景を渡すと、かなり出力が実務寄りになります。
たとえば、
この文章はYouTube概要欄に入れます。
目的は、有料コミュニティへの自然な誘導です。
売り込み感は弱めたいですが、興味がある人にはちゃんと刺さる文章にしてください。このように、用途・読者・目的を入れると、ただのリライトではなく「どこで使う文章なのか」を踏まえた出力になります。
「短くして」だけだと、単に文字数を削るだけになりがちです。
でも「YouTube概要欄で、有料コミュニティへ自然に誘導したい」と伝えると、Claudeは文章の役割まで考えやすくなります。
3. 出力形式を指定する
Claudeは丁寧に答えてくれる反面、形式を指定しないと「思っていた形と違う」が起きやすいです。
なので、こう書きます。
出力は以下の形式にしてください。
タイトル：
本文：
CTA：記事なら、
以下の構成で出してください。
タイトル
導入文
本文
まとめメールなら、
件名：
本文：という形です。
AIに任せる部分と、こちらで固定する部分を分けるのがポイントです。
形式まで自由にさせると、毎回ちょっと違うアウトプットになります。
4. 例を入れる
Claudeは例があると、一気に安定します。
<examples>
<example>
悪い例：
AIを活用しましょう！すごいです！
良い例：
AIを触って終わりではなく、実務の中でどう使うかまで一緒に試せる場所を作っています。
</example>
</examples>特に、文章のトーンを合わせたいときは例が強いです。
「自然な感じで」と言うより、自然な文章の例を渡した方が早いです。
「KEITOっぽく」「ビジネス寄りだけど硬すぎない」「初心者向けだけど薄くしない」みたいなニュアンスも、例を入れるとかなり伝わりやすくなります。
5. 長い資料は「先に素材、最後に質問」
長文資料や複数ドキュメントを扱う場合は、先に資料を置いて、最後にやってほしいことを書いた方が安定しやすいです。
<documents>
<document>
ここに資料本文
</document>
</documents>
<task>
上記をもとに、初心者向けに要点をまとめてください。
</task>長い資料を渡すときに、最初に質問を書いて、そのあとに大量の資料を置くと、AI側が途中で目的を見失いやすくなります。
イメージとしては、まず資料一式を渡して、最後に「では、この資料をもとに何をしてほしいのか」を伝える感じです。
6. ツールを使わせたいなら明示する
Claudeに「提案して」と言うと、本当に提案だけで終わることがあります。
Claude Codeやエージェント系の使い方では、特にここが重要です。
提案だけでなく、実際にファイルを編集してください。
必要なファイルを確認し、変更点を反映し、最後に変更内容を要約してください。AIに作業させたいなら、「考えて」だけではなく「実行して」と書く必要があります。
これはかなり大事です。
AIに任せているつもりでも、プロンプト上では「アドバイスを求めているだけ」になっているケースがよくあります。
7. 複雑な作業では「考える深さ」も指定する
複雑なタスクでは、Claudeに急がせない方がいいです。
このタスクは複数ステップの判断が必要です。
急がず、方針を整理してから回答してください。
ただし、最終回答では要点を簡潔にまとめてください。特に、設計、分析、コード修正、長文資料の整理などは、最初に少し考えさせた方が安定します。
ただし、最終回答まで長くなりすぎると使いづらいので、
「考えるのは丁寧に、出力は簡潔に」
という指示が実務では使いやすいです。
Claude Codeでも考え方はほぼ同じ
この考え方はClaude Codeにも共通しています。
ただしClaude Codeの場合は、普通のClaudeよりもさらに 「作業指示書」感を強くする のがコツです。
通常のClaudeは、基本的には文章を返すAIです。
一方でClaude Codeは、コードベースを読んで、ファイルを編集して、テストして、場合によってはGit操作まで行う開発エージェントです。
つまり、普通のClaudeには「発注書を書く」。
Claude Codeには、さらに一段進んで 「作業手順つきの開発チケットを書く」 イメージです。
Claude Codeで特に大事なこと
1. まず調査させる
Claude Codeにいきなり「直して」と頼むより、まず調査させた方が安定します。
まずコードベース全体を確認して、関連ファイルを特定してください。
まだ編集はしないでください。
問題点と修正方針を先に説明してください。Claude Codeは実際にファイルを触れるので、いきなり編集させると、全体を見ずに部分的な修正をしてしまうことがあります。
まず調査。
次に方針。
そのあと編集。
この順番がかなり大事です。
2. 編集範囲を指定する
Claude Codeは広く動けるぶん、放っておくと「ついでにここも直しました」が起きます。
なので、触っていいファイルを指定します。
変更してよいファイルは以下のみです。
- src/components/UserCard.tsx
- src/lib/user.ts
それ以外のファイルは変更しないでください。実務では、変更範囲を縛るのはかなり重要です。
AIが優秀になるほど、勝手に気を利かせる範囲も広がります。
だからこそ、「今回はここだけ」と明確にしておく必要があります。
3. ゴールを「完成状態」で書く
Claude Codeでは、「何をしてほしいか」よりも「どうなっていたら完了か」を書く方が強いです。
悪い例はこれです。
ログイン周りをいい感じにして良い例はこうです。
ログイン失敗時に、ユーザーへエラーメッセージが表示されるようにしてください。
現在はAPIが401を返しても画面に何も出ません。
要件は以下です。
- 401の場合：「メールアドレスまたはパスワードが違います」と表示
- 500の場合：「時間をおいて再度お試しください」と表示
- 成功時の挙動は変えない
- 既存のUIデザインに合わせる
- 修正後に関連テストを実行するClaude Codeには、このくらい書いた方がいいです。
逆に言うと、作業指示書をちゃんと書ける人ほど、Claude Codeをうまく使えます。
4. テスト・確認まで指示する
Claude Codeには、コードを書かせるだけではなく、確認まで依頼した方がいいです。
修正後、可能であれば以下を実行してください。
npm run lint
npm run test
実行できない場合は、その理由と代替確認方法を教えてください。「実装して終わり」ではなく、
「実装 → 確認 → 結果報告」までが1セットです。
Claude Codeを使うなら、ここまでプロンプトに入れるのがかなりおすすめです。
5. CLAUDE.mdに恒久ルールを書く
Claude Codeでは、CLAUDE.md にプロジェクトのルールを書いておくと便利です。
たとえば、こんな内容です。
# Project Instructions
- 回答は日本語で行う
- 変更前に必ず関連ファイルを確認する
- 大きな変更をする前に方針を説明する
- TypeScriptではanyをできるだけ使わない
- UIは既存コンポーネントの設計に合わせる
- 変更後は可能な範囲でlint/testを実行する
- 不明点がある場合は勝手に大きく変更せず、確認するこれはClaude Code用の「現場ルールブック」です。
毎回同じことをプロンプトに書くのは大変なので、プロジェクト共通のルールは CLAUDE.md に入れておく。
そのうえで、毎回の作業内容だけプロンプトで指示する。
この使い方がかなり実務的です。
Claude Code用のプロンプトテンプレ
Claude Codeでは、以下の型が使いやすいです。
目的：
〇〇を実現したいです。
現状：
現在は〇〇の状態です。
問題は〇〇です。
やってほしいこと：
1. まず関連ファイルを調査してください
2. 修正方針を簡潔に説明してください
3. 必要なファイルだけ編集してください
4. 修正後にlint/testを実行してください
5. 最後に変更内容と確認結果をまとめてください
制約：
- 既存のUIデザインは崩さない
- 不要なリファクタはしない
- 変更範囲は最小限にする
- 〇〇ファイルは触らない
完了条件：
- 〇〇ができる
- 〇〇のエラーが出ない
- 既存機能に影響しないこれはそのまま使えます。
Claude Codeに雑に、
このバグ直してと頼んでも動くことはあります。
ただ、安定させたいなら、
原因調査 → 方針説明 → 最小変更 → テスト → 要約この流れを明示した方がいいです。
まとめ
Claudeのプロンプトは、「お願い」ではなく 業務指示書 として書く。
Claude Codeの場合は、さらに踏み込んで 作業手順つきの開発チケット として書く。
これが一番しっくりきます。
Claudeに必要なのは、魔法の一文ではありません。
大事なのは、
目的
背景
入力
制約
出力形式
例
完了条件
このあたりをちゃんと渡すことです。
「いい感じにして」だと、Claudeのセンス任せになります。
でも「何のために、誰向けに、どんな形式で、何を守って、どこまでやるのか」まで書けば、Claudeはかなり素直に動いてくれます。
一言でまとめるなら、
Claudeにはプロンプトではなく、発注書を書く。
Claude Codeには、開発チケットを書く。
この考え方を持つだけで、Claudeの出力はかなり安定します。
今後、Claudeスキルのベストプラクティス編、Claude Codeのベストプラクティス編も書いていこうと考えてます。AIを学びたい人は、必ず下記から購読しといてください。
最後まで読んで頂きありがとうございます。KEITOのメルマガは皆さまの支援によって成り立っています。今後の配信も見逃さないために無料購読をお願いいたします。また有料購読でのご支援もご検討ください。
ありがとうございます
とても参考になりました