ID管理プラットフォームのAuth0、急成長の秘密をCEOが語る

ID管理ソリューションを展開するAuth0のCEOが来日した。来日に合わせて、ThinkITでは単独インタビューを行い、2013年の創業以来続いている成長の秘密を語ってもらった。

インタビューに応じてくれたのはCEOのユーへニオ・ペース（Eugenio Pace）氏と日本のカントリーマネージャーである藤田純氏、そしてAsia Pacific担当のディレクター、リチャード・マー（Richard Marr）氏だ。

左からマー氏、藤田氏、ペース氏

自己紹介をお願いします。

ペース：私はAuth0の共同創業者でCEOのユーへニオ・ペースです。出身はアルゼンチン、Auth0を創業する前はMicrosoftで働いていました。Microsoftに入ったのは2000年で、アルゼンチンで2年間働いていましたが、関わっていたプロジェクトが成功していたためにレドモンドの本社に移ってプロジェクトを続けることになり、2002年にアメリカに移住しました。本当は3年の予定でしたが、どんどん延長されていって結局10年ほどレドモンドにいることになりました。最後の5年くらいは、Azureに関わっていました。特にデベロッパーが「クラウドに移行できないのはなぜか？」「それを解決するにはどうしたら良いのか？」という問題に立ち向かっていたと言えます。その後、2013年にAuth0を創業しました。

創業したきっかけは？

ペース：私がMicrosoftのキャリアの後半で関わっていたのは、「いかにクラウドにシステムを移行させるか？」という命題だったのですが、その時に多く聞いた障壁の一つが、認証だったのです。当時、IDの管理と認証というのはOSなどと同じインフラストラクチャーの問題として認識されていました。デベロッパーにとっては、IDとパスワードでログインさえできればOKという程度の問題だったのですが、実際にはそれを実装するだけでもデベロッパーにとっては大きな労力が必要だったのです。というのも、アプリケーションだけではなく外部のAPIやスマートフォンなど多くの要素がそれに関わってくるからです。

そのためにそれを解説する本をAuth0の共同創業者の一人と一緒に本を書きました。これはIDの管理と認証をテーマにした本でした。その本の続編も書きましたが、こちらは前作の2倍の分量になりました。その時に、「このまま問題を解説する側にいるのか、それとも問題を解決する側になるのか？」という問いを自分に投げかけたのです。

その結果、2013年の1月にAuth0を創業して解決することになったわけです。ゴールは「デベロッパーにとってのID管理と認証の問題を解決する」というものでした。大事なのは「デベロッパーにとって」という部分です。そのためAuth0の初期のタグラインは「Stripe for Authentication」だったのです。

つまりTwilioがメッセージングに対してやっていること、SendGridが電子メールに対してやっていること、Stripeがペイメントに対してやっていることを、Authentication（認証）に対してやっているということですね。

つまりデベロッパーが容易にそれらの機能を自社のサービスやアプリケーションに組み込めるようにしたということですね。

ペース：そうです。そして市場は我が社の役割を理解してくれたようです。Auth0は2013年に創業して、最初のプロダクトを3月に出荷しました。その後、4月に最初のユーザーを獲得しました。その時は月に27ドルという小規模なものでしたが、その数カ月後に20万ドル／月という契約を獲得することができました。創業時と現在を比べると、従業員数は100倍（5名から500名）になり、顧客数は350倍（2社から700社）、そして売り上げは300倍になりました。結果的には我々のアプローチは成功していると言えます。

ビジネスとして成功しているのはわかりました。今後のAuth0のプランを教えてください。

ペース：我々は毎年何か目的をもってビジネスを進めています。ID管理と認証というのは非常にベーシックな問題、言ってみればレイヤー0の問題なのです。しかしその上にはもっと多くの問題があります。その中の重要な要素は、「あなたが誰か？」と「何を実行可能か？」なのです。つまりIDと役割の2つです。つまりAさんが業務システムにログインしたとします。その時に「ログインしているのは本当のAさんなのか？」そして「Aさんは業務システムの中で何が実行できるのか？」を管理しなければいけないということです。

Auth0のノベルティ。ロゴマークは保安官のバッジをイメージしているという

その部分はKubernetesなどのクラウドネイティブなシステムの中でも盛んに議論されているRBAC（Role-Based Access Control）ですね。

ペース：RBACはAuth0の中ですでに機能として実装されています。我々が目指しているのはもっと粒度の細かいアクセスコントロールです。例えば、Aさんがシアトルの住所から毎朝9時から10時の間にログインしているとします。ある日突然、午前3時にログインがあったら？　しかもそれが東京からだったとしたら？　たとえIDとパスワードが正しいものであっても、もう一度チェックしたほうが良いかもしれません。さらに、そのアクセスの時にお金の振り込みを行うアプリケーションが実行されたら？　それが1万ドルという金額だったら？

つまりコンピュータの世界では、ログインはイチかゼロ、TrueとFalseという2値しか持たないものです。でも現実の世界はそんなに簡単に白黒がハッキリするものではありません。例えば今の例なら、電話番号にSMSを送って本当にその電話を持っているAさんなのかを確認するべきですよね。そのように、とても粒度の細かいアクセスコントロールを実装したいというのが我々の将来の計画です。

また粒度の細かいアクセスコントロールをしようとするとどうしても避けて通れないのが、組織の構造の問題です。単に階層になっているだけではありません。最近は組織横断的なプロジェクトが発生して、それに対応したアクセスコントロールが必要になってきています。日本はツリー構造の階層になっていることが多いと思いますが、それでもいろいろなプロジェクトが発生して、それにIT部門が対応するのは大変なのではないでしょうか？　この問題をどうやったらシンプルに解決できるのかを考えています。

「デベロッパーにとって」という部分ですが、その部分をもう少し詳しく教えてください。

ペース：例えば作りたいアプリケーションがWebベースのフロントエンドなのか、バックエンドなのか、モバイル向けなのか、それぞれのパターンに沿ってドキュメントとサンプルを提供しています。実際にAuth0を使って認証を行う部分は、数行から数十行を追加するだけで可能なのです。その他にも多くの言語やTwitterやFacebook、Google Apps、Azureなどに対応したサンプルコードと解説を用意していますので、デベロッパーの抱える問題をなくしたいというAuth0の意図は分かってもらえると思います。

日本でのビジネス展開について教えてください。日本だとどちらかと言うとパートナー向けのチャネルを重要視する必要があると思いますが、かつてAWSがやっていたようにデベロッパー向けの草の根運動も必要ではないかと思います。

藤田：おっしゃる通りで、日本では2つのチャネルを考えています。一つはデベロッパーのための啓蒙活動を通じて、ボトムアップで浸透していく方法、そしてもう一つがパートナーを通じてビジネスを展開するという方法です。パートナーについては、すでにクラスメソッドがパートナーとして活動していますが、そういう目端の利くパートナーと協業したいというのが方針ですね。バックグラウンドがあって技術にも詳しいパートナーであれば、我々の製品への理解も早いですし、良い商談をクローズできることに繋がると考えています。

マー：今の質問は、大変良い質問だと思います。日本では、草の根運動とパートナーを通じてのビジネスの両方を進めていくのがベストだと思います。

認証のソリューションとしては、対象がマイクロサービスだろうがモノリシックなレガシーアプリケーションだろうが関係なく対応できるというのがCEOのペース氏の回答だった。

すでにKubernetes界隈ではマイクロサービス、サービスメッシュのセキュリティを高めるために、どのようにRBACを実装するのか？　という議論が盛んになっている。AWS上に構築されるSaaSとしてのAuth0が、オンプレミスとパブリッククラウドをまたぐハイブリッドなKubernetesの世界でどのような役割を果たせるのか、注目していきたい。