GitHub の OSS ライセンス検査が GA、ruleset で PR に全社方針、Code Security 必須

GitHub Enterprise Cloud で、方針に合わないライセンスの依存を PR の段階で拾う仕組みが 2026年10月16日に一般提供（GA）になった。有効にする入口は ruleset で、新しい条件 Require license compliance results before merging を使って対象リポジトリを指定する。使えるのは GHEC（データレジデンシー版の GHEC を含む）のうち、GitHub Code Security が有効なリポジトリだけだ。

PR が依存を追加・変更すると、新しく入った依存と変わった依存のそれぞれについて、ライセンスが方針で許されているかが自動で検査される。合わない依存ごとに PR へ注釈が付き、その注釈は「依存を外すか置き換える」「方針を直す」「パッケージ例外を作る」のどれかで解消する必要がある。

マージを止めるかどうかは ruleset のモード次第だ。GitHub Docs によると、Active モードでこの条件を有効にした場合は違反が解消されるまでマージをブロックする。Evaluate モードはチェックと注釈を行うが、この条件だけではマージを止めない。ただし、コメントの解決を必須とするブランチ保護規則がある場合は、Evaluate の注釈もその規則の対象になる。

dependency review action との差は方針の置き場所

changelog は、この機能を dependency review action の機能を広げるものと位置づけている。広がった部分は、エンタープライズ全体で一つのライセンス方針を持ち、それを ruleset で各リポジトリに当てられる点だ。ruleset の新条件は、既存の code scanning の条件に似た形だと説明されている。

リポジトリごとのワークフローでライセンスを検査してきたチームにとって気になるのは、既存の dependency review action と併用するのか、置き換えるのかだろう。changelog はこの関係を書いていない。リポジトリ側に独自の許可リストを持っているなら、全社方針と二重に管理することにならないか、導入前に確かめておきたい。

有効にする前にそろえるもの

前提は次の 4 つになる。

• GitHub Enterprise Cloud であること（データレジデンシーの GHEC も対象）
• 対象リポジトリで GitHub Code Security が有効になっていること
• エンタープライズのライセンス方針
• 新条件を含む ruleset と、その対象リポジトリの指定

GitHub Enterprise Server での提供は changelog に記載がない。Code Security が無効なリポジトリを ruleset の対象に含めたときにどう扱われるかも書かれていないので、ruleset の対象範囲は Code Security の有効範囲と合わせておくのが無難だ。Code Security の設定を組織に強制する方法は、Advanced Security の設定強制の記事で扱った。

注釈が付いた PR の片付け方

changelog が挙げる解消の方法は 3 つで、どれを選ぶかで影響の範囲が変わる。

解消の方法	変わるもの	影響の範囲
依存を削除・置換する	その PR の依存	その PR だけ
ライセンス方針を修正する	エンタープライズ全体の方針	方針が当たっている全リポジトリ
パッケージ例外を作る	特定パッケージの扱い	GitHub Docs ではリポジトリ別の例外も設定可能

出典：GitHub Changelog「Open source license compliance generally available」（2026年10月16日）、GitHub Docs「About open source license compliance」。影響の範囲は設定によって異なる

方針の修正は全社に効くので、一件の PR を通すために選ぶ手ではない。特定のパッケージだけ認めたいなら例外、ライセンスの扱いそのものを変える合意があるなら方針の修正、という切り分けになる。

承認者は Enterprise Open-Source License Manager

この機能には、定義済みのエンタープライズロール Enterprise Open-Source License Manager が加わった。closure request を審査・承認すべき個人やチームに割り当てるロールだ。方針の管理者には承認待ちの要求がメールで通知され、エンタープライズのコンソールから審査できる。

ruleset を有効にした時点から PR に注釈が付き始めるはずなので、ロールの割り当てを先に済ませておかないと、要求を受け取る人がいない状態になる。closure request を誰が出せるのか、どの解消方法と結び付くのかは changelog からは読み取れない。

6月のプレビューから加わった点

6月のパブリックプレビュー以降の変更として、次の 4 点が挙がっている。

• データレジデンシーの GHEC でもライセンス情報が使えるようになった。この機能だけでなく、依存関係グラフと SBOM エクスポートにもライセンス情報が入る。
• ライセンス方針の変更が audit log のイベントとして記録され、外部の記録システムと連携できる。
• エンタープライズのライセンス方針をダウンロード・更新・置換する API エンドポイントが追加された。
• パッケージが方針に合うかを確かめる API エンドポイントも追加された。changelog は、コーディングエージェントが方針違反のパッケージを推薦したり組み込んだりしないための用途を挙げている。

方針を API で置換できるので、方針をファイルとして管理し、変更を API で反映する運用も組めそうだ。ただし API の仕様はこの changelog には載っていないので、これは可能性の話にとどまる。導入の順番としては、Code Security の有効範囲の確認、ロールの割り当て、方針の作成、ruleset の対象指定、と進めると手戻りが少ない。