だみん
SumaiSync【開発記録 vol.2】 AIと一緒に走り続けたら、いつの間にか本番アプリができていた話
2026年04月16日
見出しはありません
要約を生成中...
Week 3 振り返り：がんがんvibe codingで、アプリが一気に「本物」になった話
Week 3 は、いよいよ 開発本番の週 でした。
Week 1 で題材が決まり、Week 2 で環境が整ったので、ここからはひたすらコードを書いていく週です。
ただ正直なところ、最初に想定していた以上に、想定外の問題にぶつかりながらアプリが育っていった週でした。
Week 3 でやったことを大まかに挙げると、こうなります。
ペア機能（招待コード発行・入力・ペア成立）の実装
Supabase RLS（行レベルセキュリティ）の大幅見直し
テーマ・カラーカスタマイズ機能の実装
見送り一覧ページの追加
Vercel へのデプロイ
PWA 化（スマホのホーム画面に追加できるようにする）
Next.js のセキュリティパッチ適用
パスワードリセット機能の実装
振り返ると、かなりの量をこなしていたことに気づきます。
Week 3 でいちばん時間がかかったのが、**ペア機能まわりのRLS（行レベルセキュリティ）**でした。
Supabase には、「誰がどのデータにアクセスできるか」をテーブル単位で制御できる RLS という仕組みがあります。Week 2 まではシングルユーザーを前提にしていたので、ほぼ「自分が作ったデータしか見えない」ポリシーだったのですが、2人で共有するペア機能を入れた途端に、あちこちで問題が出始めました。
新しいアカウントで招待コードを入力しても、ペアへの参加が403エラーで失敗する
ペアが成立しているのに、パートナーが登録した物件が相手側に表示されない
相手の評価やコメントも見えない
パートナーの名前も取れない
どれも画面には何も表示されず、静かに失敗しているタイプのバグで、原因を特定するのが地味に大変でした。
RLS のポリシーは SQL で書くのですが、「USING 句（更新前のチェック）」と「WITH CHECK 句（更新後のバリデーション）」の使い分けがあることを、このタイミングで初めてちゃんと理解しました。
たとえば、ペアへの参加処理では、user_b_id がまだ NULL（未参加）の行を更新する必要があるのですが、元のポリシーは「自分が関係する行しか更新できない」になっていました。user_b_id が NULL の状態では自分はまだその行と関係がないので、弾かれていたわけです。
AIと「このクエリって本当に大丈夫？もう一回考え直して」とやり取りしながら、ポリシーの条件を一つひとつ確認していきました。最終的にはペア参加・物件共有・評価参照・コメント参照・ユーザー名参照のすべてのポリシーを見直して直しました。
ポリシーの命名も、最初は日本語で「自分が登録した物件を参照」みたいになっていたのを、全部 snake_case の英語に統一しました。
ペア機能が安定したタイミングで、テーマ・カラーカスタマイズ機能も入れました。
SumaiSync はデフォルトでエメラルドグリーンを使っているのですが、設定画面からアクセントカラーを5色（エメラルド / スカイ / バイオレット / ローズ / オレンジ）の中から選べる仕組みにしました。
技術的には CSS カスタムプロパティ（--accent など）を使い、html 要素の data-accent 属性を切り替えることで色が変わる設計にしています。Tailwind でランタイムにクラスを動的に生成するのは難しいので、CSS 変数を使う方法が一番シンプルでした。
localStorage に保存しているので、リロードしても設定が残ります。こういう「細かいけど気が利いてる」機能、自分で使ってみると思った以上に嬉しいことに気づきました。
Vercel へのデプロイは思ったよりスムーズでした。GitHub リポジトリと連携しておくと、master に push するたびに自動でデプロイされます。
Supabase の Redirect URLs 設定も要注意でした。パスワードリセット機能を実装したとき、メール送信が 401 エラーになって原因を調べたら、Supabase のダッシュボード側でリダイレクト先のURLを許可リストに追加していなかっただけでした。セキュリティのために、知らないURLへのリダイレクトは Supabase 側で弾かれる仕様になっているんですね。
PWA（Progressive Web App）というのは、Webアプリなのにスマホのホーム画面に追加してネイティブアプリっぽく使える仕組みのことです。
住まい探しのアプリって、ふとした移動中にパートナーとチェックしたくなるシーンが多いと思っていたので、スマホで使いやすくしたかったのです。
manifest.ts を追加して、アイコンをエメラルド背景 + 白の家マーク（192px / 512px）で作ってもらいました。ファビコンも一緒に。こういう「デザイン素材を言葉で伝えてAIに生成してもらう」感じ、vibe coding らしくて楽しかったです。
RLS は「認証（ログイン済みか）」と「認可（このデータにアクセスしていいか）」は別物で、きちんと設計しないとデータが見えなかったり、逆に見えてはいけないデータが見えたりする
ミドルウェアはUXのためのリダイレクトであり、セキュリティの保証ではない。セキュリティはDBのポリシーとServer Actionsの認証チェックで担保する
デプロイしてみると、ローカルでは気づかなかった問題が出てくる。環境変数・リダイレクトURLの設定漏れなど
「やらないこと」を守り続けるのが意外と難しい。次々と「これも欲しい」と思ってしまうのをMVPの範囲に絞る判断は、今週も何度かしました
今週いちばん印象的だったのは、アプリが「それっぽいもの」から「ちゃんと動くもの」に変わった瞬間です。
ペア機能が成立して、2つのアカウントで物件を共有できるようになったとき、「これ、本当に使えるな」という手ごたえを感じました。
また、セキュリティのことをちゃんと考えながら開発するのが、思ったより面白かったです。RLS のポリシーを設計したり、APIキーの扱いを確認したりする作業は、「動くものを作る」以上に「安全に動くものを作る」という感覚で、新鮮でした。
パスワードリセット機能を入れたのも、「ログインできなくなったらユーザーが詰む」という当たり前のことをちゃんとケアしようという意識からでした。小さいことですが、こういうUXの穴を埋める判断を自分でできるようになってきたのは成長かなと思っています。
Week 4 のテーマは 公開・運用・発信 です。
まずは E2E テスト（Playwright）でアプリ全体のフローを通しで確認して、品質を担保します。ユニットテスト・APIテスト・コンポーネントテストはすでに全グリーンなので、最後の仕上げです。
テストが揃ったら、いよいよ外に出していきます。せっかく実体験ベースで作ったアプリなので、実際に使ってもらえる人に届けたい。X・Instagram・Threads での発信や、開発過程のブログ記事を通じて、SumaiSync を知ってもらうフェーズに入っていきます。
Week 3 は、機能を大量に実装しながら、本番運用に耐えるアプリとして整える週でもありました。
RLS のバグ・デプロイ後の設定漏れ・セキュリティの見直し…。想定外のことは多かったですが、AIとやり取りしながら一つひとつ解決できたのは、vibe coding の醍醐味だと感じています。
「動くから良し」ではなく、「ちゃんと安全に動く」ところまで見られるようになってきた Week 3 でした。
要約
コメント
まだコメントはありません。
