シングルサインオンとは？仕組み・業界別導入ポイント・失敗パターンを解説

シングルサインオン(SSO:Single Sign-On)とは、1回の認証で、連携している複数のシステムやクラウドサービスにログインできる仕組みです。IDとパスワードの確認をIdPと呼ばれる1か所に集めることで、ログインの手間とパスワードの使い回しを減らせます。総務省の令和7年版情報通信白書によれば、2024年にクラウドサービスを利用している企業は80.6%で、複数のSaaSを並行して使う働き方は標準になりました。一方でSSOは入れれば終わりの仕組みではなく、認証基盤が止まると全社のログインが止まるといった運用上のリスクもあります。本記事では、仕組みと認証・認可の違い、認証方式の違い、WindowsとAWSでのSSO、業界別の導入ポイント、メリット・デメリット、失敗パターンと導入ステップを整理します。

目次

開く

閉じる

1. シングルサインオンとは｜1回の認証で複数サービスにログインできる仕組み
2. 認証方式の種類(SAML認証・フェデレーション・エージェント・代理認証・リバースプロキシ)
3. WindowsとAWSでのシングルサインオン｜自社の環境で何が使えるか
4. 業界別の導入ポイント(製造業・医療・教育・金融等)
5. 導入のメリット・デメリット
6. 導入時によくある失敗パターン
7. 導入ステップとチェックリスト｜シングルサインオンのやり方
8. よくある質問(FAQ)
9. まとめ
10. 参考文献

シングルサインオンとは｜1回の認証で複数サービスにログインできる仕組み

シングルサインオンとは、利用者が1回だけ本人確認(認証)を受ければ、連携している複数のシステムやクラウドサービスに、改めてIDとパスワードを入力せずにログインできる仕組みです。朝一番にSSOの画面でログインすれば、その日に使うメール、チャット、勤怠、経費精算などへ個別のログイン操作なしでアクセスできます。「SSO機能」と呼ばれるものは、この仕組みを製品やクラウドサービスの中で実現する機能を指します。

SSOを構成する2つの役割(IdPとSP)

利用者の本人確認を一手に引き受けるシステムをIdP(アイデンティティプロバイダー)、ログイン先の各サービスをSP(サービスプロバイダー)と呼びます。利用者がSPにアクセスすると、SPは自分でパスワードを確認せずIdPに本人確認を依頼し、IdPから「認証済み」という証明を受け取ってログインを許可します。「シングルサインオンサーバー」と呼ばれるものは、このIdPや認証サーバーのことです。

認証と認可の違い

認証は「この人が本人であること」を確認すること、認可は「本人にどのサービスや情報へのアクセスを許すか」という権限を与えることです。SSOは認証をまとめる仕組みですが、実際には認証済みの利用者に、部署や役職に応じてどのサービスの利用を許可するかという認可の設計とセットで運用します。

SSOの認証基盤を自社で運用するときに見落としやすい、監視とAWS環境の管理

IDaaSなどのクラウド型SSOでは認証基盤の稼働は提供者が管理しますが、認証の中継サーバーや自社構築の認証基盤をAWSなどのクラウド上で動かす場合は、夜間や休日に止まったときに誰が気づくかを自社で決める必要があります。AWSを複数のアカウントに分けて使う会社では、アクセス管理に加えて利用料の請求事務も分かれがちです。この2点を外部に任せる手段として、ビジネスコンシェルジュに掲載されている2つのサービスを役割の違いで整理しました。SSOを実現する製品ではなく、AWS上で動かす場合の運用側のサービスです。AWSを使っていない会社は、この節は読み飛ばして構いません。

AWS上で認証の中継サーバーなどを動かしていて、夜間や休日の監視に人手を割けない場合の一例が、GMOグローバルサイン・ホールディングス株式会社が提供する「AWS監視・運用 マネージドクラウド for AWS」です。AWSの運用保守・監視・障害対応を代行するサービスで、24時間365日の有人監視体制を備えると商品ページに記載されています。注意したいのは、プランによってはAWS請求代行の契約が必要になる点と、最低利用期間が設けられている点で、監視の対象が認証基盤のソフトウェアまで含むかどうかは資料や公式サイトで確認してください。料金はプランによって異なるため、資料や公式サイトで確認してください。

「グループ全体の業務拡大に伴い、システムの数も増えてきましたが、個別に構築してきたシステムも多く、監視や運用の環境が統一されておらず、煩雑化、属人化が進んでいました。」

出典：CloudCREW byGMO 導入事例(イグニション・ポイント フォース株式会社)

認証方式の種類(SAML認証・フェデレーション・エージェント・代理認証・リバースプロキシ)

SSOの実現方法は1つではなく、連携先のシステムがどの規格に対応しているかによって使える方式が変わります。クラウドサービス中心ならSAMLなどの標準規格を使うフェデレーション方式、標準規格に対応していない古い社内システムが残るなら代理認証やリバースプロキシというように、方式の特徴を理解しておくと、導入後に「つながらないアプリ」が見つかる事態を避けやすくなります。

SAML認証

SAML(Security Assertion Markup Language)は、IdPとSPの間で認証結果を安全にやり取りするための標準規格です。利用者がIdPで認証を受けると、IdPは「この利用者は認証済みである」という情報を、改ざんされないよう電子署名を付けたデータ(アサーション)としてSPに渡します。SPはパスワードそのものを受け取らないため、各サービスにパスワードを保存しておく必要がなくなります。多くの法人向けクラウドサービスがSAMLに対応しており、クラウド中心の環境で最も広く使われている方式です。

フェデレーション方式

フェデレーション方式は、SAMLのほか、OpenID ConnectやOAuthといった標準的な仕組みを使い、組織やドメインをまたいで認証情報を連携させる方式の総称です。SAML認証はその代表例にあたります。OpenID Connectはスマートフォンアプリや新しいWebサービスで採用が広がっている規格で、連携先がどの規格に対応しているかを確認することが方式選定の第一歩です。

エージェント方式

エージェント方式は、Webサーバーやアプリケーションサーバーにエージェントソフトをインストールし、認証サーバーと連携してログイン状態やアクセス権限を確認する方式です。ネットワーク構成を変えずに導入しやすい一方、エージェントの導入と更新の手間がかかり、アプリケーションがエージェントに対応していなければ使えません。

代理認証方式

代理認証方式は、利用者に代わって、あらかじめ登録しておいたIDとパスワードを各システムのログイン画面に自動入力する方式です。標準規格に対応していない古い業務システムでもSSOに近い使い勝手を実現できる点が強みです。一方で、各システムのパスワード自体は残り続けるため、認証サーバー側のIDとパスワードとの同期や定期的な管理が必要です。

リバースプロキシ方式

リバースプロキシ方式は、利用者のブラウザとWebアプリケーションの間に中継サーバーを置き、そこで認証を代行する方式です。個々のアプリケーションにエージェントを入れずに済む反面、すべての通信が中継サーバーを通るため、負荷が集中して性能や障害のボトルネックになり得ます。プロキシそのものの仕組みを確認したい場合は、プロキシ(ぷろきし)とは？4種類の見分け方とVPN・SWGとの違い、効果の確認方法を解説も参考になります。

方式	仕組み	長所	短所・注意点	向いている環境
SAML認証	IdPが署名付きの認証結果をSPに渡す	SPにパスワードを置かずに済む。法人向けクラウドの対応が多い	連携先がSAMLに対応している必要がある。サービスによっては上位プランでのみ対応	クラウドサービス中心
フェデレーション方式(OpenID Connect等を含む)	標準規格で組織・ドメインをまたいで認証を連携	スマートフォンアプリや新しいWebサービスにも対応しやすい	規格ごとの設定知識が必要	クラウドとモバイルの併用
エージェント方式	サーバーに入れたエージェントが認証サーバーと連携して認証を確認	ネットワーク構成を変えずに導入しやすい	エージェントの導入・更新が必要。対応していないアプリでは使えない	自社で管理するWebサーバーが多い環境
代理認証方式	登録済みのIDとパスワードを自動入力	標準規格非対応の古いシステムにも使える	各システムのパスワード管理と同期が残る	古い社内システムが残る環境
リバースプロキシ方式	中継サーバーが認証を代行	個々のアプリにエージェントを入れずに済む	中継サーバーが性能や障害のボトルネックになり得る	社内Webシステム中心

実際の導入では、1つの方式だけで全システムをまかなえることは多くありません。クラウドサービスはSAML、古い社内システムは代理認証というように、方式を組み合わせて対応範囲を広げるのが現実的です。候補となるSSO製品やIDaaSが、どの方式にどこまで対応しているかは、選定時に必ず確認したい項目です。

SSOとIDaaS・多要素認証の関係

SSOと混同されやすい言葉に、IDaaS(Identity as a Service)と多要素認証(MFA)があります。IDaaSは、SSOに加えてIDの一元管理、多要素認証、アクセス制御、ログ管理などをクラウド上でまとめて提供するサービスの総称で、SSOはその中心的な機能の1つです。多要素認証は、パスワードに加えて、スマートフォンの認証アプリ、SMSで届くコード、生体情報など、複数の要素で本人確認する方法です。SSOは「ログインの回数を減らす」仕組み、多要素認証は「1回のログインを強くする」仕組みであり、目的が異なるため実務では組み合わせて使います。

用語	役割	SSOとの関係
SSO	1回の認証で複数サービスにログインできるようにする	本記事のテーマ
多要素認証(MFA)	複数の要素で本人確認を強化する	SSOの入口となる1回のログインを守るために組み合わせる
IDaaS	ID管理・SSO・MFA・アクセス制御をクラウドで一括提供する	SSOを実現する代表的な提供形態の1つ

WindowsとAWSでのシングルサインオン｜自社の環境で何が使えるか

WindowsではMicrosoft Entraのシームレスシングルサインオンなど、AWSではAWS IAM アイデンティティセンターが、それぞれの環境でSSOを実現する代表的な仕組みです。自社の中心がWindows・Microsoft 365なのか、AWS上のシステムなのかによって、最初に確認する機能が変わります。

Windowsのシングルサインオン

Microsoftの公式ドキュメントによれば、Microsoft Entraのシームレスシングルサインオンは、企業ネットワークに接続された会社のデバイスを使うとき、ユーザーが自動的にサインインされる機能です。有効にすると、Microsoft Entra IDにサインインするためのパスワード入力が不要になります。利用にはデバイスがドメインに参加している必要があり、Windows 10以降のMicrosoft Entra参加済みデバイスなどでは、プライマリ更新トークンを介したSSOが使われます。シームレスSSOは便宜的な機能とされ、何らかの理由で失敗した場合はパスワードを入力する通常のサインインに戻ります。対応する構成やブラウザは更新されるため、導入前に公式の最新情報で確認してください。

AWSのシングルサインオン(AWS IAM アイデンティティセンター)

AWSのシングルサインオンは、2022年7月26日に「AWS シングルサインオン」から「AWS IAM アイデンティティセンター」へ名称が変わりました。AWSの公式ドキュメントによれば、複数のAWSアカウントへのワークフォースのアクセスを一元管理でき、既存のIDプロバイダーを接続してユーザーやグループを同期できます。SAML 2.0のIDプロバイダーを使う場合、必要なフェデレーションは1回のみで、管理する証明書も1つで済みます。つまり、本記事で説明したIdPとSPの考え方が、AWSアカウントへのログインにもそのまま当てはまります。

ただし、SSOで入口をそろえても、AWSのアカウントが増えるほど利用料の請求書や支払いの事務は別に残ります。AWSを複数のアカウントで使っていて、利用料の支払い事務が分かれている場合の一例が、GMOグローバルサイン・ホールディングス株式会社が提供するCloudCREW byGMOを通じた「CloudCREW AWS請求代行」です。AWSの利用料を円建ての請求書と銀行振込で支払える法人向けサービスで、請求書は月末締めで毎月メールで届き、管理画面のクラウドポータルで請求金額や契約者情報を一元管理できると商品ページに記載されています。注意したいのは、監視や運用のサービスは有料オプション扱いである点と、申込から利用開始まで1か月以上かかる場合がある点です。料金はプランによって異なるため、資料や公式サイトで確認してください。

なお、ここで取り上げた2つのサービスは、いずれもSSOそのものを提供するものではありません。SSOの仕組みは製品や環境によって異なるため、AWSを使っていない会社は、この節のサービス紹介は読み飛ばして構いません。

業界別の導入ポイント(製造業・医療・教育・金融等)

SSOで優先すべき論点は業界によって大きく異なり、「利便性をどこまで優先し、認証の強さをどこまで求めるか」の線引きが変わります。多くの解説記事はSSOを業種共通の仕組みとして説明していますが、実際の導入では、扱う情報の機密性、端末の使われ方、既存システムの年代といった業種特有の事情が、方式や運用の設計を左右します。

製造業：古い社内システムと共用端末への対応

製造業では、生産管理や設計、品質管理などの業務システムが長年使われており、標準規格に対応していないものが残っていることが少なくありません。そのため、SAML対応のクラウドサービスと、代理認証やリバースプロキシで連携する社内システムが混在する構成になりやすい点が特徴です。また、工場では複数の作業者が1台の端末を交代で使うことも多く、「誰がログインしたままになっているか」が曖昧になりがちです。共用端末では、一定時間操作がなければ自動でログアウトする設定や、ICカードなどで素早く利用者を切り替えられる仕組みを検討すると、利便性と記録の正確さを両立しやすくなります。

医療：患者情報を扱う端末の認証強化

医療機関では、電子カルテなど患者の個人情報を扱うシステムへのアクセス管理が重要です。厚生労働省の「医療情報システムの安全管理に関するガイドライン」は、2026年6月に見直された第7.0版が公表されており、概説編・経営管理編・企画管理編・システム運用編・保守委託機関編で構成されています。医療現場では診察の合間に短時間で端末を使う場面が多く、ログインに手間がかかると共有アカウントの利用など運用上の抜け道が生まれやすくなります。SSOでログインの回数を減らしつつ、ICカードや生体認証と組み合わせて本人確認を強くすること、職種や診療科ごとにアクセスできる情報を絞ることが、設計の要になります。認証やアクセス管理に関する具体的な要求事項は、ガイドラインの原文で確認してください。個人情報の取扱いについては、個人情報保護委員会の医療・介護関係事業者向けガイダンスもあわせて確認しておきたい資料です。

教育：利用者数の多さと年度替わりのアカウント管理

学校などの教育機関では、教職員に加えて多数の児童・生徒・学生がクラウドサービスを利用します。文部科学省の「教育情報セキュリティポリシーに関するガイドライン」は令和7年3月版が最新で、教育委員会などが情報セキュリティポリシーを策定・見直す際の参考として公開されています。教育分野の特徴は、利用者の数が多く、進級・卒業・異動によって毎年大量のアカウントの追加・変更・削除が発生することです。低学年の児童にとっては、複数のパスワードを覚えること自体が負担になります。SSOで学習用サービスへのログインを1回に集約するとともに、名簿データと連携してアカウントの発行と停止を自動化できるかが、運用負担を左右するポイントです。

金融：アクセス経路の制限と権限管理の厳格化

金融機関では、顧客の資産や取引に関わる情報を扱うため、認証とアクセス管理に高い水準が求められます。金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」(令和6年10月4日)は、認証・アクセス管理の基本的な対応事項として、重要なシステムへのリモートアクセスには多要素認証を使うこと、特権アカウントの利用を厳格に制限し管理することを挙げています。あわせて、シングルサインオンや外部認証連携のように、システム間やセキュリティ境界にまたがる認証・認可で、機密性、完全性、真正性などを確保することも求めています。金融分野のSSOでは利便性よりも統制が優先される場面が多く、多要素認証の必須化に加えて、許可された端末やネットワークからのみアクセスを認める制限、退職・異動時の権限の即時停止などを組み合わせて設計するのが一般的です。

業界	主な課題	重視したい機能・設計	参考になる公的資料
製造業	標準規格非対応の社内システム、共用端末	代理認証への対応、自動ログアウト、利用者の素早い切り替え	IPA「情報セキュリティ10大脅威 2026」(業種共通)
医療	患者情報の保護、短時間での端末利用	ICカード・生体認証との組み合わせ、職種別のアクセス制御	厚生労働省「医療情報システムの安全管理に関するガイドライン」第7.0版
教育	利用者数の多さ、年度替わりの大量更新	名簿連携によるアカウントの自動発行・停止	文部科学省「教育情報セキュリティポリシーに関するガイドライン」令和7年3月版
金融	高い統制水準、特権アカウントの管理	多要素認証の必須化、端末・ネットワーク制限、権限の即時停止	金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」

IPAの「情報セキュリティ10大脅威 2026」の組織向け脅威には、内部不正による情報漏えい等(7位)や、リモートワーク等の環境や仕組みを狙った攻撃(8位)が入っています。どの業界にも共通するのは、入社・異動・退職のタイミングでアカウントと権限を確実に変更できるかという論点です。なお、ここで紹介した内容は一般的な考え方の整理であり、各ガイドラインの具体的な要求事項は原文で確認してください。

導入のメリット・デメリット

SSOのメリットは「利便性」「セキュリティ」「管理負担」の3つの面で同時に効果が出やすいことで、デメリットは認証が1か所に集中することによるリスクです。メリットだけを見て導入すると、デメリットへの備えが後回しになりがちなため、両方を並べて判断することが大切です。

主なメリット

• 利便性の向上：1日に何度も発生するログイン操作とパスワード入力の手間が減り、本来の業務に集中しやすくなる
• セキュリティの強化：利用者が管理するパスワードが実質1つになり、使い回しや書き残しを減らせる。入口の認証を多要素認証で強化しやすい
• 管理負担の軽減：パスワード忘れによる問い合わせ対応が減り、入退社時のアカウント発行・停止を1か所で行いやすくなる
• 利用状況の可視化：誰がいつどのサービスにログインしたかを集約して確認しやすくなり、不審なアクセスに気づきやすくなる

主なデメリット

• 認証情報が漏えいした場合の影響範囲が広い：SSOの認証情報が破られると、連携するすべてのサービスに不正アクセスされるおそれがある
• 認証基盤が止まると全体が止まる：IdPに障害が起きると、連携先のサービスにまとめてログインできなくなる
• すべてのサービスが対応しているとは限らない：標準規格に対応していないシステムや、上位プランでのみSSOに対応するサービスがある
• 導入と運用に費用と手間がかかる：製品の利用料に加え、設定作業や、利用者への説明・問い合わせ対応の体制づくりが必要になる

デメリットを小さくする対策

デメリットの多くは、入口の強化、アクセス経路の制限、障害時の備えの3つで軽減できます。入口の強化では、多要素認証やワンタイムパスワードを必須にし、特に管理者や特権アカウントは厳格に管理します。アクセス経路の制限では、許可したIPアドレスや端末からのみ利用できるようにして、万一パスワードが漏れても不正に使われにくくします。障害時の備えでは、認証基盤の稼働実績と連絡体制を事前に確認し、緊急時のログイン手順を決めておきます。IDaaSなどのクラウド型を選べば稼働の管理は提供者に任せられますが、中継サーバーや自社構築の認証基盤をAWSなどで動かす場合は、止まったことに気づく監視体制が自社の責任になります。

デメリットの対策は、SSOを「ログインを便利にする道具」ではなく、「社内の本人確認とアクセス管理をひとまとめに設計し直す取り組み」として捉えると考えやすくなります。基本的なメリット・デメリットの整理は、SSO(シングルサインオン)とは？メリット・デメリットなどを解説でも確認できます。

導入時によくある失敗パターン

SSO導入の失敗は、製品選びそのものよりも「事前の確認不足」と「運用設計の後回し」から生まれることがほとんどです。メリット・デメリットの説明だけでは見えにくい失敗を、導入前の状態と対策後の状態で比較して整理します。

失敗パターン	Before(起こりがちな状態)	After(対策後の状態)
1. アプリ側がSSO非対応で個別ログインが残る	契約後に一部の業務システムが標準規格に非対応と判明し、利用者は結局複数のパスワードを管理し続ける	導入前に全システムを棚卸しし、対応方式を一覧化。非対応システムは代理認証で補うか、別の方法での管理を決めておく
2. 代理認証のエージェント導入が負担になる	全端末へのソフト配布や設定に想定以上の工数がかかり、端末ごとに動作が違って問い合わせが増える	代理認証の対象を必要なシステムに絞り、配布手順と対象端末を事前に確定。パイロット部門で動作を検証してから展開する
3. 多要素認証を設定せず入口が弱いまま	SSOのパスワードだけで全サービスに入れる状態になり、漏えい時の被害範囲がかえって広がる	SSOの導入と同時に多要素認証を必須化。管理者アカウントは特に厳しい認証を設定する
4. 障害時の代替手段がない	認証基盤の障害で全サービスにログインできず、業務が止まる。自社運用の場合は止まったことに気づくのも遅れる	サービスの稼働実績や障害時の連絡体制を事前に確認し、緊急時のログイン手順を定めておく。自社運用なら監視と通知の担当を決める
5. 退職者アカウントの停止が手作業のまま	SSOは停止しても、SSO経由でないログイン手段が残り、退職者がアクセスできる状態が続く	人事情報と連携したアカウントの自動停止を検討し、SSO以外のログイン手段を原則として無効化する

特に見落とされやすいのが、1と5の組み合わせです。SSO非対応のシステムが残っていると、そのシステムだけは個別のアカウント管理が続くため、退職時の停止作業から漏れやすくなります。SSOで管理できる範囲と、できない範囲の境界線をはっきりさせておくことが、失敗を防ぐ最大のポイントです。

導入ステップとチェックリスト｜シングルサインオンのやり方

SSOは、いきなり全社に展開するのではなく、棚卸しから始めて小さな範囲で検証し、段階的に広げる進め方が失敗を減らします。一般的な導入の流れは次のとおりです。

1. システムの棚卸し：社内で使っているクラウドサービスと社内システムを一覧化し、それぞれの対応方式(SAML、OpenID Connect、代理認証の要否)と利用部門・利用者数を整理する
2. 要件の整理：SSOの対象範囲、多要素認証の方法、アクセスを許可する端末やネットワーク、ログの保管期間、業界ガイドラインで求められる水準を決める
3. 製品の比較と検証：候補となるSSO製品やIDaaSを比較し、無料トライアルなどで主要システムとの連携を実際に確認する
4. パイロット導入：情報システム部門や管理部門など、1から2部署で先行導入し、問い合わせ内容や設定の不具合を洗い出す
5. 全社展開と定着：利用者向けの手順書を整え、段階的に対象部署を広げる。展開後は権限の定期見直しと退職者アカウントの確認を続ける

製品を選ぶときの確認観点

観点	確認すること
提供形態	オンプレミス型は自社の利用状況に合わせてカスタマイズしやすい。クラウド型は設定だけで短期間に導入でき、費用はユーザー数に連動する場合が多い
連携できる範囲	既存の業務システムや、将来導入予定のサービスが、どの方式で連携できるか。社内のActive Directoryなどのディレクトリを使えるか
運用のしやすさ	アプリケーションの追加や、問題が起きたときのログ確認が扱いやすいか
サポート体制	導入時の支援があるか。海外製品は日本語対応と日本時間のサポートがあるか

主要なSSO製品の特徴を横並びで確認したい場合は、おすすめのSSO(シングルサインオン)製品4選｜選び方も解説も参考になります。導入前に確認しておきたい項目を、チェックリストとしてまとめます。

確認項目	確認の観点
対象システムの対応状況	全システムの対応方式を一覧化し、非対応システムの扱いを決めたか
多要素認証	全利用者、特に管理者アカウントに多要素認証を必須化する方針か
アカウントのライフサイクル	入社・異動・退職時の発行と停止の手順、担当者、所要時間を決めたか
障害時の対応	稼働実績と障害時の連絡体制を確認し、緊急時のログイン手順を定めたか
ログの取扱い	ログイン履歴の保管期間と閲覧権限、利用目的を社内規程に定めたか
業界ガイドライン	自社の業界に関係する公的ガイドラインの要求事項を確認したか
利用者への周知	手順書と問い合わせ窓口を用意し、パイロット導入で分かりにくい点を修正したか

ログイン履歴などのログには、従業員がいつどのサービスを利用したかという情報が含まれます。個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン(通則編)」では、個人データの安全管理措置として、組織的・人的・物理的・技術的な措置を講じることが求められています。ログをどの目的で、どの期間保管し、誰が閲覧できるかを事前に整理しておくと安心です。本記事は一般的な情報提供を目的としたもので、法的助言ではありません。個別の判断は専門家に相談してください。

ここまでの内容を、自社の状況に引き寄せて確認できるセルフチェックを用意しました。当てはまる数が多いほど、導入前の整理と運用体制の見直しが必要なサインです。

よくある質問(FAQ)

Q1. シングルサインオンとは何ですか？

A. 1回の認証で、連携している複数のシステムやクラウドサービスに、改めてIDとパスワードを入力せずにログインできる仕組みです。本人確認をIdPと呼ばれる1か所に集め、各サービスはその認証結果を信頼してログインを許可します。

Q2. シングルサインオンサーバーとは何ですか？

A. SSOの本人確認を担うIdP(認証サーバー)のことです。利用者はまずこのサーバーで認証を受け、連携先の各サービスは、サーバーから届く「認証済み」の証明を信頼してログインを許可します。クラウド型のIDaaSでは提供者が運用し、自社で構築する場合は稼働の監視や障害対応も自社の担当になります。

Q3. SAML認証と代理認証方式の違いは何ですか？

A. SAML認証は、IdPが署名付きの認証結果をサービスに渡す標準規格で、各サービスにパスワードを置かずに済みます。代理認証方式は、登録済みのIDとパスワードを自動入力する方式で、標準規格に対応していない古いシステムにも使えますが、各システムのパスワード管理は残ります。

Q4. シングルサインオンのデメリットは何ですか？

A. 認証が1か所に集中するため、認証情報が漏えいすると連携先すべてに影響が及ぶおそれがあることと、認証基盤の障害時にまとめてログインできなくなることが主なデメリットです。多要素認証の必須化と、障害時の代替手段の用意で軽減するのが一般的です。

Q5. Windowsのシングルサインオンとは何ですか？

A. Microsoftの公式ドキュメントでは、Microsoft Entraのシームレスシングルサインオンが、企業ネットワークに接続された会社のデバイスで自動的にサインインする機能として説明されています。利用にはデバイスがドメインに参加している必要があり、Windows 10以降のMicrosoft Entra参加済みデバイスなどでは、プライマリ更新トークンを介したSSOが使われます。

Q6. シングルサインオンのやり方(導入手順)を教えてください

A. 一般的には、システムの棚卸し、要件の整理、製品の比較と検証、1から2部署でのパイロット導入、全社展開と定着の順に進めます。いきなり全社に展開せず、非対応のシステムや利用者の混乱を小さな範囲で洗い出してから広げるのが、失敗を減らすコツです。

まとめ

シングルサインオンは、1回の認証で複数のサービスにログインできるようにする仕組みで、クラウドサービスの利用が当たり前になった今、利便性とセキュリティを両立させる基盤として注目されています。導入を成功させるために、次の4つを押さえておきましょう。

1. 社内の全システムを棚卸しし、SAML、フェデレーション、エージェント、代理認証など対応方式を一覧化する
2. WindowsやAWSなど自社の環境と、業界の公的ガイドラインを踏まえて、認証の強さとアクセス制御の水準を決める
3. 多要素認証の必須化と障害時の代替手段をセットで設計し、パイロット導入から段階的に広げる
4. 認証基盤をAWS上で自社運用する場合は、監視体制と利用料の請求事務を外部に任せる選択肢も、資料で比べて検討する

SSOは導入すること自体が目的ではなく、社内の本人確認とアクセス管理を整理し直すための取り組みです。まずは現在使っているシステムの一覧づくりから始めてみてください。

参考文献

• 総務省「令和7年版 情報通信白書 クラウドサービス」https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd111210.html
• IPA(独立行政法人情報処理推進機構)「情報セキュリティ10大脅威 2026」https://www.ipa.go.jp/security/10threats/10threats2026.html
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
• 個人情報保護委員会「医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンス」https://www.ppc.go.jp/personalinfo/legal/iryoukaigo_guidance/
• 厚生労働省「医療情報システムの安全管理に関するガイドライン」https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html
• 文部科学省「教育情報セキュリティポリシーに関するガイドライン」https://www.mext.go.jp/a_menu/shotou/zyouhou/detail/1397369.htm
• 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(令和6年10月4日)https://www.fsa.go.jp/common/law/cybersecurity_guideline.pdf
• Microsoft Learn「Microsoft Entra Connect: シームレス シングル サインオン」https://learn.microsoft.com/ja-jp/entra/identity/hybrid/connect/how-to-connect-sso
• AWS「AWS IAM アイデンティティセンターとは」https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/what-is.html