経営と仕事のこれから / 第一稿

会社のアカウント管理を整える実務ガイド

棚卸しから、共有の整理・担当交代・復旧確認まで

第一稿著者: 加納智之

会社のアカウント管理をどこから整えるか。小さな会社の架空事例と6点の図を使い、管理台帳、共有の例外、移行、担当交代、復旧確認を順に説明します。

複数の仕事席と個人別の鍵が中央の管理棚につながり、別の場所に予備の鍵が保管されたオフィスの概念図。

会社のパスワードを管理する必要は分かっていても、何から手を付ければよいのかは迷います。保管ツールを契約しても、管理者が一人しかいない、退職者の利用を止めたか分からない、端末が壊れると復旧手順さえ読めない、といった問題は残ります。

このガイドは、専任の情報システム担当者がいない小さな会社の経営者や管理担当者に向けたものです。誰が使えるか、不要になった利用を誰が止めるか、入れなくなったときにどう仕事を再開するかを、順に整えていきます。

1Passwordのような組織向けパスワード管理ツールを使う場合も、考える順序は同じです。ただし本稿は、特定製品の設定画面を実機で検証した操作マニュアルではありません。実際の設定は、契約プランと各サービスの公式資料で確認してください。

以下に登場する「青葉設備」は、従業員18人の設備工事会社という設定の架空事例です。実在企業への支援実績や、導入効果を示すものではありません。

最初に用意する三つのもの

最初から完璧な台帳を作る必要はありません。次の三つを用意し、重要なサービスから埋めていきます。

用意するもの 記録する内容 役割
管理台帳 サービス、管理責任者、利用者、情報の保管場所 会社として何を管理しているかを把握する
作業チェックリスト 確認した項目、結果、担当者、確認日 移行や引き継ぎの抜けを減らす
例外の記録 共有を残す理由、暫定措置、責任者、見直し日 一時的な対応が放置されることを防ぐ

パスワード、認証コードを生成する秘密情報、リカバリーコードの値は、台帳やチェックリストには書きません。 安全な保管先へ置き、台帳には保管場所と管理責任者を記録します。台帳自体も、閲覧できる人を限定します。

重要なサービスの調査、管理方法の決定、一業務での試行、対象を広げた移行、担当交代と復旧の練習、台帳更新の6段階。試行で未確認の点があれば解消して再確認する。
図1 アカウント管理を整える6つの段階。期限だけで進めず、利用・停止・復旧の確認を次へ進む条件にします。
PNGを拡大 / SVGを保存

1.止まると困るサービスから調べる

最初の対象は、メール、ドメイン、請求・会計、受発注、顧客管理、会社のSNSなどです。利用数の多さよりも、止まったときに仕事へ及ぼす影響で順番を決めます。

管理台帳には、次の項目を設けます。「不明」と書いて構いませんが、誰が調べるかを一緒に決めます。

項目 記入する内容
サービス名・用途 何の仕事で使っているか
止まったときの影響 発注できない、請求できないなど
アカウントの種類 個人別、共有、システム連携用
管理責任者・代行者 判断する人と、不在時に対応する人
利用者・権限 誰が何をできるか
認証方法 パスワード、多要素認証、パスキーなど
保管場所 保管庫の名前など。秘密情報の値は書かない
復旧情報の所在 復旧に必要な情報の場所と取り出せる人
最終確認日 いつ、誰が確認したか
未確認事項 分からないこと、調べる担当者、確認期限
管理台帳には用途、責任者、利用者、認証方法、保管場所、確認日を記録する。パスワードや復旧コードの値は安全な保管先に置き、台帳からは所在だけを参照する。
図2 台帳と保管庫の役割。管理のための情報と、ログインに使う秘密情報を分けます。
PNGを拡大 / SVGを保存

青葉設備で調べ始めたところ、次の点が見つかったとします。

サービス 見つかった状態 次に確かめること
会社のメール 個人別アカウントはあるが、管理者は一人 代わりの管理者を置けるか
ドメイン管理 前任者から引き継いだIDを使用 契約者と復旧先が会社の管理下にあるか
取引先の発注サイト 営業3人が一つのIDを使用 使う人ごとにアカウントを分けられるか
会社のSNS 社内担当者と外部業者が同じ情報でログイン 個人別に権限を付ける機能があるか

ここで、すべてのパスワードを一斉に変更するのは早計です。連携先や利用者が分からないまま変更すると、業務が止まるおそれがあります。まず関係を調べ、通常の移行として進める対象を決めます。不正利用が疑われる場合は、後述する事故対応として急いで扱います。

この段階の完了条件は、台帳の空欄がなくなることではありません。重要なサービスが見えており、分からない項目に調査担当者が付いていることです。

2.個人別アカウントと、残す共有を分ける

「使う人ごとにアカウントを分けられるか」を確認します。ここでいう個人別アカウントは、会社が業務用に管理する本人のアカウントです。私生活用のアカウントへ会社の仕事を移すという意味ではありません。

確認結果 対応
分けられる 利用者ごとにアカウントと必要な権限を用意する
分けられるが、すぐには移行できない 移行担当者と期限を決め、当面の共有範囲を限定する
分けられない 理由を確認し、共有を例外として記録する
まだ分からない 公式資料や提供元で確認する

青葉設備の発注サイトは、提供元へ確認した結果、個人別アカウントを作れない仕様だったとします。その場合、共有を隠すのではなく、営業3人に利用を限定し、営業責任者が利用者の追加・削除を判断する形にします。

例外の記録は、次の程度から始められます。

項目 記入例
対象 取引先の発注サイト
例外の内容 営業3人で一つのアカウントを共有
理由 提供元に確認し、個人別アカウントを作れないため
当面の管理 「営業・発注サイト」保管庫で管理し、閲覧者を限定
判断する人 営業責任者
変更時の対応 担当変更・退職時に利用者と共有した認証情報を見直す
見直す時期 6か月後、またはサービスの仕様変更時
青葉設備の架空事例。会社メールは代わりの管理者を確認。発注サイトは共有しかできない仕様を確認し例外管理。SNSは個人別に任せる機能を調べ、結果に応じて管理方法を選ぶ。
図3 サービスごとに管理方法を選ぶ。架空の事例であり、特定製品の機能を示すものではありません。
PNGを拡大 / SVGを保存

3.保管庫を作る前に、利用者のまとまりを決める

保管庫は、情報をまとめ、利用できる人を決める単位です。部署名だけで区切ると、部署の全員へ必要以上の情報を見せることがあります。「同じ人たちが、同じ理由で使う情報か」を考えます。

青葉設備なら、営業の発注サイトは営業担当者、総務の契約情報は総務担当者と代行者、会社の基盤に関わる管理情報は指定した管理者、というように分ける案が考えられます。

引き継ぐ業務情報と、本人の身分でログインするための情報も区別します。個人別アカウントを前任者から後任者へ渡すのではなく、後任者には本人のアカウントを用意し、サービスが備える方法でデータや役割を引き継ぎます。

4.一つの業務で試してから移行する

最初は、利用者と用途が分かり、影響を把握できる一つの業務を選びます。可能であればテスト用アカウントを使い、追加する、使う、変更する、止める、復旧する、まで確認します。

確認項目 確かめること
通常の利用 担当者が普段の仕事を行えるか
代行 担当者が不在でも、必要な人が仕事を続けられるか
権限 閲覧・編集・管理の範囲が必要以上に広くないか
認証 確認コードや鍵が、一人の私物端末だけに依存していないか
停止 利用が不要になった人のアクセスを止められるか
復旧 入れなくなった場合の手順と情報へ到達できるか
問題が起きた場合 判断する人と、業務を継続する方法が決まっているか

結果は「確認済み」「未確認」「対象外」に分け、確認日、担当者、補足を書きます。「対象外」にした理由も残します。

通常の移行は、次の順に進めます。

  1. 現在の利用者と連携先を調べる。
  2. 新しい保管場所、認証方法、権限を設定する。
  3. 担当者と代行者が実際に使えることを確かめる。
  4. 復旧方法を確認する。
  5. 不要になった古い経路を整理し、必要な認証情報の変更やログイン状態の終了を行う。
  6. 台帳を更新する。

古いメモを削除しても、そこに書かれたパスワードが無効になるわけではありません。また、パスキーを追加しただけで、従来のパスワードが使えなくなるとも限りません。残っているログイン方法を確認します。

現在の利用状況、新しい管理方法、担当者と代行者の利用、復旧を順に確認。未確認なら整理を保留して再試行し、確認済みになってから古い経路を整理して台帳を更新する。
図4 移行は使えることを確かめてから。不正利用が疑われる場合は、通常の移行と分けて対処します。
PNGを拡大 / SVGを保存

5.通常の担当交代を、一度練習する

青葉設備の総務担当者が長期休暇を取るとします。そこで、代行する仕事を洗い出し、代行者本人のアカウントへ必要な権限を付け、共有すべき書類を移します。最後に、代行者が実際の作業をできるか確認します。

休暇から戻った後は、代行のためだけに追加した権限を見直します。退職であれば、アカウントの停止、保管庫へのアクセス解除、共有していた認証情報の変更、残っているログイン状態の終了まで、対象を確認します。

確認する場所 確認する内容
パスワード管理ツール 組織や保管庫へのアクセスが残っていないか
各業務サービス 本人のアカウントや管理権限を止めたか
ログイン状態 すでにログインした端末やセッションを終了する必要がないか
システム連携 APIキーなどの変更が必要か。変更で連携が止まらないか
業務データ 後任者が必要なデータを使えるか

保管庫から外すだけでは、すでに知っているパスワードまで回収できません。1Passwordの公式資料も、退職時の対応として、アクセス停止に加え、共有していたパスワードやトークンの変更を案内しています。公式の退職者対応手順

ただし、システム連携用の鍵を不用意に変更すると、自動処理が止まることがあります。利用先と影響を確認し、変更する人と時刻を決めます。

完了条件は、前任者の不要な利用を止め、後任者が仕事を続けられることです。どちらか一方だけで引き継ぎを終えないようにします。

引き継ぎでは、後任者本人のアカウント・権限・データを準備し業務を確認する一方、前任者の不要な権限やログイン状態を整理する。両方の結果と一時権限の見直し日を記録する。
図5 引き継ぎは「使える」と「止める」を両方確認。退職・異動・休職によって、停止の対象と時期は異なります。
PNGを拡大 / SVGを保存

6.「入れなくなった場合」を確認する

青葉設備の管理者の端末が故障したとします。復旧手順は共有フォルダーに保存してありました。しかし、そのフォルダーへ入るための認証に、故障した端末が必要でした。

この場合、手順書が存在していても、復旧を始められません。復旧に必要な情報が、入れなくなった場所の中だけにある状態を避ける必要があります。

確認するのは、次の点です。

  • 管理者が入れなくなったとき、対応できる代行者がいるか。
  • 予備の認証手段を、認められた人が使えるか。
  • 復旧用のメールアドレスや電話番号を、会社として管理できるか。
  • 復旧手順や必要な情報が、同じ保管庫や端末の中だけに閉じ込められていないか。
  • 復旧後に、紛失した端末や古い認証手段を整理できるか。
  • いつ、誰が、どの方法で確認したかが残っているか。

「別の経路を用意する」とは、誰でも取り出せる場所に情報を置くことではありません。取り出せる人、必要な本人確認や承認、利用後の記録まで決めます。1Passwordの公式資料では、別の所有者の追加やEmergency Kitの保管など、組織の復旧計画を案内しています。公式の復旧計画

確認のために、本番環境で唯一の認証手段を無効にしてはいけません。テスト用アカウントや、提供元が示す安全な確認方法を使います。実際の復旧操作まで試していなければ、その点は「未確認」として残します。

管理者の端末が故障した場合、端末なしで復旧情報に到達できるか確認する。できなければ保管場所と取り出す条件を見直す。権限を持つ人が別の経路から公式手順で復旧し、不要な認証手段を整理する。
図6 復旧手順を開けない場所に閉じ込めない。権限を持つ人が、端末の故障時にも復旧を始められるようにします。
PNGを拡大 / SVGを保存

7.感染や不正利用の疑いは、通常の引き継ぎと分ける

端末の感染や不正利用が疑われる場合は、通常の担当交代と同じ手順で済ませないようにします。疑わしい端末上で認証情報を変更しても、新しい情報まで盗まれるおそれがあります。社内の責任者や契約する支援先へ連絡し、端末の隔離・調査と、安全を確認した別の端末での対応を検討します。

あらかじめ、最低限の対応先と判断の分担を決めておきます。

決めること 記録する内容
連絡先 社内責任者、保守会社、サービス提供元
端末の扱い 隔離などの初動を誰が判断するか
対応する端末 安全を確認した環境をどう用意するか
停止の範囲 誰が、どのアカウントや連携の停止を判断するか
経過の記録 発見時刻、観察した事象、実施した操作

原因を調べる前に端末を消去・初期化すると、必要な証拠を失うことがあります。慌てて自己判断で処理せず、責任者や支援先と対応を決めます。本稿は、事故対応の全手順を網羅するものではありません。

8.例外と変更を、次の担当者が読める形で残す

台帳は、定期点検のときだけでなく、入社、異動、退職、新しいサービスの契約、端末の紛失など、状態が変わったときに更新します。

青葉設備の総務担当者の休暇に合わせた変更なら、次のように残せます。

項目 記録例
変更したこと 総務の契約情報を扱う保管庫に、代行者を追加
理由 担当者の長期休暇中も契約更新を続けるため
承認した人 総務責任者
確認したこと 代行者が必要な書類を開き、更新作業を行えること
見直す時期 休暇終了後、一時的な権限を外すか確認

「誰を追加したか」だけでなく、「なぜその人が使える必要があるか」を残すと、次の担当者が判断を引き継ぎやすくなります。

導入の成果を、項目数だけで測らない

保管庫へ何件登録したかは、作業の進み具合を表します。しかし、それだけでは会社の管理が整ったかは分かりません。

管理責任者が不明なサービスは減ったか。退職者のアクセスを確認できたか。一人の私物端末にしか届かない確認コードを見直せたか。理由の分からない共有を減らせたか。復旧の未確認事項に、担当者と確認日が付いたか。こうした変化を見ます。

青葉設備の例でも、共有をすべてなくすことが目標ではありません。共有を残す理由が分かり、必要な人だけが使い、担当者が変わっても仕事を続けられる状態を目指します。

必要な人が使える。不要になった利用を止められる。担当者が変わっても仕事を続けられる。 この三つを、一つの業務から確かめていくことが、会社のアカウント管理を整える出発点です。

考え方の背景は、関連エッセイ「会社のパスワードを、担当者任せにしない」をご覧ください。

本稿の事例はすべて説明用です。製品の操作画面・契約プラン別の機能は実機検証していません。公式資料の確認日:2026年9月25日。仕様が変わった場合は、各サービスの公式手順を優先してください。