今なお多くの企業でメインフレームと呼ばれるシステムであったり、そこまで古くはなくとも20年近く動作している業務システムが存在します。そして多くの企業でリプレース案件が動いていたりします。 しかしシステムの全面的なリプレースにおいてうまくいったというケースは少ないのが現状です。何年も動かし続けたシステムはアンドキュメントな仕様が多数存在し、ワークフローの洗い出しとそれに合わせたシステム構築によって大規模な工数が必要になってしまいます。 先日富士通社よりWSMGR for Webという製品がリリースされました（ 富士通メインフレームをWeb API化できる端末接続ソフト - 製品＆サービス：ITpro Active より）。これはゲートウェイソフトウェアで、REST APIを経由してメインフレームを操作できるようにするソフトウェアです。これはシステムのリプレースではありませんが、既存資産を活用して現在のビジネスに合わせて拡張していく一助になると考えられます。 APIの利点として、API提供元のシステムはブラックボックスにできる点が挙げられます。つまりRuby on RailsやDjangoといった最新のフレームワークで作られているか、メインフレームであるかは利用者からはうかがい知れないのです。RESTfulの原則に沿って提供さえされていれば、開発者は安心して利用できるでしょう。 さらにREST APIの多くがデータの公開に偏りがちですが、サービスの公開としての役割も担いやすくなります。元々メインフレームで利用されている機能（在庫引き当てや受発注など）をREST APIから呼び出せれば、実際のワークフローは気にせずにUIやそれ以外のワークフローに集中して開発できるようになります。機能の再実装コストを抑えられるでしょう。 メインフレームを置き換える目的は様々ですが、その一つに新しいシステム（グループウェアやECシステム）との連携が挙げられるかと思います。耐久年数や保守の問題などの場合は別ですが、システム連携であればWSMGR for Webのようにメインフレームをブラックボックス化してしまうのは一つの解決策であると言えます。 これは何もメインフレームだけに限りません。過去に開発した業務システムがオープン系でWebシステムに対応していない、古いフレームワークで開発されていて手を付けられない、運用フェーズに入っており、安定性が重要であるといったケースはよくあります。そうしたシステムにおいても別なシステムでラッピングしてしまうことでREST API化してしまう手が考えられます。何よりリプレースに比べると安価で、安全な移行と言えます。 一旦API化してしまえば、新しい施策も打ちやすくなるでしょう。業務システムの操作UIもスマートフォンやタブレットに対応したり、自動化も進めやすくなります。もちろんすでに稼働しているWebシステムとの連携も容易になります。 従来システム連携ではHTTPを使わないAPI連携であったり、CSVファイルを介した連携が行われてきました。基幹システムをREST API化できれば、より速いビジネススピードで業務改善や新しいビジネス創出が見込めるはずです。

企業間におけるAPI活用が進んできています。クラウドベンダーの提供するAPIに限らず、これまでAPIを提供してこなかったような企業でもAPIを使ってビジネス拡大を図るケースが増えています。 そこで今回は企業がAPIを公開することで得られるメリットについて紹介します。 自社技術をブラックボックスにしたまま利用させられる どのような企業であっても自社独自の技術を無闇に公開したいとは思わないはずです。特に特許が絡んでいたり、自社のコア技術であれば尚更でしょう。しかし技術を持っていることや、それを新しい収益源として活かしていきたいとは思うはずです。そんな時に使えるのがAPI化です。 APIは機能を提供するのであって、実際のロジックは非公開になります。そのため独自技術部分についてはブラックボックスにしたまま外部の開発者や企業に利用してもらうことが可能です。 ビジネス連携を生むきっかけに APIが公開されていれば企業間での提携がとても早くなります。もし同じようなサービスがあった場合、APIを公開しているサービスとしていないサービスがあったならば間違いなく前者が提携先として選ばれやすくなります。 提携が決まってからAPIを開発するのでは一手遅れていると言わざるを得ません。また、その場合は提携先の仕様に合わせて開発することになってAPIとしての汎用性が失われることになるでしょう。 リーチできない新しい層へのアプローチ APIを公開することで、それを利用した企業が独自の顧客層に対してアプローチしやすくなります。これは特に大手の企業がAPIを公開した場合に有効です。大手ならではの機能（AIや機械学習など）を使って中小企業が独自のサービスを構築したり、中小企業が持つ独自技術と組み合わせて新しいサービスが生まれます。 この方法は異なる業種へのアプローチや免許が必要な業界へのアプローチに有効です。利用する中小企業にとっても独自の武器が手に入るのは大きなメリットになると言えるでしょう。 ワークフローを自動化させられる 例えばこれまではいちいち電話で状況を確認しなければなかったことがAPIを使うことで自動化できるようになります。これは人材コストの低減、最適化に大きなメリットがあります。APIを作ることで省力化に貢献できるようになります。 こうしたAPIはおもにバックオフィス系で使われます。サービス提供側としてはよく使ってもらっている機能ほど自動化する価値があると言えます。 他社との差別化に 同じ業界のサービスが存在する時にAPIを公開しているか否かはサービス採択時の一助になります。この時には特にRESTやJSON、OAuth2などの標準的技術に則って実装されている必要があります。また、特に利用が多いと想定されている言語に対してSDKやライブラリを提供するのも良いでしょう。 逆にすでに同じ業界で多くの企業がAPIを提供している場合、提供しないことがビジネスリスクにすらなります。この時には最大手のAPIフォーマットを真似て実装するのが戦略になるでしょう。そうすることで開発者は再開発の手間を極力減らした上で自社サービスへの乗り換えが実現できるようになります。 APIエコノミー形成の一歩に APIを利用した経済圏が作れるならば自社APIを軸としたAPIエコノミーが形成できるかも知れません。この時大事なのは自社APIを使って新しいビジネスを作り出すパートナーの存在でしょう。ただ利用する企業が増えるだけでは広がりに限界があるはずです。 そうした状況を作り出すためにはAPIにもビジネス活用の可能性が見いだせるような特徴が必要になります。特に情報の取得系だけでなく更新や削除系も実装されている必要があります。さらにビジネス利用を可能にするような規約や条件の策定も大事でしょう。 企業がビジネスの拡大を狙う中で、APIは必須の存在となってきています。また、APIを利用する側にとっても自社のナレッジとAPIを合わせることで新しい価値を顧客に提供できるようになります。単にコスト削減や自動化だけでなく、自社ビジネスを拡大するという視点でAPIを見ると新しい発見があることでしょう。

アプリやWebサービスをグローバル展開する中で翻訳は欠かせません。単語単位で翻訳できるもの、HTMLをまるごと翻訳できるものなど様々に存在します。今回はそんな翻訳APIをまとめて紹介します。 Microsoft Translator - Built for enterprise Microsoftの提供する翻訳サービスで、個人用と業務用に分かれて提供されています。業務用はCognitive Servicesの一サービスとして提供されています。 Microsoft Translator - Built for enterprise Google Translate API - 高速で動的なローカリゼーション  |  Google Cloud Platform 90を越える言語に対応した翻訳エンジンです。HTMLドキュメントを送るだけで翻訳結果を返してくれる機能があります。 Google Translate API - 高速で動的なローカリゼーション  |  Google Cloud Platform WorldLingo翻訳API開発ツール 60カ国語以上に対応した翻訳APIです。XMLで結果が返却されるようです。公式サイトの翻訳結果（下記リンク)が若干品質に難が感じられてしまうのが残念です。 WorldLingo翻訳API開発ツール 翻訳API(英語,中国語,韓国語,タイ語,欧州語等)｜クロスランゲージ 日本語、英語、中国語、韓国語、フランス語、ドイツ語、イタリア語、スペイン語、ポルトガル語、ロシア語、タイ語、ベトナム語、インドネシア語などに対応しています。APIはSOAPとRESTで提供されています。 翻訳API(英語,中国語,韓国語,タイ語,欧州語等)｜クロスランゲージ Gengo Gengoは自動翻訳ではなく人力翻訳になります。結果は即時には返ってこず、数日で結果が得られます。API経由で翻訳を依頼すると、若干値引きされます。サンドボックスがあるのもポイントです。 デベロッパー - Gengo Language Translator - IBM Bluemix ニュース、特許、会話などのカテゴリから翻訳対象の言語を選択できます。毎月25万文字は無料で利用できます。言語の識別については数十カ国語から自動選択されます。 Language Translator - IBM Bluemix システム連携｜ビジネスをスマートにするオンライン自動翻訳ソフト ヤラクゼン 自動翻訳と人力のクラウド翻訳両方があります。APIでそのどちらを使うかを指定できます。サイトや情報の特性に応じて切り替えられるようになっています。 システム連携｜ビジネスをスマートにするオンライン自動翻訳ソフト ヤラクゼン スピード翻訳 by GMO : 翻訳 API 特にECサイトにフォーカスしているようです。APIからの場合、30%安く依頼できるようになっています。依頼から納品までをAPIのみで行うので人力ながらも自動化が可能です。 スピード翻訳 by GMO : 翻訳 API 業界特化型AI翻訳プラットフォームサービス そして弊社NTT Communicationsの事例紹介になります。 まだβ版提供となっていますが、業界特化型AI翻訳サービスの提供を開始しました。 利用する業界や用途に特有の語彙や言い回しをAIに学習させておくことで、汎用的な自動翻訳に比べて高い精度の翻訳機能を実現できる仕組みです。β版の提供に合わせ、NTT Comと共同でビジネスを検討するパートナー企業を募集しています。 パートナリングの先行事例として、株式会社QUICKが提供する個人投資家向け情報サイト「QUICK Money World」において、「AI翻訳PF」を利用してツイッター上の英語によるツイートを翻訳するサービスを提供中です。 海外ツイートななめ読み Google翻訳がAIによって一気にレベルアップしたという話は以前に出ましたが、それ以外の翻訳サービスについてもレベルが上がってきています。なお、Google翻訳の結果を商用利用することについては著作権や利用規約にその記述がないことなどから避けた方が良いと考えられます。 品質から言うと、人力の方がまだまだ精度が高いように感じます。利用目的によって使い分けるのが良いでしょう。

はじめに 私の所属している部署では、主に法人のお客様のシステム監視・運用を24H365Dの体制で実施しています。 運用部隊にとっては、日々の運用業務を高度かつシンプルにしていくことが永遠の課題です。常にチームの業務を振り返り、どこか効率化できることはないかと模索しています。 数ある業務の中で今回は「監視データの異常分析」に注目します。 ある程度大きなシステムを運用していると、キャパシティ管理や障害の予兆キャッチの観点から、「ある期間の監視情報を調査してトピックを抜き出す」という作業が定期的に必要になります。 基本は人が監視データとにらめっこしながら変化点がないか調査するのですが、対象も多く、かなりの手間を要する作業です。 これをもっと手軽に実行できないかと思い、軽い検証をやってみました。 検証内容 検証には監視ツールと分析ツールが必要です。今回の道具としては、これらを使います。 zabbix 多くのプロジェクトで使われている、定番の監視ツールです。NTTコム ソリューションズが日本でのプレミアムパートナーとなっています。過去にzabbixを利用した案件で、必死でトラブルシュートした結果が少なからず貢献しているそうで、個人的に思い出深いソフトウェアです。 今回はバージョン3.0を使います。 twitter-anomalydetection Twitter社が2年ほど前に公開したRのパッケージです。時系列と組み合わされた数値データから、異常値を検出します。 今回はpythonで Zabbixからデータ取得 データ加工 Rに渡して分析させる という一連の処理を記述してみたいと思います。 処理を書く まずはzabbixから監視情報を取得します。zabbixにはJSONRPC準拠のAPIが実装されており、 JSON形式のデータを含んだHTTPリクエストを投げることで監視データを取得することができます。 JSONを生で書き下すのは面倒なので、こちらのライブラリを利用しました。 py-zabbix pipで導入するときの名称は「py-zabbix」となります。pyzabbixとすると別のライブラリが入ります。 データ抽出のためのサンプルコードは下記のようになります。 import datetime import time from pyzabbix import ZabbixAPI import pandas as pd # Network, Account zabbix_server = 'http://zabbix-host/zabbix' zabbix_user = "*****" zabbix_password = "*****" # Local time timefrom = "YYYY-MM-DD hh:mm:ss" # time from timetill = "YYYY-MM-DD hh:mm:ss" # time till # Local time -> Unix time timefrom_unix = int(time.mktime(datetime.datetime.strptime(timefrom, "%Y-%m-%d %H:%M:%S").timetuple())) timetill_unix = int(time.mktime(datetime.datetime.strptime(timetill, "%Y-%m-%d %H:%M:%S").timetuple())) # Get token z = ZabbixAPI(zabbix_server, user=zabbix_user, password=zabbix_password) # Get resource trend on server trend = z.trend.get( itemids="xxxxx", sortfield="clock", sortorder="ASC", time_from=timefrom_unix, time_till=timetill_unix, output=["clock", "value_avg"] ) # Store the trend data in pandas dataframe trend_data = pd.DataFrame(trend) trend_data['clock'] = pd.to_datetime(trend_data['clock'], unit='s') # Unixtime -> Datetime trend_data['value_avg'] = trend_data['value_avg'].astype(int) # Print CSV data trend_csv = pd.DataFrame.to_csv(trend_data, columns=["clock", "value_avg"], index=True) print(trend_csv) 大まかには、認証してトークンを取得→セッション用のインスタンス生成→特定アイテムのデータ取得、という流れで処理を進めています。 取れるデータやその形式については、公式のマニュアルページに詳細があります。 18. API [Zabbix Documentation 3.0] コードの中に登場しているtrend(トレンド)というのは、zabbix側で1時間ごとの取得値を平均化してDBに格納しているデータです。 値のスパイクなどの異常検出という観点では history.get で生の取得値を参照したほうがよいと思いますが、zabbix側での生値の保存期間および、分析処理時間の都合(後述)でトレンド値を利用しています。 本来は R連携のライブラリ を使ってスクリプト単体で処理を完結したかったのですが、R側に時刻データを渡すときに型をうまく読ませることができず、仕方なく一度CSVに吐かせています。完全自動化するにあたってはもう少し調べなければならないです。 さて、一度CSVに吐かせたデータをRで分析します。試行錯誤する段階では RStudio を使いました。 結果 手元の監視データで実行した結果は下図のような感じです。図中で青い丸でプロットされている点が、変化点として検出されています。 この例では、月末にかけてCPU使用率が急増したタイミングをきれいに検出できています。 上図のように単純なスパイクなどであればうまく拾えるのですが、たとえば「今まで平坦だったグラフが突然右肩上がりになる」といった変化に対しては難しいようです(実務でよく泣かされるパターンなのですが)。 そういった事象については別のアルゴリズムを援用したほうがよいのかもしれません。 また、アルゴリズムに与えるパラメータによっては、予期する異常点が取れなかったり、余計な異常点が取れてしまったりします。 継続的に運用しようとすると、誰がどのように分析対象の特性を見てチューニングしていくかが問題になります。 処理時間も課題です。今回はAWSのt2.standard上で処理を走らせたのですが、データ数が1000個程度でも処理に5秒程度要しています。 中のアルゴリズムの計算量評価まではできていないのですが、たとえば数分間隔で取得しているデータに対して1ヶ月間の傾向分析をしようとするだけでもかなりの処理時間が予想されます。 前節で、生の取得値を使わずトレンド値を利用することにした理由の1つです。 終わりに 今回の例については、実用に持っていこうとするといくつかハードルがありそうです。 しかし、運用の現場における手作業はほかにも数多くあります。 公開されているツールを組み合わせるだけで、コスト・労力をあまりかけずにアイデアを試せる時代なので、 現場ならではの目線を強みにしつつ、色々なことにトライしながら業務をもっとシンプルにしていければと思っています。

目的 インフラエンジニアだってソフトウェアを作ってみたい！ ソフトウェア開発者の動きや考え方を知りたい！ 動機 職業を聞かれてエンジニアと答えれば、返ってくる反応は「アプリやホームページを作っているんですか？」 アプリやホームページは様々な人にとって身近なもの、動くと楽しそうで、ソフトウェア開発者のことが羨ましくなってくる…「私もこんなアプリ作った！」と言いたくて参加しました。 またソフトウェア開発者の動きや考え方、視点を知ることで、いつも扱っているサービスを違った見方で捉えたいと考えていました。 内容 ハッカソンスタート！ 参加したイベントは、「 はじめてのハッカソンVol.22 」というハッカソンです。 初心者向けと銘打っているハッカソンに参加したため、時間はトータル5時間と短め、テーマも自由です。 プログラマーの方とWebデザイナーの方とチームを組みました。 まず、いろいろ普段困っていることをブレインストーミングでどんどん出してテーマを決定。 ↑テーマを決めるためのワークシート。 決まったテーマは「デスクワーク中のつまみ食いをふせぐ」 テーマ達成に使うと決めたもの TensorFlow(画像解析) Python Google Web App(食べている様子を撮る) 機械学習のための画像(人が食べている写真) と、上の図のようにできるはずだったのですが…。 Pythonのバージョンが原因でTensorFlowをインストールできなかったり、インストールできてもエラーを出し続けたりで思うように動かず画像解析は断念…。 ただ、Google Web Appでリアルタイムで写真を撮り、Push通知も出せるようになるまではチームメンバーが設定を頑張ってくれました。 アイデアが形になって、目の前で実際に動くことに感動しました。 感想 ソフトウェア開発への憧れはどう変わったか 思ったように動かないと非常に辛い…。これはインフラ構築にも言えることですが…。きれいに動くアプリの裏にはたくさんのコードとの戦いががあると思うと少し羨ましさも減りました。でもGoogle Web AppやPush通知が動いたときは嬉しかったです。 自分の普段の業務とアプリ製作までの過程を比較して感じたこと 私の普段の業務は、課題もアプローチも決まっているサービスをお客様用にカスタマイズするもの、と私は捉えています。ディスカッションによって洗い出し1つに絞った課題を解決するアプローチを考えるという、いつもと違う経験をすることができました。 また、ソフトウェアの使用者を事細かに具体的に想定することにそれほど意味があるのかと思いましたが、課題に対するメンバーの認識を合わせやすく、チームの会話も盛り上がりました。いつもの業務では既にお客様は決まっているので、使用する人のパーソナリティからディスカッションするのは新鮮でした。 課題、その課題を抱えている人、アプローチ方法といったことを自分で定義することで、日頃、自身が気になっていること、視点、考え方が浮き出てきました。 自分の取り扱っているサービスにも、作られるまでに経緯があるのだということに気がつきました。これは既存のサービスの理解に役立つと思います。 近くて遠いソフトウェア畑の人達 ハッカソン後の懇親会で他の参加者の方とお話しました。インフラエンジニアとソフトウェア開発者はお互いがお互いのことをそれほど知らないということを改めて実感しました。お互い知らなくても開発やサービス提供には問題ないのでしょう。しかし、インフラエンジニアはソフトウェア開発のこと、ソフトウェア開発者はインフラのことを知って交流を活発にすることで、プラスになるものはないか考えるのは面白そうだと思いました。 今後 すぐに行動に移せそうなアイデアを出し、短期間で、アプリであれなんであれ、目に見える、ふれられるかたちにしようと思いました。そうすることで他人からもフィードバックを得られやすくなり、自分の振り返りも行いやすくなります。 ちょっとしたことでも困っていることはメモしておき、解決策をあげてみるというのは、ソフトウェア開発だけではなく、インフラでの仕事の進め方を考えることにも応用できると思うので試します。 また、既存サービスの機能検証をするときには、なぜその機能が必要だと思われて追加されたのかを、使用者を具体的に想定して考えると、有意義な検証ができるという当たり前のことを思い出したので、今後は意識して行います。 些細なことでも疑問に思い、自分ならどうしようかと考えて具体的な行動に移そうという当たり前のまとめになりました。ただ日々の業務の中で忘れてしまうので、今後も違う畑のイベントにも参加して都度思い出していこうと思います。

多くの企業では元々Webサービスやリアルビジネスを提供しており、その機能の一つとしてAPIを提供します。APIは開発者にとって便利な仕組みですが、提供開始したからといっていきなり利用が拡大する訳ではありません。きちんと啓蒙活動を行わなければならないでしょう。 そこで今回は特にビジネスにおけるAPIについて、どう利用を広めていくかを紹介します。 特定のクライアントとはじめる ビジネス用APIの利用者の多くはすでにリアルビジネスを提供している企業になるでしょう。最も多く利用している企業ほど、自動化やシステム化のニーズがあるはずです。まずそうした企業と個別にコンタクトを取り、APIの設計から入ってもらうべきです。 APIをサービス提供側だけの視点で組み立てると、実際のワークフローを行う上で必須の情報が見落とされる可能性があります。そうした実状とかけ離れたAPIは提供しても使ってもらえない可能性が高くなりますので、実際のニーズに合わせて作るのは大事です。 ただし、あまり細かな部分まで最適化してしまうとその顧客しか使えないAPIになってしまう可能性があります。今後広くあまねく提供していく上でも個別のワークフローにまで落とし込まないように注意しましょう。 APIや最新テクノロジーに関心のあるクライアントとはじめる さらにAPIなどに関心を持ってくれる開発力のあるクライアントとはじめるのが良いでしょう。いくら最大手であっても技術的関心の低い企業と進めるのはよくありません。最初の設計から一緒に行っていくのであれば特にそうです。 特に利用者側の開発が必要になりますので、自社に開発リソースを持った企業と行うのが良いでしょう。SIerに丸投げしてしまう企業ではスピード感あるAPI開発は難しいでしょう。 多数の事例 APIを使う側の立場に立って考えると、最初はなかなか利用法が分からないものです。その結果、単純にステータスを取得して表示するだけのものが多くなってしまいます。これではなかなか普及が進まないでしょう。 そのため実例としての利用事例を増やしていきましょう。企業においてはそうした事例を公開したがらないケースが多いので注意が必要です。最初の段階から公開事例を作ること、プロモーションや開発で協力することで承諾を得ていきましょう。 そうした現実に即したワークフローとAPI活用法が見えることで、他の利用者にもアイディアが沸きやすくなります。 同業種への展開 APIの利用事例が増えたとしても、他業種での実例というのはなかなか自社のことに結びつきづらいものです。そのため最初の事例では同じ業種ばかりではなく、幅広い業種で実践していかなければなりません。 逆に事例ができあがったら同じ業種のクライアントに提案しやすくなるでしょう。事例が経理や人事など、バックオフィス側の業種によらないものであれば、支社がある場合や多国籍企業といった打ち出し方で事例化するのが良いでしょう。 社内で啓蒙 クライアントに使ってもらう必要があるAPIである以上、クライアントと最も接触する機会がある営業職の人たちへの啓蒙は欠かせません。APIは技術的なものなので、なかなか理解してもらうのは難しいでしょう。その結果、特にクライアントに利用を提案することもなく放置されてしまいます。APIの利用が自分たちはもちろん、クライアントのビジネス拡大やコスト削減にどう役立つのかを説明しなければなりません。 ビジネスにおいてはいいものだから使ってもらえるという単純な式はなかなか組み上がらないものです。相互にメリットがあるのは当然として、さらに導入や開発を後押しする理由が必要でしょう。 ドキュメントを拡充させる ビジネスでのAPI利用においてドキュメントは絶対的に重要です。提供側が考える以上に提供する必要があるでしょう。それは単純なAPI仕様だけでなく、使い方やTipsのようなものも必要です。 実際に提供を開始すると様々な質問が寄せられるはずです。そうした声をドキュメントに反映していくことで、同じ質問が出るのを回避したり、ユーザが自分の力だけで開発できるのを後押しできます。 多数のサンプルコードとベストプラクティス ドキュメントの中に多数の再現可能なサンプルコードがあるのは大事です。一部だけ載せてもさほど意味がありません。コードをコピー&ペーストしてドキュメントに記載されている内容がそのまま返ってくるのが理想です。 なお、その際のプログラミング言語は慎重に選ぶ必要があります。多数の言語について載せるのは簡単ですが、メンテナンスまで考えて載せる必要があります。最初からあまり多くの言語を載せると更新が大変になってしまうでしょう。 言語はサービスのターゲットが必要としているものに合わせる必要があります。エンタープライズであればJavaや.NETの利用が多いかも知れません。またスマートフォンアプリを対象としているならば各プラットフォームで使えるものになるでしょう。 開発者向けのサービスでもない限り、APIへの理解度はまだまだ低いのが現状です。そうした中でAPIを知らない人たちにも理解しやすい形で進めていくのは大事になります。特に「自分たちにも言えることだ」と考えてもらえるのは近い業種や職種の場合です。そうした事例を増やす必要があるでしょう。 プレスリリースなどによって広く浅く狙うのではなく、既存顧客の中からピンポイントでニーズを汲み取っていくのがお勧めです。

企業がAPIを使う側に立った時、それは一つのAPIだけを使うとは限りません。APIでは複数のAPIを組み合わせるマッシュアップと呼ばれる形態が存在します。同じ市場に存在するAPI同士を組み合わせることで、API提供元ではできないサービスを提供できる可能性があります。有名なところではホテルや旅行の検索アプリケーションが挙げられます。 そうした複数のAPIを組み合わせて使う場合、問題になるのがネットワークの遅延であったり、API停止に伴うマッシュアップサービスへの影響です。今回はそうしたマッシュアップ時における問題点と解決策を紹介します。 フロントエンドではAPIを処理しない JSONやRESTfulでのAPI提供を行っていると、WebブラウザのJavaScript側でデータを取得したり集計できるようになります。そのためWebブラウザだけで処理を完結させたいと考えることでしょう。その方がサーバサイドの仕組みも用意しないで済みますし、簡単です。 しかし各APIが密に結合している場合、一つのサービス停止が他のサービスに影響を及ぼすのは避けなければなりません。そこでデータの収集をサーバサイドで行い、データベースに入れておくことでデータの参照はいつでもできるようになります。 なお、APIによってはサーバサイドでの蓄積を禁止している場合がありますので注意してください。また、OAuth2のような仕組みを使っている場合、サーバサイドでは認証データがなくて目的のデータにアクセスできないことがあるので注意が必要です。さらにFacebookなどのOAuth2トークンは有効期限が決まっており、常にデータアクセスができる訳ではありません。 データの取得はバックグラウンドで さらにユーザのリクエストに応じてAPIを叩くのではなく、APIへのアクセス処理はバックグラウンドで行うようにしましょう。APIからのレスポンスがないと何も表示されない状態が続くのは避けるべきです。 また、一旦キューに入れてレスポンスを返す仕組みであれば、何らかの原因でAPIアクセスがエラーとなった場合も再実行しやすくなります。ユーザからの入力をそのままAPIに渡す場合、エラーが出てしまうとユーザは再度入力を強いられることになるでしょう。 データの取得中はユーザ向けにはインジケータを表示するようにしましょう。まず画面の表示だけ行ってしまって、データの取得ができ次第画面を更新するようにすればストレスは小さくて済みます。 データを疎結合にする APIを密に処理してしまうと問題が発生しやすくなります。A -> B -> Cの処理の流れがあった時に、AまたはBに不具合が発生するとCの処理は全くできなくなってしまいます。そういった事態を防ぐためにAPIはそれぞれを疎結合になるように設計しましょう。 APIの多くはHTTP/HTTPSでアクセスをします。つまり、3つのサービスを使っていて、それぞれが100msでレスポンスを返したとしても3つを密結合で使っていたら300msかかってしまうということです。 疎結合にできると各サービスへの接続が平行に（パラレルに）行えるようになります。3つのAPIを扱う場合も、同時にアクセスできれば100msでレスポンスが得られるようになります。 更新頻度の違いに注意 APIによって、データが刻々と変わるタイプとそうではないものがあります。一度取得してしまえば数ヶ月アップデートされないものもあるでしょう。例えば郵便番号から住所を返すものは、月一回くらいでしかアップデートされませんし、一年に一回しか取得し直さないとしてもワークフロー上大きく困ることはないでしょう。 そうしたデータの種類と更新頻度は注意が必要です。常に最新のデータを必要としないケースも多々ありますので、キャッシュを有効に使うのが良いでしょう。 APIはボトルネックになりがちです。データベースはシステム内部に構えられますが、APIは処理やパフォーマンス自体ブラックボックスになりますので明確に保証されるものではありません。APIがなければできない処理があるのも確かですが、頼り切りにならないよう注意しましょう。

企業におけるAPIの利用を促進し、ナレッジをシェアするEnterprise APIs Hack-Nightの9回目はMobiTech（Mobility × Technology）をテーマにウフル社のオフィスにて開催されました。 今回はその開催レポートになります。 激変する自動車産業におけるIDOMの戦略 by 株式会社IDOM　許 直人さん 現在海外ではMobilityに対して非常に積極的になっています。自動産業自体が現在サービス化、自動化という流れの中にあります。IDOMについても主力事業の流通は最優先としつつもCar As a Serviceにも注力しています。例えば自動運転にも手を付け始めていますが、一つ一つの投資金額が大きくなってしまうために慎重にならざるを得ないのが実状です。 今後の事業を考えると、若者は車に乗らず、老人は免許を返還するというトレンドがある以上、大幅な売り上げ増は臨めません。オンライン販売であったり、個人間売買など新しいチャネルの開拓が必須です。例えばIDOMではオセアニアや北米でも車の売買を行っており、日本で買ってニュージーランドで販売するような形も増えています。 そんな中現在はじめているのがノレル（月額購読型の車のレンタルサービス）であったりパスポート（メンテナンスサービス）です。システム開発も積極的で、IT系人材も積極的に採用しています。 中長期的な予測ですが、流通においては個人間売買やオンライン販売が伸びていくと予想しています。また、自動運転でレベル3まで達すれば、乗り換え需要が喚起できると考えています。とは言え2040年くらいには完全自動運転によって事業的に大きなインパクトがあると考えており、我々は危機感を持っています。 現在はシェアリングエコノミーが隆盛で、Uberなどが有名です。これは流通には大きな影響が考えられます。そこで私たちとしても自動車のサブスクリプションを提供し、所有から利用へのリプレイスを図っています。今後、車を販売した後に人に貸すと言ったようなアプローチもできると考えています。 テレマティクスコンピューティングについてはノキアがエッジコンピューティングを推しています。大部分の処理を車内にあるエッジコンピュータが処理し、結果などをクラウドに送るような仕組みです。この分野はとても投資が大きく、政府レベルで推し進める必要があります。いくら日本で使われるようになってもグローバルで再現性があるかも分かりません。今はアメリカ政府が推し進めており、車車間通信を後押しすると発表しています。 自動運転の普及によってエネルギー、環境産業やライフサイクルが大きく変化すると考えています。そのため自動車そのものではなく移動というニーズに対してフォーカスする必要があると考えています。つまりある地点からある地点への移動に注目するのです。2025年には自動運転が10%になると言われています。メディアのバイアスはあると思われますが、今後30年を考えるならばそろそろ情報収集を行っていくべきと考えています。 注目しているもう一つの市場が通信です。移動体通信やIoTは数少ない成長市場であり、車がどう関係していくか研究しています。例えば車の中にギガビットイーサネットの規格を定めようとしています。カメラやレーダー、アクセル、ブレーキに関する情報を通信するのが目的です。そうなればその通信を使ったサービスが一気に広がっていくのではないでしょうか。 現在、私たちは車のフリマアプリ「クルマジロ」を提供しています。在庫が数千台あって、メルカリよりもちょっと多いくらいです。東海と東北の二箇所でテストマーケティング中で、KPIの良い方を採用して全国展開をしていきます。元々自動車売買を行ってきましたので、CtoCを展開するとシェアを食い合うかと思われるかも知れません。しかし誰かが必ずはじめるものなので、だからこそ我々が先んじて行っています。とは言え、実際には買い取りとCtoCの両方が伸びています。買い取りを使うかCtoCを使うかの二択が提供できるようになったのが利点です。 このクルマジロは個人間売買ですが、お客さん同士ではやり取りしません。私たちが間に入って、車の状態などを詳しくチェックします。一台100万円を超えますので、それを個人が提供する情報だけで決定するのは難しいと思います。決済はなるべく短く、サービスはプロレベルというのがクルマジロの特徴です。 自動車のサブスクリプションであるノレルについては2016年12月から担当しています。現在はニーズの確認ができたという段階です。ローンが組めない方や主婦、ヒルズに住んでいる方など様々な利用者がいます。現在は一つのプランだけですが、ユーザのニーズに合わせてサービスを分割し、4月くらいにまた新規登録を再開したいと考えています。日本は法律上、車輌の登録や維持コストがとても大きくなっています。これまで人生でせいぜい10台くらいだった車の所有数が、3ヶ月で乗り換えられるようになります。ノレルについては将来的にAPIを公開して、車の場所や様々な情報を公開していきたいと考えています。 今後肝になるのがデータです。私たちの提供するサービスは一つ一つはそれほど大きくありませんが、大事なのは根幹にある巨大なデータベースです。例えば査定は年間数十万台行っています。そうした基盤データを拡大させて利用していこうと考えています。 自動車産業についてはとてもお金がかかりますし、テクノロジーもハイレベルです。すべて自分たちではできません。そこでベンチャー支援であったり、M&Aを通じてサービスを伸ばしていこうと考えています。 私たちはモビリティ革命で世界をリードしていきたいと考えています。 【講演資料】激変する自動車業界におけるクルマ屋の戦略 from naoto kyo つかれが"みえる" - 着られるセンサーで車両安全運行管理 by NTTコミュニケーションズ　増田 知彰さん 現在、年間125万人も交通事故で亡くなっています。そんな中、注目されているのが自動運転です。2025年には公共交通にも使われていくと言われています。しかしまだまだ運転手が多いのも事実で、その部分にも注目していかないといけません。バスの運転手は高齢化しており、人手不足も慢性的です。この問題は日本に限らず世界でも共通して起こっています。そこでSAPと私たちで協業し、こうした社会問題を解決していこうとしています。 今回紹介するのがその一つで、2016年10〜11月に京福バスと一緒に行った実証実験になります。20名以上のドライバーに協力してもらい、疲労度やストレスを数値化、可視化することで運行に役立てるデータを提供するというものです。これはバイタルデータだけでなく、タコグラフのような従来の技術とも組み合わせています。 夜行バスの例ですが、終盤になると疲れる率が増えてきます。休憩で一定量回復しますが、終盤になると疲れているのが分かります。周回バスの例では昼便、夜便で事情が違います。例えばバスに老人が多く乗る昼便の場合、万一彼らが転倒すると事故扱いになります。そうならないため緊張度が高くなっています。 一例ですが、ギアボックスが故障してバスが立ち往生したデータがあります。故障した時が一番ストレスのピークになっていますが、実はギアが入りづらくてストレスを感じるのはその前からはじまっていました。こうした予兆が分かっていると未然にアクションを起こして事故が防げるんじゃないかと思っています。 人が運転する間は適宜休憩やダイヤ改正、セルフケア、トレーニングなどによって事故削減につながるだろうと考えています。 今回用いた技術について紹介します。生体情報を測定するウェアは、NTTと東レが開発した機能性素材hitoeを使っています。これは金属繊維がないので着心地がよく、ジェルのような伝達をよくするものも必要ありません。そして、これで心拍を取るのですが、加えて心拍の揺らぎを測定します。この揺らぎ（心拍変動）から緊張度合いが測定できます。よく脈拍が取れるデバイスもありますが、精度については心拍を使った方が高くなります。hitoeは他にも建設現場での体調管理や事故防止を大林組と実証実験を行ったり、ドコモから個人用途のトレーニングアプリを出しています。 なお、こういったデバイスではすべてデータが確実にとれる訳ではありません。データ欠損であったりノイズもあります。どういったデータを取るのか、見せるのかをちゃんと決めたり、ビジネスとの整合性を取る必要があります。 データ収集の仕組みですが、自社のAPI Gatewayの仕組みに載せています。APIとして必要な基本機能は任せられ、サービス毎の機能開発だけに専念できました。さらに大きいのがIAM拡張階層の追加によってサプライヤーやエンドユーザという概念を追加しました。これによって直販と拡販（BtoBtoX）が同時に扱えるようになっています。 データ分析やレポーティングについては特にクレンジングが難しいところですが、私たちではJupyterを使っています。Excelのように簡単にデータを扱えます。再現可能な分析環境が手に入ります。 おまけですが、今回のプロジェクトはグローバルでトライしているため国内だけでやるのに比べて幾つかの違いがあります。例えば欧米の場合は離職率が高いため、プロジェクト憲章や仕様書、ガイドなどのドキュメントをきちんと固めます。誰が辞めてもプロジェクトが継続できるようにしています。また、各国それぞれ法制度が異なったり規制もあります。コミュニケーションについては従来はテレコンやメールでしたが、今回はSlack上で行いました。ドキュメントはMarkdownフォーマットでスムーズ、一体感を持ったコミュニケーションが実践できました。皆さんもぜひ使ってみてください。 私たちはより安心、安全な交通へ貢献をしたいと考えています。 ヒトとクルマと業務をつなげるコネクテッド・カーアプリ「Cariot」のAPI by フレクト 遠藤さん 私たちの提供するサービスはコネクテッドカーアプリのCariotになります。Car × IoTをつなげたものです。デバイスからUXまでを一気通貫で提供するB2B2X向けのサービスになります。 自動車業界や自動車は幅広く、ビジネスで使うとしても営業車、バス、タクシーなど多数あります。そんな中、自動運転にフォーカスするのかなど選択肢が色々ありますが、私たちは今日から使えるというところに重きを置いている。そこでデータを使って自分たちの業務をより良くするCariotを提供しています。 簡単なシステム構成ですが、既存の車にデバイスを差し込みます。そうすればデータをCariotプラットフォームに蓄積するようになります。そして集まったデータを仕事に活かすという仕組みです。デバイスは二種類あって、一つはOBD ITデバイスです。故障診断などに使うポートにデバイスを差し込みます。これで車のエンジン、オドメーター、アクセルの踏み込み量などが取れるようになります。もう一つはシガーソケットに差し込むタイプで、これはGPSや算出した速度をCariotプラットフォームに送ります。 今は毎月新しい機能を開発し、無料で提供しています。そしてAPIを活用して個別の業務に最適化したアプリを提供しています。アプリは全部で3種類あり、Salesforceネイティブ、Salesforceカスタム、フルカスタムとなっています。それぞれの違いは次の通りです。 - Salesforceネイティブ Salesforceの上でCariotパッケージをインストール。自分の車にデバイスを指すだけでノンプログラミングで今日から使えます。車輌の管理項目を追加も簡単です。 - Salesforceカスタム 自分たちのビジネスロジックに合わせてカスタマイズしてアプリを作ります。CariotパッケージのJavaScript APIを使って拡張します。CariotプラットフォームのAPIラッパー、ユーティリティメソッドを提供しています。 - フルカスタム スクラッチで作ります。すでにシステムがあって、そこにCariotのデータを投入したいというケースになります。パブリックなWebサイトなどで使えます。 基本的な機能は軌跡と推移が見える走行記録です。急加速や急ブレーキを発見したり、想定していたルートを走っていないなどが分かります。また、走行日報の自動生成もできます。そうやって蓄積されたデータは車輌予約と実績管理にも使えます。会議室の予約をするよう車輌を予約して、実績を管理できます。これは車輌の利用が最適化に繋がります。結果は稼働率レポートになりますので、ムダに使われている、余裕があるといった状態が可視化されます。 さらにヒートマップ機能があり、重み付けして地図上に色分けします。これは待ち時間の可視化であったり、走行のボトルネックが分かります。Salesforceが持っているデータベースにキャリオットが持っているデータを連係させますので、Salesforce上で見られるようになります。走行が長い人、急発進や急ブレーキも分かります。 現在、約20社に導入しています。導入自体はゴールではなく、そこから業務が改善し、エンドユーザのワークフローがよりよくなるのを目指しています。カスタマサポートとして継続して提案をしています。ある例では営業車輌管理として226台の走行データを管理するのに使っています。その結果、1台あたり2時間くらいかかっていた報告作業がすぐに終わるようになりました。また、報告の督促も必要なくなりました。そして、車輌の実績がデジタル化されることでムダな車輌が分かるようになり、保有台数が13台減りました。別な例ではダンプカーの運行管理があります。土砂の積み卸し、往復回数などを自動で集計できるようにしたことで業務の効率化が進みました。 次にAPIについてです。これはビジネスと技術の二つの側面があると考えています。まずビジネスについてです。まず最初に何を作るのか決めますが、この時に使いやすさや整合性、一貫性を保つ必要があります。データと人や業務の間には少なからずギャップが存在します。そのためシステムの都合に合わせたデータ形式ではなくユーザ体験を重視して作る必要があります。APIの提供はゴールではなく、スタートです。使い勝手の良いAPIを提供し、使ってもらうのが大事です。 技術の視点では後方互換性の維持を重視していますが、将来どういったAPIが必要になるか分からないので難しい所ではあります。ただ、互換性が崩れるパターンとしては「型を変えたい」「名前を変えたい」「フィールドを削除したい」など決まったパターンが多いので、こうならないためのアンチパターンを知っておくと良いかと思います。パステルの法則に従って、受信は柔軟に送信は厳密に行うのが基本です。私たちのシステムではAWSのAPI Gatewayを使っています。API Gatewayがすべてのリクエストを受けるシングルエンドポイントになっているのが大事です。 APIのケーススタディですが、到着予測APIというのを開発、提供しています。元々のきっかけは配達業者にコンタクトを取った時に、渋滞などのトラブルによって配送が遅れたり、連絡が遅れて迷惑がかかるという課題がありました。この時、ドライバーは遅れていることで大きなストレスがかかります。大事なのは荷物を届けるとともに、事故などを起こさないサービス品質もあります。顧客は荷物が来ないことにストレスを感じますので、車が今どこにあるか分かったり、後何分で来るか分かれば安心できます。 そしてAPIではルートを登録するAPIや車の現在位置を返すAPI、そしてエリアへの到着や出発をトリガーとしてプッシュするWebhook APIを実装しました。これによってドライバー、荷受け主ともに業務改善と安心につながりました。 コネクテッドカーは人、もの、コトをつなぎ、社会に還元される仕組みです。私たちはあるべき未来をクラウドで形にし、組み合わせによる新しい体験を実現したいと考えています。自前の車載デバイスからのデータに限定せず、生体データや重量、積載量、温度、天気、オープンデータ、音声などを組み合わせてサービスを提供していきたいと考えています。 発表の後、懇親会が同会場内で行われました。MobiTechはとても幅広い市場だけに可能性も大きいと言えます。それだけに参加者の会話も弾んでいました。 当日の動画はYouTubeにアップされています 。ぜひご覧ください。 今後も継続的にイベントを開催していきますので、ぜひご参加ください。

APIを使えばWebサービス同士を簡単に連携させられます。あるサービスで起こったイベントを感知して、別なサービスを起動すれば、普段行っている業務がどんどん自動化させられます。今回はそうしたタスクランナーサービスを紹介します。 IFTTT この分野における先駆者的なサービスです。あるリソースに対してアクションが起こったら、別なアクションを実行するというシンプルな形になっています。百以上のサービスが登録されており、メールやストレージ、チャット、ソーシャルサービスなどを相互連携できるようになっています。 Zapier 登録されているサービスの数で言えばIFTTT以上にあると思われます。無料プランでは1ヶ月に100回しか実行できません。月額50ドル出すと、50分ごとに処理が実行されるようになります。より本格的に使っていく方向けと言えます。 myThings Yahoo! Japanの提供するサービスです。iOS/Androidアプリでタスクを設定するところが特徴です。そのためアプリ特有のプッシュ通知を利用することもできます。また、端末の位置情報をトリガーにしたり、IoTデバイスとの連携も可能です。 Microsoft Flow マイクロソフト社の提供するサービスです。主にマイクロソフトの各種クラウドサービスと連携しますが、他も含めて108個のサービスが登録されています。よりビジネス利用に特化したサービスと言えます。 Integromat ルーターという概念によって、データをフィルタリングしたり、振り分けて別なサービスを呼び出すことができます。複数のサービスをまとめることができるので、より複雑なタスクを処理できるようになります。 Cloudpipes 300以上のサービスが登録されています。CRMやSalesforce、各種プロジェクト管理、マイクロソフトの各種サービスなど、よりビジネス的なサービスとなっています。フローは分岐したり、条件付けができます。 IFTTTなどはとてもシンプルに作られていますのですぐに理解できるでしょう。さらに扱えるサービスを増やしたZapier、スマートフォンに特化したMyThings、ビジネス向けに展開するMicrosoft Flowなど各社がサービスを展開しています。このようなサービスをどう使えば良いかは実際に手を動かしてみないと分かりづらいかも知れません。ぜひ一度試してAPI連携のポテンシャルを感じてください。

APIStudy #5参加レポート 2月21日、高円寺のヴァル研究所にてAPIStudy#5が開催されました。これはAPI設計のベストプラクティスを皆で考えるというLTとワークショップの形式で行われている勉強会になります。 今回はその参加レポートになります。 APIを巡る動き まず最初に主催であるアプレッソの脇野さんによる発表がありました。この1、2月の間にAPI関連のニュースをよく見るようになったそうです。例えば次のようなニュースがありました。 デバイスAPIはどこまで使える？最新事情を紹介──HTML5デバイスAPI勉強会 #html5jplat｜CodeIQ MAGAZINE 特集：“業種×Tech”で勝つ企業、負ける企業（3）：みずほフィナンシャルグループがAPIを中心に展開するFinTech最新事例――Amazon Echo、Soracom、LINE、Facebook、マネーフォワード、freee (1/2) - ＠IT ニュース解説 - API管理ツール、OSSも登場して戦国時代へ：ITpro 今回のAPIStudyは24人の参加で、これまでの最多となっています。とは言え元々のコンセプト通り、マニアック路線で進んでいきたいとのことです。 続いてLTの発表内容です。 こんな駅すぱあとWebサービスはいやだ by ヴァル研究所 丸山さん 駅すぱあとは1988年に生まれで29年目のサービスだそうです。SDKやイントラネット版の提供により、個人利用だけでなくビジネスシーンでも数多くの採用実績があるとのことです。そして駅すぱあとWebサービスはAPIで提供されていたり、APIだけでなくサンプル（HTML5 UI）も用意されています。 そんな駅すぱあとですが、現状次のような問題点があるそうです。 APIキーが紙で届く コピペできない… 自動発行ではない 今すぐ使いたいのに自分が使いたいときに使えない パスが直感的ではない /stationは駅の情報を返すんだろうと予想できる。/course/station、/course/passStationでは何が返ってくるのか分からない。 パラメータが多すぎる 仕様を読むのが大変。 JSONが使いづらい 紐付いているindexの番号が0はじまりじゃなく1はじまりになっている。配列の最初なのにindexが1。 さらに戻り値が配列だったり、オブジェクトの場合も。例えば結果が複数の場合は配列になり、1つの場合はオブジェクトになるといった具合。 これらは最初フィクションの体だったのですが、実はフィクションではなく実際の駅すぱあとAPIをベースに話されていたようです。最後にこれから自社でAPIの開発をする方にはこの失敗を踏まえていいものを作ってください、として丸山さんの話が終わりました。 ニフティクラウド mobile backend のREST API 4つの課題 次に筆者が登壇して発表しました。ニフティクラウド mobile backendというサービスのREST APIの仕様に関する話です。ニフティクラウド mobile backendというサービスはmBaaS（mobile Backend As a Service）と呼ばれるサービスで、アプリのバックエンド（サーバサイド）で必要な機能を提供するものです。 その中から4つの課題を紹介しました。まずAPIのバージョン管理で、リリース時（2013年）から変わっていません。変更タイミングは大きな問題です。 次にセキュリティで、署名生成のアルゴリズムが複雑であると、開発者が正しい生成アルゴリズムを書けているか検証するのが困難になります。実際にAPIを実行してみないと分からなかったり、エラーになった場合になぜエラーなのかが分かりづらいのが問題です。 3つ目は動的に変化するパスで、mBaaSの場合開発者の指定した名前でデータベースのテーブル相当の管理が可能になります。そのため、規定で存在しているデータと開発者が指定したネーミングによってAPIのパスが異なる仕組みになっています。統一性という意味において難点があります。 最後にドメインです。APIは開発者の利用するものと管理画面で利用するものと2種類存在します（実際にはさらに細分化されて4種類）。似たような機能を提供するAPIが作業領域の違いによってドメインを分けて運用せざるを得ないというのはとても面倒なことです。 といった形でLTの後のワークショップに繋げられるような話題を振って終了しました。 APIでダブルバッファリング by ヴァル研究所の伊藤さん 伊藤さんはレスポンスに時間がかかるAPIを巡る話を紹介されました。集計が絡むAPIになるとレスポンスを返すまでに1分以上かかる場合があり、大きな問題になります。 集計処理を実行しつつ、その結果を適宜確認したいというケースはよくあります。バッチ処理を実行して数日経ってから確認して問題がありました、ではやり直すのも大変だからです。そこで最新の集計結果を確認できるようなAPIを作成します。 しかしデータ量が膨大であるために処理時間がどんどん長くなっていきます。その内レスポンスがちゃんと返ってこなくなってしまったそうです。これは初期の想定よりも処理対象データ量が多かったという問題もあったそうです。 そこでリクエストのあったタイミングでバックグラウンドで集計処理を開始し、それまでは前回の集計結果を返すようにしたそうです。この最新の集計結果と前回の集計結果が2つのバッファリング（ダブルバッファリング）になります。 バッチ処理の集計結果を返すようなAPIではこのようなダブルバッファリングが必要になっていくのではないかとのことです。 ワークショップ この後、4つの課題に分かれてワークショップが実施されました。今回は次の4つの議題です。それぞれのチームで話し合った結果も書いてあります。 レスポンスが遅いのにどう対応するか 一口に遅いといってもユーザの要件とすり合わせる必要があるでしょう。 APIのサポートが増加したらどう対応するか kintoneのユーザ間サポートがよさそう。エヴァンジェリストを見つけよう。サンプルコードを充実させよう。問い合わせをAIで処理、分類分けする。営業の人たちを鍛えて簡単な質問はその場で答えられるようにする。 こんな状態は問題がある 英語対応。エラーレスポンスの形式。サポート。 複数のAPIを上手に使う方法 処理の分散と集中で解決できそう。 こちらはAPIStudy #5のグラフィックレコーディングです。 APIStudyではワークショップを取り入れることで全員参加型のイベントとなっていました。意見を交わすことで得られるものも多く、新しい知見もたまりやすいかと思います。 次回の APIStudy #6は3月28日に行われる そうです。興味がある方は参加してみてはいかがでしょうか。

2016年あたりから注目されるようになった技術ワードにサーバレスがあります。サーバレスアーキテクチャといった単語は一度は見聞きしたことがあるのではないでしょうか。 サーバレスアーキテクチャはAPIと相性が良いと言われていますが、そもそもサーバレスとは何かを紹介します。 実行時以外には存在しない究極のクラウド クラウドコンピュータの世界では、サーバと呼べる存在は仮想化されており、自由に立ち上げたり落としたりできます。とは言え、サーバ（インスタンスとも言う）を立ち上げている間は料金がかかります。そのため、不用意にサーバを立ち上げすぎないように注意しなければなりません。そのサーバはCPUの質や量、GPU、ストレージなどによって金額が変わります。つまり仮想ではあるものの、リソースを確保することに対して料金が発生します。 対してサーバレスはそのサーバ自体が存在しません。もっと単純な、関数をクラウド上に定義します。そして関数はHTTP/HTTPSを介して呼び出されます。呼び出すまでは存在しないので、料金はかかりません。そして実行する際にメモリ上に展開されたデータも破棄されるので、料金は実行した回数や実行時間などによって決まります。 サーバレスの料金体系 サーバレスのサービスとして最も有名なAWS Lambdaの料金を見ると、関数に割り当てたメモリ量、実行回数そしてじ毎回の実行時間によって決まるとしています。さらに毎月100万回のリクエスト、40万GB秒が無料枠として設定されています。実際の計算は細かいのですが、関数に対して512MBを割り当て、300万回の実行、そして毎回の実行時間が1秒だった場合、18.34ドルという計算になっています。 前述の通り、サーバレスはHTTP/HTTPSでアクセスされるものになるので、APIとしてみれば300万アクセスされるようなAPIが月額18.34ドルで運用できると言い換えることもできます。 利用できる言語は 例えばAWS Lambdaの場合、Java、Node.js、C#および Pythonがサポートされています。Google Cloud FunctionsはNode.js、Azure FunctionsではC#、f#、Node.js、Python、PHPなどがサポートされています。サポートされている言語は拡大していますので、大抵のプログラミング言語が使えるようになるでしょう。IBM Bluemixではオープンソースのサーバレス実行環境であるOpenWhiskをサポートしておりNode.js、Swift（Kitura）、Python、JavaさらにDockerも利用できます。 AWS/Google Cloud/Azure/Bluxmixはクラウドベンダーとしては最大手になりますので、いずれのプラットフォームでも使えることを考えると、Node.jsが最も良い選択肢になりそうです。 利用時の工夫 前述の通り、サーバレスアーキテクチャでは利用時間によって料金が変わってきます。つまりなるべく速く処理を終えた方が料金が安く済みます。そのため、関数の中では重たい処理を避けるのが賢明です。例えば画像の生成、ネットワークアクセスなどはボトルネックになりやすいでしょう。データベース接続もコストが高いですが、避けるのは難しいかも知れません。 関数からサーバに接続してデータを取得するのではなく、関数にサーバのデータをポストして、それを解析させるのがお勧めです。ネットワーク接続せざるを得ない場合はタイムアウト時間を極力短くして対象サーバが落ちている場合なども処理が速く済むように工夫しなければなりません。 APIゲートウェイとの組み合わせ サーバレスの話が出ると一緒に話題になるのがAPIゲートウェイです。サーバレスでは10個の関数があると、10のURLに分かれます。それぞれに関連性はありません。そのためAPI公開するとなると、何らかの取りまとめる存在が必要になります。これがAPIゲートウェイの役割です。 APIゲートウェイがアクセスを一手に引き受け、パスによってアクセス先の関数を変更します。また、認証情報を取りまとめたり、頻繁にコールされるのを制御するといった役割も担います。それによって関数がそれぞれ認証情報の検証をしたり、アクセス制御するようなコストのかかる作業をしなくて済むようになります。 サーバレスの向き不向きについて すべての処理がサーバレスに置き換わる訳ではありません。特に処理時間がかかるものついてはサーバレスに置き換えると料金が高くなる可能性があります。また、他の処理との密接度が高いものについても不利です。関数は個々に独立し、疎結合になっているのがベストです。 逆に送られてきたデータを処理してファイルに書き込んだり、メール送信するだけといった単純な処理はサーバレス向きと言えます。関数は無数にスケールさせることができますので、処理を大量に並列化したいといった目的や、逆に殆どアクセスされないのにサーバを保持しておかないといけないといった場合の置き換えに向いているでしょう。 サーバレスを使いこなすためにはこれまでのサーバを複数台揃えて運用するという方法から、クラウドを主体としたアーキテクチャ（サーバレスアーキテクチャ）を意識した形にしなければなりません。それはこれまでにない意識を必要とするでしょう。 まだまだ手探りで試されている最中で、開発や運用方法含めてトライ&エラーが必要です。しかし今後サーバレスアーキテクチャは確実に開発者が考えるべき開発要素になっていくので、今のうちに何ができて、何ができないのかを学んでおくと良いでしょう。

これからシステムにAPIを組み込んでいこうとした場合、まず真っ先に思いつくのがRESTful APIではないでしょうか。なんとなくは分かっているつもりでも、意外といざ実装してみると難しいのがRESTful APIです。今回はその基本的な考えを紹介します。 HTTP/HTTPSアクセス RESTful APIではHTTPまたはHTTPSアクセスが基本になります。ネットワークのプロトコルは他にもたくさんありますが、RESTfulな実装に向くのはHTTP/HTTPSになるでしょう。 HTTPメソッドがアクションを表す GETは取得、POSTは作成、PUT/PATCHは更新、DELETEは削除を表します。 パスがリソースを表す 例えば GET /users/1 であればユーザID=1に対する操作を意味します。 GET /users/1/posts であればユーザID=1の持っているポスト一覧を意味します。POST /users/1/posts であれば、ユーザID=1の新規投稿を意味すると言った具合です。 パスとHTTPメソッドを見れば、どのリソースに対して何の処理を行うかが分かるようになっています。usersはサービスやモデルの単位で設定し、その後の1という数字はサービス中のユニークなIDを示します。 クエリーで細かな条件を指定する さらにURLのクエリーを使って操作内容の細かな指定を行います。例えば一覧画面の場合、取得件数を指定するのが一般的です。その際、 GET /users/1/posts/limit/100 とはしません。 GET /users/1/posts?limit=100 とします。 データリソースの一覧を取得するという処理は決まっていますので、その詳細についてはクエリーやbodyを使って表現します。 取得するデータフォーマットを指定する RESTful APIではJSONまたはXMLでデータの送受信を行うことが多いです。その際、フォーマットの指定方法は主に2パターン考えられます。一つはパスに含める方法で、 GET /users/1.json といった具合です。もう一つはクエリで指定する方法で、 GET /users/1?format=json のように行います。 RESTfulの原則に則って開発するのはシステムの可読性を維持し、さらにメンテナンス性も良くします。パスの切り方などもRESTfulの原則に則っていれば、何の処理を行うのかも一目で分かるようになります。 簡単なルールしかないために、ついつい拡張したり、オリジナルルールを混ぜ込んだりしてしまいがちです。しかし、それをぐっと堪えて書くことで見通しの良いシステムを維持できるでしょう。

企業間におけるAPI利用が拡大していくと、API自体が利益を生み出すAPIエコノミーが広がっていきます。 APIエコノミー自体については以前記事にしています が、その中で考えるべき視点がサービスのAPI化です。 より複雑な処理をRESTfulで処理する 単純なデータベース構造やモデルの公開はRESTfulによって処理を行えます。RESTfulは開発者にとって分かりやすく、使い勝手の良いAPIフォーマットになりますが、幾つかの問題点があります。その一つがクライアント側（利用側）のコード量が増大することです。 単純なモデル操作だけをRESTfulで公開している場合、複数のモデルを連携させるような操作を実現するにはAPIを利用する側のコード量が増えがちです。例えばカレンダーに顧客との打ち合わせを追加する場合、RESTfulで考えると次のようになります。 顧客APIに対して顧客の存在確認を行う（GET） データがなければ作成を行う（POST） カレンダーAPIを使って日付が空いているか確認する（GET） 空いていれば顧客と自分の情報を合わせてスケジュールを登録する（POST） このロジックはすべてクライアント側で行わなければなりません。さらに4のスケジュール登録自体は顧客データを取得していなくても実行できてしまうため、作り手によってデータ構造が変わってきてしまう可能性があります。 サービスのAPI化を考える際には、これらの処理をある程度パックにし、一つのAPIとして公開するのが良いでしょう。必ず踏まなければならないステップがあるならば、それはクライアントではなくサーバ側で処理する方が効率的です。 RESTfulではネットワーク通信量が増える 先ほどの例においても4回のネットワーク通信が発生します。ネットワーク通信はどこでエラーが発生するか分からないため、なるべく少ない回数で終わらせる方が効果的です。システム連携が前提のAPIではコネクション数増大によるリソース欠乏にもなりやすく、その意味でもコネクション数は少ないに越したことはありません。 ネットワーク数を減らす方法として、バッチ処理で複数の処理を一回で送れるようにするものもあります。しかしこの場合、顧客の存在確認を行った上でデータの作成を判断すると言った条件処理は困難です。結局、必要なデータを集めて判定を行ってAPIをコールするというステップは変わりません。 通信を減らすための方法として、検索してデータがなければ作成して返すといったようなAPIを用意する方法が考えられます。よくある処理について一つにまとめてしまうことでクライアント側、サーバ側の処理両方を減らすことができるでしょう。 また、内部のメソッドを呼び出すのもお勧めです。この時、HTTPを経由して呼び出すのはよくありません。コネクション数が増えてしまうからです。ただしマイクロサービスによってシステムを疎結合にしている場合はうまくいかない可能性があります。 RESTfulはトランザクションに弱い RESTfulの弱点としてトランザクションがあります。業務システムにおいて途中でエラーが起こった時のロールバック処理は必ず求められるのですが、RESTfulではうまく実装するのが困難でしょう。これはHTTPの仕組み上、一回一回のコネクションで閉じてしまうと言う問題にも関係しています。 一度にデータをすべて受け取れれば、サーバ内部ではトランザクションを使った処理が可能になります。特に企業間におけるAPI活用においてはトランザクションを意識した設計が必要になるでしょう。 RESTfulというとデータベースのテーブルはモデル単位での操作が思い浮かびますが、モデルの操作だけで済むケースは多くありません。開発者がそのAPIを使って何を実装するのかを意識し、彼らにとって使いやすい形で公開する必要があります。 データベースではなく、利用する機能やサービスと言った単位でRESTfulなAPIを作ると使いやすいでしょう。

APIは一般的にプル型の技術です。クライアント側からアクセスがあるまでは待ちの状態になります。クライアント側から見ても、サーバ内部でどのデータが更新されているのかはアクセスしてみるまで分かりません。この手の問題で厄介になるのが「どのデータが削除されたのか」が確認しづらいということです。すべてのデータを見た上で、抜け落ちていれば削除されたといった確認方法であったり、処理の履歴を見て判断すると言った方法になってしまいます。 そこでサーバ側からでもデータの更新を伝えられる方法を使って、クライアントとのコミュニケーションに役立ててみましょう。 WebSocket WebSocketはHTML5仕様の一部として定義されていましたが、現在は本体とは切り離されています。WebSocketはいわゆるPubSubな形で、クライアントがサーバ側のメッセージを購読（Subscribe）します。サーバは誰が購読しているかは気にせず、発信（Publish）するだけです。とは言え、購読相手に対してきちんと届くように、または届かなくても良いと言った品質管理もできるようになっています。 HTML5の中で生まれたので仕組みとしてはWebブラウザを対象にしていますが、各種プログラミング言語向けに購読/発信できるライブラリが存在します。ws://、またはwss://（SSL/TLS版）ではじまる専用のプロトコルを利用します。 IoT分野であれば似たような仕組みにMQTTがあります。こちらはヘッダのデータ量が小さいという特徴があります。プロトコルはmqtt/mqttsといった独自のものになります。 WebRTC WebRTCはP2Pなメッセージプロトコルになります。動画や音声を流すこともできるので、動画チャットや音声チャットに使われることが多いようです。最初のコネクション情報を交換する際にはSTUNサーバを介しますが、実際のデータ送受信はP2Pにて実行されます。 基本的にクライアント同士のメッセージ送受信について行われますので、APIには向かないかも知れません。とは言え、リアルタイムにデータの送受信ができるプロトコルなので、活用法はあるでしょう。 WebHooks WebHooksはサーバに対してあらかじめURLを登録しておき、サーバ側で何かイベントがあった時に通知してもらう仕組みです。クライアントが通知して欲しいURLを登録するので、セキュリティについてはあまり考慮されることはないようです。 HTTP/HTTPSを使うので他の仕組みに比べると手軽です。ただしサーバ側の負荷は高くなる傾向があります。通知を受け取る側はインターネット上に公開されている必要があり、開発時は若干手間がかかります。 Webサイトプッシュ スマートフォンではよく知られているプッシュ通知の仕組みをWebブラウザで実現できるのがWebサイトプッシュです。まだGoogle ChromeやFirefoxなど限られたブラウザのみ実現できます。 サーバ側では対象になるWebブラウザのトークンを保持しておく必要があります。そのトークンを指定してメッセージを送信します。プログラム向けにJSONデータをPayloadとして送ることもできます。 APIをサーバ間でリアルタイムに送受信するために使うのであれば、現時点ではWebSocketまたはWebHooksを使うのが良さそうです。Webブラウザとの接続であれば、WebSocketまたはWebサイトプッシュになるでしょう。なお、リアルタイム通信系はRESTfulのようにデファクトスタンダードと言える形式が決まっていないため、サービスごとに送受信されるデータフォーマットが異なっています（それでもJSONを使うケースが多いですが）。導入する場合には一貫した設計になるように注意が必要でしょう。

マイクロサービス システムをごく小さくまとめ、APIベースで機能を提供するマイクロサービスがより広がっていくと考えられます。多くのモノリシックなシステムにおいて密結合が拡張性やメンテナンス性において負の資産となっています。マイクロサービス化することで結合ポイントを減らし、開発を容易にします。 マイクロサービスは多くがモデルデータのCRUD操作をREST APIにて提供します。HTMLを返すものは多くありません。まさにAPI向けの施策と言えるでしょう。ただし、サービスの分け方をうまくやらないと、ただシステムが細分化されただけで複雑なシステム構成になってしまいます。 最近ではマイクロサービス用のフレームワークも登場し、開発がより簡単になっています。次の段階としてはアーキテクチャであったり、サービスの切り分け方に関するソリューションが共有される年になっていくことでしょう。 Swagger 昨年できたOpenAPI InitiativeによってSwaggerは一社の情報からオープンソースへ、そして業界のデファクトスタンダードへ成長しようとしています。APIのドキュメント記法については他にも幾つかありますが、SwaggerおよびOpenAPIが最も大きなシェアを取ると思われます。 ただし現状のバージョン2と、新しいバージョン3は全く構造が変わることが決まっていますので、これまでに作成したツールは対応が迫られるでしょう。ドキュメントについてはコンバーターが用意される予定となっています。バージョン3は今年中にリリースされる予定です。 標準フォーマットができあがることで、周辺ツールも作りやすくなります。これまでにもドキュメント、モックサーバ、テストなど多くのライブラリがありましたが、さらに利用範囲が広がっていくものと思われます。 APIマネージメント 多くのAPIはサービスに紐付いて作成されます。そのため、各サービス責任者のやり方であったり、開発するタイミングでトレンドが変わっていることがあります。そうしたフォーマットの不統一感は利用者を混乱させたり、重複した開発を必要としたりします。 そういった問題を解決するためにAPIマネジメントを導入する企業が増えています。APIマネジメントを導入することでセキュリティ、負荷対策、インタフェースの統一、ログ管理などといった機能が一元管理できるようになります。 APIのインタフェースを変えるのは困難です。そのため、恒久的に使えるような明確な基準をもって設計に取り組む必要があるでしょう。APIマネジメントの多くはそうした基準をあらかじめ備えており、利用者にとって分かりやすいAPIが開発できるようになっています。 内部APIの増加 BtoBにおいては企業間のみで提供されるAPIが存在します。これらのAPIは契約した企業だけに公開されるもので、ドキュメントなども非公開になっています。しかし、多くのAPI関連ツールは公開前提に作られているものがあります。一般的なプログラミング言語においてメソッドの公開、非公開が指定できるのと同様に、APIにおいても公開、非公開が設定できるようになっていくでしょう。 内部APIの増加は企業間におけるAPIトランザクションの増加につながるので決して悪い兆候ではありません。ただし、企業が連携先を探す際にAPI情報が見つからないのは問題があるため、何らかのドキュメントは一般公開されるべきでしょう。 ハードウェア連携型APIの増加 数年前からIoTが一つのキーワードになっていますが、多くの企業がハードを買って、そこからネットワークへの繋ぎ込みを自分たちで開発しています。それらはとてもリソースのかかる作業であり、最近ではクラウドサービスと自動連携するIoTデバイスが登場しています。 デバイスがネットワークを備えている場合はMQTTまたはWebSocketのようなプロトコル、場合によってはREST APIをコールする仕組みになっています。デバイスの設定さえ行えばすぐにネットワーク上にデータが上げられるので、開発がとても効率化します。 IoT向けにクラウドサービスを開発している企業においては、デバイス企業と組んだ上でサービスの提供が求められていくでしょう。 HTTPエラー表現の統一 2016年03月に出た RFC 7807 - Problem Details for HTTP APIs が参考になります。この中ではapplication/problem+json または application/problem+xml というレスポンスヘッダーが提案されています。これまでREST APIではHTTPステータスを使ってエラー表現を行ったり、独自のエラーオブジェクトを返したりしていましたが、これを統一していこうという動きです。 返却する内容ですが、例えばJSONの場合は次のようになります。 { "type": "https://example.com/probs/out-of-credit", "title": "You do not have enough credit.", "detail": "Your current balance is 30, but that costs 50.", "instance": "/account/12345/msgs/abc", "balance": 30, "accounts": [ "/account/12345", "/account/67890" ] } こうしたJSONとHTTPステータスを合わせてエラーを表現していきます。 企業におけるAPI利用、公開が徐々に進んできています。2017年もまた、提携であったり自社システム同士の連携にAPIを利用すると言ったケースも増えていくことでしょう。

最近のAPIではJSONをリクエスト/レスポンスフォーマットとして採用することが多いですが、サイズが決して小さくないことやパースにかかる時間などを気にするケースもあります。そこで考えてみたいのがシリアラズされたフォーマットであったり、他のフォーマットです。今回はそんなフォーマット例を紹介します。 JSON RESTful APIで最も多いファイルフォーマットではないかと思います。JavaScriptのオブジェクトフォーマットですが、多くのプログラミング言語でパースしたり、生成できるようになっています。それだけシンプルなフォーマットであると言えます。 冗長性はあまりありませんが、JavaScript特有の波かっこの多さやダブルクォートに囲みなどはあまり好まれない部分と言えます。 google/protobuf: Protocol Buffers - Google's data interchange format Googleが開発しているフォーマットです。XMLより3〜10倍小さく、パースは20〜100倍高速であるとしています。あらかじめプロトコル定義ファイルを作成し、コンパイルすることで多くのプログラミング言語に対応したコードが生成されます。 MessagePack: It's like JSON. but fast and small. JSONと似ているわけではありませんが、サイズについては対JSONとして強く意識しているようです。JSONから不要な部分を削り取ったことで、サイズは大幅に減っています。対応しているライブラリも多いのですが、人による可読性が低いのが難点と言えるかも知れません。 Welcome to Apache Avro! Java、Python、C、C++、C#などで使えるデータのシリアラズフォーマットになります。プログラミング言語が限られてしまいますが、エンタープライズな企業システムであれば採用できる可能性がありそうです。スキーマはJSONで定義します。 The Official YAML Web Site 人が読みやすいという点を重視したフォーマットです。非常に多くのプログラミング言語でサポートされていますが、APIのフォーマットよりも設定ファイルのフォーマットとして採用されることが多いようです。 Extensible Markup Language - Wikipedia いわゆるXMLのことです。Webサービスの頃に最も使われたフォーマットです。閉じタグで囲むというのが冗長的で面倒というのが悩みのタネでした。企業間でも使えるように検証する仕組みなどもあらかじめ用意されている点が利点です。 多くの場合、XMLを解釈するライブラリはそのコードが独特なものになりがちです。JSONのようにハッシュや連想配列、Dictionaryになるわけではありません。 シリアラズされたフォーマットは人が読むことはほぼ想定されていません。そのためプログラミング言語同士の中でしか使われませんがサイズが小さかったり、高速に処理ができるようになります。サービスの規模や利用想定によって採用を考えてみても良いでしょう。

これまでサポートや問い合わせに寄せられるメッセージは人の目で見て、その意味を解釈した上でデータベースに構造化して登録されていました。しかし何百、何千とある文章を読むのは大変なことです。 それらを機械で処理できる可能性を持っているのが自然言語分析です。機械学習モデルをベースにすることでテキストの構造はもちろん、意味も分析できるようになってきています。 Cloud Natural Language API  |  Google Cloud Platform Googleが提供する自然言語分析APIです。非構造化テキストの中から場所や人の情報を取り出したり、感情を抽出することもできます。他のAPIと合わせることで音声データを分析したり、手書き文書からデータを読み取ることもできます。 IBM - Natural Language Classifier 自然言語分類 | Watson Developer Cloud - Japan IBMが提供する自然言語分類APIです。テキストの背後にある意図を解釈し、あらかじめ用意しているカテゴリのどれにマッチするのかを分類分けできます。クラスタリングの高性能版と言えます。 解説・事例 | docomo Developer support | NTTドコモ RESTfulにテキスト情報を分類分けできます。そしてもう一つ一般的にセンシティブと呼ばれる言葉を分析し、テキスト内容が危険の高いカテゴリにどれくらい近いかを分析できます。 テキスト分析 - Cognitive Services | Microsoft Azure Azureで提供される言語処理APIです。英語のテキストを分析し、自社ブランドに対する評価を判断できます。さらに重要なフレーズを抽出したり、トピック検出、言語判定が可能です。 Conversational User Experience Platform for products and services - API.AI 与えられたテキストからアクション、名前、人、日付などをJSONで取得できます。それによってテキストが何を目的としているかが判断できるようになります。英語のみサポートしています。 非構造化テキストから意味を見いだすというのはとても困難です。テキストを分析する分かち書きのような処理は分類分けはできますが、その奥にある意図までは読み取れませんでした。自然言語分析APIを使うことでメールやチャットなどのテキストも自動的に分析し、適切な対応が行えるようになるでしょう。

データを可視化する方法としてグラフやチャートが用いられます。ユーザにとってはメリットがある反面、開発者としてはグラフを出力するのはそう簡単ではありません。画像ライブラリを入れたり、JavaScriptのグラフライブラリに合わせたデータ出力が求められます。 そこで今回はグラフを簡単に作成できるAPIベースのグラフサービスを紹介します。 Charts  |  Google Developers Googleの提供するグラフサービスGoogle Chartsです。カスタマイズも容易で、グラフは画像の他SVGでの出力もできます。刻々と更新されるデータに合わせたリアルタイムグラフも作成できます。 Charts  |  Google Developers HeartRails Graph | キュートな円グラフ簡単作成サービス HeartRailsが提供する円グラフ作成サービスです。項目と割合を設定するだけでグラフが作成できます。べつやくメソッドと呼ばれるグラフを模しており、フォントも可愛らしいものが採用されています。 HeartRails Graph | キュートな円グラフ簡単作成サービス rurihabachi.com - Web API - Function(x) Graph 関数グラフを描くためのサービスです。実データではなく、関数を与えるとグラフが表示されます。 rurihabachi.com - Web API - Function(x) Graph ChartBlocks Charting API データセットを適用してグラフを生成します。グラフはSVG/PNG/JPEG/PDFといったフォーマットで出力できます。データのアップロード（リアルタイムデータ含め）、グラフのカスタマイズもAPI経由でできます。 ChartBlocks Charting API APIを使うことでサーバ側でライブラリをインストールしたり、JavaScriptで処理すると言ったコードが不要になります。手元にデータがあるならばこれらのAPIを使えばすぐにビジュアル化が実現するでしょう。

APIは外部リソースからデータを取得して他のデータと合わせて自分たちのサービスに付加価値を追加できますが、同じように外部からデータを取得する手法としてスクレイピングが知られています。今回はスクレイピングとAPIの違いを紹介します。 スクレイピングとは？ スクレイピングはサーバサイドのプログラミング言語を使って外部サーバへアクセスし、そのコンテンツから自分たちの欲しい情報を引き出す手法です。多くはHTMLを返す場合に使われ、DOMを解析したり正規表現を使ってデータを抜き出します。 スクレイピングはサービスが認めていない方法 APIはサービス提供側が一定の条件を設けた上で公開している開発者向けの機能になります。対してスクレイピングは本来はユーザ向けであるHTMLコンテンツをコンピュータに解析されるもので、公式にサポートされているものではありません。 そのためコンピュータによって負荷を高めたり、許容されていないアクセスを行うと不正アクセス防止法違反によって処罰される可能性もあります。 なぜスクレイピングをするのか 最も大きな理由としてアクセス先のサービスがAPIを提供していないという問題があります。APIがあるならばそれを使いたいと考えるでしょうが、APIがないためにスクレイピングに頼らざるを得ないと言えるでしょう。また、APIが公開されていたとしても必要な情報がスクレイピングしなければ取得できないと言ったケースもあります。 コンテンツは企業にとって生命線である場合も多く、それらのデータをまとめて抜かれてデータベース化されることを懸念する声もあります。 スクレイピングのデメリット スクレイピングはHTMLコンテンツの形式に左右されます。そのためデザインが変わるとデータがうまく取れなくなる可能性があります。その場合、再度スクレイピングの作成し直しになりますが、大幅にデザインが変わったりURLの階層が変わったりするケースもあります（実際にはSEOへの影響があるのでURLは変わらないことのが多いでしょう）。 また、サービス提供側でログを解析している場合、怪しい動きをするログを確認するとアクセス拒否される可能性があります。Googleなどシステムが強固なサービスはすぐに弾かれる可能性があり、その結果としてスクレイピング以外でのサービス利用においても影響を受けることになります。 さらに認証後のデータを取得するようなスクレイピングはサーバ側にID、パスワードなどを保存しなければなりません。これは利用者にとって大きなセキュリティリスクになることでしょう。 スクレイピングを防止するには スクレイピングはAPIが提供されていれば防げる行為です。スクレイピングは、それをしなければならないほど、コンテンツに魅力があるという証拠とも言えます。であれば公式としてきちんとアクセスコントロールした上でコンテンツをAPI提供する方が健全と言えるのではないでしょうか。 スクレイピングはイタチごっこになりがちで、防げるものではありません。そして開発者の不用意なコードによってサービス提供側が影響を受けたり、サービス利用者が迷惑を被ることになるでしょう。そうならないためにAPIを公開するというのは大切なことです。 スクレイピングの例 最近ではアプリやWebサービスで自分の資産管理を行う系統のサービスにおいて、各金融機関、クレジットカードのサイトへスクレイピングを行っているケースがあります。金融機関のID、パスワードを登録しなければならず、万一漏洩などが起こった時には大きな損害につながる可能性があります。 理想的には各金融機関がOAuth2ベースのAPIを公開し、適切なアクセスコントロールを実現できる仕組みを用意するのが一番でしょう。

多くのAPIが認証情報とともに実行されます。実行ユーザを特定する目的の場合もあれば、APIキーのような情報を使ってコール数をカウントする目的で使うこともあります。 今回はそんなAPIにおける認証情報をAPI中のどこに持たせるのが良いか、紹介します。 URLパラメータ URLのパラメータとして持たせる場合はセッションキーやトークン文字列であることが多いです。もう一つのパラメータ（アプリケーションキーなど）と合わせて、認証が正しいことを検証するようになっています。 トークン文字列は一定期間で切れる仕組みになっており、有効期限が過ぎた後はリフレッシュして新しいトークン文字列を取得し直します。 URLの場合、Webブラウザからの検証がしやすいのがメリットです。単純にURLをブラウザで開いて結果が返ってくればパラメータが正しいかどうかが確認できます。 HTTPヘッダー HTTPヘッダーに認証キーを埋め込む方法もよく見られます。Webブラウザからの確認は若干難しくなりますが、Ajaxのような仕組みを使えばヘッダーに文字列は簡単に追加できます。 クエリー文字列はどういった操作を行うか指定するものとし、ヘッダーは認証などシステムのスコープを分けるのは開発者にとって分かりやすい区分けかも知れません。 セッション、クッキー あまりお勧めしませんがセッションやクッキーに認証情報を持たせることがあります。スマートフォンアプリなどで、非公開な自社アプリ限定で使っているAPIの場合、このようなケースがあります。 利点としては既存のWebサービスと同じ仕組みで使いまわせるという点が挙げられます。Webサービスでは認証情報をURLに載せたりしません。ヘッダーにするとWebブラウザからは利用できなくなります。 WebサービスとAPIは分けて提供する方が良いのですが、Webサービス側で認証を通っているにも関わらずAPI側の認証が通っていないと判断されるのはユーザビリティが良くありません。そのため、セッションキーを利用するケースも少なからず存在します。 お勧めな方法は？ OAuth2ではURLに認証トークンを追加する方法になっています。実装としては一番手軽と言えるかも知れません。次にヘッダーへの追加が良いでしょう。セッションを用いるのはよほどのことがない限り避けるのが良いでしょう。 Webサービスとの連携についていえば、セッションの認証キーとAPIの認証トークンとを交換するAPIを用意するのが良さそうです。まず、そこにアクセスすることでAPIアクセスに使える認証トークンが手に入ります。その後からのアクセスは認証トークンを使えば良いのです。認証トークンはオンメモリに保存し、別なURLに移動した際には再度交換すれば良いでしょう。認証トークンは重要な情報なのでlocalStorageに保存するのは避けた方が良いでしょう。 認証トークンは定期的にアップデートしましょう 認証トークンは1週間程度の有効期限が良いかと思います。多くのスマートフォンアプリでは認証トークンをアプリ内にストアし、それを使い続けます。しかし万一認証トークンが漏洩した場合、誰でもそのサービスへなりすましでアクセスできるようになってしまいます。 認証トークンをアプリ内にストアするのは致し方ありませんが、アプリの起動時に新しいものと差し替えても良いでしょう。そして認証トークンは複数の端末からは使えないように制御するのが良いでしょう。そのため1ユーザに対して複数の認証トークンが保存できるようになっているのがお勧めです。 APIにおける認証トークンは認証情報そのものです。漏洩すると、APIを経由してデータ操作が自由にできるようになってしまいます。それだけに漏洩しづらい場所に保存したり、使い方にも注意が必要でしょう。 どのアプリ、どのブラウザまたはシステムからアクセスしたかが分かるように、認証トークンは複数発行できるようにしましょう。そうしてユーザから任意のタイミングでトークンを削除したり、再生成し直せるようになっていると便利ではないでしょうか。