# GitHub Code Quality の大規模展開

まず小規模なグループで Code Quality を試験導入し、品質基準を調整してから、安心してすべてのチームへ展開しましょう。

Code Qualityを一度にどこでもオンにすると、すべてのチームが同じ日に pull request に関するCode Quality結果を見始めるので、驚くべき混乱を招く可能性があります。 このチュートリアルでは、段階的にロールアウトする方法について説明します。最初に小さなグループに結果を導入し、しきい値を調整してから展開します。 組織全体に影響を与える前に、その値を証明します。

## 前提条件

* エンタープライズ所有者は、企業内の Code Quality を許可しています。 「[企業での GitHub Code Quality の使用を許可する](/ja/code-security/how-tos/secure-at-scale/configure-enterprise-security/configure-specific-tools/allow-github-code-quality-in-enterprise?utm_campaign=code-quality-ga-july-2026\&utm_medium=docs\&utm_source=docs-roll-out-at-scale-enable-cq)」を参照してください。
* 組織の所有者であるため、 Code Quality を有効にして、組織レベルでルールセットを構成できます。

## パイロットの計画

**組織全体ではなく、小規模なパイロット グループから始めます** 。 優れたパイロット グループは、単一のエンジニアリング チーム、または関連するアプリケーションのセットであり、意味のある結果を生成するのに十分なアクティブであり、結果に関するフィードバックを提供できるユーザーが所有します。

そのグループを対象にするには、\*\*\*\* に対して組織のCode Quality設定を使用します。 パイロットには、次の 2 つの優れたオプションがあります。

* **選択したリポジトリ:** パイロット リポジトリの固定リストを手動で選択します。 パイロット グループが小さく安定している場合に最適です。
* **フィルターの照合:**`code-quality-enabled: true`などのカスタム プロパティなど、定義した条件に一致するすべてのリポジトリを有効にします。 チームがより多くのリポジトリにタグを付けるにつれて、パイロットが自動的に成長する場合に最適です。

リポジトリに 1 つずつ名前を付けるのではなく、カスタム プロパティを対象とすることは、後でさらにリポジトリにプロパティを設定するだけでパイロットを拡大できることを意味します。 カスタム プロパティを使用する場合:

1. カスタム プロパティを作成します。 「[Organization 内リポジトリのカスタム プロパティの管理](/ja/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization)」を参照してください。
2. フィルターに一致するリポジトリに対して、組織レベルで Code Quality を有効にします。 「[組織と企業全体のコード品質の有効化](/ja/code-security/concepts/code-quality/enablement-at-scale#organization-level-repository-access)」を参照してください。

## 評価モードで品質ルールセットを有効にする

**最初に評価モードで品質しきい値を有効にします。** このモードでは、 Code Quality は、実際にブロックすることなく、どのプル要求が *ブロックされるかを* 報告するため、パイロット チームは適用される前に影響を確認できます。

パイロット リポジトリをスコープとする組織のルールセットとしてしきい値を設定し、影響を判断するのに十分なプル要求アクティビティ (通常は **1 週間または 2 週間**) を収集するまで評価モードのままにします。 「[プル要求のコード品質しきい値の設定](/ja/code-security/how-tos/maintain-quality-code/set-pr-thresholds)」を参照してください。

## しきい値を調整しましょう

**評価モードの結果を使用して、しきい値を調整します。**
**ルールセットの分析情報 (ルール**セットの履歴) を調べて、どのプル要求がブロックされたかとその理由を正確に確認します。 ブロックされてしまうプル リクエストが多すぎる場合は、しきい値の設定が、コードベースの現状に対して厳しすぎる可能性があります。 ブロックされるものがほとんどない場合は、設定を厳しくしたほうがよいかもしれません。 実際に適用する品質バーがゲートに反映されるまで調整します。

## 強制モードに移行する

**評価モードの結果が正しく表示されたら、ルール セットを \[評価] から \[アクティブ] に切り替えます。** このしきい値により、条件を満たさないプル要求がブロックされるようになりました。 パイロット チームは強制ゲートを経験し、ロールアウトを拡大する前に最終チェックを行います。

## 組織全体に展開する

**パイロットから学習した内容を使用してロールアウトを展開します。** 次の 2 つの方法で拡大できます。

* **選択したリポジトリ**の一覧にリポジトリを追加するか、フィルターに一致する他のリポジトリにカスタム プロパティを設定します。
* しきい値に自信が持てたら、 **リポジトリのアクセス** 設定を **\[すべてのリポジトリ** ] に切り替えて、組織全体に Code Quality を 1 回の変更で適用します。

適切なアプローチを選択できるように、組織レベルの有効化の動作について知っておくべきことがいくつかあります。

* **リポジトリアクセスの**選択肢は**既存のリポジトリと将来のリポジトリの両方**に適用されるため、後で作成されたリポジトリは自動的に選択を継承します。 これは、 **すべてのリポジトリ**、 **フィルターの照合**、リポジトリ **なし**に当てはまります。
* 保証されたベースラインを確保するために、リポジトリ管理者でも上書きできない **Enforce access** をオンにします。 オフのままにするか、\[リポジトリが **決定できるようにする**] を選択して、チームが自分のタイムラインでオプトインできるようにします。

アクセス オプションの完全な一覧と適用のしくみについては、 [組織と企業全体のコード品質の有効化](/ja/code-security/concepts/code-quality/enablement-at-scale#organization-level-repository-access) を参照してください。

### プログラムによるスケーリング

ほとんどのロールアウトでは、UI を使用して有効にするのが最適な出発点です。リポジトリを直接フィルター処理してターゲットにできます。これにより、スクリプトでの再現が困難になります。

ロールアウトを自動化する必要がある場合は、REST API を使用して Code Quality 結果を取得できます。これは、展開時の進行状況のレポートに役立ちます。 REST API を使用してリポジトリの Code Quality を有効にして、UI で各リポジトリを有効にするのではなく、組織全体でスクリプトを有効にすることもできます。 「[コード品質のための REST API エンドポイント](/ja/rest/code-quality/code-quality)」を参照してください。

## コードカバレッジを設定する

**しきい値の調整が済んだら、コードカバレッジを追加してください。** コード カバレッジは、前の手順でロールアウトした品質しきい値とは別であるため、チームに合うたびにオンにしたり、必要がない場合は完全にスキップしたりできます。

Code Qualityを有効にしても、コード カバレッジは自動的に有効になりません。 カバレッジはリポジトリごとにオプトインされ、カバレッジ データをアップロードするワークフローがリポジトリに追加された後にのみレポートが開始されます。 つまり、チームは最初に Code Quality を採用し、後でカバレッジを追加できます。

リポジトリのカバレッジを設定するには、 [リポジトリのコード カバレッジの設定](/ja/code-security/how-tos/maintain-quality-code/set-up-code-coverage) を参照してください。