PlaywrightとGitHub CopilotでPage Object Modelを構築する方法:MCP活用の実装手順

Published on: | Last updated:

最近、テスト自動化について、うーん、なんていうか、色々考えてて。昔はさ、WebアプリのUIが変わるたびにテストスクリプトを直すのが、もう本当に大変だった。Page Object Model、まあPOMって呼ばれてるデザインパターンが出てきて、だいぶ楽にはなったんだけど、それでもやっぱり手間は手間だったんだよね。

それが今、GitHub CopilotみたいなAIが出てきて、状況がガラッと変わりつつある。Playwrightっていうツールと、その中で使われてる[Playwright MCP]っていう仕組み…これを組み合わせると、AIがブラウザを直接操作するみたいな、ちょっと未来的なことができるようになってきた。正直、これってテストのやり方を根本から変えるかもしれないな、なんて思ってる。

一言で言うと、どういうこと?

まあ、すごく簡単に言うと、「AI(Copilot)がPlaywrightのテストコードのたたき台を、POMの考え方に沿って作ってくれるようになった」って感じかな。ただ、大事なのは、AIにどう指示を出すか、そしてAIが書いたものをちゃんと人間がレビューできるか、っていうスキル。結局、そこが一番重要になってくると思う。

そもそもPage Object Model(POM)って何だっけ?

あ、そうそう。一応、POMについて軽くおさらいしておくと…これはテストコードを整理整頓するための、まあデザインパターンの一種だね。Webページの各画面とか、ボタンみたいな部品を、それぞれ一個のクラス(Page Object)として定義する考え方。そのクラスの中に、要素の場所(セレクター)とか、それをクリックするとか文字を入力するとかいった操作を全部まとめて書いちゃう。

そうすることで、テストの本体からは、具体的なUIの操作が分離される。だから、もしUIのデザインが変わっても、直すのはそのページのクラスだけで済む。あちこちのテストケースを全部書き直さなくていいから、保守がすごく楽になる。…うん、だいたいそんな感じ。読みやすくなるし、再利用もしやすいし、まあ良いことずくめなんだよね、基本的には。

POMの概念を抽象的に表現したイメージ
POMの概念を抽象的に表現したイメージ

CopilotとPlaywright MCP、この組み合わせが面白い理由

じゃあ、なんでGitHub CopilotとPlaywright MCPを一緒に使うといいのか。昔のやり方と比べてみると、その差がよくわかると思う。ちょっと表にしてみようか。

項目 昔ながらのやり方(手作業) Copilot + MCPを使ったやり方
ページクラスの作成 うーん、まあ全部手で書くよね。どの要素があって、どんな操作ができて…ってのを一つ一つ定義していく。地味に時間がかかる作業。 「このページのPOM作って」って言うだけで、雛形をダーッと生成してくれる。もちろん完璧じゃないけど、スタートダッシュが全然違う。
セレクターの特定 開発者ツールを開いて、HTMLとにらめっこ。IDがあればラッキーだけど、複雑なのだとCSSセレクターやXPathを頑張って書く。これがまた、壊れやすいんだ…。 Copilotがアクセシビリティツリーとかを見て、結構賢いセレクターを提案してくれることがある。ただ、これも過信は禁物かな。変なのを拾ってくることもあるし。
テストコードの記述 作ったページクラスを呼び出して、`loginPage.enterUsername('user')`みたいに、シナリオを組み立てていく。これはこれで、ロジックを考える楽しさはあるけどね。 これも、「ログインして商品買って、メッセージを確認するテスト書いて」みたいに指示すれば、テストの骨格を丸ごと作ってくれる。すごいよね、マジで。
保守・メンテナンス UIが変わったら、該当するページクラスのセレクターを手で直す。まあ、POMのおかげで修正箇所は限定的だけど、それでも面倒なのは変わらない。 ここが面白いところで、AIに「この部分のUIが変わったから修正して」って指示できる未来も近いかも。今はまだ、人間がレビューして直すのが現実的だけど。

実際にやってみる:VS Codeでのセットアップ手順

じゃあ、具体的にどうやって環境を作るのか。…まあ、そんなに難しくはない。Node.jsとかVS Codeはもう入ってるっていう前提で話を進めるね。

  1. 前提ツールの確認
    ターミナルで node -v とか npm -v を叩いて、Node.jsが入ってるか確認。バージョンはまあ、14以上あれば大丈夫かな。あと、VS Codeも最近のやつじゃないとダメかも。

  2. Playwright MCPサーバーの設定
    VS Codeの設定ファイル、`settings.json`を開く。…えーと、開き方は設定画面からJSON形式で開く、ってやればいい。そこに、これを書き足す感じ。

    {
      "mcp": {
        "servers": {
          "playwright": {
            "command": "npx",
            "args": ["@playwright/mcp@latest"]
          }
        }
      }
    }

    これで、VS CodeがPlaywrightと会話できるようになる、っていうおまじないみたいなものだね。

  3. CopilotでAgentを選択
    設定が終わったら、GitHub Copilotのチャット画面で、入力欄のところにある「エージェントを選択」みたいなボタンを押して、「Playwright」を選ぶ。…あ、`@workspace`とか`@terminal`と並んで出てくるやつ。これを選ばないと、ただのチャットボットだからね。

  4. ツールの確認
    ちゃんと設定できたか心配なら、Copilotのチャットでツールアイコンみたいなのをクリックするといい。そこに `browser_close` とか `browser_resize` といったPlaywrightのコマンドが見えてればOK。うん、動いてる証拠だ。

CopilotにPOMを作らせてみた

準備ができたら、いよいよAIに仕事をお願いする番。今回は、よくあるECサイトのデモ、「Sauce Demo」を対象にしてみる。

Copilotのチャットに、こんな感じでやりたいことを箇条書きで投げてみる。日本語でも、まあまあ理解してくれる。

以下の手順でPOM(Page Object Model)を作ってください。

1. https://www.saucedemo.com/ を開く
2. ユーザー名とパスワードでログインする
3. "Sauce Labs Backpack" という商品をカートに入れる
4. カートを開く
5. チェックアウトボタンをクリックする
6. 名前、苗字、郵便番号にランダムなデータを入力する
7. 「続ける」ボタンをクリックする
8. 「完了」ボタンをクリックする
9. "Thank you for your order" というメッセージを検証する

そうすると、本当に数分で、Copilotが `pages` と `tests` っていうフォルダを勝手に作って、その中に必要なページクラスのファイル(`loginPage.ts` とか `inventoryPage.ts` とか)と、テストシナリオのファイルをごそっと生成してくれる。…正直、初めて見たときはちょっと感動したな。

AIがPOMのコード構造を構築している様子のイメージ
AIがPOMのコード構造を構築している様子のイメージ

でも、全部が完璧なわけじゃない(ここ大事)

ここまで聞くと、もうテストエンジニア要らないじゃん、って思うかもしれないけど、…まあ、そんなことはない。正直、AIが書いたコードって、まだまだ完璧じゃないんだよね。

例えば、すごく複雑な画面だと、要素のセレクターを間違えたり、人間ならやらないような非効率な操作を入れたりする。あと、アサーション、つまり「ちゃんとこうなってるか?」の検証部分が甘かったりもする。だから、生成されたコードを鵜呑みにするのはすごく危険。

結局、最後の品質を担保するのは人間の仕事。AIが書いた設計図を元に、ちゃんとした建物が建つように監修する建築家みたいな役割かな。…うん、そういうスキルがこれからはもっと重要になる。

そういえば、Playwrightの公式ドキュメント(もちろん英語だけど)は機能の「何ができるか」を知るには最高なんだ。でも、「どうして上手くいかないのか」とか「こういう時どうハマるか」みたいな実践的な知見は、日本のQiitaとかZennみたいな技術ブログで共有されてる記事がすごく参考になることが多い。例えば、Copilotが生成したセレクターが、日本の業務システムでよくある複雑にネストしたコンポーネントだと全然効かなかった、みたいな話を見たことがある。グローバルなツールを、ローカルな環境でどう使いこなすかっていう視点は、やっぱり大事だよね。

じゃあ、どう使うのが賢いの?

じゃあ、このすごいけど完璧じゃないAIアシスタントと、どう付き合っていくのがいいのか。

個人的には、「たたき台」や「定型作業」を作ってもらうのが一番効率的だと思う。ログインページとか、よくあるフォーム入力画面とか、そういう「毎回書くの、正直面倒だな…」って思うような部分をAIに任せる。で、人間はもっと複雑なビジネスロジックのテストとか、エッジケースの洗い出しとか、そういう頭を使わないといけない部分に集中する。

あくまで「超優秀なアシスタント」くらいに思っておくのが、精神衛生上もいいんじゃないかな。自分の仕事を奪う存在じゃなくて、面倒な作業を肩代わりしてくれるパートナーとして見る。そうすれば、もっと生産的に、もっとクリエイティブなテストの仕事ができるようになるはず。

AIが生成したコードでテストが成功した画面
AIが生成したコードでテストが成功した画面

結局のところ、どんな強力なツールも、使う人間次第ってことなんだろうね。こういうAIアシスタント、あなたはテストコード書くのに使ってみたい?それとも、まだ自分の手で書きたい派?よかったら、あなたの考えも聞かせてほしいな。

Related to this topic:

Comments

  1. Guest 2025-08-21 Reply
    テスト自動化、最近めっちゃ進化してますよね!AIとPlaywrightの組み合わせって、開発現場にマジで革命起こしそう。正直、こんな時代に仕事できて超ラッキーです(笑)
  2. Guest 2025-07-31 Reply
    うーん、AIテストって本当に信頼できるの?人間の直感と経験を完全に置き換えられるとは思えなくて…。正直、テクノロジーに頼りすぎるのは怖いかも。
  3. Guest 2025-06-27 Reply
    ねえ、AIテスト自動化って、本当に革新的だよね!POMとLLMの組み合わせって、どんな可能性があるのかな?現場の人たちはどう感じてる?
  4. Guest 2025-06-23 Reply
    うちの子もプログラミングに興味あるみたいで、こういうテスト自動化の話聞くとワクワクするんですよね。AIの力って本当にすごいって感じちゃいます。子供の未来、テクノロジーがどんどん変わっていくんだなぁって。