langchain-rust 採用判断: RustでLLMパイプラインを組む前に確認する4つの境界

RustサービスにLLM呼び出しを持ち込むときの接着剤

Pythonで書かれたLangChainの構成要素を、Rustのバイナリやサービスの中から呼びたい。これがlangchain-rustの出発点である。Pythonランタイムを別プロセスとして立て、HTTPやFFIでつなぐ方法もあるが、型の境界が増え、エラー処理も二重になる。langchain-rustはLLM、埋め込み、ベクターストア、チェーン、エージェント、ツール、DocumentLoaderを1つのクレートにまとめ、Rustの型のまま扱えるようにする。READMEは「the Rust language implementation of LangChain」と位置づけており、独自の抽象を発明したわけではない。対象読者は、すでにRustで書かれたバックエンドやCLIを持ち、そこにRAGやエージェント的な処理を足したい開発者である。新規にLLMアプリを作る場合でも、実行環境を単一バイナリに閉じ込めたいなら候補になる。

LLMからDocumentLoaderまでを同じ型でつなぐ層構造

READMEの機能一覧を縦に読むと、このクレートの構造が見える。最下層にLLMプロバイダがあり、OpenAI、Azure OpenAI、Ollama、Anthropic Claudeが対応する。次に埋め込みがあり、OpenAI、Azure OpenAI、Ollama、MistralAI、そしてローカル実行のFastEmbedが並ぶ。その上にベクターストアがあり、OpenSearch、Postgres、Qdrant、Sqlite、SurrealDBが対応する。ここまでが検索の材料を作る層である。その上にチェーンが乗る。LLM Chain、Conversational Chain、Conversational Retriever Simple、Conversational Retriever With Vector Store、Sequential Chain、Q&A Chain、SQL Chainの7種が列挙されている。さらに上にエージェントがあり、Chat Agent with ToolsとOpen AI Compatible Tools Agentの2種がある。横方向の入力としてDocumentLoaderがあり、PDF、Pandoc、HTML、HTML To Markdown、CSV、Git commitsを扱う。この積み方自体はPython版と同じ発想で、Rust側では各層が非同期のtraitとして実装されていると読める。注目したいのはDocumentLoaderの戻り値で、READMEのコード例はいずれもload().awaitの結果をStreamExtでmapし、collect::<Vec<_>>().awaitしている。つまり文書は一度にVecで返るのではなく、ストリームとして流れてくる。大量のPDFやGitログを扱うとき、この設計はメモリ効率で有利になる一方、呼び出し側がfutures_util::StreamExtを依存に加え、ストリームを消費しきるコードを書く必要がある。

Cargo.tomlに1行足してプロバイダを選ぶ

導入はcrates.ioからの依存追加が起点になる。READMEのバッジはcrates.ioのlangchain-rustを指しており、Cargo.tomlのdependenciesにlangchain-rustを加える形になる。バージョンはv4.6.0が最新リリースとして記録されている。プロバイダごとの設定は各exampleファイルに集約されており、llm_openai.rs、llm_azure_open_ai.rs、llm_ollama.rs、llm_anthropic_claude.rsを読めば、環境変数の名前やビルダーの呼び出し順を確認できる。ベクターストアも同様に、vector_store_opensearch.rs、vector_store_postgres.rs、vector_store_qdrant.rs、vector_store_sqlite_vss.rs、そしてSurrealDBだけはexamples/vector_store_surrealdb/src/main.rsという独立したクレート構成のサンプルになっている。DocumentLoaderの使い方はREADMEにコードが載っている。例えばCSVならCsvLoader::from_path(path, columns)に列名のVecを渡し、load().awaitでストリームを得る。HTML To MarkdownではHtmlToMarkdownOptions::default().with_skip_tags(vec!["figure".to_string()])のように、除外タグを設定キーとして渡す。PDFはPdfExtractLoaderとLoPdfLoaderの2実装が用意され、コード例では前者が使われ、後者はコメントアウトされている。どちらを選ぶかの判断材料はREADMEには書かれていない。

ストリームAPIとドキュメントの薄さが最初の壁になる

最初につまずきやすいのは、DocumentLoaderの戻り値の扱いである。READMEの例はすべてmap(|d| d.unwrap())で個々の要素を剥がし、collectでVecに畳んでいる。ここから読み取れるのは、ロード処理が要素ごとにResultを返しうるという点だ。1つのPDFの途中で失敗しても、ストリーム全体が即座にエラーになるとは限らない。呼び出し側がどこで失敗を扱うかを決める必要がある。もう1つの壁はドキュメントの粒度である。READMEは機能のチェックリストと短いコード片が中心で、各チェーンの入出力の型や、プロバイダごとの設定キーの一覧はexampleファイルを読まないと分からない。チュートリアルへのリンクはあるが、リポジトリ内の説明は網羅的ではない。Rustの型エラーは親切だが、そもそも何を渡すべきかがREADMEから読み取れない箇所は残る。Python版LangChainの記事を読み替えて使おうとすると、この差分で詰まる。

Python版LangChainや自前実装とどう住み分けるか

比較対象として最も自然なのはPython版のLangChainである。違いは機能の有無ではなく、実行形態にある。Python版はプロバイダと統合先の数が圧倒的に多く、コミュニティの記事や周辺ツールも厚い。langchain-rustはその一部をRustに移植したもので、対応プロバイダはREADMEに列挙された範囲に限られる。したがって、使いたいベクターストアやLLMが一覧にない時点で、このクレートは選択肢から外れる。もう1つの比較対象は自前実装である。OpenAI互換のAPIを叩くだけなら、HTTPクライアントとserdeで十分に足りる。langchain-rustを入れる価値が出るのは、チェーンやエージェントのように複数の呼び出しを組み合わせ、その間でベクター検索を挟む処理を書くときだ。逆に、単発のチャット呼び出ししか行わないなら、依存を1つ増やす見返りは小さい。エージェントについても、READMEにあるのはChat Agent with ToolsとOpen AI Compatible Tools Agentの2種で、ツールはSerpapi/Google、DuckDuckGo Search、Wolfram/Math、Command line、Text2Speechが列挙されている。ツール呼び出しのループを自前で制御したい場合は、この抽象が邪魔になることもある。

MITライセンスと更新の読み方

ライセンスはMITで、リポジトリはアーカイブされていない。MITは商用利用を含めて比較的制約の少ない条件だが、依存クレートのライセンスは別途確認が必要で、ここで法的な助言はできない。更新状況については、記録されている最新リリースがv4.6.0（2024-10-06）で、その直前の同日にv4.5.0が出ており、v4.4.2は2024-09-10である。2024年9月から10月にかけて短い間隔でバージョンが上がった後、記録上はv4.6.0が最新のリリースとして残っている。リポジトリへの最終pushは2026-09-08と記録されているが、これはリリースとは別の指標であり、タグ付けされていない変更がmainに入っている可能性を含む。採用時は、crates.ioで公開されているバージョンとmainブランチの差分を確認し、必要な修正が未リリースで止まっていないかを見るのが現実的である。メジャーバージョンが4に達しているため、過去のv3系のコード例をそのまま使うとAPIの不一致に当たる。

導入前に潰しておく3つの確認事項

第一に、ベクターストアの選定である。READMEに列挙されているのはOpenSearch、Postgres、Qdrant、Sqlite、SurrealDBの5つで、Sqliteのexampleはvector_store_sqlite_vss.rsという名前からsqlite-vss拡張を前提にしていると推測できるが、セットアップ手順はREADMEには書かれていない。第二に、非同期ストリームの扱いである。DocumentLoaderを自前のパイプラインに組み込むなら、futures_util::StreamExtを依存に加え、要素ごとのResultをどこで処理するかを決めておく必要がある。第三に、プロバイダの設定である。llm_azure_open_ai.rsとllm_openai.rsは別ファイルに分かれており、環境変数の命名も異なる。デプロイ先がAzureかOpenAIかで設定の書き分けが発生する。これら3点は、いずれもexampleファイルとcrates.ioのバージョンを突き合わせれば短時間で確認できる。逆に言えば、この確認を省いてREADMEのチェックリストだけを見て採用を決めると、後からAPIの型や設定キーの差分で手戻りが起きる。

編集部の結論

採用を検討すべきなのは、すでにTokioベースのRustサービスを持ち、OpenAI・Azure OpenAI・Ollama・AnthropicのいずれかへLLM呼び出しを寄せたいチームである。逆に、Python版LangChainの全機能や活発なドキュメントを前提にしたい場合、あるいは日本語の利用事例を当てにしたい場合は向かない。導入前に確認すべきは3点ある。第一に、使う予定のベクターストアがOpenSearch・Postgres・Qdrant・Sqlite・SurrealDBのどれに該当するか。第二に、DocumentLoaderのload()が返すストリームを自前のコードでcollectできるか。第三に、crates.io上のlangchain-rustがv4.6.0以降どのように更新されているかである。

公式情報源

1. Abraxas-365/langchain-rust on GitHub
2. Issues
3. License: MIT
4. README
5. Releases