GitHub・プルリク・コード品質・2026年10月26日に確認

GitHub：マージがコード品質の結果を待っている

ブランチのルールセットは、コード品質の結果を求められます（「Require code quality results」）。リポジトリに GitHub Code Quality が設定されていると、そのブランチへのプルリクは、解析がまだ終わっていない間、解析が何かの理由で失敗した時（たとえば Actions の分数の予算を使い切った）、または Code Quality がルールセットの決めた重大度かそれより重い結果を見つけている間はマージされません（GitHub の説明「ルールセットで使える規則」と「プルリクのコード品質の水準を決める」）。従来のブランチの保護にはこの設定が無く、ルールセットの規則 code_quality です（2026年10月26日に確認）。

GET /repos/OWNER/REPO/rules/branches/BRANCH
[{ "type": "code_quality", "parameters": { "severity": "warnings" } }]

規則が確かめること

重大度は1つ：ルールセットの「Severity」は、プルリクをマージする前に解決しなければならないコード品質の結果の、いちばん軽い重大度です。「Errors」は未解決のエラー、「Warnings and higher」は未解決の警告かエラー、「Notes and higher」は未解決のメモ・警告・エラー、「All」は未解決のコード品質の結果すべてでマージを止めます。REST API では severity（errors・warnings・notes・all）で、この規則があると、変更をマージする前にプルリクでコード品質の解析が済んでいなければなりません（GitHub の説明「ルールの REST API」）。
ラベル：指摘には、どれも重大度のラベルが付きます。Error は、バグや失敗、保守の大きな危険を招きそうな重い問題です。Warning は、品質や信頼性に響くかもしれないが、すぐに致命的ではない中くらいの問題です。Note は、軽い問題・小さな改善・おすすめです（GitHub の説明「コード品質の問題を既定のブランチに入れない」）。
解析するもの：プルリクでは、Code Quality は CodeQL の規則による指摘だけを出します。対象は C#・Go・Java・JavaScript・Python・Ruby・TypeScript です。AI による指摘は水準にできず、水準が効くのは、リポジトリに対象の言語のコードがある時だけです（GitHub の説明「GitHub Code Quality」）。
カバレッジは別の規則：行のカバレッジの下限や、カバレッジが下がる幅の上限は、「Restrict code coverage」という別の規則で、「Require code quality results」ではありません。
まず評価だけ：GitHub は、水準を合わせる間は実施の状態を「Evaluate」にするよう勧めています。その間は、どのプルリクが止まったはずかをルールセットの分析で見られ、「Active」にすると実施されます。「Get rules for a branch」は、ブランチに当てはまる有効な規則を、どの階層で設定されたものでも全部返します。評価だけのルールセットや無効のルールセットの規則は返しません。

プルリクのどこに出るか

表示：変更が求められる水準に届かないと、プルリクの下の「Checks」のところに「Merging is blocked: Code quality findings were detected.」（マージは止められています：コード品質の指摘が見つかりました）と出ます。この表示が重大度を挙げていなければ、そのリポジトリはすべての指摘への対応を求めています（GitHub の説明「プルリクの止まりを解く」）。
チェック：解析は「Checks」のところに「CodeQL - Code Quality / Analyze」のチェックとして出ます。失敗は、ワークフローが走れなかったということで、たとえば Actions の分数の予算を使い切った時です（GitHub の説明「Code Quality の CodeQL による解析」）。
指摘：Files changed のタブにある github-code-quality[bot] のコメントです。どれにも重大度のラベルと、提案された自動の修正が付きます。
ワークフロー：Actions のタブでは、Code Quality とコードスキャンの実行はどちらもワークフローの名前が CodeQL です。Code Quality の実行は、実行者が github-code-quality か、「Code Quality: push on main」のような実行の名前で見分けます。

直す所

止める重大度の指摘：その重大度かそれより重い指摘を、全部直すか却下します。Files changed のタブで「Commit suggestion」（または「Add suggestion to batch」）を押すと自動の修正を当てられ、当てはまらない指摘は理由を添えて「Dismiss finding」で却下します。却下した指摘があってもマージはできますが、その指摘はリポジトリの残りの一覧と、これからのプルリクに出ます。表示が消えなければ、止める重大度以上の指摘がまだ残っています。
解析が終わっていない・失敗した：Code Quality のチェックが終わるのを待ちます。失敗していたら、Actions のタブでそのワークフローの実行のログを開きます。プルリクにワークフローの結果が届かないまま結果を求めるルールセットは、すべてのプルリクのマージを止めることがあります。
Code Quality のコメントが無い：スキャンがまだ走っているか、変更が対象の言語に触れていないか、指摘が無いかです。
カバレッジの文が出ている：「Line coverage 22.0% is below minimum 50.0%」（行のカバレッジ 22.0% が下限の 50.0% を下回っている）や「Line coverage decreased by 2.5%, maximum allowed drop is 1.0%」（行のカバレッジが 2.5% 下がった。許される幅は 1.0%）は、カバレッジの規則です（コードのカバレッジの水準がマージを止める）。テストを足すか直して push すると、カバレッジのチェックが走り直します。

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

Lesstep の Pull Request Inbox for GitHub は、JetBrains IDE（2024.1 以降）のプラグインです。プルリクのレビュー・チェック・会話を差分の隣に出し、対象のブランチが許す方法でマージします。GitHub がプルリクを blocked と言うときは、マージの確認に読める物を名指しします（報告の無い必須チェック・まだ要るレビュー・ルールが止めている未解決の会話と署名の無いコミット・最後の push のルール・ルールセットが求めるコードスキャンのツール）。チェックの一覧には、Code Quality のチェックもほかと並んで出ます。ブランチのルールセットがコード品質の結果を求めているなら、止まっているプルリクのマージの確認にそう出し、直すか却下しなければならない指摘の重大度を出します。受信箱・差分・会話は無料、承認・コメント・解決・マージは Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。

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