「お客様が増えても回るか」事業を始める前に立てたい問い

公開日 2026-09-05　執筆：原本 昌悟（ノルツ株式会社 代表取締役）

「お客様が増えても回るか」を事業開始前に確認するには、どんな問いを立てればいい？

顧客数が増えたときに「最初に足りなくなるもの」を1つに絞って書き出すのが出発点です。詰まる場所は、自分の時間・使うツールの上限・原価のいずれかに現れやすくなります。ノルツ株式会社代表・原本は、一人社長で事業をやるときはリソースとの戦いになるため、スケールした場合に回るのかという問いを毎回立てるとよいと語っています。

事業計画のうち、売上の伸び方は多くの人が書きます。一方で「その売上を出すために、何をどれだけ動かすのか」は抜けやすい部分です。顧客が1社のときは自分の手で何とでもなりますが、社数が増えた瞬間に破綻する設計だと、受注できたのに納品できないという状態になりかねません。

原本は、この点を次のように話しています。

「結局事業を一人社長で事業をやるとき、リソースとの戦いになります。なので、この事業がスケールした場合にちゃんと回るのか、っていうところをね、あの問いを毎回立てるようにするといいんじゃないかなというふうに思っております。」

事業開始前に書き出しておきたい問い

• 顧客が10社になったとき、1日で自分が使う時間は何時間増えるか
• 提供に使うツール・システムに、回数・容量・同時実行などの上限はあるか
• 上限に当たったとき、増やせるのか（プラン変更・分散）、増やせないのか
• 顧客が増えるほど比例して増える原価は何か。固定費として吸収できるものはどれか
• 「一番先に詰まるのはここ」と1つ名指しできるか

ポイントは、すべてを網羅することではなく、最初に詰まる場所を1つ名指しできる状態にしておくことです。名指しできれば、そこだけを狙って検証できます。

ビジネスモデルが「スケールしても成り立つか」はどこを見れば検証できる？

見るべきは「顧客が増えたときに何が比例して増えるか」です。増えるものが自分の作業時間なら時間の上限、ツールの処理量ならツール側の上限、原価なら粗利が検証対象になります。原本は、一人社長は自分のリソースをあまり割かなくても提供できるビジネスモデルが望ましいと考えており、その前提でAIによる業務自動化も選択肢に入れています。

スケール検証は、細かい財務モデルを組む前に「増えるもの」を分類するだけでも精度が上がります。以下は、詰まり方の違いを整理した表です。

ボトルネックの種類	顧客が増えると起きること	事前チェックの方法
自分の時間	納品や対応の作業時間が顧客数に比例して増え、営業や経理に回す時間が消える	1社あたりの作業時間を実測し、目標顧客数で掛け算する
ツール・システムの上限	処理量や実行回数の制限に当たり、ある社数から先が受けられなくなる	使うツールの制限仕様を公式情報で確認し、少件数で実際の消費量を測る
原価・変動費	売上は増えるが粗利率が下がり、増やすほど苦しくなる	1件あたりの変動費を出し、値付けと突き合わせる

原本が新規事業を考えた背景には、一人社長で独立するとサービス提供・営業・経理財務処理など様々な業務にリソースが割かれるという現実がありました。そのため、自分のリソースをあまり割かなくても提供できるモデルが望ましいという発想で、AIによる業務効率化・自動化を選択肢に入れています。

ただし、自分の時間を使わない設計にすると、ボトルネックは「自分」から「ツール」へ移ります。移った先の上限を確認しないまま設計すると、詰まる場所が見えないまま進んでしまいます。

スケール前提の事前チェックを飛ばすと、実際にどんな失敗が起きる？

原本の場合は、AIで自動化した業務そのものをサービスとして販売する新規事業を1つ立ち上げたところ、トークンの消費が想定より大きく、Claudeの5時間ごとの利用制限に当たるという問題が出ました。企業数（顧客数）を増やすと制限にかかることが、テストの中で判明しています。

この新規事業は、自分のリソースをあまり割かずに提供できるモデルという発想で始めたものです。Claude（クロード）のスケジュール機能を使って業務が回るように設定し、その自動化された業務自体をサービスとして提供する形でスタートしました。

実際に動かしてみて見えたのは、次の発言のとおりです。

「意外とですね、トークンの消費が大きくて、クロードって5時間ごとに利用量の制限があるんですけれども、これ企業数を増やしてしまうと、この5時間の制限にどうしてもかかってしまうなということに気がつきました。」

振り返って、見落としだったと感じている点

• 顧客数を増やしたときに同時に何社まで扱えるのか、その目安を事前に置いていなかった
• 自動化によって「自分の時間」の問題は解けたが、移った先のツール上限を検証対象にしていなかった
• テスト前の段階では、1件あたりの消費量を数値で把握していなかった（テストを通じて初めて見えた）

なお、AIツールの利用制限の仕様はプランや提供元の方針によって変わります。執筆時点（2026年9月時点）の内容として書いていますので、実際に事業設計に使う場合は提供元の公式ヘルプで最新の仕様を確認してください。

スケールするかどうかは、テストでどこまで分かる？

少件数のテストでも、消費量や同時に対応できる顧客数の上限といった具体的な数値は見えてきます。原本は「テストをさせてください」とお客様にお願いして何件かテストを実施し、そこでトークン消費量と同時に対応できるお客様の数の上限を把握しました。数値が出たことで、改善すべき箇所が特定できています。

原本は、お客様に「テストをさせてください」とお願いして何件かテストを行ったからこそ、トークンの消費量や同時に対応できるお客様の数の上限が見えてきたと話しています。だからテストをすることは本当に大事だ、という趣旨です。同時に、「こういう方法でやればいいんじゃないか」という発想をすること、そして実際にテストをしてお客様の反応を見ることの両方が大事だとも語っています。

テストで取りに行くとよい情報

• 1件あたりに実際どれだけの処理量・作業時間がかかるか（実測値）
• 何件まで同時に回るか（上限の目安）
• お客様がどこで価値を感じ、どこで不満を感じるか（反応）

ただし、テストだけに頼ると「やってみて初めて分かる」ことが増えます。原本は、テストと同時に、実行する前の状態で「お客様が増えてもこの事業は成り立つのか」を考えることが理想だと述べています。事前の問いとテストの実測値は、どちらか一方ではなく組み合わせるものだという整理です。

テストの進め方や一人社長のリソース配分については、ノルツの起業支援でも関連する体験談を公開しています。

事業計画段階でスケール検証を組み込む手順は？

「増えるものの特定→上限の確認→実測→上限に当たる顧客数の算出→設計の修正」という順番で進めると、机上の計画と実測値がつながります。原本の場合はこの順番の一部を後から実施したため、テストの最中に制限に気づく形になりました。

1. 増えるものを特定する：顧客が1社増えたときに、比例して増えるものを書き出す（自分の作業時間／ツールの処理量／変動費）。
2. 上限の仕様を確認する：使うツールやサービスに回数・容量・同時実行の制限があるかを、提供元の公式情報で確認する。たとえばClaudeの場合は提供元の公式ヘルプに利用量の考え方が案内されています（2026年9月時点。最新の公式情報で確認してください）。
3. 1件あたりを実測する：少件数で実際に運用し、1件あたりの消費量と作業時間を数値で出す。
4. 上限に当たる顧客数を計算する：「一定時間あたりの上限 ÷ 1件あたりの消費量」で、同時に受けられる社数の目安を出す。原本のケースでは、Claudeの5時間ごとの利用量の制限がこの「上限」に当たりました。
5. 設計を修正する：上限が目標顧客数より小さい場合は、処理の分散、提供頻度の変更、対象業務の絞り込みなどで組み替える。

収支計画に反映するときの注意

スケール検証の結果は、売上計画の「上限」として収支計画に書き込めます。たとえば同時に扱える顧客数が分かれば、その事業の月商上限が計算できます。上限を超える売上目標を置いている場合は、単価を上げるか、上限を広げる仕組みに投資するかの判断が必要になります。

上限が見つかった事業は、やめたほうがいい？

上限が見つかったこと自体は、事業をやめる理由にはなりません。原本は5時間ごとの利用制限に気づいた後、その制限にかからないやり方への改善を進めています（進行中の取り組み）。上限が数値で分かった状態は、改善対象が特定できた状態でもあります。

この新規事業は、テストの中で「企業数を増やすと5時間の制限にかかる」という具体的な壁が見えました。壁の位置が分かったので、いまは制限にかからない運用方法に組み替える作業を進めている段階です。結果がすべて出ているわけではありません。

上限が見えた後に取れる選択肢

• 提供のタイミングを分散させ、上限に当たらない運用に組み替える
• 対象業務を絞り、1件あたりの消費量を下げる
• 受け入れ社数の上限を前提として、単価と提供内容を見直す
• その事業単体では成り立たないと判断し、別の形に組み替える

いずれの選択肢を取るにしても、「1件あたりどれだけ消費するか」「上限はどこか」という数値がないと判断ができません。テストの価値は、うまくいくかどうかを確かめることより、判断材料になる数値が手に入ることにあります。

ノルツの起業支援では、こうした事業設計の検証を月額顧問型で一緒に考えています。相談はLINEまたはお問い合わせフォームから受け付けています。

よくある質問

スケール検証は、事業を始める前と始めた後のどちらでやるべきですか？

両方です。原本は、実行する前の状態で「お客様が増えてもこの事業は成り立つのか」を考えることが理想だとしつつ、実際に何件かテストをしたからこそ消費量や同時に対応できるお客様の数の上限が見えてきたと述べています。事前の問いで詰まりそうな場所を特定し、テストで実測値を取る組み合わせが現実的です。

一人社長がスケール検証で最初に見るべきものは何ですか？

顧客が1社増えたときに比例して増えるものです。増えるものが自分の作業時間なら時間、ツールの処理量ならツール側の上限、変動費なら粗利が検証対象になります。原本は、一人社長で独立するとサービス提供・営業・経理財務処理などにリソースが割かれるため、自分のリソースをあまり割かなくても提供できるモデルが望ましいと考えています。

AIを使った自動化サービスは、リソースを使わないので安心ですか？

自動化で自分の作業時間は減っても、ボトルネックがツール側の上限に移ります。原本の場合、Claudeのスケジュール機能を使った新規事業で、トークン消費が想定より大きく、企業数を増やすと5時間ごとの利用制限に当たることが判明しました。使用するツールの制限仕様は、提供元の公式情報で最新の内容を確認してください（執筆時点＝2026年9月時点の情報として記載）。

テストは何件くらいやれば判断できますか？

件数の正解はありません。原本のケースでは「テストをさせてください」とお願いして何件か実施した段階で、トークン消費量と同時に対応できるお客様の数の上限が見えました。1件あたりの実測値が取れ、上限までの計算ができる状態になれば、判断材料としては機能します。

参考・出典

• Anthropic 公式サイト（Claudeの提供元）（2026年9月時点）
• Anthropic サポート（利用量・制限に関する公式ヘルプ）（2026年9月時点）

関連記事

新規事業は先に小さくテスト。お客様にお願いして見えたこと
AI業務自動化をサービス化したらClaudeの利用制限にぶつかった話
一人社長はリソース勝負。時間を使わない事業設計

LINEで無料相談する ご利用の流れを見る

← ブログ一覧へ戻る