受入条件の妥当性レビュー
受入条件はそろっているのに、対象ユーザーは目的まで到達できていませんか。
無料ベータ・面談制／正式版は有料提供予定
前提：personas/scenes/surfaceは必須。criteria（任意）はspec-verificationが分解した受入条件を渡す想定
- 所要時間: 30分
- 進め方: 現場の状況をヒアリングし、最初に効くツールと順番を一緒に決めます
- ご準備は不要です
※ 要件レビューAI（2026年7月まで spec-validation の名称でした）をお探しの方は spec-verification
概要
要求本文に出てくる抽象的な品質語（「手間なく」「安全に」「分かりやすく」など）を対象ペルソナごとに「どの場面で・何を負と感じ・どの状態なら満たされるか」へ本質再構成し、分解済みの受入条件がその本質を満たしているかを裁定します。受入条件は全部そろっているのに対象ユーザーが目的まで到達できない、という状態のまま実装・リリースへ進むのを、作る前・出す前の段階で止めます。
効果
- 要求本文の抽象品質語をペルソナ別に本質（場面・感じる負・期待水準）へ展開し、受入条件がその水準に届いているかを1件ずつ裁定できる。
- 欠陥を被覆漏れ（coverage_gap）／水準ズレ（fidelity_gap）／未立要求（missing_quality）の3種に分けて返すため、「基準が無い」のか「基準はあるが弱い」のかを取り違えずに直せる。
- ペルソナが目的の終端まで到達できるかを判定し、到達を塞いでいるペルソナ×シーンを機械可読で名指しする（goal_unreachable / goal_blocking）。
- 決定的層は鍵不要・同入力同出力で、その範囲だけを品質ゲートに組み込める。LLM層由来の指摘はprovenance: ai-suggestedとして区別される。
- 各指摘にfinding_idが付き、採否をreport_outcomeで記録できるため、指摘の当たり外れを後から測れる。
インプット
- 対象ペルソナ（personas・必須）
- 利用シーン（scenes・必須）
- 利用者接点（surface・必須）
- 要求本文（artifact・任意）
- 受入条件（criteria・任意）
- 目的（goal・任意）
汎用LLMとの違い
素のLLMに「この受入条件で使えそう？」と聞くと見る観点も粒度もそのつど変わりますが、本ツールは決定的層が普遍的な負のタクソノミを規則で照合するため、その範囲は同じ入力なら常に同じ指摘を返しCIのゲートに置けます。素のLLMの回答は「抜けている」「弱い」が文章の中で混ざりますが、本ツールはcoverage_gap（基準が無い）とfidelity_gap（基準はあるが期待水準に届かない）を別の欠陥種別として分離し、それぞれに対応基準（criterion_ref）を紐づけて返します。また、目的の終端まで到達できるかを判定し、到達を塞いでいるペルソナ×シーンを機械可読のgoal_blockingとして返すため、そのまま承認を止める判断に使えます。
実際の入力と、返ってきた出力
この原稿のために作成した架空の要件一式（実在の顧客案件ではありません）を spec-validation にそのまま渡した、実際のやりとりです（要約ではありません）。
目的 利用者が自分で返金を申請し、返金の完了を確認できるところまで到達できる 対象ペルソナと利用シーン 対象ペルソナ（一般の購入者・サポート担当・法人経理の3者）と、申請入口から完了確認までの利用シーンを併せて渡します。 要求本文 購入者が手間なく安全に返金を申請でき、いまどうなっているかが分かりやすく確認できる仕組みにする。 サポートに問い合わせなくても自分で完結できることを要求する。 受入条件（spec-verificationが分解したもの） AC-1: apply_refund が実装され、完了済みセッションへの返金を適用できること AC-2: send_refund_notification が呼び出され、返金完了がメールで通知されること AC-3: get_refund_status のレスポンスにrefund_statusフィールドが含まれていること AC-4: 返金申請APIが不正なorder_idに対して400を返すこと
到達可否ゲート判定: goal_unreachable（目的の終端まで到達できない）／抽出された抽象品質語: 手間なく・安全に・分かりやすく・自分で完結
| ペルソナ | 到達を塞いでいるシーン | 理由 |
|---|---|---|
| P_user | 本人確認 | high_barrier |
| P_support | 本人確認 | high_barrier |
| P_admin | 本人確認 | high_barrier |
## 決定的層のみ（鍵不要・同入力同出力）
summary : 3ペルソナ・2件の妥当性の欠陥（被覆漏れ×2）
gate_verdict : goal_unreachable
goal_reachable: False
findings (2):
- [high][open] coverage_gap / kind=dropoff / scene=本人確認 / criterion_ref=none (deterministic)
「手間なく」の本質（運用で要る操作（取消・更新・確認）の導線が見つからず立ち往生する不安）に
対応する基準がcriteriaに見当たらず、このペルソナの期待水準（逆操作・確認の導線を接点から
辿れる）を保証できない
- [high][open] coverage_gap / kind=dropoff / scene=進捗確認 / criterion_ref=none (deterministic)
（同上の本質・期待水準について、進捗確認シーンで基準が見当たらない）
## LLM層あり（本質再構成を上乗せ）
summary : 3ペルソナ・21件の妥当性の欠陥（被覆漏れ×10、水準ズレ×6、未立要求×5）
gate_verdict: goal_unreachable
by_persona : P_user {14件・最悪 high} / P_support {2件・最悪 medium} / P_admin {3件・最悪 medium}
指摘の実物（代表4件・文言の改変なし）:
[high][coverage_gap] 品質語=安全に / persona=P_user / scene=本人確認 / criterion_ref=none
感じる負 : 他人が自分の注文に返金申請できてしまうのではという不安／逆に確認が複雑だと通過できない
期待水準 : 注文の本人のみが申請でき、ITに不慣れでも保有物（注文確認メール等）で無理なく
本人確認を通過できる
問題 : AC-4はorder_idの形式不正しか見ておらず、申請者が注文の本人であることの
認証・認可を検証する基準が無い
直し方 : 他人のorder_idでの申請が拒否されること、および本人確認手段がスマホのみで
完了することを受入条件に追加する
[high][fidelity_gap] 品質語=分かりやすく / persona=P_user / scene=進捗確認 / criterion_ref=AC-3
感じる負 : APIのレスポンスフィールドや"applied"という英語値では、ITに不慣れなスマホ利用者は
今どうなっているか読み取れない
期待水準 : マイページの注文詳細に日本語の平易な文言で進捗が自動表示される状態（やっておいて水準）
問題 : AC-3はrefund_statusフィールドの存在というAPI水準に留まり、画面上での表示・文言の
わかりやすさまで解消していない。取りに行けば分かる（指示があれば）水準で止まっている
直し方 : 「マイページ上で返金の進捗が日本語の状態表示（申請受付済み/処理中/返金完了等）として
確認できる」ことを受入条件に追加・格上げする
[medium][fidelity_gap] 品質語=自分で完結 / persona=P_user / scene=返金申請 / criterion_ref=AC-4
感じる負 : order_idや金額を自分で正しく入力する必要があり、間違えると400エラーで
突き放されて先に進めない
期待水準 : 注文詳細画面のボタンから注文情報・金額が自動で引き継がれ、入力ミスが起きえない状態
問題 : AC-4は誤入力を400で弾く（利用者が正しく指示すれば通る）水準に留まり、リテラシー低の
利用者がエラー時に自力復帰できず、結局サポート問い合わせに戻るおそれ
直し方 : 「注文詳細画面からの申請ではorder_id・金額が自動設定され、利用者の手入力を要しない」
ことを受入条件化し、400は防御線として残す
[medium][coverage_gap] 品質語=安全に / persona=P_admin / scene=完了確認 / criterion_ref=none
感じる負 : 申請と返金の証跡（日時・金額・理由・完了記録）が残らず、社内統制・監査要件を
満たせない
期待水準 : 申請受理と返金完了の記録を、後から証跡として取得・保存できる
問題 : criteriaに申請・返金の履歴保全や証跡出力に関する基準が無く、統制下で証跡を残す
必要がある法人経理の本質を満たせない
直し方 : 返金申請と完了の履歴（日時・金額・理由）が記録され参照できることを受入条件に追加する
各指摘にはprovenance（deterministic / ai-suggested）とfinding_idが付きます。上の4件はいずれもai-suggested、決定的層の2件はdeterministicです。
入力に使った返金申請の要件一式は、この原稿のために作成した架空例です（実在の顧客案件ではありません）。
受入条件は4件そろって見えますが、本ツールの判定はgoal_unreachableです。到達を塞いでいるペルソナ×シーンが機械可読で名指しされ、指摘は「基準が無い（coverage_gap）」と「基準はあるが水準に届かない（fidelity_gap）」に分離されます。
社外秘のコードを、どう守るか
buboは入力を保存しません
ツールに渡したコード・仕様・データを、buboのサーバーは保存しません。bubo自身が学習に使うこともなく、処理はその場限りです。
AIに送るか・どこへ送るかは、あなたが握ります
標準のキーレス接続では、意味を読む処理は普段お使いのAIクライアントの中で実行されます。データの扱いは、お客様とそのプロバイダの既存のご契約のもとにあり、buboがAPIキーやコードをお預かりすることはありません。ご自身の契約するプロバイダを直接指定したい場合は、BYOK（Bring Your Own Key）として任意で設定できます。
AIに送らず動くツールも多くあります
多くのツールは決定的な静的解析だけで完結し、LLMに渡すのは必要な場面に限られます。AIに送る範囲を、あなた自身で絞り込めます。
ワンタイムコードは単回使用・有効期限7日・サーバーに平文保存はしません。発行したトークンは設定ファイルに直書きせず環境変数で参照します。既存のMCP設定がある場合も、壊さず冪等にマージします。
どう申し込み、どうつなぐのか
1. 面談を予約する
予約フォームから面談をお申し込みください。現在のQAの困りごとと、試したいツールをお聞かせいただきます。
2. 面談で適用先を一緒に決める
そろえたツールのうち、貴社の工程で効く順番をご一緒に見立てます。ワンタイムコードと接続コマンドは、面談後にあわせてお渡しします。
3. コード1つ、コマンド1行で接続
お受け取りしたワンタイムコードで、コマンドを1行実行（Windows / mac / Linux 各1行）。有効化・MCP設定（.mcp.json）生成・環境変数設定まで自動で完了します。あとはAIクライアント（Claude Code / Gemini CLI）を再起動するだけで、そのままQA方法論を呼び出せます。APIキーのご用意は不要です。ご自身の契約するLLMを使いたい場合は、BYOK（Bring Your Own Key）として任意で設定いただけます。