この連載では、３０年以上の会員システム設計・運用経験をもとに、AI時代に求められる新しい会員システムの設計思想を探究しています。一つひとつの「当たり前」を問い直しながら、未来の会員システムを読者の皆さまと一緒に考えていきます。
第1部では、Google、Microsoft、Apple、AWSなど、世界のプラットフォームが「状態」と「信頼」をどのように管理しているのかを見てきました。
メールアドレスそのものではなく、その先にあるRelationshipを支える設計思想が存在していたのです。
それでは、私たちがこれから設計すべき会員システムとは、どのようなものなのでしょうか。
プロローグ
私は30年以上、会員システムを設計してきました。
電話回線からインターネットへ。パソコンからスマートフォンへ。オンプレミスからクラウドへ。そして今、生成AIが当たり前の時代になりました。これほど大きく時代が変わったにもかかわらず、一つだけ、ほとんど変わっていないものがあります。それが、会員マスターです。
30年前も。今日も。そこには、氏名、住所、電話番号、メールアドレス、性別、生年月日——という項目が並んでいます。インターネットは変わりました。利用者も変わりました。サービスも変わりました。しかし、
会員マスターの基本構造は、
大きく変わっていません。
私は長年、この違和感を持ち続けてきました。だから第2部では、この「会員マスター」という発想そのものを、ゼロから問い直したいと思います。
↓
Dynamic
住所録は、項目を「保存」する箱だった。Relationship OS は、人を中心に置き、その人とつながるすべてのチャネルを「関係」として束ねる。静的な台帳から、動的な関係へ——これが第2部のテーマです。
はじめに
私は、「会員システム」という言葉を、そろそろ卒業する時代が来ていると思っています。
10年後。メールアドレスも、電話番号も、住所も、LINEも、SMSも、Apple IDも、Googleアカウントも——それらはすべて、人とつながるためのチャネルの一つになっているでしょう。では、時代がどれだけ変わっても変わらないものは何でしょうか。私は、Relationship（人との関係）だと考えています。
第1部では、Google、Microsoft、Apple、AWS——世界の巨大なメールインフラから、多くのことを学びました。Googleは、メール基盤が健全に機能しているか（Health）を見ていました。Microsoftは、送信者が信頼できる存在か（Trust）を評価していました。Appleは、利用者のプライバシー（Privacy）を守っていました。AWSは、送信者の評価（Reputation）を管理していました。彼らが管理していたのは、メールアドレスという文字列ではありません。状態であり、信頼です。
ここから始まる第2部では、私たち自身が未来の会員システムを設計します。私はこの新しい設計思想を Relationship OS と名付けました。これは既存のIT用語ではありません。30年以上、会員システムを設計し続ける中でたどり着いた、私自身の設計思想です。
Relationship OS は、製品名でも、ツールの名前でもありません。そして、CRMやCDPの代わりになるものでもありません。それは、「人」を中心に据えてシステムを設計するための、ひとつの設計思想です。氏名（Identity）、メールやLINE（Communication）、住所（Evidence）、購入や問い合わせ（Relationship Event）——バラバラに見えるこれらのデータを、「一人の人との関係」という一本の軸で統合して捉える。その考え方を、私は Relationship OS と呼んでいます。この記事は、メール基盤の技術解説ではなく、この設計思想についての話です。
企業ロゴではなく、設計思想を見る。4つの基盤に共通していたのは、メールアドレスという文字列ではなく、「状態」と「信頼」を管理していたという事実。第2部では、それを会員システムの中心思想として統合します。
Relationship OS とは何か
Relationship OS は、WindowsやmacOSのような、コンピュータのオペレーティングシステムとは少し意味が異なります。WindowsやmacOSは、アプリケーションを動かすための共通基盤です。一方で Relationship OS が動かすものは、人との Relationship です。
メール。LINE。SMS。アプリ。決済。イベント。AI。これらはすべて、Relationshipを支える部品に過ぎません。主役はチャネルではありません。データベースでもありません。画面の向こうにいる「人」と、その人との Relationship です。私は、その Relationship を支える共通基盤という意味を込めて、この設計思想を Relationship OS と名付けました。
なぜ「OS」と名付けたのか。WindowsがComputerを動かすように、Relationship OS は「人との関係」を動かす。メールもLINEもAIも、その上で動く部品にすぎない。主役は、いつも人です。
ここで、「それって Salesforce や HubSpot のような CRM、あるいは CDP（Customer Data Platform）のことでは？」と思われるかもしれません。しかし、ここには決定的な違いがあります。CRMやCDPは、バラバラになったデータを統合するための「器」です。一方、Relationship OS は、その器の上でデータをどう解釈し、どう Relationship を育てていくかという設計思想そのものです。
器だけでは、システムに魂は宿りません。人との関係をどう育てるか。その思想があって初めて、システムは価値を持ちます。
ツールではなく、設計思想。CRMやCDPは優れた「器」です。Relationship OS は、その器に何を盛り、どう解釈し、どう関係へ還元するかという「思想」。器だけでは、関係は育ちません。
第1章 会員マスターには「人」が存在しているでしょうか
ここで、皆さんに一つお願いがあります。明日、自社の会員システムを開いてみてください。そして、会員マスターを眺めてみてください。そこには何が並んでいるでしょうか。氏名、住所、電話番号、メールアドレス、生年月日、趣味、職業——。
では、そのデータから、その人が最近何に興味を持っているのか。どの商品を見ているのか。どのイベントへ参加したのか。LINEでは反応しているのか。最近困って問い合わせをしたのか。何一つ分かりません。そこに存在しているのは、血の通った「人」ではありません。住所録です。
少しだけ、自問してみてください。そこに並んでいる一つひとつの項目に、「なぜ、このデータを預かっているのか。」と。その問いこそが、Relationship OS の出発点です。
↓
関係
同じ「一人」でも、見え方がまるで違う。左は保存された項目の集合。右は、興味・購入・問い合わせ・参加が一人の人へつながった「関係」。会員システムが本当に持つべきなのは、右の姿です。
会員マスターに必要なのは、項目の数ではありません。その項目の向こうに「人」が見えるかどうかです。
第2章 30年間、変わらなかった設計
昔の会員マスターは、住所録としては最高の設計でした。紙の住所録をデジタル化する。それが当時の目的だったからです。だから、昔の設計者が間違っていたわけではありません。むしろ、その時代においては、非常に優れた設計でした。
しかし、時代は変わりました。AIが人との関係を理解しようとしている今、30年前と同じ設計思想のままで良いはずがありません。私が問い直したいのは、住所ではありません。メールアドレスでもありません。「会員マスター」という発想そのものです。
昔は住所録を作れば十分でした。しかし、これから求められるのは、人との Relationship を理解し、育てるシステムです。だから私は、会員マスターの基本構造を問い直そうと言っています。時代が変わった。だから、設計も変わらなければならないのです。
登録は、ゴールではなくスタートです。会員マスターは「一度書いて終わる台帳」ではなく、「関係とともに更新され続ける状態」として設計すべきです。
第3章 世界は何を管理しているのか
第1部で見てきたように、GoogleはHealth。MicrosoftはTrust。AppleはPrivacy。AWSはReputation。一見すると、それぞれ別のテーマのように見えます。しかし私は、この30年間システムを設計してきた中で、一つの共通点に気付きました。彼らが本当に管理していたものは、Relationshipを安全に維持するための状態だったのです。
メールアドレスという文字列ではありません。住所という文字列でもありません。「この人と安全につながり続けられるか。」その状態を管理していました。
例えばGoogleやAppleは、ユーザーを会員登録時に入力された住所という静的なデータだけで理解しているわけではありません。ユーザーが毎日持ち歩くスマートフォン。GPS、Wi-Fi、基地局、Bluetooth、位置イベント、利用履歴、ログイン履歴、端末情報、購買履歴。これらを組み合わせながら、「このユーザーは、今どのような状態なのか。」を理解しています（各社の内部アルゴリズムは公開されておらず、ここは推測を含みます）。
例えばGoogleマップでは、自宅や職場を登録しなくても、自動的に候補として表示されることがあります。これは、毎日の行動パターンから生活拠点を推定しているためだと考えられます。つまり、住所という文字列を管理しているのではなく、行動のコンテキストを管理しているのです。
世界が管理しているのは、
静的なデータではなく、状態（State）である。
国内でも同じ流れが始まっています。LINEヤフーは、検索、LINE、PayPayなど複数サービスの利用データを活用しています。メルカリは、売買履歴や決済履歴などからユーザーごとの信頼性を判断しています。もちろん、これらは私が提唱する Relationship OS そのものではありません。しかし、静的な属性ではなく、動的な行動を重視する方向へ、世界のシステム設計が進んでいることを示す重要な事例だと私は考えています。
管理すべきは、登録時の静的な属性ではありません。変化し続ける「動的なコンテキスト」こそが、人を理解する手がかりになります。
第4章 住所は本当に必要なのか
ここで誤解していただきたくないことがあります。私は、住所は不要だと言いたいわけではありません。住所には重要な役割があります。配送。請求。本人確認。そして、不正利用時の証跡。つまり住所は、Evidenceとして非常に重要なデータです。
しかし、その住所は、Relationship を育てているでしょうか。毎日のコミュニケーションを支えているでしょうか。実際に人との Relationship を動かしているのは、メール、LINE、SMS、購入履歴、イベント参加、問い合わせ——日々積み重なる行動です。
だから私は、住所を否定したいのではありません。住所には住所の役割がある。その役割を明確に定義したいのです。Relationship OS では、住所は Identity ではありません。Evidence です。役割を定義すること。それが設計なのです。
住所は Evidence、メールは Communication——このように、データにはそれぞれ役割があります。この「役割」という考え方そのものは、第6章であらためて整理します。ここでは、「会員情報だから持っている」のではなく、「役割があるから持っている」へと発想を切り替える、とだけ覚えておいてください。
「会員情報だから」は、取得の理由になりません。その項目を、何のために預かるのかを説明できないデータは、持たない勇気も必要です。
第5章 誕生日・趣味・職業を問い直す
住所だけではありません。会員マスターにある一つひとつの項目にも、「なぜ取得するのか。」という問いが必要です。例えば、生年月日。誕生日メール、年齢確認、マーケティング——様々な目的があります。しかし、本当に Relationship を育てているでしょうか。
例えば、誕生月によって顧客体験が変わってしまうことがあります。私はこれを、「誕生日ガチャ」と呼んでいます。クリスマス。年末年始。ゴールデンウィーク。世の中が最も忙しい時期に誕生日を迎える方もいます。そんな時期に、「お誕生日おめでとうございます。」という自動メールを送ったとしても、他の大量の通知に埋もれてしまうでしょう。システム都合で送るお祝いは、届いたとしても、心には届かないことがあります。
以前の記事で、「お正月の元旦に特別コンテンツを公開したところ、訪れていたのは一部の熱心な会員だけだった」という実体験をお話ししました（「あなたは、土曜日の夜にやってくる。」）。人がサービスを開かない時期にどんなに良いものを届けても、届かない。この「タイミング」の問題は、そのまま誕生日メールにも当てはまります。送る側の都合ではなく、受け取る人の状態で考える。それが Relationship を育てる設計です。
Relationship OS では、誕生日よりも、会員登録日、初回購入日、初回来店日——つまり、Relationship が始まった日を大切にします。企業と人との出会い。その歴史を祝うことの方が、Relationship を育てる設計になると私は考えています。
趣味も同じです。十年前に登録した趣味は、今も趣味でしょうか。職業も同じです。BtoB では重要です。しかし、一般消費者向けサービスでは、その情報は本当に活用されているでしょうか。
Relationship OS は、取得そのものを否定する思想ではありません。重要なのは、取得する理由を説明できること。そして、そのデータを Relationship へ還元できること。
実は、この考え方は私だけのものではありません。欧州のGDPR（一般データ保護規則）では、第5条で Purpose Limitation（目的制限の原則） が定められています。取得目的を明確にし、その目的以外には利用しない。「何のために預かるのか」を問い直すこの方向は、私一人の考えではなく、世界もまた同じ方向へ進んでいることの表れです。
「何となく昔から取得している。」
その設計は、いまやガバナンスリスクです。
Relationship OS は、データを減らそうという思想ではありません。そのデータが、なぜ存在するのか。それを説明できる設計思想なのです。
項目は、増やすほど豊かになるわけではありません。「この項目で、どんな関係を育てたいのか」を言えるかどうか。それが、設計の最初の問いです。
第6章 Relationship OS の設計思想
Relationship OS では、データベースに保存されるすべてのデータに、役割があります。氏名は Identity（本人識別）——本人を識別し、名前で呼び掛けるためのデータ。住所は Evidence（証跡・配送・本人確認）——配送や本人確認、不正利用時の証跡となるデータ。電話番号は Authentication（認証）——SMS認証や緊急時の連絡手段。メールアドレスやLINEは Communication（コミュニケーション）——継続的に、そしてリアルタイムに Relationship を維持するチャネル。
そして、購入履歴、イベント参加、問い合わせは Relationship Event（関係性イベント）——企業との Relationship を深める、重要な出来事です。問い合わせは、困りごとだけではありません。企業との対話そのものが Relationship です。
重要なのは、データを減らすことではありません。データベース設計とは、カラムを定義することではありません。そのデータが Relationship の中でどのような役割を持つのか。その役割を定義することです。Relationship OS とは、データベース設計そのものを、Relationship という視点から再設計する思想なのです。
中心は、いつも人。本人性・証跡・認証・連絡・関係イベント・AI——すべては独立した項目ではなく、一人の人へつながる「役割」。データは人を説明するために存在します。
主キーは、メールアドレスでも会員IDでもありません。「人」を中心に置き、すべてのデータをその人の役割として束ねる——これが Relationship OS の出発点です。
第7章 Relationship を育てるのはイベントである
従来の会員システムは、年齢、性別、住所、職業、趣味——こうした属性で人を理解しようとしてきました。Relationship OS は違います。Relationship を育てるのは、イベントです。
登録した日。初めて購入した日。問い合わせをした日。イベントへ参加した日。メールを読んだ日。LINEへ返信した日。これらはすべて、Relationship Event です。そして、そのイベントは時間とともに積み重なります。私はこれを、Relationship Timeline と呼んでいます。
Relationship とは、一枚の名刺ではありません。一つの住所でもありません。時間をかけて積み重なる、人と企業との歴史なのです。
上書きではなく、積み重ね。登録から始まった関係は、購入・問い合わせ・参加・継続を経て、ファンへと育っていく。Relationship OS が記録するのは、最新の属性ではなく、この「時間の流れ」そのものです。
関係は、上書きでは捉えられません。「いつ・何が起きたか」という出来事の時系列を残すことが、人を理解する土台になります。
第8章 AIが見るもの
AIは、メールだけを見ません。例えば、メールは開かない。しかし、LINEには必ず返信する。イベントには参加する。問い合わせもしている。従来のシステムであれば、「メールを開かない、だから休眠顧客」と判断していたかもしれません。
しかし Relationship OS の視点を持ったAIは違います。「メールというチャネルとの相性は良くない。しかし、Relationship は維持されている。」そう理解します。AIが分析する対象は、メールではありません。LINEでも、SMSでもありません。チャネルではなく、Relationship そのものです。
そしてAIは、Relationship を単なる数値ではなく、状態として理解するようになります。これが、次回お話しする Relationship Score という考え方です。
一つの指標では、見誤る。メールが「×」でも、イベントが「◎」なら、関係は生きている。AIは複数のチャネルを横断して関係の状態を読み取り、次回テーマの Relationship Score へとつなげます。
単一チャネルの数字で、人を判断してはいけません。AIが見るのは、関係の全体像です。だからこそ、関係イベントを横断して残す設計が必要になります。
そして、すべては一本の道でつながる
ここまで、Relationship Event、Relationship Timeline、Relationship Score——いくつかの言葉が登場しました。しかし、これらはバラバラの概念ではありません。すべては、一本の道でつながっています。
日々の出来事（Relationship Event）が、時間とともに積み重なります。その積み重ねが、Relationship Timeline —— 人と企業の歴史となります。その歴史を AI が読み解き、関係の状態を Relationship Score として理解します。そして、この一連の流れ全体を支える共通の設計思想が、Relationship OS です。
バラバラの言葉ではない。出来事が積み重なって時系列になり、AIがそれを読み、状態のスコアになる。その全体を支える設計思想が Relationship OS。すべては、一本の道でつながっています。
まとめ
30年前。私たちは住所録を作りました。20年前。私たちは会員管理システムを作りました。そして今。私たちが作るべきものは、Relationship OS です。
Relationship OS は、データを減らそうという思想ではありません。データの役割を定義し、人との Relationship を育てるための設計思想です。住所には住所の役割があります。メールにはメールの役割があります。趣味にも、職業にも——取得するのであれば、Relationship の中で果たす役割があります。
しかし、企業にとって最も価値のある資産は、住所でもありません。メールアドレスでもありません。人との Relationship です。
私は30年以上、会員システムを設計してきました。だからこそ、今、会員マスターを作り直すべきだと言っています。インターネットは変わりました。スマートフォンも生まれました。クラウドもAIも普及しました。しかし、会員マスターの基本構造は、大きく変わっていません。私は、この事実こそが、未来の会員システムを考える出発点になると考えています。
最後に、一つだけお願いがあります。明日、皆さんの会社の会員マスターを開いてみてください。そして、そこに並ぶ一つひとつの項目に問い掛けてみてください。「このデータは、何のために存在しているのか。」
Relationship OS は、新しいシステムを作ることから始まるのではありません。今ある会員マスターを問い直すことから始まります。私たちは30年間、住所録を作り続けてきました。しかし、これから私たちが作るべきものは住所録ではありません。人との Relationship を育てる基盤です。それが、私が30年以上の現場経験からたどり着いた設計思想、Relationship OS なのです。
これが、第2部全体の象徴です。WindowsはComputerを、macOSはApple Deviceを動かす。Relationship OS が動かすのは、人との関係。だから私たちは、レコードではなく、関係を設計します。
住所もメールもLINEも、すべては人とのRelationshipを育てるための部品です。中心に置くべきは、項目ではなく人。会員を管理する時代は終わりました。これからは、人との関係を設計し、育て、動かす時代です。そして、最後に一つだけ。Relationship OS は、新しいシステムではありません。人との Relationship を育てるための、設計思想です。第2部では、この思想を、さらに具体的な設計へと落とし込んでいきます。
連載ロードマップを見る
エビデンス・参考資料
- GDPR（EU一般データ保護規則）第5条 ── 目的の限定（purpose limitation）／データの最小化（data minimisation）
- Google Account ヘルプ / Google セーフティセンター（アカウント・データの取り扱い）
- Apple「プライバシー」公式ページ / Apple Platform Security（データ保護の設計思想）
- Amazon SES Developer Guide / Sending Best Practices（レピュテーション管理）
- Microsoft Learn：Exchange Online Protection（EOP）/ Smart Network Data Services（SNDS）
- RFC 7208（SPF）／ RFC 6376（DKIM）／ RFC 7489 および関連RFC（DMARC）
- 総務省「特定電子メール法」および関連ガイドライン / 個人情報保護委員会 公表資料
- LINEヤフー公式ヘルプ / 各社サービス公開ドキュメント
本連載は、公表されている技術仕様や各社の公式ドキュメントを参考にしつつ、筆者が長年にわたり会員システムを運営・設計してきた現場での経験と考察をもとに構成しています。「Relationship OS」は、岸本健志が提唱する設計思想の呼称であり、特定の製品・商標を指すものではありません。Google・Apple・Microsoft 等の内部アルゴリズムは公開されておらず、本文の関連記述には推測・考察が含まれます。
Googleは、送信者を Trust で評価しています。では、会員システムは何を評価すべきでしょうか。
クリック数でしょうか。購入回数でしょうか。ログイン回数でしょうか。私は、それだけでは足りないと思っています。
AI時代に本当に必要なのは、人との関係そのものを理解する新しい指標です。次回は、Relationship OS を支える重要な概念である 「Relationship Score」を通して、「人との関係を、どのように可視化するのか」を考えます。
ここから第2部は、「思想」から「設計」へ入っていきます。
名寄せ・重複会員の統合、マルチチャネルの一元管理、関係イベントの時系列化まで。PayAI NEXT では、会員を「項目の集合」ではなく「一人の人との関係」として設計する Relationship OS の考え方にもとづき、次世代の会員マスター設計・運用プランをご提案しています。お気軽にご相談ください。
1997年よりインターネット業界に従事。2007年の創業以来、EC、メディア、SaaS、コミュニティサイトなど数多くの会員ビジネスの立ち上げと成長を支援。
30年近く会員システムの設計・運用に携わる中で、システムは「会員を管理するもの」から「人と人との関係（Relationship）を育てるもの」へ転換すべきだと確信。現在は、AI時代における次世代のシステム設計思想として「Relationship OS」を提唱しています。
また、自身も宿泊施設の運営で現場に立ち続け、『起きている時間はすべて仕事であり、システムへの探求』という圧倒的な熱量で、会員ビジネスの未来に向き合っています。
「人との関係は設計できるのか」という問いに、これからも人生をかけて愚直に向き合い続けていきます。