GitHubは、企業で使う外部ライブラリのライセンス、つまり利用条件を共通ポリシーでチェックする機能を正式提供する。開発チームは、指定したリポジトリで新たに追加・変更されるライブラリが企業の許容基準に合うかを自動確認でき、コーディングエージェントもパッケージの推奨や導入時にポリシーへの準拠状況を照会できる。

1. 適用対象とポリシー設定

2026年10月16日に発表されたこの機能は、GitHub Enterprise Cloudの顧客を対象とする。データ保存地域を指定する顧客も含まれ、適用するリポジトリではGitHub Code Securityが有効になっている必要がある。6月のパブリックプレビューを経て正式提供に移行した。

この機能は既存の依存関係レビューの仕組みを拡張し、企業全体に適用するライセンスポリシーを導入する。ここで依存関係とは、プロジェクトが利用する外部パッケージを指す。企業共通の許容基準を設け、リポジトリごとのチェックに結び付ける方式だ。

ポリシーを適用するには、チェック条件をまとめたルールセットで対象リポジトリを指定する。その際、マージ前にライセンス準拠の結果を求める条件であるRequire license compliance results before mergingを使う。既存のコードスキャン条件と同様に、リポジトリルールに結び付ける構造だ。

2. 違反の表示とクローズ申請の審査

開発者が依存関係を追加・修正するコード変更リクエストを開くと、新たに追加・変更された依存関係のライセンスを自動チェックする。基準に合わない依存関係ごとに変更リクエストにメッセージが表示されるため、開発者は対処すべき項目をそのリクエストで確認できる。

このメッセージには対処が必要だ。原文が示す方法は、依存関係を削除または別のものに置き換えること、ライセンスポリシーを修正すること、パッケージの例外を作成することだ。したがって、違反の表示は、そのパッケージを必ず断念しなければならないという意味ではない。

クローズ申請を審査・承認する担当者には、新設された企業レベルの定義済みロールを付与する。ロール名はEnterprise Open-Source License Managerで、個人やチームに割り当てられる。担当者は保留中の申請をメールで通知され、企業管理コンソールで審査できる。

3. ポリシー管理とエージェント向けAPI

パブリックプレビュー以降、データ保存地域を指定する顧客にもライセンス情報が提供された。この情報は準拠チェックだけでなく、パッケージ間の依存関係を示す依存関係グラフやソフトウェア部品表のエクスポートにも反映される。部品表は、ソフトウェアに含まれる構成要素をまとめた一覧だ。

ライセンスポリシーを変更すると、監査ログにイベントが残る。外部の記録システムと連携できるよう、変更の事実を記録する機能だ。企業のライセンスポリシーをダウンロード、更新、置換するAPIも追加された。

別途追加されたパッケージ準拠チェックAPIは、コーディングエージェントが企業のライセンス利用ポリシーに違反するパッケージを推奨したり、コードに導入したりしないよう支援する。変更リクエスト段階のチェックとは別に、エージェントがパッケージを選ぶ際のポリシー確認に活用できるという意味だ。

4. 自動チェックと人の判断を区別する必要がある

導入の効果は、共通ポリシーをリポジトリの変更レビュー過程に結び付ける点にある。開発者がパッケージを追加・修正する際に基準に合うかを自動確認できるが、違反項目を削除するか、ポリシーや例外を変えるかの判断は残る。チェック自動化の利点と、ポリシー運用・申請審査の負担を併せて考える必要がある。

適用対象を決める際は、企業全体のポリシーと、ルールセットで指定したリポジトリを区別する必要がある。原文が説明する有効化の方法は対象リポジトリを指定するものであり、企業の全リポジトリに自動適用されるとは案内していない。

告知には詳細な設定ガイドとAPIドキュメントへのリンクがあるが、具体的なリクエスト・レスポンス形式やコード例は示されていない。実際の連携を準備する際は、告知の機能説明だけで実装方法を確定せず、リンク先のドキュメントを確認する必要がある。

今回の変更の核心は、ライセンス確認を開発者の個別チェックだけに委ねず、企業共通ポリシーと自動チェックに結び付ける一方、ポリシー変更と申請承認の判断は担当者に残す点にある。