.png)
「誰がどのシステムにどんな権限を持っているか、正直把握しきれていない」と感じている情シス担当者は珍しくありません。Google WorkspaceやSlack、Salesforceなど20種類以上のSaaSを使う企業では、従業員の入退社・異動のたびにアクセス権限の管理が追いつかなくなりやすく、気づいたときには退職者のアカウントがそのまま残っているといった事態が起きています。退職者や異動後のSaaSアカウントが適切に管理されていないと感じている情シス担当者は多く、これは珍しい課題ではありません。
こうした状況は、情報漏洩・不正アクセスのリスクを生むだけでなく、J-SOX(IT全般統制)の評価やISMS認証の審査においても「アクセス管理が不十分」として指摘される原因になります。監査法人から指摘を受けた後に慌てて整備しようとしても、記録や証跡がなければ対応に限界があります。
本記事では、アクセス権限棚卸しの5ステップ手順から、監査対応に使えるアカウント管理台帳の作り方、SaaS環境での工数削減方法、J-SOX・ISMS審査で求められる証跡の整備まで体系的に解説します。情シス担当者として棚卸し体制を整備・改善したい方に向けた内容です。
アクセス権限の棚卸しとは、従業員のアカウントと権限が業務・役職に適切に設定されているかを定期的に確認・見直す作業のことです。SaaS導入数が増加した現在、なぜ情シス担当者にとって最重要課題になっているのかを整理します。
アクセス権限の棚卸しと、日常的なアカウント管理は異なる役割を持ちます。この違いを理解することが、適切な管理体制の設計につながります。
アカウント管理は、入社時のアカウント発行、異動・昇格時の権限変更、退職時の削除といった日常的なアカウントのライフサイクル操作を指します。内部統制の観点では「予防的統制」に分類され、問題が起きる前に適切な状態を維持する仕組みです。
これに対して棚卸しは、現在のアカウントと権限の状態が正しいかどうかを定期的に確認する「発見的統制」です。日常的なアカウント管理では気づけなかった問題、たとえば半年前に異動した社員の旧部署の権限が残っていたり、業務委託終了後のアカウントが削除されていなかったりといった状態を洗い出し、修正することが目的です。予防的統制と発見的統制の両方を整えることで、内部統制としての完成度が高まります。
SaaS導入数の増加が、アクセス権限管理の複雑性を急速に高めています。国内企業が利用するSaaSの平均数は増加の一途をたどっており、人事・財務・営業・コラボレーションなど多岐にわたるシステムで個別にアカウント管理が発生しています。
特に問題となるのが、退職者・異動者への対応です。退職処理は人事部門が中心に動きますが、各SaaSのアカウント削除は情シス担当者が個別に対応する必要があります。連絡が漏れる、削除タスクが後回しになる、気づいたときにはアカウントが数ヶ月放置されていた、という状況は多くの情シス担当者が経験しているはずです。
リモートワークの普及も棚卸しの必要性を高めています。出社が前提だったオフィス環境では、人の動きを目で見て権限変更の必要性に気づけましたが、リモート環境ではそうした自然な気づきが失われています。
アクセス権限の棚卸しを怠ることで発生するリスクは大きく3種類あります。いずれも、発覚した後の対処が難しく、事前の予防が何より重要です。
第一は情報漏洩・不正アクセスです。退職者のアカウントが有効なままであれば、元従業員がいつでも顧客データや機密情報にアクセスできる状態が続きます。悪意を持った元従業員による情報持ち出しはもちろん、アカウント情報が外部に流出した場合の被害も深刻です。
第二は過剰権限による内部不正の温床化です。業務変更・異動・昇格を経るたびに新しい権限が追加される一方、不要になった権限が削除されないまま蓄積すると「特権の肥大化(Privilege Creep)」が起きます。本来アクセスできるべきでないデータを閲覧・操作できる状態が生まれ、内部不正のリスクが高まります。
第三はJ-SOX・ISMS審査での指摘です。IT全般統制評価やISMS内部監査では、アクセス権限の棚卸し実施状況と記録が確認されます。「実施していなかった」「記録が残っていなかった」という状態は、統制上の重大な不備として指摘対象になります。
.jpg)
J-SOX対応において、監査法人からアクセス管理の不備を指摘されるケースは少なくありません。どの点が問題視されるかを事前に理解しておくことが、実効性のある棚卸し体制の設計につながります。
アカウントの発行・変更・削除を行う際に申請履歴と承認記録が残っていないことは、監査法人が最も頻繁に指摘するポイントの一つです。「このアカウントはいつ、誰が、どのような目的で発行したのか」を証明できない状態は、IT全般統制として機能していないと判断されます。
評価で確認されるのは、申請記録の存在だけでなく、アカウント管理台帳との整合性です。「申請があった記録はあるが、台帳の情報と一致しない」「承認者の記録がない」といった状態も指摘の対象になります。メールで申請・承認を行っている場合は、そのメール記録が残り続けることが前提ですが、担当者交代や受信ボックスの整理でデータが失われるリスクがあります。ワークフローシステムや管理台帳への記録一元化を検討することが望まれます。
監査法人が確認する棚卸しの評価ポイントは、実施していること、定期的に実施していること、記録が残っていること、責任者の承認を得ていること、という4点です。これらのいずれかが欠けていると、統制として機能していないと判定されます。
実施頻度については、最低でも年1〜2回、できれば四半期に1回の実施が評価上の基準とされています。年に1回のみの実施では「退職者が発生してから最長1年間、アカウントが残存し続ける可能性がある」とみなされ、リスク評価が高くなります。また、SaaSを新たに導入した際に棚卸し対象に追加していないケースも頻繁に指摘される問題です。導入したSaaSを棚卸しリストに都度追加するプロセスを整備しておく必要があります。
システムへの全権アクセスを持つ特権IDの管理は、一般ユーザーのアカウント管理以上に厳格な対応が求められます。監査法人が確認するのは、特権IDの保有者リストが最新状態に保たれているか、使用時に申請・承認・操作記録のログが残っているか、そして保有者が業務上の必要最小限に絞られているかです。
スタートアップや急成長企業では、手軽さから全員に管理者権限を付与してしまうケースが見られます。これは業務上の必要性とアクセス権限の付与が乖離した高リスク状態であり、監査法人から強く指摘される典型的なパターンです。特権IDの棚卸しは一般アカウントよりも高い頻度で実施し、使用の都度の申請・承認ログを保管することを推奨します。

棚卸しを確実に実施し、監査対応にも使える記録を残すには、準備から記録完了まで5つのステップに沿って進めることが重要です。各ステップで何をするかと、何を記録するかの両方を意識してください。
棚卸しの第一歩は、自社で使用している全システムのアカウント情報を一覧化することです。社内で利用している全SaaSと社内システムをリストアップし、各サービスの管理画面からアカウント一覧をエクスポートします。
確認すべき情報は、ユーザー名・メールアドレス・権限レベル(管理者/一般/閲覧のみ等)・最終ログイン日時です。最終ログイン日時は「長期間未使用のアカウント」を発見するうえで特に重要な項目です。SaaSによってエクスポート形式(CSV・JSON等)が異なるため、事前にどのSaaSからどのように情報を取得するかを整理しておくとスムーズです。
エクスポートしたアカウント一覧を、人事部門が管理する在籍データ(従業員マスター)と照合します。この照合で発見できる問題が最も多いステップです。
確認すべき主要項目は以下のとおりです。
特に業務委託・外部パートナーは人事システムに登録されないケースが多く、管理の死角になりやすい点に注意が必要です。外部関係者のアカウント管理は別途台帳を整備することを推奨します。
アカウントの存在を確認したうえで、次に「権限の内容が現在の業務に適切か」を確認します。このステップにはユーザー部門のマネージャー(業務責任者)の協力が不可欠です。
IT部門だけでは、各部門メンバーの業務内容や権限の必要性を判断できません。各部門のマネージャーに「自部門メンバーの権限リスト」を送付し、この権限は現在の業務上必要か、変更・削除すべき権限はあるか、を確認してもらいます。確認結果の回答期限を設定し、期限内に返答がなかった場合のエスカレーションルールも決めておきましょう。
このプロセスが棚卸しの中核です。情シス単独で完結させようとすることが多くの失敗の原因であり、「業務上の必要性はユーザー部門が判断する」という役割分担を明確にすることが重要です。
Step3の確認結果をもとに、実際のアカウント変更・削除を実施します。退職者アカウントの即日削除、過剰権限の縮小(管理者権限から一般ユーザー権限へのダウングレード等)、不要なアカウントの無効化を行います。
変更・削除を実施する際は、作業内容・実施日時・実施者をすべて記録に残してください。この記録が後のステップでの台帳更新と、将来の監査対応の証跡になります。変更作業中に誤って必要なアカウントを削除してしまうリスクを避けるため、変更前に再確認のプロセスを設けることも有効です。
棚卸しの最後のステップは、実施記録をアカウント管理台帳に反映し、責任者の承認を得ることです。このステップが完了して初めて、内部統制上有効な棚卸しが実施されたと認められます。
IT部門の責任者だけでなく、各ユーザー部門の責任者による承認記録も必要です。いつ・誰が・どの範囲で棚卸しを実施し・何を変更し・誰が承認したか、の記録が、J-SOX評価やISMS審査の際に提示する証跡となります。棚卸し完了後は、次回の実施予定日も台帳に記録しておきましょう。

棚卸しの証跡として最も重要な書類がアカウント管理台帳です。J-SOX審査やISMS内部監査で提示できる台帳を整備するには、記載項目と運用フローを設計しておくことが先決です。
アカウント管理台帳は、各従業員のアクセス権限の現状と変更履歴を一元的に管理するための基盤書類です。以下の項目を含む台帳を整備してください。
このテーブルをExcelで管理している企業も多いですが、複数人が同時に編集するとファイルが破損するリスクや、バージョン管理の煩雑さが課題になります。Google スプレッドシートや専用のワークフローツールを活用することで、複数人での同時編集と変更履歴の自動記録が可能になります。
台帳を整備しても運用フローが定まっていなければ、すぐに情報が陳腐化します。以下のタイミングで台帳を更新するプロセスを確立してください。
入社時は新規アカウント発行と同時に台帳へ登録します。権限の付与理由・承認者・付与日を必ず記録します。異動・昇格時は変更内容を台帳に反映し、前の役職で保有していた権限の要否を確認・承認します。退職時はアカウント削除と同時に台帳に削除記録を残します。削除日・削除実施者・承認者を必ず記録してください。定期棚卸し時には全件を照合し、変更内容と承認結果を台帳に反映します。
運用フローを文書化し、情シス担当者の業務手順書として整備しておくことで、担当者が変わっても同じ品質の管理が継続できます。

複数のSaaSを導入している企業では、アクセス権限棚卸しの難易度がオンプレミス時代とは比べ物にならないほど高まっています。SaaS特有の課題を正確に把握し、対処法を整えることが現代の情シス担当者に求められます。
SaaS環境での棚卸しが困難な理由は、主に3つの構造的な問題から来ています。
第一の課題は、権限情報の分散です。Google Workspace・Microsoft 365・Slack・Salesforce・kintone・各種業務SaaSと、それぞれのサービスが独自の管理画面でアカウント・権限を管理しています。20種類のSaaSを導入している企業では、棚卸し対象の管理画面が20箇所に分散しており、横断的な一覧作成が手作業では困難です。
第二の課題は、フォーマットの不統一です。各SaaSでエクスポートできる情報の項目・形式が異なります。あるサービスはCSV、別のサービスはExcelのみ、エクスポート機能自体がないサービスも存在します。これらをひとつの台帳に統合するだけで、相当な工数が発生します。
第三の課題はシャドーITです。IT部門が把握していないSaaSが社員によって利用されており、棚卸し対象自体が不明なケースがあります。SSO(シングルサインオン)に接続されていないSaaSは特に管理の死角になりやすく、退職者アカウントが残存するリスクが高くなります。
すべてのSaaSで同一頻度の棚卸しを実施することは、特に情シス担当者が少ない環境では現実的ではありません。リスクの高さに応じて実施頻度を分けることで、限られたリソースを有効に活用できます。
財務データ・顧客情報・人事情報を扱うSaaS(ERP・CRM・HRシステム等)と管理者権限保有者については、四半期ごとの棚卸しを推奨します。一般的なコラボレーションツール(チャット・ドキュメント管理等)については半期ごとの実施が最低ラインです。退職者・異動者については、イベント発生のたびにリアルタイムで対応することが求められます。定期棚卸しを待たずに即時対応するプロセスを定めておくことが重要です。
SSOに接続されているSaaSであれば、IdP(IDプロバイダー)側でアカウントを無効化することで、連携する全SaaSへのアクセスを一括停止できます。退職者対応の効率化という観点でも、SSOの活用範囲を広げることは有効な施策です。
SSOに未接続のSaaSは、退職処理の際に個別に管理画面へアクセスしてアカウントを削除する必要があります。未接続SaaSの一覧を作成し、退職処理チェックリストに明記しておくことで、削除漏れを防ぐことができます。ブラウザ拡張機能やSaaS発見ツールを活用することで、IT部門が把握していないシャドーITの検出も可能です。

手作業での棚卸しは、SaaS20種類以上を抱える企業では継続が難しくなります。自動化とツールの活用で棚卸し工数を大幅に削減しながら、記録の精度と頻度を高めることができます。
手作業での棚卸し工数を具体的に試算してみましょう。20種類のSaaSを管理している場合、各サービスの管理画面へのログイン・アカウント一覧エクスポート・従業員マスターとの照合・変更対応・台帳更新という一連の作業を繰り返すと、1回の棚卸しで10〜20時間の工数が発生するケースが珍しくありません。四半期実施では年間40〜80時間を棚卸し作業だけで消費する計算になります。
担当者が少ない情シス部門では、この工数は他の業務を圧迫します。さらに、手作業は確認漏れや記録ミスが起きやすく、精度の面でも課題があります。こうした現実を踏まえると、ツールを活用した自動化の優先度は高くなります。
情シス2〜3名体制の企業が現実的にアクセス権限棚卸しを継続するための方法として、SaaS管理プラットフォームの活用が挙げられます。
以前は、各SaaSの管理画面を個別に開いてアカウント一覧をダウンロードし、Excelで人事マスターと突合して変更箇所を洗い出し、各部門に確認依頼を送って回答を待ち、台帳に転記するという一連の作業をすべて手作業で行っていました。ジョーシスのプラットフォームを活用することで、Google Workspace・Microsoft 365・Slackなど複数種類のSaaSのアカウント情報・権限情報をAPI連携で自動収集し、1つの管理画面で横断的に確認できる状態になります。
棚卸しのたびに各SaaSの管理画面を個別に開く必要がなくなり、権限の変更履歴も自動的に記録されます。退職者アカウントの残存を自動検知してアラートを発報する機能により、定期棚卸しを待たずにリアルタイムで対応できる体制が整います。SOX監査やISMS審査の際に必要な証跡も、プラットフォーム内から効率的に出力できます。
自社の規模や既存システム構成に応じて、以下のツール・アプローチも検討できます。
SailPoint Identity Security Cloudはエンタープライズ向けのID管理・アクセス認証自動化ツールです。アクセス権の棚卸し(Access Certification)機能を持ち、ワンクリックでの承認・撤回と棚卸し履歴の自動記録が可能です。大規模な組織でのID管理に適しています。
Microsoft Entra IDは、Microsoft 365を全社導入している組織でのアクセス権管理に有効です。Azure ADと連携する形でユーザーのアクセス権レビュー機能を提供しており、M365エコシステム内での統合管理を得意とします。
Okta Workflowsはプロビジョニング・デプロビジョニングの自動化に強みを持ちます。入社・異動・退職に応じたアカウントのライフサイクル管理を自動化し、棚卸し頻度自体を下げることで運用負荷を軽減するアプローチです。
.jpg)
参考: SailPoint Identity Security Cloud(公式)
棚卸しの実施だけでなく「実施した証拠を正しく残すこと」が、内部統制・外部審査における要件です。監査法人やISMS審査員が何を確認するかを把握したうえで、記録体制を整えましょう。
J-SOX評価においてアクセス管理の審査で確認される証跡は、主に4点あります。
棚卸しの実施記録として、実施日・対象システム・確認者の記録が必要です。次に各アカウントの棚卸し結果として、継続・変更・削除のいずれの判定を下し、それに対して誰が承認したかの記録が求められます。IT部門責任者だけでなくユーザー部門責任者の承認記録も必要な点がポイントです。変更・削除を実施した場合の対応記録として、いつ・誰が・何をしたかの実施ログも保管する必要があります。
監査法人が特に注目するのは、アカウント管理台帳と実際のシステム上の権限情報の整合性です。台帳上は「削除済み」になっているのに実際のシステムではアカウントが残存しているような不一致は、統制の有効性を否定する根拠になります。
ISMSのアクセス制御に関する管理策A.9では、アクセス権限の棚卸しに直接関連する複数の要求事項が設けられています。
A.9.2「ユーザーアクセスの管理」では、アクセス権の付与・変更・削除の手順を整備することが求められます。A.9.2.5「ユーザーアクセス権のレビュー」では、定期的な棚卸しの実施が明示的に要求されており、棚卸し実施の証拠書類が審査対象です。A.9.2.6「アクセス権の削除または調整」では、退職・異動時の即時対応が求められ、対応した記録の保管が必要です。
ISMS審査では「定義した手順どおりに運用できているか」が確認されます。棚卸しの手順を文書化し、その手順に従って実施した記録を残すことが審査通過の条件となります。
J-SOXに関する内部統制評価書類の保存期間は7年間が基準とされており、棚卸し記録もこれに準拠した保管が推奨されます。ISMSについては、次回審査までに提示できる状態を維持すること(最低1年間)が求められます。
棚卸し記録はアカウント管理台帳に統合して一元管理することが、保管と提示の両面で効率的です。台帳のバックアップと変更履歴の保存も確認しておきましょう。
.jpg)
参考: ISO/IEC 27001 ISMS管理策A.9(JISC)
複数SaaSにまたがるアクセス権限棚卸しを情シス2〜3名体制で継続的に運用するためのプラットフォームとして、ジョーシスのプラットフォームが有効です。分散した権限管理を一元化することで、棚卸しの精度と頻度を同時に向上させることができます。
ジョーシスのプラットフォームは、API連携によってGoogle Workspace・Microsoft 365・Slackなど複数種類のSaaSとリアルタイムで連携します。各SaaSのアカウント情報・権限情報を自動収集し、従業員ごとの「全SaaSを横断した権限一覧」を1つの画面で確認できます。棚卸し作業の起点となる「誰がどのサービスに何の権限を持っているか」の情報を、個別の管理画面を開かずに把握できるため、棚卸し開始までの準備工数が大幅に削減されます。
以前は20種類のSaaSのアカウントリストを個別にダウンロードして突合するだけで半日以上かかっていた状態から、ジョーシスの管理画面を開くだけで全SaaSの権限状態を一覧確認できる状態に変わります。退職者アカウントの残存を自動で検知するアラート機能により、定期棚卸しを待たずに問題を発見・対処できる体制が整います。
棚卸し実施後の証跡保存も、プラットフォーム内で管理できます。SOX監査やISMS審査の際に「誰がいつどのSaaSにアクセスし、何の権限を持っていたか」の履歴を効率的に出力でき、監査対応の工数削減にもつながります。情シス担当者が本来注力すべきセキュリティポリシーの改善や内部統制強化に、より多くの時間を充てられるようになります。
アクセス権限の棚卸しは、情報漏洩防止・内部不正抑止・J-SOX/ISMS対応という3つの目的にに対して有効な「発見的統制」です。SaaS導入数が増加した現在、その重要性はオンプレミス時代と比べてさらに高まっています。
棚卸し管理において特に押さえておきたいのは以下の点です。
まず着手すべきアクションとして、自社で利用している全SaaSのアカウント一覧化、退職者・異動者アカウントの残存確認、アカウント管理台帳の整備の3点から始めることをお勧めします。ジョーシスのプラットフォームを活用することで、複数SaaSにまたがるアクセス権限の棚卸しを効率的に実施し、監査対応に必要な証跡の整備も同時に進めることができます。
複数SaaSのアクセス権限を一元管理・棚卸しする具体的な方法は、ジョーシスの無料デモでご確認いただけます。
本記事は2026年4月時点の情報をもとに作成しています。各規制・基準の詳細は最新の公式ドキュメントをご確認ください。
Sign-up for a 14-day free trial and transform your IT operations.
