RubyLLM 2.0.0.rc2 レビュー: 17プロバイダーを1つのRuby APIに束ねる

RubyLLMが埋めるのはプロバイダー差分の吸収という地味な作業

AI機能をRubyで作るとき、最初に発生するのはモデルを呼ぶコードではなく、プロバイダーごとの差異を吸収するコードである。OpenAI、Anthropic、Google、xAI、Mistral、DeepSeek、Perplexity、OpenRouter、Ollama、Vertex AI、AWS など、APIの形も認証もストリーミングの返し方も違う。READMEによればRubyLLMは17のプロバイダーを組み込みで対応し、OpenAI互換のエンドポイントも直接接続できる。利用側は RubyLLM.chat や RubyLLM.embed といった同じメソッドを呼ぶだけで、プロバイダーの違いは設定に押し込まれる。対象読者は、Railsアプリにチャットや検索、文書処理を組み込みたいRubyエンジニアである。Python側のライブラリを別プロセスで動かす構成を避けたい場合に意味が出る。

会話・ツール・メディアを1つのチャットオブジェクトに集約する仕組み

中心にあるのは chat オブジェクトだ。READMEの例では RubyLLM.chat で会話を開始し、ask に文字列を渡す。ファイルを渡すときは with: オプションを使い、画像、動画、音声、PDF、ソースコードを同じ形で添付できる。ストリーミングは ask にブロックを渡し、chunk.content を逐次受け取る。ツールは RubyLLM::Tool を継承したクラスに description と execute を定義し、chat.with_tools(Weather) のように登録する。エージェントは RubyLLM::Agent を継承して model、instructions、tools を宣言するだけで、呼び出し側は new.ask を実行する。構造化出力は Schematist::Schema を継承したスキーマを with_schema で渡し、response.parsed でRubyオブジェクトとして読む。埋め込み、リランキング、文字起こし、音声合成、OCR、モデレーション、画像生成、動画生成はそれぞれ RubyLLM.embed、RubyLLM.rerank、RubyLLM.transcribe、RubyLLM.speak、RubyLLM.ocr、RubyLLM.moderate、RubyLLM.paint、RubyLLM.animate というトップレベルメソッドに分かれている。データの流れは常に「Rubyオブジェクトを渡す、Rubyオブジェクトで受け取る」で統一されている。

導入はgem追加とプロバイダー設定から始まる

READMEは2.0.0.rc2のコード例を示しており、インストールとプロバイダー設定はGetting Started（https://rubyllm.com/next/getting-started/）に従うよう案内している。リリース情報では v2.0.0.rc2 が2026-09-09、v2.0.0.rc1 が2026-09-08、安定版の 1.16.0 が2026-06-09に公開されている。つまり現時点で最新はリリース候補であり、本番で使うなら1.16.0とのAPI差分を確認する必要がある。READMEから読み取れる設定の入口は、APIキーなどのプロバイダー情報をRubyLLMに渡す部分と、chat 生成時の model: 指定である。Railsでは独自の Chat と Message レコードに対して同じAPIが動き、Active Storageの添付、Hotwireのストリーミング、バックグラウンドジョブと組み合わせられる。ジェネレータも用意されているとREADMEは述べている。プロバイダーを増やすときは、対応済みの17の中から選ぶか、OpenAI互換エンドポイントとして接続するかの二択になる。

トークンとコストの台帳、承認待ち、フォールバックという運用向けの部品

実運用で効いてくるのは、派手な生成機能より地味な制御部品である。READMEによれば、chat.tokens と chat.cost の背後には試行ごとの使用量台帳がある。with_fallbacks でバックアップモデルへの再試行を指定でき、cancel で実行を止められる。ツールには requires_approval があり、人間が承認するまで実行を保留できる。エージェントループは ask_later、step、complete? を使って自分で駆動することも、フレームワークに任せることもできる。プロンプトキャッシュは with_caching と cache_until_here で有効化する。プロンプトテンプレートは app/prompts 配下のERBを RubyLLM.render_prompt で描画する。複数エージェントの実行は RubyLLM.workflow でテレメトリ上に関連付けられる。これらは「AI機能を出す」段階ではなく「AI機能を止めずに運用する」段階で必要になるもので、フレームワークを選ぶ理由はむしろこちら側にある。

リリース候補を本番に置くリスクとRails前提の重心

最大の注意点はバージョンの位置づけである。最新の v2.0.0.rc2 はリリース候補であり、安定版は 1.16.0 である。READMEのコード例はすべて2.0.0.rc2を前提としており、1.16.0とはAPIが一致しない可能性がある。2.0系のAPIで書いたコードを1.16.0に戻す作業は、単純なバージョン番号の変更では済まないと考えるべきだ。もう一つの偏りはRailsへの最適化である。Active Recordの永続化、Active Storage、Hotwire、ジェネレータといった記述はRailsを強く前提している。素のRubyやSinatraで使う場合、これらの利点は受けられず、会話の保存や添付ファイルの管理は自分で書くことになる。READMEは「A handful of small dependencies」と述べるが、依存の具体名やバージョン制約はこの資料からは確認できない。プロバイダー側のモデル名もREADME中の例（gemini-3.7-flash、gpt-5.6-luna、rerank-v3.5）は執筆時点のもので、実際に利用可能かは各プロバイダーの状況次第である。

Pythonエコシステムと組むか、Rubyで完結させるか

比較対象として現実的なのは、Python側のLLMフレームワークを別サービスとして立て、RubyからHTTPで呼ぶ構成である。この場合、モデル呼び出しはできるが、ツール定義、スキーマ、コスト台帳、承認フローはPython側の語彙で書くことになり、Railsのモデルやジョブと密に連携させるには境界を越える変換コードが要る。RubyLLMの違いは、チャット、ツール、エージェント、埋め込み、リランキング、OCR、モデレーションまでをRubyのオブジェクトとして扱い、Railsのレコードと同じプロセスで動かせる点にある。逆に、Python固有の学習済みモデルや研究用途のパイプラインが既にあるなら、それをRubyLLMで置き換える利点はない。判断基準は「AIの処理をどこで書きたいか」であって、機能一覧の多さではない。

メンテナンスコストとMITライセンスの意味

ライセンスはMITである。商用利用、改変、再配布が許される寛容なライセンスで、ソースコードの開示義務は課されない。ただしこれは法的助言ではなく、実際の適用は自組織の法務やコンプライアンス担当が確認すべき領域である。メンテナンス面では、17プロバイダー分の差分を追い続けるコストをフレームワーク側が負担する代わりに、利用側はフレームワークのリリースサイクルに追従することになる。2.0.0.rc2 と 1.16.0 が併存している現状は、その追従コストが具体的に現れた例だ。プロバイダーのAPI仕様変更、モデル名の追加・廃止、非推奨化のたびにgemの更新が必要になる。逆に自前でプロバイダー差分を書けば、変更のタイミングは自分で決められるが、その差分を自分で保守することになる。どちらが安いかは、対応するプロバイダーの数と、追従にかけられる人数で決まる。

編集部の結論

既存のRailsアプリにAI機能を足したいチーム、複数プロバイダーを同じコードで切り替えたいチームには候補になる。逆に、Pythonの機械学習スタックやLangChain固有の機能に依存している場合、RubyLLMに合わせて設計を曲げる理由は薄い。導入前に確認すべきは、2.0.0.rc2がリリース候補であり安定版の1.16.0とはAPIが異なる点、使いたいプロバイダーが17の中に含まれるか、そしてRails以外の構成でどこまで面倒を見てくれるかである。

公式情報源

1. crmne/ruby_llm on GitHub
2. License: MIT
3. Project website
4. README
5. Releases