MCPの使いどきを考える 前編 : playwright-mcpの使い道にちょっと気付いた話
世はまさに大MCP時代
ブンブンハローAnthropic、どうもAI驚き屋です。皆さん、MCP触ってますか？
MCP(Model Context Protocol)は「AIのUSBポート」とも例えられる、様々なクライアントからアプリケーションにアクセスする際の共通プロトコルを定義するものです。
「AIとアプリがそれぞれMCPに対応してたらなんでも組み合わせられちゃうよ〜ん」みたいな、そんな規格になっています。ちなみにMCPで実際に通信を行うサーバをMCPサーバといいます。
MCPはClaudeを開発したAnthropicが提示した規格ですが、ここ数ヶ月でバズりすぎてOpenAIも相乗りするほどのブームになっています。
おそらくMCPはAIとアプリをつなぐ方法として業界のデファクトスタンダードになっていくことでしょう。
https://www.itmedia.co.jp/aiplus/articles/2503/27/news174.html
playwright-mcpを数日使っての気付き
ところで、以前テスト自動化ツールであるPlaywrightのMCPサーバであるplaywright-mcpを試したとき、
「playwright-mcpを使うならスクリプティングでいいケースが多そうで、使い道が思いつかんなあ」みたいな記事を書きました。
この記事を書いたときは実はMCP自体をあまり触ったことなかったので、そこから数日、いろいろ触ったりして試してみました。
結果、現在ではちょっとずつ意見が変わってきました。具体的には以下のような見解になってきています。
- playwright-mcpは「スクリプティングが面倒なときか、スクリプティングの知見がないとき」に便利っぽい
- MCP・CLI・APIベースのスクリプティングなど、アプリケーションへのアクセス手段は多分使い分けるものっぽい
- その使い分けは利用者の能力・用途・アプリ側のインターフェースの実装や複雑さなどの要素によって、適切な選択がケースバイケースで変わるっぽい
この記事は前編ということで、1・2の内容に限定し、どんなケースでplaywright-mcpが便利だったか、そこから得た気付きをまとめてみようと思います。
playwright-mcpが便利だったケース
これplaywright-mcpあると楽かも、となった具体的なシーンとして、
「JSTQBのシラバスページから、それぞれ最新のシラバスだけ取ってきてファイル名をリスト化して」というものがありました。
https://jstqb.jp/syllabus.html
JSTQBのシラバスページは1ページに複数のシラバスの新旧版が併記されています。
このうち各シラバスの最新版だけを一度だけDLしたいと思ったとき、どうするかなあとなりました。
普通にいったらブラウザでポチポチDLしていくと思います。APIもないし、1回こっきりだし、「最新」のロジックもよくわからないしで、スクリプト化はつらそうです。
このとき、「あ、playwight-mcpでデータフェッチすれば最新版のシラバスのリスト出せそうかも」というアイデアに思い至りました。
そこで書いたのが下のシンプルなスクリプトです。
Playwrightを使って指定されたURLにアクセスし、それぞれのシラバスの最新版のファイル名を取得してください。
その後、各シラバスをDLしてください。
実際playwright-mcpによるファイル名の一覧取得はうまくいき、面倒なポチポチ作業なしに爆速でDLできちゃいました。（PlaywrightでDLするのかと思いきやcurl叩いてました）。
※ それplaywright-mcpじゃなきゃダメなの？という指摘をする方、鋭いです。僕のブログ見ないでください！
上の用途ならWeb検索ができれば多分なんでもOKです。Claudeは現時点でWeb検索に対応していないので、Web検索・スクレイピング系のMCPを使うのが良いということだと思います。ちなみにCursorでMCPなしに @url として聞くと過去のナレッジに基づいて自信満々に誤答してきます。(claude-3.5-sonnetで確認)
このような用途に気付くと、最初「MCP使うんじゃなくてスクリプトでええやん」と言ったものの、これはちょっと不正確かなと。
繰り返しを前提とするE2Eテスト自動化においては、恐らく(codegenなどを用いた)スクリプトの方が適切なことが多いが、
もっと広くRPA的な自動化・スクレイピングのようなところではMCPの方がいい場合もある、みたいな話なんだと思います。
いやあ、俺浅かったね〜〜！
- 一回こっきり、ワンショットでの操作を実行したいとき
- 「最新のファイル」など、自然言語では表現しやすいが、いざロジックを書くとなるとすごい面倒そうなとき
- そもそもプログラミング初心者でスクリプティングってなんやねんってなってるとき
ざっくり言うと「スクリプティングする（または学習する）コスパには見合わないけど楽はしたい」時にMCPがハマる気がしてます。
MCP・CLI・APIベースのスクリプティングは使い分けるもの
ところで、アプリケーションのインターフェースはGUI・API・CLIなど複数ありますよね。
上記のPlaywrightの件を汎化して考えると、多分MCPもこれらのアクセス手段の一つの方法として、目的・用途に応じて使い分けていくものなんだろうなあと思いました。
- LLMを使い、MCPサーバ経由でアプリケーションにアクセスする方法
- コーディングエージェントを使い、CLIからアプリケーションにアクセスする方法
- コーディングエージェントを使い、APIを利用するスクリプトを記載しそのスクリプトからアプリケーションにアクセスする方法
これらはおよそAPIをwrapした仕組みとしては似ているものの、実際使うと効果的なシーンが違うんだろうなと。
いやあ、これ深いねえ〜〜！
ということで、次回はどのような要素がこの適切な使い分けを決めるのかについてもう少し考察を深めてみようと思います。ではまた後日。