Codex の悪化は魔法ではない：エラーを減らし、コンテキストをリセットする

まず短くまとめる。

1. AGENTS.md に DO NOT send optional commentary を追加する。グローバルでもプロジェクト単位でもよい。Codex が「悪化する」確率を下げられるかもしれない。
2. AI は不安定だが、人間のように創造的でもある。純粋に決定的なソフトウェアでは解けない問題を解けることがある。私たちの仕事は、その二つの間でバランスを見つけることだ。
3. 奇妙な失敗にぶつかったら、もう一段深く考える。問題の形の中に、実用的な mitigation が隠れていることが多い。

---

人々が Codex が「悪くなっている」と感じるとき、それは必ずしも提供元が意図的にモデルを弱くしたという意味ではないと思う。より有用な説明は、ある瞬間、あるバージョン、あるコンテキストの中で、間違いの確率が上がっているというものだ。AI は従来のソフトウェアのように安定していない。同じロジックが常に同じ結果を生むわけではない。各ステップは、あるコンテキストと多少のランダム性から生成される。うまくいっているときは、それは協業のように感じられる。うまくいかないときは、コンテキストが増幅器になる。間違った説明、偽のツール呼び出し、未検証の仮定がコンテキストに入り、次の判断に影響する。

だから AI がたまに間違えるとき、最大の問題はその回答そのものではない。その間違った回答が、次の回答の材料になることだ。続けて質問すれば、モデルは前の間違いを事実として扱うかもしれない。修正を求めれば、間違った前提の周りを延々と patch し続けるかもしれない。さらにコンテキストを足せば、新しい説明に織り込む noise が増えるかもしれない。これが多くの人が「悪化」と感じるもの、あるいは loop にハマる感覚だ。

DO NOT send optional commentary

今日、X で DO NOT send optional commentary を AGENTS.md に追加すると Codex 5.5 の劣化が大きく改善する、という投稿を見た。

たどっていくと、元の議論は Linux.do にあった。投稿者のテスト環境では精度が明らかに改善したが、投稿者自身も何度も、これは問題を緩和するだけであり、解消するものではないと強調していた。

この観察は私の推測とも合っていると思う。この一文は魔法ではない。効く理由は、モデルの optional output を減らすからだ。Codex が作業するとき、実際のタスクの周囲に中間説明、進捗メモ、推測、要約をよく追加する。通常なら、それらはコミュニケーションを助ける。だがモデルの状態が悪いとき、その「任意の」言葉が汚染源になることがある。早すぎる結論を出す、実際には起きていない手順を説明する、ツール呼び出しを自然言語に混ぜる、といったことが起こる。

話す量を減らしても、モデルが賢くなるわけではない。ただ、無関係なコンテキストが少なければ、モデルが自分で道を外す機会も少なくなる。

これは Codex だけの問題ではない

私は Claude でも同じ種類の問題に遭遇した。モデルが通常の preview flow を続ける代わりに、ツール呼び出しのようなテキストを出力した。その後、その会話では同じ問題が繰り返し現れた。別の会話に切り替えると、問題は突然消えた。この挙動は、問題が一つのモデル内部だけにあるわけではないことを示している。agent toolchain の中でも起こりうる。モデル、system prompt、tool protocol、context window、現在の service state のすべてが噛み合っている必要がある。どれか一つが揺れるだけで、出力は不安定になりうる。

一度その信号が出たら、同じ会話の中で修正を求め続けることは、多くの場合 recovery ではない。汚染を大きくする可能性がある。モデルはすでに「何が起きたか」という説明をコンテキストに書き込んでおり、その説明自体が間違っているかもしれないからだ。

二つの方向：予防と損切り

一つ目の方向は、間違いの確率を下げることだ。プロジェクトルールを AGENTS.md に書く。編集前にコードを読ませる。不要な commentary を減らす。大きなタスクを小さな目標に分ける。テストを実行させ、検証結果を報告させる。重要な仮定は先に確認させる。これらの実践は、AI を完全に信頼できるものにはしない。ただ、不確実な領域でモデルが自由に即興する余地を減らす。

二つ目の方向は、早めに損切りすることだ。同じ bug を何度も直している、説明は長くなるのにコードは改善しない、期待した出力形式が壊れる、ツール呼び出しをテキストとして出す、直前に与えた制約を無視する。こうした兆候が出たら、同じ thread を救おうとし続けない方がよい。多くの場合、新しい会話を始め、きれいに圧縮した brief を渡す方がよい。目的、現在のエラー、重要なファイル、すでに検証した事実だけを渡す。

これは agent の強みでもある。作業成果は disk に保存されるので、複数の会話を使って一つのタスクを完了できる。

これは engineering hygiene として扱うのが正確だ。コンテキストが汚れたら、コンテキストを掃除する。タスクが大きすぎたら、分割する。出力が自分自身を汚染し始めたら、その連鎖を切る。

結論

Codex が悪化するのは魔法ではないし、一行の prompt で完全に解決できる問題でもない。確率の問題とコンテキストの問題が重なったものとして理解する方がよい。あるとき間違いが起きやすくなり、一度間違いがコンテキストに入ると、その後の間違いも起きやすくなる。

DO NOT send optional commentary は試す価値がある。コストが低く、トレードオフも明確だからだ。中間メモが少なくなる。しかし、より大きな作業習慣の方が重要だ。減らせる noise は減らし、確認できるものは確認する。そして会話が loop し始めたら、その loop と戦わない。作業をきれいな会話に移し、そこから続ける。

もしもっと良い practice があれば、ぜひ聞きたい。AI agent の使い方や vibe coding について質問があれば、コメントで議論してほしい。