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から現状を見直してみるのも面白そうです。

FinTechの世界が拡大していく中で、お金を送る、または受け取るというごく基本的な行為についてもAPIが登場しています。APIを使って送れるようになれば、より高速でシステマチックに金融情報のやり取りが進むようになるでしょう。 今回はそうした送金、お金の受け取りをAPIで提供するサービスを紹介します。 TransferWise API Documentation グローバルな送金サービス、TransferWiseのAPIになります。日本円からポンドなど、通貨単位を超えた送金が可能です。 TransferWise API Documentation Omise: Transfer (送金) API リファレンス Omiseは決済サービスですが、払い戻しや返品処理に伴う送金処理がAPI経由でできるようになっています。 Omise: Transfer (送金) API リファレンス ネットショップの送金・返金業務を効率的に「GMO-PG送金サービス」 | GMOペイメントゲートウェイ ECサイトにおける返金処理、送金処理を効率化するためのAPIを提供しています。一度入力した口座情報は口座IDとして管理されます。 ネットショップの送金・返金業務を効率的に「GMO-PG送金サービス」 | GMOペイメントゲートウェイ 銀行振込APIの使い方 | 経費サポート｜経費精算システム「MFクラウド経費」｜サポート｜経費精算システム「MFクラウド経費」 住信SBIネット銀行/みずほ銀行/三井住友銀行向けに給与の送金処理がAPI経由で可能です。各金融機関のAPIをマネーフォワードのサービスが呼び出す形です。 銀行振込APIの使い方 | 経費サポート｜経費精算システム「MFクラウド経費」｜サポート｜経費精算システム「MFクラウド経費」 BizSTATION（BizSTATION／BizSTATION Light） | 三菱東京ＵＦＪ銀行 法人向けに送金を含めたAPIが公開されています。なお一般顧客向けにも今秋リリースが予定されています。 BizSTATION（BizSTATION／BizSTATION Light） | 三菱東京ＵＦＪ銀行 お金という企業における最重要な資産を取り扱うとあって、セキュリティや不具合が起きた時の保証などが大事になるでしょう。また、担当者ごとの取り扱える金額であったり、エラー検出、上長による承認処理を介する場合もあります。 ミスをすると大変なことになる可能性がありますが、それだけに非常に大きな手間暇がかかっていた分野でもあります。APIによって革新的な進歩を遂げる可能性もあるでしょう。

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 - ブロックチェーン自体は一社、自社だけで導入しても大きな価値を見いださないでしょう。他社であったり、ユーザ間での決済が発生する部分などに導入することで経済圏が形成できるようになります。様々な目的で利用できますが、今回紹介した各サービスで紹介されている事例などを見ることで、自社における利用法が想像できるのではないでしょうか。