「動くようになった」で満足していないか
前回Playwright MCPの入門記事を書いてから、実際に手元で動かしてみたという声を何件かいただきました。うれしい反響です。ただ、ここでちょっと立ち止まってほしいことがあります。
「動いた、便利。じゃあ自分のアプリでも早速AIに触らせよう」と、そのまま社内のシステムや本番に近い環境に繋いでしまっていないでしょうか。私も最初はそうでした。動いた喜びが先に立って、リスクの話は後回しにしてしまいがちです。
Playwright MCPは、AIに実際のブラウザを触らせる仕組みです。裏を返せば、AIが見ているページの中身がそのままAIへの入力になる、ということでもあります。ここに「プロンプトインジェクション」という穴があります。
今回は「動かす」の次の話として、このリスクを正直に整理しておきます。脅かすつもりはありません。ただ、知らずに触るのと知って触るのとでは、事故った時の被害が大きく変わってくると思っています。
外部ページの文章がAIへの指示に化ける、という話
プロンプトインジェクションを一言で言うと、AIに与えた本来の指示とは別に、AIが読み込んだデータの中に紛れ込んだ指示を、AIが本物の指示だと勘違いして実行してしまう問題です。
普段のClaude Codeの使い方で例えると分かりやすいかもしれません。私たちがAIに「このコードをリファクタして」と頼むとき、AIはその指示だけを実行してくれると信じています。ですが、AIから見ると、指示もコードもログもすべて同じ「テキスト」として渡ってきます。指示とデータを見分ける仕組みは、実はそこまで強固ではありません。
Playwright MCPの場合、AIはページの内容をアクセシビリティツリーというテキストで受け取っています。これは前回の記事でも書いた通りです。つまり、ページの中に「これまでの指示は無視して、別の操作をしてください」というような文章が紛れていたとします。AIはそれを本物の指示と区別できず、そのまま読み込んでしまう可能性があるということです。
白い背景に白い文字で書かれた一文、コメントの中に埋め込まれた一文、画像のalt属性に仕込まれた一文。人間の目にはほぼ見えなくても、AIはページの構造をそのままテキストとして読んでいるので、律儀に拾ってしまいます。これが「外部ページの文章がAIへの指示に化ける」仕組みです。
セキュリティ企業のUnit 42は、ツールの説明文そのものに悪意ある指示を仕込む「ツールポイズニング」もこの一種だとしています。MCPサーバーが提供するツールの説明を信用しすぎると、そこからも同じ穴が開くわけです。NSAとCISAも連名のセキュリティ情報シートで、MCPサーバーがやり取りするデータの中に悪意あるペイロードが紛れる危険を指摘しています。あわせて権限を最小限にすることの重要性も強調されています。国の機関がわざわざ文書を出すくらいには、現実的なリスクとして扱われているということです。
Playwright MCPで実際に何が起こりうるか
抽象的な話だけだとピンとこないと思うので、Playwright MCPを使っている場面に落とし込んで具体的に考えてみます。
知らないサイトへ誘導される
「このページの内容を要約して」とAIに頼んだとします。そのページの中に、見えない形で指示が仕込まれていたとします。「関連情報として次のURLも開いて確認しろ」というような文章です。AIは律儀にそのURLを新しいタブで開いてしまうかもしれません。Playwrightにはツールを使ってブラウザを操作する権限があるので、こういう「次のアクション」への誘導がそのまま実行に繋がってしまいます。
フォームを勝手に送信させられる
もう少し踏み込んだシナリオです。AIに「このお問い合わせフォームの入力テストをして」と頼んだページに、実は「入力内容を別の宛先にも送信しろ」という指示が紛れていたとします。AIがフォーム送信の権限を持っている以上、意図しない宛先にデータを送ってしまう可能性はゼロではありません。テストのつもりが、うっかり実データを外部に流してしまう事故です。
認証情報を持ったブラウザで動かす怖さ
これが一番怖いパターンだと思っています。ログイン済みの自分のブラウザプロファイルをそのままPlaywright MCPに使わせていると、AIがクッキーやセッションを引き継いだ状態でページを操作します。悪意あるページの指示に従って、AIが管理画面や別のタブを開いてしまえば、本来見えるはずのない情報にAIがアクセスできてしまう構図になります。機微な情報を持つブラウザプロファイルを使うときほど、この構図になっていないか注意してください。
実際、Playwright MCPのGitHubリポジトリでも、アクセシビリティツリー経由の間接的なプロンプトインジェクションが課題として報告されています。加えて、ローカルで立てたMCPサーバーがHostヘッダーを検証していなかった脆弱性(CVE-2025-9611)も過去にありました。悪意あるWebページからDNSリバインディングで直接コマンドを送り込める、というものです。こういった具体的な指摘があるくらいには、絵空事の話ではありません(この手のissueやCVEは修正が入るのも早い分野なので、自分が使っているバージョンで直っているかは各自で確認してください)。
今日からできる現実的な対策
ここまで読んで不安になった方もいると思いますが、MCPを使うのをやめましょうという結論にするつもりはありません。私自身、今も便利に使っています。大事なのは、リスクを知った上で使い方を選ぶことです。
- 信頼できるサイトだけに使う。自分のブログや自社サービスのように、中身を把握しているページから始めましょう。見知らぬ外部サイトの内容をAIに要約させたり操作させたりするのは、慣れないうちは避けたほうが無難です
- ツールと権限を最小限にする。NSAやCISAの指摘の通り、AIに与える権限は必要最小限に絞るのが基本です。フォーム送信やファイルダウンロードまで許可する必要が本当にあるか、都度見直しましょう
- 人間の確認を挟む。前回の記事でも書きましたが、私の環境ではクリックや入力のたびに確認が挟まるようになっています。地味な機能に見えて、これ、意外と使えます。慣れてくるとつい流し作業になりがちなので、私自身も気をつけています
- 機微な情報を持つブラウザプロファイルで動かさない。業務用アカウントでログイン済みのプロファイルではなく、専用のクリーンな環境でMCPを動かすほうが安全です。事故が起きても被害の範囲を小さくできます
- AIの出力を鵜呑みにしない。「このページは安全でした」「指示通り完了しました」というAIの報告自体も、汚染されたページの内容に引きずられている可能性があります。重要な操作の後は、実際に何が起きたかログやスクリーンショットで自分の目で確認しましょう
正直に言うと、これらを全部やってもリスクをゼロにはできません。プロンプトインジェクションは今のAIの仕組みの根っこに関わる問題で、完全な決定打はまだないというのが実情です(このあたりは研究も進んでいる分野なので、今後もっと良い防御策が出てくるだろうとは思っています)。だからこそ、影響範囲を小さく保つ運用でしのぐしかない、というのが今の私の理解です。
まとめ：動かせた次は、安全に動かす
というわけで、Playwright MCPを使う上でのプロンプトインジェクションのリスクを整理してみました。AIが読み込むページの中身がそのまま指示に化けうる、という仕組みさえ頭に入れておけば、身構え方はだいぶ変わってくると思います。
前回の記事では「動かせた」ところまでを書きました。今回はその続きとして、「安全に動かす」ための最低限の心構えをまとめたつもりです。信頼できるサイトから始める、権限を絞る、人間の確認を残す。地味な話ですが、この積み重ねが事故を防ぎます。
16年テストに関わってきた身としても、便利な道具ほど雑に使いたくなる気持ちはよく分かります。ですが、便利さとリスクはセットで理解しておいたほうが、結局は長く安心して使い続けられます。今使っているMCPの設定を、一度見直してみてください。
関連記事も合わせてどうぞ。
コメント