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?

Claude Code v2.1.311の修正、企業運用環境に直結する10件

0
Posted at

深夜の自動実行ログを朝確認すると、「Usage credits required for 1M context」を残してセッションが止まっていた。

200Kトークンを超えた処理が、標準コンテキストでは1Mのコンテキストが必要と判断されて強制終了していた。

v2.1.311でこの挙動が変わった。200K超えのときに止まるのではなく、会話を自動で圧縮して続行するようになった。

リリースノートには「Fixed standard-context sessions stopping with 'Usage credits required for 1M context' when a request ran over 200K tokens; Claude Code now compacts the conversation and continues」とある。

この修正1件だけでも、深夜に無人でClaude Codeを動かしているチームには意味がある。

この記事で分かること:

  • v2.1.311での1Mコンテキストエラーの挙動変更
  • CLAUDE.mdのリスト長が起動時間に影響していた問題の経緯
  • MCP・サブエージェント系でどの動作が変わったか
  • 無人実行・スケジュール実行に関係する修正の概要

対象は、Claude Codeをサブエージェント・MCP連携・SDK/claude -pで使っているエンジニア。

v2.1.311のリリースノートには40件以上の修正が含まれている。

そのすべてを並べるより、「企業での業務利用・自動化環境での無人実行」という観点で選んだ10件に絞って整理する。

起動時のパフォーマンス改善

「CLAUDE.mdに長いリスト項目を入れると、起動後とファイル編集後に長い固まりが発生していた」という修正がある。

(Fixed long freezes at startup and after reading or editing files when a CLAUDE.md file holds a very long list item)

大規模プロジェクトでは、CLAUDE.mdに設定・禁止事項・ペルソナ定義など大量の箇条書きを入れることが多い。

これが数十行〜数百行に及んでいると、起動のたびと大きなファイルを読み書きするたびに数秒の固まりが発生していた。

対処としては、CLAUDE.mdのリスト項目を短くする・項目数を減らす・別ファイルへの参照に切り出すことが有効になる。

「CLAUDE.md要約ファイル(CLAUDE-summary.md)を別に作り、本体の読み込みを減らす」構成は、この修正と組み合わせると起動速度に効く。

また「Improved startup time for Pro and Max accounts by skipping two network requests on launches within an hour of the last check」という改善もある。

Pro/Maxアカウントは、1時間以内に起動済みの場合はチェック用のネットワークリクエストを2件スキップするようになった。

毎時・毎日何度も起動するような運用では、この改善も積み重なる。

コンテキスト上限の挙動変更(企業運用への影響が大きい)

前述のとおり、v2.1.311では「200K超えで止まる」から「圧縮して続行」に変わった。

企業での大規模な処理—数百ファイルを一括でレビューする・大きなコードベースを横断して修正する・長い設計ドキュメントをもとに複数の修正を連続して実行する—では、1ターンで200Kを超えることは珍しくない。

従来はそこで強制終了し、翌朝に「途中で止まっていた」ログを確認するしかなかった。

v2.1.311以降は、圧縮されながらも続行するため、処理の途中止まりが起きにくくなる。

注意:圧縮によって過去の会話内容の一部が失われる可能性がある。
長い処理では、重要な中間状態を明示的なファイルに書き出して残しておく設計が依然として有効だ。
圧縮後にClaude側が「この作業で何をしていたか」を正確に把握できるかどうかは、作業の性質による。

MCP・サブエージェント系の修正(3件)

修正1:接続後のMCPサーバーのツールが使えない問題

「サブエージェントの起動後に接続を完了したMCPサーバーのツールをサブエージェントが使えなかった」問題が直った。

(Fixed subagents being unable to use MCP tools from servers that finish connecting after the subagent starts)

MCPサーバーによっては接続に時間がかかるものがある。

接続完了前にサブエージェントが起動した場合、そのサーバーのツールを使えないまま処理が進んでしまっていた。

v2.1.311からは、接続完了後のサーバーのツールも利用できるようになった。

複数のMCPサーバーを使うフローで、特定のサーバーのツールだけが使えないという問題が起きていた場合、この修正で解消する可能性がある。

修正2:ワークツリーが誤削除される問題

「サブエージェントが開始したバックグラウンドサブエージェントがまだワークツリーで作業中なのに、親サブエージェントの分離ワークツリーが削除されていた」問題も直った。

(Fixed a subagent's isolated worktree being removed while a background subagent it started was still working in it)

並列でサブエージェントを動かしている環境では、この問題が発生するとデータの損失や予期しないエラーにつながっていた。

並列サブエージェントを本番で使っているチームは、このバグを踏んでいた可能性がある。

修正3:/code-reviewが2回実行される問題

「終了した/code-reviewや、サブエージェントで動くスキルが、クラウドセッションやバックグラウンドセッションの再起動時に2回目の実行を始めていた」問題が直った。

(Fixed a finished /code-review, or another skill that runs in a sub-agent, running a second time when a cloud or background session restarts)

コードレビューの重複実行は、結果の整合性と実行コスト両方への影響がある。

無人稼働・スケジュール実行に関係する修正(3件)

修正4:クラッシュ後のセッション再起動

「ターン間でクラッシュしたバックグラウンドセッションが、アタッチ・ピン・スケジュールタスク・ウェイクアップが設定されているときに再起動されなかった」問題が直った。

(Fixed a background session that crashed between turns not being restarted while it was attached, pinned, or had a scheduled task or wake-up set)

スケジュールされたウェイクアップや定期タスクを設定しているセッションが、ターン間のクラッシュで止まったままになっていた。

v2.1.311からは、そのような条件下でもセッションが再起動されるようになった。

修正5:autoモードでの余分なターン生成

「autoモードのバックグラウンドエージェントが自身のシェルを待っているときに、ウェイクするたびに新しいメインの会話ターンが始まっていた」問題も直った。

(Fixed background agents in auto mode that wait on their own shells starting a new main conversation turn on every wake)

autoモードで定期的にウェイクするエージェントが、ウェイクのたびに不要な会話ターンを作っていた。

これは実行コストとセッション状態の両方に影響する。

修正6:SubagentStopフックの重複実行

「終了したSubagentStopフックが、完了時に1回ではなく1分ごとに約2回実行されていた」問題も直った。

(Fixed SubagentStop hooks running about twice a minute for each running subagent instead of once when it finishes)

SubagentStopフックを使っている場合、この修正で不要な重複実行がなくなる。

ファイル操作系の修正

「数千行のファイルを変更したときに、WriteとEditが最大5秒停止して0行変更を報告していた」問題が直った。

(Fixed Write and Edit stalling for up to 5 seconds after they ran, and reporting 0 lines changed, when changing thousands of lines in a file)

大きなファイルへの一括変更を自動化している場合、この遅延は積み重なって無視できない時間になっていた。

また「0行変更」という誤った報告が出ることで、正常に書き込まれたかどうかの確認が難しい状況もあった。

SDK・claude -p ユーザーへの修正

「claude -pおよびSDKセッションが、トランスクリプトメッセージを順序がずれた状態で保存したり、取り消されたメッセージを保持したりしていた」問題が直った。

(Fixed claude -p and SDK sessions saving transcript messages out of order or keeping messages that were taken back)

claude -pを使ったパイプライン処理でトランスクリプトを記録・分析している場合、この修正でログの信頼性が上がる。

取り消されたメッセージが記録に残っていた問題は、セッション再構築や監査ログの精度に直接影響していた。

self-hosted-runnerへの新機能追加

v2.1.311では新機能として、self-hosted-runnerに--hold-idle-fileと--max-hold-minオプションが追加された。

(Added --hold-idle-file and --max-hold-min to self-hosted-runner, to keep an idle session while your host reports processes it left running)

ホスト側が「まだプロセスが残っている」と報告している間、アイドルなセッションを維持できるようになる。

self-hosted-runnerを使っているチームにとって、実行完了後のセッション管理がより細かくコントロールできるようになった。

リリースから見えてきた傾向

v2.1.311は修正件数が多い。v2.1.309・310と比べると、「企業環境の実運用で詰まりやすいポイント」に対応した修正が集まっている印象がある。

特に、コンテキスト上限の自動圧縮・MCP接続後のツール利用・無人実行中のセッション再起動は、大規模な自動化を運用しているチームに直結する変更だ。

UI・小さなバグ・クラウドセッション特有の修正も多く含まれており、全体のリリースサイズはv2.1.309(大型バグ修正リリース)に近い規模になっている。

まだ確認できていないこと

コンテキスト圧縮が「どのタイミングで」「どの程度の量を」圧縮するかについて、公式ドキュメントには詳細が記載されていない。

圧縮が入ったことで、長い処理の後半で「前の決定を忘れた」ような挙動が増える可能性はある。

実際の無人実行環境で200Kを超えるケースが発生したとき、圧縮後の処理が正確に続行されているかを確認するための仕組みを別途設計しておくことが必要かもしれない。

self-hosted-runnerの新オプション(--hold-idle-file・--max-hold-min)の具体的な使い方についても、現時点では公式サンプルが見当たらない。

この記事で取り上げた変更点の出典は、Claude Code公式リリースノートv2.1.311(https://github.com/anthropics/claude-code/releases/tag/v2.1.311 )。

企業でのAI推進やガバナンス対応の背景については、こちらのnoteも参考にしてほしい:https://note.com/light_tern636/n/n89f27dc0a4ab

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?