>
>
公開日
特権ID管理をSaaSの管理者ロールの棚卸しに絞って解説します。サービスごとの管理者人数と保有者を数える手順から、退職者・異動者・委託先に残る権限、共有アカウント、見直し頻度と記録まで整理。情報システム部門の担当者・管理者が、権限の維持・縮小・削除を判断できる台帳の項目も示します。
特権IDとは
この記事では、SaaSの管理者ロールが付与されたアカウントを特権IDとして扱います。
本記事のポイント
管理者アカウント数と保有者数は分けて集計します。
在籍情報と委託契約を照合します。
変更後の権限まで再集計します。
SaaSの管理者権限を棚卸しする、法人の情報システム部門の担当者・管理者を対象とします。特権ID管理では、管理者アカウントの一覧だけでなく、誰がどの管理者権限を持つかを整理します。権限棚卸しで扱う課題は、アカウントと利用する人の対応、権限を残す業務上の理由、変更後に残った権限です。これらを分けて記録することで、継続する権限、解除する権限、保有者や利用目的の確認が済むまで判断を保留する権限を区別します。
棚卸しでは、管理者アカウントはログインに使う識別情報、管理者ロールは操作できる範囲を定める権限のまとまり、保有者はその権限を利用する人として区別します。アカウント数をそのまま人数として扱わず、アカウント・ロール・保有者の対応を整理します。
対象はSaaSの管理者ロールに限定し、サーバ・ネットワーク機器の特権ID、PAM製品の一般論・比較は対象外とします。緊急用アカウントやサービスアカウント、APIトークンの発行元アカウントは、管理者ロールが付与されていれば台帳の対象に含めて保有者を対応付けます。MFAの設定や操作ログの保全は権限の要否とは別の統制にあたるため、この棚卸しでは管理者権限を残すかどうかの判断に絞ります。
情報は2026年10月22日時点です。根拠のある事実は「現行の義務」と「推奨・手法の例示」に分け、独自の手順や台帳は「編集部の提案」として区別します。
▲ 特権ID管理において区別して整理する保有者、アカウント、ロールの関係性。
SaaSで特権IDが増える理由
導入時や担当変更時に追加した管理者権限を戻す契機がなければ、不要になった権限が残ります。
SaaSの特権ID管理では、管理者が増えること自体よりも、追加した理由・担当業務・終了条件を追えなくなる状態が棚卸しの課題です。
初期設定と担当交代に伴う追加
初期設定、担当交代、委託作業は、管理者権限を追加する契機になります。
導入時の設定作業や引き継ぎのために、一時的に複数の担当者へ権限を付ける運用は考えられます。ただし、作業の完了と権限の解除を結び付けなければ、追加時の必要性が失われても権限は残ります。追加の条件ごとに、次のように終了条件を対応付けます。
初期設定のために付与する場合は、設定完了後も管理業務を担当するかで継続を判断します。
担当交代で付与する場合は、引き継ぎ完了を旧担当者の権限を見直す契機にします。
委託作業で付与する場合は、依頼した作業の終了を権限の継続判断につなげます。
必要な業務が残っているのに人数だけを基準に解除すると、作業を止めるおそれがあります。追加理由を説明できない場合は、担当業務と必要な操作を整理してから、継続・縮小・解除を判断します。
業務別ロールと権限範囲の重なり
ロール名では判定せず、実行できる操作と対象範囲を台帳で確認します。
ロールとは、担当業務に応じて権限をまとめた役割です。利用者管理や設定変更などを別々の担当者に任せる場合でも、名称だけでは操作範囲の重なりを判断できません。必要な業務を限定的な権限で担えるなら範囲を縮小し、広い権限が必要なら、その理由を担当業務と結び付けます。
管理者という名前のアカウントだけを見るのは避けます。別の名称でも管理操作が可能なら、棚卸しの対象に含める判断になります。AIエージェントやAPI連携用のアカウント・トークンが管理者権限を持つ場合も、保有者を対応づけます。JPCERT/CCは10月8日の注意喚起で、APIトークンには必要最小限の権限だけを付与し、適切な有効期限を設けるよう求めています。
権限の最小化を求める一次資料
内閣官房国家サイバー統括室は2026年10月9日の「不正アクセスによる漏えい等の事案を踏まえた対応について」で、主な対策のポイントとして「管理者アカウントの利用者、アクセス権を必要最小限にする」「退職者、異動者や利用されていないもの等の不要なアカウントを速やかに無効化する」「委託先に付与するアクセス権を適切に管理する」「定期的にアカウントや権限設定を確認する」を挙げています（推奨）。
個人情報保護委員会は10月7日の注意喚起で、ガイドライン（通則編）別添の「手法の例示」の見直し予定内容を先取りして示しました（確定は2027年4月の予定）。アクセス制御の例示として、特権アカウントを割り当てる従業者・利用する端末・利用する場面等を最小限に限定すること、人事異動や退職の際にアクセス権限を変更すること、定期的な監査などでアクセス権限の棚卸しを行うことが挙がっています。いずれも見直し予定の手法の例示で、現行の義務ではありません。
現行の通則編10-6が「講じなければならない措置」とする技術的安全管理措置は、（1）アクセス制御から（4）情報システムの使用に伴う漏えい等の防止までの4つです。（1）では、担当者と取り扱う範囲を限定する適切なアクセス制御が求められています。SaaSの管理者権限を絞ることは、この措置を実践する手段の一つと編集部は考えています。委託先については法第25条（委託先の監督）があります。
SaaSごとの管理者の人数と保有者を数える手順
SaaSごとの管理者は、管理者アカウント数と、それを利用する保有者数を分けて集計します。アカウントの件数だけでは、同一人物による複数保有や共有利用を区別できません。特権ID管理の棚卸しでは、権限の付与先と実際に利用する人を対応付け、対応が取れないものは未解決として残します。
対象SaaSと集計単位の確定
IPAは10月9日の注意喚起で、利用している外部サービスを部署単位の利用も含めて洗い出すこと、その後の対策として「アカウント付与の範囲見直し」「アカウント棚卸の運用見直し」を挙げています（推奨）。一覧化の前に、対象SaaS、契約・管理環境、集計基準日を確定します。管理環境が分かれるSaaSは、環境別に抽出したうえで集計します。保有者は、管理者アカウントを実際に利用する人として扱い、申請者や承認者とは区別します。抽出日が基準日と異なる場合は、その間の権限変更も照合対象に含めます。
対象SaaSと集計基準日の確定：対象の管理環境と、いつの権限状態を数えるかを決めます。
管理者ロールの抽出：操作できる範囲を確認し、管理権限の付与先を一覧にします。
アカウントと保有者の対応付け：個人用・共有・所有者未特定に分け、利用者情報と照合します。
人数集計：アカウントの重複と人物の重複をそれぞれ除いて集計します。
未解決項目の切り分け：所有者、付与理由、期限などが不明な項目を、確認済みの結果から分離します。
対象外の管理環境がある場合は、その範囲を集計結果に添えます。抽出できていない環境を、管理者がいない環境として扱ってはいけません。
管理者ロールと付与経路の抽出
管理者ロールは、名称ではなく実際に操作可能な範囲で分類します。ロールとは、操作権限をまとめた役割です。全体管理と限定された管理を分け、ユーザー管理、権限変更、設定変更など、できる操作を台帳に記載します。画面上の「管理者」という表示だけで抽出対象を決めず、特定の部署や領域に限って管理できる役割も対象に含めます。
取得条件 | 抽出・記録の方法 |
|---|---|
管理者一覧をエクスポートできる場合 | 出力データを使い、アカウント識別子、ロール、権限範囲を整理します。 |
エクスポートできない場合 | 管理画面から同じ項目を転記し、表示条件やページの見落としを点検します。 |
グループ経由の付与がある場合 | グループへの権限付与と所属者の両方を展開し、対象アカウントまで対応付けます。 |
直接付与とグループ経由が重なる場合 | 付与経路を両方残し、アカウント数の集計では重複を除きます。 |
権限範囲が判別できない場合は、ロール名から全体管理と推測せず「権限範囲未確認」と記録します。付与経路も残せば、変更時にアカウントへの直接付与を外すのか、グループ所属を見直すのかを判断できます。たとえば退職者の直接付与だけを外しても、管理者グループへの所属が残っていれば管理権限は消えないため、グループ側の所属一覧まで確認して初めて削除完了と判定できます。
保有者の名寄せと人数集計
保有者数は、同じ人を複数回数えないように名寄せして集計します。名寄せとは、別々のアカウント情報を同一人物に対応付ける作業です。従業員情報や委託先の利用者一覧と照合できる場合は、氏名だけでなく識別情報も使って対応を確定します。表示名やメールアドレスが似ているだけでは統合せず、根拠が不足するものは未解決に分けます。
集計条件 | 管理者アカウント数 | 保有者数・別枠の扱い |
|---|---|---|
同一人物が複数アカウントを保有 | 識別子が異なるアカウントをそれぞれ数えます。 | 同一人物として重複を除きます。 |
同一アカウントに複数ロールを付与 | ロールごとに重複計上しません。 | 対応する保有者も重複計上しません。 |
共有アカウント | 共有アカウント自体を数えます。 | 利用者一覧と照合し、個人用アカウントの保有者との重複も除きます。 |
所有者が分からないアカウント | 管理権限があるものは集計に含めます。 | 人数を推測せず「所有者未特定」として別枠に残します。 |
全体管理と限定された管理を兼ねるアカウント | 範囲別にはそれぞれ記載し、総数では重複を除きます。 | 範囲別の人数を足し合わせず、人物単位で総数を出します。 |
集計結果は「管理者アカウント数」「確認済み保有者数」「所有者未特定のアカウント数」を分けて示します。共有アカウントの利用者が確定していない場合も、その旨を別記し、確認済み保有者数を実際の利用者全員の人数として扱わないようにします。
変更判断につながる台帳の作成
棚卸し台帳には、人数の集計に使う項目と、権限を残すか変えるかの判断材料を併記します。アカウント識別子を軸にロールと権限範囲を残し、共有の場合は保有者欄に利用者一覧を対応付けます。複数ロールを別行に記載するなら、集計時は同じ識別子の重複を除きます。以下の空欄を埋める形式で、SaaSごとの台帳として利用できます。
SaaS名 | アカウント識別子 | 管理者ロール | 権限範囲 | 付与経路 | 保有者 | 所属・契約先 | 付与理由 | 期限 | 判断 | 確認日 |
|---|---|---|---|---|---|---|---|---|---|---|
記入欄 | 記入欄 | 記入欄 | 記入欄 | 記入欄 | 記入欄 | 記入欄 | 記入欄 | 記入欄 | 記入欄 | 記入欄 |
表計算ソフトに貼り付ける場合は、次のCSVの見出し行と記入例をそのまま使えます（記入例の値は架空です）。
判断欄は「維持」「縮小」「解除候補」「要調査」などに統一します。付与理由と権限範囲が一致すれば維持、必要な操作より広ければ縮小、利用目的の終了が確認できれば解除候補に分けます。根拠がそろわないものは要調査とし、不明という理由だけで即時解除する扱いにはしません。
未解決項目が残る場合は、台帳にひも付く確認メモへ担当者・確認先・回答期限を記録します。
▲ SaaSごとの管理者人数と保有者を正確に把握するための5つの集計手順。
退職者・異動者・委託先に残った管理者権限
在籍情報や委託契約と照合し、現在の担当業務に必要な管理者権限だけを残します。
退職者と契約終了者の照合
退職・契約終了を確認したら、本人のアカウントは速やかに無効化します。国家サイバー統括室は、退職者や異動者などの不要なアカウントを速やかに無効化するよう求めています。後任者への管理操作の移管や連携処理の付け替えは、無効化とは別の作業として期限を決めて進め、移管が済んだらアカウントを削除します。
人事部門の在籍情報や契約管理担当者の情報をSaaS側の管理者一覧と対応づけ、氏名だけでなく社員番号やメールアドレスなど個人を識別できる情報で照合します。
委託先については、個人の識別情報、契約先、作業範囲、契約期間、社内責任者を台帳上で結び付けます。契約先との取引が続いていても、個人の担当作業が終わっていれば、その人の権限は残しません。国家サイバー統括室も、委託先に付与するアクセス権を適切に管理するよう挙げています。個人情報を扱う委託の場合は、「SaaSで特権IDが増える理由」の章で触れた法第25条（委託先の監督）の対象になります。
異動者と継続委託先の権限判定
異動後や契約継続中の権限は、現在の担当業務に合わせて維持・縮小・削除を決めます。所属や契約が続いていることだけを根拠に、以前の管理者権限は残しません。
照合結果 | 判断と実施内容 |
|---|---|
退職・契約終了を確認できた場合 | 本人のアカウントを速やかに無効化し、管理操作の移管が済んだら削除します。 |
異動後も管理業務が残る場合 | 残る管理操作を特定し、その操作に必要な範囲へ権限を縮小します。 |
担当業務が不明な場合 | 社内責任者と照合し、維持するなら理由と期限を決めます。必要な作業がないと判明した権限は削除します。 |
継続委託先でも、作業範囲が狭まった場合は権限を縮小します。維持すると決めた場合も、対象のSaaSと管理操作を記録し、期限が来たら再判定します。
後任への引き継ぎと変更結果の照合
無効化の前に、そのアカウントの権限を使う連携処理や自動実行がないかを確かめます。依存している処理があれば、後任者のアカウントや連携専用のアカウントへ付け替える担当と期限を決めます。管理者が1人しかいないSaaSでは、先に後任者へ管理者権限を付けてから無効化します。
変更前の権限、判断理由、承認者、変更後の権限は、対象アカウントの台帳に結び付けます。変更を依頼しただけでは完了にせず、SaaS側の管理者一覧を取り直し、予定した無効化・削除・縮小と一致すれば完了にします。取り直した一覧では、削除・無効化したはずのアカウントが再び有効になっていないかも確認します（IPAの点検項目）。
共有の管理者アカウント
共有の管理者アカウントは、アカウントの所有責任者と実際の利用者を分けて把握します。特権ID管理では、共有という理由だけで削除せず、利用者を特定できるか、個人別に代替できるか、管理を継続できるかで扱いを分けます。
所有責任者と利用者の対応付け
共有アカウントを棚卸しする際は、管理に責任を持つ人と、そのアカウントを使える人を別々に記録します。共有メールアドレスや部署名だけでは、保有者を確定させません。
棚卸し台帳には、対象アカウントにひも付けて所有責任者、利用可能者、利用目的、権限範囲を記載します。実際に操作した人だけでなく、認証情報を持ち利用できる人も把握する対象です。個人別アカウントも持つ人は、人数集計で重複させないよう対応付けます。
利用人数が分からない共有アカウントは「利用者未確定」として別枠に残し、確定した保有者数に混在させません。共有アカウントを集計対象から除外することも、所有責任者だけを利用者として数えることも避けます。
個人別アカウントへの移行条件
個人別の管理者アカウントを利用でき、必要な管理操作を引き継げる場合は、個人単位の管理へ移行します。移行と例外管理は、次の判断表で分けます。
判断条件 | 対応と記録 |
|---|---|
個人別で必要な管理操作を代替できる場合 | 代替の管理経路で操作できることを確かめてから、共有アカウントの利用を終了します。 |
個人別では代替できず、共有の管理を継続できる場合 | 共有を残す理由、利用者、見直し期限、認証情報の管理責任者を定め、例外として残します。 |
利用者や管理責任が未確定の場合 | 管理上の未解決事項として記録し、所有責任者のもとで利用者の特定と代替経路の確保を進めます。 |
共有アカウントの先行削除は避けます。切り替え先で必要な操作を引き継げなければ、削除を保留し、管理不能にならない経路を確保します。
共有を残す場合の例外管理
共有を残す場合は、利用者の変更に合わせて認証情報を管理し、操作主体を追える情報を確保します。個人別管理に比べ、利用者一覧と認証情報の管理を対応させ続ける負担が残ります。
利用者が変わった場合は、台帳を更新するとともに、外れた人が継続利用できないよう認証情報の変更や受け渡し先の見直しを行います。操作主体を記録で特定できるならその情報を利用し、できなければ利用申請・作業記録に氏名、利用日時、操作内容を残して対応付けます。特定のSaaSで共有利用が認められることや、監査ログで個人を識別できることは前提にしません。
▲ 共有管理者アカウントを個人別へ移行するか例外管理するかを判断するフロー。
定期的な見直しの頻度と記録
定期見直しに加え、退職・異動・契約終了や管理者を追加した時点でも権限を見直します。
更新周期に合わせた定期見直し
一次資料は「定期的に」とするだけで、頻度は定めていません（国家サイバー統括室、個人情報保護委員会の別紙）。編集部としては、人事異動の発令や委託契約の更新が集中する時期の直後を定期日にし、少なくとも半期に1回は前回との差分を照合することを提案します。初回に全体を把握し、2回目以降は追加・変更・削除の差分から確認します。
いつ | 何をするか | 誰が担うか |
|---|---|---|
初回 | SaaSごとの管理者権限と保有者を全体把握します。 | 情シスが一覧化し、人事・契約情報の管理者が在籍・契約情報を提供します。業務責任者が必要性を判断します。 |
定期日 | 前回との差分を照合し、増減と変更理由を確認します。 | 人事・契約情報の管理者が更新情報を渡し、情シスが差分を抽出します。業務責任者が維持・縮小・削除を承認します。 |
変更発生時 | 退職・異動・契約終了・管理者追加に伴う権限を判定します。 | 人事・契約情報の管理者が変更を通知し、業務責任者が要否を判断します。情シスが承認内容に沿って変更します。 |
変更後 | SaaS側の権限を取り直し、承認内容との一致を照合します。 | 情シスが結果を記録し、不一致があれば業務責任者と再判定します。 |
変更発生時の臨時見直し
退職・異動・契約終了は定期日まで待たず、その時点で対象の権限を判定します。管理者を追加するときは、付与理由と終了条件を台帳に登録します。引き継ぎなどで権限を一時的に残す場合は、例外期限と再判定の担当者を決め、期限までに継続の承認がなければ削除します。
判断と変更結果の記録
見直し履歴には、集計基準日、前回との差分、維持・縮小・削除の理由、承認者と承認日、例外期限、変更後の照合結果を残します。前回の一覧は上書きせず、比較できる形で保存します。
差分の確認では、付与の記録がない管理者アカウントや、記録のない権限の昇格がないかも見ます。JPCERT/CCは10月8日の注意喚起で、内部APIへの攻撃によって不正なアカウントの作成やユーザー権限の変更が行われた事例を挙げています。こうした差分が見つかったら、棚卸しの課題ではなくインシデントの疑いとして、社内の対応窓口に引き継ぎます。
まとめ
SaaSの特権ID管理は、次の3点から進めます。
SaaSごとに、管理者権限を持つアカウントの数と、実際に使っている保有者の数を分けて数えます。
退職・異動・委託終了の情報と照合し、退職者のアカウントは速やかに無効化します。共有の管理者アカウントは例外として、利用者と理由を記録します。
定期日と変更が起きた時点で見直し、前回との差分を記録します。記録のない管理者の追加や権限の昇格は、インシデントの疑いとして扱います。
根拠のうち、国家サイバー統括室とIPAの対策は推奨、個人情報保護委員会の別紙は2027年4月に確定予定の手法の例示、見直しの頻度は編集部の提案です。
まとめ
SaaSの管理者権限は、人数・保有者・付与理由を対応付けて見直します。特権ID管理の棚卸しでは、管理者アカウント数と保有者数を分け、人事・契約情報と照合します。定期的に見直し、変更結果を記録に残すところまでを運用に含めます。
最初の一歩は、管理しているSaaSの管理者一覧を取得し、保有者と現在の担当業務を対応付けることです。初回の完了条件は、対象SaaSすべてで各アカウントに保有者と判断（維持・縮小・解除候補・要調査）が記入され、所有者未特定のものには確認先と回答期限が残っている状態で、期限内に回答がなければ業務責任者に判断を上げます。製品導入を前提にせず、手元の一覧から着手できます。台帳の項目は、本文「変更判断につながる台帳の作成」の表をそのまま転記すれば、SaaSごとの一覧として使えます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
