--- title: "ID管理システムの導入事例と導入手順：棚卸しからSaaS連携までの段階導入と失敗例" url: "https://www.issoh.co.jp/column/details/18710/" published: 2026-10-21 updated: 2026-10-22 categories: ["セキュリティ"] publisher: "株式会社一創" --- # ID管理システムの導入事例と導入手順：棚卸しからSaaS連携までの段階導入と失敗例 ID管理システムの導入は、製品を入れた日に終わる作業ではありません。YKK APは自社開発のID管理から移行する際に旧システムの挙動調査とアカウントの棚卸しから始め、プレイドはOktaの導入後も一部の国内SaaSで手作業が残りました。本記事では公開されている導入事例を手がかりに、現状棚卸し、人事データを起点にしたID統合、SaaSや業務システムへの連携拡大という3段階の導入手順と、各段階で起きやすい失敗例を整理します。ID管理システムの導入を検討中の情報システム部門や、自社開発システムをつなぐ範囲を見積もりたい担当者に向けた内容です。 ## まとめ：ID管理システムの導入は棚卸し・人事連携・連携先拡大の3段階で進める 公開事例に共通するのは、全システムを一度に切り替えていない点です。最初にアカウントの棚卸しで不要なIDを消し、人事データを正とするID台帳を作り、監査対象や利用者の多いシステムから連携先を広げていきます。 導入効果は「作業時間の削減」と「退職者IDの自動停止」に集約されます。YKK APは年度切り替え時の管理時間を約80%削減し、プレイドは入社準備のタスクを147から42に減らしました。一方で、SCIMやAPIに対応しないSaaS・自社システムには手作業か改修が残るため、連携先の受け口を導入前に数えておくことが計画の前提になります。 年間の入退社・異動が少なく、連携先も数えるほどしかない組織は、専用のID管理システムを入れずにIDaaSの標準機能と手順書で足ります。判断基準は記事の後半で示します。 ## 公開されている導入事例に見るID管理システムの導入目的と効果の実際 製品ページの導入事例は効果の数字だけが目立ちますが、読むべきは「導入前に何が起きていたか」と「何から手を付けたか」です。ここでは経緯まで公開されている2社の事例と、ベンダーが示す標準的な導入の順序を取り上げます。 ### YKK APが自社開発のID管理から移行し年度切り替え作業を約80%削減した事例 YKK APは、オンプレミスで動かしていた自社開発のID管理システムを、アクシオのクラウド型ID管理サービス「Keyspider」へ移行しました。[IT Leadersの2026年2月26日の記事](https://it.impress.co.jp/articles/-/29039)（アクシオの2026年2月20日の発表に基づく）によると、従業員は約1万8000人（2025年3月末時点）、管理するIDは約1万3000件です。旧システムは人事システムと連携しておらず、退職者のアカウントが残存する問題と、異動が集中する時期の誤った権限付与を抱えていました。 導入の決定は2022年です。移行作業は旧システムの挙動を確認しながら仕様を整理するリバースエンジニアリングから始まり、アカウントの整理リストを作って各部署へのヒアリングで不要なアカウントを削除しました。移行後は人事システムの社員情報と組織情報が自動で反映され、年度切り替え時にアカウントや組織マスタの管理へ割いていた時間を約80%削減しています。退職者アカウントの自動停止と、権限付与の申請ワークフローも同時に整えました。 この事例で押さえたいのは、削減効果より先に「棚卸し」と「旧システムの調査」に工数を割いている点です。Keyspiderの連携方式と自社システム側の実装は[Keyspiderの連携方式と自社システムをつなぐ実装手順](https://www.issoh.co.jp/tech/details/18103/)で詳しく扱っています。 ### プレイドがOktaの導入で入社者の受け入れタスクを147から42に減らした事例 プレイドの事例は、[Okta Showcase Japan 2021の登壇内容をまとめたOkta公式ブログ](https://www.okta.com/ja-jp/blog/product-innovation/okta-showcase-japan-it-team-corp-engineer/)で公開されています。導入前は入社者のロールごとに必要なSaaSが異なり、受け入れ準備のタスクが147ありました。手作業のため設定漏れが起き、担当者は入社初日に休めない状態だったと説明されています。 Okta導入後は、入社者を適切なグループに所属させればアカウント発行と権限設定が完了する形に変え、タスクは42まで減りました。注目したいのは残った42件の中身です。一部の国内SaaSがアカウントのプロビジョニングに対応しておらず、手作業がまだ残っていると明記されています。 ID管理システムを入れても、連携先の受け口が無ければ自動化は止まります。導入効果を見積もるときは、製品の連携先一覧ではなく、自社で使っているSaaSが自動連携に対応しているかを1つずつ確かめる必要があります。 ### NECが示す統合ID管理の4ステップと内部統制対象システムから始める順序 個社の事例とは別に、ベンダーが公開している標準的な導入の順序も参考になります。[NECのWebSAM SECUREMASTERの導入効果ページ](https://jpn.nec.com/websam/securemaster/kouka.html)は、統合ID管理の進め方を次の4ステップで示しています。 1. 統合ID管理基盤を導入し、人事データを基にしたID情報マスタを一元化する 2. 財務会計など内部統制の評価対象システムから、ID情報の自動配信を始める 3. グループウェアなど利用者が広範囲にわたるシステムへ、配信対象を順次広げる 4. 整備したID基盤の上で、アクセス管理の統合やシングルサインオンに進む 同じページは導入時の課題として、人事部門との人事データ連携の調整、各システム主管部門との調整、そして「すべてのシステムを一気に統合しようとすると影響範囲が広すぎる」点を挙げています。SSOを最後に置いている点も見落とせません。ログインをまとめる前に、まとめる対象のIDを正しくしておく順序です。 ## ID管理システムを導入する前に行う現状棚卸しとID台帳の作り方 導入手順の第1段階は、製品選定より前に始めます。今あるアカウントを数え、人事データと突き合わせ、誰のものでもないIDを洗い出す作業です。ここを省くと、不要なIDを新しいシステムへそのまま持ち込むことになります。 ### システムごとのアカウント一覧を集めて人事データと突き合わせる手順 棚卸しは、ADやIDaaS、主要なSaaS、業務システムのそれぞれから有効なアカウントの一覧を出すところから始めます。各一覧に社員番号が入っていればそれで人事データと照合し、入っていなければメールアドレスや氏名で照合して、一致しないものを「不明アカウント」として別に並べます。 不明アカウントは、情シスだけで削除してはいけません。YKK APが各部署へのヒアリングで不要なアカウントを判断したように、システムの主管部門か利用部門の管理者に1件ずつ確認を取ります。確認に返事が無いアカウントは、すぐ削除せず無効化して一定期間置き、問い合わせが無ければ削除する二段構えにすると業務停止を避けられます。 この作業の裏付けになるのが、公的機関のガイドラインと注意喚起です。[IPAの組織における内部不正防止ガイドライン（第5版）](https://www.ipa.go.jp/security/guide/insider.html)は、異動や退職で不要になった利用者IDとアクセス権を「ただちに削除」するよう求めています。[大阪府警察の注意喚起](https://www.police.pref.osaka.lg.jp/seikatsu/saiba/cyber%5Fshiryou/cybersecurity%5Ftsushin/8/23555.html)も、元社員の不要なアクセス権が悪用されて業務を妨害された事案に触れ、不要なIDとアクセス権の即時削除を対策の筆頭に置いています。 ### 共有ID・委託先・サービスアカウントなど人に紐づかない例外の洗い出し 人事データと照合できないアカウントの多くは、不正なものではなく「人に紐づかないID」です。代表的なものは次のとおりです。 - 部署やチームで共用している共有ID（受付用端末、問い合わせ窓口のメールボックスなど） - 保守ベンダーや業務委託先、派遣社員に発行したID - システム間連携やバッチ処理で使うサービスアカウント - 障害時に使う緊急用の管理者ID これらは人事データに載らないため、ID管理システムの自動処理から漏れます。棚卸しの段階で「管理責任者」「利用期限」「用途」の3項目を台帳に記録し、責任者の異動や退職と連動して見直す対象にしておきます。管理者権限を持つものは[特権ID管理](https://www.issoh.co.jp/column/details/18700/)の対象として別に扱うのが原則です。 ### 人事データ側で整える社員番号・所属コード・発令日と雇用区分の項目 ID管理システムは人事データを正として動くため、人事データ側の欠けや揺れがそのままアカウントの誤りになります。導入前に人事部門と確認しておく項目は、社員番号の一意性、所属コードの体系、発令日（異動・退職の効力発生日）、雇用区分（正社員・契約社員・派遣など）の4つです。 特に見落とされやすいのが過去のレコードです。[Microsoftのクラウド人事アプリ連携の計画ガイド](https://learn.microsoft.com/ja-jp/entra/identity/app-provisioning/plan-cloud-hr-provision)は、人事システムには1970年代まで遡る雇用データがありうると書き、ITに関係の無いレコードを除外するためのフラグを人事部門と協力して付けるよう勧めています。退職済みの社員を新システムへ大量に取り込むと、それだけで照合とテストの手間が膨らみます。人事データの持ち方は[人事システムの機能と選び方](https://www.issoh.co.jp/column/details/13557/)も参照してください。 ## 人事データを起点にIDを統合し自動プロビジョニングを始める導入手順 第2段階では、人事データとID台帳をつなぎ、入社・異動・退職を自動で反映させます。人事マスタを起点にした統合IDの構成そのものは[統合ID管理システムの仕組みとAD・IDaaS併存の構成](https://www.issoh.co.jp/column/details/18708/)で解説しているため、ここでは切り替えの進め方に絞ります。 ### 照合キーの一意性を確かめてから初回同期に進む理由と公式ガイドの指針 自動プロビジョニングは、人事データの1人と既存アカウントの1件を「照合キー」で結び付けて動きます。Microsoftの計画ガイドでは既定の照合キーが従業員IDで、完全同期を始める前に、従業員IDがAD・Entra ID側に設定され一意であることを確認するよう明記されています。複数の照合属性に優先順位を付けることもでき、1件一致した時点で評価が止まる仕様です。 照合キーが欠けた既存アカウントは、人事データの社員と結び付かず、新規アカウントとして二重に作られるか、管理の外に取り残されます。初回同期の前に、第1段階の棚卸しで作った一覧を使って全アカウントに照合キーが入っているかを確かめるのが順序です。照合キーの選び方で起きる重複の例は[ID管理システム比較の選定軸](https://www.issoh.co.jp/column/details/18694/)で扱っています。 ### パイロットから対象者を段階的に広げる初回同期の進め方と確認項目 Microsoftの計画ガイドは、本番の全ユーザーに広げる前にパイロット環境で初期構成を行い、少数のテストユーザーで初回サイクルの結果を確かめてから、スコープフィルターを広げて対象者を増やすよう勧めています。ユーザーが30,000人を超える大規模な人事テナントでは、初回サイクル自体を段階に分けて実行する前提です。 テストでは、少なくとも次の人事イベントを1件ずつ発生させて、期待どおりにアカウントが変わるかを確認します。 1. 新規採用：アカウントが作成され、初日にログインして業務アプリを使える 2. 退職：アカウントが無効になり、保護された業務アプリにログインできなくなる 3. 所属変更：新しい所属に対応する組織単位（OU）へアカウントが移る 4. 上司の変更：上司の属性が新しい上司に書き換わる この4項目は同ガイドのテストシナリオに沿ったものです。自社の運用に合わせて、兼務の追加、休職、発令日を未来日付にした予約反映も足しておくと、本番の4月異動で慌てずに済みます。 ### 新旧システムの連携ファイルを突き合わせて業務システムの改修を避ける 既存のID管理の仕組みを置き換える場合、業務システムの多くは旧システムが出力するファイルを取り込んでアカウントを更新しています。YKK APの事例では、各業務システムが旧システムのCSVファイルを取り込んでいたため、新旧のCSVを突き合わせ、文字コードや改行コードまで完全一致することをテストで確かめました。画面のデータ項目の順序や名称も旧システムに寄せ、運用担当者の操作を変えていません。 連携ファイルの形式が1項目でも変わると、取り込む側の業務システムすべてに改修が発生します。移行の受け入れ条件に「既存の連携ファイルと完全一致」を入れておくと、改修範囲を新システム側だけに閉じ込められます。 ## SaaS・業務システムへ連携先を広げる順番と自社開発システムの受け口 第3段階は、ID台帳から各システムへの自動配信を増やしていく作業です。全部を同時に始めず、効果とリスクの大きい順に並べます。 ### 監査対象と利用者の多いシステムから連携先を広げる優先順位の決め方 連携先の優先順位は、NECの4ステップと同じく「監査で問われるシステム」を先頭に置きます。財務会計や販売管理、個人情報を扱うシステムは、退職者IDの残存がそのまま監査指摘になるためです。次に、メールやグループウェア、チャットのように全社員が使い、アカウント発行の件数が多いシステムを入れます。 利用者が一部の部署に限られるSaaSや、年に数回しかアカウントを発行しないシステムは後回しで構いません。連携の設定とテストに数日かけても、手作業の削減は年に数時間で終わることがあるからです。この並べ方をすると、ID管理システムの効果を早い段階で数字にでき、残りの連携先の予算も取りやすくなります。退職時の無効化と定期的な権限の見直しを統制として回す仕組みは[IGA（IDライフサイクル管理）の解説](https://www.issoh.co.jp/column/details/18704/)にまとめています。 ### SCIMやAPIに対応しない国内SaaS・自社システムに残る手作業の扱い プレイドの事例で手作業が残ったように、連携先の中には自動プロビジョニングの受け口を持たないものがあります。受け口の有無は、SCIMに対応しているか、ユーザー管理のAPIを公開しているか、どちらも無くCSVの取り込みだけか、の3段階で分けて一覧にします。 SaaSの場合は、上位プランでしかSCIMが使えないこともあるため、契約プランまで確認が必要です。自社開発の業務システムは、ID管理システム側の対応を待つのではなく、システム側にSCIMのエンドポイントを実装するのが長期的に手間の少ない方法です。仕様と実装の要点は[SCIMによるID自動プロビジョニングの仕組み](https://www.issoh.co.jp/tech/details/15876/)で解説しています。古い業務システムで改修が難しい場合は、CSV連携を残したうえで取り込みの失敗を監視する運用への切り替えが対応策です。一創では、既存の業務システムにSCIMの受け口を追加する改修や、人事データと連動するID管理の仕組みの構築を[認証基盤・ID管理システム開発](https://www.issoh.co.jp/service/system/identity/)として受託しています。 ## ID管理システムの導入で起きやすい失敗例と導入を見送ってよい場面の判断 失敗の多くは製品の性能ではなく、導入の順序で起きます。ここでは手順を飛ばしたときに起きる失敗と、そもそも導入しない方がよい条件を言い切ります。 ### 棚卸しを省いて旧台帳のまま連携し退職者IDを新システムへ持ち込む失敗 導入スケジュールが押すと、棚卸しを後回しにして旧システムのアカウントをそのまま新システムへ移したくなります。この場合、退職者や異動前のIDも「管理対象の正規アカウント」として登録され、新システムの画面上は整って見えるのに中身は旧台帳と同じという状態になります。 新システムへ移した後は、そのIDが不要かどうかを判断する材料がさらに減ります。棚卸しは移行の前に終えることを導入計画の必須工程にし、期間が足りない場合は連携先の数を減らしてでも棚卸しの期間を守る方が結果的に早く終わります。 ### 異動の集中する4月に本番切替を重ねて誤った権限を一斉に配る失敗 年度初めは人事異動が最も多い時期で、YKK APも旧システムの課題として異動集中期の誤った権限付与を挙げていました。この時期に新システムの本番切替を重ねると、人事データの反映ミスと新システムの設定ミスが同時に起き、どちらが原因かを切り分けられなくなります。 本番切替は異動の少ない時期に置き、最初の年度切り替えは旧来の確認手順を並行して残すのが安全です。発令日の予約反映を使う場合は、切替前のテストで未来日付の異動を必ず1件流しておきます。 ### 入退社と異動の件数・連携先の数でID管理システムを見送ってよい条件 専用のID管理システムが効果を出すのは、手作業の件数が多い組織です。目安として、年間の入社・異動・退職の合計が数十件に収まり、アカウントを発行するSaaSが5〜10個程度なら、IDaaSに付いているプロビジョニング機能と退職時のチェックリストで足ります。この場合は専用製品に費用をかけるより、棚卸しを半年に1回行う運用を先に固めます。兼任担当だけでこの運用を回す手順は[情シス不在の中小企業でID管理を回す方法](https://www.issoh.co.jp/column/details/18712/)で解説しています。 反対に、人事システムが別にあって異動が年間数百件を超える、監査で退職者IDの残存を指摘された、自社開発の業務システムが複数ある、のいずれかに当たるなら導入を検討する段階です。この目安は一次情報ではなく本記事の判断基準ですが、プレイドやYKK APのように手作業の件数を事前に数えておけば、導入の可否は数字で決められます。 ## よくある質問 ID管理システムの導入事例や導入手順について、検討段階でよく寄せられる質問に答えます。 ### ID管理システムの導入にはどのくらいの期間がかかりますか？ 期間を左右するのは製品の設定より、棚卸しと連携先の数です。数百人規模で連携先がIDaaSと主要SaaS数個なら、棚卸しから初回の本番稼働まで数か月で進められます。数千人以上で自社開発の業務システムが多い場合は、YKK APのように旧システムの調査から始めて年単位になることもあります。連携先は一度に全部つながず、段階的に増やす前提で計画を立ててください。 ### ID管理システムの導入事例を見るときはどこを確認すればよいですか？ 削減率の数字より、導入前の状態と最初に手を付けた作業を確認します。従業員数とID数、人事システムと連携していたか、旧システムが自社開発かどうか、手作業が残ったシステムは何か、の4点で自社と近い事例を選ぶのが確実です。プレイドの事例のように「自動化できずに残った作業」を書いている事例は、導入後の実態を知る材料として特に役立ちます。 ### ID管理システムを導入すれば退職者のアカウントはすぐに止まりますか？ 人事システムで退職処理が入り、連携先が自動プロビジョニングに対応していれば、次の同期でアカウントは無効になります。ただし、SCIMやAPIに対応しないSaaS、人事データに載らない委託先や共有ID、自動連携の外にあるローカルアカウントは止まりません。これらは台帳で責任者を決め、退職時のチェックリストで手作業の停止を確認する運用を残す必要があります。 ### 人事システムが無い会社でもID管理システムは導入できますか？ 導入はできますが、人事データの代わりになる「正」の名簿を決めることが先です。多くの製品はCSVの取り込みに対応しているため、給与システムから出力した社員一覧や、総務部門が管理する名簿を起点にできます。ただし名簿の更新が遅れれば、アカウントの反映も同じだけ遅れます。誰がいつ名簿を更新するかを決めずに導入すると、自動化の効果は出ません。 ### ID管理システムの導入費用はどのくらいかかりますか？ 費用はユーザー単価のライセンスだけでなく、初期構築費、連携先の業務システムを改修する費用、同期エラーに対応する運用工数で決まります。特に自社開発システムへの受け口の追加は、製品の見積りに含まれないことが多い費目です。製品ごとの公開価格と規模別の試算は[ID管理システムの費用・料金の解説](https://www.issoh.co.jp/column/details/18698/)で整理しています。 ## 関連記事 - [認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説](https://www.issoh.co.jp/column/details/13631/)：ID管理と認証の全体像を確認したいときの起点 - [IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説](https://www.issoh.co.jp/tech/details/16401/)：小規模組織でIDaaSの標準機能に留める場合の仕組み - [シングルサインオン比較：SSO製品・IDaaSの選び方と料金、自社システム組込みの判断](https://www.issoh.co.jp/column/details/18686/)：ID統合の次に進むSSOの選定 - [第一生命の不正アクセスと従業員12万人分の情報｜退職者データを残さない人事システムの設計](https://www.issoh.co.jp/tech/details/18138/)：退職者データが残ることのリスクを事故から確認 --- 出典: [ID管理システムの導入事例と導入手順：棚卸しからSaaS連携までの段階導入と失敗例]()（株式会社一創）