はじめに こんにちは、カケハシでデータサイエンティストをしている川邊です。 2026年3月9日〜13日に栃木県宇都宮市のライトキューブ宇都宮で開催された、言語処理学会第32回年次大会（NLP2026）に参加してきました。 カケハシはプラチナスポンサーとして協賛し、スポンサーブースの出展に加え、ポスター発表も行いました。本記事では、発表内容の紹介や学会の様子、気になった発表についてレポートします。 NLP2026について 言語処理学会年次大会は、自然言語処理（NLP）に関する国内最大級の学術会議です。今年は参加者約2,300名超、発表797件と、いずれも歴代最多の規模での開催となりました。 今年…

情報源： Elastic on Defence Cyber Marvel 2026: A Technical overview from the Exercise Floor Elastic Security Labs に掲載された DCM26 の記事をもとに、本ブログでは構成や設計上のポイントを整理します。 サイオステクノロジー株式会社 Saman イギリス国防省主催の Defence Cyber Marvel 2026（DCM26） は、伝統的なITネットワーク、企業環境、複雑な産業制御システムを対象にした、英国最大級の軍事サイバー演習です。形式としては force-on-force 型 が採用されており、防御を担う Blue Team が担当システムを守り、攻撃を担う Red Team がさまざまな手法で侵入や妨害を試みます。さらに、その攻防を White Team が監視し、システム可用性、攻撃検知、インシデント報告、復旧状況などをもとに評価します。つまり DCM26 は、単なる製品検証やデモではなく、攻撃・防御・評価が同時に進む実戦型の演習として設計されていました。 DCM26には 29カ国・70組織から 2,500人以上が参加し、5,000を超える仮想システムが稼働しました。演習は 2026年2月に5日間にわたって行われ、シンガポールの Exercise Control を中心に運営されました。Blue Team は地理的に分散した状態で参加し、英国内や海外の拠点から VPN 経由で演習環境に接続していました。この前提だけでも、参加者全員に同じ環境を安全に配布し、チームごとに厳密に分離しながら、攻撃と防御を同時に成立させる必要があったことがわかります。 こうした前提の中で、Elastic は DCM26 全体を役割ごとに異なる形で支えていました。特に中心となったのは Blue Team 向けの単一マルチテナント基盤ですが、それに加えて Red Team 向けには C2 可視化用の専用デプロイメント、NSOC 向けには演習全体と AI 利用監査を担う専用デプロイメントも用意されていました。つまり Elastic は、攻撃・防御・運営の各レイヤーをそれぞれに合った構成で支えていたのです。 目次 Blue Team基盤の設計 データ分離の仕組み 事前検証と負荷テスト 演習向けの防御設定 Red TeamとNSOCの基盤 AI活用のガバナンス Attack Discoveryの役割 3つのAI活用レイヤー 感情分析という試み まとめ 用語集 Blue Team基盤の設計 Blue Team 向けの中心構成は、単一の Elastic Cloud デプロイメント をベースにしたマルチテナント設計でした。記事では、40の defending Blue Teams を支える単一デプロイメントが中核として紹介され、チームごとの分離には Kibana Spaces と datastream namespaces が使われていたと説明されています。 この設計の価値は、規模が大きいほどはっきりします。各チームに個別クラスタを割り当てれば分離はしやすい一方で、構築・更新・監視の負荷が急増します。逆に、単一デプロイメントに集約しつつ Spaces と権限制御でチーム単位に分ければ、標準化しやすく、全体運用も現実的になります。DCM26は、このマルチテナント方式を大規模演習に適用した実例でした。 データ分離の仕組み この構成では、見た目のワークスペースを分けるだけでなく、データの流れ自体もチーム単位で整理されていました。各チームには bt_01_deployed や bt_01_hostnation のような datastream namespace が割り当てられ、読み取り権限もその namespace に応じて制御されていました。認証は Keycloak SSO と Elasticsearch の role mapping でつながれており、どのユーザーがどのチーム空間に入れるかも明確に管理されていました。 この点が重要なのは、マルチテナント環境で本当に避けたいのは UI 上の見え方ではなく、データ境界の破れ だからです。DCM26では、Spaces・データストリーム・認証・権限の各レイヤーをそろえることで、演習に必要な厳格な分離を成立させていました。 事前検証と負荷テスト このアーキテクチャは、ぶっつけ本番で採用されたわけではありません。事前には 50 の Kibana Spaces を用意し、space-scoped Fleet policies を作成したうえで、6,000台の EC2 インスタンスを使った負荷検証が行われました。そこで確認されたのは、データ漏えいが起きないこと、Fleet ポリシー更新が 60 秒以内に伝播すること、space ごとに絞った検索が高負荷でも高速に動作することなどです。 また、6,000台を一度に起動しようとすると AWS EC2 API のレート制限に当たるため、500台ずつ段階的に起動し、間に 5 分のクールオフを挟む形で展開していました。こうした地道な調整も含めて大規模構成を実運用レベルに引き上げていた点は、この事例の大きな価値です。 演習向けの防御設定 Blue Team には、System、Elastic Defend、Windows event forwarding、Auditd、Network Packet Capture などの統合が配布されていました。ただし、 Elastic Defend はそのままだと防御力が高すぎるため、演習中は Prevent mode を無効にし、Detect-only mode で使われていました 。さらに Memory Threat Prevention and Detection も、演習の大部分では無効化されていました。 ここからわかるのは、DCM26が単に「製品機能を最大限見せる場」ではなかったということです。重要だったのは、防御側がきちんと検知し、判断し、対応する訓練を成立させることでした。そのために、製品の強さをあえて制限する判断が取られていたのです。 Red TeamとNSOCの基盤 Blue Team 向けの中心基盤とは別に、Red Team 向けの専用 Elastic デプロイメントと、NSOC 向けの専用デプロイメントも用意されていました。Red Team 側では、Tuoni という C2 フレームワークの状態、ビーコンのコールバック、攻撃オペレーションの進行状況を観測するための基盤として Elastic が使われていました。 一方の NSOC では、演習全体のヘルス状況やセキュリティ監視に加え、AI利用の監査も対象に含まれていました。特に Bedrock API の呼び出しは CloudWatch に記録され、それが NSOC 側の Elastic デプロイメントから観測できるようになっていました。AIもまた、監視されるべき運用対象として扱われていたわけです。 AI活用のガバナンス DCM26では AWS Bedrock を基盤として AI を活用していましたが、運用はかなり慎重に設計されていました。Bedrock Guardrails により、ヘイト、侮辱、性的内容、暴力といった不適切コンテンツ、PII、さらに実際の機密作戦や現実世界の軍事活動に関わる話題を制限していました。 この点は、企業で生成AIを導入するときにも重要です。先に問われるのは「どれほど賢いか」ではなく、「何を扱わせてよいか」「誰が使ったかを追跡できるか」「扱ってはいけない情報に触れないか」です。DCM26は、AIの性能以前に、AIを安全に運用するための条件を固めていた事例として読めます。 Attack Discoveryの役割 演習中、Blue Team は大量のアラートに向き合う必要がありました。そこで有効だったのが Attack Discovery です。複数のアラートを相関し、攻撃の流れをストーリーとして整理することで、平均対応時間の短縮や alert fatigue の軽減に役立ったと説明されています。 ここでの役割は、すべてを自動で解決することではありません。ばらばらのシグナルを整理し、何から見るべきかを判断しやすくすることです。つまり、防御側の判断を置き換えるのではなく、 判断しやすい状態を作る ための支援として位置づけられていました。 3つのAI活用レイヤー DCM26のAI活用を理解するうえでは、この3つを混ぜないことが大切です。まず Elastic AI Assistant や Attack Discovery は、Elastic Security の標準機能として、防御側の調査やアラート理解を助ける役割を担っていました。 一方で Agent Builder は、役割別のカスタムAIエージェントを作るために使われていました。全参加者向けの IT サポートを担う GrantPT 、White Team 向けの採点支援を担う RefPT 、Red Team 向けの攻撃支援を担う Red Rock がその例です。GrantPT は手順書や過去のサポートチケットを参照し、RefPT は提出レポートや演習イベントをもとに採点を支援し、Red Rock は脆弱性や攻撃ベクトルの知識を使って Red Team を助けていました。 さらに Tines は AI そのものではなく、自動化フローの基盤として使われていました。サポート要求が発生すると Tines が動き、Bedrock AI と連携しながら過去の解決策を参照して応答を補助し、サポートキューの負荷を下げていました。つまり、Elastic AI Assistant は調査支援、Agent Builder は役割特化のエージェント構築、Tines は運用自動化と、それぞれの役割は明確に分かれています。 感情分析という試み 演習中には RocketChat の会話全体を Elastic に取り込み、Named Entity Recognition と感情分析を通じて、会話内容やチーム状態の変化を捉える取り組みも行われました。攻撃や障害だけでなく、参加者側のストレスや混乱の兆候も、運営が把握する対象に含まれていたわけです。 大規模演習では、システム異常だけでなく、人の疲労や情報過多も成果に直結します。Elastic がログ以外のテキストデータも同じ基盤で扱えることが、こうした運営の立体化につながっていました。 まとめ DCM26が示したのは、AIの価値は単にモデルを導入することでは生まれない、ということです。大規模データを処理できる基盤、チームごとに厳密に分離された設計、アラートを文脈化する機能、役割別に作られたエージェント、そして AI 利用そのものを監査できる運用モデル。これらがそろってはじめて、AIは実戦的な価値を持ちます。 Elastic はこの演習で、単なるログ基盤や SIEM としてではなく、可視化・検知・AI支援・自動化連携をつなぐ中核として機能していました。ただしそれは Elastic 単独で完結した話ではなく、AWS Bedrock、Tines、Tuoni などとの連携も含めて成立した構成です。DCM26は、AI時代のセキュリティ基盤に必要なのが強い機能の寄せ集めではなく、安全に運用できる一貫した設計 であることを示した事例だと言えるでしょう。 用語集 Elastic 検索、ログ分析、セキュリティ監視、可観測性などをまとめて扱えるプラットフォームです。大量のデータを集めて、見える化し、分析し、異常や攻撃の兆候を見つけるために使われます。 仮想システム 物理的な専用機器ではなく、ソフトウェア上で動くサーバーや端末環境のことです。クラウドや仮想化技術を使って、多数のシステムを柔軟に用意できます。 イベント システム上で起きた出来事を記録したものです。たとえばログイン、ファイル作成、通信、エラー発生などがイベントです。 EPS（Events Per Second） 1秒あたりに処理されるイベント数です。ログやセキュリティイベントがどれくらい大量に流れているかを見る目安です。 マルチテナント 1つの大きなシステムを、複数のチームや組織で共用する考え方です。たとえば1つの建物の中に、別々の会社がそれぞれ専用の部屋を持って入っているイメージです。 テナント マルチテナント環境の中で、各チームや各組織に割り当てられた独立した利用領域のことです。 アクセス制御 誰がどのデータや機能を使えるかを決める仕組み全体を指します。 インフラ自動化 サーバー構築、設定反映、ソフトウェア配布などを手作業ではなく自動で行う考え方です。大規模環境ほど重要になります。 Kibana Elasticに入ったデータを画面で見たり、検索したり、グラフやダッシュボードを作ったりするための画面ツールです。 Kibana Spaces Kibanaの中で、チームごとに画面やダッシュボード、設定を分けるための仕組みです。同じKibanaを使っていても、チームAにはA用の画面、チームBにはB用の画面を見せられます。 Keycloak SSOやユーザー認証、権限管理を行うためのソフトウェアです。誰がどのサービスに入れるかを一元的に管理できます。 SSO（Single Sign-On） 一度のログインで、複数のシステムを使えるようにする仕組みです。何度も別々にIDとパスワードを入れなくて済みます。 自動スケーリング（Autoscaling） 負荷が増えたときに、必要なリソースを自動で増やす仕組みです。逆に負荷が減れば縮小できます。 RBAC（Role-Based Access Control） 役割ベースのアクセス制御です。「この人はこの役割だから、このデータだけ見られる」というように、ロールに応じて権限を決める考え方です。 DLS（Document Level Security） ドキュメント単位のアクセス制御です。同じデータベースの中でも、「このユーザーにはこの文書だけ見せる」「別の文書は見せない」と細かく制御できます。 ドキュメント Elasticの中に保存される1件1件のデータのことです。たとえば1つのログ記録、1つのイベント記録が1ドキュメントになります。 AIガバナンス AIを安全かつ適切に使うための管理の考え方です。何をAIにさせるか、何を禁止するか、記録をどう残すかなどを決めます。 PII（Personally Identifiable Information） 個人を特定できる情報のことです。氏名、電話番号、メールアドレスなどが代表例です。 監査ログ 誰が、いつ、何をしたかを記録するログです。あとで追跡や確認ができるように残します。 CloudWatch AWS上のログやメトリクスを監視・保存するサービスです。 AWS Amazon Web Servicesの略です。Amazonが提供するクラウドサービス群のことです。 IaC（Infrastructure as Code） インフラをコードで管理する方法です。サーバーや設定を手作業で作るのではなく、設定ファイルやコードで自動的に作れるようにします。 Terraform IaCを実現する代表的なツールの1つです。クラウド環境やインフラ構成をコードで定義し、同じ環境を何度でも再現できます。 HashiCorp Vault パスワード、トークン、認証情報などの秘密情報を安全に保管・配布するためのツールです。 Catapult 記事内では、監視エージェントの展開を自動化するために使われたツールとして登場します。大量の環境に同じ設定を一括で配る役割を持ちます。 Fleet エージェントと通信し、設定を配信するための仲介サーバーです。 ポリシー システムに適用する設定ルールのことです。たとえば「このログを集める」「この挙動を監視する」などを定義します。 エージェント 各サーバーや端末に入れて、ログ収集や監視を行う小さなプログラムです。 データストリーム（Data Stream） 時系列で増え続けるデータを効率よく保存・管理するための仕組みです。ログや監視データのように、時間とともにどんどん追加されるデータに向いています。 ILM（Index Lifecycle Management） インデックスを、作成から削除まで自動で管理する仕組みです。たとえば「古いデータは圧縮する」「30日後に削除する」といったルールを自動化できます。 インデックス Elasticでデータを保存する単位です。本でいうと「1冊の本」、データベースでいうと「表」に近いイメージです。 ストレステスト 高い負荷をかけて、システムが耐えられるかを確認するテストです。本番前に限界や弱点を見つけるために行います。 EC2 AWS上で仮想サーバーを起動できるサービスです。必要な台数のサーバーをクラウド上で柔軟に用意できます。 Attack Discovery 多数のアラートやイベントを関連づけて、「1つの攻撃の流れ」として整理するElasticの機能です。ばらばらの警告を、そのままではなく意味のある攻撃ストーリーにまとめます。 アラート 「異常の可能性がある」「確認が必要」とシステムが知らせる通知です。 Initial Access 攻撃者が最初にシステムへ入り込む段階です。たとえば不正ログインや脆弱性悪用が含まれます。 Lateral Movement 攻撃者が、最初に侵入した1台から別の端末やサーバーへ横に広がっていく動きです。 Exfiltration データの持ち出しです。攻撃者が機密情報を外部へ送る段階を指します。 MITRE ATT&CK サイバー攻撃者の手口を体系的に整理した有名なフレームワークです。攻撃の段階や方法を共通言語として扱うためによく使われます。 相関分析 ばらばらに見える複数のデータの関係を見つける分析方法です。個別では小さな異常でも、つなげると大きな攻撃の流れが見えることがあります。 Agent Builder 用途ごとに専用のAIエージェントを作るための機能です。利用者、目的、参照データに応じて、役割別のAIを設計できます。 AIエージェント 特定の目的や役割を持って動くAIです。単なる雑談AIではなく、「サポート担当AI」「分析担当AI」のように仕事が決まっています。 Jira チケット管理や問い合わせ管理によく使われるツールです。障害対応やタスク管理で広く使われています。 SOP（Standard Operating Procedure） 標準作業手順書です。日常運用やトラブル対応で「この順番で対応する」という標準手順をまとめた文書です。 脆弱性 システムやソフトウェアにある弱点のことです。攻撃者に悪用される可能性があります。 可観測性（Observability） システムの状態を、外から十分に把握できるようにする考え方です。問題が起きたときに「今どこで何が起きているか」を見えるようにします。 Blue Team 防御側チームです。攻撃を検知し、調査し、守る役割を担当します。 Red Team 攻撃側チームです。実際の攻撃者を模して侵入や攻撃を行い、防御側の弱点を明らかにします。 NSOC ネットワークやセキュリティの運用全体を監視・統制する役割を持つ運用センターを指します。ここでは演習全体を見守る統制側として使われています。 White Team 演習の運営や審判を行うチームです。ルール管理や評価、全体統制を担当します。 Elastic Defend Elasticのエンドポイント防御・可視化機能です。端末上の挙動を監視し、脅威検知や調査に役立てます。 PCAP ネットワーク通信の中身を記録したデータ形式です。どんな通信が流れていたかを詳しく調べるときに使います。 感情分析 テキストから、その内容がポジティブかネガティブか、怒りや疲労の傾向があるかなどを分析する方法です。 Rocket.Chat チャットやチームコミュニケーションに使うツールです。Slackのような役割を持つソフトウェアです。 ゼロショットNLP 事前に細かく追加学習させていない分類でも、AIが文章の意味を見てテーマやカテゴリを判断する方法です。 NLP（Natural Language Processing） 自然言語処理のことです。人間の言葉をAIやコンピュータで扱えるようにする技術分野です。 ベクトル化 文章や画像を、AIが比較しやすい数値の形に変換することです。 クラスタリング 似ているデータを自動でグループ分けする分析手法です。 人的指標 システムの数字だけではなく、人の疲労、混乱、士気の変化などを表す観点です。運用の現場では、こうした人の状態も重要な判断材料になります。 The post DCM26事例：国防省主催の大規模演習を支えたElasticセキュリティの基盤設計とAI支援 first appeared on Elastic Portal .

はじめに 2026年3月26日、初の試みとして、リクルート本社オフィスにて 「産学連携技術交流会」 を開催しました。本イベント