API・SDK・OSS：用語の正確な理解と契約・知財上の含意
エンジニアが「APIで連携する」「SDKを使う」「OSSを活用する」と説明するとき、M&A担当者やVCキャピタリストがその含意まで理解できているかで、デューデリジェンスの質が変わります。
この3つの用語は技術的な説明語として頻繁に登場しますが、実際には事業継続性・ライセンス義務・知財帰属・調達先依存度に直結する概念です。「APIを使っている」という一言が、いかなるリスクを内包しているかを整理できていない状態でのDDは、後から想定外のコストが発覚する原因になります。
API・SDK・OSS の定義と関係性
API（Application Programming Interface）
APIは、ソフトウェア同士が機能やデータをやり取りするための窓口です。
最もわかりやすい例はWebサービスのHTTP APIです。Google Mapsの地図機能をアプリに組み込む場合、アプリはGoogleが定めた手順（エンドポイント・パラメータ・認証方式）に従ってリクエストを送り、地図データを受け取ります。このやり取りのルールの定義がAPIです。
APIが「窓口」であるとすれば、窓口の形と使い方を定めた仕様書がAPI仕様、その仕様に従った実際の通信がAPIコールです。APIを提供する側をプロバイダー（例：Google、Stripe）、使う側をコンシューマー（例：アプリ開発者）と呼びます。
SDK（Software Development Kit）
SDKは、APIを使いやすくするためのツールキットです。
Google Maps APIを直接使う場合、開発者はHTTPリクエストを自力で組み立てる必要があります。しかしGoogle Maps SDKを使えば、map.addMarker(lat, lng) のような直感的な関数呼び出しで同じことが実現できます。SDKはAPIを人間にとって使いやすい形に包んだライブラリ・ツール群です。
SDKには、ライブラリコード（APIとの通信を担う）だけでなく、サンプルコード・ドキュメント・テストツール・デバッグ用CLIなどが含まれることが多いです。
APIとSDKの関係を一言で表すと、APIは「規約」、SDKは「その規約に従うための道具」です。SDKなしにAPIを使うことは技術的に可能ですが、SDKがあることで開発効率が上がります。
OSS（Open Source Software）
OSSは、ソースコードが公開され、一定の条件のもとで自由に利用・改変・再配布できるソフトウェアです。
「公開されている」と「自由に使える」は同義ではありません。公開には必ずライセンスが伴い、そのライセンスが使用条件を定めています。ここが事業・法務上の論点の核心です。
API が事業に与える影響：依存と支配の非対称性
APIを利用することは、プロバイダーの意思決定にコンシューマーが従属する関係を構築することでもあります。
典型的なリスクは3つです。
料金変更リスク：TwitterがAPIの無料プランを廃止したとき、APIに依存したサービスが軒並み事業継続を迫られました。プロバイダーがAPIの価格・制限を変更する権限を持つ以上、コンシューマーはその影響を受けます。
仕様変更・廃止リスク：APIのバージョン廃止（deprecation）が通知されたとき、コンシューマーは対応コストを負います。既存のコードがAPIのバージョンアップに追いつけない場合、サービスが停止するリスクがあります。
利用規約の制限：APIの利用規約はプロバイダーが一方的に定めます。「競合サービスへの転用禁止」「特定の分野への利用禁止」などの条項が含まれる場合があります。スタートアップが複数の企業に売られる際、このような制限が実は事業の範囲を制約していたという発覚は珍しくありません。
投資・買収の文脈では、「何のAPIに、どの程度依存しているか」がリスク評価の重要な軸になります。コアプロダクトの機能が単一のAPIプロバイダーに依存している場合、そのプロバイダーとの関係変化が事業継続を左右するリスクがあります。
SDK が内包するライセンス問題
SDKは多くの場合、プロバイダーが独自のライセンスで配布します。このSDKのライセンス条件がプロダクトの設計や配布方法を制約することがあります。
フィンテック系スタートアップでは決済SDKを組み込むことが多いですが、そのSDKのライセンスが「別製品としての転売禁止」「サービス事業者としての資格要件」などを定めている場合があります。SDKを使うことで、知らず知らずのうちにライセンス上の義務を負っているケースは技術DDで時折発見されます。
確認すべき観点：
- SDKの配布ライセンスに制限条項があるか
- SDKに含まれるライブラリが別のライセンスを持っていないか（再帰的ライセンスの問題）
- APIプロバイダーとの契約（利用規約への同意を含む）が個人の開発者名義で締結されており、法人への移転が必要なケースがないか
OSS ライセンスの種類と商用利用上の注意
OSSのライセンスは大きく「パーミッシブ型」と「コピーレフト型」に分類できます。この区別が事業上のリスクと直結します。
パーミッシブ型ライセンス
| ライセンス | 代表的な採用OSS | 主な特徴 |
|---|---|---|
| MIT | React, Vue.js, Rails | 著作権表示があれば商用利用・改変・再配布が自由 |
| Apache 2.0 | Kubernetes, TensorFlow | MITに加え、特許許諾・商標使用禁止が明確化 |
| BSD 2/3-Clause | nginx, FreeBSD | MITに近い。3-Clauseは宣伝目的の使用に追加制限あり |
パーミッシブ型を使う分には商用プロダクトへの組み込みや再配布が原則自由です。ただし、著作権表示（クレジット）の省略や、ライセンス条文を改ざんした上での配布は違反になります。
コピーレフト型ライセンス
| ライセンス | 代表的な採用OSS | 主な特徴 |
|---|---|---|
| GPL v2/v3 | Linux kernel, WordPress | GPLライセンスのOSSを組み込んだソフトウェアは、頒布時にソースコードを開示する必要が生じる場合があります |
| LGPL | FFmpeg（一部） | ライブラリとして動的リンクで使う場合は開示義務が緩和される場合があります |
| AGPL | MongoDB（旧ライセンス）, Nextcloud | Webサービスとして公開する場合もソースコード開示義務が発生しえます |
コピーレフト型で特に注意が必要なのがAGPL（Affero GPL）です。通常のGPLは「ソフトウェアを配布する」場合に開示義務が発生しますが、AGPLはネットワーク経由でサービスを提供する場合にも適用されます。SaaSとして提供するだけでもソースコードの開示が求められる可能性があります。
投資・買収の実務上の論点：コアプロダクトにコピーレフト型OSSが組み込まれている場合、ソースコード開示義務の発生可能性があります。この評価は法的専門家の判断が必要ですが、「コピーレフト型OSSが使われているかどうか」の事実確認は技術担当者が行えます（詳しくは技術担当者ができる簡易IPデューデリジェンスの進め方を参照）。
IP・契約上の論点：投資家・M&A担当者が理解すべき3点
1. OSS コンポーネントはプロダクトの「IP資産」ではない
プロダクトの技術的価値を評価するとき、「何の技術で作られているか」と「その技術の権利を誰が持つか」は別の問いです。
OSSライブラリを使って作られた機能は、そのライブラリの著作権を企業が所有しているわけではありません。ライセンスに従って利用しているに過ぎません。真に企業のIP資産になるのは、自社で開発したオリジナルのコード・アルゴリズム・データ構造・ドキュメントです。
この区別ができると、「このプロダクトのコアのIP価値はどこにあるか」という評価が正確にできます。OSSの上に乗っているだけのプロダクトと、独自の技術的蓄積が差別化を生んでいるプロダクトでは、投資価値の評価が変わります。
2. APIプロバイダーとの「利用規約」は通常、優位な立場にない
一般的に、APIの利用規約はプロバイダーが作成する「約款」です。コンシューマーは内容を交渉できず、プロバイダーが定める条件を飲むか、使わないかを選ぶしかありません。
これはB2B取引の契約書とは性質が異なります。利用規約はプロバイダーによる一方的な改定が可能であり、しかも通知後の継続利用が同意とみなされる条項が多いです。
M&AのDDにおいて、ビジネス上重要なAPIについては利用規約の内容を精査し、プロバイダーによる仕様変更・価格変更・サービス終了に対してどのようなヘッジ手段があるかを確認することが望まれます。
3. OSSの「フォーク戦略」とIPの複雑化
一部のスタートアップは、OSSをそのまま使うのではなく、fork（コードをコピーして独自に改変）する戦略を取ります。フォークすることで特定のOSSプロバイダーへの依存を回避できるという利点がある一方、以下の論点が生じます。
- フォーク元のコピーレフト型ライセンスは、フォーク後の改変版にも引き継がれる場合があります
- フォーク後のメンテナンスはすべて自社が負担するため、upstream（元OSSの更新）を反映するコストが継続的に発生します
- フォークしたコードに自社の独自実装が混在する場合、「どこからが自社のIP」かの区別が曖昧になります
フォーク戦略をとっている場合、「フォーク元のライセンス・フォーク後の義務・自社コードのIPの境界」が明確かを技術DDで確認することが重要です。
投資・買収時に確認すべき項目
以上を踏まえ、DDで確認すべきポイントを整理します。
API依存のチェック
- コアプロダクトの機能のうち、外部APIに依存しているものはどれか
- 依存しているAPIのプロバイダーは誰か（Google/AWS/Stripe等の大企業か、小規模なスタートアップか）
- 依存しているAPIが廃止・価格変更された場合の影響範囲と代替手段はあるか
- APIの利用規約に事業継続を制限する条項はないか（特に競合禁止・用途制限・転売禁止の条項）
SDK・ライブラリのライセンスチェック
- コアプロダクトに組み込まれているSDK・ライブラリのライセンス一覧があるか
- コピーレフト型（GPL/LGPL/AGPL）ライセンスが含まれるか
- AGPLが含まれる場合、SaaSサービスとしての提供においてソースコード開示義務が発生しないかの法的見解があるか
- SDKが個人のアカウントで契約されておらず、法人として適切に締結されているか
OSSのフォーク利用
- フォークしているOSSがある場合、フォーク元のライセンス条件を引き継いでいるか
- フォーク版のメンテナンスリソースが確保されているか
- 自社コードとフォーク元コードの境界が追跡可能な状態（git履歴等）で管理されているか
これらの項目は、技術DDにおける「外部依存リスク」評価の一部として組み込むことができます。技術DDの全体フレームワークについては技術デューデリジェンスの全体像と7つの評価軸を参照してください。
関連記事
OSSライセンスの確認手順と、技術担当者が実施できるIP調査の全体像は技術担当者ができる簡易IPデューデリジェンスの進め方で解説しています。
技術的競争優位性の源泉を「自社保有IP」対「外部依存技術」の観点で評価する方法については、技術的優位性の源泉をどう見抜くか：R&Dの競争力評価フレームワークが参考になります。
API依存・OSS依存の評価軸は、技術デューデリジェンスの全体像と7つの評価軸の「外部依存性」「技術スタック」評価に接続します。
Tied株式会社では、VC・事業会社のM&A担当者向けに技術デューデリジェンス支援・IP評価支援を提供しています。詳細は投資家向けサービスページをご覧いただくか、お問い合わせからご相談ください。