rig を採用する前に読む、Rust における LLM 抽象化レイヤの実像
⚙️🦀 Build modular and scalable LLM Applications in Rust
ひと目でわかる
- これは何？
- rig は 20 以上のモデルプロバイダと 10 以上のベクトルストアを単一インターフェースにまとめる Rust ライブラリである。ただし README 自身が破壊的変更を予告しており、導入判断はその点をどう許容するかにかかっている。
- 誰に向いている？
- rig が向くのは、Rust を主要言語としてすでに使い、複数のモデルプロバイダやベクトルストアを切り替えながらエージェントを組み立てたいチームである。逆に、単一プロバイダで完結する小規模な用途や、API の安定を最優先するプロダクトには、README が明示する破壊的変更の予告がそのままコストになる。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
rig が埋めるのはプロバイダ差分ではなく、その差分を抱えたままコードを書き続ける負担
LLM を使うアプリケーションを書くとき、最初に発生する作業はモデルの呼び出しそのものではなく、プロバイダごとに異なるリクエスト形式、ストリーミングの扱い、埋め込みの戻り値の形を吸収する糊コードである。rig はこの糊コードをライブラリ側に寄せる。README は「20+ model providers, all under one singular unified interface」および「10+ vector store integrations, all under one singular unified interface」と述べており、対象は completion と embedding の両方、加えて transcription、audio generation、image generation の各モデル能力に及ぶ。想定読者は、Rust でサービスや CLI、デスクトップアプリを書いており、その中に LLM 呼び出しを埋め込みたい開発者である。Python 側の同等ライブラリから移植する際に、モデル切り替えのたびに呼び出し側を書き換える作業をなくしたい、という動機が最も素直に当てはまる。
rig-core と rig-agent の分離は、移植性とオーケストレーションを別レイヤとして扱う設計
リポジトリの説明によれば、rig は portable な provider/backend 契約と agent オーケストレーションを分離している。rig-core 側には provider-neutral なメッセージ、completion モデル、portable tools、memory と vector-store の契約、そして組み込みのプロバイダマッピングが入る。rig-agent 側には classic builder、prompt/streaming トレイト、typed hooks、contextual tools、extraction、そしてシリアライズ可能な AgentRun ステートマシンが入り、既定で有効になっている。ルートの rig ファサードは両方を従来のパスで再エクスポートするため、多くのコードは rig だけに依存すればよい。ここで実務上効いてくるのは、AgentRun がシリアライズ可能なステートマシンとして切られている点だ。エージェントの実行状態をプロセス外に退避できる形になっているということで、長時間走る処理や再開可能なワークフローを設計する余地がある。一方で、この分離は依存の総量を減らすものではない。rig-agent が既定で有効である以上、rig を入れる限りオーケストレーション層も一緒に付いてくる。
導入は cargo add から始まるが、プロバイダ側の設定はコード外にある
README の Get Started には Simple example の節があり、クレートは crates.io の rig として公開されている。API リファレンスは docs.rs/rig/latest/rig/、公式ドキュメントは rig.rs/docs にある。ビルドターゲットについては、portable core と classic runtime が wasm32-unknown-unknown をサポートすると README が明記しており、対象の全体像は crates/rig-agent/README.md の target support 節に置かれている。ここは注意点として読むべき箇所で、同じ記述の中で WASI は非サポート、rig-rmcp と MCP はネイティブ専用とされている。つまりブラウザ向けにビルドする構成を取るなら、MCP 経由のツール連携は最初から選択肢から外れる。可観測性については、GenAI Semantic Convention への完全準拠が Features に挙げられており、OpenTelemetry 側の計装と語彙を合わせる前提で設計されていることが読み取れる。
README が自ら破壊的変更を予告している点をどう扱うか
このプロジェクトで最も判断を迫られるのは機能の多さではなく、README 冒頭の警告である。引用すれば「Here be dragons!」に続けて、今後数か月で大量の機能を出す予定であり、将来の更新には破壊的変更が含まれると明言し、変更の注記と移行パスは都度示すとしている。リリース履歴を見ると v0.40.0、v0.41.0、v0.42.0 がそれぞれ約 1 か月間隔で並んでおり、0.x 系のまま高頻度で版が上がる運用が続いている。これは成熟度の欠如を意味しないが、依存を固定せずに追従する前提のライブラリであることは確かだ。実務的には、Cargo.toml でバージョンを固定し、更新は移行パスが提示されたタイミングでまとめて行う形になる。逆に言えば、破壊的変更を吸収する余力のない段階のプロダクトにとって、この予告はそのまま採用を見送る根拠になり得る。
向かないケースは、抽象化の層が不要なときと、MCP をブラウザで動かしたいとき
プロバイダを 1 つしか使わず、将来も切り替える見込みがないなら、rig が提供する統一インターフェースはほぼ価値を生まない。公式 SDK を直接呼ぶ方が依存は軽く、プロバイダ固有の新機能が出たときの追随も速い。もう一つ明確な境界がある。wasm32-unknown-unknown を対象にする場合、portable core と classic runtime はサポート対象だが、WASI は非サポート、rig-rmcp と MCP はネイティブ専用と README に書かれている。ブラウザ上で MCP サーバと接続する構成を想定しているなら、このライブラリではその経路が用意されていない。加えて、README の利用企業リストは非網羅的であると自ら断っており、掲載されている名前は導入判断の根拠にはならない。採用検討では、自分のユースケースが rig-core のプロバイダマッピングに存在するかどうかを docs.rs の API リファレンスで確認する作業の方が、事例を数えるより有効である。
LangChain との違いは、抽象化の厚みではなく実行時とターゲットの設計にある
同じ問題領域の代表として LangChain を挙げるなら、差は抽象化の有無ではない。LangChain は Python と JavaScript を主軸に、外部サービスやツールを組み合わせるための広い統合群と実行時を提供する。rig は Rust の型システムに乗せたクレート構成を取っており、rig-core と rig-agent という 2 層に分けた上で、rig-agent 側の AgentRun をシリアライズ可能なステートマシンとして定義している。この設計は、エージェントの状態を永続化して別プロセスで再開するような使い方を、フレームワークの外側で作り込まずに済ませる方向へ寄っている。もう一つの差はターゲットで、rig は wasm32-unknown-unknown を portable core と classic runtime の範囲で明示的にサポートする。ネイティブ前提のライブラリが多い中で、ブラウザ側にロジックを置く構成を最初から想定している点は、選定時に効く。
ライセンスと保守コスト、そして最初に確認すべき 3 点
ライセンスは MIT で、crates.io のライセンス表記もこれに揃っている。MIT は商用利用を含めて条件が緩い部類に入るが、これは法的助言ではないので、自組織のポリシーに照らした確認は別途必要になる。保守コストの面で材料から読み取れるのは、0.x 系のまま約 1 か月ごとに版が上がり、破壊的変更が予告されているという事実である。追従には継続的な作業時間がかかると見ておくべきで、これはライブラリの品質ではなくリリース方針の問題である。導入前に確認すべきは 3 点に絞られる。第一に、使いたいモデルプロバイダのマッピングが rig-core に存在するか。第二に、ビルド対象が wasm32-unknown-unknown かネイティブか。第三に、crates/rig-agent/README.md の target support 表で自分の構成が対象内に入っているか。この 3 点は README とリポジトリの記述だけで答えを出せる。
編集部の結論
rig が向くのは、Rust を主要言語としてすでに使い、複数のモデルプロバイダやベクトルストアを切り替えながらエージェントを組み立てたいチームである。逆に、単一プロバイダで完結する小規模な用途や、API の安定を最優先するプロダクトには、README が明示する破壊的変更の予告がそのままコストになる。導入前に確認すべきは、依存するプロバイダのマッピングが rig-core に存在するか、対象ターゲットが wasm32-unknown-unknown かネイティブか、そして crates/rig-agent/README.md の target support 表で自分のビルド構成が対象内に入っているかの 3 点である。
コミュニティノート