Pythonが当然の顔をしてきたAIアプリ開発に、Ruby側からはっきりとした回答が積み上がっている。RubyLLM——OpenAI、Anthropic、Google Gemini、xAI、AWS Bedrock、Ollamaなど14以上のプロバイダを単一のRuby APIに束ねるフレームワークだ。2026年6月9日にリリースされた1.16でさらに機能を厚くし、GitHubスター4.1k、RubyGemsの累計ダウンロードは300万を超えた。

「全プロバイダのAPIを、ひとつの美しいRubyで」。トップページの一文は短いが、これが意外と効く。各社が出すSDKは仕様も応答フォーマットも違って、乗り換えるたびに学び直しが要る。RubyLLMはそこを丸ごと吸収してしまう。

背景・文脈

ここ数年、AIアプリ開発の現場語はほぼPythonだった。LangChain、LlamaIndex、各社の公式SDK——技術スタックの中心がデータサイエンス側に寄っていた事情がある。だが2026年の景色は少し違ってきた。

作者のCarmine Paolinoは、自身のエッセイ「Ruby Is the Best Language for Building AI Apps」でこう書いている。LLMを”訓練”する人はほぼいない、数百万ドルかかるからだ、と。ほとんどの開発者がやっているのは、モデルの周辺を組み立てる仕事——応答のストリーミング、会話の永続化、コスト記録、課金、認証、ジョブ。つまり”Webアプリ作り”そのものだ。

そう捉え直すと、得意分野が逆転する。Railsはまさに「Webプロダクトを最短で作る」ためのフレームワークで、AIを乗せる土台としては筋がいい。RubyLLMはその思想を素直に体現したライブラリだと言っていい。

仕組み・特徴

依存はたった3つ、Faraday・Zeitwerk・Marcel。これが軽さの根っこになっている。各プロバイダの分厚いSDKを抱え込まず、HTTPクライアント1本で薄く包む設計だ。

使い方はほとんど不自然さがない。

chat = RubyLLM.chat
chat.ask "Rubyを学ぶ一番いい方法は？"

画像やPDFも同じwith:引数で渡す。

chat.ask "この画像に何が写っている？", with: "ruby_conf.jpg"
chat.ask "この契約書を要約して", with: "contract.pdf"

ストリーミングはブロック渡し、画像生成はRubyLLM.paint、ベクトル化はRubyLLM.embed。ひとつのメソッド名、ひとつの作法で、プロバイダを切り替えてもコードがほぼ動く。

ツール(関数呼び出し)もRubyらしい書き味で、RubyLLM::Toolを継承してメソッドを書くだけ。1.15からはメソッドのシグネチャからパラメータを自動推論するようになり、JSONスキーマの手書きから解放された。「コンピュータが推論できることは推論させる」——Paolinoの哲学はこの一行で言い切れる。

性能・ベンチマーク

純粋な推論性能はモデル側の話なので、ここで語るべきはエコシステム規模のほうだ。

公式のModel Registryには1166モデル(2026年6月8日時点、ローカルプロバイダを除く11社)が登録されている。能力(vision/audio/tool/embeddingなど)と料金が機械可読の形で揃っており、chat.with_model("claude-sonnet-4")のように切り替えても、コスト計算もトークン数も同じインタフェースで返ってくる。

これはPython側で苦労する点でもある。LangChainではGPTがresponse.response_metadata['token_usage']、Claudeがresponse.response_metadata['usage']、Geminiは何も返さない場合もある——という具合に、プロバイダごとに鍵が違う。RubyLLMはresponse.tokens.inputとresponse.tokens.outputで揃う。1.16直前の1.15ではコスト追跡そのものも内蔵され、response.cost.totalだけで計算済みの金額が出るようになった。

使いどころ・始め方

導入は文字通り一行。

bundle add ruby_llm

設定もシンプルで、使いたいプロバイダのAPIキーだけ初期化子に書けばいい。

RubyLLM.configure do |config|
  config.openai_api_key = ENV.fetch('OPENAI_API_KEY', nil)
end

Railsプロジェクトならbin/rails generate ruby_llm:installでActiveRecord連携用のマイグレーションが入り、acts_as_chatを書けばChatモデルが会話履歴ごと永続化される。さらにruby_llm:chat_uiジェネレータを叩くと、Turboストリーミング対応のチャットUIが/chatsに生える。これが体感、本当に数分で動く。

ライセンスはMIT。商用利用も二次配布も気兼ねが要らない。

日本・個人開発の視点

日本ではRails自体の存在感がやや薄れた時期があったが、AIプロダクトの個人開発・スモールチーム文脈でRailsが再評価される可能性は高いと僕は見ている。理由はシンプルで、AI機能”だけ”作ってもプロダクトにはならないからだ。認証・課金・ジョブキュー・管理画面まで含めて「金曜までに出す」と言える基盤として、Railsは依然として強い。

「AIで楽したな」と空気で刺す——広がる利己的LLM批判でも触れたように、AIツールの位置づけは「楽するためのオートメーション」より「作りたいものに最短で辿り着く道具」と捉えたほうが、結局よく走る。RubyLLMはまさにその系譜だ。

加えてRubyにはAsync/Fiberの仕組みが整っていて、async/awaitを全コードに散らさずに並行処理が書ける。LLMの待ち時間が支配的なAIアプリで、これは効く。

要点まとめ

• RubyLLM 1.16(2026年6月9日)が公開。14以上のAIプロバイダを単一のRuby APIで扱える
• 依存はFaraday・Zeitwerk・Marcelの3つだけ。トークン数・コスト・モデル能力までプロバイダ横断で揃う
• Railsとの噛み合わせが強烈で、ジェネレータ一発で永続化＋ストリーミングUIが立ち上がる
• 1.15からはツール定義のボイラープレートが減り、コスト追跡(response.cost.total)も内蔵
• ライセンスはMIT。個人開発・スモールチームのAIプロダクト基盤として有力な選択肢

🐦‍⬛ 編集部の視点

正直、これに触れていて思うのは——「Pythonじゃなきゃダメ」という空気は、もう半分くらい実態に合っていないのではということ。研究や訓練ならPython一択でも、世の中で作られているものの多くは「AIを乗せたWebアプリ」。だったらWebが得意な言語で書いたほうが早いに決まっている。

特に効くのはresponse.cost.totalだけでコストが取れるところ。複数モデルを使うアプリで「請求にビビる」場面が消える。地味だが、夜の精神衛生に効く機能だと思う。

もう一つ注目したいのが、Paolino氏の「コンピュータが推論できることは推論させる」という哲学。型注釈もスキーマも、書かずに済むなら書きたくない——AIアプリ開発の原則として、これは一番大事な部類に入ると考えている。

Rubyからしばらく目を離していた人ほど、いま一度触り直す価値がある。

出典・リンク

出典: https://rubyllm.com/
– RubyLLM公式
– crmne/ruby_llm (GitHub)
– Getting Started | RubyLLM
– RubyLLM 1.15: Image Editing, Cost Tracking and Less Tool Boilerplate — paolino.me
– Ruby Is the Best Language for Building AI Apps — paolino.me
– Rails + RubyLLM vs LangChain in 2026: The Honest CTO Comparison