Kaigi on Rails 2024で生成AI+ブラウザ自動テストに関する登壇をしてきた

2024/10/25-26 で東京の有明で開催されたKaigi on Rails 2024で登壇発表してきた。

タイトルは「Capybara+生成AIでどこまで本当に自然言語のテストを書けるか?」 kaigionrails.org

過去2回は

  • 2021年→Railsシステムテスト解剖学
    • 内部構造を知らずにCapybaraを使っているから不安定なテストが生み出される!
  • 2023年→E2E testing on Rails 2023
    • Capybaraのことは一旦忘れましょう。Node.jsベースのテストランナーでRailsアプリケーションをテストするには?

といった内容で、まぁまぁアンチCapybaraな人みたいな印象は持たれていそうなところで、今回はあえてCapybaraを活用するようなトピックとした。あとは、2023年頃から急速に普及している生成AIの活用についても、このタイミングで触れなければもう来年には賞味期限切れでしょう?というのもあわせてテーマを考えて、結果的にもだいぶいい感じの発表はできたと思う。

今年は仕事のほうがマジクソ忙しく、どう考えても過去2回ほどの準備時間は取れそうもなかったので、15分セッションで、しかもわりと自由研究に近い発表となった。あとから聞いた話だと、どうやら今年はプロポーサルが5本に1本くらいしか採択されていなかったようで、そんななかで割とタイムリーなこのテーマが採択されて、やや不完全な部分を残しながらもとりあえずRailsエンジニアを前に堂々と発表することができて本当に良かったなと思う。

あと、今年は去年に比べると現地参加者も懇親会参加者も(体感だけど)2倍くらいに増えてたと思う。2021年の参加時から思うと、本当に大きいカンファレンスになってきたなーという印象。2年後くらいにはDroidkaigiかそれ以上の規模になってるんじゃないか。

そんないろいろはありつつ、とりあえず去年の記事 (Kaigi on Rails 2023 現地参加して "E2E testing on Rails 2023" というお話をしてきた - YusukeIwakiのブログ)と同様、今年も登壇までにやったこと、当日のこと、などなどを忘れないように書き留めておこうと思う。

登壇ネタを決めるまで

正直いって、プロポーサルの募集が始まった時点ではネタ切れ状態だった。過去2回(とくに2021)が濃厚な内容でシステムテストまわりの仕組み解説に徹する感じでやってきたけど、Railsシステムテストの技術的な部分というのは2021年の発表時点からそんなに大きく変わっていないし、Playwrightの機能性も去年からそんなに大きくは変わっていない。

いっぽうで、2023年頃から流行りだしている「生成AI」というものについては、どうもRailsアプリケーション開発での活用というのは今ひとつピンときていない。

 ...となると、技術的な進歩がそんなにないことを逆手に取って、生成AIをめちゃくちゃ活用した自動テストっていうのを提唱してみたらおもしろいんじゃね??

って感じでなんとなくプロポーサルを出したのであった。ちなみに、当時の会社での独り言チャネルにはこのようなことが書かれていた。

記憶はあいまいだけど、たぶんChatGPTが裏でブラウザを動かしてテストシナリオを自律的に判断・実行するようなドライバを作ることだけはこのときから決めていて、逆にそれ以外のことは何も考えていなかった気がする。

Details
2023年ごろから、ChatGPTをはじめとする生成AIを活用したコーディングはあちこちで事例が共有されてきました。テストに関しても、テストデータを作らせたりテストコードを書かせたりなど、Copilot的な事例はよく聞きます。 ところで、RailsにはシステムテストというWebサーバーを実際に立ててブラウザと対向させて試験する仕組みがあります。システムテストではCapybaraが使われ、バックエンドにはSeleniumやPlaywrightなど、ブラウザを自動操作するエンジンが使われます。テストにはDOMセレクタなど機械的な言語が入力言語として使われますが、これほど生成AIがいろいろできるのなら、自然言語を入力とするOpenAIをバックエンドとしたCapybaraドライバも作れるはずではないでしょうか?ということで、実際に作ってみました。

Capybaraドライバの実装自体はかなりニッチな話題にはなるし玄人向けですが、システムテスト自然言語で試験が書ける未来を感じることについては初めての方でも楽しめるのではないかと思われます。

Pitch
まず時代的に、今年は生成AI関連の話題は欠かせないだろうと思います。そのなかで、ただ単にAIに一過性のコードやテストデータを作らせた、というのはもう飽きてきましたよね。継続的にAIに仕事させて、しかもそれをRailsシステムテストと融合させる、という発想の取り組みはこれまであまりされてこなかったのではないかと思います。 Kaigi on RailsでCapybaraやシステムテストの話題を続けてきた身として、今年はややチャレンジングな方向でライトトークをしたいです。

こんな内容で書いて出してました。「まず時代的に、今年は生成AI関連の話題は欠かせないだろうと思います」が割とマジ(本心)なところで、Kaigi on Rails 2023につづき、2024もぜひ盛り上げさせてくれ!と暗に伝えている...w

ストーリーを組み立てて発表内容を決めるまで

れいによって、iPad+Apple Pencilの出番w

人工知能に手足を持たせてブラウザを自律的に操作できるようにする!という理想像は7月末時点で↑のような絵を書いた形跡があり、結果的にはスライドの中にも登場したネタだ。

ただ、今年は本当にひどくて、深堀りを始めたのはなんと10/11で発表の2週間前。

会社のチャットの独り言チャネルにはこんなことが書き残されていた...。発表をそこそこうまくできた今だからこそ言えることだが、本当にひどい登壇駆動開発である。2週間前になり、流石に時間を取らなきゃと、まずやったことは "銭湯(ふくの湯)にいって作業する" ということ。これで一気に進捗した。

そしてコードを書くことではなくとにかく深堀りを手書きでやることから始めたのは例年の通り。順序の前後はあとから考えることにして、あらかたの内容やキャッチフレーズっぽいものなどは、10/11ごろから数日で練り上げた。

これらの内容も、本番で発表したスライドには(順序はまちまちだが)ほぼほぼそのまま登場している。やはり手書きで整理すると早い。

期待値調整!

これは完全に自分の過去の偏った経験に基づく歪んだ認識なんだけど、AIの分野というのは「ずるい」発表をする人が多い気がしている。

  • うまくいく部分だけをデモで見せて
  • 夢を感じさせるコンセプトムービーで補完して共感を集め
  • でも、実際にほとんどのユースケースでは乱数と同程度あるいはそれ以下の精度しか出ない

みたいなやつ。

Kaigi on Railsは初心者から上級者までしっかり楽しめるカンファレンスとポリシーで明言されているので、うまくいかないものはしっかりうまくいかないと伝えてみんなで良くしていこう!という流れを作っていけることが絶対である。

そうなってくると、生成AIにはガチャ要素があり、それでも高確率でうまくいく部分と、どうにもうまくいかない部分というのは過程を含めて全部見せると、次に同じことをやる人が同じ失敗をせずに済む。

結果的にはこの辺りは本番スライドでも織り込んで

  • 実用段階にはない!気楽に聞いて楽しんでくれ、と冒頭で伝える
  • デモの前に、根底の論理や、実験過程なども隠さず見せる
  • デモはビデオではなく、実際に動かすものにする

という構成で臨んだ。

一般的なテーマではデモを失敗するのを恐れてビデオにするとかやりがちだけど、今回は逆で、むしろデモは失敗する可能性のほうが高いので、それでがっかり(将来性がない)とならないよう設計をした。ということだ。

成果物の用意

実装フェーズにおいては、ふくの湯には2、3日に一回は行ったw

「Capybaraドライバを拡張して実装する方法について解説します」って言ってしまっている以上、Capybaraのドライバは最低限作って、当日までに公開できるようにしなければならない。

charai という適当な名前のライブラリにして、作った。

github.com

ブラウザをぐりぐり動かす部分は、 PlaywrightでもPuppeteerでも何でもよかったんだけど、 Page.waitForSelector とか気の利いた機能は今回いらないので、半年前くらいに WebDriver BiDiでFirefoxを動かすサンプルライブラリ minibidi を作ってたのがちょうどあったので、それを内包する形にした。

デモの用意

デモの内容というかシナリオは当日までに何度か差し替えた気はする。

  • 最初は、CSSセレクタ書かなくてもAIでここまでできるんだぜアピールをしようと、ログイン→デバイス一覧からデバイスを選択→詳細にそのデバイスのIMEIが出る、というPlaywrightで書いても結構エンジニアが苦労するやつを題材にしていたが、AIにやらせると30回以上やらせても1度も成功しない...。
  • ネタに振り切って「この写真を見てボケて」ってのもやってみて、時間的にはちょうどよかったし内容も面白かったが、「Railsのテスト」という文脈から外れすぎて、あまりに実用性とは程遠いという印象を与えてしまう。
  • 新旧で同じ見た目で、DOM構造が全然違うけど、新→旧へのフォールバックのステップ追加するだけ、っていうデモであれば、最初の方で課題感として上げていた「DOM構造が変わって移行がしんどい」って話とリンクできてよさそう。

と、いろいろ試して、最後のやつにした。

ちなみに、発表では特に言及しなかったが、このデモはとてもお金がかかっていて、

初期は1回流すのに400円くらい💰️が飛んでいっていたらしい。途中で、画像のアップロード量を調整したので、少し落ち着いたが...。

で、結局出来上がったのは、1週間前。(なお、この時点で資料は0枚!)

本番まで

さすがにスライド0枚から1週間で練習までやって本番に持って行くには、仕事いそがしいとか言っていられないので半休を二度とり、ふくの湯にも2度行き、仕上げた。

日曜日には0枚だったのが、火曜日には20枚ちょい、水曜日には94枚までふくらませ、あとは調整して練習して本番へ...。

機運を高めるべく、ちょうど10/23発売だったiPad mini第7世代を無駄買いして、どこででも練習できるぞー!とイキって、当日の朝の飛行機内でも練習しまくって、本番へ。

ちょいちょいセリフ自体は忘れたものの、全体の流れとかはわりと覚えてたので、たんたんと喋れたかなと思う。

memo

発表資料(公開用)

speakerdeck.com

当日の反応

https://x.com/search?src=typed_query&q=(%23kaigionrails_blue)%20until%3A2024-10-26%20since%3A2024-10-25_17%3A55%3A00_JST

https://x.com/search?q=(%23kaigionrails)%20until%3A2024-10-25_18%3A19%3A00_JST%20since%3A2024-10-25_17%3A55%3A00_JST&src=typed_query&f=live

まとめ

ふくの湯はとてもよかった。

だいぶ大規模なイベントになってきているし、来年も元気があれば出る(雑w