6月29日、Enterprise APIs Hack-Night #10が開催されました。このコミュニティは企業におけるAPI活用を啓蒙、ナレッジをシェアしていくというものです。今回は原点回帰し、Enterprise APIがテーマとなっています。 こちらはそのレポート記事になります。 富士通による社内API化の取組み by 富士通株式会社　鈴木 弘樹さま 富士通ではプライベートクラウドの中でApigeeを採用しています。そしてクラウドサービスとしてAPIマネージメントを提供し、お客様含めてエコシステムを構築しています。 そもそもなぜ富士通がWeb APIを推進しているか、さらに Web API推進室を立ち上げているかについて説明します。富士通では毎年、富士通サービステクノロジービジョンというビジョンペーパーを発行しています。その2014年版の中で、ハイパーコネクテッドワールドというコンセプトを掲げました。ハイパーコネクテッドワールドというのは、3年経った今では当たり前になっていますが、人や物がシームレスにネットワークに繋がっていく世界であり、それを富士通が影ながら支えていくという考えになります。この時、つなげていくためにはWeb APIが当然ながら存在しますので、Web API推進室が中心になって進めているところになります。 まずどう進めていくかが問題でした。我々が採用したいのはApigeeのユーザ事例としても挙がっているAT&T社のやり方に沿うという方法でした。彼らが最初に行ったのは、社内システムをAPIでつないでいくというもので、これをトップダウンで推し進めたのです。我々も同じように社長直下の組織として、Web API化を推し進めていきました。 次のステップはWeb APIの公開です。これは富士通自身はもとより、お客様にもWeb APIを公開してもらいました。そして相互のシステムを接続することでエコシステムを構築していきました。 我々はSIerなので、自分たちですべて開発するという選択肢もありましたが、Apigeeを採用しています。実際、これは苦渋の決断でした。決め手になったのは開発期間で、長い時間をかけられなかったということです。 現在社内にAPIポータルが整備されています。Web APIの仕様が書かれていたり、テストでAPIが実行できるようになっています。一つ一つのWeb APIは管理部署が異なりますので、このポータル上で申請をしてキーを払い出してもらう仕組みになっています。 事例について ここから幾つか事例を紹介します。まずサポートシステムについてです。富士通は長い歴史の中で様々なハードウェアやソフトウェアを販売してきました。そのため、サポート部隊が多数あり、それぞれ別なシステムが作られてきました。例えばサーバを10台購入してもらっているとして、すべてサポートに入るとは限りません。その内の半分だけといった場合もあります。そうした際、現場のエンジニアがタブレットなどを使ってライセンス状況などをその場で確認したいというニーズがありました。 既存システムを変更するのはほぼ不可能でした。そこで各システムの情報を取りだしてAPI化し、モバイルから使えるようにしました。さらにこれは社内だけでなく、パートナー企業でも使えるようにしています。 次に人事システムの例があります。これはテストだけで終わってしまった例ですが。既存システムのUI生成部分を改良してWeb APIを生成するようにしました。さらにAPIマネージメントを通じてAPIを公開しています。これによって社外からスマートフォンアプリ経由で人事、総務システムにアクセスが可能になります。ただし既存システムのUI部分に一つ一つ手を入れていくのは大変だと言うこともあり、中止となりました。 社外のクラウドサービスと社内システムを連携させた例もあります。これはAPIゲートウェイの力を使っています。パブリッククラウドと連携させる場合、社外ネットワークから社内システムを呼び出す仕組みが必要になります。これはセキュリティポリシーが大きな問題になります。これは当社のセキュリティ担当者からお墨付きをもらうことで実現できました。APIゲートウェイがあることで不正なトラフィックが防げること、ログがとれるので後からの監査もできるということで了承を得られました。 課題と解決策 ただ、Web API化を進める上でシステムオーナーとの温度差が問題になっています。社内システムは大前提として稼働し続ける必要があります。何の問題もなく動いているシステムに対して手を加える判断をするのは難しいです。旧来のシステムでは連携時においてファイル転送やバッチ処理が当たり前です。Web APIを作る際にはここに手を入れないといけません。もちろん改良するには予算がかかります。しかしWeb APIを作ったとしても恩恵を受けるのはシステムオーナーではなく、その周りにいる人たちです。オーナーは評価を受けられません。 この問題については幾つかの解決策を考えています。まず第一にビジネスデザインから入ると言うことです。何でもWeb APIにするのではなく、特に富士通のビジネスにとって必要な部分から開発するなら許諾を得られやすくなります。また、最近打ち出されている働き方改革という外圧に乗って人事周りのWeb API化を進めていくという方法もあります。 また、Web APIを公開した際に、それを使える人がどこにいるのかという問題もあります。例えばExcelを使って売り上げ分析を行っている方に対して売り上げ管理用のWeb APIが公開されたとして、その人が開発を行える訳ではありません。その実装部分についても考えないといけないでしょう。これは簡易的なフロントエンドやアプリケーションを作りやすくする仕組みも一緒に提供すべきと考えています。 技術の進歩は早く、既存のビジネスがどんどん破壊されていくという危機感を持っています。しかしそれを恐れるのではなく、私たち自身が破壊する側に回りたいという思いもあります。その一つがWeb APIです。新しいサービス、ビジネスを考える方たちはたくさんいるのですが、売り上げが立った時にその管理はどうするのかという問題があります。手作業で行うわけにはいきません。IT部門が積極的に動き、社内システムをWeb API化して推し進めていかないといけないのではないでしょうか。 API-GWを媒介としたIT資産利活用によるオペレーションコスト削減の取り組み事例紹介 by NTTコミュニケーションズ　中島 博行さま NTTコミュニケーションズではAPIゲートウェイを提供しています。今回はそのAPIゲートウェイを使った事例について紹介します。SO（サービスオーダー）をAPIを使って載せ替えた事例です。 なお、SOというのはNTT用語で、発注された内容を各システムにデータ登録し、ステータスに応じてワークフローが進んでいく一連の流れになります。例えば以下のようになります。 - お客様からサービスの発注をもらう - オーダー受付システムに受注情報を追加 - 契約管理システムに情報連携 - 対象サービスをセットアップ - 関連した案内メールを出す さらに各システムでは細かいタスクがあります。 SOは元々手作業で行っていましたが、自動化システムが導入されました。しかしこのシステムは年間数千万円の運用コストがかかっており、2016年度末で廃止が決まりました。問題は廃止後どうするかです。また手作業に戻るのか、はたまた自分たちでイチから作るのかといった相談を受けるようになりました。 既存のシステムはオーダー受付システムから受注情報を取得し、すべて自動化していました。契約管理、開通案内は独立システムがあり、その代替システムを同じように束ねられれば自動化できるのではないかと考えました。幸い、APIゲートウェイには複数のAPIをまとめてマッシュアップし、一つの新しいAPIにする機能があります。 プロジェクトの推移 ここからプロジェクトがはじまりました。まず、新SOシステムはまるっとAPIゲートウェイに変更することにしました。次に社内システムのAPIについて調査しました。調べてみた結果、意外とAPIは存在していることが分かりました。しかしインタフェースは統一されておらず、SMTPすら存在していました。幸い、APIゲートウェイにはプラグインでSMTPを呼び出したりすることもできます。なお、プロジェクトにおいて最も時間を費やしたのは社内システムとAPIゲートウェイのネットワーク接続になります。これは申請からテスト、許可まで1〜2ヶ月かかります。今回はいの一番に申請からはじめました。 様々なAPIを使う関係上、きちんと整理するためにシーケンス図を作りました。これはWebシーケンスダイアログが便利です。 ここまでできあがったら、後はAPIゲートウェイの設定を行っていくだけです。これは作成したシーケンス図に沿って、XMLベースのポリシーに合わせていくだけです。どのようなリクエストが来た時に、どう変換するかを設定します。基本的に組み合わせだけでできます。 このプロジェクトの効果として、年間数千万円かかっていたコストがほぼゼロになったというのが一番大きかったです。もし同じようなシステムをイチから開発していたら数億円かかっていたでしょう。さらに開発工数は私が業務の片手間で行って3ヶ月程度でした。 このプロジェクトを通じた2つの気付きがあります。一つは社内システムのAPIが意外と知られていないと言うことです。APIがないと思って諦めていたことが、実は可能だったりします。二つ目は社内システムのAPIが複雑ということです。機能が長い運用の中で複雑になってしまっていたり、欲しい機能がなかったりします。日付であってもフォーマットが違うなんてこともあります。 今後について 今後、APIは誰もが作って、誰もが使うのが当たり前になっていくのではないでしょうか。サービス企画の方、営業の方でも作れるようになっていくべきです。そして、それは社内でちゃんと啓蒙して広めていく必要があります。また、開発者を意識した設計になっていなければなりません。これまでのAPIファーストからAPIネイティブへ進化するのです。 今後はこのSO自動化を横展開していく予定です。モジュールを置き換えることで別なシステムに対しても同じように展開できるはずです。また、社内向けの開発者ポータルも提供していきます。 Q. どうやってAPIの開発を上長や周囲に認めてもらったのですか 私たちのチームではAPIを会社としてしっかり作っていこうという式があります。また、既存システムがすでにあって、それがなくなるとシステムをイチから作らないといけない状態でした。つまりAPI開発のメリットがしっかりと見えていた状態でした。 なので効果が分かりやすく見えているならば実行に移せるのではないでしょうか。今回のように年間コストが数千万からほぼゼロになると言われて嫌がる理由はないと思います。 Q. APIゲートウェイを何か拡張しましたか？ 足りない部分はJavaScriptを書いたりしたくらいで、ベースに手を入れていません。 Q. メンテナンスはどうやって行っていくのですか？ APIプロキシについては彼らがメンテナンスを行っていきます。API部分についてはワークフローも固まっていますので、一度立ち上げたものについては手を入れることは殆どないと思います。 マイクロサービス化のファーストステップ by 日本CA株式会社　加田 友広さま マイクロサービスとは限られた範囲の機能をもった独立したコンポーネントになります。それぞれのマイクロサービスはメッセージベースの通信で相互に接続できます。また、マイクロサービスアーキテクチャとはマイクロサービスの特徴を有し、高度に自動化された進化型のソフトウェア、システム開発手法、スタイルのことを言います。 元々AmazonやNetflixといったビジネススピードの速い企業の考え出した、スピード感ある開発スタイルになります。そういったIT企業のやり方には一定の設計思想があり、それを切り出したものがマイクロサービスになります。開発スピードを要求しつつ、大規模なシステムに対して安全に構築できます。特に決まったプロトコルや製品を採用するという訳ではありません。 そもそも、なぜ大規模なシステムをスピーディー、かつ安全に作っていくことができないのでしょうか。それはシステムが大きくなりすぎると各機能の境界が分からなくなってしまうことが挙げられます。維持可能な状態で（部分的に）リプレース可能となるシステムはどのように作れば良いのか、その答えがマイクロサービスになります。 特徴としては、 - アプリケーションサイズが小さい - Web APIで通信する - コンテキスト、ドメインドリブンデザインの考え方 業務範囲をベースにアプリケーションの枠組みを作る - 自主的に開発される DevOps的な考え方 - 独立してデプロイできる - 集中管理はしない - ビルドとリリースは自動化されている などが挙げられます。モノリシックなシステムとマイクロサービスの比較として、モノリシックなシステムの中にある機能をコンポーネント化し、 Web APIで接続する形にすることでマイクロサービス化が実現します。 既存のシステムをAPI化するには 今、既存のシステムをAPI化したいという要望があります。例えばフィンテックです。社内システムはレガシーなシステムが多いです。インタフェースが古く、CORBAやFTPといったレガシーな技術が使われています。そのため、API化が難しい状態です。APIゲートウェイすら導入できないレベルの時はどうするかを紹介します。 人目として、既存のバックエンド接続にAPIインタフェースをカスタムで付ける方法があります。既存のビジネスロジックをラッピングするだけの方法です。 もう一つの方法として、SOA/APIゲートウェイのバックエンド転送機能（プロトコル変換機能）を使う方法があります。つまりファイルを取得してAPI化するといった方法です。これはどれくらいカスタマイズできるのか確認する必要があります。 最近はバックエンドのコネクタが充実しているのですが、ライセンスが高いです。オープンソースのものもありますが、細かい部分の作り込みが発生する分、開発工数が大きくなってしまいます。 最後の方法として、スクレイピングを使うこともできます。APIゲートウェイが通常のブラウザがアクセスしているかのように振る舞うのです。リクエストを解析しないといけないので大変であったり、元々のHTML構造が変わってしまうと動かなくなってしまうという問題があります。ただ、お問い合わせも多いです。 マイクロサービスのファーストステップ ここからマイクロサービスを実践していくための方法を紹介します。まずデータセントリックとケータビリティセントリックという考え他について紹介します。 データセントリックはアプリケーションを作る際に、まずデータ設計を行う考え方です。私としてはデータ構造ではなく、アプリケーションが動くためにはどういった機能が必要なのかというケータビリティセントリックの方が良いと考えています。これはドメインドリブンに近い考え方だと思います。 データセントリックでは機能によってデータの共有が発生してしまい、部分的なリプレースがしづらくなります。また、データベースのアップグレードしたい、ドライバをアップデートしたいといった時に別なシステムにも影響を及ぼす可能性があります。 ケータビリティセントリックは個々のシステムはデータに対して疎結合になります。レスポンスさえ変わらないならば、データベースのバージョンや種類は一切気にしなくて良くなります。 現在のマイクロサービスにおけるデータの持ち方は、サービス毎にデータベースが独立して存在します。この場合、別なサービスが既存データベースにアクセスしたい場合はどうしたら良いでしょうか。データベースをレプリケーションするのは良くないでしょう。そこでデータベースのアクセスレイヤーもデータAPIとして疎結合にするのが良いのではないかと思います。新しいサービスができた時にもWeb API経由でアクセスすれば良いだけです。新しいビジネス要求に応えられない時にマイクロサービス側を変えたり、別なマイクロサービスを立てないといけない訳ですが、データAPI化すればデータアクセスが容易になるはずです。 そこでモノリシックなシステムからマイクロサービスへの移行についてです。まずロジックとデータベースを切り離します。その上でロジックをマイクロサービスに転換します。この時、各レイヤー層をWeb API化することでマイクロサービス化が実現できます。各デバイスやチャネルに対するデータ変換（JSONやXMLなど）についてはAPIゲートウェイが使えるでしょう。 この後、懇親会が開催されました。今回から勉強会と懇親会部分を分けたことで、より密の高い会話が行われていました。 そして懇親会中にはOracleの生駒さんがLTを行いました。 Oracle API Managementは買収ではなくOracle自ら開始したサービスになります。元々Oracleはデータベースの企業として知られていますが、今はクラウドに移ってきています。その一翼を担うのがAPIになります。社内でもIoTやAPIの空前のブームとなっています。こんな動画も作っています。 事例としてはデンバーの交通系企業での導入があります。今、電車がどこにあるかや遅延しているかどうかといった情報をAPIで提供しています。 API関連としてはApiaryという企業を買収しています。これはAPIの設計を行うサービスで、無償サービスも提供しています。MicrosoftやGoProといった企業も利用しています。 次回はAdTechをテーマとして、9月7日に開催を予定しています。ぜひご参加ください！

RESTful APIがIT業界で普及していますが、その反面で様々な限界も見えてきています。一つのリソースをパーマネントリンクで扱う分には簡単ですが、一覧や関連データを取得する、さらに一覧の絞り込みをしたいとなった時に突然煩雑になってしまいます。 そうした中で考えられているのがREST APIに置き換わる技術です。 OData Microsoftが提唱しているプロトコルで、HTTP/HTTPSを使います。クエリを記述することでデータの取得はもちろん新規登録や更新、削除も可能です。開発ツールも充実しており、.NET系であれば簡単に扱えるようです。 OData - the Best Way to REST GData Googleが提唱しているプロトコルで、AtomPubを拡張した形になっています。Googleが持つ多数のサービスがこのGDataに沿った形で提供されています。データ形式はXMLがメインですが、JSONにも対応しているようです。 Google Data APIs  |  Google Developers ORDS Oracle REST Data Servicesの略です。Oracleが開発している通り、Oracleデータベースとの親和性が高いプロトコルです。CRUD操作のエンドポイント（REST形式）は自動で生成されます。取得時の絞り込み条件はJSONで記述します。 Oracle REST Data Services GraphQL Facebookが開発したクエリ言語です。HTTP/HTTPSを使います。JSONに似たDSLで記述します。オープンなプロトコルなので、多数のライブラリが出ていたり関連サービスのリリースも盛んに行われています。購読という形で通知を受け取る機能もあります。 GraphQL | A query language for your API 元々この手のプロトコルとしてはODataが早かったのですが、あまり普及していません。GDataやORDSはベンダー依存が強いように見えます。GraphQLはAPIの広がりとREST APIの限界が見えてきた段階で登場し、一番良いタイミングかも知れません。

これからAPIを公開しようと考える企業は多いはずです。APIは単に作れば良いわけではなく、周辺の情報も一緒に整備していく必要があります。それらが抜け落ちると誰も使ってみようと思わないでしょう。 今回はAPIを開発する際に最低限チェックしたい6項目を紹介します。APIを公開する際にチェックしてもらうとよりスムーズな立ち上がりが期待できるでしょう。 APIフォーマット まず当たり前ですがAPIを作成しなければなりません。最近の流行としてはURLとHTTPメソッドを組み合わせたRESTful APIが人気です。各URLが個別のリソースを特定します。よく知られた仕組みを取り入れるのは開発者の体験を向上させるという点において重要です。 もちろんこれは利用目的によって異なります。例えばWebSocketの場合はURLが異なりますし、RPCであったりGraphQLで提供されるAPIは形式が異なります。とは言え、そういった技術を使う場合においてもデファクトがありますので、そうした手法を取り入れましょう。 認証 認証を伴わないAPIはまず存在しません。種類としてはBasic認証やトークン認証といった簡易的なものに加えてOAuth2/OAuth1/証明書などの認証があります。この技術の選定はAPIを誰向けに、どう提供するかによって変わってきます。 ユーザが自分のデータを操作するために提供される場合はOAuth2が一般的になっています。サーバ同士の連携ではトークン認証でも良いでしょう。シークレットキーと呼ばれる、漏洩すると不正利用される情報を伴う場合はWebブラウザ上で使えるようにするのは問題があるでしょう。 アクセス制限 アクセス制限として一般的なのは多数のアクセスに伴うバンです。APIの場合、プログラミングの組み方によっては大量のアクセスが発生することがあります。そうした時にサーバであったり他のユーザへのレスポンスを維持するためにアクセスを遮断することがあります。きちんと明文化されている場合もあれば、大きな負荷を与えた場合と言った書き方をすることもあります。 利用者によって利用できる機能を制限する場合、管理画面などを使ってアクセス制御を行います。AWSの場合、IAMという認証サービスによってアクセスできるリソースの制限ができます。この場合はユーザ、アクセス先、可能なアクションという三つの要素で制御されます。 CORS JavaScriptの場合、アクセスできるホストはlocalhostに限定されます。この制限を超えてAPIを利用できる仕組みがCORSです。これはサーバ側で設定しなければなりません。JavaScript（Webブラウザ）からAPIを利用できるようにするならば、CORSの設定は欠かせません。 なおCORSはすべてのアクセス元からの利用を許可する訳ではありません。開発するアプリケーション単位で制御することもできます。エンタープライズでの利用であれば、CORSでアクセス元を制御するのが良いでしょう。 ドキュメント 開発者向けのドキュメントは重要です。ドキュメントがなかったら誰も使ってみようと思わないでしょう。しかしドキュメントは作成やメンテナンスに大きなコストがかかります。あまり作り込み過ぎないのが良いでしょう。 最も大事なドキュメントはAPIとチュートリアルになります。最初の利用までのステップを簡単に行えるようにすることで最初の利用者を掴めるようになります。その上で徐々にドキュメントを充実させていけば良いでしょう。 SDK/ライブラリ APIをそのまま実行するのは意外と面倒です。特にOAuth2で署名を生成するのは面倒で、開発工数もかかります。面倒だと利用者も伸びないでしょう。そこで開発元としてSDKやライブラリを用意するのが一般的です。APIがブラックボックス化されれば開発者はAPIを意識せずに利用できます。 ただしSDKを提供するプログラミング言語の選定が必要になります。エンタープライズであればJavaやC#の優先順位が高くなるでしょう。スマートフォンかデスクトップかによっても異なります。将来的なメンテナンスコストも考えた上で選定しなければならないでしょう。 APIを作って公開するだけであれば簡単です。問題は使ってもらえるか、使いやすいAPIにできるかです。セキュリティも制限もなければ、利用するまでの敷居は低いかも知れません。しかしセキュリティやプライバシーに配慮されていない仕組みでは安心し手利用はできないでしょう。そうした観点も必要です。 さらにドキュメントであったり、ライブラリのような開発者がスムーズに利用をはじめられるための仕組みも用意しなければなりません。いきなりすべてを作るのは難しいので、定期的にアップデートしながら進めていくのが良いでしょう。APIは公開して終わりではなく、継続的な更新が肝心です。

大企業であったり、複数の事業をもった企業では部署やサービス毎にAPIを公開することがあります。統一されていない、基準のない中でAPIを公開すると、ユーザにとって不利益をもたらすことになったり、企業にとっても管理、運用コストの増大というデメリットにつながります。 今回はそんな管理されていないAPI公開に伴う問題を紹介します。 セキュリティリスク APIの認証技術は幾つか存在します。例えばOAuth2/OAuth1/トークン/Basic認証などです。これらがサービス毎にばらばらの基準で提供されているとどうなるでしょうか。あるサービスはOAuth2で認証し、別なサービスではトークンを発行したりします。 どの認証技術を用いるかはサービスや機能レベルによって判断されるべきで、担当者の考えだけで決まるものではありません。とても簡単なデータしか提供しないのにセキュリティ基準が非常に厳しかったり、重要なデータをトークンだけで公開したりするのは問題があります。企業全体としてのセキュリティ基準に沿って進められるべきです。 操作性の違い 長い歴史の中でAPIのトレンドが変化してしまい、古いAPIと新しいAPIでインタフェースが異なるというのはよくあります。しかし最近リリースしたものであるにも関わらずインタフェースが不統一なのは開発者にとってストレスです。インタフェースが異なればライブラリも変わってくるでしょう。同じ企業が提供するサービスであるにも関わらず、それぞれのAPIを習得するコストが大きくなります。 小さなところではURLがキャメルケースなのかスネークケースなのかであったり、削除がHTTPメソッドなのかパラメータなのか、パスの切り方がRESTfulの原則に従っているか否かと言った違いがあります。いずれも小さな違いではありますが、利用者視点で見ると、そこで躓くと大きなストレスになります。 機能差 サービス毎にAPIを作っている場合、その開発にかけられるコストは自ずと変わってきます。その結果、あるサービスではOAuth2で認証してクォート管理されていて、別なサービスではトークンだけで全く管理されていないといった事態になります。多くの開発者は最初に触ったAPIを基準に考えてしまいますので、サービス毎に基準が異なるのは問題です。 APIとしての基本機能については統一された基準で実装されている方が良いでしょう。そうすることで共通ライブラリが作成できる可能性が生まれ、一つのライブラリですべての機能が同じように開発できるようになります。 更新コスト APIは一度公開したら終わりではありません。開発コストに差が出るということは、更新についても同じことが言えます。全く更新されないAPIは完成度が高いという意味ではありません。放置されたAPIからは開発者も離れてしまうでしょう。 アプリやWebサービス側とAPIの機能差が発生するのもよくありません。一度APIを公開した後は、できる限り機能を追従して実装されるべきです。それができているAPIとできていないAPIが存在するのは開発者の心象としてよくありません。 ライブラリ開発コスト APIはそのままでは使ってもらえないかも知れません。そこでAPIの利用をラップできるライブラリの開発がよく行われます。プログラミング言語は限られますが、ライブラリがあることで利用してくれる開発者は増えるでしょう。ですがサービス毎に異なるURL基準になっていると、それだけで開発コストが上がってしまいます。 サービスごとに分岐が発生したり、認証方式を変えたりするのはとても面倒です。その結果としてサービス毎にライブラリが存在してしまい、開発者は複数のサービスを組み合わせたいと思った時にライブラリを複数インストールしなければならなくなります。 APIは企業やドメインごとに統一して提供されるべきです。一般的に開発者の期待する形に合わせておくことで利用を促進できます。提供側にとっても統一されていることで理解がしやすく、どのサービスに関係するAPIなのかもすぐに分かるようになります。 APIの統一のためにはAPIゲートウェイが最適な解決策になるでしょう。APIゲートウェイを使うことで一旦アクセスをすべてAPIゲートウェイで受け取って各サービスに分かれてアクセスするようになります。開発者の視点としてはエンドポイントが一つになるので統一感が出ます。また、APIのパスを作るルールも統一して管理されるので、イレギュラーをなくして管理できるようになります。

CA Technologies社がグローバルなAPI利用に関する調査、 APIs:Building a Connected Business in the App Economy を公開しました。特にエンタープライズ企業におけるAPI利用率の高さが伺える調査となっています。 この記事ではこのレポートの主だった内容の紹介と、そこから垣間見られる日本企業の取り組むべき方向性について紹介します。 大企業の88%がAPIを利用 グローバルなレベルで見ると、実に88%の企業がAPIをビジネスで活用しているそうです。さらに残り6%の企業は検討中とのことで、合わせると94%の企業が導入済みまたは検討中という段階にあります。もはやAPIを利用するのは当たり前であると言えるでしょう。 APIの利用目的は様々 APIを何のために利用しているかは大事なポイントです。しかし回答としては多岐に渡っています。 利益向上のため（33%） 開発者向けにAPIを提供し、セルフサポートやマーケットプレイスを展開（33%） 外部パートナーとの提携（34%） イノベーションまたは市場でのスピードアップが狙い（34%） バックエンドシステムとの連携（40%） 社内システム開発に利用（42%） わずかに高いのは社内システムでの利用になります。利益やパートナーシップで利用されているケースも3分の1程度存在します。さらに3分の1の企業がマーケットプレイスなどを展開し、開発者が収益を得たり、セルフサポートできる環境を提供しています。 API管理水準は高い APIの管理水準についてもレベルが上がっています。基本的な管理、または高度な管理を行っている企業は88%に上ります。その他の企業でも限定的な管理を行っており（10%）、全く管理していない企業は2%しかありません。 API管理は自社開発の他に、APIゲートウェイを使う方法があります。オンプレ、クラウドサービスかは選択の余地がありますが、こうしたAPIゲートウェイの利用は素早くて確実なAPI管理手法と言えるのではないでしょうか。 API管理レベルの変更によってもたらされるもの 興味深いのは基本的なAPI管理から、高度なAPI管理に変更したことによる変化です。トランザクション量が増加したり、IT系のコストが減る、顧客やパートナー満足度の向上といったメリットがあります。また、市場投入までの時間が高度なAPI管理を提供している方が早いというレポートが出ています。 なお、これらのデータは全世界、様々な業種の企業からなるデータになります。日本企業だけに限定するとAPIの活用率は低いとされています（via 「APIがビジネスに与える影響」を多くの企業が認識するも……：日本企業は「API活用」が出遅れている　CA調査 - ＠IT ）。API利用が市場投入の速さなど、ビジネスの加速につながっているならば、API利用に取り組まないのは致命的とさえ言えます。 ただし、今後大きな成長が期待できる分野であるとも言えます。その際には一歩ずつ歩んでいくのではなく、グローバルレベルでデファクトになっている技術、サービスを使うことで一気に最高レベルの仕組みを手に入れられるはずです。 すでに多数の企業がAPI管理サービスを提供しており、それらを使うことで現時点で理想的なAPI環境を手に入れられます。ぜひ今後のビジネス拡大にAPIを活用していくのであればチェックしてみてください。 APIs:Building a Connected Business in the App Economy

APIというとシステマチックな仕組みなので、中小企業とくにスタートアップが取るべき施策であるかのように感じてしまうでしょう。しかし、実際のところ大企業ほどAPI施策に向いています。この記事ではその理由について取り上げたいと思います。 数多くある事業 大企業においてはスタートアップと異なり、複数の事業展開をしているケースが殆どです。そして、それらは全く関係のない事業同士ではなく、シナジーを生むように設計されているはずです。そして顧客によっては複数のサービスを契約しているでしょう。 しかしそのシナジーは自社内部に留まってしまっていたり、ごく限られた範囲でしか生み出されていないことが殆どです。各事業においてAPIを公開できれば、顧客企業は自分たちのワークフローやニーズに合わせたシナジーを自分たちで生み出せるようになります。 すべての顧客のニーズを自社だけで満たすのは困難です。しかしAPIによって利用企業自身がカスタマイズできる仕組みを提供できれば、今まで考えていなかった新しい付加価値が生まれることでしょう。 すでにある膨大なデータ APIは主に二つの役割があります。一つは機能を提供するもので、画像を加工したり、AIで分析するといったものです。もう一つはデータベースに存在するデータをユーザの操作によって切り出して提供するものです。大企業ではすでに自社内で大量のデータが存在しているので、それらをうまく活用することで新しいビジネスにつながる可能性があります。 スタートアップでは自社データが存在しないために、データの追加/更新をAPIで提供します。それを通じて日々データを蓄積する必要があります。大企業の場合、データの追加/更新については既存のワークフローの中で行われていくでしょう。そして、まずその提供方法について考えれば良いのです。 固まったワークフロー APIによって処理が行われる時、ワークフローが変わるとAPIの処理内容も変わってきてしまいます。APIはシステムから呼び出されるので、あまり頻繁に更新が重なってインタフェースが変わるのはオススメできません。その点、大企業で昔からワークフローが変わっていないならば、それをAPIとして形作るだけになります。 ただしあらゆるワークフローに対応しようとしてパラメータが増えてしまうのは避けた方が良いでしょう。まずメジャーなワークフローに対して少ないパラメータだけで対応できるようにし、徐々に拡張していくのが理想です。 旧システムからのリプレイス 大企業でよくあるのは5年または10年に一回のシステムリプレイスです。このタイミングはAPIを開発する良いチャンスになります。既存業務を見直す際に、APIファーストの視点を取り入れましょう。API化することでデスクトップだけでなく、Webブラウザやスマートフォンなどマルチデバイスでの展開も容易になります。 APIファーストの視点で業務を見直すのは、入力操作などのUI/UXとシステムデータとの分離につながります。そうすることでシステムを簡素化し、メンテナンス性向上につながります。リプレイス案件は多くの企業にとって頭の痛い問題ですが、これを機にぜひAPIファーストの視点を取り入れてください。 他社との差別化 既存のビジネスにおいてライバル企業が存在しないということは殆どありません。各社でシェア争いをしていることでしょう。そうした中、APIの有無は差別化要因につながるようになっています。カスタマイズ性を高めたり、顧客のシステムとダイレクトにつながるようになります。 APIによるシステム連携は、他社への乗り換えも困難にします。契約を置き換えるだけでなく、システムの変更も必要になるからです。だからこそAPIを用意し、顧客に積極的に使ってもらうことができれば、それだけ他社との差別化になっていくでしょう。 大企業の特徴として、多数のプロダクト/サービスの存在、膨大な蓄積データ、ワークフローの固定化、既存顧客といった点があります。これらをポジティブな要因としてとらえ、API戦略によって他社との差別化につなげていくのが肝心です。 APIは何も小回りの効くスタートアップ企業だけの施策ではありません。大企業こそぜひ取り組んで欲しいと思います。

APIエコノミーが拡大し、企業におけるAPI利用が促進しています。そうした中とあって、APIについてしっかりと学びたい、APIを活用している人同士で交流を図りたいと思うのではないでしょうか。 今回はAPIをテーマとして開催されている勉強会を紹介します。 APIStudy - connpass “API（WebAPI）を提供するひと、利用するひとが集まり、APIに関する様々なノウハウ、疑問、課題を共有し「APIのベストプラクティスとは」を考えていく勉強会” です（公式サイトより）。LTとワークショップで構成されており、ワークショップ終了後に各グループが話し合った内容を発表し合います。 APIStudy - connpass Enterprise APIs Hack-Night - connpass 私たちが事務局として開催している勉強会です。特に企業におけるAPI利用を促進するための勉強会となっています。そのため他の勉強会に比べると技術よりもビジネス寄りの話が多くなっています。直近ではFinTechやEdTechなどxTechと呼ばれる領域の話題をテーマとして開催しています。 Enterprise APIs Hack-Night - connpass APIエコノミー友の会 V1 事例で学ぶAPIビジネス - connpass “APIから生まれる新しいビジネスに着目し、定期的に情報提供と情報交換の場をご用意して、APIビジネス拡大のためのエコシステムづくりの一助となる” のを目的とした勉強会です。APIエコノミーに着目した勉強会となっています。 APIエコノミー友の会 V1 事例で学ぶAPIビジネス - connpass Apitore -API関連の勉強会・LT大会- - connpass APIのマーケットプレイスを提供するApitoreが開催している勉強会です。勉強会の他、ハンズオンも頻繁に開催されています。 Apitore -API関連の勉強会・LT大会- - connpass Japan Web API Community - connpass 何らかの API に軽い気持ちで接続しようとして非常に苦労した人、API の価値が知りたい人、API に完全なるノンコーディングで繋ぐにはどうすればよいか知りたい人などの情報を必要としている方たちと逆に情報を共有したい人たちを対象としたゆるい勉強会です。開発者以外も対象としています。 Japan Web API Community - connpass API Meetup | Doorkeeper API系の勉強会としては最も歴史があるのがAPI Meetupです。特にビジネスだけに寄らず、多彩なAPIに関して学べる勉強会となっています。API全般に関して知りたいときには最適ではないでしょか。 API Meetup | Doorkeeper いかがでしょうか。それぞれの勉強会が特色をもって提供されています。ビジネス系、技術系など自分にあった勉強会に参加してください。

BitCoinで知られるのがブロックチェーンです。ブロックチェーン自体はあくまでも技術要素であり、仮想通貨以外でも利用できる技術です。分散型の台帳技術であり、一度書き込まれた内容は消せないという信頼性が強みです。 今回はそんなブロックチェーンを自社でも取り入れられるクラウドサービスを紹介します。 Blockchain as a Service (BaaS) | Microsoft Azure Microsoftの提供するブロックチェーンプラットフォームです。元帳を暗号化し、他の企業と共有して利用できます。特にエンタープライズ向けとして銘打たれており、ビジネスとしての利用が考えられています。 Blockchain as a Service (BaaS) | Microsoft Azure IBM ブロックチェーン - Japan IBM Bluemix上で提供されているブロックチェーンプラットフォームです。オープンソースのHyperledgerをベースとしています。開発段階ではHyperledgerを使い、大規模化したり、商用化する際にはIBM Bluemixに乗り換えると言った使い方が考えられそうです。 IBM ブロックチェーン - Japan Orb Orbは独自の分散型台帳技術Orb DLTに基づくブロックチェーンプラットフォームです。REST APIを提供しており、企業ごとに独自の仮想通貨を導入できます。 Orb Ardor – Blockchain as a Service Built on Nxt Technology グローバルなブロックチェーンもできますが、独自のブロックチェーンを構築することもできます。ワークフローに合わせて子ブロックチェーンを構築し、必要に応じてパブリックなブロックチェーンに展開すると言った使い分けが可能です。 Ardor – Blockchain as a Service Built on Nxt Technology mijin | - the Power of the Blockchain - 日本のテックビューロ社が提供するブロックチェーンプラットフォームです。最終的にプラットフォームをオープンソースとして公開する計画のようです。現在はプライベートβ中です。 mijin | - the Power of the Blockchain - ブロックチェーン自体は一社、自社だけで導入しても大きな価値を見いださないでしょう。他社であったり、ユーザ間での決済が発生する部分などに導入することで経済圏が形成できるようになります。様々な目的で利用できますが、今回紹介した各サービスで紹介されている事例などを見ることで、自社における利用法が想像できるのではないでしょうか。

今なお多くの企業でメインフレームと呼ばれるシステムであったり、そこまで古くはなくとも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の原則に則っていれば、何の処理を行うのかも一目で分かるようになります。 簡単なルールしかないために、ついつい拡張したり、オリジナルルールを混ぜ込んだりしてしまいがちです。しかし、それをぐっと堪えて書くことで見通しの良いシステムを維持できるでしょう。