今年の初め、私はメンテナンスしているSpring BootアプリケーションにAIアシスタントを追加する必要がありました。特別なものではなく、システムのドキュメントに関する質問に答えるチャットインターフェースという程度でした。選択肢は2つありました。Spring AIとLangChain4jです。
簡単な決断になると思っていました。どちらのフレームワークも成熟しており、主要なLLMプロバイダーをサポートし、Spring Boot統合も備えています。どれほど違うというのでしょうか？
6週間と2つのプロトタイプを経て、機能マトリックスが示す以上に違いが重要であることを学びました。
私はバングラデシュのダッカ出身のシニアソフトウェアエンジニアです。毎日Spring Bootで作業しており、個人的なAIインフラとしてHermes Agentも運用しています。エンタープライズJavaの世界とAIエージェントの世界の両方に足を踏み入れています。以下に、2つのフレームワークを比較して見つけた内容をお伝えします。
2つの候補
Spring AIは、Broadcom（旧VMware）のSpringチームによる公式AI統合フレームワークです。2026年にSpring Boot 4と同時にバージョン2.0.0に到達しました。チャット、エンベディング、画像生成、音声文字起こし、テキスト読み上げ、モデレーション、そして2.0の目玉機能であるMCP（Model Context Protocol）サポートなど、幅広い機能をカバーしています。start.spring.ioで他のSpringスターターと並んで見つけることができます。
LangChain4jは、Python中心のAI分野に対する回答として2023年初頭に開始されました。名前とは異なり、LangChainのJava移植版ではありません。メンテナーはこれを強調しています。これはJava用に構築されたもので、移植されたものではないということです。LangChain4jは20以上のLLMプロバイダーと30以上のベクトルストアをサポートし、Spring Boot、Quarkus、Helidon、Micronautと統合しています。
どちらのフレームワークもLLMの呼び出し、RAGパイプラインの構築、ツールの呼び出し、エージェントの作成が可能です。しかし、これらのタスクへのアプローチは根本的に異なります。
アーキテクチャの哲学
これが2つの最大の違いであり、他のすべての決定を左右します。
Spring AIはSpringエコシステムのために構築されています。すでにSpring Bootを使用している場合、Spring AIは他のSpringスターターと同様に組み込むことができます。オートコンフィギュレーション、プロパティ駆動のセットアップ、馴染みのある依存性注入モデル、Springの可観測性スタック（Micrometer、Actuator）との緊密な統合が得られます。APIはRestTemplateやWebClientをもたらした人々によって設計されたように感じられます。実際、その通りです。
Spring Boot 4プロジェクトにSpring AIを追加する方法は次のとおりです：
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-openai-spring-boot-starter</artifactId>
</dependency>
全画面表示 全画面表示を終了
application.yamlでは：
spring:
ai:
openai:
api-key: ${OPENAI_API_KEY}
chat:
options:
model: gpt-4.1
全画面表示 全画面表示を終了
コードでは：
@RestController
class ChatController {
private final ChatClient chatClient;
ChatController(ChatClient.Builder builder) {
this.chatClient = builder.build();
}
@PostMapping("/chat")
String chat(@RequestBody String message) {
return chatClient.prompt()
.user(message)
.call()
.content();
}
}
全画面表示 全画面表示を終了
これだけです。1つの依存関係、設定プロパティ、コンストラクタインジェクションで、LLMを呼び出すことができます。
LangChain4jはフレームワーク非依存です。Spring Boot、Quarkus、Helidon、Micronaut、またはプレーンJavaで使用できます。Springコンテキストにいることを前提としません。これにより移植性が高くなりますが、Spring Bootで使用する際は自分でより多くの配線を処理する必要があります。
Spring BootでLangChain4jを使用した同じチャットエンドポイントは次のとおりです：
@Configuration
class LangChain4jConfig {
@Bean
ChatLanguageModel chatModel() {
return OpenAiChatModel.builder()
.apiKey(System.getenv("OPENAI_API_KEY"))
.modelName("gpt-4.1")
.build();
}
}
@RestController
class ChatController {
private final ChatLanguageModel model;
ChatController(ChatLanguageModel model) {
this.model = model;
}
@PostMapping("/chat")
String chat(@RequestBody String message) {
return model.generate(message);
}
}
全画面表示 全画面表示を終了
コードは大幅に長くなるわけではありませんが、より明示的です。オートコンフィギュレーションに依存するのではなく、自分でモデルインスタンスを構築します。
LLMプロバイダーサポート
どちらのフレームワークも主要なプロバイダーをカバーしています。実用的な違いは一般的でないプロバイダーにあります。
Spring AI 2.0はOpenAI、Anthropic、Google Gemini、Amazon Bedrock、DeepSeek、Mistral AI、Ollama、Groq、Perplexity AI、NVIDIA、MiniMax、OCI Generative AI、Azure OpenAI、Docker Model Runnerをサポートしています。完全なリストはSpring AIリファレンスドキュメントにあります。
LangChain4jはOpenAI、Anthropic、Google Gemini、Azure OpenAI、Amazon Bedrock、Ollama、Mistral AI、DeepSeek、Groq、Perplexity AI、HuggingFace、LocalAI、その他約10をサポートしています。完全なリストは統合ページにあります。
違いは大手の名前にはありません。どちらもそれらを持っています。違いはロングテールにあります。LangChain4jにはコミュニティ提供の統合が多く、そのプラグイン風アーキテクチャにより新しいプロバイダーの追加が容易になります。Spring AIは数が少ないですが、それぞれSpringチームがメンテナンスし、一貫したAPIパターンに従っています。
勝者：主流プロバイダーは引き分け。難解なプロバイダーはLangChain4j。
ChatClient vs AI Servicesの違い
Spring AI 2.0は、WebClientやRestClientを意図的に模倣した流暢なChatClient APIを導入しました。.prompt()、.user()、.system()、.call()、.entity()の呼び出しを連鎖させます。冗長ですが表現力豊かで、リクエストの各部分を一目で確認できます。
LangChain4jは代わりにAI Servicesと呼ばれる宣言的パターンを推進しています。インターフェースを定義し、アノテーションを付け、LangChain4jが実行時に実装を生成します：
interface Assistant {
String chat(@UserMessage String message);
}
// Usage
Assistant assistant = AiServices.create(Assistant.class, model);
String response = assistant.chat("Hello!");
全画面表示 全画面表示を終了
これはSpring Data JPAのリポジトリパターンに近いものです。望むものを記述し、フレームワークが実装を生成します。
どちらのアプローチも機能します。ChatClient APIの方がフローが明示的でデバッグしやすいと感じます。AI Servicesパターンはシンプルなユースケースではクリーンですが、何か問題が発生したときに追跡しにくくなることがあります。
RAG: Retrieval-Augmented Generation
どちらのフレームワークもRAGをサポートしていますが、アプローチは異なります。
Spring AIはドキュメント取り込み用のETLフレームワークをバンドルしています。パイプラインを使用してドキュメントを読み取り、分割し、エンベッドし、ベクトルデータベースに保存できます：
var pipeline = DocumentReadConfig
.from("classpath:docs/")
.toVectorStore(pgvectorStore)
.splitter(TokenTextSplitter.builder().build())
.build();
pipeline.run();
全画面表示 全画面表示を終了
クエリ時には、Advisors APIを使用して関連するコンテキストを注入します：
chatClient.prompt()
.user(question)
.advisors(assistant.createContextRetrievalAdvisor(pgvectorStore))
.call()
.content();
全画面表示 全画面表示を終了
LangChain4jはContentRetriever抽象化を使用します。エンベディングストアとリトリーバーを設定し、それをAI Serviceに接続します：
var embeddingStore = new PgVectorEmbeddingStore(...);
var contentRetriever = new EmbeddingStoreContentRetriever(embeddingStore);
var assistant = AiServices.builder(Assistant.class)
.chatLanguageModel(model)
.contentRetriever(contentRetriever)
.build();
全画面表示 全画面表示を終了
どちらのフレームワークも主要なベクトルストアをサポートしています：pgvectorを使用したPostgreSQL、Pinecone、Qdrant、Milvus、Chroma、Redis、Weaviate、MongoDB Atlas、Cassandra、Elasticsearchなど。
違いはETLパイプラインにあります。Spring AIのDocumentReadConfigパイプラインはより意見が強く構造化されています。LangChain4jは各ステップに対してより多くの制御を提供しますが、より手動のセットアップが必要です。
MCP: Model Context Protocol
2026年において、2つのフレームワークが大きく異なる点です。
Spring AI 2.0は専用のBootスターターによるファーストクラスのMCPサポートを備えています。STDIO、SSE、Streamable-HTTPトランスポートを使用してMCPサーバーとクライアントを実行できます。Spring BeansをMCPツールとして公開するためのMCPアノテーションシステムもあります：
@McpServer
@Component
public class MathTools {
@McpTool(description = "Add two numbers")
public int add(@McpParam int a, @McpParam int b) {
return a + b;
}
}
全画面表示 全画面表示を終了
Spring AI 2.0はMCPを後付けではなくファーストクラスの統合ポイントとして扱います。application.yamlでMCPサーバーを設定すると、自動的に読み込まれます。
LangChain4jもツール呼び出しとファンクション呼び出しメカニズムを通じてMCPをサポートしています。しかし、同じレベルのオートコンフィギュレーションやアノテーション駆動のサーバーモデルはありません。MCPサーバーに接続することはできますが、手動で配線する必要があります。
MCPがアーキテクチャの核心である場合、現在はSpring AI 2.0に明確な優位性があります。
Spring AIを選択する場合
以下の場合はSpring AIを選択してください：
- すでにSpring Boot 4を使用している場合。オートコンフィギュレーション、プロパティ駆動のセットアップ、Springエコシステムの残りの部分との一貫性により、実際の開発時間を節約できます。
- 可観測性が必要な場合。Spring AIはMicrometerとSpring Boot Actuatorと箱から出して統合されています。追加の計装なしでトークン使用量、レイテンシ、エラーレートのメトリクスを取得できます。
- MCPが主要な統合パターンの場合。MCPアノテーションとオートコンフィギュレーションは、現在Javaエコシステムのどのフレームワークよりも進んでいます。
- Springチームのサポートが必要な場合。BroadcomはSpring AIに長期的にリソースをコミットしています。リリースサイクルはSpring Bootと連動しています。
Spring AIのドキュメントは優れています。リファレンスガイドは実行可能な例とともにすべての機能をカバーしています。
LangChain4jを選択する場合
以下の場合はLangChain4jを選択してください：
- Spring Bootを使用していない場合。Quarkus、Helidon、Micronaut、またはプレーンJavaを使用する場合、LangChain4jが自然な選択です。
- より幅広いプロバイダーとベクトルストアのエコシステムが必要な場合。コミュニティはより多くの統合をメンテナンスしており、リリースサイクルはどのフレームワークにも依存しません。
- AI Services宣言的パターンを好む場合。リポジトリスタイルのプロキシが自然に感じられる場合、LangChain4jはSpring AIよりもクリーンに提供します。
- フレームワーク非依存性を求める場合。Spring BootからQuarkus（またはその逆）に切り替える可能性がある場合、LangChain4jは移行コストを削減します。
LangChain4jの入門ガイドはdocs.langchain4j.devにあります。
実際に私がしたこと
2つのプロトタイプを構築した後、ドキュメントアシスタントにはSpring AIを選択しました。理由は退屈で実用的でした。プロジェクトがすでにSpring Boot 4上であり、オートコンフィギュレーションによる開発速度が顕著だったことです。Advisors APIによりRAGの実装が簡単になりました。MCPアノテーションにより、アダプターを書くことなく既存のSpring Beansをツールとして公開できました。
しかし、Quarkusでグリーンフィールドプロジェクトを開始する場合、または複数のJavaフレームワークで動作する必要があるライブラリを構築する場合は、迷わずLangChain4jを選択します。
どちらのフレームワークも優れたアプリケーションを生成します。誤った選択はそれらの間の選択ではなく、同じプロジェクトで両方を使用し、重複した抽象化を作成しようとすることです。
クイック決定マトリックス
使用フレームワーク -- Spring Boot 4？Spring AIを選択。それ以外のJVMフレームワーク？LangChain4jを選択。
プロバイダーカバレッジ -- 主流のプロバイダーは両方で十分サポートされています。難解またはコミュニティメンテナンスのプロバイダーはLangChain4jに傾きます。
MCP統合 -- Spring AI 2.0はオートコンフィギュレーション付きのファーストクラスでアノテーション駆動のMCPサポートを備えています。LangChain4jは手動配線が必要です。
可観測性 -- Spring AIはMicrometerとActuatorの組み込み統合を備えています。LangChain4jは独自の監視を配線することを期待します。
学習曲線 -- Spring Bootを知っている場合、Spring AIは自然に感じられます。SpringなしのJavaを知っている場合、LangChain4jの方が簡単に始められます。
プロジェクトの移植性 -- LangChain4jはフレームワーク非依存（Quarkus、Helidon、Micronaut、プレーンJavaで動作）です。Spring AIはSpringエコシステムに縛られます。
RAG用ETL -- Spring AIは構造化されたドキュメントパイプラインを提供します。LangChain4jは各ステップに対してより柔軟で手動の制御を提供します。
私は毎週Java、Spring Boot、AIについて書いています。購読してください。無料です。ニュースレタープラットフォームも無駄もありません。ダッカで実際のソフトウェアを構築しながら学んだことだけをお届けします。
Spring AIまたはLangChain4jを本番環境で使用したことはありますか？何が選択の決め手になりましたか？コメントであなたの経験をお聞かせください。
結論：機能リストを比較してフレームワークを選択してはいけません。プロジェクトの哲学に合ったものを選択してください。Spring AIはSpring Bootチームに速度と一貫性を報います。LangChain4jはあらゆるJVMチームに柔軟性と移植性を報います。どちらも本番環境対応です。あなたのコンテキストが決定します。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.