Require status checks to passとは？GitHubの必須ステータスチェックの設定とPendingで止まる原因

「Require status checks to pass before merging」は、GitHubのブランチ保護ルールとRulesetsにある設定で、指定したCIのチェックが成功するまでプルリクエストをマージさせない仕組みです。有効にすると、必須に指定したチェックがPRの最新コミットで成功（または skipped・neutral）になるまで、マージボタンが押せなくなります。PRのチェック一覧に出る「Required」の表示は、そのチェックがこの条件に入っているという意味です。

この記事では、設定画面の各項目の意味、GitHub Actionsのジョブを必須にするときの名前の決め方、そして「Waiting for status to be reported」のまま進まない、チェック名が検索に出てこない、「Required status checks cannot be empty」で保存できない、といった詰まりどころの原因を、GitHub公式ドキュメントの記述（2026年10月23日時点）に沿って整理します。GitHub自体の障害状況（サービスのステータス）を知りたい場合は、この機能ではなく www.githubstatus.com を確認してください。

まとめ：Require status checks to passの要点

• 意味：必須に指定したチェックが、PRの最新コミットで success・skipped・neutral のいずれかにならない限り、保護されたブランチへマージできない。
• 設定場所：Settings → Branches のブランチ保護ルール、または Settings → Rules → Rulesets。同じブランチに重ねて効き、最も厳しい設定が採用される。新規ならRulesets。
• 候補に出る条件：過去7日以内にそのリポジトリで成功したチェックだけが検索候補に出る。先に一度CIを成功させる。
• Actionsの設計：必須にするのはジョブ名。ワークフローの paths フィルタで起動しないとPendingのまま残るので、変更範囲の判定はジョブ内へ移し、if: always() の集約ジョブ1本だけを必須にする。
• マージキューを使うなら merge_group トリガーが必須。build concurrency を0にするとキューは止まる。
• 2026年10月1日から、チェックとコミットステータスもActionsの保持期間（既定90日）で削除される。長く置いたPRはチェックを作り直してからマージする。

Require status checks to passの意味とマージが止まる条件

必須ステータスチェックが満たされたと判定されるのは、チェックの結論が success・skipped・neutral のどれかのときです。判定対象はPRの最新コミットのSHAで、1つ前のコミットで成功していても要件は満たせません。追加でpushすれば、チェックはやり直しになります。

PRを経由せずに保護ブランチへ直接pushした場合も、必須チェックが通っていなければ拒否されます。このときの応答は次のような形です。

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci-build" is failing

もう1つ見落とされやすいのが、どのコミットのチェックが見られるかです。GitHubはPRごとにテスト用のマージコミットを作ります。このマージコミットにステータスが付いていればそちらが判定対象になり、PRのチェック欄に「Showing checks for the merge commit」と表示されます。付いていなければ、headコミットのチェックが対象です（Troubleshooting required status checks）。

PR画面の「Required」ラベルとチェックの状態

PRのチェック一覧で名前の横に「Required」と付いているものが、マージ条件に指定されたチェックです。成功済みのチェックにもこのラベルは付くため、いまマージを止めているかは結果と併せて見ます。付いていないチェックは失敗してもマージを止めません。チェックは実行中に次の状態を経て、完了すると結論（conclusion）が付きます。右端の列は、gh CLI の gh pr checks --json が返す bucket の分類です（gh 2.103.0のソースで確認）。

状態と結論の定義はGitHub Docsの「Status checks」にあります。同じ「Pending」に見えても、pending は concurrency グループの空き待ち、waiting はEnvironmentのデプロイ保護ルールが満たされるのを待つ状態です。承認待ちのほか、待機タイマーやカスタム保護ルールの判定待ちも含みます。

チェック（Checks）とコミットステータス（Commit statuses）の違い

必須にできる「ステータスチェック」には2種類あります。どちらも必須指定できますが、作られ方と表示が違います。

GitHub Actionsのワークフローが作るのはチェックで、コミットステータスではありません。PRの「Checks」タブに中身が出るのもチェックだけです。同じ名前のチェックとコミットステータスが両方あると、必須指定したその名前について両方が成功する必要があります。外部CIとActionsで同じ名前を使い回していると、片方の失敗でマージが止まり続けます。

ブランチ保護ルールとRulesetsでの設定手順

設定の入口は2つあります。従来のブランチ保護ルール（Settings → Branches）と、後発のRulesets（Settings → Rules → Rulesets）です。両者は共存し、同じブランチに当たるルールはすべて合算され、同じルールが複数あれば最も厳しいものが採用されます。ブランチ保護ルールは1ブランチに1つしか当たらないのに対し、Rulesetsは複数を重ねられ、削除せずに有効・無効を切り替えられ、リポジトリの読み取り権限があれば誰でも内容を確認できます。新しく作るならRulesetsを選びます。

利用できるプランにも注意が要ります。ブランチ保護もRulesetsも、Free（個人・Organization）では公開リポジトリのみで、プライベートリポジトリで使うにはPro・Team・Enterprise Cloudが必要です。

ブランチ保護ルールで有効にする手順

1. リポジトリの Settings → Branches を開き、ブランチ保護ルールを追加または編集する。
2. Branch name pattern に対象（例 main）を入れる。
3. Require status checks to pass before merging にチェックを入れる。
4. 最新のmainで検証させたい場合は Require branches to be up to date before merging も選ぶ。
5. 検索ボックスでチェック名を検索し、必須にするものを選んで保存する。

既定では、リポジトリの管理者（admin権限）や「bypass branch protections」権限を持つカスタムロールには、このルールが適用されません。管理者にも守らせるには Do not allow bypassing the above settings を有効にします。レビュー承認数とあわせた必須化の線引きはGitHubのPull Requestの作り方：作成手順とマージ方式・レビュー必須化の決め方で扱っています。

Rulesetsでの設定と「Do not require status checks on creation」

Rulesetsでは、ルール一覧の Require status checks to pass を有効にし、「Add checks」から必須にするチェックを追加します。ここにはブランチ保護ルールには無い Do not require status checks on creation というオプションがあります。有効にすると、対象パターンに一致するブランチの作成だけはチェック結果に関係なく許可されます。たとえば release/* を対象にしたルールセットで、新しいリリースブランチを切る操作がチェック待ちで拒否される事態を避けられます。作成後のマージには、通常どおりチェックが必須です。

Enterprise Cloudの「Evaluate」モードのルールセットでは、チェックは対象ブランチで走っても必須にはなりません。いきなりActiveにせず、Evaluateでどのチェックが落ちるかを見てから切り替えると、全PRが一斉に止まる事故を避けられます。

候補に無いチェック名を手入力で先に登録したときの挙動

OrganizationやEnterpriseの単位で定義するRulesetsでは、チェック名が候補一覧に出ないため、期待する名前を正確に手入力します（Troubleshooting rules）。リポジトリ単位のRulesetsでも、実行履歴に無い名前を「any source」として追加できることがクラスメソッドの検証記事で報告されており、APIで定義する場合も context には任意の文字列を渡せます。

ただし、まだ存在しない名前を必須にした瞬間から、その名前を報告するジョブが入るまですべてのPRが「Expected — Waiting for status to be reported」で止まります。ジョブ名の変更やワークフローの分割では、次の順で移行します。

1. 新しい名前のジョブを入れたPRをマージし、mainで一度成功させる。
2. 新しい名前を必須チェックに追加する。
3. 旧名を必須チェックから外し、旧ジョブを削除する。

Strict（Require branches to be up to date）とLooseの選び方

Strictは、他の人のマージでmainが進むたびに自分のPRをmainへ追従させて再ビルドする必要があり、PRが多いリポジトリでは「更新→再ビルド→その間に別PRがマージ」の繰り返しになりがちです。この追従でマージ待ちが長くなっているなら、Looseにしてマージキュー（後述）で最新のmainとの結合を検証するほうが待ち時間を減らせます。Looseにしてマージキューも使わない構成は、2本のPRがそれぞれ単独では通るのに合わさると壊れるケースを検出できないため避けます。

期待するソース（GitHub App）の指定

リポジトリへの書き込み権限があれば、人でも連携サービスでも任意のステータスを成功にできてしまいます。これを防ぐのが、チェックごとに「どのGitHub Appからの報告だけを受け付けるか」を固定する指定です。必須チェックを追加するとき、最近そのチェックを報告したAppを期待するソースとして選べます。別の主体が同名のステータスを付けても、マージは許可されません。「any source」を選んだ場合は、マージボックスで各ステータスの送信元を目で確認することになります。Rulesetsでは、Appがリポジトリに statuses:write 権限でインストールされ、最近チェックランを送信し、ルールセット内の既存の必須ステータスチェックに関連付けられていることが条件です（Available rules for rulesets）。

GitHub Actionsのジョブを必須チェックにする設計

Actionsで作られるチェックの名前は、ワークフロー名ではなくジョブ名です（name: を付けていればその値）。再利用可能ワークフローを呼ぶジョブは <呼び出し側のジョブ名> / <再利用側のジョブ名> の形になります。必須チェックの判定はワークフロー名・マトリックス・トリガーの種類を区別しないため、別々のワークフローに同じジョブ名（たとえば test）があると結果が曖昧になり、PRが止まる原因になります。ジョブ名はリポジトリ内のすべてのワークフローで一意にしてください。再利用可能ワークフローの呼び出し方はReusable Workflowsの使い方｜GitHub Actionsのworkflow_call・secrets・outputsと上限で扱っています。

マトリックスのジョブは組み合わせごとに test (22) のような別々のチェックになります。Nodeの版を足すたびに必須チェックの設定を書き換えるのは漏れの元なので、次の集約ジョブを使う構成を勧めます。組み合わせの組み方はGitHub Actionsのマトリックスビルド｜組み合わせ展開とinclude・excludeの調整を参照してください。

集約ジョブ1本だけを必須にする構成

ジョブの依存関係では「先行ジョブが失敗すると後続はスキップされる」ため、ただ needs で繋いだだけの集約ジョブは、失敗時に skipped（＝成功扱い）になってマージを通してしまいます。公式ドキュメントも、ほかのジョブに依存する必須チェックには needs と always() を組み合わせるよう案内しています。次の例は、ルートにpackage.jsonとpackage-lock.jsonがあり、npm test でテストできるプロジェクトを想定しています。

name: ci
on:
  pull_request:
  merge_group:

permissions:
  contents: read
  pull-requests: read

jobs:
  changes:
    runs-on: ubuntu-latest
    outputs:
      backend: ${{ steps.filter.outputs.backend }}
    steps:
      - uses: actions/checkout@v7
      - uses: dorny/paths-filter@v4
        id: filter
        with:
          filters: |
            backend:
              - 'backend/**'
              - 'package*.json'
              - '.github/workflows/**'

  test:
    needs: changes
    if: github.event_name == 'merge_group' || needs.changes.outputs.backend == 'true'
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [22, 24]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

  ci-ok:
    if: always()
    needs: [changes, test]
    runs-on: ubuntu-latest
    steps:
      - if: contains(needs.*.result, 'failure') || contains(needs.*.result, 'cancelled')
        run: exit 1
      - run: echo "required jobs passed or were skipped"

必須チェックに登録するのは ci-ok の1本だけです。test が変更なしでスキップされれば ci-ok は成功し、1つでも失敗・取り消しがあれば exit 1 で失敗します。changes 自体が失敗した場合も needs.*.result に failure が入るので止まります。逆に、needs に書いていないジョブの失敗は拾えないため、lintなどマージを止めるべきジョブを後から足したら ci-ok の needs にも必ず加えます。変更検出の対象には、テスト結果に影響する共通コード・テストファイル・設定ファイルも含めてください。依存関係ファイルを含めないと、package-lock.json だけを更新したPRでテストが飛びます。

このYAMLは actionlint 1.7.12（2026年10月時点の最新）で検査し、警告が出ないことを確認しています。actionlintは文法と式の型は見ますが、「必須にしたジョブがpathsフィルタで起動しない」といった設定との食い違いは検出しません。静的検査の使い方はactionlintとは？GitHub Actionsワークフローの静的解析ツールの使い方・インストール・設定、if 式の評価規則はGitHub Actionsの条件分岐（if）｜書く場所で変わるコンテキストと評価の規則が詳しいです。

paths・branchesフィルタで必須ワークフローを飛ばしてはいけない理由

上の例で、変更ファイルによる絞り込みをワークフローの on.pull_request.paths ではなくジョブの if で行っているのは、スキップのされ方によって必須チェックの扱いが正反対になるからです。

たとえば paths: ['scripts/**'] を付けたワークフローの build を必須にすると、ルート直下のREADMEだけを直したPRではワークフロー自体が起動せず、「Waiting for status to be reported」で止まります。公式の表も、この行の対処を「Avoid requiring workflows that can be skipped.」としています。フィルタの書き方はGitHub Actionsのトリガー（on）｜イベント選定とbranches・pathsフィルタの設計、変更範囲でジョブを分けるモノレポの構成はモノレポ（Monorepo）とは？マルチレポとの違い・メリット・デメリットと導入手順で扱っています。

マージキューを使うときのmerge_groupトリガーとbuild concurrency

マージキューを利用できるのは、Organization所有の公開リポジトリ、またはGitHub Enterprise Cloudを利用するOrganization所有のプライベートリポジトリです。

Require merge queue を有効にすると、キューに入ったPRは最新のベースブランチと前に並ぶPRを結合した一時ブランチで検証されます。このときGitHubが発行するのは merge_group イベントで、pull_request や push とは別物です。ワークフローの on: に merge_group: が無いと必須チェックが報告されず、キューは「Status check timeout」で設定した時間まで待ってから失敗扱いにします。上のYAMLで merge_group のときは test を無条件に走らせているのは、キュー上では結合後の全体を検証したいからです。merge_group にも branches フィルタを付けられるので、キューを使うベースブランチが複数あるときは対象を絞れます。

外部CIを使う場合は、gh-readonly-queue/{base_branch} で始まるブランチへのpushで動くようにCI側を設定します（Managing a merge queue）。キューの Build concurrency は同時に検証を依頼する数で、2026年10月13日にRulesetsのドキュメントへ（github/docsのコミット履歴で確認。以下の10月12日・9月30日の追記も同じ履歴にあります）「0にすると merge_group.checks_requested を新たに発行せず、1以上に戻すまで待機中のPRは進まない」と追記されました。CIの費用を止めるつもりで0にすると、キュー全体が止まります。

Jenkinsなど外部CIのステータスを必須にする方法

JenkinsやCircleCIなどActions以外のCIでも、GitHubにコミットステータスかチェックを送っていれば必須にできます。GitHub Appとして動く連携はチェックを、トークンでAPIを叩くだけの連携はコミットステータスを作るのが一般的です。自前のスクリプトから送る最小形は次のとおりです。

gh api repos/OWNER/REPO/statuses/"$GIT_COMMIT" \
  -f state=success \
  -f context=jenkins/build \
  -f description="Build #128 passed" \
  -f target_url=https://ci.example.com/job/app/128/

state に使えるのは error・failure・pending・success の4つです。必須チェックとして登録される名前は context の値で、大文字小文字は区別されず、省略すると default になります（REST API endpoints for commit statuses）。ビルド開始時に pending、終了時に結果を送る2回送信にしておくと、実行中であることがPR画面に出ます。同じSHAと context の組み合わせに送れるのは1000件までなので、進捗のたびに送り直す実装は避けます。送信は対象のコミットSHAに対して行うため、PRのheadコミットのSHAを正しく渡しているかが、外部CIで「Waiting for status」が解けないときの最初の確認点です。

Actionsと外部CIを組み合わせたパイプライン全体の設計や移行を外部に任せたい場合は、DevOps・CI/CD導入支援で相談を受け付けています。

Require workflows to pass・コードカバレッジ規則との違い

Rulesetsには、必須ステータスチェックと似た名前のルールがあります。混同すると「設定したのに止まらない」「止まりすぎる」の原因になるので、役割を分けておきます。

Require workflows to pass before merging（ルールセットワークフロー）は、各リポジトリにワークフローを置かなくても、Organization側で指定したワークフローを対象リポジトリのPRで走らせて必須にします。PRとマージキューの流れの中で動くため直接pushはブロックされ、すべての変更がPR経由のブランチだけを対象にするよう公式が注意しています。GITHUB_TOKEN が起こしたイベントでは走らず、ルールを作る前から開いているPRでは自動で走りません（新しいコミットのpushか、PRの閉じ直しで起動します）。2026年10月12日には、CodeQLのアクションは github/codeql-action/upload-sarif 以外使えないことも追記されました。

Restrict code coverage はパブリックプレビューの機能です。アップロード済みのカバレッジだけを評価し、アップロードの完了は待ちません。2026年9月30日の追記で、カバレッジを送るジョブのチェックをそれぞれ必須ステータスチェックにするよう案内されています。つまりカバレッジ規則を入れるなら、必須ステータスチェックとの併用が前提です。CodecovなどでカバレッジをPRに出す設定はCodecovとは｜GitHub Actions連携とcodecov.ymlの設定手順、品質ゲート全体の考え方はコード品質とは？測る指標と品質ゲートでCIに組み込む手順を参照してください。

Pendingのまま・候補に出ない・保存できないときの原因

必須ステータスチェックの設定時やマージ時に出る症状を、原因ごとに分けます。

チェック名が検索候補に出ない原因と実行条件

候補に出るのは、過去7日以内にそのリポジトリで成功したチェックだけです。作ったばかりのワークフローや、しばらく動いていないCIは出てきません。一度PRを作るなどしてチェックを成功させてから設定し直します。

もう1つの原因がトリガーの種類です。Actionsのジョブが作るチェックがPRで評価されるのは、ワークフローが push・pull_request・pull_request_review・pull_request_target・deployment・deployment_status のいずれかで起動した場合に限られます。workflow_dispatch で手動実行したチェックは、headコミットで成功していてもPRのチェック欄に出ず、必須チェックも満たしません。この制約はActionsのジョブにだけ適用され、外部のGitHub Appが作るチェックには当てはまりません。

「Waiting for status to be reported」の原因と確認順序

必須にした名前のチェックが、そのコミットで作られていない状態です。上から順に確認します。

1. ワークフローが paths ／ branches フィルタや [skip ci] でそもそも起動していないか。
2. ジョブ名を変更していないか。name: を変えると旧名の必須チェックは報告されない（移行手順は前述）。
3. PRにマージコンフリクトが無いか。pull_request のワークフローはコンフリクトを解消するまで走らない。
4. bot が作ったPRではないか（次の項）。
5. マージキュー上で止まっているなら、merge_group トリガーと build concurrency を確認する。

チェック自体は表示されていて状態が pending なら concurrency グループの空き待ち、waiting ならEnvironmentのデプロイ保護ルール待ちです。承認者の対応状況、待機タイマー、カスタム保護ルールの判定結果を確認します（GitHub ActionsのEnvironments｜承認ゲートと環境別シークレットの設計）。

botやGITHUB_TOKENが作ったPRの実行承認と対処

以前は、github-actions[bot]（ワークフロー内の GITHUB_TOKEN）が作ったPRではワークフローが起動せず、必須チェックを設定したブランチでは永遠に「Waiting」のまま、設定していないブランチではCIを通らずにマージできてしまう問題がありました。2026年6月11日のGitHubのchangelogで、こうしたPRも書き込み権限を持つユーザーが承認すればワークフローを実行できるようになりました。現在のドキュメントでは、GITHUB_TOKEN で作成・更新されたPRの opened・synchronize・reopened は承認待ちの実行を作り、PR画面から承認すると走ると説明されています。

依存関係の自動更新などでbotのPRが多いリポジトリでは、毎回の承認が手間になります。承認なしで走らせたいなら、PRの作成を GITHUB_TOKEN ではなく専用のGitHub Appのトークンで行う構成に切り替えます。

「Required status checks cannot be empty」の原因と対処

エラー文のとおり、Require status checks to pass を有効にしたまま、必須にするチェックが1つも登録されていない状態です。REST APIの仕様でも、Rulesetsの required_status_checks は省略できない項目で、strict_required_status_checks_policy は「チェックが1つ以上ないと効かない」と書かれています。チェックを1つ以上追加するか、このルールをオフにして保存します。チェック名が候補に出ないために空のまま保存しようとしている場合は、先に「過去7日以内に成功」の条件を満たすか、名前を手入力します。

「was not set by the expected GitHub App」の原因と送信元の確認

Required status check "build" was not set by the expected GitHub App. は、期待するソースに固定したAppとは別の主体が、同じ名前でステータスを付けたときの表示です。CIを別のサービスへ移した、あるいは外部CIとActionsが同じ名前を使っている、といったケースで起きます。設定側の期待するソースを付け替えるか、送信側の名前を変えて衝突を解消します。

2026年10月1日からのチェック保持期間と古いPR

2026年10月1日から、チェック・ワークフロー実行・コミットステータスもActionsの保持期間設定に従って削除されるようになりました（GitHubのchangelog）。それまでは設定に関係なく400日以上残っていました。

設定画面の項目名は「Check, workflow run, status, artifact and log retention」に変わっています。設定を延ばしても既存のデータには遡って効かず、削除済みのデータも戻りません。保持期間を過ぎて置かれたPRは、最新コミットのチェックが消えているため、空コミットのpushかPRの閉じ直し（pull_request の既定の起動条件に reopened が含まれる）でワークフローを起動し、チェックを作り直してからマージします。

REST APIとgh CLIによる必須チェックの設定・監視

リポジトリが多い組織では、画面で1つずつ設定するより、Rulesetsを定義ファイルで管理するほうが漏れを防げます。次の ruleset.json は、デフォルトブランチに対して ci-ok を必須にし、そのチェックをGitHub Actions（App ID 15368）からの報告に限る例です。

{
  "name": "main-required-checks",
  "target": "branch",
  "enforcement": "active",
  "conditions": {
    "ref_name": { "include": ["~DEFAULT_BRANCH"], "exclude": [] }
  },
  "rules": [
    {
      "type": "required_status_checks",
      "parameters": {
        "strict_required_status_checks_policy": true,
        "do_not_enforce_on_create": false,
        "required_status_checks": [
          { "context": "ci-ok", "integration_id": 15368 }
        ]
      }
    }
  ]
}

gh api repos/OWNER/REPO/rulesets --method POST --input ruleset.json

画面の項目とAPIのパラメータは、Require branches to be up to date が strict_required_status_checks_policy、Do not require status checks on creation が do_not_enforce_on_create、期待するソースが integration_id に対応します。enforcement の evaluate はGitHub Enterpriseでのみ使えます。

従来のブランチ保護APIでは、required_status_checks.contexts（名前の文字列配列）に「Closing down notice」が付き、checks 配列に context と app_id を渡す形へ移すよう案内されています。app_id を省くと最近そのチェックを報告したAppが自動で選ばれ、-1 を渡すと任意のAppを許可します。ただし2026年10月時点の公式OpenAPI定義（github/rest-api-description）では、contexts は deprecated の印が付いたまま required にも残っています。この定義から生成したクライアントで型エラーになる場合は、"contexts": [] を渡して checks 側で指定します。

PR側の確認には gh CLI が便利です。必須チェックだけを表示して完了まで待てます（gh CLIの公式マニュアルに記載）。

gh pr checks 123 --required --watch --fail-fast
gh pr checks 123 --required --json name,state,bucket

--watch を付けずに実行した場合、チェックが未完了なら終了コード8が返るので、スクリプト側で「まだ待つ」と「失敗」を区別できます。--json と --watch は同時に指定できません。必須チェックが1つも報告されていないPRに --required を付けると、no required checks reported on the '<ブランチ名>' branch というエラーになります。

よくある質問

Require status checks to pass とはどういう意味ですか？

「マージする前に、必須に指定したステータスチェックをすべて通すこと」を求めるGitHubのブランチ保護の設定です。通ったとみなされるのは success・skipped・neutral で、判定はPRの最新コミットに対して行われます。PR画面の「Required」は、そのチェックがこの条件に入っている印です。

無料プランのプライベートリポジトリでも必須ステータスチェックは使えますか？

使えません。ブランチ保護もRulesetsも、Freeでは公開リポジトリのみが対象です。プライベートリポジトリで使うにはPro・Team・Enterprise Cloudのいずれかが必要です。

管理者は必須チェックが失敗していてもマージできますか？

ブランチ保護ルールの既定では、admin権限を持つ人と「bypass branch protections」権限のロールには制限が適用されません。管理者にも守らせるには「Do not allow bypassing the above settings」を有効にします。Rulesetsでは、迂回を許可する人・チーム・Appをバイパスリストで明示します。

[skip ci] を付けたコミットで必須チェックを飛ばせますか？

飛ばせません。[skip ci] や skip-checks: true でワークフローが起動しないと、必須チェックはPendingのまま残り、PRはマージできなくなります。スキップ指示を含まないコミットを追加でpushすると、チェックが走ってマージできる状態に戻ります。

GitHubの障害状況（ステータス）はどこで確認できますか？

GitHubのサービス自体の稼働状況は www.githubstatus.com で公開されています。Actionsの遅延などでチェックが報告されない場合は、設定を疑う前にこちらでActionsやAPIの障害が出ていないかを確認してください。

関連記事

• GitHub Actionsのトリガー（on）｜イベント選定とbranches・pathsフィルタの設計
• GitHub Actionsの条件分岐（if）｜書く場所で変わるコンテキストと評価の規則
• GitHubのPull Requestの作り方：作成手順とマージ方式・レビュー必須化の決め方
• GitHub ActionsのEnvironments｜承認ゲートと環境別シークレットの設計
• GitHub Actionsでビルド・自動テストを設定する方法｜CI/CDワークフローの作り方