マッシュアップというムーブメントの追い風を受け、WebAPIを公開する企業が増えつつある。しかも、その多くは、WebAPIを無料で提供している。そこで、この節では、その収益モデルを整理し、WebAPIを提供している企業はどうやってビジネスを成立させているのか類型化してみたい。なお、WebAPI提供企業の収益モデルは下記のいずれか一つだけに当てはまるわけではなく、いくつかのモデルを兼ね備えている場合が多いので、注意されたい。
自社の商品情報をWebAPIとして提供し、WebAPIの利用によってその商品の売り上げを拡大し、収益を得ようというモデルである。代表的なものは、AmazonのAmazon Webサービスであろう。Amazonは、WebAPIを提供することによって、自社のショッピングモールに来たユーザーだけでなく、AmazonのWebAPIを利用した別のサービスに訪れたユーザーもAmazonの顧客として取り込むことができ、商品の売り上げを増加させることができる。また、Amazonというマス向けのウェブサイトでは売れない書籍が、特定のニッチなテーマに特化したサービス経由では売れる、など、ロングテール的な効果も発生している。また、WebAPIの利用側は、例えば書籍のジャンルを指定しておくだけで、そのジャンルの人気書籍を広告として自動的に掲示することができる。そうすることで、WebAPIを利用しなかった際の手動オペレーションに比べて、WebAPIの利用側の運用コストは大幅に軽減される。
自社プロモーション型に似ているが、提供する情報が、自社の商品情報ではなく自社のクライアント企業など他者の広告であるというケースである。収益源は、自社のクライアント企業などからの広告料である。国内では、リクルートや楽天、Yahoo!オークションなどのWebAPIが該当するだろう。リクルートを例にとると、例えば、ある飲食店が、リクルートの情報誌やウェブサイトに広告料を支払い出稿すると、リクルートが運営するメディアだけでなく、リクルートのWebAPIを利用した別のサービスにも広告が展開され、より多くのアクションを得ることができる。また、自社プロモーション型・広告代理店型ともに、WebAPIを利用する側は、アフィリエイトサービスとの連携により、そこからの商品購買などアクションが発生した場合にアフィリエイトフィーを得ることができる。このようなWebAPIとアフィリエイトの連携によって、小規模のサービスにもより効率的な広告収入の道が開けたといえよう。なお、中規模以上のサービスの場合、WebAPI提供元と個別契約を交わし、WebAPIを通じて取得した情報を掲載し、情報掲載料として定額の収入を得るというスキームでの提携も行われているようだ。このように、WebAPIを提供することで、WebAPI提供元としては、外部サービスとの相互運用性を高め、より多くの提携先を獲得できる可能性がある。
WebAPIが提供する情報の中に広告を埋め込み、その広告収入を収益源とするモデルである。有名どころでいうと、Google Maps APIの利用規約では、将来地図上に広告を掲載する可能性があることが示されている。その他、検索系のWebAPIにおいて、検索結果の中に一行広告を埋める等の方法も考えられる。
このモデルは、提供するWebAPIとかかわりの深い自社のサービスや商品へのロックインを狙ったものである。特徴としては、参照系だけでなく、更新系の機能も持つものが多い。例えば、セールスフォースが提供する「Apex API 8.0」は、自社がSaaSとして提供する有料のCRMサービス「Salesforce.com」上のデータに対して、基本的なCRUD操作をサポートするものである。このWebAPIを提供することで、ユーザー企業は、自社の独自システムと連携させるなどして、Salesforce.comをさらに便利に利用できる。また、セールスフォースは、中小ベンダーなどが自社で開発したアプリケーションを販売することができるマーケットプレイス「The AppExchange」を提供している。そのため、ユーザー企業は、必要な機能を自社で開発せずとも、マーケットプレイスを通じて購入したアプリケーションを利用し、Salesforce.comに組み込むことも可能だ。このようにして、自社のプラットフォームにユーザーをロックインし、そのプラットフォームを有料提供することで、継続的な収益をあげることができる。
グーグルやはてな、ライブドア等が提供する、検索機能や認証機能、投稿機能、地図機能などの汎用的機能を中心としたWebAPIは、ここに含まれるといえよう。これらの企業が提供するWebAPIが多くのサービスで利用されれば、これらの企業のサービス・プラットフォームと接続するサービスが増え、結果的にAPI提供側・利用側双方にとってのメリットが生まれる。いわば、これらの企業が提供するサービス・プラットフォームと、それらの機能をWebAPIで利用するサービスの両者が、相互にメリットを享受できるエコシステムが形成されるのである。そして、結果として多くのユーザーを獲得できれば、つまり、エコシステムが大きくなれば、たとえ後付けでも、その循環の中のどこかに換金ポイントを設けることでビジネスは成立するのである。
有料版のWebAPIを提供しつつ、利用期間や機能を限定する、或いは、サービスレベルに差をつけるなどしてダウングレードしたバージョンを無料で提供する、というモデルである。ダウングレードバージョンを使ってから、段階的に有料版のWebAPIへ移行してほしいという意図のもと、無料版を提供するのである。後述する、イーストの提供する経路検索WebAPI「RailGo」では、一ヶ月の試用期間を設けている。
その他のモデルとして、いずれは有料提供に切り替えるという目論見の元、まずはユーザーを増やすことを目的に無料提供を続ける「いずれは有料提供型」や、WebAPIの提供を通じて、WebAPI利用者やエンドユーザーの利用傾向や行動履歴を蓄積・ウオッチし、そこからマーケティングデータを得る「マーケティング型」も考えられる。また、全く収入源は無いが、無料でWebAPIを提供して多くのユーザーを獲得し、最後はどこかのポータルや投資ファンドに売り抜けることを目的とする「売り抜け型」も考えられる。こういった意図を持ったサービスは既に存在しているかもしれないが、その意図を明らかにすることは少ないため、ここでは例示することができない。
WebAPIを提供し、WebAPIを利用する側から収入を得るモデルである。このモデルは最も理解しやすいモデルであろう。例えば、ITベンダーやコンテンツプロバイダーは、提供物をメディアにパッケージングしてサービス提供者へ販売してきたが、その提供形態が、CD-ROMなどのメディアでの提供ではなく、ネットワーク越しでの提供となったわけである。例えば、イーストが提供する「RailGo」は、経路検索ソフト「駅すぱあと」のデータをWebAPI化したものであるが、月額10,500円から、トランザクション数による課金モデルを採用している。「駅すぱあと」のデータは、一般企業には容易に構築・運用できない膨大なデータベースによって構成されている。このように希少性のあるデータや機能を持つ企業の場合、WebAPIを有料で提供した収益モデルも考えられよう。
次に、無料モデルはあくまでも「お試し版」として提供し、有料モデルへ課金した際にはオプショナル・サービスやサポートを提供するというモデルも考えられる。米Googleが提供する「Google Maps for Enterprise」では、年間1万ドルから、トランザクション回数による課金モデルを採用している。このサービスを利用すると、無償版のGoogle Mapsでは表示される広告をOFFにできる、社内からしかアクセスできない（限定されたユーザーにしか利用されない）システムに組み込める、利用にあたっての米Googleからのサポートを受けられる、等のメリットがある。（このサービスは北米・欧州だけで提供されている模様）
また、有料モデルでは、一定のサービスレベルを保証するというモデルも考えられる。マッシュアップサービスを提供する側には、「マッシュアップを導入したサービスの稼働率は、利用するWebAPIの稼働率を掛け合わせた数字を超えることはできない」というリスクがある。そこで、稼働率を重視するサービスにおいてマッシュアップを導入したい場合、サービスレベル保証が無い無料のWebAPIではなく、サービスレベルの保証がある有料のWebAPIを利用するという選択肢も十分考えられよう。
こちらのモデルは、WebAPIを利用する側ではなく、WebAPIを組み込んだサービスを利用するエンドユーザーに課金するというモデルである。筆者は、それが明示的に示されたWebAPIを発見したことは無いが、例えば、オンラインウォレットサービスの事業者が、無料版ユーザーに対してはその事業者の提携するモールでしかウォレットを利用させず、有料版ユーザーに対しては、WebAPIを通じてあらゆる事業者に対してそのウォレットを利用できるようにするサービスを提供する、等の可能性も考えられる。
ただ、ネットサービスにおけるトレンドとして、エンドユーザー向けサービスを有料提供するのはなかなか難しく、少数のエンドユーザーに有料課金するサービスよりも、無料で多くのエンドユーザーを集めるサービスのほうが優勢にある。他社に対して、何らかの圧倒的優位性を確保できているサービスでないと、このモデルの適用は難しいであろう。
このほかの有料モデルとしては、ちょっとした投資的なアプローチとして、WebAPIを利用するサービスがビジネスで成功を収めた際に、その収益の一部を得るという「成功報酬型」などもありえるかもしれない。
また、WebAPIの利用側がWebAPIから得たデータに、自らが持つ何らかのデータを付加し、それをまたWebAPIとして有料提供し、その利用料金を、一次WebAPI提供者と二次WebAPI提供者で按分するようなモデルも、可能性としては考えられる。
課金制度としては、WebAPI利用者課金型、エンドユーザー課金型ともに、トランザクション数やユーザー数などによる従量課金制と、固定課金制の二種類の課金制度が考えられる。従量課金制は、料金体系の料金カーブの係数を変えたり、階段状にする等して、ユーザーの利用を促進することができる。また、固定課金制とは、つまり「使い放題」であり、WebAPIのトランザクション数やユーザー数によってあまり提供側のコストに影響が無いケースや、トランザクション数やユーザー数が増えることで提供側にメリットが生まれるようなケースで採用するのがよいであろう。
このように、WebAPIを提供する上でも様々な収益モデルが存在し、たとえ無料でWebAPIを提供しても、立派にビジネスとして成立することが分かった。なお、WebAPIを公開し、それがヒットした際には、何百万、何千万というトランザクションが寄せられる。それらのトランザクションは、一つ一つは軽くてもとにかく量が多い。そこで、システムを開発する上では、稼働率を確保してWebAPIの利用側に迷惑をかけないような設計とともに、トランザクションあたりの処理コストを下げつつ、スケーラビリティの高い設計が必要となる。低コストでの高いスケーラビリティの実現と安定した稼働こそが、WebAPIを開発する上での重要な要素であろう。そこで有用なのが、システムの自動化・自律化のノウハウや、別章で紹介しているOSSやフレームワーク、ライブラリの利用である。Web2.0的と称されるムーブメントの中には、未だエンタープライズユースに生かされていない有用なノウハウやプロダクトが多数転がっている。このようなシステムを構築する上では、それらをうまく取捨選択して活用していく必要があるであろう。
また、WebAPIの利用側としては、自身のシステムに組み込むWebAPIに関して、それが提供する機能や情報の内容だけでなく、そのサービスレベルやサポート体制なども理解した上でのが重要となってくるであろう。特に、エンタープライズシステムの開発に携わる者としては、サービスの稼働率確保は重要なテーマである。WebAPIの利用によってシステム開発コストを大きく下げることができるのは大きな魅力だが、WebAPIの選定を誤り、ユーザー企業に提供するサービスの価値を落としてしまわぬよう、十分な注意を払いつつ、最適なシステム構成を選択されたい。
本頁の著作権： Copyright (c) XML コンソーシアム 2007 All rights reserved.