Codexがテストを繰り返して終わらないときの見直し方

Codexがテストを繰り返して終わらないときは、いったん中断して直近の差分と失敗内容を確認し、具体的な完了条件を示して再開します。 修正を検証するテストは残します。何も変えていないのに同じコマンドを繰り返すことと、新しい不具合を直して再検証することは別です。

この手順は、すべてのCodex環境や特定のモデルに不具合があると断定するものではありません。処理待ち、ネットワーク、権限、テストの規模が原因で時間がかかっている場合もあります。

何が繰り返されているかを確認する

最後のコマンドは失敗しましたか。再実行する前に、関連するコードは変更されましたか。実行中の処理はまだ出力を返していますか。環境の問題をコードの不具合として直そうとしていないかも確認します。

ループから抜けるために作業中のファイルを捨てる必要はありません。先に変更内容を確認し、再開できる状態を残します。Codexのリセット時刻の確認は利用枠の話であり、テストの問題とは切り分けます。

終了条件を観察できる形にする

「アプリを堅牢にする」では、どこまで直すかが広がりがちです。「空の検索で例外が出ないようにし、空の場合と通常の場合を確認する」なら、完了を判断できます。

次の指示は、リポジトリに合わせて書き換えるための例です。利用量の削減を実測したものではありません。

既存の検索コンポーネントで、空の入力による例外を修正してください。
無関係なリファクタリングは今回の対象に含めません。
編集前に、修正を確認する最小限のチェックを示してください。
実質的な変更後に、そのチェックとプロジェクト必須の検証を実行してください。
変更や新しい失敗がない場合は、理由なく同じチェックを繰り返さないでください。
新しい仮説なしに同じ失敗が続く場合は、停止して状況を報告してください。
最後に、変わった動作、実施した確認、残っている不確実性をまとめてください。

セキュリティや回帰の必須チェックは省略しません。目的は検証をなくすことではなく、変更と検証を結び付けることです。

引き継いだ指示の食い違いを見る

今回の依頼、プロジェクトの指示、使用するスキルで、作業範囲が食い違っていないか確認します。小さな修正のつもりでも、別の指示が広範囲の監査を求めている場合があります。

環境の問題でコマンドを実行できないなら、受け入れ条件のテストが失敗した場合とは分けて報告します。早く終えるために権限を回避したり、保護を無効にしたり、成功したことにしてはいけません。

受信途中で切断された場合はストリーム切断の確認手順を使います。最初から依頼し直す前に、既存の変更と再開地点を確認してください。

トークン数だけで効率を判断しない

キャッシュ読み取り、通常入力、出力ではAPIの単価が異なる場合があります。また、ChatGPTの契約で使える枠とAPIの請求は同じものではありません。契約上の利用量は公式のCodex料金案内と、自分のアカウントの表示で確認します。

2026年9月16日に撮影したOpenAIのAPIキャッシュ仕様です。原典の英語画面を掲載しています。Codexの契約上の利用枠を換算する表ではありません。

経過時間、合格した成果物、手作業での修正、請求された再試行を記録します。モデルを比べるなら、同じリポジトリ状態、課題、権限から始めてください。AstraとSolの比較も、価格だけでなく完了した仕事を比べるための出発点になります。