Ginza.rb 第90回

『Ginza.rb 第90回 - Wasmについて学ぶぞ』に参加した。会場はメドピアさん。今月もありがとうございます。

ginzarb.connpass.com

y-yagi さんが進行をされた。ルニさんからもお墨付きとなっている y-yagi さんによる資料は以下。y-yagi さんのスライドの完成度が高いので当日のストーリーの流れはそちらで。@y-yagi's Slide Is All You Need.

y-yagi.github.io

今回が Wasm の話だったということで、TryRuby のデフォルトバージョンが CRuby 3.3 なことから、当日までに 3.4 対応できると良さそうだったものの、Wasm 力が足りず断念。ひとまず y-yagi さんやルニさんが解決に近い位置におられそうということが分かりました。

本題の Wasm は今年の RubyKaigi 2025 でも youchan と ledsun の登壇でも取り上げられていたのは記憶に新しい題材。多様化するジャンルに得手不得手はあるのがふつうの人類だと思っており、自分は Wasm はよくわかっていない側の人類なので大変勉強になりました。

Wasm は W3C による仕様で、Wasm ランタイムに対して Wasm バイナリーが乗る形になるという基本的なアーキテクチャから説明されつつ、Rust の Wasm では速度が出ている一方で、CRuby の Wasm はそのあたりまだ改善の余地があってという現状を知るにも良い機会でした。あと kateinoigakukun さんの偉業という点に何度も言及されていたけれど、本当にすごい。

余談ですが、個人的には .rbenv/shims の shim とスマホの sim カードの sim をごっちゃにしていて、そもそも単語が違うという知識訂正の機会になって良かったです。shim は高さ調整の詰め物といった意味合いで画像検索するといろいろと出てくるのをもとつねさんに教えてもらったりしていました。

次回の Ginza.rb は 2025年7月4日(金)開催予定で、Gumroad をテーマに取り上げられる予定です。

github.com

『RAG・AIエージェント[実践]入門』を読んã

『RAG・AIエージェント[実践]入門』を読んだ。ひとまず細かいところは流しながらの一周目という位置付け。

LangChainとLangGraphによるRAG・AIエージェント［実践］入門 エンジニア選書

まとめると、アプリケーションレイヤーから操作利用する LLM について書かれているので、LLM アプリケーションの実装イメージがイマイチ浮かばないという人にオススメできると思う。なので、Vibe Coding とか生成 AI を使ったコーディングとかではなく、構築対象のアプリケーションへの LLM の組み込みがテーマ。

レビュアーには、セコンさんこと舘野さんが関わっていたのがびっくりしたポイント。セコンさんが関わっているなら信頼が上がる形で読んでいた。また、この業界の入門タイトルの書籍なのに、ちゃんと入門書になっている点もポイントだった。

ざっと Slack に流していたものをベースに感想を書き残しておく。

2章では、そもそも API の話ということで、はじめに課金に関わるトークンの算出について示しているのが良い。さらに toktoken で算出できるシンプルなサンプルコードで示されているのが、具体的なトークンを見れるようになっている点としても良い。トークンそのものの中身については『LLM自作入門』に詳しいので、この書籍で扱うものではなく出過ぎてない感じでもあった。Chat Completions API の Function calling 機能を分かりやすく説明してあった。さらに 2024 年後半の情報が付加価値になっている書籍なので、賞味的にもはやめに読んでキャッチアップしておくと良さそう。

3章。プロンプトエンジニアリングの基礎書籍を先に読んでおいたので、それがコードに基づいて説明されている形と読めて理解が捗った。OpenAI 公式のクックブックからの引用となる、Few-shot プロンプティングで例示を会話履歴とさせないための、name の example_user と example_assistant にする手法は良い付加情報だった。このあたりまた読み返しておきたい。

4章。RAGの実装についてどのようにコンポーネントを構成すれば良いのか考え方を得られた。基本は PromptTemplate (入力) → LLM / Chat model (処理) → Output parser (出力) といういわゆるいつもの処理の流れ。LangChain という名前にもあるこのチェーンという流れを表現するのに LCEL を使うのがいまどきということで、それはそうなるかという表現だった。とりわけ RAG において、ドキュメントをベクトル化して保存したベクトルデータベース (e.g., Chroma) を使って入力を絞り込むのは、LLM に対するトークン数の絞り込みを事前に行ってからという話でそれはそうとなった。きちんと1章のトークンはコスト (お金) という話から繋がっている。コスト試算できるの重要。コラムにあった4次元以上のベクトルの距離について、マンハッタン距離、ユークリッド距離、コサイン類似度は、知識が薄いとそれぞれの違いがどう出ていくかイメージが難しい部分もあるものの、『数式なしでわかるAIの仕組み』や『LLM 自作入門』を先に読んでいるとイメージは付くものだった。LangChain 全体像としてのコンポーネントと、RAG に関するコンポーネントの俯瞰した理解と、それぞれの関連について知れたので基礎として完璧な章だった。

5章。LangChain Expression Language (LCEL) は、Rails において ActiveRecord::Relation を返す scope ã‚„ where 的なものとして捉えられた。RunnableLambda といった簡易構文的なものから RunnableParallel といったワークフローの並列化といったものまで用意されていて、なかなか興味深いものだった。ワークフローということで、読んだ後に Workflow Patterns のサイトを思い出した。このサイトも息が長い。

www.workflowpatterns.com

6章は出だしから良かった。最初に示されている RAG From Scratch のリンク先記事 は Fine-turning と RAG の対比として良い記事 (この記事で RAG の A を Assisted としているのは、Argumented の typo なのかな) 。RAGを使ったLLMアプリケーションの具体的なデザインの考え方を知ることができた。特にベクトルデータベースと LLM を連携させるプロンプトの工夫なんかは参考になる。概念レベルで4章の応用編という感じ。この章では特に HyDE (hypothetical DocumentEmbeddings) の考え方は参考になった。ベクトルデータベースから LLM 問い合わせという流れしか考えていなかったけれど、LLM に仮説の回答を立てさせてベクトルデータベースを調べるのなるほどと思った。あとインデクシングについては、全文検索エンジンでも必要な考慮に通じそうだし、キャッシング周りの機構について気になっていたところ GPTCache の存在に触れていた点はかゆいところに手が届く感じだった。おすすめ論文2本は知っておいて良さそう。

arxiv.org

arxiv.org

7章の RAG アプリケーションの評価は、正直あまり現段階では関心が薄いけれど、仕事だと必要になる知識だと思うため、ざっと LangSmith を使った場合はどういったものかを知るのに読んだ。これまでと少し毛並みが異なるトピックが章として入っているのは流石だったものの、カンファレンスで集中力が切れている状態で読んでいる状態に近い形になった。ひとまず LangSmith と Ragas が RAG 評価に使えるものということはわかったものの、書かれている詳細を掴めていないので改めて腰を据えて読むことにする。この章はとりわけ API 課金が発生することを度々書かれていて、LLM アプリケーションを学ぶ書籍はこういった点に注意が払われているようだ (それはそう) 。また、この章は特に手を動かさないと覚えが悪そうな点は、2巡目読む時に気をつけておこうと思う。

8章の前半は『AIとコミュニケーションする技術』やそれに近い書籍の知識を先に付けてでおくと、アドバンスド的により深い話として理解できると思う。ここまで記されてきた RAG の知識をもとに、AI エージェントをどのように構成するかの知見を得られるのと、特に近年 (2022, 2023) の論文から語られているのが根拠がしっかりしている感じで面白い。ふつうに読み物としても何度でも読めそう。2022年ごろからの論文が多く参照されていた。

2023年の論文。

arxiv.org

コマンドプロンプトの定石である「ステップバイステップで考えて」とプロンプトに付与する手法は、Zero-shot Chain-of-Thought プロンプティングという名前がついている。Few-shot CoT と Zero-shot CoT の対比はなるほどなあ。2022年論文。

arxiv.org

MRKL System の論文。これも2022年で熱量が高い時代という感じがする。

arxiv.org

たしかに、CoT で LLM での複雑なゴールをタスク化するエージェントの土台が示されているというのは、なるほどなあ。

Reasoning and Actions (ReAct) こそ、RAG の動きの原型ではという感想。論文はこれまた2022年。

arxiv.org

Plan-and-Solve プロンプティングは、Zero-shot による中間推論ステップによる推論誤りへのカウンターというのは分かるけれど、いい感じにできない作業者への、計画を依頼側で立てての詳細な指示感あった。論文は2023年。

arxiv.org

また、8.4で紹介されているマルチエージェントフレームワークのひとつである、MetaGPTのStandardized Operating Procedures (SOP) の手順と工程間の中間成果物は、ウォーターフォール感あった印象で、このあたりはまた後で読もうと思う。8章の最後はいわゆるAIと社会の話だった。運用でどのようなことを考慮するべきか端的にまとまっていた。

9章のLangGraphはワークフローということは分かり、10章は9章の具体例ということで、雰囲気のみで流し読みとしていた。

11章と12章はエージェントデザインパターン。Agent Design Pattern Catalogue は 2024 年の論文。個人的には、世代的に18のエージェントデザインパターン熱い。

arxiv.org

12章でいくつかのパターンの具体例になるけれど、紙面の都合もあるだろうし全パターンがあるわけではない。結城先生がエージェントデザインパターン本を書いてくれると理解が捗る気がする。11章は論文と照らし合わせてもおもしろそう。セルフリフレクションとKPTが通じるというの面白かったりした。後半は斜め読み気味だけれど、ひとまず知識としての初期インデックスは張れたと思う。

エージェントデザインパターンは、日本語でもとっくに注目されているところでは注目されており、LLM アプリケーションへの知識の遅れを改めて実感したので、隙間時間で見ていくつもり。また 12 章ではコードが snipet になっていたりもするので、付録を見るか公式の GitHub リポジトリでコードを見た方が理解が進むと思う。

github.com

感想まとめ。

• 理解補助のための図が結構入っているのは読みやすさに繋がっていそう。
• さっと読んでいく形だと、5章後半あたりから徐々に難しくなっていっている。
• 読めば読むだけ、LLM アプリケーション設計への視界が拓けていっているのが実感できて良い。
• 読んでいて、Web+DB アプリケーション開発は依然として続いていくのでそれはそれとして、今後に向けて LLM アプリケーション開発の能力はきちんと磨いておいた方が良さそうと改めて思った。
• Python の知識が少ないくても雰囲気で読めるにしても、どこかで身につけておいた方が良い。

オススメの星5つとしか良いようがない書籍だった。

『数式なしでわかるAIのしくみ』を読んã

『数式なしでわかるAIのしくみ 魔法から科学へ』を読んだ。RubyKaigi 2025 から帰ってきてから読み始めていたもの。

数式なしでわかるAIのしくみ　魔法から科学へ

先日読了した『AIとコミュニケーションする技術 プロンプティング・スキルの基礎と実践』と、まだ概念的に難解な部分がある『つくりながら学ぶ！LLM 自作入門』の橋渡しとして読んでようと思った一冊。LLM の処理はブラックボックスという特性があり、ブラックボックスなりにどういったものか概念レベルでも理解を深めたいというのが大きな理由。

人工知能 (AI) 、機械学習 (ML) 、ディープラーニング、LLM の関係が以前より分かるようになったのと、ニューラルネットワークとは何かというのを分かる気になれた。ニューラルネットワークへの、人間の脳のようなのは分かったから、つまり何？という先の具体的な何がが分かるようになったのは大きい。そういった人にとって、これは知識を促進できる良書だと思う。

自分は1周して理解できる気はしていなかったので、ひとまず1周目はどんなことが書いてあるか、ざざっと読み進めた形になる。全8章からなり、以下は読み進めていた際に "koicのdev/null" という名の、勤務先 Slack の分報に夜な夜な記していた感想をベースにした感想など。

• 1 章の「内挿 (interpolation) は良いが外挿 (extrapolation) はダメ」 (24p) と「相関は因果にあらず」 (26p) は覚えておくと良さそう。誤差逆伝播法 (Backpropagation) は Wikipedia のページにもなっていた。「アシロマの原則」は具体的な名前のついたものとして知ることができた。
• 2章は AI の知らざる部分、あるいはディープブルーや Alpha Go などで知っていた歴史を交えて面白かった。とりあえず、GPU とアルゴリズムとインターネットによるデータの三本柱が揃った現代が AI への土壌として整備された時代となっていることが良くわかった。この章は特に読み物として面白かった。
• 3章の、k近傍法、ランダムフォレスト、サポートベクターマシン (SVM) それぞれについて、もう一度読んでみて良さそう。
• 4章は草原のメタファで良くわからなくなった。勾配降下法と誤差逆伝播法は何となく雰囲気は分かってきたものの、ニューラルネットワークにおける初期化について、いまいち消化不良していて、AI に聞いて復習したりしていた。結果として、99ページの初期化について読み違えていたことが分かった。図4-1の人工ニューロンは理解できたので、1周目の4章としては良しとしている。実装的には微分が関わる領域なんだろうな。
• 5章はちょっと本腰入れないと一回読んだだけでは良くわからんといったものだった。128ページに示されるように、畳み込みニューラルネットワークには、インプットの後に畳み込み層とプーリング層の繰り返しが加えられて、それらの後に密層がありアウトプットになるとまでは分かった。有効受容野という用語については一度調べると良さそう。ひとまず専門外過ぎて覚えることが多いので、RubyKaigi より分からない部分もあった気がする (つまりおもしろい領域) 。わからなくても、まず概念を知りたいという要求には応えてくれる。機械学習のデータセットには、モデルを学習させるための訓練セットと、モデルの性能を測るためのテストセットに分けているというのは、技術的に汎用的に使えそうな発想だった。
• 6章は GAN (敵対的生成ネットワーク / Generative Adversarial Networks) と拡散モデルで、結構斜め読み気味に読んだ。画像生成AIとか、そもそも画像生成とか普段使わないので、いまいち身近なもの感がなくて関心が引かれづらかった。GAN の方が拡散モデルよりは原理が理解しやすかったけれど、拡散モデルのは結構斜め読みした部分があるのでそれはそう。元画像への完全な再現を求めていない場合は、元画像よりもクリアな画像を生成できるというのは、それはそうなんだけどおもしろい発想だった。168ページの0から画像を生成しているから、というのが分かったような、そうでもないかもなところがあったので、AI で確認しておいたりした。
• 7章は、『LLM自作入門』を読んだ方が詳しく載っている。モデルごとに結果が違う例なんかは、まあそうですよねという形。この章は眠気と戦いながら読んでいたとはいえ、これまでの章と比べて焦点がぼんやりしたイマイチな内容だった気がする。とはいえこの章にあった、再帰型ニューラルネットワーク (RNN) と Transformer アーキテクチャの違いは、もう少し調べて良さそう。Attention についての記載が雑だったように見えるので、あとでもう一度読もう。『Attention Is All You Need』に触れていたし、自分の目が滑っていただけかもしれない。このあたりは『つくりながら学ぶ！LLM 自作入門 』を読めばさらに詳しい理解に進めると思う。つまり『LLM 自作入門』を読み始めるにあたっての周辺知識への理解向上の狙いは成功したといえる。
• 8章は、AI の現状とちょっとした近未来に対する考察。著者の AI 観に基づいた展望の話という意味では、先日読んだ『AIとコミュニケーションする技術 プロンプティング・スキルの基礎と実践』の終盤と似たような書籍構成かもしれない。AI が自分たちにどう影響を与えるのか？ということを考えている人は、このあたりは読み物として、最後にある「日本における AI 動向」もあわせて読むと良いかもしれない。

大きな点としては、4章を読み終わったあたりで、人工ニューラルネットワークについて以前より分かった気になれたこと。まとめると以下の図にあるニューロンのネットワークを誤差逆伝播法で誤差を伝播させて、勾配降下法で重みとバイアスを最適化するもの。であっているかな？

https://ja.wikipedia.org/wiki/ニューラルネットワーク

いや、すごい。何がすごいかというと、分かった気になれたときの「おれってば、すげー感」がすごい。実質的に、何も分かっていないのにすごいと思わせるのはすごい。

個人的には、5, 6 章をきちんと理解しようとするなら、結構パワーが必要そうだった。読み進めるにあたっては、とりあえず AI の用語やモデルでわからない点は AI に聞くのが良い復習になる。書籍としては巻末に用語集があるので、そのあたりをチマチマ眺めながら理解が足りていない部分など、自身への発見を楽しめると思う。

LLM をとりまく世界への入門としては、現代の AI 技術への影響を与えた論文として『Attention Is All You Need』はすごいということは分かった。つまり Self-Attention は LLM を理解するキーになるのではと思う。

技術への理解について、実装からの理解と概念からの理解というものがあると思っているけれど、この書籍で概念理解における知識のベースアップをできたと思うので、ふたたび『LLM 自作入門』を読み進めてみようと思う。

つくりながら学ぶ！LLM 自作入門 (Compass Booksシリーズ)

The Rails Doctrineの日本語訳を公式に送った

高橋征義会長が訳した The Rails Doctrine (日本語訳) を公式のリポジトリに送った。

なお、本記事執筆時点ではまだ公式に取り込まれてはおらず、現時点での高橋会長の日本語訳の掲載先は以下の Qiita 記事。

qiita.com

rails/website に送った PR は以下で、先の RubyKaigi 2025 で高橋会長に相談して快諾いただいたうえで行ったものになる。そういった意味で、これは私にとって今年の #KaigiEffect のひとつ。

github.com

AI 翻訳が一般的になっている現代でも、この日本語訳を公式に送る意味があると思った一つ目の理由。The Rails Doctrine のページでは、プルダウンでいくつかの言語の翻訳に切り替えることができるが、現時点では英語、ドイツ語、スペイン語、フランス語、ロシア語、简体中文、繁體中文となる。ここに日本語がないのは寂しく思っていたところ。

rubyonrails.org

有名どころのサイトの日本語訳という意味では、アジャイルマニフェストも平鍋さんによって訳されているという歴史があり、それと似た意味合いとして公式サイトの The Rails Doctrine に日本語訳があるのは意味のあることだと思っている。

agilemanifesto.org

二つ目の理由として、日本語で読めるのであれば高橋会長の訳はとても良いと思っている。日本の Rails 黎明期に、Rails importer として Rails を広めてられた高橋会長によって日本語訳された The Rails Doctrine を公式で読めることは意義深いことだと思っている。高橋会長が Rails を輸入してから約20年後に、その思想となる The Rails Doctrine の日本語訳が輸出されるのは趣がある話だと思う。

以上が、The Rails Doctrine に日本語訳の PR を開いた経緯になる。以下はローカルでのスナップショットだが、PR がマージされたら公式サイトで参照できるようになる。

iPhone を機種交換した

RubyKaigi Day 1 で液晶を壊してしまったので買い替えた。

液晶の左に常に緑の縦線が入って、日が経つにつれどんどん線が太くなるライトセーバーみたいな事象が起きていた。正直、一部の文字も読めなくなっていって困っていた。そのままだと緑の発光で QR コード読み取りができないので、空港ではスクリーンキャプチャして、ライトセーバーのラインから外れる位置に QR コードを移動してパスしていた。なんだこのハック。

帰宅した翌日に購入。残念ながら求めていたモデルは Apple ストアで在庫切れだったので、キャリアのショップで購入したため、高くついてしまった。店員さんに聞いたところ、まとめると社会はきびしいという感想の事情を聞いてなんだかなあとなった。

直近だと、2018年1月に iPhone X に機種交換して、その年の8月に基盤を壊してしまって同機種の交換が起きて以来、約7年ぶりの機種交換。

koic.hatenablog.com

koic.hatenablog.com

仕事の PC についても、2月に Intel Mac から M4 Mac にして処理が高速化された上に熱を帯びなくなったけれど、今回の iPhone の買い替えについても同様の印象。チップの進化は偉大。

RubyKaigi 2025 に登壇した

RubyKaigi 2025 に登壇しました。参加者としての感想も、RubyKaigi 会期に関することは、まとめてこの記事に記しておきます。

rubykaigi.org

当日の発表スライドは以下です。

自分の発表について

満員御礼だったようで、ありがとうございました。自分の登壇を撮ることはできないので @kenchan のツイートから拝借。

#rubykaigi #rubykaigiC @koic 〜 pic.twitter.com/i5ModfAnRT

— 研ちゃんくん鑽Rubyプログラミング (@kenchan) 2025å¹´4月17æ—¥

今回は去年話した『RuboCop: LSP and Prism』の続編的な位置付けでした。RuboCop が LSP や Prism を備えたことを背景に、RuboCop 自体にどのようなことを行なったか目玉の3つを取り上げています。

LSP と Prism の続編という意味では、Plugin の話は少し逸れているかな？と思いつつ、現時点でおそらくユーザー影響があるのは Plugin が一番だろうと思いテーマに含めました。結果として話は大きくなり、松山到着の Day 0 で脳内リハをした際には 1 時間近く掛かっていたので、これは巻きで話さねばと話しました。今回の Plugin 対応に関わる設計の中心はこの図に収めたつもりです。興味があればコードと照らし合わせてみると、何か発見があるかもしれません。

いくらか端折る形になった部分もあったため、トークで疑問があれば X でのメンションや Rails/OSS パッチ会などでご質問ください。

ここでは、本編の第3部として話している AST の洞察に関するトークのまとめとして話し損ねたことを書き残しておきます。少なくとも現状における RuboCop が依存する AST のインタフェースは、あくまで Parser gem の AST であり、Parser gem が事実上の機能拡張なしのメンテナンスフェーズに入った現在においても、インタフェースとしての AST は生きています。つまり、Parser gem から Prism に実装が変わってもインタフェースは維持されるので、「実装に対してではなくインタフェースに対してプログラミングをせよ」という GoF (Gang of Four) がデザインパターンで伝えていることは、現代においても重要というものでした。実装よりもインタフェースは長生きするので API 設計や選定重要。

そのうえで、処理系間とツールチェインが同一のパーサーを使うことを Universal Parser と定義するならば、現状の RuboCop は Prism によってそれを実現している状態。一方で、AST は Universal であるべきか？というのは AST 利用者としても関心のある命題。本編では AST は利用者ごとに求める抽象度が異なるのでは？というのが以下の図。

このあたりはふつうに判断が難しい部分なので、引き続き要検討といったところです。少なくとも RuboCop の Parser gem AST を、まったく構造の異なる構文木である Prism AST に置き換える作業は、おもしろくない作業だと思っています。AI エージェントとかそういった発展の先じゃないと、人間が無限に行う作業としてはつらい割に対価が薄いんじゃないかな。どうだろう。

また、RubyKaigi 初日にスマホを壊してしまったため、あまり X や Discord を見れていなかったのですが、今後の Parser gem についての状況としては、Prism translation layer は Parser gem の内部クラスへの依存があるため、すぐに RuboCop の依存先からドロップされるということはないというか削除できません。いずれ、Parser gem を解体して必要なモジュールを適材適所に引っ越しするということはあるかもしれませんが、特に議論が進んでいるわけではないのと喫緊の課題ではないため、追々必要があれば検討がされていくと思います (余談ですが Prism translation layer から parse.y への依存は現時点でもありません) 。

ひとまず、RuboCop のバックエンドのデフォルトパーサーでユーザーの裏で動いているのは、Ruby 3.3 までは Parser gem であり、Ruby 3.4 では RuboCop 1.74 以前のデフォルトは Parser gem で、RuboCop 1.75 以降のデフォルトは Prism translation layer となっています。少なくとも Parser gem は実質開発が止まったため、今後は Prism translation layer で解析されていくでしょう。

発表後には、RuboCop コアチームメンバーで RuboCop RSpec のヘッドメンテナーをしている Benjamin Quorning とも会えたというのが今回。

コアチームだと、RubyKaigi 2018 で Bozhidar Batsov と会って、最近だと RubyConf Taiwan 2023 やその他何度か Ted Johansson と会ったりしましたが、こういったカンファレンスは GitHub でのみ知っているという開発者をリアルで知れるのは面白いところ。Benjamin は pocke さんと会いたかったみたいで繋げたかったのですが、1,500 人のカンファレンスだとなかなか難しい。1,500 人本当にすごい。

RuboCop Plugin, RuboCop 向け Ruby LSP Add-on, バックエンドパーサーへの今後の展望

Plugin について、Shopify の ufuk から rubocop-sorbet でプラグイン化による lint_roller 依存でちょっと困っていることがあるような相談があったけれど、残念ながら私の英語力では問題認識は概ねわかったものの、それは本当に問題だろうか？といったところで、うまく答えることができなかったなあというところ。ただ、rubocop-sorbet としての問題だと思うので、RuboCop としてそれを機にドラスティックな何かというのは今の段階だとなさそう。

Ruby LSP Add-on については、何か行なっていくとすると、まずは組み込み LSP のクライアントとなる vscode-rubocop の方で textDocument/codeAction 対応をした後に、組み込み言語サーバー側の方で Ruby LSP にしかない不足機能を足すということを行うかなといったところ。以下の図で表すように、Ruby LSP Add-on へのエンジン共通化に向けた基盤はできたので、良い感じに機能面を統合できると良さそう。

バックエンドパーサーの方は、Prism ならびに Prism translation layer へのバグ報告がくることがあるので、その対応やトリアージなんかは平常運転の範囲内で見るつもりです。

ただ、これらは基本線はひと段落しているものと捉えており、現時点での個人的な関心事は LLM 周辺の領域と Ruby のあいだにあるので、気が向いた時にという感じで行うと思います。こういった OSS 活動は趣味なので、軸を持ちつつ気の赴くまま。

印象に残った登壇をいくつか

聞いたセッションぜんぶは書けないのですが、ひとまず筆が動く部分について書きます。

ima1zumi さんのキーノート

ima1zumi さんのキーノートはとても良くて、The Tap あたりでもご本人に話したように、おそらくはじめて ima1zumi さんを認識したのは家族の絵文字の一家離散のツイートで、おもしろいことする人がいるなあというのが始まり。その後、同僚の頃には文字コードや文字エンコーディング好きとして Ruby にどんなことができるかというのを考えていたのを見てきているし、そういった Rubyist としての ima1zumi さんの集大成といった話で心に響く良いキーノートでした。

私自身も職業プログラマーとしてキャリアのはじまりに EBCDIC に触れることになってしまっていた経歴があるのですが、そこでエンコーディングに対してより深い関心や楽しさを持てるかどうかで人類は別れ道があるんだなあ (当時だとなんで ASCII じゃないだとか、仕事の範囲で止まっていたのを思い出す) 。次回作にも期待しています！

TRICK

TRICK はどれもすごかったけれど、個人的に一番感動したのは mame さんの、git log --oneline を使った TRICK 芸。git は 365 日使うわけで、そんな毎日使っている馴染みのツールと組み合わせた実行方法という、聞けばわかるけれどそもそもの発想がすごくて、これが天才か。。。というものが本当にすごかった。

人類には2種類いる、人類と人類でないもの、ということを改めて認識しましたが、TRICK の人たちは本当に後者ですね。

Lightning Talks

LT は勤務先の大先輩である卒業生の kkd が LT とは？なぜ銅鑼？という話をされたのが良かった。その後の LT としては、ydah さんや makicamel さんの発表は特に良かった。makicamel さんは個人的には今年開催された東京Ruby会議12の (前夜祭込みでの) ベストトーカーでしたが、今回もトークのセンスが素晴らしくてさすがでした。

kkd のトークについて、「あれ？」と思ったのは kkd 自身があまり Rubyist の外の人っぽい感じで話しているのが他人行儀だなあという感じがある点でした。これを言えるのは数少ないと思うので、ここの日記に書き残しておきたいのですが、私が現職に入社した 2004年11月の社員旅行で kkd と出会い Ruby の話で盛り上がり、2005年4月1日に発行された勤務先のメルマガに「【News】Rubyが制約言語に正式採用へ」という記事を書いているくらいに、Ruby と関わりが長い古参の Rubyist です。

objectclub.jp

この記事は 4月1日発行ということでエイプリルフールなわけですが、今回 Matz が Ruby 4.0 のリリースについて 2025年4月1日のエイプリルフールにツイートされ、20 年越しのエイプリルフール繋がりで LT の壇上で銅鑼を叩くとか個人的にエモかった。RubyKaigi すごい。

sue445 さん

sue445 さんの話は、Ruby で Go 拡張できるようにするために、想像していたよりもはるかに多くのことを行っていたり、その副産物をライブラリ化したりなど、長い年月で積み重ねてきた感ある話でさすがでした。ひとつの目標を立てて、うまくいくこともあればないこともあるのはそうなのですが、きちんと時間を使って目標に向かって取り組み続けているのが、sue445 さんのキャラクターもあいまって、RubyKaigi は趣味を本気で突き詰めている人たちだなあと思いました。

ぺんさん

ぺんさんの話は、Prism が出てくるところもあり、自分以外でも Prism の使い勝手どう？みたいな話としてされている点として興味深く聞いていました。その後にも、ぺんさんと話したりしたのですが、Linter / Formatter はひと区切りついた、通常は妥当なシンタックスのコードを相手にできるものですが、IRB のような REPL だと入力中の不完全なコードを相手取る必要があり、そのあたりの難易度は上では？と改めて聞いていて思いました。多角的な考察の上にどうデザインされると良いかという思考も改めて参考になりました。ぺんさんは本当にすごいひと。

The Parser gangs

yahonda さんの言葉を借りれば、Parser gangs (金子さん、ydah さん、junk0612) は去年よりも、LR パーサーによって Ruby の世界をどのようにしたいかが見えてきたトークだったと思います。個人的には ydah さんの発表で最後に出てきた、Prism 互換の部分について「お、ついにそこに手が動くのか」といったところ。

金子さんとは今回あまり話せなかった気がするので、そのあたりは SmartHR さんの事後勉強会あたりで話したりあるかも？

今後の 362 日

最近は LLM が関心事として高くなっているところ、期せずして Matz のキーノートでも AI が取り上げられていたこともあり、引き続き AI 時代の Ruby の在り方みたいなものはひとつのテーマとして見ていくかもしれません。LLM の Fine-Turning となると Python という話になる気がするのですが、自分の発表中で少しだけ触れた RAG, LangChain, MCP あたりをキーワードとしたアプリケーションやライブラリと LLM の間というあたりはまだ Ruby としてフロンティアに近い部分もあるのでは？と見ていて研究中。次回に向けては、そのあたりをやるかもしれないし、それ以外かもしれない。いずれにしてもしばらく LLM について研究するかなというところです。次回作にご期待ください。

廊下会議や The Tap トラックなどで得られた会話など

伊尾木さんや江渡さんといった10年以上ぶりにお久しぶりですのご挨拶ができたり、今回初めて RubyKaigi に参加したという Rubyist と話せたりと、新旧の時代を楽しめる感じのイベントでした。

会場の廊下を歩いていたら、youchan が gibier (ジビエ) が WASM 2 対応で gibier2 (ジビエ2) になったと、実はジビエのゴッドファーザー (命名者) の私に教えてくれました。どこの居酒屋だったかは忘れてしまったのですが、本当に酒の肴で須藤先輩の Rabbit を打倒するプレゼンテーションツールを目指すという話題から生まれた名前が、後年の RubyKaigi にジビエ2として登場するいうまさかの展開で、Rubyist 同士の会話はどこでどう未来の RubyKaigi につながるか分からないので、Ruby のミートアップでは色々な人と色々と話してみると面白いと改めて思いました。

高橋会長とは、The Rails Doctrine の日本語訳 を upstream に送るのはどうかという話をすることができました。長らく話そうと思って失念していたことだったので、状況を伺えて良かったです。

えにしテックの島田さんとは、『Programming Ruby 3.3 (5th Edition)』の翻訳プロジェクト へのスポンサーについて話を伺えました。この翻訳プロジェクトは Ruby コミュニティとしてとても意義深いものだと思いますので、興味のある方は一読のうえ、ぜひ島田さんにコンタクトを取ってみると良いと思います。

Day 3 の個人的 Extra Track である The Tap で、藤浪さん (makenowjust) と初めてお話しできた。以前頂いていた RuboCop への問題のある正規表現を検出する cop の提案について、bad ケースを検知しても、good ケースへの直し方がユーザーはわからなさそうで、RuboCop で検知しても無効化されということになりそうで、実用的に難しそうという点を話したりしていた。藤浪さんとしてもそのあたりはドキュメント化か何かで伝えられると良いのだろうかと、課題について共有できました。

ご挨拶や質問し損ねた点

挨拶し損ねたのは、まず Matz への還暦へのおめでとうございますを伝えられなかったこと。勤務先で配布していた『Ruby on Timeline』には「Matz の誕生」というカードがあり、その許諾確認を junk0612 から行ってもらったのですが、二つ返事でご快諾いただいたと聞いています。そのお礼や諸々の感謝を伝え損ねたなあと。また sylph01 さんは RubyConf Taiwan が一番話すタイミングという不思議な仲ですが、今回の地元開催にあたっての本気度への感謝を伝え損ねたなあ。

kenchan が mcp-rb にパッチを送っていたのを見ていたので、その背景にある LLM の話をしてみたいなあと思っていたのに、すっかり忘れいていたのだった。kenchan とは RubyKaigi 以外でも会おうと思えば会えると思うので、機会があればどこかで話したいところ。

勤務先の永和システムマネジメントとしての活動や、もろもろ

勤務先のノベルティとして配布していた『Ruby on Timeline』のパッケージ裏にあるバージョン v69.83.77 には実は意味があります。mame さんはこのバージョンについてノーヒントで10秒かからず解かれました。mame Ruby はやはり世界屈指の処理系を備えた頭脳で、慄くしかなかったです。ほんとうにすごい。興味のある方は v69.83.77 というバージョンという仕掛けについて、考えてみてください。

永和謹製『Ruby on Timeline 』ゲーム入手は、 #rubykaigi 会期中 @junk0612 @color_box @fugakkbn @haruguchiyuma @kasumi8pon @m_pixy @maimu @nsgc @wai_doi S.H. や私にお声がけください。還暦をお迎えされた @yukihiro_matz さんの誕生もタイムラインに入っています！ (おめでとうございます！) pic.twitter.com/3KnEgPbi9O

— Koichi ITO (@koic) 2025å¹´4月14æ—¥

今回入手できなかった方は、別の機会に配布する予定がありますので、またそちらでお会いしましょう。

ESM Drinkup では、fukui.rb の taketo さん (通訳ありがとうございます！) が「RuboCop LTS を作ったよ」という pboling を紹介してくれて話を聞いていました。RuboCop にはランタイムバージョン (2.7 以上をサポート) と解析バージョン (2.0 以上をサポート) という2種類のバージョンの概念があり、Prism が Ruby 3.3 以上が解析バージョンということもあり古い解析バージョンをいつかドロップしようという声を聞くことがあります。今回のユースケースを聞いて、現状ではそんなメンテナンスが大変なわけではないので、古い解析バージョンのサポートは維持した方がいいよなあと改めて思いました。

余談ですが、Prism の translation layer は Parser gem の Builder などに依存していて、Ruby 3.2 以下をドロップしても現状の Parser gem 依存はそのままでは削除できません。これは時間の都合で説明を割愛していたと思うのですが、今回の私の登壇では以下の図で Prism translation layer が Parser gem に依存している関係を示していました。

で、逆説的に Ruby 2.0 までをサポートしようと思うと、Parser gem は Prism のことを知らない (依存していない) ため、RuboCop を Parser gem AST から Prism native AST に変えることはできません。つまり Ruby 2.0 までの解析サポートを維持するという方針であれば、改めて Parser gem AST を Prism native AST に置き換える意味とは？になるのでした。感想記事を書くと、いろいろと整理されてきますね。

kkd や hidenba といった XPJUG っぽい組み合わせでの会話もできて良かったです。

おわりに

Matz のキーノートが印象的で、今後のお仕事に向けたお話し的にも、生成 AI と Ruby というあたりは個人的にちょうど一番ホットなテーマでした。DD4D の帰りに何人かと話していたのですが、生成 AI 時代の Ruby の言語デザインがどうなっていくか、言語デザイナーのまつもとさんの動きを楽しみにしています。

また、ビアバー The Tap には滞在中4泊5日のうちの3日間を、遅い時間までありがとうございました。限られた時間の本編では話せなかった廊下テックトークやいろいろ多く話せる機会になりました。

来年の RubyKaigi 2026 も楽しみです。オーガナイザーのみなさん、スタッフのみなさん、ありがとうございました！

最後に付録として、モジュール性やインタフェースについては、このあたりの書籍を元にもう少し話を入れたかったという今回の参考書籍 (?) です。尺の都合でほとんど入っていないものの、源流を辿るとこの影響を受けているという参考までに。オブジェクト指向スクリプト言語 Ruby ですからね。

オブジェクト指向における再利用のためのデザインパターン

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

オブジェクト指向入門 第2版: 原則・コンセプト

『AIとコミュニケーションする技術』を読んã

『AIとコミュニケーションする技術 プロンプティング・スキルの基礎と実践 』を読んだ。

AIとコミュニケーションする技術　プロンプティング・スキルの基礎と実践

結論として、これは読んだ方が良い。特に生成 AI == ChatGPT という状況だったり、生成 AI によってプログラマーの仕事がどうなっていくかという期待と不安を持っている人なんかにおすすめ。おそらく今後のエンジニアの世界で AI 対応済み人材となるには、この書籍のコンテンツに書かれているような議論はできる必要があると思う。用語理解からできるのもおすすめの理由。Fine-turning, In-context learning, Embedding, RAG といった用語をパッと説明できない場合は、読む価値があると思う。

書籍を知ったのは、Akapon さんのツイートがきっかけ。

【メモ】『AIとコミュニケーションする技術』森重真純 著（インプレス） pic.twitter.com/rm5Tkstfsw

— Akapon (@Akapon2010) 2025å¹´4月5æ—¥

改めて、ひとことで感想をいうと読んで良かった。ある程度、ふだんから ChatGPT か何がしらの AI ツールと触れている方が、実感を伴って読めると思います。

章単位で感想を書いてみます。

chapter 1 は、本書を読んでみたいという動機として大きな章。本書と別に読んでいる『LLM 自作入門』での用語と目的にイマイチ慣れていない部分があったので用語整理をしたいと思っていたところ、この章に LLM 周辺の用語が書かれてるのが、本書を読んでみようと思った最初の動機だった。何か新しいことを覚えようとした時に、そのドメイン用語を知って覚えるのが重要だけれど、場当たり的に覚えていたところを俯瞰的に覚えられたので良かった。また知らなかった用語もあって、思った以上に自分には役立った。用語だけ見ても良くわからんが確実に減ったと思う。

chapter 2 は、「プロンプトデザイン」がテーマであるものの、読み方によっては AI へのプロンプティングというより、社会人としてのコミュニケーションの取り方みたいな話っぽくもあった。つまり AI への指示も丁寧にやれば、それだけ不明点ない結果としてレスポンスがあるという話。そういった意味で、AI 関係なくビジネススキルのおさらいとしても読めると思う。

chapter 3 は、プロンプティング手法の分類で、ふだんから使っている人にとっては、手法整理になるかもしれません。

chapter 4 は、ほとんど無自覚に行なっているプロンプティングについて、それぞれ一般的な命名がされていたりすることを知れた章だった。例文も示されて実践的な章だったと思う。

chapter 5 は、個人的に購入して一番良かったと思う章。chapter 4 までの話を読んでこれまでとこれからの AI を考える土壌を耕し直したところ、じゃあ仕事でどのように生かすといったことを考えていけるような話になっていた。また、界隈でも耳にする「エンジニアの今後のお仕事」についての考察についてもアップデートした考え方で望めるのでは？というストーリーでおすすめ。個人的には chapter 5 の 02 はいい話だったし、5-8 にあるように、Garbage In, Garbage Out を減らすデータクレイジングはエンジニアリングの世界として重要に思えた。

chapter 6 は、これまでの話を前提とした未来像への考えを見ることができる。著者の森重さんの考え方は、自分がもともと持っていた AI との共生への考え方と大きく違っていなかったというのも読みやすさにあったけれど、そういった方針レベルではなく、実際に AI ビジネスをしている現場視点での話として蘊蓄に富んでいた。

著者が現場の AI に精通しているのが伝わってきた一冊で、LLM を取り巻く社会についての理解が上がった気がします。繰り返しになるのですが、特に生成 AI == ChatGPT みたいな感じで捉えている人は、一読すると世界観をアップデートできると思うのでおすすめです。読みやすいので週末にサッと読めると思います。