GitHub Code Qualityは、プルリクエストと既定ブランチのコードを検査し、保守性と信頼性の問題をCopilotの修正案付きで指摘するGitHubの有料機能です。2025年10月にパブリックプレビューとして公開され、2026年7月20日に一般提供(GA)へ移行しました。GAと同時に課金が始まり、非公開リポジトリのライセンス料金はアクティブコミッター1人あたり月10ドルです(公開リポジトリはコミッター料金0ドルで、AI機能の従量課金のみ)。この記事では、料金の3つの内訳、CodeQLが対応する7言語と言語ごとのルール数の差、PHPなど非対応言語での使いどころ、有効化からマージ停止・カバレッジ計測までの設定を、GitHub公式ドキュメントの記述に沿って整理します。
まとめ:GitHub Code Qualityの要点
- 料金:非公開リポジトリのライセンスはアクティブコミッター1人あたり月10ドル(公開リポジトリは0ドル)。これに、GitHubホストランナーで動かした場合のActions分と、AI機能が消費するAIクレジット(1クレジット=0.01ドル)が加わります。
- 対象プラン:GitHub TeamとGitHub Enterprise Cloudの組織リポジトリ。GitHub Enterprise Serverでは使えません。
- 対応言語:CodeQLのルール解析はC#・Go・Java・JavaScript・Python・Ruby・TypeScriptの7言語。ただしRubyのルールは3件しかありません。
- PHP:CodeQLのルール解析とプルリクエストでの指摘は対象外です。既定ブランチに最近マージされたファイルへのAI解析(既定はオフ)と、Cobertura XMLによるカバレッジ計測は言語を問いません。
- 導入順:少数のリポジトリで有効化し、ルールセットを評価(Evaluate)モードで1〜2週間回してから有効(Active)に切り替えるのが公式の推奨手順です。
以下、仕組み→料金→対応言語→設定→採用判断の順に説明します。
GitHub Code Qualityの仕組み:プルリクエストと既定ブランチの2系統
Code Qualityの検査は、プルリクエスト上と既定ブランチ上で中身が異なります。プルリクエストに付くのはCodeQLのルールで確定的に検出した指摘だけで、AIによる指摘は既定ブランチ側にしか出ません。この違いを押さえておくと、PHPの扱いや料金の内訳も理解しやすくなります。
プルリクエストでのCodeQL指摘とワークフロー
Code Qualityを有効化すると、プルリクエストごとにCodeQL解析がGitHub Actions上で走ります。YAMLを自分で書く必要はなく、GitHubが動的ワークフローとして実行します。Actionsタブでは実行者 github-code-quality、または「Code Quality: push on main」のような実行名で、Code Scanningの実行と区別できます。どちらもワークフロー名は同じ「CodeQL」なので、実行者か実行名で見分けます。
プルリクエストの「Checks」欄にはCodeQL - Code Quality / Analyzeが表示され、問題が見つかると github-code-quality[bot] が該当行にコメントを付けます。修正案を生成できた指摘にはCopilot Autofixの提案が付き、内容を確認してからコミットできます。すべての指摘に修正案が付くわけではありません。プルリクエストへのAIレビューが欲しい場合は、別機能のGitHub Copilotのコードレビューを有効にします。
既定ブランチのStandard findingsとAI findings
既定ブランチの結果は、リポジトリの「Security and quality」タブにある「Code quality」に2種類に分けて表示されます。
| 区分 | 検出方法 | 対象 | 提供段階 |
|---|---|---|---|
| Standard findings | CodeQLのルール | 既定ブランチ全体 | GA |
| AI findings | 大規模言語モデル | 最近マージされたファイル | パブリックプレビュー |
AI findingsは既定ではオフです。リポジトリのCode quality設定で有効にすると、既定ブランチにマージされた直近の変更ファイルを対象に、最大5ファイル・1ファイルあたり最大5件まで指摘を出します。言語の制限はありません。修正は1ファイルずつプルリクエストにできるほか、Copilotライセンスがあれば複数ファイルをまとめてCopilotのクラウドエージェントに任せられます。なお、AI findingsはルールセットの閾値には使えません。
保守性・信頼性スコアと重大度の判定基準
Standard findingsは「信頼性(Reliability)」と「保守性(Maintainability)」に分類されます。信頼性は性能・並行処理・エラー処理・正しさの問題、保守性は未使用コード・可読性・複雑さ・命名の衝突などです。スコアは既定ブランチ全体の結果のうち、最も重い指摘で決まります。
| スコア | 判定条件 |
|---|---|
| Excellent | 指摘なし |
| Good | Note が1件以上 |
| Fair | Warning が1件以上 |
| Poor | Error が1件以上 |
件数ではなく最も重い1件で決まるため、Error が1件でも残れば、ほかがきれいでも「Poor」になります。公式ドキュメントも、生成コードの多いリポジトリは保守性スコアが下がりやすいと注記しています。スコアは組織内で比べる目安にとどめ、個別の指摘を見て判断するのが現実的です。
CodeQLとは:Code ScanningとCode Qualityの共通エンジン
CodeQLは、ソースコードをデータベースに変換し、問題のあるパターンをクエリで検索するGitHubの静的解析エンジンです。脆弱性を探すCode Scanningと、保守性・信頼性を見るCode Qualityは、同じCodeQLで別のクエリ群を動かしています。セキュリティ用途の設定や対応言語はGitHub Code ScanningとCodeQLの設定手順で詳しく扱っています。
GitHub Code Qualityの料金:3つの請求項目と試算
GitHubの課金ドキュメントは、Code Qualityの費用を「Actions分」「AIクレジット」「アクティブコミッター数のライセンス」の3つに分けています。GA前の2026年7月13日には、請求画面でライセンス費用の見積もりを確認できる機能が先行公開されましたが、この見積もりはライセンス分だけで、Actions分とAIクレジットは含みません。
ライセンス:アクティブコミッター1人あたり月10ドル
Code Qualityは単独の製品として独自のライセンスを持ち、GitHub Advanced Securityのライセンスは消費しません。GitHubの製品ページによると、月10ドルがかかるのは非公開リポジトリで、公開リポジトリはコミッターあたりの料金が0ドル(AI機能は従量課金)です。以下の数え方と試算は非公開リポジトリを前提にしています。
- Code Qualityを有効にしたリポジトリへ、過去90日以内にコミットがプッシュされた人が1ライセンスを使う(コミットの作成日ではなくプッシュ日で判定)
- 複数のリポジトリや組織にコミットしていても、組織・エンタープライズ全体で1人1ライセンス
- メンバーだけでなく外部コラボレーターと招待中の人も含み、GitHub Appのボットは数えない
見落としやすいのは請求の基準です。請求期間中にライセンス数が最も多かった時点の数で請求されます。期間の途中で有効化を外しても当期の請求額は減らず、減るのは翌期からです。
従量課金:Actions分とAIクレジット
CodeQL解析はGitHub Actionsで動くため、GitHubホストランナーではActions分を消費しますが、実際の追加請求はリポジトリの公開範囲、ランナーの種類、プランに含まれる無料枠の残量によって変わります。セルフホストランナーを指定すればActions分はかかりません。詳細な使用量レポートでは、workflow_path が dynamic/github-code-quality/codeql の行がCode Qualityの消費分です。
Copilot Autofixの修正案生成とAI findingsは、組織共有のAIクレジットを消費します。1クレジットは0.01ドルで、トークン量に応じて課金されます。これらの利用にCopilotのライセンスは不要です。一方、指摘の修正をCopilotのクラウドエージェントに任せる場合はCopilotライセンスが要ります。AIモデルは切り替えられません。
20人チームで見積もる月額と見落としやすい上振れ
開発者20人が全員、有効化したリポジトリへ毎月プッシュする組織で試算します。
| 項目 | 金額 | 変動要因 |
|---|---|---|
| ライセンス | 20人×10ドル=月200ドル | 期間中の最大人数 |
| Actions分 | 従量 | PR数・リポジトリ規模 |
| AIクレジット | 従量 | Autofix・AI findingsの件数 |
ライセンスが上振れする典型は、業務委託者が一時的に参加するケースです。90日以内に1回でもプッシュすれば1人と数えられるため、短期の参加者が多い組織ほど頭数が増えます。組織単位で「すべてのリポジトリ」を有効にする前に、請求画面の「Licensing」で消費ライセンス数を確認しておくと想定外の請求を防げます。
CodeQLの料金とCode Scanning(GitHub Code Security)との違い
「CodeQLの料金」は、どの製品として使うかで変わります。Code Qualityとして動かすCodeQLの品質チェックは、上記の月10ドルのライセンスに含まれます。CodeQLで脆弱性を検出するCode Scanningは、別製品のGitHub Code Security(アクティブコミッター1人あたり月30ドル)の機能です。非公開リポジトリで両方を有効にする場合は、それぞれのライセンスが必要です。ただし、GitHub.comの公開リポジトリでは、CodeQLによるCode ScanningをGitHub Code Securityの有料ライセンスなしで利用できます。GitHub Advanced Securityの購入単位と課金の数え方はGitHub Advanced Securityの料金と課金の数え方にまとめています。
Code Qualityの対応7言語と検査ルール数の比較
CodeQLによるルール解析の対象は、C#・Go・Java・JavaScript・Python・Ruby・TypeScriptです(JavaScriptとTypeScriptは同じルール表)。ところが、GitHub Docsに掲載されている言語別のルール表を2026年9月29日時点で数えると、言語ごとの厚みには大きな差があります。
出典:GitHub Docs「CodeQL-powered analysis for Code Quality」から辿れる言語別クエリ表の行数を集計(JavaScriptとTypeScriptは共通表)。
| 言語 | ルール数 | 信頼性 | 保守性 |
|---|---|---|---|
| Python | 101 | 69 | 32 |
| JavaScript / TypeScript | 98 | 77 | 21 |
| Java | 89 | 57 | 32 |
| C# | 69 | 45 | 24 |
| Go | 22 | 20 | 2 |
| Ruby | 3 | 2 | 1 |
Rubyのルールは「ローカル変数への無意味な代入」「ループ内のデータベースクエリ」「未初期化の可能性があるローカル変数」の3件だけで、Rubyのルール解析で検査できる問題の種類はこれに限られます。指摘がなく「Excellent」と表示されても、ルールの対象外にある品質問題まで否定できるわけではありません。Goも保守性ルールは2件にとどまります。Rails中心の組織が品質ゲートの目的でCode Qualityを入れるなら、RuboCopなど既存のリンターを外さない前提で考えるべきです。
PHPなどCodeQL非対応言語で使える機能
PHPはCodeQLのルール解析の対象外で、プルリクエストでの指摘、Standard findings、スコア、品質の閾値によるマージ停止はいずれも働きません。PHPで使えるのは次の2つです。
- 既定ブランチにマージされたPHPファイルへのAI findings(パブリックプレビュー・設定でオンにした場合)
- Cobertura XMLを使ったラインカバレッジの表示とカバレッジ閾値(PHPUnitは
--coverage-coberturaで出力可能)
PHPのプルリクエストで保守性などのレビューが欲しい場合は、Copilotのコードレビューが候補です。セキュリティ上の指摘にはCode ScanningのAI Scanも使えますが、その指摘はマージを停止する条件にはできません。PHPプロジェクトに品質ゲートとしてCode Qualityを入れても、止められるのはカバレッジだけです。PHPStanやPHP_CodeSnifferをCIに残したうえで、AI findingsとカバレッジを上乗せする位置づけで検討してください。
GitHub Code Qualityの有効化手順
前提条件と対象外の環境
利用にはGitHub TeamかGitHub Enterprise Cloudの組織が必要で、個人アカウントやGitHub Enterprise Serverでは使えません。エンタープライズに属する組織は、先にエンタープライズオーナーがCode Qualityを許可しておく必要があります。解析はActionsで動くため、リポジトリでGitHub Actionsが有効になっていることも条件です。
リポジトリ単位での有効化
- リポジトリの「Settings」を開く
- サイドバーの「Security」にある「Code quality」を選ぶ
- 「Enable code quality」をクリックする
- 解析しない言語があればチェックを外し、ランナーを変える場合は「Labeled runner」でラベルを指定する
- 「Save changes」で保存する
組織がプライベートレジストリのキャッシュを設定していれば、依存関係の解決にそのまま使われます。
組織単位のRepository accessと強制
組織単位では「Repository access」で既定の対象を決めます。ただし、管理者が個別に有効化したリポジトリは、組織側で対象外にしても有効なまま残る場合があります。例外も含めて設定を強制するには「Enforce access」をオンにします。次の表は組織の既定設定の動作です。
| 選択肢 | 動作 | 新規リポジトリ |
|---|---|---|
| No repositories | すべて無効 | 無効 |
| Let repositories decide | 各管理者が判断 | 各管理者が判断 |
| All repositories | すべて有効 | 有効 |
| Selected repositories… | 選んだものだけ有効 | 有効にならない |
| Matching a filter… | 条件一致を有効 | 条件一致なら有効 |
フィルターは公開範囲・フォークか否か・カスタムプロパティをAND条件で組み合わせられます。「Enforce access」をオンにすると、リポジトリ管理者は有効・無効を変更できません。設定を変えると、有効化・無効化されるリポジトリ数と請求への影響が確認ダイアログに表示されます。REST APIにも GET /repos/{owner}/{repo}/code-quality/findings と PATCH /repos/{owner}/{repo}/code-quality/setup があり、指摘の取得と有効化をスクリプトで回せます。
品質ゲート:ルールセットでマージを止める設定
Require code quality resultsの重大度設定
ブランチのルールセットで「Require code quality results」を有効にすると、指定した重大度以上の指摘が未解決のプルリクエストをマージできなくなります。重大度は「Errors」「Warnings and higher」「Notes and higher」「All」から選びます。解析が実行中のときや、Actions分の予算切れなどで解析が失敗したときもマージは止まります。
組織ルールセットに同じルールを入れれば、複数リポジトリへ同じ基準をまとめて適用できます。ブロックされたプルリクエストは、該当する指摘を修正するか却下(dismiss)すれば解除されます。
全プルリクエストが止まる失敗パターンと回避策
公式ドキュメントが警告しているのは、Code Qualityのチェックが正常に動いていない状態でルールセットを有効にすることです。この状態だと、すべてのプルリクエストのマージが止まります。先に直近のプルリクエストでCodeQL - Code Quality のチェックが成功していることを確認し、ルールセットは「Evaluate」で作成してください。評価モードでは、ブロックされるはずだったプルリクエストがルールセットの履歴に記録されるだけで、実際には止まりません。公式は1〜2週間分のデータを見てから「Active」へ切り替える手順を勧めています。
もう一つの落とし穴はActions分の予算です。支出上限に達すると解析が失敗し、ルールセットがあればマージも止まります。組織全体へ一気に広げる前に、ランナーの容量と予算を確認しておくべきです。
コードカバレッジ:Cobertura XMLのアップロードと閾値
テストのラインカバレッジをプルリクエストに表示する機能は、2026年5月26日にパブリックプレビューとして公開され、GAの機能一覧にも含まれています。有効化しただけでは動かず、リポジトリごとにカバレッジをアップロードするワークフローを追加して初めて表示されます。対象はラインカバレッジだけで、ブランチカバレッジや関数カバレッジはレポートに含まれていても使われません。
ワークフローでの手動セットアップ(PHPUnitの例)
アップロードには actions/upload-code-coverage を使い、code-quality: write 権限を付けます。language にはLinguistの言語名を指定します。PHPUnitでCobertura XMLを出す例です。PHPUnitをComposerの開発依存に入れ、phpunit.xml でテストスイートとカバレッジ対象のソースディレクトリを設定済みのプロジェクトを前提とします。既定ブランチが main 以外なら branches を書き換えてください。
name: Code Coverage
on:
push:
branches: [main]
pull_request:
branches: [main]
permissions:
contents: read
code-quality: write
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
with:
ref: ${{ github.event.pull_request.head.sha || github.sha }}
- uses: shivammathur/setup-php@v2
with:
php-version: '8.4'
coverage: pcov
- run: composer install --no-interaction
- run: vendor/bin/phpunit --coverage-cobertura coverage.xml
- name: Upload coverage report
if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository
uses: actions/upload-code-coverage@v1
with:
file: coverage.xml
language: PHP
label: code-coverage/phpunit
既定ブランチへのpushで基準値を作り、プルリクエストでそれと比較するため、トリガーは両方必要です。checkout でプルリクエストのheadコミットを指定するのは、マージコミットだと行番号が差分と合わなくなるためです。フォークからのプルリクエストはアップロードを飛ばす条件にしています。完了すると github-code-quality[bot] が、既定ブランチとの比較とファイル別の増減をコメントします。Pythonなら pytest --cov=. --cov-report=xml、Goなら gocover-cobertura で同じXMLを作れます。
AIによる自動セットアップとカバレッジ閾値
設定画面の「Code coverage analysis」で「Generate workflow with AI」を選ぶと、エージェントがテストフレームワークを特定し、カバレッジ用のワークフローをプルリクエストとして作成します。追加費用はかかりません。テストが見つからない場合や、プライベートレジストリ・独自SDKが必要でビルドを再現できない場合は途中で止まります。JaCoCo XMLしか出せないJVMプロジェクトも手動設定が必要です。
ルールセットの「Restrict code coverage」(パブリックプレビュー)を使えば、最低ラインカバレッジ(例:50%未満で停止)と、既定ブランチからの低下幅(例:1ポイント超の低下で停止)の2つを閾値にできます。テストの網羅率の考え方はテストカバレッジの網羅率と目標設定、外部サービスで計測する場合はCodecovのGitHub Actions連携が比較の材料になります。
採用判断:Code Qualityが向く組織と見送るべき組織
Code Qualityが最も効くのは、Python・JavaScript/TypeScript・Java・C#が主体で、GitHub TeamかEnterprise Cloudをすでに使っている組織です。ルールはC#の69件からPythonの101件までそろっており、プルリクエストの指摘、組織ダッシュボード(Health・Trendsタブ)、ルールセットでのマージ停止、カバレッジ計測をGitHubの中だけで完結できます。外部の品質管理SaaSとカバレッジサービスを別契約している組織は、置き換えで費用と管理の手間を減らせる可能性があります。
見送るべきなのは次の3つです。
- RubyやPHPが主体で、既存リンターの置き換えが目的の組織:Rubyのルールは3件、PHPはルール解析の対象外で、既存の品質チェックを代替できない
- GitHub Enterprise Serverの組織:GA時点で提供されていない
- 業務委託者を含む90日間のアクティブコミッター数で試算した額が予算に合わない組織:対象リポジトリを絞っても合わなければ見送る
判断に迷う場合は、「Selected repositories」で1チーム分だけ有効化し、1〜2週間分のStandard findingsの件数と請求画面のライセンス数を見てから広げるのが安全です。無効化すると新しい解析と従量課金はすぐ止まり、過去の指摘やスコアは削除されずに残ります。品質指標や品質ゲートの一般論はコード品質の指標と品質ゲートで解説しています。
よくある質問
GitHub Code Qualityの料金はいくらですか?
非公開リポジトリはアクティブコミッター1人あたり月10ドルのライセンスに、GitHubホストランナーのActions分と、Copilot AutofixなどAI機能のAIクレジット(1クレジット0.01ドル)が加わります。公開リポジトリはコミッター料金が0ドルで、AI機能の従量課金だけです。ライセンスは期間中の最大数で請求されます。
CodeQLはPHPに対応していますか?
対応していません。Code QualityでもPHPはCodeQLのルール解析とプルリクエストでの指摘の対象外です。設定でオンにしたAI findings(既定ブランチにマージされたPHPファイルが対象)と、Cobertura XMLによるカバレッジ計測は使えます。
Code QualityとCode Scanningの違いは何ですか?
どちらもCodeQLを使いますが、Code Qualityは保守性と信頼性、Code Scanningはセキュリティ脆弱性を検出します。製品もライセンスも別で、Code ScanningはGitHub Code Security(1人月30ドル)の機能です。
個人アカウントやGitHub Enterprise Serverで使えますか?
使えません。対象はGitHub TeamとGitHub Enterprise Cloudの組織リポジトリで、GitHub Enterprise ServerはGA時点で提供対象外です。
GitHub Code QualityはいつGAになりましたか?
2026年7月20日です(GitHub Changelogの発表)。同日から課金も自動で始まりました。ただし、AI findings、バックログへのエージェント型Autofix、カバレッジ閾値のルールは、2026年9月時点でもパブリックプレビューです。