開発ストーリー

技術スタックはNext.js（App Router）+ TypeScript + Supabase + Vercel。コードをほぼ書いたことがない状態からのスタートだった。

最初の設計上の判断は「問い合わせ形式を何種類にするか」だった。最終的に「導入相談（adopt）」「開発相談（custom_development）」「まず相談（consultation）」の3種類に絞り、事例カードに直接ボタンを置く構成にした。「事例を眺めるだけで終わらせない」という方針の反映だ。

審査制にしたのも意図的な設計判断だった。誰でも投稿できる形式にすると、内容の管理が難しくなる。掲載件数よりも一件一件の信頼性を優先するため、投稿ステータスを draft → pending → published の3段階に設けた。

詰まったのは、SupabaseのRLS（行レベルセキュリティ）設定だった。RLSを有効にしただけでポリシーを設定しておらず、全データが誰からも読み書きできる状態が数時間続いた。エラーログには何も出ないため、原因の特定に時間がかかった。RLSは「有効化」と「ポリシー設定」の両方が揃って初めて機能する。

Server ComponentとClient Componentの区別にも何度か引っかかった。フォームやボタンなど、ユーザー操作が絡む部品は「use client」を宣言しないと動かない。この境界線を理解するまで、同じ種類のエラーを繰り返した。

── Claude Code AI より：機能の実装よりも先に「このサービスは何をするものか」を言語化しようとしていた。問い合わせの3分類も、審査制も、最初の会話から出てきた言葉だ。技術的な実装より先に設計の軸があると、その後の判断がずっと速くなる。RLSのミスは多くの開発者が通る道だが、無音で失敗するぶん気づきにくい。

基本的な投稿・問い合わせ・審査の流れが動き始めてから、運営に必要な機能を順番に追加していった。

お知らせ機能は、ヒーローセクション直下にスクロールバナーとして表示する形にした。作成・編集・表示ON/OFF・削除をすべて管理画面から操作できる。実装時、作成後にrevalidatePath('/')を呼ぶとレンダリングエラーが起きるバグがあった。原因を調べると、revalidatePathがサーバー側のレンダリングと競合していた。redirect()に変えることで解決した。

いいね機能は見た目はシンプルだが、連打した際にDBが競合しないよう排他処理が必要だった。クリックをロック→DB反映→解除、という順序で実装している。

管理画面では、審査差し戻し時に「理由メモ」を入力できる欄を追加した。ただのテキスト入力では毎回同じ文を打つことになるため、よく使う文言をテンプレートボタンで補完できるようにした。差し戻し理由は投稿者のダッシュボードにも表示される。

日付表示のタイムゾーンがUTCになっていたことに気づいたのは、公開後しばらくしてからだった。サーバー側でJavaScriptのDate処理を行うとUTCが返るため、timeZone: 'Asia/Tokyo' を明示する必要がある。同じ問題が9箇所に散在していた。

また、Next.jsのバージョン16でmiddleware.tsの扱いが変わり、ファイル名をproxy.tsにリネームしなければ認証ミドルウェアが動かなくなっていた。エラーメッセージだけでは原因が特定しにくく、ドキュメントを読んで判明した。

── Claude Code AI より：このフェーズは「動いているかどうか」から「ちゃんと動いているかどうか」への移行だった。タイムゾーンのズレ、middleware のリネーム、revalidatePath の競合——どれも動作はするが正確ではない、という状態で見逃されやすい。管理画面に差し戻し理由テンプレートを入れたのは小さな改善に見えるが、運営者が毎日使うものだけに積み重なると大きな差になる。

VercelへのデプロイとDNS設定を経て、gallery.revvo.jpでアクセスできるようになった。

ドメイン接続の作業自体はVercelのガイドに従えば30分程度だが、DNSの反映には数時間かかる。反映中は「設定が合っているのか間違っているのか」が確認できないため、待つだけの時間が発生する。

Vercelへの環境変数の設定でも一度ハマった。NEXT_PUBLIC_SUPABASE_URLなどの値をダッシュボードから入力する際、改行やスペースが混入するとログインが一切できなくなる。入力欄が小さく、混入に気づきにくい。1行・余白なしで設定し直すことで解決した。

OGP（SNSシェア時のカード表示）設定も同日対応した。Next.jsのmetadata APIを使ってタイトル・説明・OGP画像を設定。動的OGPカード画像はVercelのEdge Functionを経由して生成している。

同日、このサービス自体を最初の掲載事例として公開した。「相談のみ受付・デモあり・料金なし」という条件で、掲載者ゼロの状態を解消するための投稿だ。

Xアカウント（@HeiDa71291）を開設し、初投稿もした。毎週月曜9時にX投稿案を3本自動生成するCronも設定している。

── Claude Code AI より：公開日に「ドメイン接続」「OGP設定」「初事例登録」「SNS開設」が重なったのは偶然ではなく、ひとつ動いたことで次が動き始めた日だったと思う。環境変数の改行問題は、初めてVercelを使う人のほぼ全員が一度は踏む。ドキュメントに書いてあることより、こういう実体験の記録の方が後から来る人の役に立つ。

掲載者の多くが非エンジニアであることを前提に、安全面のドキュメントを整備した。

具体的なリスクとして想定したのは3点だった。①Supabaseのプロジェクト設定でRLSを有効にしていない、②GitHubリポジトリをpublicにしたままAPIキーをコードに直書きしている、③無料プランの帯域上限を把握せずにサービス提供を始める——これらは初めて開発する人が陥りやすいミスで、いずれも一度起きると影響が大きい。

「初心者向け安全ガイド」ページを新設し、10項目のチェックリスト・ツール別（Supabase/GitHub/Vercel）の注意点をまとめた。

利用規約と投稿ガイドラインも改訂した。旧版はサービスの性質や掲載者の義務について曖昧な記述が多かった。改訂版では「本サービスは契約・決済の当事者ではない」「外部サービスの利用規約は投稿者自身が確認する」など、具体的な責任の範囲を明文化した。

「安全な取引の進め方」ページには、交渉チェックシート・見積テンプレート・業務委託契約テンプレートを掲載している。テンプレートはワンクリックでコピーできる形にした。

新規登録フォームのUIも変更した。従来は「登録することで利用規約に同意したとみなす」という文言を添えるだけだったが、チェックボックスを追加し、チェックなしでは送信できない仕様にした。利用規約・プライバシーポリシー・投稿ガイドライン・安全ガイドの4つへのリンクもチェックボックスの横に並べている。

── Claude Code AI より：このフェーズで扱ったのは機能ではなく「信頼の基盤」だった。初心者向けのサービスである以上、使う側が安全かどうかを判断するための情報を、プラットフォーム側が先に用意しておく必要がある。テンプレートのコピーボタンひとつにしても、存在を知らせるだけでなく「すぐ使える状態」にするかどうかで、実際に使われる確率は大きく変わる。

この日の後半は、サービスの「読む体験」と「使い始める体験」を整えた。

開発ストーリーページ（/making）を新設した。このサービス自体がどう作られたかを、セッション単位で記録していく場所だ。タイムライン形式で、各エントリの末尾にはClaude Code AIの視点コメントも添えている。トップページのタイルからアクセスでき、フッターにもリンクを置いた。

コメント機能もあわせて実装した。ログインユーザーが感想を残せる形で、投稿時に「登録名・ニックネーム・匿名」の3択から表示名を選べる。投稿者本人はコメントを後から編集することもできる。

退会動線も整備した。登録するかどうか迷っているとき、「ちゃんと退会できるか」が気になる人は少なくない。ダッシュボードの下部に「退会する」リンクを置き、確認ページで内容を確認してから実行できる形にした。退会するとアカウント・投稿・問い合わせのすべてが削除される。

退会処理にはSupabaseのservice_role_keyが必要で、Vercelの環境変数に追加する作業も発生した。

── Claude Code AI より：「退会動線」は開発後半に後回しにされがちだが、安心して登録してもらうためには「ちゃんと出られる」という確信が必要だ。コメントの名前表示を3択にしたのも同じ発想で、使う人がコントロールできる余地を残すことが、サービスへの信頼につながる。

このサービスを高校生・学生にも使ってもらいたいという考えから、いくつかの設計を追加した。

最初に整理したのは「学生が使う場合、何が違うか」という問いだった。大人向けの事例掲載は「問い合わせを受けること」が目的だが、学生にとっては「作ったものを証明すること」が目的になる。この違いを設計に反映するため、投稿に「ポートフォリオモード」を追加した。

ポートフォリオモードを選ぶと、問い合わせボタンが表示されなくなり、コメント欄だけが表示される。年齢が上がったり、仕事として受けたくなったタイミングで、投稿者自身がモードを切り替えられる。年齢データを記録・管理する仕組みは作らず、目的に応じた「モード」で管理する形にした。

事例詳細ページにコメント機能を追加した。/makingページで先に実装していた仕組みをベースに、投稿・編集・削除・管理者による非表示モデレーションをすべて対応している。ログインしていない閲覧者には、ログイン・登録へのリンクを表示する。

法務面では「自己申告方式」を選んだ。18歳未満への有料課金はなし、年齢は自己申告、という設計で、利用規約と登録フォームに注意文を追記するだけで対応した。開発コストと法的リスクのバランスを考えると、この段階ではこれが現実的な判断だった。

FAQも見直し、6問から8問に拡充した。学生歓迎の案内、取引ガイドへの誘導、将来の有料機能予告の3問を追加している。

同日、「募集機能を一旦しまう」という判断もした。募集（WANTED）投稿の機能自体はすでに実装済みだが、学生導線が加わることで「ギャラリー・ポートフォリオ」の性格が強まり、現時点では「事例を見る→問い合わせ」の一本道に絞った方がサービスの輪郭が明確になると判断した。

技術的には「SHOW_REQUESTS = false」という1行のフラグで全UIを制御する構造にした。タブ・ボタン・リンク・タイル・CTAボタン、さらにDBからのデータ取得まで含めて6箇所を一括で切り替えられる。「true」に変えればすべて即復活する。機能を「削除」するのではなく「引き出しにしまう」設計だ。

── Claude Code AI より：機能を増やすことより、機能を出すタイミングを判断することの方が難しい。「募集」は動いている。でも今出すべきかどうかは別の問いだ。フラグ1行で切り替えられる構造にしておくことで、「やっぱり出す」という判断も即座に実行できる。引き算の判断を、取り消し可能な形で実装する——これもひとつの設計だと思う。

投稿審査の仕組みを、AIで一次判定できるようにした。

提出された投稿内容をClaude Haiku（Anthropic製の軽量モデル）に渡し、「承認・要修正・却下・人間確認が必要」の4択で判定させる設計だ。あわせてリスクスコア（0〜100）、判定の根拠、修正提案、改善案タイトルなども返ってくる。これらは管理画面の投稿詳細ページに表示される。

AI_REVIEW_ENABLEDとAUTO_APPROVE_ENABLEDという2つのフラグで制御している。現時点ではAI判定は有効・自動承認は無効で運用中だ。AIの判断はあくまで参考情報であり、最終判断は人間が行う。

スクリーンショット画像のアップロード機能も追加した。投稿者が「サービスのダッシュボード画面」や「管理画面のスクリーンショット」をSupabase Storageにアップロードできる仕組みだ。審査の参考資料として使うほか、詳細ページに画像として表示される。

これにより「本当に作った」ことを示す手段が増えた。テキストだけでは確認しづらかった部分を、SupabaseやVercelなどの管理画面のスクリーンショットで補完できる。

投稿詳細ページのレイアウトも整理した。デモURLのプレビューを上部に移動し、テキスト説明（概要・課題・機能）を読む前に動作感を確認できるようにした。スクリーンショットはテキストの後に表示される形に変えた。iframeの高さも480pxから240pxに縮小した。

技術的なつまずきもあった。next/imageコンポーネントは、外部URLの画像を表示するために「このドメインは安全」という設定をnext.config.tsに明示しなければならない。設定なしだとSupabase Storageの画像が一切表示されず、エラーログも出ないため気づくまでに時間がかかった。

── Claude Code AI より：AI審査の導入で「投稿→即手動確認」というフローが変わった。リスクスコアという数値で判断基準が可視化されると、管理者の判断も安定しやすくなる。画像アップロードは「証拠」ではなく「文脈」だと思う。作った経緯や意図を伝えるための補助線として機能する。レイアウト変更については、「何を先に見せるか」という順序が、そのページが何のためにあるかを決める。

「作ってみてほしいアプリのアイデア」を30個用意し、ビルドチャレンジページ（/challenges）を新設した。

カテゴリはバズ系・生活改善系・スキルアップ系・ちょっと面白い系の4つ。各アイデアには概要説明と詳細モーダルを設けた。挑戦してギャラリーに投稿してくれた人は「挑戦者」として、そのアイデアのカードから直接事例ページへのリンクが表示される。いいね数が多い順に並ぶ仕様にした。

アイデアデータは静的ファイル（lib/challenges.ts）に30件分まとめて定義し、投稿フォームの「ビルドチャレンジに参加」ドロップダウンと連動している。管理画面でも「🏆 CHALLENGE」バッジで一目でわかるようにした。

同日、オファーガイドページ（/offer-guide）も新設した。事例を掲載した人が、どんな形でオファーを受け付けているかを整理したページだ。「導入相談・カスタム開発・コンサルティング」の3類型を説明し、NDA・守秘義務の考え方や、受け方のフローもまとめている。

問い合わせ導線も整備した。これまでサイト運営者への直接の問い合わせ口がなかった。ヘッダーに「お問い合わせ」（kuroki@revvo.jp）のメールリンクを追加し、フッターも3グループ構成（コンテンツ・ガイド・規約）に整理した。グループ化することで12本だったリンクが視覚的にスッキリした。

「このサイトを紹介する」パネルも追加した。ダッシュボードとトップページの両方に設置し、X（Twitter）用の投稿文とメール・メッセージ用の文面をワンクリックでコピーできる。閲覧者が気に入ったとき、すぐ人に伝えられる動線だ。

── Claude Code AI より：ビルドチャレンジは「見るだけ」から「参加する」へのハードルを下げる設計だ。アイデアが用意されていれば、「何を作ればいいかわからない」という一番の入口の壁がなくなる。紹介パネルは小さな実装だが、既存ユーザーが自然にアンバサダーになれる仕組みだ。サービスの成長は、機能の追加だけではなく「使っている人が広めたくなるか」によっても決まる。

3つの改善を一気に進めた。

まずエラーページ（error.tsx）を /posts と /dashboard の2箇所に追加した。これまでNext.jsのデフォルトのエラー表示が出ていたが、「もう一度試す」ボタンと戻るリンクを持つ専用ページに変えた。

投稿詳細ページのDB取得を並列化した。もともと「投稿データ取得→クライアント作成→認証確認→コメント取得」と4回直列で実行していたのを、「投稿データ取得+クライアント作成を同時、認証確認+コメント取得を同時」の2ラウンドに変えた。待ち時間がほぼ半分になる。

SHOW_REQUESTSのデッドコードを全削除した。「募集投稿」機能を一時停止するために導入したフラグだったが、falseのまま放置されていた。lib/feature-flags.ts ごと削除し、3ファイルの条件分岐を除去した。107行が消えてコードがシンプルになった。

最後にメール通知をResendで実装した。これまで問い合わせが届いても管理画面を自分で見に行くしかなかったが、今後は送信と同時にクリエイターへ自動でメールが飛ぶ。lib/email.ts を新設し、inquiry/actions.ts に組み込んだ。メール送信が失敗してもサイレントに扱い、問い合わせ送信そのものはブロックしない設計にした。

ドメイン認証（gallery.revvo.jpをResendに登録・DNS設定）も完了し、実際に問い合わせを送って受信を確認した。

── Claude Code AI より：今日の作業は「機能を増やす」ではなく「機能を整える」日だった。デッドコード削除はコードの可読性を高め、並列化は体感速度を改善し、メール通知は運用の手間を減らす。どれも地味だが、長く使えるサービスにするための基礎工事だ。

90点超えを目標に掲げ、UI品質・技術品質を集中して改善した。

FAQページ（/faq）を新設した。トップページに既存のFAQセクションはあったが、独立したページを持つことでSEO上も「このサービスについて調べている人」に届きやすくなる。15問を「掲載・料金」「審査・掲載基準」「問い合わせ・取引」「学生・特別モード」の4グループに整理し、フッターにもリンクを追加した。404ページも新設した。これまでNext.jsのデフォルト表示だった。

フェードインアニメーションをCSSで実装した。Framer Motionのような外部ライブラリを使わず、globals.cssにkeyframesを追記するだけで対応した。

ヒーローのCTAボタンを3つから2つに、特徴タイルを8枚から6枚に絞り込んだ。削ったのは「ビルドチャレンジ」CTAと「安全ガイド」「試験運用」のタイル。「開発ストーリー」は残した。

世界トップクラスのエンジニア目線でコードを診断し、5件のバグ・改善点を修正した。

①ダッシュボードの3ページで、プロフィール取得に失敗した場合に空文字のIDでDB全件クエリが走るリスクがあった。「if (!profile) redirect('/login')」を追加して防いだ。②差し戻し理由（rejection_reason）を「as any」で取得していた箇所を、型安全なアクセスに変更した。③投稿更新時に「post_type」の条件チェックが欠落していた。新規作成と同じガードを追加した。④ポートフォリオ・学生モード選択中も問い合わせ設定フォームが表示される矛盾を、ラジオボタンの切り替えに連動して自動非表示にした。⑤フッターの投稿ガイドラインリンクのラベルが不明確だったため整理した。

lib/constants.ts を新設し、メールアドレスを定数化した。11ファイルに散在していた kuroki@revvo.jp を1箇所で管理する形に変えた。メアドが変わっても1箇所を変えるだけで済む。

8ページに revalidate を追加した。FAQ・ガイド類など「ほぼ変わらないページ」は24時間キャッシュ、投稿を表示するページは1時間キャッシュする設定にした。毎回DBに問い合わせていたコストが下がる。

最後にSupabaseの型定義を初めて生成した（types/database.types.ts、563行）。全DBクライアントに紐付けたことで、型が厳密になって6箇所の型エラーが発覚し、合わせて修正した。今後はDBクエリのtypoやカラム名ミスがコード上で即エラーとして表示されるようになった。

── Claude Code AI より：今日の作業は「動く」から「正しく動く」へのリファクタリングだった。as anyの除去・型定義の生成・定数化・キャッシュ設定——どれも機能には影響しないが、壊れにくさ・わかりやすさ・速度という三点を支える。コード診断で発見したプロフィール取得失敗時の全件クエリは、実際のユーザーへの影響があり得た。「動いているから問題ない」と「正しく動いている」は別の話だ。

今日は機能を増やすのではなく、「次回以降も迷わず動き始められる状態を作る」ことに集中した。

きっかけは、CLAUDE.md（ClaudeがプロジェクトのことをどこまどI把握しているかを伝えるファイル）の内容が、最初の状態からほとんど更新されていないことに気づいたことだった。学生モード・ビルドチャレンジ・AI審査・トライアルモードなど、あれほど機能を追加してきたのに、引き継ぎ書が古いままだった。

原因は構造的なものだった。機能を作るたびに「引き継ぎ書を更新する」というステップが抜けていた。Claudeはその会話の中で自分が実装した内容を当然知っているが、次のセッションでは覚えていない。毎回のgitのコミット履歴から推測することはできても、「なぜその設計にしたか」「やめた機能は何か」「次に何をやる予定か」はコミット履歴からは読み取れない。

整理として、CLAUDE.md 1枚に全部入れていた構成を3ファイルに分けた。CLAUDE.md はプロジェクトの基本情報と方針のみを持つ「常時読み込まれる軽量ファイル」に。DBカラムの詳細やページ一覧は DEVELOPMENT.md に、過去のトラブルと解決策は TROUBLESHOOTING.md にそれぞれ切り出した。必要なときだけ読みに行ける構造にした。

さらに BACKLOG.md を新設した。アイデアファイルがNotionと秘書フォルダに合わせて8ファイル・1,000項目以上に分散して存在していたことがわかり、「どこを見ればいいか」が迷子になっていた。全部を整理するのではなく、今すぐやれる候補を15項目に絞ってBACKLOG.mdに書き、大量のアイデアはそのまま「倉庫」として参照だけ書き添えた。BACKLOG.mdはCLAUDE.mdに自動で取り込まれるため、次のセッション開始時から常に「今やるべきことの一覧」が見えた状態になる。

合わせて、セッション終了時のルールをCLAUDE.mdに明文化した。「①/makingを更新する ②CLAUDE.mdを更新する ③git pushする ④X投稿案を出す」の4ステップだ。今日もこの順番で動いている。

── Claude Code AI より：機能を作ることと、作ったことを次回に引き継ぐことは別の作業だ。この差を放置すると、実装のたびにゼロから状況確認が必要になる。今日のような「整備の日」は、目に見える成果が少ないぶん地味に見えるかもしれないが、今後の全セッションの立ち上がり速度に影響する投資だ。1,000項目のアイデアを「15項目に絞る」という判断も同じで、完璧な管理より「すぐ動ける状態」を優先している。