恋の裁判所（コイサバ）

概要

カップルが恋愛の揉め事を匿名で「公開裁判」にかけると、他のユーザー（陪審員）が有罪・無罪・どっちもどっちの三択で投票し、AIが裁判官口調の判決文まで書くiOSソーシャルアプリ。日本市場向けに、企画・デザイン・フロントエンド・バックエンド・リリースまで一人で担当。 React Nativeの27画面と独自デザインシステム、Supabase（Postgres・RLS・Edge Functions 11本・pg_cron）上のAI判決パイプライン。

担当業務

• 01

  React Native + TypeScript のフロントエンド — 27画面、独自デザインシステム、DynamicColorIOSによるダークモード。tsc・eslint・jest 221件のパスを常時の基準として維持。

• 02

  Supabaseバックエンド設計 — Postgres・RLS・Edge Functions（Deno）11本・pg_cron。AI判決パイプラインは複数プロバイダのフェイルオーバー構成、プロンプトはDBに分離してアプリ再配布なしで差し替え可能。

• 03

  リリース前に中核フローをピボット（企画判断）。当初案は「投稿 → 締切まで待つ → 締切後にようやくAIが民意を要約」で、締切は3日（72時間）だった。新規アプリで3日後の再訪を期待するのは賭けが大きいと判断し廃止。現行は、作成者が公開前にAI判定を受け、確認してから公開可否を決める流れ。投票の締切は36時間 — 夜のプライムタイムを2回カバーする長さに設定。

• 04

  同じピボットでコスト構造も転換。締切後の全件自動生成（cronバッチ）を廃し、タップ時に1回生成してキャッシュする方式へ — 誰も開かない投稿にトークンを使わない。オンデマンドのEdge Functionは verify_jwt + RLS委譲、冪等キャッシュ、429・503処理、fail-closed、ユーザーあたり24時間30件のキャップ。

• 05

  App Store審査 §1.2（同意していない第三者を大衆が裁く）への対応を、「両者の主張を必須にする」ではなく匿名性そのもので設計。写真アップロードを廃して絵文字アバターに置き換え、UGC画像のモデレーションと権限ラベルの負担をゼロに。陪審員番号はユニークなランダム6桁（登録時トリガー・衝突時は再抽選）— 従来のハッシュ %9999 方式は衝突検出がなく廃止。

• 06

  リリース前の自主セキュリティ監査で、ソーシャルログインが保存したプロフィール画像URLが未ログインの公開APIレスポンスにそのまま含まれていたことを発見（影響1件）。画面上は絵文字にフォールバックするため目視QAでは絶対に捕まらない漏れだった。アプリ側の保存停止・出口関数のホワイトリストフィルタ（レガシー行までカバー）・カラムのCHECK制約の3重で遮断。公開経路のカラムは「アプリが何を入れるか」ではなく「何が入り得るか」で判断する、という規則として文書化。

• 07

  Apple・Google・LINEの3種ログイン（LINEは公式サポートがなくカスタムEdgeで自前実装）、IAPのレシート サーバー検証、App Store審査対応（アカウント削除・Privacy Manifest・ATT）。審査期間中は共有DB・Edge Functionの変更を全面的に凍結するリリース規律を適用。

• 08

  ドキュメントがコードとずれて誤った判断を招いた経験から（537コミット中「訂正」コミット23件の最多要因）、機械が検査する事実表を導入。主要な設定値をコードから抽出して文書と突き合わせるテストを置き、コードを変えると先に文書側が落ちる構成に。

成果

企画・デザイン・開発・リリースまで、一人で完遂したプロダクション級のiOSアプリ。2026年8月15日 App Store 公開。