本文へ移動

AI Buildersのための最新のニュース、知見、事例を毎日お届け

運営会社
コーディングエージェント

CodexのGPT-6.1 Sol、標準の文脈が「500k」に 公式の告知はまだなし

米OpenAIでCodexに携わるTibo氏は10月12日、CodexとChatGPT WorkでのGPT-6.1 Solの標準のコンテキスト長を27万2000トークンから50万トークンに広げたとXに投稿した。サブスクリプションの利用分には長文の追加料金をかけないという。10月13日時点で、公式の変更履歴に告知はない。

記事の内容を自社でどう進めるか、内容が固まっていない段階でも相談できます。仕事の相談

毎週 1 回、その週の記事から 5 本と実践の 1 本を選んでメールで届けます。ニュースレターを購読する(無料)

額縁の画面から長い帯が遠くへ伸び、背後に淡い疑問符が浮かぶ抽象的なイラスト

米OpenAIでCodexに携わるTibo氏は、2026年10月12日(日本時間)、CodexとChatGPT Workで使うモデル「GPT-6.1 Sol」の標準のコンテキスト長を50万トークンに広げたとXに投稿した。これまでの27万2000トークンから約8割増える。長い作業の途中で会話を圧縮する回数が減り、大きなコードを扱いやすくなる。ただし10月13日時点で、OpenAIの公式の変更履歴にこの告知は載っていない。

標準が27万2000から50万に

モデルが一度に読める文章の長さを「コンテキスト長」と呼ぶ。Tibo氏はXへの投稿で、CodexとWorkで使うGPT-6.1 Solの標準を50万トークンにしたと書いた。元の27万2000トークンから約80%の増加だという。Tibo氏のアカウントは、プロフィールで自らをOpenAIのCodexとChatGPTの担当と紹介している。

投稿は「Day 7/」で始まる。Tibo氏は利用者向けの改善を日ごとに出しており、その7日目にあたる。

GPT-6.1 Solは、OpenAIが9月29日にCodexとChatGPT Workへ加えたモデルだ。公式の変更履歴は、最上位の「GPT-6 Astra」に近い性能を、Astraより低い費用で出すと説明し、コードやアプリ、文書をまたぐ繰り返しの長い作業に向くとしている。10月8日には、出力を速める「Ultrafast」モードもCodexとChatGPT Workに加わった。長い作業に使われるモデルだけに、標準の文脈の長さは使い勝手に直結する。

同氏によると、今回の拡大は、長い作業の途中で文脈を要約して詰め直す「コンパクション」の回数を減らすためだ。多くの文脈と細かな前提を、長い時間保ったまま進める作業にも効くという。50万という値は慎重に試したうえで決めた、多くの利用者にとっての新しい「ちょうどよいところ」だと説明した。今後はさらに広げるとも述べている。

最大は1Mのまま、設定で変えられる

標準の値は利用者が変えられる。投稿によると、50万より大きくも小さくも上書きでき、GPT-6.1 Solのコンテキスト長の上限は100万トークンだ。

つまり、上限そのものは変わっていない。変わったのは、何も設定しない時に使われる長さだ。これまで27万2000トークンで圧縮が始まっていた作業は、設定を変えなくても、より長く圧縮なしで続けられる。ただし、上書きの具体的な設定の手順は、投稿には書かれていない。なお、27万2000から50万への増加は、計算すると約84%になる。投稿は、この増え方を「約80%」と書いている。

サブスクの利用分は長文の追加料金なし

Tibo氏は続く投稿で、この変更に合わせ、サブスクリプションの利用枠から使うGPT-6.1 Solには、長いコンテキストの追加料金をかけないと書いた。

文脈が長くなるほど、1回のやり取りで読む量は増える。この投稿のとおりなら、サブスクリプションでCodexを使う人は、長文の割増を気にせずに50万トークンまで使える。一方で、APIキーで従量課金で使う場合の扱いには触れていない。長く使った時に利用枠の減り方がどう変わるかも、投稿からは分からない。

公式の告知はまだない

今回の内容の出どころは、Tibo氏のXへの2本の投稿だけだ。10月13日時点で、ChatGPTとCodexの公式の変更履歴には、GPT-6.1 Solの提供開始やUltrafastモードの記載はあるが、標準のコンテキスト長を50万にした記載は見当たらない。

Codexで長い作業を回す人にとって、標準が50万になれば圧縮の回数は減る。ただし、正式な告知と利用枠の扱いが示されるまでは、Xの投稿を出どころとする未確認の変更として扱う必要がある。

編集部の見方

編集部は、この変更を「長い作業が楽になる」話より先に、出どころと条件で読むべきだと見る。根拠はOpenAIの担当者のXの投稿2本だけで、公式の変更履歴に載っておらず、利用枠の減り方やAPIでの扱いも示されていない。読者は、圧縮が多かった自分の長い作業を1本選び、Codexの画面で今のコンテキスト長を確かめてから、圧縮の回数と利用枠の減り方を前と比べるとよい。公式の告知で条件が違えば、この比較は前提から変わる。

この記事をシェア

この記事は役に立ちましたか