「スマホ表示、ちゃんと確認した？」
Web アプリを開発していて、一番後回しにしがちな作業がある。
スマホでの UI 崩れチェック。
👤「PC で動いてるから OK でしょ」
🤖「……サイドバーのアバター、メインコンテンツに重なってますけど」
👤「え？」
🤖「あとカレンダーのアジェンダ、右側に出るはずが下に落ちてます」
👤「……」
これは実話です。自分で作ったアプリを、AI に見せたら即座にバグを見つけられた。
手動で 31 画面を PC とスマホの両方でスクショ撮って目視確認——やれば見つかったかもしれない。でもやらなかった。面倒だから。
「面倒な作業こそ AI に任せればいいのでは？」
そう思って Claude Cowork（Anthropic のデスクトップエージェント）に E2E テスト + UI 崩れチェックを丸投げしてみた。結果、人間が見逃していたバグが 3 つ見つかった。
先に数字を見せます
テスト対象アプリの規模
| 指標 | 数値 |
|---|---|
| テスト対象画面数 | 31 画面 |
| TypeScript 総行数 | 約 65,000 行 |
| フロントエンドページ | 31 ページ |
| DB エンティティ数 | 28 テーブル |
| API エンドポイント数 | 25 本 |
技術スタック: Next.js 16.1 (App Router) + shadcn/ui + Tailwind CSS + Hono + Drizzle ORM。
E2E テストの結果
| 指標 | 数値 |
|---|---|
| テストフェーズ数 | 9 フェーズ |
| Cowork が報告したバグ | 7 件 |
| うち本物のバグ | 3 件 |
| 仕様通り（by design） | 2 件 |
| 仕様差異（設計判断） | 1 件 |
| 既に修正済み | 1 件 |
| 作成した GitHub Issue | 3 件 |
| テスト準備にかかった時間 | 約 30 分（Claude Code CLI で自動生成） |
| Cowork のテスト実行時間 | 約 40 分 |
準備 30 分 + 実行 40 分で、31 画面の PC/スマホ表示を全チェック。 手動でやったら半日はかかる。
Claude Cowork ってそもそも何？
Claude Cowork は、Anthropic が提供する デスクトップ操作 AI エージェント（Research Preview）です。
Claude Code（ターミナル AI）とは別物。Cowork は ブラウザを実際に操作できる。 スクロール、クリック、スクリーンショット撮影——人間がブラウザでやることを、AI が代わりにやってくれる。
| 観点 | Claude Code (CLI) | Claude Cowork (Desktop) |
|---|---|---|
| 動作場所 | ターミナル | デスクトップ（ブラウザ等） |
| 得意なこと | コード読み書き、git 操作 | 画面操作、目視確認 |
| スクショ撮影 | 不可 | 可能 |
| ブラウザ操作 | 不可 | 可能 |
| ファイル読み書き | 可能 | 可能 |
今回のアイデアは単純。CLI でテスト計画を作り、Desktop でテストを実行する。 2 つの Claude を組み合わせるワークフロー。
全体の流れ
9 フェーズのテスト構成
31 画面を一気に渡すと Cowork が混乱する。だから 画面カテゴリごとにフェーズを分割 した。
| フェーズ | 対象 | 画面数 |
|---|---|---|
| Phase 1 | ナビゲーション + レイアウト | 4 |
| Phase 2 | ダッシュボード + カレンダー | 2 |
| Phase 3 | クライアント管理 | 4 |
| Phase 4 | パートナー管理 | 4 |
| Phase 5 | 案件管理（★最重要） | 4 |
| Phase 6 | 単価管理 | 2 |
| Phase 7 | マスタ管理 | 4 |
| Phase 8 | エビデンスメール + 承認 + 請求管理 | 4 |
| Phase 9 | ユーザー管理 + 設定 | 2 |
| 最終 | 総合レポート作成 | — |
各フェーズで Cowork がやることは同じ:
- 指定 URL にアクセス
- PC 表示（1280px）でスクショ撮影
- スマホ表示（390px）でスクショ撮影
- チェックリストの各項目を目視確認
- 結果をテーブル形式で報告
Phase 5（案件管理）に「★★★最重要画面★★★」と書いた。 アプリで最も複雑な画面だから。Cowork に「ここは特に入念にチェックしてください」と伝えると、実際にチェック項目が増える。AI にも優先度は伝わる。
深掘り①：テスト計画は CLI で自動生成する
31 画面分のテスト手順を人間が手書きする？ それこそ AI の仕事。
Claude Code CLI に既存のフロントエンドコードを読ませて、テスト計画を3つのファイルとして自動生成した。
生成した 3 ファイル
docs/
├── e2e-test-plan.csv # テスト項目一覧（スプレッドシート用）
├── e2e-cowork-guide.md # 詳細テスト手順書
└── cowork-prompts.md # ★ Cowork に渡す実行用プロンプト
| ファイル | 用途 | 行数 |
|---|---|---|
e2e-test-plan.csv |
テスト項目 ID・画面・手順・期待値の一覧 | 約 130 行 |
e2e-cowork-guide.md |
人間向け詳細テスト手順書 | 約 500 行 |
cowork-prompts.md |
Cowork が直接読んで実行するプロンプト | 590 行 |
ポイントは cowork-prompts.md。 このファイルだけで Cowork がテストを実行できるように設計した。テスト仕様 + 全 9 フェーズの手順 + レポートフォーマットを1ファイルに凝縮。
CLI がコードから何を読み取るか
たとえば sidebar.tsx の navigation 配列を読めば、メニュー項目が 10 個あることがわかる。billing-portals/page.tsx を読めば、2 タブ構成でパスワードマスク UI があることがわかる。
コードが仕様書。 だからテスト計画もコードから生成できる。
深掘り②：Cowork への渡し方——「ファイル1つ渡すだけ」に至るまで
最初は フェーズごとにコピペ するワークフローを想定していた。
Phase 1 のプロンプトをコピー → Cowork に貼り付け → 結果を待つ → Phase 2 をコピー → ……
9 フェーズ分これをやる？ ダルすぎる。
「ファイルのパスを渡すだけで全フェーズ実行できないの？」
できた。Cowork はローカルファイルを読める。だから 1 行のプロンプト で全フェーズを自動実行させられる。
Cowork に渡す実際のプロンプト（これだけ）
/Users/.../docs/cowork-prompts.md を読んで、
記載されている全フェーズのE2Eテスト+UI崩れチェックを順番に実行してください。
各フェーズ完了ごとに結果を報告し、
全フェーズ完了後に総合レポートを docs/e2e-test-report.md に保存してください。
1 行。 あとは Cowork が 590 行のプロンプトファイルを読み、9 フェーズを順番に実行し、レポートを書いてくれる。
ファイル設計のコツ
最初のバージョンでは各フェーズをコードブロック（```）で囲んでいた。コピペ前提の設計。
ファイル渡し方式に変えるとき、以下を修正:
-
```を全削除（Cowork がそのまま読めるように） -
【Phase N: タイトル】の冗長なヘッダーを## Phase N: タイトルに統一 - 先頭に「テスト仕様」セクションを追加（共通の観点・報告フォーマットを1箇所に集約）
人間の操作: コピペ 9 回 → 1 行入力 1 回。
深掘り③：Cowork が見つけた 7 つのバグ
約 40 分後、Cowork から総合レポートが届いた。
バグ一覧
| # | 重要度 | 画面 | 表示 | 問題内容 |
|---|---|---|---|---|
| BUG-001 | High | サイドバー | スマホ | ユーザーアバターがメインコンテンツに重なる |
| BUG-002 | Medium | ダッシュボード | 両方 | フィルタボタンが重なることがある |
| BUG-003 | Medium | カレンダー | PC | アジェンダが右側ではなく下部に表示 |
| BUG-004 | Low | 請求管理 | 両方 | パンくずが英語表記（"billing-portals"） |
| BUG-005 | Low | サイドバー | PC | viewer ロールで管理メニューが非表示 |
| BUG-006 | Low | サイドバー | PC | メニュー折り畳み時にツールチップが出ない |
| BUG-007 | Low | エビデンスメール | 両方 | 行クリックでモーダルが開かない |
7 件。でもこの全部が本当のバグなのか？
深掘り④：バグトリアージ——AI の報告を鵜呑みにしない
ここが一番重要なパート。 Cowork の報告を鵜呑みにしてはいけない。AI は「仕様」を知らないから、意図的な挙動もバグとして報告する。
Claude Code CLI に各バグの根本原因を調査させた。結果:
トリアージ結果
| バグ | 判定 | 根拠 |
|---|---|---|
| BUG-001 | 本物のバグ |
SheetContent の flex レイアウトで mt-auto が効かず、アバターがドロワー外に押し出される |
| BUG-002 | 修正済み | 直近のコミットで修正対応済み |
| BUG-003 | 本物のバグ |
CalendarGrid と CalendarAgenda が別の <div> に入っていて、水平配置の flex/grid がない |
| BUG-004 | 本物のバグ |
breadcrumb.tsx の pathLabels に 'billing-portals' エントリが未追加 |
| BUG-005 | 仕様通り | viewer ロールは管理メニューが非表示になるのが正しい動作 |
| BUG-006 | 仕様通り | 折り畳みではなくホバー展開方式を採用。ツールチップは不要 |
| BUG-007 | 設計判断 | Eye ボタンでモーダルを開く設計。行クリックは意図的に実装していない |
7 件中 3 件が本物のバグ。 残り 4 件は仕様通り・既修正・設計判断。
この「トリアージ」のプロセスが大事。Cowork に「テスト実行」を任せ、Claude Code CLI に「バグの真偽判定」を任せる。 2 つの AI の役割分担。
深掘り⑤：見つかったバグの根本原因
3 件の本物のバグについて、Claude Code CLI が特定した根本原因を紹介します。
BUG-001: サイドバーのアバターがメインコンテンツに重なる（High）
症状: スマホ表示でハンバーガーメニューを開くと、ユーザーアバターがサイドバーのドロワーからはみ出してメインコンテンツ領域に重なる。
原因: sidebar.tsx の SidebarUserMenu コンポーネントに mt-auto が指定されているが、SheetContent（shadcn/ui の Sheet）内の flex レイアウトで overflow-y-auto との組み合わせにより、コンテンツが多い場合にアバターがドロワーの境界外に押し出される。
sidebar.tsx
└── SheetContent (side="left", w-64)
└── div.flex.flex-col.h-full.overflow-y-auto
├── SidebarNav (flex-1)
│ ├── Logo
│ ├── nav items (10個 + 区切り + 承認 + 管理)
│ └── ... ← ここが長くなると
└── SidebarUserMenu (mt-auto) ← はみ出す
BUG-003: カレンダーのアジェンダが下に落ちる（Medium）
症状: PC 表示でカレンダーの右側にアジェンダパネルが表示されるはずが、カレンダーの下に表示される。
原因: calendar/page.tsx の CalendarGrid と CalendarAgenda がそれぞれ独立した <div> に入っており、親要素に水平配置の flex や grid が指定されていない。
BUG-004: パンくずが英語表記（Low）
症状: /billing-portals ページのパンくずリストに「billing-portals」と英語のパスセグメントがそのまま表示される。
原因: breadcrumb.tsx の pathLabels マッピングに 'billing-portals': '請求管理' のエントリが未追加。新しくページを追加した際に、パンくずのラベル登録を忘れた。
3 つとも、手動テストで気づけたはずのバグ。 でも気づかなかった。PC で開発していると、スマホ幅での確認は後回しになるから。
深掘り⑥：バグ発見 → Issue 作成を CLI で一気通貫
バグのトリアージが終わったら、そのまま Claude Code CLI で GitHub Issue を作成。
👤: /create-issue
CLI のカスタムスキル /create-issue が起動し、3 つの Issue を自動作成:
| # | タイトル | 重要度 | ラベル |
|---|---|---|---|
| 1 | スマホ表示でサイドバーのユーザーアバターがメインコンテンツに重なる | High | bug |
| 2 | カレンダーPC表示でアジェンダが右側ではなく下部に表示される | Medium | bug |
| 3 | パンくずが英語表記のまま | Low | bug |
各 Issue には再現手順・期待動作・実際の動作・根本原因の仮説が自動で記載される。Cowork のスクショ + CLI の原因調査結果をまとめて Issue 化。
このあとは /solve <Issue番号> と打てば、Issue の内容を読んで修正 PR まで全自動で作ってくれる。発見 → 調査 → Issue → 修正 → PR の全工程が AI で完結する。
テストプロンプト設計のコツ
590 行のプロンプトを書くにあたって、気をつけたポイント。
1. 共通観点を冒頭にまとめる
全画面に共通するチェック観点（テキストはみ出し、タッチターゲット 44px 以上、ダークモード等）は冒頭の「テスト仕様」セクションに1箇所だけ書く。フェーズごとに繰り返さない。
2. 画面固有のチェック項目は具体的に
「テーブルが正しく表示される」ではなく「テーブル（案件名・クライアント・URL・ログインID・パスワード・支払サイクル・備考）が表示される」と 列名まで書く。 Cowork は具体的な指示ほど正確にチェックする。
3. 重要度を明示する
■ 画面3: 案件詳細（★★★最重要画面★★★）
これはアプリで最も複雑な画面です。特に入念にチェックしてください。
「★★★」と書くのは大げさに見えるが、実際に効果がある。Cowork のチェック密度が上がる。
4. 報告フォーマットを指定する
| チェック項目 | PC | スマホ | 備考 |
|---|---|---|---|
| [項目名] | ✅ or ❌ | ✅ or ❌ | [問題があれば詳細] |
フォーマットを指定しないと、Cowork が自由形式で報告してくる。後からトリアージしにくい。テーブル形式を強制すると、✅/❌ が一目でわかる。
5. レポートの保存先を指定する
総合レポートを docs/e2e-test-report.md として保存してください。
これを書かないと、Cowork はチャット内で報告して終わり。ファイルに保存させれば、後から CLI で読める。
認証の壁——Cowork の唯一の弱点
1 つだけ、Cowork に できないこと がある。
Google OAuth ログイン。
このアプリは社内ドメインの Google アカウントでしかログインできない。Cowork は Google のログインフォームを操作できない（CAPTCHA や 2 要素認証があるため）。
回避策: 人間が先にログインしておく。
1. pnpm dev でアプリを起動
2. ブラウザで http://localhost:3000 にアクセス
3. 人間が Google OAuth でログイン ← ここだけ手動
4. ログイン済みの状態で Cowork にバトンタッチ
セッション Cookie が残っているので、Cowork はそのまま全画面にアクセスできる。最初の 10 秒だけ人間が操作すれば、残り 40 分は AI が自律実行。
実際のディレクトリ構造
今回のテストで使用・生成されたファイル:
docs/
├── cowork-prompts.md # ★ Cowork に渡す590行のプロンプト
├── e2e-test-plan.csv # テスト項目一覧（130行）
├── e2e-cowork-guide.md # 人間向け詳細手順書
└── e2e-test-report.md # ★ Cowork が生成したレポート
.claude/
├── skills/
│ ├── create-issue/ # Issue 自動作成スキル
│ └── solve/ # Issue → PR 全自動スキル
└── rules/
└── auto-decide.md # 自律判断ルール
人間が書いたファイル: 0。 全て Claude Code CLI が生成し、Cowork がテストを実行し、レポートも Cowork が書いた。
再現手順：あなたのプロジェクトでも試す方法
Step 1: テストプロンプトを CLI で生成する
Claude Code CLI に以下のように依頼:
フロントエンドの全画面を対象に、E2E テスト + UI 崩れチェック用の
プロンプトファイルを作ってください。
Cowork がファイルを読んでそのまま実行できる形式で。
PC（1280px）とスマホ（390px）の両方をチェックする構成にしてください。
CLI がフロントエンドのコードを読んで、画面一覧・チェック項目・報告フォーマットを含むプロンプトファイルを生成してくれる。
Step 2: アプリを起動してログイン
pnpm dev
# ブラウザで http://localhost:3000 にアクセスしてログイン
Step 3: Cowork にファイルパスを渡す
/path/to/your/docs/cowork-prompts.md を読んで、
記載されている全フェーズの E2E テスト + UI 崩れチェックを順番に実行してください。
各フェーズ完了ごとに結果を報告し、
全フェーズ完了後に総合レポートを docs/e2e-test-report.md に保存してください。
Step 4: レポートを CLI でトリアージ
Cowork のレポートを Claude Code CLI に渡して、各バグの真偽を判定させる。
docs/e2e-test-report.md を読んで、報告されたバグそれぞれについて
コードベースを調査し、本物のバグか仕様通りかをトリアージしてください。
やってみて気づいたこと
予想通りだったこと
- スマホ表示のバグは本当に見落としやすい。 開発者は PC で開発するから、スマホ幅での確認がどうしても甘くなる。AI に任せると漏れがない。
- テスト計画の自動生成は効果的。 コードからチェック項目を生成するので、「この画面にはこのカラムがある」レベルの具体性がある。
- 報告フォーマットの統一は大事。 テーブル形式を指定しないと、Cowork の報告が自由形式になって後工程が面倒になる。
予想外だったこと
- Cowork は仕様を知らない。 「viewer ロールで管理メニューが非表示」をバグとして報告してきた。仕様通りの挙動なのに。テスト結果のトリアージは必ず必要。
- ファイル渡し方式が想像以上に楽。 最初はフェーズごとにコピペする前提で設計していたが、「ファイルパスを 1 行渡すだけ」に変えたら体験が劇的に改善した。
- CLI と Cowork の組み合わせが強い。 CLI 単体では画面を見れない。Cowork 単体ではコードを深く調査できない。2 つを組み合わせると「テスト実行 → 原因調査 → Issue 作成 → 修正」の全工程がカバーできる。
- 「★★★最重要★★★」は AI にも効く。 重要度マーカーを付けた画面では、Cowork のチェック密度が明らかに上がった。人間へのコミュニケーションと同じ手法が AI にも通用する。
まとめ
| 観点 | 評価 |
|---|---|
| 準備コスト | CLI でテスト計画を自動生成。30 分で 31 画面分 |
| 実行コスト | Cowork にファイルパスを渡すだけ。1 行で 9 フェーズ自動実行 |
| 検出精度 | 7 件報告 → 3 件が本物。偽陽性はトリアージで除去 |
| 見落とし防止 | PC 開発者が見逃すスマホバグを 確実に検出 |
| 再現性 | プロンプトファイルがあれば 何度でも同じテストを再実行 |
| 全工程自動化 | 発見 → 調査 → Issue → 修正 PR まで CLI + Cowork で完結 |
おわりに
正直、「AI に E2E テストを任せる」のは半信半疑だった。
スクショを撮って目視で確認するだけでしょ？ 人間がやっても同じじゃない？
同じじゃなかった。 人間は「多分大丈夫」で 31 画面中 20 画面をスキップする。AI は全画面を律儀に PC とスマホの両方で確認する。そして人間が「多分大丈夫」と思っていた画面からバグが見つかる。
サイドバーのアバターがメインコンテンツに重なるバグ。開発中に一度もスマホ幅でドロワーを開いたことがなかったから気づかなかった。Cowork は機械的に全画面を 390px でチェックしたから見つけた。
面倒な作業を AI に任せる。 それだけのことだが、「面倒だからやらなかった作業」が実行されるようになると、品質が変わる。
テストプロンプトは 590 行の Markdown ファイル 1 つ。プログラミング不要。日本語でチェック項目を書くだけ。
最初の一歩は「1 画面分のチェックリストを書いて Cowork に渡す」だけでいい。それで効果を実感したら、全画面に広げればいい。
31 画面 × PC/スマホ = 62 パターン。 手動なら半日。AI なら 40 分。そして人間より漏れがない。