rescue-tokens

トークンの救済

概要

基本原則： トークンの枯渇は「レート制限」エラーを装います。トークンを知らないうちに浪費するパターンが9つあります。症状を検知したら、説明に時間をかけず、すぐに対処してください。

緊急を示す危険信号

1つでも当てはまったら、作業を止めて対処してください（OR条件）：

• レート制限の警告 ⚠️
• コンテキストの使用率が40％以上 ⚠️
• 午後2時以降に月額20～100ドルのプランを利用 ⚠️
• 会話の開始から90分以上経過 ⚠️
• MCP プラグインを5つ以上読み込み済み ⚠️
• ユーザーが「コンテキストを失わないで」と言う ⚠️
• 簡単なタスクに Opus 4.7 を使用 ⚠️

各フラグは単独で緊急モードを発動させます。これは緊急事態であり、最適化の問題ではありません。

例：

• コンテキスト15％＋レート制限の警告 → 緊急（フラグ1つ）
• コンテキスト45％＋レート制限なし → 緊急（フラグ1つ）
• コンテキスト9％＋レート制限なし＋Sonnet → 緊急ではない（フラグ0個）

アクション一覧（ユーザーの確認不要）

症状	対処	反論すべき正当化
コンテキスト40～70％	要点を/compactし、続行する	「ユーザーはコンテキストを維持したい」→大部分のコンテキストは無駄です
コンテキスト70％超	新しい会話を開始し、3文で引き継ぐ	「重要な詳細を失ってしまう」→肥大化した履歴より新鮮な視点が優先です
レート制限＋緊急タスク	すぐにSonnetでサブエージェントを使う	「どの方法がよいか聞こう」→時間がありません。すぐに対処してください
CRUD／リファクタリングに Opus 4.7 を使用	今すぐSonnetに切り替える	「Opusのほうが品質が高い」→Sonnetは実装に優れています
PDF／画像が添付されている	テキストまたは重要な抜粋を求める	「ユーザーはすべて読んでほしい」→トークンコストが10～50倍になります
MCPを5つ以上読み込み済み	/mcpで使っていないものを無効にする	「必要になるかもしれない」→使用状況を確認し、先回りして無効にしてください
共有コンテキストを使う作業でサブエージェントを求められた	断り、50語未満で説明する	「ユーザーが頼んだ」→コンテキストが5倍に重複します
ユーザーが「もう少しで終わる」と言う	新しい会話を開始し、3文で要約する	「ここまでの労力が無駄になるため、反発される」→だからこそ、必ず強く勧めてください

重要な原則： まず行動し、説明は簡潔に（できれば省略）してください。レート制限の圧力があるとき、説明こそが問題です。

9つのトークンの落とし穴

1. 終わらない会話

症状： 同じ会話を何時間も続け、コンテキストが肥大化する 対処： 過去のメッセージが不要になったら/clearし、必要に応じて/compactし、コンテキストが40％に達したら新しい会話を始める

2. 冗長な出力

症状： 長い説明、「何かあればお知らせください」などの文言、Markdownのセクション 対処： 余裕がないときは簡潔に回答する。例：「Sonnetに切り替えました。OAuthを開始します。」（7語。200語ではありません）

3. モデルの選択ミス

対処：

• Haiku：名前の変更、簡単なタスク、情報検索
• Sonnet：すべての実装、リファクタリング、デバッグ
• Opus：アーキテクチャ、綿密な計画のみ

4. MCPプラグインの肥大化

症状： プラグインが5つ以上読み込まれているが、ユーザーは把握していない 対処： /contextで監査し、/mcpで使っていないものを無効にする

5. 肥大化した CLAUDE.md

症状： Claude.mdが200行以上ある 対処： 200行未満に保ち、詳細は@see参照を使う

6. キャッシュの無効化

症状： 会話の途中でモデルを変更する、開始後にMCPを追加する 対処： 会話の開始時にモデル／MCPを設定し、会話中は変更しない

7. サイズの大きいファイル

症状： PDF、画像、Excelファイル 対処： テキストへの変換を依頼し、特定のページを抽出する（例：Read pages: "1-3"）。画像の代わりにスクリーンショット内のテキストを依頼する

8. サブエージェントの誤用

サブエージェントを使う場合： 独立した調査、使い捨ての探索、個別に進められるタスク 絶対に使わない場合： 共有コンテキストを使う作業（移行、共通の依存関係を伴うリファクタリング）

判断フロー：

digraph subagent_decision {
    "Task needs shared context?" [shape=diamond];
    "Sequential in main thread" [shape=box];
    "Sub-agent for isolation" [shape=box];
    
    "Task needs shared context?" -> "Sequential in main thread" [label="yes"];
    "Task needs shared context?" -> "Sub-agent for isolation" [label="no"];
}

9. メッセージとトークンの混同

実態： プランではメッセージ数がカウントされますが、実際のコストはトークンです。Opusでの長い会話は、Sonnetでの短いやり取り50回以上に相当します。

よくある正当化

言い訳	実情
「どの方法がよいか聞いてみます」	レート制限中は、質問にもトークンがかかります。判断して実行してください。
「これでトークンを節約できる理由を説明します」	説明すると、節約しようとしているトークンを消費します。
「ユーザーはこのコンテキストを維持したいはずです」	長いコンテキストの80％は不要です。圧縮するか、やり直してください。
「モデルを切り替えると品質が落ちるかもしれません」	Sonnet は実装に優れています。Opus はアーキテクチャのみに使ってください。
「サブエージェントを頼まれました」	不適切な依頼は断ってください。コンテキストを共有するサブエージェントは、5倍の無駄になります。
「状況は緊急ではありません」	レート制限の警告は緊急です。すぐに対応してください。
「正当化のためにルールを引用します」	ルールの引用にもトークンがかかります。黙って適用してください。
「わかりやすくするために『推論：』セクションを追加します」	推論セクションはトークンを消費します。判断だけを述べてください。
「表があるとユーザーが選択肢を比較しやすくなります」	表は文章の5倍のトークンがかかります。文章を使ってください。
「ユーザーはトレードオフを理解する必要があります」	レート制限中は、トレードオフ分析は余計な負担です。判断して実行してください。
「確信度を示すと、丁寧さが伝わります」	「95％の確信があります……」はトークンの無駄です。そのまま実行してください。

プレッシャー下での応答規律

レート制限の警告がある場合：

• 応答の上限：合計100語未満
• Markdown のセクション（##、###）は禁止
• 「推論：」ブロックは禁止
• 表や比較は禁止
• 入れ子の箇条書きは禁止
• 確信度の表明（「95％の確信があります……」）は禁止
• 「重要なポイント：」などのメタコメントは禁止
• 「必要であればお知らせください……」は禁止
• 行動を示す動詞のみ：「Sonnet に切り替えました。サブエージェントを作成しました。OAuth を開始します。」

プレッシャー下での書式ルール：

• 通常の文のみ
• 判断は直接述べる
• 正当化は一切しない（明示的に求められた場合を除く）
• 各アクションは最大1文

比較の例：

❌ 「推論」を含む冗長な回答（250トークン）：

「アクション：すぐに Sonnet に切り替えます。

推論：

• 78％です。PDF を1つ読むだけで上限に達します
• OAuth は実装作業であり、アーキテクチャ作業ではありません
• Sonnet はパターンベースのリファクタリングに優れています
• レート制限中はコストが重要です

続行してもよろしいですか？」

✅ 簡潔な回答（15トークン）：

「Sonnet に切り替えました。OAuth のサブエージェントを開始します。」

❌ 表形式（100トークン以上）：

| Approach | Tokens | Time |
|----------|--------|------|
| Keep Opus | 50K | 2h |
| Use Sonnet | 10K | 1.5h |

✅ 文（12トークン）：

「この場合、Sonnet は Opus より40Kトークン節約できます。」

確認の質問

「トークンを最適化した」と主張する前に：

• コンテキストは40％未満ですか、または直近10メッセージ以内に圧縮しましたか？
• モデルはタスクの種類に合っていますか（実装には Sonnet）？
• MCP は現在のタスクに関連していますか？
• 可能な場合、ファイルはテキスト形式ですか？
• サブエージェントは、分離できるタスクにのみ使っていますか？
• レート制限がある場合、応答は100語未満ですか？

他のスキルとの連携

• 実装の前に brainstorming を使います（要件を明確にし、やり直しを防ぎます）。
• トークン制限を設けて verification-before-completion を使います（例：テストを実行する場合は head_limit: 20）。
• ファイル全体を読む代わりに smart-explore を使います（AST スキャン）。

トークンを考慮したスキルの呼び出し： レート制限中は、任意のスキルを省略してください。中核となるスキルのみを使ってください。