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

2025年6月28日(土)開催のPHPカンファレンス2025での「「Chatwork」の認証基盤の移行とログ活用によるプロダクト改善」発表資料です。
イベントページ：https://phpcon.php.gr.jp/2025/
概要：https://fortee.jp/phpcon-2025/proposal/d2bed5f9-58ed-4645-a052-75a6ad8a2415
登壇者：株式会社kubell 山下 賢治

【参考資料】
- 2025年2月14日登壇資料「SaaSの次なる潮流BPaaS ゼロイチの事業づくりと伴走するプロダクト開発の裏側」
https://speakerdeck.com/kubell_hr/devsumi2015-hiramoto
- 2025年5月8日登壇資料「Xdebug ProfileによるCIパフォーマンス改善のためのボトルネック解析」
https://speakerdeck.com/kubell_hr/241222-yamashita

Transcript

1. 「Chatwork」の認証基盤の移行とログ活用に よるプロダクト改善 山下 賢治 / Kenji Yamashita 2025年06月28日 PHP Conference Japan 2025
2. 自己紹介 2 • 名前: 山下 賢治 (Kenji Yamashita) • 所属: 株式会社kubell (旧Chatwork株式会社) ◦ 2022年4月 ~ フロントエンド開発部 ◦ 2022年10月 ~ モバイル管理画面チーム ◦ 2023年6月 ~ 認証グループ • SNS: ◦ GitHub: yamakenji24
3. 目次 CONTENTS 01 | 会社概要 02 | Auth0の導入背景 03 | Auth0への移行 04 | ログを活用したプロダクト改善 05 | まとめ
4. 01 | 会社概要
5. 2024年7月1日よりChatwork株式会社は、株式会社kubell（読み：クベル）に社名変更しました。 株式会社kubellは、誰もが使いやすく、社外のユーザーとも簡単につながることができる 日本最大級のビジネスチャット「Chatwork」を運営しています。 また、チャット経由で会計、労務、総務など様々なバックオフィス業務をアウトソースできる 「Chatwork アシスタント」などのBPaaSサービスを幅広く展開。 ビジネスチャットの会社から、BPaaSで「働く」を変えるプラットフォームを提供する会社へ事業領域を拡張します。
6. なぜ社名変更したのか？ 7 • 「Chatwork」事業に加えて、新事業「BPaaS」を始めたことが一つの大きな理由
7. サービス種類 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よりさらに上流のレイヤーをクラウド化する、次の潮流に
8. kubellが展開するBPaaSのイメージ • ビジネスチャットを最大限活用したBPaaSを展開。AIエージェント＋SaaS Hub＋Humanを組み合わせ、バックオフィス業務の実行 までを網羅的に代替 業務発生 Chatwork プロダクト 人事/労務 営業／マーケティング 経理／財務 調達／購買 総務／その他リサーチ BPaaS窓口 • サービス一覧 • 案件管理・相談 ビジネスチャット • チャット・タスク • 通知(お知らせ・BOT) 9 発生した業務を AIエージェント＋SaaS Hub＋Humanの 連携で実行 AI エージェント SaaS Hub Human データ処理 通知… 外部ツール 連携… 非定型 専門業務… 業務完了 業務効率化 によるコア業務へ の集中 業務タイプ 業務オペレーション
9. 「Chatwork」以外の最初のプロダクト、「フロントデスク」とは？ • 「BPaaS窓口」とは、依頼（アウトソーシング）したい業務を、「案件」としてまるごと発注（契約&決済）できるシ ステム的な仕組み • 「フロントデスク」とは、その内の顧客が利用する画面部位についてのプロダクト 10 引用: 平本 康裕 “SaaSの次なる潮流BPaaS ゼロイチの事業づくりと伴走するプロダク ト開発の裏側”, Developer Summit 2025 登壇資料, 2025年2月14日
10. 02 | Auth0の導入背景
11. Auth0を導入するに至った背景 課題 • 「Chatwork」は、導入当時400万以上（現在754万以上 2025.03末時点）の登録アカウントを抱える”ビジネスインフ ラ ◦ 登録アカウントのセキュリティを業界最高級水準で維持し続ける必要がある • 一方、「Chatwork」の中核機能は「ビジネスチャット」 ◦ セキュリティはコアドメインではない 解決策として、 • 日々推移するセキュリティ課題への対応、追従については、専門のIDaaSにお任せする判断 ◦ 「ハイトラフィックなビジネスチャット」という中核機能に開発リソースを集中できる状態を目指した 加えて、 • 「BPaaS」という新規事業展開 ◦ 「Chatwork」登録ユーザーへ、ビジネスチャット以外のプロダクトの提供を実現できる必要がある ◦ 認証系を、業界標準（OIDC）に準拠させながら、「Chatwork」本体から分離させ、他プロダクトの認証機能と しても運用できる状態を目指した 12
12. 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
13. 03 | Auth0への移行
14. Auth0導入のための移行戦略 15 Auth0を導入するために、754万人ユーザーを抱える既存システムを止めることはできない → 既存の構成を考慮し、どのような構成でどのように進めていくのか検討が必要 まずは全体の基本構成を設計 • Auth0へ認証サーバーを任せること • 「Chatwork」側(kubell共通認証・ID基盤側)にアカウントマスターを残すこと • 既存のアカウントを事前にAuth0へ移行しない ◦ 初回ログイン時にAuth0の機能を活用し、Just In Time provisioningする
15. Auth0導入のための移行戦略 16 • 移行開発進め方のねらい: ◦ 「Chatwork」の認証機能が、OIDC認証サーバーとOIDCクライアントに分離されれば、自ずと、「Chatwork」 以外のOIDCクライアントへの認証提供も可能となる Chatwork Chatwork (OIDCクライアント) Auth0 (OIDC認証サーバー) アカウント アカウント Chatwork (OIDCクライアント) フロントデスク (OIDCクライアント) プロダクトY (OIDCクライアント) アカウント 認証基盤 (OIDC認証サーバー)
16. 既存の認証要素の移行 17 既存の認証要素を全てAuth0へ移行したのか？ NO
17. Auth0導入するために、既存の認証要素を移行する 18 既存の認証機能とAuth0の仕様を比較検討した結果、主に以下の3つに分類した • Auth0の認証機能としてそのままAuth0側へ持っていけたもの • Auth0 Actionsを利用して移行したもの ◦ 認証のタイミングで独自処理を追加できる仕組み • 「Chatwork」に残したもの
18. Auth0導入にあたって、認証要素を分類 19 Auth0の認証機能としてそのままAuth0側へ持っていけたもの • Auth0が提供している認証機能を利用する • ex. パスワード認証やGoogle, Apple認証といったSocialログイン Auth0 Actionsを利用して移行した認証要素 • 認証の共通基盤として「Chatwork」以外のアプリへも認証機能を提供したいもの • ex. 2段階認証やメール認証 「Chatwork」側に残した認証要素 • 「Chatwork」固有の機能 • 認証の共通基盤として持っておきたい機能というわけではない
19. Auth0 導入後の認証要素の整理 20
20. • Auth0が提供する認証機能をそのまま利用する部分については ◦ 既存コードは破棄した • Auth0 Actionsを利用して独自処理を追加し移行した部分については ◦ 既存のコードを切り出して、Auth0 Actionsと連携して動くものに改変 • 「Chatwork」側に残した認証要素については ◦ OIDCクライアントとして、Callbackエンドポイントに実現できるように再編成 実際のAuth0移行開発 21 既存のコードを切り出すとは？
21. 既存システムから切り出す 22 １つのデプロイ単位の中で 様々な機能が切り出されている 同じデプロイ単位の中で Auth0に関連する単位で切り出す
22. 既存システムから切り出す 23 デプロイ単位でさらに切り出す 独立したデプロイ・スケーリングが可能に 開発・運用の効率性の向上 保守性の向上
23. さらに詳しく知りたい方へ 24 引用: 山下 祐 “既存の開発資産を活かしながら、 《新規開発コスト抑制》と《開発体験向上》 を両立する拡張 アーキテクチャ事例 ", 登壇資料, 2025年05月08日
24. さらに詳しく知りたい方へ 25 引用: 山下 祐 “既存の開発資産を活かしながら、 《新規開発コスト抑制》と《開発体験向上》 を両立する拡張 アーキテクチャ事例 ", 登壇資料, 2025年05月08日
25. さらに詳しく知りたい方へ 26 引用: 山下 祐 “既存の開発資産を活かしながら、 《新規開発コスト抑制》と《開発体験向上》 を両立する拡張 アーキテクチャ事例 ", 登壇資料, 2025年05月08日
26. 04 | ログを活用したプロダクト改善
27. 1. Auth0 SDK内のログを手厚くしたい 2. Business Eventの定義と活用
28. 1. Auth0 SDK内のログを手厚くしたい 2. Business Eventの定義と活用
29. • SDKや外部APIを利用していると、次のような要件が出てきませんか？ ◦ 特定エンドポイントに対するリクエストだけリトライしたい ◦ エンドポイントごとにタイムアウト設定を調整したい ◦ リクエストとレスポンスのログを統一フォーマットで記録したい ◦ 通信間で発生したエラーのログを細かく取得したい ◦ 任意のメトリクスを計測したい 754万人のアカウント抱える「Chatwork」にとって、運用時の可視性が不足することが課題 Auth0 SDK内のログを手厚くしたい 30
30. 標準化されたインターフェイスを活用し、解決していく PHPには、PSRという標準規約がある SDKがPSRに準拠していたら、Decoratorパターンを活用した拡張が可能となる Auth0 SDK内のログを手厚くしたい 31 これらの要件を満たすために、手を加える必要があるが.... • SDKをForkして利用する ◦ 本家に追従していくのが大変 • SDKをラップすると抽象度が上がってしんどい ◦ １つのHTTPリクエストのために、大量のコードを書く必要が出てしまう
31. 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
32. 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パターンを導入・活用しています
33. PSR準拠の恩恵：PSR-18準拠のHTTPクライアント 34
34. PSR準拠の恩恵：実装例 35 PSRに準拠しているので、任意のHTTPClientを実装可能！
35. PSR準拠の恩恵：実装例 36 実際のHTTP通信は Guzzle Client等に移譲 前後は任意の処理 元のSDKのコードを一切変更することなく 機能拡張ができている
36. PSR準拠の恩恵：実装例 ~ログの注入~ 37 ログを仕込んだり Datadogにカスタムメトリクス を送ったり
37. PSR準拠の恩恵：実装例 ~ リクエスト単位でタイムアウト調整 ~ 38 特定のエンドポイントやリクエスト時のタイムアウトを調整したい HTTP Client生成時に注入 リクエスト単位で タイムアウトを定義
38. PSR準拠の恩恵：実装例 ~リトライ処理~ 39 任意のカスタマイズが可能なため、自由度が高い 任意の条件を元に リトライしたり
39. Auth0 SDK内のログを手厚くしてどう嬉しかったか 40 エンドポイントに対するリトライ回数を細かく把握することができる • いつ、どのエンドポイントで、どういうエラーが発生したかがわかる • 何回リトライしたかがわかる • どのタイミングのリトライで成功したかがわかる 1回目では 失敗しているが 2回目では 成功している
40. 1. Auth0 SDK内のログを手厚くしたい 2. Business Eventの定義と改善への活用
41. Business Eventとは • アプリケーション内で発生するビジネスロジックのイベントを構造化 • ユーザーの行動や重要な処理を追跡可能 • Snowflakeでの分析・可視化に活用 ビジネスロジックとは • 業務や事業の価値に直結するような処理 • 例: 長期間ログインしていない休眠アカウントでログインしようとするとメール認証が要求される ◦ どれだけのユーザー数がメール認証が発火し、認証に成功/失敗したか というビジネスイベントを定義できる なぜBusiness Eventを定義したのか • エラー調査や障害対応等でログを仕込むことは多いと思う • それとは別に、プロダクト/施策/機能がどれだけ使われているか/有効かを計測・分析したい • 単純にログを出すだけでは、ログ構造がバラバラになってしまい、検索しづらくなる • 構造を共通化させることで、検索性・整合性を担保したい Business Eventの定義 42
42. Business Eventの定義例 43
43. • Fail-safe設計 ◦ ログ送信時にエラーが発生してログインできなくなるのは避けたい ◦ callableを使用し、Business Eventの生成処理を遅延させる ◦ ログ送信時にエラーが発生したよというログを送って制御する Business Eventの設計と実装 44 共通で呼び出すように することで 例外のcatch漏れがなく なる
44. 構造化されたユーザーアクションの記録として、様々な場面で活用 プロダクト改善や施策の定量評価 • 施策の有効率や既存機能の改善指標のための分析データとして サポート対応への活用 • サポート問い合わせ時の操作履歴調査のデータとして活用 • サポート対応時の調査コストを削減 • ログイン履歴、認証フローの通過履歴、アカウント設定系の変更履歴など • 特に、Chatworkでは管理者などが子ユーザーの情報を一部操作できる設計になっているので ◦ 「誰が」「いつ」「なんの」変更/操作をしたのかを正確に残しておくことが重要 Business Eventの活用 45
45. モバイルからMFAを設定可能にする機能をリリースした • セキュリティ的な要素として、MFAを設定するのは重要 • 事前調査でモバイルのみ利用しているユーザーが一定数存在していることを確認 • モバイルからも簡単に設定することで、登録率を増やしたい Business Eventから施策の有効度合いを分析 ~モバイルMFA編~ 46
46. 施策の有効度合いとして、設定率がどれだけ増えたのかを計測 • MFAを設定するユーザー数としては微増 • 増加はしているが、セキュリティ対策としては別施策を考慮する必要がありそうということが可視化 Business Eventから施策の有効度合いを分析 ~モバイルMFA編~ 47
47. 「Chatwork」に登録していないが、Google or Appleでログインしようとしているユーザーが一定数存在している • ログインエラーとなったメアドで登録していると思っている • その導線から登録ができると思っている 導線を整理することで、UX改善になるのではないか？ • 新規登録をしたいユーザーは継続して行うことができる • 新規登録率を向上させることができるのではないかという仮説 ログを用いたプロダクト改善 ~ 新規登録編 ~ 48 未登録のGoogle or Appleでログイ ンしようとしている
48. Googleアカウントでログインしたユーザーが未登録の場合に、新規登録選択画面を表示する機能をリリース • ログインしようとしたGoogleアカウントが未登録であることがわかる • 新規登録に進むか、別のメールアドレスでログインするかを選択する画面を提示 ログを用いたプロダクト改善 ~ 新規登録編 ~ 49
49. 施策後、「未登録のメアドでGoogleログインを試したあとの新規登録」の登録率が15.9%→25.4%に9.5ポイント増加 プロダクトの新規登録導線の改善を行うことでユーザー体験の改善に加え、登録者数の向上に貢献しました ログを用いたプロダクト改善 ~ 新規登録編 ~ 50
50. ログイン時のパスワード失敗が想像より毎日発生している 業務開始時にすぐに利用できないのは軽減したい これらを改善すべく、施策が進行中です！ 結果どうなるかは今後に期待 ログを用いたプロダクト改善 ~ 現在進行中 ~ 51 パスワード入力の失敗数
51. 05 | まとめ
52. まとめ Auth0を導入し、効果的に利用するための改善活動を継続して行っています PSR準拠のSDKではDecoratorパターンを活用し機能拡張を実現 Business Eventを活用してプロダクトの改善を行っています まだまだ課題、やりたいことはたくさんあります！ 53
53. 54 kubellでは ミッションに共感し、ともに実現していく仲間を募集しています （キャリア登録やニュースレター登録も受け付けています！） kubell エンジニア採用 https://www.kubell.com/recruit /engineer/ エンジニアを絶賛募集中です！
54. 働くをもっと楽しく、創造的に 56