はじめに：開発において、最も気が乗らず、最も手を抜きたくなるものとは...
動作確認です。
大切であることは過去の苦い経験から重々承知ですが、一番気が乗らない。
AIのおかげでDraft PRは大量に作成できるけど、動作確認がまだ終わっていないためにレビューリクエストができないもどかしさ。
Playwright MCPやBrowser Useでブラウザ操作を行うことはできたが、動作確認したことを証拠として残すまでどうしようか悩んでいました。
解決策：Claude for Chromeを使い、動作確認用PRを作る方法
ClaudeにはChromeの拡張機能（Claude for Chrome）が現在Beta版として提供されています。
これをスラッシュコマンドに組み込んで、それらを数珠繋ぎに実行していくワークフローを作成しました。
大雑把なワークフローはこのようになっています。
デバッグしたいPRの差分を分析し、デバッグ項目を自動生成 + デバッグ用ブランチ作成
↓
Claude for Chromeでブラウザを操作し、E2E動作確認を自動実行。スクショ、GIFを撮る。
↓
デバッグ結果（スクリーンショット・GIF付き）を別のPRとして投稿
ポイントは、デバッグの証拠を元のPRとは別のPRとして投稿している点です。
これによりmainブランチ、作業ブランチを汚さず、Claude Codeだけでスクショ/GIFをセキュアにGitHubのクラウド上に残すことができるようになります。
スラッシュコマンドのワークフロー全体像
先ほどのワークフローはスラッシュコマンドで表すとこのようになっています。
/debug-plan <PR番号>
成果物: debug-plan-<YYYYMMDD-HHMM>.md
↓
ユーザーが/clear（コンテキストクリア）
↓
/debug-implement debug-plan-<YYYYMMDD-HHMM>.md
成果物: debug-report-<YYYYMMDD-HHMM>.md, 動作確認SS, 動作確認GIF
↓
ユーザーが/clear（コンテキストクリア）
↓
/debug-pr-create debug-plan-<YYYYMMDD-HHMM>.md
成果物: 動作確認用PR
各スキルがファイルを介して連携する、疎結合な設計です。
各ステップ間で /clear を挟んでいるのは、コンテキストウィンドウの節約のためです。必要最低限のコンテキストにするために、各スキルが独立したファイル（デバッグプランやレポート）を介してデータを受け渡す設計にすることで、何度行なっても質が高いアウトプットができるようにしています。
コンテキストエンジニアリングの大切さは、こちらの記事が勉強になります。
各スキルの詳細
1. debug-plan：PRの差分から動作確認項目を自動生成
/debug-plan #123
最初のスキルは、PRの内容を分析して動作確認の計画を生成するものです。
やっていること：
-
gh pr viewでPRの詳細情報と差分を取得 -
PRのブランチにチェックアウト
-
デバッグ用ブランチをPRのブランチから作成
-
PRの差分をClaudeが分析し、動作確認項目を生成
-
テンプレートに基づいてデバッグプランファイルを出力
生成されるデバッグプランはこんな構造になっています。
# デバッグプラン
## 基本情報
| 項目 | 値 |
|------|-----|
| 対象PR | #123 |
| PR タイトル | ログイン後のリダイレクト修正 |
| 元ブランチ | fix/login-redirect |
| デバッグ用ブランチ | debug/123-fix-login-redirect |
## デバッグ項目
### 新機能・変更機能の動作確認
| # | 確認項目 | 確認手順 | 期待結果 | ステータス |
|---|---------|---------|---------|-----------|
| 1 | ログイン後のリダイレクト | メール/PWでログイン | ダッシュボードに遷移する | ⬜ 未実施 |
| 2 | プロフィール未作成時の遷移 | 新規ユーザーでログイン | /auth/complete-profile に遷移する | ⬜ 未実施 |
### デグレーション確認
| # | 確認項目 | 確認手順 | 期待結果 | ステータス |
|---|---------|---------|---------|-----------|
| 1 | 既存ユーザーのログインフロー | 既存ユーザーでログイン | 従来通りダッシュボードに遷移 | ⬜ 未実施 |
この計画書は次の debug-implementコマンドの入力として使用するためテンプレートを用意することで、成果物の品質がキープされます。テンプレートを用意する運用は他のコマンドでも用いています。
また、メール認証やCAPTCHAなどClaudeによる自動操作が難しい項目も「ユーザー介入が必要な項目」として別セクションに分類してくれます。「全部自動で！」ではなく、現実的なラインを引いてくれるのが実用的です。
2. debug-implement：Claude for Chromeで自動E2E実行
/debug-implement debug-plan-20260311-1430.md
先ほどのデバッグプランを受け取り、Claude for Chromeでデバッグを行います。
Claude for Chromeにより以下のようなブラウザ操作が可能になります。
-
ページ遷移（
navigate） -
フォーム入力（
form_input） -
クリックなどのUI操作（
computer） -
要素の検索と確認（
find） -
スクリーンショットの撮影
-
GIF形式での操作記録
やっていること：
-
デバッグプランファイルを読み込む
-
正しいブランチにいるか、アプリが
localhost:3000で起動しているかなど事前準備ができているか確認 -
出力ディレクトリ（スクリーンショット・GIF保存先）を準備
-
Claude for Chromeでブラウザセッションを初期化
-
デバッグ項目を1つずつ実行：
-
GIF記録を開始
-
ブラウザ操作を実行
-
スクリーンショットを撮影
-
結果を判定（✅ OK / ❌ NG / ⚠️ 要確認 / 🔄 スキップ）
-
デバッグレポートを生成
-
デバッグプランのステータスを更新
スクリーンショットやGIFは指定した出力先に保存まで行ってくれます。
3. debug-pr-create：デバッグ結果をPRとして残す
/debug-pr-create debug-plan-20260311-1430.md
最後のスキルは、デバッグの結果をdraft PRとして残し、視覚的にエビデンスを確認できるようにするものです。
やっていること：
- デバッグプランとデバッグレポートの両方を読み込み、結果を抽出
- スクリーンショット・GIFなど未コミットのエビデンスをコミット・プッシュ
- テンプレートに基づいてPR descriptionを生成し、draft PRを作成
スクリーンショットやGIFもコミットに含まれるので、ローカルで動かさなくても動作確認の結果を視覚的に確認できます。
また、間違ってマージしないように、PRは必ずドラフトで作成し、タイトルにも[デバッグ]を明記して作成するようにしています。確認が終わったらクローズする運用です。
今回のポイント
スキル間のデータ受け渡しはファイルベース
コンテキストエンジニアリングを意識した設計にするために、スキルとスキルの間で /clearコマンドでコンテキストをクリアしています。
これにより各スキルは独立したコマンドとして実行されるため、スキル間の状態共有はファイルを介して行います。
また、これらのファイルは動作確認のレポートとしても利用しています。
最終的な成果物
ファイル名にタイムスタンプを含めることで、命名衝突を避けています。
元のPRとは別の動作確認用のPRを作ること
スクリーンショットやGIFを作成できることはわかっていたのですが、これをどうやって証拠として残すのか悩んでいました。
ghコマンドで直接PRにimg/gifを貼り付けることができれば一番手っ取り早かったのですが、今のところできないみたいでした。
そこで、動作確認用の別PRを作成することで、
- 人間の手を介さず、Claudeだけで「動作確認→動作確認の証拠を残す」までができる
- mainブランチ、作業ブランチを汚さない
- セキュア
- デバッグ項目計画、デバッグレポートと一緒にSSがあるのでわかりやすい
- 作業ブランチからブランチを切っているので、diffを見ればわかりやすい。
というメリットがあります。
他の案としては
- CLIで画像をアップロードできるサービスを経由し、そのURLをPRに貼り付ける。（Imgur / ImgBB）
- セキュリティ的に怖いのでアウト。あとそもそもPRには貼れないかも...?
- ストレージを自分で用意する
- 工数が大きい。そこまでしなくていい。
などがあったのですが、どれも要件に合わず不採用となりました。
実際に使ってみた
PRの番号を引数にしてdebug-planを実行
debug-planが完了して、ファイルが生成される。次のコマンドも提案させる。
プランのファイルはこんな感じ
debug-implementを実行して動作確認を行う
GIFの作成・保存もやってくれる
debug-pr-createで作ったPR
スクショ/GIFも貼ってくれる
まとめ
今回やったこと
動作確認をClaudeで完全自動化させ、スクショ/GIF付きのエビデンスまで残すワークフローを作りました。
3つのスラッシュコマンドを数珠繋ぎに実行する構成：
- /debug-plan — PRの差分を分析し、動作確認項目を自動生成
- /debug-implement <プランファイル> — Claude for Chromeでブラウザを自動操作し、スクショ・GIFを撮影
- /debug-pr-create <プランファイル> — エビデンス付きのドラフトPRを自動作成
また、各コマンド間で /clear を挟み、ファイルを介してデータを受け渡す疎結合設計にすることでコンテキストを節約しつつ品質を安定させています。
エビデンスの保存先として「元のPRとは別の動作確認用PR」を作る方式を採用しており、mainブランチを汚さずセキュアに画像を残せるようにしています。
メリット
動作確認をClaudeに委譲するメリットとしては
- 完全に放置して、その間に違うことができる。
- 人間だと流石にやらないだろみたいな細かいところまで見てくれる
- フォントやカラーもちゃんと潜って確認してくれる
があります。
改善点・迷いポイント
改善点としては
- 上の例だと15分くらいかかってしまったので、もう少し高速化したい。
- gifがやたらと作られていたのでUIだけの確認であればSSの分岐を作る。
- PRを元に動作確認項目を作成しているので、実装がベースになっているが、そもそも正しいか。
あたりかなと思います。
最後に
動作確認は人間がやったほうがいいという意見がありそうですが、結局は実装者が責任を負えるかどうかにかかっていると思います。
「動作確認はAIがやりました！問題ないです！」と胸を張って言えるかどうか。
不安が残るなら自分で行うべきなんだろうなと思いました。
zennの記事の転載です。