GitHub Actions大規模障害：症状と対応

冒頭まとめ

この記事は設定ミスの記事ではありません。 2026年8月6日から7日にかけて発生した、GitHub 側のサービス障害の記録です。

permissions の見直し、workflow ファイルの書き換え、トークンの再発行、ランナーの再登録——これらを行っても状況は変わりません。原因は利用者側の設定にないためです。

対象期間は、公式の調査開始が日本時間の8月7日 0:22（UTC 8月6日 15:22）、影響の緩和が確認されたのが8月7日 9:05（UTC 0:05）です。本記事の執筆時点で公式の状態は「監視中」であり、正式な解決の宣言はまだ出ていません。最新の状況は公式のインシデントページ（Incident with Actions）で確認してください。

この障害の特徴は、単一のエラー文言では説明できないことです。停止した処理の段階によって、症状がまったく違う形で現れました。「Actions が動かない」という同じ体験でも、どの段階で止まったかによって、取るべき対応が変わります。

何が起きたか：処理段階ごとの症状

公式の更新をもとに、停止した段階ごとに整理します。

とくに重要なのが1行目です。公式の説明によれば、復旧を助けるために webhook の起点が意図的に絞られていました。一時は全体の約15%しか処理されていない状態です。

つまり、push しても何も起きない、pull request を作ってもワークフローの一覧に何も現れない、という状況が発生していました。利用者から見れば「自分の設定が壊れた」ようにしか見えませんが、実際には復旧のための措置です。この段階で workflow ファイルを触っても、何も変わりません。

3行目も特徴的です。公式は途中で「既に有効でないジョブがランナーへ割り当てられている」問題を特定したと発表しています。GitHub 側が用意するランナーと、自前で用意するランナーの両方が影響を受けました。

利用者側の問題との見分け方

以下の兆候が複数当てはまる場合、原因は自分の設定ではありません。

ワークフローそのものが作成されない。特定のジョブが失敗するのではなく、実行が始まらないのが特徴です。

複数のリポジトリで同時に発生している。設定はリポジトリごとに独立しているため、同時発生は外部要因を示します。

GitHub 側のランナーと自前のランナーの両方で失敗している。この2つは実行環境が別なので、片方だけの設定問題では説明できません。

設定を変更していないワークフローまで失敗している。

Actions API や Pages など、Actions 以外にも同時に症状が出ている。

公式のステータスページにインシデントが掲載されている。

逆に、特定のジョブや特定の API 操作だけが再現性をもって失敗する場合は、利用者側の問題です。とくに Resource not accessible by integration のように権限を示す文言が特定の操作で必ず出るなら、そちらを調べてください（GitHub の Resource not accessible by integration の記事）。

障害中にしてよいこと

障害そのものは利用者側で解決できません。ここでの目的は、復旧後に困らないための記録と、二次被害の防止です。

発生時刻、実行の識別子、対象のコミット、API の応答内容を保存します。復旧後に「どこまで進んだか」を確認する材料になります。

公式のステータス更新を購読します。ページを繰り返し開くより確実です。

重複して実行されると危険な配備を、一時的に止めます。とくに外部への通知、課金処理、本番環境への反映を含むものが対象です。

復旧後に再実行すべきジョブを整理しておきます。障害中に失敗したものと、そもそも起動しなかったものは、扱いが違います。

書き込みを伴う処理は、外部の側で処理済みかどうかを確認してから再実行します。

障害中に避けること

この節が、この記事で最も実用的な部分です。障害中の善意の操作が、復旧後に問題を残します。

根拠なく permissions を広い設定へ変更しない。障害が終われば元に戻す必要がありますが、その作業自体が忘れられます。広げた権限が残ることが、次の事故の入り口になります。

トークンや秘密情報を作り直さない。原因ではないうえ、再発行は他のワークフローを壊す可能性があります。

workflow ファイルを次々に変更しない。変更するたびに履歴が増え、復旧後にどれが有効な設定だったか分からなくなります。

queued のままの状態に対して、再実行を大量に投入しない。キューの滞留を悪化させます。公式も、復旧作業としてキューの消化を進めていました。

書き込み処理を、状態を確認せずに再実行しない。応答が失敗でも、処理だけは完了している可能性があります。とくに配備、リリースの作成、外部システムへの通知が該当します。

自前のランナーを設定不良と決めつけて再登録しない。今回は、ランナーの登録時にエラーや利用制限が出る状態が公式に報告されています。再登録しても同じ結果になります。

公式のタイムライン

公式の更新のみを記載します。日本時間と協定世界時を併記します。

成功率の推移（30〜40% → 65% → 97% → 99%）は、どの時間帯の失敗が障害由来かを判断する材料になります。自分の実行記録の時刻と突き合わせてください。

なお、Enterprise Importer による移行は、監視中へ移行した時点でも停止したままと発表されています。この機能を使っている場合は、再開の告知を待つ必要があります。

復旧後の確認

監視中への移行は、解決の宣言ではありません。以下を自分で確認してください。

新しい push でワークフローが作成されるか。webhook の起点が絞られていた影響が残っていないかを見ます。

queued の状態からランナーの割り当てへ進むか。

Actions API が正常に応答するか。

同じコミットに対する重複した配備が残っていないか。障害中の再実行が二重に効いている可能性があります。

Pages やリリースなど、成果物が実際に反映されているか。ジョブが成功していても、配信側が追いついていない場合があります。

障害中に起動しなかったワークフローを洗い出し、必要なものを手動で実行します。起動しなかったものは、あとから自動的には実行されません。

原因について現時点で言えること

公式に発表されている範囲では、無効になったジョブがランナーへ割り当てられていた問題が特定され、その修正が展開されています。GitHub 側のランナーと自前のランナーの両方が影響を受けました。

それ以上の原因は、執筆時点で公表されていません。推測で補わないでください。 詳細な原因分析は、公式が後日公開する形になります。

公開されたあとに確認すべき点を挙げておきます。障害を引き起こした内部の変更や構成要素。webhook の絞り込みが必要になった理由。GitHub 側と自前の両方のランナーへ波及した経路。再発防止策。そして、利用者側の設計に反映できる教訓です。

補足：似ているが別のもの

特定の API 操作だけが権限のエラーで失敗する場合は、今回の障害とは別です。発生する段階も対処もまったく違います（GitHub の Resource not accessible by integration の記事）。

API が特定の状態コードを返す場合も、恒常的な原因と障害由来を区別する必要があります（GitHub API の 503 の記事）。今回の障害を「503 の障害」「409 の障害」と要約するのは正確ではありません。症状は複数の段階にまたがっており、単一の状態コードには収まらないためです。

なお、同じ8月6日には Pages の配信遅延が別のインシデントとして記録され、日本時間 8月7日 1:22（UTC 16:22）に解決しています。Pages の症状には、こちらに由来するものが混在している可能性があります。

切り分けの順序

1. 公式のステータスページを確認する。掲載があれば、設定を触る前に止まる。
2. ワークフローが「失敗した」のか「作成されなかった」のかを区別する。後者は webhook 段階。
3. 複数のリポジトリで同時に起きているかを確認する。
4. GitHub 側と自前のランナーの両方で起きているかを確認する。
5. 発生時刻を記録し、公式のタイムラインと突き合わせる。
6. 書き込みを伴う処理は、外部側の状態を確認するまで再実行しない。
7. permissions やトークンを変更しない。障害中の変更は復旧後に残る。
8. 復旧後、起動しなかったワークフローを洗い出して手動で実行する。

確認コマンド集

# 1. 公式のステータスを取得する（障害の有無を最初に確認）
curl -sS https://www.githubstatus.com/api/v2/status.json \
  | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['status']['indicator'], '|', d['status']['description'])"

# 2. 進行中のインシデントを一覧する
curl -sS https://www.githubstatus.com/api/v2/incidents/unresolved.json \
  | python3 -c "
import json,sys
for i in json.load(sys.stdin)['incidents']:
    print(i['created_at'], i['status'], i['name'])
"

# 3. 影響を受けている構成要素を確認する
curl -sS https://www.githubstatus.com/api/v2/components.json \
  | python3 -c "
import json,sys
for c in json.load(sys.stdin)['components']:
    if c['status'] != 'operational': print(c['name'], '->', c['status'])
"

# 4. 指定期間に失敗した実行を一覧する（記録の保存用）
gh run list --repo <所有者>/<リポジトリ> --status failure --limit 100 \
  --json databaseId,name,headSha,createdAt,conclusion

# 5. キューのまま滞留している実行を確認する
gh run list --repo <所有者>/<リポジトリ> --status queued \
  --json databaseId,name,createdAt

# 6. 特定のコミットに対する実行が作成されたかを確認する（webhook 段階の判定）
gh run list --repo <所有者>/<リポジトリ> --commit <コミットSHA> \
  --json databaseId,event,status,conclusion

# 7. 復旧後に、必要なワークフローを手動で起動する
gh workflow run <ワークフロー名> --repo <所有者>/<リポジトリ> --ref <ブランチ>

# 8. 自前のランナーの登録状態を確認する（再登録の前に）
gh api repos/<所有者>/<リポジトリ>/actions/runners \
  --jq '.runners[] | {name, status, busy}'

Editor’s Note

この障害で最も示唆的なのは、復旧のための措置が、利用者には障害の悪化に見えたという点です。

公式の更新によれば、GitHub は復旧を進めるために webhook の起点を意図的に絞りました。一時は全体の約15%しか処理していない、と明示されています。その結果として、push しても pull request を作っても、ワークフローが作成されない状態が続きました。

利用者の側から見ると、これは最も設定ミスらしく見える症状です。ジョブが失敗するならログを読めますが、そもそも実行が作成されないなら、疑うのは自分の workflow ファイルか権限設定でしょう。実際には、GitHub 側が回復のために流量を絞っていた結果でした。

ここに、障害対応の原則が現れています。症状の見た目と、原因の所在は一致しない。 そして、症状が「自分の設定が悪い」ように見えるときほど、外部要因の確認を先に済ませる価値があります。ステータスページを見るのに要する時間は数十秒ですが、permissions を書き換えて検証する時間は数十分かかり、しかも復旧後にその変更が残ります。

もう1つ、この記録から読み取れることがあります。公式のタイムラインでは、成功率が30〜40%まで落ち、65%、97%、99% と段階的に戻っています。障害は「落ちている」か「戻っている」かの二値ではありません。 復旧の途中で成功した実行と失敗した実行が混在するため、「一度成功したから解決した」とは判断できません。時刻と成功率の推移を突き合わせて、自分の実行がどの局面にあったかを見てください。

免責事項：本記事の内容は、執筆時点の公開情報をもとに作成したものです。ソフトウェアの仕様は予告なく変更されることがあります。最新の情報は各ツールの公式サポートページをご確認ください。本記事の情報を利用した結果生じたいかなる損害についても、著者および運営者は責任を負いかねます。