みなさんこんにちは！ワンキャリアでOCIDチームに所属しているエンジニアの吉田（X： @yoshida_baystar ）です。 今回はワンキャリアエンジニアのターミナルをご紹介します！

Linuxは、多くの企業システム、クラウド環境、コンテナ基盤で使われています。 そのため、Linuxカーネルに深刻な脆弱性が見つかると、影響はとても大きくなります。 Elastic Security Labs は、Linuxカーネルの権限昇格脆弱性である Copy Fail (CVE-2026-31431) 、Copy Fail 2、そして DirtyFrag を分析しました。これらは、Linuxの page cache に関係するバグを悪用し、通常ユーザーから root権限 を取得できる可能性がある攻撃です。 特に Copy Fail (CVE-2026-31431) は実際の攻撃で悪用されたことが報告されており、米国CISAの Known Exploited Vulnerabilities (KEV) カタログ にも追加されています。KEVカタログに載るということは、「机上の脆弱性」ではなく「現実に攻撃で使われている脆弱性」であることを意味します。米国の連邦機関は期限内のパッチ適用が義務付けられるレベルであり、民間企業にとっても優先対応すべき強いシグナルです。 この記事では、この攻撃をセキュリティ初心者にもわかるように整理しながら、Elastic Securityがどのように脅威を分析し、検知につなげているのか、そして Elasticが公開している検知ルール を紹介します。 目次 まず、何が危険なのか？ page cache とは何か？ page cache corruption とは？ Copy Fail は何をするのか？ DirtyFrag は何が違うのか？ ⚠️ ここが最重要：Copy Fail のパッチだけでは不十分 なぜ Elastic の分析が重要なのか？ Elastic が公開した検知ルール5本 1. Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket 2. Suspicious SUID Binary Execution 3. Suspicious Kernel Feature Activity 4. Namespace Manipulation Using Unshare 5. Privilege Escalation via SUID/SGID 5本のルールがどう連携するか Elastic の強み：すべての検知ルールが GitHub で公開されている これがなぜ重要なのか？ 日本のユーザーにとっての意味 ビジネス視点でなぜ重要なのか？ まとめ：Elastic Security は「攻撃の形」ではなく「攻撃の動き」を見る 参考リンク まず、何が危険なのか？ 今回のポイントは、攻撃者がLinux上で root権限 を取得できる可能性があることです。 rootとは、Linuxにおける最も強い権限を持つユーザーです。 たとえるなら、ビル全体のマスターキーを持つ管理者のような存在です。 通常ユーザーは、自分の部屋や許可された場所にしか入れません。 しかしrootは、システム全体の設定変更、ファイルの読み書き、プロセスの停止、ユーザー作成など、多くの操作ができます。 つまり、攻撃者がroot権限を取ると、次のようなことが可能になります。 機密ファイルを読む セキュリティツールを止める マルウェアを設置する ログを改ざんする 他のシステムへ侵入する足がかりを作る これは、単なる「1台のLinuxサーバーの問題」ではありません。 企業のクラウド環境、コンテナ基盤、業務システム全体に影響する可能性があります。 page cache とは何か？ 今回の攻撃を理解するために、まず page cache を理解する必要があります。 page cacheとは、Linuxがファイルアクセスを速くするために使うメモリ上の一時的な保管場所です。 たとえば、図書館をイメージしてください。 本棚にある本が「ディスク上のファイル」だとします。 でも、よく読まれる本を毎回本棚まで取りに行くのは面倒です。 そこで図書館員は、よく使う本のコピーを机の上に置いておきます。 この「机の上のコピー」が、Linuxでいう page cache です。 たとえ Linux 本棚の本 ディスク上のファイル 机の上のコピー page cache 図書館員 Linuxカーネル 本を読む人 アプリケーション 通常、page cacheは便利な仕組みです。 ファイルを毎回ディスクから読むより、メモリから読んだ方が速いからです。 しかし、今回のような脆弱性では、この「メモリ上のコピー」が悪用されます。 page cache corruption とは？ page cache corruption とは、簡単に言うと、Linuxが信頼しているメモリ上のファイルコピーを不正に書き換えることです。 重要なのは、攻撃者が必ずしもディスク上の本物のファイルを書き換えるわけではない、という点です。 本物のファイルは変わっていないように見えます。 しかし、Linuxが実際に使うメモリ上のコピーだけが壊されている可能性があります。 これは非常に厄介です。 なぜなら、ファイルの改ざんチェックをしても、ディスク上のファイルは正常に見えることがあるからです。 一方で、システムは壊されたpage cacheの内容を使ってしまう可能性があります。 たとえるなら、会社の正式な契約書は金庫の中で無事なのに、担当者が机の上に置いていたコピーだけがこっそり書き換えられている状態です。 担当者がそのコピーを信じて処理を進めると、間違った判断につながります。 Copy Fail は何をするのか？ Elasticの説明によると、Copy Fail は Linuxカーネルの暗号処理（authencesn テンプレート）に関係するロジックバグです。AF_ALG と splice() という Linux の正規機能を組み合わせることで、読み取り可能なファイルのpage cacheに対して、制御された4バイトの書き込みを行えると説明されています。 ここで重要なのは、これが setuidバイナリ に対して使われるという点です。 setuid バイナリとは 実行したユーザーではなく、ファイルの所有者の権限で動く特殊なプログラムです。 たとえば /usr/bin/su は所有者がrootで、setuid が設定されているため、認証処理などの一部の処理をroot権限で実行できます。もちろん、通常はパスワード確認などの認証があるため、誰でも自由にrootになれるわけではありません。 しかし、この「root権限で動く部分」こそが攻撃者の標的になります。Copy Fail のような攻撃では、ディスク上のファイルを直接書き換えるのではなく、page cache上のバイナリ内容を壊すことで、root権限で実行される処理を悪用しようとします。 実際に Copy Fail では、/usr/bin/su のようなsetuidバイナリのメモリ上の見え方を壊し、 ディスク上のファイルを変更せずに権限昇格 につなげることができます。公開されている攻撃コードは、わずか732バイトのPythonスクリプトで、Ubuntu、Amazon Linux、RHEL、SUSE といった主要ディストリビューションで動作します。 ここで重要なのは、攻撃者が「怪しいマルウェア」だけを使っているわけではないことです。 AF_ALG も splice() も、Linuxに存在する正規の仕組みです。 つまり攻撃は、完全に外部から見て明らかに怪しい動作だけで成り立っているわけではありません。 正規のLinux機能を組み合わせて、カーネルの細かいバグを突いています。 これが、検知を難しくします。 DirtyFrag は何が違うのか？ DirtyFragも、page cache corruption を悪用する Linuxカーネルの権限昇格攻撃です。 基本の考え方は Copy Fail と似ていますが、 攻撃経路がネットワークスタックに広がっている 点が大きく異なります。 Elasticのブログによると、DirtyFragには2つの経路があります。 経路 使われる仕組み 攻撃対象 結果 ESPパス AF_NETLINK 経由のXFRM SA /usr/bin/su suを最小限のroot shell ELFで上書き RxRPCパス（フォールバック） AF_RXRPC + pcbc(fcrypt) /etc/passwd rootのパスワードフィールドをクリア /etc/passwd のrootパスワードフィールドがクリアされると、環境によってはパスワードなしでrootとして認証が通ってしまう可能性があります。 実際の挙動は、PAM や SSH の設定、shadow ファイルの運用状況によって変わります。しかし、いずれにしても、root認証の前提を壊す重大な改ざんであることに変わりはありません。 さらに、両方の経路ともに unshare(CLONE_NEWUSER | CLONE_NEWNET) を使って namespace capability を取得する前段が必要です。これは、後述する検知ロジックで重要なポイントになります。 ⚠️ ここが最重要：Copy Fail のパッチだけでは不十分 Elasticのブログが警告している最も重要なポイントは次のことです。 DirtyFrag は algif_aead モジュールに依存しません。 つまり、Copy Fail の緩和策（algif_aead を無効化する）だけを適用したシステムは、依然としてDirtyFragに脆弱なままです。 「Copy Fail対策はやったから安心」という思い込みが、最も危険な状態を生みます。 両方の脆弱性に対して、 それぞれ独立した対策が必要 です。 なぜ Elastic の分析が重要なのか？ ここからが、Elastic Securityを理解するうえで大事なポイントです。 Elasticは、単に「特定の攻撃コードを見つけましょう」という見方だけをしていません。 セキュリティ研究者は、新しい脆弱性が見つかると、しばしば PoC（Proof of Concept） と呼ばれる実証コードを公開します。これは「この攻撃が本当に可能であることを示すデモコード」であり、防御側が脆弱性を理解し、対策を検証するために使われます。 しかし、攻撃者はこの実証コードをそのままの形で使うとは限りません。 Pythonで書かれたコードを、GoやRustやCに書き換えることもできます。 ファイル名やプロセス名を変えることもできます。実行方法を少し変えることもできます。 実際、Copy Fail はすでに Python / Go / Rust / C / Metasploit など、複数の言語・フレームワークで実装が公開されており、DirtyFrag も C言語版の実装が公開されています。 そのため、 特定の攻撃コードの見た目だけを検知していると、少し変えられただけで見逃す可能性があります 。 Elasticが重視しているのは、攻撃の primitive と behavior です。 primitive とは、攻撃を構成する小さな技術的な部品のことです。 たとえば、ビルへの侵入で考えると、攻撃全体は「不正侵入」です。 その中のprimitiveは、次のような小さな行動です。 鍵をこじ開ける 監視カメラを避ける 裏口を使う 管理室に入る Linux攻撃で言えば、primitiveは次のようなものです。 AF_ALG を使う splice() を使う page cache を壊す setuidバイナリを悪用する unshare() でnamespaceを作る Elasticは、攻撃コードそのものだけでなく、こうした攻撃の部品や行動パターンを見ようとしています。 これは、現代のセキュリティ検知において非常に重要です。 Elastic が公開した検知ルール5本 今回 Elastic Security Labs は、Copy Fail / DirtyFrag に対応する検知ルールを公開しました。 ここで重要なのは、 これらのルールはすべて GitHub で誰でも見られる ということです（後述）。 以下、5本のルールがそれぞれ「何を検知するか」を簡潔に紹介します。 1. Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket 何を検知するか: 非rootユーザーが AF_ALG ソケット（暗号処理用の特殊なソケット）と splice() を組み合わせて使い、その後 root 権限のプロセス実行やシェル起動につながる流れ。 攻撃のどこで効くか: Copy Fail の最も核心的なプリミティブを直接捉えます。 前提条件: このルールを有効に活用するには、Linux 上で auditd 系のログを Elastic に取り込んでいる必要があります。具体的には、Elastic Agent の Auditd Manager integration や Auditbeat の設定が必要です。これらがない環境では、socket や splice のような低レベルな syscall の動きは見えません。 🔗 GitHubでルールの実物を見る 2. Suspicious SUID Binary Execution 何を検知するか: su、sudo、pkexec、passwd などのSUIDバイナリが、不審な親プロセス（PythonやRubyなどのスクリプトランタイム、/tmp や /dev/shm といったユーザー書き込み可能パスからの実行）から、最小限の引数で呼び出されるパターン。 攻撃のどこで効くか: Copy Fail / DirtyFrag の両方の 最終段階 （root権限取得の瞬間）を捉えます。auditd が入っていない環境でも、プロセス実行イベントだけで動作するため、適用範囲が広いのが特徴です。 🔗 GitHubでルールの実物を見る 3. Suspicious Kernel Feature Activity 何を検知するか: sysctl などによるカーネル機能の不審な操作。攻撃者が防御機構を無効化したり、カーネル動作を変更したりする動きを捉えます。 位置づけ: このルールは Copy Fail / DirtyFrag 専用というより、攻撃者がカーネル機能を不審に操作する動きを広く見るための補助的な検知です。今回のようなカーネル悪用の文脈でも、関連する不審な操作を見つけるための追加レイヤーとして役立ちます。 🔗 GitHubでルールの実物を見る 4. Namespace Manipulation Using Unshare 何を検知するか: unshare コマンドや syscall によるユーザーネームスペース（特に CLONE_NEWUSER | CLONE_NEWNET）の作成と、その直後の root プロセス実行・setuid(0) の相関。 攻撃のどこで効くか: DirtyFrag 固有の前段 を捉えます。DirtyFrag は namespace の取得が必須なので、ここを潰すと攻撃チェーン全体が成立しなくなります。 前提条件: このルールも、syscall レベルの検知部分は auditd 系のログが必要です。プロセス実行イベントの部分は Elastic Agent / Endpoint で取得できます。 🔗 GitHubでルールの実物を見る 5. Privilege Escalation via SUID/SGID 何を検知するか: SUID/SGIDバイナリを悪用した権限昇格全般のパターン。Copy Fail / DirtyFrag に限らず、類似の権限昇格手法を広くカバーします。 攻撃のどこで効くか: 汎用的な権限昇格の最終段階。Copy Fail / DirtyFrag の派生や、まだ公開されていない類似手法にも備える保険的なルールです。 🔗 GitHubでルールの実物を見る 5本のルールがどう連携するか これらのルールは、それぞれ独立して動きますが、 攻撃の異なる段階を多層的にカバーする設計 になっています。 攻撃者が1つの段階を回避しても、別の段階で検知できる 多層防御（defense in depth） の考え方です。 Elastic の強み：すべての検知ルールが GitHub で公開されている ここで、Elastic Security の重要な特徴をお伝えします。 Elastic は、商用製品の検知ルールをすべて GitHub で公開しています。 リポジトリはこちらです： 🔗 elastic/detection-rules このリポジトリには、Elastic Security で使われる検知ルールが TOML 形式で格納されており、 誰でも自由に閲覧・Fork・コメント・Pull Request 可能 です。 これがなぜ重要なのか？ セキュリティ運用において、検知ルールの中身がわからないことは、いくつもの問題を引き起こします。 検知ルールが見られない場合 検知ルールが公開されている場合 アラートが出たが、なぜ発火したかわからない ルールのロジックを読んで理由を理解できる 誤検知が出ても、チューニングできない 条件を読んで、自社環境向けに例外を追加できる 「ベンダーを信じるしかない」状態 自分でレビューして納得できる 検知漏れがあっても、原因がわからない ロジックの穴を発見し、改善提案できる コミュニティ知見が共有されない OSSとしてコミュニティに還元できる なお、検知ルールを公開しているベンダーは Elastic だけではありません。Microsoft Sentinel も Analytics rules を GitHub で公開しており、透明性の高いアプローチを取っています。一方、多くの商用 EDR/SIEM 製品では検知ロジックが非公開で、ユーザーがルールの中身を確認できないことも珍しくありません。Elastic は早い段階からこの公開方針を一貫して続けている点が特徴です。 日本のユーザーにとっての意味 日本では、Elastic を完全に理解しているエンジニアはまだ多くありません。 だからこそ、 ルールがオープンソースとして公開されている ことの価値は大きいです。 英語のブログを完全に理解できなくても、 TOMLファイルを読めば検知ロジックがわかる 社内SOCのナレッジとして ルールを写経・改造して学べる 自社環境特有の誤検知に対して 自分で例外条件を追加できる 日本語コミュニティで ルールの解釈を議論できる ビジネス視点でなぜ重要なのか？ この話は、セキュリティ研究者だけのものではありません。 企業にとって重要なのは、次の3つです。 1つ目は、被害の早期発見です。 root権限を取られると、攻撃者はより深くシステムに入り込めます。早く気づければ、被害を小さくできます。 2つ目は、調査時間の短縮です。 SOCやセキュリティ担当者は、毎日多くのアラートを見ています。Elastic Securityのように、攻撃の流れを見せられる仕組みがあると、「これは何が起きているのか」を早く理解できます。 3つ目は、未知・変種への対応力です。 攻撃者は攻撃コードを書き換えます。ツール名も変えます。実行方法も変えます。 しかし、攻撃に必要な基本行動は大きく変わりにくいです。 だからこそ、Elasticが重視している「ふるまい検知」は、ビジネスにとっても価値があります。 まとめ：Elastic Security は「攻撃の形」ではなく「攻撃の動き」を見る Copy Fail や DirtyFrag は、Linuxカーネルの細かいバグを悪用する高度な攻撃です。 しかし、初心者向けに一言でまとめるなら、こう言えます。 Linuxが高速化のために使っている page cache を悪用し、メモリ上のファイル内容を壊すことで、通常ユーザーから root権限を取る攻撃です。 そして、Elastic Security Labs の重要な貢献は、これを単なる脆弱性情報として紹介するだけでなく、 実際の検知ルールに落とし込み、GitHub で公開している 点です。 特定の攻撃コードだけを見るのではなく、攻撃に必要な primitive や behavior を見る。 そして、そのロジックをオープンにすることで、コミュニティ全体の防御力を底上げする。 これは、現代のセキュリティ運用においてとても重要な考え方です。 攻撃者はコードの見た目を変えられます。 しかし、root権限を取るために必要な行動の流れは、完全には隠しにくいです。 Elastic Security は、その流れをデータから見つけるためのプラットフォームです。 そして、その検知ロジックを オープンに、透明に、コミュニティと共に進化させている のが、Elastic の大きな強みです。 参考リンク Elastic Security Labs 原文ブログ: Copy Fail and DirtyFrag: Linux Page Cache Bugs in the Wild Elastic の検知ルールリポジトリ: elastic/detection-rules (GitHub) CISA Known Exploited Vulnerabilities Catalog: CISA KEV この記事は、Elastic Security Labs が公開した英語ブログ「Copy Fail and DirtyFrag: Linux Page Cache Bugs in the Wild」をもとに、日本のElastic利用者向けに整理・補足したものです。 The post Copy Fail / DirtyFrag を検知する：Linux カーネルの page cache 攻撃と5つの検知ルール first appeared on Elastic Portal .

Elastic がバージョン 9.4 をリリースしました。セキュリティ自動化エンジン「Workflows」の正式版リリースを筆頭に、AI によるルール生成・専門知識モジュール（Skills）・クエリ言語 ES|QL の大幅強化など、幅広い領域にわたるアップデートが含まれています。本記事では注目機能を速報でまとめます。 目次 1. Elastic Workflows が正式版（GA）に 2. Elastic AI Agent に専門知識モジュール「Skills」が登場 3. AI による ES|QL 検知ルール自動生成 4. ES|QL クエリ言語の強化 5. ベクトル検索の高速化 6. Kibana の強化 7. Observability：メトリクス・時系列分析の強化 8. セキュリティ：エンティティ管理の深化 まとめ：9.4 の位置付け 参照リンク 1. Elastic Workflows が正式版（GA）に セキュリティ運用の自動化エンジン「Elastic Workflows」が 9.3 の試験公開（Tech Preview）から正式版に昇格しました。 アラートの受信から、ケース作成・担当者割当・Slack 通知・外部システム連携までを YAML または自然言語で定義し、Kibana 内で完結して実行できます。データ移動が不要な点が他の SOAR ツールとの大きな違いです。 主な追加機能： ケース管理ステップが 4 種類 → 25 種類に拡張 ：担当者割当・証拠添付・重要度設定・タグ管理など、インシデントの全ライフサイクルに対応 Human-in-the-Loop（ waitForInput ） ：AI が調査・分類を行い、エスカレーション判断だけをアナリストに委ねる仕組みを正式サポート ワークフローの組み合わせ（ workflow.execute ） ：マルウェア対応・フィッシング対応などを独立したモジュールとして再利用可能に 制御フロー強化 ：switch（多方向分岐）・while（ループ）・loop.break/continue を追加 自然言語でのワークフロー作成 （Tech Preview）：攻撃対応シナリオを日本語・英語で説明するだけで YAML を自動生成 最小構成のワークフロー例（YAML）： name: Critical アラート対応ワークフロー enabled: true triggers:   - type: alert        # アラート発火を起点に起動 steps:   - name: create_case     type: cases.createCase     with:       owner: securitySolution       title: "{{ event.rule.name }} - {{ event.alerts[0].host.name }}"       severity: high       tags:         - auto-triage 📎 参照： Elastic Workflows GA: automation where your security data already lives 2. Elastic AI Agent に専門知識モジュール「Skills」が登場 従来の AI アシスタントは「すべての知識を1つのプロンプトに詰め込む」設計でした。9.4 では、タスクに応じて専門知識モジュール（スキル）をオンデマンドで切り替える「Skills」アーキテクチャが導入されました。 コンテキストウィンドウを知識ではなく実データに使える分、各スキルの回答精度が向上します。スキルを追加しても既存スキルの品質が落ちない設計が特徴です。 9.4 で搭載された 5 つのセキュリティスキル： スキル 役割 Detection Rule Edit 自然言語から ES|QL 検知ルールを生成・編集 Alert Analysis アラートのトリアージ・関連アラート探索・脅威インテル照合 Threat Hunting 仮説駆動型の脅威ハンティング（横移動・C2 テンプレート内蔵） Entity Analytics ユーザー・ホストのリスクスコア・行動パターンのプロファイリング Security ML Jobs 機械学習ジョブの異常をエンティティコンテキストと相関させて調査 このほか、Kibana ダッシュボード作成・ワークフロー YAML 生成・エンティティ関係グラフ作成の 3 つのプラットフォームスキルも追加されました。 実際の使い方の例（自然言語プロンプトを送るだけ）： プロンプト例 起動するスキル 「アラート 82a1f を分析して。認証情報窃取キャンペーンと関連してる？」 Alert Analysis 「過去7日間で侵害されたホストからの横移動をハントして」 Threat Hunting 「今週最もリスクの高いユーザーとその要因を教えて」 Entity Analytics 「svc-backup-prod に関連する異常は何？」 Security ML Jobs 📎 参照： One agent, the right skills: Elastic Security 9.4 brings domain expertise on demand to every SOC workflow 3. AI による ES|QL 検知ルール自動生成 攻撃の挙動を自然言語で記述するだけで、本番対応の ES|QL 検知ルールを AI が自動生成します。ルール作成画面から「AI rule creation」を選択するだけで使用できます。 生成されるもの： ES|QL クエリ（構文検証済み） MITRE ATT&CK マッピング 重要度・リスクスコア タグ・スケジュール設定 生成後はチャット形式で反復的に調整でき、有効化前に自環境の実ログでプレビュー確認が可能です。 実際のプロンプト例（公式ブログより）： 「Okta で、同一ユーザー＆同一 IP から：3 回以上の認証失敗、1 回以上の MFA 失敗、ログイン成功、その後に権限付与またはポリシー更新。この全シーケンスが揃った場合に、認証情報窃取の成功攻撃として検知して」 これだけで、STATS で各段階をカウントして閾値判定する複雑な ES|QL クエリ・MITRE ATT&CK マッピング（T1110.004 Credential Stuffing・T1078 Valid Accounts）・重要度設定までが一括生成されます。 ⚠️ Enterprise ライセンスが必要です。 📎 参照： From plain English to production rule: AI-native Elasticsearch ES|QL detection in Elastic Security 4. ES|QL クエリ言語の強化 Elastic のパイプライン型クエリ言語 ES|QL に 4 つの大きな機能が追加されました。 サブクエリ（Subqueries） ：異なるインデックスの複数クエリを 1 文で結合。例えばビジネスデータとサーバーログを時系列でまとめて分析できます。 FROM   (FROM ecommerce | EVAL domain = "business" | KEEP ts, domain, summary),   (FROM logs       | EVAL domain = "ops"      | KEEP ts, domain, summary) | SORT ts ロジカルビュー（Logical Views） ：複雑な集計ロジックを名前付きで保存し、ダッシュボード・アラート全体で再利用できます。SQL の VIEW に相当する概念で、ビュー定義を更新すれば参照する全ダッシュボードに即時反映されます。 -- ビューを定義（一度だけ） CREATE VIEW high_risk_users AS FROM .alerts-security* | WHERE risk_score > 70 | STATS ... -- 以降、複数のダッシュボードから FROM view_name で参照可能 FROM high_risk_users  -- 事前定義したビューを通常のインデックスのように利用 | WHERE @timestamp > NOW() - 24 hours | KEEP user.name, risk_score JSON 関数抽出 ：JSON 形式で格納されたフィールドの値を、再インデックスなしに直接クエリで取り出せます。スキーマが不定形なログデータの分析に有効です。 ROW raw = "{ \"user\": { \"name\": \"yamada\", \"id\": 42 }, \"source\": { \"ip\": \"10.0.0.1\" } }" | EVAL user_name = JSON_EXTRACT(raw, "user.name") | EVAL user_id = JSON_EXTRACT(raw, "user.id") | EVAL src_ip = JSON_EXTRACT(raw, "source.ip") | KEEP user_name, user_id, src_ip 実行結果： user_name | user_id | src_ip ----------+---------+----------- yamada | 42 | 10.0.0.1 パスは user.name のドット記法、 groups[0] のブラケット記法のどちらも利用できます。キーに . が含まれる場合は ['event.id'] のブラケット記法が必須です。 マッピング外フィールドへのアクセス （ SET unmapped_fields="load" ） ：インデックス定義に漏れていたフィールドも後から遡ってクエリ可能になりました（従来の「無知の崖」問題を解消）。 9.3のバージョン -- 従来：マッピング外のフィールドは結果に含まれない FROM my_unmapped_test | KEEP @timestamp, user, amount, department -- 9.4：SET ディレクティブで未マッピングフィールドも _source から取り出せる SET unmapped_fields="load"; FROM my_unmapped_test | KEEP @timestamp, user, amount, department 実行結果（ SET unmapped_fields="load" を指定した場合）： @timestamp | user | amount | department ---------------------+--------+--------+------------- 2026-05-06T13:00:00Z | tanaka | 320 | sales 2026-05-06T12:00:00Z | yamada | 150 | engineering "load" のほかに "nullify" （明示的に null を返す）も指定可能です。性能面では _source からの読み出しになるため、マッピング済みフィールドのクエリよりやや遅くなる点に注意が必要です。 📎 参照： What’s new in Elastic 9.4（公式ブログ） ・ ES|QL Logical Views 詳細ブログ ・ Elasticsearch リリースノート 5. ベクトル検索の高速化 AI ワークロード（RAG など）の基盤となるベクトル検索が大幅に強化されました。 DiskBBQ 改善 ：フィルター付きクエリのレイテンシを最低 3 倍改善 GPU 加速インデックス作成が GA 昇格 ：NVIDIA cuVS 統合により、セルフマネージド環境でインデックス速度が最大 12 倍、force merge が 7 倍高速化 量子化ビット数の選択肢拡大 ：1 ビットのみだったところ、2・4・7 ビットが追加。精度とサイズのバランスを調整可能に 量子化ビットの設定例（インデックス作成時）： PUT bbq_disk-index { "mappings": { "properties": { "my_vector": { "type": "dense_vector", "dims": 64, "index": true, "index_options": { "type": "bbq_disk", "bits": 2 // 1, 2, 4, 7 から選択（数値が大きいほど高精度・大容量） } } } } } ⚠️ GPU 機能はセルフマネージド環境（NVIDIA GPU 搭載サーバー）限定です。 📎 参照： What’s new in Elastic 9.4（公式ブログ） ・ DiskBBQ アーキテクチャ解説ブログ ・ GPU ベクトルインデックス加速ブログ ・ GPU ベクトルインデックス ドキュメント 6. Kibana の強化 AI によるダッシュボード作成 ：自然言語でダッシュボードのレイアウトや可視化を説明すると、AI が反復的に構築します。 Dashboards as Code ：ダッシュボードを API・JSON で定義・管理できます。Git による差分管理や CI/CD パイプラインでの自動デプロイが可能になりました。 API 経由でダッシュボードを作成する例： POST kbn:/api/dashboards { "title": "My first API dashboard", "panels": [ { "grid": { "x": 0, "y": 0, "w": 24, "h": 10 }, "type": "vis", "config": { "type": "xy", "title": "Total log entries over time", "layers": [ { "type": "line", "data_source": { "type": "esql", "query": "FROM kibana_sample_data_logs | STATS count = COUNT() BY BUCKET(@timestamp, 75, ?_tstart, ?_tend)" } } ] } } ] } Agent Builder の拡張 ：Skills・Attachments・Connectors・Plugins の 4 プリミティブが追加。長い会話でのコンテキスト管理（クエリ結果オフロード・コンパクション・要約）が改善され、マルチターン対話のコスト効率も向上しました。 📎 参照： What’s new in Elastic 9.4（公式ブログ） ・ Elastic AI Agent ドキュメント 7. Observability：メトリクス・時系列分析の強化 TSDB パフォーマンス改善 ：時系列メトリクスの保存効率が Prometheus 比 2.6 倍向上、クエリ速度は Prometheus/Mimir 比で最大 25 倍高速化。 ES|QL 時系列関数の追加 ：rate（変化率）・changes（変化量）・cumulative（累積）・trange（時間範囲）・clamp（値クリップ）が利用可能に。 PromQL のネイティブサポート ：Prometheus メトリクスを Elasticsearch に直接取り込み、Kibana 上で PromQL を実行できます。PromQL の結果を ES|QL パイプラインに流し込むことも可能です。 PromQL → ES|QL を組み合わせる例： # PromQL の結果を ES|QL コマンドにパイプして集計 PROMQL index=k8s step=1h bytes=(max by (cluster) (network.bytes_in)) | STATS max_bytes=MAX(bytes) BY cluster | SORT cluster 📎 参照： What’s new in Elastic 9.4（公式ブログ） ・ Elasticsearch リリースノート（TSDB・PromQL 詳細） 8. セキュリティ：エンティティ管理の深化 エンティティ統合（Entity Resolution） ：Okta・Microsoft Entra など複数の IdP に存在するアカウントを 1 つの従業員レコードに名寄せ。「同一人物が複数 ID を持っている」問題を解消し、横断的なリスク評価が可能になります。 統合のイメージ： 従来（バラバラに存在）            9.4（1つのレコードに統合） ─────────────────────────         ──────────────────────────── Okta:    t.yamada@co.jp     ┐ Entra:   tyamada            ├──→  山田 剛（Takeshi Yamada） GitHub:  yamada-t           │      └─ リスクスコアを統合計算 Slack:   takeshi.yamada     ┘      └─ クロスシステムのアラートを集約 動的ウォッチリスト（Dynamic Watchlists） ：組織的な重要度（例：役員・特権アカウント）をリスクスコアへの乗数として反映できます。 エンティティ起点のハンティングリード ：アラート起点の受動的調査から、リスクの高い行動パターンを事前に洗い出す能動的なハンティングへのシフトを支援します。 エンドポイント調査の拡張 ： Runscript Response Action + Script Library：感染端末へのリモートスクリプト実行とライブラリ管理 Memory Dump Response Action（Linux 対応）：マルウェア解析用のメモリ取得 Osquery 強化・Jumplists テーブル拡張：最近使用したファイル履歴のフォレンジック照会 📎 参照： What’s new in Elastic 9.4（公式ブログ） ・ Elastic Security リリースノート ・ Entity Analytics AI Skill ブログ まとめ：9.4 の位置付け カテゴリ 主なアップデート セキュリティ自動化 Workflows GA・25 種ケースステップ・Human-in-the-Loop AI エージェント Skills 5 種・プラットフォームスキル 3 種・Agent Builder 拡張 検知エンジニアリング AI による ES|QL ルール自動生成・MITRE 自動マッピング クエリ言語 ES|QL サブクエリ・ビュー・JSON 抽出・マッピング外フィールド ベクトル検索 3〜12 倍高速化・量子化ビット選択肢拡大 可観測性 TSDB 効率化・PromQL ネイティブ対応・時系列集計関数 エンティティ管理 名寄せ・動的ウォッチリスト・能動的ハンティングリード 9.4 はセキュリティチームだけでなく、インフラ・SRE・AI 開発チームにも広く関わるリリースです。特に Workflows と Skills の組み合わせによる「Agentic SOC（自律型 SOC）」への移行は、今後の Elastic Security の方向性を示すものといえます。 参照リンク 記事・ドキュメント URL What’s new in Elastic 9.4（公式メインブログ） https://www.elastic.co/blog/whats-new-elastic-9-4-0 Elastic Workflows GA（9.4） https://www.elastic.co/security-labs/elastic-workflows-ga-9-4 Workflows 入門（9.3 Tech Preview） https://www.elastic.co/security-labs/security-automation-with-elastic-workflows Skills in Elastic Security 9.4 https://www.elastic.co/security-labs/skills-elastic-security-9-4 AI による ES|QL 検知ルール生成 https://www.elastic.co/security-labs/ai-esql-detection-rule-creation Entity Analytics AI Skill ブログ https://www.elastic.co/security-labs/entity-analytics-agent-builder ES|QL Logical Views 詳細ブログ https://www.elastic.co/search-labs/blog/elasticsearch-esql-logical-views DiskBBQ アーキテクチャ解説ブログ https://www.elastic.co/search-labs/blog/diskbbq-elasticsearch-introduction GPU ベクトルインデックス加速ブログ https://www.elastic.co/search-labs/blog/elasticsearch-gpu-accelerated-vector-indexing-nvidia GPU ベクトルインデックス ドキュメント https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/gpu-vector-indexing Elastic AI Agent ドキュメント https://www.elastic.co/docs/explore-analyze/ai-features/elastic-agent-builder Workflows ドキュメント https://www.elastic.co/docs/explore-analyze/workflows Elastic Workflow Library（GitHub） https://github.com/elastic/workflows Elasticsearch リリースノート（9.4） https://www.elastic.co/docs/release-notes/elasticsearch Elastic Security リリースノート（9.4） https://www.elastic.co/docs/release-notes/security Elastic リリースノート（全製品） https://www.elastic.co/docs/release-notes The post Elastic 9.4 リリースまとめ：AI・自動化・クエリ言語が一斉強化 first appeared on Elastic Portal .