料金表を先に決めるべき理由
Claude API を使ったマイクロ SaaS を作り始めるとき、多くの方がまず「何が作れるか」から入ります。私もかつてはそうでしたが、何度か小さな失敗を重ねて、今は「料金表を先に書く」を習慣にしています。
理由は単純で、Claude API は本番稼働すると従量の原価が毎日積み上がっていくからです。機能を作り切ってから料金を考えると、原価の方が先に膨らんでしまい、「使ってもらうほど赤字が増える」という構造に陥りがちです。先に料金表を立てて、そこから逆算して機能スコープを決めるのが、マイクロ SaaS の健全な進め方だと実感しています。
ここでは料金表を先に書くために必要な設計の型を、原価構造、モデル選択、値付け実験、グランドファザリングまでひととおりお伝えします。数千円から数十万円規模の月額で回る、個人〜少人数運営のマイクロ SaaS を前提にしています。
Claude API の原価構造を素直に把握する
料金設計の出発点は、Claude API 自体のコスト構造を手触りとして理解することです。2026 年時点での Anthropic の課金は、入力トークン単価、出力トークン単価、Prompt Caching の書き込み／読み出し、Extended Thinking 分、ツール使用分、という要素に分かれています。
私がおすすめする最初のステップは、自分のアプリで一回のリクエストが平均いくらかかるかを、実測することです。理論値ではなく、実際に動いたログから算出します。Anthropic のコンソールにある使用量ダッシュボードか、自前で input_tokens と output_tokens をログに記録して集計すると、1 リクエストあたりの原価が円単位で出てきます。
私の例では、あるチャット型マイクロ SaaS の初期実装で、1 リクエストあたり平均 14 円でした。原価がこの単位で見えてくると、月間 1,000 リクエストで 14,000 円、1 万リクエストで 14 万円、という感覚がつかめます。この数字を持たずに月額料金を決めると、ヘビーユーザー 1 人で赤字になる、という事故が起きます。
粗利率 65% を逆算する原価テンプレート
個人運営のマイクロ SaaS で目指したい粗利率は、私の経験では最低でも 65%、可能なら 75% です。これを下回ると、サーバー代・決済手数料・問い合わせ対応の人件費（自分の時間）を差し引いたときに、手元に残るキャッシュが薄くなります。
逆算の計算式はシンプルです。月額料金 × (1 − 粗利率) = 1 ユーザーあたりの許容原価。月額 1,500 円、粗利率 65% なら、1 ユーザーあたり月 525 円が許容原価です。1 リクエストあたり 14 円の例だと、月 37 リクエストで原価上限に達します。
ここで現実とのギャップが見えてきます。チャット型サービスでヘビーユーザーが月 200 リクエスト送る想定なら、14 円 × 200 = 2,800 円で、月額 1,500 円のプランは成立しません。この段階で選択肢は三つあります。1 リクエストあたりの原価を下げる（Prompt Caching、モデルのダウンサイズ、プロンプト短縮）、月額料金を上げる（月額 4,000 円にする）、従量課金を組み合わせる（月額 1,500 円 + 100 リクエスト超過分は 1 リクエスト 20 円）です。
Prompt Caching は原価削減で最も効きます。システムプロンプトが長い SaaS だと、キャッシュヒット時に読み出し単価がキャッシュ書き込みの 10 分の 1 程度になるため、1 リクエストの実原価が 14 円から 3〜4 円に落ちることがあります。料金設計の前提として、キャッシュヒット率をどこまで上げられるかを実装段階で検証しておくと、後の値付けで楽になります。
三つの料金モデルの向き不向き
マイクロ SaaS の料金モデルは、大きく三つに整理できます。従量課金、サブスクリプション、Freemium です。それぞれに向き不向きがあります。
従量課金が向くのは、利用頻度のばらつきが大きいサービスです。たとえば「月に 1 回だけ契約書をレビューする」ユーザーと「毎日レビューする」ユーザーが混在する場合、一律のサブスクだと前者に高く、後者に安く見えてしまいます。リクエスト単位で課金すれば、両者とも納得しやすい価格になります。弱点は、月末まで売上が読めないことと、初回購入のハードルが心理的に高いことです。
サブスクリプションが向くのは、日次または週次で定期的に使われる前提のサービスです。利用頻度が安定しているほど、ユーザー側も予算化しやすく、事業側も MRR（月次経常収益）として積み上げやすくなります。弱点は、利用頻度の低いユーザーにとって割高に感じられ、チャーンしやすいことです。
Freemium は、利用頻度の低い層を長期的に囲い込みながら、一部をサブスクへ転換させる戦術です。向くのは「最初は試さないと価値が伝わらない」サービスと「プロユーザーと一般ユーザーの使用量に 10 倍以上の開きがある」サービスです。弱点は、無料枠の原価が事業側の持ち出しになるため、転換率が 5% を下回ると成立しないことです。
私の経験上、マイクロ SaaS のスイートスポットは「サブスク + 従量オーバーの二段構え」です。基本料金でライトユーザーを囲い込み、ヘビーユーザーには追加課金で原価を回収する形で、粗利率を安定させられます。
サブスク + 従量のブレンド設計
具体的にサブスク + 従量のブレンドを設計する手順を、5 ステップでご紹介します。
一つ目は、プランの「含み込み単位」を決めます。たとえば「月 100 リクエストまで含む」「月 10 時間分の処理時間まで含む」のように、ユーザーが自分の使用量を把握しやすい単位を選びます。トークン数で語るのはエンジニア以外には伝わりにくいので、「リクエスト数」や「生成回数」など、業務文脈の単位に変換することが大事です。
二つ目は、含み込み単位を超えたときの従量単価を決めます。超過分の単価は、プラン内単価よりも高めに設定するのが一般的です。プラン内は「セット割引」、超過分は「単品価格」というイメージで、プランを買った方が得だと感じてもらえる差をつけます。
三つ目は、段階プランを用意します。Solo プラン（月 1,500 円・月 100 回まで）、Pro プラン（月 4,800 円・月 500 回まで）、Team プラン（月 14,800 円・月 2,000 回まで）、のように、利用量の階段を三段程度で刻みます。段階が多すぎるとユーザーが迷いますし、少なすぎると各プランの適合範囲が狭くなります。三段がちょうど良いバランスだと感じます。
四つ目は、年払いの割引を用意します。年払い 2 ヶ月分無料、といった割引は、事業側のキャッシュフローを前倒しするだけでなく、チャーン率を下げる強力な仕組みです。個人運営の SaaS だと、年払い顧客の LTV（生涯価値）が月払い顧客の 3 倍以上になることもあります。
五つ目は、超過時の自動アップグレード導線を設計します。ユーザーが月の含み込み枠を超えたときに、超過課金が発生する前に「次のプランへアップグレードすると割安になります」と提示するバナーを入れておくと、ユーザー体験とアップセルの両立ができます。
値付け実験で失敗しないための段階的ローンチ
料金表はローンチ時点で完成している必要はありません。むしろ、段階的に調整していく前提で設計した方が、失敗コストを抑えられます。
私が使っている段階的ローンチのパターンは、おおむね次の流れです。
まず、ローンチ初月は「早期ベータ価格」としてやや低めの料金で走らせます。たとえば本来の想定が月 3,000 円なら、ベータ価格 1,500 円で募集します。この段階の目的は、実際の利用量データを集めることと、初期ファンを獲得することです。ベータ価格であることを明示し、「正式リリース時に価格は上がる予定です」と伝えておきます。
次に、ベータ終了のタイミングで、正規料金を発表します。このとき、ベータ期間中に登録したユーザーには、一定期間（たとえば 6 ヶ月）ベータ価格を継続する「グランドファザリング」を適用します。これにより、ベータ参加者が離反せず、ベータ体験の価値が維持されます。
最後に、正規料金でしばらく運用したあと、3〜6 ヶ月おきに値付けの見直しを検討します。値上げは過激にはやらず、10〜20% の範囲に留め、既存ユーザーには 1〜2 ヶ月の事前通知を行います。値上げ時には同時に機能追加を発表すると、心理的な受け入れやすさが高まります。
ダウングレード対策としての「スリープ会員」設計
マイクロ SaaS の収益性を左右するのは、既存ユーザーのチャーン対策です。ユーザーが忙しくて一時的に使えなくなったとき、全面解約されるのと、スリープモードに入ってもらうのでは、その後の復帰率が全く違います。
スリープ会員の設計はシンプルです。月額 1,500 円のプランを、一時的に月額 300 円の「スリープ料金」に切り替えられるようにします。スリープ中は利用できませんが、アカウントとデータは保持され、いつでもスリープ解除で元に戻せる、という仕組みです。
この仕組みを入れると、「一時的に使わないから解約する」という層の多くをスリープに吸収できます。完全解約だと 30% が戻ってくるのに対して、スリープからの復帰は 60〜70% になる、というのが個人運営 SaaS 界隈で共有されている肌感覚です。
Stripe のサブスクリプション API では、pause_collection 機能を使うとサブスクを一時停止できます。ただし課金を完全停止するとスリープ料金が取れないので、プラン切り替え（ update で別の price に変更）を使う方が実装は素直です。
価格改定時に信頼を失わないためのコミュニケーション
価格改定は、やり方を間違えると一気に信頼を失います。私は次の三つの原則を守るようにしています。
一つ目は、事前通知を必ず行うことです。最低でも 1 ヶ月、できれば 2 ヶ月前に、メールと管理画面の両方で通知します。突然値上がりするのは、どんな理由があっても心情的に受け入れにくいものです。
二つ目は、値上げの理由を正直に書くことです。原価が上がった、新機能を追加した、市場相場と合わせた、など、具体的な理由を率直に書きます。「諸般の事情により」は避けます。ユーザーは値上げそのものより、扱いが雑なことに怒ることが多いです。
三つ目は、既存ユーザーへの配慮を明示することです。グランドファザリングの期間、年払い切替での割引、スリープへの切り替え、といった選択肢を同時に案内します。「値上げします、以上」ではなく「値上げします、その上でこういう選択肢があります」と書くだけで、離反率が大きく変わります。
個人運営のマイクロSaaSがスケールする料金設計の終着点
マイクロ SaaS は規模を追わない事業です。10 人で成立する料金、100 人で利益が残る料金、1,000 人で無理なくサーバーが回る料金、を階段状に設計しておくと、ゆるやかに成長しながら利益を確保できます。
私が目安にしているのは、100 ユーザーで月額粗利 20 万円、500 ユーザーで月額粗利 80 万円、1,000 ユーザーで月額粗利 150 万円、というラインです。この水準に届いていれば、個人運営でも開発を続けられるキャッシュが残ります。
料金表の数字は、ここから逆算できます。月額粗利 150 万円を 1,000 ユーザーで出すには、1 ユーザーあたり月 1,500 円の粗利が必要です。粗利率 65% を前提にすると、平均月額料金は約 2,300 円、超過従量分を含めた客単価は 2,500〜3,000 円というレンジに落ち着きます。この数字を最初の料金表に素直に反映しておくのが、マイクロ SaaS を長く続ける一番の近道です。
次のアクション
ここまで読んでくださってありがとうございます。今日やれることを一つ提案します。いま進めているマイクロ SaaS の 1 リクエストあたりの実原価を、実装したコードのログから実測してみてください。14 円でも 2 円でも、その数字が出た瞬間に、月額料金の候補が機械的に決まります。逆算が終われば、あとは本記事でご紹介したブレンドモデルに当てはめるだけです。料金表を先に書くという小さな習慣が、マイクロ SaaS の黒字化を現実のものにします。