非機能要件一覧｜IPA非機能要求グレード6大項目と定義書テンプレート

非機能要件とは、システムが「何をするか（機能）」ではなく「どれくらいの品質で動くか」を決める要件で、可用性・性能・運用・移行・セキュリティ・環境の6つに整理するのが定番です。 この6分類は、IPA（情報処理推進機構）が公開している「非機能要求グレード2018」の大項目にもとづいています。

この記事では、6大項目×35中項目の一覧表、モデルシステム3種で目標水準を決める手順、そのまま使える非機能要件定義書テンプレート（Markdown）、ヒアリング用チェックリストを1ページにまとめました。さらに、稼働率と停止時間の換算や応答時間のパーセンタイルを Python で計算した結果を載せ、「99.9%と99.99%で何が変わるのか」「平均だけで性能目標を書くと何が起きるのか」を数字で確認できるようにしています。

非機能要件の一覧（6大項目の早見表）

出典：IPA「非機能要求グレード2018」（大項目・中項目の名称）。各列の「例」は本記事で用意した説明用の例です。

非機能要件と機能要件の違い

機能要件は「タスクを登録できる」のような“できること”、非機能要件は「登録が1秒以内に終わる」「平日日中は止まらない」のような“どのくらいの品質か”を決めます。 非機能要件は利用者から言葉で出てきにくく、後から決めると設計や費用に大きく影響するため、要件定義の早い段階で一覧を使って漏れなく確認するのがポイントです。

IPA 非機能要求グレードとは

非機能要求グレードは、発注者と開発者が非機能要件を同じ物差しで話し合うための「項目一覧」と「段階（レベル）」のセットです。 IPA が公開しており、2018年版が最新です（IPA のページには、2018年版をもって更新を終えており、問い合わせは受け付けていない旨が記載されています。資料は引き続きダウンロードできます）。

構成資料

IPA のダウンロードページによると、2018年版は次の資料で構成されています。

階層構造（大項目→中項目→小項目→メトリクス）

項目は4階層で、いちばん下の「メトリクス」ごとにレベル0〜5の段階が定義されています。 例えば「A 可用性 → A.1 継続性 → 小項目 → A.1.1.1 運用時間」のように、記号でたどれるのが特徴です。

flowchart LR
    A[大項目 A 可用性] --> A1[中項目 A.1 継続性]
    A1 --> A11[小項目 A.1.1 運用スケジュール]
    A11 --> M1[メトリクス A.1.1.1 運用時間（通常）]
    M1 --> L[レベル0〜5 の段階]

6大項目×中項目の一覧表

次の表が、非機能要求グレード2018の中項目35個です。 ヒアリングや定義書の章立てにそのまま使えます。「何を決めるか」の列は、本記事で中項目の趣旨を短くまとめたものです。

A 可用性

B 性能・拡張性

C 運用・保守性

D 移行性

E セキュリティ

F システム環境・エコロジー

出典：IPA「非機能要求グレード2018」の大項目・中項目の名称と記号。

モデルシステム3種で目標水準を決める手順

非機能要求グレードでは、まず「どのくらい社会に影響するシステムか」を3つのモデルから選び、その初期値をたたき台に重要項目のレベルを調整します。 一からすべて決めるより、合意までの時間を短くできるのが利点です。

IPA の利用ガイドで示されている進め方は、次の3段階です。

重要項目の早見表（可用性・性能を中心に）

重要項目とは、システムの構成や費用に大きく影響するため、優先して合意しておくメトリクスです。 可用性の A.1 継続性では、運用時間・計画停止・RPO・RTO・RLO・稼働率などが重要項目に指定されています。下の表は、主な重要項目と、レベルの値の例（IPA の公開資料で確認できたもの）、モデルごとの考え方をまとめたものです。

表の「殆ど無い／限定される／極めて大きい」の列は、レベル番号ではなく考え方の目安です。 正式な初期値は IPA の「グレード表」（ダウンロード資料に含まれる Excel）に、モデルごとのレベルとして載っています。定義書に書く前に、必ずグレード表で確認してください。

数値の決め方

非機能要件は「速いこと」「止まらないこと」のような言葉ではなく、数値と測り方をセットで書くと、テストで合否を判断できるようになります。 ここでは、迷いやすい3つ（稼働率、RPO/RTO、応答時間）の決め方を、計算結果とともに整理します。

稼働率と停止時間の換算表（Python で計算）

稼働率は「止まってよい時間」に直すと、利用者と合意しやすくなります。次のコードは標準ライブラリだけで動きます。

# availability.py  (Python 3.11 標準ライブラリのみ)
from datetime import timedelta

def fmt(sec: float) -> str:
    td = timedelta(seconds=round(sec))
    h, rem = divmod(td.total_seconds(), 3600)
    m, s = divmod(rem, 60)
    return f"{int(h)}時間{int(m):02d}分{int(s):02d}秒"

YEAR = 365 * 24 * 3600   # 1年（365日）
MONTH = 30 * 24 * 3600   # 1か月（30日）
BIZ_YEAR = 245 * 9 * 3600  # 平日 9時〜18時のみ運用（年245日×9時間）

print("| 稼働率 | 年間の停止許容（24時間365日） | 月間（30日） | 平日9〜18時運用の年間 |")
print("|---|---|---|---|")
for a in [0.99, 0.995, 0.999, 0.9995, 0.9999, 0.99999]:
    down = 1 - a
    print(f"| {a*100:g}% | {fmt(YEAR*down)} | {fmt(MONTH*down)} | {fmt(BIZ_YEAR*down)} |")

# 直列と並列（冗長化）の稼働率
web, app, db = 0.999, 0.999, 0.9995
serial = web * app * db
print(f"\n直列(Web×AP×DB) = {serial*100:.4f}%  年間停止 {fmt(YEAR*(1-serial))}")
pair = 1 - (1 - app) ** 2
print(f"AP を2台並列     = {pair*100:.4f}%")
print(f"直列(AP2台並列)  = {web*pair*db*100:.4f}%  年間停止 {fmt(YEAR*(1-web*pair*db))}")

実行結果（python3 availability.py、Python 3.11.15）：

直列(Web×AP×DB) = 99.7502%  年間停止 21時間52分57秒
AP を2台並列     = 99.9999%
直列(AP2台並列)  = 99.8500%  年間停止 13時間08分40秒

この結果から読み取れるポイントは3つです。

• 「9」が1つ増えるごとに停止許容は10分の1になります。 99.9% は年8時間45分、99.99% は年52分です。月1回・1時間の計画停止を入れるなら、それだけで 99.9% を超えてしまうため、計画停止を稼働率に含めるかどうかを定義書に明記します。
• 稼働率は「運用時間の中で」計算するのが一般的です。 平日9〜18時だけ運用するなら、同じ 99.9% でも許容停止は年2時間12分です。運用時間（A.1.1.1）とセットで書きます。
• 直列につながる部品の稼働率は掛け算で下がり、冗長化（並列）で上がります。 Web・AP・DB がそれぞれ 99.9% 前後でも、全体は 99.75% になりました。AP を2台にしても全体は 99.85% で、残りの部品（Web・DB）の冗長化も検討が必要だとわかります。

RPO・RTO・RLO の決め方

RPO は「どの時点のデータまで戻せればよいか」、RTO は「どれくらいの時間で戻せばよいか」、RLO は「どのレベル（全機能か一部機能か）まで戻すか」です。

flowchart LR
    B[最後のバックアップ] -- RPO：失ってよいデータの幅 --> X[障害発生]
    X -- RTO：復旧までの時間 --> R[業務再開（RLO のレベルで）]

RPO を小さくするほどバックアップの頻度や仕組みの費用が上がり、RTO を短くするほど予備機や自動切替の費用が上がります。 利用者の「ゼロにしたい」という希望は、費用の目安と一緒に提示して落としどころを決めると合意しやすくなります。

応答時間はパーセンタイルで書く（Python で計算）

応答時間の目標は「平均」ではなく「p95（95%のリクエストがこの時間以内）」のようなパーセンタイルで書くのがおすすめです。 平均だと、一部の遅いリクエストが見えにくくなるためです。次のコードは、架空の応答時間データ1万件（98%は200ミリ秒前後、2%だけ2〜4秒）で確認したものです。

# percentile.py  (Python 3.11 標準ライブラリのみ)
import random
import statistics

random.seed(42)
# 架空の応答時間データ（ミリ秒）：通常は 200ms 前後、2% だけ 2〜4 秒かかる
samples = [random.lognormvariate(5.3, 0.35) for _ in range(9800)]
samples += [random.uniform(2000, 4000) for _ in range(200)]

q = statistics.quantiles(samples, n=100, method="inclusive")  # q[i] = (i+1) パーセンタイル
print(f"件数        : {len(samples)}")
print(f"平均        : {statistics.fmean(samples):7.1f} ms")
print(f"中央値(p50) : {q[49]:7.1f} ms")
print(f"p90         : {q[89]:7.1f} ms")
print(f"p95         : {q[94]:7.1f} ms")
print(f"p99         : {q[98]:7.1f} ms")
print(f"最大        : {max(samples):7.1f} ms")

target = 1000
ok = sum(s <= target for s in samples) / len(samples)
print(f"{target}ms 以内の割合（順守率）: {ok*100:.1f}%")

実行結果：

件数        : 10000
平均        :   267.6 ms
中央値(p50) :   201.4 ms
p90         :   329.9 ms
p95         :   389.8 ms
p99         :  2916.6 ms
最大        :  3987.1 ms
1000ms 以内の割合（順守率）: 98.0%

平均は 267.6ms と速く見えますが、p99 は約2.9秒で、100回に1回以上は3秒近く待たされています。 「平均 500ms 以内」と書くとこのシステムは合格しますが、「p99 1秒以内」と書けば不合格として改善の対象になります。IPA のグレードにも「通常時レスポンス順守率」（何%のリクエストが目標時間内に収まるか）というメトリクスがあり、考え方は同じです。

応答時間の目標は、条件（同時アクセス数、データ件数、測る区間）とセットで書きます。負荷テストのツールや進め方は既存記事「負荷テストの進め方とk6の使い方」で扱っています。

そのまま使える非機能要件定義書テンプレート

定義書は「項目・目標値・測定方法・根拠」の4点を必ずそろえると、後工程のテストや運用で迷いません。 以下は Markdown でそのまま使えるテンプレートです。値は架空のタスク管理システムの記入例です。

# 非機能要件定義書（タスク管理システム）

- 文書番号：NFR-001 / 版：1.0 / 作成日：2026-10-01
- 参照：IPA 非機能要求グレード2018
- モデルシステム：社会的影響が限定されるシステム（初期値として採用し、下記のとおり調整）

## 1. 前提条件
| ID | 項目 | 内容 |
|---|---|---|
| PRE-01 | 利用者数 | 社員 800 名（3 年後 1,200 名） |
| PRE-02 | 利用時間帯 | 平日 8:00〜20:00 |
| PRE-03 | 利用端末 | 社内 PC（最新版の Chrome / Edge） |

## 2. 可用性
| ID | グレード項目 | 要件 | 目標値 | 測定方法 | 根拠 |
|---|---|---|---|---|---|
| NFR-A-01 | A.1.1.1 運用時間 | サービス提供時間 | 平日 8:00〜20:00 | 監視ツールの稼働記録 | 利用時間帯（PRE-02） |
| NFR-A-02 | A.1.1.3 計画停止 | 計画停止の扱い | 月 1 回、休日 2 時間以内、7 日前通知 | 保守記録 | 業務時間外で吸収できる |
| NFR-A-03 | A.1.5.1 稼働率 | 運用時間内の稼働率（計画停止を除く） | 99.9% 以上（月間） | 外形監視の 1 分間隔の成功率 | 年間停止許容 約 3 時間 |
| NFR-A-04 | A.1.3.1 RPO | 復旧時点 | 障害の 1 時間前まで | 復旧訓練で確認 | 1 時間分の再入力は許容 |
| NFR-A-05 | A.1.3.2 RTO | 復旧時間 | 4 時間以内 | 復旧訓練で確認 | 半日止まると締め作業に影響 |
| NFR-A-06 | A.2 耐障害性 | 冗長化 | AP 2 台、DB はマネージドの複数ゾーン構成 | 構成図・切替試験 | NFR-A-03 の達成 |

## 3. 性能・拡張性
| ID | グレード項目 | 要件 | 目標値 | 測定方法 | 根拠 |
|---|---|---|---|---|---|
| NFR-B-01 | B.1 業務処理量 | 同時アクセス | 300 セッション | 負荷テスト | 利用者の 4 割が同時利用 |
| NFR-B-02 | B.2 性能目標値 | 画面の応答時間 | 通常時 p95 1 秒以内、p99 3 秒以内 | 負荷テスト（NFR-B-01 の条件） | 操作の待ち時間の許容 |
| NFR-B-03 | B.2 性能目標値 | 夜間バッチ | 2 時間以内に完了 | ジョブ実行ログ | 翌朝 8:00 の利用開始に間に合う |
| NFR-B-04 | B.3 リソース拡張性 | 余裕 | CPU・メモリ使用率 ピーク時 70% 以下 | 監視の 5 分平均 | 3 年後の利用者増に対応 |

## 4. 運用・保守性
| ID | グレード項目 | 要件 | 目標値 | 測定方法 | 根拠 |
|---|---|---|---|---|---|
| NFR-C-01 | C.1 通常運用 | バックアップ | DB 日次フル＋1 時間ごとの差分、30 日保管 | バックアップ記録 | NFR-A-04 |
| NFR-C-02 | C.1 通常運用 | 監視 | 死活・リソース・エラー率を 1 分間隔 | 監視設定 | 障害の早期検知 |
| NFR-C-03 | C.3 障害時運用 | 障害連絡 | 検知から 30 分以内に一次連絡 | 障害報告書 | 利用部門への周知 |
| NFR-C-04 | C.5 サポート体制 | 問い合わせ対応 | 平日 9:00〜18:00 | 窓口記録 | 運用時間帯 |

## 5. 移行性
| ID | グレード項目 | 要件 | 目標値 | 測定方法 | 根拠 |
|---|---|---|---|---|---|
| NFR-D-01 | D.1 移行時期 | 切替時の停止 | 休日 12 時間以内 | リハーサル結果 | 業務への影響を避ける |
| NFR-D-02 | D.4 移行対象 - データ | 移行データ | タスク 200 万件、添付 300GB | 件数・ハッシュ照合 | 現行システムの全件 |
| NFR-D-03 | D.5 移行計画 | リハーサル | 本番前に 2 回 | リハーサル報告 | 手順と時間の確認 |

## 6. セキュリティ
| ID | グレード項目 | 要件 | 目標値 | 測定方法 | 根拠 |
|---|---|---|---|---|---|
| NFR-E-01 | E.5 アクセス・利用制限 | 認証 | 社内 ID 基盤とのシングルサインオン＋多要素認証 | 設定確認 | 社内規程 |
| NFR-E-02 | E.6 データ秘匿 | 暗号化 | 通信は TLS 1.2 以上、保存データは暗号化 | 設定確認・診断 | 社内規程 |
| NFR-E-03 | E.7 不正追跡・監視 | 操作ログ | 1 年保存、管理者操作は全件 | ログ保管設定 | 監査対応 |
| NFR-E-04 | E.3 セキュリティ診断 | 脆弱性診断 | リリース前と年 1 回 | 診断報告書 | 継続的な確認 |

## 7. システム環境・エコロジー
| ID | グレード項目 | 要件 | 目標値 | 測定方法 | 根拠 |
|---|---|---|---|---|---|
| NFR-F-01 | F.2 システム特性 | 利用場所 | 社内ネットワークと VPN 経由のみ | ネットワーク設定 | 社外公開しない |
| NFR-F-02 | F.1 システム制約 | 稼働基盤 | 社で契約済みのクラウド | 構成図 | 既存契約の活用 |

## 8. 対象外・保留事項
| ID | 内容 | 理由・期限 |
|---|---|---|
| OUT-01 | 遠隔地での災害対策（A.3） | 今回は対象外。次期で検討 |

テンプレートを書くときのポイント

「根拠」の列は省略されがちですが、値を見直すときの判断材料になる大切な列です。 費用との調整で目標値を下げる場合も、根拠があれば影響を説明できます。

ヒアリング用チェックリスト

利用者に「非機能要件を教えてください」と聞いても答えにくいため、業務の言葉で質問し、回答を数値に置き換えるのがコツです。

ヒアリング後の確認チェックリスト

要件定義書・基本設計書・運用設計書との関係

非機能要件定義書は「何をどの水準で満たすか」を決める文書で、「どう実現するか」は基本設計書や運用設計書に引き継ぎます。 各文書の書き方は既存記事（「要件定義書の書き方」「基本設計書の書き方」「運用設計書の書き方」）で扱っているので、ここでは対応関係だけを整理します。

flowchart LR
    R[要件定義書<br/>機能要件＋非機能要件の概要] --> N[非機能要件定義書<br/>目標値・測定方法・根拠]
    N --> B[基本設計書<br/>構成・冗長化・性能設計]
    N --> O[運用設計書<br/>監視・バックアップ・障害対応]
    N --> T[テスト計画<br/>性能テスト・障害試験]

要件 ID（NFR-A-03 など）を設計書・テスト項目にも書いておくと、「どの要件を、どの設計で満たし、どのテストで確認したか」を追跡できます。

よくある抜けと直し方

よくある質問

Q. 非機能要求グレードの項目はすべて決める必要がありますか？ A. すべてを同じ深さで決める必要はありません。 IPA の手順どおり、まず重要項目を決め、残りはモデルシステムの初期値を採用するか「対象外」と明記します。大切なのは、決めなかった項目も「決めていない」ことが文書でわかる状態にすることです。

Q. 非機能要件と非機能要求の違いは何ですか？ A. 「要求」は利用者が望むこと、「要件」は合意して満たすと決めたことです。 ヒアリングで集めた要求を、費用や技術の制約と調整して、目標値と測定方法のある要件に落とし込みます。

Q. クラウドを使う場合も非機能要求グレードは使えますか？ A. 使えます。 稼働率や RPO/RTO などの考え方は同じです。クラウド事業者が公開している稼働率（SLA）は部品ごとの値なので、上の計算例のように組み合わせた全体の値を確認し、運用設計で補う部分を決めます。

Q. 稼働率 99.99% はどのくらい難しいですか？ A. 年間の停止許容は約52分で、計画停止を入れる余地がほとんどありません。 無停止での更新、複数拠点での冗長化、自動切替などが必要になり、構成と運用の費用が大きく変わります。まず業務上必要な運用時間と RTO から逆算して決めるのがおすすめです。

まとめ

• 非機能要件は「どれくらいの品質で動くか」を決める要件で、IPA 非機能要求グレード2018の6大項目・35中項目で漏れなく確認できる
• まずモデルシステム3種から近いものを選び、重要項目のレベルを調整する。正式な初期値は IPA のグレード表で確認する
• 稼働率は停止時間に換算して合意する。99.9% は年約8時間45分、99.99% は年約52分
• 応答時間は平均ではなくパーセンタイル（p95・p99）や順守率で書くと、遅いリクエストを見逃さない
• 定義書は「項目・目標値・測定方法・根拠」の4点セットで書き、要件 ID で設計とテストにつなぐ
• ヒアリングは業務の言葉で聞いて数値に置き換えると、利用者も答えやすい

株式会社RJCでは、品質を数字で語れるシステムづくりを仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。