非機能テストの項目一覧テンプレート｜カテゴリ別確認項目

2026 10/28

2026年10月28日

「機能はひととおりテストしたはずなのに、本番でシステムが固まった」「負荷がかかった途端にレスポンスが返らなくなった」。受託開発の現場では、こうしたトラブルの多くが非機能面の確認漏れから起きています。

非機能面の確認項目は、機能テストのように画面や仕様書から自然に洗い出せるものではありません。そのため担当者の経験に依存しやすく、抜けに気づくのはたいてい本番稼働後という構造的な問題を抱えています。リリース直前に慌てて確認し、十分に詰め切れないまま出してしまった経験のある方も多いはずです。

この記事では、非機能テストの項目を抜けなく洗い出すための一覧テンプレートを、カテゴリ別の確認項目・測定方法・判定基準の例とともに示します。あわせて目標値の決め方、スコープの線引き、現場でよくある抜け・失敗例まで、テスト計画にそのまま転用できる粒度で整理します。コピーして自社の目標値を書き換えれば、そのままチェックリストとして使える構成にしています。

非機能の品質は「仕様書に書かれていない要求」をどれだけ具体的なテスト項目に翻訳できるかで決まります。定義の話はほどほどに、使える一覧づくりに軸足を置いて進めます。

非機能テストの項目とは何か｜機能テストとの違い

非機能テストとは、「正しく動くか」ではなく「どれだけうまく動くか」を確認するテストの総称です。表示内容が仕様どおりかを見る機能テストに対し、非機能テストは速度・同時アクセス耐性・障害からの復旧・セキュリティ・運用のしやすさといった品質特性を対象にします。

国際規格の ISO/IEC 25010 では、ソフトウェア品質を「機能適合性」を含む複数の品質特性に分類しており、性能効率性・信頼性・セキュリティ・互換性・保守性・移植性などが非機能側の柱になります。非機能面のテスト項目は、この品質特性を自社システムの文脈に落とし込む作業だと考えると整理しやすくなります。抽象的な品質特性のままでは測れないため、「何を・どう測り・どの値なら合格か」まで具体化するのが実務の役割です。

機能テストと非機能テストの違いを、観点の出どころで比べると次のようになります。

比較軸	機能テスト	非機能テスト
確認する問い	仕様どおりに動くか	どれだけうまく動くか
項目の出どころ	画面・機能仕様書	品質特性・運用要件・SLA
判定の基準	期待結果と一致するか	目標値（閾値）を満たすか
抜けに気づく時期	テスト工程内が多い	本番稼働後が多い
担当者の依存度	比較的低い	高い（経験に左右される）

機能テストは「期待結果との一致」で合否が出るのに対し、非機能テストは事前に目標値を決めておかないと合否判定そのものができません。ここが最初のつまずきどころです。「遅い気がする」「たぶん大丈夫」といった主観で判断すると、クライアントとの間で水掛け論になります。

機能テストと非機能テストの関係を押さえるうえで、次の点は特に重要です。

機能テストが終わっても、非機能テストは別に計画する必要がある
項目は「仕様書に書かれていない要求」から作るため、意識して洗い出す
合否判定には目標値（閾値）の事前定義が前提になる
測定には本番に近い環境・データ量が欠かせない

なお、用語の定義や資格体系を正確に確認したい場合は、JSTQB（日本ソフトウェアテスト技術者資格認定）の公式サイトが参考になります。本記事では定義の深掘りよりも、現場で使える項目の洗い出しに焦点を当てます。

非機能テストの項目を洗い出す6つのカテゴリ

ゼロから思いつきで考えると、非機能の観点は必ず漏れます。先にカテゴリの枠を用意し、各カテゴリに該当する項目を当てはめていく進め方が確実です。本記事では、受託開発で扱う機会の多い6カテゴリに整理します。

IPA（情報処理推進機構）が公開する非機能要求グレードの紹介ページでも、非機能要求を「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の大項目に分類しています。この公的な分類を参考に、テスト項目へ落とし込みやすい形へ再編したものが下表です。

カテゴリ	何を確かめるか	代表的な関心事
性能・負荷	速度と同時処理の耐性	レスポンスタイム、スループット、ピーク時の挙動
可用性・障害復旧	止まらない・早く戻る	稼働率、冗長化、RTO・RPO
セキュリティ	守れているか	認証認可、脆弱性、通信暗号化
運用・保守性	運用しやすいか	監視、ログ、バックアップ、デプロイ
互換性	環境差で壊れないか	ブラウザ、OS、端末、外部連携
拡張性・キャパシティ	増加に耐えられるか	データ増、利用者増、リソース余力

カテゴリの枠を先に固定してから項目を埋めると、「考えつかなかった観点」を機械的にあぶり出せます。属人的な洗い出しから脱却する最初の一歩です。

カテゴリを使うときのコツは次の3点です。

全カテゴリをいったん机に並べる：対象外と判断する場合も「なぜ対象外か」を記録しておく
システムの性質で重み付けする：toC のWebなら性能・可用性、社内基幹ならセキュリティ・運用を厚くする
要件定義の非機能要件と突き合わせる：要件に書かれた目標値をテスト項目の判定基準に引き継ぐ

6カテゴリはあくまで出発点です。決済や個人情報を扱うなら移行性やコンプライアンスを足す、組込み系ならリソース制約を厚くするなど、案件の性質に応じて枠自体を調整してください。大切なのは「枠を見ながら考える」状態を作ることです。

カテゴリ別の非機能テスト項目一覧テンプレート

ここからが本記事の中心です。カテゴリごとに「確認項目」「測定方法」「判定基準の例」を表にしました。判定基準の数値はあくまで一例であり、実際の値は後述する「目標値の決め方」に沿って自社システムの要件から決めてください。そのまま貼り付けて、自社の目標値列を書き換える使い方を想定しています。

表は一度作って終わりにせず、プロジェクトの進行に合わせて更新していく「生きたチェックリスト」として扱うのがおすすめです。測定を終えた項目には実測値と合否を書き足し、未達の項目は改善・再テストの記録を残します。こうして運用すると、テストの進捗と残課題が一枚の表で把握でき、クライアントや上長への報告資料としてもそのまま使えます。確認項目の列に「担当者」と「実施予定日」を足せば、簡易な進捗管理表にもなります。

性能・負荷のテスト項目

性能・負荷は、非機能テストの中でも本番影響が大きく、やり直しコストの高いカテゴリです。平常時と繁忙期（ピーク）を分けて考えるのが実務の基本になります。

確認項目	測定方法	判定基準の例
平常時レスポンスタイム	主要画面の応答時間を計測	主要画面が3秒以内（例）
ピーク時レスポンスタイム	想定ピーク同時数で負荷をかけ計測	劣化しても5秒以内（例）
スループット	単位時間あたりの処理件数を計測	100件/秒以上（例）
同時接続耐性	同時ユーザー数を段階的に増加	想定の1.5倍まで破綻しない（例）
長時間稼働（耐久）	一定負荷を数時間継続	メモリリークなし・応答維持

スループットは単位時間あたりに処理できる量、レスポンスタイムは1件あたりの応答時間を指します。両者は別の指標なので、片方だけで合否を決めないよう注意してください。たとえばスループットは十分でも、1件あたりの応答が遅ければ利用者の体感は悪くなります。

負荷のかけ方やシナリオ設計を体系的に詰めたい場合は、パフォーマンステストの基本と実践手順をまとめた記事が参考になります。繁忙期のピークを外注で検証したい場合の依頼範囲は、負荷テストの外注で押さえる勘所をまとめた記事が実務の助けになります。

性能テストは「平均値」ではなくピーク時と最悪値（最も遅い応答）で評価するのが鉄則です。平均が速くても、繁忙期の一瞬の詰まりがクレームにつながります。

可用性・障害復旧のテスト項目

可用性は「止まらないこと」、障害復旧は「止まっても早く戻せること」です。両輪で設計し、わざと壊して戻す試験まで含めて初めてテストしたと言えます。構成図の上で冗長化されていても、実際に切り替わるかは試さないと分かりません。

確認項目	測定方法	判定基準の例
冗長構成の切替	稼働系を停止し待機系へ切替	自動切替が成功する
目標復旧時間（RTO）	障害発生から復旧までを計測	2時間以内に復旧（例）
目標復旧時点（RPO）	復旧後のデータ欠損範囲を確認	直近5分以内（例）
バックアップ復元	バックアップから実際に復元	手順書どおり完了する
縮退運転	一部機能停止時の継続性を確認	主要業務は継続できる

RTO（Recovery Time Objective）は「いつまでに復旧するか」、RPO（Recovery Point Objective）は「どの時点まで戻せるか（許容データ損失量）」を表す指標です。両者は混同されがちなので、要件定義の段階で定義をそろえておきます。RTOを短くするほど冗長化や自動化のコストが上がるため、業務の許容停止時間から逆算して決めるのが現実的です。

バックアップは「取得できている」ではなく「復元できる」まで確認する
切替手順は、担当者がいない夜間でも実行できるかを検証する
障害訓練は机上ではなく、検証環境で実際に止めて行う
復旧後にデータの整合性が保たれているかまで確認する

セキュリティのテスト項目

セキュリティは発覚時の損失が大きく、クライアントの信頼を直接左右します。認証認可の確認と、脆弱性の有無の確認を分けて進めます。両者は性質が異なり、前者は仕様の検証、後者は攻撃者視点での探索になります。

確認項目	測定方法	判定基準の例
認証	不正なログイン試行を実施	失敗時に適切に拒否・ロック
認可（権限）	権限外の操作・URL直打ちを試行	他者データへアクセス不可
通信暗号化	HTTPS・TLS設定を確認	平文通信が存在しない
既知脆弱性	脆弱性スキャンツールで検査	重大度「高」の検出ゼロ
入力検証	不正値・境界値を投入	SQLインジェクション等が成立しない

脆弱性検査の進め方や自動化の考え方を知りたい場合は、セキュリティテストの基本と実践をまとめた記事が実務の助けになります。ツールによる機械的なスキャンと、権限設計を踏まえた手動確認は役割が違うため、両方を計画に組み込みます。

セキュリティで最も漏れやすいのは、認証（本人確認）ではなく認可（権限制御）の確認です。ログインできた利用者が、本来見えてはいけないデータに到達できないかを必ず試します。画面の導線上は制御されていても、URLやAPIを直接叩くと通ってしまう例が後を絶ちません。

運用・保守性のテスト項目

運用・保守性は、リリース後に効いてくるカテゴリです。開発中は意識されにくく、本番で運用チームが困って初めて不足が露呈します。「作って終わり」ではなく「運用し続けられるか」を問う視点が求められます。

確認項目	測定方法	判定基準の例
監視・アラート	異常を意図的に発生させる	想定時間内に通知が届く
ログ出力	エラー再現時のログを確認	原因特定に足る情報が残る
バックアップ運用	定期取得ジョブを確認	スケジュールどおり取得
デプロイ・切戻し	リリースと切戻しを試行	手順どおり安全に戻せる
設定変更	設定値変更の反映を確認	再起動要否が明確である

ログは「出ている」だけでは不十分で、障害発生時に原因へたどり着けるかが判定の肝になります。運用担当者に実際のログを見てもらい、調査できるかをレビューすると精度が上がります。開発者にしか読めないログは、夜間の一次対応では役に立ちません。

監視項目は「正常範囲」と「アラート閾値」をセットで定義する
切戻し手順は、リリース当日に慌てないよう事前に通しで試す
ログには個人情報や認証情報を出力していないかも確認する

互換性のテスト項目

互換性は、利用環境の多様さに起因する不具合を防ぐカテゴリです。対象環境を無限に広げるとコストが膨らむため、要件で範囲を絞り込みます。開発者の手元では再現しない不具合が出やすい領域でもあります。

確認項目	測定方法	判定基準の例
ブラウザ互換	対象ブラウザで表示・操作確認	対象全ブラウザで崩れなし
OS・端末互換	対象OS・端末で動作確認	主要操作が完了できる
画面サイズ	複数解像度で表示確認	レイアウト崩れなし
外部システム連携	連携先とデータ送受信を確認	仕様どおり送受信できる
文字コード	多言語・特殊文字を入力	文字化け・欠落なし

対象ブラウザや端末は「シェア上位」と「クライアント指定環境」の両面から決めます。外部連携は相手側の仕様変更で壊れやすいため、連携テストは継続的に回せる形にしておくと安心です。相手システムのテスト環境が使えるかどうかも、早めに確認しておきたいポイントです。

互換性テストは対象環境を要件で明示的に絞ることが、コストと品質を両立させる唯一の方法です。「全ブラウザ対応」を曖昧に掲げると、終わりのないテストになります。

拡張性・キャパシティのテスト項目

拡張性・キャパシティは、将来の増加に耐えられるかを確かめるカテゴリです。リリース時点で足りていても、データや利用者の増加で数か月後に破綻する例が少なくありません。「今」ではなく「将来の想定値」で試すのが特徴です。

確認項目	測定方法	判定基準の例
データ量増加	将来想定のデータ量を投入	応答が目標値内に収まる
利用者増加	想定成長後の同時数で負荷	破綻せず劣化が許容内
リソース余力	CPU・メモリ使用率を計測	ピーク時でも余力を残す
スケール対応	サーバ増設・増強を試行	増強で性能が向上する
ストレージ逼迫	容量上限付近の挙動を確認	逼迫前に警告が出る

将来の増加をどう見積もるか、リソース余力をどれだけ残すかという設計は、キャパシティプランニングの基本と実践をまとめた記事で体系的に扱っています。テスト項目を決める前提として、増加の前提値をそろえておくと判定がぶれません。特にデータ量は、件数が増えると検索やバッチの応答が急に悪化することがあるため、将来想定での再計測が有効です。

目標値（判定基準）の決め方と現場の判断基準

非機能テストの項目は、目標値が決まって初めて合否判定ができます。ところが要件定義で「速いこと」「安定していること」としか書かれておらず、テスト段階で数値に詰まるケースが後を絶ちません。ここでは目標値を決める実務の順序を示します。

目標値は、次の優先順位で決めていくと根拠が通ります。上から順に検討し、上位で決められない場合に下位へ降りていくイメージです。

契約・SLAに明記された値：最優先。合意済みのため判定基準に直結する
業務要件から逆算した値：「夜間バッチは翌朝6時までに完了」など業務の締切から導く
現行システムの実測値：リプレース案件なら現行以上を基準にする
一般的な感覚値：上記が無い場合の暫定。必ずクライアント合意を取る

判断に迷う点	現場での決め方
レスポンスの目標	利用者が離脱しない体感速度から逆算（例：主要画面3秒）
ピーク同時数	過去実績の最大値に安全係数を掛ける
稼働率・RTO	業務が止まって困る時間から許容停止時間を定義
脆弱性の許容	重大度「高」はゼロ、「中」以下は期限付き対応
互換環境の範囲	シェア上位とクライアント指定環境に限定

目標値に迷ったら、「この値を下回ると誰がどう困るか」を一文で書けるかを確認してください。書けない目標値は、根拠がなく後で揉める火種になります。

もう一つの実務ポイントは、目標値を「平常時」と「ピーク時」で分けることです。平常時は快適な体感を、ピーク時は「破綻しない下限」を基準にすると、過剰なチューニングを避けつつ本番トラブルを防げます。すべてを最高水準で狙うと費用対効果が悪化するため、どこに力を入れるかの判断が欠かせません。

目標値はクライアントと合意し、テスト計画書に判定基準として明記しておきます。口頭合意のままにすると、本番で問題が出たときに「言った・言わない」の議論になりがちです。数値と測定条件をセットで文書に残すことで、合否の判断がぶれなくなります。

「どこまでやるか」スコープの判断基準

非機能テストは、やろうと思えばいくらでも深掘りできます。限られた工数の中で、どこまでやるかを決めることが現場のPMの腕の見せどころです。全項目を一律に全力で実施するのではなく、リスクに応じてメリハリをつけます。少人数のテスト体制では、この割り切りができるかどうかが品質と納期を両立できるかの分かれ目になります。

スコープは、以下の2軸で項目を仕分けると判断しやすくなります。

影響度：その非機能が破綻したとき、業務・信頼にどれだけダメージがあるか
発生可能性：そのシステムの性質上、問題が起きやすいか

影響度 × 可能性	対応方針	例
高 × 高	重点的に実施	toCサービスの性能・可用性
高 × 低	要点だけ実施	社内ツールの大規模障害復旧
低 × 高	簡易確認	管理画面の軽微な表示崩れ
低 × 低	対象外（記録は残す）	ほぼ使われない環境の互換性

スコープを削る判断そのものを、「なぜやらないか」の記録とともにクライアントへ共有することが、後のトラブルを防ぎます。黙って省くと、本番障害時に「なぜテストしなかったのか」と問われます。

スコープを決めるときの実務上の注意点は次のとおりです。

「やらない」と決めた項目こそ、理由と合意を文書に残す
予算が限られるなら、影響度の高いカテゴリから順に工数を配分する
全カテゴリ浅く広くより、重要カテゴリを深くのほうが本番事故を防げる
一度決めたスコープも、仕様変更があれば見直す

費用対効果を上長やクライアントに説明する際は、この仕分け表がそのまま根拠資料になります。「どこに工数をかけ、どこを割り切ったか」を一枚で示せると、予算の合意が取りやすくなります。限られたリソースを最も効くところに集中させる判断は、専任のQAを置けない体制ほど重要になります。

非機能テストでよくある抜け・失敗例

ここでは、受託開発の現場で繰り返し起きる抜け・失敗例を、匿名化した典型パターンとして挙げます。いずれも「機能テストは完璧だったのに本番で問題が出た」ケースです。自社のチェックリストと照らし合わせてみてください。

失敗パターン	何が起きたか	防ぎ方
ピーク未検証	平常時のみ試験しキャンペーンで停止	ピーク時シナリオを必須項目にする
認可の抜け	URL直打ちで他社データが閲覧可能	権限外アクセスの試行を項目化
復元未確認	バックアップ取得のみで復元できず	復元まで含めて判定基準にする
ログ不足	障害時に原因が追えなかった	運用担当のログレビューを実施
目標値なし	「遅い」の判定で水掛け論	事前に数値目標を合意する

これらの失敗に共通するのは、「項目はあったが判定基準と実行条件が甘かった」という点です。項目を並べただけで安心せず、測定方法と合格ラインまで決め切ることが肝心です。

具体的な失敗の背景を補足すると、次のような事情が絡んでいることが多いものです。

ピーク未検証：開発環境の性能が本番と違い、平常時の体感で問題なしと判断してしまう
認可の抜け：画面上の導線でしか操作確認をせず、直接URLやAPIを叩く経路を試さない
復元未確認：バックアップジョブの成功ログだけを見て、実際に戻す訓練をしていない
目標値なし：要件が曖昧なまま着手し、テスト段階で基準を決められず判定が止まる

こうした抜けは、本記事のカテゴリ別テンプレートで項目を機械的に当てはめ、各項目に測定方法と判定基準をセットで書き込むことでかなり防げます。項目一覧はチームでレビューし、「この項目は誰がどう測るか」を言語化しておくと、担当者が替わっても品質が保てます。一人の経験に頼る状態から、チームで再現できる状態へ移すことが、抜けを減らす本質的な対策です。

非機能テストを実行に移すための進め方

ここまでのテンプレートを、実際のプロジェクトに落とし込む手順をまとめます。非機能テストの項目は、計画の早い段階で枠を決めておくほど、後工程での手戻りが減ります。リリース直前に慌てて洗い出すのではなく、要件定義から仕込んでおくのが理想です。

要件定義でカテゴリと目標値の枠を確保する：6カテゴリを並べ、対象・対象外と暫定目標値を仮置きする
テスト計画で項目一覧を確定する：本記事の表を自社用に書き換え、測定方法・判定基準を埋める
スコープを影響度×可能性で仕分ける：工数配分を決め、割り切る項目は理由を記録する
実行環境を本番に近づける：性能・負荷は特に、環境差が判定を狂わせる
結果を判定基準と突き合わせて合否を出す：数値で記録し、未達は改善と再テストへ回す

テスト項目を正式なドキュメントに落とす段階では、システムテスト仕様書テンプレートを解説した記事の様式に、非機能の項目行を追加していくとスムーズです。機能・非機能を同じ仕様書で管理すると、抜けや二重管理を防げます。

非機能の確認は、「計画で枠を決め、仕様書で確定し、実行で数値を取る」の3段階で管理すると漏れにくくなります。思いついたときに足す運用では、必ずどこかが抜けます。

よくある質問

非機能テストについて、受託開発のPMから寄せられることの多い質問をまとめました。この記事で扱った要点は、次の3つに集約できます。

項目はカテゴリの枠から機械的に洗い出し、測定方法と判定基準をセットで決める
目標値は契約・業務要件・現行実測の順に根拠を積み上げ、クライアントと合意する
スコープは影響度×可能性で仕分け、やらない項目も理由を記録して共有する

Q. 非機能テストはどの工程で実施すべきですか。 A. 項目の枠は要件定義で確保し、実行はシステムテスト工程で行うのが一般的です。性能・負荷は本番に近い環境が必要なため、環境が整う時期を逆算して計画します。遅く着手するほど、問題発覚時の手戻りが大きくなります。要件定義の段階でカテゴリと暫定目標値を仮置きしておくと、後工程の見積もりも安定します。

Q. 全項目を毎回やる必要がありますか。 A. 必要ありません。影響度と発生可能性で仕分け、重要なカテゴリに工数を集中させます。やらない項目は理由を記録し、クライアントと合意しておくことが重要です。小規模な改修であれば、変更が影響する非機能カテゴリだけに絞って確認する判断も現実的です。

Q. 社内に非機能テストの経験者がいません。どうすればよいですか。 A. まずは本記事のカテゴリ別テンプレートで項目の枠を埋め、目標値をクライアントと合意するところから始めます。性能・セキュリティなど専門性の高い領域は、外部の専門家に部分的に依頼する選択肢もあります。すべてを内製で抱え込むより、知見のある領域と外部に任せる領域を切り分けるほうが、結果的に品質と納期を守りやすくなります。

非機能テストは専門性が高く、社内に経験者がいないと項目の洗い出しから目標値の設定まで手探りになりがちです。自社のテスト体制で非機能面までカバーしきれるか不安を感じている方は、テストに関するご相談窓口から現状の課題をお聞かせください。項目の洗い出しや体制づくりの進め方について、実務目線でご相談いただけます。