AIの暴走でトークンを溶かした夜から｜個人開発者が「軽量モデル×外骨格スクリプト」で手に入れた止まらない自動化環境

---

1. 画面が固まり、数日間何もできなくなったあの夜のこと

「よし、あとはAIが自分でエラーを直して仕上げてくれるはずだ」

そう確信して画面から離れ、少し経ってから戻ったとき、ターミナルに並んでいたのは大量のエラーログと、無情にも「Quota Exceeded（利用枠超過）」を告げるAPIレスポンスでした。

自律型AIエージェントが、些細な構文エラーやファイルパスのズレを解消しようと、数十回にわたって自己修復ループを高速で回し続けていたのです。1リクエストごとに過去の長大なログを抱え込み、トークン消費量は雪だるま式に膨張。あっという間に無料枠・日次クォータの上限を使い果たしてしまいました。

その結果どうなったか。開発環境は完全に沈黙し、数日間にわたって何も手がつけられない状態に追い込まれました。

個人開発において、API制限による数日間の停止は手痛い打撃です。「自動化で作業を速くするはずが、自動化によって数日間の足止めを食らう」という本末転倒な現実を前に、私は深い反省と強い危機感を抱きました。

「気合や注意深さで見張るのには限界がある。仕組みそのものを変えなければ、何度でも同じ事故を繰り返す」

この手痛い失敗が、私の開発環境における「コスト最適化と評価設計」の原点となりました。

---

2. なぜ「賢いモデルに全部任せる」と破綻しやすいのか

多くの開発者がAIを導入する際、まずは最も賢いフラグシップモデルを選び、プロンプトひとつで全てを解決させようとしがちです。しかし、個人開発の自動化パイプラインにおいて、そのアプローチは構造的な脆さを抱えやすくなります。

賢いモデルは複雑な要件定義や抽象思考には欠かせません。しかし、ファイル操作やスクリプト実行といった日常タスクではトークン単価が高く、生成速度も相対的に重くなります。さらに、長大な履歴を抱え込むことで、コンテキストが肥大化し、必要な情報が埋もれる「Context Rot」の問題も起こりやすくなります。

この悪循環を断ち切るために導き出した結論が、「モデルの暴走可能領域をシステム側で狭め、外骨格（スクリプト）で囲う」 という設計思想でした。

---

3. トークンを溶かさない「4つの防衛アーキテクチャ」

現在、私の作業環境（036 Factory）で実際に稼働し、安定した成果を上げている具体的な防衛策は以下の4点です。

① モデルの階層化と軽量モデル・推論Low設定の固定

日々のコード編集、ファイル移動、フォーマット変換、定期バッチ処理には、最上位モデルを一切使いません。すべて「Gemini 3.8 Flash（Antigravity環境側での推論・thinking設定をLowに固定）」または「Gemini 3.1 Flash-Lite」相当の軽量モデルに物理的にルーティングしています。

公式の役割分担でも、Gemini 3.1 Flash-Liteは「大量のエージェントタスクやシンプルなデータ処理向け」と位置付けられています。定型タスクでは思考レベルを低水準に抑え、1リクエストあたりのコストを極限まで引き下げる。これだけで、同じ回数の作業を実行しても消費クォータの減り方はまったく別次元になります。

② 生ログの遮断と「要約ファクト」への圧縮

ターミナルの長大なビルドログ、Webページの生HTML、テスト結果のスタックトレースを、そのままLLMの入力に流し込むことを禁止しました。

私のケースでは、生データを丸ごと渡した際、1回のやり取りだけで 15,000〜30,000 トークン規模まで膨らむことがありました。そこで中間処理スクリプトを挟み、「処理の成否」「具体的なエラー行」「差分件数」といった最小限の要約ファクトだけにトリミングしてLLMへ渡す設計に改めました。

私の運用では、生ログを要約ファクトに変換したところ、1回あたりの入力を約800〜1,500トークンに抑えられ、元のログ投入時と比べて消費トークンを約90%減らすことができました。

③ 自律デバッグの「最大2手制限」という安全弁

AIがエラーに直面した際、自律的にコードを修正して再試行する回数を「最大2手まで」と厳格にルール化しました。

【自律デバッグの境界線】
1手目：単純ミスの修復（構文エラー・タイポ・引数指定・インポート漏れの解消）
2手目：アプローチの転換（別ライブラリの利用・代替関数への切り替え・迂回パスの選択）
3手目：【実行厳禁】即座に停止し、エラーファクトをそのまま人間に報告

なぜ「2手」なのか。科学的な普遍の最適解というより、私の運用では、2回試しても解決しないケースは、単純なコードミスよりも、ファイルの存在、権限、API仕様、実行環境などの前提条件を疑うべきケースが多かったからです。

前提が崩れている状態でAIに3手、4手と突撃させても、的外れな修正を繰り返してトークンを溶かす泥沼に入りやすくなります。「2手を上限とする安全弁」を自分で設定し、2手で止めて人間にバトンを渡す二層防御を敷くことで、暴走の芽を確実に摘み取れるようになりました。

④ 決定論的処理の外骨格化と機械的バリデーション

「軽量モデルを使うと、出力フォーマットの崩れやハルシネーションが起きるのではないか？」という疑問があるかもしれません。

その対策として、Markdownの記法整形、ファイル名の日付付与、画像の移動やリサイズなど、「ルールが決まっている作業」をLLMに推論させるのをやめました。これらはすべて、Pythonスクリプトなどの「外骨格（ハーネス）」としてツール化し、私の環境では、「1回コマンドを呼ぶだけ」で通常0.1秒程度、API消費ゼロで終わるように設計しています。

さらに、LLMが出力したMarkdownやデータに対しては、lint_blog_rules.py のような静的解析スクリプトを自動実行し、太字記法の崩れや必須タグの欠落を機械的に検知・自動修復（Auto-fix）します。プロンプトで「丁寧に書いてね」とお願いするのではなく、外骨格スクリプトで物理的に品質を保証するアプローチです。

---

4. 実際に運用してわかった「速い、止まらない」という確かな手応え

「軽量モデルに落として、ルールでガチガチに縛ったら、開発効率が落ちるのではないか？」

導入前はそんな懸念もありました。しかし、実際にこの環境で毎日開発を回してみて得られたリアルな実感は、まったく逆でした。

圧倒的に「早い」。そして「止まらない」。

私の環境では、推論Low設定と入力コンテキストの圧縮を組み合わせることで、通常の処理は1〜2秒程度で返ることが多くなりました。上位モデルの生成待ちストレスから解放され、リズムを崩さずにテンポよく開発が進みます。

そして何より、外骨格スクリプトと2手制限という強固なブレーキがあるため、「裏で勝手に暴走して利用枠を溶かしてしまうかもしれない」という心理的恐怖がゼロになりました。

「止まらない仕組み」を作ったことで、結果として日々の自動化パイプラインは極めて高い信頼性を獲得したのです。

---

5. まとめ：AIを賢く使うとは、AIを働かせすぎないこと

AIエージェントの進化を目の当たりにすると、つい「すべてを自律的に任せたい」という衝動に駆られます。しかし、個人開発における持続可能な自動化とは、AIに自由奔放に考えさせることではなく、「考えなくていい領域をいかにコードで固めてあげるか」 にあります。

• 賢いモデルに丸投げせず、軽量モデルを使い倒す。
• 生ログを遮断し、要約ファクトでトークンを大幅に削る。
• 自律修正は「2手」の安全弁で明確に線を引き、前提崩れを早期に検知する。
• 定型作業とフォーマット検査はスクリプト（外骨格）に一任する。

もし今、API制限の壁にぶつかっていたり、月末の請求書や利用枠の枯渇に怯えながら開発している方がいれば、ぜひ「賢いモデル頼み」から「軽量モデル×外骨格」への移行を試してみてください。

手元で小気味よく動き続ける「速くて止まらない」開発環境の快適さは、一度味わうともう戻れなくなります。

---