2026/09/04Codex

AI活用導入・運用

Codexのコンテキスト圧縮を止める設定｜文脈をメモで保つ

「さっき直したはずの箇所を、また同じやり方で壊す」「一度は却下した方針を、しばらくすると蒸し返してくる」——長い作業をCodexに任せていると、多くの人がこの不可解さに突き当たります。

結論から言うと、原因の多くはモデルの賢さではなく、コンテキストウィンドウが埋まったときに走る「要約による圧縮（compaction）」です。2026年9月3日（米国時間）に発表されたGPT-6 Astraでは、この圧縮の代わりにメモと検索可能な履歴で文脈を保つ実験的モードが加わり、config.tomlの2行で有効にできます。

株式会社Fyveは、中小企業のAI活用を月額で伴走する専属AI活用顧問サービスを提供しています。私は日中の開発と、夜間に無人で走らせる自動化ジョブの両方で、この「忘れる」問題に長く対処してきました。この記事では公式の仕様を正確に押さえたうえで、有効化の手順と、私がこの機能にどこまで任せるつもりかまで書きます。

先に結論｜押さえるべきは3点

詳しい背景は後述しますが、急いでいる方のために要点だけ先に置きます。

従来のcompactionは「過去のやり取りを1つの要約に潰す」処理です。潰すときに、なぜその修正が失敗したのか、そのコンポーネントがどう振る舞ったのかといった細部が落ちます
Astraの新しいモードは「メモを取り続ける」＋「過去のコンテキストウィンドウを検索可能なまま残す」という二段構えです。メモに書き漏らした情報も、後から過去のメッセージやツール出力を検索して拾い直せます
有効化は~/.codex/config.tomlに2行。既定は無効で、OpenAIは「数週間のうちにAstraの既定にする」と案内しています（2026年9月4日時点）

この記事はGPT-6 Astraというモデルそのものの解説ではなく、そのリリースで増えた「道具」の使い方に絞っています。モデル本体の変更点・料金・使えるプランについては、別記事にまとめました。

CodexGPT-6 Astraとは｜変更点・料金・使えるプラン

なぜCodexは長い作業で文脈を失うのか

先に、何が起きているのかを整理します。ここを理解しないと、設定を変えても「何が良くなったのか」が判断できません。

コンテキストウィンドウは有限である

AIが一度のやり取りで読み書きできるトークンの量には上限があります。これがコンテキストウィンドウです。GPT-6 Astraの場合は1,050,000トークンで、これは決して小さくありません。

ただし、上限が大きいことと「長い作業で情報が失われない」ことは別の話です。数時間かけて複雑なバグを追ったり、大規模なリファクタリングを進めたりすれば、どれだけ広い窓でもいずれ埋まります。コンテキストウィンドウの大きさそのものについては、こちらで実際の分量に換算して解説しています。

CodexGPT-6 Astraの105万トークンで何が入るのか

窓が大きいのに埋まるのはなぜか

「105万トークンもあるのに、そんなに早く埋まるのか」と思われるかもしれません。ここには実務でしか見えにくい事情があります。

コンテキストを食うのは、人間が書いた指示文ではありません。ツールが返す出力です。ファイルを丸ごと読ませれば、その中身がそのまま窓に入ります。テストを走らせればログが入り、失敗すればスタックトレースが入ります。検索を実行すれば該当箇所の周辺が入り、差分を確認すれば差分が入ります。

複雑な不具合を追う作業は、この「読む・試す・失敗する」を何十回も繰り返す行為です。1回あたりの出力が数千トークンでも、往復を重ねれば桁が変わります。つまり窓を広げても、埋まるまでの時間が延びるだけで、長い作業を最後まで走らせれば結局は同じ壁に当たります。

だからこそ、上限の大きさとは別に「埋まったときに何をするか」という設計が効いてきます。ここが今回変わった部分です。

compactionが何をしているか

窓が埋まりかけたとき、これまでのモデルはcompaction（圧縮）という処理を行ってきました。やっていることは単純で、それまでの長いやり取りをモデル自身が要約し、その要約を持って新しい窓で作業を再開するというものです。

要約なので、当然ながら情報は減ります。しかも減らし方はモデルに任されているため、何が残って何が消えるかを人間側からは制御しきれません。長いセッションでは、この圧縮が一度ではなく繰り返し走ります。要約の要約の要約、という状態になっていくわけです。

落ちるのは「うまくいかなかった記録」

ここが実務で効いてくるところです。要約は性質上「いまどうなっているか」を残し、「そこに至るまでに何を試して何がダメだったか」を捨てます。

OpenAIの公式発表も、compactionについて「なぜ修正が失敗したのか、あるコンポーネントがどう振る舞うのかといった詳細が、圧縮のたびに抜け落ちうる」という趣旨の説明をしています。私の体感とも一致します。長時間のセッションで起きる典型的な症状は、次のようなものです。

すでに試して失敗したアプローチに、もう一度そっくり同じ手順で入っていく
「この方式は採らない」と合意したはずの設計を、後半で提案し直してくる
序盤に出たテストの失敗ログを参照できず、症状の説明が最初からやり直しになる

いずれも「モデルが馬鹿になった」のではなく、判断の材料が要約の過程で捨てられた結果です。人間で言えば、議事録の要点だけを渡されて途中から会議に入るようなもので、決定事項は分かっても「なぜその案が消えたか」は分かりません。

読者特典・無料ダウンロードCodexに「課金」する前に読む本無料でダウンロード →

GPT-6 Astraで変わったこと｜要約からメモ＋検索へ

2026年9月3日（米国時間）に発表されたGPT-6 Astraでは、Codexにおけるこの部分の設計が変わりました。

公式が説明している内容

OpenAIの発表によると、Astraはコンテキストウィンドウをまたいでメモを保持し、蓄積した詳細を単一の要約に繰り返し圧縮せずに保てるようになっています。さらに、以前のコンテキストウィンドウは検索可能な状態で残り、メモに取り込まれなかった情報についても、過去のメッセージやツール出力から要件やテスト結果を探し出せるとしています。

この機能は現時点で実験的な位置づけで、Codexのconfig.tomlで有効化する必要があります。OpenAIは「今後数週間のうちにAstraの既定になる」としています。

「メモ」と「検索」は別の仕組み

混同しやすいので分けて理解しておくと、後の判断が楽になります。

仕組み	役割	限界
メモ（notes）	作業中に重要と判断した詳細を、窓をまたいで持ち越す	何をメモするかはモデルの判断。書かれなければ残らない
検索可能な履歴	過去のコンテキストウィンドウの中身を、後から探して参照する	探しに行かなければ使われない。存在を思い出す必要がある

この二段構えが要点です。メモだけなら「モデルが重要だと思わなかったもの」は従来同様に失われますが、履歴が検索可能に残っているぶん、取りこぼしを後から回収する経路が用意されています。逆に言えば、どちらもモデル側の判断に依存する点は変わりません。

従来のcompactionは要約に圧縮、Astraの実験モードはメモと検索可能な履歴で文脈を残す比較図

「Codex永続メモリ」とは別の話

ここは特に誤解されやすいところです。Codexにはすでに永続メモリ（Memories）という機能があり、こちらはセッションをまたいでプロジェクト固有の知識を引き継ぐ仕組みです。昨日の続きから話せるようにするための機能で、対象は「セッションとセッションの間」です。

今回の新しい文脈管理は、1本のセッションの内側で、窓が埋まったときに何を捨てるかという話です。守備範囲がまったく違うので、片方を入れたからもう片方が要らなくなる、という関係ではありません。永続メモリ側の解説はこちらにまとめています。

CodexCodex 永続メモリ｜セッション横断のコンテキスト

有効化の手順｜config.tomlに2行

実際の設定は拍子抜けするほど簡単です。ただし前提条件があるので、順に確認します。

1. 設定ファイルの場所

ユーザー単位の設定は~/.codex/config.tomlに置きます。プロジェクト単位で上書きしたい場合は、そのプロジェクト内に.codex/config.tomlを置く方法もあります（プロジェクトを信頼した場合にのみ読み込まれます）。

初めて触る場合、ファイル自体が存在しないこともあります。その場合は新規に作って構いません。

2. 記述する内容

公式のconfigリファレンスに沿うと、書くのは次の2行です。

[features.context_management]
experimental_mode = true

このキーの既定値はfalse、つまり何もしなければ従来どおりのcompactionが使われます。公式の説明は「コンテキストを繰り返し単一の要約に圧縮するのではなく、メモと検索可能な履歴を使って蓄積された詳細を保持する」というものです。

3. 前提条件を満たしているか確認する

ここを見落とすと、設定を書いたのに何も変わらないという状態になります。公式リファレンスによれば、この機能はPlus・Pro・Pro LiteのいずれかでのChatGPTサインインが必要です（2026年9月4日時点）。APIキーだけで動かしている構成では対象外という理解になります。

また、対象はあくまでAstraでの動作として案内されている機能です。別のモデルを指定して動かしている場合は、期待した挙動にならない可能性があります。

4. いま入れるか、既定になるまで待つか

OpenAIは数週間のうちにAstraの既定にすると述べています。したがって「待てば自動的に来る」ものではありますが、先に入れておく実務上の意味は、既定化の前に自分の作業で挙動を確かめられることにあります。

実験的機能である以上、既定化までに細部が変わる可能性はあります。業務の本番フローに直結する環境では、まず個人の開発環境で試すのが順当です。

あわせて知っておきたいcompaction関連の設定

新モードに切り替える前に、compactionの挙動を設定で調整していた方もいるはずです。公式のconfigリファレンスには、関連するキーがいくつか用意されています。

キー	役割
`model_auto_compact_token_limit`	自動compactionが走るトークン閾値
`model_auto_compact_token_limit_scope`	閾値をコンテキスト全体で数えるか、前置き以降の増加分で数えるか
`compact_prompt`	圧縮時に使うプロンプトをその場で上書きする
`experimental_compact_prompt_file`	圧縮プロンプトを外部ファイルから読み込む

これらは「圧縮をいつ走らせるか」「圧縮のときに何を残せと指示するか」を人間側から制御する道具です。新しい文脈管理モードは、その手前にある圧縮するという方式そのものを置き換える提案なので、目的が重なる部分があります。両方を同時に細かく調整すると何が効いているのか分からなくなるため、切り替えるなら一度に一つだけ変えるのが安全です。

私はこう扱います｜無人でAIを回している側の判断

ここからは公式情報ではなく、私自身の運用方針です。私は自社の業務をAIで自動化しており、夜間に無人で走るジョブと日中の開発が並行して動いています。この「文脈が失われる問題」は、ずっと前から対処せざるを得ない課題でした。

これまで私が取ってきた対策

結論として、私はcompactionと戦うのをやめる方向で運用を組んできました。具体的には3つです。

コンテキストが溜まる前に、新しいセッションを始める。コンテキスト量を積み上げて精度を上げるアプローチ自体を本質的でないと考えているため、そもそも窓が埋まるところまで持っていきません
知見はセッションではなくファイルに置く。プロジェクト単位でMarkdownのデータフォルダに蓄積する形にしてから、セッション間の文脈維持の問題はほぼ解消しました。以前はメモリ機能だけに頼っていた時期も、外部のノートツールと連携させた時期もありましたが、いずれも実務で頼れる水準にはなりませんでした
繰り返す作業はスキル化する。手順を毎回説明するのではなく再現可能な形にしてしまえば、そもそも覚えていてもらう必要がありません

この3つは、いずれも「AIに覚えさせる」のではなく「AIが読む場所に置いておく」という発想です。

新モードで置き換わる部分・置き換わらない部分

そのうえで今回の機能をどう見ているかというと、置き換わるのは1つ目だけだと考えています。

課題	新モードで改善が期待できるか
1本の長いセッション内で、失敗の理由や途中の観察が失われる	期待できる。まさにこの機能の狙い
セッションをまたいで、プロジェクトの前提や決定事項を保つ	守備範囲外。永続メモリかファイルの仕事
組織のルール・命名規則・禁止事項を確実に守らせる	期待しない。明文化してファイルに置くべき領域
人間が後から経緯を検証する	期待しない。モデルのメモは人間の記録の代わりにならない

つまり「デバッグや大規模な変更を1本のセッションで押し切りたいとき」の体験は良くなるはずですが、消えては困る決定ほど、人間が読める形でファイルに書くという原則は変わりません。むしろメモが賢くなるほど、書かなくても何とかなってしまう場面が増え、後から経緯を追えない状態を作りやすくなります。私はそこを警戒しています。

無人運用で入れる前に測ること

もう一点、無人で回している立場から気にしているのがトークン消費です。過去のコンテキストウィンドウを検索可能に保つということは、必要に応じて過去を読みに行く動作が増えるということでもあります。

私は以前、複数の重い作業を1セッションで並行させた結果、利用枠の上限に一気に到達したことがあります。普通に使っていても数時間で到達する体感で、この経験以降は「どれだけのコンテキストを読ませているか」を常に意識する運用に切り替えました。新しい文脈管理が消費量にどう効くかは、実際に同じ作業で前後を比べるまで分からないため、無人ジョブへの適用は検証してからにします。

使用量の確認方法そのものは、こちらにまとめています。

CodexCodex の使用量を確認する方法｜トークン管理の実務

導入前に確認したい3つの落とし穴

落とし穴1：実験的機能であることを忘れる

既定化が予告されているとはいえ、現時点では実験的機能です。挙動が変わる前提で使うべきで、この機能に依存した業務手順を先に作らないことをおすすめします。特に、複数人が同じ手順書で動いているチームでは、環境ごとに設定が違う状態が混乱を生みます。

落とし穴2：サインイン条件を満たしていない

前述のとおり、公式リファレンスはPlus・Pro・Pro LiteでのChatGPTサインインを条件として挙げています。設定を書いたのに変化を感じない場合、まずここを疑うべきです。設定ファイルの記述ミスを延々と探す前に、前提条件から確認してください。

落とし穴3：短い作業で効果を測ろうとする

これは実務でいちばん起こりやすい失敗です。この機能が効くのは、コンテキストウィンドウが実際に埋まるほど長い作業だけです。10分で終わるタスクを何度試しても違いは出ません。

評価するなら、普段いちばん長く粘っている作業——複雑な不具合の追跡や、広い範囲に手を入れる変更——を選び、設定の前後で同じ内容をやらせて比べるのが確実です。見るべきは出力の巧拙ではなく、「一度失敗した道にもう一度入るか」という一点です。

効果を測る手順｜4ステップ

「なんとなく良くなった気がする」で判断すると、次に不調が出たときに切り分けられません。私が新しい設定を評価するときの手順を、そのまま書いておきます。

ステップ1：長い作業を1つ選ぶ

普段いちばん長く粘っている作業を選びます。目安は、途中で一度は圧縮が走るくらいの長さです。短いタスクを選ぶと、この設定は評価できません。

ステップ2：判定基準を先に決める

走らせる前に、何をもって良し悪しとするかを紙に書きます。私が見ているのは次の3点です。

同じ失敗を繰り返したか（一度ダメだった方法に再突入していないか）
序盤の決定を後半まで守れたか（方針の蒸し返しがないか）
人間が説明し直した回数（前提を再入力させられた回数を数える）

3点目は特に有効です。回数として数えられるため、体感に頼らずに比較できます。

ステップ3：設定の前後で同じ内容を走らせる

設定を変えた後に新しいセッションを開き、同じ作業を同じ指示で走らせます。途中で人間が助け舟を出すと比較にならないので、口を出したくなっても回数を数えるだけにとどめるのがコツです。

ステップ4：消費量もあわせて記録する

体験が良くなっても、消費が跳ね上がるなら業務での使い方は変わります。前後で使用量を確認し、改善幅と消費幅を並べて見てから、常用するかを決めます。

メモに残ってほしいことを、人間側から増やせるか

ここはよく聞かれる論点ですが、公式が「何をメモするか」の指定方法を案内しているわけではありません。あくまでモデルが重要と判断したものが残る仕組みです。

そのうえで私が実務で取っている方法は単純で、覚えておいてほしい判断は、その場で明示的に言葉にすることです。「この方式はA案の理由で採らない、以後この前提で進めて」と一度はっきり言語化しておくと、要約されるにせよメモされるにせよ、残る確率が上がります。曖昧なまま流れた合意は、まず残りません。

ただしこれは確率を上げる工夫であって、保証ではありません。絶対に守らせたいことは、会話ではなくファイルに書く——この線引きは、機能が新しくなっても動かさないほうがよいと考えています。

中小企業の現場ではどう受け止めればよいか

ここまで設定ファイルの話をしてきましたが、これは非エンジニアの方が自分で触る種類の設定ではありません。それでも、経営側が知っておく価値はあると考えています。

私がクライアント先で「AIが指示を守らない」「前に言ったことを忘れる」という相談を受けるとき、原因は多くの場合モデルの性能ではなく、情報の置き場所にあります。会話の中でしか伝えていないルールは、会話が長くなれば失われます。当たり前のようですが、AIに任せる業務が増えるほどこの前提が忘れられがちです。

今回の変更が示しているのは、ツール側もその問題を仕様レベルで解こうとしているという事実です。ただし、解かれるのは「1回の作業の中で忘れる」部分だけです。会社としての判断基準や手順は、引き続き人間が明文化して置いておく必要があります。私が支援に入るときも、最初にやるのはツールの設定ではなく、暗黙のルールを書き出して、AIが毎回読む場所に置く作業です。

Claude Codeを使っている場合も、事情は同じです。ツールごとに仕組みは違いますが、考え方は共通しています。

Claude Code 1Mコンテキストの落とし穴｜セッション管理の実践法

よくある質問

既定になるまで待ったほうがよいですか

業務の本番フローで使っている環境なら、待つ判断は妥当です。個人の開発環境なら、先に入れて自分の長時間作業で挙動を確かめておくと、既定化されたときに慌てずに済みます。

compactionは完全になくなるのですか

公式が述べているのは「単一の要約に繰り返し圧縮するのではなく、メモと検索可能な履歴を使う」という方式の置き換えです。compactionに関する設定キー自体は引き続きconfigリファレンスに掲載されており、この機能が有効なときに従来の圧縮がどう扱われるかまでは公表されていません。断定的な理解は避け、公式ドキュメントの更新を追うことをおすすめします。