Claude Max 5xでOpusが200Kになる報告 — ヘルプの500Kとの食い違い

統合後のClaudeアプリでMax 5xのOpus 4.6を長く使うと、数往復ごとに自動圧縮が走る。そう報告するissueが、Claude Codeのリポジトリに立っています。ヘルプセンターはチャットのOpus 4.6を500Kと書いており、報告された挙動は200Kのモデルに近い動きです。

先に結論を書くと、食い違いの原因はAnthropicから示されていません。ただしヘルプセンターの表を面ごとに読むと、Opus 4.6が200Kと書かれた列が1つあります。Coworkの列です。

報告されている挙動と測定値

issue #100502は2026年10月8日に立ち、openのままです。タイトルは「統合後のClaudeアプリがMax 5xでOpus 4.6を200Kで動かしている」という趣旨で、ラベルにはbugとregressionが付いています。報告者の条件は次のとおりです。

• プラン: Max 5x、使用クレジット(usage credits)は有効
• 利用面: 統合後のClaudeアプリ(iOSとWindowsデスクトップ)。Claude CodeのCLIではない
• モデル: Opus 4.6
• 使い方: MCPコネクタ1〜2個とプロジェクト指示を入れたプロジェクトで長い会話を続ける

報告者はセッションのトランスクリプトに残るusageの値から、1回のAPI呼び出しで送られたトークン数を測っています。

引き算で確かめると、142,596から92,034を引いて約5.1万です。報告者が「サイクルあたりの余白は約5万」と書いた数字と合います。同じスレッドは、導入前の半年間で圧縮が計60回ほどだったのに、統合後は数メッセージごとに圧縮が走ると書いています。

窓を500Kと仮定すると、固定分を引いた余白は約40.8万です。実際の余白はその8分の1ほどでした。この落差が報告の核心です。

ヘルプセンターの表は面ごとに値が違う

issueは根拠として、ヘルプセンターの「有料プランのコンテキストウィンドウはどれくらいか」という記事の一文を挙げています。チャットではOpus 4.6が全有料プランで500Kという内容です。この記事の表は、チャット・Claude Code・Coworkの3つに分かれています。Opus 4.6とその周辺を並べると、次のようになります。

CoworkでOpus 4.6とSonnet 4.6だけが200Kで、新しいモデルは1Mです。表に載らないモデルは、チャットで200Kという扱いです。

9月16日の発表で、CoworkとチャットはひとつのClaudeに統合されました。Pro・Maxから順に、数週間かけて展開されています。チャット中心の使い方なら、有効にする操作は要らないと案内されています。

ここから先は推測です。統合後のアプリが、Opus 4.6にCoworkの列の値を当てているなら、報告の挙動と表の数字は噛み合います。チャットの列の値で動くはずだという期待と、Coworkの列の値で動いているという観察が、同じアプリの中でぶつかる形です。ただし、アプリがどちらの列を参照するかは、ヘルプセンターにも発表にも書かれていません。

前例: CoworkのOpus 4.6とコンテキストの履歴

issueの報告者は、同じ型の話が春にもあったと指摘しています。いずれもclosedです。

#100502の報告者は、今回の挙動を#36760のフラグの巻き戻しが全会話に及んだものと読んでいます。これは報告者の推理で、Anthropicの説明ではありません。#33154の側からは、1Mを強制すると別の失敗(レート制限)が出るという構図も見えます。窓の広さと制限のバランスを、サーバー側のフラグで調整していた可能性はありますが、確かな根拠はありません。

固定分は何で埋まっているのか

窓の大きさと並んで、報告が突いているのが固定分です。最初の呼び出しだけで92,034トークンあります。issueに追記されたコメントは、別セッションのプロンプトスナップショットから内訳を見積もっています。トークン数は文字数をJSONで約3.2、散文で約3.8で割った概算です。

合計は最初の呼び出しの実測と1割ほどの差で収まる、とコメントは述べています。ウィジェット17個のうち16個(約1.8万トークン)は、一度も使っていない会話でも毎回送られるという指摘です。

もう1つは、スキルの一覧が毎ターン付け足される点です。コメントによると、一覧は1回で約4.7Kトークンあり、48メッセージのセッションで20回注入されていました。累計は約94Kトークンです。コメントはこの2点を、記載どおりの窓を使う案に次ぐ改善案として挙げています。

• スキル一覧は圧縮サイクルごとに1回だけ入れる
• ウィジェットなど中核でないツール定義は、必要になるまで読み込まない

どちらも報告者の見積もりと提案です。実装の実際はissueからは分かりません。

ヘルプセンターの同じ記事にも、関連する注意書きがあります。コネクタやツールは多くのトークンを使うので、有効な数を意識すると使える窓が増える、という内容です。プロジェクト指示も簡潔にとあります。固定分を減らす手は、公式の案内と報告の両方が同じ方向を指しています。MCPのツール定義が窓を圧迫する仕組みは、MCPのツール定義はなぜコンテキストを圧迫するのかで掘り下げています。

自分の環境で窓を確かめる手順

報告が自分の環境にも当てはまるかは、手元で測れます。報告者の方法を借りると、次の流れです。

報告者の環境では、トランスクリプトが~/.claude/projects以下のJSONLに残っていました。次のスクリプトは、その最新ファイルから、呼び出し回数・最初の値・最大値・直近の値を出します。報告者のスクリプトの骨格を短くした形で、アプリが同じ場所に書き出すかはお使いの環境で確かめてください。

python3 - <<'EOF'
import json, glob, os
f = max(glob.glob(os.path.expanduser(
    '~/.claude/projects/*/*.jsonl')), key=os.path.getmtime)
calls = {}
for line in open(f):
    r = json.loads(line)
    if r.get('type') != 'assistant':
        continue
    m = r['message']
    u = m.get('usage') or {}
    n = ((u.get('input_tokens') or 0)
         + (u.get('cache_creation_input_tokens') or 0)
         + (u.get('cache_read_input_tokens') or 0))
    calls[m.get('id')] = max(calls.get(m.get('id'), 0), n)
v = [x for x in calls.values() if x]
print('calls', len(v), '| first', v[0],
      '| max', max(v), '| now', v[-1])
EOF

最大値が圧縮の直前で14万前後に止まるなら、報告と同じ挙動です。40万を超えて伸びるなら、その環境の窓は報告者より広いことになります。Claude Codeのセッションなら、/contextで窓の分母と内訳が直接見えます。/contextの読み方はClaude Codeのコンテキストウィンドウを可視化して中身を確認する方法にまとめています。

窓が狭いときの打ち手

ヘルプセンターの記事には、アプリの窓の広さをユーザーが選ぶ方法が載っていません。手元で動かせるのは次の3つです。

1. Claude Codeに移して使う。ヘルプセンターの表では、Claude CodeのOpus 4.6は1Mです。/model claude-opus-4-6[1m]で選びます。Max・Team・Enterpriseでは、Opus 4.6の1Mはサブスクリプションに含まれます。Proは使用クレジットが必要です
2. 新しいモデルを選ぶ。Coworkの列では、Opus 4.7・4.8・5.5は1Mです。Opus 4.6にこだわる理由がなければ、モデルを切り替えるだけで窓が変わる可能性があります
3. 固定分を減らす。使わないコネクタを外し、プロジェクト指示を短くします

3番目の効果は、報告のコメントが示す内訳から推し量れます。ユーザーの2つのMCPコネクタは約4Kトークンなので、2個を外しても余白は約5万から約5.4万程度にしか増えません。コネクタの数より、ハーネス側の固定分のほうが大きいということです。

Claude Code側で圧縮のタイミングを調整する方法は、Claude Code compactの発火条件と要約後に残る情報で解説しています。1Mの実務的な使い方と費用はClaude 1Mコンテキストの実務活用に、Maxの枠の違いはCoworkのMax 5xとMax 20xの選び方にあります。

圧縮の頻度は会話の質に響く

ヘルプセンターは、自動コンテキスト管理を次のように説明しています。コード実行が有効な有料プランでは、窓の上限に近づくと古いメッセージが要約され、会話が続けられます。長い会話ほど、使用量の上限をより多く消費します。

つまり窓が狭いと、体験の悪化は圧縮の回数に出ます。要約のたびに細部が落ち、使用量の消費も増えます。サイクルあたりの余白が5万なら、1往復で5,000トークン使うなら、圧縮は10往復ほどで来ます。

この報告で言い切れることは2つです。1つ目は、ヘルプセンターの表が面ごとに値を分けており、Opus 4.6だけを見るとチャットが500K、Coworkが200Kと食い違うこと。2つ目は、統合後のアプリがどちらの列に従うかを、公式の資料が書いていないことです。残りの、窓が200Kに戻されたのか、固定分が大きいだけなのかは、issueとヘルプセンターの記述だけでは切り分けられません。切り分けるには、「自分の環境で窓を確かめる手順」のスクリプトで最大値を測る必要があります。

報告が正しければ、実害はプランの価値の読み違いです。Max 5xを選ぶ理由のひとつが「長い会話を圧縮なしで続けられること」だった人にとって、窓の広さは料金ページでは見えない仕様になります。窓の広さが明記されているのはClaude Codeで、長い作業の置き場にする選択肢があります。