プロンプトと出力の制御 — 結局どうすればいいか

12本を統合する。モデル固有の調整は 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 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 望む出力の例を示せ。抽象的な指示よりも効果的である。

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-consistency JSON スキーマへの適合を保証したいなら、以下の prompt engineering の手法ではなく Structured Outputs を使え。

Structured Outputs で足りない場合の5手:

手	中身
出力形式を明示	キー名と値の型まで書く
~~prefill~~	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	誤った論理や前提が露見する
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. **まずはモデルやプロンプトに制約を課さずによく効くプロンプトを作り、レイテンシ削減はその後に試すほうが常に良い。**早すぎる段階でレイテンシを削ろうとすると、最高性能がどのようなものかを知る機会を失いかねない。

手段の優先順:

1. 制約なしで良く効くプロンプトを作る（ここを飛ばすと最高性能が分からない）
2. effort を下げる（対応モデルなら最も効く）
3. モデルを見直す（速度重視なら Haiku 4.5）
4. プロンプトと出力の長さを削る
5. max_tokens で上限を切る（乱暴。冒頭に答えが来るケース向け）
6. ストリーミング（体感の応答性）
7. 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 minimum necessary structure. 最良のプロンプトは、最も長いものでも最も複雑なものでもない。必要最小限の構造で、目的を確実に達成するものである。

9. thinking が入ったときの書き方

thinking が有効なら、prompting の作法が少し変わる。

規則	中身
細かい手順より一般的な指示	「think thoroughly」のほうが、人が書いた step-by-step より良い推論になることが多い
multishot は thinking にも効く	few-shot 例の中で `<thinking>` タグを使うと、そのパターンを一般化する
自己検証させる	`Before you finish, verify your answer against [test criteria].`（ただし Opus 5 では逆効果。model-migration 参照）
thinking オフ時の手動 CoT	`<thinking>` / `<answer>` で分離（Opus 5 では非推奨）

思考の頻度も 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 メッセージへの追記はキャッシュを壊さない。パラメータ変更は壊す。

10. 学習の順序

prompt-eng-interactive-tutorial の9章立ては、そのまま学習順序として使える。

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 部分は現在非対応）
6. Precognition                    段階的思考（今は adaptive thinking）
7. Using Examples                  few-shot
8. Avoiding Hallucinations         接地と「わからない」の許可
9. Building Complex Prompts        実際のユースケースへの組み立て
付録: Chaining / Tool Use / Search & Retrieval

注意: Claude 3 世代前提なので、章5の prefill は現在非対応。読み替えが要る。

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つ目が最も価値が高い。 訂正をその場で終わらせず、次回から不要にする。

ai-docs

エクスプローラー

プロンプトと出力の制御