0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Sonnet 5 になってからメインセッションのコンテキスト消費が減った気がするので、理由を考えてみた

0
Posted at

はじめに

Claude Code のモデルが Sonnet 5 になってから、メインセッションのコンテキスト消費が明らかに緩やかになったという体感があります。以前は「この機能を作って」とお願いすると、作業の途中で油断すると auto-compact が走っている、ということもありました。最近は同一セッションのまま長時間作業できることが増えました。

「なぜ減ったのか」を、自分の仮説と公式発表を突き合わせながら考えてみます。先に書いておくと、公式発表を素直に読むとトークン消費はむしろ増えるはずなので、このギャップ自体が面白いポイントです。

なお、この記事は計測に基づくものではなく、体感ベースの考察です。


環境

  • OS:Windows 11 + WSL2(Ubuntu 22.04)
  • Claude Code:最新版(記事執筆時点)
  • 使用モデル:Claude Sonnet 5(2026年6月30日リリース、Sonnet 4.6 の後継)

体感していること

  • メインセッションのコンテキスト残量の減りが以前より遅い
  • auto-compact に到達するまでの時間が伸びた
  • 結果として、「区切りのいいところでセッションを分ける」判断をする回数が減った

Sonnet 4.6 のころは、機能 1 つの実装が終わる前に auto-compact が走ることも珍しくなく、次のタスクは新しいセッションで始めることが多かったです。Sonnet 5 では、同じセッションで 2〜3 タスク続けても余裕が残っている感覚があります。


仮説:サブエージェントに任せる作業量が増えたから

私の仮説はこれです。

サブエージェントは、メインセッションとは別のコンテキストウィンドウで動きます。ファイルを何十個読もうが、検索を何回走らせようが、その中間結果はサブエージェント側のコンテキストに積まれ、メインセッションに戻ってくるのは最終レポートだけです。つまり、探索・調査系の作業をサブエージェントに委譲する割合が増えれば、メインセッションの消費は自然と減ります。

Sonnet 5 は Anthropic 自身が「最もエージェント的な Sonnet」と表現しているモデルで、公式のマイグレーションガイドにも「Sonnet 4.6 よりデフォルトでエージェント的に振る舞い、ツールや自己検証ループに積極的に手を伸ばす」という趣旨の記述があります。体感でも、以前なら自分でファイルを読みにいっていた場面で、Explore 系のサブエージェントに調査を投げるケースが増えた気がしています。


公式発表と突き合わせると:素朴に読むと消費はむしろ増えるはず

ここが不思議なところで、公式発表には「コンテキスト消費が減る」とは書かれていません。むしろ逆方向の記述があります。

公式情報 コンテキスト消費への影響
新トークナイザ採用。同じテキストが従来比約 1.0〜1.35 倍のトークン数になる 増える
adaptive thinking がデフォルトで有効(thinking 未指定でも思考する) 増える
エージェント的挙動が強化され、ツール呼び出しと自己検証が増える メイン単体なら増える
コンテキストウィンドウは 1M / 最大出力 128K(Sonnet 4.6 から据え置き) 変わらない

実際、独立系ベンチマークの Artificial Analysis は、Intelligence Index の評価において Sonnet 5 が 3 億出力トークンを生成した(同クラスのモデル平均は 7,200 万)として、かなり饒舌なモデルだと指摘しています。つまり、システム全体のトークン消費はおそらく増えているのに、メインセッションのコンテキストだけは減って見えているわけです。

これは矛盾ではなく、「トークンがどこで消費されているか」が変わったと考えると辻褄が合います。増えたぶんの消費はサブエージェント側のコンテキストに逃げていて、メインセッションには要約された結果だけが積まれます。公式発表の数字だけを見ると「消費は増える」と読めますが、Claude Code での体感を説明するには、委譲の増加という構造の変化まで見る必要がありそうです。この点で、体感ベースの仮説のほうが実態に近いのではと思っています。


実はこうかも:モデル以外の要因

とはいえ、モデルの挙動変化だけが原因と言い切るのは早い気もしていて、他にも候補があります。

Claude Code 本体の改善と時期が重なっている説。Claude Code には、古いツール実行結果をコンテキストから除去する context editing や、履歴を要約する compaction といったコンテキスト管理機能があり、これらはモデルとは独立に改善され続けています。実際、公式 changelog を確認すると、Sonnet 5 リリース(6月30日)の翌日にあたる Claude Code 2.1.198(2026年7月1日)で「サブエージェントはデフォルトでバックグラウンド実行になる」という変更が入っていました。モデルのリリースと Claude Code 本体のアップデートはこのくらい時期が重なるので、Claude Code 側の改善をモデルの手柄だと誤認している可能性はあります。

ツール呼び出しが整理された説。Sonnet 5 は指示への追従がより字義通りになり、ファイルも必要な範囲だけ読む・呼び出しをまとめるといった動きが上手くなった印象があります。同じ調査でも、無駄な読み直しが減ればメインセッションの消費は減ります。

単に作業スタイルが変わった説。モデルが賢くなったことで自分のプロンプトが短くなった、手戻りのやり取りが減った、という人間側の変化も混ざっていそうです。

体感の正体は、おそらく「委譲の増加」を主因に、これらが複合したものだと考えています。


おわりに

これまで、大きめのタスクの区切りではセッションを分けたほうが性能がよいとされてきました。コンテキストが埋まった状態のモデルは精度が落ちやすく、要約を書いて新セッションに引き継ぐ、という運用が良かったように思います。

Sonnet 5 + 最近の Claude Code では、コンテキスト消費量を見つつではありますが、今までセッションを分けていた粒度の作業を同一セッションで続けられる場面が増えました。セッション間の文脈引き継ぎは、要約時の情報落ちが必ず発生するポイントだったので、引き継ぎのタイミング自体が減るのは地味に大きい変化だと感じています。

Claude Code 2.1.198 からはサブエージェントがデフォルトでバックグラウンド実行になっており、「メインセッションは薄く長く、重い作業は別コンテキストへ」という方向はさらに進みそうです。引き続き様子を見ながら更新していきます。


参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?