もうIDとパスワードを何個も覚えたくない人へ：シングルサインオンを“用語なし”で理解する

• 「シングルサインオンって言葉は聞いたことがあるけど、正直よくわからない」
• 社内や自社サービスで、システムごとに別々のID・パスワードを使っている
• 「とにかく、同じIDでまとめたい」「ログイン回数を減らしたい」と思っている

そんな方向けに、

• シングルサインオンを技術用語なしでざっくり説明
• “なんちゃって”に終わる「セイムサインオン」との違い
• 複数ID管理から抜け出すために、最初にやるべき3ステップ

を、実際のお客さまとのやりとりベースでお話しします。

現場でよくある最初の相談は、だいたいこんな感じです。

「サービスが増えすぎて、IDとパスワードがバラバラなんです」
「一回ログインしたら、他のサービスもそのまま使えるようにしたいんですよね」

ここで「それ、シングルサインオンですね」とこちらが言うと、

「あ、そういう名前なんですね」

となることがほとんどです。

つまり、
“シングルサインオン”という言葉は知らなくて当たり前です。
イメージさえ共有できれば十分です。

この記事ではあえて、最初は「シングルサインオン（SSO）」という言葉をほぼ使わずに説明してみます。

複数システムにそれぞれ別のIDでログインしていると、こんな状態になりがちです。

• システムA：メールアドレス＋パスワードA
• システムB：社員番号＋パスワードB
• システムC：ID＋パスワードC ……

しかも、

• 「どれがどのシステムのパスワードかわからない」
• 「パスワードを忘れて、情シスに電話・メール」
• 「退職者のアカウント消し忘れが心配」

といった問題もついてきます。

ユーザーにとっては「面倒」
管理側にとっては「怖い」

のが、複数ID・パスワード管理の世界です。

では、理想の世界はどういう状態でしょうか。

身近な例でいえば、

• 朝、会社のPCにログインしたら
  → Outlook や Teams、kintone などが、そのまま使える
• Googleアカウントに一度ログインしたら
  → Gmail も、カレンダーも、ドライブも、そのまま使える

こういう状態をイメージしてください。

「最初の1回だけちゃんとログインをする」
→ そのあと、同じ人であることをシステム同士で確認し合う
→ ユーザーは、いちいちID・パスワードを入れなくても各サービスを使える

これが、シングルサインオンのざっくりしたイメージです。

ここでややこしいのが、「セイムサインオン（Same Sign-On）」という考え方です。

ぱっと見、シングルサインオンとほぼ同じだと思われがちですが、
中身は結構違います。

セイムサインオンとは？

• 各システムのユーザーDBに、同じIDとパスワードをコピーして持つやり方
• 見かけ上は「どのシステムも、同じID／パスワードでログインできる」

ただし、

• Aシステム用のユーザーテーブル
• Bシステム用のユーザーテーブル
• Cシステム用のユーザーテーブル

…という具合に、IDとパスワードがシステムごとに存在しています。

何が困るのか？

• パスワードを変更するとき
  → すべてのシステムに反映する仕組みを作らないといけない
• 退職者のアカウントを止めるとき
  → 全システムで消し忘れがないか気をつける必要がある
• セキュリティ事故が起きたとき
  → どこから漏れたか追いかけるのが大変

ID・パスワードが「何個も存在している世界」はあまり変わっていないわけです。

本来のシングルサインオンでは、発想が逆になります。

• IDとパスワードを、1箇所の“認証基盤”にだけ持つ
• 各システムは、その認証基盤に「この人って本物？」「誰？」と聞きにいく
• 認証基盤が「この人は○○さんで、ログインOKです」と返す

たとえるなら、各システムが「お巡りさん」に
→ 「この人、ちゃんと身分証持っていますか？」と聞きにいくイメージです。

ここでのポイントは、

「ID・パスワードをどこに何個持つか？」

です。

• セイムサインオン
  → 各システムにバラバラに持つ（同じ内容だけど、実体は別）
• シングルサインオン
  → 一箇所だけに持つ（他は「確認するだけ」）

と覚えておくと、だいぶスッキリします。

では、「うちもそういう世界に行きたい」と思ったとき、
何から手をつければよいでしょうか。

技術的な細かい話は専門家に任せるとして、
まずは次の3ステップだけ押さえておけば十分です。

ステップ1：今どんなIDが存在しているか棚卸しする

• どんなシステムがあるか（社内・社外・クラウドサービスなど）
• それぞれのシステムで
  • IDとして何を使っているか（メールアドレス、社員番号など）
  • どこで管理しているか（AD、独自DB、Excel…）
• どのユーザーがどのシステムを使っているか

ここを曖昧にしたまま進めると、後で必ずつまずきます。

ステップ2：「ID基盤を新しく作るのか、既存システムを使うのか」を決める

シングルサインオンの話になると、必ず出てくるのがこの分かれ道です。

• 新しくID基盤（認証基盤）を作るのか
• すでにあるもの（例：Entra ID／Azure AD、Google Workspace など）を使うのか

ここを最初に決めておかないと、

• 見積もりがまったく合わない
• プロジェクトの難易度が想定より高くなる

といった事態になりがちです。

「うちは社員IDはすでにADで一元管理している」など、
既にあるものを活かすシナリオがないかを、まずは確認してみてください。

ステップ3：いきなり全部やろうとせず「小さく始める」

• まずは2〜3個のシステムから始める
• 社内利用だけで試してみる
• パスワード移行（特に暗号化されている場合）の方法を決める
  → 必要に応じて「初回ログイン時にパスワード再設定」フローを設計

特に既存会員DBのパスワードが暗号化されている場合は要注意です。
復号できない暗号方式だった場合、

技術的に無理に解こうとするのではなく、ユーザーに「初回ログイン時にパスワードを再設定してもらう」 というUX・運用の話もセットで考える必要があります。

ここまでのポイントを整理すると…

• 「シングルサインオン」という言葉は知らなくてOK
  → イメージは「一度ログインしたら、他もそのまま使える世界」
• セイムサインオンとの決定的な違いは
  → ID・パスワードをどこに何個持つか
• 複数ID管理から抜け出す最初の一歩は
  → IDの棚卸し → ID基盤を作るor使うを決める → 小さく始める

細かいプロトコルの名前（SAML、OAuth2.0、OpenID Connect…）は、
正直、営業や企画の立場では覚えなくても大丈夫です。

大事なのは、

• ユーザーにどんな体験をしてもらいたいか
• 管理側の運用をどれだけ楽に、どれだけ安全にしたいか

という「ゴールのイメージ」です。

そのイメージさえ共有できれば、あとは技術側が

• どの方式を使うか
• どのサービス（Entra ID、IDaaS、Keycloakなど）を組み合わせるか

を具体化していきます。

もし社内で、

「とにかくIDとパスワードが多すぎて管理できない」
「退職者のアカウント消し忘れが怖い」

といった声が出ているようであれば、
それはシングルサインオンを検討し始める、ちょうど良いタイミングかもしれません。