目次

Claude CodeのまわりにMCP、CLI、Skills、Cloudflare、Playwrightなどの選択肢が並ぶイラスト

Claude Codeをかなり使うようになってきて、ふと思った。

「何か追加したら、もっと楽になるんじゃないか？」

今まではほぼ素のClaude Codeを使っていた。 そこでMCPの一覧や、他の人が使っているツールを調べ始めた。

最初は単純に、

「便利そうなMCPをいくつか入れれば、Claude Codeもその分便利になるだろう」

と思っていた。

でも調べて、実際に導入してみると、ちょっと違った。

最終的に入れたのは、

  • Playwright CLI + Skills
  • Cloudflare API MCP

の2つ。

逆に、検討したけど入れなかったものもある。

実際に個人サイト「ぽいもの本舗」を公開・運用しながら試してみて、今はこう考えている。

MCPを増やす = Claude Codeが便利になる、ではない。

まずPlaywright MCPを入れようと思った

最初に欲しかったのは、ブラウザ操作だった。

Claude Codeにサイトを実装してもらった後、

  • PCで崩れていないか
  • スマホで崩れていないか
  • 横スクロールが発生していないか
  • JavaScriptエラーが出ていないか
  • リンクがちゃんと動くか
  • スクリーンショットを撮って確認する

といった作業を任せたかった。

そこで最初に候補になったのがPlaywright MCP。

ただ、調べてみると、Playwright公式では、Claude Codeのようなcoding agentにはPlaywright CLIが向いていると案内されている。

しかもCLIと一緒にSkillsをインストールできる。

Playwright MCPを常時接続するのではなく、

「ブラウザ操作が必要なときに、Claude CodeがSkillを読んでCLIを使う」

という形にできる。

これは自分の使い方にはかなり合っていた。

Playwright CLI + Skillsを入れてみた

導入自体もClaude Codeに任せた。

グローバルにPlaywright CLIを入れ、Claude Code用のSkillもホームディレクトリにインストール。

その後Claude Codeを再起動すると、Playwright Skillを認識するようになった。

実際に「ぽいもの本舗」を確認させてみると、

  • Desktop / Mobileの両方で表示確認
  • title取得
  • JavaScriptエラー確認
  • 横スクロール確認
  • Heroの高さ確認
  • Canvasアニメーションの動作確認
  • screenshot取得

まで自動でやってくれた。

さらに公開前の最終確認では、全ページをPCとスマホ幅で巡回し、

  • 404
  • ナビゲーション
  • 画像読み込み
  • 内部リンク
  • responsive
  • JavaScriptエラー

まで確認できた。

これはかなり便利だった。

今までなら、自分でページを開いてスクショを撮ってClaudeに見せていた部分を、かなり減らせる。

途中でちょっと問題も起きた

導入時に1つだけ変な挙動があった。

自分の環境はWindows + Node.js 24なのだが、

playwright-cli --help

や

playwright-cli --version

を実行すると、内容自体は正常に表示された後、終了処理でlibuvのassertionが発生した。

一瞬「導入失敗か？」と思った。

ただし、

  • open
  • goto
  • eval
  • screenshot
  • snapshot
  • close

など、実際のブラウザ操作はすべて正常。

最終的には、実運用に支障がないのでそのまま使うことにした。

こういう細かい相性問題は、実際に入れてみないと分からない。

次にCloudflareを楽にしたくなった

「ぽいもの本舗」はCloudflare Workers Static Assetsで公開している。

なので次は、

  • Workerの状態
  • Deployment
  • DNS
  • Custom Domain
  • Cloudflareの各種設定
  • セキュリティログ

などをClaude Codeから確認できるようにしたかった。

最初はCloudflare公式Pluginを丸ごと入れるつもりだった。

Cloudflare公式も、Skills / MCP / Wranglerを組み合わせる構成を案内している。

ただ、自分の場合はそこまで全部必要なのか？と思い、もう一度調べ直した。

そこで見つけたのがCloudflare API MCPのCode Modeだった。

Cloudflareは「全部入り」ではなくAPI MCPだけにした

Cloudflare API MCPは、Cloudflare APIを幅広く扱える。

普通なら大量のツール定義が必要になりそうだが、Code Modeでは主に

  • search
  • execute

という少数のツールから必要なAPIを探して実行する。

Cloudflare公式によると、2,500以上のAPIエンドポイントを、search / executeの2ツールを通して約1,000トークンのモデルコンテキストで扱える設計になっている。

これなら「Cloudflare用のツールを大量にClaude Codeへ載せる」という感じではない。

自分が欲しかったのも、

「Cloudflareの状態をClaude Codeから確認したい」

という部分だったので、公式Plugin一式は入れず、Cloudflare API MCPだけを追加した。

さらにOAuthはRead onlyで認証した。

これでClaude CodeはCloudflareを確認できるが、勝手にDNSやWorkerを書き換えることはできない。

この構成はかなり気に入っている。

なお、2026年8月時点でCloudflareはCode Modeをexperimentalとして案内しているため、今後仕様が変わる可能性はある。

入れた直後、本当に役に立った

Cloudflare API MCPを入れてすぐ、実際に問題が起きた。

Google Search Consoleへサイトマップを登録したところ、

「サイトマップを読み込めませんでした」

となり、HTTP 403が返っていた。

ブラウザからサイトマップを開くと普通に表示される。

最初は何が起きているのか分からなかった。

そこで、導入したばかりのCloudflare API MCPをRead onlyで使って調べてもらった。

Search ConsoleのHTTP 403をCloudflare API MCPで調査し、AI Trainingのブロック設定がGooglebotを止めていた原因を特定して解決した流れ

すると、Cloudflareの実ログから、

  • 本物のGooglebot
  • GoogleのASN
  • sitemap-index.xmlへのアクセス
  • firewallManagedによるblock
  • HTTP 403

というイベントを発見。

さらに設定を切り分けていくと、原因はCloudflareのAI Bot Policyだった。

「AI Trainingをブロック」がGooglebotまで止めていた

当初はAIクローラーについて、

  • Search：許可
  • Agent：許可
  • Training：ブロック

にしていた。

「AI学習だけ拒否して、検索は許可する」というつもりだった。

ところがCloudflareのTraining分類は、SearchとTrainingの両方で使われるmixed-purpose crawlerもブロック対象に含んでいる。

Googlebot自体がAI学習専用のクローラーというわけではない。

ただ実際のCloudflareのログでは、verifiedなGooglebotからのリクエストが403で止まっていた。

そのため今回は、Cloudflare側の分類と設定によってGooglebotまで巻き込まれた、と判断した。

しかもサイトマップだけではなく、全ページが対象だった。

放置していたらGooglebotがサイトをクロールできず、検索にも載らないところだった。

最終的にネットワーク側は、

  • Search：Allow
  • Agent：Allow
  • Training：Allow

へ変更。

AI学習拒否についてはManaged robots.txt側で、

ai-train=no

や学習系BotへのDisallowを表明する形にした。

Google-ExtendedはGoogle Searchとは別の制御トークンで、これをrobots.txtで拒否してもGoogle Searchへの掲載やランキングには影響しない。

変更後、Googlebotが200でページとサイトマップを取得できていることをCloudflareのログで確認。

Search Consoleのサイトマップも「成功しました」になった。

Cloudflare MCPを入れたその日に、普通に役に立った。

検討したけど入れなかったものもある

今回、便利そうなものを全部入れたわけではない。

Claude in Chrome

CloudflareやSearch Consoleのようなログイン済み画面をClaude Codeに操作させられるので、最初はかなり良さそうに見えた。

ただ、Chrome Web Storeの評価や不具合報告を調べて、今回は保留にした。

将来安定してきたら再検討する。

GitHub MCP

GitHub公式MCPもある。

ただ、自分のClaude Code環境ではすでにgitやgh CLIを使って、

  • pull
  • commit
  • push
  • 履歴確認

などができている。

今のところ、追加するメリットがそこまで大きくないと判断した。

Google Search Console MCP

Search Console用のMCPもいくつか存在する。

ただし2026年8月時点で、今回見つけた候補はコミュニティ製だった。

さらにサイトを公開した直後なので、そもそも分析する検索データがほとんどない。

これは1〜2週間以上データが溜まってから、必要ならread-onlyのものを改めて検討することにした。

今の使い分け

今回いろいろ調べて、実際に使ってみた結果、今はこんな感じで考えている。

CLIがあるなら、まずCLI + Skills

今回のPlaywrightがこれ。

Claude Codeが必要なときだけSkillを読み、CLIを使う。

常に大量のツールを抱える必要がない。

外部サービスのAPIを直接触りたいならMCP

Cloudflareはこれ。

Claude Codeだけでは取得できないアカウント内の情報をAPI経由で確認できる。

こういう用途はMCPのメリットが大きい。

書き込みが必要ないならread-only

Cloudflare API MCPも最初はRead onlyにした。

「確認したいだけ」なのにWrite権限まで与える必要はない。

必要になったときに考えればいい。

すでにCLIで足りているなら増やさない

GitHubがこれ。

便利そうだから追加するのではなく、

「今困っていることが、本当にこれで減るのか？」

で決めるようにした。

MCPを増やす = Claude Codeが便利になる、ではない

今回、最初は「Claude Codeに何を追加すればもっと便利になるんだろう」と考えていた。

そしてMCPを探し始めた。

でも実際には、

  • Playwright → MCPではなくCLI + Skills
  • Cloudflare → 全部入りPluginではなくAPI MCPだけ
  • GitHub → 既存CLIで十分
  • Search Console → 今はまだ入れない
  • Claude in Chrome → 安定性を見て保留

という結果になった。

結局大事なのは、MCPの数ではなかった。

MCPを増やす = Claude Codeが便利になる、ではない。

その作業に一番合った接続方法を選ぶ方がいい。

今回の自分の環境では、

  • ローカルで完結する操作 → CLI + Skills
  • 外部サービスのデータ → MCP
  • 状態確認だけ → read-only
  • すでにCLIで困っていない → 何も追加しない

という分け方がかなりしっくりきた。

まだ使い始めたばかりなので、今後変わるかもしれない。

でも少なくとも、「便利そうなMCPを片っ端から入れる」よりは、今の方がClaude Codeを扱いやすい。

しばらくこの構成で使ってみようと思う。