ソフトウェアに含まれるオープンソースライセンス：企業が確認すべきこと

自社のソフトウェアには、どんなオープンソースライセンスが含まれているでしょうか。 ほぼすべての最新アプリはオープンソースのライブラリで作られており、それぞれに利用条件を定めるライセンスがあります。多くの経営者はその一覧を見たことがありません。2026年10月16日、GitHubはオープンソースライセンスコンプライアンスを一般提供し、すべてのプルリクエストで自動的にライセンスを確認できるようになりました。

この記事では、依存関係のライセンスが重要な理由、GitHubの新機能の仕組み、そしてソフトウェアを開発するチームに確認すべきことを解説します。

依存関係のライセンスが重要な理由

依存関係とは、コードを一から書く代わりにアプリが使うライブラリのことです。ライブラリ自体にも依存関係があるため、実際の一覧は開発者が直接選んだものよりずっと長くなりがちです。各ライブラリのライセンスは利用できる範囲を定めており、組織は通常、受け入れるライセンスを決めています。

問題はタイミングです。受け入れられないライセンスが監査、資金調達、買収の段階で見つかると、ライブラリの置き換えには時間も費用もかかります。ライブラリを追加した時点で見つければ、コストはほとんどかかりません。

GitHubが公開した機能

• 企業全体のライセンスポリシー。 マージ前にライセンスコンプライアンスの結果を求めるルールセットの条件で有効になります。
• 自動チェック。 プルリクエストで依存関係が追加・変更されるたびに実行され、不適合な依存関係ごとに注記が付きます。
• 専用ロール。 例外申請を確認・承認する担当者向けに、Enterprise Open-Source License Managerが用意されています。
• 依存関係グラフとSBOMエクスポートへのライセンス情報。 データレジデンシーを使うGitHub Enterprise Cloudの顧客にも提供されます。
• 監査ログとAPI。 ポリシーに反するパッケージをコーディングエージェントが推奨しないためのエンドポイントも含まれます。

この機能は、データレジデンシーを含むGitHub Enterprise Cloudの顧客が、GitHub Code Securityを有効にしたリポジトリで利用できます。

依存関係がチェックに通らない場合

GitHubによると、各注記には、依存関係の削除または置き換え、ライセンスポリシーの変更、パッケージの例外作成のいずれかで対応する必要があります。これにより、ライセンス対応は後から行う別プロジェクトではなく、通常のコードレビューの一部になります。

ライセンスチェックは、ほかのパイプラインの安全対策とも相性が良いものです。ワークフローの依存関係を確認済みのコードに固定する方法はCI/CDパイプラインを守る方法の記事で紹介しています。

開発パートナーに確認すべきこと

1. 1ライセンス付きの依存関係一覧を受け取れるか。 たとえば引き渡し時のSBOMエクスポートなど。
2. 2どのライセンスを受け入れているか。 珍しいライセンスは誰が判断するか。
3. 3新しいライブラリの追加時に自動でライセンスを確認しているか。
4. 4リリース後、誰が依存関係を最新に保つか。

これらへの明確な回答は、MVP開発ガイドで解説している範囲やスケジュールと並んで、健全なプロジェクトの一部です。

ビジネスへの影響

ソフトウェアを発注すると、その構成要素もすべて引き継ぐことになります。アプリの中身を把握し、ライブラリを追加するたびにライセンスを確認することで、監査、資金調達、買収の際の高くつく想定外の事態を防げます。

Estontincのサポート

Estontincはマラン（インドネシア）のソフトウェア開発会社で、6年以上にわたり100件以上のプロジェクトと50社以上のクライアントを支援してきました。カスタムソフトウェアサービスではプロジェクトとともに依存関係の一覧をお渡しし、リリース後もライブラリを保守します。クラウド・DevOpsチームは、パイプラインに依存関係とライセンスの自動チェックを組み込みます。

アプリの中身を知りたい場合は、お問い合わせページからお聞かせください。24時間以内にご返信します。