LangChain4j 採用判断: Java に LLM を組み込むときの統一 API とその境界

Java 側に LLM ライブラリが無かったという出発点

README は開発開始の動機をこう説明している。2023 年初頭、Python と JavaScript には LLM 向けライブラリが多数あったが、Java 側に対応するものが見当たらなかった。LangChain4j はその空白を埋めるために始まった。対象読者は Java アプリケーションに LLM を組み込もうとしている開発者であり、とくに既存のエンタープライズ Java 基盤の上で動かしたい人だ。README は Quarkus、Spring Boot、Helidon、Micronaut との統合を挙げている。新規に Python サービスを立てるのではなく、既存の JVM サービスの中に推論呼び出しを置きたい、という要求が想定されている。ここで注意したいのは、名前から Python 版 LangChain の Java ポートだと誤解されやすい点だ。README は明示的に否定している。API も内部実装もリリースサイクルも Python 版とは独立で、型安全性、POJO、アノテーション、インターフェース、依存性注入、流暢な API といった Java の慣習を前提に設計されている。

統一 API が解こうとしている問題の正体

LLM プロバイダも埋め込みストアも、それぞれ独自の API を持つ。OpenAI 用に書いたコードを Google Vertex AI に移すには書き直しが要る、というのが出発点の問題意識である。LangChain4j はこの上に統一 API を置き、プロバイダ間の切り替えをコードの書き換えなしで行えるようにする、と README は述べている。README によれば 20 以上の LLM プロバイダと 30 以上の埋め込みストアに対応する。ただし対応数は README の主張であり、個々のプロバイダでどの機能まで使えるかは統合ごとに差があると考えたほうがよい。統一 API は共通部分集合を定義するものだから、プロバイダ固有の新機能は抽象の外側に落ちる。この点は採用時の実務的な判断材料になる。

低レベルの道具と高レベルのパターンを同じ棚に置く

README は提供物をツールボックスと表現し、プロンプトテンプレート、チャットメモリ管理、関数呼び出しといった低レベルの部品から、エージェントや RAG のような高レベルのパターンまでを含むとしている。抽象ごとにインターフェースを用意し、代表的な実装を複数添える方針も書かれている。RAG についてはデータ取り込みから検索までの一連のパイプラインを対象にすると明記されている。つまり利用者は、検索部分だけ自前で書いて生成部分はライブラリに任せる、といった部分的な採用ができる。ツール呼び出しは MCP 対応にも触れられている。ここは設計思想がはっきり出ている箇所で、全部入りを強制するのではなく、必要な層だけ使う前提の構成だ。

依存の追加と最初の呼び出しまでの手順

Maven Central の座標は README のバッジから dev.langchain4j:langchain4j であることが読み取れる。ビルドファイルにこの groupId と artifactId を追加するのが最初の一歩になる。導入手順の本文は docs.langchain4j.dev/get-started に置かれているため、実際の依存記述やプロバイダ別モジュールの指定はそちらを参照する必要がある。動作するコード例は langchain4j-examples リポジトリにまとまっており、素の Java の例、Quarkus の例、Spring Boot の例、Helidon の例、Micronaut の例がそれぞれ別の場所に分かれている。Quarkus の場合は quarkus-langchain4j、Helidon の場合は io.helidon.integrations.langchain4j、Micronaut の場合は micronaut-langchain4j という別個の依存を使う構成だと README は示している。フレームワーク統合が本体とは別リポジトリで管理されている点は、バージョンの追随を考えるうえで把握しておきたい。

1.19.1 という誤公開リリースが示すもの

リリース一覧には 1.20.0、1.19.2、1.19.1 が並ぶ。日付だけを見ると 1.20.0 が 9 月 4 日、1.19.1 と 1.19.2 が 9 月 7 日で、番号の順序と日付の順序が一致していない。さらに 1.19.1 には「published in error, do not use」という注記が付いている。リリースノートはこの誤公開を明示しており、1.19.1 を依存に固定してはいけない。1.19.2 と 1.20.0 にはそれぞれ beta 版が併記されており、安定版とベータ版が同じタイミングで出る運用だ。ライブラリは活発に開発中で、一部機能は作業中だと README も認めている。バージョン範囲を緩く指定して自動で上がるようにすると、意図しない版を拾う余地が残る。

統一 API が向かない場面

抽象化には必ず代償がある。プロバイダが新しい推論パラメータや固有のツール形式を出したとき、統一 API に取り込まれるまで待つか、抽象を迂回して直接クライアントを呼ぶかになる。前者は機能差し替えの即応性を失い、後者はプロバイダ切り替えの利点を捨てる。プロバイダ固有機能を売りにした設計をするなら、この抽象は足かせになる。もう一つ、Python 版 LangChain のコードやプロンプト資産をそのまま持ってくる用途にも向かない。README が繰り返し述べるとおり API は独立して設計されており、移植を前提としていない。ドキュメントの厚さも統合ごとに差がある。20 以上のプロバイダのうち、手厚い例が用意されているのは一部だと考えておいたほうがよい。

代替としての Spring AI という選択肢

JVM で LLM を扱う場合、Spring AI が比較対象になる。違いは統合の重心にある。LangChain4j はフレームワーク非依存のコアライブラリを持ち、Quarkus、Spring Boot、Helidon、Micronaut への統合はそれぞれ別の依存として外側に置く構成だと README から読み取れる。Spring AI は Spring のプログラミングモデルを前提に据える。したがって、すでに Spring Boot に全面的に寄せているなら Spring AI のほうが設定と DI の流れに素直に乗る。逆に、Quarkus や Micronaut を使っている、あるいはフレームワークを跨いで同じ抽象を使い回したいなら LangChain4j の分離構造が効く。どちらが優れているという話ではなく、既存スタックとの距離で決まる。

Apache-2.0 とメンテナンスコストの見積もり

ライセンスは Apache-2.0 で、リポジトリはアーカイブされていない。Apache-2.0 は商用利用や改変、再配布を許容し、特許条項を含む一般的な許容型ライセンスである。ただし本記事は法的助言ではない。自組織のポリシーに照らした確認は別途必要になる。メンテナンス面では、本体と各フレームワーク統合が別々に動いているため、追随すべきバージョンが複数ある。プロバイダ側の API 変更にどこまで追随するかは、統一 API の対応状況に依存する。アップグレードのたびに確認すべきは、利用中のプロバイダ統合とフレームワーク統合がどの本体バージョンを要求しているかである。1.19.1 のような誤公開が起きている以上、依存は範囲指定ではなく固定し、上げる際はリリースノートを読んでからにする。

編集部の結論

すでに Java でサービスを運用しており、LLM プロバイダやベクトルストアを後から差し替える可能性があるチームに向く。逆に、プロバイダ固有の最新 API を初日から使いたい場合や、Python 版 LangChain の資産をそのまま持ち込みたい場合には向かない。採用前に確認すべきは、自分のユースケースが docs.langchain4j.dev の integrations 一覧に載っているか、そして 1.19.1 のような誤公開リリースを踏まないよう依存バージョンを固定できるか、の 2 点である。

公式情報源

1. langchain4j/langchain4j on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases