Office アドイン サービスをアップセルするライセンスを実装するImplement licensing to upsell your Office Add-in services

サブスクリプション サービスによってサポートされる Office アドインを作成する場合、アドインが公開できる機能やメッセージングは、顧客がそのサービスに対して支払いを行ったかどうかによって異なります。この記事では、ライセンスを提供してサービスをアップセルする方法について説明します。また、アドインを取得する方法に基づいて、個人や組織のライセンス状態を処理する方法についても説明します。If you're building an Office Add-in that is backed by a subscription service, your add-in can expose different functionality or messaging depending on whether the customer paid for that service. This article describes how to deliver licensing and upsell your services. It also explains how to handle licensing state for individuals and organizations, based on how the add-in is acquired.

手順 1:すべての顧客に単一のマニフェストを使用するStep 1: Use a single manifest for all customers

アドインの配布とメンテナンスを容易にするために、AppSource に単一のアドインを提出することをお勧めします。To make distributing and maintaining your add-in easy, we recommend that you submit a single add-in to the Office Store. このように、アドイン コマンドやシングル サインオンなどの新機能を追加すると、これらの機能はすべての顧客に提供されます。さまざまな顧客に対して異なるアドインをサポートすることについて心配する必要はありません。また、マニフェストを変更するときに、各顧客の管理者に連絡する必要もありません。That way, as you add new features, such as add-in commands or single sign-on, those features are made available to all customers; you don't need to worry about supporting different add-ins for different customers, and you don't need to contact each customer’s administrator when you change the manifest.

Note

一部のカスタマイズ シナリオはまだサポートされていないため、たとえば、リボンに別のアイコンを使用する場合や、アドイン コマンドに別のグループ名を使用する場合などは、カスタム マニフェストを顧客に提供する必要があります。Because some customization scenarios are not yet supported, you might have to provide a customer a custom manifest; for example, if you want to use a different icon on the ribbon or a different group name for add-in commands.

手順 2: ライセンス データベースを作成するStep 2: Create a licensing database

組織に対して Office アドインを販売するには、ライセンス データベースを作成する必要があります。To sell Office Add-ins to organizations, you need to create a licensing database. これは、次の理由から必要になります。This is necessary because:

  • 多くのソフトウェア ベンダーでは、ベンダー独自のライセンス システムを通じて、独自の請求/支払いモデルと選択したプライス ポイントを使用してアドイン (および、アドインをサポートするサブスクリプション サービス) を販売しています。Many software vendors sell the add-in (and the subscription service that backs it) through their own licensing system, via their own invoices/payment models and at the price points they choose.
  • 一元展開では、ユーザーが AppSource からアドインを購入して、それらを展開することができません。AppSource の有料アドインは、現在、個人用 ID (Microsoft アカウント) でのみ動作し、職場または学校のアカウントでは動作しません。Centralized deployment does not allow users to buy add-ins from the Office Store and deploy them. Office Store paid add-ins today only work with personal identities (Microsoft accounts), not work or school accounts.

そのため、ライセンス データベースを作成するか、既存のライセンス データベースを使用する必要があります。これは、次のものを記録します。As such, you must build a licensing database (or use your existing licensing database). This might record:

  • 顧客を一意に識別する、組織のテナント ID。The organizational tenant ID that uniquely identifies the customer.
  • 組織の名前。The organization name.
  • その顧客に販売したライセンスの数 (これは無制限サイト ライセンスにできます)。The count of licenses you have sold to that customer (this can be an unlimited site license).
  • ライセンスが割り当てられているユーザー全員のユーザー名/ユーザー ID のリスト。A list of the usernames/user IDs of all users who have a license assigned.
  • 各ユーザーのライセンスが試用版、有料版ベーシック、有料版プレミアムのどれなのか。Whether the license for each user is trial, paid basic, or paid premium.
  • この組織に所属するユーザーをブロックするかどうか (たとえば、ユーザーはサービスを使用し続けるが購入はしない場合など)。Whether users belonging to this organization should be blocked (for example, if they keep using the service but do not purchase it).
  • 内部販売システムへのリンク。これを使用すると、特定の組織のライセンスを、その販売のユーザー自身の記録にマップすることができます。Links to your internal sales system, which you can use to map a given organization’s license(s) to your own records of that sale.

このデータベースはアドインに、次のような API を公開できる必要があります。This database should be able to expose an API to your add-in that might be similar to the following.

www.contoso-addin.com/VerifyLicense.aspx? Username=xxx; autoProvision=1

    Return enum:

        - Organization has paid license, and User has paid license
        - Organization has paid license, and User has trial license
        - Organization has paid license, and User has no license
        - Organization has no license, and User has trial license
        - Organization has no license, and User has no license

この API は、アドインが顧客の社内で実行されるときに呼び出されます。This API is called when the add-in runs on a customer’s premises. これはパブリックにアクセスできる必要があります。It must be publicly accessible.

通常は、少なくとも一定期間、アドインを誰かに試用してもらうことをお勧めします。購入したライセンスよりも多くのライセンスを使用している顧客のフォローアップを計画します。In general, we recommend that you let anyone try your add-in, at least for a certain period of time. Plan to follow up with customers who use more licenses than they have paid for.

ユーザーに有効なライセンスが付与されるかどうかを選択するビジネス ロジックは、ユーザーの判断に任されます。次のようなアプローチが考えられます。The business logic for choosing whether or not a user is given a valid license is up to your discretion. The following are some possible approaches.

常にライセンスを付与するAlways give licenses

任意の組織で誰もがアドインを試用できるようにしようと決定した場合。アドインの大量使用を確認した場合は、営業チームが顧客にアプローチして、顧客にライセンスを販売できます。You might decide you want to let anyone from any organization try your add-in. If you see high-volume usage of your add-in, your sales team can approach customers to sell them a license.

アドインの使用を継続しながら購入はしない顧客をブロックする内部メカニズムを組み込むことができます。You can include an internal mechanism to block customers who continue to use the add-in without making a purchase.

ライセンスの制限を超えた場合の判断Discretion when exceeding license limits

組織がライセンスを 200 購入する場合に、201、210、または 300 のユーザーがアドインを使用しようとしたときに起きることを検討します。If an organization buys 200 licenses, consider what happens when 201, 210, or 300 users try to use the add-in. 一般的に、グループのサイズは人々がチームや組織に加わったり離れたりするにつれて変化するため、何らかの判断を適用してシームレスなカスタマー エクスペリエンスを維持することをお勧めします。Generally, we recommend that you apply some discretion to preserve a seamless customer experience, because group sizes change as people join and leave teams or organizations. ただし、アドインで使用するサービスの実行に高いコストがかかる場合は、ライセンスの制限を厳密に決定します。If the service your add-in uses is expensive to run, however, you might decide to be strict about licensing limits.

先着順を基にした実施Enforcement based on first come, first served

最初に割り当てられたユーザーがライセンスを受け取り、ライセンスの最大数に達した後は、それ以上のユーザーに対してライセンスを拒否するようにします。You might want to let the first assigned users receive a license, but refuse licenses to any more users after the maximum number of licenses has been reached.

同時使用を基にした実施Enforcement based on concurrent usage

過去 30 日間にアドインを使用したユーザーのみをカウントするようにします。たとえば、最大 200 人のユーザーにライセンスを許可できます。ユーザー 201 がその月のアドインを使用しようとしても、アクセスは許可されません。You might want to only count users who have used the add-in in the last 30 days. For example, you might allow up to 200 users to have a license. If user 201 tries to use the add-in that month, they will not be granted access.

日付を基にした試用の実施Date-based enforcement of trials

日付を基にした実施を使用します。たとえば、A 社がライセンスを購入しておらず、10 人のユーザーがアドインを試用している場合、そのユーザーがアドインを 30 日間 (試用版として) 使用できるようにします。B 社が 20 人分のユーザーのライセンスを購入しており、B 社の別のユーザー 5 人が試用する場合、そのユーザーは 60 日間、試用版として使用できる可能性があります。You might want to use date-based enforcement. For example, if company A has not bought a license and 10 users try your add-in, you might let them use it (as a trial) for 30 days. If company B has bought a license for 20 users, and another 5 users from company B try it, they might get to use it as a trial for 60 days.

手順 3:アドインを変更して OpenID 認証でユーザーを認証し、シングル サインオンを使用するStep 3: Modify your add-in to authenticate the user with OpenID authentication, and use single sign-on

アドインを使用している人に合わせてアップセル可能なインテリジェント エクスペリエンスを提供するために、アドインは現在のユーザーが誰なのかを知る必要があります。To provide an intelligent experience that can upsell depending on who is using the add-in, the add-in needs to learn who the current user is.

アドインで OpenID 認証を使用する場合、ユーザーは個人用 ID (Microsoft アカウント) か、職場または学校のアカウントを使用してサインインできます。When you use OpenID authentication in your add-in, users can sign in using a personal identity (a Microsoft account) or a work or school account.

また、シングル サインオンを使用する場合、ユーザーは Office にサインインするときと同じ ID を使用して、自動的にアドインにサインインされます。(Office 2013 または Office 2016 ユーザーは、手動によるサインインが必要です。)Also, when you use single sign-on, users are signed in to the add-in automatically with the same identity they use to sign in to Office. (Office 2013 or Office 2016 users still need to sign in manually.)

手順 4:アドインを変更してライセンスの状態を確認するStep 4: Modify your add-in to look up licensing state

次に、アドインはユーザーに関する情報を識別する必要があります。Your add-in must next identify information about the user.

職場または学校のアカウントでサインインするユーザーの場合は、アドインに Oauth のサポートを追加できます。For users who sign in with a work or school account, you can add support for Oauth to your add-in. 詳細については、「Office アドインで外部サービスを承認する」を参照してください。For details, see Authorize external services in your Office Add-in. これにより、Microsoft Graph を使用して、ユーザーに関する次の情報を取得できます。This allows you to use Microsoft Graph to get the following information about the user:

  • 組織のテナント ID。組織の取得メソッドを使用します。Their organizational tenant ID, via the Get organization method.
  • ユーザーに割り当てられているロールのリスト。getMemberObjects アクションを使用します。The list of roles that are assigned to the user, via the getMemberObjects action.

    テナント管理者ディレクトリのロールには、次の特定の ID があります。62e90394-69f5-4237-9190-012177145e10。The tenant admin directory role has the following specific ID: 62e90394-69f5-4237-9190-012177145e10. 他のロールも照会できます。You can query for other roles as well.

詳細については、「Microsoft Graph のアクセス許可スコープ」を参照してください。For more information, see Microsoft Graph permission scopes.

この情報をライセンス API に渡します。Pass this information to your licensing API.

手順 5:カスタム ブランドを適用するStep 5: Apply custom branding

特定の顧客のアドインの再ブランドをサポートできます。これを行うには、アドイン サービスがアクティブになったときに、現在のユーザーの組織 ID を渡します。これは、2 つの方法のいずれかで実行できます。You can support the rebranding of your add-in for a particular customer. To do this, you pass the current user's organization ID when your add-in service activates. You can do this in one of two ways:

  • 組織のテナント ID を使用して、スプラッシュ スクリーンで使用する組織のロゴまたは名前を取得します。Use the organizational tenant ID to retrieve the organization's logo or name that is to be used on the splash screen.
  • アドイン マニフェストが組織固有の場合は、すべての組織に共通のバックエンド サービスを使用しますが、その組織の名前 (または ID) を URL パラメーターまたはアクティベーション URL のパスとして含めます。If the add-in manifest is organization-specific, use a common backend service for all organizations, but include that organization’s name (or ID) as a URL parameter or path in the activation URL.

組織が特定のブランドを持っていないか、必要としない場合は、一般的なブランドに戻すことができます。You can fall back to generic branding if the organization does not have or need specific branding.

手順 6: ライセンスの状態に基づいてアドイン体験を変更するStep 6: Modify the add-in experience based on licensing state

アドインのビジネス ロジックは、ライセンスの状態に基づいて、ユーザーにさまざまな体験を提供する必要があります。次に例を示します。Your add-in’s business logic should provide a different experience to the user based on the state of the license. For example:

  • 職場または学校のアカウントでサインインしたユーザーの場合。For users signed in with a work or school account:
    • ユーザーが有効なライセンスを持っている場合は、ブランド化された有料の体験が得られます。If the user has a valid license, they get a branded, paid experience.
    • ユーザーが試用版ライセンスを所有しており、その組織がライセンスを購入している場合は、ユーザーの IT 部門に連絡してライセンスを取得してくださいという通知が表示されることがあります。If the user has a trial license and their organization has purchased licenses, they might see a notification to contact their IT department to get a license.
    • ユーザーが試用版ライセンスを所有しており、その組織がライセンスを購入していない場合は、ライセンス購入のメリットについての詳細を示すメッセージが表示されることがあります。If the user has a trial license and their organization has not purchased licenses, they might see prompts to learn more about the benefits of purchasing a license.
    • ユーザーが有効なライセンスや試用版のライセンスを所有していない場合は、ライセンスの購入を IT 部門に依頼するような画面が表示される可能性がありますが、アドインの使用はブロックされます。If the user does not have a valid or trial license, they might see a screen that encourages them to ask their IT department to purchase licenses, but be blocked from using the add-in.
  • Microsoft アカウントでサインインしたユーザーの場合。For users signed in with a Microsoft account:
    • 有料ライセンスを持っていないユーザーには、ライセンス購入の要求が表示されることがあります。Users who do not have paid licenses might see a request to purchase a license.

従業員の中には、管理者への連絡方法を知らない人もいるので注意してください。できる限り、適切で有益なユーザー エクスペリエンスを提供します。Note that some employees might not know how to contact their administrator. Provide graceful or informative user experiences where possible.

手順 7:顧客を獲得するStep 7: Win the customer

顧客にアドインの成功体験があるかどうかを理解するために役立つアプリ内テレメトリーを含めます。この情報を使用して、連絡先の顧客や連絡する時期を決定できます。ベスト プラクティスとしては、顧客にアドインを試用してもらい、アプリケーションや電子メール (AppSource へのリンク) でフォローアップしたり、本人を直接フォローアップします。Include in-app telemetry to help you understand whether customers have a successful experience with your add-in. You can use this information to determine which customers to contact and when. As a best practice, let customers try your add-in, and follow up in the app, by email (link to AppSource), and in person.

市場投入のベスト プラクティスについては、「Office ISV GTM ガイド」を参照してください。For go-to-market best practices, see the Office ISV GTM guide.

手順 8:販売を記録するStep 8: Record the sale

顧客の購入時に、その顧客のレコードでライセンス データベースを更新します。名前または電子メールでライセンス データベース内の顧客を検索し、販売されたライセンスの数を記録します。When a customer makes a purchase, update your licensing database with the record for that customer. Look up the customer in your licensing database by name or email, and record how many licenses were sold.

手順 9:顧客にアドインを展開するStep 9: Deploy the add-in to the customer

顧客の購入後に、アドインを顧客の環境に展開する必要があります。アドインは、顧客のテナント管理者や再販業者が展開することも、自分で直接展開することもできます。After a customer makes a purchase, you need to deploy the add-in to the customer’s environment. The customer’s tenant administrator or a reseller can deploy the add-in, or you can deploy it yourself.

テナント管理者は一元展開を使用してアドインを展開できます。A tenant administrator can deploy the add-in via centralized deployment. アドインが AppSource に公開されている場合、管理者は Office 365 の管理センターのページの Office アドインの追加のリンクからアドインを選択できます。If your add-in is published in the Office Store, the admin can select it from the Add an Office Add-in link on the Office 365 admin center page. アドインにカスタム マニフェストがある場合、管理者は自分のコンピューターか URL からマニフェストをアップロードする必要があります。If your add-in has a custom manifest, the adminstrator will need to upload the manifest from their computer or a URL.

関連項目See also