2025/9/26-27に東京駅すぐのJPタワーで開催されたKaigi on Railsで、今年も登壇をした。
いままで一貫してRailsのシステムテストの話をKaigi on Railsで登壇発表してきてたが、生成AIや周辺サービスの発展もあいまって今年はだいぶRailsシステムテストからは離れた方向となった。
- 2021年→Railsのシステムテスト解剖学
- 内部構造を知らずにCapybaraを使っているから不安定なテストが生み出される！とにかく解説
- 2023年→E2E testing on Rails 2023
- Capybaraのことは一旦忘れて、Node.jsベースのテストランナーでRailsアプリケーションをテストすることはできるのか？という考察と実践
- 2024年 →Capybara+生成AIでどこまで本当に自然言語のテストを書けるか？
れいによって反省記事とかを書いてみる。
登壇まで
もう40近いおじさんで、体力は若い頃に比べるとかなり衰退しているので、当然にKaigi on Railsに向けて何かを作って発表するぞとかそういったことは無理。なんなら、そろそろ若手に任せるべき年代でもある。
いっぽうで、3年以上はPlaywrightのRubyクライアントを継続開発している＆Kaigi on Railsにそこそこ登壇させてもらっている&１年だけRejectされた年があるという唯一無二の強み(?)もあり、一応いまだにブラウザの自動操作まわりについては好きで調べているので、語れること自体は結構ある。
若手を活躍させてこそ真の偉い人なのだろうが、システムテストを語らせて自分以上に情熱がある人をRails界隈ではほとんど見たことがないので、今はまだもう少し啓蒙をしないといけないフェーズなのだろう。
今年も登壇をして、しっかりRailsのシステムテストの行く末について語っておきたいと思った。
登壇ネタを考える
今回は、Gemini DeepResearchをフル活用した。全部考えさせたとかそういうことではなく、コンサルティング役としていろいろ考えてもらった。
過去４年の下積みを全部情報として与えて、今年の時代背景を含めてどんな発表をすべきか？という原案をいくつか出してもらった。実際に投げたプロンプトの一部は以下のような感じ。
あなたは技術カンファレンスの査読を行い、自身も経験が豊富なエンジニアです。 今年のKaigi on Rails 2025ではどのようなプロポーサルを出すと通りそうか、またどのようなプロポーサルは通らなさそうか、時代背景やRuby on Railsの置かれた状況なども加味して、いくつか例示してください。 なお、Kaigi on Railsは以下のようなコンセプトが示されているカンファレンスです。 >Kaigi on Railsのコアコンセプトは「初学者から上級者までが楽しめるWeb系の技術カンファレンス」です。Kaigi on Railsは技術カンファレンスへの参加の敷居を下げることを意図して企画されています。また、名前の通りRailsを話題の中心に据えるカンファレンスではありますが、広くWebに関すること全般（例えばフロントエンドやプロトコルなど）についてもカバーすることで参加者の知見を深め、また明日からの仕事に役立てていただければと考えています。 過去 Kaigi on Rails 2022 https://kaigionrails.org/2022/timetable/#day1 https://kaigionrails.org/2022/timetable/#day2 Kaigi on Rails 2023 https://kaigionrails.org/2023/schedule/#day1 https://kaigionrails.org/2023/schedule/#day2 Kaigi on Rails 2024 https://kaigionrails.org/2024/schedule/#day1 https://kaigionrails.org/2024/schedule/#day2 --- 私自身は、Ruby on Railsのシステムテストで使用するCapybara Playwright ドライバの開発者ですが、 2021・・・accepted title: Railsのシステムテスト解剖学 description: Railsには、ブラウザとRailsサーバーを対向させて自動試験するためのシステムテストという仕組みがあります。システムテストは単なるE2Eテストのフレームワークとして認識されがちですが、一般的なE2Eテストのノウハウをもとに自動テストを組むと不安定なテストに悩まされ、運用負荷が高くなりがちです。このセッションでは「システムテスト解剖学」と題し、システムテスト実行時に何がどう動いているのか、具体的にはCapybaraの構造や特性を明らかにしていきます。そのうえで、不安定なテストはなぜ生まれてしまうのか、どうすれば軽減できるのか、などシステムテストの運用改善のための知見を共有したいと思います。 2022・・・rejected title: SinatraとOpenAPIで始めるローコストAPI開発 abstract: RailsでAPIを開発するのはとても気持ちがよいです。 （以下, 2023, 2024 の内容をコピペして貼り付け。後略）
100行をゆうに超えるプロンプトでも、Gemini 2.5 pro はしっかり提案を出してくれて、登壇ネタを考えるにおいて大きな指針を示してくれた。
全部は乗せられないが、ざっとこういう感じだ。
1.4 主要な分析結果と戦略的含意
過去のプログラムを分析すると、単なる技術の羅列ではなく、開発者が直面する具体的な「問題」のポートフォリオであることがわかる。採択される発表は、「N+1クエリの撲滅」、「レガシーコードの移行」、「複雑なデプロイメントの克服」 といった、共感可能な開発者のペインポイントを解決する形で構成されていることが多い。「技術的負債の借り換え」 や「デプロイを任されたので...障害になった件」 といったタイトルは、問題解決型の物語形式への強い嗜好を示している。技術は解決のためのツールであり、その適用ストーリーこそが聴衆を引きつけるフックとなる。したがって、プロポーザルは「なぜ」その技術が必要だったのか（問題）を提示し、その上で「どのように」使ったのか（解決策）を語るべきである。
また、カンファレンスのプログラムには二つの主要な潮流が存在する。一つは、Railsコアチームのメンバーや、@zzak、@byroot、Palkanといった著名なコントリビューターによる基調講演 に象徴される、Railsの公式な哲学や最新機能に深く根差した「正統派」の潮流である。HotwireやActive Recordの内部構造に関するセッションがこれにあたる。もう一つは、Shopifyが大規模化の過程で生み出したPackwerk や、JRubyの活用 のような、標準的なRailsの枠組みを超えて現実世界の極端な要件に対応するための「実践派」の潮流である。これは、カンファレンスが理想論だけでなく、現実的な問題解決策も高く評価していることを示している。この二元的な性質を理解することは、自身のプロポーザルを位置づける上で極めて重要である。提案者は、自身が「正統派」（新しいRailsの流儀を極める者）なのか、「実践派」（Railsを極限状況に適応させる方法を示す者）なのかを明確にし、その立場に沿った物語を構築することが採択への道を拓く。
2.1 成功体験（2021年、2023年、2024年）：勝利の方程式の特定
採択されたプロポーザルには、共通の成功要因が存在する可能性が高い。以下の仮説フレームワークを用いて、自身の成功体験を分析することが推奨される。
時事性 (Timeliness): そのトピックは、発表の年に「旬」であった技術や問題を取り上げていたか？例えば、2021年の採択は、当時プレビュー段階だったRails 7の新機能に関する初期の深い探求であった可能性などが考えられる。
問題解決の物語 (Problem-Solving Narrative): 発表は、多くの開発者が共感できるような困難な課題を克服した「War Story」や実践的なガイドとして構成されていたか？
新規性 (Novelty): 独自のアプローチ、新しいツールの組み合わせ、あるいは自明ではないドメインからのケーススタディを提示していたか？
聴衆への訴求力 (Audience Appeal): カンファレンスのコアコンセプトである「初学者から上級者まで」を意識し、中級から上級というスイートスポットを狙いつつ、初学者にも理解の足がかりがあるような構成になっていたか？
これらの問いに答えることで、自身の強みや、レビュー委員会に評価されやすい提案のパターンが明らかになる。
3.3 テーマ潮流3：AIによって拡張される開発者とアプリケーション
背景: 生成AIは、目新しい技術から開発ワークフローにおける実用的なツールへと移行しつつある 。Rubyコミュニティもその活用法を積極的に模索している 。
2024年の前例: 2024年には、テストでのAI活用（「Capybara+生成AI」）や、機能実装（「生成 AIの応答をタイピングアニメーションで表示」）に関する発表があった 。
2025年の機会: 「どのように使うか」という点からさらに踏み込み、「次は何が可能か」という問いに答える必要がある。
ここまでいろいろ分析をしてもらって、さらに↑のGemini DeepResearchの結果をPDF化して、ChatGPTに「生成AIテーマでいくならこのあたりかなー」というのを数回壁打ちして、今回の「あなたのWebサービスはAIで自動テストしてもらえる？」というテーマにした。
テーマ選定にあたり事前に知っていたこと
去年の「生成AIがこれだけ発展してきたんだから、システムテストを自然言語で書くことくらいできるでしょう」というメッセージ性の発表は、本当にただただ 自分の思いつき （良くいえばアイディア駆動）で、特段に何かを参考にしたわけではなかった。
一方で、今年は思いつきな部分は実はほとんどなく
- 年始早々に Browser Use やばいです って記事みて使ったら本当にこいつが衝撃的すぎて、Rubyにポーティングしようとしていて、中の処理にはすでに異常に詳しい人になっていた
- 結局、Browser Useの開発スピードに個人開発でキャッチアップし続けるのは無理だなと諦めたが...
- PlaywrightのRubyクライアントを作る過程で、Playwrightのプルリクはかなり見る機会があって、
snapshotForAIというキャッチーな名前のメソッドがあることは認識していた。そして、どうもそれはARIA snapshotというものを内部的に使っているのも把握はしていた。- これはたぶんPlaywrightをソースコードレベルで見ている人じゃないと知られてなさそう
日頃からブラウザの自動操作まわりをいじっている過程で、発表の種になるようなものは持っていた。
プロポーサルの作成
ここは、さすがに生成AIではなく自分で書いた。
「HogeHoge AIだとうまくいくけど、FugaFuga AIだと動かない」ってのは完全にその場の思いつきなフレーズだったけど、「似たようなサービスが次々と出てくる今だからこそ、中の仕組み理解に立ち返り、技術選定をみんなでできるようになろう」というメッセージ性をこめて運営メンバーたちにぶつけた形だ。これこそ、Kaigi on Railsが大事にしている"初学者から上級者まで楽しめる"１つの要素だからだ。
Details | Kaigi on Rails 2024では生成AIによる自動テストがどこまでできるかというPoCのような発表がありましたが、その後1年もたたずに世の中ではBrowser UseやPlaywright MCPといった自然言語でブラウザを自動操作するための仕組みが登場しました。そして今後ももっと色々なツールが出てくるでしょう。
我々Railsエンジニアとしては、AIエージェントや自動テストツールの登場に一喜一憂するのではなく、これらのエンジンはなぜ自動試験がうまくできるのかを理解して、Railsで開発中のサービスに応用してAIテストでラクできるようにすることがとても重要です。 ネタバレにはなりますが、実際にPlaywright MCPで用いられているsnapshotForAIなどのコード・ロジックを読み解くと、AIが何を手がかりにWebサイトを解釈しているかがわかります。そのあたりをしっかり基礎理解することで、「HogeHoge AIだとうちのサービスはちゃんとテストできるけど、Fugafuga AIだと全然うまく動かない」といったツール選定の表面的な議論から脱却し、AI活用には自分たちのサービスをどう変えたら良いのかという本質的な改善議論をすることができるようになります。 また、Playwright MCPのようなツールをRailsから直接利用する方法はまだありませんが、Capybaraドライバを作りつつ解説することで、Railsのシステムテストとのつなぎもできるようになります。
また、2024年の「Capybara+生成AIでどこまで本当に自然言語のテストを書けるか？」の発表では課題が多くうまく動かなかったCapybaraドライバ https://github.com/YusukeIwaki/charai は、アクセシビリティツリーをベースにすることでどこまでまともに自動試験ができるようになるか？という部分も見どころです。
Pitch | この1年で、世の中では生成AIを活用したサービスやAIエージェントなどが数多く登場し、何をどう活用したら自分たちが開発効率化できるのか？というのは多くの会社で議論されているはずです。 この発表ではそのなかでも生成AIを活用した自動テストにフォーカスをあてていて、その裏の仕組みを理解していないと「HogeHoge AIだとうちのサービスはちゃんとテストできるけど、Fugafuga AIだと全然うまく動かない」といった不毛な議論になりがちなところを、AIがアクセシビリティツリーを手がかりにWebサイトを解釈しているなど裏の仕組みをしっかり解説することで、本質的にAIによる開発効率化を議論するための材料を提供します。 これまでKaigi on RailsではRailsのシステムテストやPlaywrightなどE2Eテストについてトークを重ねてきましたが、AI時代においてもAIに流されずRailsエンジニアが開発の主導権を握り続けるための確かな指針となる知見を共有したいと考えています。
やってる事的には、2024の発表と同じく、自然言語でテストが書けるCapybaraドライバを作ったよってだけだ。しかし、前回は新しい世界をみせてあげようじゃないかって方向性だったのに対して、今年は2021のシステムテスト解剖学と同じように「なんとなくだけ理解したつもり」で動いてるものに対して基礎理解を深める方向性に振り切った。なので、枠もがっつり30分枠にしてCFPを出した。
資料作成
iPadで全体のストーリーを考えて、スライドの作成は極力ぎりぎりまでやらない、ってのは今年も同じくやった。
ただ、去年でも
今年は仕事のほうがマジクソ忙しく、どう考えても過去２回ほどの準備時間は取れそうもなかったので、15分セッションで、しかもわりと自由研究に近い発表となった。
こんなことを書いていたが、今年もさらに相変わらずマジクソ忙しくて、実は資料の作成に着手したのが6日前、資料がおおむね完成したのが前夜。流石にもっと早くやっていたほうが良かったなとは思う。
生成AIでスライドくらい作れるかなーと思ったけど、さすがに自分のスタイルに合うものを作ってもらえるほど便利なサービスはまだなかった。
結果的にはそこそこボリューミーな資料を3日で仕上げることとなった。
サンプルコンテンツの作成には Claude Codeをフル活用
３日でスライドを仕上げたと書いたが、中身を考えるのは２ヶ月前くらいからスキマ時間でやっていた。
こんな感じでREADMEを余すことなく書いて、Claude Codeを起動する。
あとは、発表の内容を理解してもらったうえで、「アクセシビリティに問題のあるパターンのアコーディオンとドロップダウンのサンプルコンテンツ作って」みたいな感じでプロンプト投げてサンプルコンテンツをいろいろ作らせた。
いろいろ作ってもらったのを１こ１こHTMLを開いて見ることすら面倒だったので、
↑のように比較表を作ってパット見で正しいものが作られたか判断しやすくしたり、
このようなカタログを Playwrightでキャプチャ用のスクリプトを作って 画像を撮って貼り付けて、みたいな指示で普通に動いてくれた。Playwrightをつかうとサイトの動画を撮ったり特定要素のスクショを撮ったりできるという機能を知っておくと、生成AI活用も捗るな〜〜と実感した瞬間であった。
資料の構成確認
これはデブサミ2025に登壇したときに絶大な効果を発揮した取り組みだが、資料を通しで説明（リハーサル）したのをGoogle音声入力でドキュメントに書き起こしておいて、それを発表資料PDFとあわせてGemini 2.5 proに食わせて、発表に足りないところ・余計なところをレビューしてもらう、というものだ。
30分の発表で、書き起こすと400行くらいあるものでも、Gemini 2.5 proだったらしっかり読み取ってくれる。
とくにこの最後の部分は自分自身も気づいていなかった観点で、「なるほど〜〜！！！」となった。
資料の末尾の構成を少し変えたおかげで、実際の発表でもこんな反響があった。Geminiありがとう
アクセシビリティの改善への理解が「AIフレンドリーにしないと開発効率上がらないですよ！」という文脈を入り口に前に進めるチャンスだ！ #kaigionrails_blue
— たま (@tama50505) 2025年9月26日
ようは、Capybaraドライバ作って、何になるん？って部分が初版の資料では圧倒的に不足していたのだ。その部分を、「アクセシビリティというのは生成AIにサイトを見てもらう上でも重要だってのが、フルスクラッチでCapybaraドライバ作って評価する中でも見えた。」という結論に変えたのだ。
当日の反応
まとめ
まだ２日目が終わっていないが、今年も登壇してたくさんの人と話すことができてよかった。福岡ではこの規模感のイベントがないので参加も登壇も毎年刺激になる。
