こんにちは、リッチファンズ非公認ブログ 編集長のモリッチです。運営会社ではない、いち編集者としての観察と感想でお届けします。今日は少し技術寄りの話 — リッチファンズが「完全秘匿性」をどうやって実装しているのか、3 つのレイヤーに分けて解説します。
レイヤー 1: 通信 (IP アドレスの削除)
ウェブアクセスを受ける最前線の nginx リバースプロキシで、クライアントの IP アドレスを削除しています。
- Next.js アプリケーションログには IP が入らない
- データベースには IP を格納するカラムがない (設計時から)
- アクセスログにも記録されない
結果として、「誰がどこからアクセスしたか」を後から辿る手段が 物理的に存在しません。
レイヤー 2: 身元 (一方向ハッシュ化)
SNS 連携時、外部サービスから受け取った ID (X の user_id、Google の sub 等) は、一方向ハッシュ関数を通して不可逆な文字列に変換されます。
- ソルト (追加のランダム値) は本番環境の秘密鍵として管理
- 元の値からハッシュは計算できるが、ハッシュから元の値には戻せない
- 同じアカウントが再ログインすると同じハッシュになるので、識別は成り立つ
「あの X アカウントの人と、こちらの X アカウントの人は同一か?」の照合は可能でも、「このハッシュ値が誰か?」は特定できません。
レイヤー 3: モデレーション判定素材 (暗号化保存)
コンテンツ AI 判定に使った素材 (画像・音声のフィンガープリント、判定結果、モデレーションログ) は、すべて暗号化して保存しています。
- 復号鍵は運用側でも簡単には取り出せない設計
- 情報開示請求が来ても、「暗号化された不明瞭なバイト列」しか提供できない
結論: 「渡さない」ではなく「渡すものが無い」
リッチファンズの秘匿性は「情報開示に応じたくない」というスタンスではありません。「物理的に応じる材料を持っていない」という状態を維持することを目的とした設計です。
プラットフォーマーとしては極めて珍しい方針です。編集長が調べた限り、国内でここまで振り切っている事業者は他に思い当たりません。
編集長の感想
「ポリシーで守る」の限界は、運営体制が変わったり、司法判断が変わったりすると、ポリシーごと変わりうる点にあります。アーキテクチャで守るのは、その脆さを設計段階で消してしまう方法です。
詳細な設計思想は サービス紹介ページにも一部触れられています。
— リッチファンズ非公認ブログ 編集長 モリッチ
