Embabel Agent Framework が 1.0 に到達
本文の状態
日本語全文を表示中
詳細モードで約8分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
InfoQ AI/ML
Embabel は Java/Kotlin 開発者向けに、GoAP（目標指向行動計画）を採用した AI エージェント構築フレームワークの 1.0 版を公開し、Spring AI を基盤として動的な計画立案と柔軟なモデル選択を実現する。
AI深層分析を開く2026年8月3日 23:42
AI深層分析
キーポイント
Embabel 1.0 の一般提供開始
Java および Kotlin 開発者向けに、AI エージェントを構築するためのフレームワーク「Embabel」がバージョン 1.0 の一般利用（GA）へ到達した。
GoAP を採用した動的計画機能
事前にスクリプトやグラフを固定するのではなく、目標とアクションの事前条件・効果を定義し、実行時にプランナーが最適な行動シーケンスを検索する GoAP（Goal-Oriented Action Planning）を採用している。
Spring AI 上位層としての設計
Embabel は Spring AI を置き換えるものではなく、その上に構築されたレイヤーであり、Spring MVC が Servlet API の上に成り立つように、エージェントの宣言型定義を可能にする。
柔軟なモデル選択と構成
OpenAI や Anthropic などの主要プロバイダーに加え、ローカル環境もサポートし、個々のアクションや役割（ロール）に対して特定のモデルを割り当てる柔軟な設定が可能である。
柔軟なモデル選択とルーティング
Embabel は Spring AI を継承して多様なプロバイダーやローカル環境をサポートし、開発者は個々のアクションに特定モデルを固定するか、役割エイリアスを通じてコストや能力に応じた動的ルーティングが可能である。
重要な引用
Embabel lets Java and Kotlin developers define agents as typed domain objects (goals, actions, and the conditions that connect them) rather than hand-coding a sequence of prompts and tool calls
An analogy: Spring AI exists at the level of the Servlet API, while Embabel is more like Spring MVC.
If the world changes mid-task (a tool call fails, new information arrives), the planner can reassess and find a new path rather than falling over
The choice isn't made once for the whole agent: a developer can pin an individual action to a specific model, or define role aliases in configuration and have an action reference the role instead of a hard-coded name.
編集コメントを表示
編集コメント
Spring Framework の創始者である Rod Johnson 氏によるこのプロジェクトは、Java エコシステムにおける AI エージェント開発の標準化に向けた重要な一歩となる。従来のプロンプトエンジニアリングや手動ワークフローに依存するアプローチから脱却し、より構造化されたエージェント設計を可能にする点は、大規模な Java アプリケーションを持つ企業にとって特に価値が高い。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Java と Kotlin の開発者が AI エージェントを構築するためのフレームワーク「Embabel」が、1.0 一般公開版に到達しました。Embabel を使えば、開発者はプロンプトやツール呼び出しの手動シーケンスを記述する代わりに、型付きのドメインオブジェクト（ゴール、アクション、そしてそれらを繋ぐ条件）としてエージェントを定義できます。実行時には計画ステップを通じて、現在の状態から目標に到達する方法を導き出します。
この計画ステップは、ビデオゲーム AI で採用されている「Goal-Oriented Action Planning (GOAP)」のアイデアを応用したものです。スクリプトや事前に接続されたグラフに従うのではなく、エージェントには利用可能なアクションのセットが与えられ、それぞれに事前条件と効果が定義されています。プランナーはこの中から目標を満たすアクションのシーケンスを検索します。タスク中に状況が変わった場合（ツール呼び出しが失敗したり、新しい情報が得られたりしても）、プランナーは再評価して新たな経路を見つけ出すため、システムが崩壊したり、事前にその分岐を想定したワークフローが必要になったりするのを防ぎます。
Embabel は、Spring AI（モデルの呼び出し、埋め込みの管理、ツールの呼び出しを行う Spring チーム公式ライブラリ）を置き換えるものではありません。むしろ、その上に構築されたものです。
Embabel は Spring Framework の生みの親である Rod Johnson 氏と共同で開発されました。「Embabel 1.0.0 GA がほぼ完成し、非常に興奮しています」と、Johnson 氏は発表しました。2003 年に Spring や Spring MVC を設立した同氏が、プロジェクトの README で以下のように歴史的な類似点を挙げています。
「例え話をしましょう。Spring AI は Servlet API のレベルに位置しますが、Embabel はより Spring MVC に近い存在です」
生の Servlet でも動作は可能ですが、すべてのアプリケーションが同じ問題（リクエストパラメータの解析、適切なハンドラーへの転送、オブジェクトと HTTP 間のコンバージョンなど）を毎回解決することになります。Spring MVC は Servlet を置き換えたのではなく、その上に位置し、開発者が手動で HttpServletRequest をパースする代わりに、型付きのメソッドシグネチャを書くことを可能にしました。
Embabel も同様の戦略を採用しています。Spring AI がモデルとの通信に必要な基盤（プラムビング）を提供し、Emabel は「目標はこれらであり、それらを達成するための型付きアクションはこれらです」と開発者が宣言するレイヤーを提供します。残りのシーケンス制御はフレームワークが担当します。
Spring AI との階層的な関係は、モデル選択にも反映されています。Embabel は Spring AI を基盤としているため、OpenAI、Anthropic、Gemini、Bedrock、Mistral、DeepSeek など Spring AI がサポートする主要プロバイダーのほとんどを利用可能です。また、Ollama や Docker、あるいは OpenAI 互換の LMStudio エンドポイントを通じて、ローカル環境やセルフホスト型のオプションも利用できます。
モデルの選択はエージェント全体で一度きり行うものではありません。開発者は 個々のアクションを特定のモデルに固定 したり、設定ファイル内で役割エイリアスを定義したりすることが可能です。例えば、推論能力が求められるステップには「最良」モデルを、定型処理には「低コスト」モデルを割り当て、各アクションは具体的なモデル名ではなくこの役割を参照するように設定できます。
これにより、単一のエージェントで複数のモデルを混在させて実行し、コスト、プライバシー要件、あるいは機能面のニーズに応じて各ステップに最適なモデルを自動的にルーティングすることが容易になります。
Embabel の計画機能は、LangChain が構築したグラフ指向のオーケストレーションレイヤーである LangGraph との違いを決定づける要素です。Java チームは、LangChain4j や Spring AI と連携するように設計された Java 版 LangGraph4j を通じて、Embabel を直接使用できます。
LangGraph はエージェントワークフローを有向グラフとして表現します。ノードは関数（LLM の呼び出し、ツールの実行、データベースの照会など）であり、エッジはどのノードを次に実行するかを決定するルーティングロジック（静的または条件付き）です。このプロセスでは共有状態オブジェクトが経路を通じて渡されます。
開発者は事前にそのグラフを定義します。具体的には、どのノードが存在し、どのエッジでそれらが接続され、どのような条件で制御が移動するかを指定します。一方、Embabel のプランナーは異なるアプローチを採用しています。開発者がグラフを手動で結線するのではなく、フレームワークが実行時に利用可能な型付きアクションの中から経路を検索し、開発者が明示的に結線していなかったアクションの組み合わせも可能にします。
Embabel は、GOAP 計画と明示的な状態機械を同じエージェント内で混在させることをサポートしています。これにより、チームは特定のステップにおいて LangGraph 方式のような固定ルーティングを採用することも可能です。
Akka は、アクターモデルを中核に据えた Lightbend 社がメンテナンスするツールキットです。既存の分散システムにおける強みを活かしてアプローチしており、Spring のようなプログラミングモデルの伝統とは一線を画しています。
Akka では、各作業単位（ここではエージェント）は、独自の隔離された状態とメールボックスを持つアクターとして実行されます。また、失敗時にシステム全体を混乱させることなく再起動可能な階層構造によって監視されています。
Akka Agentic Platform は、この仕組みをエージェントに直接適用しています。エージェントの状態や進行中の会話は、プロセスクラッシュ後も生存するアクター内に保持され、クラスター全体に分散させることも可能です。これにより、長時間稼働するエージェントは、再起動後にゼロから再構築したり、複数マシンで動作するようにアーキテクチャを根本から見直したりする必要がありません。
Embabel のアプローチはプログラミングモデルです。「目標」と「型付きアクション」を宣言し、フレームワークが計画を立てます。一方、Akka はインフラストラクチャに近い立場です。アクターランタイムが、その上で動作するエージェントロジックの下で、永続化、フォールトトレランス、分散処理を自動的に処理します。
JetBrains の Koog はこれらとは異なる第三の道を歩んでいます。これはランタイムや宣言的なプログラミングモデルではなく、Kotlin 自体が持つ言語機能を中心に構築されています。
各プロジェクトは、エージェントの構造をどこに置くべきかという点で異なる賭けをしています。Embabel は型システムに、Akka はランタイムに、Koog は言語そのものに賭けているのです。
Spring Boot サービスをすでに運用しているチームにとって、今回のリリースは Embabel を「注目すべきプロジェクト」から「評価対象のツール」へと位置づける転換点となります。プロジェクトの Overview ガイド では、まず最初のゴールと型付きアクションを定義し、その後に計画機能の詳細へと進む手順が解説されています。
著者について
Erik Costlow
Erik Costlow はソフトウェアセキュリティの専門家であり、Java に関する豊富な経験を持っています。現在、Azul の JVM のセキュリティを担当しており、最高速度での稼働を維持しつつ、すべてのユーザーにとってセキュリティをより容易で強力なものにする取り組みを行っています。
Oracle では Java 8 のセキュリティに注力するシニアプロダクトマネージャーとして活躍し、ハッキングが頻発していた時期に参加しました。その後、ゼロデイ脆弱性が約2年間発生しないという状況を経て退社しています。その期間中、企業・商用レベルとコミュニティレベルの両方から Java の詳細を深く学びました。
また、Turbonomic のプロダクトマネジメントチームにおいて、データセンターおよびクラウドのパフォーマンス自動化にも貢献しました。さらに、開発者がカスタムソースコード内の脆弱性を発見し修正するためのツールである「Fortify 静的コード解析器」のプロダクトマネージメントも担当しています。
Packt Publishing では、データ分析、統計学、暗号化に関する複数の開発者向けコースを出版した実績もあります。
原文を表示
Embabel, a framework for building AI agents on the Java, reached its 1.0 general-availability release. Embabel lets Java and Kotlin developers define agents as typed domain objects (goals, actions, and the conditions that connect them) rather than hand-coding a sequence of prompts and tool calls, using a planning step to work out how to get from the current state to a goal at runtime.
That planning step borrows an idea from video game AI called Goal-Oriented Action Planning (GOAP). Instead of following a script or a pre-wired graph, the agent is given a set of available actions, each with preconditions and effects, and a planner searches for a sequence of actions that satisfies the goal. If the world changes mid-task (a tool call fails, new information arrives), the planner can reassess and find a new path rather than falling over or requiring the workflow to have anticipated that branch in advance.
Embabel doesn't replace Spring AI, the Spring team's own library for calling models, managing embeddings, and invoking tools; it's built on top of it. Embabel was co-created by the creator of the Spring Framework: Rod Johnson announced the release with "Embabel 1.0.0 GA nearly ready...excited!" Johnson founded Spring, and with it Spring MVC, in 2003, and the project's README draws a direct parallel to that history: "An analogy: Spring AI exists at the level of the Servlet API, while Embabel is more like Spring MVC." Raw servlets work, but every application ends up re-solving the same problems: parsing request parameters, dispatching to the right handler, converting objects to and from HTTP. Spring MVC didn't replace servlets; it sat on top of them and let developers write a typed method signature instead of parsing a HttpServletRequest by hand. Embabel is making the same bet for agents: Spring AI supplies the plumbing to talk to a model, and Embabel supplies the layer where a developer declares "these are my goals and the typed actions available to reach them," leaving the framework to work out the sequencing.
That same layered relationship with Spring AI carries through to model choice. Because Embabel builds on Spring AI, it inherits support for most of the providers Spring AI does (OpenAI, Anthropic, Gemini, Bedrock, Mistral, DeepSeek), plus local and self-hosted options through Ollama, Docker, or an OpenAI-compatible LMStudio endpoint. The choice isn't made once for the whole agent: a developer can pin an individual action to a specific model, or define role aliases in configuration (a "best" model for the step that needs strong reasoning, a "cheapest" one for routine steps) and have an action reference the role instead of a hard-coded name. That makes it straightforward to run a single agent across a mix of models, routing each step to whichever one fits its cost, privacy, or capability needs.
The planning step itself is what sets Embabel apart from LangGraph, the graph-oriented orchestration layer built by LangChain. Java teams can use it directly through LangGraph4j, a Java port built to work with LangChain4j and Spring AI. LangGraph represents an agent workflow as a directed graph: nodes are functions (an LLM call, a tool invocation, a database lookup) and edges are the routing logic, static or conditional, that decides which node executes next, with a shared state object passed along the way. The developer defines that graph up front: which nodes exist, which edges connect them, and under what conditions control moves between them. Embabel's planner starts from a different point: rather than the developer wiring the graph, the framework searches for a path through the available typed actions at runtime, and can combine actions into sequences the developer never explicitly wired together. Embabel supports mixing GOAP planning with explicit state machines in the same agent, so a team can still drop into LangGraph-style fixed routing for the steps where that's what they want.
Akka, the Lightbend-maintained toolkit built around the actor model, approaches the same problem from existing strength in distributed systems rather than Spring's programming-model tradition. In Akka, each unit of work (here, an agent) runs as an actor with its own isolated state and mailbox, supervised by a hierarchy that can restart it after a failure without disturbing the rest of the system. The Akka Agentic Platform applies that directly to agents: an agent's state and in-flight conversation live in an actor that survives a process crash and can be distributed across a cluster, so a long-running agent doesn't need to be rebuilt from scratch after a restart or re-architected to run across multiple machines. Embabel's pitch is a programming model: declare goals and typed actions, let the framework plan. Akka's is closer to infrastructure: the actor runtime handles persistence, fault tolerance, and distribution underneath whatever agent logic runs on top. JetBrains' Koog takes a third approach, built around Kotlin's own language features rather than a runtime or a declarative programming model. Each is making a different bet on where an agent's structure should live: the type system for Embabel, the runtime for Akka, the language itself for Koog.
For teams already running Spring Boot services, this release is the point where Embabel stops being a project to watch and starts being one to evaluate. The project's "Overview" guide walks through defining a first goal and typed action before getting into planning behavior.
About the Author
Erik Costlow
Erik Costlow is a software security expert with extensive Java experience. He handles the security of Azul's JVMs that operate at peak speed while making security easier and better for all. Erik was the principal product manager in Oracle focused on security of Java 8, joining at the height of hacks and departing after a two-year absence of zero-day vulnerabilities. During that time, he learned the details of Java at both a corporate/commercial and community level. He also assisted Turbonomic's product management team in the data center/cloud performance automation. Erik also lead product management for Fortify static code analyzer, a tool that helps developers find and fix vulnerabilities in custom source code. Erik has also published several developer courses through Packt Publishing on data analysis, statistics, and cryptography.
Show moreShow less
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み