共有アカウントをやめるときは、まず何の業務とデータがそのIDに結び付いているかを調べます。管理者、データ所有者、認証の受信先、外部連携を引き継ぎ、個別IDで業務を試してから、計画的に利用を止めましょう。ただし、退職者の不正利用や認証情報の漏えいが疑われる場合は、この通常の移行を待たず、管理者が利用制限と保全を判断します。
見積、受注、図面、現場記録で同じIDを使っていると、誰が操作したのかを後から追いにくくなります。個別IDへ変える際も、作成しただけでは権限や通知が引き継がれるとは限りません。この記事では、業務を調べるところから、少人数の試行、切替、停止後の点検までを説明します。サービスごとの契約や機能の差を調べ、現場の代替手段も先に決めて進めます。
| 状況 | 判断 | 最初の対応 | 続けて調べること |
|---|---|---|---|
| 共有IDに管理者権限がある | 通常の移行では引継ぎ後に停止する | 管理作業ができる個別IDを用意する | 復旧連絡先、データ所有者、外部連携 |
| 受注・図面閲覧で毎日使う | 削除前に個別IDで試行する | 日常利用者を含む少人数で個別IDを試す | 閲覧、入力、通知、操作履歴 |
| 共有タブレットで使う | 端末共有とID共有を分ける | 端末上の利用者切替手順を決める | ログアウト、保存済み認証、交代後のIDと権限 |
| 認証先や所有者が不明 | 通常の削除を保留し、利用制限は別に判断する | 台帳に不明な事項と調査担当・期限を書く | 受信先変更、データ引継ぎ、復旧方法 |
個別アカウント化で追う利用者と権限を決める
移行後に目指すのは、利用者、操作、権限、管理責任を対応付けられる状態です。誰が設定を変え、誰が入退社時に利用を止めるかを決めましょう。全員へ管理者権限を付けては、IDを分けても誤操作の範囲は広いままです。また、個別IDに変えるだけで全操作の履歴が残るわけではないため、記録対象や保存期間、閲覧できる担当も利用サービスで調べます。
共有PCやタブレットを使うことと、同じIDでログインすることは分けて考えます。端末を交代するときは、前の人のセッションや保存済み認証を残さず、次の人のIDで入った状態を確かめます。端末上で名前を選ぶだけの機能は、本人を認証しているかも調べましょう。移行の順番は管理権限、社外からの利用、止めた場合の影響を比べ、試せる業務から決めます。
共有IDと止められない業務を棚卸しする
対象を探すときは、サービス名の一覧だけでなく、受注から月次処理までの作業をたどります。管理担当が表を作り、受注、製造、事務の担当へ実際の利用を聞きます。メール、保存先、表計算、フォーム、受注・在庫・勤怠に加え、通知送信や自動処理だけに使うIDも拾いましょう。人のログイン用と連携処理用を区別すると、個人IDへ単純に置き換えて止まる処理を見つけやすくなります。
- 受注受付：メール受信、見積書の閲覧、受注データの入力
- 図面管理：保管場所の閲覧、改訂、社外への共有
- 現場記録：設備点検、不良報告、作業実績の入力
- 月次処理：集計、承認、データ出力、設定変更
共有IDごとに、利用者と端末、使う時間、管理権限、データの所有、認証先、外部連携、退職者が使える経路を記します。止められない理由と代替方法も担当へ尋ねましょう。不明な項目は調査担当と期限を付け、通常の削除は保留します。ただし、利用資格を失った人や漏えいの疑いを放置するための保留ではありません。アクセスを制限しながら業務を続ける方法を管理者が判断します。
共有アカウント移行台帳を作り切替日まで管理する
下の移行台帳では、共有IDごとに1行を設け、発行、権限設定、試行、切替、停止を追います。利用者が多い場合は個別IDの一覧を別に結び付け、代表者だけの試験で全員完了にしません。台帳は管理担当などに閲覧を絞り、パスワード、認証コード、復旧コードは記載しないでください。認証情報は指定の保管手段で管理し、台帳には管理者や保管先の識別だけを残します。
| 台帳の項目 | 記入例 |
|---|---|
| サービス・共有ID | 受注記録サービス／order-shared |
| 用途・現行利用者 | 受注入力・照合／受注担当、製造担当、管理担当 |
| データ所有者・現行権限 | 所有者を調査中／管理者 |
| 移行先個別ID・移行後の役割 | 担当者別IDを発行予定／入力担当、閲覧担当、管理者 |
| 認証方法・不明な事項 | 受信先を調査中／認証先と外部連携を担当者へ照会 |
| 切替日・停止日・点検者 | 試行後に決定／切替を点検した人と根拠を記載 |
表のorder-sharedは架空の例で、所有者と認証先が未判明のため切替日を確定していません。調査担当と予定日を入れ、所有者や連携の引継ぎが終わったら、その証拠と点検者を追記します。切替日と旧IDの停止日は分けても構いませんが、残す理由と利用できる範囲、終了日を決めましょう。過去データを保つことと、誰でも旧IDへログインできることは別です。
役割ごとに必要最小限の権限を割り当てる
権限は、旧IDをそのまま複製せず、担当が行う操作から割り当てます。閲覧、入力、修正、削除、設定、招待、外部共有、出力を分けて並べると、過剰な範囲を見つけやすくなります。下の表は役割の例で、各サービスに同じ名称や粒度の設定があるとは限りません。機能が足りない場合も、全員へ強い権限を付ける前に、対象ファイルを分けるなどの方法を検討します。
| 役割 | 主な操作 | 原則として持たせない操作 |
|---|---|---|
| 一般利用者 | 担当業務の対象情報を閲覧 | 削除、設定変更、利用者追加 |
| 入力担当 | 新規入力、担当範囲の修正 | 他担当の記録削除、外部共有 |
| 承認担当 | 内容審査、承認処理 | 利用者追加、認証設定の変更 |
| データ管理担当 | 帳票、共有範囲、保管場所の管理 | 組織全体の設定変更 |
| システム管理者 | 利用者追加、権限変更、設定変更 | 日常業務用の共通利用 |
受注では編集と出力、図面では閲覧と外部共有、品質では入力と削除などを分けます。兼務で権限を広げるときは、理由、申請者、承認者、期限、期限後に戻す担当を残しましょう。表計算には、スプレッドシートの保護範囲で誤編集を防ぐ設定方法も使えます。ただし、セルを保護することと、ファイルの閲覧やコピーを制限することは別なので、共有範囲から合わせて点検します。
管理者とデータ所有者を共有IDより先に引き継ぐ
通常の停止前には、管理者、データ所有者、契約・請求の連絡先、連携の管理者、認証と復旧の連絡先を引き継ぎます。個別IDを作っても、元IDに結び付いたデータや自動処理が移るとは限らないためです。所有権を移せないもの、再設定や再承認を要する連携も台帳へ分け、提供元の手順に従います。本人用の認証器を他人で使い回す引継ぎはせず、新担当の方法を登録して試します。
管理作業を担当する個別IDと、不在時に復旧する経路を先に用意します。複数管理者を設定できる場合も、全員へ同じ強い権限を与えず役割を割り当てましょう。登録しただけで終えず、新しいIDから招待、権限変更、復旧設定、ログ閲覧など、その役割に許された操作を試します。試験は対象を限定し、実データを誤って共有・削除しない検証用の対象を使います。
少人数でログインから業務完了まで試す
試行には管理担当だけでなく、実際に入力や閲覧をする人を含めます。通常業務が発生する日に、招待から入力、承認、通知、過去記録の閲覧までを通してみましょう。ログインに成功しても、承認画面へ入れない、通知が旧IDに届く、といった欠けが残る場合があるためです。許可した操作ができることに加え、許可していない操作ができないことも下の項目で試します。
- 招待の受信、初回ログイン、二段階認証が完了する
- 担当業務のファイル、帳票、過去記録を閲覧できる
- 入力、更新、承認、通知を担当範囲で実行できる
- 対象の操作が個別IDと日時に対応して履歴へ残る
- 不要な設定変更や外部共有ができない
共有端末は、利用終了、ログアウト、保存済み認証の扱い、次の人の表示名と権限を手順にします。試行で問題が出ても、現場判断で旧IDへ戻すのではなく、承認した戻し方を使います。時刻、利用者、失敗した操作、途中まで保存した内容、戻した理由を残し、二重入力を避けましょう。操作の追い方は、スプレッドシートの変更履歴を追跡する運用も参照してください。
切替日の可否を判断し共有IDを停止する
切替前には対象業務、日時、新しい入り方、問い合わせ先、旧IDを使わない開始時点を知らせます。当日は担当リーダーが利用者別の試行結果と未了項目を読み、管理担当が切替可否を判断します。以下は通常の計画移行の流れです。実施した担当と時刻、判断の根拠を記し、侵害が疑われるIDを試行完了まで使い続ける手順とは分けて扱います。
- 管理者、データ所有者、認証・復旧先、外部連携の引継ぎを照合する
- 未了なら通常の切替を保留し、理由と調査日、旧IDの制限を決める
- 引継ぎ後に個別IDで対象業務を完了できるか試す
- 完了できなければ、影響範囲を記録して試行段階へ戻る
- 試験を終えたら停止方法と事後点検を決め、データ削除は保存条件を満たして別に判断する
停止の前後で、個別IDの業務、権限、通知、連携、履歴を点検します。旧IDの無効化、ログイン中のセッション終了、アプリへの許可の取消が同じ操作で済むかはサービスで異なるため、提供元の手順で残る経路も調べます。共有端末の保存済み認証も除き、旧IDで再び入れないことを試します。データの削除や契約終了は別の判断です。保存義務、移管、復元可否、費用を調べず削除しません。
共有IDを残すときは例外の利用記録を作る
設備用端末や代表窓口では、同じ使い方をすぐに変えられない場合があります。まず個別ログイン、代理・委任、共有メールボックスなど、提供元が用意した方法で役割を分けられるかを調べます。自動処理用には、その用途に対応する認証方法と管理者を割り当てましょう。代表アドレスを残すために、受信者全員が同じパスワードを使う構成へ戻さないようにします。
例外を残すなら、目的、利用者、責任者、時間帯、認証情報の管理者、見直し日、廃止予定日を承認記録へ残します。操作した人を追えない場合の手書き記録は補助であり、本人認証や完全な操作ログの代わりにはなりません。IPAのガイドラインも、共有IDを避け、やむを得ない場合は利用者を特定できる仕組みを求めています（https://www.ipa.go.jp/security/guide/sme/about.html）。月次の点検で例外の継続を判断します。
個別アカウント化後は毎月の棚卸しで維持する
移行後は月1回の点検に加え、入社、退職、異動、委託終了、端末の紛失などが起きた時点で権限を見直します。人員変更を月末まで待たせる運用にはしません。台帳と実設定を比べ、使わないID、過剰な管理権限、外部共有、認証と復旧先を調べましょう。使われていないIDでも自動処理の依存がある場合は、履歴と担当へ照会してから処置します。
権限変更は依頼、承認、実施を分け、担当と日付を残します。設定変更、削除、外部共有などの履歴も所定の頻度で読みますが、履歴がないことだけで異常なしとは決めません。利用環境によって記録される範囲が違うためです。不審な操作を見つけたら定期点検を待たず管理担当へ連絡し、利用停止やセッション取消、証拠の保全、影響調査を対応手順に従って進めます。
利用者や権限を分けたいのに、今のツールでは実現できない場合は、無料ツールから業務システムへ移行する判断基準も参考になります。ID数だけでなく、権限の粒度、履歴、復旧、連携、契約費用を比べ、自社で維持できる範囲を選びましょう。
よくある質問
共有メールアドレスは個別アカウントに移行すると使えなくなりますか？
共有メールアドレスと共通のログインIDは別です。代表窓口のアドレスを残し、閲覧や返信を個別IDの委任で行えるサービスもあります。ただし、方式によって送信者表示、履歴、権限、契約が異なります。受信、返信、過去メール、担当交代、通知先まで試し、旧ID停止後に窓口が止まらない状態を作ってから切り替えます。
共有タブレットでは利用者ごとに毎回ログインし直す必要がありますか？
誰が操作したかを追うには、利用者の交代を本人認証と結び付けます。サービスが対応する端末切替や認証方法を使い、前の人のログイン状態を引き継がない手順を決めましょう。名前を一覧から選ぶだけでは、その人が操作した証明にならない場合があります。共有ブラウザの自動入力や同期も試し、次の人が前の人の情報へ入れない状態にします。
退職者の個別アカウントはいつ停止し、データは誰が引き継ぎますか？
退職や契約終了で利用資格を失う時点に合わせ、アクセスを止める日時を事前に決めます。引継ぎが未了だからと、退職者が使える状態を延長しません。データは管理者が保全し、提供元の移管方法で後任へ渡します。管理権限、復旧先、連携、端末、共有先も処置し、停止と移管を別々に記録してください。アカウントの削除は保存と移管の条件を満たしてから判断します。
管理者権限を持つ人が1人しかいない場合、最初に何を準備すべきですか？
まず、その1人が不在でも復旧できる連絡先と認証手段、データの管理先を決めます。サービスが許す範囲で追加の管理者を個別IDとして用意し、役割を割り当てて管理操作を試しましょう。追加できない場合は、提供元への復旧手続と代替業務を文書化します。旧共有IDの計画停止は管理作業を引き継いでから行い、パスワードを大勢へ渡すことを代行策にしません。
まとめ
まずは業務をたどり、共有IDに結び付く利用者、データ、認証、管理権限、連携を台帳へまとめましょう。次に、担当の操作へ合わせた個別IDを用意し、少人数で業務と権限、履歴、復旧を試します。通った項目と未了項目を根拠に切替を判断し、旧IDの停止後も通知や連携が動くところまで点検してください。
運用後は、人員変更時の処置と毎月の点検を組み合わせます。台帳の未解決項目、残る共有ID、過剰な権限を実設定と比べると、移行途中のまま止まった箇所を追えます。利用機能や契約、復旧方法が変わった場合も手順を更新しましょう。IDを増やしたことを完了とせず、誰が何をでき、退職や異常時に誰が止めるかまで維持します。
