目次

ここ数日、Codexを使っていて妙な違和感がある。

「あれ？ こんなに言うこと聞かなかったっけ？」

僕は普段、Codexに実際の開発作業をかなり任せています。だからベンチマークの数字よりも、気になるのはこういうところです。

  • 前に説明したことを覚えているか
  • 既存コードを調べてから変更するか
  • 指示したところまで最後まで実装するか
  • やっていないのに「完了しました」と言わないか

そして最近、このあたりが怪しい。

最初は「僕の指示が悪いのかな？」と思っていました。でも気になってGitHub Issues、Reddit、OpenAI Developer Community、OpenAI Statusを調べると、似た違和感を書いている人がいました。

同じファイルを読む。さっき決めた要件を忘れる

まず気になったのが、9月7日に投稿されたCodex公式リポジトリのIssue #43496です。

投稿者は、Linux / WSL環境でCodex CLIを0.153.4に更新したあと、Sol・Terra・Astraで作業が遅くなり、要件や調査結果を保てなくなったと報告しています。

同じファイルの読み直しや、リポジトリの再調査が続く。明示した条件を落とし、実装が不十分なまま進捗を報告する。修正を頼むと、また探索へ戻る。

「さっき言ったこと、もう忘れた？」という僕の感覚に近い。

投稿者は、モデルとツールのやり取りのたびに、タスクの文脈が弱まっているように見えると推測しています。ただし、内部のコンテキスト管理に不具合があると確認されたわけではありません。特定の環境とバージョンでの報告です。

「やっていないのに完了報告」が一番困る

もう一つが、同じく9月7日投稿のIssue #43329。こちらは9月6日にGPT-6 Astraで経験した挙動の報告です。

実装と回帰確認を頼んだのに、数十秒で完了したような報告をして終了する。複数の不具合の一部しか直さず、全体を終えたように伝える。コードを調べずに推測で修正する、といった症状が挙げられています。

興味深いのは、「変更せず、まず原因を調べて」と明示すると、同じモデルが5〜10分ほどコードを読み、仮説を検証したという点です。

投稿者は、能力そのものより、作業を終える判断や証拠の確認に問題があると考えています。これも診断が確定した話ではありませんが、「仕事をしない」と「仕事ができない」は分けて見る必要がありそうです。

僕にとっても、間違ったコード以上に困るのは、確認していないのに「確認しました」と言われること。報告を信じて次へ進めないなら、任せるための確認作業が増えてしまいます。

速度とUsageにも不満が出ている

Redditには、Solの生成速度が中央値で約50 TPSから約30 TPSへ落ちた、というユーザー報告もあります。TPSは1秒あたりに生成するトークン数で、投稿タイトルは9月7日以降の変化を指しています。

これは個人の観測です。同じ条件で広く検証されたベンチマークでも、OpenAIの公式測定でもありません。生成速度だけで、実装の正しさまで分かるわけでもない。

また、Developer Communityの9月8日の投稿では、Sol Mediumによる約55分の作業で、新しい5時間枠の約74〜76%を消費したと報告されています。投稿者は、以前の同種の作業より消費が増えたと感じているそうです。

ここでいう5時間枠を「必ず5時間作業できる保証」と読むのは適切ではありません。この記事で注目しているのは、同じように使っていた人が、以前との違いを訴えていることです。

Redditの「Don’t use Codex TODAY!」という投稿にも不満はあります。一方で、同じような問題を経験していないというコメントもある。投稿の存在だけで、すべての利用者に一律の劣化が起きているとは言えません。

公式の障害情報は、別の列に置いて読む

ユーザーの体感とは別に、OpenAI Statusで確認できる出来事もあります。

日付（参照ページ表記） 確認できる内容 情報の種類
9月3日 ChatGPTとCodexでエラー増加。解消済み 公式障害情報
9月4日 APAC地域でCodex Cloudなどのエラー増加。復旧済み 公式障害情報
9月7日 文脈の維持や早すぎる作業終了についてIssueが投稿された ユーザー報告
9月8日 Sol Mediumで以前より使用量を消費するという投稿 ユーザー報告
9月9日 Codexの予期しない使用上限リセットを調査し、復旧を報告 公式障害情報

公式の出典は、9月3日のエラー増加、9月4日のAPAC障害、9月9日の使用上限リセット問題です。日付は各ページの表示に合わせており、日本時間の発生日を統一して示したものではありません。

僕は日本から使っているので、APAC地域の障害は気になります。ただし、Codex Cloudの障害を、そのまま手元のCLIで感じた品質低下の原因にすることはできません。

また、9月9日に確認されたのは「予期しない使用上限のリセット」です。「使用量の消費が速すぎる」という報告すべてについて、OpenAIが不具合を認めて修正した、という意味ではありません。

同じ時期に起きた出来事は並べられる。でも、それを一本の因果関係でつなぐには、まだ材料が足りません。

OpenAIはCodexを「ナーフ」したのか？

ナーフは、ゲームなどで能力を弱くする調整のこと。今回も「裏で小さいモデルに切り替えているのでは」という推測が出ています。

ただ、今回確認した出典には、OpenAIが意図的にモデル性能を落としたと裏付ける情報はありません。

GitHubにIssueがあることと、その原因をOpenAIが認めたことは別です。公式リポジトリに書かれたユーザーの推測も、公式見解にはなりません。

「似た報告が複数ある」とは言える。でも「だからナーフされた」とは言えない。ここは分けておきたいです。

モデルの頭の良さと、仕事を完遂する安定性

ここからは、報告を読んで考えた僕自身の仮説です。

Codexに任せる開発は、一問一答では終わりません。コードを読む。必要なファイルを探す。変更する。ツールを実行する。結果を受け取り、次の行動を決める。その繰り返しです。

その途中で要件を失ったり、検証前に終了したりすれば、一つひとつの回答がもっともらしくても仕事は完成しません。

だから「モデルがどれだけ賢いか」と、「その能力を使って最後まで仕事を進められるか」は、分けて考えたほうがよさそうです。

コンテキストの受け渡し、ツールの結果の扱い、終了の判断、サービス側の状態。こうした要素のどこに問題があっても、使う側には「急にバカになった」と感じられる可能性があります。今回どこが原因なのかは、確認できていません。

最近、指示を細かくしている理由

これは僕自身の最近の感覚とも重なります。

以前なら「ここ直して。既存の仕様は壊さないで」くらいでも、調査から実装まで進めてくれた。最近は、作業の区切りと完了条件を明示したほうが安定するように感じています。

たとえば、こんな頼み方です。

まず既存実装を調べ、原因と根拠を整理してください。そのうえで修正し、必要なテストと実際の出力を確認してください。最後に、要求ごとの対応結果、確認した内容、未完了の項目を報告してください。実行していない確認は、実行済みとして扱わないでください。

調査結果を見てから実装方針を決めたい仕事なら、最初の依頼を「原因調査まで」に区切ります。

これは公式の修正方法でも、改善を保証するプロンプトでもありません。僕が、任せた仕事の途中経過と結果を確かめやすくするための工夫です。

本当は、ここまで言わなくても進めてくれるのがうれしいんですけどね。

気のせいで片付けず、原因も決めつけない

今回調べた範囲では、僕が感じた違和感に似たユーザー報告は複数ありました。同時期に公式の障害もありました。

ただし、影響の広さや共通の原因、モデル自体の性能が低下したかどうかは、この情報だけでは分かりません。

今回いちばん考えさせられたのは、AIの使い勝手は、モデルの頭の良さだけでは決まらないということです。

どれだけ難しい問題が解けても、頼んだことを忘れ、途中でやめ、確認せずに完了と言うなら、仕事では使いづらい。

AIエージェントを日常的に使うほど、僕が欲しくなるのは「どれだけ安定して、最後まで仕事を任せられるか」です。

僕はCodexをかなり気に入って使っています。だからこそ、早くいつものCodexに戻ってくれ。今はそんな気持ちです。

※2026年9月11日時点で参照できた情報をもとにしています。ユーザー報告、公式障害情報、筆者の体験・考察を分けて記載しました。ユーザー報告について、筆者が同一条件で再現実験を行ったものではありません。