Claude Code Media
無料で試す
連載 3/3この記事は「非エンジニア向け」シリーズの第 3 回 / 全 3 本シリーズ全体を見る →
15分4,066字初級

非エンジニアが Vibe Coding で 24 時間アプリを作る完全手順【2026年5月版】

自社の業務アプリを 24 時間以内に作る「Vibe Coding」の実装ガイド。Claude Code + Lovable + Supabase を組み合わせ、要件整理 → 画面試作 → DB 設計 → デプロイまでを非エンジニアが進める手順を、所要時間の目安・つまずきポイント・公開先まで全工程解説。実作業は約 12 時間 + 翌日の運用テストを想定したサンプルシナリオです。

By Claude Code Media 編集部Reviewed by Claude Code Media 編集部

「自社の業務アプリ、外注すると 200 万・3 ヶ月。でも要件は自分が一番よく分かっている」— そんな状況の非エンジニアこそ、Vibe Coding で 24 時間以内に動くものを作れる時代になりました。本稿は、この手順で作れる社内ツールの サンプルシナリオを題材に、要件整理からデプロイまでの工程とつまずきポイントを 「コピペできる手順書」 として解説します。

完成イメージ（この記事で作るもの）

「社員向けの経費精算 申請フォーム」を例にします。要件:

  • 社員が金額・摘要・領収書画像をアップロード
  • 経理担当がブラウザで承認ボタンを押す
  • 承認されたものは freee の API で自動仕訳起票

これを 自分でコードを書く部分を最小限にして 24 時間以内に公開する流れを解説します。なお「コードを書かない」とはいえ、工程 4・5 では ターミナルで Claude Code を操作します（コマンドのコピペが中心で、プログラミング自体は不要です）。

全工程と所要時間（目安）

以下はサンプルシナリオでの 所要時間の目安です。実際の時間は要件の複雑さや習熟度により変動します。

工程所要（目安）ツール
1. 要件を Claude と整理2 時間Claude Code（or 公式チャット）
2. UI を Lovable で試作3 時間Lovable
3. DB を Supabase で構築2 時間Supabase
4. ロジックを Claude Code で実装4 時間Claude Code（ターミナル操作）
5. Vercel にデプロイ1 時間Vercel（ターミナル / ブラウザ）
6. 1 日運用テスト翌日（待機中心）—

実作業時間は 合計約 12 時間。これに翌日の運用テストを加えて、全体で 24 時間以内に収める想定です。

⚠️ Vibe Coding の限界（先に明示）

「全部を任せてはいけない」3 点:

  1. 個人情報・決済を扱うアプリは推奨しない — 生成コードのセキュリティ監査ができないため。社内向け or 軽量 SaaS まで。
  2. 大規模スケール（1 万 MAU 以上）は専門家に再設計依頼 — 速さ優先で書かれるため、性能・障害耐性が弱い。
  3. 生成コードのコピーライト・依存ライセンス — Claude / Lovable の出力が含む npm パッケージのライセンス確認は人間の責任。

詳しくは Vibe Coding とは？2026 年の開発革命を 5 分で完全理解 を参照。

工程 1: 要件を Claude と整理（2 時間）

やること

  1. 自分の頭の中の「やりたいこと」を Claude に話す
  2. 「具体的な仕様書」に変換してもらう
  3. 不明点を Claude が質問してくる → 答える
  4. 仕様書を Markdown で保存

Claude へのプロンプト例

私は非エンジニアです。社内の経費精算アプリを 24 時間以内に作りたいです。
以下を整理した「要件定義書」を作ってください。

- 誰が使うか: 社員 12 名 + 経理 1 名
- 何ができるか: 社員が金額・摘要・領収書画像を提出 → 経理が承認 → freee に仕訳起票
- どのデバイスで使うか: 主にスマホ（社員）/ PC（経理）
- 必要なログイン: あり（社員の Google アカウント）
- データ保管: 領収書画像は原則 7 年保管（電子帳簿保存法。要件により最長 10 年。詳細は税理士・国税庁資料で確認）

不明点があれば 1 個ずつ質問してください。私が答えた後で要件定義書を完成させてください。

つまずきポイント

  • Claude は **「全部を 1 度に聞かない」**と良い質問を返してくる。逆に「何を聞けばいいか分からない」状態でも、「とりあえずやりたいことを話して」で OK。
  • 仕様書ができたら必ず人間が読み返す。**「これって本当に欲しい？」「これって法律的に大丈夫？」**の 2 軸で疑う。

成果物

  • docs/requirements.md（要件定義書、1,500 字程度）

工程 2: UI を Lovable で試作（3 時間）

やること

  1. lovable.dev でアカウント作成（メールアドレスだけで OK）
  2. 「New Project」→ 工程 1 の要件定義書をそのまま貼り付け
  3. Lovable が自動で画面を生成する（React + Tailwind で）
  4. プレビューで気になる箇所を「ここをこうして」と日本語で修正依頼
  5. 完成したら GitHub にエクスポート

Lovable への初回プロンプト例

社内向けの経費精算アプリを作ってください。

【画面構成】
- /login: Google 認証
- /submit: 社員が経費を提出（金額・摘要・領収書画像アップロード）
- /admin: 経理が一覧 + 承認ボタン
- /history: 自分の過去提出一覧

【デザイン】
- 落ち着いた配色（白 + ネイビー + アクセントに青）
- スマホ最優先（社員はスマホ提出）
- 日本語 UI

【データ】
仮データで動くようにしてください。バックエンドは後で接続します。

つまずきポイント

  • Lovable は最初の生成で 80% できるが、ピクセル単位の調整は不得意。**「ヘッダーをもっと薄く」「ボタンを大きく」**くらいの粒度で指示する。
  • 細かい修正は 1 回 1 修正にする。10 個まとめて頼むと混乱して全部壊れがち。

成果物

  • Lovable プロジェクト + GitHub リポジトリ（フロントエンドのコード自動生成済）

工程 3: DB を Supabase で構築（2 時間）

やること

  1. supabase.com でアカウント作成（GitHub 認証可）
  2. 「New Project」を作成（東京リージョン推奨、Free プランで OK）
  3. テーブルを「Table Editor」で 3 つ作る
    • expenses: 経費申請データ
    • users: 社員データ
    • receipts: 領収書画像メタ
  4. 「Storage」でバケット receipts を作成（プライベート）
  5. 「Authentication」で Google プロバイダを有効化

テーブル作成プロンプト（Claude Code に頼む）

Supabase で以下 3 テーブルの SQL を作って。
私は Supabase ダッシュボードの SQL Editor で実行します。

【expenses】
- id (uuid, pk)
- user_id (uuid, fk → auth.users)
- amount (int) -- 金額（円）
- description (text)
- receipt_path (text) -- storage パス
- status (text, default 'pending') -- pending/approved/rejected
- approved_by (uuid, fk → auth.users, nullable)
- approved_at (timestamptz, nullable)
- created_at (timestamptz, default now())

RLS は:
- 社員は自分の行だけ insert / select 可
- 経理（role='accounting'）は全 select / update 可

【users】
auth.users と紐付ける profiles テーブル。
- id (uuid, pk, fk → auth.users)
- display_name (text)
- email (text)
- role (text, default 'employee') -- employee / accounting / admin

【receipts は不要】
storage で済むので削除。

つまずきポイント

  • RLS（Row Level Security）は必ず有効化。OFF だと社員が他人の申請を見えてしまう。
  • Supabase Free プランは 500MB DB / 1GB storage まで。社員 12 名なら十分。

成果物

  • Supabase プロジェクト + 環境変数 NEXT_PUBLIC_SUPABASE_URL / NEXT_PUBLIC_SUPABASE_ANON_KEY

工程 4: ロジックを Claude Code で実装（4 時間）

やること

  1. 工程 2 で出力された GitHub リポジトリをローカルに clone
  2. ターミナルでそのフォルダに入って claude を起動
  3. /init で CLAUDE.md を生成
  4. Claude に「Supabase を接続して経費提出を保存できるようにして」と依頼

Claude Code へのプロンプト

このリポジトリは Lovable で生成された React + Vite アプリ。
仮データで動いている状態。これに以下を実装してください。

1. Supabase クライアントを @supabase/supabase-js で導入
2. /submit ページのフォーム送信を Supabase の expenses テーブルに insert
3. 領収書画像は Supabase Storage の receipts バケットにアップロード
4. /admin ページで status='pending' の expenses を一覧表示、承認ボタンで status='approved' に更新
5. /history で自分（auth.uid）が提出した過去 expenses を表示
6. すべてのデータアクセスで RLS を信用（クライアント側でフィルタしない）

環境変数:
- VITE_SUPABASE_URL
- VITE_SUPABASE_ANON_KEY

不明点があれば質問してください。実装が終わったら動作確認手順を 5 ステップで示してください。

つまずきポイント

  • Claude が「エラーが出ました」と言ったら、エラーメッセージをそのまま貼って返す。自分で解読しなくていい。
  • Lovable 生成コードの構造をいじりすぎると Claude が混乱する。「最小限の追加で動かして」と頼む。
  • 4 時間で終わらなければ「ここで切る」判断も大事。完璧を目指さない。

工程 5: Vercel にデプロイ（1 時間）

やること

  1. vercel.com で GitHub 連携、リポジトリを import
  2. 環境変数 2 つ（VITE_SUPABASE_URL / VITE_SUPABASE_ANON_KEY）を Vercel に設定
  3. Deploy ボタンを押す → 数分で公開
  4. 表示された URL（xxx.vercel.app）を社員に共有

つまずきポイント

  • 1 回目のビルドは失敗することが多い。Claude に **「Vercel のビルドログを見て」**と頼んで対応。
  • ドメインは独自取得しなくても OK。社内利用なら xxx.vercel.app のままで十分。

工程 6: 1 日運用テスト（翌日・待機中心）

やること

  • 自分 + 同僚数人で実際に「経費申請 → 承認」を 1 日通して試す
  • バグ・違和感を Notion / メモアプリに書き溜める
  • 翌朝 Claude に「これらの修正を順に対応して」と渡す

運用テストで見つかりやすいバグの例

このタイプのアプリでは、運用テストで以下のような不具合が出やすいので、想定して進めるとスムーズです:

  • 領収書 PDF が表示されない（image only 対応 → PDF プレビュー追加）
  • 金額入力にカンマが効かない（input type 修正）
  • スマホで承認ボタンが画面外（fixed footer に変更）
  • 承認後の通知メールが届かない（Resend 連携追加）
  • 日付フォーマットが英語（ja-JP に固定）
  • サインアウトリンクが見つからない（ヘッダー追加）

この程度の修正であれば、エラー内容を Claude に渡して順に対応させることで、まとめて短時間で潰せることが多いです。

24 時間後にあるもの

  • 動く社内アプリ 1 個（URL 公開済み）
  • 「自分でも作れる」という肌感覚

コストの内訳

サブスク実費と人件費換算を分けて考えると以下のようになります（為替・プランにより変動）。

区分内訳目安
サブスク実費Supabase Free + Vercel Free + Lovable Pro $20 + Claude Code $20約 6,000 円（$40 相当）
人件費換算自分の作業 約 12 時間 ×（自身の時給）時給により変動

サブスク実費だけなら 月 6,000 円程度で、外注（200 万円規模）と比べると桁違いに安く試せます。人件費は「自分の時間をどう評価するか」で大きく変わるため、分けて捉えるのが実態に合います。

これだけあれば、次の業務アプリはより短い時間で作れるようになります。

注意 4 点

1. 個人情報と決済は別ものと考える

経費精算は社員の名前・口座・金額が乗ります。社外秘・個人情報の取り扱い規程を社内で確認してから運用開始。決済を組み込む場合は専門家設計に切り替えること。

2. 法令対応

本記事は監修者（税理士・弁護士等）による法令レビューを経たものではありません。以下は概要であり、適用要件・保存期間は必ず税理士や国税庁・e-Gov 等の一次情報で確認してください。

  • 電子帳簿保存法（電帳法）：領収書画像の保存期間は 原則 7 年（要件により最長 10 年） + 改ざん防止措置 + 検索要件
  • インボイス制度：取引先の登録番号管理
  • 個人情報保護法：社員情報の利用目的 / 保管期間明示

3. バックアップ

Supabase は自動でバックアップを取りますが、月 1 回は pg_dump で手元にも保存。事故時の復旧元として必須。

4. 「全部 AI」にしない

UI / DB / ロジックを AI に任せても、**「これって本当に必要？」**を問えるのは人間だけ。要件定義（工程 1）こそ AI に丸投げしてはいけません。

まとめ

非エンジニアが Vibe Coding で 24 時間アプリを作るのは、ツール選定さえ間違えなければ実現可能な時代です。本稿の工程をそのまま辿れば、プログラミング経験がなくても（ターミナルでのコマンド操作は伴いますが）社内向け業務アプリを 1 つ持てます。

関連記事:

ByClaude Code Media 編集部

AI支援で執筆 — 本記事は Claude Code エージェントによる執筆支援を受け、編集部が事実確認・編集を行っています。 数値・引用元は記事更新日時点で確認済みですが、最新情報は各公式サイトでご確認ください。

Related

続けて読む

すべての記事 →