株式会社サムライズム
山本裕介（@yusuke）

Twitter APIのデファクトスタンダードライブラリ『Twitter4J』の開発者。Twitter API連携支援プログラムであるT4J Enterpriseの提供や、開発ツールの販売を行う株式会社サムライズム代表取締役。また、クリエイティブ集団abstのAPIスペシャリストも務める

近年のサービス開発で、API、特にWeb API/REST APIの重要度は日に日に高まっています。

Web API/REST APIは、端的（または抽象的）に言えば「分散コンピューティング」技術の一種です。歴史的には20世紀から存在しており、特段新しい技術ではありません。

ベンダー独自のプロトコルで実装されたもの、オープンなプロトコルながらも比較的高価なミドルウエアを必要としたもの、プロトコルがオープンかつ商用でもオープンソースのミドルウエアが存在したものなど、似た技術がさまざま発明されてきました。

では、なぜ今、Web APIが注目されているのでしょうか？

理由の1つとして考えられるのは、REST APIはインターネットのプロトコルの中心となったHTTP/Web技術がベースとなっていることです。そしてもう1つは、シンプルかつ柔軟に「変化」に対応できることでしょう。

WebベースのAPI技術は、Google MapsのようなJavaScriptを使ったサイト埋込型に始まり、検索キーワード候補をリアルタイムに提示するGoogle SuggestをはじめとするAjax/リアルタイムWeb技術の流行、そしてTwitter APIを起点とするREST APIの流行という一連の流れで確固たる地位を築きました。

HTTPを通過できるAPI技術としては、CORBAやXML Webサービスなどもありましたが、Webのスピード感の中、HTTPを前提とした必要最小限の仕組みになっているREST APIが好まれています。

わたしはCORBAやXML Webサービスも触ってきた人間ですが、ちょっとドキュメントを見るだけで、さっと試すことができるREST APIの手軽さは非常に魅力的。気付けば、かれこれ7年もTwitter APIを触ってきた次第です。

それほど、APIは魅力的なものだと言えます。

作る作らないの議論はもう終わっている。いかなるAPIを作るか

最近は毎月、毎週、毎日と新しいWebサービスが生まれてきていますが、ローンチのタイミングからAPIを公開するサービスも増えてきました。APIの公開が、サービスの応用範囲と収益性を押し上げることは、すでにGoogleやTwitterが証明していることです。

いまや会社を興す際、「ホームページを作成するか」という議論はナンセンスですが、同じく「APIを作るか、公開するか」という議論は終わっていると言ってもいいでしょう。

誤解を恐れずに言うと、「ホームページのない会社は存在しないのと同じ」なのと同様に、「APIがなければサービスがないのと同じ」という段階に差しかかっています。

わたしは以前、Twitter社にて「デベロッパーアドボケイト」（APIのエバンジェリストのような役割、Googleにあった同名の役職の流れを汲んでいる）と呼ばれる職務にあたっていました。

API専任の技術者を置くということは、GoogleやTwitterが、

《APIを成長の柱として、戦略的に人材を投入している》

ことにほかなりません。

どんな見た目、クオリティでもいいから、とにかくホームページを作ればいいわけではないのと同じく、「何でも良いからとにかくAPIを公開すれば良い」わけではありません。

「いかなるAPIを公開するか」については、十分に議論・検討をして戦略的に進めていくべきでしょう。

では、APIの戦略として、どのようなものが考えられるでしょうか？

考えるべきはアクセス権、マネタイズ、APIエクスペリエンスの3つ

今回は、API戦略を考える上で重要な3点、アクセス権、マネタイズ、APIエクスペリエンスを一つ一つ掘り下げていきます。

【1】アクセス権

第一に考えるべきなのは、APIが読み取り専用なのか、それともサービスのデータに変更を与えるような書き込みも可能なのかという点です。

もちろん、読み取り専用のAPIの方が手軽・気軽に公開することができます。現在政府が進めている「オープンデータ」は必ずしもREST APIの体を保っているわけではありませんが、情報の活用・応用を広めるための一種のAPIと言えます。

「秘密にしておく必要がない情報」は、まずAPI化を検討すべきでしょう。

しかし、読み取り専用のAPIでは、できることが限られます。Twitter APIが流行した理由は、APIがシンプルで使いやすいだけでなく、Twitterというサービスの本質そのものをほとんど「読み書き可能な」APIとして公開したことにあります。

ただし、書き込み可能なAPIを公開するには多大な注意が必要です。

書き込み可能なAPIが原因となるアカウントの乗っ取り、なりすまし、スパムや改ざんなどは、現在日常的に起きています。

また、読み取り専用のAPIは、（保護された情報を読み取る場合を除き）誰が呼び出しても同じ結果となりますので、匿名呼び出しを許可することができる反面、書き込み可能なAPIはそうはいきません。

・誰がAPIを呼び出すのか（認証）
・またはどういう操作が許可されているのか（認可）

を管理する仕組みが必要です。

認証・認可の仕組みはさまざまな試行錯誤が行われてきましたが、ほぼデファクトスタンダードとなったOAuthを使うのが良いでしょう。

また、APIとはちょっと話題がずれますが、認証の仕組みとして、OAuth2.0をベースとしたOpenID Connectという仕様がつい先日正式に策定されました。

旧来のOpenIDは、ユーザーの識別情報しか取得できませんでした。例えば、「Yahoo IDでログイン」といった仕組みを実装できても、名前やメールアドレスといった情報は初回ログイン後にサービスで個別にユーザーに入力してもらう必要があり、やや使いづらい面がありました。

OpenID Connectでは、対応するサービスプロバイダーからユーザー情報も取得できますので、今後はシングルサインオンのデファクトスタンダードになっていく可能性があります。

サービスのAPI公開と併せて、サービスのログイン手段としてOpenID Connectに対応することも検討しましょう。

【2】マネタイズ

自由に使えて、認証・認可・アクセス権を慎重に設計したAPIを公開すれば、サービスがうまくいくわけではありません。APIを公開するからには、APIを提供するサービス側、そしてAPIを利用するデベロッパー側双方にメリットがある必要があります。

どちらか一方にしかメリットがないAPIでは、いずれ破綻するのは明らかです。当初は自由にAPIを使ってサービスそのものをアプリケーションとして実装できてしまうことで人気を博したTwitter APIは、途中で方向転換を行い、いわゆる「クライアントアプリケーション」の開発に制限をかけたことで話題になりました。

TwitterというサービスそのものはTwitter側で画一的なヒューマンインターフェースを提供し、APIを利用するデベロッパーは周辺サービスの開発に専念してもらいたいという意向です。クライアントアプリケーションの乱立、そしてサービスの表玄関をサードパーティに奪われてしまうことによるマネタイズ機会の損失を懸念したと見る向きもあります。

ですので、APIを公開することによるサービス側の利益は何なのか、利用するデベロッパー側の利益は何なのかということを十分に設計しておくこと、また適切なタイミングで転換することが重要です。

API一般について書く本稿では、具体的な利益・マネタイズ方法の設計については述べませんが、わたしが昨年視察に行ってきた『I love APIs Conferene 2013（※米サンフランシスコで行われた、APIに焦点を当てたカンファレンス）』で聞いた興味深い事例、北米の大手ドラッグストアチェーンWalgreensが展開する写真プリントのAPIを紹介しましょう。

Walgreensには、日本のコンビニエンスストアにあるような「店頭の写真プリントサービス」があります。それを、デベロッパーが自分のサービスやアプリに「Walgreensの店頭でプリントする」機能として、APIを使って組み込むことができるのです。

デベロッパーがAPIを利用する動機付けとして面白いのは、このAPIがレベニューシェアによるビジネスモデルになっていることです（※説明用動画は以下）。

※閲覧できない場合はコチラをクリック: Walgreens QuickPrints API Overview

つまり、サービス・アプリ内からユーザーがAPIを使って写真プリントを行うと、Walgreensの収益の一部がデベロッパーに還元されるのです。

サービス・アプリの機能がリッチになるだけでなく、直接的な収益にもつながるわけですから、デベロッパーにとってAPIを利用する大きな動機付けになりますね。レベニューシェアモデルのAPIは、ほかにあまり例を聞きませんが、今後増えていくのではないでしょうか。

【3】APIエクスペリエンス

今、あらゆるサービスの開発・運営でUX（ユーザーエクスペリエンス）が重要視されています。同じ機能のサービスやアプリが複数あれば、使って楽しい、見た目が綺麗な方をユーザーは選ぶからです。

これと同じく、APIの使い心地、APIエクスペリエンスまたはデベロッパーエクスペリエンスも重要です。APIも使って楽しくなければなりません。

「楽しさ」の尺度はいろいろありますが、まずは「最低限苦痛を感じない」よう準備をする必要があります。APIを使って何ができるかというのは、まず試してみないと分からない、想像できないことが往々にしてあります。手軽に試してもらうためには、整備されたドキュメント、コードサンプルが最低限必要です。

また、実際にプログラムを書かなくても、ブラウザからAPIのパラメータをいろいろと設定して手軽に試せるコンソールがあると良いでしょう。例えばTwitter APIではブラウザからAPIコンソールを使ってさまざまなエンドポイントに対して任意のパラメータで呼び出しを行い、生のリクエストとレスポンスを確認することができるようになっています。

これは、Apigee社のApigee API Consoleという技術が使われています。

Apigee API Consoleは、WADLというAPIの定義さえ用意すれば、簡単に、そして無料でサービス内にAPIコンソールを埋め込むことができるのでお勧めです。

そして、最後になりますが、APIエクスペリエンスを高める上で、APIのバインディングライブラリ/SDKも重要です。

特にC#やJavaなど型安全なプログラミング言語から、厳密な型付けがされていないREST APIを呼び出すのは、時に苦痛を伴います。バインディングライブラリ/SDKが用意されていれば、ドキュメントをつぶさに確認することなく、IDEやコンパイラの助けを借りて楽しくAPIを扱うことができるようになります。

サービスのAPI利用をうながしたい場合は、公式SDKの準備も視野に入れましょう。

最後に

Twitter APIをひたすら7年も触り続けているわたしは、やや特殊かもしれません。が、それだけAPIによって広がるエコシステムは無限大で、非常にエキサイティングなものです。

グローバルでAPIの提供が当たり前となりつつある今、日本発のサービスも、「戦略的なAPI」を持って生き抜いていってほしいと切に願っています。