SalesforceやStripe、Slackなど、APIを公開することにより収益を大きく向上させたベンダーは多くあります。
Stripeは収益の大部分をAPIを通じて得ており、Twillioに買収される前にSendGridが2018年に公開していたデータによると彼らの収益の81%はAPIを通じたメール配信によるものでした。
公開APIの料金体系や仕様、プラットフォームの体系などは後から変更しにくい部分が多く、リリース前にプロダクト特性や成長戦略を踏まえて練り上げる必要があるので、実例も含めて参考にしてみてください。
収益化の方法 | 海外SaaSベンダーの例 | 国内SaaSベンダーの例 | |
|---|---|---|---|
直接課金 | APIコールに直接的に課金する | Open AI | PAY.JP |
間接課金 | APIによる課金は行わないが、APIを通じてプロダクトの顧客獲得や離反防止を促進させる | Dropbox | LINE |
Platform課金 | 自社APIを用いたアプリをPlatformに掲載し、収益の一部を回収する | Salesforce | ー |
APIコールそのものに費用を請求する最もシンプルでわかりやすいパターンです。1コールから課金するベンダーもいれば、特定のコール数やデータ量を超える場合に課金するベンダーもあります。
最近だと生成AIのAPIを使ってみるために、Open AIやClaudeに課金した方も多いのではないでしょうか。
直接課金の形態でAPIを普及させるのは、前提として大きなニーズとサービスそのものの価値が必要です。
ユーザーが納得感を持ってAPIそのものに課金するには、以下のような特徴を持つSaaSプロダクトは直接課金と相性が良いのではないかと思います。
高度な技術や独自のデータを持つ企業(Open AI、DeepLなど)
スケーラブルで需要の高いサービスを提供する企業(Stripe、Twillioなど)
使用量に応じた課金が自然なサービスを提供する企業(AWS, GCPなど)
特にOpen AIやAWS、GCPなど、裏側でインフラやストレージにコストがかかっていることが想起しやすいプロダクトに関しては直接課金が受け入れられやすいでしょう。
反対に、API連携機能が「魅力品質」から「当たり前品質」にシフトしつつある昨今だと、業務系SaaSなどにおいて業務データを他のサービスに連携する等の単純なデータの入出力で直接課金を採用すると、一般的には受け入れられにくい可能性があります。

直接課金のAPIの中でも細分化すると、以下のようなパターンが見受けられます。
従量課金: コール数に応じて金額が上がっていく
従量キャップ課金: コールリミットごとに課金金額が上がっていく
プラン課金: 上位プランにするとAPIを利用できるようになる
オプション課金: APIコールをするためのオプションに課金が発生する
どのパターンを選択するかは、APIが利用されることによるサーバーへの負荷やAPIのコール数が提供価値と比例していくか、などの観点を踏まえて考慮が必要になるでしょう。
API自体は無償で公開するものの、APIによって間接的に顧客獲得や機能利用、解約防止などに貢献し、収益を高めるというモデルです。

SaaSを選定する際、「自分が使っている〇〇と連携できる」というのは大きなメリットになるため顧客の意思決定にポジティブな影響を与えることができるのは想像しやすい側面かと思います。
またAPIを公開して外部システムとの連携を促進することには、ツールの依存度・リプレイスコストを高めて解約防止につなげるという副次的効果もあります。
(厳密な相関関係は不明瞭ではありますが)とあるSaaSベンダーではAPI連携機能を使っている有料ユーザーはそうでない有料ユーザーに比べて解約率が半分以下というデータも見えたこともありました。
DropboxやTrello、Github、LinkedIn、Notionなど大手Webサービスが無償でAPIを公開しているのも、直接的な課金機会の創出というよりはサービス価値の向上による間接的な効果を狙っているものと推察できます。
このようなパターンでは利用者には敷居が低く使いやすい側面がありますが、一方でSaaSベンダーにとって効果測定が難しく、APIを公開・メンテナンスするコストに対してリターンが見合っているかはとてもわかりにくいという難点があります。
「顧客獲得や離反防止に効く(効いている)はず」という仮説だけでAPIを公開すると十分なリターンが得られなかったり、どのAPIを公開するか?という意思決定で大きなミスが生まれてしまうリスクがあります。
何のためにAPIを公開するか?具体的にどの事業KPIに直結するか?は一般論に落としにくく検証コストも高い部分ですが、API戦略を立てるうえで欠かせない観点です。

またAPIそのものでは課金をせずとも、有料機能の利用をAPIによって促進するというパターンも見受けられます。
例えばLINE公式アカウント(企業向けLINEアカウント)の場合、Messaging APIというAPIを通じてAPI経由で企業からユーザーにメッセージを配信できるようになっています。
LINEはMessaging APIの利用そのものには課金をしていませんが、メッセージ配信は配信通数に応じた従量課金となっているため、API経由でメッセージが配信されればされるほど、サービスの有料機能の利用が促進されるという仕組みになっています。
特にLINEは国内でもAPIエコシステムが発展しており、多くのSaaSベンダーや広告代理店がLINE APIを使ってLINE配信ツールを作って顧客獲得していいます。結果としてLINEはAPIを公開すること自社のマーケティング・CSリソースの外でも売上が拡大していく構造を作ることに成功しています。
自社で公開しているAPIを使って作られたアプリをプラットフォームに並べ、決済手数料などの名目でアプリ利用料の一部を回収して収益化するパターンです。
身近な事例としてはAppleのApp Storeが想像しやすいですが、SaaSの世界で最も有名な事例としてはSalesforceのApp Exchangeというアプリプラットフォームでしょう。
SalesforceはAppExchangeで行われた決済の15%を彼らの収益として徴収します。逆に言うと、アプリデベロッパーとしては15%も持っていかれるコストを上回るメリットをApp Exchangeの掲載に感じているということです。

この課金モデルがうまくいくと、エコシステムの拡大に比例してAPI収益を得られるという莫大なメリットが手に入ります。またエコシステムにアプリが増えてプロダクト価値が高まることでエンドユーザーが集まり、そのユーザー基盤に惹かれたSIerやデベロッパーが集まることで更にアプリも増えるというネットワーク効果も期待できます。
同じようなモデルはShopifyやIntuit(北米最大手の会計ソフト)、Atlassianなどで実践され、成功しています。
最もインパクトのあるPlatform課金ですが、これを実現するには「大きなSaaS市場の中で大規模なユーザーベースを持つ」というのが最低条件になります。
ネットワーク効果やプラットフォーム戦略を語るうえで「ニワトリタマゴ」と言われることがよくありますが、Platform課金を成功させるにはユーザーとアプリを開発するDeveloperを両方集める必要があります。
いまだに日本発のPlatform課金の成功事例が見られないのは以下のような背景があるのではと考えています。
APIの浸透度が十分に高まっていない
欧米と比較してSaaSのマーケットサイズが小さく、莫大なユーザーベースを持つSaaSがまだ少ない
日本の開発会社では個社ごと開発を行うSIerの比率が高くSaaSインテグレーターが少ない
逆に言うと未だAPI Platform成熟しきっていない日本でPlatform課金を成功させるには、ユーザーベースを拡大したうえで、単にAPIを公開するのではなく開発パートナーやエバンジェリストを開拓しながら戦略的にPlatformを作っていく必要があります。
Platformで稼ぐにはPlatform上で発生しているお金の流れを把握し取りっぱぐれが発生しないように「連携アプリの課金基盤を抑えている」というのが必須になります。
Salesforceはアプリのお金の流れを自社プラットフォーム(App Exchange)上に留めることでアプリのトラフィックを確実に自社の収益に還元しており、SaaSではありませんがAppleのApp Storeも同様です。
課金基盤を抑えずにAPI公開するとたとえAPIが世に広まっても各Developerが自身の課金基盤で自由に商売しているカオスな状態になってしまい、これを後からコントロールするのは非常に難しい作業になるでしょう。
スケーラブルで安定したAPIや課金基盤といった機能面の拡張や、高い目標を持ちながら一緒にビジネスを推進してくれるパートナーの開拓など道のりはかなり険しいものですが、いつの日か日本でもAPI Platformが現れるのを心待ちにしています。
APIを公開して収益化していく難しさには、後から引き返せない要素が多いという背景があるかと思います(無償APIを有償に切り替える / 課金基盤を後から握りに行く等)。
公開APIをクイックに検証・リリースしてユーザーの反応を見るのももちろん良い方法ですが、戦略策定と効果測定は強く意識していくと良いでしょう。
本メディアはAPI特化の開発会社であるECU株式会社が運営しています。記事についてのご質問やAPIに関するご相談・お問い合わせはお気軽にお問い合わせフォームまで。