ID・パスワードを増やしたくない方へ：シングルサインオンを、用語を抑えて理解する
- シングルサインオンという言葉は聞いたことがあるが、内容を整理できていない
- 社内や自社サービスで、システムごとに別々のID・パスワードを利用している
- 同一IDで統一し、ログイン回数や管理工数を減らしたい
本記事では、次の3点を整理します。
- シングルサインオンの考え方を、専門用語を最小限にして説明する
- 混同されやすいセイムサインオンとの違いを、構造の観点で整理する
- 複数ID管理から移行する際、検討初期に押さえたい3ステップを提示する
目次
用語より先に共有すべきポイント
現場で最初に挙がる相談は、次のような内容が中心です。
「利用サービスが増え、IDとパスワードがシステムごとに分かれている」
「一度ログインした後は、別のサービスも追加の入力を減らして利用したい」。
この段階では、名称を先に確定するよりも、実現したい利用体験と運用上の課題を共有できていることが重要です。
本記事では、まず判断するポイントを明確にしたうえで、必要な用語のみ補足します。
SSOや認証基盤の設計・開発について詳しく知りたい方は、LYZONのSSO・認証基盤連携の詳細もあわせてご覧ください。
複数ID・パスワード管理で増える負荷とリスク
複数システムにそれぞれ別のIDでログインしていると、次のような状態になりやすくなります。
- システムA：メールアドレス＋パスワードA
- システムB：社員番号＋パスワードB
- システムC：ID＋パスワードC
この状態で増えやすいのは、感覚的な「大変さ」ではなく、次のような具体的な増加要因です。
- 利用者側：入力ミスや再発行依頼が増える（組み合わせが増えるため）
- 管理側：パスワード再発行の問い合わせ対応が増え、運用工数が増える
- アカウント管理：退職者・異動者のアカウント停止における確認対象が増え、停止漏れが起きるリスクが上がる
- 事故対応：調査範囲が広がり、原因切り分けに必要な時間と関係者調整が増える
以降の話を整理しやすくするためにも、「何が増えるのか（作業量／確認対象／切り分け時間）」を先に固定しておくと整理が進みます。
一度のログインで複数システムを利用する仕組み
目指す状態は、最初のログイン以降、別システムへ移動しても追加の入力を最小限にして利用できる状態です。
身近な例としては、次のような体験があります。
- 会社PCにログイン後、OutlookやTeams、業務アプリを追加の入力なしで利用できる
- Googleアカウントでログイン後、Gmailやカレンダー、ドライブを連続して利用できる
流れは次のとおりです。
- 最初の1回だけ認証を行う
- 以降は同一利用者であることをシステム間で確認する
- 利用者は都度のID・パスワード入力を減らして利用できる
この考え方が、シングルサインオンです。以降は必要に応じてSSO（Single Sign-On）という略称も併記します。
セイムサインオンとの違い
混同されやすい概念として、セイムサインオン（Same Sign-On）があります。見た目は似ていますが、内部構造が異なります。
セイムサインオンは、各システムのユーザーDBに同じID・パスワード情報を複製して保持する運用です。そのため保持先が増えます。
- Aシステム用のユーザー情報
- Bシステム用のユーザー情報
- Cシステム用のユーザー情報
この構造では、運用上の論点が増えやすくなります。
- パスワード変更：全システムへ変更を反映するための連携処理・確認項目が増える
- アカウント停止：停止漏れを防ぐためのチェック対象・チェック手順が増える
- セキュリティ事故：侵害範囲の特定に必要なログ確認や関係者調整が増える
整理のポイントは、「同じID・パスワードで入れるか」ではなく、ID・パスワードの保持先と保持数です。
シングルサインオンの基本構造
シングルサインオンでは、ID・パスワードを各システムに持たせず、認証基盤にまとめて管理します。
- ID・パスワードは認証基盤にまとめる
- 各システムは認証基盤へ照会し、本人確認結果を受け取る
- 認証基盤が利用者を特定し、利用可否を返す
- 認証基盤：IDやパスワードなどの認証情報をまとめて管理し、各システムへ認証結果を返す仕組みを指します。
ここでの判断軸は次の1点です。
「ID・パスワードを、どこに、いくつ保持するか」
- セイムサインオン：各システムに保持する（保持先が複数）
- シングルサインオン：認証基盤にまとめる（各システムは参照する）
複数ID管理から移行するための3ステップ
技術方式の詳細に入る前に、検討初期で前提を揃えることが重要です。前提が曖昧なまま進めると、後工程で調整が増え、手戻りが発生しやすくなります。
ステップ1：IDと対象システムの洗い出し
次の観点で「対象」を決めます。
- 対象システム：社内／社外／クラウドサービスを列挙する
- IDの種類：IDとして何を使っているか（メールアドレス、社員番号など）
- 管理場所：どこで管理しているか（AD、独自DB、表計算ファイルなど）
- 利用者区分：どのユーザーがどのシステムを使うか（従業員、取引先、会員など）
- AD：Active Directory。社内のユーザーや権限を一元管理するために利用されることが多いディレクトリサービスです。
ステップ2：ID基盤の方針決定
次の分岐を先に決めます。
- 新しくID基盤（認証基盤）を用意する
- 既存のサービスや基盤を利用する（例：Entra ID、Google Workspace など）
ここを決めずに進めると、見積・スケジュール・設計項目の前提が揃わず、後から調整が増えやすくなります。
ステップ3：適用範囲を絞って開始する
一度に全システムへ適用すると、関係者・調整回数・検証パターンが増え、移行難易度が上がりやすくなります。初期は範囲を絞って進めます。
- まずは2〜3システムから開始する
- 社内利用から適用し、運用手順と問い合わせ対応を整備する
- パスワード移行の方針を決める（ハッシュ化されている場合は特に注意する）
- 必要に応じて、初回ログイン時のパスワード再設定フローを設計する
既存会員DBのパスワードがハッシュ化されている場合、原則として復号できず、従来のパスワードをそのまま移行できないことがあります。
その場合は、技術的な移行可否に加えて、次をセットで設計すると想定外の作業を抑えやすくなります。
- 初回ログイン時に再設定へ誘導する導線
- 再設定に伴う周知、問い合わせ対応、例外対応の運用手順
- 移行期間中のサポート体制と担当範囲
要点整理と導入判断のポイント
シングルサインオン（SSO）は、複数システム利用時のログイン体験を統一し、ID・パスワード管理に伴う運用工数と運用リスクを抑えるための考え方です。
混同されやすいセイムサインオンは、各システムが同一のID・パスワード情報をそれぞれ保持する構造になりやすく、パスワード変更の反映やアカウント停止、事故時の原因切り分けにおいて、確認対象と関係者調整が増える点が検討ポイントになります。判断軸は「ID・パスワードの保持先と保持数」です。
検討初期は、方式名（SAML、OAuth 2.0、OpenID Connect など）を先に覚えるよりも、次の2点を判断できる形に整理することが重要です。
- 利用者に提供したいログイン体験：追加の入力をどこまで減らすか、再認証が必要となる条件は何か
- 管理側で抑えたい運用面の課題：運用工数をどこで減らすか、運用リスクをどこで下げるか（アカウント停止、変更反映、障害時の切り分け手順など）
そのうえで、洗い出し → ID基盤の方針決定 → 適用範囲を絞って開始、の順に前提を揃えると、後工程での調整や手戻りを抑えやすくなります。特に移行時は、技術的な連携に加えて、初回ログイン時の再設定フローや問い合わせ対応を含む運用手順まで設計範囲に含めることが、安定運用につながります。
会員向けサイトや認証を伴うWebシステム構築について知りたい方は、下記ページをご覧ください。
LYZONでは、SSO・認証基盤連携の設計・開発をご支援しています。
複数システムのログイン統一や、認証基盤の整理を検討したい方は、下記ページもあわせてご覧ください。
LYZONのSSO・認証基盤連携開発
ログインの煩雑さが離脱を招きます
複数サービスを横断するSSOの実装から認証基盤設計まで。セキュリティと利便性を両立した構成をご紹介。
SSOに関するよくある質問
Q1. 社内でSSOをどう説明すれば認識がそろいますか？
現場では「同じ利用者として複数サービスを行き来したい」という要望から検討が始まるケースが多いです。
説明時は「最初のログイン以降、同じ利用者であることをシステム側で確認し、追加の入力を減らす仕組み」と定義すると、利用部門・情シス・開発で目的を合わせやすくなります。
Q2. セイムサインオン（Same Sign-On）とSSOの違いは何ですか？
違いは、ID・パスワードが「どこに、いくつ存在するか」です。Same Sign-Onは各システムが同じID・パスワードをそれぞれ保持するため、変更反映や停止対応などで確認対象が増え、運用工数や運用リスクが上がりやすくなります。
SSOは認証基盤（ID基盤）側に集約し、各システムは認証結果を参照する構造です。
Q3. SSO検討の最初に決めるべきポイントは何ですか？
「ID基盤（認証基盤）を新規に用意するか、既存サービスを利用するか」を先に固定すると、見積もり・スケジュール・設計項目の前提が揃います。
あわせて、パスワード移行の制約が出る場合に備え、初回ログイン時の再設定フローと運用手順まで含めて整理しておくことが重要です。
LYZONのSSO・認証基盤連携開発
ログインの煩雑さが離脱を招きます
複数サービスを横断するSSOの実装から認証基盤設計まで。セキュリティと利便性を両立した構成をご紹介。
株式会社LYZONの社内ニュースを始め、デザインの知識やお役立ち情報など様々な情報を発信しています。
