こんにちは、ログラスでCTOをしております、いとひろ（@itohiro73）です。去年までは半年に1回まわってきたTech Blog Sprintが、今回はもう前回書いた記事から10ヶ月も経つということで、チーム規模の成長ぶりに驚く毎日です。
さて、ログラスは先日「Loglass AI Agents」構想を発表しました。ログラス代表布川の動画にもあるように、私たちは今、SaaSの価値を従来の形から変容させていく必要性を感じています。これまでの定量的なデータに基づいた決定論的な従来型のSaaSシステムにとどまらず、非定型なデータや不確実性の高い情報に基づいた非決定論的なタスクをAI Agentを通じて実現し、より良い意思決定に貢献するようなビジネスモデルをいかに構築していくか。私たちは今、その激動の時代の真っ只中にいます。
AIエージェントは銀の弾丸か？
この記事を読んでいるエンジニアの皆さんの中には、すでにClaude CodeやCodex、Cursor、DevinといったコーディングAIエージェントを使いこなしている方は多いのではないでしょうか？これらのツールは、時に驚くほど素晴らしいアウトプットを出してくれますが、一方で「あれ、最近出力が微妙だな」と感じることもあるかと思います。コーディングエージェントの強力さに感動しつつも、常に期待された出力が実現できるわけでもないなかで、どのように品質を担保すべきか、そんな悩みを持つエンジニアの皆さんは多いのではないでしょうか。
AIエージェントは、非常に鮮やかに複雑なタスクをこなすように見えます。そして、その振る舞いからAIはなんでもできてしまう魔法の箱のように感じられるかもしれません。しかし、その華やかな動きの裏には、現実のビジネスアプリケーションに応用する上での大きな課題が隠されています。
それが、決定論的な振る舞いと非決定論的な振る舞いの違いです。
従来の業務アプリケーションやB2B SaaSでは、基本的に同じ入力に対しては同じ出力が返されるといった、決定論的な振る舞いをします。この性質は、エンタープライズレベルの業務アプリケーションが重要視する信頼性や一貫性を担保する上で非常に重要なものです。例えば、帳票をPDFで出力する機能は、何千回実行しても同じフォーマットで、同じデータを含むPDFを生成します。給与計算のアプリケーションであれば、同じ入力条件に対しては何千回実行したとしても必ず同じ計算結果を期待します。この信頼性こそが、私たちが業務に安心してシステムを利用できる理由です。
一方で、多くのAIエージェントは、LLMの持つ柔軟性と創造性に依存しています。LLMは、人間のように状況を理解し、多様なタスクをこなすことができますが、その振る舞いは非決定論的です。同じプロンプトを与えても、毎回異なる出力が返ってくることがあり、ビジネスに不可欠な予測可能性や監査可能性を損なう可能性があります。このギャップこそが、AIエージェントを実用的なビジネスアプリケーションへと進化させる上での最大の障壁となる可能性があると私は考えています。
OSS AIエージェントフレームワークEmbabelの紹介
上記で挙げたような課題を解決できる可能性を持ったフレームワークとして、Springフレームワークの生みの親であるRod Johnsonが開発・公開しているOSS AIエージェントフレームワークであるEmbabelを紹介したいと思います。
EmbabelはKotlinで書かれているAIエージェントフレームワークで、JVM環境で動作します。このフレームワークの基本思想としては、以下のように述べられています。
Embabel aims to help unlock the full business value of Gen AI, by giving developers the framework to make it safe and dependable.
日本語に翻訳すると以下のようになります。
Embabelは、開発者がGen AIを安全かつ信頼性の高いものにするためのフレームワークを提供することで、Gen AIのビジネス価値を最大限に引き出すことを目指しています。
記事の冒頭で述べた問題意識に照らし合わせると、ビジネスのあらゆる業務は、その性質に応じて「決定論的」から「非決定論的」まで、連続的なグラデーションで捉えることができます。
- 純粋な決定論的業務: 給与計算や在庫管理など、厳格なルールに基づく一貫性が求められる業務。
- 決定論的要素と非決定論的要素が混在する業務: 顧客問い合わせ対応や旅程計画など、定型的な情報検索やワークフロー（決定論的）と、柔軟で創造的な対応（非決定論的）が組み合わさる業務。
- 純粋な非決定論的業務: マーケティングのコピーライティングや新規事業のアイデア出しなど、創造性や定性的な判断が最も重要となる業務。
AIエージェントを開発する際において、このグラデーション全体に対応するのはなかなか困難です。しかし、Embabel は、特に「決定論的要素と非決定論的要素が混在する業務」を解決するための、非常にユニークなアプローチを提供します。私がEmbabelがこの課題を解決できるのではないかと考える理由は、Embabelがネイティブにサポートする2つの主要な技術的特徴にあります。
-
非LLMアルゴリズムGOAPによる決定論的な計画ステップ
多くのエージェントフレームワークがLLMにすべてを任せるのに対し、Embabelはタスク実行前にGOAP (Goal Oriented Action Planning) という、LLMに依存しないアルゴリズムを用いて計画を策定します 。この計画プロセスは、エージェントの行動を常に予測可能で、説明可能なものにします 。例えば、EmbabelのサンプルAIエージェントとして実装されている「Triper」の例がわかりやすいです。旅程を生成するAIエージェントで、LLM単体で同様の機能を実現しようとすると、不正確なURLの生成やツールの不正確な使用といった問題が生じうるという課題があります。一方、Embabelの決定論的プランニングを用いることで、旅程の各ステップ（例：地点情報の検索、ホテル検索）を明確に分け、Google MapsのURL生成のような決定論的タスクは、LLMに任せず、あらかじめ組み込まれたコードで確実に実行させることができます。これにより、信頼性が求められる業務フローを堅牢に制御しつつ、LLMは創造的なタスクにフォーカスするようにフレームワーク内でコントロールすることができるのです。 -
ドメインモデルと型安全性（DICE）
AIエージェント開発では、プロンプトの入力や出力が型のないマップ形式で堅牢性のない方式になりがちでした 。Embabelはこれを解決するため、KotlinのデータクラスやJavaのレコードといった厳格な型を持つドメインモデルの利用を奨励します 。このアプローチは、LLMとのやり取りを構造化し、型安全性を確保します 。この設計思想は、Embabelが提唱するDICE（Domain-Integrated Context Engineering）という概念に直結します 。DICEは、単なるプロンプトエンジニアリングではなく、既存のビジネスドメインの知識やデータモデルをAIのコンテキストに統合します。例えば、顧客問い合わせ対応のエージェントは、テキストをパースして顧客IDや注文番号といった情報を抽出し、それをCustomerやOrderといった型安全なドメインオブジェクトにマッピングします。これにより、LLMは単なるテキストではなく、ユビキタス言語で会話し、既存のシステムやデータと安全かつスムーズに連携できるようになります。このアプローチでは、従来のソフトウェア開発で培われたリポジトリパターンやイベントソーシングといった概念をAIエージェントの「記憶」として活用することも可能にします。
Embabelの差別化ポイント
LLMの発達に伴い、AIエージェントの開発フレームワークはさまざまな言語や環境で登場してきています。Embabelの立ち位置は、これら他のAIエージェントフレームワークと比較するとより明確になります。
-
Mastra (TypeScript):
- https://mastra.ai/
- TypeScriptの強みである型安全性を活かし、ウェブ開発者にとって馴染みのある環境でエージェントを開発できることを目指しています。ワークフローグラフや評価機能など、開発の生産性を高めることに焦点を当てています。
-
KOOG (Kotlin):
- https://github.com/JetBrains/koog
- Embabelと同じくKotlin製で、JVMエコシステムとの親和性を重視しています。Kotlin DSLによる記述の簡潔さを追求し、既存のエンタープライズアプリケーションへの統合を容易にすることを目標としています。
これらのフレームワークがそれぞれ異なるアプローチでAIエージェント開発の課題を解決しようとしている一方で、Embabelは先に挙げた「決定論的な計画アルゴリズム」と「ドメインモデルの深い統合」を通じて、根本的な「エンタープライズグレードの信頼性の獲得」という課題に答えることを目指していると言えます。
おわりに
ここ数年における生成AIの驚異的な進化により、AIエージェントを軸とした新たなプロダクト開発の世界観が台頭しつつあります。しかし、その開発手法はまだ確立されておらず、私たちは依然として黎明期にいると言えるでしょう。AIエージェントをエンタープライズグレードのアプリケーションへと進化させるためには、従来の決定論的システムと、AIの持つ非決定論的AIをいかに融合させるか、その接合点の設計こそが今後のAIエージェント開発における最も重要な課題となるのではないか、というのが私の持っている仮説です。
今回紹介したEmbabelは、LLMの持つ非決定論的な創造性を生かしつつ、ビジネスアプリケーションに不可欠な決定論的な信頼性を確保するための、明確なフレームワークを提供してくれます。このようなフレームワークの活用により、既存の業務アプリケーションやBtoB SaaSの延長線上ではない、全く新しい「AIネイティブなプロダクト」を創造するための鍵となるものなのではないかと考えています。
今回はEmbabelの主要な技術的特性について解説してきましたが、次回はより具体的なサンプルAIエージェントをEmbabelを使って実装してみることによって、その特徴を深掘りしてみたいと思います。（次にLoglass Tech Blog Sprintが回ってくるのは1年後とかになりそうなので、普通にZenn記事を書くかと思います😄）
お楽しみに！
参考リンク
Embabel: https://github.com/embabel
The Embabel Vision: https://medium.com/@springrod/the-embabel-vision-967654f13793
AI for your Gen AI: How and Why Embabel Plans: https://medium.com/@springrod/ai-for-your-gen-ai-how-and-why-embabel-plans-3930244218f6
Context Engineering Needs Domain Understanding: https://medium.com/@springrod/context-engineering-needs-domain-understanding-b4387e8e4bf8
Tripper: https://github.com/embabel/tripper
Discussion