GPT-6 Astraの品質問題が修正されたという話が気になりました。最初ほど仕事を進めてくれなくなるのは、モデル自体の変化なのか、使い続けた会話の問題なのか。Claude Codeでも起きるのかを含めて、公開情報と手元の設定を確認してみました。
2026年9月14日時点の技術メモです。ローカルでは設定とCLIのバージョンを確認しましたが、モデルの性能比較や修正前後の再現実験はしていません。
今回、何が修正されたのか
まず、今回のパッチが何を指すのかを確認しました。検索ではモデルの表示を直すCodexの更新も出てきたため、品質問題の修正と区別する必要がありました。
該当する説明は、Tibo Sottiaux氏が9月12日に公開した投稿でした。利用者と調査し、次の問題を見つけて修正したと説明しています。
| 対象 | 報告された問題と対応 |
|---|---|
| 以前のモデル向けのスキル | 一部が過剰に発動したり、作業の自己確認を妨げたりしていました。修正済みと報告されています。 |
| オプトインの文脈管理実験 | 途中で止まる、古いメッセージに返答する問題があり、実験を無効化しました。影響は概算で4,000〜5,000人です。 |
| 一部の配信エンジン | 設定不備のあるエンジンを通る一部のトラフィックで、品質低下を測定し、該当エンジンを除去しました。 |
4,000〜5,000人という数字は、文脈管理実験についての推定です。品質問題全体の影響人数ではありません。
ここで私の捉え方が少し変わりました。モデルへのパッチと聞くと、学習済みのモデルを作り直したように受け取っていました。しかし、この投稿が説明しているのは、指示や文脈の扱い、配信環境の修正です。重みの更新や再学習をしたとは書かれていません。
また、エンジンのどの設定が誤っていたのかは公開されていません。量子化、計算量の削減、別モデルへの切り替えなどを、今回の原因として断定できる情報はありませんでした。
モデルと、それを動かす仕組みを分ける
前提として、GPT-6 Astraはモデル名です。CodexやClaude Codeは、モデルに指示を渡し、ファイルを読み、ツールを実行するための製品です。
普段見ている結果には、モデルの能力だけでなく、渡された指示、会話履歴、ツールの結果、実行環境も含まれています。モデルが同じでも、これらが変われば仕事の進み方は変わります。
たとえば、作業を終えたらテストする能力があっても、読み込まれたスキルが確認を止めてしまえば、未検証の成果物が返ってきます。最新の依頼を正しく解釈できても、文脈管理が古い依頼を渡せば、違う仕事に答えてしまいます。
これは今回の報告から考えた例です。実際にどの指示や内部処理が問題だったかを再現したものではありません。ただ、体感ではどれも、モデルが以前より頼りなくなったように見えると思います。
時間が経つ、には二つの意味がある
最初は、公開直後より悪くなることと、長い会話の後半で失敗が増えることを一緒に考えていました。ここを分けないと、対処を間違えそうです。
| 観察している変化 | まず切り分けたい対象 |
|---|---|
| リリースから数日後、新しい会話でも結果が変わる | 提供側の変更、不具合、クライアント更新、設定、課題の違い |
| 同じ会話を続けるうちに、要件を落とし始める | 履歴の増加、古い仮説、指示の競合、文脈の圧縮や引き継ぎ |
| 同じ条件でも、成功する回と失敗する回がある | 出力のばらつき、ツールや配信経路の差。一度の比較では原因を決めません。 |
通常の推論では、使うたびに学習済みの重みが消耗する、という仕組みではありません。固定したモデルが、時計の進みによって一律に能力を失うと考える必要はないと思います。
公開後のサービスでは、モデルの周囲が更新されます。同じ会話の中では、モデルへ渡す内容が増えたり、圧縮されたりします。どちらも時間とともに進みますが、変わっているものは別です。
長い会話では、情報が残っていても使い切れない
コンテキストウィンドウは、一度の処理で扱える情報量の上限です。入力できる量と、必要な情報を正確に使えるかは同じではありません。
Lost in the Middle では、回答に必要な情報を入力の中央に置くと、先頭や末尾に置いた場合より性能が下がる例が報告されています。これは2023年の研究で、Astraを測った結果ではありません。長い入力を受け付けることだけでは、情報の利用を保証できないという参考になります。論文
Anthropicも、入力が長くなるにつれて情報の想起が難しくなる現象を context rot として説明しています。程度はモデルによって異なります。Context engineeringの解説
技術調査では、単に文字数が増えるだけではありません。最初に疑った原因、否定した仮説、古いコード、失敗したコマンドが同じ会話に残ります。
たとえば、途中で依存パッケージを追加しない方針に変えたのに、前半にはパッケージの選定理由が長く残っている場合です。最新の条件に従う必要がありますが、古い案を再び採用してしまえば手戻りになります。
このような失敗は、履歴がどう構成されているかを調べる理由になります。ただし、長い会話で失敗しただけで、原因を必ず context rot と決めることもできません。今回のような文脈管理の不具合でも、似た症状は出ます。
圧縮すれば解決するとも限らない
長い作業では、会話を圧縮して次の処理へ引き継ぐ compaction が使われます。OpenAIのAPIにも、過去の状態を少ないトークンで引き継ぐ仕組みがあります。返される圧縮項目は不透明で、人が読める要約とは限りません。OpenAIのCompactionドキュメント
情報を減らすと、不要な履歴を整理できます。一方で、次の判断に必要な条件まで落ちると、正しく続行できません。ClaudeのAgent SDKの説明にも、圧縮後に会話の初期の細かな指示が残らない可能性が書かれています。Agent loopの説明
私が技術メモで残したいのは、現在の結論だけではありません。ある案を採用しなかった理由も必要です。これが引き継がれないと、一度確認して却下した方法を、もう一度調べ始めることになります。
ただし、一般的な圧縮と、今回無効化されたオプトイン実験は同一視しません。9月12日の投稿だけでは、実験の内部実装や、不具合が起きた正確な処理までは分かりませんでした。
Claude Codeでも起きるのか
Claude Codeなら避けられる、とまでは言えません。長い会話の問題と、提供側の障害の両方について資料がありました。
Claude Codeの公式ガイドは、文脈が埋まるにつれて性能が落ち、以前の指示を忘れたり、間違いが増えたりすることを説明しています。別の作業に移る際の /clear や、長い作業を続けるための /compact が案内されています。Claude Codeのベストプラクティス
提供側の例では、Anthropicが2025年9月17日に公開した障害報告が参考になりました。これは今回のAstraとは別の、過去のClaudeの障害です。
報告された原因は、コンテキスト長に応じたリクエストの振り分けミス、出力トークンの生成異常、TPU向けコンパイラの不具合でした。振り分けミスでは、該当期間に利用したClaude Codeユーザーの約30%が、少なくとも一度影響を受けたと説明されています。これは全リクエストの30%という意味ではありません。Anthropicの障害報告
同じ報告では、負荷分散の変更で影響範囲が広がり、問題が出る人と正常に使える人が混在したとしています。モデルの学習だけを見ていては説明できない品質変動が、Claudeでも実際に起きていました。
この事例から、現在のClaudeが不調だとも、Astraと同じ原因だとも言えません。比較するときは、製品名だけで安定性を判断せず、履歴と配信環境の両方を見る必要があると感じました。
手元では、まず何を確認したか
今回は、いきなり大量のプロンプトを流す前に、比較の前提を確認しました。修正前の配信エンジンを指定できず、過去の同条件の出力も用意していないためです。今のモデルが一度成功しても、今回の修正で改善した証明にはなりません。
手元のmacOSで、PATH上のCLIと、ホームディレクトリにあるCodexの設定ファイルを読み取りました。
| 確認項目 | 2026年9月14日の結果 |
|---|---|
| OS・CPU | macOS・arm64 |
| PATH上のCodex CLI | 0.147.0 |
| PATH上のClaude Code | 2.1.270 |
| 確認したCodex設定のモデル | gpt-6-astra |
| 同じ設定の推論強度 | high |
features.context_management.experimental_mode | 明示設定なし |
ここで気をつけたいのは、PATH上のCLIとデスクトップアプリが使う実行環境を同じと扱わないことです。この表から、利用中のアプリも 0.147.0 だとは判断できません。
実験のキーが書かれていなかったことも、その設定ファイルで確認できた範囲の話です。起動引数や別の設定、過去の実行状態までは確認していません。今回の不具合に遭遇したかどうかは、この結果だけでは分かりませんでした。
確認用のスクリプトと結果は、記事リポジトリの examples/astra-quality-audit/ に残しました。Python 3.11以上で実行できます。
python3 examples/astra-quality-audit/audit_environment.py
このスクリプトが読むのは限定した設定項目とCLIバージョンです。モデル推論は実行しません。今回は、環境確認までを実施した内容として記録しています。
次に比較するなら、履歴と設定を一つずつ変える
ここからは未実施の検証案です。AstraとClaude Codeに別々の仕事を頼み、印象を比べても、何が違ったのかが残りません。小さなコード修正と、その成否を判定するテストを先に固定したいと思います。
最初に比較するのは、短い仕様だけを渡す条件と、同じ仕様に固定した長い履歴を加える条件です。コードの初期状態、モデル、推論設定、利用可能なツールはそろえます。両方に同じ最新要件を入れて、条件ごとに最低5回、順序を入れ替えて実行します。5回は傾向を見るための小さな試行で、統計的な結論には足りません。
過去の誤答を追加する実験や、履歴を圧縮する実験は、その後で別に行います。長さ、誤情報、圧縮を一度に変えると、失敗した理由を絞れないためです。
見たいのは回答の長さより、要求した仕事を終えたかどうかです。外部のテストで要件充足を確認し、途中停止、テスト未実行、実行していないのに成功と報告した回数を記録します。時間とトークン数は別の指標として残します。
Claude Codeでも同じ課題を使います。ただし、Codexとの比較には、モデル以外に指示やツールの差も含まれます。製品としての完了率を見る比較と、共通のAPI評価器でモデルを比較する実験は、分けて考えたいです。
この方法で調べられるのは、現在の環境で履歴や設定を変えた影響です。修正前の環境がなければ、9月12日の修正による改善幅までは測れません。
次の長い作業で試したいこと
今回調べて、品質低下をすべて気のせいとして扱うのも、すべてモデル本体の変化と考えるのも早いと感じました。Astraでは周辺の仕組みに実際の不具合があり、Claudeにも配信基盤による品質低下の記録がありました。
手元ではまず、最新の要件、却下した案と理由、未完了の作業、検証結果を短いメモに残したいと思います。Claude Codeで作業を切り替える場合は、そのメモを用意してから /clear します。同じ作業を続ける場合は、たとえば次のように残したい内容を指定します。
/compact 最新の要件、変更したファイル、却下した案と理由、テスト結果、未完了の作業を残してください。
これはClaude Code向けの操作例です。圧縮しても必要な情報が残ったかは確認します。
次は同じ課題を新しい会話と長い会話で比べ、どの条件で手戻りが増えるのかを残したいです。モデル名だけで判断するより、自分の作業が最後まで終わる条件を確かめるほうが、日々の使い方につながると思います。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK