Enterprise APIs Hack-Night #2 レポート

去る12月3日、渋谷の21cafeにてEnterprise APIs Hack-Night #2 が開催されました。今回はそのレポート記事になります。

Enterprise APIs Hack-Night #2 - connpass

Office 365 を中核としたこれからの API 戦略

登壇者：日本マイクロソフト株式会社 テクニカル エバンジェリスト 松崎 剛さん

Microsoftでは多くのWebサービスを提供していますが、今回はその中でもOffice 365に関する話になります。Office 365ではExtensibility、Remote API Accessがありますが、今回はRemote API Accessについてしょうかいします。技術的にはOAuth2とRESTfulを使っている。

大事なキーワードはOpenness。JavaScriptがあればVisual Studioを使わなくても開発できます。言語にも依存しないので、.NET以外の言語でも開発できます。

もう一つの戦略はクロスデバイス。最近はApple、Androidを優先して開発しているくらいです。昔はWindowsを優先していましたが、iOSやAndroidの上でも自分たちの製品を使ってほしいと考えています。

今後のOffice 365 APIがどうなっていくかについて、まず現状から説明します。

• OneDrive
• SharePoint
• Exchange
• Active Directory

これらはすべてRESTfulなAPIが用意されています。Azure ActiveDirectoryがすべての認証を司っています。ここだけ取り出して使うことも可能です。ビジネス向けとして、管理者がOKを出したら従業員の方は、わざわざ一つ一つの機能に許可を出さなくてもOAuth認証だけで機能を使えるようにしています。

そして今後についてですが、1週間前に発表したのがUnified - Microsoft Graphです。これまで各APIはエンドポイントがばらばらで、権限も個別に分かれていました。ファイルを上長にメールするなどといったら、各APIにアクセスしないといけない状態で、そのファイルのある場所によって各APIの許可をもらう必要があります。

ユーザが選択したファイルのプレビューを出といった操作をしようとした場合、Exchange、SharePoint、OneDriveの各パーミションを取っておかないといけませんでした。Graphはエンドポイントを一つにし、横の製品間の横断をできるようにします。

Unifiedにはもう一つの側面があります。ビジネスとコンシューマ用APIの統合です。例えばMSにはOneDriveが2つあります。一つは単なるOneDriveで、もう一つはOneDrive for Businessです。同様にSkypeもあります。

今後、すべてAPIのエンドポイントを統一（graph.microsoft.com）していきます。ただし、これはコンシューマとビジネスが一緒になるという意味ではありません。for Businessは今後も残っていきます。APIのエンドポイントを一つにしていくだけです。アプリを一つを作っておくと、もう一つ（ビジネス）にも対応できるようになります。

さらにソケット型のサードパーティ統合が行われます。例えばOffice 365のアプリランチャーの画面に認証したアプリが出るようになります。そしてアプリから簡単に機械学習などのAzureの機能が使えるようになります。その結果、あなたの組織はどれだけ会議をしたかなどをビジュアル化することができたり、セールスフォースなどからデータを出せるようになるのです。

最後にSkype Developer Platform。今はSkypeのオンプレ版しかありません。今後REST APIを出します。音声通話、ビデオ通話に関するAPIを含まれます。JavaScript SDKを出すので簡単に使えるようになるでしょう。

トレタ × Yahoo! JapanのAPIによる提携の話

登壇者：増井 雄一郎 さん

Yahooが先日リリースした空席レーダーはトレタのデータを使っています。今から歩いて5分のところにある30人入れる店を探せるようなアプリです。

トレタCEOの中村は元々レストランを経営しており、実際に予約台帳を手書きでやっていました。この予約台帳はレストランの生命線であり、これをデジタル化しようとしているのがトレタになります。

提携の話が出たきっかけは、CEOがたまたまYahooの人と話をしたところからです。Yahooも元々Yahoo予約をやっていたのだけれど視点が違うという認識でした。これまでの問題は、予約サイトから予約があると、紙の台帳に反映して、各予約サイトにも反映するという大きな作業があった。そのため、飲食店側が面倒で使うのを嫌がりました。トレタは予約台帳システムなので、受け口は電話でもAPI経由でもOKというのが大きなポイントです。

そしてYahooとトレタで予約を軸に毎週ペースで会議を重ねて、APIのフォーマットを議論していきました。お互いサービスの初期設計の段階から提携できる形に設計を行っていたので話はスムーズでした。例えばトレタは予約は埋まる視点、Yahooは予約が空いているところという視点で、側面がまったく異なるのです。

今の時代、すべて自分たちでやるというのは無理があります。トレタではレジの会社のAPIとつなごうと考えています。そのためには外部連携することを前提とする必要があります。また、先にAPIの実装が終わっているというのがポイントです。大手と同時にやると力関係が働くので注意が必要です。

さらに本体のコアバリュー以外はAPIとしておく必要があります。また、オープンスタンダードを採用するのもポイントです。他社では独自の仕組みを無理押ししてくると聞きますが、トレタではOAuth2を使っている。標準技術を使っているので繋ぎこみの話がとても早く済みます。

最後に、大手との提携になるとPマークの取得、セキュリティ監査が必須になります。このコストは意外と大きいので、セキュリティチェックすることを前提に、チェック表などを作っておけば良かったと今ではかんじています。

提携先の対応速度は優先度次第です。トレタも今は4000店舗を越えて話がしやすくなっています。リリースしたばかりだと優先度が上がらないので、実績をあげるのが大事です。また、トレタは飲食店の代弁ができるといった立ち位置だったので相手も話を聞いてくれました。今後、スタートアップは大手と組んでいかないといけないと感じています。そんな時、大手に旨味をとられるのではないか、潰されるのではないかと心配してもしかたがありません。大手はリソースがあるので、やろうと思ったら提携せずともできてしまいます。なので自分たちの持ち味をいかさないといけなければならないのです。

「データの力を、まちの力に」〜UDC2015の取り組みとオープンデータ・プラットフォームDKANの活用〜

• 登壇者：東京大学空間情報科学研究センター（CSIS） 瀬戸 寿一 さん
• 登壇者：ANNAI 太田垣 恭子 さん

私たちはUrban Data Challenge 2015というプロジェクトを行っています。これは1年間を通して地域課題を解決していくプロジェクトです。地域課題というのは短い期間で結果を出すのは難しいと感じています。例えば札幌の保育園マップをベースとして、同様の動きが東京などに広がっています。

私たちは全国20拠点を設けていて、通年でワークショップで行っています。金沢では毎月ワークショップをやっているくらい活発です。また、社会性ある活動とあって、データパートナーが多いです。国立国会図書館、NAVITIME、オープンガバメント推進委員会などです。

オープンデータについては2014年は2500件でしたが、2015年は10457件と4倍以上になっています。ただし、日本のオープンデータは自治体のサイトに埋め込まれているため、手作業で収集しなければなりませんでした。中にはWeb APIでデータをオープンにしている自治体もゼロではありません。流山市、会津若松市はAPIを提供中です。

このオープンデータを支える仕組みとして知っておいて欲しいのがオープンデータポータルである、そのオープンソース実装がdkanです。システムはDrupalを使っています。DrupalはWebアプリケーションプラットフォームとして知られていて、有名なところではホワイトハウスがあります。政府自治体で24%のシェアを誇っており、オーストラリア政府はすべてDrupalにしようとしているくらい認知度があります。

そしてDrupalはAPI連携に強いCMSであり、REST対応にも対応しています。例えば以下のようなプラットフォームと連携できます。

• 他のDrupalサイト
• Android
• iPhone
• その他

オープンデータとは誰でも自由に使えるデータ置き場のことです。再利用、再配布も許可されています。そのため、使いやすいことが大事です。外部連携やAPIで取得できたり、各データのURIがあったりといった具合です。ただ、自治体の担当者レベルではCSV公開ですら大変なのが実状です。そんなレベルではデータ検索がしたいニーズはあるのですが、作るのは大変だったりします。

そういった機能をパッケージングしたのがdkanです。Drupal拡張なのでモジュールも利用できます。ECも大丈夫です。似たようなものにCKANもあり（Python）、dkanはCKANとのAPI互換となっています。他にも組織による権限分配に対応していて、自治体のような組織でもワークフローが構築できます。データはSolrを使って検索できます。

ロシア政府データポータルもdkanでできています。表形式で出したりグラフ化、地図化できます。データは一般公開なのか、ユーザ登録必須とするかなど自由に設計できます。

品質APIのご紹介とniconicoでのトライアル事例

登壇者：NTTネットワーク基盤技術研究所 木村 拓人 さん

QoEとはユーザ体験の品質のことで、今回は品質APIシステムがどういったものであるか紹介します。仕組みとしては次のようになります。

• ユーザから視聴要求がくる
• 基地局、IPアドレスなどを受け取る
• 見たい動画に対して幾つかのレートを持っているので、品質APIに問い合わせる
• 品質APIは最適な動画の品質を返す

ネットワーク品質に応じた配信を行うことで、再生停止発生率を著しく低減されられました。また通信データ量を20%下げることにも成功しました。

ユーザの視聴環境、動画配信条件を入力として、最適な配信条件を返す仕組みとなっています。

応用として、

• 通信前にAPIを叩くことで、通信状況が悪いためしばらくお待ちくださいといった案内が出せる
• 通信品質マップ

などが考えられます。

第1回に比べて企業色を強く打ち出したイベントになっているかと思います。参加者の方の満足度も非常に高く、登壇の後の懇親会も大変盛り上がっていました。

次回は2月10日を予定しています。ぜひご参加ください！