Atmosphere 4.0.70 レビュー: JVM で AI エージェントを本番サービスとして動かすためのランタイム

Atmosphere が埋めるのは「エージェントの実行時」という層

多くのエージェントフレームワークは、モデルの呼び出し方やプロンプトの組み立て方を定義する。Atmosphere が扱うのはその外側で、トークンをどのトランスポートでクライアントまで流すか、ツール呼び出しの直前に何を検査するか、実行をどの単位で観測・再開するかという部分だ。README はこれを「real-time engine for AI agents on the JVM」と表現し、フレームワークそのものではなく、フレームワークの下で動く実行時基盤として位置づけている。

対象読者は、すでに JVM 上でサービスを運用しているチームだ。Spring Boot や Quarkus のアプリケーションがあり、そこにエージェント機能を足したいが、モデルプロバイダを差し替えるたびにエンドポイントを書き直したくない、という状況を想定している。README の比較表では「Swap AI integrations」の行に、単一の AgentRuntime SPI と12のランタイムアダプタ、契約テスト済みの capability flags が挙げられている。

もう一つの軸はガバナンスだ。ポリシーアドミッション、@AgentScope、人間の承認、プラン検証、コスト上限、PII の書き換え、管理者によるキルスイッチが README の表に並ぶ。エージェントを「本番サービスとして振る舞わせる」という言い回しは、この層があることを指している。

ブロードキャスタを中心にしたデータの流れ

README の冒頭説明によれば、トークンは LLM ランタイムからクライアントへ、フィルタ・ゲート・観測が可能なブロードキャスタを通って流れる。つまりパイプラインの中心はブロードキャスタで、WebSocket、SSE、long-polling、gRPC はその出口として扱われる。WebSocket、SSE、long-polling は常時有効なデフォルトで、gRPC も同じパイプラインに乗る。WebTransport over HTTP/3 はオプション扱いで、クラスパスに jetty-http3-server か reactor-netty-http を追加し、開発用証明書を用意する必要があると README は述べている。

ランタイム側は atmosphere-ai の AgentRuntime SPI が受ける。12のアダプタがあり、それぞれの capability flags は契約テストで検証される。ここで重要なのは、アダプタの乗り換えがエンドポイントの書き換えを伴わないという設計意図だ。@Agent を付けたクラスがそのまま動く、という表現が README にある。

オーケストレーションは @Coordinator、AgentFleet、ハンドオフ、条件分岐で構成され、イベントソーシングされた coordination journal が因果関係の系譜を記録する。永続化された Workflow<S> は CheckpointStore 上で休止でき、atmosphere-checkpoint-temporal を追加すれば Temporal をバックエンドにできる。ここで README が明示しているのは、これは durable step execution であって wall-clock triggering ではないという点だ。定時起動はコンテナのスケジューラや専用スケジューラの仕事になる。

導入は CLI の atmosphere run から始まる

README の Quick Start は3段階で示されている。まずサンプルを動かすなら、Homebrew の tap か install.sh で CLI を入れる。

brew install Atmosphere/tap/atmosphere curl -fsSL https://raw.githubusercontent.com/Atmosphere/atmosphere/main/cli/install.sh | sh

次にアプリを作る。テンプレートは ai-chat が例として挙げられている。

atmosphere new my-agent --template ai-chat cd my-agent LLM_API_KEY=your-key ./mvnw spring-boot:run

API キーは環境変数 LLM_API_KEY で渡す形になっている。

ランタイムアダプタの差し替えは CLI のオプションで行う。README では --runtime spring-ai を指定すると Spring AI アダプタ向けにスキャフォールドし、CLI のオーバーレイが Maven 設定を注入する、という説明が途中で切れている。この先の正確な記述は手元の資料では確認できないので、実際のオプション一覧は CLI のヘルプで確認してほしい。

依存関係としては atmosphere-runtime が Maven Central の org.atmosphere グループで公開されており、クライアント側は npm の atmosphere.js、JVM クライアントは wasync が用意されている。

ホストとスケジューラを自分で持つという制約

README の Scope 節は率直だ。Atmosphere はリアルタイムのイベント駆動フレームワークであり、エージェントのホスティングプラットフォームではない。計算資源とスケジューリングは、選んだホスト（Tomcat、Jetty、Netty、Undertow、Quarkus、Spring Boot、任意のサーブレットコンテナ）が所有する。決済やコマースのプリミティブはスコープ外と明記されている。

この切り分けは、Cloudflare Agents、AWS Bedrock Agents、Vertex AI Agents のようなプラットフォーム製品と比べたときに効いてくる。Atmosphere はモデルの重みをホストしない。プロバイダを呼ぶだけだ。ベクトルストアも管理しない。SemanticRecallInterceptor は用意されているが、保存先は Spring AI の VectorStore や LangChain4j の embeddings、あるいは自前のものを BYO で接続する。

もう一つの制約は実行モデルだ。README は、ステートレスでバースト的で、アイドル時には休止すべき自律エージェントには、サーバーレスのエージェントプラットフォームの方が通常は適していると書いている。Atmosphere の強みは長命なステートフルセッションをリアルタイムトランスポートで維持し、ポリシーアドミッションをクリティカルパスに置くことだから、セッションを保持し続ける前提が合わないワークロードでは利点が反転する。

サンドボックスも同様に範囲が限られる。atmosphere-sandbox の SandboxProvider SPI と DockerSandboxProvider がデフォルトとして提供されるが、ブラウザ自動化やヘッドレス Chromium は提供されない。

Spring AI や LangChain4j を直接使う場合との違い

Spring AI や LangChain4j を直接使う選択肢と、Atmosphere を挟む選択肢は、抽象化の層が違う。前者はモデル呼び出しとプロンプト、ツール定義の抽象化を提供する。Atmosphere はそれらを AgentRuntime SPI の背後にアダプタとして置き、上にトランスポートとガバナンスを載せる。

実務上の差は、フレームワークを乗り換えたときにどこを書き直すかという点に出る。Spring AI から LangChain4j へ移る場合、直接使っていれば呼び出し側のコードに変更が及ぶ。Atmosphere を挟んでいれば、アダプタの差し替えと capability flags の再確認で済む設計になっている。ただしこれは設計意図であって、すべての機能が12のアダプタで同一に使える保証ではない。capability flags が契約テストで検証されているという記述は、逆に言えばアダプタごとに使える機能に差があることを示している。

ガバナンスを自前で書くコストも比較対象になる。ポリシーアドミッション、コスト上限、PII 書き換え、人間の承認、キルスイッチを Spring AI の上に自作するなら、それはアプリケーションコードとして保守され続ける。Atmosphere はこれをフレームワーク側の機能として持つ。その代わり、ポリシーの表現方法や承認フローの形は Atmosphere の設計に従うことになる。

HITL 承認とセッションテープの実際の挙動

人間の承認（HITL）について README が述べているのは、永続的な承認はスレッドを保持せずに休止し、ワークフローの状態を永続化し、REST の承認サーフェスを通じて再開するという点だ。スレッドを占有しないというのは、承認待ちの件数が増えてもサーバのスレッドプールが枯渇しないことを意味する。承認待ちの状態はどこかに永続化される必要があり、そこは atmosphere-durable-sessions 系のモジュールが担う。

長い実行の再開は、永続セッション、run ID、リプレイバッファ、チェックポイント、再接続安全な継続で支えられる。クライアントが切断しても、run ID を軸に続きから再開できるという設計だ。

観測面では、オプトインの session tape がセッション境界の AI イベントを記録する。SQLite で永続化され、モデル呼び出しなしで実行や協調ツリーを再構築でき、そこから小さいモデルを蒸留できると README は説明する。デバッグや監査の用途を想定した機能だが、オプトインである以上、有効にしなければ何も記録されない。

メモリは2層ある。AiConversationMemory が会話ごとの履歴、LongTermMemory がユーザーごとの事実を扱う。保存先はインメモリか、atmosphere-durable-sessions-sqlite / -redis による永続化を選べる。

プロトコル公開とチャネルの広さがもたらす保守コスト

Atmosphere は同じエージェントを複数の入口から公開する。ブラウザ向けエンドポイントに加え、MCP（MCP 2026-07-28 仕様のステートレス RC、セッションは 2024-11-05 まで遡って対応）、A2A、AG-UI、そして Slack、Telegram、Discord、WhatsApp、Messenger の各モジュールが README に列挙されている。

この広さは採用の決め手になり得るが、保守の観点では注意が要る。MCP の仕様は日付付きで版が管理されており、ステートレス RC と過去仕様の両方をサポートするということは、仕様改訂のたびに追従作業が発生するということだ。チャネルアダプタも同様で、各メッセージングプラットフォームの API 変更に引きずられる。

リリースの頻度はこの点と無関係ではない。手元の資料では atmosphere-4.0.70（2026-09-01）、4.0.69（2026-08-30）、4.0.68（2026-08-23）と、週次に近い間隔でパッチが出ている。活発である一方、依存する側はバージョン固定とアップグレード検証の運用を最初から決めておく必要がある。

ライセンスは Apache-2.0 で、OSI 承認の許諾型ライセンスに分類される。商用利用や改変、再配布が可能で、特許条項と帰属表示の条件が含まれる。ただし個々の依存モジュール（Temporal 連携や各種チャネルアダプタ）が同じ条件で提供されているかは別途確認が必要で、ここは法的助言ではなく確認事項の指摘として受け取ってほしい。

編集部の結論

既存の JVM スタックの中に、人間の承認を挟みながらマルチチャネルで動くエージェントを置きたいチームに向く。逆に、アイドル時に完全に休止させたいサーバーレス型の自律エージェントや、決済・課金のプリミティブまで一つの製品で揃えたい場合には合わない。導入前に確認すべきは、自分のホスト（Tomcat、Jetty、Netty、Undertow、Quarkus、Spring Boot のいずれか）で atmosphere-runtime のブロードキャスタが期待通り動くか、そして選んだ AgentRuntime アダプタの capability flags が自分のユースケースをカバーしているか。この2点はドキュメント上の表で確認できるので、PoC の最初の1日で潰しておきたい。

公式情報源

1. Atmosphere/atmosphere on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases