JavaベースのマイクロサービスやバッチジョブにAIエージェントを組み込む計画があるSREやインフラ担当者に向けた話です。2026年初頭、Spring Framework（Javaの依存性注入基盤として2003年に登場した定番フレームワーク）の作者Rod Johnson氏が、Embabelという新しいAIエージェントフレームワークを発表しました。単なる新ツールの紹介ではなく、なぜこの設計が可用性設計と相性が良いのかを整理します。
これまでJavaでLLM（大規模言語モデル）を扱う選択肢は、Spring AIかLangChain4jが中心でした。Spring AIはSpringエコシステムにLLM連携を持ち込むライブラリです。LangChain4jはPython向けLangChainのパターンをJavaに移植したものです。どちらもプロンプトを送って応答を受け取る「チャットボット型」の構造が土台になっています。
この構造には限界があります。数分〜数十分かかる複数ステップの処理を計画的に実行したり、失敗時に自分の作業を検証してリトライしたり、複数エージェントを協調させたりする用途には向いていません。Embabelはまさにこの領域を狙って作られています。
GOAPという設計思想の中身
Embabelの核心はGOAP（Goal-Oriented Action Planning、ゴール指向の行動計画）というゲームAI由来の技術です。F.E.A.R.やKillzoneといったゲームのNPC行動制御に使われてきた仕組みで、各アクションに「事前条件（実行前に満たすべき状態）」と「効果（実行後に変化する状態）」を定義します。
プランナーと呼ばれる計画エンジンが、現在の状態からゴールまでの行動列を組み立てます。ここで重要なのは、この計画立案自体がLLM呼び出しではなく決定的なアルゴリズムだという点です。つまり「なぜこの手順で実行したか」を後から機械的に説明できます。
これはSRE視点で見逃せない特性です。障害調査や監査で「エージェントがなぜその操作をしたのか」を追跡できるかどうかは、本番投入の可否を左右します。LLMの応答は非決定的（同じ入力でも毎回結果が変わりうる）ですが、Embabelでは計画部分だけを決定的な処理として切り離しています。
EmbabelはKotlinで書かれていますが、JavaコードからもBeanとアノテーションで自然に扱えます。設計上の位置づけは、Johnson氏自身が「Spring AIとEmbabelの関係は、Servlet APIとSpring MVCの関係に近い」と説明しています。Spring AIがモデル接続やプロンプトテンプレートといった低レベルの配線を担い、Embabelがその上でエージェントのオーケストレーション（複数処理の調整・実行管理）を担う構造です。
コードで見る役割分担
実装は@Agent（状態と能力を持つコンポーネント）、@Action（事前条件と効果を持つ処理単位）、@AchievesGoal（ゴール到達を示すメソッド）という3つのアノテーションで表現されます。ブログ記事を書いて校閲するエージェントの例では、下書きを作るwriteDraftメソッドと、それをレビューするreviewDraftメソッドをそれぞれ@Actionとして定義し、後者に@AchievesGoalを付けています。
@Agent(description = "Write and review a blog post")
public class BlogWriterAgent {
@Action(description = "Write a first draft")
public BlogDraft writeDraft(UserInput input, AI ai) {
return ai.withDefaultLlm()
.creating(BlogDraft.class)
.fromPrompt("Write a blog post about " + input.getContent());
}
}アクションが完了するたびにプランナーが状態を再評価し、ゴール未達なら再計画します。このループはゴール達成か、システム側の打ち切り判断まで続きます。バッチ処理でリトライ回数の上限やタイムアウトを設計する感覚に近いものがあります。
既存のオーケストレーション基盤との比較
インフラ屋の視点では、これはKubernetesのコントローラーパターン（望ましい状態と現在の状態を比較し続けて収束させる仕組み）に近い構造だと捉えると理解しやすいです。KubernetesのReconcile Loop（差分を検知して調整するループ）が「宣言的な状態」を扱うのに対し、EmbabelのPlanner再評価ループは「宣言的なゴール」に対して行動計画を組み直します。
TerraformのようなIaC（Infrastructure as Code、インフラ構成をコードで管理する手法）と比べると対比がより明確です。Terraformはterraform planで差分を計算し、applyで決定的に適用します。計画立案が決定的である点はEmbabelのプランナーと共通していますが、Terraformが扱う対象はインフラのリソース状態で、EmbabelはLLM呼び出しを含むタスクの実行順序です。つまりEmbabelは「AI処理版のplan/apply」に近い発想を持ち込んでいると考えると位置づけやすくなります。
Spring AIやLangChain4jとの使い分けは、処理時間とステップ数で判断できます。数秒で終わる単発の応答生成やRAG（検索拡張生成）パイプラインならSpring AIやLangChain4jで十分です。数分単位で複数ステップを実行し、途中で失敗を検知して再計画する必要があるなら、Embabelのようなプランニング層が有効な選択肢になります。
本番導入前に確認すべきポイント
Embabelは2026年に登場したばかりのフレームワークです。まずpom.xmlやbuild.gradleの依存バージョンを固定し、GitHubリポジトリのリリースノートで安定版かどうかを確認してください。破壊的変更が頻発する初期段階のOSSは、SemVer（セマンティックバージョニング）のメジャーバージョンが0系かどうかで判断材料になります。
オブザーバビリティ（システム内部の状態を外部から観測できる仕組み）の観点では、@Actionの実行ログとプランナーの再計画イベントを構造化ログとして出力できるか確認が必要です。既存のOpenTelemetry（分散トレーシングの標準規格）計装がSpring AI層でどこまで効くか、Embabelのオーケストレーション層でスパンが分断されないかは事前に検証しておく価値があります。
SLO（Service Level Objective、サービスレベル目標）設計では、LLM呼び出しを含むアクションのレイテンシがばらつきやすい点に注意が必要です。単純なAPIのp99レイテンシとは違い、プランナーの再計画回数によって処理時間が伸びる可能性があります。再計画の上限回数やタイムアウト値を明示的に設定し、それをSLOの分母から除外するか、別カテゴリのSLIとして扱うかを事前に決めておくと運用が安定します。
コスト最適化の観点では、@Actionごとに異なるLLMを割り当てられる設計（withLlmByRoleのような呼び出し）が用意されている点が重要です。下書き作成には安価なモデル、最終レビューには高精度なモデルというように役割ごとにモデルを使い分けることで、無条件に高性能モデルを使い続けるより実行コストを抑えられます。
まとめ
Embabelは、LLM呼び出しを中心に据えるチャットボット型の設計から一歩進み、GOAPによる決定的な計画立案とLLMによる非決定的な処理を分離した点が特徴です。監査性や再現性が求められる企業向けJavaシステムでは、この分離自体が可用性設計上の利点になります。
導入を検討するなら、まずGitHubのリポジトリでバージョンとメジャーリリースの有無を確認してください。次に、既存のSpring AI資産をどこまで流用でき、どこからEmbabelのオーケストレーション層に置き換えるかを小さなPoC（概念実証）で切り分けるのが現実的です。
再計画ループのタイムアウト設定とログ出力の粒度は、本番投入前に必ず検証しておきたいポイントです。SLOやコスト試算に反映させることで、既存のマイクロサービス運用の枠組みにAIエージェントを無理なく組み込めるはずです。