前回のDay 5では、Codexが次に送る指示を提案する「Composer predictions」と、dotsのスマホ作成・Codex連携を取り上げました。
今回の続きでは、Day 6とDay 7をまとめて整理します。Day 6は新機能の追加ではなく、利用枠まわりのリセット配布が中心でした。一方のDay 7では、GPT-6.1 Sol をCodex / Workで使うときのデフォルトコンテキスト長が272kから500kへ増加。見た目は地味でも、長い作業を続ける人にはかなり効く改善です。
「今日は派手な新機能があるのか」「ただのリセットなのか」を追う連載ですが、Day 6・Day 7はまさにそのコントラストがはっきり出た2日でした。Day 6は“補給日”、Day 7は“土台の改善日”として見ると流れがつかみやすくなります。
Day 6は改善よりもリセット配布が中心だった
Day 6で目立ったのは、新しい操作や機能の追加ではありませんでした。Tibo氏の投稿は「Day 6/ Reset」という非常に短いものです。つまり、この日は「何か新しいことができるようになった」というより、まずは使える枠を補充する日として受け止めるのが自然です。
告知本文はシンプルに「Day 6/ Reset」
Day 6の投稿は、内容を盛り込んだ長文ではなく、ほぼ一言で終わる告知でした。これまでの流れを見ると、改善が多い日は新機能の説明が並び、そうでない日はリセットや配布の話だけになることがあります。今回は後者です。
この点は、読者にとって誤解しやすいポイントでもあります。「Day 6が来た＝改善が来た」ではなく、今回は“改善なしでリセット中心”と整理したほうが実態に近いでしょう。
ここで押さえたいポイント
- Day 6の主題は新機能ではなくリセット
- 告知本文は短く、改善内容の列挙はなし
- 「28日間毎日改善」ではなく、あくまで「改善かリセットか」を追う流れ
図1：Day 6の投稿。本文は「Day 6/ Reset」と非常にシンプルで、この日は改善追加ではなくリセット配布が中心だったことが読み取れます。
当日中の反映を案内、のちに配布完了も報告
Day 6では、その後の投稿で「Global reset by EOD」、さらに「Put the reset in the bag. All propagated.」といった案内も出ています。細かな仕様説明よりも、「今日のうちに配る」「行き渡った」という運用連絡の色が強い日でした。
ここで注意したいのは、リセットの詳細な適用範囲が投稿文だけで完全に説明されているわけではないことです。どのプランのどの残量にどう反映されるかは、最終的には自分の利用画面や公式ヘルプの案内を合わせて確認する必要があります。投稿から読み取れるのは、少なくとも「全体向けのリセット配布を進めた」という運用上のメッセージです。
ユーザーの関心は依然として「利用枠をどうするか」
Day 6そのものはリセット告知中心でしたが、周辺の反応を見ると、ユーザーの関心が依然として利用枠の設計に強く向いていることもわかります。Tibo氏が出した投票では、Proユーザー向けの運用について次のような選択肢が示されていました。
- 5時間制限あり、週の使用量は2倍 … 33.2%
- 5時間制限なし、使用量は同じ … 37.8%
- 結果を見る … 29%
この投票では、「5時間制限なし、使用量は同じ」が最も多く支持されました。もちろん投票結果は製品仕様そのものではありませんが、少なくとも利用者が「総量」だけでなく、短時間で止まる使い勝手の悪さも強く意識していることは読み取れます。
これはDay 6が“ただの補給日”に見えても重要な材料です。なぜなら、どれだけ機能が増えても、途中で作業が区切られてしまう体験が大きな不満として残るなら、実運用での満足度は上がりにくいからです。
図2：Proユーザー向けの利用枠に関する投票結果。5時間制限の有無が大きな関心事になっていることがわかります。投票はユーザー意向の参考材料であり、公式仕様の確定告知ではありません。
Day 7はGPT-6.1 Solのデフォルトコンテキスト長が500kに
Day 7では、Day 6とは対照的に、中身のある改善が入りました。内容は、GPT-6.1 SolをCodexおよびWork経由で使う場合のデフォルトコンテキスト長を500kへ引き上げたというものです。従来は272kだったため、約80%の増加になります。
一見すると地味ですが、長い作業を続ける人ほど効いてくる変更です。とくに、数回のやり取りで終わらず、仕様、過去の修正、例外条件、参考資料などを抱えたまま進むタスクでは、体感差が出やすいでしょう。
272kから500kへ、約80%の増加
投稿で案内された変更点を、まずはシンプルに整理すると次のとおりです。
- 対象: GPT-6.1 Sol
- 対象環境: Codex および Work
- 変更内容: デフォルトコンテキスト長を272k → 500kへ増加
- 増加幅: 約80%増
- 追加の補足: 将来的にはさらに引き上げる方針
「デフォルト」と書かれている点も重要です。つまり、特別な設定をしなくても、まず多くのユーザーが使う標準値が大きくなった、ということです。
図3：Day 7の投稿。GPT-6.1 Solのデフォルトコンテキスト長を、Codex / Workで使う場合に500kへ引き上げたと案内しています。ユーザー提供の翻訳表示スクリーンショットです。
なぜ効くのか——コンパクションが起きにくくなる
投稿では、今回の引き上げによってcompactions（コンパクション）の発生が減ることにも触れられています。
ここでいうコンパクションは、長い作業を続ける中で、過去のやり取りや条件の一部を圧縮・要約しながら扱うような動きをイメージするとわかりやすいでしょう。もちろん圧縮自体が悪いわけではありませんが、圧縮が増えるほど、細かなニュアンスや例外条件がこぼれやすくなります。
今回の改善で期待できるのは、たとえば次のような場面です。
- 長い仕様書や複数ファイルを前提にして修正を続けるとき
- 何日かにわたって同じタスクを少しずつ進めるとき
- 「ここは変えてよい／ここは触らない」などの条件が多いとき
- テスト結果、例外、保留事項を抱えたまま仕上げに進むとき
要するに、長期戦の作業で文脈を持ち続けやすくする改善です。派手な新ボタンよりも、実務ではこちらのほうが効く場面も少なくありません。
必要に応じて上書きでき、最大は1M
Day 7の投稿では、デフォルト値を500kにしたうえで、必要に応じて高くも低くも上書きできること、そして最大コンテキスト長は1Mであることも案内されています。
ここは少し丁寧に見る価値があります。OpenAIの開発者向けモデル仕様ページでは、GPT-6.1 Solのコンテキストウィンドウが1.05M tokensと案内されています。一方で、今回の投稿ではCodex / Workでの実運用に関する説明として「最大1M」が示されています。
この違いは、一般の読者向けには次のように整理するとわかりやすいでしょう。
- モデル全体の仕様ページでは、GPT-6.1 Solの大きなコンテキスト枠が示されている
- Codex / Workの運用説明では、デフォルト500k、上書き可能、最大1Mという実務寄りの説明が出ている
- つまり今回は、モデルの能力そのものというより、Codex / Workでの使い勝手をどう調整するかが主題
このため、本記事ではCodex / Workでの運用改善として読むのが自然です。
この2日間から見えること
Day 6とDay 7を続けて見ると、OpenAIがCodex / Workを「新機能を毎日足すだけの製品」ではなく、「使い続けやすく整える製品」として磨いていることが見えてきます。
リセットも重要なアップデートの一部になっている
Day 6は改善告知こそ少なかったものの、利用者にとっては無意味ではありません。むしろ、日常的に使う人ほど、使える残量が戻ること自体が体験の継続条件になります。
Day 7の改善は「長い仕事」に効く
今回の500k化は、短いやり取りだけでは恩恵を感じにくいかもしれません。しかし、以下のような使い方では体感差が出やすいはずです。
- 大きめのコードベースをまたいで修正する
- 記事や資料、仕様書を参照しながら何段階も仕上げる
- 前回の判断や制約を保ったまま翌日に続きを進める
- Workで複数ステップの下調べとまとめを往復する
「速い」「賢い」だけでなく「途中で崩れにくい」方向へ
Day 1〜Day 5では、UIの反応や入力補助、dots連携のような“見える改善”が目立ちました。Day 7はそれとは少し違って、見えにくいけれど、長時間使ったときの崩れにくさを底上げする改善です。
この違いは大きいです。日常利用では、派手な新機能よりも、前に伝えた条件を忘れにくいこと、長い作業でも文脈がつながりやすいことのほうが、最終的な満足度を左右することが多いからです。
まとめ｜Day 6は補給、Day 7は長期戦向けの地味に大きい改善
Day 6は、機能の追加よりもリセット配布が主役でした。改善がない日が混ざることで、「28日間」企画が単なる連日の新機能発表ではなく、運用も含めた変化の記録であることがよくわかります。
そしてDay 7では、GPT-6.1 Solのデフォルトコンテキスト長が500kへ増加。これにより、長い作業でコンパクションが起きにくくなり、文脈やニュアンスを保ったまま進めやすくなることが期待されます。
短くまとめるなら、こうです。
- Day 6: 改善よりリセット。利用継続のための補給日
- Day 7: デフォルト500k化。長い仕事の安定性を底上げする改善日
派手さではDay 5のほうが伝わりやすいかもしれません。しかし、実際に毎日使う側から見ると、Day 7のような土台の改善はじわじわ効いてきます。これから先の更新を見るうえでも、「何が新しくできるようになったか」だけでなく、長く使ったときにどこがラクになるのかに注目すると、変化の意味がつかみやすくなりそうです。
参考・確認した情報源
発表内容はTibo氏の公開投稿と提供画像、モデル仕様と利用環境はOpenAIの公式資料を2026年10月12日に確認しました。投稿で示された運用値とAPIの仕様は、同じ数値として扱っていません。
前回記事
入力予測やdots連携の流れは、前回の記事とあわせて読むとつながります。
一次情報・公式情報
GPT-6.1 Solの提供環境とモデル仕様の確認に使った公式資料です。
投稿確認元
Day 6・Day 7の個別投稿と配布完了の案内を確認しました。画像は論評に必要な引用資料として、発信者と出典を併記しています。
-
本記事で使用したDay 6 / Day 7関連画像は、ユーザー提供スクリーンショット（2026-10-12確認）をもとに整理
コメント