はじめに
こんにちは！新人PMおじさん改め、入社1年ちょっとのkenkenです。
さて、最近お客様とお話ししていると、「自社の顧客向けサービスにログイン機能を付けたいんだけど、どういうサービスを使えばいいの？」というご相談が増えてきました。
ここで登場するのが「CIAM（Customer Identity and Access Management、顧客向けID管理）」です。
結論から先にお伝えすると、顧客向けのIDは、自社社員向けのIDとは別のレイヤーで考えるのが基本です。そしてその実現方法には、大きく2種類あります。
- (a) いま使っている自社社員向けIdPの「外部ID機能」を使う（例：Entra External ID）
- (b) 外部ID専用に設計された「専業CIAM」を使う（例：Auth0）
CIAMはB2CだけでなくB2Bでも使いますし、製品ごとに特徴が異なるので、何がフィットするかは自社の要件次第です。
この記事では、認証基盤の主な種類の中でCIAMがどこに位置するのかを整理したうえで、「自社には何がフィットするの？」を考えるための判断材料を、PM目線でお伝えしていきます。
そもそも：認証基盤の主な種類を整理する
CIAMだけを単体で見ると「IDのSaaSでしょ？」と混同しがちなので、まずはまわりの用語との役割の違いから整理させてください。用語はできるだけ自分の言葉で書きます。
- IAM（Identity and Access Management）
- 認証・認可・アカウント管理をすべて包含する最上位カテゴリです。クラウドサービスに限らず、オンプレミスのActive Directoryのような社内設置型の認証基盤も含みます。以下のIDaaSやCIAMなども、すべてこのIAMの中に含まれます。
- IDaaS（Identity as a Service）
- IAMをクラウドで提供する「形態」です（SSO＝Single Sign-On、MFA＝Multi-Factor Authentication などをSaaSで提供）。対象を分ける言葉ではなく、提供のしかたを表します。
- 自社社員向けIAM（Workforce IAM）
- 自社の従業員など内部ユーザー向けのID管理です（Entra ID／Okta 等）。
- CIAM（Customer Identity and Access Management）
- 顧客・外部ユーザー向けのID管理です。今回の主役です。
- IdP（Identity Provider）
- 認証を担う基盤です。自社社員向けIdPが、顧客向けの「外部ID機能」を持っていることがあります。
整理すると、こんな並びになります。
| 分類の軸 | 種類 | 説明 |
|---|---|---|
| 最上位カテゴリ | IAM | 認証・認可・アカウント管理すべてを包含する親カテゴリ（クラウド／オンプレミスを問わない） |
| 対象で分ける | 自社社員向けIAM（Workforce） | 従業員など内部ユーザー向け（Entra ID／Okta 等） |
| 対象で分ける | CIAM（顧客向け） | 顧客・外部ユーザー向け（本記事の主役） |
| 提供形態で分ける | IDaaS | IAMをクラウドで提供する形態（自社社員向け・顧客向けのどちらもありうる） |
大事なのは、CIAMは自社社員向けの「置き換え」ではなく、対象が違う別レイヤーだということです。ここを押さえると、後の話がスッと入ってきます。
なお「EIAM（Enterprise IAM）」という言葉も見かけますが、これは規模の大小というより、自社社員向けIAMをガバナンス（IGA＝Identity Governance and Administration）や特権アクセス管理（PAM＝Privileged Access Management）まで含めて包括的に扱う領域を指します。SailPointやSaviynt（IGA系）、CyberArk（PAM系）のように、SSO／MFA中心のIDaaSとは機能が明確に異なる製品もあります。ただ本記事のテーマ（顧客向けか自社社員向けか）とは別の軸なので、ここでは深入りしません。
CIAMって何をしてくれるの？
CIAMは、顧客向けアプリやAPIの「入口」に立って、次のようなことをしてくれます。自社社員向けIAMと共通の機能と、CIAMならではの機能に分けて見ると分かりやすいです。
- 認証・認可【自社社員向けと共通】
- 顧客がログインし、必要な範囲だけにアクセスできるようにする、IAMの基本機能です。技術的には、OIDC（OpenID Connect）やOAuthといった標準プロトコルを使って、顧客向けアプリへトークンを発行します。
- 登録・プロファイル管理【CIAMならでは】
- 顧客が自分でサインアップ・更新・退会でき、プロファイルを一元管理できます。自社社員向けは人事（HR）起点でアカウントを作りますが、顧客は「セルフ登録」が前提という違いがあります。
- 同意・プライバシー【CIAMならでは】
- どの目的で情報を使うかの同意取得・記録と、開示・訂正・削除への対応です。社内規程で統制できる自社社員と違い、顧客一人ひとりの同意を管理する必要があります。
- スケールとUX【CIAMならでは】
- 大量ユーザーや急なアクセス増に耐えつつ、摩擦の少ないログイン（パスワードレスやソーシャルログイン等）を提供します。ユーザー数がおおよそ読める自社社員向けと違い、顧客の数は大きく変動します。
自社社員向けとの一番の違いは、優先する軸が「統制」ではなく「顧客体験（UX）とビジネス貢献」に寄ることです。自社社員はMFAの手間を受け入れてくれますが、顧客は面倒だと感じたら離脱してしまいます。この一点が、設計の考え方を分ける分岐点になります。
B2Cだけじゃなく、B2Bでも使うんです
「CIAM＝ECサイトの会員ログインでしょ？」と思われがちですが、B2Bでも使います。
- B2Cの例
- 会員制サイトやECの顧客ログイン、ソーシャルログイン、リコメンド連携。
- B2Bの例
- 自社が開発・提供するサービスに、取引先企業のユーザーがログインする場面です。典型的な動機は、取引先のユーザーを自社社員向けIdPには混ぜず、外部ユーザー用のユーザーDB（ディレクトリ）を別に立てて管理したい、というもの。そのうえで、企業（組織）ごとにテナントを分けたり、規模の大きい取引先からは先方のIdPでのSSO連携を求められたりすることもあります。
「顧客＝個人」に限らず「顧客＝取引先の従業員」も外部ユーザーであり、CIAMの守備範囲です。特にB2Bでは、取引先ごとのIdP連携や、組織単位の権限委譲（デリゲート管理）が論点になりやすいです。
CIAMの実現方法は2種類ある
ここが今回の一番お伝えしたいところです。CIAM製品の比較に入る前に、まずどちらの方法で実現するかという選択があります。
(a) いま使っているIdPの「外部ID機能」を使う
主要な自社社員向けIdP／IDaaSは、それぞれ外部ユーザー向けのCIAM機能を別建てで持っています。すでに使っているIdPの延長で始められるのが利点です。
| 自社社員向けIdP／IDaaS | 内包する外部ID（CIAM）機能 | ひとこと補足 |
|---|---|---|
| Microsoft Entra ID | Entra External ID | 旧Azure AD B2Cの後継（B2Cは2025年5月に新規販売終了、既存顧客は少なくとも2030年5月までサポート）。Microsoft中心の環境と相性◎ |
| Okta Workforce Identity Cloud | Okta Customer Identity | Okta自社プラットフォーム上で提供 |
| Google Cloud Identity | Google Cloud Identity Platform | Firebase Auth系。MAU課金 |
| Ping Identity（PingOne） | PingOne for Customers／PingOne Advanced Identity Cloud（AIC） | AICが旧ForgeRock製品。特性は製品ごとに異なります |
| IBM Security Verify | 外部／消費者向けモジュール | 外部ユーザー管理は別ライセンスになりがち |
※製品名や機能範囲は更新が早いので、最新の情報は各ベンダーの公式ドキュメントをご確認ください。
(b) 専業CIAM（Auth0など）を使う
外部ID専用に設計された製品群です。代表例は Auth0、Amazon Cognito、LoginRadius、Frontegg、FusionAuth など。開発者向けの自由度や、外部ID特化の機能（同意管理・大規模スケール・多様なソーシャル連携）が厚い傾向があります。
ちなみにAuth0は、買収によって現在はOkta傘下にあり、「Okta Customer Identity Cloud」という名前でも提供されています。上の表に出てきた「Okta Customer Identity」（Oktaが自社プラットフォーム上で提供する外部ID機能）とは別の製品なので、名前の似ているこの2つは混同注意です。
で、結局何を選べばいいの？
ここが一番気になるところですよね。ただ正直にお伝えすると、「(a)だから◯◯、(b)だから△△」とカテゴリで決められるものではありません。カスタマイズの自由度もスケールも始めやすさも、カテゴリではなく製品ごとに大きく異なるためです（例えば(a)側にも、PingOne Advanced Identity Cloudのように大規模向けの柔軟性を持つ製品があります）。
なので選定は、カテゴリの比較ではなく、自社の要件を先に整理して、製品ごとの前提に当てていく進め方をおすすめします。整理しておきたい要件は、だいたい次のあたりです。
- 既存エコシステムとの関係
- いま使っている自社社員向けIdPやクラウドとの親和性を、どこまで重視するか。
- B2Bの組織要件
- 取引先ごとのテナント／組織の分離や、取引先IdPとのSSO連携が、どの程度必要か。
- ログイン体験のカスタマイズ
- 標準的な画面と流れで足りるか、独自フロー・独自ロジックまで作り込みたいか。
- 規模と課金
- 想定するMAU（Monthly Active Users、月間アクティブユーザー）とその伸び方。MAU課金が一般的なので、事業計画とセットで見積もれるか。
- 運用体制
- 誰が運用するのか。認証基盤が1つ増えることによる契約・監視・障害対応の負担を担えるか。
この要件が固まると、(a)(b)のカテゴリを横断して、候補は自然と数製品に絞れてきます。個別製品の突き合わせは、そこからで十分間に合います。
⚠️ 各製品は機能拡充が続いていて、特性も変わっていきます。個別機能の可否は、必ずベンダー公式のドキュメント（一次ソース）で最新の情報をご確認ください。
はじめて顧客向けIDを持つときに、見落としがちなポイント
つまずきやすいのは、自社サービスにログイン機能を持つことになって、はじめてCIAMの要件に向き合うケースです。社内のID管理とは前提が違うぶん、次のあたりが見落とされがちです。
- コスト構造
- 課金は登録ユーザー数ではなくMAUベースが一般的です。ここを見落として見積もると、アクセスが伸びた途端にコストが想定を超えて膨らみます。
- ライフサイクル（特に利用終了時）
- アカウントの作成（セルフ登録・管理者作成・取引先IdP連携など）に比べて、退会・休眠・契約終了といった利用終了時の扱い（削除・無効化の方針）は決め忘れられがちです。ここが曖昧だと放置アカウントが積み上がり、この後に挙げる同意・プライバシーや攻撃面のリスクの温床になります。
- UX
- セキュリティ側の要請だけで認証を厳しくする（MFA必須など）と、面倒に感じた顧客がそのまま離脱します。
- 同意・プライバシー
- 同意の取得・記録や削除依頼への対応を後回しにすると、法令対応のリスクになります。
- 攻撃面
- 公開の登録エンドポイントは、bot登録やアカウント乗っ取り（ATO＝Account Takeover）の的になります。社内システムにはなかった種類の対策が必要になります。
まとめ：あなたのサービスに合ったCIAMの実現方法は？
CIAM（顧客向けID管理）は、自社社員向けのIDとは別レイヤーで考えるのが基本でした。そして選定は、カテゴリで優劣が決まるわけではなく、製品ごとの特徴に自社の要件を当てて「何がフィットするか」で決めるのがポイントです。なお、ごく小規模で社内限定に近いサービスであれば、無理にCIAMを立てず、当面は既存IdPの外部ID機能で足りる場合もあります。
選ぶ前に、まずはご自身のサービスの状況を整理してみるのがおすすめです。
- 想定ユーザー数と、その伸び方
- B2CなのかB2Bなのか
- 必要な同意管理のレベル
- 取引先IdPの数と種類（B2Bの場合）
- 既存の自社社員向けIdP資産との境界
「やりたいこと」と「やるべきこと」の切り分けが難しいときは、誰かに相談してみるのもいいかもしれませんね！
一次ソース（2026-07-03にURL実在・内容を確認済み）
- Auth0 Docs：Auth0 Organizations（B2B組織機能）／B2B IAMアーキテクチャ：認証
- Microsoft Learn：Entra External ID ドキュメント／外部テナント（CIAM）ドキュメント
- Google Cloud：Identity Platform ドキュメント（MAU課金は製品ページに記載）
- Ping Identity：PingOne Advanced Identity Cloud ドキュメント（旧ForgeRock Identity Cloudと明記）／PingOne for Customers データシート
- 標準仕様：OAuth 2.0（RFC 6749）／OpenID Connect Core 1.0
