なぜWebサービスにはSSOやMFAが実装されないのか

どうも おかしん です。

近年、X（旧Twitter）などのSNSで、情シス（情報システム部門）の方々が「SSO（シングルサインオン）やMFA（多要素認証）を実装してほしい」と、様々なWebサービスに対して要望や苦言を発信しているのをよく目にします。

私自身も、先日 2026年の今、なぜSSOが重要なのか という記事を書きました。

その中で私は、SSO、MFA、最低限の監査ログ、管理者保護は、できるだけ基本機能側へ寄っていってほしいと書きました。高度な自動化、詳細な権限、長期ログ保持、SIEM連携、複雑なワークフロー、専任サポートを上位プランにするのは分かる。ただ、会社として安全に使うための最低条件まで高いプランに閉じ込めるのは健全ではない、という話です。

前回の記事の主張は、今でも変わっていません。SSO、MFA、ログは、セキュリティ上は「高級機能」ではありません。会社でWebサービスを使うなら、退職者を止める、認証を強くする、誰が何をしたか追えるようにする。これは本来、基本的な統制です。

一方で、こうした発信には、ある種の「情シスのポジショントーク」的な側面もあるのではないかと思っています。

情シスやセキュリティ担当の立場から見れば、SSOやMFAやログがほしいのは当然です。実際、その要求は正しい。ただ、Webサービスも一つのビジネスです。ビジネスとして実装する意義があるか、どれくらいの顧客が使えるのか、サポートできるのか、契約や売上に効くのか。そうした判断によって、機能が提供されるかどうかが決まる現実があります。

特に、宿泊、飲食、小売、レジャー、施設運営のような現場型のBtoBtoCサービスでは、話はさらに複雑です。

「SAML/SSOを付けてください」「MFAを強制できるようにしてください」「監査ログを出してください」という要求は正しい。でも、その機能名のまま投げても、プロダクトのロードマップにも、現場の運用にも、購買判断にも乗りにくいことがあります。

この記事では、なぜWebサービスにはSSOやMFAがなかなか実装されないのかを、開発企業側と情シス側の両方の視点、特にビジネス上の観点から整理します。

「SSOやMFAを付けてほしい」は正しい

まず前提として、SSOやMFAやログを求めること自体は正しいです。

Webサービスを企業で使う以上、アカウント管理、退職者停止、パスワード管理、管理者権限、監査ログは避けて通れません。サービスごとにIDとパスワードが散らばり、退職者の停止が手作業になり、管理者操作のログが見えない状態は、会社として説明しにくい状態です。

CISAのSecure by Demand Guide でも、ソフトウェアの購入者が確認できる観点として、ベースライン版にログやSSOのような基本的なセキュリティ機能が含まれるか、標準ベースのSSOを追加費用なしで統合できるか、MFAやパスキーのような認証を既定・無償で使えるか、SaaSでは少なくとも6か月分のセキュリティログを追加費用なしで提供するか、といった項目が挙げられています。

また、NCSCのSaaS安全利用ガイダンス でも、SaaS利用時にはユーザーのオンボーディングとオフボーディング、信頼できるIDソース、SSO、MFA、直接認証時のMFA、管理者保護、監査ログ、緊急アクセスなどが扱われています。

つまり、SSOやMFAやログを求めることは、情シスのわがままではありません。会社としてWebサービスを安全に使うための、かなり基本的な要求です。

ただ、ここで1つ分けて考えたいことがあります。

基本的な統制であることと、すべての市場で同じ実装形態がそのまま普及することは別です。

ここを混ぜると、「正しいことを言っているのに、なぜか届かない」という状態になります。

エンタープライズIAMが前提にしている利用者像

SSOやSCIMやMFAが強く効くのは、次のような前提があるときです。

• 利用者ごとに1人1アカウントがある
• 会社メールや社員番号など、安定した識別子がある
• Microsoft Entra ID、Okta、Google Workspace などのIdPがある
• 入社、異動、退職を中央で管理している
• 管理者が設定変更やログ確認を担える
• 利用者がMFAやパスキーを設定、復旧できる
• SaaSの契約者と日々の利用者が同じ組織内にいる

この前提では、SAMLやOpenID ConnectによるSSOは非常に強いです。IdP側でMFAや条件付きアクセスをかけられます。退職者の新規ログインを止められます。SCIMがあればユーザー作成、属性変更、無効化も自動化できます。ログをIdPやSIEMに寄せれば、事故時の調査もしやすくなります。

だから、エンタープライズSaaSでは「SAML/SSOに対応していますか」「SCIMに対応していますか」「監査ログをエクスポートできますか」は自然な質問です。

ただ、この世界観は、かなりきれいな企業内ITの前提に立っています。

従業員が会社メールを持っている。人事情報があり、入退社が管理されている。利用者ごとに端末やアカウントがある。困ったときに情シスが助けられる。IdPを運用する人がいる。

この前提があるなら、SSO、MFA、SCIM、ログはまっすぐ効きます。

でも、すべてのWebサービスがこの前提で使われているわけではありません。

現場型BtoBtoCサービスでは前提が崩れる

宿泊、飲食、小売、レジャー、施設運営のような領域では、Webサービスの利用者像が大きく変わります。

たとえば、予約管理、在庫管理、店舗管理、施設管理、シフト、受付、決済、顧客対応のようなサービスを考えます。

契約しているのは本部かもしれません。実際に画面を触るのは店舗や施設の担当者かもしれません。日々の操作はアルバイト、パート、委託先、現場責任者が担うかもしれません。端末は共有PCやタブレットかもしれません。会社メールが全員にあるとは限りません。1人1アカウントではなく、施設単位、店舗単位、部門単位のアカウントが運用されているかもしれません。

このとき、「IdPとSAML連携してください」と言っても、そもそもその施設側にIdPがないことがあります。あったとしても、全スタッフがIdPのユーザーではないことがあります。1人1アカウントを作ると、入退職、シフト、異動、代理操作、端末紛失、MFAリセットの運用が一気に増えることがあります。

これは、現場のリテラシーが低いという話ではありません。

サービスが支えている業務の形が違う、という話です。

現場型サービスでは、ITの管理単位が「社員」ではなく「施設」「店舗」「シフト」「端末」「担当業務」になっていることがあります。責任主体も、契約者、施設責任者、現場スタッフ、外部パートナー、予約者、顧客に分かれます。

この構造では、エンタープライズIAMの機能をそのまま持ってきても、すぐには噛み合いません。

SSOが不要なのではありません。MFAが早すぎるのでもありません。

SSOやMFAが効くための前提を、プロダクトと顧客の運用で一緒に作る必要があるということです。

高級機能ではなく、前提が重い機能として見る

ここで大事なのは、SSO、MFA、ログを「高級機能」と呼ばないことです。

高級機能と呼んでしまうと、「お金を払える大企業だけが使うもの」「小さい顧客には不要なもの」という意味に寄ってしまいます。でも、認証を強くすること、管理者操作を守ること、事故時に追跡できることは、顧客規模に関係なく重要です。

一方で、実装形態としてのSSO、MFA、ログには前提があります。

こう見ると、SSOやMFAやログは高級機能ではなく、前提が重い機能だと言えます。

そして、前提が重い機能は、単に「実装しました」だけでは普及しません。顧客が使える単位に分解し、導入順序を作り、サポートできる形にしないと、ロードマップ上の優先順位も上がりにくくなります。

開発企業側から見ると、なぜ実装が遅れるのか

開発企業側から見ると、SAML/SSOやMFAや監査ログの実装が遅れる理由はいくつもあります。

1つ目は、要望者と利用者と購買者が違うことです。

情シスやセキュリティ担当はSSOを求めます。しかし、実際にそのサービスを選ぶのは事業部門や現場部門かもしれません。日々使うのは店舗や施設の担当者かもしれません。契約更新を判断する人は、SSOよりも売上、予約数、現場工数、サポート対応、手数料、決済、在庫管理を見ているかもしれません。

このとき、SSOやMFAの要望は「あると望ましいが、今すぐ契約を左右する機能」になりにくいことがあります。

2つ目は、実装しても使える顧客が限られることです。

市場全体のうち、IdPを持ち、SAML設定ができ、証明書更新や属性マッピングを理解し、障害時の切り分けができる顧客がどれくらいいるのか。特に現場型BtoBtoCサービスでは、ここが読みづらい。

もちろん、大口顧客、チェーン本部、上場企業、規制業種、セキュリティ成熟度の高い企業ではSSOが強い要求になります。そういう顧客を取りに行くなら、SAML/OIDC SSO、SCIM、ログエクスポートは重要な投資です。

ただ、市場の大半がそこまで成熟していない場合、開発企業は「今作っても使える顧客が少ない」と判断しがちです。

3つ目は、サポート負荷です。

SSOは設定すれば終わりではありません。IdP側の設定、属性、証明書、リダイレクトURL、ログイン失敗、既存アカウントとの紐づけ、メールアドレス変更、管理者の締め出し、証明書期限切れ、IdP障害時の復旧が発生します。

MFAも同じです。スマートフォンをなくした、機種変更した、担当者が退職した、共有端末で使えない、コードが届かない、管理者だけ入れなくなった。こうした問い合わせを受ける体制が必要です。

監査ログも、出せば終わりではありません。どの操作をログに残すのか。誰が見られるのか。どれくらい保持するのか。ダウンロードできるのか。ログを削除できる管理者をどう扱うのか。仕様として詰めることが多い。

4つ目は、プロダクトの本業ではないことです。

予約サービスなら、予約、在庫、料金、通知、決済、現場オペレーションがコアです。勤怠サービスなら、打刻、申請、シフト、集計、法改正対応がコアです。小売や飲食向けなら、現場のスピード、ミスの少なさ、端末運用、サポートが価値になります。

認証、権限、ログは重要ですが、顧客が日々感じるコア価値より後回しになりやすい。

これは開発企業を擁護して終わる話ではありません。要望が少ないことは、安全ニーズがないことを意味しません。事故が起きるまで要望が顕在化しないだけ、ということもあります。

だからこそ、開発企業側は「要望が少ないから不要」ではなく、「今の顧客が使える安全策に分解できているか」を見る必要があります。

情シス側は、機能名ではなく守りたい状態を伝える

一方で、情シスやセキュリティ担当側にも工夫の余地があります。

「SAMLに対応してください」「MFAを付けてください」「監査ログをください」は、正しい要求です。ただ、開発企業側から見ると、それがどの事故シナリオを防ぎたいのか、どの顧客層に効くのか、どの順序で作ればよいのかが見えにくいことがあります。

要求は、機能名ではなく守りたい状態へ翻訳した方が届きやすくなります。

この翻訳があると、開発企業側もロードマップに落としやすくなります。

たとえば、「全ユーザーMFAを今すぐ強制してほしい」ではなく、「まず管理者だけMFAを必須にしてほしい」「予約キャンセル、返金、振込先変更、権限変更のような危険操作には再認証を入れてほしい」「MFAリセットはログに残してほしい」と言えば、実装の粒度が変わります。

「SAMLがほしい」も同じです。

本当にやりたいことが退職者停止であれば、SAMLだけでなく、管理者が利用者を無効化できること、最終ログインを見られること、施設ごとのアカウント棚卸しができること、招待中ユーザーを取り消せることも重要です。

SAMLは強い解決策ですが、SAMLだけが解決策ではありません。

まず実装されるべき安全策

現場型BtoBtoCサービスであっても、何もしなくてよいわけではありません。

むしろ、1人1アカウントやIdPがまだ十分に普及していない市場だからこそ、サービス側が段階的な安全策を持つことが重要です。

私なら、次のような順序で考えます。

ここで言いたいのは、「SAMLの前にやるべきことがあるからSAMLは後でよい」という単純な話ではありません。

SAML/OIDC SSOやSCIMは、成熟した顧客にとっては非常に重要です。大口顧客やエンタープライズ展開を考えるなら、早めにロードマップへ入れるべきです。

ただ、SAMLだけを作っても、IdPを持たない顧客、1人1アカウントで運用していない顧客、現場端末中心の顧客には届きません。

だから、基本統制を複数の層に分ける必要があります。

管理者MFA、重要操作ログ、権限分離、再認証、通知、利用者棚卸し。これらは、IdPがない顧客にも効きます。その上で、IdPがある顧客にはSAML/OIDC、SCIM、ログ連携を提供する。

この2段構えにすると、「高級機能かどうか」という議論から、「どの顧客成熟度に、どの安全策を届けるか」という議論に変わります。

開発企業は「セキュリティ機能」を商品ではなく設計にする

開発企業側に伝えたいのは、セキュリティ機能を単なる上位プランの差別化要素にしない方がよい、ということです。

もちろん、すべてを無償で提供するのは現実的ではありません。SAML/OIDC、SCIM、長期ログ保持、SIEM連携、細かい権限管理、専任サポートにはコストがかかります。そこに価格を付けること自体は理解できます。

ただ、管理者MFA、ログイン履歴、重要操作ログ、権限分離、危険操作の再認証のような機能まで上位プランに寄せすぎると、顧客の基本的な安全性が上がりません。

結果として、事故が起きたときにサービス提供者側も苦しくなります。

「顧客が設定していなかった」「要望がなかった」「上位プランにはあった」と言いたくなるかもしれません。でも、現実には、顧客は機能名を知らないことがあります。現場はリスクを言語化できないことがあります。事故が起きるまで必要性に気づけないことがあります。

だから、開発企業は顧客をざっくり次のように分けて、ロードマップを持つとよいと思います。

• IdPなし、施設単位アカウント中心の顧客
• IdPなし、1人1アカウントへ移行したい顧客
• IdPあり、SSOだけ使いたい顧客
• IdPあり、SCIMやログ連携まで求める顧客
• 本部統制と現場運用の両方を求めるチェーン型顧客

この分類があると、「SSOを作るか作らないか」ではなく、「どの層に、どの安全策を、どの順序で届けるか」を考えられます。

セキュリティ機能は、単品の機能ではなく、顧客成熟度に合わせた設計です。

情シスは要求を契約と運用に落とす

情シス側も、ベンダーに要求するときは、少し言い方を変えるとよいです。

単に「SAML対応してください」と言うだけではなく、次のように聞く。

• 退職者や異動者のアクセスを、誰がどの単位で止められますか
• 管理者アカウントにはMFAを必須化できますか
• MFAリセットや管理者変更はログに残りますか
• 重要操作は誰が、いつ、何をしたか追えますか
• ログはどれくらい保持され、どの形式で出せますか
• 施設単位アカウントから個人アカウントへ移行できますか
• IdPを持つ顧客向けに、SAML/OIDCやSCIMのロードマップはありますか
• 事故時に、どのログをどれくらいの時間で提供できますか

こう聞くと、ベンダー側も答えやすくなります。

「SAMLはありません」で終わるのではなく、「今はSAMLはないが、管理者MFAと重要操作ログはある」「個人アカウント化はできる」「ログ保持は90日」「CSV出力はできる」「大口顧客向けにSSOは検討中」といった会話になります。

もちろん、企業としてSSOが必須なら、必須要件として契約条件に入れるべきです。金融、医療、重要インフラ、上場企業、個人情報や決済情報を大量に扱う業務では、最初からSAML/OIDC SSOやMFA、監査ログを強く求めるべき場面もあります。

ただ、すべての現場型サービスに同じ言い方をしても、実装されるとは限りません。

機能名を投げるだけでなく、守りたい状態、事故シナリオ、必要な証跡、代替策、段階的な移行案まで伝える。ここまで落とすと、要求がプロダクトの言葉に近づきます。

「要望がない」は安全ニーズがないことではない

最後に、開発企業側にも情シス側にも共通して言えることがあります。

「顧客から要望がない」は、安全ニーズがないことを意味しません。

現場の顧客は、SAMLという単語を知らないかもしれません。MFAの方式を知らないかもしれません。監査ログの保持期間を要件化したことがないかもしれません。

でも、困ることはあります。

担当者が辞めたあともログインできてしまう。誰が予約情報を見たのか分からない。返金や設定変更を誰がしたのか分からない。パスワードを共有していて、事故時に説明できない。管理者アカウントが1つしかなく、担当者が変わるたびに引き継ぎが曖昧になる。

これは、SAMLという言葉で要望されないだけで、安全ニーズそのものは存在しています。

だから、開発企業は「顧客がSAMLと言わないから不要」と考えない方がよいです。情シスは「SAMLと言えば伝わるはず」と考えない方がよいです。

両者の間に必要なのは翻訳です。

情シスは、機能名を事故シナリオと必要な証跡へ翻訳する。開発企業は、顧客の成熟度に合わせて、使える安全策へ翻訳する。

この翻訳ができると、SSO、MFA、ログは「高級機能かどうか」という議論から離れます。

会社としてWebサービスを安全に使うための基本統制を、どの市場に、どの順序で、どの運用単位で届けるか。そういう話になります。

まとめ

SSO、MFA、ログは高級機能ではありません。

会社でWebサービスを使うなら、認証を強くすること、退職者を止めること、管理者操作を守ること、事故時に追えることは、基本的な統制です。

ただし、現場型BtoBtoCサービスでは、エンタープライズIAMの前提がそのまま成立しないことがあります。IdPがない。1人1アカウントではない。会社メールがない。共有端末がある。契約者と利用者が違う。そういう市場で、SAML/SSOやMFAという機能名だけを投げても、実装にも運用にも乗りにくい。

だから、要求を翻訳する必要があります。

情シスは「SAMLを付けて」だけでなく、退職者停止、管理者MFA、危険操作の再認証、重要操作ログ、権限分離、証跡提出のような守りたい状態へ分解する。

開発企業は「要望がないから不要」ではなく、顧客の成熟度に合わせて、IdPがなくても効く安全策と、IdPがある顧客向けのSSO/SCIM/ログ連携を段階的に設計する。

前回の記事で書いた「SSO、MFA、ログは基本機能側へ寄ってほしい」という主張は、この記事でも変わりません。

ただ、その「基本機能」は、必ずしも最初からSAML、SCIM、SIEM連携だけを意味しません。

現場で運用でき、事故時に被害を狭め、あとから説明できる安全策として届ける。そこまで含めて、Webサービスのセキュリティ機能を考えたいです。