API と ChatGPT と Codex を使い分けても障害経路は分離されない

要約

一つの組織が OpenAI を複数の方法で利用することは珍しくない。アプリケーションは API を呼び、社員は ChatGPT を使い、開発者は Codex で作業する。

これらは用途と操作方法が異なる。しかし、今回の状態記録では三つの製品群が同じインシデントに含まれた。利用画面を分けるだけでは、供給者側の障害経路が独立するとは言えない。

これは全コンポーネントが同じ物理設備で動くという証拠ではない。状態ページには構成図がなく、各機能の影響度も示していない。確認できるのは、顧客が複数の OpenAI 経路で相関したエラーに遭遇し得たことだ。

12、2、4というコンポーネント数は報告範囲である。18件の独立故障でも、18種類の顧客でもない。

OpenAI はエラー率上昇と述べたが、全リクエスト数、失敗数、利用者数、地域を公表していない。したがって、利用不能率や金銭的損失を計算できない。

製品横断の範囲は顧客の設計判断に影響する。可用性を高めるなら、画面だけでなく、供給者、インフラ、認証、データ経路などの独立性を検討する必要がある。ただし、どの代替策が今回有効だったかは状態ページから分からない。

OpenAI は16:48:54に、下流インフラ事業者と緩和策を実装していると発表した。これにより、技術的な制御の一部が別組織にあることが分かる。

事業者名は公表されていない。クラウド、ネットワーク、データセンターなど特定分野に原因を割り当てることもできない。相手が故障を起こしたのか、修復に必要だっただけなのかも不明だ。

利用者が契約し、状態情報を受け取る窓口は OpenAI である。一方、OpenAI は供給連鎖の協力を必要とした。依存の開示は責任の境界を説明するが、責任を自動的に消すものではない。

本稿の時点は17:23:49.505 UTC で固定する。その時、状態は identified で未解決だった。後の更新があっても、当時の運用判断に後から結末を持ち込んではならない。

顧客は待機、再試行、別工程への切り替えを選ぶ必要があった。コストは存在するが、影響量がないため金額にはできない。

次に必要なのは、最終解決時刻、原因、三製品群への伝播、下流との制御分担、再発防止策である。それまでは、複数製品の利用を複数インフラの保険と扱わないことが、最も確かな運用上の教訓となる。