GitHub Code Qualityの「organization-level repository targeting」は、組織内の全リポジトリへ一括適用していた設定を、必要なリポジトリだけに絞って有効化・無効化できるようにする変更です。対象は、カスタムプロパティ、手動選択、リポジトリの可視性、フォークの状態から指定でき、必要に応じてリポジトリ管理者による設定変更も禁止できます。(The GitHub Blog)
対応を優先すべきなのは、GitHub TeamまたはGitHub Enterprise Cloudで多数のリポジトリを管理している組織です。特に、段階導入したい場合、利用コストを制御したい場合、重要なリポジトリで設定を固定したい場合は確認が必要です。一方、通常の開発者がコードやワークフローを直ちに変更する必要はありません。ただし、自分のリポジトリが新たに対象または対象外となる可能性はあります。
GitHub Code Qualityの組織レベルターゲティングで何が変わったのか
2026年7月10日時点で確認できるGitHub公式情報では、米国日付の2026年7月9日付Changelogとして「Organization-level targeting for GitHub Code Quality」が公開されています。
これまで組織設定からGitHub Code Qualityを操作する場合は、組織内のリポジトリをまとめて有効化または無効化する形でした。今回の変更により、組織の所有者は適用先を限定できるようになります。(The GitHub Blog)
| 確認項目 | 従来の組織設定 | 今回追加された動作 | 実務上の影響 |
|---|---|---|---|
| 適用範囲 | 組織内の全リポジトリへ一括適用 | 一部のリポジトリだけを指定可能 | 段階導入や限定運用がしやすくなる |
| 対象の指定方法 | リポジトリ単位の個別設定が中心 | カスタムプロパティ、手動選択、可視性、フォーク状態で指定 | リポジトリ数が多い組織でも管理しやすい |
| 設定の強制 | 組織単位で対象を細かく固定する機能は限定的 | 対象リポジトリで設定を強制可能 | リポジトリ管理者による変更を防げる |
| CodeQL分析やPRチェック | Code Qualityワークフローで実行 | 今回の発表では変更の記載なし | 通常はコードやワークフローの移行不要 |
| GitHub Enterprise Server | 利用不可 | 引き続き利用不可 | GHES利用組織は現時点で対応不要 |
重要なのは、今回の変更がCode Qualityの解析ルールやプルリクエスト上の表示を置き換えるものではなく、どのリポジトリに適用するかを管理するための変更である点です。
既存のCode Qualityでは、動的に生成される「Code Quality」ワークフローがCodeQL分析を実行し、プルリクエストでは「CodeQL – Code Quality / Analyze」というチェックが表示されます。今回のChangelogでは、この解析処理やチェック名を変更するとは説明されていません。(GitHub Docs)
今回の変更で対応が必要な人
対応要否は、契約プランだけでなく、リポジトリ数、現在の有効化方法、コスト管理の必要性で判断します。
| 利用状況 | 対応優先度 | 確認すべきこと |
|---|---|---|
| GitHub Teamで複数リポジトリを管理している | 高 | 全リポジトリへの適用が本当に必要か |
| GitHub Enterprise Cloudで組織を管理している | 高 | エンタープライズポリシーと組織設定の関係 |
| 一部の製品リポジトリから段階導入したい | 高 | カスタムプロパティまたは手動選択の設計 |
| Code Qualityの利用料金を抑えたい | 高 | 対象リポジトリとアクティブコミッターの範囲 |
| APIやスクリプトでリポジトリ設定を変更している | 中 | 組織による強制設定と自動処理の競合 |
| 1つのリポジトリだけを個別管理している | 低 | 組織側で設定が強制されていないか |
| GitHub Enterprise Serverを利用している | 対応不要 | 現時点では機能の対象外 |
| 一般の開発者としてコードを変更している | 低 | PRチェックやマージ条件への影響 |
GitHub Code Qualityの組織レベルターゲティングは、GitHub TeamとGitHub Enterprise Cloudのパブリックプレビューとして提供され、GitHub Enterprise Serverでは利用できません。組織が所有するリポジトリが対象です。(The GitHub Blog)
リポジトリの指定方法と使い分け
新機能では、4種類の方法で対象リポジトリを選べます。単に設定できるというだけでなく、運用目的に合った方法を選ぶことが重要です。
カスタムプロパティで指定する
カスタムプロパティは、リポジトリ数が多く、一定の基準で継続的に対象を管理したい場合に適しています。
例えば、次のようなプロパティを組織内で定義しているケースです。
lifecycle=productioncriticality=highcode-quality=requiredowner=platform-team
本番運用中で重要度の高いリポジトリだけを対象にするなど、管理ルールを明文化できます。
ただし、プロパティが未設定のリポジトリや、表記が統一されていないリポジトリがあると、意図せず対象から漏れる可能性があります。設定前に、対象候補のリポジトリへ必要なプロパティが付与されているかを一覧で確認してください。
また、プロパティ値を後から変更した場合の反映タイミングや、複数条件が重なった場合の優先順位は、Changelogだけでは詳細を確認できません。実運用前に検証用リポジトリで挙動を確認するのが安全です。
リポジトリを手動で選択する
手動選択は、少数のリポジトリで試験導入する場合に向いています。
例えば、次のような使い方が考えられます。
- 代表的な3～5リポジトリで先行検証する
- 新しいサービスだけで利用する
- 規制対応が必要なシステムだけを対象にする
- 利用コストを確認してから段階的に増やす
対象が明確で分かりやすい一方、新規リポジトリが作成されても自動的に対象へ追加されるとは限りません。長期運用では、対象追加をリポジトリ作成手順に組み込む必要があります。
リポジトリの可視性で指定する
可視性による指定では、Public、Internal、Privateといった区分を基準にできます。
公開OSSリポジトリだけでCode Qualityを利用したい場合や、社内リポジトリを優先して導入したい場合に便利です。
ただし、リポジトリの可視性を後から変更する運用がある場合は注意が必要です。可視性をPrivateからPublicへ変更したときに、Code Qualityの有効状態も変化するのかを事前にテストしてください。
フォークの状態で指定する
フォークかどうかを条件に含められます。
外部リポジトリのフォークを多数保有している組織では、フォークを対象外にすることで不要なスキャンや管理負荷を抑えられます。一方、フォークしたコードへ独自の変更を加え、製品として運用している場合は、単純にすべてのフォークを除外すると重要なリポジトリが漏れます。
「フォークであるか」だけではなく、実際の用途と保守状況を確認してから条件を決める必要があります。
これら4種類の選択方法は、GitHub公式Changelogで明示されています。(The GitHub Blog)
設定を強制する場合と強制しない場合の違い
組織の所有者は、対象リポジトリに対してCode Qualityの設定を強制できます。強制すると、リポジトリ管理者は対象リポジトリの設定を変更できません。(The GitHub Blog)
強制を推奨できるケース
次のようなリポジトリでは、組織側で設定を固定する価値があります。
- 決済、認証、個人情報処理など重要度の高いシステム
- セキュリティ基準や監査基準の対象となるリポジトリ
- 複数部門が共同管理し、設定のばらつきを防ぎたいリポジトリ
- Code Qualityの結果をマージ条件に使用しているリポジトリ
最初から強制しないほうがよいケース
導入直後は、強制せずに動作を確認したほうが安全です。
特に、セルフホステッドランナー、プライベートパッケージ、独自のマージルールを利用しているリポジトリでは、分析ワークフローが正常に完了しない可能性があります。
まず有効化だけを行い、分析結果、GitHub Actionsの実行時間、PRチェック、開発者への影響を確認します。その後、問題がないことを確認してから強制へ切り替えると、障害時の切り戻しが容易です。
既存実装との互換性
リポジトリ内のコード変更は通常不要
今回公表された差分は、組織設定におけるリポジトリの選択と設定の強制です。解析言語、CodeQLクエリ、PRコメント、既存ワークフローの形式を変更する内容は発表されていません。
そのため、すでにCode Qualityが正常に動作しているリポジトリであれば、今回の機能追加だけを理由にソースコードやワークフローを修正する必要は通常ありません。
ただし、組織ポリシーによってリポジトリが新たに有効化された場合は初回スキャンが実行されます。反対に対象外となれば、今後の分析、PRチェック、利用料金に影響する可能性があります。Code Qualityは初回にデフォルトブランチ全体を分析し、その後は新規または更新されたプルリクエストも分析します。(GitHub Docs)
既存のAdvanced Securityポリシーは確認が必要
GitHub Enterprise Cloudのエンタープライズ設定では、既存のGitHub Advanced Securityポリシー設定が、独立したGitHub Code Qualityのポリシーにも自動適用されます。(GitHub Docs)
これは一定の互換性を確保する仕組みですが、「現在の設定をそのまま引き継げば問題ない」とは限りません。過去にAdvanced Securityを広範囲へ許可していた場合、意図した以上の組織やリポジトリでCode Qualityを利用できる状態になる可能性があります。
エンタープライズ管理者は、次の順序で確認してください。
- エンタープライズでCode Qualityを許可している組織
- 各組織で設定された対象リポジトリ
- 対象リポジトリでの強制設定
- リポジトリ単位の現在の有効状態
- Code Quality結果を必須にするルールセット
APIや運用スクリプトは別途テストする
公開されているGitHub Code QualityのREST APIドキュメントでは、リポジトリ単位の設定取得と変更が案内されています。
主な処理は、リポジトリごとに次の情報を取得または変更するものです。
- Code Qualityの有効状態
- 対象言語
- 標準ランナーまたはラベル指定ランナー
- セットアップ状況
一方、執筆時点のCode Quality REST APIページでは、今回追加された組織レベルのターゲティングポリシーを作成する専用エンドポイントは確認できません。(GitHub Docs)
既存のスクリプトで各リポジトリを有効化している場合でも、すぐに処理を廃止しないでください。組織側で設定を強制した状態に対して、スクリプトがどの権限で実行され、どのレスポンスを返すかをテストする必要があります。
特に確認したいのは、次のケースです。
- 組織側で有効化を強制しているリポジトリを、APIで無効化しようとした場合
- 組織側で無効化しているリポジトリを、APIで有効化しようとした場合
- リポジトリ管理者権限のトークンを利用している場合
- 組織所有者またはエンタープライズ管理者のトークンを利用している場合
強制設定とAPI操作が競合した場合の詳細は、発表文だけでは判断できません。実行結果、HTTPステータス、監査ログを記録して確認してください。
既存の全リポジトリ設定がどう移行されるかを確認する
公式Changelogでは、既存の「全リポジトリで有効」という設定が、新しいターゲティング設定へどのような条件で移行されるかまでは説明されていません。
機能が表示されたら、次の点を確認します。
- 現在有効なリポジトリがすべて対象として残っているか
- 新規リポジトリが自動的に対象へ含まれるか
- 対象外にしたリポジトリで分析が停止しているか
- リポジトリ管理者が設定を変更できる状態か
- 意図せず「強制」が有効になっていないか
執筆時点のGitHub Docsには、組織設定で全リポジトリを一括して有効化または無効化する従来の説明も残っています。一方、Changelogでは部分的なターゲティングが案内されているため、ドキュメントと実際の組織画面で反映時期が異なる可能性を考慮してください。(GitHub Docs)
GitHub Code Qualityを導入するための条件
組織レベルターゲティングを検討する前に、Code Quality自体の利用条件を確認します。
| 項目 | 条件・確認内容 |
|---|---|
| 契約プラン | GitHub TeamまたはGitHub Enterprise Cloud |
| リポジトリ | 組織が所有するリポジトリ |
| GitHub Enterprise Server | 対象外 |
| 組織での設定権限 | 組織の所有者 |
| エンタープライズポリシー | エンタープライズ所有者による許可が必要 |
| GitHub Actions | 有効化が必要 |
| 解析言語 | C#、Go、Java、JavaScript、Python、Ruby、TypeScriptなど |
| ランナー | 標準ランナーまたは指定ラベルのランナー |
| 追加ライセンス | GitHub CopilotやGitHub Code Securityの契約は必須ではない |
| 提供状況 | パブリックプレビュー |
GitHub Code Qualityは、GitHub Actionsを利用して分析ワークフローを実行します。対応言語のリポジトリでは、ルールベースのCodeQL分析を利用できます。(GitHub Docs)
エンタープライズ環境では、エンタープライズ所有者がすべての組織または選択した組織に対してCode Qualityを許可する必要があります。組織レベルのターゲティング設定だけを変更しても、上位のエンタープライズポリシーで許可されていなければ利用できません。(GitHub Docs)
料金への影響を踏まえて対象を決める
GitHub Code Qualityは2026年7月20日に一般提供へ移行する予定です。パブリックプレビュー期間中はCode QualityのAIクレジットやアクティブコミッターに対する料金は発生しませんが、分析に使用するGitHub Actionsの実行時間は消費されます。(GitHub Docs)
一般提供後は、主に次のコストが関係します。
- GitHub Actionsの実行時間
- AIによる分析で使用するクレジット
- Code Qualityを有効化したリポジトリのアクティブコミッター
アクティブコミッターは、過去90日以内に対象リポジトリへプッシュされたコミットを持つユーザーとして扱われます。同じユーザーが複数の対象リポジトリや組織で活動していても、条件を満たす範囲では1ライセンスとして数えられます。(GitHub Docs)
したがって、組織レベルターゲティングは単なる管理機能ではなく、コスト管理の手段にもなります。
例えば、次のようなリポジトリまで無条件に有効化する必要があるかを見直します。
- 長期間更新されていない検証用リポジトリ
- 教育やサンプル目的のリポジトリ
- 上流の変更を追跡するだけのフォーク
- 廃止予定のシステム
- CodeQLの結果を実際には確認していないリポジトリ
ただし、料金だけを理由に重要なリポジトリを対象外にすると、品質上の問題を検出できなくなります。コスト、変更頻度、システムの重要度、既存テストの充実度を合わせて判断してください。
安全に導入する手順
現在の設定を記録する
変更前に、リポジトリごとの状態を記録します。
最低限、次の情報を一覧にしてください。
- Code Qualityの有効・無効
- 対象言語
- 使用ランナー
- カスタムプロパティ
- 可視性とフォーク状態
- Code Quality結果を必須にするルールセット
- 過去90日間に活動した開発者
- GitHub Actionsの利用時間
リポジトリ単位のセットアップ状態はREST APIでも取得できます。(GitHub Docs)
対象とする基準を先に決める
画面上でリポジトリを選ぶ前に、導入目的を明確にします。
例えば、次のように分類します。
| 分類 | 推奨設定例 |
|---|---|
| 本番運用中の重要システム | 有効化し、検証後に強制 |
| 通常の業務システム | 有効化するが、当初は強制しない |
| 新規開発中のリポジトリ | チーム単位で段階導入 |
| 検証・サンプル用 | 原則対象外 |
| 外部リポジトリの参照用フォーク | 原則対象外 |
| 独自改修して運用するフォーク | 個別に判断 |
「すべて有効」または「すべて無効」の二択ではなく、Code Qualityを利用する価値が高いリポジトリから優先することが重要です。
代表的なリポジトリで試験する
最初のテストには、条件が異なる複数のリポジトリを含めます。
- 標準のGitHubホステッドランナーを使うリポジトリ
- セルフホステッドランナーを使うリポジトリ
- JavaScriptやPythonなど、異なる言語のリポジトリ
- Privateリポジトリ
- フォークリポジトリ
- プライベートパッケージを参照するリポジトリ
- Code Quality結果をマージ条件に使用するリポジトリ
同じ構成のリポジトリだけでテストすると、本番展開後にランナーや依存関係の違いで失敗しやすくなります。
強制せずに有効化する
試験段階では、まずCode Qualityを有効化し、リポジトリ管理者による変更を禁止しない状態で確認します。
次の結果が得られることを確認してください。
- デフォルトブランチの初回分析が完了する
- 「Code Quality」ワークフローが成功する
- PRに「CodeQL – Code Quality / Analyze」が表示される
- 検出結果がPR上またはダッシュボードに表示される
- 対象外リポジトリでは設定が変わっていない
- 想定したランナーで処理されている
Code Qualityの組織ダッシュボードでは、閲覧権限を持つリポジトリの検出状況や傾向を確認できます。(GitHub Docs)
問題がなければ設定を強制する
試験期間中に問題がなければ、重要なリポジトリから設定を強制します。
強制後は、リポジトリ管理者が設定を変更できないことも確認してください。運用上は、Code Qualityを無効化する必要が生じた場合の申請先と承認者も決めておくと混乱を防げます。
監査ログを確認する
組織のCode Qualityポリシーを変更すると、監査ログではorg.code_quality_entity_policy_updateイベントを確認できます。(GitHub Docs)
誰が、いつ、どのような設定へ変更したかを追跡できるよう、テスト時にも監査ログを保存してください。設定変更をInfrastructure as Codeで管理できない段階では、変更申請番号や作業記録と監査ログを結び付けておくと安全です。
テスト時に見落としやすい注意点
Code Quality結果を必須にする前にワークフローを成功させる
GitHubのルールセットでは、「Require code quality results」を使用して、Code Qualityの結果をマージ条件にできます。
ただし、分析ワークフローが結果を返せない状態で必須条件を追加すると、すべてのプルリクエストがマージできなくなる可能性があります。GitHub公式ドキュメントでも、先に「CodeQL – Code Quality」チェックが正常に実行されることを確認するよう案内されています。(GitHub Docs)
安全な順序は次のとおりです。
- Code Qualityを有効化する
- 初回分析の完了を確認する
- テスト用PRでチェックが成功することを確認する
- 必要な重大度を決める
- ルールセットへ必須条件を追加する
- 最後に組織設定を強制する
GitHub Actionsの上限とランナーラベルを確認する
Code Qualityの分析はGitHub Actionsを利用します。Actionsの利用枠を使い切った場合や、指定したラベルに一致するランナーが存在しない場合、分析は完了しません。(GitHub Docs)
特に多数のリポジトリを一度に対象へ追加すると、初回分析が集中します。対象を小分けにし、Actionsの利用状況とランナーの待ち時間を確認しながら展開してください。
プライベートレジストリを後から追加した場合
Code Qualityを有効化した後で新しいプライベートレジストリを組織へ追加した場合、分析からそのレジストリを利用するには、Code Qualityを一度無効化してから再度有効化する必要があります。(GitHub Docs)
ターゲティング設定を変更するタイミングで、次の依存先も確認してください。
- 社内のnpmレジストリ
- MavenやGradleで利用する社内リポジトリ
- Pythonパッケージのプライベートインデックス
- コンテナレジストリ
- ネットワーク内からのみ接続できる依存サービス
対象条件の境界をテストする
ターゲティング条件そのものもテスト対象です。
例えば、カスタムプロパティを使用する場合は、少なくとも次の4種類を用意します。
- 条件に一致するリポジトリ
- 条件に一致しないリポジトリ
- 対象プロパティが未設定のリポジトリ
- 複数の条件に一致するリポジトリ
可視性やフォーク状態を条件にする場合は、属性を変更した後の挙動も確認します。条件変更が即時に反映されるか、既存の分析結果が残るか、設定の強制状態がどう変わるかを記録してください。
切り戻し時はルールセットも確認する
障害対応でCode Qualityを無効化しても、ルールセットにCode Quality結果の必須条件が残っていると、必要なチェックが返らず、プルリクエストのマージに影響する可能性があります。
切り戻し手順には、次の作業をセットで含めます。
- 組織のターゲティング設定を戻す
- 強制設定を解除する
- リポジトリのCode Quality状態を確認する
- Code Quality結果を要求するルールセットを確認する
- テスト用PRでマージ条件を再確認する
- 監査ログへ変更が記録されたことを確認する
自組織で対応が必要かを判断するチェックリスト
次の項目に1つでも該当する場合は、組織設定を確認する価値があります。
- GitHub TeamまたはGitHub Enterprise Cloudを利用している
- 組織内に多数のリポジトリがある
- 現在、Code Qualityを全リポジトリへ一括適用している
- 本番用と検証用のリポジトリが混在している
- 外部リポジトリのフォークを多数保有している
- GitHub Actionsの利用時間を抑えたい
- Code Qualityの一般提供後のコストを管理したい
- リポジトリ管理者による設定解除を防ぎたい
- APIやスクリプトでCode Qualityを設定している
- Code Quality結果をマージ条件にしている
反対に、GitHub Enterprise Serverを利用している場合や、Code Qualityを利用していない個人リポジトリだけを管理している場合は、今回の変更に対する即時対応は不要です。
まとめ：対象範囲を決めてから、小規模に検証する
GitHub Code Qualityのorganization-level repository targetingにより、組織内の全リポジトリへ一括適用するだけでなく、カスタムプロパティ、手動選択、可視性、フォーク状態を使って適用先を絞り込めるようになりました。さらに、対象リポジトリの設定を組織側で強制できます。(The GitHub Blog)
今回の変更で、通常はソースコードや既存ワークフローを移行する必要はありません。しかし、対象範囲、管理者権限、GitHub Actionsの消費、一般提供後の料金、マージ条件には影響します。
まず現在の有効状態とルールセットを記録し、代表的なリポジトリだけを対象にしてください。初回分析とPRチェックが正常に完了し、対象外リポジトリに影響がないことを確認した後で、対象拡大と設定の強制を行うのが安全です。
コメント