brainlid/langchain: ElixirからLLMを呼ぶための抽象化レイヤーをどう読むか

ElixirアプリにLLMを足すときの、実際の障壁

ElixirでLLMを呼ぶこと自体は難しくない。HTTPクライアントでJSONを投げ、レスポンスをパースすれば動く。問題はその先で、会話の文脈を保つ仕組み、ツール呼び出しの往復、プロバイダごとに違うリクエスト形式、ストリーミングの扱いが、機能を足すたびにアプリのあちこちに散らばっていく。brainlid/langchainはこの散らばりを吸収するために置かれる層で、READMEは「ElixirアプリケーションがAIサービスとセルフホストモデルを統合できるようにする」と説明している。想定読者は、Phoenixなどで既にElixirのプロダクトを運用していて、Pythonのサービスを別途立てずにLLM機能を同じコードベースに載せたい開発者だ。READMEの価値提案は2つに整理されている。ひとつは言語モデルを扱うための抽象化とその実装群、もうひとつは特定の目的向けに部品を組み上げた既製のチェーン。前者は単体でも使えると明記されており、フレームワーク全体に乗るかどうかを選べる。

Python版を写していないという設計判断

名前は同じだが、中身は別物として作られている。READMEは「このElixir版はJavaScript版とPython版とのパリティを目指していない」と明言し、理由を2つ挙げる。JSとPythonはオブジェクト指向言語であり、Elixirは関数型なので、当てはまらない設計を押し込まない。もうひとつは歴史的な事情で、JS/Python版は会話型LLMが一般的になる前に始まったため、モデル側が履歴を保持しない時代の名残として会話履歴を自前で保存する仕組みに力を割いてきた。このライブラリはその作業を引き継がない。実務上これは、Python版で組んだチェーン定義やプロンプトのシリアライズ資産をそのまま持ってくる発想が使えないことを意味する。逆に、会話履歴の管理をフレームワーク側の流儀に合わせる必要がなく、自分のアプリが持つデータ構造のまま扱える余地が残る。READMEによれば、設計はJavaScript版が実際にどう動き、どうLLMとやり取りしていたかに強く影響を受けている。パリティは捨てたが、発想の出所はJS版にある。

対応チャットモデルの広さと、その内訳の読み方

READMEの対応表にはAnthropic Claude、AWS Bedrock Mantle、OpenAI ChatGPT、OpenAI Responses API、Cloudflare Workers AI、xAI Grok、Google Gemini、Google Vertex AI、DeepSeek、Ollama、Mistral、Perplexity、orq.ai、Bumblebee、ReqLLMが並ぶ。数だけ見ると網羅的に思えるが、内訳は3種類に分かれている。第一に独自の実装を持つもの（Anthropic、OpenAI、Gemini、xAIなど）。第二にOpenAI互換のゲートウェイとしてChatOpenAI経由で叩くもので、Cloudflare Workers AIとAWS Bedrock Mantleがこれに当たる。第三に別ライブラリへのアダプタで、BumblebeeはNx経由のセルフホストモデル、ReqLLMはreq_llmを介したマルチプロバイダ接続だ。この分類は導入時に効く。第二と第三は実装の実体が別の場所にあるため、不具合が出たときにどちらのリポジトリを見るべきかが変わる。またOllamaとBumblebeeが含まれる点は、外部APIに会話を送れない要件がある現場では選定理由になり得る。

インストールと、キー名が揃っていない設定まわり

要件はElixir 1.17以上。mix.exsの依存はREADMEでは次のように示されている。

def deps do [ {:langchain, "~> 0.9.0"} ] end

ここは注意点がある。リポジトリの最新リリースはv0.13.1で、READMEの記載はそれより古い。実際にどのバージョンが解決されるかはmix deps.getの結果で確認するのが確実だ。API呼び出しにはReqライブラリが使われると明記されている。設定はconfig/runtime.exsに置き、キーはプロバイダごとに異なる。OpenAIはopenai_keyとopenai_org_id、Anthropicは:anthropic_key、xAIは:xai_api_keyという具合で、アトムの付け方も統一されていない。秘密情報の解決方法は3通り用意されている。環境変数をSystem.fetch_env!で読む、{MyApp.Secrets, :openai_api_key, []}のようなタプルでモジュール関数に委譲する、fn -> System.fetch_env!("OPENAI_API_KEY") endのような無名関数を渡す。タプルや関数を使える設計は、実行時にシークレットストアから取り出す運用に向く。READMEはAPIキーをリポジトリにコミットしないよう求め、fly.ioではfly secrets set OPENAI_API_KEY=...の形式を例示している。

プロンプトキャッシュという、コスト側の設計論点

READMEの末尾近くにプロンプトキャッシュの節がある。ChatGPT、Claude、DeepSeekはいずれもプレフィックスベースのプロンプトキャッシュを提供しており、長いプロンプトではコストと性能の面で利点がある、という内容だ。ここで実装者にとって重要なのは、キャッシュがプロバイダ側の機能であって、ライブラリが計算するものではないという点である。つまり効くかどうかは、プロンプトの先頭部分が呼び出しをまたいで安定しているかで決まる。システムプロンプトの冒頭に日時やユーザー固有の情報を差し込む設計にしていると、プレフィックスが毎回変わり、キャッシュの対象から外れる。逆に、固定の指示を先頭に置き、可変部分を後ろに寄せる構成にすれば、プロバイダ側の仕組みに乗りやすい。ライブラリ側の抽象化はこの並び順を強制しないので、プロンプトの組み立て方を決めるのはアプリケーション側の責任になる。

向かないケースと、代わりに検討するもの

このライブラリが適さない場面ははっきりしている。第一に、Python版LangChainで組んだチェーンやシリアライズ済みオブジェクトを資産として持つチーム。READMEが互換を目指さないと明言している以上、それらは移行できない。第二に、複雑なエージェントのオーケストレーションをフレームワーク側の既製部品で賄いたい場合。READMEは既製チェーンに触れているが、具体的なチェーンの一覧やAPIは提示された資料からは確認できない。第三に、Elixir 1.17未満のプロジェクト。要件として明記されているため、依存として追加しても解決しない。代替としては、HTTPクライアントと自前のモジュールで直接APIを叩く方法がある。違いは抽象化の有無だ。直接叩けばプロバイダ固有の挙動を完全に制御できるが、プロバイダを増やすたびにリクエスト形式、ストリーミング、ツール呼び出しの差分を自分で吸収することになる。このライブラリはその差分をChatOpenAIやChatAnthropicといった実装に寄せる。乗り換えの判断軸は、対応プロバイダ数の多さではなく、自前で吸収したくない差分がどれだけあるかになる。

メンテナンス状況とライセンスの扱い

リポジトリはアーカイブされておらず、最終pushは2026年9月9日。v0.12.0が2026年8月22日、v0.13.0が8月23日、v0.13.1が8月26日と、短期間にリリースが続いている。活発に見えるが、この間隔は破壊的変更を含む版が続いた可能性も示す。0.x系である以上、マイナー番号の上がり方がそのまま互換性の保証にはならない。アップグレードコストを見積もるには、各リリースのノートを追う必要がある。ライセンスは提示された情報ではNOASSERTIONとしか判別できず、MITやApache-2.0といった具体的な識別子は確認できない。したがって、ライセンス条件についてここで断定はできない。商用配布や自社サービスへの組み込みを検討する場合は、リポジトリのLICENSEファイルを直接開き、条文を確認したうえで必要なら法務に回すことになる。この点は他の項目と違い、ドキュメントを読んでも解決しない。

編集部の結論

Elixir 1.17以降で動くアプリを持ち、OpenAIやAnthropicのAPIキーを既に管理しているチームには、導入コストの低い選択肢になる。逆に、Python版LangChainのチェーン定義やシリアライズ済みオブジェクトを資産として持っている場合、このライブラリは互換を目指していないため移行先にはならない。導入前に確認すべきは3点。mix.exsに書く依存がREADMEでは~> 0.9.0、最新リリースがv0.13.1とずれているので、実際に解決されるバージョンをmix deps.getで確かめること。config/runtime.exsに置くキーがopenai_key、openai_org_id、:anthropic_key、:xai_api_keyと種類ごとに揺れているので、使うプロバイダのキー名をドキュメントで照合すること。そしてライセンスがNOASSERTIONとしか判別できていないため、配布物や自社サービスに組み込む前にリポジトリのLICENSEファイルを直接開いて条件を読むこと。

公式情報源

1. brainlid/langchain on GitHub
2. Issues
3. Project website
4. README
5. Releases