SaaS開発の流れと費用の考え方｜外注先の選び方と公開前の確認点

SaaS開発とは、ソフトウェアを自社のサーバーに入れて渡すのではなく、クラウド上で動かし、インターネット経由で多くの顧客に同じ仕組みで提供する前提で、企画から設計、実装、公開、運用までを行うことです。作って納品すれば終わる受託開発と違い、公開後の監視、更新、サポート、課金の管理までを事業として続けるのが特徴です。本記事では、SaaS開発の意味、開発の流れ、マルチテナントや課金などの設計、既存ソフトのSaaS化、費用の考え方、外注先の選び方、公開前に確認したい運用とセキュリティの項目を整理します。内容は、2026年10月22日時点の総務省・個人情報保護委員会・IPA・AWS・Microsoftなどの公開情報と、各サービスの商品ページにもとづきます。

目次

開く

閉じる

1. SaaS開発とは｜クラウド上で継続して提供するソフトウェアを作ること
2. SaaSを開発するメリットとデメリット
3. SaaS開発の流れ｜構想から運用までの8ステップ
4. SaaS開発の設計で先に決める4つのこと｜テナント・認証と個人データ・課金・技術選定
5. 既存のソフトウェアをSaaS化する場合の考え方
6. お手本にする既存SaaSの見方
7. SaaS開発の費用の考え方｜開発費と公開後の運用費に分けて見る
8. SaaS開発を外注する場合｜内製との分け方と、外注先を比べる5つの観点
9. SaaSを公開する前に確認する、提供者側の運用とセキュリティの項目
10. よくある質問(FAQ)
11. まとめ｜SaaS開発で押さえたい7つのこと
12. 参考文献

SaaS開発とは｜クラウド上で継続して提供するソフトウェアを作ること

SaaS開発とは、クラウド上で動かし、インターネット経由で多くの顧客に継続して提供することを前提に、ソフトウェアを企画、設計、実装、運用することです。

AWSのホワイトペーパー「SaaS Architecture Fundamentals」は、SaaSという言葉が事業の形と提供の形の両方を表すと説明しています(AWS「SaaS Architecture Fundamentals」)。つまりSaaS開発は、プログラムを作る作業だけでなく、料金の取り方、顧客の迎え入れ、障害への対応までを含めて設計する取り組みです。

開発の型	動かす場所と運用する人	更新の仕方
受託開発(特定の顧客向け)	発注した企業の環境、または指定された環境に納める。納品後の保守は契約で決める	顧客ごとに更新の時期と内容を調整する
パッケージ販売	利用者が自社の環境にインストールして使う	利用者が更新版を適用する
SaaS	事業者のクラウド環境で動かし、利用者はインターネット経由で使う	事業者が全利用者に同じ仕組みで更新を届ける

(一般的な整理の例です。実際の契約や製品によって異なります。)総務省「クラウドサービス提供における情報セキュリティ対策ガイドライン(第3版)」は、SaaSでは、クラウドサービス事業者がアプリケーション層以下の実装、設定、更新及び運用を管理し、利用者はアプリケーションで扱うデータの管理に責任を持つと整理しています(23頁)。PaaSでは事業者がミドルウェア層以下、IaaSでは仮想環境層以下を管理します(24-25頁)。作る側から見ると、SaaSは事業者が引き受ける範囲が最も広い提供形態です。

提供形態	事業者が管理する範囲	利用者が管理する範囲
SaaS	アプリケーション層以下の実装、設定、更新及び運用	アプリケーションで扱うデータの管理(限定的なアカウント管理の権限を持つ場合がある)
PaaS	ミドルウェア層以下の実装、設定、更新及び運用。データセンター内のネットワークも管理する	アプリケーションの開発と管理。提供されるセキュリティ機能の設定
IaaS	仮想環境層以下の実装、設定、更新及び運用。データセンター内のネットワークも管理する	OSを含む、仮想環境上で動くすべてのソフトウェアの管理

ASPという呼び方は、SaaSとほぼ同じ意味で使われる、SaaSを提供する事業者を指す、個別環境か共有環境かで違いを説明するなど、解説によって整理が分かれます。ASPやIaaS・PaaS、SIerとの関係はSaaSとASP・クラウドの違いで、SaaSそのものの意味と例はSaaSって何？で整理しています。

SaaSを作った側には、公開後に止めずに動かし続ける責任が残ります。同ガイドラインは、SaaS編の基本として、クラウドサービスの稼働監視、障害監視、パフォーマンス監視、セキュリティインシデント監視を行い、利用者に提供する時間帯と稼働率を定め、停止や異常を検知したら利用者に速報することを求めています(73頁)。夜間や休日も含めて、この監視を自社の開発担当だけで回せるかは、設計の前に考えておきたい点です。

AWS上でSaaSを動かす場合に、この監視と運用を外部に任せる選択肢の一例が、GMOグローバルサイン・ホールディングス株式会社のAWS監視・運用 マネージドクラウド for AWSです。商品ページでは、運用監視ツールをAmazon CloudWatch、Zabbix、Mackerelから選べることと、24時間365日の有人監視体制で人手不足や夜間・休日の対応に備えられることが、おすすめのポイントとして紹介されています(2026年10月22日確認)。注意点は、障害発生時の一次対応が手順書に沿った復旧を基本とすることで、自社の要件に合わせるオプションも用意されています。対象はAWSの環境で、料金はプランによって異なるため、資料や公式サイトで確認してください。

基本の要件は24時間365日の監視でしたが、CloudCREW の提案にはAWS認定資格をもったSEによるサポートを受けられるメニュー（※）がありました。

AWS事例(ジャスネットコミュニケーションズ株式会社。依頼の決め手として掲載) 出典：導入事例ページ

SaaSを開発するメリットとデメリット

SaaS開発のメリットは、継続課金による収益の見通しと、更新の一元管理で、デメリットは、投資の回収に時間がかかることと、公開後の運用とサポートが続くことです。

買い手の側でもSaaSの利用は広がっています。総務省の令和7年通信利用動向調査によると、クラウドサービスを一部でも利用している企業は83.5%、全社的に利用している企業は60.0%でした(総務省「令和7年通信利用動向調査の結果」)。この利用の広がりが、SaaSを作る事業の前提になっています。

メリット

1. 継続課金で収益を見込みやすい: 月額や年額で課金するため、契約が続く限り収益が積み上がります。SaaS開発の解説でも、継続的な収益が主なメリットとして挙げられています(TD SYNNEX「SaaS開発やSaaS化の手順を解説」)
2. 更新を一元管理できる: 事業者側のクラウドで動くため、機能の追加や修正を、すべての利用者に同じ形で届けられます
3. 小さく公開して改善できる: 機能を絞った最小限の製品で始め、フィードバックを集めながら繰り返し作る進め方と相性がよいとされています(Stripe「SaaS ビジネスを立ち上げる方法」)
4. 無料プランや試用から有料へつなげられる: 料金モデルの選択肢として、フリーミアムのように無料版で関心を引き、価値を感じた利用者に有料版へ移ってもらう形があります
5. 場所を限らず提供できる: インターネット経由で提供するため、地理的な制約を受けにくい形態です

デメリット

1. 投資の回収に時間がかかる: 初期の開発費を、月額料金で少しずつ回収する形になるため、回収期間が長くなりやすいと解説されています
2. 公開後も開発が続く: 解約を防ぐために、継続的な改善と更新が必要です
3. サポートの負担が大きい: 利用者からの質問や苦情に対応するプロセスを作ることが、総務省のガイドラインでもSaaS事業者の基本として求められています(63頁)
4. 止まったときの責任が事業者にある: 稼働率の目標や障害時の連絡を、SLAなどで利用者に示す必要があります
5. セキュリティと法令への対応が欠かせない: 多数の顧客のデータを預かるため、個人データの扱いや、設定の不備による事故への備えが必要です

SaaS開発の流れ｜構想から運用までの8ステップ

SaaS開発の流れは、課題と対象の決定、要件定義とMVPの絞り込み、設計、UI/UX設計、実装、テスト、リリース、運用と改善の8ステップで考えると進めやすくなります。

一般的な開発の解説は、要件定義からリリースまでを5段階前後で示すものが多く、SaaSでは、そのあとの運用と改善が事業の中心になります。次の表は、解説と総務省ガイドラインの項目をあわせて、8つのステップに整理したものです(整理の例です)。

ステップ	やること	確認のポイント
1. 課題と対象を決める	解決する課題と、使う人(業種、規模、役割)を決める	潜在ユーザーと話し、課題と既存製品の足りない点を把握する進め方が、Stripeの解説で紹介されています
2. 要件を決め、MVPに絞る	必須の機能と、後回しにする機能を分ける	1つか2つの機能に絞った最小限の製品で始め、フィードバックを集める
3. 設計する	テナントの分け方、認証と権限、個人データの扱い、課金の仕組みを決める	次の節で整理します
4. UI/UXを設計する	初めて使う人が迷わない画面と流れにする	使いやすさが継続率に影響するとの解説があります(TD SYNNEX)
5. 実装する	言語と基盤を選び、開発、試験、運用の環境を分ける	総務省ガイドラインは、環境の分離を基本として求めています(76頁)
6. テストする	単体から負荷、セキュリティまで確かめる	受入れ試験の基準を決め、試験データを保護する(70頁)
7. リリースする	変更内容と予定日を、利用者に事前に知らせる	変更の開始と完了も通知する(75頁)
8. 運用して改善する	監視、バックアップ、サポート、利用状況の確認を続ける	稼働・障害監視(73頁)、バックアップ(83頁)、苦情対応(63頁)

開発の途中でつまずきやすい点も、解説で整理されています。Stripeは、シンプルさと機能のバランス、柔軟すぎる設計と作り込み不足の両方を避けること、経常収益と請求の管理、解約を防ぐこと、セキュリティ基準への準拠、カスタマイズと標準化のバランス、インフラ費用の最適化、止めずに更新を続けること、価格の決め方を、よくある課題に挙げています。アマテックの解説は、機能の増加、顧客ごとの仕様の差、請求の不整合、運用担当の不在を、事前の整理で防げる課題として挙げています。どれも、公開後に直すと手間が大きくなるため、設計の段階から確認します。

MVPは、動くモックアップのことではありません。個人開発SaaSの解説(ShiftB「個人開発SaaSの作り方」)は、機能は絞っても、その範囲は本番の品質で仕上げるものだと定義しています。範囲を絞ることと、品質を下げることは別だと考えると、最初のリリースの判断がしやすくなります。

公的な資料では、総務省「クラウドサービス提供における情報セキュリティ対策ガイドライン(第3版)」が、プロジェクトの種類にかかわらず、開発のライフサイクルで情報セキュリティに取り組むことを基本としています(70頁)。ベストプラクティスとして、システムの変更を正式な変更管理の手順で管理すること、情報セキュリティに配慮した構築の原則を文書化してすべてのシステムに適用すること、外部委託した開発を監督・監視すること、受入れ試験の基準を設けること、試験データを注意深く選定・保護することが挙げられています。

SaaS開発の設計で先に決める4つのこと｜テナント・認証と個人データ・課金・技術選定

SaaS開発の設計では、テナントの分け方、認証と個人データの扱い、料金モデル、技術の選び方を先に決めます。あとから変えるには、データの持ち方や課金の仕組みに手を入れる必要が出るためです。

SaaSに共通して必要になる機能

顧客の業務を支える機能のほかに、SaaSを継続して提供するための共通の機能が必要になります。SaaS開発の解説(アマテック「SaaS開発とは？」)は、認証・権限管理、テナント管理とデータ分離、契約・料金プラン・決済、セキュリティと監査ログ、運用監視と障害対応を、主な共通機能として挙げています。

共通の機能	設計で決めること(整理の例)	公的な資料での関連項目
認証・権限管理	ログインできることと、見てよい情報を操作できることを分けて設計する	アクセス制御、セッション管理(総務省ガイドライン)
テナント管理とデータ分離	顧客企業ごとの境界を、検索や集計などすべての処理で守る	次の項で整理するテナントの分け方
契約・料金プラン・決済	課金の単位と、契約の状態に応じた利用権限を、決済と連動させる	後述の料金モデル
セキュリティ・監査ログ	扱う情報に応じた対策を組み込み、利用者の活動や情報セキュリティの事象の記録を取得して定期的に見直す	イベントログの取得(76頁)
運用監視・障害対応	障害の検知と、検知後に対応する担当者と連絡の手順を、セットで決める	稼働・障害監視(73頁)

テナントの分け方(マルチテナントとテナント分離)

マイクロソフトの設計ガイドは、マルチテナントのソリューションを、複数の顧客またはテナントが使うものと説明し、テナントはユーザーとは異なり、1つの組織、会社、またはグループの複数のユーザーが1つのテナントを形成するとしています(Microsoft Learn「Azure でのマルチテナント ソリューションの設計」)。SaaSでは、この顧客ごとのまとまりを、どこまで分けて持つかが設計の中心になります。

AWSのSaaS Lensは、SaaSのアーキテクチャを、サイロ(silo)、プール(pool)、ブリッジ(bridge)の3つのモデルに分けています(AWS SaaS Lens「Silo, Pool, and Bridge Models」)。

モデル	内容(AWS SaaS Lensの説明)	検討しやすい場面(整理の例)
サイロ	テナントに専用のリソースを割り当てる。たとえば、テナントごとに独立したインフラやデータベースを持つ。専用でも、ID、オンボーディング、運用は共通の仕組みで管理する点が、個別の環境を用意するサービスとの違い	規制や顧客の要件で、データの分離が強く求められる場合
プール	テナントがリソースを共有する。拡張しやすい共有の基盤で、規模の経済や管理のしやすさを得る	多くの顧客に同じ仕組みで提供し、費用を抑えたい場合
ブリッジ	一部をサイロ、一部をプールにする混在型。たとえば、マイクロサービスごとに方式を変える	機能ごとに、データの規制や性能の要件が違う場合

AWSの説明では、サービスのデータにかかわる規制の状況や、ほかのテナントの負荷から受ける影響(ノイジーネイバー)が、マイクロサービスをサイロにする方向に働くことがあるとされています。一方で、俊敏さ、アクセスの傾向、費用の面からは、プールに傾くことがあります。

認証と権限、個人データの扱い

テナントごとの認証と権限は、ほかのテナントのデータが見えないことの土台になります。あわせて決めたいのが、自社のSaaSが顧客の個人データを取り扱う設計かどうかです。個人情報保護委員会のQ&A(個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」に関するQ&A)では、クラウドサービスの利用が第三者提供にあたるかの判断基準は、保存された電子データに個人データが含まれるかではなく、クラウドサービス提供事業者が個人データを取り扱うこととなっているかどうかだとしています(Q7-53)。事業者が個人データを取り扱わないこととなっている場合の例として、契約条項で事業者がサーバ上の個人データを取り扱わない旨が定められ、適切にアクセス制御が行われている場合が挙げられています。この場合でも、利用する事業者は、自ら果たすべき安全管理措置の一環として、適切な措置を講じる必要があります(Q7-54)。

作る側から見ると、顧客のデータをどこまで見える状態で持つかによって、利用企業との契約や、求められる安全管理の前提が変わりえます。データの持ち方は、設計の早い段階で決めておく項目です(本記事は法的助言ではありません。個別の判断は専門家に確認してください)。

料金モデルと、運用で追う指標

SaaSの料金モデルには、複数の型があります。Stripeの解説では、段階制、従量課金、フリーミアム、定額、ユーザー数、アクティブユーザー数、カスタム、ハイブリッドが挙げられています(Stripe「SaaS ビジネスを立ち上げる方法」)。このうち代表的な型を、設計で気をつける点とあわせて並べます(金額の目安ではありません)。

料金モデル	内容(Stripeの説明)	設計で気をつける点(整理の例)
段階制	機能や上限が異なる複数のプランを用意し、幅広い顧客層とアップグレードを狙う	機能の出し分けと上限の管理が必要になる
従量課金	利用量に応じて課金し、価値と料金を直接連動させる	利用量を正しく計測し、請求に反映する仕組みが必要になる
フリーミアム	無料版で関心を引き、価値を感じた利用者に有料版へ移ってもらう	無料の利用者の分も、運用とサポートの負担がかかる
定額	単一の料金で全機能を提供する。単純だが拡張性は限られる	利用が増えても収益が増えにくい
ユーザー数	利用者の数に応じて課金し、チームの規模に合わせて拡張しやすい	利用者の追加と削除を、課金に反映する仕組みが必要になる
ハイブリッド	複数の料金方式を組み合わせ、多様な顧客に対応する	請求の仕組みが複雑になる

継続課金の請求処理は複雑で、手作業で行うと破綻しやすいという課題が、Stripeの解説では挙げられています。また、運用では、MRR(月次経常収益)、ARR(年間経常収益)、LTV(顧客生涯価値)、チャーン(解約率)などの指標を追うことが紹介されています。

技術の選び方

言語や基盤は、公的な基準で決まるものではありません。採用しやすさ、既存の資産、クラウド基盤との相性、運用の自動化のしやすさなどから選ぶのが一般的です(整理の例です)。SaaS開発の解説では、RubyやPythonなどのWeb系言語が例に挙がっています(発注ナビ「SaaSとは？メリットやデメリット、開発時に意識するポイントなど」)。Stripeの解説は、速度や拡張性を考慮しつつ、初期の段階で複雑になりすぎない技術を選ぶよう勧めています。

既存のソフトウェアをSaaS化する場合の考え方

既存のソフトウェアをSaaS化するには、クラウドへ移すだけでなく、複数の顧客が共有できる作りと、課金や運用の仕組みを加える必要があります。

パッケージソフトや、顧客ごとに環境を用意してきたシステムをSaaS化する場合、どこまで作り直すかが最初の判断になります。AWS規範ガイダンスの移行戦略は、クラウドへの移行を7つに分類しており、SaaS化の検討に使えるのは次の3つです(AWS規範ガイダンス「移行戦略について」)。

方式	内容(AWS規範ガイダンスの説明)	SaaS化での考え方(整理の例)
リホスト	アプリケーションを変更せずに、ソース環境からクラウドへ移動する。リフトアンドシフトとも呼ばれる	顧客ごとに環境を用意する形(サイロに近い形)で、早く提供を始められる。更新と運用の手間は、顧客の数だけ増える
リプラットフォーム	クラウドに移行し、効率的な運用、コスト削減、クラウド機能の活用のために、ある程度の最適化を行う	データベースなど一部をクラウドのサービスに替えて、運用の手間を減らす
リファクタリング	クラウドネイティブ機能を最大限に活用して、俊敏性、性能、拡張性を高めるために、クラウドへ移行しアーキテクチャを変更する	複数の顧客で共有する設計(プールに近い形)へ作り直す。時間と費用の負担が大きい

SaaS開発の解説(TD SYNNEX)でも、変更を最小限にして素早く移す方法と、クラウドネイティブに作り直す方法があり、前者には限界、後者には負担があること、先に移してから段階的に最適化する進め方があることが整理されています。どの方式でも、既存の顧客ごとのカスタマイズをどこまで標準に取り込むかは判断が必要で、Stripeの解説も、カスタマイズと標準化のバランスを、SaaS開発のよくある課題に挙げています。

クラウド移行そのものの方式と手順はクラウド移行とはで、オンプレミス環境の構成要素はオンプレミス環境とはで整理しています。

お手本にする既存SaaSの見方

お手本にする既存SaaSは、機能だけでなく、料金ページの構成、無料で試せる範囲、ヘルプとAPIの公開、障害情報の出し方、セキュリティの公開情報を見ると、作る側の判断材料になります。

見る場所	分かること(整理の例)
料金ページ	料金モデルの型(段階制、従量課金など)と、プランごとの機能や上限の分け方
無料プラン・試用の案内	どこまで無料で試せるか。有料へ移る動機をどう作っているか
ヘルプ・API仕様	利用者への説明の粒度と、外部サービスとの連携の範囲
障害情報・稼働状況の案内	停止や異常を、利用者にどのように速報しているか
セキュリティ・個人情報の案内	責任範囲、データの扱い、第三者の認証や外部の基準への対応の示し方

分野別の代表例はSaaSの代表例で、日本で提供されているSaaSの業種別の見取り図はSaaSを提供する日本企業とはで整理しています。

SaaS開発の費用の考え方｜開発費と公開後の運用費に分けて見る

SaaS開発の費用は、機能の範囲、体制、使う基盤で大きく変わり、公的な標準単価もないため、開発費と公開後の運用費に分けて、見積もりの内訳を確認します。

金額の相場だけを見ると、公開後に続く費用を見落とします。次のように、時期ごとに費目を並べると、抜けを防げます(費目の整理の例で、金額の目安ではありません)。

時期	費目	見落としやすい点
構想・要件定義	課題の整理、要件定義、プロトタイプ	範囲が曖昧だと、あとから機能が増える
開発	設計、UI/UX、実装、テスト	MVPに絞るか、全機能を作るかで大きく変わる
公開時	インフラの構築、セキュリティの確認、利用規約とプライバシーポリシー、決済の導入	公開の直前に必要になり、後回しにしやすい
公開後	クラウドの利用料、監視と運用、保守、サポートの人件費、決済の手数料	利用者が増えるほど増える費目がある
継続	機能の追加、解約を防ぐための改善	公開後も開発が続く前提で、予算を見ておく

期間も同じで、機能の数だけでは決まりません。工数(作業量)と期間(経過時間)は別のもので、外部サービスとの連携、既存データの移行、顧客の受入れ確認、承認待ちが、期間を延ばす要因になると解説されています(アマテック「SaaS開発とは？」)。

SaaS開発の解説では、低めの月額料金で初期の投資を回収する形になるため、回収の期間が長くなりやすく、資金繰りに注意が必要とされています。外注する場合は、固定価格型、時間単価型、成果報酬型といった契約の形でも、見積もりの見え方が変わります(GICP「SaaS開発でおすすめのシステム開発会社」)。

AWSでSaaSを動かす場合、公開後の費目のひとつが、クラウドの利用料です。利用料の支払いを円建ての請求書にそろえたい場合の一例が、同じくGMOグローバルサイン・ホールディングス株式会社のCloudCREW AWS請求代行です。商品ページでは、AWSの定価から値引きを受けて利用できること、日本円建ての請求書に対応し銀行振込で支払えること、初期費用や代行手数料などの各種手数料がかからないこと、クラウドの運用改善に向けたアセスメント支援を無料で受けられることが紹介されています(2026年10月22日確認)。注意点は、監視や運用サービスを利用する場合は有料オプション扱いになることです。対象はAWSの利用料で、料金はプランによって異なるため、資料や公式サイトで確認してください。

AWS請求代行サービスによってAWS利用料のコストを大きく抑えることができ、取り組み当初に抱えていた最も大きな課題を解決できています。

AWS事例(株式会社パム。導入後の成果として掲載) 出典：導入事例ページ

SaaS開発を外注する場合｜内製との分け方と、外注先を比べる5つの観点

SaaS開発を外注するときは、どこまでを委託するかを先に決め、外注先を、料金体系、SaaSの実績、開発体制、運用保守、セキュリティと法令対応の5つの観点で比べます。

内製、外注、共同の分け方

進め方	向く場面(整理の例)	注意点
自社で作る(内製)	開発の人材がそろい、仕様が頻繁に変わる、または製品の中核になる部分	開発に加えて、運用とサポートの体制も自社で持つ必要がある
外注する	社内に開発の人材が少ない、または期間を区切って作りたい	要件の伝え方と、受入れ試験の基準を決めておかないと、期待との差が出やすい
共同で進める	企画と要件は自社で持ち、実装の一部を委託したい	役割の分担と、成果物の権利の扱いを契約で決める
専属チームを組む(ラボ型)	開発の人員が不足し、継続して機能を追加していきたい	仕様の判断と品質の確認を、自社が担い続けられるかが前提になる
ノーコードなどの既製の基盤を使う	小さく始めて、要件を検証したい	料金、機能の制約、データを移すときの条件を、先に確認する

個人で作ることについては、小規模なMVPなら個人でも可能とする一方、本格的な事業化は専門の会社への依頼が現実的とする解説(GICP)と、個人開発に向けて企画から運用までの手順を示す解説(ShiftB)があります。どちらにするかは、作りたいSaaSの規模と、公開後に続く運用の負担から判断します。

外注先を比べる5つの観点

SaaS開発会社を紹介する解説では、次の5つの観点が挙げられています。会社ごとの優劣は案件の要件で変わるため、本記事では会社の一覧や順位は掲載せず、比べる観点を整理します。

観点	確認すること
料金体系	固定価格型、時間単価型、成果報酬型のどれか。見積もりの内訳がどこまで示されるか
実績と得意な業界	マルチテナント、課金、外部サービスとのAPI連携など、SaaS特有の要件に対応した実績があるか
開発体制	国内かオフショアか、プロジェクトマネージャーがいるか、どの開発手法を使うか
運用保守のサポート	リリース後の保守の範囲、対応時間、追加費用がどうなっているか
セキュリティと法令対応	認証制度、暗号化、業界の規制への対応が、契約前に確認できるか

契約の考え方は、IPAの「情報システム・モデル取引・契約書」が参考になります。ページには、第二版と、アジャイル開発版が掲載されており、ユーザ企業とITベンダの取引構造を透明にするため、各開発段階で担うべき責務の解説と、契約書のひな型が示されています(IPA「情報システム・モデル取引・契約書」)。

外注先の開発を監督する側の考え方としては、総務省「クラウドサービス提供における情報セキュリティ対策ガイドライン(第3版)」が、外部委託したシステム開発の活動を監督・監視すること、受入れ試験のプログラムと基準を確立することを挙げています(70頁)。SIerとSaaS、パッケージ、自社構築の選び方は、SaaSとSIerの違いで整理しています(本記事は法的助言ではありません)。

SaaSを公開する前に確認する、提供者側の運用とセキュリティの項目

SaaSを公開する前には、責任範囲とSLA、稼働・障害監視、変更の通知、環境の分離、バックアップ、インシデントの報告、緊急時対応、データの引継ぎを、提供者として決めておきます。総務省のガイドライン第3版が、これらの項目を挙げています。

総務省「クラウドサービス提供における情報セキュリティ対策ガイドライン(第3版)」は、2021年9月に公表されたガイドラインで、共通編、SaaS編、PaaS/IaaS編に分かれています。対策には「基本」と「推奨」があり、ベストプラクティスや評価項目が付記されています。ガイドラインは、実施必須事項を示すものではなく、対策を実施する上での指標として、自らが行うべき対策を選択して実施するよう求めています。SaaSを作る側が、公開前に決めておきたい項目を、ページ番号とあわせて整理すると、次のとおりです(整理の例です)。

ガイドラインの項目	提供者が決めておくこと(要点)
責任範囲とSLA(63頁)	事業者自身の責任範囲をSLA等で文書化し、利用者に明確に示す
稼働・障害監視(73頁)	稼働、障害、パフォーマンス、セキュリティインシデントを監視する。提供する時間帯と稼働率を定め、停止を検知したら利用者に速報する
変更管理(75頁)	変更内容、変更予定日、技術的な説明を利用者に提供し、変更の開始と完了を通知する
環境分離(76頁)	開発、試験、運用の環境を分離し、運用環境に適用する前に、試験環境で試験する
バックアップ(83頁)	利用者のデータ、アプリケーションの管理情報、システム構成情報を定期的に保存する。対象、世代、間隔、戻し方(リストア)を決める
インシデントの報告(59頁)	利用者が事業者に、事業者が利用者に報告する仕組みと、状況を追跡できる仕組みを用意する
緊急時対応計画(66頁)	復旧の目標と優先順位、役割、連絡先を含む計画を作り、実施の手順を文書化する
他のサービスへの引継ぎ(50頁)	利用の終了や乗り換えのときに、情報を引き継ぐかどうかを、あらかじめ利用者と合意して文書化する
開発プロセスのセキュリティ(70頁)	変更管理、外部委託の監督、受入れ試験、試験データの保護を、開発の進め方に組み込む

稼働・障害監視の評価項目として、ガイドラインは参考値を示しています。たとえば稼働率は、99.9%以上、99.0%以上などのパターンが、死活監視の間隔は、1分に1回以上から30分に1回以上までのパターンが示されています(73頁)。自社のSLAとしてどの水準にするかは、サービスの内容と、運用の体制に合わせて決めます。

設定の不備による事故を防ぐための手引きとして、総務省は、第3版をもとにした「クラウドサービス利用・提供における適切な設定のためのガイドライン」も示しています。

公開後の運用を支える選択肢を、役割の違いで並べます(2026年10月22日に各商品ページで確認した内容です)。2サービスはいずれもAWSの環境が対象で、SaaS開発そのものを請け負うサービスとして紹介されているものではありません。

2サービスの使い分けは、公開後の運用で、監視の人手を外に出したいのか、クラウドの利用料の支払いと管理を整えたいのかで考えられます。どちらも、公開前に決めておく責任範囲と運用の手順を、代わりに決めてくれるものではありません。自社で決める項目と、外部に任せる範囲を分けるために、次のセルフチェックを用意しました。

チェックが付いた項目は、公開前に決める順番の目安になります。決めた内容をSLAや運用手順として文書にしておくと、利用者への説明と、監視や運用を外部に任せるときの依頼内容のどちらにも使えます。

よくある質問(FAQ)

Q1. SaaS開発とは何ですか？

A. SaaS開発とは、クラウド上で動かし、インターネット経由で多くの顧客に継続して提供することを前提に、ソフトウェアを企画、設計、実装、運用することです。作って納品すれば終わる受託開発と違い、公開後の監視、更新、サポート、課金の管理までを事業として続けます。

Q2. SaaSとは何ですか？代表的な例は？

A. SaaSとは、事業者がクラウド上で運用しているソフトウェアを、利用者がインターネット経由で使う提供形態です。総務省のガイドラインでは、事業者がアプリケーション層以下の実装、設定、更新及び運用を管理し、利用者はアプリケーションで扱うデータの管理に責任を持つと整理されています。代表例は分野別に整理でき、人事・労務ではカオナビ、タレントパレット、ジンジャー人事労務、会計ではfreee会計、マネーフォワード クラウド会計などがあります。

Q3. 日本のSaaS大手企業5社はどこですか？

A. 5大SaaS企業や、日本のSaaS大手企業という公的な定義はなく、売上、利用者数、分野のどれで見るかによって顔ぶれが変わります。分野別の代表例や、日本で提供されているSaaSの業種別の見取り図は、別の記事で整理しています。

Q4. SaaSの開発費はいくらですか？

A. 公的な標準単価はなく、機能の範囲、体制、使う基盤によって大きく変わります。企画から実装、テストまでの開発費と、公開後のクラウド利用料、監視と運用、保守、サポート、決済の手数料などの運用費に分けて、見積もりの内訳と契約の形(固定価格型、時間単価型、成果報酬型)を確認します。本記事では具体的な金額は示していません。

Q5. SaaS開発の流れと、開発言語の選び方は？

A. 課題と対象を決める、要件を決めてMVPに絞る、設計する、UI/UXを設計する、実装する、テストする、リリースする、運用して改善する、の8ステップで進めます。開発言語に公的な基準はなく、採用しやすさ、既存の資産、クラウド基盤との相性、運用の自動化のしやすさなどから選びます。

Q6. SaaS開発は、個人や自社だけでもできますか？

A. 小規模なMVPなら個人でも可能とする解説があります。一方で、本格的な事業化では、専門の会社への依頼が現実的とする解説もあります。どちらにするかは、作りたいSaaSの規模と、公開後に続く運用とサポートの負担から判断します。

まとめ｜SaaS開発で押さえたい7つのこと

SaaS開発は、作って渡して終わりではなく、公開後の運用、サポート、課金までを事業として続ける取り組みです。開発の流れだけでなく、設計、費用、外注先、公開前の確認までを、早い段階で決めておきます。

1. SaaS開発とは、クラウド上で動かし、多くの顧客に継続して提供することを前提に、ソフトウェアを企画、設計、実装、運用すること
2. 流れは、課題と対象の決定、要件定義とMVPの絞り込み、設計、UI/UX設計、実装、テスト、リリース、運用と改善の8ステップ
3. 設計では、テナントの分け方(サイロ、プール、ブリッジ)、個人データの扱い、料金モデルを先に決める
4. 既存のソフトウェアをSaaS化するときは、クラウドへ移すだけでなく、複数の顧客が共有できる作りと、課金、運用の仕組みを加える
5. 費用は、開発費と公開後の運用費に分け、見積もりの内訳と契約の形を確認する
6. 外注先は、料金体系、実績、開発体制、運用保守、セキュリティと法令対応の5つの観点で比べる
7. 公開前に、総務省ガイドラインの項目で運用を確認し、監視や利用料の管理を外部に任せる選択肢も、資料で比べて体制を決める

まずは、解決する課題と、最初に使ってもらう顧客を、1文で書き出すところから始められます。

参考文献

• 総務省「クラウドサービス提供における情報セキュリティ対策ガイドライン(第3版)」2021年9月https://www.soumu.go.jp/main_content/000771515.pdf
• 総務省「クラウドサービス利用・提供における適切な設定のためのガイドライン」2022年10月https://www.soumu.go.jp/main_content/000843318.pdf
• 総務省「令和7年通信利用動向調査の結果」https://www.soumu.go.jp/johotsusintokei/statistics/data/260529_1.pdf
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」に関するQ&Ahttps://www.ppc.go.jp/personalinfo/faq/APPI_QA/
• IPA「情報システム・モデル取引・契約書」https://www.ipa.go.jp/digital/model/index.html
• AWS「SaaS Architecture Fundamentals」https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/saas-architecture-fundamentals.html
• AWS SaaS Lens「Silo, Pool, and Bridge Models」https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-pool-and-bridge-models.html
• AWS規範ガイダンス「移行戦略について」https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• Microsoft Learn「Azure でのマルチテナント ソリューションの設計」https://learn.microsoft.com/ja-jp/azure/architecture/guide/multitenant/overview
• Stripe「SaaS ビジネスを立ち上げる方法」https://stripe.com/jp/resources/more/how-to-start-a-saas-business-a-guide-for-getting-started
• アマテック「SaaS開発とは？仕組み・開発の流れ・費用・成功のポイントを解説」https://ama-tec.jp/tech/saas-development/
• TD SYNNEX「SaaS開発やSaaS化の手順を解説！外注時のコスト目安も紹介」https://jp.tdsynnex.com/blog/cloud/saas-development-outsourcing-cost-guide/
• GICP「SaaS開発でおすすめのシステム開発会社」https://gicp.co.jp/manegementnote/saassystem-development-company/
• ShiftB「個人開発SaaSの作り方」https://shiftb.dev/articles/indie-dev-saas
• 発注ナビ「SaaSとは？メリットやデメリット、開発時に意識するポイントなど」https://hnavi.co.jp/knowledge/blog/saas-development/
• AWS事例「ジャスネットコミュニケーションズ株式会社」https://managed.gmocloud.com/case/case-jusnet.html
• AWS事例「株式会社パム」https://managed.gmocloud.com/case/pam.html