不具合分析AI
出た不具合を、その場の修正で終わらせていませんか。
無料ベータ・面談制／正式版は有料提供予定
- 所要時間: 30分
- 進め方: 現場の状況をヒアリングし、最初に効くツールと順番を一緒に決めます
- ご準備は不要です
概要
不具合は直して終わりにすると同じ原因で再発します。一件ずつの対症療法ではなく、出た不具合を上流（要件・設計・実装・テスト）のどこで作り込んだかへ還元し、共通の根本原因と打ち手を見える化することで、不具合を「上流改善のための情報」に変えます。
効果
- 不具合を種別・作り込み工程・重大度へ分類し、件数分布で弱点工程を見える化する。
- 複数件に通底する根本原因をテーマ化し、対症療法から構造的改善へつなぐ。
- 次は作り込まないための再発防止策と、テストを足すべき工程・観点を具体的に示す。
- 件数集計・分類は決定的で、繰り返しても同じ結果が得られる（傾向の継続観測に使える）。
インプット
- 不具合報告
- 補足文脈（任意）
汎用LLMとの違い
不具合を種別・作り込み工程・原因類型へ仕分ける分類カタログと、複数件を構造的な根本原因へ抽象化する分析観点が bubo 独自の中核です。汎用LLMに丸投げするより、決定的な分類・分布で土台を保証しつつ、再発防止とテスト追加先まで一貫して還元します。
実際の入力と、返ってきた出力
同じ障害報告一覧と問いかけを、汎用AIと defect-analyzer にそのまま渡した実際のやりとりです（要約ではありません）。
# checkout-service 障害報告一覧 - checkout-serviceの商品検索のレスポンスが遅く、注文一覧の表示に10秒以上かかることがある。 - 外部の配送業者との連携でタイムアウトが頻発し、注文確定処理が止まる。 - 決済情報の一部が消失し、注文データの金額が不整合になった重大インシデント。
# checkout-service 障害報告の分析 ## 1. 商品検索レスポンス遅延(注文一覧表示に10秒以上) **根本原因(推定)** - 商品検索クエリに対する適切なインデックスが存在しない、またはN+1クエリが発生している可能性 - 注文一覧表示時に商品情報を都度同期的に外部/DB問い合わせしており、キャッシュが効いていない - データ量増加に伴うクエリプランの劣化(統計情報の陳腐化) **再発防止策** - 遅延クエリのログ・スロークエリログを常時監視し、閾値超過をアラート化 - 検索結果のキャッシュ層(Redis等)導入、TTL設計 - インデックス設計のレビューをリリースプロセスに組み込む - N+1が疑われる箇所はAPMツール(New Relic, Datadog等)でクエリ発行回数を可視化 **テスト観点** - 大量データ(本番相当件数)を投入した負荷テスト・パフォーマンステスト - レスポンスタイムのSLA(例:1秒以内)を定めたパフォーマンス回帰テスト - キャッシュヒット率・キャッシュ無効化ロジックの単体テスト - 商品件数・注文件数のスケール変化に対するクエリ実行計画の検証 --- ## 2. 外部配送業者連携のタイムアウトによる注文確定処理の停止 **根本原因(推定)** - 外部APIの応答遅延・障害に対してタイムアウト設定や同期呼び出しのままの実装になっている - リトライ・サーキットブレーカーなどの耐障害設計が組み込まれていない - 外部連携の失敗が注文確定処理全体をブロックする同期的な設計 （以下、3件目「決済情報の消失」および「全体を通じた共通の再発防止策」が続く）
## 分類（種別・工程別の件数分布） - 種別: 性能(1件)、連携(1件)、データ(1件) - 工程: 実装(3件) ## 根本原因テーマ - 外部システム連携における耐障害設計(タイムアウト・リトライ)の欠如: 商品検索のレスポンス遅延や配送業者連携のタイムアウトが処理全体をブロックしており、外部呼び出しに対する時間上限設定や失敗時の代替処理が組み込まれていない。 - 決済・金額データの整合性検証機構の欠如: 決済情報の一部消失により注文金額が不整合になっており、更新処理の原子性(トランザクション)や事後検証が行われていない。 ## 再発防止策 - 外部連携(配送業者API・検索処理)にタイムアウト値とリトライ/サーキットブレーカーを要求仕様として明文化する - 決済・金額更新処理をトランザクション化し、処理後に金額整合性を自動チェックする仕組みを導入する - 注文一覧・商品検索のレスポンスタイム上限を受け入れ基準として明記する - 障害注入(遅延・タイムアウト・部分失敗)テストをリリース前チェックリストに追加する ## テスト追加箇所 - 配送業者APIとの結合テストにタイムアウト・接続失敗シナリオを追加 - 決済処理の結合テストに金額不整合検知のアサーションを追加 - 商品検索・注文一覧表示のパフォーマンス(負荷)テストを追加 - 注文確定フローのE2Eテストに外部連携失敗時の異常系を追加 （機械可読な集計もあわせて返ります: n_defects: 3, n_themes: 2）
汎用AIは3件の報告を1件ずつ独立に掘り下げ、報告文には無いミドルウェア名や実装パターン（キャッシュ層、Sagaパターン、分散トレーシング等）まで推定で広げていきます。本ツールは同じ入力を、まず種別（性能／連携／データ）と工程で件数分布に落としたうえで、別々に見える3件を2つの根本原因テーマに束ね直します。「検索の遅延」と「配送業者連携のタイムアウト」が同じ〈外部呼び出しの耐障害設計の欠如〉に帰着する、という横断の見立ては汎用AIの出力には現れません。件数分布・テーマ・再発防止策・テスト追加箇所という枠が毎回同じなので、複数回の障害分析を並べて傾向を追うことができます。
社外秘のコードを、どう守るか
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）として任意で設定いただけます。