Claude APIのレイテンシ削減とTTFT計測 — 実装3パターン

Claude APIの応答が遅いと感じたとき、公式ガイドが挙げる打ち手は①適切なモデルを選ぶ②プロンプトと出力のトークン数を削る③ストリーミングで体感速度を上げる、の3つです。加えてレイテンシの計測には「baseline latency」と「Time To First Token(TTFT)」という2つの異なる指標があり、どちらを見ているかで改善の方向性が変わります。

公式ガイドは対策に着手する前の前提として、まず制約なしに動くプロンプトを先に作り、そのうえでレイテンシ対策を試す順序を推奨しています。最初からレイテンシを気にして設計すると、そのタスクで本来出せる最高の精度がどの水準かを見失うためです。

baseline latencyとTTFTの違い

• baseline latency: プロンプトの処理から応答の生成完了までにかかる時間全体を指します。入力・出力のトークン毎秒(tokens per second)を考慮しない、モデル全体の速さのおおまかな目安です。
• Time To First Token(TTFT): プロンプト送信から、最初の1トークンが生成されるまでの時間です。ストリーミングを使うアプリケーションで、ユーザーにどれだけ早く反応が返ってきたと感じさせられるかに直結する指標です。

この2つを混同すると改善の的が外れます。baseline latencyは応答全体の完了までの時間なので、出力トークン数を削れば短縮できます。一方TTFTは最初の1トークンが出るまでの時間なので、出力トークン数を減らしても大きくは変わりません。体感速度を上げたいならTTFT、バッチ処理全体のスループットを上げたいならbaseline latency、と目的に応じて見る指標を分けます。

TTFTを実測するには、ストリーミングレスポンスの最初のイベントが届くまでの時間を計測します。簡易的には、リクエスト送信時刻と最初のcontent_block_deltaイベント受信時刻の差分を取るだけで確認できます。

time curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 1,
    "stream": true,
    "messages": [{"role": "user", "content": "Hello"}]
  }' | head -n 1

max_tokensを極端に小さくしてストリームの最初の1行が届くまでの時間を計れば、baseline latencyを含まない概算のTTFTが取れます。本番計測では、SDKのストリーミングイベントに直接タイムスタンプを打つほうが正確です。

実装1: 適切なモデルを選ぶ

レイテンシを減らす最も直接的な方法は、ユースケースに見合ったモデルを選ぶことです。速度が最優先の用途では、高い知性を保ちながら最速の応答を返すClaude Haiku 4.5が候補になります。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-haiku-4-5",
    "max_tokens": 100,
    "messages": [{"role": "user", "content": "顧客フィードバックを2文で要約してください: [フィードバック本文]"}]
  }'

モデル一覧で比較すると、相対レイテンシはClaude Haiku 4.5が最速、Claude Sonnet 5が高速、Claude Opus 5が中程度、Claude Fable 5.1が最も遅いという序列です(実際の速度はプロンプト長・出力長・thinkingのeffortにも左右されます)。速度と知性のどちらを優先するかは、タスクごとに個別に判断する必要があります。

速度だけを見ればHaiku 4.5一択に見えますが、単価も含めて考えると「速くて安いが精度で妥協するモデル」と「遅くて高いが複雑なタスクを崩れずにこなすモデル」のどちらに寄せるかというトレードオフです。1リクエストあたりのレイテンシ差が数百ミリ秒でも、大量のリクエストを捌くバッチ処理では体感差が積み上がるため、用途がはっきりしているタスクほどモデル選択の効果が大きく出ます。速度と単価のどちらを優先するかで迷う場合は、Claude APIとサブスクの料金比較で単価そのものの考え方も確認しておくと判断しやすくなります。

実装2: プロンプトと出力のトークン数を減らす

処理・生成するトークンが少ないほど応答は速くなります。公式ガイドは以下の具体策を挙げています。

• プロンプトを明確かつ簡潔にする: 不要な詳細や重複した情報を削ります。ただしClaudeはユースケースの文脈を持たないため、指示が曖昧すぎると意図した論理の飛躍をしてくれない点に注意が必要です。
• 簡潔な応答を直接指示する: 冗長な出力が続くなら「簡潔に答えてください」と明示的に頼みます。LLMは単語ではなくトークン単位で数えているため、正確な単語数を指定するより、段落数や文数で上限を指定するほうが効果的です。
• max_tokensで出力の上限を設定する: 生成される応答の最大長にハードリミットをかけられます。

• temperatureを調整する: temperatureパラメータは出力のランダム性を制御します。低い値(例: 0.2)にすると、より焦点の絞られた短い応答になる傾向があり、高い値(例: 0.8)にすると多様だが長くなりがちな出力になります。プロンプトの明確さ・出力品質・トークン数のバランスは、実際に値を変えて試す以外に確実な決め方はありません。

実装3: ストリーミングで体感速度を上げる

ストリーミングは、応答全体が完成する前から生成済みの部分をクライアントへ送り始める機能です。"stream": trueをリクエストに指定するだけで有効になり、ユーザーインターフェース側でトークンが届くたびに順次表示すれば、実際の生成時間は変わらなくても体感の応答速度は大きく改善します。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 1024,
    "stream": true,
    "messages": [{"role": "user", "content": "Hello"}]
  }' | jq -rj 'select(.delta.type? == "text_delta") | .delta.text'

ストリーミングを使う設計では、TTFTがユーザー体験を左右する主指標になります。baseline latencyだけを見ていると、ストリーミング導入の効果が数値に現れず「速くなった実感があるのに指標が変わらない」というズレが起きるので、ストリーミングを入れたらTTFTベースで計測し直す必要があります。ストリーミング出力をコード側でどう組み立てるかはAgent SDKのストリーミング出力を有効にする、ツールと組み合わせて構造化データを流す実装はClaude Codeの構造化出力とストリーミングをツールに組み込むを参考にしてください。

3つの実装をどう組み合わせるか

即効性で言えば、モデル変更(実装1)が最も効果が大きくコストが低い一手です。既存のプロンプトをそのままにモデルIDを差し替えるだけで試せるため、最初に検証する価値があります。次点はストリーミング(実装3)で、実装コストは小さいわりに体感速度の改善が大きく出ます。トークン削減(実装2)は効果測定に時間がかかる反面、baseline latencyそのものを縮める唯一の手段なので、バッチ処理やAPIコストの削減も同時に狙う場合はここに手をかける価値があります。

3つを同時に見直すより、まずモデルとストリーミングだけ変えて効果を測り、それでも足りなければトークン削減とeffort調整に手を広げる、という段階的な進め方のほうが、どの変更がどれだけ効いたのかを切り分けやすくなります。

thinkingのeffortもレイテンシに影響する

モデル比較表の「相対レイテンシ」はデフォルトの挙動を前提にしていますが、実際のレイテンシはthinking(拡張思考)のeffort設定にも大きく左右されます。Claude Opus 5・Claude Sonnet 5・Claude Fable 5.1はデフォルトのeffortがhighで、複雑な問題ほど内部で長く考えてから応答を返す設計です。速度を優先したいタスクでは、effortをlowやmediumに下げることで、モデル自体を変更せずにレイテンシを縮める余地があります。

ただしeffortを下げると、複雑な推論を要するタスクでは回答の質が落ちるトレードオフが発生します。単純な分類・抽出タスクではeffortを下げても品質差が出にくい一方、多段階の計算や込み入った条件分岐を含むタスクでは、モデル選択(実装1)よりもeffort調整のほうが品質への影響が大きく出ることがあるため、両方を独立に検証する価値があります。

Claude Haiku 4.5はeffortパラメータ自体をサポートしていないため、この調整はClaude Opus 5・Claude Sonnet 5・Claude Fable 5.1のようなeffortを持つモデルに限った話です。Haiku 4.5で速度をさらに詰めたい場合は、実装2(トークン削減)と実装3(ストリーミング)の組み合わせに絞って検討することになります。

まとめ

Claude APIのレイテンシ対策は、モデル選択・トークン削減・ストリーミングの3つが基本形です。改善の効果を正しく測るには、応答完了までのbaseline latencyと、最初のトークンが出るまでのTTFTを区別して計測することが前提になります。max_tokensは出力を強制的に打ち切る荒い手段である点、temperatureを下げると出力が短くなる傾向がある点を踏まえて、タスクの性質に合わせて組み合わせを選んでください。