コンソールでのデバッグ

Chrome DevTools MCPを使用してWebアプリケーションのコンソールエラーをキャプチャし、分析します。

トークン効率: 手動でのコンソール検査パターンを排除（60%削減: 2,000 → 800トークン）

使用方法

以下で呼び出します: /debug-console [url]

例:

• /debug-console - 現在のページをデバッグ（ブラウザが既に開いている場合）
• /debug-console http://localhost:3000/app/scheduler - 特定ページにナビゲートしてデバッグ
• /debug-console http://localhost:3000 - ホームページをデバッグ

前提条件

• Chrome DevTools MCPが有効: claude --chrome
• Claude in Chrome拡張機能でChromeブラウザが実行中
• アプリケーションがlocalhost:3000で実行中

ワークフロー

ステップ1: URLへのナビゲーション

URLが指定された場合:

mcp__playwright__browser_navigate({ url: "[provided-url]" })

URLが指定されていない場合:

• Chromeブラウザの現在のページを使用
• ナビゲーションステップをスキップ

ステップ2: コンソールメッセージのキャプチャ

エラーと警告をキャプチャ:

mcp__playwright__browser_console_messages({ level: "error" })

フィルタ条件:

• レベル: 「error」はエラーと警告を含みます（より高い重大度のレベルも含まれます）
• JavaScriptエラー
• ネットワーク障害（404、500、CORSエラー）
• React/Next.jsエラー
• ランタイム例外

ステップ3: エラーの分析

エラーをタイプ別にグループ化:

1. 構文エラー: パースエラー、無効な構文
2. ランタイムエラー: TypeError、ReferenceError、null/未定義アクセス
3. ネットワークエラー: 失敗したフェッチ、404、CORSの問題
4. フレームワークエラー: Reactハイドレーション、Next.jsエラー
5. サードパーティエラー: 外部ライブラリエラー

詳細を抽出:

• エラーメッセージ（完全なテキスト）
• ファイルの場所（file:line:column）
• スタックトレース（利用可能な場合）
• エラーカウント（発生回数）
• タイムスタンプ（エラーが発生した時刻）

ステップ4: 結果を報告

構造化されたサマリーを作成:

## コンソールデバッグレポート: [URL]

**日時**: [timestamp]
**ブラウザ**: Chrome（Chrome DevTools MCP経由）

### サマリー
- 総エラー数: [count]
- 重大なエラー: [count]（機能をブロック）
- 警告: [count]（非ブロッキング問題）
- ネットワーク障害: [count]

### 重大なエラー

#### 1. [エラータイプ] - [重大度]
- **メッセージ**: [エラーメッセージ]
- **場所**: [file:line:column]
- **タイプ**: [TypeError | ReferenceError | NetworkError | など]
- **スタックトレース**:

[利用可能な場合はスタックトレース]

- **発生回数**: [count]
- **影響**: [破損しているものの説明]
- **推奨事項**: [具体的な修正提案]

[各重大なエラーについて繰り返す]

### 警告

#### 1. [警告タイプ]
- **メッセージ**: [警告メッセージ]
- **場所**: [file:line:column]
- **推奨事項**: [修正提案]

[各警告について繰り返す]

### ネットワーク障害

#### 1. [リクエストURL]
- **ステータス**: [404 | 500 | など]
- **タイプ**: [CORS | Timeout | Server Error]
- **推奨事項**: [修正提案]

[各ネットワーク障害について繰り返す]

### 次のステップ

**即座のアクション**:
1. [重大なエラー1を修正]
2. [重大なエラー2を修正]
3. [ネットワーク障害に対処]

**オプションの改善**:
1. [警告に対処]
2. [コンソールログに基づくパフォーマンス最適化]

ステップ5: レポートを保存（重大なエラーが見つかった場合）

以下の場合のみ保存:

• 重大なエラーカウント > 0
• または警告カウント > 3
• またはネットワーク障害カウント > 1

保存場所: .claude/logs/debug_console_[timestamp].md

重大な問題がない場合:

• ユーザーにレポートサマリーを直接報告
• ログファイルを作成しない（トークン効率）

成功基準

• すべてのコンソールエラーがキャプチャされている（エラーレベル以上）
• エラーがタイプ別に分類されている（構文、ランタイム、ネットワーク、フレームワーク）
• ファイルの場所が抽出されている（file:line:column）
• 重大なエラーに対してスタックトレースが含まれている
• 各エラーに対して実行可能な推奨事項が提供されている
• レポート形式が明確で構造化されている

エラーハンドリング

一般的な問題

問題: 「Chrome DevTools MCPが利用できません」

• 解決方法: Claude Codeをclaude --chromeで開始
• フォールバック: 手動でのコンソール検査を提案

問題: 「ブラウザが応答しません」

• 解決方法: ブラウザをブロックしているモーダルダイアログを確認
• アクション: ダイアログを手動で閉じるか、新しいタブを作成

問題: 「コンソールメッセージが見つかりません」

• 結果: 「エラーが見つかりません」と報告（成功ケース）
• アクション: ユーザーにアプリがコンソールエラーなしで実行されていることを通知

問題: 「コンソールメッセージが多すぎます（>100）」

• 解決方法: head_limitを使用して最初の50エラーをキャプチャ
• アクション: レポートに記載: 「最初の50エラーを表示（合計: [count]）」

例

例1: シンプルなデバッグ

ユーザー: /debug-console http://localhost:3000/app/scheduler

出力:

## コンソールデバッグレポート: http://localhost:3000/app/scheduler

### サマリー
- 総エラー数: 2
- 重大なエラー: 1
- 警告: 1

### 重大なエラー

#### 1. TypeError - 重大
- **メッセージ**: Cannot read properties of undefined (reading 'shifts')
- **場所**: SchedulerView.tsx:42:15
- **タイプ**: TypeError（ランタイムエラー）
- **スタックトレース**:

at SchedulerView (SchedulerView.tsx:42:15) at renderWithHooks (react-dom.production.min.js:14985)

- **発生回数**: 1
- **影響**: Schedulerがシフトデータのレンダリングに失敗
- **推奨事項**: shiftsにアクセスする前にnullチェックを追加: `data?.shifts?.map(...)`

### 警告

#### 1. Reactハイドレーション警告
- **メッセージ**: Text content did not match. Server: "0 shifts" Client: "Loading..."
- **場所**: ShiftCount.tsx:15:8
- **推奨事項**: サーバーとクライアントが同じ初期状態をレンダリングすることを確認

### 次のステップ

**即座のアクション**:
1. SchedulerView.tsxの42行目のTypeErrorを修正（nullチェックを追加）
2. ShiftCountコンポーネントのReactハイドレーションを確認

例2: エラーが見つかりません

ユーザー: /debug-console

出力:

## コンソールデバッグレポート: http://localhost:3000/app/scheduler

✅ エラーが見つかりません！

**サマリー**:
- 総エラー数: 0
- 警告: 0
- ネットワーク障害: 0

アプリケーションはコンソールエラーなしで実行されています。

例3: ネットワーク障害

ユーザー: /debug-console http://localhost:3000/app/dashboard

出力:

## コンソールデバッグレポート: http://localhost:3000/app/dashboard

### サマリー
- 総エラー数: 0
- ネットワーク障害: 2

### ネットワーク障害

#### 1. GET /api/trpc/users.getAll
- **ステータス**: 500 Internal Server Error
- **タイプ**: サーバーエラー
- **推奨事項**: tRPCプロシージャエラーについてサーバーログを確認

#### 2. GET /api/trpc/metrics.getWeekly
- **ステータス**: 404 Not Found
- **タイプ**: エンドポイント欠落
- **推奨事項**: tRPCルーターにmetrics.getWeeklyプロシージャが含まれていることを確認

### 次のステップ

**即座のアクション**:
1. users.getAllエラーについてバックエンドサーバーログを確認
2. tRPCルーターにmetrics.getWeeklyプロシージャを追加

開発ワークフローとの統合

このスキルを使用する場合:

• ✅ 新しい機能を実装した後（コンソールエラーがないことを確認）
• ✅ コードをコミットする前（プリコミットチェック）
• ✅ ユーザーが「アプリが動作しない」と報告した場合（最初にコンソールをデバッグ）
• ✅ localhostにデプロイした後（健全性チェック）
• ✅ UIの問題をデバッグする場合（JavaScriptエラーを確認）

このスキルを使用しない場合:

• ❌ 正式なE2Eテスト（代わりにPlaywrightテストフレームワークを使用）
• ❌ 本番環境でのデバッグ（本番環境監視ツールを使用）
• ❌ パフォーマンスプロファイリング（Chrome DevToolsプロファイラーを直接使用）

関連ツールとスキル

• auth-verify スキル: 認証が必要なページをデバッグする前に認証
• PLAYWRIGHT_MCP_AUTOMATION.md: ブラウザ自動化パターン
• Chrome DevTools MCP: ネイティブブラウザデバッグ機能

トークン効率

ベースライン（手動でのコンソール検査）:

• PLAYWRIGHT_MCP_AUTOMATION.mdを読む: 1,200トークン
• ページにナビゲート: 200トークン
• コンソールをキャプチャ: 300トークン
• 分析とレポート形式: 300トークン
• 合計: 約2,000トークン

debug-consoleスキルを使用:

• スキル呼び出し: 200トークン
• コンソールキャプチャ+分析: 400トークン
• レポート生成: 200トークン
• 合計: 約800トークン

削減: 1,200トークン（60%削減）

想定される使用: 週10回 週間削減: 12,000トークン 年間削減: 624,000トークン（約$1.50/年）

---

スキルバージョン: 1.0 作成: 2026-01-09 最終更新: 2026-01-09 必須: Claude Code v2.1.0+、Chrome DevTools MCP