[AD] Web APIのビジネス化に関する9つのパターン
※ 再び営業用記事です。しばらくの後、別ブログに移します。
MASHUP AWARD 4thが終わり、ちょっと熱の冷めている感のあるWeb API業界ですが。各Web API提供企業の方が頭を悩ましているのがこのビジネス化についてです。Web上で提供するサービスサイトと異なり、PVによる広告モデルを適用することが難しく、各社ともに苦心しているのが実情です。
そこでWeb APIにおけるビジネスモデルについてまとめてみました。
via mapa de tags y artistas en last fm | interactive artist & tag map on Flickr - Photo Sharing!
詳細は以下。
1. 従量課金型
Amazon Webサービスの各種Web APIがこれに当てはまります。例えばAmazon S3やAmazon SimpleDBなどがそうです。Amazon Webサービスは登録しただけで課金がはじまることはありません。あくまでも利用に応じた課金になります。
これの類似パターンとしては、ある一定のトラフィックまで無料で利用でき、それを越えると課金を開始するというものも考えられます。これは個人レベルの簡単なものであれば無料ででき、トラフィックが集まってきた段階で課金するというものになります。
個人的にはこれが最も適切な課金体系ではないかと思われます。個人であれば無料、または安く利用できるのが良く、トラフィックを集めてビジネス化する際には有料としてサービスを保証してもらえるのが適切と考えられるからです。
2. 初期費用や月額費用型
利用に際して初期費用や月額での課金が必ず決まっているパターンです。これは扱っているデータが希少で、価値が高い場合に適用できるモデルです。例えばAdWordsのAPIやOverture（Yahoo! Search Markething）などのWeb APIです。
このモデルは希少なデータや技術を扱っている関係で優位になれます。また、そのWeb APIを使ってマッシュアップはビジネスモデルが前提になります。逆に言えば、マッシュアップ開発者がビジネスモデルを組みやすいWeb APIであれば適用できるモデルと言えます。
3. ビジネス課金
いわゆる商用利用は有料というパターンです。これも分かりやすいモデルと言えます。個人の非商用ではじめたマッシュアップが人気を集め、ビジネス化できそうになった段階で有料に切り替えることができます。この場合はサービスレベルの保証であったり、サポートを受けられたりと言ったことが可能になります。
この手のモデルは数多く、Yahoo! JapanやGoogleでも使われています。日本ではどこどこJPがあります。ただ初期の段階で企業利用しようと思った際に、その交渉を行う手間や、企業サイト内で利用する（企業概要に地図を貼付けるなど）場合に課金が発生するのか規約を注意深くチェックする必要があります。
他にも基本は有料として提供していますが、開発期間として一定期間は無料で利用できるモデルもあります。経路案内のRailGoで使われているものになります。こちらは1ヶ月間の開発期間が設けられています。この場合、一ヶ月にて開発から運用およびビジネス化を目指すのはほぼ不可能なため、ビジネス化を基本として開発を行う必要があります。お試しと捉えず、無料期間と考えた方が良いでしょう。
4. 企業連携型
Web APIのもたらした恩恵に企業同士が提携した際にデータ交換フォーマットや規約が簡単になるということがあります。この場合、提携先（Web API提供元）はデータ提供先に対して請求が発生していると考えられます。
ビジネス課金と似ていますが、提携というレベルまで踏み込めるか否かが異なります。
5. 機能差別型
Web APIに無償レベルと有償レベルの機能差を設ける方法です。Flashでのグラフ生成Web APIである「JSChart」やHTMLやURLを指定してPDF化する「HTML2PDF.BIZ」、「vds」がこの手法をとっています。これによりWeb APIの利用法を把握し、さらに突っ込んだ使い方をしたい場合有料に切り替えるといったことが考えられます。日本ではこのタイプが多いようです。
機能以外でも帯域を変更する等サービスレベルに格差をもたらせることで課金することが可能になります。
6. 手数料型
AmazonのSimple PaymentやGoogle Checkoutなどで見られる課金システムに対しての手数料を受け取るビジネスです。決済システムは未だにシステムを構築する上で難度の高いものになりますので、それをWeb APIで提供する価値は大きいと思われます。
特殊技術型のWeb APIと言えますが、利用者も課金を行っているためトランザクションに対しての課金も行いやすくなります。
以下はWeb API単体で稼ぐのを止めて、何らかのフィードバックを得るものになります。
7. サービス拡充型
Web APIを利用してもらうことで、そのデータ提供元になるサービスへのアクセス数を増やそうというものになります。Salesforce.comのように自社のCRMシステムにプラグインするWeb APIもここに含まれます。この場合重要なのはデータの参照だけでなく、データの追加、更新、削除も同時も行えるようにすることです。参照のみ（フィードなど）のWeb APIが多いのですが、これでは元Webサービスの拡充は行えません。
Web APIを通じてデータを吸い上げ、コンテンツを拡充することによって元Webサービスの魅力を引き上げるのが目的になります。
8. パブリッシング型
二年くらい前までに流行った手法です。Web APIという文字をプレスリリースに含めると掲載される可能性が高かったため、機能追加したパターンです。言わば時流に乗った形です。
しかし現在では通用しなくなってきています。またこの手法であれば元々の意義は達成したと思われますので停止してしまうのも選択肢の一つです。
9. 広告型/販売型
アフィリエイト系やEC系、広告系になります。この場合、公開される場所が多ければ多いほど売上が上げられます。例えばAmazonアソシエイト、アフィリエイト2.0、リクルート系Web APIなどになります。
これも一つのやり方としては正しいものになります。さらに普及させるためにはAmazonのようにおまかせリンクを提供するなどブログパーツを通じてさらに露出を増やす必要があります。
いずれのモデルをとるにせよ、Web APIを通じてビジネスモデルが確立できなければ初期投資は行っても追加投資したりバージョンアップしたりすることは難しくなります。メンテナンスのされないWeb APIでは利用者も減り、意味のないものになってしまうことでしょう。
逆にビジネスモデルが確立できた場合は人員を投入でき、目標管理の上でさらに利用促進を訴えることができるようになります。ぜひ自社のWeb APIに合ったビジネスモデルを見つけ、収益化に臨んでください。
また、逆にこれからWeb APIを提供しようとされている企業であれば、自社の強み（Webサービス面だけでなく技術力やインフラなど）を分析し、それをWeb APIという形を通じて提供するようにしてみると良いでしょう。Web APIのみで収益化ができれば、持続的な開発や開発者向けのサポートなどさらにWeb APIに磨きをかけられるようになるはずです。
MOONGIFTでは御社の強みを活かしたWeb API提供方法、ビジネスモデル化を企画、提案いたします。ご興味のある方はぜひinfo@moongift.jpまでご連絡ください！