バグを調査して根本原因を特定

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

Steel.devクラウドブラウザを使い、実ユーザー視点でWebアプリを自動テストし、バグを検出できます。 ページレンダリング、リンク・フォーム機能、エッジケース（空入力、特殊文字、ネットワーク遅延）、JavaScriptエラーを包括的にチェックできます。 検出したバグをCritical/High/Medium/Lowに分類し、Tier（Quick/Standard/Exhaustive）に応じた自動修正ループで品質を向上させます。 テスト実行から修正検証までのワークフローを自動化し、Paperclip Heartbeatで定期的にQAを実行できます。 Web アプリケーション開発チームの品質保証（QA）担当者 継続的デリバリーで定期的な自動テストが必要なスタートアップやSaaS企業 ブラウザの互換性確認やレイアウト崩れ検出を自動化したいフロントエンド開発チーム バグ検出から修正検証までを効率化したいプロダクト開発チーム Dev QA（Browser Testing & Bug Fix Agent）は、Steel.dev クラウドブラウザAPI を使い、Paperclip Heartbeat上でWebアプリを実ユーザー視点でテストします。 環境変数STEEL_API_KEY、PAPERCLIP_API_URL/KEY、COMPANY_ID、RUN_IDを設定後、Heartbeatフローは以下の通り：割り当てIssueを取得 → テスト対象URL・スコープを抽出 → ブラウザセッション作成 → テスト実行・バグ検出・修正・再検証 → レポートをIssueコメントに投稿 → セッション終了。 Steel.dev API操作は、POST /sessions でセッション作成（CDP_URL取得）、POST /actions/navigate でページ遷移、GET /actions/screenshot でスクリーンショット取得、DELETE /sessions でセッション終了。テストプロセスは、IssueからTarget URL・Scope・Tier を抽出。テスト実行ではレンダリング（HTTP 200、レイアウト、モバイル表示）、インタラクション（リンク・フォーム・ボタン・連打耐性）、エッジケース（空入力・特殊文字・遅延・戻る）、コンソール（JSエラー・ネットワークエラー）をチェック。バグをCritical/High/Medium/Low に分類し、Tier別に修正範囲を決定します。

モバイルや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 で提供されています。