要約
- GitHubは8月1日11時16分25.356秒（UTC）にkk183dslzdzdを開始し、12時30分21.775秒に解決した。
- 公開インシデントの継続時間は1時間13分56.419秒だった。
- Copilot製品とIDE画面でGPT-5.6 Lunaの可用性が低下し、原因は上流モデル事業者の問題だとされた。
- 利用者には別のモデルを選ぶかAutoを利用するよう案内された。
- 12時29分20.237秒の本文はLuna復旧と緩和完了を伝えたが、状態ラベルはinvestigatingのままだった。
- 事業者名、原因、総要求数、エラー率、地域、利用者数、切替成功率はなく、GitHubは後日の根本原因分析を約束した。
製品の稼働とモデルの稼働は同じではない
Copilotの入口が応答していても、選択した推論モデルだけが不安定になることがある。可用性の境界はGitHubの画面にとどまらず、モデル選択層、外部事業者への経路、推論サービスまで連なる。
GitHubは上流依存を明示したが、企業名も障害層も示していない。認証、容量、ネットワーク、要求処理、モデル提供などは候補にすぎず、公開情報から一つを選ぶことはできない。
別モデルは継続手段だが同一サービスではない
他モデルやAutoへの切替案は、単一経路で完全停止する構造ではなかったことを示す。急ぎの開発作業には有用だった可能性が高い。しかしモデルが変われば、文脈理解、コード生成の傾向、遅延、出力の一貫性、規則が変わり得る。
Autoが何を選んだのか、進行中の会話が移行したのか、何割が切替に成功したのかは不明だ。したがって確認できるのは迂回案の存在であり、機能同等性ではない。
公開時系列は復調を段階的に示す
11時16分25.435秒に調査が始まり、11時20分02.543秒にLunaが特定された。12時13分24.248秒には回復が観測され、12時29分20.237秒に再利用可能とされた。正式解決は12時30分21.775秒である。
最後のおよそ1分は、復旧宣言と記録の終了を分ける。ただし、上流側の修正時刻や全経路の安定時刻までは分からない。状態ページは外部向けの節目を示すが、内部作業の完全な履歴ではない。
状態ラベルより本文が先に進んだ
緩和完了を述べた更新はinvestigatingのラベルを保っていた。運用フロー上の遅れかもしれず、復旧していなかった証拠ではない。一方、コードだけを読む監視は、人が文章を読む場合と違う判断をする可能性があった。
状態、本文、時刻を別々に保存する設計が必要だ。矛盾を自動で消すと、復旧情報がどの順序で公開されたかという証拠まで失われる。
minorから利用者割合は分からない
影響区分はminorだが、総要求数、失敗数、組織、地域、IDE種別がない。プラットフォーム全体の比率にも、企業の生産性損失にも換算できない。
Lunaを固定した工程は強く影響を受け、Autoを既定にした利用者は軽微だったかもしれない。どちらも資料と矛盾しない。全体分類と個別依存度を分けて評価する必要がある。
モデル名を運用記録に含める
AI支援をビルドやレビューに組み込む組織は、要求したモデル、実際に使われたモデルが分かる場合はその名称、時刻、エラー、再試行、遅延、出力の採用先を残すとよい。失敗と代替を区別し、挙動差を後から検証できる。
本件で危険な出力やリポジトリ改変が起きたという意味ではない。GitHubが報告したのは可用性であり、機密性や完全性の事故ではない。
約束された分析が答えるべき点
根本原因分析には、障害境界、失敗・遅延要求の規模、検知、Auto経路の変化、事業者の健全性を今後の選択に反映する方法が必要だ。状態ラベルの遅れも説明対象になる。
現時点では、上流問題でLunaが1時間13分56.419秒の公開障害となり、別モデルが回避策だったとだけ言える。事業者、原因、実測範囲、切替の機能的負担は不明である。
