AIがバグを自動で修正する時代へ ── Bugoon MCP で変わるBefore/After

QAからのバグ報告に、なぜ30分もかかるのか

「ログインボタンが押せない」──そんなSlackメッセージから始まる朝は、開発者なら誰でも経験があるはずです。QAエンジニアが報告を上げ、開発者がその内容を解読し、環境を再現し、原因を特定して修正する。このサイクルに、熟練者でも平均30分以上かかります。Bugoon MCPは、このループを根本から変えます。

Before：MCP なしのバグ修正フロー

従来のフローは、以下のような手順で進みます。

• QAがバグを発見し、Bugoonウィジェットからスクリーンショット付きで報告
• GitHubにIssueが作成され、SlackにURLが通知される
• 開発者がIssueを開き、スクリーンショットを見てステップを手動で読み解く
• ローカル環境で再現を試み、コンソールエラーやDOMを自分で確認する
• 原因を特定してコードを修正し、Issueのステータスを手動で「解決済み」に更新する

情報は揃っているはずなのに、「手で繋ぐ」作業が至るところに存在します。これがリードタイムの最大の原因です。

After：MCP ありのバグ修正フロー

Bugoon MCPをClaude Codeに接続すると、フローはこう変わります。

• QAがウィジェットからバグ報告（ここは同じ）
• 開発者がClaude Codeで /fix-bug コマンドを実行
• MCPがGitHub IssueのIDを受け取り、スクリーンショット・DOM・エラーログを自動取得
• Claude Codeが原因を分析し、修正コードを提案・適用
• MCPがIssueのステータスを自動で更新

開発者が行うのは、コマンドを1回打つことと、最終的な差分を確認することだけです。

コード例：fix-bug コマンドの実装

.claude/commands/fix-bug.md に以下のように記述することで、カスタムスラッシュコマンドとして登録できます。

# .claude/commands/fix-bug.md
# 引数: $ARGUMENTS にGitHub Issue番号を渡す

1. mcp__bugoon__get_bug_report を呼び出してIssue #$ARGUMENTS の詳細を取得する
2. 取得したスクリーンショットパス・DOM・コンソールエラーを分析する
3. 原因となっているファイルを特定し、最小限の変更で修正する
4. mcp__bugoon__update_status でIssueステータスを "in_progress" に更新する
5. 修正内容の要約を日本語で出力する

MCPツールの呼び出しフローをJSON形式で示すと、以下のようになります。

{
  "tool": "mcp__bugoon__get_bug_report",
  "input": {
    "issue_number": 42,
    "include": ["screenshot_url", "dom_snapshot", "console_errors", "interaction_steps"]
  }
}

レスポンスには screenshot_url（Firebase StorageのURL）、dom_snapshot（報告時点のHTML構造）、console_errors（JSエラーのスタックトレース）、interaction_steps（再現手順）が含まれます。Claude Codeはこれらを一度に受け取り、コードベースと照合して修正箇所を特定します。

まとめと次のステップ

Bugoon MCPの導入により、「情報を集める時間」がゼロになります。QAが報告した瞬間に必要なコンテキストはすべて構造化されており、Claude Codeがそれを読み取って修正まで完結させます。開発者はコードレビューとデプロイ判断に集中できるようになります。

まずは npm install -g @rubyjobs-jp/bugoon-mcp-server でMCPサーバーをインストールし、.claude/settings.json にMCPの設定を追加するところから始めてみてください。セットアップは5分以内で完了します。

次の記事では、Bugoon MCPを使ってE2Eテストの失敗レポートを自動でトリアージし、Flaky Testと本物のバグを分類するフローを紹介します。