Claude Code更新、Autoモード長時間セッションの速度低下バグを修正
2026年7月24日 10:25
Claude Codeで長時間にわたるエージェント型ワークフローを実行する開発者は、ターンを重ねるにつれてセッションが線形ではなく二次関数的に遅くなる正規化処理のバグに直面していた。2026年7月20日に配信された「Claude Code v2.1.216」では、この問題が修正された。特に影響が大きいのは、50ターンや100ターンに及ぶAutoモードのセッションを実行する、Claude Codeを積極的に活用している開発者だ。
今回のリリースでは、このパワーユーザーにとって実用上重要な修正に加え、新しい設定項目 sandbox.filesystem.disabled、OAuthトークンの更新が誤った権限拒否として扱われる問題の修正、エージェントセッションの復元に関する改善も導入された。一方、リリース前後の7月16日から22日には少なくとも6件のプラットフォーム障害が発生しており、Claude Codeを日常的な開発基盤として利用する企業チームにとって、サービスの安定性が継続的な課題となっている。
■長時間セッションを停止寸前に追い込んだ二次関数的コスト
Claude Codeは各API呼び出しの前に、会話履歴全体に対してメッセージの正規化処理を実行する。この処理の目的は、リクエストを送信する前にメッセージの形式を標準化することだ。バグはこの処理の実装にあり、計算コストがセッション長に対して線形ではなく二次関数的に増大していた。つまり、セッション長が2倍になると、正規化コストは2倍ではなく4倍になっていた。
実際の影響は、数字で考えると理解しやすい。コンピュータサイエンスの表記では、50ターンのセッションに対して線形アルゴリズム（O(n)）を実行する場合、作業量は50単位となる。これに対して二次時間のアルゴリズム（O(n²)）では、同じセッションでも2,500単位となり、修正後の処理とバグがある処理の間には50倍の差が生じる。
大規模なリファクタリングや複数ファイルの編集で数十ターンを重ねる開発者にとって、この性能低下は急激に進む一方で、原因が見えにくいものだった。エラーも警告も表示されず、各API呼び出しの前に数秒間停止するだけだったため、ネットワーク遅延やシステム負荷と誤認されやすかった。今回の修正では、正規化処理が単一の線形スキャンに再構成され、ターン数の増加に伴う二次関数的な性能悪化が解消された。
この修正が特に重要となるのがAutoモードだ。2026年7月10日にすべてのClaude Codeユーザー向けに一般提供が開始されたこの機能は、各ステップで人間による確認を求めることなくセッションを実行する。バックグラウンドのAI分類器が、保留中のファイル書き込み、シェルコマンド、ネットワーク呼び出しを評価し、処理を続行するかどうかを自律的に判断する。
Autoモードのセッションは、人間が監督する対話型セッションよりも多くのターンを蓄積しやすい。この自律型ワークフローを積極的に活用し、Anthropicが特に利用拡大を図っている開発者ほど、二次関数的な性能低下の影響を強く受けていた。
■sandbox.filesystem.disabledが実際に引き換えにするもの
v2.1.216の変更履歴に記載されている新しい設定 sandbox.filesystem.disabled を使用すると、ネットワークの外向き通信に対する制御を維持したまま、Claude Codeのファイルシステム分離レイヤーを無効化できる。このオプションが何を行い、何を失わせるのかを理解するには、分離レイヤーの仕組みを知る必要がある。
Claude Codeのサンドボックスは、システムレベルでファイル操作を傍受し、実際の書き込みがディスクに到達する前にパスの許可リストと拒否リストを適用する。この仕組みにより、Claude Codeの作業範囲をプロジェクトディレクトリ内に限定し、その外部にある任意のパスへの書き込みを拒否できる。
しかし、一部のビルドツールチェーンは、この傍受メカニズムと競合する。特定の一時ディレクトリのパス、ファイル記述子の動作、シンボリックリンクの解決方法などに依存しており、傍受処理によって正常な動作を妨げられる場合があるためだ。この互換性問題に直面するチームにとって、ファイルシステム分離は保護機能ではなく、ビルドを妨げる要因となっていた。
sandbox.filesystem.disabled は、この問題を回避するための手段である。有効にすると、Claude Codeはプロジェクトディレクトリ外を含め、現在のユーザーがアクセス権を持つ任意のパスに書き込めるようになる。一方、別の仕組みで実装されているネットワークの外向き通信に対する制御は、ファイルシステム分離を無効化しても維持される。
Anthropicのドキュメントは、この設定を推奨されるデフォルトではなく、上級ユーザー向けのオプションと位置づけている。この位置づけは妥当だ。ファイルシステム分離を無効にすると、制約のあるビルド環境との互換性を得る代わりに、重要な安全層を失う。一般的なトラブルシューティングとして無効にするのではなく、互換性に関する具体的な理由がある場合に限って、意図的に有効にするべきだ。
■誤った権限拒否を引き起こしていたOAuthトークン
長時間のClaude Codeセッションを実行するチームにとって、v2.1.216には特に注目すべき修正がある。変更履歴に記載されている、認証エラーが見かけ上の安全上の判断として表示されていた問題だ。
OAuth 2.0のアクセストークンは、長時間のセッション中に有効期限を迎え、更新されることがある。セッションの途中でトークンが更新された際、送信されるAPIリクエストに古いトークンが含まれ、HTTP 401 Unauthorizedレスポンスが返される場合があった。
Claude Code内部のAutoモード分類器は、この401エラーを権限拒否として表示していた。そのため、実際の原因が古い認証情報であるにもかかわらず、Claudeが意図や安全上の理由からコマンドを実行しないと判断したように見えていた。
今回の修正により、トークン更新に伴うイベントは、拒否として分類器に伝わるのではなく、認証処理に送られるようになった。明確な安全上の理由がないまま長時間セッションでClaude Codeがコマンドを拒否していた場合、実際の権限判断ではなく、このバグが原因だった可能性がある。
■誤った権限範囲で再開されていたエージェントセッション
パフォーマンスと認証の修正に加え、v2.1.216では、本番環境のマルチエージェントワークフローに関係する問題にも対処した。セッションをまたいで再開した後、エージェントの権限範囲がどのように復元されるかという問題だ。
再開されたバックグラウンドエージェントのセッションは、元の設定を復元するのではなく、デフォルトのエージェント構成に戻る場合があった。その結果、エージェントに与えられた役割を定義するカスタムプロンプトやツール制限が失われていた。
限定された役割で起動されたサブエージェントが、元の役割に与えられていたものよりも広い権限を持つデフォルトエージェントとして再開される可能性があった。今回の修正により、保存されたセッション状態から再開する際に、エージェントの元のプロンプトとツール制限が復元されるようになった。
範囲を限定したサブエージェントを並行して実行するチームにとって、以前の動作は原因を突き止めにくいリスクだった。サブタスクを専門のエージェントに委任するワークフローでは、こうした構成がよく用いられる。エージェントはコンテキストを保持しているため、同じ状態で処理を継続しているように見える一方、セッションの再開時に権限範囲だけが気付かないうちに拡大していたからだ。
関連するセキュリティ強化では、ワークツリー分離に存在した同様の抜け道も塞がれた。リリースノートによると、分離されたワークツリーで動作するサブエージェントは、以前は --git-dir のようなフラグを渡したり、GIT_DIR や GIT_WORK_TREE といった環境変数を設定したりすることで、Gitの操作先を共有チェックアウトへ変更できた。現在は、こうしたフラグや環境変数による分離の回避が防止されている。
■不安定な週に登場した改善アップデート
v2.1.216の技術的な改善は、2026年7月におけるAnthropicプラットフォームの信頼性という別の課題が目立つ時期に導入された。
StatusGatorとBifrostが追跡したインシデント記録によると、リリース前後の1週間には、少なくとも6件のサービス障害が記録されている。7月16日には、複数のClaudeモデルに影響する3時間26分の大規模障害が発生した。7月17日には3件の個別のインシデントが発生し、最も長いものは約75分間続き、Claude Cowork、Claude API、claude.ai、Claude Codeに影響した。
v2.1.216がリリースされた7月20日には、Opus 4.5でエラー率が上昇するインシデントが発生し、約3時間続いた。7月22日には、claude.aiでのドキュメント作成、Cowork Remote、Claude Code、Claude Code on the Web、Claude Tag、Claude Designに同時に影響する複数サービスの障害が発生した。StatusGatorの追跡によると、7月20日に発生したインシデントのうち1件は、公式には認められなかったという。
Anthropicは以前、障害が続いた背景について、Claude Codeの企業導入や一般ユーザーの登録急増により、需要が利用可能なコンピューティング容量を上回ったためだと説明していた。これは利用拡大に伴う問題ではあるが、Claude Codeを日常のワークフローに組み込んでいるエンジニアリングチームが直面する運用上の現実を変えるものではない。
Claude Codeのように頻繁に更新されるプラットフォームには、リスクが積み重なる可能性がある。v2.1.216の2日後となる7月22日には、v2.1.218がリリースされている。各リリースがリグレッションを引き起こす可能性があるほか、システムプロンプト、ツールの挙動、UIの調整などが次々に変更されることで、個々の変更がツールを改善するものであっても、確立済みのワークフローが中断される可能性がある。
企業利用に向けてClaude Codeを評価しているチームにとって、障害履歴は計画時に考慮すべき要素であり、それだけで導入を断念すべき決定的な理由ではない。適切な考え方は、Anthropic自身のチームがエージェントを大規模に展開するときにも用いている「障害を前提に設計する」というものだ。
APIレベルだけでなくセッションレベルでも停止やエラーを監視し、障害によって出力品質が気付かないうちに低下するのではなく、問題を速やかに検知できるようにする必要がある。
■プラットフォームのバージョン状況とアップデートの目的
2026年7月22日にリリースされたClaude Code v2.1.218が、本記事の公開時点における最新バージョンである。本記事で取り上げたv2.1.216の修正は、v2.1.218およびそれ以降のすべてのリリースに含まれている。アップデートするには、任意のターミナルで claude update を実行する。
二次関数的な性能低下の修正は、Autoモードで長時間セッションを実行する開発者にとって、最も即効性のある変更だ。sandbox.filesystem.disabled は、ビルド環境とファイルシステム分離の互換性に問題を抱えるチームに関係する。OAuthトークン更新の修正は、明確な説明がないまま長時間のワークフローを中断させていた誤った権限拒否を解消する。
エージェントセッション復元の修正は、マルチエージェントワークフローで権限範囲を限定したサブエージェントを使用するチームにとって重要だ。セッション再開時に権限が不適切に拡大する問題は、監査上の不備となっていた。
v2.1.216の変更履歴にある約40項目のうち、そのほかの項目には、シェル解析のエッジケース、VS Codeの表示改善、Prometheusメトリクスとの互換性改善、複数の@メンションおよびセッション選択画面に関するバグ修正が含まれる。Prometheusメトリクスについては、OTELエンドポイントに含まれていた不正な「# UNIT」行が修正された。
■注目ポイントQ&A
●なぜセッションが長くなるほどClaude Codeが遅くなっていたのですか？現在は修正されていますか？
速度低下の原因は、各API呼び出しの前に実行されるメッセージ正規化処理の計算量に関するバグでした。このバグにより、正規化コストはセッション長に対して二次関数的に増大していました。つまり、ターン数が2倍になると、正規化にかかる時間は2倍ではなく4倍になっていました。
50ターンや100ターンに及ぶAutoモードのセッションを実行する開発者にとって、この問題は各API呼び出しの前に数秒間の停止を引き起こし、ネットワークの問題と誤認されやすいものでした。v2.1.216では、正規化処理が線形スキャンに再構成され、セッションが長くなるにつれて性能低下が二次関数的に増幅する問題が解消されました。この修正はv2.1.216以降のすべてのリリースに含まれています。
●sandbox.filesystem.disabledは実際に何を行う設定ですか？使用すべきですか？
v2.1.216のリリースノートに記載されている通り、この設定は、ネットワークの外向き通信に対する制御を有効にしたまま、Claude Codeのファイルシステム分離レイヤーを無効にします。ファイルシステム分離レイヤーは通常、エージェントがアクセスできる範囲を、許可された特定のパスに制限します。
ファイルシステム分離を無効にすると、Claude Codeはプロジェクトディレクトリ外を含め、現在のユーザーがアクセス権を持つ任意のパスに書き込めるようになります。この設定は、分離レイヤーが使用する傍受メカニズムとビルド環境が競合する上級ユーザーを対象としています。大多数の開発者にとって、デフォルトの分離構成は重要な安全層となるため、具体的な互換性上の理由がない限り無効にすべきではありません。
●長時間のセッションで、Claude Codeが明確な理由なくコマンドを拒否していたのはなぜですか？
文書化されている原因の1つは、v2.1.216で修正されたOAuthトークン更新のバグです。セッションの途中でアクセストークンが期限切れになったり更新されたりした際、発生したHTTP 401 Unauthorizedレスポンスが認証処理に送られず、Autoモードの分類器によって権限拒否として表示されていました。
これにより、古い認証情報によるエラーが、Claudeが安全上または意図上の理由から続行しないと判断したかのように見えていました。長時間のセッションで明確な安全上の理由なくClaude Codeがコマンドを拒否した場合、トークンの更新が実際の原因だった可能性があります。今回の修正により、401エラーは意図を判断する分類器ではなく、認証処理に送られるようになりました。
●2026年7月の障害発生状況を踏まえると、Claude Codeは企業の日常的な利用に耐えられる信頼性がありますか？
2026年7月には、1週間に少なくとも6件のインシデントが記録されました。Anthropicは、企業による急速な導入などを背景に、コンピューティング需要が供給を上回ったことが障害の一因だと説明しています。インシデントは実際に発生しましたが、おおむね数時間以内に解消されており、Anthropicのステータスページ（status.claude.com）では、ほぼリアルタイムで状況を確認できます。
企業で導入する場合は、Claude Codeを可用性が保証されたサービスとはみなさず、障害を前提に設計することが標準的な対策となります。Claude Codeに依存するワークフローには、タイムアウト処理とフォールバック動作を組み込む必要があります。また、セッションレベルで監視し、障害を気付きにくい停止として放置するのではなく、観測可能なエラーとして検知できるようにすることが重要です。
元記事: Claude Code Update Kills Quadratic Slowdown That Compounded in Auto Mode’s Longest Sessions