Claude Codeで競合分析をしようとしたとき、
「Playwright MCPだけでいいのか？」
「Chrome DevTools MCPは何が違うのか？」
「結局どれを使えばいいのか分からない」
と迷ったことはありませんか？
私自身も同じ疑問を持ち、複数のMCPを実際に試した結果、
競合分析においてはChrome DevTools MCPの方が適しているケースが多いと分かりました。
この記事では、
・Playwright MCPとChrome DevTools MCPの違い
・競合分析における最適な使い分け
・すぐに使える実践プロンプト
を整理しています。
この記事でやること
- Claude Code に Chrome DevTools MCP を追加する
- 追加後に状態を確認する
- Playwright MCP がすでに入っている環境で、競合分析時は Chrome DevTools MCP を使うようにする
- 競合分析用の3本のプロンプトを、そのまま使える形でまとめる
前提
この記事は、以下の前提です。
- Claude Code を利用している
- Playwright MCP はすでに導入済み
- 今回は追加で Chrome DevTools MCP を導入する
- 競合分析では、Chrome DevTools MCP を優先的に使う
Playwright MCP が入っている環境でも、プロンプト側で使うツールを明示しておくと運用しやすくなります。
1. Chrome DevTools MCP のインストール
まずは Chrome DevTools MCP を追加します。
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest
これで、Claude Code から Chrome を使った確認や分析を行いやすくなります。
2. インストール後の確認方法
追加できたかは、次のコマンドで確認できます。
claude mcp list
特定サーバーの詳細を見たい場合は、次を使います。
claude mcp get chrome-devtools
claude mcp get playwright
Claude Code のセッション内では、次のコマンドでサーバー状態を確認できます。
/mcp
ここで chrome-devtools が見えていれば、まず登録確認はできています。
3. 競合分析では Chrome DevTools MCP を使う前提にする
今回は Playwright MCP がすでに入っている環境を前提にしています。
そのため、何も書かずにプロンプトを投げると、どちらの MCP を使うかが曖昧になることがあります。
そこで、競合分析用のプロンプトでは、先頭に次の一文を入れます。
この分析では Chrome DevTools MCP を使ってください。
Playwright MCP は使わないでください。
これを入れておくことで、競合分析時の意図がぶれにくくなります。
4. 動作確認用の最小テスト
最初の確認としては、次のような短いプロンプトで十分です。
Check the performance of https://developers.chrome.com
これで Chrome を使った確認が動けば、ひとまず準備完了です。
5. 競合分析用プロンプト その1: 新規獲得導線 比較
公開記事では、固有名詞を避けてプレースホルダー化しておくのが安全です。
実際に使うときは、自分の調査対象 URL に置き換えてください。
この分析では Chrome DevTools MCP を使ってください。
Playwright MCP は使わないでください。
分析対象はiPhone 13相当での表示を中心にしてください。
必要に応じて以下を実施してください。
- スクリーンショット取得
- CTA確認
- ネットワーク確認
- 表示速度確認
- Lighthouse観点での確認
以下の対象サイトを巡回し、新規ユーザー獲得の観点で比較分析してください。
対象:
- 自社サービス: [自社サービスURL]
- 競合A: [競合AのURL]
- 競合B: [競合BのURL]
- 競合C: [競合CのURL]
- 競合D: [競合DのURL]
調査目的:
- 自社アプリ / 自社サービスの新規獲得導線改善に活かせる示唆を抽出すること
- 特に「初回訪問から会員登録・コンテンツ閲覧・購入意欲形成まで」の導線設計を比較すること
確認観点:
1. ファーストビューで何を訴求しているか
2. 会員登録やログイン導線の見つけやすさ
3. 無料・クーポン・ポイント・初回特典の見せ方
4. CTAの位置、文言、数、押しやすさ
5. 詳細ページやランキングページへの到達しやすさ
6. 離脱しやすい箇所、迷いやすい箇所
7. iPhone 13相当での表示での視認性、情報量、スクロール負荷
8. 自社が取り入れる価値の高い導線設計
出力ルール:
- 事実 / 観測結果 / 仮説 / 推奨対応 を明確に分ける
- 推測は断定せず「仮説」と明記する
- 各サイトについて、強み・弱みを簡潔に整理する
- 最後に「自社アプリ向け改善案」を優先度つきで5件出す
- 改善案は、できるだけ「なぜ有効か」まで書く
- 可能ならスクリーンショットや確認根拠も添える
- 可能なら会員登録導線、無料導線、ランキング導線、詳細導線の4観点で比較する
出力形式:
# 1. 事実
# 2. 観測結果
# 3. 仮説
# 4. 競合別比較
# 5. 自社アプリ向け改善案（優先度つき）
6. 競合分析用プロンプト その2: 詳細ページ・無料体験・購買導線 比較
この分析では Chrome DevTools MCP を使ってください。
Playwright MCP は使わないでください。
分析対象はiPhone 13相当での表示を中心にしてください。
必要に応じて以下を実施してください。
- スクリーンショット取得
- CTA確認
- ネットワーク確認
- 表示速度確認
- ファーストビュー確認
以下の対象サイトを巡回し、詳細ページから無料体験・購入意欲形成までの導線を比較分析してください。
比較対象:
- 同一カテゴリ内で比較しやすい代表コンテンツを1つ選ぶ
- 競合によっては「単体販売」より「話読み / 無料導線 / 待てば無料導線」が前面に出る可能性があるため、厳密な同一販売形態比較ではなく、「詳細ページから読ませる・欲しくさせる体験比較」として扱う
対象:
- 自社サービス: [自社詳細ページURL]
- 競合A: [競合Aの詳細ページURL]
- 競合B: [競合Bの詳細ページURL]
- 競合C: [競合Cの詳細ページURL]
- 競合D: [競合Dの詳細ページURL]
調査目的:
- 自社アプリ / 自社サービスの詳細ページ改善に活かせる示唆を抽出すること
- 特に「無料体験」「購入判断」「回遊促進」の設計差を明らかにすること
確認観点:
1. ファーストビューで見える情報
2. サムネイル、レビュー、説明文、巻数、価格、特典の配置
3. 無料体験ボタンの位置・文言・目立ちやすさ
4. 購入ボタンやカート導線の配置と優先順位
5. 続編、関連コンテンツ、同作者作品への導線
6. セール、割引、ポイント還元、期間限定訴求の見せ方
7. 情報量が多すぎて判断しづらくなっていないか
8. 購買意欲を高める要素が何か
9. 自社より優れている体験があるか
追加ルール:
- 競合によっては、無料話・待てば無料・話単位導線の見せ方も重要な比較対象とする
- 「無料で読ませる力」と「購入したくさせる力」を分けて評価する
出力ルール:
- 事実 / 観測結果 / 仮説 / 推奨対応 を明確に分ける
- 競合ごとに「購入したくなる理由」と「迷う理由」を整理する
- 最後に、自社アプリ向けの改善案を
- すぐできるもの
- 中規模改修が必要なもの
に分けて提案する
- 可能なら各改善案に、想定効果（CV改善 / 回遊改善 / 無料体験促進 など）を付ける
- 可能なら「詳細ページのファーストビュー改善案」も最後にまとめる
出力形式:
# 1. 事実
# 2. 観測結果
# 3. 仮説
# 4. 競合別比較
# 5. 自社アプリ向け改善案
## 5-1. すぐできるもの
## 5-2. 中規模改修が必要なもの
## 5-3. ファーストビュー改善案
7. 競合分析用プロンプト その3: 回遊・継続利用・発見性 比較
この分析では Chrome DevTools MCP を使ってください。
Playwright MCP は使わないでください。
分析対象はiPhone 13相当での表示を中心にしてください。
必要に応じて以下を実施してください。
- スクリーンショット取得
- 導線確認
- ネットワーク確認
- 表示速度確認
- 主要画面の回遊フロー確認
以下の対象サイトを巡回し、ユーザーがコンテンツを見つけ続け、回遊し続ける仕組みを比較分析してください。
対象:
- 自社サービス: [自社サービスURL]
- 競合A: [競合AのURL]
- 競合B: [競合BのURL]
- 競合C: [競合CのURL]
- 競合D: [競合DのURL]
調査目的:
- 自社アプリ / 自社サービスの回遊性・発見性・継続利用率向上に活かせる示唆を抽出すること
- 特に「ランキング」「検索」「ジャンル」「レコメンド」「まとめ導線」の設計差を比較すること
確認観点:
1. ホーム画面やトップページでコンテンツを発見しやすいか
2. ランキング、特集、ジャンル導線の分かりやすさ
3. 検索機能や絞り込み機能の使いやすさ
4. レコメンドの質と配置
5. 続きを見たくなる導線設計
6. コンテンツから別コンテンツへ自然に遷移できるか
7. キャンペーン導線と通常導線のバランス
8. 回遊を邪魔する要素があるか
9. 自社が弱い箇所、競合が強い箇所
追加ルール:
- 可能ならトップページだけでなく、ランキング、無料導線、ジャンル導線まで1階層以上たどって比較する
- 無料起点の継続利用設計が強いサービスは重点的に見る
- セール・無料・購入導線の混在バランスも確認する
- 検索起点の発見性と、レコメンド起点の回遊性を分けて見る
出力ルール:
- 事実 / 観測結果 / 仮説 / 推奨対応 を明確に分ける
- 各サイトについて「回遊しやすい理由」を3点以内で整理する
- 最後に、自社アプリ向けに
1. 発見性改善
2. 回遊性改善
3. 継続利用改善
の3カテゴリで改善案を出す
- 改善案は優先度つきで出す
- 可能なら、アプリUIに落とし込んだ場合の実装イメージも簡潔に添える
出力形式:
# 1. 事実
# 2. 観測結果
# 3. 仮説
# 4. 競合別比較
# 5. 自社アプリ向け改善案
## 5-1. 発見性改善
## 5-2. 回遊性改善
## 5-3. 継続利用改善
8. なぜ今回は Chrome DevTools MCP を前面に出しているのか
Playwright MCP が入っている環境でも、今回の3本は 競合サイトの見え方、導線、読み込み、ネットワーク、スクリーンショット、表示速度 をまとめて確認したい用途です。
そのため、今回は Chrome DevTools MCP を前面に出す構成にしています。
つまり、役割分担としては次のイメージです。
-
Chrome DevTools MCP
探索的な競合分析、表示確認、速度確認、スクリーンショット確認向け -
Playwright MCP
同じ手順の繰り返し確認、定型テスト、再現性重視の確認向け
9. 注意点
外部サイトを対象に調査する場合は、次の点に注意した方が安全です。
- ログイン状態のまま調査しない
- 個人情報や機密情報が表示される状態で使わない
- 取得したスクリーンショットやログの扱いに注意する
- 公開記事では、自社名・アプリ名・競合名をそのまま書かない
公開記事では、今回のように プレースホルダー化しておくと扱いやすいです。
まとめ
今回は、Playwright MCP はすでに導入済みの環境を前提に、追加で Chrome DevTools MCP を導入し、競合分析時には Chrome DevTools MCP を使う構成を整理しました。