【デブサミ2020】セッションレポート（AD）

たった6人でドキュメント330ページ分の巨大構想を実装できたわけとは？キャラクター召喚装置「Gatebox」のプラットフォーム設計に学ぶ【デブサミ2020】

【13-A-7】GateboxにおけるAzure AD/AD B2Cを基盤としたID Centricな組織・サービス・プラットフォームの設計

2020/04/16 12:00

　「キャラクターと暮らせる世界の実現」というビジョンを掲げ、キャラクター召喚装置だけではなく、アプリ配信システム、逢妻ヒカリや「Gatebox Video」などの自社アプリを提供しているGatebox。設計当初から、ハードウェアだけではなく、家でも外でもハードとアプリ双方でやりとりしたい、好きな3DCGキャラクターをアプリで購入して召喚できることがイメージされていたという。どのようにしてこの構想を実現していったのか。Azure ADはGateboxというプラットフォームでどんな役割を果たしているのか。Gatebox 取締役サービス設計担当の久森達郎氏が解説した。

Gatebox株式会社取締役 Chief Service Architecture Officer 久森達郎氏

Gateboxは設計段階から今のようなサービスをイメージしていた

　「連携コンポーネントが多いサービス設計を考えるときは『機能』や『スキーマ』ではなく、『人（ID）』から考えることが大事ということを伝えに来た」

　こう語り、久森氏のセッションは始まった。

　久森氏がGateboxに入社したのは2017年。それまではソーシャルゲームやアドテク領域でサービス基盤開発運用に従事した後、マイクロソフトでAzureのテクノロジーエバンジェリストとして活動していたという。

　Gateboxは好きなキャラクターと一緒に暮らせる、生活できる世界の実現を考えている会社だ。提供しているプロダクトおよびサービスは、キャラクターとの音声会話が楽しめるキャラクター召喚装置「Gatebox」、アプリ配信システム「App Market」、キャラクター型AIパートナー「逢妻ヒカリ」や自作キャラクターを召喚できる「Gatebox Video」などの自作アプリを提供している。

　Gateboxでは法人・個人問わず、Gateboxのアプリケーションの開発ができるよう、「開発者向けプログラム『Gatebox Developer Program』を提供している」と久森氏。作成したアプリは自身のGateboxで起動できるほか、App Marketを通じて他の「Gatebox」ユーザーにも配信が可能になる。「購入者の約10％が開発者登録している。自分で好きなキャラクターを召喚するだけではなく、ビジネスソリューションを開発する開発者・企業も増えている」（久森氏）

　Gateboxの予約販売が始まった2016年の年末に公開されたプロモーションムービーを見ればわかるが、「現在の姿の大枠は、この頃にイメージされた」と久森氏は話す。ユーザーの動きや音声などを認識して、ユーザーの状態を判定し、その状況に合わせたリアクションをすることや、外にいてもネットワーク越しにチャットが楽しめたり、自分の好きな3DCGキャラクターをアプリで購入して召喚できることなどが既にビジョンとして記されていたのだ。

　このように構想範囲が広いサービスを作っていこうとすると、「場当たり的な作り方では、サービス拡大やマーケットの動向による路線変更などが難しくなると考えた」と久森氏。というのもハードウェアスタートアップは、作るのにも時間、費用がかかる。「売価が15万円の製品でも、試作には数百万円かかることもある。しかも試作は1回で終わらず、3～4回行うこともざら」と久森氏。数を作るには投資も必要になる。「できるだけ柔軟なサービスの入れ替え、改善を行っていけるようにする設計が重要だと感じた」と久森氏は振り返る。

構想実現の鍵を握るIDを整理

　どうやって実装していったのか。Gateboxで作るサービスは3つの大きな要素で構成される。

　第一が自社キャラ・サービスである。これはキャラクター召喚装置としての魅力や体験を伝えるためのもの。具体的には逢妻ヒカリという自社のキャラクターサービスやGatebox Videoである。第二はプラットフォームとしての仕組みで、AppMarketやDeveloper Console。第三はキャラクター召喚装置そのものであるハードウェアやOSである。

　ただ、目に見えているものだけでこれらのサービスが成り立つわけではない。これらのサービスを運営するには、イベント運営管理ツール、対話エンジン設定、CSツール、配信制御のための管理ツールや課金処理のバックエンドシステム、アプリを本体に配布する際のインストールやアンインストールの仕組み、本体の設定やアプリ切り替えなどの管理ツールが必要になる。「結構な数の考慮事項が存在していた」と久森氏は語る。

　そこで久森氏はGoogleやApple、Nintendoのエコシステムを参考にしたという。例えばGoogleであれば、Gmailという囲い込みがあり、そのIDがGoogle Playと強く結び付いている。またAppleも同様で、iPhoneという強力なデバイスとそれを支えるApp StoreやiTunes Storeがある。Genius Barの予約もApple IDで行うようになっている。またNintendoは5年前にアカウント体系を刷新し、NintendoアカウントをFacebookやTwitterなどのソーシャルサービスのアカウントと連携し、自社のデバイス以外にも統一して使っていける構想となっていた。「Gateboxも同じ状況を作り出すことで、本体に閉じない体験の幅を広げることができると考えました」（久森氏）

　Gateboxはユーザーの状況を記録し、それに合わせて動作をし、ユーザーに提供されるサービスがデバイスをまたぎ、利用履歴が共有され、さらにキャラクターそれぞれの体験を販売できるというサービスである。「これを実現するには、どのサービスも、同じIDで使える必要がある。そこでまず、登場するIDを整理することから始めた」と久森氏は語る。

　IDは大きく3つに整理。1つはGatebox Customer IDで、Gateboxサービスを利用するユーザーのためのIDである。2つめはEmployee IDで、Gateboxサービスを運営する従業員のためのID、3つめがDeveloper ID。これはGateboxサービスに関連する開発者のためのIDである。

　組織境界の再設計も行った。従来のソフトチームとハードチームという体制から、自社キャラチーム、プラットフォームチーム、ハードウェアチームという開発体制へと変えたという。「システム設計は組織構造を反映するというコンウェイの法則がある。だから組織を変えた」（久森氏）

　さらに開発するものを、製品を特徴付ける要素（SoE）と製品を動かすための要素（SoR）とに分けた。SoEとは製品を見たときに「これがほしい」というインプレッションを与える要素である。Gateboxの場合、自社キャラアプリやLINE連携などの周辺サービス、ハードウェアがこれに該当。一方、配信・課金システムやアカウントなどのプラットフォーム、ハードウェアに搭載されるOSやミドルウェアはSoRと位置づけられた。

認証管理システムとしてAzure AD、Azure AD B2Cを選定

　続いてIDを統合・管理する技術選定を行った。「独自のサインインシステムを作ると、セキュリティが大変。一般的に広く使われている技術に従うことにした」と久森氏。Customer IDとDeveloper IDはOpenID ConnectとOAuth 2.0、Employee IDはSAMLで統合していくことなった。先に設定したIDの定義に従い、ユーザー向けのサービスはすべてCustomer IDのIdp、デベロッパー向けのサービスはDeveloper IDのIdp、G suiteやOffice 365、GitやCI/CDなどの開発ツール、運営ツールなどについてはEmployee IDのIdpに寄せることとなった。

　そのID認証ツールとして選定したのが、Azure ADである。「Azure ADでEmployee IDの認証を実現。Azure AD B2CでCustomer IDやDeveloper IDの認証フローを実装するほか、OpenID Connect／OAuth 2.0のフローで、IDトークン、アクセストークンの発行などを実現している」（久森氏）

　Azure AD、Azure AD B2Cを採用した理由について久森氏は、「認証が市場の差別化要因になるケースはない。Azure ADなら安定的に認証の仕組みが提供される。だから自分たちで作らなかった」と明かす。また当時、同社はBizSpark Plusの採択企業だったことも採用のポイントになったという。

　当初から開発者や運営者を考慮した理由についても久森氏は明かした。Gateboxは閉じたプラットフォームではなく、開かれたプラットフォーム。したがって、「マルチテナントなWeb APIやバックエンドを作る必要があったから」と久森氏。マルチテナントにすると、エンドユーザー認証や開発者認証、アプリ認証、開発／運営の認証をどうするのかという問題が出てくる。そこでGateboxのWeb APIでは3つのトークンを要求するように設計している。1つ目のエンドユーザー認証は本体認証を行う。ただ、Gateboxはボタンが1つしか用意されていないので、本体認証はQRコードを組み合わせてアクセストークンを取得できるような仕組みを作ったという。2つめがAPI認証である。そのリクエストが正当なユーザーか、正当な認証を経てきたものかについては、「Azure ADのトークン認証を使っている」と久森氏。

　次に開発者認証では、開発する主体は複数なので、正当な開発者がAPIリクエストしてきたかを把握する必要がある。そこで採用したのがAzureのAPI Managementというサービスである。「API Managementで発行したキーに対して認証をかけることで開発者認証を実装している」（久森氏）

　とはいえ、開発者はアプリを複数作ることができる。これまでの情報だけでは開発者は特定できても、アプリを特定することができない。そこでAPI認証でアプリを特定するセカンダリートークンを発行するという方法を採用していた。

　最後は開発／運営の認証をどうするか。管理ツールはセンシティブな情報を閲覧できたり破壊的な操作ができる。その割にCS業務や監視対応などをアウトソースすることも多い。つまり、アクセスコントロールが欠かせないのである。そこでGateboxではAzure ADに集約し、社外メンバーはゲストアカウントを使うことで、誰がどういうツールにアクセスしているかを管理しているという。

　Gateboxにおける全般的なAPIコールのフローは図の通りだ。まずIdpからアクセストークンを取得し、デバイスやブラウザがリクエストするときにそのトークンをつける。その際に開発者とアプリを特定するセカンダリートークンをつけ、API Gatewayに投げる。そこでAPI Gatewayではそのアクセスが正しいかどうかを確認し、APIサーバにリクエストを投げるという構成になっている。

　デバイス管理システムや本体、App Marketのログインに関しては、ユーザーがウェブブラウザで管理画面にログインして認証情報をとった後、ある手段を用いて、本体にワンタイムトークンを渡し、Azure ADからアクセストークンを取得し、リフレッシュし続けるという構成となっている。

　デベロッパーがアプリ配布などをする場合は、Developer Consoleにログインして、返されたアクセストークンを用いて認証、ストレージにアクセスしてアプリケーションの情報を登録する。アプリ配布は、本体からAzure AD B2Cでアクセストークンを取得し、APIを通じて、登録された情報を基にパッケージをダウンロードする作りとなっている。

　管理コンソールやサポートツールはAzure App Service認証で統合。「認証処理の実装を自分たちでやらなくていいので、このサービスを使っている」（久森氏）

　このような設計方法でGateboxはローンチされた。想定範囲が大きかったため、プラットフォームの部分だけで、42個プロジェクトが動いていたという。だが「リポジトリとしては4個。リポジトリとしてはモノシリックだけど、結果として生成されるのは複数というCI/CD体制を採用した」と久森氏。実際に開発で手を動かした人は社外を含めて6人だったという。

　とはいえ、開発において作ったドキュメントは、初期構想や計画スライド、計画文書、システムプランなど、合計で330ページにものぼったと言う。

　「構想範囲が広くても、自分たちが何を目指すのかを明確にし、ちゃんと設計すれば、手を動かす人が少人数でも開発できる」最後に久森氏はこう語り、セッションを締めた。