一行要約
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. まずはモデルやプロンプトに制約を課さずによく効くプロンプトを作り、レイテンシ削減はその後に試すほうが常に良い。早すぎる段階でレイテンシを削ろうとすると、最高性能がどのようなものかを知る機会を失いかねない。
最適化の順序が最大の主張。
要点
2つの指標
| 指標 | 内容 |
|---|---|
| baseline latency | 入出力のトークン毎秒を考慮しない、プロンプト処理から応答生成までの時間。モデルの速さの一般的な目安 |
| TTFT（time to first token） | プロンプト送信から最初のトークンが生成されるまで。ストリーミングを使って応答性を上げたいときに特に重要 |
3つの手段
1. 正しいモデルを選ぶ
For speed-critical applications, Claude Haiku 4.5 offers the fastest response times while maintaining high intelligence. 速度が重要なアプリケーションでは、Claude Haiku 4.5 が高い知性を保ちながら最速の応答時間を提供する。
2. プロンプトと出力の長さを最適化する
- 明確だが簡潔に — ただしClaude はユースケースの文脈を持たないので、指示が不明確だと意図した推論の飛躍をしない
- 短い応答を明示的に求める
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 は単語ではなくトークンで数えるため、正確な語数や語数の上限を指定しても、段落数や文数の上限を指定するほどには効かない。
max_tokensで上限を設ける — ただし文の途中や単語の途中で切れる乱暴な手段。多肢選択や短答のように答えが冒頭に来るケースに向くtemperatureを試す — 低い値（0.2）でより絞られた短い応答になることがある
3. 応答をストリーミングする — 完全な出力を待たずに返し始める。体感の応答性が大きく改善する。
そのまま使える具体例
速度重視の構成:
message = client.messages.create(
model="claude-haiku-4-5",
max_tokens=100,
messages=[
{"role": "user", "content": "Summarize this customer feedback in 2 sentences: [feedback text]"}
],
)長さの指定の仕方（トークン単位で数えるので語数指定は効きにくい）:
❌ Answer in under 50 words.
✅ Answer in two sentences.
✅ Answer in one paragraph.最適化の順序:
1. 制約なしで良く効くプロンプトを作る（ここを飛ばすと最高性能が分からなくなる）
2. モデルを見直す（速度重視なら Haiku 4.5）
3. effort を下げる（対応モデルなら。これが最も効く場合が多い）
4. プロンプトと出力の長さを削る（文/段落単位で指定する）
5. max_tokens で上限を切る（乱暴。冒頭に答えが来るケース向け）
6. ストリーミングする（体感の応答性）原典で言及されている関連文書
- effort — 対応モデルではこれが最も効くレバー（
lowで速度とコストを大きく下げられる） - choosing-a-model — Haiku 4.5 の位置づけ
- claude-prompting-best-practices — 明確で簡潔な指示の書き方
- thinking —
display: "omitted"による TTFT の改善 - prompt-caching — pre-warming による初回のキャッシュミス解消