非機能要件からアーキテクチャを選ぶ：比較表とADRで設計判断を残す

2026年10月25日 · 約9分で読めます

「高可用で拡張しやすい」を、比較できる条件へ変える。受注システムの例で、SLO・障害時の容量・運用体制を整理し、必須条件と選好を分け、検証結果と見直す条件までADRに残します。

「高可用な受注システム」を、判断できる要件に変える

「将来伸びるのでマイクロサービスにしたい」「障害に強いので複数リージョンにしたい」。設計レビューで構成の名前から議論すると、何を解決する案なのかが見えなくなります。アーキテクトは、利用者への影響と事業上の制約を先にそろえます。

曖昧な要求	比較に使う条件	確認方法
速くしたい	合意した注文受付APIの対象リクエストの95%以上を500ms以内に応答	本番相当のデータ・偏り・負荷で測定し、本番でも同じ境界から観測
落ちにくくしたい	30日窓で対象リクエストの成功率99.9%以上。タイムアウトも失敗に含める	対象操作・成功の定義・計測地点を固定しSLIを集計
AZ障害に備えたい	1AZ停止時も残るアプリ容量でピーク負荷を扱える	障害時の負荷試験とDB切り替えを含む復旧試験
運用できる構成にしたい	合意した対応時間の初動・復旧を、権限と代替要員のある担当で行える	当番表、手順、権限、訓練結果を確認

成功には何を含めるのかも決めます。注文受付の200応答を返しただけで、注文が保存されていなければ成功とは扱えません。APIの受付と業務処理の完了が別なら、それぞれの指標を用意します。認証エラーなどの除外条件も先に合意し、都合よく失敗を分母から取り除かないようにします。

SLOを、設計と優先順位に使える数にする

サービスレベル指標（SLI）は実際の品質の測定値、サービスレベル目標（SLO）はその目標です。Google SRE Workbookは、利用者にとって良いイベントの割合を使い、関係者と目標を合意して改善判断に使う方法を説明しています。CPU使用率だけでは、注文できたかは分かりません。

上の例で30日間の対象リクエストが100万件なら、成功率99.9%のエラーバジェットは1,000件です。計算は1,000,000 × (1 − 0.999)。これはリクエスト数で定義した目標なので、停止可能な分数へそのまま換算できません。アクセスの集中する10分と深夜の10分では、影響する件数が違います。

遅延の目標は別に追います。成功率を満たしても、遅い応答が増えて500ms以内の割合が95%を下回ることがあります。SLOを外れそうなときに機能追加と信頼性改善のどちらを優先するか、誰が判断するかまで合意しておきます。

必須条件と選好を分けてから、候補を比べる

データの保存地域、必要な認可、復旧目標など、満たさないと採用できない条件を先に確認します。「費用が安いから認可の欠落を相殺する」という採点は成立しません。条件が未検証の案は、合格ではなく保留として扱います。

候補	この例での評価	採用前に確かめること
アプリとDBを単一AZに配置	AZ喪失時にそのまま継続できず、今回の障害要件を満たさない	要件を変更するなら、業務影響と復旧時間を改めて合意
アプリを複数AZに配置し、複数AZ対応のマネージドDBを使う	要件を満たすか検証する候補。DBの運用作業を一部委ねられる	DB切り替え中の挙動、接続の復旧、容量、バックアップ復元、費用
複数リージョンで書き込みを受ける	広域障害への選択肢になるが、今回必要かと運用可能性は別に判断	更新の衝突、データ複製、認可、障害判断、訓練と運用の費用

比較の範囲もそろえます。マネージドDBの利用料と、自前DBのサーバー代だけを比べると、更新・バックアップ・復旧訓練の手間が抜けます。購入する案でも、アプリ側の再接続やデータ移行は自分たちの責任です。データ出力、スキーマ変換、移行中の並行運用を含めて退出の手間を見積もります。

最も危ない前提から、小さく検証する

複数AZの図を描いても、障害時に容量が足りるとは限りません。3AZへ均等にアプリを配置し、1AZを失うと、残る各AZの負荷は理想的な均等分散で1.5倍になります。通常200req/sを各AZで約66.7req/sずつ処理していたなら、障害後は各100req/sです。

均等分散を仮定した1AZあたりのアプリ負荷。容量や応答時間の実測ではない

通常：3AZ: 約66.7 req/s
1AZ喪失：2AZ: 100 req/s

この計算はアプリへの流量の一次見積もりです。DBの書き込み能力、アクセスの偏り、切り替え中の再試行は別に確認します。データ量・ホットキー・キャッシュの状態をそろえ、AZを失った状態で目標を測ります。未検証の性能を、比較表の確定値にしないことが大切です。

ADRには「選んだ理由」と「変える条件」を残す

アーキテクチャ決定記録（ADR）は、重要な判断の背景・決定・結果を残すものです。AWSのガイドは、採択後に判断を変える場合、新しいADRで以前の決定を置き換え、経緯を保持する方法を説明しています。選ばなかった案が劣っていると断定せず、その時点の制約と判断を残します。

検証前のADRの例。未実施の試験を合格扱いにしない

状態: 提案中
対象: 注文受付の配置とDB運用
背景: 6人チーム、ピーク200req/s、1AZ障害への備え
案: 単一AZ / 複数AZ＋マネージドDB / 複数リージョン書き込み
提案: 複数AZ＋マネージドDB
理由: AZ障害要件を検証でき、DB運用の負担を一部委ねられる
代償: 利用料、製品への依存、切り替え中の一時的な失敗
未確認: DB切り替え後の再接続、復元時間、障害時p95
検証: 運用担当が負荷・切り替え・復元を試験し、業務責任者と評価
採択条件: 合意した品質・復旧目標と運用費を満たす証拠がそろう
再検討: 地域要件、ピーク負荷、復旧目標、担当体制が変わるとき

設計レビューで確かめる5つの問い

利用者のどの操作を守るのか。測定の対象、負荷、障害の範囲が明確か。
必須条件を満たす根拠があるか。仮説と測定済みの事実を分けているか。
不採用案と比べたときの利点と代償を、同じ費用・運用の範囲で説明できるか。
障害中に誰が判断し、必要な権限で操作し、結果を確認するか。
どの変化でこの判断を見直すか。期限のある未確認事項に担当がいるか。

アーキテクトの成果は、構成図に加えて、なぜその構成が今の要件に合うのかを他の人が確かめられることです。条件が変われば、同じ比較表と検証方法を使って判断を更新できます。