powered by TechFeed
表示モード
Anthropic

AnthropicのMessage Threads、長い会話での応答待ち時間を35%短縮 — APIリクエストのたびに全履歴を送り直す問題を大幅に緩和

11月3日、The Decoderが「Anthropic's Message Threads cut time to first token by 35 percent for long conversations」と題した記事を公開した。AnthropicがClaude APIに追加した「Message Threads」機能が、長いコンテキストでの応答開始時間を大幅に短縮するという内容だ。

11月3日、The Decoderが「Anthropic's Message Threads cut time to first token by 35 percent for long conversations」と題した記事を公開した。AnthropicがClaude APIに追加した「Message Threads」機能が、長いコンテキストでの応答開始時間を大幅に短縮するという内容だ。


会話履歴の全送信という根本的な課題

LLMのAPIを使って長期的な会話やエージェントを構築する際、開発者が長らく直面してきた問題のひとつが「会話履歴の全送信」だ。ChatGPTやClaudeのようなLLMは本質的にステートレス(stateless)な設計になっており、前回のやり取りを自分では覚えていない。そのため、会話の文脈を維持するには、開発者がAPIリクエストのたびにそれまでのやり取りをすべてトークンとして送り直す必要がある。

コンテキストが短いうちは問題にならないが、コーディングエージェントや大量ドキュメントを扱うワークフローのように会話が長くなるほど、最初のトークンが返ってくるまでの待ち時間(TTFT: Time to First Token)が顕著に伸びる。ユーザー体験の観点でも、エージェント実行コストの観点でも、見過ごせないボトルネックだった。

AnthropicはこれをMessage Threadsで解決しようとしている。前回のリクエストから変更された部分だけを送信する仕組みに切り替えることで、50万〜100万トークン規模のリクエストにおいてTTFTを約35%削減できるという。

仕組みと設計上の注意点

Message ThreadsはパブリックベータとしてClaude platformで公開されている。スレッドはリクエスト間にわたって、暗号化された状態でメモリ上に保持される。いわば「会話の差分だけを送る」最適化レイヤーをAPI側が担う形だ。

設計上、注意すべき制約が2点ある。

まず、非アクティブ状態が5分続くと自動的に期限切れになる。バッチ処理や非同期的なエージェントループなど、リクエスト間に時間が空くユースケースでは設計に工夫が必要だ。

次に、トークン使用量は変わらない。ClaudeはあくまでもフルコンテキストをRead(読み込み)しているため、課金されるトークン数は従来と同じだ。この機能はあくまでもネットワーク転送コストと待ち時間の削減に特化した最適化であり、コスト削減を期待するならプロンプトキャッシングなど別の手法と組み合わせる必要がある。

恩恵を受けるのはどんなユースケースか

Anthropicは以下のユースケースが最も効果を得やすいと説明している:

  • コーディングエージェント
  • コンピューター操作エージェント(computer-use agents)
  • 大量のドキュメントや画像を処理するワークフロー

いずれも長いコンテキストを繰り返し参照しながらやり取りを続けるタイプの処理だ。エージェント系の開発者にとっては、UXと実行速度の両面で直接的なメリットがある。なお、Anthropicが提供するエージェント構築のベストプラクティスは公式ドキュメントにまとめられており、Message Threadsとあわせて参照するとよいだろう。

対応プラットフォーム

Claude platformのAPIに加え、AWS・Microsoft Azure AI Foundry・Google Cloud経由でも利用可能だ。エンタープライズ環境でマルチクラウド構成を取っている場合でも対応している。大規模なエージェントパイプラインをクラウド基盤上で運用している開発チームにとっては、追加の移行コストなしに恩恵を受けられる点は評価できる。


詳細はAnthropic's Message Threads cut time to first token by 35 percent for long conversationsを参照していただきたい。