バイブコーディングしたい個人開発者必見 プロおすすめの作り方【Webアプリ編】
Claude Codeに「会員登録できる予約サービス作って」と頼むと、普通にかなりそれっぽいものができます。
これ、便利なんですけど怖いんですよね。
画面が動いた。登録できた。予約もできた。じゃあ完成かというと、たぶん一番大事なところがまだ残っています。
認証と権限です。
ログインしていない人が管理画面のURLを直接開いたらどうなるのか。他人の予約番号を入れたら見えてしまわないか。別の会社のデータを検索できないか。削除済みのデータを直接指定したらどうなるのか。ログイン画面を何百回も叩かれたらどうするのか。
こういうところまで最初から全部プロンプトに書けるなら、もう普通にかなり開発できます。
いや、そこまで書けるならこの記事いらないな。
なので今回は、Webアプリを個人でバイブコーディングしたい人向けに、自分ならどういう順番で作るかを書きます。
いきなりClaude Codeに作らせる前に、完成条件を作る
最初にやることは、コードを書くことではありません。何ができたら完成なのかを先に決めます。
ただし、立派な仕様書を書く必要はありません。例えば「小さい会社向けの予約システムを作りたい。お客さんが予約できて、店側は管理画面から予約を確認できるようにしたい」くらいで十分です。
これを、まずPM on RailsのAIチャットへ入れます。
PM on Railsは、作りたいものを「何を実現したいか」「誰が何をできるようになりたいか」「どんな利用場面で、どう動けば正しいか」へ分けて管理するために自分たちで作っている開発管理の仕組みです。
マジで宣伝とかじゃなくて、自分が個人開発するならこのやり方にします。
自社で作っているから勧めているのではなく、AIにコードを書かせるなら、この工程を飛ばしていきなり実装へ行く方が危ないと思っているからです。自分たちの開発でも実際に使っています。
要するに、
作りたいもの
↓
利用者がやりたいこと
↓
具体的な利用場面
↓
どうなれば合格か
まで先に作ります。
ここまでできてからClaude Codeへ渡した方が、AIが「なんとなく完成しました」と自分で採点する状態を減らせます。
普通の人が一番抜かしやすいのは「変な使い方」です
Webアプリで怖いのは、普通に使ったときより、普通じゃない使い方をされたときです。
例えば予約サービスなら、「予約できる」だけでは全然足りません。他人の予約番号を直接指定したらどうなるのか。同じ予約ボタンを連打したらどうなるのか。ログアウト後に以前の画面を開いたらどうなるのか。店Aの人が店Bの予約を見られないか。
そんなこと、最初から全部思いつく？
自分は仕事としてこういう異常系や権限境界を洗い出します。でも、個人開発者がWebアプリを一個作るたびに、認証・権限・入力・境界値・失敗時の挙動まで毎回ゼロから全部考えるのは普通にしんどいと思います。
だから、人間の記憶力やプロンプト力へ寄せるより、最初からレビュー観点を仕組みに持たせた方がいい。
PM on Railsでは、普通に成功する場合だけではなく、失敗する場合や境界にある場合も含めて、AIに利用場面を出させます。
実際にPM on Rails自身を作るときにも、「参加していない案件の番号を直接指定しても中身を取得できない」だけでは終わらせていません。その案件が存在すること自体を推測できない。検索結果の件数にも出ない。AIへ質問しても漏れない。関連情報をたどっても漏れない。そこまで確認対象にしています。
これを毎回人間がゼロから思い出すのではなく、先にレビューする仕組みへ寄せる。
プロンプト職人になるより、こっちの方が自然な気がします。
PM on Railsを使いたくないなら、GitHub Issuesで同じことをやればいい
別にPM on Railsを使わないと、この作り方ができないわけではありません。
使いたくなければ、GitHub Issuesでもできます。
「何を実現したいか」をIssueに書く。その下に「誰が何をできるようになりたいか」を書く。さらに、正常に動く場合だけではなく、失敗する場合や境界にある場合まで、具体的な利用場面を書いてClaude Codeに渡す。
この「前提・もし・ならば」で利用場面を書く方法は、別の記事で具体例までまとめています。
Gherkin入門｜「前提・もし・ならば」をどう書けばいいか、具体例で解説
これを読んで、「なるほど、自分でIssueに毎回これを書けばいいのね」と思ったなら、それで全然いいです。
逆に、
いや、毎回これ自分でやるの普通に面倒だな。
と思ったら、素直にPM on Railsを使っておけばいいと思います。
自分がPM on Railsを勧めている理由もそこです。魔法のAIだからではなく、この面倒だけど重要な工程を毎回ちゃんと通すための道具として普通に便利だからです。
仕様ができたら、Claude CodeをPM on Railsにつなぐ
完成条件ができたら、そこで初めてClaude Codeに実装させます。
PM on RailsはClaude Codeなどの開発AIから接続できるので、「この作業を進めて」と渡したときに、作業カードだけではなく、その機能をなぜ作るのか、利用者は何をしたいのか、どう動けば正しいのかまで一緒に見られるようにしています。
最近はさらに、過去にその周辺で起きた不具合や、以前試してうまくいかなかった実装方法まで、着手時の情報として返すようにしています。
AIが賢くなることも大事です。でも、同じ失敗を毎回まっさらな状態から再発明しない方が普通に効きます。
AIにも黒歴史は読ませた方がいい。
人間も同じです。
初心者ほど、Honoで最安構成を狙わない方がいい
Webアプリを安く動かすだけなら、Cloudflare Workersの上でHonoのような軽い仕組みを使う方法はかなり良いです。
経験のあるエンジニアなら、自分も普通に使います。安いし速いし、自由度も高い。
でも、バイブコーディング初心者にはあまり勧めません。
軽い仕組みは、面倒を見てくれる範囲も薄い。
認証をどう組むか。権限をどこで確認するか。入力値をどこで弾くか。データをどう保存するか。失敗時にどう戻すか。自由度が高い分、自分で決める場所が増えます。
経験者には自由です。初心者には穴です。
なので、多少構成が重くても、最初はLaravelのようなフルスタックのフレームワークを使った方がいいと思っています。
Laravelには、認証、入力確認、データ操作、権限判定などについて、長年使われてきた普通のやり方があります。AIへ自由研究をさせる範囲を減らせます。
初心者は自由を減らした方が安全です。
Firebaseも、初心者のバイブコーディングでは自分なら使わない
Firebaseも簡単にアプリを作れるサービスとしてよく候補に入りますが、初心者がバイブコーディングするなら、自分は勧めません。
Firebase自体が危険なサービスという意味ではありません。むしろ初期状態ではデータへのアクセスを拒否する安全側の設定も用意されています。
問題は、その後です。
実際のアプリでは、「ログインした人なら見ていい」「自分のデータだけ見ていい」「管理者だけ変更していい」のような細かい公開範囲を、Firebase側の専用ルールでも設計する必要があります。
公式ドキュメントでも、開発中に全員へ読み書きを許可する設定を本番へ持っていくと、データを盗まれたり変更・削除されたりする危険があると明記されています。また「ログインしている人なら許可」という条件だけでも、ログイン済みの全員へ広く権限を渡す設定になり得ます。
さらに、サーバー側から接続する方法によっては、その専用ルールを通らず、別の権限管理が必要になります。
いや、初心者に覚えさせるもの増えてない？
Webアプリを一つ作りたいだけなのに、安全性の正解がアプリ側とFirebase側へ分かれると、AIが片方だけ直して「安全です」と言う余地も増えます。
だからこの記事では、初心者はFirebaseを使わず、Laravel側で認証・権限・入力確認をできるだけ一つの開発規約へ寄せることを勧めます。
Laravelも、素の状態ではなくAI向けの雛形から作らせる
Laravelを選べば終わりかというと、もちろんそんなことはありません。
AIは正しい書き方もできますが、変な書き方もものすごい速度でできます。
速度だけは平等です。
なので、うちではLaravelとReactを組み合わせたDockerの雛形を公開しています。この雛形には、単にアプリを起動するためのファイルだけではなく、Claude Codeが守る開発ルールも入れています。
例えば、入力確認をどこで行うか、データを画面へどう渡すか、コードをどこへ置くか、どんな自動検査を通すか、画面をまたぐ動作をどうテストするか、といったルールです。
つまり、「好きに建てて」ではなく、先に建築基準を渡してから作らせます。
個人開発でも、この差はかなり大きいと思っています。
BeekleのLaravel + React Docker Template
このテンプレは自分たちの開発でも使うので、俺が死なない限りはメンテします。
公開して終わりではなく、Laravelや周辺ツールの更新、AI向けの開発ルール、自動検査まわりも、自分たちで使いながら直していくつもりです。
公開先はCloudflare Containersで十分だと思う
LaravelをDockerで作ったら、公開先はCloudflare Containersがかなり使いやすい候補です。
Cloudflare Containersは、月額最低5ドルのWorkers有料プランに一定の利用枠が含まれていて、コンテナが実際に動いている時間に応じて課金されます。アクセスがないときは停止させられるので、小さい個人開発ならかなり小さく始められます。
純粋な安さだけならHonoとCloudflare Workersの方が下げやすいです。でも、月数ドルを削るために認証や権限の設計まで難しくするなら、自分はLaravelを取ります。
サーバー代を削って、個人情報を配るサービスになったら意味がない。
Cloudflare側では、大量アクセスによる攻撃への対策が全プランで自動提供されています。Webへの典型的な攻撃を弾くルールもあり、ログイン画面などへのアクセス回数を制限する仕組みも設定できます。
もちろん、Cloudflareを使えばアプリ側の権限設計が不要になるわけではありません。他人のデータを見せない、入力を確認する、管理者だけに操作を許可するといった部分はLaravel側で守ります。
外から来る攻撃への防御はCloudflareへ寄せ、アプリ内部の認証・権限はLaravelへ寄せる。何を守るかはPM on Railsで先に確認する。この分担がかなり分かりやすいです。
結局、自分ならこの順番で作る
個人でWebアプリをバイブコーディングするなら、自分なら次の順番にします。
- PM on RailsのAIチャットに、作りたいものを普通の日本語で書く
- 何を実現したいか、利用者が何をしたいか、具体的な利用場面を生成する
- 認証・権限・失敗時・境界条件など、抜けている観点をAIにレビューさせる
- Claude CodeをPM on Railsへ接続して、完成条件ごと実装させる
- Laravelの雛形から作らせ、コードの置き方や自動検査を自由にさせすぎない
- Cloudflare Containersへ公開する
- Cloudflare側で大量アクセス対策、Web攻撃対策、アクセス回数制限を設定する
- 公開後も、作った利用場面どおりに動くか自動テストを残す
逆に、経験が十分あるならHonoとCloudflare Workersでさらに薄く、安く作ればいいと思います。
でも、初心者が最初から最安構成を目指す必要はないです。
AIでコードを書くコストは下がりました。
その分、これから大事になるのは、「何を作れば正しいか」と「何をやったら危ないか」を先に決めることなんだと思います。
プロンプトを上手に書ける人だけが安全に作れる状態にするより、最初からレビュー観点と開発ルールを仕組みに入れておく。
AIが速くなっても、事故まで速くしない。
PM on Railsは、そこをやりたくて作っています。