月間10万PVで直面した個人開発から「サービス運用」への転換点

10万PVは、すべての個人開発者が高価な構成へ移行すべき数字ではない。重要なのはPVの絶対数ではなく、自分のサービスを止めたときに誰が困るのか、そして障害をどれだけ早く発見して復旧できるのかだ。

自分だけが使うアプリなら、数時間止まっても再起動すれば済むかもしれない。ところが、検索やSNS経由で継続的にユーザーが訪れ、データを保存し、通知や決済を待っているなら、それはもう単なる開発物ではない。規模が小さくても、利用者から見ればサービスである。

個人開発からサービス運用への移行タイミングは、売上やユーザー数だけでは決まらない。無料枠の上限、障害に気づくまでの時間、データを失った場合の復旧手段、毎月負担できる費用と作業量。この複数の境界線が重なったとき、趣味の開発はサービス運用へ変わる。

月間10万PVが突きつける「趣味」と「サービス」の境界線

個人でアプリやWebサービスを始めたばかりの時期は、ほとんどの場合「趣味」の領域にある。VercelやSupabase、Cloudflareなどの無料枠を組み合わせ、月数千PV程度のサイトをほぼ費用なしで動かす。ドメイン代さえ惜しいと感じながら、機能を追加していくフェーズだ。

この段階では、構成が多少いびつでも大きな問題にはなりにくい。LaravelのアプリをDockerで動かし、ローカル環境と本番環境の差分を完全には吸収できていなくても、利用者が自分だけなら困るのは自分である。WordPressにプラグインを追加しすぎて管理画面が重くなっても、必要なときに待てばよい。

障害通知がなくても、使おうとしたときに落ちていれば気づける。バックアップを取っていなくても、失うデータが自分のメモや試作データだけなら、作り直すという判断もできる。

しかし、アクセスが増えると、この「自分だけが困る」という前提が崩れる。

無料プランの仕様は、サービスごとに異なる。データベース容量、転送量、ストレージ、関数の実行回数、ビルド時間、同時接続数など、別々の項目に上限が設定されている。無料枠の数字だけを横並びにして、「このアクセス数なら大丈夫」と判断するのは危険だ。プラン内容や上限は変更されることもあるため、導入時とアクセスが増えた時点で、各サービスの公式料金表と利用状況を確認する必要がある。

PVは、ページが表示された回数にすぎない。1PVの裏側で画像を複数読み込み、APIを呼び、アクセス解析や広告スクリプトを実行していることがある。記事を一つ読んでいるだけに見えても、インフラ側では複数のリクエストが同時に発生している。

検索画面や絞り込み機能を持つサービスなら、1回の画面表示でデータベースへの問い合わせが何度も走ることもある。ログイン後の画面では、ユーザー情報、通知、履歴、権限、集計データをそれぞれ取得しているかもしれない。PVだけを見ていると、実際の負荷を見誤る。

ここで、趣味とサービスの違いを整理してみる。

• 趣味は、落ちても自分が困るだけなら、都合のよい時間に再起動できる。
• サービスは、利用者が困る可能性があるため、障害を発見する仕組みが必要になる。
• 趣味では、データベースのバックアップを後回しにできる。
• サービスでは、バックアップの取得だけでなく、復旧できるかどうかまで考える必要がある。
• 趣味では、新機能を作った時間がそのまま成果になる。
• サービスでは、新機能が監視対象、問い合わせ、権限管理、障害原因を増やすことがある。
• 趣味では、開発者の記憶が運用手順になる。
• サービスでは、別の日の自分でも復旧できるように、手順を外へ出しておく必要がある。

月間10万PVは、無料枠の数字だけで判断できる規模ではない。アクセスの裏側にあるリクエストと、止まったときの影響を見始める地点だ。

10万PVは1日あたりではなく、1か月あたりの数字である。それでも、構成の弱い部分が少しずつ表面化するには十分な規模だ。特に、画像の配信、動的なページ生成、データベースへの問い合わせ、外部APIの呼び出しが多いサービスでは、PVより早く別の上限に届くことがある。

WordPressで先に見直すべき場所

WordPressで運用している場合、プラグインが増えるほど、1リクエストあたりの処理は複雑になる。すべてのプラグインが常に問題を起こすわけではないが、管理画面、記事表示、検索、画像処理、定期実行のどこに負荷がかかっているのかは確認したい。

キャッシュなしで動的な処理を繰り返していると、アクセスが増えたときにCPUやメモリを消費する。管理画面の処理と閲覧者向けの処理が同じサーバー上で動いている場合、記事更新やバックアップの時間帯とアクセス集中が重なるだけで、サイト全体が不安定になることもある。

対策は、単純にサーバーのスペックを上げることではない。

• ページキャッシュをどこで持つか決める。
• 未ログインユーザー向けのページをできるだけ静的に配信する。
• 画像をアプリケーションサーバーから切り離す。
• 管理画面や検索など、キャッシュできない処理を特定する。
• プラグインの定期処理がどのタイミングで動くか確認する。
• バックアップ処理が本番の応答性能に影響しないようにする。

WordPressは導入しやすい一方で、機能を足すほど処理の経路が見えにくくなる。重くなってからプラグインを一つずつ疑うより、キャッシュ、画像、検索、管理画面の役割を先に分けた方が、運用は安定しやすい。

LaravelとDockerで見落としやすい運用負荷

LaravelでAPIベースのサービスを作っている場合は、データベースの問い合わせ方が負荷の中心になることがある。開発中は数件のデータしか扱わないため、N+1クエリが残っていても気づきにくい。しかし、ユーザーや履歴が増えると、一覧画面を開くだけで同じ種類のクエリが大量に発生する。

アプリケーションサーバーのCPUを増やしても、データベースへの問い合わせが非効率なままなら、負荷の場所が移動するだけだ。取得する列を絞る、ページネーションを入れる、適切なインデックスを検討する、同じ集計結果を短時間キャッシュする。こうした地味な改善が、サービス運用では効いてくる。

Dockerも同じである。開発環境をそろえるには便利だが、Dockerを使っていること自体が運用の自動化を意味するわけではない。

コンテナが落ちたときに再起動するのか。ログはどこに残るのか。イメージを更新した後、問題が起きたら前のバージョンへ戻せるのか。ディスクがログで埋まったらどうなるのか。データベースのコンテナを誤って削除した場合、どこから復旧するのか。

そこまで決めて初めて、Dockerはサービスを支える道具になる。コンテナを分けただけでは、障害の影響範囲は分離されない。一台のVPSにすべてを載せているなら、基盤そのものが停止したとき、アプリケーション、キュー、データベース、バッチ処理が同時に影響を受ける。

インフラコストの罠：広告収益とサーバー維持費の収支バランス

個人開発のマネタイズ手段として、最初に広告を検討する人は多い。広告は決済機能や顧客対応を用意しなくても始めやすく、アクセスが積み上がれば収益が発生する。個人開発との相性がよい方法であることは確かだ。

ただし、広告収益が出た時点で、サービスが完全な趣味ではなくなるわけでもない。広告を表示するためにユーザーのアクセスを受け取り、その対価として収益を得ている以上、規模が小さくても運用上の責任は少しずつ発生する。

広告収益は、PVに比例して単純に増えるものではない。ジャンル、ユーザーの地域、広告の表示位置、画面構成、季節、広告単価などによって変動する。月間10万PVなら必ず一定額になる、といった見方はできない。

一方、インフラ費用もPVだけでは決まらない。画像の比率が高いサイト、検索や絞り込みを多用するサービス、ログイン後の動的ページが多いサービスでは、PVが少なくてもサーバーやデータベースの負荷が大きくなる。

広告収益と費用には、増え方の時間差もある。アクセスが急増した場合、広告収益への反映がすぐに同じ割合で進むとは限らない。しかし、転送量や外部サービスの利用量は、アクセスの増加に合わせて先に膨らむことがある。収益が確定する前に、請求だけが増える可能性があるということだ。

料金表ではなく、課金の発生条件を見る

Vercel、Supabase、Cloudflare、AWSなどを使う場合、無料プランや有料プランの金額だけを見るのでは足りない。無料枠を超えた場合に停止するのか、自動的に従量課金が発生するのか、追加利用の単価は何か、どの項目が請求に影響するのかを確認する必要がある。

Supabaseのようなサービスでも、データベース容量だけでなく、帯域、ストレージ、コンピュート、関数など、項目ごとに条件が分かれている。単一の「リクエスト上限」として考えると、実際の料金体系から離れてしまう。

Vercelも同様に、帯域だけを見て構成の安全性を判断することはできない。静的ファイルの配信量、画像最適化、関数の実行、ビルド、ログなど、使っている機能によって確認すべき項目が変わる。各サービスの現行仕様を確認し、自分の利用量を項目別に分解して見る方が正確だ。

PlanetScaleやNeonなどのデータベースサービスも、無料で使えることを前提に選ぶべきではない。料金体系や無料利用の条件はサービスごとに異なり、変更されることもある。無料枠があるかどうかではなく、無料枠が終了した後の移行先と費用まで見ておく必要がある。

収支は「平常時」と「悪い月」を分けて考える

サービスの収支を見るときは、平常時の広告収益と月額費用を並べるだけでは不十分だ。アクセスが急増した場合、画像やログが増えた場合、外部APIを多く呼び出した場合、障害対応が発生した場合を別々に考えたい。

「月間10万PVなら月にいくら儲かる」と決め打ちするより、収益と費用の幅を持たせる方が現実的だ。特に、広告収益のように外部要因で変動するものは、最高月の数字ではなく、低い月でも維持できるかを見る。

確認したいのは、単純な売上と費用の差額だけではない。

• アクセスが一時的に増えた場合、どの項目の費用が膨らむのか。
• 無料枠を超えたとき、自動的に課金へ移行するのか。
• 画像やログの保存量が増え続ける構成になっていないか。
• 収益がほとんどない月でも、一定期間は維持できるか。
• 自分の作業時間を含めたとき、継続する価値があるか。
• 解約やサービス停止を決めた場合、データを取り出せるか。

「儲かっているか」ではなく、「悪い月でも壊れないか」を見る。個人開発でサービス化に踏み切る基準は、最高月の売上ではなく、最低月の収益と、最大時に発生しうる費用を並べたときに見えてくる。

常時起動からサーバーレスへ：コストを抑える構成変更の考え方

個人開発では、最初にVPSを一台借り、そこへアプリケーション、データベース、画像、バッチ処理をまとめる構成が分かりやすい。常時起動しているため、アクセスが少ない時間帯も一定の費用は発生するが、仕組みを理解しやすく、LaravelやWordPressをそのまま動かしやすい。

問題は、アクセスが増えたときに、すべての処理を同じ場所で受け止めようとすることだ。

• VPSを常時起動し、アプリケーションとデータベースを動かす。
• 画像やJavaScriptも同じサーバーから配信する。
• Dockerで役割を分けているが、監視や自動復旧は用意していない。
• 障害が起きても、ユーザーから連絡が来るまで気づかない。

この構成では、画像配信が帯域を消費し、画像変換がCPUを使い、ログがディスクを圧迫する。その影響でAPIの応答が遅くなり、データベースのバックアップまで失敗する可能性がある。コンテナを分けていても、同じサーバーのリソースを共有していれば、負荷の影響は完全には分離できない。

移行を考えるときは、まず処理を性質ごとに分ける。

• 静的なページやフロントエンドは、エッジ配信へ移す。
• 画像やファイルは、アプリケーションサーバーとは別のストレージから配信する。
• 認証、データ登録、権限確認など、動的な処理だけをAPIへ残す。
• 重い処理や定期処理は、画面表示のリクエストから切り離す。
• 多少古くてもよい集計結果は、短時間キャッシュする。
• 常に動いている必要のない処理は、実行時だけ動かす構成を検討する。

フロントエンドをVercelやCloudflare Pagesへ移し、画像をオブジェクトストレージへ移し、バックエンドの一部をAWS Lambdaなどのサーバーレスへ切り出す。こうした分離によって、アクセスの波がそのまま一台のVPSへ集中する状態を避けられる。

ただし、「サーバーレスにすれば必ず安くなる」という話ではない。サーバーレスは、アクセスが少ない時間帯に常時起動の費用を抑えやすい一方、呼び出し回数、実行時間、メモリ、データ転送などの従量課金が発生する。設計を誤ると、便利なサービスを組み合わせた分だけ請求箇所が増える。

データベースへの接続も注意が必要だ。関数が呼ばれるたびに新しい接続を作ると、関数の実行数より先にデータベースの接続数が問題になることがある。接続の再利用、接続プール、処理のまとめ方など、利用するデータベースに合った設計が必要になる。

移行は費用の大きい順ではなく、影響範囲の大きい順に行う

一度にすべてを移行する必要はない。むしろ、全面移行は切り戻しが難しく、個人開発では負担が大きい。

最初に画像配信だけを外へ出す。次に静的なフロントエンドを分離する。その後、重いバッチ処理や定期処理を関数化する。データベースを最後までVPSに残す構成もあり得る。

判断の軸は、「最新の構成か」ではない。どの部分を移すと、費用と障害リスクが下がるのかである。

WordPressなら、すべてのリクエストを動的に処理する必要はない。更新頻度の低いページをキャッシュし、画像をアプリケーションサーバーから切り離すだけでも、VPSの役割は変わる。Laravelでも、認証やデータ更新は動的に処理しながら、公開ページや集計結果はキャッシュできる。

データの整合性が必要な部分と、多少古くても問題ない部分を分ける。ここを分けられると、処理を減らしやすい。コスト削減は、安いサービスへ置き換えることより、そもそも処理しなくてよいものを見つけることから始まる。

運用自動化の必須要件：監視・エラー通知・最適化の仕組み作り

コストを削減しても、運用が人力のままでは、趣味とサービスの境界線を越えられない。サービス化したからといって、24時間画面を見張る必要があるわけではない。必要なのは、人間が見ていない時間に異常を検知し、対応が必要なものだけ知らせる仕組みだ。

個人開発者が導入する運用自動化は、最初から大規模にする必要はない。まずは次の順番で考えるとよい。

1. 死活監視とエラー通知

UptimeRobotやBetter Stackなどで、サービスが応答しているかを確認する。ログイン画面だけを見るのではなく、重要なAPIやデータベースとの接続を含めて、利用者が実際に使う経路に近い確認を用意したい。

画面が表示されていても、登録処理だけが壊れていることはある。トップページの監視だけでは、サービスの核心部分が停止している状態を見逃す。

通知先はSlackでもDiscordでもよい。大切なのは、障害が起きたときにスマートフォンで気づけることと、通知を受け取った後に何を確認するかが決まっていることだ。

2. ログを後から追える状態にする

Vercelのログ、Sentryのエラートラッキング、AWS CloudWatch Logsなど、利用している環境に合わせてログを確認できるようにする。

ログを保存するだけでは不十分である。発生時刻、リクエストID、ユーザー操作、対象の機能が追えると、原因調査が早くなる。個人開発では、障害が起きた瞬間にすべての状況を覚えていることはできない。後から確認できる情報を残しておくことが重要だ。

ただし、個人情報や認証情報をそのままログへ出してはいけない。便利だからといってリクエスト全体を記録すると、ログそのものが管理対象になる。何を残し、何を残さないかを決めることも運用設計の一部である。

3. データベースの問い合わせを減らす

Laravelでは、遅いクエリを調べ、必要なインデックスを検討する。N+1クエリの解消は地味だが、アクセス増加に対して効果が出やすい。

ほかにも、次のような整理がある。

• 必要な列だけを取得する。
• 一覧画面にページネーションを入れる。
• 同じ内容を何度も取得している箇所をキャッシュする。
• 不要な並び替えや集計を毎回実行しない。
• 管理画面の集計処理を、利用者向けのリクエストから切り離す。
• 大量データを一度に読み込まず、分割して処理する。

データベースの負荷は、PVが増えたときに突然現れるというより、開発中から積み重なっている。小さなデータで問題が見えないだけで、構造としてはすでに存在していることが多い。

4. 画像配信をアプリケーションから切り離す

画像をアップロード時にリサイズし、用途に応じたサイズで配信する。元画像をそのままHTMLへ埋め込む運用は、帯域と表示速度の両方で不利になりやすい。

Cloudflare R2やS3などのオブジェクトストレージを使う場合も、容量や転送量、操作回数など、料金に影響する項目を確認する必要がある。保存先を分ければ自動的に安くなるわけではない。どのサイズの画像を、どの経路から、どの頻度で配信しているのかを把握することが先だ。

WordPressでもLaravelでも、アプリケーションが画像を毎回中継する必要があるのかを考えたい。画像を別の配信経路へ出すだけで、アプリケーションサーバーの負担が軽くなることがある。

5. 課金と契約状態を自動化する

Stripeなどの決済サービスを使う場合、Webhookでサブスクの開始、停止、支払い失敗を受け取り、アプリ側の契約状態を更新する。

決済が成功したのに権限が付かない。解約したのに有料機能を使い続けられる。支払いに失敗したユーザーの状態が更新されない。こうした処理を手作業で直し続けるのは難しい。

決済関連では、Webhookが重複して届いた場合や、処理途中で失敗した場合も考える必要がある。同じイベントを複数回処理しても状態が壊れないようにするなど、通常の画面処理とは違う設計が求められる。

6. バックアップと復旧手順を確認する

バックアップが存在することと、復旧できることは別である。保存先、世代数、保持期間を決め、復旧手順を自分で説明できる状態にしておく。

対象はデータベースだけではない。アップロード画像、環境変数、決済関連の設定、ドメインやDNSの情報など、サービスを再構成するために必要なものを洗い出す。

バックアップが正常に取れているという通知だけでは、復旧できる保証にならない。少なくとも、どのデータをどこから戻すのか、戻した後に何を確認するのかを整理しておく。障害が起きてから手順を考えると、復旧の遅れがそのままユーザーの不利益になる。

通知は多ければよいわけではない。すべての警告を同じ場所へ流すと、重要な障害が雑多なログに埋もれる。

• すぐに対応しないとユーザーが使えない障害。
• 数時間以内に調査したい性能劣化やエラー増加。
• 週次や月次で確認すればよい容量、費用、更新の通知。

この三つを分けるだけでも、通知に追われにくくなる。夜間に即対応すべき障害と、翌朝でよい警告は同じ扱いにしない。サービスの継続性だけでなく、運用する人間の睡眠も設計対象に含めるべきだ。

通知が鳴るたびに開発者が飛び起きる構成は、信頼性が高いのではない。対応の優先度まで設計されて、初めて運用自動化になる。

自動化の罠は、最初からすべてを導入しようとすることにある。死活監視とエラー通知から始め、次にログ、バックアップ、画像最適化、課金処理へ広げていけばよい。完璧なダッシュボードを作ろうとして、運用そのものに疲れてしまっては意味がない。

自動化には、作業を減らすだけでなく、判断を固定する効果もある。障害が起きたら通知する。課金に失敗したら契約状態を切り替える。画像がアップロードされたらサイズを調整する。毎回その場で判断している処理を仕組みに移すことで、開発者の頭の中にしかなかった運用ルールをシステム側へ移せる。

持続可能なグロースのためのマネタイズとインフラ設計の再定義

マネタイズとインフラ設計は、別々に決めるものではない。ここを分けて考えると、収益を増やすために機能を追加し、その機能が負荷と問い合わせを増やし、結果として利益が残らないという状況になる。

個人開発でよくある失敗は、次のようなものだ。

• 広告に頼りすぎて、ユーザー体験が崩れている。
• サブスクを導入したが、解約フローが複雑になっている。
• 投げ銭の導線を置いただけで、利用者が支払う理由が見えない。
• 有料プランと無料プランの差が分かりにくい。
• 収益機能を追加した結果、問い合わせや返金対応が増えている。
• 無料ユーザーの大量利用が、そのまま開発者の費用負担になっている。

広告収益でサーバー代を回収しようとすると、PVを増やす必要がある。しかし、PVが増えれば必ず利益が増えるわけではない。画像や動的ページの比率が高ければ、アクセス増加とともに費用も増える。

サブスクでも同じだ。ユーザーごとに保存データが増えるサービスでは、契約者が増えるほどストレージやバックアップの費用が増える。画像、動画、生成物、エクスポートファイルを扱うサービスでは、アプリケーション本体よりもファイルの保管と配信がコストの中心になることがある。

コスト構造をPVだけに依存させない

このジレンマを避けるには、収益と費用が同じ指標だけで増えないように設計する。

• 基本機能は無料で提供し、エクスポートや高度な分析などを有料にする。
• サブスクユーザーには広告を非表示にする。
• 趣味で使う層と業務利用の層で、保存容量やサポート範囲を分ける。
• API提供やチーム利用など、PVだけに依存しない収益手段を用意する。
• 無料ユーザーの利用量に上限を設け、想定外の大量利用を防ぐ。
• 大きなファイルや高頻度の処理を、通常の無料利用と同じ条件にしない。

無料プランの上限を厳しくしすぎると、価値を理解する前にユーザーが離れる。制限の目的は、すぐに有料へ追い込むことではない。サービスを試せる余地を残しながら、開発者の費用が予測不能にならない位置に線を引くことだ。

インフラ側でも、無料枠は「使い切る目標」ではなく、余白を持たせて使うものだと考えたい。無料枠の条件や上限はサービスごとに異なるため、導入前に公式仕様を確認する。平常時の利用量が上限ぎりぎりなら、急なアクセス増や設定ミスだけで運用が不安定になる。

一方で、すべてを有料のクラウドサービスへ移せば安心というわけでもない。便利なサービスを組み合わせるほど、請求の発生箇所や障害の確認箇所が増える。全てをVPSへ集約する構成も、障害時の影響範囲が広くなりやすい。

現実的には、処理の性質に応じて使い分けることになる。

• 常に動いている必要があるもの。
• アクセスがあったときだけ動けばよいもの。
• 大量のデータを保存するもの。
• 外部へ配信するもの。
• 失敗するとユーザーのデータや決済に影響するもの。

これらを一つのサーバー、一つの課金モデルへ押し込めない。構成を分ける理由は、最新技術を使うためではなく、費用と障害の影響範囲を分けるためである。

サービス運用への移行タイミングを決める三つの視点

月間10万PVという数字だけで、VPSが必要か、サーバーレスへ移行すべきかは判断できない。見るべきなのは、次の三つだ。

まず見るべきは、アクセスではなく負荷の内訳

静的な記事が中心なのか、ログイン後の画面が多いのか、画像を大量に配信しているのか、1回のアクセスで何本のAPIを呼ぶのか。アクセスをアプリケーション、データベース、ストレージ、帯域へ分けて見る。

PVが増えてもキャッシュが効いていれば、アプリケーションへの負荷は抑えられる。反対に、PVが少なくても、毎回重い集計や検索を実行していれば、データベースが先に限界へ近づく。

次に、障害時の損失を考える

自分のメモ帳代わりのアプリなら、数時間の停止を許容できるかもしれない。予約、決済、データ保存、通知を扱うなら、同じ停止時間でも意味が変わる。

ユーザーが何を失うのかを考えると、必要な監視やバックアップの水準が見えてくる。データを失う可能性があるなら、復旧までの時間だけでなく、どの時点まで戻せる必要があるのかも決めたい。

最後に、運用できる量かを判断する

構成が高度でも、自分が理解できず、通知を見ても原因を追えないなら、個人サービスには重すぎる。安い構成より、壊れたときに自分で直せる構成の方が長期的には強い。

複数のクラウドサービスを組み合わせると、個々の料金は小さく見えても、設定、権限、ログ、障害対応の手間が増える。自分が月に使える時間と、対応できる時間帯を踏まえて構成を選ぶ必要がある。

個人開発の「サービス化費用」は、サーバーの料金表だけでは出せない。監視、バックアップ、ログ保存、ドメイン、決済手数料、問い合わせ対応、そして自分の時間まで含めて、ようやく運用コストの全体像になる。

だからといって、最初からすべてを有料にする必要はない。ユーザーが増えた部分、障害が起きると困る部分、失敗時の復旧が難しい部分から、順番に運用を強くしていけばよい。

趣味の開発をサービス運用へ移すタイミング

個人開発からサービス運用への移行タイミングは、「月間10万PVに到達した日」と機械的に決めるものではない。むしろ、次のような変化が重なったときに判断するものだ。

ユーザーが継続的に利用している。データを預かっている。障害を自分だけでは発見できない。復旧に失敗すると利用者へ影響が出る。無料枠や従量課金の条件を把握しないと、費用が予測できない。新機能よりも、既存機能を安定して動かす時間が増えている。

この状態になったら、趣味の延長として扱うには、すでに責任が大きくなっている。

モダンな技術を使えば、すべてが解決するわけではない。VPSを捨ててクラウドへ全面移行すればよいわけでもない。Laravelを使うか、WordPressを使うか、Dockerでまとめるか、サーバーレスへ切り出すか。選択肢そのものより、「今、自分のサービスがどこにあり、どこへ持っていきたいのか」を冷静に見極めることが重要だ。

サーバー代で慌てる前に、無料枠の条件と収益の変動を可視化する。アクセスが増えたときの費用、障害が起きたときの復旧時間、ユーザーが支払う理由。この三つが見えてくれば、個人アプリをサービス化するタイミングも、移行にかけられる費用も具体的になる。

趣味の温度感のまま、サービスの数字に向き合う瞬間は、アクセスが増えた後にやってくる。そのとき必要なのは、勢いで高価な構成へ乗り換えることではない。自分が責任を持って運用できる範囲を定め、壊れ方を予想し、収益とコストが釣り合う場所へ少しずつサービスを移していくことだ。

月間10万PVは、個人開発の終わりではない。利用者が増えたことで、開発者の都合だけではなく、サービスを使う人の期待にも向き合い始める転換点である。無料枠の数字に頼る段階から、負荷、費用、復旧、収益を自分で設計する段階へ移る。その変化を受け入れたとき、趣味で始めたアプリは、無理なく続けられるサービスへ近づいていく。

Related reading: 個人開発のサーバー選定：VPSによる低コスト管理とPaaSの自動化 and Cloudflare R2による個人開発アプリのDBバックアップ自動化とコスト削減.