地方自治体や政府のオープンデータでの成功事例が多くなってきました。IoTやWebサービス、事業戦略などにも利用できる可能性をを秘めた情報もあることでしょう。そんなオープンデータを探すきっかけとなるサイトをまとめました。 DATA GO JP（データカタログサイト） 政府が運用する、情報ポータルサイトです。内閣官房情報通信技術（IT）総合戦略室で企画され、総務省行政管理局が運用しているとのことです。サイト内はオープンデータの検索が出来るようになっていて、各省庁、グループ、タグ、フォーマットで絞り込めます。また、開発者向けに、サイトで利用しているデータベースそのものの「オープンデータAPI」が用意されています。機会があれば、APIを試してみてはいかでしょうか。 LinkData.org オープンデータを活用するために、データセットをまとめて検索できるサイトです。非常に多くの自治体データが検索できますので、まずはここで検索するとよいでしょう。 オープンデータを利用したアプリなども多く紹介されています。参考になるアプリも探すことができるのではないでしょうか。 公共クラウドシステム ジャンルとしては今のところ観光情報だけとなっていますが、APIが用意されており、全データCSVでダウンロードも可能です。一つの観光情報のデータ量としては十分な情報があると思いますが、観光情報としてはもう少し写真が多いと良いので、その辺りは別の情報とマッシュアップすれば良いのではないでしょうか。地方の観光情報を探す点では非常に有益です。 自治体オープンデータ 福岡、北九州を中心としたオープンデータのサイトです。 まだ自治体数が少ないですが、サイトデザインも非常にまとまっており利用者に対して考えられているサイトです。 データセットも多く揃えられており、1時間で更新されるようなリアルタイムなデータも存在しました。 データもCSV形式、Excel形式が多くあり、データの二次編集がやりやすいと思います。 オープンデータの活用事例 防災情報 全国避難所ガイド オープンデータを利用した、全国の避難所データが10万件以上収録されているスマフォアプリです。データベースは随時更新されているようで、一時滞在施設や給水拠点、医療機関などが検索できます。アプリ起動と同時に、現在地からの避難所が表示されるのはとても便利です。 カーリル | 日本最大の図書館蔵書検索サイト オープンデータを利用して、全国の図書館を串刺しで借りたい本を検索出来るサイトです。本のデータベースとなると、重いというような印象を受けますが、カーリルにおいてはそれを払拭するようなスピードとなっており、公共のデータと、民間の技術がマッチした素晴らしい例だと思います。サイト自体でもオープンなAPIも提供されていて、過去には、そのAPIを利用したコンテストも開催されたようです。 オープンデータの今後 日本政府においても、「機械判読に適したデータ形式を、営利目的も含めた二次利用が可能な利用ルールで公開する「オープンデータ」の取組を推進しています。」 日本政府データカタログサイト より抜粋 ここで言う機械判読の定義なのですが、PCなどで表示や閲覧できる方法のことを指しているであろうことから、Excel形式、PDF形式の配布もあるようです。しかし企業などがシステムでデータ活用を行うとすると、データそのものが欲しい場合が多く、これらのフォーマットはとても扱いにくくなります。 情報によっては、CSVなどフラットデータも存在しますが、まだまだその様にまとまっているデータは少なく感じました。 公共データが自由に使える社会となっている現在、自社サービスへの取込、販売促進などなど…これからの益々増えていく政府・自治体のオープンデータを活用するアイデアを生み出して行くことが、さらなるオープンデータの発展を生むことでしょう。

APIですべてのデータを発信することに対して危機感を抱くというのはよくあることです。類似の他社サービスに簡単に乗り換えられてしまうのではないか、乗り換え用の変換ツールを作られてしまうのではないかと言ったことが考えられるでしょう。 しかし利用者視点で考えるとデータエクスポート系の機能はとても大事なものです。そして、それは翻って自社サービスにとってもプラスの価値を持つものになります。 移行するのは簡単ではない いくら機能としてエクスポートができるとしても、実際に乗り換えるというのは大きなコストです。実際に使われるのはサービス自体が終了する時くらいでしょう。 APIを他社と全く合わせて提供するのは困難です。似たような機能を提供するAPIであったとしても、インタフェースは異なるのが一般的です。そのため、サービスを移行したとしても新サービスに合わせた開発は必ず発生します。そうしたコストは決して小さくないため、乗り換えは困難になります。 移行するのはサービスの質の問題 大きなコストを払ってでもサービスを変えようと考えるのはよほどのことです。つまりAPIにエクスポート機能があろうとなかろうと乗り換えたくなるくらいサービスの質に差があるということです。エクスポート機能がない、サービスの質が悪いという状態は利用者にとって大きなデメリットであり、サービスに対して悪い印象しか残らなくなってしまうでしょう。 エクスポート機能が与える安心感 しかしエクスポート機能が提供されているだけで利用者に与える心象は大きなプラスになります。いざとなれば（そのいざは殆どないわけですが）載せ替えできるという安心感がサービスに対する信頼につながります。 バックアップ機能になる APIのデータがきちんと履歴管理されているならばまた違いますが、多くのAPIは最新のデータを返すものが多くなっています。そのため利用者視点で考えるとデータが誤って削除されたり更新されてしまった場合に備えてバックアップを取っておきたいと考えるでしょう。 日々自動的にエクスポートが行えるならば、それがバックアップとして利用できるようになります。載せ替えはしなくとも、バックアップ目的でエクスポートを利用したいというのはよく聞く話です。 選定時のメリット これからAPIを使っていこうと考えている開発者が類似のサービスを見比べた時、エクスポート機能を備えているものとそうでないものがあったとします。その時エクスポート機能を備えているものは大きなアドバンテージになります。 開発者として、データのロックインを嫌います。特にAPIのようにシステムで自動連携、日々データが蓄積されていくものは使い始めたが最後、データは増えていく一方です。それがロックインされているというのは経営上のリスクにもなります。 エクスポートできるということは、最後のハンドリングは自分たちでできるということです。エクスポート機能の有無は選定に大きく関わってくるでしょう。 API提供企業としては一度使い始めたユーザを取りこぼしたくない、逃したくないと考えるのは自然なことです。その結果、データをロックインする傾向にあります。しかし、逆に利用者視点で考えるとロックインされるのはリスクでしかありません。 API提供企業は利用者を増やすためにも、利用者視点でサービスを提供することを考えなければなりません。特に対開発者という視点で考えると、データのロックインは最も避けるべきことと言えます。

今回はAPIのバージョン管理について主なパターンと、既存のソフトウェアで使われるバージョン管理との相違点について紹介します。 パス もっともオーソドックスな方法と言えます。多くの場合、次のようになります。 /v1/users またはバージョン番号を日付で行っているケースもあります。 /2016-06-01/users バージョン番号を持たせるケースの場合、何をもってv2にするかが問題になります。日付の場合、リリースしたタイミング（その日付）を使うので数字の付け方に悩むことはないでしょう。 ただし、これらの方法の場合、 何をもってバージョンを上げるか という問題が常に付きまといます。既存の修正なのか、バージョンアップなのかの区別が判断しづらいということです。できればリリース前にバージョンの付け方をルール化しておくのがいいでしょう。 また、v2を作った場合にすべてのAPIがインタフェースを変える訳ではないという問題があります。usersは変えたとしても、productsやその他のインタフェースはそのままで良いというケースがほとんどでしょう。そうした時に、あるAPIは常に古い日付であったり、逆に更新されていないけれどもバージョンが上がってしまうAPIが出ることになります。 HTTPヘッダー バージョンをHTTPヘッダーに含めるケースがあります。このメリットとしては、パスのように アクセス先を変えないで済む ということです。エンドポイントはAPIのバージョンが上がったとしても変わりません。利用者としては常に同じURLで使えるというのはメリットがあります。 デメリットとしては多くの場合、HTTPアクセス部分は共通化して作られるため、usersはv2、productsはv1といった具合に切り替えるのは簡単ではないということです。特にHTTPヘッダーのような情報は共通化した上で、v1またはv2という文字列で固定されてしまっている可能性があります。 SDKやライブラリです隠蔽する方法も考えられますが、それでもバージョンを指定してもらうというのは余計な手間を増やしてしまうためあまり良いと方法とは言えないでしょう。 クエリー クエリー文字列の中でバージョンを指定する方法もあります。こちらはHTTPヘッダーと同じでエンドポイントは常に同じです。そしてURIのクエリーの中でバージョンを指定します。HTTPヘッダーよりは変えやすい印象です。 この場合、バージョンを固定しておけば返ってくる情報は常に同じという安心感があります。パスで指定するケースに比べて、管理単位が細くなる印象です。 // パスでの指定 /v1/users /v1/products /v2/users // v1とは別なレスポンス /v2/products // v1と同じレスポンス // クエリーでの指定 /users?v=1 /users?v=2 /products?v=1 クエリーでの指定の場合、v=2は存在しないことになります。開発者としては新しいデータ取得法を使いたい場合はv=2を指定し、そうでない場合はv=1を指定することになります。 デメリットとしては共通したアクセスになるので、クエリーでの指定を見てレスポンスを返す分、ソースコードの分岐が増えてしまいます。徐々にソースコードが汚くなるかも知れません。 case params[:v] when '1' // バージョン1を指定した場合 when '2' // バージョン2を指定した場合 end もちろん最初からバージョンアップする前提で作られている場合は綺麗に設計もできるのですが、多くの場合バージョン番号は用意していても使うための仕組みはないケースが殆どです。 一般的バージョン管理との相違 パスにバージョン情報を入れた場合、印象としてはSubversionのような全体でバージョン番号を持ったバージョン管理に近い印象になります。もちろん、更新されていない /v2/productsに対してアクセスがあったら/v1/productsを呼び出すといった形にできますが、利用者としては v1 と v2 で何が違うのかと疑問に思ってしまうことでしょう。ドキュメントにその説明を載せるのも面倒です。 かつてあったCVSの場合、バージョン管理はファイル単位になります。クエリを使った方法はこれに近いものになるでしょう。アクセス先単位でバージョン番号を指定するのはあまり筋が良いとは思いませんが、現実的かも知れません。この場合、アクセス先単位でドキュメントに v1、v2の相違について掲載できるようになります。 Gitのような分散型バージョン管理の考え方をAPIのバージョン管理に適用した場合はどうなるでしょうか。これは2つの考え方ができます。 タグを使った全体の制御 まず大きなリリース単位によってタグを使います。このタグはパスに含めるのが良いでしょう。v1、v2相当になります。 アクセス先単位での細かい指定 さらに細かく動作を指定したい場合はクエリ文字列を使って設定できるようにします。これは次のタグに至るまでの細かいバージョン番号と言えます。基本的にはタグを使ったものだけで十分でしょう。 APIのバージョン管理はあまりうまくいっていないケースが多い印象があります。どのタイミングでバージョンを上げるか、後方互換性をどう維持するか、修正と機能追加の違いは何かといった具合です。 これらは既存のソフトウェアのバージョン管理が参考になると言えます。メジャー、マイナーアップデートなどの考え方、APIの開発計画に合わせてバージョン更新を考えていくのが良いでしょう。多くの場合、一度目のバージョンアップを躊躇してしまうためにずっと同じバージョン番号で更新を重ねてしまうようです。最初のバージョンアップは事前の計画に沿って進めていくのが良いでしょう。

最近のAPIはJSONを基本フォーマットとして提供していることもあり、Webアプリケーションから利用したいという要望が強くなっています。しかしWebアプリケーションでのAPI利用は、サーバサイドとは異なる問題点が幾つもあります。 非同期 Webアプリケーションの場合、基本的に利用する言語はJavaScriptになります。JavaScriptはシングルスレッドな実装なので、ネットワークやデータの処理に時間がかかるものを同期処理にすると、処理が完了するまで全く何も操作できなくなってしまいます。それを防ぐためにJavaScriptは非同期で実行されます。 非同期処理においては何かの処理完了を待ってから次の処理につなぐといった動作をする際にコードがネストしながら書くことになります。現在、Promiseやyield、syncといった新しい技術も開発されてきていますが、APIとのデータ送受信は非同期処理であることを強く意識する必要があるでしょう。 CORS Webブラウザはセキュアな設計を重視しています。そのため表示しているサイト以外のデータを利用するのに対してセキュリティ上の制約がたくさんあります。特にプログラマブルなAjaxについてその傾向が強くなっています。 GETであればJSONPが使えますが、POST/PUT/DELETEといったメソッドについてはサーバ側でCORSがサポートされている必要があります。逆にサーバ側の設計としては無制限にCORSを許可するのはセキュリティ上のリスクになるということを把握しておく必要があります。 キーの隠蔽 APIの利用に際してキーを使う場合、そのキーが漏洩しないように注意しなければなりません。HTMLやJavaScript上に定義するのは問題です。多くの場合、Webサイトのドメインとキーの組み合わせで制御しています。 安全な方法としてはOAuth2でドメインを使って制御するのが良いでしょう。また、提供側としてはトークンの再生成機能を用意しておくのも必要です。 認証 Webアプリケーションではキーの完全な隠蔽が難しいので、認証においても注意が必要です。OAuth2を使うのが良いですが、場合によってはトークン認証を使うかも知れません。トークンが漏洩すると外部からデータ操作が可能になってしまうので注意が必要です。 Basic認証はID/パスワードの入力が必要になるのでお勧めしません。APIと関係なく認証だけを使いたいのであれば、OpenIDを使う方法も考えられます。 コードが公開される JavaScriptの最大の難点としてはソースコードが公開されてしまうことでしょう。難読化することもできますが、逆に可読性を回復させるソフトウェアも存在するので大した意味はありません。 現在、ウェブアセンブリとしてJavaScriptをコンパイルする技術も開発が進められていますが、標準化するのはまだまだ先でしょう。そのためソースコードは誰かに見られても大丈夫なようにしておく必要があります。 Webアプリケーションの場合、サーバサイドで使うのと違う点としては、 利用主体がコンピュータ（サーバ）/人（Webアプリケーション） ソースコードが見られない（サーバ）/見られる（Webアプリケーション） が挙げられます。相違点を適切に把握し、セキュリティに配慮した利用が肝要です。提供側としては、利用主体の違いによって提供するデータであったり、方法を選定する必要があるでしょう。

APIは自動処理であるという点において、セキュリティリスクの大きい技術と言えます。もし認証情報が漏れると、次のようなリスクが起こりえるでしょう。 データを一気に消される プライバシーや機密に関わるデータを一気に抜かれる 違法なデータをアップロードされる 不要なデータが大量に送られる そうした状態を防ぐためにもセキュリティについて十分な配慮が必要です。 1. アクセス制限をかけましょう 企業同士の提携によるAPI利用の場合、IPアドレス単位でアクセス制限しても良いでしょう。そうすることで提携先の企業からの正しいリクエストであると担保できます。 2. 認証をかけましょう 個人や利用者単位であればOAuth2を使い、サーバからのアクセスであればトークンや証明書形式での認証を行いましょう。トークンや証明書は複数発行できるようにし、万が一漏れた時にリニューできるようにしておきます。 3. 通信はSSL/TLS 企業の特定の場所からのアクセスであっても通信はSSL/TLSを使って暗号化処理を行いましょう。パブリックなものでなくとも、クライアント証明書でも良いでしょう。 4. アクセス権限をつけましょう 企業レベルのAPIであれば、トークン単位であってもアクセスできる機能に制限を設けられるようにしましょう。そうすることで、不用意なデータアクセスを避けられるようになります。 5. バックアップをとりましょう APIからのデータ削除処理は処理としては正しいデータ削除となります。データ更新についても同様です。かなりバックアップを取り、データを復旧できるようにしておくべきです。直近のデータ操作であれば、取り消し処理ができるようになっているのが望ましいです。 6. ログを取りましょう 操作ログを残しておくのは監査目的にも重要な意味を持ちます。操作前のデータと操作後のデータを取っておくことで、バックアップにもなるでしょう。 7. 異常なデータ操作を検出できるようにする 不要に大量のアクセスが一気にきた場合、それらを検出して処理をペンディングする仕組みがあります。APIにおいても必要な技術です。 また、最近では機械学習分野が進んでおり、定常的ではない操作が行われた時に通知を出せるようになっています。誰もいないはずの深夜にアクセスがきた場合や、普段行わないデータ検索が行われたといった時に検出できるようになっていると、より早く問題解決につなげられるはずです。 API操作のためのキーが漏洩したりすると、誰も知らない内に大量のデータが消されていたなんて問題になる可能性があります。また、辞めた担当者が外部からデータを閲覧していたということになったらセキュリティ上の大きなリスクになるでしょう。 APIは自動化の仕組みのため、普段運用の中では気付きづらい存在と言えます。だからこそ未然の準備と、検出する仕組みが必要になるのです。

昨今は内部・外部ストレージ、クラウドストレージも格安サービスが増え利用が手軽になり、気軽に大容量データを扱えるようになりました。 サイト内でも画像を手軽にアップロードしたりするサービスは、必須条件といっても過言では無いくらい要求が高まっていますが、それに伴ってデータを整理、分類して、次のサービスアップに繋げることが肝心となっています。 そこで今回は、画像解析を行ってくれるAPIをまとめました。 ※ なお、API仕様や利用料金などは、2016-05-26現在のデータとなっています。 AlchemyVision (IBM Watson) IBM Watsonの画像解析APIです。年齢範囲、男女、テキストなどを取得できます。 複数の人数にも対応していて、かなりの精度で解析が可能です。 しかし、あまりフレーム内に顔が接近していると判別が難しい様子で、これからの精度アップが期待されるところでしょう。 同サービスのVisual Recognitionにマージされたとアナウンスがありましたが、今後このサービスが継続されるかどうかまでは現在の所は説明がありませんので、利用にあたっては注意する必要があるでしょう。 サイトページ： AlchemyVision | IBM Watson Developer Cloud デモページ： Alchemy Vision Visual Insights (IBM Watson) IBM Watsonの画像コレクション解析APIです。 写真のコレクション（Zipアーカイブ）から、人や動物、物、場所等を含め、アクティビティの内容や関心事項の値を解析できるAPIです。 写真1枚を解析するのではなく、コレクション全体の中での占める割合を算出してくれます。 出力内容は、画像イメージの階層構造とスコアリングが中心となっています。 サイトページ： Visual Insights | IBM Watson Developer Cloud デモページ： Visual Insights Visual Recognition (IBM Watson) IBM Watsonの画像解析APIです。 同サービスのAlchemy Visionは、2016年05月20日に、こちらのサービスにマージされたようです。 クラス分類、taxonomy分類、顔検出（性別、年齢範囲、有名人など）の解析が可能です。 Bluemixの１アカウントで、一日あたり250のイベント（画像）まで無料ですが、それ以上は解析内容ごとに料金が変わるので注意が必要です。 サイトページ： Visual Recognition | IBM Watson Developer Cloud デモページ： Visual Recognition Demo Google Cloud Vision API Google Cloud の機械学習による画像APIです。 OCR機能、属性、ランドマーク、顔、ロゴ、有害コンテンツの検知、ラベル(物体)検知などが可能です。 チュートリアルは Google Storage を利用する方法になっていますが、バイトデータを直接送信することもできるAPIとなっています。 課金方法は、機能ユニット単位となっており、例えば顔検知とラベル(物体)検知をした場合、両方の機能の利用分が月額で請求されます。 最大で20Mユニット/月 となっていますが、申請をすれば追加で拡張できるようです。 Google Cloud Vision API Computer Vision (Cognitive Services) Microsoft製の画像解析APIです。 状況説明、タグ付け、アダルトコンテンツ、カテゴリ、カラーなどが解析できます。 有名人などを認識可能であり、世界中のビジネス、政治、スポーツ、エンターテイメントから200000人もの有名人を認識できるそうです。 また、テキスト解析、変わったところではサムネイル生成も可能となっています。 利用料金は5,000トランザクション/月まで無料となっていますので、いろいろと試すことが出来そうです。 サイトページ： Microsoft Cognitive Services - Computer Vision API Emotion (Cognitive Services) Microsoftが提供する画像解析APIで、「怒り」「軽蔑」「嫌悪感」「恐怖」「幸福」「中立」「悲しみ」「驚き」のスコアリングするAPIです。 複数人の解析もカバーしており、それぞれの顔の位置情報も取得できます。 かなり隣接した顔位置でも解析ができるようで、精度も安定しているようです。 利用料金は30,000トランザクション/月まで無料となっています。 サイトページ： Microsoft Cognitive Services - Emotion API Microsoft CaptionBot 最後にAPIではありませんが、Microsoftの画像解析サービスサイトを紹介します。 これは、上記のMicrosoft Cognitive Servicesを組み合わせて作成されているようです。 画像をアップロード、URLなどで指定すると、それについて解析してコメントを返却するサービスとなっています。 このように、APIの組み合わせ次第で面白いサービスができるという一例でしょう。 サイトページ： CaptionBot 最後に 画像解析APIは、各サービスで趣向をこらしているようです。 BigDataを扱うことで、非常に優れたサービスが、大変多く出てきている印象をうけます。 画像解析APIは、アイデア次第でいろいろなサービスに組み込むことができそうです。 ぜひ皆さんのサービスに役立ててください。

APIというのは主に外部の開発者が見ることになります。そしてその設計思想が彼らの思いとマッチしていないと使うのを嫌がられることになります。逆にエレガントで統一性のあるAPIは開発者を刺激し、使おうという姿勢に変えてくれます。 ​ そこで今回は多くのAPIを提供している各社がリリースしたAPIガイドラインを紹介します。 ​ interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API ​ Herokuが実践しているAPIデザインガイドになります。ステータスコード、リソース、タイムゾーン、パスの付け方、バージョニングなど数多くの項目に渡って記述されています。 ​ API開発指針 | EC-CUBE3 ​ ​ 国産Eコマースシステム、EC-CUBE3におけるAPI開発指針になります。日本語で書かれているので分かりやすいでしょう��� ​ これから始めるエンタープライズ Web API 開発 | オブジェクトの広場 ​ ​ エンタープライズAPI設計における注意点がまとまっています。使いやすさ、分かりやすさ、安全性、堅牢性、耐障害性などエンタープライズならではの説明があります。 ​ Web API設計指針を考えた | MMMブログ ​ ​ MMM社によるAPI設計指針をブログで公開しています。URL、レスポンスなどについて記述されています。 ​ WhiteHouse/api-standards ​ ホワイトハウスのAPI標準です。オープンデータを進める上でもこうしたドキュメントが公開されていることで一貫性をもった提供が期待できるはずです。 ​ api-standards/api-style-guide.md at master · paypal/api-standards ​ PayPal社のAPIスタイルガイドです。複雑なオペレーションにおけるリスクとメリットなどは参考になる点がありそうです。 ​ 18F/api-standards: API Standards for 18F ​ 18Fというのは米連邦政府のテクノロジーチームだそうです。彼らのAPI開発におけるベストプラクティスがまとまっています。 ​ refinery29/api-standards: Refinery 29 API Standards ​ ソートやページネーション、モックレスポンス、検索など実用的なAPIにおける標準がまとまっています。 ​ API Design eBook ​ ​ ApigeeによるAPIデザインの電子書籍（PDF）になります。2012年のものですが、内容的には現在でも十分通用するものになっています。電子書籍なのでリーダーに入れて読むのに良さそうです。 ​ API Design Guide — API Design Guide 0.1 documentation ​ オーストラリアのシドニーとキャンベラによるAPIデザインガイドです。開発およびその利用に関する説明があります。 ​ ​ 企業がAPI設計指針を作ると言うことは統一感を作り出すのに大事なことでしょう。また、その設計時においてはここで紹介したコンテンツが役立つはずです。将来的にはこうしたコンテンツをベースにしたLint系ツールが出てくるかも知れません。 ​ 開発者を魅了する、魅力的なAPIを提供するためにも設計のいろはは習得する必要があるでしょう。ぜひ参考にしてください。

プロジェクト管理は企業内での製品やサービス開発を行う肝と言えるシステムです。そんなプロジェクト管理でも数多くのサービスがAPIを公開しています。APIによって基幹システムとの連携も容易になりますので、そういった視点で選定してみるのも良いでしょう。 ​ Wrike for developers ​ ​ OAuthを使ってアプリを作り、それとコネクトします。つまりユーザの権限によって取得できるデータが変わります。コンタクト、ユーザ、グループ、ワークフロー、ファイル、タスク、タイムログ、添付ファイルなど数多くのデータが操作できます。 ​ スペース情報の取得 | Backlog API | Nulab Developers ​ ​ APIキーとOAuthの2つの認証が用意されています。殆どすべての操作についてAPIを介して可能で、データの取得についても柔軟に行えます。Wikiページなども取得、更新できるので外部データを取り込んでWikiを更新するといった操作も行えます。 ​ Trello Developers ​ ​ カンバン系のボード、チェックリスト、メンバー、通知、検索、WebHooksなどの操作ができます。サンドボックスも用意されていますので開発者にとって使いやすいでしょう。 ​ プロジェクト管理SaaS Clarizen（クラリゼン） | NSW ​ ​ 具体的な仕様は契約しないと分かりませんが、他システムとの連携を前提としたAPIが用意されているとのことです。 ​ JIRA REST APIs - Atlassian Developers ​ ​ Atlassianが提供するJIRAのAPIです。WebHooksもありますが、RESTfulなAPIによるデータ公開も行っています。認証はBasic認証またはOAuthとなっています。 ​ Smartsheet 日本語 ​ ​ Excelのようなインタフェースでガントチャートが作成できるサービスです。APIとしてもシートやセルなど表計算のような操作ができるようになっています。WebHooksも提供しています。 ​ Code, test, and deploy together with GitLab open source git repo management software | GitLab ​ ​ オープンソースのGitLabですが、ホスティングサービスも公式に提供しています。元々GitHubを追従して開発されてきましたので、APIのインタフェースや機能もGitHubに似たものとなっています。 ​ Kanban Tool API | Online Kanban Boards ​ ​ カンバンを提供するサービスです。RESTまたはJSONPによるAPIを提供しています。認証はトークンのみとなっています。タスクやタイムトラッキング、レポーティングといったAPIがあります。 ​ ActiveCollab API ​ ​ ActiveCollabはBasecamp対抗馬と言われていたほどのプロジェクト管理で、APIについてもほぼすべてのデータを出力、操作できるようになっています。認証は各ユーザのID/パスワードを使って行うようです。 ​ Rest api - Redmine ​ ​ オープンソースのプロジェクト管理システムですが、APIを提供しています。Redmineをホスティングしているサービス事業者もありますので、そういったところで使うと便利でしょう。 ​ basecamp/bcx-api: API documentation and wrappers for Basecamp 2 ​ ​ Ruby on Rails開発元として知られているBasecamp社（旧37 Signals社）の提供するプロジェクト管理のAPIです。Basic認証のみを提供しています。 ​ ​ プロジェクト管理のAPIとしては、外部や社内リソースから取り込んで新しいページを作ったり、外部のCIサーバと連携したIssueの作成などがよく使われます。さらに出力計としては社内の財務管理システムや顧客管理システムとの連携も考えられます。 ​ APIがあるかないかでプロジェクト管理の使い方が全く変わってきます。業務システムだけにシステム連携の可否は大きな鍵となってくるはずです。

各社がボットAPIをリリースしています。メッセージはテキスト主体のサービスなので、開発がしやすいこと、メッセージを解析することでユーザに自然言語的なレスポンスを返してサービス提供できるのが魅力です。 そこで今回は各社がリリースしているボットAPIをまとめて紹介します。 HipChat - API v2 - Getting started 企業での利用が多いチャットサービスHipChatではREST APIによるメッセージの送信とWebHooksを使ったメッセージの受信をサポートしています。さらにカード型というJSONフォーマットによる特殊なテンプレートも実現します。 Office Dev Center - Skype 世界最大規模のチャットネットワークを誇るSkypeでもボット機能があります。Azure上で簡単にボットが構築できる機能がありますが、APIも公開されているようです。 REST APIs | Twitter Developers TwitterのAPIでは受信に関するWebHooksはありません。その代わりにストリーミングAPIが提供されており、それを使ってリアルタイムにツイートデータを受信できます。ただしキーワードによる絞り込みが必要です。 LINE Developers - BOT API - Overview LINEではWebHooksを使ったメッセージの受信に加えて、スタンプなどの多彩なフォーマットでメッセージが送信できるようになっています。 Bot Users | Slack Slackでは受信のWebHooks、送信のREST APIに加えて、新しいボットを開発する機能もあります。ボットマーケットも整備されており、開発したボットを配布するのに使えます。 Messenger Platform Facebook Messengerでは1対1のコミュニケーションが基本となります。写真などのメディアを受信することができ、送信時にはボタンや写真付きレイアウトを指定することができます。 Bot Code Examples Telegramはセキュリティの高さを謳っているメッセンジャーサービスです。WebHooksを使ったメッセージの受信が可能です。写真やビデオなどのメディア情報が構造的に渡ってきます。 Kik Bot Dashboard カナダ製のメッセンジャーサービスです。ボットショップもすでに整備されています。タイピング情報まで取得できるWebHooks機能があります。テキスト、リンク、ステッカーなどのオブジェクトを指定して送信します。 IMified - IMified API 外部サービスを巡回して、JabberやAIM、SMS、Twitterなどで通知してくれるサービスです。それらのメッセージを受信して別なメッセージを送信するといったボットが開発できるようです。 Webhook | Typetalk | Nulab Developers チームチャットサービスです。WebHooksによるメッセージ受信をサポートしています。ボットに対するメンションだけを送信してくれます。 いかがでしょうか。多くのチャットボットAPIはWebHooksをサポートする形で、似たような形式となっています。一つの形に慣れてしまえば、他のサービスに乗り換えたとしてもボットを開発するのはさほど難しくなさそうです。 ユーザからデータを得て、何を処理するかを考えてみましょう。

最近、チャットボットに人気が集まっています。FacebookがMessenger Platformを発表し、さらにLINEがBot APIを発表しました。さらにSkypeや、よく知られているSlackもボットを開発できます。そこに新しいビジネスチャンスを見いだしている人たちもたくさんいます。 そこで今回はチャットボットを作る際に使われているAPIについて紹介します。 WebHooks 一般的にチャットボットではWebHooksが使われています。チャットに投稿があったタイミングで、あらかじめ指定したURLに対してデータをPOSTしてくれます。ボット側から定期的にデータの存在を確認しにいく必要はありません。これは投稿者（IDのみ）、投稿内容、投稿場所といったデータが含まれています。 一度のWebHooksの中には、複数のメッセージが含まれていることがあります。これは通信量を減らすための工夫です。 ストリーミング WebHooksに対応していない、TwitterのようなサービスにおいてはストリーミングAPIが提供されています。これはTwitterのサーバに持続的な接続を行い、指定したワードを含むメッセージが届く度にイベントが発生します。 技術的に若干難度か高いこと、接続できる数に限度があること（Twitterは1アカウント1接続まで。かつすべてのワードがとれるわけではありません）、サービス自体ベストエフォートであるといった点を考えておく必要があります。 RESTful チャットサービスにデータを投稿するのはRESTfulなAPIによって実現しています。HTTPS通信を使い、指定されたトークンを使ってPOSTするだけです。WebHooksとは切り離せますので、定期的なお知らせ、ツイートなどを流す際には外部からコールしてあげればOKです。 OAuth2 多くのチャットボットではチャットメッセージの中にユーザ情報を含んでいません。そこであらかじめ取得したIDを使ってプロフィールAPIを叩くことになります。この時使われるのがOAuth2です。つまり、投稿したユーザの情報が見られる権限（主にユーザ自身）を使ってプロフィール情報を取得します。Slackのようにグループを基本としている場合は、グループの一員であれば情報が取得できます。 ボットはユーザ情報収集目的に使うと危険性が高いので、プライバシーに配慮しているのだと思われます。 いかがでしょうか。チャットボットもこれまでのAPIによって成り立っています。こうした技術を習得しておけば、ボットの開発はとても簡単に行えるでしょう。逆に提供側としてもこの辺りの技術を使って提供すべきで、独自路線はやめておくべきです。

APIではHTTPステータスコードが大事な意味を持ちます。それによってクライアントではエラーが起きたかどうかを判断します。ステータスコードが200でエラーオブジェクトが返ってくると言うのはとても変な状態と言えます。 そこで今回は主なステータスコードとその使い方を紹介します。 正常系 正常系は200番台で表されることが多いです。 200 OK 最も一般的なステータスコードです。単にOKという意味であったり、アップデートや削除が完了した際にも200を使います。 201 Created 新規作成の場合だけ201としているケースがあります。RESTfulであれば、POSTメソッドだけ201にしていることが多いです。 202 Accepted あまり多くありませんがバッチ処理が受け付けられた場合に返すことがあります。 リダイレクト系 300系のリダイレクトは時々使われますが、APIのURLを変更するのは良い仕様ではないのでお勧めしません。クライアントが自動的にURLを変更してくれなかったり、OAuth2のようにシグネチャ生成の中にパス情報が入っている場合、リダイレクトは生成エラーにつながるでしょう。 301 Moved Permanently 恒久的にURLが変わった場合に使います。 302 Found URLが一時的に変わった場合に使います。これはお勧めしません。 クライアントエラー系 システム側で正常なエラー処理として判断されるものは400番台を使います。 400 Bad Request リクエストが不正な場合に指定します。シグネチャ生成のエラーに用いたりします。 401 Unauthorized 認証エラーの場合に使います。ID/パスワード認証はもちろん、トークンベースの場合でも利用します。 402 Payment Required 決済情報が必要であったり、課金上限を超えてしまった場合に利用します。 403 Forbidden リソースへのアクセス権限がない場合に使います。認証はOKですが、権限が足りない場合は403を使います。 404 Not Found リソースが存在しない場合のエラーとして用います。 405 Method Not Allowed HTTPメソッド（GET/POST/PUT/DELETE/OPTIONS/HEADなど）が許可されていない場合のエラーとして使います。アプリケーション側で実装することもありますが、一般的にHTTPサーバ側での対応になるでしょう。 406 Not Acceptable リクエストヘッダー情報が間違っている場合に使います。mimeが間違っている場合もありますが、シグネチャが間違っていたり、セットすべきヘッダーがない場合も406を使います。 409 Conflict 更新がバッティングしたり、ユニークなIDが重複してしまった場合などに使います。 システムエラー系 500番台は主にシステムエラーになります。アプリケーション開発者が認識していなかったエラーが発生した場合はこちらを指定します。APIとして出さない方が良いエラーです。 500 Internal Server Error 主にCGI系のスクリプトで例外エラーが発生した場合に返されます。 502 Bad Gateway アプリケーションサーバが落ちている時にHTTPサーバが返すことが多いエラーです。 503 Service Unavailable アプリケーションサーバ側で何らかのシステムエラーが発生した場合に返します。 他にもエラーコードは幾つかありますが、主に使うのはここで紹介したコードになるのではないでしょうか。適切なエラーコードを選ぶことで、開発者にとって分かりやすいAPIになります。開発を補助する情報として統一感をもって選ぶようにしましょう。

APIの利用者が増えないという悩みは良く聞くところです。そのために行いたい施策を紹介します。 1. インタフェースを他と合わせる もしすでに同分野においてAPIが存在するのであれば、そこに合わせたAPI設計を選択するという手があります。あえて独自性を貫くのは、あまり良い選択肢ではありません。開発者にとっても似たAPIは乗り換え対象にもなるので、全く別な構成よりは似ている方が手軽と言えます。 ただしGoogleとOracleの裁判で見るように、APIにも著作権が認められようとしています（最終的な判決は執筆時点では出ていません）。完全に真似するのは訴訟リスクを背負うことになるので止めましょう。 2. グローバルに提供する APIは自動化の仕組みであり、使っていくことで国境や言語の壁を越えることが多々あります。そうした中、国内専用というのは、海外を考えた時に別なAPIを探さねばならず、後々面倒になります。利用者としては避けてしまうでしょう。 なるべく制限を設けず、グローバルに提供するようにしましょう。 3. 標準技術を利用する 独自の認証技術やアクセス方式を採用するのは止めましょう。RESTfulであったり、OAuth2.0のようにすでに標準化されている技術を積極的に使いましょう。URL設計や、セキュリティ、通信方式などもなるべくすでに数多あるものを採用するのが良いでしょう。 APIはあくまでも利用者にとって使いやすいものであるべきで、提供側のエゴを押しつけるのはよくありません。標準技術の採用は結果としてメンテナンスしやすく、セキュリティにも強いものになるはずです。 4. ライブラリ、SDKを用意する APIを提供するだけで使ってもらえるわけではありません。APIをもっと簡単に使ってもらえるライブラリやSDKを充実させましょう。ライブラリはなるべく数多くの言語を採用すべきですが、最初は提供側の期待する言語からで良いでしょう。例えばエンタープライズであればJavaや.NETが最初になるでしょう。 SDKはスマートフォンアプリ向けに提供されますが、多くの開発者はよく分からないSDKをインストールしたいとは思っていません。また、SDKのせいでアプリが落ちたりするのは致命的な問題になりますので、テストを十二分に行う必要があります。 5. ドキュメントを充実させる APIドキュメントはとにかくしっかりと作り込んでいきましょう。提供側にとっては当たり前のことであっても、利用者は全く知らないことがたくさんあります。それは利用者が不勉強なのではなく、提供側がその道のプロだからです。 コンテンツを拡充させれば、Googleなどの検索流入も増えていきます。利用者はまず最初にドキュメントをチェックして使えるかどうかを判断します。それだけに力を入れたい部分になります。 6. 質問を受け付ける 利用者からの質問を受け付けましょう。質問はなるべくオープンな場所で行い、コンテンツと一部になるように活用していきましょう。利用者の意見、バグ報告、希望する機能を聞くことで開発計画を柔軟に変更し、役立てるようにしましょう。 7. より短いコードで試せるようにする APIを試すまでのステップはなるべく少ない方が良いです。色々インストールする手間があったり、登録して操作が必要だったりするとあっという間に飽きてしまいます。利用者はそこまでしてAPIを使いたいと思っていません。 オンラインだけで試すことができたり、チュートリアルを使って簡単に結果を確認できるようになっていれば、利用者も次のステップに進みやすくなるでしょう。 8. 宣伝する かつてはAPIをリリースするだけで使ってもらえることがありました。また、大手の企業（Google、Facebook、Amazon、Appleなど）であればリリースするだけで開発者がこぞって寄ってきます。しかし多くの企業はそのようなことはありません。 しっかり宣伝し、一人でも多くの人たちに触れてもらえるように努力しましょう。 9. 分かりやすさ APIの説明を一言で言えるようにしましょう。何ができるのか、何が嬉しいのか、明確になっていないと開発者は理解するだけで疲れてしまいます。彼らにあえて使いたいと思うモチベーションがないことを理解しなければなりません。 基本的にいかなるサービスでも同じですが、APIの場合は開発者が対象であること、画面にぱっと出せる見栄えの良いものでないことなどからより明確に、より短い時間でメリットを訴求できるようになっている必要があります。 特に分かりやすさはAPIを広めるファーストステップとして重要と言えるでしょう。

企業におけるAPI活用を広めていくEnterprise APIs Hack-Nightの第4回がTECH LAB PAAKにて開催されました。今回のテーマはFinTechで、雨にも関わらずたくさんの方々に参加いただきました。 今回からEnterprise APIs Hack-NightではxTech（エクステック）に注目しており、各種マーケット×テクノロジーをテーマにしてイベントを開催していきます。今回はFinTech（ファイナンス×テクノロジー）になります。 当日の模様は YouTubeにて公開 しています。最初の方に機械操作音が入ってしまっています、ご了承ください。 「X-Tech」という潮流 NTTデータ経営研究所 妹尾 直紀さん コンピュータは最初期において、単純な計算を行うだけでした。それが数十年経ち、技術連携が行われ、最適化の時代になりました。そして最近ではディープラーニング、A.Iなどによって自ら想像していく時代に入ってきたと認識しています。 それに伴い、これまで業界には存在しなかった企業（IT企業）が市場に参入するようになってきました。ITを活用することで、これまでの事業規模よりも小さくとも十分に収益をあげられるようになっています。そのような中で、市場×テクノロジーというx-Techという流れが生まれています。 幾つかあるのですが、代表的なものとしてはHealthTech、ReTech、FoodTech、EdTech、AdTechなどがあります。主な企業は下記の画像をご覧ください。 実際に様々なサービスが生まれているのですが、その本質は何かを考えると 思考能力のプロモーション 個人と企業のボーダーレス化 使い道のイノベーション に分類されると言えます。その結果として将来どうなっていくかを考えていくと、 思考能力のプロモーション：提供価値の先鋭化 個人と企業のボーダーレス化：プレイヤーの多様化 使い道のイノベーション：ビジネスリソースに関する利用方法の拡大 となっていくのではないでしょうか。この結果として注目したいのがサービスのアンバンドル（先鋭化）です。従来の商品はパッケージングされて、組み合わせ販売されてきました。しかしx-Techによって特化型サービスが登場していくことでパッケージから外れた存在が増えていくことでしょう。その結果、サービスが氾濫してしまい、再度サービスをピックアップして組み合わせた、リバンドルという流れができててくると考えています。 そして、そのアンバンドル/リバンドルを支える存在として、APIをはじめとした共通化されたインタフェースが必要になってくるのではないでしょうか。 ガラケーが支える発展途上国のFintechとAPIの関係 REDKNEE 志田 典道さん（ 当日の動画 　 当日の資料 ） FinTechは世界全体で見た時にお金持ちのための仕組みであるというのが志田さんの考えです。世界のお金持ち、約10億人はクレジットカードを持ち、銀行口座を持っています。そうではない世界60億人の多くは銀行口座すら持っていません。しかし彼らは携帯電話は持っています。ケニアにおける携帯電話保有率は82%となっています。 その携帯電話はいわゆるスマホではなく、SMSと通話機能が中心のガラケーとなっています。そうした地域ではネットワークもLTEではなく2Gが中心です。そして、彼らの中で注目が高いのがモバイル送金サービスです。今回はエムペサというサービスを中心に紹介してもらいました。 モバイル送金サービスはSMSを使って送金を行う仕組みで、仮想通貨に当たる仕組みを使っています。銀行口座がないため、プリペイドでの携帯電話の利用が基本となっています。その充当した金額を他人に送ったり、場合によっては電気料金の支払いにも使われています。 仮想通貨はエムペサの店舗によって実際の通貨に換金できるようになっています。エムペサはケニアの銀行とオペレータ（通信企業など）が作った仕組みになっています。 Q&A 未成年についてはどうか？ 残念ながら未成年、女性に対する現金以外の決済手段はほぼないのが実情です。 オープンソース仮想通貨を使ってリアル通貨の国際送金を実現する PayPal 岡村さん（ 当日の動画 ） FinTechのイチ技術として注目を集めているのがBitCoinをオリジナルとする仮想通貨技術ではないでしょうか。仮想通貨とは国が価値を保証する法定通貨とは異なり、後ろ盾のない通貨になります。BitCoinの場合は中央サーバの存在しないP2Pネットワーク網の中に構築されていますが、派生パターンとしては中央サーバが存在するものもあります。BitCoinの計算処理は数十秒を要しますが、中央サーバがあることで数秒で計算処理が終わるようになります。 BitCoinにない機能を実装しているサービスも出てきています。メタデータを追加したり、そもそもブロックチェーンの外に別なサービスを作って、それとブロックチェーンとつなぎ合わせるサービスもあります。 今回はRippleとステラというサービスを紹介してもらいました。 Rippleは外国為替送金を効率化するためのネットワークとなっています。現在、外国為替の送金（例えばUSドルからユーロなど）はとても複雑で手数料がかかる状態です。これをブロックチェーン技術によって効率化します。 Rippleは元々オープンソースでしたが、今は一部を除いてクローズドになり、企業が運営しています。そしてステラは現在もオープンソースとなっており、自由に仮想通貨プラットフォームを構築できるようになっています。テストネットワークも用意されており、すぐに試せるようになっています。 金融機関とフィンテック、APIへの取組み 三菱UFJフィナンシャル・グループ 藤井 達人さん（ 当日の動画 ） バンキングAPIについての現状について説明がありました。取り組みについてはイギリスが進んでおり、さらにEUでもバンキングAPIの普及を推し進めています。APIを使うことで1週間以内に別な銀行の口座にデータを移すといったことが可能になっています。 日本ではまだまだ特定企業間に限定されていたり、家計簿サービスが銀行のID/パスワードを使ってスクレイピングをしてデータを取得している状況です。APIが普及することによって改善できる可能性があります。特にセキュリティ面において、ID/パスワードではなくOAuth2によって安全に必要なデータだけを公開できるようになるでしょう。 バンキングAPIを標準化するといった動きもありますが、ビッグバンクと地方銀行で熱量が違っていたり、各銀行の特徴をなくさざるを得ないといった問題があります。おそらく最大公約数的な機能だけになってしまうと思います。 さらにAPIをサードパーティーが使って誤った送金処理を行った場合、その責任範囲が誰にあるのかといった問題が不明確になります。その意味ですべての機能をバンキングAPIとして提供する必要があるのかについても議論が必要です。 三菱UFJとしては3月にハンズオンを実施しました。そこではダミーのAPIを提供し、開発者ポータルも作ったのですが、開発者の方々から多くのフィードバックを得られました。こうした活動を通してよりよいAPI設計を行っていきたいと考えています。 Q&A IBMが標準APIを提供しますとアナウンスしていますが？ 正直どうなるか分かりません。ベンダーが売り込めば標準的になっていく可能性もあると思います。 SIerができること？ ベンチャーはtoCに強いイメージがあるので、SIerはtoBをやっていくのが良いのではないでしょうか。 銀行に勤めている側から見て、銀行APIの実用に対する足枷はなにか？ 何が起きるのか分からないという人が多いです。私の周りはバンキングAPIを推し進めようとしている人ばかりなので、反対する人はそんなにいない印象です。ただし、お金がかかりそうだ、という意見が多いです。後、セキュリティの話題が多かったり、送金って本当にやるのかといった点が最近のよくある話題です。 なお、国としてもバンキングAPIを検討するというのをロードマップに組み込んでいます。 APIが出て普及した時、地方銀行はどうなっていくのか？ 地方銀行が自前でAPIを作って提供するのはまだしばらく先になりそうです。APIが地場のビジネスに影響を及ぼすかどうかは分かりません。個人的にはポジティブな面を見ていくべきじゃないかと思っています。 外部コミュニティとどう付き合っていきますか？ まだAPIを公開すると決まっておらず、実現までにまだいくつかのステップがあるのが実情です。GitHubとかを積極的に使っていくべきだと思っています。自分たちが作ったのを使って、という姿勢ではダメだと思います。皆さんの意見を取り入れていきたい。また、一度作って終わりじゃなくβテスト的なものも必要だと考えています。 発表後は懇親会を開催しました。FinTechは注目の高いキーワードだけに、懇親会も盛り上がっていました。 LTにて三菱総研DCSの人見さんが「BTMU FinTech Challenge 2016銀行ハッカソンにAPIパートナーとして参加した」を発表されました。 次回は6月、RetailTechをキーワードに行う予定です。ぜひご参加ください！ Enterprise APIs Hack-Night #4 - connpass

ここ数年で聞かれるようになってきたのがAPIエコノミーという言葉です。一言で言えばAPIを使ったビジネス化ということになるのですが、実態としてはどうなっているのでしょうか。 APIマネジメント系サービスの台頭 最も分かりやすいのはAPIマネジメントと呼ばれるサービスが続々登場していることです。主だったプレイヤーとしても、 Apigee AWS IBM などがあります。企業におけるAPI作成、公開の流れを作りつつ、APIを使って収益化を促せるようになります。自社技術や自社コンテンツを持ち、それらをAPIで公開することによって収益化を図る上で大事な存在です。 企業提携の基礎に 従来、企業連携を行う際にはまず契約ベースの話が固まった後、双方の技術者が仕様を詰めていくのが一般的でした。しかし、これでは3つの問題があります。 企業パワーの違いによって実装工数が偏る 時間がかかる 2社間で最適化されており、別な提携時には同じ手順を繰り返す APIを前提としている場合、どちらも複数企業との連携を前提として考えますので、機能は汎用的なものになります。あらかじめAPIが開発されている場合は、従来の手順に比べて大幅に工数を短縮できるでしょう。 技術を他社から借りる API（Web API）という単語が聞かれるようになってすでに10年以上が経過し、世の中には数多くのAPIが存在します。企業にとって、一からサービスを構築するまでもなく、すでに存在するAPIを使ってサービスを作り上げる方が遙かに効率的で、素早くローンチができる時代になっています。 API提供事業者では既存ビジネスとの兼ね合いで提供できないサービスというのが存在します（他社との比較サービスなど）。そういった隙間を狙って新しいサービスを提供するのも良いでしょう。また、自社の既存サービスに新しい付加価値を追加する際にもAPIを使うことで素早く、確実に行うことができるようになります。 汎用的なテクノロジーAPIの出現 これまでAPIは主にコンテンツを持った企業がそれを公開する手段として使われることが多くなっていました。しかし最近ではクラウドサーバの操作であったり、計算処理のクラウド化、言語処理、機械学習、A.IなどテクノロジーAPIが登場してきています。これらはそのままでは一般ユーザには利用が難しく、使いやすい機能であったり、ユーザ企業が持っているデータと合わせてはじめて付加価値を生み出せるものとなっています。 こうしたAPIを使いこなし、新しいビジネスを生み出すことがAPIエコノミーの醍醐味と言えるでしょう。 APIエコノミーへの関わり方は様々です。この大きな流れの中で自社がどういう立ち位置であるべきか企画してみてはいかがでしょうか。

今回はAPIを利用する側の視点で見ていたいと思います。APIを使わずに構築されることの方が減っている現在、特有の注意点があるとすれば何でしょうか。 削除系の取り扱い APIではその命令を実行すればそのまま処理されます。コンピュータ上で自動処理される場合、あっと思った瞬間にはすべて処理が終わってしまっている可能性がありますので。データの参照、追加処理についてはさほど大きな問題にはなりませんが、更新や削除処理については十分に注意して開発すると必要があります。 間違って不用意なデータの更新、削除を行わせないためには権限管理が欠かせないでしょう。また、バックアップが取れるAPIが提供されているものを利用する方が良いでしょう。 課金体系 海外のAPIでは実行回数によって従量課金されるものもあります。これらは利用するコードのミスによっては膨大な課金になる可能性があります。十分に注意した上で設計しなければなりません。課金アラートがあるサービスもありますが、開発者がミスに気付かないと丸一日課金され続けたといった事態になる場合も多々あります。 運用時の見積もりが取りづらい場合はデータ量やアクセス数などで試算してみる必要があります。一回あたりの処理は安くともAPI経由の場合は一気にアクセスが行われるため予想以上に高くなることもあります。 トランザクションが難しい APIはアクセスごとに処理が行われます。そのため一般的なシステムでいうところのトランザクション処理が難しいのが問題視されます。トランザクションが必要なほど複雑な処理を実行しているのが問題なので、システム全体をシンプルに設計し直す必要があります。 また、どうしようもない場合はAPI提供元に相談してみるのも良いかもしれません。それによって新しいAPIを用意してもらえる可能性があります。ただしいずれの場合においてもトランザクションのサポートは難しいと考えておくべきで、ない前提でシステムを構築する必要があります。 システムダウン、メンテナンス時の対応 従来のアプリケーションサーバ、データベースサーバの組み合わせの場合、どちらかをメンテナンスする際にはもう片方は止めておくものでした。しかしAPI経由の場合はそういった意思疎通は困難と言えます。24時間365日、何の問題もなく提供され続けるシステムは存在しないと考えないといけません。 そのためエラーコードが返ってきたり、HTTPレスポンスがエラーになった時を考慮したコーディングになっているべきです。また、それに合わせたテストコードも書いておく必要があります。 ただし最近ではラップトップやスマートフォン、タブレットの普及によって一時的にオフラインの状態も少なくありません。そうしたオフライン時の動作と同じようにしておくのが良いのではないでしょうか。 セキュリティ！セキュリティ！セキュリティ！ データの取得はもちろん、更新や削除がある処理についてはセキュリティを十分に評価しなければなりません。不正な値を入れた時の処理、トークンが漏えいした場合の処理（サービスによってはトークンの更新ができないものもあります）、パスワードの取り扱いなど外部からでも確認できる項目があります。 クラウドサービスである以上、サーバ内部などはブラックボックスであることを許容しなければなりません。そのため、API提供元が信頼できる企業であるかどうかも大事な指針になります。 継続的にメンテナンス、機能追加されているか 企業が信頼できたとしても作られたAPIがそのまま放置されているのでは事業継続性が疑われます。お知らせがきちんと更新されているか、機能追加されているかといったチェックをしましょう。 更新されていないAPIはその内提供が終了してしまったり、問題があった時の対応も良くない可能性があります。 ドキュメントが整備されているか ドキュメントはAPIを使う際の要です。ただ文書量があれば良いというわけではありません。分かりやすく、使いやすいドキュメントであるかいなかで、サービス提供元が利用者視点を持っているかどうかが分かります。 またドキュメントの整備も適切に行われていなければなりません。使えないAPIがそのままドキュメントに載っていたり、実際の動作と異なるといった場合は注意が必要です。 サポート体制 APIとドキュメントがあれば後は勝手にシステムが出来上がるわけではありません。実際に使っていく上で多くの問題、疑問が出るのが当たり前です。そんな時のサポート体制がどうなっているかは要確認です。 また技術サポート的な意味合いと、システムがエラーになった時のサポートは異なります。システムエラーについては24時間365日の体制が望まれるでしょう。技術サポートは概ね、平日の9〜5時といったパターンが多いように思います。 それ以外に利用者が集まったコミュニティ的なものがあると良いでしょう。エラーが出たときに、それが自分たちの使い方に問題があるか否か問題の切り分けに使えるはずです。また、利用者同士の方が目線が同じである分、解決が早いケースもあります。 APIを使ったアーキテクチャでは従来の構成と異なる問題が発生します。それらの特性を正しく認識することがシステムの疎結合であったり、開発の高速化につながります。 一見すると何でもできそうに見えるAPIですが、できないこともまた多いです。またベンダーの選定などもこれまでと異なる視点でみる必要があるでしょう。今回あげたような項目に注意して開発に取り組んでください。

システム開発時にAPIを利用するというのはよくあることですが、運用時においても役立つAPIはたくさんあります。今回はまずカテゴリについて紹介します。APIを活用することで運用負荷を軽減しましょう。 バージョン管理 最近のプロジェクトではGitが一番よく使われているかと思います。その中でも最も有名なGitHubは多数のAPIを有しており、コードの取得や更新、課題の登録や更新もAPI経由で操作が可能です。 後述するCIではエラーがあった時にGitHub上に課題を自動作成するものもあります。コードはシステムの要になりますので、GitHubのAPIを通じてシステムが連携していることが多いようです。 CI（継続的インテグレーション） 開発、テストそしてデプロイの流れを自動化する上で欠かせないのがCIです。有名なものとしてオープンソースのJenkinsがあります。また、CircleCIなどクラウドでCIを提供するサービスも数多くあります。 CIは基本的にシステム連携前提で作られていますので、APIから操作するのが基本となっています。結果はWeb上で閲覧できる他、後述するChatOpsとしてメッセージを飛ばしたり、GitHubの課題を作成したりします。 ログ管理 システムのログは日に日に増えていきます。それらをただ単に蓄積していてもストレージのムダにしかなりません。そこでログ管理系サービスが使われます。API経由でデータを登録するものもありますが、Fluentdを使ってデータを飛ばすものが多いようです。 ログ管理の場合、データの登録はAPI経由で行いつつ、ダッシュボード上でビジュアル化されます。各フレームワーク向けにプラグインやSDKを提供し、APIを直接利用するものは多くないようです。 監視 サーバやサービスの監視系の目的は主に生死管理になるでしょう。クラウドなどを使ってサーバをダイナミックに増減させている場合、監視対象もまたダイナミックに変化します。そこでAPIが利用できます。 監視系はその状態を通知するだけです。前述のCIと同様、ChatOpsとしてメッセージを飛ばすものが増えています。また、メールやSMS、自動音声による電話をかけるというものもあります。 IaaS/PaaS操作 昨今のクラウドサーバはAPI操作できるものが殆どになってきました。サーバの立ち上げ、アプリケーションのデプロイそしてサーバのシャットダウンまですべてAPI経由で操作します。管理画面もありますが、自動化を進める上ではAPIが便利でしょう。 ネットワーク操作 ネットワークというと有線、無線に限らず普遍的なものに思われますが、最近では速度をAPI経由で操作できるようになっています。最大速度は決まっていますが、速度を低速にすることで料金を下げたり、ネットワークの利用自体を止めることもできます。 業務時間だけネットワークを利用できるようにしたり、サービスの利用可否を自動的に制御する際に使われています。 情報共有 かつてはプロジェクト管理やグループウェアで行われた情報共有も、最近ではChatOpsというキーワードが聞かれるようになってきました。ChatOpsでは情報をチャットの中に一元集約し、システム開発関係者が見るべき場所を絞り込んでくれます。 これまで述べてきたような監視であったり、IaaS/PaaS操作においてもメッセージをチャット上に投げるものが増えています。システム管理者はチャットさえチェックしていればメッセージにいち早く気付けるようになります。 有名なところではSlack、Hip Chatなどがあげられます。日本発で知られているChatWorkのAPIはプレビュー版（限定公開）であり、今後のオープン化、広まりが期待されます。 運用時におけるAPI活用は主にアウトソースが目的になります。手作業でやることもできますが、工数がかかったり管理が煩雑化するので自動化によるミスやコスト低減を狙えます。 自動化したことで減った工数をさらに開発へ移動し、さらなる付加価値を生み出してはいかがでしょうか。

ここ数年で盛り上がっているのがIoT（Internet Of Things）です。その領域においてAPIがどのように使われているか紹介します。 デバイスからネットワークへのアクセス 一般的に通信モジュールは値段が高いのですが、重機器や自動販売機のような価格が高いものにとっては通信モジュールの値段は問題になりませんので、そうしたデバイスからサーバにデータをアップロードする際にはAPIを使って行います。この場合、デバイスのID、ステータスをアップロードするのが一般的です。 デバイスが大量であったり、スマートフォン前提のシステム構成の場合、ゲートウェイになるデバイスへの通信にはWiFi/Bluetoothなどを使います。この場合はAPIを使っておらず、データを集積したゲートウェイからサーバへのデータアップロードに対してAPIを使います。 データの特性について Webブラウザやサーバ間通信に使われていたAPIに比べて、IoTデバイスからのアクセスはよりデータ量が小さく、通信回数が多いという特性があります。数百から数万単位のデバイスを設置した場合、サーバへ定期的にアクセスするようにしていると単位時間（例えば1時間）ごとに瞬間的にアクセスが増えることになります。これはネットワークの遅延につながったり、サーバ負荷の問題になります。 そのためデバイスごとにデータをアップロードするタイミングを分けるのが一般的です。また、データのアップロードタイミングについても考慮が必要で、あまり頻繁にするとその分データ量が増えてしまいストレージを逼迫するようなことにつながります。 相互通信について IoTで度々求められるのが相互通信です。その場合はMQTTやWebSocketといったプロトコルが採用するのが良いでしょう。ただし相互通信を可能にすると消費電力量が増えますので、常時電源につながれているのが前提になります。 ネットワークに3Gなどを使っている場合、相互通信が100%保証される訳ではないことにも注意が必要です。通信が切れた場合のフローについても検討しておく必要があるでしょう。 認証技術について Webの世界ではSSLによる暗号化が当たり前になっていますが、ことIoTにおいてはデバイスが小型、超低消費電力が求められることもあってSSL/TLSのような計算処理をするのに向いていないことがあります。そのため、意図的にセキュアでない通信になっていることがあります。 そうした場合、ゲートウェイからサーバ間は暗号化して通信するようにしたり、SORACOMのように閉域網を使って安全にデータをアップロードする仕組みを利用するのが良いでしょう。 また、個々のIoTデバイスに対してOAuth2を使って認証といった操作は困難ですので、個々のデバイスをトークンベースで管理するのが一般的です。もちろん、これはIoTデバイスが消費電力を考慮せずに使えたり、CPUなども十分高速なものが使える環境では状況が異なります。 APIはインターネット技術の一つとしてあって当たり前なもの、融け込んだ技術と言えます。IoTにおいてもそれは変わらないでしょう。ただし、人が介さないケースもあり、その結果としてアクセス方法であったり、通信方式が特有なものとなっています。 スマートフォンアプリなどとはまた異なるAPIが求められる点を注意してください。

FinTechではその多くの金融機関が個別に契約してパートナー向けにAPIを公開しています。利用者としても個別に開発するよりも契約したパートナーが取りまとめてくれる方が利用しやすいでしょう。 今回はそのとりまとめ役になるであろう、会計/家計簿サービスのAPIをまとめてみました。これらのサービスを知っておけば、家計簿や資産管理がテクニカルなものになっていくことでしょう。 プライベートクラウド会計ソフトRUCARO 日本一安全なプライベートクラウド会計ソフトウェアを目指しているオープンソースの会計ソフトウェアです。自分でサーバを立てますので、金融機関の情報を外部サーバに預ける必要がないのが利点です。 APIはJSON形式で送受信します。統制モジュールと会計モジュールについて公開されており、今後も増えていくとのことです。 開発者向け(API) プライベートクラウド会計ソフトRUCARO 日本最大級！無料の家計簿アプリ・レシート家計簿「Zaim」 レシートを撮影すれば入力が自動的に行われたり、銀行やカードの情報を読み取って支出、収入を自動入力してくれます。約1,500の金融機関に対応してデータの自動取り込みができるとのことです。 APIではZaimへお金の項目を登録したり、Zaimに登録されている項目一覧を取得することができます。 Zaim Developers Center Kakeibon(旧OCN家計簿) ～無料で使える自動ネット家計簿～ Kakeibonは元々Webブラウザ向けでしたが、スマートフォンアプリもリリースされました。なお、執筆時点（2016年1月現在）はAPIの公開はされていません。今後、API公開も予定されているとのことです。 家計簿アプリ・家計簿ソフト「マネーフォワード」 マネーフォワードは銀行やクレジットカードと連携し、1,800以上の金融機関からデータを自動的に取り込みます。自動的に食費や光熱費などに分類してくれる機能もあります。 APIを使って入出金履歴の取得、資産の取得、金融機関の管理、各種マスタの情報参照ができます。 moneyforward/api-doc: moneyforward api documents 会計ソフト freee (フリー) | 無料から使えるクラウド会計ソフト freeeは個人ではなく法人（個人事業主含む）を対象とした会計システムを提供しています。freeeのAPIでは勘定科目、取引、品目、仕訳帳、取引先、部門、税区分などfreeeで扱われる各種データを操作できるようになっています。 freee APIドキュメント 個人としては家計簿、企業であれば会計サービスがターゲットになるでしょう。これらのサービスを使うことで、多くの金融機関、クレジットカード会社からの情報を集約し、分析や運用がもっと自動化していけるようになることでしょう。

APIの作り出すエコシステムは単にAPIを使う側、提供する側に限られていると思っていませんか。実際には周辺サービスが拡充していきます。今回はそんな周辺サービスの例を紹介します。そこから自社の新しいビジネスが思いつくかも知れません。 API解析 すでにAPIを提供している場合、その利用動向を知ることでさらに強化すべき領域であったり、逆に提供を停止すべき機能が見えてきます。Webサイトであればアクセス解析に相当するものであり、APIの場合はプロキシを立てて解析する場合やパケットを分析するものがあります。 API Analytics | API Reporting | MuleSoft APIゲートウェイ APIゲートウェイはごく簡単にAPIを提供開始できるようにするためのシステムです。認証機能を提供したり、CSVデータや既存Webサイトを使ってAPIが提供できるようになります。APIゲートウェイによって既存システムへのアクセスを限定することができるので、セキュリティ的にも安心できます。 システムによってはAPIへのアクセスを制御することによって課金できるようにしたり、解析機能を提供するものもあります。 自社データなどを使わない、AWS LambdaのようにコードをアップロードすることでAPIを作成できるサービスもあります。 Amazon API Gateway （API を容易に作成・管理） | AWS Oracle API Gateway StrongLoop | API Gateway API Management | Predictive Analytics | Apigee API集約 APIはそれぞれエンドポイントが異なるのが難点です。そうした問題を解決してくれるのがAPI集約サービスです。APIゲートウェイと似ていますが、外部のAPIをラッピングして使うのがポイントです。 一般的にはキャッシュするような仕組みはなく、アクセス先を統一できるのが利点となります。APIを切り替えたり、買収などによってエンドポイントが変更されてしまった場合の対応が容易になるでしょう。 CloudRail - The Universal API - One API for Everything ステータス管理 APIへのアクセスを監視し、安全性を確認できるサービスです。こうしたステータス管理はAPIのサービスから隔絶されている必要がありますので外部サービスを使った方が効率的です。 単純に指定したURLへのアクセスを行うもの、認証やデータの追加などさらに細かな条件が指定できるものなどがあります。エラーがあった際の通知先もメールであったりチャットサービスへの送信など多彩です。 StatusPage.io - Hosted Status Pages for Your Company StatusHub - Bulletproof, hosted status pages for your web application or service テスト APIは一般的にHTTP/HTTPSを使いますので外部からの負荷テストに向いています。ステータス管理と同じですが、本番環境に対して行う以外にも開発環境への負荷テストという需要があります。 さらにJSON Schemaを使った自動テストであったり、CIツールと連携した受け入れテストの自動化にも使われます。APIの場合、外部サービスを使ったブラックボックステストの方が向いているでしょう。 Ping-API - Automated API Testing API Monitoring and Testing · Runscope Cloud Load Testing Tools for APIs and Websites · LoadFocus.com ドキュメント管理 APIは開発者向けのサービスであり、多くの場合画面がありません。そのため必要になるのがAPIドキュメントです。専用サービスではJSON SchemaをHTML化したり、SwaggerのようにWeb上でテスト実行できるものもあります。 開発ドキュメントを自社でホスティングしても良いのですが、Webサーバの用意やメンテナンスが面倒である場合はGitHubページを使ったり、Amazon S3のWebホスティング機能を使うケースも数多くあります。 Apigee API Studio Apiary — Home Q&Aコミュニティ いくら正確なドキュメントを用意したとしても開発者が何の問題もなく開発できるわけはありません。必ず質問が出てくるでしょう。そうした時に使えるのがQ&Aコミュニティです。自社で構築する場合は問題ありませんが、外部サービスを使う際にはコードが綺麗に貼り付けられて、開発者が数多く集まっているサービスを選びましょう。 Stack Overflow teratail【テラテイル】｜思考するエンジニアのためのQAプラットフォーム いかがでしょうか。APIを巡るエコシステムには多くの分野があります。自社でAPI公開するデータがなかったとしても、技術力を武器に参入することはできるでしょう。APIをビジネスで利用するのが当たり前になっている現在、ぜひ新しいビジネスを発見してください。

3月23日、リクルート社のメディアテクノロジーラボにて通信APIをテーマとしたアイディアソンを開催 しました。実際に作るわけではないので、奇抜で飛び抜けたアイディアが数多く生まれています。当日の様子は Mashup Ideathon〜通信APIを使って新たなサービスを考えよう〜NTTコムAPI・Twilio　#MA12 (3ページ目) - Togetterまとめ にもまとまっています。 最初はインプットタイム まずはじめにインプットタイムとして今回参加した企業によるAPI紹介が行われました。NTTコミュニケーションズからは通信帯域、経路を操作するAPIを紹介しました。 Twilio社は音声通話、SMSのAPIを。 REDKNEE社は課金系APIの紹介となりました。 アイディアソン開始 インプットタイムが終わったら、いよいよアイディアソンの開始です。まずチームごとに軸として利用するAPIがランダムに割り当てられました。 そして、そのAPIから連想されるキーワードをリストアップしていきます。 次に組み合わせるキーワードとして、週末に見たもの、触れたものをリストアップしていきます。 そしてAPIと週末のキーワードをそれぞれ2つずつピックアップして、計4つのキーワードを元にサービスを考えていきます。 それぞれAPI提供企業の担当者がメンターとして加わり、約1時間ほどアイディア創出が行われました。 発表 アイディアソンが終了したら、各チームの発表が行われました。以下はその抜粋です。 募帯域 by バンドエイド 帯域をシェアできるサービス。災害地域でも安定したネットワークが使える。地方にいるおじいちゃん、おばあちゃんに高画質4Kでライブ中継で卒業式の映像を流すような使い方も。帯域で欲しい商品を買える。スマートグラスで帯域を見えるようにして、帯域を持っている人がもてる世の中になり、合コンで使うことだってできるようになる。 三越の魔法陣 by MITSUKOSHI 三越に来ないと受けられないサービスを提供する。来店者限定でプレミアム写真を提供する。来店してチェックイン。カタログを見たり、洋品店で試着をする。そうすると専属カメラマンに写真撮影してもらえる。購入したら三越のクラウドに写真をアップロードし、その際にNTTコミュニケーションズのAPIで通信帯域を引き上げる。写真屋さんで高画質な写真をダウンロードし、実際の写真にできる。 夢を見れるメガネ by 4人の小人 専用デバイスのメガネをかけているとキャラクターが近づいてくるのが分かる。みんなでいった時に、一度解散して集合するのが簡単になる。近くになると音楽が流れる。混雑状況も見える。楽しんでいるかどうか（汗をかいているかとか）も可視化される。自分が3時間後に疲れているかどうか分かるので、アトラクションではなく空いているレストランに行こうと考えられる。天気も分かる。隠れミッキーがメガネを通して光ったりするので、混雑が分散できる。隠れキャラクターを設定でき、自分たちの夢見る世界を自分たちでカスタマイズできる。 のぞき見したい by マネタイズ 真似タイズ。セレブがInstagramで格好良い写真をアップロードしている。でも日常は分からないので、それをわかるようにする。購入履歴が取れるAPI、位置情報APIを組み合わせる。届くまで何が来るか分からないが、有名な人が買っているものを購入できる。購買する人がセレブを選択すると、金額が出る。買うと決めたらブラックボックスのまま、商品が届く。セレブの生の日常が分かるサービス。 夕方ラッキー by 夕方ラッキー インドからパキスタンへ行くと同じルピーなのに使えない。現地のお金がなくても商品が買えたりする。REDKNEEの購入履歴で与信が取れる。服や通貨を写真でアップロードする。与信がとれるとYou got a luckyとメッセージが来る。 世界花粉症天下一武道会 by テレふぉんえっち 花粉症はネガティブなイメージ。でもそれも個性であり、個性を楽しもう。花粉症はネガティブなイメージだけど、花粉症を楽しめるようなサービス。世界花粉症天下一武道会。そこには最強を諦めた人たちがいる。最強の花粉症を決めるサービス。一定時間内に一番辛い花粉症の人が勝ち。辛い環境に自分たちを置いて競う。富士樹海で大きく息を吸って、それを動画配信する。すする音、くしゃみの音で住民が判定する。治験に花粉症のデータを売ることで賞金や運営費が賄う。花粉症チャンピオンとしての内定電話をTwilioで。僕には花粉があると胸を張っていえるのはTwilioがあるから。 野良猫 by HearTiwilio ハートフルなサービスを作ろう。Twilioを使って遠距離のコミュニケーションをより近くできる。ドライブをバーチャル的に作成する。東京と九州にいる状態でバーチャルドライブを楽しめる。親孝行としてもあり。Twilioのビデオチャットを使って過去のドライブを懐かしく楽しむ。日時を決めてVRをつける。Twilioを使って会話を楽しむ。バーチャルドライブ中の会話をTwilioの機能で保存しておく。プロポーズの言葉が10年後とかにいきなり電話がかかってきて思い出される。 優秀アイディアを選出 今回は全員投票による優秀アイディアの選出を行いました。各チームとも接戦だったのですが、バンドエイドチームが見事優秀アイディアに選ばれました。 また、Twilio社からもてれふぉんえっちチームがTwilio賞が選ばれました。 今回はアイディアソンとあって、自由な発想をもとに様々なアイディアが飛び交っていました。こうした普段考えないような視点で、全く知らない人たちと一緒にサービスを考えてみる体験は普段の生活、仕事の中でも活かされるのではないでしょうか。 皆さん、ご参加ありがとうございます！