カミナシ社の『ID管理基盤』製品内製 - その意思決定背景と2年間の進化 #AWSUnicornDay / Kaminashi ID - The Big Whys

2025/09/02
AWS Unicorn Day Tokyo 2025
https://aws.amazon.com/startups/events/unicorn-day-tokyo-inperson

---
Tori Hara (@toricls)
CTO, Kaminashi

Manato Takai (@manaty0226), Ph.D
EM, Kaminashi ID Unit, Kaminashi

Transcript

1. カミナシ社の『ID管理基盤』製品内製 その意思決定背景と2年間の進化 Tori Hara (@toricls) CTO, Kaminashi Manato Takai (@manaty0226), Ph.D EM, Kaminashi ID Unit, Kaminashi
2. コミュニティでよく聞かれる3つのこと カミナシの ID 管理基盤製品について、よく聞かれる質問 / 本日お話しすること 1 アーリーフェーズ、単一プロダクトのタイミングで共通 ID 化を決めた背景は？ 2 IDaaS じゃなくて内製？なんで？ 3 具体的にどんな流れで全プロダクトの ID 統合をやり切ったの？
3. 想定聴講者とゴール • 中長期を意識した意思決定の難しさを感じているスタートアップ企業技術経営者 • 自社製品/顧客向け ID 基盤の開発にあたり、IDaaS 活用 or 内製で悩んでいる技術リーダー • 自社製品/顧客向け ID 基盤を内製で開発していくにあたり、その技術的ヒントが欲しい技術者 想定聴講者 セッションのゴール • 技術経営者が、意思決定における短期/中長期整理の勘所のパターンの一つを知れる • 技術リーダーが、IDaaS 活用 or 内製の判断をケーススタディから学べる • 自社で ID 基盤開発にこれから取り組む技術者が、その設計・実装や移行パターンの一つを学べる
4. アジェンダ • カミナシとは • ID 基盤開発による共通 ID 化の意思決定背景 • ID 基盤内製の意思決定背景 • 当時選択したトレードオフ 事業・経営意思決定編 技術・プロジェクト編 • 「カミナシ ID管理」基盤を支える技術 • (技術的に)カミナシはなぜID管理基盤を内製したか • ID管理基盤立ち上げから、全顧客・プロダクトから利用される基盤になるまでの流れ まとめ • まとめます
5. カミナシとは
6. ノンデスクワーカーの 才能を解き放つ Mission
7. ※ 独⽴⾏政法⼈労働政策研究‧研修機構「職業別就業者数」より当社算出 デスク ワーカー 43% 57% ノンデスク ワーカー 設備‧清掃 福祉施設 旅客‧運輸 製造業 飲⾷店 スーパー‧⼩売 ⽇本における 労働⼈⼝の割合 ノンデスクワーカーは⽇本の労働⼈⼝の半数以上。 私たちの⽣活は、あらゆる場⾯で ノンデスクワーカーに⽀えられている
8. 私たちの当たり前が 当たり前ではない世界。 プライベートではスマホを使いこなす⼈が、職場に⾏くととなぜか 紙とペンの世界にタイムスリップしてしまいます。 ノンデスクワーカーの働く環境
9. 現場での実体験が、 カミナシの原点。 CEO諸岡の家業は⾷品製造や空港関連業務、ビル清掃などの事業を営んでおり、 従業員の97.5%がノンデスクワーカーでした。 創業者が体感した現場の実体験が、私たちカミナシの揺るぎない原点です。 当事者として体感した、アナログで前時代的な世界。
10. “現場の基盤” カミナシ 3つの領域をまたぐデジタルインフラに Method 作業 Men ⼈ Machine 設備 電⼦帳票 マニュアル‧研修 コミュニケーション 設備カルテ 1つのアカウントで複数のシステムを利⽤。運⽤の負担軽減とセキュリティ向上
11. “現場の基盤” カミナシ 3つの領域をまたぐデジタルインフラに Method 作業 Men ⼈ Machine 設備 電⼦帳票 マニュアル‧研修 コミュニケーション 設備カルテ 1つのアカウントで複数のシステムを利⽤。運⽤の負担軽減とセキュリティ向上 本日のメイントピック
12. 「カミナシ ID管理」プロダクトビジョン 地球上でもっとも ノンデスクワーカーに寄り添った アイデンティティプロバイダーへ
13. ⾷品製造 ホテル 飲⾷ ⼩売 物流‧運送 医療‧福祉 建設 機械製造 導⼊現場数は15,000超 ⾃動⾞からコンビニまで皆さんの⽣活の裏側にカミナシが
14. ID 基盤開発による共通 ID 化の 意思決定背景
15. 2023 タイムライン 2020.06 「カミナシ レポート」 リリース 🎉 4月 2023.04 「カミナシ レポート」からの 認証切り離し設計着⼿ 3月 2023.03 シリーズB 資⾦調達 マルチプロダクト戦略発表 7月 2023.07 ID情報の移⾏と ダブルライト着⼿ 12月 2023.12 OpenID Connect 準拠 🎉 8月 2024.08 「カミナシ 従業員」 リリース 🎉 2024.08 「カミナシ ID管理」 リリース 🎉 「カミナシ ID管理」の歴史 2023-2024 6月 2023.06 切り離した認証機構のリリース 🎉 9月 2023.09 マルチプロダクト化 探索本格化 2024 2月 2024.02 「カミナシ ID管理」 管理画⾯リリース 🎉
16. 2023 タイムライン 2020.06 「カミナシ レポート」 リリース 🎉 4月 2023.04 「カミナシ レポート」からの 認証切り離し設計着⼿ 3月 2023.03 シリーズB 資⾦調達 マルチプロダクト戦略発表 7月 2023.07 ID情報の移⾏と ダブルライト着⼿ 12月 2023.12 OpenID Connect 準拠 🎉 8月 2024.08 「カミナシ 従業員」 リリース 🎉 2024.08 「カミナシ ID管理」 リリース 🎉 6月 2023.06 切り離した認証機構のリリース 🎉 9月 2023.09 マルチプロダクト化 探索本格化 2024 2月 2024.02 「カミナシ ID管理」 管理画⾯リリース 🎉 ID 管理・認証機構の オーナーシップを独立チームに移行
17. 2023 タイムライン 2020.06 「カミナシ レポート」 リリース 🎉 4月 2023.04 「カミナシ レポート」からの 認証切り離し設計着⼿ 3月 2023.03 シリーズB 資⾦調達 マルチプロダクト戦略発表 7月 2023.07 ID情報の移⾏ ダブルライト着⼿ 12月 2023.12 OpenID Connect 準拠 🎉 8月 2024.08 「カミナシ 従業員」 リリース 🎉 2024.08 「カミナシ ID管理」 リリース 🎉 6月 2023.06 切り離した認証機構のリリース 🎉 9月 2023.09 マルチプロダクト化 探索本格化 2024 2月 2024.02 「カミナシ ID管理」 管理画⾯リリース 🎉 新規プロダクトを受け入れるための インターフェースの準備 2024.08 以降については、後段の『技術・プロジェクト編』にて紹介します
18. 「カミナシ ID管理」のなぜ • 「マルチプロダクトが成功してからで良いのでは？」 • マルチプロダクト化していくという戦略は意思決定済み ◦ シリーズ B 調達時の外部発表も意思決定済み Q: 単一プロダクトしかないタイミングで共通 ID 化を意思決定したのはなぜ？ • マルチプロダクトな SaaS 企業にとって、共通 ID 化の意義は大きい ◦ 理想的なユーザー体験を創出できるだけでなく、「クロスセル」難易度を下げる価値は非常に大きい ◦ 既存顧客基盤の価値が最大化される ◦ 新規顧客が複数プロダクトをセットで購入して使い始める妥当性の創出 → 先人たちが残してくれた、数々の挑戦や苦難の事例 ◦ 共通 ID 化を成し遂げるのに5年の月日がかかりました ◦ 共通 ID 化に3年取り組んできましたが、終わりが見えないので諦めました ◦ ID 基盤以前から存在するプロダクトたちは、共通 ID 化できるメドが立っていません ◦ etc., etc., ... 1 2 3
19. 「カミナシ ID管理」のなぜ → 「現場のデジタル導入が難しいのは、ノンデスクワーカーの業務やユースケースにフィットする 既存アイデンティティ・プロバイダーがないことが背景の一つなのでは？」 • カミナシ社のミッション・ビジョン実現に繋がる重要な仮説の存在 • オーナーシップの明示的分離 ◦ 「カミナシ レポート」は電子帳票プロダクトであり、ID 管理プロダクトではない ◦ 「カミナシ レポート」チームが所有している限り、ID 管理まわりの機能開発や改修優先順位は上がらない Q: ID 管理基盤を独立分離して開発していく意思決定したのはなぜ？ • 新規プロダクト群の「カミナシ レポート」への依存回避 ◦ 新規プロダクトのサービス運用に「カミナシ レポート」が必要以上の責任を追うことは受容できない → ID 管理基盤への投資が、ミッション実現や事業拡大のブロッカー解消に貢献しうる 1 2 3 ◦ 「共用端末」という現場ならではの利用形態 ◦ 全員がメールアドレスを持っているわけではないという特性 ◦ デジタルデバイスの利用は、現場においては主たる業務ではなく付帯業務 ◦ オフィスワーカーユースに最適化されたプライシング, etc., ...
20. ID 基盤内製の意思決定背景
21. 「カミナシ ID管理」のなぜ すべてを満たしうる方法が、結果として「内製」だった ◦ 既存プロダクトを見捨てずに、全プロダクトの ID 統合まで段階的に移行できるプロセスの実現 ◦ グローバルスタンダードなプロトコル準拠と、オフィスワーカー領域で見慣れないユースケースのサポート • 「カミナシ レポート」が置き去りにならない、という必達要件 ◦ ID管理/認証機構を「カミナシ レポート」から順次切り離して段階的に「カミナシ ID管理」に移行した背景 ◦ 「既存プロダクトの方は ID 管理基盤が小慣れてきたら移行しよう...」はだいたい無理 Q: IDaaS (Amazon Cognito, Auth0, ...) で良いのでは？ • OpenID Connect サポートと、ノンデスクワーカー業務の特徴的ユースケース(先述)サポートの両立 ◦ 段階的に移行しながら、「カミナシ レポート」以降の新規プロダクトが OIDC に準拠できること ▪ (詳細は技術パートにて後述) ◦ グローバルスタンダードなプロトコルに準拠しながら、細部にコントロールが効くこと ▪ ノンデスクワーカー業務の特徴的ユースケースのサポートは「カミナシ ID管理」にとってクリティカル • ミッション・ビジョン、それが実現されたときの事業的インパクトの大きさを考えれば譲れない ▪ (詳細は技術パートにて後述) 1 2 3
22. 意思決定当時に選択した トレードオフ
23. 受容したリスクや選択したトレードオフ 新旧問わず全プロダクトでの ID 統合完遂を重視 ◦ 『「カミナシ レポート」は後から合流してもらおう...』なら、もっと楽に短い期間で ID 統合まで完遂できた 可能性もある ◦ 短期的な負荷や難易度の高さを受容し、中長期的に理想状態に到達できる可能性が高い方法を選択した • ID 管理/認証基盤に独立したオーナーシップを確立するためのチーム分離 ◦ 短期売上への貢献が見えにくい基盤製品であるため、人的投資は潤沢にはできない (1名スタート → 2名) ◦ 少人数ゆえの運用・オンコール面での不安定さがあるリスクを受容 ▪ 優秀なメンバーと協力的な社内のおかげもあり、実際にはかなり安定していた ◦ チームを分離するからこそのコミュニケーションオーバーヘッドも受容 • 柔軟な移行プロセスと進化を実現するための内製という決断 ◦ 短期売上への貢献が見えにくい基盤製品であるため、人的投資は潤沢には... ◦ 内製(つまり IDaaS を使わない)でありながら、ID 統合完遂までの期間を不必要に長期化させないために、 「セントラルな認可機構」を初期機能スコープから外すことを決断 1 2 3
24. カミナシ ID管理基盤の技術
25. カミナシ ID管理のアーキテクチャ Amazon CloudFront Application Load Balancer Amazon Elastic Container Service AWS App Runner Amazon DynamoDB Amazon Aurora PostgreSQL AWS Lambda Amazon DynamoDB ID管理・認証認可API ID管理フロントエンド 内製のID管理基盤は基本的には一般的なWebアプリケーションスタックと同様。
26. カミナシ ID管理のアーキテクチャ Amazon CloudFront Application Load Balancer Amazon Elastic Container Service AWS App Runner Amazon DynamoDB Amazon Aurora PostgreSQL AWS Lambda Amazon DynamoDB ID管理・認証認可API ID管理フロントエンド ory/fositeというライブラリ を使って認証認可基盤を内製 メールによる認証コード送信 用のLambda 端末認証につかう mTLS用のALB
27. カミナシはID管理をなぜ内製したのか （技術的な側面）
28. カミナシはID管理をなぜ内製したのか（技術的な側面） 1 2 ID管理におけるテナント分離境界 ビジネスユースケースにあわせたOAuth拡張仕様適用
29. マルチテナントSaaSのID管理におけるプールとサイロ 認証ドメイン 外部IdP接続 セキュリティポリシー ユーザー テナントA 認証ドメイン 外部IdP接続 セキュリティ ポリシー ユーザー テナントB 認証ドメイン 外部IdP接続 セキュリティ ポリシー ユーザー マルチテナントSaaSでは、ID管理に関する各種リソースについてテナントを横断して管理するか、 もしくはテナントごとに管理するか、ビジネスユースケースによって変わってくる。 プールモデルの一例 サイロモデルの一例
30. テナント分離境界1/3：認証ドメインのテナント分離境界 ログイン時の入口となるURLをテナントごとに分離するかどうか。既存の認証機能がある場合、元々提供し ていたURLから変更するのは顧客コミュニケーションも含めて困難な場合がある。 また、顧客ごとにログインUIを変更したい（e.g. ロゴを出したい）といった場合もある。 auth.xxx.com tenantA.auth.xxx.com tenantB.auth.xxx.com tenant A tenant B tenant A tenant B
31. テナント分離境界2/3：クライアントや外部IdPのテナント分離境界 特にB2Bでは顧客企業で社内利用しているID管理基盤からフェデレーションしたいという要望が多いため、 テナントごとに接続可能な外部IdPを設定管理する必要がある。 テナントA テナントB カミナシのIdP テナントA 社内IdP用 クライアント テナントB 社内IdP用 クライアント
32. テナント分離境界3/3：ユーザーのテナント分離境界（あるいはテナント自身の境界） パスワードポリシーなどセキュリティポリシー設定を含めた各種リソースをテナントごとにテナント管理者に よって設定することが求められるケースも多い。 また、ユースケースが広がってくるとテナントの親子関係や、それによる管理者の管理可能な範囲を作り込む 必要が出てくる。 tenant A tenant B tenant A-1 tenant A-2 tenant A-3 異なるテナントの管理はできない 子テナントの管理の要求 パスワードポリシー パスワードポリシー
33. カミナシはID管理をなぜ内製したのか（技術的な側面） 1 2 ID管理におけるテナント分離境界 ビジネスユースケースにあわせたOAuth拡張仕様適用
34. OAuth拡張仕様：カミナシにおけるOAuth拡張仕様の適用事例 現場に設置されたタブレットを複数人が共用して操作するという利用シーン。 ログインID/パスワードを共有して利用するケースも。 複数人が共有することで漏洩リスクの増大 わかりやすいパスワードの設定 退職者の不正利用リスク ログインID/パスワードの共有
35. OAuth拡張仕様：カミナシにおけるOAuth拡張仕様の適用事例 [1] https://tools.ietf.org/html/rfc8705 RFC8705 Mutual TLS Client Authentication and Certificate-Bound Access Token [1] ①クライアント証明書とともに相互TLS接続して デバイス自身が認証しつつトークンリクエスト ②クライアント証明書に基づきクライアント認証してトークン応答 OAuth mTLSはクライアント証明書を利用した相互TLS接続に基づくクライアント認証と、証明書で 送信者制約したアクセストークンの払い出しと利用のOAuth拡張仕様。 これを利用することで、特定の端末が物理的に窃取されなければ安全なアクセスが可能となる。 端末自体のパスコードロックと組み合わせて所有+知識認証の運用も可能。
36. カミナシにおける ID管理基盤の立ち上げからID統合まで
37. カミナシ ID管理の立ち上げからID統合までの歩み フェーズ 1 既存プロダクトから 認証機能の切り出し フェーズ 2 新プロダクトのオンボーディング OpenID Connectへの切替 フェーズ 3 ID統合 カミナシレポート 認証機能 カミナシID管理 切り出し カミナシID管理 カミナシ レポート カミナシ 従業員 他 旧認証機能 新認証機能 ID管理機能 カミナシID管理 カミナシ レポート カミナシ 従業員 他 新認証機能 ID管理機能 ID管理機能
38. フェーズ１：認証機能の切り出し 最速で共通認証基盤を立ち上げるため、ミニマムスコープで既存プロダクトから認証機能を切り出した。 やらないと選択したこと： • 既存プロダクトを標準プロトコル（OpenID Connect準拠）へ切り替える • ID管理機能（ユーザー登録、編集、削除など）を立ち上げた基盤に移行する →スコープを最小限に絞り早期立ち上げすることで、「既存プロダクトの収容」と「新規プロダクトが 　共通ID管理基盤を利用する意思決定への重力」を両立する カミナシ レポート カミナシ ID管理 ログイン試行 ユーザー情報の問い合わせ カミナシ レポート カミナシ ID管理 ステップ1：機能だけ切り出し ステップ2：データの切り出し ユーザー管理 ユーザー情報の同期 自己完結してログイン 処理できるように
39. フェーズ2：新プロダクトのオンボーディング、OpenID Connectへの切替 新プロダクトに対してOpenID Connectに則った認証機能とID管理機能を提供。 既存プロダクトの認証機能をOpenID Connectに移行。 やらないと選択したこと： • 既存プロダクトのID管理機能（ユーザー登録、編集、削除など）を立ち上げた基盤に移行する • 同一ユーザーがマルチプロダクトを利用できるようにする（＝ID統合しないことの選択） →既存プロダクトの管理画面移行によるハレーションを回避して新規プロダクトを共通ID管理基盤に 　迅速にオンボーディング カミナシ レポート カミナシ ID管理 ユーザー情報の同期 カミナシ 従業員 OpenID Connectへ移行 OpenID Connect カミナシID管理の ユーザー管理画面 カミナシレポートの ユーザー管理画面
40. フェーズ3：ID統合 既存プロダクトと新プロダクトを同一ユーザーで利用できるように統合し移行を完了。 やらないと選択したこと： • 全テナントを一括で統合すること • 既存プロダクトのユーザーデータモデルを大幅に変更すること →・お客様の導入状況や利用規模によっては調整に1ヶ月以上要したため、フィーチャーフラグで個別切替 　・既存プロダクトのDBのデータモデルに大幅な変更を加えるリスクと工数を回避 カミナシ レポート カミナシ ID管理 カミナシ 従業員 OpenID Connect OpenID Connect カミナシID管理の ユーザー管理画面 既存プロダクトのデータモデルを 残すためイベント連携でコピー 既存プロダクトユーザーも 共通ID管理基盤画面に移行
41. ID統合に関する詳細はカミナシエンジニアブログで！ スタートアップがゼロから作る共通 ID基盤：立ち上げ〜 ID統合まで道のり（前編） 本発表中に公開しました！できたてホヤホヤ！
42. まとめ
43. まとめ • ビジョンや中長期の勝ち筋と、短期の事業戦略に接続性が見出だす ◦ これにより、中長期を意識した意思決定が比較的容易になる ◦ (残念ながらまったく繋がりを見出せず、ただのポエムになることもある) • ID 管理基盤の開発は、基本的には IDaaS の活用がオススメ ◦ 多くの企業にとって、ID 管理基盤の開発は “Undifferentiated Heavy Lifting” ◦ “差別化に繋がらない重労働” は IDaaS やマネージドサービスに任せ、自分たちのビジネスの差別化につなが る領域にフォーカスすべき ◦ カミナシでは、たまたま ID 管理基盤が自社ビジネスの差別化に繋がる重要領域だった • マルチテナント B2B SaaSにおける ID 管理や認証認可はおもしろい ◦ ID管理における各種リソースのプールが重要な観点の一つ ◦ 認証認可に対しても複雑な要件だからこそ標準化された仕様を適用する ◦ ID統合は技術力、社内外調整力、気合いの総合格闘技 • ノンデスクワーカーの業務特性や特徴的な環境をサポートできるアイデンティティプロバイダーの 開発には重要な意義があり、そしてとても楽しい ◦ おもしろくて、楽しいので、つまり...
44. まとめ 「カミナシ ID管理」チームでは、絶賛仲間を募集中です！ 登壇した2名以外も懇親会に参加しています！ぜひ気軽にお声がけください 🙌 ENG-4003 シニアソフトウェアエンジニア 「カミナシ ID管理」 - IAM ENG-4005 シニアソフトウェアエンジニア 「カミナシ ID管理」 - フロントエンド