--- title: "IGAとは：IDライフサイクル管理とアクセス認証の仕組み、IAM・PAMとの違いと導入判断" url: "https://www.issoh.co.jp/column/details/18704/" published: 2026-10-21 updated: 2026-10-21 categories: ["セキュリティ"] publisher: "株式会社一創" --- # IGAとは：IDライフサイクル管理とアクセス認証の仕組み、IAM・PAMとの違いと導入判断 IGA（Identity Governance and Administration）とは、入社・異動・退職に合わせてIDを発行・変更・削除し、付与したアクセス権が今も正しいかを定期的に確かめる仕組みです。日本語では「IDガバナンス」「ID統制」とも呼ばれます。この記事では、IDライフサイクル管理の流れと抜けやすい箇所、アクセス認証や職務分掌といった統制の機能、IAM・IDaaS・PAMとの違いが説明の対象です。あわせて、Microsoft Entra ID Governanceで実現できる範囲とライセンス条件、IGA製品を入れるべき組織と見送ってよい組織の線引きまで整理します。 ## まとめ：IGAはIDの発行から削除までと権限の見直しを記録付きで回す仕組み IGAが扱うのは「誰にどの権限を、なぜ、いつまで持たせるか」です。ログインの仕組みを担うIAMやIDaaSとは役割が違い、権限が正しく付いているかを確かめて証跡を残す側に立ちます。 IGAの仕組みを構成する要素は、大きく分けて次の2つです。1つは人事データを起点にしたIDライフサイクル管理で、入社日にアカウントを用意し、異動で旧権限を外し、退職日に止めます。もう1つはアクセスの統制で、申請と承認の記録、定期的なアクセス認証、両立させてはいけない権限の組み合わせのチェックを行います。 導入の判断は人数より「監査で棚卸しの記録を求められるか」と「異動の頻度」で決まります。監査対象のシステムを持ち、組織変更のたびに権限の付け替えが発生する組織はIGAを前提に設計します。SaaS中心で従業員が少ない組織は、IDaaSの標準機能とID台帳の整備から始めれば十分です。 ## IGAの定義とIAM・IDaaS・PAMとの違い＝ログインでなく権限の統制を担う ### IGAの定義と構成要素＝IDと権限の運用管理・方針に沿った統制の役割 IGAは、Administration（IDと権限を作り・変え・消す運用）とGovernance（その運用が方針どおりか確かめる統制）を1つにまとめた呼び方です。Microsoftの[Microsoft Entra ID ガバナンスの公式解説](https://learn.microsoft.com/ja-jp/entra/id-governance/identity-governance-overview)は、IDガバナンスが答えるべき問いとして次の4つを挙げています。 - どのIDがどのリソースにアクセスできるべきか - そのIDはアクセスを使って何をしているか - アクセスを管理する組織的な管理策が存在するか - 監査人が、管理策が機能していると確認できるか 最後の問いがIGAの性格をよく表しています。権限を正しく付けるだけでは足りず、正しく付けていることを第三者に示せる記録まで含めて初めてIGAと呼べます。 ### IAM・IDaaSとの違いは「ログインさせる」か「権限が正しいか確かめる」か IAM（IDおよびアクセス管理）やIDaaSが解決するのは、本人を確かめてシステムに入れる処理です。多要素認証、SSO、OIDCやSAMLによる連携がこれに当たり、詳しくは[認証・ID管理の全体像（MFA・SSO・OIDC・IDaaSの違い）](https://www.issoh.co.jp/column/details/13631/)で扱っています。 IGAが受け持つ範囲は、ログイン処理の手前と後ろです。手前では、誰にアカウントと権限を配るかを人事データと申請から決めます。後ろでは、配った権限がまだ必要かを定期的に問い直します。両者は置き換えの関係ではありません。IDaaSが権限変更の処理を実行し、IGAがその変更が方針に合っているかを確かめる、という組み合わせで動きます。認証・認可・監査まで含めたIAM全体の中でIGAが受け持つ位置は[IDおよびアクセス管理（IAM）の全体像](https://www.issoh.co.jp/column/details/18706/)で整理しています。 ### 特権ID管理（PAM）との分担とIGAが対象にする全従業員・外部ユーザー 対象の広さでも分担が決まります。 | 領域 | 主な対象 | 中心になる機能 | | --------- | ------------- | --------------- | | IGA | 全従業員・委託先・ゲスト | 入社・異動・退職の処理、棚卸し | | PAM・PIM | 管理者などの特権ID | 期限付き貸出、操作記録 | | IAM・IDaaS | ログインするすべての利用者 | 認証、SSO、条件付きアクセス | IGAは人数の多い一般IDを広く扱い、PAMは数の少ない強い権限を深く扱います。rootやグローバル管理者の貸出と操作記録は[特権ID管理の仕組みと監査で問われる要件](https://www.issoh.co.jp/column/details/18700/)にまとめたので、本記事は全従業員のIDと権限の統制に絞ります。 ## IDライフサイクル管理の流れ＝入社・異動・退職で起きる処理と抜けやすい箇所 ### 入社（Joiner）は人事データを起点に初日までにアカウントと権限を用意 IDライフサイクルは、入社（Joiner）・異動（Mover）・退職（Leaver）の3場面で語られることが多く、頭文字からJMLとも呼ばれます。Microsoftの[ライフサイクル ワークフローの解説](https://learn.microsoft.com/ja-jp/entra/id-governance/what-are-lifecycle-workflows)も、加入者・異動者・離脱者の3フェーズでユーザーを管理すると説明しています。 入社で問われるのは速さです。同じページには、新入社員の入社日属性`employeeHireDate`の7日前に上長へメールを送るワークフローの例が載っています。入社日を人事システムに登録した時点で、アカウント作成、部署に応じたグループへの追加、初回ログイン用の情報の通知までを前倒しで進める設計にすると、初日に「メールが使えない」という状態がなくなります。 ### 異動（Mover）で新しい権限の付与より前の権限の削除が漏れやすい理由 3場面のうち、最も事故が起きやすいのが異動です。新しい部署の権限は、本人が業務で困るのですぐに申請されます。一方、前の部署の権限は本人も上長も困らないので、誰も外す依頼を出しません。 この結果、異動を2〜3回経験した社員ほど、複数部署の権限を抱えたままになります。営業部から経理部へ移った社員が、顧客管理システムの全件出力権限と支払処理の権限を同時に持つ、といった状態です。異動では「付与」と「削除」を必ず同じ処理として扱い、旧部署の権限は新部署の権限が付いた時点で外す、または期限を付けて自動で外すルールにします。 ### 退職（Leaver）は無効化の期限とSSO外のローカルアカウントの残存 退職では、アカウントを止める期限を決めることが出発点です。退職者リストを月1回受け取って手で消す運用では、最長で1か月近く有効なアカウントが残ります。 見落としやすいのは、SSOを通らないアカウントです。SSOを止めても、連携先にIDとパスワードでログインできるローカルアカウントが残っていれば、そこから入れてしまいます。業務委託先が独自に発行した共有アカウントや、部署単位で契約したSaaSも同じです。退職処理の対象は「IDaaSのアカウント」ではなく「その人が持つすべてのアカウント」と定義し、無効化の後、一定期間を置いて削除する2段階にしておくと、誤って止めた場合の復旧もできます。 ### 人事システムを起点にする設計とSCIMによる連携先への自動反映 JMLを自動化する前提は、IDの正本をどこに置くかを決めることです。Microsoftの公式解説も、多くの組織で従業員のIDライフサイクルは人事システム上の情報に結び付いていると述べています。所属・役職・入社日・退職日を人事システムから受け取り、それを起点に各システムのアカウントを作り変えるのが基本形です。 連携先へ反映する標準的な方式がSCIMです。SCIM 2.0のプロトコルは2015年9月に[IETF RFC 7644](https://datatracker.ietf.org/doc/html/rfc7644)として公開され、ユーザーやグループの作成・更新・削除をHTTPのAPIでやり取りする手順を定めています。SCIMの受け口を持つSaaSなら、人事の変更をそのまま反映することが可能です。エンドポイントの作り方は[SCIMによるID自動プロビジョニングの仕組みと実装](https://www.issoh.co.jp/tech/details/15876/)で解説しています。 ## IGAのアクセス統制機能＝申請承認・アクセス認証・職務分掌・ロール設計 ### アクセス申請と承認ワークフローで付与の理由と承認者を記録に残す 人事データだけでは決まらない権限もあります。プロジェクト単位で使うフォルダや、一時的に必要な業務システムの閲覧権限がその例です。こうした権限は、利用者が申請し、上長やシステムの所有者が承認する流れで付与します。 IGAで残すべき記録は、申請理由・承認者・付与日・有効期限の4つです。チャットや口頭の依頼で付けた権限は、後から「なぜこの人が持っているのか」を誰も説明できません。有効期限まで申請時に決めておけば、期限切れで自動的に外れるため、棚卸しの対象そのものが減ります。 ### アクセス認証（アクセスレビュー）で付与済み権限を定期的に再確認する アクセス認証は、付与済みの権限一覧を上長やリソースの所有者に見せ、「この人にこの権限はまだ必要か」を承認または却下させる作業です。日本では「ID棚卸し」「権限棚卸し」と呼ばれることもあります。 Microsoftの[アクセス レビューの公式解説](https://learn.microsoft.com/ja-jp/entra/id-governance/access-reviews-overview)では、対象はグループのメンバー、アプリへの割り当て、ロールの割り当てで、毎週・毎月・毎四半期・毎年の周期で繰り返し設定できると説明されています。周期は権限の重さで分けるのが実務的です。顧客データや会計に触れる権限は四半期、一般的なファイル共有は年1回、というように対象ごとに頻度を変えると、レビュー担当者の負担が偏りません。 ### 職務分掌（SoD）チェックで「発注と承認」など両立させない権限を防ぐ 職務分掌（Segregation of Duties）は、1人が持つと不正が可能になる権限の組み合わせを禁止する考え方です。代表例は次のとおりです。 - 発注の登録と、その発注の承認 - 取引先マスタの登録と、支払の実行 - アカウントの作成と、そのアカウントへの権限付与の承認 IGAでは、この組み合わせを「両立不可」のルールとして登録し、申請時に違反があれば止めます。前述の異動で旧権限が残る問題と組み合わさると、本人に悪意がなくても職務分掌の違反状態が生まれるおそれがあるためです。ルールを登録するだけでなく、既存の権限に違反がないかを定期的に検出する運用まで含めて考えます。 ### ロールベースの権限設計（RBAC）と期限付きの例外権限を管理する方法 権限を1人ずつ付けていては、数百人規模で管理が破綻します。そこで「経理部・担当者」「営業部・課長」のように職務ごとのロールを定義し、ロールに権限をまとめて割り当てるのがRBAC（ロールベースのアクセス制御）です。 設計の勘所は、ロールで全員分を表現しようとしないことです。部署と役職の組み合わせで基本ロールを作り、それ以外は期限付きの個別申請で扱います。個別申請の権限が同じ部署で何人にも付いている場合は、その権限も基本ロールに取り込む対象です。ロールを先に作り込むより、例外の実績からロールを育てるほうが運用に乗ります。 ## IGAの実現方式＝IDaaSの拡張・IGA製品・業務システムへの組み込みの比較 ### Microsoft Entra ID Governanceの機能とライセンス条件 Microsoft 365を使っている組織なら、まずEntra IDの機能でどこまでできるかを確かめます。[Microsoft Entra ID ガバナンス ライセンスの基礎](https://learn.microsoft.com/ja-jp/entra/id-governance/licensing-fundamentals)によると、主な機能と必要なライセンスは次のとおりです（2026年10月時点）。 | 機能 | 最低限必要なライセンス | | ---------------- | ------------------- | | 人事主導のプロビジョニング | Entra ID P1 | | アクセスレビューの基本機能 | Entra ID P2 | | アクセスパッケージの職務の分離 | Entra ID P2 | | ライフサイクル ワークフロー | Entra ID Governance | | アクセスパッケージの自動割り当て | Entra ID Governance | 同じページには、P2で公開済みの機能は残る一方、新しいIGAの機能はP2に追加されないと明記されています。P1はMicrosoft 365 E3、P2はE5に含まれますが、入社・異動・退職の自動処理であるライフサイクル ワークフローを使うにはEntra ID Governanceの追加契約が必要です。E5を契約していればIGAもそろう、という前提で計画すると、見積もりの段階で食い違います。 ### IGA製品（SailPoint・Saviynt・midPoint）を選ぶべき場面と条件 IGA専業の製品が向くのは、連携先にSAPなどの基幹システムやオンプレミスの業務システムが多く、職務分掌のルールが数十件以上ある組織です。商用ではSailPointやSaviyntが代表で、OSSでは[オープンソースのIGAツールmidPoint](https://www.issoh.co.jp/tech/details/4690/)があります。 専業製品の強みは、多様なシステムへのコネクタと、ロールの分析やレビュー結果の監査報告といった統制側の機能の厚さです。その分、導入にはロール設計と連携先ごとの接続作業が伴い、期間は数か月から1年単位になります。IDaaS付帯型・国産ID管理パッケージ・IGA製品・人事システム付帯型の4タイプの違いは、[ID管理システム比較（人事連携・棚卸しで選ぶ機能要件）](https://www.issoh.co.jp/column/details/18694/)で比べています。 ### 自社開発の業務システムをIGAにつなぐときの改修範囲と実装の論点 IGA製品やIDaaSを入れても、自社で作った業務システムがつながらなければ、そこだけ手作業の棚卸しが残ります。つなぐための改修は、主に次の3つです。 1. アカウントの作成・更新・停止を外部から受け付ける口（SCIMのエンドポイントやAPI）を用意する 2. システム内の権限を「ロール」や「グループ」として外から読める形に整理する 3. 現在の利用者と権限の一覧を出力し、アクセス認証の材料として渡せるようにする 手間がかかるのは2つ目です。画面ごと・ボタンごとに権限フラグを持たせた古いシステムでは、まず権限をロールにまとめ直す作業から始まります。既存システムへのSCIM受け口の追加や、認証基盤と連携した権限モデルの見直しは、一創の[認証基盤・ID管理システム開発](https://www.issoh.co.jp/service/system/identity/)でご相談いただけます。 ## IGAを導入すべき組織と見送る組織の判断基準・導入で失敗する典型パターン ### 導入を前提に検討すべき条件＝監査の要求・連携先の数・異動の頻度 次のいずれかに当てはまるなら、IGAの仕組みを前提に設計します。 - J-SOXの対象システムやISMS認証の範囲があり、権限棚卸しの記録を監査で提出している - 人事異動が年2回以上あり、そのたびに数十人以上の権限を付け替えている - アカウントを管理する業務システムやSaaSが20を超え、退職処理を手順書で回している 「年2回」「20」は一次情報ではなく、手作業の棚卸しが回らなくなる目安として本記事が置いた基準です。ISMSでは、ISO/IEC 27001:2022の附属書Aにある識別情報の管理（5.16）やアクセス権（5.18）の管理策が、IDの発行から削除、権限の見直しに対応します。管理策の全体像は[ISO27001の2022年版の管理策と取得手順](https://www.issoh.co.jp/column/details/13432/)で確認できます。 ### IGA製品を見送ってよい組織の規模と先に整えるべきID台帳の記録項目 反対に、専用のIGA製品が過剰になる組織もあります。従業員が100人未満で、業務の大半をMicrosoft 365やGoogle Workspaceと10個程度のSaaSで回しているなら、IDaaSのプロビジョニングと、年1回の手作業の棚卸しで足ります。 この規模で先にやるべきは、製品の選定ではなくID台帳の整備です。システムごとに誰のアカウントがあり、どの権限を持ち、誰が承認したかを1つの表にまとめます。台帳が作れない状態でIGA製品を入れても、取り込むデータの正しさを誰も保証できません。 ### IGA導入で失敗する典型例＝ロールの作り込みすぎとアクセス認証の形骸化 IGAの導入が止まる原因は、ほぼ2つに集約されます。 1つ目は、ロールの作り込みすぎです。部署・役職・拠点・プロジェクトの組み合わせをすべてロールにした結果、ロールの数が従業員数に近づき、個別に権限を付けていたころと管理の手間が変わらなくなります。基本ロールは部署と役職の組み合わせに留め、残りは期限付きの申請で扱います。 2つ目は、アクセス認証の形骸化です。上長に数百行の権限一覧を送ると、中身を確かめずに全件承認されがちです。これでは記録は残っても統制は効いていません。レビュー対象を前回から変わった権限や、90日以上使われていない権限に絞り、1人が一度に確認する件数を減らす設計にします。 ## よくある質問 IGAとIDライフサイクル管理について、導入検討の段階でよく寄せられる質問をまとめました。 ### IGAとIAMは何が違うのですか？ IAMは本人を認証してシステムに入れる仕組みで、多要素認証やSSOが中心です。IGAは、誰にどの権限を持たせるかを人事データと申請で決め、付与した権限がまだ必要かを定期的に確かめて記録に残す仕組みです。IAMが権限変更を実行し、IGAがその変更が方針に合っているかを統制する関係にあり、どちらか一方で置き換えるものではありません。製品によっては1つのサービスで両方を提供しています。 ### IDライフサイクル管理とIGAは同じ意味ですか？ IDライフサイクル管理はIGAの一部です。入社・異動・退職に合わせてIDを作り、変え、止める処理を指します。IGAはこれに加えて、アクセスの申請と承認、定期的なアクセス認証、職務分掌のチェックといった統制の機能まで含みます。人事システムとの連携でアカウントの作成と削除を自動化しただけでは、付与済みの権限が正しいかを確かめる仕組みが欠けているため、IGAとしては半分の状態です。 ### ID棚卸しはどのくらいの頻度で行えばよいですか？ 権限の重さで頻度を分けます。顧客データや会計、支払に関わる権限は四半期ごと、一般的なファイル共有やグループの所属は年1回が実務的な目安です。監査で頻度を指定されている場合はそれに合わせます。Microsoft Entra IDのアクセスレビューは毎週から毎年まで周期を選べるため、対象ごとに別のレビューを作ると、重要な権限だけを短い周期で確認できます。 ### IGAの導入にはどのくらいの期間がかかりますか？ 範囲で大きく変わります。Microsoft 365とSCIM対応のSaaSが中心で、Entra ID Governanceの機能で済む場合は、人事データの整備を含めて数か月が目安です。IGA専業製品で基幹システムやオンプレミスの業務システムまでつなぐ場合は、ロール設計と連携先ごとの接続作業が加わり、1年単位の計画になります。最初の連携先を退職処理の影響が大きいシステムに絞り、段階的に広げると早く効果が出ます。 ### 中小企業にもIGAは必要ですか？ 考え方は必要ですが、専用製品が必要とは限りません。従業員100人未満でSaaS中心なら、IDaaSのプロビジョニングで入社と退職を自動化し、年1回の棚卸しを手作業で行えば監査で説明できる状態に近づけます。最初にやるべきは、システムごとのアカウントと権限、承認者を1つの台帳にまとめることです。異動のたびに旧権限を外すルールを決めておくだけでも、権限の残り過ぎは大きく減らせます。 ## 関連記事 - [ID管理システムの費用・料金：課金単位と連携数で増える総額、受託構築との比較](https://www.issoh.co.jp/column/details/18698/)：IGAを含むID管理の総額の見積もり方 - [Saviyntとは？読み方・IGA/PAMの機能とSaviynt Japanの現状](https://www.issoh.co.jp/tech/details/4627/)：IGAと特権アクセス管理を1製品で扱う商用製品の例 - [IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説](https://www.issoh.co.jp/tech/details/16401/)：IGAが連携するIDaaSの仕組み - [ノンヒューマンアイデンティティ（NHI）とは？機械IDの管理・リスクと実装者向けの守り方を解説](https://www.issoh.co.jp/tech/details/13616/)：人以外のIDのライフサイクル管理 - [ISMSの内部監査とは？箇条9.2の要求事項と進め方・管理策別の質問例](https://www.issoh.co.jp/column/details/12645/)：アクセス権の棚卸しが内部監査でどう確認されるか --- 出典: [IGAとは：IDライフサイクル管理とアクセス認証の仕組み、IAM・PAMとの違いと導入判断]()（株式会社一創）