RubyKaigi 2026 に登壇しました
こんにちは。株式会社タイミーのバックエンドエンジニアの神山(@dak2)です。 2026/4/22 から 24 まで函館で開催された RubyKaigi 2026 に参加し、Day 2 に登壇しました。 タイミーでは、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度を活用し、8名が現地でカンファレンスに参加してきました。 登壇内容や参加セッションで得た学びは各レポートにまとめています。気になった方はご覧いただけると幸いです。読者の皆様の今後の学びの参考になれば嬉しいです。 tech.timee.co.jp tech.timee.co.jp tech.timee.co.jp Road To RubyKaigi 2026 地震や飛行機の遅延などもありましたね。皆様の中にも、移動に戸惑った方いらっしゃったのではないでしょうか。 色々大変でしたが、参加者の方々が無事到着されたのを X（旧Twitter）で見て、一安心したのを覚えています。 印象に残ったセッション A Faster FFI rubykaigi.org 自分が作っている gem で Ruby と Rust を使っており、FFI 周りが気になっていたので聞きました。 FFIは、引数の数の確認や型変換（アンボックス）を実行時に行う必要があるため、C拡張に比べてオーバーヘッドが大きいようです。また、ピュアなRubyで書かれたJITコンパイラのFJITはC拡張より速いものの、CRubyの内部データ構造に強く依存していました。そのため仕様変更に弱く、実用的ではなかったとのことです。 FJIT これですね。fjit.rb · GitHub これに加え、アーロンは hacks gem というものを作っていて、そこから CRuby の 構造体を引っ張ってきて FJIT で使っているみたい。AST をダンプして構造体の名前を元にデータ構造を抽出、メモリのレイアウト情報を計算して Ruby のハッシュに格納して返してるみたいですね。 面白いなー。すごい力技だw FJIT はこのハッシュに依存しているから実用的ではなかったとのこと。 新たな解決策として ffx という gem を作ったみたいです。 Ruby の値を C に変換してネイティブ関数を呼ぶ impl 関数と、実際のコードへジャンプするトランポリン関数を生成。トランポリン関数を生成する際に、アセンブリに impl 関数への jump 命令を書いておき、その次のメモリ領域にマジックマーカーや型情報、パラメータなどのメタデータを書き込んでおく。 通常の実行時には impl 関数へ jump するので、型情報などは読み込まれないけど、ZJIT でのコンパイル時にはマジックマーカーを検知してメタデータを読み取って最適化に使うとのこと。 このハックは単純にすごいなと思いました。感心しながら聞いていたのを覚えています。勉強になります。個人的に印象に残るセッションでした。 Lightning-Fast Method Calls with Ruby 4.1 ZJIT rubykaigi.org speakerdeck.com 行く末が気になる ZJIT ですね。速さは正義ということで、とても期待しています。そこで、このセッションを聞きに行きました。 今の ZJIT はメソッド呼び出し時に全てのパラメータを一度メモリにロードしてしまう課題があるみたいですね。 バックトレースや例外処理、ローカル変数読み込みなどでスタック上に正確なメタデータを残しておく必要があるためとのこと。 これに対し、Lightweight Frames が提案されていました。 メタデータの書き込みを遅延させ、書き込むフィールドを「JIT Return」の1つなど最小限に限定しつつ、メソッドコール時のメモリライトを削減すると。ただ、ローカル変数の処理や例外時の longjmp などをどうにかしていかないといけないみたいですね。帰ってきてから ZJIT の内部を読んでみています。 Matz Keynote なんか Matz が一番楽しそうだったなあと思う Keynote でした。Ruby という言語を作ってなお、まだ作りたいものがある。AI と一緒に作った Spinel を発表している Matz が楽しそうだった。AI Slop とか色々ありますが、作りたいものを作るって最高ですよね。最高にクールでした。非常にインスピレーションを受けた Keynote でした。 matz リツイート 登壇 登壇時の写真 special thanks to @ginkouno rubykaigi.org speakerdeck.com AI 時代の Ruby では、NoMethodError を静的に解析できたら良いのではないか、という内容で登壇しました。登壇は想像していた何倍も得るものがありました。 きっかけは「日常の疑問」だった このトークの種は、普段の業務で感じた引っかかりでした。型アノテーション付きの Ruby とそうでない Ruby を行き来していると、どうしても型チェックの遅さが気になります。一方で、AI Agent のコーディング能力が一気に上がったことで、「そもそも型をちゃんと書いていく ROI ってどうなんだっけ？」という疑問が、頭の片隅から離れませんでした。 この「気になり」を寝かせていたところ、CFP が1週間延長になった当日、サウナで急に像を結びました。よく「サウナで整うと閃く」と言いますが、実際は逆で、普段から問題意識を温めていたからこそ、たまたま緩んだ瞬間に繋がったのかなと思っています。整うどころではなくなり、速攻で帰りました。その後、寝る間も惜しんでアイディアを形にし、CFP を提出したのが懐かしいです。 「型ありの Ruby と型なしの Ruby、両方を日常的に書いている自分だからこそ立てられる問い」だと思えたことが、提出のモチベーションになりました。自分の業務の中の違和感は、思っている以上にトークの種になるんだなと。 gem を作って「持論」を形にした セッション内で発表した Method-Ray という gem は、コアロジックに Rust を用いています。命名は X-Ray から着想を得ていて、個人的にも気に入っています。「こうすればできるのでは」という仮説をもとに設計し、最小限で動くものを形にし、gem として公開しました。僕の持論やスタンスを gem に込めた上で CFP を提出しました。 株式会社mov の @pjocprac さんが型関連のセッション内容をまとめてくださっており、僕の発表内容にも触れてくださっているので、詳細に興味があればぜひご覧ください。 RubyKaigiで型まわりの内容をまとめたブログ書きました！RubyKaigi 2026 型まわり4セッション聴講メモ — AI コーディング時代の Ruby の型#RubyKaigi https://t.co/HZB5PJW7z0— Takeshi Watanabe (@pjocprac) 2026年4月27日 登壇して初めて得られた3つのもの 発表後、いろんな方に声をかけていただきました。「ここの型解析どうしてる？」「なんでそう思ったんですか？」「英語話せるんですか？」などたくさんお声がけいただき嬉しかったです。 自分の盲点を埋めるフィードバック 質問内容を受けて「自分の gem もこう直さないといけないな」と気づきが連鎖的に出てきました。一人だと気づきにくい視点に気づかせてくれるというのは良い機会だなと。 自分のスタンスを認識する 今回はスタンスを取った発表をしたのですが、それに対していろんな意見をもらえました。賛否両論あると思いますし、いろんな意見があると思いますが、同時に自分の立ち位置もはっきりしました。スタンスを取った発表をして良かったなと思っています。 アイデアの昇華 @okuramasafumi さんとは、いわゆる廊下の話で、「テストが十分速ければ AI が PDCA を回しやすくなって、それは型解析の近似になっているのでは」という方向性を議論しました。登壇内容を、登壇の外で次のテーマへと押し進めてもらえる感覚があり、これは登壇したからこそ発生した会話なんだと思うと、良い機会に恵まれたなと嬉しく思いました。 次にやりたいこと 今後は、Method-Ray の解析範囲を広げたいのと、RBS の Rust crate の利便性を高めたいですね。自分の gem で RBS のロードを Rust crate から行いたいなと思っています。また、廊下での会話の流れもあって、高速化にも気持ちが出てきています。登壇を経て、自分の中の「次にやること」のリストが、行く前より大きくなっています。 終わりに 今年の Kaigi も最高でした。運営の方々、本当に素敵な機会をありがとうございました。いろんな方と知り合えましたし、思考を深められました。ぼんやりと次にやりたいことが見えてきました。<a href="https://rubykaigi.o
- Ruby
- Rust
- 静的解析
- JIT
RubyKaigi 2026参加レポート
はじめに タイミーでは、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度を活用し、8名がRubyKaigi 2026 in 函館に現地参加しました。 また今年はDay2に、タイミーから @dak2 さんが "No Types Needed, Just Callable Method Check" というタイトルで登壇しました。 本レポートでは、参加したエンジニアが注目したセッションごとに、ポイントや得た知見をまとめてご紹介します。 各セッションごとに内容を整理し、参加者自身の視点から学びや気づきをまとめています。読者の皆様にとって、今後の学びの参考になれば幸いです。 Surviving Black Friday: 329 billion requests with Falcon! rubykaigi.org Shopify社のSamuel Williamsさん、Marc-André Cournoyerさん、Josh TeeterさんがFalconを導入することでブラックフライデー・サイバーマンデー(BFCM)期間の合計3,290億リクエストを乗り切ったお話でした。 自身は普段Webのバックエンドエンジニアとしてユーザートラフィックのパフォーマンス課題について関心を持っており、その流れでFalconや基礎技術のAsyncにも興味を持っていました。 Falconの開発者であるSamuelさんから、本番稼働中の高トラフィックなプロダクトにFalconを導入する際のコストや注意点、そして得られる効果を聞けると期待して、このセッションを聴講しました。 前提として、FalconとはAsyncベースのRack互換Webサーバーです。 AsyncとはRubyの軽量スレッドであるFiberを利用した非同期I/Oフレームワーク（ノンブロッキングI/O）です。 github.com Falconは単一プロセスの中で複数のHTTPリクエストに対応するFiberを割り当てます。 FiberでI/Oが発生すると、処理を別のFiberに移すことで、大量のリクエストの処理を実現します。 OSネイティブのプロセスやスレッドではなく、Fiberで並行処理を実現するためメモリ効率が良く、PumaやUnicornと比較してランニングコストが低いという特徴があります。 セッションではFalconのアーキテクチャの解説と導入に伴う段階的なスケールテストを通して多くの課題を解決していった様子を発表されていました。 取り組みの結果、従前のUnicornよりもスループット・コアあたりのリクエスト数・レイテンシが改善し、冒頭にもあったBFCM期間の3,290億リクエストを捌き切りました。 まず最初に自分が抱いた感想として、プロダクトの課題を解決しつつOSSコミュニティへの還元を忘れないという点に感銘を受けました。 導入の過程でFalconに対して行われた改善は誰もが利用できるようになっています。 Falconを実際のプロダクトに導入し、入念なテストを重ねてブラッシュアップしたうえで、個社最適化にとどめずOSSとして誰もが使える形で公開し、Rubyコミュニティ全体へ還元する姿勢に、エンジニアとしてとても憧れました。 また、発表の中でスケールテストの重要性について強くお話をされていたのが印象的でした。 最近の自身の関心ごとの一つとして、以下にテストをしやすい環境を作るか・本番に近い環境でテストができるかというものがありました。 Shopify社は「Genghis」というツールを用いてこれを行っているそうなのですが、詳しい情報が見つけられなかったのでご存知の方がいれば教えていただけると嬉しいです。 また、同社のテックブログを読むと「Game Day」と称してスケールテスト以外にもカオスエンジニアリングや障害のシミュレーションなどかなり大規模で入念なテストを行っていたことがわかります。 shopify.engineering ユーザー増加やキャンペーン施策によるトラフィックの増加は、パフォーマンスだけではなくランニングコストという面においても重大な関心事です。そうした状況で、Falconは有効な選択肢の一つだと感じました。 実際に触ってみて他のRack互換アプリケーションサーバーとどのような違いがあるか試してみたくなったので、まずは自身のローカルのRailsでFalconを動かしてみようと思います。 FalconのRuby on Railsの導入に関しては2025年のKaigi on RailsのキーノートでSamuelさんが発表しておりこちらもおすすめです。 kaigionrails.org 志賀(@akitoshiga) Practical TypeProf: Lessons from Analyzing Optcarrot speakerdeck.com @mametter さんによる、Rubyの型解析ツールTypeProfを、Ruby製8ビットマシンシミュレータであるOptcarrotに適用し、偽陽性の型エラーをゼロにするまでに何をしたのかという話でした。 TypeProfは、最小限の型注釈でエラー表示、定義ジャンプ、補完を提供するエディタ支援ツールです。型検査機にはSteepやSorbetがありますが、TypeProfはそれらとは異なり、型注釈をほとんど書かずにコードから型を推論します。 偽陽性の型エラーの原因は、実行時の不変条件が伝わらず、コード上nilになり得る型に対するメソッド呼び出しによるもの、動的メソッドで解析自体が難しいものなどがありましたが、本発表ではそれらをどう見つけどう直したかというものをAIの活用も含めてお話しされていました。 原因調査の中で、AIがキーポイントの調査において有効であることが語られました。実装全体の把握やその中でも特に多く呼び出される処理の特定は人間が調査するにはコストが高く不向きであると思うので、その部分をAIが十分に代替できるというのは素晴らしいなと思いました。 一方で、RBSでの型付けはAI任せだと雑になりがちなので一部は自分の手で直したと語られていました。まだまだAIは万能ではなく、人間が有効に使えているかどうかを判断する必要があり、場合によっては人の手で修正することが必要であるというメッセージとして受け取りました。 話の最後には同氏が以前公開された記事を踏まえ、型を書かないRubyがAIコーディングとの相性が良い可能性について触れており、その中で型の役割についてもガードレールとして機能するとされていたが、定量効果については慎重に評価すべきではないだろうか、としていました。 今後の展望としては、まずは人間向けに改善を進めていき、AIの使い勝手が安定してきた頃にAIエージェントを助けるためのツールとしての改良も検討しているとしていました。 RubyがAIコーディングと相性が良いかもしれないという示唆は、Rubyをメインで使っている者として、今後も使っていく価値のある言語である可能性を示されたような安心がありました。一方で動的言語であるが故に実行時エラーの懸念が常に付き纏いますが、そこを少ないコストで軽減できるツールとしてTypeProfの進化には期待したいです。 Rubyにおける型は、人によって意見が分かれると思います。個人的には、「型はあるに越したことはない。しかし、自分でわざわざ型注釈は書きたくない」という意見です。TypeProfは僕のようなRubyistにとって理想のツールとなる可能性があります。 RubyKaigi後、早速TypeProfを試してみようと思いましたが、RBSでモジュールエイリアスを定義しているとエラーによりTypeProfが起動しない問題に遭遇したので、PRを作成しました。 github.com 今後も自分にできる範囲でTypeProfの進化に貢献していきたいです。 rhiroe(@buta_botti) Ruby Releases Ruby rubykaigi.org @hsbt さんによるRubyのリリースを支えるRubyによる仕組みづくりについての発表でした。 今回の発表で印象的だったのは、数値で示されたリリースプロセスの進化と「徹底してRubyを使い込むこと」でした。 かつてRubyのセキュリティリリース現場では、最大4つの安定版ブランチにパッチを当てるために複数名のコミッターが5〜6時間に及ぶ深夜作業をされていたそうです。インフラ構成管理やリリーススクリプト、各種自動化ツールをRubyで揃えて改善を進めたことで、それが今や1名が1時間程度の作業で完了できる体制になったといいます。自動化による効率性向上に加えて、緊急性が高いセキュリティパッチ対応におけるRubyコミュニティのアジリティが底上げされたと感じました。 更に、リリースの頻度についても、2022年の年間9回から2024年の15回へと約1.5倍に加速しています。hsbtさん自身が、Ruby 4.0以降は「2週間に1回の頻度でリリースする」という目標を立てられているといい、既にRuby 4.0リリース以降から10回のリリースが実現できているようです。テスト基盤はGitHub ActionsとRuby CIの2系統で運用され、GitHub Actionsには約120のworkflowが存在するなど、幅広いプラットフォーム・ビルドパターン・コンフィギュレーションを継続的に検証できる体制が紹介されていました。 特に、開発版Rubyにおけるパフォーマンス向上やメモリ削減などの成果を現行の安定バージョンに還元するバックポートの仕組みや、OIDC連携によるTrusted Publisher、Sigstoreを用いた署名など、Bundlerを含むエコシステム全体に最新のセキュリティ標準が組み込まれていくことが紹介され、Rubyエコシステムの揺るぎない技術的信頼を感じました。 RubyによるRubyのためのリリースプロセスの改善が、あらゆるRubyistへの良質なユーザー体験を形作っているのだと感じられる発表でした。 江田（@edy629s） Lightning-Fast Method Calls with Ruby 4.1 ZJIT speakerdeck.com こちらのセッションでは今後のRubyの進化には欠かすことのできないZJITに関する内容でした。 特にメソッドコールに関する詳細なアプローチについて話されていました。 このセッションは今回の会場で一番広いホールで行われたのですが、そのほとんどの座席が埋まっているという状態で始まりました。 これはRubyにおけるZJITの注目度の高さが伺えますし、ShopifyのJIT開発チームでもYJITの頃から活躍されているk0kubun氏のトークであることからも多くの人を集めたセッションとなったのだと思います。 セッションの内容はメソッドコールにおけるRuby内部のアプローチについてRuby VMとYJIT、そしてZJITについて比較を行いながら話されていました。 まず最初にZJITのメソッドコール最適化の方法はいかにmemory writeを減らすかということに主眼をおいていることがわかりました。 メソッドコールはコードの実行においては多くの割合を占めるものであり、ここの部分での最適化の積み重ねが最終的に大きな改善となりうる箇所です。 本セッションではmemoryに加えてregisterの活用とそれぞれの活用順序を組み合わせることで、YJITと比べてもより高効率な最適化を目指したことを個々のステップを丁寧に説明されていました。 私はこのセッションにおいて、情報工学において誰もが習うであろうmemory, registerの組み合わせがいかに重要かを改めて認識することになりました。 CRubyという巨大な処理系においてもコンピューターの基礎となるアーキテクチャを駆使することで改善を積み重ねられるという事実に、ZJITという大きな取り組みの中にも基礎ありき
- Ruby
- Rails
- パフォーマンス
- テスト
RubyKaigi 2026は、SREにとっても"行く価値"のあるカンファレンスだった
こんにちは、タイミーでSRE業務を担当している徳富(@yannKazu1)です。 先日、函館で開催されたRubyKaigi 2026に参加してきました。Ruby本体やパーサ、GC、JITといった「言語の中身」を深掘りするカンファレンスなので、普段アプリケーションコードよりインフラ寄りの仕事をしている自分が行って楽しめるのか、という気持ちも少しありました。ですが、結果としてとても楽しめたので、感想を書いておきます。 SREが行っても普通に楽しめた 普段の仕事はRailsアプリケーションを安定して動かしたり、スケールさせたり、観測したりすることが中心です。Ruby本体にコミットするわけでも、パーサを書くわけでもないので、専門外の話も多いだろうと思っていました。 実際、聞いていて全部の細部までは追えないセッションもありました。それでも、 普段ブラックボックスとして扱っているGCやランタイムの中身が、作っている人の口から語られる 他社のRails運用をやっている人たちと直接話せる このあたりだけでも参加する価値を感じました。 Day 1のブースが意外と良かった 参加されたことがある方ならわかると思いますが、Day 2以降はブース巡りが意外と慌ただしくなります。スタンプラリーで人が流れたり、セッションの合間で時間が限られていたり。 その点、Day 1はスタンプラリーがまだ始まっていないので、ブースが比較的空いていてゆっくり話せる時間帯でした。立ち寄っても順番待ちがほとんどなく、エンジニアの方とじっくり話せます。 RubyKaigiにはほぼ例外なくRailsを本番運用している会社さんがスポンサーとして出展しているので、SREとしては「他社さんのアーキテクチャや困りごとを直接聞ける場」として、これがかなり面白かったです。 Railsで完結する vs クラウドネイティブに振り切る 複数の会社さんと話して興味深かったのが、「Railsの中で完結させるか、AWSのマネージドサービスに切り出すか」の判断基準が会社によって全然違うことです。 Railsはよくできていて、ActiveJob + Sidekiq、ActiveStorage、ActionCableなどを組み合わせれば、大抵のユースケースはRailsの世界の中で完結します。わざわざクラウドネイティブなマネージドサービスに切り出さなくても、運用負荷を抑えながら回せるケースは多い。 一方で、「ジョブの遅延が事業KPIに直結するので、マネージドサービスに切り出して水平スケールを確実にしている」と話す会社さんもあれば、逆に「今のスタックで十分捌けているし、Rubyエンジニアが運用できる構成に揃えたほうが組織的に強い」と話す会社さんもありました。 技術選定の基準として挙がっていたのは、ざっくりこんな観点です。 スパイク耐性が事業上クリティカルかどうか 運用するチームのスキルセットと採用市場 コールドスタートを許容できるワークロードか RubyKaigiは登壇者も来場者もアプリケーションエンジニアが中心です。そのため、「Sidekiqのままいくか、それとも切り出すか」といったテーマひとつとっても、「アプリケーション側からどう見えているか、何が嬉しいかつらいか」という視点で語られていたのが印象的でした。 普段、SRE系のイベントで「インフラ側の都合」としてこの手の話を聞くことが多い私にとっては、この視点の対比が非常に新鮮に感じられました。 「正解は一つじゃない」と頭ではわかっていても、SRE目線とアプリ目線では同じ意思決定でも見えている景色が違います。両方の視点を持っておくことが大事だなと、改めて感じました。 AI活用の温度感 もう一つ、多くのブースでも話題になったのがAI活用です。プロダクトへの組み込み、社内開発フローへの導入、営業・カスタマーサポートへの活用と、レイヤーごとに状況が違っていて面白かったです。 特に印象に残ったのが、SmartBankさんのブースで展示されていた「スマートバンクで働くAI Agentたち」のポスターでした。アプリユーザー向けの「ワンバンフレンズ」(家計を読み解いて気づきを届けるAIアシスタント)、社内メンバー向けの「Ask! ワンバン」(自然言語で社内データを検索・分析する分析AI)、そして開発者向けの「Guardie」(エラーや異常を検知してログ・コード・変更履歴を横断して原因特定を支援する番犬AI)という三本立てで、ユーザー向け / 社内向け / 開発者向けの3レイヤーに対してそれぞれAIエージェントを配置しているのがすごく整理されていて印象的でした。 特にGuardieはSRE視点でめちゃくちゃ刺さりました。「2時間覚悟していた調査が10分で終わった」という社内の声が紹介されていて、これは障害対応におけるMTTR(平均復旧時間)を本質的に短縮しに行っている事例だなと。エラー検知 → ログ・コード・変更履歴を横断した原因特定までをAIに任せる、というのはこれから我々も作っていこうと思っていた仕組みが普通に動いていて、刺激を受けました。 ブース担当の方とは「どこまでをAIに任せて、どこから人間がやるべきか」「誤検知や暴走への安全装置をどう設計しているか」みたいな話までできて、こういう一次情報が聞けるのもRubyKaigiならではでした。 気になった話は、その後のアフターパーティでさらに深掘りできました。資料には載らない現場のリアルな知見が交換される場として、ブース + アフターパーティの組み合わせは、セッションと同じくらい価値があったと感じます。 参加したセッションを日ごとに振り返る ここからは、自分が参加して特に印象に残ったセッションを日ごとに紹介していきます。 Day 1: Exploring RuboCop with MCP (Koichi ITO さん) 1日目に聴いたのが、RuboCopコアチーム・MCP Ruby SDKチームメンバーのKoichi ITOさんによる、RuboCopとMCP(Model Context Protocol)を組み合わせる試みについてのセッションです。 これまでRuboCopは「人間」または「他のプログラム（CIなど）」をきっかけに実行されてきました。そこにAI時代になって、AIエージェントという新しい実行のきっかけが登場した、というのが導入の話です。生成AIとリンター/フォーマッターをどう組み合わせるか、Rubyで実装されたMCPサーバーをエージェントの隣で走らせるとどうなるか、という内容でした。 技術的には、 MCP SDKの構造(サーバーとクライアントそれぞれのSDKがあること) トランスポート層としてstdioとStreamable HTTPの2種類があり、用途で使い分けること HTTPトランスポートではセッション管理が肝になり、Pumaのようなスレッドモデル + シングルプロセス構成だと素直に動くが、複数プロセス・複数ホストに横断するとセッションの保持が難しくなること ただしStateless Mode(stateless: true)を使えば、Pumaの複数ワーカーやUnicornのような複数プロセス構成にも対応できること。ただしこれはリクエストごとに新しいtransportインスタンスが生成されるためMCP-Session-Idを共有できないという制約とのトレードオフであり、「セッション保持を諦める代わりに複数ワーカー/プロセスでもスケールできる」という割り切り あたりが特に勉強になりました。特にセッション管理の話は、MCPサーバーをWebアプリケーションとして本番に乗せようとすると、ロードバランサーやスケールアウトとの兼ね合いが出てくるという点で実践的でした。ステートフル/ステートレスをどう使い分けるかは、これから考えないといけないテーマになりそうです。 セッションの締めくくりで「LLMの確率的な性質を決定的なツールに組み込むことで、これまでの決定的なツールとは違う未来が描ける」という話があって、そこも印象的でした。MCPのサンプリング(サーバーがクライアント経由でLLM補完を要求する仕組み)や、Elicitation(実行中にユーザーへ追加情報を問い合わせる仕組み)といった機能は、ツールの形そのものを変えそうな予感があります。 スライド: https://speakerdeck.com/koic/exploring-rubocop-with-mcp Day 2: Chasing Real-Time Observability for CRuby (Shintaro Otsuka さん) 2日目で一番テンションが上がったのがこのセッション。CRubyの実行状態をリアルタイムに3D可視化するというツール「rrtrace」の話でした。 普通のプロファイラはサンプリングベースで、後から集計して結果を見る形が多いですが、このツールは「いまこの瞬間にCRubyの中で何が起きているか」を、複数スレッドのスタック状態として3次元空間にレンダリングしながら見せる、というアプローチです。デモを見せてもらった時、IRBに入力するたびにスタックが積み上がっていく様子がリアルタイムで見えて、純粋に「すごいものを見ている」という感覚になりました。 技術的なポイントとしては、 計測側のC拡張は軽量に保つ設計で、イベントの収集と転送に特化している イベントはTracePoint API(CALL / RETURN / INTERNAL_GC_ENTER / INTERNAL_GC_EXIT)や内部のスレッドイベント(INTERNAL_THREAD_EVENT、こちらはWindowsでは利用不可)から収集し、timestamp(60bit) + event type(4bit) + method id/thread id(64bit)の合計16バイトの構造体に統一 C拡張(計測側)とビジュアライザプロセスの間はOS管理の共有メモリ上のリングバッファで受け渡し ビジュアライザ側はCRubyのコアを使っていない別プロセスなので、可視化処理が重くてもCRubyの実行を直接ブロックしない スタックシミュレーションが重いため、Parallel Scanアルゴリズムで並列化している という設計でした。ただし、スライドのベンチマーク結果を見ると、rrtrace有効時は関数呼び出しスループットがplain CRubyの17%程度(73,417,127 → 12,760,131 calls/s、約5.9倍遅くなる)、Railsサーバーのrpsもplain CRubyの55%程度(203.19 → 110.84 rps)になるとのことで、計測のオーバーヘッド自体は「小さくない(not small)」とスライドでも明記されていました。TracePointフックのコストが支配的で、ここは今後の課題とのことです。 それでも、「重い処理を別プロセスに全部寄せる」というアーキテクチャの考え方は面白かったです。計測側はできるだけ軽く保って、分析・可視化は別のリソースでやる。この割り切りが設計をシンプルにしていて、きれいだなと思いました。 「現代のマシンは10コア以上あるのが普通で、CRubyが1コアで動くなら残りのコアを観測やビジュアライズに自由に使える」という、リソースの捉え方の話も新鮮でした。GVLがある世界での観測ツールの設計思想として、納得感が強かったです。 スライド: https://speakerdeck.com/whitegreen/chasing-real-time-observability-for-cruby Day 3: The Less-Told Story of Socket Timeouts (Misaki Shioi さん) 3日目に聴いたのがこれ。ソケットライブラリのタイムアウトの歴史と内部実装を、Issue/Commitを参照しながらRuby 4.0までの流れに沿って解説していくセッションでした。タイトルからして気になっていたけど、期待以上の内容でした。 Socket.tcp / TCPSocket.new には、 resolv_timeout (名前解決のタイムアウト) connect_timeout (接続のタイムアウト) そしてRuby 4.0で追加された open_timeout (全体のタイムアウト) の3種類があります。「この3つがなぜ必要で、どういう順番で導入され、どんな歴史的な紆余曲折があったのか」を、Issue/Commitを参照しながら丁寧に追っていく構成でした。 特に印象的だったのが、 まず Socket.tcp に connect_timeout が導入され、続いて Addrinfo.getaddrinfo への timeout および Socket.tcp への resolv_timeout が追加されたこと resolv_timeout と connect_timeout を両方指定しても、全体のタイムアウト時間は制御できない(複数アドレスに対して逐次接続を試行するため、合計時間が想定より長くなりうる) これらの問題を解決するために、Ruby 4.0で全体時間を管理する open_timeout が追加された という話の流れです。普段、HTTPクライアントのopen_timeout/read_timeout/write_timeoutを「だいたいこのくらい」で設定しがちですが、その下のレイヤーでは名前解決と接続が並行で走っていて、タイムアウトの組み合わせによっては想定と全然違う挙動になるということを、改めて意識させられました。 また、歴史的な経緯として特に面白かったのが、名前解決の中断可能化(interruptible)をめぐる話です。 getaddrinfo(3) はブロッキング呼び出しで、Ctrl+C でも中断できないという問題が長年ありました。これを解決するアプローチとして、まず2020年1月に「Addrinfo.getaddrinfo が timeout をサポートする」提案が行われ、そのパッチで Addrinfo.getaddrinfo に timeout、Socket.tcp に resolv_timeout が追加されると同時に、内部的に「GNU拡張のgetaddrinfo_a(3)が利用可能ならそれを使う」実装が入りました(getaddrinfo_a(3)はワーカースレッドで非同期に名前解決を行う仕組み)。その後2020年8月には「Make Socket.getaddrinfo interruptible」がマージされ、Socket.getaddrinfo の内部もこの getaddrinfo_a(3) を使うように利用範囲が拡張、さらに2020年9月には TCPSocket.new にも resolv_timeout / connect_timeout が追加され、名前解決を中断可能にする方向で進められました。 ところがその後、Rails ActiveJobの統合テストが失敗するようになったという報告が入り、調査の結果、fork後の子プロセスでgetaddrinfo_a(3)を呼び出すとハングすることが判明します。getaddrinfo_a(3)は内部で再利用可能なワーカースレッドを保持しているのですが、forkでコピーされる子プロセスにはワーカースレッドが存在しないにもかかわらず内部状態は「ワーカースレッドが待機中」のままになっており、これによってデッドロックが発生する、という仕組みでした。 2ヶ月以上の調査と回避策の検討を経て、最終的にはgetaddrinfo_a(3)の導入自体が撤回され、関連変更もrevertされました。その代わり、後に別アプローチとして「名前解決ごとに専用のpthreadを立ててgetaddrinfo(3)を実行する」方式(mameさん提案、ruby/ruby#8695)が採用され、こちらはrsock_getaddrinfo内に実装されることで、内部的にrsock_getaddrinfoを呼んでいるAddrinfo.getaddrinfoやSocket.getaddrinfoを含む幅広いメソッドで名前解決のブロッキング問題が解消された、という流れです。 外部API連携で「タイムアウトを設定したはずなのにハングする」「connect_timeoutを短くしたのに、複数アドレスがあるホストで合計時間が想定の何倍もかかる」みたいな経験がある人は少なくないと思いますが、まさにあれの背景にある話でした。タイムアウト設計の見直しや、Ruby 4.0以降はopen_timeoutを積極的に使っていくこと、テストでタイムアウト周りの挙動を確認しておくことなど、すぐに持ち帰れる学びがいくつもありました。 スライド: https://speakerdeck.com/coe401_/the-less-told-story-of-socket-timeouts リモートワーク時代の副次効果 もう一つ書いておきたいのが社内メンバーとの関係性の話です。 弊社エンジニアはリモートワーク中心で、普段の業務だと開発チームの全員と毎日話すわけではありません。SlackやZoomでは話すけれど、雑談ベースで「最近どう?」みたいな会話になりにくい人もいます。 それが、RubyKaigiで3日間一緒に過ごすと一気に距離が縮まります。一緒にセッションを聞いて、休憩中に「今のどう思った?」と話して、夜は飲みに行って、移動中に雑談する。この3日間の密度は、リモートでの数ヶ月分のコ
- Ruby
- Rails
- SRE
- 観測
- 生成AI
rubydex MCPでClaude Codeのトークン消費は減るのか？タイミーモノリスRailsで検証した
こんにちは、タイミーのバックエンド/Webフロント基盤チーム マネージャーの新谷（@euglena1215）です。 先日開催された RubyKaigi 2026 に参加してきました。その中で特に気になったのが、Shopify の Alexandre Terrasa さんによる「Blazing-fast Code Indexing for Smarter Ruby Tools」という発表です。 この発表では rubydex という Rust 製の Ruby Code Indexer が紹介されていました。RubyLSP や Tapioca に統合することで最大10倍の高速化と2倍のメモリ削減を実現したという内容でした。また、Ruby ツールのための統一的なコードインデックス基盤としてのビジョンも示されていました。Shopify の Ruby DX チームが9名関わっているということで、Shopify への rubydex への本気度が伺えます。 発表の中では、Experimental ながら MCP サーバー（rubydex-mcp）も提供されていることが紹介されていました。Claude Code などの AI アシスタントからセマンティックにコードベースを検索できるようになっています。 AI Coding Agent にコードベースを調査させると、Grep → Read → また Grep…というループが延々と続き、トークンがみるみる消費されていきます。rubydex-mcp を使えば、クラス定義やリファレンス、継承ツリーといった構造的な情報を、1回の MCP ツール呼び出しで取得できます。そのため、このループを大幅に削減できそうです。 実際にどの程度効果があるのか、タイミーのバックエンドリポジトリで定量的に検証してみました。 rubydex とは rubydex は Shopify が開発した Ruby Code Indexer です。 github.com Rust 製の Indexer がコードベースを解析し、MCP（Model Context Protocol）サーバーとして以下のツールを提供します。 ツール 機能 search_declarations 名前によるファジー検索（クラス、モジュール、メソッド、定数） get_declaration 完全修飾名による定義情報の取得（ドキュメント、祖先チェーン、メンバー） find_constant_references 定数の参照箇所をコードベース全体から検索 get_descendants クラス/モジュールの継承ツリーを取得 get_file_declarations ファイル内の構造一覧 codebase_stats コードベース全体の統計情報 通常、AI Coding Agent がコードベースを調査する際は grep や find でファイルを探し、Read で中身を読み、また grep で次のファイルを探し…というループを繰り返します。rubydex を使うと、このループの多くが1回の MCP ツール呼び出しで完結できる可能性があります。 検証方法 概要 claude -p（Claude Code の非インタラクティブモード）を使い、rubydex あり/なし の2条件で同じプロンプトを実行し、トークン消費量と回答品質を比較しました。 検証環境 ツール：Claude Code CLI (claude -p) モデル：claude-sonnet-4-6 rubydex_mcp バージョン：0.1.0 対象リポジトリ：タイミーのバックエンド（モジュラーモノリス、70パッケージ） 条件の制御 外部要因を排除するため、以下の共通オプションを使用しました。 claude -p "<prompt>" \\ --output-format json \\ # トークン使用量を含む JSON 出力 --model sonnet \\ # モデル固定 --bare \\ # hooks, CLAUDE.md 等を無効化 --strict-mcp-config \\ # .mcp.json を無視し引数の MCP 設定のみ使用 --mcp-config <config> \\ # 条件別の MCP 設定 --tools "Read,Bash,Edit" \\ --no-session-persistence --bare で CLAUDE.md の自動読み込み等の副作用を排除し、--strict-mcp-config により MCP サーバーの有効/無効を制御しています。これにより、2条件間の差は rubydex の有無のみになります。 プロンプト rubydex のツール群が効果を発揮しそうな質問を5種類用意しました。 ID プロンプト class_hierarchy XXXモデルのクラス継承チェーンと、includeしているモジュールの一覧を教えてください。それぞれのモジュールがどのファイルで定義されているかも含めてください。 find_references YYYモデルがコードベース全体でどこから参照されているか調査してください。参照元をコントローラ、モデル、サービス等のカテゴリ別に分類して一覧にしてください。 descendants ApplicationRecordを継承しているクラスの一覧を取得し、packs/ディレクトリ配下のパッケージごとに何個のモデルが存在するか集計してください。上位10パッケージを表示してください。 method_investigation XXXモデルに定義されているpublicインスタンスメソッドのうち、名前に'status'を含むものをすべてリストアップしてください。各メソッドの定義場所（ファイルパスと行番号）と、そのメソッドが何をしているかの簡単な説明を付けてください。 codebase_overview このRailsプロジェクトのpacks/ディレクトリ配下のパッケージ構成を調査してください。各パッケージに含まれるモデル数、主要なクラス名を一覧にし、パッケージ間の依存関係で特に密結合なものがあれば指摘してください。 各条件 × 各プロンプトで5回ずつ、合計50回実行しました。LLM の出力は非決定的なので、複数回実行して平均を取ることでばらつきの影響を軽減しています。 結果 トークン消費量 プロンプト rubydex なし（平均トークン） rubydex あり（平均トークン） 変化率 class_hierarchy 144,076 85,958 -40.3% codebase_overview 1,187,722 664,761 -44.0% descendants 46,501 165,795 +256.5% find_references 770,404 332,369 -56.9% method_investigation 986,840 636,411 -35.5% 5つ中4つのプロンプトで 35〜57% のトークン削減 を達成しました 🎉 コスト・速度 プロンプト コスト変化 実行時間変化 ターン数変化 class_hierarchy -16.7% -48.6% -35.4% codebase_overview -34.3% -19.6% -13.7% descendants +294.6% +261.0% +62.7% find_references -33.5% -19.0% -11.9% method_investigation -30.7% -50.1% -38.1% ターン数（エージェントのツール呼び出し回数）の削減がトークン削減の主因です。rubydex のセマンティック検索が Grep → Read の繰り返しを置き換えることで、エージェントループが短縮されています。 回答品質（LLM-as-a-Judge） トークンが減っても回答品質が下がっては意味がありません。別の Claude セッションを立ち上げ両条件の回答を渡し、正確性・網羅性・有用性の3観点で5点満点のスコアリングを行いました。 プロンプト rubydex なし（平均） rubydex あり（平均） 差分 class_hierarchy 4.33 4.00 -0.33 codebase_overview 4.33 4.00 -0.33 descendants 3.00 4.67 +1.67 find_references 4.00 4.00 0.00 method_investigation 3.33 4.33 +1.00 平均 3.80 4.20 +0.40 回答品質はむしろ改善しています 👏 Judge のコメントから見えた傾向を簡単にまとめます。 rubydex ありで改善した点（正確性） rubydex なしの場合、grep の結果をもとに関連しそうなクラスやメソッドを補足情報として列挙する傾向があった。目視では誤情報は確認できなかったが、裏取りが不十分な状態で情報を出しているため信頼性の判断がしにくい（method_investigation など） rubydex ありではインデックスに基づいた情報を返すため、出力の根拠が明確になっている rubydex なしが勝った点（網羅性・有用性） grep ベースの調査は探索範囲が広いため、rubydex が返さないカテゴリ（Policy、Mailer 等）の参照元も拾えていた（find_references） rubydex なしの回答はファイルのフルパスや構造図を含むなど、開発者がすぐに使える形に整理されている傾向があった（class_hierarchy, codebase_overview） 総じて、rubydex ありは正確性で優位、rubydex なしは網羅性で優位という傾向が見られました。また、いくつかのプロンプトの回答を目視でも確認しましたが、rubydex ありで明らかにおかしな内容を回答しているケースは見られませんでした。 descendants が悪化したケース 唯一、descendants プロンプトではトークンが +256.5% と大幅に悪化しました。 このプロンプトは「ApplicationRecord の子孫クラスをパッケージ別に集計する」という内容です。rubydex の get_descendants ツールは全子孫を忠実に返します。（我々の環境では346クラス）一方、rubydex なしの場合は grep -r "< ApplicationRecord" のような検索で主要なものだけを拾うため、結果的にトークンが少なく済んでいました。 つまり、大量の結果を返すような網羅的な検索では、rubydex がかえってトークンを増やすケースがあります。ただし、品質面では rubydex ありの方が +1.67pt と最も大きく改善しており、正確性とのトレードオフと言えます。 まとめ 5つ中4つのプロンプトで 35〜57% のトークン削減 と 17〜34% のコスト削減 を達成しつつ、回答品質は LLM-as-a-Judge の評価で同等以上（5点満点で 3.80 → 4.20）でした。特に「クラスの参照元を探す」「メソッドの定義場所を調べる」といった構造的な検索タスクで効果が顕著です。 一方、全件取得のような網羅的検索ではトークンが増えるケースもあり、万能ではありません。rubydex が提供するツールの特性を理解した上で導入すると、より効果的に活用できそうです。 また、現状 rubydex-mcp を利用するには Rust ツールチェーン（cargo）が必要で、ソースからのビルドが求められます。開発環境の依存が増えることになるため、チーム全員が使える形に整備するかどうかはもう少し見極めたいところです。とはいえ、トークン35〜57%削減という効果は十分に大きく、rubydex-mcp への期待はとても高まる結果となりました。 検証の制約 今回の検証にはいくつかの制約があります。結果を解釈する際の参考にしてください。 --bare モードでの検証: CLAUDE.md 等が無効化されているため、通常利用時とはベースのトークン消費量が異なります キャッシュの影響: 実行順序や間隔によってキャッシュヒット率が変わるため、コスト比較は参考値です 回答品質の評価: LLM-as-a-Judge による自動評価のみで、正解データとの突合は行っていません プロンプトの偏り: rubydex が得意そうなタスクを選んでいるため、実際の利用での改善幅はこれより小さくなる可能性があります
- Ruby
- Claude Code
- MCP
- 生成AI
福岡Rubyist会議05に行ってきました！
福岡Rubyist会議05 参加レポート こんにちは！Timeeでバックエンドエンジニアをしている志賀(@akitoshiga)です。 表題の通り「福岡Rubyist会議05 」に参加してきたのでそちらのレポートを書きたいと思います！ regional.rubykaigi.org 今回「Kaigi Pass」という社内制度を利用して参加しました。 「Kaigi Pass」とは、世界中で開催されているあらゆる技術カンファレンスへの参加を支援する制度です。 productpr.timee.co.jp 会場の様子 当日は福岡県福岡市博多区にある「リファレンス駅東ビル」というところで行われました。 会場いっぱいに来場者が集まりとても賑わっていました。 また、会場には福岡県八女市の名物である八女茶が提供されていました。 自分もいただいたのですがとても美味しかったです。 セッション 特に自分の関心が高かったセッションを3つほど紹介したいと思います。 SQLQL とは何だったのか 発表者 : yancya(@yancya)さん www.slideshare.net yancyaさんが取り組まれているSQLQLについての概要と、技術の変遷に伴ったアップデートのお話でした。 SQLQLとはWebクライアントからSQLクエリを送信して、その実行結果をJSONで返すというコンセプトです。 GraphQLのSQL版と考えるとイメージが掴みやすいと思います。 SQLQLに関しては以下で詳しく解説されています。 SQLQL #Rails - Qiita Client Challenge なお、ここではRDBMSにPostgresを使用することを前提としています。 SQLQLはクライアントが任意でSQLを送信できるので、これを安全に使えるようにするためにさまざまな工夫が施されていました。 WITH句によるCTEを使って取得対象のDBをラップすることでアクセスできる属性を絞り、秘匿すべきデータへのアクセスを制限しています。 INSERT, UPDATE, DELETEといった副作用を伴う操作に関しては自由に実行できないようにSELECTのみの権限しか実行ユーザーには与えず、定義した書き込み権限のあるストアドプロシージャでしか副作用のある操作を実行できないような仕組みを取られていました。 また、悪意のあるクエリの対策としてpg_queryによってクエリをパースしてAST（抽象構文木）をチェックしていました。 課題も存在していて、再帰処理にはうまく対応できないそうです。 SQL ServerやMySQLは再帰処理の深さを設定できるのですが、Postgresだと存在していないため代わりにタイムアウトのみで設定しているそうです。 クライアントでクエリをフェッチすることが可能になるので、これを用いたときにAPI開発コストの削減に繋がるのは良さそうだなと思いました。 ビジネスロジックがストアドプロシージャに集中してしまわないかなというのと、サーバー側ではクエリを効率化できないのでデータ量が多かったりリレーションの複雑なテーブルからデータを取得する場合はクライアント側で工夫が必要だなと感じました。 SQLをそのままパラメーターにしてWeb経由でクエリを投げるアイデアと、安全性を担保するためのさまざまな試みに技術者のロマンを感じました。 再帰処理に関してはPostgreSQLに存在するCYCLE句を使えば安全に扱えそうなのですが、そうすると特定のRDBMSに依存してしまうのと、クライアントとクエリの決め打ちをしなければならずコンセプトと乖離しそうな気がするので悩みどころだなと感じました。 今回はこのSQLQLのアップデートとしてWAL監視のアイデアを取り込んだデモアプリを披露されていました。 WAL（先行書き込みログ）とはデータベースに変更を行う前に操作内容を記録するログのことであり、このWALを監視することでリアルタイムなデータストリームの観測が可能で、このアイデアをSQLQLに応用されていました。 WAL監視については自分は初見だったのですが、CDC（Change Data Capture）の実装に利用されたりしているそうです。e.g. Debezium Server このほかにもSQL標準の変遷やLive QueryなどSQLQLを起点としてDB 、データ基盤についての幅広いお話を伺いました。 Live Queryで話に上がっていたKafka Streamsについては内部動作と構造に興味が湧いたので後日その深掘りをしてみました。 また、WAL監視については今後複数コンポーネント間でリアルタイムにデータ更新を検知したいときなどにこのアイデアが役立ちそうだなと思いました。 型を書かないRuby開発への挑戦 発表者 : shia(@riseshia)さん speakerdeck.com 自作GemのTypeGuessrのお話。 TypeGuessrは「型情報を開発者が追加せずに型情報を得る」ことをコンセプトに開発されたGemで、Ruby LSPのアドオンという形で使用します。 github.com Rubyに型情報をもたらすツールはいろいろありますが、SteepやSorbetといったような型定義を行い正確な型情報を得るものとは明確に棲み分ける形で開発されています。 Hash/Arrayに対してStructural Typing（構造的部分型）をサポートしつつも複雑な型推論が走りそうな場合はあえてuntypedにして計算量をコントロールしています。 特徴として、Duck Typingに基づくヒューリスティックな推論を用いて型情報を取得しており、クラスに定義されたメソッドをそのレシーバーから辿ることによってこれを実現しています。 この方法でも行数が10万行以上のRailsプロジェクトであれば平均10%〜20%で型情報を得られるそうです。 Duck Typingを利用して振る舞いから型を推論する部分はRubyらしさを感じるとともにユニークで興味深いなと思いました。 まだできたばかりでパフォーマンスには向上の余地があるそうで、このアプローチでどのようにこれらを解決していくのか動向を追ってみたいなと思いました。 少し話は逸れますが、型検査ツールのパフォーマンス改善という話でふと去年の関西Ruby会議で聞いたpockeさんのこのキーノートを思い出しました。 speakerdeck.com Steepのメモリ削減のために自作のプロファイラで観測してプロセス間通信のレベルまで踏み込んで改善に取り組んだ過程がとても面白かったので、よかったらこちらもチェックしてみてください。 Ecosystem on parse.y 発表 : S.H.さん S.H.さんが開発されているparse.yを利用したGemであるkanayagoとigata、そしてこれらを組み合わせたエコシステムのお話 parse.yとはRubyの文法定義ファイルのことで、昨今のRubyist界隈を取り巻くパーサームーブメントを語る上で欠かせないものです。 parse.yはRubyコミッターのydahさんの以下のスライドがparse.y周辺の情報やパーサー自体についても丁寧に解説されていて理解しやすいです たのしいparse.y - Speaker Deck S.Hさんはこのparse.yを利用して、パースしたAST（抽象構文木）ノードをRubyクラスとして扱うことができるkanayagoを開発されました。 github.com ASTをRubyオブジェクトにすることで従来よりももっと手軽にASTを扱えるようになり、パターンマッチングにも対応可能になっています。 これによってコード解析・構文チェックなどといったRubyの文法のASTに関する操作がとても直感的・簡単に行えるようになっています。 またS.Hさんはこのkanayagoをベースとしてigataとkanayago-lspを開発されました。 github.com igataはkanayagoが生成するRubyクラス名、メソッド名、引数の情報などを抽出してMinitestやRSpecに対応したテストファイルを自動作成します。 これに加えてLLMと組み合わせて、テストの中身まで自動補完させる運用も想定されています。 kanayago-lspはkanayagoを用いてVSCodeやVimなどで利用でき、Rubyの新しいパーサーであるPrismでは検知できないものも検知できるそうです。 S.Hさんはこのparse.y、これを利用したkanayagoを利用したエコシステムの構築を目指しており今後はLinterの開発を目指しているそうです。 S.HさんのASTに使われる各ノードを体系立った独自のRubyクラス群にラップするというアイデアがとても素晴らしいなと思いました。 parse.yから生成できるノードは100種類以上あるのでかなり根気がいる作業だと思いましたが、ここは生成AIをうまく活用されたそうです。 Ruby3.4からデフォルトパーサーがparse.yから生成されるパーサーからPrismに置き換わりましたがparse.yの根強い人気というか盛り上がりを感じました。 先ほど紹介したTypeGuessrもそうなのですが、何かを作るにあたりよりRubyらしさを追求するアプローチをみなさんされていて、このマインドはRubyistに通じるものなのかなと感じていました。 これらは開発のお手伝いをしてくれる方を絶賛募集中とのことです。自分もとても興味があるので機会があればパッチを投げたいなと思いました。 そのためにkanayago自体も積極的に使ってみたいと思います。 これらの他にもこの日の
- Ruby
- SQL
- 静的解析
- AST
- Gem