AIに聞いてみたけど、微妙な答えしか返ってこなかった。この体験のほとんどは、モデルの限界ではなく指示の書き方が原因です。
プロンプトは、モデルへ渡す指示や材料のことです。実務でそのまま使える書き方の型を扱います。
シリーズ目次 / 前章: 05. Claudeを使い始める:画面・プラン・準備 / 次章: 07. ClaudeのProjects・Artifacts・メモリ
Table of contents
Open Table of contents
この章のねらい
- 良いプロンプトの構成要素を知り、自分で組み立てられるようになる
- XMLタグによる区切りなど、Claudeで特に効く書き方を身につける
- 現行モデルで逆効果になりやすい書き方を避けられるようになる
5つの構成要素
次の5つを意識して組み立てると、結果が安定します。
| 要素 | 中身 | 例 |
|---|---|---|
| 文脈 | 誰のための、何のための作業か | 「社内の非エンジニア向け勉強会の資料です」 |
| 依頼 | やってほしいこと | 「この技術文書を要約してください」 |
| 材料 | 対象の文章やデータ | 実際の文書本文 |
| 制約 | 守ってほしい条件 | 「専門用語には必ず注釈を付ける」 |
| 出力形式 | 返してほしい形 | 「見出し付きの箇条書きで、全体800字以内」 |
全部を毎回書く必要はありません。ただし思ったものが返ってこないときは、この5つのどれかが欠けています。そう考えると原因を絞りやすい。
実例で比べる
同じ目的でも、書き方で結果が変わります。
改善前
このドキュメントを要約して
改善後
社内の非エンジニア向け勉強会で配る資料を作っています。
以下の技術文書を要約してください。
条件:
- 専門用語が出てきたら、その場で1文の注釈を付ける
- 「なぜそれが必要か」が伝わることを優先し、実装の詳細は省く
- 見出し付きの箇条書き、全体で800字以内
文書:
(ここに本文)
改善後は長いですが、書いているのは相手と目的と条件と形式だけです。一度型を作れば、次からは材料を差し替えるだけで済みます。
曖昧な形容詞は具体的な基準に置き換えてください。簡潔により800字以内、分かりやすくより専門用語に注釈を付ける。モデルは指示を額面どおりに受け取るので、測れる形で書いたほうが確実です。
区切りを明示する
長いプロンプトでは、指示と材料が混ざります。材料の文章の中に「〜してください」という一文があると、それを指示として受け取ってしまう。
防ぐ定番の方法が、XMLに似たタグで囲むことです。Claudeの公式ドキュメントでも推奨されています。
以下のレビュー本文を分類してください。
<レビュー>
配送は早かったが、箱が潰れていた。返品したい。
</レビュー>
<出力形式>
感情: ポジティブ / ネガティブ / 中立
理由: 1文
</出力形式>
区切りの有無で何が変わるかを並べると、次のとおりです。
タグの名前は日本語でも英語でも構いません。大事なのは、どこからどこまでが何なのかが構造として見えることです。
例を1つ見せる
言葉で説明しづらい要求は、例を見せるのが最短です。
次の形式で要約してください。
例:
入力: 弊社は2026年度第1四半期の売上が前年同期比12%増となりました。
出力: 【売上】2026年Q1、前年同期比+12%
では、以下を同じ形式で。
入力: (本文)
例が1つあるだけで、記号の使い方も語調も情報の取捨選択もまとめて伝わります。文章で20行かけて説明するより効きます。
例を出すときは、これは例ですと明示するか、上のようにタグや見出しで区切ってください。例と実際の依頼が地続きになっていると、例の内容まで処理対象だと解釈されることがあります。
プロンプトの育て方
良いプロンプトは一発では書けません。直しながら育てるものです。
| 症状 | 次に試すこと |
|---|---|
| 内容は合っているが形式が違う | 出力形式を具体的に書く、例を1つ見せる |
| 一般論ばかりで浅い | 文脈(相手・目的)を足す、エフォートを上げる |
| 聞いていないことまで書く | 「〜のみを出力してください」と範囲を絞る |
| 前提を間違えている | 材料として前提を明示的に渡す |
| 長すぎる | 字数や項目数を数字で指定する |
会話の途中でもっと短く、その2番目をもう少し詳しく、と伝えて直していける。これがチャット形式の利点です。最初から完璧を目指すより、2〜3往復で仕上げるつもりで始めるほうが早く終わります。
現行モデルで逆効果になる書き方
ここは、少し前の常識が通用しなくなった部分です。
以前のモデルは指示に従いきらないことがあり、その対策として 絶対に、必ず、重要 といった強調を重ねる書き方が広まりました。ところが現行のClaudeは指示への追従性が高く、この手の強調は過剰反応を招きます。
| 避けたい書き方 | 置き換え |
|---|---|
| 「絶対に必ず表を使うこと!」 | 「比較する項目が3つ以上あるときは表にする」 |
| 「〜するな。〜も禁止。〜も避けよ」(禁止の羅列) | してほしいことを肯定形で1〜2行 |
| 「迷ったら検索して」 | 「日付や価格など、変わりうる情報は検索して確認する」 |
| 「手を抜かず徹底的に」 | (削除。指示がなくても丁寧に取り組む) |
書き換えの方向を1枚にすると、次のようになります。
強調をすべて禁じる必要はありません。ただし強調が多いほど、どれが本当に重要なのかが伝わらなくなります。本当に外せない1〜2点に絞ってください。
同じ理由で、長大なプロンプトも見直す価値があります。昔うまくいかなかったから足した一文が積み重なって、いまのモデルには余計な制約になっていることがあります。
判断の基準
細かい技を覚えるより、次の一点を持っておくほうが役に立ちます。
その指示を、事情を知らない優秀な新人に渡して、期待どおりの成果物が返ってくるか。
新人には、背景も判断基準も成果物の形も伝える必要があります。逆に、業界の常識や自明な手順まで細かく指示する必要はありません。この感覚が、そのままプロンプトの塩梅になります。
要点
- プロンプトは文脈、依頼、材料、制約、出力形式の5要素で組み立てる
- 曖昧な形容詞は、字数や条件など測れる基準に置き換える
- 指示と材料はタグで区切り、混ざらないようにする
- 例を1つ見せると、文章での説明より速く正確に伝わる
- 現行モデルでは過度な強調や禁止の羅列が逆効果になるため、肯定形で簡潔に書く
参考資料
- Claude Platform ドキュメント「Prompt engineering overview」 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview — プロンプト設計の基本
- Claude Platform ドキュメント「Use XML tags to structure your prompts」 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/use-xml-tags — タグによる区切りの推奨
- Claude Platform ドキュメント「Claude prompting best practices」 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices — 現行モデル向けの書き方と、過度な強調を避ける指針
- Claude Platform ドキュメント「Effort」 https://platform.claude.com/docs/en/build-with-claude/effort — 回答が浅いときの設定側の対処
シリーズ目次 / 前章: 05. Claudeを使い始める:画面・プラン・準備 / 次章: 07. ClaudeのProjects・Artifacts・メモリ