社員マスタ連携の認証設計が招くリスク
社員マスタと連携した認証設計は、ID管理の一元化と運用効率の観点から、多くの大企業で採用されている定石の構成です。入退社処理や権限付与を人事システム起点で自動化できるため、情シス部門の運用負荷を大きく下げる効果があります。
一方で、この設計は基盤側（人事システムや社員マスタ）のID体系に強く依存するため、基幹システム刷新やM&Aに伴うID体系変更が発生した際に、連鎖的な改修コストが顕在化するという構造的リスクを抱えています。追加投資が必要となるケースも珍しくありません。
本記事では、社員マスタ連携型の認証設計が持つ隠れたコスト構造を、責任分界と改修工数の観点から解説します。
目次
社員マスタ連携型認証設計の一般的な構成
多くの大企業では、人事システムに登録された社員マスタを、ID管理における最上位のマスターソース（信頼できる唯一の情報源）として位置づけ、そこから各種業務システムやSSO（シングルサインオン）基盤へIDと属性情報を連携する構成が採用されています。
典型的な流れは以下の通りです。
- 人事システムで社員データを登録・更新
- 社員マスタから認証基盤（IDaaS、Active Directoryなど）へ連携
- 認証基盤から各業務システムへID・権限情報を配布
- 各業務システムはこの情報をキーとして認可判定
この構成は、ID管理の標準化を進める上で有効であり、監査対応や退職者の権限剥奪といったガバナンス面でも大きな利点があります。
リスクが顕在化する分岐点：ID体系の変更
問題が生じるのは、基盤側のID体系そのものが変更される場面です。主な発生シーンは次の3つです。
- 基幹システム（人事システム）の刷新に伴う社員番号体系の変更
- M&Aや組織統合に伴うID体系の統合
- グローバル展開に伴う海外法人の社員IDフォーマット統合、国内外で異なる採番ルールの統一
これらの局面では、社員IDそのものがキーとして連携先システムに残っているため、変更が下流の全システムに波及します。連携先が10システムであれば10システム、50システムであれば50システム分の改修が発生する構造です。
改修コストが「連鎖的に増える」順番
改修コストがどのように積み上がるかを、実際の順序で見ていきます。
第一段階は、認証基盤側の改修です。ID体系の変換ロジックやマッピングテーブルの整備が必要になります。
第二段階は、連携先システム側の改修です。旧IDでログや権限データを保持しているシステムでは、履歴データの移行、ログ検索条件の変更、通知先設定の再構成といった調整が増えます。
第三段階は、外部SaaSとの連携部分です。SAMLのNameIDやOIDCのsubクレームに旧社員番号を使っているケースでは、SaaS側の設定変更・ユーザー再紐付け作業が発生します。SaaSベンダーとの調整、ライセンス再割り当て、監査ログの整合性確認まで含めると、1サービスあたり数日〜数週間の工数が発生することもあり、SaaSの設定自由度によっては対応そのものが難しいケースもあります。
第四段階は、業務プロセス側の見直しです。ワークフローの承認者設定、BIツールでのアクセス権、共有ドライブの権限など、社員IDを直接参照している箇所の棚卸しと再設定が必要となります。
連携先が20〜30システムを超える大企業では、改修コストが当初見積もりの数倍に膨らむケースが実際に発生しています。
なぜこのリスクは事前に見えにくいのか
このリスクが導入時に見過ごされやすい理由は、責任分界の曖昧さにあります。認証基盤の設計は情シス部門、社員マスタは人事部門、各業務システムは各業務部門と、責任範囲が分散しているため、ID体系変更時の影響範囲を横断的に評価できる部門が存在しない場合が多いのです。
また、認証設計の初期段階では「連携すること」自体が主目的となり、将来のID体系変更を前提とした設計になっていないケースが多く見られます。社員番号を直接キーとして使うか、内部的な代替キー（UUID等）を発行して抽象化するかで、将来の改修工数は大きく変わります。
設計時に確認すべき観点
将来の改修コストを抑えるため、設計時点で以下の観点を確認することが判断軸になります。
- 認証キーとして社員番号そのものを使うか、代替の不変IDを使うか
- 社員マスタと認証基盤の間に変換層を挟むか
- 連携先システムに配布する属性のうち、どれを不変とみなすか
- ID体系変更時の影響範囲を、契約・SLA上でどこまで明文化するか
- 責任分界（人事／情シス／業務部門）の役割定義
具体的な実装パターンとしては、社員マスタと認証基盤の間にSCIM準拠のプロビジョニング層を挟み、ID体系変更時の変換処理を一箇所に集約する方法が有効です。また、UUIDなどの不変IDをSAMLのNameIDやOIDCのsubクレームとして発行し、社員番号は変更可能な属性の一つとして別途連携する設計にしておくことで、基盤側のID体系変更が下流システムに波及しにくくなります。
これらは認証基盤の選定段階、あるいはSSO・IDaaSの導入検討初期に整理しておくことで、後年の手戻りを大きく減らすことができます。
よくある質問（FAQ）
Q. 既に社員番号を直接キーとして認証設計している場合、今から変更すべきでしょうか。
直ちに全面的な作り替えを推奨するものではありませんが、次の基幹刷新やSaaS追加のタイミングで、代替キーへの移行を段階的に検討することが有効です。まずは現状の依存関係の棚卸しから始めることをおすすめします。
Q. SSOやIDaaSを導入すればこの問題は解決しますか。
IDaaS導入そのものが解決策になるわけではありません。IDaaS側でどのような属性をキーとして扱うか、連携先にどの属性を配布するかといった設計思想が、将来の改修工数を左右します。製品選定より先に、認証キーと属性連携の設計方針を固めることを優先してください。
Q. 改修コストの概算をどのように見積もればよいでしょうか。
連携先システム数、各システムでの社員番号の使われ方（認証キー／ログキー／権限キー／外部連携キー）、SaaS契約数の3軸で整理すると、影響範囲がおおよそ見えてきます。個別の見積もりについては、現状のシステム構成をもとにご相談ください。
LYZONが提供するWebサービス
Webに関するお悩みは、まずLYZONへ
構築・運用・AIまで、Webに関わる課題をワンストップで対応。まず何ができるかをご覧ください。
2015年入社。
サポートデスクとして下積み期間を経てディレクターに転身。主に運用案件を担当。
家に帰れば、息子2人の胃袋を満たすべく食事作りに追われている。
