OpenAI・Codexの「28日間アップデート」をこれからも毎日詳しく調査して発信します。続きの新機能やリセット情報が気になる方は、ぜひフォローしてください。
2026年10月13日（米国時間）、OpenAIの28日間アップデート企画で Day 9 が発表されました。
今回の内容は、ChatGPTとCodexのデスクトップアプリで、ディスクに保存する状態データを約60%減らすストレージ最適化です。
前日のDay 8はグローバルリセット、Day 7はGPT-6.1 Solの標準コンテキストを500Kへ拡張する改善でした。Day 9は派手なAIモデル更新ではなく、日常的に使うデスクトップアプリの負荷を抑える、品質改善になります。
ただし、重要な注意点があります。
「ディスク上の状態データが約60%減る見込み」であって、RAM消費、アプリ全体のサイズ、SSD全体の使用量、利用料金が60%減るという話ではありません。
この記事では、公式発表の範囲と未公表事項を厳密に分けたうえで、なぜ保存データが増えるのか、過去の問題報告、手元のPCでの確認コマンド、使う際の注意事項まで整理します。
調査時点：2026年10月14日（日本時間）。 当日の発表は「約60%の削減が見込まれる」という表現です。全ユーザーの実測値、対象バージョン、内部実装、既存データの削減タイミングなどは、公式のDay 9告知では詳しく示されていません。
まず結論：Day 9の発表内容
| 項目 | 公式発表で確認できたこと |
|---|---|
| 企画 | OpenAI 28日間アップデートの Day 9 |
| 発表日 | 2026年10月13日（米国時間） |
| 対象 | ChatGPT / Codex デスクトップアプリ |
| 改善 | ディスクに保存する状態データを最適化 |
| 期待される効果 | 保存状態の容量を約60%削減 |
| 展開状況 | ロールアウトを開始・展開済みと案内 |
| 対象OS・バージョン | 発表には個別の対応表なし |
| 60%の測定条件 | 発表には詳細なし |
| Day 9の新たなフルリセット | 公式追跡表に掲載なし |
OpenAI公式の28日間トラッカーは次のようにまとめています。
Storage optimizations rolled out for the ChatGPT and Codex desktop apps are expected to reduce the amount of state stored on disk by 60%.
OpenAI Developer Community：28 days of Shipping at OpenAI
OpenAIのTibo Sottiaux氏によるDay 9発表（X）
「rolled out（展開）」と「expected（見込み）」が同時に使われているのがポイントです。機能が配布されていても、各環境で必ず60%の節約効果が得られるとは限りません。
60%減るのは「何の容量」？
結論から言うと、デスクトップアプリがディスク上に保持する「状態データ（state）」の容量です。
状態データは、アプリが作業を再開・継続するために保持する情報を広く指します。一般的には、次のようなものがあります。
- 会話・作業スレッドの履歴
- 途中の作業状態とメタデータ
- 実行したツールや操作に関する情報
- インデックスや再開に必要な関連情報
ただし、今回の発表は、これらの各データ種類のうち何が具体的に最適化されたかを列挙していません。 上記は状態データの一般例であり、すべてが今回の60%削減対象だと確認されたわけではありません。
RAM、ストレージ、コンテキストの違い
| 用語 | 意味 | Day 9との関係 |
|---|---|---|
| ディスクストレージ | SSD / HDDへ永続保存するデータ | 今回の直接の改善対象 |
| RAM（メモリ） | アプリ実行中に使う作業領域 | 60%削減との発表なし |
| AIのコンテキスト長 | モデルが一度に参照できるトークン数 | Day 7の500Kとは別 |
| クラウド容量 | サーバー側に保存する情報 | 60%削減との発表なし |
| 利用枠・クレジット | Codex / Workなどの使用量 | Day 9でリセットされたとの発表なし |
例えば100GBなら40GBになる？
「60%減る」を計算上の例に置き換えると、次のようになります。
変更前の状態データ：100 GB
想定削減量： 60 GB
変更後の状態データ： 40 GB
計算式は次の通りです。
削減後 = 削減前 × (1 - 0.60)
= 削減前 × 0.40
ただし、これは計算上の説明用サンプルです。実際に100GBの状態データがあるユーザーの容量が40GBになるという保証はありません。ほかのファイルやOSの予約容量まで含めたPC全体の空き容量が60%改善するわけでもありません。
なぜCodexのローカル容量が問題になりやすい？
Codexは、短い質問に回答するだけのツールではありません。
例えば開発タスクでは、次のような作業が長時間続きます。
Issueを読む
↓
ソースコードを調査
↓
ターミナルでコマンドを実行
↓
テストログを確認
↓
ファイルを修正
↓
サブエージェントが追加調査
↓
CIで失敗した内容を分析
↓
再修正・レビュー・PR
アプリには過去の状態を再開したり、作業の流れを追跡したりする必要があるため、使い方によっては大量のデータを保存することになります。
とくに、ログが長いタスク、画像を含む会話、大量のサブタスクを持つ仕事は、状態データが膨らみやすいケースです。
こうした傾向を示すユーザーの過去の問題報告が、OpenAIのCodex GitHubリポジトリにもあります。
過去の報告：ローカルの作業履歴が数十GB以上に
2026年7月20日に作成されたopenai/codex Issue #34337では、Codex CLIとデスクトップのローカルセッション保存先が、長期利用で数十GBから数百GB規模へ膨らんだという報告がまとめられています。
具体例として、報告者の環境では約70GiBのセッションデータが確認されました。
原因候補として挙げられているのは、
- Compaction（会話の圧縮・要約）による履歴の重複
- サブエージェントへ親の履歴を引き継ぐ際のコピー
- 画像や大きなツール出力の保持
などです。
別のIssue #35458では、スクリーンショットの内容が再保存され、セッション保存先が約165GiBに達したという報告もあります。
これらはユーザーが報告した事象であり、OpenAIがDay 9の60%改善と同じ原因だと確認した資料ではありません。
Day 9の改善でこれらの不具合は解決した？
現時点では断定できません。
Day 9の公式文は、状態データの最適化による約60%の削減見込みを伝えていますが、
- 上記の個別Issueがすべて修正された
- 既存の巨大なセッションが必ず自動圧縮される
- サブエージェントによる重複保存が完全になくなった
- すべてのOSと過去バージョンで同じ削減率になる
とは明記していません。
「ストレージの最適化が展開された」ことと「保存データの増大に関するすべての問題が解決した」ことは別として理解する必要があります。
技術的にはどうやって小さくできる？
今回のDay 9投稿では実装詳細が明らかにされていません。
以下は一般的な状態保存の設計における代表的な最適化手法です。OpenAIが今回これらを採用したと確認されたわけではありません。
1. 圧縮（Compression）
文章・JSONなどの繰り返しパターンが多いデータを、容量の小さい形式へ変換します。
保存前：1,000 MBのログデータ
↓ 圧縮（概念例）
保存後： 400 MBのデータ
実際の削減率はデータの内容と圧縮方式に依存します。
2. 重複排除（Deduplication）
親スレッドと複数のサブエージェントが同じ情報を参照する場合、同じ大きなデータを何度も保存する代わりに、共有できる参照として保持する方式です。
重複保存：
親の履歴 × 3つの子タスク
重複排除の考え方：
共通の履歴 × 1
＋ 子タスクごとの差分
3. ライフサイクル管理
再開する必要がない一時データ、古いキャッシュ、不要になったスナップショットを、破損が起きないように管理する方法です。
ここで大切なのは、単に古い会話履歴を削除するだけでは安全な最適化にならないことです。
ユーザーが後で再開できる必要があるデータと、一時的で再生成できる情報を区別する必要があります。
これらは技術的な参考解説です。今回の60%削減が、圧縮・重複排除・自動削除のどれによるものかは非公表です。
自分のPCでストレージを確認する方法
Day 9の最適化の影響を確認したい場合、まず保存先の容量を読み取り専用の方法で測定するのが安全です。
次のコマンドは、Codex CLIでも利用される~/.codexの容量を見る例です。ChatGPTデスクトップアプリの全保存データと完全に一致するものではありません。
macOSの場合
ターミナルで実行します。
du -sh ~/.codex
-
du：Disk Usage。ディスク使用量を調べる -
-s：指定したフォルダー全体を合計して表示 -
-h：KB、MB、GBなど読みやすい単位で表示 -
~/.codex：ホームディレクトリにあるCodexのローカルデータの例
セッション履歴だけを確認する場合は次の通りです。
du -sh ~/.codex/sessions
例：
2.4G /Users/example/.codex
1.9G /Users/example/.codex/sessions
上記の数値はサンプルです。
ファイルが存在しない場合はエラーになります。ローカルデータの保存場所は、Codexの設定やバージョンによって変わる場合があります。
Windows（PowerShell）の場合
PowerShellで、まず保存フォルダーを確認します。
Test-Path "$env:USERPROFILE\.codex"
Test-Pathは指定したファイルやフォルダーが存在するか確認するコマンドです。存在すればTrue、なければFalseが返ります。
存在する場合は容量を計算します。
$items = Get-ChildItem "$env:USERPROFILE\.codex" -File -Recurse -ErrorAction SilentlyContinue
$bytes = ($items | Measure-Object -Property Length -Sum).Sum
"{0:N2} GB" -f ($bytes / 1GB)
-
Get-ChildItem：ファイル一覧を取得 -
-File：フォルダーではなくファイルを対象 -
-Recurse：下位フォルダーも再帰的に調べる -
-ErrorAction SilentlyContinue：アクセスできないファイルのエラー表示を省略 -
Measure-Object -Sum：各ファイルのサイズを合算 -
1GB：PowerShellのサイズ定数（2進法ベース）
この例はファイルサイズの合計であり、ファイルシステム上の実際の物理占有量や、アプリ関連データの全体と一致しない場合があります。
アップデート前後で比較するなら
以下の条件を揃えると変化を見やすくなります。
- アプリのバージョンとOSの種類を控える
- 同じ保存先の容量を測る
- アプリを更新して再起動する
- 再び同じ保存先を測る
- 減らなかった場合も、勝手に保存データを削除しない
途中で大量のタスクを実行すると、新たな履歴が増えるため比較が難しくなります。
なお、アプリの設定を削除したり、~/.codex/sessionsを丸ごと消したりする必要はありません。
状態データを手動で消すと、再開できるはずのスレッドや作業履歴を失うおそれがあります。容量削減だけを目的とした未確認の一括削除は避けてください。
Day 9で何が変わらない？
今回の発表は、デスクトップの保存状態の最適化です。別の改善と混同しないように整理しておきます。
APIのモデル料金は変わらない
今回の「約60%」は、APIのトークン料金の割引率ではありません。
GPT-6.1 SolのStandard / Ultrafast料金にも関係しません。
Codexの利用枠はリセットされない
Day 9の発表内容に、追加のグローバルリセットは記載されていません。
Day 6とDay 8はリセットでしたが、Day 9は状態データの保存効率の改善です。
Day 7の500Kコンテキストとも別
Day 7で増えたのは、モデルが1回の処理で扱えるトークンの上限です。
Day 9で改善されたのは、アプリがローカルディスクに保存するデータ量です。
この2つは関連する場合はありますが、同じ設定でも同じ指標でもありません。
スマホ版に60%削減が適用されたわけではない
公式の対象はデスクトップアプリです。iOSやAndroidのアプリ内保存量が同様に60%削減されたという発表ではありません。
Day 1〜Day 9のアップデートを振り返る
| 日 | 公式企画での主な内容 |
|---|---|
| Day 1 | GPT-6 Astra / GPT-6.1 Solの標準速度改善 |
| Day 2 | Auto-review無料化、API Tier簡略化、Meetings、Decisions API。追加の一斉リセットも実施 |
| Day 3 | GPT-6 / Intelligent UI、保存可能なリセット配布 |
| Day 4 | GPT-6.1 Sol Ultrafast、Instant steering |
| Day 5 | Dotsのスマホ対応、Composer predictions |
| Day 6 | グローバルリセット |
| Day 7 | GPT-6.1 Solの標準コンテキスト272K→500K |
| Day 8 | グローバルリセット |
| Day 9 | デスクトップの状態保存を最適化し、ディスク使用量を約60%削減見込み |
公式トラッカーではDay 10以降は、この記事の執筆時点で**Pending（発表待ち）**です。
よくある質問
Q. 自分のSSDの空き容量も60%増える？
いいえ。 削減対象はアプリが保持する状態データです。PC全体のSSDにはOS、写真、動画、開発リポジトリなど別のデータもあります。
Q. ChatGPTのメモリ使用量が60%減る？
いいえ。 公式はディスク上に保存する状態データの量について述べており、実行時RAM使用量の削減は発表していません。
Q. 手動で設定する必要がある？
公式のDay 9告知ではロールアウト済みの最適化として説明されています。専用の設定項目や手動コマンドは案内されていません。
Q. 既に保存されている過去の大きな履歴も小さくなる？
公式の短い告知だけでは不明です。 既存データがいつ再編成されるのか、後から作られる状態データのみが対象なのかは詳細が示されていません。
Q. 以前の大容量の不具合は全部直った？
確認できません。 大きなセッションデータに関するユーザーIssueは存在しますが、個別IssueをDay 9の改善がすべて解決したと断定できる一次情報はありません。
Q. Day 9にリセットチケットの追加配布はあった？
公式トラッカーには記載がありません。 Day 9で確認できる発表内容は、デスクトップの状態データ最適化です。
まとめ
Day 9は、ChatGPTとCodexのデスクトップアプリで、保存する状態データを約60%減らすことを見込んだ改善でした。
押さえるべき点は以下の通りです。
- 対象はChatGPT / Codexのデスクトップアプリ
- ローカルディスクに保持する「state」が約60%減る見込み
- アプリ全体のインストールサイズ、RAM、API料金が60%減るとは発表されていない
- Codexの長時間セッションの容量増大について、過去にユーザーから報告があった
- ただし、Day 9が個別の全不具合を修正したかは未確認
- 保存領域の確認は
duやPowerShellなどの読み取りだけのコマンドで行える - 履歴や作業状態を自己判断で一括削除しない
- Day 9の追加フルリセットは公式追跡情報に掲載なし
AIエージェントは長時間の仕事や複数のサブタスクを扱うため、モデルの速さだけでなく、履歴の保持・復帰・ローカルデータの容量管理も使い勝手を大きく左右します。
今後、具体的な実装方式、どのデータが圧縮対象か、実際の容量削減率が追加公開されれば追記していきます。
参考・一次情報
- OpenAI Developer Community：28 days of Shipping at OpenAI（Day 9）
- Tibo Sottiaux氏によるDay 9の公式発表
- OpenAI公式：ChatGPT & Codex Changelog
- OpenAI GitHub：Codex CLI / Desktopのローカルセッション容量に関するIssue #34337 （ユーザー報告でありDay 9の実装修正を証明するものではありません）
- OpenAI GitHub：画像履歴の重複に関するIssue #35458 （同上）
明日以降もOpenAI・Codexの28日間アップデートを毎日調査して発信します。Day 10の新機能やリセットの最新情報も知りたい方は、ぜひフォローしてください。