Claude APIが会話の要約を9月14日にベータ公開。長い会話の運用費は下がるのか

2026年9月14日、Anthropic が Messages API に オンデマンドの会話圧縮（compaction） をベータ公開した。これまでは「入力トークンが一定量を超えたら自動で要約する」方式だけだったが、今回の追加で 発注側のシステムが「いつ要約するか」を自分で決められるようになった。

地味な機能追加に見えるが、チャット・問い合わせ対応・エージェント型の自動処理を作る案件では、運用費の計算式そのものが変わる話である。そして、圧縮すれば必ず安くなるわけではない。公式ドキュメントの数字を追うと、むしろ請求が増える使い方がはっきり書かれている。

事実を確認したうえで、見積書のどこを見ればよいかまで整理する。

長く伸びた紙テープの一部が束ねられ、1枚のカードに置き換わっている

公表されている事実

Anthropic の公式ドキュメント（Claude Platform Docs）のリリースノートと機能ページで確認できるものだけを並べる。

項目	内容
公開日	2026年9月14日（ベータ）
機能	会話の一部を要約した「compaction ブロック」を API が返す。以降のリクエストでは、そのブロックを元のメッセージ群の代わりに先頭へ送る
指定方法	ベータヘッダー `compact-2026-09-04` と、トップレベルの `compaction` パラメータ
従来方式	ベータヘッダー `compact-2026-01-12`。入力トークンが閾値（既定 150,000／最小 50,000）に達した時点で自動的に要約する
今回の差分	圧縮のタイミングを呼び出し側が選べる。バックグラウンド実行が可能。要約のあとに直近の数ターンを一字一句そのまま残せる
再利用時の課金	一度作った compaction ブロックを次回以降に使い回す分には、追加の圧縮費用はかからない
制約	要約より前のターンの thinking（推論過程）は引き継がれない。要約が、それ以前の作業について残る唯一の情報になる

対応モデルは Claude Fable 5.1 / Mythos 5.1 / Fable 5 / Mythos 5 / Opus 5 / Opus 4.8 / 4.7 / 4.6 / Sonnet 5 / Sonnet 4.6 で、Claude API のほか AWS・Google Cloud・Microsoft Foundry 経由でも使える。

論点 1. 長い会話の費用は「件数 × 単価」では出ない

まずここが、発注側と受注側で最もずれる。

LLM の API には会話の記憶がない。2 往復目には 1 往復目の全文を、10 往復目には 9 往復分の全文を、毎回まるごと送り直している。 つまり 1 件の問い合わせ対応にかかる入力トークンは、往復回数に比例して増えるのではなく、回数の 2 乗に近い勢いで増える。

具体的に言えば、1 往復あたり 2,000 トークンの会話なら、

3 往復で終わる問い合わせ … 累計の入力はおよそ 12,000 トークン
10 往復かかる問い合わせ … 累計の入力はおよそ 110,000 トークン

往復回数は 3 倍強なのに、入力トークンは 9 倍以上になる。見積書に「問い合わせ 1 件あたり ◯ 円 × 月 5,000 件」と書かれていたら、その「1 件」が何往復を想定した数字なのかを必ず確認する必要がある。この前提が書かれていない運用費の見積もりは、件数が合っていても総額が数倍ずれる。

会話圧縮は、この「履歴が伸び続ける」部分に上限を設ける仕組みである。要約に置き換えた分だけ、以降のリクエストの入力トークンが減る。効くのは 長い会話・長時間動くエージェントであって、1 往復で完結する分類・要約・抽出の処理には関係がない。関連する考え方は AI APIの料金体系と月額の試算方法にまとめている。

論点 2. 要約をつくる呼び出しにも課金される

ここが今回いちばん実務に効く。圧縮は無料の処理ではない。 要約を作るために、それまでの会話全体をもう一度モデルに読ませているからである。

公式ドキュメントは、圧縮が起きたときのトークン内訳の例をそのまま載せている。

内訳	入力トークン	出力トークン
圧縮（要約の生成）	180,000	3,500
本来の応答	23,000	1,000
請求対象の合計	203,000	4,500

合計 207,500 トークン。そのうち 88%（183,500 トークン）は要約を作るために消えている。

さらに注意が必要なのは、API のレスポンスで返る トップレベルの input_tokens / output_tokens には、圧縮分が含まれないことである。上の例では 23,000 / 1,000 しか出てこない。総額を知るには usage.iterations の各項目を足し合わせる必要がある、とドキュメントに明記されている。

これは費用管理の実装バグに直結する。社内のダッシュボードが「トップレベルの usage を合計する」作りになっていると、実際の請求額と乖離する。 運用を伴う案件では、検収項目に次の 1 行を入れておきたい。

費用集計は usage.iterations の全項目を合算していること。圧縮・再試行を含む請求額と、管理画面の表示額が一致することを 1 か月分のデータで確認する。

なお、圧縮を「1 回だけ」やって以降は使い回すなら、この 183,500 トークンは 1 回きりの負担である。損益分岐点は「そのあと何往復続くか」で決まる。 3 往復で終わる会話を圧縮するのは、ほぼ確実に損になる。

論点 3. 「いつ圧縮するか」が設計項目になった

従来の閾値方式（compact-2026-01-12）は、入力が既定 150,000 トークンに達したところで自動的に要約が走る。止められるのは閾値の設定だけで、どの会話のどの瞬間に大きな課金が発生するかを、呼び出し側は選べなかった。

今回のオンデマンド方式では、呼び出し側が圧縮のタイミングを指定する。加えて、

圧縮の呼び出しをバックグラウンドで走らせられる（利用者を待たせない）
要約のあとに直近の数ターンを一字一句そのまま残せる

この 2 点が加わった。応答が数秒止まる問題と、要約で直前のやり取りがぼやける問題が、設計で避けられるようになったということである。

発注側にとっての意味は 1 つ。「圧縮方針」を見積もりの前提として文章にできるようになった。 たとえば「10 往復ごと、または入力 8 万トークン超で圧縮。直近 2 往復は原文保持。圧縮はバックグラウンド実行」と書けば、月額の試算根拠が再現可能になる。逆に、この記述がない運用費の見積もりは、同じ条件で別の会社に出しても比較できない。見積書を横並びにする手順は相見積もりを比較する方法を参照してほしい。

費用にどう効くか

受け取った見積書で確認するのは次の 4 点である。

「1 件あたり」の想定往復数が書かれているか。 書かれていなければ質問する。3 往復想定と 10 往復想定では、入力トークンが 9 倍違う
会話が長くなったときの上限設計があるか。 圧縮・古い履歴の切り捨て・要約の自前実装のいずれか。「特に対策なし」なら、想定より会話が伸びた月に請求が跳ねる
圧縮そのものの費用が試算に入っているか。 入っていない試算は、圧縮が走る会話ほど実績と外れる
費用集計が usage.iterations を合算しているか。 従量精算の契約なら、これは請求の正確さそのものである

3 と 4 は、API 従量分を発注側が実費で持つ契約のときに特に効く。契約型ごとの違いは AI運用費は定額保守か従量精算かに整理してある。

精度の面でも 1 点ある。要約より前の thinking は引き継がれないと公式に書かれている。長い調査や多段の判断を挟むエージェント案件では、圧縮の前後で判断の質が変わりうる。 受け入れテストの条件に「圧縮が 1 回起きたあとの会話でも、◯◯の情報を保持していること」を入れておくと、あとから揉めにくい。

まとめ

2026年9月14日、Messages API に任意のタイミングで会話を要約する機能がベータで追加された（compact-2026-09-04）
長い会話の費用は往復回数の 2 乗に近い勢いで増える。圧縮はそこに上限を設ける仕組みで、短い処理には関係がない
圧縮の呼び出し自体が課金される。 公式の例では 1 回の圧縮で 18 万トークン超。しかもトップレベルの usage には出ない
見積書では「1 件あたりの想定往復数」「長期化時の上限設計」「圧縮費用の計上」「usage.iterations の合算」の 4 点を確認する

手元の見積書がこの前提を書いているかは見積書チェックで機械的に確認できる。これから発注する段階なら、費用診断で条件を整理してから相談に進むと、往復回数のような前提を最初から書面に載せやすい。分野別の相場は費用相場にまとめている。

参考・出典

Claude Platform Docs リリースノート（2026年9月14日／オンデマンド圧縮のベータ公開、ベータヘッダー compact-2026-09-04、バックグラウンド実行、直近ターンの原文保持） https://platform.claude.com/docs/en/release-notes/api
Claude Platform Docs「Compaction」（従来の閾値方式 compact-2026-01-12 の既定値 150,000／最小 50,000、対応モデル、usage.iterations による課金内訳と合算の必要性、再利用時に追加の圧縮費用が発生しないこと、thinking が引き継がれない制約） https://platform.claude.com/docs/en/build-with-claude/compaction

※ 本文中のトークン数は上記公式ドキュメントに記載された例および既定値である。往復回数とトークン量の試算は、1 往復 2,000 トークンという仮定を置いた本サイトの計算で、実際の値は会話の内容・システムプロンプトの長さ・添付の有無で変わる。円換算額は単価改定と為替で動くため示していない。