社員名簿は誰のものか。総務と情シスで決めるID基盤の持ち方

受付やチャットの社員名簿が、人事の名簿と合わない。
名簿が増えるほど、ズレは起きやすくなります。

全部を1つにまとめるのは容易ではないため、複数の名簿が残る前提で考える、現実的な持ち方があります。

名簿（マスタ）が増えるほど、ズレが起きる

社員名簿（マスタ）は、ツールが増えるたびに増えます。
人事、ID基盤（社員のIDとログインをまとめて管理する仕組み）、受付、チャット、会議室。それぞれが自分の名簿を持ちます。
※注釈：マスタは、ツールごとに持つ社員の一覧のことです。

名簿が増えると、次のようなズレが現場に出ます。

• 異動の反映が漏れて、来客の知らせが前の部署の担当者に届く。
• 退職した社員の名前が、受付の検索画面に残る。
• どの名簿が正しいか分からず、突き合わせに時間がかかる。
• 直す人が決まっておらず、ズレに誰も気づけない。
• 表記が揃わず、同じ社員が別の人として扱われる。

表記のズレは、名簿を突き合わせたり同期したりするときに、原因として見つけにくいものの1つです。
人の目には同じ名前でも、ツールによっては別の文字列として扱われます。
ツールを足すたびに、名簿ごとの命名ルールや記号、スペースの使い方が少しずつ分かれていきます。

たとえばMicrosoft Entra IDとの同期では、名と姓は半角英数字だけが写され、全角が1文字でも含まれると、写されずに既存の値が残ります。

ID基盤の役割は2つあります。「誰が社員か」を持つ名簿と、「本人か」を確かめる認証です。
この2つは別の機能なので、この記事でも分けて書きます。

全部を1つにまとめるのは大変なので、現実的には複数の名簿が残る前提で考える

名簿が1か所なら、更新も突き合わせも1回で済みます。
社員名簿を1か所に集約する考え方（ワンデータベース）です。
そうなればよいという考えは、自然だと思います。

ただ、移すのは簡単ではありません。
名簿の移管には費用と手間がかかり、費用の承認も要ります。
人事、情シス、各部署と、全社に関わります。
うまくいかなかったときの戻し方や、引き継ぎの手間も重くなります。

受付を入れる側が、お客様の名簿の土台を変えることもできません。
RECEPTIONISTは、お客様の名簿やID基盤を入れ替えずに、連携する形です。

だから現実的には、名簿は複数残る前提で、ルールを徹底して、間違えにくくする工夫を積み重ねます。
将来に1か所へ集約する選択肢を、否定するものではありません。

複数の名簿を、仕組みで揃える工夫

複数の名簿が残るなら、ルールで揃えます。
名簿の変更を最初に入力する場所を決め、ほかの名簿はそこから写す。
この考え方を「正の元」と呼びます。

候補は、人事システム、ID基盤（Microsoft Entra ID（旧Azure AD）やGoogle Workspace）、総務が管理するExcelなどです。
選ぶ目安は、異動や退職の情報が最初に入る場所に近いかどうかです。
そこを大元にすると、同じ内容を二度入力しなくて済みます。

総務は「いつ、誰が変わるか」を渡します。
情シスは「どのシステムに、どの方法で反映できるか」を答えます。
この分担を先に決めておくと、漏れがどちらの側で起きたのかを追えます。

大元を決めても、ほかのツールが自動でついてくるとは限りません。
反映の持ち方は3つあり、どれにも向き不向きがあります。

※注釈：SCIMは、IDの変更をほかのツールへほぼ即時に伝える、業界標準の仕組みです。

今できることと心得

名簿の土台を変えなくても、今日から決められることがあります。

• 正の元になる名簿（正本）を決め、ほかの名簿をそれに合わせるルールを作る。名簿は複数のままです。食い違ったときは正本に直す、という基準を先に決めます。
• 表記のルールを正本に揃える。姓名の間のスペース、全角と半角、部署名の略称、メールアドレスの書き方を、正本の表記に合わせて決めます。
• 正本からほかの名簿へ、誰がいつ反映するかを決める。反映が週次なら、退職日の何日前までに正本へ入力するかまで決めます。
• 誰が、いつ、どこを直したかを残す。担当が替わっても、手順を引き継げます。
• 小さな範囲から始める。まず1つのツールで試して、元に戻せる状態を保ちます。
• 既存の名簿と並行して動かす。新しい仕組みに一度に切り替えず、結果が合うかを見比べます。

仕組みを選ぶときは、失敗したときに戻せるかどうかも条件に入れます。
名簿の持ち方を決める前に、来客の知らせがどう届くのかを見ておきたいときは、3分でわかる！受付システム解説資料で、基本機能と導入事例を確認できます。

情シスに渡す確認項目

総務から情シスに相談するときは、次の項目を並べて渡すと、話が早く進みます。

• 名簿の正の元（正本）はどこか。人事システム、ID基盤、Excelのどれを正本にするか。ほかの名簿を正本に合わせるルールはあるか。
• 異動・退職を、誰がいつまでに入力するか。入力が遅れた日数が、そのまま名簿のズレになります。
• ツールへの反映は、手・同期・ファイルのどれか。同期なら、手動か、週1回の定期実行で運用が回るか。
• 退職者を、いつ各ツールから外すか。
• 名簿の表記ルールは揃っているか。姓名のスペース、全角と半角、部署名の略称、メールアドレスの書き方が、名簿の間で違わないか。
• ログインをまとめるか。まとめる場合、使っているID基盤が対応一覧に入っているか。
• ID基盤がGoogle WorkspaceとMicrosoft 365に分かれていないか。分かれている場合、どちらを大元にするか。
• 障害や移行でID基盤にログインできないとき、どう対応するか。

ツールを入れたあとの連携を、来客対応から設計する考え方は、別の記事で整理しています。

今のID基盤のまま、受付をつなげられます

お客様のID基盤や名簿を入れ替えなくても、RECEPTIONISTには連携の形がいくつかあります。
大きく、認証（ログイン）と、名簿の同期に分かれます。2026年11月4日時点の内容です。

認証：ログインを一か所にまとめる

ログインを一か所にまとめる仕組み（SSO）に、SAML認証で対応しています（PREMIUMプラン）。
※注釈：SAML認証は、ID基盤でのログイン結果をほかのツールへ渡す方式です。

対応するID基盤（IdP）は、ヘルプに記載のあるもので、
OneLogin、Microsoft Entra ID（旧Azure AD）、Google Workspace、HENNGE One、CloudGate UNO、Okta、trustlogin、Nextsetの8つです。
※注釈：IdPは、ログインを一元管理する側のサービスです。

設定すると、メイン管理者を除いて、メールアドレスとパスワードでのログインができなくなります。
Microsoft Entra IDの場合、連携する属性は、メールアドレス、名前、名と姓です。
管理者が未登録の社員でも、Entra IDにアカウントがあれば、SAML認証でログインでき、アカウントが自動で追加されます。

名簿の同期：社員名簿を写す

Microsoft Entra IDからは、社員名簿を同期できます（PREMIUMプラン）。
同期は手動か、週1回の定期実行です。定期実行は、設定の申請から反映まで約1週間かかります。
Microsoft Entra IDにいない社員は、受付側でも削除されます。

ただし、管理者と有効なアポの担当者は削除されません。
Outlookの予定や会議室まで含めた話は、Outlook・会議室・名簿までつなぐ場合にまとめています。

SFTPでは、名簿ファイルを毎日6:30に取り込みます。
Google Workspaceから社員名簿を自動で同期する機能は、現時点では提供していません。

Google Workspaceの会社は、手で直すか、ファイルで取り込む形になります。
予定や会議室まで含めた話は、Google Workspaceで来客・予定・会議室までつなぐ場合を読んでください。

公開APIで取得できるのは社員一覧のみで、登録や更新には使えません。

認証と名簿の同期は、別の設定です。
どちらをどのID基盤につなぐかは、情シスと一緒に決めます。
名簿の持ち方を決めたら、来客対応の流れ全体を3分でわかる！受付システム解説資料で確認してください。