次の方法で共有

ライセンシング

  • [アーティクル]

Mary Kirtland
Microsoft Corporation

2001 年 2 月 21 日

先週のコラム では、Web サービス Favorites の設計段階で検討したユーザーのプライバシーの問題について取り上げました。ユーザーのプライバシーの問題に関する最初の調査に基づいて、私たちは Favorites サービスの最初のリリースでは 3 つの主要な使用シナリオに焦点を合わせることにしました。

  • Web サイト（仮に msdn.microsoft.com とします）は、各ページに、ユーザーがクリックするとそのページを coldrooster.com に保存されているユーザーのお気に入りに追加できるようなボタンを用意します。

  • Msdn.microsoft.com は、もともとは msdn.microsoft.com 自身がユーザーに代わって保存した、お気に入りのページを表示する Web ページを提供します。

  • Msdn.microsoft.com は、もともとは msdn.microsoft.com 自身がユーザーに代わって保存した、お気に入りのページをユーザーが管理できるような Web アプリケーションを提供します。

基本的に、Favorites サービスを使う Web サイトはそれぞれ個別にユーザーのお気に入り用のプライベート ストアを与えられます。このように限定されたシナリオ セットでも、私たちはサービスへのアクセスを既知のクライアントに制限する必要があると判断しました。つまり、サービスをライセンスする必要があるということです。

本稿では、ライセンシングについて詳しく述べます。また、Web サービスのビジネス モデルを決定するときに考慮する問題、ビジネス モデルとライセンシングの関係、私たちが Favorites サービスのために選んだモデルとその理由、また選んだモデルが設計や実装に及ぼす影響についても説明します。

皆さんのコメントに対するフィードバック

本題に入る前に、先週のコラムに対して寄せられた読者のご質問にお答えしたいと思います。

まずユーザーのプライバシーに関して、なぜ私たちが欧州共同体（EU）データ保護規制と取り組むのかお尋ねになった方がいらっしゃいます。「欧州共同体データ保護規制」については、http://europa.eu.int/comm/internal_market/en/media/dataprot/ non-MS link をお読みください。私たちプロジェクト チームは Microsoft で働いており、このサービスを Microsoft が所有する機器で稼動させる計画なので、私たちが配置するサービスは EU データ保護規制に関する Microsoft のポリシーに従う必要があるのです。

現在私たちは Microsoft の Corporate Policy Group と協力し、Favorites サービスを実運用サーバーに配置した場合に Microsoft のポリシーに合うように調整しています。私たちが EU の要件を満たすために「特別」措置を講じる場合は、もちろん皆さんにお知らせします。ただし、私たちが Microsoft のポリシーを守るために必要なことと、皆さんが自社のポリシーを守るために必要なことは、必ずしも一致するとは限りませんのでご注意ください。これは、プロジェクトのライフサイクルを通じて法律顧問と協力し、顧客、スタッフ、サーバーの所在地に関係なく、プライバシー ポリシーが現在の法律を守るよう調整しなければならない理由のよい例です。

また、Favorites サービスを何か他のものと統合して新しいサービスを配置する場合の、ログオン コンポーネントの取り扱い方法について尋ねた方がいらっしゃいます。手短にお答えすると、ログオン コンポーネントのメソッドは Web サービス Favorites を通じて公開されます。このシナリオのクライアント アプリケーションの場合、新しいサービスはこのログオン メソッドを呼び出さなければ、ユーザーのお気に入り管理メソッドを使うことはできません。詳しくは、次のコラムで認証と承認についてお話しますので次週までお待ちください。

Web サービスのビジネス モデル

エンド ユーザーと直接やりとりする大抵の Web サイトは、いくつかのビジネス モデルに集中しているように思われます。ユーザーの観点からいうと、いくつか選択肢があります。

  • ユーザーはサイトのすべての機能を自由に利用できる。

  • ユーザーはサイトの一部またはすべての機能を利用するには、サインアップして無料アカウントを得る必要がある。

  • ユーザーはサイトの一部またはすべての機能を利用するには、料金を支払って会員になる必要がある。会員は通常、一連の機能を特定の期間内で自由に利用できる。

  • ユーザーは、1 回ごとに料金を支払って一部のコンテンツにアクセスする。

ビジネス モデルには、サイトの開発と運営にかかる費用を企業がどのように回収するかというもう 1 つの側面があります。

  • 開発および運営費は、事業を進めるための経費の一部に組み入れられる。

  • ユーザーがサイトの利用料金を支払う。

  • サイト内のスペースを広告主や他のサイトに販売する。

これらのモデルは、このままでは Web サービスで使うことはできません。通常、Web サービスはエンド ユーザーが直接使うことはありません。また、Web サービスはプログラミングの中で使用されるため、広告収入に頼ることはできません。しかし、Web サイトのモデルは、Web サービスのビジネス モデルを定義するときに考慮すべき課題を洗い出すのに役に立ちます。私たちが洗い出した課題は、顧客、価格設定、支払い方法、サブスクリプション、通知、料金請求、決済猶予期間、認証、監査、顧客サービスでした。

顧客

まずどのような顧客と取引契約を結びたいのかが問題となります。通常、Web サービス プロバイダが契約を結ぶのは、その Web サービスをアプリケーションに採用したいと考えているアプリケーション開発者です。Web サービスがユーザー固有のデータを保存する場合、Web サービスは、アプリケーション開発者の代わりに、またはアプリケーション開発者のほかに、エンド ユーザーとの契約を締結するでしょう。また、Web サービス プロバイダが 1 つまたは複数のアプリケーション サービス プロバイダ（ASP）と取引契約を結び、サービスをホストする可能性もあります。また ASP も必要に応じてアプリケーション開発者やエンド ユーザーと関係を築きます。

価格設定

対象顧客が明らかになったら、顧客がサービスにどれくらいの価値を置くか、いくらならサービスに料金を支払うかを検討します。検討すべき事項の 1 つは、リクエストの回数に応じて料金を決めるか（ペイ パー ビュー モデル）、または一定期間内で無制限の使用権を与えるか（リース モデル）です。また、すべてのタイプのリクエストに対して同一価格にするか、すべての顧客に対して同一価格にするか、また所定の顧客に対して常に同一価格にするかも考慮する必要があります。

支払い方法

サービスに対して料金を請求する場合は、支払い方法を考慮する必要があります。通常、エンド ユーザーと直接やり取りする Web サイトはクレジット カードを受け付けます。しかし、Web サービスを利用する企業は、クレジット カードを使って支払いたいとは思わないでしょう。小切手や電信送金での支払いを受け付ける必要があるでしょう。

もう 1 つ考慮すべきこととして、顧客の支払い方法を前払い、後払い、代引きのどれにするかがあります。後払いにする場合は、未払い代金の上限を設けたいと思うでしょう。また、すべての顧客に対して標準の上限を設けたり、顧客ごとに異なる上限を設定したりするやり方もあります。

サブスクリプション

課金をするかどうかにかかわらず、誰がサービスを呼び出しているかを識別する手段が必要になります。この場合、各顧客がアカウント（またはサブスクリプション）を申し込む必要があります。どんな方法にしたらよいでしょうか？

希望者に直ちにアカウントを与えるのか、またはアカウントを与える前に何らかの承認手続きを設けるのか検討する必要があります。承認手続きを設ける場合、顧客が Web 上で申し込めるようにするのか、または顧客サービスに電話をかけて申し込むようにするのか決める必要があります。また、新規のアカウントのリクエストを審査し、承認するスタッフが必要かどうかも決める必要があります。

また、アカウントを与える前にどのような情報をリクエストし、またその他のどんな情報を顧客に尋ねるのかも考える必要があります。先週のコラムで述べたように、多分この情報は公正な取り扱いによって保護する必要のある個人情報のカテゴリに入るでしょう。

もう 1 つ考慮しなければならないのは、顧客がアカウントの ID やパスワードを選択できるようにするのか、それとも無作為の ID やパスワードを生成するのかです。顧客がアカウントの ID を選択できるようにする場合は、ID が重複した場合の対応を考える必要があります。

また、パスワードなどのアカウント情報を顧客がどのように維持するのかを考える必要があります。顧客は皆さんの Web サイトを使うのか、顧客サービス担当者に電話できるのかを決める必要があります。顧客がアカウントの ID やパスワードを忘れてしまった場合どうするかも考える必要があります。

通知と料金請求

サブスクリプションの期間を限定する場合は、期間が切れることを顧客に通知する手続きを決定する必要があります。サービス料金を請求し、顧客の支払い方法が代引きでない場合も同様です。顧客に通知する方法を考える必要があります。たとえば、電子メールを送る、電話をかける、請求書を郵送するなどの方法があります。また、何回まで通知を試みるか、毎回同じ方法を使うかも考える必要があります。サブスクリプションの期間が切れるどれぐらい前に通知するかも考える必要があります。

特にリクエスト回数でサービスに課金する場合は、顧客に請求する頻度を考える必要があります。顧客は、サービス リクエストのたびに請求され、何千通もの請求書が送られてくるのは好まないでしょう。日別、週別、月別に請求をまとめ、請求の内訳を見たい人には詳細な利用状況報告書を提供する方法もあります。

決済猶予期間

サブスクリプション期間が切れたり、支払期限が過ぎたりしたあと、決済猶予期間を設けるかどうかを考慮する必要があります。設ける場合は、決済猶予期間の長さについても考える必要があります。また、決済猶予期間中にアカウントに制限を設けるかどうかも考える必要があります。たとえば、既存の情報の照会だけを許可し、新しい情報の保存はできないようにする方法もあります。また、決済猶予期間中に顧客に追加通知を送るかどうか考慮する必要もあります。

認証

技術的なレベルでは、サービスを利用するのに顧客にアカウントをリクエストする場合は、サービス リクエストが出されたときに顧客を認証する方法を考える必要があります。現在、通信プロトコルの認証機能、アプリケーション レベルの認証、第三者の認証という、3 つの基本的な認証機構があります。最も簡単なアプローチは、Web サービスとメッセージを交換するため使う通信プロトコルの機能を強化することです。たとえば、Microsoft Internet Information Server 5.0 は、HTTP 用に認証機構をいくつかサポートしています。また、Web サービスにカスタムの認証機構を実装する選択肢もあります。たとえば、Web サービスが SOAP メッセージを受け取るときに、顧客の認証情報を SOAP のヘッダに入れて、または SOAP の本文の要素として送ることができます。また、Microsoft Passport など第三者のサービスを使って認証を処理することもできます。

どの機構にもそれぞれ長短があります。安全性に優れた機構もあります。Web サービスを開発するツールによって広くサポートされていない機構もあります。クライアントが第三者から証明書またはアカウントを取得しなければならない機構もあります。パフォーマンスのオーバーヘッドが高い機構もあります。対象顧客を念頭に置いてこれらの長短を考慮して、Web サービスに適した機構を決定する必要があります。現在 Web サービスに対して利用可能なその他の認証オプションについては、Web Service Security の記事をお読みください。

監査

監査プロセスのために集める必要のある情報についても考える必要があります。料金請求や顧客のプライバシーを巡る紛争が生じた場合に、どんな情報が必要になるか考えておく必要があります。リクエストごとに課金する場合は、膨大な量のデータになる可能性があります。毎日集めるデータの量や、データの保管方法を考えなければなりません。紛争を回避または解決するのに役に立つ標準報告書を作成するべきか考慮する必要があります。

顧客サービス

最後に、どのような種類の顧客サービスを提供するかを検討します。サブスクリプションのリクエストと管理のために顧客サービスが必要になるかもしれません。顧客がサービスへのアクセスや利用に関する問題を報告する手段を提供する必要があるかもしれません。また、皆さんのサービスを採用するアプリケーション開発者を支援する手段を提供する必要があるかもしれません。

各種の顧客サービスごとに、サービスの提供のし方を考える必要があります。顧客が Web サイトを使ってヘルプを得られるようにするべきか。顧客が電子メールを送れるようにするべきか。顧客が電話で連絡を取れるようにするべきか。効果的なサポートを提供するために、どんな選択肢を選び、どんなツールやインフラを用意したらよいか、なども考えます。

ビジネス モデルとライセンシング

以上 9 つの課題を考慮すれば、Web サービスのビジネス モデルについてかなりよいアイデアが得られるはずです。これとライセンシングはどんな関係があるのでしょうか？

私たちがライセンスという用語を使う場合、それは Web サービスの使用に関する顧客と Web サービス プロバイダとの間の契約を意味します。誰もが匿名で自由にアクセスできるというビジネス モデル以外は、多分ライセンス契約が必要となるでしょう。たとえば、アカウントやサブスクリプションを申し込むという行為は、顧客が一定の使用条件を受け入れることを意味します。顧客がライセンス契約書を読み、署名しなければ、会員の権利が与えられない場合もあるでしょう。一般に私たちは、ライセンスされた顧客にアクセスを制限する Web サービスを論じる場合に、ビジネス モデルの代わりにライセンシングという用語を使います。

Favorites のライセンシング モデル

Favorites サービスの初回リリース用に私たちが選択したシナリオに基づいて、私たちは既に対象顧客を決定しました。それは、Favorites サービスを採用したいと思うアプリケーション開発者（さらに正確に言うと開発会社）です。次に考慮した点は、顧客がサービスを使う前にサブスクリプションを申し込む必要があるかどうかということでした。もしサブスクリプションを申し込むよう要求しなければどうなるか考えてみましょう。

あるアプリケーションが Favorites サービスを使ってお気に入りの保存を開始したとします。ユーザーのプライバシー保護のために、実際には呼び出し元にそれぞれ専用のデータ ストアを用意してもらうことにしました。この場合データ ストアはどのようにして識別されるでしょうか？呼び出し元がストアの名前を指定したとすると、2 つの呼び出し元が同じ名前を指定する可能性があります。その場合私たちには呼び出し元を互いに区別する手段がありません。固有のデータ ストア識別子を返す CreateStore メソッドを提供することはできます。しかし、固有の識別子が紛失したり、盗まれたりした場合はどうなるでしょうか？固有の識別子を特定の呼び出し元と対応付ける情報がなければ、紛失した識別子を取り出すことはできません。識別子が盗まれた場合はどうすることもできません。事実、私たちは、識別子が盗まれたと報告する人がデータ ストアを作成した呼び出し元と関係があることを確認することさえできません。

結局、顧客にサブスクリプションのためにサインアップするよう求めるのがよいようです。私たちは、紛失したり、盗まれたりしたアカウントの ID やパスワードに対処するのに十分な連絡先情報を集めることができます。また連絡先情報があれば、特定のアプリケーションが Favorites サービスを使う方法に問題があるのを発見したときに連絡することができます。

私たちはこの段階で、私たちのライセンシング モデルを、連絡先情報を知らせ（おそらく私たちのプライバシー ポリシーやその他の放棄書を読んだ）開発組織に与えられる、無料で、無期限のライセンスに決めることもできたでしょう。しかし、私たちはシステム設計全体に及ぼす影響を調べるために、もっと複雑なビジネス モデルをサポートするシステムを設計することにしました。

第 1 段階では、Favorites サービスは、自らのアプリケーションからサービスを使いたいと思う開発組織にライセンスされます。ライセンシングの規則を次に示します。

  • ライセンシーには、一定の期間、サービスへの無制限のアクセス許可を与える。

  • ライセンシーはサービス料金を前払いで支払う。請求金額は、ライセンス期間の長さと、ライセンシーが Favorites を管理するエンド ユーザーの総数で決まる。

  • ライセンシーは、ライセンス期間が切れる 1 か月前に電子メールで通知される。

  • ライセンシーは、ライセンス期間が切れる 1 週間前に電話で通知される。

  • ライセンシーには、ライセンス期間が切れてから 10 日間の決済猶予期間が与えられる。

次の図表にライセンシングのワークフローを示します。

図 1 Favorites のライセンシング ワークフロー

ライセンシングの手続きを開始するには顧客窓口に連絡する必要があります。すべての料金の請求書がライセンシーに送られ、支払いが行われてから、ライセンスが有効になります。ライセンスが有効になると、Favorites サービスの使用に必要なすべての情報が記載された電子メールがライセンシーの会社に送られます。ライセンスが有効になってから最大 24 時間、新しいライセンシーが Favorites サービスに認識されないことがあります。

新規ライセンスの期間はすべて 3 か月で、料金はユーザー 1 人あたり $0.00 です。最初の 3 か月間のあと、ライセンスは 3 か月間、6 か月間、1 年間、または 2 年間と更新できます。請求金額は、ライセンシーが Favorites を管理するユーザーの数で決まります。料金の計算方法は「機能仕様書」 に定められています。

ライセンスの更新料を計算するため、また料金請求を巡る紛争の際の防護策として、Favorites は、サービスの呼び出しとその結果（成功、クライアント エラー、サーバー エラー）をすべて記録します。

なお、MSDN が実際にこのライセンシング モデルの機能をすべて実装するサンプル サービスを配置するのは実用的ではありません。たとえば、私たちは、新しいライセンス リクエストに応答したり、ライセンス期間が切れる 1 週間前にライセンシーに電話をかけたりする顧客担当者を確保できません。また、サンプル サービスを使うために実際に料金を請求したいとも思いません。しかしながら、このライセンシング モデルをサポートできるシステムを設計することが重要だと思ったのです。配置したサービスを試し、難なくライセンスを取得できるようにするには、実装の段階である程度変更が必要になるでしょう。もちろん、設計と実装の変更点はお知らせします。あまり紛らわしくならなければいいのですが。

Favorites へのライセンシングの実装

多分想像できると思いますが、ライセンシング モデルをサポートすることによって Favorites サービスはやや複雑になってしまいました。単に COM コンポーネントを実装し、Web サービスで公開するだけでは十分ではありませんでした。見込み顧客がサブスクリプションをリクエストする方法、顧客が自分のアカウント情報を維持する方法、サブスクリプションの更新の通知を出すツールなどがいつの間にか必要になりました。ライセンス更新料を計算するために、サービスのすべての呼び出しに関するデータを集める必要がありました。また、認証機構を実装する必要がありました。次の図は、Favorites のシステム アーキテクチャの高レベルの見取り図です。

図 2 第 1 段階の Favorites サービスのライセンシング アーキテクチャ

顧客は、サブスクリプションとアカウント情報の変更は、Favorites の Web サイトを通じて要請します。Web サイトはデータ入力を検証し、このリクエストを**ライセンシング（Licensing）**コンポーネントへ送り、リクエストを受け取ったことを確認するメッセージを表示します。一般に、Favorites サービスはサブスクリプションやアカウント情報の変更を即座には許可しません。未処理のリクエストは顧客窓口担当者による検証のため保存されます。リクエストが受け付けられると、リクエストが完了したことを確認する電子メールがライセンシーの連絡先に送られます。

**ライセンシング（Licensing）**コンポーネントは、ライセンシング モデルのビジネス ロジックを実装します。 ライセンシング コンポーネントのメソッドはそれぞれ同じ構造をもっています。すなわち、**監査（Audit）オブジェクトを初期化して監査ログ エントリを作成し、入力パラメータを検証し、ストアド プロシージャを呼び出して適当なデータベースを更新し、必要に応じて電子メールの通知を送り、メソッドの結果と共に監査（Audit）**オブジェクトを更新し、監査ログ エントリを保存します。ビジネス ルールの中には、**ライセンシング（Licensing）**コンポーネントではなく、ストアド プロシージャで実施されるものもあります。IIS SMTP サービスを使って電子メールが送られます。

ライセンシング モデルのワークフローは、ライセンシー（Licensee）および通知（Notifications）データベースに保存された一組のステータス フラグを使って実施されます。たとえば、見込み顧客が新規ライセンスを要請すると、新規ライセンシーの記録は、ステータスが未処理（pending）にセットされた状態でライセンシー（Licensee） データベースに書き込まれます。また、ライセンス更新の通知が送られると、それは**通知（Notifications）**データベースに記録されます。

私たちのビジネス モデルが実際に実装される場合、顧客窓口担当者が顧客の連絡先情報を検証してから、新規ライセンスが与えられ、連絡先情報への変更が許可されることになります。Favorites ライセンス管理システム（Favorites License Management System ＝FLMS） は、顧客窓口担当者がこれを使って未処理のリクエストを表示し、リクエストを受け付けまたは拒否できる Web ベースのアプリケーションです。私たちは顧客窓口担当者を確保できないため、仕組みがわかるように、いくつかのリクエストのサポートのみを実装しました。FLMS は外部の顧客の Web サイトと同じく、その仕組みのほとんどを**ライセンシング（Licensing）**コンポーネントに依存しています。

MSDN のために配置するサービスでは、顧客窓口担当者がいないため、私たちは未処理のリクエストをチェックし、**ライセンシング（Licensing）コンポーネントのサービスを使って自動的にリクエストを許可する AutoAdmin というプロセスを実装しました。また、更新通知を自動的に生成する方法も必要です。これは 1 日に 1 回実行される更新（Renewals）**という別のプロセスに実装されます。

ライセンス更新料を計算し、また料金請求や顧客のプライバシーを巡る紛争を解決するために必要な情報を記録するため、前述の**監査（Audit）コンポーネントを使って、Web サービス Favorites と Web サイトへのすべてのリクエストの結果を監査ログ（Audit Log）**データベースに記録します。それぞれの監査ログ記録には、リクエストを行うライセンシー、リクエストの依頼主のユーザー、リクエストされた操作の種類、その操作がリクエストされた時間、リクエストの処理にかかった時間、リクエストの結果に関する情報が記録されます。この情報を使って、**レポート（Reports）**サービスの中心となる毎日の利用統計を計算します。毎日の利用統計の計算が終わったら、生の監査ログ記録はアーカイブに格納されます。

また、もし Web サービスへの呼び出し元を認証する方法がなければ、このような支援インフラも何の役にも立ちません。私たちは Favorites サービスのためにアプリケーションレ レベルの認証を実装することにしました。Favorites サービスを使いたいと思うアプリケーションは、まず**ログオン（Logon）サービスを呼び出し、キーを取得します。さらに、アプリケーションはお気に入り（Favorites）およびレポート（Reports）**Web サービスへのリクエストのたびにそのキーを提示します。キーが有効であれば、リクエストの処理が許可されます。有効でなければ、アクセスは拒否されます。

結論

このように、Web サービスのビジネス モデルに関して行う決定は、システムに対するリクエスト全体に重大な影響を及ぼす可能性があります。システム アーキテクチャを大幅に変更しなければならないような事態を避けるために、できるだけ早い段階でビジネス モデルを決定するよう試みるべきです。他方、顧客がどのようなビジネス モデルを受け入れるか予測するのは至難の業です。ビジネス モデルの変更に対応できる柔軟な設計を追求するのがよいでしょう。

次週は、認証と承認の問題を中心に、引き続き Favorites サービスを実装するときに遭遇する設計の問題についてお話します。