本文へ移動
開発ツール AI生成 文責 blackstrawberry

GitHub Advanced Security の設定強制、組織管理者の上書きも止まる3択に

エンタープライズ階層で決めた GitHub Advanced Security の設定を、組織の管理者にも上書きさせない値が Enforcement に増えた。従来は repository owner だけが強制の対象で、組織側は外だった。

エンタープライズ階層で定義した GitHub Advanced Security の設定を、組織の管理者にも上書きさせない選択肢が加わった。これまで強制が止めていたのは repository owner による変更だけで、organization 側はその外にいた(GitHub Changelog、2026年9月15日)。組織ごとに設定を緩めたり足したりしてきたチームは、新しい強制を選ぶ前に、既存の上書きがどう扱われるかを確認する必要がある。

切り替えは security configuration の中の「Enforcement」ドロップダウンで行う。値は3つあり、どれを選ぶかは「誰の上書きを止めるか」を選ぶことと同じだ。

Enforcement の3値を「誰を止めるか」で読む

Enforcement の値上書きが止まる相手
Don’t enforce止めない
Enforce for repository ownersrepository owner
Enforce for repository and organization ownersrepository owner と organization owner

出典:Enforce GitHub Advanced Security configurations(GitHub Changelog、2026年9月15日)

3値のうち真ん中が、これまでの強制にあたる。告知が「以前は enforcement が repository owner の変更を止めるだけだった」と書いているのは、この段が上限だったという意味だ。増えたのは3番目で、組織の管理者が enterprise 階層の設定を上書きする経路をふさぐ。ドロップダウンが security configuration の中にある以上、強制の強さは configuration ごとに持つ値だと読めるが、そう明記されているわけではない。

用語には揺れがある。ドロップダウンの文言は repository owners と organization owners だが、告知の説明文は organization and repository administrators という言い方をしている。owner と administrator が同じ範囲を指すのかは、この告知からは読み取れない。組織に owner 以外の管理権限を配っているなら、そこは自分の環境で確かめるしかない。

影響が出るのは上書きしてきた組織だけ

止まるのは上書きであって、設定そのものではない。enterprise 階層に何も定義していなければ止める対象がないので、今日やることはない。影響が出るのは、enterprise 側に設定があり、かつ組織または repository の階層でそれを変えてきたところだ。全社で同じ設定を敷きたいというコンプライアンス側の要求を抱えているなら、組織ごとの例外を閉じる手段が一段増えたことになる。

告知が書いていないことのほうが、実務では先に当たる。既存の security configuration の Enforcement がどの値から始まるのか、すでに repository owner 向けの強制を選んでいた設定がそのまま維持されるのか、切り替えに猶予があるのか、いずれも触れられていない。enterprise 管理者が選び直すまで挙動は変わらない、と読むのが自然ではあるが、これは告知の文面から出てくる話ではなく、あくまで推測である。

切り替える前に並べておくもの

強制を一段上げる判断は enterprise 側にあり、効き目を受けるのは組織側だ。順番としては、切り替えの可否を議論する前に、どの階層で何を決めているかを棚卸ししたほうが早い。強制後に変更できなくなる差分の候補が見えるからだ。

  • enterprise 階層で定義している security configuration と、適用先の組織
  • 組織階層で上書きしている項目と、変えた理由
  • repository 単位で例外にしているリポジトリ

三つが揃えば、「Enforce for repository and organization owners」に切り替えたあと、誰が変更できなくなる差分かを確認するための一覧になる。既存の差分が自動的に消えるかは、告知には書かれていない。理由の欄が埋まらない上書きは、強制を待つまでもなく畳んでよい。逆に理由が書ける上書きは、enterprise 階層の設定そのものを変える交渉材料になる。組織の裁量として残すか、全社の設定を寄せるかの二択で、後者のほうが強制と衝突しない。

GitHub Enterprise Cloud と GitHub Enterprise Server のどちらで使えるか、REST API から Enforcement を指定できるか、強制の対象になる設定項目がどこまでかは、この告知には書かれていない。組織側で例外を運用しているなら、対象範囲と切り替え時期を enterprise 管理者に先に聞いておくのが確実だ。上の階層で決めた方針を下の階層に効かせる形自体は、Actions の実行保護 のように他の領域でも進んでいる。

出典 種別について