動くようになった機能の画面を前に、負荷や障害時の備えが抜けていないか手元のメモで一人で確かめている開発リーダー
設計・レビューでのAI活用約11分

非機能要件の抜け漏れをAIに洗わせる｜観点リストと確認の型

「機能はできました」と報告した数日後に、「で、アクセスが増えても大丈夫？」「サーバーが落ちたらどうなるの？」と聞かれてヒヤッとする。 急いで作っているときほど、目の前の「動く／動かない」に気を取られて、性能や障害時の備えは頭の隅に追いやられがちですよね。悪いのは意識の低さではなく、ひとりで機能もその周りも全部見るのは、そもそも手が回らないからです。

こういう「機能以外の備え」——非機能要件は、AIに観点を洗わせるのが向いています。 非機能要件とは、「何をするか（機能）」ではなく、「どれくらいの速さ・安定・安全で動くべきか」を決める要件のこと。性能、可用性（落ちにくさ）、運用のしやすさ、セキュリティなどが含まれます。忘れた頃に牙をむく代わりに、設計の早い段階で「抜けの候補」を並べておけば、後の手戻りとヒヤッとをぐっと減らせます。

結論：非機能要件の抜けをAIに洗わせるコツは、①観点のリストを先に渡す（性能・可用性・拡張性・運用保守・セキュリティ・移行など）→ ②各観点で「この機能だと何が問題になりそうか」を問いの形で挙げさせる → ③出た観点を今回の規模で要る／要らないに仕分けする → ④具体的な数値目標（何秒以内・何件まで）は自分で決める、の順です。AIは「考え漏れの候補」を並べる相手であって、目標値を決める相手ではありません。数字と最終判断は自分に残します。

非機能要件が抜けるのは、責められるようなミスではありません。 機能が動くことと、本番で安定して動き続けることは、見る角度が違います。角度を変えて一度ざっと洗う——その作業に、AIを気軽に足せます。

なぜ非機能要件は後回しになりやすいのか

機能要件は「何を作るか」なので、作っている最中ずっと目に入ります。一方、非機能要件は次のような性質があって、どうしても後回しになりがちです。

そして厄介なのは、非機能要件の抜けは後から直すほど高くつくことです。動いてから「やっぱり倍のアクセスに耐えたい」となると、設計から見直しになることもあります。だからこそ、実装に入る前か、遅くとも設計を固める段階で、「機能以外に、この機能はどんな条件で動くべきか」を一度洗っておくのが効きます。

ここでAIに頼むのは、「答えを出してもらう」ためではありません。自分では思いつかなかった観点を、机の上に並べてもらうためです。並べば、要る／要らないの判断ができます。頭の中にないものは、判断の対象にすらならない——そこを埋める相手として使います。

洗わせるための観点リスト

非機能要件を性能・可用性・運用の3つの観点に分けて、それぞれ何を確かめるのかを情景で示した観点マップ

まず、AIに見てほしい観点のリストを渡します。丸ごと「非機能要件を洗って」と頼むより、切り口を先に示す方が、この機能に紐づいた具体的な指摘が返ります。実務でよく効く観点を挙げておきます。

観点AIに洗わせることひとことで言うと
性能応答時間・同時アクセス・データ量が増えたときの重さ「遅くならない？」
可用性障害・メンテ時の振る舞い、どこまで止まってよいか「落ちたらどうする？」
拡張性利用が増えたとき／機能を足すときの伸ばしやすさ「増えても平気？」
運用・保守ログ・監視・アラート・復旧、誰が面倒を見るか「本番で困るのは誰？」
セキュリティ認証・認可、扱うデータの機密度、入力の検証「守るべきものは？」
移行・互換既存データの移行、旧仕様との両立、切り替え手順「今あるものは？」

全部を毎回使う必要はありません。今回の機能で不安な観点を2〜3個選べば十分です。渡すプロンプトの例：

これから作る機能の概要を渡します。あなたはレビュアーとして、
次の観点ごとに「この機能で考え漏れになりそうな点」を挙げてください。
- 性能（応答時間・同時アクセス・データ量）
- 可用性（障害時・メンテ時の振る舞い）
- 運用・保守（本番で誰がどう面倒を見るか）

各観点について、
・気になる点（この機能だと具体的に何が問題になりそうか）
・確認すべき問い（自分やチームに投げるべき質問の形で）
を挙げてください。
まだ数値目標や結論は出さなくて大丈夫です。
この機能では関係が薄い観点は「今回は影響が小さい」で構いません。

【機能の概要】
（作るもの・想定する使われ方・扱うデータ・現時点で分かっている制約を3〜10行で）

ポイントは3つあります。 ひとつ目は、観点を先に指定すること。これで指摘が「この機能のここ」に紐づきます。 ふたつ目は、「確認すべき問い」の形でも出させること。断定ではなく問いなら、あなたが確かめて答える余地が残ります。 みっつ目は、「関係が薄い観点は影響が小さいでよい」と添えること。これを入れないと、AIは全観点で無理に問題をひねり出し、今回は要らない心配まで並べがちになります。

出た観点を「今回の規模」で仕分けする

観点別に洗うと、「あれも」「これも」と考え漏れの候補が10も20も出てきます。全部に備えていたら、小さな機能が大げさな設計になってしまいます。そこで次に、今回の規模でどこまで要るかを仕分けします。

さきほど挙げてくれた点を、今回の規模を前提に3つに仕分けしてください。
今回の規模：（例：社内利用・同時数十人・1日数千件・止まっても数分は許容）

- 今回必要：この規模でも備えておくべき
- 今回は過剰：将来必要になるかもしれないが、今は見送ってよい
- 要判断：規模や方針次第で、人が決めるべき

それぞれ、なぜその仕分けかの理由も一言添えてください。

規模の前提を渡すのが肝です。同じ「同時アクセス対策」でも、社内数十人と一般公開では必要度がまるで違います。前提なしに聞くと、AIは大きめ・安全側に振った一般論を返しがちで、小さな機能に過剰な備えを勧めてくることがあります。「今回は過剰」を明示的に許すと、身の丈に合った線引きに近づきます。

こうして仕分けると、「今回必要」だけに絞って設計を詰められます。忙しい日は、「今回必要」の観点だけ手を打って、残りはメモに残すだけでも十分前進です。大事なのは、頭の中になかった観点が一覧になって、判断の対象に変わったことです。

なお、このやりとりはチャットに概要を貼るだけでも回りますが、Claude Code・Cursor・GitHub Copilot のような CLI／エージェント型の道具なら、設計メモや既存コードを読ませたうえで観点別に洗わせられます。実際の作りに沿う分、指摘が具体的になります。それでも、次の「数値と判断は自分で持つ」線引きは変わりません。

鵜呑みにしない——数値目標と判断は自分で持つ

ここが、いちばん大事な所です。 AIが挙げるのは、あくまで「考え漏れの候補」であって「確定した要件」ではありません。もっともらしく書かれていても、次のような外れが混ざります。

とくに注意したいのが、具体的な数値目標です。「同時1000アクセス」「99.9%の稼働率」「3秒以内の応答」——こうした数字は、業務の要求・利用者数・予算・許容できる停止時間から人が決めるものです。AIが挙げた数字は「たたき台」にはなりますが、そのまま要件にはできません。ここはAIに任せず、関係者と握る部分です。

だから、洗い出した観点は次のように受け止めます。

AIに「この観点、今回の規模で本当に要る？」と聞き返すのも有効です。ただしAIは要る・要らないのどちらにも簡単に傾くので、最後の線引きは自分で。要件に入れるのも外すのも、理由を自分の言葉で言える状態にしておきます。もっともらしい誤りの見抜き方はAIのハルシネーション（もっともらしい誤り）の見抜き方に、そもそもAIに任せてよい範囲はAIに任せてはいけない判断・領域の線引きにまとめています。

明日、まず試すこと

いきなり全観点でやろうとしなくて大丈夫です。今、手元にある機能か、これから作る一件で、次の小さな一歩だけ踏んでみてください。

  1. 不安な観点を2つだけ選ぶ（迷ったら「性能」と「可用性」が効きやすい）
  2. 上のプロンプトに機能概要を3〜10行で貼って、観点別に洗わせる
  3. 今回の規模（利用者数・件数・許せる停止時間）を伝えて、要る／過剰に仕分けさせる
  4. 「今回必要」の観点だけ、具体的な目標値を自分で決めてメモに書く
  5. 決めた内容（この観点はこの数字で／今回は見送り）を一行残して、必要なら関係者に確認する

これだけで、「機能はできたけど本番は不安」が「どこまで備えるか決めた上で進める」に変わります。

非機能要件 洗い出しチェックリスト

洗わせる前と、指摘を受け取った後で、さっと確認します。全部に○が要るわけではなく、関係する所だけで十分です。時間がない日は、太字の2つ——「観点を指定した」「数値目標は自分で決めた」——だけ押さえれば及第です。

洗わせる前

指摘を受け取った後

最後に

機能を動かすだけでも、精一杯の日があります。そのうえ性能も障害対応も運用も、と全部ひとりで抱えるのは、正直しんどいものです。抜けがあっても、それはあなたの怠慢ではなく、見るべき角度が多すぎるからです。

でも、答えをもらうためでなく、もう一つの角度から考え漏れを並べるためにAIを使えば、頭の中だけにあった「なんとなくの不安」が、仕分けできる一覧に変わります。備えるところは備え、今回は見送るところは見送る。そう決めた上で進められれば、後から「なぜ考えてなかったの」と問われても、落ち着いて答えられます。

非機能要件の観点を洗い出して要る・要らないを決め終え、納得して次の設計へ進もうとしている開発リーダー

全観点でなくても、今日ひとつ「アクセスが増えたら？」とAIに洗わせて、要る数字を自分で決められたなら、それはもう、忘れた頃の牙を先回りで抜く一歩です。

よければ、こちらも

関連用語