--- title: "OpenAEVとは？OpenBASからの改称・CE/EEの違いとDocker導入手順【2026年10月】" url: "https://www.issoh.co.jp/tech/details/11392/" published: 2026-03-17 updated: 2026-10-08 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 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の発展形だとしています。違いは検証の回し方にあります。 | 観点 | BAS | AEV（Filigranの説明） | | ----- | ---------- | ---------------- | | 検証の単位 | 個々の攻撃手法の再現 | 攻撃者のTTPと攻撃経路 | | 実施の頻度 | 演習・点検ごと | 継続的なループ | | 出力 | 検知・防御できたか | 弱点の優先順位と修正の手引き | AEVは、Gartnerが提唱するCTEM（継続的脅威エクスポージャー管理）の「検証」段階を担う技術として語られることが多い言葉です。CTEMの5段階と脆弱性管理との違いは[CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説](/tech/details/13277/)で整理しています。 ### 版番号の変遷と最新版 OpenAEVはリリースの頻度が高く、2.0.0から3.261005.0までの約1年で70本のリリースがGitHubに並び、日付形式に移った2026年5月20日以降は20週で38本と、週に2本近いペースです。版番号の付け方も途中で変わりました。 | 版 | 公開日 | 内容 | | ---------- | ----------- | --------------- | | 1.0.1 | 2024年5月16日 | OpenBASとしての1.0系 | | 1.18.20 | 2025年9月24日 | OpenBAS名での最終系列 | | 2.0.0 | 2025年10月28日 | OpenAEVへ改称 | | 2.3.4 | 2026年5月11日 | 従来形式の最終版 | | 2.260520.0 | 2026年5月20日 | 日付形式の版番号へ移行 | | 3.260729.0 | 2026年7月30日 | メジャー番号を3へ | | 3.261005.0 | 2026年10月5日 | 2026年10月8日時点の最新 | 日付形式では、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検証環境と料金の実額を実装者向けに解説](/tech/details/17455/)を参照してください。 ## Community EditionとEnterprise Editionの違い OpenAEVはオープンコア型です。EEのソースコードも同じGitHubリポジトリに含まれ、ファイル先頭のライセンスヘッダーでCEかEEかが分かれます。ヘッダーの無いファイルはCE（Apache License 2.0）の扱いです。 | 機能 | CE | EE | | ------------------------------------ | -- | -- | | シナリオ・シミュレーション・アトミックテスト | ○ | ○ | | OpenAEV Agent・Caldera経由の実行 | ○ | ○ | | ダッシュボード・レポート・通知 | ○ | ○ | | ロール（RBAC） | ○ | ○ | | CrowdStrike・Tanium・SentinelOne等経由の実行 | × | ○ | | 生成AIによるメール・記事の作成 | × | ○ | | インジェクトを連鎖させるワークフロー | × | ○ | | AIによる検知ルールの修正案・CVEの修正手順 | × | ○ | | マルチテナント・監査ログ | × | ○ | 表は[EEの公式ページ](https://docs.openaev.io/latest/administration/enterprise/)（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）です。[公式ドキュメントの要件ページ](https://docs.openaev.io/latest/deployment/platform/overview/)（2026年10月1日更新）の推奨値は次のとおりです。 | コンポーネント | 推奨版 | CPU | メモリ | ディスク | | ------------- | ------ | ---- | -------- | ---------- | | OpenAEV本体 | – | 2コア | 8GB以上 | 不要 | | PostgreSQL | 17.0以上 | 2コア | 8GB以上 | SSD 16GB以上 | | Elasticsearch | 9.0以上 | 2コア | 8GB以上 | SSD 16GB以上 | | RabbitMQ | 4.3以上 | 1コア | 512MB以上 | 2GB以上 | | S3 / Silo | 最新 | 1コア | 128MB以上 | SSD 16GB以上 | | インジェクター・コレクター | – | 各1コア | 各128MB以上 | 不要 | 表の下限を合計すると、メモリは本体と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=＜乱数＞ OPENAEV_ADMIN_EMAIL=secops@example.com OPENAEV_ADMIN_PASSWORD=＜強いパスワード＞ POSTGRES_USER=openaev POSTGRES_PASSWORD=＜強いパスワード＞ MINIO_ROOT_PASSWORD=＜強いパスワード＞ RABBITMQ_DEFAULT_PASS=＜強いパスワード＞ XTM_ONE_SECRET_KEY=＜64桁の乱数＞ XTM_ONE_ADMIN_EMAIL=secops@example.com 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のエンドポイントが既定の `/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年時点】](/tech/details/13310/)、検証するシナリオを選ぶ前段の脅威の洗い出しは[脅威モデリングとは？STRIDEでの脅威抽出手順とツール選定を実装目線で解説](/tech/details/16226/)が参考になります。 ## よくある質問 ### 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つの段階と企業の導入判断を解説](/tech/details/13277/) - [SOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説【2026年時点】](/tech/details/13310/) - [Splunkとは？SPLの書き方・Docker検証環境と料金の実額を実装者向けに解説](/tech/details/17455/) - [脅威モデリングとは？STRIDEでの脅威抽出手順とツール選定を実装目線で解説](/tech/details/16226/) - [AIレッドチーミングとは？生成AIの脆弱性を洗い出す実施手順とツール選定【2026年時点】](/tech/details/16071/) --- 出典: [OpenAEVとは？OpenBASからの改称・CE/EEの違いとDocker導入手順【2026年10月】]()（株式会社一創）