SaaSのテスト観点｜事故る7領域の確認項目

2026 8/24

2026年8月24日 2026年8月24日

SaaSのテスト観点は、単機能のWebアプリと同じ感覚でリストを作ると、必ずと言っていいほど抜けが出ます。共有された基盤の上で複数の顧客が同居する構造そのものが、通常のテストでは見えない事故ポイントを生むからです。

しかも厄介なのは、これらの抜けがリリース直後には表面化せず、テナント数が増えたある日に「他社のデータが見えた」「請求額がおかしい」という形で一気に噴き出すことです。

本記事では、マルチテナントSaaS特有で漏れやすい確認項目を、事故りやすい順に7領域へ整理しました。各領域を「なぜ漏れるか → 破れると何が起きるか → 確認項目」の三段で示すので、自社の観点表の抜け漏れ点検にそのまま使えます。

SaaSのテスト観点が漏れやすい理由と4大事故ポイント

SaaSのテスト観点とは、データ分離・権限・課金・プラン制御・共通アップデート・オンボーディング・可用性という、マルチテナント特有で漏れやすい7領域の確認軸を指します。

まず、なぜSaaSでは観点が漏れるのかを押さえておきます。原因は構造にあります。

共有基盤：DB・キャッシュ・検索インデックスを複数テナントで共有するため、分離が一箇所でも甘いと全テナントに波及する
共通コード：全顧客が同じコードベースを使うため、1回の変更が想定外のテナントに影響する
組み合わせの掛け算：プラン × ロール × テナント設定の組み合わせが爆発し、代表1パターンの確認では網羅できない

単機能アプリのテスト観点をそのまま流用すると、この「掛け算」の部分がまるごと抜け落ちます。

SaaSで特に事故が集中するのは、次の4大ポイントです。まずここを最優先で検証する、という優先順位付けに使ってください。

事故ポイント	典型的な実害	事故りやすさ
① テナント間データ越境	他社データ閲覧・情報漏洩	最大
② 権限昇格	越権操作・管理機能の乗っ取り	大
③ 課金の境界（日割り・上限）	過剰請求・請求漏れ・二重課金	大
④ 共通アップデートによるデグレ	特定顧客だけ機能停止・数値ズレ	中〜大

本記事の7領域はこの事故りやすさ順に並べています。上から順にチェックリストとして潰していけば、被害の大きい事故から先に手当てできます。

ただし、上から順に潰すというのは「上位領域が終わるまで下位に着手しない」という意味ではありません。データ分離と権限は毎リリースの回帰対象として固定し、課金やプラン制御は該当機能に変更が入ったリリースで重点的に見る、というように領域ごとに確認の頻度を変えるのが実務的です。工数が限られるほど、この頻度設計が品質を左右します。

なお、テスト観点そのものを体系的に洗い出す手順は本記事の範囲外です。網羅的な観点表の作り方はテスト観点の洗い出しテクニックを確認するを併せて参照してください。ここではSaaS固有の「漏れやすい急所」に絞ります。

マルチテナントのデータ分離｜テナント越境をどう潰すか

テナントAとテナントBを隔てる壁をUIは遮断するが、API直叩き・帳票出力・バッチ・通知の裏経路が壁を迂回して越境する図

最も被害が大きいのがデータ分離です。テナントの壁を越えて他社のデータに触れられる状態は、それ自体が重大インシデントになります。

なぜ漏れるか

共有DBで全テナントのレコードを同じテーブルに格納している場合、WHERE tenant_id = ? という絞り込みが1箇所でも欠けると、その経路だけ壁が消えます。IDの取り違え、共有インデックスの混在、共有ストレージのパス設計の甘さも同じ穴になります。

分離方式によっても穴の出方は変わります。全テナントを1つのスキーマに同居させる方式（共有スキーマ）では、アプリ側の絞り込み条件が唯一の壁になるため、実装漏れがそのまま越境につながります。テナントごとにスキーマやデータベースを分ける方式なら壁は厚くなりますが、接続先の切り替えを誤ると別テナントに書き込む事故が起きます。どちらの方式でも「壁がどこにあるか」を把握し、その壁を通らない経路がないかを疑うのが出発点です。

破れると何が起きるか

他テナントのデータが1件でも見えたら、それは情報漏洩です。契約解除や損害賠償に直結し、SaaS事業者にとっては信頼の失墜という回復困難なダメージになります。テナント越境や権限昇格の類型はOWASP Top 10 2021のA01: Broken Access Controlでもアクセス制御の破れとして筆頭に位置づけられており、Webアプリで最も頻出する脆弱性です。国内の実務ではIPA「安全なウェブサイトの作り方」がアクセス制御と認可の考え方を公的に整理しており、確認項目の裏付けとして使えます。

確認項目

ここで意識したいのが、テストの目的の切り分けです。「正しい権限を持つ主体が正しく操作できるか」を見るのが機能テスト（正常系）、「許可されない主体が他社データへ到達できないか」を見るのがセキュリティテスト（負の経路）です。テナント越境の実証は後者にあたり、正常系のケースだけを積み上げても壁の穴は見つかりません。

盲点は、画面（UI）以外の経路です。UIの一覧画面だけ確認して安心すると、次の経路がすり抜けます。

検索・一覧：フィルタ条件からtenant_idが抜けていないか
API直叩き（オブジェクトレベル認可）：他テナントのIDを指定して他社の個別オブジェクトを取得・更新できないか
帳票・PDF出力：出力処理が独自クエリを使い、絞り込みを再実装していないか
メール・通知：宛先の解決が別テナントのユーザーを拾っていないか
バッチ・集計：夜間バッチの集約単位がテナントをまたいでいないか
エクスポート／インポート：CSV出力・取り込みでテナント境界が保たれているか
キャッシュ・全文検索インデックス：キャッシュキーや検索インデックスがテナント単位で分離されているか
ファイル／オブジェクトストレージ：保存パスやバケットがテナント単位で分離され、他社ファイルのURLに到達できないか
論理削除データ：削除済みフラグのレコードが検索・復元・エクスポート経路から越境しないか
ログ・監査証跡：ログや監査ログに他テナントの情報が混在していないか
Webhook等の外部連携：連携先へ送るペイロードに別テナントのデータが混ざっていないか

UIで正しく絞り込めていても、API・帳票・バッチ・通知は別実装であることが多く、そこから壁が破れます。各経路を独立に「他テナントのデータに到達できないか」で確認するのが鉄則です。

検証の具体的な進め方としては、テナントAとテナントBの2つを用意し、Aのユーザーでログインした状態でBのデータのIDを指定して各経路にアクセスする、という交差テストが基本形です。UIで拒否されても、同じ操作をAPIリクエストとして直接送ると通ってしまうことがあるため、必ずリクエスト単位で再現します。返ってきたレスポンスに他テナントの件数やIDが混ざっていないかを、目視ではなく期待件数との突き合わせで機械的に判定するのが確実です。

この交差テストは、一度書けば毎リリース自動で回せる形にしておく価値が特に高い領域です。データ越境は起きた瞬間に重大インシデントになる一方で、機能追加のたびに新しい経路が増えていくため、手動での見張りは早晩破綻します。主要な取得系・更新系のエンドポイントについて、他テナントIDでのアクセスが必ず拒否されることを検証する自動テストを、リグレッションスイートの中核に据えてください。

権限・ロールのテスト観点｜権限昇格を防ぐ

データ分離の次に事故が大きいのが、権限（ロール）の設計です。テスト観点として、ロールごとの可視・操作範囲は必ず正面から検証します。

なぜ漏れるか

ロールと機能の組み合わせが多く、パターンが爆発します。さらに「ボタンをUIで非表示にしているだけ」で権限を制御した気になっているケースが典型です。

破れると何が起きるか

一般ユーザーが管理機能を実行できると、越権操作・他ユーザー情報の改ざん・テナント管理機能の乗っ取りにつながります。

UIで隠すだけの制御は、APIから素通りします。ボタンを消してもエンドポイントが生きていれば、直接リクエストで実行されます。

確認項目

操作	一般ユーザー	テナント管理者	全体管理者
自テナントのデータ閲覧	○	○	○
ユーザー招待・権限変更	×	○	○
課金・プラン変更	×	○	○
他テナントの管理	×	×	○

上のようなロール × 操作の可否マトリクスを作り、以下を確認します。

直リンク・APIで、権限外の操作が拒否されるか（可視だけでなく実行も遮断）
招待中・脱退後・ロール変更直後に、権限が即座に正しく反映されるか
テナント管理者と全体管理者の権限が明確に分離されているか

認可は2つの層で考えると漏れにくくなります。1つは「この機能を使ってよいか」という機能単位の認可、もう1つは「この特定のデータを操作してよいか」というデータ単位の認可です。前者だけを実装して後者が抜けると、正しい機能画面から他人のデータIDを指定して操作できてしまいます。機能が使えることと、そのデータに触れてよいことは別問題として、両方を確認してください。

ここで工数の壁になるのが組み合わせ爆発です。すべてを全網羅するのは非現実的なので、軸ごとに濃淡を付けます。事故時の被害が大きい高リスク軸（テナントID × 操作可否）は全網羅し、それ以外の多条件はペアワイズ（オールペア）で組み合わせ数を絞ります。

こうした「条件の組み合わせ」を漏れなく整理するには判定表が有効です。どの条件のときにどの結果になるべきかを表として書き出すと、確認済みと未確認の区別が一目でつきます。プラン × 権限のような多条件は判定表テストで条件組み合わせを整理する方法を読むが役立ちます。

なお、権限やデータ分離の検証は専門性が高く、兼任体制では負荷が大きい領域です。外部の力を借りる判断軸を知りたい方はSaaSのテスト外注で押さえる判断項目を読むも参考にしてください。

課金・サブスクリプションのテスト観点｜日割り・上限の境界

トライアルから有効・支払い失敗・猶予期間・停止・復活・解約へ至るサブスク契約の状態遷移と、プラン変更時の日割り再計算・起きてはならない無効遷移を示す図

金銭が絡む課金は、事故が即座に信頼失墜へ変わる領域です。テスト観点の中でも、境界条件の詰めが甘くなりやすい急所です。

なぜ漏れるか

反映タイミング（即時か次回請求か）、締め日、日割り計算の境界が仕様として曖昧なまま実装されることが多いためです。

課金の反映タイミングは、仕様として明文化しない限りテストできません。「いつから・いくら」を先に定義することが、テスト設計の前提になります。

破れると何が起きるか

過剰請求・請求漏れ・二重課金は、そのまま金銭事故です。返金対応やクレームだけでなく、「請求すら正確でない」という不信感が解約につながります。

確認項目

境界と状態遷移の2軸で確認します。

反映時点：アップグレード／ダウングレードが即時か次回請求サイクルか
日割りの境界：月初・月末・うるう年など日数の境目で金額が正しいか
支払い失敗：カード決済失敗時のリトライ・猶予期間・利用制限・復帰の挙動
従量・数量課金：集計の単位（日次／月次）と上限到達時の扱い

課金テストで見落とされがちなのが、検証環境の準備そのものです。決済代行サービスのサンドボックスを使い、成功・失敗・遅延といった応答を意図的に再現できる状態を整えておく必要があります。また、日割りや更新日の検証にはシステム時刻を進める操作が欠かせません。時刻を固定・操作できないと、月末や更新日の境界を再現するために実際の日付を待つことになり、テストが回らなくなります。

金額そのものの正しさに加えて、請求書や領収書の表示も確認対象です。税率や端数処理の丸め方、複数プランを併用したときの合算、途中解約時の返金額など、金額を人が読む最終成果物の段階で誤りが出ると、たとえ内部計算が正しくてもクレームになります。計算ロジックと表示の両方を、代表的な料金パターンで突き合わせておくと安心です。

日割りや上限の金額は、まさに境界値でバグが出ます。境界の設計は境界値分析のやり方と実践ポイントを確認するが具体的です。

契約状態の移り変わりも重要です。次のような遷移を漏れなく確認します。

遷移	確認したい挙動
トライアル → 有効	課金開始・機能開放のタイミング
有効 → プラン変更	日割り・上限の再計算
支払い失敗 → 猶予期間 → 停止	利用制限のかかる範囲と通知
停止 → 復活（支払い再開）	機能再開のタイミングと請求の起点
有効 → 期限切れ	自動更新の有無とデータ保持
解約 → 再開	過去データの復旧・再課金の起点

起きてはならない無効遷移（例：解約済みなのに課金再開ステップが飛ばされる、停止中に上位機能が使える等）も、正常な遷移と同じ重みで確認します。この状態遷移の網羅は状態遷移テストでサブスク契約の遷移を検証する手法を読むで体系的に扱えます。トライアルから解約・再開までの経路を図にすると、抜けている遷移が一目で分かります。

プラン別機能制御（フィーチャーフラグ）のテスト観点

多くのSaaSはプランごとに使える機能を切り替えます。ここの制御漏れは、機会損失と不公平を生みます。

なぜ漏れるか

プラン × フィーチャーフラグ × 上限の組み合わせが多く、確認しきれないためです。データ分離と同様、UIで非表示にしただけで裏の機能が生きているパターンが頻発します。

破れると何が起きるか

下位プランで上位機能が使えてしまう（正当に課金している顧客との不公平・収益機会の損失）
上限（ユーザー数・容量・API回数）を超えても止まらず、データ破損やパフォーマンス劣化を招く

プラン制御は「使えないはず」を確認するテストであり、正常系だけ見ても抜けは見つかりません。

確認項目

機能・上限	下位プラン	上位プラン	確認ポイント
上位機能A	×	○	直リンク・APIでも遮断されるか
ユーザー数上限	少	多	上限到達時に追加を拒否するか
データ容量	小	大	超過時の挙動（拒否・警告）

プラン別の機能ON/OFFマトリクスを作り、OFF側をAPIレベルで確認する
上限到達時に、エラーで止まるのか、黙って超過するのかを検証する
ダウングレード後、上位プランで作ったデータの表示・エクスポートがどうなるか
フラグ切替がリアルタイムに反映されるか（キャッシュで古い状態が残らないか）

フィーチャーフラグは、コード内の分岐だけでなく、契約情報・設定ファイル・管理画面など複数の場所で管理されることがあります。管理元が分散していると、ある場所では無効なのに別の場所の設定で有効になっている、といった食い違いが生じます。フラグの「正」がどこにあるかを一本化し、その1箇所を変えたときに全経路へ正しく反映されるかを確認してください。

見落としやすいのが、プラン変更をまたいだデータの整合性です。上位プランでのみ作れるデータを持ったまま下位プランへ落ちたとき、そのデータを閲覧だけは許すのか、完全に隠すのか、エクスポートは認めるのかは仕様として明確に決めておく必要があります。ここが曖昧だと、ダウングレード後に「見えるはずのデータが消えた」「消したはずの機能が使えた」といった問い合わせが必ず発生します。

継続的アップデートのテスト観点｜共通コード変更による特定テナントのデグレ

1つの共通コード変更が全テナントへ配信され、テナントA・Bは正常だがカスタマイズの濃いテナントCだけデグレする様子と、カナリアリリース・代表テナント回帰で先行検知する流れを示す図

SaaSは全顧客が同じコードを使うため、1回のアップデートが特定のテナントだけを壊すことがあります。

なぜ漏れるか

テナントごとに設定・カスタマイズ・データ量が異なるためです。代表1テナントで動作確認しても、別の設定を持つテナントでは再現しない不具合を見逃します。

「うちの検証環境では動いた」は、全テナントで動く保証にはなりません。

破れると何が起きるか

特定顧客だけ画面が崩れる、機能が停止する、集計値がずれる、といった障害が起きます。全体障害よりも発見が遅れやすく、その顧客の信頼を個別に失います。

確認項目

設定バリエーション別のリグレッション：主要な設定パターンを代表テナントとして選び、回帰確認する
代表テナント選定基準：データ量が多い・カスタマイズが濃い・古くからの顧客など、リスクの高い条件を選ぶ
段階リリース：カナリアリリースで一部テナントに先行適用し、影響を観測する
ロールバック可否：問題発生時に安全に戻せるか、データ移行を伴う変更は戻せるかを事前確認する

特に注意したいのが、データベースのスキーマ変更を伴うアップデートです。テナントごとにデータ量が大きく異なるため、小さなテナントでは一瞬で終わるマイグレーションが、大規模テナントでは長時間のロックを引き起こし、その間だけサービスが止まることがあります。データ量が最大級のテナントに近い規模のデータで、移行にかかる時間とロックの影響を事前に測っておくと安全です。

毎リリースで全テナントを手で確認するのは現実的ではありません。継続的アップデートの現実解は、リスクの高い代表テナント2〜3件を固定の回帰セットにし、そこは自動化して毎リリース回すことです。回帰の観点を体系的に組み立てる際は、観点表アプローチをテナント設定という軸に当てはめると整理しやすくなります。

オンボーディングと可用性のテスト観点｜初期状態とノイジーネイバー

最後は、入口（オンボーディング）と全体の安定性（可用性）です。地味ですが、ここの不備は後続の全機能に波及します。

なぜ漏れるか

新規テナント作成やサインアップは開発初期に一度作られたきり、その後のテストで軽視されがちです。可用性はテナント数が増えて初めて問題が顕在化するため、初期のテストでは見えません。

破れると何が起きるか

サインアップや招待でつまずくと、そもそも使われる前に離脱する
テナント作成直後の初期データ・デフォルト権限が不正だと、後続の全操作が誤った前提の上で動く
1テナントの高負荷が基盤を占有し、他の全テナントを巻き込む（ノイジーネイバー問題）

1テナントの重いバッチが、無関係な他社の画面を遅くする——共有基盤ではこれが普通に起きます。

確認項目

分類	確認項目
認証・入口	サインアップ・招待・SSO/認証の各経路が網羅されているか
初期状態	テナント作成直後の初期データ・デフォルト権限が正しいか
可用性	テナント数増加時の性能劣化、応答時間の変化
リソース隔離	1テナントの高負荷が他テナントに波及しないか、テナント単位のレート制限が効くか

認証経路は正常系だけでなく、招待期限切れ・重複招待などの異常系も確認する
可用性とノイジーネイバーは非機能（性能）テストの領域です。複数テナントの同時負荷を生成し、他テナントのレイテンシ劣化を閾値で判定します

入口と対になるのが出口、つまり退会とテナント削除の処理です。テナントを削除したのに関連データが一部残ると、他テナントの集計に混入したり、同じ識別子で再登録したときに古いデータが復活したりします。削除が全テーブル・全ストレージに波及しているか、削除後にそのテナントのデータへどの経路からも到達できないかを確認してください。個人情報の削除要求への対応という観点でも、この出口の検証は軽視できません。

可用性やノイジーネイバーは、テストだけで守り切れる領域ではありません。事前のテストで「どの規模でどの程度劣化するか」の当たりを付けつつ、本番では監視とアラートで異常を早期に検知する、という役割分担が現実的です。テスト段階では、テナント単位のレート制限やタイムアウトといった保護機構が実際に働くことを確認しておけば十分で、あらゆる負荷パターンを再現しようとする必要はありません。

なお、リソース隔離そのものの作り込みは基盤側の責務です。PMがテスト観点として最低限押さえるべきは「上限規模のテナントで重い処理を流し、他テナントの応答が保たれるか」という1シナリオに絞ってよい、というのが身の丈の現実解です。

SaaSのテスト観点チェックリストを体制に組み込む

ここまでの7領域を、チェックリストとして再掲します。

データ分離：UI以外（API・帳票・バッチ・通知・ストレージ・ログ・外部連携）からの越境
権限・ロール：APIレベルでの権限昇格の遮断（負の経路の検証）
課金：日割り・上限の境界と契約状態遷移（無効遷移を含む）
プラン別機能制御：使えないはずの機能・上限超過の挙動
継続的アップデート：設定バリエーション別のデグレ
オンボーディング：入口と初期状態
可用性：ノイジーネイバーとリソース隔離

まず①〜③（データ越境・権限昇格・課金）の被害が大きい領域から潰すのが、限られた工数での最適解です。他社データ露出は契約解除・賠償に、誤請求は信頼失墜に直結するため、事故時の被害が大きい順に優先順位を付けてください。

兼任・少人数でも回せる最小構成

すべてを一度に整備しようとすると必ず溢れます。最小構成として、まず①データ分離のAPI／エクスポート経路と②権限マトリクスの2つを最優先で1スプリントに載せてください。この2領域は事故時の被害が最も大きく、ここだけ先に固めるだけでも重大インシデントの芽は大きく減らせます。

工数配分の観点では、全領域を毎回同じ密度で見る必要はありません。次のように「手動で都度」と「自動化して毎リリース」を切り分けると回しやすくなります。

区分	向いている領域	進め方
手動で都度確認	オンボーディング・初期状態、稀な仕様変更部分	リリース内容に応じて都度チェック
自動化して毎リリース	データ分離・権限・課金の負の経路	代表テナントの固定回帰セットで自動化

回帰セットは一度作って終わりではなく、事故やヒヤリハットが起きるたびに1項目ずつ追加して育てていくものです。実際に起きた越境や誤請求は、最も費用対効果の高いテストケースになります。障害対応の振り返りで「この観点があれば防げた」という項目を必ず1つ回帰セットに足す、という運用にすると、観点表は放っておいても実態に即して厚くなっていきます。

まず月曜からやる一歩

大きな整備計画の前に、月曜からできる一歩があります。直近リリースの権限マトリクスを1枚だけ埋め、空欄＝未テスト領域として可視化してください。埋まらないマスがそのまま、いま事故が起きうる穴です。

そのうえで、自社で回すと恒常的に溢れる領域が見えてきたら、その領域は外注に切り出したほうが費用対効果で有利になることが多いです。テスト観点の抜け漏れ点検や、兼任中心のテスト体制の見直しを検討されている方は、テスト体制の見直しについて相談するからお気軽にお問い合わせください。現状の観点表のどこに穴が空きやすいか、一緒に整理するところから始められます。

よくある質問

Q. SaaSのテスト観点で最初に確認すべきはどこですか。 被害が最大のデータ分離、特にAPI・エクスポート経路からのテナント越境です。次に権限マトリクスによる権限昇格の遮断を押さえます。この2つは事故時の損害が契約解除・賠償に直結するため、最優先で固めます。

Q. 全部の観点を毎リリース回すのは無理があります。 無理に全網羅する必要はありません。データ分離・権限・課金の負の経路をリスクの高い代表テナント2〜3件の固定回帰セットにして自動化し、それ以外は手動で都度確認する、という濃淡の付け方が現実的です。

Q. マルチテナント特有の観点は、どうやって既存の観点表に足せばよいですか。 既存の機能ベースの観点表に、テナントという軸を1列足すのが手早い方法です。各機能について「他テナントから見えないか」「プランで正しく制御されるか」を問う列を加えるだけで、本記事の急所の多くをカバーできます。ゼロから作り直す必要はなく、いまある表を拡張する形で十分です。