SaaS開発とは？受託開発・パッケージとの違い

SaaS開発とは、1つのソフトウェアを自社で持ち続け、インターネット経由で複数の顧客に月額などで提供するための開発です。

SaaSはSoftware as a Serviceの略で、利用者はソフトウェアを買ったり自社のサーバーに入れたりせず、ブラウザやアプリから使います。

総務省「令和6年通信利用動向調査」では、クラウドサービスを利用している企業は8割を超えています（2024年8月末時点、2025年5月30日公表）。使う側に広がった今、自社の業務ノウハウや既存システムをSaaSとして提供したいという相談も増えています。

⇒　900件以上の構築実績から生まれた『型』でリスクを抑える。AI駆動セルフ開発ツール『S-MASE』の詳細を見る

SaaSは「納品して終わり」ではなく「提供し続ける」事業

SaaSを提供する側は、ソフトウェアを作るだけでなく、動かし続ける責任を負います。たとえるなら、受託開発は注文住宅を建てて施主に引き渡す仕事で、SaaSは賃貸マンションを建てて自ら管理する仕事です。建物の持ち主は自社で、入居者（顧客企業）は複数いて、設備の点検や修理も自社が担います。

そのため、SaaSの収益は売り切りではなく、使われ続けることで積み上がります。開発費を回収できるかどうかは、リリース後に解約されずに使われ続けるかで決まります。

受託開発・パッケージ・SaaSを比べる

3つの違いは、ソフトウェアの持ち主、収益の形、リリース後の運用を誰が担うかに表れます。

比べる点	受託開発	パッケージ	SaaS
ソフトウェアの持ち主	発注した企業	開発元（利用者はライセンスを購入）	開発元（提供者）
利用する顧客	発注した1社	購入した複数の企業	契約した複数の企業
収益の形	開発費（一括が多い）	ライセンス料＋保守料	月額・年額などの利用料
サーバーと運用	発注企業（または委託先）	購入した企業	提供者
機能の改善	発注企業が依頼したとき	新しい版の発売時	提供者が継続して行う

この記事は、SaaSを「提供する側」の視点で解説します。社内で使う業務アプリを作るか、既存のSaaSを使うかで迷っている場合は、「【完全ガイド】業務アプリ開発とは？手法の選び方と失敗しない進め方」をご覧ください。

SaaSに必要な機能：業務機能の外側にある「提供のための機能」

提供し続ける仕組みが前提になる分、SaaSには、顧客が使う業務機能のほかに、提供するための機能が必要です。企画の段階では業務機能に目が向きがちですが、費用と期間を大きく左右するのは提供のための機能です。

認証・権限とテナント分離

認証は、利用者が本人かどうかを確かめる仕組みです。法人向けのSaaSでは、ログインに加えて「管理者」「一般の利用者」などの権限の違いや、顧客企業ごとの利用者の追加・削除が求められます。

テナント分離とは、1つのシステムを複数の顧客企業で使いながら、ある企業のデータが別の企業から見えないように分ける仕組みです。賃貸マンションでいえば、各部屋の鍵にあたります。後から作り直すと影響が大きいため、最初の設計で方式を決めておく必要があります。

料金プラン・課金・請求

SaaSでは、プランごとに使える機能や人数を変え、毎月の利用料を請求します。必要になるのは、プランの管理、カードや請求書での支払い、無料期間から有料への切り替え、プラン変更や解約の処理です。

課金は売上に直結するうえ、間違いがあると顧客の信頼を損ねます。外部の決済サービスを使って作る部分を減らすことも、選択肢の1つです。

管理画面・問い合わせ対応・運用監視

提供者側には、顧客の契約状況や利用状況を確認する管理画面が必要です。あわせて、問い合わせを受ける窓口、障害が起きたときに気づく監視、誰がいつ何をしたかを記録する操作ログも欠かせません。

これらは顧客の目には触れにくい機能です。しかし、顧客が増えるほど手作業では回らなくなり、対応の遅れが解約につながります。

初回リリースで必須か、後回しにできるか

提供のための機能をすべて最初から作り込むと、リリースが遅れます。最初は顧客が少ないことを前提に、後から作り直しにくいものだけを最初から作り、手作業で代わりができるものは後に回すと考えると判断しやすくなります。

機能	初回リリースでの扱い	理由
認証・権限	最初から必要	安全に使ってもらう前提になる
テナント分離	最初から必要	後から方式を変えると作り直しが大きい
料金プラン・課金	最初は手作業や外部サービスで代用できる	顧客が少ないうちは請求書の発行でも回る
提供者向けの管理画面	最低限から始められる	顧客が増える前に段階的に足せる
操作ログ	最初から記録だけはしておく	過去の記録は後から作れない
運用監視	最初から必要	障害に気づけないと信頼を失う
細かな利用分析	後回しにできる	改善の段階で必要になる

SaaSの作り方3通りと選び方

必要な機能が見えてくると、次に決めるのは作り方です。作り方は「フルスクラッチ」「ノーコード・ローコード」「既存の型やAI駆動ツールを使う」の3通りに分けると比べやすくなります。アプリ開発全般の手法の違いは、親記事の「アプリ構築の費用・手法・期間を徹底比較」でも解説しています。

フルスクラッチ：自由度は高いが、提供の機能もすべて作る

フルスクラッチとは、設計からプログラムまでを一から作る方法です。業務の進め方が独特なSaaSや、ほかにない機能で勝負するSaaSでは、自由に作れることが強みになります。

その反面、認証・テナント分離・課金・管理画面といった提供のための機能も、すべて自社で作って運用することになります。費用と期間が最もかかりやすく、開発会社に頼む場合は、リリース後も改善を続けられる体制まで確認が必要です。

ノーコード・ローコード：早く出せるが、伸びたときの限界を確かめる

ノーコード・ローコードとは、プログラムをほとんど書かずに、画面の操作で仕組みを作る方法です。小さく早く出して、顧客の反応を確かめたい段階に向いています。

ただし、顧客企業ごとのデータの分け方、利用者が増えたときの処理の速さ、細かな課金の設定などは、ツールによって対応できる範囲が違います。顧客が増えたあとに別の作り方へ移すことになっても困らないかを、始める前に確かめておきます。

既存の型やAI駆動ツールを使う：検証と本開発を同じ流れで進める

3つ目は、すでにある型（よく使われる機能の組み合わせ）や、AIで仕組みを自動生成するツールを土台にする方法です。土台にある部分を作らずに済むため、事業として独自に作り込みたい部分に時間と費用を回せます。

カスタメディアプラットフォームのAI駆動セルフ開発ツール「S-MASE」は、900件以上の構築実績から生まれた型を使い、プロンプトからインフラ・データベース・画面を自動生成できます。お客様自身が開発を進め、カスタメディアが伴走する方式で、MVPでの検証を繰り返しながら本開発へつなげられます。開発期間は、ご発注後おおむね3〜6か月です。

判断の目安：独自性・期間・運用体制で選ぶ

3つの作り方は、どれが優れているかではなく、事業の状況で選びます。目安は、作りたい機能の独自性、リリースまでの期間、リリース後に運用と改善を担える体制の3点です。

なお、1つに決める必要はありません。たとえば、ノーコードで反応を確かめてから別の作り方で本開発に入る、といった組み合わせもあります。その場合は、検証で作ったものとデータをどこまで引き継げるかを先に確認しておきます。

導入事例：近鉄不動産「LaaS（ラース）」

複数の機能を、会員向けの1つのサービスとして提供している例です。カスタメディアの導入事例では、近鉄不動産株式会社が会員制コミュニティーサービス「LaaS（ラース）」を構築しました。

LaaSでは、習い事を教え合う「スキルマッチ」、個人で作った作品を売り買いできる「オープンマーケット」、会員価格でのレンタルスペース予約、住まいと暮らしの情報を、1つのサイトで提供しています。

マッチング、売り買い、予約という性質の違う機能を1つの会員サービスにまとめている点は、複数の機能を持つSaaSを企画するときの参考になります。詳しくは「近鉄不動産株式会社 / LaaS」をご覧ください。

SaaS開発の進め方

作り方を選んでも、いきなり完成形を目指すと、売れるかわからないものに多くの費用をかけることになります。SaaS開発は、小さく出して確かめ、使われ方を見ながら育てる流れで進めます。

課題と顧客を決め、MVPで確かめる

最初に決めるのは、誰のどの課題を解決するSaaSなのかです。業種、企業の規模、使う部署まで絞ると、必要な機能と料金の考え方が見えてきます。

次に、必要最小限の機能を持つMVP（Minimum Viable Product）を作り、実際の顧客に使ってもらいます。確かめたいのは「お金を払ってでも使い続けたいか」です。MVPの考え方は「MVP開発とは？PoC・プロトタイプとの違いと進め方」、技術的に作れるかを先に確かめたい場合は「PoC開発の進め方！失敗しない目的と成功基準の決め方」をご覧ください。

要件定義でSaaSならではの項目を決める

MVPで手応えが得られたら、本開発の要件を固めます。業務機能に加えて、SaaSでは次の項目を決めておく必要があります。

• 顧客企業ごとのデータの分け方（テナント分離の方式）
• 料金プランと、プランごとに使える機能・人数
• 稼働時間の目標や障害時の連絡方法（SLA）
• 利用規約、解約時のデータの扱い

要件定義の進め方そのものは「要件定義とは？進め方・決める項目・発注者の役割」で解説しています。

開発・リリース・改善を回す

開発が終わったら、最初は限られた顧客にリリースし、問い合わせや使われ方を見ながら直していきます。いきなり広く売り出すより、障害や使いにくい箇所を早い段階で見つけられます。

リリース後に機能を足し、直し続けることまでが、SaaS開発の範囲です。改善の担い手を誰にするかは、開発を始める前に決めておきます。

SaaS開発の費用と期間の考え方

進め方が長く続く分、SaaSの費用は「作る費用」だけでは見積もれません。費用は、リリースまでの初期費用と、提供を続ける間の継続費用に分けて考えます。

初期費用と継続費用を分けて見る

初期費用は、企画・設計・開発・テストにかかる費用です。継続費用には、サーバーや外部サービスの利用料、監視と障害対応、問い合わせ対応、機能の改善が含まれます。

受託開発では、納品後の費用は保守契約の範囲に限られることが多くあります。一方、SaaSでは改善を止めると競合に見劣りしていくため、継続費用も事業計画に入れておきます。

費用と期間を左右する要因

費用と期間は、主に業務機能の数と複雑さ、提供のための機能をどこまで作るか、作り方、求められるセキュリティの水準で変わります。たとえば、前の章の表で後回しにできる機能を初回から外すだけでも、初期費用は抑えやすくなります。

アプリ開発の費用の内訳と見積もりの見方は、「アプリ開発費用の相場・内訳・見積もりのポイント」で詳しく解説しています。

法人や政府に売るなら確認したい要件

費用の見通しが立っても、法人の顧客、特に大企業や政府機関に売る場合は、機能とは別の関門があります。導入の前に、提供者のセキュリティ対策や責任の範囲を確認されることが多いため、開発の段階から備えておきます。

総務省ガイドラインにある「責任分界」の考え方

総務省は、クラウドサービスを提供する事業者向けに「クラウドサービス提供における情報セキュリティ対策ガイドライン」を公表しています。2021年9月30日に公表された第3版では、責任分界の考え方の見直しと、国際規格との整合が図られました。

責任分界とは、セキュリティ対策のうち、どこまでを提供者が担い、どこからを利用企業が担うかを分けることです。賃貸マンションでいえば、建物の防犯設備は管理会社、部屋の鍵の管理は入居者、という分担にあたります。顧客から問われたときに答えられるよう、分担を文書にしておくと説明しやすくなります。

政府機関向けはISMAP／ISMAP-LIU

政府機関に提供する場合は、ISMAP（政府情報システムのためのセキュリティ評価制度）が関わります。デジタル庁によると、ISMAPは、政府が求めるセキュリティ要求を満たしているクラウドサービスをあらかじめ評価・登録し、政府のクラウドサービス調達におけるセキュリティ水準の確保を図る制度です。

SaaS向けには、ISMAP-LIUという仕組みもあります。対象は、機密性2情報を扱うSaaSのうち、リスクの小さな業務・情報の処理に用いるものです。外部監査の範囲が狭くなる一方、提供者は自ら行う内部監査の実施状況を報告する必要があります（デジタル庁「ISMAP-LIU」、2026年10月22日確認）。なお、自治体に提供する場合は、各団体の調達仕様で求められる基準を確認します。

顧客から確認されやすい項目

大企業や公的機関との商談では、契約の前にセキュリティに関する質問票が届くこともあります。次の項目は、開発の段階で答えを用意しておくと商談が進めやすくなります。

項目	確認されやすいこと
責任分界	提供者と利用企業が、それぞれどの対策を担うか
データの保管	保管する場所（国内か海外か）、バックアップの頻度
稼働と障害対応	稼働時間の目標、障害時の連絡方法と復旧の手順
権限と記録	利用者の権限の分け方、操作ログを残す期間
解約時の扱い	データの返却方法と、削除する時期
第三者の評価	ISMAP／ISMAP-LIUへの登録、ISO/IEC 27017（クラウドセキュリティの国際規格）などの認証

SaaS開発でよくある失敗と防ぎ方

ここまでの要件を押さえていても、進め方でつまずく例は少なくありません。失敗の多くは、作る前と作った後の判断を先送りしたことから起きます。

最初から機能を詰め込む

顧客の要望を聞くほど、機能を足したくなります。しかし、使われるかわからない機能まで初回に作ると、リリースが遅れ、費用も回収しにくくなります。MVPで確かめた課題に必要な機能に絞り、残りはリリース後の改善に回します。

課金と運用を後回しにする

業務機能が完成してから課金や問い合わせ対応を考え始めると、リリースの直前に大きな作業が残ります。手作業で代用する場合も、誰がどの手順で行うかは、リリースの前に決めておきます。

開発会社に任せきりにする

開発を外部に頼む場合でも、何をどの順で改善するかを決めるのは提供者自身です。仕様や設計の情報を社内に残さずに任せきりにすると、別の会社に移ることも、自社で手を入れることも難しくなります。この状態の防ぎ方は「ベンダーロックインとは？原因・リスクと抜け出し方をわかりやすく解説」で取り上げています。

自社開発か外注か：社内に残すべき役割

外部に頼むかどうかは、すべてを自社で作れるかではなく、どの役割を社内に残すかで判断します。

SaaSでは、顧客の声を聞いて何を作るかを決める役割、料金と契約を決める役割、開発の優先順位を決める役割は、事業そのものです。これらを社内に残したうえで、設計・開発・運用のどこを外部に頼むかを決めます。社内に技術者がいない場合でも、仕様の判断と進み具合の確認を担う担当者を置くことで、外部の会社と対等に進められます。

外部の会社との進め方は「ベンダーコントロールとは？丸投げにしない進め方と発注側の役割を解説」、依頼の流れと会社の選び方は「アプリ開発を依頼するには？費用相場・会社の選び方・失敗しない流れを解説」をご覧ください。

よくある質問

まとめ｜SaaS開発は「提供し続ける形」から逆算する

SaaS開発は、1つのソフトウェアを自社で持ち続け、複数の顧客に提供するための開発です。受託開発と違い、認証・テナント分離・課金・運用監視といった提供のための機能と、リリース後の改善までが開発の範囲に入ります。

作り方は、フルスクラッチ、ノーコード・ローコード、既存の型やAI駆動ツールの3通りから、機能の独自性・期間・運用体制で選びます。最初から作るものと後回しにするものを分け、小さく出して確かめながら育てることが、費用を抑えて事業を続ける近道です。法人の顧客に提供する場合は、責任分界やデータの扱いなど、商談で確認される項目も要件定義の段階で決めておきます。

SaaSの立ち上げを相談したい方へ

カスタメディアでは、自社サービスをSaaSとして提供したい企業に向けて、企画の整理からMVPでの検証、本開発、リリース後のグロースまでのご相談を承っています。AI駆動セルフ開発ツール「S-MASE」で検証を繰り返しながら開発を進め、その経験を本開発に生かす方法をご紹介します。

⇒　900件以上の構築実績から生まれた『型』でリスクを抑える。AI駆動セルフ開発ツール『S-MASE』の詳細を見る