SAML連携とは？仕組みと設定の流れをわかりやすく解説

投稿日 2026年11月9日
著者筒井咲妃
カテゴリー SSOとID管理

SaaSの利用が広がるなか、「SAML連携でSSOを実現したいが、何をどう設定すればよいのか分からない」という情報システム担当者の方も多いのではないでしょうか。

本記事では、SAML連携の仕組み（IdP・SP・SAMLアサーション）から、メタデータ交換や属性マッピングといった設定の流れ、導入時の注意点までをわかりやすく解説します。

結論から言うと、SAML連携は「IdPとSPがメタデータを交換し、IdPが発行したアサーションをSPが検証する」ことで成り立っており、設定のポイントはメタデータ交換・属性マッピング・証明書管理の3つです。

SAML連携とは

SAML連携の仕組み

SAML連携の詳細をご説明する前に、まず登場人物をご紹介しましょう。

登場人物	役割	代表例
IdP	ユーザーを認証し、認証結果を含むアサーションを発行する側	Microsoft Entra ID（旧Azure AD）、Okta
SP	IdPから受け取ったアサーションを検証し、サービスへのアクセスを許可する側	Salesforce、Slack
ユーザー	IdPで認証を行い、SSOを利用してSPのサービスにログインする人	従業員、サービス利用者など

認証フローの2種類（IdP Initiated／SP Initiated）

SAMLによるSSOの開始方法には、大きく分けて2つのパターンがあります。

* IdP Initiated（IdP起点型）

IdP側からログインフローを開始する方式です。社内ポータルサイトにアイコンが並んでいて、そこをクリックすると各SPにログインできる、というような使われ方が一般的です。社内システムのハブから各種SaaSへアクセスする運用で多く見られます。

* SP Initiated（SP起点型）

ユーザーがSP（利用したいサービス）のログイン画面にアクセスした際、自動的にIdPのログイン画面へリダイレクトされる方式です。
認証後、再びSPへ戻ってログインが完了します。ユーザーがサービスのURLを直接ブックマークして利用するケースに対応しやすく、実務ではこちらの方が広く利用されています。

SAMLアサーションとは

SAML連携における認証結果の受け渡しは、「SAMLアサーション」と呼ばれるデータを通じて行われます。

アサーションとは、IdPが発行する「このユーザーは確かに認証済みである」ということを証明する、電子署名付きのXML文書です。
改ざんを防ぐために署名が付与されており、SP側はこの署名を検証することで、なりすましなどのリスクを防いだうえで認証結果を信頼できます。

アサーションには主に以下の情報が含まれます。
➢ ユーザーID（NameIDなど、ユーザーを識別する情報）
➢ 有効期限（アサーションが有効な時間範囲)
➢ 属性情報（メールアドレスや所属部署など、SP側で利用する付加情報)

SAML連携の設定に必要なもの

ここからは、実際にIdPとSPを接続する際に必要となる設定項目を見ていきます。

メタデータの交換

SAML連携の設定は、一般的にIdPとSPがそれぞれの「メタデータ」というXMLファイルを交換してお互いの設定情報を共有するところから始まります。
メタデータには、主に以下の要素が含まれます。

エンドポイントURL（ログインやログアウトの受け口となるURL）

証明書（電子署名の検証に使う公開鍵証明書）

エンティティID（IdP・SPそれぞれを一意に識別するID）

多くのIdP・SPはこのメタデータをXMLファイルとしてダウンロードでき、相手側の管理画面にアップロードするだけで基本設定が完了する仕組みになっています。

IdP側の設定項目

IdP側では、主に以下の設定を行います。

SPのエンティティID・ACS（Assertion Consumer Service）URLの登録

ACS URLは、IdPが発行したアサーションをSPが受け取るためのエンドポイントです。この登録が誤っていると、認証後にアサーションが正しく届かず、ログインエラーの原因になります。

送信する属性のマッピング設定

NameID（ユーザーを一意に識別する値）やメールアドレスなど、SPに送信する属性項目を設定します。SP側が求める属性とIdP側が保有する属性を正しく対応付ける作業であり、ここでの設定ミスはログイン後の権限不整合などにつながる可能性がありますので十分注意しましょう。

SP側の設定項目

SP側では、主に以下の設定を行います。

IdPのSSO URL・証明書の登録

ユーザーをIdPの認証画面へリダイレクトするためのURLと、アサーションの署名を検証するための証明書を登録します。

NameIDフォーマットの指定

ユーザー識別子の形式を指定します。「emailAddress」（メールアドレス形式）や「persistent」（恒久的な一意識別子）など、SPの仕様に応じて適切な形式を選ぶ必要があります。

SAML連携の設定手順

SAML連携の設定は、大きく5つのステップで進めます。

連携するSPのSAML対応状況を確認する
SPがSAMLに対応しているかを確認します。プランによって対応可否が異なり、上位プランでのみ利用できるサービスもあるため、契約中のプランも合わせてチェックしましょう。

IdPにSP（アプリ）を登録する
IdPの管理画面で、連携するSPをアプリケーションとして登録します。

メタデータを交換する
IdPとSPの間で、次の情報を相互に登録します。お互いを信頼できる相手として認識させる大切な作業です。
・エンティティID
・ACS URL
・証明書

属性マッピング・NameIDを設定する
メールアドレスや氏名などの属性を、SPが求める形式でIdPから渡せるようにマッピングします。ユーザーを一意に識別するNameIDもここで決めます。

テストユーザーで動作確認し、本番展開する
まず少人数のテストユーザーでSSOログインを確認し、問題がなければ本番のユーザーへ展開します。いきなり全社に展開しないことが、トラブルを防ぐポイントです。

SAML連携のメリット

SAML連携を導入することで、情シス・ユーザー双方に次のようなメリットがあります。

SPごとのパスワード管理が不要

ユーザーはIdPの認証情報だけを管理すればよく、SPごとに個別のパスワードを覚える必要がなくなります。パスワードの使い回しや管理表による管理といった、セキュリティリスクの高い運用からの脱却にもつながります。

セキュリティ強化

電子署名によって認証情報の改ざんや不正な発行を検知できるほか、HTTPSによる通信経路の保護や、必要に応じたアサーションの暗号化により、盗聴や情報漏えいのリスクを低減できます。

ID一元管理

従業員の入社・異動・退職があった際も、IdP側の設定変更だけで、連携している全SPへのログイン認証を即座に遮断・一元制御できます。（※SP側のアカウント自体の自動作成・同期・削除まで行う場合は、別途SCIMなどのプロビジョニング連携が必要）
退職者アカウントの削除漏れといった、情シスにとって頭の痛い問題への対策としても有効です。

SAML連携の注意点・よくある課題

一方で、SAML連携の導入・運用にはいくつかの注意点も存在します。

非対応システムの存在

国産SaaSやオンプレミスで稼働している基幹システムなどは、SAMLに対応していないケースが多く残されています。
例：勤怠管理・経費精算・基幹システムなど

設定ミスのリスク

証明書の有効期限切れや、ACS URLの入力誤りなど、些細な設定ミスがSSO全体の停止につながることがあります。特に証明書には有効期限があるため、更新を忘れると突然ログインできなくなるトラブルが起こりがちです。

IdP障害時の影響

IdPが停止すると、連携しているすべてのサービスにログインできなくなります。IdPは認証の「一点集中」となる仕組みであるがゆえに、可用性の確保・冗長化が運用上の重要なポイントとなります。

SAML連携に対応したソリューション

前述の通り、SAML連携を進めるうえで多くの情シス担当者が直面するのが「SAML非対応システムがある」という課題です。

このような課題を解決するのが、KeygatewayT1です。

KeygatewayT1は、SAML非対応のシステムをSAML連携可能にするアダプターツールです。原則として既存の社内システムを改修せずに、SAML非対応のシステムもSSO環境に組み込める点が大きな強みです。
「一部のシステムだけがSAMLに対応していないせいで、全社SSO化が進まない」などの課題をお持ちの方は、ぜひご検討ください。

SAML非対応システムをSSO化する『KeygatewayT1』の詳細はこちら