2025年4月16日(水)から 18日(金)まで、愛媛県民文化会館にてRubyKaigi 2025が開催されました。最終日のキーノートはRubyの生みの親であるまつもとゆきひろさんが登壇し、「⁠⁠Programming Language for AI age（AI時代におけるプログラミング言語⁠）⁠」について話しました。

登壇の際に舞台のせり上がりからまつもとさんが登場し、会場は大いに盛り上がりました。そして、「⁠ 他のテックカンファレンスではAIについての話題で持ちきりですが、（⁠RubyKaigiでは）誰もAIについて話してないのでこのタイトルに決めました」と話し始めました。

AIに対する逆アルファシンドロームの警告

AIの進化が著しい現代においてもなお「人間が主であり、AIは従であるべきだ」とまつもとさんは言います。AIが賢くなってきたからといって、人間がそのしもべのようになってしまう現状に警鐘を鳴らします。

たとえば、犬は群れで生きる動物であり、甘やかすと自分をボスだと思ってさまざまな問題行動を起こすようになります。これを一般的に「アルファシンドローム」と呼びます。

今日のAIには得意なことと苦手なことがあります。得意なことはプログラミングです。「⁠こういうコードを書いてほしい」とお願いすると、概ね正しく動くコードを生成してくれます（よく間違えることもありますが⁠）⁠。一方で、苦手なことは交渉や仕様決めなどです。

最近はプログラマという仕事はAIに奪われてしまうのでは、と諦めている人もいるかもしれません。AIに得意な仕事だけをやらせてしまうと、私たち人間がAIのために働くことになってしまうのではないか、とまつもとさんは危惧しています。私たち人間が主人で、AIは人間の奉仕者であるべきです。何をAIに任せて、何を人間がやるのかをきちんと考えなければならない、と強調しました。

人間が楽しめるプログラミングの仕事はAIが得意だからとAIに任せ、つらい仕事を人間が担っている現状を、まつもとさんは「逆アルファシンドローム」と表現し、私たちはこの逆アルファシンドロームに気をつけなければいけないと警告しました。

AI時代のプログラミング言語

「AI時代に望まれるプログラミング言語はなにか？」という話題に移りました。「⁠AIを作るためのプログラミング言語は？と問われたときは、Pythonを使え！と話が終わってしまうので」と会場の笑いを誘いました。

まつもとさんは会場の参加者に対して、「⁠実際にAIを使ってコーディングしている人は手を挙げてもらっていいですか？」と聞きました。その結果、なんと参加者の7〜8割ほどの人の手が挙がっていました。まつもとさん自身もAIを使うそうですが、今はまだAIも賢くないので使い所が難しい、と述べました。たとえばmrubyを参考にmrubyを作ると、前のコードと同じコードが出てくるそうです。しかし、AIは日々賢くなっているため、モデルに存在しない新しいコードを作り出せる未来は遠くないかもしれません。AIが賢くなった未来に、どんな性質をもったプログラミング言語が使われるのでしょうか？

自然言語を使う？

多くの人は「自然言語」と答えるかもしれません。実際、コードを直接書くよりも、「⁠こんなプログラムがほしい」とAIに伝え、その結果を確認することが増えてきています。自然言語は、「⁠ほしいもの」や「達成したいこと」などのゴールやビジョンを説明するときに便利です。

しかし、プログラムの中身について話す場合には自然言語は冗長すぎると言及しました。たとえば古代ギリシャでは、数学についすべて自然言語で議論されていましたが、数式を使うようになってから、数学が発展しました。数式によって、より簡潔にわかりやすく、数学の概念を組み立てられるようになりました。同じように、自然言語よりも簡潔で明確、理論的という特質を持ったなんらかの人工的な言語があると、もっとプログラミングがよくできる。それはおそらく何らかのプログラミング言語である、とまつもとさんは予想します。

未来における静的な型

AIが出力したコードを読んで人間が修正したり、人間が書いたコードをAIが手直ししたりなど、AIと人間が相互にやり取りする場合、一般的には静的型付け言語が使いやすいと言われています。AIがおかしなプログラムを書いた場合、コンパイルエラーが出るので間違いにすぐ気づくことができるためです。ただ、未来のことを考えた場合、本当に静的型付けは必要だろうか、とまつもとさんは問いました。人間はうっかり型を間違えることがありますが、賢い人間は型エラーを起こさないので、十分に賢いAIは静的型付けなどなくても型エラーを起こさない、と言います。

静的な型は楽しい

一方で、静的な型が好きな人もたくさんいます。型があることでエラーを早く見つけられたり、型情報がドキュメントになったりするなど、型から得られる恩恵も多いからです。現代において、流行りの言語が静的型付けであることも理由の一つかもしれません。しかし、まつもとさんが考える一番の理由は「静的型付け言語は楽しいから」です。

現代の複雑な問題に対応するため、型の形は複雑化してきました。その結果、静的型付けは難しくなり、難しくなるとパズルみたいで楽しい、ということです。

私たちは楽しいからRubyをやっています（もちろん上司から言われたからという人もいると思いますが⁠）⁠。Rubyを作ったまつもとさんも、Rubyが楽しいから作ったと言います。また、他の人が他の言語を楽しいと思うことは良いことだと思うけど、Rubyistは型の楽しさが分からないからダメだ、と言われる筋合いはないと語ります。りんごとみかんを比較しているようなもので、「⁠りんごは美味しいぞ、だからお前もりんごを食べろ」と、みかん派に言っても知らないというわけです。

AI時代のプログラミング言語が持つべき3つの特性

まつもとさんは、AIが十分に賢くなった未来において、プログラミング言語が持つべき特質について、次の3つを挙げました。

1. 簡潔さ

より短く、最小限に書けることにより、効率的にAIとコミュニケーションが取れるようになります。トークンの数が少ないほうが、トークンウィンドウに長く情報が残り、AIはより多くの情報を引き出せます。また、型や宣言などを最小限にして、アルゴリズムの本質的な部分に集中できます。人間がコードを見たときに、「⁠これは何をしているコードか」が分かりやすいと良いです。AIの補助があるときに、簡潔さはより重要視されるのではないかと提案しました。

2. 表現力

簡潔に書くことに加えて、現実世界の問題を解決するアプリケーションを実装する能力が必要です。Hello Worldやフィボナッチ数列を計算するプログラムを書けたとしても、それでは仕事になりません。仕事としてプログラム言語を使う場合、現実世界の問題も解決できる言語である必要があります。現実世界の問題を記述し切れる能力を持っていること、かつ本当に記述できるという実例によって証明されている記述性が求められます。

3. 拡張性

たとえばWebアプリケーションを作る人たちと、ゲームを作る人たちと、組み込みアプリケーションを作る人たちとでは、それぞれ必要とされる語彙が違います。必要な語彙を埋めるために、拡張性が必要です。それには言語として拡張できる機能が必要ですし、実際に語彙を提供してくれるライブラリがあるほうが望ましいです。表現するためにDSL（Domain Specific Language）を言語の上に記述できることが望ましいでしょう。

まつもとさんはそんな特徴を持っている言語を私たちに教えてくれました。Rubyという言語です。未来のことは不確実で変わる可能性があるけど、Rubyが覇権をとる未来は十分あり得る、と続けました。

AI時代に向けた3つの提案

この未来を実現するために、私たちにできることについて3つ提案しました。

1. データを増やすこと

AIはすべてのプログラミング言語を平等に理解できるわけではなく、取り込んだデータが多いほうが強力になります。より良い出力を得るためには、より多くの新しいコードをAIに教える必要があります。たとえば、RubyのコードをAIで出力すると、古いイディオムのコードを生成することがあるそうです。Rubyコードの出力を改善するためには、モダンなコードをAIに教える必要があります。

ある会社はOpenAIと交渉して、自分たちで作ったモダンで質の高いRubyのコードをAIに入れようとしているそうです。その交渉が実現した場合、AIの生成するRubyのコードのクオリティが上がる可能性があります。また、私たちが自信のあるコードをGitHubなどでオープンソースとして公開すると、よりクオリティの高いRubyコードをAIが出力するようになる可能性があります。

2. 便利なツールを作ること

現在はまだAIのコードを信用しきれないので、様々なツールが必要です。

ツールは人間のコーディングを支援して、生産性をあげてくれます（RubyのライブラリではRuboCop、Steep、TypeProf、Sorbet、Debugger、irb、Parsers（Prism & Lrama⁠）⁠、Ruby-lspなど⁠）⁠。RubyKaigiを見ても分かるとおり、次々と新しいツールが生まれ、改善され、人間のコーディングを支えてくれています。まつもとさんは今後AIを使ったツールが出てくる可能性を示唆しました。

3. パフォーマンスを上げること

「みんなパフォーマンス大好きなのに、なぜかRubyを使うんですよね」とまつもとさんは笑います。みんな速いプログラムが好きなのです。

まつもとさん曰く「私は速いプログラムを作る才能がない」ため、初期のRubyは遅い言語だったと言います。ここで、Rubyのパフォーマンスの変遷から、Rubyコミュニティ全体で速度改善を図るために努力してきたことを紹介しました。なお、Rubyは速度改善が難しい仕様になっているそうで、誰のせいかというと、まつもとさん自身のせいとのことです。

v1.8のころはRubyはPHPやPythonより遅いと言われていました。しかし、笹田さんがVM YARVを入れ、ブラッドさんが提案したMJITを国分さんがマージしたことで、Rubyの速度はかなり改善しました。その後、MaximeさんとShopifyの人たちによってYJITが導入され、Railsでも10〜20%速くなりました。このように、RubyはRubyコミュニティ全体で速度改善を図るために努力してきました。

今よりもRubyを速くするために、これからも様々な努力を続けていく必要があります（なぜならみんな速いのが好きだから！⁠）⁠。今回の松山のRubyKaigiでも、様々なRubyを速くする方策についての話がありました。

• JIT：ZJITが入ります（アップストリームにします）
• 国分さんのDeoptimizationの話：脱最適化の話
• アーロンさんのClass.newについて：改善して速くする話
• RactorやConcurrencyの話

短期的に考えるとRubyは他の言語に負けている、とまつもとさんは言います。AIが読み込んだコードの量で言えば、JavaScriptやPythonのほうが圧倒的に多いと想像しているそうです。しかし、長期的に上に挙げたRubyの良い特質が活きれば、Rubyがメジャーな言語として生き残る世界もあり得るのではないかとも考えています。そのために私たちができることはたくさんあると語りました。なんとも希望のある話です。

コミュニティの力と今後に向けて

具体的に私たちにできることはなんでしょうか。まつもとさんは、コミュニティの力を強調しました。

オープンソース開発者はなかなか報われません。ありがとうと言われるのは良いけど、どれだけ頑張ってもなかなか経済的支援にたどり着けず、他の言語ではコミュニティを去っていく人もいるそうです。

よって、開発者を一人にせず、一緒に何かをやっていくことが大事であると、まつもとさんは言います。参加者の中には、Rubyコミッターのオレンジ色のTシャツ（2025年はコミッターのTシャツの色がオレンジでした）の方々とすごい距離を感じた人もいるかもしれませんが、実はそんなに距離はないそうです。

コミッターの中にも、かなり若い人や、プログラミングを学んだ経験が短い人など、様々な人がいます。自分のやりたいことが見つかればコミッター側になれるし、Rubyのコアの部分でなくても、何かのgemやフレームワーク、何かの仕組み、ドキュメントなど、できることはたくさんあると指摘します。

私たちはコミュニティであり、コミュニティがRubyの力の源であるとし、「⁠Rubyにできることはまだまだたくさんあるので、ぜひ一緒にやりましょう」と、まつもとさんは参加者に呼びかけました。

Ruby 4.0に向けて

1995年12月21日にv.0.95で初公開されたRubyは、今年で30周年になります。2013年にRuby2.0、2020年にRuby3.0がリリースされ、少しずつバージョンを上げてきました。そして今年、Rubyの30周年を記念して、Ruby 4.0へのメジャーバージョンアップすることを発表しました。

2025年4月1日にも、まつもとさんのXにてRuby 4.0のリリースが示唆されていました。自身も4.0を出すのか悩んでいたようで、エイプリルフールにアップデートをちらつかせることで、アップデートしなくても許される状態にしたそうです。ちょっとずるいですよね！と笑うまつもとさんでした。

今回のバージョンアップは、今までのような大きな機能追加や仕様変更があるわけではありません。Linuxのように気分を一新する意味合いが強いアップデートです。

Ruby 4.0での機能追加としては、「⁠実験的なNamespace」と「実験的なZJIT」の2つを発表しました。

1. 実験的なNamespace

新たにNamespaceというclassが追加されます。この変更によって、次のことが可能になります。

名前の衝突を回避する

複数のライブラリやgemを同時に使う場合、クラス名やメソッド名が被る問題が起きがちです。Namespaceを使うことで、名前空間を分離し、偶然の衝突を防止できます。

Refinementとの連携

Refinementと組み合わせることで、特定のNamespace内でクラスの振る舞いを変えることが可能になります。これを応用し、gemのメソッドを特定のNamespaceに閉じ込めて管理するといったことも可能になる見通しです。たとえば、RSpecのitやdescribeメソッドをNamespace内に閉じ込めて、外部への影響を抑えるような利用法も想定されています。ただし、メソッドの名前を特定のgem内に閉じ込める使い方は、gem側の対応が必要になるため、Ruby 4.0になってすぐに使えるようになるわけではありません。

2. 実験的なZJIT

現行のYJITはトレーシングJITですが、ZJITはMethod JITになります。また、SSA IR（単一代入中間表現）を採用するため、JITコンパイルの結果をファイルに書き込んで残しておくことが可能になります。アプリケーションを起動する度に毎回コンパイルする必要がなくなり、JITタイムが劇的に改善されるということです。まつもとさんもかなり期待しているそうです。ZJITもRuby 4.0が出た際にすぐ使えるわけではありませんが、未来の大きな可能性を広げてくれる可能性があります。

マージの調整

Ruby4.0で追加される機能の作者たち（Namespaceの田籠さん、ZJITのShopifyのRubyインフラチーム）と話して、比較的近い時期にupstreamにマージしたいとのことでした。

なお、Ruby 4.0のことは誰にも相談しないで今回のキーノートで取り上げたため、リリースされなかったときはエイプリルフールだったと思ってもらえれば、と笑っていました。

終わりに

まつもとさんはトークの終わりに、スポンサー企業やRubyコミュニティへの感謝を述べ、「⁠未来を感じさせる希望に満ちたキーノートをお送りしました」という言葉で締めくくりました。