GitHub Enterprise ServerでCode Qualityが見つからない理由|GHEC・Teamとの対応差

GitHub Enterprise Server(GHES)の管理画面で「Code Quality」が見つからない場合、原因は権限不足や設定ミスではありません。2026年7月20日の一般提供(GA)時点で、GitHub Code QualityはGitHub Enterprise Cloud(GHEC)とGitHub Teamのみを対象としており、GHESでは利用できないためです。

そのため、GHESを最新版へ更新したり、GitHub ActionsやGitHub Advanced Securityを有効にしたりしても、Code Qualityの設定項目は追加されません。現時点の対応は、対象リポジトリをGHECまたはGitHub Teamで運用するか、GHES上で既存の静的解析・テスト・品質ゲートを継続することです。(The GitHub Blog)

目次

GitHub Enterprise ServerでCode Qualityが見つからない理由

GitHubは、GitHub Code QualityのGA発表で、提供対象を「GitHub Enterprise Cloud」と「GitHub Team」としています。一方、GitHub Enterprise Serverについては「not available at launch」、つまりGA開始時点では利用できないと明記しています。(The GitHub Blog)

したがって、GHESでは次のような状態になります。

  • エンタープライズ管理画面にCode Qualityのポリシーが表示されない
  • Organizationの「Settings」にCode Qualityが表示されない
  • リポジトリの「Settings」→「Security」にCode qualityが表示されない
  • Code Qualityを有効化するボタンが見つからない
  • 管理者権限を付与しても設定できない

これは画面表示の不具合ではなく、製品の対応範囲による正常な動作です。

GitHub Teamで使えてGHESで使えないのはプランの上下関係が理由ではない

「Enterprise Serverの方が上位プランなのに、なぜGitHub Teamでは使えるのか」と疑問に感じるかもしれません。

ただし、今回の違いは契約プランの上下関係ではなく、クラウドサービスか、自己管理型サーバーかというホスティング形態の違いです。

GitHub TeamとGHECはGitHubが運用するクラウド環境です。GitHub側で機能を展開すれば、利用者がサーバーを更新しなくても新機能を提供できます。

一方、GHESは利用組織が自社環境やクラウド上に構築し、バージョンアップや運用を管理する製品です。クラウドで提供された新機能が、同じタイミングでGHESにも実装されるとは限りません。

GHES・GHEC・GitHub Teamの対応差

利用環境Code QualityのGA時点の対応管理画面からの有効化主な対応
GitHub Enterprise Server非対応不可既存の品質管理ツールを継続するか、今後の対応を待つ
GitHub Enterprise Cloud対応可能Enterprise、Organization、Repositoryのポリシーを確認する
GitHub Team対応可能OrganizationまたはRepositoryの設定から有効化する
GitHub Free/Pro対象外不可GitHub Team以上の対応プランを検討する

GitHub公式ドキュメントでも、Code Qualityを利用できるプランは「GitHub Team or GitHub Enterprise Cloud」とされています。GHESは利用対象に含まれていません。(GitHub Docs)

「not available at launch」は今後の提供日を意味しない

「not available at launch」という表現から、近いうちにGHESにも対応すると考えるのは早計です。

この表現で分かるのは、GA開始時点では利用できないという事実までです。GitHubのGA発表では、GHES版の提供時期や対象バージョン、ロードマップは示されていません。(The GitHub Blog)

そのため、次期GHESバージョンで必ず使えることを前提に、導入計画や予算を組むべきではありません。正式な対応発表やGHESリリースノートを確認してから判断する必要があります。

管理画面にCode Qualityがないときの切り分け方

Code Qualityが表示されない場合は、権限やブラウザを確認する前に、利用しているGitHubの種類を確認します。

利用環境がGHESかを確認する

次のような環境はGitHub Enterprise Serverです。

  • 組織がGitHubサーバーのバージョンアップを管理している
  • 自社管理のサーバーやクラウド環境にGitHubを構築している
  • GitHub.comとは別の社内向けURLで利用している
  • 管理者がバックアップ、メンテナンス、アプライアンス設定を管理している

GHESであることが確認できた場合、それ以上、Code Qualityの表示設定を探す必要はありません。GA時点では未対応です。

GHECまたはGitHub Teamの場合は設定条件を確認する

GHECまたはGitHub Teamを利用しているにもかかわらず、Code Qualityを有効化できない場合は、次の項目を確認します。

確認項目確認する内容
契約プランGitHub TeamまたはGitHub Enterprise Cloudであるか
操作権限Repository owner、Organization owner、管理者権限があるか
EnterpriseポリシーEnterprise ownerが対象OrganizationでCode Qualityを許可しているか
GitHub Actions対象リポジトリでGitHub Actionsが利用可能か
Organizationポリシー対象リポジトリがRepository accessの範囲に含まれているか
課金設定Code Qualityの追加料金を利用できる状態か

GHECでは、Enterprise ownerが最初にCode Qualityの利用を許可します。そのうえでOrganization ownerが対象リポジトリを指定し、必要に応じてリポジトリ管理者が個別に有効化します。(GitHub Docs)

GHEC・GitHub TeamでCode Qualityを有効化する流れ

対応するクラウド環境では、リポジトリ単位またはOrganization単位でCode Qualityを有効化できます。

リポジトリ単位で有効化する

対象リポジトリを開き、次の順に操作します。

  1. リポジトリの「Settings」を開く
  2. サイドバーの「Security」を確認する
  3. 「Code quality」を開く
  4. 「Enable code quality」を選択する
  5. 分析対象の言語とRunnerを確認する
  6. 設定を保存する

GitHub Code QualityはGitHub Actionsを使用してCodeQL分析を実行するため、GitHub Actionsが無効になっている環境では正常に利用できません。(GitHub Docs)

Organization単位で有効化する

Organization ownerは、Organizationの「Settings」→「Security」→「Code quality」から対象範囲を設定できます。

対象範囲は、すべてのリポジトリ、選択したリポジトリ、条件に一致するリポジトリなどから指定できます。多数のリポジトリへ一括展開する場合は、最初から全体へ適用せず、代表的なリポジトリで試験運用する方が安全です。

分析時間、Runnerの負荷、検出結果の量、開発者の対応工数、課金への影響を確認してから対象を広げると、運用上の混乱を抑えられます。

Self-hosted runner対応とGHES対応を混同しない

GitHub Code Qualityは、GitHub-hosted runnerだけでなくself-hosted runnerでも分析を実行できます。ここで注意したいのは、self-hosted runnerに対応していることと、GitHub Enterprise Serverに対応していることは別という点です。

self-hosted runnerは、GHECやGitHub Team上のリポジトリについて、分析処理を自社管理のRunnerで実行する構成です。Code Qualityの管理機能や結果表示までGHES上で利用できるという意味ではありません。(The GitHub Blog)

次の構成は可能です。

GitHub Enterprise Cloud
        ↓
GitHub Actionsワークフロー
        ↓
社内ネットワーク上のself-hosted runner

一方、次の構成はGA時点ではCode Qualityの対象外です。

GitHub Enterprise Server
        ↓
self-hosted runner
        ↓
GitHub Code Qualityを有効化

Runnerを追加しても、GHESの管理画面にCode Qualityが現れることはありません。

GitHub Advanced Securityを契約してもGHESでは有効化できない

GitHub Code Qualityは、GitHub Advanced Securityに含まれる機能ではなく、独立した有料製品です。

そのため、次の対応を行ってもGHESでCode Qualityを有効化できるようにはなりません。

  • GitHub Advanced Securityのライセンスを追加する
  • GitHub Code Securityを有効化する
  • Code scanningを有効化する
  • CodeQLのワークフローを作成する
  • GitHub Actionsを有効化する
  • 管理者権限を追加する

GA発表時点の料金体系は、アクティブなコミッター単位の基本料金に加え、AI機能の使用量とGitHub Actionsの実行コストが発生する構成です。GitHubはCode QualityをGitHub Advanced Securityとは別の製品として説明しています。(The GitHub Blog)

GHESで利用できる現実的な対応方法

GHESにCode Qualityを追加する設定上の回避策はありません。組織のクラウド利用方針やソースコードの機密性に応じて、次のいずれかを選びます。

対応するGHECまたはGitHub Teamで運用する

クラウド上へのソースコード保存が認められている場合は、対象リポジトリをGHECまたはGitHub Teamで運用する方法があります。

特に、次のようなリポジトリは先行導入の候補になります。

  • 社外公開済みのソースコード
  • 機密情報を含まない社内ツール
  • 新規開発で移行コストが小さいプロジェクト
  • AI生成コードの品質確認を強化したいプロジェクト
  • 複数リポジトリの品質をOrganization単位で可視化したい環境

ただし、Code Qualityを使うためだけにリポジトリを移行すると、認証、権限管理、監査ログ、ネットワーク接続、CI/CD、データ保管方針まで見直す必要があります。

機能の有無だけで決めず、移行コストと運用リスクを含めて判断してください。

GHES上で既存の品質管理を継続する

オンプレミス運用が必須の場合は、Code Qualityに近い品質管理を既存のCI/CDで継続します。

最低限、次の仕組みを組み合わせます。

  • 言語別リンターによるコーディング規約チェック
  • 静的解析による不具合や保守性の確認
  • 単体テストと結合テスト
  • テストカバレッジの測定
  • Pull Requestごとの自動チェック
  • 品質基準を満たさない変更のマージ制限
  • 検出結果の定期的な棚卸し

すでにオンプレミス向けの品質管理ツールやCI基盤を運用している場合は、GHES版Code Qualityを待つ間も、その仕組みを維持する方が現実的です。

Code scanningとCode Qualityを使い分ける

GHESでは、契約や設定条件を満たせばCodeQLを使ったcode scanningを利用できます。ただし、code scanningとCode Qualityは同じ機能ではありません。

機能主な目的
Code scanningセキュリティ上の脆弱性や危険なコードを検出する
Code Quality保守性、信頼性、品質債務、カバレッジなどを管理する
リンター書式、構文、コーディング規約違反を検出する
テスト実際の動作が期待どおりか確認する

code scanningを有効にしても、Code Qualityの品質スコア、品質向けダッシュボード、AI支援による品質検出などが追加されるわけではありません。両者を代替関係ではなく、目的の異なる仕組みとして整理する必要があります。GHESでのcode scanningは、GitHub Code Securityが有効なOrganization所有リポジトリなどで利用できます。(GitHub Docs)

GitHubの正式対応を待つ

ソースコードをクラウドへ移せず、既存ツールも変更したくない場合は、GHESへの正式対応を待つことになります。

確認先は、GitHubのChangelog、GitHub Enterprise Serverのリリースノート、Code Qualityの公式ドキュメントです。

ただし、「not available at launch」という表現だけを根拠に、特定の時期に提供されると見込むのは避けてください。対応バージョンと提供条件が正式に発表されるまでは、現在の品質管理体制を継続する必要があります。

よくある誤った対応

対応結果
GHESを最新版へ更新するCode Quality対応が発表されていなければ表示されない
ブラウザのキャッシュを削除する製品の対応範囲は変わらない
Enterprise owner権限を付与するGHES自体が未対応なら有効化できない
GitHub Actionsを有効にするCode Qualityの前提条件にはなるが、GHES対応にはならない
self-hosted runnerを追加するGHEC・Team上の処理には使えるが、GHES対応にはならない
GitHub Advanced Securityを購入するCode Qualityは別製品であり、GHES対応も追加されない
サポートへ表示不具合として問い合わせるまずGHES非対応であることを案内される可能性が高い

GHECやGitHub Teamで表示されない場合は権限やポリシーの確認が必要ですが、GHESの場合はその前に互換性を確認することが重要です。

GHES利用組織が次に取るべき行動

まず、自社環境がGHES、GHEC、GitHub Teamのどれに該当するかを確認してください。

GHESであれば、Code Qualityが表示されないのは仕様です。設定変更による有効化はできません。次の順序で方針を決めます。

  1. クラウド上で管理できるリポジトリがあるか確認する
  2. 利用可能であればGHECまたはGitHub Teamで小規模な検証を行う
  3. クラウド移行できないリポジトリは既存の品質管理を継続する
  4. code scanningとCode Qualityを混同せず、必要な機能を整理する
  5. GHESの正式対応が発表されるまでリリース情報を確認する

GHECまたはGitHub Teamであれば、Enterpriseポリシー、Organizationの対象範囲、管理者権限、GitHub Actionsの順に確認します。

重要なのは、Code Qualityが見つからない問題を一律に「権限不足」と判断しないことです。GHESでは互換性の問題、GHEC・GitHub Teamでは設定やポリシーの問題として切り分けることで、不要な調査や設定変更を避けられます。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次