複数のOrganizationでセキュリティ設定をそろえるときは、設定を配った後に「誰が変更できるか」まで決める必要があります。チームごとの裁量を残すのか、Enterprise共通の方針として維持するのかで、管理の仕方が変わるためです。

2026年9月15日のGitHubの更新で、Enterpriseのセキュリティ構成をOrganization管理者にも強制できるようになりました。この変更を使ううえでは、上書きを制限する範囲と、実際に検査が動く条件を分けて考えると判断しやすくなります。

設定の強制は、有効・無効を決めた項目に働く

セキュリティ構成（security configuration）は、GitHubのセキュリティ機能の有効化設定をまとめ、リポジトリへ適用する仕組みです。複数のリポジトリを共通の設定で管理するための単位、と考えると分かりやすいですね。セキュリティ構成の説明

強制の対象になるのは、その構成で有効または無効を指定した機能です。未設定の項目は強制されません。つまり、強制する管理者の範囲を広げても、構成が指定していない項目まで一律に固定するわけではありません。カスタム構成の作成手順

この違いから、まず「全社で同じ状態にしたい項目」を明確にする必要があると分かります。たとえば共通で有効にしたい項目が未設定のままなら、管理者への制限だけを強めても、その項目の統一にはつながりません。

Organizationまで強制すると、変更の判断をEnterpriseへ集約できる

従来の強制はリポジトリ所有者による変更を防ぐものでした。今回、Organization所有者も対象に含める選択肢が加わり、Enterpriseで決めた設定を下位の管理者が上書きできないようにできます。構成のEnforcement欄では、次の3つを選べます。変更の告知

選択肢	この構成による変更制限
Don’t enforce	強制しない
Enforce for repository owners	リポジトリ所有者の変更を制限
Enforce for repository and organization owners	リポジトリ所有者とOrganization所有者の変更を制限

選び方は、設定変更の判断をどこへ置くかで考えられます。Organizationごとの調整を認める運用と、Enterprise共通の基準を維持する運用では、必要な制限が異なります。

後者を選ぶなら、例外が必要になったときの相談先もEnterprise側へつなげておきたいところです。これは新しい承認ワークフローが自動で付くという意味ではなく、変更権限の範囲に合わせた運用上の提案です。

強制する構成は、適用先と費用まで見てから広げる

構成を作成する操作と、リポジトリへ適用する操作は別です。Enterpriseでの適用には、全リポジトリを対象にする選択肢と、まだ構成のないリポジトリだけを対象にする選択肢があります。既存の構成を使っている場所も変更対象にするのかを、先に決めておきましょう。構成の適用手順

GitHub Code SecurityやGitHub Secret Protectionを含めてprivate・internalリポジトリへ適用する場合は、利用料金またはGitHub Advanced Securityのライセンスが関係します。また、新規作成時のデフォルト構成を設定していても、Organizationへ移管されたリポジトリには手動で構成を適用する必要があります。構成作成時の条件

このため、導入時は既存リポジトリへの適用と、以後の新規作成・移管の扱いを続けて設計すると、方針を維持しやすくなります。強制モードを選ぶだけでは、対象リポジトリの選定までは済まないわけですね。

設定の上書き防止と、スキャンの稼働確認を分ける

強制した構成にも、機能が働かなくなる条件があります。たとえばcode scanningでは、後からGitHub Actionsを無効にしたり、必要なActionsを利用できなくしたりすると、有効化が適用されない場合があります。強制に関する制約

同じ資料には、強制対象の機能をREST APIで変更しようとすると、呼び出しは成功したように見えても有効化状態は変わらない、と記載されています。設定変更を自動化しているなら、APIの成功応答だけで完了とせず、変更後の実際の状態を読み直す設計が必要です。

構成の適用状態も確認できます。リポジトリの構成状態には、適用・強制中を示す enforced や、適用失敗を示す failed があります。これは構成との関係を示す状態なので、スキャン結果と合わせて見るのが適切です。構成状態のリファレンス

Enterprise共通の設定を維持したいなら、Organization管理者まで含めた強制が選択肢になります。その効果を運用につなげるには、固定する項目、適用先、検査の稼働を順に確かめること。変更の判断を集約しつつ、各リポジトリで保護が働いているところまで見届けるのが、この機能の使いどころです。

出典

• Title: Enforce GitHub Advanced Security configurations
• URL: https://github.blog/changelog/2026-09-15-enforce-github-advanced-security-configurations