開発の流れ
Webサービスを公開するまでの流れ｜データとログインが入ると工程はどう増えるか
このページの結論
工程は5つです。審査がないので自分の判断で出せます。Webページとの差は、データの置き場所とログインを決める工程が入ることと、公開の前に「他人のデータが読めない状態か」を確かめる工程が加わることです。
Webページとの違いは、預かるものがあること
読んでもらうだけのページなら、置いてあるファイルを返すだけで成り立ちます。 Webサービスは、使う人が入力した内容を保存し、次に来たときにその人にだけ返します。 ここに、2つの仕組みが要ります。
工程が増える理由は、ほぼこの2つに集約されます。 逆に言えば、保存するものがなく、ログインも要らないなら、 Webページ・ブログの流れと同じ工程で出せます。
公開までの全体の流れ
- 01 何ができるサービスか決める 誰の何が済むのか
- 02 手元で動かす まだ自分だけが使える
- 03 データの置き場所を決める 保存とログインを預ける先
- 04 公開する URLを配れば誰でも使える
- 05 使う人が増えたら見直す 費用と負荷が動く
Webページとの差は3つ目の工程です。ここで決めた先が、その後の費用の増え方も決めます。
順番で迷いやすいのが、2つ目と3つ目です。 データの置き場所を先に契約してから作り始める人が多いのですが、 先に手元で動く形を作った方が、何を保存したいのかがはっきりします。 保存する項目が決まっていない状態でデータベースを設計すると、あとで作り直しになります。
工程ごとに何を決めるか
何ができるサービスか決める
誰の、どんな用事が済むのかを1行にします。ここで「保存するものは何か」と「ログインが要るか」まで書き出しておくと、3つ目の工程で迷いません。
迷いやすいところ: 機能を並べ始めると終わりません。最初に出す版で残す機能を1つに絞ると、公開までの距離が短くなります。
手元で動かす
自分のパソコンの中で、一連の操作が通るところまで作ります。この段階では保存先を仮のもので済ませても構いません。
迷いやすいところ: 保存する項目は、ここで動かしてから確定させます。先に決めきると、作り直しになりやすい部分です。
データの置き場所を決める
保存の場所と、ログインの仕組みをどこに任せるかを決めます。この2つをまとめて借りられるサービスがあり、その場合は契約が1つで済みます。
迷いやすいところ: 誰がどのデータを読めるかの制限を、この工程の中で設定します。あとで足す作業になると、設定漏れに気づきにくくなります。
公開する
コードを公開先へ送ると、URLが割り当てられて誰でも使える状態になります。審査を待つ相手はいません。
迷いやすいところ: 公開する前に、ログインしていない状態と、別のアカウントでログインした状態の両方で開いて、他人のデータが見えないことを確かめます。
使う人が増えたら見直す
人が増えると、保存量と通信量が増え、無料枠の範囲を超えることがあります。どの数値が上限に近いかを見る場所が、契約したサービスの管理画面にあります。
迷いやすいところ: 料金は使った量で変わる形が多いため、上限に達したときに止まるのか、そのまま課金されるのかを、契約前に料金ページで確認します。
判断点1: データとログインをどこに任せるか
保存の場所と、ログインの仕組みは、別々に用意することもできますし、 まとめて借りることもできます。個人で作る場合は、まとめて借りる形が工程を減らします。 テーブル (保存したいものごとに作る表)を作り、 どのアプリから読み書きするかを繋ぐところまでが、この工程です。
手順の実際はSupabaseのページにまとめています。 アプリの土台に何を使っているか( フレームワーク )によって繋ぎ方が変わるので、 そこは開発を頼んでいるAIに聞くと早い部分です。
判断点2: 公開の場所をどちらにするか
公開の場所は、送れば公開まで引き受けてくれる形と、 自分でサーバーを1台借りて管理する形に分かれます。 どちらを選ぶかで、4つ目の工程の中身が変わります。
| 任せる(ホスティング) | 自分で管理する(VPS) | |
|---|---|---|
| 公開の工程 | コードを送ると、変換から配置まで自動で進む | サーバーを借り、動かす環境を自分で用意する |
| 設定の範囲 | 決められた範囲の中で設定する | 中身をほぼ自由に決められる |
| 費用の形 | 無料の範囲から始められる | 契約した時点から月ごとの費用がかかる |
| 止まったとき | サービス側の記録を見て原因をたどる | 自分で入って原因を調べ、復旧させる |
| 向いている場合 | 最初の1本。手を動かす先を作る側に寄せたい場合 | 任せる形では実現できない要件がある場合 |
「任せる」の側の流れはVercelのページに、 「自分で管理する」の側の流れはConoHa VPSのページにあります。 デプロイ (公開先に配置して使える状態にすること)を自動にしておくと、 直すたびの作業が「コードを送る」だけになります。
公開の前に確かめる: 誰がどのデータを読めるか
ここは、工程の中で最も落としやすく、落としたときの影響が大きい部分です。 データベースは、設定しなければ「置いてあるものを求められたとおりに返す」動きをします。 つまり、行ごとの制限をかけないまま公開すると、 ログインした誰もが他人の保存した内容を読める状態になり得ます。
この制限のことを RLS (行ごとのアクセス制限)と呼びます。 テーブルを作った直後に設定し、公開の前に、 別のアカウントでログインして他人のデータが出てこないことを実際に確かめます。 画面上は自分のデータしか出ていなくても、制限が入っていないことがあります。 設定の場所と確かめ方はSupabaseのページにあります。
工程の途中で出てくる、そのほかの判断点
サービスの内容によって、要る場合と要らない場合がある判断点です。 要らないなら工程を増やさずに済みます。
- メールを送るかどうか ― パスワードの再設定や、登録の確認、通知を出すなら、送信の仕組みが要ります。 自分で用意すると届かない問題に時間を取られるため、 メール送信API に任せる形が現実的です。設定はResendのページにあります。
- コードの置き場所と、公開の自動化 ― コードを リポジトリ に置いておくと、変更の履歴が残り、 おかしくなったときに前の状態へ戻せます。公開先と繋いでおけば、 送るたびに ビルド と公開が自動で走ります。 流れはGitHubのページにまとめています。
- お金を受け取るかどうか ― 月額課金や買い切りにする場合は、決済を扱う工程が加わります。 自分が売り手になるため、表示の義務も生じます。 Stripeと特定商取引法の表示を参照してください。
公開したあと ― 使われ方を見て直す
5つ目の工程は、公開したあとにずっと続きます。 見るのは2つで、使われ方と、費用です。
使われ方は アクセス解析 で記録します。 Webサービスの場合は、来た人数より「登録まで進んだ人がどこで止まったか」の方が手がかりになります。 入れ方はPostHogのページにあります。
費用は、無料枠から始められますが、使う人が増えると増えます。 増え方が読みにくいと感じたら、収益とコストの関係に整理してあります。
よくある質問
データベースは、作り始める前に決めておくものですか？
先に手元で動かしてから決める方が、保存する項目が具体的になります。項目が固まらないうちに作り込むと、作り直しになりやすい部分です。
ログインの仕組みは、自分で作った方がいいですか？
パスワードの保管や再設定まで自分で引き受けることになるため、個人で作る範囲では任せる形が選ばれることが多いです。データの保存とまとめて借りられるサービスがあります。
アクセス制限は、あとから設定してもいいですか？
公開の前に済ませる工程です。制限がないまま公開すると、他人の保存した内容が読める状態になり得ます。テーブルを作った直後に設定し、別のアカウントで確かめます。
無料枠を超えたら、いきなり請求が来ますか？
超えた分が課金される形と、そこで動きが止まる形があり、サービスによって違います。契約する前に、料金のページでどちらなのかを確認します。
公開したあとに大きく作り変えても大丈夫ですか？
アプリの側は差し替えられます。ただし保存済みのデータの形を変える場合は、すでに入っているデータをどう扱うかを決める必要があります。
次に読むページ
- 開発の流れ 形ごとの工程の入口。ほかの形と見比べる場合はこちら
- Webページ・ブログの流れ 保存もログインも要らない場合の、工程が最も少ない形
- 便利ツール・拡張機能の流れ 配る場所によって、審査の有無が変わる形
- 個人開発で何が作れるのか 形ごとの費用と審査の違いを、7つ並べて比べる
出典
- 行ごとのアクセス制限の考え方: Supabase Docs「Row Level Security」
- ログインの仕組みを借りる形: Supabase Docs「Auth」
- コードを送ると公開まで進む仕組み: Vercel Docs「Getting Started with Vercel」
- コードの置き場所と変更の履歴: GitHub Docs「リポジトリについて」
- アプリからのメール送信: Resend Docs「Introduction」