AI要件定義は受け入れ条件から逆算する

AIに要件定義を任せると、最初に増えるのは機能一覧だ。だが、現場で詰まるのはそこではない。「何をもって完成とするか」が抜けると、仕様は一気にあいまいになる。

受け入れ条件は、そのあいまいさを止めるための線だ。SmartWebは受け入れ基準を、機能やユーザーストーリーが受け入れられるために満たすべき具体的で測定可能な条件として説明している。TestRailも、ユーザーストーリーと受け入れ条件は別物で、後者は完了判断の土台だと整理している。

AI要件定義では、この順番が逆転しやすい。先に「何ができるか」を並べると、レビューが感覚勝負になる。先に「何なら合格か」を置くと、要件・テスト・レビューの3つが同じ物差しで揃う。

受け入れ条件が先にあると何が変わるか

受け入れ条件を先に決めると、要件定義の会話がかなり変わる。

まず、機能の議論が「あるかないか」ではなく、「どの条件なら十分か」に変わる。これは大きい。たとえば「問い合わせ内容を要約するAI」を考えると、単に要約が出るだけでは足りない。

• どのくらいの長さなら許容するか
• どの項目を必ず残すか
• どのケースでは人間確認に戻すか
• どの出力は危険なので止めるか

この4点が見えていないと、レビューでは「なんとなく良い」「少し違う」で終わる。AIはそこをもっともらしく埋めるのが得意だから、なおさら危ない。

逆に、受け入れ条件が先にあると、AI要件定義は「書く前にレビュー設計」を決めるべき理由 と同じで、レビューの観点が先に決まる。AIエージェント要件定義は評価設計から で整理したように、評価できるものしか改善できない。

AI向け受け入れ条件は4点セットで考える

通常の要件定義と違って、AIの受け入れ条件は一文だけでは弱い。InstitutePM の「AI acceptance criteria」の整理は分かりやすい。AI機能では、少なくとも次の4つを分けて書くべきだ。

1. 振る舞いと許容揺れ

まず、何をしてほしいかを書く。ただし、AIは毎回同じ出力にはならない。だから、表現の揺れをどこまで許容するかも一緒に書く。

たとえば会議要約なら、「80〜200語の範囲で、決定事項とアクションアイテムを落とさない」といった書き方になる。見た目の一致ではなく、内容の合格を見に行く。

2. 評価のしきい値

次に、測定方法を決める。AIは印象だけで評価すると崩れる。テストセット、サンプル数、合格ラインを先に置く。

ここがないと、レビューは「たぶん良い」で止まる。Miro が AI 要件収集テンプレートで MoSCoW を使って優先順位を分けるのも同じで、曖昧なものをそのまま並べないことが重要だ。

3. 安全条件

やってはいけないことも、受け入れ条件に入れる。

AIは、正しい出力を出すことより、危ない出力を止めることが難しい。たとえば、個人情報を含む文面をそのまま外部送信しない、権限外の操作はしない、入力が不足している時は止まる、という条件だ。

4. 人間に戻す条件

最後に、人間確認へ戻す境界を決める。

AIは列挙と整形は得意だが、利害調整は苦手だ。予算が絡む変更、運用を変える変更、顧客体験の優先順位が割れる変更は、最初から人間に戻す。ここを決めておくと、後から責任線がぼやけない。

要件定義に落とすなら、先に4行書く

実務では、受け入れ条件を次の4行に分けると扱いやすい。

この4行があるだけで、要件定義はかなり締まる。NijiBox が要件定義の進め方で、目的・成功基準・スコープの言語化とレビュー・変更管理を重視しているのも、同じ理由だ。

AI要件定義でよくある失敗は、スコープが広いまま進めてしまうことだ。だから、最初に受け入れ条件を書き、そこからスコープを削る。順番を逆にすると、あとで全部必要に見えてしまう。

受け入れ条件から逆算すると、仕様の質が上がる

受け入れ条件を先に置くと、仕様の粒度も自然に揃う。

たとえば「問い合わせメールの下書きを作るAI」を考える。機能だけを見ると、下書きを生成すれば終わりに見える。だが、受け入れ条件を置くと論点は変わる。

• 差出人に不自然な敬語は入っていないか
• 返信先の社名を誤っていないか
• 機密情報が混ざっていないか
• 送信前に人間確認が必要なケースを止められるか

このあたりまで見えると、仕様書は単なる説明文ではなくなる。テストケースに直結し、レビュー設計にもつながる。

これが、AIに要件定義を任せると何が壊れるか で触れた「速く間違える」を防ぐ方法でもある。先に合格ラインがあれば、AIが速く書いても迷いにくい。

受け入れ条件はユーザーストーリーの最後ではなく、最初に置く

一般的なソフトウェア開発では、ユーザーストーリーの後ろに受け入れ条件を書くことが多い。だが、AI案件では逆の方がうまくいくことが多い。

先に受け入れ条件を書くと、次の順で考えられる。

1. 何を成功とするか
2. 何を止めるか
3. 何を人間に戻すか
4. そのために必要な入力は何か

この順番だと、後から仕様を足し込むより、最初に削る方がやりやすい。AIは広い要求をそのまま膨らませるので、最初に境界を置いた方が結果は安定する。

先に決めるなら、まずこの3つで足りる

細かいテンプレートを作る前に、最低限これだけ決めれば十分だ。

• 完了条件
• 禁止条件
• 人間確認条件

この3つがあれば、会話はかなり前に進む。そこに判定方法を足せば、レビューもテストも一段軽くなる。

逆に、この4つがない要件定義は、AIに渡すほど曖昧さが増える。見た目は整っても、現場では使いにくい。そこはかなりはっきりしている。

AI要件定義をうまく回したいなら、機能一覧から入るより、完成条件から入る。受け入れ条件は後付けの説明ではなく、最初に置くべき設計図だ。

必要なら次に、あなたのチーム向けの要件定義テンプレートを「受け入れ条件先行」で組み直せる。そこまでやると、AIの出力はだいぶ扱いやすくなる。

参考

• Writing Acceptance Criteria for AI Features
• アジャイルテストの受け入れ条件 - TestRail Blog
• 要件定義とは？発注側向けに進め方や失敗を回避するポイントを解説
• AI要件収集テンプレート | Miro

関連記事

• AI要件定義はどう変わるか？AIエージェントが現場にもたらした3つの変化
• AI要件定義は変更差分から始める
• 要件定義AIは「書く前にレビュー設計」を決めるべき理由