【IT統制】権限の棚卸は、何を・誰が・どの頻度で見ればいいのか——SaaSの利用者IDを四半期で確かめる ‣ はてなベース株式会社

棚卸で確かめるのは「IDが本人のものか」「権限が職責に合っているか」「管理者権限を持つ人が限られているか」の3点です。利用部門の責任者が四半期に1回、台帳と実際の設定を突き合わせて確認し、是正した内容を記録に残します。基準は棚卸の頻度を固定していませんが、四半期が実務の相場です。
この記事の要約

棚卸で確かめる3つの観点——IDの存在・権限の妥当性・管理者権限の限定を、四半期ごとに台帳と突き合わせて記録する

架空のA社（社員60人、経理2人）は、freee会計とバクラク請求書でバックオフィスを回しています。IPO準備で監査法人から「利用者IDと権限の棚卸を始めてください」と言われましたが、何をどのくらいの頻度でやればいいのか分かりません。

棚卸で確かめるのは「IDの存在」「権限の妥当性」「管理者権限の限定」の3点

監基報315の付録6は、アクセス管理プロセスの構成要素として「利用者アクセスレビュー」を挙げています。その内容は「付与している権限に対して随時、利用者アクセス権を再証明又は評価する内部統制」です（監基報315 付録6 2.(1)）。権限の棚卸は、この利用者アクセスレビューに該当します。

付録6はアクセス管理プロセスの構成要素を8つ挙げています（認証、権限の付与、プロビジョニング、デプロビジョニング、特権アクセス、利用者アクセスレビュー、セキュリティの環境設定、物理的アクセス）。この8つのうち、SaaSの権限棚卸で実務的に確かめる点を、編集部の整理として3つに絞ります。

1つ目は、IDの存在です。退職者や異動者のIDが残っていないかを確かめます。付録6は「デプロビジョニング」として「退職又は異動時に利用者のアクセス権を削除する内部統制」を挙げています。退職者のIDが残っていれば、元社員がシステムにログインできる状態が続いていることになります。棚卸をしてみると、退職から3か月後も総務担当のfreeeアカウントが有効なまま残っていた、というケースが起きやすいです。

2つ目は、権限の妥当性です。各利用者の権限が現在の職責に合っているかを確かめます。付録6は「権限の付与」として「利用者が職責に必要な情報にアクセスし、それ以外の情報にはアクセスできないようにする内部統制」を定義し、「これにより、適切な職務分離が促進される」としています。freee会計には6種類のデフォルト権限セット（管理者・一般（経理）・取引登録のみ・閲覧のみ・一般（経理以外）・申請・承認）があります（2026年10月時点の公式ヘルプ）。経理の実務担当者が「管理者」権限を持っていれば、仕訳の登録と承認経路の変更の両方ができる状態です。棚卸でこれが見つかったら、その担当者の権限を「一般（経理）」に変更し、管理者権限を経理責任者だけに限定します。

3つ目は、管理者権限の限定です。管理者権限を持つ利用者が必要最小限に絞られているかを確かめます。付録6は「特権アクセス」として、管理者権限の管理をアクセス管理プロセスの構成要素に挙げています。315実務ガイダンス第1号のQ41（監査人向けのリスク評価のQ&A）でも、整備すべき内部統制の例として「必要最小限の者のみに付与されるべき」「通常の操作に使用するIDと分けて使う」ことを挙げています。バクラクでも、共通管理の「管理者」は他のメンバーの権限を変更できるため、同じ考え方で棚卸します。バクラクの共通管理には「管理者」「ユーザー管理者」「経理担当」「一般」の4段階があり（2026年10月時点の公式情報）、業務内容に応じて必要最小限のロールを割り当てているかを確かめます。

棚卸は利用部門の責任者が行い、情シスや内部監査が確かめる

棚卸を「誰が行い、誰が承認するか」を決めておかないと、実施そのものが有名無実になり、確認した内容も是正の判断も記録に残りません。

実施基準は、ITGCの整備と評価を経営者の責任としています。具体的には「内外からのアクセス管理などシステムの安全性の確保」をITGCの例として挙げています（実施基準 I.2(6)②ロa）。実務では、経営者がこの責任を各システムの利用部門の責任者に委ねます。freee会計であれば経理責任者、バクラク請求書であれば経理や総務の責任者が棚卸の実施者になるのが一般的です。

ここで大事なのは、棚卸を行う人と、自分の権限が確認対象になる人が同じにならないことです。経理責任者が自分自身の管理者権限を「問題なし」と判断するだけでは、統制として機能しません。棚卸の結果を承認する人は、実施者より上位の管理者か、別の部門の責任者にします。

A社の例では、経理責任者が棚卸台帳を作成し、管理部長が内容を確認して承認する形が考えられます。管理部長は情シスを兼務しているため、自分のIDの権限を別の取締役に確認・承認してもらうなど、自己承認にならない工夫が必要です。

役割	担当の例	やること
実施者	経理責任者	台帳と実際の設定を突き合わせ、差異を洗い出す
承認者	管理部長	差異の是正内容を確認し、承認する
確認者	内部監査（または取締役）	棚卸が手順どおり行われたかを独立して確かめる

内部監査が独立して棚卸の記録を確かめることで、経営者評価の証拠にもなります。社員数が少なく内部監査の専任がいない会社では、監査役が確認者を兼ねる場合もあります。IDと権限の管理の全体像はSaaSで経理を回す会社に残るITGCの記事で扱っていますが、棚卸の体制でとくにつまずきやすいのは「管理者権限を持つ人が自分で棚卸をして、自分で承認する」状態です。SaaSの利用者が少ない会社ほど、1人が複数の役割を兼ねるため、意識して体制を組む必要があります。

四半期ごとの棚卸が実務の相場だが、基準は頻度を固定していない

実施基準も監基報315も、棚卸の頻度を具体的に定めていません。実施基準はアクセス管理をITGCの例に挙げていますが、見直しの間隔には触れておらず、監基報315の付録6も「随時」としか書いていません。

実務では、四半期に1回の棚卸が一般的です。理由は3つあります。

入退社や異動は四半期の区切りに集中しやすく、退職者IDの放置が発覚しやすい
SOC1レポートの対象期間は6か月や1年が多く、利用会社の宿題も四半期を区切りに管理しやすい。SOC1レポートの読み方の記事で扱ったSOC1レポートの読み方では、利用会社が整備すべき宿題の中にIDと権限の見直しが含まれます
監査法人のショートレビューや期末の監査で「四半期で棚卸をしていますか」と聞かれることが多い

A社の年間スケジュールの例を示します。3月決算であれば、6月・9月・12月・3月の四半期末に棚卸を行います。1回あたりの作業量は、SaaSが3〜4つ、利用者が20〜30人の規模であれば、台帳の突き合わせに1〜2時間、差異の是正と承認に半日ほどです。最初の棚卸は台帳の作成から始めるため、倍の時間を見ておきます。

棚卸のほかに、年次で行う作業もあります。SOC1レポートの入手と確認（年1回）、SaaSの料金プランの見直し（ログの取得に必要なプランかどうかの確認）、IPO準備のロードマップの中でのIT統制の進捗確認です。年間の計画に棚卸と年次作業の両方を載せておくと、抜け漏れを防げます。IPO準備のJ-SOXロードマップの記事で整理したIPO準備のロードマップでは、直前々期からIDの申請・削除と四半期の棚卸を動かし始めることを勧めています。

ただし、管理者権限の変更やAPI連携用IDの追加など、影響の大きい変更は四半期を待たずに都度確認します。315実務ガイダンス第1号のQ41（監査人向け）では、特権IDについて通常のIDの管理に加えて追加の統制を例示しています。管理者権限を付与するときは、そのつど申請と承認を行います。四半期の棚卸では、申請どおりに設定されているかを確かめます。

なお、監基報330第13項(2)に「少なくとも３年に１回」という規定がありますが、これは財務諸表監査で監査人が内部統制に依拠する場合の規定であり、経営者が行う棚卸の頻度を定めるものではありません。

棚卸の記録は「いつ・誰が・何を確かめ・何を是正したか」を残す

棚卸台帳の記録項目。システム名・利用者名・権限ロール・変更点・確認結果・是正内容を1行にまとめる

棚卸は、やったことを記録に残さなければ監査の証拠になりません。記録に含めるのは次の4つです。

いつ: 棚卸の実施日と承認日
誰が: 実施者と承認者の氏名
何を確かめたか: システムごと・利用者ごとのIDの存在、権限ロール、管理者権限の有無
何を是正したか: 退職者IDの削除、権限の変更、管理者権限の移管など、差異と対応

台帳の形式に決まりはありませんが、「システム名・利用者名・権限ロール・前回からの変更点・確認結果・是正内容」を1行にまとめた表が使いやすいです。スプレッドシートでもExcelでも構いません。大事なのは、確認した結果と是正の内容が、あとから追える形で残っていることです。

棚卸の手順は3ステップです。まず、SaaSのメンバー一覧をエクスポートまたはキャプチャし、台帳の「現在の状態」列を更新します。次に、前回の台帳と比較して、追加・削除・変更のあったIDを洗い出します。最後に、差異があるIDについて「この権限が必要か」を利用部門の責任者が判断し、是正が必要なものは実行してから承認者に回します。

freee会計では、メンバー一覧の画面から利用者のIDと権限セットを確認できます（2026年10月時点の公式ヘルプ）。カスタム権限を使っている場合は、権限の名前だけでなく、有効にしている操作の範囲も台帳に記録しておくと、棚卸のときに設定内容を調べ直す手間が減ります（2026年10月時点の公式ヘルプ）。法人のエンタープライズプランであればイベントログ（操作ログ）を取得でき、権限変更の履歴も追えます（2026年10月時点の公式ヘルプ）。プランが対応していなければ、棚卸のたびにメンバー一覧の画面をキャプチャし、前回のキャプチャと見比べる方法で代替します。

API連携用のIDやAPIキーも棚卸の対象です。退職者が発行したAPIキーが使われ続けていないかを確かめるため、連携先のシステムと用途を台帳に載せておきます。連携を許可したメンバーが退職した場合は、そのトークンやキーが失効・削除されているかを確かめます。バクラクのAPIキーは有効期限と読み書きの範囲を設定できるため、台帳にはキーの用途、有効期限、権限範囲、発行者を記録します。

読み違えやすいポイント

ポイント	正しい扱い
SSOを入れれば棚卸は不要になる	SSOは認証（ログインの本人確認）をまとめる仕組みで、各SaaSの権限ロールの管理とは別です。SSOで退職者のログインを一括で止められても、SaaS側にIDと権限が残っていれば棚卸の対象です。権限の妥当性はサービスごとに確かめます
API連携用のIDは棚卸の対象外	API連携用のIDやAPIキーもアクセス権の一種です。とくにAPI連携でfreeeに仕訳を起票している場合、連携ユーザーの権限が承認経路に影響することがあります。AIエージェントに仕訳を起票させたときの監査対応の記事で扱ったとおりです