Axon FrameworkはCQRSとイベントソーシングをJavaで実装するためのフレームワークです。2025年11月以降、前提が2つ変わりました。バージョン5で集約のモデリングAPIが作り直され、さらにAxon Framework 4が2026年6月30日にサポート終了を迎えています。2026年9月時点の最新版、Spring Bootへの導入で変わった依存座標、そして4系に留まる場合のリスクを一次情報で整理します。
まとめ：導入・移行の前に押さえる4点
最新版は5.3.2（2026年9月10日）です。Axon Framework 4は2026年6月30日にサポートが終了し、公式は「New CVEs affecting AF4 will not be fixed by the maintainers.」と明言しています。4.13.2で止めたままの本番環境は、脆弱性修正が上流から来ない状態です。
Spring Bootへ組み込む依存は、4系のorg.axonframework:axon-spring-boot-starterから5系ではorg.axonframework.extensions.spring:axon-spring-boot-starterへ、groupIdごと変わりました。こちらはApache License 2.0のままです。一方でAxon Server接続と分散メッセージングは5.1でio.axoniq.framework（Axoniq Framework）へ切り出され、本番利用にサブスクリプションが必要になりました。
移行で手間がかかるのはSagaです。5系のコアにSagaは無く、実行中のインスタンスを同じアプリケーション内で引き継ぐ互換モジュールは提供待ちの状態にあります。動作要件もJava 21へ上がりました。以下、版と要件、OSSと商用の境界、導入手順、移行で壊れる箇所、採用判断の順に見ていきます。
Axon Frameworkの守備範囲と2026年9月時点のバージョン
フレームワークが引き受ける処理と、設計者が決める部分
Axon Frameworkが提供するのは、コマンド・イベント・クエリという3種類のメッセージを配送する経路と、イベント列から現在の状態を復元する仕組みです。コマンドを受け取るエンティティ、そこから発行するイベント、読み取り用の投影をどう切るかは設計者が決めます。AxonはCQRSによる読み書きの責務分離とイベントソーシングによる状態再生を配線する道具であって、境界の引き方そのものを代行するものではありません。境界の設計はドメイン駆動設計の集約とコンテキスト分割の話になります。
この前提に立つと、Axonの採否は「CQRSをやるかどうか」ではなく、メッセージ基盤とイベントストアを自前で組むか既製品に寄せるかの選択になります。
Axon 5・4のバージョンとサポート状況
AxonIQは2025年11月18日に5.0を公開し、2026年は9月までに14回のGAリリースを出しています。2026年9月21日時点の状況は次のとおりです。
| 系列 | 最新版 | 公開日 | Java | Spring Boot | 上流サポート |
|---|---|---|---|---|---|
| Axon Framework 5 | 5.3.2 | 2026-09-10 | 21以上 | 3・4 | 継続中 |
| Axon Framework 4 | 4.13.2 | 2026-06-23 | 17以上 | 2・3・4 | 2026-06-30に終了 |
Javaの要件はjarの実体で確認できます。axon-messaging-5.3.2.jarのマニフェストはJava-Version: 21、クラスファイルのメジャーバージョンは65（Java 21）でした。4.13.2は同じ場所が17（メジャー61）なので、4系から5系へ上げるときはランタイムの引き上げが同時に必要です。
Spring Bootとの対応は、公式のSpring Boot Integrationの対応表に版ごとの一覧があります。Axon 5.0.3以降はSpring Boot 3と4の両方が対象で、4.13はSpring Boot 2・3・4に対応します。Spring Boot 4系へ先に移行している環境でもAxon 5をそのまま使えます。なおaxon-parentの5.3.2はSpring Framework 6.2.19とSpring Boot 3.5.16を依存管理値として固定していますが、これはビルド時の既定値であって対応範囲とは別物です。
4系については、AxonIQが有償の長期サポートを1年分用意しています。無償で使い続ける選択肢は、上流の脆弱性修正が来ないことを受け入れる判断とセットになります。
Axon Framework 5.1で分かれたOSSと商用の境界
org.axonframework と io.axoniq.framework の分担
2026年4月28日の5.1.0リリース告知は「This release marks the first release wherein the split between Axon Framework and Axoniq Framework is apparent.」と述べ、Axon Serverコネクタ、Axon ServerのSpring連携、Testcontainerサポート、DistributedCommandBus、DistributedQueryBus、デッドレターキュー実装を商用側へ移しました。公式のフレームワーク比較ページは境界をgroupIdで説明しています。
「Axon Framework modules are marked with org.axonframework, whereas Axoniq Framework modules are marked with io.axoniq.framework」。後者は「commercial offerings under the Axoniq Terms of Service, and require an active subscription for production use」と明記されています。実際、io.axoniq.framework配下のjarのpomヘッダには「Licensed under the AXONIQ TERMS OF SERVICE, Version 29 April 2026」と書かれており、ライセンスはビルド成果物のレベルで分かれています。
分かりにくいのは、Axon Serverのサーバ本体と接続コネクタで扱いが違う点です。サーバ側のAxoniq Developer editionは公式に「entirely free to use. It is limited to a single node」とされ、単一ノードなら無償です。一方、そこへ接続するクライアント側のaxon-server-connectorは5.1以降io.axoniq.frameworkに属するため、本番ではサブスクリプションの対象になります。
認証情報なしの評価モードと15分後の強制終了
ここが運用上いちばん重要です。Axoniq Frameworkのモジュールは起動時に資格を検証し、認証情報が無い場合は評価モードで動きます。公式ドキュメントの記述は「All Axoniq Framework features operate for a 15-minute evaluation window, regardless of which features are in use.」「Once the evaluation window closes, the application is forcefully shut down.」です。認証情報なしの評価時間を超えると、警告で済むのではなくアプリケーションが強制終了します。
認証情報を設定したうえでAxoniq Platformへ到達できなくなった場合は「it enters a 24-hour grace period」とされ、24時間は動作を継続します。猶予が切れればやはり強制終了します。外部接続を閉じた環境で長時間稼働させる予定があるなら、公式はAxoniq Platformへ常時接続できない場合にライセンスファイルを環境へ配置する方式を案内しているので、自社の構成に適用できるかを事前にAxonIQへ確認してください。
無償のまま本番を続けられる範囲
結論として、Apache 2.0のモジュールだけで構成すれば無償で本番運用できます。コマンド・イベント・クエリのAPI、エンティティのモデリング、イベントソーシング、JPAのトークンストア、テストフィクスチャ、そしてSpring Bootの自動構成はすべてApache 2.0の側に残っています。イベントストアをRDBに置く構成なら、商用モジュールに触れずに完結します。
商用の利用条件が適用されるのは、Axoniq Frameworkのモジュールを本番で使う段階です。Axon Serverへ接続する、コマンドバスやクエリバスを分散させる、提供されているデッドレターキューを使う――このいずれかに踏み込むと対象になります。単一サービスからAxon Serverへつなぐだけでも該当するので、判断軸は分散の有無ではなく使うモジュールです。商用モジュールを採用する時点で契約条件と費用を確認する設計にしておけば、あとから構成を組み替える手戻りを避けられます。
Spring Bootへの導入：Axon 5で変わった依存座標
Axon 5・4のSpring Bootスターター依存座標
5系のOSSスターターはgroupIdがorg.axonframework.extensions.springに変わりました。artifactIdは4系と同じaxon-spring-boot-starterですが、groupIdを4系のままにして5.3.2を指定すると、その座標が存在せず依存解決でビルドが失敗します。
dependencies {
implementation platform("org.axonframework:axon-framework-bom:5.3.2")
implementation("org.axonframework.extensions.spring:axon-spring-boot-starter")
implementation("org.axonframework:axon-eventsourcing")
}
BOMがスターターの版も管理するため、個別の依存にバージョンを書く必要はありません。Axon Serverへ接続する場合は、商用側のBOMとスターターに差し替えます。こちらはAxoniq Platformの資格情報が必要です。
dependencies {
implementation platform("io.axoniq.framework:axoniq-framework-bom:5.3.2")
implementation("io.axoniq.framework:axoniq-spring-boot-starter")
}
4系を維持するなら、これまでどおりorg.axonframework:axon-spring-boot-starter:4.13.2です。ただし前述のとおり上流の保守は終わっています。
Axon 5での最小実装
Axon 5はエンティティ中心のモデルになり、4系の@Aggregateと@AggregateIdentifierは置き換わりました。Spring Bootで自動検出させる場合はスターターに含まれる@EventSourcedを使い、Springを使わない構成では@EventSourcedEntityを明示的に登録します。イベントの発行も静的メソッドではなく、ハンドラの引数で受け取るEventAppender経由になります。
package com.example;
import org.axonframework.eventsourcing.annotation.EventSourcingHandler;
import org.axonframework.eventsourcing.annotation.EventTag;
import org.axonframework.eventsourcing.annotation.reflection.EntityCreator;
import org.axonframework.extension.spring.stereotype.EventSourced;
import org.axonframework.messaging.commandhandling.annotation.CommandHandler;
import org.axonframework.messaging.eventhandling.gateway.EventAppender;
import org.axonframework.modelling.annotation.TargetEntityId;
@EventSourced(tagKey = "accountId")
public class Account {
private long balance;
@EntityCreator
public Account() {
}
@CommandHandler
void handle(DepositMoney command, EventAppender appender) {
if (command.amount() <= 0) {
throw new IllegalArgumentException("amount must be positive");
}
appender.append(new MoneyDeposited(command.accountId(), command.amount()));
}
@EventSourcingHandler
void on(MoneyDeposited event) {
this.balance += event.amount();
}
public record DepositMoney(@TargetEntityId String accountId, long amount) {}
public record MoneyDeposited(@EventTag(key = "accountId") String accountId, long amount) {}
}
これは5.3.2の実jarに対するコンパイル確認用の抜粋で、Spring Bootでの起動・コマンド配送・イベントの保存と復元までを通したものではありません。口座開設にあたる生成コマンドとイベントは省いています。
tagKeyと@EventTag(key = ...)は対になっており、この組で状態復元時に読み込むイベントが選ばれます。キーが一致していないと必要なイベントが選択されず、残高が復元されません。同じ識別子でイベントを保存して読み直し、期待する状態になるかをテストで確かめてください。
Axon 4から5へ移行するときに壊れる箇所
Axon 4から5へのパッケージ・アノテーション対応
ハンドラ系のアノテーションはパッケージごと移動しました。jarの中身で確認した対応は次のとおりです。
| 用途 | Axon 4（4.13.2） | Axon 5（5.3.2） |
|---|---|---|
| コマンド処理 | commandhandling.CommandHandler | messaging.commandhandling.annotation.CommandHandler |
| イベント処理 | eventhandling.EventHandler | messaging.eventhandling.annotation.EventHandler |
| クエリ処理 | queryhandling.QueryHandler | messaging.queryhandling.annotation.QueryHandler |
| 集約の宣言（Spring） | spring.stereotype.Aggregate | extension.spring.stereotype.EventSourced |
| 集約の宣言（非Spring） | modelling.command.AggregateRoot | eventsourcing.annotation.EventSourcedEntity |
| 識別子 | modelling.command.AggregateIdentifier | eventsourcing.annotation.EventTag |
いずれもorg.axonframework配下のパッケージです。importの付け替えはコンパイルエラーを頼りに一括置換できます。置換では済まないのが次の2つです。
実行中Sagaの移行制約と4系との並行稼働
5系のコアにSagaはありません。axon-modellingの4.13.2にはmodelling.saga配下に73個のクラスファイルがありますが、5.3.2のjarには同じパッケージが存在しませんでした。
新しく長時間プロセスを書くだけなら代替はあります。通常のイベントハンドラで書く方法や、プロセス用イベントから状態を組み立てる方法が公式のSaga移行ガイドに示されています。推奨とされるWorkflowsは「an Axoniq Framework feature and require an Axoniq license to run in production」で、商用かつプレビュー段階です。
制約があるのはすでに走っているSagaインスタンスの扱いです。4系のAPIを5系アプリ内で動かし続けるaxon-legacyモジュールについて、公式は「The axon-legacy module is under development and scheduled for 5.4.0. Until it lands, there is no supported way to upgrade an application with sagas in flight.」と書いています。ただしこれは同一アプリ内で引き継ぐ場合の話で、移行経路が無いわけではありません。公式は並行稼働による方法も示しています。「Whether or not you use the legacy module, migrate running saga instances by drainage: let saga instances created by Axon Framework 4 finish normally, while new process instances start on an Axon Framework 5 implementation.」――既存Sagaを4系で完了させ、新規プロセスだけ5系で受ける形です。コード移行と並行稼働の設計は、互換モジュールを待たずに進められます。なお5系にはDeadlineManagerに相当する仕組みも無く、公式は「Axon Framework 5 has no built-in deadline scheduling.」としています。
scatter-gatherクエリAPIの廃止と代替設計
クエリのscatter-gather APIは、公式の機能比較表で「Deprecated and removed as of Axon Framework 5」と記載され、5系には存在しません。複数ハンドラへ同報して結果を集める処理を使っている場合は、クエリを個別に発行する形へ書き換えるか、投影側で集約済みの読み取りモデルを用意する設計に変える必要があります。
採用判断：Axonが向く案件と避けるべき案件
向いているのは、監査要件で「いつ誰が何をしたか」を欠落なく残す必要があり、かつ読み取りと書き込みの負荷特性が大きく違うシステムです。金融の取引履歴や在庫の引当のように、状態そのものより状態に至った経緯が業務上の価値を持つ領域では、イベントを一次データにする設計が効きます。
一方で、次の条件に当てはまるなら採用や移行を見送るべきです。第一に、実行中のSagaを同一アプリ内で引き継ぐ必要があり、4系との並行稼働も運用上組めない場合。5.4.0で予定されるaxon-legacyの提供前は、この条件での移行が成立しません。4系は上流保守が切れているため、待つあいだ脆弱性修正の空白を抱えることになります。有償LTSの費用と待機期間を天秤にかける話です。第二に、サービス境界がまだ動いている段階のプロダクト。イベントは一度書けば消せない一次データなので、スキーマが固まる前にイベントソーシングへ踏み込むと、アップキャスタの保守が本体の開発を圧迫します。この段階ではモジュラモノリスで境界を試すほうが安全です。
新規に始めるなら、まずApache 2.0の範囲でRDBをイベントストアにした単一サービスを作り、運用に耐えるか確かめるのが現実的です。そこで手応えを得てから、分散とAxon Serverの費用を検討すれば足ります。
よくある質問
Axon Frameworkの最新バージョンはいくつですか？
2026年9月21日時点で5.3.2です。2026年9月10日に公開されました。4系の最終版は4.13.2（2026年6月23日）です。
Axon Framework 4はまだ使えますか？
動作はしますが、2026年6月30日で上流のサポートが終了しています。公式は新たに見つかったCVEが修正されないことを明記しており、無償のまま使い続けるのは脆弱性を放置する判断になります。AxonIQは1年分の有償長期サポートを提供しています。
Axon Frameworkは無料で使えますか？
org.axonframeworkとorg.axonframework.extensions.springのモジュールはApache License 2.0なので、本番を含めて無償です。Axon Server接続、分散コマンド／クエリバス、デッドレターキューなどio.axoniq.frameworkのモジュールは商用で、本番利用にサブスクリプションが必要です。
Axon Serverは必須ですか？
必須ではありません。イベントストアをRDBに置く構成なら使わずに済みます。サーバ本体のAxoniq Developer editionは単一ノード限定で無償ですが、5.1以降は接続コネクタが商用モジュールに属するため、本番で接続するならライセンスが要ります。
Axon 5でSagaは使えますか？
5系のコアにSagaはありません。新規の長時間プロセスは通常のイベントハンドラや商用のWorkflowsで書きます。実行中のSagaインスタンスを同一アプリ内で引き継ぐ互換モジュールは5.4.0で追加予定ですが、既存Sagaを4系で完了させながら新規処理を5系へ移す並行稼働なら、公式ガイドに沿って今から進められます。
