マルチテナントのシステム開発の発注/外注/依頼/委託方法について

マルチテナントのシステム開発を発注する際は、複数の顧客が共通基盤を使う前提で、データ・権限・性能の分離要件を先に定め、RFPと契約に落とし込むことが成功の要点です。

「共有データベースで安全に運用できるのか」「パッケージやSaaSで足りるのか」「開発会社から届いた見積もりをどう比べるのか」と迷う担当者は少なくありません。この記事では、発注形態の選び方、RFP・要件整理、契約形態、費用相場、委託先の選定、見積比較、発注後の進め方までを、非技術者の方にも判断しやすい順番で解説します。なお、金額は一般的な業務システムの相場とリサーチノートをもとにした目安であり、実際の費用はテナント数や分離要件によって変わります。

▼全体ガイドの記事
・マルチテナントのシステム開発の完全ガイド

マルチテナントのシステムを発注する前に押さえる全体像

マルチテナントとは、1つのアプリケーションやコードベースを複数の企業・組織が利用しながら、各社には自社専用の環境に見えるように提供する方式です。販売管理、CRM、勤怠、人事、予約、ECなどのSaaSでよく使われますが、単にログインユーザーを増やす仕組みではありません。最も重要なのは、テナントをまたいだデータや権限の混入を防ぎ、契約単位で利用開始・変更・停止・削除まで管理できることです。

共有型は、複数テナントが同じアプリケーションやデータベースを使う方式です。顧客追加のたびに環境を複製する必要がなく、アップデートを一括適用しやすいため、標準化された業務を低コストで提供したい場合に向いています。一方で、クエリの条件漏れやキャッシュキーの衝突が起きると、別テナントの情報が見えてしまう危険があります。

専用型は、テナントごとにデータベース、アプリケーション、クラウド環境などを分ける方式です。機密性、性能、データ所在地、顧客ごとの個別要件に対応しやすい反面、構築・監視・バックアップ・アップデートの対象が増えます。AWS Well-Architected SaaS Lensでも、共有による効率だけでなく、コンプライアンス、ノイジーネイバー、階層別サービスなどを理由にサイロ型を選ぶ考え方が示されています（出典: AWS Well-Architected SaaS Lens、2026年参照）。

発注時に「tenant_idを付ける」とだけ書くと、仕様が不十分になりがちです。テナント境界は、認証・認可、データベース、キャッシュ、ファイルストレージ、検索インデックス、メッセージキュー、メール配信、ログ、バックアップ、管理者画面まで確認します。たとえば共有キャッシュにテナント識別子がない、CSV出力だけ別の検索条件になっている、バックアップから復元したデータを誤って別顧客へ戻せる、といった箇所も事故の原因になります。

OWASPのMulti-Tenant Application Security Cheat Sheetでも、クライアントが送ったテナントIDをそのまま信頼せず、認証済みのセッションやトークンからテナントコンテキストを確定すること、データアクセス層で所有権を検証すること、キャッシュキーや保存パスにもテナント境界を反映することが推奨されています（出典: OWASP Multi-Tenant Application Security Cheat Sheet、2026年参照）。この範囲をRFPの非機能要件に含めることが発注の出発点です。

発注形態はどれを選ぶ？パッケージ・クラウド・スクラッチの違い

発注形態は、作りたい機能の多さだけでなく、業務をどこまで標準化できるか、自社がSaaS事業者として継続運用するかで決めます。既存サービスに合わせられるのにフルスクラッチを選ぶと初期費用と保守負担が膨らみ、反対に差別化が必要なのに設定変更だけで済ませると、後から大規模な作り直しになりやすいです。

販売管理、勤怠、請求、顧客管理など、業務の大部分を既存の運用に合わせられる場合は、マルチテナント型のSaaSやパッケージを導入し、足りない部分だけAPI連携やアドオンで補う方法が現実的です。初期の開発量を抑え、アップデートやセキュリティ対応をサービス提供会社に寄せられる点が利点です。

ただし、SaaSの「複数ユーザー対応」と、自社が複数企業へ提供するためのテナント管理は同じではありません。テナントごとの管理者、料金プラン、データエクスポート、解約時の削除、監査ログ、外部連携、SSOの有無を確認し、標準機能で足りない範囲を一覧にします。個別カスタマイズを重ねるほど、将来のアップデートや契約終了時の移行条件も確認が必要になります。

自社サービスとして多くの顧客を増やしたい、顧客ごとの業務設定を持たせたい、既存基幹システムや外部APIと連携したい場合は、AWS、Azure、Google Cloudなどのマネージドサービスを使ったクラウド開発が候補になります。クラウドに寄せると、監視、バックアップ、WAF、データベース運用などを標準サービスで構成しやすく、将来の増加に合わせた拡張も設計しやすくなります。

AWSが2025年8月に公開したアイデミーの事例では、ECS、Application Load Balancer、Aurora PostgreSQLのRow Level Security、AWS WAFを組み合わせ、2名の開発チームが3週間でインフラ環境を構築したと紹介されています（出典: AWS Japan公式ブログ「アイデミー様のSaaS on AWS事例」、2025年）。ただし、この3週間はインフラ環境の構築期間であり、業務アプリケーション全体の要件定義・開発・移行期間とは分けて見積もる必要があります。

特殊な業務ルール、厳格なデータ所在地、既存基幹との複雑なリアルタイム連携、顧客ごとに異なる料金・権限モデルなどが競争力になる場合は、クラウド上のスクラッチ開発が適しています。最初から顧客ごとの環境を複製するのではなく、共通機能と顧客固有設定を分離し、共通コードを保ったまま設定で差分を吸収できる設計にします。

機密性の高い顧客だけ専用データベースや専用環境に移せるハイブリッド型も有効です。共有型、テナント別スキーマ・データベースを使うブリッジ型、テナントごとに環境を分けるサイロ型を、全顧客に一律適用する必要はありません。料金プランや契約条件と連動して分離レベルを変える前提を、発注段階で開発会社と合意しておくと、将来の大口顧客にも対応しやすくなります。

RFPと要件整理で発注先に伝えるべき項目

RFPは、開発会社に要望を伝えるだけの資料ではなく、同じ条件で提案と見積もりを比較するための基準です。「マルチテナント対応」と一言で済ませず、誰が、どの業務を、何社で利用し、どの程度の性能と分離が必要なのかを数値と業務シナリオで書きます。未確定の項目は未定と明記し、提案側に確認事項と代替案を出してもらいます。

まず、サービスの対象業界、初年度と3年後のテナント数、1テナントあたりのユーザー数、同時接続数、料金プラン、無料トライアル、利用開始までの作業を整理します。テナント登録を営業担当が手作業で行うのか、契約・決済と連動して自動作成するのかで、必要な管理画面と連携方式が変わります。プラン変更、休止、解約、データエクスポート、削除証跡まで業務フローに含めることが大切です。

機能要件には、テナント管理者、部門管理者、一般利用者、運用者などの権限を記載します。顧客の管理者が自社ユーザーを追加できるのか、運用者が障害対応で顧客データを見る場合に承認や記録が必要なのかも明確にします。売上や利用量をテナント単位で集計する場合は、課金対象となるメトリクス、計測単位、上限超過時の動作まで書いておくと、後から請求機能の追加費用が発生しにくいです。

非機能要件では、稼働率、目標応答時間、同時実行数、バックアップ頻度、復旧目標時間、復旧時点、データ保持期間、監視時間、障害連絡の方法を決めます。「高速」「安全」といった形容詞だけでは見積もりの前提が会社ごとに変わるため、ピーク時の件数や許容時間で表現します。1社の大量処理が他社の性能を下げるノイジーネイバー対策として、テナント別のクォータ、レート制限、優先度、アラートも要求に含めます。

セキュリティ要件は、ログインだけでなく、テナントIDの改ざん、IDOR、権限昇格、CSV・ファイル出力、キャッシュ、検索、バッチ、メール、バックアップ復元を対象にします。異なるテナントのユーザーで同じ操作を行い、データが混ざらないことをテストケースとして指定します。個人データを扱う場合は、クラウド事業者や保守会社が実際にデータを取り扱うか、国外の再委託先があるか、保存場所・アクセス場所・削除方法を確認します。個人情報保護委員会は、外国にある事業者へ個人データの取扱いを委託する場合も、法第28条の整理が必要になる場合があると示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドラインに関するQ&A」、2025年確認）。

新規性が高い案件や、既存シングルテナント製品を移行する案件では、いきなり本開発を契約せず、短いPoCで不確実性を減らす方法があります。PoCでは、異なるテナントのログイン、権限、データ取得、ファイル保存、通知、CSV出力、バックアップ復元、同時アクセスを最低限検証します。tenant_idを書き換えたリクエストが拒否されるか、解約済みテナントがアクセスできないか、大量処理が他社へ影響しないかも確認します。

PoCの成果物は画面だけではありません。採用した分離方式、想定テナント数、負荷試験の条件、未解決のリスク、本開発で必要な追加工数を報告書にしてもらいます。本番の受け入れ条件には、機能テストだけでなく、クロステナントアクセスがないこと、監査ログが残ること、復元手順を実行できること、障害時の連絡と切り戻しができることを含めます。

マルチテナント開発の契約形態と責任分界

契約形態は、要件の確定度と変更の多さに合わせて選びます。マルチテナント開発では、分離方式や移行データの状態によって途中で設計変更が起きやすいため、すべての工程を最初から完成責任だけで固定すると、無理な前提が見積もりや品質に現れます。要件定義、設計、開発、移行、運用を工程ごとに分け、成果物と責任範囲を確認します。

請負契約は、完成させるシステムや成果物、検収条件を定めて進める形態です。要件が固まった機能開発や、合意済みの移行ツールなどには向いています。契約書や仕様書には、対応するブラウザ、性能条件、セキュリティ試験、テナント分離試験、納品物、検収期限、瑕疵や契約不適合への対応を記載します。

注意点は、仕様変更の扱いです。料金プランの追加、専用環境への変更、既存データの不備、外部APIの仕様変更などが起きた場合に、追加費用や納期をどの手順で合意するかを決めます。「軽微な変更」の定義が曖昧だと、発注者と受託者の双方が想定外の負担を抱えます。変更要求票、影響範囲、承認者、見積もり更新の手順をあらかじめ合意すると安全です。

準委任契約は、専門人材が一定の業務を遂行することを目的とする形態です。要件定義、アーキテクチャ検討、PoC、アジャイル開発、既存システムの段階的な移行など、作業内容を進めながら決める工程と相性がよいです。発注者側にも優先順位を決める責任があるため、プロダクトオーナー、業務担当、セキュリティ担当の参加時間を確保します。

契約では、作業時間だけでなく、週次報告、設計レビュー、リスク管理表、コードレビュー、テスト結果、意思決定記録などの成果物を定めます。準委任だから品質保証が不要になるわけではありません。特にテナント分離のような重大要件は、実施するテストと合格条件を個別に明文化します。

納品後に自社で改善できるよう、ソースコード、設計書、API仕様、データベース定義、IaC、テストコード、運用手順書、監査ログの取り扱いを確認します。著作権の帰属だけでなく、改修や二次利用に必要な権利、第三者ライブラリのライセンス、クラウドアカウントの所有者、契約終了時のデータ返却と削除証明まで決めます。

再委託先がいる場合は、会社名や所在国、担当範囲、アクセス可能なデータ、事故時の連絡、監査の可否を確認します。発注先が「セキュリティはクラウド会社の責任」と説明しても、アプリケーションの認可やテナント分離は別の責任です。クラウド、受託開発会社、再委託先、自社運用の責任分界を図にして、障害・漏えい・データ削除の際に誰が何をするかを合意します。

マルチテナントのシステム開発費用相場と見積もりの内訳

マルチテナントのシステム開発費は、PoC・MVPなら300万〜800万円、標準的なBtoB SaaSなら800万〜2,000万円、複数業務を含む本格サービスなら2,000万〜5,000万円、厳格な監査や専用環境を含むエンタープライズ型なら5,000万〜1億円以上が一つの推定レンジです。期間はそれぞれ2〜4か月、4〜8か月、8〜15か月、12〜24か月以上が目安ですが、いずれも公的な一律価格ではありません（出典: NotebookLMリサーチノート「マルチテナントのシステム」、2026年8月）。

PoC・MVPの300万〜800万円は、1つの主要業務、数テナント、共有データベース、基本的なロール管理、最低限の管理画面を想定したレンジです。標準的なBtoB SaaSでは、テナント登録、プランや課金、外部API、監査ログ、バックアップ、負荷試験まで含むため、800万〜2,000万円程度が目安になります。複数業務、SSO、帳票、データ移行、顧客別の専用分離を含めると、2,000万〜5,000万円以上へ上がりやすいです。

一般的な業務システムの相場としては、小規模が50万〜300万円または300万〜1,000万円、中規模が300万〜1,000万円または1,000万〜5,000万円、大規模が1,000万円以上または5,000万〜1億円以上と整理されることがあります。これは分類方法で幅が変わるため、マルチテナント固有の費用として断定できません（出典: NotebookLMリサーチノート、2026年8月）。発注時には、機能数だけでなく、テナント分離、移行、監査、負荷試験、運用自動化を含めた見積もりかを確認します。

見積書では、要件定義、UI・UX、アーキテクチャ設計、アプリケーション実装、データベース設計、テナント管理、認証・認可、課金、外部連携、移行、テスト、インフラ構築、監視、ドキュメントを工程別に分けます。マルチテナント対応を一式にまとめた見積もりは比較しにくいため、共有DB、テナント別スキーマ、専用DBのどれを前提にしたかも明記してもらいます。

ランニングコストには、クラウド利用料、データベース、ストレージ、バックアップ、監視、WAF、外部認証、メール配信、サポート、障害対応、脆弱性診断、追加開発が含まれます。一般的な目安として保守運用費を初期開発費の年15〜25％程度とする整理がありますが、24時間監視、SLA、専用環境、データ量、サポート窓口の有無で変動します（出典: NotebookLMリサーチノート、2026年8月）。顧客が増えたときのテナント追加費用と、専用型へ移行する費用も別に聞いておくと安心です。

費用を大きく左右するのは、テナント数とユーザー数、データ量、ピーク時の同時処理、分離方式、既存データの品質、外部連携、SSO、監査要件、専用環境の有無です。特に既存のシングルテナント製品を移行する場合は、全クエリへのテナント条件追加、データモデル変更、顧客別設定の切り出し、移行リハーサルが必要になるため、初期費用だけではなく検証期間も見ます。

見積もりの安さだけで決めるのではなく、同じ条件にそろえた総額を比較します。ある会社が負荷試験や監査ログを含め、別の会社がオプション扱いにしている場合、表面上の金額差は品質差ではなく範囲差かもしれません。見積もりの前提、含まれない作業、追加単価、クラウド費用、契約終了時の移行費用を横並びにすることが重要です。

委託先の選定と見積比較で失敗しないポイント

委託先は、単なるWeb開発実績ではなく、複数企業を同じ基盤で安全に運用した経験で選びます。提案書の見栄えや会社規模だけでなく、分離方式を選んだ理由、顧客追加・解約の自動化、障害時の影響範囲、クロステナント試験、データ移行、SLA、運用体制を具体的に説明できるかを確認します。

面談では、守秘義務に配慮しながら、同じコードベースで何テナント程度を運用したか、共有DB・スキーマ分離・専用DBのどれを採用したか、顧客ごとの設定や料金プランをどう管理したかを質問します。差し支えない範囲で、障害時にどのテナントへ影響したか、リリースを一括で行ったか、顧客ごとに延期できたかも確認します。

技術だけでなく、業務理解と運用体制も見ます。要件定義に参加する担当者、設計レビューを行う責任者、セキュリティ試験の担当、リリース後の問い合わせ窓口が誰なのかを明らかにします。再委託がある場合は、テナント情報にアクセスする会社と国、アクセス権限、ログの保管、契約終了時の削除まで提示できる会社が望ましいです。

相見積もりは3社程度以上に依頼し、同じRFPと同じ質問票を渡します。比較する項目は、要件定義、設計、アプリ開発、インフラ、テナント管理、分離テスト、負荷試験、脆弱性診断、データ移行、教育、保守、追加開発です。各社の見積書に「含む」「別途」「発注者が用意」を記載してもらうと、契約後の認識違いを減らせます。

価格だけでなく、納期、体制、提案の具体性、リスクの説明、発注者側に必要な作業を比較します。極端に安い提案は、非機能要件、テスト、移行、運用設計が抜けている可能性があります。反対に高額な提案でも、専用環境や過剰な機能を一律に含んでいる場合があります。自社の優先順位に合わせて、必須・できれば欲しい・将来対応の三段階に分けて評価します。

提案を受けるときは、「この分離方式を採用した理由は何ですか」「テナントIDをどこで確定し、どの層で再検証しますか」「キャッシュ、ファイル、検索、バッチ、バックアップはどう分離しますか」と具体的に聞きます。さらに、1社の高負荷で他社が遅くなった場合、解約後にアクセスが残った場合、データ移行に失敗した場合の検知・切り戻し・責任分担も確認します。

2025年11月、AWSは同じLambda関数を使いながらテナントごとに実行環境を分けるテナント分離モードを発表し、2026年6月にはイベントソースマッピングとの連携方法も公開しました（出典: AWS Compute Blog、2025年11月・2026年6月）。こうした新機能は選択肢を広げますが、データベース、キャッシュ、ストレージ、ログまで自動的に分離するものではありません。新技術を使う提案ほど、どの境界をサービスに任せ、どの境界をアプリ側で検証するかを説明してもらいます。

よくある質問

発注前に多く寄せられる疑問を、判断の基準と一緒に回答します。技術的な正解を一つに決めるのではなく、顧客の機密性、成長規模、予算、運用体制に合わせて選ぶことが重要です。

必ず顧客ごとに分ける必要はありません。共有テーブル、テナント別スキーマ、テナント別データベース、専用環境を、機密性・性能・顧客契約・運用コストで選びます。重要なのは、採用理由と、データアクセス層・監査・バックアップ・移行まで一貫した分離を実装することです。

PoC・MVPは300万〜800万円、標準的なBtoB SaaSは800万〜2,000万円、本格サービスは2,000万〜5,000万円、厳格な専用要件を含む場合は5,000万〜1億円以上が推定レンジです。ただし、これはマルチテナント専用の公的統計ではなく、一般的な業務システム相場に分離・課金・監査・移行などを加味した目安です。RFPで前提条件をそろえ、工程別の相見積もりを取ってください。

複数顧客を同じ基盤で運用した実績、分離方式を判断した理由、クロステナント試験、テナント追加・解約の自動化、障害時の責任分界、データ移行、保守体制を基準に選びます。提案内容が「システム開発一式」だけでなく、要件定義、設計、分離テスト、負荷試験、移行、運用まで工程別に説明されているかを確認すると比較しやすいです。

分離方式、セキュリティ試験、性能条件、障害時の連絡と切り戻し、データの保存・返却・削除、クラウドと再委託先の責任分界、ソースコードや設計書の権利を記載します。顧客ごとの専用環境へ移行できる場合は、移行条件と追加費用も明記します。個人データや国外の委託先が関係する場合は、法務・個人情報保護の担当者にも確認してもらうと安全です。

まとめ

マルチテナントのシステムを発注・外注するときは、最初に「何社が、どの業務を、どの分離レベルで使うのか」を決めます。共有型、ブリッジ型、専用型にはそれぞれ利点と負担があり、すべての顧客に同じ方式を適用する必要はありません。機密性や性能が必要な顧客だけ専用環境へ移せるハイブリッド型も含め、事業の成長シナリオから選びます。

RFPにはテナント数、ユーザー数、データ量、性能、認証、権限、監査ログ、バックアップ、解約・削除、再委託、データ所在地を記載します。見積もりは工程別に分け、分離テストや負荷試験、移行、保守を含むか確認します。契約では成果物、変更管理、責任分界、権利、データ返却と削除を明確にし、3社程度以上の提案を同じ条件で比較すると、価格だけでは見えない差を判断しやすくなります。

いきなり開発会社へ「マルチテナント対応で作ってください」と依頼するのではなく、異なるテナントでのログイン、データ取得、ファイル、CSV、通知、バックアップ復元を検証するPoCの範囲を決めます。発注先には、どの層でテナントを識別・認可し、どのテストで漏えいを防ぐのかを説明してもらいます。発注者側の業務知識と、委託先の設計・実装・運用力を組み合わせることで、初期費用だけでなく、顧客追加後も安全に成長できるシステムを目指せます。

▼全体ガイドの記事
・マルチテナントのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。