基本設計レビューAI
実装に入ってから「この設計、影響範囲を見落としていた」と気づいていませんか。
無料ベータ・面談制／正式版は有料提供予定
- 所要時間: 30分
- 進め方: 現場の状況をヒアリングし、最初に効くツールと順番を一緒に決めます
- ご準備は不要です
概要
設計段階の抜け（異常系を考えていない、インターフェースが曖昧、影響範囲が未分析、テストしづらい構造）は、実装やテストに進んでから手戻りとして跳ね返ります。設計書を実装前に機械的にレビューし、必須観点の充足を保証することで、最も安く直せる段階で欠陥を潰します。
効果
- 影響範囲分析・IF定義・異常系・テスト容易性の記載漏れを決定的に検出する。
- 単一責務違反や高結合の兆候を拾い、実装前にリファクタリングの判断材料を与える。
- 必須観点の充足度を見える化し、設計レビューの抜けを防ぐ。
- 各指摘に「設計に何を書き足すか」までの直し方が付く。
- 決定的層は同じ入力に同じ結果＝設計レビューの品質ゲートに組み込める。
インプット
- 基本設計書
汎用LLMとの違い
設計の構造的完全性を判定する必須観点カタログと検出規則、責務集中・高結合を拾うしきい値が bubo 独自の中核です。汎用LLMと違い、設計の必須観点を取りこぼさず同じ入力に同じ結果を返す再現性を土台に、必要なら意味的レビューを上乗せします。
実際の入力と、返ってきた出力
同じ基本設計書を、汎用AIにそのまま渡した場合と、design-review に渡した場合の実際の出力です（同一モデル・要約なし）。
# 基本設計書: ポイント付与バッチ ## 概要 毎日03:00に前日の確定注文を集計し、注文金額の1%をユーザーにポイント付与する。付与結果をユーザーにメール通知する。 ## 処理フロー 1. 前日(00:00〜23:59)に status=確定 になった注文を orders から抽出する 2. ユーザーごとに注文金額を合計し、その1%（小数点以下切り捨て）をポイント数として算出する 3. points テーブルに付与レコードを insert する 4. users.point_balance に算出ポイントを加算する 5. 付与完了をユーザーにメール通知する ## インターフェース - 入力: なし（cronスケジュール起動） - 出力: 付与件数・合計ポイント数をログに出力する ## 異常系 - DB接続に失敗した場合はバッチを異常終了し、運用にアラートを送る ## 非機能要件 - 想定対象ユーザー数: 10万人／日 - 実行時間帯: 深夜のため多少の遅延は許容
基本設計書を拝見しました。全体として処理の流れが素直に書かれていて分かりやすいと思います。以下、気になった点をいくつかコメントします。 - 処理フローが1〜5まで順を追って書かれていて読みやすいです。概要と処理フローの対応も取れています。 - 3のpoints insertと4のpoint_balance加算は、途中で失敗したときにどちらか片方だけ反映されてしまう可能性があるので、トランザクションでまとめておくと安心だと思います。 - 5のメール通知について、送信に失敗した場合どうするか（リトライするか、ログだけ残すか）が書かれていないので、一言あるとよさそうです。 - 異常系がDB接続失敗のケースだけになっているので、対象注文が0件だった場合の扱いも触れておくと親切かなと思いました。 - 非機能要件で10万人／日という規模感が書かれているのは良いですが、その件数を一括処理するのか分割するのかがあると、実装時に判断しやすいかもしれません。 大きな問題はなく、上記を補足すればより分かりやすい設計書になると思います。
■ 汎用AIの回答には出てこなかった高リスク観点 [重大] バッチ再実行・リトライ時に同一対象日の付与が重複し、ポイントが二重加算される恐れ。処理単位に一意制約や実行済み判定が無い。 [重大] read-modify-write方式の加算で、バッチと注文処理など他経路が同時にpoint_balanceを更新するとロストアップデートが発生し残高が不整合になる。 [重大] 日付境界とcron 03:00が単一TZ前提。海外ユーザーやサーバTZ変更で集計対象日がずれ、付与漏れ・二重付与を招く恐れ。 [重大] 監査/ログに『何を記録するか』が件数・合計のみで、対象ユーザー・付与額・対象日・失敗理由など記録内容の定義が未定義。付与の追跡・監査ができない。 [重大] 通貨の最小単位差（円は0桁、ドルは2桁等）が未考慮。多通貨だと1%計算・切り捨ての基準が曖昧で金額誤りに。 [重大] 通知文言の多言語対応・ユーザー言語ロケールの考慮が無く、単一言語固定になる懸念。 [重大] 影響範囲分析（依存・回帰対象）が設計に記載されていない。 [中] 付与後に注文がキャンセル/返品/確定取消された場合のポイント払い戻し・減算の状態と経路が未定義。不正残高が残る。 [中] 加算後残高の範囲・上限・オーバーフロー時の扱いが未定義で、境界での挙動が曖昧。 [中] 注文金額に負値・返品・キャンセルが混入した場合の検証が無く、不正・過大なポイント付与に繋がりうる。切り捨て後の負値も未考慮。 [中] ログやメール本文にユーザーID・メールアドレス・残高等の機微情報が混入すると露出リスク。ログの保護範囲が未定義。 [中] テスト容易性（観測・制御・注入できる設計）への配慮が見当たらない。 ■ 素朴な依頼でも触れられた観点（design-review も指摘） [重大] points insert後にpoint_balance加算やメールが失敗した場合の巻き戻し/補償経路が未定義。残高と付与履歴が不整合になる。 [重大] メール送信失敗時の扱いが未定義。DBコミット後の送信失敗で通知欠落、送信後のロールバックで残高と不一致。外部mail障害でバッチ全体が停止する恐れ。 [中] 件数上限・分割の記載がなく、注文/ユーザー急増時に一括処理でメモリ・DB負荷が枯渇しバッチ停止を招く。
同じAIでも、設計レビューの観点と手法を内蔵しているかで見えるものが変わります。上の高リスク観点は、観点を持たない素の依頼では出てきませんでした。design-review は二重付与・タイムゾーン・監査・国際化などの高リスク観点を毎回体系的に洗い出します。
社外秘のコードを、どう守るか
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）として任意で設定いただけます。