エグゼクティブ・サマリー
- RaaSは値付けの話ではなく、事業構造の話である。 売り切りからRaaSへ移すと、収益は平準化する一方で、資産・保守・稼働管理の負担が提供側に移る。この三点を同時に設計しないと、契約が増えるほど資金が枯れる。
- 最初に置くべきはP/Lではなく「1台のユニットエコノミクス」である。 機器原価・設置費・保守原価・撤去費を1台に集約し、月額から回収期間を出す。この1枚がないRaaS事業計画は、ほぼ例外なく途中で破綻する。
- キャッシュの谷は事業計画の中心論点である。 導入が伸びるほど先行支出が積み上がるため、成長そのものが資金を食う。誰が資産を持つか(自社/リース会社/ファンド)の設計は、価格設計より先に決めるべき論点である。
- 収益を決める変数は三つしかない——稼働率・解約率・保守原価。 月額単価をいくら上げても、この三つが崩れれば回収は成立しない。逆にこの三つが安定すれば、単価は市場水準で十分戦える。
- RaaSの本当の差別化は「止まらないこと」である。 顧客が払い続ける理由は機能ではなく、現場が回り続けている事実にある。定着支援と遠隔監視は、コストではなく解約率を下げる投資として設計する。
RaaSは「売り方」ではなく「事業構造」の変更である
ロボットの提供側でRaaS(Robot as a Service)を検討する動機は、たいてい二つに集約される。一つは、顧客側の初期投資の壁が高く商談が止まるため、月額にして入口を下げたいというもの。もう一つは、単発の受注に依存した収益を平準化し、ストック収益を積み上げたいというものである。どちらも正しい動機だが、この二つだけを見てRaaSを始めると、ほぼ確実に同じ場所でつまずく。
つまずくのは、売り切りでは顧客側にあった三つの負担——初期投資、稼働責任、保守責任——が、月額にした瞬間すべて提供側に移るからである。売り切りなら、納品して検収が通れば代金は回収でき、その後にロボットが止まっても保守契約の範囲で対応すればよい。RaaSでは、ロボットが止まっている間も設備の資金負担は提供側に残り、月額の請求は続けにくく、解約の理由になる。つまりRaaSは、「収益モデル」だけを差し替える施策ではなく、収益・資産・原価の三つを同時に組み替える事業構造の変更である。
本稿は、RaaSを提供する側——メーカー、SIer、商社、運用事業者、あるいはこれから事業を立ち上げる企業——に向けて、その構造をどう設計するかを扱う。調達する側から見た「購入かRaaSか」の判断軸は購入かRaaSか——ロボット調達方式の選び方で、受託を主体とするSIer事業の収益構造はロボットSIerという事業で扱っているため、本稿では提供側の事業設計に絞る。
1. 三つの負担がどこへ移るか
RaaSに移行したときに何が起きるかを、負担の移動として整理しておく。ここを曖昧にしたまま月額を決めると、月額の水準が「顧客が受け入れやすい額」で決まってしまい、原価の実態と切り離される。
| 負担 | 売り切り | RaaS | 提供側が新たに負う設計課題 |
|---|---|---|---|
| 初期投資 | 顧客が支払う | 提供側が立て替える | 回収期間、資金調達、キャッシュの谷 |
| 資産保有 | 顧客の資産 | 提供側またはファイナンス会社 | バランスシート、残価、中古再配置 |
| 稼働責任 | 顧客の運用範囲 | 実質的に提供側 | 遠隔監視、駆けつけ体制、SLA |
| 保守原価 | 保守契約で個別請求 | 月額に内包されがち | 部品費、出動費、予防保全の設計 |
| 撤去・回収 | 想定外 | 解約のたびに発生 | 撤去費、再整備費、再販路 |
| 需要変動 | 顧客が吸収 | 提供側が吸収 | 稼働率、繁閑差、機種の入れ替え |
この表で重要なのは右列である。売り切りでは存在しなかった業務——遠隔監視、再整備、再配置、撤去——が、RaaSでは恒常的な業務として発生する。これらは組織にとって新しい機能であり、既存の営業・エンジニアリング体制に追加で乗せると、必ず現場が疲弊する。RaaS事業の立ち上げが失敗するとき、その原因は価格設計ではなく、この新しい機能を誰が担うかを決めていなかったことにあることが多い。
2. 1台のユニットエコノミクスを置く
RaaS事業計画の中心は、全社P/Lでも年度売上計画でもない。1台あたりのユニットエコノミクスである。これを置かずに「3年で500台」といった台数計画から入ると、台数が伸びるほど赤字が深くなる計画ができあがる。
置き方は単純で、1台に紐づくすべての支出を契約期間で並べ、月額収入と突き合わせるだけである。以下は構造を示すための仮の数値であり、実機の価格帯や現場条件によって当然変わる。自社の数字を入れて置き直してほしい。
| 項目 | 区分 | 金額(例) | 発生タイミング |
|---|---|---|---|
| 機器原価 | 先行支出 | 6,000千円 | 導入時 |
| 設置・立ち上げ工数 | 先行支出 | 1,200千円 | 導入時 |
| ティーチング・調整 | 先行支出 | 800千円 | 導入時 |
| 先行支出 合計 | — | 8,000千円 | — |
| 月額収入 | 収入 | 250千円/月 | 毎月 |
| 保守・部品費 | 月次原価 | 40千円/月 | 毎月 |
| 遠隔監視・サポート | 月次原価 | 25千円/月 | 毎月 |
| 出動対応(平準化後) | 月次原価 | 20千円/月 | 毎月 |
| 月次粗利 | — | 165千円/月 | — |
| 単純回収期間 | — | 約49ヶ月 | — |
| 撤去・再整備費 | 期末支出 | 600千円 | 解約時 |
この例では、先行支出8,000千円を月次粗利165千円で回収するのに約49ヶ月、つまり4年強かかる。ここに撤去・再整備費が乗るため、実質的な損益分岐は5年契約でようやく成立する水準である。RaaS事業が「3年契約で回る」と直感的に思われがちなのに実際は苦しくなるのは、この計算を1台単位で置いていないためである。
ユニットエコノミクスを置いたら、次の四つを必ず確認する。
- 回収期間が契約期間に収まっているか。 収まっていなければ、その事業は契約更新を前提にした賭けになる。更新率の前提を明示せずに計画に織り込んではいけない。
- 月次粗利率は何%か。 保守・監視・出動を含めた後の粗利率が5割を切ると、解約が数件出ただけでポートフォリオ全体が沈む。
- 先行支出のうち、どこが圧縮可能か。 多くの場合、機器原価より設置・ティーチング工数のほうが圧縮余地が大きい。標準化とティーチングレス化がRaaS事業の粗利に直結するのはこのためである。
- 撤去後の機体をどう扱うか。 再整備して次の顧客へ回せるなら残価が立つ。回せないなら全損として計上すべきである。
3. キャッシュの谷——成長が資金を食う
ユニットエコノミクスが成立していても、RaaS事業には固有の資金問題がある。導入1台ごとに先行支出が出て、回収は数年かけて細く戻ってくるため、導入が伸びるほど資金繰りは悪化する。売れば売るほど現金が減る、という売り切り事業では起こらない現象が起きる。
このキャッシュの谷は、次の三つで規定される。1台あたり先行支出、月次の新規導入台数、回収期間。仮に先行支出8,000千円・月次粗利165千円で、毎月3台ずつ導入していくと、先行支出は月24,000千円ずつ積み上がる一方、回収は既存台数の累積分しか戻らない。単純化すると、累積導入台数が回収期間(49ヶ月)×月次導入ペースに達するまで、キャッシュフローは負のまま推移する。この谷の深さと期間を事前に数字で出し、そのぶんの資金をどう手当てするかを決めておくことが、RaaS事業計画の実質的な骨格である。
打ち手は大きく三つある。
一つ目は、初期費用を分離することである。 設置・ティーチング費用だけを一時金として受け取り、機器分のみを月額にする。顧客の初期投資の壁を下げる目的は保ちながら、先行支出の3〜4割を導入時に回収できる。実務上、最も現実的で最初に検討すべき手である。
二つ目は、契約期間を実態に合わせることである。 回収期間が49ヶ月なら、3年契約ではなく5年契約を基本形に置く。短期契約を出すなら、その分は月額に上乗せするか、中途解約時の残債精算条項を明示する。ここを曖昧にしたまま短期契約を安く売ると、解約が出るたびに損失が確定する。
三つ目は、資産を自社で持たないことである。 これは次節で扱う。
4. 誰が資産を持つか——三つのスキーム
RaaSにおいて、機体という資産を誰のバランスシートに置くかは、価格設計より先に決めるべき論点である。選択肢は実務上おおむね三つに整理できる。
| スキーム | 資産の所在 | 提供側の資金負担 | 提供側の利益率 | 向く局面 |
|---|---|---|---|---|
| 自社保有型 | 提供側 | 大きい | 高い | 実績が出て、資金余力がある段階 |
| リース会社介在型 | リース会社 | 小さい | 中程度 | 立ち上げ期。与信は顧客側に依存 |
| ファンド・SPC型 | 別会社 | 小さい | 中〜低 | 台数規模が見え、標準化が進んだ段階 |
立ち上げ期にありがちな失敗は、自社保有型で始めてしまうことである。実績のない段階では台数が読めず、稼働率も解約率も実測値がない。そこへ資産を自社で抱えると、想定が外れたときに退路がなくなる。最初の10〜30台はリース会社を介在させ、稼働率・解約率・保守原価の実測値を取る。数字が固まってから、利益率の高い自社保有型へ移す——この順序のほうが安全である。
リース会社介在型で注意すべきは、与信が顧客側に立つ場合、顧客の信用力によって成約可否が決まる点である。中小事業者を主要顧客に想定しているなら、この方式だけでは商談が通らない層が残る。その層をどう扱うかは、事業計画の対象顧客定義そのものに跳ね返る。
5. 収益を決める三変数——稼働率・解約率・保守原価
RaaS事業の損益は、突き詰めると三つの変数で決まる。月額単価はその次である。
稼働率は、機体が実際に価値を出している時間の比率である。ここが下がると、顧客は「払っている割に動いていない」と感じ、更新時に必ず論点化する。稼働率を提供側が可視化できていないと、この議論は顧客の体感で進み、値引き交渉になる。稼働・停止・停止理由を機体側で取得し、月次レポートとして提示できる状態をつくることが、価格を守る最も確実な手段である。指標の設計はロボット導入のKPI設計、データの取り方はロボットデータ基盤を参照されたい。
解約率は、RaaSの事業価値をそのまま規定する。回収期間が契約期間に近い事業では、解約1件の損失は新規1件の利益を大きく上回る。したがってRaaS事業における最重要の営業活動は、新規開拓ではなく既存顧客の稼働維持である。ここを営業組織の評価指標に入れていないRaaS事業は、構造的に解約が増える。
解約の理由は、故障そのものよりも「現場が使いこなせないまま止まった」であることが多い。導入後の定着に何が要るかは導入後の定着化と運用設計で扱ったとおりで、RaaSではこの定着支援が善意のサービスではなく、解約率を下げるための収益防衛投資になる。位置づけを変えれば、投じるべき工数の判断も変わる。
保守原価は、月額に内包した瞬間に上振れリスクが提供側へ移る。売り切り+保守契約なら、部品交換は都度請求できた。RaaSでは月額に含まれているのが通例で、想定外の故障が続けば粗利が直接削られる。対策は予防保全に寄せることであり、事後対応から予知・予防へ移す設計は予知保全とロボットの保守運用で扱っている。RaaS事業では、予防保全は品質施策ではなく原価施策である。
6. 月額に何を含め、何を外すか
月額の設計で最も揉めるのは、金額の水準ではなく含有範囲である。ここを曖昧にすると、契約後に「これは含まれているはずだ」という認識差が生まれ、無償対応が積み上がって粗利が消える。含める・外すの線引きは、次の基準で引くとよい。
含めるべきものは、発生頻度が読めて、提供側の努力で減らせるものである。定期点検、消耗品交換、遠隔監視、ソフトウェア更新、稼働レポート。これらは原価が平準化でき、しかも提供側が予防保全で削減できる。含めることで顧客の安心感を高めつつ、原価は自社努力で下げられる。
外すべきものは、発生頻度が読めず、顧客側の行動に左右されるものである。顧客都合による設置場所の変更、作業内容変更に伴う再ティーチング、顧客の過失・環境起因による破損、周辺設備の改修。これらを月額に含めると、原価が顧客の行動次第で青天井になる。別途見積の対象として、契約書に例示付きで明記する。
判断が割れるのが出動対応である。 完全に含めると遠方顧客で赤字化し、完全に外すと顧客の不満が解約に直結する。実務的には「年間◯回まで無償、超過分は別途」という上限付きで含めるのが折り合いやすい。回数上限を置くことは、顧客にとっても自社の使い方を見直す動機になる。
7. データを収益に変える——ただし順序を間違えない
RaaS事業の議論では、稼働データを蓄積して新たな収益源にするという構想がしばしば語られる。方向としては正しいが、順序を間違えると投資だけが先行する。
データが収益になる経路は、実際には次の順で現れる。第一に、自社の原価が下がる。故障の予兆を掴めれば出動が減り、部品在庫が最適化される。ここが最も確実で、最初に取りに行くべき効果である。第二に、解約率が下がる。稼働実績を可視化して顧客に返せば、投資対効果の説明が顧客社内で通りやすくなり、更新が取りやすくなる。第三に、ようやくデータそのものの外販や新サービスが視野に入る。
多くのRaaS事業構想は第三から入ろうとして頓挫する。第一と第二は自社の意思だけで実現でき、しかも効果が数字で確認できる。まずここを取り、蓄積が十分になってから第三を検討するのが順当である。
8. 立ち上げ24ヶ月のロードマップ
RaaS事業の立ち上げを、実行順で並べる。台数を追うのは最後である。
| 期間 | 主眼 | 主な成果物 | 判断ポイント |
|---|---|---|---|
| 0〜3ヶ月 | 事業設計 | ユニットエコノミクス表、キャッシュフロー計画、対象顧客定義 | 回収期間が契約期間に収まるか |
| 3〜6ヶ月 | 契約とスキーム | 契約書雛形、SLA、含有範囲の線引き、資産スキームの決定 | 中途解約・撤去・データ帰属を明記したか |
| 6〜12ヶ月 | 初期導入10台 | 稼働率・解約率・保守原価の実測値、遠隔監視の運用開始 | 実測値が計画前提と乖離していないか |
| 12〜18ヶ月 | 原価の作り込み | 予防保全の運用、設置・ティーチングの標準化、再整備フローの確立 | 先行支出と月次原価が下がったか |
| 18〜24ヶ月 | 拡大 | 資産スキームの切り替え、台数拡大、稼働レポートの標準提供 | キャッシュの谷を越える手当てができているか |
この順序で外してはならないのは、6〜12ヶ月の実測値を取る前に台数を追わないことである。稼働率・解約率・保守原価の三つは、机上の想定と実測が最もずれる項目であり、しかもずれた状態で台数を伸ばすと損失が台数に比例して拡大する。10台の実測で計画を作り直してから拡大する。この一段を飛ばした事業が、後から立て直すのは難しい。
9. 立ち上げ前チェックリスト
自社のRaaS構想が実行段階に耐えるかを、次の項目で点検してほしい。「未定」が三つ以上あれば、まだ台数計画を作る段階ではない。
- 1台あたりの先行支出(機器・設置・ティーチング)を金額で置いているか
- 月次原価に、保守・部品・遠隔監視・出動を分けて入れているか
- 回収期間を月数で出し、契約期間と比較したか
- 撤去・再整備費を計上し、機体の再配置可否を判断したか
- キャッシュの谷の深さ(最大累積マイナス)を月次で試算したか
- 資産を誰が持つかを決め、立ち上げ期と拡大期で分けて設計したか
- 月額の含有範囲を、含める/外す/上限付きの三分類で文書化したか
- 中途解約時の残債精算、撤去責任、データ帰属を契約書に書いたか
- 稼働率・解約率・保守原価の三指標を、誰がいつ見るか決めたか
- 定着支援を、コストではなく解約率を下げる投資として予算化したか
- 遠隔監視と駆けつけを、既存組織の兼務ではなく担当を決めて配置したか
- 最初の10台で計画を作り直す、という前提を経営として合意しているか
まとめ
RaaSは、顧客の初期投資の壁を下げる有効な手段であり、提供側にとってもストック収益を積む合理的な選択肢である。しかしそれは、収益・資産・原価の三つを同時に組み替えるという前提に立ったときに限られる。月額に置き換えるだけの発想で始めると、負担だけが提供側に移り、成長が資金を食う構造ができあがる。
出発点は1台のユニットエコノミクスであり、次にキャッシュの谷の手当て、そして稼働率・解約率・保守原価という三変数の実測である。台数はその後についてくる。逆順にした事業は、ほぼ例外なく同じ場所でつまずいてきた。
そして、RaaS事業の設計は一社では閉じない。機体を出すメーカー、現場を組むSIer、資産を持つファイナンス、日々動かす運用事業者、そして使う側のユーザー企業——この当事者が同じ設計を共有していないと、契約書の文言だけが厚くなり、実務は回らない。
RobiZyは、ユーザー企業・メーカー・SIer・運用事業者・自治体・大学が同じテーブルに着くNPO法人の会員組織である。ロボットを売らない中立の立場だからこそ、事業モデルの設計や契約条件の相場感、他社が実際にどこでつまずいたかといった、通常は社外に出てこない情報が行き交う場になっている。RaaS事業をこれから立ち上げる企業にとっても、既存事業を組み替えようとしている企業にとっても、当事者が一堂に会する場は判断の速度を大きく変える。関心のある方は、正会員としての参加をご検討いただきたい。