月額サブスクのAIコーディングエージェント (LLMを定額で使うタイプのサービス) を使い始めると、たいてい最初にぶつかるのが利用枠の表示である。「今週の使用量」として出てくるのは、丸められた整数のパーセント1つ — 例えば 37 。金額は出ない。
この表示のままでは、実務で必要な3つの問いにどれも答えられない。
- いくら分の仕事ができるのか — 37 が$3なのか$30なのか分からないと、月額$20を払う価値を評価できない
- 失効までにあと何件進められるか — 週次リセットで余りが消えるタイプの枠では、使い切る計画を立てられない
- 枠は正しく消費されているか — 想定より減りが速いとき、測りようがなければ原因調査も始まらない
本稿は、整数のパーセントゲージだけを頼りに週次上限の金額 (cap) を$で確定する測定法をまとめる。対象は「累計消費を丸めた整数で表示するサブスク型のLLMサービス」全般で、Devin Pro (2026-09-06時点) で実測して手法を検証した。原理が分かれば道具はいらない — 自分の消費を小刻みに進めて、整数の繰り上がりを観測するだけである。
原理 — 繰り上がりは等間隔の固定点を跨ぐ
表示を式で書く。累計消費を s (自分の消費+他経路の外部消費の合計、$)、週次上限を cap ($) とすると、ゲージの整数 g は
g = round(100 × s / cap)
に従う (丸めmodeが四捨五入であることの確認方法は後述)。g が n から n+1 に繰り上がる (以下、この瞬間を flip と呼ぶ) のは、100s/cap が n+0.5 を跨いだとき、つまり s が
B_n = (n + 0.5) × cap / 100
を超えた瞬間である。ここで重要な性質が2つ出る。
性質1: 境界 B_n は$空間の等間隔格子である。 隣接する境界の差はどの n でも
B_{n+1} − B_n = cap / 100
で一定である。この間隔は cap の100分の1そのものであり、外部の事情に一切依らない。
性質2: 外部消費はオフセットをずらすだけで、間隔を壊さない。 チームの別メンバーの消費や別マシンの仕事が s に混ざると、s = 外部消費 x + 自分の消費 m となる。flip は x + m が境界を跨ぐときに起きるので、x が増えると「どの m で flip が起きるか」はずれる。しかし境界同士の間隔は変わらない。隣接する2つの flip の間の m の差は、x の値がなんであれ cap/100 に等しい。
これが測定可能な理由である。自分の消費 m を小刻みに進め、flip を2回以上観測して、隣接 flip 間の m の差 Δ を取れば
cap = 100 × Δ
が得られる。flip が3つ観測できれば Δ が2組取れ、互いに一致することで測定の自己検証になる。
単発のflipでは確定できないことにも触れておく。flip を1回だけ観測しても、「自分の消費がどの境界を跨いだか」が分からないため、cap の取り得る範囲が区間にしかならない。外部消費 x の分だけ解がずれるからである。連続 flip の差分はこの曖昧さを構造的に消す — 計測器が「丸められた整数のゲージ1つ」しかない状況で使える一般形と言える。
手順
前提として、自分の呼び出しの消費$を呼出単位で記録できること (Devin CLIならローカルの sessions DB、他のCLIならログやAPIのusage欄)。記録が呼出単位で取れない場合、モデル単価×トークン数の見積もりで代用できるが、step の幅が荒くなる分、flip の bracket も荒くなる。
- 機械側の消費記録を開く — 自分の呼出ごとに$が追える状態を用意する
- 最安帯のモデルで2呼ずつ歩く — 1回のstepが cap の100分の1より小さくなるよう、最も安いモデルを短いプロンプトで呼ぶ。ゲージの整数が1ずつ上がることを確認しながら進む (2つ以上一気に上がったら、その区間は step が大きすぎたか、外部消費が動いた証拠)
- flipをbracket化する — ゲージの整数が上がる直前と直後の、自分の累計消費$のペア (直前$, 直後] を記録する。中点をその flip の推定位置とする
- 隣接flipの中点差から cap を出す — Δ = 隣接flipの中点差として cap = 100 × Δ。間に整数が1つ飛んでいる (例: 9→11) 場合は2境界分なので Δ / 2 を使う
- 内部整合を確認する — 各 flip の中点位置から逆算した外部消費 x が、全ての flip 対で同じ値に揃うことを確認する。揃わない区間はスキャン中に外部消費が動いた証拠なので、その区間を捨てて測り直す
説明のための数値例 (仮の値) を示す。3つの flip を bracket として捕獲できたとする。
| flip | 直前の自分消費$ | 直後の自分消費$ | 中点 |
|---|---|---|---|
| A (n→n+1) | 0.11 | 0.12 | 0.115 |
| B (n+1→n+2) | 0.21 | 0.22 | 0.215 |
| C (n+2→n+3) | 0.31 | 0.32 | 0.315 |
中点差は A→B が 0.100、B→C が 0.100 で一致している。よって cap = 100 × 0.100 = $10.00 (週次)。2組が一致している時点で、この区間の外部消費は一定だった、つまり測定は汚染されていない、という検証まで同時に取れている。
落とし穴 — 実測で踏んだ3つ
1. ゲージの集計lag。 ゲージは呼出完了と同時に更新されない。数秒〜数十秒の集計遅延があり、急いで連続呼出した直後に読むと表示は古い。これは最も質の悪い罠で、cap を過大に見せる方向にだけ効く — 遅れて見えている消費をまだ消えていないものとして追加で呼んでしまうためである。実測では、連続呼出を終えて数十秒後の読みは2〜3割未反映だった。対処は単純で、呼出を止めて1分以上待ってからゲージを読む。手順2の「2呼ずつ」はこの待ち時間を発生させるための設計でもある。
2. 丸めmodeの確認。 表示が四捨五入か切捨てかで、境界の位置 (n+0.5 か n か) が半分ずれる。丸めmodeの誤認は cap の推定を丸ごとずらすので、先に確認しておく。便利なのは階層の違うゲージの同時観測である。週次ゲージと日次ゲージがあり、日次枠が週次枠の半分 (週の初日に日次上限いっぱい使うと週ゲージが半分になる) のサービスなら、「日次の整数が切捨て解釈と矛盾する組合せ (日が 11 のとき週が 6 など、切捨てなら週の丸めは日以上に切り上がらないはず)」が観測できれば四捨五入と確定できる。確認できないサービスでは、丸めの違いは step を細かくして相殺できる (bracket が境界を含む限り、境界位置の半stepぶんのずれは中点差には乗らない)。
3. baselineに外部消費が混ざる。 スキャン開始時のゲージ値や「今どの境界にいるか」は、外部消費の分だけ不定である。だからこれらを使わない。情報を持つのは flip 同士の差分だけである。手順5の整合確認は、この前提がスキャン区間内で成立していたことの事後証明になっている。
実測結果 — Devin Proに適用した場合
Devin Pro (月額$20のプラン、CLIは v3000.6.14、検証日 2026-09-06) にこの手法を適用した。Devinの日次・週次クォータとプラン体系は公式docsのbillingページに整理されている (2026-09-07時点)。結果を帯で示す。
- 週次上限: $30台 — 月額の数倍分の仕事が週で回る計算になる
- 日次上限: 週次の半分 — 週の頭に日次上限を使い切ると週ゲージが半分になる設計
- 測定コスト: $1未満・100呼強・所要1時間弱 — 最安帯モデルを2呼ずつ歩いた
数値の取り扱いについて但し書きを付す。まず上限は提供側の表示単価 (rate-card) 換算であり、providerへの実請求額と一致する保証はない。次に、プランやモデル単価の改定で cap 自体が変わる — だから「どこかに書かれた値」を信じるより、自分の使う時点で自分で測る方が確からしい。本稿では点確定値と生の測定logは省略した (使い切り計画には帯で十分であり、正確な値が必要な読者は上の手順で自分の環境の値を取れる)。
この手法が効く条件と効かない条件
- 効く: 累計消費を整数%で表示するサブスクAIサービスで、(a) 自分の呼出の消費$が呼出単位で記録できる (b) ゲージが分単位で更新される
- 効かない: 消費が%でなくACUのような独自単位のみで、$換算のレートが非公開の場合 (ただし「独自単位のcap」なら同じ手順で測定できる — Δ が cap の100分の1である構造は単位に依存しない)
- 精度の限界: bracket の幅 = 1 step の消費$。step を細かくすれば精度は上がるが、所要時間とゲージlag待ちが増える。実用上は cap の100分の1の精度で十分である
まとめ
整数%のゲージしかないサブスクAIの週次利用枠は、次の観察で$確定できる。自分の消費を小刻みに進め、整数の繰り上がり (flip) を2回以上観測し、隣接flip間の消費差に100を掛ける。 外部消費の混入は境界のオフセットをずらすだけで間隔を壊さないため、チームで共有しているアカウントでも成立する。集計lag待ちと丸めmode確認という2つの前提を守れば、コスト$1未満・1時間で自分の環境の値が取れる。
枠の実態が分かると、コスト削減の基本である使い切りの計画 (何をいつ回すか) と、枠が想定より速く減る異常の検知が初めて数字で立てられる。サブスクAIの費用対効果を議論する土台の測定として使えるはずである。
なお、サブスクAIの実測評価・日本語環境への導入前確認はJapan LaunchOpsで請け負っている。相談は日本語AI評価のページで受け付けている。