7日間で月額SaaSをリリース — LDL142の心筋梗塞から Next.js × Supabase で低コレ食堂を作るまで

この記事は闘病記ではない。プログラマーが本職ではない当事者が、コードを1行も書かずにAIに丸投げで7日間で月額SaaSを出した記録だ。技術選定もコードも全部AIに任せ、自分が判断したのは「何を作るか」「何を残すか」「何を捨てるか」だけ。倒れた経緯と感情の側は note の当事者連載に分けてある（末尾にリンク）。

LDL142という出発点

事実だけ並べる。

• 2026-04-10：LDL142、心筋梗塞、緊急搬送
• 2026-04-13：カテーテル手術
• 2026-04-16：退院（入院7日間）
• 2026-04-17：AIに「自分用の簡単な献立サイト」を相談 → スコープが膨らみ「月額SaaS可能」と判明
• 2026-04-18：本格開発開始（Day 1）
• 2026-04-24：低コレ食堂リリース（Day 7）

退院した日（4-16）にやったのは、病院でもらった管理栄養士の食事資料を読み直すことだった。そこで先生から聞いた一言が引っかかっていた——「1日の栄養は多少上下してもいい。ただし、1週間で平均して、塩分なら6g以下を目安に」。つまり、必要なのは「今日1食の管理」ではなく「1週間の献立の総和を整える設計」だ。市販のレシピアプリは「食材検索」が主で、「LDLを下げたい人の1週間献立」という視点では作られていない。当事者の自分が毎日使うために作ろうと決めた。翌日（4-17）、AIに「自分用の簡単な献立サイトを作りたい」と相談を始めた。話すうちにやりたいことが増え、「これは課金できるのでは」と思うようになった。

なお食事療法の効能や栄養学の話はここでは書かない。書くなら別の場所で、書ける範囲で。

制約条件 — 「捨てるリスト」を最初に書いた

制約は2つ。

• 退院直後の体力：1日4〜5時間しか開発に充てられない
• 開発者：1人

リリースまでの期限は決めていなかった。ただ、退院直後の当事者性と体力のテンションが続くうちにリリースしたい、という方針はあった。「鉄は熱いうちに打て」を物理的に実現したい——それだけだ。

鉄が熱いうちにリリースしたかったから、まず最初の数時間で「何を残し、何を捨てるか」を方針として固めた。「期限7日」ではなく「捨てるラインを最初に決める」だけが、最大の判断だった。結果として7日目にリリースできる状態に達した、というのが事後的な事実だ。

検討して、外したもの

• 撮影画像からのカロリー自動予測（信頼性が乏しく、誤った数値で食事記録が汚れるリスクが高い）
• 血圧・体重の画像OCR入力（機能としては魅力的だが、手入力で十分・機能過多と判断）
• 「実際に食べたもの」を緻密に記録する設計（続けられなければ意味がない。目標を高くして挫折させる設計を避けた）
• ネイティブアプリ化（作り方表示中の画面ロック対策として検討→React + PWA で十分代替できた。課金面で必要になれば再検討する）
• 専用管理画面（Supabase 管理画面で運用すれば足りる）

そもそも検討の俎上に載せなかったもの

• 自前認証（Supabase Auth 前提。当事者性が続くうちのリリースに間に合わないので即除外）
• 多言語対応
• カスタムデザインシステム
• リッチな献立編集UI（ドラッグ&ドロップ / 共有 / エクスポート）
• 自前インフラ（Docker / VPS / Kubernetes — そもそも知識がない領域はマネージドに丸投げ）

「検討して外した」と「検討すらしなかった」は別物だ。後者は判断ですらない。判断の俎上に載せないと決めた時点で、その領域に1秒も使わない。これも「鉄が熱いうちにリリースする」ための判断だった。

残したもの

• 認証（Supabase Auth に丸投げ）
• 今週＋来週の献立 + 買い物リスト（これが見られないと使い物にならないので、最初から必須要件として実装）
• 体重・血圧・LDL を記録する
• 月額課金導線（Stripe Checkout）

残したものを主軸に置いて開発を進め、それ以外の機能はバイブコーディングで必要なものをその場で追加していった。コアだけ固定して周辺は流動的にする、このスタンスが結果として7日目のリリースを可能にした。

コードは書かない、AIに任せる

ここで前提を一つはっきりさせる。自分はプログラマーが本職ではない。コードが書けないわけではないが、AIに任せた方が圧倒的に早いし正確で、体感では自分の100倍速い。

今回の7日でも、コードは1行も書いていない。技術選定もコードも、すべてAIに任せた。自分がやったのは、AIに「何を作りたいか」「何を残すか」「何を捨てるか」「どんな制約があるか」を伝え、出てきたものを採用するかどうかを判断することだけだった。

速いと、何が良いか。一つ目は、開発途中の挫折が圧倒的に減ることだ。プログラマーが本職ではない自分が一人で書くと、エラーで詰まる時間、調べる時間、リファクタする時間ですぐ何日も溶ける。気持ちが続かない。AIに任せると、その障壁が消える。作り上げる前にやめてしまう、という個人開発の最大の敗因が回避できる。

二つ目は、ローンチまでの機会損失が小さくなること。退院直後の体力と当事者性のテンションは、長くは続かない。「鉄は熱いうちに打て」を物理的に実現できるのが、AIに任せる最大のリターンだ。考えていたものを、考えていた熱量のうちに世に出せる。

これは「楽をした」のではない。当事者起点でプロダクトを作るとき、コードが書けるかどうかはもう律速ではない、ということだ。「自分が一番このサービスを欲しい人」が直接プロダクトを動かせるなら、エンジニアに要件を伝える往復は不要になる。判断のレイテンシが消える。

もちろん、AIが出すコードを盲信したわけではない。動かしてみて挙動を確認し、想定と違えばAIに「ここをこう直して」と伝える。バグが起きれば再現条件を渡してAIに調べさせる。自分の役割は「設計者・当事者ユーザー・QA」であって、「実装者」ではなかった。

技術選定 — AIが提案したスタックを採用

スタックは Next.js (App Router) + Supabase + Vercel + Stripe Checkout。ただし、これを自分で比較検討して選んだわけではない。AIに方針だけ伝え、提案されたものをそのまま採用した。

自分が決めたのは方針だけだ。

• マネージドサービスだけで完結すること（サーバ運用に1秒も使わない）
• 月額固定費を最小化すること（個人開発で長く続けられる前提）
• 課金は最短ルートで通すこと（カード入力UIは作らない・解約画面は後回し）
• 1週間で動かしきれること

この条件をAIに渡したら、Next.js × Supabase × Vercel × Stripe Checkout の組み合わせが返ってきた。Rails や Firebase、Cloudflare Workers との比較も含めてAIが整理してくれた。自分は「これで進める」と判断しただけだ。

採用した構成

役割	採用したサービス
認証	Supabase Auth
DB	Supabase Postgres（RLS で権限制御）
ファイル	Supabase Storage
ホスティング	Vercel
監視・ログ	Vercel と Supabase の管理画面
課金	Stripe Checkout + Webhook で subscriptions テーブル更新

サブスクSaaSの肝は「課金状態でアクセス制御」が破綻しないこと — ここはAIに任せた。ただし、UIや解約画面を「後回しでいい」とは考えなかった。課金から解約までユーザーが困らずに操作できることは、リリース時点で揃えるべき要件として最初から固めていた。これは自分が当事者ユーザーとしての立場で決めた要件で、AIに委ねなかった。

7日間のタイムライン

実際の進行はこうだった。Day 0 を退院翌日（4-17）のスコープ相談日、Day 1 を本格開発の初コミット日（4-18）、Day 7 がリリース当日（4-24）にあたる。

詰まった話を2つ

7日のうち、AIに任せていてもうまくいかず本気で詰まったのは次の2件だった。どちらも commit log にそのまま痕跡が残っている。

1. Vercel 60秒制限 vs 1週間ぶんの献立 AI 生成

最初はAIが「献立生成も Vercel Functions で完結させる」前提で組んだ。1ユーザー分でも Claude API 呼び出しが20〜30秒級になり、複数ユーザー × 週次自動生成を考えると 60 秒では到底収まらない。

打った手は3つ。Sonnet 系から Haiku への切り替え、生成失敗時のリトライ削除、enrichment（栄養値補完）を生成APIの外に出す — どれもAIに指示して実装させた。それでも本番の週次バッチには厳しく、最終的に「Vercel cron で月額SaaSの本番バッチを回す」設計を捨て、ロリポップの PHP cron に逃がす判断を自分でした。Vercel に固執しない判断ができたのは、コードを自分で書いていないからこそ — 「今組んでいるものに愛着がない」ことが切り替えの早さに繋がったと思う。

2. Supabase クライアントの使い分け（cookies() が unstable_cache 内で使えない）

Next.js の unstable_cache の中で、Supabase の認証付きクライアント（cookie からセッションを取り出すタイプ）を呼ぼうとすると失敗する。cookies() がキャッシュ関数のスコープでは呼べないためだ。

最初はAIが「ユーザー認証 client（createClient）だけで通す」構造で組んでハマった。Day 4 でAIに「ユーザー認証は RLS 適用 client、データ書き込みや一括処理は service role の admin client」と役割で分ける構造に切り替えるよう指示し、食材マスタの取得などは createAdminClient 経由に直してもらった。RLS を「全部 anon でやる」発想から、「読みは RLS、書きはサービスロール」というよくある分け方に着地させた、というだけの話だが、AIに任せた最初の構造をそのまま採用していたため、これを設計初日に確定できていなかったのが地味に効いた。

7日に収まった理由 — コア固定・AI委任・当事者性

結果として7日目にリリースできた本当の理由は技術選定ではない。「コアを最初に固定したこと」「コードを書かずAIに完全委任したこと」「当事者であること」の3点が噛み合った結果だ。期限を決めて走ったのではない、走り続けた結果が7日目だった。

1. コアを最初に固定した。 「これだけは残す」という核を Day 1 に決めて動かさなかった。それ以外は開発しながら必要だと気づいたものをその場で足していく。「あったほうがいい機能」が浮かんでも、答えはすぐ出る — 「これは主軸の上に乗るか、乗らないか」だけだ。

2. コードを書かずAIに完全委任した。 自分で書いたコードには「動くまでに費やした時間」への愛着が残る。AIに書かせたコードにそれはない。Day 3 で Vercel cron から PHP cron に逃がす判断ができたのも、組んだコードを惜しまずに済んだからだ。コードに自分の時間を投じていないことは、ピボットの軽さに変換される。

3. 当事者であることが判断軸になった。 普段のWebアプリ開発では「ユーザーがこれを欲しがるか」を考えて作る。当事者の自分が毎日使うものだと、「自分が今これを使いたいか」で判定できる。判断のレイテンシが消える。

これは資格や経験ではない。「コアの固定」「AI完全委任」「当事者性」が生んだ判断力で、誰でも自分が当事者である領域では同じことができる。

1ヶ月運用してわかったこと

• 早く出すと修正点が即座に明確になる：当事者の自分が毎日使うので、不満が出た瞬間に直したい場所が分かる
• 当事者ユーザー＝自分、を起点にすると判断が迷わない：「自分は使うか？」で全部決まる
• マネージドサービス選定は正解だった：1ヶ月でインフラ起因のトラブルゼロ
• AI完全委任でも運用は回る：機能追加・バグ修正・本番デプロイまで全部AIに指示して通せる。自分の役割は「何を作るか」「何を直すか」を判断することだけ
• 「自分でコードを書く」より「自分が当事者である」のほうが強い：実装の細部はAIに任せ、自分は当事者として全体を見る。書かない側に振り切るメリットのほうが大きい
• 数字（PV / 登録数 / MRR）は別記事で公開する：今回は技術選定の記録に絞る

結び — 制約・当事者性・AIが揃った時

期限は設けなかったが、当事者性が続くうちにリリースしたかったから、コアを固定する判断が研ぎ澄まされた。倒れた経験は当事者性として残った。AIが実装を引き受けたから、自分でコードを書かずに設計と判断に集中できた。この3つが揃った時、プログラマーが本職でなくても月額SaaSは結果として7日で出せる。

西川製作所として書くことの意味は、作り手の手の内を見せていくことにある。何を選び、何を捨て、何をAIに任せ、なぜ7日で出せたか。次は数字、その次は技術の詳解。月1本のペースで積む。

関連リンク

• note 当事者連載：「LDL142を放置した父が、保育園の廊下で倒れるまで」 — 同じ題材を物語側から書いた版
• 低コレ食堂（プロダクト本体）：https://teikore-shokudo.com
• 同様のWebアプリ開発をご検討の方はお問い合わせからどうぞ