バイブコーディングのトークン管理戦略

Thu, 19 Mar 2026 09:00:00 +0900

トークン不足はモデル性能の問題ではなく、たいていはコンテキストの運用方法の問題です。

チョン・ドヒョン - ROBOCO首席コンサルタント

Claude Code、Codex、Geminiのようなバイブコーディングツールを長く使っていると、ある時点から似たような症状が現れます。応答が遅くなり、すでに合意した制約を忘れ、関係のないファイルにまで手を出し始めるのです。これをよく「トークンが足りない」と表現しますが、実際に起きている現象は、より正確に言えばコンテキスト汚染、あるいはContext Rotに近いものです。

Perplexityを通じてまとめたideationメモを読み返してみると、要点ははっきりしています。実際の利用環境では、トークン使用量の大部分は出力ではなく入力コンテキストで発生します。したがって問題を解く最良の方法も「より大きなモデル」ではなく「よりきれいなコンテキスト」なのです。本稿ではその内容をもとに、ツール別の機能紹介ではなく実務の運用戦略を中心に、トークン管理の原則を整理してみます。

TL;DR

トークン不足は単なる上限の問題ではなく、会話・ログ・文書が入り混じって生じるコンテキスト汚染の問題として捉えるべきです。
.claudeignore、作業文書の分割、/clearと/compact、handoff文書のように、範囲を絞る習慣がまず先です。
良いバイブコーディングとは、長いプロンプトよりも、いま必要な情報だけをモデルに見せるコンテキスト設計に近いものです。

なぜトークンが先に尽きるのか

長いセッションが積み重なり続けると、問題は二つの層で現れます。一つは純粋なトークン上限への到達であり、もう一つはそれより先に訪れる品質の低下です。会話ログ、失敗した試み、暫定的な仮説、長いビルドログ、すでに終わった作業の文脈が残り続けると、モデルはいま重要な情報とすでに破棄された情報を区別しにくくなります。

この現象は、単にコンテキストウィンドウの大きさでは解決しません。長いコンテキストはより多くの情報を収められるようにしてくれますが、その中の情報がきちんと整理されている保証まではしてくれないからです。だからこそトークン管理の核心は、節約そのものよりも選別にあります。

戦略1: `.claudeignore`で、そもそも読ませてはいけないものを遮断する

実測ベースで最もROIが高い単一の施策は、.claudeignoreの設定です。ideation文書に引用された事例では、node_modules、ビルド成果物、ログ、バイナリ、大容量画像、lockファイルを除外するだけでも30〜40%程度の削減効果が報告されています。¹²

たとえば、こういった具合です。

node_modules/
.next/
dist/
build/
coverage/
.cache/
*.log
*.db
*.sqlite
.env*
*.png
*.jpg
*.gif
*.mp4

この戦略の本質は節約ではありません。モデルが、そもそも見ても役に立たない情報を見ないようにすることです。とくにlockファイルやビルド成果物は、トークンを多く消費するわりに推論上の価値がほとんどありません。

戦略2: `tasks.md`を一つに詰め込まず、インデックス構造に分割する

ideation文書で最も印象的な事例の一つが、単一の大きなtasks.mdをドメイン別文書とINDEX.mdの構造に分けて76.1%の削減を達成したケースです。³

tasks/
├── INDEX.md
├── backend.md
├── frontend.md
├── infra.md
├── security.md
└── archive/

この構造が良い理由は単純です。すべての作業ですべてのタスクを読む必要はないからです。全体の状況はINDEX.mdだけ見ればよく、特定の作業では該当ドメインのファイルだけを読めば済みます。完了した履歴はarchive/に片付けておけば、現在のセッションの作業台から消えます。

トークン管理とは、結局のところ文書の情報アーキテクチャの問題でもあるのです。

戦略3: セッションを長く引きずらず、`/clear`と`/compact`を意識的に使う

Claude Codeを基準に見ると、最も即効性が高い方法は/clearと/compactを戦略的に使うことです。⁴⁵

/clearは作業の文脈を完全に初期化するときに使います。
/compactは重要な内容だけを残して会話履歴を要約するときに使います。
長いデバッグセッションの直後、機能を一つ終えたとき、あるいはコンテキスト使用量が70%程度に達したときにcompactをかける習慣が効果的です。⁵

肝心なのは、長い会話をずっと維持するほうが生産的だという錯覚から抜け出すことです。セッションは長く続けるよりも、短く切って再開できるべきなのです。

戦略4: handoff文書を残して新しいセッションに移る

セッションを頻繁に切るには、再開のコストが低くなければなりません。このとき最も単純で強力な方法が、HANDOFF.mdのような短い引き継ぎ文書を置くことです。⁶

たとえば、以下の程度で十分です。

目標: ログインフローのrace condition解消
修正したファイル: auth_service.ts, login_controller.ts
確認した事実: DBの問題ではなく、APIの重複呼び出しが原因
失敗した試み: mutexの適用は副作用が出たためロールバック
次の作業: idempotency key方式の検討
完了条件: 重複ログインの再現テストが通ること

この文書の目的は、長文の記録を残すことではありません。次のセッションがすぐに働き出せる程度の方向性だけを残すことです。

Gemini on ROBOCO