SAMLのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

SAMLのシステム開発は、IdPとSPの認証連携を設計し、既存の業務システムへSSO・属性連携・アカウント管理を段階的に組み込む取り組みです。単にログイン画面を変更するのではなく、利用者情報、権限、証明書、障害時の運用まで決めて初めて安全に稼働できます。

「既存のWebシステムはSAML対応できるのか」「Microsoft Entra IDやGoogle WorkspaceをIdPにできるのか」「IDaaSの導入と個別開発のどちらがよいのか」と迷う担当者は少なくありません。本記事では、SAMLのシステムの全体像から、要件整理、方式選定、設計開発、テスト、稼働、定着までの進め方、費用相場、見積もりの確認ポイントを実務目線で解説します。

▼全体ガイドの記事
・SAMLのシステム開発の完全ガイド

SAMLのシステムの全体像を理解する

SAMLは、XML形式のアサーションを使って、利用者を認証した事実や属性情報を別のサービスへ伝える標準仕様です。代表的な構成では、Microsoft Entra ID、HENNGE One、OktaなどがIdP、業務SaaSや自社WebアプリがSPになります。SAML 2.0はOASISが標準化した仕様であり、企業向けのブラウザSSOや組織間の認証連携で使われています（出典：OASIS「Security Assertion Markup Language（SAML）v2.0」、2005年）と確認できます。

IdPはIdentity Providerの略で、利用者の本人確認と認証ポリシーの適用を担当します。Active Directoryや人事マスターと連携して利用者を管理し、パスワード、MFA、端末条件などを確認した後、認証済みであることを示すSAML Responseを発行します。SPはService Providerの略で、業務アプリやSaaSなど利用者が使うサービスです。SPはResponseの署名や有効期間を検証し、NameIDや部署、グループなどの属性を自社ユーザーと権限へ結び付けます。

SP起点のログインでは、利用者が業務アプリへアクセスし、SPがAuthnRequestという認証要求をIdPへ送ります。IdPで認証が完了すると、IdPが署名付きのSAML ResponseとAssertionをブラウザ経由でSPのACS（Assertion Consumer Service）URLへ返します。SPはIssuer、Audience、Destination、Recipient、InResponseTo、NotBefore、NotOnOrAfter、署名証明書などを検証し、問題がなければ自分のセッションを開始します。Microsoft Learnの技術資料でも、AuthnRequest、ACS URL、Issuer、Audience、AttributeStatementを個別に設定・検証する流れが示されています（出典：Microsoft Learn「シングル サインオン SAMLプロトコル」、2026年8月確認）と確認できます。

このとき連携するのはログイン可否だけとは限りません。NameID、メールアドレス、社員番号、部署、役職、グループ、ロールを属性として渡せば、SP側の権限設定へ反映できます。ただし、SAMLは強い認証そのものではありません。MFA、パスキー、端末状態の確認、最小権限、入社・異動・退職のライフサイクル管理は、IdPやSCIM、API、運用ルールと組み合わせて実現します。

SAMLのシステム開発・導入はどのように進めますか？6フェーズで解説

SAMLのシステムは、要件整理から定着までを一続きのプロジェクトとして設計します。特に、利用者情報と権限の整理を後回しにすると、ログイン自体は成功しても「誰がどの画面を使えるか」が決まらず、稼働後に手作業が増えます。6フェーズごとに成果物と判断基準を置き、代表的な1アプリで検証してから接続先を増やす進め方が現実的です。

最初に、対象を「社内の従業員向け」「子会社・取引先とのB2B連携」「顧客向けサービス」のどれにするか分けます。次に、利用者数、接続アプリ数、利用地域、既存ディレクトリ、人事マスター、レガシーWeb、利用端末、認証強度、ログ保存期間、可用性、退職時に何分以内で停止するかを整理します。SAML対応アプリを一覧にするだけでなく、現行のログイン方法、ユーザー識別子、権限の決め方、問い合わせ件数も記録します。

成果物は、対象業務一覧、利用者・権限の現状表、接続先一覧、非機能要件、用語定義、概算スケジュールです。接続先ごとにEntity ID、ACS URL、Single Logout URL、NameID形式、属性名、署名・暗号化方針、アカウント作成方法を記録する「SAML接続台帳」を先に作ると、ベンダー間の認識差を抑えられます。既存アプリがSAML非対応でも、リバースプロキシ、エージェント、フォーム認証代行、認証アダプターで接続できる可能性を調べます。

方式は、接続アプリが標準的なSaaS中心ならクラウド型IDaaS、閉域網や古いWebが多いならオンプレミス型またはハイブリッド、顧客向けの独自認証体験やマルチテナントが競争力に直結するならカスタム開発を軸に比較します。すでにMicrosoft 365を利用している場合はMicrosoft Entra ID、Google Workspace中心なら既存の管理基盤、国内SaaSの導入支援やユーザーポータルを重視する場合はHENNGE OneやGMOトラスト・ログインなど、現在の契約・運用資産を起点に候補を絞ります。

比較時は、SAML 2.0だけでなくOIDC、SCIM、MFA、パスキー、条件付きアクセス、監査ログ、API、AD・人事データ連携の範囲を見ます。標準の認証とライフサイクルは製品へ寄せ、独自権限やレガシー接続だけをアダプターで補うハイブリッドは、将来のOIDCやパスキーへの移行もしやすい方式です。認証の中核をスクラッチで自作する場合は、XML署名検証、リプレイ対策、鍵管理、脆弱性対応を長期的に担える体制があるかを、価格より先に判断します。

設計では、どのシステムをIdPにし、どのアプリをSPにするかを決めます。ユーザー識別子は、変更されやすいメールアドレスだけに依存せず、社員番号やIdPの不変IDなど、退職・再入社・ドメイン変更が起きても再ひも付けできる値を候補にします。部署や役職を属性として送る場合は、属性値をそのまま権限に変換するのか、SP側の承認を経て付与するのかを決め、異動時に過剰権限が残らない設計にします。

開発・設定の対象には、メタデータ交換、証明書登録、AuthnRequest、ACSの受け口、セッションの有効期限、ログアウト、エラー画面、監査ログ、緊急時のローカル管理者経路を含めます。ユーザー作成・更新・停止・削除は、SAMLログインだけで自動化されるわけではありません。SCIMやAPI、人事マスター連携、JITプロビジョニングのどれを採用するかを決め、退職者がIdPでは無効でもSP内に残るケースを防ぎます。

テストは、ログイン画面が表示されることだけで合格にしません。正常系ではSP起点・IdP起点のログイン、初回ユーザー、既存ユーザー、複数ブラウザ、複数端末、グループ別の権限、ログアウト、再ログインを確認します。異常系では、署名不一致、期限切れ証明書、時刻ずれ、IssuerやAudienceの不一致、ACS URLの誤り、属性欠落、重複ID、未登録ユーザー、IdP障害、SP障害、RelayStateの不正値、Single Logoutの失敗を試験します。

セキュリティテストでは、TLSで通信を保護し、署名者の証明書を登録済みの信頼元から取得できているかを確かめます。OWASPは、XMLを信頼できるローカルスキーマで検証し、SAML文書内のKeyInfoを無条件に信用せず、署名ラッピング攻撃を避けることを推奨しています。また、Responseの有効期間を短くし、必要に応じてOneTimeUseやリプレイ検知を使う考え方も示しています（出典：OWASP「SAML Security Cheat Sheet」、2026年8月確認）。この内容を受入テストの項目へ落とし込み、結果と再現手順を納品物に残します。

本番移行は、管理者と少人数の代表ユーザーでパイロットを行ってから段階的に広げます。最初は問い合わせが少なく、業務停止の影響が比較的小さいアプリを選び、属性マッピング、権限、ログ、障害時の切り戻しを確認します。その後、部門単位やアプリ単位で移行し、旧ログインの併用期限、利用者への周知、問い合わせ窓口、緊急用の管理者経路を決めます。

稼働判定では、ログイン成功率だけでなく、重要業務の利用継続、退職者の停止時間、認証障害時の復旧時間、監査ログの取得、証明書更新の担当者が明確かを確認します。証明書は有効期限を台帳で管理し、少なくとも90日前を目安に通知する運用が扱いやすいですが、実際の通知期間は証明書の更新方式と接続先の反映リードタイムで決めます。ロールバック手順は、旧ログインをいつまで残すか、誰が切り替えるか、利用者へどう伝えるかまで書面化します。

稼働後は、認証基盤を置いて終わりにせず、接続先の追加、組織変更、権限レビュー、証明書更新、ログ監視、問い合わせ対応を定例化します。月次または四半期ごとに、利用されていないアカウント、長期間使われていない権限、失敗ログイン、異常な地域や端末からのアクセス、プロビジョニングの失敗を確認します。人事マスターの異動情報が正しくIdPやSPへ反映されるかも、実データに近いケースで点検します。

利用者には、初回ログイン、MFA登録、パスワードリセット、スマートフォン変更、障害時の連絡先を短い手順で案内します。情シスだけでなく、業務部門の管理者が権限申請や退職処理を理解できる状態が定着の条件です。納品時には、接続台帳、属性一覧、証明書と鍵の管理方法、設定変更手順、テスト結果、障害対応フロー、ベンダー連絡先、契約終了時のデータ出力方法を残し、担当者が変わっても運用できるようにします。

SAMLのシステムの費用相場と内訳

SAMLのシステムには、接続アプリ数や既存システムの改修量に応じた一律の定価がありません。以下の金額は、リサーチノートにある一般的な業務システムの相場、公開されているIDaaS料金、SAML連携で必要になる作業をもとにした推定レンジです。確定金額ではないため、見積もりでは設定、改修、移行、テスト、運用設計、保守を分けて確認します。

標準コネクターで代表的な1〜3アプリをIDaaSへ接続し、属性マッピング、MFA方針、受入テストまで行う場合は、初期20万〜60万円程度、2〜8週間程度が一つの目安です。既存の社内WebをSAMLのSPへ改修し、セッション管理、権限変換、エラー処理、ログ、証明書更新、総合テストまで含める場合は、100万〜600万円程度、1〜4か月程度が参考レンジになります。

複数SaaS、Active Directoryや人事データ、SCIM、MFA、端末制御、移行、教育を含む認証基盤は、500万〜2,000万円程度、3〜9か月程度となる可能性があります。子会社・取引先・顧客を含むマルチテナント、高可用性、災害対策、複数IdP、24時間運用まで求める場合は、2,000万〜5,000万円以上、6〜18か月程度が推定レンジです。これらはSAML固有の公定価格ではなく、要件と工数から推定した目安です。

2026年8月に確認した公式料金では、HENNGE One Identity EditionはIdPが1ユーザー月額300円、IdP Proが500円で、最小契約ID数は200以上と表示されています（出典：HENNGE株式会社「価格とプラン」、2026年8月確認）と確認できます。単純計算では200IDで月6万〜10万円、年72万〜120万円ですが、税別であり、初期設定やオプションは別に確認が必要です。GMOトラスト・ログインは、SSOプロが1ユーザー月額300円、SSOプロ＋SaaS管理が500円で、30名以上、12か月契約と表示されています（出典：GMOグローバルサイン株式会社「料金・機能」、2026年8月確認）と確認できます。

Microsoft Entra IDを新規に契約する場合、公式料金ページではP1がユーザー月額1,049円相当、P2が1,499円相当の年払い料金として案内されています。Microsoft 365 E3、Business Premium、E5などに含まれる場合があるため、既存契約の有無で追加費用は変わります（出典：Microsoft「Microsoft Entraのプランと価格」、2026年8月確認）。総額は、初期設定・アプリ改修費、IDaaSまたはライセンス費、インフラ費、証明書管理費、運用監視・保守費、移行・教育費を合算し、3年TCOで比較します。

SAMLのシステムの見積もりを取る際のポイント

SAML案件の見積もりは、ライセンスの月額だけを比較すると失敗しやすい領域です。初期設定が安く見えても、属性の整理、既存ユーザーの移行、接続先ごとの例外、テスト、証明書更新、障害時の切り分けが別料金なら、稼働前後に追加費用が発生します。RFPや見積依頼書には、接続台帳と受入条件を添え、同じ前提で複数社へ依頼します。

見積依頼時は、利用者数を「現在の人数」だけでなく、3年後の想定、外部ユーザー、休眠アカウントの扱いまで示します。接続するアプリ、SAML対応の有無、SPとIdPの候補、既存のログイン方式、AD・LDAP・人事DBの連携方法、NameID、属性、権限、MFA、端末制御、ログ保存期間、可用性、データ所在地、サポート時間も明記します。特に、接続アプリ数を「無制限」とする場合でも、導入支援の対象数や個別コネクターの作業費が含まれない場合があります。

納品物も価格に影響します。接続台帳、設定一覧、メタデータ、証明書更新手順、属性マッピング表、テスト仕様書と結果、運用マニュアル、障害時の切り戻し手順、管理者教育、利用者向け案内を成果物として列挙します。作業範囲が「設定支援」なのか「既存アプリのソース改修」なのか、「受入テスト支援」なのかを分けると、提案の比較がしやすくなります。

SAMLの案件では、IDaaSや認証製品を提供するベンダー、導入設定を支援するSIer、既存業務システムを改修する開発会社が別になることがあります。「SAML対応実績あり」だけでなく、自社と近い利用者数、接続アプリ数、レガシー環境、既存ディレクトリ、監査要件を経験しているか確認します。提案会社が担当する範囲、再委託先、障害時の一次窓口、設定変更の承認者も質問します。

技術面では、SAML 2.0、OIDC、SCIM、MFA、パスキー、API、条件付きアクセスを将来組み合わせられるかを見ます。運用面では、証明書のローテーション、鍵の保管、時刻同期、監査ログ、バックアップ、冗長化、SLA、問い合わせ対応、契約終了時のデータ出力と移行支援を確認します。価格の安さだけでなく、担当者が変わっても運用できる資料と体制が提案書に含まれている会社を選ぶことが重要です。

見積もりの確認では、証明書期限切れ、時刻ずれ、属性値の不一致、退職者の停止漏れ、IdP障害、SP障害、接続先の仕様変更、ライセンス数の増加、ログ保存期間の延長を想定します。それぞれに、誰が検知し、誰が判断し、何分以内にどの手順で復旧するかを確認します。証明書と秘密鍵の管理責任が自社とベンダーのどちらにあるか、鍵漏えい時の緊急ローテーションが契約に含まれるかも重要です。

個人データを扱う場合は、アクセス制御、アクセス者の識別・認証、不正アクセス防止、漏えい防止を運用まで含めて評価します。SAMLを導入しただけで、個人情報保護やゼロトラストが自動的に完了するわけではありません。最小権限、MFA、端末条件、ログの定期分析、暗号化、委託先管理を別の管理項目として見積もりへ含め、契約書には監査ログの所有、設定情報の返却、別ベンダー移行の協力範囲を明記します。

よくある質問（FAQ）

SAMLのシステムを検討すると、IDaaSの選び方、既存アプリの対応可否、SAMLとOIDCの使い分け、費用と開発期間について質問が出ます。ここでは、導入前に特に確認したい疑問へ直接回答します。

標準コネクターで1〜3アプリを接続する設定なら、初期20万〜60万円程度、2〜8週間程度が推定の目安です。既存WebのSP改修は100万〜600万円程度、複数アプリやAD・人事データ、SCIM、MFA、移行を含む認証基盤は500万〜2,000万円程度となる可能性があります。アプリ数、ユーザー数、レガシー対応、可用性、運用設計で変わるため、確定金額ではなくレンジとして比較してください。

対応できる可能性があります。アプリがSAMLを直接実装できなくても、リバースプロキシ、エージェント、フォーム認証代行、認証アダプターで入口を統合できる場合があります。ただし、画面やセッションの構造、利用者識別子、権限の持ち方、ネットワーク制約によって改修範囲が変わるため、代表アプリでPoCを行い、ログインだけでなくログアウト、タイムアウト、権限変更、障害時の戻し方まで確認してから本開発へ進みます。

既存の企業向けSaaSや社内WebとのブラウザSSOではSAML、新規のWebサービス、モバイルアプリ、API中心の構成ではOIDCを候補にします。どちらか一方に全社で統一する必要はなく、IdPが両方を提供できる構成を選び、接続先の特性で使い分ける方法が現実的です。既存SAMLをすぐ廃止するのではなく、新規サービスからOIDCやパスキーを採用し、接続先の更新時に段階的に移行すると二重投資を抑えやすくなります。

接続先、証明書の用途、発行日、有効期限、更新担当、反映手順、切り戻し手順を証明書台帳へ登録します。IdPとSPのどちらが署名するか、署名用と暗号化用の鍵を分けるか、メタデータの自動更新が使えるかも確認します。有効期限の90日前を目安に通知し、検証環境で新証明書を登録してから本番へ反映する運用にすると、ログイン停止のリスクを下げられます。

まとめ

SAMLのシステム開発・導入は、SAML対応製品を契約するだけでは完了しません。IdPとSPの役割、ユーザー識別子、属性と権限、アカウントのライフサイクル、証明書、ログ、障害時の復旧を一つの運用設計として決めることが重要です。

要件整理では対象ユーザー、接続先、既存認証基盤、権限、非機能要件を整理します。選定ではIDaaS、パッケージ、オンプレミス、ハイブリッド、個別開発を将来のOIDC・SCIM・MFA・パスキーまで含めて比較します。設計開発ではNameID、属性、ACS、Audience、証明書、セッション、プロビジョニングを決め、テストでは正常系と異常系を検証します。稼働ではパイロットと切り戻しを準備し、定着では権限レビュー、証明書更新、ログ監視、利用者教育を定例化します。

最初の一歩は、利用者・アプリ・属性・権限・認証方式・停止方法を並べたSAML接続台帳を作ることです。代表的な1アプリでPoCを行い、SAML Responseの検証、権限連携、退職者の停止、証明書更新、障害時の代替経路を確認してから、他のアプリへ展開します。見積もりはライセンス月額だけでなく、初期設定、改修、移行、テスト、運用、3年TCOで比較し、自社に必要な範囲を満たすパートナーを選びます。

SAMLは成熟した企業間連携の選択肢であり、OIDCやパスキーと対立するものではありません。既存SaaSにはSAML、新規アプリやモバイルにはOIDC・パスキーというように役割を分け、認証基盤と業務システムを段階的に改善すると、利用者の利便性と運用の安全性を両立しやすくなります。

▼全体ガイドの記事
・SAMLのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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