GitHub Actions認証障害で多数のworkflow runが開始できなかった

GitHub Actions と GitHub Pages が、2026-05-26 10:57 UTC から 13:18 UTC まで障害になった。
日本時間では 2026-05-26 19:57 から 22:18 まで。
GitHub Status は途中で、Actions の実行開始と action ダウンロードに関わる認証問題を明記している。

単にrunnerが遅い話ではなく、workflow run を始められない、action を取得できない、という入口側の失敗だった。
公式Statusの文面では run 開始と action ダウンロードに絞っているが、外部の報道では走行中の job も停止、scheduled/cron トリガーも発火しなかった、と書かれている。
runner minutes は残っているのに CI checks が動かない症状で、クォータ不足では? と勘違いしたユーザもいたようだ。
CIをリトライしても、同じ認証層で詰まる時間帯があったことになる。

公式Statusの時系列

GitHub Status のインシデントページでは、対象サービスは Actions と Pages になっている。
時刻を日本時間へ直すとこうなる。

JST	UTC	状態
19:57	10:57	Actions と Pages の degraded performance を調査開始
20:19	11:19	Actions が degraded availability
20:53	11:53	Actions run の開始失敗と actions のダウンロード失敗につながる認証問題を調査。大半の Actions runs が影響
21:17	12:17	Actions の degraded performance を継続調査
21:37	12:37	GitHub Actions に影響する認証問題の原因を特定し、mitigation 中
22:00	13:00	Actions と Pages の degradation をmitigateし、安定性を監視
22:18	13:18	解決。詳細なroot cause analysisは後日共有予定

Cyber Security News はこの障害を「GitHub Down」として取り上げ、CI/CDパイプラインやPages公開に影響したと書いている。
ただ、2026-05-27時点で根本原因の説明はGitHubからまだ出ていない。
Status にあるのは、認証問題が Actions に影響し、原因を特定して緩和し、解決したというところまでだ。

Pagesも巻き込まれた理由

GitHub Pages は以前のような専用ビルド基盤だけではなく、現在は GitHub Actions を標準のデプロイ経路として使う。
GitHub は 2022 年に、Pages のビルドとデプロイを Actions ベースへ寄せたと説明している。

そのため、Actions 側で run の開始や action ダウンロードが失敗すると、静的サイトの更新も止まる。
今回のStatusで Actions と Pages が同じインシデントに入っているのは自然だ。
Pagesそのものの配信が全域で落ちた話なのか、Pages deploy workflow が詰まった話なのかは、Statusの文面だけでは切り分けられない。

5月で2回目、ただし原因系統は別

GitHub Actions の障害は 2026年5月で2回目だ。
5/15 にも 07:43 UTC から 08:48 UTC まで、約65分にわたって Actions が degraded になっている。
こちらは GitHub がpostmortemを出していて、原因は「サポート基盤の planned failover で、自動化された service discovery の更新が正しく伝播しなかった」と説明されている。ピーク時で約42%の run が失敗または開始遅延し、Pages、Coding Agent、Code Review Agent も巻き込まれた。

5/26 の認証問題とは原因系統が違うが、入口側で Actions が止まるという出方は似ている。
月のうち2回、CI/CD を Actions に集約している運用が同じ場所で詰まったことになる。
外部監視で workflow run のステータスを見ていれば、Status の更新を待たずに気付ける、というのは 5/15 のpostmortemでも指摘されている点だ。

リリース待ちのチェックは外部サービス扱いにする

Actions の障害は、コードやテストが壊れていなくてもリリースを止める。
今回のように「workflow run が開始できない」「action をダウンロードできない」形だと、workflow YAMLを触っても直らない。

自分の運用で見るなら、本番デプロイを Actions の成功だけに強く結びつけている箇所が詰まりやすい。
手動デプロイの迂回路、リリース判定の保留ルール、ステータスページを見てから再実行する手順を用意しておくほうが現実的だ。

ここはセキュリティの話とは別だが、CI/CDをGitHub Actionsに集約しているほど影響が広がる点は同じ。
GitHub Actionsの2026年セキュリティロードマップでは、Actions runner、依存関係、シークレット、外向き通信をどう絞るかを書いた。
今回の障害では攻撃やシークレット流出は示されていないが、Actions が止まるとテスト、デプロイ、Pages、セキュリティスキャンが同時に止まる。

まだ分からないところ

GitHub は解決時に、詳細なroot cause analysisを後日共有すると書いている。
2026-05-27時点では、どの認証コンポーネントが壊れたのか、なぜ Actions と Pages に出たのか、再発防止策が何かは公開されていない。

今の段階で言えるのは、認証問題が Actions run 開始と action ダウンロードに波及し、約2時間21分で解決した、という範囲まで。原因が出たら Actions 側の設計で避けられる話だったのかを見直したい。