Claude Code × Playwright MCP で、競合調査を「眺めて終わり」から「営業提案の自動生成」に変えた話

Posted at 2026-04-11

競合サイト、ちゃんと見てますか？

——見てはいる。でも「見た」で終わっていませんか？

トップページを眺めて、サービスページを確認して、気になった点をSlackに貼って……それ、先週もやりましたよね。そして先週のメモ、もう誰も見ていませんよね。

この記事では、VS Code上で Claude Code と Playwright MCP を組み合わせて、公開ページの定点観測から営業提案用Markdownの生成までを1つの流れにする方法を紹介します。Claude Code は VS Code 拡張で使うのが推奨されており、IDE上でプラン確認、差分レビュー、会話履歴の利用などができます。Playwright MCP は、Playwright を使ったブラウザ自動化を MCP 経由で AI から扱える OSS のサーバーです。

プロンプトと出力テンプレートをそのまま載せているので、コピペで回せます。

この記事でやることは、単なる競合分析ではありません。

公開ページを観測する
→ 競合の見せ方・導線・品質面の特徴を整理する
→ 提案ネタへ変換する
→ 営業向け Markdown として保存する

という流れまでを、1つの運用として扱います。

この手法が向いているケース

このやり方は、次のような企業向けの提案材料を作る時に向いています。

Webサービス会社
アプリ運営会社
EC事業者
SaaS事業者
ゲーム会社

共通点は、継続的にUI変更やリリースがあり、品質事故が売上や継続率に直結しやすいことです。

例えば、次のような観測結果はそのまま提案の切り口になります。

問い合わせ導線が分かりにくい
→ 第三者検証提案
スマホ表示が窮屈
→ 多端末UI検証提案
CTAが弱い
→ UI/UX改善提案
実績訴求が弱い
→ 見せ方改善の比較分析提案

ここで大事なのは、競合サイトの感想を書いて終わらせないことです。
必ず「どの業種の、どの部門に、どの提案として持っていけるか」まで変換します。

なぜ Playwright MCP を使うのか

今回の目的は、定点観測です。

つまり必要なのは、ブラウザ内部の深い解析よりも、まず次のようなことです。

指定ページを毎回同じ条件で見る
CTAの有無を確認する
問い合わせ導線を確認する
スマホ相当表示で見え方を確認する
必要に応じてスクリーンショットを残す

Playwright は、Chromium / Firefox / WebKit を同じAPIで扱えます。さらにデバイスエミュレーションでは、userAgent、viewport、screenSize、hasTouch などをまとめて再現できます。フルページスクリーンショット取得も標準で扱えます。こうした性質は、競合サイトの週次観測と相性が良いです。

一方で、Chrome DevTools MCP が強いのは、Network、Console、Performance trace、DOM/CSS などの深掘りデバッグです。
そのため、次の役割分担が自然です。

週次の競合観測の主役: Playwright MCP
原因調査の深掘り要員: Chrome DevTools MCP

実行環境

今回は、次の前提で進めます。

VS Code を使っている
Claude Code を VS Code 上で使える状態にしている
Playwright MCP をインストール済み
調査対象は公開ページのみ
問い合わせフォームは送信しない
出力先は ~/Documents/competitor-watch

Claude Code は VS Code でも利用でき、VS Code 拡張の利用が推奨されています。

まず決めるべき観測対象

競合サイトを広く見すぎると、運用がすぐ重くなります。
最初は、各社について次の5カテゴリに絞るのが現実的です。

トップ
主力サービスページ
実績または事例ページ
問い合わせ導線ページ
採用または技術ブログ相当ページ

この5カテゴリに絞る理由は単純で、営業提案に必要な材料がほぼ揃うからです。

何を強く訴求しているか
どの導線を重視しているか
実績をどう見せているか
問い合わせしやすいか
更新や注力領域のシグナルがあるか

今回のゴール

今回のゴールは、次の3段です。

公開ページを観測する
自社向けの提案ネタに変換する
営業用 Markdown にまとめて保存する

つまり、競合調査そのものが目的ではなく、提案材料の下書きを毎回一定品質で作ることが目的です。

Claude Code に渡すプロンプト

以下のプロンプトを、VS Code上の Claude Code にそのまま渡せば使えます。
{自社名} や {競合URL} などのプレースホルダーは、ご自身の環境に合わせて書き換えてください。

Playwright MCPを使って、{自社名}の{事業名}向けの競合観測と、営業・提案に転用できるMarkdownレポートを作成してください。

対象企業:
- 競合A: {URL}
- 競合B: {URL}
- 競合C: {URL}

目的:
公開Webページを定点観測し、競合の見せ方・導線・品質面の特徴を整理したうえで、
{自社名}の営業担当者・提案書作成者がそのまま活用できる提案材料へ変換すること。

今回の営業先の前提:
狙うべき営業先は、以下のような、継続的にUI変更やリリースがあり、品質事故が売上や継続率に直結しやすい企業とする。
- Webサービス会社
- アプリ運営会社
- EC事業者
- SaaS事業者
- ゲーム会社

営業先に対する分析の考え方:
- 各競合の観測結果を、上記のどの営業先に刺さる提案へ転換できるかを考える
- 単なる競合分析で終わらせず、「どの業種」「どの部門」「どの課題」に提案できるかまで整理する
- 特に、開発部門、QA部門、プロダクト部門、Web運用部門、情報システム部門に刺さる論点を意識する
- 品質事故が売上、CVR、継続率、ユーザー体験、問い合わせ増加に影響しやすい文脈で提案機会を整理する

重要:
- 今回はページ数制限なし
- ただし冗長な説明は避け、営業資料として読みやすい構成にする
- 最初に要点を短くまとめ、その後に詳細を書く
- 競合調査で終わらせず、必ず{自社名}の提案機会に変換する

確認対象ページ:
- トップ
- 主力サービスページ
- 実績または事例ページ
- 問い合わせ導線ページ
- 採用または技術ブログ相当ページ

確認観点:
- 主要CTAの有無
- 訴求内容とその変化
- 実績・事例の見せ方
- 問い合わせ導線の分かりやすさ
- device emulationを使って、iPhone 13相当の表示条件でレイアウト崩れ、CTAの見え方、操作しづらさがないか
- {自社名}の提案ネタに転用できるか

実施ルール:
- Playwright MCPを使って公開ページのみ確認する
- 問い合わせフォームは送信しない
- 各社で重要ページを優先して巡回する
- device emulationを使って、iPhone 13相当の表示条件でも確認する
- 必要に応じてスクリーンショットを取得する
- 事実 / 解釈 / 提案 を明確に分ける
- 断定できない内容は「仮説」と明記する
- 主観的な感想ではなく、営業提案に使える示唆へ変換する
- 各競合について「何が強いか」だけでなく、「{自社名}が提案機会にできる点」も書く

提案ネタへの変換ルール:
- 問い合わせ導線が長い、分かりにくい
  → 導線・離脱観点の第三者検証提案
- レイアウト崩れや表示の窮屈さがある
  → 多端末UI検証提案
- CTAが弱い、見つけにくい、文言が曖昧
  → UI/UX観点を含む改善提案
- 実績や事例の見せ方が弱い
  → 実績訴求改善の比較分析提案
- サービス説明が広すぎて焦点がぼける
  → 訴求整理・品質観点整理の提案
- モバイル表示で操作しづらさがある
  → スマホ表示を含む実機観点・エミュレーション観点の検証提案
- 品質保証や第三者検証の見せ方が弱い
  → 第三者視点レビューと検証報告書支援の提案

営業先別の整理ルール:
- Webサービス会社向け:
  UI導線、会員登録、CV改善、問い合わせ導線、継続利用に関わる品質課題として整理する
- アプリ運営会社向け:
  多端末表示差分、リリース前検証、アップデート時の品質担保、継続率への影響として整理する
- EC事業者向け:
  商品詳細、カート、決済、問い合わせ導線、スマホUIの品質課題として整理する
- SaaS事業者向け:
  業務画面の使いやすさ、導入時の品質不安、サポート負荷、継続利用率への影響として整理する
- ゲーム会社向け:
  端末差分、不具合発見、ユーザー体験低下、リリース前の品質保証として整理する

出力方針:
- 営業担当者が「どの業種の、どの部門に、何を切り口に話すか」が分かるようにする
- 提案書作成者が「どの課題に対して何を提案するか」を流用できるようにする
- 競合ごとの観測結果だけでなく、競合横断の比較も入れる
- 自社の勝ち筋、差別化ポイント、提案機会を明確にする
- 優先度を High / Medium / Low で付ける
- すぐ使える営業トークの叩き台も含める
- 推測は必ず「仮説」と明記する

最終成果物:
- 営業・提案用Markdownレポートを作成する
- レポートは画面上に出力するだけでなく、~/Documents/competitor-watch 配下に Markdown ファイルとして保存する
- 保存ファイル名は日付が分かる形式にする（例: 2026-04-11_competitor_report.md）
- 可能であれば、同時に latest_competitor_report.md も更新する

ここで効いているポイント

このプロンプトで重要なのは、次の4点です。

1. 「調査して」で終わらせていない

単なるサイト確認ではなく、営業提案へ変換することまで明示しています。
これで、単なる観測メモで終わりにくくなります。

2. 確認対象ページを固定している

トップから全部見に行くのではなく、5カテゴリに絞っています。
これで毎週回しやすくなります。

3. モバイル確認を曖昧にしていない

「モバイル表示を見る」ではなく、iPhone 13相当の device emulation と書いています。
Playwright のエミュレーションは、端末プロファイルに基づいてブラウザ挙動を再現できます。

4. 出力先まで指定している

その場のチャット出力だけでなく、~/Documents/competitor-watch に Markdown 保存するようにしています。
これで履歴として蓄積できます。

出力する Markdown の形も固定しておく

出力フォーマットも先に固定しておくと、毎回の品質がかなり安定します。

# {自社名} 競合観測レポート（YYYY-MM-DD）

## 0. エグゼクティブサマリー
- 今回の観測で重要だった点を3〜5項目で要約
- 自社にとっての主要な提案機会を要約
- まず営業で使うべき論点を要約

## 1. 今週の重要変化
### 競合A
-
### 競合B
-
### 競合C
-

## 2. 競合別の観測事実
### 競合A
#### 事実
-
#### 解釈
-
#### 提案ネタ
-
#### 刺さりやすい営業先
-
#### 刺さりやすい部門
-
#### 優先度
- High / Medium / Low

### 競合B
#### 事実
-
#### 解釈
-
#### 提案ネタ
-
#### 刺さりやすい営業先
-
#### 刺さりやすい部門
-
#### 優先度
- High / Medium / Low

### 競合C
#### 事実
-
#### 解釈
-
#### 提案ネタ
-
#### 刺さりやすい営業先
-
#### 刺さりやすい部門
-
#### 優先度
- High / Medium / Low

## 3. 競合横断の比較
### 共通して強い点
-
### 共通して弱い、または改善余地がありそうな点
-
### 自社が差別化しやすいポイント
-
### 仮説ベースで継続監視すべき点
-

## 4. 営業先別の提案機会
### Webサービス会社向け
- 想定課題:
- 提案切り口:
- 自社が提供できる支援:
- 刺さりやすい部門:
- 優先度:

### アプリ運営会社向け
- 想定課題:
- 提案切り口:
- 自社が提供できる支援:
- 刺さりやすい部門:
- 優先度:

### EC事業者向け
- 想定課題:
- 提案切り口:
- 自社が提供できる支援:
- 刺さりやすい部門:
- 優先度:

### SaaS事業者向け
- 想定課題:
- 提案切り口:
- 自社が提供できる支援:
- 刺さりやすい部門:
- 優先度:

### ゲーム会社向け
- 想定課題:
- 提案切り口:
- 自社が提供できる支援:
- 刺さりやすい部門:
- 優先度:

## 5. 営業・提案機会
### すぐ提案に使えるテーマ
- テーマ:
  - 根拠:
  - 提案できる支援:
  - 想定顧客:
  - 想定部門:
  - 優先度:

### 中長期で育てるテーマ
- テーマ:
  - 根拠:
  - 提案できる支援:
  - 想定顧客:
  - 想定部門:
  - 優先度:

## 6. 営業トークの叩き台
-
-
-

## 7. 次週も継続確認する点
-
-
-

## 8. 補足
- スクリーンショットや確認URLがあれば列挙
- 断定できない事項は「仮説」として整理

実際に回してみて感じたメリット

このやり方のメリットは、競合調査が再利用可能な作業に変わることです。

従来は、

毎回見方がぶれる
メモの粒度が一定しない
提案に変換する時にもう一度考え直す

ということが起きがちでした。

でも、プロンプトと出力フォーマットを固定すると、

見るページが固定される
見る観点が固定される
提案への変換ルールが固定される
Markdownとして蓄積される

ので、毎週の質が安定しやすくなります。

注意点

この手法は、公開ページの観測 を前提にしています。

問い合わせフォームは送信しない
ログイン必須領域には入らない
過剰なアクセスをしない
事実と仮説を分ける

また、Playwright MCP の README では、これは Playwright の MCP インターフェースであり、coding agent の用途では CLI+SKILLS の方が向く場合もある と説明されています。つまり、用途によっては Playwright MCP 一択ではありません。ただ、今回のような「VS Code上で競合サイトを観測し、レポートまで作る」流れでは十分実用的です。

まとめ

VS Code上で Claude Code と Playwright MCP を使うと、競合サイト調査を

眺める
メモする
提案に使うために再整理する

という曖昧な流れから、

公開ページを定点観測する
iPhone 13相当でも確認する
CTAや導線を観測する
提案ネタへ変換する
Markdownとして保存する

という再利用しやすい流れに変えられます。

競合調査を「調査」で終わらせず、営業提案の下書き生成フロー に変えたい時には、かなり相性の良い方法です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up