バイブコーディングでトークンを溶かさないための2つの工夫

人生で初めてのバイブコーディングを始めるために契約したClaude ProとGoogle AI Proを契約して一か月。Claude Code, Google Antigravityで管理しているのはSwiftのiOSアプリとAWS CDKのバックエンド。両方を同じセッションでメンテしようとするとトークンが想像以上の速さで消える。月額課金しているのに使用制限に引っかかるのは純粋にストレスだった。

試行錯誤の末に落ち着いた運用を2つ紹介する。

---

仕様書をAIに書かせて /docs に置く

仕様書がない状態でAIに質問すると、毎回コードベース全体をクロールして文脈を把握しようとする。これがトークン消費の大きな原因になる。

実装初期に以下を指示して生成させた。

my-project/
  docs/
    spec.md     # 機能仕様・アーキテクチャ概要
    rules.md    # コーディング規約・AIへの指示ルール

以降は「docs/spec.md を前提に答えて」の一言で文脈共有が完結する。コードを読み込ませる必要がなくなるので、トークン消費が明らかに落ちた。

指示のブレも減った。「毎回ちょっと意図と違う」という現象は、AIが毎回コンテキストを推測していることが原因のひとつ。ルールを明文化して渡すと、実装の方向性がずれにくくなる。

仕様書は実装と並走して育てていくイメージ。最初は粗くていい。

副次効果として、マルチAI運用がしやすくなる。 同じ spec.md をGeminiに渡して設計レビューを頼む、ClaudeとGeminiで回答を比較する、といった使い方が自然にできるようになった。

---

モデルをタスクの性質で使い分ける

最初は全タスクを上位モデル（Pro / Sonnet）に投げていた。質は高いが使用制限への到達が早い。

下位モデル（Flash / Haiku）に切り替えると今度はコードを壊されることが増えた。特にGemini Flashには何度もやられた。修正のデバッグに時間を取られ、結果として上位モデルをデバッグに使う羽目になる。本末転倒だった。

今の使い分けはこうなっている。

タスク	モデル
実装計画・設計レビュー	上位（Pro / Sonnet）
コーディング	下位（Flash / Haiku）
デバッグ・原因調査	上位（Pro / Sonnet）
文法確認・細かい質問	下位（Flash / Haiku）

「思考が必要な場面は上位、手を動かす場面は下位」というシンプルな基準。

コーディングを下位モデルに任せるには、指示の精度が重要になる。ここで仕様書が効いてくる。spec.md と rules.md を渡した状態で実装を依頼すると、下位モデルでもコンテキストのズレが起きにくく、コードを壊されるケースが減った。

使用制限に引っかかる頻度は、この2つを組み合わせてから明らかに下がっている。