Codexの「揺れ」を抑える実践ガイド

文脈・セッション・受入試験で安定させる方法
Codexは優秀なコーディングエージェントですが、長く使っていると「同じ指示でも挙動がぶれる」現象に遭遇します。これは気分の波ではなく、原因が特定できる構造的な揺れです。本記事では、実際の運用で見えた4つの原因と、それを抑えるためのベストプラクティスをまとめます。
揺れが起きる4つの原因

1. 毎回まっさらな状態から文脈を組み立てる
   Codexは基本的にstatelessです。1回ごとに固定文 → scope.md → progress.md → Issue の順で読み直し、文脈を組み立てます。読む物が長いと、どの文を重く見るかが回ごとに変わります。
2. 同じ入力でも出力が揺れる
   これはモデルの性質です。参考になる事例でも「ある失敗は2回に1回しか出ない」と指摘されており、Codexも同様です。「退役させない」を「新を主にしない」と読んだり、既存コードを流用せず書き直したりする解釈差は、前後の回では起きないことがあります。これは消せません。
3. 回の後半で質が落ちる
   90分を超え、入力トークンが500万〜1,100万に達するような回では、後半に「ついでの確認」「全試験の再実行」「長い報告」が増え、無言停止も後半に集中しやすくなります。
4. 前の回の要約に引きずられる
   progress.mdに前の回が「待ち」と書くと、次の回も待ちから始めます。この連鎖で同じ状態が続くことがあります。
   ベストプラクティス
   文脈は短く・具体的に保つ
   scope.mdやタスク定義は極力短くします。20ブロック・数十KBの追記は避け、15〜30行程度に圧縮するだけで揺れは大きく減ります。曖昧な表現は排除し、「次はこれをする」と具体的に書くのが効果的です。
   セッションを短く区切る
   1セッション1件を基本にします。受入が通ったら必ず終える。目安は60分以内です。長時間・高トークンのセッションはcompactionが繰り返し発生し、実行フロンティア（何が完了していて次に何をすべきか）が劣化しやすいためです。
   受入試験をゲートにする
   「終わり」をモデルの自己判断に任せません。機械的な受入試験を用意し、試験が通らなければ終われない構造にします。解釈が揺れても、試験が基準になります。
   ExecPlan / PLANS.md を活用する
   OpenAIが推奨する形式を使うと安定しやすいです。必須要素は以下の通りです。
   • Progress：チェックリストで現状を正確に反映し、次の一手を具体的に書く
   • Decision Log：なぜその判断をしたかを記録する
   • マイルストーンごとに「何が存在すれば完了か」を明確にする
   これで「前の回の要約に引きずられる」問題をかなり抑えられます。

まとめ
揺れの大半は、渡す文脈の長さ・曖昧さ・回の長さが作っているものです。残る本質的な揺れ（モデルのサンプリングと解釈の非決定性）は、受入試験で機械的に押さえます。
Codexは「長時間の自律エージェント」として使うより、「短い作業単位を、明確な受入基準で繰り返す」方が安定します。文脈を短く保ち、1件1回で切り、受入試験をゲートにし、次の一手を具体的に書く。この4つを守るだけで、体感する揺れは大きく減ります。