要件フォーマット整形
箇条書きと散文が混ざった要件を、診断にかけられる形に直す手間。
無料ベータ・面談制／正式版は有料提供予定
概要
現実の要件定義は自由記述が大半で、そのままでは「測れるか・抜けが無いか」を機械的に点検できません。曖昧なまま下流へ流すのではなく、入口で要件を検証可能な構造へ整えることで、はじめから良い要件として設計・テストに渡せるようにします。
効果
- 自由記述の要件を厳密にレビュー可能な形へ整える（点検不能の解消）。
- 要求の単位化・理由/成功基準の明示で、曖昧要件による手戻りを上流で防ぐ。
- 変換できなかった文（要確認）を明示し、要件の穴を可視化する。
インプット
- 要件定義テキスト
汎用LLMとの違い
要求の単位化・理由の明示・仕様への分解ルールといったUSDMの形式知が bubo 独自の中核です。汎用LLMに「整えて」と頼むより、検証可能性を意図した構造へ一貫して変換し、変換できなかった箇所を取りこぼさず明示します。
実際の入力と、返ってきた出力
同じ自由記述の要件を、汎用AIと usdm-normalize にそのまま渡した、実際のやりとりです（要約ではありません）。
パスワード変更の機能がほしい。ユーザーが自分でパスワードを変えられるようにする。新しいパスワードは8文字以上にする。変更が終わったら本人に確認メールを送る。あと管理者はユーザー一覧をCSVで出せるようにしたい。ログイン画面は不正ログインを防ぎたいのでreCAPTCHAを入れる。画面全体はできるだけ使いやすくする。データは安全に保管すること。
以下、USDM形式で整理します。 ## 要求 REQ-01: ユーザーは自分でパスワードを変更できるようにしたい | 項目 | 内容 | |---|---| | 理由 | セキュリティ確保・パスワード漏洩時等に利用者自身で対処できるようにするため | ### 仕様 - SPEC-01-1 | 説明 | ログイン中のユーザーが「パスワード変更」画面から新しいパスワードを設定できる - SPEC-01-2 | 制約 | 新しいパスワードは8文字以上とする - SPEC-01-3 | 制約(要確認) | 本人確認のため、変更時は現在のパスワードの入力を求めるか要検討 - SPEC-01-4 | 動作 | 変更完了時、登録済みメールアドレス宛に完了通知メールを送信する - SPEC-01-5 | 例外 | 8文字未満の場合はエラーを表示し変更を拒否する ## 要求 REQ-02: 管理者はユーザー一覧をCSVで出力できるようにしたい | 項目 | 内容 | |---|---| | 理由 | ユーザー管理業務（分析・監査・外部システム連携等）を効率化するため | ### 仕様 - SPEC-02-1 | 説明 | 管理者権限を持つユーザーは管理画面からユーザー一覧をCSVでダウンロードできる - SPEC-02-2 | 制約(要確認) | CSVに含める項目（氏名・メール・登録日・最終ログイン日時等）は未指定のため要確定 - SPEC-02-3 | 制約 | 管理者以外はこの機能にアクセスできない（権限制御） - SPEC-02-4 | 制約(要確認) | 出力件数が多い場合の処理方式（非同期生成等）は未指定のため要確定 ## 要求 REQ-03: ログイン画面での不正ログインを防止したい | 項目 | 内容 | |---|---| | 理由 | 総当たり攻撃・ボットによる不正ログインを防ぐため | ### 仕様 - SPEC-03-1 | 説明 | ログイン画面にreCAPTCHAを組み込み、送信前に人間の操作であることを検証する - SPEC-03-2 | 動作 | reCAPTCHA認証に失敗した場合、ログイン処理を実行せずエラーを表示する - SPEC-03-3 | 制約(要確認) | reCAPTCHAのバージョン（v2チェックボックス／v3スコア型）は未指定のため要確定 ## 要求 REQ-04: 画面全体を使いやすくしたい | 項目 | 内容 | |---|---| | 理由 | ユーザーの利便性・操作性を向上させるため | ### 仕様 - SPEC-04-1 | 説明(要確認) | 「使いやすさ」の受け入れ基準が未定義。改善観点（レスポンシブ対応・入力補助・エラー表示のわかりやすさ等）の明確化が必要 ## 要求 REQ-05: データを安全に保管したい | 項目 | 内容 | |---|---| | 理由 | 個人情報・認証情報の漏洩防止のため | ### 仕様 - SPEC-05-1 | 説明 | パスワードは平文で保存せず、ハッシュ化（bcrypt等のソルト付きハッシュ）して保管する - SPEC-05-2 | 制約(要確認) | 通信の暗号化（HTTPS必須化）、保存データの暗号化範囲は未指定のため要確定 - SPEC-05-3 | 制約(要確認) | 「安全」の基準（準拠すべきセキュリティ基準・ログ保存方針等）が未定義。要具体化
# USDM化の結果（変換5件 / 既存0件 / 要確認2件・confidence 0.71） ## REQ-1 ユーザーによるパスワード変更機能の提供 - 理由: ユーザーが自分でパスワードを変更できるようにするため - 成功基準: ログイン済みのユーザーが、新旧パスワードを入力してパスワードを更新できること - SPEC-1-1: 現在のパスワード確認機能 - SPEC-1-2: 新しいパスワードの入力フィールド - SPEC-1-3: 新しいパスワードの確認用入力フィールド ## REQ-2 パスワード文字数制限の適用 - 理由: パスワードの最低文字数を規定するため - 成功基準: 8文字未満のパスワード設定時にエラーメッセージが表示されること - SPEC-2-1: パスワード長を8文字以上に制限するバリデーションの実装 ## REQ-3 パスワード変更完了通知メールの送信 - 理由: パスワード変更が行われたことを本人に通知するため - 成功基準: パスワード変更処理完了後、登録済みメールアドレス宛に通知メールが送信されること - SPEC-3-1: SMTPメール送信機能 - SPEC-3-2: メール送信テンプレート ## REQ-4 管理者によるユーザー一覧CSV出力機能の提供 - 理由: 管理者がユーザー情報を管理できるようにするため - 成功基準: 管理者が操作画面からユーザー一覧をCSV形式のファイルとしてダウンロードできること - SPEC-4-1: 管理者権限チェック機能 - SPEC-4-2: ユーザーデータのCSV変換・ダウンロード処理 ## REQ-5 ログイン画面へのreCAPTCHA導入 - 理由: 不正ログインを防止するため - 成功基準: ログイン画面にreCAPTCHAの認証ブロックが表示され、認証が成功しない限りログインできないこと - SPEC-5-1: Google reCAPTCHA APIの統合 ── 未変換（要確認）── - 「画面全体はできるだけ使いやすくする」→ 要求の可能性があるが変換しなかった（要確認） - 「データは安全に保管すること」→ 要求の可能性があるが変換しなかった（要確認）
同じ入力を渡した実際のやりとりです。汎用AIも十分に整形しますが、勝手に前提を足す・毎回ぶれる点に注意。
汎用LLMだけに任せず、usdm-normalize を使う理由
汎用AIも要件を整形できます。差は品質ではなく、毎回同じ結果を・勝手に足さず・そのまま後工程へ渡せることです。
汎用LLMだけに任せると
毎回ぶれて、再現しない
同じ入力でもフォーマットも中身も変わり、監査や再レビューの基準にできない。
原文に無い前提を創作する
未指定の仕様（暗号化方式・本人確認・reCAPTCHAのバージョン等）を勝手に確定してしまう。
後工程にそのまま渡せない
出力が自由形式で、厳密診断や機械処理へ直接つなげられない。
usdm-normalize なら
決定的で、再現する
同じ入力なら毎回同じUSDM構造。監査・再レビューの基準にできる。
創作せず、『要確認』で返す
変換できない曖昧な要件は勝手に仕様化せず、『要確認（未変換）』として正直に示す。
機械可読で、そのまま次工程へ
confidence・変換内訳・未変換リストつき。spec-validation の厳密診断へそのまま渡せる。
社外秘のコードを、どう守るか
buboは入力を保存しません
ツールに渡したコード・仕様・データを、buboのサーバーは保存しません。bubo自身が学習に使うこともなく、処理はその場限りです。
AIに送るか・どこへ送るかは、あなたが握ります
LLMはお手元の鍵で、あなたが選んだプロバイダを呼びます。学習に使うかどうかといったデータの規約も、あなたとプロバイダの契約のもとにあります。なお、LLMキーを使うツールは現時点でClaude・Geminiに対応しており、他プロバイダは順次対応予定です。
AIに送らず動くツールも多くあります
多くのツールは決定的な静的解析だけで完結し、LLMに渡すのは必要な場面に限られます。AIに送る範囲を、あなた自身で絞り込めます。
どう申し込み、どうつなぐのか
1. 面談を予約する
予約フォームから面談をお申し込みください。現在のQAの困りごとと、試したいツールをお聞かせいただきます。
2. 面談で適用先を一緒に決める
そろえたツールのうち、貴社の工程で効く順番をご一緒に見立てます。設定方法・つなぎ方は、この面談でお渡しします。
3. お手元のLLMで動かす
お手元のLLMの鍵（ご自身の鍵をそのまま使うこの方式を、BYOKと呼びます）を設定し、buboのMCPサーバーへ接続。普段お使いのAIクライアントから、そのままQA方法論を呼び出せます。