目次 [ close ]
  1. はじめに
  2. 結論：ルールを決めて、プルリクエストで止める機能
  3. 「オープンソースライセンスコンプライアンス」とは？
  4. 使えるのは誰？
  5. どうやってプルリクエストを止める？
    1. 例外を認めたいときは？
    2. GAで追加されたもの
    3. 間接的な依存関係もチェックされる？
  6. 使えない場合はどうする？
    1. Dependency Review Action を使う
    2. ソースコードをスキャンする
  7. よくある勘違い：チェックを通ればライセンスは守れている？
  8. ポリシーはどう決める？
    1. ライセンスの種類ごとに分けて考える
    2. バージョンを区別する
  9. 導入のチェックリスト
  10. まとめ
  11. 関連記事
  12. 参考資料

はじめに

新人君

おっさん、GitHubに依存パッケージのライセンスをチェックしてくれる機能が出たって聞きました。これを使えば、ライセンスのことはGitHubにまかせておけばいいんですよね？

ossan

便利な機能だけど、まかせきりはだめだよ。GitHubがやってくれるのは 決めたルールに合わないものを止めること なんだ。ルールを決めるのも、ライセンスの義務を守るのも、使う側の仕事なんだよ。

この記事では、GitHubの「オープンソースライセンスコンプライアンス（Open source license compliance）」機能で何ができるのか、使えない場合はどうするのか、ポリシーをどう決めればよいのかを整理します。

結論：ルールを決めて、プルリクエストで止める機能

  • 会社で「使ってよいライセンス」のポリシーを決めておくと、合わないライセンスの依存パッケージを追加するプルリクエストを マージ前に止められる
  • 使えるのは GitHub Enterprise Cloud で、GitHub Code Security を有効にしたリポジトリ
  • 機能が止めてくれるのは「ポリシー違反の追加」まで。著作権表示の同梱などの ライセンスの義務は、別に守る必要がある

「オープンソースライセンスコンプライアンス」とは？

コンプライアンス（compliance）は「決まりを守ること」です。この機能は、プロジェクトが使っているOSS（依存パッケージ）のライセンスが、会社の決まりに合っているかをGitHub上でチェックするものです。

たとえるなら、社員食堂の入口に立つ「アレルギー表示のチェック係」のようなものです。「この食材は使わない」という決まりを先に渡しておくと、決まりに合わない料理が出されそうになったときに止めてくれます。ただし、何を禁止にするかを決めるのは、チェック係ではなく食堂の運営側です。

提供の時期は次のとおりです。

  • 2026-06-30：公開プレビューとして提供開始
  • 2026-10-16：一般提供（GA）

使えるのは誰？

GitHub Docs では、次の条件が挙げられています。

  • GitHub Enterprise Cloud（データレジデンシー版を含む）であること
  • リポジトリで GitHub Code Security が有効になっていること
  • 依存関係グラフ（Dependency graph：リポジトリが使っているパッケージを GitHub が一覧にする機能）が有効になっていること

この条件のとおり、個人アカウントや、GitHub Enterprise Cloud 以外のプランでは使えません。対象外の場合の代わりの方法は、後述の「使えない場合はどうする？」で紹介します。

どうやってプルリクエストを止める？

しくみは、大きく次の3つのステップです。

  1. ポリシーを決める：Enterprise（会社全体）の単位で、許可するライセンスを決める。ライセンスは用意された一覧から選び、一覧にないものは SPDX 識別子で追加する
  2. ルールセットで強制する：ルールセット（ブランチへのマージ条件などをまとめて設定するGitHubの機能）に、「Require license compliance results before merging」という条件を入れる。ルールセットは Enterprise・Organization・リポジトリの単位で設定できる
  3. プルリクエストで判定する：依存パッケージを追加・変更するプルリクエストがチェックされ、ポリシーに合わないパッケージには注釈（アノテーション）がつき、マージする前に止まる

SPDX識別子は、MIT や Apache-2.0 のような、ライセンスの決まった短い呼び名です。

💡 ルールセットを「Evaluate（評価）」モードにすると、チェックと注釈だけを行い、マージは止めません。いきなり止めるのが不安なときは、まず Evaluate モードで様子を見てから「Active（有効）」モードに切り替える、という進め方ができます。

例外を認めたいときは？

注釈がついたパッケージは、別のものに置き換える、ポリシーを見直す、例外を認める、のどれかで対応します。

「このパッケージだけは使いたい」という場合は、開発者が理由を書いて申請し、「Enterprise Open-Source License Manager」というロール（役割）の人が承認・却下します。承認するときは、例外をパッケージ単位・ライセンス単位・パッケージ名のパターン単位のどれにするか、また、そのリポジトリだけか Enterprise 全体かを選べます。

ロールが分かれているので、開発者が自分の判断でポリシーをゆるめることはできません。法務や、OSSの管理をする担当者（OSPO：Open Source Program Office）に承認役をまかせる形がとれます。

GAで追加されたもの

  • 監査ログ：ポリシーを変えたときの記録が残る
  • API：ポリシーのダウンロード・更新・置き換えをプログラムから行える
  • API：パッケージがポリシーに合っているかを確認できる。GitHub Changelog では、AIのコーディングエージェントが、ポリシーに合わないパッケージを勧めたり組み込んだりしないようにするための使い道が紹介されています

間接的な依存関係もチェックされる？

はい。GitHub Docs では、自分で直接入れたパッケージだけでなく、そのパッケージが使っている別のパッケージ（間接的な依存関係、推移的依存関係とも呼ぶ）もチェックの対象とされています。ただし、対象になるのは依存関係グラフで検出できたものです。

使えない場合はどうする？

Dependency Review Action を使う

GitHubには、以前から「Dependency Review Action」という GitHub Actions のアクションがあります。プルリクエストで追加される依存パッケージを調べ、許可リストに合わないライセンスがあればチェックを失敗させられます。

# 例：許可するライセンスを SPDX 識別子で並べる
- uses: actions/checkout@v6
- uses: actions/dependency-review-action@v5
  with:
    allow-licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC

README には、次のように書かれています。

  • パブリックリポジトリで使える。プライベートリポジトリで使うには GitHub Advanced Security のライセンスが必要
  • 許可しないライセンスを並べる deny-licenses は、次のメジャーリリースで削除される可能性がある非推奨のオプション。allow-licenses と同時には使えない
  • ライセンスの情報は ClearlyDefined（OSSのライセンス情報を集めているプロジェクト）から取得している
  • ⚠️ ライセンスを検出できなかったパッケージは、知らせてはくれるが、チェックは失敗しない

ブランチ保護やルールセットで、このチェックが通らないとマージできないようにしておけば、似たことができます。

ソースコードをスキャンする

依存パッケージの宣言ではなく、ソースコードそのものに含まれるライセンスを調べたい場合は、scancode-toolkit のようなスキャンツールを使います。使い方はscancode-toolkitの記事で解説しています。

よくある勘違い：チェックを通ればライセンスは守れている？

新人君

チェックが通ったパッケージなら、もう何も気にせず使っていいってことですよね？

ossan

そこがよくある勘違いなんだ。チェックが見ているのは「どのライセンスか」だけ。そのライセンスで決められた義務を守ったかどうかまでは見ていないんだよ。

⚠️ ライセンスチェックが通っても、次のことは別に対応が必要です。

  • ライセンスの義務：たとえばMITライセンスなら、配布するときに著作権表示とライセンス文を含める必要がある
  • 判定に使われるライセンス情報の正しさ：パッケージに書かれたライセンスが、実際のLICENSEファイルと食い違っていることがある
  • ライセンスがわからないパッケージ：ライセンスが書かれていない、または検出できなかったパッケージの扱い。GitHub Docs には、オープンソースライセンスコンプライアンス機能でどう扱うかの記載が見つかりませんでした。Dependency Review Action では、検出できなくてもチェックは失敗しません

パッケージの宣言とLICENSEファイルのどちらを見ればよいかは、OSSライセンスはどこを確認すれば良いのかで解説しています。

ポリシーはどう決める？

ツールは決めたとおりに止めるだけなので、ポリシーの中身がいちばん大事です。ここでは、ポリシーを考えるときの観点を紹介します。どのライセンスを許可するかは、製品の配布のしかたや会社の方針によって変わるので、法務担当者と相談して決めてください。

ライセンスの種類ごとに分けて考える

  • パーミッシブライセンス（MIT、BSD、Apache-2.0 など）：義務が比較的軽く、許可リストに入れることが多い種類です。くわしくはパーミッシブライセンスの記事をご覧ください
  • コピーレフトライセンス（GPL、LGPL、MPL など）：改変したものや組み合わせたものにも同じライセンスを求めるタイプです。製品の配布のしかたによって影響が変わるので、一律に許可・禁止せず、個別に確認する流れにする方法もあります
  • ネットワーク越しの利用にも条件があるライセンス（AGPL など）：SaaSとして提供するだけでもソースコードの提供が必要になる場合があります。くわしくはAGPLライセンスの記事をご覧ください

💡 GitHubの機能のポリシーは「許可するライセンス」を決める形です。「禁止リスト」ではなく「許可リスト」にしておくと、知らないライセンスが入ってきたときに、自動で止まって確認の機会ができます。

バージョンを区別する

GPL-2.0-only と GPL-2.0-or-later のように、同じライセンスでもバージョンの扱いで意味が変わります。許可リストを作るときは、SPDX識別子でバージョンまで区別して書きましょう。

導入のチェックリスト

  • ✅ 自社のプランで機能が使えるか確認する（GitHub Enterprise Cloud ＋ GitHub Code Security ＋ 依存関係グラフ）
  • ✅ 許可するライセンスの一覧を、法務担当者と相談して決める
  • ✅ 例外を承認する人（Enterprise Open-Source License Manager）を決める
  • ✅ まずは Evaluate モードで試し、止まりすぎないか確かめてから Active モードに切り替える
  • ✅ ライセンスがわからないパッケージの扱いを決めておく（ツール任せにせず、人が確認する流れを用意する）
  • ✅ チェックとは別に、著作権表示の同梱などのライセンスの義務を守るしくみを用意する
  • ⚠️ 対象外のプランでは、Dependency Review Action やスキャンツールで代わりのチェックを入れる

まとめ

  • GitHubの「オープンソースライセンスコンプライアンス」は、ポリシーに合わないライセンスの依存パッケージを、プルリクエストの段階で止める機能
  • 使えるのは GitHub Enterprise Cloud ＋ GitHub Code Security。対象外なら Dependency Review Action などで代わりのチェックができる
  • 機能が見るのは「どのライセンスか」まで。ポリシーを決めることと、ライセンスの義務を守ることは人の仕事

新人君

GitHubは「門番」で、ルールを決めたり義務を守ったりするのは僕たちなんですね。

ossan

そのとおり。門番がいれば見落としはぐっと減るから、ルールづくりとセットで上手に使おう。

関連記事

参考資料

この記事の内容は、2026年10月26日時点の情報をもとにしています。GitHubの機能や提供条件は変わることがあるので、導入するときは最新の公式情報をご確認ください。

本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。具体的な案件については、弁護士などの専門家にご相談ください。