SAMLの発注は、まず現状調査と方式比較から始め、要件定義とRFP作成、提案・見積比較、契約と設計を経て、接続・テスト・移行へ進みます。利用者と接続先を先に調べておくと、認証基盤全体を整えやすくなります。
発注形態や費用、委託先の選び方も、この流れに沿って見ていきます。
▼全体ガイドの記事
・SAMLのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SAMLのシステムを発注する前に知っておきたい全体像
SAMLは、認証した事実やユーザー属性を別のサービスへ伝える標準プロトコルです。認証を行うIdPと、業務アプリやSaaSであるSPとの間で、署名付きのSAML Responseをやり取りします。
外注の対象には、SAML機能の実装に加えて、認証方式と権限、アカウント連携、運用体制も含まれます。業務システムとして設計し、その範囲を発注時に決めておきます。
SAMLにおけるIdPとSPの役割分担
IdPが利用者を認証し、SPが業務アプリへのログインを受け持ちます。そのため、両者をどこに配置するかで連携方式が決まります。
- 一般的な構成：Entra ID、HENNGE One、GMOトラスト・ログイン、OktaなどをIdPとし、社内WebシステムやSaaSをSPとする形です。
- 既存環境：Microsoft 365中心ならEntra ID、Google Workspace中心なら既存ディレクトリやIDaaSとの役割を見比べます。
- B2Bサービス：顧客企業のIdPでログインさせる場合は、自社がSPになることがあります。
接続先ごとにIdPが異なる場合は、メタデータとNameIDを管理する設計が必要です。属性名や署名方式も、同じように管理します。役割があいまいなまま発注すると、開発後にSAML対応済みでも接続できない事態が起こります。
IDaaS導入、既存改修、個別開発の使い分け
発注形態は大きく三つに分けられます。IDaaSの標準機能を導入する形、既存の社内WebシステムをSP化する形、複数テナントや独自の認可モデルを持つ認証基盤を個別に開発する形です。
社内SaaSのSSO化が中心なら、標準コネクターを使う導入型が合います。一方、古いWebシステムや閉域網のアプリが残る場合は、リバースプロキシや認証アダプターを組み合わせます。
顧客向けサービスの認証を新規開発する場合は、SAMLだけに固定せず、OIDCやパスキーも併用できる構成にしておくと、将来の二重投資を抑えられます。
SAMLシステムの発注・外注の進め方
ログイン画面の改修だけで考えず、アカウントの発行・変更・停止や障害時の運用まで含めて、一つのプロジェクトとして扱います。進め方は、現状調査と方式比較から始めて、要件定義とRFP作成、提案・見積比較、契約と設計へと進み、最後に接続・テスト・移行を行います。
最初の調査で利用者と接続先の全体を把握し、その内容をRFPに反映してから、見積もりと契約に進みます。
現状と利用者の範囲の調査
調査では、利用者と接続アプリを整理します。対象ユーザーは、社員や派遣社員、子会社、そして取引先や顧客に分けたうえで、それぞれの人数と増減の見込みを確認します。
- アプリごとの状態：SAML対応の有無、現行の認証、管理者権限、利用停止の方法、データの重要度。
- ユーザー情報の正本：Active Directory、人事システム、Microsoft 365、Google Workspaceなどのうち、どれを正とするか。
- 更新と停止の運用：入社・異動・退職の反映を誰がいつ行うか、自動化と手動承認をどう使い分けるか。
ユーザー情報の正本が定まらないと、入社・異動・退職の反映をどこで合わせるかが曖昧になります。利用者数だけで認証基盤を選ぶと、取引先ごとのIdP連携やアカウント停止の要件が抜けやすくなります。SCIMやAPIによる自動化と、手動承認の範囲も早めに決めておきます。
退職者の即時停止が必要なら、SAML SSOだけでなく、プロビジョニングとライフサイクル管理の費用も要件に含めます。
RFPに書くSAML固有の接続情報と運用条件
RFPには、目的や範囲、現行構成を示します。また、希望日程や予算の考え方、納品物、選定基準も書きます。接続条件は、提案会社が見積もれるように具体化します。
- 接続仕様：接続先のIDやURL、開始方式、バインディングを記載します。
- 識別と属性：NameIDの形式、必要な属性と属性名、値の形式、必須か任意か、アプリ内ロールへの変換を示します。
- 保護と運用：署名と暗号化、証明書の更新、時刻許容範囲、RelayState、エラー表示を定義しておきます。
具体的には、Entity ID、ACS URL、Single Logout URLを書きます。また、開始方式がIdP initiatedかSP initiatedか、バインディングがHTTP-RedirectかHTTP-POSTかを示します。
属性については、メールアドレスを送るだけでは不十分で、部署やグループをロールに変換するルールも決めておきます。
Audience、Destination、Recipientの扱いも記載します。これらの条件を揃えておくと、提案内容と見積もりを同じ基準で比べられます。
契約における責任分界と変更条件
契約方式と管理責任を整理しておけば、仕様変更や認証情報の管理範囲がはっきりします。
- 契約方式：要件が確定した作業は請負、調査や追加検証は準委任か時間単価とします。
- 契約条件：成果物、検収、瑕疵対応、仕様変更、再委託、秘密保持、個人データ、障害連絡。
- 認証情報の責任：メタデータ、設定、証明書、秘密鍵、監査ログの管理者を分けておきます。
全工程を最初から固定価格の請負にすると、古いシステムの仕様が不明だったり、接続先の制約が後から見つかったりしたとき、変更契約が膨らむおそれがあります。
秘密鍵を委託先だけが持つ状態は避け、鍵の保管・更新・緊急失効を自社で統制できる形にします。
SAMLのシステム開発・外注費用の相場と内訳
SAML案件に一律の公開価格はほとんどありません。費用は、ID数、アプリ数、既存改修で変わります。加えて、SCIMやMFAの導入、移行、テスト・運用設計によっても変わります。
ここに示す金額は、一般的な業務システムの相場をSAML／SSO案件に当てはめた推定レンジです。予算化では、PoCと導入設定、改修を分けて見積もり、ライセンスと保守も別の項目として扱います。
方式別の初期費用の幅（20万円台から5,000万円以上）
方式ごとに費用と含まれる範囲が異なるため、金額だけでなく、対象となる構成もあわせて見ます。
- IDaaS設定：代表アプリ1〜3個の標準接続は、20万〜60万円程度です。
- 既存Web改修：SAML SP化の推定レンジは100万〜600万円程度です。
- 認証基盤：複数SaaS連携は500万〜2,000万円、複雑な構成は2,000万〜5,000万円以上になる可能性があります。
IDaaS設定には、初期設定と属性マッピング、MFA方針、受入テストが含まれます。期間は2〜8週間程度ですが、接続調整や社内教育の有無で変わります。
Web改修では、ログイン、セッション、属性・権限連携を扱います。加えて、エラー画面、ログ、証明書更新と総合テストも範囲に入ります。金額は、公式の一律価格ではなく、リサーチノートに基づく推定です。
複数SaaSの基盤には、AD・人事DBとの連携、SCIM、MFAを含む場合があります。端末制御を加えることもあります。複雑な構成は、子会社・取引先・顧客向けのマルチテナント型か、オンプレ・クラウドのハイブリッド型です。
一般的な業務システムには、小規模が50万〜1,000万円、中規模が300万〜5,000万円という目安があります。期間は、小規模が1〜6か月、中規模が3〜12か月です（出典: 業務システム全般_16 一次Q&A、2026年）。
SAML案件では、認証処理そのものより、既存システムとの境界や接続先ごとの例外が費用を左右します。さらに、移行や運用設計の範囲も、費用に大きく関わります。
ID数と追加機能で分けるライセンス費用
サービスごとに課金単位や契約条件が違うため、代表的な料金と適用条件を照らし合わせて比べます。
- HENNGE One Identity Edition：月額300円からです。
- GMOトラスト・ログイン：SSOプロ＋SaaS管理は1ユーザー月額500円です。
- Microsoft Entra ID：P1はユーザー月額899円相当、P2は1,349円相当です。
料金は2026年8月に確認した公式掲載情報です。また、GMOプランはユーザー数30名以上かつ12か月契約とされています（出典: HENNGE株式会社「価格とプラン」、GMOグローバルサイン株式会社「料金・機能」、2026年確認）。
表示価格は税別です。導入支援や追加オプションは、別途見積もりになる場合があります。
Microsoft 365の契約プランにEntra ID機能が含まれる場合があります（出典: Microsoft「Microsoft Entraのプランと価格」、2026年確認）。
条件付きアクセス、IDガバナンス、リスク検出の要否を確認します。加えて、アプリケーションプロキシも必要かどうかを確かめます。
対象ライセンスを確かめたうえで、既存契約を含めた差額で比べます。
3年TCOによる比較
3年TCOは、初期費用だけでなく継続費や追加作業も含めて比べます。
- 合算する費用：初期設定、アプリ改修、ライセンス、インフラ、移行・教育、監視・保守。
- 月額300円の例：200IDで月6万円、年72万円、3年216万円。
- 月額500円の例：200IDで月10万円、年120万円、3年360万円。
実際の契約には、最低ID数や税、割引が加わるほか、契約期間やオプションも関わります。ここで示した金額は試算値のため、最終価格と分けて考えます。
保守費は、初期開発費の年15〜25％程度を参考にできます。ただし、これはSAML固有の公開相場ではありません。
保守の範囲は、証明書更新、接続先の追加、停止の不備への対応で変わります。さらに、IdP・SP障害の切り分け、ログ調査、脆弱性対応の範囲でも変わります。
追加アプリや緊急対応の単価が明確なプランは、3年TCOで有利になる場合があります。
委託先の選定とSAMLの見積比較で確認すべきポイント
IDaaS販売会社、認証基盤のSIer、既存業務システム会社では得意分野が異なるため、現行システムと運用課題を理解し、設計・移行・保守まで担えるかで比べます。
似た条件での実績確認
実績の確認では、件数だけでなく、自社に近い条件と担当範囲を見ます。
- 導入条件：利用者数、アプリ数、IdP・SP、AD・人事DB連携を確認します。
- 実装と運用：レガシー対応、移行方式、保守体制、担当範囲、納品物を確かめます。
- PoCの接続先：属性が多いもの、古い認証方式のもの、外部企業利用のものなど、難しいアプリを選びます。
- PoCの成功条件：権限反映、退職者停止、証明書更新、障害復旧まで確かめる。
近い規模の事例がない場合は、想定リスクと追加費用の条件を質問します。PoCの成功条件をログインだけにしないことで、本番見積もりの精度が上がります。
会社名や導入効果を一般化して示す説明に加えて、委託先の担当範囲と納品物を確認します。
見積書の作業項目と除外項目の横並び比較
見積書では、作業範囲と契約条件を揃えてから、提案同士を比べます。
- 作業範囲：要件定義、設計、接続、改修、ユーザー連携、MFA、ログ、テスト、移行、教育、保守。
- 費用・契約：初期費用、月額・年額、最低数、期間、追加ユーザー・アプリ単価、オプション、支援、保守。
- 引き継ぎと納期：解約時のデータ返却と、要件確定など納期の起算条件を揃えます。
「SAML対応一式」では、対象アプリ数や属性変更の回数、証明書更新支援の有無が分かりません。前提条件と除外項目を金額と並べて見ると、不足している作業に気づきやすくなります。
納期も、発注日からではなく、要件確定、メタデータ受領、テスト環境の準備など、起算条件を揃えて比べます。
自社の5パターンに合う委託先の選び方
自社環境に近い経験は、委託先を絞る目安になります。そこで、該当する構成の実績と対応力を確かめます。
- Microsoft 365中心：Entra IDのライセンスと既存AD連携を活用できる会社を選びます。
- Google Workspace中心：ディレクトリやSaaSを洗い出すところまで支援できる会社を比べます。
- オンプレミス中心：リバースプロキシ、閉域網、冗長化、段階移行の経験を確認します。
- 取引先ごとにIdPが異なる：複数テナントとメタデータ管理の実績を見ます。
- 顧客向けログインを新設：SAML、OIDC、OAuth、MFA、パスキーを使い分ける設計力を重視します。
方式がまだ決まっていないなら、製品を先に販売する会社より、要件と将来の方針を比べたうえで提案できる会社が向いています。
RFPと要件定義に必ず入れたいSAMLの項目
RFPの精度は、見積もりの精度と発注後の変更量に直結します。技術条件に加えて、業務上の理由、対象の利用者やシステム、責任者も示すことが必要です。
メタデータと属性マッピングまでを含む接続仕様
接続仕様では、接続先だけでなく、属性・権限の扱いまで定めます。
- 接続設定：IdP・SP、Entity ID、ACS・SLO URL、バインディング、NameIDを定めます。
- 保護設定：署名アルゴリズム、暗号化の要否、証明書の有効期間を決めます。
- 権限と識別：属性からのロール変換と、メールアドレスなど主キーの選定。
- 属性の反映：退職・異動を次回ログイン時に反映するか、SCIMで即時に反映するかを決めます。
部署や役職、グループは、どのロールへ変換するかを定義します。契約プランも、どのロールへ変換するかを定義します。また、主キーをメールアドレスにするか、従業員番号など不変の識別子にするかも決めます。
SPでは、SAML ResponseのIssuerとAudienceを検証します。加えて、Destination、Recipient、InResponseToも検証します。さらに、NotBeforeとNotOnOrAfterも検証要件に含めます。
証明書・ログ・緊急時対応を含む運用要件
運用項目は、証明書の更新、ログ、障害時対応に分けて定めます。
- 証明書：監視担当、更新前の検証環境、ロールバック、メタデータ変更の承認を決めておきます。
- 通知時期：90日前、60日前、30日前などに通知し、記憶に頼らず更新します。
- ログ：成功・失敗、属性変更、停止、管理者操作、証明書更新の記録と、保存期間、検索権限、出力、SIEM連携。
- 障害対応：緊急ログイン、障害切り分け、SLO失敗時の再ログイン、窓口、SLAを定めます。
SAMLは認証結果を連携する仕組みです。MFAや端末制御、最小権限、ログ監視は、SAMLを入れただけでは自動で完了しません。
セキュリティと受入テストの基準
受入テストでは、正常系だけでなく異常系や情報管理も確認します。
- 認証異常：署名不一致、証明書切れ、時刻ずれ、RelayState不正値を試します。
- 利用者情報：属性欠落、権限変更、退職者、重複IDの状態を確かめます。
- 障害：IdP障害とSP障害の切り分けを確認します。
- 個人情報：アクセス制御、識別・認証、不正アクセス・漏えい防止、委託先管理を確認します。
- 受入成果物：証跡、脆弱性診断、設定、手順書、連絡網、教育資料、コードや設定の引き渡し。
SAML Responseの署名検証とTLS、秘密鍵の保護も欠かせません（出典: OWASP Foundation「SAML Security Cheat Sheet」、2026年確認）。個人情報を扱う際は、個人情報保護委員会のガイドラインも参照します。
SAMLの発注・外注で起こりやすい失敗と対策
ログインの成功だけをゴールにすると、本番移行後に権限や運用の問題が起きます。そこで、失敗を発注の段階で想定し、見積もり、契約、テストに反映します。
「SAML対応」だけの発注で不足する要件
「SAML 2.0対応」とだけ書かれた提案では、必要な機能や作業範囲が見えないことがあります。そこで、提案書では、機能、費用と役割、方式の使い分けを分けて示してもらいます。
- 機能：SLO、属性マッピング、SCIM、MFA、監査ログ、レガシー対応の有無を確認します。
- 費用と役割：標準機能、追加開発、別途ライセンス、委託先の担当範囲を分けます。
- 方式の使い分け：企業SaaSはSAML、新規モバイル・顧客向けはOIDCやパスキーを使う場合があります。
SAMLとOIDCは、どちらが優れているかで選ぶより、用途ごとに併用するほうが移行しやすい場合があります。
OWASPのAuthentication Cheat Sheetは、認証・SSOにOIDC、API認可にOAuthを使う考え方を示しています（出典: OWASP Foundation「Authentication Cheat Sheet」、2026年確認）。
証明書とアカウント停止の運用体制
証明書とアカウント停止は、担当者と手順を定めて管理します。
- 証明書更新：期限監視、更新、事前検証、緊急連絡を保守範囲に入れます。
- 秘密鍵：自社保有か、委託先に作業用権限のみ渡すかを契約に記します。
- 停止対象：SPのローカルアカウント、API・共有アカウント、外部招待。
- 停止手順：退職・契約終了時の手順と、SCIM失敗の検知・手動停止を用意します。
証明書の期限が切れると、設定が正しくても全ユーザーがログインできなくなります。そのため、更新後の確認者と承認者を決めておきます。
製品依存と引き継ぎ不足への契約上の備え
製品依存や引き継ぎに備えて、データ返却、実装の移行性、再委託と保守条件を契約で確認します。
- データ返却：解約時にメタデータ、属性、アプリ一覧、設定、ログ、手順書を受け取ります。
- 方式変更：認証・認可ロジックをIDaaS固有実装から分け、OIDCやパスキーに備えます。
- 再委託：委託範囲、情報アクセス、監査、終了時の削除証明を確認します。
IDaaSには、設定情報やユーザー属性、ログ、ワークフローが蓄積されます。そのため、契約では、保守の受付時間や一次回答、復旧目標を明記します。
計画保守、料金改定、接続先追加の単価も書いておくと、運用後の予算を見通せます。
SAMLのシステム発注に関するよくある質問
発注前には、費用や委託先について確認が必要です。認証方式と契約形態も、あわせて確かめておきます。
SAMLのシステム開発を外注するといくらかかりますか？
IDaaS標準設定は20万〜60万円程度、既存WebシステムのSP化は100万〜600万円程度が目安です。複数アプリ・AD・SCIM・MFAを含む基盤は、500万〜2,000万円程度が推定レンジです。
製品ライセンスや最低契約数は別に計算します。移行と保守も、別々に見積もります。方式と範囲を分けた形で、見積もりを取得してください。
SAMLに強い委託先はどのように選べばよいですか？
利用者規模や接続先、既存認証基盤、レガシー対応が自社に近い会社を選びます。さらに、要件定義から保守までの責任範囲を説明できるかも見ます。
IDaaSの機能、SIerの設計・移行力、既存業務システム会社の改修力を分けて評価し、提案書と見積書の前提条件を比べます。
SAMLではなくOIDCを選ぶべきですか？
既存の企業SaaS連携ではSAMLが適することが多く、新規モバイルアプリや顧客向けサービスではOIDCを優先する場合があります。
全社で一方式に統一するのではなく、接続先や利用者、属性、将来のパスキー対応を整理します。そのため、SAMLとOIDCを併用できる基盤が現実的です。
SAMLの発注は請負と準委任のどちらがよいですか？
要件と成果物が固まった接続設定やアプリ改修は請負、現状調査、PoC、接続先の制約確認は準委任に分ける方法が使いやすいです。
変更管理、検収、障害対応、証明書と秘密鍵の責任分界も明記します。発注後に追加費用が生じる条件を確認してください。
まとめ
発注時は、SAML対応の有無だけでなく、IdP・SPの役割や属性・権限連携、MFAを比べます。さらに、SCIMと監査ログ、証明書更新と障害対応も見ておきます。
利用者と接続先を一覧にし、IDaaS導入、既存改修、個別開発から適切な方式を選びます。
発注前のRFPと比較軸の整理
RFPには、Entity ID、ACS URL、NameIDを記載します。加えて、属性マッピングや署名・暗号化、テストも書き、運用と責任分界まで含めます。
見積もりは、初期開発費に加えてライセンス費や最低契約数、追加アプリを含め、3年TCOで比べます。保守や移行、教育も含めて見ます。
小さな検証から本番への段階移行
PoCと方式選択の手順を踏んでから、本番へ段階的に移行します。
- 代表的なSaaS、既存Webシステム、属性の多いアプリでPoCを行います。
- 正常系と異常系を確認し、接続先に合う認証方式を定めます。
- 企業SaaSはSAML、新規サービスはOIDCやパスキーなどを使い、段階移行します。
将来の方式も見据えた移行計画を立てると、利用者への影響と発注リスクを抑えられます。
SAML開発は、認証機能の実装に加えて、業務や運用の実情を踏まえた進め方が求められます。設計・開発・移行・保守まで支援できる委託先を選ぶことが重要です。
▼全体ガイドの記事
・SAMLのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。