要件レビューAI
その要件定義書、つくる前から穴が空いていませんか。
無料ベータ・面談制／正式版は有料提供予定
概要
要件レビューは観点が抜けやすく、指摘を並べても「結局どの価値が足りないのか」が俯瞰しにくいのが難点です。本ツールは決定的な点検と観点ドリブンの価値レビューに、価値4要素（誰の/なぜ/何を/どこまで）を1枚の表で見渡す地図を足し、作成者が自分で「どこが弱いか」に気づけるようにします。採点はせず、最も危険なセル（価値の核が弱く根拠も無い箇所）を示します。
効果
- 測定可能性・展開漏れ・理由欠落などを決定的に必ず拾い、レビューの抜けをなくす。
- 価値4要素（誰の/なぜ/何を/どこまで）の充足を1枚の表で俯瞰でき、どの価値が抜けているか作成者が自分で気づける。
- 価値の要があやしいのに根拠も示されていない、最優先で見直すべき箇所をはっきり指し示す。
- 抽出役と批評役を別モデルに分けることで、自分の抽出を自分で甘く見るバイアスを抑える。
- 修正前後を diff で機械突合し、指摘が本当に消えたかをクローズドループで確認できる。
インプット
- 要件定義書（USDM）
- 修正前後の要件定義書
- 要件定義書＋元インプット
- プロファイル指定（任意）
汎用LLMとの違い
USDMの形式知、価値レビューの観点カタログと判定手順、価値4要素マトリクスの構成、抽出役と批評役を分ける設計が bubo 独自の中核です。汎用LLMに「レビューして」と頼むのと違い、測れるか・抜けが無いかを決定的に必ず点検し、価値を観点ドリブンに診たうえで、どの価値が足りないかを1枚の表で俯瞰させます。
実際の入力と、返ってきた出力
同じ要件を、汎用AIと spec-validation にそのまま渡した、実際のやりとりです（要約ではありません）。要件には、測れないもの・手段が先行したものが混じっています。
## REQ-01 システムは高速に応答すること ## REQ-02 管理者はユーザー情報をCSV形式でエクスポートできる ## REQ-03 ログイン画面にreCAPTCHAを導入する ## REQ-04 画面はわかりやすく、使いやすいこと ## REQ-05 データはできるだけ安全に保管すること
REQ-01「システムは高速に応答すること」— 「高速」の定義がないため合否判定ができません。「主要画面は3秒以内に表示」のように、具体的な数値目標と測定条件(負荷条件・ネットワーク環境等)を明記すべきです。 REQ-02「管理者はユーザー情報をCSV形式でエクスポートできる」— これは要件として比較的具体的ですが、詳細が不足しています。エクスポート対象の項目(全項目か一部か)、文字コード(Shift_JISかUTF-8か)、対象データの範囲(全件か検索結果か)、権限確認の方法などを補足すると実装・テストしやすくなります。 REQ-03「ログイン画面にreCAPTCHAを導入する」— これは要件というより実現手段(How)を直接指定しています。本来の要件は「不正ログイン・ボット攻撃を防止する」であり、reCAPTCHAはその一手段のはずです。手段を先に固定すると他の選択肢(レートリミット、多要素認証など)を検討する余地がなくなるので、目的と手段を分けて書くことをおすすめします。 REQ-04「画面はわかりやすく、使いやすいこと」— REQ-01と同様、「わかりやすい」「使いやすい」が主観的で検証不能です。誰にとって(新規ユーザーか熟練ユーザーか)、どういう基準で判定するか(タスク完了率、初回操作の迷いの少なさ、UIガイドライン準拠など)を明確にする必要があります。 REQ-05「データはできるだけ安全に保管すること」— 「できるだけ」という表現が曖昧で、対策の範囲に上限がありません。対象データの機密度に応じて、暗号化方式(保管時・通信時)、アクセス制御、バックアップ方針など、どこまで対応するかの基準を具体化すべきです。 全体として、REQ-01・04・05は非機能要件が定性的な表現にとどまっており検証可能性が低く、REQ-02は詳細度が不足、REQ-03は目的と手段が混同されています。優先度としては、まず「何を達成したいか(目的)」を明文化し、その上で数値基準や実装手段を整理し直すと、後工程のテスト設計や実装判断がぶれにくくなります。
# 修正リスト - [要確認] 上位価値 @ 文書全体 - 問題: 要求全体が実現しようとする具体的な業務目標や最終アウトカムが定義されていないため、要件の妥当性が判断できません。 - 直し方: システム導入によって達成したい具体的な事業目的や、解決すべき課題を最上位のゴールとして定義してください。 - [要確認] 対象者 @ REQ-01 - 問題: REQ-01「システムは高速に応答すること」: 価値の受け手が明記されていないため、誰にとっての高速応答か不明。 - 直し方: 「利用者が快適に操作できるよう、システムは応答速度を○秒以内とする」のように対象を明記する。 - 展開漏れ @ REQ-01 - 問題: REQ-01 に対応する仕様(SPEC)がありません - 直し方: REQ-01 を実現する仕様を SPEC-01-1 形式で追加してください - 成功基準欠落 @ REQ-01 - 問題: REQ-01 に成功基準がありません - 記入例: 検索ボタン押下後、2秒以内に結果画面を表示する。 - 理由欠落 @ REQ-01 - 問題: REQ-01 に理由(reason)がありません - 記入例: 検索待ち時間を短縮し、ユーザーの操作ストレスを軽減するため。 - [要確認] to-be価値 @ REQ-02 - 問題: REQ-02: エクスポートという手段に焦点が当たり、目的である業務上のメリットやあるべき状態が未定義。 - [要確認] 漏れ:広さ @ REQ-02 - 問題: REQ-02: ユーザーデータの取り扱いやログイン履歴に関する監査証跡の要件が定義されていない。 - 展開漏れ / 成功基準欠落 / 理由欠落 @ REQ-02 - 問題: 仕様(SPEC)・成功基準・理由が未記載。 - [要確認] to-be価値 @ REQ-03 - 問題: REQ-03「reCAPTCHAを導入する」: reCAPTCHA導入という手段が目的化しており、セキュリティ上の期待状態が不明確。 - 直し方: 「ボットによる不正アクセスが確実に排除され、ログインの安全性が確保されている」ことを目的として記述する。 - [要確認] 対象者 @ REQ-03 - 問題: 導入の目的や、誰の利便性・保護のための措置かが不明。 - [要確認] 漏れ:状態 @ REQ-03 - 問題: reCAPTCHAの認証失敗時のエラー処理・通知要件が欠如。 - 展開漏れ / 成功基準欠落 / 理由欠落 @ REQ-03 - 問題: 仕様(SPEC)・成功基準・理由が未記載。 - [要確認] 対象者 @ REQ-04 - 問題: REQ-04「わかりやすく、使いやすいこと」: 誰にとってわかりやすいかが不明。 - 直し方: 「一般ユーザーがマニュアルなしで操作できるよう、画面のUIを改善する」のように対象を限定する。 - 展開漏れ / 成功基準欠落 / 理由欠落 @ REQ-04 - 問題: 仕様(SPEC)・成功基準・理由が未記載。 - 記入例: 主要なメニューへの遷移を3クリック以内で行えること。 - [要確認] 対象者 @ REQ-05 - 問題: REQ-05「できるだけ安全に保管すること」: 誰のどのような利益のために安全保管するのか対象が不明。 - 展開漏れ / 成功基準欠落 / 理由欠落 @ REQ-05 - 問題: 仕様(SPEC)・成功基準・理由が未記載。 - 記入例: 全ての個人情報はAES-256で暗号化し、3年間の保存期間を設定する。
汎用LLMだけに任せるときのリスク
- 再現しない：同じ入力でも結果が毎回変わり、監査や再チェックの基準にできない。
- 網羅の保証がない：見落としても「見落とした」ことに気づけない。確認する項目が増えるほど崩れやすい。
- もっともらしい誤り：実在しない問題や誤った基準を、自信ありげに混ぜることがある（ハルシネーション）。
- 自動で止められない：出力は文章のため、CIの品質ゲートとして機械的にブロックできない。
汎用AIも的確な指摘を返します。違いは品質の高低ではなく、spec-validation は全要件×観点を漏れなく機械的に点検し（網羅を保証・同じ入力なら毎回同じ）、USDM方法論（対象者／手段の目的化／価値の深さ・広さ・状態）に沿って構造化・記入例つきで返す点です。上のリスクは、この決定的な網羅と合否での出力で抑えられます。
社外秘のコードを、どう守るか
buboは入力を保存しません
ツールに渡したコード・仕様・データを、buboのサーバーは保存しません。bubo自身が学習に使うこともなく、処理はその場限りです。
AIに送るか・どこへ送るかは、あなたが握ります
LLMはお手元の鍵で、あなたが選んだプロバイダを呼びます。学習に使うかどうかといったデータの規約も、あなたとプロバイダの契約のもとにあります。なお、LLMキーを使うツールは現時点でClaude・Geminiに対応しており、他プロバイダは順次対応予定です。
AIに送らず動くツールも多くあります
多くのツールは決定的な静的解析だけで完結し、LLMに渡すのは必要な場面に限られます。AIに送る範囲を、あなた自身で絞り込めます。
どう申し込み、どうつなぐのか
1. 面談を予約する
予約フォームから面談をお申し込みください。現在のQAの困りごとと、試したいツールをお聞かせいただきます。
2. 面談で適用先を一緒に決める
そろえたツールのうち、貴社の工程で効く順番をご一緒に見立てます。設定方法・つなぎ方は、この面談でお渡しします。
3. お手元のLLMで動かす
お手元のLLMの鍵（ご自身の鍵をそのまま使うこの方式を、BYOKと呼びます）を設定し、buboのMCPサーバーへ接続。普段お使いのAIクライアントから、そのままQA方法論を呼び出せます。