---
title: "IPAの非機能要求グレードとは？6大項目238メトリクスとグレード表の使い方"
url: "https://www.issoh.co.jp/tech/details/8441/"
published: 2025-08-27
updated: 2026-09-19
categories: ["アーキテクチャ"]
publisher: "株式会社一創"
---

# IPAの非機能要求グレードとは？6大項目238メトリクスとグレード表の使い方

非機能要求グレードは、IPA（独立行政法人情報処理推進機構）が公開した、システム基盤の非機能要求を洗い出して発注者と開発者で合意するためのツール群です。名前は知られている一方で、実際に何項目あるのか、どのファイルを開けば要求レベルの具体値が載っているのかは、解説記事を読んでも分かりにくいところがあります。この記事では配布されている非機能要求グレード2018の本体ファイル一式を展開し、項目数とレベル値を数え直したうえで、選定から合意までの手順と、使う前に知っておくべき現在の位置づけを整理します。

## まとめ：非機能要求グレードの要点

- 非機能要求グレードは、非機能要求項目を網羅的にリストアップして分類し、それぞれの要求レベルを段階的に示したツール群です。現行版は2018年4月公開の「非機能要求グレード2018」です。
- 大項目は可用性・性能／拡張性・運用／保守性・移行性・セキュリティ・システム環境／エコロジーの6つで、項目一覧に並ぶメトリクス（指標）は合計238件です。
- そのうちグレード表を構成する重要項目は92件です。全238件をいきなり検討するのではなく、重要項目から先に決めるのが設計思想です。
- 手順は3段階です。社会的影響の大きさで3つのモデルシステムから1つ選び、グレード表のベース値を出発点に重要項目のレベルを決め、最後に項目一覧で残りを埋めます。
- レベルは0から5の6段階ですが、すべてのメトリクスが6段階あるわけではありません。3段階しか持たないメトリクスもあります。
- 本事業は2009年度から2018年度で終了しており、IPAサイトではアーカイブ配下に置かれています。ファイルの配布は続いていますが、問い合わせ対応は終了しており、配布されている本体は2018年版です。

以下では、この6点の根拠をIPAの配布ファイルと公開ページの記述から順に確認していきます。

## 非機能要求グレードの位置づけ｜認識の行き違いを防ぐためのツール群

IPAは非機能要求グレードを、次のように定義しています。

「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです。

ここで押さえておきたいのは、非機能要求グレードが扱う対象が「システム基盤」に限定されている点です。配布物の正式名称は「システム基盤の非機能要求に関する項目一覧」「システム基盤の非機能要求に関するグレード表」で、アプリケーションの機能そのものは対象外です。機能側の要件をどう切り分けるかは[機能要件とは？非機能要件・業務要件との違いと定義する5つの事項](/column/details/3715/)で整理しています。

初版は2010年4月に公開されました。英語版のタイトルは「Non-Functional Requirements Grades」で、非機能要件を指す略語のNFRはNon-Functional Requirementsの頭文字です。

### 配布される7つのファイルと役割

非機能要求グレード2018の本体（日本語版）は、一括ダウンロード用のZIP（9.7MB）に7つのファイルとして収められています。それぞれの役割はIPAの紹介ページに明記されています。

| ファイル       | 形式    | 役割                   |
| ---------- | ----- | -------------------- |
| 利用ガイド（利用編） | PDF   | 非機能要求グレードの利用方法の解説    |
| 利用ガイド（解説編） | PDF   | 非機能要求グレードの背景の解説      |
| グレード表      | PDF   | 3つのモデルシステムに対応する要求レベル |
| 項目一覧       | PDF   | 非機能要求項目の一覧           |
| 樹系図        | PDF   | 項目を6つの大項目ごとに階層的に示した図 |
| 活用シート      | Excel | グレード表と項目一覧を統合し記入できる表 |
| 利用ガイド（活用編） | PDF   | 利用シーンごとの事例集          |

実務で最初に開くべきは活用シートです。グレード表と項目一覧を1つのスプレッドシートに統合したもので、合意結果をそのまま入力でき、プロジェクトに応じたカスタマイズも認められています。「非機能要求グレード Excel」で探している場合、該当するのはこの活用シートです。

## 6大項目の内訳｜238メトリクスと重要項目92件

項目一覧は、大項目・中項目・小項目・メトリクス（指標）の4階層で構成されます。項番は大項目を英字A〜Fで表し、そこから先をピリオド区切りの連番で示す形式です。たとえばA.1.1.1は可用性の最初のメトリクスにあたります。

階層ごとの件数は、項目一覧PDFの最終ページに合計行として印刷されています。読み取ると大項目6、中項目35、小項目118、重要項目92、メトリクス238です。大項目ごとの内訳は、同じ配布物の活用シート（Excel）の238行を大項目列と重要項目列で集計したものが次の表です。

| 項番 | 大項目          | 中項目 | 小項目 | メトリクス | うち重要項目 |
| -- | ------------ | --- | --- | ----- | ------ |
| A  | 可用性          | 4   | 16  | 33    | 12     |
| B  | 性能・拡張性       | 4   | 17  | 43    | 19     |
| C  | 運用・保守性       | 6   | 35  | 71    | 22     |
| D  | 移行性          | 5   | 9   | 18    | 8      |
| E  | セキュリティ       | 11  | 18  | 37    | 19     |
| F  | システム環境・エコロジー | 5   | 23  | 36    | 12     |
| 合計 | 6大項目         | 35  | 118 | 238   | 92     |

出典：IPA「非機能要求グレード2018」項目一覧・グレード表・活用シート

この238という数は、IPAが公開している改訂情報からも裏付けが取れます。改訂情報には「従来の非機能要求グレードの全体236メトリクスに対し、新規追加が2メトリクス、既存項目に何らかの修正を施したものは20メトリクスとなります」と書かれており、初版の236件に2件を足した238件が2018年版の総数という計算が合います。

分量の偏りにも意味があります。運用・保守性が71メトリクスと突出して多く、小項目だけで35あります。移行性は18メトリクスで最小です。238件を均等に割り振ると検討時間が足りなくなるため、運用・保守性に全体の3割の工数を見込む、といった配分の目安として使えます。

### 重複項目という設計と、238件が延べ数である理由

238件は、大項目をまたいで同じ内容が二重に掲載されている項目を含んだ延べ数です。IPAはこれを重複項目と呼び、意図的に残しています。項目一覧の凡例では、重複項目を「大項目間で重複する項目。非機能要求グレードでは、大項目毎に検討対象者や検討順が異なることを想定し、検討漏れを防ぐため、いくつかの項目が重複している」と説明しています。

実例がA.1.1.1「運用時間（通常）」とC.1.1.1です。備考欄には「運用時間は、システムの可用性の実現レベルを表す項目であるとともに、運用・保守性に関する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている」と記載されています。可用性の担当者と運用設計の担当者が別々に検討しても取りこぼさないための冗長化です。活用シートで重複項目の印が付く行は16件あります。項目一覧に並ぶ行数として数えれば238件、重複を除いた実質の項目数として数えれば238件より少なくなるため、どちらの数え方をしているかを先に決めてから集計してください。

なお、非機能要求グレードの6大項目は品質のモデルとしてはISO/IEC 25010の品質特性と重なる部分があります。両者は目的が違い、25010が製品品質の評価軸を定める規格であるのに対し、非機能要求グレードは受発注者間の合意形成を目的としたツールです。規格側の分類は[ISO/IEC 25010とは？品質特性の一覧と2023年改訂（安全性の追加）まで解説](/tech/details/5019/)にまとめています。

## 利用手順の3段階｜モデルシステム選定からレベル合意まで

IPAは利用手順を3段階と定めています。ユーザと開発者で全項目を一度に均一に確認することは現実的ではなく、また、ある項目が決まれば従属的にレベルが決まる項目もあるため、重要な項目から段階的に確認する構成になっています。

### 段階1：モデルシステムの選定｜社会的影響の大きさによる3類型の比較

最初に、開発対象に最も近いモデルシステムを1つ選びます。用意されているのは「社会的影響が殆ど無いシステム」「社会的影響が限定されるシステム」「社会的影響が極めて大きいシステム」の3つです。それぞれの概要は、グレード表の先頭にあるモデルシステムシートに定義されています。以下はその定義文をそのまま引用したものです。

- 社会的影響が殆ど無いシステム：企業の特定部門が比較的限られた範囲で利用しているシステムで、機能が低下または利用不可な状態になった場合、利用部門では大きな影響があるが、その他には影響しないもの。ここでは、ごく小規模のインターネット公開システムを想定している。
- 社会的影響が限定されるシステム：企業活動の基盤となるシステムで、その機能が低下又は利用不可能な状態に陥った場合、当該企業活動に多大の影響を及ぼすと共に取引先や顧客等の外部利用者にも影響を及ぼすもの。ここでは、企業内のネットワークに限定した基幹システムを想定している。
- 社会的影響が極めて大きいシステム：国民生活・社会経済活動の基盤となるシステムで、その機能が低下又は利用不可能な状態に陥った場合、国民生活・社会経済活動に多大な影響を与えるもの。ここでは、不特定多数の人が利用するインフラシステムを想定している。

選定は概要文だけで決めるわけではありません。モデルシステムシートには16の特徴が3類型ぶん具体的に書かれており、自社システムの想定と突き合わせて選びます。主要な特徴を抜き出すと次のようになります。

| 特徴     | 影響が殆ど無い          | 影響が限定される            | 影響が極めて大きい            |
| ------ | ---------------- | ------------------- | -------------------- |
| 稼働率    | 年に数日の停止まで許容（99%） | 年に1時間程度まで許容（99.99%） | 年に数分間程度まで許容（99.999%） |
| 目標復旧水準 | 週次バックアップからの復旧    | 1営業日以内での復旧          | 数時間で障害発生時点まで復旧       |
| 大規模災害  | 再構築による復旧が前提      | 1週間以内での復旧を目指す       | DRサイトでの業務継続          |
| 運用時間   | 業務時間内のみ、夜間運用なし   | 夜間バッチ後に若干の停止時間      | 24時間365日の運用          |
| バックアップ | 管理者が必要なデータのみ手動   | システム全体を日次で自動取得      | 運用サイトと同期したDRサイト      |
| 運用監視   | 各種ログで死活監視        | 業務機能の稼働を監視          | 性能・リソースまで監視し予兆検出     |
| 重要資産   | 重要資産を保有しない       | 保有するが特定の相手とのみ接続     | 保有し不特定多数に提供          |
| 耐震     | 最低限のレベル          | 通常レベルの対策            | 高いレベル                |

選定は2ステップです。まずシステムの役割と、機能が低下または利用不可能な状態に陥った場合の影響の程度でモデルシステムを選びます。次に、選んだモデルシステムと開発するシステムの非機能要求を比較して差を確認し、選択の妥当性を検証します。ここは差を洗い出して記録する段階で、たとえば稼働率の桁が想定と合わない場合も、その差は段階2以降のレベル調整で埋めます。稼働率や復旧時間をサービスレベルとして契約に落とす手順は[SLA（サービスレベル合意）とは？定義・SLOとの違い・要件と稼働率保証を解説](/column/details/3065/)で扱っています。

### 段階2：重要項目92件のレベル決定｜グレード表のベース値調整

モデルシステムが決まると、グレード表の該当列に初期値が入った状態になります。IPAはこの初期値をベース値と呼びます。段階2では樹系図で全体を俯瞰しながら、グレード表の92件の重要項目についてベース値を確認し、要求に応じて上下させます。

重要項目は「非機能要求を検討する上で品質やコストに大きな影響を与える項目」と定義され、選ばれた項目がそのままグレード表を構成します。92件という数は全238件の4割ほどで、ここだけを先に合意すれば要求の骨格が固まる設計です。

レベルの定義は、メトリクスごとに具体値で書かれています。A.1.1.1「運用時間（通常）」の場合は次のとおりです。

| レベル | 運用時間（通常）のレベル値       |
| --- | ------------------- |
| 0   | 規定無し                |
| 1   | 定時内（9時〜17時）         |
| 2   | 夜間のみ停止（9時〜21時）      |
| 3   | 1時間程度の停止有り（9時〜翌朝8時） |
| 4   | 若干の停止有り（9時〜翌朝8時55分） |
| 5   | 24時間無停止             |

この表を読むときに外せない条件が備考に書かれています。「（）内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない」という注記です。9時始業でない業務システムは時間帯をスライドさせて読み替えることが前提で、括弧内の時刻を満たさないからレベル2ではない、という判定にはなりません。また「停止有り」は停止しなければならない時間帯ではなく、停止できる可能性のある時間帯を指します。

レベルが必ず6段階あるわけではない点も、実務では誤解されやすいところです。A.1.1.3「計画停止の有無」はレベル0が「計画停止有り（運用スケジュールの変更可）」、レベル1が「計画停止有り（運用スケジュールの変更不可）」、レベル2が「計画停止無し」の3段階までで、レベル3以上は定義されていません。0から5の6段階はあくまで整理の枠であり、メトリクスごとに使われる段数は異なります。レベルが大きいほど実現の難易度が高く、一般的に開発コストが高くなる、という関係だけが共通します。

### 段階3：重要項目以外のレベル決定｜項目一覧による残りの要求の確認

最後に、項目一覧を使って重要項目以外のメトリクスの要求レベルを決めます。ここで初めて238件すべてが検討対象になります。項目一覧には運用コストへの影響という列があり、開発コストをかけることで運用コストを下げられる可能性のあるメトリクスに印が付いています。予算配分を議論するときの材料になる列です。

非機能要求グレードは、すべての要求項目がシステムで一意に決まることを前提にしていません。サブシステムごとに要求レベルが異なる場合は、システムで共通的に設定する項目とサブシステム単位に設定する項目に分けて確認するよう指示されています。決まったレベル値を要件定義書のどの章に書くかは[要件定義書の書き方：章立てサンプル・記載項目・レビュー観点を作業手順で解説](/column/details/12849/)を参照してください。

## 2018年改訂の中身｜セキュリティと仮想化で追加された2メトリクス

非機能要求グレード2018は、初版公開後の社会と技術の変化を反映した改訂版です。IPAは改訂対象をセキュリティに関する要求と仮想化に関する要求の2つに絞り、「これまでのスコープは維持したまま」改訂したと説明しています。全面的な作り直しではなく、変化した部分への追従です。

規模は限定的で、新規追加が2メトリクス、既存項目の修正が20メトリクスにとどまります。[IPAの改訂情報（PDF）](https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000066170.pdf)に挙げられている代表例は次の4件です。

| 項番       | メトリクス                       | 区分     | 改訂内容   |
| -------- | --------------------------- | ------ | ------ |
| E.11.1.1 | セキュリティインシデントの対応体制           | セキュリティ | 新規追加   |
| E.1.1.1  | 順守すべき社内規程、ルール、法令、ガイドライン等の有無 | セキュリティ | 記載を拡充  |
| B.4.1.2  | HWリソース専有の設定                 | 性能・拡張性 | 新規追加   |
| A.2.5.3  | 冗長化（ディスク）                   | 可用性    | 記載を見直し |

新規追加の2件が何を狙ったものかは、改訂の理由まで読むとはっきりします。E.11.1.1は、標的型攻撃のように完全防御が事実上不可能な攻撃が出てきたことを受け、インシデントは発生するものという前提に立って、早期検出と早期対処のためのインシデントレスポンスチームを常設するかどうかを決めるために追加されました。B.4.1.2は、複数の論理サーバ間でCPU等のハードウェアリソースを共有するオーバコミットを採用するかどうかを決めるためのメトリクスです。

記載の見直し側も理由が明快です。A.2.5.3は、従来RAID1やRAID5というRAIDレベルでストレージの冗長性を表現していたところ、仮想化技術をベースにした分散ストレージなどRAID以外の冗長化が広がり、従来の記載が合理的でなくなったための修正です。E.1.1.1は、パブリッククラウド等の普及でシステム基盤のグローバル化が進んだことを受け、EU一般データ保護規則（GDPR）のような国や地域特有の法令やガイドラインを漏らさないよう記載を広げたものです。

本体の改訂後も更新は続き、2019年3月28日には利用ガイド（活用編）が第2版になりました。このとき、クラウドサービスへの要求を整理する、情報セキュリティに関する新たな脅威に備える、新技術の導入を検討する、クラウドサービス提供者としてSLAを検討する、という4つの利用シーンが追加されています。新規開発だけでなく既存システムのアセスメントにも使える、という方向への拡張です。

## 使う前に押さえる限界｜IPAの留意事項と事業終了後の位置づけ

導入を検討する段階で最初に確認しておくべきなのは、この取り組みがすでに終了しているという事実です。IPAの紹介ページは現在アーカイブ配下に置かれており、冒頭に「本ページの情報は、2023年8月時点のものです。本事業は終了しているため、お問い合わせには対応できません。」、続けて「本事業は、2009〜2018年度に実施しました。」と明記されています。

一方でファイルの配布は継続しており、2026年9月時点でも[IPAの非機能要求グレード紹介ページ](https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html)から本体一括ZIP（9.7MB）、各種研修教材（3.8MB）、経営層向け読本のPDFをいずれも取得できます。同ページで配布されている本体は2018年版で、それ以降の版は掲載されていません。使うこと自体は妨げられていないので、参照した時点で掲載版と更新履歴を確認してから社内標準に取り込むのが安全です。

IPA自身も適用範囲の限界を利用ガイドに明記しています。示されている留意事項は2つです。

- 項目一覧に存在しない非機能要求が発生した場合：非機能要求グレードは汎用的かつレベル化が可能なメトリクスを選定しているため、具体的な事案では個別・特有の要求が生じることがあります。その場合は項目一覧に存在しない要求を個別要求として別に整理し、非機能要求グレードと併用することが推奨されています。
- モデルシステムに該当しない案件で利用する場合：3つのモデルシステムのどれにも当てはまらない場合でも、非機能要求グレードを使って非機能要求を直接規定することは可能とされています。

もう1つ、誤解されやすい点についてIPA自身が図を修正した記録が残っています。紹介ページの更新履歴には、2023年8月17日に「図1 機能／非機能要求の相違点と課題」について、「非機能要求」が「ビジネスに直結しない」との誤解を招く表現があったため図を更新した、と記載されています。非機能要求は業務に直結しない技術的な付帯条件だ、という理解はIPAが打ち消しにかかった側の解釈にあたります。

ツールとして見たときの実務上の制約は、項目一覧に技術名を冠したメトリクスが無いことです。コンテナやマネージドサービスを前提とした構成であっても、まずは可用性や性能・拡張性の既存メトリクスに要求を対応づけ、そこで表現しきれない要求だけを個別要求として追記する、という留意事項どおりの進め方になります。調達で外部ベンダに要求を提示する場面では、利用ガイドが情報提供依頼書（RFI）や提案依頼書（RFP）の作成に利用する例を示しています。提案依頼書そのものの構成は[RFPとは？提案依頼書の意味・目的・記載項目と目次テンプレートを解説](/column/details/15344/)で解説しています。

## よくある質問

### 非機能要件の6大項目とは何ですか？

非機能要求グレードが定める大項目は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つです。項番はA〜Fの英字で表され、配下に中項目35件、小項目118件、メトリクス238件が並びます。なお、これは非機能要求グレードでの分類であり、非機能要件一般に6大項目という決まった定義があるわけではありません。

### 機能要求と非機能要求の違いは何ですか？

機能要求はシステムが何をするかを定めるもので、非機能要求は業務機能以外の性質、つまりどの程度の品質で動くかを定めるものです。非機能要求グレードが扱うのはシステム基盤に関する非機能要求で、稼働率、応答時間、バックアップ方式、監視範囲、移行方式といった項目が対象になります。

### 非機能要件は英語で何と言いますか？

Non-Functional Requirementsで、略語はNFRです。IPAが公開している英語版の正式タイトルは「Non-Functional Requirements Grades」です。ただし英語版として配布されているファイル一式は初版（2010年4月）をもとにしたもので、2018年版の改訂内容は反映されていません。

### 非機能要求グレードはどこからダウンロードできますか？

IPAサイトのアーカイブ配下にある[非機能要求グレードの紹介ページ](https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html)から、無償で取得できます。本体（日本語版）と利用ガイド（活用編）は一括ZIP（9.7MB）、各種研修教材は別のZIP（3.8MB）です。Excel形式のファイルを探している場合は、ZIPに含まれる活用シートが該当します。英語版と中国語版も別ZIPで公開されています。

### 非機能要求グレードは今も使えますか？

ファイルの公開は続いており、チェックリストとしては現在も使えます。ただし本事業は2009年度から2018年度で実施されて終了しており、IPAは問い合わせに対応できないと明記しています。紹介ページに掲載されている本体は2018年版で、それ以降の版は出ていません。項目一覧に当てはまらない要求が出た場合は、IPA自身が推奨しているとおり、個別要求として別に整理して併用してください。

## 関連記事

- [機能要件とは？非機能要件・業務要件との違いと定義する5つの事項](/column/details/3715/)
- [ISO/IEC 25010とは？品質特性の一覧と2023年改訂（安全性の追加）まで解説](/tech/details/5019/)
- [SLA（サービスレベル合意）とは？定義・SLOとの違い・要件と稼働率保証を解説](/column/details/3065/)
- [要件定義書の書き方：章立てサンプル・記載項目・レビュー観点を作業手順で解説](/column/details/12849/)
- [RFPとは？提案依頼書の意味・目的・記載項目と目次テンプレートを解説](/column/details/15344/)

---

出典: [IPAの非機能要求グレードとは？6大項目238メトリクスとグレード表の使い方](<https://www.issoh.co.jp/tech/details/8441/>)（株式会社一創）
