3行まとめ
public previewから一般提供へ移り、GitHub TeamとGitHub Enterprise Cloudで有料製品として扱います。
アクティブコミッター、AI-powered capabilities、CodeQL解析に使うActions minutesを分けて見ます。
組織一括有効化の前に、対象リポジトリ、Rulesets、coverage、例外手順を決めます。
preview中の前提をそのまま延長せず、費用、対象、品質ゲートを分けて確認することが重要です。
- GitHub Code Qualityは、2026年7月20日にpublic previewから一般提供へ移り、有料製品になります。対象はGitHub TeamとGitHub Enterprise Cloudで、GitHub Enterprise Serverは対象外です。
- 料金は、Code Qualityを有効にしたリポジトリのアクティブコミッター1人あたり月10ドルを土台に、AI-powered capabilitiesの使用量、CodeQL解析に使うGitHub Actions minutesを分けて見ます。
- 同じ6月16日に組織一括有効化もpublic previewとして案内されました。全リポジトリへ一気に広げる前に、対象範囲、Rulesetsの品質ゲート、coverage、例外手順を決めるのが先です。
GitHub Code Qualityの一般提供予定が、2026年6月16日のGitHub Changelogで告知されました。表向きは「previewからGAへ」という短いニュースですが、GitHub TeamやGitHub Enterprise Cloudを使う組織では、7月20日までに現場でそのまま効く判断が必要になります。
特に見るべきなのは、機能そのものより運用の境界です。どのリポジトリで有効にするのか。誰がアクティブコミッターとして数えられるのか。Copilot code reviewやCopilot AutofixのようなAI処理はどの費用に寄るのか。CodeQLの決定的解析はActions minutesとしてどれだけ走るのか。ここが曖昧なまま組織一括有効化を使うと、品質管理が進む前に請求とPRブロックの混乱が来ます。
この記事では、2026年6月17日JST時点で確認できるGitHub公式のChangelogとDocsをもとに、7月20日前に管理者が決めるべき点を整理します。Microsoft Watch JapanはMicrosoftおよびGitHubとは非提携の独立サイトであり、本文は導入判断の整理であって、契約や購入を勧めるものではありません。
7月20日に何が変わるのか
- preview期間
Code Qualityそのものは試せますが、スキャンに使うGitHub Actions minutesは消費します。
- 2026年7月20日
public previewからgeneral availabilityへ移り、purchasable productとして扱われます。
- 対象プラン
利用対象はGitHub TeamとGitHub Enterprise Cloudで、GitHub Enterprise Serverは対象外です。
- 運用機能
organization-wide deployment、organization dashboard、rulesets、coverage summaryを導入範囲と合わせて見ます。
今回のGAはGitHub Enterprise CloudとTeamの話として、GitHub Enterprise Serverの更新とは分けて確認します。
最初に押さえるべき変更は、GitHub Code Qualityが「試せるpreview機能」から「購入対象の製品」へ移る点です。GitHubの告知では、2026年7月20日にpublic previewからgeneral availabilityへ移行し、purchasable productになると説明されています。
この日付は、単なるマーケティング上の節目ではありません。GitHub Docsのbillingページでも、一般提供になる7月20日から利用に料金が発生すると整理されています。preview中に試していた組織は、7月20日前に「継続するリポジトリ」と「止めるリポジトリ」を分けておく必要があります。
public previewから有料の一般提供へ移る
GitHub Code Qualityは、pull requestやdefault branchのスキャンを通じて、maintainabilityやreliabilityに関する問題を見つける機能です。GitHub Docsでは、CodeQLによるrule-based analysis、AI-powered analysis、Copilot-powered autofix、repository dashboard、organization dashboard、rulesetsとの連携、coverage summaryなどが説明されています。
preview期間中は、Code Qualityそのものの課金は発生しない一方で、スキャンに使うGitHub Actions minutesは消費されます。7月20日以降は、この状態が変わります。料金の扱いは後述しますが、少なくとも「previewなので無料のまま広げてよい」という前提は、7月20日で終わると考えるべきです。
確認する日付
管理者がまず残すべき日付は、Changelogの告知日である2026年6月16日、確認日である2026年6月17日JST、一般提供予定日の2026年7月20日です。previewの試用判断とGA後の課金判断を混ぜないよう、会議資料や棚卸し表にもこの3点を分けて書くと安全です。
対象はTeamとEnterprise Cloudに限る
対象プランも見落とせません。GitHub ChangelogとDocsでは、GitHub Code QualityはGitHub TeamとGitHub Enterprise Cloudで利用できると示されています。GitHub Enterprise Serverは対象外です。
この点は、GitHub Enterprise Server 3.21の一般提供を追っている管理者ほど混同しやすいところです。GHES側ではREST APIやActions runner、OpenTelemetryなどの更新がありますが、今回のCode Quality GAはGitHub Enterprise CloudとTeamの話です。GHES管理者は、<a href="https://msft-watch.blog.mo-gmo.com/msft-53-github-enterprise-server-3-21-ga-rest-api-actions-runner-opentelemetry/">GitHub Enterprise Server 3.21の記事</a>で追うべき変更と分けて読む必要があります。
新機能は組織展開と品質ゲートに寄っている
GA予告で目立つのは、個別リポジトリのスキャンだけではありません。GitHubは、organization-wide deployment、organization-level quality dashboards、rulesetsによるcode coverage enforcement、repositoryおよびorganization-level quality scoring、enablementやfindings management向けAPIを挙げています。
つまり、GitHub Code Qualityは「PRにコメントが出る便利機能」から、組織全体で品質基準を管理する製品に寄っています。技術的負債を見える化したいチームには前進です。ただし、組織単位の品質スコアやRulesetsは、設定を誤ると全社のpull requestを止める力も持ちます。先にルールを作るのではなく、まず実行結果が安定しているかを見ます。
料金は3種類に分けて見る
請求見積もりはリポジトリ数だけでは決まりません。誰がpushしているか、どのAI機能を使うか、解析がどれだけ走るかを分けて確認します。
7月20日以降のCode Qualityは、1つの単純な月額だけで読むと危険です。GitHub Changelogでは、Code Qualityの料金をbase subscriptionとmetered usageに分けています。Docs側では、GA後の費用をGitHub Actions minutes、GitHub AI Credits、active committersの3種類として説明しています。
管理者が見るべき順番は、まずアクティブコミッターの人数、次にAIを使う処理、最後にActions minutesです。これを分けると、請求の見積もりと導入範囲の議論がかなり現実的になります。
アクティブコミッターは月10ドルの基礎料金になる
GitHub Changelogでは、Code Qualityを有効にしたリポジトリのactive committer 1人あたり月10ドルと説明されています。ここでいうactive committerは、単にGitHub組織に所属している全員ではありません。GitHub Docsのbilling説明では、Code Qualityが有効なリポジトリに対して、直近90日以内にpushされたcommitをもつuniqueなactive committerが測定対象になります。
確認すべき点は、人数だけではありません。GitHub TeamまたはEnterpriseのライセンスを持つ組織メンバー、Enterprise Managed User、external collaborator、pending invitationの扱いを見ます。複数リポジトリや複数organizationにまたがる場合でも、同じ利用者が重複して数えられないよう、組織またはenterprise全体で測定されると説明されています。GitHub App botは除外されます。
この定義を踏まえると、費用見積もりは「有効化するリポジトリ数」だけでは出ません。直近90日以内に誰がpushしているか、外部協力者がどこに関わっているか、旧リポジトリに最近の修正commitが入っているかを確認します。
見積もりで外さない対象
費用担当に渡す人数は、正社員の開発者数だけで作らないほうがよいでしょう。external collaboratorやpending invitationがCode Quality有効リポジトリに関わっている場合、実際の測定対象に入る可能性があるため、リポジトリ別の直近90日pushと合わせて確認します。
AI CreditsはAI-powered capabilitiesだけに紐づける
AI-powered capabilitiesは、別の費用層として扱います。GitHub Changelogでは、Copilot code review、AI-assisted detection、Copilot Autofixなどがusage-based billingの対象例として挙げられています。Docsのbillingページでは、Code QualityのAIモデル利用はGitHub AI Creditsを消費し、1 AI creditは0.01ドルとして説明されています。
Code QualityのすべてがAI Creditsを消費するわけではありません。CodeQLによる決定的解析と、AI-powered analysisやCopilot Autofixは分けて見ます。Copilot code reviewをすでに使っている組織では、<a href="https://msft-watch.blog.mo-gmo.com/msft-50-github-copilot-code-review-org-runner-content-exclusion-custom-instructions/">Copilot code reviewの組織単位runner設定やcontent exclusionの記事</a>で整理した管理者設定ともつながります。
もう1つの注意点は、Code Quality側のAI分析ではモデル切り替えがサポートされないとDocsに書かれていることです。通常のCopilot model pickerの感覚で、「安いモデルへ切り替える」「別モデルで結果を比較する」といった運用を前提にしないほうがよいでしょう。
CodeQLの決定的解析はActions minutesを見る
Code Qualityのrule-based analysisは、CodeQLを使います。この解析はGitHub Actions workflowとして走るため、GitHub Actions minutesを消費します。preview期間中も、Code Qualityそのものの課金はなくてもActions minutesは消費されるとDocsに明記されています。
GA後も、この費用層は別に残ります。GitHub-hosted runnerで実行するならActions minutesを見ます。self-hosted runnerを使う場合は、runner側の運用コストと可用性を見ます。GitHub Actionsでは、self-hosted runnerの最低バージョン適用も別途進んでいるため、<a href="https://msft-watch.blog.mo-gmo.com/msft-49-github-actions-self-hosted-runner-minimum-version-enforcement/">self-hosted runner最低バージョン適用の記事</a>と合わせて確認しておくと、Code Qualityの解析基盤をどこで走らせるかを決めやすくなります。
費用担当に渡すなら、見積もり表は3行に分けるのが実務的です。アクティブコミッターの基礎料金、AI Credits、Actions minutes。この3つを混ぜると、どの設定変更で費用が下がるのかが見えなくなります。
組織一括有効化は便利だが、まず範囲を区切る
この分類は品質の高低ではなく、Code Qualityを安定して運用できる準備度を分けるためのものです。
GitHubは同じ6月16日に、Organization-level enablement for GitHub Code Qualityも案内しました。組織管理者が各リポジトリを個別に設定しなくても、organization settingsから一括でCode Qualityを有効化または無効化できるという内容です。
これは大規模組織には便利です。とはいえ、便利さと安全さは別です。7月20日に有料化が控えている機能を全既存リポジトリへ一括で広げる場合、費用、Actions実行量、PRブロック、対応言語、coverageの準備状況をまとめて背負うことになります。
Security配下のCode qualityで一括オンオフできる
GitHub Changelogによると、organization settingsのSecurity配下に新しいCode qualityセクションが用意され、全既存リポジトリに対して一括でオンまたはオフにできます。この組織一括有効化機能は、確認時点ではpublic previewです。対象はGitHub Enterprise CloudとGitHub Teamで、ここでもGitHub Enterprise Serverは対象外です。
この設定は、組織管理者にとってかなり強い操作です。リポジトリごとに手で有効化する負担を下げる一方で、意図しないリポジトリへもCode Qualityが入ります。特に外部協力者が多いリポジトリ、Actions minutesの余力が少ないリポジトリ、legacy codeが多く初回スキャンで大量のfindingが出そうなリポジトリは、先に分類しておきたいところです。
一括操作前の条件
一括オンに進む前に、対象外にしたいリポジトリ、Actionsを使えないリポジトリ、費用説明が未完了のリポジトリを先に洗い出します。一括オフも同じで、止める理由と再評価日を残しておかないと、あとから品質管理の空白になりやすくなります。
全リポジトリではなく、3群に分ける
有効化候補は、まず3群に分けると扱いやすくなります。
| 区分 | 代表例 | 7月20日前の判断 |
|---|---|---|
| 先行導入 | 開発頻度が高く、CodeQL対象言語で、Actions運用が安定しているリポジトリ | 継続候補。PRコメント、default branch scan、Actions消費、coverageの表示を確認する |
| 検証継続 | CodeQL対象言語だが、legacy領域や外部協力者が多いリポジトリ | 一括有効化ではなく、対象を絞って結果を見てから広げる |
| 保留または無効化 | ほぼ保守停止、Actionsを使えない、対象言語が薄い、費用対効果を説明しにくいリポジトリ | 7月20日前に無効化候補として扱う |
この分類は、品質の高低を決めるものではありません。Code Qualityの導入準備度を分けるためのものです。古い重要システムほど、いきなりPRブロックを入れるより、findingの棚卸しと例外ルールの設計から始めたほうが安定します。
無効化も期限つきの判断として扱う
Code Qualityを止める判断は、後ろ向きな判断とは限りません。7月20日前に、費用と運用範囲が説明できないリポジトリをいったん無効化するのは、むしろ管理された導入です。
ただし、無効化したまま忘れると、品質管理の対象から外れ続けます。保留リポジトリには、次に見直す日付、必要な準備、担当者を残しておきます。たとえば、coverageをCobertura XMLで出せるようにする、Actions runnerを整える、CodeQL対象言語のスキャン結果を確認する、といった条件です。
Rulesetsで品質ゲートを作る前に確認する
- 1workflow成功
最近のpull requestでCodeQL – Code Qualityが成功し、botコメントとdashboardに意味のある結果が出ているか確認します。
- 2指標を分ける
maintainability、reliability、coverageを同じ品質としてまとめず、それぞれ別の観点として見ます。
- 3閾値を段階化
既存負債を一度に止めるのではなく、まず新しい悪化を止めるところから始めます。
- 4例外手順
hotfix、release branch、生成コード、legacy moduleなどで誰がbypassできるか、記録をどこに残すかを決めます。
品質ゲートはチームを助ける仕組みです。blockingを有効にする前に、成功条件、閾値、例外の扱いをそろえます。
GitHub Code Qualityの価値は、単にfindingを表示するだけではありません。Rulesetsと組み合わせることで、maintainability、reliability、coverageの基準を満たさないpull requestをmergeできないようにできます。
これは強力ですが、導入順序を間違えると危険です。品質ゲートはチームを助けるための仕組みであり、壊れた設定でPRを止めるためのものではありません。
まずCode Quality workflowの成功を確認する
GitHub DocsのRulesets関連手順では、Code Qualityのthresholdをrulesetに入れる前に、Code Quality workflowがpull requestで正常に走り、結果を返していることを確認する流れになっています。ここを飛ばすと、ルールだけが先に有効になり、mergeできないpull requestが出る可能性があります。
最初に見るのは、最近のpull requestです。Checks欄でCodeQL – Code Qualityが成功しているか。github-code-quality[bot]のコメントが意味のある形で出ているか。default branchのCode qualityページにstandard findingsとAI findingsが分かれて表示されているか。coverage summaryを使うなら、coverage reportのアップロードが安定しているか。ここまでを確認してから、blockingに進みます。
ブロック前の最低条件
blockingに進めるのは、少なくとも最近のpull requestでworkflowが成功し、findingの意味を担当者が説明でき、例外時のbypass権限が決まっている状態です。結果が出ているだけで、まだ誰も読めていない段階なら、Rulesetsは警告運用にとどめるほうが安全です。
maintainability、reliability、coverageを分けて閾値化する
Code Qualityで扱う指標は、同じ「品質」でも中身が違います。GitHub Docsのmetrics referenceでは、reliabilityは意図した機能を正しく、予測可能に、安定して実行する観点、maintainabilityは理解、変更、拡張のしやすさの観点として説明されています。coverageは、テストがどの範囲を通っているかを示す別の指標です。
この3つを一度に厳しくすると、チームは何を直せばよいのか分からなくなります。最初は、新しい悪化を止めるところから始めるのが現実的です。既存の大きな負債を一気にmerge条件へ入れるのではなく、既存findingは改善計画へ分け、新規PRでは一定以上の悪化を防ぐ導入が向いています。
coverageについても、先にCobertura XMLの生成とアップロードが安定しているかを見ます。GitHub Docsでは、Pythonのpytest-cov、JavaのJaCoCo、JavaScript/TypeScriptのIstanbulやnyc、RubyのSimpleCov、Goのgocover-coberturaなど、Cobertura XMLを出す例が示されています。言語やテスト基盤により準備が必要です。
ブロック前に例外と解除手順を決める
Rulesetsでblockingを始める前に、例外と解除手順を決めておきます。hotfix、release branch、生成コード、legacy module、外部依存の都合でcoverageが出せない領域、緊急障害対応などは、現実の運用で必ず出ます。
例外をなくすことが目的ではありません。誰がbypassできるのか、どの条件なら許可するのか、記録をどこに残すのかを決めます。Code Qualityの品質ゲートは、CODEOWNERS、branch protection、CodeQL security alerts、secret scanningを置き換えるものではありません。それぞれ別の層として見ます。
GA前のチェックリストを管理者向けにまとめる
同じCode Qualityでも、費用、基盤、開発、セキュリティで判断材料は違います。役割ごとに確認項目を分けると見落としを減らせます。
7月20日までにやることは、機能を試すことだけではありません。費用、対象、PR運用、例外手順、更新追跡を分けて決めます。次の表を、管理者と費用担当の会話の起点にすると見落としを減らせます。
| 担当 | 確認項目 | 見る場所 | 完了条件 |
|---|---|---|---|
| Organization管理者 | Code Qualityを有効にするリポジトリ範囲 | Organization settings、repository settings | 先行導入、検証継続、保留の3群に分けた |
| 費用担当 | アクティブコミッター数 | Billing and licensing、usage report、repository contributor状況 | 直近90日のpushと外部協力者を含めて見積もった |
| Platform管理者 | Actions minutesとrunner | Actions usage report、runner設定 | CodeQL解析の実行先と余力を確認した |
| 開発リード | PRコメントとfindingの妥当性 | 最近のpull request、Code quality dashboard | 誤検知、対応不能finding、修正優先度を見た |
| QAまたは開発チーム | coverage | CI workflow、Cobertura XML、PR summary | coverage reportが安定してアップロードされる |
| セキュリティ/開発基盤 | Rulesetsと例外 | Rulesets、branch protection、CODEOWNERS | blocking前にbypass権限と記録方法を決めた |
費用担当と管理者で見る項目を分ける
費用担当には、アクティブコミッター、AI Credits、Actions minutesの3層を分けて渡します。開発基盤チームには、workflowの成功率、runner、CodeQL対象言語、coverage、Rulesetsの影響範囲を渡します。開発チームには、findingが実際の修正につながるか、Autofixの提案が使えるか、PRレビューの負荷がどう変わるかを確認してもらいます。
同じCode Qualityでも、見る人によって判断材料が違います。全員に同じ機能説明を配るより、役割ごとの確認リストにしたほうが早く進みます。
7月20日前に残す判断をする
preview中にすでに使っている組織は、7月20日前に残す判断をします。先行導入リポジトリで、pull requestコメント、default branch scan、Actions minutes、AI findings、Copilot Autofix、coverage summary、Rulesetsの警告運用まで確認できているなら、継続候補にできます。
一方で、初回スキャンだけで大量のfindingが出て、担当者も修正方針も決まっていないリポジトリは、いったん保留にしてよいでしょう。Code Qualityは、オンにしただけで品質が上がる機能ではありません。結果を読み、修正し、例外を管理する人がいて初めて効きます。
公開後に更新すべき情報を残す
7月20日以降は、Docsやbilling説明が更新される可能性があります。特に確認したいのは、価格ページとの整合、AI Creditsの説明、active committerの測定、API、organization-level enablementのpreview終了有無、GitHub Enterprise Server対応の有無です。
再確認するタイミング
再確認日は、7月20日の直前、GA当日、初回請求サイクル後の3回に分けると現実的です。Docsの文言だけでなく、実際のusage report、Actions実行量、AI Creditsの消費、Rulesetsで止まったpull requestの有無を合わせて見ます。
月次で追うなら、<a href="https://msft-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月の重要トピックまとめ</a>に、7月20日前後の再確認項目として残しておくと便利です。Microsoft Watch Japanでも、GitHub ChangelogとDocsの更新は継続して追います。
次に読むなら
GitHub Changelog、Microsoft 365 Copilot、Windows、Azure、GitHub Copilotの更新をまとめて追う場合は、<a href="https://msft-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>でも新着確認メモを配信しています。製品の提供条件やDocsの変更は後から効いてくることが多いので、GA日付の前後だけでも追跡しておくと判断しやすくなります。
参照した主な情報源
- GitHub Changelog「GitHub Code Quality generally available July 20, 2026」
GitHub Code Quality generally available July 20, 2026
- GitHub Changelog「Organization-level enablement for GitHub Code Quality」
Organization-level enablement for GitHub Code Quality
- GitHub Docs「About GitHub Code Quality」
https://docs.github.com/en/code-security/concepts/about-code-quality
- GitHub Docs「GitHub Code Quality billing」
https://docs.github.com/en/billing/concepts/product-billing/github-code-quality
- GitHub Docs「Enabling GitHub Code Quality」
https://docs.github.com/en/code-security/how-tos/maintain-quality-code/enable-code-quality
- GitHub Docs「Setting code quality thresholds for pull requests」
https://docs.github.com/en/code-security/how-tos/maintain-quality-code/set-pr-thresholds
- GitHub Docs「Setting up code coverage for your repository」
https://docs.github.com/en/code-security/how-tos/maintain-quality-code/set-up-code-coverage
- GitHub Docs「Metrics and ratings reference」
https://docs.github.com/en/code-security/reference/code-quality/metrics-and-ratings
更新履歴
- 2026年6月17日JST
GitHub ChangelogとGitHub Docsを確認し、一般提供日、対象プラン、料金の3層、組織一括有効化、Rulesets、coverageの確認点を整理しました。
GitHub DocsやChangelogは更新されるため、運用判断では確認日も一緒に残します。
- 2026年6月17日JST: GitHub ChangelogとGitHub Docsを確認し、一般提供日、対象プラン、料金の3層、組織一括有効化、Rulesets、coverageの確認点を整理しました。