<サイトレイアウト タイトル=共通メールアドレスと共有ログインを分ける 説明=info@やsales@などの共通窓口を複数人で扱いながら、メールサービスのID・パスワードは共有せず、利用者別認証へ移す考え方を整理します。>

← 記事一覧へ

アカウント・権限共有・クラウド

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

共通メールアドレスと共有ログインを分ける

この状態なら読む

次のような会社を対象にします。

ここで残したいのは共通の宛先・差出人という業務上の窓口です。全員が同じ資格情報を使うことは、その業務要件と同じではありません。

「共通アドレス」と「共通資格情報」は別物

顧客から見れば、担当者が変わっても同じ info@ へ連絡できる方が便利な場合があります。

一方、内部では利用者ごとに別のIDで認証し、その共通窓口へアクセスする設計にできるサービスがあります。

英国NCSCも、共有の業務要件がある場合、可能ならアカウントそのものを共有するより、別アカウントへ権限を委任する方法を使うことを示しています。

つまり目標は、次のように分けることです。

役割 例
公開する窓口 info@company.example
実際に認証する人 山田さん、佐藤さん等の利用者別ID
窓口を使える人の管理 管理者がメンバー追加・削除
返信時の差出人 共通アドレス、または担当者名を含む表示
記録 サービスが持つ送信履歴、監査情報、担当管理等

窓口を共有しても、パスワードまで共有する必要はありません。

使っているサービスにどの共有方式があるか確認する

メールサービスによって機能名や挙動は異なります。代表的には次のような方式があります。

共有メールボックス

複数の利用者が、自分のアカウントで認証した後に共通メールボックスを開く方式です。

共通アドレスで受信し、サービスが対応していれば共通アドレスから返信できます。メンバー追加・削除で利用者を管理できるため、共通パスワードを配る必要を減らせます。

委任

あるメールボックスへの閲覧・送信等の権限を、別の利用者アカウントへ渡す方式です。

窓口そのものは一つでも、認証は利用者ごとに行います。

グループ・配布リスト

共通アドレスへ届いたメールを複数の個人メールボックスへ配る方式です。

受信には向いていますが、誰が対応中か、共通アドレスからどう返信するか、送信履歴をどこへ残すかは別に確認します。

転送

共通アドレスへ届いたメールを複数の宛先へ転送する方式です。

簡単に始められる場合がありますが、返信元、対応済み管理、退職時の転送解除、外部転送の有無を確認します。

どの方式が適切かは、現在のメールサービスが提供する公式機能と契約条件で確認します。

先に確認する5つの業務要件

機能名から選ぶ前に、共通窓口で何を実現したいかを整理します。

1. 受信だけ共有したいのか

複数人が同じ問い合わせを読めればよいのか、それとも全員が共通アドレスから返信する必要があるのかを分けます。

2. 誰が対応したか残したいのか

問い合わせ対応では、同じ顧客へ二重返信したり、誰も返信しなかったりすることがあります。

メールの既読状態だけで足りるのか、担当者・対応済み・保留などを管理する必要があるのかを確認します。

3. 共通名義で送信したいのか

顧客へ常に info@ から見せたいのか、担当者個人のアドレスで返信してもよいのかを決めます。

4. 過去メールを全員で見たいのか

問い合わせ履歴をチーム全員が参照する必要があるのか、担当者だけでよいのかを確認します。

5. 社外の人も使うのか

外部委託先や制作会社も共通窓口を扱う場合、社員と同じ資格情報を渡すのではなく、外部者だけ後から外せる権限付与ができるか確認します。

移行前に共有IDが持っているものを確認する

共有IDを止める前に、現在のアカウントが何を持っているかを確認します。

メールアドレスが、WebサービスのログインIDやパスワード再設定先として使われていることもあります。窓口移行と他サービスの認証を同時に壊さないようにします。

移行の順序

1. 利用者別の業務IDを確認する

共通窓口を使う人が、それぞれ自分の業務用IDで認証できる状態を作ります。

個人用メールや私物アカウントを会社の認証主体にするのではなく、会社が利用停止できる業務IDを使えるか確認します。

2. 共通窓口を利用者別IDから使えるようにする

利用サービスの共有メールボックス、委任、グループ等の公式機能を使い、個人別認証のまま共通窓口へアクセスできるようにします。

3. 受信・返信・履歴を試す

本番切替前に、少なくとも次を試します。

4. MFAと復旧先を共有パスワードから切り離す

利用者別IDでは、各利用者のMFAを個別に管理します。

共通窓口の管理者権限や復旧経路については、特定の一人だけが持つ私物電話・個人メールに依存していないか確認します。

5. 共有IDへの直接ログインを止める

利用者別IDから共通窓口を扱えることを確認したら、旧共有IDのパスワードを日常利用者へ配らない状態へ移します。

サービス上必要なアカウントとして残す場合も、日常的に全員が直接ログインする方式へ戻さないようにします。

退職・異動時は「窓口を消す」のではなく「その人だけ外す」

個別認証へ分ける大きな利点は、担当者が変わっても info@ 自体を変えなくてよいことです。

退職・異動時には次を確認します。

共通パスワードを全員へ再配布する運用より、一人だけ外せる状態を目指します。

「誰が返信したか」をどう残すか

共通窓口を個別認証へ分けても、顧客から見た差出人が常に info@ なら、受信者には担当者が見えない場合があります。

必要なら内部で次を組み合わせます。

すべての会社に専用の問い合わせ管理システムが必要とは限りません。問い合わせ量が少なければ、メールサービスの機能だけで足りる場合もあります。

転送だけで運用する場合の注意

共有機能が使えず転送を使う場合は、次を確認します。

転送は「受信を配る」機能であり、窓口運用全体を自動的に解決するものではありません。

共通アドレスを他サービスの共有ログインに使わない

info@ を共通窓口として維持していても、そのアドレスを使って会計、クラウドストレージ、SNS、Web管理画面などへ全員でログインする必要はありません。

メールの共同受信と、他サービスの認証主体は分けます。

共通アドレスが他サービスの復旧先として使われている場合は、誰が復旧メールを読めるか、管理者だけに限定すべきかも確認します。

小規模事業者での最小構成

高度なメール管理基盤を前提にしなくても、まず次の状態を目標にできます。

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

重要なのは、顧客向けの共通窓口は残しながら、内部の認証主体まで一つにしないことです。

根拠・一次情報

外部事実は、資料トップではなく実際に確認した原典内の位置へ戻れるようにしています。 リンク先が対応している場合は該当文言を直接表示します。

  1. NCSCは、共有の業務要件がある場合でも、可能な場合はアカウント共有より別アカウントへの権限委任を使うことを示している。