共有アカウントを減らす権限設計｜入社・異動・退任で漏れない台帳の作り方

サービスごとの管理者と目的を一覧にする

サービス名、利用目的、契約主体、主管部署、主管理者、副管理者、利用者、認証方式、外部連携、データの種類を台帳へ記録します。ログインURLは記載しても、パスワード、復旧コード、APIキーは書きません。

主管理者が退任者や個人メールになっている場合は優先度を上げます。契約とデータが法人に属すること、少なくとも二人の適切な管理者が復旧できることを確認します。

個人アカウントを原則にする理由

個人ごとのアカウントなら、操作履歴を追いやすく、退任時に対象者だけを停止できます。権限も閲覧、編集、請求、管理などへ分けられます。共有IDでは、一つの認証情報が漏れた時の影響範囲も大きくなります。

サービスがメンバー招待へ対応しているなら、料金と利用規約を確認したうえで個人アカウントへ移します。無料枠を維持するためだけの共有が、規約違反や復旧困難を招かないかを比較します。

役職名ではなく実際の作業から権限を作る

「営業」「管理者」のような名称だけで権限を決めると、不要な請求情報や顧客データまで見える場合があります。見積を作る、顧客を編集する、データを書き出す、メンバーを招待する、請求方法を変更する、と操作単位で必要性を確認します。

日常作業に管理者権限が不要なら、通常アカウントと管理操作を分けます。権限不足が起きた時の申請先と対応時間を決めておけば、念のため全員を管理者にする必要は減ります。

入社・異動・退任を一つの流れにする

入社時は役割テンプレートから必要なサービスだけを招待し、本人の会社メールで多要素認証を設定します。異動時は追加だけでなく、以前の役割で不要になった権限を外します。

退任時はアカウント停止、共有アカウントの認証情報変更、所有ファイルの移管、連携トークンの失効、復旧連絡先の更新を一覧で行います。最終出社日だけでなく、アクセス停止時刻と実施者を固定します。

外部委託先は案件と期限を付ける

外部協力者を組織全体のグループへ入れず、担当案件や必要なフォルダへ限定します。招待時に終了予定日と社内責任者を台帳へ記録し、契約終了を待たず月次棚卸しで確認します。

一時的な管理権限が必要な場合は、作業内容、開始・終了時刻、実施ログ、解除確認を残します。恒久的な広い権限へ変わっていないかをreadbackします。

月次棚卸しで見る順番

利用記録がないことだけで即時に削除せず、業務依存、法的保存、緊急用途を確認します。変更する場合は対象と影響を限定し、停止後に必要な業務が継続できるか確認します。

• 退任者・契約終了者のアカウント
• 個人メールや不明なドメインの利用者
• 管理者・請求管理者・データ書き出し権限
• 期限を過ぎた外部共有
• 90日以上利用記録がないアカウント
• 所有者が一人しかいない重要データ
• 利用目的が分からない外部連携

最小の権限台帳チェックリスト

• 契約主体と主・副管理者が分かる
• 個人アカウントで利用できるサービスを特定した
• 役割ごとに必要な操作だけを列挙した
• 入社・異動・退任の担当と期限を決めた
• 外部利用者へ案件と終了日を付けた
• 管理者と外部連携を月次で確認する
• 変更後に停止状態と業務継続をreadbackする

三つの場面で過不足を確かめる

経理担当が請求書を確認する場面では、請求情報の閲覧とダウンロードが必要でも、契約変更や利用者削除まで必要とは限りません。広い管理者権限を渡す前に、実際の作業を「見る・作る・承認する・設定を変える」に分け、担当する操作だけを台帳へ記録します。月末だけ必要な権限なら、付与日と終了日も同時に決めます。

制作会社がウェブサイトを更新する場面では、対象サイトの編集権限と公開権限を分けられるか確認します。テスト環境への編集、社内担当者による確認、本番公開という順序にすれば、外部利用者へ全社設定や請求情報を見せずに済む場合があります。契約終了日だけでなく、成果物の引き渡し先と所有者も決めます。

代表者が不在の場面では、緊急連絡、請求継続、データ書き出し、サービス障害への対応が別の管理者で行えるかを試します。副管理者を置くだけでなく、復旧連絡先が個人端末だけになっていないか、二要素認証と復旧情報へ適切に到達できるかを確認します。確認結果そのものをチャットへ貼らず、実施日と可否だけを台帳へ残します。

権限変更は小さく実行して戻り方を残す

変更前に、対象者、対象サービス、現在の役割、変更後の役割、変更理由、実施予定日時を一行で固定します。次に、その人が当日行う業務と自動処理への影響を確認します。特に管理者、API連携、共有メール、請求管理は見た目の利用頻度だけで判断せず、別の担当者やシステムから参照されていないかを調べます。

最初はテスト利用者または影響を限定できる一人で変更し、ログイン、閲覧、編集、承認など必要な操作だけができることと、不要な設定へ到達できないことを確認します。問題があれば元の役割へ戻せるよう、変更前の状態と復旧担当を記録します。大人数の一括変更は、この小さな確認が終わってから同じ手順で行います。

変更後は管理画面上の表示だけで終えず、本人の業務画面と監査ログの両方をreadbackします。削除したつもりの招待、期限切れリンク、別グループ経由の権限が残ることがあるためです。失敗した場合は、誰が困ったかではなく、どの操作ができなかったかを記録すると、権限を再び過大に戻さずに修正できます。

台帳は一行で次の担当者が判断できる形にする

最低限の列は、サービス名、契約主体、利用目的、主管理者、副管理者、利用者またはグループ、付与した役割、付与日、終了日、最終確認日、次回確認日です。個々のパスワードや復旧コードは台帳へ書きません。秘密情報の保管場所は、権限を持つ人だけが分かる参照先として分離します。

たとえば「会計サービス／合同会社LaunchX／月次請求確認／主:経理担当／副:代表者／閲覧担当グループ／請求閲覧／2026-07-22／継続／確認済み／2026-08-22」のように、一行から目的と見直し時期が分かる形にします。役職だけでなく実際の責任を記すと、異動時にも何を引き継ぐべきか判断できます。

月次確認では全項目を書き直さず、終了日超過、管理者不在、用途不明、外部共有、長期未利用などの例外から見ます。例外を直した後に確認日を更新し、保留した項目には理由と次の判断日を置きます。こうすると、台帳が名簿の写しではなく、権限変更を安全に進める作業表になります。

棚卸し担当を交代しても同じ判断ができるよう、例外ごとの確認先を一つ示します。退任は人事記録、外部委託は契約と案件台帳、管理者はサービス画面、長期未利用は監査ログというように、根拠を分けます。画面上の表示と業務担当者の記憶が違う時は、どちらかを推測で採用せず、未確認として影響を限定した調査へ回します。

緊急時の連絡先は担当者名だけでなく、役割、代替担当、確認できる記録を台帳へ結び付けます。休暇中の管理者へ個人連絡を前提にせず、別の管理者がテスト用アカウントで必要な確認画面まで到達できるかを定期的に試します。

この記事の限界

必要な権限管理は、データの機密性、顧客契約、業界規制、各サービスの仕様で異なります。本記事は一般的な運用設計であり、法令遵守や個別システムの安全性を保証しません。重要環境では専門家とベンダーの最新公式文書を確認してください。