外部の開発会社に依頼している案件で、「今日は GitHub が落ちているので進みません」と連絡が来たら、どう受け止めるでしょうか。言い訳に聞こえるか、妥当な報告に聞こえるかは、何がどこまで止まるのかを知っているかどうかで変わります。
2026年8月17日、GitHub は7時間47分にわたって障害を起こしました。github.com 本体だけでなく、認証、Actions、API、プルリクエスト、Issues、そして Copilot まで影響を受けています。8月20日に公開された振り返りには、発注する側が読んでも意味のある内容が書かれていました。
原因はコードではなく、容量だった
障害は、トラフィックが過去最高に達したときに、Central US データセンターの重要なインフラ構成要素がそれに追随してスケールできなかったことから始まりました。GitHub は、この障害がコードや構成の変更によって直接引き起こされたものではなく、根本的にはストレージ容量の不足によるものだったと説明しています。
背景には利用量の急増があります。月間のコミット数は2026年4月の14億から、約4か月で29億へと倍増しました。AI エージェントによる開発が一般化した結果、人間の数が増えていないのにリポジトリへの書き込みだけが倍になったわけです。容量計画の前提が、従来の伸び方から外れたことになります。
ここは他人事ではありません。自社システムのキャパシティ計画も、「利用者数 × 平均操作回数」で見積もっているなら、同じ形で外れます。エージェントが操作する前提になると、1人あたりの操作回数の分布が変わります。
長引かせたのはリトライだった
読んでいていちばん実務的だったのは、復旧が遅れた理由のほうです。
障害中に発生した大量のリトライが内部のロードバランサの負荷を押し上げ、状況を悪化させました。特に Copilot の認証トークンを処理するサービスでは、通常であれば毎秒7,000〜9,000件のリクエストが、毎秒70,000〜100,000件まで膨れ上がっています。 認証に失敗すると大量に再試行してしまう挙動が、クライアント側（Visual Studio Code）にあった可能性が指摘されています。
結果として、Copilot の復旧は他のサービスより遅れました。GitHub は再発防止として、サービス間の呼び出しに一貫したリトライ回数の上限、リトライ予算、可変タイムアウトを適用するとしています。
この形は、規模を問わず起きます。 自社のスマホアプリや業務システムが、サーバーからエラーが返ってきたときに即座に再試行する作りになっていれば、障害の瞬間に負荷が数倍から十数倍になります。復旧しようとサーバーを立ち上げても、待機していたクライアントが一斉に殺到して再び落ちる。開発時には気づきにくく、本番の障害で初めて表面化する種類の問題です。
発注時の要件として書くなら、次の1行で足ります。「エラー時の再試行は回数の上限を設け、間隔を指数的に広げ、ばらつきを持たせること」。実装コストはほとんどかかりません。
発注側が備える意味があるのは3か所
「GitHub が止まるなら別のところにも置こう」という話にはなりません。二重化のコストが釣り合わないためです。備えるとすれば、次の3か所です。
1. 納期の扱いを先に決めておく。 外部サービスの障害で作業が止まった場合に、納期をどう扱うかを契約に書いてあるかどうか。書いていなければ、起きたときに感情の問題になります。1行あれば済みます。
2. リリース当日の段取り。 障害が起きて困るのは、日常の開発よりもリリース作業です。CI が動かなければデプロイできません。重要なリリースの日に、手動で切り戻せる経路があるかは確認しておく価値があります。SaaS 停止時の業務継続をどう設計するかはSaaS障害を前提にした業務継続の考え方に整理しました。
3. コードの所在。 発注者としていちばん重要なのはここです。障害そのものより、自社が発注して作らせたコードが、自社の管理下にあるかどうか。開発会社のアカウント配下にしかない状態は、障害よりも取引終了のときに問題になります。契約でどう押さえるかはコードの置き場所を契約に書いていますかで扱っています。
「止まらないもの」を増やすより、止まり方を選ぶ
今回のような障害のたびに「自前で持つべきだ」という議論が出ますが、自前で持てば7時間47分より短く復旧できるかというと、まず無理です。GitHub より手厚い運用体制を敷ける組織は多くありません。
現実的なのは、止まったときに何が止まるかを把握し、止まって困るものだけを別経路にしておくことです。開発の手が止まるのは許容できても、本番環境のデプロイができないのは困る、という優先順位が普通です。構成要素を足すときに「あとで外せるか」を見る観点は入れた構成要素を外せるかに書きました。同じ問いが、依存する外部サービスにも当てはまります。
次にやること
まず、自社のシステムで、エラー時にクライアントが何回・どの間隔で再試行しているかを確認してください。 設定していない場合、ライブラリの既定値がそのまま効いています。既定値が自社の負荷に対して適切である保証はありません。
そのうえで、外部サービスの障害時に納期と作業をどう扱うかを、次の契約更新で1行足しておいてください。 起きてから決めるより、はるかに安く済みます。
システム開発の依存関係の整理、障害を前提とした設計レビュー、再試行やタイムアウトの実装方針については、グリームハブの開発・AI・自動化のご相談で承っています。既存システムの構成によって手当ての優先順位が変わるため、個別にご相談ください。お問い合わせからどうぞ。
