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賞が選ばれました。 今回はアイディアソンとあって、自由な発想をもとに様々なアイディアが飛び交っていました。こうした普段考えないような視点で、全く知らない人たちと一緒にサービスを考えてみる体験は普段の生活、仕事の中でも活かされるのではないでしょうか。 皆さん、ご参加ありがとうございます！

APIを利用したり、提供する中で良くあがってくる問題を紹介します。従来のシステム開発手法と異なるために、問題もまた特徴的です。それらは単に問題として終わらせるのではなく、APIらしい解決方法を考える必要があるでしょう。 トランザクション APIを提供していて最もよくある問題がトランザクションではないでしょうか。この解決法は幾つかあります。 トランザクションが不要な設計をする トランザクションIDを用いる 有効期限付きデータロック トランザクションが不要な設計は最もベストな選択と言えます。実際、システムを開発していて必ずしもトランザクションが必要という場面は多くありません。アイディア次第で解決できるのですが、RDBMSにおけるトランザクションはとても便利なのでつい頼ってしまっていないでしょうか。 また、逆にトランザクションが必要な場合にそれらの処理をひとまとめにしたAPIを提供するという方法があります。その場合はRDBMSのトランザクションが使えますので安心です。 トランザクションIDを使う方法はシステムの複雑化を招く傾向があります。トランザクションを自作するのに匹敵するかも知れません。データのロック、前のデータの保存、ロック解除、データを戻す処理などを自分で作るのはとても大変ですし、不具合があると大きな問題になる可能性があります。 そもそも商品の在庫引き当てなどの場合、行単位でのデータロックで対応できる可能性があるでしょう。その上で5分間などのロック有効期限を設けることで、その間に決済処理を行ったり、失敗した場合にはロックを解除するといった処理にするのが良いかと思います。 ネットワークコネクションが増える RESTfulなAPIではデータモデル一つに対して一つのURIが割り当てられます。そのため、3つのモデルを操作する場合には3つのネットワークコネクションが必要になります。これはスマートフォンアプリなどでは大きな問題になります。 解決策としては、 ネットワーク接続の非同期化 複数処理の同時実行 があります。ネットワーク接続の非同期化は最も簡単な方法で、プログラミング側で対応できます。ただしネットワークコネクション数は変わりませんし、サーバへの負荷が高まる傾向があります。 後者の複数処理の同時実行はバッチ処理化です。3つのモデルに対するリクエストをまとめて一回でリクエストできるようにします。これはプロキシサーバを設け、そのサーバがリクエストを3つに分割してAPIリクエストを行ってもらうことで解決できます。プロキシサーバでは返ってきたレスポンスを一つに結合して返す必要があります。なお、この方法はリクエストの結果を受け取って処理判定して別なリクエストを行う場合には使えません。 例えば顧客情報と取引履歴、サポート対応履歴などを取得して画面に表示する場合、これらの情報を一回のHTTPリクエストとレスポンスだけで受け取れるようになります。 相互通信 APIは一般的にサーバへのリクエストとレスポンスで成り立っています。そのためサーバ側からクライアントに対してリクエストを行うのには向いていません。解決策としては、 WebSocket/MQTTの利用 WebHooksの利用 があげられます。WebSocket/MQTTは相互通信のプロトコルですが、環境によってはバッテリーの消費などが大きくなるかも知れません。WebHooksはクライアントとサーバが常時繋がっている必要はありませんが、クライアント側がHTTPアクセスを受け入れている必要があります。 スマートフォンアプリの場合はプッシュ通知を使い、それを受け取ったタイミングでAPIを叩いてもらう仕組みが使えます。 通信断 APIの処理に時間がかかっていたり、ネットワーク環境が不安定な場合にネットワークが途絶えるリスクがあります。データの取得であれば再度取得すれば良いだけですが、データの登録や更新が伴う場合は大きなリスクになります。 この問題はサーバとクライアント間で処理IDを設けることで、お互いの処理IDを交わすことで通信断した時の処理が終わっているかどうかを確認することができます。そして、クライアント側では処理する内容を記録しておき、オンラインになった時に再開できる仕組みにしておく必要があるでしょう。 CORS Webアプリケーション向けにAPIを公開している場合、ドメインを越えたCORS問題が話題になります。無条件に解放してしまうと思いもしないサイトからアクセスが来る可能性があります。できれば適切に許可を出したいところです。 解決策としてはOAuth2を用いてアクセス元に対するパーミッションを適用することです。アプリケーションごとに公開ドメインを設定し、適切にフィルタリングできるようにしましょう。 APIを提供すると、通常のWebアプリケーションや業務システムではなかった問題に遭遇することがあります。APIらしい設計であったり、クライアント側とのデータ送受信方法を考える必要があるでしょう。

Webサイトやサービスに地図を表示させたいと思った時に便利なのが地図APIです。今回は、無料で利用できる（条件に依っては有料の場合あり）地図APIをまとめてみました。 Google Map API GoogleMapを表示できるAPIサービス。Googleの用意した豊富なMapAPIサービスを使用できる。マニュアルは一部英語だが、丁寧に解説されている。標準プランの場合、1日の表示回数が制限内であれば無料になる。プレミアムプラン（有料）の場合、年間契約でサポートなども付いている。 Yahoo Javascript Map API Yahoo！ロコと同じ地図が表示できる。マウスでドラッグできるJavascriptで動かせる地図のAPI。雨雲レーダー情報を重ねて表示できる機能あり。他にスタティックバージョン・スマホ用（iOS版、Android版)もあり。使用にはYahoo Japan IDとアプリケーションIDの取得が必要であるが、無料。使用方法についてweb上で丁寧に解説されているので、初めて地図APIを使う人にも向いているサービス。 いつもNAVI API ゼンリンデータコムの法人・商用向け地図APIサービス。「渋滞情報」「路線図検索」などゼンリンの豊富な検索サービスを使用できる。電話サポートや「開発者向け情報提供サイト」があり、ユーザーサポートが充実している。5000PV/月以内の場合は無料利用可能。 電子国土web 国土地理院が提供する地図APIサービス。利用目的により、無料で利用できる。地図を利用したサイトを開設した場合、報告が必要。 Open Street Map 自由に参加し、自由に編集し、自由に使用できる地図版Wikipediaと呼ばれるオープンソースの地図。APIも提供している。 Bing Maps: Choose Your Bing Maps API Microsoft社の提供するBing MapのAPIです。試用は90日間、年間12.5万トランザクションまで無料で利用できます。それ以上は有償ライセンスを購入する必要があります。 スマートフォンが広まるのにあわせて位置情報データも増大しています。取得した位置情報を地図上にマッピングしたり、ルート計算、距離測定などに利用ができます。地図は現実世界にも近い存在なので、利用できる場面は多いでしょう。

企業としてAPIを提供し、かつそれをビジネスで活用していこうという動きが出始めています。今はまだスタートアップをはじめとする小規模な企業か、クラウドベンダーなどのIT系企業で取り入れられている動きですが、徐々にそれ以外の企業においても採用されつつあります。 今回はそんなAPIをビジネスで使うことによる新しいチャンスや事業拡大を目指す方法について紹介します。 多面的展開を前提に考える これまでのWebサービスのように、PCのブラウザ向けだけに情報を提供するのであればAPIを提供する意味がありません。昨今、デバイスの種類は急激に増加しており、提供形態もまた増えています。それらを認識し、多面的展開を目指すべきです。 分かりやすいところではスマートフォンやタブレットなどのスマートデバイス、サーバサイド連携、IoTデバイス、Webブラウザの機能拡張などが考えられます。情報の発信先を限定しない観点が必要です。 見通しの良い、保守しやすいシステムへ システムは最初に開発した時には分かりやすくとも、徐々に手を入れていく中で分かりづらく、負債へと変わっていきます。これはシステムが表示部分まで担っている場合に起こりがちです。 API化するということは、システムの表示部分を切り離すということです。すべての表示処理（アプリの画面やWebブラウザなど）はそれぞれのデバイスに任せることができます。また、iOSとAndroidなどで発生する特有の処理はアプリ側で担うことになりますのでロジックもすっきりとさせることができます。 保守しやすいシステムはシステムの運用コストを下げ、新しいビジネスの変化にも追従しやすくなるでしょう。スマートフォンに変わる新しい仕組みが登場したとしてもすぐに対応できるはずです。 システム連携の工数削減 企業間連携や提携を通じて情報の送受信が発生する場合、APIがあるとないとで大幅に工数が変わってきます。特に自分たちだけがない場合、仕様を相手に合わせて設計することになるでしょう。これは相手の企業特有のビジネスフローを含んだものになり、他企業との提携には使えないものになるかも知れません。 APIがあれば、そうした工数が一気に削減できます。もしAPIがない状態で企業連携の話が進んだ場合、そこからお互いに話し合って仕様を検討して実装して結合テストをして…といったことをしているとあっという間に1年経ってしまうはずです。それがAPIがあることで、数ヶ月もあれば完成することになります。 最近のビジネスにおいては手動ではなく自動化されることが前提となっているため、APIの有無によって完了までの時間やその後のスピード感がまったく変わってくるでしょう。 複数企業との提携が容易に APIは自社のビジネスフローを確立するものになります。全く足りない機能があれば追加開発する必要がありますが、そうでない場合はAPIを利用する側がロジックを組んだ上で利用します。つまりAPIが標準フローを担うのです。 標準フローができていれば、後は水平展開していくだけで企業提携が進められるようになります。 トレタ、 POSシステム5社と提携　 シームレスなデータ連携を実現する 「トレタPOSコネクト」を3月1日リリース はまさにその典型と言えます。 ビジネスにおけるAPI利用のイメージは、Webブラウザ以外への情報発信先の拡大、他企業との提携などの利用先拡大と言ったものになるかと思います。つまりAPIを単に作るだけでは意味がなく、APIを使って何をするかが大事ということです。そのためにはAPIありきではなく、ニーズありきで考えた上で、APIという自動化、システム化を担う技術をどう組み込んでいくかが重要になるでしょう。

APIを使った開発、運用でよくあるのが突如としてアクセスできなくなるという問題です。今回はその際に関係する技術と解決手段を紹介します。 自社ネットワークの問題 APIは問題がなくとも、自社側のネットワークに問題が発生していることがあります。LANカードの不具合、ネットワーク設定のミス、ルータ/ファイアウォールの不具合、ケーブルの破損などが考えられます。 外部ネットワークの定期的なアクセスチェックはもちろんですが、内部ネットワークについてもきちんと確認するのが良いでしょう。こういった不具合の問題として、不具合を通知するメールも送信できなくなることです。不具合発生時の通知はもちろん、通常運用時にも定期的な通知を行うのも手です。また、別ネットワークからの生存確認を行うシステムの導入もお勧めです。 DNSエラー ネットワーク周りでよくあるのがDNSの問題です。自社運用の場合はもちろん、ドメイン設定のミスなどでアクセスできなくなることがあります。この場合の問題としては、DNSには設定のキャッシュがあるので問題発生の確認が遅れてしまうことです。 APIからの応答がない APIへリクエストを送ってもレスポンスがない場合、サーバが完全に停止しているか、処理が重たいために遅延している可能性があります。利用する際に適切なタイムアウトを設定しておかないとリクエストが他のキューと合わさって多重化したり、ハングしてしまう可能性があります。 APIのレスポンスに対する品質を予め確認しておいたり、計測しておくことでレスポンスの悪化を予め知ることができます。また、5秒程度でタイムアウトするようにしたり、前のキューが終わっていなかったらアクセスしないように制御します。 40X系のエラーが返ってくる 存在するはずのエンドポイントから404エラーが返ってくるとすれば、アプリケーションサーバが止まっている可能性やAPI自体が削除されてしまった可能性があります。401の場合は認証エラーが多いので、キーを再生成した可能性があります。 一般的に40X系のエラーレスポンスはシステム上の正しいエラーであることが多いので、コードの見直しを行うのが良いでしょう。 50X系のエラーが返ってくる 503はシステムエラーであったり、50X系のエラーはシステムの例外エラーであることが多いです。これは予期せぬエラーになりますのでAPIのテストが不十分であったり、データベースやストレージで問題が発生している可能性があります。API提供元への問い合わせが必要でしょう。 APIでのエラーはシステムの連鎖的不具合につながる可能性があるので、それぞれの問題の切り分けによって正しく判断し、素早い対応が求められます。ただし利用する側としてもエラーが発生することを予め見込んだ上で作り込んでおくのが大事でしょう。

レストランやアパレルなど、殆どの店舗で導入されているのがPOS（Point of Sales）システムです。そんな店舗ビジネスの基盤とも言えるPOSシステムにおいてもAPI活用が広がっています。 今回はそんなPOSシステムで使えるAPIをまとめました。 Orange API タブレットを使ったPOSシステム、EC-Orange POSが提供しているAPIです。売り上げ、商品、在庫、顧客情報を連携できるようになっています。既存の基幹システムとの連携などが想定されています。 スマレジ iPhone/iPadを用いたPOSレジシステム、スマレジで公開されているAPIです。売り上げ、在庫、商品データなどが取得できます。オプションにより会員情報も取得できます。 また、WebHooksにより商品、会員、在庫情報などが更新されたタイミングでHTTPリクエストを飛ばすこともできます。 ユビレジ iPadを使ったレジシステム、ユビレジの公開しているAPIです。売り上げデータのダウンロード、メニュー編集、顧客データの編集などユジレジでできることのほぼすべてがAPI経由で可能です。 ユビレジ for Salesforceという仕組みを使うことでユビレジの売り上げデータをSalesforceへインポートできる仕組みもあります。 Omnivore.io レストラン用のPOSシステムを提供しているOmnivoreのAPIです。商品、オーダー、メニュー、支払いなどすべての機能がAPIから操作できるようになっています。 poscube iPadを使った飲食店専用のPOSシステムを提供しています。注文データや注文履歴、商品データ、テーブル状況と言ったデータをAPI経由で利用できます。空席状況の確認などにも利用できます。 Revel Systems POS iPadを使ったPOSシステムを提供しています。APIを介して全データへのアクセスが可能とのことです。 Point of Sale - Developer API | Power your App with eThor 注文や支払いへのアクセスができます。Facebookからの注文にも対応しているようです。 Shopify POS App SDK Shopifyは元々ECショップを作成できるサービスでしたが、POSシステムも提供するようになっています。POSアプリを提供する訳ではなく、SDKを提供する方法をとっているようで、自分でPOSシステムを組むという形になるようです。 最近ではiPadやタブレットを使ったPOSアプリがたくさん出てきています。そうしたアプリではAPIを使うのが基本になるので、パートナー向けに公開することでAPI公開が実現できます。 多くは基幹システムとの連携に用いられるようで、まさにビジネス向けのAPIと言えそうです。

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と逆方向の利用が考えられます。ぜひ使いこなして業務を改善、スピードアップしてください。