Claude Codeのクォータ削減：エージェントは新たな「レガシーコードの山」を生み出しているのか？

Claude Code の週次クォータ延長が注目を集め、Agent プログラムのトークン消費メカニズムを分析。Agent の長時間実行により、working set が継続的に膨張し、各ステップで履歴状態が蓄積される。また、キャッシュヒット後もコンテキストを占有する特性により、計算コストが累積的に増加する。過剰なクリーンアップは「意味的ページフォールト」を引き起こし、Agent が情報を再取得する必要が生じる。記事は、このコード状態と設計状態の保存精度の不一致が、AI が生成する「伝統的コード」を招く可能性を指摘。後続の Agent が初期コードの設計的因果関係を理解できず、結果として queue、bypass、retry が互いに補完し合う複雑なコードが形成される。

記事執筆者、出典：雷峰網

コードは確かにAgentが書いたものですが、後のAgentは前のAgentがなぜそう書いたのかを知らないのです。

当初定于8月19日结束的Claude Code +50%週額度加成が、Anthropicによって8月31日まで延長された。原定の期限前後には、Hacker News上でClaude Codeの使用コストに関する議論が巻き起こり、多くのユーザーが、それほど複雑でないタスクでも、Agentが数回実行するだけで額度が急速に減ってしまうことに気付いた。

問題は、Claude Code が最後に生成される数行のコードだけでなく、ファイルの読み取り、呼び出しチェーンの検索、テストの実行、ログの処理など、すべてのステップがその後のコンテキストに引き続き影響を与えることです。タスクが長くなるほど、エージェントが抱える履歴が重くなり、システムはクリーンアップと圧縮にますます依存します。

コードはリポジトリに完全に残り続けることができるが、初期の設計理由は圧縮の過程で次第に薄れてしまう。その結果、トークンの消費とコードのスパゲッティが同じ場所で合流し始める。

通常、チャットでのコーディングでは計算の境界が明確です。コードの一部を入力し、モデルが読み取った後、説明または修正案を提示し、この一連の処理は基本的に終了します。

Claude Codeの基本単位はagent loopに変更されました。モデルはまず現在の状態を観察し、次にどのファイルを読み込むか、またはどのコマンドを実行するかを決定します。ツールが結果を返した後、モデルは次の判断を行います。

ソースコードを読み、参照を検索し、テストを実行し、Git diffを確認し、ファイルを変更するという動作は、ユーザー側では一連の連続的な操作に見えますが、モデル側では実際には複数の独立した推論リクエストの列です。Claude Codeの公式ドキュメントでも、「モデルの判断—ツールの呼び出し—結果に基づく継続的な判断」というサイクルをエージェントの動作の中心としています。

例えば、ログイン状態が偶発的に無効になる問題。エージェントはまずエントリーポイントを特定し、状態がサービスから来ていることを発見して、サービスのコードを読み進める。キャッシュを発見した後、誰がそれを書き込んでいるかを検索する。次にテストを実行すると、別の異常が発生したため、fixtureを確認する。修正後、再度検証すると、古いテストが互換性の問題を再び浮き彫りにする。

おそらく、ここでようやくその数行のコードを書き始めたのだろう。したがって、diffのサイズと計算量の間にはほぼ安定した比例関係が存在しない。5行のパッチの背後には3回の推論しかない場合もあれば、30回のツールインタラクションを経ている場合もある。

Agentタスクを分割すると、2つの変数が得られます。1つはステップカウントで、タスクを完了するためにAgentが何ステップ進んだかを示します。もう1つはワーキングセットで、現在のステップに到達した時点で、モデルがどの程度のプロジェクト状態を把握しているかを示します。

ステップ数を増やすだけでも消費が増加します。ワークセットがさらに同期して大きくなり続けると、状況は全く異なります。第3ステップでは数千トークンを処理するだけかもしれませんが、第30ステップでは、プロジェクトのルール、関連ソースコード、テスト結果、変更履歴、およびツールの返答を抱えながら推論を継続している可能性があります。

これはCoding Agentのコスト構造が変化し始めた点でもあります：計算量は書かれたコード行数ではなく、「何ステップ進むか × 1ステップあたりの負荷」に依存するようになりました。

エージェントの1回のモデルリクエストは、大きく3つの部分に分割できる。安定している部分には、system prompt、CLAUDE.md、ツール定義、およびプロジェクトルールが含まれる。変化しやすい部分には、コードファイル、検索結果、テストログ、Git diff、および以前のタスクトラジェクトリが含まれる。最後に、今回のモデル生成によるリーズニング、テキスト、およびコードが含まれる。

ここではよくある誤解があります：以前の内容をすでに読んでいるので、繰り返しコストを発生させるべきではないという考えです。しかし問題は、LLMには従来のプログラムのようにいつでもアクセス可能な内部メモリが存在しないことです。前回のセッションで知っていた情報が、次回の判断にも依存する場合、その状態は引き続き利用可能なコンテキストに含まれている必要があります。

Promptキャッシュはこの問題を軽減できます。Claude Codeの公式ドキュメントでは、promptキャッシュがない場合、各リクエストごとに履歴全体を再処理する必要があることが明確に記載されています。キャッシュがヒットすると、すでに処理された安定したプレフィックスを再利用でき、重複した計算とコストを削減できます。

キャッシュは「同じ履歴をもう少し安価に再利用できるか」を解決するものであり、「その履歴をまだ維持すべきか」を解決していない。100Kトークンの古い状態がキャッシュにヒットして安価になったとしても、それは依然としてコンテキストを占有し、現在の推論がその上に構築されている状態である。

したがって、長いタスクを次のように大まかに表すことができます：ステップ t の入力規模は、安定したプレフィックス S に、現在の有効ワークセット W_t を加え、さらにこのラウンドで生成された新しい情報 Δ_t を加えたものにほぼ等しくなります。

真正麻烦的是 W_t。如果每走一步，Agent 又多读一点源码、多得到一点日志、多留下一个决策，而旧信息没有及时退出，那么 W_t 会随着任务推进不断增加。

極端に簡略化され、キャッシュやクリーンアップが一切ないモデルでは、各ラウンドで追加される有効な状態がほぼ同じである場合、合計処理量は 1 + 2 + 3 + … + n の累積構造に近づきます。つまり、step count が2倍になったとしても、処理された過去の状態全体はそれよりも速く増加する可能性があります。

実際のシステムにはキャッシュ、コンテキスト編集、コンパクションが存在するため、この増加曲線を機械的に従うことはありませんが、問題の形状は変わりません：エージェントの実行時間が長くなるほど、新しいアクションはより重い履歴の上に構築される可能性が高くなります。

したがって、長期間のタスクにおける短いユーザーのプロンプトはすぐに存在感を失う。コストを主導し始めるのは、タスクの連続性を維持するためにモデルが継続的に持ち運ぶワークセットである。

ワーキングセットがなぜこれほど急速に膨張するのか、ツールの出力が大きな要因である。ソースコードには少なくとも構造があるが、ログにはしばしばそれが欠けている。

一次 grep は数百か所の参照を返すことができ、1回のビルドで大量の警告が出力され、1回のテスト失敗で完全なスタックトレースが付いてくることがあります。Docker、コンパイラ、パッケージマネージャーも、タスクに長期的な価値のない大量のテキストを生成します。

ステップ10のテストで8Kトークンのログが生成されたと仮定します。これは最初にコンテキストに導入されたとき、単に8Kトークンです。しかし、エージェントはソースコードの確認、修正、再テストを継続する必要があり、このログが有効な履歴に残っている限り、その後の多くのリクエストの基本重量を増加させます。

これはストレージシステム内のライト増幅に似ています：1回の論理的書き込みが、その後のより多くの底层処理を引き起こします。Agentの状況では、1回のツール出力が実行履歴に書き込まれ、その後の推論と一緒に移動します。

したがって、8Kトークンをタスク終了直前に配置するか、タスク開始時に配置するかで、全体への影響は全く異なります。Claude Codeは現在、この汚染を自発的に削減しています。公式では、高出力タスクをサブエージェントで隔離することを推奨しており、検索結果、ログ、大量のファイルコンテンツがメインセッションのコンテキストを消費することを明確に述べています。ツール定義自体もスペースを消費するため、ツールセットが大きすぎることも状態の負担を増加させます。

しかし、ここには逆の問題が生じます。ログが高価だからといって、すべてを削除することはできません。3000行のログの中には、根本原因に関連するものがわずか20行しかない可能性があります。システムは事前にその20行がどれであるかを知りません。早期にクリーンアップしてしまうと、エージェントが後でその詳細のいずれかを必要とした際に、テストを再実行するかファイルを再開くしかありません。

これはセマンティックページフォールトと呼べます。従来の仮想メモリでは、プログラムがメモリに存在しないページにアクセスすると、システムはディスクから再読み込みします。Coding Agentが早期の証拠を破棄した場合も同様の現象が発生し、リポジトリの再検索、ファイルの再読み込み、コマンドの再実行、あるいはすでに分析済みの問題の再導出という形で現れます。

したがって、長期間のタスクは二難の状況に陥る：歴史をあまりにも多く残すと、以降のステップが次第に重くなる。逆に、あまりにも積極的にクリーンアップすると、エージェントは以前に见过した情報を繰り返し取得してしまう。

これにより、コンテキスト管理を「トークンを少し減らす」ことで簡略化できない理由が説明される。真正に解決すべきは、ワークセットの選択である：今まさにワークエリアに残しておく必要がある情報は何か、そしてどれがすでに使命を果たした中間産物であるか。

ここでようやく、compaction、memory、sub-agent に存在意義が生まれる。

Claude Code はコンテキストの境界に近づくとセッションを自動的に圧縮し、一部の古いツール結果をクリーンアップします。公式でも、長期間のセッションにおける関係のない会話、ファイル内容、コマンド結果がウィンドウを埋め尽くし、モデルのパフォーマンスを妨げる可能性があると注意喚起しています。

システムの観点から見ると、compactionは一見、意味的なガベージコレクションに似ています。問題は、通常のガベージコレクションが「このオブジェクトに参照が残っているか」を判断するのに対し、Agentは「この情報が今後意味を持つのか」を判断しなければならない点です。

後者の方がはるかに難しい。たとえば、初期の設計結論には、あるモジュールはユーザー状態を自分でキャッシュしてはならず、システムは状態に所有者が1つしか許可されず、すべての変更はサービスを経由しなければならないという内容があった。

数十歩進んだ後、この情報が「以前にserviceによる調整で状態の問題が解決されました。」と要約された場合、事実は間違っていないが、情報は変化している。元の内容にはconstraintが含まれていたが、後の要約にはeventのみが保存されている。

次にAgentがパフォーマンスの問題に遭遇し、サービス呼び出しが遅いことに気づいた場合、おそらくモジュールにキャッシュを追加するだろう。それは現在掌握している情報に反していない。当初キャッシュを禁止した因果関係はもはや有効ではないからだ。

Claude Codeのコンテキストドキュメントには、一部のpathスコープルールとネストされたCLAUDE.mdファイルがセッションとともにコンパクション要約され、対応するファイルを再読み取るまで再ロードされないことが明確に記載されています。

Memoryは長期的な知識保存の問題を解決しようとしています。プロジェクトルートディレクトリのCLAUDE.mdとauto memoryは、ビルドコマンド、プロジェクト仕様、デバッグ経験などの内容を短期的な対話から抽出し、セッション開始時に再読み込みできます。しかしAnthropicはその位置づけを明確に記載しています：これらのMemoryは依然としてcontextであり、強制的な設定ではありません。

この違いは非常に重要です。「ここではデータベースに直接アクセスできません」というルールをメモリにだけ記述した場合、それは依然としてモデルが理解し従う必要のある自然言語にすぎません。しかし、同じルールを依存関係のlint、型制約、またはCIチェックとして記述した場合、初めて簡単に回避できないソフトウェアの不変条件になります。

サブエージェントは別の課題、つまりワークセットの隔離を解決します。独立したエージェントがリポジトリをスキャンしたり、長いログを分析し、圧縮された結果をメインエージェントに返すことで、元のノイズがメインスレッドに侵入するのを防げます。Claude Codeの公式なサブエージェントの用途の一つは、コンテキストの隔離です。

その代償も興味深い：メインエージェントはよりクリーンな状態を得たが、一部の元の証拠を失った。複数のエージェントが同時に実行されると、それぞれ独自のコンテキストを構築する。したがって、コンパクション、メモリ、サブエージェントを総合的に見ると、すでにエージェント時代のメモリ階層に非常に似ている。

現在のコンテキストは高価なワークメモリであり、コンパクションは圧縮を担当し、メモリはセッション間の状態を保存し、サブエージェントは独立したアドレス空間でノイズを隔離します。問題は「コンテキストが十分に大きいか」というものから、別のレベルへと移りました：

どの状態を高忠実度で保存し、どの状態を要約のみ残すかという問題は、その後のコード品質に直接影響します。

前の実行構造を理解した後、Claude Code の週間クォータを見ると、プラットフォームが「メッセージ数」でエージェントを計測し続けるのは難しくなることがわかる。なぜなら、1つのメッセージはもはや安定した意味を持たないからである。

変数名を変更するのは1つのメッセージであり、認証モジュール全体をリファクタリングするのも1つのメッセージです。前者は数ステップで完了する可能性がありますが、後者は数十ラウンドを実行し、数十のファイルを読み取り、複数のエージェントを起動する可能性があります。同じリクエストでも、背後で必要なリソースは全く異なる規模になることがあります。

Claude Code では、スクロール制限と週次クレジット枠を導入している；Codex は現在、入力トークン、キャッシュされた入力トークン、出力トークンに基づいてクレジットを換算している；Cursor のプランはエージェントに異なる使用プールを提供し、サードパーティモデルの消費量はモデル API の価格に影響される。

三つの製品のインターフェース言語は異なるが、解決すべき基本的な問題は非常に似ている：実行パスが事前に決定できない知的プログラムに推論リソースをどのように割り当てるか。Coding Agentがどのくらいの時間実行されるかは、タスク開始時には很难確定する。

モデルはすぐに根本原因を特定できる場合もあれば、複数の誤った仮説を繰り返し提示する可能性があります。一度のテストで成功する場合もあれば、長時間のデバッグループに陥る可能性もあります。1つのエージェントで十分な場合もあれば、複数のサブエージェントに分割する必要がある場合もあります。

従来のAPIは、リクエストごとに課金されるのが一般的です。これは、1回のリクエストによるリソースの変動を一定範囲に抑えられるからです。しかし、エージェントはこの安定性を崩しています。そのため、ここではトークンがややCPU時間のような性質を帯び始めています。

この類比は等号で結べません。異なるモデルでは、同じ数のトークンを処理するための計算コストが異なり、入力、キャッシュされた入力、出力にもそれぞれ異なるコストがあります。しかし開発者側から見れば、それらが担う機能は次第に似通ってきています。つまり、タスクを継続するためにどれだけの計算リソースを消費しているかを示しているという点です。

Anthropicは今年、Claude Codeの使用上限を引き上げる際に、クォータの増加と新しいコンピューティング容量の追加を直接関連付けました。これにより、興味深い指標の変化が生じます。これまでCoding Agentを評価する際は、「同じ問題を一度でどれだけうまく書けるか」を比較するのが一般的でした。今後は、同じエンジニアリングの状態変化を達成する際に、どれだけ効率的な計算資源を消費するかがより意味を持つようになるでしょう。

エージェントが大量のトークンを消費して、ファイルの再開、テストの再実行、失われたコンテキストの再復元を繰り返している場合、そのトークンは対応するエンジニアリングの進展をもたらしていません。

このような非効率な状態復元は、ちょうど下層のテクニカルデットとぶつかります。

ここでは、Coding Agent が維持するソフトウェアを、同時に進化する二つの状態に抽象化できます。一つはコード状態 R_tです。ファイル、型、インターフェース、テスト、Git コミットはすべてこの層に属します。Agent が 20 番目のステップで追加した一行の retryは、削除されない限り、100 番目のステップでファイルを開いたときも完全に存在し続けています。コードは過去の変更を非常に高精度で保存します。

もう一つのセットは設計状態 M_tです。なぜここで retryが必要なのか、なぜそのキャッシュはサービスにしか置けないのか、なぜこの状態にオーナーが二つ存在できないのか、なぜ見かけ上余分な判断を暫く削除できないのかという情報は、設計の因果関係に属します。

M_tGitのように自然な損失のないストレージは存在しません。これは、会話、推論、ツールの返答、メモリ、ルールファイル、およびコンパクション要約に分散しています。タスクが進むにつれて、一部の内容は削除され、一部は要約され、一部は再検索が必要になります。

したがって、非常に重要な非対称性が生じます。結果は高忠実度で蓄積されますが、その結果を生み出した因果関係は継続的にダウンサンプリングされます。これは単に「エージェントは物事を忘れる」と言うよりもはるかに深刻です。

並列問題が発生した際、エージェントは分析の結果、キューに追加しました。その時点での完全な結論は、書き込みパスAのみに競合が存在するため、キューはAのみをカバーでき、書き込みパスBは低遅延が必要であり、このキューには含められないということでした。

コードはqueueを完全に保存しました。長時間実行した後、設計状態は「ここでqueueを使ってrace conditionを解決する」だけになっている可能性があります。

その後、B も偶発的なエラーが発生した。Agent はコードを再び読み取る際に、自然に B も既存のキューに追加した。

その後、遅延がさらに増加したため、bypass を追加した。bypass が偶発的な状態不一致を引き起こしたため、周辺に retry を補完した。ここで、いずれの変更も明らかに馬鹿げているわけではない。それぞれのパッチは、その時点での局所的な状況ではむしろ合理的に見えるほどだった。しかしコードは、「明確な並行モデル」から、queue、bypass、retry が互いに補い合う状態へと変化していた。

AIのコードのスパゲッティは、おそらくこのような形で形成される。モデルがいきなりゴミのようなコードを書き出すという形ではなく、局所的に正しい部分が積み重なり、全体のモデルが徐々に消えていくという形で現れる可能性が高い。

従来のソフトウェアでは、このような問題は通常、人員の引継ぎを通じて徐々に形成されます。元の作者が去り、新しい開発者が古いコードを見て、それがなぜ存在するのかを知らず、その外側に互換性のためのロジックをさらに追加します。

Coding Agentは「人員交接」を「コンテキスト交接」に変えてしまった。第20ステップと第100ステップはまだ同じClaude Codeセッションのように見えるが、実際に取得された設計状態はもはや完全には一致していない。情報の観点から見れば、これは二人のエンジニアが次第に短縮されていく交接ドキュメントを通じて同じリポジトリを維持しているようなものである。

テストでもその一部しか解決できません。テストは行動を守ることに優れています：インターフェースは何を返すべきか、特定の入力でクラッシュしてはいけない、過去のバグは再発してはいけません。しかし、多くのアーキテクチャの制約は自然に入出力として現れません。

状態はオーナーを1つしか持てず、ドメイン層はUIに逆依存できず、特定のパッケージはデータベースに直接接続できず、書き込み操作は統一されたトランザクション境界を経由しなければならない。これらの制約がドキュメントやエージェントの記憶にしか存在しない場合、局所的な修正で見過ごされやすくなる。

結果、非常に面倒なエンジニアリング状態が発生します：テストはまだ緑ですが、コードはますます説明しづらくなっています。さらに危険なのは、ここにフィードバックループが存在していることです。

アーキテクチャが混乱し始め、Agentが次に機能を理解するにはより多くのファイルを読み取る必要がある；依存関係が複雑になるほど、ワーキングセットが大きくなる；ワーキングセットが重くなるほど、システムはクリーンアップと圧縮をより必要とする；設計の因果関係が薄いほど、後の変更は現在のコードや局所的なテストに依存しやすくなる。

その結果、コードの複雑さが向上し、トークンコストが増加する。そのトークン圧力は、さらに短い状態保持と局所的なパッチを促す。これがAgentコーディングにおける「繰り返すほど問題が増える」という現象の背後にある、注意すべきメカニズムである。

これは単一のモデル能力の問題ではなく、コード状態と設計状態の保存精度が一致していないシステムの問題です。

Coding Agentはますます長時間動作できるようになっていますが、「数時間走れる」こと自体が必ずしも良い能力指標とは限りません。

エージェントが3時間作業した後、2時間前に修正したファイルを再読み込みし、ある抽象概念がなぜ存在するのかを再推論し、すでに実行済みのテストを再実行する必要がある場合、この3時間のうち相当な部分の計算は状態の復元に費やされている。

次に生じる疑問は、エージェントが50ステップ、100ステップを経た後、その後の意思決定に役立つ因果情報をどれだけ保持し続けられるかということである。

状態忠実度と呼ぶことができます。

これは、コンテキストにどれだけのトークンを詰め込めるかではなく、ツール呼び出し、圧縮、セッション間およびメモリ検索を経た後、どの程度の重要な設計情報が利用可能な形で保持されるかを測定しています。これは、エージェントの長期記憶がより長いコンテキストにのみ依存してはならないことを意味します。

一部の知識はメモリに保存するのが適切です。たとえば、プロジェクトの構築方法や開発習慣などです。一部の意思決定は、構造化されたADRやコードインデックスに記録すべきです。一方、違反するとシステムのアーキテクチャ境界を破壊するようなものは、型、テスト、lint、依存関係ルール、CIに直接記述するのが最適です。

ルールがソフトウェアが実行可能な制約に変換された場合、エージェントはそれを「記憶」する必要はない。次回のエージェントは対話の内容を忘れても、コンパイラやテストを簡単に回避することはできない。

信頼性が低い場合、Agentが長く動作すればするほど、システムにより多くの地雷を仕込むことになります。

これはおそらく、Coding Agent が「コードを書ける」から「ソフトウェアを長期的に保守できる」へと進化するために超えなければならない一線である：設計知識を確率的な言語記憶から、検索可能で検証可能かつ実行可能なソフトウェア状態へと徐々に移行することである。

それ以外に、自主実行時間が長くなるほど、奇妙な状況が生じます。エージェントのコード作成速度はますます速くなり、プロジェクトも急激に変化していますが、一定期間ごとに、それは前の期間に残された世界を再び理解しなければなりません。

伝統的な古くからのコードによくある一文は、「これは触らないで、なぜ動かなくなるのかわからない。」

AIの世代継承コードはさらにひどい可能性がある：コードは確かにAgentが書いたものだが、後のAgentは前のAgentがなぜこのような書き方をしたのかを知らない。