Codexループの止め方と原因別の確認・再開方法の要点整理

Codexループとは何か──「反復」と「進捗」を分けて見る

コーディングでは、テストが失敗したら原因を直し、もう一度確認するという反復が普通に起きます。したがって、同じ種類の操作が二度行われただけでループとは言えません。Codexループと呼べるのは、試行を重ねても変更差分、検査結果、判断材料のいずれも増えず、同じ地点へ戻り続ける状態です。人が画面を見ていると会話が動いているため気づきにくいものの、ファイルの内容と確認結果を前の試行と比べれば、実質的な進捗がないことを見つけられます。

最初に確認したいのは、Codexが「考え直している」のか「同じ操作を再実行している」のかという違いです。新しい仮説に基づく変更や、失敗理由を説明する結果があれば反復には意味があります。反対に、同じファイルを読んで同じ結論を出し、差分を増やさないまま次のターンへ進むなら、いったん止める判断が必要です。公式リポジトリの報告にも、作業が完了しないまま利用量を消費したという事例がありますが、個別報告をすべての環境へそのまま一般化してはいけません。

同じ処理が続く3つのサイン

一つ目のサインは、同じファイル、同じ検索語、同じ確認コマンドが短い間隔で繰り返されることです。二つ目は、Codexの説明が「次に修正する」「確認を始める」と言い換えられるだけで、実際の差分や検査結果が増えないことです。三つ目は、コンテキストを整理した直後に、完了した調査まで最初からやり直すことです。三つが重なるほど、待ち続けるより状態を保存して止める価値が高くなります。

ただし、同じファイルを再度読むこと自体は悪くありません。直前の変更で前提が変わった、テスト結果を受けて呼び出し元を確認した、という理由が説明できるなら必要な再確認です。判断の基準は回数ではなく、前回から何が変わったかです。差分、実行結果、対象範囲のどれかを一行で説明できるかを見ます。

正常な反復との境界

正常な反復には、次の試行へ渡す新しい材料があります。たとえば失敗したテストの行番号が特定され、修正後に別のテストが通り、次の問題が見つかったなら、作業は前進しています。一方、失敗した理由が不明なまま同じ入力だけを送り直し、同じ出力を受け取る状態では、入力と確認条件を変えない限り改善を期待できません。完了条件を明示し、意味のある差分がない場合は報告して止まるよう依頼することが境界を作ります。

なぜ今ループ対策が重要か──Agents APIと長時間セッション

OpenAIは2026年9月10日、Codexで得た実行基盤を開発者へ提供するAgents APIの公開ベータを発表しました。公式発表では、モデル、指示、道具、環境を指定してエージェントのセッションを作り、長い作業を続けるための文脈管理や、複数のサブエージェントによる分担を扱えると説明されています。これはCodexループを新しく定義する発表ではありませんが、短い一問一答だけでなく、数時間にわたり状態を保つ作業が現実的になったことを示します。長く任せられるほど、止める条件と確認の区切りを先に置く意味が大きくなります。

長時間タスクでは、画面上の発言だけで進捗を判断しないことが大切です。ファイルの差分、テストや検査の結果、最後に人が判断した時点を別々に見ます。コンテキストの整理が入っても、すでに完了した作業と次の一手が保たれていれば正常な継続です。整理のたびに同じ調査へ戻るなら、圧縮そのものを責めるのではなく、保存されている状態と依頼の完了条件を見直します。

9月10日の発表から確認できること

Agents APIの発表で確認できるのは、長いセッションを支える文脈管理、道具の定義を必要なときに扱う仕組み、複数のサブエージェントを使える公開ベータが案内されたという事実です。OpenAIは、Codexの仕組みを基礎に、モデル更新に合わせて実行基盤も改善すると説明しています。利用者がこの情報から得るべき実務上の示唆は、長い作業ほど「目的」「対象」「結果の保存場所」「終了条件」を最初の依頼に含めることです。出典はAgents APIの公式発表です。

発表から推測してはいけないこと

公開ベータの発表だけで、現在使っているCodexアプリやCLIの画面に同じ機能が表示される、すべてのアカウントで同じモデルが選べる、ループが自動で検出される、と断定することはできません。APIの公開範囲、アプリの版、利用するモデル、作業環境は別の確認項目です。個別の症状を見つけたら、発表内容を原因の証拠にせず、発生した入口、版番号、繰り返した操作、差分の有無を記録して切り分けます。

症状を4種類に分ける──原因を決めつけない診断表

「ループしている」という言葉だけでは、どこを止めればよいか分かりません。Codexの作業ターン、背景で走る端末、コンテキストの継続、画面表示は別の層です。最初の一分で層を分ければ、セッション全体を閉じる必要があるのか、端末だけを止めればよいのか、表示を開き直せばよいのかを選びやすくなります。次の表では、観測できる症状と最初の確認先を対応させます。

表の「最初に見るもの」は、原因を確定する証拠ではなく、次の確認先を絞る入口です。たとえば背景端末に同じ出力がある場合、会話の発言を読み続けても端末の停止にはなりません。逆に、画面のスクロールだけが循環している場合は、ファイル差分が変わっていないことを確かめれば、作業ターンのループと分けられます。公式リポジトリには長い会話の表示位置が循環する報告もあるため、表示の異常と作業の異常を同じ扱いにしないことが重要です。出典: Codex公式リポジトリの表示に関する報告

進捗の証拠を3つそろえる

診断時は、会話の文章よりも、変更差分、確認結果、対象範囲の三つを優先します。変更差分が増えたか、検査結果が改善したか、対象ファイルが依頼した範囲に収まっているかを確認してください。三つとも変わっていないなら、次のターンを待つ理由は弱くなります。どれか一つだけ変わった場合も、変化が完了条件に近づいているのかを判断し、関係のないファイルや出力が増えただけなら止めて整理します。

まず消費を止める──セッションを残したまま中断する

ループを疑ったときに最優先なのは、原因をその場で言い当てることではありません。変更や利用量が増え続ける状態を止め、後から確認できる情報を残すことです。現在のCodex CLI公式資料では、背景端末の一覧を/psで確認し、/stopで現在のセッションに属する背景端末を停止できます。一方、/stopは背景端末向けの操作なので、エージェントの進行中ターンをすべて止める命令と同じ意味ではありません。画面に停止操作がある場合はそれを使い、CLIでは公式資料にあるCtrl+Cや/exitの意味を確認してから実行します。

停止直後にセッションを削除したり、作業フォルダーを初期化したりすると、原因を調べる材料まで失われます。まずは現在の画面、版番号、最後の出力、差分の状態を保存し、その後に必要なら新しいセッションへ移ります。公式コマンド資料でも、/diffはステージ済み・未ステージ・未追跡の変更を確認するための操作として案内されています。ループが疑わしいときほど、先に差分を見る順番を守ることが重要です。

Step 1: まず動いている対象を確認する

画面の最終メッセージだけでなく、現在のセッション名、対象フォルダー、Codexの版番号、選択中のモデル、背景端末の有無を記録します。CLIなら/psで背景端末を確認し、画面上の処理が続いているのか、端末だけが動いているのかを分けます。WindowsではPowerShellの別ウィンドウやターミナルタブも対象に含め、同じコマンドが別の場所で動いていないかを確認してください。

Step 2: 増え続ける処理を止める

背景端末の反復なら、一覧で対象を見分けてから/stopを実行します。進行中ターンを中断する場合は、使っている画面の停止ボタン、または公式資料が示すCtrl+Cや/exitの動作を確認します。操作後に新しい出力が止まったか、ファイルのタイムスタンプと差分が変わらなくなったかを見てください。一度止まったように見えても、別の端末や別セッションが残っていれば、そちらも分けて確認します。

Step 3: 差分と確認結果を読む

停止できたら/diff、必要に応じて/statusを使い、変更されたファイル、未追跡ファイル、最後に通った検査を整理します。差分が完了条件を満たしているなら、ループを止めた状態で人が確認し、無理に再開しません。差分が途中なら、何が済み、何が未確認かを一行で書き出します。差分がない場合は、同じ依頼を再送する前に、対象範囲か完了条件のどちらかを変える必要があります。

Step 4: すぐ同じ状態へ戻さない

保存済みの会話を/resumeで開き直すことはできますが、ループの原因が同じ依頼や同じ状態にあるなら、再開だけでは同じ反復を再現する可能性があります。まず短い要約を作り、最後の差分、最後の確認結果、未完了の一点、止めた理由を並べます。その要約を使って新しい会話または分岐した会話を始め、対象を狭くして一回だけ確認します。公式資料の/resumeは履歴を引き継ぐ操作、/forkは現在の会話から別の会話を作る操作であり、どちらも原因を自動で修正する機能ではありません。

止めた後に残す記録──再開できる状態を作る

ループから復旧する作業では、「何が起きたか」を長い文章で再現するより、次の人や次のセッションが使える事実を短く残すほうが役に立ちます。日時は対象日の2026-09-13、入口はCodex CLI・デスクトップアプリ・IDEのどれか、版番号とモデル名は表示どおりに記録します。さらに、最後に意味のある差分が増えた時点、最後に確認できた検査、繰り返されたファイルや操作、停止した時刻を一つのメモへまとめます。

この記録には、推測した原因と確認できた事実を別の欄に置きます。「圧縮が原因だと思う」「モデルが迷ったようだ」という仮説は残してよいものの、公式に確認された事実や手元の観測と同じ文章にしません。原因が確定していなくても、ループを止め、差分を保全し、次の範囲を一つに絞れたなら、再開に必要な状態は作れています。

再開条件を決める

再開してよいのは、対象ファイル、依頼の目的、完了条件、最初に行う確認が決まっているときです。「続きから進めて」とだけ送るのではなく、「前回はAまで完了、Bだけ未確認。Bのファイルを読み、差分が必要か判断し、不要なら理由を報告して終了」と書きます。さらに、同じファイルを二回続けて読み直して差分が増えない場合、同じ検査が同じ結果になる場合は、次の試行を止めて報告する条件を加えます。

依頼文を変える──ループしにくい完了条件

Codexにループを止めさせるには、「最後まで続ける」よりも、どの状態を完了とみなすかを具体的に書くことが効果的です。対象を一つの機能や一つの不具合に絞り、変更してよい場所と触れない場所を分け、確認方法を一つか二つに定めます。作業が必要ない場合にも、変更しない理由を報告して終了するようにすれば、何かを変え続ける方向への偏りを抑えられます。

依頼文に入れる要素は、目的、対象、完了条件、確認方法、中断条件の五つです。抽象的な「改善する」ではなく、「このファイルのこの関数で、空の入力を受けたときの結果を変える。関連する検査を通し、差分を要約する」と書きます。Codexが別の問題を見つけた場合も、対象外として記録だけを残し、依頼の範囲を勝手に広げないようにします。

変更範囲を一つに絞る

最初の依頼は、リポジトリ全体の調査と修正を同時に任せないことが重要です。入口となるファイル、関係する呼び出し元、確認する検査を先に指定し、まず読み取り結果を返させます。その後に変更を依頼し、差分を確認してから次のファイルへ進みます。読み取りだけで原因が分からない場合は、対象を増やす理由を説明させ、無関係なディレクトリを巡回し続けないようにします。

反復上限と中断条件を書く

依頼文には「同じ操作を何度でも続ける」という含みを持たせず、試行の境界を置きます。たとえば「同じ検査が二回続けて同じ結果なら、再実行せず、出力と考えられる原因をまとめて終了する」「意味のある差分が増えない状態が二回続いたら停止する」といった書き方です。回数は作業の性質に合わせますが、上限を決めること自体が大切です。利用者が戻って判断できる地点を明示すれば、長い処理でも止めどきを失いにくくなります。

変更と検証を分ける

一つのターンで調査、複数ファイルの変更、検査、別機能の整理まで詰め込むと、どこから同じ反復が始まったのか分からなくなります。調査の結論を短く保存し、変更を一つ入れ、検査結果を確認し、次の依頼へ進む順番にします。検査が失敗した場合も、すぐに全体をやり直さず、失敗箇所と今回の差分の関係を確かめます。結果が変わらないなら、同じ手順を繰り返すのではなく、入力、対象、または確認方法を一つだけ変えます。

対象: src/example.ts の validateInput
目的: 空の入力を受けたときのエラー内容を明確にする
完了条件: 関連する検査が通り、変更ファイルが対象の1ファイルに収まる
中断条件: 同じ検査が2回続けて同じ結果なら再実行せず、原因と次の確認事項を報告して終了する

コンテキスト圧縮後に同じ計画へ戻るとき

長い会話では、文脈を空けるために以前のやり取りが要約へ置き換わることがあります。Codex CLI公式資料は、/compactについて、過去のターンを簡潔な要約へ置き換えて重要な詳細を保ちながら文脈を解放する操作として説明しています。圧縮後に少し前の内容を確認することは正常ですが、完了済みの調査を何度もやり直し、同じ計画を言い換えるだけなら、会話の要約に「完了済みの事実」と「次の一手」が十分残っていない可能性があります。出典: Codex CLI公式コマンド資料

圧縮が起きたことだけを見て原因と決めるのは早計です。対象のファイルが大きい、最初の依頼が広い、確認結果を返さずに説明を積み上げている、といった条件も同じ症状を作ります。圧縮前に「何が完了したか」「次に一つだけ何をするか」「失敗したらどこで止めるか」を短く確認し、必要なら手動で区切ります。圧縮後にそれらが保たれているかを読み、保たれていなければ新しい会話用の要約を作ります。

圧縮を原因と決めつけない

同じ計画へ戻ったときは、圧縮の前後で差分と確認結果が変わったかを比べます。差分が残り、次の検査も明確なら、要約を補足して続けられます。差分がなく、同じファイルの読み取りだけが増えたなら、依頼を止めて対象を狭くします。会話の長さ、モデル、版番号、入力ファイルの大きさを記録しておけば、圧縮が起きたこととループが始まったことの前後関係を後から確かめられます。

/resumeと新しいセッションの使い分け

前回の履歴を読み直したいだけなら/resumeが向いています。最後の差分と確認結果が残っており、次の一手も一文で言えるなら、同じ会話を続ける価値があります。一方、同じ計画へ何度も戻る、何が完了したか判定できない、対象範囲が広すぎるという場合は、新しい会話または/forkで境界を作ります。新しい会話へ移るときも、履歴を全部貼り付けるのではなく、目的、完了済み、未完了、差分、検査結果、中断条件だけを渡します。

サブエージェントを使う作業で見る点

複数のサブエージェントを使う作業では、親の会話が進んでいなくても子の一つが動いている、または子の結果を待つ処理だけが繰り返されるという見え方が起こり得ます。OpenAIのAgents API発表は、複雑な作業を独立した部分へ分け、サブエージェントが自分の文脈を持って進める仕組みを紹介しています。便利な反面、親の完了条件、子へ渡した範囲、子から戻った結果を別々に確認しなければ、全体が進んでいると誤認しやすくなります。

サブエージェントに関する公式リポジトリの報告では、同じ検査を繰り返す、状態確認の呼び出しが進捗につながらない、といった症状が個別に議論されています。これらは再現条件の参考になりますが、一般仕様の説明ではありません。親タスクが新しい結果を受け取ったか、子タスクが同じ操作を繰り返していないか、対象ファイルが予定の範囲を超えていないかを、親と子で分けて見ます。出典: Codex公式リポジトリのサブエージェント状態に関する報告

親と子の進捗を別々に見る

親の画面に「確認中」「続ける」と表示されていても、子が有効な結果を返したとは限りません。子ごとに担当範囲、最後に読んだファイル、差分、検査結果、状態を記録し、親がそれを取り込んだ時点を確認します。同じ結果が何度も戻る場合は、親へ再送する前に子の作業を止め、結果を一度の要約へまとめます。親と子の両方へ同じ広い依頼を渡さないことも、反復を減らす境界になります。

並列数より終了条件を先に決める

サブエージェントの数を増やすより、各担当の終了条件を小さく定めるほうが重要です。「認証部分を調べる」ではなく、「対象ファイルと呼び出し元を特定し、根拠行と未確認点を返す」と書けば、調査が無限に広がりにくくなります。親は結果を受け取ったら、採用するもの、保留するもの、対象外のものを決め、不要な子を待ち続けません。子の数や処理時間だけを進捗の指標にしないことが大切です。

Windowsでの確認──PowerShellと画面表示を切り分ける

Windowsでは、Codexの処理、PowerShellのコマンド、ターミナルの表示が同じ画面に並ぶため、どの層が繰り返しているのかを見失いやすくなります。画面に同じ文章が出ているだけなら、ファイルの最終更新時刻と差分を先に確認します。ファイルが変わっていなければ、表示の循環か、作業ターンの反復かをさらに分けます。PowerShellの別タブやバックグラウンド端末に同じ処理が残っていないかも、/psと画面一覧で照合してください。

Windowsの端末で中断キーを押すと、入力欄を消す動作と実行中ターンを止める動作が版や入力状態によって区別されることがあります。Codex CLI公式資料のショートカット説明と、現在の画面に表示される案内を確認し、停止したつもりで入力だけを消していないかを見ます。中断後は、画面の赤い通知だけで復旧を判断せず、差分、端末の終了状態、最後の出力を順に確認します。

端末が繰り返す場合

同じPowerShellコマンドが何度も走り、Codexの会話は増えていない場合、まず背景端末を疑います。/psの一覧でコマンドと最新出力を確認し、対象が分かったら/stopでその端末を止めます。手動で開いたPowerShellや別のターミナルから起動した処理は一覧に出ない場合があるため、タブ、タスク一覧、対象ファイルの更新時刻も合わせて見ます。止めた後に同じ処理を再開する前に、入力と終了条件を一つずつ見直します。

画面だけが動く場合

画面が先頭と末尾を行き来する、空白が表示される、最新メッセージへ移れないという場合は、コードの変更ループと別の表示問題かもしれません。OpenAI Codex公式リポジトリには、長い会話で表示位置が循環する報告があります。まず別の会話や差分表示が正常か、ファイルが変わっていないかを確認し、作業ターンを止める必要があるかを分けます。再表示や再起動を試す場合も、先にセッション名と差分を記録しておきます。出典: Codex公式リポジトリの表示問題の報告

公式情報を読むときの注意──報告と仕様を分ける

ループの情報を探すと、公式リポジトリのIssue、リリースページ、開発者向けコマンド資料が見つかります。それぞれ役割が違います。Issueは特定の環境で起きた症状、再現条件、利用者が試した対処を知る資料です。リリースページは版番号、公開日、掲載された変更を確認する資料です。開発者向け資料は、現行コマンドの目的や使い方を確認する資料です。三つを同じ強さの根拠として扱わず、症状、仕様、公開事実を対応させます。

たとえば「無限に繰り返した」というIssueがあっても、全員に起きる、特定のモデルが原因、最新版で解決済みという結論までは、そのIssueだけから導けません。逆に、リリースページに新しい版があるから、目の前のループが更新で直るとも限りません。版番号を記録し、公式の説明に書かれた範囲と、自分の環境で確認した範囲を分けることが、誤った復旧判断を防ぎます。

Issueは再現条件の資料として使う

Issueを読むときは、見出しの印象より、発生した入口、OS、アプリやCLIの版、モデル、再現手順、期待された動作を拾います。たとえば同じ「ループ」でも、コンテキスト整理後に同じファイルを読む問題、画面のスクロールが循環する問題、状態確認の呼び出しが進まない問題では、最初の操作が異なります。自分の症状と共通する項目だけを取り出し、書かれていない根本原因や解決済みの状態を推測しません。出典: Codex公式リポジトリのコンテキスト整理に関する報告

リリース情報は版番号と公開内容だけ読む

2026年9月13日に確認する版は、手元の表示と公式リリース一覧を照合します。9月11日にはOpenAI Codexの0.155.0 alpha系列が複数公開されていますが、先行版の公開だけでループ対策が含まれるとは断定できません。リリース本文に書かれた変更だけを採用し、書かれていない性能や安定性は手元で検証する項目へ分けます。出典: openai/codex公式リリース一覧

再開前チェック──同じループを戻さないために

再開前に確認することは多くありませんが、順番を崩すと同じ状態へ戻りやすくなります。次の順序で、事実を一つずつ確かめます。

1. 入口、版番号、モデル、対象フォルダー、セッション名を記録する。
2. /psで背景端末を確認し、不要な反復があれば/stopで止める。
3. /diffで変更ファイルと未追跡ファイルを確認し、差分を保存する。
4. 最後に通った検査、失敗した検査、まだ未確認の一点を分けて書く。
5. 目的、対象、完了条件、中断条件を一つの依頼文へ組み直す。
6. /resumeで続けるか、新しい会話や/forkへ移るかを決める。
7. 最初は一つのファイルまたは一つの検査だけを対象にして結果を確認する。

この順序で大切なのは、再開を最後に置くことです。先に履歴を開くと、会話の勢いに押されて同じ依頼をそのまま送ってしまいます。先に差分と確認結果を読み、未完了の一点だけを選べば、Codexが過去の説明を繰り返す余地を減らせます。結果が変わらない場合は、その場で止めて記録を更新し、別のモデルや版へ急いで切り替える前に、入力と対象範囲を見直します。

まとめ──ループ対策は「止める・見る・狭める」

Codexループを見つけたら、まず処理の増加を止め、次に差分と確認結果を読み、最後に対象と完了条件を狭めて再開します。/stopは背景端末、/diffは変更、/compactは文脈整理、/resumeは保存済み会話の再開というように、公式コマンドの役割を分けて使うことが重要です。画面表示の循環、背景端末の反復、コンテキスト整理後の再読込、親子タスクの待ち続けは、同じループという言葉でも確認先が違います。

2026年9月10日のAgents API発表が示すように、Codex系の作業は長く、複数の道具やサブエージェントを扱う方向へ広がっています。長く任せられることと、無制限に待ち続けることは同じではありません。目的、対象、完了条件、中断条件、最後の差分を先に置き、人が確認できる地点を作ることで、長時間タスクの便利さを保ちながら、意味のない反復を早く切り分けられます。