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

本記事について

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

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

本記事のテーマについてさらに詳しく知りたい方は『システム設計のセオリーと実践方法がこれ1冊でしっかりわかる教科書』も参考にしてみてください。

そもそも非機能要件とは何か

非機能要件とは、ざっくり言えば「システムが”何をするか”ではなく”どれくらいちゃんと動くか”を決めるルール」です。

家を建てるときの耐震性能や断熱性能を想像してください。間取り（機能要件）は住む人が決められますが、「震度6に耐えるか」「冬の室温を何度に保てるか」は専門家でないと設計できません。しかも完成後に耐震等級を上げるのは建て直しに近い大工事です。ソフトウェアも同じで、「1秒以内に応答する」「月間稼働率99.9%を保つ」といった品質基準を最初に決めておかないと、完成してから「動くけど遅い・止まる・運用が地獄」という大炎上を招きます。

なぜ非機能要件が必要か

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

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

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

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

規制要件との整合性

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

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

IPAの非機能要求グレードが日本では標準的な分類です。6つの大項目で網羅的に整理できます。

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

可用性

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

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

性能

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

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

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

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

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

運用・保守性

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

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

セキュリティ

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

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

移行性

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

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

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

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

SLA・SLOとの関係

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

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

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

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

判断基準②:組織の体制

運用チームの規模で非機能要件の実現可能性が変わります。24／7体制がないのに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マスキング、ペネトレ年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、改ざん防止の監査ログ。非機能要件が法規制そのものと一体化。

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

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

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

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

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

やってはいけないこと

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

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

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

| 「非機能要件は後から決める」と後回し | 後付け改修は10倍コスト、最初に決めるのが鉄則 | | 「99.9%なら99.99%でも大差ない」と安易 | 月43分vs月4.3分、構築コスト数倍、業務要件に見合う水準を選ぶ |

AI判断軸

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

非機能要件テストの自動生成とAI

非機能要件が数値で定義されていれば、AIは対応するテストコードを高い精度で生成できます。「応答時間200ms以内、同時接続1000ユーザー」という要件があれば、k6やLocustの負荷テストスクリプトをほぼそのまま生成可能です。

逆に「速くする」「落ちないようにする」のような言葉だけの非機能要件では、テスト生成が不可能です。何をもって合格とするかの基準がなければ、AIも人間もテストを書けません。

非機能要件を最初に数値化する習慣は、単にドキュメントの品質だけでなく、AI活用によるテスト自動化の前提条件としても必須になっています。IPAの非機能要件グレードを参照して項目を網羅し、各項目に具体的な数値を入れる作業を初期段階で完了させてください。

AIが生成するインフラ設計は非機能要件の数値がないと暴走する

AIにインフラ構成を提案させると、非機能要件が曖昧な場合に過剰設計か過小設計のどちらかに振れます。「高可用性」とだけ書くと、マルチリージョン・マルチAZ・自動フェイルオーバーのフル構成が出てくることがあり、月額コストが想定の数倍になります。

数値があれば話が変わります。「稼働率99.9%・RPO 1時間・RTO 4時間」と明示すれば、単一リージョン・マルチAZ・日次バックアップで十分という判断をAIが正しく下せます。

この問題はAI特有ではなく、人間のインフラエンジニアでも同じことが起きますが、AIの場合は「確認せずにそのまま出力する」点が異なります。人間なら「99.99%って本当に必要ですか？」と聞き返しますが、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へ緊急切り戻し、という事例が語り継がれています。「機能が完成しても、非機能が未定義ならシステムは使い物にならない」──この現実を繰り返し突きつけているのが、非機能要件軽視の歴史です。

この記事に関連する記事

まとめ

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

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

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

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

本記事で扱った内容の詳細は AWS Well-Architected フレームワーク - パフォーマンス効率 も合わせて参考にしてください。

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