CodeZine(コードジン)

特集ページ一覧

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

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

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2020/04/16 12:00

目次

構想実現の鍵を握る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と位置づけられた。

GateboxにおけるSoRとSoE
GateboxにおけるSoRとSoE

認証管理システムとして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コールのフロー
Gateboxにおける全般的なAPIコールのフロー

 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ページにものぼったと言う。

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

お問い合わせ

 日本マイクロソフト株式会社

  • 【Microsoft Learn】
    • Microsoft Azureについて学習できる無料のオンライン トレーニング コンテンツ一覧

 Gatebox株式会社



  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

バックナンバー

連載:【デブサミ2020】セッションレポート

もっと読む

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5