2026.10.21 セキュリティ

IDおよびアクセス管理（IAM）とは：ID管理と認可の違い、企業IAM基盤の構成と導入判断

IDおよびアクセス管理（IAM：Identity and Access Management）とは、利用者のIDを作って維持し、そのIDが「どのシステムで何をしてよいか」を判定して記録する仕組みの総称です。この記事では、ID管理とアクセス管理の違い、IDaaS・IGA・PAM・AWS IAMといった隣接語との境界、認可の中核になるRBACとABACの使い分けを整理します。そのうえで、ID台帳・IdP・プロビジョニング・認可・監査で組む企業IAM基盤の構成と、導入を進める順番、全社導入すべき組織と部分導入で足りる組織の線引きまで解説します。

まとめ：IAMはIDの管理と認可の判定を組み合わせて全社の入口と権限を統制する仕組み

IAMは製品名ではありません。「この人は誰か」を確かめるID管理・認証と、「この人に何を許すか」を決めるアクセス管理・認可を、1つの方針で動かすための考え方と仕組みの集まりです。

企業のIAM基盤は、人事データを起点にしたID台帳、ログインの入口になるIdP、各システムへアカウントを配るプロビジョニング、業務アプリ側の認可、権限とアクセスの記録という5つの層で組みます。IDaaSを契約すれば入口の層は片付きますが、認可と棚卸しの層は残ります。

進める順番はID台帳の整備が先です。台帳が不正確なままSSOを入れると、退職者のIDが1か所にまとまって残るだけになります。監査で権限の棚卸しを求められ、異動が多く、連携するシステムが10を超える組織は全社基盤として設計します。それ以外はIDaaSの標準機能と台帳整備で十分です。

IAMの定義とID管理・アクセス管理の違い＝本人の確認と許可範囲の判定

IAMの定義とNIST SP 800-63-4が示す本人確認・認証・連携の範囲

IAMの「Identity」側の範囲を最も具体的に定めている一次情報は、米国立標準技術研究所（NIST）のデジタルアイデンティティ指針です。2025年7月に公開されたNIST SP 800-63-4は、前版のSP 800-63-3を置き換え、利用者の本人確認（identity proofing）、認証（authentication）、フェデレーション（federation）の3領域を扱うと明記しています。

この3領域はそれぞれ別冊（63A・63B・63C）に分かれています。登録時にその人が本人かを確かめる工程、ログインのたびに認証器で確かめる工程、確かめた結果を別のシステムへ渡す工程です。

IAMはこれに「Access」側、つまり確かめたIDに何を許すかの判定と、その記録を加えたものです。認証の方式（多要素認証やパスキー、SAML・OIDC）は認証・ID管理の全体像とMFA・SSO・IDaaSの選び方で詳しく整理しているので、この記事では認可と全社の構成に重心を置きます。

ID管理とアクセス管理の違い＝IDを作り維持する仕事と利用時に可否を決める仕事

ID管理とアクセス管理の違いは、処理が動くタイミングです。ID管理は入社・異動・退職といった人事イベントで動き、アカウントの作成、所属や役職の属性の更新、無効化と削除を担います。アクセス管理は利用者がシステムを使う瞬間に動き、その操作を許可するかを判定します。

営業部の社員が経理部へ異動した場面で考えると分かりやすくなります。ID管理の仕事は、人事システムの所属変更を受けてIDの部署属性を書き換えることです。アクセス管理の仕事は、書き換わった部署属性を見て、翌日から顧客管理システムの編集を拒否し、会計システムの閲覧を許可することです。

片方だけでは事故を防げません。ID管理が正しくてもアクセス管理が部署属性を見ていなければ旧権限は残り、アクセス管理が精密でも台帳の属性が古ければ判定は誤ります。

IAM・IDaaS・IGA・PAM・AWS IAMの用語の境界と担当範囲の比較

IAMの周辺には似た略語が多く、製品の説明でも混同されがちです。担当範囲で並べると次のとおりです。

用語	主に担う範囲	IAMとの関係
IAM	ID管理・認証・認可・記録の全体	総称
IDaaS	認証とSSOをクラウドで提供	入口の層を担う製品形態
IGA	IDの発行から削除と権限の棚卸し	統制の層を担う
PAM	管理者など特権IDの貸出と操作記録	特権IDに限った強化
AWS IAM	AWS上のリソースへの権限付与	1つのクラウド内の認可機能

統制の層はIGA（IDライフサイクル管理とアクセス認証）、特権IDの扱いは特権ID管理の貸出・操作記録の仕組みで個別に扱っています。検索で「IAM」と打つとAWS IAMのユーザー・ロール・ポリシーの解説も多く出ますが、こちらはAWSアカウント内の権限に限った機能で、社員全体のIDを管理する仕組みではありません。

アクセス管理の中核になる認可モデル＝RBACとABACの仕組みと使い分けの条件

RBACの仕組みとINCITS 359が定めるロール階層と職務分掌の考え方

RBAC（ロールベースアクセス制御）は、権限を利用者へ直接付けず、「経理担当」「営業マネージャー」などのロールに束ねてから利用者へ割り当てる方式です。NISTのRole Based Access Controlプロジェクトによると、NISTのRBACモデルは2004年にANSI/INCITS 359-2004として米国の標準に採用され、2012年にINCITS 359-2012へ改訂されています。

実務で効くのは、ロール階層と相互排他のロールです。上位ロールが下位ロールの権限を引き継ぐ階層を使えば、マネージャーに担当者の権限を重ねて付ける手間が消えます。相互排他は、支払の申請と承認のように同じ人に持たせてはいけない組み合わせを機械的に拒否する仕組みで、職務分掌の監査にそのまま答えられます。

RBACは監査担当者に説明しやすいのが強みです。「経理担当ロールを持つ人は誰か」という問いに一覧で答えられます。実装の詳細はRBACの仕組みと導入判断の実装解説を参照してください。

ABACの仕組みとNIST SP 800-162が示す属性と環境条件での判定

ABAC（属性ベースアクセス制御）は、ロールではなく属性の組み合わせで可否を決めます。NIST SP 800-162は、主体（利用者）、対象（データやリソース）、要求された操作、場合によっては環境条件の属性を、ポリシーやルールと照らして判定する方式と定義しています。

「所属が経理部で、対象の伝票が自部門のもので、社内ネットワークから平日9時〜20時にアクセスした場合だけ編集を許す」といった条件は、RBACではロールを掛け算で増やさないと表現できません。ABACなら1本のポリシーで書けます。

代償は見通しの悪さです。属性とルールの組み合わせから「この人は結局何ができるのか」を一覧にするには、ポリシーを評価し直す仕組みが要ります。属性の値が人事システムから正しく届かなければ、判定は簡単に誤ります。

RBACとABACを併用する設計＝ロールで大枠を決め属性で例外を絞る分担

どちらか一方に寄せる必要はありません。企業のシステムで破綻しにくいのは、ロールで「どの業務機能を使えるか」の大枠を決め、属性で「どのデータまで触れるか」を絞る分担です。

受発注システムを例にすると、「受注入力」「出荷指示」といった画面単位の権限はロールで配り、どの拠点・どの取引先の伝票を見られるかは利用者の所属拠点属性と伝票の拠点属性の一致で判定します。ロールの数は業務機能の数に比例するだけになり、拠点が増えてもロールは増えません。

ロールの数が利用者数の半分を超えてきたら、属性へ逃がすべき条件がロールに混ざっている合図です。両者の使い分けはABACとRBACの使い分けの実装解説にまとめています。

企業IAM基盤の構成要素＝ID台帳・IdP・プロビジョニング・認可・監査の5層

人事データを起点にしたID台帳とSCIMによるアカウント配布の流れ

企業IAM基盤の最下層は、全社員のIDと属性を1か所で持つID台帳です。正しい値の出どころは人事システムに置きます。入社日・所属・役職・退職日を人事が登録し、その変更を台帳が受け取る形にすると、情報システム部門が退職者を聞き回る運用が要らなくなります。この台帳を専用製品で持つ場合の仕組みはID台帳を統合ID管理システムで持つ構成で整理しています。

台帳から各SaaSや業務システムへアカウントを配る工程がプロビジョニングです。標準の手段はRFC 7644（SCIMプロトコル）で、2015年9月に公開されたこの仕様は、ユーザーやグループの作成・更新・削除をHTTPのAPIとして定めています。SCIMに対応したSaaSなら、退職日に台帳でIDを無効にした時点で各サービスのアカウントも止まります。

SCIMに対応しない古い業務システムは、CSVの定期取込みやデータベースへの直接書き込みで連携することになり、ここが連携費用の大半を占めます。製品タイプごとの連携方式の違いはID管理システムの4タイプ比較で整理しています。

IdPとSSOが担う認証の入口と業務アプリ側に残る認可の責任範囲

IdP（Identity Provider）は、ログインを1か所で受け付け、認証の結果をSAMLやOpenID Connectで各システムへ渡す役割です。IDaaS（クラウド型IdP）のSAML・OIDC・SCIM連携を入れれば、多要素認証の強制や不審なログインの検知はこの層でまとめて掛けられます。

ただし、IdPが渡すのは「この人はAさんで、所属は経理部」という情報までです。会計システムのどの画面を開けるか、どの伝票を承認できるかは、受け取った側のアプリが判定します。SSOを入れたのに権限の事故が減らない組織は、この責任分担を見落としています。

2020年8月に公開されたNISTのSP 800-207（ゼロトラストアーキテクチャ）も、リソースへのアクセスを要求のたびに判定する構成を前提にしています。入口でのログイン1回で全てを許す設計とは考え方が逆です。

アクセスログと権限の棚卸しで監査に答える承認記録と操作記録の残し方

最上層は記録です。監査で問われるのは「今、誰が何の権限を持っているか」と「過去に誰が何をしたか」の2種類で、残すべきデータが違います。

前者には、台帳とロールの割当から作る権限一覧と、上長がその一覧を確認して承認した記録が要ります。後者には、IdPのログイン記録に加えて、業務アプリ側の操作記録が要ります。IdPのログだけでは、誰がいつログインしたかは分かっても、どの伝票を書き換えたかは分かりません。

実務でまず押さえるべきは前者の棚卸しです。年2回、部門長に自部門の権限一覧を確認させ、不要な権限を外した記録を残すだけで、監査指摘の多くは防げます。

IAM基盤を設計する順番と自社開発システムをつなぐときの改修範囲

ID台帳の整備から始めるIAM導入順序と各段階で止めてよい到達点

全社IAM基盤は一度に作りません。次の順番で進め、各段階で効果を確かめてから次へ進みます。

人事データとID台帳の突合（退職者ID・重複ID・所属の誤りを洗い出す）
IdPの導入と主要SaaSのSSO化（多要素認証の強制を含む）
SCIMや取込み処理による入社・異動・退職の自動反映
業務システムの認可をロールと属性で整理し直す
権限の棚卸しと操作記録の定期運用

従業員100人未満でSaaS中心の組織は、2までで止めても困りません。3以降が効くのは、異動が年に数十件あり、連携先のシステムが多い組織です。逆に1を飛ばして2から始めると、退職者や重複のIDまでSSOの対象になり、整理し直す手間が倍になります。

自社開発の業務システムをIAMにつなぐときの認証と認可の改修箇所

パッケージやSaaSはIdPとの連携機能を持っていますが、自社開発の業務システムは自分で改修する必要があります。改修箇所は大きく3つです。

1つ目はログイン処理で、自前のID・パスワード照合をやめ、SAMLまたはOpenID Connectで IdP の認証結果を受け取る形に置き換えます。OpenID Connectの仕様はOpenID Connect Core 1.0が正本です。2つ目はユーザー情報の受け取りで、SCIMのエンドポイントを実装するか、台帳からの定期取込みを作ります。3つ目が最も工数を食う認可の整理で、画面やAPIごとに散らばった権限チェックを、ロールと属性で判定する共通の処理へまとめ直します。

3つ目を後回しにしてログインだけ置き換えると、入口は新しくなっても権限の事故は減りません。一創では認証基盤・ID管理システム開発として、既存システムのIdP連携と認可処理の作り直しを、台帳の整備から一体で支援しています。

IAMの導入を全社で進めるべき組織と部分導入で足りる組織の判断基準

全社IAM基盤を前提に設計すべき条件＝監査要件・異動頻度・連携数

全社基盤として設計すべきかは、従業員数より次の3条件で決まります。

上場準備・J-SOX・ISMSなどの監査で、権限の棚卸し記録を求められる
組織変更や異動が多く、権限の付け替えが月単位で発生する
IDを持たせるシステムが10を超え、うち自社開発やオンプレミスの業務システムを含む

3つのうち2つ以上に当てはまるなら、ID台帳・プロビジョニング・認可・棚卸しまでを最初から全体設計に含めます。部分導入を重ねると、システムごとに別のロール表ができ、後から統合する費用のほうが高くつきます。

当てはまるのが1つ以下なら、全社基盤は過剰です。IDaaSの標準機能でSSOと多要素認証を入れ、ID台帳を人事データと月1回突合する運用で十分に回ります。費用の目安はID管理システムの課金単位と総額の増え方で比較できます。

IAM導入で失敗する典型パターン＝ロールの増えすぎと退職者IDの放置

最も多い失敗は、部署と役職の組み合わせをすべてロールにしてしまうことです。部署20×役職5で100ロールになり、例外のたびにロールを足すうちに、誰も中身を説明できない表ができます。拠点や担当取引先のような条件は属性へ逃がし、ロールは業務機能の単位に留めます。

次に多いのが、SSOを入れたことで安心し、IdPに連携していないシステムの退職者IDを放置する失敗です。SSO対象外のシステムこそ、台帳との突合を定期作業に組み込みます。

人以外のIDも見落とされがちです。バッチ処理やシステム連携用のサービスアカウント、APIキーは人事イベントで消えないため、担当者の退職後も残り続けます。こうした機械のIDは、人のIDとは別の台帳で持ち主と有効期限を管理します。

よくある質問

IDおよびアクセス管理（IAM）について、検討の初期によく出る疑問をまとめました。

IAMとID管理は同じ意味ですか？

同じ意味で使われることもありますが、厳密には範囲が違います。ID管理はIDの作成・属性の更新・無効化と削除を指し、人事イベントに合わせて動きます。IAMはそこにアクセス管理、つまりIDが何をしてよいかの判定と、その記録を加えた総称です。製品の説明で「ID管理システム」と書かれていても、認可の機能まで持つかは製品ごとに確認が要ります。

IAMとIDaaSの違いは何ですか？

IAMは考え方と仕組みの総称で、IDaaSはその一部をクラウドサービスとして提供する製品形態です。IDaaSが主に担うのは認証とSSO、SaaSへのアカウント配布で、業務アプリ内の細かな認可や、自社開発システムの権限設計までは担いません。IDaaSを契約しても、ID台帳の整備と各システムの認可の整理は自社の作業として残ります。

AWS IAMは社内のID管理にも使えますか？

使えません。AWS IAMはAWSアカウント内のリソース（EC2やS3など）に対する権限を付与する機能で、対象はAWSの操作に限られます。社員全体のIDを管理し、SaaSや業務システムへのログインをまとめる用途には、IdPやIDaaSを使います。両者をつなぐ場合は、IdPで認証した社員にAWSのロールを一時的に引き受けさせる構成が一般的です。

IAMの導入にはどのくらいの期間がかかりますか？

範囲で大きく変わります。SaaS中心の組織がIDaaSでSSOと多要素認証を入れるだけなら、ID台帳の突合を含めて数週間から2か月程度が目安です。自社開発の業務システムの認可を作り直し、人事システムからの自動反映まで含める場合は、連携するシステムの数と改修の量に比例して半年以上かかることもあります。

中小企業にもIAMは必要ですか？

必要ですが、全社基盤まで作る必要があるとは限りません。従業員が少なくSaaS中心なら、IDaaSでSSOと多要素認証を入れ、退職者のアカウントを当日に止める手順を決めるだけで、IAMの目的の大半は果たせます。監査で権限の棚卸しを求められる、自社開発システムを抱えているといった条件が加わった段階で、台帳と認可の整備に進みます。