SAMLのシステム開発の完全ガイド

SAMLのシステムは、認証をIdPが担い、業務サービス（SP）がその結果を受け取る仕組みです。導入方式は、クラウド型IDaaS、オンプレミス型、ハイブリッド型から、認証要件と既存環境に合わせて選びます。

仕組みと流れ、費用、選び方、運用を順に説明します。各テーマの詳細は、関連記事もご覧ください。

▼関連記事一覧
・SAMLのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・SAMLのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・SAMLのシステム開発の見積相場や費用/コスト/値段について
・SAMLのシステム開発の発注/外注/依頼/委託方法について

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

SAMLのシステムの全体像

SAMLは、XML形式のアサーションで認証の事実や属性を別のサービスへ伝える標準仕様です。2005年にOASISで承認され、企業向けWebサービスのSSOや組織間の認証連携で使われています（出典: OASIS「Security Assertion Markup Language（SAML）v2.0」、2005年）。

IdPとSPの役割

IdPはIdentity Providerの略で、利用者の本人確認を担当します。社内ディレクトリや人事マスターと連携して、利用者を管理します。

IdPは、パスワードやMFA、端末条件などの認証ポリシーを適用し、認証済みを示すSAML Responseを発行します。

一方で、SPはService Providerの略で、業務SaaSやWebアプリなど、利用者が使うサービスを指します。受け取ったResponseの署名と有効期間を確認し、NameIDや部署、グループを自社のユーザーや権限に結び付けます。

ログインの流れ

SP起点のログインは、利用者の操作からセッション開始まで次の順に進みます。

1. 利用者が業務アプリへアクセスすると、SPはAuthnRequestという認証要求をブラウザ経由でIdPへ送ります。
2. IdPで認証が完了すると、署名付きのSAML ResponseとAssertionをブラウザ経由でSPのACS URLへ返します。
3. SPはResponseを検証し、問題がなければセッションを開始します。

SPは、発行元（Issuer）や宛先（Audience、Destination、Recipient）が自社の設定と合うかを確かめます。また、要求との対応（InResponseTo）、有効期間、署名者の証明書も検証します。

公式技術文書では、HTTP Redirectで要求を送り、HTTP POSTでResponseを返す流れが説明されています（出典: SAML対応の公式技術文書、2025年更新）。

SAMLのシステムの種類と主な機能の比較

SAMLのシステムは、プロトコルと、認証やアカウント管理を担う仕組みを分けて考えると比べやすくなります。

IDaaSと既存認証基盤への統合認証、オンプレミス型、カスタム開発型では、初期費用と運用の負担が異なります。柔軟性や将来の移行しやすさも、方式ごとに違います。

クラウド型IDaaSを利用する方式

クラウド型IDaaSは、SAMLのIdP機能に加えて、MFAやユーザーポータル、監査ログ、プロビジョニングなどを提供します。アプリが増えた場合も、メタデータ交換やテンプレートで設定しやすい方式です。

認証基盤のサーバーや冗長化を自社で持たずに済むので、クラウドサービスを多く使う企業や、少人数で情シスを運営する企業に合った方式です。

契約の前に見ておきたいのは、最低契約ID数、ログ保管期間、アプリ追加費です。SCIMや端末制御が追加料金になるかも、見ておきます。契約を終える際には、データを出力できるかの確認も必要です。

オンプレミス型とハイブリッド型

オンプレミス型は、自社のデータセンターや閉域網に認証基盤を置く方式です。レガシーWebや特殊なネットワーク、厳格なデータ保管要件がある場合に、選びやすい形です。

一方で、サーバーや証明書を自社で管理し続けます。パッチの適用やバックアップ、災害対策も、継続して行う作業です。ハイブリッド型は、標準的な認証やMFAをクラウドへ寄せる方式です。

ハイブリッド型では、古い業務アプリや独自の権限を、アダプター、リバースプロキシ、APIで補います。標準の領域と独自の領域を分けられるため、段階的に移行を進めやすい構成です。

SAMLとOIDC、SCIM、MFAの違い

SAMLは主にブラウザ経由で認証結果や属性を連携するプロトコルです。一方で、OIDCはOAuth 2.0を基盤にIDトークンを扱い、スマートフォンアプリや新規Webサービスに適用しやすい傾向があります。

SCIMは、ユーザーの作成、更新、停止、削除を自動で連携するための仕様で、認証の方式ではありません。MFAは本人確認を強める手段で、SAMLを使っただけでは付きません。

これらは競合する用語ではなく、役割が異なる部品です。そのため、必要に応じて組み合わせて使います。

SAMLのシステム開発・導入の進め方

SAMLの開発や導入では、ログイン画面を差し替える前に、対象ユーザーと接続アプリ、権限を先に定義します。認証の強さや停止の手順も、同じ段階で決めておきます。

小さな対象で検証してから本番へ広げれば、リスクを抑えられます。複数のシステムがある場合は、代表アプリでPoCを行い、属性マッピングと障害時の復旧方法を確かめます。

要件定義で決める項目

まず、社内利用、子会社・取引先とのB2B連携、顧客向けサービスのうち、どれを対象にするかを決めます。続いて、利用者数と接続アプリ数を整理します。既存ディレクトリや人事マスター、レガシーアプリの状況も確かめます。

利用地域、可用性、ログ保存期間の3点は、要件として先に決めます。データ所在地と退職時の停止時間も、あわせて整理します。接続先ごとの仕様を一覧にすると、見積もりとテストが具体的になります。

• 接続情報：Entity ID、ACS URL、Single Logout URL
• 識別・属性：NameID形式、属性名
• 保護方針：署名と暗号化の方針

設計・設定・改修

設計では、どのシステムをIdPにし、どのアプリをSPにするかを決めます。ユーザー識別子は、メールアドレスだけに頼らず、変わりにくい一意のIDを使うか、異動時の再ひも付けルールを用意します。

部署、役職、グループを属性として送る場合は、属性値から権限を自動で付与する範囲を決めておきます。設定・改修では、接続設定から緊急用の経路まで、実装の対象に含めます。

• 接続設定：メタデータ交換、証明書登録、ACSの受け口
• セッション：有効期限、ログアウト、エラー画面
• 緊急経路：ローカル管理者のログイン経路

テスト・移行・リリース

本番への影響を抑えるため、異常系の確認から段階移行まで、順番に進めます。

1. 正常系と異常系のログインを、それぞれ試します。
2. 少人数で先行試験を行い、問い合わせ対応と切り戻しの手順を用意しておきます。
3. 接続先を一度に増やさず、重要度の低いアプリから段階的に移すと、本番への影響を小さくできます。

テストでは、署名の不一致や証明書の期限切れ、時刻のずれを確かめます。さらに、属性の欠落や権限の変更、重複IDも対象に含めます。

未登録ユーザーも対象です。IdP・SP障害やRelayStateの不正値、Single Logoutの失敗も、テストに含めます。

先行試験では、問い合わせ窓口と旧ログインの併用期間を決め、切り戻しの条件を文書にします。利用者には、ログイン方法とパスワードの扱いを伝えます。問い合わせ先と障害時の代替手段も、あわせて知らせます。

SAMLのシステムの費用相場と期間

SAMLの費用には一律の定価がなく、接続アプリ数や既存システムの改修量で変わります。ユーザー連携やMFA、ログも費用に関わります。また、可用性や移行支援も、費用に影響します。

この金額は、一般的な業務システムの工数相場と公開価格に基づく目安で、確定した金額ではありません。本番障害の影響は大きいので、テストと運用設計が見積もりに含まれているかを確かめます。

▶ 詳細はこちら：SAMLのシステム開発の見積相場や費用/コスト/値段について

方式別の初期費用と開発期間

開発方式と含める機能によって、初期費用と期間の目安が異なります。

• IDaaS接続：標準コネクターで1〜3アプリを接続する場合は、20万〜60万円程度、2〜8週間です。初期設定や属性マッピング、MFA方針、受入テストを含みます。
• 社内Web改修：SP改修は100万〜600万円程度、1〜4か月程度です。セッション管理、権限変換、エラー処理、ログ、証明書更新、総合テストを含みます。
• 認証基盤：複数アプリやディレクトリ、人事データ、SCIM、端末制御、移行教育を含む場合は、500万〜2,000万円程度、3〜9か月程度です。
• 大規模構成：2,000万〜5,000万円以上、6〜18か月程度となる可能性があります。

大規模構成の目安は、子会社・取引先とのマルチテナント、高可用性、災害対策、複数IdPまで求める場合のものです。

ライセンスと3年TCOの計算

公開されている料金だけでは、総額は分かりません。月額に加えて、利用条件と3年分の費用を見ておく必要があります。

• 公開料金の例：国内IDaaSには、SSO付きのプランがあります。
• 月額の試算：月額500円で30IDなら月1万5,000円、年18万円です。初期設定、端末制御、導入支援、契約期間などが別料金の場合があります。
• 契約条件：対象ID数、休眠ID、接続アプリ数、ログ保管年数、SCIM、MFA、サポート範囲
• 3年TCO：初期設定・アプリ改修、ライセンス、インフラ、証明書管理、運用監視・保守、移行・教育を合わせた、3年間の総額
• 追加費用：標準プラン外の機能は、別料金の場合があります。

国内IDaaSの公開価格は、1ユーザーあたり月額300円台から500円台で、最低契約数は30ID以上または50〜100ID以上の例があります（出典: 各サービスの公式料金ページ、2026年8月確認）。

条件付きアクセスやIDガバナンス、アプリケーションプロキシは、別ライセンスになる場合があります。3年分の利用者数やアプリ追加、証明書更新を比べます。障害対応や契約終了時の移行費も、あわせて見ておきます。

初期費用が安い方式でも、総額が安いとは限りません。

SAMLのシステム開発会社・ベンダーの選び方

SAMLの案件では、製品を提供するベンダー、導入設定を支援する会社、既存の業務システムを改修する開発会社で、役割が分かれます。

製品の機能に加えて、自社の認証方式と業務権限をつなぐ設計力、障害時の切り分け、契約終了後の移行しやすさを比べます。

実績の接続数と難易度

「SAML対応の実績がある」という説明だけでは不十分で、どの規模や構成の接続を担ったかを確かめる必要があります。

社内SaaSを数個つなぐ案件、古いWebをリバースプロキシでつなぐ案件、複数組織のIdPを受け入れる案件では、必要な技術と運用が異なります。

自社に近いユーザー数や接続アプリ数の実績を見ます。既存ディレクトリやレガシー環境、監査要件の経験も、あわせて確かめます。担当範囲と障害時の復旧方法は、直接質問しておくとよいでしょう。

技術力と運用体制の評価

将来、OIDCやSCIM、MFAを組み合わせられるかを確かめます。パスキーやAPI連携も、提案の段階で聞いておきます。

NameIDと属性の設計や署名証明書のローテーションは、提案書で見ます。鍵の保管や時刻同期も見ておきます。監査ログやバックアップ、冗長化の体制も確かめます。

SLAや問い合わせの一次窓口も確かめます。納品物には、設定一覧や接続先ごとのメタデータ、テスト結果を含めてもらいます。障害対応手順と証明書更新カレンダーも、納品に加えます。

見積もりと契約条件の比較

見積もりは、作業ごとに分けて提示してもらいます。「SAML連携一式」では、接続先の追加や属性変更の費用が分かりません。証明書更新や障害調査にかかる費用も、見えにくいままです。

• 作業項目：要件定義、PoC、初期設定、アプリ改修
• 移行・運用：ディレクトリ連携、移行、テスト、教育、保守
• 契約条件：最低契約ID数、契約期間、解約時のデータ出力

契約書には、設定情報の返却や再委託先を明記します。脆弱性への対応と、重大障害の連絡時間も書いておきます。

▶ 詳細はこちら：SAMLのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：SAMLのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

▶ 詳細はこちら：SAMLのシステム開発の発注/外注/依頼/委託方法について

SAMLのシステムで必要なセキュリティ設計とテスト

SAMLでは、認証済みという情報を正しく受け渡すために、Responseの検証が欠かせません。SAMLを導入しただけで、ゼロトラストやMFA、個人情報保護まで済むわけではありません。

認証と認可、端末とネットワークは、それぞれ別の層として設計します。ログや委託先の管理も、層ごとに分けて考えます。

ResponseとAssertionの検証

Responseが本物か、再利用されていないかを確かめ、想定した接続先だけで受け入れる設計にします。

• 通信と署名：TLSによる通信の保護と、信頼したIdPの証明書による署名検証
• 値の検証：Responseの識別情報と有効時間の照合
• 再利用の防止：想定したACS URL以外での受け付けを止め、有効時間を短くします。IDと受信履歴を管理して、同じResponseを使い回させない設計にします。
• 対策の根拠：OWASPのガイドに示されたSAMLの安全対策

確認する値は、Issuer、Audience、Destinationです。さらに、RecipientとInResponseToを確かめます。NotBeforeとNotOnOrAfterも、確認の対象です。

同じガイドには、OneTimeUseなどの対策も挙げられています（出典: OWASP「SAML Security Cheat Sheet」、2026年8月閲覧）。

証明書と秘密鍵のライフサイクル管理

証明書の期限切れは、利用者が一斉にログインできなくなる代表的な障害です。そのため、発行日と有効期限、更新担当、予告通知を台帳に残します。本番反映の手順や、旧証明書との並行期間、切り戻し方法も決めておきます。

期限の90日前、60日前、30日前を目安に通知し、更新後は全接続先を確かめます。秘密鍵はアクセス権を絞り、可能ならハードウェア保護や管理サービスを使います。

権限と個人情報の扱いの分離

部署や役職をSAMLの属性として送られてきても、それだけで高い権限を与えないことが基本です。SP側で、必要な権限を改めて判断します。

最小権限や職務分掌を基本にし、管理者には多要素認証を使います。定期的な権限レビューも行います。個人情報を含む属性は必要な範囲に絞り、ログに不要な個人情報は残しません。

SAMLの導入とは別に、個人情報保護委員会のガイドラインが示すアクセス制御や不正アクセス防止の考え方も、管理策として確かめます（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

導入後の運用、障害対応、将来の移行

本番運用では、ログイン成功率を見るだけでなく、属性の変更やアカウントの停止、証明書の更新を継続して管理します。接続先の追加やIdP・SPの障害への対応も、同じ体制で扱います。担当者と判断基準を決めておくと、開発会社やベンダーへの依存を減らせます。

SAMLを残しながら、新しいアプリやモバイル向けの認証を別のプロトコルへ広げる段階移行も、早めに設計します。

ログイン障害を切り分ける手順

ログインできないときは、利用者単位の問題か、全体障害かを切り分けます。続いて、IdPでの認証、ResponseのACS到達、署名検証の順に確かめます。そのあとで、属性とSP側のユーザー・権限を特定します。

頻出の原因は、時刻のずれやAudienceの不一致、NameID形式の違いです。証明書の期限切れや、属性名の大文字と小文字の違い、アカウント停止の反映遅れも、よく見られます。

エラー画面には機密情報を出さず、相関IDを利用者に示します。管理者ログで詳細を追えるように設計します。

入社・異動・退職の連携

認証が成功しても、退職者のアカウントがSPに残っていれば、リスクになります。そのため、人事マスターとIdPのどちらを正とするかを決めておきます。入社や異動、休職、退職のイベントを伝える経路も定義します。

SCIMやAPIを使う場合も、停止の失敗を検知する仕組みと、再実行や手動停止、証跡の保存を用意します。権限属性を自動で更新する場合は、異動日より前に権限が変わるケースや、兼務者が複数の所属を持つケースをテストします。

SAMLからOIDCやパスキーへの段階移行

既存の企業向けSaaSではSAMLを続けつつ、新規Webアプリ、モバイルアプリ、顧客向けサービスではOIDCやパスキーを併用する方針が現実的です。

SAMLは残したまま、認証の入口を共通のIdPへ集約します。そのうえで、アプリごとに適したプロトコルを選びます。

新規開発の要件書には、SAMLとOIDC、SCIM、MFAを含めておきます。パスキーや監査ログ、将来のユーザー移行APIも、同じ要件書に入れます。こうしておくと、二重投資を抑えやすくなります。

よくある質問（FAQ）

SAMLのシステムを検討するときに、特に質問されやすい内容をまとめています。自社の利用者数や既存環境と照らし合わせて、導入方式や見積もりで確かめたい点を探せます。

SAMLとSSOは同じものですか？

同じものではありません。SAMLは認証情報を連携する標準プロトコルで、SSOは一度の認証で複数サービスを利用できる状態や仕組みです。

SAMLはSSOを実現する代表的な方式の一つです。また、OIDCなど別の方式でもSSOは実現できます。

古いWebシステムでもSAML対応できますか？

対応できる可能性があります。アプリ本体を改修するほか、リバースプロキシや認証アダプター、エージェント、フォーム認証代行を使って、古いログイン方式の前段にSAMLを置く方法もあります。

権限の連携やセッション、ログアウト、通信経路、保守のしやすさは、方式ごとに異なります。代表画面でPoCを行ってから、本番の方式を決めます。

SAMLを導入すればMFAやゼロトラストも実現できますか？

MFAやゼロトラストは、SAMLに加えて、IdPや周辺のIAM機能を組み合わせて実現します。端末状態や接続元、リスク判定、最小権限、ログ分析なども、その組み合わせに含めます。

要件書には、認証プロトコルだけでなく、追加認証の条件や管理者操作の記録方法、退職者の停止時間も書いておきます。

SAMLのシステム開発にはいくらかかりますか？

標準的なアプリ接続だけなら初期20万〜60万円程度、既存WebのSP改修なら100万〜600万円程度です。複数アプリや人事連携を含む認証基盤は500万〜2,000万円程度が目安です。

これは一律の料金ではなく、要件と工数から算出した推定の幅です。見積もりは、接続アプリ数やID数、MFA、SCIMなどの項目ごとに、複数の会社から取得します。ログや移行、保守も分けてもらい、3年TCOで比べます。

まとめ：要件・費用・運用を一体にした選定

SAMLのシステムは、IdPとSPの間で認証結果や属性を連携し、複数の業務サービスを安全に利用する基盤です。導入時は、SAML対応の有無よりも、要件全体で判断する必要があります。

ユーザーのライフサイクルやMFA、SCIM、監査ログを確かめます。証明書の更新や既存システムの改修、障害時の代替経路も、見ておきます。

自社に合う方式の選び方

クラウドサービスを中心に運用負担を減らしたい場合は、IDaaSが候補になります。閉域網やレガシーWebが多い場合は、オンプレミスかハイブリッドが候補です。

独自の顧客向け認証や特殊な権限モデルが競争力になる場合は、標準の基盤とカスタム部分を分けて考えます。

代表アプリでPoCを行い、SAMLを残す領域と、OIDCやパスキーへ寄せる領域を決めると、将来の変更に対応しやすくなります。

発注前の要件書と3年TCO

発注の前に、認証要件と費用を整理しておきます。

• 基本要件：利用者数、接続先、Entity ID、ACS URL、NameID、属性
• 制御・運用：署名、証明書、MFA、アカウント停止、ログ、SLA
• 移行・保守：テスト、移行、保守
• 3年TCO：初期費用に加え、ライセンスやID数、アプリ追加、証明書更新、教育、障害対応、契約終了後の移行まで含めた3年間の総額

SAMLのシステムを、ログイン画面の改修だけでなく、認証・権限・運用を含む業務基盤として捉えると、導入後に困らない選定につながります。

▼関連記事一覧
・SAMLのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・SAMLのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・SAMLのシステム開発の見積相場や費用/コスト/値段について
・SAMLのシステム開発の発注/外注/依頼/委託方法について

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。