Chatwork認証基盤移行のリアル 〜IDaaS採用、そして現実解へ〜

2026年5月20日(水)に実施された「B2B SaaSの認証認可の変遷 － 事業成長が迫る基盤移行のリアル」での発表資料です。
イベントページ：https://findy-tools.connpass.com/event/388589/
登壇者：株式会社kubell 田中 浩一

Transcript

1. Chatwork認証基盤移行のリアル 〜IDaaS採用、そして現実解へ〜 株式会社kubell プロダクトディビジョン Chatworkプロダクトユニット プロダクトマネジメントグループ プロダクトマネジメントチーム 田中 浩一 2026.05.20 Findy Tools 「B2B SaaSの認証認可の変遷 － 事業成長が迫る基盤移行のリアル」 登壇資料
2. Introduction • 「Chatwork」は今年15周年を迎えました。 • 当初、「Chatwork」の認証機能は、「Chatwork」本体とモノリシックに一体的でした。 • 2023年頃、認証基盤を「Chatwork」本体から、論理的、かつ物理的に切り離したアーキテクチャーへと移行する大改 修を行いました。この認証基盤の中核は、Auth0というIDaaSによって担われています。 • 本発表では下記の様な内容についてお話します。: ◦ なぜそのような大改修を経ての認証基盤の切り出しを実施することとしたのか、そのビジネス的背景や狙い ◦ IDaaS導入や、伴う改修はどのように進められたのか、その過程でどのような問題が生じたか ◦ 結果として、現在の認証基盤のアーキテクチャーはどのようなものとなっているのか 2 https://brand.chatwo rk.com/chatwork-day/
3. 目次 CONTENTS 01 | Chatwork株式会社から 株式会社kubellへ 02 | IDaaS（Auth0）の導入 04 | アカウントデータ移行のリアル 05 | 振り返りと概念整理 03 | 移行開発のリアル
4. 01 | Chatwork株式会社から 株式会社kubellへ
5. 2024年7月1日よりChatwork株式会社は、株式会社kubell（読み：クベル）に社名変更しました。 株式会社kubellは、誰もが使いやすく、社外のユーザーとも簡単につながることができる 日本最大級のビジネスチャット「Chatwork」を運営しています。 また、チャット経由で会計、労務、総務など様々なバックオフィス業務をアウトソースできる 「タクシタ」などのBPaaSサービスを幅広く展開。 ビジネスチャットの会社から、BPaaSで「働く」を変えるプラットフォームを提供する会社へ事業領域を拡張します。
6. なぜ社名変更したのか？ 6 • これまでのビジネスチャット事業に加えて、新たにBPaaS事業を始めたことが一つの大きな理由 引用: 株式会社kubell "2026年12月期 第1四半期 決算説明資料", 2026年5月15日
7. BPaaS事業とは何か？ 7 • 多様なSaaSが利用できていても、多数のSaaSを使いこなしつつの業務プロセス構築は難易度が高い • それを解決するために、業務プロセスを丸ごと巻き取るBPaaSが有効 引用: 株式会社kubell "2026年12月期 第1四半期 決算説明資料", 2026年5月15日
8. BPaaS事業のイメージ 8 1. お客様から、「Chatwork」や「BPaaS窓口」を通して、”仕事”を依頼、つまり発注いただく 2. 受注側（つまりkubellのBPaaS組織）は、業務プロセスを進行させて、終わったら完了報告（納品）をする 引用: 株式会社kubell "2025年12月期 通期 決算説明資料", 2026年2月13日
9. 「Chatwork」以外のプロダクト • 「BPaaS窓口」: 依頼したい業務を、「案件」としてまるごと発注（契約&決済） • 「AIエージェント」: 社会保険労務士（社労士）事務所向け、労務関連業務支援 9 引用: 株式会社kubell "2025年12月期 通期 決算説明資料", 2026年2月13日
10. BPaaS事業の、認証チーム（当時）としての課題設定 10 • 認証チーム（当時）は、BPaaS事業が展開されるということは、「Chatwork」以外のプロダクトが登場し、それらの プロダクトへ認証提供していくことを意味している、という点を受け止め Chatwork BPaaS窓口 アプリ AIエージェント アプリ アカウント 認証基盤 その他の プロダクト Chatwork アカウント
11. 02 | IDaaS（Auth0）の導入
12. 前提知識 • 「IDaaS（”IDentity as a Service”）」とは？: ◦ IDやパスワードを一元集中管理し、ログイン画面を含む認証機能を提供するSaaS ◦ IAM（”Identity and Access Management”）機能を提供するSaaS（”IAM as a Service”と言ってもよい） • 「Auth0」とは？: ◦ Okta社によって運営されるIDaaSの一つ • 他にIDaaSにはどんなものがあるか？: ◦ Amazon Cognito ◦ Microsoft Entra ID / Entra External ID ◦ Google Cloud Identity Platform ◦ GMO トラスト・ログイン • 「CIAM（”Customer Identity and Access Management”）」とは？: ◦ 企業内の従業員のID管理ではなく、サービスを利用する顧客のID管理を特に意図したIAM機能 ▪ 従業員のID管理を意図したIAM機能を「EIAM（”Enterprise Identity and Access Management”）」と称 することも ◦ IDaaSによって、CIAM向け、EIAM向けといった違いがある 12
13. IDaaSを導入するに至った背景 13 引用: 山下 賢治 “Okta CIC Actionを活用した独自の認証関連機能の移行方法、およびログやメトリク スの監視手法について実例紹介”, Okta Japan主催 Okta CIC Meetup 登壇資料, 2024年7月11日 Okta CIC = Auth0の”旧”名称 809.4万 (2026年3月時点)
14. IDaaS選定時の比較項目 • パフォーマンス: ◦ 「Chatwork」のMAU推移予測に対して、十分カバーできるパフォーマンスプランを提供している事 • 費用体系: ◦ CIAM目的であり、MAUベースの料金体系である事 • 不正ログイン対策: ◦ 不正ログイン対策機能に関して、IDaaS自身が継続的に拡充を行なっている事 • その他、各機能のFit/Gap: ◦ CIAM向けであること ◦ SAML認証, Social Login, CAPTCHA, MFA, ...といった機能が直接サポートされている、または実現可能である事 ◦ URLに独自ドメインが使用できる事, ログイン画面のカスタマイズができること ◦ ネイティブモバイルアプリ向けにもログイン画面を提供できる事 14
15. Findy Toolsに寄稿しております 15 https://findy-tools.io/pro ducts/auth0/35/94
16. 03 | 移行開発のリアル
17. Auth0を前提とした認証機能部位リプレース開発計画 (1 of 2) • 基本的な開発ミッション: ◦ “「Chatwork」の認証機能部位を、Auth0にリプレースする” • リプレース開発の技術的要点: ◦ モノリシックに作り込まれている「Chatwork」の認証機能部位を、Auth0というOIDC認証サーバー （OpenID Provider）と、「Chatwork」というOIDCクライアント（Relying Party）との構成に分離する こと ▪ Auth0は、そもそもOIDC認証サーバー（OpenID Provider）である ▪ 「Chatwork」を、OIDCクライアント（Relying Party）として振る舞うよう改修する 17
18. Auth0を前提とした認証機能部位リプレース開発計画 (2 of 2) 18 • 移行開発進め方のねらい: ◦ 「Chatwork」の認証機能が、OIDC認証サーバーとOIDCクラアイントに分離されれば、自ずと、「Chatwork」 以外のOIDCクライアントへの認証提供も可能となる Chatwork Chatwork (OIDCクライアント) Auth0 (OIDC認証サーバー) アカウント アカウント Chatwork (OIDCクライアント) BPaaS窓口 アプリ (OIDCクライアント) AIエージェント アプリ (OIDCクライアント) アカウント 認証基盤 (OIDC認証サーバー)
19. 移行開発: 具体的な進め方 1. 「Chatwork」の既存の認証関連機能（”認証要素”）にはどんなものがあるのか洗い出して列挙する。 2. どの機能をAuth0へ任せて、どの機能を「Chatwork」側に残すべきか？一つ一つ見極めていく。 19
20. ”認証要素”を洗い出す 20 パスワード認証 SAML認証 Google認証 Apple認証 2段階認証 休眠アカウント メール認証 アカウント停止 組織間移行中 アカウントロック Chatwork www.chatwork.com
21. “認証要素”を移行計画に応じて分類する A. そのままAuth0提供機能を利用する ✓ （将来の）認証基盤として、「Chatwork」以外のプロダクトへも提供したいもの ✓ かつ、Auth0にそのまま置き換え可能な機能が有る B. Auth0 Actionsを利用して、カスタム実装する ✓ （将来の）認証基盤として、「Chatwork」以外のプロダクトへも提供したいもの ✓ しかし、Auth0にそのまま置き換え可能な機能が無い C. 「Chatwork」に残す ✓ 「Chatwork」というプロダクト固有の機能だと判断されるもの 21
22. ”認証要素”をそれぞれ移行開発する • パスワード認証, SAML認証, Google認証, Apple認証, アカウントロック, ... ✓ 基本的な認証機能は、Auth0提供の当該機能をそのまま利用 ⇒ Auth0へ移行するので、既存コードは破棄する • 2段階認証, 休眠アカウント・メール認証, ... ✓ Auth0 Actionsを利用してカスタム実装しつつ、OIDC認証サーバー側へ移行 ⇒ コードを切り出して、Auth0 Actionsと連携して動くものに改変する • アカウント停止, 組織間移行中, ... ✓ 「Chatwork」側の責務として残す ⇒ OIDCクライアントとして、Callbackエンドポイントにて実現されるように、コードを再編成する 22
23. ”認証要素” As-Is (再掲) 23 パスワード認証 SAML認証 Google認証 Apple認証 2段階認証 休眠アカウント メール認証 アカウント停止 組織間移行中 アカウントロック Chatwork www.chatwork.com
24. “認証要素” To-Be 24 OIDC認証サーバー Auth0 Actions カスタム実装 休眠アカウント メール認証 組織間移行中 アカウント停止 www.chatwork.com Chatwork (OIDCクライアント) auth.chatwork.com
25. ・・・と、さらっと言ってますが、 • 実際の移行開発は、 ◦ Auth0提供の相当機能をそのまま利用する機能部位については、、、 ⇒ 既存コードは破棄！ ◦ Auth0 Actionsを利用してカスタム実装しつつ、OIDC認証サーバー側へ移行する機能部位については、、、 ⇒ コードを切り出して、Auth0 Actionsと連携して動くものに改変 ◦ 「Chatwork」側matterとして残す機能部位については、、、 ⇒ OIDCクライアントとして、Callbackエンドポイントにて実現されるように、クラス類を再編成する • つまりは、地道に続くリライティング（再実装）・・・ ◦ 年単位の開発期間の半分は既存コードの再編成に費やしていた 25
26. 04 | アカウントデータ移行のリアル
27. 事前一括移行 vs Auth0 Automatic Migration 27 • 事前一括移行のConsが目立った ◦ 事前一括移行バッチの実行時間が、相当程度になると見積もられた ▪ 400万以上（当時）の登録アカウントというデータ量 ⇒ 秒間100件移行できたとして、11時間 ▪ Auth0 APIのレスポンスタイムやRate Limitの制約 ⇒ 実際には、1週間程度と見積もられた ◦ 移行バッチ実行中、サービス停止か、少なくともなんらか縮退運用が避けられない • Auth0のAutomatic Migrationを利用することで、このConsを避けられる
28. Auth0 Automatic Migration 28 See: https://auth0.com/blog/how-to-migrate-users-to-auth0-a-technic al-guide/#Automatic-User-Migration--Trickle-Lazy-Migration- ログイン →Auth0ユーザーDBに既に存在しているかチェッ 　ク →存在していたら認証PASS →存在していなかったら、カスタムの既存DB検証 　スクリプトを実行 →OKだったら、Auth0ユーザーDBに登録&認証 　PASS
29. ChatworkにおけるAutomatic Migrationの利用（概念） 29
30. アカウントデータ移行: 当初計画 1. 十分な期間、Automatic Migrationで運用 ⇒ アクティブユーザーが移行されるのを見届ける 2. 十分な期間経過後 ⇒ 非アクティブユーザーを一括移行 ∵ 対象アカウントが縮退運用になっても影響は少ない 30
31. アカウントデータ移行: 結果（現状） 1. 十分な期間、Automatic Migrationで運用 ⇒ アクティブユーザーが移行されるのを見届ける 2. 十分な期間経過後 ⇒ 非アクティブユーザーを一括移行 ∵ 対象アカウントが縮退運用になっても影響は少ない 31
32. アカウントデータの持ち方、現状アーキテクチャー（概念） • 現状のアーキテクチャー: ◦ アカウントデータの”マスター”は、Chatwork側の既存DBのまま、とした ◦ Auth0側のユーザーDBは、アカウントデータの、認証機能用のいわば”レプリカ”と位置付け ▪ Automatic Migrationが、レプリケーション機能として運用されているイメージ • その理由: ◦ アカウントマスターは、将来のディレクトリーサービスのコアとなる期待があって、Auth0のユーザーDBでは 様々なクエリー要求を満たせそうになかった 32
33. 05 | 振り返りと概念整理
34. 振り返り 34 1. kubellは、ビジネスチャット事業に加えて、BPaaS事業に取り組み始めた 2. システム的には、「Chatwork」以外に複数プロダクト展開されることを意味する 3. 複数プロダクトへ認証提供するための、認証基盤が必要 4. まずは既存の「Chatwork」の認証機能部位をAuth0前提でリプレースする、というゴール設定で移行開発 Chatwork Chatwork (OIDCクライアント) Auth0 (OIDC認証サーバー) アカウント アカウント Chatwork (OIDCクライアント) BPaaS窓口 アプリ (OIDCクライアント) AIエージェント アプリ (OIDCクライアント) アカウント 認証基盤 (OIDC認証サーバー)
35. 概念整理 (1): 認証基盤への三つのミニマム要求 35 • 認証基盤に対する要求纏めに取り掛かるにおいて、ビジネスモデルやプロダクト戦略が変化しても、なにせ複数プロダ クト展開することに違いはない点に注目 • 複数プロダクトを展開する事から、下に示す様な三つのミニマム要求が発せられる、と整理した • これを実現するものとして認証基盤を計画した 顧客ベース アカウント ミニマム要求 プロダクト シングル・サイン・ オン 複数プロダクトを シームレスに利用で きる 再度の本人確認（メ アド確認）不要 あるプロダクトに於 いて一度アカウント 登録したら、他のプ ロダクトを利用する 時再度登録しなくて よい 共通ID アカウントの属性や アクティビティを、 プロダクト横断的に 紐づけられる Chatwork BPaaS窓口 アプリ AIエージェント アプリ その他の プロダクト
36. 概念整理 (2): 認証要素、何を認証基盤へ持っていき、何を残したか • 認証基盤へ持っていった認証要素: ✓ 認証基盤として、「Chatwork」以外の全てのプロダクトへ共通して提供したいもの ➢ 結論として、純粋に認証のみを、認証基盤の責務とした • 「Chatwork」に残した認証要素: ✓ 「Chatwork」というプロダクト固有の機能だと判断されるもの ➢ プロダクト固有の問題は、プロダクト固有の認可の問題であると、えいっと割り切り 36
37. 概念整理 (3): なぜ「認可」は扱わないか？ • 根本原理の認識: ◦ 「認可」のモデルとはビジネスモデルそのものである ◦ これを無理に統合することはしない • kubellの複数プロダクト展開における状況: ◦ プロダクトによって、そもそも「契約」が異なる ⇒ Principalを束ねる単位の概念がプロダクトごとに異なる ▪ ビジネスモデル的要請から、各プロダクトの契約は、セールスプロセス上基本的には独立している • 「Chatwork」は、ビジネスチャット事業として展開 • 「BPaaS窓口アプリ」は、BPaaS事業として展開 ◦ プロダクトによって、権限管理したい対象が異なる ⇒ Resourceの概念がプロダクトごとに異なる ▪ 「Chatwork」は、チャットルームやチーム ▪ 「BPaaS窓口アプリ」は、「案件」 • 結論: ◦ もっぱら、アカウントの本人認証のみを認証基盤の責務とする ▪ 個人としてのPrincipal概念（だけ）を統合、共通化する 37
38. 付録
39. 参考資料 ▪ 田中 浩一 “ログイン機能をAuth0に移行した話（一人のシニア開発者の目線から）”, kubell Creator’s Note, 2023年12月13日 https://creators-note.chatwork.com/entry/2023/12/13/000000 ※ 本発表者による社員ブログ ▪ 田中 浩一 “Auth0 by Okta導入で、認証時セキュリティは専門IDaaSにお任せ、プロダクト間SSOはほぼ開発レスで実現”, Findy Tools, 2024年5月31日 https://findy-tools.io/products/auth0/35/94 ※ 本発表者によるFindy Toolsへの寄稿 ▪ 山下 賢治 “Okta CIC Actionを活用した独自の認証関連機能の移行方法、およびログやメトリクスの監視手法について実例紹介”, Okta Japan主催 Okta CIC Meetup 登壇資料, 2024年7月11日 https://speakerdeck.com/kubell_hr/240711-yamashita ※ 認証チームメンバー（当時）による、Auth0カスタマー対象のMeetup登壇資料 ▪ 株式会社kubell "2026年12月期 第1四半期 決算説明資料", 2026年5月15日 https://contents.xj-storage.jp/xcontents/AS04681/b9a347cc/7546/4772/a5e5/c1ae294893f4/14012026051553767 4.pdf ▪ 株式会社kubell "2025年12月期 通期 決算説明資料", 2026年2月13日 https://contents.xj-storage.jp/xcontents/AS04681/1d0588db/8ad0/4469/9b7c/ac08a4da8042/14012026021356137 8.pdf 39
40. 40 kubellでは ミッションに共感し、ともに実現していく仲間を募集しています kubell エンジニア採用 https://career.kubell.com/product/ エンジニアを絶賛募集中です！
41. 41 もっと知りたい方はこちら “kubellグループの日々をとどける”メディア kubell days “kubellのエンジニアブログ” Creater's note 情報がぎゅっと詰まった 「Chatwork」エンジニア組織 紹介資料 https://days.kubell.com/ https://speakerdeck.com/kubell_ hr/chatwork-engineer https://creators-note.chatw ork.com/
42. 働くをもっと楽しく、創造的に 42