非機能要件の設計 ― 「止まらない」という言葉に値札はない ― 生成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 パーセンタイル）で定義するのが現代的です。

拡張性・運用・セキュリティ・移行性

拡張性は将来の成長に対応できるかです。水平拡張（サーバー追加）・垂直拡張（スペック増強）・データ容量の伸び・ユーザー10倍/100倍の成長・海外展開──最初から全て設計するのは過剰ですが、段階的拡張のシナリオは考えておく必要があります。

運用・保守性はバックアップ（頻度・保存期間・復元試験）・監視・ログ保存・デプロイ頻度・運用手順書・オンコール体制を定義します。ここが弱いと運用チームの負担が爆発し障害が増えます。運用を外注する前提なら、委託可能な水準の定義が必要です。

セキュリティは認証（MFA必須・パスワード強度）・認可（最小権限）・暗号化（通信・保存・鍵管理）・監査ログ（保存期間・改ざん防止）・脆弱性対応SLA・ペネトレ試験の頻度を定義します。個人情報保護法・GDPR・PCI DSS等の規制要件は必ず織り込みます。

移行性はデータ移行方式（一括 / 段階）・並行稼働期間・ロールバック手順・カットオーバー時の停止時間・ユーザートレーニングを定義します。移行計画の設計不足でプロジェクトが破綻する事例は多く、軽視してはいけません。

さらに忘れやすい項目として、ブラウザ対応範囲・文字コード（絵文字対応）・タイムゾーン・多言語対応（i18n）・アクセシビリティ（WCAG 2.1）・災害対策（DR）があります。これらは完成後に「対応してない」と言われて炎上しがちな項目で、IPAの非機能要求グレードのような網羅チェックリストで最初に定義します。

なお非機能要件はSLA / SLOと密接に連動します。非機能要件は設計時の目標、SLOは運用時の内部目標、SLAは外部契約（違反で罰金・減額）で、SLAに影響する可用性・性能はSLAより厳しく設定するのが鉄則です（詳細はSLOとSLI）。

3つのシナリオで考える

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

可用性99%に応答3秒、日次バックアップという水準で問題ありません。IPA非機能グレードで言えば「モデルシステム1」相当で、SLAは不要ですし、RTO 24時間・RPO 1日で十分です。セキュリティは社内ID連携とTLSで最低限をカバーしておきましょう。そもそも運用体制が業務時間のみであれば、守れる可用性も99%が上限なのです。

個人・スタートアップ ― 1か月で出せる構成が正解 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-startup/

一般B2C Web・中小SaaSの場合

B2Cであれば可用性99.9%にP95 500ms、24/7のオンコール（IPAの「モデル2」）、B2B SaaSであれば可用性99.95%にSLA契約、監査ログ7年、SOC 2対応（「モデル3」）というのが目安になります。SLO管理を導入して、顧客ごとのSLAにはRTOとRPOを明記しておきます。マルチテナントの分離設計も、この段階で非機能要件に含めておきたいところです。

中小SaaS ― マネージドに寄せて少人数で回す ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-saas/

金融・決済・医療の場合

可用性99.99%以上にマルチリージョンDR、FISCやPCI DSS、HIPAAへの準拠（IPAの「モデル4」）という世界になります。24/7のSRE専属体制、年次ペネトレと四半期の脆弱性診断、FIPS 140-2認定HSMでの暗号化、改ざん防止の監査ログと、非機能要件が法規制そのものと一体化していきます。24/7体制がないのに99.99%は守れませんので、運用体制との整合が大前提です。

大企業基幹系 ― 新しい技術より組織で成立する設計 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-enterprise/

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

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

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

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

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

やってはいけないこと

非機能要件で事故る典型を、特に危険な6つに絞ります。どれも動くけど使えないシステムを生みます。

Knight Capital 2012年事件は段階的展開（Canary）・自動ロールバック・監視といった非機能要件の全欠落が致命傷でした（詳細は付録「重大インシデント事例集」）。非機能要件は「動くけど使えない」を防ぐ保険です。

AI判断軸 ― 数値化が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 フレームワーク - パフォーマンス効率 も合わせて参考にしてください。

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