こんにちは！株式会社雲海設計の技術部です。2026年4月に入り、弊社への相談で最も増えているカテゴリのひとつが「自社プロダクトをSaaSとして外販したいので、saas受託開発できる会社を探している」という依頼です。2025年までは「とりあえず業務システムをクラウドで作る」程度の解像度で済んでいましたが、2026年はAIエージェント時代の到来で「単発で作って終わるシステム」と「継続課金で育てるSaaS」の境目がはっきりし、発注側の意思決定も変わりました。
本記事では、saas受託開発の実態を、従来型の受託開発との違いという切り口で整理します。マルチテナント設計・契約と知財・収益モデルの3軸で、発注側が選定時に必ず確認すべき基準をコンサル視点でまとめました。
- saas受託開発は「一度納品して終わり」ではなく「継続運用・継続課金を前提に作る」設計思想が根本から違う
- 選定軸はマルチテナント設計力・契約と知財の分配・収益モデルとの整合の3点
- 契約形態は請負単発ではなく、準委任+レベニューシェア+SLAのハイブリッドが2026年の主流
- 技術的な地雷はテナント分離・権限モデル・ログと監査・課金基盤の4領域に集中
- 失敗の7割は「受託の感覚で見積もり、SaaSの感覚で運用した」ことに起因する
なぜ今「saas受託開発」の相談が急増しているのか？
結論から言うと、既存の業務システムや業界ノウハウをSaaSとして外販し、継続課金ビジネスに転換したいという経営判断が、中堅・中小企業まで一気に降りてきたからです。2025年までは大手SaaSベンダーの独壇場でしたが、2026年は業界特化・地域特化の垂直SaaSが勝ち筋として広く認知されました。
2026年に潮目を変えた3つの動き
第一に、Gartnerは2026年予測で「2028年までに新規エンタープライズソフトウェアの80%がマルチテナントSaaS形態で提供される」と指摘しており、オンプレや単一テナント前提の発注は投資回収が難しくなっています。第二に、生成AIとエージェントの台頭で「SaaS is dead」論争が活発化し、SaaSの設計思想そのものを見直す動きが強まりました(詳細はSaaS is deadはなぜ言われる？参照)。第三に、MIT Sloan Management Reviewの2025年レポートは、垂直SaaSのARR成長率が水平SaaSを上回るトレンドを指摘しており、業界知見を持つ事業会社がSaaS側に回る流れが加速しています。
「2026年以降のB2Bソフトウェア投資は、単発受託ではなく、継続提供を前提としたプラットフォーム投資として評価される。」— Gartner「Future of Software Engineering 2026」要旨
つまり、受託開発とSaaS受託開発は似て非なるものであり、同じ感覚で発注すると確実に事故ります。
従来の受託開発とsaas受託開発は何が違うのか？
結論は「成果物の定義」「運用責任の所在」「収益の流れ」の3つが構造的に違うという点です。ここを混同すると、見積もりも契約もスケジュールも全部ズレます。
3つの観点で違いを比較
| 観点 | 従来の受託開発 | saas受託開発 |
|---|---|---|
| 成果物 | 仕様通りのシステム一式 | 継続的に育つプロダクト |
| テナント | シングル(特定の発注者用) | マルチテナント前提 |
| 契約 | 請負・一括支払い | 準委任+継続運用+レベニューシェア |
| 知財 | 発注者に全帰属が多い | 共同保有 or ベンダー保有+ライセンス |
| 運用 | 納品後は発注者 or 保守契約 | ベンダーが継続運用・機能追加 |
| KPI | QCD(品質・コスト・納期) | ARR・解約率・NRR |
| 課金基盤 | 通常不要 | 必須(Stripe等の組込) |
特に見落とされがちなのが知財の扱いです。従来受託の感覚で「全部こちらに権利ください」と主張すると、ベンダー側は他社展開ができず開発費がそのまま請求されるため、見積もりが3倍に跳ね上がります。SaaSとして外販する以上、ソースコードはベンダー保有、発注者は独占利用権や優先販売権を取るという設計のほうが双方の経済合理性に合います。
関連して、見積もりが膨らむ構造的な理由は「見積もり3倍、納期2倍」になったシステム開発の犯人を探せでも触れていますので、合わせて読むと発注側の視点が固まります。
マルチテナント設計で発注側が確認すべきことは？
結論は「テナント分離の強度」「権限モデル」「データ越境」の3つです。ここが甘いとセキュリティインシデントが発生した瞬間、全顧客分の損害賠償を一気に背負うことになります。
テナント分離のレベルを必ず明文化する
マルチテナントには強度の異なる3パターンがあり、saas受託開発の見積もり・運用コスト・セキュリティ要件に直結します。
- 共有DB + tenant_id分離: コスト最安・開発速い・漏洩時の影響範囲が最大
- 共有DB + スキーマ分離: 中庸・顧客ごとのバックアップが取りやすい
- テナントごと専用DB/インフラ: 分離強度最高・運用コスト数倍・金融や医療向け
発注側は「どのレベルを採用するか、なぜそのレベルか」を必ずRFP段階で擦り合わせてください。「とりあえず安く」で1を選ぶと、後から金融系顧客を取る段階で3への再設計が必要になり、プロダクトを作り直す羽目になります。
権限モデル・監査ログは最初から入れる
SaaSは顧客企業の管理者・一般ユーザー・ベンダー側運用者・サポート担当など多層の権限が必要です。後付けは極めて困難なので、初期設計で以下は必ず盛り込みます。
- RBAC(ロールベースアクセス制御)の基盤
- 全操作の監査ログ(誰が・いつ・何をしたか)
- テナント管理者によるユーザー招待・SSO連携(SAML / OIDC)
- ベンダー側の「なりすまし支援」ログと顧客通知
より詳しい権限設計の実装論点はAIセキュリティ対策実装ガイド2026で扱っているので、技術担当者と併読してください。
契約と知財はどう設計すべきか？
結論から言うと、saas受託開発の契約は「初期開発フェーズ」「共同運用フェーズ」「外販フェーズ」の3段階で別契約にするのが2026年の実務トレンドです。1本の請負契約で済ませようとすると、運用責任と収益分配が曖昧になり必ず揉めます。
フェーズ別の推奨契約形態
| フェーズ | 契約形態 | 主な論点 |
|---|---|---|
| 初期開発(MVP構築) | 準委任 or ハイブリッド請負 | スコープ・マイルストーン・検収基準 |
| 共同運用(β〜正式リリース) | 準委任+SLA | 稼働率・インシデント対応・機能追加フロー |
| 外販(スケール期) | レベニューシェア or ライセンス | 売上分配率・知財帰属・競業避止 |
知財は「誰が外販できるか」で決める
知財帰属で揉めないコツは、「このプロダクトを他社に売れる権利を持つのは誰か」を契約で明確にすることです。実務では以下の3パターンが多く使われます。
- パターンA: 発注者完全保有型 — 開発費を全額負担する代わりに、ソースコードも販売権もすべて発注者。ベンダーは単なる開発会社として退場
- パターンB: 共同保有+独占ライセンス型 — ソースコードはベンダー保有、発注者は業界独占の販売権を得る。開発費は折半またはレベニューシェア
- パターンC: ベンダー保有+優先顧客型 — ベンダーがプロダクトを保有し、発注者は優先顧客として優遇条件+機能要望の優先反映権を持つ
どれが正解というより、発注者が「自社事業のコアにSaaS販売を据えるか、自社業務のDXが主目的か」で分岐します。前者ならA、後者ならCが経済合理的です。要件定義段階での認識齟齬を防ぐ方法は要件定義コミュニケーション設計術も参考になります。
収益モデルとプロダクト設計をどう整合させる？
結論は「課金単位と技術的な計測単位を一致させる」ことです。シート課金なのにユーザー単位の利用ログが取れない、従量課金なのにイベント計測がない、といった設計ミスはSaaSで頻発します。
主要な収益モデルと技術要件
| 収益モデル | 計測すべきメトリクス | 技術的実装ポイント |
|---|---|---|
| シート課金(月額×ユーザー数) | アクティブユーザー数 | ユーザー管理・SSO・休眠判定 |
| 従量課金(API呼び出し等) | イベント数・データ量 | メータリング基盤・集計ジョブ |
| ティア課金(プラン別機能差) | プラン別利用率 | Feature Flag・プラン制御 |
| レベニューシェア(売上連動) | GMV・取引金額 | 決済連携・月次精算処理 |
AI機能を組み込むSaaSでは、トークン消費量の可視化と原価管理が2026年の必須論点です。ここは生成AIの請求が読めない会社へで詳しく扱っています。
雲海設計の支援事例から見えた典型パターン
弊社が伴走したあるプロジェクトでは、発注側が当初「業務システムをそのままSaaS化したい」と希望されましたが、ヒアリングを進めると約7割の機能が特定顧客の業務フローに依存しており、そのまま外販するとカスタマイズ地獄に陥る構造でした。そこで以下のフェーズ分けで再設計しました。
- 自社利用MVP(3ヶ月): 発注者社内でのみ利用、請負契約
- β外販(6ヶ月): 3社限定でフィードバック収集、準委任+SLA
- 正式SaaS化(リリース後): 共同運用会社を設立、レベニューシェア
このように「SaaSにする前提のまま一気に作る」のではなく、段階的に外販可能性を検証するアプローチが、2026年のsaas受託開発では最も事故率が低いパターンです。
失敗する発注側の典型パターンは？
結論は「受託の感覚で発注し、SaaSの期待値で運用しようとする」ミスマッチです。具体的には以下の5つが典型です。
- 初期見積もりの安さだけで選定 — 継続運用コストを見ずに決め、リリース半年後にベンダーが離脱
- 「全部ウチの権利で」と主張 — ベンダーの外販モチベーションが消え、機能追加が止まる
- SLAを定めず準委任 — 稼働率責任が曖昧で、障害時の対応が後手に回る
- マルチテナント要件を後出し — シングルテナントで作った後に「他社にも売りたい」が発覚、再設計
- 課金基盤を自前実装 — Stripe等を使わず車輪の再発明、税制改正のたびに改修地獄
これらを避ける最大のコツは、「発注前に3社以上のsaas受託開発会社と話す」「技術顧問やITコンサルを1人挟む」ことです。自社内だけの判断では、SaaS特有の運用観点が必ず抜け落ちます。
よくある質問
Q. saas受託開発の費用相場はどのくらいですか？
A. MVPで1,500万〜4,000万円、β運用開始までに合計5,000万〜1億円程度が2026年の相場観です。ただし従来受託のような「一括見積もり」ではなく、フェーズごとの積み上げになります。レベニューシェア併用で初期費用を下げるパターンも増えています。
Q. 内製とsaas受託開発、どちらを選ぶべきですか？
A. SaaS化がコア事業なら内製、自社業務の延長で副次的にSaaS化するなら受託がおすすめです。内製は人材採用に1〜2年かかるため、市場投入スピードを重視するなら受託で立ち上げて段階的に内製化する「ハイブリッド」も有効です。
Q. マルチテナントとシングルテナント、最初はどちらで作るべき？
A. 外販の可能性が1%でもあるなら、最初からマルチテナント前提で作るべきです。後からの分離改修は事実上プロダクトの作り直しに近く、2〜3倍のコストがかかります。
Q. AIを組み込んだSaaSの受託開発で、特に気をつけるべきことは？
A. トークン原価の可視化と、顧客ごとの利用上限制御です。AI APIの費用がそのまま原価に乗るため、無制限プランは赤字リスクが高く、プラン別の上限設計が必須です。
Q. 契約書のひな形はありますか？
A. JISA(情報サービス産業協会)やIPAのモデル契約がベースになりますが、SaaS外販を含む場合は別途レベニューシェア条項・知財共有条項を追加する必要があります。弁護士とベンダーの両方に確認することをおすすめします。
雲海設計のsaas受託開発支援
株式会社雲海設計では、業界特化型SaaSの立ち上げから外販までを伴走する受託開発・コンサルティングを提供しています。マルチテナント設計、契約・知財設計、収益モデル設計、AI機能の組み込みまで、発注側の視点で一気通貫でご支援します。
- DXソリューション — 自社業務のSaaS化構想から実装まで
- ITコンサルティング — ベンダー選定・契約レビュー・技術顧問
- Web開発・デザイン — SaaSのフロントエンド・管理画面設計
「うちの業務ノウハウ、SaaSにできるだろうか？」という構想段階のご相談も歓迎です。お問い合わせはこちらからお気軽にどうぞ。