0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

マイクロSaaSのランニングコストを月$1に抑える工夫 — 無料枠と自宅サーバーの使い分け

0
Last updated at Posted at 2026-05-08

連載: マイクロSaaS: #1 なぜ米国法人 | #2 Stripe Atlas設立 | #3 年間維持費 | #4 フランチャイズ税 | #5 アイデアの見つけ方 | #6 MVP 1週間 | #7 月$1で運用 | #8 公開後の時期

前回、MVPを作って公開する流れについて書いた。今回は、公開した後の話として、ランニングコストをいかに低く抑えるかについて書く。

#1で「損をしない設計」について触れたが、その具体的な中身がこの記事の内容である。

なぜランニングコストにこだわるのか

会社員のマイクロSaaS経営は、時間とお金を投じて、お金を稼ぐことを目指す活動である。前回の記事でも書いたように、

  • 構想したアプリが実際に実装まで行くことは稀
  • 実装したアプリが想定通りの収益を上げることは稀
  • ましてや、デプロイ直後から流行ることは稀

である。実際のところ、空いた時間でスマホを無意味にいじったり、ネットフリックスを見て時間を潰してしまうよりは、無駄になってもコツコツ開発を続ける方がためにはなる。しかし、MVPまで漕ぎ着けたアプリの場合は多少なりとも淡い期待を持ち合わせているので、デプロイ直後にやっぱり全然反応がないと落ち込む。

仮にここでランニングコストが高いとする。回収できると思っていたコストは全く回収できず、毎月数万円の請求が来て、売上はゼロ。この状態が3ヶ月、半年と続くと、「本当にこのまま続けていいのか」という疑問が頭を離れなくなる。半年、1年と保守管理を続けていれば伸びたかもしれないサービスを、3ヶ月くらいで撤退して、また新しいものを作り始める。冷静に判断すべきタイミングで、焦りから変な判断をしてしまう。

逆に、月$1なら何も感じない。1年2年くらいは放置しておいても全く問題ない。この「実質コストゼロ」状態を維持することが、コツコツやり続けるための前提条件だと考えている。

一番やってはいけないこと

一番やってはいけないのは、最初からアプリが爆売れしてユーザーが大量にいる状態を想定してリソースを設計することである。「このサーバーだと1万ユーザーがアクセスした場合に負荷がかかるかもしれない。1つ上のプランにしよう」とか、場合によっては「商標登録を先に済ませよう」「特許を取ってしまおう」「利用規約を弁護士に依頼して作ってもらわないと」といった具合である。

現実として、ほとんどの場合は最初の半年間は1日数十人がアクセスする程度である。
商標を争うほどの知名度など得られないし、利用規約など誰も読まない。そもそも、LPさえ読んでもらえるかは怪しい。
スケールの問題は、スケールしてから考えればいい。

おすすめの構成:無料枠を使い倒す

自分が使っている構成とコストは以下の通りである。

カテゴリ サービス 月額 備考
サーバー Vercel $0 無料プランで十分。商用利用は有料プラン推奨
バックエンド Firebase(Firestore) 数十円〜 無料枠が大きい。小規模なら実質無料
認証 Firebase Authentication $0 ユーザー数無制限で無料
決済 Stripe $0(+手数料2.9%) 売上がなければコストゼロ
エラー監視 Sentry $0 無料プランで月5,000イベント
アクセス解析 Google Analytics $0 完全無料
検索分析 Google Search Console $0 完全無料
ドメイン Cloudflare 約$1/月 .comドメインが年$10〜15

この構成の優秀なところは、ユーザーがゼロの場合はドメイン代の月約$1しかかからないことである。サービスが成長して無料枠を超えたときに初めて追加コストが発生するが、その時点では売上も立っているはずなので問題にならない。

Vercelの注意点

ただし、Vercelには2つの注意点がある。頻繁にデプロイを繰り返すと無料枠をすぐに使い切ることと、無料プランでは商用利用が基本的にNGであることである。そのため、自分はVercelをやめて自宅サーバーに置き換えた。

自宅サーバーで月0円

自分の場合、最もコスト削減に効いているのはサーバー代が0円であることである。自宅にサーバーを1台置いて、全てのサービスをそこで動かしている。もともと別の用途で使っていたサーバーなので、購入にかかる初期費用や追加の電気代はほぼゼロである。

自宅サーバーには固定IPアドレスがないが、Cloudflare Tunnelを使えば問題ない。Cloudflare Tunnelは、自宅サーバーからCloudflareのネットワークに向けてトンネルを張る仕組みで、外部からのリクエストをCloudflare経由で自宅サーバーに転送してくれる。これが無料で使える。つまり、ドメインさえ持っていれば自宅のサーバーをインターネットに公開できる。SSL証明書もCloudflareが自動で管理してくれるので、HTTPSの設定も不要である。

もし読者が自分と同様にすでにサーバーを持っていて、多少の知識があるなら自宅サーバーでの運用をおすすめする。サーバーでなくても、1世代前のPCが余っているのであれば、それで構わない。

一方で、わざわざ自宅サーバーを新規に購入して構築するのはおすすめできない。月々の維持費にはサーバー自体の購入代金と電気代を上乗せして考える必要があるからである。

費目 金額
サーバー購入代金(36万円を4年償却) 7,500円/月
電気代 約2,000円/月
合計 約9,500円/月

さらに、自宅サーバーには以下のデメリットもある。

自宅サーバー vs Vercel有料プラン

項目 自宅サーバー(新規購入) Vercel有料プラン
月額 約9,500円(償却+電気代) $20(約3,000円)
冗長性 なし(停電で落ちる) あり
セキュリティ管理 自分でやる プロバイダーが管理
スケーラビリティ ハードウェア上限 自動スケール
技術知識 必要 不要

すでにサーバーを持っている場合を除けば、Vercelの有料プランの方が安くて楽である。Vercelはスポーツジムに近いビジネスモデルだと思っている。契約している会員の多くはあまり利用しておらず、リソースは共有されている。一人当たりにかかるコストは非常に安いので、個人がサーバーを購入して維持する場合よりも、はるかに低価格で同等のものを提供できるのだろう。

コストの推移

理想的には、コストは以下のように推移する。

フェーズ 売上 月額コスト 状態
立ち上げ期 0 アプリあたり月$1 精神的に無風
初期ユーザー期 数千円 月$1のまま 売上がコストを上回る
成長期 数万円 月数千円 無料枠を超え始めるが売上の方が大きい
スケール期 数十万円 月数万円 クラウド移行。売上で十分カバー

ポイントは、どのフェーズでもコストが売上を大幅に上回ることがないように設計していることである。特に立ち上げ期の「売上ゼロでもコストが気にならない」状態を作ることが、精神的な安定の鍵になる。

参考までに、自分は今この構成で複数のマイクロSaaSを動かしている。サーバーは自宅で1台、追加コストはアプリごとのドメイン代だけなので、アプリ数を増やしてもコストはほぼ変わらない。複数のサービスを同時に試して、伸びたものに集中するというポートフォリオ戦略との相性がいい。

運用しているサービス

具体的にはこの構成で以下のマイクロSaaSを動かしている。

  • incnumber.com — 米国法人向けの電話番号維持サービス。月 $7 で、OpenPhone(現Quo)Starter $19/月の3分の1強。SMS はメールに転送、電話は自動でテキスト誘導するので英語を話す必要がない。
  • faxchat.app — 米国・国際向けのオンライン FAX。Pro プラン月 $12(送信 200 + 受信 300 ページ)は eFax 月額 $19.95 の約6割。サブスクが嫌なら登録不要・1回 $1.50 + $0.30/ページの都度課金も使える。
  • quickfaxjp.com — 日本国内向けのオンライン FAX 送信サービス。月額なし、1枚 ¥300 から、登録不要。コンビニまで行かずスマホからそのまま送れる。

連載: マイクロSaaS: #1 なぜ米国法人 | #2 Stripe Atlas設立 | #3 年間維持費 | #4 フランチャイズ税 | #5 アイデアの見つけ方 | #6 MVP 1週間 | #7 月$1で運用 | #8 公開後の時期

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?