エンタープライズJavaにおけるAI統合の次なる課題：Spring AIとMCPの普及がもたらすセキュリティ危機

Javaエコシステムの技術カンファレンス「UberConf 2026」が米国コロラド州で開幕し、エンタープライズJavaにおけるAI導入は統合の段階からガバナンスとセキュリティの段階へと移行していることが浮き彫りになった。Spring AIやMCP（Model Context Protocol）の普及によりAIの実装は容易になった一方で、AI生成コードの脆弱性やエージェントの認証管理が新たな課題として指摘されている。開発チームは、AIツールの活用と並行して、厳格なアーキテクチャ設計とセキュリティポリシーの構築を迫られている。

■AI統合からガバナンスへ移行するJavaエコシステム

Javaエコシステムの主要な技術カンファレンスである「UberConf 2026」が、コロラド州デンバーのウェスティン・ウェストミンスターで開幕した。150のセッションに登壇する40名以上のスピーカーたちは、エンタープライズJavaにAIを導入すべきかどうかを議論しているのではない。彼らは、組織の本番システムですでに進行しているAI導入をどのようにガバナンス（統治）するかを教えている。カンファレンスは7月17日（金）まで開催される。

Javaエコシステムは、AI統合の問題を概ね解決したと言える。Spring Frameworkの公式抽象化レイヤーである「Spring AI」は2025年に本番環境での利用に対応し、Spring BootアプリケーションにAIを組み込むチームにとっての事実上の標準となった。また、AIエージェントを外部ツールやデータソースに接続するためのオープン標準「MCP（Model Context Protocol）」は、月間SDKダウンロード数が9,700万回を超え、Fortune 500企業の推定28%で導入されているとみられる。今年のカンファレンスのほぼすべてのセッションで問われているのは「次は何が来るのか」であり、シニアエンジニアたちが提示する答えはシビアなものだ。エンタープライズJavaは統合を解決したが、ガバナンスはまだ解決していないという。

■Spring AIの本番環境対応とセキュリティの代償

Spring AIの本番環境への対応は本格的だ。このフレームワークは、Spring Bootの確立された自動構成モデルをAI領域に適用している。開発者は、OpenAI、Anthropic、Azure OpenAI、Google Geminiなどのプロバイダーの依存関係を追加し、プロパティファイルにAPIキーを提供し、他のSpring管理コンポーネントと同様にChatClientやChatModelのBeanを注入するだけでよい。AIプロバイダーを切り替える際も、アプリケーションコードを書き換える必要はなく、依存関係と設定プロパティを変更するだけで済む。BroadcomのSpring Developer Advocateであり、Java界隈で広く支持されているJosh Long氏は、プロンプトのテンプレート化、RAG（検索拡張生成）パイプライン、会話メモリ、MCP統合などを網羅するSpring BootのAI統合に関する複数のセッションと1日ワークショップを主導している。

しかし、本番環境への対応というストーリーが完全に捉えきれていないのは、Spring AIの急速な普及が、攻撃対象領域（アタックサーフェス）の急速な拡大をもたらしたという事実だ。2026年4月、コミュニティからSpringチームに報告されたセキュリティアドバイザリは、過去の平均と比較して1,700%以上も急増した。これは、AIを活用した脆弱性スキャナーが、Springの依存関係グラフ内のバグをかつてない速度で発見したことの直接的な結果である。Broadcomは、フレームワークの23年の歴史の中で最大規模とされるSpringセキュリティアップデートでこれに対応した。公開された脆弱性の中には、Spring AIバージョン1.0.xから1.1.xに影響を与え、特別に細工されたフィルタ文字列を介してSpring AIのベクトルストアインターフェースでSQLインジェクションを許す「CVE-2026-47835」や、影響を受けるサーバーでのリモートコード実行を可能にするRAGパイプライン実装のSpring Expression Languageインジェクションの欠陥「CVE-2026-22738」が含まれていた。

セキュリティの状況はさらに具体的になっている。2026年春にVeracodeが発表した調査によると、Javaコードの5つの重要な脆弱性カテゴリにわたって最新の主要AIモデルをテストした結果、AIが生成したJavaコードのセキュリティ合格率は約55%にとどまっていることが判明した。LLMの機能は大幅に向上しているにもかかわらず、2年前とほぼ同じ水準である。同調査ではJavaのパフォーマンスが他の言語よりも悪かったが、研究者らはその理由を、最新のセキュリティフレームワーク以前の公開リポジトリにあるレガシーなJavaパターンをAIモデルが過剰に学習しているためだと分析している。実用的な観点から言えば、明示的なセキュリティ重視のプロンプトやレビューなしに生成されたAI生成Javaコードの約半数には、既知の悪用可能な脆弱性が含まれているということになる。

このような背景から、UberConf 2026のセキュリティトラックは直接的な運用上の重要性を帯びている。カンファレンスの「エンドツーエンドAIセキュリティ」ワークショップでは、プロンプトとコンテキストのセキュリティ、ガードレールの実装、MCPサーバーの堅牢化、敵対的テスト、ポリシー主導のガバナンス、セキュアなエージェントのライフサイクル管理を網羅する8つの構造化されたラボが展開されている。参加者は、セキュリティが他人の問題であるというデモンストレーションではなく、ゼロから構築された安全で監査可能、かつポリシー制御されたAIシステムを持ち帰ることが明確な目的とされている。

■エンタープライズインフラとなるMCP、残る認証の課題

2024年11月にAnthropicによって導入され、2025年12月にLinux FoundationのAgentic AI Foundationに寄贈されたMCPは、N対Mの統合の複雑さを解消しつつある。このプロトコルが主流になる前は、AIエージェントを新しいデータソースやエンタープライズツールに接続するには、組み合わせごとにカスタムの統合コードが必要だった。MCPはこの接続を標準化し、リソースごとに1つのサーバーを用意すれば、MCP互換のエージェントクライアントならどれでも利用できるようにした。MCPの初期から言われている「AIのためのUSB-C」という例えは、基盤となるアーキテクチャの性質を正確に表している。

7月28日に最終公開が予定されているMCPの次期メジャー仕様（バージョン2026-07-28）のリリース候補版は、2026年5月21日にロックされた。アーキテクチャ上の最大の変更点は、ステートレスなプロトコルコアへの移行である。現在のMCPサーバーはセッション状態を維持する必要があり、これがスティッキーなルーティングを強制し、標準的なロードバランサーやAPIゲートウェイの背後での水平スケーリングを制限している。新しい仕様では、セッションの作成、再開、移行が標準化され、サーバーの再起動やスケールアウトのイベントが接続されたクライアントに対して透過的になる。また、リソース読み取りのためのTTLベースのキャッシュ制御（HTTPのCache-Controlセマンティクスを直接モデル化）や、メタデータレイヤーでのW3C Trace Contextの伝播も導入され、ホストアプリケーションからクライアントSDK、MCPサーバー、そしてサーバーが呼び出すダウンストリームに至るまで、ツール呼び出しの分散トレースが可能になる。

しかし、この仕様リリースでも解決されないのが認証（Auth）の問題だ。本番環境でのMCP展開において、認証は一貫して最も困難な未解決問題とされている。OAuth 2.1のトークンライフサイクルは長時間稼働するエージェントセッションの期間と一致せず、サーバーごと・ユーザーごとの同意プロンプトは手動でのオンボーディングの摩擦を生み、スケールしない。さらに、個人アカウントとエンタープライズアカウントのアクセスの境界が曖昧になり、コンプライアンス上のリスクを生み出している。Anthropic、Microsoft、Okta、Asana、Atlassian、Figma、Slackがサポートし、最近安定化した「Enterprise-Managed Authorization」拡張機能は、組織の既存のIDプロバイダーを通じて認証をルーティングすることで同意プロンプトの問題に対処し、ユーザーごとのハンドシェイクを管理者が一度定義する集中型ポリシーに置き換える。それでも、現在本番環境で稼働しているMCPサーバーは全体の約5%にすぎず、残りは開発者のラップトップ上で動いているという現状は、認証とガバナンスの摩擦が依然として残っていることを示している。

UberConf 2026の複数のセッションでは、このインフラのギャップに直接対処している。Spring AI（バージョン1.0でネイティブなMCPサポートを導入し、1.1で大幅に拡張）を使用したMCPサーバー構築のディープダイブ、MCPメッセージフローのライブでのプロトコルレベルの解体、製品固有のプロトコルではなく相互運用性アーキテクチャとしてのMCPの分析、そして参加者が生のプロトコルから機能するMCPサーバーを記述し、それを使用するエージェントを構築するハンズオンワークショップなどが含まれる。Principal EngineerでありJava Champion、そして新刊『Spring AI in Action』の著者であるCraig Walls氏は、Spring AIのフルプロダクションスタックとともにMCP統合について解説している。

■仮想スレッドがJava AIワークロードの経済性を変えた理由

カンファレンスのModern Javaトラックにおける静かだが実質的に重要な変化の1つは、仮想スレッド（Virtual Threads）が新機能としてではなく、定着したインフラとして扱われていることだ。JDK 21でProject Loomの一部として最終化された仮想スレッドは、オペレーティングシステム（OS）ではなくJVMによって完全に管理される軽量スレッドである。OSスレッドと1対1でマッピングされ、それぞれ約1MBのスタック領域を消費する従来のプラットフォームスレッドとは異なり、仮想スレッドはJVMによって少数のキャリアスレッドのプール上でスケジュールされる。仮想スレッドがデータベース呼び出し、HTTPリクエスト、LLM API呼び出しなどのI/O操作でブロックされると、JVMは即座にそれを待機させ、OSレベルのコンテキストスイッチなしに同じキャリアスレッド上で別の仮想スレッドをスケジュールする。OSスレッドがブロックされることはない。

AIワークロードにとって、これは直接的な意味を持つ。LLM APIの呼び出しは本質的にレイテンシが高く、モデルの応答を300〜2,000ミリ秒待つ間スレッドを保持し続けるというワークロードこそが、リアクティブプログラミングのフレームワークを必要と感じさせていた理由だった。仮想スレッドはそのトレードオフを排除する。数千の同時LLMリクエストを処理するSpring Bootアプリケーションは、リアクターチェーンやコールバックスタック、ノンブロッキングDSLを使用することなく、Java開発者が常に知っているシンプルなブロッキングプログラミングモデルを使用しながら、リアクティブプログラミングが提供するように設計されたのと同じ並行性のヘッドルームを達成できるようになった。経済的な結果として、Javaバックエンドと並行して個別のPython AIサービススタックを維持するための追加のインフラコストは、パフォーマンスの理由だけでは正当化されなくなった。

理解しておくべき制約は、仮想スレッドが対処するのはI/Oバウンドのレイテンシであり、CPUバウンドのスループットではないということだ。埋め込み計算、大規模なトークン化、ローカルホストモデルでの推論など、計算集約型のワークロードに対しては、仮想スレッドは並行性の利点を提供しない。特定のアーキテクチャにおいて仮想スレッドがリアクティブプログラミングを置き換えるかどうかを評価するチームは、決定を下す前にワークロードの特性を把握する必要がある。Josh Long氏の1日Spring Bootワークショップでは、より広範なSpringエコシステムとともに、この違いが明確にカバーされている。

■コード生成が安価になる中、アーキテクチャの重要性が増す

ソフトウェアアーキテクチャトラック、AIガバナンストラック、技術リーダーシップワークショップを通じて、カンファレンスで最も一貫して主張されているのは、「AIによるコード生成の加速は、アーキテクチャの規律の重要性を低下させたのではなく、むしろ高めた」ということだ。

ソフトウェアアーキテクトのMichael Carducci氏は、「Tailor-Made Architecture Model」と呼ぶ3セッションのシリーズで、この問題を制約理論の観点から説明している。AIツールがコード生成を加速させているため、ソフトウェアデリバリーのボトルネックは上流の設計とアーキテクチャに移行した。真の制約が純粋な出力ボリュームではなくアーキテクチャの一貫性である場合、より多くのコードをより速く生成するという局所的な最適化は、システム全体のスループットを悪化させる。「コードが安価なとき、アーキテクチャがすべてである（When Code is Cheap, Architecture is Everything）」と題されたセッションは、このテーゼを直接的に示している。

『A Software Enchiridion』の著者であり、Substackシリーズ「Engineering Agents」のクリエイターであるRussell Miles氏は、AIエージェントエンジニアリングにGOAP（目標指向アクションプランニング）とOODAループ（観察、情勢判断、意思決定、行動：空軍大佐John Boydによって開発された意思決定モデル）を適用する新しいJVMベースのフレームワーク「Embabel」に関する2つのセッションと1日ワークショップを開催している。MITメディアラボのJeff Orkin氏によって開発され、F.E.A.R.（2005年）などのゲームAIシステムに導入されたGOAPは、エージェントがいかなるアクションを実行する前にも明示的な事前条件を満たし、実行中も型付けされた不変条件を維持することを要求する。この規律をLLMエージェントに適用するということは、エージェントがドメインの制約を暗黙のうちに違反したり、レビューされていない副作用を生成したりできないことを意味する。エージェントは行動する前に、チェック可能で監査可能な事前条件を満たさなければならない。このフレームワークはまた、Miles氏がDICE（Domain-Integrated Context Engineering）と呼ぶものを導入しており、エージェントが生のテキストではなく型付けされたJavaドメインモデル上で直接推論できるようにすることで、Java開発者がランタイムエラーのクラス全体を防ぐためにすでに使用している型安全性を維持する。

Embabelの背後にある実践的なテーゼは、「バイブコーディング（vibe coding）」の問題、つまりAIがもっともらしく見えるコードを生成し、隠れた結合、セキュリティの脆弱性、設計のドリフトを蓄積させる問題は、モデルの品質の問題ではなくアーキテクチャの問題であるということだ。監査可能なAI支援開発を生み出すのは、より優れたプロンプトではなく、エージェントレベルでのより優れたガードレールである。

■JavaはAIエンタープライズを運用する準備ができているか

業界のデータは、慎重ながらも自信を裏付けている。Azulの「2026 State of Java Survey」によると、2026年初頭までに、AI機能にJavaを使用していると報告した企業は62%に達し、1年前の50%から増加した。Spring AIの自動構成モデルは統合の摩擦を劇的に低下させた。以前はJavaバックエンドと並行して個別のPython AIサービスを維持する必要があったチームも、現在では既存のSpring BootアプリケーションにLLMワークフローを直接統合し、すでに運用しているのと同じ依存性の注入、可観測性、設定パターンを使用できるようになった。バルセロナで開催されたSpring I/O 2026でも、UberConfのプログラムを貫くのと同じ結論が確認された。2026年のJavaチームにとっての問いは、もはや「LLMをどう呼び出すか」ではない。「組織が要求するセキュリティとガバナンスの制御を備え、責任を持って大規模にエージェントワークフローを構築するにはどうすればよいか」である。

この問いの変化こそが、UberConf 2026のセキュリティトラックとガバナンスのコンテンツを、単なる理論的なプログラミング以上のものにしている。プラットフォームエンジニアリングは、2026年までに大規模なエンジニアリング組織の80%で採用されるというGartnerの予測に向かって進んでおり、このカンファレンスで行われているアーキテクチャ上の決定は、その選択が組織内のすべての開発チームの標準ツールチェーンとなるプラットフォームチームによってますます行われるようになっていることを意味する。このようなイベントで支持されるフレームワーク、プロトコル、セキュリティ態勢は、カンファレンスのセッション概要ではめったに捉えられないほどの組織的な影響力を持っている。

Spring Boot 3.5は2026年6月30日にサポート終了（EOL）を迎えた。パッチが適用されていないEOL後のバージョンを実行し続けている組織は、Spring SecurityおよびSpring Cloud Gatewayの実装において文書化された悪用可能な脆弱性に直面しており、さらなるCVEの修正にアクセスすることはできない。Spring Boot 4.0およびSpring AI 2.0への移行パスは、このリスクをクリアするのと同じパスであり、カンファレンスのModern JavaおよびSecurityトラックは、移行の範囲とそれに続くセキュリティ態勢の両方に対処している。

2026年7月時点でのJava AIエコシステムの現状に対する最も率直な評価は、セッションリスト自体に埋め込まれているものかもしれない。UberConf 2026には、参加者が1日でゼロから安全なAIシステムを構築することを学ぶAIセキュリティワークショップ、参加者が1日で独自のプロトコル実装を記述することを学ぶMCPサーバーワークショップ、そしてエージェントは最初から自律性を持つのではなく、自律性を獲得しなければならないと主張するエージェントガバナンスセッションが含まれている。カンファレンスがこれら3つを同時に教える必要があるという事実こそが、エコシステムが現在どこにあるのかを正確に物語っている。つまり、統合インフラストラクチャにおいては有能で本番環境の準備が整っているが、責任ある本番展開に必要な規律とガバナンスレイヤーはまだ構築中であるということだ。

■注目ポイントQ&A

●2026年現在、エンタープライズJavaアプリケーションにおいてSpring AIは実際に本番環境で利用可能ですか、それともまだ実験段階ですか？

Spring AIは2025年5月の1.0リリースでGA（一般提供）ステータスに達し、2026年5月にバージョン2.0（Spring Boot 4.0が必要）をリリースしました。UberConf 2026やSpring I/O 2026などのイベントに参加する業界の実務者は、これを実験的なフレームワークではなく本番インフラとして扱っています。複数の独立した評価により、2026年初頭の時点でLangChain4jとSpring AIの両方が本番環境に対応し、実戦でテストされていることが確認されています。現在Spring Boot 3.xを使用しているチームにとっての主な移行の考慮事項は、Spring AI 2.0にはSpring Boot 4.0が必要であること、そしてSpring Boot 3.5が2026年6月30日にサポート終了（EOL）を迎えたことです。延長サポートなしで3.5を実行しているチームは、もはやセキュリティパッチを受け取れません。

●MCPとは何ですか？また、AIシステムを構築するJava開発者にとってなぜ重要なのですか？

MCP（Model Context Protocol）は、2024年11月にAnthropicによって導入され、現在はLinux Foundationによって管理されているオープン標準であり、AIエージェントが外部ツールやデータソースに接続する方法を標準化します。LLMとエンタープライズデータソースの組み合わせごとにカスタムの統合コードを書く代わりに、チームはリソースごとに1つのMCPサーバーを構築し、MCP互換のエージェントであればどれでもそれを使用できるようになります。特にJava開発者にとって、Spring AIはバージョン1.0でネイティブなMCPサポートを導入し、1.1で拡張しました。MCPサーバーは標準のSpringアノテーションを使用して構築でき、AIプロバイダーの接続を処理するのと同じSpring Bootの自動構成モデルがMCPクライアントの接続も処理します。現在の本番環境におけるボトルネックは認証です。OAuth 2.1のトークンライフサイクルは長時間稼働するエージェントセッションと一致せず、企業はサーバーごとの同意プロンプトではなく、ゲートウェイレベルの認証管理を必要としています。

●LLM API呼び出しを伴うAIワークロードにおいて、Javaチームはリアクティブプログラミングと仮想スレッドのどちらを使用すべきですか？

ほとんどのLLM APIワークロードは、CPUバウンドではなくI/Oバウンド（モデルの応答待ち）であるため、現在では仮想スレッド（JDK 21で最終化されたProject Loom）が推奨されるアプローチです。仮想スレッドを使用すると、Project ReactorやRxJavaなどのリアクティブフレームワークのコードの複雑さなしに、JVMが少数のキャリアスレッドのプール上で数百万の同時ブロッキング操作を処理できるようになります。トレードオフとして、仮想スレッドはI/Oバウンドの並行性を向上させますが、CPUバウンドの計算には利点を提供しません。ワークロードにローカルホストモデルの推論や大規模なトークン化が含まれる場合は、リアクティブプログラミングや明示的なスレッドプールのサイジングが依然として正当化される可能性があります。Spring AIを介した標準的なLLM API統合の場合、仮想スレッドとブロッキングプログラミングモデルが推奨される出発点です。

●カンファレンスではエージェントAIのガバナンスが広く取り上げられていますが、エンジニアリングチームにとってこれは実際には何を意味するのでしょうか？

エージェントのガバナンスとは、自律型エージェントが実行できることを、実行する前に制御するための信頼境界、権限スコープ、および監査メカニズムを定義することを意味します。実際には、エージェントがどのツールをどのような条件で呼び出せるかを強制するポリシー・アズ・コード、影響範囲の管理（障害や誤動作がスタック全体に伝播しないように、エージェントが書き込みアクセスできるシステムを制限すること）、エージェントのすべての決定、ツール呼び出し、および結果の監査可能なログを生成する可観測性、そして定義された信頼度のしきい値を超えるアクションに対する人間のエスカレーションパスなどが含まれます。UberConf 2026で使用されている「エージェントは最初から自律性を持つのではなく、自律性を獲得する」という概念的な枠組みは、エージェントのアクションが実行される前に明示的な事前条件と不変条件を要求するGOAP（目標指向アクションプランニング）アーキテクチャに直接マッピングされます。明示的なガイダンスなしに生成されたAI生成Javaコードの約半数に既知のセキュリティ脆弱性が含まれているというVeracodeの調査結果は、これらのガバナンス構造がオプションではない理由を示す経験的な根拠となっています。

元記事: Enterprise Java Embraces Spring AI and MCP as Agent Security Becomes Its Next Crisis