2026.06.29 プラットフォーム

Spring AI 2.0とは？2026年6月GAの新機能・Spring Boot 4移行・MCP対応を解説【2026年最新】

Spring AI 2.0は2026年6月12日にGA（正式版）としてリリースされ、Spring Boot 4.0/4.1とSpring Framework 7.0を前提とする新しい基盤へ刷新されました。本記事では、1.xから設計がどう変わったのか、エージェント実行を支えるアドバイザーチェーンとコアに取り込まれたMCP、そして既存のSpring Boot 3.x環境からの移行手順までを、公式リリースノートの一次情報に基づいて整理します。Javaバージョン要件やazure-openaiモジュール廃止といった破壊的変更、LangChain4jとの選択基準にも触れ、今すぐ採用すべきか見送るべきかの判断材料を示します。Spring Bootに慣れた開発者が、最短でSpringらしいAIアプリ開発に踏み出せる状態を目指します。

目次

まとめ：Spring AI 2.0の要点とSpring Boot 4必須という前提

Spring AI 2.0.0のGAは2026年6月12日です。最大の前提は「Spring Boot 4.0が必須」という点で、Spring Boot 3.xのコンテキストでは読み込めません。これは推奨ではなくアーキテクチャ上の制約であり、Boot 3.xを運用中のチームにとっては移行計画が採用の出発点になります。

中身の刷新は3層あります。基盤はJackson 3への移行とJSpecifyによるnull安全、オプションのbuilder必須化です。エージェント面では、各モデル内に隠れていたツール実行ループをChatClientのアドバイザーチェーンに統一しました。連携面では、コミュニティモジュールだったMCP（Model Context Protocol）がコア機能となり、アノテーション1つでSpringサービスをMCPサーバーとして公開できます。

採用の判断はチームの現在地で分かれます。新規開発ならBoot 4＋Spring AI 2.0で始めるのが素直です。Boot 3.xを運用中で2026年6月30日のEOL（Spring Boot 3.5・Spring Framework 6.2）まで移行猶予が無いなら、2.0を急がずEOL対応を先に固めるべきです。Springスタックを持たない、あるいは最大限のプロバイダー網羅と柔軟性が要るなら、フレームワーク非依存のLangChain4jも有力な選択肢になります。

Spring AI 2.0とは｜2026年6月GAと「Spring Boot 4必須」という新基盤

Spring AIは、OpenAIやAnthropicなどのLLMプロバイダーをSpring流の抽象で扱うためのアプリケーションフレームワークです。1.0は2025年5月にGAし、RAGとツール呼び出しを備えた「概念実証」として広がりました。2.0は機能追加よりも、設計・一貫性・品質の基準を引き直す「土台の作り直し」に主眼が置かれています。

2026年6月12日GA：Spring AI 2.0のリリース時期とバージョン体系（1.0/1.1/2.0）

Spring AI 2.0.0は2026年6月12日にMaven Centralで公開されました（リリースタグはv2.0.0）。GAに至るまでM1（2025年12月11日）からM8、RC1（2026年6月6日）と段階を踏んでいます。リリースラインは2.0系だけでなく、1.0.x・1.1.xも並行して保守されており、すぐにBoot 4へ動けないチームは当面1.1系のパッチで脆弱性対応を受けられます。実際、2.0.0-M3・1.1.3・1.0.4ではCVE-2026-22729とCVE-2026-22730が同時に修正されました。「最新版＝2.0」と単純化せず、自社のBootバージョンに合う系統を選ぶのが安全です。

Spring Boot 4.0/4.1・Framework 7.0前提への基盤刷新（Jackson 3・JSpecify）

2.0はSpring Boot 4.0/4.1およびSpring Framework 7.0で動くよう設計されています。Spring Boot 4.0は2025年11月20日にリリースされ、Jakarta EE 11、70以上のモジュール分割、API versioning、ポートフォリオ全体のJSpecify null安全を備えた、2022年のJakarta EE移行以来の大型リリースです。Spring AI 2.0もこの流れに沿い、JSON処理をJackson 2からJackson 3へ移行し、コードベース全体をJSpecifyで注釈しました。NullAwayと組み合わせることでnull安全がコンパイル時に強制され、Kotlinからは真の非nullable型として扱えます。基盤の詳細はSpring Boot 4の変更点・新機能側で補完できます。

オプション設計の再構築：setter廃止・builder必須・immutable化

null安全への対応は、オプションと設定プロパティの扱いそのものを作り直す契機になりました。OpenAiChatOptionsなどのオプションクラスはsetterが廃止され、builderでのみ生成、生成後はimmutableになります。これはOpenAIだけでなくAnthropic、Mistral AI、Google GenAI、Bedrock、MiniMax、ElevenLabsの各オプションに横断的に適用されました。デフォルト値はモデルや設定プロパティではなくオプション層に一元化され、プロパティキーから不自然だった.optionsセグメントも除去されています。setterで値を差し込んでいた1.x時代のコードは、builderベースへ書き換えが必要です。

対応プロバイダーの整理：SDK一本化とOllamaまでの標準サポート範囲

2.0はコアでサポートするチャットモデルプロバイダーを意図的に絞り込みました。OpenAIは3実装（Azure・HTTP・SDK）から公式SDKの1本へ、Anthropicは2実装からSDK1本へ、Google GenAIはGenAI SDKへ集約されています。標準でサポートされるのは次の構成です。

  • OpenAI（公式SDK。OpenAI互換APIの他社モデルにも利用可。既定チャットモデルはgpt-5-mini）
  • Anthropic（公式SDK。Minimaxなどの互換APIにも利用可）
  • Amazon Bedrock
  • Google GenAI（GenAI SDK）
  • Mistral AI／DeepSeek
  • Ollama（ローカルLLM。Llama・Mistral・PhiなどをAPIコストなしで実行）

このうちローカル実行は、開発・検証・機微データを扱う用途でコストとデータ持ち出しを抑える現実的な選択肢です。starterをOllama用に差し替えるだけでコードを変えずローカルモデルへ切り替えられます。導入の前提はOllamaの使い方で具体化できます。なお、OCI Generative AI（Oracle）やAzure Cosmos DB（Microsoft）はベンダー側が保守する形で提供されます。

Spring AI 2.0の主要な新機能｜エージェント実行基盤とMCPのコア統合

2.0で最も実装に効くのは、エージェント的な処理を組み立てる「足場」が整ったことです。1.xではツール呼び出しのループが各モデルの内部に埋め込まれ、フックも差し替えもできませんでした。2.0はこの構造を解体し、合成可能な部品として表に出しました。

Unified Tool Calling：ツール実行ループのアドバイザーチェーンへの移譲

2.0では、ツール実行ループがChatClientのアドバイザーチェーンに第一級の部品として載りました。各リクエストは順序付きのアドバイザー列を通り、ループ（下流チェーンへの再進入）も扱えます。具体的にはToolCallingAdvisorがChatClientに自動登録され、ツール呼び出しの往復を完結させます。各モデルが個別に抱えていたアドホックなツールループは撤去され、internalToolExecutionEnabledも廃止されました。各イテレーションを自分で制御したい場合は、明示的にオプトアウトして手動でループを回せます。同じ仕組みがツール呼び出し、構造化出力の再試行、評価ループを共通して駆動するのが設計の核心です。

数百ツールへのスケールと構造化出力の自己修正という2つの実行系統

ツール数が増えるとプロンプトが肥大化します。ToolSearchToolCallingAdvisorはツールを段階的に開示する仕組みで、セッションごとに全ツールを一度だけインデックス化し、モデルが必要なものをその都度取得します。数百のツールを毎リクエストに同梱せずに済むため、規模の大きいエージェントで効きます。もう一つの系統が構造化出力の信頼性です。ネイティブの構造化出力を有効にしても非準拠のJSONが返ることはあり、自動登録されるStructuredOutputValidationAdvisorが検証失敗時に再実行して自己修正します。「ツールの探索」と「出力の検証」という別々の信頼性課題が、同じアドバイザー機構の上で解けるようになりました。

MCPがコア機能に：@McpToolなどアノテーションとStreamable HTTP既定化

1.xでコミュニティモジュールだったMCP（Model Context Protocol）が、2.0でコアに統合されました。Spring AI 2.0は公式のMCP Java SDK 2.0.0を同梱し、2025年11月25日版のMCP仕様に準拠します。mcp-annotationsモジュールが取り込まれ、@McpTool・@McpResource・@McpPromptを付けるだけで、任意のSpringサービスをMCPサーバーの機能として公開できます。クライアント側も第一級で、サンプリング・elicitation・能力変更通知を宣言的ハンドラで扱えます。トランスポートはWebMVC/WebFlux実装がMCP Java SDKからSpring AI側へ移管され、Streamable HTTPが既定となって非推奨のSSEを置き換えました。リモート配備でスケールさせたい場合はステートレス版を、ローカルのプロセス連携にはSTDIOを選べます。結果として、1つのSpring BootアプリがMCPクライアントとMCPサーバーを同時に務められます。

MCPの本番運用：OAuth 2.0／APIキー認証とMicrometer可観測性

MCPがコアに入ったことで、Springの本番スタックをそのまま継承できます。サーバー連携にはMicrometerのスパンとOpenTelemetry互換メトリクスが付き、可観測性を後付けせずに確保できます。認証はspring-ai-community/mcp-securityプロジェクトを通じてOAuth 2.0とAPIキーに対応します。外部にツールを公開するMCPサーバーは事実上の攻撃面になるため、認可の設計は最初に決めるべき項目です。Spring Securityのフィルタ構成に不慣れな場合はSecurityFilterChainの仕組みを先に押さえると、MCPエンドポイントの保護を組み立てやすくなります。

Spring AI 1.xからの移行｜破壊的変更とSpring Boot 4移行の段取り

2.0の恩恵を受ける条件は、まずBoot 4に乗ることです。ここを飛ばして「Spring AIだけ上げる」ことはできません。移行の難所はSpring AIではなくSpring Boot 4側にあり、その規模を見誤ると期日に追われます。

大前提：Spring Boot 3.xでは動かない事実とJavaバージョン要件

Spring AI 2.0はSpring Boot 4.0の依存モデル上に作られており、3.xコンテキストでは読み込めません。Spring Boot 4.0の最低ラインはJava 17ですが、仮想スレッドなどを活かすためJava 21以降が推奨で、Spring AI 2.0のM1告知では「開発にJava 21が必要」と明記されました。実務上はJava 21を基準に据えるのが無難です。さらにBoot 4.0ではJackson 3が必須化し、JUnit 4とUndertowが除去され、3.x系で非推奨だったAPIは一掃されます。なお、Spring Boot 3.5とSpring Framework 6.2は2026年6月30日にEOLを迎えます。自社がどのBootバージョンにいて、どこまで延命できるかはSpring Bootのバージョン一覧とサポート期限で確認しておくと、移行の緊急度を正しく見積もれます。

主な破壊的変更：azure-openaiモジュール廃止とJackson 3・ツールAPI整理

2.0では既存コードに直接刺さる変更がいくつかあります。影響範囲の広いものから順に挙げます。

  • azure-openaiモジュール廃止：spring-ai-azure-openaiが削除され、Azure OpenAIの機能は標準のspring-ai-openaiへ統合。Azure利用中なら依存を差し替える必要があります
  • Jackson 3：グループIDがcom.fasterxml.jacksonからtools.jacksonへ変更。JsonProcessingExceptionがIOExceptionを継承しなくなり、catch (IOException e)で握っていた箇所はコンパイルエラー無しに挙動が変わります
  • ツール実行API整理：internalToolExecutionEnabledとtoolNames()、SpringBeanToolCallbackResolverが廃止。明示的なToolCallback Beanへ寄せる設計に変わりました
  • ベクトルストア削減：InfinispanとSAP HANA DBのベクトルストアモジュールが削除

特にJackson 3のcatch句の罠は「動いているように見えて静かに壊れる」典型です。Azureからの移行を伴うチームは、Azure OpenAI ServiceとOpenAI APIの違いを踏まえたうえでプロバイダー設定を見直すと混乱を避けられます。

推奨移行手順：3.5へ→Jackson移行→Boot 4→Spring AI 2.0の順序

Boot 3.2から4.0へ一気に上げるのは避け、段階を踏むのが公式の推奨です。手順は次の通りです。

  1. Spring Boot 3.5へ上げ、非推奨警告をすべて解消する（3.5で残った非推奨APIは4.0で代替なく消えるため）
  2. Jackson 2→3を移行する（OpenRewriteのレシピorg.openrewrite.java.jackson.UpgradeJackson_2_3で機械的な改名を自動化し、catch句のIOException変更は手動で確認）
  3. Spring Boot 4.0へ上げる（公式の移行ガイドをチェックリストとして使用）
  4. 最後にSpring AI 2.0のstarterを追加する（基盤が整った状態で導入）

新規プロジェクトならこの移行経路は不要です。start.spring.ioでSpring Boot 4.0系を選び、プロバイダーとベクトルストアのSpring AI starterを足せば、最初から正しい構成で始められます。依存のバージョン整合はspring-ai-bomに任せるとブレません。

Spring AI 2.0を今採用すべきかの判断｜見送る基準とLangChain4jとの使い分け

「新しいから入れる」では判断を誤ります。2.0の価値はBoot 4を前提に最大化される一方、移行コストもBoot 4に紐づきます。状況別に、採用すべきケースと見送るべきケースを切り分けます。

グリーンフィールドはBoot 4＋Spring AI 2.0で始めるべき理由

新規開発は迷わず2.0で始めるべきです。移行負債が無く、Boot 4のモジュール構成・null安全・API versioningを最初から享受できます。エージェント設計でも、アドバイザーチェーンとMCPのコア統合があるため、ツール実行や外部連携を後から無理に作り込まずに済みます。既定がgpt-5-mini、プロバイダー差し替えが依存とプロパティの変更で完結する点も、立ち上げの速度に効きます。greenfieldで1.xを選ぶ理由はほぼありません。

移行猶予が無いなら2.0を急がない：EOL対応を先行させる失敗回避

ここは言い切ります。Spring Boot 3.xを本番運用していて、2026年6月30日のEOLまでにBoot 4移行を完了できる見込みが無いなら、2.0採用を先送りし、まずEOL対応を確定させるべきです。非自明な規模のエンタープライズ用途でBoot 4移行は数週間では終わらず、GA直後から期日まで走っても圧縮された移行になりがちです。典型的な失敗パターンは、AI 2.0の機能を取りに行った結果、依存互換監査・非推奨API整理・Jackson 3互換確認・テスト整備を飛ばし、本番リスクを抱えたまま期日に間に合わせることです。脆弱性対応だけが目的なら、1.1系のパッチで足りる場面も多くあります。移行は締め切りに追われるスプリントではなく、計画的に進める前提を置くべきです。

Spring AI 2.0 vs LangChain4j：Spring Boot資産の有無で決める選択

JavaのAIフレームワークはSpring AIとLangChain4jが二大選択肢です。判断軸はシンプルで、Spring Bootの資産があるかどうかです。

観点 Spring AI 2.0 LangChain4j
設計思想 Springに統合された意見の強い構成（Advisors・Bean as Tool） 細かい部品を組む「レゴ型」の柔軟構成
対象スタック Spring Boot 4が前提 Quarkus・Micronaut・Helidon・素のJavaでも動作
連携の広さ コアは主要プロバイダーに集約 より多くのLLM・ベクトルストアに対応
向くチーム 既にSpring Bootに投資し、AIを自然な拡張にしたい 最大限の柔軟性や非Springスタックが必要

結論として、Spring Bootで動いている、あるいはこれからBoot 4で作るチームはSpring AI 2.0が素直です。フレームワークを固定したくない、対応プロバイダーの幅を最優先する、Springを使っていないといった条件ではLangChain4jが合います。「どちらが優れているか」ではなく「自分のスタックにどちらが馴染むか」で選ぶのが実務上の正解です。

Spring AI 2.0に関するよくある質問

Spring AI 2.0の導入・移行でよく問われる点を、一次情報に基づいて簡潔に回答します。

Spring AI 2.0はいつリリースされましたか？

2.0.0のGA（正式版）は2026年6月12日にMaven Centralで公開されました。M1は2025年12月11日で、その後M2〜M8、RC1（2026年6月6日）を経てGAに至っています。1.0.x・1.1.xのリリースラインも並行して保守されています。

Spring AI 2.0はSpring Boot 3.xで使えますか？

使えません。Spring AI 2.0はSpring Boot 4.0の依存モデル上に構築されており、3.xコンテキストでは読み込めない設計です。Boot 3.xを使い続けるなら、Spring AIは1.1系を利用するのが現実的です。

Spring AI 2.0に必要なJavaのバージョンは？

前提となるSpring Boot 4.0の最低ラインはJava 17ですが、仮想スレッドなどを活かすためJava 21以降が推奨されます。Spring AI 2.0のM1告知でも「開発にJava 21が必要」と示されており、実務上はJava 21を基準にするのが無難です。

Spring AI 2.0でMCPサーバーは作れますか？

作れます。コアに統合されたmcp-annotationsを使い、@McpTool・@McpResource・@McpPromptを付けるだけで、Springサービスの機能をMCPサーバーとして公開できます。1つのアプリがMCPクライアントとサーバーを兼ねることも可能で、既定トランスポートはStreamable HTTPです。

Spring AIとLangChain4jはどちらを選ぶべきですか？

Spring Bootの資産があるか、これからBoot 4で作るチームはSpring AI 2.0が馴染みます。フレームワーク非依存の柔軟性や、より広いプロバイダー対応を最優先する場合、あるいは非Springスタックの場合はLangChain4jが適します。自社スタックとの相性で選ぶのが基準です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る