GitHub・プルリク・必須のステータスチェック・2026年10月26日に確認

GitHub：必須のチェックが「Expected — Waiting for status to be reported」のまま

ブランチの保護やルールセットは、マージの前に通るべきステータスチェックを必須にできます。プルリクの最新のコミットにまだ報告していない必須のチェックは、マージの欄に「Expected — Waiting for status to be reported」（予定・報告待ち）と出ます（GitHub のコミュニティの報告に引かれている文）。報告して合格するまで、プルリクはブロックされたままです。下の原因は GitHub の説明「必須のステータスチェックのトラブルシューティング」によります。API ではプルリクの mergeable_state が blocked、GraphQL の mergeStateStatus が BLOCKED です（2026年10月26日に確認）。

GET /repos/OWNER/REPO/branches/BRANCH         → protection.required_status_checks.contexts
GET /repos/OWNER/REPO/rules/branches/BRANCH   → 規則 "required_status_checks" の required_status_checks[].context
GET /repos/OWNER/REPO/commits/SHA/check-runs  → check_runs[].name
GET /repos/OWNER/REPO/commits/SHA/status      → statuses[].context

報告が来ない理由

ワークフローが飛ばされた：パスの絞り込み、ブランチの絞り込み、コミットのメッセージの飛ばす指示（[skip ci]）でワークフローが飛ばされると、そのチェックは保留のまま残り、マージを止めます。GitHub の例では、scripts 以下のファイルが変わった時だけ走るワークフローに対し、リポジトリの直下のファイルだけを変えたプルリクが「Waiting for status to be reported」でブロックされます。GitHub の勧めは、飛ばされうるワークフローを必須にしないことです。
数に入らないイベント：ワークフローのジョブのチェックがプルリクで数に入るのは、実行のきっかけが push・pull_request・pull_request_review・pull_request_target・deployment・deployment_status のときだけです。head のブランチで workflow_dispatch から始めた実行は、head のコミットで合格しても必須を満たしません。外部の GitHub App のチェックには当てはまりません。
マージの衝突：プルリクに衝突がある間は、pull_request のワークフローは走りません。先に衝突を解きます。pull_request_target のワークフローは走ります（GitHub の説明「ワークフローを起動するイベント」）。
マージキュー：GitHub Actions のチェックを必須にしたキューでは、ワークフローを別の merge_group イベントでも走らせる必要があります。無いとチェックが報告されず、マージは失敗します。
承認待ちのフォークの実行：フォークから出したプルリクのワークフローの実行は、書き込み権限のあるメンテナーの承認が要ることがあります（「Awaiting approval」→「Approve workflows to run」）。30日を超えて承認を待った実行は期限切れになり、失敗の扱いになります。
別の名前：必須は名前で決まります。ジョブの名前を変えたなどで別の名前で報告したチェックは、必須のチェックの代わりにならず、必須のほうは「Expected」のまま残ります。必須の名前と、head のコミットに報告された名前を比べます（上の4つの読み取り）。
別のアプリ：必須には、チェックを付けるべき GitHub App を指定できます（ブランチの保護では app_id、ルールセットでは integration_id）。ほかの人や連携が付けた状態ではマージできず（GitHub の説明「保護されたブランチについて」）、GitHub は例えば「Required status check "build" was not set by the expected GitHub App.」（必須のチェック build が、決められた GitHub App から付けられていません）と言います。
前のコミット：必須のチェックは最新のコミットで合格する必要があり、前のコミットのチェックは数に入りません。push の後は、もう一度報告が要ります。

合格として数えられる物

結果：success・skipped・neutral は必須を満たします。条件で飛ばされたジョブは「Success」と報告し、必須でもマージを止めません（GitHub の説明「ステータスチェック」）。cancelled（取り消し）や stale になったチェックは満たさず、もう一度走るまで止めます（取り消されたチェック）。
失敗したジョブの後のジョブ：needs の先が失敗したジョブは飛ばされ、マージを止めないことがあります。ほかのジョブに頼る必須のチェックには、needs と一緒に always() を使うよう GitHub は勧めています。
同じ名前の2種類：チェックとコミットのステータスが同じ名前で、その名前が必須なら、両方が合格する必要があります。
マージのコミットか head か：試しのマージのコミットにステータスがあれば、合格すべきはそちらです（「Showing checks for the merge commit」）。無ければ head のコミットです。
最新であること：規則がブランチを最新にするよう求めているなら、先に base のブランチをマージかリベースで取り込みます（ブランチの更新が断られる理由）。

直す所

飛ばされるワークフロー：絞り込みで飛ばされうるワークフローを必須にしません。条件で飛ばされたジョブは Success と報告するので、ワークフローの絞り込みでなくジョブの条件にすれば、チェックは報告され続けます。
イベント：ワークフローを pull_request で起動します（マージキューなら merge_group も）。
名前とアプリ：ブランチの保護の規則かルールセットで、必須の名前をチェックが報告する名前に、必須のアプリを実際に付けるアプリに合わせます。
フォーク：変更（とくに .github/workflows/ 以下）を見てから、ワークフローの実行を承認します。
ブランチへ直接 push する：必須のチェックが合格する前に保護されたブランチへ push すると、GH006: Protected branch update failed と「Required status check "NAME" is failing」（必須のチェック NAME が失敗しています）で断られます。
管理者：ブランチの保護の規則の制限は、既定では管理者の権限を持つ人と「bypass branch protections」の権限を持つ役割には掛かりません。マージできる人と待たされる人がいるのはそのためです。

IntelliJ IDEA の「All required checks have passed」「Checks in progress…」「Checks failed」

IntelliJ IDEA に入っている GitHub のプルリクの機能は、プルリクの状態にチェックの行を1つ出し、Details… のリンクでチェックの一覧を開いて、1つをブラウザで開けます。ソース（2026年10月30日に確認）では、この行はプルリクの最後のコミットにあるチェック（コミットのステータスと check runs の両方）から決まり、それぞれが必須かどうかは GitHub の isRequired（このプルリクをマージする前に通る必要があるか）で読みます：

「All required checks have passed」（必須のチェックは全部通った）は、必須のチェックが全部成功したときに出ます。必須でないチェックは数えないので、必須が1つも無いときも、ほかのチェックがどうなっていても、この文になります。
そうでないときは、走っているチェックが1つ以上あり、失敗したチェックも1つ以上あれば「Checks in progress, and some already failed…」、走っているチェックがあり失敗が無ければ「Checks in progress…」、それ以外はすべて「Checks failed」です。
失敗として数える物：状態が error・failure・expected のコミットのステータスと、結果が failure・cancelled・timed_out・stale・action_required・startup_failure・neutral の check run。結果が skipped の check run は、通ったとも失敗したとも数えず、スキップとして数えます。そのため、必須のチェックが neutral か skipped で終わると、走っているチェックが無いときは行が「Checks failed」のままになります。GitHub は、必須のチェックではどちらも通ったと数えます（GitHub の説明「About protected branches」）。
コミットに何も無い必須のチェックは、この行が数えるチェックに入りません。そのため、GitHub がそのチェックを「Expected — Waiting for status to be reported」と出してマージを止めている間も、行は「All required checks have passed」になることがあります。最後のコミットにチェックが1つも無いときは、行は出ません。

ソース：GHPRMergeabilityStateBuilder.kt・CodeReviewDetailsStatusComponentFactory.kt・CollaborationToolsBundle.properties。下のプラグインは、結果が neutral か skipped の check run を失敗でなく「スキップ」と出し、まだ報告していない必須のチェックを1つずつ名前で出します。

IntelliJ IDEA で GitHub のプルリクを見るなら

Lesstep の Pull Request Inbox for GitHub は、JetBrains IDE（2024.1 以降）のプラグインです。head のコミットのチェックを、コミットのステータスと check runs の両方とも、リンクつきで一覧にします。GitHub がプルリクを blocked と言うときは、マージの確認に「対象のブランチのルールをまだ満たしていない（必須のレビューか、必須のチェック）」と出します。head のコミットでまだ報告していない必須のチェックは、対象のブランチの保護とルールセットから名前を読み、そこに「必須のチェック「名前」が、このコミットでまだ報告されていません」と1つずつ出します（トークンにコミットのチェックが全部は見せてもらえない時は出しません）。Fine-grained のトークンには check runs が見せてもらえません（チェックが出ない理由）。受信箱・差分・会話は無料、承認・コメント・マージは Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。

GitHub は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。