要約

  • GitHubは8月3日09時53分27.172秒（UTC）に7s119p1yxttrを開始し、11時25分12.371秒に解決した。公開記録の長さは1時間31分45.199秒だった。
  • Copilotのチャット用モデルとエージェント用モデルで可用性が低下し、複数モデルが影響を受け、顧客要求が失敗する可能性があると説明した。
  • 10時35分19.914秒にも断続的なエラーが続き、11時19分04.001秒に緩和、そこから6分08.370秒の監視を経て解決した。
  • 影響区分はminorだが、総要求数、失敗率、利用者・組織数、地域、モデル名、顧客ごとの影響時間は公表されていない。
  • GitHubは詳細な根本原因分析を予告したものの、固定した締め切り時点では原因、緩和方法、再試行規則、受理済みエージェント処理の扱いが不明だった。

「Copilot」という一項目の内側に複数の経路

ステータス画面が示す影響コンポーネントはCopilotの一つだけである。しかし09時54分22.985秒の更新は、実際の障害面が単純ではないことを示した。チャットとエージェントのモデルで可用性が落ち、複数モデルが対象となり、要求が失敗し得るという内容だった。

これはCopilot全体の完全停止を意味しない。全要求が失敗したとは書かれておらず、割合もない。一方、一つの特定モデルだけの問題とも読めない。対象モデルが伏せられている以上、利用者が別モデルを選べば必ず回避できた、という根拠もない。

チャットとエージェントでは、失敗後に確かめるべき対象が異なる。チャットなら返答の有無を人が見やすい。エージェントはリポジトリの確認、ツール呼び出し、変更案の作成、テストなどを連続して進める場合がある。本件で実際に重複変更や不完全な書き込みが起きた証拠はない。ただし、長い処理では「応答がなかった」と「何も実行されなかった」は同義ではない。

断続的な失敗は状態確認を必要にする

開始から約42分後の10時35分19.914秒、GitHubはなお断続的なエラーを観測し、緩和策を検討しているとした。同じ時間帯でも成功と失敗が混在し得るため、一度の成功で先行処理すべての完了を証明することはできない。反対に、一度のエラーから全トラフィック停止を結論づけることもできない。

エージェント処理では、要求が受理されたか、実行中か、実行前に失敗したか、途中で止まったか、再試行が二重の処理を作るかを分けて考える必要がある。公開記録はCopilot内部のキューや冪等性を説明していないため、本件について具体的な動作を断定できない。

企業側でできるのは、利用可能な要求IDと時刻を残し、再試行前にリポジトリや外部システムの実状態を確かめ、通信エラー、実行エラー、結果確認を別の段階として扱うことだ。これは8月3日にデータ破損があったという主張ではなく、不明な状態を自動再試行で増幅させないための一般的な運用である。

緩和から解決まで6分余りを置いた

GitHubは11時19分04.001秒に劣化を緩和したと発表し、監視状態へ移した。この時点でCopilotコンポーネントはdegraded performanceからoperationalへ戻った。正式な解決は11時25分12.371秒で、差は6分08.370秒だった。

この間隔は安定性を確認する段階があったことを示すが、修正手段は示さない。トラフィック移動、容量追加、コードのロールバック、依存先の隔離、要求方針の変更のいずれも公表されていない。どれかを事実として補うことはできない。

1時間31分45.199秒という長さも、すべての顧客が同じ時間だけ使えなかったという数値ではない。個々の影響は短かったかもしれず、断続的だったかもしれず、全くなかった可能性もある。逆に、劣化中に受理された作業はコンポーネント復旧後も確認を要し得る。公開時計はGitHubのインシデント管理を測るもので、顧客ごとの復旧時刻ではない。

minorは利用者影響の割合ではない

GitHubは影響をminorに分類した。このラベルはプロバイダー側の事象を整理するには役立つが、利用者の何％が影響を受けたかを表さない。総要求数、失敗数、遅延分布、利用者数、組織数、地域、モデル別の内訳はない。

そのため、エージェントを実行していなかったチームが何も気づかなかった場合と、レビューや支援業務の一要求に依存したチームが実質的に止まった場合の両方が、この記録と両立する。どちらが多数だったかは判断できない。

同じ理由で、過去のGitHubのモデル障害と一つの原因にまとめることもできない。今回は上流プロバイダーが挙げられておらず、共通原因の説明もない。同じ製品で時期が近いことは因果関係の証拠にならない。

公開された迂回策はなかった

五つの更新には、別モデルへの切り替え、Autoの利用、エージェント停止、特定間隔での再試行といった利用者向け手順がない。対象が未公表の複数モデルである以上、モデル変更が共有障害面を外れるという保証もなかった。

迂回策の記載がないことは、内部に代替経路が存在しなかった証明ではない。顧客が使える手順として検証・公表されなかった、という意味に限られる。企業は平時に、自動再試行できる作業、モデルが変われば人の承認を要する作業、外部状態を確認するまで止める書き込みを分けておく必要がある。

AIが回答を補助するだけでなく処理を実行する段階では、継続性は「別の返答が得られるか」だけでは足りない。どの処理が受理され、完了し、検証されたかをたどれることが必要になる。

可用性の回復は説明の完了ではない

解決時にGitHubは詳細な根本原因分析を共有すると表明した。締め切りまでに取得した一次情報には、原因も緩和方法も掲載されていない。検知までの時間、失敗と遅延の割合、再試行成功率、キューの処理、チャットとエージェントの影響差も不明である。

意思決定に役立つ分析なら、複数モデルが共有した境界、エラーが断続的になった理由、検知の仕組み、復旧させた措置、受理済みエージェント処理に再実行や照合が必要だったかを示すべきだ。minorを解釈できる総量も欠かせない。

確認できる結論は限定的である。GitHubは複数のチャット・エージェント経路で断続的な要求失敗が起きた約92分の公開インシデント後にCopilotを復旧した。技術的な仕組みと実測された顧客影響はまだ示されていない。

出典