「Chatwork」の認証基盤の移行とログ活用によるプロダクト改善

by kubell

Slide 1

Slide 1 text

「Chatwork」の認証基盤の移行とログ活用によるプロダクト改善山下賢治 / Kenji Yamashita 2025年06月28日 PHP Conference Japan 2025

Slide 2

Slide 2 text

自己紹介 2 ● 名前: 山下賢治 (Kenji Yamashita) ● 所属: 株式会社kubell (旧Chatwork株式会社) ○ 2022年4月 ~ フロントエンド開発部 ○ 2022年10月 ~ モバイル管理画面チーム ○ 2023年6月 ~ 認証グループ ● SNS: ○ GitHub: yamakenji24

Slide 3

Slide 3 text

Slide 4

Slide 4 text

01 | 会社概要

Slide 5

Slide 5 text

2024年7月1日よりChatwork株式会社は、株式会社kubell（読み：クベル）に社名変更しました。株式会社kubellは、誰もが使いやすく、社外のユーザーとも簡単につながることができる日本最大級のビジネスチャット「Chatwork」を運営しています。また、チャット経由で会計、労務、総務など様々なバックオフィス業務をアウトソースできる「Chatwork アシスタント」などのBPaaSサービスを幅広く展開。ビジネスチャットの会社から、BPaaSで「働く」を変えるプラットフォームを提供する会社へ事業領域を拡張します。

Slide 6

Slide 6 text

なぜ社名変更したのか？ 7 ● 「Chatwork」事業に加えて、新事業「BPaaS」を始めたことが一つの大きな理由

Slide 7

Slide 7 text

サービス種類 BPaaSとは 8 BPaaS （Business Process as a Service） SaaS （Software as a Service） PaaS （Platform as a Service） IaaS （Infrastructure as a Service）ハードウェアミドルウェアアプリケーションビジネスプロセス提供範囲 ● BPaaSとは Business Process as a Service の略。ソフトウェアの提供ではなく、業務プロセスそのものを提供するクラウドサービスであり、クラウド経由で業務アウトソーシング(BPO)が可能 ● SaaSよりさらに上流のレイヤーをクラウド化する、次の潮流に

Slide 8

Slide 8 text

kubellが展開するBPaaSのイメージ ● ビジネスチャットを最大限活用したBPaaSを展開。AIエージェント＋SaaS Hub＋Humanを組み合わせ、バックオフィス業務の実行までを網羅的に代替業務発生 Chatwork プロダクト人事/労務営業／マーケティング経理／財務調達／購買総務／その他リサーチ BPaaS窓口 ● サービス一覧 ● 案件管理・相談ビジネスチャット ● チャット・タスク ● 通知(お知らせ・BOT) 9 発生した業務を AIエージェント＋SaaS Hub＋Humanの連携で実行 AI エージェント SaaS Hub Human データ処理通知… 外部ツール連携… 非定型専門業務… 業務完了業務効率化によるコア業務への集中業務タイプ業務オペレーション

Slide 9

Slide 9 text

「Chatwork」以外の最初のプロダクト、「フロントデスク」とは？ ● 「BPaaS窓口」とは、依頼（アウトソーシング）したい業務を、「案件」としてまるごと発注（契約&決済）できるシステム的な仕組み ● 「フロントデスク」とは、その内の顧客が利用する画面部位についてのプロダクト 10 引用: 平本康裕 “SaaSの次なる潮流BPaaS ゼロイチの事業づくりと伴走するプロダクト開発の裏側”, Developer Summit 2025 登壇資料, 2025年2月14日

Slide 10

Slide 10 text

02 | Auth0の導入背景

Slide 11

Slide 11 text

Auth0を導入するに至った背景課題 ● 「Chatwork」は、導入当時400万以上（現在754万以上 2025.03末時点）の登録アカウントを抱える”ビジネスインフラ ○ 登録アカウントのセキュリティを業界最高級水準で維持し続ける必要がある ● 一方、「Chatwork」の中核機能は「ビジネスチャット」 ○ セキュリティはコアドメインではない解決策として、 ● 日々推移するセキュリティ課題への対応、追従については、専門のIDaaSにお任せする判断 ○ 「ハイトラフィックなビジネスチャット」という中核機能に開発リソースを集中できる状態を目指した加えて、 ● 「BPaaS」という新規事業展開 ○ 「Chatwork」登録ユーザーへ、ビジネスチャット以外のプロダクトの提供を実現できる必要がある ○ 認証系を、業界標準（OIDC）に準拠させながら、「Chatwork」本体から分離させ、他プロダクトの認証機能としても運用できる状態を目指した 12

Slide 12

Slide 12 text

IDaaS選定時の比較項目 ● パフォーマンス: ○ 「Chatwork」のMAU推移予測に対して、十分カバーできるパフォーマンスプランを提供している事 ● 費用体系: ○ CIAM(Customer Identity and Access Management)目的であり、MAUベースの料金体系である事 ● 不正ログイン対策: ○ 不正ログイン対策機能に関して、IDaaS自身が継続的に拡充を行なっている事 ● その他、各機能のFit/Gap: ○ CIAM(Customer Identity and Access Management)向けであること ○ SAML認証, Social Login, CAPTCHA, MFA, ...といった機能が直接サポートされている、または実現可能である事 ○ URLに独自ドメインが使用できる事, ログイン画面のカスタマイズができること ○ ネイティブモバイルアプリ向けにもログイン画面を提供できる事 13

Slide 13

Slide 13 text

03 | Auth0への移行

Slide 14

Slide 14 text

Auth0導入のための移行戦略 15 Auth0を導入するために、754万人ユーザーを抱える既存システムを止めることはできない → 既存の構成を考慮し、どのような構成でどのように進めていくのか検討が必要まずは全体の基本構成を設計 ● Auth0へ認証サーバーを任せること ● 「Chatwork」側(kubell共通認証・ID基盤側)にアカウントマスターを残すこと ● 既存のアカウントを事前にAuth0へ移行しない ○ 初回ログイン時にAuth0の機能を活用し、Just In Time provisioningする

Slide 15

Slide 15 text

Auth0導入のための移行戦略 16 ● 移行開発進め方のねらい: ○ 「Chatwork」の認証機能が、OIDC認証サーバーとOIDCクライアントに分離されれば、自ずと、「Chatwork」以外のOIDCクライアントへの認証提供も可能となる Chatwork Chatwork (OIDCクライアント) Auth0 (OIDC認証サーバー) アカウントアカウント Chatwork (OIDCクライアント) フロントデスク (OIDCクライアント) プロダクトY (OIDCクライアント) アカウント認証基盤 (OIDC認証サーバー)

Slide 16

Slide 16 text

既存の認証要素の移行 17 既存の認証要素を全てAuth0へ移行したのか？ NO

Slide 17

Slide 17 text

Auth0導入するために、既存の認証要素を移行する 18 既存の認証機能とAuth0の仕様を比較検討した結果、主に以下の3つに分類した ● Auth0の認証機能としてそのままAuth0側へ持っていけたもの ● Auth0 Actionsを利用して移行したもの ○ 認証のタイミングで独自処理を追加できる仕組み ● 「Chatwork」に残したもの

Slide 18

Slide 18 text

Auth0導入にあたって、認証要素を分類 19 Auth0の認証機能としてそのままAuth0側へ持っていけたもの ● Auth0が提供している認証機能を利用する ● ex. パスワード認証やGoogle, Apple認証といったSocialログイン Auth0 Actionsを利用して移行した認証要素 ● 認証の共通基盤として「Chatwork」以外のアプリへも認証機能を提供したいもの ● ex. 2段階認証やメール認証「Chatwork」側に残した認証要素 ● 「Chatwork」固有の機能 ● 認証の共通基盤として持っておきたい機能というわけではない

Slide 19

Slide 19 text

Auth0 導入後の認証要素の整理 20

Slide 20

Slide 20 text

● Auth0が提供する認証機能をそのまま利用する部分については ○ 既存コードは破棄した ● Auth0 Actionsを利用して独自処理を追加し移行した部分については ○ 既存のコードを切り出して、Auth0 Actionsと連携して動くものに改変 ● 「Chatwork」側に残した認証要素については ○ OIDCクライアントとして、Callbackエンドポイントに実現できるように再編成実際のAuth0移行開発 21 既存のコードを切り出すとは？

Slide 21

Slide 21 text

既存システムから切り出す 22 １つのデプロイ単位の中で様々な機能が切り出されている同じデプロイ単位の中で Auth0に関連する単位で切り出す

Slide 22

Slide 22 text

既存システムから切り出す 23 デプロイ単位でさらに切り出す独立したデプロイ・スケーリングが可能に開発・運用の効率性の向上保守性の向上

Slide 23

Slide 23 text

さらに詳しく知りたい方へ 24 引用: 山下祐 “既存の開発資産を活かしながら、《新規開発コスト抑制》と《開発体験向上》を両立する拡張アーキテクチャ事例 ", 登壇資料, 2025年05月08日

Slide 24

Slide 24 text

さらに詳しく知りたい方へ 25 引用: 山下祐 “既存の開発資産を活かしながら、《新規開発コスト抑制》と《開発体験向上》を両立する拡張アーキテクチャ事例 ", 登壇資料, 2025年05月08日

Slide 25

Slide 25 text

さらに詳しく知りたい方へ 26 引用: 山下祐 “既存の開発資産を活かしながら、《新規開発コスト抑制》と《開発体験向上》を両立する拡張アーキテクチャ事例 ", 登壇資料, 2025年05月08日

Slide 26

Slide 26 text

04 | ログを活用したプロダクト改善

Slide 27

Slide 27 text

1. Auth0 SDK内のログを手厚くしたい 2. Business Eventの定義と活用

Slide 28

Slide 28 text

1. Auth0 SDK内のログを手厚くしたい 2. Business Eventの定義と活用

Slide 29

Slide 29 text

● SDKや外部APIを利用していると、次のような要件が出てきませんか？ ○ 特定エンドポイントに対するリクエストだけリトライしたい ○ エンドポイントごとにタイムアウト設定を調整したい ○ リクエストとレスポンスのログを統一フォーマットで記録したい ○ 通信間で発生したエラーのログを細かく取得したい ○ 任意のメトリクスを計測したい 754万人のアカウント抱える「Chatwork」にとって、運用時の可視性が不足することが課題 Auth0 SDK内のログを手厚くしたい 30

Slide 30

Slide 30 text

標準化されたインターフェイスを活用し、解決していく PHPには、PSRという標準規約がある SDKがPSRに準拠していたら、Decoratorパターンを活用した拡張が可能となる Auth0 SDK内のログを手厚くしたい 31 これらの要件を満たすために、手を加える必要があるが.... ● SDKをForkして利用する ○ 本家に追従していくのが大変 ● SDKをラップすると抽象度が上がってしんどい ○ １つのHTTPリクエストのために、大量のコードを書く必要が出てしまう

Slide 31

Slide 31 text

PSR (PHP Standards Recommendation) とは？ PHP-FIG(The PHP Freamework Interop Group)によって策定されているPHP開発者向けの規約 PSRの分類(2025年6月現在) ● AUTOLOADING : クラスの自動読み込み (ex. PSR-4) ● INTERFACES : ログなどの共通インターフェイス (ex. PSR-3, PSR-11) ● HTTP : HTTPリクエストやレスポンスの扱い (ex. PSR-7) ● CODING STYLES: コーディングスタイルの統一 (ex. PSR-1) 必ず守らなければならない規約ではない PSRに準拠していることで、以下の恩恵を受けやすい ● コーディングスタイルの統一 ● フレームワークやライブラリとの連携がしやすくなる ● 拡張性の高い設計が実現しやすくなる今回特に取り扱うのはPSR-18 32

Slide 32

Slide 32 text

PSR準拠の恩恵：拡張性のある構造 Auth0 PHP SDKは、HTTP通信実装部分にPSR-18インターフェースを採用しています ● PSR-18に準拠していることで任意のHTTPクライアントを差し替えることが可能です ● HTTPClientInterfaceに準拠したDecoratorクラスを作成することで、拡張が可能 33 https://github.com/auth0/auth0-PHP/blob/main/src/Configuration/SdkConfiguration.php#L84 Auth0 SDKがPSRに準拠していたため、Decoratorパターンを導入・活用しています

Slide 33

Slide 33 text

PSR準拠の恩恵：PSR-18準拠のHTTPクライアント 34

Slide 34

Slide 34 text

PSR準拠の恩恵：実装例 35 PSRに準拠しているので、任意のHTTPClientを実装可能！

Slide 35

Slide 35 text

PSR準拠の恩恵：実装例 36 実際のHTTP通信は Guzzle Client等に移譲前後は任意の処理元のSDKのコードを一切変更することなく機能拡張ができている

Slide 36

Slide 36 text

PSR準拠の恩恵：実装例 ~ログの注入~ 37 ログを仕込んだり Datadogにカスタムメトリクスを送ったり

Slide 37

Slide 37 text

PSR準拠の恩恵：実装例 ~ リクエスト単位でタイムアウト調整 ~ 38 特定のエンドポイントやリクエスト時のタイムアウトを調整したい HTTP Client生成時に注入リクエスト単位でタイムアウトを定義

Slide 38

Slide 38 text

PSR準拠の恩恵：実装例 ~リトライ処理~ 39 任意のカスタマイズが可能なため、自由度が高い任意の条件を元にリトライしたり

Slide 39

Slide 39 text

Auth0 SDK内のログを手厚くしてどう嬉しかったか 40 エンドポイントに対するリトライ回数を細かく把握することができる ● いつ、どのエンドポイントで、どういうエラーが発生したかがわかる ● 何回リトライしたかがわかる ● どのタイミングのリトライで成功したかがわかる 1回目では失敗しているが 2回目では成功している

Slide 40

Slide 40 text

1. Auth0 SDK内のログを手厚くしたい 2. Business Eventの定義と改善への活用

Slide 41

Slide 41 text

Business Eventとは ● アプリケーション内で発生するビジネスロジックのイベントを構造化 ● ユーザーの行動や重要な処理を追跡可能 ● Snowﬂakeでの分析・可視化に活用ビジネスロジックとは ● 業務や事業の価値に直結するような処理 ● 例: 長期間ログインしていない休眠アカウントでログインしようとするとメール認証が要求される ○ どれだけのユーザー数がメール認証が発火し、認証に成功/失敗したかというビジネスイベントを定義できるなぜBusiness Eventを定義したのか ● エラー調査や障害対応等でログを仕込むことは多いと思う ● それとは別に、プロダクト/施策/機能がどれだけ使われているか/有効かを計測・分析したい ● 単純にログを出すだけでは、ログ構造がバラバラになってしまい、検索しづらくなる ● 構造を共通化させることで、検索性・整合性を担保したい Business Eventの定義 42

Slide 42

Slide 42 text

Business Eventの定義例 43

Slide 43

Slide 43 text

● Fail-safe設計 ○ ログ送信時にエラーが発生してログインできなくなるのは避けたい ○ callableを使用し、Business Eventの生成処理を遅延させる ○ ログ送信時にエラーが発生したよというログを送って制御する Business Eventの設計と実装 44 共通で呼び出すようにすることで例外のcatch漏れがなくなる

Slide 44

Slide 44 text

構造化されたユーザーアクションの記録として、様々な場面で活用プロダクト改善や施策の定量評価 ● 施策の有効率や既存機能の改善指標のための分析データとしてサポート対応への活用 ● サポート問い合わせ時の操作履歴調査のデータとして活用 ● サポート対応時の調査コストを削減 ● ログイン履歴、認証フローの通過履歴、アカウント設定系の変更履歴など ● 特に、Chatworkでは管理者などが子ユーザーの情報を一部操作できる設計になっているので ○ 「誰が」「いつ」「なんの」変更/操作をしたのかを正確に残しておくことが重要 Business Eventの活用 45

Slide 45

Slide 45 text

モバイルからMFAを設定可能にする機能をリリースした ● セキュリティ的な要素として、MFAを設定するのは重要 ● 事前調査でモバイルのみ利用しているユーザーが一定数存在していることを確認 ● モバイルからも簡単に設定することで、登録率を増やしたい Business Eventから施策の有効度合いを分析 ~モバイルMFA編~ 46

Slide 46

Slide 46 text

施策の有効度合いとして、設定率がどれだけ増えたのかを計測 ● MFAを設定するユーザー数としては微増 ● 増加はしているが、セキュリティ対策としては別施策を考慮する必要がありそうということが可視化 Business Eventから施策の有効度合いを分析 ~モバイルMFA編~ 47

Slide 47

Slide 47 text

「Chatwork」に登録していないが、Google or Appleでログインしようとしているユーザーが一定数存在している ● ログインエラーとなったメアドで登録していると思っている ● その導線から登録ができると思っている導線を整理することで、UX改善になるのではないか？ ● 新規登録をしたいユーザーは継続して行うことができる ● 新規登録率を向上させることができるのではないかという仮説ログを用いたプロダクト改善 ~ 新規登録編 ~ 48 未登録のGoogle or Appleでログインしようとしている

Slide 48

Slide 48 text

Googleアカウントでログインしたユーザーが未登録の場合に、新規登録選択画面を表示する機能をリリース ● ログインしようとしたGoogleアカウントが未登録であることがわかる ● 新規登録に進むか、別のメールアドレスでログインするかを選択する画面を提示ログを用いたプロダクト改善 ~ 新規登録編 ~ 49

Slide 49

Slide 49 text

施策後、「未登録のメアドでGoogleログインを試したあとの新規登録」の登録率が15.9%→25.4%に9.5ポイント増加プロダクトの新規登録導線の改善を行うことでユーザー体験の改善に加え、登録者数の向上に貢献しましたログを用いたプロダクト改善 ~ 新規登録編 ~ 50

Slide 50

Slide 50 text

ログイン時のパスワード失敗が想像より毎日発生している業務開始時にすぐに利用できないのは軽減したいこれらを改善すべく、施策が進行中です！結果どうなるかは今後に期待ログを用いたプロダクト改善 ~ 現在進行中 ~ 51 パスワード入力の失敗数

Slide 51

Slide 51 text

05 | まとめ

Slide 52

Slide 52 text

まとめ Auth0を導入し、効果的に利用するための改善活動を継続して行っています PSR準拠のSDKではDecoratorパターンを活用し機能拡張を実現 Business Eventを活用してプロダクトの改善を行っていますまだまだ課題、やりたいことはたくさんあります！ 53

Slide 53

Slide 53 text

54 kubellではミッションに共感し、ともに実現していく仲間を募集しています（キャリア登録やニュースレター登録も受け付けています！） kubell エンジニア採用 https://www.kubell.com/recruit /engineer/ エンジニアを絶賛募集中です！

Slide 54

Slide 54 text

働くをもっと楽しく、創造的に 56