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

SAMLのシステム開発は、要件整理と方式選定から始め、設計・開発とテストを経て、段階稼働と運用改善に進みます。この順で進めると、安全な認証連携につながります。

SAML連携の全体像、導入の6フェーズ、費用相場と見積もりの確認事項を順に見ていきます。

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

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

SAMLのシステムの全体像

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

IdPとSPの役割

代表的な構成では、Microsoft Entra ID、HENNGE One、OktaなどがIdPになり、業務SaaSや自社WebアプリがSPになります。

• IdP：利用者の認証と、認証ポリシーの適用。
• SP：認証結果の検証と、利用者へのサービス提供。

IdPはIdentity Providerの略で、Active Directoryや人事マスターと連携します。パスワード、MFA、端末条件などを確認したうえで、SAML Responseを発行します。

SPはService Providerの略で、Responseの署名や有効期間を検証します。そのうえで、NameIDや部署、グループなどを自社ユーザーや権限に結び付けます。

SAMLで連携する情報とログインの流れ

SP起点の場合は、利用者が業務アプリへアクセスし、SPがAuthnRequest（認証要求）をIdPへ送ります。

IdPは認証が済むと、署名付きSAML ResponseとAssertionをブラウザ経由で返します。その送信先が、SPのACS（Assertion Consumer Service）URLです。

1. SPは、Issuer、Audience、Destination、Recipient、InResponseToを検証します。
2. NotBeforeとNotOnOrAfterで有効期間を確かめたうえで、署名証明書も検証します。
3. 検証に問題がなければ、SPは自分のセッションを開始します。

Microsoft Learnでも、AuthnRequest、ACS URL、Issuer、Audienceを個別に設定・検証する流れが示されています。AttributeStatementは、ほかの項目と分けて確認します（出典：Microsoft Learn「シングル サインオン SAMLプロトコル」、2026年8月確認）。

SAMLで連携する情報は、ログインの可否に加えて、利用者の属性も含みます。NameIDやメールアドレス、社員番号は、SP側の権限設定へ反映できます。部署や役職、グループ、ロールも反映の対象です。

強い認証を目指すなら、MFAやパスキーを、端末状態や最小権限、入社・異動・退職の管理と組み合わせる必要があります。その組み合わせには、IdPやSCIM、API、運用ルールが関わります。

SAMLのシステム開発・導入の6フェーズ

SAML導入は、要件整理から定着までを一続きのプロジェクトとして設計します。特に、利用者情報や権限を後回しにすると、稼働後に手作業が増えるおそれがあります。

フェーズごとに成果物と判断基準を決めます。そのうえで、代表的な1アプリで検証してから接続先を増やす進め方が現実的です。

フェーズ1：要件整理と対象範囲の決定

最初に対象を、社内従業員向け、子会社・取引先とのB2B連携、顧客向けサービスに分けます。

• 規模と利用環境：利用者数、接続アプリ数、利用地域、端末の洗い出し。
• 既存基盤：ディレクトリ、人事マスター、レガシーWeb、現行ログインの記録。
• 運用要件：認証強度、ログ保存期間、可用性、退職時の停止時間の決定。

権限の決め方や問い合わせ件数も記録します。成果物には、対象業務一覧、利用者・権限の現状表、接続先一覧を含めます。さらに、非機能要件、用語定義、概算スケジュールも加えます。

Entity ID、ACS URLを、接続先ごとにSAML接続台帳へ記録します。Single Logout URL、NameID形式、属性名も同じ台帳に入れます。

署名・暗号化方針とアカウント作成方法も、台帳に加えます。台帳を先に作っておくと、ベンダー間の認識差を抑えられます。

SAML非対応のアプリも、接続できる可能性を調べます。その手段には、リバースプロキシやエージェント、フォーム認証代行、認証アダプターがあります。

フェーズ2：IDaaS・パッケージ・個別開発の選定

方式は、接続環境や認証体験に合わせて選びます。次の条件で候補を絞り込みます。

• クラウド型IDaaS：接続アプリが標準SaaS中心の場合。
• オンプレミス型・ハイブリッド：閉域網や古いWebが多い場合。
• カスタム開発：顧客向けの独自認証体験やマルチテナントが競争力に直結する場合。

Microsoft 365を使うならMicrosoft Entra ID、Google Workspaceが中心なら既存の管理基盤が候補です。また、国内SaaSの支援やポータルを重視するなら、HENNGE OneやGMOトラスト・ログインも候補になります。

比較では、SAML 2.0に加えて、OIDCやSCIM、MFA、パスキーを確認します。さらに、条件付きアクセスや監査ログ、API、AD・人事データ連携も見ておきます。

標準の認証とライフサイクルは製品の機能に寄せ、独自の権限やレガシー接続はアダプターで補うハイブリッドは、OIDCやパスキーへ移行しやすい方式です。

認証の中核を自作する場合は、価格より先に、XML署名検証やリプレイ対策、鍵管理、脆弱性対応を長期的に担える体制があるかを確認します。

フェーズ3：属性・権限・接続方式の設計と開発

設計では、IdPとSPを定めたうえで、利用者識別子や属性を権限に反映する方針を決めます。

• 利用者識別子：メールアドレスに頼らない値も候補にできます。
• 再ひも付け：社員番号やIdPの不変IDなら、退職・再入社・ドメイン変更の後も対応できる可能性があります。
• 権限反映：部署・役職の変換方法とSP承認の要否を定め、異動時に過剰な権限が残らない設計にします。

開発・設定の範囲には、メタデータ交換や証明書登録、AuthnRequest、ACSを含めます。セッション期限とログアウトに加え、エラー画面と監査ログも対象に入ります。

緊急時に使うローカル管理者の経路も用意します。なお、ユーザーの作成・更新・停止・削除は、SAMLログインだけでは自動化されません。

方式は、SCIMやAPI、人事マスター連携、JITプロビジョニングから選び、IdPで無効化した退職者がSPに残るケースを防ぎます。

フェーズ4：正常系と異常系のテスト

テストでは、正常系と異常系の両方を確認します。ログイン画面が表示されることは、その一部にすぎません。

• 正常系：SP・IdP起点、初回・既存ユーザー、複数ブラウザ・端末、グループ別権限、ログアウト・再ログインの確認。
• 異常系：署名不一致、期限切れ証明書、時刻ずれ、Issuer・Audience不一致、ACS URL誤り、属性欠落、重複IDの試験。
• 障害系：未登録ユーザー、IdP・SP障害、RelayState不正値、Single Logout失敗の試験。

セキュリティテストでは、TLSを使い、署名者証明書が登録済みの信頼元から取得できているかを確認します。

OWASPは、ローカルの信頼できるスキーマでXMLを検証し、KeyInfoを無条件に信用しないよう推奨しています。加えて、署名ラッピング攻撃を避けるよう呼びかけています。

Responseの有効期間を短くし、必要に応じてOneTimeUseやリプレイ検知を使う考え方も示されています（出典：OWASP「SAML Security Cheat Sheet」、2026年8月確認）。

テストで確認した項目は受入テストに反映し、結果と再現手順を納品物に残します。

フェーズ5：パイロットから本番稼働への移行

本番移行は、パイロット、検証、段階展開の順に進めます。

1. 管理者と少人数の代表ユーザーで試し、問い合わせが少なく業務停止の影響が小さいアプリから始めます。
2. 属性マッピング、権限、ログ、障害時の切り戻しを確認します。
3. 部門・アプリ単位で移行し、旧ログイン併用期限、周知、窓口、緊急管理者経路を決めます。

稼働判定では、ログイン成功率に加えて、重要業務の継続を確認します。退職者の停止時間と障害復旧時間、監査ログ、証明書更新担当者も見ておきます。

証明書の期限は台帳で管理し、少なくとも90日前を目安に通知します。通知時期は、更新方式と接続先の反映リードタイムで決めます。

ロールバック手順には、旧ログインを残す期間と切り替え担当者、利用者への伝え方を記載します。

フェーズ6：運用と利用定着の改善

稼働後は、変更対応と定期点検を運用に組み込みます。

• 定例業務：接続先追加、組織変更、権限レビュー、証明書更新、ログ監視、問い合わせ対応。
• 定期点検：月次または四半期ごとに未使用アカウントや長期未使用権限を確認。
• 異常確認：失敗ログイン、異常な地域・端末、プロビジョニング失敗を点検。

人事マスターの異動情報がIdPやSPに反映されるかは、実データに近いケースで確認します。そのうえで、利用者には初回ログインやMFA登録、パスワードリセットなどを案内します。

また、スマートフォン変更時や障害時の連絡先も、短い手順で示します。業務部門の管理者が権限申請や退職処理を理解していることが、定着の条件になります。

納品時には、接続台帳と属性一覧、証明書・鍵の管理方法、設定変更の記録を残します。さらに、テスト結果と障害対応、ベンダー連絡先、契約終了時のデータ出力方法も残します。

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

SAMLの費用は、接続アプリ数や既存システムの改修量によって変わり、一律の定価はありません。

ここで示すのは、業務システムの相場、公開IDaaS料金、必要作業をもとにした推定レンジで、確定金額ではありません。

見積もりでは、設定と改修、移行、テストを分けて確認します。運用設計と保守も、別の項目として見ておきます。

方式別の初期費用と期間の目安

費用と期間は、接続範囲と必要な改修によって変わります。次の範囲ごとの目安を、見積もりを比べる基準にします。

• 標準コネクター：1〜3アプリの設定は初期20万〜60万円程度、2〜8週間程度です。
• 既存Web改修：SP改修は100万〜600万円程度、1〜4か月程度です。
• 認証基盤：複数SaaSやAD・人事データ、SCIM、MFA等を含み、500万〜2,000万円程度、3〜9か月程度です。
• 大規模・高可用性：2,000万〜5,000万円以上、6〜18か月程度が推定レンジです。

標準コネクターの範囲は、属性マッピング、MFA方針、受入テストまでです。一方、Web改修の範囲には、セッション管理や権限変換、エラー処理を含みます。さらに、ログ、証明書更新、総合テストも範囲に入ります。

認証基盤には端末制御、移行、教育を含む場合があります。大規模構成は、子会社・取引先・顧客向けマルチテナントや災害対策、複数IdP、24時間運用などを求める場合の推定です。

金額と期間は、要件と工数から推定した目安で、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月確認）。

総額を比べるときは、初期費用から運用・移行までを洗い出します。

• 初期設定・アプリ改修費
• IDaaSまたはライセンス費、インフラ費
• 証明書管理費、運用監視・保守費
• 移行費、教育費

新規契約時のMicrosoft Entra IDの年払い料金は、P1がユーザー月額1,049円相当、P2が1,499円相当です（出典：Microsoft「Microsoft Entraのプランと価格」、2026年8月確認）。

Microsoft Entra IDは、Microsoft 365 E3、Business Premium、E5などに含まれる場合があり、既存契約で追加費用が変わります。

見積もりは、3年TCO（総所有コスト）で比較します。

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

見積もりを比べるときは、ライセンス月額に加えて、別の費用項目も確認します。たとえば、属性整理やユーザー移行、接続先の例外が別料金なら、追加費用が生じます。テスト、証明書更新、障害切り分けも、別料金かどうかを見ておきます。

RFPや見積依頼書に接続台帳と受入条件を添えて、同じ前提で複数社に依頼します。

見積書に書く要件と前提条件

見積もりの前提は、利用者数、接続先、認証・運用要件に分けて整理します。

• 利用者数：現在と3年後の想定、外部ユーザー、休眠アカウントの扱い。
• 接続要件：アプリ、SAML対応状況、SP・IdP、現行ログイン、AD・LDAP・人事DB連携。
• 認証情報：NameID、属性、権限、MFA、端末制御。
• 運用条件：ログ保存期間、可用性、データ所在地、サポート時間。

アプリ数が無制限であっても、支援対象数や個別コネクター費は含まれない場合があります。

納品物には、接続台帳、設定一覧、メタデータを含めます。加えて、証明書更新手順、属性マッピング表、テスト仕様と結果も含めます。

運用マニュアルや切り戻し手順、管理者教育、利用者案内も確認します。「設定支援」「既存アプリのソース改修」「受入テスト支援」の範囲を分けておくと、見積もりの違いが見えてきます。

製品・導入・改修の役割によるベンダー比較

ベンダーを比べるときは、製品・導入・改修それぞれの役割と経験を確認します。

• 体制・実績：製品提供会社、SIer、開発会社の担当分担と近い環境での経験。
• 責任範囲：再委託先、障害窓口、設定変更の承認者。
• 技術・運用：SAML 2.0、OIDC、SCIM、MFA、パスキー、API、条件付きアクセス。
• 契約終了：データ出力、移行支援、担当交代後も運用できる資料と体制。

運用面では、証明書のローテーションや鍵の保管、時刻同期を確認します。さらに、監査ログやバックアップ、冗長化も見ておきます。また、SLAや問い合わせ対応、契約終了時のデータ出力と移行支援も確認します。

リスクと追加費用の事前確認

追加費用や障害につながる事象を想定し、それぞれの対応責任を確認します。

• 認証障害：証明書期限切れ、時刻ずれ、属性不一致、退職者の停止漏れ、IdP・SP障害。
• 費用変動：接続先仕様変更、ライセンス数増加、ログ保存期間の延長。
• 復旧体制：検知・判断担当、復旧手順と所要時間、鍵の管理責任や緊急ローテーション契約。
• 個人データ：アクセス制御、利用者の識別・認証、不正アクセス・漏えい防止を運用まで評価。

個人情報保護やゼロトラストには、SAML導入のほかに対策が要ります。最小権限やMFA、端末条件を、別項目で見積もります。さらに、ログ分析や暗号化、委託先管理も見積もりに含めます。

契約書には、監査ログの所有、設定情報の返却、別ベンダーへの移行協力の範囲を明記します。

よくある質問（FAQ）

導入前によくある疑問として、IDaaSの選び方や既存アプリの対応可否、SAMLとOIDCの使い分けを取り上げます。費用や期間についても、あわせて回答します。

SAMLのシステム開発費用はいくらですか？

標準コネクターで1〜3アプリを接続する場合、初期は20万〜60万円程度、期間は2〜8週間程度が推定の目安です。

既存WebのSP改修は100万〜600万円程度です。一方で、AD・人事データやSCIM、MFA、移行を含む、複数アプリの認証基盤は500万〜2,000万円程度となる可能性があります。

費用は、アプリ数や利用者数、レガシー対応によって変わります。可用性や運用設計も影響するため、確定額ではなくレンジとして比べてください。

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

対応できる可能性があります。直接SAMLを実装できなくても、リバースプロキシやエージェント、フォーム認証代行、認証アダプターで入口を統合できる場合があります。

改修範囲は、画面・セッション構造や利用者識別子、権限、ネットワーク制約によって変わります。代表アプリでPoCを行い、本開発の前にログインとログアウト、タイムアウトを確認します。さらに、権限変更や障害時の戻し方も、あわせて見ておきます。

SAMLとOIDCはどちらを選べばよいですか？

企業向けSaaSや社内WebとのブラウザSSOではSAML、新規Webサービス、モバイルアプリ、API中心の構成ではOIDCを候補にします。

全社で方式を一つに揃えるより、IdPが両方を提供する環境で接続先の特性に合わせて使い分ける方法があります。たとえば、新規サービスからOIDCやパスキーを採用し、接続先の更新時に段階移行すると、二重投資を抑えやすくなります。

SAML証明書の期限切れを防ぐにはどうしますか？

接続先や証明書用途、発行日、有効期限を、証明書台帳へ登録します。さらに、更新担当と反映・切り戻し手順も記録します。

IdPとSPの署名担当や、署名用と暗号化用の鍵を分けるかを確認します。メタデータの自動更新の可否も、あわせて見ておきます。

有効期限の90日前を目安に通知します。そのうえで、検証環境で新しい証明書を登録してから本番へ反映すると、ログイン停止のリスクを下げられます。

まとめ

SAML開発では、対応製品を選ぶだけでなく、IdPとSP、識別子、属性・権限を決めておくことが大切です。さらに、アカウント管理と証明書、ログ、障害復旧も、一つの運用設計にまとめます。

6フェーズで確認する要点

導入は、要件整理と方式選定から始め、設計開発とテストを経て、段階稼働と運用定着へ進めます。

1. 対象ユーザー、接続先、既存基盤、権限、非機能要件を整理します。
2. IDaaS、パッケージ、オンプレミス、ハイブリッド、個別開発を比較します。
3. NameID、属性、ACS、Audience、証明書、セッション、プロビジョニングを決めます。
4. 正常系・異常系を検証し、パイロットと切り戻しを準備します。
5. 権限レビュー、証明書更新、ログ監視、利用者教育を定例化します。

最初に作るべき資料と次の一歩

導入前に用意する資料と検証内容を、順番に整理します。

1. 利用者、アプリ、属性、権限、認証方式、停止方法を並べたSAML接続台帳を作ります。
2. 代表的な1アプリでPoCを行い、Response検証、権限連携、退職者停止、証明書更新、障害時の代替経路を確かめます。
3. 必要範囲を満たすパートナーを選び、ライセンス月額だけでなく初期設定、改修、移行、テスト、運用、3年TCOを比べます。

SAMLは、OIDCやパスキーと併用できます。たとえば、既存SaaSにはSAML、新規アプリやモバイルにはOIDCやパスキーを使うように、役割を分けます。

認証基盤と業務システムを段階的に改善すると、利用者の利便性と運用の安全性を両立しやすくなります。

▼全体ガイドの記事
・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を創業。