共通メールとログイン

この状態なら読む

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

• info@、sales@、support@、reserve@ などを複数人で扱いたい
• 現在は、そのメールアドレスの1つのID・パスワードを全員で共有している
• 共通窓口自体は残したい
• 退職・異動時には一人だけ外せるようにしたい
• 誰が返信したか、誰が設定を変えたかを区別しやすくしたい

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

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

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

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

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

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

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

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

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

共有メールボックス

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

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

委任

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

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

グループ・配布リスト

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

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

転送

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 社外の人も使うのか

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

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

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

• 過去の受信メール
• 送信済みメール
• 連絡先
• ルール・フィルタ
• 自動返信
• 転送設定
• 署名
• カレンダーや共有先
• 他サービスのログイン・復旧先
• MFAと復旧用電話番号・メール
• 管理者権限

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

移行の順序

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

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

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

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

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

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

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

• 外部から共通アドレスへ送信して全員が必要な範囲で見られるか
• 共通アドレスから返信できるか
• 返信した人を内部で確認できるか
• 送信済みメールが必要な人から参照できるか
• 二重対応を避ける運用ができるか

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

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

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

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

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

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

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

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

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

• その人の共通窓口への権限を外す
• その人の業務用IDを停止する
• 私物端末やメールアプリに残るデータを確認する
• 個別に設定した転送が残っていないか確認する
• 外部委託者の場合は契約終了に合わせて権限を外す

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

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

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

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

• サービスの監査・送信記録
• 返信時の担当者署名
• フォルダやラベル
• 対応済みフラグ
• 問い合わせ管理ツール
• 業務日報や案件番号

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

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

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

• 退職者のアドレスへ転送が残らないか
• 私物メールへ自動転送していないか
• 誰が返信したか分からなくならないか
• 顧客へ個人アドレスが露出して問題ないか
• 送信済み履歴が分散しないか
• 複数人が同時に返信しない運用があるか

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

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

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

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

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

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

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

• 共通窓口のアドレスは維持する
• 利用者は自分の業務IDで認証する
• サービスの公式な共有・委任機能を使う
• メンバー追加・削除の責任者を決める
• 退職時はその人だけ外せる
• 共通パスワードを日常利用者へ配らない
• MFAと復旧先の管理主体を説明できる
• 誰が返信したか必要な範囲で追える

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

• info@ などの共通アドレスを使うこと自体を問題とは扱いません。
• すべてのメールサービスに共有メールボックスや委任機能があるとは扱いません。
• 転送を一律に禁止しません。
• 特定ベンダーのメール製品を一律に推奨しません。
• 個別認証へ分けただけで問い合わせ対応の抜け漏れがなくなるとは扱いません。

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