この時代の大きな転換期の中のカンファレンスに参加できてとても楽しかったですし、 そこで自分も発表できたこと、とても嬉しく思います。 関係者の皆様ありがとうございました。
発表資料はこちらです。
また、発表ノートに埋まっていたトークスクリプトもMarkdownにしました。
Kaigi on Rails 2026でのトーク、Event is what happens のトークスクリプトです。 · GitHub
アプリケーション設計の話をすると、なかなかどうして、個々で携わっているコードベースが違いすぎて、「ふーんそちらはそうなんだー」となりがちなんですよね。
とはいえこの大AI時代、スライドとトークスクリプトをAIに入力して、それをみなさんのアプリケーションに適用したらどうなるかを議論するのなんかに使えていただければとても嬉しいです。
AI君に食わせるとたぶん「発想としては面白いところはありますが、実際にイベントの通信経路して扱うには注意が必要です。それを想定した機能ではないはず。ナントカカントカ」みたいに言われるんじゃないかと思います。トークの準備をしながら私もかなり言われました。それはそうなんですけど、でも『わかっちゃった』から仕方がないね、というテンションでお話しさせてもらったわけです。楽しんでいただけてるといいのですが。
参加者としての立場だと、やはりRESTのトークが2篇あったのが楽しかったですね。堪能しました。懇親会でもRESTfulな設計を実世界でどう適用するか、みたいな議論に参加させてもらって楽しかったです。時代はREST。
セマンティックを解しすぎたAIが、GET /user/42/profileしたらプロフィールGETできたけど、43にしたらどうかなとかやっているきらいがありますが、そこはハイパーメディアを尊重して、URLを不透明に扱ってほしい。AIはもっとRESTを学ぶべき。
さて、プログラマが3人集まればAIの話をする昨今、DHHとMatzのキーノート、そして松田さんの話も面白かったです。
懇親会なんかで、p45のイベントをサブスクライブするやつを、どのファイルに書くといいですかねえと言う質問を受けました。個人的には下記のようなふうに考えています。
- イベントとサブスクライバの構成は config/initializers/events.rb とかに書いておく
- イベントや、特にサブスクライバの実装は models でよいのでは
- chirin を使うアイディアだと、実装の多くは jobs や mailers になると思うので、それはそこに
- そのうえで、jobs のロジックが厚くなったら models に抽出する。これは昔からそう
こうしておけば、Railsに習熟した人間とAIのプログラマーにとっては割と探しやすいかと思います。
で、このようにしておくと「これが起こると、続きの処理は何が走るの?」「このメールが送られる契機はどんなのがある?」という質問に答えるための知識が凝集できて嬉しいんですよね。
2026年10月の感触では、やはり簡単な自然言語から、仕事で携わるようなスケールのソフトウェアを一息に生成できるイメージはまだありません。 そもそも自然言語は曖昧なもので、またその用語を厳密に定義していけば、結局プログラミング言語に近いものになると思います。
「注文が入ったら在庫引き当て処理が走る、ただし元の注文をブロックしないように非同期ジョブを使うこと。非同期ジョブは標準の仕組みを使う。」よりも「InventoryReservationJob.subscribe(Event::OrderPlaced)」のほうが、私は、わかりやすいし信用できるので、そう書きたい。かつ、AIはInventoryReservationJob.subscribe(Event::OrderPlaced)の羅列を解読して、人間向けに自然言語の解説を生成するのは得意そう。
そんなふうに、決定的に動いてほしいプログラマーの気持ちと、自然言語でそれを任意解像度で取り出したい人たちとの、ちょうど良いインターフェースに Ruby がなりうるんじゃないかと思っており、その表現の一つに、このイベントの観点が役立つといいなと思っています。
