AIの利用制限やトークン爆食いをどう防ぐか｜個人開発者が行き着いたモデル使い分けとObsidian・MCP連携の知見

---

1. 「便利だから」と任せていると、あっという間に訪れる制限の壁

コードの生成、長文の要約、Obsidianに溜まった日々のメモの整理。

AIを単なるチャット相手ではなく「開発や思考の相棒」として本格的に日常業務へ組み込むようになると、作業効率は劇的に向上します。手作業では何時間もかかる作業が一瞬で下書きされ、自分専用の知恵袋が手元にある心強さは、一度体験すると手放せません。

しかし、仕組みを整えて活用頻度が高まれば高まるほど、必ずと言っていいほどぶつかるのが「トークンの急激な消費」と「API利用制限（レートリミット）」の壁です。

「気づいたらその日の利用枠の上限に達してしまい、作業が中断してしまった」
「裏で回していた自動スクリプトがエラーを深追いし、短時間で大量のリクエストを消費していた」

Google AI Studioをはじめとする各種LLMサービスでは、無料枠や開発者向けの利用枠が提供されていますが、個人開発者やスモールチームにとって利用リソースは有限です。「便利だからとりあえず全部AIに読ませる」「常に最新・最高峰のモデルで処理させる」という無計画なアプローチを続けていると、この枠はあっという間に枯渇します。

この問題を回避し、日々の作業を快適かつ持続可能なものにするために、現場での試行錯誤を経て辿り着いた「3つの省エネ運用設計」についてまとめました。

---

2. 対策①：モデルの「役割分担（Tiering）」を徹底する

最も効果が大きく、かつすぐに導入できるのがモデルの明確な使い分けです。

世の中のトレンドを見ていると、「常に最新のフラッグシップモデルや大型の推論モデルを使うのが正解」のように思えがちですが、日常のタスクの多くはそこまでの推論深度を必要としていません。

表層の「対話」と裏方の「バッチ」を分ける

例えば、エディタ上で人間とリアルタイムに議論を交わす場面では、文脈を鋭く捉えつつも推論レベルを必要最小限（thinking_level=low など）に設定したバランスの良いモデルを選びます。

一方で、深夜にObsidianの過去ノートを巡回して関連トピックをリストアップしたり、定期的にテキストの差分をチェックするようなスクリプトでは、高ボリューム処理に特化した超軽量なFlash-Lite系モデルを明示的に指定します。

さらに重要なのは、「なんでもかんでもAIに判定させない」 という規律です。日付のフォーマット確認やMarkdownの構文チェックなどは、数十行のPythonスクリプトや正規表現で動かした方が、トークン消費は完全にゼロで済み、速度もミリ秒単位で完了します。

---

3. 対策②：Obsidian連携と「MCPツールの運用オーバーヘッド」に配慮する

Obsidianを「第二の脳」として育てている方ほど陥りがちなのが、「ノートをそのまま全部LLMのプロンプトに流し込んでしまう」 という失敗です。また、最近普及が進むMCP（Model Context Protocol）の扱いにも留意すべきポイントがあります。

① MCPツールの常駐とオーバーヘッド

MCPは外部ツールやノートをAIに操作させられる便利な仕組みです。ただし、利用するクライアントやエージェントの実装によっては、接続されているツール群のスキーマ情報が毎回のプロンプト送信時に付加され、無視できないオーバーヘッドになる場合があります。

「頻繁に使わないツールは必要な作業時のみ接続する」「LLMによる判断が不要な定型巡回・同期バッチは、MCPを介さず独立した軽量Pythonスクリプトとして処理する」という切り分けを意識することで、ツール定義によるコンテキストの圧迫を防ぎやすくなります。

② Obsidianノートの「3段階インプット」

近年のLLMは長大なコンテキストを扱えますが、Vault内のMarkdownを丸ごと流し込むと、トークン消費が増えるだけでなく、情報量が増えすぎることによって重要な情報がコンテキストの中で埋もれ、回答品質が低下する「Context Rot（文脈の希薄化）」が起こりやすくなります。

そのため、現場では以下の3段階による絞り込みを実践しています。

【第1段階：インデックス・MOCの照合】
ノート名やタグ、MOC（Map of Content）の一覧から、
今回関連するファイル群（上位3〜5件）を特定する。
↓
【第2段階：Frontmatterと要約の読み込み】
ファイルの全文ではなく、先頭のメタデータや「TL;DR（記事の要約）」だけを渡し、
文脈が合致しているか確認する。
↓
【第3段階：該当セクションのみの抽出注入】
確信が持てた部分だけ、H2〜H3単位のセクションを切り出してプロンプトに注入する。

この段階的アプローチを採ることで、AIに読み込ませるトークン量を大幅に圧縮でき、同時に回答のピントが劇的に合致しやすくなります。

---

4. 対策③：自律ループを縛る「2手上限」の運用ルール

AIに自律的なタスク実行（ツールの呼び出しやスクリプトの修正）を任せる場合、最も警戒すべきは「エラー解決のための無限試行ループ」です。

スクリプトのエラーが出た際、AIが自動で「コード修正 ➔ 実行 ➔ 再エラー ➔ 別のアプローチで修正 ➔ 再実行」を繰り返す仕組みは一見便利ですが、歯止めがないと、短時間で大量のリクエストを消費してしまいます。

なぜ「2手」を上限としているのか？

私が「最大2手（1回の修正と1回の再試行）」を自律デバッグの境界線にしているのは、2回試して直らなかった場合、同じエラーをAI自身に局所修正させ続けるよりも、前提条件や設計を人間が見直した方が圧倒的に早いと判断しているからです。

これはAI全般に当てはまる普遍的な最適値ではありません。あくまで私の個人開発環境において、AIが表層的なエラーメッセージに引きずられて別の箇所を破壊するのを防ぎ、「自動修復をどこで打ち切るか」を決めた運用上の安全弁です。

【自律デバッグ枠の運用ルール】
スクリプトのエラーや構文ミスの発生時、同一セッション内でのAIによる自己修復は 「最大2手まで」 とする。3手以上の深追いは行わず、エラーの客観的事実のみを人間に報告して判断を仰ぐ。

私の運用では、AIに下準備や初動対応を任せ、前提の見直しや最終判断は人間が担うという二層防御を仕組みとして敷いています。

これこそが、不意の制限到達による作業中断を防ぎ、最もストレスなく日常開発を続けるための知恵だと実感しています。

---

5. まとめ：道具の特性を理解し、長く付き合える関係をつくる

AIの性能向上に伴い、私たちは「何でもAIに任せられる」ような感覚を持ちがちです。

しかし、実際の現場で頼れる相棒として機能させ続けるためには、限られた計算資源（トークンやレートリミット）を意識し、適材適所の設計を行う冷静さが欠かせません。

• 頭脳の使い分け: 対話には中核モデル（thinking_level=low など）、裏方のバッチには超軽量モデルを割り当てる。
• オーバーヘッドへの配慮: MCPツールの常駐を見直し、Obsidianノートはセクション単位で絞り込む。
• 境界線の明示: AIの自律試行は「2手」を安全弁として止め、最後は人間が手綱を握る。

道具の得意・不得意を見極め、無駄のない仕組みを整えること。それによって初めて、AIは日々の開発や思考を静かに、かつ力強く支え続けてくれる存在になります。

---