バイブコーディングで開発は爆速になったけど、テストどうする問題をClaude Codeが解決してくれた話
バイブコーディングで開発は爆速になったけど、テストどうする問題をClaude Codeが解決してくれた話
バイブコーディングで開発は爆速になったけど、テストどうする問題をClaude Codeが解決してくれた話
テストのしわ寄せ問題
最近、バイブコーディング（AIにコードを書かせる開発スタイル）で開発スピードが劇的に上がった。自分の場合はNext.js + Supabaseの会員管理システムを、VSCode上のClaude Codeで開発している。チャットパネルでAIに「この機能追加して」と伝えるだけでコードが出てくるので、正直コードを書くスピードは以前の何倍にもなった。
ただ、困ったことが一つ。
テストが追いつかない。
コードの変更が多いぶん、「ちゃんと動くか」の確認作業が膨大になる。Playwrightでテストコード書く？いや、そのテストコード自体がメンテ対象になるし、そもそもテストコードを書く時間がもったいない。
そんな中、Xでこの投稿が流れてきた。
Computer use is now in Claude Code. Claude can open your apps, click through your UI, and test what it built, right from the CLI. — Claude (@claudeai) March 30, 2026
Claude Codeにコンピュータ操作機能が追加された。つまり、AIが実際にブラウザを開いて、ボタンをクリックして、画面の状態をスクリーンショットで確認して、バグまで指摘してくれるらしい。
これは気になる。検証してみたいし、できれば今関わっている実務のプロジェクトでそのまま使えたら最高だな、と思って試してみた。
セットアップ（10分で終わる）
必要なもの:
macOS
Claude ProまたはMaxプラン
Claude Code v2.1.85以降
手順はシンプルで、Claude Codeを起動して /mcp コマンドからcomputer-useサーバーを有効化するだけ。macOSのアクセシビリティと画面収録の権限を許可する必要があるけど、一度やれば終わり。
自分の場合はClaude Code v2.1.47だったのでアップデートが必要だった。npm update -g @anthropic-ai/claude-code で一発。
最初のテスト：ログイン画面のスクリーンショット
まずは簡単なところから。Claude Codeに日本語でこう指示した。
すると、Claudeが自動でPlaywrightを使ってブラウザを起動し、スクリーンショットを撮り、画面の内容まで分析してくれた。
「管理者ログイン画面が表示されており、メールアドレス入力欄、パスワード入力欄、ログインボタン…」と要素を全て認識。
おお、動く。
バリデーションテストで早速バグ発見
調子に乗って次の指示。
Claudeは自動でPlaywrightのテストスクリプトを書いて実行。空欄のままログインボタンを押して、エラーメッセージのスクリーンショットを撮った。
そしてここからが面白い。テスト結果だけじゃなく、改善提案まで出してきた。
「これはフロントエンド側のバリデーションではなく、空のままSupabase Authに送信されてサーバー側で認証失敗した結果のエラーメッセージです。入力前にクライアント側でバリデーションを行う方が、UX的にもサーバー負荷的にも望ましいかもしれません。」
手動テストなら「エラー出た、OK」で終わるところを、AIが「もっといいやり方あるよ」と指摘してくれる。
実務で使ってみる
ここまでのログイン画面のテストは、いわばComputer Useの動作確認。テストのテストみたいなものだった。
ちゃんと動くことがわかったので、ここからは実際に自分が関わっている案件で使ってみることにした。
自分の開発環境はこんな構成になっている:
Claude Code（VSCodeのチャットパネル） — ここでバイブコーディング（コード生成・修正）『赤いとこ』
Claude Code（VSCodeのターミナル） — テスト実行に使う『黄色いとこ』
Claude デスクトップアプリ — テスト結果の分析や相談に使う
同じClaude Codeでも、VSCodeのチャットパネルでコードを書いて、ターミナル側でテストを回すという使い分けをしている。
今回の変更内容（有効期限検索、入会日範囲検索、一括アクティブ化、振込日の未来日付制限など）は全てチャットパネル側でバイブコーディングしていた。テストもチャットパネルでやりたかったけど、Computer Useによるテスト実行はターミナル側のClaude Codeでしかできないと言われた。
じゃあせめてテスト項目はチャットパネル側で作ってもらおう、と思った。チャットパネルには今回の変更のやり取りが全部残っているので、変更の影響範囲を一番正確に把握できるはず。
そこでチャットパネルに「このプロンプト以下の変更の影響範囲のテスト項目を作って」と伝えた。チャットパネルでは、バイブコーディングのやり取りが上から下に時系列で並んでいる。その途中に以下のように書き込んだ形。つまり「ここから下にある今日の変更内容をもとにテストを作って」という意味。
チャットパネルが10カテゴリのテスト項目を生成してくれたので、それをVSCodeのターミナル内で動いているClaude Codeにコピペして投げた。「全部まとめて実行して」と。5つのAgentが並列で走って結果が返ってきた。
全40項目PASS。
…おお、完璧じゃん。と思ったんだけど。
「設計書を見て安全と言ってるだけ」問題
全項目PASS。でも正直、早すぎないか？ 画面確認してるはずなのに10分で40項目？ なんか引っかかる。
こういう時に相談するのが、自分にとって心の拠り所になっているClaude デスクトップアプリ（claude.ai）。開発の相談役みたいな存在で、VSCodeのターミナルとは別に常に開いている。テスト結果を共有して「これどう思う？」と聞いてみた。
すると、こう指摘された。
「今回のテストはほぼ全てコードレビュー（静的解析）で判定されています。つまり『コードにこう書いてあるからPASS』という判定です。」
これは例えるなら、建物の設計図を見て「この建物は大丈夫」と言っている状態。実際に建物に入って確認したわけじゃない。
コードレビューだけでは見つけられない問題がある:
CSSの競合で実際にはボタンが見えない
非同期処理のタイミングでUIが壊れる
特定のデータパターンで表示がおかしくなる
ブラウザ固有のレンダリング問題
全40項目PASSのうち、実際にブラウザで操作して確認できていたのはたった2項目だけだった。
ブラウザテストでやり直し
というわけで、今度はターミナルのClaude Codeに「コードレビューだけでなく、実際にブラウザで操作して確認する項目も必ず入れて」と指示してテスト仕様書を作り直させた。各テスト項目に「ブラウザテスト」か「コードレビュー」かを明確に分けて、ブラウザテスト用にはPlaywrightのログインヘルパー関数まで用意させた。
そして再テスト実行。今度は実際にブラウザを操作して、スクリーンショットという証拠付きで確認。
結果はブラウザテスト19項目＋コードレビュー、合計56項目中55項目PASS。
しかもテスト中に仕様書になかった不具合まで1件発見してくれた（ログイン直後のセッション同期問題）。さらに振込日のmax制限が一部画面で未対応という指摘もあった。
今度は信頼できる結果。
再テストも一発
最初のブラウザテストで2項目だけ微妙なところがあった:
サポート金額が¥0と表示された（テストスクリプトの入力方法の問題）
チケット一覧がローディング中にスクリーンショットを撮ってしまった
これもClaude Codeに「この2つだけ再テストして」と投げたら、4分で修正版のテストを実行してPASSを確認してくれた。
実際どれくらい時間が節約できたか
今回テストした内容を手動でやる場合:
テスト項目の洗い出し: 1〜2時間
各画面の操作・確認: 3〜4時間
スクリーンショットの整理: 1時間
テスト結果のドキュメント化: 1時間
合計6〜8時間。丸一日の作業。
Claude Codeだと:
テスト項目の自動生成: 2分
1回目のテスト（コードレビュー中心、やり直し）: 10分
2回目のテスト（ブラウザテスト）: 14分
再テスト（2項目）: 4分
結果レポート生成: 1分
合計約30分。やり直しを含めても30分。
学んだこと
コードレビューとブラウザテストは別物
AIにテストを任せるときに一番大事なのは、「何を根拠にPASSと言っているか」を確認すること。コードを読んだだけの判定と、実際に画面を操作した判定は全然違う。最初から「ブラウザテストも必ず含めて」と指示するのがコツ。
テスト項目を「どこで」作るかが意外と大事
今回はチャットパネル側でテスト項目を作ったが、ターミナルのClaude Codeでもgit logやgit diffを使って変更履歴からテスト項目を自動生成できる。
ただし、この2つには違いがある:
チャットパネル: バイブコーディングのやり取りが全部残っているので、「なぜその変更をしたか」という意図まで把握している。テスト項目の精度が高くなりやすい
ターミナル（Claude Code）: git diffからコードの変更は正確に読めるが、変更の意図まではわからない。ただしテスト実行まで一気通貫でできる
自分の場合は「チャットパネルでテスト項目を作る→ターミナルにコピペして実行」が一番うまくいった。変更の文脈を知っている場所でテスト設計して、実行力がある場所でテストを回す、という分業。
エラーが出ても粘り強い
セットアップ中にアクセシビリティ権限のエラーが出たり、Playwrightのバイナリパスが見つからなかったり、ログインがServer Actionとの相性で失敗したり。でもClaude Codeは毎回自分でアプローチを変えてリトライしてくれた。人間だったら3回目くらいで心が折れる。
完璧ではないが十分実用的
ローディング中にスクリーンショットを撮ってしまうとか、フォーム入力がうまくいかないとか、細かい問題はある。でも「10秒待ってから撮り直して」と日本語で言えば修正できる。Playwrightのセレクタを直すより圧倒的に楽。
まとめ
バイブコーディングで「作る」のは爆速になった。でもテストが追いつかない問題は残っていた。
Claude Code Computer Useは、その「テストのしわ寄せ」を解決してくれる。ただし、最初は「コード読んだだけでPASS」になりがちなので、ブラウザテストを明示的に指示することが重要。
テスト専任の人を雇うほどではないけど、手動テストの時間はなんとかしたい——そんな規模感の開発にドンピシャだと思う。
人を雇う前に、まず試してみる価値はある。
バイブコーディングで開発は爆速になったけど、テストどうする問題をClaude Codeが解決してくれた話
テストのしわ寄せ問題
最近、バイブコーディング（AIにコードを書かせる開発スタイル）で開発スピードが劇的に上がった。自分の場合はNext.js + Supabaseの会員管理システムを、VSCode上のClaude Codeで開発している。チャットパネルでAIに「この機能追加して」と伝えるだけでコードが出てくるので、正直コードを書くスピードは以前の何倍にもなった。
ただ、困ったことが一つ。
テストが追いつかない。
コードの変更が多いぶん、「ちゃんと動くか」の確認作業が膨大になる。Playwrightでテストコード書く？いや、そのテストコード自体がメンテ対象になるし、そもそもテストコードを書く時間がもったいない。
そんな中、Xでこの投稿が流れてきた。
Computer use is now in Claude Code. Claude can open your apps, click through your UI, and test what it built, right from the CLI. — Claude (@claudeai) March 30, 2026
Claude Codeにコンピュータ操作機能が追加された。つまり、AIが実際にブラウザを開いて、ボタンをクリックして、画面の状態をスクリーンショットで確認して、バグまで指摘してくれるらしい。
これは気になる。検証してみたいし、できれば今関わっている実務のプロジェクトでそのまま使えたら最高だな、と思って試してみた。
セットアップ（10分で終わる）
必要なもの:
macOS
Claude ProまたはMaxプラン
Claude Code v2.1.85以降
手順はシンプルで、Claude Codeを起動して /mcp コマンドからcomputer-useサーバーを有効化するだけ。macOSのアクセシビリティと画面収録の権限を許可する必要があるけど、一度やれば終わり。
自分の場合はClaude Code v2.1.47だったのでアップデートが必要だった。npm update -g @anthropic-ai/claude-code で一発。
最初のテスト：ログイン画面のスクリーンショット
まずは簡単なところから。Claude Codeに日本語でこう指示した。
すると、Claudeが自動でPlaywrightを使ってブラウザを起動し、スクリーンショットを撮り、画面の内容まで分析してくれた。
「管理者ログイン画面が表示されており、メールアドレス入力欄、パスワード入力欄、ログインボタン…」と要素を全て認識。
おお、動く。
バリデーションテストで早速バグ発見
調子に乗って次の指示。
Claudeは自動でPlaywrightのテストスクリプトを書いて実行。空欄のままログインボタンを押して、エラーメッセージのスクリーンショットを撮った。
そしてここからが面白い。テスト結果だけじゃなく、改善提案まで出してきた。
「これはフロントエンド側のバリデーションではなく、空のままSupabase Authに送信されてサーバー側で認証失敗した結果のエラーメッセージです。入力前にクライアント側でバリデーションを行う方が、UX的にもサーバー負荷的にも望ましいかもしれません。」
手動テストなら「エラー出た、OK」で終わるところを、AIが「もっといいやり方あるよ」と指摘してくれる。
実務で使ってみる
ここまでのログイン画面のテストは、いわばComputer Useの動作確認。テストのテストみたいなものだった。
ちゃんと動くことがわかったので、ここからは実際に自分が関わっている案件で使ってみることにした。
自分の開発環境はこんな構成になっている:
Claude Code（VSCodeのチャットパネル） — ここでバイブコーディング（コード生成・修正）『赤いとこ』
Claude Code（VSCodeのターミナル） — テスト実行に使う『黄色いとこ』
Claude デスクトップアプリ — テスト結果の分析や相談に使う
同じClaude Codeでも、VSCodeのチャットパネルでコードを書いて、ターミナル側でテストを回すという使い分けをしている。
今回の変更内容（有効期限検索、入会日範囲検索、一括アクティブ化、振込日の未来日付制限など）は全てチャットパネル側でバイブコーディングしていた。テストもチャットパネルでやりたかったけど、Computer Useによるテスト実行はターミナル側のClaude Codeでしかできないと言われた。
じゃあせめてテスト項目はチャットパネル側で作ってもらおう、と思った。チャットパネルには今回の変更のやり取りが全部残っているので、変更の影響範囲を一番正確に把握できるはず。
そこでチャットパネルに「このプロンプト以下の変更の影響範囲のテスト項目を作って」と伝えた。チャットパネルでは、バイブコーディングのやり取りが上から下に時系列で並んでいる。その途中に以下のように書き込んだ形。つまり「ここから下にある今日の変更内容をもとにテストを作って」という意味。
チャットパネルが10カテゴリのテスト項目を生成してくれたので、それをVSCodeのターミナル内で動いているClaude Codeにコピペして投げた。「全部まとめて実行して」と。5つのAgentが並列で走って結果が返ってきた。
全40項目PASS。
…おお、完璧じゃん。と思ったんだけど。
「設計書を見て安全と言ってるだけ」問題
全項目PASS。でも正直、早すぎないか？ 画面確認してるはずなのに10分で40項目？ なんか引っかかる。
こういう時に相談するのが、自分にとって心の拠り所になっているClaude デスクトップアプリ（claude.ai）。開発の相談役みたいな存在で、VSCodeのターミナルとは別に常に開いている。テスト結果を共有して「これどう思う？」と聞いてみた。
すると、こう指摘された。
「今回のテストはほぼ全てコードレビュー（静的解析）で判定されています。つまり『コードにこう書いてあるからPASS』という判定です。」
これは例えるなら、建物の設計図を見て「この建物は大丈夫」と言っている状態。実際に建物に入って確認したわけじゃない。
コードレビューだけでは見つけられない問題がある:
CSSの競合で実際にはボタンが見えない
非同期処理のタイミングでUIが壊れる
特定のデータパターンで表示がおかしくなる
ブラウザ固有のレンダリング問題
全40項目PASSのうち、実際にブラウザで操作して確認できていたのはたった2項目だけだった。
ブラウザテストでやり直し
というわけで、今度はターミナルのClaude Codeに「コードレビューだけでなく、実際にブラウザで操作して確認する項目も必ず入れて」と指示してテスト仕様書を作り直させた。各テスト項目に「ブラウザテスト」か「コードレビュー」かを明確に分けて、ブラウザテスト用にはPlaywrightのログインヘルパー関数まで用意させた。
そして再テスト実行。今度は実際にブラウザを操作して、スクリーンショットという証拠付きで確認。
結果はブラウザテスト19項目＋コードレビュー、合計56項目中55項目PASS。
しかもテスト中に仕様書になかった不具合まで1件発見してくれた（ログイン直後のセッション同期問題）。さらに振込日のmax制限が一部画面で未対応という指摘もあった。
今度は信頼できる結果。
再テストも一発
最初のブラウザテストで2項目だけ微妙なところがあった:
サポート金額が¥0と表示された（テストスクリプトの入力方法の問題）
チケット一覧がローディング中にスクリーンショットを撮ってしまった
これもClaude Codeに「この2つだけ再テストして」と投げたら、4分で修正版のテストを実行してPASSを確認してくれた。
実際どれくらい時間が節約できたか
今回テストした内容を手動でやる場合:
テスト項目の洗い出し: 1〜2時間
各画面の操作・確認: 3〜4時間
スクリーンショットの整理: 1時間
テスト結果のドキュメント化: 1時間
合計6〜8時間。丸一日の作業。
Claude Codeだと:
テスト項目の自動生成: 2分
1回目のテスト（コードレビュー中心、やり直し）: 10分
2回目のテスト（ブラウザテスト）: 14分
再テスト（2項目）: 4分
結果レポート生成: 1分
合計約30分。やり直しを含めても30分。
学んだこと
コードレビューとブラウザテストは別物
AIにテストを任せるときに一番大事なのは、「何を根拠にPASSと言っているか」を確認すること。コードを読んだだけの判定と、実際に画面を操作した判定は全然違う。最初から「ブラウザテストも必ず含めて」と指示するのがコツ。
テスト項目を「どこで」作るかが意外と大事
今回はチャットパネル側でテスト項目を作ったが、ターミナルのClaude Codeでもgit logやgit diffを使って変更履歴からテスト項目を自動生成できる。
ただし、この2つには違いがある:
チャットパネル: バイブコーディングのやり取りが全部残っているので、「なぜその変更をしたか」という意図まで把握している。テスト項目の精度が高くなりやすい
ターミナル（Claude Code）: git diffからコードの変更は正確に読めるが、変更の意図まではわからない。ただしテスト実行まで一気通貫でできる
自分の場合は「チャットパネルでテスト項目を作る→ターミナルにコピペして実行」が一番うまくいった。変更の文脈を知っている場所でテスト設計して、実行力がある場所でテストを回す、という分業。
エラーが出ても粘り強い
セットアップ中にアクセシビリティ権限のエラーが出たり、Playwrightのバイナリパスが見つからなかったり、ログインがServer Actionとの相性で失敗したり。でもClaude Codeは毎回自分でアプローチを変えてリトライしてくれた。人間だったら3回目くらいで心が折れる。
完璧ではないが十分実用的
ローディング中にスクリーンショットを撮ってしまうとか、フォーム入力がうまくいかないとか、細かい問題はある。でも「10秒待ってから撮り直して」と日本語で言えば修正できる。Playwrightのセレクタを直すより圧倒的に楽。
まとめ
バイブコーディングで「作る」のは爆速になった。でもテストが追いつかない問題は残っていた。
Claude Code Computer Useは、その「テストのしわ寄せ」を解決してくれる。ただし、最初は「コード読んだだけでPASS」になりがちなので、ブラウザテストを明示的に指示することが重要。
テスト専任の人を雇うほどではないけど、手動テストの時間はなんとかしたい——そんな規模感の開発にドンピシャだと思う。
人を雇う前に、まず試してみる価値はある。
