要約
- OpenAI は00:55:27 UTC、
invalid_promptコードのエラー率上昇について調査を開始した。 - 01:39:33に緩和策を適用して監視へ移り、02:20:19に全面復旧を公表した。公開された経過は1時間24分52秒である。
- 障害記録は HTTP 状態を示していない。別に、公式 Python SDK は実際の HTTP 400を
BadRequestErrorに対応させ、一般的な400を通常の自動再試行に含めない。 - 運用手順が
invalid_promptを直ちに恒久失敗とすると、有効だった処理を回収できない。逆に一律再送すれば、重複や負荷を招く。 - 根本原因、障害率、地域、対象モデルやエンドポイント、リクエスト数、顧客数は公表されていない。同時間帯の同名エラーをすべて供給側に帰属させることもできない。
障害対応手順は、平常時の分類が外れたときに価値を示す。invalid_promptは平常なら、入力形式やパラメーターを見直すための信号である。しかし今回は OpenAI 自身が、そのコードの増加を API 障害として扱った。担当者が最初の文字列だけを信じれば、供給側の回復を待つべき処理を、利用者の誤りとして閉じてしまう。
必要なのは例外を無制限に増やすことではない。通常ルールを保ったまま、複数の証拠が矛盾したときだけ入る「判定保留」を設けることである。
検知段階ではエラー名と発生率を分ける
一件のinvalid_promptは、まず入力エラーとして扱うのが妥当だ。ところが、変更していない既知のリクエスト形式で同じ応答が急増したなら、名称とは別に異常率を警告すべきである。
運用ダッシュボードは、HTTP 状態、エラーコード、モデル、エンドポイント、SDK の版、地域やアカウント単位の発生数を時系列で持つ。平常時の割合と比較すれば、「一人の設定ミス」と「多数の安定した処理が同時に崩れた状態」を区別しやすい。
この段階では原因を断定しない。アプリケーションの新しい配備や資格情報の問題でも、同じような増加は起こる。検知の役割は、恒久失敗として捨てる前に調査経路を開くことだ。
判定段階では公式時刻を機械的に取り込む
OpenAI の構造化ステータス記録には、調査開始、緩和・監視、解決の時刻がある。人がブラウザーで読むだけでなく、別の収集系が適度な間隔で取得し、期限付きの内部シグナルに変換できる。
00:55:27から02:20:19までという窓は、再点検すべき処理を絞る材料になる。OpenAI は影響コンポーネントを APIs としたため、同じ時間の無関係な製品エラーまで一括で扱う理由はない。
ただし、時刻が重なっただけで因果関係は確定しない。本当に不正な入力も事故中に送信される。公式シグナルはローカル診断を上書きする命令ではなく、確信度を下げて保留へ移す根拠である。
保全段階では再送より先に識別子を残す
公式 Python SDK は、失敗したAPIStatusErrorからリクエスト ID を参照できると説明している。これに業務ジョブ ID、UTC 時刻、試行回数、応答状態、エラーコードを結び付ければ、一件の処理を供給側へ照会できる。
入力の同一性を確かめるためには、機密性を落とした指紋も使える。エンドポイント、モデル、パラメーター名の集合、社内スキーマ版などを正規化してハッシュ化すれば、内容を公開せずに「以前成功した形が急に失敗した」と示せる。
生のプロンプト、個人情報、API キーを障害ログへ複製してはならない。復旧可能性を高めるためのログが、情報漏えいの面積を広げれば本末転倒である。
再実行段階では SDK の標準動作を理解する
SDK は400をBadRequestErrorにする。標準の自動再試行は接続エラー、408、409、429、500以上に向けられ、明示的なx-should-retry指示も先に評価される。普通の400は自動では繰り返されない。ただし、これは400を実際に受けた場合の規則であり、今回の障害応答が400だった証拠ではない。
この設計は間違いではない。不正なパラメーターを何度送っても修正にはならず、無駄な呼び出しが増えるだけだ。運用側が行う限定再実行は、標準設定を一律変更することとは違う。
候補は、公式障害窓に入り、既知の形式であり、最初の処理結果が残っていないものに限る。少数の合成テストで回復を確認し、速度と総数に上限を設ける。副作用を伴う後続処理では、初回が実行済みでないか確認してから再開する。
照合段階で初めて復旧が完了する
OpenAI が02:20:19に「影響を受けたサービスは全面復旧」としたことは、供給側の公開状態を閉じる。顧客側で破棄されたジョブ、利用者に返したエラー、切り替えた代替経路までは元に戻さない。
復旧後の台帳には、少なくとも四つの結果が要る。実際に入力不正だったもの、障害候補として未処理のもの、再実行して結果を確認したもの、初回処理済みの可能性があり下流確認を要するものだ。
同じ操作を二度行っても安全かどうかは、API 応答だけでなく業務上の効果で決まる。生成コストが二重になる場合もあれば、公開、通知、記録更新などが重複する場合もある。再実行の成功件数だけでは、照合は終わらない。
手順が断定してはいけないこと
OpenAI は根本原因も HTTP 状態も示していない。なぜinvalid_promptとして現れたのか、どのモデルやエンドポイントが対象だったのか、失敗率と顧客数がどれほどだったのかも不明である。ステータス上の「minor」は、個々の利用者の影響を数量化しない。
したがって、運用記録には未知をそのまま残す必要がある。「事故中の400はすべて供給側」「解決後は全ジョブが回復」「再送すれば必ず安全」という文は書けない。
一方、今回の事実だけで改訂できる手順はある。エラー急増を検知し、公式状態で判定を補い、リクエスト ID を保全し、対象を限定して再実行し、最後に業務状態を照合する。この五段階を持てば、次にエラー名が責任の所在を誤って示しても、処理を捨てず、無差別にも送り直さずに済む。