Message threads（メッセージスレッズ）は、Anthropicが2026年11月2日に公開ベータとして提供開始したMessages APIの新機能で、会話をターン間でサーバー側に保持し、2ターン目以降は新規メッセージと直前のメッセージIDだけを送れるようにする仕組みです。長く走るエージェントの応答開始までの時間を短くします。
室谷代表取締役AnthropicがMessages APIに「Message threads」を出してきたんですよね。これは地味に見えて、エージェント開発者にはかなり効く話です。
テキトー教師DotAI 認定講師そうなんですよ。単に「APIが便利になった」という話じゃなくて、長いセッションを前提にしたエージェント設計の前提が変わる話なんです。
まず何が発表されたかを整理しましょう。
まず何が発表されたかを整理しましょう。
室谷代表取締役Anthropicの公式ブログによると、これはMessages APIで会話をサーバー側にキャッシュする仕組みで、毎ターン全履歴を送り直さなくてよくなる、と。Claude Codeにはすでに統合済みで、500K〜1MトークンのリクエストでTTFT（最初のトークンが返るまでの時間）の中央値が約35%下がったという数字が出ています。
テキトー教師DotAI 認定講師ここで大事なのは「最大35%」ではなく「中央値で約35%」という点なんですよ。資料の表現は median TTFT drop by about 35% ですから、上限の話ではない。
そこは正確に押さえておきたいところです。
そこは正確に押さえておきたいところです。
Message threadsとは？AnthropicがMessages APIで公開ベータ開始
Message threadsと従来のMessages APIの違い
従来のMessages API
- ステートレスな設計
- 毎ターン会話履歴の全部を送信
- 公式ドキュメントに明記された標準的な使い方
Message threads(公開ベータ)
- 会話をサーバー側に保持
- 次回以降は新規分だけを送信
- 会話を数分間保持(ベータ)
- レイテンシが重要な場面向けの追加機能
室谷代表取締役あらためて定義からいくと、Message threadsはAnthropicが2026年11月2日に公開ベータで出したMessages APIの機能で、会話をサーバー側に保持して、次回以降は新規分だけを送れるようにするものです。公式ブログのコピーは「send your conversation once, and the API receives only what's new with every turn」、つまり会話を一度送れば、以降は新しい分だけAPIが受け取る、という言い方になっています。
テキトー教師DotAI 認定講師従来のMessages APIはステートレスで、毎ターン会話履歴の全部を送る設計でした。公式ドキュメントにも「The Messages API is stateless, which means that you always send the full conversational history to the API」と明記されていて、そこにベータとして「With message threads, in beta, the API can keep the conversation for a few minutes, so that each later request sends only the new messages」という一文が加わった形です。
室谷代表取締役既存の設計を壊すものではなくて、ステートレスな使い方はそのまま残る。その上で、レイテンシが重要な場面ではスレッドを使える、という追加なんですよね。
テキトー教師DotAI 認定講師そこは講座でもよく聞かれるところで、受講生さんが「マルチターンのたびに全部送るのが当たり前」と思っている方が多いんです。それが任意で省略できるようになった、というのが今回のポイントです。
Message threadsで何が変わる？TTFT約35%短縮とリクエスト800KB→1.8KB
Message threadsで変わるもの・変わらないもの
変わるもの
- 1リクエストあたりの送信データ量（長い会話で中央値 約800KB → 1.8KB）
- TTFT（500K〜1Mトークンのリクエストで中央値 約35%短縮、Claude Codeでの計測）
変わらないもの
- トークン使用量と課金（Claudeは毎ターン全履歴を読むため、標準のトークン料金のまま）
- レート制限（既存のレート制限が適用）
室谷代表取締役数字の話をしておくと、公式ブログには2つ出ています。ひとつはClaude CodeでMessage threadsがほとんどのユーザーにデフォルトでオンになっていて、500K〜1MトークンのリクエストでTTFTの中央値が約35%下がったというもの。
もうひとつが、長い会話でリクエストの中央値が約800KBから1.8KBになったというものです。
もうひとつが、長い会話でリクエストの中央値が約800KBから1.8KBになったというものです。
テキトー教師DotAI 認定講師800KBから1.8KBですから、送るデータ量としては桁が2つ変わる。これはインパクトが大きいですね。
室谷代表取締役ただ、ここは誤解されやすいので丁寧に言っておきたいんですけど、リクエストが小さくなることと、トークン使用量が減ることは別なんですよ。公式ブログにも「While each request is smaller with message threads, Claude still reads the full conversation on every turn, so token usage stays the same」とあって、Claudeは毎ターン全履歴を読むのでトークン使用量は変わらない。
つまり課金は標準のトークン料金のままです。
つまり課金は標準のトークン料金のままです。
テキトー教師DotAI 認定講師整理するとこうです。
- 変わるもの:1リクエストあたりの送信データ量（長い会話で中央値 約800KB → 1.8KB）
- 変わるもの:TTFT（500K〜1Mトークンのリクエストで中央値 約35%短縮、Claude Codeでの計測）
- 変わらないもの:トークン使用量と課金（標準のトークン料金のまま）
- 変わらないもの:レート制限（既存のレート制限が適用）
室谷代表取締役だから「コストが35%下がる」ではないんですよね。速くなる話であって、安くなる話ではない。
ここを混同すると見積もりを間違えます。
ここを混同すると見積もりを間違えます。
テキトー教師DotAI 認定講師単に安くなる話じゃないんですよ。体感速度とネットワーク転送量の話として捉えるのが正しい理解です。
Message threadsの仕組み——会話をサーバーに保持し新規分だけ送る
Message threadsの仕組みと失効時の流れ
- 01初回リクエスト会話全体を含めて送信し、そこでスレッドが始まる
- 02以降のリクエスト新しいメッセージと直前のレスポンスのIDだけを含める
- 03サーバー側の保持ターン間のスレッドはメモリ上に保持され、暗号化され、ディスクには書かれない
- 04スレッドの失効最後のリクエストから5分で失効する
- 05失効後の再開クライアントが全履歴を再送して新しいスレッドを始める
室谷代表取締役仕組みをもう少し具体的にいくと、最初のリクエストに会話全体を含めて送ると、そこでスレッドが始まる。以降の各リクエストには、新しいメッセージと直前のレスポンスのIDだけを含める、という流れです。
テキトー教師DotAI 認定講師公式ブログでは、ターン間のスレッドはメモリ上に保持され、暗号化されていて、ディスクには書かれないと説明されています。ここはセキュリティの観点でも押さえておきたい記述ですね。
室谷代表取締役で、スレッドには寿命があって、最後のリクエストから5分で失効する。失効したらクライアントが全履歴を再送して新しいスレッドを始める、という設計になっています。
テキトー教師DotAI 認定講師つまり「ずっと残る会話の保存場所」ではないんですよ。あくまでアクティブなセッションのための短命なキャッシュだと。
5分という数字は実装に効いてきますから、講座でもここは強調したいところです。
5分という数字は実装に効いてきますから、講座でもここは強調したいところです。
室谷代表取締役MYUUUでもエージェントを回していて、ツール実行が長引いて次のリクエストまで間が空くケースがあるんですよね。そういう設計だと5分の失効は意識しておかないといけない。
失効後の再送で挙動が変わらないように、クライアント側は全履歴を保持しておく前提で組む必要があります。
失効後の再送で挙動が変わらないように、クライアント側は全履歴を保持しておく前提で組む必要があります。
テキトー教師DotAI 認定講師そこはまさに「サーバーが持ってくれるからクライアントは何も持たなくていい」ではない、という注意点です。フォールバックとして全履歴を再送できる状態を維持しておく。
これは実装上の必須事項だと思います。
これは実装上の必須事項だと思います。
Message threadsの使い方・始め方——threadパラメータとベータヘッダー
室谷代表取締役使い方はシンプルで、Messages APIのリクエストにthreadパラメータを追加し、ベータヘッダーを付ける。最初のリクエストは会話全体を含めてスレッドを開始し、以降は新規メッセージと直前のレスポンスIDだけを含める、という形です。
テキトー教師DotAI 認定講師既存のリクエスト形式を大きく組み替えるものではなく、パラメータとヘッダーの追加で試せる。ここは移行のハードルが低いところですね。
具体的なパラメータの書式やヘッダーの値については、公式ドキュメントを参照するのが確実です。
具体的なパラメータの書式やヘッダーの値については、公式ドキュメントを参照するのが確実です。
室谷代表取締役ドキュメント側では、Message threadsが「Context management」の項目に並んでいて、プロンプトキャッシュやコンテキスト編集と同系統の機能として整理されているんですよね。コンテキスト管理の一手法として読むと位置づけが分かりやすいです。
テキトー教師DotAI 認定講師あわせて、Messages APIの基本をおさらいしておくと、messages配列にroleとcontentを並べて送る形です。roleはuserとassistantが基本で、ドキュメントには過去のターンが必ずしもClaude由来である必要はなく、合成のassistantメッセージを使えるという記述もあります。
室谷代表取締役その基本構造は変わらないので、既存のコードの延長で試せるのがありがたいですよね。Claude Code側の使い方や更新の話はClaude Codeとは？読み方・できること・使い方を完全解説【2026年最新】でもまとめているので、あわせて読むと全体像がつかめます。
テキトー教師DotAI 認定講師実際に手を動かすなら、環境構築のところでつまずく方も多いので、Claude Code npmインストール完全ガイド【2026年最新】：コマンド・非推奨の理由・ネイティブ移行手順までのような手順記事を横に置いておくと進めやすいと思います。
料金と提供範囲——トークン使用量は変わらない？日本から使える？
室谷代表取締役料金と提供範囲は公式に明記されていて、標準のClaudeトークン料金と既存のレート制限が適用されます。提供先はネイティブのClaude Platformに加えて、Claude Platform on AWS、Claude in Microsoft Foundry、Claude Models on Google Cloud（Anthropic管理）です。
テキトー教師DotAI 認定講師クラウド経由の提供も最初からラインナップに入っているのは、エンタープライズで使っているチームには大きいですね。
室谷代表取締役日本から使えるかという点については、提供範囲が上記のプラットフォーム群とされているので、そこから利用する形になります。ただし日本リージョン固有の提供開始日やデータレジデンシーの扱いについては、今回の発表資料では言及されていません。
現時点では明らかにされていない、と正直に書いておくのが正確です。
現時点では明らかにされていない、と正直に書いておくのが正確です。
テキトー教師DotAI 認定講師料金面でもう一点、誤解しやすいところを整理しておきますね。トークン使用量は変わらないので、コスト最適化のための機能ではありません。
あくまでレイテンシ改善の機能です。コストを見たい場合は、モデルごとの単価やプロンプトキャッシュの扱いを別途確認する必要があります。
あくまでレイテンシ改善の機能です。コストを見たい場合は、モデルごとの単価やプロンプトキャッシュの扱いを別途確認する必要があります。
室谷代表取締役そうそう。プロンプトキャッシュはキャッシュヒットの料金が別建てで設定されていますけど、Message threadsはそこを変える話ではないんですよね。
同じトークン料金のまま、送信が軽くなる。
同じトークン料金のまま、送信が軽くなる。
テキトー教師DotAI 認定講師向いているユースケース——コーディングエージェントやcomputer useでの効果
室谷代表取締役公式ブログが挙げている向き先は3つです。1つ目が長く走るコーディングエージェントで、ツール結果やファイル編集のたびに会話が積み上がるケース。
2つ目がcomputer useエージェントで、スクリーンショットが毎ターン再アップロードされずスレッド側に残る。3つ目が文書や画像が多いワークフローで、リクエスト自体が小さくなる、というものです。
2つ目がcomputer useエージェントで、スクリーンショットが毎ターン再アップロードされずスレッド側に残る。3つ目が文書や画像が多いワークフローで、リクエスト自体が小さくなる、というものです。
テキトー教師DotAI 認定講師そして「The more context an agent carries, the more message threads can reduce time to first token」、つまりエージェントが抱えるコンテキストが多いほどTTFTの削減効果が大きい、と明言されています。
室谷代表取締役これは逆に言うと、短いチャットでは効果が小さいということでもあるんですよね。数百リクエストを1セッションで投げるようなエージェントに向いている。
コーディングエージェントがまさにそれで、Claude Codeでデフォルトオンになっているのも納得です。
コーディングエージェントがまさにそれで、Claude Codeでデフォルトオンになっているのも納得です。
テキトー教師DotAI 認定講師computer useの例は分かりやすいですね。スクリーンショットを毎ターン送り直すのは、データ量としても無駄が大きい。
それがスレッドに残るだけで、リクエストの組み立てがかなり素直になります。
それがスレッドに残るだけで、リクエストの組み立てがかなり素直になります。
室谷代表取締役MYUUUでも画像や文書を扱うワークフローがあるので、そこは素直に効きそうだなと。ただ、5分で失効する前提なので、人間の確認を挟むようなワークフローだと失効しやすい。
そこは設計次第です。
そこは設計次第です。
テキトー教師DotAI 認定講師逆に、即応性が重要なアクティブなセッションに向いている、と公式が書いているとおりですね。人間が介在して何分も待つようなフローは、従来どおり全履歴を送る前提で組むほうが安定します。
室谷代表取締役あと、これは資料に書かれている範囲の話ですけど、スレッドはメモリ上に暗号化して保持され、ディスクには書かれない。5分で失効する。
この3点セットで、データの扱いとしては比較的説明しやすい設計になっていると思います。
この3点セットで、データの扱いとしては比較的説明しやすい設計になっていると思います。
テキトー教師DotAI 認定講師社内稟議で「会話はどこに保存されるのか」と聞かれるやつですね。メモリ上、暗号化、ディスクには書かない、最後のリクエストから5分で失効。
この4つを答えられれば、ひとまず説明は成立します。
この4つを答えられれば、ひとまず説明は成立します。
よくある質問
室谷代表取締役ここからは、開発者が気になりそうな点をFAQ形式で整理していきますね。
テキトー教師DotAI 認定講師まず基本のところから。Messages APIのマルチターン会話はどう実装するのか、という点です。
室谷代表取締役従来どおりなら、messages配列にuserとassistantのターンを積んで毎回全部送る形です。Message threadsを使う場合は、最初のリクエストに会話全体とthreadパラメータ、ベータヘッダーを付けてスレッドを開始し、以降は新規メッセージと直前のレスポンスIDだけを送ります。
テキトー教師DotAI 認定講師では、スレッドはいつまで保持されるのか。
室谷代表取締役最後のリクエストから5分で失効します。失効後はクライアントが全履歴を再送して新しいスレッドを開始する形です。
保持中はメモリ上に暗号化して置かれ、ディスクには書かれません。
保持中はメモリ上に暗号化して置かれ、ディスクには書かれません。
テキトー教師DotAI 認定講師料金は安くなるのか、という質問も来そうですね。
室谷代表取締役トークン使用量は変わらないので、料金は標準のトークン料金のままです。安くはなりません。
速くなる機能です。
速くなる機能です。
テキトー教師DotAI 認定講師レート制限は別枠になるのか。
室谷代表取締役既存のレート制限が適用されます。別枠の緩和があるとは資料には書かれていません。
テキトー教師DotAI 認定講師どのモデルでも使えるのか、という点はどうでしょう。
室谷代表取締役今回の発表資料では、モデルごとの対応可否までは明記されていません。現時点では明らかにされていない、というのが正確なところです。
利用時は公式ドキュメントで確認してください。
利用時は公式ドキュメントで確認してください。
テキトー教師DotAI 認定講師Claude Code側で何か設定が要るのか、というのも聞かれそうです。
室谷代表取締役公式ブログによると、Message threadsはほとんどのClaude Codeユーザーでデフォルトでオンになっている、と書かれています。個別の設定方法については今回の資料には記載がないので、そこはドキュメント確認になります。
テキトー教師DotAI 認定講師最後に、既存実装からの移行で気をつける点を整理しておきましょう。
室谷代表取締役クライアント側で全履歴を持ち続ける設計は維持しておくこと。5分の失効に備えて、再送で復帰できるようにしておくこと。
そして、トークン課金は変わらないので、コスト見積もりは据え置きで考えること。この3点ですね。
そして、トークン課金は変わらないので、コスト見積もりは据え置きで考えること。この3点ですね。
テキトー教師DotAI 認定講師まとめると、Message threadsは「会話をサーバーに預けて、送るものを減らして、応答開始を速くする」機能です。長く走るエージェントほど効く、と。
開発チームはまずClaude Codeで体感し、自前のエージェントにthreadパラメータを足して試す、という順番が現実的だと思います。
開発チームはまずClaude Codeで体感し、自前のエージェントにthreadパラメータを足して試す、という順番が現実的だと思います。
室谷代表取締役そうですね。派手な機能ではないですけど、エージェントの設計を考える人ほど効く話なんですよね。
500K〜1Mトークンのセッションを回しているチームは、一度試す価値があります。
500K〜1Mトークンのセッションを回しているチームは、一度試す価値があります。
