v2.31.2 の更新を当てた日の夕方、モデル選択の欄に Gemini 4 Carbon が low・medium・high の三段で並んでいるのを見て、私はしばらく手が止まりました。Google Cloud の資格情報でサインインしている環境だけに出る選択肢です。使ってみたい気持ちと、従量課金の請求が頭をよぎる気持ちが、同時にやってきました。
というのも、Carbon の API 価格はいまが導入価格で、11 月 30 日を過ぎると入力・出力とも単価が倍になると案内されているからです。壁紙アプリのストア説明文の多言語の見直しや、自分の Web サイトの不具合調査に Antigravity を使っておりますので、「1 回いくらか」が分からないまま high を選び続けるのは、さすがに胃が痛くなります。
そこで、手元の典型的な作業を二つに分けて、トークン数から費用を試算する小さなスクリプトを書きました。結論を先にお伝えすると、値上げそのものより、キャッシュ率と思考レベルのほうが請求額を大きく動かします。
まず事実を整理します — 何が変わり、何が変わらないのか
公式の発表と changelog で確認できた範囲を、表にまとめます（2026 年 11 月 13 日時点）。
| 項目 | 内容 | 出典 |
|---|---|---|
| Antigravity での提供 | v2.31.2（11/11）で、Google Cloud のアプリケーションのデフォルト認証情報（ADC）でサインインしたとき、Carbon を low / medium / high から選べる | Antigravity changelog |
| 導入価格（〜11/30） | 入力 $2.00・出力 $10.00（100 万トークンあたり） | Google の Carbon 提供開始の告知 |
| 通常価格（12/1〜） | 入力 $4.00・出力 $20.00（100 万トークンあたり） | 同上 |
| キャッシュ済み入力 | 入力単価の 95% 引き | 同上 |
| 思考トークン | 出力トークンとして課金 | Gemini API の料金ページの記載 |
一次情報は Antigravity の changelog と Gemini 4 Carbon の提供開始の告知 です。Google Cloud 側の 料金ページ には、エンドポイントによって単価がわずかに違う記載や、導入価格をクレジットの払い戻しというかたちで適用すると読める記載もあります。請求レポートを見るときは、払い戻し前の金額が先に表示される可能性を頭に置いておくと、慌てずに済むかもしれません。
一方で、サブスクリプションのプラン（Pro や Ultra）で使う場合の上限の考え方は、この値上げとは別の話です。プラン側の判断は Antigravity の料金と使用量 — 無料枠・Pro・AI Ultra の損益分岐 に書き残しています。
試算のスクリプト — 1 回の作業を 4 つの数字で表す
何を解決するスクリプトかというと、「この作業を Carbon でやったら、11 月と 12 月でそれぞれいくらか」を、手で電卓を叩かずに並べることです。入力するのは、入力トークン・出力トークン・思考トークン・キャッシュに乗る割合の 4 つだけにしました。
#!/usr/bin/env python3
"""Gemini 4 Carbon のセッション費用を、導入価格と通常価格で並べて試算する。"""
import argparse
# 単価は USD / 100 万トークン（2026-11-13 時点の公開情報。契約前に公式で再確認）
PRICES = {
"intro": {"input": 2.00, "output": 10.00}, # 〜2026-11-30
"standard": {"input": 4.00, "output": 20.00}, # 2026-12-01〜
}
CACHE_DISCOUNT = 0.95 # キャッシュ済み入力は入力単価の 95% 引き
def session_cost(p, input_tok, output_tok, thinking_tok, cache_ratio):
cached = input_tok * cache_ratio
fresh = input_tok - cached
cost_in = (fresh + cached * (1 - CACHE_DISCOUNT)) * p["input"] / 1e6
# 思考トークンは出力として数える
cost_out = (output_tok + thinking_tok) * p["output"] / 1e6
return cost_in + cost_out
def main():
ap = argparse.ArgumentParser()
ap.add_argument("--input", type=int, required=True, help="1 セッションの入力トークン合計")
ap.add_argument("--output", type=int, required=True, help="1 セッションの出力トークン合計")
ap.add_argument("--thinking", type=int, default=0, help="思考トークン合計")
ap.add_argument("--cache", type=float, default=0.0, help="入力のうちキャッシュに乗る割合 0〜1")
ap.add_argument("--per-month", type=int, default=20, help="月あたりのセッション数")
a = ap.parse_args()
for name, p in PRICES.items():
one = session_cost(p, a.input, a.output, a.thinking, a.cache)
print(f"{name:9s} 1回 ${one:6.3f} 月{a.per_month}回 ${one * a.per_month:7.2f}")
if __name__ == "__main__":
main()なぜこう書くかというと、エージェントの作業は 1 往復ではなく、同じファイル群を何度も読み直す往復の積み重ねだからです。入力トークンは往復ごとに積み上がり、その大部分は前の往復と同じ内容——つまりキャッシュに乗りうる部分です。単価表だけを眺めていると、この「同じものを何度も読む」構造が見えなくなります。
思考トークンを出力と分けて引数にしたのも同じ理由です。low・medium・high の違いは、ほぼこの数字の違いとして請求に現れます。
二つの作業で試算しました — 短い修正と、長い調査
トークン数は、私の作業の長さを思い浮かべて置いた仮の数字です。実測値ではありませんので、ご自身の請求レポートの数字に差し替えてお使いください。
- 作業 A: サイトの表示崩れを 1 か所直す短い修正。入力 6 万・出力 4 千・思考 6 千トークン、月 40 回
- 作業 B: ストア説明文の多言語版を横断して食い違いを洗い出す長い調査。入力 90 万・出力 3 万・思考 6 万トークン、月 8 回
| 条件 | 導入価格・月額 | 通常価格・月額 |
|---|---|---|
| A・キャッシュ 0% | $8.80 | $17.60 |
| A・キャッシュ 60% | $6.06 | $12.13 |
| B・キャッシュ 0% | $21.60 | $43.20 |
| B・キャッシュ 70% | $12.02 | $24.05 |
| B・キャッシュ 70%・思考を 3 倍（high 想定） | $21.62 | $43.25 |
表の数字は、上のスクリプトをそのまま実行した出力です。たとえば作業 B のキャッシュ 70% は次のように呼び出しています。
python3 carbon_cost.py --input 900000 --output 30000 --thinking 60000 --cache 0.7 --per-month 8
# intro 1回 $ 1.503 月8回 $ 12.02
# standard 1回 $ 3.006 月8回 $ 24.05最初、私は入力単価の $2 だけを見て「長い調査でも安いものだ」と考えていました。ところが作業 B では、入力の請求がキャッシュ次第で 3 分の 1 ほどまで縮み、逆に思考を high 相当に増やすと、その節約分がほとんど消えてしまいます。12 月の通常価格でキャッシュ 70% なら、導入価格でキャッシュなしの場合と近い金額に収まる——値上げ分は、使い方で吸収できる範囲にあったのです。
値上げを吸収できる条件と、できない条件
試算から引いた線引きを、三つに分けて書き残します。
吸収できるのは、同じ文脈を何度も読み直す長い作業です。 作業 B のように、大きなファイル群を開いたまま往復を重ねる作業はキャッシュが効きやすく、単価が倍になっても月額の伸びは抑えられます。会話を途中で何度も作り直すと、キャッシュの恩恵を自分で捨てることになります。
吸収しにくいのは、短い修正を数多くこなす作業です。 作業 A は 1 回が小さく、キャッシュに乗る部分も少なめです。単価の倍化がそのまま月額に出ます。ここは Carbon にこだわらず、軽いモデルへ振り分ける余地がいちばん大きいところです。
思考レベルの high は、作業の種類で決めます。 原因の見当がついていない調査には high の価値がありますが、手順の決まった修正に high を当てても、増えるのは思考トークンと請求額だけです。推論強度の選び方そのものは、速いはずのモデルが遅いとき、疑うのはモデルではなく推論強度です にもまとめています。
単価は Google が決め、キャッシュ率と思考レベルは私が決める。 値上げの日に慌てないために、自分で動かせる二つの数字のほうを先に見るようにしています。
自分の数字に差し替える手順
仮の数字のままでは判断に使えませんので、11 月のうちに実際の値を取っておくことをおすすめします。
- Carbon で、ふだんどおりの作業を 1 回だけ行います。
- Google Cloud コンソールの請求レポートで、対象プロジェクトを SKU ごとに分けて表示します。
- 入力・キャッシュ済み入力・出力の使用量を、その日の分だけ読み取ります。
- スクリプトの
--input--output--cacheに当てはめ、--thinkingは出力に含まれている前提で 0 にします。 - 月の回数を掛けて、12 月以降の見込みを出します。
手順 4 で思考を 0 にするのは、請求レポート上では思考トークンが出力と合わせて計上されると考えられるためです。二重に数えないよう、ここだけ気をつけてください。
請求の反映には時間差があるので、作業した翌日に見るくらいがちょうどよいと感じています。数字が出たら、短い作業と長い作業のどちらに Carbon を残すかを、表の上で決め直せます。
短い作業を軽いモデルへ逃がす基準を数字で詰めたい方は、Pro に回す件数を半分にしても、トークンは6割残っていた — モデル振り分けの基準を測り直す で、振り分けの閾値を測り直した記録を掘り下げています。まずは手元の作業 1 回分の数字を取るところから、始めていただければと思います。