Azure API Management による収益化
適用対象: すべての API Management レベル
近年の Web API はデジタル経済を支えています。 これらは会社の知的財産 (IP) をサード パーティに提供し、次のような形で収益を生み出します。
- データ、アルゴリズム、プロセスの形式で IP をパッケージ化する。
- サード パーティが手間なく一貫した方法で有益な IP を発見して利用できるようにする。
- 使用の対価を直接的または間接的に支払うメカニズムを提供する。
どの API の成功事例にも共通するテーマは、"健全なビジネス モデル" です。 持続可能な方法で価値は創造され、すべての当事者間で交換されます。
一般にスタートアップと老舗の企業、そしてその中間に位置するあらゆる組織が、そのビジネス モデルでデジタル変革を模索しています。 API には、ビジネス モデルを実現し、基になる IP のマーケティング、導入、利用、スケーリングのハードルを下げて、コスト効率を高める効果があります。
初めて API を公開する組織は、複雑に絡んだ一連の意思決定に直面します。 Azure API Management プラットフォームは、リスクを下げて重要な要素の展開を加速させますが、独自の技術モデルとビジネス モデルを軸にしてその API を構成、構築する必要があるのは、やはり組織です。
収益化戦略を策定する
"収益化" は、何かをお金に変えるプロセスです。このケースでは API の価値がそれに相当します。 通常、API のインタラクションのバリュー チェーンには、バラバラに存在する 3 つの当事者が関係します。
API 収益化戦略には、次のようなカテゴリがあります。
| API 収益化戦略 | 説明 |
|---|---|
| Free | API はサプライ チェーンを効率化するなど、企業間の統合を促進します。 API は収益化されませんが、ビジネス プロセスの効率化につながるため、API プロバイダーと API コンシューマーの双方にとって大きな価値が生まれます。 |
| コンシューマーが支払う | API との間で行ったインタラクションの数に応じて、API コンシューマーが支払いを行います。 このドキュメントで主に取り上げるのは、このアプローチです。 |
| コンシューマーが支払いを受ける | たとえば、API コンシューマーが API を使用して Web サイトに広告を埋め込み、それによって生み出された収益が API コンシューマーに分配されます。 |
| 間接収益化 | API の収益は、API とのインタラクション数によって決まるのではなく、API によって促進された他の収益源から得られます。 |
Note
収益化戦略は API プロバイダーによって設定されるものであり、API コンシューマーのニーズを満たすように設計されている必要があります。
さまざまな要因が設計には影響するため、API 収益化に万能のソリューションはありません。 競合企業の API との差別化を図り、生み出される収益を最大化するのが、収益化戦略です。
API の収益化戦略を導入する方法については、以降の手順で説明します。
手順 1: 顧客を理解する
最初に API を発見してから最大限にスケーリングするまで、API コンシューマーが体験するであろう各ステージを綿密に計画します。
次に示したのは、顧客が辿る可能性のある一連のステージの例です。
顧客ステージ 説明 調査 API コンシューマーが手間なく無料で API を試用できるようにします。 実装 API との連携に必要な開発とテスト作業を支援するうえで十分な API アクセスを提供します。 プレビュー 顧客がそのオファリングを立ち上げ、初期の需要を把握できるようにします。 初期運用 使用レベルが完全に把握できておらず、リスク回避アプローチが必要である可能性がある場合は、運用環境における API の早期導入を支援します。 初期成長 エンド ユーザーからの需要の増加に対応して API コンシューマーが API の使用量を段階的に増やせるようにします。 スケール API の毎月の使用量が絶えず高水準で推移するようになったら、購入量を増やすことを API コンシューマーに奨励します。 グローバルな成長 API を世界規模で使用してくれるユーザーには、最適な卸値を提示することによって報います。 この取り組みのステージごとに、API が顧客にもたらす価値を分析します。
API によって顧客にもたらされる直接的な価値が十分わかっている場合は、価値ベースの価格戦略の適用を検討してください。
顧客による API の存続使用の予想レベルと API の存続期間中に見込まれる顧客数を計算します。
手順 2: コストを定量化する
API の総保有コストを計算します。
| コスト | 説明 |
|---|---|
| 顧客獲得コスト (COCA: Cost Of Customer Acquisition) | マーケティング、販売、オンボーディングのコスト。 最も成功した API は、導入レベルの増加に従って、COCA がゼロになる傾向があります。 API のオンボーディングは、ほぼセルフ サービスであることが必要です。 要因として、支払いシステムとの円滑な統合やドキュメントが挙げられます。 |
| エンジニアリング コスト | API の存続期間にわたって、その構築、テスト、運用、保守を担当する人材。 最も重要なコスト要素となる傾向があります。 可能な限り、クラウドの PaaS やサーバーレス テクノロジを活用して最小限に抑えるようにしてください。 |
| インフラストラクチャ コスト | API をその存続期間にわたってサポートするために必要な、基盤となるプラットフォーム、コンピューティング、ネットワーク、ストレージのコスト。 API 使用レベルに比例してスケールアップするインフラストラクチャ コスト モデルを実現するには、クラウド プラットフォームを活用します。 |
手順 3: 市場調査を実施する
- 市場調査を通じて競合企業を特定します。
- 競合企業の収益化戦略を分析します。
- API で提供する具体的な機能 (実用性を意図した機能とそれ以外の機能) を把握します。
手順 4: 収益モデルを設計する
以上の手順の成果に基づいて収益モデルを設計します。 次の 2 つの観点から取り組むことができます。
| Dimension | 説明 |
|---|---|
| サービス品質 | API の使用量に上限を設定して、提供するサービス レベルに制約を設定します。 一定期間に実行できる API 呼び出しのクォータ (1 か月あたり 50,000 回など) を定義しておき、そのクォータに達したら、呼び出しをブロックします。 また、レート制限を設定し、短時間に実行できる呼び出し回数を抑制することもできます (1 秒あたり 100 回など)。 上限とレート制限を同時に適用し、短期集中的な API 呼び出しでは毎月のクォータを消費できないようにします。 |
| 価格 | API 呼び出しごとに支払われる単価を定義します。 |
顧客体験の各ステージで顧客を支援する収益モデルを設計することで、個々の顧客からもたらされる生涯価値 (LTV: LifeTime Value) を最大化します。
- 顧客ができるだけ簡単にスケーリングして規模を拡大できるようにします。
- 収益モデルにおける次の階層に移行することを顧客に提案します。
- たとえば、API 呼び出し回数が多い顧客には、単価を下げることによって報います。
- 収益モデルはできるだけシンプルに保ちます。
- 選択肢を提供する必要性と、選択肢が多すぎて顧客が困惑するリスクのバランスを考慮します。
- 収益モデルの各階層の差別化に使用する観点の数は増やさないようにします。
- 透明性を保ちます。
- 各種の選択肢についての明確なドキュメントを用意します。
- 顧客のニーズに最も合った収益モデルを選ぶためのツールを顧客に提供します。
必要な価格モデルの範囲を明らかにしてください。 "価格モデル" とは、API コンシューマーによる利用を API プロバイダーが収益に変えるための具体的な規則の集まりをいいます。
たとえば、前述の顧客ステージをサポートするためには、6 種類のサブスクリプションが必要と考えられます。
| サブスクリプションの種類 | 説明 |
|---|---|
Free |
API コンシューマーは、義務やコスト負担なく API を試用して、ユース ケースを満たすかどうかを判断できます。 登録にあたっての障壁はすべて取り除きます。 |
Freemium |
API コンシューマーは無料で API を使用できますが、需要の増加に伴って有料サービスに切り替えることができます。 |
Metered |
API コンシューマーは、毎月必要に応じて何度でも API を呼び出すことができますが、1 回の呼び出しごとに一定額が課金されます。 |
Tier |
API コンシューマーは、毎月決められた回数の呼び出しに対して課金されます。 この制限を超えた場合は、追加の呼び出しごとに超過分が課金されます。 定期的に超過分が発生するようであれば、次の階層にアップグレードすることができます。 |
Tier + Overage |
API コンシューマーは、毎月決められた回数の呼び出しに対して課金されます。 この制限を超えた場合は、追加の呼び出しごとに決められた額が課金されます。 |
Unit |
API コンシューマーは、毎月決められた量の呼び出しに対して課金されます。 この制限を超えた場合は、呼び出し単位ごとに超過分が課金されます。 |
API 製品群は、収益モデルによって定義されます。 各 API 製品には、API コンシューマーのライフサイクルにおける特定のステージをターゲットとする固有の価格モデルが導入されます。
一般に、価格モデルは変更すべきではありませんが、収益モデルに合わせて価格モデルの構成と適用を調整しなければならない場合もあります。 たとえば、競合企業に合わせて価格を調整するようなケースが該当します。
上記の例を基に、価格モデルを適用して、次のように全体的な収益モデルを作成できます。
| 顧客のライフサイクル ステージ | 価格モデル | 価格モデルの構成 | サービスの品質 (QoS) |
|---|---|---|---|
| 調査 | Free | 実装されていません。 | コンシューマーが 1 か月あたり 100 回までしか呼び出せないよう制限するクォータが設定されます。 |
| 実装 | フリーミアム | 段階的階層:
|
クォータは設定されません。 コンシューマーは何回でも呼び出しを実行でき、それに応じて課金されますが、1 分あたりの呼び出しを 100 回までとするレート制限が適用されます。 |
| プレビュー | 従量制 | 価格は、呼び出し 100 回につき $0.15 をコンシューマーに課金するように設定されます。 | クォータは設定されません。 コンシューマーは何回でも呼び出しを実行でき、それに応じて課金されますが、1 分あたりの呼び出しを 200 回までとするレート制限が適用されます。 |
| 初期運用 | レベル | 価格は、1 か月あたり $14.95 をコンシューマーに課金するように設定されます。 | コンシューマーには、1 か月あたりの呼び出しを 50,000 回までに制限するクォータと、1 分あたりの呼び出しを 100 回までとするレート制限が設定されます。 |
| 初期成長 | 階層 + 超過分 | 段階的階層:
|
クォータは設定されません。 コンシューマーは何回でも呼び出しを実行でき、追加の呼び出しごとに課金されますが、1 分あたりの呼び出しを 100 回までとするレート制限が適用されます。 |
| スケール | 階層 + 超過分 | 段階的階層:
|
クォータは設定されません。 コンシューマーは何回でも呼び出しを実行でき、追加の呼び出しごとに課金されますが、1 分あたりの呼び出しを 1,200 回までとするレート制限が適用されます。 |
| グローバルな成長 | ユニット | 段階的階層。すべての階層は、1,500,000 回の呼び出しについて均一の金額 ($749.95/月) です。 | クォータは設定されません。 コンシューマーは何回でも呼び出しを実行でき、追加の呼び出しごとに課金されますが、1 分あたりの呼び出しを 3,500 回までとするレート制限が適用されます。 |
上の表に基づいて収益モデルを解釈する 2 つの例:
Tier 価格モデル
ライフサイクルの初期運用フェーズ中、API コンシューマーをサポートする目的で適用します。 Tier 価格モデル構成では、コンシューマーに次の規則が適用されます。- 月額 $14.95 を支払います。
- 1 か月に呼び出すことのできる回数は 50,000 回までとなります。
- 1 分あたりの呼び出しを 100 回までとするレート制限が適用されます。
ライフサイクルのスケール フェーズ階層 + 超過分 価格モデルを適用することによって導入されます。コンシューマーには、次の規則が適用されます。
- 最初の 500,000 回の呼び出しについて月額 $449.95 を支払います。
- 最初の 50,000 回を超える分については、呼び出し 100 回につき $0.06 が課金されます。
- 1 分あたりの呼び出しを 1,200 回までとするレート制限が適用されます。
手順 5: 調整する
収益モデル全体で価格を次のように調整します。
- 上記手順 3. の市場調査に基づいて、API の価格が高くなりすぎたり低くなりすぎたりしないように価格を設定します。
- 収益モデルにおいて、不公平と思われる点や、モデルを回避してより有利な価格の獲得を顧客に助長するような点があれば訂正します。
- マージンを含む総保有コストをカバーできるだけの総生涯価値 (TLV: Total Lifetime Value) を生み出すように収益モデルが作られていることを確認します。
- 収益モデルの各階層のサービス オファリングの品質にソリューションが対応できることを確認します。
- たとえば、1 分あたり 3,500 回の呼び出しをサポートする場合、そのスループット レベルにまでエンドツーエンドのソリューションをスケーリングできることを確認します。
手順 6: リリースして監視する
API の使用料を徴収するための適切なソリューションを選択します。 プロバイダーは、大きく 2 つのグループに分けられます。
支払いプラットフォーム (Stripe など)
顧客によって選択された特定の収益モデルを適用して、生の API 使用メトリックに基づく支払いを計算します。 収益化戦略を反映するように支払いプラットフォームを構成してください。
支払いプロバイダー (Adyen など)
支払い取引の円滑化にのみ関係します。 このサービスを呼び出す前に収益化戦略 (API の使用メトリックを支払い額に変換するなど) を適用する必要があります。
Azure API Management の組み込みの機能を使用して導入を促進し、リスクを排除します。 API Management の特定の機能の詳細については、「API Management での収益化のサポート方法」を参照してください。
基盤システムへの収益化戦略のコーディング方法に柔軟性を持たせたソリューションを、サンプル プロジェクトと同じアプローチで導入してください。 柔軟性のあるコーディングにより、変更に随時対応し、そのリスクとコストを最小限に抑えることができます。
ご利用の Azure サブスクリプションでサンプル プロジェクトを導入するには、収益化に関する GitHub リポジトリのドキュメントに従ってください。
証拠に基づく意思決定ができるよう、API がどのように使用されているかを定期的に監視しましょう。 たとえば、顧客離反をうかがわせる証拠がある場合、前述の手順 1. から手順 5. を繰り返して、その原因を特定して解決します。
継続的な進化
上記のすべての手順を見直して再評価することで、収益化戦略を定期的に確認しましょう。 顧客の実態や API の提供にかかるコスト、市場で変化する競合関係への対応について理解が深まるにつれ、いずれ収益化戦略を刷新しなければならない場合もあります。
収益化戦略は、API 導入の成功の 1 つの側面にすぎない、ということを覚えておいてください。 その他にも次のような側面があります。
- 開発者の経験
- ドキュメントの質
- 法律条項
- 約束されたサービス レベルを満たすために API をスケーリングする能力。
次の手順
- API Management での収益化のサポート方法。
- 関連する Git リポジトリを使用して、Adyen または Stripe 統合のデモをデプロイします。