GitHubが7時間47分停止——「そこが止まったら何も進まない」を洗い出す

※ 本記事は2026年8月24日時点の公開情報に基づきます。最新情報は各社公式発表等をご参照ください。

GitHubは2026年8月20日、同社CTOのVlad Fedorov氏の名義で、8月17日に発生した障害についての説明を公表しました。継続時間は7時間47分。影響はgithub.comにとどまらず、認証、GitHub Actions、API、プルリクエスト、Issues、そしてCopilotにまで及びました。原因について同社はこう記しています。「私たちの調査により、トラフィックが新たなピークに達したとき、Central USデータセンターの重要なインフラコンポーネントがそれに合わせてスケールできなかったことで障害が始まったことが分かった」（出典: GitHub 公式ブログ）。

止まったのは1社ではなく、そこに乗っていた全員

運用の観点で重い事実は、影響範囲の広がり方です。コードの保管場所が止まっただけなら、影響は限定的だったはずです。しかし実際には認証が落ち、自動化が止まり、AI支援も使えなくなりました。

多くの企業は、いつの間にか1つの基盤の上に、開発・デプロイ・レビュー・AI支援を積み上げています。便利さの裏側で、単一の障害点に業務全体がぶら下がる構造ができあがる。今回はそれが7時間47分にわたって可視化された形です。

「連鎖」が被害を大きくする

GitHubが挙げた再発防止策の一覧は、そのまま点検リストとして使えます。重要システムの分離、共有依存の排除、リトライの上限と予算の一貫した実装、CPU・メモリのアラートの見直し、テストとロールアウト手順の改善、可観測性とアラートの強化。加えて、monorepoの読み取り容量を線形にスケールさせること、そして現在プラットフォーム負荷の**58%**を担うAzure基盤の拡張が挙げられています（出典: 同上）。

注目したいのは「リトライの上限と予算」です。障害時、クライアントが自動で再試行を繰り返すと、復旧しようとしているシステムに追加の負荷がかかります。善意の自動化が復旧を遅らせる。自社で組んだ自動処理にも、同じ性質の危険が潜んでいます。

「7時間47分」を自社に置き換える

数字を自社に当てはめると、意味が具体的になります。朝から夕方まで、業務システムが使えない。受注も、出荷指示も、請求も止まる。その間の売上は、翌日に取り戻せるものと、そのまま消えるものに分かれます。

事業継続計画というと大がかりに聞こえますが、実務で必要なのは消える売上がどれかを知っておくことです。翌日に回せるなら、慌てて代替策を用意する必要はありません。消えるなら、そこだけ手当てすればよい。全業務を守ろうとすると計画は完成しませんが、対象を絞れば1日で作れます。

中小企業への翻訳——復旧を待つ以外の選択肢を持つ

自社でインフラを運用していなくても、やることは同じです。所要は半日です。

1. 「止まると何も進まない」サービスを列挙する。 業務システム、認証（シングルサインオン）、チャット、クラウドストレージ、会計。名前を並べるだけで、依存の集中は見えてきます。

2. 1つずつ「止まったら何が止まるか」を書く。 受注は取れるか、請求は出せるか、給与は払えるか。想像ではなく、業務単位で書き出します。

3. 手作業の代替手順を1枚にする。 全業務は要りません。当日の売上に直結する2〜3業務だけ、紙とメールで回す手順を用意しておく。年に一度使うかどうかですが、使う日は必ず来ます。

あわせて、社内の自動処理に再試行の上限を入れているか確認してください。無制限のリトライは、相手先が復旧したあとに自社を詰まらせます。

まとめ

• GitHubは2026年8月20日、8月17日に発生した7時間47分の障害について説明を公表。影響はgithub.com、認証、GitHub Actions、API、プルリクエスト、Issues、Copilotに及んだ
• 原因は、トラフィックが新たなピークに達した際に、Central USデータセンターの重要なインフラコンポーネントがスケールできなかったこと
• 再発防止策として、重要システムの分離、共有依存の排除、リトライ上限と予算の一貫した実装、アラートの見直し、可観測性の強化、monorepo読み取り容量の線形スケール、Azure基盤（現在プラットフォーム負荷の58%を担う）の拡張が挙げられている
• 中小企業が取れる対策は、依存サービスの列挙、業務単位での停止影響の記述、主要業務の手動代替手順の用意、そして社内自動処理へのリトライ上限の設定

クラウドの障害は、自社の努力では防げません。防げないからこそ、止まった数時間をどう過ごすかだけが自社の裁量です。復旧を待つしかない会社と、代替手順に切り替えられる会社の差は、事前の半日で決まります。可用性を買うのではなく、止まる前提で設計しておくことが現実的な備えだと私たちは考えます。