光の速さでAIの使用上限に達したので、トークン節約術を全部まとめる

AI と一緒にアプリを作っていると、避けて通れないのが利用上限です。
定額プランでも無限に使えるわけではなく、
一定期間内に AI が読み書きした量（トークン）が上限に達すると、しばらく使えなくなります。
自分は一番高性能なモデルで回し続けて、光の速さで上限に達しました。

それ以来「精度を落とさずにトークンを減らす」工夫をずっと積み上げてきたので、
今までやってきた節約術を全部まとめておきます。
コードが書けない自分でもできたことばかりなので、同じ悩みの人の参考になれば。

大前提：AIは毎回、資料を読み直している

まず知っておきたいのは、AI との会話は毎回リセットされるということです。
新しいセッションの AI は何も覚えていないので、
ルールや過去の教訓を書いた資料を、会話のたびに読み直します。

つまり読ませる資料の量が、そのまま毎回のコストになる。
ここが分かると、節約のやることが見えてきます。
「読む量を減らす」「書く量を太らせない」「重い頭脳を無駄遣いしない」の3方向です。

【読む量を減らす】全部読ませない仕組み

AI 向けの資料は、育てているうちに一時 17 ファイルまで増えました。
これを毎回全部読ませていたら、会話を始めた瞬間にトークンが溶けます。

そこで作ったのが「逆引き地図」です。
「知りたいこと → 読むファイル」の対応表を README に置いて、
必要なファイルだけ開く運用にしました。
たとえば販売の話をしないセッションでは、販売戦略の資料は一切読まない。

あわせて資料ごとに読む優先度も決めてあります。
仕事の進め方をまとめた引き継ぎ書はほぼ必須、
技術メモは開発作業のときだけ、
プロジェクトの進捗メモは該当プロジェクトの欄だけ読めばいい、という具合です。

細かいところでは、こんなルールも明文化しました。

ファイルは必要な範囲だけ読む（全文を開かない）
一度読んだ内容を読み直さない
冗長な再掲・前置きを避ける

どれも人間の感覚だと当たり前ですが、
ルールとして書いておかないと AI は律儀に全部読みます。

【書く量を太らせない】資料の肥大化を止める制度

資料は「失敗したら教訓を追記する」方式で育てているので、放っておくと太る一方です。
太った資料は毎回読み込まれるので、トークン消費も増え続けます。

そこで「md圧縮制度」を作りました。中身はこうです。

1ファイル 200行を超えたら圧縮する
ただし消すのではなく、詳細は保管用フォルダへ退避して本文に1行のポインタを残す
保管用フォルダは通常のセッションでは読まない（ここが節約の本体です）
禁止事項や事故の教訓など「消えると同じ失敗を繰り返す」部分は絶対に縮めない

退避先も git 管理下なので、記憶は実際には消えません。
「圧縮しても、いつでも全文に戻れる」と分かってから、安心して縮められるようになりました。

もうひとつ効いたのが「書き先ルール」です。
新しく分かったことをどのファイルに追記するかの対応表を作ったら、
AI がその都度新しいファイルを作る増殖が止まりました。
ファイルが増えないことも、立派な節約です。

【道具を増やしすぎない】便利機能にも読み込みコストがある

AI には、定型作業を登録しておける「スキル」や、
外部ツールと連携する仕組み（MCP）を追加できます。
便利なのでつい増やしたくなりますが、
登録した道具の説明文も、毎回 AI に読み込まれています。

使っていないスキルや連携ツールは、置いてあるだけでトークンを食う。
これに気づいてから「数より精度」を基準にして、
月1回以上使うもの・抜け漏れが事故につながるものだけ登録するようにしました。
迷ったら作らない、です。

【事故に気づく】同じ資料が毎回2回読まれていた

ある日、共通ルールの資料が毎回2回読み込まれていることが分かりました。
資料の置き場所の都合で、マスター版とコピー版の両方が読まれていたのが原因です。
量にしてメッセージごとに約10KB。
気づくまでの間、ずっと二重に払い続けていたことになります。

ファイル名を変えて片方だけ読まれるように直しましたが、教訓はシンプルで、
「何が読み込まれているか」を一度 AI 自身に棚卸しさせてみる価値はあります。
思わぬところで無駄が見つかるかもしれません。

【並列の罠】速くなるだけで、安くはならない

AI は作業を並列で走らせることができます。
ただしこれ、速くなるだけでトークンの合計は減りません。
むしろ1本ごとに資料の読み込み（起動コスト）がかかるので、本数分だけ増えます。

なので普段は並列を2〜3本までに制限して、
まとめられる作業は1本に束ねるルールにしました。
急ぎのときだけ本数を増やす。速度とコストのトレードオフを意識して選びます。

【一番効いた】頭脳のグレードを使い分ける

ここまでいろいろ書きましたが、一番効果が大きかったのはこれです。
AI には頭脳のグレード（モデル）が複数あって、上位モデルほどトークンの消費が重い。
自分が上限に一瞬で達したのも、全部を上位モデルでやっていたからでした。

今はこう使い分けています。

設計・原因不明のデバッグ・大事な判断 → 上位モデル
決まった作業の横展開・原因が特定済みの修正・記録の追記 → 下位モデル

しかも、この使い分け判断を自分でやるのではなく、
「タスクの重さとモデルの釣り合いを AI 自身がチェックして、切り替えを提案する」
というルールにしてあります。
非エンジニアの自分には作業の重さが分からないので、判断ごと AI に任せる形です。

さらに直近では、役割分担まで進めました。
上位モデルが設計だけを書き、実装と検証は下位モデルの担当に固定する。
上位モデルがコードを直接書くのは禁止、というルールです。
これを入れてから、上限に張り付く頻度がまったく変わりました。

絶対に削らないと決めているもの

最後に、いちばん大事なことを。
節約術を並べてきましたが、検証と網羅だけは絶対に削りません。

修正したら実際に動かして確かめる。
直す対象は1箇所ではなく、似た箇所を全部洗い出してから直す。
ここをトークン惜しさに省くと、バグの見逃しや直し漏れで結局やり直しになり、
かえって高くつきます。実体験です。

だからルールにも「精度を損なわない範囲で節約する」と明記してあります。
順番を間違えないこと。
節約はあくまで、品質を守ったうえでの2番目の目標です。

振り返ると、節約術の正体はどれも「仕組み化」でした。
その場の我慢ではなく、読む量・書く量・頭脳のグレードが自然と適正になるルールを作って、
AI 自身に守らせる。
上限に達して悔しい思いをした分だけ、仕組みが増えていった記録でもあります。