記事のサマリー（TL;DR）
- SmartHRが2026年2月、認証・認可を専任で担う「認証・認可基盤ユニット」を新設
- モノリスに内包された認証機能の課題（セキュリティ境界の欠如・リリース独立性の欠如・単一障害点）を解消するため、マイクロサービスへの段階移行を選択
- ストラングラーフィグパターン＋ダークローンチ＋カナリアリリースを組み合わせた無停止移行を目指す
国内 SaaS プロダクト基盤チームが参照すべき認証分離の設計判断
マルチプロダクト展開が進む SaaS では、認証機能がモノリスに埋め込まれたまま複数チームが手を入れ続けることで、境界のない認証コードが蓄積しやすい。SmartHR の事例は「オーナーシップ不在の認証実装の積み重ね」という問題が顕在化するタイミングと、モジュラモノリス（Packwerk）では解消しきれない限界を具体的に示している。
kintone や Salesforce のような外部 SaaS と連携する IDaaS 領域を持つプロダクトでも、認証領域の責務境界が曖昧なまま SSO（SAML・パスキー）対応を追加すると同様の構造的債務が生まれる。イベントストーミングで「認証 / IDaaS / 認可」を明確に分割してから実装に入るアプローチは、規模を問わず再現性が高い。
詳細
認証・認可基盤ユニットとは
SmartHR のプロダクト基盤開発本部は、権限管理・課金・従業員データ活用など、プロダクト横断の基盤を整備する組織です。その中に従来「権限基盤ユニット」が存在しており、Policy-as-Code によるアクセス制御や新しい権限基盤の設計を進める過程で、認可だけでなく認証を含めた領域全体のアーキテクチャ課題に向き合う必要性が高まりました。その結果、2026年2月に独立したユニットとして「認証・認可基盤ユニット」が再編されました。
現在は少人数のプロダクトエンジニアで構成されていますが、扱うテーマは全プロダクトの土台となる領域です。
ミッション・ビジョン・バリュー
チームの方向性は次のように定義されています。
- ミッション：認証・認可のボトルネックを解消し、安全で高速な価値提供を支える基盤を提供する
- ビジョン：認証・認可が透明に機能し、各プロダクトがビジネスロジックに集中できている状態
- バリュー
- セルフサービスの提供：API とドキュメントだけで実装を完結させる
- 柔軟性：多様な認証・認可要件に対応する
- 仕組みによる統制：自動化されたガードレールで安全性を担保する
キーワードは「透明に機能する」です。認証・認可はすべてのプロダクトに必要でありながら、それ自体がプロダクトの価値の中心になることはありません。だからこそ、各プロダクトの開発者が認証・認可に悩まず、ビジネスロジックに集中できる状態を目指しています。
なぜ今、認証・認可の基盤なのか
マルチプロダクト戦略と認証の重要性
SmartHR はマルチプロダクト戦略を掲げ、労務管理からタレントマネジメントまでプロダクトを拡大し続けています。事業規模の拡大を見据えたとき、プロダクト基盤には次の3点が求められます。
- 市場への迅速な価値提供：新機能やセキュリティ改善を素早く市場に投入できる体制
- サービスの信頼性確保：大規模なトラフィックに耐え、障害時の影響を最小化できるインフラ
- セキュリティ品質の向上：機密性の高い人事情報を扱う以上、高いセキュリティ水準は顧客からの信頼の前提条件
これらを満たすには、SAML SSO（Security Assertion Markup Language を用いたシングルサインオン）やパスキー対応といった認証機能が不可欠です。これを「守りのコスト」ではなく「事業成長を支える価値創出の起点」と位置づけることが、このユニットの出発点でした。
モノリスに内包された認証が抱える3つの構造的課題
現在、SmartHR の認証機能はコアサービス（モノリス）に内包されており、過去には複数のプロダクトチームが手を入れられる状態でした。プロダクトが少なかった時代はそれで合理的でしたが、オーナーシップが不在のまま個別要件に特化した実装が積み重なっていきました。マルチプロダクト化が進むにつれ、次の3つの構造的課題が顕在化しています。
① セキュリティ：責務境界の欠如
認証コードとビジネスロジックが同一プロセス内にあるため、モノリス内のどのコードも理論上は認証の内部状態（セッショントークン）にアクセスできます。認証と無関係な変更が意図せずセキュリティを低下させるリスクを制御できず、ペネトレーションテストや第三者監査で「認証だけ」を審査することもできない状態でした。
② デリバリ：リリースの独立性の欠如
認証の改善をリリースしたくても、モノリスのデプロイサイクルに依存するため単独リリースができません。仮説検証のサイクルがモノリスのリリースサイクルに律速され、市場への価値提供が遅れます。
③ 可用性：単一障害点（SPOF）
モノリスで障害が発生すると認証機能も停止し、SmartHR の全プロダクトにログインできなくなります。認証は他サービスの稼働状況にかかわらず提供され続けるべき機能であるにもかかわらず、その独立性が担保されていませんでした。
ドメインの整理：まずは認証領域にフォーカス
これらの課題はいずれも、認証がモノリスに内包されている限り根本解決できません。そこでチームはイベントストーミングなどを通じて、漠然と「認証周り」と呼ばれていた領域を3つのドメインに整理しました。
| ドメイン | 役割 |
|---|---|
| 認証領域（現在フォーカス） | ユーザーの同一性を検証・保証（SmartHR の IdP 機能） |
| IDaaS 領域 | 同一性担保後の外部 SaaS との連携 |
| 認可領域 | 同一性が保証されたユーザーのリソースへのアクセス制御 |
現在は認証領域に集中しており、ここの責務境界が明確になれば、IDaaS 領域・認可領域もそれぞれ独立して進化できると考えています。
なぜマイクロサービスなのか——モジュラモノリスの限界
SmartHR ではモジュラモノリス化も並行して進めてきました。認証・認可についても「モジュラモノリスのまま責務境界を整理すればよいのでは」という選択肢を検討しています。
しかし、パッケージ間の依存を宣言・静的解析で検出するために導入した Packwerk には限界がありました。SmartHR ではテナントや課金体系をもとにした業務上の認可が多く存在し、認可機能が課金・テナントに依存する必要があります。その依存を Packwerk 上で許容すると、変更頻度の高い領域に認可が引っ張られる構造になり、境界の見直しに弱いという問題が残りました。
さらに、モジュラモノリスでは前述3課題のうち「デリバリ（リリースの独立性）」と「可用性」を解消できません。そこで認証については、コードベースを物理的に分離できるマイクロサービスを採用しました。プロセスを分離することで責務境界を物理的に強制でき、独立デプロイと障害分離による可用性向上も見込めます。マイクロサービス化が運用の複雑さやネットワーク境界をまたぐ通信コストを新たにもたらすことは認識したうえで、「可用性と独立デプロイがもたらす価値がその代償を上回る」と判断しています。
移行戦略：ストラングラーフィグ＋ダークローンチ＋カナリアリリース
認証は停止できません。ビッグバンリライトは事業リスクが大きすぎるため、ストラングラーフィグパターン（既存システムを一度に置き換えず、新システムで機能を少しずつ包み込むように移していく手法）による段階的移行を選択しています。
具体的には、次の手法を組み合わせます。
- ダークローンチ：新経路に本番トラフィックを流しつつ、結果は利用者に見せずに挙動を検証する
- カナリアリリース：一部トラフィックから段階的に新系統へ切り替える
エンドポイント単位でダウンタイムを可能な限り抑えた移行を目指し、既存の振る舞いを維持したまま切り出す「リフト」を先行させ、機能改善はその後に行う方針です。
目指す達成状態
この取り組みで目指すのは次の3点です。
- 認証領域の独立性確保：認証機能が独立したシステムとして運用され、他チームとの調整なしに任意タイミングでリリースできる。他システムの障害が認証に波及しない。
- 認証方式の統一とセキュリティ品質の向上：全プロダクトで一貫した認証方式を採用し、監査可能な状態で運用する。ペネトレーションテストや第三者監査を認証範囲に絞って実施できる。
- ビジネス規模に対応した可用性基準の確立：将来の事業規模を見据えた可用性目標（SLO）を設定し、監視と障害対応の体制を整備する。
これからの取り組み
ユニット発足からこれまでは、認証領域の課題を構造化し、戦略・戦術を策定したうえで認証基盤の設計・実装に着手してきました。「なぜやるのか」「何をもって成功とするのか」をステークホルダーと合意してから手を動かすことを大切にしています。
今後は既存機能を維持したままの段階的な切り出し（リフト）を推進し、設計と実装のフィードバックサイクルを短く回しながらイテレーティブに基盤を育てていく方針です。さらにユニット名にある「認可」の通り、前身チームで培った Policy-as-Code によるアクセス制御の知見も活かしながら、将来的には認可領域にも着手していく予定です。
このユニットで働く面白さ
チームの醍醐味として、次の3点が挙げられています。
- 抽象と具体の往復：各プロダクトの個別要件を抽象化し「基盤」として再定義する。具体的な課題から汎用的なソリューションを導き出すモデリングの面白さがあります。
- セルフサービスと安全性の両立：「各チームが自律的に開発できる」と「安全性を担保する」を、自動化されたガードレールという仕組みで同時に実現します。
- ミッションクリティカルな環境での設計：認証の障害は全プロダクトに影響するため、高可用性・高性能が必須の緊張感の中で「信頼性」を追求できます。
得られる成長としては、認証・認可という複雑なドメインでの設計・モデリング経験、不確実性の高い課題を構造化する力（戦略レベルの構想から要件定義・設計まで）、大規模システムの移行戦略を立案・実行する力、そして多様なステークホルダーとの期待値調整や合意形成力が挙げられています。