先日、TwitterがAPI利用に対する締め付けを突然厳しくしました。元々規約にあった、複数のアプリケーションキーを一つのサービスで利用している問題に対するものですが、利用していないはずの開発者も凍結対象になってしまったようです。
よく知られたところではTogetterもその凍結対象になったサービスの一つで、数週間に渡ってアカウントが停止されていました（現在は復旧済み）。規約違反があればもちろん問題ですが、警告なしに突然凍結するのはあまりにも乱暴と言えますし、問題ないはずのアカウントを凍結するのは開発者に対する裏切りとさえ言えるでしょう。
こうした点からAPIをビジネス利用する上でのリスクが幾つか見えてきます。
規約を十分に確認する
まず利用規約を十分に読み込みましょう。個人がプライベートで作るものについてはあまり関係ありませんが、企業で事業として利用するのであればその内容をきちんと精査しておく必要があります。商用利用について細かく規定されているケースや、利用する上での注意点についても明記されているはずです。
多くのAPIでは個々の企業利用について契約をカスタマイズすることはありません。API提供側からの条件をそのまま承諾することになりますので、自分たちの利用フローが規約を守れるかどうかは注意しなければなりません。
SLAを確認する
サービスレベルが保証されていないサービスを利用するのは危険です。突然の終了であったり、メンテナンスが行われる可能性があります。オンラインサービスの場合、常時アクセスがあるのでAPIが突然利用できないのはリスクになります。しかし、100%のSLAというのは事実上不可能なので、99.8%などでも十分と言えるでしょう。
なお、多くのサービスではSLAを下回った場合にその課金額を上限とした保障となっています。つまり、APIの停止に伴って巨額の損失が発生したとしても、月額利用料程度しか保障は受けられません。そのため、APIが一時停止した場合でもサービスが継続できるような仕組みを設けておくべきでしょう。
有料プランを採用する
APIによっては商用利用を前提として有料プランを提示しています。ビジネスで利用する場合には利用量に応じたプランを適切に選択しましょう。実際には複数人や複数のプロジェクトで使っているにも関わらずアカウントを共有していたりすると適切な保障を受けられないケースがあります。
無料枠の中で使うという手もありますが、無料枠の場合は保障がなかったり、レスポンスが悪い場合もあります。無料プランと有料プランの違いを適切に判別し、商用サービスを提供するのであれば、APIも有料プランを使うようにしましょう。
他サービスとの並列利用
APIは一つのサービスに頼り切るのではなく、類似サービスを複数利用するのがお勧めです。例えば決済においても一つではなく、複数サービスに対応しておくことで万が一APIが一時停止した場合においても切り替えが容易になります。
APIの突然の停止はよくあることです。一ヶ月後に停止されると分かって慌てて開発するのではなく、あらかじめ複数サービスに対応しておくことで乗り換えが容易になります。突貫の開発ではリソース不足になったり、バグが入り込む可能性があります。あらかじめ複数の選択肢を持っておくことで、リスクヘッジできるようになります。
キャッシュ
APIによってはキャッシュを禁止している場合もあるので注意が必要ですが、データ取得系のサービスについてはキャッシュを使うことで一時的なエラーを回避できるようになります。TwitterやFacebookなどのソーシャルサービスでも有効です。
APIは常にネットワークを使うのでデータベースに比べるとレスポンスが悪くなりがちです。キャッシュを使うことでユーザ体験を向上できます。
サービス利用者にキーを登録してもらう
TwitterのようにAPIのコンシューマキー一つに対して10万ユーザまでしか認めていないケースもあります。そういった限界を超えるために、利用者が自分のコンシューマキーを登録してもらうという方法が考えられます。
他にもAPIキー単位でアクセス数を制限している場合も、APIキーを変えることでさらにアクセスできるようになります。APIの利用数が多いサービスで、利用者が開発者であればこういった方法も選べるでしょう。
APIキーを利用しないでも取れるデータを確認する
APIキーは誰がアクセスしているかを特定するために使われます。そのためAPIキー単位でアクセス制限されることになります。しかしAPIによってはAPIキーを使わなくともアクセスできるものもあります。そうしたAPIにおいてはキーを指定しない方がアクセス制限にとらわれなくなります。
自社開発の道を探る
膨大なデータを持っているサービスを自社システムで置き換えるのは難しいですが、機械学習や画像変換など機能を提供するAPIであれば自社開発することもできるでしょう。初期についてはAPIを使うことでリリーススピードを向上させ、サービス規模が大きくなる際に自社開発にリプレイスする方法があります。
API提供側としては、規模や利用量が増えても使い続けてもらえるコストメリットが打ち出せなければなりませんが、利用側としては自社開発に乗り換える方がコストダウンにつながることもあるでしょう。
APIに依存したサービスは必然的にリスクが高くなります。かつてFacebookアプリの仕組みを使って急成長したZingaはFacebookのAPI制限が強まるのに合わせてヒット作を生み出しづらくなっていきました。また、Twitter向けに作られたURL短縮サービスの多くはTwitterは公式短縮URLサービスをリリースしたことで市場が縮小しています。
APIを使い続けることで事業スピードを上がるメリットもありつつ、完全に頼り切らない道を探ることもまたビジネス上のリスクヘッジにつながるでしょう。
