APIは“Web API”と呼ばれることが多いので、Webアプリケーションと関係が強いと感じられるでしょう。しかしAPIの活用される場所はWebだけに留まらなくなっています。その一つがスマートフォンアプリです。 iOS/Androidを中心としたアプリストアでは300万を超えるアプリが登録されています。この殆どがネットワーク機能を使っており、それらのネットワーク機能はAPIを利用しています。今回はそんなスマートフォンアプリとAPIの関係について紹介します。 多くがプラットフォームまたはプライベートAPI アプリで使われるプラットフォームのAPIとしてはFacebookやTwitter、GitHub、GoogleなどのOAuth認証であったり、DropboxやiCloudなどのストレージAPIがあります。通常、こうしたAPIだけで構成されるものは多くなく、独自のAPIを組み合わせてアプリとしているものが多いです。 そして独自のAPIはオープンになっておらず、プライベートなAPIとして提供されています。アプリはWebアプリケーションと異なりCORS（Cross-Origin Resource Sharing）を気にせずデータの取得、更新ができるのがメリットと言えます。 ビジネスロジックを隠蔽 APIを開発する場合、その多くは細かいビジネスロジックまでサーバサイドで処理を行います。アプリはビューであったり、ユーザの入力データを受け付ける目的で利用します。なるべくビジネスロジックは持たせないのが一般的です。 理由としてはiOS/Androidへの素早い対応が期待されるからでしょう。両プラットフォームで同じロジックを実装するのであればAPIとしてサーバサイドで実装し、アプリはそれを呼び出すだけにした方が工数が減ります。そのため、プライベートAPIはそのアプリならではのニーズに合わせて設計、開発されます。 SDKを利用 プラットフォームのAPIを使う場合、その多くはプラットフォームが提供しているSDKを使います。それによってAPIを実際にコールする部分は隠蔽され、より使いやすい形でデータを操作できます。 プライベートなAPIの場合、利用するアプリが限定されるのでライブラリとして再利用性を高める程度に留まっていることが多いようです。逆にAPIを他のアプリでも使ってもらおうと思うならばSDKの開発は必須と言えるでしょう。 多くがRESTfulまたはバッチ APIの呼び出しは多くがRESTful、JSONで返却されるようになっています。RESTfulで問題になることが多い、トランザクションが使えないと言った問題は、サーバサイドのロジックで処理するプライベートAPIで解決することが多いです。 一般的にRESTfulでは一つのリソースに対する一つの操作を1リクエストとしています。しかしこれはネットワーク通信回数を増やす傾向にあるため、アプリの動作が重たく感じられてしまいます。 そこでバッチ処理として複数のAPI操作を一回のリクエストにまとめる方法があります。この方法はAPIサーバの前にプロキシサーバが立ち、それがバッチ処理を順番にリクエストし、結果を結合して返すといった処理を行います。 セキュリティに注意 アプリとAPIサーバ間の通信はほぼ筒抜けです。もしSSL/TLSを使っていたとしてもアプリ側に設定を行うことで盗み見ることはできます。その結果として、ゲームアプリで言うところのチートなどが行われます。 そのため、通信内容は見られることを前提として誤ったデータが混入されるのを防ぐ仕組みを整えておきましょう。SSL/TLSは基本としつつ、サーバ側のロジックでチート処理に対して対策をするのは必須です。 Webブラウザは利用者保護の仕組みが整っています。外部ドメインに対してできる処理が限られていたり、サーバ側が許可しなかったらiframeやAjax処理もできないようになっています。 対してスマートフォンアプリは自由度が高くなっています。APIを提供する側としても、アプリをターゲットとするならば今回あげた要件は必須になってくるでしょう。

Mashup Awardから見るよく使われるAPIの条件とは？ Mashup Awardは毎年行われているAPI活用コンテストです。すでに11回も行われており、毎年多くの作品が生み出されています。 今回は 2015年のMashup Awardにて最も使われたAPIベスト5 を見つつ、APIが使われるために必要な条件を紹介したいと思います。 Microsoft Azure Microsoft社では数多くのAPIを提供しています。特にIaaSとしてのAzureプラットフォームが人気のようです。2009年から3年連続で最も使われているAPI第一位を守り続けているとのことです。 Twilio for KDDI Web Communications 簡単にネットと電話をつなげられるAPIとして有名です。海外のハッカソンでも人気のAPIとして知られています。 ニフティクラウドmobile backend スマートフォンアプリを作る際に必要なサーバサイドの機能を提供するサービスです。ユーザ管理やプッシュ通知、位置情報検索が利用できます。 SendGrid メール送信サービスです。開封率やリンクのクリックトラッキング、テンプレートといったメール送信で必要になりそうな機能が提供されます。 Monaca HTML5を使ってiOS/Androidアプリが開発できるプラットフォームです。Web開発で培った技術を使ってiOS/Androidの両プラットフォームに対応したアプリが開発できます。 pepper ソフトバンク社の販売するロボットです。タブレットを使ってアプリを開発できます。会話をしたり、身振りを使ったりと多彩な動作が可能です。 これらのAPIを見る限り、大枠で2つに分類ができます。 プラットフォーム 開発補助&単機能 プラットフォームとしてはMicrosoft Azure、ニフティクラウド mobile backend、Monaca、pepperがあります。開発補助で使えるのはTwilioやSendGrindになるでしょう。プラットフォームとしては使いやすさやドキュメント、ハンズオンの回数、サポートなど導入までの敷居とその後のサポートが差別化につながっているようです。 開発補助系ではAPI自体が他と違う珍しいものであったり、それを使うことでマッシュアップが魅力的なものになるかが大きな鍵になるかと思います。もちろん、導入の敷居が低かったり、ドキュメントが充実しているのは言うまでもありません。 【発表】最も使われたAPI &（勝手に）DeveloperSupport大賞発表 2015年版 | Mashup Awards によると、サポートやハンズオンの取り組みが手厚いかどうかが結果に表れているようです。つまりAPIは単に作って公開するだけではだめで、積極的に開発者へコミットすることではじめて使ってもらえるようになるのだと考えられます。 APIを公開する企業としては、公開後の動きこそ大事というのが分かるのではないでしょうか。

Parse.comというスマートフォンアプリのサーバサイドを提供するサービスが突如として サービス終了のアナウンス をしました。1年間の猶予があるとは言え、信頼して使ってきた開発者にとっては寝耳に水の出来事となっています。 Parse.comはFacebookに買収されたサービスであり、買収後も継続してサービスを運営してきました。それだけに突然の終了アナウンスはParse.comはもちろん、Facebookへの信頼についても揺らぎかねないものでした。 今回はそんなAPIを使う上での最大のリスクとも言える、提供企業側のサービス運営方針変更に伴うリスクについて紹介します。 サービス終了がありえる 当たり前ではあるのですが、永続的に存在しうるサービスはありません。お気に入りだったWebメディアであったり、ECサイトが閉鎖された経験は誰もがあるでしょう。これらは多くの場合、代替サービスが存在します。 APIの場合、サービス提供側がベンダーロックしているケースが多くあります。その結果としてサービス方針の変更が大きな影響を及ぼすことになります。 サービス終了に限らないリスク サービス終了は最も大きなインパクトがあるかも知れません。しかしそれ以外にもリスクはあります。価格変更（無料で使えていたサービスが有料化したり、価格があがるなど）、サービスメンテナンスや緊急停止などもあります。そのため、サービスを使い続けるとともに、常に代替や自分たちで同等のシステムを構築する方法について模索しておく必要があるでしょう。 信頼できるベンダーの選択 ここでいう信頼性とは、企業が巨大であれば良いわけではありません。大企業にとってはAPIサービスはごくごく小さな事業規模であることも多く、その結果として収益が見込めないと分かるとすぐに精算してしまう可能性があります。 また、収益化されていない、またはする気が見えないサービスも要注意です。APIのアップデート、発信力、コミュニティなどを統合的に鑑みた上で、ベンダーがAPIの提供に本気であるかどうかを判断する必要があります。 リスクヘッジの方法について APIが突然終わることのないよう、常にリスクヘッジを考える必要があります。例えば、 代替サービスの選定 自社開発への移行 契約上の縛り サービスの買収 などがあるでしょう。提供を終了しているサービスは他社への売却を検討している可能性があります。そのため、サービスを買い取ることでリスクをなくすこともできるでしょう。 APIは内部がブラックボックスになっています。それはプログラムもそうですが、運営企業についても外からでは分からないことがたくさんあります。そのため、開発者界隈で積極的に情報を交換したり、市場の推移を見てリスクヘッジを常に考えておくのが良いでしょう。

APIを複数組み合わせて新しい価値を作り上げるのがマッシュアップです。日本では Mashup Awardが毎年開催 されており、数多くのマッシュアップ作品が生み出されています。中にはそれをベースにビジネス化に乗り出す方々もいます。 そこで今回はマッシュアップサービスをビジネスとして考える時のメリット、デメリットについて解説します。 メリット 元になるデータが不要 APIが提供するデータを使うので、手元にデータがなかったとしてもすぐにサービス開発できるのがマッシュアップの魅力でしょう。ホテル、駅、地図、サーバなどあらゆるリソースがAPIを介して利用できます。 少ないリソースではじめられる 例えば位置情報に関連したサービスを考えた場合、ある地点を軸とした周辺情報を返すAPIを使うでしょう。本来、位置情報を使った検索処理は負荷が高かったり、複雑なシステムが必要ですが、そうした開発は一切不要で利用できます。 また、画像変換や天気情報なども複雑なロジックを気にすることなく使えるのが魅力です。自分たちでゼロから構築したら時間も工数もかかる作業ですが、APIを使うことですぐに手に入れられます。 公式では提供できないアプローチができる API提供元でもサービスを運営しているケースは多いです。そんな時にマッシュアップで似たようなサービスを作ってもなかなか流行らせるのは難しいかも知れません。しかしニッチ戦略をとることで十分にメリットあるサービスを作ることができます。 本家にはアプローチしづらい特定の市場向けに作ったり、特定用途に向いたUIを作ることもできます。そうした小さな市場向けに特化するのは公式サービスとしては難しいですが、マッシュアップであれば容易に作ることができます。 相対するサービス同士を結合することも可能 主に比較系サービスを考えた場合、複数の類似APIを組み合わせることが多いでしょう。そうしたサービスもまた、公式では提供しづらいのでマッシュアップならではのアプローチと言えます。 競合が存在するからこそ使える手法と言えるでしょう。利用者にとっては大きなメリットがあるサービスになるので、そこから収益をあげることもできるはずです。 デメリット API提供元の決断で左右される マッシュアップの最大のリスクと言えます。API提供元が突然API提供を止める（またはメンテナンスする）、利用制限をする、APIのフォーマットが変わるなど考えるべきリスクは数多くあります。 こうした潜在的リスクを回避するためにはあらかじめ法人契約したり、SLAが保証されたAPIを選定すると言った工夫が必要でしょう。 権利問題 APIが提供するデータ、画像などは基本的に権利はAPI提供企業にあります。つまり自分たちのものだと言えるデータがないのがマッシュアップのリスクと言えます。例えばAPIが応答不能になった場合を考えてキャッシュしたいと思うかも知れませんが、規約によって禁じているものもありますので注意が必要です。 キャッシュに関連して、API提供元でデータを消したのにマッシュアップ側で残ってしまうケースがあります。ユーザの不満につながったり、最悪の場合刑罰につながるリスクもあります。 真似が容易 マッシュアップはロジックの差になるので、真似がしやすいのがデメリットと言えます。回避するためには自分たち独自のデータを用意するべきでしょう。もちろんマッシュアップされたコンテンツを独自データにすることもできます。 Webサービスは一般的に模倣しやすいですが、マッシュアップでは特にその傾向が高くなります。他社に真似されない、独自の技術やコンテンツを蓄積する必要があります。 マッシュアップはWebサービスを一から作るのに比べると格段にはやく、かつデータの揃った状態で開発ができます。もちろんそれは他社にとっても同様で、すぐに真似されるリスクはあります。 それらのリスクを回避する手段はありますので、リスクを理解した上で進めれば決して問題にはならないでしょう。ビジネスにつながるマッシュアップをぜひ考えてみてください。

API提供をしているのに、なかなか利用が伸びずに悩んでいるというケースを聞くことがあります。総じて提供側に問題があることが多いのですが、なかなか中の人では気付きづらいようです。 そこで今回はAPI提供におけるよくある問題点を挙げてみたいと思います。 APIだけ提供する これはよくあるケースですが、APIを提供すれば勝手に利用が伸びていくと思っているケースです。実際にはそんなことはありません。例えば各言語向けのライブラリであったり、サンプルコードがないと、使ってみたいと思えないはずです。 ライブラリやSDK、Developer Kitと呼ばれる類のソフトウェアについてはなるべくオープンソースで公開しましょう。そうすることで何か困ったことがあってもコードを見つつ、開発者が自己解決できるようになります。 ドキュメントの不整備 APIの最低限のドキュメントしか用意されていないケースも問題です。ドキュメントはどれだけあってもありすぎると言うことはありません。すべてを見る人は多くなく、実際には検索エンジンで探してきてくれることの方が多いはずです。 これはライブラリについても同じで、ライブラリのクラス/APIドキュメントも用意しましょう。これらはJavaDocやPHPDocumentorといったツールから自動生成されるものを使うと良いでしょう。 質問できない どんなによくできたAPIであっても使っていると質問が出てくるものです。そんな時に聞ける場所が用意されていないのは大きなマイナスです。なるべくオープンな場所で聞けるようにしてあげましょう。 そして質問が来たら放置せず、中の人が積極的に答えるようにしましょう。Q&A形式でのナレッジの蓄積は個々だけでなく、それを閲覧している人にとっても大きなコンテンツとなっていくはずです。 汎用性がない APIを見て、どう考えても一つしか使い方の考えられないものも数多くあります。提供側の意図はAPIを通して見えてくるもので、自社の利益ばかり考えるようなAPIは誰も使いたいと思わないでしょう。 かといって、あまり汎用性が高すぎる（何でもできる）のも問題です。中のエンジニアとしての設計技量次第かも知れません。 更新されない APIは作って終わりではなく、定期的なメンテナンスが欠かせません。それを止めてしまったAPIは開発者からもあっという間に見放されてしまうでしょう。 定期的な開発を可能にするのは、APIにビジネス的メリットが見いだせるかどうかにかかっていると言えます。自社と開発者のメリット、そのバランスがとれてこそAPIとしての成功が見えてくると言えるでしょう。 独自仕様 認証が独自仕様であったり、開発が面倒なものを誰が使いたいと思うでしょうか。世の中にはすでにデファクトになる技術がたくさんありますので、そういった流れに乗ったAPI設計を行うべきです。 独自仕様の場合は使いやすくするライブラリが必須と言えます。デファクトがなかったとしても、認証やフォーマット、セキュリティ周りなどにおいて標準仕様を取り入れることはできるはずです。 利用制限が厳しい ビジネス用途でもない限り、利用制限はなるべく撤廃しましょう。もちろん無制限に使える必要はありませんが、1日に数十人が使ったらリミットになってしまう程度では面白くも何ともないでしょう。 ビジネス用途のAPIにおいてもパートナー契約しなければ仕様すら見られないというのでは問題があります。サンドボックス環境を用意するなど、試せる環境は用意すべきです。 APIは通常のWebサービスとは異なり、広め方に苦労することがあるかも知れません。そのためにもまずアンチパターンはなくすべきです。 自社の提供するAPIがこれらに引っかかっていないか、ぜひ見直してみてください。 画像は Crossroads: Success or Failure より。

一般的なAPIはこちらからAPIをコールします。それに対してWebHooksはサーバ側からこちらの指定したURLをコールしてもらう仕組みです。 用途は絞られるかも知れませんが、使い方によってはとても有用です。今回はカテゴリごとにWebHooksを提供しているAPIをまとめてみました。 メール/マーケティング 圧倒的に多いのがこのメールやマーケティング分野です。ユーザが何かアクションしたタイミングで通知代わりに飛ばしてくれるようなイメージです。 The WebHook APIs - WuFoo Webhooks | Campaign Monitor MailChimp | API Docs Webhooks API | Mandrill Webhooks — Mailgun API documentation VerticalResponse - Webhooks API Recurly Developer Hub Webhooks API — FluidSurveys APIs Docs Webhooks - Email Marketing API コミュニケーション 有名なところではSlackがあります。チャットの他、コミュニティなどでもWebHooksが使われているようです。 Incoming Webhooks | Slack Outgoing Webhooks | Slack HipChat - API v2 - Webhooks Jive REST API v3.13 → Webhooks service Webhooks API - NationBuilder 開発 開発系ではGitHubもWebHooksを提供しています。開発スピードを速くしたり、外部サービス（CIなど）と連携する上で必須の機能と言えるでしょう。 Webhooks | GitHub Developer Guide PagerDuty Developer API Reference | Trello Developers Webhooks - Atlassian Developers Eコマース/決済 決済系ではまず対象のサービスをコールして、その後はサーバ側とデータを送受信することで決済データを授受します。WebHooksを使うことでセキュアなデータのやり取りを可能にしています。 Webhook - Shopify API - Developer Resources Webhook | WebPay: 開発者向けクレジットカード決済サービス Webhooks overview - PayPal Developer Webhooks - Stripe API: Webhooks - Chargify Documentation API documentation - Webhooks - SEOshop ストレージ DropboxやBoxなどでもWebHooksを提供しているようです。ファイルの更新時にコールするといった使い方ができそうです。 Developers - Dropbox Box Developer 変更の監視 - Evernote Developers ビジネス ビジネス系は使い方が難しいですが、通常のAPIとはまた違った利用法が生まれるかも知れません。 Person API Documentation - FullContact Vend / Webhooks - Vend Developers Webhooks - shipwire マーケティング系がとても多いのに驚かされます。アンケートの回答やメールマーケティングへの反応をリアルタイムに受け取ることで、オートマーケティングを可能にしているのかも知れません。 WebHooksを使えばこれまでとAPIと逆方向の利用が考えられます。ぜひ使いこなして業務を改善、スピードアップしてください。

APIはシステム連携に用いるもので、24時間365日使えて当たり前といった雰囲気があります。とは言え、人が作るものだけに何らかの不具合が発生する可能性もないわけではありません。 そこで必要になるのがステータスの確認ページです。最近では有名なWebサービスでは大抵APIやサービスステータスページを公開しています。今回はそうしたAPIステータスページを作るためのソフトウェアやサービスを紹介します。 owainlewis/status Scalaで作られたシステムです。登録したURLに対してレスポンスが返ってくるかチェックをします。エラーが発生した際に、その結果をSlackに対して飛ばす機能があります。 デモページ DoESLiverpool/status ちょっと変わった見え方のステータスページになります。オンライン、または稼働中というラベルが強調されていますので生死確認は分かりやすいでしょう。各ステータスをクリックすると、細かなデータが分かるようになっています。システムはNode.js製です。 デモページ Stashboard: The open source status dashboard AmazonやGoogleのステータスページをまねた作りになっています。Twilioが開発しています。システムはGoogle App Engine上に立てる仕様になっているのは、まさにGoogle App Engine向きな使い方と言えそうです。 デモページ Cachet - The Open Source Status Page System かなりリッチなUIのステータスページが作れます。公開できる情報を伴ったダッシュボード的なシステムと言えそうです。フィードも公開できますので、購読しておくことで履歴の蓄積もできます。デザインはスマートフォン対応です。 デモページ StatusPage.io - Hosted Status Pages for Your Company 多くの企業でも使われているステータスページ提供サービスです。グローバルにUS/EUなどからアクセスしてくれるので、一部地域ではうまく接続できないといった問題にも対処できます。月額29ドルからの有料サービスとなっています。 いかがでしょうか。オープンソース・ソフトウェアであれば自分たちでサーバを用意してデプロイすれば良いでしょう。ただし同じ地域に用意するのは意味がありません。EUやUSなど遠くに置く必要があります。Google App EngineであればGoogleのネットワーク化にありますので離れた存在となりそうです。 StatusPage.ioを使えばより手軽にステータスページが用意できます。APIを公開する際にはこういったページも忘れずに用意するようにしましょう。

Webシステムにおいてネットワーク速度は常に問題になります。特に最近は動画コンテンツが増えているため、ネットワークへの投資を控えるとユーザが大いにストレスを感じてしまうでしょう。 そこで今回はCDNをまとめて紹介します。特にAPIを提供しているものになるので、システムと連携してダイナミックにコンテンツを配信できるはずです。 CDN by MaxCDN | Experts in Content Delivery Network Services MaxCDNのAPIでは各種プログラミング言語向けにSDKが提供されています。Python/Ruby/PHP/Node.js/.NET/Goとなっています。これらのSDKを使って、MaxCDNがフルコントロールできるとのことです。 また、GitHubとの連携によって、コードをアップロードするとCDNのキャッシュをクリアすると言った操作もできます。 API | MaxCDN Product Features CDN powered by KeyCDN | Content Delivery Made Easy KeyCDNのAPIはRESTfulに操作が可能です。ゾーンの作成、一覧、更新、削除などがすべてAPI経由で操作できます。CDNのステータスや課金情報の取得も可能です。 KeyCDN API | CDN API Documentation Rackspace: Managed Dedicated & Cloud Computing Services クラウド管理サービスを提供するRackspaceでは独自に提供するCDNのAPIを提供しています。サーバ自体の運用はRackspaceにお任せですが、サーバのレスポンスについて高速化または調整したい時に使えるでしょう。 Rackspace CDN API 1.0 - Rackspace Developer Portal CDN by MetaCDN - Live Streaming - Content Delivery Network MetaCDNは通常のCDNの他、ライブストリーミングに特に強みを置いています。APIからでももちろんライブストリーミングに関する操作ができます。CDN配信するコンテンツの登録や削除と言った操作ができます。 MetaCDN Web Service API Content Delivery Network (CDN) | CDN77.com CDN77ではCDNの操作はもちろんのこと、課金、データセンターのロケーション、請求書、ログ、レポート、ストレージとストレージの場所に関するデータの取得、操作がAPI経由でできるようになっています。 Api | CDN77.com jsDelivr - A free super-fast CDN for developers and webmasters 誰でも使える無料のパブリックCDNであるjsDelivrのAPIです。データが自由に登録できる訳ではありませんので、登録されているライブラリの一覧やバージョンリストを取得できるAPIとなっています。 jsdelivr/api: API for public CDNs 選ばれる次世代定額CDN｜レッドボックス CDNは一般的に従量課金制ですが、レッドボックスは定額のCDNとなっています。APIではキャッシュの削除に対応しており、正規表現もサポートしています。 定額CDN「エッジキャッシュ」にAPI機能追加！正規表現も正式サポートしました。 | レッドボックス Affordable CDN by CDNsun | Content Delivery Network ライブストリーミングへの対応や1TBあたり45ドル、ソフトウェアダウンロードサポートなどの特徴があります。APIではサービス、ストレージ、ロケーションなどが操作できます。 CDN API | CDNsun Content Delivery Network (CDN) & Cloud Computing Services | Akamai CDNの最大手として知られるAkamaiもAPIを提供しています。開発途中のAPIも多く、力を入れているのが分かります。その数も多く、運用からレポーティング、決済まで幅広く対応しています。 API Catalog Amazon CloudFront CDN （コンテンツ配信とストリーミング） | AWS Amazon Web Servicesが提供するCDNです。Amazon S3と連携しており、WAFなど他のAWSと連携できるのが強みと言えます。動的なコンテンツ配信にも対応しています。 Amazon CloudFront CDN （コンテンツ配信とストリーミング） | AWS CDNについては各サービスとも大きな差異はないと思いますが、APIについては提供範囲が大きく異なるようです。何でも高速配信というのではなく、より細かく指定できたりキャッシュのクリアができるものを選ぶのが良さそうです。 CDNは一般的に従量課金なので、全コンテンツをCDN化すると料金が高くなってしまいます。その点もAPIを使って細かくマネジメントすると良いのではないでしょうか。

自社データをAPIとして公開することを考えた際にポイントとなってくるのが、そのAPIによってどんなメリットがあるのかということでしょう。企業としてAPIを公開する以上、単に公開して終わりという訳ではありません。そこには新しい収益源になる可能性があってこそだと思われます。 そこで今回はAPIを使った主な収益化の方法について紹介します。 データの販売 自社の持っているデータが貴重なもの、または特許や資格が絡むといった理由で他の企業との差別化が図れる場合は、そのデータ自体を有料で販売する方法が考えられます。 例えばIPアドレスから地域情報を返すデータベースを持っている Digital Element 、 どこどこJP であったり、天気データを販売している 天気予報API もあります。地図データをGoogleマップに提供しているゼンリン社もよく知られています。 既存サービスのアドオン すでにWebサービスを提供しており、APIは有料で利用できるようしているサービスも多数あります。一般ユーザであればWebサービスでも十分ですが、企業が大量の処理を自動化する中ではAPIを使いたいというニーズがあります。そこでAPIを有料として提供します。 自動化、スピードアップなど企業でよく発生するニーズに対応できるようになります。APIを追加機能とすることで、課金ターゲットにすることができます。 既存サービスの機能拡充 もし自社で何らかのWebサービスを提供している場合、さらに機能拡充を狙って他社のAPIを使うことが考えられます。単体機能では使いづらくとも、自社のサービスと合わせることで魅力的になるのであれば取り込む価値があるでしょう。 Yahoo空席レーダーではトレタ社のレストラン予約データを使って提供されています。Yahoo空席レーダー自体は有料ではありませんが、ユーザの囲い込みに大いに貢献しているサービスになります。 他の企業との提携 他の企業との提携を考えた場合、今はAPIを用いた自動化が当たり前になっています。むしろAPIがない場合、提携も進めづらい状態と言えます。相互にAPIがあるからこそ、自動化ができたりインタフェースのすり合わせもスムーズに行えるようになります。 APIを汎用的に設計、開発することで一社のみならず複数企業との提携も容易に行えるようになります。さらに大手との提携が進めば自分たちのAPIが業界標準となっていくことも考えられるでしょう。 機能の販売 APIで提供されるのは何も自社データに限りません。画像加工であったりグラフの出力などデータ加工を行うAPIも有料で提供されることがあります。その場合、あまり簡単なものであると他社に簡単に模倣されてしまいますので、自社独自の技術が合わさってこそ収益化も考えられるようになります。 例えばクラウド上で動画を変換するサービスであったり、3Dモデリングを行うサービスもあります。大量のリソースを使うサービスであってもクラウド上の基盤を用いることで安価、かつ高速に処理できるようになります。 APIを公開しただけではなかなか利用が伸びるものではありません。利用が伸びない中ではAPIの追加開発も困難になります。Webサービスと異なり、UIがない中でのサービス提供となると打ち出し方、ビジネスモデルも変わってくるでしょう。 B to BにおいてAPIを開発する際にはまず適切なビジネスモデルを組み上げた上で行わなければなりません。もしそれがうまくいったならば、自社の新しい収益源として大いに貢献してくれることでしょう。

ここ半年くらいで一気に注目が集まっている技術ワードがブロックチェーンです。BitCoinで使われている技術として知っている人も多いかと思いますが、ブロックチェーンを限られたネットワーク内で利用する方法が取り上げられています。 ここ最近の動きやブロックチェーン実装についてまとめてみました。 オープンソースによるブロックチェーン実装 オープンソースでブロックチェーンを体感する最も早い方法は BitCoin を使うことでしょう。現在、それ以外でも実装がはじまっています。 Linux Foundation Unites Industry Leaders to Advance Blockchain Technology としてIBM、アクセンチュア、シスコなどを集めて実装を開始しています。このプロジェクトはLinux Foundationの監督下にあります。また、 R3コンソーシアムもオープンソースのブロックチェーン実装を開発 しはじめています。 SaaSとしてのブロックチェーン実装 オープンソースの場合、自社でクラウド環境を組み上げる必要がありますが、SaaSの場合はそういった手間は不要です。 Chain | Enterprise Blockchain Platform NasdaqがChain社と提携し、未公開株式市場でブロックチェーン技術を使うと発表しています（via 金融インフラをブロックチェーンで代替してコストを10分の1に、日本から「mijin」が登場 | TechCrunch Japan ）。 mijin 国内のブロックチェーン実装で、さくらのクラウドと組んで実証実験環境を提供するとのことです。mijin自体オープンソース・ソフトウェアとなっています。 クラウドではマイクロソフトのAzureでもブロックチェーンサービスが開始しています。 Ethereum Blockchain as a Serviceというサービス になります。 イスラエルの企業、Coluもクラウドでブロックチェーンベースのサービスを提供しています。 Blockchain Technology and Colored Coins - digital assets - Colu Coluではbitcoinの情報に加えてメタデータを追加できるとのことで、通貨だけでなく鍵やチケットと言った付加情報を含めたトランザクションができるようになります（via Bitcoinのブロックチェーンに便利なメタデータ層をつけて多様なアプリケーションを可能にするColu | TechCrunch Japan ）。これによりブロックチェーンの可能性が大きく飛躍することでしょう。 企業の動き 企業としてブロックチェーンを商品化する動きもあります。前述のIBM、マイクロソフト、さくらインターネットなどに加えてサムスンも開発を開始しています（via サムスンがブロックチェイン技術を研究、5年以内に製品化目処 | BTCN｜ビットコインニュース ）。国内ではOrb社がブロックチェーン技術を研究、開発しています。すでに SmartCoinという仮想通貨発行サービスを提供 しています。 誰でも簡単に仮想通貨がつくれる、OrbのSmartCoin ブロックチェーン技術はFinTechと絡みつつも、Coluでのメタ情報付与など多くの可能性を持った技術となっています。クラウドとの親和性も高く、APIを通じて自動的にスケールしたり、データのトランザクションを管理するのに使える可能性があるでしょう。 オープンソースによる実装はまだしばらくかかるかも知れませんので、クラウドベースでいち早く体験してみてはいかがでしょうか。

メリークリスマス！ Enterprise APIs Advent Calendar 2015 のラストをかざるのは、Enterprise APIs Hack-Night #3開催概要のご案内です！ 2015/2/10(水) 19:00より、Enterprise APIs Hack-Night #3を開催します。 場所は dots. さんのイベントスペースです。 今回も特にテーマは絞らず幅広くやります。 様々な分野、立場からEnterpriseなAPIについて語っていただきます。 セッション（予定）は以下の通りです。 FintechにおけるAPIとマネーフォワードの取組み（仮） by 株式会社マネーフォワード　泉谷さん APIで作る教育プラットフォーム（仮） by 株式会社リアルグローブ　大畑さん APIだけでフロントエンド開発を可能にした話（仮） by 有限会社バーチャルテクノロジー　竹嵜さん 5分間のLT × 5 by 有志一同（登壇者募集！） 当日は懇親会も予定していますので、ご気軽にご参加ください。 勉強会詳細とお申込みは こちら から。

以前、 IAM API の活用方法についてご紹介しましたが、今回はNTT Comサービスのビジネスプロセスを制御する「Business Process API」の利用シーンについてご紹介したいと思います。 本記事は、 Enterprise APIs Advent Calendar 2015 への投稿です。 Business Process APIとは？ NTT Com各種サービスのビジネスプロセスに関する情報提供、操作を可能とするAPIです。 具体的には以下４つの情報操作を可能とします。 契約情報 サービスオーダ チケット情報 メンテナンス情報 各APIの詳細は Business Process API Docs をご覧ください。 人が介在しない正確なオーダ管理 主にNTT Comのパートナー企業さまでご活用いただきたいBusiness Process APIのユースケースです。 従来、NTT Comのサービスを契約する場合は、営業やコールセンタ等を通じてお申込みしていただく必要があり、専任のオペレータを用意するなどパートナー企業さまにとって大きな負担となっていました。 サービスの申込、変更、解約に関するAPIを開放することで、パートナー企業さまのシステムから直接オーダ処理を実現することが可能になりました。 これにより、パートナー企業さまで専任オペレータを用意する必要がなくなるため、人的コストを削減できたり、手作業によって発生するオペレーションミスをなくすことなどが期待できます。 運用保守の見える化と一元化 NTT Comサービスの工事情報や障害情報、復旧情報を確認するには、専用のポータルサイトへアクセスする必要がありました。 メールやRSSでも情報を受け取ることは可能ですが、お客さまの運用保守システムなどで情報を一元的に管理することが困難でした。 このような状況を改善する目的で開放されたのがチケットAPIやメンテナンスAPIです。これらのAPIを活用することで、お客さまの運用保守システムと連携することが可能となり、NTT Comサービスの運用状況を可視化して利用することが可能となりました。 ホワイトレーベル（ホワイトラベル）提供 Business Process APIを活用すれば、契約情報の管理や運用状況をAPIを介して情報取得することができるため、NTT Comサービスをお客さまブランドでエンドユーザに提供することもできます。 以上のように、Business Process APIを活用することで、NTT Comサービスをより扱いやすくご利用いただくことが可能となります。 また、国内主要通信キャリアにおいて、サービスのビジネスプロセスに関するAPIを公開したのはNTT Comが初です。 Business Process APIは無料でご利用いただけますので、是非みなさまのビジネスにご活用いただければと思います。

見積書、請求書そして納品書などビジネスの場では様々な帳票が利用されています。かつては自社内にサーバがあり、そこから帳票を出力していました。しかし最近ではクラウド型の帳票出力サービスが増えています。 今回はそんな帳票サービスの中でもAPIを用意しているものを紹介します。APIを使うことで基幹システムとの連携や自動化がスムーズになることでしょう。 MakeLeaps API 帳票の作成と郵送まで行ってくれるクラウド請求サービスです。オンライン決済システムも備わっています。 認証APIだけが公開されており、他のAPIについては問い合わせが必要となっています。現在オープンβとなっています。 クラウドで見積・納品・請求書を簡単作成、管理、郵送 Misoca API について · Misoca(みそか) API Webブラウザはもちろんアプリもリリースされている請求書作成サービスです。メール配信、PDF保存、郵送ができます。 OAuth2に対応したアプリケーションが作成できるようになっています。郵送指示や入金ステータスの変更などがAPI経由でできます。 請求書作成サービス「Misoca(ミソカ)」 開発者の方へ｜請求書作成ソフト「MFクラウド請求書」 マネーフォワード社によるサービスで、OAuth2認証に対応しています。取引先の作成や帳票の作成なども含めてほぼ全ての操作がAPI経由で可能なようです。 請求書作成ソフト「MFクラウド請求書」 Zoho Invoice API Zoho社によるサービスですが、今のところ日本語化はされていないようです。請求書、納品書の作成、取引先の管理などがAPIを経由して可能です。 Invoice Software | Online Invoicing Solution From Zoho 2つの連携インターフェース API｜大規模帳票管理｜クラウドシェアードオフィス 帳票がExcel上で設計できるのでプログラマでなくとも手軽に扱えるのが利点です。帳票の郵送も可能です。 既存のWebサービスに電子帳票を作成する機能を追加すると言った使い方もできるとのことです。 クラウド帳票｜大規模帳票管理｜クラウドソリューション｜クラウドシェアードオフィス 帳票の出力枚数が増えると自動化を考えるようになります。クラウドでもそれは同じで何百枚もの帳票をミスなく出力するのは大変なことです。また、売り上げ管理などは自社の既存システムを使っているケースも少なくありません。 帳票サービスを使う際にはAPIが提供されているかどうかを重視した方が良さそうです。

Enterprise APIs Advent Calendar 2015 への記事です。 大学や専門学校ではもちろん、最近では小中学校においてもICTの活用が進んでいます。 ICT活用事例として代表的なものにeラーニングがありますが、eラーニングの仕様については国際的な標準規格が存在し、今日はその一つであるExperience APIについてご紹介したいと思います。 Experience API(旧称：Tin Can API) eラーニングの仕様についてはSCROMという国際的な標準規格が、米国のADLという機関によって策定されましたが、このSCORMに継ぐ世界標準規格として定めらたのがExperience APIです。 Experience APIは、あらゆるタイプの教育経験（学習活動履歴など）を記録するために、教育コンテンツと教育システム間を相互にやりとりするためのAPIです。 略してxAPIと呼ばれることもあるそうです。 Experience APIはRESTベースのインタフェースを備え、データフォーマットはJSONで規定されています。 詳細は APIリファレンス をご確認ください。 （日本語版もあります） Experience APIが策定された経緯 SCORMはLMSにおいて学習履歴を管理しますが、SCORMの規格は色々問題があったようです。 そこで、Experience APIでは、SCORMでは実現できない以下の操作が実現可能になるよう規定されています。 例えば以下のようなことが実現できるようです。（以下、Wikipediaより抜粋） ウェブブラウザ外でのeラーニングの実施 モバイルアプリケーションにおけるeラーニング 教材に対しての、より広い制御 OAuthを利用した高セキュリティ プラットフォームを跨いだ学習：例として、モバイルで学習開始しＰＣで終了 ゲームやシミュレーターにおけるユーザー動作のトラッキング 実世界でのパフォーマンスのトレース チームでの成績管理 教育プランとゴールの追跡管理 その他のシステムのデータとLMSのデータをマージして比較 動画教材等において、どの部分が視聴されているか等の詳細の学習履歴把握 Experience APIに対応したサービス edo-xrs 個人から発生する様々なデータを記録するリアルグローブ社のプラットフォームです。学習記録や医療記録等をはじめとする、あらゆるパーソナルレコードをスケーラブルかつ高速に蓄積することができます。『edo-xrs』は、LRS(Learning Record Store)として、総務省「先導的教育システム実証事業」の学習記録データ蓄積機能に採用されています。 （2015/8/12プレスリリースより抜粋） edo-xrsプロジェクトサイト LRS ( Tin Can ) ジンジャーアップ社の統合ソリューションで、日本でいち早くExperience APIに対応したLRSを開発し、様々なサービスに適用されています。 Experience APIの仕様により、e-ラーニング系でよくある動画視聴コンテンツなどで、各教材内の動画コンテンツのどの部分が視聴学習されているか、など細かな視聴実績を把握することが可能になるようです。つまり、動画を開いてもすぐに終了させてしまうとバレてしまう。 また、APIで情報の入出力ができるようになるので、業務系システムなど外部システム間の連携が容易にできるというメリットもあります。 その他教育系API　 Google Classroom API Experience APIに準拠しているのか不明ですが、GoogleもClassroomという教育系プラットフォームを提供しています。 まだ評価フェーズですが、APIもデベロッパに公開されています。 教育分野においては、コンテンツの互換性が特に重要であることから、インタフェースの仕様については早くから業界標準が存在していました。 そしてExperience APIが定義され、各個人の学習活動履歴がビックデータとして様々な用途に活用されはじめています。 教育分野は新規参入が難しいイメージがありますが、標準化されたAPIを上手く活用することで新たなビジネスチャンスが期待できる分野なのかもしれません。

APIは作って終わりではなく、徐々に機能追加したり問題があればフィックスをします。それを繰り返す内に起きるのがバージョンアップ問題です。今回はAPIのバージョンアップに絡んだ問題と、その解決策を紹介します。 URL設計 将来のバージョンアップを予期したURL設計にしておくのは大事です。よくあるのは /v1/からURLをはじめるパターンです。これを忘れていると、URLの中に無理矢理入れることになります（/users/ と /users_2/ といった具合に）。 いつをもってバージョンを変えるか悩む これが最も良くある問題ではないかと思います。ちょっとした機能追加でバージョンを上げてしまうと、今後繰り返されるちょっとした修正のたびにバージョンが上がってしまって管理しきれなくなります。かといっていつまでもバージョンアップしないといつまで経ってもv1のままで、何のためにバージョン番号をつけたのか分からなくなってしまうでしょう。 結局のところポリシー次第なのですが、注意点としてはバージョンが変わるとこれまでの既存のAPI全体を作り変える必要があるということです。少なくともコピーすることはできますが、インタフェース設計が変わっていたりすると全体のバランスが崩れてしまいます。 コストがかかる ということはAPIのバージョンが変わると、全面的に作り変える必要が出てくるのです。そのためバージョン1はSOAP、バージョン2はRESTfulなど技術的なパラダイムシフトが起こった、またはアーキテクチャが変わったタイミングでバージョンアップするのが良いかも知れません。 後方互換性を維持するべきか 利用者のことを考えると後方互換性は維持されているのが良いでしょう。サポートとしても、ある機能が使えないときに、それがバージョン1に起因するものなのか、違うのかに判断が困るかも知れません。 ただし後方互換性の維持はモダンな実装の足かせになったり、開発やテストコストの増加につながります。さらに利用しているライブラリをバージョンアップしたタイミングで古いバージョンの動作が変わったりする可能性があります。そのため、できればサーバ自体を分け、過去のAPIについてはノータッチにするというのが安心かも知れません。 古いAPIをいつまでサポートすべきか API連携のシステムは一旦開発するとそのまま放置されるのが一般的です。そのため古いAPIが使えなくなるといったアナウンスをすると、補修が発生します。しかし数年前のシステムを完全に把握しているというのは稀でしょう。 そのため新しいAPIリリース後、1年くらいの猶予は必要だと思われます。しかし多くのケースではうまく乗り換えできず、そのままずるずると古いAPIのまま続いてしまっています。特にB to Bで提供されているAPIではその傾向が強くあります。あらかじめ契約時にその旨（APIのバージョンアップがあること。古いAPIについては段階的に廃止されていくなど）を追加しておくのが良いでしょう。 あらかじめAPIを利用するライブラリを提供しておき、直接APIを触らないようにしておきましょう。そうすることでライブラリのバージョンを変えれば既存のシステムには手を加えずに新バージョンに対応できるようになります。 オープンソースではメジャーバージョンアップしたタイミングで過去の資産をすべて切り捨てることもありますが、多くの場合は継続して利用されます。それを参考にして考えると、バージョン2にアクセスしても既存の機能はそのまま使える方が安全かも知れません。その中で技術的負債になってしまっている機能については推奨せずであったり、期日をもって閉鎖とするのが良いのではないでしょうか。

認証を行うAPIとしてはOpenIDが有名なのですが、認証だけであるためにメールアドレスの取得であったり、その後のシステム連携に繋げられないといった不満があります。そこで認証と委譲を行うOAuth（特に1.0の問題点を解決したOAuth2）を使うのが一般的になっています。 そこで今回は既存のシステムはもちろん、今後作られるシステムでも手軽にOAuth2の機能が追加できるライブラリを紹介します。 PHP bshaffer/oauth2-server-php : 特に依存のないOAuth2サーバです。既存システムと並列して疎結合で立てるのが良さそうです。 thephpleague/oauth2-server : こちらも独立型ですが、CakePHP3やLaravelとの連携も想定されています。 lucadegasperi/oauth2-server-laravel : Laravelフレームワーク用のOAuth2サーバライブラリです。 zfcampus/zf-oauth2 : 名前の通り、Zend Framework用のOAuth2サーバライブラリです。 bshaffer/oauth2-server-bundle : SymfonyアプリケーションにOAuth2サーバ機能を追加します。 Filsh/yii2-oauth2-server : Yii2アプリケーションにOAtuh2サーバ機能を追加します。 sumeko/phalcon-oauth2-server : こちらはPhalcon向けのOAuth2サーバです。 justingreerbbi/wordpress-oauth-server : WordPressプラグインとして動作するOAuth2サーバです。 Ruby assaf/rack-oauth2-server : Rackアプリケーションなので独立して利用できます。 doorkeeper-gem/doorkeeper : RailsアプリケーションにOAuth2サーバ機能を組み込めます。 songkick/oauth2-provider : ごくシンプルなOAuth2サーバで、Sinatraなどで使うこともできます。 Python joestump/python-oauth2 : Python 2.6/2.7/3.3/3.4に対応しています。多くのフレームワークと組み合わせて利用できます。 hiidef/oauth2app : Djangoアプリケーションの中で使えるOAuth2サーバです。 Node.js thomseddon/node-oauth2-server : Expressと組み合わせて使えるNode.js用のOAuth2サーバです。 ammmir/node-oauth2-provider : こちらもExpressと組み合わせて使うOAuth2サーバです。 .NET IdentityServer/IdentityServer3 : OAuth2だけでなく、OpenIDにも対応したサーバです。 Go RichardKnop/go-oauth2-server : GoとPostgreSQLによるOAuth2サーバです。 Java tuxdna/play-oauth2-server : Play! 2.0 framework用のOAuth2サーバです。 OAuth2サーバを立てることで、APIとしてぐっと使いやすくなります。企業向けとなるとユーザ管理の構造化なども求められるかも知れませんが、基本的にはこれらを拡張していく形で実装できるでしょう。 API構築の際にお試しください。

APIを作る際にはシステムを構築する必要があります。実際、使えるシステムになるか未検証であったり、機能面の過不足が不明確な段階においてあまり作り込むのは避けたいところです。 そこで手元にある既存のリソースを手軽にAPI化してくれるソフトウェアを使ってみましょう。そうすることでモックアップの作成を高速化し、早期に検証が可能になります。 davbre/mira MiraはRuby on Railsを使ったシステムであり、CSVファイルをWeb API化します。元データが静的ファイルなので、GETのみのインタフェースで提供されます。 外部システムとの連携において、CSVファイルをダウンロードした後に他のシステムにはAPI経由でデータを渡すと言ったような使い方もできそうです。 thestorefront/FastAPI FastAPIもRuby製のライブラリで、PostgreSQLをAPI化するのに必要な機能を提供しています。公開するカラムなどを定義しておくだけで、JSON化できます。 jonahoffline/csv2api CSV2APIはRuby製ライブラリで、CSVファイルをJSONまたはXML API化します。CSVファイルごとにパスが切られるので複数ファイルを扱うことができます。一覧表示のWeb表示もサポートしています。 julzhk/simple_api Python製のライブラリでCSVファイルをAPIにします。Google App Engine上で動かす前提となっています。データを検索したり、返却するカラムを指定することが可能です。 acarl/pg-restify PostgreSQLをAPI化します。多少の設定は必要ですが、HTTP経由でデータの取得はもちろん、追加や更新、削除にも対応します。 waldoj/instant-api JSONファイルを読み込んでRESTfulなインタフェースを提供します。実データのJSONファイルでは検索したり、1件だけのデータを取得するような細かな操作はできませんので、よりプログラマブルな使い方が可能になるでしょう。 先日、 Data簡単API化サービス というサービスがリリースされるなど、既存のレガシーな資産をAPIとして活かしたいというニーズは一定数ありそうです。自社データを振り返っても多くの資産が眠っているのではないでしょうか。 そうしたデータはファイルのままではシステム連携しづらいですが、API化することで新しい可能性が見えてくることでしょう。ぜひ活用してください！

去る12月3日、渋谷の21cafeにて Enterprise APIs Hack-Night #2 が開催されました 。今回はそのレポート記事になります。 Enterprise APIs Hack-Night #2 - connpass Office 365 を中核としたこれからの API 戦略 登壇者：日本マイクロソフト株式会社 テクニカル エバンジェリスト 松崎 剛さん Microsoftでは多くのWebサービスを提供していますが、今回はその中でもOffice 365に関する話になります。Office 365ではExtensibility、Remote API Accessがありますが、今回はRemote API Accessについてしょうかいします。技術的にはOAuth2とRESTfulを使っている。 大事なキーワードはOpenness。JavaScriptがあればVisual Studioを使わなくても開発できます。言語にも依存しないので、.NET以外の言語でも開発できます。 もう一つの戦略はクロスデバイス。最近はApple、Androidを優先して開発しているくらいです。昔はWindowsを優先していましたが、iOSやAndroidの上でも自分たちの製品を使ってほしいと考えています。 今後のOffice 365 APIがどうなっていくかについて、まず現状から説明します。 OneDrive SharePoint Exchange Active Directory これらはすべてRESTfulなAPIが用意されています。Azure ActiveDirectoryがすべての認証を司っています。ここだけ取り出して使うことも可能です。ビジネス向けとして、管理者がOKを出したら従業員の方は、わざわざ一つ一つの機能に許可を出さなくてもOAuth認証だけで機能を使えるようにしています。 そして今後についてですが、1週間前に発表したのがUnified - Microsoft Graphです。これまで各APIはエンドポイントがばらばらで、権限も個別に分かれていました。ファイルを上長にメールするなどといったら、各APIにアクセスしないといけない状態で、そのファイルのある場所によって各APIの許可をもらう必要があります。 ユーザが選択したファイルのプレビューを出といった操作をしようとした場合、Exchange、SharePoint、OneDriveの各パーミションを取っておかないといけませんでした。Graphはエンドポイントを一つにし、横の製品間の横断をできるようにします。 Unifiedにはもう一つの側面があります。ビジネスとコンシューマ用APIの統合です。例えばMSにはOneDriveが2つあります。一つは単なるOneDriveで、もう一つはOneDrive for Businessです。同様にSkypeもあります。 今後、すべてAPIのエンドポイントを統一（graph.microsoft.com）していきます。ただし、これはコンシューマとビジネスが一緒になるという意味ではありません。for Businessは今後も残っていきます。APIのエンドポイントを一つにしていくだけです。アプリを一つを作っておくと、もう一つ（ビジネス）にも対応できるようになります。 さらにソケット型のサードパーティ統合が行われます。例えばOffice 365のアプリランチャーの画面に認証したアプリが出るようになります。そしてアプリから簡単に機械学習などのAzureの機能が使えるようになります。その結果、あなたの組織はどれだけ会議をしたかなどをビジュアル化することができたり、セールスフォースなどからデータを出せるようになるのです。 最後にSkype Developer Platform。今はSkypeのオンプレ版しかありません。今後REST APIを出します。音声通話、ビデオ通話に関するAPIを含まれます。JavaScript SDKを出すので簡単に使えるようになるでしょう。 トレタ × Yahoo! JapanのAPIによる提携の話 登壇者：増井 雄一郎 さん Yahooが先日リリースした空席レーダーはトレタのデータを使っています。今から歩いて5分のところにある30人入れる店を探せるようなアプリです。 トレタCEOの中村は元々レストランを経営しており、実際に予約台帳を手書きでやっていました。この予約台帳はレストランの生命線であり、これをデジタル化しようとしているのがトレタになります。 提携の話が出たきっかけは、CEOがたまたまYahooの人と話をしたところからです。Yahooも元々Yahoo予約をやっていたのだけれど視点が違うという認識でした。これまでの問題は、予約サイトから予約があると、紙の台帳に反映して、各予約サイトにも反映するという大きな作業があった。そのため、飲食店側が面倒で使うのを嫌がりました。トレタは予約台帳システムなので、受け口は電話でもAPI経由でもOKというのが大きなポイントです。 そしてYahooとトレタで予約を軸に毎週ペースで会議を重ねて、APIのフォーマットを議論していきました。お互いサービスの初期設計の段階から提携できる形に設計を行っていたので話はスムーズでした。例えばトレタは予約は埋まる視点、Yahooは予約が空いているところという視点で、側面がまったく異なるのです。 今の時代、すべて自分たちでやるというのは無理があります。トレタではレジの会社のAPIとつなごうと考えています。そのためには外部連携することを前提とする必要があります。また、先にAPIの実装が終わっているというのがポイントです。大手と同時にやると力関係が働くので注意が必要です。 さらに本体のコアバリュー以外はAPIとしておく必要があります。また、オープンスタンダードを採用するのもポイントです。他社では独自の仕組みを無理押ししてくると聞きますが、トレタではOAuth2を使っている。標準技術を使っているので繋ぎこみの話がとても早く済みます。 最後に、大手との提携になるとPマークの取得、セキュリティ監査が必須になります。このコストは意外と大きいので、セキュリティチェックすることを前提に、チェック表などを作っておけば良かったと今ではかんじています。 提携先の対応速度は優先度次第です。トレタも今は4000店舗を越えて話がしやすくなっています。リリースしたばかりだと優先度が上がらないので、実績をあげるのが大事です。また、トレタは飲食店の代弁ができるといった立ち位置だったので相手も話を聞いてくれました。今後、スタートアップは大手と組んでいかないといけないと感じています。そんな時、大手に旨味をとられるのではないか、潰されるのではないかと心配してもしかたがありません。大手はリソースがあるので、やろうと思ったら提携せずともできてしまいます。なので自分たちの持ち味をいかさないといけなければならないのです。 「データの力を、まちの力に」〜UDC2015の取り組みとオープンデータ・プラットフォームDKANの活用〜 登壇者：東京大学空間情報科学研究センター（CSIS） 瀬戸 寿一 さん 登壇者：ANNAI 太田垣 恭子 さん 私たちはUrban Data Challenge 2015というプロジェクトを行っています。これは1年間を通して地域課題を解決していくプロジェクトです。地域課題というのは短い期間で結果を出すのは難しいと感じています。例えば札幌の保育園マップをベースとして、同様の動きが東京などに広がっています。 私たちは全国20拠点を設けていて、通年でワークショップで行っています。金沢では毎月ワークショップをやっているくらい活発です。また、社会性ある活動とあって、データパートナーが多いです。国立国会図書館、NAVITIME、オープンガバメント推進委員会などです。 オープンデータについては2014年は2500件でしたが、2015年は10457件と4倍以上になっています。ただし、日本のオープンデータは自治体のサイトに埋め込まれているため、手作業で収集しなければなりませんでした。中にはWeb APIでデータをオープンにしている自治体もゼロではありません。流山市、会津若松市はAPIを提供中です。 このオープンデータを支える仕組みとして知っておいて欲しいのがオープンデータポータルである、そのオープンソース実装がdkanです。システムはDrupalを使っています。DrupalはWebアプリケーションプラットフォームとして知られていて、有名なところではホワイトハウスがあります。政府自治体で24%のシェアを誇っており、オーストラリア政府はすべてDrupalにしようとしているくらい認知度があります。 そしてDrupalはAPI連携に強いCMSであり、REST対応にも対応しています。例えば以下のようなプラットフォームと連携できます。 他のDrupalサイト Android iPhone その他 オープンデータとは誰でも自由に使えるデータ置き場のことです。再利用、再配布も許可されています。そのため、使いやすいことが大事です。外部連携やAPIで取得できたり、各データのURIがあったりといった具合です。ただ、自治体の担当者レベルではCSV公開ですら大変なのが実状です。そんなレベルではデータ検索がしたいニーズはあるのですが、作るのは大変だったりします。 そういった機能をパッケージングしたのがdkanです。Drupal拡張なのでモジュールも利用できます。ECも大丈夫です。似たようなものにCKANもあり（Python）、dkanはCKANとのAPI互換となっています。他にも組織による権限分配に対応していて、自治体のような組織でもワークフローが構築できます。データはSolrを使って検索できます。 ロシア政府データポータルもdkanでできています。表形式で出したりグラフ化、地図化できます。データは一般公開なのか、ユーザ登録必須とするかなど自由に設計できます。 品質APIのご紹介とniconicoでのトライアル事例 登壇者：NTTネットワーク基盤技術研究所 木村 拓人 さん QoEとはユーザ体験の品質のことで、今回は品質APIシステムがどういったものであるか紹介します。仕組みとしては次のようになります。 ユーザから視聴要求がくる 基地局、IPアドレスなどを受け取る 見たい動画に対して幾つかのレートを持っているので、品質APIに問い合わせる 品質APIは最適な動画の品質を返す ネットワーク品質に応じた配信を行うことで、再生停止発生率を著しく低減されられました。また通信データ量を20%下げることにも成功しました。 ユーザの視聴環境、動画配信条件を入力として、最適な配信条件を返す仕組みとなっています。 応用として、 通信前にAPIを叩くことで、通信状況が悪いためしばらくお待ちくださいといった案内が出せる 通信品質マップ などが考えられます。 第1回に比べて企業色を強く打ち出したイベントになっているかと思います。参加者の方の満足度も非常に高く、登壇の後の懇親会も大変盛り上がっていました。 次回は2月10日を予定しています。ぜひご参加ください！

APIを提供する多くのサービスにおいてステータスページを提供しています（ AWS Service Health Dashboard 、 GitHub System Status 、 Apps Status Dashboard など）。特に企業向けにAPIを提供する際にはSLAが必要になりますので、外部から見られるステータスページの存在は大事です。 今回はそんなAPIのステータスチェックの仕組みを作る上での注意点をあげていきます。 1. DB操作を含めること APIサーバに単にアクセスしてレスポンスを受け取るだけであれば、それはAPIというよりもHTTPサーバのステータスレベルのチェックになります。これでは殆ど意味がありません。 確実にDB操作を伴う操作を行うようにしましょう。それによりアプリケーションサーバ、DBサーバのステータスがチェックできます。なおファイルを保存したりする場合はその部分も動作チェックを行う必要があります。 2. 正しいエラー操作を行う 正常系だけのテストでは片手落ちです。400系、500系を含めた正しいエラーコードが返ってくるかどうかもきちんと確認しておきましょう。時々エラーステータスコードを変更したりすることがありますが、元々のエラーステータスを期待しているクライアントもあります（正常系ですが、200が201になるなど）。 APIのステータスチェックはブラックボックステストになりますので、正常系はもちろんのこと、エラー系についても網羅的にテストしておく必要があるでしょう。 3. データをクリーニングする ステータスチェックはテストではありませんので、一般的に本番サーバ上で行われます。そのためステータスをチェックする際にデータを追加している場合は、それを元に戻してあげる必要があります。 登録したデータに対して削除処理を行うことで元の状態に戻るようにしておく必要があります。特にリアルタイムバッチ処理であったり、ファイルの保存が伴う場合にもきちんとデータが削除されるようにしましょう。その点においてRESTful APIであればDELETEメソッド時の処理として保証されるでしょう。 4. 認証を行う DBを操作する場合と同様にAPIのステータスをチェックする際には認証を行うようにしましょう。できれば新規ユーザの作成からユーザアカウントの削除まで一貫してチェックできるのが良いでしょう。 認証の状態によってエラーが発生するというのはよくありがちです。特に本番環境のデータは予定していたものと異なる場合も多く、その結果としてAPIがエラーを起こすというのはよくあります。 5. レスポンスを測定する ステータスは生死確認だけではありません。レスポンスについても測定し、閾値を越えるようであればアラートを出すようにしましょう。特にデータ量の増加に伴うレスポンス低下は最初には分からないエラー要因になりますので注意が必要です。 APIの場合、外部システムから定期的に多くのリクエストが発生します。一度待ちが発生すると、雪だるま式に積み重なって処理しきれなくなる可能性があります。トークンごとのアクセス制御も必要ですが、システムのレスポンスが適切にできているか（遅延が発生していないか）は常に注視しましょう。 6. 海外からのステータスもチェックする インターネットはグローバルなサービスであり、国内限定のAPIでもない限りは海外からの利用においてもステータスのチェックが必要です。時々、特定の外国からアクセスできないといった問題が発生することがあります。もちろん多くの場合は諸外国側のネットワーク問題になります。 ステータスチェックを同じサーバ、ネットワーク内で行っても意味がないのと同様、なるべく離れたサーバから監視する必要があります。その際には日本、US、EUなど複数箇所からモニタリングできるようにしましょう。 7. APIが外部サービスにつながる部分も確実に、かつ慎重に APIゲートウェイの場合、APIがさらに外部のAPIに接続して出力を加工していることがあります。そうした場合、自社のサーバは問題がなくとも、外部サーバのエラーによってAPIに問題が生じることがあります。 外部サービスへの過度の負荷は避けるべきですが、APIのステータスチェックを行う際には外部サービスも含めて確実に行っておきましょう。また、外部サービスがエラーになっても利用者に不具合が発生しないよう、あらかじめエラーステータスコードを設けておきましょう。 しっかりと構築されたシステムにおいてもエラーは発生するものです。Webブラウザからのアクセスであれば人が見た目で判断して復旧までアクセスを控えることができます。しかし自動化されたシステムにおいてはそういった機構が備わっていないことも多々あるようです。 予想外のエラーは利用者のシステムに思いもしなかったエラーを発生させる可能性があります。そうならないためにも日々の運用状況を適切に可視化するようにしましょう。

最近になってFinTechと言われるキーワードが聞かれるようになってきました。Finance + Techの造語で、特に銀行/証券系などの金融サービスとインターネットテクノロジーを組み合わせた新しいサービスを指し示しています。 FinTech自体は概念となっており、その特徴としては以下のように挙げられます。 1. オープンではなくクローズドなAPI公開 みずほ銀行とLINEが提携して、 LINE上で残高照会ができるサービス を開始していたり、 住信SBIネット銀行とマネーフォワードが提携して家計簿に反映 するといった事例が見られるようになっています。要点としては、これらは一般公開されたオープンなAPIではなく、提携企業にのみ公開されるクローズドなAPIであるということです。 FinTechはお金が絡むとあって、一つのミスが金融企業の根幹を崩しかねない危険性をはらんでいます。それだけに多くの企業がAPI公開に及び腰だったのですが、周辺サービスが拡充してきたのに合わせて特定企業向けにAPI公開する流れになっていると言えます。 2. オンライン決済サービスが牽引 FinTechというワードは後付けで、元々PayPalなどを筆頭に決済・送金サービスの多くはAPI公開をしています。日本でもここ数年で SPIKE（スパイク） や WebPay 、 PAY.JP といった新しい決済サービスが誕生しています。 また、数年前に話題になったBitCoin系の仮想通貨サービスも様々な問題は抱えつつも規模を拡大しており、ブロックチェーンサービスとして成長しています。特に マイクロソフトではEthereum Blockchain as a Service（EBaaS）としてクラウドのブロックチェーン開発環境の提供を開始 しています。 3. 世界におけるトレンド まだまだ技術革新が考えられるとは言え、成熟している決済サービスの他に世界で注目を集めている分野は主に3つ考えられます。一つは銀行系である預金、資産運用系です。もう一つは資金調達や融資に関係するもので、VCなどの巨額のものではなく、個人や中小企業を対象としたマイクロファイナンス系になります。 最後は企業向けのサービスです。現状、FinTech系の多くは消費者向けに提供されるものが多くなっています。そしてそのデータは自社サービスの機能拡充として提供されるものです。対して企業向けの場合は新しい収益源になりえるものが期待されるでしょう。APIによる自動連携をもとに新しい事業が生み出せるかどうかが市場の未来を握っているのではないでしょうか。 4. 自社だけで完結しないのがFinTech 金融×テクノロジーというだけではWebサービス化して終わりのように見えますが、FinTechの特徴としてAPIに注目しなければならないでしょう。つまり他社との連携を視野に入れる必要があります。そのためプレイヤーとしては、基盤になるサービスを提供する企業と、それらを使って顧客やユーザ向けに情報提供する企業とに分かれています。 前者はどちらかというと銀行や証券外車と言った長い歴史をもった企業が、後者はマネーフォワードやfreeeといった新興企業が多いようです。いずれにせよ、新しいユーザ層である若い世代や新しいツールを使いこなす人たちを囲い込んだ新興企業の顧客層を旧来の金融系企業の基盤と組み合わせることで新しい魅力が生まれる点がFinTechの魅力と言えます。 逆に垂直統合的に自社だけでやろうとするのは幅広いユーザ層の取り込みという点においてお勧めされません。銀行一社が自分たちの顧客向けだけにサービスを作ったとしても、現在は複数の預金先をもっている人が殆どでしょう。そうした他の銀行まで扱える可能性がないサービスをあえて使おうとする人は多くないと考えられます。 実際のところ、一般企業としてFinTechをどう捉えるべきなのでしょうか。幾つか考えられます。 現在FinTech関連は出資を受けやすいということもあり、FinTech関連の事業を興す API連携を使って自社の経理周りの業務を自動化する 中小企業融資など、FinTechサービスを利用する 世界をソフトウェアが飲み込むというのは数年前に出たフレーズですが、実際金融系においても通貨や証券の仮想化・デジタル化を通じてソフトウェア化が進んでいると言えます。現実世界で感じている課題があれば、それをソフトウェア化することで解決できる可能性があるでしょう。