SAMLのシステム開発の発注/外注/依頼/委託方法について

SAMLのシステム開発を発注・外注するなら、SAML対応の有無だけでなく、IdP・SP・ユーザー管理・MFA・監査ログまで含めた認証基盤全体を設計できる委託先を選ぶことが重要です。

本記事では、既存の業務システムをSAML SSOに対応させたい企業の担当者に向けて、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積書の比較方法を順番に解説します。公開されている料金と、SAML連携案件から算出した推定レンジを分けて紹介しますので、自社の条件に当てはめながら検討してください。

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

SAMLのシステムを発注する前に知っておきたい全体像

SAMLは、認証した事実やユーザー属性を別のサービスへ伝える標準プロトコルです。利用者を認証するIdPと、利用者が使う業務アプリやSaaSであるSPの間で、署名付きのSAML Responseを受け渡します。そのため、外注する対象は「SAMLの機能」だけではなく、認証方式、権限、アカウント連携、運用体制を含む業務システムです。

発注前に、どのシステムをIdPにするか、どのシステムをSPにするかを整理します。Microsoft Entra ID、HENNGE One、GMOトラスト・ログイン、OktaなどのIDaaSをIdPにし、社内WebシステムやSaaSをSPとして接続する構成が一般的です。すでにMicrosoft 365を利用している企業はEntra IDを中心に検討し、Google Workspace中心なら既存のディレクトリやIDaaSとの役割分担を比較します。

一方、顧客企業が自社のIdPでログインするB2Bサービスでは、自社がSPになることがあります。子会社や取引先ごとにIdPが異なる場合は、接続先ごとのメタデータ、NameID、属性名、署名方式を管理できる設計が必要です。ここを曖昧にしたまま発注すると、開発後に「SAML対応なのに接続できない」という事態が起こります。

発注形態は大きく三つに分けられます。一つ目はIDaaSの標準機能を導入し、接続設定と運用設計を外注する方法です。二つ目は、既存の社内WebシステムをSAMLのSPとして改修する方法です。三つ目は、複数テナントや独自の認可モデルを持つ認証基盤を個別開発する方法です。

社内SaaSのSSO化が中心なら、標準コネクターを使う導入型が適しています。古いWebシステムや閉域網のアプリが残る場合は、リバースプロキシや認証アダプターを組み合わせます。顧客向けサービスの認証を新規開発する場合は、SAMLだけに固定せず、OIDCやパスキーを併用できる構成にしておくと将来の二重投資を抑えやすくなります。

SAMLシステムの発注・外注はどのように進めますか？

結論からいうと、SAMLの発注は「現状調査と方式比較」「要件定義とRFP作成」「提案・見積比較」「契約と設計」「接続・テスト・移行」の順で進めると失敗を抑えられます。ログイン画面の改修だけを先に依頼するのではなく、アカウントの発行・変更・停止と障害時の運用まで一つのプロジェクトとして扱います。

まず、対象ユーザーを社員、派遣社員、子会社、取引先、顧客に分け、人数と増減の見込みを確認します。次に、接続対象のアプリごとに、SAML対応の有無、現行の認証方式、管理者権限、利用停止方法、データの重要度を一覧にします。認証基盤を選ぶ前に利用者数だけを見ると、取引先ごとのIdP連携やアカウント停止の要件が抜けやすいです。

さらに、Active Directory、人事システム、Microsoft 365、Google Workspaceなど、ユーザー情報の正本を決めます。入社・異動・退職を誰がいつ反映するのか、SCIMやAPIで自動化するのか、手動承認を残すのかを整理します。特に退職者の即時停止が必要なシステムでは、SAML SSOだけでなくプロビジョニングとライフサイクル管理の費用も要件に含めます。

RFPには、目的、対象範囲、現行構成、希望スケジュール、予算の考え方、納品物、選定基準を記載します。SAML固有の項目として、Entity ID、ACS URL、Single Logout URL、IdP initiatedとSP initiatedのどちらを使うか、HTTP-RedirectまたはHTTP-POSTのバインディング、NameID形式、必要な属性、署名・暗号化、証明書の更新方法を並べます。

属性は「メールアドレスを送る」と書くだけでは不十分です。属性名、値の形式、必須か任意か、部署やグループからアプリ内ロールへ変換するルールまで定義します。Audience、Destination、Recipient、時刻の許容範囲、RelayStateの扱い、エラー時に利用者へ表示する内容も、提案会社が見積もれる粒度で示すことが大切です。

契約形態は、要件が固まっている部分を請負契約、調査や追加検証が必要な部分を準委任契約または時間単価契約に分ける方法が現実的です。最初から全工程を固定価格の請負にすると、古いシステムの仕様不明や接続先の制約が発見されたときに、変更契約が膨らむ可能性があります。

契約書や個別契約では、成果物の範囲、検収条件、瑕疵対応、仕様変更の扱い、再委託の可否、秘密保持、個人データの取り扱い、障害時の連絡体制を確認します。特に認証基盤では、SAMLメタデータ、設定ファイル、証明書、秘密鍵、監査ログの管理責任を分けて記載します。秘密鍵を委託先だけが保有する状態は避け、鍵の保管・更新・緊急失効を自社で統制できる形にします。

SAMLのシステム開発・外注費用の相場と内訳

SAML案件には公開された一律価格がほとんどないため、費用はID数、接続アプリ数、既存システムの改修範囲、SCIMやMFAの有無、移行・テスト・運用設計で大きく変わります。以下の金額は、一般的な業務システムの相場をSAML／SSO案件に当てはめた推定レンジです。正式な予算化では、PoC、導入設定、アプリ改修、ライセンス、保守を分けて見積もりを取得してください。

IDaaSの標準コネクター設定だけなら、初期設定、代表アプリ1〜3個の接続、属性マッピング、MFA方針、受入テストを含めて20万〜60万円程度が一つの目安です。期間は2〜8週間程度とされますが、接続先の調整や社内教育が含まれるかで変わります。これは公式一律価格ではなく、リサーチノートに基づく案件推定です。

既存の社内WebシステムをSAML SP化する改修は、ログイン処理、セッション、属性連携、権限変換、エラー画面、ログ、証明書更新、総合テストまで含めて100万〜600万円程度が推定レンジです。複数SaaSとAD・人事DB、SCIM、MFA、端末制御まで含む認証基盤は500万〜2,000万円程度、子会社・取引先・顧客を含むマルチテナント型やオンプレ・クラウドのハイブリッド構成は2,000万〜5,000万円以上になる可能性があります。

一般的な業務システムの目安として、一次Q&Aでは小規模50万〜1,000万円、中規模300万〜5,000万円、期間はそれぞれ1〜6か月、3〜12か月と整理されています（出典: 業務システム全般_16 一次Q&A、2026年）。SAML案件では認証処理そのものより、既存システムとの境界、接続先ごとの例外、移行と運用設計が費用を左右します。

ライセンスは初期費用と別に、ID数、契約期間、対象プラン、追加オプションを確認します。2026年8月に公式料金ページを確認したところ、HENNGE One Identity Editionは月額300円から、GMOトラスト・ログインのSSOプロ＋SaaS管理は1ユーザー月額500円、ユーザー数30名以上、12か月契約と案内されています（出典: HENNGE株式会社「価格とプラン」、GMOグローバルサイン株式会社「料金・機能」、2026年確認）。表示価格は税別で、導入支援や追加オプションは別途見積もりになる場合があります。

Microsoft 365を利用している企業は、Entra IDの機能が契約プランに含まれる場合があります。単体の公式価格は、Entra ID P1がユーザー月額899円相当、P2が1,349円相当と案内されています（出典: Microsoft「Microsoft Entraのプランと価格」、2026年確認）。ただし、条件付きアクセス、IDガバナンス、リスク検出、アプリケーションプロキシなどの必要機能と対象ライセンスを確認し、既存契約を含む差額で比較してください。

見積もりを比較するときは、初期設定費、アプリ改修費、ライセンス費、インフラ費、移行・教育費、監視・保守費を合算します。例えば200IDで月額300円のサービスなら、ライセンス部分だけは単純計算で月6万円、年72万円、3年216万円です。200IDで月額500円なら月10万円、年120万円、3年360万円です。実際の契約では最低ID数、税、割引、契約期間、オプションが加わるため、試算値を最終価格と混同しないことが大切です。

保守費は初期開発費の年15〜25％程度を参考値にできますが、SAML固有の公開相場ではありません。証明書更新、接続先追加、ユーザー停止の不備、IdPやSPの障害切り分け、ログ調査、脆弱性対応をどこまで含むかで変わります。3年TCOでは、安い月額プランよりも、追加アプリや緊急対応の単価が明確なプランが有利になることがあります。

委託先の選定とSAMLの見積比較で確認すべきポイント

SAML対応をうたう会社でも、IDaaSの販売会社、認証基盤のSIer、既存業務システムの開発会社では得意領域が異なります。製品の機能一覧だけで判断せず、自社の現行システムと運用課題をどこまで理解し、設計・移行・保守まで責任を持てるかで比較します。

実績を聞くときは「SAMLを何件やったか」だけでなく、利用者数、接続アプリ数、IdPとSPの構成、AD・人事DB連携、レガシー対応、移行方式、保守体制を確認します。自社と近い規模の事例がなければ、提案会社が想定するリスクと追加費用の条件を質問します。会社名や導入効果を一般化した説明ではなく、担当範囲と納品物を確認することが重要です。

PoCを依頼する場合は、代表的なアプリ一つだけでなく、属性の多いアプリ、古い認証方式のアプリ、外部企業が利用するアプリなど、失敗しやすい接続先を選びます。PoCの成功条件を「ログインできた」だけにせず、権限反映、退職者停止、証明書更新、障害時の復旧まで含めると、本番見積もりの精度が上がります。

見積書は、要件定義、基本設計、SAML接続設定、既存アプリ改修、ユーザー連携、MFA、ログ、テスト、移行、教育、保守に分けてもらいます。「SAML対応一式」のような一行見積もりでは、何個のアプリが含まれるか、属性マッピングの変更は何回までか、証明書更新の支援があるか判断できません。

比較表には、初期費用、月額・年額、最低契約数、契約期間、追加ユーザー単価、追加アプリ単価、オプション、導入支援、保守、解約時のデータ返却を記載します。金額だけでなく、前提条件と除外項目を同じ欄に置くと、安く見える提案の不足分を発見できます。納期についても、発注日からではなく、要件確定、メタデータ受領、テスト環境の準備などの起算条件を揃えます。

すでにMicrosoft 365がある企業は、Entra IDのライセンスと既存のAD連携を活用できる会社を選びます。Google Workspace中心の企業は、ディレクトリやSaaSの棚卸しまで支援できる会社を比較します。オンプレミスのWebシステムが多い企業は、リバースプロキシ、閉域網、冗長化、段階移行の経験を確認します。

取引先ごとにIdPが異なる企業は、複数テナントとメタデータ管理を得意とする会社が候補です。顧客向けログインを新規に作る企業は、SAMLだけでなくOIDC、OAuth、MFA、パスキーを用途ごとに使い分けられる設計力を重視します。方式が決まっていない段階では、製品を先に売る会社より、要件と将来方針を比較して提案できる会社が向いています。

RFPと要件定義に必ず入れたいSAMLの項目

RFPの精度は、見積もりの精度と発注後の変更量に直結します。技術項目は専門用語を並べるだけでなく、業務上なぜ必要なのか、どの利用者・システムに適用するのか、誰が責任を持つのかまで記載します。

最低限、IdP・SPの構成、Entity ID、ACS URL、SLO URL、バインディング、NameID、属性名、署名アルゴリズム、暗号化の要否、証明書の有効期間を記載します。SAML Responseを受け取ったSP側でIssuer、Audience、Destination、Recipient、InResponseTo、NotBefore、NotOnOrAfterを検証することも要件に含めます。

権限連携では、部署、役職、グループ、契約プランなどをどのロールに変換するかを定義します。メールアドレスを主キーにするのか、従業員番号など不変の識別子を使うのかも決めます。退職・異動で属性が変わったときに、次回ログインで反映するのか、SCIMで即時反映するのかによって必要な機能とテストが変わります。

本番運用では、証明書の有効期限をいつ誰が監視し、更新前にどの環境で検証し、問題があればどうロールバックするかを定義します。90日前、60日前、30日前などの通知ルールを設け、証明書更新を担当者の記憶だけに依存しない体制を作ります。IdPやSPのメタデータが変更された場合の承認手順も必要です。

ログ要件では、ログイン成功・失敗、属性変更、アカウント停止、管理者操作、証明書更新を記録し、保存期間、検索権限、エクスポート方法、SIEM連携を確認します。IdP障害時の緊急ログイン、SP障害時の切り分け、SLO失敗時の再ログイン、問い合わせ窓口、SLAもRFPに含めます。SAMLは認証結果を連携する仕組みであり、MFA、端末制御、最小権限、ログ監視まで自動で完了するわけではありません。

正常ログインだけでなく、署名不一致、証明書期限切れ、時刻ずれ、属性欠落、権限変更、退職者、重複ID、IdP障害、SP障害、RelayStateの不正値をテストします。SAML Responseの署名検証やTLS、秘密鍵の保護は、OWASPのSAML Security Cheat Sheetでも重要な確認事項とされています（出典: OWASP Foundation「SAML Security Cheat Sheet」、2026年確認）。

個人情報を扱う場合は、個人情報保護委員会のガイドラインを参照し、アクセス制御、利用者の識別・認証、不正アクセス防止、漏えい防止、委託先管理を確認します。受入条件には、テスト証跡、脆弱性診断、設定一覧、運用手順書、障害連絡網、教育資料、ソースコードや設定の引き渡し範囲を含めます。

SAMLの発注・外注で起こりやすい失敗と対策

SAMLのプロジェクトでは、ログイン成功をゴールにしてしまうと、本番移行後の権限や運用で問題が発生します。よくある失敗を発注段階で想定し、見積もり・契約・テストに落とし込むことが大切です。

「SAML 2.0に対応していること」だけを要件にすると、SLO、属性マッピング、SCIM、MFA、監査ログ、レガシー対応が含まれないことがあります。提案書では対応方式、標準機能、追加開発、別途ライセンス、委託先の担当範囲を分けて表示してもらいます。

また、SAMLとOIDCは優劣だけで選ぶものではありません。企業SaaSの既存連携ではSAMLを継続し、新規のモバイル・顧客向けサービスではOIDCやパスキーを採用するなど、用途別に併用する方が移行しやすい場合があります。OWASPのAuthentication Cheat Sheetも、認証・SSOにはOIDC、API認可にはOAuthを使う考え方を示しています（出典: OWASP Foundation「Authentication Cheat Sheet」、2026年確認）。

証明書の期限切れは、設定が正しくても全ユーザーがログインできなくなる代表的な障害です。委託先の保守範囲に期限監視、更新作業、事前検証、緊急連絡を含め、更新後の確認者と承認者を決めます。自社が秘密鍵を保有するのか、委託先が作業用の権限だけを持つのかも契約に残します。

アカウント停止も、SAMLログインを止めるだけでは不十分です。SP側に残るローカルアカウント、APIトークン、共有アカウント、外部招待ユーザーを確認し、退職・契約終了時の停止手順を定義します。SCIM連携を採用する場合でも、連携失敗時の検知と手動停止の手順を用意してください。

IDaaSを導入すると、設定情報、ユーザー属性、ログ、ワークフローが製品に蓄積されます。解約や別製品への移行に備え、メタデータ、属性マッピング、アプリ一覧、設定値、ログのエクスポート、運用手順書をどの形式で受け取れるか確認します。将来のOIDCやパスキー対応を妨げないよう、アプリ側の認証・認可ロジックをIDaaS固有の実装から分離することも有効です。

委託先が再委託する場合は、再委託先の範囲、アクセスできる情報、監査方法、終了時の削除証明を確認します。保守契約を結ぶときは、問い合わせの受付時間、一次回答、復旧目標、計画メンテナンス、料金改定、接続先追加の単価を明記し、運用開始後の予算が読める状態にします。

SAMLのシステム発注に関するよくある質問

SAMLの外注では、費用、開発会社の選び方、SAMLと他の認証方式の関係について質問が多く寄せられます。ここでは、発注前に判断しやすいように結論から回答します。

IDaaSの標準設定は20万〜60万円程度、既存WebシステムのSP化は100万〜600万円程度、複数アプリ・AD・SCIM・MFAを含む認証基盤は500万〜2,000万円程度が推定レンジです。製品ライセンス、最低契約数、移行、保守は別に計算する必要があるため、方式と範囲を分けた見積もりを取得してください。

自社と似た利用者規模、接続先、既存認証基盤、レガシー対応の実績があり、要件定義から保守まで責任範囲を説明できる会社を選びます。IDaaSの機能、SIerの設計・移行力、既存業務システム会社の改修力を分けて評価し、提案書と見積書の前提条件を横並びで比較してください。

既存の企業SaaS連携ではSAMLが適していることが多く、新規のモバイルアプリや顧客向けサービスではOIDCを優先する場合があります。全社で一つに統一するのではなく、接続先、利用者、必要な属性、将来のパスキー対応を整理し、SAMLとOIDCを併用できる認証基盤を選ぶことが現実的です。

要件と成果物が固まっている接続設定やアプリ改修は請負、現状調査やPoC、接続先の制約確認は準委任に分ける方法が使いやすいです。契約方式だけでなく、変更管理、検収条件、障害対応、証明書と秘密鍵の責任分界を明記し、発注後に想定外の追加費用が出る条件を確認してください。

まとめ

SAMLのシステムを発注・外注するときは、SAML対応の有無だけでなく、IdPとSPの役割、属性・権限連携、MFA、SCIM、監査ログ、証明書更新、障害対応まで含めて比較します。まず利用者と接続先を棚卸しし、IDaaS導入、既存システム改修、個別開発のどれが適切かを判断してください。

RFPにはEntity ID、ACS URL、NameID、属性マッピング、署名・暗号化、テスト、運用、責任分界を記載します。見積もりは初期開発費だけでなく、ライセンス、最低契約数、追加アプリ、保守、移行、教育を含む3年TCOで比べると、提案の違いを正しく把握できます。

最初から全システムを切り替えず、代表的なSaaS、既存Webシステム、属性の多いアプリでPoCを行い、正常系と異常系を確認します。そのうえで、企業SaaSはSAML、新規サービスはOIDCやパスキーなど、将来の認証方式も見据えた段階移行を計画すると、利用者への影響と発注リスクを抑えられます。

SAMLのシステム開発は、認証機能の実装だけで終わるプロジェクトではありません。自社の業務と運用を理解し、設計・開発・移行・保守を一貫して支援できる委託先に相談することで、安全性と費用の両面を納得できる形に整えられます。

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