「うちのシステム、どんなオープンソースを使ってるか把握してますか？」――この問いに即答できる中堅企業は、ほとんどない。 現代のシステムは、自社で書いたコードよりも、OSS（オープンソースソフトウェア）の部品（ライブラリ・フレームワーク）の方が圧倒的に多い。AI コーディングツールが OSS を多用したコードを生成する時代、どの OSS を・どのライセンスで・どのバージョンで使っているかを把握する「OSS ガバナンス」が、中堅企業（年商 30-300 億）の見えないリスクになっている。
IPA の 2025 年度オープンソース推進レポートは、国内企業 362 社の調査や世界 7 か国・30,298 リポジトリの比較を踏まえ、日本の OSS 推進の現在地と次の一手を示している（IPA「2025年度オープンソース推進レポート」）。
本記事は、OSS ガバナンスが重要になる 5 つの理由、ライセンス違反・脆弱性・保守放棄の 3 大リスク、SBOM（ソフトウェア部品表）と依存管理、開発会社に確認すべき OSS ガバナンス 8 項目、よくある失敗、FAQ を一次ソースとともに整理する。
目次
- OSS ガバナンスとは何か
- IPA 推進レポートが示す日本の OSS 現在地
- OSS ガバナンスが重要になる 5 つの理由
- OSS の 3 大リスク：ライセンス違反 / 脆弱性 / 保守放棄
- SBOM（ソフトウェア部品表）と依存管理
- 開発会社に確認すべき OSS ガバナンス 8 項目
- OSS ガバナンスでよくある失敗 6 パターン
- よくある質問（FAQ 10 問）
- 参考一次ソース
OSS ガバナンスとは何か
OSS ガバナンスとは、システムで使用しているオープンソースソフトウェアを 把握・管理・統制する仕組みのことだ。具体的には：
- どの OSS を使っているか（インベントリ把握）
- 各 OSS のライセンスは何か（ライセンス管理）
- 各 OSS にセキュリティ脆弱性はないか（脆弱性管理）
- 各 OSS はメンテナンスされているか（保守性評価）
現代のシステムは、自社コードより OSS 部品の方が圧倒的に多い。一般的な Web アプリケーションは、数百〜数千の OSS ライブラリに依存している。それらを把握せず使うことは、**「中身が分からない部品で建物を建てる」**ようなものだ。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
IPA 推進レポートが示す日本の OSS 現在地
IPA の 2025 年度オープンソース推進レポート（IPA 公式）は、国内企業 362 社の調査と世界 7 か国・30,298 リポジトリの比較を踏まえ、日本の OSS 推進の現在地を分析している。
レポートの主要論点
- 日本企業の OSS 活用・貢献の現状と国際比較
- OSS のセキュリティ・保守性・ガバナンスの課題
- 日本が「次の一手」として取るべき OSS 推進の方向性
※具体的な数値・比較結果は IPA 公表レポート原典を必ず参照のこと。本記事は中堅企業の OSS ガバナンス実務の文脈で論点を整理する。
中堅企業にとっての含意
OSS は「無料で使える便利な部品」だが、使いっぱなしではリスクが蓄積する。特に AI コーディングツールが OSS を多用したコードを生成する時代、「気づかないうちに大量の OSS に依存し、ライセンス・脆弱性・保守のリスクを抱える」状態に陥りやすい。
OSS ガバナンスが重要になる 5 つの理由
理由 1: AI 生成コードが OSS を多用する
AI コーディングツールは、既存の OSS ライブラリを活用したコードを生成する。開発者が意識せずに大量の OSS 依存が増える。どの OSS を使っているか把握しないと、リスクが見えない。
理由 2: ライセンス違反は法的リスク
OSS には様々なライセンス（MIT / Apache / GPL / AGPL 等）がある。GPL 系を商用製品に組み込むと、自社コードの公開義務が生じる場合がある。知らずに使うと法的トラブルになる。
理由 3: 脆弱性が攻撃ベクタになる
OSS の既知脆弱性（CVE）を放置すると、攻撃者の侵入口になる。連載でも扱う Veeam / Log4j 等、OSS 脆弱性起因のインシデントは多発している。
理由 4: メンテ放棄された OSS は時限爆弾
メンテナンスが止まった OSS（開発者が離れた、プロジェクトが終了した）を使い続けると、脆弱性が出ても修正されない。依存先の健全性評価が必要。
理由 5: SBOM が取引・調達の要件に
**SBOM（Software Bill of Materials = ソフトウェア部品表）**の提出が、取引先・調達の要件になりつつある。米大統領令でも政府調達で SBOM が要求される流れ。SBOM を出せないと取引機会を失うリスク。
OSS の 3 大リスク：ライセンス違反 / 脆弱性 / 保守放棄
リスク 1: ライセンス違反
OSS ライセンスの主な種類：
| ライセンス | 特徴 | 商用利用時の注意 |
|---|---|---|
| MIT / BSD / Apache | 寛容（permissive） | 著作権表示すれば自由 |
| LGPL | 弱コピーレフト | 動的リンクなら比較的自由 |
| GPL | 強コピーレフト | 組み込むと自社コード公開義務 |
| AGPL | 最強コピーレフト | SaaS でも公開義務（ネットワーク利用含む） |
典型的な違反: GPL / AGPL の OSS を商用製品に組み込み、ソースコード公開義務に気づかず違反。AI 生成コードに GPL コードが混入するリスクもある。
リスク 2: 脆弱性（CVE）
OSS の既知脆弱性を放置すると侵入口になる。代表例：
- Log4j（Log4Shell, 2021）: Java ログライブラリの脆弱性で世界的な大騒動
- 各種フレームワーク・ライブラリの CVE: 定期的に発見される
対策: 依存ライブラリの脆弱性スキャン（Dependabot / Snyk / Trivy）+ 迅速なアップデート。
リスク 3: 保守放棄（メンテ停止）
メンテナンスが止まった OSS は、脆弱性が出ても修正されない。評価指標：
- 最終コミット日（直近にメンテされているか）
- メンテナー数（1 人依存は危険）
- Issue / PR の対応状況
- スター数・利用実績
OpenSSF（Open Source Security Foundation）の Scorecard 等で OSS の健全性を評価できる。
SBOM（ソフトウェア部品表）と依存管理
SBOM とは
**SBOM（Software Bill of Materials）**は、ソフトウェアに含まれる全 OSS 部品の一覧（部品表）。製造業の BOM（部品表）のソフトウェア版。
参考: 経済産業省「ソフトウェア管理に向けた SBOM の導入に関する手引」 / NTIA SBOM
SBOM で分かること
- システムが依存する全 OSS とそのバージョン
- 各 OSS のライセンス
- 各 OSS の既知脆弱性
- 依存の依存（推移的依存）まで
SBOM の作り方
- 自動生成ツール: Syft / CycloneDX / SPDX ツール
- CI/CD パイプラインに組み込み、ビルドのたびに SBOM 生成
- 脆弱性スキャン（Grype / Trivy）と連携
中堅企業の SBOM 導入ステップ
- 既存システムの依存ライブラリを棚卸（package.json / composer.json / requirements.txt 等）
- SBOM 生成ツールを CI に組み込み
- 脆弱性スキャンを定期実行
- ライセンスチェックを自動化
- 取引先からの SBOM 要求に対応できる体制
開発会社に確認すべき OSS ガバナンス 8 項目
システム開発を外注する際、OSS ガバナンスについて確認すべき 8 項目。
□ 1. 使用 OSS のインベントリ（一覧）を納品物に含むか
□ 2. SBOM（ソフトウェア部品表）を提供できるか
□ 3. OSS ライセンスのチェック（GPL/AGPL 混入確認）を実施するか
□ 4. 依存ライブラリの脆弱性スキャン（Dependabot/Snyk/Trivy）を実施するか
□ 5. OSS のアップデート方針（脆弱性対応）を提示するか
□ 6. メンテ放棄 OSS を避ける選定基準があるか
□ 7. AI 生成コードへの GPL コード混入チェックを行うか
□ 8. 保守契約に OSS 脆弱性対応が含まれるか
「OSS は無料だから安い」だけで開発会社を選ぶと、ライセンス違反・脆弱性放置・保守放棄のリスクを抱える。OSS ガバナンスまで考えた開発会社を選ぶ。
OSS ガバナンスでよくある失敗 6 パターン
- 使用 OSS を把握していない: 何を使っているか分からず、リスクが見えない
- ライセンス未確認: GPL/AGPL を商用に組み込み、公開義務違反
- 脆弱性放置: CVE が出ても更新せず、攻撃ベクタに
- メンテ放棄 OSS への依存: 修正されない OSS を使い続ける
- SBOM 不在: 取引先の SBOM 要求に対応できず機会損失
- AI 生成コードの無検証: GPL コード混入・脆弱ライブラリ採用に気づかない
よくある質問（FAQ 10 問）
Q1. OSS は無料だからリスクはない？
A. 無料でも法的・セキュリティ・保守のリスクがある。ライセンス違反・脆弱性・メンテ放棄の 3 大リスクを管理する必要がある。
Q2. GPL の OSS は使ってはいけない？
A. 使い方による。社内ツールなら問題ないことが多いが、商用製品に組み込んで配布する場合は公開義務が生じる可能性。用途とライセンスを確認。
Q3. SBOM は中堅企業にも必要？
A. 取引先・調達で要求されつつあるので、対応できる体制が望ましい。まず使用 OSS の棚卸から始める。
Q4. AI 生成コードのライセンスは大丈夫？
A. 確認が必要。AI が学習データの GPL コードに似たコードを生成する懸念がある。ライセンスチェック + コードレビューで対応。
Q5. OSS の脆弱性はどう管理する？
A. Dependabot（GitHub）/ Snyk / Trivy 等で依存ライブラリを自動スキャン、CVE が出たら迅速にアップデート。
Q6. メンテ放棄 OSS を見分けるには？
A. 最終コミット日 / メンテナー数 / Issue 対応状況 / OpenSSF Scorecard 等で健全性を評価。1 人メンテ・更新停止は要注意。
Q7. 既存システムの OSS を今から把握できる？
A. できる。package.json / composer.json / requirements.txt 等から依存ライブラリを抽出、SBOM ツールで一覧化、脆弱性スキャン。
Q8. OSS ガバナンスのコストは？
A. ツール（Snyk / Dependabot 等）は無料枠もあり。SBOM 生成ツールは OSS。導入工数は数日〜。リスク（違反・侵害）と比べれば安い。
Q9. 保守契約に OSS 対応を含めるべき？
A. 含めるべき。OSS 脆弱性は継続的に発見されるため、保守契約に「依存ライブラリの脆弱性監視・対応」を明記。
Q10. 中小企業でも OSS ガバナンスは必要？
A. 必要。規模を問わず、使っている OSS のライセンス・脆弱性は管理すべき。まず棚卸から。
参考一次ソース
- IPA「2025年度オープンソース推進レポート：世界の潮流と日本の現在地」
- 経済産業省「ソフトウェア管理に向けた SBOM の導入に関する手引」
- OpenSSF（Open Source Security Foundation）
- OpenSSF Scorecard
- IPA「情報セキュリティ10大脅威 2026」
- NIST「Software Supply Chain Security」
まとめ
- 現代のシステムは自社コードより OSS 部品が圧倒的に多く、AI 生成コードがそれを加速
- IPA 2025 OSS 推進レポート（362 社調査 / 世界 7 か国比較）が日本の OSS 現在地と課題を提示
- OSS の 3 大リスク = ライセンス違反 / 脆弱性 / 保守放棄
- SBOM（部品表）+ 脆弱性スキャン + ライセンスチェックで管理、開発会社には 8 項目を確認
OSS は強力な武器だが、ガバナンスなしで使うと見えないリスクが蓄積する。AI 時代こそ「何を使っているか」を把握する体制が問われる。
OSS ガバナンスを考えた開発・保守を相談したい方へ
GXO株式会社は、中堅企業向けに 保守性・セキュリティ・ライセンス管理まで考えたシステム開発を提供しています。
- OSS インベントリ + SBOM 整備: 使用 OSS の棚卸と部品表作成
- ライセンスチェック: GPL/AGPL 混入の確認、商用利用の適合性評価
- 脆弱性管理: 依存ライブラリの自動スキャン + 迅速なアップデート
- 保守契約: OSS 脆弱性の継続監視・対応を含む保守
著者: GXO株式会社 初回公開: 2026 年 5 月 22 日