毎年、気がついたらプロポーサルの募集が終わってた〜〜 となってたソフトウェアテスト自動化カンファレンス、今年はたまたまKaigi on Railsが早く開催されて、それ関連でTwitterで登壇応募した人の投稿を偶然みて気づいた。
テスト自動化カンファレンスにプロポーザル出した！！
— やまずん (@55_ymzn) 2025年9月20日
下期はやる気なかったけど、テスト自動化カンファレンスはプロポーザル出すのが初だからいいよね！！！！
そこに自分も出したらなんと採択されたので、かねてからPlaywrightのポーティングをやってきた身としての話をできた。
資料について
今回も例によってiPadにストーリーを練って一気にスライドを仕上げるつもりだった。
1週間くらい前から通勤時間でiPad+Apple pencilでメモのアプリで書いていたのだけど、会社の11インチiPad（別のAppleアカウント）にメモを共有してそっちでカキカキしていたのがまずかったのか、どこかで同期にしくったようで当日未明にみたらこうなっていた...。
大急ぎで脳内キャッシュにあった構成を書き出して、当日AM4時くらいにはなんとか書き直したかな...
ちなみに、Appleのメモアプリはもう信用ならないので、最近仕事でもっぱら使っているFreeformを活用。Apple pencilがまともにつかえるFigmaみたいなもんで、このアプリならiPad miniでも結構いい感じに使える。別アカウントに共有ももうやらない。
そして、AM4時に書いたメモを、ひと寝入りしてから朝に見てみると自分でも解読不能...w
とりあえず矢印の向きはそこそこ考えて書いてたはず、ということでなんとなくの話の流れを再構築して、13時のオープニングのときには、スライドの調整が終わっていない状態。結局スライドの調整が終わったのが登壇の42分前。
格段に賢くなっているGemini 3.0
ちなみに、自分はいまだにKeynoteでスライドを作っている。
字ばっかりのスライドが好みではなく、絵を多くしようとすると、Markdownベースのやつでは無理で、どうしてもKeynoteかPowerpointに頼らざるを得ない。最近だと社内勉強会の資料くらいならGemini DeepResearchでGoogleドキュメントで済ませることはできるようになったが、登壇資料で生成AIの恩恵を得られるのはまだ先になりそうだ。
こういうのを見ると、KeynoteじゃないとするといまのところFigmaが有力なのかなとは見ているものの、現時点ではまだ難しい。
ただ、 プレゼンテーションのストーリーを練る部分においては、Geminiの3.0が従来の2.5とは比べ物にならないくらい合理的な構成ができるようになっている。
以前のKaigi on Rails 2025のときに、Gemini 2.5 proにプレゼンの構成を、それなりのインプット情報をもとに考えさせたのがこんな感じだった。
プレゼンテーション設計書：あなたのWebサービスはAIに自動テストしてもらえる？アクセシビリティツリーで読み解く、AIの『視点』 セクション1：序論：「魔法」から「メカニズム」へ このセクションの目的は、聴衆の注意を即座に引きつけ、現代のAIテストツールが持つ「魔法」のような能力を提示し、そこから「これは実際にどのように機能しているのか？」というエンジニアリングの本質的な問いへと移行することです。発表者の過去のE2Eテストに関する発表との連続性を示すことで、このセッションが長年にわたる探求の論理的な結論であることを位置づけ、信頼性を確立します。
スライド1：タイトルスライド タイトル: あなたのWebサービスはAIに自動テストしてもらえる？アクセシビリティツリーで読み解く、AIの『視点』
登壇者情報: 氏名、役職、ソーシャルメディア情報
カンファレンスロゴ
スライド2：「魔法」- 心を掴むオープニング コンテンツ: 短く、しかし強力なビデオデモンストレーションから開始します。Playwright MCPのようなツールを「エージェントモード」で使い、単一の自然言語プロンプトから複雑なユーザーフロー（例：ログイン、ダッシュボードへの移動、テーブルのフィルタリング、結果の検証）を自動化する様子を提示します 。ビデオはテンポよく、AIがUIを巧みに操作する様子を印象的に見せることで、その見かけ上の知性を強調します 。
トークのポイント: 「この1年で、自然言語をE2Eテストに変換するツールが登場しました。まるで魔法のようです。しかし、エンジニアである私たちは、そこに魔法はなく、抽象化のレイヤーがあるだけだと知っています。本日は、そのレイヤーを一枚一枚剥がしていきましょう。」
スライド3：私のE2Eテストを巡る旅路（信頼性の構築） コンテンツ: 発表者の過去3回の登壇タイトルと、それぞれの核心的な学びを簡潔に表示します。
「Railsのシステムテスト解剖学」(2021): 「Capybaraの内部構造を解剖し、テストがなぜ不安定（Flaky）になるのかを学びました。」
「E2E testing on Rails 2023」(2023): 「PlaywrightのようなモダンなNode.js製テストランナーが、不安定さの問題をいかに解決できるかを探求しました。」
「Capybara+生成AIでどこまで本当に自然言語のテストを書けるか？」(2024): 「自然言語テストの実現可能性を探るプロトタイプを構築しましたが、同時にその課題も認識しました。」
トークのポイント: 「私がこのカンファレンスで追い求めてきたテーマはただ一つ、RailsにおけるE2Eテストをいかにして信頼性が高く、保守しやすいものにするか、です。Capybaraの内部構造の解剖から始まり、不安定なテストとの戦いを経て、昨年は生成AIの世界に足を踏み入れました。そして今年、私たちはその根底にある真理を解き明かすために、さらに深く潜ります。」
わからんでもないが、なんとなく表面的な印象が強めで、中身があまり伴っていない、「普通そんなプレゼンしないよなぁ〜」感がどこか残るような印象のものだった。
今回のソフトウェアテスト自動化カンファレンスのほうは、Gemini 3.0でこんな感じ。
- イントロダクション (2分) スライド1: タイトルスライド
タイトル：「Playwrightのソースコードに見る、自動テストを自動で書く技術」
サブタイトル：～1.56 エージェント機能に至るまでの内部変遷～
名前、Twitter IDなど
(掴みの画像案: Playwright 1.56のリリースページのスクリーンショットと、「衝撃」のような文字)
スライド2: 自己紹介と「なぜ私が話すのか」
簡単な自己紹介。
キーメッセージ：「Playwrightのソースを4年間読み続けている私にとって、1.56のエージェント機能は『衝撃』ではなく『ついに来たか』でした」
トークのポイント:
多くの人にとって1.56のエージェント機能は突然の黒船来襲のように見えたかもしれない。
しかし、ソースコードを追っていると、これは突然変異ではなく、長年の進化の必然的な結果であることがわかる。
今日はその「進化の歴史」を、内部実装の視点から紐解いていく。
- 前史：AI×Playwrightの萌芽 (2分) スライド3: 早すぎた実験「playwright-mdd」
内容: かつて存在した、AIデコーディングの実験的機能について触れる。
資料: Zennの記事のスクリーンショット (https://zenn.dev/yusukeiwaki/scraps/6032430a01fea2)
キーワード: 「AIに操作させる」というアイデア自体は新しくない。
トークのポイント:
実は以前から、PlaywrightチームはAI活用を模索していた形跡がある（mddなど）。
しかし、当時はまだLLMの性能も、Playwright側の準備も整っていなかったため、一旦表舞台から姿を消した。
では、そこから何が変わったのか？ エージェントを実現するために、裏側で何が準備されていったのか？
- 変遷①：AIが「自分の操作」を理解するための準備 (3分) スライド4: 人間用からAI用へ。「Recorder API」の進化
内容: コード生成（Codegen）の裏側にあるRecorderの仕組みが変わった話。
資料: Zennの記事のスクリーンショット (https://zenn.dev/yusukeiwaki/scraps/cf5c95e703fc58)
図解案: [人間が操作] -> [従来のRecorder] -> [言語固有のコード(TS/JS/Python)]
図解案: [人間orAIが操作] -> [新しいRecorder API] -> [任意の操作ログ/中間表現] -> [AIが理解しやすい形式]
トークのポイント:
エージェントが自律的に動くには、「自分が今何をしたか」を正確に把握する必要がある。
以前のRecorderは「人間が使うコード」を生成するのが目的だった。
しかし、Recorder APIが公開され、操作を任意の言語やログ形式に変換できるようになった。
これが決定打。これにより、「AIが見やすい形式の操作ログ」を取得する基盤が整った。>
（ブログにコピペするとダラダラと長いので読みづらくてスマンッて感じだけど）感覚的には遥かにストーリー構成がしっかりしているものが出てきている。
今後はみんな何かしら生成AIの支援をうけてスライドの構成とかも考えるようになるだろうから、さまざまなカンファレンスのレベルが上がりそうな気はする。
発表のレビューはやっぱりGemini
べつにGemini好きなわけではなく、コーディングのお供はつねにClaudeなんだけど、発表のレビューでは15分とか30分しゃべりつづけた文章+PDFを食わせないといけないので、コンテキストサイズの大きさで定評のあるGeminiにまさるものはない。
あなたはPlaywrightによる自動テストの運用を長年経験してきたQAエンジニアです。 自動テストカンファレンスでの登壇内容についてレビューをしてほしいです。発表時間は12分程度ですので、この部分は特に説明しなくてもいい、とかそういう部分があればコメントを下さい。また、より詳細に説明に時間を取ったいい部分などもあればおしえてください。
概要: Playwrightのソースコードに見る、自動テストを自動で書く技術 / YusukeIwakiさん Playwright 1.56のエージェント機能に衝撃を受けた方も多いかと思います。しかし、この機能は実は突然現れたわけではありません。Playwrightのソースを4年間読み続けているエンジニアが、エージェント機能が公になるまでのPlaywright内部的な変遷を解説します。中の仕組みを理解すれば、他の自動テストライブラリで同様の機能を実現するヒントが見えてくるかも？
発表資料：添付のPDF
トークスクリプト（音声入力していて、一部誤りや切れてしまっています）
はい それでは プレイライトのソースコードに見る 自動テストを自動で 各技術という内容で いわき が発表させていただきます よろしくお願いいたします まず私ですが（・・・後略）
という感じで、長大なトークスクリプト（練習の時のを音声入力したやつ）を全部貼って、
- 短縮・さらっと流しても良い部分 (Time Savers) 「人間はどうやってE2Eテストをしてきたか」の一般的な話（スライド14〜18付近）
理由: 聴衆はテスト自動化カンファレンスの参加者なので、テスト設計→実装→実行→保守の流れは「釈迦に説法」です。「従来のこのフローを、AIはどう代替しようとしているか」という対比の文脈で、図を指し示す程度でサクサク進めてOKです。
- 厚く説明してほしい・強調すべき部分 (Highlight Areas) ここがこの発表の「核」であり、QAエンジニアとして一番聞きたい部分です。
「mdd」と「現在のMCP」の決定的な違い（スライド26〜27、41）
ここが重要: 「ハルシネーション（AIの記憶頼り）」vs「操作ログ（事実）ベース」 の比較はこの発表のハイライトです。
伝え方: 「今のMCP実装（mddの流れを汲んだもの）は、AIが適当にコードを書いているのではなく、ブラウザが吐き出した正確なログを清書させているだけだから信頼性が高い」という点を強調してください。QAエンジニアは「AI生成コードの信頼性」を一番懸念しているので、ここが刺さります。
Recorder APIの変遷（スライド36〜40、シーケンス図）
ここが重要: 単なる録画ツールだったRecorderが、「イベント（操作ログ）を外部に吐き出すAPI」に進化したことで、AIとの連携が可能になったという技術的転換点です。
伝え方: スライド40のシーケンス図（特に★ここが隠れた重要プロセス）は、少し時間を取って丁寧に解説すると良いです。「ここがブラックボックスじゃなくて、ちゃんとDOM解析イベントが発火してるんですよ」と伝わると、安心感があります。
など、結構「そうだなーー」と思えるフィードバックを6個ほどもらった。実際に発表のときに↑の3点はとくに変えた部分で、割といい感じで話せた気はする。
このあたりも、今後みんな生成AIをプレゼンで活用するようになれば、カンファレンスのレベルがさらに上がりそう。
ソフトウェアテスト自動化カンファレンス2025をみて...
今年は本当に生成AIとPlaywrightのネタが多かった気がする。
去年のタイムテーブル と比べると、今年のタイムテーブル は生成AIとPlaywright合わせたら半分くらいを占めてそうな感じ。
「自動テストの自動化」っていうキーワードを使っている人が他にいたかはあまりわからないけど、実際E2Eテストの実装においてはそんな時代になりつつある。
基本的には品質向上/業務効率化のためにツールを使いこなす役割の人が多そうだったので、そんな中で、ツールの中身/生い立ちをじっくり話すことで今後の技術選定に役立てるっていう特異な自分の発表には一定の意味はあったんじゃないかと思う。
今後もPlaywright Agentsを使ってみた事例は山のように出てくるだろうけど、「うちのサイト、Playwrightだとうまくいかねー！」ってなったときに、Playwrightを恨んで他のツールを探し始めるか、Playwrightの生い立ちを知って自分のサービスやテストプロセスをPlaywrightに寄り添う形に変えるか、判断しやすくなる一助となっていれば嬉しい限り。
Playwrightをもっと知りたい人へ
Playwright MCP に関しては Kaigi on Rails 2025で渾身の30分トークをしたのがある。これを見ると、「うちのサイトはなんでPlaywright MCPだとうまく動かないんだろうか」の理解は深まるかもしれない。Playwrightを恨んで他のツールを探し始める前にぜひ見てみてほしい。
あとは、Playwrightに興味はあるがのソースコードを読むなんて大変だと思っている人は、ぜひ microsoft/playwrightのGitHubリポジトリで package.jsonの履歴だけでも見ることはおすすめしたい。
平たくいうと、 npx playwright hoge のサブコマンドの追加削除があるとここに現れてくることが多い。
今回の発表で登場した playwright-mddの追加削除もここにはあるし、最近だと iterate on perform という謎機能（スクリプトの自動操作の最中でLLMに何か考えさせるような仕組みっぽい）が追加されているのも見えたりする。
