【IT統制】IDの発行・削除と特権IDは、どう申請し記録に残す？ ‣ はてなベース株式会社

IDは、人事の入社・異動・退職の連絡を起点に配属先の責任者が申請し、申請者とは別の人が承認してから設定します。退職者のIDは最終出社日までに止め、退職日と止めた日の両方を台帳に残します。管理者権限を持つ特権IDは、持つ人を絞り、日々の作業用のIDと分け、共有しません。申請日・承認者・実施日・実施者を1件1行で残すID管理台帳が、監査での証拠になります。
この記事の要約

架空のA社は社員70人、経理3人の会社で、工務店向けに建材を卸しています。会計はfreee会計のアドバンスプランで、請求書の受け取りと経費精算はバクラクで回していました。上場準備に入った春、監査法人から「IDの申請と承認の記録を見せてください」と言われました。ところが、招待も削除も情シスを兼ねる管理部長がその場で済ませていて、記録がありませんでした。IT内部統制を担当する内田さんは、経理3年目の世戸田さんに、経理が使うSaaSのIDを洗い出すよう頼みました。

「IDって、入社したら招待して、辞めたら消すだけですよね。記録まで要るんですか」。世戸田さんの素朴な疑問に、内田さんもすぐには答えられませんでした。そこで2人は、経理と内部統制に詳しい外部の専門家の銭形さんに相談しました。会社も人物も、すべて架空です。

申請は人事の連絡から始め、申請者とは別の人が承認する

銭形さんが最初に決めるよう勧めたのは、誰を承認者にするかでした。承認者は申請者と別の人にし、その人選はCFO・経理責任者が決めます。

経済産業省が2024年12月25日に公表した、以下の追補版が参考になります。追補版は、アクセス管理の統制目標の例に「担当者の登録及び登録削除のための手順が定められ、承認されていること」を挙げています。統制の例に並ぶのも、アカウントの「申請、設定、発行、一時停止、廃止に関する手続」です。

では、なぜ申請と承認を分けるのか。同じ節で追補版は「システムとデータヘのアクセス権の申請と承認に関して、職務分離がなされている」を統制の例とし、評価の手続として「同一人物が両方の行為を実施していないことを確かめる」と書いています。

申請の起点は、人事や総務からの入社・異動・退職の連絡です。というのも、起点が人事なら、申請の漏れを人事の名簿と突き合わせて見つけられるからです。具体的には、配属先の責任者が本人の使うシステムと権限を申請します。そして管理部長など別の人が、その権限が職務に合うかを見て承認します。

異動で大事なのは、前の部署の権限を外してから新しい権限を付ける順番です。たとえば、営業で部下の経費を承認していた人が経理に移り、その権限が残ったとします。すると、自分が支払いを担当する経費を、自分で承認できてしまうのです。

freee会計で気をつけたいのは、招待できる人の範囲です。2026年10月時点の公式ヘルプによると、メンバーの招待と権限の変更は「管理者」だけでなく、経理担当向けの「一般（経理）」の権限セットでもできます。この権限で管理者は招待できません。それでも、経理担当は台帳を通さずに人を招待できます。

内田さんと世戸田さんが比べた手は2つでした。1つは、招待は管理者だけが行うと決め、月次の確認で台帳に無い招待を探す方法です。もう1つは、カスタム権限で招待の権限を付けない権限セットを作る方法でした。ただし、2026年4月時点のヘルプでは、法人の新プランでカスタム権限を使えるのはスタンダード以上です。

退職者のIDは、退職日に止めれば足りる？

退職は、人事の連絡から削除まで5つの手順で進める。最終出社日にログインを止め、同じ日に台帳に書く

足りないわけではありません。それでも銭形さんが勧めたのは、退職日ではなく最終出社日に止めることでした。経理責任者が前もって決めておくのは、この期限です。

離職した人のアクセス権は、すぐに外すのが基本です。追補版も、担当者が離職した場合に「直ちにアクセス権が解除されていること」を統制目標の例に挙げています。評価の手続の例では、退職者のサンプルを抜き出して「退職後、即座にアクセス権が削除されていることを確かめる」としています。

ずれが起きやすいのは、有給休暇の消化です。たとえば、最終出社日が6月30日で、退職日が7月15日だとします。退職日の翌日に止めると、最終出社日からの2週間は、会社に来ない本人がログインできてしまいます。

だから、最終出社日にログインを止め、台帳の備考に退職日を書いておきます。そうすれば、監査人に2つの日付の関係を説明できるはずです。

止める前には、案件の引き継ぎが要ります。freee会計でメンバーを削除すると、その人の差し戻し中の経費精算や支払依頼などのワークフローは操作できなくなり、下書きもほかのメンバーから見えなくなるからです。削除できるのは管理者だけで、事業所を作成したメンバーは削除できません。そのため、退職者が作成者なら、先に作成者を付け替えます。バクラクでも、本人の申請中の案件と、本人が入っている承認経路を最終出社日までに見直しておきましょう。

止めることと消すことも、別の話です。2026年10月時点のGoogle Workspaceのヘルプによると、ユーザーを停止してもアクセスが止まるだけで、データは残り、料金もかかり続けます。一方、削除は組織を離れる人にだけ行い、その前にメールやファイルを他の人へ移すよう案内されています。あわせて、台帳の実施日には止めた日を、備考には削除した日を書きます。

実は世戸田さんも、Googleのアカウントさえ止めれば全部止まると思い込んでいました。しかし、でつないでいても、に対応していないSaaSにはIDが残ります。でも同じです。さらに、freee会計のSAMLログインは有料のオプションで、2026年7月時点のヘルプではメンバーごとの設定でした。有効にしていない人は、パスワードで入れてしまいます。退職のときは、SaaSごとに止めるしかありません。

特権IDは持つ人を絞り、日々の作業用のIDと分ける

CFOが判断に関わるのは、管理者権限を誰に持たせるかと、管理者が1人のときの確かめ方です。

この記事では、管理者権限を持つIDを特権IDと呼びます。freee会計なら「管理者」がそれに当たり、メンバーの削除やセキュリティの管理など、ほかの権限ではできない操作ができます。日本公認会計士協会ののQ41の言葉では、特権IDは「全てのマスター情報、パラメータ設定値の変更や会計データの作成、変更、削除及びそれらの権限の設定等が可能な、操作に制限を受けない特別なＩＤ」です。たとえるなら、ビルのどの部屋でも開けられるマスターキーでしょう。

「管理者は多いほうが安心じゃないですか」。世戸田さんはそう尋ねましたが、銭形さんの答えは逆でした。追補版は、特権IDの付与を「担当者や利用期間を限定し、そのIDに対する業務にのみ利用していること」を統制目標の例にしています。統制の例も、運用基準を置くこと、付与を「最小限にとどめていること」、不要なら「すぐに特権を停止する」ことです。ただ、何人までという決まりはありません。

Q41が例示する内部統制のうち、SaaSに当てはめやすいのは次の3つです。

特権IDと通常の操作に使うIDを区別し、特権IDを持つ人も日常の処理は通常のIDで行う
特権IDで行った操作の内容を文書にし、利用部門の管理者の承認を受ける
ログの取得機能を使い、事後にモニタリングする

共有IDを作らない理由は、誰が操作したかが分からなくなるからです。Q41も、特権IDが共有されていると「誰が使用して会計データを修正したかを特定することが困難」になるリスクを挙げています。

とはいえ、管理者が1人しかいない会社では、その1人が設定も承認もできてしまいます。監査基準報告書315は、A145項で、従業員の少ない複雑でない企業では職務の分離が現実的でない場合があると書いています。その場合に経営者が代替的な内部統制を整備することがある、とするのが付録3です。

そこでA社は、CFOを務める取締役に予備の管理者IDを持たせ、日常の作業には使わないことにしました。取締役は月に1回、台帳と各SaaSのメンバー一覧を突き合わせ、管理部長が行った招待・削除・権限の変更を確かめます。予備の管理者IDを使ったときは、台帳に行を立てて代表取締役に報告する決まりです。さらに、予備の管理者がいれば、管理部長が不在でも退職者のIDを止められます。

freee会計では、月締め・年度締めや、指定した期間の会計データの一括削除も管理者だけの操作です。経費精算もfreee会計なら、管理者は承認者でなくても代理で承認できます。こうした操作がいつでもできてしまうので、日常の処理は通常のIDで行います。設定を管理者が変えたときの記録の残し方は、SaaSの設定変更を記録に残す方法の記事で扱いました。

正直なところ、悩ましいのはログです。事後に確かめられる範囲が、プランで変わるからです。2026年9月時点のプラン別の機能表では、freee会計の権限変更の履歴とイベントログは、エンタープライズプランの機能でした。ログイン履歴はほかのプランでも見られますが、最新20件だけです。アドバンスのA社では使えないため、台帳と、月次の確認で撮ったメンバー一覧の画面の控えが記録の中心になりました。

また、Google Workspaceの管理者も特権IDです。2026年10月時点のヘルプで、Googleは特権管理者を複数置き、アカウントを共有せず、日常の業務には特権管理者のアカウントを使わないよう勧めています。

ID管理台帳は、申請・承認・実施の担当と日付を1件1行で残す

台帳の項目は、監査人が何を確かめるかから逆算して決めます。追補版の評価の手続の例は、新規の登録のサンプルについて「責任者がアクセス権を承認したか、承認されたアクセス権が設定されたアクセス権と合致しているか」を確かめる、と書いています。つまり、承認した人、承認した権限、実際に設定した日と人が1行で読めれば、この確認に答えられるわけです。

下の台帳の項目は、編集部が組みました。追補版の付録にあるIT全般統制のは、行の例を省略しているためです。もとにしたのは、追補版第IV章 3.(3)②の統制目標・評価の手続の例と、監査基準報告書315 付録6のアクセス管理のプロセスのうち、権限の付与と変更、退職・異動時の削除、特権アクセスです。行は、世戸田さんが春から書き始めた台帳を想定した架空の例です。

申請日	対象者	種別	対象システムとロール	申請者	承認者	実施日	実施者	備考
2026-03-25	営業担当（4月1日入社）	発行	バクラク経費の申請だけの権限	営業部長	管理部長	2026-04-01	管理部長	入社日に招待した。freee会計は使わない
2026-05-20	経理担当（6月30日最終出社、7月15日退職）	削除	freee会計、バクラク、Google Workspace	経理責任者	管理部長	2026-06-30	管理部長	差し戻し中の申請が無いことを確認。Googleは停止し、データを移して7月31日に削除
2026-06-22	営業の主任（7月1日に経理へ異動）	変更	バクラク営業の承認者の設定を外し、経理の権限を追加。freee会計一般（経理）を追加	経理責任者	管理部長	2026-07-01	管理部長	退職者の後任。前の権限を外してから付けた
2026-06-24	取締役（CFO）	発行（特権）	freee会計管理者、バクラク管理者の権限、Google Workspace 特権管理者	管理部長	代表取締役	2026-07-01	管理部長	予備の管理者。日常の作業には使わない
2026-07-27	顧問の税理士事務所	発行	freee会計アドバイザーとして招待、権限は一般（経理）	経理責任者	管理部長	2026-08-01	管理部長	契約期間を記入。契約が終わる月に事務所へ連携解除を依頼し、外れたことを確かめる
2026-09-01	管理部長	変更（特権）	Google Workspace 日常用のIDから特権管理者を外し、管理用のIDを分ける	取締役（CFO）	代表取締役	2026-09-02	管理部長	月次の確認で、日常用のIDに特権が付いていたのを見つけた
2026-10-09	営業担当（10月16日から休職）	削除	バクラク	営業部長	管理部長	2026-10-15	管理部長	ログインを止めた。復職の連絡を受けたら、発行の申請を出し直す

1件の申請を1行にし、種別は「発行」「変更」「削除」の3つにします。管理者権限の行は種別に「特権」と書き添え、承認者を1段上にします。A社では代表取締役にして、管理部長が自分の権限を自分で承認しないようにしました。もっとも、A社は日常の管理者が管理部長1人なので、承認者と実施者が同じ管理部長になる行が多くなりました。この点は、取締役による月次の確認で補います。実際の台帳には、役職ではなく個人名を書いてください。

顧問の税理士事務所は、freee会計の「アドバイザー」として招待します。招待できるのは管理者だけで、事務所のメンバーは外部メンバーとして登録される仕組みです。2026年1月時点の公式ヘルプによると、顧問契約が終わって事務所の側で「連携解除」を行えば、事務所のメンバーは顧問先のfreee会計から全員削除されます。そのため顧問先は、契約が終わる月に連携解除を依頼し、外れたことをメンバー一覧で確かめます。

付ける権限は、職務に合わせて選びましょう。freeeは、全機能を任せてよい場合は「管理者」を勧めています。管理者を付けるなら、台帳では特権の行です。反対に、経理担当向けの権限を付けた事務所はメンバーを招待できるので、月次の確認で事務所が招待したメンバーがいないかも見ておきます。

承認の証跡は、台帳とは別に残します。承認のメールやチャット、ワークフローの画面を、申請日と対象者が分かる名前で保存し、承認した日は証跡の日付で示してください。もし証跡の日付が実施日より後なら、承認の前に設定を変えたことになります。その場合は、理由を備考に書きます。

監査法人は、台帳のどの行から見る？

銭形さんの見立てでは、最初に聞かれやすいのは退職者の行と管理者の一覧です。監査人は台帳の行を抜き出し、記録どおりに動いたかを確かめます。追補版の評価の手続の例に沿うと、見られるのは次の4つです。

確かめること	準備しておくもの
新規の登録に承認があり、承認どおりに設定されたか	台帳の発行の行と承認の証跡、メンバー一覧
退職者のIDが退職後すぐに止まったか	人事の退職者一覧と台帳の削除の行
異動者の権限が適時に変わったか	人事の異動の一覧と台帳の変更の行
特権IDが正しい職務の人だけにあるか	管理者権限を持つ人の一覧と、その理由

退職者と異動者の確認では、人事の一覧がになります。退職者が全員台帳に載っていることは、台帳だけでは示せません。そのため、人事の一覧と台帳を突き合わせておきます。システムから出した一覧を証拠に使うときの確かめ方は、システム帳票の正確性と網羅性を確かめる方法の記事が参考になるはずです。

管理者が1人の会社にとって、いちばん説明に困るのはここかもしれません。追補版の評価の手続の例は、特権IDで全ての機能を使える場合に、「スプリットパスワードや相互監視等」による別の統制を併用しているかを確かめる、と書いています。

相互監視は特権IDを使うその場で別の人が立ち会う統制なので、月次の確認とは性質が違うのです。それでも銭形さんは、日常の管理者が1人の会社なら、取締役による月次の確認を事後の統制として説明することになる、と考えています。315実務ガイダンス第1号のQ41にも、特権IDの使用状況を適時にモニタリングしていれば、リスクが低減されていると監査人が判断できる場合もある、とあります。最後は、説明として足りるかを監査法人と協議して決めるしかありません。

外部の人のIDも確認の対象です。315実務ガイダンス第1号のQ27は、ソフトの開発会社が保守のためにアクセスできる場合を取り上げています。アクセスが作業のときだけなら、作業後にIDを削除するか無効化していれば、不適切なアクセスは防がれていると考えられます。一方、常にアクセスできるなら、監査人が作業の内容と会社の確認の方法を把握します。Q27はソフトの開発会社の話ですが、銭形さんは顧問の税理士事務所も常にアクセスできる側として扱うよう勧めました。

権限が職務に合っているかを定期的に見直す棚卸は、台帳とは別の統制です。四半期の棚卸の進め方は、権限の棚卸の進め方の記事にまとめました。

A社の話に戻ります。世戸田さんは台帳を作り、春の入社から1件ずつ行を立てていきました。秋には、取締役の月次の確認で見つかった特権の付けすぎも、是正の1行になりました。

「入社したら招待して、辞めたら消すだけ」。世戸田さんが出した答えは、その間に申請と承認を挟み、1件1行で残すことでした。変わったのは、誰が頼み、誰が認め、いつ誰がやったかを、あとから読めるようになったことです。監査法人の「記録を見せてください」にも、台帳と承認の証跡で答えられるようになりました。

SaaSで経理を回しても残るIT統制の全体像は、SaaSで経理を回す会社に残るITGCの記事で扱っています。AIエージェントやAPI連携に使うIDも同じ台帳に載せると漏れにくく、AIに仕訳を起票させるときの扱いはAIエージェントに仕訳を起票させたときの監査対応の記事にまとめました。ID管理台帳のExcelのひな形は、Excel のひな形をダウンロードするからダウンロードできます。