インボイス管理サービス「Bill One」 の認証を内製認証基盤に置き換えた話 Sansan技術本部 Geeks Who Drink in Osaka！〜KANSAI SaaS edition〜 Sansan株式会社 加藤 耕太

写真が入ります 加藤 耕太（Kota Kato） Sansan株式会社 技術本部 Bill One Engineering Unit＠関⻄⽀店 Sansan株式会社所属のソフトウェアエンジニア。 インボイス管 理サービス「Bill One」のアーキテクトとして、技術選定から⽴ ち上げに関わり、現在に⾄るまで開発および技術マネジメントに 従事。 趣味: 散歩、ゲーム

アジェンダ - Bill Oneとは - 認証基盤内製化の背景 - 新しい認証基盤の設計 - リリース結果と今後 - まとめ

Bill Oneとは

働き⽅を変えるDXサービス 請求 ⼈や企業との出会いをビジネスチャンスにつなげる「働き⽅を変えるDXサービス」を提供 ビジネスフローにおけるさまざまな分野でサービスを展開 名刺管理 名刺DX 営業 営業DX 契約 契約DX 経理DX 個⼈向けDX 法⼈向けDX 必要な情報を すぐに⾒つけられる 情報の管理がしやすく すぐに共有できる 情報を分析・活⽤しやすく データに基づいた判断ができる SansanのDXサービスの活⽤で変わる働き⽅

請求書受領から、⽉次決算を加速する インボイス管理サービス「Bill One」 あらゆる請求書をオンラインで受け取り、 企業全体の請求書業務を加速する インボイス管理サービスです。

Bill Oneの提供価値 どんな形式の請求書でもワンストップで受領し、契約企業の請求書の⼀元管理を実現します。 ※ Sansan株式会社が規定する条件を満たした場合のデータ化精度 ワンストップ受領 99.9％※の精度でデータ化 クラウド上で⼀元管理 請求書を発⾏する企業 Bill Oneの契約企業 メール 添付 アップ ロード 郵送 代理受領 代理スキャン

認証基盤内製化の背景

Bill Oneの成⻑ ※MAU: Monthly Active User 認証基盤の移⾏タイミング

従来の認証基盤: Auth0 Okta社が提供する開発者向けのIDaaS (Identity as a Service) - 様々なアプリケーションに簡単に組み込める - MFA (Multi Factor Authentication) 、ブルートフォース検知など セキュリティ機能が充実 - B2B (企業向け), B2C (消費者向け), B2E (従業員向け) のログインを提供 - Single Sign-On (SSO) やOrganizationなど、B2B SaaS向けの機能も充実 - M2M (Machine-to-Machine) の認証も提供 https://auth0.com/

従来の認証基盤の課題1: コスト - サービスの成⻑に伴うコストの増加 - MAU単価の⽐較（参考） - Bill OneはMAUに応じて直接的に収益が上がるビジネスモデルではない - ユーザー数課⾦ではない課⾦体系 - 取引先に無料アカウントを作成してもらえる > 取引先のユーザーが毎⽉ログインして請求書を送るケースも多い サービス MAU単価 (⽉額) 備考 Auth0 $0.24 B2B Professionalプランで7,500 MAUの場合の 参考値 （実際の契約額とは異なる） Amazon Cognito $0.0055 50,001 〜 100,000MAUの場合の参考値

従来の認証基盤の課題2: ⼈材 - 当社では歴史的にプロダクトごとの独⽴性が⾼い - ユーザー管理や認証も分かれている - 新規プロダクトを開始する際、初期のフェーズではプロダクトごとに 認証周りに強い⼈材を配置するのが難しい - IDaaSを使ってもSSO周りの知⾒は必要 C# AWS Kotlin Google Cloud Kotlin / Go Google Cloud Ruby AWS 主要⾔語 インフラ

共通認証基盤プロジェクト 1. サービスの成⻑に伴うコストの増加 2. 新規プロダクトを開始する際、初期のフェーズではプロダクトごとに 認証周りに強い⼈材を配置するのが難しい 専⾨チームを組んで認証基盤を内製化し、プロダクトの共通認証基盤とする

新しい認証基盤の設計

設計⽅針 - コストは意識しつつも、機微な情報はマネージドなIDaaSに寄せる - ⾜りない機能は⾃前のアプリケーションで補う - SSOはAuth0を使い続ける マネージドなIDaaS ⾃前の アプリケーション Auth0 顧客のID Provider パスワード 認証の場合 SSOの場合 ID連携

技術選定 - IDaaS - Amazon Cognito - クラウドサービス - AWS - アプリケーション - ユーザー向け画⾯・API: Go - 管理画⾯: TypeScript, React 選定理由 - コスト削減が⾒込める - ⾃前のアプリケーションで機能を補いやすい - AWSを得意とするメンバーは多い

アーキテクチャ（エンドユーザー向け部分の抜粋）

リリース時のリスクを⼩さくするため、データを⼀気に移⾏するのではなく、 ログインしたユーザーから順次移⾏する アカウント移⾏⽅針 Cognito（新） ログイン画⾯ Auth0（旧） ① メールアドレス・ パスワードを⼊⼒ ② Cognitoに 問い合わせ ③ Cognitoにユーザーが 存在しない場合はAuth0 に問い合わせ ④ パスワードが正し ければデータ移⾏

リリース結果と今後

リリース後の状況 - 😀 3週間でMAUの約86%のユーザーが新基盤に移⾏ - 😢 ログイン画⾯のドメイン変更により、ログイン不可の問い合わせが増加 - パスワードマネージャーはサブドメインの違いを無視してサジェストする - ⼀度保存すれば、サブドメインが⼀致するものが優先される Bill Oneの旧ログイン画⾯ (auth.bill-one.com) Bill Oneの新ログイン画⾯ (auth.sansan.com) Sansanのログイン画⾯ (ap.sansan.com) Bill Oneの ID/パスワード Sansanの ID/パスワード サジェスト サジェスト サジェスト

リリースの成果 - コスト - ⼤幅な削減に成功 - ⼈材 - 専⾨チームを結成できたが、他プロダクトへの展開は認証基盤の機能や プロダクト戦略次第

- プロダクトの初期フェーズで認証周りの⼯数を削減できた効果は⼤きい - Auth0は機能が豊富であることを痛感 - 例: CognitoのHosted UIは⼀切カスタマイズ・⽇本語化できないので、MFAの 設定フローを（ワンタイムパスワード設定⽤のQRコードを作るところも含め て）⾃作する必要がある - コストの問題がなければAuth0を使い続けたかった - ユーザー数課⾦のサービスや、MAUあたりの収益が⾼いビジネスモデルで あれば、コストに⾒合う価値があると思う - ⼀⽅で、⾃作のアプリケーションによって、⾃由度が上がってプロダクト 独⾃の要件が実現しやすくなった⾯もある Auth0の利⽤を振り返っての所感

- 旧認証基盤でコストと⼈材が課題になっていた - Amazon Cognitoをベースに認証基盤を内製化した - 無事にリリースして、コストを削減できた - ⼈材⾯の課題解決は道なかば まとめ 詳しくはブログ記事もご覧ください！ https://buildersbox.corp-sansan.com/entry/bill-one-in-house-auth-platform Sansan Tech Blog

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/

No content