package.jsonを読み込み、node_modulesフォルダを選択するだけで、依存パッケージのライセンス一覧、 ライセンス表記文、CycloneDX・SPDX形式のSBOMを自動生成します。
このツールはブラウザの中だけで動いています。入力した内容が、外部に送信されることはありません。入力内容は外部に送信されません。
詳しく1. package.json を読み込む
OSSライセンス管理とSBOM作成が必要な理由（EUサイバーレジリエンス法対応）
npmパッケージを使ったアプリケーションには、数十〜数千のオープンソースライブラリが依存関係として組み込まれています。それぞれがMIT・Apache-2.0・GPLなど異なるライセンスを持っており、商用製品として出荷する際には、各ライセンスが定める表記義務やソースコード開示義務を遵守する必要があります。さらに、2027年12月から本格適用が予定されるEUサイバーレジリエンス法（CRA）では、EU市場にデジタル製品を出荷するメーカーに対してSBOM（ソフトウェア部品表）の整備が求められる見込みで、ライセンス管理とSBOM作成の両方に対応できる体制作りが急務になっています。
本ツールは、package.jsonの読み込みと、node_modulesフォルダの選択（ブラウザ内でのローカル読み取り）だけで、依存パッケージのライセンス一覧、アプリに同梱するライセンス表記文（NOTICE / LICENSES.txt）、そしてCycloneDX・SPDX形式のSBOM（JSON）を自動生成するオンラインツールです。GPL系などのコピーレフトライセンスを検出して警告表示するほか、テスト・ビルド時にのみ使うdevDependenciesを出力から除外する切り替えにも対応しています。
データはすべてブラウザ内で処理され、外部サーバーへ送信されることはありません。社外秘のプロジェクトであっても、安心してライセンス棚卸しとSBOM作成の準備を進められます。
こんなシーンで便利です
製品出荷前のOSSライセンス棚卸しに
アプリや組み込み機器の出荷前に、使用しているOSSのライセンス種別を一覧化し、商用利用やGPL系ライセンスの混入がないかを確認する作業に使えます。
EUサイバーレジリエンス法などの規制対応準備に
EUに製品を出荷するメーカーの品質・法務担当者が、SBOM整備の義務化（2027年12月〜）に先立って、CycloneDX・SPDX形式のSBOM作成フローを事前に検証する際に活用できます。
アプリのクレジット表記（ライセンス表記画面）作成に
モバイルアプリの「ライセンス情報」画面やWebサービスのフッターに掲載するOSSクレジット表記文を、依存パッケージ一覧からそのまま生成できます。
OSS利用申請・社内レビューの提出資料作りに
社内のOSS利用申請フローや取引先からの監査対応で、依存パッケージとライセンスの一覧表、SBOMファイルの提出を求められた際の一次資料として活用できます。
使い方は簡単 4ステップ
- プロジェクトの package.json の内容を貼り付け、またはファイルをアップロードします。
- （推奨）「node_modulesフォルダを選択」から、インストール済みのnode_modulesフォルダをブラウザ内で読み込みます。各パッケージの正確なライセンス情報が自動検出されます。
- 一覧でライセンスが「UNKNOWN」のパッケージがあれば、ドロップダウンまたは自由入力で手動補完します。devDependenciesを含めるかどうかも切り替えられます。
- 「ライセンス表記」タブで表記文を、「SBOM生成」タブでCycloneDX・SPDX形式のファイルをそれぞれダウンロードします。
※node_modulesの読み込みはブラウザのローカルファイル読み取り機能を使用しており、内容が外部に送信されることはありません。
ご利用時の注意点
- ライセンス判定の限界：package-lock.json単体にはライセンス情報が含まれないことが多いため、正確な判定にはnode_modulesフォルダの選択を推奨します。選択しない場合、多くのパッケージが「UNKNOWN」として表示されます。
- 法的判断について：本ツールが検出・分類するライセンス情報やコピーレフト警告は目安です。実際のライセンス遵守義務の判断は、必ず自社の法務担当者または弁護士にご確認ください。
- SBOMの仕様準拠について：生成されるSBOMはCycloneDX・SPDXの一般的な構造に沿って作成される一次出力です。提出先が公式バリデータでの検証を求める場合は、別途ご確認のうえご利用ください。
- 完全無料・安全：package.jsonやnode_modulesの内容は外部サーバーに送信されない、通信が発生しないブラウザ完結型の設計です。
代表的なOSSライセンスの特徴比較表
依存パッケージのライセンスを確認する際に押さえておきたい、代表的なライセンスの性質の違いです。最終的な法的判断は専門家にご確認ください。
| ライセンス | 分類 | 商用利用 | ソースコード開示義務 | 特徴 |
|---|---|---|---|---|
| MIT | 寛容型（permissive） | 可 | なし | 最も普及している短い許諾文。表記のみで利用可能 |
| Apache-2.0 | 寛容型（permissive） | 可 | なし | 特許条項を含む。改変時の変更内容の明示が必要 |
| BSD-3-Clause | 寛容型（permissive） | 可 | なし | 著作者名を使った宣伝の制限条項を含む |
| ISC | 寛容型（permissive） | 可 | なし | MITとほぼ同等の簡潔な許諾文 |
| LGPL-3.0 | 弱いコピーレフト | 可（条件付き） | ライブラリ部分のみ | 動的リンクであれば自社コードの開示義務は限定的 |
| GPL-3.0 | 強いコピーレフト | 可（条件付き） | 組み込んだ全体に及ぶ可能性 | 組み込み方によっては自社コードの開示義務が発生 |
| AGPL-3.0 | 強いコピーレフト | 可（条件付き） | ネットワーク経由の利用も対象 | SaaS提供時も開示義務が及びうる点に特に注意 |
【コピーレフトライセンスへの注意】
GPL・AGPL・LGPLなどのコピーレフト系ライセンスは、組み込み方（静的リンク／動的リンク、改変の有無など）によって義務の及ぶ範囲が変わります。
※本表は一般的な傾向を示す参考情報であり、個別のライセンス全文・バージョン差異・組み込み方法によって義務の内容は異なります。最終判断は必ず法務担当者・弁護士にご確認ください。
SBOM・OSSライセンス管理の実務知識
EUサイバーレジリエンス法をはじめとする規制対応や、実務でのライセンス管理に役立つ基礎知識を解説します。
結論：まずライセンス一覧の可視化から着手し、SBOM生成はその延長線上で行う
SBOMという言葉だけが先行しがちですが、実務的には「自社製品にどのOSSが、どのライセンスで含まれているか」を正確に一覧化することが全ての出発点です。
一覧化ができていれば、CycloneDXやSPDXといった標準フォーマットへの変換は機械的に行えるため、まずはpackage.jsonとnode_modulesからの正確なライセンス収集を優先し、SBOM生成はその成果物として捉えるのが実務上スムーズです。
EUサイバーレジリエンス法（CRA）とSBOM義務化の概要
EUサイバーレジリエンス法は、EU市場で販売されるデジタル要素を含む製品全般にサイバーセキュリティ対策を義務付ける規則で、主要な義務規定は2027年12月11日から適用開始が予定されています。
対象製品のメーカーには、脆弱性管理の一環としてSBOM（ソフトウェア部品表）の作成・保持が実務上の前提として位置付けられており、出荷後に発見された脆弱性が自社製品に影響するかを迅速に判断する基盤として活用されます。適用範囲や具体的な義務内容は製品分類によって異なるため、対象製品を扱う場合は必ず最新の公式情報・専門家の見解をご確認ください。
CycloneDXとSPDX、2つの標準フォーマットの違い
CycloneDXはOWASPが主導して策定したフォーマットで、脆弱性情報（VEX）との連携や依存関係の構造表現に強みがあり、セキュリティ運用との親和性が高いのが特徴です。
SPDXはLinux Foundation配下で標準化された、国際標準（ISO/IEC 5962）にもなっているフォーマットで、ライセンスコンプライアンスの文脈で長く使われてきた実績があります。
取引先や規制当局からの指定がない場合は、両方を生成しておき、提出時に必要な形式を選ぶ運用が実務的には安全です。
node_modulesのライセンス情報が信頼できないケースへの対処
一部のパッケージはpackage.jsonにlicenseフィールドを記載していなかったり、LICENSEファイルの内容と食い違っていたりすることがあります。本ツールで「UNKNOWN」と表示されたパッケージについては、パッケージのリポジトリやnpmの配布ページを個別に確認し、手動でライセンスを補完することをおすすめします。
件数が多い場合は、まずダウンロード数の多い主要な依存パッケージから優先的に確認すると、限られた時間で実務上のリスクを効率よく洗い出せます。
よくある失敗と対策
package-lock.jsonだけを見てライセンスを「確認済み」と判断してしまう
package-lock.jsonにはパッケージのバージョンや取得元URLは記録されていますが、ライセンス情報自体は含まれていないことがほとんどです。lockファイルの中身を目視しただけでライセンス確認を終えたことにしてしまうと、実際には未確認のまま製品を出荷してしまう失敗につながります。
💡 対策・解決策を見る▼
devDependenciesまで含めた厳しすぎるライセンス一覧を取引先に提出してしまう
テストツールやビルドツールなどdevDependenciesに含まれるOSSまで一律にSBOMやライセンス一覧へ含めてしまい、実際には製品に組み込まれていないパッケージについてまで不要な確認・問い合わせが発生してしまうケースです。
💡 対策・解決策を見る▼
GPL系ライセンスの混入に気づかないまま商用製品に組み込んでしまう
依存関係の数が多いプロジェクトでは、間接的に（他のパッケージ経由で）GPLやAGPLなどのコピーレフトライセンスのパッケージが紛れ込んでいても見落としがちです。配布後に指摘を受けてから対応すると、対象パッケージの差し替えや開示対応に大きなコストがかかります。
💡 対策・解決策を見る▼
SBOMを一度作成しただけで更新せず、実態と乖離した状態で保持してしまう
製品出荷時に一度SBOMを作成したものの、その後の依存パッケージのバージョンアップやライブラリの追加・削除を反映せず、古いSBOMをそのまま保持し続けてしまう失敗です。脆弱性対応の際に実態と異なるSBOMを参照すると、影響範囲の判断を誤るリスクがあります。
💡 対策・解決策を見る▼
よくある質問（FAQ）
Q.SBOM（ソフトウェア部品表）とは何ですか、なぜ必要なのですか
A. SBOM（Software Bill of Materials）とは、ソフトウェアに含まれるオープンソースを含む全ての構成部品（ライブラリ・バージョン・ライセンス等）を一覧化した明細書です。脆弱性が発見された際に自社製品への影響範囲を迅速に特定したり、ライセンス遵守状況を証明したりする目的で作成されます。EUサイバーレジリエンス法（CRA）など、デジタル製品を扱うメーカーにSBOMの保持・提供を求める規制が各国で整備されつつあり、出荷前の準備として作成しておく重要性が高まっています。
Q.CycloneDXとSPDXはどちらを使えばよいですか
A. どちらもSBOMの標準フォーマットですが、提出先によって指定が異なります。CycloneDXはOWASPが策定し脆弱性管理ツールとの連携に強みがあり、SPDXはLinux Foundationが策定しライセンスコンプライアンス用途で広く使われています。取引先や規制当局から形式の指定がある場合はそれに従い、指定がない場合はまずCycloneDXから着手するのが実務上一般的です。本ツールでは同じ依存関係データから両形式を同時に生成できるため、提出先が変わっても作り直す必要はありません。
Q.package.jsonだけでライセンス情報は正確に分かりますか
A. package.jsonやpackage-lock.jsonには、依存パッケージ自体のライセンス情報が含まれていないことがほとんどです。正確なライセンスを取得するには、実際にインストールされた各パッケージのpackage.json（node_modules内）に記載されたlicenseフィールドを読み取る必要があります。本ツールでは「node_modulesフォルダを選択」する機能により、ブラウザ上でローカルのpackage.jsonを直接読み取り、外部に送信することなく正確なライセンス情報を取得します。
Q.node_modulesフォルダを選択すると、中身がサーバーにアップロードされますか
A. 一切アップロードされません。本ツールはブラウザのファイル選択API（ディレクトリ選択）を使ってローカルのファイルを直接読み込み、JavaScriptの処理だけでライセンス情報を抽出します。読み込んだファイルの内容が外部のサーバーへ送信されたり、どこかに保存されたりすることはないため、社外秘のプロジェクトでも安心して利用できます。
Q.GPLなどのコピーレフトライセンスが混ざっているとどうなりますか
A. GPL・AGPL・LGPLなどのコピーレフト系ライセンスは、自社ソフトウェアに組み込んで配布する際にソースコードの開示義務などが発生する場合があります。本ツールは依存関係の一覧上でコピーレフト系ライセンスを検出すると警告バッジを表示しますので、該当パッケージが商用利用の方針に問題ないか、法務担当者と事前に確認することをおすすめします。ライセンスの法的解釈については、必ず自社の法務担当者または弁護士にご確認ください。
Q.devDependencies（開発用の依存関係）もSBOMに含めるべきですか
A. 一般的には、実際に製品に組み込まれて出荷される依存関係（dependencies）のみをSBOMの対象とし、テストやビルド時にのみ使用するdevDependenciesは対象外とすることが多いです。本ツールにはdevDependenciesの含める／除外するを切り替えるトグルを用意しているため、提出先の要件に合わせて出力内容を調整できます。
Q.生成したSBOMやライセンス表記文は、そのまま提出・公開しても問題ありませんか
A. 本ツールが生成するSBOM・ライセンス表記文は、入力されたpackage.jsonやnode_modules内の情報をもとにした一次的な出力であり、公的な認証や監査を保証するものではありません。実際に取引先への提出や製品への同梱を行う前に、ライセンスが不明（UNKNOWN）のまま残っているパッケージがないか、内容に誤りがないかを必ず確認し、必要に応じて法務担当者のレビューを受けてください。
あなたの声で、
このツールをより鋭く。
「こんな機能が欲しい」「ここを直してほしい」といったご意見や、新しいツールのリクエストを募集しています。エンジニアが直接目を通し、開発の参考にさせていただきます。