SaaSオファーの収益化

2022.06.13
ストア公開
Azure ADSaaSオファーサブスクリプション管理ユーザー管理収益化
この記事は約17分で読めます。

はじめに

Microsoft AppSource、Azureマーケットプレースなどのコマーシャル マーケットプレースにおいて、潜在顧客がTeamsアプリを「課金あり」のSaaS オファー（transactable SaaS offer）として購入できるようにするには、「課金あり」用のランディングページとWebフックのエンドポイントを実装して、パートナーセンターの [Technical configuration] タブに設定する必要があります（Add technical details for a SaaS offer in Azure Marketplace）。たとえば、下図①と②のようにそれぞれ、ランディングページとWebフックのエンドポイントを設定します。

ContosoAMPBasic/README.md (github.com)

また、発行者ポータルを実装して、発行者ポータル上で顧客側のIT管理者が行った変更をSaaS fulfillment APIsを介してMicrosoft側に通知すると同時に、Webフックを介して受け取ったMicrosoft側の情報を発行者ポータルに反映させることにより、Microsoft側と発行者側の間でサブスクリプション情報を同期させる必要もあります。

購入・管理プロセスで実現すべきAPIフロー
SaaS fulfillment APIs in the Microsoft commercial marketplace

本稿では、以下のコードサンプルを参照しながら、たとえば上記の「ランディングページとWebフックの実装」「サブスクリプション情報の同期」など、SaaSオファーの収益化のために必要となるコーディングを概観します。具体的な実装方法については、これらのコードサンプルもあわせてご覧ください。

きれもん

SaaS Monetizationコードサンプルのうち、ランディングページ、発行者ポータル、Webフックに関係するプロジェクトは以下のものになります。

きれもん

学習モジュールMastering-the-Marketplaceのうち、次の動画とハンズオンが参考になります。

SaaSオファーの購入プロセス

「ランディングページ」とは、SaaSオファーの購入プロセスにおいて、潜在顧客がコマーシャル マーケットプレース上の [Configure account] ボタンをクリックしたときに表示されるWebページのことです。

きれもん

「ランディング」（landing＝着地、着陸）というのは、「購入プロセス開始後に『着地』する先のWebページ」といった意味合いになります。

ランディングページにおいては、「サブスクリプションをアクティブにするためのボタン」「ライセンスを購入するためのボタン」「アクティブ化された後の一連の案内」などの提供が想定されます。下図の2つの例のような「ようこそ」（Welcome）ページを表示させて、これらの機能を提供します。

ランディングページの例1
move from paid add-ins to paid web apps with free add-ins
（SaaS Monetizationコードサンプル）
ランディングページの例2
Commercial Marketplace SaaS SDK Sample Application Demo

「アクティブ化された後の一連の案内」については、以下のような内容の案内を行うページを用意しておきます。

  • 各種管理方法
  • サポート問い合わせ方法
  • 説明書
きれもん

ランディングページの作成についての概要は、Build the landing page for your transactable SaaS offer in the commercial marketplaceをご覧ください。

購入プロセスの必須要素

Azure Active Directory and transactable SaaS offers in the commercial marketplaceによれば、下図の購入プロセスにおいて、AAD SSO認証に基づく②～④のプロセスの実装は、「必須」とされています。

きれもん

同資料において、実装することが「必須」とされているのは、購入プロセスとサブスクリプション管理までです。ユーザー管理の内容については「推奨」とされています。本稿では、購入プロセス、サブスクリプション管理までの概要をまとめていきます。

ランディングページを開く際には、デフォルトの USER.READ スコープのアクセス許可のみで開く（つまり、追加の認証プロンプトなしでSSOされる）ようにしておきます（下図②）。サブスクリプションをアクティベートする前の段階で、適切でない認証プロンプト（管理者の同意が必要な認証プロンプトなど）が表示されるのを避けるためです。

AAD SSO認証を介したアクセス許可の追加取得は必要な場合に限るようにし、タイミングについてもユーザーがサブスクリプションをアクティベートした後に行います。

次に、ランディングページを開く際にMicrosoft側から渡されるIDトークンを使用して、SaaS fulfillment APIsを介してサブスクリプション情報を取得（下図③）、IDトークン自体から識別情報を抽出、およびMicrosoft Graph APIを介してユーザープロファイルなどのリソースを取得します（下図④）。

これらのステップは、購入プロセスの後に、サブスクリプション管理（ライセンス購入、プラン数・シート数変更、支払い状況確認、サブスクリプションの更新・取り消しなど）、ユーザー管理（プロビジョニング、アクセス権の管理、ユーザー用ページの提供、各種連絡・手続きなど）を行うための準備となります。

課金ありSaaSオファーの購入・管理プロセス
Azure Active Directory and transactable SaaS offers in the commercial marketplace
きれもん

Teamsアプリに対して選択できるのは、「ユーザー毎課金プラン」だけです。「従量課金プラン」は利用できないため、上図の「metering APIs」「metering subsystems」の部分は使用されない形になります。

きれもん

サブスクリプションを作成する操作を指して「purchase」（購入）という表現が使用される場合があります。しかし、サブスクリプションをいわゆる「購入」するだけでは課金はされません。サブスクリプションがアクティブにされてはじめて課金が開始されます。「購入するなら料金を支払わないといけない」と考えるのが普通ですから、この場合は、「購入」とは呼ばないで「作成」という表現を使うようにするほうが誤解がないと言えます。

サブスクリプション作成から課金開始まで (ユーザー毎課金の場合)
[FAQ] How are you notified when a user subscribes to your SaaS offer?
きれもん

AAD SSO認証の実装については、外部からTeamsボットにDM送信のトリガを送るなどの既存のコードサンプルを動かして真似する方法が近道です。

SaaSオファーのサブスクリプション管理

サブスクリプション管理のための機能を利用するために、「発行者ポータル」と呼ばれる内部的なWebページを構築します。発行者ポータルにおいては、Microsoft側と発行者側の間で、サブスクリプション情報を同期させる処理を実装する必要があります。

きれもん

「発行者」（publisher）というのは、顧客やエンドユーザーといった、「サービスを利用する側」である購読者（subscriber）に対する対義語で、「サービスを提供する側」といった意味合いになります。したがって、「発行者ポータル」というのは、SaaSオファーの販売者自身ならびに、ISV（independent service vendor）や顧客(企業)（customer）のIT管理者が、「提供中のサブスクリプションを管理するための内部的なWebページ」ということになります。

発行者ポータル

発行者ポータルは、発行者のための「ポータル」（portal＝入口、玄関）となるWebページです。発行者ポータル上で提供させる機能としては、以下のようなものが想定されます。

  • 登録情報(オファー名、プラン名、契約期間、氏名、組織、emailアドレス等)を閲覧・変更する
  • 追加のアクセス許可(USER.READ以外)を付与する
  • サブスクリプションのステータスを変更する
  • ライセンスを購入する
  • プラン、シート数などの設定を変更する
  • 支払い状況を表示する
  • 使用量を表示する（従量課金プランの場合）

たとえば、SaaS Monetizationコードサンプルにおいては、下図のような発行者ポータルを通して、「ライセンスの購入」ボタン（[Purchase] ボタン）を提供するとともに、ライセンス購入の結果として「ライセンス数」および「ユーザーの一覧」を表示しています。さらに、下図のコードサンプルでは、アカウントにライセンスを割り当てた結果として、アプリ側にも「You do have a paid license」と表示させています。

発行者ポータルの例1（手前は購入されたライセンスを表示するTeamsアプリの画面）
Code sample: Move from paid apps to paid web apps with free apps
（SaaS Monetizationコードサンプル）

また、学習モジュールMastering-the-Marketplaceにおいても、下図のような発行者ポータルを通して、「サブスクリプションの一覧」（Manage All Subscriptions）、「サブスクリプションの詳細」（Subscription Values）、「現在のプラン」（Plan for this Subscription）が表示されるとともに、「発行者アクション」（Publisher Actions）として「サブスクリプションをアクティブにする」（Activate this subscription）や「サブスクリプションを削除する」（Delete (Unsubscribe) this subscription）を選択することによって、「ステータス」（SaasSubscriptionStatus）を「保留」（PendingFulfillmentStart）、「アクティブ」（Subscribed）から、「削除済み」（Unsubscribed）に変化させています。

発行者ポータルの例2
Building a Simple SaaS Publisher Portal in .NET – YouTube
(ハンズオン: Lab 3: Installing a Publisher Portal)
きれもん

学習モジュールMastering-the-Marketplaceでは、アカウントの種類として、ランディングページの場合は不特定の潜在顧客が利用することが想定されるため「マルチテナント」、発行者ポータルの場合は個別のテナントごとに異なるページを表示させることを想定して「シングルテナント」がそれぞれ選択されています。すなわち下図のように、ファイルappsettings.json内に設定されたTenantIdの値は、ランディングページに対しては“common“、発行者ポータルに対してはそのテナントのテナントIDがそれぞれ設定されています。

ランディングページのappsettings.json発行者ポータルのappsettings.json

サブスクリプション情報の同期

サブスクリプション管理において、発行者ポータル上の情報（ひいては発行者側システム内の情報）をMicrosoft側のサブスクリプション情報と同期させる必要があります。サブスクリプション情報の同期は、WebフックとSaaS fulfillment APIsを使用して、双方向の形で行います。

  • Microsoft側の状態変化を発行者ポータル上の情報と同期させるために、Webフックを介してMicrosoft側から通知を受け取ります。「プラン変更の完了」「シート数変更の完了」「支払い済・未払い」などの状態変化についての通知を受け取り、発行者ポータルに反映させて情報を同期させます。
  • 発行者ポータル上で変更した情報をMicrosoft側に同期させるために、SaaS fulfillment APIs（SaaS fulfillment Subscription APIs v2とSaaS fulfillment Operations APIs v2）を使用して、Microsoft側に向けて通知や照会を送ります。通知や照会を送ることにより、Microsoft側に反映させて情報を同期させます。（その後、変更の完了通知をWebフックで受け取って完了確認します。）
きれもん

SaaSオファーのサブスクリプションのライフサイクル全体について状態遷移を図にすると、下図のようになります。Webフック（でマーク）とSaaS fulfillment APIs（でマーク）を利用して、各々の状態遷移に伴う同期処理をコーディングしていきます。

SaaSサブスクリプションのライフサイクル
Managing the SaaS subscription life cycle

発行者側からMicrosoft側への通知と照会

発行者側からMicrosoft側に通知と照会を送るための、SaaS fulfillment APIs のHTTPリクエストを一覧すると、下図のようになります。詳しくは、以下の資料をご覧ください。

Microsoft側から発行者側への通知

Microsoft側から発行者側のWebフックに送られる通知のペイロードとアクションを一覧すると、下図のようになります。詳しくは、以下の資料をご覧ください。

SaaS Monetizationコードサンプル

きれもん

SaaS Monetizationコードサンプルについて詳しくは、Monetize your Microsoft 365 add-in or app through Microsoft Commercial Marketplaceを参照してください。以下の動画にも、わかりやすいデモが提供されています。

下図のように、SaaS Monetizationコードサンプルでは、SampleWebAPIのコントローラ、およびSampleWebAppの各種JSファイルにおいて、それぞれWebフックのアクションに応答するためのハンドラ、およびSaaS fulfillment APIsのHTTPSリクエストを呼び出して行なう処理が実装されていることを確認できます。

SaaS Monetizationコードサンプルのデモ（Code sample: Move from paid apps to paid web apps with free apps）では、AppSourceのモック上で[Purchase]（購入）ボタンを押してサブスクリプションを購入（作成）し（下図①）、その結果として開かれたランディングページ上でサブスクリプションをアクティベートし（下図②③）、[Add User]（ユーザーの追加）を選択してから（下図④）、そのユーザーにライセンスを割り当てています（下図⑤）。その結果、ユーザーの一覧にユーザーが追加されます（下図⑥）。

SaaS MonetizationコードサンプルのTeamsアプリのデモ（[Video] Monetization Code Sample Demo.mp4 (Teamsのデモは12:46から)）の中で、アプリ側にライセンス情報を表示するコードの箇所は、以下のとおりです。下図左側のファイル「SubscriptionsController.cs」では、Teamsボット上にライセンス情報を表示する箇所、下図右側のファイル「HomeController.cs」では、Teamsタブ上にライセンス情報を表示する箇所を、それぞれ確認できます。

まとめ

コマーシャル マーケットプレースで、潜在顧客がTeamsアプリを「課金あり」のSaaS オファー（transactable SaaS offer）として購入できるようにするには、「課金あり」用のランディングページを作成し、WebフックとSaaS fulfillment APIsを使用して発行者ポータル上のサブスクリプション情報を同期させる必要がありました。

実装の雛形としては、学習モジュールとコードサンプルを参考にすることができました。

付録

参考になる資料

参考になるウェビナー、ビデオ

コメント