🗝️
LayerX／kubellの実例から学ぶ プロダクトが大きくなっても壊れない認証設計とは？
複数のプロダクトを同時に運用する際、認証や認可をどう設計すれば後々の負債を回避できるのか。2025年4月23日に開催された本イベントでは、まさにマルチプロダクトや業務領域の拡大によって高まる認証基盤の重要性を議題に、実践的な知見が共有されました。登壇いただいたのは LayerX にて「バクラク」シリーズを展開するチームでID基盤を担当するconvto氏と、kubell（旧Chatwork）で認証リプレイスに取り組んだ田中浩一氏。両社の実例を通じ、ID管理や認証基盤をどう設計すべきかを深く探ります。
イベント概要と背景
企業や組織が成長するにつれ、単一サービスから複数プロダクトへ展開するケースは増えています。しかし、共通ID基盤を後から再構築すると、エンジニアリング面・運用面ともに大きなコストがかかりがちです。 本イベントでは、「Chatwork」から複数プロダクト展開を進めた kubell と、「バクラク」シリーズを複数展開する LayerX の事例から、その認証基盤をどのように再設計し、技術的課題を乗り越えてきたのかを学びました。モデレーターは、overflow CTOの 大谷旅人 氏です。
登壇者紹介
田中 浩一 氏（kubell）
Chatwork時代からの認証やアカウント管理を担当。
受託開発で長年エンタープライズ系の会員管理などに携わり、2021年よりChatwork（現kubell）に入社。
モノリシックだった「Chatwork」の認証基盤をアイデンティティサービス（IDaaS）に移行する大規模プロジェクトを経験。
convto 氏（LayerX）
2023年にLayerXへ入社し、「バクラク」事業部でID基盤を担当。
バクラクシリーズのマルチプロダクト展開を支える認証設計や、組織規模の拡大に対応するID管理の実装を推進。
LT1: kubellの田中さん「モノリシックな「Chatwork」から、認証基盤をどのように切り出していったか」
背景とビジネス的要請
Chatworkはユーザー規模が大きく、さらに新たな複数プロダクトを展開し始める局面で「認証基盤の刷新」が必須に。セキュリティ強化やID管理を専門に任せたいという経営的判断もあり、IDaaS（アイダース） を導入することに。 田中さんいわく、「モノリシックなChatwork本体から認証を切り出す には年単位の作業が必要だった」とのこと。特に既存の認証関連機能を1つずつ洗い出し、「これはアイダースに任せる」「これは自社に残す」と分類管理したプロセスが成功の鍵になったそうです。
OS0を使ったリプレイス
自社で持たず、専門家に任せたい という方針でアイダースを選定
不正アクセスなどセキュリティ要件を標準的に備える
Chatwork特有の多彩な認証要素（2段階認証、メール認証など）は、アイダースのカスタマイズポイント（Actions等）で対応
データ移行は、「オートマティックマイグレーション」機能を活用し、大きな一括移行をせず徐々に進める形で煩雑さを減らした
組織横断
Chatworkは元々、複数組織を横断してユーザーがチャットルームに参加できる設計だったため、「テナントを切り替えて使う」という発想が薄いそうです。このため、認証基盤側の「共通ユーザー」を中心に管理しやすい仕組みが取りやすかったと語られました。
LT2: LayerX・convtoさん「バクラクの認証基盤の未来と現在地」
多彩な要件との向き合い
「バクラク」シリーズは当初からID基盤を分離して設計しており、マルチプロダクト対応が比較的やりやすい構成だったとのこと。しかし、組織が拡大し、業務提携や外部APIを介した利用ニーズが増えるにつれ、オープンスタンダードやセキュリティモデルへの対応など、新たな要求が次々と生じたそうです。 たとえば「OS2.0の認可コードフローをサポートしてほしい」という要望が出た際には、OSSの「Ory Hydra」 を使って最低限の仕組みを被せる形で実装。既存のユーザー情報管理を大きく変えずに、標準仕様の認可フローを提供できる利点を活かしたとのこと。
用途限定セッションの設計
convtoさんは「非バクラクユーザーにリソースを一時共有したい」「オフィス設置のPCで打刻機能だけ使いたい」など、多様なユースケースに対応するための用途限定セッションを工夫した事例も紹介。ワンタイムパスやICカード読取により、業務で必要な範囲に限定した認証セッションを発行するアプローチが興味深いポイントです。
認証と認可をどう切り分けるか
バクラクでは、認可はほぼ各プロダクトで持つ方針を貫いています。「認可のモデルはビジネスロジックそのもの」という考えから、認証基盤で抱えすぎると複雑化してしまうため、あえて境界を明確にすることで運用負荷を下げているとのこと。
Q&Aダイジェスト
以下、参加者から寄せられた質問と、お二人の主な回答です。
いつからID基盤を共通化すべき？
kubell: 必要に迫られてから動く形になったが、本音を言えば「早期にOIDCなど標準仕様に準拠しておくと後々ラク」
LayerX: 事業計画どおりにいくとは限らないため、あまりに先回りしすぎてもコスト増。必要が生じた時点で検討してもよい。
自前か、IDaaSか？
kubell: OS0を選んだ理由は「不正対策などセキュリティ面を任せられる」+「カスタマイズ性が高い」
LayerX: Ory Hydraを採用したのは、自社基盤を大きく変えずにOS2.0対応が欲しかったから。「OSSで必要最小限に加えるだけ」の利点があった
テナント横断の認証認可はどうしてる？
kubell: Chatworkはテナント概念が薄く、組織横断チャットルームも容易
LayerX: 「あるユーザーが複数テナントに所属可能」という設計。テナントごとにログイン方法やポリシーが異なる場合は、基盤側でチェックし適用
既存ユーザーのデータ移行は大変？
kubell: OS0の「オートマティックマイグレーション」で、初回ログイン時に逐次移行。大きな一括移行を回避
LayerX: 基本的にID基盤内やRDBにマスターを保持する設計なら、一部だけ別ソフトウェア導入時も比較的スムーズ
全体を踏まえた感想 - 認証基盤が拓く未来
複数プロダクトを展開する成長企業にとって、認証基盤はもはや“当たり前品質”の域を越えて、サービス提供を支える重要な骨格といえそうです。単純にパスワード認証が動けばよい時代から、ビジネスごとに異なる認可モデルや外部連携、スマートなUXを求める声が高まり、自然と要件は肥大化します。 今回の発表で感じたのは、認証やアカウント管理の領域はどうしても“地味”に映りがちですが、それゆえに文化のように根付くまで地道な改善と運用が鍵になるということ。田中さんが語ったように「当たり前に動いて当たり前に守られる世界」を実現するのは一筋縄ではいきません。 しかしconvtoさんの事例のように、複数プロダクトの境界をなるべく明確にしつつ、OSSや標準仕様を上手に組み合わせることで、柔軟かつ拡張しやすい基盤をつくることも可能です。 「認証は裏方だからこそ醍醐味がある」という両社の言葉が印象的でした。アクセス制御が整備されるとビジネスは広がり、移行がスムーズだと新機能導入スピードも上がる。認証基盤がプロダクトの未来を左右し得るのだと強く再認識させられるイベントでした。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...