シングルサインオン（SSO）とは｜発注判断5つの基準と選び方チェックリスト

「社内で使う SaaS が増えてきたので、SSO（シングルサインオン）の導入を検討してほしい」——経営層や上長からこう指示され、担当としてアサインされた情報システム部門の方は少なくないはずです。パスワード使い回しや退職者アカウントの放置は監査でも必ず指摘される項目であり、SSO 導入は正しい方向性の一つです。

一方で、「では、どの製品を選べばよいか」「そもそも自社に本当に必要か」「発注前に何を決めておけばベンダー営業に振り回されずに済むか」となると、判断の物差しを持たないまま話が進んでしまうケースが多く見られます。SSO はセキュリティを強化する仕組みでありながら、選定を誤れば「SSO が止まると全業務が止まる」という単一障害点（SPOF）を新たに抱え込むことにもなり、投資対効果と運用リスクの両面を同じ精度で見極める必要があります。

しかも SSO 製品は、対応プロトコル・MFA（多要素認証）オプション・SCIM 連携・監査ログ・オンプレ対応・料金プランなど、比較すべき観点が多く、ベンダー資料をそのまま見比べても意思決定にはたどり着けません。まず「自社側の判断軸」を固めない限り、複数社比較を主導することは困難です。

本記事では、発注者の立場から SSO 導入を判断するための考え方を、SSO の基本概念、導入すべきかを見極める前提条件、発注判断の5つの基準、RFP に盛り込む項目、陥りがちな失敗パターン、そして最後に発注前チェックリストと次のアクションという流れで解説します。読み終わったときに、「自社は SSO を導入すべきか」を上長・経営に説明できる材料と、ベンダー選定を主導するための判断軸が手元に残る構成にしています。

—Free Download / 資料ダウンロード

【サンプル】システム開発 提案依頼書（RFP）

この資料でわかること

システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。

こんな方におすすめです

• 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
• 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
• 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

シングルサインオン（SSO）とは？発注者視点で押さえる基本

SSO 導入の判断軸を検討する前に、まず発注者として最低限押さえておきたい基本を整理します。技術詳細ではなく「発注時にどんな選択肢が発生するのか」を理解することが目的です。

SSO の定義と「1回の認証で複数サービスにログイン」の意味

シングルサインオン（Single Sign-On、以下 SSO）は、1回の認証で、連携している複数のクラウドサービス・社内システムにログインできる状態を実現する仕組みです。利用者は SSO サービス（IDaaS 等）にサインインするだけで、Microsoft 365・Google Workspace・Salesforce・Slack・Box などの SaaS を、それぞれ ID とパスワードを入力し直すことなく利用できます。

発注者の視点では、SSO は単なる「ログイン便利ツール」ではなく、ID 管理（アイデンティティ管理）の統合基盤と捉えるのが正確です。ログイン一元化と同時に、以下の3つが同時に実現できる点が、導入価値の中心にあります。

• 認証を1箇所に集約することで、多要素認証（MFA）・条件付きアクセス（デバイス・IP・時間帯による制御）を横断的に適用できる
• 入退社に伴うアカウントの発行・停止（プロビジョニング／デプロビジョニング）を、SCIM 等の連携で自動化しやすくなる
• 「誰が・いつ・どのサービスにログインしたか」の監査ログを一元的に取得できる

一方で、「1回の認証で複数サービスにログインできる」ということは、裏を返せば SSO が止まると連携先すべてに入れなくなるということでもあります。この点は後半で「単一障害点リスク」として詳しく扱います。

発注者が理解すべき代表的な認証方式の位置づけ

SSO の実現方式にはいくつか種類があり、発注時にベンダーから提示される言葉としては、少なくとも以下の名称が登場します。全部を実装レベルで理解する必要はありませんが、「何のためにどの方式が使われるか」の位置づけは押さえておくと、ベンダー比較で見落としを防げます。

発注者としてまず確認すべきは、「連携したい SaaS・社内システムが SAML 2.0 または OIDC に対応しているか」です。ここが「代行入力型でしか対応できない」となると、監査要件や運用コストの前提条件が大きく変わるためです。

IDaaS（クラウド型）と自社構築（オンプレ型）の全体像

SSO の提供形態は、大きく クラウド型（IDaaS） と オンプレ型（自社構築） に分かれます。近年は IDaaS（Identity as a Service）が主流ですが、既存の Active Directory 資産・オンプレアプリの多さによっては、両者のハイブリッド構成が最適解になるケースもあります。

• IDaaS（クラウド型）: サービスとして提供される SSO 基盤。Microsoft Entra ID（旧 Azure AD）、Okta、OneLogin、TrustLogin、GMO トラスト・ログインなど。初期構築負担が軽く、SaaS 連携テンプレートが豊富。ユーザー単価課金が主流
• オンプレ型: 自社サーバーに SSO 基盤を構築する方式。オンプレ独自アプリが多い環境や、認証情報を社外に置きたくない業種で選択される。構築・運用の内製工数が大きく、近年の選定では少数派

発注者としては、まず 「自社は IDaaS 前提でよいか、オンプレ型も検討対象か」 を最初に決める必要があります。既存の Active Directory を活用したい場合も、多くは AD をアイデンティティ源としつつ IDaaS を上位に置く「ハイブリッド構成」に落ち着きます。

SSO 導入を今検討すべきかを見極める前提条件

「経営から検討を指示されたから」だけで発注に進むのは危険です。SSO 導入は投資規模が中〜大となるケースが多く、導入効果が出やすい前提条件と、逆に「今はほかの対策を優先すべき」ケースがあります。ここは Go/NoGo を上長・経営に説明する材料として、必ず自分の言葉で整理しておきたい部分です。

導入効果が出やすい前提条件（SaaS 数・利用者数・退職者対応頻度）

SSO の投資対効果が明確に出やすいのは、以下のような条件が揃っている環境です。

• 業務利用中の SaaS が概ね5サービス以上: パスワード管理コスト・アカウント棚卸しコストが SSO 導入コストを上回る目安
• 利用者が100名以上: ユーザー単価課金の総額と、削減される情シス工数・利用者のログイン工数のバランスが取りやすい
• 入退社・組織異動が一定頻度で発生している: 退職者アカウントの停止漏れが監査指摘のリスクを高めるため、SCIM 連携による自動化の効果が大きい
• 監査対応（ISMS・Pマーク・SOC2 等）が必要: 認証情報の集約・監査ログの一元管理は、監査対応工数の削減に直結する
• リモートワーク・BYOD が浸透している: 場所・デバイスを問わないアクセス制御と MFA の適用が、ゼロトラスト方針とも整合する

とくにクラウド利用が拡大している環境では、SaaS 側の統制設計と社内の情報セキュリティ基盤の関係を整理しておく必要があります。監査対応・クラウド利用時の内部統制の観点で押さえておきたい実務は、SOC2レポートとクラウドセキュリティやIT ガバナンスと情報セキュリティ基礎も参考にしてください。

上記のうち複数が該当するなら、SSO 導入の検討価値は明確にあります。逆に、以下の場合は Go/NoGo の判断を保留すべきです。

導入前に SSO 以外を優先すべきケース

• 業務 SaaS が 2〜3 サービス程度: 各 SaaS のパスワードマネージャー（ブラウザ内蔵機能や既存のパスワード管理ツール）＋ MFA 強制で、投資対効果的には十分なケースがある
• ID 台帳が Excel 管理で整備されていない: SSO 導入以前に、「そもそも誰がどのサービスを使っているか」の棚卸しが先。IDaaS を導入しても、連携対象を洗い出せなければ効果が出ない
• Active Directory 自体の整理が未着手: AD のグループ設計・OU 設計が実態と乖離している場合、それを引きずったまま IDaaS に連携すると運用が破綻する
• 予算・体制的に MFA まで到達できない: SSO 単体では「1つのパスワードで全部入れる」状態を作るだけで、MFA なしではむしろセキュリティが劣化する。MFA 前提の予算が確保できないなら導入を見送るべき

とくに 「ID 台帳整備が未着手」 の状態で SSO を発注しても、期待した効果は出ません。この場合は、まず ID 棚卸しと AD/クラウドディレクトリの整理を先行させるのが正解です。

Go/NoGo を判断する社内チェックリスト

上長・経営に Go/NoGo を説明する前に、以下を社内で確認します。

• 業務利用中の SaaS 一覧（想定される連携対象）は洗い出せているか
• 直近1年間の入退社・組織異動の件数と、それに伴うアカウント停止・棚卸しの工数はどの程度か
• 監査（内部監査・外部監査）で指摘された事項に、パスワード管理・アカウント棚卸しが含まれているか
• ID 管理の起点となるディレクトリ（Active Directory / Microsoft Entra ID / Google Workspace 等）は、実態と一致しているか
• MFA の導入・運用を前提として予算・利用者説明・端末対応が可能か

これらに「概ね Yes」と答えられるなら、次の「発注判断の5つの基準」に進んで問題ありません。「No」が多い項目があれば、そこを SSO 導入と並行または先行して対処する計画を立てる必要があります。

発注判断で押さえるべき5つの基準

ここからが本記事の中核です。ベンダー営業を受ける前に、発注者側で「この5つの観点で製品を判断する」という物差しを固めておきます。順序も重要で、「前提となる連携範囲 → 求める機能 → 提供形態 → コスト → リスク」の流れで検討していきます。

基準1「対応プロトコルと連携範囲」

最初に押さえるべきは、自社が SSO で連携したいサービスが、その製品でカバーできるかです。ここで齟齬があると、後段のコスト検討・体制検討がすべて意味を失います。

具体的には以下を確認します。

• 連携したい主要 SaaS が、その IDaaS 製品の「連携テンプレート（コネクタ）」にリストアップされているか
• リストにない SaaS も、SAML 2.0 または OIDC 対応であればカスタム連携で追加できるか（追加の可否・料金・工数）
• SCIM によるユーザー自動プロビジョニング／デプロビジョニングは、どの SaaS で対応可能か
• Active Directory との連携（オンプレ AD との同期・パススルー認証・ハイブリッド ID 構成）は、どの方式が可能か
• オンプレ独自業務システム（勤怠管理・会計・基幹系）は、どの方式（エージェント／リバースプロキシ／代行入力）で連携するか

とくに SCIM 対応の粒度 はベンダー資料上「対応」と書かれていても、実際は特定 SaaS の一部機能に限定されるケースがあります。「連携できます」の一言で終わらせず、対象 SaaS ごとに個別に確認する姿勢が重要です。

基準2「認証方式・多要素認証（MFA）と条件付きアクセス」

SSO は「1つのパスワードで全部入れる」状態を作る仕組みなので、MFA と条件付きアクセスをセットで検討する必要があります。MFA のない SSO は、むしろセキュリティを劣化させます。

発注前に決めておくべき事項:

• MFA の要件: TOTP（Authenticator アプリ）・SMS・プッシュ通知・FIDO2 セキュリティキー・生体認証のうち、どこまで求めるか
• 条件付きアクセスの範囲: 社外ネットワークからのアクセス時のみ MFA・特定デバイス（会社支給端末）以外は接続拒否・時間帯制御 など
• リスクベース認証: 通常と異なるロケーション・端末からのログインを検知して追加認証を要求する機能の要否
• 例外運用: 派遣・業務委託・外部監査人などのアクセス制御をどう扱うか

MFA・条件付きアクセスは製品のグレード（Enterprise プランなど）でしか提供されないケースが多く、「基本プランで見積を取ったら MFA が別料金だった」という失敗に直結します。MFA・条件付きアクセスの要件を先に定義してから見積依頼することを強くおすすめします。

外部人材（業務委託・派遣・複業）を活用している場合、認証・アクセス制御の設計は特に重要です。認証設計を含めたゼロトラストの考え方については、ゼロトラストとは？や、デジタル庁の「ゼロトラストアーキテクチャ適用方針」（PDF）なども参考になります。

基準3「クラウド型（IDaaS）／オンプレ型と AD 統合方針」

提供形態の選択は、既存の ID 基盤との整合性で決まります。

• フル IDaaS（クラウドディレクトリを起点にする）: 既存 AD への依存が小さい、あるいは AD を廃止したい場合。Microsoft Entra ID / Okta / Google Workspace のディレクトリを主にする構成
• ハイブリッド（AD ＋ IDaaS）: 既存の AD が主要な人事情報源で、オンプレ資産（ファイルサーバー・オンプレアプリ）が多い場合。AD Connect 等で AD → IDaaS へ同期する構成
• オンプレ SSO: 認証情報を社外に一切出さない方針、または法規制上クラウド利用が制限されている場合

多くの中堅企業ではハイブリッド構成が現実解になります。この場合、以下の設計判断が必要です。

• アイデンティティの起点をどこに置くか（AD が原本 / IDaaS が原本 / 両方向同期）
• AD 側のグループ・OU 設計は SSO 連携に耐えられる状態か（実態と乖離している場合は整理が先）
• AD の可用性が SSO の可用性に直結することを許容できるか（AD が落ちると IDaaS 経由の認証も影響を受ける構成があるため）

「とりあえず現状の AD をそのまま IDaaS に同期する」で発注すると、AD 側の整理不足がそのまま SSO 環境の運用負荷になります。

基準4「費用対効果（TCO）」

費用は「ライセンス料」だけを見るのではなく、TCO（Total Cost of Ownership、総所有コスト） で捉えます。

発生するコスト（3年 TCO の想定）

• 初期費用（構築・設定・連携）
• ユーザー単価 × 利用者数 × 期間
• オプション費用（MFA・条件付きアクセス・監査ログ・SCIM 連携・カスタムアプリ対応）
• 保守運用費用（社内工数・ベンダー保守）
• 教育・利用者説明コスト（初期展開時）

削減される定量効果（試算のフレーム）

• ログイン工数削減: 利用者数 × 1人あたり年間ログイン回数 × ログイン所要時間の短縮分 × 平均時給
• アカウント発行・停止工数削減: 入退社件数 × 1件あたり作業時間の削減分 × 情シス人件費単価
• 監査対応工数削減: 監査回数 × 1回あたり削減時間 × 情シス人件費単価
• アカウント放置リスクの回避: 退職者アカウント放置による情報漏えい発生時の想定損害額 × 発生確率の低下分

すべての効果を精緻に金額化する必要はありませんが、上長・経営に説明する際に「何がどの程度削減される想定か」を数字で示せる状態を目標にします。感覚値の説明では稟議は通りません。

基準5「単一障害点リスクと運用体制の適合性」

競合記事では「デメリットの一つ」として軽く扱われがちですが、発注判断では最重要基準の一つとして扱うべき論点です。SSO は認証を1箇所に集約する以上、その1箇所が止まると連携先すべてに入れなくなるという性質を持ちます。

発注前に必ず確認すべき事項:

• ベンダー側の SLA: 99.9% / 99.95% / 99.99% など、稼働率保証と補償条件
• ベンダー側の冗長化構成: マルチリージョン・アクティブ／アクティブ・障害時のフェイルオーバー
• 緊急時のバイパス経路: SSO が停止した場合の各 SaaS への緊急ログイン手段（管理者用のブレイクグラス アカウント、SaaS 側の直接ログイン維持など）
• 障害検知と通知: ベンダーの障害情報がどのように通知されるか、社内の周知フロー
• 社内運用体制: SSO のトラブル一次対応を情シス何名で担うのか、24時間対応が必要か

情報処理推進機構（IPA）の「情報セキュリティ10大脅威 2026」などでも、認証情報の集約・多要素認証の適用は組織部門の対策として繰り返し取り上げられています。ただし、そのメリットの裏返しとして「認証基盤自体の可用性」への配慮も同時に必要になります。

運用体制との適合性も見逃せません。IDaaS は導入すれば完成ではなく、連携先追加・SCIM 設定変更・MFA 例外運用など、継続的な運用が発生します。この工数を、情シスの現体制で吸収できるかを冷静に見積もる必要があります。体制が薄い場合は、ベンダー保守サービスや外部の運用支援を組み合わせる前提で TCO を計算すべきです。

RFP（提案依頼書）に盛り込むべき項目と発注前に社内で決めておくこと

判断軸が固まったら、それをベンダー選定プロセスに落とし込みます。ここでの主戦場は RFP（提案依頼書） ですが、RFP を書き始める前に、社内で確定させておくべき事項があります。

発注前に社内で確定させる10項目チェックリスト

以下の10項目を、RFP 発行前に社内で確定させておくことをおすすめします。ここが曖昧なままだと、ベンダーからの提案が横並びでない状態で返ってきて、比較のしようがなくなります。

1. 対象利用者数（現行・3年後の想定を含む）
2. 対象 SaaS・社内システムの一覧（優先度付き。必須／推奨／将来検討 の3層で区分）
3. 必須プロトコル（SAML 2.0 / OIDC / SCIM のどれを必須とするか）
4. MFA 要件（対応方式・強制範囲・例外運用）
5. 条件付きアクセス要件（社外接続・特定デバイス・時間帯）
6. 既存 Active Directory の扱い（維持／段階的縮小／廃止）
7. オンプレ独自業務システムの扱い（対象／対象外／将来検討）
8. 可用性・SLA 要件（求める稼働率・障害時対応時間）
9. 予算レンジ（初期・年間ランニング・3年 TCO）
10. 稼働開始希望時期と展開計画（PoC → 部分展開 → 全社展開）

これらは「厳密な要件書」というより、社内での合意事項として位置づけます。ここで合意できていないまま RFP を出すと、ベンダーの解釈で提案がバラバラになり、比較で疲弊します。

RFP に記載する必須項目

RFP には以下を必ず含めます。

• 背景・目的: SSO 導入に至った経緯・解決したい課題
• 対象範囲: 上記チェックリストの1〜7を要件として明示
• 機能要件: 必須／推奨に分けて記載（マストとナイスの区別を明確にする）
• 非機能要件: SLA・データ保管地域・監査ログ保持期間・障害時対応
• スケジュール: RFP 発行日・質疑期限・回答期限・提案書提出期限・PoC 期間・稼働開始希望時期
• 評価基準: 提案書のどの項目を、どの重みで評価するか（機能適合度・コスト・保守体制・実績など）
• 提出物の指定: 提案書・見積書・想定スケジュール・PoC 計画・参考事例

とくに 評価基準を先に開示する ことは、ベンダーに「何を訴求すればよいか」を明示することになり、比較しやすい提案が返ってきます。機能要件・非機能要件の書き方に不安がある場合は、セキュリティ要件定義ガイドも併読すると、抜け漏れを潰しやすくなります。

ベンダー比較で見落としがちな評価観点

見積書の金額だけで比較すると、以下のような後から効いてくる論点を見落とします。

• SCIM 対応の粒度: 「SCIM 対応」と書かれていても、対象 SaaS ごとに実装差がある。連携したい SaaS 名を挙げて個別確認する
• カスタムアプリ対応: 自社の内製アプリや、コネクタ未提供の SaaS への対応可否・追加費用
• 監査ログの保持期間・エクスポート方法: 標準保持期間・延長料金・監査ツールへの連携可否
• サポート対応時間・言語: 障害発生時の一次対応の受付時間、日本語対応の有無、24時間サポートの有無
• 契約期間・解約条件: 3年契約でユーザー単価が下がる代わりに、途中解約の違約金が発生するケースがある
• 料金プランの変更条件: 利用者増加時の単価変動、プランアップグレード時の初期費用
• 導入支援の範囲: どこまでがベンダー側の作業で、どこから自社側の作業か（役割分担マトリクス）

これらは、提案書と見積書だけでは読み取りにくいため、質疑応答フェーズで書面で確認しておくことをおすすめします。

SSO 導入で発注者が陥りがちな失敗パターンと回避策

ここでは、発注前に潰しておけば避けられた失敗パターンを紹介します。いずれも実際に起こりうるものなので、自社の状況に照らして「同じ穴に落ちないか」を確認してみてください。

失敗パターン1「連携できると聞いた業務システムが SAML 未対応だった」

症状: ベンダー営業から「主要 SaaS には全て対応しています」と説明を受け発注したが、連携予定のうち1つが実は SAML 未対応で、代行入力型でしか対応できないと後から判明。監査観点で NG となり、追加開発が発生した。

回避策: 連携対象のリストを RFP に含め、「対象 SaaS 名を明示した上で、対応プロトコルと連携方法（SAML / OIDC / 代行入力 / エージェント）を提案書に記載してもらう」 ように依頼する。「対応可能」の一言で済ませないこと。

失敗パターン2「MFA が上位プラン必須で予算超過した」

症状: 基本プランの見積を取って稟議を通したが、実装フェーズで「MFA を有効化するには上位プランへのアップグレードが必要」と判明。ユーザー単価が跳ね上がり、予算超過で再稟議になった。

回避策: MFA・条件付きアクセス・SCIM 連携・監査ログ延長など、運用に必要なオプションを最初から見積に含める。「基本プランの単価」ではなく、「自社が実際に使う構成での単価」で比較する。

失敗パターン3「SSO 停止で全業務が止まる緊急事態への備えがなかった」

症状: SSO ベンダー側の障害で数時間サービス停止が発生し、連携している全 SaaS にログインできず、全社の業務が実質停止した。管理者側にも緊急ログインの手段が用意されていなかった。

回避策: 発注前に 「SSO が停止した場合の緊急時対応手順」 をベンダーと共同で設計する。具体的には、緊急時用の管理者アカウント（ブレイクグラス アカウント）を SaaS 側に温存する、代表的な業務システムには直接ログインできる経路を残す、障害発生時の社内周知フローを事前に決めておく、といった対策を組み合わせます。

失敗パターン4「退職者アカウントの棚卸しが自動化されず監査指摘が残った」

症状: SSO は導入したが、SCIM 連携が一部 SaaS でしか動かず、退職者アカウントの停止が手動運用で残り続けた。監査で「SSO 導入後も退職者アカウントの停止漏れがある」と指摘され、SSO 導入の効果自体が疑問視された。

回避策: 発注前に 連携対象 SaaS ごとの SCIM 対応状況（有無・対応範囲）を個別確認する。SCIM 対応が薄い SaaS については、代替手段（API 連携・定期的な手動棚卸しの徹底）をあらかじめ設計しておく。

失敗パターン5「オンプレ独自業務システムの SSO 対応が追加開発になり総額が跳ねた」

症状: 主要 SaaS は SSO で問題なく連携できたが、オンプレの独自業務システム（勤怠・会計・基幹系）が SAML 非対応で、エージェント型・リバースプロキシ型・独自改修などの選択を迫られた。想定外の追加開発費が発生し、投資対効果の説明が難しくなった。

回避策: 発注前の「対象システム棚卸し」で、オンプレ独自業務システムを SSO の対象に含めるかを明示的に判断する。含める場合は、SAML 対応の可否をベンダーおよびシステム所管の開発ベンダーと事前確認し、追加開発費の見積を取っておく。含めない場合は、「これは SSO の対象外である」ことを社内で合意し、代替のセキュリティ対策（IP 制限・VPN 経由アクセス等）を明確にする。

発注前チェックリストと次のアクション

ここまでの内容を、実際に社内で使えるチェックリスト形式でまとめます。持ち帰りやすい形にしていますので、社内会議・上長への相談・ベンダー選定の各フェーズで参照してください。

発注判断の Go/NoGo を確定させる社内確認事項

以下の項目に一つずつ答えを持って、Go/NoGo を判断します。

• 業務利用中の SaaS 数と利用者数、直近1年の入退社件数は、SSO 投資の目安（SaaS 5種以上・利用者100名以上・入退社が一定頻度）を満たすか
• ID 台帳・Active Directory の実態は、SSO 連携に耐える整理状態か
• MFA を前提とした予算・体制・利用者説明が確保できるか
• 監査（内部監査・外部監査）でパスワード管理・アカウント棚卸しの指摘があるか
• SSO 導入で削減される工数・リスク回避額を、金額換算で説明できるか

すべてに前向きに答えられるなら Go。答えられない項目があるなら、そこを SSO 導入と並行または先行して整理する計画を立てます。

経営・稟議向け説明ポイント（効果・リスク・投資額）

上長・経営に説明する際は、以下の3点をセットで提示します。

• 効果: 情シス工数削減（アカウント発行・停止・棚卸し・監査対応）・利用者工数削減（ログイン時間）・監査指摘の解消・退職者アカウント放置リスクの低減
• リスク: 単一障害点化（SSO 停止時の業務停止リスク）・オプション追加による予算増・既存 AD／オンプレ資産との整合コスト
• 投資額: 初期費用・3年 TCO・オプション費用・保守運用費用

「効果だけを強調する」提案は逆に信頼性を落とします。リスクとその対策までセットで提示できる状態が、稟議を通す上で重要です。

RFP 作成・ベンダー選定に進む前の準備事項

Go 判断が出たら、以下の順序で進めることをおすすめします。

1. 社内合意事項の確定（前述の10項目チェックリストを完成させる）
2. RFI（情報提供依頼書）の発行（複数ベンダーから概要情報を集める段階。省略も可）
3. RFP（提案依頼書）の作成（本記事の RFP 項目を参照）
4. 提案書・見積書の受領と比較（評価基準に沿ってスコアリング）
5. PoC（概念実証）（1〜2製品に絞って、主要 SaaS 連携・MFA 動作・SCIM 連携を実環境で確認）
6. 契約・キックオフ（役割分担マトリクス・展開計画・SLA・障害時対応手順を書面で確認）

外部人材の活用が絡む場合や、認証設計そのものを内製できるリソースが不足している場合は、選定・PoC のフェーズで 認証・セキュリティ設計の知見を持つ技術パートナーの助言を得る ことも有効です。ベンダー中立の立場でレビューしてくれる第三者がいると、ベンダー営業に振り回されずに済みます。

SSO の発注判断は、「便利ツールの導入」ではなく「認証基盤という重要インフラの選定」です。判断軸を持たないままベンダー営業に付き合うと、後から予算・運用・監査のいずれかでほころびが出ます。本記事のチェックリストと5つの基準を持ち帰り、社内合意を固めた上で、次のアクションに進んでください。

—Free Download / 資料ダウンロード

【サンプル】システム開発 提案依頼書（RFP）

この資料でわかること

システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。

こんな方におすすめです

• 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
• 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
• 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。