← 記事一覧へ

公開: 2026/9/13 ・ 更新: 2026/9/13

共用PCは残して、業務SaaSのIDだけを個別にする

この状態なら読む

次のような現場を対象にします。

• 店舗、受付、工場、倉庫、事務所などで1台のPCを複数人が交代で使っている
• PCそのものを人数分へ増やす必要性は低い、またはすぐには増やせない
• Microsoft 365、Google Workspace、業務SaaS、クラウドストレージなどは利用者別IDを発行できる
• 現在はPCだけでなく、SaaS側も1つのID・パスワードを複数人で共有している

ここでは、共用PCを直ちに廃止することを結論にしません。先に、端末を共用することと、SaaSの資格情報を共有することを別問題として扱います。

共用PCと共有IDは同じ問題ではない

1台のPCを交代で使う業務はあります。Windowsの公式資料でも、複数のユーザーが同じデバイスへサインインして使用する共有端末の利用形態が案内されています。

一方、PCが共用だからといって、クラウドやSaaSでも同じID・パスワードを使う必要があるわけではありません。

分けて考える対象は少なくとも次の4つです。

最初から4層すべてを完全に分離できなくても構いません。個別IDを発行できるSaaSから、認証主体を分けるだけでも運用は変えられます。

SaaSを個別IDへ分けると何が変わるか

一人だけ利用停止しやすくなる

共有IDでは、一人だけ利用を止めたいときに共通パスワードの変更や全員への再配布が必要になりやすくなります。

利用者別IDであれば、サービスが持つアカウント管理機能の範囲で、退職・異動した人だけを停止する設計にできます。

権限を全員同じにしなくてよくなる

受付担当、経理担当、管理者が同じIDを使っていると、必要な操作範囲の違いをアカウント単位で表しにくくなります。

個別IDにすると、サービスが権限設定へ対応している場合、日常利用者と管理者、閲覧だけ必要な人と変更する人を分ける余地ができます。

操作記録を利用者と結び付けやすくなる

サービス側に操作履歴や監査ログがあっても、全員が同じIDを使えば、そのIDの内側で誰が操作したかは別の手段で補わなければなりません。

利用者別IDなら、少なくともサービスが記録する利用者IDと実際の利用者を対応させやすくなります。

MFAと復旧先を利用者ごとに考えられる

共有IDへMFAを設定すると、認証アプリ、電話番号、セキュリティキー、復旧先を誰が持つかという別の共有問題が起きます。

利用者別IDへ分ける場合は、認証要素と復旧経路も「その人の利用を止めたときに残らないか」「会社として必要な復旧ができるか」で確認します。

共用PCを残すなら、引継ぎ時の状態を管理する

SaaSを個別IDへ分けても、前の利用者のログイン状態が共用PCへ残っていれば分離は崩れます。

最低限、次を運用として決めます。

1. 業務SaaSは利用者ごとのIDでログインする
   • 共用PCだからという理由だけで共通資格情報へ戻さない。
2. 交代時に対象SaaSからサインアウトする
   • 画面を閉じるだけでログイン状態が残るサービスは、明示的なサインアウトまで確認する。
3. 共用ブラウザへ業務パスワードを保存しない
   • 次の利用者が自動入力や保存済み資格情報を使える状態を避ける。
4. 前利用者のセッションが残っていないことを確認する
   • タブ、アプリ、ブラウザプロファイルを切り替えただけで十分な分離とみなさない。
5. ダウンロードした業務ファイルの扱いを決める
   • デスクトップ、ダウンロードフォルダ、一時保存先へ残したファイルを次の利用者がそのまま開けないか確認する。
6. 管理者IDを日常利用へ使わない
   • 管理設定が必要なときだけ管理用IDを使い、通常業務のIDと分ける。

現場では「ログアウトしてください」だけだと忘れやすいため、交代時の短い手順として画面横などに残す方が運用しやすい場合があります。

ブラウザプロファイルを使う場合も過信しない

利用者ごとにブラウザプロファイルを分けると、ブックマークや履歴、ログイン状態を分離しやすくなる場合があります。

ただし、共用PC上で他人のプロファイルへ切り替えられる状態なら、それだけを強い認証境界とは扱いません。SaaS側の個別認証、端末のロック、OS利用者の分離など、必要な境界を別に確認します。

ブラウザプロファイルは整理手段として使い、共有パスワードを正当化する理由にはしません。

個人データを扱う場合は、利用者を区別できるかを確認する

個人情報保護委員会の通則編では、個人データを情報システムで取り扱う場合の技術的安全管理措置として、アクセス制御、アクセス者の識別と認証などが示されています。

そのため、顧客情報や従業員情報などの個人データを扱うSaaSでは、単に「社内の人しか使わない」だけでなく、誰を利用者として許可し、どう識別・認証しているかを説明できる状態が重要です。

これは、共用PCそのものを一律に禁止するという意味ではありません。端末共用を残すなら、SaaS側の利用者識別や端末上に残る情報を含めて、どこで主体を区別するかを明確にします。

PCのログインまで個別にした方がよい条件

SaaSだけを個別IDへ分ける方法は、すべての共用PCへ十分とは限りません。次の状態がある場合は、Windows等のOSログインも利用者別へ分けることを検討します。

• 利用者ごとに見えてよいローカルファイルが異なる
• ブラウザや業務アプリへログイン状態が残りやすい
• メールクライアントや同期アプリが個人別に常駐する
• 顧客情報、給与、人事、認証情報など機密性の高い情報を扱う
• ダウンロード、印刷、USBへの保存を利用者ごとに管理したい
• 端末上の操作も利用者単位で追いたい
• 交代のたびに完全なサインアウト確認を行う運用が現実的でない

逆に、PCが特定の受付処理だけに使われ、ローカルへ重要情報を残さず、利用するSaaSも個別IDで確実に交代できるなら、端末共用を残したまま改善できる場合があります。

費用を増やさず始める順序

まず契約変更やPC追加の前に、現在の契約内で何ができるかを確認します。

1. 共用しているSaaS・クラウドIDを一覧にする。
2. 各サービスが利用者別IDを発行できるか確認する。
3. 追加費用なし、または既存契約内で分けられるサービスから個別化する。
4. 管理者、個人データを扱う人、退職時に個別停止したい人を優先する。
5. 共用PCの交代手順へ、サインアウトと残存ファイル確認を追加する。
6. 個別IDで運用しても端末上の情報が混ざる場合だけ、OSログイン分離や端末追加を次の改善として検討する。

個別IDの追加にライセンス費用が掛かるサービスでは、料金だけで「共有のままでよい」とは決めず、扱う情報、権限、退職時の停止、操作記録の必要性と合わせて優先順位を付けます。

個別IDを発行できないシステムは別問題として扱う

製品仕様や契約上、利用者別IDを発行できない業務システムもあります。

その場合は「個別IDへ分ける」で解決したことにせず、誰がいつ使ったかを別記録で補う、利用端末を限定する、資格情報の変更責任者を決める、管理者操作を分ける、更改条件を決めるなど、代替の管理を検討します。

共用PCが必要なことと、システムが個別IDを持てないことも別の論点です。

この解説が断定しないこと

• 共用PCを使うこと自体が一律に不適切だとは扱いません。
• 個別IDへ分けただけで十分なセキュリティになるとは扱いません。
• ブラウザプロファイルだけで利用者分離が完成するとは扱いません。
• すべての会社へPCを人数分購入することを求めません。
• 特定のSaaSやライセンスを一律に推奨しません。

目標は、端末の台数を増やすことではなく、誰がどの資格情報で業務サービスへアクセスしているかを説明でき、必要な人だけを止められる状態へ近づけることです。