JavaでAIエージェントを構築するOSS「Embabel」の仕組み

Java や Kotlin で動いている業務システムに AI エージェント機能を組み込みたい。そう考えたときに最初にぶつかるのが、「JVM 側で何を選べばいいのか分からない」という壁です。エージェントフレームワークの情報は Python 中心で、日本語の比較記事も多くありません。

Spring AI や LangChain4j については情報が増えてきました。しかし、これらを触ってみて次に手が止まるのは「LLM 呼び出しをどう並べるか」という一段上のレイヤーです。ステップの順序、失敗時のリトライ、条件分岐。この部分の設計は各プロジェクトの実装に委ねられており、気づけばエージェントの制御ロジックが巨大な分岐と状態管理コードに膨らんでいく、という話は珍しくありません。

Embabel Agent Framework（以下 Embabel）は、この領域に対して異なるアプローチを取ります。開発者が実行順序を書くのではなく、「どんなアクションがあるか」「どんなゴールを達成したいか」を宣言し、実行順序はプランナーが動的に組み立てるという設計です。ゲーム AI で使われてきた GOAP（Goal Oriented Action Planning）というアルゴリズムを既定のプランナーとして採用しています。

本記事では、Embabel の中核概念、GOAP による動的プランニングが従来の実装とどう違うか、Spring エコシステムとの統合、そして LangChain4j・Spring AI・ADK for Java との違いを整理します。目的は「Embabel を自プロジェクトに採用すべきか」を読者が自分で判断できる材料を揃えることです。

なお本記事は、公開されている README・公式ユーザーガイド・公式サイト、および GitHub API から取得したリポジトリメタデータを読み解いて整理した内容です。動作環境の構築や実行による確認は行っていません。数値やバージョンは 2026 年 8 月 29 日時点のものです。

Embabelとは｜JVM向けのAIエージェントフレームワーク

リポジトリの基本情報

Embabel は、JVM 上でエージェント的なフローを記述するためのフレームワークです。リポジトリの説明文は「Agent framework for the JVM. Pronounced Em-BAY-bel」で、読み方は「エムベイベル」となります。

ソースは embabel/embabel-agent で公開されています。アーカイブ済みリポジトリでもフォークリポジトリでもなく、最終更新は 2026 年 8 月 28 日と、日次に近い頻度で更新が続いている状態です。

README には「Written in Kotlin but offers a natural usage model from Java.」と記載されており、実装言語は Kotlin ですが Java からも自然に扱えることが明示されています。言語構成も Kotlin が約 988 万バイト、Java が約 151 万バイトと、Java コードも相応に含まれています。

「JVMネイティブ」を掲げる背景

Embabel が「JVM 向け」を前面に出す理由は、Embabel 公式サイトの主張に表れています。Python は機械学習の実験には強いものの、本番環境でのスケーラビリティに課題がある。そのギャップを JVM の成熟したツールチェーンと型システムで埋める、という位置づけです。サイトのキャッチコピーは「As modern as Kotlin, as proven as Java」で、強い型付け・成熟したツール・堅牢でスケーラブルなシステムの実績を訴求しています。

README にも同じ発想が現れています。エージェントを本番投入するうえで隣接する重要な資産は LLM そのものではなく、すでに稼働している既存のコードとインフラである、という主張です。これは「新しいエージェント基盤をゼロから立ち上げる」のではなく、「既存の Spring アプリケーションを Gen AI 化する」という導入シナリオを想定していることを意味します。

もう一つ押さえておきたい背景として、README には「From the creator of Spring.」と明記されています。Spring Framework の作者である Rod Johnson 氏が立ち上げたプロジェクトであり、後述する Spring エコシステムとの密結合な設計は、この出自を反映したものです。

Embabelの中核概念：Action・Goal・Condition・ドメインモデル

5つの概念と、それぞれがコード上で何に対応するか

Embabel を理解する最短ルートは、README の Key Concepts に挙げられた 5 つの概念を、Java / Kotlin エンジニアの語彙に置き換えることです。

ここで最も重要なのは Plan の行です。従来のエージェント実装では、開発者が「A を実行して、その結果が X なら B、そうでなければ C」という実行順序をコードで書きます。Embabel ではこの実行順序を書きません。アクションの型シグネチャとゴールの宣言から、プランナーがアクション列を組み立てます。しかも各アクションの完了後に条件が再評価され、必要なら計画を組み直します。README はこれを実質的な OODA ループ（観察・状況判断・意思決定・行動のサイクル）と表現しています。

開発者が条件を直接書かなくてよい理由

「条件を宣言するのが面倒そうだ」と感じた方は、README の注記を確認しておくとよいでしょう。アプリケーション開発者が通常これらの概念を直接扱う必要はなく、多くの条件はコード上のデータフローから導出され、事前条件・事後条件はシステムが推論する、と記載されています。

具体的には、UserInput を引数に取り StarPerson を返すアクションがあれば、「UserInput が揃っていること」が事前条件、「StarPerson が得られること」が事後条件として自動的に導かれます。型がそのままフローの接続情報になる設計です。GOAP のような計画アルゴリズムを使うと聞くと、AI プランニング固有の記述が増えそうに思えますが、開発者が書くのは型付きのメソッドであり、プランニング用のメタデータを別途書き並べる作業は前提になっていません。

この設計の副作用として、拡張のコストが下がります。README は「動的プランニングにより、ドメインオブジェクト・アクション・ゴール・条件を追加するだけで能力を拡張できる」と説明しています。有限状態機械（FSM）の定義を書き換えたり、既存の分岐コードに手を入れたりせずに、新しいアクションを追加するだけでプランナーがそれを候補に含めるようになる、という主張です。

BlackboardとDICE

Embabel Agent Framework User Guide には、README には出てこない 2 つの用語が定義されています。採用検討時に公式ドキュメントを読み進めるうえで前提となる語なので、ここで整理しておきます。

• Blackboard: プロセスの状態と各アクションの実行結果を保持する共有メモリです。アクション間のデータ受け渡しはこの共有領域を介して行われ、型駆動のデータフロー自動オーケストレーションを支えています。ブラックボードモデル自体は AI 分野で古くからあるアーキテクチャパターンで、複数の処理主体が共有の作業領域を読み書きしながら問題を解いていく構造を指します。
• DICE（Domain-Integrated Context Engineering）: 型付きドメインオブジェクトによって LLM の入出力を構造化する、という考え方を指す用語です。プロンプトを文字列と連想配列で組み立てるのではなく、ドメイン型を通じて入出力を定義することで、リファクタリング支援や静的検査を効かせる狙いがあります。README の「No more magic maps.」という表現は同じ思想を端的に言い表したものです。

公式ガイドではアーキテクチャが階層で示されており、API 層（アノテーション）、プロセス管理層（AgentProcess / SimpleAgentProcess / ConcurrentAgentProcess）、計画エンジン（A* GOAP プランナー）、ツール層（Tool / ToolGroup / McpToolFactory / RAG 統合）、LLM 統合層（OperationContext.ai() / PromptRunner）、Spring 統合層（@EmbabelComponent・DI・AOP）という構成になっています。どのレイヤーに手を入れることになるのかを把握しておくと、学習コストの見積もりがしやすくなります。

GOAPによる動的プランニングが従来のAIエージェント実装と異なる点

FSM・逐次実行とプランニングの違い

Embabel が他フレームワークとの差別化点として最初に挙げているのが、プランニングの高度さです。README は「有限状態機械（FSM）や逐次実行を超えて、非 LLM の AI アルゴリズムによる真のプランニング段階を導入する」と説明しています。

違いを整理すると次のようになります。

README は「既知のステップを新しい順序で組み合わせ、プログラムされていないタスクを実行できる」と述べており、並列化などの実行時挙動についてもプランナーが判断すると記載しています。公式ガイドによれば、既定のプランナーは各アクション実行後に自動で再計画を行い、A* アルゴリズムで最適なアクション順序を探索します。動的な環境への適応と、失敗からの回復をこの再計画で実現する設計です。

一方で、この性質は裏返せば「何が実行されるかを事前に完全に確定できない」ことを意味します。監査要件が厳しい業務や、処理手順そのものが仕様として固定されている領域では、動的プランニングは利点ではなく制御しづらさとして働く可能性があります。採用判断ではこの点を最初に見極める価値があります。

GOAPとUtility AIの使い分け

既定のプランニングアルゴリズムは GOAP（Goal Oriented Action Planning）です。ゲーム AI の分野で普及した計画アルゴリズムで、世界の現在状態とゴールに基づいて動的にアクションを選択します。

README によれば、プランニング手法はプラガブルで、Utility AI も標準サポートされています。両者の違いは選択の基準にあります。

• GOAP: 厳密な事前条件・事後条件を満たすアクションを A* で探索して最短経路を求めます。手順がある程度定まっており、達成条件が明確なタスクに向きます
• Utility AI: 動的な効用スコアでアクションを選びます。厳密な条件充足ではなくスコアの高低で判断するため、探索的・オープンエンドなタスクに向きます

Goals / actions / plans という概念自体は GOAP に依存していないため、プランナーを差し替えても記述したアクションはそのまま使える設計になっています。

実行モード Focused / Closed / Open と決定性のトレードオフ

AgentPlatform には 3 つの実行モードがあり、どこまで動的にするかを選べます。

README は Open モードについて「Open mode is the most powerful, but least deterministic.」と明記しています。開発者が想定していなかった経路を発見したり、複数プロバイダの機能を組み合わせたりすることがある一方、どのゴールも妥当と確信できなければ実行しないという安全側の挙動も持ちます。ゴール選択をさらに制限したい場合は GoalChoiceApprover インタフェースで制御できます。

なお Open モードであっても、実行される個々のステップは事前に定義済みのアクションに限られます。ステップ自体が LLM 変換である場合、プロンプトはユーザーコードが制御しますが結果は非決定的になる、という整理です。「どこまで動的にするか」をモードで段階的に選べる点は、いきなり Open モードから始めなくてよいという意味で導入のハードルを下げます。

将来的には実行中のプロセスにゴールやエージェントを追加する Evolving モードや、Embabel 同士および他社エージェントフレームワークとのフェデレーションも構想として README に記載されています。これらは現時点では実装済み機能ではないため、採用判断の材料としては切り離して考える必要があります。

Java・KotlinでのAIエージェント実装コードの書き味

アノテーションベースの記述

Embabel には 2 つの記述スタイルがあります。ひとつは @Agent / @Goal / @Condition / @Action / @AchievesGoal を使うアノテーションベースの記述で、README は Spring MVC に似た書き味だと説明しています。もうひとつは Kotlin DSL（agent { ... } / action { ... } ブロック）です。

README の「Show Me The Code」には、星座から関連ニュースを探して文章を書く StarNewsFinder というサンプルが Java と Kotlin の両方で掲載されています。Java 版からアクション定義の部分を抜粋します。

    @Action
    public StarPerson extractStarPerson(UserInput userInput, Ai ai) {
        return ai
                .withLlm(OpenAiModels.GPT_41)
                .createObjectIfPossible(
                        """
                                Create a person from this user input, extracting their name and star sign:
                                %s""".formatted(userInput.getContent()),
                        StarPerson.class
                );
    }

    @Action
    public Horoscope retrieveHoroscope(StarPerson starPerson) {
        return new Horoscope(horoscopeService.dailyHoroscope(starPerson.sign()));
    }

（引用元: README の Show Me The Code より extractStarPerson / retrieveHoroscope アクションの抜粋）

注目すべき点が 2 つあります。1 つ目は、extractStarPerson が UserInput を受け取って StarPerson を返し、retrieveHoroscope が StarPerson を受け取って Horoscope を返す、という型の連鎖です。この型情報がそのままデータフローになり、プランナーが実行順序を決める材料になります。

2 つ目は、retrieveHoroscope が LLM を一切使っていないことです。既存の HoroscopeService（Spring がコンストラクタ経由で注入します）を呼ぶだけの通常のコードが、LLM を使うアクションと同じ土俵に並んでいます。既存のサービス層をそのままアクションとして組み込める設計であることが、このコードから読み取れます。

終端アクションには @AchievesGoal を付けます。

    // The @AchievesGoal annotation indicates that completing this action
    // achieves the given goal, so the agent can be complete
    @AchievesGoal(
            description = "Write an amusing writeup for the target person based on their horoscope and current news stories",
            export = @Export(
                    remote = true,
                    name = "starNewsWriteupJava",
                    startingInputTypes = {StarPerson.class, UserInput.class})
    )
    @Action

（引用元: README の Show Me The Code より終端アクション writeup に付与されたアノテーションの抜粋）

export = @Export(remote = true, ...) によって、そのゴールをリモートから呼び出せる形で公開する指定も同じアノテーション内で行えます。

ツールを必要とするアクションには @Action(toolGroups = {CoreToolGroups.WEB}) のようにツールグループを宣言します。ツールの要求がアクションのメタデータとして表現されるため、どのステップが外部アクセスを伴うかがシグネチャの近くで把握できます。

ドメイン型は Java の record（Kotlin では data class）で定義し、@JsonClassDescription / @JsonPropertyDescription で LLM 向けの説明を付与します。JSON Schema の生成には victools/jsonschema-generator の Jackson モジュールが使われています。プロンプトに埋める型の説明が、ドメインクラスの定義と同じ場所に置かれる構造です。

アクション単位でLLMを選ぶ設計

Embabel の設計思想として README が挙げているのが、複数の LLM を混在させる前提です。用途ごとに最適で安価なモデルを選び、必要ならローカルモデルを部分的に使う、という運用を想定しています。

これはアクション単位で指定します。先ほど抜粋した extractStarPerson では ai.withLlm(OpenAiModels.GPT_41) と特定モデルを指定していましたが、既定モデルを使う場合は ai.withDefaultLlm() を呼びます。同じサンプルの中でも、文章生成を担う終端アクション writeup では、次のように別のモデルと温度パラメータを組み合わせています。

        var llm = LlmOptions
                .withModel(OpenAiModels.GPT_41_MINI)
                // High temperature for creativity
                .withTemperature(0.9);

（引用元: README の Show Me The Code より writeup アクション内の抜粋）

構造化データの抽出には安価な小型モデル、創造性が要る文章生成には温度を上げたモデル、といった使い分けをアクション単位で書き分けられます。エージェントの実行コストが読みにくい問題に対して、どのステップにどのモデルを割り当てるかをコード上で明示できる点は、コスト見積もりの観点で扱いやすい構造です。

ユニットテストでプロンプトを確かめる

README はテスト容易性を設計当初からの方針として挙げており、エージェントのユニットテスト例を掲載しています。FakeOperationContext を使い、LLM を呼ばずにプロンプトの内容とツールグループの付与状況を確かめる例です。

        starNewsFinder.writeup(starPerson, relevantNewsStories, horoscope, context);

        var prompt = context.getLlmInvocations().getFirst().getPrompt();
        var toolGroups = context.getLlmInvocations().getFirst().getInteraction().getToolGroups();


        assertTrue(prompt.contains(starPerson.getName()));
        assertTrue(prompt.contains(starPerson.sign()));
        assertTrue(prompt.contains(cockatoos.getSummary()));
        assertTrue(prompt.contains(emus.getSummary()));

        assertTrue(toolGroups.isEmpty(), "The LLM should not have been given any tool groups");

（引用元: README の Show Me The Code よりユニットテスト例の抜粋）

LLM の応答は非決定的なので出力そのものを確かめるのは困難ですが、「必要な情報がプロンプトに含まれているか」「意図しないツールが渡されていないか」は決定的にテストできます。エージェントの品質保証をどう組み立てるかは採用時の懸念になりやすいポイントであり、この粒度のテストが標準で書ける点は判断材料になります。

Spring Boot・MCP・A2A・可観測性とのエコシステム統合

MCPサーバとして公開する／MCPサーバを利用する

Embabel は MCP（Model Context Protocol）の両方向に対応しています。

公開側では、Embabel のエージェントプラットフォーム自体を SSE 経由の MCP サーバとして動かし、Claude Desktop などのクライアントから利用できます。README には claude_desktop_config.yml の設定例と、MCP Inspector での確認手順が記載されています。

利用側では、Spring AI の MCP クライアント設定（spring.ai.mcp.client）を通じて外部の MCP サーバに接続します。stdio 接続（Docker と socat の組み合わせ）と、リモートの Streamable HTTP 接続の両方に対応しています。加えて Docker Desktop（>4.43.2 が前提）の MCP カタログとの連携手順も用意されており、Brave Search・Fetch・Puppeteer・Wikipedia などのツールを有効化できます。

MCP クライアント部分が Spring AI の実装をそのまま使う構成である点は、後述する「Embabel と Spring AI の関係」を理解するうえでの具体例にもなっています。

A2Aによる他エージェントとの相互接続

Google が提唱する A2A（Agent2Agent）プロトコルにも対応しています。a2a という Spring プロファイルを有効にすると A2A サーバが起動する構成で、利用には GOOGLE_STUDIO_API_KEY が必要です。

後述するモジュール成熟度区分では、A2A は Incubating に分類されています。他社のエージェント基盤と相互接続する構想が実装として進みつつある段階、という位置づけで捉えるのが妥当です。

可観測性（何が自動でトレースされるか）

本番投入の可否を判断するうえで具体的な材料になるのが可観測性まわりです。embabel-agent-starter-observability を依存に追加し、OpenTelemetry のエクスポータ（Zipkin / Langfuse）を設定すると、アプリケーションコードを変更せずにトレースとメトリクスを取得できると README は説明しています。

自動で計測される項目として挙げられているのは次のとおりです。

• エージェントのライフサイクル
• 各アクションの子スパン
• LLM 呼び出しとトークン使用量
• ツール呼び出し
• プランニング・再プランニングの反復
• 状態遷移

独自のメソッドをスパン化したい場合は @Tracked アノテーションを使います。動的プランニングは「なぜこの順序で実行されたか」が事後に分かりにくくなりがちですが、プランニングと再プランニングの反復がトレース対象に含まれている点は、この懸念に対する回答になっています。既存の分散トレース基盤を持っているチームであれば、そこに載せられるかどうかを具体的に検討できます。

モデル接続の選択肢も広く用意されています。ローカル実行向けには Ollama・Docker Models・LMStudio 用のスターター、クラウド側では OCI Generative AI 用スターター（embabel-agent-starter-oci-genai）があります。任意の Spring AI ChatModel があれば Llm 型の Spring Bean を定義してカスタム LLM を追加できる、という拡張ポイントも用意されています。

環境変数の必須項目は OPENAI_API_KEY のみで、任意で ANTHROPIC_API_KEY（コーディングエージェント機能に必要）などを設定します。README には、Spring AI 流の SPRING_AI_OPENAI_API_KEY ではなく一般的な命名を採用している旨がわざわざ明記されています。既存の資格情報管理の仕組みに合わせやすいようにという配慮と読めます。

Embabelの導入手順とプロジェクトの成熟度

前提バージョンと依存関係の追加（MavenとGradleの差）

公式ガイドによれば Java 21 以上が必須で、Spring Boot スターター依存を前提とした設計になっています。Java 17 で稼働しているプロジェクトでは、まずランタイムのバージョンアップが前提条件になります。

Maven の場合、v0.2.0 以降は Maven Central から取得できるため追加のリポジトリ設定は不要です。

<dependency>
    <groupId>com.embabel.agent</groupId>
    <artifactId>embabel-agent-starter</artifactId>
    <version>${embabel-agent.version}</version>
</dependency>

（引用元: README の Maven セクション。アーティファクトは Maven Central の embabel-agent-api でも確認できます）

一方 Gradle の場合は、Spring Milestones リポジトリを明示する必要があります。

repositories {
    mavenCentral()
    maven {
        name = "Spring Milestones"
        url = uri("https://repo.spring.io/milestone")
    }
}

（引用元: README の Gradle セクション）

この差が生まれる理由も README に説明があります。Embabel の BOM が実験的な Spring コンポーネント（mcp-bom）に推移的に依存しており、それが Maven Central にない一方、Gradle は親 POM や BOM のリポジトリ設定を継承しないためです。Gradle 側で依存解決エラーに遭遇した場合の当たりを付けやすい情報なので、導入前に把握しておく価値があります。

なお README の Quick Start に掲載されている依存バージョンの記述例には旧版の番号（0.3.0）が残っています。最新版は GitHub Releases の v1.5.1（2026-08-24 公開）なので、バージョン指定はリリース一覧側を確認するのが確実です。

プロジェクトの雛形は、project-creator ツールを使う方法と、Java / Kotlin のテンプレートリポジトリで「Use this template」を使う方法が案内されています。テストについては、mvn test で走るユニットテストは外部接続を必要とせず、統合テストは mvn -Pintegration-tests test と別プロファイルに分離されています。資格情報がない環境では該当テストがスキップされる設計です。CI での扱いを検討する際の前提として押さえておくとよいでしょう。

リリース状況とモジュールごとの成熟度区分

メンテナンス状況を測る材料を、公開情報から整理すると次のようになります。

1.0 到達から約 1 か月で 1.5.1 まで進んでおり、開発速度は速い状態です。一方で、リポジトリ作成が 2025 年 4 月と若く、1.0 以降のマイナーバージョンが短期間で刻まれている点は、API の安定性を慎重に見る材料にもなります。

ここで重要なのが、公式ガイドがモジュール単位で成熟度を 3 区分している点です。

「1.0 に到達しているから全機能が安定」ではなく、必要な機能がどの区分にあるかを確認する必要があります。たとえば A2A による他エージェント連携や DICE 関連機能を導入の主目的にする場合、それらは Incubating 区分であるという前提で計画を立てることになります。逆に、アノテーション API・ドメイン型・MCP 連携という中核部分は安定区分に入っているため、標準的な使い方の範囲であれば見通しは立てやすい構成です。

なお LLM プロバイダ用スターターとしては、openai / anthropic / gemini / mistral-ai / ollama / bedrock / deepseek / openai-custom（OpenRouter 等）が安定として挙げられています。

補足として、README にはプロジェクト自身が AI エージェントで開発工程を加速する「Dog Food Policy」が掲げられています。同時に「開発者が最終的な制御権を持ち、エージェントの成果をコミット／マージする開発者がコーディング標準への適合に責任を負う」とも明記されており、生成物の扱いに関する方針が公開されています。

類似OSSとの違い：LangChain4j・Spring AI・ADK for Java

比較テーブル（実測値ベース）

JVM 上で LLM アプリケーションやエージェントを構築する選択肢として比較対象になりやすい 3 つのプロジェクトと並べます。数値はいずれも GitHub API から 2026 年 8 月 29 日に取得した値です。

規模だけを見れば LangChain4j と Spring AI が先行しています。ただし、これらは Embabel と同じ責務を担っているわけではありません。

Spring AIとの関係は「競合」ではなく「階層の違い」

初見で最も誤解しやすく、かつ採用判断に直結するのがここです。README には「Why not just Spring AI?」という項目があり、その回答として、Spring AI は良いものであり Embabel はその上に構築されている、と明言されています。競合関係ではありません。

README が示すアナロジーは分かりやすいものです。Spring AI が Servlet API に相当し、Embabel が Spring MVC に相当する、という位置づけです。Servlet API を直接書いても Web アプリケーションは作れますが、多くのアプリケーションはより高水準の Spring MVC で書くほうが適切である。同じ関係が LLM 統合層とエージェント記述層の間にもある、という主張です。

実装面でもこの関係が現れています。前述のとおり MCP クライアント機能は Spring AI の実装（spring.ai.mcp.client）を利用しており、カスタム LLM の追加も Spring AI の ChatModel を Llm 型の Bean として定義する形で行います。したがって「Spring AI と Embabel のどちらを選ぶか」という問いの立て方は、多くの場合そもそも成立しません。適切な問いは「Spring AI の上に自前でフロー制御を書くか、Embabel のプランニング層に載せるか」です。

一方 LangChain4j は立ち位置が異なります。フレームワーク非依存で、Quarkus・Spring Boot・素の Java のいずれからも使え、LLM プロバイダとベクトルストアの統一 API、ツール呼び出し（MCP 含む）、RAG などを幅広く備えています。Spring を採用していない JVM プロジェクトであれば、こちらが現実的な選択肢になります。なお Spring AI と LangChain4j はどちらも 2025 年 5 月に GA 1.0 に到達しており、Boot スターター・ベクトルストア統合・ツール呼び出し・RAG・MCP・チャットメモリといった機能を備えている点は共通しています（出典: LangChain4j vs Spring AI（Level Up Coding））。

ADK for Java は、Google がエージェントの構築・評価・デプロイを一貫して扱うために提供している code-first のツールキットです。Vertex AI など Google のエージェント基盤との親和性が最大の特徴で、そこに寄せた構成を取るかどうかが選定軸になります。

どの状況でどれを選ぶかの判断軸

上記を判断軸として整理すると、確認すべき問いは 2 つに集約できます。

1. Spring / Spring Boot を採用しているか。採用していなければ Embabel は前提から外れ、LangChain4j や ADK for Java が候補になります
2. フロー制御に動的プランニングが要るか。ステップの順序が仕様として固定できるなら、Spring AI や LangChain4j の上に逐次処理を書くほうが構成はシンプルです。ゴールは定義できるが到達経路が状況依存で変わる、あるいはアクションを増やしながら能力を拡張していきたい場合に、Embabel のプランニング層が効いてきます

この 2 つがどちらも「はい」であれば、Embabel は検討する価値のある選択肢です。どちらかが「いいえ」であれば、より薄いレイヤーのライブラリを直接使うほうが妥当な構成になりやすい、という整理になります。

Embabelの採用を検討する際のチェックポイント

ここまでの内容を、採用判断の観点で整理します。

向いているケース

• Spring / Spring Boot の資産が厚く、既存のサービス層やドメインモデルをそのままアクションとして組み込みたい
• ゴールは明確だが到達経路が状況依存で、フローを事前に固定しきれない
• アクション単位で LLM を使い分け、コストと品質のバランスを取りたい
• OpenTelemetry ベースの既存トレース基盤に、エージェントの実行状況を載せたい
• 型安全性とリファクタリング支援を重視し、プロンプトを文字列と連想配列で組み立てる構成を避けたい

慎重に判断すべきケース

• 処理フローが完全に決定的でよく、動的プランニングが要件に対して過剰になる
• Spring / Spring Boot を採用していない（Quarkus や素の Java 環境では LangChain4j 等が候補）
• Java 21 未満で稼働しており、ランタイムのバージョンアップが直近では難しい
• 導入の主目的が Incubating / Experimental 区分のモジュール（A2A、DICE、評価機能、skills 等）にある
• API の安定性を最優先し、1.0 到達から日が浅いプロジェクトの変更追従コストを負担できない

次の一歩

まず動きを把握したい場合は Embabel Agent Examples に例とチュートリアルがまとまっています。自分のプロジェクトの形で確かめたい場合は Java テンプレート または Kotlin テンプレート が出発点になります。API の詳細やモジュール成熟度の最新状況は Embabel Agent Framework User Guide で確認できます。公式サイトにはドキュメントへ自然言語で質問できる機能も用意されています。

Embabel は、JVM の型システムと Spring の運用資産を前提に、エージェントのフロー制御をプランナーに委ねるという設計を取ったフレームワークです。動的プランニングを利点と見るか制御しづらさと見るかは、扱う業務の性質によって分かれます。本記事で整理した判断軸が、その見極めの材料になれば幸いです。

AI エージェントの業務システムへの組み込みや、既存の Java / Spring アプリケーションの Gen AI 対応をご検討中の場合は、お問い合わせフォーム からご相談いただけます。技術選定の段階からのご相談にも対応しています。