AIで作るユーザーストーリーの受入条件：検証できる20の例

ストーリー、受入条件、テスト、完成の定義を分ける

ユーザーストーリーは、誰にとって何が役立つのかを表します。受入条件は、解決策が満たすべき条件です。テストケースは、特定のデータと環境でその条件をどう観察するかを定めます。テスト結果は、実際に何が起きたかの記録です。これらを分けておけば、実装の変更に紛れて業務上の約束まで変わることを防ぎやすくなります。

この区別は生成AI以前から重要でした。Agile Allianceは、Ron JeffriesによるCard、Conversation、Confirmationのモデルを2001年に位置付けています。今日の実務に置き換えると、カードを生成することは、関係者との対話や結果の確認を代替しません。Agile Alliance：Three Cs。

Scrumの完成の定義は、インクリメントに求められる製品品質の状態を示します。一つの招待テストが通っても、共通の品質要求が免除されるわけではありません。逆に、技術チェックリストを完了しても、未決定の招待方針は確定しません。Scrum Guide：完成の定義。

状態変化を説明するときはGiven–When–Thenが使えます。Cucumberでは開始時の状況、出来事、観察可能な結果を分け、実行には対応するステップ定義が必要です。本稿の例は仕様を説明する文章であり、導入済みのCucumberテスト一式ではありません。Cucumber Gherkinリファレンス。

具体例を書く前に、招待の規則を揃える

架空のワークスペースW7の定員は十席です。正式メンバー八人と、有効期限内の保留中招待一件で、九席を使用しています。オーナーはmina@example.testをMemberとして招待したいと考えています。このアドレスは合成テストデータであり、実際にメールを送る対象ではありません。保留中の招待と正式メンバーの資格は別の状態です。

機能を四つの関連ストーリーに分けます。INV-01は招待作成、INV-02は通知の配信状態、INV-03は期限切れと取り消し、INV-04は対応する操作方法と言語での使いやすさを扱います。機能全体のチェックリストを、一つの小さな見積もり可能なストーリーに見せかけないための分割です。

これらは教材用の決定であり、セキュリティ標準、メール仕様、推奨SLAではありません。実際の資料には、方針の版、承認者、適用開始日も添えます。二つのメモが矛盾する場合は、責任者が適用規則を決めるまで矛盾を明示しておきます。

たとえば営業メモの「誰でも招待できる」はP1を上書きしません。また、定員十席はOpenMaxの料金プランの説明ではありません。保留中の招待が席を予約するかどうか未決定なら、まずその質問をしてください。自然に見える仮定も、確認されるまでは仮定です。

20の受入条件：観察結果と見落としやすい反例

機能全体の確認候補として読んでください。各例には動作と、表面的な確認では見逃す理由を示しています。関連する複数の結果を含む場合は、曖昧な「一部合格」にせず、それぞれのアサーションを記録します。

1. 作成に成功しても、宛先はまだ保留中

W7の使用済み席数が九で、操作者が現在も権限を持つオーナーの場合、新しい有効な宛先をMemberとして送信すると、権限のある招待画面にI77がPendingとして現れ、使用済み席数は十になります。正式メンバー画面は八人のままです。P1–P4、INV-01。 成功メッセージだけでは、保存の失敗や早すぎるメンバー作成を見逃します。許可されたテストアクセスで両方の観察結果を残します。

2. 必須メールが空なら、ほかの入力は保持する

メールは空でもMemberと備考が入力済みの場合、送信するとメール必須のエラーを示し、招待を作りません。役割と備考は修正のために残ります。P2、INV-01。 このフォームで承認された空文字と空白のみのデータを用います。「宛先をここに入力」のようなAIの仮テキストを有効値と扱ってはいけません。エラー表示と入力保持は別々に確認します。

3. 任意の備考に内容を補わない

必須項目が有効で備考が未設定なら、招待を作成した後も備考は未設定です。P2、INV-01。 あいさつ、人物関係、招待理由を勝手に生成しません。画面でエラーが出ないだけでなく、招待詳細の未設定値を確認します。将来、特定の役割に備考が必要になった場合は、新しい条件付き規則として扱い、この例を黙って変えないようにします。

4. 形式検証とメール到達を混同しない

承認済みの不正データmina.example.testを送信すると、形式エラーを示し、招待も通知ジョブも作成しません。P2、INV-01。 有効データmina@example.testで確認できるのは、この製品の入力規則を満たすことだけです。メールボックスの実在、所有者、到達可能性は証明できません。AIに万能の正規表現を作らせず、チームのメール検証仕様を使います。

5. 招待からオーナー権限を付与しない

招待作成がMemberとViewerだけを許可する場合、Ownerを指定した要求は拒否され、新しい招待は作られません。P2、INV-01。 表示される選択肢だけでなく、書き換えた要求も試します。ドロップダウンに選択肢がないことは、サーバーが許可値を強制している証拠ではありません。オーナーの移譲は、別の認可されたストーリーに属します。

6. 最後の一席を正しく扱う

使用済み九席なら、新規招待一件で十席にできます。十席なら、別の新規宛先への招待は定員の説明とともに拒否し、予約を増やしません。P3、INV-01。 満員時の拒否だけを確認すると、最後の空席まで誤って拒否する不具合を見逃します。正式メンバー数と保留中の予約数を分けて記録し、合計の根拠を説明できるようにします。

7. 要求キーを変えても、同じ宛先を二重招待しない

同じ宛先のI77がW7でPendingの場合、オーナーが別の論理要求キーで再度招待しても、既存の招待を示し、新しい席を予約しません。P3–P4、INV-01。 宛先の同一性や正規化は、実際のID管理責任者と定義します。教材では完全に同じアドレスを使います。別名や大文字小文字をすべてのメール環境でどう扱うかまで、この例から決めることはできません。

8. 正式メンバーをもう一度招待しない

宛先がすでにW7の正式メンバーなら、招待要求に対して、権限のある画面で既存のメンバーであることを説明します。招待数と使用済み席数は増えません。P3、INV-01。 保留中の招待とは異なる状態なので、別のデータが必要です。親切な説明をしようとして、別テナントでの所属情報を表示しないようにします。

9. Viewerの直接要求も拒否する

W7でViewerの操作者が作成要求を直接送信した場合、アクセスを拒否し、招待状態を変更しません。P1、INV-01。 教材では403を返します。確認対象はInviteボタンが隠れているかどうかではありません。実際の認可と情報開示の扱いは、呼び出し元に何を返すかも含め、セキュリティ担当者のレビューが必要です。

10. フォーム表示後の権限変更を反映する

フォームを開いたときはOwnerでも、送信前にViewerへ変更された場合、状態変更の時点で要求を拒否し、席を予約しません。P1、INV-01。 ページ表示時の確認だけでよい、という古い権限への依存を検出する例です。テストでは役割変更を制御し、後続の結果を観察します。「以前は権限があった」は現在の権限を求める規則の代わりになりません。

11. 識別子の変更で別ワークスペースへアクセスしない

W7のオーナーでもW8に権限がない操作者がW8を対象に要求した場合、拒否し、W8のメンバー、招待、定員を開示しません。P1、INV-01。 通常のワークスペースだけでなく、権限のない対象を明示的に試します。実際の応答はセキュリティ方針に従います。存在しない対象と、存在してもアクセス禁止の対象を、あえて区別させない設計もあります。

12. 変更のない再送は元の招待を返す

K77でI77を作成した後、24時間の再取得可能期間内に、現在も権限のある同じ操作者がW7で同じ内容を送ると、I77を返し、予約は増えません。P4、INV-01。 範囲にはワークスペース、操作者、キー、要求内容が含まれます。連続クリックと応答喪失は別の場面として記録します。ネットワーク要求が一回増えても、新しい業務上の招待が必要になったとは限りません。

13. 同じキーで内容を変えたら競合を示す

K77がMember招待を作成済みの場合、同じK77でViewerへ変更した要求は競合となり、I77は変わりません。P4、INV-01。 教材の応答は409です。変更した内容に「成功」と返すと、要求した役割変更が実行されていない事実を隠してしまいます。既存招待の編集を許すなら、その操作の仕様と権限を別途定義します。

14. 同時要求で最後の一席を二重使用しない

使用済み九席に初期化したW7で、異なる新規宛先の二要求が最後の一席を同時に求める場合、作成できる招待は一件だけです。もう一件は定員による拒否となり、最終合計は十一ではなく十になります。P3、INV-01。 手動で順番に二回クリックしても並行処理の証拠にはなりません。開発側が制御可能な同時実行テストを用意し、両応答と最終的な定員表示を記録します。

15. 応答喪失を、作成失敗と断定しない

サーバーではI77が作られたものの応答が失われた場合、期間内に変更のないK77要求で照合すると、既存招待を取得し、追加予約は発生しません。P4、INV-01。 照合前は結果不明であり、画面で作成失敗と断定してはいけません。24時間を過ぎたら、合意済みの復旧経路で保留中の招待を調べます。キーによる再取得が永久に保証されるとは考えません。

16. 配信失敗で、保存済み招待まで消さない

I77がPendingで通知配信に一時的な障害が起きた場合、教材で定めた三回の試行後は担当者の対応待ちとします。I77と一席分の予約は引き続き確認できます。P6、INV-02。 キューに入ったメールを到達済みと表示しません。安定したイベントIDは重複排除に役立ちますが、外部の受信箱であらゆる障害時に必ず一通だけ届く、という保証ではありません。

17. 有効期限は正確な時点で判断する

I77の作成時刻は2026-01-05T10:00:00Z、期限は2026-01-07T10:00:00Zです。ほかの条件を満たせば、その直前の受諾要求は進められますが、期限と同じ時点では進められません。P5、INV-03。 時計を制御して確認します。期限切れによる予約解放は一回だけで、状態は説明可能なまま残します。受諾後のメンバー作成は別ストーリーで定義し、リンクがあるだけで自動加入できると仮定しません。

18. 取り消しの再実行で二席を解放しない

権限のあるオーナーがPendingの招待を取り消した後、再び取り消してもRevokedのままで、予約解放は一回だけです。P1、P5、INV-03。 使用済み十席から、最初の解放で九席になり、二回目も九席を維持します。受諾と取り消しが競合する場合は、別途競合規則が必要です。順次実行の例もAIの文章も、その判断を代わりに決めることはできません。

19. キーボードでメールエラーを見つけ、修正できる

対応するキーボードとスクリーンリーダーの組み合わせで、メール必須エラーが起きたとき、利用者は対象項目とエラーを認識し、ポインターなしで修正箇所へ移動し、ほかの入力を失わず再送できます。P7、INV-04。 ブラウザー、支援技術、フォーカス、読み上げの証拠を記録します。Tabキーで一度巡回しただけでは、包括的なアクセシビリティ評価やWCAG適合の証明にはなりません。

20. 言語とタイムゾーンが違っても同じ期限を示す

I77のUTC期限を東京、上海、UTCの文脈で表示すると、1月7日の19:00、18:00、10:00となり、承認済みの文言と明確なタイムゾーンを表示します。P7、INV-04。 保存する期限と招待IDは変えません。実際の狭い画面での表示と未翻訳時の代替表示を確認します。文字列を翻訳しただけでは、ローカライズの検証が終わったとは言えません。

AIの条件案を五段階で具体化する

1. 最小限の有効な資料を固定する。 ストーリー、P1–P7に相当する実際の規則、承認済みデータ、対象外事項、未解決の質問を揃えます。本番の招待トークンや個人アドレスは除きます。AIが読めない資料は欠落として報告し、確認したことにしません。
2. 候補と反論を一緒に求める。 規則ID、開始状態、操作、結果、禁止する副作用、反例を各候補に付け、足りない判断を質問にします。承認済みの根拠がない規則は、一般的に聞こえても提案のままです。
3. プロダクト、開発、QAで具体例を検討する。 「保留中の招待は席を予約するのか」のような違いを明確にします。Example Mappingは規則、例、未回答の質問を分けます。質問を文章の推敲で消さず、解決するまで残します。Cucumber Example Mapping。
4. 範囲を承認してからテストに結び付ける。 作成、配信、ライフサイクルを一つのまとまった小さなストーリーにできなければ分割します。安定した条件IDと版を付け、業務判断者と技術的な実現性の判断者を明確にします。生成テストのアサーションも独立してレビューします。
5. 結果に合わせて期待値を書き換えない。 承認版に対してビルド、環境、証拠を記録し、失敗、実行阻害、未実行を区別します。方針が変われば旧結果を残し、影響するテストを再評価します。観察後に期待値をこっそり変えて合格を作らないことが重要です。

上流の未解決リスクにはAIプロジェクトリスク登録テンプレートが使えます。提供後のプロセス改善にはスプリントふりかえり分析ガイドを参照できます。ただし、ふりかえりは個別機能の受入証拠を代替しません。

弱い条件案と、不完全なテスト記録を読み解く

以下は、AIが出しそうな弱い表現を編集者が作った例です。実測したモデルの出力履歴ではありません。見栄えのよい文章にするのではなく、どの業務上の誤りを直すのかを明確にします。

ダウンロード資料の12件は、T01–T04が合格、T05は認可の強制に失敗、T06が合格、T07の並行処理は未実行、T08–T10が合格、T11のキーボードとエラー処理は失敗、T12の日本語表示は未実行です。合格八件、失敗二件、未実行二件となります。計画12件のうち10件を実行し、その10件のうち八件が合格しました。計画全体で合格証拠があるのは八件です。

分母が違えば答える質問も違います。これらは交換可能な「品質スコア」ではありません。また、この12件だけで20の条件すべてを確認しているわけではありません。実行済みの合格率が80%でも、認可の失敗がある動作は受け入れられません。並行処理を実行していなければ、その合格証拠はありません。修正し、未実行の確認を行い、残りの網羅性を見直すのが妥当です。

これは架空の証拠を読む練習です。記録を作るために招待バックエンド、メール事業者、OpenMaxのフローを実行したわけではありません。資料から件数や割合を計算し直すことはできますが、確認できるのは12件の教材記録の解釈だけであり、製品の動作ではありません。

不確実性に合う、最も簡単な整理方法を選ぶ

ストーリーが小さく、決定者と話せるなら、短い対話と共有文書で十分な場合があります。準備は少なく、意見の違いを見える形にできます。一方、記録する人がいなければ判断は失われます。自動化を増やす前に、版を管理したワークシートを用意します。

バックログツールに備わるテンプレートは、規則、例、証拠を毎回そろえる助けになります。ただし意味の正しさは判断しません。必須の入力欄には、承認済みの方針も創作された方針も書けます。自動構文チェックが得意なのは、IDの欠落や形式の不備であり、業務規則の正しさではありません。

動作が合意され、システムを操作できる段階では、実行可能なテストが役立ちます。ただし間違った期待を忠実に実行することもあります。業務規則とアサーションは別々に確認してください。長い文脈を繰り返し扱うときはAIの整理支援が有用ですが、もっともらしい未承認の詳細が加わるリスクもあります。小さくレビューした試行の後に、版管理と書き込み権限を明確にして範囲を広げます。

OpenMaxが支援できる部分と、代替できない判断

OpenMaxのAIプロダクトマネージャー向け公式資料には、ユーザーストーリー、受入条件、対象外の動作、未解決の質問を整理するPRD生成プロンプトがあります。これは要求の草案作成という用途の根拠であって、招待エンジンや自社テスト環境との接続が実証されたという意味ではありません。OpenMax AIプロダクトマネージャーの用途。

有用な引き継ぎは、機密情報を除いた要求資料から条件案を作り、チームにレビューしてもらう形です。承認済みバックログとテスト証拠の正式記録は、チームが定めたシステムに残します。書き込みや連携を有効にする前に、利用可能なコネクター、許可範囲、レビュー方法、復旧動作を自分たちの環境で確認します。本稿ではそれらを実機検証していません。

次のオリジナルプロンプトから始められます。

添付した承認済み規則だけを使い、INV-01の受入条件案を作成してください。規則ID、操作者、開始状態、操作、観察可能な結果、禁止する副作用、反例、未解決の質問を各項目に含めてください。Pending、メンバー資格、配信状態を分けてください。方針、性能目標、テスト結果を創作しないでください。根拠のない判断は質問として示し、バックログを変更せず、招待も送信しないでください。

中心となる方針に合意がなければ、OpenMaxは不足する業務上の決定権を埋められません。まず責任者と決めてから、OpenMaxの製品情報を確認し、本番ではない一つのストーリーでワークシートを試します。どの候補を残し、変え、却下したかを理由とともに説明できるようになってから、対象を広げます。

限界：この例だけで機能全体の合格を宣言しない

実際のセキュリティやプライバシーは、構成と適用される義務に沿った専門レビューが必要です。架空のテナント・役割規則は、認可設計や法的助言ではありません。本番トークン、顧客のアドレス、機密の要求資料を、未承認のツールに入力しないでください。

性能、復旧、アクセシビリティには、それぞれの証拠が必要です。「速い」には、操作、負荷、環境、パーセンタイルの計算法、標本期間、エラーの扱いを定めます。テンプレートから根拠なく800ミリ秒という値をコピーしません。「復旧可能」には、復旧時点、所要時間、データ整合性の確認が必要で、前のデプロイ版へ戻すだけでは不十分です。一つのフォームが使えても、サイト全体の適合を証明したことにはなりません。

機能そのものがAIモデルを使う場合は、データセットの版、評価基準、レビュー方法、許されない結果、代替動作を定める別の評価仕様を追加します。AIで条件を書くことと、AIシステムの条件を書くことは別の課題です。決定的な招待テストでモデル品質は証明できず、モデルの平均点が高くても権限違反を正当化できません。

ストーリーを閉じる前に、どんな観察結果が出たら、この実装を受け入れないのかを確認します。誰も答えられなければ、AIに文章を増やさせる前に規則か例を直してください。教材では、合格率を魅力的に見せるより、認可とキーボードの欠陥を解消することが先です。

よくある質問

AIが作った受入条件は、そのまま使えますか？

責任を持つチームが根拠の規則、範囲、検証可能性を確認するまでは候補です。文章の承認と、実装されたシステムでの検証は別の段階です。

すべてのストーリーに20例が必要ですか？

必要ありません。関連するリスクを選び、無関係な動作は別ストーリーに分けます。本稿の20例は一つの招待機能の作成、配信、ライフサイクル、利用体験にまたがっています。

Given–When–Thenなら検証可能ですか？

形式だけでは不十分です。開始状態、業務規則、観察結果、具体的な境界が必要です。自動実行には、ステップの実装、環境、実際の結果も必要になります。

テスト合格率80%なら受け入れてよいですか？

割合だけでは判断できません。架空の資料では実行済み十件中八件が合格ですが、二件は失敗し、別の二件は未実行です。認可の失敗は阻止要因であり、全条件を網羅した記録でもありません。

OpenMaxがストーリーを自動承認できますか？

本稿で確認したのは公式の要求草案作成という用途だけです。自動承認、バックログ連携、テスト実行は検証していません。受入判断はチームから権限を与えられた人が行います。

出典と編集方法

OpenMaxコンテンツチーム、2026年9月4日改訂。OpenMax自身が提供する教育目的の製品関連コンテンツであり、独立した製品レビューではありません。招待規則、例、プロンプト、ワークシート、結果記録はこのガイドのために作成しました。顧客事例、ベンチマーク、実機テストではありません。実際のセキュリティ、プライバシー、アクセシビリティ要求は専門担当者のレビューが必要です。

• Cucumber：Gherkinリファレンス — 状況、出来事、観察結果と、実行可能なステップの区別。
• Cucumber：Example Mapping — 規則、例、未解決の質問を分ける方法。
• Agile Alliance：Three Cs — 対話と確認の歴史的な背景。
• Scrum Guide — インクリメント品質の共通の完成の定義。
• OpenMax：AIプロダクトマネージャー — 公開された要求作成プロンプト。掲載されたマーケティング上の効果数値は本稿に使用していません。