GitHubのライセンスコンプライアンス機能が一般提供開始

GitHubは2026年10月16日、オープンソースライセンスコンプライアンスを一般提供にしました。対象は、GitHub Code Securityを有効にしたGitHub Enterprise Cloudのリポジトリです。この機能は、プルリクエストが追加するすべての依存関係のライセンスを検査します。そのライセンスが会社のポリシーに反する場合は、マージをブロックできます。ライセンスのレビューは通常、コードが書かれた後に手作業で遅れて行われるため、これは重要です。

ライセンスコンプライアンスでできること

オープンソースのパッケージには、すべてライセンスが付いています。ライセンスとは、そのパッケージを使うための法的な条件です。MITやApache 2.0のように、利用者にほとんど何も求めないライセンスもあります。一方で、企業の弁護士が受け入れられない条件を加えるライセンスもあります。Help Net Securityが引用したところでは、GitHubのプロダクトマネージャーであるJeff Luszcz氏とEric Sorenson氏は「ほぼすべてのソフトウェアには、何らかのライセンス契約が付いている」と書いています。

GitHubのchangelogによると、この機能はdependency review actionを拡張し、エンタープライズ全体で1つのライセンスポリシーを使えるようにします。エンタープライズとは、多数の組織をまとめるGitHubの最上位のアカウントです。依存関係を追加または変更するプルリクエストでは、チェックが自動で実行されます。ライセンスが許可されていない依存関係には、それぞれアノテーションが付きます。アノテーションとは、プルリクエストに付けられる注記です。

changelogによると、開発者にはその後、3つの対応方法があります。パッケージを削除するか置き換える、ライセンスポリシーを変更する、またはそのパッケージ1つについて例外を申請する、のいずれかです。

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

GitHubは2026年6月30日、この機能をパブリックプレビューとして公開しました。changelogによると、一般提供では4つの機能が加わります。

一般提供で追加されたもの	機能
データレジデンシーへの対応	データレジデンシー対応のEnterprise Cloudでも、ライセンスデータが依存関係グラフとSBOMのエクスポートに入るようになりました
監査ログのイベント	ライセンスポリシーの変更が記録され、外部のシステムで追跡できます
ポリシーのREST API	エンタープライズのライセンスポリシーをダウンロード、更新、置き換えする新しいエンドポイント
パッケージ確認のエンドポイント	パッケージがポリシーに準拠しているかをツールに返すので、コーディングエージェントは非準拠のパッケージを避けられます

SBOM（ソフトウェア部品表）とは、ソフトウェアに含まれるすべてのコンポーネントの一覧です。AIコーディングツールにとって最も重要なのは最後の行です。エージェントはパッケージを追加する前に、それが許可されているかをGitHubに問い合わせられるようになりました。

適用の仕組み

ポリシーには、許可するライセンスを列挙します。GitHubのドキュメントによると、管理者は組み込みの一覧から選ぶか、SPDX識別子でほかのライセンスを追加します。SPDX識別子とは、ライセンスを表す標準の短いコードです。チェックは推移的な依存関係も対象にします。つまり、あなたのパッケージが取り込むパッケージも検査されます。

rulesetは、エンタープライズ、組織、リポジトリの各レベルでポリシーを適用します。rulesetとは、多数のリポジトリにまとめてルールを設定するGitHubの仕組みです。ドキュメントは次の2つのモードを説明しています。

• Active: 「Requires license compliance results before merging」という条件を持つrulesetは、問題が解決されるまでマージをブロックします。
• Evaluate: 同じチェックが実行され、プルリクエストにアノテーションが付きますが、ブロックはしません。

例外の申請は、新しい定義済みのエンタープライズロールに送られます。changelogはこのロールをEnterprise Open-Source License Managerと呼んでいます。このロールのレビュアーはメールで通知を受け取り、エンタープライズのコンソールから申請を承認します。

GitHubのドキュメントは、中央に1つの広いポリシーを置き、リポジトリごとに例外を設ける形を勧めています。チームは、inactive、evaluate、activeの値を持つカスタムのリポジトリプロパティを追加できます。rulesetがそれらの値を対象にすることで、リポジトリごとに適用の強さを設定できます。

GitHub社内での使い方

Help Net Securityの7月の報道によると、GitHub自身のオープンソースプログラムオフィスがこのツールを使っています。このオフィスは、記事の約2か月前に社内ツールから移行しました。適用をオンにする前に、約1か月間リポジトリをEvaluateモードで運用しました。報道によると、ライセンスの申請の多くは「数時間以内」にレビューされました。最初の許可リストはMIT、Apache 2.0、BSD-3-Clauseでした。

同じ報道は、安全弁にも触れています。チームは重要な修正のためにリポジトリをActiveからEvaluateに戻し、その後また元に切り替えられます。

GitHubは今月、プルリクエストの守りを固めています。10月15日にはプルリクエスト向けAI Scanを一般提供にしました。その翌日には、GitHub Actionsのworkflow lockfileがパブリックプレビューになりました。

開発者にとっての意味

会社でCode Security付きのGitHub Enterprise Cloudを使っているなら、今日からこの機能をオンにできます。別料金を示した情報源はありません。導入を計画する前に、現在のCode Securityの契約で何がカバーされるかを確認してください。

GitHub自身のチームと同じように、Evaluateモードから始めてください。1か月分のアノテーションを見れば、マージがブロックされる前に、コードベースがすでにどのライセンスに依存しているかがわかります。その後、カスタムプロパティを使って、リポジトリをグループごとに順番にActiveへ移してください。

まず許可リストについて合意してください。MIT、Apache 2.0、BSD-3-Clauseはよくある出発点です。ライセンスマネージャーのロールを誰が担うかも決めてください。担当のレビュアーがいないと、例外の申請が滞るからです。

社内ツールやコーディングエージェントを作っているなら、新しいパッケージ確認のエンドポイントを見てください。インストール前にパッケージを確認するエージェントなら、後でプルリクエストがブロックされる手間を省けます。

どのパッケージエコシステムが対象かを示した情報源はありません。全面的な対応を前提にする前に、社内で使っている言語ごとに1つずつリポジトリを試してください。