AIに受け入れ条件を言語化させる｜仕様の曖昧さを先に潰す
「一覧に、検索をつけておいてもらえますか」
そう頼まれて、会員一覧に名前の検索欄をつけました。入力した名前と一致する会員が出てくる。動作確認もして、レビューも通して、リリース。
数日後、依頼した人から連絡が来ます。
「名前の一部だけだと出てこないんですね。あと、退会した人も出てきちゃってて……」
こちらは完全一致のつもりで、退会者のことは考えていなかった。向こうは部分一致のつもりで、退会者は出ないのが当たり前だと思っていた。どちらも間違ってはいません。「何ができたら完成か」が、どこにも書かれていなかっただけです。
この「完成の条件」を、受け入れ条件と呼びます。依頼した人が「これで受け取ります」と言える条件を、作る前に言葉にしたもののことです。英語では Acceptance Criteria と書かれることもあります。
この記事では、受け入れ条件をAIに言語化させて、仕様の曖昧さを作る前に潰す方法を整理します。
結論：順番は3つです。①書き出す——依頼の文章をAIに渡し、「〜できる」「〜のときは〜になる」の形の条件に分けてもらう。②問い返す——曖昧な言葉と決まっていない点を、AIに質問の形で出させる。答えは推測させず、依頼した人に聞く。③例で固める——決まった条件を、具体的な入力と結果の例に書き直し、依頼した人に「この例で合っていますか」と確かめる。
覚え方は 書き出す → 問い返す → 例で固める。①がないと②で何を聞けばいいか分からず、③がないと「合意したつもり」が残ります。
今日ぜんぶやる必要はありません。次の依頼を1件だけ選んで、②の「質問リスト」をAIに作らせるだけでも、打ち合わせの中身が変わります。
何が起きているのか——曖昧さは「言葉」ではなく「前提」にある
打ち手の前に、なぜ受け入れ条件が曖昧なまま作り始めてしまうのかを整理します。原因の側を見ておくと、AIに何を頼めばいいかが見えてきます。
1つ目は、依頼の言葉が短いこと。「検索をつけて」「CSVで出せるように」「承認フローを入れて」。頼む側の頭の中には具体的な絵がありますが、言葉にすると、その絵の大半は省かれます。省かれた部分は、作る側が自分の前提で埋めることになります。
2つ目は、「当たり前」が人によって違うこと。退会者は出ないのが当たり前、部分一致が当たり前、並び順は新しい順が当たり前。当たり前だと思っていることほど、誰も書きません。
3つ目は、うまくいく場合しか話していないこと。「名前で検索したら会員が出る」は話しても、「0件だったら何を表示するか」「1万件ヒットしたらどうするか」はたいてい話していません（境界値・異常系をAIに考えさせて漏れを減らす手順）。
4つ目は、AIに頼むと、曖昧さがそのまま実装に変わること。「会員一覧に検索をつけて」とAIに頼めば、動くコードはすぐ出てきます。ただそのコードは、曖昧だった部分をAIがもっともらしく決めたものです。部分一致にするか、退会者を含めるか、AIは黙って選んでいます（AIにコードを書かせる前に渡す前提と制約｜伝え方の型）。
5つ目は、「確認しました」が言葉のままで終わっていること。打ち合わせで「部分一致で」と決めても、「田中」で「田中太郎」と「山田中子」の両方が出てよいのかまでは確かめていない。言葉の合意は、例に落とすまで意外とずれています。
6つ目は、AIが「依頼した人の意図」までは知らないこと。AIは、曖昧な言葉を見つけて質問にするのは得意です。けれどその質問の答えを知っているのは、依頼した人だけです。
裏を返すと、これは聞き方の問題です。書く前に「何が分かっていないか」を一覧にすると、聞くべきことが自然に見えてきます。そして曖昧な言葉を拾い出すのは、AIがかなり得意な作業です。
具体例——つい、こうなりがちという形
どれも「早く形にして見せよう」という前向きな気持ちから生まれます。心当たりのある行があれば、そこだけ見れば十分です。
- 「検索できるように」：部分一致か完全一致か、ひらがなとカタカナを同じに扱うか、全角と半角はどうするか。どれも決めないまま、どれかで実装されます。
- 「一覧で見られるように」：何件ずつ表示するか、並び順は何か、削除済み・退会済みのデータを含めるか。
- 「CSVで出せるように」：全件か、画面で絞り込んだ結果だけか。文字コードは何か、Excelでそのまま開けるか。
- 「承認が必要なようにして」：誰が承認するのか、差し戻されたらどこへ戻るのか、承認者が不在のときはどうするか（AIに状態遷移の抜けを洗わせる｜ステートマシンの穴の見つけ方）。
- 「速くして」：何秒なら速いのか、どの画面のどの操作の話なのか。数字がない「速く」は、終わりが決まりません（非機能要件の抜け漏れをAIに洗わせる｜観点リストと確認の型）。
- 「メールで通知して」：誰に、いつ、何回。送れなかったときはどうするか。
- 「いい感じに」「分かりやすく」：受け入れる側の感覚でしか判定できない言葉。これが残っていると、完成の判定がいつまでも決まりません。
影響——完成の条件がないと、「終わり」が決まらない
急いで全部直さないと大変、という話ではありません。ただ、あとから効いてくる種類の問題なので、書いておきます。
- 作り直しが出る：リリース後に「そういう意味じゃなかった」が来ると、設計からやり直すこともあります。作る前の10分の質問が、あとの数日を減らします。
- 見積もりがぶれる：条件が決まっていないと、どこまで作れば終わりなのかが決まらず、工数の説明もしにくくなります（「AIで早くなるよね」と言われた見積もり｜工数の織り込み方）。
- テストの合否が決められない：「検索できる」だけでは、何を入れて何が出れば合格なのか、テストが書けません。
- レビューで何を見ればいいか分からない：コードが正しく動いていても、「正しい」の基準がなければ、レビューは書き方の話だけで終わります（AIにレビューさせてもバグが残る｜人が見るべき観点）。
- 依頼した人との関係が少しずつすり減る：どちらも悪くないのに、「言ったのに」「聞いてない」が積み重なります。
少し安心できる話をすると、この領域は打ち手がはっきりしています。分厚い仕様書を書く必要はありません。分かっていないことを質問にして、答えを例で確かめる。それだけで、ずれの大部分は作る前に見つかります。
明日からやること（書き出す・問い返す・例で固める）
上から順に、小さく始められます。今日は②だけでも構いません。
1. 書き出す——依頼を「条件」の形に分ける
依頼の文章は、そのままでは確かめようがありません。まず、確かめられる形に分けます。
- 依頼を1件だけ選ぶ。チケット、チャットのやり取り、打ち合わせのメモ。原文をそのままAIに渡します。自分で要約してから渡すと、自分の前提が混ざります。
- 「〜できる」「〜のときは〜になる」の形に分けてもらう。「検索をつけて」なら、「名前で会員を検索できる」「検索結果は一覧に表示される」のように、1文に1つの条件にします。
- 誰の立場の条件かを添える。利用者なのか、管理者なのか、担当者なのか。同じ機能でも、見る人によって完成の形が変わります。
- 既存の画面や仕様があれば、一緒に渡す。今ある一覧画面の並び順や表示件数は、新しい条件の「当たり前」の出どころになります。
2. 問い返す——曖昧な言葉と未定の点を、質問にする
ここがいちばんAIの効くところです。条件の一覧を渡して、「決まっていないこと」を質問の形で出してもらいます。
- 答えをAIに決めさせない。AIに出してもらうのは「部分一致ですか、完全一致ですか」という質問まで。どちらを選ぶかは、依頼した人に聞きます。
- うまくいかない場合の質問も出させる。0件のとき、件数が多すぎるとき、入力が空のとき、権限がない人が使ったとき。うまくいく場合の条件だけで終わらせないのがコツです。
- 「いい感じに」「速く」のような言葉に印をつけさせる。判定の基準がない言葉を、数字や具体的な状態に言い換える質問にしてもらいます。
- 質問は、答えやすい形に整える。「検索の仕様はどうしますか」ではなく、「『田中』で検索したとき、『山田中子』さんも出てよいですか」。選択肢か具体例つきの質問にすると、忙しい依頼者でも数秒で答えられます。
- 質問が多すぎたら、優先をつける。作り方が大きく変わるものから先に聞き、見た目の細かい点はあとに回します。全部を一度に聞かなくて大丈夫です。
3. 例で固める——決まったことを、具体的な入力と結果に書き直す
言葉で合意しても、まだずれは残ります。最後に具体例に落として、同じ絵を見ているか確かめます。
- 「前提・操作・結果」の3つで書く。「退会済みの会員『田中太郎』がいる状態で（前提）、『田中』で検索すると（操作）、『田中太郎』は表示されない（結果）」。この形は Given / When / Then とも呼ばれ、テストの書き方としても広く使われています。
- 例は、境目を選ぶ。ふつうの例より、「これは出る？出ない？」と迷う例のほうが、ずれを見つける力があります。部分一致なら「途中に含む名前」、件数なら「ちょうど上限の件数」。
- 依頼した人に、例のまま見せる。条件の文章より、例のほうがずっと確かめやすいものです。「この5つの例で合っていますか」と聞けば、言葉では出てこなかった前提が返ってきます。
- 合意した例を、そのままテストにする。例が「前提・操作・結果」でそろっていれば、テストケースはほぼできています。AIに例からテストコードを書かせやすいところです（AIにテストケースを洗い出させる｜観点の与え方）。
- 例は、チケットや仕様書に残す。あとから「なぜこうなっているのか」を聞かれたとき、合意した例があれば、それが答えになります（仕様書・設計書のドラフトをAIで作る｜叩き台の作り方と注意点）。
AIに相談するときのプロンプト（コピーして使えます）
前提を渡さないと、AIは曖昧な点をもっともらしく埋めてきます。質問の形で出すこと、答えを推測しないことを、先に伝えるのがコツです。
ある機能の依頼について、受け入れ条件（何ができたら完成か）を言葉にする手伝いをお願いします。
①下の依頼文をもとに、「〜できる」「〜のときは〜になる」の形の条件に分けてください。1文に1つの条件にしてください。
②条件の中で、意味が人によって変わりそうな言葉（「検索」「一覧」「速く」「分かりやすく」など）に印をつけてください。
③決まっていない点を、依頼者への質問の形で挙げてください。答えを推測で決めないでください。質問は、選択肢か具体例をつけて、短く答えられる形にしてください。
④うまくいかない場合（0件・件数が多い・入力が空・権限がない・途中で失敗した など）について、決まっていない点も質問にしてください。
⑤質問に、作り方が大きく変わるもの／あとから変えやすいものの区別をつけてください。
⑥最後に、依頼者に確かめるための具体例を、「前提・操作・結果」の形で5つほど作ってください。判断が分かれそうな境目の例を優先してください。結果が決まっていない例は、結果を「要確認」としてください。
依頼文（原文のまま）：（ ） 利用する人：（ ） 関係する既存の画面・仕様：（ ） すでに決まっていること：（ ）
③の一文が効きます。「推測で決めないで」と先に伝えるだけで、AIが黙って選んでしまうのを防げます。分からないことが分からないまま見えることが、この作業のいちばん大事なところです。
出てきた質問と例は、次の3点だけ自分の目で確かめます。（1）依頼文にない機能や条件が、いつのまにか足されていないか、（2）「要確認」と書かせた例に、推測の結果が入っていないか、（3）質問が、依頼した人の言葉で答えられる形になっているか。技術の言葉だらけの質問は、そのまま渡すと答えが返ってきにくいので、一言だけ言い換えておくと親切です。
受け入れ条件を固めるチェックリスト（コピーして使えます）
全部に○が要るわけではありません。気になった行だけで十分です。
① 書き出す
- 依頼を1件に絞り、原文のままAIに渡したか
- 「〜できる」「〜のときは〜になる」の形で、1文1条件に分けたか
- 誰の立場の条件か（利用者・管理者・担当者）を添えたか
- 関係する既存の画面・仕様も一緒に確認したか
② 問い返す
- 意味が人によって変わる言葉に印をつけたか
- 決まっていない点を、選択肢か具体例つきの質問にしたか
- 質問の答えを、AIではなく依頼した人から聞いたか
- うまくいかない場合（0件・多すぎる・空・権限なし・失敗）も質問に入れたか
- 「速く」「分かりやすく」を、数字や具体的な状態に言い換えたか
③ 例で固める
- 決まった条件を「前提・操作・結果」の例に書き直したか
- 判断が分かれそうな境目の例を入れたか
- 依頼した人に、例のまま見せて確かめたか
- 合意した例を、チケットや仕様書に残したか
- 例をテストケースに落としたか
この記事のまとめ
「そういう意味じゃなかった」は、どちらかの落ち度ではなく、完成の条件が言葉になっていなかったことから生まれます。
やることは3つ。①書き出す——依頼を「〜できる」「〜のときは〜になる」の条件に分ける。②問い返す——曖昧な言葉と未定の点をAIに質問の形で出させ、答えは依頼した人に聞く。③例で固める——決まったことを「前提・操作・結果」の具体例にして、同じ絵を見ているか確かめる。
AIに相談するときは、「答えを推測で決めないで、質問にして」と先に一言添える。それだけで、分かっていないことが、分かっていないまま見えるようになります。
「一部だけだと出てこないんですね」と言われたとき、まず自分の作り方を疑ったと思います。実際には、あなたは頼まれたとおりに作っていて、完成の条件がまだ言葉になっていなかっただけでした。
これは、気をつけて防ぐ種類のものではありません。質問にして、例にして、見える形にする種類のものです。そして質問の一覧は、AIが数分で下書きしてくれます。
今日は、次に届いた依頼を1件だけAIに渡して、「決まっていないこと」を質問にしてもらう。その質問を依頼した人に聞くだけで、次の「そういう意味じゃなかった」は、きっと作る前に見つかります。
よければ、こちらも
- 仕様書の叩き台は仕様書・設計書のドラフトをAIで作る｜叩き台の作り方と注意点
- 例をテストにするならAIにテストケースを洗い出させる｜観点の与え方
- うまくいかない場合の洗い出しは境界値・異常系をAIに考えさせて漏れを減らす手順
- 「速く」を数字にするなら非機能要件の抜け漏れをAIに洗わせる｜観点リストと確認の型
- 条件が決まったらAIに実装タスクを分解させる｜WBSの抜けを見つける使い方
- AIに書かせる前の渡し方はAIにコードを書かせる前に渡す前提と制約｜伝え方の型
- 画面をまたぐ流れの確認はE2E・結合テストのシナリオをAIに書かせる——観点の渡し方