2026.09.18 2026.09.18

100万トークンを使い切る前に、料金表のどこで跳ねるかを見る

ゲンキ

100万トークンの文脈を扱えると聞くと、手元の資料を全部渡してしまいたくなる。データシート、部品表、過去の記録、取扱説明書。分割の手間が消えるなら、それだけで価値がある。

ところが料金表を開くと、単価の欄が一種類ではないことに気づく。標準、バッチ、高速、そして長い文脈。GPT-6 Astra 料金を実務で扱うなら、単価そのものより、この欄が切り替わる条件を先に押さえたほうがよい。切り替わりは、こちらが気づかないうちに起きる。

先に本記事の立場を書いておく。当サイトは実際の請求を確認しておらず、以下の試算はすべて公開されている単価から計算したものである。数値は2026年9月6日時点で開発元の料金表と API リファレンスから取った。為替は扱わず、米ドルのまま記載する。

GPT-6 Astra の単価表をそのまま置く
GPT-6 Astra の料金表で、長い文脈の行だけが規則から外れている
切り替わる条件は、入力272,000トークン
8,000トークン増やして、請求が倍以上になる
境界の手前に、余裕を持って止める
分けて投げれば、境界は踏まない
トークン数をどう見積もるか
100万トークン対応でも、資料に回せるのはその全部ではない
長く入れれば結果が良くなる、とも限らない
それでも境界を越える価値があるとき
キャッシュは何を安くするのか
バッチは半額だが、待てる仕事に限られる
高速は、速さを金で買う階層である
知識が4月末で止まっていることは、費用にも効く
3Dプリントの原価計算と、構造は同じである
見積りを立てるときの手順
本記事で確認できなかったこと
まとめ
出典・参考

忍者AdMax

GPT-6 Astra の単価表をそのまま置く

まず、公開されている単価を並べる。いずれも100万トークンあたりの米ドルである。

階層	入力	キャッシュ入力	キャッシュ書込	出力
標準	$10.00	$1.00	$12.50	$50.00
バッチ	$5.00	$0.50	$6.25	$25.00
高速	$20.00	$2.00	$25.00	$100.00
標準・長い文脈	$20.00	$2.00	$25.00	$75.00

表としては単純だが、見るべき点が3つある。バッチは標準のちょうど半額であること、高速は標準のちょうど2倍であること、そして長い文脈の行だけが規則的でないことだ。

その前に、列の意味を確認しておきたい。入力は、こちらが送った内容に対してかかる料金である。指示文、渡した資料、これまでのやりとり。送ったものはすべて数えられる。出力は、返ってきた内容にかかる料金で、単価は入力の5倍になっている。返答が長くなる用途ほど、出力の側が請求を支配する。

キャッシュの2列は、同じ内容を繰り返し送る場合のための仕組みである。一度送った内容を保存しておき、次回以降はその保存分を安く読み出す。保存するときにかかるのが書込、読み出すときにかかるのが読み込みだ。したがって、この2列は「同じものを何度送るか」によって意味が変わる。

階層の3つ、つまり標準とバッチと高速は、速さと待ち時間の違いである。同じモデルの同じ能力に対して、どれだけ待てるかで単価が変わるという構造になっている。バッチと高速の間には4倍の開きがあり、これは選ぶモデルを変えるのに匹敵する差である。

GPT-6 Astra の料金表で、長い文脈の行だけが規則から外れている

高速の行は、入力も出力も一律に2倍になっている。ところが長い文脈の行は、入力とキャッシュが2倍なのに対し、出力は $50.00 から $75.00 で 1.5倍である。

この非対称は、API リファレンスの本文にも明記されている。入力とキャッシュの単価が2倍、出力が1.5倍、という書き分けだ。

なぜこの点をわざわざ強調するかというと、要約された記事では最も潰れやすい箇所だからである。「長い文脈は倍額」と一行で書けば読みやすいが、出力は倍額ではない。出力の量が多い用途では、この差は請求額に直接効く。表を自分で開く価値がある典型例である。

丸められた情報は、たいてい安全な方向には丸まらない。この場合は出力を2倍と思い込むので過大に見積もることになり、実害は小さい。しかし逆向きの誤りもありうる。要約を信じて計算する習慣がつくと、どちらに転ぶかは運任せになる。単価のように結果が金額で出る項目は、原典を開く手間に見合う。

切り替わる条件は、入力272,000トークン

では、いつ長い文脈の行に切り替わるのか。条件は明快で、入力が272,000トークンを超えたときである。

そして、ここが最も重要な点になる。超えた分だけが高くなるのではなく、リクエスト全体が高い単価で計算される。API リファレンスは「リクエスト全体に対して」と明記している。

段階的に上がるのではなく、境界で一段跳ぶ。この構造を知らずに使うと、入力を少し増やしたつもりが請求は倍になっている、という事態が起きる。

8,000トークン増やして、請求が倍以上になる

具体的に計算してみる。以下はすべて公開単価からの試算であり、実際の請求ではない。

入力が272,000トークンちょうどの場合、標準の単価が適用される。

272,000 × $10.00 / 1,000,000 = $2.72

ここから8,000トークン、率にして3%だけ増やして280,000トークンにすると、長い文脈の単価に切り替わる。

280,000 × $20.00 / 1,000,000 = $5.60

3%増やしただけで、請求は2.06倍になる。増えた8,000トークン分の対価ではなく、全体の単価が変わったことによる差である。

出力も加えて比べておく。出力を10,000トークンとすると、標準なら $0.50、長い文脈なら $0.75 になる。合計すると $3.22 と $6.35 で、やはり倍近い。

境界の手前に、余裕を持って止める

この構造から出てくる指針は単純である。272,000トークンを目標にせず、余裕を持った上限を自分で決める。

理由は、入力のトークン数を事前に正確に読むのが難しいからだ。渡す資料が増減する、テンプレートが伸びる、前回のやりとりが積み上がる。運用しているうちに、気づかないまま境界を越えていることがある。

余裕をどれだけ取るかは用途次第だが、境界の直前を狙う運用は割に合わない。境界を越えた瞬間の損は、境界の手前で節約できる額よりずっと大きいからだ。上の試算でいえば、8,000トークン分を惜しんで境界を踏むと、節約しようとした額の何十倍も余計に払うことになる。

分けて投げれば、境界は踏まない

もうひとつの対処は、単純に分けて投げることである。

280,000トークンの資料を140,000トークンずつ2回に分ければ、どちらも境界を越えない。合計の入力量は同じでも、単価は標準のままである。

もちろん、分ければ済むとは限らない。資料の全体を一度に見せないと答えが出ない問いもある。ただ、実務で扱う仕事の多くは、そこまでの一体性を必要としていない。分けられるかどうかを最初に検討するだけで、費用の桁が変わる場面がある。

分け方にも向き不向きがある。素直なのは、資料を種類で分けることだ。仕様書を見れば答えが出る問いと、記録を見れば答えが出る問いは、たいてい別の問いである。同じ束にして渡していたものを、問いごとに必要な分だけ渡す形に組み替える。

一方で、分けたことによって答えの質が落ちる場合もある。前半と後半を照らし合わせないと分からない矛盾を探す、といった仕事は分割に向かない。この場合は素直に境界を越えることを受け入れ、そのかわり回数を減らす方向で調整する。境界を越えるリクエストを1日に何十回も投げる構成にはしない、ということだ。

トークン数をどう見積もるか

境界の話をする以上、自分の資料が何トークンになるかを知る必要がある。ところが、これは文字数から直接は決まらない。同じ文字数でも、内容によってトークン数は変わる。

したがって、実務での手順は「数えてから決める」になる。渡す予定の資料を実際に数え、その値を基準にする。感覚で「このくらいなら大丈夫だろう」と判断すると、境界の近くで外す。

数え方には注意点がひとつある。数えるべきなのは資料だけではないことだ。指示文、これまでのやりとり、道具の定義、返答の形式の指定。リクエストに乗るものはすべて入力に数えられる。資料だけを数えて余裕があると思っていたら、周辺で膨らんでいた、というのはよくある外し方である。

長く運用する場合は、実際の使用量を定期的に見返すのが確実だ。運用は必ず育つ。前置きが伸び、渡す資料が増え、履歴が積み上がる。始めたときの見積りは、三か月後には合っていないと考えておいたほうがよい。

手元のテキストが何トークンになるかは、AI トークンカウンターに貼り付ければ Claude / GPT / Gemini それぞれの概算とコストが同時に出る。境界の手前に収まっているかを判断するには、まずこの数字を取るのが早い。

100万トークン対応でも、資料に回せるのはその全部ではない

境界の話と混同しやすいので、上限の話も整理しておく。

仕様上の文脈長は1,050,000トークンで、最大出力は128,000トークンである。文脈長は入力と出力の合計なので、「100万トークン分の資料を投げられる」わけではない。出力の上限いっぱいまで使う想定なら、資料に回せるのは差し引き92万トークン前後という計算になる（この92万は公表値ではなく、公開されている2つの数字からの引き算である）。この点はGPT-6 Astra は何を変えたのか — 発表と一次情報だけで現在地を測る（2026-09-14 公開）でも触れた。

そして、上限まで使えることと、上限まで使うべきことは別である。90万トークン規模の入力は 272,000 の境界をはるかに超えているので、そのリクエストは丸ごと高い側の単価で計算される。入力とキャッシュが2倍、出力が1.5倍である。上限は技術的な制約であって、推奨値ではない。

長く入れれば結果が良くなる、とも限らない

費用の話とは別に、性能の側も見ておきたい。長い文脈から必要な情報を取り出せるかを測るベンチマークでは、256,000から512,000トークンの範囲で 100.0%、512,000から1,000,000トークンの範囲で 96.3% という値が公開されている。前世代はそれぞれ 91.5% と 73.8% だった。

長い範囲での取り出し能力は明らかに上がっている。ただし、これは必要な情報が入っていれば見つけられるという話であって、入れるほど答えが良くなるという話ではない。関係のない資料を足せば、その分の入力料金は確実に発生し、答えが良くなる保証はない。

渡す資料を絞る作業は、費用と品質の両方に効く。どちらか片方のためだけの手間ではない。

それでも境界を越える価値があるとき

ここまで境界を避ける話ばかり書いたが、越えたほうがよい場合もある。判断の基準を置いておきたい。

越える価値があるのは、分割によって答えの質が落ち、その落ち方が費用差より高くつくときである。たとえば、長い仕様書の全体を通して矛盾を探す作業。前半の記述と後半の記述を突き合わせないと見つからない種類の問題は、分けた時点で見つからなくなる。見つからなかった矛盾が後工程で顕在化する損失は、単価の差より大きいことが多い。

逆に、越える価値がないのは、単に渡すのが楽だから全部入れている場合である。どの資料が要るか考える手間を惜しんで全部を渡す。この選択は、手間を金で買っていることになる。買っている自覚があるならよいが、たいていは無自覚である。

判断のしかたとしては、一度だけ両方で試してみるのが早い。絞って渡した場合と、全部渡した場合で、答えがどれだけ変わるか。変わらないなら、絞った側が正解である。この確認は一度やれば済み、その後の運用にずっと効く。

キャッシュは何を安くするのか

繰り返し同じ前置きを送る用途では、キャッシュの単価が効いてくる。

標準の入力が $10.00 に対し、キャッシュから読む場合は $1.00 である。10分の1だ。毎回同じ指示書、同じ設計基準、同じ用語集を送っているなら、ここは大きい。

ただし、書き込む側には別の単価がある。キャッシュ書込は $12.50 で、通常の入力 $10.00 より高い。つまり、一度しか使わない内容を載せると、かえって高くつく。

判断の目安は回数である。書込に $12.50 を払って、以降 $1.00 で読めるなら、2回目以降で差が出る。繰り返し使う前置きだけを載せるという運用が、素直な結論になる。

この単価の構造は、運用の作り方にも影響する。前置きを毎回少しずつ書き換える構成にしていると、書き換えるたびに保存し直すことになりかねない。逆に、変わらない部分と変わる部分をはっきり分けて書く構成にしておけば、変わらない部分だけを保存の対象にできる。

具体的には、用語の定義、設計の基準、出力の形式といった固定的な内容を前に置き、その回ごとの資料や問いを後ろに置く。文章の構成としても読みやすくなるので、費用のためだけの工夫ではない。同じ内容を毎回違う順序で書かないという、単純な規律に落ちる。

バッチは半額だが、待てる仕事に限られる

バッチの単価は標準のちょうど半分である。入力 $5.00、出力 $25.00。割引としては大きい。

向いているのは、答えがすぐに要らない仕事だ。まとめて投げて、後で結果を受け取る。設計の候補を大量に生成しておく、記録をまとめて整形する、資料を一括で要約する。こうした作業は、数分後に答えが返る必要がない。

逆に、対話しながら進める作業には使えない。待てるかどうかが唯一の判断軸であり、待てるなら半額になる。自分の作業を「待てるもの」と「待てないもの」に仕分けるだけで、費用は下がる。

高速は、速さを金で買う階層である

高速の階層は、標準の最大2倍の速度に対して価格も2倍という設計になっている。速さと費用が同じ倍率で動くので、判断は分かりやすい。

時間に値段がついている作業でだけ使う、というのが妥当な線だろう。人が画面の前で待っている作業、締め切りが迫っている作業。逆に、夜間に流しておく処理を高速にする理由はない。

ここで前節と合わせると、階層の使い分けは自然に決まる。待てない仕事は高速、普通の仕事は標準、待てる仕事はバッチ。同じモデルでも、仕事の性質で4倍の幅がある。

注意しておきたいのは、速さの表記が「最大2倍」であることだ。常に2倍になるとは書かれていない。一方で価格のほうは、条件なしの2倍である。支払いは確定で、効果は上限つきという非対称がある。

したがって、高速を使うかどうかは「速くなるか」ではなく「速くなった分に値段をつけられるか」で決める。人が手を止めて待っている時間には値段がつく。夜間に流れている処理の時間には、たいてい値段がつかない。この線引きさえできていれば、迷う場面は多くない。

知識が4月末で止まっていることは、費用にも効く

見落とされやすい影響がひとつある。このモデルの知識は2026年4月30日で止まっている。したがって、それ以降の仕様や価格を扱わせるには、こちらから資料を渡す必要がある。

渡す資料は入力トークンとして課金される。つまり、新しい話題ほど入力が増え、費用が上がる。しかも、そういう話題ほど資料が長くなりがちだ。仕様書、リリースノート、価格表。

ここでも効くのは、渡す前に絞ることである。関係する箇所だけを抜き出して渡せば、境界も踏みにくくなる。全部渡して探させる運用は、楽だが高い。

3Dプリントの原価計算と、構造は同じである

この費用の考え方は、実は見慣れた構造をしている。

3Dプリントの原価を計算するとき、比例するものと比例しないものを分けた。材料費と電気代は造形量に比例するが、段取りの時間や失敗の損失は比例しない。同じように、AI の費用にも量に比例する部分と、境界で跳ねる部分がある。入力トークンの単価は比例するが、272,000の境界は跳ぶ。

比例する部分は、量を減らせば減る。跳ぶ部分は、量を減らしても境界を越えていれば意味がない。まず境界の内側に入れてから、量を削るという順序になる。この順序を逆にすると、削った労力が請求に反映されない。

原価を構造で捉える考え方は3Dプリントの原価を日本の電気代で計算し直す — 値付けの根拠を作る（2026-08-19 公開）にまとめてある。単価表の読み方としては、そのまま流用が利く。

見積りを立てるときの手順

以上を、着手前にやることとして並べ直す。

渡す資料のトークン数を数える。境界を踏むかどうかが最初の分岐になる
踏むなら、分けられないかを検討する。分けられれば単価は標準のままである
繰り返す前置きを切り出す。2回以上使うならキャッシュに載せる価値がある
待てる仕事を仕分ける。待てるならバッチで半額になる
上限を決める。回数か費用のどちらかで、止まる条件を先に置く

5番目は、繰り返し呼び出す構成を組むときに効く。うまくいかない処理ほど回数が伸びるので、放置すると最も価値の低い作業に最も金を使うことになる。この点は、大量に印刷する前に見積りを立てる話とよく似ている。段取りの考え方は大量印刷を前提に設定を決める — 時間・材料・失敗率の見積り（2026-09-02 公開）が近い。