Claude Codeで長いタスクを始める前に：compactのタイミングと、サブエージェント・使用量の管理

Claude Codeにコードの読み取り、修正、テストを続けて任せるとき、慌ててコンテキストを消す必要はありません。かといって、「1Mを使い切る」ためだけに過去の議論をすべて残しておく必要もありません。

先に考えたいのは、次の作業に元の情報のどの部分が必要なのか、委任する仕事は独立して完了できるのか、そしてタスクが終わったとき、単に使用量の数字が小さくなっただけではなく、本当に改善したと何をもって判断するかです。

9月19日、ZryMillerは自分のやり方を変えたと投稿しました。以前は頻繁にcompactしていたものの、自分が「デフォルト」と呼ぶ1Mのウィンドウに戻したところ、使い勝手が大きく改善したと感じ、初めてのアプリの公開を準備していると述べています。ただし、その投稿には比較可能なタスク、変更前後の使用量、アプリが最終的に公開された結果はありません。参考になる個人の体験談ですが、「圧縮しなければ、あらゆる長いタスクがうまくいく」とは結論づけられません。

「頻繁に圧縮する」か「一切圧縮しない」かを選ぶのではなく、具体的な作業の区切りで判断しましょう。

まず、何を使っているかを確認する

ターミナルでclaude --versionを実行し、クライアントのバージョンを記録します。セッションに入ったら、/statusでアカウントと現在のモデル、/modelで選択可能なモデルと関連設定、/contextでコンテキストの使用状況を確認します。使用量を見たいときは/usageを実行します。これらはそれぞれ別の情報を見るためのコマンドであり、同じ指標ではありません。公式コマンドリファレンス · 使用量の説明

今回の議論に登場するモデルの正式名称はClaude Fable 5.1で、Claude APIのモデルIDはclaude-fable-5-1です。公式仕様ではコンテキストウィンドウが1Mトークンとされています。モデル、Claude Codeのバージョン、effort設定は別々の項目です。「Fableを使った」「Ultraを使った」だけで記録を済ませないようにしましょう。モデルの公式仕様

ただし、モデルが1Mに対応しているからといって、すべてのアカウント、モデル、接続方法で同じ利用条件になるわけではありません。たとえば公式ドキュメントでは、Opusの1MはMax、Team、Enterpriseに含まれる一方、Proではusage creditsが必要と区別されています。サブスクリプションでSonnet 4.6の1Mを利用する場合にもusage creditsが必要です。これらの条件をそのまま別のモデルに当てはめないでください。クライアントの設定、モデルのマッピング、ゲートウェイ側の対応も確認が必要です。選択欄で[1m]を付け加えても、サーバー側のモデルの能力が自動的に拡張されるわけではありません。1Mの利用条件とモデル設定

混同しやすい3つの数字も分けて考える必要があります。コンテキスト使用量は、現在のリクエストに収める必要がある情報量です。累積トークン使用量は、各リクエストが処理した入力、出力、キャッシュされた内容の量を記録したものです。サブスクリプションの利用枠は、該当する利用期間内のアカウントの上限です。5時間や1週間というのは利用枠の期間であり、タスクが5時間や1週間、連続して動き続けられる保証ではありません。キャッシュにヒットした内容もコンテキスト内の場所を使いますが、APIの課金では別のキャッシュ料金が適用される場合があります。したがって、「コンテキストを30%使った」を「5時間枠を30%使った」に換算することはできません。1Mも、無料で何度も処理できるトークンの割り当てではありません。コンテキストとキャッシュ · APIの料金体系

compactする前に、次の作業に何が必要かを見る

フロントエンド、API、データベースをまたぐ不具合を調べているとします。読み終えたばかりのコード断片、失敗したリクエスト、ある境界条件から、まだ検証可能な結論は出ていません。この時点で「チャットが長くなったから」という理由だけで圧縮すると、次に照合するために必要な細部を失うかもしれません。

一方、原因が明確になり、関連ファイルと根拠の場所が記録され、合意済みの方針に沿って実装を少し直すだけなら、それまでの大量の検索過程を現在のウィンドウに残す必要はないかもしれません。

圧縮に適したタイミングは、一律の使用率ではなく、ひとつの段階が終わり、信頼できる記録から続行できる状態になったときです。 これは作業の進め方としての提案であって、モデルの固定しきい値ではありません。

まず、指定したタスク記録に必要な状態をClaudeに書き出してもらいます。確認済みの事実と根拠の場所、実際に変更したファイル、実行したチェックとその実際の結果、未解決事項、次の作業です。会話全体をコピーする必要はありません。未検証の推測を結論として残すことも避けます。

そのうえで、残したい内容を明示して標準の/compactを使えます。圧縮の仕組み

/compact 現在の目標、確認済みの結論と根拠の場所、変更したファイル、実行したチェックとその実際の結果、未解決事項、次の作業を残してください。重複した検索や、すでに除外した可能性についての議論は削除してください。

これは要約に対する指示であり、「情報が失われない」という保証ではありません。修正を続ける前に、圧縮後のコンテキストをもとに次の作業を説明してもらい、主要な制約を実際のファイルやタスク記録と照合します。境界条件が抜けていたら先に戻し、実装がずれてから手直しすることにならないようにします。

次の仕事が別の無関係なタスクなら、現在の成果と引き継ぎ情報を保存し、/clearで新しいセッションを始めるほうが通常は単純です。元の会話に戻る必要があれば/resumeを使います。セッションを消しても、すでに発生した使用量は戻らず、サブスクリプションの利用枠もリセットされません。セッションのコマンド · 使用量表示でリセットされる範囲

Claude Codeにはもともと自動圧縮があるため、この方法を試すためにプラグインを入れる必要はありません。v2.1.221以降では/autocompactも使えます。引数なしなら現在の自動圧縮ウィンドウを表示し、/autocompact autoならモデル向けに調整されたウィンドウ設定に戻します。後者は設定を保存する操作であって、単にモデルに好みを伝えるものではありません。モデルの最大ウィンドウと自動圧縮ウィンドウも別の概念です。自動圧縮コマンド

HKTECH_AIは、1回のcompactで5時間枠の約15%を使う可能性があると見積もっていました。ただし、投稿には請求明細も計算方法もなく、この割合を運用ルールにはできません。比較すべきなのは、圧縮によって後続のリクエストに繰り返し持ち込む内容が減ったか、その代わりに読み直し、説明のやり直し、修正が発生しなかったかです。

サブエージェントで分担するなら、「一度にひとつ」をどう実現するかを区別する

SHCHは、Fableが計画と判断を担い、SonnetのScoutが検索し、OpusのBuilderが明確なタスクを実行する構成を紹介しました。その際、一度に呼び出すサブエージェントはひとつにするよう、特に注意しています。

公開されたBuilderの画像では、既存の計画に従うこと、計画に問題があれば停止して報告すること、さらにサブエージェントを起動しないこと、チェック結果を報告することが強調されています。こうした指示には、責任範囲を明確にする価値があります。ただし、画像内の「さらにサブエージェントを起動しない」はあくまでプロンプト上の制約であり、ソフトウェアが強制する上限ではありません。投稿者は複数のメインセッションを動かすことにも言及しており、検証可能な変更前後の使用量も公開していません。したがって、「アカウント全体でエージェントがひとつだけになる構成」とは解釈できず、一定割合の節約を約束することもできません。

通常のサブエージェントは独立したコンテキストから始まり、委任されたタスクと対応する設定を受け取ります。メインセッションの会話履歴をすべて自動的に持つわけではなく、既存の会話を引き継ぐのはforkサブエージェントです。細かな調査過程をサブエージェントに移せば、メインセッションに直接残る途中経過を減らせますが、サブエージェント自身のリクエストでもトークンは処理され、返した結果もメインセッションに入ります。サブエージェントのコンテキスト範囲

そのため、「同時にいくつ起動するか」より先に、「この仕事は委任する価値があるか」を考えます。単純な検索に、計画役、調査役、実行役の一式は必要ありません。同じファイルを何度も変更する2つの仕事も、同時実行に向くとは限りません。本当に独立していて、成果物が明確な調査のほうが、並行して比較するのに向いています。

たとえば、作業指示は次のように具体化できます。

目的：今回合意した変更を完了し、直接関係するチェックを通す。
変更可能な範囲：今回の依頼に関わる実装と対応するテスト。
進め方：単純な検索は直接実行する。委任が本当に必要な場合は、そのサブタスクに必要な背景と成果物の要件だけを渡し、一度にひとつのサブエージェントを割り当てる。待機中に同じ状態を繰り返し問い合わせない。
完了条件：受け入れ条件を満たす成果を出し、関連チェックが通ったら停止する。進められない場合は、完了した内容と阻害要因を報告し、同じタスクを再起動しない。

これも、依然として行動に対する指示です。標準のサブエージェントの作成を実際に制限したい場合は、クライアントの制御項目を使います。 Claude Code v2.1.217以降では、同時実行数と委任の深さを制限できます。以下はmacOS、LinuxのBash/Zshで起動する例で、不要な並列処理を調べる際の控えめな初期設定として使えます。環境変数リファレンス

CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS=1 \
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 \
claude

最初の変数は、ひとつのセッション内でAgentツールから新しいサブエージェントを作成するときの同時実行チェックを設定します。2つ目はサブエージェントを1階層に制限し、その先への入れ子の委任を防ぎます。プロンプトではなく、すでに起動している別のセッションを後から変更するものでもありません。環境変数リファレンス

ただし、これは「常にすべてのエージェントがひとつ以下になる」グローバルなロックではありません。公式ドキュメントには例外が明記されています。ultracodeセッションではこの同時実行制限は適用されず、手動の/subtaskや完了済みサブエージェントの再開も、同じ新規作成チェックでは阻止されません。ワークフローとagent teamsにはそれぞれ別の制限があります。複数のメインセッションや外部から起動したプロセスを、この設定ひとつでまとめて管理することもできません。同時実行制限と例外

独自のスケジューラーで本当のグローバル上限が必要なら、起動、再開、再試行を共通のキューや同時実行ロックで管理します。プロンプトに「一度にひとつ」と書くだけでは足りません。これは独自のスケジューリング実装であって、別の未説明のClaude Code設定ではありません。

結果を待つことと、モデルに進捗を何度も聞かせることは違う

LeeLeepenkmanの不満は、単に「サブエージェントを使った」というものではありません。Fable 5.1がmuseに大きなプロンプトを渡したあと、約5秒おきにポーリングしてコンテキストが急増した、と説明しています。元の投稿にはmuseの具体的な実装、リクエスト記録、問題解消後の結果がありません。そのため、5秒をClaude Codeの固定ポーリング間隔として扱うことはできません。

現在、標準のバックグラウンドサブエージェントには完了通知があり、結果は後続のターンでメインセッションに返されます。実行状況は/tasksで確認できます。これは、モデルに「終わりましたか」と新しいリクエストを繰り返し送らせることとは別です。バックグラウンドサブエージェントと結果通知

調査するときは、セッションのツール記録を展開して同じタスクを追います。繰り返した確認で新しい情報は得られたか。完了した仕事が再起動されていないか。状態確認が本当に新しいモデル呼び出しにつながったか。Ctrl+Oで会話をより詳しく表示できますが、画面の更新回数をそのままモデルのリクエスト数として数えることはできません。リクエスト単位の使用量が必要なら、実際に利用している接続先の記録も照合します。操作とセッション表示

標準の通知を使っている場合、通常はモデルによる高頻度の確認ループを追加する必要はありません。外部ツールがポーリングしか提供しないなら、プログラム側で妥当な間隔で状態変化を確認し、タイムアウトを設け、新しい結果や異常があったときだけモデルに情報を渡せます。ここで減らしたいのは、新しい情報をもたらさないモデル呼び出しであり、必要な進捗確認を禁止することではありません。

利用枠が回復したら、まず残っている仕事を確かめる

intwerpretは、さらに激しい体験を報告しました。利用上限に達したあと、待機して自動で続行する選択をしたところ、39個のエージェントが現れて再び利用枠を使い切り、最終的にCodexへ戻ったと主張しています。資料にはクライアントのバージョン、タスク内容、完全な設定、再開機能がどこから提供されていたかの情報がなく、その後タスクが完了したかも不明です。

この報告は再開手順を確認するきっかけにはなりますが、「Claude Codeの自動再開は必ず39個のエージェントを起動する」ことの証明ではありません。また、投稿者が「Ultra」と表現しただけでは、先ほどのultracodeモードを使っていたとも断定できません。

一方で、現在の自動続行をすべてサードパーティーのスクリプトによるものと考えるのも正しくありません。公式の操作ドキュメントには、利用上限の回復後に続行する標準機能が記載されています。v2.1.234以降では、条件を満たすサブスクリプションの対話型セッションが、利用枠の回復を待って作業を続行できます。APIキー利用、-p、すべてのバックグラウンドモードで同じ動きをするという意味ではありません。再開も、ユーザーが最後に出した元のタスクを単純に再送することではありません。標準の待機と自動続行

人が見ていない状態でタスクを再開させるつもりがなければ、/configで**Continue automatically at usage limit（利用上限の回復後に自動で続行）**をオフにします。対応するバージョンでは、次のコマンドでも設定できます。

/config autoContinueAtUsageLimit=false

すでに待機に入っている場合は、その待機自体も取り消します。入力欄が空の状態でEscを押すか、/rate-limit-optionsで**Don’t continue automatically（自動で続行しない）**を選びます。デフォルト設定の変更と、すでに選択した今回の待機を取り消すことは、別の操作です。自動続行の取り消しと設定

そのうえで、/tasksと実際のファイルの状態を確認します。まだ動いているタスク、完了したタスク、もう一度確認するだけでよいタスクはどれでしょうか。既存の結果は再利用し、未完了の仕事には続行する目標を明示します。要件を丸ごと再送し、もう一度タスクの分解から始めさせるのは避けます。

特に、コミット、デプロイ、メッセージ送信など外部に影響する操作では、前回の実行が成功していないかを先に確かめます。利用枠の回復が解決するのは「リクエストを続けられるか」であり、「次の操作が重複しないか」までは保証しません。

使用量の改善を判断する前に、完成した結果を見る

chasemdevは、Fable自身にずっとコードを書かせているのではなく、Opusのサブエージェントを取りまとめさせていると説明していました。それでも、近いうちに週間上限に達しそうだと予想しています。ここでの「近いうち」は投稿時点の本人の予測であり、確認済みの最終消費量ではありません。ただし、記録で見落としやすい点を示しています。メインモデルだけでなく、サブエージェントが使うモデルと、その仕事も含めて考える必要があります。

現在の/usageのSession欄には、セッションのトークン使用量と、ローカルで計算された料金の見積もりが表示されます。サブスクリプション利用者は、同じ画面でプランの使用量も確認できます。Session内のドル表示はサブスクリプションの請求額ではなく、API提供元の最終的な請求額と一致するとも限りません。従量課金では、実際の提供元の請求を基準にしてください。現在の/usageの意味

サブスクリプション使用量のローカルな内訳も、あくまで手がかりです。サブエージェント、プラグイン、スキルなどへの割り当ては、その端末の最近の履歴に基づきます。他の端末やWebでの使用量をすべて含むものではなく、あるプラグインが「どれだけ無駄を生んだか」の因果関係を示すものでもありません。Showing last-known usageと表示されたら、表示データの時刻を記録し、更新してから比較します。内訳の対象範囲とキャッシュされた表示

複雑な評価システムを作る必要はありません。範囲が明確で安全に再現できるタスクを選び、受け入れ条件を書いたうえで、開始時と終了時に次の内容を記録します。

記録するもの	確認したいこと
タスク、開始時のコードのバージョン、モデル、effort、クライアントのバージョン	前後で同じ種類の仕事と設定を比較しているか。
/contextと圧縮の過程	圧縮後に制約が抜けたり、読み直しや説明のやり直しが生じたりしていないか。
サブエージェントと待機中の動作	何を新規作成・再開し、最大でいくつ同時に動いたか。新情報のない確認を繰り返していないか。
使用量の表示値、時刻、利用枠のリセット時点	途中で利用枠がリセットされていないか。他のセッションが混ざっていないか。APIでは関連する全モデルを確認したか。
実際の成果物とチェック結果	要件は満たされたか。関連チェックは通ったか。人による手直しがどれだけ残っているか。

変えるのはひとつのやり方だけにします。たとえば、調査が終わってからcompactする、あるいは新しいサブエージェントの同時実行数を制限する、といった変更です。元の受け入れ条件はそのままにし、数字を小さくするためにタスクをひそかに縮めないでください。キャッシュの状態が異なっていたかも記録します。モデル、コードのバージョン、タスク規模が違う2回の実行なら、差をすべてcompactの効果にしてはいけません。

トークンが少し減っても、要件が抜けたり検証を人に残したりしたなら改善とは言えません。逆に、コンテキストを長く保持したことで調査を繰り返さず一度で完了したなら、ウィンドウ使用量が高いだけで無駄とも言えません。

独立したAPI利用とサブスクリプションは、なおさら分けて記録する必要があります。課金元を切り替えても元のサブスクリプション枠は回復せず、クライアントの委任、待機、圧縮の動作も自動では変わりません。価値を判断するなら、あるモデルの単価だけでなく、同じタスクを完了するまでの総使用量と手戻りを比較しましょう。課金方式の違い · APIのトークン課金体系

圧縮の判断をプラグインに任せる前に、何が外部へ送られるかを見る

Kun Chenの出発点は実用的な問いでした。「when should i /compact my session」――現在のセッションは、いつ圧縮すべきなのか。compact-adviserはTypeSafeのJevを使い、圧縮に向いた作業の区切りに達したかを判断します。ヒントだけを出すモードと、利用者が明示的に選ぶ自動モードがあります。プロジェクトの説明

この記事の確認対象はコミットd1655faa16a22b68bff60c3d7deb0123e1e52a53に固定しており、Claude Code用プラグインのマニフェストに記載されたバージョンは0.1.4です。プロジェクトはNode.js 22以降、Claude Code 2.1.274以降を必要とし、2.1.275で検証したとしています。Claude Codeとの連携は実験的な関数hooksに依存し、CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1が必要です。これはプロジェクトが示す互換性条件であり、この記事でインストールして実測した結果ではありません。固定バージョンのマニフェスト · バージョンと連携の要件

より重要なのは、hintモードは自動で圧縮しないというだけで、ローカルで判断する、あるいはコンテキストを外に出さないという意味ではないことです。セキュリティ文書によれば、インストール後、起動環境、保存済み設定、または作業ディレクトリの.envからキーを取得でき、呼び出し条件を満たすと、選別されたセッション内容がTypeSafeに送信されます。ユーザーの制約、最近の可視の応答とツール結果、既存の要約、成果物名などが含まれます。送信への同意を別途確認する独立したスイッチはありません。抜粋にもコードや業務情報が含まれる可能性があり、できる限りのマスキングは、機密情報が残らない保証ではありません。コンテキストの外部送信範囲

すでにインストールしている場合は、/compact-adviser offで無効にするか、起動時に次を使えます。

COMPACT_ADVISER_DISABLE=1 claude

プロジェクトの説明では、これによりプラグインのリクエスト、ヒント、自動圧縮が停止します。無効になるのはプラグインであり、Claude Code本体の自動圧縮ではありません。 業務内容を追加でTypeSafeへ送信してはいけない場合は、autoからhintに切り替えるだけでなく、無効化またはアンインストールしてください。無効化の方法

作者が述べる40セッションの評価はプロジェクト自身によるもので、データセットは公開されていません。それを根拠に、自分のタスクで細部が失われないと保証することはできません。プラグインが「圧縮に適している」と判断しても、最後に確かめるべきなのは、圧縮後に作業を正しく続けられるかです。評価の限界

プラグインを入れなくても、作業の区切りで状態を保存し、次に本当に必要な情報を残すことはできます。サブエージェントには明確で独立した仕事を任せ、待機や再開で重複起動を避け、成果物と使用量記録の両方から効果を判断しましょう。

長いタスクの管理で目指すのは、ウィンドウを埋めることでも、個々のリクエストを最も安く見せることでもありません。タスクを前に進めない仕事を減らし、始めたことを確実に終えることです。