🐋

Claude Codeを寝てる間に動かしたい。でもコストが怖いのでproxy/routerを挟む話

に公開
AI
proxy
コスト管理
Claude Code
byok
tech

はじめに

Claude Code、便利ですよね。

「このコードベースをリファクタしておいて」と投げて寝る。
朝起きると、ちゃんと進んでいる(ことが多い)。

最近は Cursor、Cline、Roo Code、Windsurf も含めて、
寝てる間や席を外している間に AI に作業を任せるスタイルが、
個人開発でも当たり前になってきた感じがあります。

ただ、長く使えば使うほど、ひとつの違和感が出てきました。

便利なのは間違いない。
でも、今いくら使っているか、見えてなくないか?

この記事は、その違和感の整理と、
「proxy / router を挟む」というアプローチについての話です。

怖さの正体

「便利なのに怖い」と感じるとき、たいてい正体は 見えにくさ です。

具体的には、こんな感じだと思います。

  • 1 回のセッションでどれくらい使ったか、ぱっと分からない
  • サブスク利用では 5 時間制限・週間制限、API 利用では従量課金の上限が気になってくる
  • API 経由で使うと、ツール側・案件側では合計コストが見えにくい
  • 寝ている間に動かしていると、止めどころが分からない
  • どのモデルが、どれくらい消費しているのかも、雰囲気でしか把握していない

「壊れているわけではない」けれど、「見えていない」。

この 見えてなさ が、寝てる間運用との相性が一番悪いんです。

正直な体験談

正直に言うと、Claude Code で「請求が爆発した」みたいな話はありません。

ただ、実際に使っていて一番大きいと感じたのは、
後から判断できることでした。

「あのプロンプトで、これくらい使っていたのか」
「あのループで、思ったよりコストが膨らんでいたのか」
「逆に、この作業はこれだけしか使っていなかったのか」

こういうことが、後から数字で見える。

これは単なる節約の話ではありません。

どのプロンプトが重いのか。
どの作業はコストに見合っているのか。
どのループは早めに止めるべきだったのか。
どのモデルやプロバイダーなら十分だったのか。

そういう判断材料が残ること自体が、
AI エージェントを長く使ううえでかなり重要だと感じています。

怖いのは、1 回の金額ではありません。

見えないまま使い続けて、
あとから何も振り返れないことです。

だから僕は、Claude Code や各種ツールに API キーをそのまま持たせるだけではなく、
proxy / router を 1 枚挟んで、
使用量・上限・ログ・停止条件を自分側で握る構成を考えるようになりました。

proxy / router を挟むという考え方

ざっくり、こういう構成です。


Claude Code (Cursor / Cline 等)
        ↓
   proxy / router
        ↓
OpenAI / Anthropic / Gemini / DeepSeek …


Claude Code はそのまま使います。
ただし、リクエストの宛先を 自分の proxy / router に向ける だけ。

Claude Code の場合は、ANTHROPIC_BASE_URL のような設定で、
リクエスト先を proxy / gateway に向けられます。

一方で、Cursor / Cline / Roo Code など OpenAI 互換 API を設定できるツールでは、
base URL と API キーを差し替える形で同じような構成にできます。

これを挟むと、何が嬉しいのか。
ここからが本題です。

proxy / router を挟むと何が嬉しいのか

1. 上限を自分側で持てる

一番分かりやすい価値です。

  • API キー単位で「月にいくらまで」と決める
  • 上限に達したら、リクエストを止める
  • 上限が反映されるまでのラグを短くする

OpenAI などのプロバイダー側にも上限機能はありますが、
反映まで時間がかかったり、設定の粒度が合わなかったりします。

proxy / router を自分で持っていれば、
「自分のルール」で止められる。これが大きいです。

2. プロンプトごとの使用量が見える

リクエスト単位でログが残ります。

  • どのモデルを使ったか
  • 入力 / 出力トークン
  • かかった金額(概算)
  • 何時何分に走ったか

「今月いくら使ったか」だけでなく、
**「どのリクエストが重かったか」**が後から追えるようになります。

寝てる間に動かしているなら、これは大事です。
朝起きてログを見て、変な動きをしていないか、目で確認できる。

3. プロバイダー別に実コストを比較できる

OpenAI / Anthropic / Gemini / DeepSeek。

それぞれ、得意分野も価格も違います。
ですが、自分のワークロードで実際に走らせたときに、
どのプロバイダーが一番コスパが良いかは、使ってみないと分からない。

proxy / router を通して同じワークロードを別プロバイダーに振ると、
実コストの比較ができるようになります。

「DeepSeek の方が安いらしい」ではなく、
「自分の使い方だと、月いくら違う」が出せるようになる、ということです。

4. AI 利用料を「案件原価」として見えるようにできる

ここが、個人的には一番面白いと思っているところです。

API キーを 案件ごと / 顧客ごとに分けて発行しておくと、
proxy / router 側で、それぞれにかかった利用料が分けて見えるようにできます。

  • 「この案件、AI 利用料込みで採算が合っているか」
  • 「このお客さん向けの自動化、今月どれくらい使ったか」
  • 「次回の見積もりに、どれくらい乗せるべきか」

こういう判断材料が、後付けの感覚ではなく、実数字で出てくるようにできる。

これは、業務で AI を使うときには地味にすごく効きます。

AI の利用料を、ただの経費ではなく、案件ごとの原価として見えるようにする。

工夫次第で、こういう運用に持っていけるのが、
proxy / router を挟むことの一番大きな価値だと思っています。

5. 次の使い方・次の請求に反映できる

1〜4 がそろうと、

  • 「この使い方は割に合わないからやめる」
  • 「このモデルに切り替える」
  • 「この顧客向けには値上げをお願いする」
  • 「ここはキャッシュを入れる」

といった、次のアクションが取れるようになります。

逆に言うと、これらが見えていないと、
「便利だった気がする」で終わってしまう。

BYOK は「無料化」ではなく「管理を自分側に戻す」こと

proxy / router の話とセットで出てくるのが BYOK
(Bring Your Own Key)です。

自分のプロバイダー API キーを、自分のツールやサービスに登録して使うやり方ですね。

「サブスクで縛られず、従量課金で必要な分だけ払える」
という説明をよく見ますが、それだけだと半分しか合っていないと思います。

BYOK の本質は、コストの管理責任を自分側に取り戻すことです。

  • 月額を払えばよい、ではなく、自分で上限を持つ
  • 提供者の制限に従う、ではなく、自分のポリシーで止める
  • 値上げを待つ、ではなく、自分でプロバイダーを切り替える

これは「制限を抜け道的に回避する」という話ではなく、
自分で使う API 利用料を、自分で管理できる状態にするという話です。

ただし便利と引き換えに、責任が増える話です。
だからこそ、proxy / router での見える化と上限管理がセットで必要になります。

「BYOK = 管理を自分側に戻す」と捉えると、
proxy / router を挟む意味がきれいにつながります。

24 時間運用で必要になるもの

寝てる間運用、24 時間運用を視野に入れると、
最低限こういうものが必要になってきます。

  • リクエスト 1 回あたりの上限(暴走時の最大被害額)
  • 1 日 / 1 ヶ月の累計上限
  • 案件別 / API キー別の上限
  • 異常時に新規リクエストを止める仕組み
  • 上限到達時の通知
  • 後から振り返れる使用量ログ

「これらを全部、自分のコードの中で書く」のは正直しんどいです。

特に、プロバイダーをまたいで同じルールを適用するとなると、
実装量も増えるし、テストもしんどい。

「アプリ層で全部やる」のではなく、
proxy / router の層に寄せる方が、結果的に楽になります。

ちなみに、僕がやっていること

ここまで書いてきたような「上限・ログ・比較・案件原価」を、
自分の運用でまとめて見たかったので、
この proxy / router 層を自分で作りました。

qzira という BYOK 型の AI API ゲートウェイです。

  • OpenAI / Anthropic / Gemini / DeepSeek の API キーを登録
  • qzira 経由で叩く
  • API キー単位で予算上限を設定 → 定期チェックで上限超過を検知し、以降の新規リクエストを止める設計
  • 使用量はログとして残るので、後から振り返れる

API キーを 案件ごと / 顧客ごとに発行して使えば、
「4. AI 利用料を『案件原価』として見えるようにできる」も、
工夫次第で運用に乗せられると思います。

これが唯一の正解だとは思っていません。
OSS の選択肢もありますし、自分でゼロから書くのもアリです。

ただ少なくとも、僕の「気づいた時には地味に積み上がってた」は、
このレイヤーを 1 枚挟むことでだいぶ楽になりました。

Claude Code から使う場合は、ANTHROPIC_BASE_URL を qzira に向ける形で試せます。

無料プランもあるので、
「自分の使い方だと、どれくらい見えるようになるのか」
を一度触ってみてもらえるとうれしいです。

まとめ

  • Claude Code を寝てる間 / 24 時間動かすのは、便利だけど 見えにくい
  • 怖いのは 1 回の金額ではなく、あとから振り返れないこと
  • proxy / router を 1 枚挟むと、上限・ログ・比較・案件原価・次の改善が手に入る
  • BYOK は「無料化」ではなく「管理を自分側に取り戻す」こと
  • AI の利用料は、ただの経費ではなく、案件ごとの原価として見えるようにする

「賢い AI を選ぶ」だけでなく、
「動かしたあと、何を測るか」を決めることが、
寝てる間運用との付き合い方として大事なんじゃないかと思っています。

Discussion