>
>
公開日
アクセス権限の棚卸しは、社内の全SaaSについて「このアカウントは存在してよいか」「権限は業務に見合っているか」を、業務を知る承認者に確かめてもらう作業です。本記事では、一般ユーザーを含む全アカウントを年1回見直す手順を、対象の絞り方、データの集め方、人事マスタとの突合、承認者レビューの回し方、是正と記録の残し方の順に解説します。
本記事のポイント
棚卸しで確かめるのは「アカウントの存在」「権限の妥当性」「承認者の確認」の3点です
個人情報保護委員会が2026年10月7日に示した安全管理措置の見直し予定内容にも、アクセス権限の定期的な棚卸しが例示されています
全SaaSを同じ深さで見ると回りません。機密度とアカウント数で優先度を付けます
監査で説明に使えるのは、実施したことを示す記録です。依頼・回答・是正の記録を同じシートで追います
アクセス権限の棚卸しとは？確認する3つの観点
アクセス権限の棚卸しは、アカウントの一覧を作って終わる作業ではありません。一覧をもとに、業務部門の承認者が「この人にこの権限が必要か」を判断し、その結果を記録するところまでを含みます。
確認する3つの観点
棚卸しでは、アカウント1件ごとに次の3点を確かめます。
観点 | 確かめること | 見つかりやすい問題 |
|---|---|---|
存在してよいか | 在籍者・契約中の委託先など、使う理由がある人のアカウントか | 退職者・契約終了者のアカウント、持ち主のわからないアカウント |
権限が業務に見合うか | ロールや所属グループが、現在の業務に必要な範囲に収まっているか | 異動前の部署の権限が残っている、一般業務なのに編集・管理権限がある |
承認者が確認したか | 業務を知る人が妥当と判断し、その判断が記録に残っているか | 情シスが一覧を眺めただけで、承認の記録がない |
3つ目の観点が欠かせないのは、情シスだけでは権限の妥当性を判断しきれないからです。情シスはSaaSの設定に詳しくても、各部署の業務にどの権限が必要かまではわかりません。承認の記録がなければ、監査で「誰が妥当と判断したのか」も説明できません。
最小権限の原則との関係
最小権限の原則とは、利用者に業務上必要な最小限の権限だけを与える考え方です。権限は、付与した時点では業務に見合っていても、異動やプロジェクトの終了とともに過剰になっていきます。棚卸しは、ずれた権限を定期的に業務に見合う範囲へ戻す作業です。
本記事で扱う範囲
本記事は、一般ユーザーを含む全アカウントを対象に、年1回のレビューを回す手順に絞ります。近いテーマは次の記事で扱っています。
SaaSの管理者ロール・特権IDに絞った見直しは、特権ID管理とSaaS管理者ロールの棚卸し
使われていないライセンスの削減など、コストを目的にした棚卸しは、SaaS棚卸しの手順
退職者のアカウントを止める手順は、IdP停止後のSaaS確認手順
監査・認証で求められる権限見直しと頻度の決め方
主要な基準は、アクセス権限を定期的に見直すことを求めていますが、頻度を「年何回」と数字で定めているものは多くありません。基準の要求を確かめたうえで、自社のリスクに合わせて頻度を決めます。
主な基準が求めていること
情シスが関わることの多い4つの基準を、公表資料に沿って整理します。
基準 | 公表資料での位置づけ | 棚卸しとの関係 |
|---|---|---|
個人情報保護法の安全管理措置 | 個人情報保護委員会は2026年10月7日の注意喚起の別紙で、ガイドライン（通則編）の技術的安全管理措置の見直し予定内容を先取りして示しました。「アクセス制御」の手法の例示には、人事異動や退職時の権限変更と、定期的な監査などによるアクセス権限の棚卸しが挙がっています | 見直しの確定は2027年4月の予定です。手法の例示は、すべて講じなければ法違反になるものではないと明記されています |
ISMS（ISO/IEC 27001:2022） | 附属書Aの管理策「5.18 アクセス権」は、アクセス権の提供・レビュー・変更・削除を、組織のアクセス制御の方針に沿って行うことを扱います | レビューの頻度や方法は、組織が方針として決めます |
J-SOX（財務報告に係る内部統制） | 金融庁が公表している実施基準は、IT全般統制の例として「内外からのアクセス管理などシステムの安全性の確保」を挙げています | 会計・販売など財務報告に関わるシステムの権限管理は、IT全般統制として評価される領域です |
SCS評価制度（★3） | 経済産業省の資料では、★3は毎年自己評価を行い、結果を評価機関へ提出する仕組みです | 棚卸しの記録は、毎年の自己評価で対策状況を示す材料になります |
個人情報保護委員会の注意喚起の内容は、個人情報保護委員会のWARNING改訂と情シスの点検ポイントで、安全管理措置全体の進め方は安全管理措置を実務に落とすアクセス制御と権限管理で解説しています。ISMSの規格の構成はISO/IEC 27001の改正点と情シスの実務対応、SCS評価制度★3の要求事項はSCS評価制度★3チェックリストが参考になります。
頻度は「定期」と「変更時」の2本立てにする
年1回の定期棚卸しだけでは、異動や委託契約の終了から次の棚卸しまで、不要な権限が残る期間が長くなります。そこで、定期の見直しと、人の動きをきっかけにした見直しを分けて決めておくと運用しやすくなります。
見直しの種類 | 頻度の目安（編集部の提案） | 対象 |
|---|---|---|
定期棚卸し | 年1回 | 全SaaS・全アカウント |
高リスクSaaSの追加棚卸し | 半年に1回 | 個人データを大量に扱うSaaS、財務報告に関わるシステム |
変更時の見直し | 都度 | 異動・退職・休職者、契約を終えた委託先、終了したプロジェクトのメンバー |
定期棚卸しの時期は、ISMSの審査、J-SOXの評価、SCS評価制度の更新など、記録を提出する時期から逆算して決めます。審査の直前に慌てて実施すると、承認者の回答期限が短くなり、形だけのレビューになりがちです。
棚卸しの対象と優先順位の決め方
全SaaSを同じ深さで見ようとすると、承認者の負担が増えて回答が集まりません。SaaSを機密度とアカウント数で3段階に分け、段階ごとに確認の深さを変えます。
SaaSを3段階に分ける
優先度 | 当てはまるSaaSの例 | 確認の深さ |
|---|---|---|
A | 人事・労務、会計、顧客管理（CRM）、ファイル共有、ソースコード管理など、個人データや機密情報、財務データを扱うもの | 全アカウントについて、ロール・グループまで承認者が確認する |
B | チャット、メール、ドキュメントなど全社員が使うコミュニケーション基盤 | 人事マスタとの不整合と、標準より高い権限を持つアカウントを承認者が確認する |
C | 特定部署だけで使うツール、閲覧中心のツール | 人事マスタとの不整合だけを確認する |
Bの全社基盤は、アカウント数が多い一方で、ほとんどの人が同じ標準権限です。全件を承認者に見せるより、標準と違うアカウントだけを抜き出す方が、確認の質が上がります。
対象から漏れやすいもの
対象のSaaS一覧は、情シスが契約を把握しているものだけで作ると漏れが出ます。部署が独自に契約したSaaSや、無料プランのまま業務で使われているSaaSにも、社員のアカウントと業務データがあるためです。経費精算やコーポレートカードの明細、IdPのログと突き合わせて一覧を補います。把握していないSaaSが見つかる理由と対策は、シャドーITの原因と企業の対策で整理しています。
アカウントの種類にも漏れやすいものがあります。
業務委託・派遣・アルバイトなど、人事マスタの正社員一覧に載らない人のアカウント
招待中のまま放置されたアカウント、外部の取引先を招待したゲストアカウント
部署で共有しているアカウント、システム連携用のサービスアカウント
手順１：アカウントと権限のデータを集める
最初の手順では、対象SaaSごとにアカウントと権限の一覧を、取得した日時と範囲がわかる形で集めます。取得範囲が曖昧なままだと、一覧に載っていないアカウントが「存在しない」のか「取得していない」のかを区別できません。
データの取り方
データの取り方は、主に次の3つです。
取り方 | 向いている場面 | 注意点 |
|---|---|---|
各SaaSの管理画面からCSVを出力する | 対象SaaSが少ない、管理画面にエクスポート機能がある | SaaSごとに項目名や形式が違い、そろえる作業が発生する。有効なユーザーだけが既定表示になっている画面もある |
IdP（ID管理の基盤）から取得する | SSOやSCIMでつないでいるSaaSが多い | IdPに登録していないSaaSや、SaaS側で直接作られたアカウントは見えない |
SaaS管理ツールで横断的に取得する | SaaSが多く、毎年同じ形式で比較したい | 連携していないSaaSは、管理画面からの出力で補う |
IdPのアカウントを止めてもSaaS側のアカウントが残る理由は、SaaS管理の定義と4つの管理対象の「IDaaS（SSO）との違い」で解説しています。
集める項目
後の突合と承認者レビューで使うため、少なくとも次の項目をそろえます。
SaaS名と、テナント・ワークスペースなどの範囲
ユーザーの識別子、メールアドレス、表示名
ロール・権限、所属グループ
アカウントの状態（有効・無効・招待中など）
最終ログイン日時（取得できるSaaSのみ）
認証方式（SSO経由か、SaaS独自のID・パスワードか）
取得日時と取得者
最終ログイン日時は、プランによっては管理画面に出ないことがあります。取得できない項目は空欄のまま「取得不可」と記録し、推測で埋めないようにします。
手順２：人事マスタと突合し、不整合を分類する
集めた一覧を人事マスタと突き合わせ、問題のありそうなアカウントを種類ごとに分けます。種類によって、次に誰が何を判断するかが変わるためです。
突合の基準をそろえる
突合は、社員番号など変わらない識別子で行うのが確実です。メールアドレスは、改姓や組織再編で変わることがあり、SaaSによっては個人のアドレスで登録されていることもあります。氏名だけが一致する場合は、同一人物と決めつけずに確認対象に回します。
人事マスタに正社員しか載っていない場合は、業務委託やアルバイトの情報を各部署から集める必要があります。情シス用に、雇用形態や契約形態を含めた従業員一覧を別に持っておくと、毎年の突合が楽になります。
不整合の分類と次の対応
分類 | 状態 | 次の対応 |
|---|---|---|
退職済み・契約終了 | 人事マスタでは退職済みなのに、アカウントが有効 | 承認者レビューを待たずに停止する |
異動済み | 所属は変わったが、前の部署のグループやロールが残っている | 現在の上長に、権限の継続・縮小を判断してもらう |
所属不明 | 人事マスタに該当者がいない、識別子が一致しない | SaaSのオーナー部署に持ち主を確認する |
共有アカウント | 個人にひも付かない部署共有のID | 管理責任者を決め、利用者と利用目的を記録する |
外部委託・ゲスト | 社外の人のアカウント | 契約を担当する社内の部署に、契約期間と必要な権限を確認する |
長期未ログイン | 有効だが、長期間ログインがない | 上長に利用継続の要否を確認する |
標準より高い権限 | 部署の標準ロールより上の権限がある | 上長とSaaSオーナーに、業務上の必要性を確認する |
使われていないアカウントの解約によるコスト削減は、SaaSライセンス管理の削減マトリクスと進め方でも扱っています。本記事の棚卸しでは、ライセンスの有無より、権限が業務に見合っているかを判断の軸にします。
手順３：業務部門の承認者にレビューを依頼する
承認者レビューでは、部署の上長に「部下のアカウントと権限が業務に必要か」を判断してもらいます。情シスの役割は、判断しやすい形に一覧を整え、期限までに回答を集めることです。
承認者を決める
承認者は、原則として利用者の上長にします。業務に何が必要かを一番知っているのは上長だからです。ただし、上長は各SaaSのロールで何ができるかまでは知らないことが多いため、ロールの意味はSaaSのオーナー部署か情シスが説明を添えます。
承認者を決めるときは、次の2点に注意します。
承認者自身のアカウントは、さらに上位の人が承認する。 自分の権限を自分で承認すると、確認の意味がなくなります
情シスのアカウントも対象に含める。 情シスの管理者権限は情シス以外の責任者が確認します。特権IDの見直し方は特権ID管理の記事で解説しています
一覧の見せ方：全件か差分か
承認者に送る一覧は、部署単位に切り出し、1人の承認者が見る行数をできるだけ減らします。初回の棚卸しは全件を見てもらい、2回目以降は次の形に絞ると負担が下がります（編集部の提案）。
優先度AのSaaS：全件
優先度B・CのSaaS：前回の棚卸しから増えた・変わったアカウントと、手順②で不整合に分類したアカウント
回答の選択肢と期限
自由記述で回答を集めると、集計のたびに解釈が必要になります。回答は次のような選択肢から選んでもらいます。
回答 | 意味 | 情シスの対応 |
|---|---|---|
継続 | アカウントも権限も今のままでよい | 記録して完了 |
権限を下げる | アカウントは必要だが、ロールやグループが過剰 | 変更後の権限を確認して実施 |
削除・停止 | アカウント自体が不要 | 停止・削除を実施 |
自分の部下ではない | 承認者の担当外 | 正しい承認者を確認して依頼し直す |
回答期限は2週間程度を目安にし、期限の数日前と期限当日に催促します。期限を過ぎても回答がない場合に「継続」とみなす運用は避けます。未回答のアカウントは、承認者の上位者へエスカレーションし、それでも回答がなければ権限を下げる、などのルールを事前に決めておきます。
手順４：是正して証跡を残す
承認者の回答に沿って権限を変更し、変更後の状態をもう一度取得して確かめます。監査や審査で説明に使えるのは、計画から是正までを追える記録です。
是正と例外承認
「権限を下げる」「削除・停止」と回答されたアカウントは、変更を実施した後に一覧を再取得し、期待した状態になっているかを確かめます。変更の操作をしたことと、変更後の状態を確認したことは、別々に記録します。
業務の都合ですぐに権限を下げられない場合は、例外として扱います。例外には、理由、期限、承認者を必ず付け、期限が来たら再び判断します。期限のない例外は、次の棚卸しまで放置されやすいためです。
退職者のアカウントで不審な利用が見つかった場合は、削除を急がず、利用を止めたうえで調査担当に引き継ぎます。削除と無効化の判断は退職者のアカウント削除の記事で詳しく解説しています。
残しておく記録
記録 | 内容 |
|---|---|
実施計画 | 対象SaaS、優先度、実施期間、担当者 |
取得データ | SaaSごとの一覧、取得日時、取得範囲、取得者 |
依頼と回答 | 承認者、依頼日、回答日、回答内容 |
是正 | 実施者、実施日時、変更前と変更後の権限 |
例外 | 理由、期限、例外を認めた人 |
完了確認 | 再取得した一覧と確認日時、未完了の件数と理由 |
IT監査で求められる証跡の整え方は、IT監査対応と証跡管理で解説しています。
棚卸しシートの列構成
依頼・回答・是正を別々のファイルで管理すると、どのアカウントがどこまで進んだかを追えなくなります。アカウント1件を1行にし、次の列を持つシートで最後まで追うと、記録をそのまま監査に出せます。
列 | 記入例 |
|---|---|
棚卸し実施回 | 2026年度 定期 |
SaaS名・範囲 | 顧客管理SaaS／営業部ワークスペース |
優先度 | A |
ユーザー識別子 | 社員番号 10234 |
氏名・所属（人事マスタ） | 山田 太郎／営業企画部 |
雇用形態 | 正社員 |
ロール・権限 | 管理者 |
最終ログイン | 2026/09/30 |
不整合の分類 | 異動済み（前所属：営業1部） |
承認者 | 営業企画部長 |
回答・回答日 | 権限を下げる（一般ユーザーへ）／2026/11/05 |
是正内容・実施者・実施日 | 一般ユーザーへ変更／情シス 佐藤／2026/11/06 |
再確認日 | 2026/11/07 |
例外の理由・期限 | （なし） |
記入例の氏名・日付は架空のものです。列は自社の監査で求められる項目に合わせて増減してください。
棚卸しを毎年軽くする仕組み
棚卸しの負担は、前回からのずれの量で決まります。人事情報の変更がアカウントと権限に自動で反映されるほど、毎年の棚卸しで見つかる不整合は減ります。
SCIMで人事情報の変更を自動で反映する
SCIMは、IdPで行ったアカウントの作成・変更・無効化を、各SaaSに自動で反映するための標準の仕組みです。人事情報をIdPに取り込み、SCIMで各SaaSへつなげば、退職や異動のたびに手作業で変更する必要がなくなります。仕組みの基本はSCIMとは？自動プロビジョニングの仕組みで解説しています。
ただし、SCIMに対応しているかどうかは、SaaSや契約プランによって異なります。グループやロールまで同期できるかも、SaaSとIdPの組み合わせ次第です。自社で使っているSaaSの対応状況はSCIM対応SaaS一覧で、IdPごとの設定手順はSCIMプロビジョニングの設定手順で確認できます。
部署や職種ごとに付与する権限を決めておくと、異動時に「何を外して何を付けるか」が明確になります。権限の設計方法はRBACの設計手順、入社・異動・退職の流れ全体は入退社フローテンプレートが参考になります。
SCIM非対応のSaaSを含めて横断的に把握する
SCIMに対応していないSaaSや、IdPを経由しないアカウントは、自動反映の仕組みだけでは管理できません。棚卸しの対象から外れないよう、SaaSとアカウントを横断的に把握する仕組みを別に用意します。
マネーフォワード Admina（以下、Admina）は、連携しているSaaSのアカウントを一覧にまとめ、アカウントごとのロールやステータス、2要素認証の設定状況を確認できます（SaaS可視化）。連携できるSaaSの数は国内トップクラスで、従業員マスターと照合して退職済みのアカウントを検知し、入社日・退職日を起点にアカウントの発行・削除を予約実行することもできます（ID管理、オートメーション）。
棚卸しの突合で手間がかかる部分にも使えます。Admina Directoryは、業務委託やアルバイトを含めた情シス用の従業員マスターを持ち、従業員マスターに登録されていないアカウントを「未登録ID」として検知します。利用者に利用状況を確かめたい場合は、棚卸しサーベイでメールやSlackにアンケートを配信し、回答を集計できます。
note株式会社では、半年に1回ほど各SaaSの管理画面を見ながら棚卸しをしていましたが、Admina導入後はアカウントの登録状況が自動で連携され、棚卸しの年間作業時間を90%削減できたと話しています（note株式会社の事例）。
よくある質問（FAQ）
Q. アクセス権限の棚卸しは、どのくらいの頻度で行えばよいですか？
A. 全SaaSを対象にした定期棚卸しを年1回行い、異動・退職・委託契約の終了のたびに都度見直すのが基本です。ISO/IEC 27001や個人情報保護委員会の資料は頻度を数字で定めていないため、個人データを大量に扱うSaaSや財務報告に関わるシステムは半年に1回にするなど、リスクに応じて決めます。
Q. 特権IDの棚卸しとは何が違いますか？
A. 特権IDの棚卸しは、SaaSの管理者ロールなど強い権限を持つアカウントに絞った見直しです。本記事の棚卸しは、一般ユーザーを含む全アカウントが対象です。管理者ロールは影響が大きいため、全体の棚卸しとは別に、より短い間隔で見直す企業もあります。
Q. SaaS棚卸しとアクセス権限の棚卸しは同じ作業ですか？
A. 使うデータは似ていますが、目的が違います。SaaS棚卸しは、利用中のSaaSと契約・ライセンスを把握し、コストの無駄を減らすことが主な目的です。アクセス権限の棚卸しは、アカウントと権限が業務に見合っているかを承認者が確認し、記録に残すことが目的です。同じ一覧を使って、両方を同時に進めることもできます。
Q. SSOやSCIMを導入していれば、棚卸しは不要ですか？
A. 不要にはなりません。SSOやSCIMでつないでいないSaaSや、SaaS側で直接作られたアカウントは、IdPの管理から外れています。SCIMでつないでいても、ロールやグループが同期されないSaaSもあります。自動化で減るのは不整合の量で、承認者が権限の妥当性を確認する作業は残ります。
Q. 承認者がなかなか回答しない場合は、どうすればよいですか？
A. 期限前と期限当日に催促し、それでも回答がなければ承認者の上位者にエスカレーションします。未回答を「継続」とみなすと、棚卸しの記録としての意味がなくなります。未回答の場合の扱いは、棚卸しを始める前に決めて承認者に伝えておきます。
Q. 業務委託やゲストのアカウントは、誰が承認すればよいですか？
A. 委託契約や取引先とのやり取りを担当している社内の部署の責任者が承認します。契約の終了日をあわせて記録しておくと、次の棚卸しを待たずに停止の判断ができます。
Q. Excelで棚卸しを管理しても、監査で問題になりませんか？
A. 依頼・回答・是正の記録が追える形になっていれば、Excelでも説明はできます。ただし、SaaSの数が増えると、一覧の取得と形式の統一に毎年かなりの時間がかかります。対象SaaSが多い場合は、SaaS管理ツールで一覧の取得を自動化すると、承認者レビューと是正に時間を回せます。
まとめ
アクセス権限の棚卸しは、アカウントの一覧を作る作業と、業務を知る承認者が権限の妥当性を判断する作業の2つでできています。後者の記録が残っていないと、監査では実施したと説明できません。最後に、年次の棚卸しで押さえる点をチェックリストにまとめます。
✅ 定期棚卸しの時期を、ISMS審査やJ-SOX評価、SCS評価制度の更新から逆算して決めている
✅ 異動・退職・委託契約の終了時に、都度権限を見直すルールがある
✅ 対象SaaSの一覧に、部署が独自に契約したSaaSも含めている
✅ SaaSを優先度A・B・Cに分け、確認の深さを変えている
✅ アカウント一覧に、取得日時と取得範囲を記録している
✅ 人事マスタと社員番号などの識別子で突合し、不整合を分類している
✅ 承認者を利用者の上長にし、承認者自身と情シスの権限は別の人が承認している
✅ 回答を選択肢で集め、未回答時の扱いを事前に決めている
✅ 是正後に一覧を再取得し、変更後の状態を確認している
✅ 例外には理由・期限・承認者を付けている
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
