Webアプリをリアルに自動テストしてバグを検出・修正

テストが失敗したり、実装が意図通りに動かない時に、推測や思いつきではなく、ログ出力による「証拠」に基づいてバグの原因を特定できます。 考えられる原因を5～7個列挙し、最も可能性の高いものに絞って検証するため、闇雲なデバッグの時間を大幅に削減できます。 修正後も、デバッグログをすべて削除し、プロジェクト全体の一貫性を保った状態でコミットできます。 テストコードがパスしないトラブルに遭遇したエンジニア 「なぜ動かないのか理由が不明」という状況から抜け出したい方 原因不明のコンパイルエラーやランタイムエラーの対応を効率化したい方 バグ修正時に、問題の根本原因を正確に把握してから対応したいチーム ワークフローは6ステップで構成。Step 1：症状の正確な把握。エラーメッセージ・スタックトレース全文確認、期待値と実際値の差分明確化、再現条件の特定を「期待/実際/エラー/再現」テンプレートで記録。Step 2：仮説の列挙（5～7個）。データ（入力値・初期化順序）、状態（ライフサイクル・タイミング）、依存（他システム連携・イベント順序）、環境（Unity固有・非同期・スレッド）のカテゴリ別に幅広く検討。Step 3：絞り込み（1～2個）。エラーメッセージとの整合性、変更履歴との関連、再現パターンの一致、過去類似バグ経験を判断基準に。Step 4：ログによる仮説検証。問題メソッドの入口・出口、条件分岐直前、データ変換前後に Debug.Log で値を出力。Step 5：検証と修正。ログ結果から原因特定し最小限修正、外れたら新仮説を追加検証。Step 6：クリーンアップ。デバッグログ全削除、プロジェクト一貫性確認。アンチパターンは推測修正・一度に大量変更・ログ残し。

症状から出発して、ログ・スタックトレース・デバッグツールを活用しながら根本原因を特定できます 5 Why 分析やフィッシュボーン図など体系的な RCA（根本原因分析）手法を使い、表面的な原因ではなく本質的な問題を見つけられます メモリリーク、競合状態、パフォーマンス問題など、複雑なバグのパターンに対応できます デバッグループに陥ったときに自動検出し、別のアプローチを提案して効率的に問題を解決できます GitHub Issue から問題の詳細を抽出し、構造的に調査を進めることができます 本番環境で複雑なバグが発生し、原因が特定しづらい状況に困っている開発者 デバッグに何時間もかかってしまい、効率化したい人 チーム内で「このバグ、何が問題なのか」を説明する必要がある人 パフォーマンス問題やメモリリークなど、実装的な根深い問題に対応したい人 Bug Hunter AI は英語でバグ調査・根本原因分析・フィックス生成を支援するエージェントで、日本語での対話で効率的なデバッグを実現します。得意領域は再現手順（Minimal Reproducible Examples）・ログ分析（エラーログ・スタックトレース）・デバッグツール（ブレークポイント・ステップ実行・変数監視）、および 5 Why・フィッシュボーン図・タイムラインを使った RCA です。バグ種別としてロジックエラー・メモリリーク・競合状態・パフォーマンス問題・セキュリティ脆弱性に対応し、二分探索デバッグ・ラバーダック・分割統治・仮説検証などの戦略を適用します。MUSUBI Agent の StuckDetector モジュールでデバッグループ検出が可能（repeatThreshold: 3、minHistoryLength: 5）で、IssueResolver で GitHub Issue から bug 詳細を抽出（issue number・title・description）して体系的に調査を開始できます。

モバイルやCloudflare経由でセッション開いた直後に発生する「再接続中...」ループを診断・修正できます。 ブラウザコンソールの WebSocket connection failed エラーと 502 Bad Gateway の原因を特定できます。 ttydプロセス起動時のタイミングレース問題を解決する2段階確認方式を実装できます。 サーバーログから「ポートリッスン準備完了」を確認してからクライアント接続を許可する仕組みに変更できます。 既存アクティブセッションの再起動時に旧ロジックが残っている問題を検出・修正できます。 ttydを使ったブラウザベースターミナルを運用している開発者 モバイルやプロキシ経由でのリモート接続が多い環境の管理者 WebSocket接続エラーのトラブルシューティングに時間がかかっている方 接続の安定性を改善したいインフラエンジニア ttydプロセス起動には2つのステップが存在します：(1)プロセス起動（spawn完了）と(2)ポートリッスン開始（WebSocket接続受付可能）。旧実装では(1)までしか確認していないため、クライアントが(2)完了前にWS接続を試行してしまい失敗します。特にCloudflare Zero Trust経由ではプロキシ遅延により顕著に発生します。解決策として、新規メソッド waitForTtydReady() を実装し、ポートリッスン確認を10秒間、100ms間隔でリトライします。このメソッドは port、timeoutMs、retryIntervalMs をパラメータに取り、ポート監視完了時に「Port ready after XXXms」ログを出力します。session-manager.js の起動フローに2段階確認方式を導入し、Step 1でプロセス生存確認、Step 2でポートリッスン確認を実行する実装が commit: e0775da で提供されています。