.png)
従業員が使うシステムやSaaSが増え続けるなかで、「誰が・どのアカウントを・どんな権限で持っているか」を把握しきれずに悩む情シス担当者は少なくありません。退職者のアカウントが消し忘れられ、監査で指摘を受けて初めて棚卸しの不備に気づくケースもよく耳にします。
こうした状態を防ぐ土台になるのが、ID管理台帳です。本稿では、台帳に載せるべき項目の設計から、Excelでのテンプレート作成手順、日々の運用ルール、そして脱Excelでツールへ移行する判断基準までを、実務でそのまま使える形でご案内します。

ID管理台帳とは、社内で発行されたユーザーIDやアカウントを、利用者・権限・状態とひもづけて一覧化した管理表です。誰がどのシステムにアクセスできるかを一目で追えるようにし、アカウントの発行から削除までを統制する起点になります。
台帳が対象とするのは、人にひもづくアカウントとアクセス権限です。基幹システムのログインID、各種SaaSのユーザーアカウント、メールアドレス、特権IDなどが該当します。物理的な端末そのものではなく、あくまで「利用者と権限の対応関係」を記録する点が特徴です。
台帳では、ひとつのアカウントを「誰が使い」「いつ発行され」「どの権限を持ち」「今どの状態にあるか」という単位で管理します。この粒度をそろえておくことで、後述する棚卸しや監査対応が格段に進めやすくなります。
ID管理台帳と混同されやすいのが、IT資産台帳です。IT資産台帳はPCやサーバー、ソフトウェアライセンスといった「モノ」の在庫と契約を管理するのに対し、ID管理台帳は「人と権限」の対応を管理します。
両者は目的も記載項目も異なるため、無理にひとつの表へ詰め込むと更新が破綻しやすくなります。デバイスやライセンスの管理は資産台帳側に切り出し、相互に参照できるようにしておく運用が現実的です。資産側の設計は関連記事で詳しく整理しています。
関連記事:IT資産台帳 作り方|情シス向け項目設計・運用ルール・自動化の実装ガイド
台帳づくりを後回しにすると、目に見えないリスクが静かに積み上がります。ここでは、なぜ情シスがID管理台帳を整備すべきなのかを、放置した場合に起きる問題から確認します。
台帳がない組織では、退職者のアカウントが削除されないまま残る「野良アカウント」が発生しがちです。放置された認証情報は、不正アクセスや情報持ち出しの入口になり得ます。IPAのガイドラインでも、不要になった利用者IDとアクセス権は速やかに削除すべきだと明記されています。
台帳で利用者の在籍状態とアカウントを結びつけておけば、退職や異動のタイミングで削除漏れを機械的に洗い出せます。誰も使っていないアカウントの発見は、関連記事でも詳しく解説しています。
関連記事:孤立アカウントとは|定義・セキュリティリスク・発見方法・削除手順を解説
上場企業やその準備段階の企業にとって、ID管理台帳は内部統制の重要な証跡になります。J-SOXでは、権限のある人だけが権限の範囲内でアクセスできる状態を維持し、定期的にアクセス権限を見直す運用が求められます。
台帳が整っていれば、監査人から「誰がどの権限を持つか」を問われた際にも即座に提示できます。逆に台帳が曖昧だと、棚卸しの証跡そのものを求められて対応に追われることになります。
関連記事:IT内部統制とは|情シスが知っておくべき基礎知識・J-SOX対応・実践方法を解説
台帳の実効性は、項目設計でほぼ決まります。多すぎれば更新が追いつかず、少なすぎれば棚卸しに使えません。まずは運用に耐える最小限の項目からそろえるのが賢明です。
どの組織でも共通して必要になるのが、利用者と権限を特定するための基本情報です。氏名・社員番号・所属部署・役職に加え、対象システム名、アカウントID、権限区分をそろえます。これらがあれば、「誰が・何に・どこまでアクセスできるか」を一意に追えます。
さらに、発行日・最終更新日・アカウントの状態(有効・停止・削除済み)を加えると、棚卸しの判断材料になります。状態の欄は、後から見た人でも迷わないよう表記を統一しておくことが肝心です。
一般アカウントに加えて、特に注意して管理したいのが特権IDです。サーバーや管理コンソールの管理者権限は、悪用された際の被害が大きいため、利用者・付与理由・棚卸し頻度を分けて記録します。
権限は必要最小限にとどめる「最小権限の原則」に沿って設計すると、台帳の見通しがよくなります。共有アカウントは可能な限り個人単位に分け、多要素認証の有無も欄として持たせておくと、リスクの高いアカウントを一覧で識別できます。
関連記事:特権ID管理とは?不適切な管理に潜むリスクと適切な管理方法を解説
関連記事:最小権限の原則とは|SaaS時代の情シスが実践すべきアクセス制御の考え方
多くの情シスが最初に選ぶのが、Excelでの台帳づくりです。低コストで始められ、カスタマイズも柔軟という利点があります。ここでは、Excelで実用的な台帳を組み立てる手順を順番に見ていきます。
最初に、前章で挙げた項目を列として並べます。氏名・部署・システム名・アカウントID・権限区分・状態・発行日・最終確認日を1行1アカウントで記録できるようにします。1人が複数のシステムを使う場合は、アカウント単位で行を分けると棚卸しがしやすくなります。
権限区分や状態の列はプルダウン(入力規則)で選択式にすると、表記ゆれを防げます。この段階でテンプレートとして保存しておけば、次回以降の運用がぶれません。
テンプレートができたら、現状のアカウントを棚卸しして入力します。人事の在籍者名簿と、各システムの利用者一覧を突き合わせ、実在するアカウントを一件ずつ埋めていきます。この初回の突合で、名簿にない利用者や、退職済みなのに残るアカウントが見つかることも珍しくありません。
有効期限や最終確認日のセルには、条件付き書式で期限超過を色分けする設定を入れておくと、更新漏れに気づきやすくなります。台帳は作って終わりではなく、更新され続けて初めて価値を持つという点を意識して設計しましょう。
関連記事:SaaSアクセス管理とは|権限設計・入退社連動・定期レビューの実践ガイド
台帳は、更新の仕組みとセットで初めて機能します。属人的な更新に頼ると、担当者の異動とともに形骸化してしまいます。ここでは、台帳を生かし続けるための運用ルールを整理します。
もっとも重要なのが、入社・退職・異動のたびに台帳を更新するフローを定めることです。入社時にはアカウント発行と同時に台帳へ登録し、退職時には削除と同時に状態を「削除済み」に更新します。人事イベントを起点にすることで、更新のタイミングが明確になります。
このフローを申請書やワークフローと結びつけておくと、「誰の指示で発行・削除したか」という証跡も残せます。承認の記録は、そのまま監査対応の材料になります。
日々の更新に加えて、半年に一度など定期的な棚卸しを行い、台帳と実態のズレを補正します。全アカウントを対象に、利用実態のない権限や、退職者の残存アカウントがないかを点検します。
棚卸しの結果は、いつ・誰が・何を確認したかまで記録に残します。この積み重ねが、権限の妥当性を説明できる状態をつくります。
情シスの負荷を抑えながら台帳運用を軌道に乗せたい方へ向けて、実務のポイントをまとめた資料をご用意しています。
Excelは手軽な一方で、規模が大きくなると運用が破綻しやすくなります。どの状態になったらツールへ移行すべきか、判断の目安を押さえておきましょう。
Excelの台帳は、手入力に依存するため入力漏れや転記ミスが避けられません。複数人が同時に編集するとバージョンが分岐し、どれが最新かわからなくなることもあります。さらに、実際のシステム側のアカウント状態と台帳が自動では同期しないため、記録と実態が徐々に乖離していきます。
アカウント数が数百を超え、連携するSaaSが数十種類に達すると、手作業での突合は現実的でなくなります。棚卸しのたびに膨大な工数がかかるなら、それが移行を検討する合図です。
移行の判断軸は、アカウント規模・SaaSの種類数・監査要件の3点で考えると整理しやすくなります。アカウントが増え、退職者対応や権限レビューの頻度が上がるほど、自動連携の価値は高まります。IDの一元管理という考え方は、関連記事もあわせて確認すると理解が深まります。
関連記事:アイデンティティ管理とは|SaaS時代に情シスが押さえるべき基本と実装フレームワーク
関連記事:IAMとは?仕組み・IDaaS/IGAとの違い・情シスが押さえる導入ポイント
台帳運用をツール化すると、これまで手作業で埋めていた情報が自動で最新化されます。ここでは、専用プラットフォームに移行した場合に得られる変化を具体的に見ていきます。
従来のExcel運用では、各システムのアカウント状態を担当者が目視で確認し、手で転記していました。ツールを使うと、連携済みのSaaSやシステムからアカウント情報を自動で収集し、常に最新の一覧として保持できます。手入力に頼っていた状態から、実態と台帳が一致する状態へと変わります。
ジョーシスのプラットフォームは、350以上のアプリケーション連携に対応し、アカウントと利用者、権限を横断的に可視化します。国内外1,000社以上に導入され、入退社にともなうアカウントの発行・削除を自動化することで、IT工数を最大50%削減した実績があります。
自動連携により、棚卸しは「システムから吐き出された最新一覧を確認する」作業へと軽くなります。退職者の残存アカウントや、使われていない権限も一覧で検出できるため、削除漏れのリスクを抑えられます。
権限の変更履歴や承認の記録が残ることで、監査時にも証跡をそのまま提示できます。手作業での証跡集めに追われていた状態から、必要なときにすぐ取り出せる状態への転換が期待できます。実際の運用イメージは、デモで確認いただくのが近道です。
ID管理台帳の作成と運用について、情シス担当者からよく寄せられる質問にお答えします。
分けて管理することをおすすめします。ID管理台帳は「人と権限」、IT資産台帳は「端末やライセンスなどのモノ」を扱い、目的も更新のきっかけも異なります。両者を無理に統合すると更新が煩雑になるため、別々に持ち、相互に参照できる形が実務的です。
アカウント数が数百規模を超え、連携SaaSが数十種類に増えるまでが一つの目安です。この規模を超えると手作業での突合や棚卸しに大きな工数がかかり、記録と実態の乖離も起きやすくなります。監査対応の頻度が上がったタイミングも、ツール移行を検討する合図です。
利用者を特定する氏名・部署、対象システム名、アカウントID、権限区分、アカウントの状態が最低限の項目です。加えて発行日と最終確認日を持たせると、棚卸しや削除漏れの点検がしやすくなります。特権IDは通常のアカウントと分けて記録すると安全です。
半年に一度を基本とし、監査要件やリスクの高さに応じて頻度を上げます。日々の入退社・異動にあわせた更新を前提としたうえで、定期棚卸しで台帳と実態のズレを補正する二段構えが効果的です。棚卸しの記録は証跡として残しておきます。
ID管理台帳は、「誰が・どのアカウントを・どんな権限で持つか」を可視化し、退職者アカウントの放置や監査対応の不備を防ぐ土台になります。まずは基本項目をそろえたExcelテンプレートから始め、入退社との連動と定期棚卸しをルール化することが第一歩です。
アカウント数やSaaSの種類が増え、手作業での運用に限界を感じたら、自動連携できるツールへの移行を検討する段階です。台帳を「作る」ことをゴールにせず、更新され続ける仕組みとして育てていくことが、統制の効いたID管理につながります。
Sign-up for a 14-day free trial and transform your IT operations.
