AI・OSS・SBOM

なぜOSS・AI・SBOMが重要か

2020年のSolarWinds事案を契機に、ソフトウェアサプライチェーンのセキュリティが企業の重要課題となりました。製品・システムの大半にOSSコンポーネントが含まれているにもかかわらず、管理が放置されているケースが多く、GPL違反が発覚した場合は製品の販売差し止めや訴訟に発展するリスクがあります。

OSSライセンスの種別とリスクプロファイル

OSSライセンスには多様な種別があり、商用利用時の法的義務が大きく異なります。組織として「ホワイトリスト（承認）」「グレーリスト（法務確認要）」「ブラックリスト（禁止）」を定義し、開発チームが明確な判断基準を持てるようにします。

ライセンス種別	代表例	主な条件・法的義務	商用利用リスク
強いコピーレフト	GPL v2/v3	派生物（改変・組み込みを含む）にも同一ライセンスを適用してソース公開義務あり	高：自社コードの開示義務リスク
弱いコピーレフト	LGPL v2.1/v3、Mozilla	ライブラリとしてリンクする場合は自社コードの開示義務なし。ただし改変部分は公開が必要	中：適切な利用方法の管理が必要
Permissive A	Apache 2.0	著作権表示・免責事項の保持。特許条項あり（特許権の明示的許諾と報復条項）	低：著作権表示の省略は違反
Permissive B	MIT、BSD	著作権表示と免責事項の保持のみ要求。最も制約が少ない	最低：商用製品組み込みに最適

OSSガバナンスの実装

組織としてOSSを安全に活用するためには、ガバナンスの仕組みを開発プロセスに組み込む必要があります。

• OSSポリシーの策定：組織として許容するOSSライセンス種別のホワイトリスト・グレーリスト・ブラックリストを定義し、開発チームが明確な判断基準を持てるようにします。
• SCAツールの導入：WhiteSource/Mend・Black Duck・FOSSA・OSS Reviewなどのソフトウェア構成分析（SCA）ツールをCI/CDパイプラインに組み込み、依存するOSSコンポーネントのライセンスを自動検出・評価します。
• ライセンス互換性管理：複数のOSSコンポーネントを組み合わせる際のライセンス互換性（例：GPL v2とApache 2.0の非互換）を評価するプロセスを整備します。
• 定期監査：年次以上の頻度で、製品・システムに含まれるOSSコンポーネントのライセンス状況を全面的に棚卸しし、新たな脆弱性やライセンス変更に対応します。
• SBOMとの連携：SCAツールの出力をSBOM（第7章参照）に統合し、サプライチェーンセキュリティ管理とライセンスコンプライアンス管理を一体化します。

OSSライセンス互換性マトリックス

複数のOSSコンポーネントを組み合わせる場合、ライセンスの互換性を事前確認することが必須です。特にGPL v2とApache 2.0の組み合わせは条件付き互換となるため、法務部門との連携が必要です。

	GPL v2	GPL v3	LGPL v2.1	Apache 2.0	MIT / BSD
GPL v2	○	×	○	△	○
GPL v3	×	○	○	○	○
LGPL v2.1	○	○	○	○	○
Apache 2.0	△	○	○	○	○
MIT / BSD	○	○	○	○	○

○ 互換（組み合わせ可） × 非互換（組み合わせ不可） △ 条件付き互換（法務確認要）※本表は一般的なガイダンスであり、法的判断には専門家への相談を推奨します。

生成AIツールのライセンス管理

GitHub Copilot・Microsoft 365 Copilot・Claude Enterprise・Google Gemini for Workspaceなどの生成AIツールは急速に組織内に普及しており、従来のソフトウェアライセンスとは質的に異なる管理上の問題を含んでいます。

特性	管理上の考慮点
課金モデルの多様性	ユーザーシート課金（月額固定）・APIトークン消費量課金・ハイブリッド型が混在。実際のAPI使用量と予算を継続的に照合する仕組みが必要
知的財産帰属条件	AIが生成したコード・文書の著作権がユーザーに帰属するか否かはベンダーの利用規約によって異なる。入力データのモデル学習への利用可否も契約ごとに確認が必要（Enterprise契約では通常、学習利用を禁止）
データ処理条件	企業機密・個人情報を含むデータをAIに入力する際の処理条件（クラウド上での保存期間・データ残留地域・サードパーティ共有の有無）を契約で確認し、情報セキュリティポリシーとの整合性を検証
利用ポリシー管理	AIツールの使用が許容される業務範囲（顧客データの入力禁止等）を定めた社内ポリシーを策定し、DLP（データ損失防止）との組み合わせで遵守を担保

AI管理の実装フレームワーク

組織が生成AIツールを安全に活用するためには、台帳管理・ガバナンス委員会・コスト管理の3つの柱が必要です。

AI規制動向と証跡管理要件

各国・地域でAI利用に関する規制とガイドラインが整備されています。SLAMのAI管理フレームワークはこれらの規制要件と整合した設計が求められます。

規制/ガイドライン	発効状況	SLAM上の主な対応義務
EU AI Act（欧州AI法）	2024〜26年 段階的施行	高リスクAIは技術文書・使用記録・人間監視の義務。リスク分類に基づき組織内AIツールを分類管理する台帳を整備。高リスクAIの利用記録は最低10年保管。
NIST AI RMF	2023年公開（任意適用）	GOVERN/MAP/MEASURE/MANAGEの4機能に沿ったAIリスク管理体制の構築。米国政府調達への参加企業に事実上の要件化が進む。
経産省・内閣府AIガイドライン	2024年版（任意適用推奨）	AI利用方針の策定・従業員への教育・利用記録の保持を推奨。生成AIの出力検証プロセスの整備。
GDPR 第22条	適用中（EU関連業務）	自動化された意思決定に対する異議申し立て権の保障。AIによる個人への重大な影響を伴う決定に人間の判断を介在させるプロセスの設計。

SBOMとソフトウェアサプライチェーンセキュリティ

SBOM（Software Bill of Materials：ソフトウェア部品表）は「ソフトウェアを構成するすべてのコンポーネント（ライブラリ・フレームワーク・OSS・サードパーティ製品）のリスト」であり、ITAMシステムが管理するソフトウェアインベントリの詳細版として位置付けられます。2020年のSolarWinds事案以降、米国では大統領令14028（2021年）においてSBOMの整備が政府調達ソフトウェアに義務付けられ、この潮流は民間企業にも急速に波及しています。