開発部・アプリ基盤チームの深野です。
今回、弊社から自分を含む3名が松山で開催されたRubyKaigi2025に参加して色々なセッションを聞いてきました。
その3名で印象に残ったセッションのことや参加しての感想などを話し合ったものを文字起こしして、再構成したものが今回のブログになります。
なお、弊社はSilver SponsorとしてRubyKaigi2025に協賛させていただきました。
自己紹介
竹内: シンクロフード3年目の竹内と申します。普段は主にモビマルというキッチンカー関連のサービスの開発を行っています。Rubyに関しては、高校生くらいの時からやっていて、もう20年くらい前から触れています。RubyKaigiに関しては、今回が初参加となります。よろしくお願いします。
小島: 去年新卒で入社して今年で2年目の小島です。Ruby自体は入社前に1年内定者インターンで利用していたので今年でRuby歴3年目に入りました。3年目ですがRubyに関してはまだまだ初心者です。RubyKaigiの参加は初めてで、東京Ruby会議に今年の1月に参加しています。よろしくお願いします。
深野: 新卒でシンクロフードに就職してから、現在6年目になる深野です。Ruby歴は5年ほどです。RubyKaigiには、去年から続けて2回目の参加になります。RubyKaigi以外の技術カンファレンスですと、Kaigi On Railsに去年参加しました。よろしくお願いします。
印象に残ったセッション
Make Parsers Compatible Using Automata Learning
深野:竹内さんにまずは聞いてみます。今回RubyKaigiに参加した中で印象的だったセッションを1つ教えてください。
竹内: 僕はパーサーに興味を持っていたので、1日目の「Make Parsers Compatible Using Automata Learning」というセッションに興味を持ちました。
深野: そのセッションは具体的にどのような内容でしたか？
竹内: Rubyのパーサーにはparse.yとPrismという2つがあるのですが、その互換性を形式的な手法を使って違いがないかを確認するという手法の紹介でした。
小島: そもそも普段Rubyを書いていてパーサーが気になることってあまりない気がするのですが、なぜそもそもパーサーに興味があったのでしょうか？
竹内: そうですね。昔から言語処理系などを作っていたので、その時パーサーの手法などを色々調べていたという感じです。
小島: なるほど。昔から言語処理系を作っていたんですね。
小島: 深野さんも何か質問はありますか？
深野: 具体的にどのようにその2つのパーサーに互換性があるということを示したのでしょうか？
竹内: Automata Learningという手法が用いられています。ブラックボックスになっているパーサーを外からモデル化して、その内部構造を自動的に推定するという手法になっています。言語全体をモデル化するのは難しいのですが、その一部に着目することで違いを見つけていくことは可能だそうです。
深野: なるほど。ブラックボックスということはCやRubyなどで書かれたパーサーを静的解析したりするのではないのでしょうか？
竹内: 静的解析というよりは、ブラックボックスとしてパーサーを実際に実行した振る舞いから分析する手法となっています。そのため他の言語で書かれていてもこの手法を用いることが可能だと思います。
深野: なるほど。振る舞いの方を見るということですね。
深野:内容はなんとなくわかったのですが、どこが面白いと感じたのでしょうか。
竹内: そうですね。パーサーの振る舞いからオートマトンを形成するというアルゴリズムなのですが、一般的なRubyなどの文法では正規文法には収まりません。そのためどのようにオートマトンを作成していくのかが気になりました。正規言語ではないのでDFAなどでは扱えませんが、VPA（Visibly Pushdown Automata）と呼ばれる、正規言語より強い言語を表現できるオートマトンを使うというのが興味深かったです。文脈自由文法よりは弱いので全ては表現できないんですけども、今回の用途に実用できるほどの表現力を持ったオートマトンということで、興味を持ちました。
深野: オートマトンの授業で習う初歩的なものよりは広いけど文脈自由文法まではカバーできないオートマトンがあって、それを使ってパーサーの動きをオートマトンで表現したということなんですね。こんなことができるとは知らなかったです。
竹内: 一般的なオートマトンの授業で習うのがDFAやNFAだと思うんですけど、その次にプッシュダウンオートマトンと言って文脈自由文法を表現できるオートマトンの一種があって、VPAはその中間に位置するものですね。これだと、DFAのように共通部分や差分などを計算できつつ、DFAよりも強いという性質を持つ文法になっているそうです。
Ruby Taught Me About Encoding Under the Hood
深野: では、小島さんはRubyKaigi初参加だと思うのですが、面白かった講演はどちらでしょうか？
小島: 僕が印象に残っているのは初日のキーノートでima1zumiさんという方がお話されていた「Ruby Taught Me About Encoding Under the Hood」という、文字コードエンコーディングの発表です。
深野: 私と竹内さんは内容を知ってはいるのですが、ご存知ない方のために講演内容を教えてください。
小島: 1時間の発表なので内容が結構あるんですけど、最初に文字エンコーディングの歴史を手早く紹介して、その後、エンコーディングのハマりやすいところについて実体験を交えながら発表されていました。最後は、今後Rubyで文字コードエンコーディング関係のどういう改善をしたいかっていう話をしていただきました。
深野: 面白かった点は何かありますか？
小島: そうですね、僕はRubyKaigiに参加しているのにそんなにRubyに詳しくなかったのですが、Rubyに詳しくなくても話を通してわかるというのがまず助かったポイントではあります。面白かった点としては、半角カタカナがなぜ何のために生まれたかみたいな話だったり、普通のひらがなとかだと2バイト以上使っていると思うのですが、そういう文字の内部での扱いの話が面白かったです。他には、書記素クラスタという、僕ら人間が見た時の文字数みたいな概念があるらしいのですが、その話も面白かったです。
深野: ありがとうございます。そうですよね。私も書記素クラスタの概念などは知らなかったので勉強になりました。家族の絵文字が表示されるのは1文字なんですけど、内部的には4つのコードポイントで構成されているみたいな内容ですよね？
小島: 先ほど発表を見直したら7コードポイントでしたね、内部的には。
深野: あ、7つ。結合文字（Zero Width Joiner）があるからですね。内部的に7つのコードポイントを結合して、幅的には1文字の家族の文字ができてるみたいなのは知らなかったです。
竹内: 僕の興味を惹かれた点を言うと、Unicode15.1.0で追加された Indic Conjunct Break プロパティがあります。昔サンスクリットと一緒にデーヴァナーガリーを学んだ際に、文字の結合がかなり複雑になっていて苦労したのを思い出しました。例えば क् と ष が連続すると क्ष という全く見た目が異なる文字になったりします。
深野: なるほど。文字って奥が深いですよね。私はアルファベットと日本語の文字ぐらいしか詳しくないですけど、世界の他の国を見ていけばなんか違うルールだったり違う体系の文字がありますよね。西洋のソフトウェアのアスキー文字以外への解像度の低さに苦しめられてきた日本人としては、世界の多様な文字をソフトウェアでサポートしていってくれるUnicodeの新しいバージョンには積極的に追従していきたいですね。
On-the-fly Suggestions of Rewriting Method Deprecations
竹内: それでは深野さんは、今回のRubyKaigiで興味を持ったセッションはありましたでしょうか？
深野: 「On-the-fly Suggestions of Rewriting Method Deprecations」という講演が面白かったです。
竹内: 内容についてはどのようなものだったでしょうか？
深野: はい。こちらの内容は、プログラミングやライブラリのDeprecation Warning、非推奨警告の対応方法について整理した上で、Rubyについて今のシステムよりももっと自動化されたようなものを提案しているという内容です。具体的には、まずDeprecation Warningに関して、既存のプログラミング言語がどういった方法で対応しているのかをそれぞれ列挙した上で、それらの対応方法を自動化具合のレベル別に5段階でまとめています。著者はこのように5段階で表現した中で、Rubyで5段階目の自動化のその先まで考えようという内容になっています。
小島: 僕もこのセッションを聞いたのですが、ちょっと結末を覚えていなくて、Rubyで結局どうしようみたいな結末になったのでしょうか？
深野: 結末としては、発表者はPharoというプログラミング言語を参考にして、Deprecation Warningのランタイムでの自動修正ができるようなgemを作ったんですが、実際それにはまだかなり制約があるということでした。技術的な制約がまずありますが、それよりさらに大きいものが、Rubyのエコシステムがこれをそもそも採用するのかというところですね。現状、これは単なるサードパーティgemであって、言語の組み込み機能ではないですよね。言語の組み込み機能としてDeprecation Warningの書き換えをサポートしているようなものはC#などがありますが、Rubyはそうではありません。この機能を使うには結局gemの作者がこのgemを認識してもらうとか、逆にgemを使うユーザー側が自分でDeprecation Warningの書き換えルールを自分で書いて設定する必要があるという意味で、提案はしたけど、実際はまだまだ難しいんじゃないかという結論だったかなと思います。
小島: なるほど難しいのですね。ただ、個人的にはランタイムでの自動修正があったら嬉しいなと思うのですが、深野さんはどうでしょうか？
深野: はい。嬉しいなと思います。今は弊社ではDeprecation WarningについてはランタイムでSentryに通知して、それを見て手動でプルリクを作って直すということをやっているんですけれども、やはりどうしても手間がかかります。ランタイムでの自動修正みたいなところができれば、言語だったりフレームワークだったり、gemだったりのバージョンアップが全体的にもっとスムーズに行えるようになると思います。
竹内: 聞いていて興味深いなと思いました。今回の発表というのは、コードを実行した際にDeprecatedになっていて、変更すべきコードを自動的に書き換えてくれるという認識でいいでしょうか？
深野: そうですね。コードの実行時に書き換わるというような想定なんですけれども、もちろんこの機能はproduction環境での実行というのは考慮されていないようです。test環境だったり、あとはローカルのdevelopment環境などでコードを実行して、その時に書き換えるというようなのを想定しているという話だったと思います。
竹内: ありがとうございます。もし完全にできたらかなり有益だと思うんですが、主な技術的な制限というのはどのようなものがあるのでしょうか？
深野: そうですね。例えば、まず書き換えのルールとして単純なメソッドの書き換えというのはすごく簡単ですよね。例えばRubyのURIでしたら、URI.regexpが非推奨になったので代わりにURI::DEFAULT_PARSER.make_regexpを使うみたいにするというのはすごく簡単だと思います。ただし代替策がないような場合、つまりこのメソッドが使えなくなりますが、これと同じような処理をする代替メソッドが提供されたりしていないみたいなケースでは書き換えルールを設定するのがとても難しそうですし、発表時点のRubyのDepreWriterでは実装されていなかったようです。
竹内: ありがとうございます。確かに代替策がない場合とかコンテキストによってどう書き換えるかが変わる場合というのはありそうなので、完璧に実装するのは難しそうだなというのは理解できました。
Matz Keynote
深野: ところで、今回のMatzさんのキーノートについてはどのような感想を持ちましたか？
竹内: そうですね、私が特に印象に残ったのは1番最初に話されていたReverse Alpha Syndromeの話ですね。AIが発展していくにつれて、人間はAIのために働くようになってしまうのではないかという懸念についてです。確かに注意していかないと、人間が下僕になってしまうというのは確かにその通りかもしれないと思いますね。最近のAIエージェントによるコーディングを見ても少しそうなってきている感覚はあるので、プログラミングの楽しさを見失わない、忘れないようにしていくのは1つ重要なことかなと思いました。小島さんは何か感想などありますか？
小島: そうですね。今竹内さんが言ってくださったのは僕も同感です。後はそうですね、正直僕はMatzさんがRubyコミュニティにおいて何をしているかそんなに詳しく知らなかったのですが、キーノートの内容を聞いて、あ、この人がRubyのコミュニティのトップなんだなっていう感じがすごくしました。Rubyの将来まで見据えられていて面白い内容でした。
深野: 私は型についての話が印象的でした。最近の静的型付け言語ブームでは開発生産性や安全性などよりも、実は1番理由として大きいのは開発者が型のパズル的な側面が楽しいからなんじゃないかという大胆な話だったのですが、自分は結構共感してしまいました。実際にrbsを触っていたりするのはかなり楽しいですし。MatzさんはRubyに言語機能としての静的型付けを組み込むことに反対されているとは思うのですが、静的型づけ言語を触る楽しさの部分を認めてくれたのはいいなって思いました。
竹内: 最後にもう1点いいでしょうか。他に印象深かったのが、Rubyコミッターと、会場に来ている、セッションを聞いている人たちがそれほど壁がないという発言でした。ちょっとした巡り合わせやエネルギーの向き方で周囲に与える影響も大きく変わってきますし、小さなことでもRubyコミュニティに貢献できたりはしますので、そうした垣根っていうのはそれほど大きくないんだなっていうのは、Matzさんのメッセージの中で感銘を受けた部分です。
深野: 確かにそこはすごく重要なメッセージでしたね。
RubyKaigi全体についての感想
深野: 最後にRubyKaigiに参加しての感想を一言ずつ述べていきましょう。
竹内: 今回がRubyKaigiの初参加でした。10年くらい前はRubyコミュニティの動向を追っていたんですが、最近は離れている状態でした。今回参加して忘れていたRubyの楽しさを思い出せたのが非常に良かった点だと思います。小島さんは何か感想ありますか？
小島: 僕はRubyにそんな詳しくなくてそれでも楽しめるのかなって少し不安だったのですが、先ほど紹介したima1zumiさんのキーノートの内容もRubyをそんな深く知らなくても楽しめる内容でしたし、そういう発表がいくつかありました。あとはやっぱりRubyのコミュニティに触れるいい機会になるというか、参加したことでRubyを勉強するモチベーションも上がったり、色々いい影響を受けることができたので参加して良かったなと思ってます。深野さんはどうですか？
深野: 今回のRubyKaigiの感想というか、去年のRubyKaigiに参加してからの1年の感想になってしまうんですけど、同じ人の発表を連続して聞き続けるとその人の興味の変遷だったり、OSSを公開している方だったらその成果物だったりを追いかけられて楽しいというところに気がつけました。具体的には、Rubyで実装されたWebアプリケーションの高速化について、去年は速度の計測について話していたのが今年はそこから発展して実際にSinatraを改造して速くするという発表をされていたosyouyuさんの発表などです。去年のRubyKaigi初参加もとても面白かったのですが、それとはまた異なるRubyKaigiを縦で追い続ける楽しみというのを味わうことができました。
おわりに
一緒に参加した弊社メンバーと講演についての感想を話してみることで、自分が聞けなかった講演についても興味を深めることができたり、自分が聞いていた講演についても改めて内容を咀嚼したりすることができました。
RubyKaigiのオーガナイザーの方々や、発表者の皆さんへの感謝でこの記事を締めたいと思います。
来年のRuby Kaigiも非常に楽しみです。
