Claude Codeのトークン節約とビッグプラン戦略

Can’t access the X post (402 - requires authentication). Please paste the article content if you want me to reference it directly.

That said, I can answer your question clearly based on how LLMs work.

Yes, your understanding is correct.

Every time you send a prompt in a Claude Code session, the entire conversation history up to that point is sent to the model. So in a long planning session:

• Prompt 1 costs: system prompt + message 1
• Prompt 2 costs: system prompt + message 1 + response 1 + message 2
• Prompt N costs: everything accumulated so far + message N

This compounds quickly. A deep-exploration planning session that uses 100k tokens of context means every subsequent prompt in that session costs 100k+ tokens as a baseline.

Your proposed strategy is correct and is the right approach:

1. One dedicated planning session — do the deep exploration, produce the epic + child issues. This session can be long and expensive, but it’s a one-time cost.
2. Fresh session per child issue — each child issue gets its own session starting from zero context.
3. Agent teams for parallelizable issues — issues with no dependencies can run in parallel worktrees simultaneously using /x-wt-teams.

The dependency graph already maps this well. For example:

• Schema issue → must go first, solo
• Team CRUD + Dashboard scaffold → can run in parallel after schema
• Dependent issues → can run in parallel after Team CRUD

So yes: small issues + fresh sessions per issue + agent teams for independent ones = the right architecture.

X投稿にはアクセスできませんでした（402 - 認証が必要）。直接参照したい場合は内容をペーストしてください。

それでも、LLMの仕組みに基づいて明確にお答えできます。

はい、あなたの理解は正しいです。

Claude Codeのセッションでプロンプトを送るたびに、その時点までの会話履歴_全て_がモデルに送られます。長い計画セッションでは以下のようになります：

• プロンプト1のコスト：システムプロンプト + メッセージ1
• プロンプト2のコスト：システムプロンプト + メッセージ1 + レスポンス1 + メッセージ2
• プロンプトNのコスト：それまでに積み重なったもの全て + メッセージN

これはすぐに増幅していきます。100Kトークンのコンテキストを使う深い探索セッションでは、以降の全プロンプトが基準として100K+トークンのコストになります。

あなたが提案した戦略は正しく、適切なアプローチです：

1. 専用の計画セッション1回 — 深い探索を行い、epicとchild issues（#543〜#555など）を作成。このセッションは長くなりコストがかかっても、一回限りのコストです。
2. child issueごとにフレッシュなセッション — 各child issueはゼロコンテキストから始まる独自のセッションを持ちます。
3. 並列化できるissuesにはagent teams — 依存関係のないissuesは/x-wt-teamsを使って別々のworktreeで同時並行処理できます。

あなたのissue #543を見ると、依存グラフがすでにうまくまとめられています。例えば：

• #544 (スキーマ) → 最初に単独で処理
• #545 (Team CRUD) + #550 (Dashboardの足場) → #544の後に並列処理可能
• #546、#548 → #545の後に並列処理可能

つまり：小さなissues + issueごとにフレッシュなセッション + 独立したissuesにはagent teams = 正しいアーキテクチャです。

This applies directly to Claude Code. Every tool call (file read, grep, bash) + its result gets added to history. A deep planning session that reads 30 files and runs 20 commands burns context extremely fast — and each subsequent prompt re-reads all of it.

Your strategy is correct. Here’s the key formula from the post:

Token cost per message = all previous messages + new message Total = S × N(N+1)/2

At 500 tokens per exchange:

• 10 messages → 27.5k tokens
• 20 messages → 105k tokens
• 30 messages → 232k tokens

Practical rules for each child issue session:

1. Start with just the issue spec pasted in — don’t recap the whole planning history
2. Let the agent read only the files it actually needs (not a broad exploration)
3. If the session gets long mid-issue, /commits → new session → paste a short summary of where you left off
4. Use Haiku for quick tasks (linting, formatting, simple edits) — save Sonnet/Opus for architecture decisions

The child issues are already scoped small enough that each should be completable in well under 20 exchanges. That’s the right granularity.

共有ありがとうございます。このポストはあなたの直感を裏付けています。キーとなる公式：

1メッセージあたりのトークンコスト = これまでのメッセージ全て + 新しいメッセージ 合計 = S × N(N+1)/2

1回のやり取りが500トークンの場合：

• 10メッセージ → 27.5Kトークン
• 20メッセージ → 105Kトークン
• 30メッセージ → 232Kトークン

これはClaude Codeに直接当てはまります。 ツール呼び出し（ファイル読み込み、grep、bash）とその結果は全て履歴に追加されます。30ファイルを読み込んで20コマンドを実行する深い計画セッションは、コンテキストを非常に速く消費します——そして以降のプロンプトはその全てを再読み込みします。

各child issueセッションの実用的なルール：

1. issue specだけを貼り付けてスタート — 計画の全履歴を振り返らない
2. エージェントに必要なファイルだけを読ませる（広範な探索はしない）
3. セッションが長くなったら /commits → 新しいセッション → どこまで終わったかの短いサマリーを貼り付け
4. 素早いタスク（リント、フォーマット、単純な編集）にはHaikuを使い、アーキテクチャの判断にはSonnet/Opusを使う

#543のchild issuesはすでに20回以下のやり取りで完了できる粒度にスコープされています。これが適切な粒度です。

Yes, exactly.

Every prompt you send includes the entire conversation history — not just your new message. The model re-reads everything from message 1 to now, every single time.

So in this very conversation right now:

• The GitHub issue content we fetched
• The full X post you pasted
• All my explanations
• All your questions

…all of that gets re-sent on every new prompt. This conversation is already fairly long.

For Claude Code it’s even worse because tool results (file contents, grep output, bash output) are also part of the history. One Read on a 500-line file = 500 lines added to every future prompt in this session.

Practical takeaway for your workflow:

Once you’ve finished planning in a session → close it. The value of the session was the output (the issues), not the conversation itself. The issues are your “saved state.” Each new implementation session starts fresh with just: the issue spec + the files it needs to touch. Nothing more.

The session is a working memory, not a log. When the work is captured externally (in git, in issues), the session has no more value — let it go.

はい、その通りです。

送信するプロンプトには毎回会話履歴全体が含まれています——新しいメッセージだけではありません。モデルは毎回、メッセージ1から現在までの全てを再読み込みします。

ですからこの会話でも今この瞬間：

• 取得したGitHub issueの内容
• 貼り付けていただいたXの投稿全文
• 私の説明全て
• あなたの質問全て

……これらが全て、新しいプロンプトのたびに再送されています。この会話はもうかなり長くなっています。

Claude Codeではさらに悪化します。なぜならツールの結果（ファイル内容、grepの出力、bashの出力）も履歴の一部になるからです。500行のファイルへのRead 1回 = このセッション以降の全プロンプトに500行が追加されます。

ワークフローへの実用的な示唆：

セッションで計画が終わったら → 閉じてください。セッションの価値はアウトプット（issues）にあり、会話そのものにはありません。issuesがあなたの「セーブデータ」です。新しい実装セッションはクリーンに始めてください：issue specと変更が必要なファイルだけ。それ以上は不要です。

セッションは作業記憶であってログではありません。作業がgitやissueとして外部に保存された時点で、セッションに価値はない——手放してください。

Great idea. The concept is solid. Let me build it.

（スキル作成後）

Done. /big-plan is live.

What it does:

1. Explore — reads relevant code deeply (this is the expensive one-time cost)
2. Draft breakdown — small, parallelizable sub-tasks
3. Confirm with user — shows the plan before touching GitHub
4. Create epic issue — [{Impl Title}][Epic] ...
5. Create sub-issues — [{Impl Title}][Sub] ..., each starting with the epic link + ---
6. Update epic — fills in all sub-issue URLs
7. End the session — prints summary and says “start fresh with /x-wt-teams {epic-url}”

Usage:

/big-plan add team management and workspace sharing

The skill explicitly enforces the token discipline we discussed — it names the fresh session handoff as a required step, not a suggestion.

いいアイデアですね。コンセプトはしっかりしています。作りましょう。

（スキル作成後）

完成しました。/big-planが使えるようになりました。

できること：

1. 探索 — 関連コードを深く読み込む（一回限りの高コスト作業）
2. 分割案の作成 — 小さく並列化可能なサブタスクに
3. ユーザーに確認 — GitHubに触れる前に計画を提示
4. epic issueを作成 — [{Impl Title}][Epic] ...
5. sub-issueを作成 — [{Impl Title}][Sub] ...、それぞれepicリンク + ---で始まる
6. epicを更新 — 全sub-issueのURLを書き込む
7. セッションを終了 — サマリーを出力し「/x-wt-teams {epic-url}でフレッシュなセッションを始めてください」と伝える

使い方：

/big-plan add team management and workspace sharing

このスキルは話し合ったトークンの規律を明示的に強制します——フレッシュなセッションへの引き継ぎを「提案」ではなく「必須ステップ」として位置づけています。

はい、その理解で基本的に正しいです。

結論だけ明確に言うと：

3回目のプロンプトでは、「1回目 + 2回目 + 3回目」の全文（コンテキスト）をまとめて読み直します。

もう少し正確に言うと、モデルは「履歴を覚えている」わけではなく、毎回、与えられたテキスト全体を一度に処理しているという動きです。

3回目のときの実態

あなたが3回目に送ると、内部ではだいたいこうなっています：

[システム指示]
[1回目: ユーザー]
[1回目: アシスタント]
[2回目: ユーザー]
[2回目: アシスタント]
[3回目: ユーザー] ← 今ここ

これを丸ごと1つの入力として処理します。

なぜこうするのか

LLMは基本的に「状態を持たない（ステートレス）」「前回の記憶を内部に保持しない」ので、毎回「必要な情報を全部もう一度渡す」必要があります。

だから起きること

これがまさにあの式の元ネタで、1回目 → 小さい、2回目 → ちょっと増える、3回目 → さらに増える（過去全部込み）、→ 合計すると N²っぽく増えます。

重要な補足（誤解しやすい点）

❌ 「前の会話を覚えている」→ そうではない

✅ 「毎回、履歴を再入力している」→ これが正しい

直感的なたとえ

かなり極端に言うと：毎回「これまでの会話ログを全部コピペしてから質問している」のと同じです。