Claude Codeを使っていて、妙な違和感がある。
それほど重い処理をしているわけでもないのに、
コンテキストが異様なスピードで削れていく。
1往復ごとに、確実に何かが減っている。
──そんな感覚を持った人は少なくないはずだ。
実際、GitHub Issueでも、
「それほど激しい使い方ではないのに、短時間でクォータを使い切る」という報告が上がっている。
ログを分析すると、原因は単純な“出力の多さ”ではない。
過去のコンテキストを読み返すトークンが、大量に積み上がっていた。
そして気づく。
これは本当に「モデルの問題」なのか？
つまり、この違和感は個人の環境や使い方の問題ではない。
構造として起きている。
違和感の正体 ─ なぜこんなに減るのか
実際のところ、Claude Codeのコンテキスト消費は直感と合わない。
少し長めのコード生成や、数回のやり取りをしただけで、
明らかに「減り方がおかしい」と感じる場面がある。
ここで一度、冷静に考えてみる。
本当にそんなに“重い処理”をしているのか？
単発の質問や軽い修正依頼であれば、
本来そこまで大量のトークンを消費するとは思えない。
にもかかわらず、現実には確実に削られていく。
しかもその減り方は、
・出力が長いから減る
・複雑な推論をしているから減る
といった単純な理由では説明がつかない。
むしろ逆に、
「大したことをしていないのに減る」
という違和感のほうが強い。
ここで気づくべきポイントはひとつ。
消費されているのは、出力ではない。
“見えていない部分”でトークンが使われている。
つまり、問題は「何を出力したか」ではなく、
「何を読み込んでいるか」にある。
Claude Codeが悪いのか？
では、この挙動はClaude Code固有の問題なのか。
結論から言えば、そうではない。
同じような違和感は、他のエージェント型ツールでも起きている。
たとえば、ローカル環境で試したエージェント構成や、
いわゆる「Claude Codeごっこ」のような実装でも、
コンテキストの減り方は明らかに早い。
つまりこれは、特定のモデルやサービスの問題ではない。
もう少し踏み込むと、
・モデルの性能が低いから
・最適化が甘いから
・実装が雑だから
といった話でもない。
むしろ逆で、
“きちんと作られているエージェントほど、この傾向は強く出る”
ここが厄介なポイントだ。
では何が起きているのか。
問題はモデルではなく、
その「使い方」にある。
本質は「エージェント構造」にある
では、その「使い方」とは何か。
答えはシンプルで、エージェントの動きそのものにある。
Claude Codeのようなエージェントは、
単に「質問に答える」ツールではない。
内部では、
- 過去のやり取り（履歴）
- モデルの思考ログ
- ツールの実行結果
- ファイルの状態
といった情報をまとめて扱いながら、次の行動を決めている。
ここまでは問題ない。
問題は、その扱い方にある。
エージェントはこれらの情報を、
“差分”ではなく“全体”として毎回モデルに渡している。
つまり、1回のやり取りごとに
「これまでのすべて」を持って再計算している。
ここが、違和感の正体だ。
見えているやり取りは1往復でも、
内部では巨大な文脈を抱えた処理が繰り返されている。
その結果として、
「大したことをしていないのに減る」
という現象が起きる。
エージェントは「会話」をしているのではない。
毎回「状態の再構築」をしている。
Transformerの宿命と誤解
ここでひとつ、よくある疑問が出てくる。
「そもそもTransformerって、全部のコンテキストを読むものじゃないのか？」
これは半分正しい。
Transformerは、入力されたトークン列をすべて参照しながら処理を行う。
いわゆるSelf-Attentionの仕組みだ。
つまり、
「渡されたものは全部読む」
これは仕様であり、避けることはできない。
では、やはり毎回すべてを読み込むのは宿命なのか。
答えはNOだ。
重要なのはここで、
“全部読むこと”と、“全部渡すこと”は別の話である。
Transformerの宿命はあくまで前者であって、
後者は設計の問題だ。
本来であれば、
- 必要な部分だけを渡す
- 過去の状態を外部に保持する
- 差分だけを処理する
といった構成もあり得る。
しかし現在のエージェントは、
「とりあえず全部渡す」というシンプルな方法を採用している。
結果として、
読むコストではなく、“渡す量”が爆発している。
なお、この負荷を軽減するために、
一定のタイミングでコンテキストを圧縮する「Auto Compact」のような仕組みも用意されている。
しかし体感としては、これが劇的に効いているとは言い難い。
圧縮されたとしても、依然としてまとまった文脈は維持されるため、
次のリクエストでは再びそれを読み込む必要がある。
結果として、
「少し軽くなるが、根本的には変わらない」
という挙動になる。
Cache readの罠 ─ 安いが、無料ではない
では、実際にどこでトークンが消費されているのか。
ここで出てくるのが「Cache read」という存在だ。
エージェントは毎回、過去のコンテキストを参照しながら処理を行う。
その際、すでに処理済みの部分についてはキャッシュが効き、
フルコストではなく「割安なコスト」で読み込まれる。
一見すると、うまく最適化されているように見える。
しかし問題は、その“量”にある。
キャッシュされたコンテキストは、
セッションが長くなるほど増えていく。
そして次のリクエストでは、それをまとめて読み込む。
つまり、
過去が増えるほど、現在の処理コストが上がる
ここで重要なのは、
「安い」ことと「タダである」ことは違う、という点だ。
Cache readは確かに割安だが、
ゼロではない。
そして、それが積み上がる。
最初は気にならないレベルでも、
やり取りが続くにつれて無視できない量になっていく。
結果として、
「なぜか減る」という感覚が、
時間差で効いてくる。
なぜ“爆食い”になるのか
ここまでの話をまとめると、構造はシンプルだ。
エージェントは、
- 過去の履歴
- 思考ログ
- ツールの実行結果
といった情報を抱えながら動作する。
そしてそれらを、毎回まとめてモデルに渡している。
この時点で、すでに土台はできている。
問題は、それが「積み上がる」ことだ。
やり取りが増えるほど履歴は伸び、
ツールを使うほどログは増え、
思考を挟むほど内部情報は肥大化する。
そして次のリクエストでは、そのすべてを再び読み込む。
この構造を式で表すとこうなる。
会話の長さ × ツールの回数 × 思考ログ量 ＝ コンテキスト総量
これがそのまま、次の処理のコストになる。
つまり、
使えば使うほど、次の一手が重くなる。
ここには上限を抑える自然なブレーキが存在しない。
Auto Compactのような圧縮はあるものの、
文脈そのものを抱え続ける設計である以上、
増加の流れは止まらない。
その結果、
最初は軽快に動いていたセッションが、
気づけば重くなり、コストも増えていく。
これが「トークン爆食い」と感じる正体だ。
これは消費ではなく、増幅に近い。
ローカルAIでも同じことが起きている
この問題は、クラウド環境に限った話ではない。
ローカルAIでも、同じ構造がそのまま現れる。
実際に、LM Studioと小型モデル（4Bクラス）で
エージェント的な動きを試してみると、
コンテキストの圧迫はすぐに体感できる。
最初は問題なく動いていても、
やり取りが増えるにつれて、
- 応答が遅くなる
- 文脈を取り違える
- 出力が不安定になる
といった変化が出てくる。
これはモデルの性能が低いからではない。
より正確には、
「限られたコンテキストの中で、過去を抱え込みすぎている」
状態だ。
クラウドではこれが「コスト」として現れるが、
ローカルでは「性能劣化」として現れる。
本質は同じで、
見えていないコンテキストが膨らみ続けている。
つまり、場所が違うだけで、
起きている問題は同一だ。
コストが見えないだけで、問題が消えているわけではない。
なぜCodexに人が流れるのか
こうした構造を踏まえると、
最近の流れも見えてくる。
一部のユーザーが、いわゆる「Codex型」の使い方に戻りつつある理由だ。
Codex型の特徴はシンプルで、
- タスク単位で使う
- 文脈を引きずらない
- 必要な情報だけを都度与える
というスタイルにある。
エージェントのように状態を持ち続けるのではなく、
1回ごとに完結させる設計だ。
一見すると不便に見えるが、
この方式には大きな利点がある。
コンテキストが膨らまない。
その結果、
- コストが予測しやすい
- 挙動が安定する
- 劣化しにくい
といった特徴が出てくる。
ここで重要なのは、
AIの能力が下がったわけではない、という点だ。
むしろ逆で、
「どこまでAIに任せるか」を見直した結果として、
このスタイルに戻ってきている。
つまり、
AIに委ねていた“状態管理”が、人間側に戻っている。
これは退化ではない。
最適化だ。
便利さを削ることで、安定性を取り戻している。
エージェントAIの正体
ここまでの話を踏まえると、
エージェントAIの見え方が変わってくる。
一般には、
「AIが自律的に考えて、作業を進めてくれる存在」
として語られることが多い。
しかし実態は、もう少し現実的だ。
エージェントAIは、
“思考を自動化している”わけではない。
やっていることはむしろ、
「状態管理の外注」
に近い。
本来であれば人間が把握し、
必要に応じて切り出していた文脈を、
すべてAI側に持たせている。
その結果、
- 何を覚えているか
- どこまで参照しているか
- どれだけのコストがかかっているか
といった部分がブラックボックス化する。
そしてその代償が、
トークン消費や性能劣化として表面化する。
つまりエージェントは、
便利さと引き換えに、「見えないコスト」を引き受けている存在だ。
AIは仕事をしているのではない。
文脈を抱え続けているだけだ。
結論
問題はモデルではない。
「全部を毎回渡す」という設計そのものが、
コストを爆発させている。
エージェントは確かに便利だ。
しかしその裏では、
見えないコンテキストが積み上がり続けている。
使えば使うほど、次が重くなる。
この構造が変わらない限り、
トークン消費も、性能劣化も避けられない。
だからこそ今、
「どこまでAIに任せるか」を考えることが、
これまで以上に重要になっている。
便利さには、必ず代償がある。
あとがき
全部AIに任せれば楽になる。
少なくとも、そう思っていた。
実際には逆で、
「どこまで任せるか」を考える仕事が増えただけかもしれない。
エージェントは確かに便利だ。
だが、その便利さは無限ではない。
むしろ、使いどころを間違えると、
静かにコストと負荷を積み上げていく。
だから最近は少しだけ考え方を変えた。
全部やらせるのではなく、
必要なところだけ任せる。
残りは、自分でやる。
結局それが、一番バランスがいい気がしている。
参考リンク
Claude Code usage issue（GitHub）
https://github.com/anthropics/claude-code/issues/45756
