非機能要件の設計 ― 「止まらない」という言葉に値札はない ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソリューションアーキテクチャ」カテゴリ第3弾として、非機能要件について解説する記事です。

機能要件は業務部門が書ける、非機能要件は専門家でないと書けない──非機能要件が曖昧だと「動くけど遅い／止まる／運用が地獄」の完成後大炎上が起こります。本記事では性能・可用性・セキュリティ・運用性の数値化、IPA非機能要件グレード、AI時代の非機能テスト自動化まで扱います。

このカテゴリの他の記事

なぜ非機能要件が必要か

「完成したが使えない」を防ぐ

機能は完璧でも、応答10秒のシステムは使われません。数値で定まっていないと、受け入れ時に揉めます。

コスト見積もりの根拠になる

「99.9%稼働」と「99.99%稼働」では構築コストが5倍違うこともあります。数値が決まって初めて見積もりができます。

規制要件との整合性

金融・医療・個人情報は法規制で非機能要件の水準が決まっていることも多く、先に明確化しないと違反リスクが出ます。

非機能要件の主要カテゴリ

IPA（Information-technology Promotion Agency＝独立行政法人情報処理推進機構）の非機能要求グレードが日本では標準的な分類です。6つの大項目で網羅的に整理できます。

flowchart TB
    NFR([非機能要件])
    AVAIL[可用性<br/>稼働率99.9%等]
    PERF[性能・拡張性<br/>レスポンス・TPS]
    OPS[運用・保守性<br/>監視/バックアップ]
    MIG[移行性<br/>データ/環境移行]
    SEC[セキュリティ<br/>認証/暗号化]
    ENV[システム環境<br/>OS/ブラウザ前提]
    NFR --> AVAIL
    NFR --> PERF
    NFR --> OPS
    NFR --> MIG
    NFR --> SEC
    NFR --> ENV
    BAD[非機能を曖昧にする<br/>= 完成後に大炎上]
    BAD -.|よくある失敗| NFR
    classDef root fill:#fef3c7,stroke:#d97706,stroke-width:2px;
    classDef cat fill:#dbeafe,stroke:#2563eb;
    classDef bad fill:#fee2e2,stroke:#dc2626;
    class NFR root;
    class AVAIL,PERF,OPS,MIG,SEC,ENV cat;
    class BAD bad;

カテゴリ	内容
可用性	止まらない度合い
性能・拡張性	速さ・スケール
運用・保守性	運用のしやすさ
移行性	移行のしやすさ
セキュリティ	守られているか
システム環境	前提環境・要件

IPA の非機能要求グレードは無料で使えるテンプレートで、日本企業では広く活用されています。

可用性

システムがどれだけ止まらないかを定義します。SLO で扱った内容と同じ観点で、数値化が必須です。

指標	内容	典型値
稼働率	月何%稼働するか	99.9%（月43分ダウン）
RTO	障害時の復旧目標時間	1時間
RPO	データ損失許容時間	15分
MTBF	平均故障間隔	30日
MTTR	平均修復時間	30分

99.99%を約束すると月4.3分しかダウンできない極めて厳しい水準です。コストは跳ね上がるので、業務要件に見合った水準を選びます。

性能

どれだけ速く・多く処理できるかを定義します。業務の性質に応じて、応答時間とスループットを明確に数値化します。

指標	内容	典型例
応答時間	1リクエストの処理時間	P95 で300ms 以内
スループット	単位時間の処理数	1000 req/sec
同時接続数	並行ユーザー数	10,000
ピーク倍率	ピーク時の負荷	平常の10倍
レイテンシ	ネットワーク遅延	50ms 以下

「応答3秒以内」は平均か最大かを明確にします。通常は P95／P99（95／99 パーセンタイル）で定義するのが現代的です。

拡張性（スケーラビリティ）

将来の成長に対応できるかを定義します。サービス開始時の規模だけでなく、数年後の成長予測も含めて設計します。

指標	内容
水平拡張	サーバー追加で対応可能か
垂直拡張	CPU・メモリ増強で対応可能か
データ拡張	DB 容量の伸び
ユーザー拡張	10倍・100倍の成長
地理拡張	海外展開

最初から全て設計するのは過剰ですが、段階的拡張のシナリオは考えておく必要があります。

運用・保守性

運用のしやすさを定義します。ここが弱いと、運用チームの負担が爆発し、障害が増えます。

項目	内容
バックアップ	頻度・保存期間・復元試験
監視	何を・どの頻度で監視
ログ保存	期間・容量
デプロイ	頻度・停止時間
ドキュメント	運用手順書の整備
オンコール	24／7の対応体制

「運用を外注する前提」なら、運用委託可能な水準を定義する必要があります。

セキュリティ

守るべき水準を定義します。扱うデータの機微度と法規制で水準が変わります。

項目	内容
認証	MFA（Multi-Factor Authentication＝多要素認証）必須・パスワード強度
認可	権限設計・最小権限
暗号化	通信・保存・鍵管理
監査ログ	保存期間・改ざん防止
脆弱性対応	パッチ適用 SLA
ペネトレーション試験	頻度・範囲

個人情報保護法・GDPR（EU一般データ保護規則）・PCI DSS（クレジットカード業界のデータ保護基準）等の規制要件は必ず織り込みます。

移行性

既存システムからの移行のしやすさを定義します。移行計画の設計不足でプロジェクトが破綻する事例は多く、軽視してはいけません。

項目	内容
データ移行方式	一括／段階
並行稼働	新旧両用期間
ロールバック	戻す手順・条件
システム停止時間	カットオーバー時
ユーザートレーニング	教育計画
業務停止影響	業務部門との調整

非機能要件の「抜け漏れ」対策

非機能要件は忘れやすい項目が多いです。IPA の非機能要求グレードのような網羅チェックリストを使い、抜けをなくします。

忘れやすい項目	内容
ブラウザ対応範囲	IE11 は? Chrome 最新のみ?
文字コード	UTF-8・絵文字対応
タイムゾーン	UTC・JST・複数地域
多言語対応	i18n（internationalization＝国際化）・L10n（localization＝地域化）
アクセシビリティ	WCAG（Web Content Accessibility Guidelines＝Webアクセシビリティ基準）2.1準拠
災害対策	DR（Disaster Recovery＝災害復旧）・地理分散
ログ保存	法的要件

これらは完成後に「対応してない」と言われて炎上しがちな項目です。最初に定義します。

SLA・SLOとの関係

非機能要件は SLA／SLO と密接に連動します。SLA が外部契約上の約束なら、非機能要件は設計時点での目標値です。

	非機能要件	SLO	SLA
フェーズ	設計時	運用時	契約時
性質	目標	内部目標	外部契約
違反時	設計変更	改善投資	罰金・減額

SLA に影響する非機能要件（可用性・性能）は、SLAより厳しく設定するのが鉄則です。

判断基準①:システムの性質

業務の重要性・公開範囲で非機能要件の厳しさが変わります。

システム性質	可用性目安
社内ツール	99%
一般B2Cサービス	99.9%
B2B SaaS	99.95%
金融・決済	99.99%
電力・通信	99.999%

判断基準②:組織の体制

運用チームの規模で非機能要件の実現可能性が変わります。24／7体制がないのに99.99% は守れません。

運用体制	可能な可用性
業務時間のみ	99%
拡張時間	99.5%
24/7 オンコール	99.9%
24/7 SRE（Site Reliability Engineering＝サービス信頼性エンジニア）専属	99.95%
多地域・Follow-the-Sun	99.99% 以上

ケース別の選び方

社内ツール・業務時間利用

可用性99% + 応答3秒 + 日次バックアップ。IPA 非機能グレードは「モデルシステム1」相当。SLA 不要、RTO 24時間・RPO 1日で十分。セキュリティは社内 ID 連携 + TLS で最低限カバー。

一般B2C Webサービス

可用性99.9% + P95 500ms + 24／7オンコール + 自動バックアップ。IPA「モデル2」、SLO 管理導入、個人情報保護法対応の PII（Personally Identifiable Information＝個人を特定できる情報）マスキング、ペネトレ年1回。AWS／GCP マネージドサービスを活用してコスト最適化。

B2B SaaS・エンタープライズ顧客

可用性99.95% + SLA 契約 + 監査ログ7年 + SOC 2（サービス組織のセキュリティ・可用性等を監査する米国基準）対応。IPA「モデル3」相当、顧客ごとの SLA 個別締結、RTO／RPO を契約に明記、ISO 27001 取得を視野に。マルチテナント分離設計を非機能要件に含める。

金融・決済・医療

可用性99.99%+ + マルチリージョン DR + FISC／PCI DSS／HIPAA 準拠。IPA「モデル4」、24／7 SRE 専属、年次ペネトレ・四半期脆弱性診断、暗号化は FIPS 140-2（米国政府の暗号モジュール認定基準）認定の HSM（Hardware Security Module＝専用暗号ハードウェア）、改ざん防止の監査ログ。非機能要件が法規制そのものと一体化。

よくある勘違い

非機能要件は後から決める

後から追加する改修は10倍コストがかかります。最初に決めるのが鉄則。

可用性は高いほど良い

コストが指数関数的に増えます。業務要件に見合う水準を選びます。

99.9%なら99.99%でも大差ない

大差あり。99.9%は月43分・99.99%は月4.3分で、構築コストは数倍です。

非機能要件は技術部門が決める

業務影響を判断するのは業務部門。両者の合意が必要です。

業務部門が「止まらないシステムにしてほしい」と要望し 99.99% で見積もりを出したら「高すぎる」と却下、「99.9% なら半額以下」と伝えた途端「それで十分」と即決──という事例があります。業務側は「止まらない」という言葉を使っていても、月に43分程度のダウンは許容できることが、数字のやり取りで初めて明らかになる。非機能要件は、数字を並べて見せた瞬間にようやく議論が始まる、言葉のままでは永遠に噛み合わない、と示唆する典型例です。

サービス種別×非機能要件の数値Gate

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

非機能要件は数値で合意した瞬間に議論が始まる領域。以下が業界定番の対応表です。

サービス種別	可用性	RTO	RPO	応答時間(P95)	月額コスト目安
社内ツール	99%	24時間	1日	3秒	数万円
一般B2C Web	99.9%	1時間	15分	500ms	数十万円
B2B SaaS	99.95%	30分	5分	300ms	数十〜百万円
金融・決済	99.99%	5分	1分	100ms	数百万円〜
通信・電力	99.999%	30秒	10秒	50ms	数千万円〜

99.9%と99.99%で構築コストは数倍違うが経験則。業務部門が「止まらないシステム」と要望しても、数値で提示すると「99.9%で十分」となることが多い。IPA非機能要求グレードは日本で標準のチェックリストで、忘れやすい項目（タイムゾーン・ブラウザ対応・i18n・WCAG 等）を網羅的にカバーします。

「止まらない」は数値で提示して初めて議論が始まる。言葉では永遠に噛み合いません。

非機能要件設計の鬼門・禁じ手

非機能要件で事故る典型パターン。どれも動くけど使えないシステムを生みます。

禁じ手	なぜダメか
非機能要件を後から決める	Knight Capital事件（段階展開・自動ロールバック欠落で45分4.4億ドル損失）
可用性を「できるだけ高く」で曖昧に合意	数値化ないと設計も見積もりもできない
「なんとなく99.99%」で全システムに適用	99.9%と99.99%で構築コスト数倍、過剰投資
応答時間を平均値で定義	1%の遅いユーザーが見えない、P95／P99 で測る
運用体制なしで99.99%を約束	24／7 SRE 専属がないと守れない
災害対策（DR）を最後に付け加える	後付けはコスト10倍、最初から設計
ブラウザ対応範囲を未定義でリリース	完成後に「IE11対応してない」と指摘、大改修
タイムゾーン・文字コードを忘れる	海外展開・絵文字で致命的バグ
WCAG（アクセシビリティ）を無視	2024年4月日本施行の改正障害者差別解消法違反リスク
非機能要件をテスト化しない	設計書に書いただけで誰も検証せず、本番で発覚

Knight Capital 2012年事件は段階的展開（Canary）・自動ロールバック・監視といった非機能要件の全欠落が致命傷でした（詳細は付録「重大インシデント事例集」）。某大手EC年末商戦の新UIリリース後30秒遅延でSNS炎上、4時間後旧UI緊急切り戻しの事例も、応答時間非機能要件未定義の代償を示します。

非機能要件は「動くけど使えない」を防ぐ保険。最初に数値で定義しましょう。

AI時代の視点

AI 駆動開発（バイブコーディング）と AI 活用が前提になると、非機能要件はAIが生成するコードの品質基準として重要性が増します。AI が書くコードの性能・セキュリティは人間のレビューだけでは担保できないため、非機能要件を自動テストで検証する仕組みが必要です。

AI時代に有利	AI時代に不利
数値化された非機能要件	「速く」「安全に」の言葉
自動負荷試験	手動の一回限り試験
自動セキュリティスキャン	人力レビューだけ
SLOベース監視	閾値ベース

非機能要件をテスト化し、CI/CD に組み込むのが新しい常識です。AI が書いたコードの非機能要件を自動検証する仕組みが、品質を担保します。

AI 時代は非機能要件を自動テスト化する。数値を定義するだけでは守られません。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• 可用性目標（99.X%・RTO・RPO）
• 性能目標（応答時間・スループット）
• 拡張性（成長シナリオ）
• 運用要件（監視・バックアップ・オンコール）
• セキュリティ水準（認証・暗号化・監査）
• 移行計画（並行稼働・ロールバック）
• 網羅チェック（IPA 非機能要求グレード等）

筆者メモ — 「非機能要件なし」が炎上を生んだ事例

非機能要件を後回しにして炎上した事例は、SI業界で絶えず語り継がれています。

Knight Capital 2012年事件は、非機能要件（特にデプロイの安全性）を軽視した結果の象徴で、後の調査で「段階的展開（Canary）・自動ロールバック・監視といった非機能要件が全て欠落していたこと」が致命傷と判定されました（詳細は付録「重大インシデント事例集」）。

もう一つ、Amazon Prime の Prime Day 初年度停止も引用されます。ピーク時トラフィックに対する性能非機能要件の見積もりが甘く、チェックアウトが数時間ダウン、億ドル単位の機会損失を出したと推定されています。以降、Amazon は性能要件を実測ベースで四半期ごとに更新し、カオスエンジニアリングで自動検証する仕組みを組み込みました。

日本国内でも、某大手 EC サイトが年末商戦に向けて新 UI をリリースした直後、応答時間の非機能要件が未定義でピーク時に30秒以上の応答遅延が発生、SNS で炎上して4時間後に旧UIへ緊急切り戻し、という事例が語り継がれています。「機能が完成しても、非機能が未定義ならシステムは使い物にならない」──この現実を繰り返し突きつけているのが、非機能要件軽視の歴史です。

最終的な判断の仕方

非機能要件の核心は数値で定義し、最初に決めるという発想です。機能要件は業務部門が書けますが、非機能要件（性能・可用性・セキュリティ・運用・移行）は専門家でないと書けない領域で、ここが曖昧だと完成後に「動くけど遅い」「月に何度も止まる」「運用が地獄」という炎上が必ず起こります。後から追加する改修は10倍コスト、99.9%と99.99%では構築コストが数倍違う──この現実を数値で示して業務部門と合意するのがソリューションアーキテクトの責任です。IPA 非機能要求グレードは日本で標準のチェックリストで、抜け漏れ防止の最強の武器になります。

もう一つの決定的な軸は非機能要件を自動テスト化してAIが書くコードの品質を担保するという要請です。AI が書くコードの性能・セキュリティは人間レビューだけでは担保できません。負荷試験・セキュリティスキャン・SLO 監視を CI/CD に組み込み、数値化された非機能要件を継続的に検証する仕組みが、AI 時代の品質保証の土台になります。

選定の優先順位

1. 最初に数値で決める — 後回しは10倍コスト、曖昧は致命傷
2. IPAグレードで網羅チェック — 忘れやすい項目（タイムゾーン・ブラウザ等）も抜けなく
3. 運用体制と整合させる — 24／7なしで99.99%は守れない、身の丈に合う水準
4. CI/CDで自動テスト化 — AI 生成コードの性能・セキュリティを継続検証

「数値化して自動テスト化する」非機能要件は曖昧だと完成後に炎上します。

まとめ

本記事は非機能要件の設計について、可用性・性能・運用・セキュリティ・IPAグレード・SLA／SLOとの関係・AI時代の自動テスト化まで含めて解説しました。如何だったでしょうか。

数値で最初に決め、IPAで網羅し、運用体制と整合させ、自動テスト化する。これが2026年の非機能要件設計の現実解です。

次回は「見積もりとROI」について解説します。3点見積もり・バッファ・3年ROI・損益分岐点の作法と、稟議を通すための数字の組み立て方を掘り下げる予定です。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。