先日、TwitterがAPI利用に対する締め付けを突然厳しくしました。元々規約にあった、複数のアプリケーションキーを一つのサービスで利用している問題に対するものですが、利用していないはずの開発者も凍結対象になってしまったようです。 よく知られたところではTogetterもその凍結対象になったサービスの一つで、数週間に渡ってアカウントが停止されていました（現在は復旧済み）。規約違反があればもちろん問題ですが、警告なしに突然凍結するのはあまりにも乱暴と言えますし、問題ないはずのアカウントを凍結するのは開発者に対する裏切りとさえ言えるでしょう。 こうした点からAPIをビジネス利用する上でのリスクが幾つか見えてきます。 規約を十分に確認する まず利用規約を十分に読み込みましょう。個人がプライベートで作るものについてはあまり関係ありませんが、企業で事業として利用するのであればその内容をきちんと精査しておく必要があります。商用利用について細かく規定されているケースや、利用する上での注意点についても明記されているはずです。 多くのAPIでは個々の企業利用について契約をカスタマイズすることはありません。API提供側からの条件をそのまま承諾することになりますので、自分たちの利用フローが規約を守れるかどうかは注意しなければなりません。 SLAを確認する サービスレベルが保証されていないサービスを利用するのは危険です。突然の終了であったり、メンテナンスが行われる可能性があります。オンラインサービスの場合、常時アクセスがあるのでAPIが突然利用できないのはリスクになります。しかし、100%のSLAというのは事実上不可能なので、99.8%などでも十分と言えるでしょう。 なお、多くのサービスではSLAを下回った場合にその課金額を上限とした保障となっています。つまり、APIの停止に伴って巨額の損失が発生したとしても、月額利用料程度しか保障は受けられません。そのため、APIが一時停止した場合でもサービスが継続できるような仕組みを設けておくべきでしょう。 有料プランを採用する APIによっては商用利用を前提として有料プランを提示しています。ビジネスで利用する場合には利用量に応じたプランを適切に選択しましょう。実際には複数人や複数のプロジェクトで使っているにも関わらずアカウントを共有していたりすると適切な保障を受けられないケースがあります。 無料枠の中で使うという手もありますが、無料枠の場合は保障がなかったり、レスポンスが悪い場合もあります。無料プランと有料プランの違いを適切に判別し、商用サービスを提供するのであれば、APIも有料プランを使うようにしましょう。 他サービスとの並列利用 APIは一つのサービスに頼り切るのではなく、類似サービスを複数利用するのがお勧めです。例えば決済においても一つではなく、複数サービスに対応しておくことで万が一APIが一時停止した場合においても切り替えが容易になります。 APIの突然の停止はよくあることです。一ヶ月後に停止されると分かって慌てて開発するのではなく、あらかじめ複数サービスに対応しておくことで乗り換えが容易になります。突貫の開発ではリソース不足になったり、バグが入り込む可能性があります。あらかじめ複数の選択肢を持っておくことで、リスクヘッジできるようになります。 キャッシュ APIによってはキャッシュを禁止している場合もあるので注意が必要ですが、データ取得系のサービスについてはキャッシュを使うことで一時的なエラーを回避できるようになります。TwitterやFacebookなどのソーシャルサービスでも有効です。 APIは常にネットワークを使うのでデータベースに比べるとレスポンスが悪くなりがちです。キャッシュを使うことでユーザ体験を向上できます。 サービス利用者にキーを登録してもらう TwitterのようにAPIのコンシューマキー一つに対して10万ユーザまでしか認めていないケースもあります。そういった限界を超えるために、利用者が自分のコンシューマキーを登録してもらうという方法が考えられます。 他にもAPIキー単位でアクセス数を制限している場合も、APIキーを変えることでさらにアクセスできるようになります。APIの利用数が多いサービスで、利用者が開発者であればこういった方法も選べるでしょう。 APIキーを利用しないでも取れるデータを確認する APIキーは誰がアクセスしているかを特定するために使われます。そのためAPIキー単位でアクセス制限されることになります。しかしAPIによってはAPIキーを使わなくともアクセスできるものもあります。そうしたAPIにおいてはキーを指定しない方がアクセス制限にとらわれなくなります。 自社開発の道を探る 膨大なデータを持っているサービスを自社システムで置き換えるのは難しいですが、機械学習や画像変換など機能を提供するAPIであれば自社開発することもできるでしょう。初期についてはAPIを使うことでリリーススピードを向上させ、サービス規模が大きくなる際に自社開発にリプレイスする方法があります。 API提供側としては、規模や利用量が増えても使い続けてもらえるコストメリットが打ち出せなければなりませんが、利用側としては自社開発に乗り換える方がコストダウンにつながることもあるでしょう。 APIに依存したサービスは必然的にリスクが高くなります。かつてFacebookアプリの仕組みを使って急成長したZingaはFacebookのAPI制限が強まるのに合わせてヒット作を生み出しづらくなっていきました。また、Twitter向けに作られたURL短縮サービスの多くはTwitterは公式短縮URLサービスをリリースしたことで市場が縮小しています。 APIを使い続けることで事業スピードを上がるメリットもありつつ、完全に頼り切らない道を探ることもまたビジネス上のリスクヘッジにつながるでしょう。

改ざんを防止するJSONとして注目されているのがJSON Web Tokenです。署名することでデータの改ざんを防止しつつ、URLセーフな仕組みとなっています。JSON自体は誰でも閲覧できるのでセキュアな情報を送るのには適していませんが、改ざんしたとしてもそれを検証する仕組みが用意されていることで安心して利用できます。 そんなJSON Web Tokenがどういった場面で使われているのか紹介します。 セッション トークンの中にユーザIDであったり、ユーザ名、有効期限といった情報を持たせることで認証後のクライアントにセッションとして使ってもらいます。サーバ側ではセッションをデータベースで管理する必要がなくなります。 Cookieなどにデータを持たせておいて、アクセスの度にその内容をチェックすることで改ざんされていないか確認ができます。改ざんされていないのであれば、ユーザIDをそのまま利用できます。 セッションIDはユニークで単なる文字列なのが一般的ですが、その場合はセッションIDをデータベースに保存しておく必要があります。JSON Web Tokenを使うことでデータベースに保存することなく、安全なセッション管理ができます。 OAuth2トークン OAuth2トークンとしてJSON Web Tokenを使うことで、こちらもデータベースで管理する必要がなくなります。ただし有効期限だけを延ばすと言った操作はできないのでリフレッシュトークンを使ってトークン自体改める必要があります。 例えばGoogleのOAuthトークンはJSON Web Tokenになっています。公開鍵も配布されていますので、それを使ってトークンの検証ができるようになっています。 OpenID Connect OAuth2をベースにした認証プロトコルであるOpenID ConnectのIDトークンはJSON Web Tokenが使われています。ペイロード部分については任意の情報で構いませんが、ヘッダー部分については RFC 7515の中で決められています 。 メールアドレス確認 メールアドレスと有効期限をペイロードとしてJSON Web Tokenを生成し、メールアドレス認証用のURLとすればデータベースで確認コードを保存することなく、正しいメールアドレスであるという検証ができます。 改ざんはできないので別なメールアドレスを適用することはできませんし、自分のメールアドレスであればURLに含まれていても問題はないでしょう。また、JSON Web TokenはURLセーフになっていますので、URL中に含めるのも問題ありません。 JSON Web Tokenを使うことでこれまでデータベースに保存していた一時的なトークンや確認コードが不要になります。送られてきたデータを適切に検証すれば、その内容が正しいことが簡単に分かります。 なおJSON Web Tokenでは秘密鍵が重要になりますので、間違っても紛失しないようくれぐれも注意してください。また、BASE64デコードしているので情報はURLセーフである反面、含んでいる情報の1.5倍くらいに長くなってしまいます。あまり多くの情報を盛り込まない方が良いでしょう。

2018/2/27(火)に和田 卓人(@t_wada)さんに、テスト駆動開発(Test Driven Development, 以下TDD)の1日ワークショップを開催していただきました！ 本ワークショップは前半と後半で2部構成になります。 前半: TDDの講義およびライブコーディング 後半: TDDの実習およびt_wadaさん含む全員参加型のコードレビュー 特に後半の全員参加型のコードレビューはワークショップの特徴的な要素であり、なかなか無い機会です。人数が多いと参加者全員のコードレビューができない可能性があったため、今回は小規模(全14人)で開催しました。 以下でワークショップの内容を振り返り・議論となったポイントを記載します。 前半: テスト駆動開発とは？ 午前中は、テスト駆動開発についてt_wadaさんから説明いただきました。 講演の中では、まずはじめにKent Beck氏の著書"テスト駆動開発入門"の書き出しが引用されています： 「動作するきれいなコード」Ron Jeffriesのこの簡潔な言葉が、テスト駆動開発(TDD)のゴールだ。動作するきれいなコードはあらゆる意味で価値がある。 TDDのゴールである、 動作するキレイなコード に行き着くためには、大きく2つ道のりがあります。 上段のオレンジの道は。すぐ動かさずに念入りに設計・検討をして、その後にコードが動作するように直していく道です。これまでのソフトウェア工学では、オレンジの道が推奨されていました。しかし、日々の実際の開発ではコードを書いて始めてわかることもたくさんあります。また、考えに考え抜いてきれいなコードを書けても、実際にうごかしてみたら遅かった、といったケースもあります。言い換えると、予測可能性が低いということです。 現代のシステム開発では、周囲の環境が高速で変化していきます。たとえば、OSもアップデートされますし、周囲のソフトウェアのエコシステムやプログラミング言語が変化していきます。現代のソフトウェア開発では、このような変化の側面を考慮しつつ開発していく必要があり、オレンジの道は実体として険しいということが分かっています。 そこで、現代(2018年)のソフトウェア開発では、青色の道を辿っていく開発があります。今回のTDDは青色の道に沿った開発手法なのですが、青色の道には心理面での罠が3つあります。罠とは以下の感情を持ってしまうことです： 堕落: 動くからいいじゃないか、と考えてしまう 焦り: 作るものはいっぱいあるから、きれいにする時間はない 恐れ: せっかく動くところまできているのに、きれいにするために触ったら壊れてしまうのではないか TDDは最後の難関である「恐れ」に対処するための技術です。TDDのサイクルは以下の流れとなります： 次の目標を考える その目標を示すテストを各 そのテストを実行して失敗させる(Red) 目的のコードを書く 2で書いたテストを成功させる(Green) テストが通るままでリファクタリングを行う(Refactor) 1-6を繰り返す 実際のTDDでは、上記のサイクルを繰り返してコードを書いていきます。 ワークショップでは、 FizzBuzz問題 を例に、TDDのライブコーディングで説明がありました。 後半: ペアプログラミング + TDD の実践kkk 後半(午後)は、実際に参加者同士でペアを組んで、TDD実習を行いました。 テーマは、 Semantic Versioning(semver) で、semverを表すオブジェクトの実装およびmajor/minor/patchのアップデート方法を実装していくというものです。後半のプログラムは"1-1.5時間程度の実装の後に、全員参加型のコードレビュー"を2サイクル回すという流れで実施します。実装言語は自由であり、今回の参加者は Python/Ruby/Node.js/Java を選択していました。 通常の開発では1-2名のコードレビューを受けるのはあるかと思いますが、参加者全員の目で、さらに異なる言語のレビューをするのはなかなか無い機会です。参加者からも、「別の言語での実装は参考になる」という声があがっていました。 以下で、実際のコードレビューの質疑の中で、参考になるものがあったので共有します: 値を設定するメソッドのテストについて Q: たとえば、setVersionのような値を設定するメソッドのテストはどうすればいいのか？ A: getVersionのような対となるメソッドを利用して、テストできる。基本的にはリフレクションを使わない。 Q: その場合、getVersion自体が壊れてしまった場合は、setVersionのテストも壊れるがそれはしょうがないのか？ A: YES。受け入れるべきリスクと考える。 例外のテストについて Q: 例外のテストの書き方は悩んだが、どのような方法あるのか？ A: 例外のテストの書き方はいくつかある。try/fail/catchパターンというのは1つで昔からある。メリットとして、catchした後のアサーションも書けるので、例外の中身自体のテストもできる。また、アノテーションを使って、ある例外が出たらテスト成功という書き方もある。 どこまでモックすべきなのか？ Q: たとえばデータベースような状態を保持してくれるソフトウェアや、外部APIのように3rd Party側が状態を保持するようなケースで、どこまでモックすれば良いのか？ A: 1つのポリシとして、1台のラップトップに入るものは全て実際のものを使うようにしている。したがってデータベースは実際のものを使うが、3rd PartyのAPIが外部のものなので、モックする。 参加者からの感想 参加者からは以下のような声が挙がっていました: TDDのアンチパターンである、Assertionルーレット等、テストを書く上でのアンチパターンに名前が付いているのが面白いし、覚える役に立ちそうでした。 プログラミングやテストを行う中で発生するジレンマや葛藤に対し、分かりやすい視点・解説で論理的に説明下さり、見通しが立ったように思います。メンテナンス性を確保するために、機能を細分化することの必要性や意義についても認識が深まりました。 これまで業務等でRuby/Golangのテストを実装したり、テスト駆動開発に挑戦したことはありましたが、体系的に学ぶことは初めてで、とても勉強になりました。 上記のコメントからも、非常に有用なワークショップであったことが伝わってきます！ おわりに NTTコミュニケーションズでは、ソフトウェア開発の内製に力を入れています。テスト駆動開発のような汎用的なソフトウェア開発スキルを学ぶワークショップは、エンジニアにとって刺激的で、そして非常に有用なものでした。今回は参加者数を絞っていましたが、参加を希望する社員も多くいるため、t_wadaさんに協力を依頼しつつ、ワークショップを継続的に開催し、エンジニアのソフトウェア開発スキルを向上させていきたいと考えております。

綺麗なAPIとは開発者にとって理解しやすく、使いやすいAPIです。さらに提供側にとってはメンテナンスしやすく、拡張性も担保されたものになります。そうしたAPIを設計するのは容易ではありませんが、幾つかのルールを設けておくことでも十分に綺麗に設計できるようになるでしょう。 1. モデル型かアクション型か URLを設計する際にRESTfulに作るのがデファクトになっていますが、その中でもURLの作り方をモデル（ユーザ、商品など）にするか、アクション型（購入する、出席するなど）にするかで分かれます。どちらを採用するにしても明確な基準が必要です。両方を満遍なく取り入れると、非常に分かりづらいものになります。 一般的には GET /users/1 でユーザデータに対する操作であるといった形にします。つまりモデル型です。 となると POST /purchase で購入するというアクションを定義するよりも POST /orders で注文データを作成するといった形の方が自然です。 またログインにおいてもセッションデータを作成するという意味で POST /session のがいいでしょう。セッションはブラウザごとに一つなので複数形ではなく単数形になります。 POST /login といったアクションベースではない方が良いでしょう。 2. RESTfulの原則に従う RESTfulの原則はURLが操作する対象のリソースを指定し、それに対するCRUD操作をHTTPメソッドで指定するというものです。その原則を尊重することでコントローラの機能を分離し、ソースコードの可読性も高まります。 一つのリソースが複数の状態を持つ場合、例えばタスク管理で考えてみます。 タスクの一覧（/tasks） アクティブなタスクの一覧（tasks/active） 期限の近いタスクの一覧（tasks/limit） 完了にしたタスクの一覧（tasks/done） とした場合、これらはすべてGETで処理されるものになります。これをRuby on Railsでハンドリングしようとした場合、ルーティングを設定することで一つのコントローラ（TasksController）で処理することもできます。しかし、管理が煩雑になっていくでしょう。 そこで以下のように分離して考えます。 タスクの一覧（TasksController#index） アクティブなタスクの一覧（Tasks::ActiveController#index） 期限の近いタスクの一覧（Tasks::LimitController#index） 完了にしたタスクの一覧（Tasks::DoneController#index） こうすることで一つのコントローラの中に実装されるコード量を減らせるのと同時に、対象になるリソースの限定とHTTPメソッドによる操作というRESTfulの原則が維持されます。それぞれの機能は似たようなもの（ステータスが違う程度）になりますので、実際のコードは共通化されたライブラリを活用することになるでしょう。 3. バージョンをURIに持たせない APIのバージョンをどこに持たせるかは常に問題になります。URIに入れた場合、多くは /api/1.0/users のようになります。これは多くの場合、2.0になった時に1.0で動作するライブラリをコピーする必要が出るでしょう。同じようなコードが氾濫することになり、管理が煩雑になります。開発者としても一部は1.0、一部は2.0を使い分ける時に共通したURLが /api/ しかなくなってしまうのは不便です。 そこでHTTPヘッダーやクエリストリングの中にバージョン番号を持たせるのはどうでしょう。よりフレキシブルに変更したいならばクエリストリングになるでしょう。HTTPヘッダーであればURLは共通で使えるようになります。 サーバ側としても既存のシステムがまったく別物に置き換わることはそうそうありませんので、プログラム中でバージョン番号を判定するだけで処理できるようになるでしょう。 4. レスポンスにHALなどを採用する 単なるJSONでは情報が不足するようになっています。そこで JSON API などメタデータを追加するJSONフォーマットが望まれるようになっています。その一つ、 HAL はAWSでも採用されているフォーマットであり、今後デファクトになっていく可能性があります。 HALを使うことでページネーションがある時に次のリンクを示すことができたり、追加のメタデータを付与できます。JSON APIもまた有名なJSONに情報を付与するフォーマットで、必要に応じて採用する方を決定すればいいでしょう。 APIのレスポンスを変えるというのはそうそう簡単ではありませんので、バージョン番号を使ったり、フォーマットを指定した場合などに採用するのがいいでしょう。もちろん、これから作るならばあらかじめ採用を決めておくのが最良です。 5. POST/PUTでもレスポンスボディを返す APIを使った開発においてよくあるのがPOST/PUTでデータを更新した時に、最新のデータをGETで取り直すというものです。これは2回APIアクセスする必要があってムダです。POSTで作った、PUTで更新したデータについて、その最新の状態をレスポンスに含めるようにしましょう。 特にサーバ側で処理されるデータがある場合、クライアント側ではデータがどういった値を持つかは分かりません。その結果、GETでアクセスする必要が生じてしまいます。ネットワークはボトルネックになりやすいので、クライアントからのアクセスを少なく済むようなサーバ側の実装を心がけましょう。 APIを実装する上でポイントになる部分はもっとたくさんあると思われますが、今回は主なポイントを5つ紹介しました。初期リリース時点では綺麗でも、更新を重ねていく内に破綻していくのはデータベース設計でもよくあることです。データベース管理者が将来的な拡張性も見込んでテーブル設計を行うのと同様に、APIにおいても更新を考えた上でメンテナンス性や論理的破綻を起こさないような設計を行いましょう。

SwaggerやOpen API Specification（以下OAS）はAPIのデファクトフォーマットになってきています。特にこれらのフォーマットでドキュメントを作っておくと、関連するライブラリやドキュメントが自動生成できるのが便利です。 Swagger/OASを使ったモックサーバであったり、テスト環境やエディタなどをまとめて提供してくれるのが SwaggerHub です。Swagger周辺のエコシステムを活用したい方はぜひ使ってみてください。 SwaggerHubについて SwaggerHubはSwagger/OASファイルの編集とプレビュー、ドキュメント表示などに加えてモックサーバを立ち上げたり関連するサーバ、クライアント双方のライブラリが生成できます。 設定は公開することもできるので、そのままAPIドキュメントとして開発者に使ってもらうことができます。 仕組みとしてはGitHub風で、組織を作成してその中にプロジェクトを追加する形になります。 新しいAPIをイチから作ることもできますし、インポートにも対応しています。 テンプレートも用意されており、さらにSwagger/OASのどちらかを選択できます。なお、OASの場合は幾つかの機能が未実装になっています。 編集画面です。左側がエディタで、編集内容が右側に反映されます。こちらはOASでの記述となっています。 日本語も問題なく使えます。 APIのモックサーバを立ち上げることもできます。 サーバ、クライアントのライブラリ生成機能はSwaggerの場合のみ有効です。多くのプログラミング言語に対応しています。 SwaggerHubではユーザの作成した定義ファイルが公開されており、API設計を行う上での参考にもなります。また、モックサーバの立ち上げなどSwagger/OASを使った開発サイクルをサポートしていますので、ドキュメント以外の要素においてもSwagger/OASを活用していきたい時に役立つでしょう。 新規でこれから作っていく場合はもちろんのこと、既存のファイルをインポートすることもできます。Swagger/OASのエコシステムを活用する際にぜひ使ってみてください。 SwaggerHub Powerful API Design Platform, Built for Teams

こんにちは、普段は SkyWay の開発・運用をしている岩瀬( @iwashi86 )です。 先日、クラウドアカデミー 1 という社内勉強会で、SkyWayのドキュメントに適用している継続的インテグレーション(CI)および継続的デプロイ(CD)について講演してきました。発表資料は以下になります。 オンラインドキュメントへCI/CDを適用している話 from Yoshimasa Iwase 内容の要約 内容を3行でまとめるとこんな感じです： MkDocsを使って静的WebサイトをMarkdownで書いて生成 textlintで文章をテスト CircleCIを使って、ドキュメントを継続的テスト＆デプロイ 実際の講演では、前半でそれぞれの項目について詳細化して説明し、後半でライブコーディング形式で実演しました。 発表後の質疑や感想など 発表後の質疑応答コーナーで、いくつかの質問をいただきました。そこで上がった質問の1つとして、「本フローが適用できない文書はあるか？」というものがあります。ポエムなどの詩的な文書には難しいかもしれませんが、 textlintでは任意のルールを作成可能 であるため、適用範囲は独自に拡大可能です。実際には拡大せずとも、(特に)技術系文書向けに既存のルールが多く存在するため、それらを活用するだけでも品質の底上げは十分に可能です。 より便利にルールを適用するために、ルールを複数まとめている、Presetも公開されています。たとえば、日本語の技術系文書では このPreset が活用できます。 また、終了後の参加者の感想として、「実際に自分のチームでも使ってみたい」などのコメントをいただきました。本勉強会に参加するのは、エンジニアだけではないため、普段からプログラムに触れるメンバ以外にも印象的だったようです。 まとめ クラウドアカデミーという社内勉強会で、ドキュメントにCI/CDを適用する話を講演してきました CI/CDにはMkDocs/textlint/CircleCI 活用しています textlintは様々な文書に適用可能です みなさまも、文書の品質改善にCI/CDのフローを適用してはいかがでしょうか。 Enterprise Cloud に関わるメンバが開催している社内勉強会 ↩

皆さま、明けましておめでとうございます。2018年になりました。個人、企業ともに新しいチャレンジを行っていく計画を立てるのに良い時期です。そこで、APIという視点において今年はどんな年になるのか紹介したいと思います。 ECサイト オンライン決済において、PCI DSSへの準拠が求められています。これは商品売買に限らず、クレジットカードを入力するような決済処理全般において対応が必要です。これは2018年03月までに対応が必要になります。 PCIDSSとは｜日本カード情報セキュリティ協議会 従来、購入者がWebサイト上でクレジットカード情報を入力し、サーバサイドで決済を行うのが一般的でした。しかし、昨今の情報流出やセキュリティインシデントの発生に伴ってクレジットカード情報を受け取る場合にはPCI DSSの高いレベルでの準拠が求められるようになります。これは中小規模なECサイトでは負担が大きい仕組みと言えます。 そこで最近ではクレジットカード情報をAPIで決済サービスへ送信して、一時的に使えるトークンに置き換え、そのトークンと購入額で決済を行う仕組みが提供されています。StripeやSquare、PAY.JPといったAPIで提供されている仕組みを使うことで、ユーザビリティを損なうことなくセキュアな決済が実現できます。 2018年前半まではECサイトはPCI DSSへの対応に追われるでしょう。 銀行API 2017年05月に改正銀行法が成立し、APIを提供する努力義務が銀行業界に課せられることになりました。本来、APIで安全にアクセスすべきなのですが、銀行業界は閉鎖的であったり、技術的なイノベーションが遅れることもあって、スクレイピングによるデータ取得が横行していました。これは行儀の悪い仕組みであり、Webサイトのデザイン変更によってサービスが止まってしまうといったリスクもあります。 現在、銀行では特定企業と契約を結びながらAPIを利用できるようになっています。さらにマネーフォワードではみずほ銀行、三井住友銀行、住信SBIネット銀行に対して送金が可能になっています。これもAPIを使っています（ ついにメガバンクが「更新系API」を提供開始、マネーフォワードが経費精算振込で連携一番乗り | TechCrunch Japan ）。 2018年においても、この傾向はさらに強まっていくと考えられます。銀行のAPIは個人情報や資産に関係してくるので一般開放は難しいかも知れませんが、企業提携などによって使えるサービスが増えていくことでしょう。 GraphQL RESTfulの課題が幾つも散見されるようになってきました。それに対する答えの一つとしてGraphQLに注目が集まっています。RESTful APIをすべて置き換える存在ではありませんが、GraphQLを取得系APIとして公開するケースは増えています。 GitHub Universe 2017において、GitHubもGraphQLを公開しました。今後もこの流れは広がっていくと考えられます。 GraphQL | A query language for your API Open API Specification Swaggerを継承し、APIドキュメントフォーマットとしてOpen API Specificationが2017年07月にローンチしました。2.0と3.0には互換性がありませんが、コンバータは存在します。今後、ソフトウェアやサービスがOpen API Specificationに対応していくと考えられます。 APIドキュメントについては他にも幾つかのフォーマットが存在しますが、Open API Specificationが最もデファクトに近い存在になってきていると言えます。ツールや関連サービスなどのエコシステムが整ってきていますので、APIドキュメントをOpen API Specificationに対応させておくことで広がりを持たせられることでしょう。 Home - Open API Initiative OpenID Connect OpenID ConnectはOAuth2をベースにした認証技術となっています。IDトークンとアクセストークンの発行両方に対応しています。OpenIDは認証情報を引き回すことができ、アクセストークンを使えば外部サービスのデータを許可した部分においてだけ利用できます。 現在、多くのサービスにおいてOAuth2だけでなくOpenID Connectも提供されるようになっています。提供側としては両方を、利用する側としては必要な方を選ぶといいでしょう。2018年においてもこの広がりはさらに早くなっていくと考えられます。 OpenID Connect | OpenID JSON JSONの事実上、最後と言える仕様が2017年12月に公開されました（ 事実上最後のJSON仕様「RFC 8259」と「ECMA-404 2nd Editon」公開。UTF-8エンコード必須に － Publickey ）。ECMAとの統一も行われ、今後はUTF-8エンコードが必須になるということが決まりました。APIにおいてほぼデファクトになってきているフォーマットだけに、仕様が固まったのはAPI利用側/提供側双方にとってメリットがあるでしょう。 JSONをイチから作るケースはそうそうないかと思います。多くの場合、各プログラミング言語についているライブラリを利用することでしょう。JSONの仕様が固まったと言える状況なので、各ライブラリも最終版と言える状態になってくるのではないでしょうか。 APIのデータフォーマットにおいてはJSONの他、XMLやProtocol Bufferなど様々にあります。しかし最も扱いやすく、人に対してもある程度可読性が確保されているフォーマットとしてJSONは今後も利用が増えていくと思われます。 JSON APIを提供する、利用するのが当たり前になりつつある現在、2018年もAPIのエコシステムがますます広がっていくと思われます。金融系のような固い業界においてもAPIが浸透してきていますので、今年も多くの企業がAPI公開に踏み切ることでしょう。

APIを公開して新しい収益軸にしたいと考える企業が増えています。しかし、その際に何からはじめれば良いか分かっていない方も多くいます。今回はAPI提供の企画段階から考えていくべきポイントを紹介します。 自社だけの資産を見つける API公開する上で肝になるのが自社独自の資産です。独自性が強ければ強いほど、価値があり他社がおいそれと参入できないものになります。デジタルよりもリアル、その資産を取得するのに時間がかかったり、特殊な技能が必要、十分なお金がなければならないといった特徴があると有利でしょう。 例えば寺田倉庫では倉庫を持っているというのが最大の利点になります。Amazonは倉庫はもちろん、Amazonという超巨大Eコマースサービスを持っていること、他にも古物商や弁護士資格が必要な技能をAPI化するのも良いでしょう。 最小単位での利用を実現する 次にそれらの資産を細分化し、なるべく細かい単位で使えるようにしましょう。単位が大きい場合、それは月額の予算も大きくなりがちです。そうなると契約の締結なども大事になり、結果として大企業同士の提携レベルになってしまいます。それであればAPIという形をとるメリットが薄くなります。APIはロングテールビジネスとして考える方が分かりやすいはずです。 とは言えFinTech系では企業同士の提携によってプライベートAPIを公開しています。APIの特性によっても変わってくる点ではありますが、ターゲットを広く取るのであれば、利用単位はなるべく小さくすべきです。 前述の寺田倉庫であれば段ボール1個、1ヶ月単位での課金になります。AWSでは1万単位でのアクセスで数円であったり、少なく利用するユーザからは少なく、大規模に利用する企業からは十分に収益をあげるモデルになっています。 業務フローを自動化する 実際の業務はアナログで行うとしても、そこに至るフローをなるべく自動化しなければAPI化のメリットはありません。APIというインタフェースを用意したのであれば、その後のデータの流れも自動化していきましょう。APIをコールされるとメールが来て、それから普段の業務フロー…というのはナンセンスです。 APIを公開している企業において、社内フローが従来のままというのはよくあるケースです。これではAPIによる依頼増に対応できず、業務がパンクしてしまいます。API公開を計画するならば、現状業務の最適化についても検討すべきでしょう。 24時間対応できる部分を考える APIは24時間365日稼働しているのが基本です。リクエストは常時発生します。すべてのリクエストをリアルタイムに行っていく必要はありませんが、なるべくキューに貯めすぎない仕組みが必要です。クラウドソーシングを活用するなど、時間に依らない運用体制を確立すべきです。 人の手による作業が入る場合、その作業状況を返すAPIを用意したり、Webhookで完了を通知する仕組みを用意するのが良いでしょう。人の手で行っている作業がAPIとしての付加価値につながる場合もあります（サンサンの名刺管理など）。 標準技術を積極的に取り入れる 日本企業はオリジナルの仕組みが大好きです。しかしことAPIについてはオリジナルの仕組みは喜ばれません。今であればOAuth2やOpenID、RESTful API、CRUD操作というのが標準であり、使っていくべき仕組みです。 APIは自社でももちろん使いますが、基本的には他者が利用するものです。そうした人たちにとって標準技術の方が取り入れやすいですし、問題があった時の解決も早いでしょう。 内部の仕組みが整っていないままにAPIを公開したとしても、業務の負荷が増すだけです。まず社内のフローを見直し、API公開に対応できる自動化を推し進めなければなりません。 とは言え、APIは企業のIT化を進める上でも重要な観点になります。自社の資産を見つけ、それを新しい収益源に展開しましょう。

APIを新しいビジネスとして、新たな収益源にしたいと考えたとしましょう。通常のWebサービスであれば利用する度に課金したり、月額課金モデルなどが有名ですが、APIにおいてはまた別な観点で戦略を考える必要があります。 今回はそうしたAPI事業化に対する懸念点、調査すべき点を紹介します。 販売戦略を立てる どのような事業であってもゴールや販売戦略が必要です。特にAPIの場合、開発者でない人たちに対してその良さをアピールするのは非常に難しいという問題があります。そのため、営業担当者が積極的に売りづらい商材になりがちで、なかなか利用が伸びなかったりします。 そういった事態にならないよう、あらかじめどう販売するか入念に考える必要があります。特にAPIは利用する側に開発を強いるものです。できあがった製品を購入するのとは違うので、そういった点からもどう売っていくかを考えなければなりません。 APIファースト APIを戦略の軸において考えるならば、そのサービス全体がAPIで提供されているくらいの形で進めましょう。特にユーザ向けの管理画面では表示できる情報はすべてAPIでも取得できるべきです。そのためにはAPIファースト、APIありきで開発を行えば良いでしょう。 このような進め方はスマートフォンアプリであれば当たり前です。APIファーストによって、デバイスのUIという縛りをなくして、データ利用ができます。 ペルソナ 通常のマーケティングであればペルソナといえば個人ですが、APIが対象にするのはコンピュータになります。そのため、対象企業の事業や業種がペルソナになってきます。出版社や個人向け保険などであったり、決済やメール送信など機能単位で考える場合もあります。 ライバル調査 APIの場合、一度稼働しているものに対して乗り換えるニーズは強くありません。飛び抜けて安い、または使いやすいといった特徴が必要です。複数APIを織り交ぜることもできますが、それは希でしょう。 APIについては市場の独占化が強く行われるので、強力なプレイヤーが存在する市場は新規参入が困難です。 料金体系 日本企業においては予算を稟議にかけて承諾されると、その範囲内での出費が求められます。海外では1アクセスごとの課金など、運用してみないと予算がいくらになるか分からないものが多いですが、日本の商習慣に合っていないと言えるでしょう（現在は幾分認知されていますが）。 月額固定金額で利用できるのが日本企業にとっては理想と言えます。しかし、API提供側としては取り過ぎたり、逆にマイナスになる可能性も秘めています。なお、手数料型ビジネスである決済においては1トランザクションごとの課金が認知されています。向き不向きがあるかも知れません。 バランス型よりも特化型 ことAPIについて求められるのは単機能で分かりやすいものです。Webサービスのように様々な機能があって、ユーザが選択しながらサービス提供を行うのはAPIには向いていません。固定化された使い方をシステム連携で常時行っているのが一般的です。 将来的にAPIが増えていくのは構いませんが、最初については多くない方が良いでしょう。その単機能が市場に求められているかどうかで成否を決められる分、開発工数も抑えられますし、失敗時のリスクも下げられます。 APIは自動化されて動くので、料金を青天井にするのは利用側、提供側にとって大きなリスクになります。アラートを出したり、あらかじめ制限をかけておいて使えるようにするのが良いでしょう。 手数料型ビジネスが一般的に受け入れられているジャンルもあれば、そうでないジャンルもあります。自社で提供するAPIがどこにマッチするかを適切に判断しましょう。

APIはシステム連携で使われるため、一度開発してから頻繁に手を入れなくなるかも知れません。しかし常に新しい人たちが使っていくことを考えると、レガシー化して古い技術を使い続けるのも躊躇されます。そこで今回はAPIがレガシー化しないための方法を紹介します。 常に手を加え続ける APIは一度作って終わりではありません。むしろ放置してしまうと実装がどうなっていたのかを忘れがちで、半年や一年後にメンテナンスもできなくなります。その結果、メソッドを分けたりして、全体のバランスが悪くなります。 逆説的ですが、常にメンテナンスし続けることが結果としてAPIの寿命を延ばします。 フレームワークを積極的に使う APIは進化の速い技術です。特にスマートフォンが出てからOAuth2のような技術であったり、GraphQLなども登場しています。すべてを実装していてはあっという間に廃れたAPIになってしまうことでしょう。 もし自社でAPIを開発、提供するのであれば積極的に外部ライブラリを使っていくべきでしょう。そうすることで実装を薄くことが実現し、メンテナンスも容易になります。もちろん、その際には長期的に使えて自社要件にあったフレームワークの選定が必要になります。 APIゲートウェイの活用 APIはただJSONの入出力インタフェースを追加すれば良いわけではありません。負荷対策であったり、クォート制限、認証なども必要です。そうした部分まですべて自社開発しているといつまでもリリースできないかも知れません。 APIゲートウェイはそうしたAPIの根幹になる部分を提供してくれるサービスになります。また、システム自体はJSONインタフェースを備えていなかったとしてもデータを変換してくれる機能もあります。APIゲートウェイの活用がAPI戦略において大事なポイントになるでしょう。 ワークフローに合わせすぎない APIの設計に関わりますが、必要なワークフローをサーバ（API）とクライアントのどちらで持つかは大きな問題です。サーバ側の実装を厚くすると、クライアント側の実装は減らせます。ただしワークフローは変わりやすいことが多いため、影響を受けやすくなります。その結果、使わなくなるAPIも増えてしまうでしょう。そして新しいワークフローができるたびにAPIが増えていきます。 逆にワークフローに関係なく理想的なAPI設計を追求すると、クライアント側のコード量が増えていきます。スマートフォン、Webアプリケーション、IoTなどすべてにおいて同じような実装が増えていくのはムダな開発コストにもつながります。 難しい問題ではありますが、APIの独立性は寿命に大きく関わってきます。どちらかと言えば後者の方が長生きに、レガシー化しない傾向があります。 リリース直後は先進的であったり、標準的であったとしても時代の流れとともに新しい技術が生み出されていきます。そうした波に乗り遅れるとあっという間においていかれてしまうでしょう。特に標準技術が変わったにも関わらず古い標準のままであった場合、利用する側としては躊躇してしまいます。 APIは変化の激しい技術です。そうした波を乗りこなし、新しい技術も積極的に取り入れてください。

API開発する際にモックアップサーバがあったり、テストを行う際にスタブのライブラリがあると便利です。スタブはプログラミング言語に依存しますが、モックサーバであればJSONスキーマなどを使って立ち上げられます。今回はそうしたスタブ、モックサーバを紹介します。 heroku/dorante: stub an API from a JSON schema JSON SchemaをベースにAPIサーバのスタブを作成します。単純にJSON Schemaを適用するだけでも利用できますし、細かくコーディング（レスポンス内容をカスタマイズするなど）もできます。 heroku/dorante: stub an API from a JSON schema putan/stubon: stubon is simple dummy api server. 専用のJSON/YAMLフォーマットに沿って記述してスタブサーバを立ち上げます。 '/aaa/get': - request: method: 'GET' response: status: 200 body: result: 'OK!' SSLにも対応しているのが特徴です。 putan/stubon: stubon is simple dummy api server. byoutline/MockServer: Simple REST server that makes simulating API easy. Javaで作られています。JSONファイルでパス、メソッド、クエリを定義し、そのレスポンスを記述してモックサーバのベースを作ります。 byoutline/MockServer: Simple REST server that makes simulating API easy. change/facebook-stub: Dropin Facebook Javascript API Stub for testing FacebookのJavaScript API向けのスタブです。ネットワーク接続を伴わず、Facebookにアクセスすることもないので、利用者のソーシャル状況などに左右されないテストができます。 change/facebook-stub: Dropin Facebook Javascript API Stub for testing kosamari/api-stub: Simple, no dependency, temporary API for your prototype JSONフォーマットで記述した内容を元にスタブサーバを立ち上げます。機能は豊富ではありませんが、その分簡単に立ち上げられるのが便利です。 kosamari/api-stub: Simple, no dependency, temporary API for your prototype markvincze/Stubbery: Library for creating Api stubs in .NET. https://markvincze.github.io/Stubbery/ .NET用のスタブライブラリです。テストコード中にあらかじめ書いておくことで、ユニットテストで利用できます。 markvincze/Stubbery: Library for creating Api stubs in .NET. https://markvincze.github.io/Stubbery/ knuton/stubb: Specify REST API stubs using your file system. フォルダとファイルを使って実際にJSONファイルなどを配置し、その内容を読み取ります。例えば whales/GET.1.json といったファイルを用意します。コードと分離して管理できるのでメンテナンスしやすそうです。 knuton/stubb: Specify REST API stubs using your file system. endeepak/stub_on_web: Create stub urls to test external API integration Elixirで作られたスタブサーバです。Elixirで書かれた設定ファイルをベースとして、サーバが立ち上がります。 endeepak/stub_on_web: Create stub urls to test external API integration スタブとモックサーバは提供される機能が異なりますが、どちらもテスト時において役立つことでしょう。特にその言語のテスト環境において良いスタブライブラリがない場合にはモックサーバを使ってテストするのが良さそうです。

去る2017年11月22日、 五反田のDEJIMA にて Enterprise APIs Hack-Night #12「HRTech」 が開催されました。HRはヒューマンリソース（Human Resource）の略で、HRTechとは人事労務系テクノロジーになります。 今回はfreee社（山本 伶さん）とネオキャリア社（野海 芳博さん）にご登壇いただきました。 労務管理の効率化から人事労務のプラットフォームへ by 山本 伶さん@freee株式会社 freee社は人員が急激に増えており、山本さんが入社した頃（20人）と比べてなんと20倍にもなっています。その結果、起こっているのが人事担当者の業務多忙化です。毎月の給与はもちろんのこと、入社手続きや市民税県民税の対応などが頻繁に行われています。年末になるとよく知られている年末調整もあります。 本来、人事担当者は全社的な人員配置であったり、従業員のモチベーション管理などに注力したいのですが、日々の業務が多忙であるためにそうした本来すべきところに手が回らなくなってしまっているそうです。そうした細かいオペレーションを補助できるのが人事労務freeeになります。 人事労務freeeは最初、給与計算freeeとしてスタートしています。そしてe-Gov APIという総務省系のAPIに国内初対応し、入社手続き機能などを追加していった結果、現在の人事労務freeeとなっています。 人事労務でよくあるのが紙多すぎ問題です。役所などに届ける必要がある用紙などはすべて紙ベースという問題があります。それが一歩発展してもExcelの種類が増えたり、個人のナレッジに頼った運用が行われます。そして役所も縦割り社会であるために、保険事務所や年金事務所などがすべて別な場所にあって回るのが大変という問題もあります。その結果として業務フローが分断され、複雑になっています。 人事労務freeeではそういった問題を解決したいとのことです。最新の情報が一元管理され、かつPDFによるペーパーレス化が進められています。freee社自身、ペーパーレス化が強く求められているとのことです。給与明細の自動計算や、備え付けが必要な書類を自動で作成、保管しています。 ここからは未来の話になりますが、人事労務freeeが目指しているのは業務効率化の先にある本来人事が行うべき役割のサポートになります。最適な人員配置、生産性やコスト分析、採用サポート、評価制度の運用、ヘルスケアなど企業として投資すべき領域にも踏み出していきたいとしています。そのためにも、まずは現状の業務を徹底して効率化していく必要があります。 人事労務freeeや会計freeeの利点は企業におけるお金の動きのハブになっている点です。これらの情報を活かすことで、企業の全面的バックアップが可能になるのではないかとしています。現在、人事労務freeeではAPIを準備しており、それによって企業内のBIツールとの連携やチャット、タイムカードとの連携などが考えられます。山本さんはAmazon Dashボタンを使って出退勤を打刻できるボタンを作ってみたいと話されていました。 freeeを使うことで業務の効率化が可能ですが、さらにAPIを使うことによってHRTech業界全体の活性化を促していきたいとしています。とかく煩雑な業務になりがちな人事労務をホワイトな環境にし、多様な働き方を実現したいとのことです。 jinjerによる"人事"の見える化と共に描く未来 by 野海 芳博さん@株式会社ネオキャリア Jinjerは採用管理サービスを提供しています。日本全体における人口減少が続く中で、求人需要が増しています。しかし採用プロセスは各社複雑で、それにかかる時間も長くなっています。その効率化を支援しています。 当初、共通アカウントと呼ぶデータベースを構築し、それを中心として全サービスを疎結合で連携しようと考えたそうですがうまくいかなかったそうです。クライアントで解決しようとしすぎる結果、処理が長くなったり非効率的な処理によって負荷が増大してしまいました。現在、システム全体を見直しており、効率的なシステム構築が進められています。 Jinjerでは今後、組織管理や組織改編に伴う予約投稿など組織図の変更にも対応していくとのことです。また、大手の企業では自社内に人事系のシステムを構築していますので、それらとJinjerの採用管理サービスを接続していきたいとしています。 一例として紹介されていたのがエンゲージメントアラートです。従業員の出退勤時の打刻と同時に顔写真を撮影します。その際の表情を分析にすることによってエンゲージメントを7段階で判断しています。小さなチームであれば各メンバーの顔が分かるので問題ありませんが、数十人や百人を超えるチームでは全体の把握は容易ではありません。モチベーション低下やキャパシティオーバーなどを早期発見できるとしています。 ここからは未来の話ですが、登録されている組織図や就業規則を解析して、本当に組織の現状にあった就業規則なのかどうかを判断できるようになるのではないでしょうか。また、人員の組み合わせによってはパフォーマンス低下が推測されるといった人工知能の活用も考えられるとのことです。 API周りとして労務管理ではe-Gov API対応していたそうですが、使っていたバージョン1に対して最新版であるバージョン2は対応している項目が多いそうです。しかしバージョン2では状況照会ができない問題があり、現在対応を取りやめているそうです。 人材開発のトレンドキーワード by 土岐 哲生さん@NTTコミュニケーションズ株式会社 今月から人事に配属されたこともあり、まず人事業界の状況を分析されています。そのため、日本で行われている講演を400以上分析してみたところ、採用活動や働き方改革といったキーワードが浮かび上がってきました。対してアメリカではオキシトシン、心理的安全性、マイクロ・ラーニングといったキーワードが出てきます。日本では企業事例的な内容が多く、対してアメリカではより科学的分析やアプローチが話にあがっているとのことです。 海外ではミレニアム世代が中核メンバーとして育ってきており、従来の教育法は通用しなくなっています。そこで注目されているのが1〜2分の教育を毎日繰り返すマイクロ・ラーニングだそうです。他にも習得が遅れている人同士をマッチングして相互サポートする仕組みも注目が集まっています。 この後、懇親会が開催されました。人事労務はまだまだ手作業が多く、非効率的な業務が多い分野でもあります。そのため、テクノロジーによって改善できる余地が多い領域でもあります。また、各社の取り組みに興味がある方が多いようで、どういった施策がとられているのか熱心に話されていました。 Enterprise APIs Hack-Nightでは引き続きビジネスにおけるAPI活用をテーマにイベントを開催していきます。興味がある方は Connpassのページ にてグループに参加してください。新しいイベントが作られた際に通知メールが届くようになります。ぜひご参加ください。

GraphQLを提供する際にイチから構築する必要はありません。すでに各種プログラミング言語向けにサーバ実装が登場しています。今回は言語、フレームワーク別にGraphQLサーバ実装を紹介します。 Go neelance/graphql-go まだ開発途中ですが、2016年10月GraphQL仕様の全実装を目指して開発が進められています。 rgraphql/magellan リアルタイムストリーミングをサポートしたGraphQLサーバです。通信にはWebSocketを使っています。 Node.js graphql/express-graphql Node.jsのWebアプリケーションフレームワーク、Expressと組み合わせて利用するGraphQLサーバです。 const graphqlHTTP = require('express-graphql'); app.use('/graphql', graphqlHTTP({ schema: MyGraphQLSchema, graphiql: true })); のように記述することで /graphql 以下でサービス提供できるようになります。 apollographql/apollo-server Expressの他、Connect/Hapi/Koa/AWS Lambda/ZEIT Microと組み合わせて使えるGraphQLサーバです。 chentsulin/koa-graphql Koaと組み合わせて使うGraphQLサーバです。以下のように実装します。 const mount = require('koa-mount'); const graphqlHTTP = require('koa-graphql'); app.use(mount('/graphql', graphqlHTTP({ schema: MyGraphQLSchema, graphiql: true }))); Python alecrasmussen/falcon-graphql-server Falcon と Graphene を組み合わせて作られています。実行は次のようになり、単独でアプリケーションサーバとして動作します。 $ gunicorn -c server_config.py falcon_graphql_server:graphQL_api PHP Youshido/GraphQLBundle Symfonyのバンドルとして作られているGraphQLサーバです。フレームワークに組み込む形なので、若干コード量は多くなります。 Scala sangria-graphql/sangria-akka-http-example デモ実装なので完成度はそれほど高くないかも知れませんが、ベースや参考にすることはできそうです。サーバを内包していますので、以下のコマンドで立ち上がります。 $ sbt run GraphQLをきちんと実装している例はまだ多くありません。言語についてもGoやNode.jsが多く、それ以外の言語ではクライアントの実装くらいとなっています。今後GraphQLが広まっていくためにはサーバとして使えるライブラリが必須でしょう。

単一のエンドポイントで、クライアント側で指定することで任意のデータを取得できるGraphQLですが、ビジネスで利用する際に必ず注意しなければならないのがセキュリティでしょう。GraphQLを利用、提供する上での注意点を紹介します。 認証 GraphQLではサーバサイドのデータベースのようにID/パスワードのような仕組みは用意されていません。他のAPIと同様に、認証技術と組み合わせることができます。例えばOAuth2であったり、トークン認証になります。これらは自分で実装する必要があります。 そのため、REST APIとGraphQLの共存は難しいことではありません。取得（GET）についてはGraphQLを、データの追加/更新/削除はREST APIといった具合に使い分けることもできます。その際、どちらも同じ認証データを用いられるでしょう。 ネスト GraphQL特有の問題として、関連データのネストがあります。Eコマースなどにおいて、あるユーザが複数の注文履歴情報を持ち、個々の注文履歴は複数の商品データを持ちます。さらに個々の商品データは複数の在庫情報を持つかも知れません。そうした関連データを連結して取得できるのもGraphQLの特性ですが、あまり深くネストを指定できる訳ではありません。サーバ側の設定で変更できますが、デフォルトで2つまでというのが多いようです。 GraphQLはインタフェースであって、その背後にあるのは従来のデータベースになります。SQLで関連テーブルをつなげていくと、負荷が増してしまうのは当然です。運用時には注意が必要でしょう。 バリデーション GraphQLでは元々スキーマを定義してクエリを受け付けます。そのため、数値や文字列などのレベルにおいてはデフォルトで入力チェックが行われます。しかし文字列長であったり、メールアドレスやユーザIDのユニークチェック、パスワード検証のような仕組みは用意されていません。そういった特定のフローについては自分で実装しなければなりません。 とは言え、一度スキーマレベルでのチェックを通っていることで、サーバサイドでの実装はシンプルなものになるでしょう。 権限 GraphQLはスキーマが一つしかありません。そのため、ユーザ/グループごとにアクセスさせたいデータ、させたくないというデータがあるとコードですべて実装しなければなりません。この実装はかなり煩雑になる上、スキーマ上は構造が確認できる形になるでしょう。 そしてユーザが記述したGraphQLのクエリに対して、アクセスしていいデータかどうかを判別するというのはかなり煩雑な処理になるでしょう。今の時点では良い解決策がなさそう（権限毎にGraphQLのパスを分けるなど）なので、GraphQLは全体に対して共通仕様であると考えた方が良さそうです。 GraphQLはまだ新しい技術だけに、すべての仕様をきちんと把握した上で運用するようにしないと思わぬトラブルにつながる可能性があります。既存のREST APIとの棲み分けや、利用範囲の絞り込みなどを行った上で運用した方が良さそうです。

ついにOpenAPI Specificationがリリースされました。以前紹介した通り、文書構造が分かりやすくなったのが一番の特徴です。できることとしてはそれほど大きくは変わりません。 そこでこれまでSwagger.jsonで作ってきた内容をOpenAPI Specificationのフォーマットに整えるニーズが出てきます。手作業でやるのはとても大変なので、まずはコンバーターを使ってみましょう。それが Mermade Swagger 2.0 to OpenAPI 3.0.0 converter です。 オープンソース・ソフトウェアとして 作られています。 使い方 使い方としてはテキストエリアにSwagger.json（YAMLでも可）を貼り付けるか、Swagger.jsonをアップロードとして指定します。なお、バリデーションだけ行うこともできます。 内容を変換するとYAML形式で表示されます。 一番最初の行に openapi: 3.0.0 と書いてあるのが一番の特徴でしょう。 リクエストパラメータとレスポンスパラメータが同じ形式になったこと、リファレンスが統一されたのが利便性を向上させてくれることでしょう。 OpenAPI Specification対応について 現在、各ソフトウェアでOpenAPI Specification対応が進められています。その一つとしてSwagger Editorがあります。こちらは従来のSwagger 2.0はもちろん、OpenAPI Specificationにも対応しています。 今後、対応ソフトウェアはどんどん増えていくでしょう。また、今後はSwagger系サービスを作る際にはOpenAPI Specificationを基準に開発するのが良さそうです。 Mermade Swagger 2.0 to OpenAPI 3.0.0 converter

APIはApplication Programming Interface（アプリケーション・プログラミング・インタフェース）の略語です。アプリケーションやシステムを開発するためのインタフェースといった意味になります。 今でこそWeb APIもAPIと呼ばれたりしますが、元々APIというのはデスクトップアプリケーションで用意されている仕組みでした。例えばExcelを外部プログラミングから呼び出してデータ入力や出力をさせたり、プリンタドライバを呼び出して印刷処理をするといった具合です。これらはWindowsやmacOS、LinuxといったOSの中で動作する仕組みです。つまりWindowsやmacOS、それぞれのOSの中でしか動かない仕組みです。 Web APIは多くの場合、通信する仕組みとしてHTTP/HTTPSを採用しています。HTTP/HTTPSはインターネット通信を行う上で標準的な仕組みで、プログラミングを行うためのライブラリも多数存在します。HTTP/HTTPSを採用することで、Web APIはOSという垣根を越えて使えるようになっています。 Webサービスからスタート 元々Web API（以下単にAPIとします）はWebサービスと呼ばれていました。XMLをデータフォーマットとし、SOAPというプロトコルを使っていました。サービス内容を定義するWSDLという言語を用いていました。主に大企業同士がシステム連携するための仕組みとして作られていましたが、Webサービス提供側、利用側双方の負担が大きい（複雑である）ためにあまり普及しませんでした。 その後、Web2.0という単語が登場した辺りから状況が変わってきます。情報発信系に限定されますが、RSSフィードというブログの情報配信フォーマットができ、これによってWebサイトの内容をRSSフィードで配信する風潮が広がっていきました。さらにdel.icio.usやはてなブックマークといったサービスが外部からデータの投稿を許可する仕組みを用意したり、ブログサービスにおいてもXML-PRCという仕組みで外部から投稿できる仕組みができあがりました。 普及する上での大きな役割を担ったのがTwitterでしょう。当初、Twitterは閲覧、投稿などの仕組みの殆どがAPIで公開されていました。これによってTwitterを利用する開発者たちがこぞってクライアントアプリケーションを開発したり、関連サービスを生み出しました。TwitterはAPIによって成長したサービスの一つと言えるでしょう。他にもflickr、Googleマップ、Amazonアソシエイトなど多くのサービスがAPIをビジネスの成長に利用してきました。 Facebookアプリの台頭 次に大きな変化だったのがFacebookが自社プラットフォームを公開したタイミングだったと言えます。これまではTwitterのAPIを利用したサービスであってもTwitterとは別サービスであるという認識がされていました。対してFacebookでは、Facebookの中にアプリが展開できるようになりました。これによってユーザはFacebookの中に留まったままサービスを利用でき、サードパーティーアプリケーション開発者はFacebookが持つ膨大なユーザベースを活用できました。この仕組みによって最も成長したのはZinga（ゲーム企業）です。FarmVilleという畑を耕すアプリが有名で、友人の助けを得ながら進める仕組みはソーシャルゲームという分野を築いた立役者だったと言えます。 ただしこの手法はユーザのプライバシーに関する問題を提起することにもなりました。キャンペーンに応募するためにFacebookページにいいねすると、そのユーザ属性が見えるようになったり、広告のトラッキングにも用いられるようになりました。ユーザに成り代わってメッセージを送るスパムまがいのアプリも登場しました。Facebookでは問題が起きた時に都度、仕組みを見直しています。現在ではFacebookアプリと言う仕組みはあまり用いられていません。また、プライバシーを保護するためにユーザ自身が自分の情報公開を制限できるOAuthというAPIが普及するきっかけにもなったと言えます。 スマートフォンアプリの普及が後押しに さらにiPhone、Androidといったスマートフォンの登場もAPI普及に拍車をかけました。なぜかというと、スマートフォンは小さなデバイスなのでデータの保存領域はそれほど大きくありません。その結果、データをクラウドに保存し、それを参照する仕組みが必要になります。データの保存と参照について、APIを使うということです。アプリではデータを受け取った後、それらをUIとして表示しています。前述のWebサービス各社はもちろんのこと、今では殆どのスマートフォンアプリが何らかのAPIを用いているでしょう。 これによって自社アプリでしか使わない、プライベートAPIと呼べるような存在が増えています。自社アプリのデータを保存したり、参照するためだけに作られているAPIのことです。これまでWebサイトを提供する上ではHTMLをサーバから出力すれば良かったのですが、アプリではHTMLを使うわけではありません。そのため、アプリ向けにAPIを追加開発するケースも多くなりました。 しかしプライベートAPIではついセキュリティや認証周りが弱くなりがちです。アプリが出始めた当初ではゲームのチート行為も多く、サーバに不正なデータを送り込んだりすることも行われていました。プライベートAPIについても標準的なセキュリティ技術を用いたり、APIゲートウェイと言った仕組みを用いることでセキュリティレベルを引き上げることができるようになっています。 今やあって当たり前に そうしたAPIの広がりがあり、今やAPIを公開しない理由がなくなっています。コンシューマ向けに限らず、ビジネス向けにおいてもAPIを公開することでうまくいっている事例が増えています。幾つかのメリットがありますが、まずビジネスのスピードがアップすることがあげられます。従来のすべて自前で開発する主義を捨て、APIを使うことで開発工数や期間の低減が実現できます。また、企業提携においてもAPIが活用されるようになっています。お互いがAPIを利用し合うことで、素早い提携が実現できています。FinTech周りでは企業提携し、提携した企業だけに限定してAPI公開が行われています。 API周囲のエコシステムも充実してきています。前述のAPIゲートウェイはその一つで、APIを持たない企業に対してAPIを提供したり、社内システムを安全に外部公開することができます。APIを提供する敷居を下げることで、自社データ活用の幅を広げられるようになります。 APIの技術はここ20年くらいで一気に発展しています。特にここ数年ではビジネスにおける活用に注目が集まっています。ぜひAPIを公開、利用してビジネスを拡大させてください。

APIファーストが叫ばれる時代になって、企業間連携が多くなっています。しかしその前からシステム間連携がなかった訳ではありません。ともすればAPIではなく、旧来の手法でのシステム連携でも良いのではないかという考えも出てしまうでしょう。 そこで今回は旧来のシステム連携と現代のAPI連携の違いについて紹介します。 主に一対多だったシステム連携 よく知られているところでは全銀手順であったり、クレジットカードのCAFISがあります。これらは中央にサービスがあり、それを利用するために各社が実装して接続していました。このように一つの巨大なシステムに外部から接続する形が多かったのではないでしょうか。 もちろんAPIになってもサーバに接続するという形は変わっていません。しかしクライアント側は一つのAPIとだけ繋ぐのではなく、他にもニーズに応じて様々なAPIを使いこなすのが一般的です。場合によっては同じ機能（例えば決済、広告など）を状況に応じて使い分けると言ったことも普通に行われています。 プロトコルはHTTP(S) 旧来のシステム連携ではプロトコルも独自のものであることが多かったでしょう。そのため専用のハードウェアを買ったり、専用線を用意する必要がありました。それに対してAPIではHTTP/HTTPSを使うのが一般的です。 独自の仕組みがなくなり、一般化された技術を採用することでAPIの公開に対する敷居が低くなっています。どのような企業でも自由にAPIが公開できるようになったことでAPIファーストとまで言われるほど種類が増えています。 データフォーマットはXML/JSON 旧来のシステム連携では固定長のメッセージ文などがよく使われていました。ネットワークの速度が遅かった時代ではそれが最適でしたが、今はインターネット接続が高速化しています。その時代の中ではすでに化石化した技術と言えます。 API連携では共通フォーマットとしてXMLやJSONがよく使われます。最近ではJSONのが多いでしょう。また、速度やデータサイズを小さくしたい場合にはProtocol Bufferを用いていることもあります。多少冗長的だとしても人でも読みやすかったり、構造の理解が容易であること、独自ではなくデファクトの技術を採用するところに利点があります。 同時双方向ではないケースが多い 旧来のシステム連携ではサーバと接続する契約を結んでいたこともあり、データの送受信は双方向で行われることがありました。しかしAPI連携の場合はHTTPというプロトコルの問題もあり、双方向でないことが殆どです。 インターネット上に公開されたサーバに対してはWebhooksを用いた呼び出しもできますが、社内システム同士の連携になるとファイアフォールに穴を開けて対応することもあります。多くの場合はAPIの利用側が都度アクセスし、データを取得したり更新する形になるでしょう。 契約から利用できるまでのスケジュールが短い システム連携では互いのサーバを直接接続すると言った仕組みをとっていたため、そこに至るまでの経緯が長くなっていました。契約を締結し、ハードを準備して接続テストを行って…と数ヶ月かかることも少なくありません。 API連携においてそれだけのスケジュールがかかるのはビジネス的に致命的です。すでにできあがっているAPIであればキーの払い出しを即日に行ったり、サンドボックス環境はユーザ登録なしで使えると言った手軽さが重要でしょう。 かつては大手のシステムと連結するというのは特別なことで、投資も大きかったですが、今ではWebのフォームを送信するだけと言ったくらいになっています。連携すること自体は大きな問題でなくなっている現在、大事なのはその連携をどうビジネスに活かすかという視点に移っています。ぜひAPIファーストの視点をシステム開発に取り入れ、戦略的にITをビジネスに活かしてください。

企業におけるAPI利用を促進すべく、そのナレッジを共有するのがEnterprise APIs Hack-Nightです。9月7日に行われた #11 はAdRoll社にてAdTechをテーマに行われました。 こちらはそのレポートです。 プログラマブル広告の実現に向けたAdRoll APIの使い方 by AdRoll株式会社 志田 典道さん AdRollはリターゲティング広告を提供する企業です。リターゲティング広告というのは何かのWebサイトを訪問した後、別なサイトでそれに類似した広告が表示される仕組みです。ユーザの属性を知ることで別なサイトへ訪問している際でもターゲティングされた広告が表示されます。元々USベースの企業で2015年から日本の参入しています。主なクライアントはECサイトです。 技術的な素養をお話しすると、私たち全社員がDevOpsに関わっています。また、システムがすべてAWS上に構築されています。1,000を超えるインスタンスの管理者は1〜2名くらいで、それ以外は開発者自身が責任持って運用しています。プログラミング言語はPythonがメインです。また、AdRollではtdb（トレールDB）というオープンソース・ソフトウェアを開発、公開しています。 アドテク業界におけるAPI利用はかなり進んでいます。まず広告媒体からSSPへのリクエストは1000万PV/日というのもざらです。さらにそれが複数媒体あります。そういったアクセスをさばけないといけません。 さらにAdRollのようなDSP（デマンドサイドプラットフォーム）から入札情報がかってきます。現在、広告媒体からのリクエストからはじまってDSPが入札の有無を判断して広告の表示/非表示を決定するまで自動化が進んでいます。とはいえ、まだまだ手作業が多いのも事実です。 広告主とDSPの間には代理店が存在します。そこにマニュアル操作が多いです。例えばアカウントを開いたりキャンペーン設定を行う、KPIのモニタリング、レポーティング、GAとの比較などなど。広告代理店はDSPが複数ある中でまとめて管理しないといけない。DSPの分、広告主の分だけそういった作業が発生します。特に広告主は色々なDSPを使って比較したがるので広告代理店はとても大変です。 昔の広告と言えばテレビ、新聞、ラジオなど限られたメディアで、代理店は枠を頑張って確保すればOKでした。今はデジタル化が進んでおりWeb、アプリ、Facebook、テレビなどジャンルが多彩になっています。現在、これもまた気合いと根性でなんとかすると言う広告の現場は変わっていません。広告要件、KPI確認、配信面の調整、改善提案はマニュアル操作でも致し方ないですが、他のキャンペーン設定やクリエイティブ定義、入稿、キャンペーンローンチ、レポーティングはAPIで自動化できるのではないでしょうか。 自動化された広告はプログラマティック広告と呼ばれています。ここからどうやって実現していくか、何に注意するかを紹介します。まずプログラマティック広告でできることとして、キャンペーンの自動運用があります。人間が管理画面で設定するのではなく、定型化してデータをがさっと取り込んで設定を自動化します。次にレポート業務があります。パフォーマンスがどうだったか広告主に求められます。その際に管理画面にログインしてデータをダウンロードしてExcelで並べて…といった手間暇かかることが未だに行われています。これを自動化します。 そのためには自社および他社とのツール連携が欠かせません。そして自社のポータルシステムに統合します。そしてワンクリックでAdRollに出稿できる仕組みを作らなければなりません。未だに手作業でやっていることを考えるとプログラマティック広告に移行すべきだと思います。 ではそれを実現するにはどうしたら良いでしょう。まず最初に何を自動化したいのかを決めなければなりません。レポーティングだけでいいのか、ローンチまで含めてすべてなのかです。レポートを自動化するのであれば、複数の会社からデータを取得してローカルまたは他のシステムに入れる仕組みになるでしょう。なお、広告ベンダーのAPIはまだオープンになっていないことが多いですし、ドキュメントも不十分です。この点はベンダー選びの大事なポイントになるので、あらかじめ確認しておきましょう。 また、自分たちの振ろーが実現できるのかをシーケンス図にして確認すると理解が深まるのでお勧めです。誰がトリガーを実行して、誰がデータの受け手なのかといった内容をシーケンス図で確認しましょう。エラーが起きたときにどういったエラーコードが返ってくるのかも確認しておく必要があります。当社ではApigeeを使っていますが、Apigeeにはエラーを細かく出力する設定があります。 次にプログラマティック広告の注意点です。広告にはお金が関わっています。そのため自動化に失敗した時の検知を必ず設けましょう。そうしないと余計な予算がかかってしまったりすることがあります。全体のエラー率を把握し、エラー発生ポイントを見極める必要があります。エラー時のパターンを確認して、特定パターンの時に通知を投げるようにしましょう。よくあっては困るのですが、日本円のつもりがUSドルで設定していたなんてこともあります。 APIでの処理結果を手動で変更できるのか、さらにAPIで失敗した内容を手動で引き継げるのかも大事です。失敗した際のエラーについてもきちんとデータが返ってくる場合もあればFATAL ERRORといったメッセージだったりなんてこともあります。エラー一覧があると良いと思います。 最後にAdRoll APIについてです。AdRollには幾つかの製品がありますが、それぞれにAPIがあります。例えばCRUD APIは広告を作成したり入稿するときに使うAPIです。レポーティングAPIはレポートデータを返してくれます。EメールAPIはAdRoll Emailというサービスに関係しています。ニュースレターに登録して、幾つかページを閲覧します。そうするとこういう商品見てましたよね、とメールでのお知らせがくるサービスです。 オーディエンスAPIは、我々とSSPの間で共有化しているIDのテーブルがあります。これを付け合わせてユーザの属性情報や興味のある商品（DMP）とIDを付け合わせられるものです。プロスペクティングAPIは、この商品に興味があるかも知れないという解析結果に基づいて広告を表示します。 AdRollではデベロッパーポータルを用意しており、APIドキュメントやAPIに関するサポート窓口もあります。ぜひ使ってみてください。 Q. 実際に代理店に自動化してもらおうと思ったらどういう風に進めるのが良いでしょう。 現実問題として、代理店には殆どエンジニアがいません。やってもらおうと思うと外部に発注したりと大事になってしまいます。そこを手助けするソリューションベンダーがいないのかな、とも思うのですが。 サプライサイドからみたアドテクノロジー by Supership inc 大野 祐輔さん SSPは媒体側の存在です。広告枠を売りたいSSP側としてどんなテクノロジーを使っているのかを紹介します。私たちのテクノロジーセンターは90人くらいのエンジニアで回していますので、割とエンジニアがいる方ではないかと思います。そしてSupershipとしてはDSP/SSP/DMPを全部持っています。 まずは我々のサービスの一つであるアドジェネ、引いてはSSPの簡単な説明をします。SSPは前述の通り、媒体側の存在です。例えばau、グノシーなど広告枠はたくさんあります。Webならタグ、アプリならSDKを入れてもらうことで、その先につながっているDSPから広告をピックアップして出稿するのがSSPです。アドネットワークは独自の配信ロジックがあります。その配信先は各社独自のシステムです。例えばFacebook、Amazonなどです。アドジェネのSDKを入れるとそういった違いを吸収してくれます。 主な広告フォーマットについて 今は例えば以下のような広告フォーマットがあります。 バナー ネイティブ ネイティブビデオ ビデオ 二、三年前はバナーが多かったです。そんな中、二年くらい前からネイティブフォーマット（Facebook広告、Yahooなどタイムラインに表れる広告です。インフィードといったりもします）が増えてきました。さらにネイティブが静止画ではなく動画になったのが動画リワードです。ゲームオーバーになった時にこの動画を見ればコインがもらえるよ、といったものです。ユーザが必ず見てくれるのでかなり価値があります。Googleのアドモブもやっており、フォーマットが多様化しています。 アドジェネの場合、ビデオはWebサイトの比率が高いです。インプレッションは少ないですが、単価は高い傾向があります。ネイティブはAndroid、Webが多くなっています。ネイティブとバナーはWeb/iOS/Androidがほぼ同じです。単価は高いですが、ビデオは在庫がまだまだ少ない状態です。 買い付け手法について 主な方法はオークションで、オープンオークション/プライベートオークション/ヘッダービッディングなどがあります。去年まではほとんどオープンオークションで、例えばグノシーさんの枠買いたい人いますか、とフラットに聞いていました。去年くらいからPMP（プライベートに良い在庫を買い付けますという仕組み）が出てきました。これは海外では当たり前でしたが、我々は電通さんと電通PMPというサービスをはじめています。良い媒体社の良い在庫に出稿できる仕組みです。 最近、アメリカではヘッダービッディングが盛り上がっています。正直、バナーなどの広告はGoogleが市場の在庫を7〜8割押さえています。そんな中、Googleの仕組みをハックしてより高い金額で出すのです。今はWebサイトがあって、そこにJavaScriptのタグを入れる方式です。その結果、Googleに通信を押さえられています。ヘッダービッディングではGoogleのタグをハックしてより良い在庫を出します。さらにそれをサーバ側で解析して出すと言った状態になっています。 API活用について APIではありませんが、Ad Parts Collection（APC）方式によるスムーズな広告配信連携があります。様々な広告を配信するためには色々なベンダーのSDKを入れないといけません。そのため接続先が増える度にSDKを入れないといけない状態です。それを吸収する仕組みです。APIを用意している事業者も多いので、SDKレスでアドジェネを通じて同じフォーマットで返すようになります。媒体社側の実装が楽になります。媒体社によってはそもそもSDKを入れたくないというニーズもあります。そこで我々はAPIベースにしてパーツを返すので、後はそれぞれ最適な形で表示してくださいという形も行っています。 現在、APIを使った接続方式が売り上げの3割くらいです。残りの3割がRDPで、残りはレガシーな形です。みんなが楽できるように配信できるようになっています。RMPが良いのですが、それだけでは足りません。 先ほど言ったAPCについて深掘りします。これはSSPとADNW間の通信をAPI化するものです。各ADNWの仕様差分をAPCが吸収します。幾つかのアドネットワークをAPIで吸収しています。元々タグベースだったところもAPIで切り替えられています。なお、FacebookやAmazonにはかたくなに拒否されています。 広告フォーマット、配信手法の多様化している中で、API活用がアドテクノロジーにおいても進んでいくのではないでしょうか。 「ユーザ理解」実現のためのクロスDMPの活用 by 株式会社クロスリスティング 三木 武さん まずアドテクの構成です。ここではRTB（リアルタイムビッディング）という入札が行われています。DMP（データマネージメントプラットフォーム）はDSP側です。マーケティング活動を最適化するための「データ管理基盤」のことになります。 この時にいうデータというのはログデータ（アクセスログ）、CRM、顧客管理基盤、外部のデータ（買ってきたもの）などが挙げられます。DMPはそれらのデータを放り込む箱です。その結果をマーケティング施策に使います。利用先としては広告が多いです。他にはCRM系の施策（1to1型）、オウンドメディアの分析、改善などにも使います。 このDMPにはパブリックDMPとプライベートDMPがあります。自社のデータを格納し、運用するのがプライベートDMPです。トレジャーデータが有名です。プライベートDMPにデータを提供するのがパブリックDMPになります。多くのメディアの行動データ、広告配信結果データなどを持っています。 ユーザを理解する ユーザ理解とはすなわち、この人がどんな人かというのを知りたいということです。プライベートDMPでは自社サイトの行動ログ、メルマガに登録してくれているかなどです。Eコマースなら購入履歴や住所氏名などになります。 ただし、その人がサイト外でどんな行動をしているかは分からりません。パブリックDMPではそういった行動データを提供できます。例えばQ&Aサイトの閲覧ログ、検索クエリデータ、アンケートパネルなどです。郵便番号情報から世帯年収が分かるといった仕組みもあります。多くのDMPではブラウザのクッキーを同じユーザだと特定する目的で利用しています。 プライベートなデータは小さく、パブリックなデータは大きいです。この両者の重なっている部分を活用することがユーザ理解に繋がります。さらに重なっていない範囲においては類似ユーザと見ることができます。彼らは潜在顧客であり、これをオーディエンス拡張と言います。 まず最初にタグを設定します。コンバージョンが得られたユーザの特徴を分析します。大手企業を中心にプライベートDMPを構築し、よりユーザ理解を深めるために外部データとしてパブリックDMPと連携する動きが活発になっています。広告配信に活用する場合にはCookie Syncやビギーバックによる連携を行っています。 ユーザ理解を深めるための技術 ユーザインサイトを明らかにするには様々な情報が必要です。検索行動の分析、悩み事や困り毎、興味関心は何か（Q&Aやブログ記事の解析）、男性か女性か（属性分析）などです。 一般的なユーザ理解システムの流れとしては、まずユーザの触れているもの、読んでいるWebページ、購入したもの、検索キーワードなどを解析する必要があります。そして商品の関連性、相関関係などを特徴量、ベクトルとして分析します。最終的にアイテムDBを保持します。 次にユーザ履歴ごとにプロットして、この人らしさを出します。その結果としてユーザのクラスタリングが可能になります。ユーザの興味関心内容やユーザ属性をベクトル化し、クラスタリングなどの統計解析技術によりユーザを高次元空間にマッピングします。 解析例 例ですが、不動産サイトのユーザ像を把握することがありました。賃貸と戸建て物件ではユーザ層は異なるんじゃないだろうかという仮説があったのですが、実際に測定された訳ではありません。その結果として不動産購入においては女性が主導権を握っていることが分かりました。また、戸建て物件を探すユーザは国内旅行など経済面でゆとりがあることも分かっています。 他の事例として、プロバイダの解約予兆分析があります。これは引っ越しが解約原因であったり、地震保険や家具の新調など住まいの変化と因果関係があることが分かっています。さらに美容系サイトでのコンテンツマーケティングでは毎年3月にアクセス数が伸びるのが特徴になっています。カメラ購入ユーザの性別・年代別インサイトでは一眼レフはお洒落じゃない、小さいカメラが欲しいというニーズがあったり、60代男性は山登りやバードウォッチングに走る傾向があることも分かっています。 ユーザ理解を深めるためにはユーザの行動データを適切に解析する必要があります。そして要素技術としてはテキストマイニングや機械学習の系統が主流となっています。 この後、懇親会が開催されました。多くの方が情報交換されていました。 次回のEnterprise APIs Hack-Nightは11月、HRTech（ヒューマンリソーステクノロジー）をテーマに行われます。ご興味ある方はぜひご参加ください！

元々CMS（コンテンツ・マネジメント・システム）というのはWebサイト構築に使われてきました。有名なところとしてはDrupal、WordPress、MovableTypeなどがあります。いずれもHTMLを出力するもので、ブログや一般的なWebサイト構築に使われています。 そんな中、最近ではAPIを公開し、HTMLを使わないタイプの利用が進んでいます。HTMLを全く出力しない、ヘッドレスCMSと呼ばれるタイプのCMSも出てきています。 配信先がWebに限らなくなってきた このようなAPI化が進む大きな要因としては、コンテンツの配信先がWebに留まらなくなってきたことが挙げられます。特に大きいのはスマートフォンアプリでしょう。数年前であればWebViewを使ってヘルプやよくある質問、リリース情報などを配信するケースもありましたが、最近ではAPIを使うことでよりネイティブな表示を行うケースが増えています。 Webとアプリ、両方に同じ情報を発信したい時にもCMSをベースにすると便利です。元々Web向けの機能はありますので、追加としてアプリをサポートできるようになります。管理画面が同じなので、運用コストも増えません。 システム連携の重要性 これまでCMSを使いつつEコマースやコミュニティサイトを立ち上げたいと思ったら、プラグインに頼る方式になっていました。しかしプラグインが専門のソフトウェアに敵うケースはなかなかありません。やはり機能の不足感を感じてしまうでしょう。 そうした中でAPIを用いた連携であれば、専門のソフトウェアとCMSを柔軟に連携させられるようになります。すでに数多あるEコマースシステムを置き換えるようなプラグインを開発するのではなく、Eコマースシステムが不得意とするCMS機能についてだけ連携するような形です。お互いの得手不得手を補い合うことで、より魅力的なサービスが実現できます。 便利な管理画面 CMSの魅力と言えるのが管理画面です。コンテンツをただ書くだけでなく、承認機能であったり、メタ情報の追加などもできます。公開日時の設定やパスワードロックなども可能です。こうした機能をイチから作るのはとても大変で、APIを介してCMSを利用することで手軽に手に入るようになります。 APIを使う場合、テーマやウィジェットなどのUI部分については利用できなくなります。柔軟性を得られる一方でCMSで元々提供されていた便利な機能も幾つか使えなくなります。そうした点に留意しつつ自社システムに組み込んでいく必要があるでしょう。 異なるUXへの対応 前述のWebとアプリの違いはもちろん、スマートフォンとデスクトップのWebブラウジングもまた異なるユーザ体験が求められます。スマートフォンではSPA（シングルページアプリケーション）のように動くものが求められたり、より途切れない画面遷移が理想とされます。 そうしたデバイスの違いはレスポンシブWebデザインによってUIで埋めることはできます。しかしクリックやタップなどの違いを吸収するのは大変です。無理にWebでアプリのような動きを再現するのではなく、APIによってコンテンツを各デバイスに配信し、表示やUXは各デバイス毎に最適なものを実装するのも一つの解決策となってきています。 CMSがAPI化されることで、よりコンテンツにフォーカスした運用が求められるようになります。また、CMSでWebサイトを構築するという従来の目的に留まらず、アプリや他のシステム向けのコンテンツ配信など幅広く活用が考えられるようになります。CMSを画像や動画、テキストなどのアセット管理に使ったり、コンテンツ配信元にしたシステム構成を考えると、従来よりも可能性が広がっていくのではないでしょうか。

社内人的リソースをよりよく活用するためにHR管理は欠かせません。人事に関わる方にとっては限られた社内リソースを十分に活用するために頭を悩ませているはずです。 今回はHR系サービス各社の提供するAPIをまとめて紹介します。 People HR HRに関する様々なサービスを提供しています。従業員の管理から評価の可視化、求人管理なども行えます。スマートフォンアプリも提供しています。APIはRESTfulになっています。 HR Software from People HR | HR Systems | Try for free | Cloud HR Software SmartHR for developers 従業員の登録、管理に加えて部署や雇用形態などをRESTfulに操作できます。WebHookにも対応しているので、入社した際などのタイミングでチャットへ通知したり、別なシステムを呼び出すと言ったことが可能です。 SmartHR for developers BambooHR 中小規模の組織にあったHRを提供しています。従業員管理、求人管理、メールによる新入社員のフォローアップなどの機能があります。WebHookも備わっているので、チャットなどのシステムと連携できます。 HR Software for Small & Medium Businesses | BambooHR エムケイシステムのマイナンバー マイナンバー管理システム「マイナde社労夢」で使えるAPIになります。マイナンバーの登録、管理ができるAPIになります。 外部連携API一覧 – エムケイシステムのマイナンバー 日本では日本ならではの人事の仕組みがありますので、海外のシステムをそのまま導入するのは難しいかも知れません。とは言え、海外企業のが伸びている状況を鑑みると、人事の仕組みにおいても海外から学べることは多数ありそうです。 HRにおいてもAPIを使って既存システムと連携したり、より自動化を進めていく傾向があります。人的リソースの活用、従業員の満足度向上のために人事システムからどういった働きかけができるのか、APIから現状を見直してみるのも面白そうです。