要約

  • GitHub は8月1日18時03分05.539秒（UTC）に sj1tzyrx599x を開始し、18時44分28.733秒に解決した。
  • 公開期間は41分23.194秒だった。
  • 最初は特定の上流 AI モデル事業者でエラー率が上がったとだけ報告し、モデルも企業も示さなかった。
  • 18時20分20.807秒に Fable 5の可用性低下を明らかにし、別モデルまたは Auto を勧めた。
  • 18時20分48.941秒、28.134秒後に緩和へ移り、18時23分40.021秒に Fable の復旧を伝えた。
  • 事業者、原因、要求母数、エラー率、利用者数、地域はなく、詳細分析が予告された。

最初の告知では避けるモデルが分からなかった

18時03分15.483秒の「特定の上流事業者」という表現は、全機能障害ではないと示す一方、利用者が選択を変えるには足りなかった。Fable が現れるまで17分5.324秒あった。

この時間が切り分け、事業者確認、公開判断のどれだったかは不明だ。記録が示すのは、情報が分類から具体的経路へ進んだ順序だけである。

利用者側では、この違いが一般警告から実行可能な経路変更へ移る時点を決める。

名前の直後に緩和状態へ移った

モデル名の更新から28.134秒で、GitHub は退化が緩和されたとした。さらに2分51.080秒後に Fable を利用可能と明記した。

修正作業は名称公開前から進んでいた可能性がある。28秒で技術修理したと読むべきではない。時刻は公開の節目である。

回避策は対象が分かって初めて具体化する

一般的な上流警告だけでは、どのモデルから切り替えるべきか判断しにくい。Fable 特定後、他モデルや Auto が実行可能な回避策になった。

Auto の行き先、切替成功率、遅延、挙動比較はない。選択肢の存在は分かるが、同等性は分からない。

同じ日でも同じ原因とは限らない

同日早くには GPT-5.6 Luna の別件があった。上流事業者という共通語と時間の近さだけで、同一企業、設備、原因を結びつけることはできない。

二件は依存パターンを示すが、一つの障害である証拠はない。

復旧確認後も約21分監視した

Fable が戻った18時23分40.021秒から解決18時44分28.733秒まで20分48.712秒ある。

監視指標と閾値は非公表だ。慎重な状態遷移は分かるが、残存エラー率は分からない。

モデル選択とフォールバックを記録する

要求モデル、エラー、再試行、Auto の選択、遅延、下流利用を残せば、失敗と代替を区別できる。許可モデルの変更も運用判断として監査可能にすべきだ。

プロンプト流出、コード漏えい、出力破損の証拠はない。報告対象は可用性である。

原因分析は認識過程も説明すべきだ

Fable 関与を知った時点、事業者状態との対応、緩和条件、Auto の動作、影響数が必要だ。Luna との関係も明示すべきである。

現時点では、Fable 5が41:23.194の公開障害で退化し、説明が一般的エラーから具体モデルへ進んだと分かる。事業者、原因、規模、先行事件との関係は不明だ。

出典