ログイン学習を始める
AIニュース

GitHubがOSSライセンス確認の自動チェックを一般提供｜仕組みと注意点

  • 公開
  • 約8分で読めます
デジライズAIスクール 監修茶圓 将裕（株式会社デジライズ 代表取締役CEO）

GitHubは2026年10月16日のChangelogで、依存関係のライセンスを一元的なポリシーで点検する機能「Open source license compliance」の一般提供を発表しました。対象は企業向けの提供形態ですが、OSSのライセンスを確認する方法を自分なりに整えたい個人開発者やフリーランスにも、手順の設計図として役に立ちます。この記事では発表された内容を整理し、納品物に混ざるOSSを自分で洗い出して記録する流れに読み替えます。

要点

  • Open source license complianceが2026年10月16日に一般提供になった。対象はGitHub Enterprise Cloudの顧客で、data-resident GHECも含む
  • ポリシーを適用するには、GitHub Code Securityが有効なリポジトリであることが条件
  • dependency review actionの機能を広げ、企業全体のライセンスポリシーをルールセットで効かせる
  • 依存を追加・変更したプルリクエストで自動チェックが走り、ポリシーに合わない依存には注釈が付く
  • 2026年6月30日の公開プレビュー以降、SBOMへのライセンス情報の反映や監査ログ、APIエンドポイントが加わった

何が発表されたか

一般提供の対象と条件

Open source license complianceは、GitHub Enterprise Cloudの顧客向けに一般提供されました。データの保存場所を指定する形態であるdata-resident GHECも対象に含まれます。利用できるのはGitHub Code Securityを有効にしたリポジトリです。GitHub Docsでは、この機能は依存関係のライセンスを追跡し、サプライチェーン（開発に使う外部の部品のつながり）にあるOSSについてポリシーを効かせるためのものだと説明されています。

チェックが動く仕組み

この機能はdependency review actionの機能を拡張し、企業全体のライセンスポリシーを導入します。ポリシーは「Require license compliance results before merging」という新しい条件を使うルールセットでリポジトリを対象にすると有効になります。ルールセットはenterprise・organization・repositoryのスコープで定義できます。許可するライセンスは組み込みのリストから指定し、リストに無い場合はSPDXライセンス識別子を手で追加します。評価には、dependency graphで検出された推移的な依存（依存先がさらに依存しているもの）も含まれます。

開発者が依存を追加または変更したプルリクエストを開くと、ライセンスチェックが自動で走り、新しい依存や変更された依存が許容されるライセンスかを確認します。合わない依存はプルリクエスト上の注釈で示され、依存の削除か置き換え、ライセンスポリシーの修正、パッケージ例外の作成のいずれかで対処する必要があります。Activeモードのルールセットでは違反が解消されるまでマージがブロックされ、Evaluateモードではチェックと注釈は行われるものの、マージはブロックされません。さらに、コメントの解決をマージ条件にするブランチ保護ルールはライセンスチェックの注釈も追跡します。

承認する役割と例外の申請

新しい事前定義のenterpriseロールとして「Enterprise Open-Source License Manager」が加わりました。注釈が付いても自動で例外申請にはなりません。開発者がその依存を使いたい場合に、GitHubが追加情報を尋ねたうえでclosure requestがEnterprise Open Source License Managersへ送られます。ポリシー管理者は保留中の申請をメールで通知され、enterprise consoleから確認できます。書き込み権限のある開発者は、リポジトリのライセンスポリシー設定ページで、適用中のポリシーと例外を確認できます。

公開プレビューからの改善

2026年6月30日の公開プレビュー以降の改善として、次の点が挙げられています。data residencyの顧客でもライセンス情報が使えるようになり、dependency graphとSoftware Bill of Materials（SBOM）のエクスポートにライセンス情報が入ります。ライセンスポリシーの変更は監査ログのイベントとして記録されます。企業のライセンスポリシーを取得・更新・置き換えるAPIエンドポイントと、パッケージがポリシーに準拠しているかを確認するAPIエンドポイントも追加されました。後者により、コーディングエージェントが組織のライセンス利用ポリシーに違反するパッケージを勧めたり取り込んだりしないようにできるとされています。

個人の仕事や学びにどう使えるか

この機能自体は企業向けですが、審査の流れは個人でもそのまま真似できます。鍵は「先に基準を決める」「依存を全部出す」「合わないものの扱いを記録する」の三段です。

受託でWebサイトやアプリを作るフリーランスのエンジニアなら、案件を始める前に使ってよいライセンスの一覧を作っておく方法が参考になります。発表では、許可するライセンスを組み込みリストから指定し、無いものはSPDXライセンス識別子で追加する形が取られています。SPDX識別子は「MIT」のようにライセンスを一意に表す記法なので、自分の基準表も同じ書き方で揃えておくと、後から調べ直す手間が減ります。

個人開発のアプリを公開するエンジニアや、業務システムを納品する開発者には、依存の洗い出し方が参考になります。評価に推移的な依存まで含まれているとおり、自分が直接入れたライブラリだけを見ても足りません。dependency graphとSBOMのエクスポートにライセンス情報が入る改善が示されているので、納品物ごとに部品表を書き出し、ライセンス列を付けて保存しておくと説明資料になります。

開発会社のディレクターや法務の担当者であれば、判断の履歴を残す発想が使えます。ポリシー変更が監査ログのイベントになる仕組みと同じように、「この依存はこの理由で置き換えた」「この依存は例外として残した」と日付付きで残しておけば、後任や取引先への説明がしやすくなります。

会社・チームで使うときのポイント

GitHub Docsでは、大きな組織の進め方として、広いポリシーを中央で定め、レビュー担当にEnterprise Open Source License Managerのロールを割り当て、リポジトリのカスタムプロパティでinactive・evaluate・activeを分類し、その値を対象にしたルールセットで強制の度合いを切り替える形が紹介されています。まずEvaluateモードで注釈だけを集めて実態を把握し、合意ができた範囲からActiveモードに切り替える順番が現実的です。ライセンスの判断は法務と開発の両方に関わるため、誰が承認するかを先に決めておくと運用が止まりません。法人として導入や社内研修を設計するなら、株式会社デジライズに相談できます。同社は法人向けAIリスキリングサービスで導入社数No.1（東京商工リサーチ・2026年3月末時点）で、累計600社超・5万人以上のAI活用を支援しています。

使う前の注意点

この機能はGitHub Enterprise Cloudの顧客向けで、ポリシーを効かせるにはリポジトリにGitHub Code Securityのライセンスが必要です。個人のアカウントや他のプランでそのまま使えるかどうかは、申し込む前に公式のヘルプで最新の提供範囲を確かめてください。運用面では、Evaluateモードのルールセットはマージをブロックしないため、注釈を見落とすと素通りする点に注意が必要です。また注釈は自動で例外申請にならないので、依存を残したい場合は申請して承認を得る手順が別に必要です。ロールの名称は公開プレビュー時の発表と一般提供時の発表で表記が異なるため、設定画面では実際の表示を確認しながら進めるのが安全です。

まとめ

Open source license complianceの一般提供は、OSSのライセンス確認を人の記憶ではなく、決めた基準とチェックの自動化で回す流れを示しています。企業向けの機能ですが、基準表を作り、推移的な依存まで洗い出し、判断を記録するという三段は、個人の納品作業でも今日から再現できます。開発まわりのAI活用を体系的に学ぶなら、デジライズAIスクールのコース一覧から「IT・デジタルのAI活用全体図（職種別｜IT・デジタル）」のような講座を覗いてみてください。デジライズAIスクールは個人向けのオンラインAIスクールで、動画は990本以上あります。

出典

この記事は、各社の公式の発表をもとに AI で下書きし、出典の本文との照合とGoogle 検索による事実確認（ファクトチェック）を通ったものだけを公開しています。