2025年4月16日から18日の3日間、愛媛県松山市にて、RubyKaigi 2025 が開催されました。
タイミーでは、昨年に続き、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度を活用し、新卒内定者やインターン生を含む総勢16名が現地でカンファレンスに参加しました。 この記事では、現地参加した各エンジニアの印象に残ったセッションとその感想をまとめてお届けします。 今回はその第4回で、Day3の内容をまとめています。 Day1, Day2のセッションに関する内容についてもぜひ合わせてお読みください！
各セッションごとに内容を整理し、参加者自身の視点から学びや気づきをまとめています。読者の皆様にとって、今後の学びの参考になれば幸いです。
On-the-fly Suggestions of Rewriting Method Deprecations
発表
概要
deprecated への対応は開発者にとって時間と手間がかかる作業であり、本来の開発から注意を逸らします。ドキュメントの作成や警告表示、静的解析ツールなどを用いた既存の対応策には限界があり、特に Ruby のような動的型付け言語では、静的解析による検知や修正には過不足が生じてしまいます。そこでコードの実行時に自動書き換えまで行うアプローチを提唱し、それを実現するため deprewriter-ruby Gem を開発したという発表でした。これは deprecated なメソッド呼び出しを検知して、規定したルールに則って上書きをするというもので、ライブラリ開発者が非推奨化するメソッドに「どのように書き換えるべきか」という変換ルールを定義することで、利用者がテストなどでそのメソッドを呼び出すと、Gemが変換ルールに則り自動で書き換えてくれるようになります。
gem の説明の中ではメソッド呼び出しのインターセプト、呼び出し元情報の取得（caller_locations）、ソースコード解析（Prism/SyntaxTree）、AST変換（Synvertベース）、ファイル書き換え/差分出力といった技術要素を解説してくださいました。また、ファイルを直接上書きするだけではなく、ログ出力モード、差分（パッチ）出力モード、直接書き換えモード（主にテスト環境向け）を提供しているそうです。
この gem は各言語の deprecation の対応状況を調べていく中で、Pharo言語の自動リファクタリング機能に影響を受けて開発されました。 Pharo での deprecated なメソッドの置き換え等は Deprewriter と呼ばれていますが、それを Ruby でも実装してみて、実際にどのように利用できるか、動くのかを紹介してくださいました。
将来的には、 Ruby エコシステム全体で非推奨対応の負担を軽減し、開発者がより本質的な作業に集中できる環境を目指したいというビジョンを示してくださいました。
感想
メソッドの Deprecation（非推奨化）に関して、ドキュメントを参照しながら開発の過程で修正していくというプロセスは、自分にとってあまりに当たり前なものでした。本番環境で実際に適用するかどうかはさておき、実行中にそれらが自動で修正されるという体験は、自分にとって非常に斬新かつ素晴らしい開発者体験だと感じ、プログラミング言語にはまだまだ進化の余地があるのだと改めて実感できました。何らかのアップデートに伴いCIが実行され、差分があった場合に別途PR（Pull Request）が作成されるという状況は、開発者体験を大きく向上させそうです。また、言語やライブラリの開発者にとっても、互換性の問題を発生させにくい優れた仕組みだと感じています。最近論文を読んでいないことも思い出したので、自分も改めて論文を読み直してみたいと思います。
Rails などの著名なライブラリに対して RuboCop がいわば「肩代わりして」行っているようなことを、ライブラリ自身の責任で行えるようになるというのは、ライブラリ開発者としても理想的な機能ではないでしょうか。とはいえ、実際のコードでよく起こりうる「同じメソッド名で挙動が異なる」という場合（例えば引数のキー名が変わったなど）は、「現在どのような状態なのか」の判定が難しいため、うまく実現するのは大変そうだという予感がします。今後の発展に期待しています。
非推奨メソッドへの対応は、特に Rails のバージョンアップの際に度々発生します。その度にリリースノートを読み込み、ソースコードの差分を確認して対応しますが、コストのかかる作業だと常々感じており、そのような状況下でこの発表を聞き、自動で修正されるというアプローチに感銘を受けました。
この Gem は、ライブラリの利用者にとっては夢のような機能を提供する一方で、利用者が便利になるためのコストをライブラリ作成者に強いる設計だと思います。これは RBS にも言えることですが、こういった設計の機能が広く浸透するには時間がかかるでしょう。浸透させるためには、この Gem を利用するユーザーが増え、よりスタンダードな機能にしていくことが重要ですが、そう簡単ではないだろうとも感じました。
個人的には是非とも普及してほしい Gem だと思うので、自分でライブラリを作成する際や、deprecation の自動修正に共感してくれるライブラリを見つけた際には、積極的に活用していきたいと思いました。
（@rhiroe）
Matz Keynote - Programming Language for AI age（Day3）
発表
概要
毎年恒例の Matz による Closing Keynote です。今年は「AIとプログラミング言語」をテーマに、言語デザイナーの視点からプログラミング言語について論じられました。
犬における「アルファシンドローム」（ペットが自分がリーダーだと勘違いする現象）を紹介し、それを AI に当てはめ、「逆アルファシンドローム」という概念を提唱しました。これは、人間が AI のできない「面倒な」あるいは「望ましくない」タスクのみを担当し、AI ができる（そして人間にとって楽しいかもしれない創造的な）部分を AI に任せてしまうことで、人間が AI に従属してしまう危険性を指摘するものです。全体を通して、人間が主人であり続け、AI は奉仕者であるべきとし、プログラミングの楽しさや主導権を失わないために、どのタスクを AI に委任するかを意識的に選択する必要があると主張していました。
AI 時代に望ましい言語の特性として「簡潔さ（Conciseness）」「表現力（Expressiveness）」「拡張性（Extensibility）」の3点を挙げ、Ruby が全てを満たしている素晴らしい言語だとしました。AI 時代にはプログラミング言語ではなく、人間の話す自然言語が最適なのではないか、という可能性については、数式を例に挙げ、自然言語は形式言語に比べて正確性に限界があることにも触れました。
近年話題の静的型付けについて、不可欠かどうかについては疑問を呈し、役立つ場面もあるが、第一に必要なものではないかもしれず、過度に複雑なシステムは簡潔さや楽しさを損なう可能性があると指摘しました。
またセッションの最後に、今年は Ruby 4.0 がリリースされる（かもしれない）というサプライズもありました。
感想
今回の RubyKaigi では AI の話題がほとんどなかったなと思っていたところ、最後に Matz が話してくださいました。タイトルは「Programming Language for AI age（ AI 時代のプログラミング言語）」（「Programming Language for AI（ AI のためのプログラミング言語）」ではない点がポイント）。これは Matz にしか語れない内容だ！と、わくわくしながら聞いていました。途中、いつもの「静的型付き言語 vs 動的型付き言語」の話になっていったのも、風物詩の趣があり良かったです。
さて、Matz によれば AI 時代に求められるプログラミング言語とは「Concise, Expressive and Extendible」、つまり簡潔で表現力が高く、拡張しやすい言語であるべきだと。それは、つまり Ruby のことだ、というオチでした。
また、本題の前に語られていた「人間（プログラマ）と AI の関係」の話も非常に印象的でした。主従関係としては人間が主人であり、人間が AI に従うべきではないという考えです。この考え方は過去にも語られており、当時は「コンピュータ」だったものが、今回は「AI」に置き換わっている形です。何にせよ、主役は人間であるということを改めて再確認しました。AI を使えば色々便利になり、あれもこれも置き換えられると考えていた自分としては、ハッとする内容でした。
途中、「AI 支援を使っている人は挙手してください」という質問があり、半数くらいが手を上げていました。これは個人的には想像以上に多いという印象です。
Ruby は「たのしい」を重視している言語なので、我々ユーザーも「たのしい」から Ruby を選んでいて、それほど AI 支援に興味を持っていないのではないかと思っていたからです。（AI に仕事を奪われるのはもう仕方ないとしても、AI に「たのしい」ことを奪われるのは我慢ならないですよね。）
「人間が主人、AI が従者」という主張も、それが成り立つのは「Ruby がたのしい」という前提があってのことだと思います。AI の利用が拡大することで「たのしい」の価値や意味が無くなってしまうのではないかと危惧しています。
AI のサポートはこれまでそれなりに試しましたが、「よくある機能の作成」や「簡単な雑務」、「実装からテストの作成」くらいしかまともに使えていません。個人的には「要求から要件と仕様を作る」、「仕様からテストを作る」部分を AI でできるようになれば嬉しいなぁと思いつつ、普段の業務では自分がテストを書くしかない状況で、世の中の「AI すごい!!」みたいな空気に若干違和感がありました。
今回の話の中で、AI は奉仕者に過ぎず人間がプログラミングの楽しい部分を担うべきだという話には、共感しかありませんでした。自分にとって楽しい部分は「設計」と「実装」なので、その部分は自分でやりつつ、その他を AI がやってくれる未来がやってくると嬉しいなぁと思いながら聞いていました。
一方で、AI を駆使した方が工数やコストを削減できるという話もちらほら聞くことがあり、その影響で AI にできる部分を AI にやらせ、AI ができないことを人間がする、まさにこの話の中での逆アルファシンドロームが実現された未来がやってくる可能性もないとは言えません。そうならないためにも全てのプログラマには、人間が主導権を持つための AI に委任する作業の選択を意識的に行うようにしてほしいなと切に願います。
（@rhiroe）
The Ruby One-Binary Tool, Enhanced with Kompo
発表
概要
Kompo というツールを開発されている @ahogappa さんによる発表です。
Ruby のプログラムをワンバイナリにまとめるためのツール「Kompo」の開発とその進捗についての発表でした。
以前の発表（RubyKaigi 2024）時点では、require をオーバーライドして必要な Ruby スクリプトやライブラリを実行ファイルに埋め込む方式でしたが、Sinatra と SQLite 程度の規模のアプリケーションでしか動作しないという課題がありました。
今回の発表では、仮想ファイルシステムを構築することで以前の課題を解決し、Rails アプリケーションのワンバイナリ化に成功したことが報告されました。
感想
Ruby で実装したゲームをクロスプラットフォームで配布したいという背景から Kompo の実装を始めたとのことで、2日目に発表された「How to make the Groovebox」と同様に自身の趣味と結びついたセッションでした。
Kompo に関しては今回の発表で初めて知りましたが、Rails で作られたアプリケーションをワンバイナリにできるという発想がなく、単純に驚きました。
この技術が発展することで、Ruby のアプリケーションがより手軽に、より多くの環境で利用できるようになり、Ruby の発展に繋がりそうだと思いました。
クロスプラットフォーム化の部分に関してはまだ達成されていないとのことでしたので、今後の進展に期待しています。
（@Keisuke Kuwahara）
Analyzing Ruby Code in IRB
発表
概要
2024年から Ruby Committer となった @tompng さんによる、IRB における「解析」に関する発表でした。IRB の内部動作において、特にシンタックスハイライト、オートインデント、コード補完、コードの終了判定といった機能は、これまで主に Ripper というツールを使用して実装されてきました。それを、Ruby のパーサーである Prism への移行を進めることで、これらの機能の精度と堅牢性向上を図っているという内容でした。また、IRB でエッジケース的な “weird-code”（奇妙なコード）を受け取った際の挙動が、具体的な事例を交えて紹介されていました。
感想
普段何気なく自分が使用している IRB の奥深さ、シンプルなインターフェースの奥底にある課題に触れることができました。本セッションに限らず RubyKaigi ではパーサーにフォーカスした内容が多く、個人的に好きなテーマです。def を入力するとハイライトされる、end を入力するとオートインデントされるといった基本的な動作すら誰かがメンテナンスしてくれているんだな…と改めて感慨深い気持ちになったと共に、表現力が高く奇妙な構文を書ける Ruby ならではの様々な入力ケースが披露され、苦悩の歴史が垣間見えました。特に Nesting Analysis（ネスト解析）の内容に入ってからは「こんなコードも想定しなきゃいけないの？」と勝手に絶望的な気持ちになりながら見ていました。Prism への本格移行の道のりはまだまだ長いと思いますが、従来のトークンベース解析に比べて、AST（抽象構文木）ベースの Prism を使えば、IRB が担っていた独自の構文解析を委譲できる点が魅力的だと感じました。Ruby における楽しみがまた一つ増えた感覚があり、今後の RubyKaigi でも動向をウォッチしていきたいと思います。
（@edy629s）
終わりに
さて、本ブログにてタイミーによる RubyKaigi 2025 の参加レポートも終了となります。Day1やDay2に関してもブログを書いているのでよろしければそちらも併せてご覧ください。
今後も Ruby を利用する会社の一員としていろんな発信、貢献をしていけたらと考えているので、今後お会いした際にぜひ一緒にお話ができると嬉しいです！それではまた来年函館でお会いしましょう！
