CData Software Blog

クラウド連携のCData Software の技術ブログです。

Horizontal SaaS 647種類のAPI提供状況を調査:そこから見えてきた国産 SaaS APIの今

こんにちは! CData Software Japan で API Horic 担当の 杉本@sugimomoto です。

みなさんは SaaS比較サイト BOXIL が公開している「Horizontal SaaS カオスマップ」というものを見たことはありますか?

f:id:sugimomoto:20200607162339p:plain

ボクシル運営のスマートキャンプ、最新SaaSカオスマップ制作 - SaaS業界レポート2019市場規模など先行公開 より

国内SaaSサービス最大手の比較サイトを運営しているだけあって、600種類以上のSaaSがカテゴリ毎にわかりやすくまとまっているカオスマップです。SaaS導入を検討している方であれば見ておいて損は無い資料ですね。

私も大好きな資料なんですが、どうしても物足りなかった要素が1つあります。それはAPIが提供されているかどうかわからない!」という点です。

以下の記事でもある通り現在の SaaS にとって「API」というのは重要なファクターの一つです。

www.itmedia.co.jp

SaaSでは「外部のソフトウェアとつなぐことができるのは当然」という価値観があり、API連携に消極的なものは敬遠されるからだ。

このようにカオスマップになるほど多様なサービスが溢れている状況では、何かしらの手段を用いてそれぞれの連携を構成しなければ、せっかく高機能なSaaSを導入したとしても、そのパワフルな機能を十分に活かすことはできません。

そこで個人的興味と趣味、そして私自身が様々なAPIを触っている経験から生じた「疑問」から、この600種類以上にわたるSaaS一つ一つのAPI提供状況を調べ上げてみました!(なお、一個人の趣味であり、業務ではありません)

f:id:sugimomoto:20200607162353p:plain

この記事ではその調査結果から見えてきた、SaaS APIの現状、海外SaaSと国内SaaS それぞれのAPI提供状況の違いに迫ってみます。

そして、せっかくなのでこの一覧をパブリックに公開します! 以下のURLから作成したGoogle Spread Sheetにアクセスできますので、是非見てみてください!

docs.google.com

もちろん「API調査リストなのに、このリストをAPIで取れないなんてイケてないよね?」みたいな方のためにも、このAPIリストを取れるAPIを作って公開しています!(もはや何がなんだか) なお、作り方はこちら

horizontalsaasapi.azurewebsites.net

f:id:sugimomoto:20200608110252p:plain

なぜこんな調査をしたのか?

それではこのAPI調査を行った理由・背景、そしてそれを踏まえてAPI調査を行ったことで見えてきた「国産SaaS APIの今」をお伝えしていきたいと思います。

私はクラウドサービス連携用のコネクタ・ドライバーの開発・テクニカルサポートを担当していることもあり、普段ひたすら国内SaaSクラウドサービスのAPIをウォッチしています。

日々様々な情報をウォッチしていると、プレスリリースなどで「API連携しました!」とか「APIの提供を開始しました!」とよく見かけます。そこでワクワクしながらWebサイトにアクセスしたりするのですが、API仕様書が見当たらなくて「どんなAPI連携をどうやって実現できるんだ!?」ということがたくさんあります。

特に国産のクラウドサービスで多い印象があり、度々そういう状況に遭遇するので

「なんか国産SaaSって海外SaaSに比べてあまりAPI提供してない? 仕様書とかこんなに公開しないものなの? APIを試してみたいのに、トライアルが無いなー?」

f:id:sugimomoto:20200608113710p:plain

という疑問を常日頃持っていました。

私は触ったことがあるAPIをあげればおそらく200種類近く、API仕様書を見たことがあるものも含めれば300種類以上はありますが、これは漠然とした疑問であり、何一つ数字的根拠はありませんでした。

ただ、闇雲にSaaS APIを調べても、現状世の中には驚くべきほどSaaSが出回っているので、きりがありません。

そこで私も知っていて、かつ日本でも多くのユーザーの方に認知されている SaaS比較サイト BOXIL が公開している「Horizontal SaaS カオスマップ」を元に調査してみよう! と思ったのが今回の調査の始まりでした。

なので、今回の一覧にはAPIの情報だけでなく、国産 SaaS なのか否か、トライアルは提供しているのかどうかも含めて記載しています。

調査結果

それでは、先にあげた疑問に対して、このリストからどのような見解を得ることができたのか? 分析結果も含めてお届けしたいと思います。

ちなみに分析には Microsoft が提供するBIツールの「Power BI」を使用しました。

全体状況

海外SaaSと国産SaaSをそれぞれ比較する前に、まず全体状況を見てみましょう。

f:id:sugimomoto:20200608101632p:plain

今回分析の対象としたサービスは647種類。カオスマップには実際680種類ほどロゴが並んでいますが、重複しているサービスを除いたところ、647種類となりました。そのうち、487種類が国産のSaaSです。

この647種類のうち45.6%、およそ半数が何かしらのAPIをすでに公開・提供している、という結果になりました。

アーキテクチャについてはRESTが圧倒的で、認証方法はOAuth(1,2も含め)最も多かったです。(ただし、API KeyとAPI Tokenの何が違うねん、と言われると結構微妙です。ここはリファレンスに書かれていたものに準拠します)

ちなみに完全に個人的な情報ですが、この一覧の中で過去に私が触ったことがある、試したことがあるAPIの数は59件でした。まだまだ道のりは遠いですね。

API提供状況は海外SaaSが90%超に対して国産SaaSは約30%に留まる

次に国産と海外それぞれのSaaSAPI提供状況にどれくらい差があるかを見てみました。

ただ、上にも書いてありますが、前提として母数が違うことは改めて押さえておきましょう。全体のSaaSのうち487種類が国産です。

f:id:sugimomoto:20200608102052p:plain

それでも、このAPI提供状況については驚くほど大差がつきました。海外SaaS の9割以上APIを提供しているにも関わらず、国産は3割程度:151件に留まります。

もう一点考慮するべきは、海外に関しては導入数含めかなり大きめでグローバル展開している製品が多いという点です。これはおそらくBOXILさんが国内でも提供および使われている海外SaaSという点に重きをおいているからではないでしょうか。

ただ、私が感じていた「海外のSaaSよりも、APIがあまり提供されていない」という感触は間違いないように思います。

ちなみにカテゴリ別に国産のAPI提供状況を絞った場合、「健康管理」「MDM」「iPaaS」「IS」「イベント管理」「リファラル」「SSO」「リファレンス」「AI面接」の分野に関してはAPIが提供されていませんでした。このあたりはAPIを公開することで、他社に対して優位に立てる一要素になるかもしれませんね。

1ページ目

f:id:sugimomoto:20200608102323p:plain

2ページ目

f:id:sugimomoto:20200608102336p:plain

国産SaaS APIのうち43%はAPI仕様書が非公開

続いて、API の Architecture(RESTやSOAPなど)を比較してみます。ここで注目したいのはArchitectureそれ自体だけでなく、そのArchitectureを確認できるリファレンス・API仕様書が公開されているかどうか? です。

f:id:sugimomoto:20200608102410p:plain

こちらも驚くべき結果となっていて、国産 SaaS では161種類APIが提供されていますが、そのうちの「43%はAPI仕様書が非公開」となっていました。

調査した所感では、機能一覧には「API連携」の記載があるにも関わらず問い合わせが必須であったり、パートナー向けのみに公開しているといった方式が目立ちました。

Architectureの種類に関しては圧倒的に「REST」で、これはまあ間違いないかなと思っていました。大きく違うとすれば、RPC Likeなものが、国産は多いかなという印象です。

なお、私が好きなODataベースで公開している国産SaaSは一つもありませんでした。寂しい。

できれば、OpenAPI Spec や Postman Collection、SDKの提供状況みたいなものも見てみたかったところですね。その辺は少しだけMemoでも触れています。

トライアルの提供状況について

次にトライアルの提供状況です。このグラフはAPIを提供しているSaaSのみに絞ったものです。

f:id:sugimomoto:20200608102836p:plain

面白いことにここで大きな差は見られませんでした。SaaS はトライアルで試してもらう、というカルチャーが国内でも根付いているなという印象です。

なお、国産SaaSに絞ってみると、APIを提供しているサービスの方が、同様にトライアルも提供している割合が多いようです。

ところで、なぜトライアルについて調査したのか? も伝えておこうと思います。私が好きなAPIに関する資料の一つに「KPIs for APIs」というスライドがあります。

www.slideshare.net

このスライドの中で資料でAPIをより使ってもらうために必要となる指標の一つとして「TTFHW」というものが紹介されています。

f:id:sugimomoto:20200607162437p:plain

「Time to first "Hello World"」

そのAPIを使うために、「トライアルを取得し、API Referenceを確認して、認証を通して、データにアクセスする」ここまでの一連のプロセスに要する時間、

つまり開発者が「Hello World」を行うまでにどのくらいの時間を要するか? という指標です。もちろんトライアル提供だけがこの指標に関わるわけではありませんが、仕様書が公開されているかと同様に開発者に対するDX(Developer Experience)として大事なものの一つでしょう。

なお、このトライアル可否は「APIを試すことができそうかどうか?」という方針の元決めているので、30日間トライアルやFreeライセンスが提供されているSaaSをTrueとしました。いわゆる営業さんが無料で「デモ」をしてくれる、みたいなものは対象外としています。

まとめ

今年のGWから開始して、およそ1ヶ月ほどちまちまと調べ続けていたのですが、思った以上に大変な作業だったので、こうして正式に公開することができて、とても嬉しいです。

(早ければ1時間くらいで50件ほど調べることができるんですが、つまると1つで1時間かかったりしますからね・・・。あと1時間もやるとさすがに飽きる・・・。)

なお、今回のレポートで国産SaaSはダメダメだよ、とか言うつもりはサラサラありません。

むしろ国産 SaaS にとって APIの分野はまだまだ伸びしろに溢れている、攻めるべき領域かつ仕様書一つ公開するだけで大きく他のサービスに対して優位に立つことができる、ということが見えたのは大きなポイントだったと思います。

昨今はクラウドETLや国産 iPaaSの領域も盛り上がってきて、日に日にAPI連携の重要性は増してきていると肌で感じます。私の会社の製品でも連携先・コネクタは国内国外のサービス問わず拡充させていきたいなと思っているので、このレポートがさらなるAPIエコシステム拡大の一助になれば嬉しいなと思っています。

補足:調査方法について

補足として、この調査をどのように行っていたのかについて書き残しておきます。

ちなみにBOXILさんは一覧表としてこのカオスマップを公開していないので、まずは全部のロゴマークからサービス・製品名をリストアップし、そしてサービスを一つ一つGoogle で調べて、というプロセスをたどっています。

ここで言うAPIとは何か?

APIと言っても色んな種類があるので、私が調査するための定義としたものをお伝えしておきます。

それは「そのサービスの外部からリクエスト可能なプログラミングインターフェース」です。

「外部から」というのが重要であると考えています。例えばPluginやアドオンのようにそのサービスの内部で拡張開発を行うためのAPI、そのサービス自身が外部のAPIに対してリクエストを行うための機能はここでは対象外としました。

ETLツールやBIツール・iPaaSのHTTPリクエスト用コネクタ、チャットボット開発用の組み込みSDK、WebHookも対象外です。そのETLツールが管理用として提供している外部からリクエスト可能なAPIなどは対象としています。

Architecture

API ReferenceにRESTとかSOAPとかODataとかGraphQLとかと書かれていれば、それを尊重しています。複数存在する場合は、メジャーっぽいものを対象にしました。

書かれていない場合は、仕様書をいくつか見て、URIリソースが名詞ベースで、各HTTPメソッド(GET・POST・PUT・DELETE)を利用している場合、RESTとしました。

URIが動詞かつ全エンドポイントがPOST、Bodyでメソッド名を送る、などの場合には「RPC Like」。RESTとRPC Likeが混合されているAPIも多いですが、ベースがRESTアプローチだなと思ったら、RESTとしています。

この辺は人によって色々と意見があるかもしれないですが(私もある)、一つの観点として見てもらうのがいいかなと思っています。

Authentication

認証方法については、いくつか存在する場合は、代表的なものを取り上げています。OAuthとかBasicであればいいんですが、結構このあたりは独自のアプローチを取っているサービスが多いイメージでした。

API Key、API Tokenの扱いについては一番悩むところで、ドキュメントにかかれているものをとりあえず尊重しています。(Access KeyとかはAPI Keyに統一したつもりです)

OAuth は 1.0 と 2.0 がありますが、Referenceに書いてあればそれを記載していますし、書いていなければただの OAuth としました。

ここ違うぞ! ここ公開しているよ! とかがあったら

私のTwitter もしくは、sugimotok@cdata.com までご連絡ください。

Special Thanks

このロゴをひたすら調べる中で、Twitter上でとてもたくさんの方に助けてもらいました。みなさんのご協力がなければこのリストは完成しませんでした。

ここで改めて御礼申し上げます! ありがとうございました!