GitHubライセンス検査GA：例外の再審査まで運用に組み込む
依存関係の更新にセキュリティ警告がなくても、ライセンス審査が終わったとは限らない。検査が緑でも、製品の全配布形態を評価したことにはならない。GitHubは2026年10月16日、ライセンス準拠検査の一般提供を発表した。
利用条件と対象を先に確認する
対象はデータレジデンシーを含むGitHub Enterprise Cloudで、リポジトリのGitHub Code Securityが有効であることが条件だ。すべてのFree・Teamに自動適用されると解釈しない。企業方針をrulesetのRequire license compliance results before mergingで対象リポジトリに適用する。利用資格、対象、実際のマージ条件を別々に確認したい。 Activeはマージを制限し、Evaluateは注記のみだ。ただし別のコメント解決必須ルールがある場合は注記がマージに影響しうる。
検査単位は変更された依存関係
依存関係を追加・変更するPRでは、新規または変更されたパッケージを方針と照合し、不適合を注記する。削除・置換、方針変更、パッケージ例外などで対応できる。ただし既存配布物全体の審査完了ではない。どのバージョンをどの方針で評価したかを記録しよう。以下は公式機能と区別した運用上の提案だ。
例外に責任者と再確認の契機を付ける
Enterprise Open-Source License Managerは終了申請の審査・承認担当を指定する役割だ。チームではパッケージ、バージョン、PR、用途、理由、責任者、再審査の契機も記録できる。デモ用途の承認を顧客向け配布に転用する前に再確認する、といった手順だ。GitHubが例外を自動失効させるという説明ではない。
エージェントの選定前に確認する
発表にはパッケージの方針適合を確認するAPIと方針変更の監査イベントも含まれる。インストール前の確認は後の置換作業を減らす可能性がある。応答の有無だけでなく対象、方針、時刻、結果を変更記録に紐付けたい。通信失敗や不明なライセンスを暗黙に許可せず、審査へ回す。
まず許可済みと意図的に不適合な依存関係を使う小さなテストPRを一つずつ作り、注記とマージ制限、例外承認後の記録を確認する方法がある。顧客コードを変更しないテスト用リポジトリが適切だ。全体適用前に担当と解除手順を決める。これは提案であり、実施済みの試験報告ではない。
導入時の問いは、誰が例外を管理し、何が変われば再審査するかだ。公式発表はコミュニティ討論を案内するが、本稿は参加規模や普及率を推定しない。個々のライセンスの法的判断を代替するものでもない。次の依存関係PRに判断理由と再審査条件を残そう。
出典と確認範囲
GitHub Docs · Open source license compliance
2026年10月17日に公式発表を確認。最新の資料と自分のアカウント設定を併せて確認してほしい。