アカウント棚卸のやり方｜監査を通す業務プロセスと証跡の残し方【実践手順書】

「アカウント棚卸を実施してください」と監査人に言われて、何から始めればいいかわからなくなった経験はないだろうか。

アカウント棚卸とは、会社が使っているシステムの「誰がどんな権限でアクセスできるか」を定期的に確認・整理する作業だ。

「棚卸」という言葉は聞いたことがあっても、具体的に何をどう記録すればいいか、どこまでやれば監査人が納得するかわからない——というケースは非常に多い。

この記事では、監査に通るアカウント棚卸の進め方を、Excelの具体的な項目から体制の設計まで含めて解説する。

アカウント棚卸とは何か

アカウント棚卸とは、会社が使っているシステムの「誰がどんな権限でアクセスできるか」を、定期的に確認・整理する作業だ。

IT全般統制のアクセス管理カテゴリに含まれ、監査では必ずと言っていいほど実施及び証跡の提出を求められる。

なぜ棚卸が必要か

アカウント棚卸が必要な理由は、放置されたアカウントなどによる不正アクセスを防止し、システムの開発及び運用リスクを減らすためにある。
放置されたアカウントは、不正アクセスや情報漏洩のリスクになる。それを防止するために棚卸を行う。

いわば、入退社・異動・兼務などを行ってもIDが適切な状態をキープするのが棚卸の目的だ。

また、棚卸はIT全般統制における「最小権限の原則」を維持するための仕組みでもある。業務に不要な権限を持つアカウントが放置されると、意図しないデータへのアクセスや改ざんリスクが生まれる。棚卸はこのリスクを定期的にリセットする機会だ。

棚卸のスコープ：どのシステムを対象にするか

まず対象システムのリストを作ることから始めよう。そのためにはまず「システム一覧」を作成し、現在会社で利用しているシステムを洗い出す。ベンチャーの場合「現場が勝手に登録してました」「個人アカウントでシステム登録してました」というケースも珍しくないため、まず棚卸の前提となるシステム把握が必要になる。

対象とするシステムを洗い出したら、棚卸を行うべきシステムを絞り込む。例えば、以下のシステムなどは棚卸の対象になりやすいだろう。

システムの例	選択の観点
会計システム（freee/弥生/勘定奉行など）、ERPシステム	財務諸表に直結するデータを扱う
売上処理・受発注など会計に直接連携するシステム	会計データの上流にあたる
AWS/GCP/Azureなどのクラウドインフラ（IaaS）	会計・業務システムの基盤になっている
給与システム、人事システム	個人情報・給与データを扱う
kintone、Salesforceなど業務システム	売上・仕入などの業務データを扱う
Google Workspace / Microsoft 365	情報資産全般へのアクセス管理

すべてを一度にやろうとしないこと。まず「財務諸表に影響するシステム」から始めて、翌年以降にスコープを広げるのが現実的だ。

Excel必須7項目

アカウント棚卸のExcelには、一般的に以下のような項目を盛り込むことが多い。

#	項目名	記載内容	必須理由
1	ユーザーID	システム上のログインID	識別のため
2	氏名	フルネーム（英語表記でも可）	在籍確認のため
3	所属・役職	部署・雇用形態（正社員/業委/派遣）	権限の妥当性確認のため
4	権限レベル	管理者/一般ユーザー/閲覧のみ等	最小権限原則の確認のため
5	在籍ステータス	在籍中/退職済/休職中/契約終了	削除対象の特定のため
6	確認者・確認日	誰がいつ確認したか	監査証跡のため（最重要）
7	対応状況	対応不要/削除済/権限変更済	棚卸結果の記録のため

所属・役職や権限レベルを確認する際は、組織図や社員リストとの突合を忘れないこと。システム上の情報が古いまま放置されているケースは多い。棚卸は「人事情報と権限情報の照合作業」でもある。

確認者・確認日欄は必ず埋めること。何かしらの形で「誰がいつ確認したか」を記録として残しておけばよい。

また、アカウント棚卸のテンプレートファイルは以下からDL可能であるため、興味のある方は参考にするとよい。

資料Dlはこちら

棚卸の進め方：5ステップ

進め方は以下の5ステップからなる。

ステップ1：システムからユーザーリストを書き出す

管理者権限でシステムにログインし、全ユーザーのリストをエクスポートする。多くのシステムはCSVエクスポートができる。エクスポートできないシステムは、管理画面のスクリーンショットを証跡として残す。

ステップ2：人事データと突き合わせる

エクスポートしたユーザーリストと、人事システムの在籍者リストを照合する。確認するポイントは3つだ。

退職日をすぎているアカウントは即削除対象
外部委託・派遣は契約終了日と照合する
長期休職者・育休中の権限は一時停止が望ましいか確認する

ステップ3：権限レベルの妥当性を確認する

各ユーザーの権限レベルが「その人の業務に本当に必要か」を確認する。管理者権限を持つ人数は最小限か、異動後も旧部署の権限が残っていないか、閲覧で十分な業務なのに編集権限を持っていないか——この3点が確認ポイントだ。

この確認は情シスだけで判断するのではなく、各システムのオーナー（業務責任者）に確認を依頼するのが正しい進め方だ。

ステップ4：対応が必要なアカウントを処理する

確認が終わったら、退職者や契約終了した外部委託のアカウントを削除し、権限が業務と合っていないユーザーは適切に変更する。対応した内容と日付は記録として残しておくこと。

ステップ5：結果を記録し、承認を得る

棚卸が完了したら、Excelの確認者・確認日欄を埋め、責任者の承認を得る。承認のパターンはExcelへのサイン・押印、「棚卸完了・承認」のメール保存、ワークフローシステムでの承認フロー——いずれかで対応できる。Googleスプレッドシートを使っている場合は、コメント機能や承認ワークフローのアドオンを活用すると記録が自動で残るため使いやすい。

棚卸を機能させる体制設計

証跡として何かを残すことも大事だが、それ以上に「この棚卸が機能する体制になっているか」が重要である。そのための体制として、以下の要素を含めるのが望ましい。

誰がやるか（責任の所在）
情シスは「システムからリストを出す役割」だ。権限が業務に適切かどうかの判断は、各システムの業務責任者（経理部長・部門マネージャーなど）が担う。情シスが一元管理するか各部門に責任を持たせるかは組織によって異なるが、どちらであれ「誰が責任者か」を決めておくことが先決だ。

いつやるか（頻度と起動条件）
年1回の定期棚卸を基本とし、退職・異動・外部委託終了のタイミングでリアルタイムに対応する二本柱が理想だ。定期棚卸だけでは、退職から次の棚卸まで数ヶ月間アカウントが残り続けるリスクがある。

例外時に誰が動くか（エスカレーション設計）
人事と情シスの間で「退職・異動情報の共有フロー」が決まっていないと、業委・派遣のアカウントは放置されやすい。このフローを作ることが、棚卸の品質を上げる最短経路だ。

ぶっちゃけ、よく見る失敗パターン

現場での経験から言うと、「そもそも棚卸をやっていない」というパターンが非常に多い。特にスタートアップは外部委託・フリーランスのアカウントが残りやすい。なぜなら、正社員の退職はHRフローで処理されるが、業委・派遣は契約終了のタイミングが人事と情シスで共有されていないケースが多いためである。
また、GitHubやAWSなどは、ソースコードの漏洩や本番環境へのアクセスを防止するために、契約終了後にただちに削除する習慣をつけることが望ましい。

また、情シスだけでアクセスコントロールを完結させようとするのは現実的には困難なケースが多い。例えば、財務システムの権限が「その業務に適切かどうか」は、財務・経理の責任者でないと判断できないなど、現場にしか判断できない権限管理も多いからである。

情シスと業務部門がどう役割を分担するかを最初に設計しておかないと、棚卸は形骸化しやすい。