こんにちは、freee エンジニアの WaTTsonとyongiです！少し遅くなりましたが、2024年10月25日(金)〜26日(土)に行われたKaigi on Rails 2024に参加してきたのでレポートします！
今年のKaigi on Railsは10月25日(金)〜26日(土)有明セントラルタワーホール & カンファレンスで行われました。freeeのオフィスは大崎にありますが、大崎からはりんかい線で1本で行くことができます。行きやすくて良いですね！
freeeではWebサービスのバックエンドとしてメインでRuby on Railsを使っています。なので、Railsに関して色々なセッションを聞いたり、懇親会でRailsを使っている色々なエンジニアの方々とお話しできたのはとても良かったです！
セッションの感想その1: WaTTson
WaTTsonです。7月にセキュリティのチーム（PSIRT）から異動して、現在は通知基盤・タスク基盤の開発を行っています。タスク基盤のバックエンドでRuby on Railsを使っています。それまでPSIRTでは開発らしい開発をほとんどやっていなかったので、Rails歴4ヶ月の初心者として参加しました。
セッションを聞いている上でのポイントとしては、「Railsでセキュリティに関係する話」と「Rails初心者として知っておきたいRailsの思想に関する話」が特に気になっていました。それぞれ、関連するセッションがいくつかあったので全部紹介したいところですが、長くなるので2つだけピックアップします。
まずセキュリティの話で、2日目にHall Blueで行われたKoji NAKAMURA「ActiveRecord SQLインジェクションクイズ (Rails 7.1.3.4)」です。 私がPSIRTにいたときには、業務としてどちらかというとインフラ寄りのセキュリティを扱っていたので、アプリケーション層での話は若干手薄になっていました。アプリケーションの開発チームに移ったからには当然そちらについてもさらに力を入れていかないといけないので、Railsのセキュリティ関係の仕様は気になっています。
RailsではActiveRecordがORMとしてデータベースとのやりとりを隠蔽していることにより開発がしやすくなっています。一方で、これは書いたコードから実際に実行されるSQLが組み立てられるまでの仕組みが若干複雑だという話にもなるので、SQL injectionの懸念などは気をつけたいところです。
User.where("name = #{params[:name]}")のような書き方が問題を起こすことはよく知られています。ですが、ActiveRecodeのSQL injectionのパターンには色々なものが知られており、最後の問題で挙げられていたUser.exists?(params[:id])のようなパターンで起きうるのはちょっと罠っぽいところです。セキュリティをかじっているRails開発者としては、https://rails-sqli.org/ で紹介されているようなSQL injectionについてはきちんと把握しておきたいですね。
2つめに取り上げるのは、1日目にHall Blueで行われた五十嵐邦明「Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング」です。今回のKaigi on Railsでは最初と最後の基調講演で「Rails Way」の話が特に注目されていて、全体の大きなトピックになっているように思いました。このセッションでも「Rails wayから外れずに設計を進める方法と、Rails wayから外れていくときにRailsの仕組みを理解してできる限りなめらかに新しい設計ルールを入れていく方法」ということが話されていて、最初の基調講演からの続きの話として聞いていて面白かったです。
Railsに触れ始めた初心者といっても、業務としては既に組み上げられたある程度大きなプロダクトを触ることになります。冒頭の基調講演で「Rails 8はHELLO WORLDから最初の動作バージョンまでにできるだけ早く着くことに集中している」という話がありましたが、実務で触るのは0→1よりも1→∞の部分が多くなってきます。そういう中で、Rails wayからどうやって外れずに進めるか、外れていくならどう折り合いを付けていくか、というのが語られていたのが面白いポイントでした。もっとも、freeeのプロダクトではこのセッションでは推奨されていない「Service層」を入れているものもそれなりにあるので、実務での生かし方はもう少し色々考えないといけなそうですが……。
Rails Wayについては、たまたま少し前にObie Fernandez『The Rails 5 Way』を買って読み始めていたところだったので、ここで関連する話を色々聞けたのはちょうど良いタイミングでした。今回の学びを糧に、これからもRailsについてさらに研鑽を積んでいこうと思います！
セッションの感想その2: yongi
こんにちは。yongiです。23新卒としてfreeeに入社し、freee申告とfreee顧問先管理の開発を行っています。どちらもバックエンドにRuby on Railsを使っています。Kaigi on Rails は2回目の参加です。昨年の様子はこちらの記事をご覧ください。
私が取り上げるのは、「ActionCableなら簡単？生成AIの応答をタイピングアニメーションで表示。実装、コスト削減、テスト、運用まで。」です。kaiba さんの発表で、1日目にHall Redで行われました。ActionCableを使ったことはありませんが、生成AIとのチャットにおけるリアルタイム感のあるUXはどうやって実現しているのだろうと思っていたので、ぜひ聞いてみたいと思っていました。
Action Cableは、リアルタイム通信を実現するためのフレームワークです。WebSocketプロトコルを利用して、サーバーとクライアント間で双方向の通信を可能にします。生成AIとのチャットアプリでは、AIの回答を描画する際、まるでAIがタイピングしているかのようなアニメーションがよく用いられます。この仕組みはActionCableを使えば簡単に実装できそうですが、実際に開発するとなると様々な工夫が必要であることがわかります。
LLMからのレスポンスはServer-Sent Eventsとして細切れに返ってきます。これらのレスポンスをActionCable経由でクライアントに送信し、クライアント側でその都度描画することで回答をタイピングのように表示することができます。しかし、ActionCableをRailsサーバー上で実行する場合、コネクションの占有やパフォーマンス負荷によって他のAPIに悪影響を及ぼす可能性があります。そのため、本番環境においては、Action Cableを専用サーバーで実行したり、サブスクリプションアダプタを活用して非同期化するなどの対策が必要となります。非同期化する場合、LLMからのレスポンスの順番が保証されなくなるため、独自実装で番号を付ける等の工夫が必要になります。
コスト面の課題もあります。プロンプトが大きい場合、レスポンス1回あたりの料金が高価になります。本番環境以外ではアカウントを分けたり、1回だけ本物のリクエストを行うVCRを活用するなどの対策が必要となります。
一見シンプルに見えるLLMとのチャットでも、裏側ではRailsの様々な機能が活躍していることがわかり、とても勉強になる発表でした。また、コスト面の課題もLLMならではの観点で、時代の変化を感じました。発表では思わず笑ってしまうようなジョークが各所に仕込まれていました。ぜひアーカイブもご覧になってみてください。
まとめ
以上、WaTTsonとyongiのセッション感想でした！
それぞれに学びがあり、交流があり、良いカンファレンスだったと思います。 運営の皆さん、登壇者の皆さん、そして他の参加者の皆さん、ありがとうございました！
