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

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

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

過去２回は

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

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

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

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

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

登壇ネタを決めるまで

正直いって、プロポーサルの募集が始まった時点ではネタ切れ状態だった。過去２回（とくに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もぜひ盛り上げさせてくれ！と暗に伝えている...ｗ

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

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

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

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

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

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

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

期待値調整！

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

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

みたいなやつ。

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

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

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

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

という構成で臨んだ。

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

成果物の用意

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

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

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

github.com

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

デモの用意

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

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

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

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

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

で、結局出来上がったのは、１週間前。（なお、この時点で資料は0枚！）

本番まで

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

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

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

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

memo

発表資料（公開用）

speakerdeck.com

youtu.be

当日の反応

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

Webアプリ開発者であれば、Chromebook Flexは一度見る価値あり

yusukeiwaki.hatenablog.com

こんな記事を書いたのはもう３年も前になるが、実はMacbook 12インチは結局スペック不足で早々に手放し、 Dockerが満足に使えるMacbook Air 2020 (Core i7 + 16GB/512GB)に乗り換え、さらにはM2, M3あたりの高性能さがほしいと思って、今年になって20万以上するMacbook Air 15インチ (M2, 16GB/1TB) に乗り換えてきた。

ここまで申し分のないスペックのPCを買ったはいいが、実際そんなに活用ができていない。もちろんそのへんのネット閲覧だけとかではなく、DockerとかNode.js, Rubyあたりのコードはわりと高頻度で書いているものの、いちばん高頻度でやっていることが、playwright-ruby-clientの毎月のアップデート作業で、こいつは実はそんなにCPUもメモリもいらない。 むしろ(物理的に)重くて、買い物の合間にRSpecを書くなんてことが15インチのMacbook Airでは割と難しく、趣味の開発をスキマ時間でやりにくいという問題が顕在化してきていた。

そうなってくると、べつにLinuxの安いマシンでもいいなじゃないか？と思い始めた。

LinuxのノートPC？

なんとなくメルカリを見てみたら、ちょうど3.5マンで富士通製のLIFEBOOK WU2/D2のCore i7 16GB/512GBのモデルがあったので、一旦即買い。なんせこいつは重量が700g弱しかないので、Macbook Airの半分だ。まじで（物理的に）軽い。

めっちゃ軽い。

キーボードが日本語刻印なし、Core i7, メモリ16GB、などできる限りのカスタマイズがされているマシンが3.5万なら買うしかないだろう。

で、問題はこいつがWindows PCだということ。

10年ぶりにWindowsを触ってみると、だいぶ使用感は変わっている印象こそあれど、なんだかんだでマイクロソフト。「エクスペリエンスをなんちゃら〜」みたいな日本語が意味不明なセットアップ画面に出てくるのは昔ながらである。そんなPCは使いたくない。（ただただマイクロソフトが嫌いなだけw

そうなると、代替としては

あたりだろう。

見ての通りDebian大好きな身としてのバイアスはあり、何もなければDebianいれたかったものの、Xウインドウや日本語入力周りで未だに苦労をしないといけないのは目に見えているので、ChromeやAndroid StudioやVS codeなどは本当に難なく使えたほうが嬉しい。 （実は一番めんどくさいのはChromeだったりする）

ChromeOS?

逆に、Chromeが中心にあってあとはおまけ、というChromebook化してしまうのはどうだろう？

ネットブックじゃないので

  • gitコマンドはちゃんと使えないと困る
  • 画面のスクショをGitHubに貼り付けるくらいの操作は当然できないと困る
    • いままでは Clean Shot X に課金してたくらいなんだから
  • VS codeã‚„Android Studioなど各種ツールは難なく使えると嬉しい

あたりは押さえておきたかった。そのうえで、ChromeOS Flexを試しに入れてみると...

... とくに動作確認機種ではないが、思いの外ちゃんと動いている。Androidアプリのランタイムこそ入っていないものの、Linuxアプリケーションについては問題なく使えている。Xウインドウ上でGUIで動くアプリケーションも、chrome://flagsで1個機能フラグをオンにするだけで日本語入力がまじで難なくできちゃったのが一番の驚きだったりする。

zenn.dev

playwright-ruby-clientのGemを開発する際によくやる、Chromiumが裏で立ち上がっていてVScodeでコード書いてRSpec流す、という状況についても普通にできてしまっている。

仮想マシンでDebianが動いているということを忘れてしまうくらいシームレスに色々動いているなぁと言う印象で、ここまでやられるとネイティブのDebianよりも遥かに開発体験がよい。CPU/GPUをフル活用したいプログラムならば話は別だろうけど、ふつうにWebアプリ開発やるだけならこれで十分では？！

Developers Summit 2024 のリレーセッションでプチ登壇してきた

の最後の時間枠で「生成AIで開発生産性向上！リレーセッション」の中で8分ほどだけしゃべってきました。

ちょうど同時刻に、「オフラインカンファレンス復活！イベント現地参加の魅力を語りつくすリレーセッション」っていう、めちゃくちゃ聞きたい感じのセッションが被ってたのが心残りですが、とりあえず初めてのデブサミ参加で結構楽しめたかなーと思っています。

資料

speakerdeck.com

とってもながーいタイトルですw

どうしてこんなタイトルにしたのかはのちほど...

登壇までの話

れいによって、どういう取り組みをして登壇に至ったのかを書いておこうと思います。

デブサミに申し込むまで

特に深い理由はなかったものの、なんとなくTwitterで流れてきてて応募してみた、くらいのノリでCFP出しました。

Developers Summitは、なんちゃらKaigiとかとは違って、特定分野に異常に詳しい人達が話すというよりは、技術的な知見や運用知見などを共有して、日本のITなコミュニティの成長に貢献していこう的な感じのカンファレンスのようです。ということで、内容もどちらかというと運用知見を多めに話をしてみようとは思っていました。

「でも、自分が生成AIとかなんとかで運用知見というと、、うーーん、なにもない（苦笑）」みたいなところから始めました。

CFP出す数日前に「ボット運用してみて良かったところ改善したところとかを、丁寧に共有すれば普通に知見として成り立つんじゃね？」ってことで、あらためて会社のブログ記事に書いていた内容を思い出し、iPadで手書きメモでストーリーを軽く練って、それっぽくCFP書いたら奇跡的に通りました。

ストーリーを深く練る

これはKaigi on Rails 2021, Kaigi on Rails 2023, と続けてきたことです。スライドは極限まで作らない。手書きでストーリーをとにかく仕上げる。

最初はマイクロソフトのドキュメントがくそすぎるとか、Microsoft Teamsでボット作らせる気ないだろうとか、愚痴ばっかりでしたが、まぁそんな発表が面白いはずもなく、結構書いては捨てて書いては捨ててという感じで推敲を重ねました。

あと、実装に踏み込むと知見の共有という部分がだいぶ薄れてしまうことから、「実装についてはブログみてください」に振り切ったり。

あとは、タイトルは惜しみなく長くして、冒頭でなぜそのように考えたかをしっかり絵で説明しよう、とか。

プロフィール登録、タイトル・概要登録、資料アップロード...

Acceptされると、本番に近づくにつれて解像度の高い情報を提供するような感じで、翔泳社のCodeZine編集部のデブサミ運営事務局からけっこう丁寧に細かく連絡がメールで来ます。自分はふだんメールの習慣なんてないので、結構見逃します。メールが来たらSlack通知するとか仕掛けておくべきでしたね...。（ごめんなさい、、、翔泳社のCodeZine編集部の方々...。）

あと、今回の発表は「リレーセッション」という形式上、自分のPC持ち込みではなく、共用のWindows PC上であらかじめ送付しておいたPowerPointプレゼンテーションを操作して行うというものでした。かれこれ10年くらいMacユーザなので、PowerPointなんて普段は全くつかいません。とりあえずKeynoteで作りました。アニメーション周りで非互換とかバグるといやなので、アニメーションは全く使わず、ただ絵を並べただけにしました。

PowerPointで見てみると案の定フォントサイズの調整が必要な程度には崩れましたが、10分で直せる程度のものだったので、Keynote意外と使える子でした。

ç·´ç¿’

6分くらいで収めるよう、2回くらいTeams会議で録画してプレゼンして見直して、ってのをやってみました。

淡々と10分弱しゃべるのだと全く面白くなくて、

こういうスライドを急遽追加したり、

あとは、ながーいタイトルを口にすることなく進めるというのも意外と難しくて何度か練習しました。

で、タイトル長すぎじゃね？

「ChatGPTを個々人が使っていた組織から、チームチャットにボットを棲まわせてみんなが活用する組織になるまでの変遷、ぜんぶ紹介しちゃいます」

これは、口にすると10秒くらいかかる。長い。ただ、そんな複雑なことを言うつもりもなくて、スライドにあった

これを表現したかっただけ。なんだけど、どの要素も削るに削れなくて、結局長いままになってしまった、というオチです。変に削って伝わらないよりは、多少長くてもイメージが正確に伝わるほうがマシかなと諦めた、というのもあります。

あと、デブサミの事務局の方々に審査をしてもらう段階でも埋もれないようにと意識したところはあって、生成AIセッションの応募でチャットボット系のものはいくつかあるだろうから、「なーんだこいつもチャットボット自慢かー」と誤解をされないようにしないといけませんでした。

「ChatGPTを個々人が使っていた組織から、チームチャットにボットを棲まわせてみんなが活用する組織になるまで」

だと、なんか自慢でもするのかなこいつ、って見えるじゃないですか？なので「変遷、ぜんぶ紹介しちゃいます」のように変遷にフォーカスがあたっていることを強調したのでした。

登壇

仕事の都合でどうしても前日入りが難しく、2日目の午前中移動でその日の夜に最終便で帰るという強行スケジュールで臨みました。

今年は羽田空港なので（福岡から行く身としては）かなり便が良く助かりました。

半日しかないので、ブースを回ったり他の会社の人としゃべったり、という方向に集中して参加しました。いわゆる「廊下」です。

ちなみに、なにか話すきっかけになるかな？とおもって無造作に置かれたピアノで２〜３曲弾いてみたりしたものの、そもそも自分はコミュ障だし、そもそもそんな道端でピアノ弾いている人がエンジニアとはみんな思わないわけで、この作戦は大失敗でしたw

肝心の発表自体は、ちょっと緊張気味でセリフをなんどか飛ばしてしまったので、若干時間オーバーに。ごめんなさい...。

懇親会

AIプログラミングの話を聞いたり、自分のOSSを布教してみたりしていました。mablやAutifyの方々とゆるく話せたのは結構楽しかった。

懇親会に限らずですが、デブサミはわりと「名刺」の出番が多かったです。Sansanとかじゃなくて、紙の名刺。

帰り

福岡空港といえば門限があるので、北九州空港行きの最終便。

呉服町付近でメルチャリがなかなか見つからず、天神まで歩いてようやく発見。疲れていたので、電動アシスト付き自転車を初めてつかったけど、すんごい楽で感動した。室見川の前後の坂道もまったく息が上がることなくスイスイ。

まとめ

業界の有名人が結構いて、懇親会だけでも価値があると思いました。（雑w）