---
title: "統合ID管理システムとは：人事マスタ連携の仕組みとAD・IDaaS併存の構成、大企業の要件"
url: "https://www.issoh.co.jp/column/details/18708/"
published: 2026-10-21
updated: 2026-10-21
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# 統合ID管理システムとは：人事マスタ連携の仕組みとAD・IDaaS併存の構成、大企業の要件

統合ID管理システムとは、人事システムの社員情報を起点に、Active Directory・Microsoft 365・業務システム・SaaSに散らばったIDを1人1つの統合IDに束ね、作成・変更・削除をまとめて管理する仕組みです。統合ID管理ツールの製品ページは機能の一覧から入りますが、導入の成否を分けるのは、どのデータを正とし、どの順番でIDを流すかという構成の設計です。この記事では、統合認証やIGAとの違い、人事システム連携の処理の流れ、オンプレミスのActive DirectoryとEntra ID・IDaaSを併存させる構成、グループ会社やM&Aで複数の人事システムを統合するときの制約、大企業が確かめる要件と導入を見送る条件までを整理します。

## まとめ：統合ID管理システムは人事マスタを起点に全システムのIDを1つに束ねる基盤

統合ID管理システムの役割は、人事マスタを唯一の正として統合IDを発行し、そこから各システムへアカウントを配ることです。ログインを1回にするSSOや、権限の妥当性を定期的に見直すIGAとは担当が分かれます。統合IDの番号は社員番号やメールアドレスと切り離して採番し、改姓・転籍・再雇用でも変わらない値にしておくと、後からつなぐシステムが増えても照合が崩れません。

構成は「人事システム、統合ID管理、Active Directory、Entra ID、SaaS」の順に一方向で流すのが基本形です。ADのオブジェクトがドメインあたり15万を超える、グループ会社ごとにADフォレストやEntraテナントが分かれている、といった大企業の条件では同期方式の選び方が変わります。人事システムが1つで異動が少なく、SaaS中心の組織なら、統合ID管理システムを別に入れずIDaaSの標準機能で足ります。

## 統合ID管理システムの定義と統合認証・SSO・IGAとの役割の切り分け

「統合ID管理」は製品カテゴリの呼び名として使われ、範囲が製品ごとに少しずつ違います。認証・認可・IDライフサイクルの全体像は[認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選び方](https://www.issoh.co.jp/column/details/13631/)にまとめているので、ここでは「統合」が何を指すかに絞ります。

### 分散したIDを1人1つの統合IDに束ねて作成から削除まで一元管理する仕組み

統合前の典型的な状態は、ADのアカウント名、会計システムのユーザーコード、勤怠システムの社員番号、SaaSのメールアドレスと、同じ社員に4種類のIDが付いている状態です。誰がどのシステムにアカウントを持っているかを一覧にできないため、退職時の停止漏れが起きます。

統合ID管理システムは、この4種類のIDを1つの統合IDにひも付けた台帳を持ち、人事の発令に合わせて各システムへ作成・変更・削除を指示します。台帳が1つになることで「この人のアカウントはどこにあるか」に答えられるようになる。これが「統合」の中身です。

### 統合認証やSSOとの違いはログインでなくIDの台帳と配布を担う点にある

統合認証という言葉は、ID管理とシングルサインオンの2つを合わせた意味で使われることが多くあります。統合ID管理システムが受け持つのはそのうちID管理の側で、ログイン画面やトークンの発行は担当しません。SSOを入れても連携先にアカウントが無ければログインできず、残っていれば別経路のパスワードログインが通ります。

権限の付与が正しいかを上長に定期確認させるアクセス認証は、[IGA（IDガバナンス）](https://www.issoh.co.jp/column/details/18704/)の領域です。ID管理と認可を合わせた全社基盤の層構成は[IDおよびアクセス管理（IAM）とは](https://www.issoh.co.jp/column/details/18706/)で扱っています。統合ID管理はその中で「ID台帳と配布」の層にあたります。

## 人事システム連携で統合IDが作られて各システムへ届くまでの処理の流れ

統合ID管理システムの中核はプロビジョニングです。ただし「人事データを取り込んで配る」の手前に、何を正とし、どの番号で人を識別するかを決める設計があります。

### 人事マスタを正とするSource of Authorityの考え方と取り込む項目

Microsoftの[人事主導のプロビジョニングの解説](https://learn.microsoft.com/ja-jp/entra/identity/app-provisioning/what-is-hr-driven-provisioning)は、人事システムをデジタルIDの権限のある起点（Source of Authority）として扱い、新規採用・属性の更新・退職・再雇用の4場面を自動化の対象に挙げています。統合ID管理でも考え方は同じで、氏名や所属をADやSaaS側で直接書き換えず、必ず人事マスタを直して流します。

取り込む項目は、社員番号・氏名・所属コード・役職・雇用区分・入社日・退職日・発令日の8項目が最低限です。派遣社員や業務委託を人事システムで管理していない会社では、別の台帳を2つ目の起点として足すことになります。[人事システムとは？機能・種類・選び方](https://www.issoh.co.jp/column/details/13557/)の段階で、ID管理に渡す項目と入力のタイミングを人事部門と合意しておくと手戻りが減ります。

### 発令日の予約反映と兼務・出向を統合IDの属性に持たせる運用設計

大企業で問題になるのは、4月1日付の一斉異動を3月中に登録する「予約発令」と、兼務・出向の扱いです。統合ID管理システムは、発令日を属性として持ち、当日の0時に所属とグループを切り替える処理を備えている製品が多くあります。兼務は主所属と兼務所属を別の属性で持ち、権限は両方の所属から合算します。

この設計を省いて「現在の所属」だけを持たせると、異動日の前日に権限が切り替わる、出向者が出向元と出向先の両方の権限を持ち続ける、といったずれが起きます。製品ごとの対応状況の比べ方は[ID管理システム比較：4タイプの違いと人事連携・棚卸しで選ぶ機能要件](https://www.issoh.co.jp/column/details/18694/)で整理しました。

### 統合ID番号の採番ルールとログインIDを社員番号から切り離す理由

統合IDの番号には、社員番号をそのまま使わず、統合ID管理システムが採番する不変の番号を使うことを勧めます。社員番号はグループ内転籍や再雇用で振り直されることがあり、メールアドレスは改姓で変わるためです。

| 識別子        | 変わる場面       | 統合IDとしての適否  |
| ---------- | ----------- | ----------- |
| 統合ID番号（採番） | 原則変わらない     | 照合キーに使う     |
| 社員番号       | 転籍・再雇用で振り直し | 属性として保持する   |
| メールアドレス    | 改姓・ドメイン変更   | ログインIDにのみ使う |
| ADのアカウント名  | 命名規則の変更     | 配布先の値として持つ  |

統合IDの番号と各システムのIDを対応づける表を台帳に持てば、ログインIDの命名規則を後から変えても照合は崩れません。照合キーの選び方で重複アカウントが生まれる仕組みは、比較記事の該当章で具体例を挙げています。

## オンプレミスADとEntra ID・IDaaSを併存させる統合ID管理の構成パターン

日本の大企業の多くは、オンプレミスのActive DirectoryとMicrosoft Entra IDを併存させています。統合ID管理システムをどこに置き、どちら向きにIDを流すかで、構成は大きく2つに分かれます。

### 人事から統合ID管理・AD・Entra IDの順に流す構成とクラウド同期の役割

最も多いのは、統合ID管理システムがADにアカウントを作り、ADからEntra IDへは同期ツールで上げる構成です。この同期にはMicrosoft Entra Connect SyncかMicrosoft Entra Cloud Syncを使います。[Cloud Syncの公式解説](https://learn.microsoft.com/ja-jp/entra/identity/hybrid/cloud-sync/what-is-cloud-sync)によると、Cloud Syncは送信接続だけを使う軽量なエージェントで、同期は2分ごとに実行され、複数のエージェントを別サーバーに置いて自動で切り替えられます（2026年10月時点）。

この構成では、AD側でアカウントを手作業で作る運用を止めることが前提です。統合ID管理システム以外の経路でADにユーザーができると、台帳に載らないアカウントが同期でクラウドまで上がります。Entra IDとADの役割の違いは[Microsoft Entra ID（旧Azure AD）とは？Active Directoryとの違い](https://www.issoh.co.jp/tech/details/3163/)を参照してください。

### Entra Connect SyncとCloud Syncの選定：オブジェクト数・機能差

同期ツールの選択は、大企業ほど規模の上限で決まります。[Microsoftの移行判断ガイド](https://learn.microsoft.com/ja-jp/entra/identity/hybrid/cloud-sync/connect-to-cloud-sync-decision-guide)の比較表から、統合ID管理の構成に効く行を抜き出します（2026年10月時点）。

| 項目              | Connect Sync | Cloud Sync |
| --------------- | ------------ | ---------- |
| ドメインあたりのオブジェクト数 | 無制限          | 150,000まで  |
| グループのメンバー数      | 250,000まで    | 50,000まで   |
| 切断されたフォレスト      | 非対応          | 対応         |
| 複数ドメインの属性マージ    | 対応           | 非対応        |
| 同時に動く同期インスタンス   | 1つ           | 複数         |

同じガイドは、新しい同期機能は主にCloud Syncで開発されると明記しています。従業員と退職者・共有アカウント・PCを合わせてドメインあたり15万オブジェクトに収まるならCloud Sync、超えるか複数ドメインの属性を1人に合成しているならConnect Syncを残す、という分け方が現実的です。PCのコンピューターオブジェクトも数に入る点は見落とされがちです。

### IDaaSを統合ID管理の主役にしてADを縮小していく移行の順序

もう1つの構成は、人事システムからEntra IDなどのIDaaSへ直接IDを流し、ADは縮小させる方向です。ここで確認すべき制約があります。移行判断ガイドの比較表では、クラウドからADへのグループのプロビジョニングはCloud Syncで対応する一方、ADへのユーザーのプロビジョニングはConnect Sync・Cloud Syncのどちらも対応していません（2026年10月時点）。

つまりADにログインする社内システムやファイルサーバーが残る間は、ユーザーをADに作る経路を別に持つ必要があります。順序としては、SaaSの配布をIDaaSへ移し、AD依存のシステムを減らしてから人事起点をIDaaS側へ切り替える流れです。IDaaSが受け持てる範囲は[IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携](https://www.issoh.co.jp/tech/details/16401/)で確認できます。

## グループ会社やM&Aで複数の人事システムとADを統合するときの要件

「id管理システム 大企業」で調べる読者の多くが抱える課題は、1社分の統合ではなく、グループ会社ごとに分かれた人事システム・AD・テナントの統合です。ここは製品ページにほとんど書かれていない領域です。

### 切断されたADフォレストを統合せずに1つのテナントへ同期する方法

買収した会社のADフォレストと親会社のフォレストの間に信頼関係もネットワーク接続も無い状態を、Microsoftは「切断されたフォレスト」と呼びます。Cloud Syncは各フォレストにエージェントを置くだけで、フォレストを統合せずに1つのEntraテナントへ同期できると[公式に記載](https://learn.microsoft.com/ja-jp/entra/identity/hybrid/cloud-sync/what-is-cloud-sync)されています。

統合ID管理の観点で注意すべきは、同じ人物が両方のフォレストにアカウントを持つ場合です。出向者や兼務者がいると、テナント上に同一人物が2人できます。同期を始める前に、統合ID番号で両社の社員を名寄せし、どちらのアカウントを正にするかを決めてください。

### テナントを分けたままグループ会社のIDを相互に配るテナント間同期の制約

会社ごとにEntraテナントを持ち続ける場合は、テナント間同期で他社テナントに自社社員のアカウントを作れます。[公式の概要ページ](https://learn.microsoft.com/ja-jp/entra/identity/multi-tenant-organizations/cross-tenant-synchronization-overview)によると、同期はソーステナントからのプッシュで、同期できるのはソースの内部メンバーだけです。間隔は40分固定、ユーザーの同期にはソース側で1人ずつEntra ID P1、グループの同期にはEntra ID GovernanceまたはEntra Suiteのライセンスが要り、入れ子のグループは対象外です（2026年10月時点）。

同じページは、テナント間同期は移行ツールではないとも明記しています。グループで統合IDを1つにしたいのか、各社のIDを残して相互に見えればよいのかを先に決めないと、テナント間同期とテナント統合のどちらを選ぶかが定まりません。退職の反映が最大40分遅れる点も、即時停止の手順と合わせて設計に入れます。

### グループ共通の統合ID番号と会社ごとの社員番号を対応づける名寄せ

複数の人事システムを束ねるときは、グループ共通の統合ID番号を発行し、各社の社員番号を属性として並べて持つ形にします。名寄せは氏名と生年月日だけで機械的に突き合わせると、同姓同名の誤結合が起きます。社内メールアドレスや入社日を組み合わせて候補を出し、最後は人事担当者が確認する手順が安全です。

名寄せの結果を統合ID管理システムに投入する前に、一致しなかった人の一覧を各社に戻して確認する期間を2〜4週間取ると、稼働後の重複アカウントの問い合わせが減ります。

## 大企業が統合ID管理システムに求める要件と自社開発システムをつなぐ範囲

数千人から数万人規模の統合では、機能の有無より、処理時間と記録の残り方で製品の差が出ます。

### 数万ID規模で確かめる同期時間・処理の冗長化・変更履歴の非機能要件

確かめる順は次のとおりです。最初に、4月1日の一斉異動のように数千件の変更が同時に来たとき、全件が連携先に届くまでの時間を見ます。次に、統合ID管理サーバーや同期サーバーが止まったときに処理を引き継げるかです。Connect Syncは同期サーバーが単一障害点になると移行判断ガイドに書かれており、待機系の用意が要ります。

最後が変更履歴です。誰が、いつ、どの人事データを根拠に、どのシステムのアカウントを変えたかを、監査で求められる保存期間にわたって引き出せるかを確認します。上場企業の内部統制評価やISMSの審査では、この履歴がアクセス権管理の証跡になります。

### 自社開発の業務システムに統合IDを受け取る口を作るときの改修範囲

統合ID管理製品のコネクタが用意されているのは、AD・主要SaaS・国内パッケージまでです。自社で開発した業務システムには、統合IDを受け取る口を自分たちで作る必要があるため、改修の対象です。標準の受け口はSCIMで、ユーザーの作成・検索・更新・無効化の4操作を実装すれば、製品を乗り換えても同じ口でつながります。仕組みは[SCIMとは？ID自動プロビジョニングの仕組みとエンドポイント実装](https://www.issoh.co.jp/tech/details/15876/)で解説しています。

改修の範囲には、ユーザーテーブルに統合ID番号の列を足す作業と、既存アカウントへの統合ID番号の付与（移行時の名寄せ）も含まれます。一創の[認証基盤・ID管理システム開発](https://www.issoh.co.jp/service/system/identity/)では、既存の業務システムにSCIMの受け口を作る改修から、人事システムとID基盤の接続設計までをまとめて対応しています。

## 統合ID管理システムを入れるべき組織と見送る組織の判断基準・失敗例

統合ID管理システムは、人事データの品質と連携先の数がそろって初めて効果が出ます。導入する条件と見送る条件を言い切ります。

### 人事システムが複数あり年間の異動が数百件を超える組織は導入する

次のいずれかに当てはまる組織は、統合ID管理システムを導入します。グループ会社で人事システムが2つ以上ある。年間の入社・異動・退職が合わせて数百件を超え、情報システム部門の手作業が月に数日かかっている。ADを使う社内システムとSaaSの両方にアカウントを配っている。

この条件では、IDaaSの属性マッピングだけで兼務や予約発令を表現しようとすると式が膨らみ、保守できる人が1人に限られます。統合IDの台帳を独立して持つほうが、担当者が替わっても運用が続きます。

### 統合IDを作らずIDaaSのSCIM連携だけで済ませる方がよい組織の条件

人事システムが1つ、従業員が数百人以下、ADを使うシステムが無く連携先の多くがSCIM対応のSaaS、という組織は統合ID管理システムを入れません。Entra IDやOktaの人事連携とSCIMプロビジョニングで、統合IDに相当する役割を十分に果たせます。製品費と構築費がかかるうえ、台帳が2つになって不整合の原因が増えるだけです。

この規模で先に取り組むべきは、ログインIDの命名規則とメールアドレスの付け方を統一することです。将来組織が大きくなったときにも、そのまま統合IDの照合に使えます。

### 例外アカウントを統合IDの外に残したまま稼働させ退職者IDが残る失敗

最も多い失敗は、共有アカウント・テスト用アカウント・外部委託者のアカウントを「後で対応する」として統合IDの外に残したまま稼働させることです。台帳に載らないアカウントは退職や契約終了の処理から漏れ、数年後の棚卸しで持ち主の分からないアカウントとして見つかります。

稼働前に、全システムのアカウントを統合IDにひも付くもの・例外として台帳に登録するもの・削除するもの、の3つに振り分けてください。例外は所有者と有効期限を必ず持たせます。持ち主の分からない管理者アカウントは、特権IDとして別の管理に移します。稼働前の振り分けを含めた導入の進め方と企業の導入例は[ID管理システムの導入事例と段階導入の手順](https://www.issoh.co.jp/column/details/18710/)で紹介しています。

## よくある質問

統合ID管理システムについて、検索でよく調べられている質問にお答えします。

### 統合ID管理と統合認証は何が違いますか？

統合認証は、ID管理とシングルサインオンを合わせた広い意味で使われる言葉です。統合ID管理はそのうちID管理の側を指し、人事データを起点にアカウントを作成・変更・削除し、どのシステムに誰のアカウントがあるかを台帳で管理します。ログインを1回にする仕組みを担うのはSSO製品やIDaaSで、認証の対象は統合ID管理システムが配ったアカウントです。両方を1つの製品で提供する場合もありますが、選定では別の要件として確認します。

### 統合ID管理ツールにはどのような種類の製品がありますか？

出自で分けると、Entra IDやOktaなどIDaaSに付いたプロビジョニング機能、日本の人事制度に合わせた国産のID管理パッケージ、アクセス認証まで備えたIGA製品、人事システムの追加機能の4つがあります。統合IDの台帳を独立して持てるのは主に国産パッケージとIGA製品です。タイプごとの違いと選定軸は[ID管理システムの4タイプ比較](https://www.issoh.co.jp/column/details/18694/)で整理しています。

### 統合ID管理システムの導入費用はどのくらいかかりますか？

費用は製品のライセンスより、連携先の数と自社システムの改修範囲で大きく変わります。ユーザー単価で課金される製品では、退職者や外部委託者を課金対象に含めるかでも年額が変わります。課金単位ごとの増え方と、受託で構築した場合との比較は[ID管理システムの費用・料金](https://www.issoh.co.jp/column/details/18698/)にまとめました。見積りを取る前に、連携先の一覧と各システムの受け口（SCIM・API・CSV）を用意すると比較しやすくなります。

### Active Directoryがあれば統合ID管理システムは不要ですか？

Active Directoryはアカウントを保管するディレクトリで、人事データを読み取ってアカウントを自動で作成・無効化する機能は標準では持っていません。ADを使わない業務システムやSaaSのアカウントも管理できません。ADを統合IDの配布先の1つと位置づけ、統合ID管理システムからADへ配り、ADからEntra IDへ同期する構成が一般的です。ADだけで運用している組織では、退職時の停止漏れがSaaS側で起きやすくなります。

### 中小企業にも統合ID管理システムは必要ですか？

従業員が数百人以下で人事システムが1つ、連携先がSCIM対応のSaaS中心なら、専用の統合ID管理システムは不要です。Microsoft 365やGoogle Workspaceの管理機能、IDaaSのSCIM連携、退職時の手順書で回ります。グループ会社の統合を控えている、ADを使う社内システムが多い、といった条件が加わった時点で検討を始めれば間に合います。

## 関連記事

- [特権ID管理とは](https://www.issoh.co.jp/column/details/18700/)：統合IDの外に置く管理者アカウントの扱いと、監査で問われる操作記録の要件です。
- [LDAPとは？仕組み・Active Directoryとの違いと認証実装をコード付きで解説](https://www.issoh.co.jp/tech/details/13316/)：統合ID管理がADやディレクトリにアカウントを書き込むときの仕組みです。
- [第一生命の不正アクセスと従業員12万人分の情報｜退職者データを残さない人事システムの設計](https://www.issoh.co.jp/tech/details/18138/)：退職者のデータとアカウントを残さない設計を事故事例から確認できます。

---

出典: [統合ID管理システムとは：人事マスタ連携の仕組みとAD・IDaaS併存の構成、大企業の要件](<https://www.issoh.co.jp/column/details/18708/>)（株式会社一創）
