AIに長い作業を任せている最中、画面の接続が切れた。再接続後に同じ指示を送り直すべきか、それとも裏で処理が続いているのか。ここを間違えると、ファイル更新や外部送信が二重になる。
OpenAIは2026年9月3日、Codex 0.153.0を公開した。今回の更新で私が注目したのは、派手な生成機能ではない。外部のapp-serverとの接続が落ちたとき、TUIが自動で再接続し、入力途中の文章や会話履歴を残しながら、送信結果が曖昧な指示を勝手に再送しない設計だ。
これは開発者向け画面の修正に見える。ただ、会社でAIに仕事を委譲するなら、再接続より「二重実行を避けるために何を止めるか」の方が大事になる。
Codex 0.153.0で何が変わったか
公式リリースには、外部app-serverとの接続が切れたあとにTUIセッションを再接続する修正が記載されている。再接続時には下書きと会話記録を維持し、送信済みか判断できない入力や待機中の入力は、人が確認できる状態で止める。
実装を追うと、役割がもう少しはっきりする。
- Pull Request #41911は、切断時に会話の下書き、待機中の入力、貼り付けた文章、添付、エージェント画面で入力中の内容を保持する。古い接続から遅れて届いた完了通知は無視し、自動再送もしない。
- Pull Request #41916は、新しいクライアントを立ち上げて作業中のスレッドへ戻る。会話記録、下書き、実行時の設定、通知経路を引き継ぐ一方、送信された可能性がある入力は確認待ちに置く。再開できない会話も、キャッシュされた読み取り専用画面として残る。
- Pull Request #41918は、複数エージェントを扱う画面でも選択中の作業と入力を保つ。接続後に一覧を更新しても、待機中の入力は勝手に流さない。
公式リリースには、Vim入力のundo/redo、遠隔マーケットプレイスからのプラグイン操作、TUI履歴への完全なパッチ表示なども含まれる。本稿では、会社の運用事故に直結する再接続と再送制御に絞る。
切断と失敗は同じではない
ブラウザやターミナルから応答が消えると、人は失敗と判断しやすい。しかし実際には、表示側だけが切れ、サーバーでは処理が終わっている場合がある。そこで同じ指示を再送すると、結果が二重になる。
たとえばAIに「顧客20社へ案内を送る」「請求候補を会計台帳へ登録する」「商品在庫を更新する」と任せたとする。接続断のあと同じ依頼を投げ直し、最初の処理も生きていれば、メールは二重送信、台帳は重複登録、在庫は二度減算になり得る。文章生成なら作り直せば済むが、外部へ作用する仕事は戻せないことがある。
Codex 0.153.0の考え方は単純だ。画面は戻す。下書きも残す。ただし、実行されたか分からない入力は隔離し、人が確認するまで再送しない。私はこの分離を、社内AIの標準動作にした方がいいと考えている。
社内AIは3つの状態を持つべきだ
AIの進捗を「成功」「失敗」だけで管理すると、切断時に判断を誤る。最低でも、次の3状態が必要になる。
- 未送信。入力は端末側に残っているが、処理受付の記録がない。
- 受付不明。送った可能性はあるものの、受付IDや開始記録を確認できない。
- 受付済み。処理IDがあり、実行状況または結果を照会できる。
再接続後に自動で流してよいのは、原則として未送信だけだ。受付不明は止め、送信履歴、処理ID、外部システム側の更新履歴を確認する。受付済みは同じ仕事を新規作成せず、既存の処理を追跡する。
ここで効くのが、仕事ごとの一意な受付IDだ。「9月7日の在庫更新」のような曖昧な名前ではなく、案件、対象、実行単位を特定できるIDを付ける。同じIDが来たら二度目を拒否する仕組みにしておけば、画面側の再送判断が多少ずれても事故を抑えられる。
導入前に決める4項目
最初から大きな監視基盤を作る必要はない。AIに外部操作を任せる業務について、まず次の4項目を台帳に持たせる。
- 受付ID：同じ依頼を識別し、重複実行を止める番号
- 現在状態：未送信、受付不明、受付済み、実行中、完了、要確認
- 結果の正本：送信履歴、更新後のレコード、生成ファイルなど、完了を判定する保存先
- 再開条件：誰が何を確認したら、再送または継続してよいか
特に「完了しました」というAIの返答だけを正本にしない方がいい。メールなら送信済みフォルダ、台帳更新なら対象レコード、ファイル生成なら保存先を読み返す。返答は報告であって、処理結果そのものではない。
外部送信、削除、支払い、公開を伴う仕事では、受付不明の自動再送を禁止する。社内メモの要約や一時ファイルの生成なら、同じ入力をやり直しても影響は小さい。業務の危険度に応じて、再送ルールを変えるのが現実的だ。
運用で起きる失敗
一つ目は、再接続できたことを作業完了と取り違えるケースだ。画面や会話が復元されても、外部システムの処理が成功した証拠にはならない。必ず結果の保存先を確認する。
二つ目は、切断前の指示を全部再生する設計。読み取りだけなら大きな問題になりにくいが、書き込みが混ざると危険だ。再接続では会話を戻し、実行は戻さない。実行済みか不明なものを一件ずつ照合する。
三つ目は、担当者が変わると判断できない状態だ。「さっきの続き」で通じるのは、その場にいた人だけ。受付ID、対象、最終確認時刻、次に確認する場所を残しておけば、別の担当者や別のAIでも引き継げる。
なお、Codexの修正はTUIとapp-server間の再接続を扱うものだ。業務システム側の重複防止、メールの取り消し、会計データの整合性まで自動で保証する機能ではない。会社側で受付IDと結果照合を設計しなければ、二重実行のリスクは残る。
最初の一手
AIが外部へ書き込む仕事を一つ選び、接続が切れた直後の手順を紙一枚にする。「同じ指示を再送する前に、どこを見れば実行済みか分かるか」を決めるだけでいい。
確認先が存在しないなら、AI化より先に受付記録を作る。AIへ仕事を渡す手綱は、細かな禁止ルールではない。切断しても、誰が見ても同じ状態が分かり、二重に動かさず再開できることだ。今回のCodex更新は、その地味な条件を製品側でも扱い始めた。
小さく試すなら更新業務から
実証対象には、やり直し可能で履歴が残る社内台帳の更新が向いている。AIに5件だけ処理させ、途中で意図的に画面を閉じる。再接続後、下書きが残るか、受付済みの件数を確認できるか、同じ受付IDを再送したとき拒否されるかを確かめる。
合格条件は「つながり直した」では足りない。5件が重複なく一度ずつ更新され、未処理と処理済みを第三者が判別できること。受付不明の1件があれば、勝手に続けず確認待ちへ移ること。この二つを満たしてから対象件数を増やす。
逆に、最初の実証に顧客メールや請求処理を選ぶのは避けたい。失敗時の影響が大きく、再接続の検証より後始末が重くなる。社内台帳で状態管理を固め、そのあと承認付きの外部操作へ広げる。この順番なら、製品の便利さではなく、会社の仕事が壊れずに戻るかを評価できる。