CIAMとは？認証基盤での役割と、パブリッククラウド付随のCIAM機能／独立CIAMの選び方【2026】

※2026-07-29更新：CIAMの実現方法の分類を「パブリッククラウドに付随するCIAM機能／独立CIAM」の軸に整理し直しました（旧：既存IdPの外部ID機能／専業CIAM）。

はじめに

こんにちは！新人PMおじさん改め、入社1年ちょっとのkenkenです。

さて、最近お客様とお話ししていると、「自社の顧客向けサービスにログイン機能を付けたいんだけど、どういうサービスを使えばいいの？」というご相談が増えてきました。

ここで登場するのが「CIAM（Customer Identity and Access Management、顧客向けID管理）」です。読み方は「サイアム」または「シーアイアム」です。

結論から先にお伝えすると、顧客向けのIDは、自社社員向けのIDとは別のレイヤーで考えるのが基本です。そしてその実現方法には、大きく2種類あります。

• (a) パブリッククラウドに付随するCIAM機能を使う（例：Entra External ID、Amazon Cognito）
• (b) 独立基盤で提供される「独立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）
  • 認証を担う基盤です。

整理すると、こんな並びになります。

大事なのは、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) パブリッククラウドに付随するCIAM機能を使う

Microsoft・AWS・Googleといった主要なパブリッククラウドは、それぞれ顧客向けIDを扱うCIAM機能を用意しています。すでに使っているクラウドがあれば、その延長で始めやすいのも特徴です。

※製品名や機能範囲は更新が早いので、最新の情報は各ベンダーの公式ドキュメントをご確認ください。

(b) 独立基盤の「独立CIAM」を使う

特定のパブリッククラウドには紐づかず、独立した基盤で提供されるCIAMサービス群です。CIAMそのものを製品として提供しているため、同意管理・ソーシャル連携・ログインフローの作り込みといった顧客向けIDまわりの機能を、ひとつのパッケージとして一通り備えているのが特徴です（個々の機能がパブリッククラウド付随側にないとは限りません）。

ちなみにAuth0は、買収によって現在はOkta傘下にあり、「Okta Customer Identity Cloud」という名前でも提供されています。上の表にも挙げた「Okta Customer Identity」（Oktaプラットフォーム上で提供される、これとは別のCIAM製品）と名前が似ているので、この2つは混同注意です。

で、結局何を選べばいいの？

ここが一番気になるところですよね。ただ正直にお伝えすると、「(a)だから◯◯、(b)だから△△」とカテゴリで決められるものではありません。カスタマイズの自由度もスケールも始めやすさも、カテゴリではなく製品ごとに大きく異なるためです（例えば、パブリッククラウド付随のAmazon Cognitoが大規模サービスを支えている例もあれば、独立CIAM側に小さく速く始められる製品もあります）。

なので選定は、カテゴリの比較ではなく、自社の要件を先に整理して、製品ごとの前提に当てていく進め方をおすすめします。整理しておきたい要件は、だいたい次のあたりです。

• 既存エコシステムとの関係
  • いま使っている自社社員向けIdPやクラウドとの親和性を、どこまで重視するか。
• B2Bの組織要件
  • 取引先ごとのテナント／組織の分離や、取引先IdPとのSSO連携が、どの程度必要か。
• ログイン体験のカスタマイズ
  • 標準的な画面と流れで足りるか、独自フロー・独自ロジックまで作り込みたいか。
• 規模と課金
  • 想定するMAU（Monthly Active Users、月間アクティブユーザー）とその伸び方。MAU課金が一般的なので、事業計画とセットで見積もれるか。
• 運用体制
  • 誰が、どんなスキルセットで運用するのか。パブリッククラウド付随の機能はそのクラウド自体の運用が前提になる一方、独立CIAMには管理コンソール中心で運用できる（開発やクラウドの知見を必ずしも前提としない）製品もあります。契約・監視・障害対応まで含めて、自社の体制に合うかを確認します。

この要件が固まると、(a)(b)のカテゴリを横断して、候補は自然と数製品に絞れてきます。個別製品の突き合わせは、そこからで十分間に合います。

⚠️ 各製品は機能拡充が続いていて、特性も変わっていきます。個別機能の可否は、必ずベンダー公式のドキュメント（一次ソース）で最新の情報をご確認ください。

はじめて顧客向けIDを持つときに、見落としがちなポイント

つまずきやすいのは、自社サービスにログイン機能を持つことになって、はじめてCIAMの要件に向き合うケースです。社内のID管理とは前提が違うぶん、次のあたりが見落とされがちです。

• コスト構造
  • 課金は登録ユーザー数ではなくMAUベースが一般的です。ここを見落として見積もると、アクセスが伸びた途端にコストが想定を超えて膨らみます。
• ライフサイクル（特に利用終了時）
  • アカウントの作成（セルフ登録・管理者作成・取引先IdP連携など）に比べて、退会・休眠・契約終了といった利用終了時の扱い（削除・無効化の方針）は決め忘れられがちです。ここが曖昧だと放置アカウントが積み上がり、この後に挙げる同意・プライバシーや攻撃面のリスクの温床になります。
• UX
  • セキュリティ側の要請だけで認証を厳しくする（MFA必須など）と、面倒に感じた顧客がそのまま離脱します。
• 同意・プライバシー
  • 同意の取得・記録や削除依頼への対応を後回しにすると、法令対応のリスクになります。
• 攻撃面
  • 公開の登録エンドポイントは、bot登録やアカウント乗っ取り（ATO＝Account Takeover）の的になります。社内システムにはなかった種類の対策が必要になります。

まとめ：あなたのサービスに合ったCIAMの実現方法は？

CIAM（顧客向けID管理）は、自社社員向けのIDとは別レイヤーで考えるのが基本でした。そして選定は、カテゴリで優劣が決まるわけではなく、製品ごとの特徴に自社の要件を当てて「何がフィットするか」で決めるのがポイントです。なお、ごく小規模で社内限定に近いサービスであれば、独立CIAMまで立てず、当面はパブリッククラウドに付随する機能で足りる場合もあります。

選ぶ前に、まずはご自身のサービスの状況を整理してみるのがおすすめです。

• 想定ユーザー数と、その伸び方
• 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課金は製品ページに記載）
• AWS：Amazon Cognito ドキュメント（2026-07-06確認。ユーザープール＝サインアップ／サインインを提供するユーザーディレクトリと明記）
• Ping Identity：PingOne Advanced Identity Cloud ドキュメント（旧ForgeRock Identity Cloudと明記）／PingOne for Customers データシート
• 独立CIAM各社：LoginRadius Docs／Frontegg：B2B SaaS向けCIAM／FusionAuth Docs（いずれも2026-07-29に確認）
• 標準仕様：OAuth 2.0（RFC 6749）／OpenID Connect Core 1.0