はじめに：ソーシャル機能とプライバシーの微妙なバランス

Airbnbは近年、よりソーシャルなプラットフォームへと進化しています。体験(Experience)に参加する人が誰かを事前に確認でき、同じ体験に参加したゲスト同士でメッセージを送り合い、プロフィールには「一緒に会った人」セクションが設けられています。

しかし、こうした機能は本質的に 個人情報の露出というリスクを伴います。「誰がこの体験に参加しているか」を表示することはユーザー体験を向上させますが、同時に「自分がどこにいるか」「誰と一緒にいるか」が他人に公開されることを意味します。

Airbnbエンジニアリングチームがこの問題をどのように解決したのか、そのアーキテクチャ的アプローチは日本のサービス開発者にとっても大きな示唆を与えてくれるはずです。

参考: 本記事はAirbnbエンジニアリングブログの Privacy-first connections: Empowering social experiences at Airbnb を基に分析・拡充したものです。原文にない日本市場向けの考察や実務的なアドバイスを追加しています。

Privacy first architecture diagram showing User and Profile separation for social features

核となるアイデア：UserとProfileを完全に分離する

Airbnbは「ユーザー(User)」と「プロフィール(Profile)」を明確に区別しました。

  • User: 名前、メールアドレス、電話番号など 内部で管理する実際のユーザー情報
  • Profile: 特定のコンテキスト（例：特定の体験）において 外部に公開される情報の部分集合

例えば、マリーというユーザーが「おばあちゃんとパスタ作り」体験にはプロフィールAで、「ヤギヨガ」体験にはプロフィールBで参加できます。プロフィールAは名前のみ公開、プロフィールBは写真と自己紹介まで公開する、というように 体験ごとに異なる公開範囲を設定できます。

これを可能にした技術的決定は User IDとProfile IDの分離です。

# 概念的にこのように分離されます
user = {
    "user_id": "u_12345",
    "name": "Marie Kim",
    "email": "marie@example.com",
    "phone": "+81-90-1234-5678"
}

profile_for_experience_a = {
    "profile_id": "p_exp_a_001",
    "user_id": "u_12345",
    "display_name": "Marie",
    "photo_url": None,  # 非公開
    "about_me": ""
}

profile_for_experience_b = {
    "profile_id": "p_exp_b_002",
    "user_id": "u_12345",
    "display_name": "Marie Kim",
    "photo_url": "https://...",  # 公開
    "about_me": "パスタとヤギが大好きです"
}

こうして分離することで、体験Aと体験Bに同じユーザーが参加していても、二つのプロフィールが互いにリンクされることはありません。 同じユーザーであることを知り得るのはシステム内部だけです。

Developer reviewing code with AI powered refactoring tools for privacy compliance Technical Structure Concept

権限システム：Himejiと最小権限の原則

プロフィールが分離されただけでは終わりません。誰がどのプロフィールを見ることができるかを制御する権限システムが必要です。

Airbnbは自社開発の権限システム Himeji を採用しています。Himejiの核心的な特徴は データレイヤーで直接アクセス制御を行う点です。フロントエンドでUIを隠すだけでなく、データベースクエリの段階から権限のないデータはそもそも取得できないように設計されています。

# Himejiの動作を抽象化した例
class ProfileAccessController:
    def __init__(self):
        # 書き込み時に権限関係を非正規化して保存
        self.permission_cache = {}
    
    def can_view_profile(self, viewer_id: str, target_profile_id: str) -> bool:
        """
        参照時はキャッシュされた権限のみを高速に確認
        """
        return self.permission_cache.get(f"{viewer_id}:{target_profile_id}", False)
    
    def grant_permission(self, viewer_id: str, target_profile_id: str):
        """
        権限付与時にリレーションを非正規化して保存
        """
        self.permission_cache[f"{viewer_id}:{target_profile_id}"] = True

この方式の利点は 読み取り性能が非常に高速で、スケーラビリティに優れることです。実際のサービスでは数百万件の権限関係をリアルタイムで確認する必要があるため、書き込み時に事前計算しておく戦略が効果的です。

AIリファクタリングと全社的協業

このようなアーキテクチャ変更を実際のコードベースに適用するのは簡単ではありません。Airbnbは以下のプロセスを踏みました。

  1. 自動監査(Audit): Pythonスクリプトでコードベース全体をスキャンし、User IDを直接使用している箇所をすべて特定
  2. チーム所有権マッピング: 各コード片を担当チームに自動割り当て
  3. 手動レビュー: 各チームがコードが内部用か外部露出用かを判断
  4. AIリファクタリング: AIツールがコード変更を提案し、エンジニアがレビュー・修正
  5. 全社的なアライメント: エンジニアリング、プロダクト、法務、プライバシーチームが一体となって推進

このプロセスで 型安全性(Type Safety) が重要な役割を果たしました。Profile IDとUser IDが誤って混在しないよう、型システムで強制しています。

// TypeScriptで表現した型安全性
// User IDとProfile IDを別々の型として宣言
type UserId = string & { __brand: 'UserId' };
type ProfileId = string & { __brand: 'ProfileId' };

function getProfileByUserId(userId: UserId): Profile | null {
    // User IDでプロフィールを検索
}

function getProfileByProfileId(profileId: ProfileId): Profile | null {
    // Profile IDでプロフィールを検索
}

// コンパイル時に誤った使用を防止
const uid: UserId = "u_12345" as UserId;
const pid: ProfileId = "p_exp_001" as ProfileId;

// getProfileByUserId(pid); // ❌ 型エラー！ProfileIdをUserIdの位置に使えない
getProfileByUserId(uid);    // ✅ 正常

Network of connected profiles with context aware permissions and access control Programming Illustration

日本のサービスに適用できるインサイト

1. User-Profile分離は想像以上に多くの場面で必要

日本国内のコミュニティサービス（例：ジモティー、ミクシィ、note）でも同様の検討が必要です。

  • ジモティー: 地域の取引相手にはプロフィールを見せる必要があるが、特定の商品に「問い合わせ」をした人のプロフィールは制限的に表示すべき
  • note: クリエイターのプロフィールと、記事に「スキ」をした読者のプロフィールの公開範囲は異なるべき

「ユーザー」という単一の概念ですべてを処理しようとすると、後からプライバシー機能を追加する際に大規模なリファクタリングが必要になります。初期段階から「コンテキスト別プロフィール」の概念を取り入れることをお勧めします。

2. 権限システムはデータレイヤーで処理せよ

フロントエンドだけで権限チェックを行うと、APIを直接呼び出した場合にバイパスされるリスクがあります。Himejiのように データベースやORMレイヤーで権限を強制することがセキュリティの基本です。

3. AIリファクタリングツールは「提案」として使い、「レビュー」は人間が行う

Airbnbの事例で印象的だったのは、AIが提案したコード変更を エンジニアが必ずレビューした点です。AIはビジネスロジックの微妙なニュアンスを完全には理解できないからです。日本でもGitHub CopilotやCursorなどのツールを使用する際、「AIが書いたから大丈夫」という姿勢は危険です。

4. 注意点：このアーキテクチャのコスト

User-Profile分離は確かに強力ですが、複雑性と運用コストが増加します。

  • データベースクエリが複雑化（User → Profile → Permissionの関係）
  • プロフィール作成/削除/変更時の同期問題が発生する可能性
  • 既存のUser IDに依存するレガシーコードのマイグレーションが必要

Airbnbは大規模なエンジニアリング組織があったからこそ実現できました。スタートアップ初期は 必要最小限のプライバシー機能だけを実装し、サービス成長に合わせて段階的に導入する戦略が現実的です。

5. 次のステップとしての学習方向

  • Zero Trust Architecture: すべてのリクエストを信頼せず、毎回認証/認可を行うアプローチ
  • GDPR/個人情報保護法対応: グローバル展開時に必須
  • ABAC (Attribute-Based Access Control): Himejiのような高度な権限システムの理論的背景

合わせて読みたい記事

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。