OpenAEVとは？OpenBASからの改称・CE/EEの違いとDocker導入手順【2026年10月】

OpenAEV（Open Adversarial Exposure Validation）は、フランスのFiligranが開発するオープンソースの攻撃シミュレーション基盤です。2025年10月28日に公開されたバージョン2.0で旧名のOpenBAS（Open Breach and Attack Simulation）から改称し、Filigranは翌29日のプレスリリースで改称とEnterprise Editionの刷新を発表しました。GitHubのリポジトリも OpenAEV-Platform/openaev へ移っています。

この記事では、改称の中身とAEVという言葉の意味、シナリオ・インジェクト・エクスペクテーションの仕組み、無償のCommunity Edition（CE）と有償のEnterprise Edition（EE）の境目、Docker Composeでの導入手順、OpenCTIとの連携設定を、GitHubのリリースノートと公式ドキュメント（docs.openaev.io）で確かめながら整理します。数値と版番号は2026年10月8日時点のものです。

まとめ：OpenAEVの正体と2026年10月時点の要点

• OpenBASの新しい名前：製品そのものは同じで、2025年10月28日のOpenAEV 2.0.0で改称した。1.x系はOpenBASの名前で公開されていた
• 最新版は3.261005.0（2026年10月5日公開）。2026年5月から版番号が日付形式（2.260520.0など）になり、7月30日の3.260729.0でメジャー番号が3に上がった
• ライセンスは2本立て：CEはApache License 2.0、EEは独自のEnterprise Edition License。EEのソースも同じリポジトリにあり、ファイル先頭のヘッダーで区別される
• EEはオンプレミスでも契約が前提：試用ライセンスがあり、開発・研究用途や非政府の慈善団体にはFiligranが無償ライセンスを提供する場合がある。CrowdStrike・Tanium・SentinelOne・Palo Alto Cortex・Microsoft Defender for Endpointの各エージェント経由の実行、マルチテナント、監査ログはEE
• 導入はDocker Composeが標準：PostgreSQL・Elasticsearch・RabbitMQ・S3互換ストレージが必須。本体とPostgreSQL・Elasticsearchにそれぞれ8GB以上のメモリが推奨されている。Elasticsearchの推奨は9.0以上に上がった

OpenBASからOpenAEVへの改称とAEVの意味

OpenAEV 2.0.0のリリースノートは、冒頭で「OpenBAS is renamed OpenAEV」と告げています。機能が別製品に入れ替わったのではなく、OpenBAS 1.18系の後継がそのまま2.0として出た形です。改称の理由として挙げられているのが、BAS（Breach and Attack Simulation）からAEV（Adversarial Exposure Validation）への位置づけの変更です。

BASとAEVの違い

リリースノートはGartnerの定義を引き、AEVを「攻撃が実行可能かどうかの証拠を、一貫して・継続的に・自動で示す技術」と説明しています。そのうえでFiligranは、AEVをBASの置き換えではなくBASの発展形だとしています。違いは検証の回し方にあります。

AEVは、Gartnerが提唱するCTEM（継続的脅威エクスポージャー管理）の「検証」段階を担う技術として語られることが多い言葉です。CTEMの5段階と脆弱性管理との違いはCTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説で整理しています。

版番号の変遷と最新版

OpenAEVはリリースの頻度が高く、2.0.0から3.261005.0までの約1年で70本のリリースがGitHubに並び、日付形式に移った2026年5月20日以降は20週で38本と、週に2本近いペースです。版番号の付け方も途中で変わりました。

日付形式では、2つ目の数字が年月日を表します（3.261005.0なら2026年10月5日）。GitHubの公開日とは1日ずれることがあり、3.260729.0の公開は7月30日でした。検索で見つかる解説記事の多くは1.x系か2.0前後の内容なので、画面名や必須設定が現行版と合わないことがあります。手順を参照するときは、docs.openaev.ioの版表記と手元の版を突き合わせてください。

OpenBAS 1.xから2.0へ上げるときの移行点

改称は名前だけの変更ではなく、イメージ名・設定名・データの接頭辞まで変わりました。公式の移行ガイド（2.0.0 OpenAEV renaming）が手作業で確認するよう求めているのは次の箇所です。

• Dockerイメージ：新しい名前空間（openaev/platform など）から取得する
• SAMLの環境変数：OPENBAS_PROVIDER_XXX を OPENAEV_PROVIDER_XXX へ読み替える
• MinIOの既定バケット：openbas から openaev に変わる。既存バケットを移すか、MINIO_BUCKET で既存の名前を指定する
• RabbitMQのキュー：接頭辞が変わるため、実行中のシミュレーションが終わってから更新する
• Elasticsearch・OpenSearchの索引：接頭辞が openaev になる。移行後は古い openbas の索引を削除して容量を空ける
• エージェント：大半は自動で更新されるが、詳細インストールで「ユーザーサービス」として入れたものは、旧エージェントを削除して入れ直す

CrowdStrike経由で実行している場合は、応答スクリプトの名前も「OpenBAS Subprocessor」から「OpenAEV Subprocessor」へ変える必要があります。

OpenAEVの仕組み：シナリオ・インジェクト・エクスペクテーション

OpenAEVで検証を組む単位は3つです。インジェクトは1つの攻撃動作や連絡（コマンド実行、フィッシングメール送信、Slack投稿など）、シナリオはインジェクトを時系列に並べた台本、シミュレーションはシナリオを実際に走らせた1回分の実行です。インジェクトを1本だけ単発で試す「アトミックテスト」もあり、2.0以降は定期実行もできます。

結果の判定に使うのがエクスペクテーション（期待値）です。インジェクトごとに「何が起きれば成功か」を決め、スコアを持たせます。公式ドキュメントでは、次の2系統に分かれています。

• 手動：メールやSMSを受け取った人が報告・エスカレーションしたかを、演習の主催者が判定する。机上演習やインシデント対応訓練で使う
• 自動：EDRやSIEMなどに接続したコレクターの信号で判定する。防御（攻撃がブロックされたか）・検知（アラートが上がったか）・脆弱性（対象にCVEが存在するか）・記事（対象者がメディア対応訓練の記事を読んだか、確認したか）の4種類がある

複数の端末や人を対象にした場合の集計方法も選べます。「全対象が成功で100点、1つでも失敗なら0点」はコンプライアンス確認向き、「1つでも成功すれば100点」はSOCの検知確認向きと公式に例示されています。全エクスペクテーションの判定が出た時点で、シミュレーションは完了と扱われます。技術的な攻撃と人の対応を同じシナリオで測れる点が、端末上の検知確認に絞った検証ツールとの違いです。

エージェントとエグゼキューターの種類

端末上で攻撃動作を実行するのがエグゼキューターです。標準はFiligranが開発するOpenAEV Agent（Rust製）で、Windows・Linux・macOSのx64とARM64に対応します。エージェント自身は攻撃動作をせず、ジョブを受け取ってインプラントと呼ぶ別プロセスに実行させます。ウイルス対策ソフトに対して中立を保つための設計です。

公式ドキュメントは、ウイルス対策ソフトの除外設定を「必須」としたうえで、除外する範囲を runtimes サブフォルダだけに限るよう求めています。攻撃動作のファイルは別の場所に置かれ、本来の検知・ブロックが働くようになっています。1.14以降は同じ端末に複数のエージェントを入れられるため、一般ユーザー権限と管理者権限で結果を比べる使い方もできます。

既存のEDRエージェントを経由して実行する方式もあります。対応はオープンソースのCalderaと、Tanium・CrowdStrike Falcon・SentinelOne・Palo Alto Cortex・Microsoft Defender for Endpoint（いずれもEE）です。Microsoft Defender for Endpointは3.260729.0で追加され、端末に入っているMDEセンサーをLive Response API経由で使います。

インジェクターとコレクターの役割

インジェクターは外部のサービスやツールに働きかける部品で、大半は独立したPythonプロセスとして動きます。GitHubのinjectorsリポジトリには、Nmap・Nuclei・NetExec・Shodan・Censys・AWS（Stratus Red Team）・メール送信（SMTP・Microsoft 365・Google Workspace）・Slack・Teams・AI Red Teamなどが並びます。標準のdocker-compose.ymlに最初から入っているのはNmapとNucleiです。

コレクターは逆向きで、SIEM・EDR・XDRなどから「検知されたか・防がれたか」を取りに行きます。CrowdStrike・Microsoft Defender・Microsoft Sentinel・SentinelOne・Splunk ES・Elastic・QRadar・Palo Alto Cortex XDRなどに対応し、MITRE ATT&CK・Atomic Red Team・NVDのCVEといった攻撃手法や脆弱性の定義を取り込むコレクターもあります。EDRやSIEMの結果を自動取得するには対応するコレクターが必要ですが、自動エクスペクテーションにも結果を手動で登録できます。Splunkを検知側に置く場合のSPLや検証環境はSplunkとは？SPLの書き方・Docker検証環境と料金の実額を実装者向けに解説を参照してください。

Community EditionとEnterprise Editionの違い

OpenAEVはオープンコア型です。EEのソースコードも同じGitHubリポジトリに含まれ、ファイル先頭のライセンスヘッダーでCEかEEかが分かれます。ヘッダーの無いファイルはCE（Apache License 2.0）の扱いです。

表はEEの公式ページ（Available features）と、2.0.0・3.260729.0のリリースノートの（CE）（EE）表記から作りました。AI関連でも、3.260729.0で入ったAI Doc ReviewerやAI Red Teamインジェクターの拡張はCEと表記されています。「AIはすべてEE」ではない点に注意してください。

EEライセンスを使える条件

EEは、プラットフォームの設定画面にある「Manage your Enterprise Edition License」からライセンスキーを入れると有効になります。キーを発行するのはFiligranだけで、入手経路は公式ドキュメントで次のように決められています。

• 試用：Filigranのサイトで試用ライセンスを発行できる
• 無償：コネクター開発や技術パートナーとの連携などの開発・研究用途、非政府の慈善団体
• SaaS：FiligranのSaaS利用者には自動で付与される
• それ以外：オンプレミスを含め、Filigranとエンタープライズ契約を結んだ組織に限る

つまり、社内で試用したEE機能をそのまま本番で使い続けることはできません。PoCの段階でCEだけで成り立つ構成かどうかを先に確かめ、EDR経由の実行が要件に入るなら、その時点で見積もりを取るのが順当です。価格は公開されていません。

Docker Composeでの導入手順と必要リソース

公式の導入方法は、Docker Composeと、リリースパッケージ（openaev-api.jar）を使う手動導入の2つです。本番環境についてはKubernetesなどで全コンポーネントをコンテナとして動かすことが推奨されています。ここでは検証環境を作る前提で、Docker Composeの手順を追います。

必須の依存コンポーネントと推奨リソース

手動導入の場合に必要なのは、Javaの実行環境・PostgreSQL・Elasticsearch・RabbitMQ・S3互換ストレージ（標準構成ではMinIOから派生したSilo）です。公式ドキュメントの要件ページ（2026年10月1日更新）の推奨値は次のとおりです。

表の下限を合計すると、メモリは本体とPostgreSQL・Elasticsearchだけで24GBです。標準のdocker-compose.ymlはこれにRabbitMQ・Silo・Redis・XTM Composer・XTM One（ワーカーと専用PostgreSQLを含む）・コレクター4本・インジェクター2本を加えて起動するため、ホストのメモリはその分を積み上げて見積もります。なお、標準の.env.sampleがElasticsearchのJVMに割り当てるのは4GB（ELASTIC_MEMORY_SIZE=4G）で、表の8GBより小さい値です。

Elasticsearchの版は、公式資料どうしで記述が揃っていません。2026年10月1日更新の要件ページは9.0以上を必須の下限とし、移行ガイド（Elasticsearch 9）は「9.x用のクライアントに切り替えたため8.xのサーバーでは起動しない」と説明しています。ただし移行ガイドの適用開始版は「[MigrationVersion]」のまま空欄で、2026年10月8日時点の標準docker-compose.ymlは8.19.23を指定しています。最新版3.261005.0のソースには8.x用と9.x用の両方のクライアントが含まれています。新しく環境を作るならElasticsearchは9.xで用意し、既存の8.x系クラスターを流用する場合は、上げるOpenAEVの版のリリースノートで対応版を確かめてから更新してください。OpenSearchを使う構成はこの変更の影響を受けません。

.envで必ず変える値

Docker用のファイルは OpenAEV-Platform/docker リポジトリにあります。現行のdocker-compose.ymlは、OpenAEV本体と依存コンポーネントに加えて、4つのコレクター（MITRE ATT&CK・OpenAEV・Atomic Red Team・NVD CVE）、2つのインジェクター（Nmap・Nuclei）、統合管理のXTM ComposerとXTM Oneまでを一度に起動する構成です。

git clone https://github.com/OpenAEV-Platform/docker.git
cd docker
cp .env.sample .env

.env.sampleで「MANDATORY」と明記されているのは、管理者トークン（UUIDv4）とXTM One登録用トークン（長い乱数）の2つです。暗号化キーとソルトも2.1.0から必須になり、ソルトは8バイト以上と決められています。値は先にターミナルで作っておきます。

uuidgen | tr 'A-Z' 'a-z'   # OPENAEV_ADMIN_TOKEN 用
openssl rand -hex 32        # PLATFORM_REGISTRATION_TOKEN・XTM_ONE_SECRET_KEY 用
openssl rand -hex 16        # OPENAEV_ADMIN_ENCRYPTION_KEY・SALT 用

生成した値と、初期値の ChangeMe が入ったパスワード類を.envで置き換えます。

OPENAEV_ADMIN_TOKEN=＜uuidgenの出力＞
PLATFORM_REGISTRATION_TOKEN=＜64桁の乱数＞
OPENAEV_ADMIN_ENCRYPTION_KEY=＜乱数＞
OPENAEV_ADMIN_ENCRYPTION_SALT=＜乱数＞
[email protected]
OPENAEV_ADMIN_PASSWORD=＜強いパスワード＞
POSTGRES_USER=openaev
POSTGRES_PASSWORD=＜強いパスワード＞
MINIO_ROOT_PASSWORD=＜強いパスワード＞
RABBITMQ_DEFAULT_PASS=＜強いパスワード＞
XTM_ONE_SECRET_KEY=＜64桁の乱数＞
[email protected]
XTM_ONE_ADMIN_PASSWORD=＜強いパスワード＞
XTM_ONE_POSTGRES_USER=xtmone
XTM_ONE_POSTGRES_PASSWORD=＜強いパスワード＞

フィッシング演習でメールを送る場合は、SMTP_HOST などのメール設定も実在のサーバーに合わせます。

Docker Composeの起動確認とOpenAEVへの初回ログイン

docker compose up -d
docker compose ps

OpenAEV本体と依存サービスのヘルスチェックが成功し、コレクター・インジェクターなどの実行状態とログに異常がないことを確認したら、http://localhost:8080 を開き、.envの OPENAEV_ADMIN_EMAIL と OPENAEV_ADMIN_PASSWORD でログインします。2.0以降の新規インスタンスには、シナリオ・ダッシュボード・連携設定の初期コンテンツ（Starter pack）と「Getting started」ページが入っています。続けて画面右上のアイコンから端末にOpenAEV Agentを入れれば、アトミックテストを1本走らせるところまで進めます。

docker-compose.ymlのイメージは openaev/platform:latest のように latest タグで書かれています。リリースが週に1〜2回出る製品なので、検証環境を作り直すたびに版が変わります。結果を比べたい期間は、イメージのタグを版番号で固定しておくのが安全です。

起動しないときに最初に見る箇所

• PostgreSQLの認証失敗：POSTGRES_USER に admin などの予約名を使うと失敗する。公式は openaev などへの変更を案内している
• 本体がすぐ終了する：docker compose logs openaev でログを見て、必須の環境変数の未設定と、PostgreSQL・Elasticsearch・RabbitMQ・MinIOの状態を確認する
• Elasticsearchが落ちる：ELASTIC_MEMORY_SIZE に対してホストのメモリが足りていない。Linuxでは vm.max_map_count の不足も疑う

OpenCTIとの連携設定

同じFiligranの脅威インテリジェンス基盤OpenCTIとは、XTM Suiteコネクターで双方向につながります。OpenCTIで特定の侵入セットや脅威プロファイルを選んでOpenAEVのシナリオ実行を起動し、その検知率・防御率をOpenCTIへ書き戻す流れです。前提として、OpenCTIはv6.x以降が推奨されています。

接続はOpenAEVのテナント単位です。テナントのUUIDを {id} に入れ、OpenAEV側に次の環境変数を設定します。Docker Composeの場合はopenaevサービスのenvironmentに追加し、設定変更を反映してコンテナを再作成してください。.envへの追記だけではコンテナへ渡りません。

OPENAEV_XTM_OPENCTI_{id}_ENABLE=true
OPENAEV_XTM_OPENCTI_{id}_URL=https://opencti.example.com
OPENAEV_XTM_OPENCTI_{id}_TOKEN=＜OpenCTIのAPIトークン＞

再起動後、OpenCTIのコネクター一覧に「OpenAEV Coverage」が表示されれば接続できています。GraphQLのエンドポイントが既定の <url>/graphql と異なる構成（リバースプロキシで別パスにしている等）の場合だけ、APIのURLを別途指定します。テナントのUUIDは管理画面のテナント設定で確認できます。

OpenAEVの導入を見送るべき条件

OpenAEVはCEだけでも検証を一通り回せますが、どの組織にも向くわけではありません。次のどれかに当てはまるなら、導入より先に手当てが要ります。

• ウイルス対策の除外設定を通せない：OpenAEV Agentは runtimes フォルダの除外が必須。端末の設定変更に数か月の承認がかかる組織では、検証が始まらない。EDR経由の実行に切り替える場合はEEの契約が要る
• 検知結果を返す先が無い：EDRやSIEMの結果を自動取得するには対応するコレクターが必要。接続できない場合は結果を手動登録できるが、継続的な自動検証を目的とするなら、結果取得の仕組みを先に整える必要がある。まずSOCの監視基盤が整っているかを確認する
• 運用する人がいない：週1〜2回のリリースに追随し、検知できなかった攻撃手法を検知ルールの修正に戻す担当が要る。検知結果の分析や修正後の再検証を担当できない場合は、診断後の改善支援まで含む外部サービスを検討する

逆に、SIEM・EDRが稼働していて、検知ルールを継続的に直す体制がある組織なら、CEの範囲でMITRE ATT&CKの手法ごとに検知の穴を洗い出せます。SOCの体制づくりについてはSOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説【2026年時点】、検証するシナリオを選ぶ前段の脅威の洗い出しは脅威モデリングとは？STRIDEでの脅威抽出手順とツール選定を実装目線で解説が参考になります。

よくある質問

OpenBASとOpenAEVの違いは何ですか？

同じ製品です。2025年10月28日公開のバージョン2.0でOpenBASからOpenAEVへ改称しました。GitHubのリポジトリやDockerイメージの名前もOpenAEVに変わっているため、1.x系の手順書は名前を読み替える必要があります。

OpenAEVは無料で使えますか？

Community EditionはApache License 2.0で、商用環境を含めて無料で使えます。EDRエージェント経由の実行やマルチテナントなどのEnterprise Edition機能は、原則としてFiligranとの契約が必要です。試用ライセンスのほか、開発・研究用途や非政府の慈善団体には無償ライセンスが提供される場合もあります。

OpenAEVのGitHubリポジトリはどこですか？

本体は github.com/OpenAEV-Platform/openaev、Docker Composeの設定は同じ組織の docker リポジトリ、インジェクターとコレクターはそれぞれ injectors と collectors リポジトリにあります。

ビル管理システムのOpenBASとは関係がありますか？

関係ありません。カナダのMircom社が提供するビル自動化システム（空調・照明の制御）にも「OpenBAS」という製品があり、検索結果に混ざります。Filigranのセキュリティ製品の旧名とは別物です。

AEVとは何の略ですか？

Adversarial Exposure Validation（敵対的エクスポージャー検証）の略です。攻撃者の手法を再現して、自社の弱点が実際に悪用できるかを継続的に確かめる技術を指します。Filigranはこれを、攻撃シミュレーション（BAS）の発展形と位置づけています。

関連記事

• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説
• SOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説【2026年時点】
• Splunkとは？SPLの書き方・Docker検証環境と料金の実額を実装者向けに解説
• 脅威モデリングとは？STRIDEでの脅威抽出手順とツール選定を実装目線で解説
• AIレッドチーミングとは？生成AIの脆弱性を洗い出す実施手順とツール選定【2026年時点】