この記事の要点
新規事業は、完成させてから売るのではなく「テストをさせてください」とお客様にお願いして小さく試す方法があります。原本は自社の新規事業で何件かテストを行い、AIツールの利用制限という想定外の上限を本格提供の前に見つけました。原本は、テストと同時に「お客様が増えても成り立つか」を毎回問うことを勧めており、原本のケースでは本格提供の前に設計を見直す段階へ戻れました（改善は現在進行中です）。
公開日 2026-09-05 執筆：原本 昌悟（ノルツ株式会社 代表取締役）
新規事業は本格提供の前に小さくテストしたほうがいい？
原本の経験では、小さくテストしたことで、本格提供の前に想定外の制約を見つけられました。実際に動かしてテストするまで、トークン消費量や同時に対応できるお客様の数の上限は見えていませんでした。テストは「完成度を見せる場」ではなく「想定外を早く見つける場」として使っています。
原本は自社で、AIを使って業務を自動化し、その自動化した業務自体をサービスとして販売するという発想で、新規事業を1つスタートしました。実際にお客様に使ってもらうテストを行った段階で、トークンの消費量や、同時に対応できるお客様の数の上限が具体的に見えてきました（設計時点でどこまで想定していたかについて、原本は明言していません）。
「こういう方法でやればいいんじゃないかという発想をするのがすごい大事です。それで実際にテストをしてみて、お客様の反応というんですかね、どういうような反応をされるのかとか、すごい大事だなというふうに思っています。」（ノルツ株式会社代表・原本）
「発想」と「テスト」はセットで初めて意味を持つ
新しい事業アイデアは、思いついた時点ではまだ仮説にすぎません。原本の場合も、「AIで自動化した業務をそのままサービスとして売る」という発想からスタートしましたが、実運用でどのくらいの負荷がかかるかは、テストを行うまで数値としては可視化されていませんでした。
- 発想（仮説）＝こういう方法でやればいいのではないか
- テスト＝実際にお客様に使ってもらい、反応と制約を見る
- 修正＝見えた制約に合わせて設計を見直す
原本の場合、お客様にお願いして何件かテストを行ったことが、問題の早期発見につながりました。テストの段階で制約が見えたため、本格提供に進む前に設計を見直す作業へ戻ることができています（改善は現在進行中で、本格提供に至った段階ではありません）。
お客様に新規事業のテストをお願いするとき、どう伝えればいい？
原本は「テストをさせてください」と伝えてお客様にお願いし、何件かテストを実施しました。本記事では、原本の発言どおり「何件か」という範囲でのみ記載します。完成品として売るのではなく、検証段階であることを最初に共有する形です。
新規事業の検証でつまずきやすいのは、「まだ完成していないものをお客様に見せていいのか」という迷いです。原本はここを、テスト段階であると先に伝える形で進めました。
「テストをさせてくださいとお願いをして、何件かテストをしたからこそ、このトークンの消費量とかね、上限の同時に対応できるお客様の数とかそういうのが見えてきたという問題がありますので、テストすることは本当に大事だなというふうに思っております。」（ノルツ株式会社代表・原本）
原本が実際にやったこと
- テストであることを伝えてお願いした：「テストをさせてください」と直接お客様に依頼した
- 何件かテストを実施した：原本は具体的な件数を明らかにしていないため、本記事でも「何件か」という表現にとどめる
- テストを通じて数量面の情報を得た：トークンの消費量と、同時に対応できるお客様の数の上限が見えてきた
「テストです」と伝えるのは、期待値を下げる行為ではなく、検証段階を正直に共有する行為だと原本は考えています。原本の場合、この伝え方でお客様に協力していただき、テストを実施できました。
小さくテストして、実際にどんな問題が見えた？
原本のケースでは、AIツールのトークン消費が想定より大きく、Claudeの「5時間ごとの利用量の制限」に、お客様（企業数）を増やすとどうしてもかかってしまうことに気づきました。これは実際にお客様に使ってもらうテストで初めて具体的に見えた制約です（設計時点の想定について原本は明言していません）。
原本が着手した新規事業は、Claude（クロード）のスケジュール機能を使って業務が回るように設定し、それをサービスとして提供するモデルでした。テストの過程で見えたのは、性能や品質ではなく「同時にどれだけのお客様を抱えられるか」という上限の問題でした。
「意外とですね、トークンの消費が大きくて、クロードって5時間ごとに利用量の制限があるんですけれども、これ企業数を増やしてしまうと、この5時間の制限にどうしてもかかってしまうなということに気がつきました。」（ノルツ株式会社代表・原本）
テストで見えた3つのこと
- トークンの消費量が、当初の想定より大きかった
- Claudeには5時間ごとの利用量の制限があり、企業数を増やすとその制限にかかってしまう
- 結果として「同時に対応できるお客様の数」に上限があることが具体的に見えた
これが分かったのは、お客様に「テストをさせてください」とお願いして何件か動かしたからでした。原本は現在、5時間ごとの利用制限にかからないやり方へ改善を進めています（本記事執筆時点では進行中の取り組みで、設計の作り直しは完了していません）。
なお、本記事に記した「5時間ごとの制限」は、原本が利用していた環境で起きたこととして読んでください（原本の発言ではプラン名は特定されていません）。AIツールの利用量に関する条件や仕様は変更されることがあるため、導入を検討する場合は、提供元であるAnthropicの公式ヘルプセンターで最新の内容を必ず確認してください（本記事の記載は2026年9月時点のものです）。
新規事業のテストはどんな手順で進めればいい？
原本が実際に踏んだ流れは、発想→テストのお願い→少数で実施→反応と制約の記録→設計の見直し、の5段階です。完璧に作り込む前に人に使ってもらう順番にすることが要点で、テストの目的は売上ではなく「上限と反応の把握」に置いています。
原本が自社の新規事業（AI自動化サービス）で踏んだ手順を、そのまま整理したものです。特別な仕組みは使っていません。
- 発想を1つに絞る：「AIで自動化した業務そのものをサービスとして売る」という形で、新規事業を1個に絞ってスタートした
- 最小限の形で動かせるようにする：Claudeのスケジュール機能を使って、業務が回る設定を組む
- お客様にテストをお願いする：「テストをさせてください」と伝え、何件かテストを実施する（原本は具体的な件数を明らかにしていないため、本記事でも「何件か」という範囲でのみ記載する）
- 反応と制約を見る：お客様の反応だけでなく、トークン消費量や同時に対応できるお客様の数といった数量面も確認する
- 制約に合わせて設計を見直す：5時間ごとの利用制限にかからないやり方へ改善する（原本は現在この段階で、進行中）
テストで見るべきは「反応」と「上限」の2軸
原本の経験では、テストで確認できたものは大きく2つに分かれました。ひとつはお客様がどういう反応をするかという定性面。もうひとつは、どこまで数を増やせるかという定量面です。原本の場合、定量面のほうに想定外があり、そこが本格提供前に見えたことが収穫でした。
テストせずに本格提供した場合と、小さく試した場合は何が違う？
違いが出るのは、問題に気づくタイミングです。原本のケースでは、テスト段階で利用制限に気づけたため、本格提供の前に設計を見直す段階に戻ることができました（改善は現在進行中です）。テストをしなかった場合の展開については、原本は実際に試していないため事実として比較はできません。
まず、原本が実際に経験した「お客様に頼んで小さくテストした側」で分かったことだけを整理します。テストをせずに本格提供へ進んだ場合の展開は原本が経験していないため、表には入れず、後段で「想像である」と明記して分けました。
| 観点 | お客様に頼んで小さくテストした結果（原本が実際に経験したこと） |
|---|---|
| 問題が見えたタイミング | 本格提供の前（何件かのテストの段階で気づいた） |
| 見えてきた情報 | トークン消費量と、同時に対応できるお客様の数の上限 |
| 直すときの状況 | 設計を見直す段階に戻れた（改善は進行中） |
| お客様への伝え方 | 「テストをさせてください」と検証段階であることを最初に共有できた |
| 表の位置づけ | 原本の1つの事業での経験であり、すべての事業に当てはまる一般則ではない |
テストしなかった場合に想定されるリスク（原本の想像。未経験のため実測なし）
以下は原本が実際に通っていない道であり、検証された比較データではありません。想像として読んでください。
- お客様が増えたあとに同じ制約にぶつかり、稼働中の運用を続けながら直すことになるかもしれない
- 制約が「提供品質の低下」という形で表面化してから気づくかもしれない
- 完成品として提供した前提になるため、途中で設計を変えにくくなるかもしれない
テストは「先に制約とぶつかっておく」ための手段
原本は、AI自動化サービスのトークン消費という想定外を、テスト段階で引き当てました。企業数を増やしてから同じ制約にぶつかっていたらどうなっていたかは実際には分かりませんが、少なくとも本格提供の前に気づけたことで、いまは設計を見直す時間を取れています。
「お客様が増えても成り立つか」はテスト前にどう確認する？
原本は、テストと同時に「スケールした場合にこの事業はちゃんと回るのか」という問いを毎回立てることを勧めています。理想は実行前にこの問いを立てることですが、原本自身はテストを実施した段階で初めて上限に気づきました。
「結局事業を一人社長で事業をやるとき、リソースとの戦いになります。なので、この事業がスケールした場合にちゃんと回るのか、っていうところをね、あの問いを毎回立てるようにするといいんじゃないかなというふうに思っております。」（ノルツ株式会社代表・原本）
原本のケースでは、テストを実施した段階で、トークン消費量と5時間ごとの利用制限による「同時に対応できるお客様の数」の上限に気づきました。設計時点でどこまで想定していたかについては、原本自身は明確に語っていません。
スケール前に確認したいチェック項目（編集部整理）
原本の発言に基づくのは「この事業がスケールした場合にちゃんと回るのか、という問いを毎回立てる」という一点です。以下は、その問いを実務で具体化するために編集部で整理した一般的な確認項目で、原本が当時使っていたチェックリストではありません。
- お客様が1件のときと増えたときで、使うツールの消費量はどれだけ変わるか
- 使っているツールに、時間あたり・期間あたりの利用制限はあるか（原本のケースではClaudeの5時間ごとの利用量制限が該当した）
- その制限にかかるのは、お客様が何件になったときか
- 制限にかかったとき、自分の作業時間で埋める運用になっていないか
- お客様が増えたときに増えるコストは、料金の中に収まっているか
上のような項目を1枚のメモにして事前に埋めるだけでも、テストで確認すべきポイントは整理しやすくなります。
この観点は、AIを使うサービスに限りません。「お客様が増えたときに何が先に詰まるのか」を特定しておくことは、事業計画・収支計画を現実的な数字に落とすうえでも役立ちます。
一人社長がリソースを割かずに提供できる事業とは？
原本は、一人社長は自分のリソースをあまり割かなくても提供できるビジネスモデルが望ましいと考えています。例として挙げているのは、つなぐだけで成立する営業代行、紹介するだけで成立する採用代行、そして近年選択肢として増えてきたAIによる業務効率化・自動化です。
一人で独立すると、サービス提供だけでなく営業、経理財務処理まで自分の時間が割かれます。原本が新規事業の入口として「AIで自動化した業務をそのまま売る」という発想に至ったのは、この構造から来ています。
モデル例と一般的な留意点
「モデル」列の3つは原本が例として挙げたものです。「留意点」列は原本の発言ではなく、編集部が一般的な観点として補ったものです。ただしAIの行に記した「原本はここで詰まった」という部分のみ、原本の実体験です。
| モデル（原本が挙げた例） | 自分がやること | 留意点（編集部による一般的な整理） |
|---|---|---|
| 営業代行 | つなぐ | つなぐ相手がいることが前提になる |
| 採用代行 | 紹介する | 紹介先・紹介元との関係づくりが前提になる |
| AIによる業務効率化・自動化 | 仕組みを設計し、動かす | ツール側の利用制限やコストが上限になり得る（この点で原本はここで詰まった＝原本の実体験） |
「自分の時間を使わない設計」は、そのままでは魅力的に見えます。ただ原本の体験では、自分の時間の代わりにツールの制限がボトルネックになりました。何を自分の代わりに働かせるにしても、その代わりの部分に上限があるかどうかを先に見ておく必要があると感じています。
迷ったら、テストの設計から一緒に考える
ノルツの起業支援では、新規事業のアイデアをどう小さくテストするか、テストで何を見るか、スケールしたときに成り立つのかという問いの立て方まで、月額顧問型で毎月伴走しています。相談はLINE、またはサイトのお問い合わせフォームから受け付けています。詳細はノルツの起業支援をご覧ください。
よくある質問
新規事業のテストは何件くらいやればいい？
件数の正解はありません。ノルツ株式会社代表・原本のケースでは、お客様に「テストをさせてください」とお願いして何件かテストを行いました（原本は具体的な件数を明らかにしていないため、ここでも「何件か」という表現にとどめます）。その中で、トークン消費量や同時に対応できるお客様の数の上限が見えてきました。（以下は編集部の一般的な整理）件数そのものより、テストから制約が見えるかどうかに目を向ける考え方もあります。
未完成のサービスをお客様に見せるのは失礼にならない？
原本は「テストをさせてください」と、検証段階であることを伝えてお願いしました。完成品として提供するのではなく、テスト段階であることを最初に共有して協力を仰ぐ形です。原本の場合、この伝え方でお客様に協力していただき、何件かテストを実施できました。
テストで問題が見つかったら、その事業はやめるべき？
必ずやめる必要はありません。原本の新規事業では、Claudeの5時間ごとの利用量制限にかかってしまうという問題が見つかりましたが、現在は制限にかからないやり方へ改善を進めています（進行中で、完了はしていません）。テストの目的は合否判定ではなく、どこを直せば成り立つのかを特定することにあります。
AIツールを使ったサービスを設計するとき、最初に確認すべきことは？
利用量やレート（時間あたり）の制限があるか、そしてお客様が何件になったときにその制限にかかるかを確認しておくことです。原本のケースでは、テストを実施した段階で初めて、トークン消費量と5時間ごとの利用制限による上限に気づきました。AIツールの仕様や利用量に関する条件は変更されることがあるため、導入前に提供元の公式情報で最新の内容を確認してください（本記事の記載は2026年9月時点のものです）。
「スケールしても成り立つか」はいつ考えるのが理想？
原本は、テストと同時に、できれば実行する前の段階でこの問いを立てるのが理想だと話しています。一人社長の事業はリソースとの戦いになるため、「この事業がスケールした場合にちゃんと回るのか」という問いを毎回立てておくとよい、というのが原本の考えです。
参考・出典
- Anthropic ヘルプセンター（Claudeの利用量・プランに関する提供元の公式情報。最新の仕様確認先）（2026年9月時点（公開前に記載内容の確認を推奨））
ノルツの起業支援について
ノルツの起業支援では、代表・原本が自身の実体験をもとに、創業期の意思決定に月額顧問型で伴走します。「何から始めればいいか分からない」段階でも大丈夫です。まずはLINEからお気軽にご相談ください。