OSSの「使える」とAPIの「つながる」を、事業として「使い続けられる」に変える契約・運用設計
OSS（オープンソースソフトウェア）や外部APIは、現代のSaaS・FinTech・Webサービスの開発に欠かせない存在です。自社でゼロから実装するよりも高速に機能を追加できる一方、導入時の技術判断だけで利用を決めると、リリース直前や資金調達・M&Aのデューデリジェンスで、ライセンス義務や外部サービス依存が顕在化することがあります。
OSSと外部APIは、いずれも「外部の技術を利用する」という点では共通しますが、法的な問題は同じではありません。OSSでは著作権者が付したライセンス条件を、どのコードをどのように改変・結合・配布するかに即して確認する必要があります。外部APIでは、API提供者の利用規約・個別契約・SLA・データ条件が、自社サービスの継続性や顧客への約束をどこまで支えられるかが問題になります。
結論｜確認すべきポイントは「ライセンス名」や「APIの有無」だけではありません
OSSは、ライセンスの種類に加えて、バージョン、改変の有無、他のコードとの結合方法、配布の有無、ネットワーク経由の利用形態まで確認します。
外部APIは、利用可能範囲、料金・レート制限、データの利用条件、仕様変更・廃止、SLA、責任制限、終了時のデータ移行まで確認します。
最も重要なのは、導入時の一回限りのレビューではなく、依存コンポーネントとAPI規約の変更を継続的に追跡できる運用です。
1．OSSと外部APIでは、リスクの発生源が異なる
OSSのリスクは、主として著作権者がソフトウェアの利用・複製・改変・配布等を許諾する際に付したライセンス条件から生じます。これに対し、外部APIのリスクは、API提供者との契約条件と、提供者のシステムに事業が依存することから生じます。両者を「外部ライブラリ」と一括管理すると、確認項目が抜けやすくなります。
| 区分 | 主な法的・実務的論点 | 典型的な確認資料 |
|---|---|---|
| OSS | ライセンス条件、著作権表示、ソースコード提供、特許条項、ライセンス互換性、脆弱性 | LICENSE、NOTICE、COPYING、リポジトリ、依存関係情報 |
| 外部API | 利用許諾範囲、商用利用、データ利用、レート制限、仕様変更、SLA、免責・責任、停止・終了 | API Terms、Developer Terms、個別契約、SLA、DPA、料金表、仕様書 |
| 共通 | 変更管理、担当者、台帳、リリース判定、障害・終了時の代替策 | 社内ポリシー、SBOM・依存台帳、契約台帳、変更履歴 |
2．OSSは「無料のコード」ではなく、条件付きで利用を許諾されたソフトウェア
OSSは、無償で取得できることと、無条件に利用できることが同義ではありません。公開リポジトリにソースコードが置かれていても、明確なライセンスが付されていなければ、当然に自由利用できるとは限りません。IPAも2026年のガイドブックで、GitHub等にあるコードを「フリー素材」と考えることは誤解であると注意喚起しています。
実務では、ライブラリ名だけでなく、利用している「バージョン」と、そのバージョンに適用されるライセンスを記録します。同じプロジェクトでも、バージョンアップでライセンスが変わる場合や、複数ライセンスから選択できるデュアルライセンス方式が採られる場合があるためです。
3．主要なOSSライセンスを「公開義務の強弱」だけで判断しない
OSSライセンスは、一般にパーミッシブ型、弱いコピーレフト、強いコピーレフトなどに整理されます。ただし、「MITなら安全」「GPLなら危険」という単純なラベルで判断するのは適切ではありません。利用形態と各ライセンスの具体的な条件を対応させる必要があります。
| ライセンス例 | 基本的な特徴 | 実務上の主な確認点 |
|---|---|---|
| MIT / BSD系 | 比較的制約が少なく、商用利用・改変・再配布が可能 | 著作権表示・ライセンス文の維持。MITも「何もしなくてよい」ライセンスではない。 |
| Apache License 2.0 | パーミッシブ型。明示的な特許ライセンスを含む | ライセンス文、変更表示、著作権・特許等の表示、NOTICEがある場合の取扱い、特許訴訟時の終了条項。 |
| MPL 2.0 | ファイル単位のコピーレフトを採用するライセンス | Covered Softwareの改変ファイル等のソース提供義務と、より大きな独自プログラムとの境界。 |
| LGPL v3 | ライブラリ利用を想定した弱いコピーレフト | 結合方法だけでなく、ライブラリの置換・再リンクを可能にする条件、表示、ライセンス文、必要なソース等。 |
| GPL v2/v3 | 強いコピーレフト。対象著作物を配布する場面でソース提供等が重要 | 何がGPL対象の結合著作物となるか、配布（convey）の有無、対応ソース、ライセンス互換性。 |
| AGPL v3 | GPL系に加え、改変版をネットワーク経由で利用させる場合の特則 | サーバ上での提供だから公開義務が生じない、という一般的なGPLの感覚をそのまま当てはめない。 |
3-1．MIT・BSD系でも表示義務を落とさない
MIT Licenseは、広範な利用を認める一方、ソフトウェアのコピー又は実質的な部分に著作権表示と許諾表示を含めることを条件としています。商用製品に組み込む場合は、Third Party Notices、ライセンス一覧、アプリ内表示等のどこで条件を履行するかをリリース前に決めます。
3-2．Apache License 2.0はNOTICEと特許条項まで見る
Apache License 2.0では、ライセンス文の交付、変更したファイルへの変更表示、一定の著作権・特許・商標・帰属表示の維持などが求められます。また、原著作物にNOTICEファイルが含まれる場合、その帰属表示の取扱いも確認が必要です。さらに、コントリビューターからの特許ライセンスと、一定の特許訴訟を提起した場合の終了条項があるため、著作権表示だけを見て完了とはできません。
3-3．LGPLは「動的リンクなら無条件に安全」というルールではない
LGPL v3は、ライブラリとアプリケーションを結合したCombined Workを独自条件で配布できる余地を設けていますが、ライブラリ部分の改変を妨げないこと、所定の表示、ライセンス文の提供、利用者が変更版ライブラリと再結合できる仕組み等の条件があります。静的リンクか動的リンクかだけで結論を出さず、実際のビルド・配布方式を技術担当者と確認します。
3-4．GPLとAGPLは「配布」と「ネットワーク利用」を分けて考える
GPLでは、単に自社サーバ上でプログラムを実行し、利用者がネットワーク越しにサービスを利用するだけで、直ちに自社サービス全体のソースコード提供義務が発生するとは限りません。他方、GPL対象プログラムやそれと一体と評価される成果物を顧客へ配布する場合には、対応ソースの提供等が問題になります。
AGPL v3は、改変したプログラムをネットワーク経由で利用させる場合について、遠隔利用者に対応ソースを取得する機会を提供する特則を設けています。そのため、SaaSであればコピーレフトを気にしなくてよい、という判断はAGPLには当てはまりません。
4．ソースコード提供義務の有無は「どのコードを、どう届けるか」から判定する
コピーレフト型ライセンスの検討では、「OSSを使っているか」だけでなく、実際のソフトウェア構成と提供形態を図にすることが有効です。たとえば、サーバ内部だけで利用するライブラリ、ブラウザへ配信するJavaScript、モバイルアプリに同梱するライブラリ、顧客環境へ納品するDockerイメージ、SDKとして第三者へ配布するコードでは、ライセンス上の行為が異なります。
| 利用形態 | 確認すべきポイント |
|---|---|
| 自社サーバ内部のみ | 配布の有無。AGPL等のネットワーク利用に関する特則。改変の有無。 |
| Webフロントに配信 | ブラウザへコードが配布される構成か。バンドル後のライセンス表示・ソース提供。 |
| iOS / Androidアプリ | OSSがアプリバイナリに組み込まれて配布されるか。アプリストア条件との両立。 |
| オンプレミス納品 | 実行ファイル・コンテナ・依存物を顧客へ渡す範囲。対応ソース提供やライセンス文の同梱。 |
| SDK・ライブラリ提供 | 自社顧客がさらに再配布することを想定したライセンス連鎖と表示方法。 |
「独立モジュールに分ければ必ずGPLの影響を切れる」といった形式論だけで設計するのも危険です。プロセス分離、IPC、API通信、リンク方法、共通データ構造など技術的な関係を把握したうえで、対象ライセンスの文言と法的評価を検討する必要があります。
5．ライセンス互換性・デュアルライセンス・特許も確認する
複数のOSSを組み合わせる場合、それぞれの条件を同時に履行できるかというライセンス互換性が問題になります。特に、強いコピーレフトのコードと、追加的な利用制限を課すライセンスを結合する場合は注意が必要です。
また、同じソフトウェアが「GPL又は商用ライセンス」のように複数の条件で提供されることがあります。この場合、商用ライセンスを購入することで公開義務等を回避できる場合がありますが、購入主体、利用席数・サーバ数、子会社利用、再配布権、契約終了後の利用などを確認します。Apache License 2.0など明示的な特許条項を含むライセンスでは、著作権だけでなく特許ライセンスの範囲も重要です。
6．OSSコンプライアンスは、リリース直前の法務チェックでは回らない
OSSは依存関係が多層化し、直接導入したライブラリだけでなく、パッケージが自動的に取り込む推移的依存関係にも異なるライセンスが含まれます。そのため、開発者がリリース直前に利用OSSを手作業で一覧化する運用では、継続性に限界があります。
経済産業省の「ソフトウェア管理に向けたSBOM導入に関する手引 ver 2.0」は、SBOMを脆弱性管理だけでなくライセンス管理にも活用できる仕組みとして位置付けています。また、OpenChainのISO/IEC 5230は、OSSライセンスコンプライアンスのための役割・プロセス・継続的運用の枠組みを示しています。IPAも2026年にOSPOスターターキット（ドラフト版）を公開し、組織的なOSSポリシーと運用ルールの整備を支援しています。
| 工程 | 実務で残すべきもの |
|---|---|
| 導入申請 | OSS名・バージョン・用途・導入理由・ライセンス・配布形態 |
| 自動検出 | SBOM / SCA等による直接・推移的依存関係の抽出 |
| 法務・知財判定 | 禁止・要承認ライセンス、公開義務、NOTICE、特許・互換性の判定 |
| リリースゲート | Third Party Notices、ライセンス文、必要なソース・オファーの準備 |
| 運用 | バージョン変更・ライセンス変更・脆弱性・EOLの監視 |
| 証跡保存 | 採用時のライセンス文、ソース対応版、レビュー結果、配布物の記録 |
7．外部APIは「技術仕様」ではなく、継続的なサービス契約として読む
外部APIには、OSSライセンスのような共通のライセンス体系があるわけではありません。各提供者のDeveloper Terms、API Terms、個別契約、料金表、SLA、プライバシー条件等を読み、利用可能な行為と提供者が負う義務を確認します。APIキーが発行され、技術的に呼び出せることと、契約上その利用が許されていることは別問題です。
とくに無料プランや開発者向けプランから事業を開始する場合、商用利用、再販売、顧客への機能提供、結果データの保存、キャッシュ、機械学習への利用などが制限されることがあります。事業化の前に、本番利用に適用される契約条件へ切り替えて確認する必要があります。
8．外部API利用規約で必ず確認したい10項目
| 確認項目 | 確認内容 |
|---|---|
| 1 利用許諾範囲 | 商用利用、社内利用、顧客向け提供、再販売、サブライセンス、地域・用途制限。 |
| 2 APIキー・認証 | キー共有禁止、顧客ごとの認証、漏えい時の通知・失効、秘密管理。 |
| 3 レート・クォータ | 秒・日・月単位の上限、超過時の停止、増枠手続、従量課金。 |
| 4 キャッシュ・保存 | レスポンスデータをどの期間・目的で保存・再利用できるか。派生データの扱い。 |
| 5 データ利用 | 送信データを提供者がサービス提供以外の目的、分析、広告、モデル学習等に利用できるか。 |
| 6 表示・ブランド | 出典表示、ロゴ・商標、Powered by表示、表示位置や削除禁止。 |
| 7 仕様変更・廃止 | バージョン変更、非推奨化、廃止の通知期間、移行期間、互換性。 |
| 8 SLA・サポート | 可用性、障害通知、復旧目標、サポート時間、サービスクレジット。 |
| 9 知財・責任 | 出力・データの権利、第三者権利侵害、補償、保証、責任上限、間接損害。 |
| 10 停止・終了 | 違反時の即時停止、任意終了、終了後のデータ取得、移行支援、削除。 |
9．個人データをAPIへ送る場合、「委託」か「第三者提供」かを先に整理する
API連携で顧客情報やユーザー情報を外部事業者へ送信する場合、個人情報保護法上の整理も必要です。利用目的の達成に必要な範囲で、API提供者が自社の指示に従って処理するだけであれば「委託」と整理できる場合があります。この場合でも、委託先に対する必要かつ適切な監督が必要です。
一方、API提供者が受領したデータを、自社の広告、独自サービス改善、他顧客向け分析、モデル学習など自らの目的でも利用する場合、「委託だから第三者提供ではない」と当然には整理できません。実際のデータ利用目的をAPI規約・DPA・プライバシーポリシーから確認します。外国にある事業者への提供では、外国第三者提供の規律も別途確認が必要です。GDPRが適用される場合には、DPAや国際移転の整理も追加されます。
10．顧客向け契約は、上流APIの条件を超えて約束しない
外部APIを自社SaaSの中核機能として利用する場合、API提供者との「上流契約」と、自社が顧客と締結する「下流契約」の不整合が大きなリスクになります。上流で保証されていない可用性やデータ保存期間を、下流契約で無条件に保証すると、API障害がそのまま自社の契約違反になります。
| 上流APIの条件 | 下流の顧客契約で確認する点 |
|---|---|
| SLAなし／ベストエフォート | 自社だけで99.9%等を保証できる構成か。除外時間・外部サービス障害の扱い。 |
| API提供者の責任上限が低い | 自社の顧客に対する賠償上限とのギャップを把握する。 |
| 仕様変更・廃止権が広い | 機能変更・終了条項、代替機能、通知手続と整合させる。 |
| 保存・再利用が制限される | 顧客へのデータ保持・エクスポート保証が履行可能か確認する。 |
| 特定用途・業種を禁止 | 自社顧客の利用用途まで制御できる禁止事項・審査フローを設ける。 |
| 価格変更・従量課金 | 顧客価格、利用上限、超過課金、更新時値上げの設計に反映する。 |
このように上流契約と下流契約の義務を対応させる考え方を、実務上「バック・トゥ・バック」で設計すると表現します。完全に同一の条項にする必要はありませんが、自社がコントロールできないリスクを顧客に約束していないかを項目ごとに照合することが重要です。
11．API停止・仕様変更は、法務だけでなくシステム設計で吸収する
API提供者との契約で十分な通知期間やSLAを確保できない場合、契約交渉だけでリスクを消すことはできません。その場合は、システム側で依存度を下げる設計が必要です。
- API呼出し部分を抽象化し、代替プロバイダへ切り替えやすくする
- 外部API障害時にサービス全体を停止せず、該当機能だけを縮退させる
- 必要な範囲でキャッシュ・再試行を実装する。ただしAPI規約上許される範囲を確認する
- バージョン廃止・料金変更・規約変更の通知先を個人メールではなく管理用アドレスにする
- 重要APIについて代替候補、切替手順、顧客通知文案を事前に用意する
契約上の権利を増やすことが難しい大手APIでは、特にこの「法務とアーキテクチャの組合せ」が重要になります。
12．資金調達・M&Aでは、OSSとAPIの依存関係がデューデリジェンス対象になる
資金調達やM&Aの技術・法務デューデリジェンスでは、重要なソフトウェア資産を自社が適法に利用できるか、サービスを継続できるかが確認されます。OSS台帳が存在せず、GPL・AGPLの利用状況を説明できない場合や、中核機能が解約自由な無料APIだけに依存している場合は、是正対応や契約変更がクロージング条件になることもあり得ます。
そのため、平時から「重要OSS」「重要API」を特定し、ライセンス・契約・技術的依存度・代替可能性を一つの台帳で追跡しておくと、リスク管理だけでなくデューデリジェンス対応も効率化できます。
13．導入からリリースまでの実務フロー
- 候補選定：OSS又はAPIを採用する技術的理由と代替候補を記録する。
- 条件確認：OSSはライセンスとバージョン、APIは本番利用に適用される規約・料金・SLAを取得する。
- 利用形態の整理：改変、結合、配布、ネットワーク利用、送信データ、キャッシュ等の実装を確認する。
- リスク判定：公開義務、表示、特許、データ利用、利用制限、仕様変更、責任上限を判定する。
- 契約・設計反映：必要な商用ライセンス、DPA、SLA、顧客規約、技術的な代替策を整備する。
- リリース確認：Third Party Notices、ソース提供方法、APIキー管理、監視・通知先を確認する。
- 継続監視：バージョン・ライセンス・規約・料金・EOL・脆弱性の変更を追跡する。
14．よくある誤解
「GitHubに公開されているコードは自由に使える」
公開されていることと利用許諾があることは別です。適用ライセンスが確認できないコードは、安易に製品へ取り込まない方が安全です。
「GPLを使うと必ず自社コードを全部公開する」
どの成果物がライセンス対象となるか、結合関係と配布形態により判断します。単純にOSSを利用した事実だけでは結論は出ません。
「SaaSならGPLを気にしなくてよい」
GPLの配布義務の発生場面とは別に、AGPLのネットワーク利用特則、ブラウザ配布コード、顧客向けコンテナ等を確認します。
「LGPLは動的リンクなら確認不要」
LGPLにも表示・ライセンス文・再リンク等の条件があります。採用方法を技術的に確認します。
「MITなら何も表示しなくてよい」
MITにも著作権表示・許諾表示の維持条件があります。
「APIが動いているなら商用利用できる」
技術的アクセス権と契約上の利用許諾は別です。開発者向けプランに商用利用・再販売制限がないか確認します。
「API障害は提供者の責任だから自社は免責される」
自社と顧客の契約は別です。顧客に対するSLAや損害賠償義務が上流契約で補填されるとは限りません。
15．弊所の実務上の視点｜「法務レビュー対象」をコードと契約の変更イベントに組み込む
OSS・API管理で最も避けたいのは、法務が年1回だけ台帳を確認し、開発現場では日々依存関係が変わっている状態です。法務レビューは、①新規OSSの導入、②ライセンスが要注意類型に該当した場合、③OSSの改変・配布形態が変わる場合、④重要APIの新規導入、⑤API規約・料金・SLAの重要変更、⑥顧客への保証内容を変更する場合など、開発・契約のイベントと連動させる方が機能します。
すべてのOSS・APIを弁護士が個別に承認する必要はありません。パーミッシブ型の標準利用などは社内ルールで処理し、GPL・AGPL・独自ライセンス、重要APIの中核利用、個人データの独自利用を伴うAPIなどをエスカレーション対象にすることで、開発速度とリスク管理を両立できます。
16．OSS・外部API利用チェックリスト
- OSS名・バージョン・入手元・ライセンスを記録しているか
- 直接依存だけでなく推移的依存関係まで把握しているか
- OSSを改変・結合・配布する方法を確認したか
- GPL・LGPL・AGPL・MPL等の条件を個別に確認したか
- MIT・BSD・Apache等の著作権表示・NOTICE等を反映したか
- 必要なソースコードやソース入手方法を提供できる状態か
- ライセンス互換性・デュアルライセンス・特許条項を確認したか
- SBOM又は同等の依存関係台帳を更新できるか
- APIの商用利用・顧客向け提供・再販売が許されているか
- APIのレート制限・料金・仕様変更・廃止条件を確認したか
- APIへ送るデータの利用目的と個人情報保護法上の整理を確認したか
- APIのSLA・責任上限と顧客向け契約の保証が整合しているか
- API停止時の代替手段・縮退運転・顧客通知手順があるか
- OSS・APIの規約・ライセンス変更を継続的に監視する担当を決めたか
17．FAQ
Q1．OSSを社内だけで使う場合もライセンス確認は必要ですか？
必要です。配布を伴わないため特定のソース提供義務が生じない場合でも、ライセンスによって許諾される利用範囲を確認し、将来の配布・SaaS化・顧客納品に備えて記録しておくべきです。
Q2．GPLのライブラリを使うと、必ず自社ソースを公開しなければなりませんか？
必ずではありません。対象プログラムとの結合関係、改変の有無、配布の有無等から判断します。ただし、配布する成果物にGPL対象の結合著作物が含まれる場合には、対応ソース提供等が重要になります。
Q3．SaaSならAGPLも問題ありませんか？
AGPL v3は、改変版をネットワーク経由で利用させる場合に、遠隔利用者へ対応ソースを取得する機会を提供する特則を設けています。SaaSでの利用形態を前提に個別確認が必要です。
Q4．OSS管理にSBOMは必須ですか？
すべての企業に法令上SBOM作成義務があるという意味ではありませんが、依存関係・ライセンス・脆弱性を継続管理する有力な手法です。自社規模と製品特性に応じて導入範囲を決めます。
Q5．外部APIの利用規約が一方的に変更された場合、従うしかありませんか？
契約の適用関係や変更条項によります。交渉余地が小さいサービスでは、重要変更を検知する運用と、代替API・機能縮退など技術的な退出手段を事前に用意することが重要です。
Q6．API提供者が受信データをAI学習に使う場合、委託として扱えますか？
自社の委託業務の範囲を超え、提供者自身の目的でデータを利用する場合には、単純な委託として扱えない可能性があります。規約上の利用目的と個人情報保護法上の提供関係を確認します。
Q7．OSSやAPIの確認はいつ行うのがよいですか？
本番リリース直前では遅いことがあります。重要なOSS・APIは設計・選定段階で確認し、導入後もバージョン、ライセンス、規約、料金、EOL等の変更を継続的に監視します。
18．主要な一次資料・参考資料
- 独立行政法人情報処理推進機構（IPA）「その『思い込み』がリスクになる？OSSに対する誤解を解く5つの処方箋」（2026年2月25日公開、2026年8月3日更新）
- 独立行政法人情報処理推進機構（IPA）「OSPOスターターキット ドラフト版」（2026年4月16日公開）
- 経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver 2.0」（2024年8月29日）
- OpenChain Project「ISO/IEC 5230 Open Source License Compliance」「ISO/IEC 18974 Open Source Security Assurance」
- Open Source Initiative（OSI）各ライセンス本文（MIT、Apache-2.0、MPL-2.0等）
- Free Software Foundation（GNU Project）GNU GPL v3、GNU LGPL v3、GNU AGPL v3及びGNU Licenses FAQ
- Apache Software Foundation「Apache License, Version 2.0」
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」「外国にある第三者への提供編」
19．まとめ
OSSと外部APIは、開発速度を上げるための重要な基盤ですが、技術的に利用できることだけでは事業利用の安全性は確保できません。OSSでは、ライセンス名ではなく、具体的なコード構成・改変・配布・ネットワーク利用に応じて義務を判定し、表示・ソース提供・ライセンス互換性を管理します。外部APIでは、利用許諾範囲、データ利用、仕様変更、SLA、責任、終了条件を確認し、顧客向け契約とのギャップを埋める必要があります。
実務上は、OSS・APIの導入時に一度確認して終わりではなく、SBOMや依存台帳、契約台帳、変更通知の受信体制を整え、開発・法務・セキュリティが同じ情報を継続的に更新できる仕組みを作ることが重要です。
弊所では、OSSライセンスの採用可否・公開義務の整理、外部API利用規約のレビュー、SaaS利用規約・SLA・DPAとの整合確認、開発チーム向けのOSS／API運用ルール整備まで、事業モデルと技術構成に応じてサポートしています。新規サービスの設計段階や、資金調達・M&A前の棚卸し段階で確認することで、リリース後の仕様変更やデューデリジェンスでの手戻りを抑えやすくなります。
