GitHub Code Qualityは、2026年7月20日にpublic previewから一般提供へ移り、無料で試せる便利機能から「GitHub Actions minutes」「GitHub AI Credits」「active committers」の3つを管理して使うプロダクトへ変わります。今やるべきことは、有効化済みリポジトリを洗い出し、どのリポジトリで品質ゲートをかけるか、誰が費用を見るか、self-hosted runnerに逃がすかを先に決めることです。特にTeamやEnterprise Cloudで複数リポジトリを抱える組織ほど、7月20日以降の請求前提で対象範囲を絞ってから有効化した方が安全です。
GitHub Code Qualityの結論: 7月20日までに対象範囲と費用監視を決める
GitHub Docsでは、Code Qualityはpull requestとdefault branchの両方でコード品質の問題を見つけ、Copilot-powered autofixやrulesets、coverage連携まで含めて品質運用を回す機能として説明されています。単なるlintの置き換えではなく、標準のCodeQL分析で見つけた問題をPR上のコメントやダッシュボードにまとめ、AI findingsでは最近default branchへpushされたファイルも別枠で見られるのが特徴です。つまり導入判断の軸は「解析できるか」よりも、「どのリポジトリで継続的に品質ゲートを運用したいか」にあります。
何が7月20日に変わる？ public preview終了で課金前提になる
公式DocsのEnableページとBillingページの両方で、GitHub Code Qualityは2026年7月20日にgenerally availableになると明記されています。preview期間中はprivate repositoryをscanしてもAI creditsやactive committer usageでは課金されませんが、Code Quality scansはGitHub Actions minutesを消費します。7月20日以降は追加料金が発生するため、もし費用を避けたいならその日までにCode Qualityをdisableする必要があります。つまり今週の実務は「まず試す」ではなく、「残す対象を決める」段階です。
課金は3本立て: Actions minutes・AI Credits・active committers
Billingページによると、GA後の費用は3種類あります。1つ目はGitHub Actions minutesで、Code Quality scanはworkflowとして動くため、GitHub-hosted runnerを使う限り分単位の消費が発生します。2つ目はGitHub AI Creditsで、Code QualityのAI機能は使用トークン量に応じて請求され、1 AI credit = 0.01 USDです。3つ目はactive committersで、Code Qualityを有効化したrepositoryへ過去90日以内にpushした一意のcommitter数がライセンス使用量になります。複数repositoryにまたがっても1人1ライセンスとして数える一方、不要なrepositoryで有効化したままだとunique committer分のムダが残ります。
導入前に確認したい前提条件
Code Qualityはorganization-owned repositories向けで、対象プランはGitHub TeamまたはGitHub Enterprise Cloudです。さらにenterprise配下ではenterprise ownerが利用を許可している必要があり、GitHub Actionsも有効化されていなければ動きません。CodeQLによるquality analysisの正式サポート言語はC#、Go、Java、JavaScript、Python、Ruby、TypeScriptです。加えてAI-powered analysisはrecent pushes to the default branchだけを対象にし、上記以外の言語でも問題を見つける場合があります。ここを誤解すると「全リポジトリを同じ深さで見てくれる」と期待しすぎるので注意が必要です。
有効化手順: enterprise許可→repository設定の順で進める
Enableページでは、repository単位では Settings → Security → Code quality から有効化し、必要なら言語チェックボックスを外し、runner typeをGitHub-hostedかlabeled runnerか選んで保存する流れです。organization単位ではSettings配下のCode qualityでトグルを切り替え、全repositoryへ一括適用できます。実務では、いきなりorganization全体で有効化するより、1. mainlineのPR量が多いrepositoryを選ぶ、2. self-hosted runnerを使うか決める、3. billing ownerがusage reportを見る、4. その後に横展開する、の順が失敗しにくいです。
どのリポジトリから始めるべき？ 向くケースと後回しにするケース
向いているのは、PRベースで開発していて、default branchの健全性を継続監視したいrepositoryです。たとえば複数人が触るWebアプリ、SDK、社内共通ライブラリのように、maintainabilityとreliabilityの劣化を早く拾いたいコードベースです。逆に後回しにしやすいのは、コミッターが頻繁に入れ替わる検証用repository、CodeQL非対応言語が中心のrepository、GitHub Actions minutesをこれ以上増やしたくない環境です。費用より品質を優先する基幹repositoryから始め、短命なPoCやsandboxは外す方がactive committerの膨張を抑えやすいでしょう。
運用開始後に見る場所: PRコメント・Standard findings・usage report
Quickstartによると、PRでは github-code-quality[bot] がrule-based problemをコメントし、可能ならCopilot Autofixで修正候補を出します。default branch側では Security and quality タブの Standard findings でReliabilityとMaintainabilityの評価、AI findingsで最近mergeされたコードの指摘を確認できます。加えてBillingページは dynamic/github-code-scanning/codeql workflow の消費をusage reportから追えると案内しています。つまり運用開始後は、開発チームがPRで修正、品質担当がdashboardで傾向確認、情シスや管理者がbillingで分単位とcommitter数を見る分業が現実的です。
注意点: Copilot契約の有無より運用設計の方が重要
Aboutページでは、Code QualityやCopilot-powered autofixを使うのにCopilot licenseやCode Security licenseは不要と明記されています。ここだけ見ると導入ハードルは低く見えますが、本当に難しいのは誰が findings を直すか、rulesetでどこまでblockするか、minutes増加をどう吸収するかです。GitHub-hosted runner前提のまま全repositoryへ広げると、preview中は見えにくかったコストが7月20日以降に一気に表面化する可能性があります。機能比較より先に「対象repository」「owner」「停止条件」を決めておく方が、後戻りの少ない導入になります。
まとめ: まず1〜3個の重要リポジトリで試し、7月20日前に残す対象を確定する
GitHub Code Qualityは、PRレビューとdefault branchの品質監視をひとつの画面にまとめられる点が魅力ですが、2026年7月20日以降は無料の実験機能ではありません。おすすめは、main repositoryを1〜3個選び、Actions minutesの増え方、AI Creditsの扱い、active committerの範囲を見た上で、本番適用するrepositoryだけを残す進め方です。関連記事として、CopilotのAI Credits移行やPremium Requests監査の記事もあわせて読むと、GitHub系コスト管理の全体像をつかみやすくなります。
GitHub Code Qualityをどのrepositoryまで有効化するべきか、Copilot課金や監査運用まで含めて整理したい場合は、 無料相談はこちら 。GitHub導入状況に合わせて、対象repositoryの絞り込みから費用監視の設計まで一緒に整理できます。
