プロンプト設計と出力の制御 — 結局どうすればいいか
15本を統合する。モデル固有の調整は model-migration に分けたので、ここは世代をまたいで残る部分だけを扱う。
1. 始める前の前提
prompt engineering に入る前に持っているべきもの。
- 成功基準が明確に定義されていること
- その基準に対して経験的にテストする手段があること
- 改善したい prompt の初稿があること
If not, spend time establishing that first. —
prompt-engineering-overviewなければ、まずそれを固めることに時間を使え。
そして、すべてを prompt で解こうとしない。
Not every success criteria or failing eval is best solved by prompt engineering. For example, you can sometimes improve latency and cost more easily by selecting a different model.
すべての成功基準や、失敗した eval が、prompt engineering で解決するのが最善とは限らない。たとえば別のモデルを選ぶほうが、レイテンシとコストを容易に改善できる場合がある。
判断の分岐:
| 症状 | 先に見るもの |
|---|---|
| レイテンシ / コストの問題 | モデル選択と effort |
| JSON スキーマへの厳密な準拠 | Structured Outputs（prompt ではない） |
| 必ず守らせたい（Claude Code） | hook（指示ではなく強制） |
| prompt ごとでなく毎セッション効かせたい | CLAUDE.md・skills などの誘導手段に移す（best-practices-for-prompt-engineering） |
| それ以外 | prompt engineering |
2. 中核の4技法
claude-prompting-best-practices と best-practices-for-prompt-engineering が同じ4つを挙げている。
① 明確かつ直接的に
Think of Claude as a brilliant but new employee who lacks context on your norms and workflows.
Claude は優秀ではあるが、あなたの規範や仕事の流れを知らない新入社員だと考えよ。
Golden rule:
Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they’d be confused, Claude will be too.
そのタスクの前提をほとんど知らない同僚にプロンプトを見せ、その通りにやってもらえ。その人が戸惑うなら、Claude も戸惑う。
❌ Create an analytics dashboard
✅ Create an analytics dashboard. Include as many relevant features and interactions
as possible. Go beyond the basics to create a fully-featured implementation.「above and beyond」が欲しいなら、曖昧なプロンプトから推測させずに明示的に要求する。
② 理由を書く
指示の背後にある動機を説明すると、Claude はそこから一般化する。
❌ NEVER use ellipses
✅ Your response will be read aloud by a text-to-speech engine, so never use ellipses
since the text-to-speech engine will not know how to pronounce them.これは最もコスト効率が良い技法。 1文足すだけで、書いていないケースにも対応できる。
③ 具体的に書く
制約・文脈・構造・要件を含める。
❌ Create a meal plan for a Mediterranean diet
✅ Design a Mediterranean diet meal plan for pre-diabetic management. 1,800 calories daily,
emphasis on low glycemic foods. List breakfast, lunch, dinner, and one snack with
complete nutritional breakdowns.④ 例を使う
出力の形式・トーン・構造を steer する最も信頼できる手段。
例の3条件:
- relevant — 実ユースケースに近い
- diverse — edge case を含み、意図しないパターンを学習させない
- structured —
<example>タグで囲む（複数なら<examples>）
3〜5個が推奨。 例そのものの relevance と diversity を Claude に評価させたり、追加生成させたりしてもよい。
Provide examples of your desired output. This is more effective than abstract instructions. —
increase-consistency望む出力の例を示せ。抽象的な指示よりも効果的である。
規則の一覧より目的を渡す（事例）
Anthropic の営業の購入エージェントでは、「顧客の要件を理解し、見込み客を見極め、最適なプランを勧めることが目的」という一文が、見極めの条件をフローチャートで並べるより効き、長さ・複雑さ・構造を変えて試した prompt では短いほど良かった（sales-buying-agent）。
3. 構造化する
XML タグで種類ごとに囲む
指示・文脈・例・変数入力が混在するときに誤読が減る。タグ名はプロンプト間で一貫させる。
ただし「重い XML タグ」は古い技法として名指しされている（best-practices-for-prompt-engineering の「避けるべき間違い」）。混在するときに使うのであって、常用するものではない。
長い文脈（20k トークン超）
| 規則 | 理由 |
|---|---|
| 長い資料を先頭に置く（クエリ・指示・例より上） | クエリを末尾に置くと応答品質が最大30%改善（複数文書で特に） |
複数文書は <document> に <source> と <document_content> | 出所が区別できる |
| 引用で接地させる | 作業の前に関連箇所を引用させる |
4. 出力の形式を制御する
4つの手
- 「するな」ではなく「せよ」で書く
❌ Do not use markdown in your response ✅ Your response should be composed of smoothly flowing prose paragraphs. - XML の書式指示子 —
Write the prose sections in <smoothly_flowing_prose_paragraphs> tags. - プロンプトの文体を出力の文体に合わせる — プロンプトから markdown を減らすと出力の markdown も減る
- 細かい要求は詳細に明示する
一貫性が要るとき
まず判断する:
For guaranteed JSON schema conformance: If you need Claude to always output valid JSON that conforms to a specific schema, use Structured Outputs instead of the prompt engineering techniques below. —
increase-consistencyJSON スキーマへの適合を保証したいなら、以下の prompt engineering の手法ではなく Structured Outputs を使え。
Structured Outputs で足りない場合の5手:
| 手 | 中身 |
|---|---|
| 出力形式を明示 | キー名と値の型まで書く |
| Claude 4.6 以降では非対応。Structured Outputs か system prompt へ | |
| 例で制約 | 抽象的な指示より効く |
| retrieval で接地 | 固定の情報集合に紐づける。使った出典を出力させる |
| prompt chain に分解 | 各サブタスクが Claude の全注意を受ける |
キャラクターを保つなら、system prompt で role を定義し、よくあるシナリオと期待される応答のリストを入れる。これが「キャラクターを崩さずに多様な状況を扱う訓練」になる。
5. hallucination を減らす
中核は2つ。どちらも prompt 1行で効く。
①「わからない」と言う許可を明示的に与える
Explicitly give Claude permission to admit uncertainty. This simple technique can drastically reduce false information.
「わからない」と認めてよいと、Claude に明示的に許可せよ。この単純な手法で誤情報を劇的に減らせる。
If you're unsure about any aspect or if the report lacks necessary information,
say "I don't have enough information to confidently assess this."② 先に逐語引用を抽出させてから作業させる
20k トークンを超える長文書で有効。
1. Extract exact quotes from the policy that are most relevant to GDPR and CCPA compliance.
If you can't find relevant quotes, state "No relevant quotes found."
2. Use the quotes to analyze the compliance of these policy sections, referencing the quotes
by number. Only base your analysis on the extracted quotes.2つの仕掛けが効いている: 引用が見つからない場合の逃げ道と、引用のみに基づけという制約。
③ 生成後に自己検証させて撤回させる
After drafting, review each claim. For each claim, find a direct quote from the documents
that supports it. If you can't find a supporting quote, remove that claim and mark where
it was removed with empty [] brackets.「削除して痕跡を残す」のが巧い。何が落ちたか分かる。
agentic coding での接地
<investigate_before_answering>
Never speculate about code you have not opened. If the user references a specific file,
you MUST read the file before answering.
</investigate_before_answering>発展的な4技法
| 技法 | 何が分かるか |
|---|---|
| chain-of-thought verification | thinking を display: "summarized" で使い、答えがおかしいとき要約された推論を見る。誤った論理や前提が露見しうる（推論を本文に書かせるのではない） |
| best-of-N verification | 出力間の不一致が hallucination の兆候 |
| iterative refinement | 不整合を捕まえて直せる |
| external knowledge restriction | 一般知識ではなく与えた文書だけを使わせる |
while these techniques significantly reduce hallucinations, they don’t eliminate them entirely.
これらの手法は hallucination を大幅に減らすが、完全になくすわけではない。
6. レイテンシを減らす
順序が最も重要な主張。
It’s always better to first engineer a prompt that works well without model or prompt constraints, and then try latency reduction strategies afterward. Trying to reduce latency prematurely might prevent you from discovering what top performance looks like.
まずはモデルやプロンプトに制約を課さずによく効くプロンプトを作り、レイテンシ削減はその後に試すほうが常に良い。早すぎる段階でレイテンシを削ろうとすると、最高性能がどのようなものかを知る機会を失いかねない。
手段の優先順:
- 制約なしで良く効くプロンプトを作る（ここを飛ばすと最高性能が分からない）
effortを下げる（対応モデルなら最も効く）- モデルを見直す（速度重視なら Haiku 4.5）
- プロンプトと出力の長さを削る
max_tokensで上限を切る（乱暴。冒頭に答えが来るケース向け）- ストリーミング（体感の応答性）
display: "omitted"（thinking を返さず TTFT を短縮。コストは変わらない）
長さの指定の仕方に注意:
Because of how LLMs count tokens instead of words, asking for an exact word count or a word count limit is not as effective a strategy as asking for paragraph or sentence count limits.
LLM は単語ではなくトークンで数えるため、正確な語数や語数の上限を指定しても、段落数や文数の上限を指定するほどには効かない。
❌ Answer in under 50 words.
✅ Answer in two sentences.7. トラブルシューティング表
best-practices-for-prompt-engineering の表が実用的。症状から引く。
| 問題 | 対処 |
|---|---|
| 出力が一般的すぎる | 具体性を足す、例を足す、網羅的な出力を要求する |
| 話が逸れる | 実際の目的を明示する、文脈を与える |
| 形式が一貫しない | few-shot 例を足す（prefill は 4.6+ で不可） |
| タスクが複雑すぎる | 複数のプロンプトに分割する（chaining） |
| 不要な前置きが付く | 直接答えるよう明示的に要求する。漏れたら後処理 |
| hallucination | 「わからない」と言う許可を明示的に与える |
| 頼んでいない提案が来る | 行動について明示する（“Suggest changes” ではなく “Change this”） |
| ツールを使ってくれない | なぜ・どう使うべきかを明確に記述する |
| 推論が浅い | prompt で回避せず effort を上げる |
8. 避けるべき間違い
best-practices-for-prompt-engineering の列挙。
- 不要な複雑さによる過剰設計
- 発展的な技法を追って基本を無視する
- AI が心を読むと仮定する
- すべての技法を同時に使う
- 反復と洗練を飛ばす
- 古くなった技法に頼る（重い XML タグ、role prompting）
The best prompt isn’t the longest or most complex. It’s the one that achieves your goals reliably with the minimum necessary structure.
最良のプロンプトは、最も長いものでも最も複雑なものでもない。必要最小限の構造で、目的を確実に達成するものである。
禁止すると別の既定に落ちる
improving-frontend-design-through-skills が、§8 の「避けるべき間違い」に一つ足す形の指摘をしている。禁止リストは新しい既定を作る。
Even with explicit instructions to avoid certain patterns, the model can default to other common choices (like Space Grotesk for typography). The final reminder to “think outside the box” reinforces creative variation. —
improving-frontend-design-through-skills特定のパターンを避けよと明示的に指示しても、モデルは他のありふれた選択（typography なら Space Grotesk など）に既定で落ちうる。最後の「枠の外で考えよ」という念押しが創造的な変化を補強する。
背景にあるのは分布収束で、訓練データを支配する「安全で誰も不快にさせない選択」に寄る性質。だから「A を使うな」だけでは B に集まるだけで、発散そのものを促す一文が要る。
同じ原典が、指示を書く高度についても具体的な線を引いている。
prompting the model at the right altitude, avoiding the two extremes of low-altitude hardcoded logic like specifying exact hex codes and vague high-altitude guidance that assumes shared context —
improving-frontend-design-through-skills正しい高度でモデルに prompt する。厳密な hex 値を指定するような低空のハードコードされた論理と、共有された文脈を前提とする曖昧な高空の指針という、2つの極端を避ける。
効かせ方の核は、美的な要求を実装できる次元（typography / 色 / モーション / 背景）に割ることで、いずれも Claude が書けるコードに直結する。
9. thinking が入ったときの書き方
thinking が有効なら、prompting の作法が少し変わる。
| 規則 | 中身 |
|---|---|
| 細かい手順より一般的な指示 | 「think thoroughly」のほうが、人が書いた step-by-step より良い推論になることが多い（claude-prompting-best-practices） |
| multishot は thinking にも効く | prompt 内の解き方の例が、Claude が自分の thinking ブロックで似た問題にどう取り組むかを形づくる。各例は「問題・方法・期待する答え」で示す |
| 自己検証させる | Before you finish, verify your answer against [test criteria].（ただし Opus 5 では逆効果。model-migration 参照） |
| thinking オフ時の手動 CoT | 答える前に考え抜かせ、最終的な答えを <answer> タグに入れさせる。Fable 5.1 / Fable 5 / Opus 5.5 / Opus 5 / Sonnet 5.5 では thinking に頼る —— 推論を書き出させる prompt（<thinking> タグなど）は断られうる |
思考の頻度も promptable:
減らす:
Thinking adds latency and should only be used when it will meaningfully improve
answer quality - typically for problems that require multistep reasoning.
When in doubt, respond directly.増やす:
This task involves multistep reasoning. Think carefully before responding.ただし順序がある。
If you want Claude to think less often, lower the effort level before reaching for prompt-based steering.
Claude が考える頻度を下げたいなら、プロンプトによる誘導に手を伸ばす前に effort レベルを下げよ。
per-message steering の利点: 最新の user メッセージへの追記はキャッシュを壊さない。パラメータ変更は壊す。
推論の要るタスクで JSON を返させる
Sonnet 5.5 では、structured outputs では応答が JSON だけなので、考える場所は thinking しかない。adaptive で system prompt の最後に Think the problem through before you answer. を足すか xhigh にする。structured outputs が使えないなら、応答の最後の JSON 値を取る（最初の { から最後の } までを取ると、下書きの JSON まで含む）。stop_reason が "max_tokens" の応答は、JSON として正しくても失敗として扱う（prompting-claude-sonnet-5-5）。
10. 学習の順序
prompt-eng-interactive-tutorial の9章立ては学習順序として使えるが、Claude 3 世代向けに書かれており、Prompting best practices と食い違うところは後者に従う（prompt-engineering-overview）。
| 章 | 扱うもの |
|---|---|
| 1. Basic Prompt Structure | プロンプトの骨格 |
| 2. Being Clear and Direct | 曖昧さを消す |
| 3. Assigning Roles | system prompt での role |
| 4. Separating Data from Instructions | XML タグによる分離 |
| 5. Formatting Output | 出力形式の制御（prefill 部分は Claude 4.6 以降で非対応） |
| 6. Precognition | 段階的思考。推論を書き出させる形は、Fable 5.1 / Fable 5 / Opus 5.5 / Opus 5 / Sonnet 5.5 では断られうる —— thinking に任せる（§9） |
| 7. Using Examples | few-shot |
| 8. Avoiding Hallucinations | 接地と「わからない」の許可 |
| 9. Building Complex Prompts | 実際のユースケースへの組み立て |
| 付録 | Chaining / Tool Use / Search & Retrieval |
注意: Claude 3 世代前提なので、章5の prefill は Claude 4.6 以降で非対応、章6の書き出す推論は上の5モデルで断られうる。読み替えが要る。
11. 手順にまとめる
書く前
- 成功基準を定義したか（SMART）
- 経験的にテストする手段があるか
- prompt で解くべき問題か（モデル / effort / Structured Outputs / hook ではないか）
書く
- 文脈の乏しい新入社員に説明するつもりで書いたか
- 「なぜ」を書いたか（一般化してくれる）
- 具体的か（制約・文脈・構造・要件）
- 例を 3〜5個、edge case 込みで入れたか
- 「するな」ではなく「せよ」で書いたか
- 長い資料を先頭に置いたか（20k超）
品質を上げる
- 「わからない」と言う許可を与えたか
- 長文書なら引用を先に抽出させたか
- 一貫性が要るなら Structured Outputs で足りないか確認したか
速くする（プロンプトが固まってから）
effortを下げられるか- 長さは「文/段落」で指定したか（語数ではなく）
- ストリーミングしているか
見直す
- 技法を全部盛りしていないか
- 古い技法（重い XML、role prompting）に頼っていないか
- モデル世代が変わったら model-migration を確認
12. コピペできるプロンプト集
prompt-library に Claude Code 用の 52件が SDLC フェーズ（discover / design / build / ship / operate）別にある。型として読むと4つに集約される。
| 型 | 形 |
|---|---|
| 読んで → 書き出す | read {input} and write up ... |
| 実装して → 検証する | implement the fix, and run the tests |
| 既存を学んでから作る | look at how {example} is implemented, then build {new} the same way |
| 訂正を仕組みに変える | you keep {mistake}. add a rule to CLAUDE.md so this stops happening |
4つ目が最も価値が高い。 訂正をその場で終わらせず、次回から不要にする。