GPT-6 Astraは、APIで1,050,000トークンのコンテキストウィンドウと最大128,000トークンの出力に対応しています。
数字だけを見ると「PDFを何冊でもまとめて入れられる」「巨大なコードベースを丸ごと読ませられる」と感じますが、実務では容量だけで判断するとコストと精度の両方で損をしやすくなります。
結論から言うと、100万トークンは“全部入れるための枠”ではなく、“必要なら非常に大きな作業領域を確保できる枠”と考えるのが適切です。
特にGPT-6 Astraは、入力が272Kトークンを超えるとAPIの長文料金が適用され、原則としてそのリクエスト全体の入力・キャッシュ料金が2倍、出力料金が1.5倍になります。
大量資料を扱うなら、全文投入、分割処理、File Searchなどの検索型処理を使い分けることが重要です。
この記事では1.05Mコンテキストを日本語文書・PDF・コード量の感覚に置き換え、272Kを境に料金がどう変わるのかを具体例で整理します。
OpenAI公式のGPT-6 Astraモデルページでは、コンテキストウィンドウは1,050,000トークン、最大出力は128,000トークンとされています。
ここで注意したいのは、コンテキストと最大出力は同じ意味ではないことです。
コンテキストウィンドウは、モデルが1回の処理で参照できる会話履歴、指示、ファイル内容、ツール結果などを含む作業領域です。
一方、128Kはモデルが返せる最大出力量です。
したがって「1.05M入力して、さらに128Kを必ず返せる」と単純に考えるのではなく、APIの仕様や実際のリクエスト構成、推論トークン、ツール利用を含めて余裕を持たせる必要があります。
また、1.05Mという上限まで毎回使う必要はありません。
短い質問や数十ページの資料であれば、巨大コンテキストの恩恵より、必要な情報だけを整理して渡す方が速く、安く、検証もしやすいケースが多くなります。
トークン数を「日本語○文字」「PDF○ページ」「コード○行」と固定換算することはできません。
日本語と英語では分割方法が異なり、PDFも文字密度、表、画像、OCRの有無で消費量が変わります。
コードも言語、コメント量、識別子の長さによって差が出ます。
そのため、実務では次のように“幅”で考えるのが安全です。
・日本語文書：数十万〜100万文字級でも、内容や記号の多さでトークン数は大きく変動
・一般的なテキスト中心PDF：数百〜千ページ級に届く場合があるが、ページ密度によって大差
・画像・図表中心PDF：画像入力やOCR処理が加わるため、ページ数だけでは判断できない
・コードベース：数十万行規模でも言語やファイル構成次第で大きく変わる
重要なのは、アップロード前に「ページ数」ではなく、可能なら実際のトークン数を計測することです。
API利用ではトークナイザーや使用量情報を確認し、272K境界を超えるかどうかを事前に把握すると料金設計がしやすくなります。
GPT-6 Astraの標準API料金は、100万トークンあたり入力10ドル、キャッシュ済み入力1ドル、キャッシュ書き込み12.50ドル、出力50ドルです。
さらにOpenAI公式モデルページでは、入力が272Kトークンを超えるプロンプトについて、入力とキャッシュ関連料金が2倍、出力料金が1.5倍となり、その倍率が“リクエスト全体”に適用されると説明されています。
つまり、272Kを1トークンだけ超えた部分だけが高くなる段階課金ではありません。
境界を超えたリクエスト全体が長文料金になる点が重要です。
標準時と272K超の目安は次の通りです。
標準：入力 $10 / 1M、cached input $1 / 1M、cache write $12.50 / 1M、出力 $50 / 1M
272K超：入力 $20 / 1M、cached input $2 / 1M、cache write $25 / 1M、出力 $75 / 1M
なお、製品・実行環境によって例外があります。
OpenAIの料金案内では、CodexでGPT-6 Astraを使う場合、272K超の長文コンテキスト追加倍率が適用されない例外が案内されています。
API、ChatGPT Work、Codexを同じ料金条件だと思い込まないことが大切です。
ここでは分かりやすく、キャッシュなしの入力と20Kトークンの出力を想定します。ツール料金などは含めません。
100K入力＋20K出力：
入力1.00ドル＋出力1.00ドル＝約2.00ドル
270K入力＋20K出力：
入力2.70ドル＋出力1.00ドル＝約3.70ドル
500K入力＋20K出力：
272K超なので入力10.00ドル＋出力1.50ドル＝約11.50ドル
1M入力＋20K出力：
入力20.00ドル＋出力1.50ドル＝約21.50ドル
この差を見ると、272K付近では「あと少しだから全部入れる」が必ずしも合理的ではありません。
例えば280Kの資料を、そのまま1回で処理するのか、不要部分を除いて270K以下にするのかで料金体系そのものが変わります。
ただし、分割すれば必ず安くなるわけでもありません。
同じ共通指示や資料を何度も送り直せば、合計入力が増えるからです。
繰り返し利用する情報はPrompt CachingやFile Searchを組み合わせた方が効率的な場合があります。
1.05Mコンテキストの価値は「大量の情報を保持できること」であり、「大量に入れるほど回答精度が自動的に上がること」ではありません。
長文では、モデルが必要な記述を見つける検索能力、複数箇所の関係を正しく結ぶ能力、古い情報と新しい情報を区別する能力が重要になります。
不要な資料や重複した資料を大量に入れると、むしろ判断対象が増え、検証しづらくなります。
特に社内規程、契約書、調査資料、コードベースでは、次の問題が起きやすくなります。
・同じテーマの旧版と新版が混ざる
・似た名前のファイルを取り違える
・重要な例外条項が大量の本文に埋もれる
・回答はもっともらしいが参照箇所が違う
・巨大入力のたびにコストが発生する
そのため、長文処理では「入れられる量」と「正しく探し出せる量」を分けて考える必要があります。
全文投入が向くのは、文書全体の関係性を一度に見る必要があるタスクです。
例えば複数契約書の矛盾検出、巨大コードベースの横断的な依存関係調査、長い研究資料群から共通論点を抽出する作業などです。
一方、章ごとの要約、ファイル単位の分類、定型的な情報抽出は分割しやすい作業です。
独立して処理できるなら、50K〜200K程度のまとまりに分け、最後に統合する方が失敗箇所を特定しやすくなります。
判断基準は次の３つです。
全文投入：
全体関係の把握が必要／単発処理／入力コストを許容できる／一括で整合性を見たい
分割処理：
各部分が独立／途中結果を検証したい／再実行範囲を小さくしたい／並列化したい
検索型：
同じ資料を繰り返し参照／質問ごとに必要箇所が違う／資料が増え続ける／毎回全文を送るのが非効率
File Searchは、登録したファイル群から質問に関係する情報を検索し、必要な部分をモデルへ渡す用途に向きます。
毎回巨大な全文をプロンプトへ詰め込む方式とは設計思想が異なります。
例えば社内マニュアル100冊から毎回2〜3項目を確認するなら、100冊を毎回全文投入するより検索型の方が合理的です。
資料の再利用性が高いほど、この差は大きくなります。
Deep Researchは、単なる長文入力というより、Webや接続された情報源を横断して調査を進め、複数ステップで情報を集める用途に向きます。
手元に確定した資料があり、その全体を分析したい場合と、外部情報を探索して答えを作りたい場合では選ぶ機能が異なります。
契約書10本の横断比較：
全文投入または大きめのまとまりで処理。条項間の関係が重要。
社内FAQを毎日検索：
File Search向き。毎回全文投入する必要性が低い。
1000ページ資料の章別要約：
分割処理向き。章単位で検証し、最後に統合。
巨大コードベースの設計調査：
Astraの長文コンテキストを活かしつつ、対象ディレクトリや目的を絞る。
最新市場調査：
Deep Researchなど検索・調査型機能を優先。固定資料だけでは最新性を確保できない。
同じ長い前提を何度も使うAPI処理：
Prompt Cachingを検討。
最も多い失敗は「入るから全部入れる」です。
100万トークンは上限であり、推奨入力サイズではありません。
コストを抑えるには、まず重複資料、旧版、無関係な付録を除きます。
次に、272K境界を超える必要が本当にあるか確認します。
繰り返し利用する長い前提はキャッシュを検討し、質問ごとに必要箇所が変わる資料群は検索型へ切り替えます。
また、巨大リクエストを1回成功させることより、失敗した時にどこから再実行できるかも重要です。
500K入力の処理が最後で失敗すると再実行コストも大きくなります。
分割可能な工程は分割し、途中成果物を保存する設計が実務では安定します。
GPT-6 Astraの1.05Mコンテキストは、これまで分割が前提だった巨大資料やコードベースを一度に扱える可能性を広げます。
一方で、272K超ではAPI料金体系が変わるため、容量だけを見て投入量を増やすとコストが急に上がる場合があります。
判断の基本はシンプルです。
全体の関係性が必要なら全文投入、独立して処理できるなら分割、同じ資料を繰り返し参照するなら検索・キャッシュ型を検討します。
100万トークンを使い切ることが目的ではありません。
必要な情報を、必要な範囲で、再現性とコストを管理しながら処理できることが、巨大コンテキストの本当のメリットです。
.png){kind=logo}
