会員基盤の正しい作り方｜「管理」と「認証」を分けて設計する

会員基盤は「どこに、どう作るか」を最初に間違えると、あとで作り直しになります。そして、いちばん多い間違いが「会員“管理”と会員“認証”を混同し、一つの大きなデータベースに全部を載せてしまう」ことです。登録も、配信も、購買履歴も、認証も——ひとまとめにすれば楽に見えますが、これは規模が大きくなるほど破綻します。正しい会員基盤は、役割の違うものをレイヤーで分けて組みます。この記事では、なぜ分けるのか、どの層に何を置くのか、そしてID体系・名寄せ・連携・移行まで、実装の視点で順を追って整理します。

まず区別する——「会員管理」と「会員認証」は別物です

言葉が似ているために混同されますが、この二つは担うものがまったく違います。会員“管理”は、会員の属性やステータス、購買履歴を扱い、マーケティングや顧客対応に使う——CRMやCDPの領域です。一方会員“認証”は、「その人が本人か」を確かめ、安全にログインさせる仕組み——CIAM（顧客向けのID管理）やIDaaSの領域です。多くの解説記事は前者（会員“管理”システム）の話に終始し、後者（認証基盤）の設計を曖昧にしています。しかし実際に破綻を招くのは、この二つを一枚のDBに詰め込んでしまう設計なのです。

両者は、求められる性質からして逆を向いています。認証は、正しさ・速さ・堅牢さが命で、更新はまれ、読み取りは膨大、停止は許されない、という尖った特性を持ちます。会員管理は、扱う項目がどんどん増え、集計や分析のために自由に結合したい、という広がる特性を持ちます。尖ったものと広がるものを同じ器に入れると、片方の都合がもう片方の足を引っ張ります。だから最初に、この二つを別の層として設計するところから始めます。

なぜ、一つのDBに全部載せてはいけないのか

理由は、保守性・障害波及・スケールの三つに集約されます。認証は、数千万規模の同時アクセスや、パスワードレスへの追随といった、独自の速さと堅牢さを求められる領域です。そこに購買履歴の分析や配信の都合が同居すると、片方の変更や障害が、もう片方を巻き込みます。テーブル定義を一つ変えるたびに認証まで再テストが要る、分析の重いクエリが認証の応答を遅らせる、といった具合です。

だから定石は、認証・共通IDを“原本（マスタ）”として一箇所に持ち、各業務システムには“写し（コピー）”をイベント駆動で非同期に配るという設計です。会員が登録・更新されたら、そのイベントをPub/Subのような仕組みで各システムへ流し、それぞれが自分のコピーを更新する。原本と各システムを疎結合にしておくことで、独立して保守でき、障害の波及も抑えられます。全システムをリアルタイムに同期させようとしないのが、むしろ堅牢さの鍵です。この「イベントで配る」具体的なやり方は、後半の連携の節で掘り下げます。

認証層（CIAM）と会員データ層に、何を置くか

層を分けると決めたら、次は「どの層に、どのデータと責務を置くか」を線引きします。認証層（CIAM／IDaaS）に置くのは、本人確認に直接かかわるものだけです。ログイン手段（パスワードのハッシュ、パスキー／FIDOの公開鍵、ソーシャルやLINEとの連携情報）、多要素認証の設定、セッションやトークンの発行、そして利用者を一意に指す識別子——ここまでが認証層の担当です。逆に、氏名や住所、購買履歴、キャンペーンの当選履歴といった“人となり”の属性は、認証層には置きません。認証層は薄く、堅く保つのが原則です。

一方の会員データ層には、属性・同意・名寄せの結果を置きます。ここが、認証層の識別子と、購買や行動のデータを結ぶハブになります。「本人か」を判定するのが認証層、「その人は誰で、何に同意し、何を買ったか」を束ねるのが会員データ層、と役割で覚えると混乱しません。認証に要る最小限だけを認証層に残し、それ以外は会員データ層へ寄せる、という切り分けが基本形です。

認証を担う層に何が求められるかは、IDプロバイダのOktaがCIAMの要件として整理しています。1顧客あたり数千万件規模を捌くスケーラビリティ、極めて高い可用性、ソーシャルからパスワードレスまで幅広く扱える認証の柔軟性、GDPR等に対応するプライバシー、そしてAPI/SDK前提の開発者中心設計です。会員登録の入口としてのLINEログインやソーシャルログインは、まさにこの認証層に“入口”としてつながります。

だから、業務アプリDBを「認証基盤」にはしない

ここで、よくある相談に触れておきます。「kintoneのような業務アプリに、会員を載せてはいけないのか」というものです。答えは、優劣ではなく設計目的の違い（適材適所）にあります。kintoneは社内業務の改善や情報共有に最適化された基盤で、社外の利用者は“ゲストユーザー”として招待する——つまり「あらかじめ分かっている相手」を前提にした課金・運用モデルです。不特定多数が自分で登録してくる、数万〜数千万規模の一般消費者会員を、認証基盤として捌く用途は想定していません。アクセス制御も、アプリ・レコード単位の閲覧編集の話であり、OIDCやSAMLで外部サービスへIDを連携し、SSOやトークンを発行するCIAMとは、そもそもレイヤーが違います。

業務アプリは「顧客管理・社内業務」の層で活かし、認証はその前段に専用の認証基盤（IDaaS／CIAM）を置く。これは優劣の話ではなく、適材適所の配置です。

正しい形——3つの層に分けて組む

ここまでを整理すると、会員基盤は次の三つの層に分かれます。それぞれ「主に置くもの」「代表的な選択肢」「役割」が異なり、共通の会員IDで結んでいきます。

①認証層は、専用DBまたはIDaaS（Auth0・Amazon Cognito・Firebase・Okta など）で、共通IDの原本を持ちます。②会員データ層は、属性・同意・名寄せの中心で、認証IDと購買・行動を結ぶハブ。③顧客管理・活用層は、CRMやCDP（Salesforce Data Cloud など）でマーケティングやLTVに使います。原本は①、②③へは写しをイベント駆動で配る——これが疎結合の骨格です。製品ごとの機能・実料金と「作る／買う」の判断は 「認証は作るか買うか」、3製品の比較は 「Auth0 vs Firebase vs Cognito」 にまとめています。

ID体系の設計——内部IDと外部IDを分け、対応表で束ねる

層を分け、原本を認証層に置くと決めたら、その原本の背骨になるID体系を設計します。ここを雑にすると、後からどれだけ立派な分析基盤を載せても、人がつながりません。要点は二つ。内部の会員IDと、外部のログイン識別子を分けること。そして1人が複数のログイン手段を持つ前提で、対応表（マッピング）で束ねることです。

内部の会員IDは、システムが機械的に採番する、意味を持たない番号（サロゲートキー）にします。連番でもUUIDでも構いませんが、共通するのは「メールアドレスや電話番号のような“中身のある値”を主キーにしない」という点です。メールも電話も、本人が変えます。変わりうる値を人の背番号にすると、変更のたびに全システムの結合が壊れます。だから内部IDは、一度振ったら二度と変えず、二度と使い回さない。そして外部には露出させません。URLやメール本文、他システムへの連携に出すのは、内部IDそのものではなく、用途ごとに分けた別の識別子にします。

外部IDは、ログイン手段の側が持つ識別子です。ソーシャルログインやLINEログインはOpenID Connectに準拠しており、IDトークンの中の sub（subject＝利用者を一意に指す値）と iss（issuer＝発行元）の組み合わせが、その発行元における唯一の安定した識別子になります。LINEログインなら、発行元は https://access.line.me、sub はLINEのユーザーIDにあたります。ここで大事なのは、メールアドレスを識別子の主キーにしないことです。OpenID Connectの仕様でも、email や phone_number は再割り当てや変更がありうるため一意識別子として使ってはならないとされ、頼ってよいのは iss＋sub だけ、と明記されています。

メールや電話番号を会員の主キーにしない。内部IDは意味を持たない番号にして、外部には出さない——これがID体系の背骨です。

この内部IDと外部IDを結ぶのが対応表です。1人の会員（内部ID）に対し、パスワードログイン・LINE・各ソーシャルといった複数の外部IDがぶら下がる、一対多の構造にします。同じ人が別の手段でログインしてきたとき、新規に作るのか、既存の会員に紐づける（アカウントリンク）のかを判断するのも、この対応表の役目です。なお、発行元によっては同じ人でもアプリごとに異なる sub（ペアワイズ識別子）を発行するため、「外部IDは発行元とアプリの組で一意」として設計しておくと、後で取り違えません。

いちばんの肝——名寄せは「キー設計」で決まる

複数の外部IDや、既存の会員データを、同一人物で正しく束ねる名寄せが、会員基盤の質を決めます。名寄せは、感覚ではなく設計です。中心にあるのは突合キー（マッチングキー）の選定で、キーは「一意性・取得可能性・安定性」の三つで評価します。メールは取得しやすいが変わりうる、電話は比較的安定だが未取得の会員も多い、会員番号は一意だが名寄せ前は同じ人が複数持っている——といった具合に、単独では決め手に欠けます。だから実務では、複数キーを重ね合わせます。

判定は、完全一致だけでは取りこぼします。表記ゆれ（全角半角、旧姓、住所の番地表記）を吸収するため、部分一致やスコア閾値によるあいまい（確率的）マッチングを組み合わせ、必要に応じて類似度（レーベンシュタイン距離やN-gramなど）や機械学習まで使い分けます。実装は、①データの棚卸しと品質調査、②クレンジング（全角半角の統一、住所の正規化など）、③候補ペアの抽出とスコアリング、④マスターレコードの生成、という順で進めます。

見落とされがちなのがマージとアンマージです。名寄せは必ず誤ります。別人を同一人物と判定してしまう誤マージは、問い合わせ履歴や購買履歴を他人と混ぜてしまう事故で、個人情報の観点でも重大です。だから統合は“元に戻せる”形で行うのが鉄則です。元レコードを物理的に消してしまわず、どのレコードをどの代表レコードへ寄せたかの由来（来歴）を残しておけば、誤マージが分かったときに分離（アンマージ）で復旧できます。片方向に潰す設計は、いちど間違えると取り返しがつきません。

もう一つ、名寄せの責任分界を決めておきます。名寄せは会員データ層の責務にし、CRMやMAには“名寄せ済みの結果”だけを配る——各システムがそれぞれ勝手に名寄せを始めると、同じ人が層ごとに違う束ね方をされ、突き合わせが二度と合わなくなります。LINEのユーザーIDや会員番号、メール・電話をどう突合キーに据えるか——ここが後のデータ活用の質を決めます（LINEのID連携は 「LINEのID連携（EC/CRM）」、Salesforceでの実装は 「Salesforceを会員基盤にする」 を参照）。

層をつなぐ——認証イベントを、非同期で配る

層を分けたら、次は“つなぎ方”です。ここで同期呼び出し（相手のAPIを直接叩いて、返事を待つ）を選ぶと、せっかく分けた意味が薄れます。CRMが重い、MAが応答しない——そのたびに、会員登録やログインまで一緒に遅くなり、あるいは失敗します。入口である認証の可用性を、後段のシステムの都合に人質へ取られてはいけません。

だから、連携はイベント駆動の非同期にします。新規登録・ログイン・属性更新といった出来事を、認証層／会員データ層がイベントとして発行（publish）し、会員データ層・CRM・MAはそれを購読（subscribe）して、自分のペースで追随します。相手が一時的に落ちていても、イベントは滞留させてリトライできるので、送り手は影響を受けません。設計上おさえる勘所は三つです。第一に冪等性——同じイベントが二重に届いても壊れないよう、イベントIDで重複を排除します。第二に順序と鮮度——更新が前後しても最新が残るよう、バージョンや更新時刻で新旧を判定します。第三に確実な発行——原本の更新とイベント発行がずれないよう、更新と同じトランザクションでいったん記録してから流す（アウトボックス方式）といった作り込みが要ります。同期でつなぎたくなる誘惑を断つことが、疎結合の実効性を守ります。

止められない前提で作る——可用性・監査ログ・鍵管理

会員基盤は、機能ではなく非機能要件で寿命が決まります。まず可用性。認証はすべての機能の入口なので、ここが単一障害点になると、サービス全体が落ちます。認証系は多重化し、一部が不調でも既存のセッションは生かし続けられるよう、トークンの有効期限やフェイルセーフを設計します。連携を非同期にしておくのも、可用性を守る一手です。

次に監査ログ。誰が、いつ、どこから、何にログインし、あるいは失敗したか。管理者がどの会員情報を閲覧・変更したか。これらを、後から改ざんできない形（追記のみ）で残し、保持期間を決めておきます。不正アクセスの検知にも、漏えい時の影響範囲の特定にも、監査ログが一次資料になります。

そして鍵・シークレット管理。トークンの署名に使う秘密鍵、ソーシャル連携のクライアントシークレット、各種APIキーを、ソースコードや設定ファイル、ましてやDBに直書きしてはいけません。専用のシークレット管理（鍵管理サービス）に預け、定期的にローテーションし、参照は最小権限に絞ります。トークンの署名鍵は、更新しても検証側が追随できるよう、公開鍵を配布点（JWKSのようなエンドポイント）で切り替えられる設計にしておきます。これらは地味ですが、後付けが最も難しい部分です。

設計に、法令を織り込む

会員基盤は個人情報の塊です。まず入口として、個人情報保護法は利用目的をできる限り特定し、取得時に本人へ通知または公表することを求めています（利用目的の特定）。会員登録の画面設計と、同意・利用目的を会員データ層に保持する設計は、ここから逆算します。目的外に使わない——たとえば認証のために取得した情報を、無断で広告配信に回さない——という線引きを、データの持ち方で担保します。

次に漏えい時です。個人情報保護法では、一定の漏えい等が起きた場合に報告が義務づけられます。対象となるのは、要配慮個人情報の漏えい、クレジットカード番号やログインID＋パスワードの組み合わせなど財産的被害のおそれがあるもの、不正目的によるもの、そして本人数が1,000人を超えるものです。報告の期限は、速報が発覚から3〜5日以内、確報が30日以内（不正目的の場合は60日以内）とされています。よく混同されますが、これはEUのGDPRが定める「72時間以内」とは別の基準です。こうした要件は、設計段階でチェックリスト化しておくべきで、通信の暗号化、パスワードのハッシュ化保存、多要素認証、バックアップと復元テストが基本線になります。

「作り直し」を避ける——移行の現実解

既存の会員システムからの移行では、思わぬ壁にぶつかります。パスワードはハッシュ化して保存されているため、そのまま平文で移せません。現実的な解は三つ。ユーザーに初回ログイン時の再設定を促す、仮パスワードを発行する、あるいは遅延移行（Lazy migration）——旧方式のハッシュで初回だけ照合し、その裏で新方式に再ハッシュして以降は新方式に切り替える、という手法です。

移行そのものは、一気に切り替えず、並行稼働を挟むのが安全です。新旧の基盤をしばらく並走させ、書き込みは両系に流し、読み取りを段階的に新系へ寄せていく。問題が出たら読み取りを旧系へ戻せるよう、切り戻しの経路を最初から用意しておきます。片道切符の移行は、当日に何か起きると詰みます。加えて、契約管理と会員管理が同居している場合は、先に分離してから移すのが定石です。NTTドコモグループの事例が、基盤構築（STEP1）と他システム連携（STEP2）を分け、それぞれを段階でリリースしてサービスを止めなかったのは、まさにこの考え方の実践です。

参考にした情報：Okta（CIAMの要件）、NTTデータ 公表事例（会員基盤刷新）、個人情報保護委員会（個人情報保護法・利用目的・漏えい等の報告義務）、OpenID Connect の仕様（識別子としての iss＋sub）、LINE Developers（IDトークンの取り扱い）、名寄せの実装論に関する各種解説（キー設計・判定ルール・アルゴリズム）。IDaaS各製品の料金は改定が多く、本記事では製品名の紹介にとどめています（実料金は各社公式および比較記事を参照）。仕様・法令は改定される場合があるため、設計時は最新の一次情報をご確認ください（内容は執筆時点）。