---
title: "Require status checks to passとは？GitHubの必須ステータスチェックの設定とPendingで止まる原因"
url: "https://www.issoh.co.jp/tech/details/5873/"
published: 2025-03-17
updated: 2026-10-23
categories: ["GitHub"]
publisher: "株式会社一創"
---

# 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](https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/troubleshooting-required-status-checks)）。

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

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

| 状態・結論                                  | 意味                            | マージ | gh の bucket |
| -------------------------------------- | ----------------------------- | --- | ----------- |
| `expected`                             | 報告待ち（Actions専用）               | 不可  | pending     |
| `requested` ／ `queued` ／ `in_progress` | 作成済み・待機中・実行中                  | 不可  | pending     |
| `pending`                              | concurrency の上限で待機（Actions専用） | 不可  | pending     |
| `waiting`                              | Environment の保護ルール待ち          | 不可  | pending     |
| `success`                              | 成功                            | 可   | pass        |
| `skipped` ／ `neutral`                  | スキップ・中立                       | 可   | skipping    |
| `failure` ／ `timed_out`                | 失敗・タイムアウト                     | 不可  | fail        |
| `cancelled`                            | 取り消し                          | 不可  | cancel      |
| `action_required`                      | 要対応で完了                        | 不可  | fail        |
| `stale`                                | 時間がかかりすぎて失効                   | 不可  | pending     |

状態と結論の定義は[GitHub Docsの「Status checks」](https://docs.github.com/en/pull-requests/reference/status-checks)にあります。同じ「Pending」に見えても、`pending` は concurrency グループの空き待ち、`waiting` はEnvironmentのデプロイ保護ルールが満たされるのを待つ状態です。承認待ちのほか、待機タイマーやカスタム保護ルールの判定待ちも含みます。

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

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

| 種類           | 作る主体                   | 中身            | API          |
| ------------ | ---------------------- | ------------- | ------------ |
| チェック（Checks） | GitHub Apps（Actions含む） | ログ・アノテーション・詳細 | Checks API   |
| コミットステータス    | 外部サービス・連携              | 状態と短い説明のみ     | Statuses API |

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の作り方：作成手順とマージ方式・レビュー必須化の決め方](/tech/details/18004/)で扱っています。

### 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](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-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（既定） | up to date にチェック | 最新のベースを取り込み済み | mainが進むたびに再ビルド |
| Loose      | up to date を外す   | ベースとの差は問わない   | マージ後にmainが壊れうる |
| 無効         | 必須チェック自体を外す      | 制限なし          | 非互換な変更が入りやすい   |

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](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets)）。

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

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

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

### 集約ジョブ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ワークフローの静的解析ツールの使い方・インストール・設定](/tech/details/10397/)、`if` 式の評価規則は[GitHub Actionsの条件分岐（if）｜書く場所で変わるコンテキストと評価の規則](/tech/details/16957/)が詳しいです。

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

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

| スキップの原因                       | チェックの結果     | 必須チェックへの影響 |
| ----------------------------- | ----------- | ---------- |
| ワークフローの paths ／ branches フィルタ | Pending のまま | マージが止まる    |
| コミットメッセージの `[skip ci]` 等      | Pending のまま | マージが止まる    |
| ジョブの `if` が偽                  | Success     | 通る         |
| 依存先ジョブの失敗で後続がスキップ             | スキップ        | 止まらないことがある |

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

### マージキューを使うときの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](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue)）。キューの **Build concurrency** は同時に検証を依頼する数で、2026年10月13日にRulesetsのドキュメントへ（[github/docsのコミット履歴](https://github.com/github/docs/commits/main/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md)で確認。以下の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](https://docs.github.com/en/rest/commits/statuses)）。ビルド開始時に `pending`、終了時に結果を送る2回送信にしておくと、実行中であることがPR画面に出ます。同じSHAと `context` の組み合わせに送れるのは1000件までなので、進捗のたびに送り直す実装は避けます。送信は対象の**コミットSHA**に対して行うため、PRのheadコミットのSHAを正しく渡しているかが、外部CIで「Waiting for status」が解けないときの最初の確認点です。

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

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

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

| ルール                                      | 何を強制するか          | 定義する場所                     |
| ---------------------------------------- | ---------------- | -------------------------- |
| Require status checks to pass            | 指定した名前のチェック成功    | リポジトリ・Organization         |
| Require workflows to pass before merging | 指定したワークフローの実行と成功 | Organization・Enterpriseの設定 |
| Restrict code coverage                   | 行カバレッジのしきい値      | Rulesets（Code Quality有効時）  |

**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の設定手順](/tech/details/17720/)、品質ゲート全体の考え方は[コード品質とは？測る指標と品質ゲートでCIに組み込む手順](/tech/details/5209/)を参照してください。

## 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｜承認ゲートと環境別シークレットの設計](/tech/details/16935/)）。

### botやGITHUB\_TOKENが作ったPRの実行承認と対処

以前は、`github-actions[bot]`（ワークフロー内の `GITHUB_TOKEN`）が作ったPRではワークフローが起動せず、必須チェックを設定したブランチでは永遠に「Waiting」のまま、設定していないブランチではCIを通らずにマージできてしまう問題がありました。2026年6月11日の[GitHubのchangelog](https://github.blog/changelog/2026-06-11-bot-created-pull-requests-can-run-workflows-if-approved/)で、こうした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](https://github.blog/changelog/2026-07-17-actions-retention-will-cover-checks-workflow-runs-and-statuses/)）。それまでは設定に関係なく400日以上残っていました。

| 項目           | 値                        |
| ------------ | ------------------------ |
| 既定の保持期間      | 90日                      |
| 公開リポジトリの設定範囲 | 1〜90日                    |
| プライベートの設定範囲  | 1〜400日                   |
| 対象           | Actionsと外部アプリのチェック・ステータス |
| 設定変更の効き方     | 新しく作られるものだけ              |

設定画面の項目名は「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フィルタの設計](/tech/details/16923/)
- [GitHub Actionsの条件分岐（if）｜書く場所で変わるコンテキストと評価の規則](/tech/details/16957/)
- [GitHubのPull Requestの作り方：作成手順とマージ方式・レビュー必須化の決め方](/tech/details/18004/)
- [GitHub ActionsのEnvironments｜承認ゲートと環境別シークレットの設計](/tech/details/16935/)
- [GitHub Actionsでビルド・自動テストを設定する方法｜CI/CDワークフローの作り方](/tech/details/2497/)

---

出典: [Require status checks to passとは？GitHubの必須ステータスチェックの設定とPendingで止まる原因](<https://www.issoh.co.jp/tech/details/5873/>)（株式会社一創）