公開2026.09.15更新2026.10.30 アーキテクチャ

非機能要件とは？6大項目の数値化とk6での閾値テストまで実装目線で解説

非機能要件は、システムが「何をするか」ではなく「どの水準で動き続けるか」を決める要件です。稼働率99.9%、ピーク時のレスポンス3秒以内、といった数値がこれにあたります。この記事では、IPAの非機能要求グレード2018が示す6大項目とレベル値の実数、その値をSLI・SLOへ変換する手順、k6のthresholdsとPrometheusのアラートルールに写して合否を機械判定させる書き方、過剰な要求を見送る条件までを実装者の目線で整理しました。要件定義書の数字がそのままテストコードになる状態を目指します。

まとめ：非機能要件の合否は数値の粒度と検証手段の有無で決まる

非機能要件が空文になる原因は、項目の抜けではありません。「高速に動作すること」と書いてしまい、誰も合否を判定できない状態で検収を迎えることです。

回避策は単純です。項目ごとに、測る対象・測り方・合格ラインを数値で書く。揃わない行は要件ではなく願望として扱ってください。

数値を決める土台はIPAの非機能要求グレード2018が持っています。稼働率なら95%から99.999%までの6段階というレベル表があり、自社が社会的影響のどの区分に当たるかを選べばベース値が決まる。ゼロから数字を考える必要はありません。

決めた数値は、k6のthresholdsに転記すればCIの合否になり、Prometheusのアラートルールに転記すれば運用中の通知になります。要件定義書とテストコードの数字が一致していれば、性能要件は検収時の争点から外れる。逆に、検証手段を書けない要件は最初から削ってください。可用性99.99%を掲げながら単一構成で見積もる案件は、要件より先に費用と体制を詰める場面です。見送り条件は最終章に置きました。

非機能要件の定義と機能要件との境界線・IPA非機能要求グレード6大項目の全体像

非機能要件は残り物の総称ではありません。決め方と決める主体がはっきりしている領域です。

機能要件との切り分け基準と「どの水準で動き続けるか」という問いの立て方

機能要件は「何ができるか」を規定します。受注登録ができる、在庫を引き当てられる、といった振る舞いです。非機能要件はその振る舞いに条件を付け、受注登録が1秒以内に完了すること、月間の停止が52.6分を超えないこと、という形になります。

切り分けに迷ったら、文を疑問形にしてみてください。「実装されているか」で答えが出るなら機能要件、「どのくらいか」を聞き返したくなるなら非機能要件です。

この違いは責任分担にも響きます。機能要件の抜けは追加実装で埋まりますが、非機能要件の抜けはアーキテクチャの作り直しになる。冗長化しない前提の構成に検収直前で99.99%を要求されても、サーバーを足して解決する話にはなりません。だから非機能要件は要件定義の段階で成果物として扱う必要があり、設計工程に入ってからでは選択肢が消えています。

IPA非機能要求グレード2018の6大項目A〜Fと236メトリクスという構成

国内の受託開発で共通言語になっているのが、IPAの非機能要求グレードです。2010年4月に初版が公開され、2018年4月に改訂されました。項目はA〜Fの記号で管理され、A：可用性、B：性能・拡張性、C：運用・保守性、D：移行性、E：セキュリティ、F：システム環境・エコロジーの6大項目に分かれます。

ツール群は4点です。決めるべき項目を並べた「項目一覧」、モデルシステムごとのベース値を示す「グレード表」、検討順をツリーで示した「樹系図」、前2者をマージして記入用にしたシート。手を動かすのは記入シートです。

IPAが公開した2018年改訂の差分資料によると、全体は236メトリクスで構成され、改訂では新規追加が2件、既存項目の修正が20件でした。対象はセキュリティと仮想化です。標的型攻撃を前提にインシデントレスポンスチームの常設要否（E.11.1.1）が新設され、可用性の冗長化（A.2.5.3）はRAIDレベルだけで表現する記載が見直されました。項目の一覧と各項目の意味を網羅的に追うなら、非機能要求グレードの6カテゴリとレベル設定プロセスの解説を先に読むと、この先の数値化の話が早く入ります。

社会的影響の3段階からモデルシステムを選んで基準値を決める手順

記入シートには、選択レベルの列が3系統あります。「社会的影響が殆ど無いシステム」「社会的影響が限定されるシステム」「社会的影響が極めて大きいシステム」の3つ。これがモデルシステムで、対象がどれに当たるかを最初に決めます。

選び方は、停止したときに誰が困るかで決まります。部門内の業務が止まるだけなら1つ目、取引先や顧客の業務が止まるなら2つ目、社会インフラなら3つ目です。

区分が決まると、各項目の推奨レベルが自動的に埋まります。稼働率（A.1.5.1）なら、社会的影響が殆ど無いシステムはレベル2＝99%、極めて大きいシステムはレベル4以上が目安。埋まった値を採用するか上げ下げするかを1項目ずつ判断する作業が、非機能要件定義の実体です。行政案件なら、デジタル庁のデジタル・ガバメント推進標準ガイドライン群にも要件定義書の標準テンプレートがあり、DS-120実践ガイドブックが2026年6月12日改定で公開されています。

稼働率と運用時間をIPAのレベル表から選ぶ手順と年間停止時間の実額

可用性は非機能要件の中で最も費用に跳ねる領域です。把握しないまま桁を上げると、構成と運用体制が一気に変わります。

稼働率レベル0〜5と24時間365日稼働での年間停止時間18.3日〜5.26分

A.1.5.1「稼働率」は、レベル0が95%以下、レベル1が95%、レベル2が99%、レベル3が99.9%、レベル4が99.99%、レベル5が99.999%と定義されています。意味は「明示された利用条件の下で、システムが要求されたサービスを提供できる割合」で、運用スケジュールで定義された稼働時間を分母に、中断時間から求めます。

同じシートには、24時間365日稼働の場合に1年間で業務が中断する時間の合計が併記されています。95%なら18.3日、99%なら87.6時間、99.9%なら8.76時間、99.99%なら52.6分、99.999%なら5.26分。99.9%と99.99%の差は、年間で8時間対52分の開きです。

稼働時間帯が限られるシステムでは見え方が変わる。1日8時間・週5日稼働なら、週に1時間のサービス切替で97.5%、月に1時間なら99.4%、年に1時間なら99.95%です。分母が違えばパーセンテージは大きく動くため、桁を議論する前に運用時間を確定してください。計算式と冗長構成の組み方は高可用性設計をインフラ実装目線でまとめた記事で扱っています。

運用時間の6段階とSLAのサービスクレジットが実際に返す金額の範囲

分母を決めるのがA.1.1.1「運用時間（通常）」です。レベル0は規定無し、レベル1は定時内（9時〜17時）、レベル2は夜間のみ停止（9時〜21時）、レベル3は1時間程度の停止有り（9時〜翌朝8時）、レベル4は若干の停止有り（9時〜翌朝8時55分）、レベル5は24時間無停止。括弧内の時間は一例で、レベル選定の条件そのものではありません。

この項目は可用性と運用・保守性の両方に置かれた重複項目（C.1.1.1）で、後者では開発コストと運用コストを検討する材料になります。24時間無停止を選んだ瞬間、オンコール体制と夜間作業の窓が要件として付いてくる。

クラウド側の数字も確認しておいてください。Amazon Compute SLAはリージョンレベルで月間稼働率99.99%をコミットし、下回った場合のサービスクレジットは99.0%以上99.99%未満で10%、95.0%以上99.0%未満で30%、95.0%未満で100%です。インスタンスレベルは99.5%。返るのは利用料の一部であり、業務停止による損失は補償されません。SLAはリスク移転ではなく上限の宣言だと理解しておくと、SLAとSLO・SLIの違いを顧客と話すときに言葉が混ざりません。

通常時・ピーク時・縮退時で分ける性能要件の数値化とSLOへの変換手順

性能要件は「3秒以内」とだけ書かれがちです。その1行では、いつの3秒で何割が守れば合格かが決まりません。

通常時・ピーク時・縮退時で順守率を分けるレスポンス要件の書き分け

非機能要求グレードは、レスポンス順守率を3つの状態に分けています。B.2.1.1が通常時、B.2.1.2がピーク時、B.2.1.3が縮退時。レベルは、定めない・60%・80%・90%・95%・99%以上の6段階です。

3つを同じ値にする必要はありません。通常時95%、ピーク時80%、縮退時60%という設定が実務ではよく通ります。ピーク時も通常と同じ速度で返す構成は、平常時に余剰リソースを抱えることを意味するためです。

シートには「レベルに示した順守率はおおまかな目安であり、具体的にはレスポンスと順守率について数値で合意する必要がある」と注記されています。順守率だけでは足りず、目標レスポンス値と対象処理をセットで書いて初めて要件になる。バッチ側はB.2.2.1で「所定の時間内に収まる」か「再実行の余裕が確保できる」かの選択です。夜間バッチで後者を選ばないと、1回のリトライで翌朝のオンライン開始に間に合いません。

平均値でなくp95・p99で書く理由とSLI・SLOへ変換する具体手順

順守率95%という指標は、そのままパーセンタイルに翻訳できます。「95%の処理が1秒以内」はp95が1秒未満という意味で、この形なら監視ツールの集計単位と一致します。

平均値で書いてはいけない理由は、Googleが公開するSRE BookのService Level Objectivesの章に明示されています。平均は長いテールの遅延を曖昧にし、その変化も隠すため。同章の例では、典型的なリクエストが約50ミリ秒である一方、5%のリクエストは20倍遅い状況が示されています。

変換は3ステップです。第1に、測る対象（SLI）を決める。SLIは「提供されるサービスのレベルのある側面を慎重に定義した定量的尺度」で、リクエストレイテンシ・エラー率・スループットが代表例です。第2に、その目標値または範囲（SLO）を置く。第3に、顧客と交わす契約に載せる値をSLOより緩い側に設定する。同章はSLOを選ぶ指針として、現在の性能を基準に目標を選ばないこと、集計をシンプルに保つこと、「常に利用可能」のような絶対値を避けること、数を最小限にすることの4点を挙げました。指標の選び方はSLI・SLO・SLAの違いを扱った記事で追えます。

k6のthresholdsで非機能要件を合否判定できるテストコードにする手順

ここまでで数値は揃いました。次は、人が目視で確認しない形にします。

thresholdsに要件をそのまま写すk6スクリプトの書き方と閾値の指定

負荷試験ツールのk6には、合格ラインをスクリプト内に宣言するthresholdsがあります。公式ドキュメントは、エラー率1%未満とp95で200ミリ秒未満を指定する例を示しています。要件定義書の行をこのオブジェクトへ転記する作業です。

「ピーク時は80%が1秒以内、エラー率0.1%未満」なら、次のように書けます。

import http from 'k6/http';

export const options = {
  scenarios: {
    peak: {
      executor: 'constant-arrival-rate',
      rate: 120,
      timeUnit: '1s',
      duration: '10m',
      preAllocatedVUs: 200,
    },
  },
  thresholds: {
    // ピーク時レスポンス順守率80%（B.2.1.2 レベル2）を p(80) に写す
    'http_req_duration{name:order}': ['p(80)<1000', 'p(99)<3000'],
    // エラー率0.1%未満
    http_req_failed: ['rate<0.001'],
  },
};

export default function () {
  http.get('https://example.internal/api/orders', {
    tags: { name: 'order' },
  });
}

要点は2つあります。ひとつはタグ付きメトリクスで対象処理を絞ること。全リクエストを混ぜたp80は、軽い参照APIに引っ張られて実態より良く出ます。もうひとつはp99も併記すること。順守率を満たしていても、残り20%が30秒かかる状態は受け入れられません。

abortOnFailと終了コードでCIのビルド合否へ接続する設定の作り方

thresholdsを満たさなかった場合、k6はゼロ以外の終了コードで終了します。CIはこれを見ればよく、ログの読み取りは不要。GitHub ActionsやGitLab CIに組み込めば、性能劣化を含むプルリクエストが落ちます。

長時間の試験では、失敗が確定した時点で打ち切りたい場面もあるでしょう。thresholdsの各条件はオブジェクト形式でも書け、abortOnFailをtrueにすると完了前でも中止されます。ウォームアップ中の悪化で誤って止めないよう、delayAbortEvalに10sや1mの遅延を指定しておきます。

運用上の注意はデータの再現性です。結果は環境とデータ量に強く依存するため、閾値をCIの合否に使うなら実行環境とテストデータを固定してください。共有のステージング環境で他チームのバッチが走る時間帯に流すと、コードと無関係な理由で赤くなる。失敗が常態化すれば、やがて誰も見なくなります。試験環境の分離で詰まる場合は、AWS・Google Cloud・Azureのインフラ構築の段階から性能要件を前提に設計を組む進め方が確実です。

Prometheusのアラートルールへ写して運用中も非機能要件を守る設定

リリース前に合格しても、運用が始まれば数値は動きます。要件は監視側にも同じ数字で置きます。

PrometheusのalertingルールへSLOを写すYAML設定の作り方

可用性99.9%というSLOは、エラー率0.1%に置き換えると監視で扱いやすくなります。リクエスト総数に対する5xxの比率を記録ルールで定義し、アラートルールで判定します。

groups:
  - name: slo-availability
    rules:
      - record: job:http_errors:ratio5m
        expr: sum(rate(http_requests_total{status=~"5.."}[5m]))
          / sum(rate(http_requests_total[5m]))

      - alert: ErrorBudgetBurnFast
        expr: job:http_errors:ratio5m > 14.4 * 0.001
        for: 2m
        labels:
          severity: page
        annotations:
          summary: "SLO 99.9% のバジェットを高速消費中"

0.001はSLO99.9%の許容エラー率、14.4は消費速度の倍率です。この倍率の考え方はSRE WorkbookのAlerting on SLOsの章で整理されており、1時間の観測窓で14.4倍の速度が続くと30日分のエラーバジェットを2%消費する計算です。消費速度で置くと、短時間のスパイクで呼ばれる回数が減る。メトリクスの型や収集方式はメトリクス監視の4種のメトリック型とアラート閾値の設計にまとめています。

エラーバジェットの消費速度でアラートの通知先と緊急度を分ける設計

消費速度を複数の窓で測ると、通知先を分けられます。1時間窓で14.4倍なら即時のページング、6時間窓で6倍ならチケット起票。前者は夜中でも起こし、後者は翌営業日に見る。この線引きを要件定義の段階で合意しておくと、運用開始後に通知の重さで揉めません。

決めるのは通知の宛先だけではありません。E.11.1.1がインシデントレスポンスチームの常設要否を問う以上、常設しないなら夜間の一次対応は当番制になり、復旧目標時間はその体制で届く値へ下げるしかない。体制と数値は連動します。検知から復旧までの流れはITIL準拠のインシデント管理プロセスと監視・オンコールの実装で扱っています。

非機能要件が形骸化する失敗パターンと過剰な要求を見送る判断基準

236メトリクスを前に手が止まる現場は多く見かけます。埋め方の順序と、埋めない判断の基準を決めておきます。

全項目を一律のレベルで埋める失敗と重要項目から先に詰める順序

最もよくある失敗は、シートの全行を機械的に中間レベルで埋めることです。表は完成に見えますが、費用が跳ねる項目と誤差の項目が同じ重みで並ぶため、見積もりの根拠になりません。

シートには重要項目の印が付いています。まずその行だけを埋めてください。可用性なら運用時間と稼働率、性能なら通常時・ピーク時の順守率とオンラインリクエスト件数（B.1.1.4）、移行性なら移行データ量と変換ルール数（D.4.3.2）。ここが決まれば構成と工数の大半が決まります。

埋める順序にも前後関係があります。F.2.1.1のユーザー数はB.1.1.1と重複項目で、性能・拡張性を決める前提になる値です。ユーザー数が「不特定多数」なのか「上限が決まっている」のかが未確定のまま稼働率だけを99.99%と決めても、必要なリソースは算出できない。シートの備考にも、数値が決められない場合は類似システムを参考に仮置きすることが必要だと書かれています。工程全体での位置づけはシステム開発の7フェーズと成果物・工数比率を参照してください。

検証手段のない非機能要件を書かない原則と受入条件への落とし込み

書いてはいけない要件があります。測り方が決まらないものです。「操作性が良いこと」「拡張性が高いこと」は、検収の場で合否を判定できません。

落とし込む方法は2つ。ひとつは数値と測定手順をセットで書くこと。「同時接続200で受注登録のp95が1秒未満、測定はk6の指定シナリオで実施」まで書けば、誰が測っても同じ結論になります。もうひとつは代理指標への置き換え。拡張性なら「ピーク時の2倍の負荷をインスタンス追加のみで処理でき、追加作業は30分以内」という形です。

それでも数値化できない項目は、要件から外して設計方針の欄へ移してください。要件として残すと、検収時に主観の議論が始まります。受入条件に書く要件は、測定方法・測定環境・判定式の3点が揃うものだけに限る。この原則を先に合意しておくと、レビューが「この行はどう測りますか」の一問で進みます。

99.99%の可用性要件を採用しない条件と過剰設計になる具体的な場面

結論から書きます。次の3条件のいずれかに当たる案件では、稼働率99.99%を要件に入れません。

第1に、業務側の運用が平日9時から18時に限られ、夜間・休日の停止が業務に影響しない場合。年間52.6分という数値は24時間365日を分母にした値であり、稼働時間帯が1日9時間なら同じ停止時間でも99.97%前後になります。分母の違いを無視して桁を揃えると、必要のない冗長化に費用を払うことになる。

第2に、24時間の有人監視体制を置かない場合。99.99%は月間の停止許容が4分22秒です。検知から復旧までを人の判断を挟んで4分で終えるのは、自動フェイルオーバーと自動切り戻しが揃っていなければ成立しません。オンコールに電話して起きるまでの時間だけで超過する。体制を置かないなら99.9%へ下げ、月間43分の枠で確実に復旧する設計のほうが実像に合います。

第3に、業務停止1時間あたりの損失額が算出されていない場合。可用性の桁を上げる判断は、追加費用と回避できる損失の比較でしか正当化できません。損失額が出せないなら、まず99.9%で構成を組み、実測の停止実績を1年分ためてから見直してください。IPAのシートも、レベル選定の条件として「性能低下がシステムの評価低下につながる場合」に上げる、「代替手段がある場合」に下げる、という条件付きの記載を各項目に添えています。判断を条件に紐づける姿勢が、非機能要件を空文にしない歯止めになります。

よくある質問

非機能要件の定義作業で挙がる質問を5つ取り上げます。

非機能要件の6大項目とは何を指しますか？

IPAの非機能要求グレードが定める大項目で、可用性（A）、性能・拡張性（B）、運用・保守性（C）、移行性（D）、セキュリティ（E）、システム環境・エコロジー（F）の6つです。2018年改訂版の全体は236メトリクスで構成され、各大項目の下に中項目・小項目が階層化されています。すべてを埋める必要はなく、重要項目の印が付いた行から決めていく進め方が現実的でしょう。

非機能要件のサンプルや記入例はどこで入手できますか？

IPAのサイトから非機能要求グレード本体が一括ダウンロードでき、項目一覧・グレード表・樹系図・記入用シートが含まれます。記入用シートは項目一覧とグレード表をマージした表で、モデルシステム別の推奨レベルがあらかじめ入っている。行政案件であれば、デジタル庁の標準ガイドライン群にあるDS-120実践ガイドブックに要件定義書標準テンプレートが含まれており、章立ての参考になります。

稼働率99.9%と99.99%では何がどれだけ変わりますか？

24時間365日稼働の場合、年間の中断許容時間が8.76時間と52.6分になります。約10倍の差です。99.9%は単一構成と短時間での復旧手順で届く場合がありますが、99.99%は自動フェイルオーバーと冗長化が前提になり、切り戻しの自動化も必要になる。費用は運用体制側にも発生するため、桁を上げる前に業務側の停止許容時間を確認してください。

非機能要件は誰がいつ決めるものですか？

発注者と開発ベンダーが要件定義の工程で合意します。非機能要求グレードが「ユーザーとベンダー間で決めるべき項目の一覧」という形を取るのは、片方だけでは決められないためです。業務の停止許容時間は発注者しか知らず、実現する構成と費用はベンダー側にしか見積もれない。設計工程での変更は作り直しになるため、要件定義の完了条件に含めてください。

性能要件は「3秒以内」とだけ書けばよいですか？

不足します。対象処理、状態（通常時・ピーク時・縮退時のどれか）、順守率、測定方法の4点が揃って初めて判定できる要件になる。IPAのシートも、順守率のレベル値は目安であり、レスポンスと順守率について数値で合意する必要があると注記しています。書いた数値をそのままk6のthresholdsへ写せる粒度かどうかが、実務的な判断基準になるでしょう。