TECH PLAY

サイオステクノロジー((DXSL))

サイオステクノロジー((DXSL)) の技術ブログ

81

情報源: 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 .
目次 概要 実現できること AutoOps とは システム構成イメージ サンプルの内容 動作確認環境 ファイルの説明 セットアップ手順 1. パスワードなどの設定 2. コンテナの起動 3. オンプレミス側での API Key の発行 3.1. オンプレミス Kibana へのログイン 3.2. API Key の発行 3.3. Home 画面 3.4. Welcome 画面 3.5. API Key 作成画面 3.6. API Key の貼り付け 4. Cloud Connect 4.1. メニュー移動 4.2. Elastic Cloud へのログイン 4.3. Cloud Connect API Key の取得 4.4. 接続 5. AutoOps の有効化と接続 5.1. Connect AutoOps 5.2. Configure Docker Agent 5.3. Docker Compose 用の設定 5.4. AutoOps の Docker コンテナのビルド 5.5. Elastic Cloud 側での受付開始 6. AutoOps 画面 6.1. Overview 6.2. Cluster 6.3. Nodes 6.4. Indices 6.5. Shards 6.6. その他 まとめ 概要 本ブログは、オンプレミス環境の Elasticsearch のインデックス情報やメトリクスを Elastic Cloud 上で一元監視する Elastic AutoOps の紹介記事です。 実現できること オンプレミス環境の Elasticsearch ノードの稼働状態、パフォーマンス、リソース使用率の可視化 インデックス情報、シャード配置、スレッドプールなどの詳細監視 Elastic Cloud の管理画面からの統合的なヘルスチェック AutoOps とは Elastic AutoOps は、Elasticsearch クラスターの健全性を維持するための監視・最適化支援ツールです。 無料ユーザーでも利用できます。 参考URL https://www.elastic.co/docs/deploy-manage/monitor/autoops https://www.elastic.co/jp/blog/autoops-free https://www.elastic.co/jp/platform/autoops https://www.elastic.co/search-labs/jp/blog/elastic-autoops-self-managed-elasticsearch システム構成イメージ Elastic Agent がオンプレミス環境の Elasticsearch のインデックス情報や、各種メトリクスを取得し、それらを Elastic Cloud へセキュアに送信します。 これにより、外部からセキュアにインデックス情報やCPU使用率などの監視が可能になります。 サンプルの内容 Elasticsearch 環境 docker-compose.yml, .env.sample オンプレミス Elasticsearch をコンテナとして動作させます。 AutoOps エージェント環境 docker-compose-autoops.yml, Dockerfile-autoops メトリクスを転送するためのエージェントを構成します。 動作確認環境 Elastic Cloud (無償アカウントで利用可能) Docker 実行環境 筆者は Windows 上の Rancher Desktop 1.20.1 で動作確認 オンプレミス Elasticsearch: v9.3.3 (Basic License) 自動でダウンロードされます。 AutoOps: v9.3.2 執筆時点で v9.3.3 での動作検証ができなかったため、v9.3.2 を使用しています。 自動でダウンロードされます。 ファイルの説明 ※下記のファイルは、 https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-04-autoops/README.md で公開しています。 ファイル 説明 備考 .env.sample 環境変数のテンプレート .env にコピーして使用 docker-compose.yml Elasticsearch 本体の構成 Master : 3 nodes, Data : 2 nodes, Kibana docker-compose-autoops.yml AutoOps用エージェントの構成 Dockerfile-autoops AutoOps用カスタム Dockerfile セットアップ手順 [!IMPORTANT] ※事前に Elastic Cloud のアカウントが必要です。(無償アカウントでも可) 1. パスワードなどの設定 .env.sample を .env にコピーし、パスワードや暗号化キー、メモリサイズを編集します。 cp .env.sample .env 主な設定項目 CLUSTER_NAME : 監視画面に表示されるクラスタ名 ELASTIC_PASSWORD : 任意のパスワード KIBANA_PASSWORD : 任意のパスワード SAVEDOBJECTS_ENCRYPTIONKEY: 32文字以上のランダムな文字列 MEM_LIMIT : 各コンテナに割り当てるメモリの上限サイズ 2. コンテナの起動 Rancher Desktop 等の Docker ランタイムが起動していることを確認し、以下を実行します。 docker-compose up -d --build オンプレスの Elasticsearch 9.3.3 のダウンロードが行われるため、しばらく時間がかかります。 3. オンプレミス側での API Key の発行 AutoOps から オンプレミス Elasticsearch へ接続するための API Key を発行します。 3.1. オンプレミス Kibana へのログイン http://localhost:5601 へアクセスしログインします。 user: elastic password : .env ファイルの ELASTIC_PASSWORD に設定したパスワード 3.2. API Key の発行 オンプレミス Elastic の Home 画面上で、AutoOps から オンプレミス Elasticsearch へアクセスするための API Key を発行します。 3.3. Home 画面 Home 画面で Elasticsearch を選択します。 3.4. Welcome 画面 Welcome 画面が表示されるので、右上の [(+) API keys] をクリックします。 3.5. API Key 作成画面 API Key 作成画面が表示されるので、API key name に autoops_key と入力し、 [Create API key] をクリックします。 3.6. API Key の貼り付け 生成された API Key が画面に表示されるので、これをコピーして、 .env ファイルの AUTOOPS_ES_API_KEY に貼り付けます。 AUTOOPS_ES_API_KEY=... 4. Cloud Connect オンプレミス Elasticsearch を Elastic Cloud に紐づけます。 4.1. メニュー移動 Home > Management > Cloud Connect をクリック。 4.2. Elastic Cloud へのログイン [Log in]をクリックします。その後、画面の指示に従い Elastic Cloud へログインします。 4.3. Cloud Connect API Key の取得 画面の指示に従い Cloud Connect API Key を取得します。 4.4. 接続 取得したキーをオンプレミスの Kibana 上の入力欄にペーストし、[Connect] をクリックします。 5. AutoOps の有効化と接続 5.1. Connect AutoOps Elastic Cloud 側で操作します。 画面に沿って Connected Clusters の Connect AutoOps 画面へ進みます。 ※もしも、次の画面が表示されたら、画面下の Just want AutoOps ? の Get started をクリックしてください。 AutoOps Agent のインストールタイプを聞かれますが、今回は Docker を使用しているので、Docker をクリックします。 5.2. Configure Docker Agent AutoOps の設定画面が表示されるので、今回は、Elasticsearch endpoint URL に https://es01:9200 を入力します。 authentication method が API key となっていることを確認して、[Next]をクリックします。 5.3. Docker Compose 用の設定 Docker か Docker Compose かを選択する画面になるので、Docker Compose を選択し、 画面に表示されているコマンドをコピーします。 本来であれば、これをそのまま動かしたいところなのですが、この画面に表示されている内容だと Elasticsearch の SSL 設定が考慮されていません。 したがって、本サンプルでは SSL に対応した docker-compose-autoops.yml を用意しています。 画面からコピーしたコマンドの内容を元に下記の4つの値を .env ファイルへ転記していきます。 AUTOOPS_OTEL_URL=... ... AUTOOPS_TOKEN=... ... ELASTIC_CLOUD_CONNECTED_MODE_API_KEY=... ... AUTOOPS_TEMP_RESOURCE_ID=... ※ 値の部分を ‘…’ や “…” で囲む必要はありません。 5.4. AutoOps の Docker コンテナのビルド docker-compose -f ./docker-compose-autoops.yml up -d --build AutoOps用の Elastic Agent 9.3.2 がダウンロードされるため、しばらく時間がかかります。 5.5. Elastic Cloud 側での受付開始 コンテナが動き出したら、Elastic Cloud の先ほどの画面の右下の [I have run the command] をクリックします。 6. AutoOps 画面 しばらくすると、オンプレミス Elasticsearch の各種情報が AutoOps 画面で確認できるようになります。 6.1. Overview 6.2. Cluster 6.3. Nodes 上記は、Nodes の Activity を表示した画面ですが、Activity 以外にも下記を表示することができます。 Host and process Thread Pools Data Http Circuit Breakers Network Disk Activity-Additional 6.4. Indices 6.5. Shards 6.6. その他 他にも下記の画面が用意されています。実際に使ってみてください。 Template Optimizer Notifications Notifications Settings Events Settings Dismiss Events まとめ 本サンプルを通じて、Elastic Cloud Connect を利用することで、セルフマネージド(オンプレミスや独自のクラウド環境)で運用している Elasticsearch クラスターを、 Elastic Cloud 上の高度な運用支援機能「AutoOps」 にシームレスに統合できることを確認しました。 本構成のメリット 運用負荷の軽減: 複雑な監視ダッシュボードを自作することなく、Elastic 公式のベストプラクティスに基づいた監視画面(スレッドプール、サーキットブレーカー、シャード配置など)を即座に利用できます。 一元管理: 複数のセルフマネージドクラスターを Elastic Cloud という単一のコントロールプレーンで俯瞰できるようになります。 最適化の示唆: Template Optimizer などの機能により、インデックス設計の改善点など、パフォーマンス向上に直結する気づきを得られます。 次のステップへのヒント 本サンプルは評価・学習用としての最小構成です。実運用に向けては、以下の検討をお勧めします。 証明書の管理 本サンプルでは SSL 接続を簡略化していますが、本番環境では適切な CA 証明書による検証を検討してください。 アラート通知 Notifications Settings を利用して、Slack やメールへの通知設定を行い、異常検知を自動化しましょう。 リソース監視の深化 Host and process メトリクスを深掘りし、Elasticsearch プロセスだけでなく、ホスト OS 側のリソース逼迫状況との相関を分析してみてください。 このサンプルが、皆さまの Elasticsearch 運用自動化(AutoOps)の第一歩となれば幸いです。 The post AutoOps を使ってオンプレミスの Elasticsearch のインデックス情報、メトリクスを Elastic Cloud で監視する first appeared on Elastic Portal .
少し間が空きましたが、シリーズを再開します。 第1〜3回でデータの取り込み・最初のルール作成・Timelineでの 攻撃チェーン調査まで進みました。第4回はその続きです。 EQLのsequenceで「失敗のあとに成功した」攻撃パターンを 自動検出し、ES|QLで「どのIPが最も危険か」「何バイト送られたか」 を数値で把握する方法を紹介します。CaseとNotesを使った 調査記録の残し方も扱います。 シリーズのこれまでの流れ: 1回目  環境構築とログの取り込み 2回目  KQLでログを読んで最初のルールを作る 3回目  Timelineで攻撃の全体像を追う ← ここまで完了している前提 ※本シリーズで使用するデータセットは、 第1回 の記事からダウンロードできます。 目次 この記事を読むと何ができるか EQL(Correlation)で攻撃の「順序」を自動検出する ES|QLで集計・分析する クエリ1:ログイン失敗をIPごとに集計する クエリ2:攻撃対象のユーザー名を集計する クエリ3:大容量通信を探す Caseに調査内容を登録する Notesで調査メモを残す この章のまとめ 第4回チェックリスト この記事を読むと何ができるか EQLのsequence構文で攻撃の順序パターンを自動検出できる ES|QLでIPごとのログイン失敗件数・大容量通信を集計できる CaseとNotesで調査内容をチームで共有・記録できる EQL(Correlation)で攻撃の「順序」を自動検出する なぜ使うのか 第3回では「目でイベントを追って」攻撃の流れを確認しました。しかし実務では、1日に何千件ものイベントが流れる中から「特定の順番で起きたイベントの組み合わせ」を手動で見つけるのは現実的ではありません。 EQL(Event Query Language)の sequence 構文を使うと、「AのあとにBが起きた組み合わせ」を自動で検出できます。 EQLのsequenceクエリを書く このサンプルデータでは event.category の値が "iam" です。Elastic SecurityのEQLパーサーが期待する authentication カテゴリとは名称が異なるため、 any where event.category == "iam" という書き方を使います。 TimelineのCorrelationタブを開き、次のクエリを入力します。 sequence by source.ip [ any where event.category == "iam" and event.action == "user-login" and event.outcome == "failure" ] [ any where event.category == "iam" and event.action == "user-login" and event.outcome == "success" and user.name in ("admin_root", "admin", "root", "administrator") ] このクエリの意味を整理します。確認ポイント: source.ip: 192.168.1.100 のシーケンスが検出されているか 1つ目のイベント(failure)と2つ目のイベントが時系列順に並んでいるか 45.33.21.11 のシーケンスも検出されているか EQLでできること・できないことを整理しておきます。 できること できないこと イベントの順序を条件にする 集計・合計値の計算 複数イベントをまとめて1件として扱う フィールドの加工・変換 時間的な近接(maxspan)を条件にする 複数インデックスにまたがる複雑な結合 集計や加工が必要なときは、次のES|QLを使います。 ES|QLで集計・分析する KQLは「条件に一致するイベントを見つける」検索ツールです。一方ES|QLは「見つけたイベントを集計・加工・ランキングする」分析ツールです。「どのIPが一番多く失敗しているか」「何バイト送られたか」を素早く把握したいときに使います。 ES|QLはパイプ( | )でコマンドをつなげる構造です。「FROMでデータを取り出し、WHEREで絞り込み、STATSで集計し、SORTで並べる」という順番で読むと理解しやすいです。 TimelineのES|QLタブを開きます。 クエリ1:ログイン失敗をIPごとに集計する FROM training-security-logs | WHERE event.action == "user-login" AND event.outcome == "failure" | STATS failure_count = COUNT(*) BY source.ip | SORT failure_count DESC 期待される結果: source.ip failure_count 45.33.21.11 8 192.168.1.100 4 45.33.21.11 が外部から8回、 192.168.1.100 が内部から4回失敗していることが一目でわかります。 クエリ2:攻撃対象のユーザー名を集計する FROM training-security-logs | WHERE event.action == "user-login" AND event.outcome == "failure" | STATS attempt_count = COUNT(*) BY user.name | SORT attempt_count DESC 期待される結果: user.name attempt_count guest 5 admin_root 3 administrator 2 admin 1 root 1 guest が最も多く試されています。攻撃者が「存在しそうなデフォルトアカウント名」から順番に試している典型的なパターンです。 クエリ3:大容量通信を探す FROM training-security-logs | WHERE event.action == "data-transfer" | STATS max_bytes = MAX(network.bytes), total_bytes = SUM(network.bytes) BY source.ip, destination.ip | WHERE max_bytes > 10000000 | SORT max_bytes DESC 期待される結果: source.ip destination.ip max_bytes total_bytes 192.168.1.100 103.10.10.100 85,000,000 85,000,000以上 103.10.10.100 への85MB超の転送が浮かび上がります。このようなデータ量ベースの異常検知はKQLでは書けず、ES|QLが得意とする用途です。 Caseに調査内容を登録する セキュリティ調査は個人作業ではありません。「何を見つけたか」「誰が対応しているか」「どう判断したか」をチームで共有し、記録として残すことが実務では不可欠です。 Security → Alerts を開き、 source.ip: 192.168.1.100 のアラートをクリックして flyout を開きます。「Add to existing case → Add to new case」を選択します。 Case の記入例: 項目 入力例 タイトル 内部ブルートフォース攻撃 from 192.168.1.100 Severity Medium(ログイン成功・データ持ち出しが確認されているため) Tags brute-force , data-exfiltration , prod-srv-01 説明欄のテンプレート(初動調査メモ): ## 概要 2025-03-18 UTC 10:01〜10:10 の間に、192.168.1.100 から PROD-SRV-01 に対する一連の攻撃を確認。 ## 確認された活動 - 10:01台:ポートスキャン(445, 139, 80, 3389, 22) - 10:03台:admin_root へのブルートフォース → 10:03:06 に成功 - 10:03〜10:04台:whoami, net user, net localgroup による偵察 - 10:05〜10:07台:スケジュールタスク・レジストリによる永続化 - 10:06〜10:10台:103.10.10.100 への C2 接続・85MB のデータ持ち出し ## 次のアクション - [ ] 192.168.1.100 の所有者・用途を確認する - [ ] admin_root アカウントのパスワードを即時変更する - [ ] 103.10.10.100 への通信をブロックする - [ ] PROD-SRV-01 のスケジュールタスク・レジストリを精査する CaseのSeverityをアラートのSeverityより高くした理由:第2回で作ったルールはSeverity: Low(単純なログイン失敗の検知)でした。しかしTimelineで調査した結果、ログイン成功・永続化・データ持ち出しまで確認できました。ルールのSeverityはイベントの性質、CaseのSeverityは調査で判明した実際の影響度を反映させます。 Notesで調査メモを残す Timelineは分析ツールですが、「自分が何を考えながら調査したか」はTimelineには残りません。Notesを使うことで、「事実(ログ)」「解釈(何が起きているか)」「仮説(次に何を確認すべきか)」を時系列のイベントに紐づけて残せます。 Timelineで気になるイベントの行にカーソルを合わせ、行左端のアクションアイコンから「Add note」をクリックします。 良いNotesには3つの要素があります。 要素 内容 例 事実 ログから読み取れること 10:03:06 に admin_root で user-login success 解釈 そのイベントが意味すること ブルートフォース成功。この時点から侵害が始まっている 仮説・次のアクション 次に確認すること 10:03:06 以降の admin_root の行動を追う 実際のメモ例(10:03:06の成功イベントに紐づけて記録): 【事実】 192.168.1.100 から admin_root での user-login が success。 直前の 10:03:00〜10:03:05 に同 IP から失敗が4件続いている。 【解釈】 ブルートフォース攻撃が成功し、PROD-SRV-01 への侵入が完了した と判断できる。この時点が攻撃の「侵入成功ライン」。 【次のアクション】 admin_root として実行されたプロセスを 10:03:06 以降で追う。 特に cmd.exe, powershell.exe, schtasks.exe の実行を確認する。 ノートを追加しているものに赤い点が付きます。 この章のまとめ 機能 使う場面 KQL(第3回) イベントを絞り込んで目で読む Correlation(EQL) イベントの順序パターンを自動検出する ES|QL 集計・ランキング・異常値の発見 Case 調査内容をチームで共有・記録する Notes 調査の思考プロセスを時系列に紐づける 第4回チェックリスト [ ] EQLのsequenceクエリを実行し、 192.168.1.100 のブルートフォースシーケンスが検出されている [ ] ES|QLでIPごとのログイン失敗件数を集計し、 45.33.21.11 (8件)と 192.168.1.100 (4件)が確認できている [ ] 調査内容をCaseに登録し、タイトル・説明・次のアクションが入力されている [ ] 10:03:06 の成功イベントにNotesを追加し、事実・解釈・次のアクションが記録されている 次回は: ルールを「作る」だけで終わらせない最終回です。Alert suppressionとExceptionsを正しく使い分けてノイズを減らし、ルールタイプ(Custom query / Threshold / ES|QL)を目的に応じて使い分ける方法を学びます。 The post Elastic Securityで始める検知エンジニアリング — EQLとES|QLで攻撃を自動検出・集計する(第4回) first appeared on Elastic Portal .
サイオステクノロジー株式会社 Saman 2026年3月、ソフトウェアサプライチェーンを狙った攻撃が相次ぎました。 信頼されているライブラリやツールそのものが侵害され、開発者が普通に使うだけでリスクにさらされる状況が現実のものとなりました。 その中で注目されたのが、JavaScriptライブラリ「Axios」の侵害と、それを早い段階で捉えたElasticのPoCツールです。 目次 2026年3月:相次いだサプライチェーン攻撃 Axiosとは何か 今回の攻撃で何が起きたのか plain-crypto-jsとは インストール時に起きること なぜ気づきにくかったのか ElasticのPoC:supply-chain-monitor ツールの構成とAIの役割 仕組み 実証できたから、オープンソースにした なぜAIが必要なのか Elasticの方向性 まとめ 2026年3月:相次いだサプライチェーン攻撃 2026年3月には、複数のサプライチェーン攻撃が確認されています。 Trivy侵害 セキュリティスキャナが侵害され、CI/CD関連の認証情報が流出 LiteLLM侵害 流出した認証情報を利用し、悪意あるパッケージが公開 Telnyx Python SDK侵害 同様の流れで公式SDKが汚染 Axios侵害 npm上で公開されたパッケージに悪意ある依存が追加 これらは同じ月に発生した一連の事象ですが、 すべてが単一の攻撃者によるものではなく、複数の活動が重なっていたと考えられています。 Axiosとは何か Axiosは、WebアプリケーションでAPI通信を行うためのJavaScriptライブラリです。 多くのプロジェクトで使われており、週1億回くらいダウンロードされることもある、非常に広く利用されているパッケージです。 今回の攻撃で何が起きたのか 今回の攻撃では、AxiosのGitHub上の通常の開発コードではなく、npmで公開されたパッケージに対して変更が加えられました。 具体的には、以下のような構造です。 axios └── plain-crypto-js(悪意ある依存パッケージ) plain-crypto-jsとは plain-crypto-jsは、実在する暗号ライブラリ「crypto-js」に似せた名前のパッケージです。 見た目は自然(crypto系ライブラリに見える) しかし中身はマルウェア このように、既存ライブラリに似た名前を使うことで、開発者に違和感を持たせないようにする手口が使われていました。 インストール時に起きること 開発者は通常どおり以下を実行します。 npm install axios しかし、悪意あるバージョン(例:1.14.1 / 0.30.4)を取得した場合、裏では次のような処理が行われます。 Axiosがインストールされる plain-crypto-jsが依存としてインストールされる postinstallスクリプトが自動実行される マルウェア(RAT)が起動する この悪意あるバージョンは短時間(数時間程度)公開されており、その間に取得した場合に影響を受ける可能性がありました。 なぜ気づきにくかったのか 今回のポイントは、「違和感の小ささ」です。 crypto系の自然な名前 依存関係は自動でインストールされる パッケージの差分は通常見ない さらに、GitHub上の通常の開発フローではなく、公開パッケージ側に変更が加えられた点も検知を難しくしていました。 ElasticのPoC:supply-chain-monitor この攻撃を捉えたのが、Elastic Security LabsのJoe Desimone氏が開発した supply-chain-monitor  というPoCツールです。 ツールの構成とAIの役割 Joeが作った  supply-chain-monitor  の考え方は「差分をAIに読ませる」に尽きます。パッケージ更新が出た瞬間に旧バージョンとの差分を取り、LLMに「これは悪意ある変更か?」と問うだけです。 仕組み PyPIやnpmの更新フィードを定期的に取得し、新しいバージョンの公開を検知する あらかじめ定義したwatchlist(ダウンロード数上位パッケージ)に含まれるかを確認する 対象パッケージの場合、レジストリから「旧バージョン」と「新バージョン」を直接ダウンロードする npm install  や  pip install  は使用せず、コードを実行しない形で安全に取得する 2つのバージョン間の差分(diff)を生成する 差分をMarkdown形式に整形する 整形された差分をLLMに入力として渡すLLMは以下の観点で分析する この変更は開発として自然か 追加されたコードや依存関係に意味があるか 不要・不自然な変更が含まれていないか 分析結果として「malicious / benign」などの判定(verdict)を生成する maliciousと判断された場合、Slackなどにアラートを送信する アナリストはアラート内容(差分+AIの説明)をもとに追加調査を行う このアプローチの重要なポイントは、 コードを実行せずに、 使われる前の段階で異常を検知できることです。 従来のアプローチ AIを使ったアプローチ – IOC(IP・ドメイン)を照合 – シグネチャによるマッチング – 過去の攻撃パターンに対応 -「何があるか」を見る – コードの変化を読む – 変更の意図を分析する – 未知の攻撃にも対応できる -「何が変わったか」の意味を見る Axiosの検知でAIが見抜いたのは次の点です: plain-crypto-js  は依存として追加されているのに、コード内で使われていない。人はcryptoっぽい名前だから関係あるかもと見過ごします。AIは 使われていない依存の追加=説明できない変更=怪しい と判断しました。 実証できたから、オープンソースにした このツールはAxiosの侵害を、非常に早い段階でアラートとして検知しました。実際に機能することが証明されたことで、Elasticはこのツールをオープンソースとしてコミュニティに公開することを決定しました。 Joe氏はテスト中に明確なフォールスポジティブを経験しなかったと述べていますが、本人もサンプル数の少なさによる過学習の可能性に触れており、PoCとしての位置づけです。 この取り組みを共有する理由はコミュニティ全体で学ぶことが最も重要だと考えているからです。もしこのアイデアをもとに、より良いものを作る人がいれば素晴らしいことですし、パッケージレジストリ側がこの仕組みを取り入れることができれば、さらに良いことです。そして、この考え方によって次に誰かが被害を防げるのであれば、それだけで十分に価値があります。 Joe Desimone MITライセンスで公開。誰でも使え、誰でも改善に貢献できます。 github.com/elastic/supply-chain-monitor なぜAIが必要なのか パッケージ更新は毎日大量に発生します。 人間がすべての差分を確認することは現実的ではありません。 AIは、 差分を読み続ける 文脈を理解する 異常を説明できる ことで、従来では対応できなかった領域をカバーします。 Elasticの方向性 Elasticでは、AIを活用したセキュリティの進化が、すでにさまざまな形で進んでいます。 例えば、Attack Discovery、Workflows、Agent Builderといった機能を組み合わせることで、APTレベルの高度な攻撃を自動で検知し、その妥当性まで確認する仕組みが実現されています。 これは単なる自動化ではなく、 調査・判断・対応の一連の流れを支援する「エージェント型セキュリティ」 です。 日々増え続けるアラートや攻撃に対して、SOCが疲弊するのではなく、より効率的かつ的確に対応できる。 Elasticは、AIを中核に据えることで、セキュリティの「効率」と「精度」の両方を引き上げています。 ※  APTレベル = 国や大企業レベルの“高度でしつこい攻撃” まとめ 今回のAxiosの事例が示したのは、信頼そのものが攻撃対象になる時代です。 そして、それに対抗するためには「変化を理解する力」が必要になります。 ElasticのPoCツールが示したのは、その新しい方向性です。 セキュリティは今、「見る」から「理解する」へと進み始めています。 参考元: How we caught the Axios supply chain attack — Elastic Security Labs Joe Desimone shares the story of how he caught the Axios supply chain attack with a proof of concept tool built in an af... www.elastic.co GitHub - elastic/supply-chain-monitor Contribute to elastic/supply-chain-monitor development by creating an account on GitHub. github.com The post AIで変化の意味を読む:Elasticの新検知ツール(PoC)がAxios攻撃を捉えた方法 first appeared on Elastic Portal .
サイオステクノロジー株式会社 Saman アラートは「何かが起きた」という通知にすぎません。「本当に攻撃なのか」「何をされたのか」を判断するには、アラートの前後に何が起きていたかを調査する必要があります。今回はTimelineを使って、ポートスキャンから始まりデータ持ち出しで終わる一連の攻撃を5つのフェーズに分けて追います。 シリーズの前の回 1回目 2回目 Elastic Securityで始める検知エンジニアリング — 環境構築とログの取り込み(第1回) これから5回に分けて、Elastic Securityを使ったセキュリティ監視の基礎を、手を動かしながら学んでいきます。第1回はデータの取り込みと、Discover・Securityの両方で見えるようにするまでの環境構築です。今後の予定本シ... elastic.sios.jp 2026.03.31 Elastic Securityで始める検知エンジニアリング — KQLでログを読んで最初のルールを作る(第2回) ログを読まずにルールは作れません。前回に続いて今回はDiscoverでイベントの中身を確認しながら、「ログイン失敗を検知する」最初のルールを正しい条件で作ります。ルール作成前にDiscoverで確認する習慣が、後々の誤検知を防ぐ最大のポイン... elastic.sios.jp 2026.04.01 目次 この記事を読むと何ができるか Timelineを開く 最初の絞り込み 攻撃の流れを読む:5つのフェーズ フェーズ1:偵察(UTC 10:01:05〜10:01:35) フェーズ2:初期アクセス(UTC 10:03:00〜10:03:06) フェーズ3:権限確認(UTC 10:03:30〜10:04:30) フェーズ4:永続化(UTC 10:05:00〜10:07:30) フェーズ5:データ持ち出し(UTC 10:06:30〜10:10:00) ピボットで視点を切り替える この章のまとめ 第3回チェックリスト この記事を読むと何ができるか Timelineを使ってアラートと生イベントをまとめて調査できる source.ip → user.name → destination.ip の順でピボットしながら攻撃の流れを追える このサンプルデータ(1回目のブログからダウンロードできます)で起きた攻撃を5つのフェーズで説明できる ※第1・2回を読んでいることを前提にしています。 Timelineを開く Elastic Security の Timeline は、複数のイベントを時系列で並べ、相互に関連付けながら調査できる、インタラクティブなワークスペースです。 手順: Security → Alerts を開き、時間範囲を「Last 2 years」にします source.ip: 192.168.1.100 に対応するアラート行( user.name: admin_root 、 host.name: PROD-SRV-01 )を探します アクションアイコンから 「Investigate in timeline」 をクリックします Alert detailsのフライアウトからも同じ操作が可能です。フライアウト右下の「Investigate in timeline」ボタンを使うと、アラートのコンテキストを引き継いだ状態でTimelineが開きます。 最初の絞り込み Timelineを開いたら、まず query builder で以下のフィルターを設定します。 host.name:"PROD-SRV-01" and source.ip:"192.168.1.100" 次に _id (1件1件のログに付く一意のID)を列から削除して表示を整理します。 画面左側のフィールドリストからフィールド名をクリックして列として追加します。追うべきフィールドは以下の通りです。 フィールド 何を見るか @timestamp いつ起きたか event.action 何をしたか event.outcome 成功か失敗か user.name 誰として動いたか process.name どのプロセスが実行されたか source.ip どこから来たか destination.ip どこへ出たか destination.port どのポートへ network.bytes 何バイト転送したか rule.name どのルールで検知されたか @timestampを古いから新しい方にソートします。 rule.name が空欄のイベントは「通常のログ(生イベント)」です。攻撃チェーンは検知されたイベントだけでは完成しません。その間にある生イベントも含めて読むことで、初めて全体像が見えます。 補足:なぜ user.name:"admin_root" で絞り込まないのか ポートスキャン段階(UTC 10:01台)の connection-attempt イベントには user.name が入っていません。 user.name で絞ると攻撃の最初のフェーズが見えなくなります。 攻撃の流れを読む:5つのフェーズ このサンプルデータには、教科書的な攻撃の5つのフェーズがすべて含まれています。各フェーズの詳細を順番に見ていきます。 フェーズ1:偵察(UTC 10:01:05〜10:01:35) event.action: connection-attempt event.outcome: failure rule.name: Port Scan Detected 192.168.1.100 から 172.16.0.1 に向けて、ポート445・139・80・3389・22への接続試行失敗が30秒間に5件並びます。接続が拒否されてもそれ自体が情報になります。どのサービスが動いているかがわかれば、次のステップを選べます。 UTC destination.port event.outcome 10:01:05 445(SMB) failure 10:01:06 139(NetBIOS) failure 10:01:07 80(HTTP) failure 10:01:20 3389(RDP) failure 10:01:35 22(SSH) failure フェーズ2:初期アクセス(UTC 10:03:00〜10:03:06) event.action: user-login rule.name: Brute Force Attempt → Brute Force Success わずか6秒の間に、ログイン失敗4件とログイン成功1件が連続します。 UTC user.name event.outcome 10:03:00 admin_root failure 10:03:02 admin_root failure 10:03:04 admin_root failure 10:03:05 administrator failure 10:03:06 admin_root success 「失敗の連続 → 突然の成功」というパターンは、ブルートフォース攻撃の典型的な痕跡です。 見落としやすいポイント:10:03:06の成功イベントにはルール名が入っていますが、もしこのルールが存在しなかった場合、Alertsテーブルには失敗のアラートしか表示されません。ログイン成功は「異常ではない」として見落とされやすく、これが侵入を気づかれにくくする要因の1つです。 フェーズ3:権限確認(UTC 10:03:30〜10:04:30) event.action: process-created rule.name: Suspicious CMD Execution, Domain Enumeration, Privilege Enumeration ログイン成功の直後、 admin_root として3つのプロセスが連続して実行されます。 UTC process.name process.command_line 意味 10:03:30 cmd.exe cmd.exe /c whoami && ipconfig /all 自分が誰か・どの環境かを確認 10:04:00 net.exe net user /domain ドメインユーザー一覧を取得 10:04:30 net.exe net localgroup administrators 管理者グループのメンバーを確認 「どの権限で入れたか」「他にどんなユーザーがいるか」を把握することで、次の行動を計画します。 フェーズ4:永続化(UTC 10:05:00〜10:07:30) event.action: process-created rule.name: Scheduled Task Created, Suspicious PowerShell Encoded Command, Registry Persistence UTC process.name 意味 10:05:00 schtasks.exe スケジュールタスクを作成(再起動後も実行され続ける仕掛け) 10:06:00 powershell.exe Base64エンコードされたコマンドを実行(内容を難読化して検知を回避) 10:07:30 reg.exe レジストリのRunキーに追記(ログイン時に自動実行される仕掛け) この段階は「侵入後に居続けるための準備」です。Base64でコマンドを難読化しているのは、シグネチャベースの検知ツールの目をくらませる典型的な手口です。 「永続化」とは:攻撃者が「1回侵入できた」だけで終わらせず、再起動後やパスワード変更後にも再び接続できる状態を作ることです。スケジュールタスク・レジストリRunキー・サービスの登録などがよく使われます。 フェーズ5:データ持ち出し(UTC 10:06:30〜10:10:00) event.action: connected, data-transfer rule.name: C2 Connection Attempt, Large Data Exfiltration UTC event.action destination.ip network.bytes 意味 10:06:30 connected 103.10.10.100:443 512 外部サーバーへの接続確立(C2通信) 10:09:45 process-created — — Compress-Archiveでデータを圧縮・準備 10:10:00 data-transfer 103.10.10.100 85,000,000 85MBのデータを外部へ送信 「接続確立 → データ圧縮・準備 → 大量送信」という順番がTimelineで一目でわかります。 443番ポートへの通信が見逃されやすい理由:443番ポートはHTTPSの標準ポートです。多くのファイアウォールは443番を業務上の正常通信として許可しているため、C2通信はこのポートを意図的に使うことがあります。ポート番号だけで判断せず、接続先IPアドレスが既知サーバーかどうかも確認することが重要です。 ピボットで視点を切り替える Timelineの強みは「見つけた値をその場で次の絞り込みに使える」ことです。攻撃者の行動(user.name)から外部への通信(destination.ip)という流れに沿って、以下の順でピボットすることで調査が深まります。 ピボット1: user.name で絞り込む(侵害アカウントの視点) host.name:"PROD-SRV-01" and user.name:"admin_root" 攻撃者が admin_root でログインした後、どのプロセスを実行し、どこへ通信したかが一本線で見えます。「侵入後に何をされたか」を把握したいときに有効です。 ピボット2: destination.ip で絞り込む(外部通信の視点) destination.ip:"103.10.10.100" source.ip の条件を取り除き、外部サーバーへの通信だけを見ます。「いつ・どのユーザーが・何バイト送ったか」が圧縮されて表示されます。 この章のまとめ Timelineはアラートと生イベントをまとめて追う調査画面である rule.name が空のイベント(生ログ)も含めて読むことで、攻撃の全体像が見える source.ip → user.name → destination.ip の順でピボットすると、攻撃を立体的に理解できる このデータの攻撃は「ポートスキャン → ブルートフォース → 権限確認 → 永続化 → データ持ち出し」の5フェーズで構成されている アラートだけでは攻撃の全体像は見えない。アラートは「調査の入口」である 第3回チェックリスト [ ] Timelineを source.ip: 192.168.1.100 で絞り込み、5つのフェーズが時系列で見えている [ ] user.name: admin_root でピボットし、侵入後の活動が追えている [ ] destination.ip: 103.10.10.100 でピボットし、C2通信と持ち出しの流れが見えている [ ] 攻撃の流れを自分の言葉で5フェーズに整理して説明できる 次回は: EQLのsequenceで攻撃パターンを自動検出し、ES|QLで「どのIPが最も危険か」を数値で把握する方法を紹介します。目でログを追う調査の次のステップです。 The post Elastic Securityで始める検知エンジニアリングー Timelineで攻撃の全体像を追う(第3回) first appeared on Elastic Portal .
サイオステクノロジー株式会社 Saman 2026年3月末、広く使われているHTTPライブラリ Axios がサプライチェーン攻撃の標的になりました。 サプライチェーン攻撃とは、利用者が普段から信頼しているソフトウェアや配布経路を悪用して、マルウェアを届ける手口です。今回の事件は「有名なライブラリが乗っ取られた」という単純な話ではなく、現代のソフトウェア開発が持つ構造的な脆弱性を突いた、非常に巧妙なものでした。 本記事は、Elastic Security Labsが公開した調査・分析レポートを中心にもとにまとめています。技術的な詳細や検知ルールについては、ぜひ Elastic Security Labsの公式記事 またはElasticのJoe Desimoneさんが Github Gist で公開しているものを直接ご参照ください。 目次 何が起きたのか なぜこれほど危険だったのか Elasticはどう検知していたのか 1つの設計思想から生まれた攻撃 感染が疑われる場合の対応 この事例が示すもの 何が起きたのか 攻撃者はAxiosメンテナーのnpmアカウントを乗っ取り、悪意あるバージョン( axios@1.14.1 と axios@0.30.4 )をnpmに公開しました。通常、Axiosは GitHub Actions を経由した公開フローを採用していますが、今回は通常とは異なる公開経路が使われた可能性があり、直接CLIから公開されたとみられています。 この悪意あるバージョンには、 plain-crypto-js@4.2.1 という不正な依存パッケージが仕込まれていました。パッケージには postinstall という仕組みがあり、インストール完了後に自動でコードを実行できます。今回はこれを悪用して setup.js が自動起動し、攻撃者のコードが走る状態になっていました。 つまり、利用者は npm installをしただけで、知らぬ間に攻撃者のコードを実行してしまう可能性がありました。 Huntressの観測によると、パッケージ公開からわずか 89秒後 に最初の感染が確認されています。公開時間が短くても、被害は十分に広がることが証明されました。 なお、問題はAxiosそのものではなく、配布経路が一時的に侵害された点にあります。 なぜこれほど危険だったのか ① 自分でAxiosを入れていなくても感染する Axiosは非常に広く使われているため、別のパッケージが内部で依存しているケース(トランジティブ依存)も多くあります。「自分のプロジェクトにAxiosはない」と思っていても、気づかないうちに入っていた、というケースが起こり得ます。 ② バグでも脆弱性でもない攻撃だった 今回はCVEやゼロデイ脆弱性を突いたものではありません。信頼された公開経路そのものが武器にされた事件です。どれだけコードが安全でも、配布フローが侵害されれば意味をなしません。 ③ Windows・macOS・Linuxすべてが対象 setup.js は難読化されており、実行時にOSを判別してそれぞれに対応したマルウェアを起動します。開発者のPC、CI/CDパイプライン、本番サーバーまで、環境を問わず標的になり得ました。 Elasticはどう検知していたのか Elastic Security Labsが注目したのは、ドメイン名やファイルハッシュではなく、 プロセスの実行チェーン です。これはエンドポイント上の振る舞い(EDR的な観点)に基づく検知であり、「何が実行されたか」ではなく「どのように実行されたか」に着目しています。 node 起動 → OSコマンド実行 → 外部からファイル取得 → 実行 正規のパッケージインストールでは、このような流れは通常起きません。攻撃者はドメイン名やファイル名を変えることはできますが、npm install 直後のこの不自然な実行の連鎖はそう簡単には変えられない、という考え方です。 OSごとの検知シグナルも具体的に示されています。Linuxでは node 後の sh/curl 起動とPythonスクリプトの実行、Windowsではエンコードされた PowerShell の実行と永続化の試み、macOSでは osascript の利用や不審なパスへのファイル配置が観測されました。 さらにElasticは、この問題を把握した後に GitHub Security Advisory を提出し、検知ルールと詳細分析を公開するなど、情報共有にも積極的に動いていました。 1つの設計思想から生まれた攻撃 Elasticの詳細分析(”One RAT to Rule Them All”)によると、OS別に異なるマルウェアが使われていたように見えて、実際には通信構造とコマンド体系が共通していました。 実装言語はOSごとに違っても、攻撃者は クロスプラットフォームで動く1つの統一されたRAT(遠隔操作マルウェア)運用 を設計していたと考えられます。これは場当たり的な攻撃ではなく、計画的・組織的に準備された攻撃であることを示しています。 感染が疑われる場合の対応 Huntressは、影響を受けたバージョンを導入していた場合、 ファイルを削除して終わりにしてはいけない と強く警告しています。 RATが一度動いてしまうと、何が参照・持ち出されたかを完全に特定することは困難です。推奨される対応は以下の通りです。 資格情報・トークンのローテーション 影響範囲の徹底調査 必要に応じた環境の再構築 「マルウェアを消した」ことと「安全が戻った」ことは別物です。特にシークレットやアクセストークンが置かれるCI/CD環境では、侵害前提の対応が求められます。 この事例が示すもの 今回のAxios事件は、オープンソースを使うこと自体が危険だという話ではありません。むしろ、依存関係が当たり前になった現代の開発では、 守るべき対象も「コードの品質」から「サプライチェーン全体の信頼性」へと広がっている ことを示した事件です。 89秒で感染が始まるスピードは、人手による確認だけでは対応が追いつかないことを如実に示しています。固定のIOCに頼るだけでなく、インストール直後の不自然な実行チェーンを監視する仕組みを持てているかどうか、今一度見直すきっかけにしてください。 参考元 Elastic Security Labs, Elastic releases detections for the Axios supply chain compromise Elastic Security Labs, Inside the Axios supply chain compromise – one RAT to rule them all Huntress, Supply Chain Compromise of axios npm Package Joe Desimone, axios_compromise.md (GitHub Gist) The post Axiosサプライチェーン攻撃速報:Elasticはこの攻撃をどう検知したのか first appeared on Elastic Portal .
Saman ログを読まずにルールは作れません。 前回 に続いて今回はDiscoverでイベントの中身を確認しながら、「ログイン失敗を検知する」最初のルールを正しい条件で作ります。ルール作成前にDiscoverで確認する習慣が、後々の誤検知を防ぐ最大のポイントです。 ※本シリーズで使用するデータセットは、 第1回 の記事 からダウンロードできます。 Elastic Securityで始める検知エンジニアリング — 環境構築とログの取り込み(第1回) これから5回に分けて、Elastic Securityを使ったセキュリティ監視の基礎を、手を動かしながら学んでいきます。第1回はデータの取り込みと、Discover・Securityの両方で見えるようにするまでの環境構築です。今後の予定本シ... elastic.sios.jp 2026.03.31 目次 この記事を読むと何ができるか Step 1:Discoverでイベントの中身を確認する Step 2:ログイン失敗だけに絞り込む Step 3:このサンプルデータに含まれる2つのシナリオ Step 4:ルールタイプを選ぶ Step 5:ルールを作る Step 6:過去データに対してルールを確認する アラートが見えないときの確認手順 生成されたアラートから読み取れること サマリー画面で全体傾向を把握する テーブルで個別アラートを確認する この章のまとめ 第2回チェックリスト この記事を読むと何ができるか event.outcome:"failure" に複数種類の失敗が混在していることを理解できる event.action:"user-login" and event.outcome:"failure" でログイン失敗だけを正確に絞り込める Failed Login Detection (Basic Rule) という名前の検知ルールが動いている状態になる 過去データの確認に Rule preview と manual run を使い分けられる Step 1:Discoverでイベントの中身を確認する Discoverを開き、左上のData Viewが training-security-logs になっていることを確認します。時間範囲は「Last 2 years」に変更してください。 まず次のフィールドを列として追加します。フィールド名の横の「+」アイコンをクリックすると列に追加できます。 フィールド 何を見るか @timestamp いつ起きたか event.action 何のイベントか event.outcome 成功か失敗か user.name 対象ユーザー source.ip 送信元IP host.name 対象ホスト Step 2:ログイン失敗だけに絞り込む まず次のKQLを実行します。 event.outcome:"failure" 18件ヒットします。ここで event.action 列に注目してください。 event.outcome:"failure" は「失敗したイベント全般」を返します。ログイン失敗だけでなく、ポートスキャン時の接続失敗も含まれます。「Failed Login Detection」という名前のルールをこの条件で作ると、名前と実態がずれたルールになってしまいます。 event.action 件数 意味 connection-attempt 6件 ポートへの接続試行が失敗 user-login 12件 ログイン試行が失敗 次のKQLを実行します。 event.action:"user-login" and event.outcome:"failure" 12件に絞られます。 connection-attempt の失敗が消え、純粋にログイン失敗だけが残っているはずです。 確認ポイント: event.action がすべて user-login になっているか event.outcome がすべて failure になっているか connection-attempt のようなネットワーク失敗が混ざっていないか 混ざっていなければ、この条件がルールのKQLとして使えます。 event.category をルール条件に使う際の注意点 event.category はマルチバリューフィールドです。1件のイベントが ["iam", "authentication"] のように複数の値を持てる設計になっています。Elastic SecurityのCustom query ruleでこのフィールドをルール条件に使うと、「The event.category field cannot be used for…」というエラーが表示される場合があります。ルールのKQL条件では event.action や event.outcome のようなシングルバリューフィールドを使い、 event.category はDiscover での確認用として使うのが安全です。 ※ Discoverでフィールドの統計量を確認できる。 Step 3:このサンプルデータに含まれる2つのシナリオ 絞り込んだ12件を時系列で見ると、2つの独立した攻撃シナリオが含まれています。この章では両方のシナリオを拾う「一般的なログイン失敗の監視ルール」を作ります。シナリオAの攻撃チェーンを詳しく追う調査は第3回で行います。 シナリオA:内部ネットワークからの侵害の可能性(source.ip: 192.168.1.100) UTC 10:03 台に、 192.168.1.100 から PROD-SRV-01 に対して admin_root と administrator へのログイン失敗が複数回続き、その直後に成功しています。 このような「短時間の連続失敗の後に成功する」挙動は、ブルートフォース攻撃による認証突破の可能性を示す典型的なパターンです。ただし、ユーザーの入力ミスによる正常なログインの可能性もあるため、追加の調査が必要です。 シナリオB:外部からのブルートフォース(source.ip: 45.33.21.11) UTC 10:14〜10:17 台に、外部 IP 45.33.21.11 から PROD-SRV-01 に対して guest・admin・root・administrator など複数のユーザー名でログイン失敗が連続して発生しています。 これは、一般的なアカウント名を順に試す典型的なブルートフォース攻撃の挙動です。 Step 4:ルールタイプを選ぶ Elastic Securityには複数のルールタイプがあります。 ルールタイプ 何を見るか 向いているケース Custom query 条件に一致する1件1件のイベント 1件でも起きたら知らせたい Threshold 一致したイベントの件数 5回以上失敗したら知らせたい ES|QL 集計・加工した結果 合計転送量が閾値を超えたら Event Correlation イベントの順序・パターン AのあとにBが起きたら 今回は「1件のログイン失敗が起きたら知らせたい」ので Custom query を選びます。Threshold は「何回失敗したか」を数えるためのものであり、1件ずつ検知したい今回の目的には向きません。Threshold の使い方は第5回で扱います。 Step 5:ルールを作る Security → Rules → Detection rules (SIEM) → Create new rule を開きます。 ルールタイプの選択画面で「Custom query」を選んで「Selected」にします。 Define rule の設定: データソースとして「Data View」タブを選び、 training-security-logs を指定します。Custom query 欄に次を入力します。 event.action:"user-login" and event.outcome:"failure" 保存前に必ずDiscoverで確認する ルールを保存する前に、同じKQLをDiscoverで実行して「期待したイベントだけが返ってくるか」を必ず確認してください。この確認を省くと、想定外のイベントを拾うルールや、何もヒットしないルールを本番環境に入れてしまうリスクがあります。 About rule の設定: 項目 設定値 Name Failed Login Detection (Basic Rule) Description training-security-logs 内のログイン失敗イベントを検知する Severity Low Risk score 21 Schedule の設定: 項目 設定値 Runs every 5 minutes Additional look-back time 1 minute 「Continue」をクリックし、「Create & enable rule」で保存します。 ※ノイズ削減(重複アラートの圧縮や正常動作の除外)は別の回で扱います。 Step 6:過去データに対してルールを確認する このサンプルは2025-03-18の過去データです。ルールを有効化しても、ルールは「現在時刻からの直近ウィンドウ」を見るため、今すぐアラートが自動生成されることはありません。これは故障ではなく正常な動作です。 過去データを確認するための2つの方法を使い分けます。 Rule preview の手順: ルール編集画面右上の「Rule preview」をクリック 時間範囲を設定する 開始: 2025-03-18 10:00:00 (UTC)/ 画面表示では 19:00:00 JST 終了: 2025-03-18 10:30:30 (UTC)/ 画面表示では 19:30:30 JST 「Refresh」をクリック 期待値:12件のアラートが表示される(内部侵害4件 + 外部ブルートフォース8件) Manual run の手順: ルール詳細画面の右上メニューから「Manual run」を選ぶ 時間範囲を過去データの期間に合わせて指定する 「Run」をクリック Security → Alerts を開き、Alerts画面の時間範囲も「Last 2 years」などに広げる ※Additional look-back timeをかなり長くとる方法も合います アラートが見えないときの確認手順 手順 確認内容 ① Discoverで同じKQLを実行してヒットするか確認する ② 各画面の時間範囲が過去データに合っているか確認する ③ securitySolution:defaultIndex に training-security-logs が入っているか確認する(第1回参照) ④ ルール詳細の「Execution results」タブを確認する。「Succeeded」はクエリが正常終了したことを意味するだけで、ヒット件数がゼロのまま正常終了することがある 生成されたアラートから読み取れること Manual run後に Security → Alerts を開くと、次の状況が確認できます。 サマリー画面で全体傾向を把握する 画面上部の Summary タブでは、検知結果の全体傾向が一目でわかります。 確認項目 このデータでの期待値 Severity levels すべて「Low」、計12件 Alerts by name Failed Login Detection (Basic Rule):12件 Top alerts by source.ip 45.33.21.11(約66%)、192.168.1.100(約33%) 「どの送信元からの攻撃が多いか」がひと目でわかります。 テーブルで個別アラートを確認する テーブルビューで確認すべき主なフィールドは次のとおりです。 フィールド 確認すること @timestamp いつ発生したか(時間が集中していないか) Rule どのルールで検知されたか Severity / Risk Score 重要度(今回は Low / 21) host.name 攻撃対象のホスト(PROD-SRV-01) user.name 試されたユーザー名(admin_root, guest など) 今回の12件のアラートから、次の状況が推測できます。 同一ホスト( PROD-SRV-01 )に対して 複数のユーザー名( admin_root ・ administrator ・ guest ・ admin ・ root )で 複数回のログイン失敗が発生している 送信元IPが2つあり、 45.33.21.11 が大多数を占める これはブルートフォース攻撃の典型的な兆候です。ただしこの時点では「疑いがある」という段階です。次の第3回でTimelineを使って攻撃の流れを詳しく追います。 この章のまとめ event.outcome:"failure" だけでは、ログイン失敗以外の失敗イベントも含まれる event.action:"user-login" and event.outcome:"failure" で、ログイン失敗だけを正確に絞れる event.category はマルチバリューフィールドのため、ルールのKQL条件に使うとエラーになる場合がある 最初のルールには Custom query を使い、件数ではなく1件1件を検知する 過去データの確認には、Rule preview(シミュレーション)と manual run(本番実行)を使い分ける 第2回チェックリスト [ ] event.outcome:"failure" で18件、 event.action:"user-login" and event.outcome:"failure" で12件ヒットする [ ] Failed Login Detection (Basic Rule) が作成され、有効化されている [ ] Rule preview または manual run でアラートが確認できている [ ] Alertsのサマリーで 45.33.21.11 と 192.168.1.100 の2つの送信元が見えている 次回は: Timelineを使って、 192.168.1.100 からの攻撃をポートスキャンからデータ持ち出しまで1本の時系列で読み解きます。「アラートを見る」から「攻撃の流れを説明できる」へ進みます。 The post Elastic Securityで始める検知エンジニアリング — KQLでログを読んで最初のルールを作る(第2回) first appeared on Elastic Portal .
サイオステクノロジー株式会社 Saman これから5回に分けて、Elastic Securityを使ったセキュリティ監視の基礎を、手を動かしながら学んでいきます。第1回はデータの取り込みと、Discover・Securityの両方で見えるようにするまでの環境構築です。 今後の予定 本シリーズでは、以下の流れでステップアップしていきます。 第2回:KQLでログを読み、最初の検知ルールを作る 第3回:Timelineで攻撃の全体像を追う 第4回:EQL / ES|QLで攻撃を自動検出・集計する 第5回:ノイズを減らし、運用できるルールにする 本ブログでは、ローカル環境に構築した Elastic Stack v9.3 を使用して、実際に手を動かしながら検証・解説を行っています。 Elastic Stack はオープンソースとして利用可能であり、クラウド版(Elastic Cloud)も無料トライアルで試すことができます。 Elastic Stack(ダウンロード) https://www.elastic.co/jp/downloads/ Elastic Cloud(無料トライアル) https://www.elastic.co/jp/cloud/cloud-trial-overview 目次 この記事を読むと何ができるか まず覚えておく5つの用語 演習データについて Step 1:ファイルをアップロードする Step 2:インデックス名を確認する Step 3:マッピングを設定する Step 4:Security画面でもデータを見えるようにする Step 5:時間範囲の調整 取り込みの確認 よくあるつまずきポイント この章のまとめ 第1回チェックリスト この記事を読むと何ができるか サンプルデータ82件をElasticsearchに正しく取り込める Discoverでイベントを確認できる Elastic Securityの画面でも同じデータが見える状態になる まず覚えておく5つの用語 このシリーズ全体で繰り返し登場します。最初に整理しておきます。 イベント :1件のログです。「ログイン成功」「プロセス起動」「外部への通信」など、「何かが起きた記録」です。このガイドでは 82件のイベントを使います。 ルール :イベントを条件で監視し、怪しいものを自動で見つけるための設定です。「ログイン失敗が起きたら知らせる」という定義がルールです。 アラート :ルールの条件に一致した結果です。イベントは「原材料」、アラートは「調査が必要かもしれない、という通知」です。アラートが出たからといって、必ずしもインシデントではありません。 Timeline :複数のイベントを時系列で並べながら、攻撃の流れを追う調査画面です。第3章で詳しく使います。 Case :調査メモ、担当者のアサイン、証拠をひとまとめにする入れ物です。チームで調査内容を共有するために使います。 演習データについて 今回使うサンプルデータ security_sample_v2.ndjson の概要です。 項目 値 形式 NDJSON(1行1イベント) 件数 82件 時間範囲 2025-03-18 09:45:00 〜 10:30:00(UTC) 取り込み先インデックス名 training-security-logs このデータはElastic Securityの学習用に設計されたサンプルです。完全な本番用ECSデータではありませんが、Discover・検知ルール・Timelineの練習には十分使えます。 ECS(Elastic Common Schema)とは 異なるログソース間でフィールド名を統一するための共通ルールです。WindowsイベントログでもLinux syslogでも、「ログイン失敗」は event.outcome: "failure" と書く、という約束事です。この共通化によって、複数製品のログを横断して検索・分析できるようになります。 Step 1:ファイルをアップロードする KibanaのIntegrationメニューから「Upload file」を開きます。画面遷移はバージョン差が出ることがあるので、迷ったら Global Search で検索して開いてください。 またはKibanaのホーム画面から「Upload a file」を選んでもかまいません。 security_sample_v2.ndjson を画面にドラッグ&ドロップします。Kibanaがファイルを自動解析します(数秒かかります)。 インデックス名を logs-training-security に指定します。 Step 2:インデックス名を確認する 「Advanced options」を展開し、「Create data view」にチェックが入っていることを確認します。このチェックが入っていると、取り込みと同時にDiscover用のデータビューが自動で作成されます。 training-security-logs ⚠️ このインデックス名は正確に入力してください 第2回以降の手順でこの名前を前提にしています。別の名前で取り込むと、後の手順がすべて動作しません。 Step 3:マッピングを設定する 「Mappings」欄に次のJSONを入力します。マッピングとは「このフィールドを日付として扱う」「これをIPアドレスとして扱う」という型の定義です。省略すると集計や範囲検索が正しく動かなくなります。 { "properties": { "@timestamp": { "type": "date" }, "agent.type": { "type": "keyword" }, "ecs.version": { "type": "keyword" }, "event.kind": { "type": "keyword" }, "event.type": { "type": "keyword" }, "event.category": { "type": "keyword" }, "event.action": { "type": "keyword" }, "event.outcome": { "type": "keyword" }, "source.ip": { "type": "ip" }, "destination.ip": { "type": "ip" }, "destination.port": { "type": "integer" }, "network.bytes": { "type": "long" }, "network.transport": { "type": "keyword" }, "network.protocol": { "type": "keyword" }, "user.name": { "type": "keyword" }, "host.name": { "type": "keyword" }, "process.name": { "type": "keyword" }, "process.pid": { "type": "integer" }, "process.command_line": { "type": "wildcard" }, "process.parent.name": { "type": "keyword" }, "dns.question.name": { "type": "keyword" }, "rule.name": { "type": "keyword" } } } マッピングが重要な理由: @timestamp が date 型でないと、時間範囲で絞り込めない network.bytes が long 型でないと、合計・最大値の集計ができない source.ip が ip 型でないと、CIDRなどのIP範囲検索が使えない 設定を確認したら「Import」をクリックします。「Import complete」と表示されれば成功です。 Step 4:Security画面でもデータを見えるようにする Data Viewを作っただけでは、SecurityアプリはこのインデックスをElastic Securityが使うインデックス一覧に含みません。 securitySolution:defaultIndex という設定にインデックス名を追加する必要があります。 Stack Management → Advanced Settings → securitySolution:defaultIndex 現在の値の末尾に training-security-logs を追加して「Save changes」をクリックし、ページをリロードします。 なぜこの設定が必要か Elastic Securityはデフォルトで logs-* 、 metrics-* などの決まったパターンのインデックスしか見ません。 training-security-logs はそのパターンに含まれないため、明示的に追加する必要があります。本番環境でも、カスタムインデックスを使う場合は同じ手順が必要になります。 ⚠️ バージョンについての注意 securitySolution:defaultIndex の設定箇所はElasticのバージョンによって異なる場合があります。公式ドキュメントも合わせて確認してください。 Step 5:時間範囲の調整 このサンプルデータは 2025-03-18 のタイムスタンプを持っています。Kibanaのデフォルト表示は「直近15分」や「Today」なので、そのままではデータが空に見えることがあります。取り込み失敗ではなく、単に時間範囲が合っていないだけです。 方法 操作 ざっくり確認したい 画面右上の時間範囲ピッカーで「Last 2 years」を選択 正確に指定したい 「Absolute」で開始 2025-03-18 09:45:00 、終了 2025-03-18 10:30:00 を入力 UTC と日本時間(JST)のズレに注意 サンプルデータのタイムスタンプはUTCで記録されています。Kibanaの表示はブラウザのタイムゾーン(日本環境ではJST = UTC+9)で表示されるため、画面上では 18:45〜19:30 のように見えます。このシリーズでは時刻をUTCで記述します。画面上の表示が9時間ずれていても異常ではありません。 取り込みの確認 取り込みが完了したら、次の3つで正しく入ったか確認します。 確認1:件数確認 Dev Tools(Console)で実行します。 GET training-security-logs/_count 期待値: 82 確認2:時間範囲確認 POST _query { "query": """ FROM training-security-logs | STATS total = COUNT(*), earliest = MIN(@timestamp), latest = MAX(@timestamp) """ } 期待値: total = 82 earliest = 2025-03-18T09:45:00.000Z latest = 2025-03-18T10:30:00.000Z 確認3:数値フィールドの型確認 POST _query { "query": """ FROM training-security-logs | WHERE network.bytes IS NOT NULL | STATS max_bytes = MAX(network.bytes), sum_bytes = SUM(network.bytes) """ } 期待値: max_bytes = 120000000 (120MB) この値が返ってくれば、 network.bytes が数値型として正しく取り込まれています。文字列型で取り込まれていると、この集計はエラーになります。 確認4:データ種別確認 POST _query { "query": """ FROM training-security-logs | STATS count = COUNT(*) BY agent.type | SORT count DESC """ } 期待値: winlogbeat = 53 packetbeat = 29 よくあるつまずきポイント 取り込んだはずなのにDiscoverに何も表示されない場合は、次を順番に確認してください。 時間範囲が「Last 15 minutes」になっていないか :「Last 2 years」に変更する Data Viewが training-security-logs になっているか :左上のドロップダウンで確認 インデックス名にタイポがないか : training-security-log (sなし)は別のインデックス Discoverでは見えるのにSecurityでは見えない場合は、Step 4の securitySolution:defaultIndex の設定を再確認してください。 この章のまとめ やったこと なぜ必要か インデックス名を training-security-logs に指定 後の章の全手順がこの名前を前提にしているため マッピングに型を明示 時間検索・数値集計・IP検索を正しく動かすため securitySolution:defaultIndex に追加 Security画面でこのデータを使えるようにするため 時間範囲を調整 2025-03-18の過去データを画面に表示するため 第1回チェックリスト [ ] GET training-security-logs/_count が 82 を返す [ ] Discoverで training-security-logs データビューを開き、イベントが見える [ ] Security → Rules 画面を開いたときにエラーが出ていない 次回は: KQLでログの中身を読みながら、最初の検知ルールを正しい条件で作ります。 event.outcome:"failure" だけでは何が起きるか、第2回で確認します。 The post Elastic Securityで始める検知エンジニアリング — 環境構築とログの取り込み(第1回) first appeared on Elastic Portal .
Elastic Inference Service (EIS) を使った「ベクトル検索」と「生成AIによる回答(RAG)」について、全2回にわたって解説します。 第2回となる今回は「実践編」として、EIS を通じてモデルを呼び出し、「ベクトル検索」と「生成AIによる回答(RAG)」を実際に動かしてみます。 目次 前提条件 テストデータ、各種スクリプト 検索データのアップロード インデックスとパイプラインの作成 1. インデックスの作成 2. マッピングの定義 3. エイリアスの作成 4. インジェストパイプラインの作成 5. データの Reindex(ベクトル化の実行) 各種検索 キーワード検索(全文検索) ベクトル検索 (kNN) Reciprocal Rank Fusion (RRF) によるハイブリッド検索 セマンティックリランク 生成AIによる回答 技術的な補足 モデル名の指定 RRF とセマンティックリランクの役割 waganeko_tmp インデックス 参考リンク まとめ 前提条件 前回の「 準備編 」での設定が完了していることを前提とします。 テストデータ、各種スクリプト このサンプルで使用するテストデータおよび各種スクリプトは、下記の GitHub リポジトリで公開しています。 elastic-blogs/2026-03-eis at main · SIOS-Technology-Inc/elastic-blogs A sample code for blogs about Elastic. Contribute to SIOS-Technology-Inc/elastic-blogs development by creating an accoun... github.com 検索データのアップロード 今回のデモデータには、夏目漱石の『吾輩は猫である』を使用します。 青空文庫のデータ を元に、ルビを削除して NDJSON 形式に加工したファイルを用意しました。 データファイル: no_ruby_wagahai_wa_neko_dearu.ndjson アップロード手順:  README.md  を参照し、Self-Managed の Elasticsearch 上の waganeko_tmp インデックスへアップロードしてください。 インデックスとパイプラインの作成 1. インデックスの作成 まずは、形態素解析(icu/kuromoji)の設定を施した waganeko_2026_03 インデックスを作成します。 a2_create_index.md のスクリプトを Dev Tools の Console から実行してください。 2. マッピングの定義 a3_create_index_mapping.md を Self-Managed の Dev Tool の Console から実行し、waganeko_2026_03 インデックスへフィールドを作成します。 「吾輩は猫である」の本文を content フィールドに、本文から生成される密ベクトルを content_embedding フィールドへ格納するようにしています。 密ベクトルの type には、bbq_disk を指定しています。今回のデータは少量なので bbq_disk を使わなくてもよいのですが、bbq_disk の検証も兼ねて bbq_disk を使用しています。 3. エイリアスの作成 運用の利便性を高めるため、waganeko_2026_03 に対して waganeko というエイリアスを付与します。 a4_create_alias.md を実行してください。 4. インジェストパイプラインの作成 ここが EIS の真骨頂です。 a5_create_ingest_pipeline.md を実行します。 パイプライン内で指定している .jina-embeddings-v5-text-nano モデルは、Self-Managed 側にはインストールされていません。 EIS を経由することで、外部モデルをあたかもローカルモデルのように利用できます。 このパイプラインをデータ取り込み時に通過させることで、content フィールドの内容に応じた密ベクトルを生成し、content_embedding フィールドへ格納できるようになります。 5. データの Reindex(ベクトル化の実行) a6_reindex.md を実行し、waganeko_tmp から waganeko へデータをコピーします。 この際、前述のパイプラインにより自動的にベクトル化が行われます。 各種検索 ここからは、ES|QL を用いて異なる検索手法を試していきます。 キーワード検索(全文検索) まずは、従来の全部検索です。スクリプトは下記にも掲載しています。 a7_keyword_search.md POST /_query { "query": """ FROM waganeko METADATA _score, _id, _index | WHERE MATCH(content, ?query) | KEEP chunk_no, content, _score | SORT _score DESC | LIMIT 20 """, "params": [ { "query": "吾輩が生まれた場所は?" } ] } 検索結果:「場所」という単語に引っ張られ、必ずしも意図した回答(冒頭の一節)が上位に来るとは限りません。 ... "values": [ [ 1217, "しばらくは爺さんの方へ気を取られて他の化物の事は全く忘れていたのみならず、苦しそうにすくんでいた主人さえ記憶の中から消え去った時突然流しと板の間の中間で大きな声を出すものがある。見ると紛れもなき苦沙弥先生である。主人の声の図抜けて大いなるのと、その濁って聴き苦しいのは今日に始まった事ではないが場所が場所だけに吾輩は少からず驚ろいた。", 8.456548690795898 ], [ 213, "「なるほど仲居は茶屋に隷属するもので、遣手は娼家に起臥する者ですね。次に見番と云うのは人間ですかまたは一定の場所を指すのですか、もし人間とすれば男ですか女ですか」「見番は何でも男の人間だと思います」「何を司どっているんですかな」「さあそこまではまだ調べが届いておりません。その内調べて見ましょう」これで懸合をやった日には頓珍漢なものが出来るだろうと吾輩は主人の顔をちょっと見上げた。", 6.545511245727539 ], ... ] ... ベクトル検索 (kNN) 次にベクトル検索(kNN)を行ってみます。スクリプトは下記にも掲載しています。 a8_vector_search.md POST /_query { "query": """ FROM waganeko METADATA _score, _id, _index | WHERE KNN(content_embedding, TEXT_EMBEDDING(?query, ".jina-embeddings-v5-text-nano")) | KEEP chunk_no, content, _score | SORT _score DESC | LIMIT 20 """, "params": [ { "query": "吾輩が生まれた場所は?" } ] } クエリーから密ベクトルを生成するモデルには、”.jina-embeddings-v5-text-nano” を指定します。 検索結果:「どこで生れたかとんと見当がつかぬ…」という有名な冒頭部分が 1 位にランクインしました。 ... "values": [ [ 2, "どこで生れたかとんと見当がつかぬ。何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。吾輩はここで始めて人間というものを見た。しかもあとで聞くとそれは書生という人間中で一番獰悪な種族であったそうだ。この書生というのは時々我々を捕えて煮て食うという話である。しかしその当時は何という考もなかったから別段恐しいとも思わなかった。", 0.7278214693069458 ], [ 1039, "ちょうど三日目の暁方に、隣の家で赤ん坊がおぎゃあと泣いた声を聞いて、うんそうだと豁然大悟して、それから早速長い髪を切って男の着物をきて Hierophilus の講義をききに行った。首尾よく講義をきき終せて、もう大丈夫と云うところでもって、いよいよ産婆を開業した。ところが、奥さん流行りましたね。あちらでもおぎゃあと生れるこちらでもおぎゃあと生れる。", 0.7182090282440186 ], ... ] ... Reciprocal Rank Fusion (RRF) によるハイブリッド検索 さきほどのキーワード検索結果とベクトル検索結果を RRF により融合してみます。スクリプトは下記にも掲載しています。 a9_rrf.md POST /_query { "query": """ FROM waganeko METADATA _score, _id, _index | FORK (WHERE KNN(content_embedding, TEXT_EMBEDDING(?query, ".jina-embeddings-v5-text-nano")) | SORT _score DESC | LIMIT 20) (WHERE MATCH(content, ?query) | SORT _score DESC | LIMIT 20) | DROP content_embedding | FUSE | KEEP chunk_no, content, _score | SORT _score DESC | LIMIT 10 """, "params": [ { "query": "吾輩が生まれた場所は?" } ] } ES|QL の FUSE を使って RRF によるランキング融合を行っています。 ES|QL FUSE command | Elasticsearch Reference www.elastic.co 検索結果:今回は、欲しかったドキュメントのキーワード検索での順位が低かったために、RRF での結果では欲しかったドキュメントが第2位になっています。 ... "values": [ [ 1462, "今日何人あばたに出逢って、その主は男か女か、その場所は小川町の勧工場であるか、上野の公園であるか、ことごとく彼の日記につけ込んである。彼はあばたに関する智識においては決して誰にも譲るまいと確信している。せんだってある洋行帰りの友人が来た折なぞは、「君西洋人にはあばたがあるかな」と聞いたくらいだ。", 0.028958333333333336 ], [ 2, "どこで生れたかとんと見当がつかぬ。何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。吾輩はここで始めて人間というものを見た。しかもあとで聞くとそれは書生という人間中で一番獰悪な種族であったそうだ。この書生というのは時々我々を捕えて煮て食うという話である。しかしその当時は何という考もなかったから別段恐しいとも思わなかった。", 0.01639344262295082 ], ... ] ... セマンティックリランク さきほどの RRF により候補を絞り込んだ後に、セマンティックリランクを行ってみます。 セマンティックリランクに利用するモデルは、”.jina-reranker-v3″ です。 スクリプトは下記にも掲載しています。 a10_rrf_semantic_rerank.md POST /_query { "query": """ FROM waganeko METADATA _score, _id, _index | FORK (WHERE MATCH(content, ?query) | SORT _score DESC | LIMIT 20) (WHERE KNN(content_embedding, TEXT_EMBEDDING(?query, ".jina-embeddings-v5-text-nano")) | SORT _score DESC | LIMIT 20) | DROP content_embedding | FUSE | SORT _score DESC | LIMIT 10 | RERANK ?query ON content WITH { "inference_id" : ".jina-reranker-v3" } | KEEP chunk_no, content, _score | SORT _score DESC """, "params": [ { "query": "吾輩が生まれた場所は?" } ] } ES|QL の RERANK コマンドを使ってセマンティックリランクを行います。 ES|QL RERANK command | Elasticsearch Reference www.elastic.co 注目してほしいのは、Self-Managed の Elasticsearch には .jina-reranker-v3 をインストールしていないにもかかわらず、利用できる点です。 検索結果:欲しかったドキュメントが第1位になりました。 ... "values": [ [ 2, "どこで生れたかとんと見当がつかぬ。何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。吾輩はここで始めて人間というものを見た。しかもあとで聞くとそれは書生という人間中で一番獰悪な種族であったそうだ。この書生というのは時々我々を捕えて煮て食うという話である。しかしその当時は何という考もなかったから別段恐しいとも思わなかった。", 0.33165714144706726 ], [ 1217, "しばらくは爺さんの方へ気を取られて他の化物の事は全く忘れていたのみならず、苦しそうにすくんでいた主人さえ記憶の中から消え去った時突然流しと板の間の中間で大きな声を出すものがある。見ると紛れもなき苦沙弥先生である。主人の声の図抜けて大いなるのと、その濁って聴き苦しいのは今日に始まった事ではないが場所が場所だけに吾輩は少からず驚ろいた。", 0.08227790892124176 ], ... ] ... 生成AIによる回答 最後に、検索結果のコンテキストを LLM に渡し、自然言語で回答を生成させます。 やや乱暴ですが、セマンティックリランクの結果の第1位のドキュメントの内容を元にして、生成AI に質問に回答するよう依頼してみます。 回答に使用するモデルは、.openai-gpt-oss-120b-completion です。 スクリプトは下記にも掲載しています。 a11_completion.md POST /_query { "query": """ FROM waganeko METADATA _score, _id, _index | FORK (WHERE MATCH(content, ?query) | SORT _score DESC | LIMIT 20) (WHERE KNN(content_embedding, TEXT_EMBEDDING(?query, ".jina-embeddings-v5-text-nano")) | SORT _score DESC | LIMIT 20) | DROP content_embedding | FUSE | SORT _score DESC | LIMIT 10 | RERANK ?query ON content WITH { "inference_id" : ".jina-reranker-v3" } | SORT _score DESC | KEEP content | LIMIT 1 | COMPLETION CONCAT("Answer in Japanese the following question ", ?query, " based on:\n", content) WITH { "inference_id" : ".openai-gpt-oss-120b-completion" } """, "params": [ { "query": "吾輩が生まれた場所は?" } ] } ES|QL の COMPLETION コマンドを利用しています。 ES|QL COMPLETION command | Elasticsearch Reference www.elastic.co 注目してほしいのは、Self-Managed の Elasticsearch には .openai-gpt-oss-120b-completion をインストールしていないにもかかわらず、利用できる点です。 回答結果の例 吾輩は「薄暗く湿った所」、すなわち暗くてじめじめした場所で生まれました。 (「どこで生れたかとんと見当がつかぬ。何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。」という記述に基づく。) 合っているようです。 技術的な補足 モデル名の指定 EIS で利用するモデル名は、Elastic Cloud の Relevance > Inference endpoints 画面に表示される Endpoint を使用します。 RRF とセマンティックリランクの役割 本サンプルでは、RRF とセマンティックリランクを併用しています。 Reciprocal Rank Fusion (RRF): キーワードとベクトルの異なる検索手法を統合し、候補を漏れなく抽出する「絞り込み」のフェーズ。 セマンティックリランク: 絞り込まれた上位ドキュメントに対し、LLM 的な文脈理解で「真の回答」を最上位に持ってくる「仕上げ」のフェーズ。 waganeko_tmp インデックス waganeko_tmp インデックスの内容を waganeko インデックスへ reindex した後は、waganeko_tmp インデックスは不要となります。 必要なければ、削除してかまいません。 参考リンク Cloud Connect を利用した場合の追加費用については、下記を参照してください。 https://cloud.elastic.co/cloud-pricing-table?productType=cloud_connect まとめ Self-Managed の Elasticsearch であっても、Elastic Inference Service (EIS)を活用することで、 重い推論モデルを自前で管理・運用することなく、ベクトル検索やセマンティックリランク、生成AIによる回答を極めてシンプルに実装できました。 ぜひ、皆さんの環境でも EIS を活用した高度な検索体験を試してみてください。 The post Elastic Inference Service (EIS) を使った「ベクトル検索」および「生成AIによる回答(RAG)」(実践編) first appeared on Elastic Portal .
Elastic Inference Service (EIS) を使った「ベクトル検索」と「生成AIによる回答(RAG)」について、全2回にわたって解説します。 第1回となる今回は「準備編」として、環境構築からクラウド連携までを詳しく説明します。 目次 Elastic Inference Service (EIS) とは? 本連載で実現できること システム構成イメージ 動作確認環境 サンプルコード ベクトル検索のための準備作業 1. 環境変数の準備 2. コンテナの起動 3. Elastic Cloud 連携 (Cloud Connect) 3.1. Self-Managed Kibana へのログイン 3.2. Cloud Connect 画面への移動 3.3. Elastic Cloud へのログインと接続 次回予告 Elastic Inference Service (EIS) とは? Elastic Inference Service (EIS) は、Elastic Cloud 上で推論モデルをホスト・運用するためのマネージドサービスです。 従来、Self-Managed(オンプレミスや独自インスタンス)の Elasticsearch でベクトル検索やAI回答を行うには、自前で推論用ノードを構築・管理する必要がありました。EIS を活用することで、インフラ管理の手間を抑えつつ、強力なベクトル検索機能を Self-Managed 環境に組み込むことが可能になります。 公式ドキュメント: Elastic Inference Service (EIS) | Elastic Docs 本連載で実現できること 今回と次回の記事を通して、以下の機能を実装します。 Embedding: 外部モデルによるベクトル生成およびベクトル検索 Rerank: セマンティック・リランクによる検索精度の向上 Completion: LLM(OpenAI等)を利用した RAG(生成AI回答)の実現 システム構成イメージ 今回の構成は、Self-Managed 側のリソースを抑えつつ、計算負荷の高い推論処理を Elastic Cloud に委託するハイブリッドな構成です。 [Self-Managed Elasticsearch] <--- Elastic Cloud Connect ---> [Elastic Cloud (EIS)] Self-Managed 側に重いモデルをデプロイする必要がないため、既存環境への導入ハードルが低いのが特徴です。 [!CAUTION] 課金に関する注意 モデルの使用量に応じて、Elastic Cloud の利用料が発生します。検証の際は、トークン消費量やモデルの起動時間に十分ご注意ください。 動作確認環境 記事の執筆にあたり、以下の環境で動作を確認しています。 Elastic Cloud: Enterprise License Self-Managed Elasticsearch: v9.3.2 (Trial License) OS/Tool: Windows版 Rancher Desktop v1.20.1 利用モデル: Jina-embeddings-v5-text-nano Jina-reranker-v3 OpenAI-gpt-oss-120b-completion サンプルコード 本記事で使用するスクリプトや設定ファイルは、以下の GitHub リポジトリで公開しています。 GitHub:  SIOS-Technology-Inc/elastic-blogs/2026-03-eis ベクトル検索のための準備作業 ※作業には、ログイン可能な Elastic Cloud アカウントがあらかじめ必要です。 1. 環境変数の準備 リポジトリ内の  .env.sample  をコピーして .env を作成し、各項目を環境に合わせて編集します。 cp .env.sample .env 主な設定項目: ELASTIC_PASSWORD: Elasticsearch の elastic ユーザ用パスワード SAVEDOBJECTS_ENCRYPTIONKEY: 32文字以上のランダムな文字列(Kibana用) ES01_MEM_LIMIT: es01 コンテナに割り当てるメモリサイズ KIBANA_MEM_LIMIT: kibana コンテナに割り当てるメモリサイズ 2. コンテナの起動 Rancher Desktop 等の Docker ランタイムが起動していることを確認します。 docker-compose.yml  ファイル、および、  Dockerfile-es01  ファイルがあるディレクトリ上で以下のコマンドを実行します。 docker-compose up -d --build ※初回起動時はプラグインのインストールが走るため、完了まで数分かかります。 ※本構成は検証用のため、シングルノード構成となっています。 3. Elastic Cloud 連携 (Cloud Connect) 3.1. Self-Managed Kibana へのログイン ブラウザで  http://localhost:5601  にアクセスします。 User: elastic Password: .env で設定した ELASTIC_PASSWORD 3.2. Cloud Connect 画面への移動 Home > Management > Cloud Connect を選択します。 3.3. Elastic Cloud へのログインと接続 画面の指示に従い、Elastic Cloud へログインします。 Elastic Cloud にログイン後、Cloud Connect API Key を発行・コピーします。 取得したキーを Self-Managed 側の Kibana 画面に貼り付け、[Connect] をクリックします。 ステータスが正常になれば、Self-Managed 環境と Elastic Cloud の連携は完了です! 次回予告 今回は、Cloud Connect を利用して Self-Managed Elasticsearch と Elastic Cloud を橋渡しする手順を解説しました。 次回(実践編)は、いよいよ EIS を通じてモデルを呼び出し、「ベクトル検索」と「生成AIによる回答(RAG)」を実際に動かしてみます。お楽しみに! The post Elastic Inference Service (EIS) を使った「ベクトル検索」および「生成AIによる回答(RAG)」(準備編) first appeared on Elastic Portal .
SIOS Technology, Inc. Saman 本記事では、 Elastic Security Labs が公開しているレポートを紹介します。こちらのレポートは、単なる「新種マルウェア発見のお知らせ」ではなく、攻撃の全体像を丁寧に解体し、防御側が何をすべきかを具体的に示しています。 目次 攻撃の概要:5段階で忍び込む「ClickFix」キャンペーン 「怪しい外国語のサイトだから気づける」はもう通用しない MIMICRATとは何か 「正面玄関」を使われると、ドアは閉められない Elastic Security Labsの研究が示した重要な学び まとめ 用語集 攻撃の概要:5段階で忍び込む「ClickFix」キャンペーン Elastic Security Labsが発見したこのキャンペーン、通称「ClickFix」は、 ソーシャルエンジニアリング主導型の攻撃 です。システムの脆弱性ではなく「人の心理」を利用して騙す手法で、自前の悪意あるサイトを用意するのではなく、実在する正規サイトに不正スクリプトをひそかに埋め込みます。 たとえるなら、本物の企業サイトに「偽の案内ポップアップ」をこっそり貼り付けるようなイメージです。見た目は本物なので疑われにくいのが特徴です。 攻撃の流れはこうです: 正規ウェブサイトへの不正侵入 偽の「PCに問題があります」メッセージを表示 ユーザー自身がPowerShellコマンドを貼り付けて実行 複数のローダー(次の処理を呼び出す起動係)がメモリ上で連鎖動作 最終ペイロード「MIMICRAT」が展開される ここで特筆すべきは、 脆弱性の悪用もゼロデイ攻撃も使っていない という点です。必要なのは「このコマンドを実行してください」という一言だけ。技術ではなく、人間心理を突く設計になっています。 「怪しい外国語のサイトだから気づける」はもう通用しない このキャンペーンがさらに厄介なのは、 言語の壁を取り払っている 点です。攻撃プログラムはアクセス者のブラウザ言語設定を自動的に読み取り、偽のエラー画面をその言語で表示します。日本語環境なら日本語で、英語環境なら英語で。対応言語は日本語・英語・中国語・韓国語を含む17言語に及びます。 対応言語リストに「Japanese(日本語)」が明記されている以上、日本に住む私たちも攻撃者の射程圏内です。 ただし、攻撃者は特定の企業や国を狙い撃ちしているわけではありません。「母国語で表示して安心させ、世界中の誰でもいいから騙す」という日和見主義的な戦略です。標的を絞らないからこそ、逆に誰もが対象になりえます。 つまり、「普段使っている言葉で自然に罠にかかる」危険性があるということです。 MIMICRATとは何か MIMICRATはC/C++で書かれたカスタムRAT(Remote Access Trojan)、つまり感染したPCを遠隔操作できるマルウェアです。 感染したマシン上で攻撃者ができることは多岐にわたります。 Windowsログイントークンの窃取 — パスワードなしでなりすましが可能になるデジタル証明書のような情報を盗む 任意コマンドの実行 — 遠隔から操作命令を送ることができる ファイルの読み書き SOCKS5プロキシトンネルの確立 — 感染PCを”踏み台”として外部通信に利用する そして最大の特徴が、攻撃者との通信(C2通信)に HTTPS/ポート443 を使用していることです。 「正面玄関」を使われると、ドアは閉められない 会社のビルに「正面玄関」があるとします。社員も来客も配達員も、みんなそこを使います。インターネットでいえば、これがHTTPS/ポート443です。 MIMICRATも、このまったく同じドアを使います。裏口を探さない。窓を割らない。普通の顔をして、正面から堂々と歩いてくる。 当然、セキュリティチームはこのドアを閉めることができません。閉めれば、インターネット全体が止まります。 では、どうやって見破るのか。 答えは**「行動の異常を観察すること」です。従来型のセキュリティは、過去に確認された”指紋”と一致するかを見るシグネチャベース検出**が中心でした。しかし今回はそれが通用しません。 代わりに必要なのは、たとえば次のような視点です。 普段PowerShellを使わないPCが突然スクリプトを実行している 深夜に30秒ごと特定サーバーへ通信している 通常触らないシステムファイルへアクセスしている これが**振る舞い検知(Behavioral Detection)**の考え方です。「これは既知の悪いものか?」ではなく、「これは普段と違う動きをしているか?」を見るのです。 では、その“行動の異常”をどうやって見つけるのか。 ここで重要になるのが、エンドポイントやネットワークのテレメトリを一元的に収集し、通常時の振る舞いと比較できる仕組みです。 Elastic Securityは、エンドポイント・ネットワーク・ログを横断して可視化し、振る舞いベースで検出ルールを構築できる設計になっています。単なる「ウイルス検知」ではなく、攻撃の流れを追える点が特徴です。 Elastic Security Labsの研究が示した重要な学び Elastic Security Labsは、マルウェアを特定しただけではありません。今回の分析から、防御側にとって重要な示唆がいくつか得られています。 攻撃は「単発イベント」ではなく「連鎖」である 。1つのステップだけを見ても全体像は見えません。攻撃チェーン全体を追える視点が必要です。 「監視カメラ」を止めてから動く 。MIMICRATはAMSI(スクリプトのウイルス検査機能)とETW(Windowsのログ記録機能)を無効化します。こうしたログ無効化の動きは単体では見逃されがちですが、プロセス実行履歴・スクリプトログ・メモリ挙動を横断的に分析すれば、攻撃の痕跡は残ります。 ファイルに痕跡を残さない 。MIMICRATは主にメモリ上で動作し、ディスクにファイルを残しません。そのため従来型のアンチウイルスによる検出が難しく、振る舞いベースの監視が欠かせません。 現代でも人間が最大の侵入口 。ゼロデイも高度な侵入技術も不要でした。必要だったのは「ユーザーにコマンドを貼り付けさせる」だけです。 まとめ MIMICRATは高度です。しかし、どの段階にも痕跡は残ります。 重要なのは、ファイル単体ではなく 攻撃の流れを見る視点 です。マルウェアは常に変わりますが、攻撃の進め方のパターンは急には変わりません。 Elastic Securityは、エンドポイント・ネットワーク・ログを横断して可視化し、振る舞いベースで検出ルールを構築できる設計になっています。単なる「ウイルス検知」ではなく、攻撃の流れを追える点が特徴です。 用語集 用語 意味 RAT 遠隔操作が可能なマルウェア C2(Command & Control) 感染PCと攻撃者をつなぐ通信回線 PowerShell Windowsに標準搭載された管理用コマンドツール ローダー 次のプログラムを起動する小さなプログラム ゼロデイ攻撃 まだ修正されていない未知の脆弱性を突く攻撃 AMSI Windowsのスクリプト検査機能 ETW Windowsのログ記録機能 HTTPS / ポート443 通常の安全なウェブ通信 シグネチャベース検出 既知のウイルスの”指紋”と一致するかを見る方式 振る舞い検知 通常と異なる行動パターンを検出する方式 テレメトリ PCの動作ログや行動記録データ The post 改ざんされた正規サイトから拡散:ClickFixキャンペーンが配布するカスタムRAT「MIMICRAT」の実態 first appeared on Elastic Portal .
SIOS Technology, Inc. Saman 目次 はじめに:この記事で解決できること 問題の本質:フルスキャン前提の設計 解決策の発想:Elasticsearch Transformsとは何か Transformの構造を理解する サンプルデータで効果を検証する 実験①:高cardinalityキーでの集約(clientip × 1時間) 実験②:低cardinalityキーでの集約(response × 1時間) Transformが生む2種類の圧縮 ① 縦方向の圧縮(行を減らす) ② 横方向の圧縮(列を減らす) 実行手順 まとめと設計指針 はじめに:この記事で解決できること 数十億件規模のElasticsearchで、ダッシュボード表示のたびに数十秒待つ、そんな問題を抱えているなら、原因はクエリではなく 設計 にあるかもしれません。 本記事では、SIOS Technologyのサマンが実務で直面した問題とその解決策として、 Elasticsearch Transforms を使った事前計算パターンを説明します。サンプルデータを使った実験結果も含め、実際に得られる効果を再現できる手順を紹介します。 問題の本質:フルスキャン前提の設計 以前担当したプロジェクトでは、Kibanaダッシュボードを開くたびにタイムアウトが発生していました。最初はクエリチューニングやノード増強を検討しましたが、根本原因は runtime fieldを使ったフルスキャン前提の設計 にありました。 実装していたES|QLクエリはこのようなものです。 FROM <巨大インデックス> | EVAL metric = GREATEST(fieldA, fieldB) | STATS MAX(metric) BY group_id 理論上は正しいクエリです。しかし数十億件に対してこれを毎回実行すると、全期間スキャン→全行で演算→高cardinalityフィールドで集約という処理をダッシュボード表示のたびに繰り返すことになります。 「これはクエリの問題ではなく、設計の問題だ」 と気づいたことが解決の出発点でした。 解決策の発想:Elasticsearch Transformsとは何か Elasticsearch Transformsは、生データを別インデックスに事前集計して保存する機能です。 生データインデックス → Transform → サマリーインデックス ダッシュボードやアラートは軽量なサマリーインデックスだけを参照するため、検索のたびに重い計算を繰り返す必要がなくなります。 重要な点として、**Transformは「クエリを速くするツール」ではなく「データ構造を再設計するツール」**です。効果の大小は、 group_by の設計——何をキーにまとめるか——に直接依存します。 Transformの構造を理解する 実験の前に、Transformがどういう構造を持つかを把握しておきましょう。 PUT _transform/<name> { "source": { ... }, "pivot": { ... }, "dest": { ... }, "settings": { ... } } source :読み込むインデックスを指定します。クエリフィルターを加えることで、不要なデータを事前に除外できます。 "source": { "index": "kibana_sample_data_logs", "query": { "range": { "@timestamp": { "gte": "now-90d" } } } } pivot :最も重要なブロックです。group_byでどの粒度にまとめるかを、aggregationsで何を計算するかを定義します。設計ミスはほぼここで起きます。 "pivot": { "group_by": { "timestamp_hour": { "date_histogram": { "field": "@timestamp", "calendar_interval": "1h" } }, "response": { "terms": { "field": "response.keyword" } } }, "aggregations": { "request_count": { "value_count": { "field": "bytes" } }, "total_bytes": { "sum": { "field": "bytes" } } } } dest :出力先インデックスを指定します。以後のダッシュボードやアラートはこのインデックスだけを参照します。 settings :大規模環境では必須の安全装置です。max_page_search_sizeは一度に処理するドキュメント数を制御し、メモリ枯渇を防ぎます。値はクラスタのヒープメモリに応じて調整が必要です(デフォルトは500。余裕がなければ100〜200程度から始めるのが無難です)。 "settings": { "max_page_search_size": 100 } サンプルデータで効果を検証する ここからはElasticでデフォルトで入っているkibana_sample_data_logs(約14,000件、約8.4MB)を使って、group_by設計の違いがどれほど結果に影響するかを確認します。 実験①:高cardinalityキーでの集約(clientip × 1時間) clientipはほぼリクエストごとに異なるIPアドレスです。これを1時間単位と組み合わせてgroup_byに使うと、グループがほとんど1件ずつになり、まとめる対象がありません。 PUT _transform/sample-ip-hourly-v1 { "source": { "index": "kibana_sample_data_logs" }, "pivot": { "group_by": { "timestamp_hour": { "date_histogram": { "field": "@timestamp", "calendar_interval": "1h" } }, "clientip": { "terms": { "field": "clientip" } } }, "aggregations": { "total_bytes": { "sum": { "field": "bytes" } }, "request_count": { "value_count": { "field": "bytes" } }, "error_count": { "filter": { "term": { "response.keyword": "404" } } }, "error_rate": { "bucket_script": { "buckets_path": { "errors": "error_count._count", "total": "request_count" }, "script": "params.total > 0 ? (params.errors / params.total) * 100 : 0" } } } }, "dest": { "index": "summary-ip-hourly" } } POST _transform/sample-ip-hourly-v1/_start 結果: ドキュメント数:13,844件(元データとほぼ同数) サイズ:約2.7MB Transformは実行されていますが、圧縮効果はほぼゼロです。 cardinalityが高いキーは、まとめるべき単位として機能しません。 実験②:低cardinalityキーでの集約(response × 1時間) response(HTTPステータスコード)は200、404、503など数種類しかありません。これを1時間単位でまとめると、同じ時間帯の同じレスポンスコードが大量にひとつのドキュメントに集約されます。 PUT _transform/sample-response-hourly-v1 { "source": { "index": "kibana_sample_data_logs" }, "pivot": { "group_by": { "timestamp_hour": { "date_histogram": { "field": "@timestamp", "calendar_interval": "1h" } }, "response": { "terms": { "field": "response.keyword" } } }, "aggregations": { "request_count": { "value_count": { "field": "bytes" } }, "total_bytes": { "sum": { "field": "bytes" } }, "error_flag_count": { "filter": { "range": { "response.keyword": { "gte": "400" } } } }, "error_rate": { "bucket_script": { "buckets_path": { "errors": "error_flag_count._count", "total": "request_count" }, "script": "params.total > 0 ? (params.errors / params.total) * 100 : 0" } } } }, "dest": { "index": "summary-response-hourly" } } POST _transform/sample-response-hourly-v1/_start 結果: ドキュメント数:2,005件( 約85%削減 ) サイズ:約405KB( 約95%削減 ) サイズを確認するには、summary-response-hourly/*stats を実行し、レスポンス内の “store” フィールドにある “size_in_bytes” の値を確認できます。 この劇的な差はどこから来るのでしょうか。 Transformが生む2種類の圧縮 Transformが実現する圧縮は、実は2方向で同時にやります。 ① 縦方向の圧縮(行を減らす) 元ログ: 時刻 response bytes 10:01 200 1000 10:05 200 2000 10:10 200 1500 10:15 404 300 10:20 404 500 5行あります。 これを 1時間 × response でまとめると: 時間 response total_bytes 10:00 200 4500 10:00 404 800 5行 → 2行 これが縦方向の圧縮です。 同じカテゴリが繰り返し出るほど効果は大きくなります。 ② 横方向の圧縮(列を減らす) 元ログには多くのフィールドがあります。 message agent geo request referer tags …… でも、集約に必要なのは: 時間 response bytes だけ。 Transform後のインデックスには、不要なフィールドは存在しません。 つまり、列が消える。 今回サイズが95%削減された理由はここにあります。 実行手順 # 1. Transformを作成 PUT _transform/summary-response-hourly { ... } # 2. 実行前にプレビューで確認(大規模環境では必須) POST _transform/summary-response-hourly/_preview # 3. 起動 POST _transform/summary-response-hourly/_start # 4. 状態確認 GET _transform/summary-response-hourly/_stats # 5. 必要に応じて停止・削除 POST _transform/summary-response-hourly/_stop DELETE _transform/summary-response-hourly まとめと設計指針 Transformsを導入する前に、以下の問いに答えてみてください。 この計算は、本当に検索時にやる必要がありますか? 答えがNoであれば、Transformは有効な選択肢です。設計時には以下の点に注意してください。 group_byのcardinalityを下げる ことが効果の前提条件。高cardinalityキーは原則として避ける 必要なフィールドだけを残す 設計にすることで、横方向の圧縮も最大化できる _preview で必ず事前検証 してから本番適用する max_page_search_sizeはクラスタのリソースに合わせて調整する スケールが大きくなるほどTransformの効果は大きくなります。数億・数十億件規模の時系列データを扱っているなら、「事前計算+サマリーインデックス」という設計パターンは真っ先に検討すべき選択肢です。 The post Elasticsearch Transforms入門ガイド|重い集計クエリを事前計算で解決する方法 first appeared on Elastic Portal .
目次 はじめに 開発環境 構成図 事前準備 リポジトリの取得と展開 環境変数の設定 コンテナの起動 EDOT Collector の設定 5.1. Python コンテナへの接続 5.2. EDOT Collector のダウンロード Elasticsearch との連携設定 6.1. System OpenTelemetry Assets の有効化 6.2. API Key の生成 6.3. otel.yml の編集 6.4. EDOT Collector の起動 Python アプリのトレース取得 7.1 appuser で Python コンテナへ接続する 7.2. 計装 (Instrumentation) の準備 7.3. Python アプリの実行 観測データの確認 8.1. Dashboard の表示 8.2. Logs の表示 8.3. トレースの表示 まとめ 参考URL はじめに これまで Elastic Observability でフルスタックな観測を実現するには、Fleet Server や Elastic Agent、および各 Integration(System, APM等)の個別設定が必要でした。 しかし、最新の Elastic Observability (v9.2以降) では、OpenTelemetry (OTel) をネイティブにサポート。 これにより、独自エージェントの複雑な管理をスキップして、より標準的かつ柔軟にデータを集約できるようになりました。 本記事では、この新しい機能の使い方を解説します。 開発環境 Elasticsearch / Kibana: v9.2.4 Basic License Python : v3.14 Docker環境 : 筆者は Windows 上の Rancher Deskop 1.20.1 を利用 ※ステータス: OpenTelemetry Integration は、Elasticsearch 9.2 時点で Preview です。 構成図 今回の構成では、Pythonアプリケーションが稼働するコンテナ内に EDOT (Elastic Distribution of OpenTelemetry) Collector を配置し、そこから直接 Elasticsearch へデータを送信します。 事前準備 リポジトリの取得と展開 まずは検証用コードをダウンロードします。 https://github.com/SIOS-Technology-Inc/elastic-blogs/tags  にアクセスします。 release-2026-02-02 をクリックします。 Assets の Source code (zip) をクリックします。 elastic-blogs-release-2026-02-02.zip がダウンロードされます。 elastic-blogs-release-2026-02-02.zip を解凍します。 環境変数の設定 Windows などでターミナルを開きます。 2026-02-otel/app フォルダに移動します。 cd 2026-02-otel/app .env.sample をコピーして、パスワードやメモリ制限などの環境変数を設定します。 cp .env.sample .env メモ帳などで .env ファイルを編集します。 ... ELASTIC_PASSWORD=... (Elasticsearchのパスワードを設定します。) KIBANA_PASSEORD=... (Kibana用の内部パスワードを設定します。) ... SAVEDOBJECTS_ENCRYPTIONKEY=... (SavedObjects用の暗号化キーを設定します。) ... ES01_MEM_LIMIT=... (Elasticsearchのメモリ上限を設定します。) KB_MEM_LIMIT=... (Kibanaのメモリ上限を設定します。) コンテナの起動 docker compose -f docker-compose-es-kibana-python.yml up -d EDOT Collector の設定 5.1. Python コンテナへの接続 ※今回は、Python を動かすコンテナに Elastic Distribution of OpenTelemetry (EDOT) Collector をインストールするので、Python コンテナへ接続します。 root 権限でインストールおよび実行するので、-u 0 を指定します。 docker exec -itu 0 app-python-app-1 /bin/bash 5.2. EDOT Collector のダウンロード 下記で Elastic 9.2.4 用の EDOT Collector をダウンロードします。 wget https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-9.2.4-linux-x86_64.tar.gz tar xvfz elastic-agent-9.2.4-linux-x86_64.tar.gz cd elastic-agent-9.2.4-linux-x86_64 # 設定用ディレクトリの作成とサンプルのコピー mkdir data/otel cp ../otel.yml.sample otel.yml otel.yml.sample は、あらかじめ elastic-agent-9.2.4-linux-x86_64 内の otel.yml.sample を抽出し、改変したものです。 exporters/elasticsearch/otel/tls などを改変しています。 ※otel.yml の編集は、後で行います。 Elasticsearch との連携設定 6.1. System OpenTelemetry Assets の有効化 Web ブラウザから  http://localhost:5601  へアクセスし、 ユーザーID: elastic パスワード: 4.2. で ELASTIC_PASSWORD に設定した文字列 で Kibana にログインします。 Management / Integrations 画面を表示します。 Display: beta integrations を ON にします(※System OpenTelemetry Assets は、Elastic 9.2.4 の時点では Preview 版のため)。 System OpenTelemetry Assets を検索し、クリックします。 右上の [↓ Install System OpenTelemetry Assets] ボタンをクリックします。 Install System OpenTelemetry Assets のダイアログが表示されるので、右下の [Install System OpenTelemetry Assets] ボタンをクリックします。 ※Assets欄にあるダッシュボードがインストールされます。 6.2. API Key の生成 EDOT Collector から Elasticsearch へ書き込むための API Key を生成し、控えておきます。 Kibana の Home 画面から Elasticsearch アイコンをクリックします。 [Create API key ] ボタンをクリックします。 Name : otel と入力し、[Create API key] をクリックします。 API Key が生成されるので、コピーしておきます(メモ帳などに一時的にペーストしておきます)。 6.3. otel.yml の編集 Python を動作させているコンテナ上で作業します。 vi otel.yml 取得した API Key を 5.2. で配置した otel.yml に反映させます。 ... exportes: elasticsearch/otel: endpoints: ["https;//es01:9200"] api_key: "YOUR_API_KEY_HERE" ... 6.4. EDOT Collector の起動 今回は、あくまでも検証用のための実行なので、ターミナルからバックグラウンドで実行します。 ./otelcol --config ./otel.yml >> /var/log/otelcol.log 2>&1 & これで、Python コンテナのログやメトリクスが Elasticsearch へ送信されるようになります。 このコンテナからは、exit して OK です。 Python アプリのトレース取得 7.1 appuser で Python コンテナへ接続する docker exec -it app-python-app-1 /bin/bash 7.2. 計装 (Instrumentation) の準備 OpenTelemetry のライブラリをインストールします。 edot-bootstrap --action=install opentelemetry-bootstrap -a install 7.3. Python アプリの実行 コードに Elastic 専用の処理を書く必要はありません。 opentelemetry-instrument を冠して実行するだけで、自動的にトレースが送信されます。 実行する Python アプリ (src/test.py) のソースコード 3回ループするだけの単純な Python コードです。 import time from opentelemetry import trace def func1_sub(tracer): with tracer.start_as_current_span("func1_sub"): print ("Hello") time.sleep(1) def func1(tracer): with tracer.start_as_current_span("func1"): i = 0 while i < 3: func1_sub(tracer) i += 1 if __name__ == "__main__": tracer = trace.get_tracer(__name__) func1(tracer) Python アプリを実行します。 opentelemetry-instrument python src/test.py このコンテナからは exit して OK です。 観測データの確認 8.1. Dashboard の表示 Kibana の Analytics / Dashboard からダッシュボードを表示してみます。 [Otel] Hosts Overview ※このダッシュボードは、6.1 で追加されたものです。 EDOT Collector を動作させているホストの稼働状況が可視化されます。 [Otel] Host Details – Metrics EDOT Collector を動作させているホストの CPU や Memory, Network など各種メトリクスが可視化されます。 8.2. Logs の表示 Kibana の Discover から logs-* を表示してみます。 EDOT Collector を動作させているホストの /var/log/*.log の内容が表示されます。 ※ログが表示されない場合、表示対象期間を調整してみてください。 8.3. トレースの表示 Kibana の Observability / Application 画面を表示します。 Service inventory 画面が表示されます。 my-python-script を選択します。 “my-python-script” という名前は、python/Dockerfile に OTEL_SERVICE_NAME として記載していたものです。 my-python-script の Overview が表示されます。 Transactions をクリックします。 src/test.py のトランザクションに関する情報が表示されます。 画面の下の方の Transactions の func1 をクリックします。 func1 の trace 情報が表示されます。 func1 内で func1_sub が3回実行され、実行時間はそれぞれ、3秒、1秒となっていることがわかります。 ※ “func1” や “func1_sub” といった名前は、src/test.py 内に記載したものです。 まとめ OpenTelemetry を採用することで、以下の大きなメリットが得られます。 運用の簡素化: Fleet Server や複雑な Agent 管理から解放されます。 脱ベンダーロックイン: 業界標準のプロトコル(OTLP)を使用するため、将来的なプラットフォームの移行や併用が容易になります。 ポータビリティ: Elastic 固有のコードをアプリに埋め込む必要がなくなり、コードの純粋性を保てます。 現在 Preview 機能ですが、今後の Observability のデファクトスタンダードになることが予想されます。ぜひ今のうちに触れてみてください。 参考URL https://qiita.com/takeo-furukubo/items/2747bdf3e28037b1870b https://qiita.com/takeo-furukubo/items/5f5322977daf6d48fc8c https://www.elastic.co/docs/solutions/observability/get-started/opentelemetry/quickstart/self-managed/hosts_vms https://github.com/SIOS-Technology-Inc/elastic-blogs The post OpenTelemetry を使って Elastic Observability にログ、メトリクス、トレースを取り込んでみよう。 first appeared on Elastic Portal .
目次 はじめに 開発環境 事前準備 メインデータの用意(Sample web logs) 国マスタのインポート Lookup Index への変換 【実践】ES|QL での集計比較 Lookup Join なし(国コードのみ) Lookup Join あり(国名を結合) まとめ 参考資料 添付資料:country_list.csv はじめに これまで Elasticsearch で「メインのインデックスに、別インデックスの情報を紐付けて表示したい」場合、Enrich Processor を使用して、取り込み(Ingest)フェーズであらかじめデータを結合しておくのが一般的でした。 しかし、この方法ではデータの更新のたびに Enrich Policy の再実行が必要になるなど、運用の手間がかかる側面がありました。 最新の Elasticsearch では、ES|QL の LOOKUP JOIN 機能が登場し、クエリ実行時にリアルタイムで別インデックスの情報を参照できるようになりました。本記事では、この便利な新機能の使い方を紹介します。 開発環境 Elasticsearch / Kibana: v9.2.4 Chrome ※注意事項: LOOKUP JOIN … ON … == … の記法は、Elasticsearch 9.2 時点で Preview です。 事前準備 メインデータの用意(Sample web logs) 今回は Kibana に標準で用意されている「Sample web logs」を使用します。 まだ取り込んでいない場合は、Kibana ホームの「Add data」から Sample web logs を追加してください。 参考: https://elastic.sios.jp/blog/elasticsearch-esql-introduction-log-analysis/ 国マスタのインポート この記事の末尾に記載している country_list.csv を使用して、マスタデータを作成します。 ※筆者は、Webブラウザに Chrome を使用しました。 Kibana の Home > Upload a file を開きます。 country_list.csv をアップロードし、設定を以下のように変更します。 Index name: country_list Advanced options > Data view: off(マスタなので Data view は不要です) [Import] をクリックします。 Lookup Index への変換 ES|QL の Lookup Join を利用するには、通常のインデックスを「Lookup 用」に変換する必要があります。 Stack Management > Index Management から country_list を選択します。 2. Manage ボタンから Convert to lookup index をクリックします。 3. Lookup index name に lookup-country_list と入力し、Convert を実行します。 Note: この操作により、インメモリで高速に結合可能な特殊なインデックスが生成されます。元の country_list もそのまま残ります。 【実践】ES|QL での集計比較 Lookup Join なし(国コードのみ) まずは、通常の集計を行ってみます。 Kibana の Discover を開き、上部の [Try ES|QL] をクリックします。 以下のクエリを入力して実行します。 FROM kibana_sample_data_logs | STATS bytes_sum = sum(bytes) BY geo.dest | KEEP geo.dest, bytes_sum | SORT bytes_sum DESC | LIMIT 8 集計対象の期間は、適当に調整してください。下記の例では、Last 24 hours を指定しています。 結果: geo.dest 項目に CN や US といった 2 桁の国コードが表示されます。これだけでは、直感的にどの国か分かりにくいですよね。 Lookup Join あり(国名を結合) 次に、LOOKUP JOIN を使って国マスタから国名を引っ張ってきます。 FROM kibana_sample_data_logs | STATS bytes_sum = sum(bytes) BY geo.dest | LOOKUP JOIN lookup-country_list ON geo.dest == country_code | KEEP country_name, bytes_sum | SORT bytes_sum DESC | LIMIT 8 結果: country_name が結合され、「CHINA」「UNITED STATES」といった具体的な国名が表示されるようになります! まとめ ES|QL の LOOKUP JOIN を使うメリットは以下の通りです。 運用の簡略化: Enrich Policy を管理・更新する手間が省ける。 直感的な記述: SQL の JOIN に近い感覚で、クエリ内で動的に結合できる。 柔軟性: 必要なときだけマスタ情報を付与できる。 現在は Preview 機能ですが、将来的に Elasticsearch でのログ分析やレポート作成において、欠かせない機能になるはずです。 参考資料 Elastic公式: LOOKUP JOIN command https://www.elastic.co/docs/reference/query-languages/esql/commands/lookup-join 添付資料:country_list.csv 国マスタのCSVです。 ※このデータは、 https://www.e-tax.nta.go.jp/toiawase/qa/crs/countrycode.htm を元に生成したものです。 country_code,country_name AF,AFGHANISTAN AX,ALAND ISLANDS AL,ALBANIA DZ,ALGERIA AS,AMERICAN SAMOA AD,ANDORRA AO,ANGOLA AI,ANGUILLA AQ,ANTARCTICA AG,ANTIGUA AND BARBUDA AR,ARGENTINA AM,ARMENIA AW,ARUBA AU,AUSTRALIA AT,AUSTRIA AZ,AZERBAIJAN BS,BAHAMAS BH,BAHRAIN BD,BANGLADESH BB,BARBADOS BY,BELARUS BE,BELGIUM BZ,BELIZE BJ,BENIN BM,BERMUDA BT,BHUTAN BO,"BOLIVIA, PLURINATIONAL STATE OF" BQ,"BONAIRE, SINT EUSTATIUS AND SABA" BA,BOSNIA AND HERZEGOVINA BW,BOTSWANA BV,BOUVET ISLAND BR,BRAZIL IO,BRITISH INDIAN OCEAN TERRITORY BN,BRUNEI DARUSSALAM BG,BULGARIA BF,BURKINA FASO BI,BURUNDI KH,CAMBODIA CM,CAMEROON CA,CANADA CV,CABO VERDE KY,CAYMAN ISLANDS CF,CENTRAL AFRICAN REPUBLIC TD,CHAD CL,CHILE CN,CHINA CX,CHRISTMAS ISLAND CC,COCOS (KEELING) ISLANDS CO,COLOMBIA KM,COMOROS CG,CONGO CD,"CONGO, THE DEMOCRATIC REPUBLIC OF THE" CK,COOK ISLANDS CR,COSTA RICA CI,COTE D'IVOIRE HR,CROATIA CU,CUBA CW,CURACAO CY,CYPRUS CZ,CZECHIA DK,DENMARK DJ,DJIBOUTI DM,DOMINICA DO,DOMINICAN REPUBLIC EC,ECUADOR EG,EGYPT SV,EL SALVADOR GQ,EQUATORIAL GUINEA ER,ERITREA EE,ESTONIA ET,ETHIOPIA FK,FALKLAND ISLANDS (MALVINAS) FO,FAROE ISLANDS FJ,FIJI FI,FINLAND FR,FRANCE GF,FRENCH GUIANA PF,FRENCH POLYNESIA TF,FRENCH SOUTHERN TERRITORIES GA,GABON GM,GAMBIA GE,GEORGIA DE,GERMANY GH,GHANA GI,GIBRALTAR GR,GREECE GL,GREENLAND GD,GRENADA GP,GUADELOUPE GU,GUAM GT,GUATEMALA GG,GUERNSEY GN,GUINEA GW,GUINEA-BISSAU GY,GUYANA HT,HAITI HM,HEARD ISLAND AND MCDONALD ISLANDS VA,HOLY SEE (VATICAN CITY STATE) HN,HONDURAS HK,HONG KONG HU,HUNGARY IS,ICELAND IN,INDIA ID,INDONESIA IR,"IRAN, ISLAMIC REPUBLIC OF" IQ,IRAQ IE,IRELAND IM,ISLE OF MAN IL,ISRAEL IT,ITALY JM,JAMAICA JP,JAPAN JE,JERSEY JO,JORDAN KZ,KAZAKHSTAN KE,KENYA KI,KIRIBATI KP,"KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF" KR,"KOREA, REPUBLIC OF" KW,KUWAIT KG,KYRGYZSTAN LA,LAO PEOPLE'S DEMOCRATIC REPUBLIC LV,LATVIA LB,LEBANON LS,LESOTHO LR,LIBERIA LY,LIBYA LI,LIECHTENSTEIN LT,LITHUANIA LU,LUXEMBOURG MO,MACAO MK,NORTH MACEDONIA MG,MADAGASCAR MW,MALAWI MY,MALAYSIA MV,MALDIVES ML,MALI MT,MALTA MH,MARSHALL ISLANDS MQ,MARTINIQUE MR,MAURITANIA MU,MAURITIUS YT,MAYOTTE MX,MEXICO FM,"MICRONESIA, FEDERATED STATES OF" MD,"MOLDOVA, REPUBLIC OF" MC,MONACO MN,MONGOLIA ME,MONTENEGRO MS,MONTSERRAT MA,MOROCCO MZ,MOZAMBIQUE MM,MYANMAR NA,NAMIBIA NR,NAURU NP,NEPAL NL,NETHERLANDS NC,NEW CALEDONIA NZ,NEW ZEALAND NI,NICARAGUA NE,NIGER NG,NIGERIA NU,NIUE NF,NORFOLK ISLAND MP,NORTHERN MARIANA ISLANDS NO,NORWAY OM,OMAN PK,PAKISTAN PW,PALAU PS,"PALESTINE, STATE OF" PA,PANAMA PG,PAPUA NEW GUINEA PY,PARAGUAY PE,PERU PH,PHILIPPINES PN,PITCAIRN PL,POLAND PT,PORTUGAL PR,PUERTO RICO QA,QATAR RE,REUNION RO,ROMANIA RU,RUSSIAN FEDERATION RW,RWANDA BL,SAINT BARTHELEMY SH,"SAINT HELENA, ASCENSION AND TRISTAN DA CUNHA" KN,SAINT KITTS AND NEVIS LC,SAINT LUCIA MF,SAINT MARTIN (FRENCH PART) PM,SAINT PIERRE AND MIQUELON VC,SAINT VINCENT AND THE GRENADINES WS,SAMOA SM,SAN MARINO ST,SAO TOME AND PRINCIPE SA,SAUDI ARABIA SN,SENEGAL RS,SERBIA SC,SEYCHELLES SL,SIERRA LEONE SG,SINGAPORE SX,SINT MAARTEN (DUTCH PART) SK,SLOVAKIA SI,SLOVENIA SB,SOLOMON ISLANDS SO,SOMALIA ZA,SOUTH AFRICA GS,SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS SS,SOUTH SUDAN ES,SPAIN LK,SRI LANKA SD,SUDAN SR,SURINAME SJ,SVALBARD AND JAN MAYEN SZ,ESWATINI SE,SWEDEN CH,SWITZERLAND SY,SYRIAN ARAB REPUBLIC TW,"TAIWAN, PROVINCE OF CHINA" TJ,TAJIKISTAN TZ,"TANZANIA, UNITED REPUBLIC OF" TH,THAILAND TL,TIMOR-LESTE TG,TOGO TK,TOKELAU TO,TONGA TT,TRINIDAD AND TOBAGO TN,TUNISIA TR,TURKEY TM,TURKMENISTAN TC,TURKS AND CAICOS ISLANDS TV,TUVALU UG,UGANDA UA,UKRAINE AE,UNITED ARAB EMIRATES GB,UNITED KINGDOM OF GREAT BRITAIN AND NORTHERN IRELAND US,UNITED STATES UM,UNITED STATES MINOR OUTLYING ISLANDS UY,URUGUAY UZ,UZBEKISTAN VU,VANUATU VE,"VENEZUELA, BOLIVARIAN REPUBLIC OF" VN,VIET NAM VG,"VIRGIN ISLANDS, BRITISH" VI,"VIRGIN ISLANDS, U.S." WF,WALLIS AND FUTUNA EH,WESTERN SAHARA YE,YEMEN ZM,ZAMBIA ZW,ZIMBABWE XK,KOSOVO The post ES|QL の Lookup Join でインデックス結合が驚くほど簡単に first appeared on Elastic Portal .
情報源: Elastic公式サイト – ブラジル警察機関の顧客事例 目次 はじめに 導入前の課題 時間のかかるデータベース検索 スケーラビリティの問題 Elasticsearch導入によるソリューション ベクトルデータベースを活用した顔認証システム カスタムモバイル・ウェブアプリケーションとElasticsearchの連携 導入効果 検索時間の大幅な短縮 犯罪者の迅速な特定と逮捕 市民サービスの向上 現場での捜査活動の強化 技術的アーキテクチャの特徴 大規模データ処理能力 高速ベクトル検索 まとめ はじめに 300万人以上の住民を抱えるブラジルの大都市圏において、警察機関が最先端の技術を活用した捜査システムを導入しました。Elasticsearchのベクトルデータベースを中心とした顔認証技術により、犯罪捜査の効率が大幅に改善し、市民の安全確保に大きく貢献しています。本記事では、この取り組みについてご紹介します。 ※ベクトルデータベースとは、画像や文章の特徴を数値(ベクトル)として保存し、似ているものを高速に探せる仕組みです。 導入前の課題 時間のかかるデータベース検索 導入前、警察官は膨大なデータベースを検索するために 数時間から数日 を要していました。このデータベースには、文書、写真、動画など、数十億件もの情報が含まれており、効率的な検索システムの構築が急務でした。 本プロジェクトを担当した技術責任者は次のように語っています、「警察官たちはデータベースの検索に多くの時間を費やし、本来の犯罪防止や現場対応向上という任務から離れてしまっていました。私たちは検索時間を数分、あるいは数秒にまで短縮する必要があったのです」 スケーラビリティの問題 都市の成長と共に、データ量は増加の一途を辿っていました。数百万件の検索クエリと数テラバイトの写真、文書、デジタルメディアを処理できる、スケーラブルなアーキテクチャが求められていました。 Elasticsearch導入によるソリューション ベクトルデータベースを活用した顔認証システム ブラジルの警察機関は、 Elasticsearchのベクトルデータベース を顔認証技術の基盤として採用しました。このシステムにより、警察官は現場で撮影した写真を使って、迅速かつ正確にデータベース検索を実行できるようになりました。 カスタムモバイル・ウェブアプリケーションとElasticsearchの連携 ブラジルの公共安全組織は、警察官が簡単に写真を撮影・アップロードできるよう、専用のモバイルアプリケーションとウェブアプリケーションを開発しました。このアプリと画像データベースの橋渡しをするために、強力なベクトル検索機能を持つElasticsearchが採用されています。 導入効果 検索時間の大幅な短縮 以前は数時間から数日かかっていたデータベース検索が、現在では 数分から数秒 で完了するようになりました。これにより、警察官は迅速な意思決定を行い、事件現場でより効果的に対応できるようになっています。 犯罪者の迅速な特定と逮捕 導入初期段階から、顕著な成果が現れています。従来のシステムでは、データベース検索に時間がかかりすぎるため、その間に容疑者が現場から逃走してしまうケースがありました。しかし、Elasticsearchの導入後は、現場で撮影した写真を使って数秒から数分で容疑者を特定できるようになり、その場で逮捕に至るケースが増えています。 市民サービスの向上 顔認証技術は、犯罪捜査だけでなく、市民支援にも活用されています。 印象的な事例: ある警察官が、約2週間行方不明になっていたアルツハイマー病の高齢男性を発見しました。警察官が写真を撮影し、行方不明者データベースで検索したところ、すぐに男性の名前と連絡先が判明しました。 技術責任者によると、「ご家族は非常に喜び、ほっとされています。数日間希望を持って待っていたご家族に、この良い知らせを伝えることができました。」 また、犯罪被害者の迅速な身元確認により、遺族や愛する人々に確実な情報と心の安らぎを提供することも可能になっています。 現場での捜査活動の強化 Elasticsearchの導入により、警察官はコンピュータの前で過ごす時間が減り、地域社会での重要な捜査活動により多くの時間を割けるようになりました。これは、犯罪予防と公共の安全において、極めて重要な改善です。 技術的アーキテクチャの特徴 大規模データ処理能力 Elasticsearchのベクトルデータベースを採用したアーキテクチャは、以下の能力を備えています。 導入規模: 13ノードで構成される大規模なElasticsearchベクトルデータベース 6テラバイトの膨大なデータを保管 このシステムは、数百万件の検索クエリと数テラバイトの写真、文書、デジタルメディアを処理できる高いスケーラビリティと拡張性を実現しています。 高速ベクトル検索 ベクトル検索技術により、画像の特徴を数値化し、類似画像を高速で検索することが可能になっています。これが、顔認証システムの高速化と精度向上の鍵となっています。 まとめ ブラジルの警察機関によるElasticsearchの導入事例は、最先端のテクノロジーが公共安全の分野でどのように活用されているかを示す優れた例です。これは、決して特別な国・特別な事情だから成立したわけではありません。同じ構造の課題は、日本の自治体や公共機関にも数多く存在します。 たとえば、日本では次のようなデータが日々蓄積されています。 防犯カメラの画像・動画データ 行方不明者や高齢者に関する記録 災害時の被災者情報、安否確認情報 住民対応の履歴、問い合わせ記録 これらは「量が多い」「形式がバラバラ」「必要なときにすぐ探せない」という共通の課題を抱えています。 Elasticsearchを検索基盤として使うと、これらの バラバラなデータを一元的に検索・分析 できるようになります。 テキスト(記録・報告書・メモ) ログ(システム・アクセス履歴) 画像や動画から抽出した特徴データ を1つの検索エンジンでまとめて探せるため、 迅速な横断検索 が可能になります。これは日本の自治体、警察、消防、防災部門にとっても非常に現実的で、かつ導入効果を説明しやすい価値といえます。 本記事は、Elastic社の公式カスタマー事例を基に作成されました。詳細については、 Elastic公式サイト をご覧ください。 The post 警察機関におけるElasticsearch活用事例 first appeared on Elastic Portal .
目次 はじめに 再帰チャンキング (Recursive Chunking) とは 概略 分割のイメージ Recursive Chunkingによる分割結果 参考URL 実践:インデキシング 1. 準備 2. Inference Endpoint の作成 3. インデックスの作成 4. マッピングの追加 5. ドキュメントの取り込み 6. データの反映 実践:検索と結果検証 ケース1. 表データの検索 考察 比較:Sentence Chunking の場合 ケース2. 階層が深いブロックの検索 比較:Word Chunking の場合 採用時の重要な注意点 まとめ はじめに RAG(Retrieval-Augmented Generation)や検索アプリケーションの構築において、Markdown文書の「チャンキング戦略」に頭を悩ませたことはありませんか? 従来、Markdown文書に対して単純な word(単語数)や sentence(文)単位でのチャンキングを行うと、見出しと本文が分離してしまったり、文脈が複数のブロックに分断されたりするケースが多々ありました。その結果、検索結果にノイズが含まれ、回答精度の低下を招く要因となっていました。 Elasticsearch 8.19.0 および 9.1.0 では、この課題を解決する新たな戦略として 再帰チャンキング(Recursive Chunking) が追加されました。 本記事では、この再帰チャンキングの仕組みと、実際に有価証券報告書(Markdown形式)を用いたインデキシングおよび検索実験の結果をご紹介します。 ※補足: 本ブログで使用したスクリプトやテストデータは、下記のリポジトリで公開しています。 https://github.com/sios-elastic-tech/blogs/tree/main/2025-12-recursive-chunking 再帰チャンキング (Recursive Chunking) とは 概略 再帰チャンキングは、定義されたセパレーター(区切り文字)のリストに基づいて、文書を階層的かつ再帰的に分割する手法です。 Markdownの見出し構造(#, ##, ###…)をセパレーターとして定義することで、文書の論理構造を保ったままチャンクを生成できます。 例: "chunking_settings": { "strategy": "recursive", "max_chunk_size": 300, "separators": [ "\n# ", "\n## ", "\n### ", "\n#### ", "\n##### ", "\n###### ", "\n^(?!\\s*$).*\\n-{1,}\\n", "\n^(?!\\s*$).*\\n={1,}\\n" ] } ※ “separators” の指定は、 “separator_group” : “markdown” と書くことも可能ですが、 ここではカスタマイズ性を重視し、 “separators” を明示的に記述する形式で解説します。 分割のイメージ この戦略を用いると、Markdown文書は以下のように構造的に分割されます。 元の Markdown 文書 # 1. 企業の概況 ## 1.1. 主要な経営指標 ### 1.1.1. 売上高の推移 (本文テキスト...) ### 1.1.2. 利益の推移 (本文テキスト...) ## 1.2. 沿革 (本文テキスト...) # 2. 事業の内容 (本文テキスト...) Recursive Chunkingによる分割結果 チャンク1 # 1. 企業の概況 ## 1.1. 主要な経営指標 ### 1.1.1. 売上高の推移 (本文テキスト...) チャンク2 ### 1.1.2. 利益の推移 (本文テキスト...) チャンク3 ## 1.2. 沿革 (本文テキスト...) チャンク4 # 2. 事業の内容 (本文テキスト...) ※重要なポイント: 構造を無視した分割(例:1.1.2. の途中から始まり、1.2. の冒頭が含まれるなど)が発生しません。 見出しの階層が変わるタイミングで適切に分割されるため、各チャンクが「意味のあるまとまり」を持ちます。 参考URL Recursive chunking in Elasticsearch for structured documents - Elasticsearch Labs Learn how to configure recursive chunking in Elasticsearch with chunk size, separator groups, and custom separator lists... www.elastic.co Chunking strategies: Elasticsearch chunking & its strategies - Elasticsearch Labs Learn the fundamentals of document chunking in Elasticsearch, compare different chunking strategies, and discover how yo... www.elastic.co Elasticsearch chunking: Set up chunking for inference endpoints - Elasticsearch Labs Explore Elasticsearch chunking strategies, learn how Elasticsearch chunks text, and how to configure chunking settings f... www.elastic.co Inference integrations | Elastic Docs Elasticsearch provides a machine learning inference API to create and manage inference endpoints that integrate with ser... www.elastic.co 実践:インデキシング 実際に Elasticsearch を用いて、Markdown文書の取り込みとベクトル化を行います。 ※使用するデータについて テストデータとして、サイオス株式会社の2024年12月期の有価証券報告書を使用します。 出典: https://www.sios.com/ja/ir/news/docs/20250328houkokusho.pdf 本検証作業では、上記の PDF の内容を抜粋、改変して markdown 化したものを利用します。 https://github.com/sios-elastic-tech/blogs/blob/main/2025-12-recursive-chunking/input_data/ir_report_20250328.md 1. 準備 Elasticsearch のバージョン 8.19.0 以上、または 9.1.0 以上 (Enterprise License) (本記事での検証環境: Docker 上の Elasticsearch 9.2.2 ) 必要なプラグイン analysis-icu https://www.elastic.co/docs/reference/elasticsearch/plugins/analysis-icu analysis-kuromoji https://www.elastic.co/docs/reference/elasticsearch/plugins/analysis-kuromoji モデルのデプロイ 今回は、.multilingual-e5-small_linux-x86_64 を使用します。 参考手順: https://www.elastic.co/search-labs/jp/blog/multilingual-embedding-model-deployment-elasticsearch のステップ3 2. Inference Endpoint の作成 ドキュメント取り込み時に「チャンク分割」と「密ベクトル生成」を行うための inference endpoint を作成します。 ここで strategy: “recursive” を指定します。 参考URL: https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-inference-put-elasticsearch Kibana の Dev Tools (Console) から次のリクエストを発行します。 PUT _inference/text_embedding/e5_chunk_recursive { "service": "elasticsearch", "service_settings": { "num_allocations": 1, "num_threads": 1, "model_id": ".multilingual-e5-small_linux-x86_64" }, "chunking_settings": { "strategy": "recursive", "max_chunk_size": 300, "separators": [ "\n# ", "\n## ", "\n### ", "\n#### ", "\n##### ", "\n###### " ] } } ※今回のテストデータでは、— や === による区切りは使用していないので、separators から除外してシンプルにしています。 3. インデックスの作成 日本語検索に最適化するため、kuromoji と icu_normalizer を設定したインデックスを作成します。 PUT /ir_report_2024_chunk_recursive { "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 1, "refresh_interval": "3600s" }, "analysis": { "char_filter": { "ja_normalizer": { "type": "icu_normalizer", "name": "nfkc_cf", "mode": "compose" } }, "tokenizer": { "ja_kuromoji_tokenizer": { "mode": "search", "type": "kuromoji_tokenizer", "discard_compound_token": true } }, "analyzer": { "ja_kuromoji_index_analyzer": { "type": "custom", "char_filter": [ "ja_normalizer", "kuromoji_iteration_mark" ], "tokenizer": "ja_kuromoji_tokenizer", "filter": [ "kuromoji_baseform", "kuromoji_part_of_speech", "cjk_width", "ja_stop", "kuromoji_number", "kuromoji_stemmer" ] }, "ja_kuromoji_search_analyzer": { "type": "custom", "char_filter": [ "ja_normalizer", "kuromoji_iteration_mark" ], "tokenizer": "ja_kuromoji_tokenizer", "filter": [ "kuromoji_baseform", "kuromoji_part_of_speech", "cjk_width", "ja_stop", "kuromoji_number", "kuromoji_stemmer" ] } } } } } 4. マッピングの追加 作成したエンドポイント (e5_chunk_recursive) を使用するようにマッピングを定義します。 semantic_text 型を利用することで、テキスト処理とベクトル化を自動化します。 PUT /ir_report_2024_chunk_recursive/_mappings { "dynamic": false, "_source": { "excludes": [ "content.text_embedding" ] }, "properties": { "content": { "type": "text", "analyzer": "ja_kuromoji_index_analyzer", "search_analyzer": "ja_kuromoji_search_analyzer", "fields": { "text_embedding": { "type": "semantic_text", "inference_id": "e5_chunk_recursive" } } } } } 5. ドキュメントの取り込み Markdown化した有価証券報告書データを取り込みます。(以下は抜粋です) POST /ir_report_2024_chunk_recursive/_doc { "content": """ # 第1 【企業の概況】 ## 1 【主要な経営指標等の推移】 ### (1) 連結経営指標等 | 回次 | 第24期 | 第25期 | 第26期 | 第27期 | 第28期 | |:--|:--|:--|:--|:--|:--:| | 決算年月 | 2020年12月 | 2021年12月 | 2022年12月 | 2023年12月 | 2024年12月 | | 売上高(千円) | 14,841,739 | 15,725,371 | 14,420,269 | 15,889,487 | 20,561,583 | ... 当連結会計年度におきましては、個別決算において関係会社株式の減損による特別損失の計上を行うことから、利 益剰余金が大幅に減少することになり、誠に遺憾ではございますが、期末配当を無配とさせていただきたいと存じま す。 """ } 全文は、下記を参照してください。 File not found ?? sios-elastic-tech/blogs A sample code for blogs about elasticsearch. Contribute to sios-elastic-tech/blogs development by creating an account on... github.com 6. データの反映 データを検索可能にするため、リフレッシュを行います。 POST /ir_report_2024_chunk_recursive/_refresh 実践:検索と結果検証 取り込んだデータに対してセマンティック検索を行い、再帰チャンキングの効果を確認します。 ケース1. 表データの検索 クエリ: “2024年度の有給休暇取得率” GET /ir_report_2024_chunk_recursive/_search { "_source": false, "query": { "semantic": { "field": "content.text_embedding", "query": "2024年度の有給休暇取得率" } }, "highlight": { "fields": { "content.text_embedding": { "order": "score", "number_of_fragments": 1 } } } } 検索結果 """ ### (3) 指標及び目標 当社グループは、上記の「(2)①人材の多様性の確保を含む人材の育成に関する方針」及び「(2)②社内環境整備に 関する方針」について、次の指標を用いています。当該指標に関する目標及び実績は、次の通りです。 | 指標 | 2023年度実績 | 2024年度実績 | 目標 | |:--|:--|:--|:--:| | 管理職に占める女性労働者の割合 | 15.5% | 10.5% | 20%(2025年度) | | 男性労働者の育児休業取得率 | 38.5% | 100.0% | 100%(2025年度) | | 労働者の男女の賃金の差異 | 76.3% | 78.4% | 80%(2025年度) | | 有給休暇取得率 | 74.9% | 69.8% | 80%(2025年度) | | 離職率 | 6.4% | 7.7% | 5%以下(毎年) | | 月平均所定外残業時間 | 14.3時間 | 14.1時間 | − | | 障がい者雇用率 | 2.96% | 2.48% | − | (注) 1.国内グループ会社(当社、サンプルテクノロジー株式会社)を対象に計算しています。 2.当社グループでは定年制を廃止しているため、離職率については、すべての退職者を含めて 計算しています。 3.目標の「−」は、設定がないことを示しています。 """ 考察 Markdownの表全体が一つのチャンクとして綺麗に取得できており、必要な文脈(表のヘッダーや注釈)が保持されています。 LLM にこのテキストを渡した場合でも、表構造を正しく解釈できると思われます。 比較:Sentence Chunking の場合 一方で、sentence 戦略を用いた場合、表の途中でチャンクが分割されてしまい、ヘッダー情報が欠落するケースが見られました。 Sentence Chunking での検索結果の抜粋: """(100-999人)では管理職を除く55歳以上のシニア世代がいきいきと働く企業として、3位に選出されました。 ### (3) 指標及び目標 当社グループは、上記の「(2)①人材の多様性の確保を含む人材の育成に関する方針」及び「(2)②社内環境整備に 関する方針」について、次の指標を用いています。当該指標に関する目標及び実績は、次の通りです。 | 指標 | 2023年度実績 | 2024年度実績 | 目標 | |:--|:--|:--|:--:| | 管理職に占める女性労働者の割合 | 15.5% | 10.5% | 20%(2025年度) | | 男性労働者の育児休業取得率 | 38.5% | 100.0% | 100%(2025年度) | """, """| 労働者の男女の賃金の差異 | 76.3% | 78.4% | 80%(2025年度) | | 有給休暇取得率 | 74.9% | 69.8% | 80%(2025年度) | | 離職率 | 6.4% | 7.7% | 5%以下(毎年) | | 月平均所定外残業時間 | 14.3時間 | 14.1時間 | − | | 障がい者雇用率 | 2.96% | 2.48% | − | (注) 1.国内グループ会社(当社、サンプルテクノロジー株式会社)を対象に計算しています。 2.当社グループでは定年制を廃止しているため、離職率については、すべての退職者を含めて 計算しています。 3.目標の「−」は、設定がないことを示しています。 ## 3 【事業等のリスク】 """ このようにヘッダーとデータ行が分断されると、数値だけがヒットしても 「それが何の数値か(2023年度の実績なのか、それとも、2024年度の実績なのか)」を正しく理解できず、 回答精度の低下に直結します。 ケース2. 階層が深いブロックの検索 クエリ: “当連結会計年度のアプリケーション事業の販売実績” GET /ir_report_2024_chunk_recursive/_search { "_source": false, "query": { "semantic": { "field": "content.text_embedding", "query": "当連結会計年度のアプリケーション事業の販売実績" } }, "highlight": { "fields": { "content.text_embedding": { "order": "score", "number_of_fragments": 1 } } } } 検索結果 """ ##### (d) 販売実績 当連結会計年度の販売実績をセグメントごとに示すと、次のとおりであります。 | セグメントの名称 | 当連結会計年度(自2024年1月1日至2024年12月31日) | 前年同期比(%) | |:--|:--|:--:| | オープンシステム基盤事業(千円) | 14,573,839 | 147.1 | | アプリケーション事業(千円) | 5,986,143 | 100.3 | | 合計(千円) | 20,559,983 | 129.5 | (注)1.セグメント間の内部売上高又は振替高を除いた外部顧客に対する売上高を記載しております。 2.最近2連結会計年度の主要な販売先及び当該販売実績の総販売実績に対する割合は次のとおりであります。 | 販売先 | 前連結会計年度(自2023年1月1日至2023年12月31日) | | 当連結会計年度(自2024年1月1日至2024年12月31日) | | |:--|:--|:--|:--|:--:| | | 金額(千円) | 割合(%) | 金額(千円) | 割合(%) | | 株式会社*** | 4,229,893 | 26.6 | 6,067,031 | 29.5 | | 株式会社*** | 2,026,750 | 12.8 | 2,599,494 | 12.6 | """ ピンポイントで検索したいブロック(見出し (d) 販売実績 配下)のみがヒットしています。 比較:Word Chunking の場合 一方で、word 戦略を用いた場合、単純な単語数で区切るため、目的のブロックの前に直前のセクション の残骸が含まれたり、取得したい情報が途中で切れたりする現象が発生しました。 Word Chunking での検索結果の抜粋: """(前年同期は157百万円の使用)となりました。 #### ③ 生産、受注及び販売の状況 ##### (a) 生産実績 当連結会計年度の生産実績をセグメントごとに示すと、次のとおりであります。 | セグメントの名称 | 当連結会計年度(自2024年1月1日至2024年12月31日) | 前年同期比(%) | |:--|:--|:--:| | オープンシステム基盤事業(千円) | 894,022 | 128.9 | | アプリケーション事業(千円) | 1,979,893 | 88.3 | | 合計(千円) | 2,873,915 | 97.9 | ##### (b) 仕入実績 当連結会計年度の仕入実績をセグメントごとに示すと、次のとおりであります。 | セグメントの名称 | 当連結会計年度(自2024年1月1日至2024年12月31日) | 前年同期比(%) | |:--|:--|:--:| | オープンシステム基盤事業(千円) | 11,053,511 | 165.7 | | アプリケーション事業(千円) | 1,303,180 | 123.3 | | 合計(千円) | 12,356,691 | 159.9 | ##### (c) 受注実績 当連結会計年度の受注実績をセグメントごとに示すと、次のとおりであります。 | セグメントの名称 | 受注高(千円) | 前年同期比(%) | 受注残高(千円) | 前年同期比(%) | |:--|:--|:--|:--|:--:| | オープンシステム基盤事業 | 14,871,485 | 141.6 | 2,742,583 | 112.2 | | アプリケーション事業 | 6,400,717 | 115.5 | 2,477,333 | 120.1 | | 合計 | 21,272,202 | 132.6 | 5,219,917 | 115.8 | ##### (d) 販売実績 当連結会計年度の販売実績をセグメントごとに示すと、次のとおりであります。 | セグメントの名称 | 当連結会計年度(自2024年1月1日至2024年12月31日) | 前年同期比(%) | |:--|:--|:--:| | オープンシステム基盤事業(千円) | 14,573,839 | 147.1 | | アプリケーション事業(千円) | 5,986,143 | 100.3 | | 合計(千円) | 20,559,983 | 129.5 | (注)1.セグメント間の内部売上高又は振替高を除いた外部顧客に対する売上高を記載しております。 2.最近2連結会計年度の主要な販売先及び当該 """ 採用時の重要な注意点 Elasticsearch の chunking_settings (Inference API) を使用してチャンキングを行った場合、 データ構造は以下のようになります。 content (text 型) content.text_embedding (semantic_text 型) 複数の密ベクトル (分割されたチャンクの数だけ生成される) この構造下では、「チャンク単位でのキーワード検索 + ベクトル検索(ハイブリッド検索)」を行うことが困難です。 標準のキーワード検索(Match Queryなど)を行うと、ドキュメント全体(content フィールド)に対してマッチングが行われるため、ベクトル検索でヒットしたチャンクとは無関係の箇所にあるキーワードにも反応してしまいます。 もし、「チャンクごとに、厳密なキーワード検索とベクトル検索を組み合わせたい」 という要件がある場合は、Elasticsearch 側での自動チャンキング機能(Inference API の chunking)は使用せず、以下のアプローチを検討してください。 LangChain などの外部ライブラリを使用して、アプリケーション側で事前に Markdown を分割する。 分割した各チャンクを、それぞれ独立した Elasticsearch ドキュメントとしてインデックスする。 こうすることで、1つのドキュメントに対して「1つのテキスト」と「1つのベクトル」が対応するシンプルな構造となり、チャンク単位でのハイブリッド検索が容易になります。 まとめ 検証の結果、Markdown 文書に対して Recursive Chunking(再帰チャンキング) を適用することで、以下のメリットが確認できました。 文脈の保持: 見出しや表などの論理的なまとまりが維持される。 ノイズの削減: 無関係なセクションの混入を防ぎ、検索精度の向上に寄与する。 RAGへの最適化: LLMに渡すコンテキストとして、より意味の通った情報を提供できる。 Markdown形式のドキュメント(技術仕様書、社内Wiki、レポートなど)を検索対象とする場合、 Elasticsearchの再帰チャンキング(Recursive Chunking)は非常に強力な選択肢となります。ぜひ一度お試しください。 The post Markdown 文書のための再帰チャンキング入門 — Elasticsearch での実践と比較 first appeared on Elastic Portal .
Elasticsearch を使っていると、クエリ記述には KQL や ES|QL、Query DSLなどいくつかの書き方が登場します。しかし、そのすべての 下で動いているのは Apache Lucene の検索エンジン です。 Luceneを「高性能なエンジン」だとすれば、Elasticsearchはそのエンジンを搭載した「高級車」のようなものです。Lucene を一言でいうと、 テキストを検索しやすい形に変えて、素早く答えてくれるエンジン です。 この記事では、Kibanaにデフォルトで入っている Kibana Sample Data Logs を使い、Lucene クエリの基本とよく使う構文を整理します。 目次 Luceneモードへの切り替え 基本クエリ 1. フリーテキスト検索 2. キーワード検索 3. Wildcard Matching 4. Proximity Matching(近接検索) 5. Range Searches(範囲検索) 6. Fuzzy Searches(あいまい検索) 7. Boosts(スコアの重み付け) 8. Boolean Operators & Grouping(論理演算とグループ化) よくある落とし穴 まとめ Luceneモードへの切り替え Kibanaの検索バーは現在、デフォルトで KQL (Kibana Query Language) になっています。この記事で紹介するクエリ(特に ~ を使う近接検索や TO を使う範囲指定)を正しく動作させるには、以下の手順でモードを切り替えてください。 基本クエリ 検索のやり方として2つあります。 1. フリーテキスト検索 フリーテキスト検索を実行するには、テキスト文字列を入力するだけです。たとえば、Web サーバーのログを検索する場合、safari と入力してすべてのフィールドを検索できます。 2. キーワード検索 特定のフィールドが特定の値と一致するものを探します。 クエリ 説明 response: 404 ステータスコードが 404 のログのみを検索します。 machine.os: “win 8” OSが “win 8” というフレーズと完全に一致するものを検索します。 geo.src: US -geo.dest: US アクセス元がアメリカで、かつ目的地がアメリカ ではない ものを検索します(マイナス記号  – は除外を意味します)。 3. Wildcard Matching 文字の一部が不明な場合や、パターン検索に使用します。 クエリ 説明 agent: Mozilla* User Agentが “Mozilla” で始まるすべてのログを検索します。 extension: d* 拡張子が “d” で始まるファイル(debなど)へのアクセスを検索します。 referer: *twitter* リファラー(参照元URL)の中間に “twitter” が含まれるログを検索します。 ⚠️ 注意: 先頭に * を置く検索(例: *name )は、全インデックスを走査するため非常に遅くなる可能性があり、推奨されません。 4. Proximity Matching(近接検索) 2つの単語が互いに指定した距離(単語数)以内で出現するドキュメントを探します。 クエリ 説明 “beats HTTP”~4 メッセージ内で “beats” と “HTTP” が 4単語以内 の距離にあるものを検索します。単なるAND検索よりも文脈の強いつながりを見つけられます。 5. Range Searches(範囲検索) 数値や日付の範囲を指定します。 クエリ 説明 bytes: [10000 TO *] 転送量が 10,000バイト以上 のログを検索します(* は上限なし)。 response: [500 TO 599] ステータスコードが 500番台 (サーバーエラー) の範囲にあるログを検索します。 bytes: {0 TO 100} 転送量が0より大きく100未満を検索します。[] は境界値を含み(以上・以下)、{} は境界値を含みません(より大きい・より小さい)。 6. Fuzzy Searches(あいまい検索) スペルミスや表記ゆれを許容して検索します。 クエリ 説明 index:kibana_smple_dat_logs スペルミスを許容して検索します(例: “kibana_sample_data_logs” にヒットします)。 index:kibana_smple_dat_logs~1 1文字違いまで許容します(例: 1文字までなのでkibana_sample_data_logsにヒットしません)。 💡 ポイント: ~ は単語の後ろにつけるとFuzzy(roan~)、フレーズの後ろにつけるとProximity(”foo bar”~4)として機能します。 7. Boosts(スコアの重み付け) 特定の条件に合致するドキュメントの検索スコア(関連度)を高くします。 クエリ 説明 response:404^2 OR response:503 404エラーの重要度(スコア)を2倍にして検索します。関連度順に並べた際、404エラーの方が上位に来やすくなります。 8. Boolean Operators & Grouping(論理演算とグループ化) 複雑な条件を組み合わせます。Lucene の演算子(AND, OR, NOT)は 大文字 が必須です。小文字にすることで、特定の文字が演算子としてではなく、単語として認識されます。 クエリ 説明 NOT response: 200 ステータスコードが 200 (成功) ではない (=エラーやリダイレクト) ログをすべて表示します。 geo.src: US AND response: 404 アメリカからのアクセス かつ 404エラーだったログを検索します。 (extension: rmp OR extension:deb) AND geo.dest:GB グループ化: 「拡張子がrmpかdeb」という条件を優先し、かつイギリスからのアクセスであるものを検索します。 よくある落とし穴 Luceneクエリが思ったように動かない場合、以下の原因が考えられます。 KeywordフィールドでのFuzzy検索: keyword 型のフィールドは解析(Analyzer処理)されないため、Fuzzy検索(~)が効きません。 句読点や記号の消失: データ取り込み時に Standard Analyzer を通っている場合、記号が削除されていることがあります。「検索できない」と思ったら、元のテキストがどうトークン化されているか確認が必要です。 特殊文字のエスケープ: + – && || ! ( ) { } [ ] ^ ” ~ * ? : \ などの文字を検索値として含める場合は、直前にバックスラッシュ \ を置いてエスケープする必要があります(例:file_name:report\-2025\.pdf)。 まとめ 全文検索、ログ検索、アラート条件、検索パフォーマンス — すべての土台は Lucene にあります。 KQL: Kibanaでの日常的な利用に最適(簡単・安全)。 Lucene: 複雑な検索(正規表現、Fuzzy、Proximity)を行いたい時に利用。 まずはSample Dataを使って、Luceneならではの柔軟な検索を体験してみてください。 The post ElasticsearchのためのLuceneクエリ入門ガイド first appeared on Elastic Portal .
目次 はじめに 準備作業 環境 サンプルデータの取り込み ダッシュボードの作成 1. ダッシュボードの新規作成 2. Variable control の作成 3. グラフと Variable control の紐づけ 動作確認 まとめ はじめに Elastic の Kibana では、これまでグラフごとに集計項目を固定して作成する必要がありました。 しかし、Elastic Stack 8.18 以降(または 9.0 以降)で強化された「Variable control」機能と ES|QL を組み合わせることで、一つのパネルで集計項目を動的に切り替えることが可能になりました。 ダッシュボード上でプルダウンメニューを操作するだけで集計項目を変えられるため、似たようなグラフを何個も作る必要がなくなり、分析の柔軟性が大幅に向上します。本記事では、その具体的な実装手順をご紹介します。 準備作業 環境 以下の環境を使用します。 Elasticsearch / Kibana : 8.18以降 または 9.0以降   – 本記事では、バージョン 9.2.0 で検証しています。 サンプルデータの取り込み 下記の記事などを参考に、「Sample web logs」データを Kibana に取り込んでください。 参考: https://elastic.sios.jp/blog/elasticsearch-esql-introduction-log-analysis/ ダッシュボードの作成 1. ダッシュボードの新規作成 1.1. メインメニューの Analytics / Dashboards をクリックし、Dashboard 一覧画面へ遷移します。 1.2. 右上の [+ Create dashboard] をクリックします。 ダッシュボードの新規作成画面へ遷移します。 1.3. 対象期間を調整します。(例: Last 15 minutes を、Last 7 days に変更) 1.4. [(+) Add] > New Panel を選択します。 1.5. パネルの種類として、ES|QL を選択します。 ES|QLの入力画面に切り替わります。 1.6. ES|QL の入力欄に以下のクエリーを貼り付けます。 まずは、ベースとなるグラフを作成するため、geo.dest (宛先地域)ごとのアクセス数を集計するクエリーを入力します。 FROM kibana_sample_data_logs | STATS count = count() BY geo.dest | SORT count DESC | LIMIT 10 1.7. 右上の [▷ Run Query] をクリックし、グラフが描画されることを確認します。 1.8. 右下の [✓ Apply and close] をクリックします。 2. Variable control の作成 次に、先ほどのグラフの集計項目を簡単に変更できるようにするための Variable control を追加します。 2.1. 画面上部の [(+) Add] をクリックし、Controls > Variable control を選択します。 Variable control の新規作成画面が表示されます。 2.2. Variable control の設定画面で以下のように入力します。 Type を Values from a query から Static values に変更します。 Name を ??stats_field に変更します。 Values に集計対象としたいフィールド名を入力していきます。 agent clientip geo.dest host machine.os response tags url 2.3. 右下の [Save] をクリックします。ダッシュボードに stats_field の control が追加されます。 3. グラフと Variable control の紐づけ 作成した Variable control の値に応じてグラフが変化するように、クエリーを修正します。 3.1. 作成したグラフパネルの右上のオプションから鉛筆アイコンをクリックします。 グラフ部分の編集画面へ遷移します。 3.2. ES|QL クエリー内の geo.dest 部分を削除します。 | STATS count = count() BY geo.dest   <-- この geo.dest を削除 3.3. 削除した箇所でキーボードのスペースバーを押すと、候補が表示されます。 選択肢の中から、先ほど作成した、 ??stats_field を選択します。 3.4. [▷ Run query] をクリックします。グラフの Horizontal axis (横軸)が ??stats_field に変わり、グラフが再描画されます。 3.5. 右下の [✓ Apply and close] をクリックします。 3.6. ダッシュボード右上の [Save] をクリックし、タイトル(例:”variable control test”)を入力して保存します。 動作確認 実際に Variable control を操作してみましょう。 ダッシュボード上の stats_field プルダウンを clientip に変更すると、クライアント IP ごとの集計結果に切り替わります。 同様に、stats_field を、geo.dest, host, machine.os, response, tags, url に変えると、それぞれのフィールドに基づいた集計結果が即座に表示されます。 まとめ Variable control を活用することで、1つのグラフパネルであっても多角的な視点での分析が可能になることがお分かりいただけたかと思います。これにより、ダッシュボードの表示領域を節約しつつ、インタラクティブなデータ探索が可能になります。 今回は「集計フィールド(BY句)」を変数化する例を紹介しましたが、この機能は「集計関数(STATS句)」や「フィルタ条件(WHERE句)」などにも応用可能です。ぜひ皆さんの環境でも試してみてください。 参考URL: https://www.elastic.co/search-labs/blog/kibana-dashboard-interactivity-variable-controls-overview The post 【Kibana】ES|QLとVariable control で実現! 集計項目を動的に切り替えるダッシュボード作成術 first appeared on Elastic Portal .
Elasticは、データを素早く検索・分析するための強力な基盤として長年活用されてきました。しかし、クラウドネイティブな環境が標準となるにつれ、従来のデータ管理手法である「ステートフル」モデルでは対応しきれない課題も顕在化しています。 これまでのElasticは、データ処理を行う「コンピューティング」と、データを保存する「ストレージ」が一体となった構成でした。この方式は確かな実績を持つ一方で、システムの拡張や管理運用において、手間やコストが増大しやすいという側面がありました。 そこで新たに登場したのが、「サーバーレス」アーキテクチャです。本稿では、これら二つの方式を比較しながら、サーバーレスアーキテクチャが実現する「コンピューティングとストレージの分離」が、いかにして高い運用効率、柔軟な拡張性、そして優れたコスト効率をもたらすのかを解説します。 目次 従来のステートフルアーキテクチャのレビュー 基本構成とデータ階層化 運用上の課題 サーバーレスアーキテクチャの登場 中核概念:コンピューティングとストレージの分離 「スィンシャード(Thin Shards)」による効率化 シャード再配置問題の解決 詳細なプロセス比較:インデックス作成と検索 ステートフルモデルのデータフロー サーバーレスモデルのデータフロー 最適化:バッチコミット 運用の変革:自動スケーリングとコスト効率 負荷に応じた自動スケーリング コストモデルの最適化 現状の考慮事項と制限 サービス提供開始時期と日本での利用について Elastic Cloud Serverless についてのよくある質問 料金と提供地域 データ管理 セキュリティ、準拠、アクセス プロジェクトのライフサイクルとサポート 結論 参考:用語の意味 参考:リンク集 従来のステートフルアーキテクチャのレビュー サーバーレスモデルがもたらす革新性を正確に評価するためには、まずその前身である従来のステートフルアーキテクチャの構造と、それが直面していた運用上の課題を理解することが重要です。 基本構成とデータ階層化 ステートフルアーキテクチャにおけるデータ管理は、一般的にインデックスライフサイクル管理(ILM)に基づいた階層化が特徴です。 Hot層: 最もアクティブなデータが配置される階層です。インデックス作成(書き込み)と検索クエリが集中するため、高性能なローカルSSDが使用されます。ここでは可用性と耐障害性を確保するため、プライマリとレプリカの両方のシャードが保持されます。 Warm/Cold層: アクセス頻度が低下したデータが移動する階層であり、コスト効率の良いストレージが利用される傾向にあります。 Frozen層: ほとんどアクセスされないアーカイブデータを格納する階層です。S3などのオブジェクトストレージ上のスナップショットをソースとし、必要なデータのみをキャッシュにマウントすることで、ストレージコストの大幅な削減を図ります。 運用上の課題 この階層化モデルは有効に機能してきましたが、運用上、いくつかの課題も指摘されていました。 コンピューティングとストレージの密結合: 大きな課題の一つは、CPUやRAMとローカルディスクが不可分である点です。ストレージ容量のみを増強したい場合でもコンピューティングリソースを同時にスケールアップする必要があり、結果として「オーバープロビジョニング」による不要なコストが発生するケースが見られました。 シャード再配置のコスト: ノードの追加・削除や障害時には、クラスター全体でシャードの物理的なデータコピー(再配置)が発生します。これには帯域消費と時間を要するため、頻繁なアップグレードやスケーリングが躊躇され、結果としてCVEへの対応遅延など俊敏性に影響を与える要因となっていました。 管理の複雑さ: 利用者は、自身のワークロードに合わせてクラスターのサイジングを決定し、適切なILMポリシーを設計・設定する必要があります。どのデータをどのタイミングでHot層からWarm層へ移動させるかといった判断は、利用者の専門知識と経験に依存し、運用管理の負担となる場合がありました。 サーバーレスアーキテクチャの登場 これらの課題への回答の一つとして登場したのが、サーバーレスアーキテクチャです。 中核概念:コンピューティングとストレージの分離 最大の変化は、データ(セグメントファイル)がノードのローカルディスクではなく、S3のようなオブジェクトストレージにプライマリストアとして一元保存される点にあります。これにより、ノードはデータの永続保持責任から解放され、実質的に「ステートレス」となります。インデックス作成(書き込み)専用ノードと、検索(読み取り)専用ノードに分離され、それぞれ独立して管理・スケーリングすることが可能になりました。 「スィンシャード(Thin Shards)」による効率化 このアーキテクチャを支える技術が「ツィンシャード」です。従来のシャードとは異なり、初期状態ではメタデータのみを保持します。データの実体はオブジェクトストレージから必要に応じて読み込まれるため、ノードは軽量な状態を維持できます。これは大規模クラスターにおけるリソース効率の向上に寄与すると考えられます。 シャード再配置問題の解決 この分離により、ノード追加時にはオブジェクトストレージからメタデータを読み込むだけで済むため、ノードの起動が非常に高速化されました。大規模なデータ転送が発生しにくいため、ローリングアップグレードやスケーリングがネットワーク帯域を圧迫することなく実行可能となります。 詳細なプロセス比較:インデックス作成と検索 データライフサイクルにおける具体的なプロセスも変革されています。 ステートフルモデルのデータフロー 従来は、インメモリバッファへの格納と同時にローカルディスクのトランザクションログへ書き込み、その後refresh操作で検索可能にし、flush操作でディスクへ永続化するというフローが一般的でした。 サーバーレスモデルのデータフロー インデックス作成ノード: ドキュメント受信後、トランザクションログがオブジェクトストレージにアップロードされ、その完了確認をもってクライアントにACKが返されます。これにより、単一ノードのディスクに依存するよりも高い耐久性が期待できます。 検索ノード: クエリに必要なセグメントファイルのみをオブジェクトストレージからオンデマンドで取得します。また、インデックス直後の最新データに対しては、検索ノードがインデックス作成ノードに直接問い合わせを行うことで、リアルタイムに近い検索体験を提供するよう設計されています。 出典)https://www.elastic.co/jp/cloud/serverless 最適化:バッチコミット オブジェクトストレージへのAPIコール回数を最適化するため、「バッチコミット」という技術が採用されています。複数のコミットを論理的にグループ化し、差分データのみを追加することで、コストとパフォーマンスの両立を図っています。 運用の変革:自動スケーリングとコスト効率 このアーキテクチャは、運用の自動化とコスト最適化にも直結します。 負荷に応じた自動スケーリング インジェスト量や検索クエリ量に基づき、インデックス作成ノードと検索ノードがそれぞれ独立して自動的にスケールします。なお、コールドスタート(スケールアップ時の初期レイテンシ)を回避したい場合は、「サーチパワー(search power)」設定により、アイドル時でも最低限のノードを維持する運用が可能です。 コストモデルの最適化 ストレージとコンピューティングの分離、自動スケーリングによるオーバープロビジョニングの解消、そして従量課金モデルの組み合わせにより、TCO(総所有コスト)の削減が期待できる構造となっています。 現状の考慮事項と制限 サーバーレスアーキテクチャは強力ですが、採用にあたっては現時点での実装における制約を理解しておく必要があります。 リフレッシュレートの調整: オブジェクトストレージへの負荷軽減のため、リフレッシュレートにはスロットリング(制限)が設けられています(例:15秒に1回など)。 シャード数設定: ユーザーによる手動設定は提供されず、プラットフォームによる自動管理となります。 サービス提供開始時期と日本での利用について 本サービスは2024年12月に一般提供(GA)が開始されました。そして、日本のユーザーにとって待望のAWS 東京リージョン(ap-northeast-1)での提供は、2025年10月より開始されています。 Elastic Cloud Serverlessは、開発者がインフラ管理よりもデータの価値創出に集中できる環境を提供します。現在は14日間の無料トライアルも提供されているため、興味のある方はぜひ実際にその挙動を試し、次世代のパフォーマンスを体感してみてください。 日本国内での導入支援体制についてご案内します: サイオステクノロジー は、Elasticの国内初のディストリビューターです。現在、Elastics社と共同で、Elasticがグローバルに提供している「サーチ」「セキュリティ」「オブザーバビリティ」の3つのソリューションについて、日本国内における展開を強化しております。 サーバーレスアーキテクチャへの移行や、具体的な導入・活用方法についてご不明な点がございましたら、どうぞご遠慮なく弊社までお問い合わせください。 Elastic Cloud Serverless についてのよくある質問 以下は、2025年11月時点の公式ドキュメント(Elastic Docs)に基づくFAQの抜粋です。 料金と提供地域 Q:Serverless の料金についてはどこで確認できますか? A:Elasticsearch Serverless、Observability Serverless、および Elastic Security Serverless の各料金情報ページをご覧ください。 Q:Elastic Cloud Serverless はどのクラウドリージョンでサポートされていますか? A:選定されたAWS/GCP/Azureのリージョンで利用可能です。今後、対応リージョンの拡大も計画されています。詳細は公式ドキュメントの「Regions」をご参照ください。 データ管理 Q:Serverless プロジェクトへ、またプロジェクトからデータを移動するにはどうすればいいですか? A:現在、データ移行ツールを開発中です。暫定的には、Logstashを使用し、Elasticsearch入出力プラグインを通じてServerlessプロジェクトとのデータ移動を実施してください。 Q:Serverless プロジェクトに対してバックアップやリストアのリクエストはできますか? A:プロジェクトのバックアップやリストア要求は、現時点ではサポートされていません。データ移行ツールの強化が進められています。 セキュリティ、準拠、アクセス Q:Elastic Cloud Serverless のサービスアカウントはどう作成できますか? A:Serverlessプロジェクト内でサービスアカウントのAPIキーを作成してください。将来的にはTerraform等のツールによるAPIキー作成の自動化オプションも提供される予定です。 Q:Elastic Cloud Serverless はどのようなコンプライアンスおよびプライバシー基準に準拠していますか? A:Elasticプラットフォーム全体と同様に、独立監査を受け、主要なコンプライアンスおよびプライバシー基準を満たすよう認証されています。詳しくはElastic Trust Centerをご覧ください。特定の基準に関してはロードマップに記載があります。 プロジェクトのライフサイクルとサポート Q:Elastic Cloud Serverless はソフトウェアのバージョン互換性をどのように確保していますか? A:アップグレード時にも接続や設定には影響が出ないよう設計されています。互換性維持のため、品質テストおよびAPIバージョニングが用いられています。 Q:Serverless プロジェクトを Hosted 型(Elastic Cloud Hosted)への変換、あるいは Hosted 型を Serverless プロジェクトに変換できますか? A:プロジェクトおよびデプロイメントは異なるアーキテクチャに基づいているため、相互の変換はできません。 Q:Serverless プロジェクトを別のタイプのプロジェクトに変換できますか? A:プロジェクトを別タイプに変換することはできませんが、必要に応じて任意の数のプロジェクトを作成可能です。課金は実際の使用量に基づきます。 Q:Elastic Cloud Serverless のサポートケースを提出するにはどうすればいいですか? A:普段お使いのサブスクリプションに対してケースを作成してください。ケース本文に「Serverless プロジェクトを使用中」である旨を記載すると、適切なサポートが受けられます。 結論 Elasticのサーバーレスアーキテクチャへの移行は、コンピューティングとストレージの分離、オブジェクトストレージの活用、そしてスィンシャードという技術革新によって実現されました。これにより、スケーラビリティの向上や運用管理の簡素化、コスト効率の改善が見込まれます。 参考:用語の意味 インデックスライフサイクル管理 (ILM): データを作成から削除までポリシーに基づいて自動管理する機能。 オーバープロビジョニング: ピーク時の負荷や将来の増加を見越して、必要以上のリソース(CPU、メモリ、ストレージ)をあらかじめ確保しておくこと。 トランザクションログ (Translog): データの変更操作を記録するログ。メモリ上のデータがディスクに永続化される前にクラッシュした場合のデータ復旧に使用されます。 セグメントファイル: Elasticsearch(内部のLucene)におけるインデックスの構成単位。不変(Immutable)なファイルとして保存されます。 ローリングアップグレード: サービスを停止させることなく、クラスター内のノードを1台ずつ(または一部ずつ)順番に更新していく手法。 コールドスタート: サーバーレス環境において、リクエストが発生してからリソースが立ち上がり、処理が可能になるまでに生じる初期遅延のこと。 CVE (Common Vulnerabilities and Exposures): 共通脆弱性識別子。公開されているセキュリティ脆弱性に対して割り当てられる固有のID。 総所有コスト (TCO): システムの導入から運用、維持管理にかかる費用の総額。 ACK (確認応答): 一般的なネットワーク用語です。 参考:リンク集 https://www.elastic.co/docs/deploy-manage/deploy/elastic-cloud/serverless https://www.elastic.co/docs/deploy-manage/deploy/elastic-cloud#general-what-is-serverless-elastic-differences-between-serverless-projects-and-hosted-deployments-on-ecloud https://www.elastic.co/search-labs/blog/thin-indexing-shards-elasticsearch-serverless https://www.elastic.co/search-labs/blog/elasticsearch-serverless-tier-autoscaling https://www.elastic.co/search-labs/blog/elasticsearch-refresh-costs-serverless https://www.elastic.co/search-labs/blog/elastic-serverless-performance-stress-testing https://www.elastic.co/docs/deploy-manage/deploy/elastic-cloud/manage-serverless-projects-using-api The post Elastics Cloud Serverless:ステートフルからサーバーレスへの技術的移行 first appeared on Elastic Portal .
目次 【10秒で診断】あなたの会社は大丈夫ですか? 1. なぜ今、多くの企業が「セキュリティの穴」に気づいていないのか よくある4つの問題 実態:攻撃発見までの平均時間は一週間以上 2. Elasticが実現する「防御・検知・対応・調査」の統合基盤 理由① エンドポイントで攻撃を「入口」で止める、Elastic Defend (EDR) 理由② 端末からクラウドまで「すべて」を可視化🔍 理由③ フィールドレベルの厳格なアクセス制御 理由④ 通信・保存データの完全暗号化 理由⑤ 誰が・いつ・何をしたかを完全記録 理由⑥ コストと速度を両立するデータティアリング 3. 攻撃の「前」「中」「後」すべてに対応、Elastic Securityの実力 攻撃前:異常を早期に検知 攻撃中:リアルタイムで防御・封じ込め 攻撃後:迅速な初動調査と復旧 4. 【実績】なぜ業界リーダーが Elastic を選ぶのか 世界中の企業が選ぶプラットフォーム 企業が得られる5つの価値 5. まとめ:「攻撃されることを前提」に設計された統合防御基盤 Elastic Securityが統合する機能 6. 【次のステップ】SIOSテクノロジーにご相談ください こんなお悩みをお持ちの方へ まずは無料相談から 【10秒で診断】あなたの会社は大丈夫ですか? ✅ 監査で「3年前のログを見せて」と言われたら、すぐ出せますか? ✅ インシデント発生時、複数システムのログを横断検索できますか? ✅ 端末(PC・サーバ)で何が起きているか、リアルタイムに把握できますか? ✅ ランサムウェアが実行される前に、異常な動きを検知・遮断できますか? 1つでも「NO」なら、このまま読み進めてください。 1. なぜ今、多くの企業が「セキュリティの穴」に気づいていないのか サイバー攻撃は日々高度化しています。しかし、多くの企業は以下の 致命的なギャップ を抱えたままです。 よくある4つの問題 問題①「エンドポイントが攻撃の入口なのに、見えていない」 PC・サーバは攻撃者が最初に侵入する接点 ファイアウォール・アンチウイルスでは、既に侵入された後の「ポスト侵入フェーズ」をカバーできない → 気づいた時には横展開され、被害が全社に拡大 問題②「必要な時にログが見られない」 古いログはアーカイブされ、復元に数時間〜数日 システムごとにログが分散し、横断検索が困難 → インシデント対応の初動が遅れ、被害が拡大 問題③「機密情報の管理が不十分」 誰が何を見られるか制御できていない 監査時に「誰がいつアクセスしたか」を証明できない → 内部不正リスク、コンプライアンス違反の危険 問題④「コストか速度か、選べない」 全データ保管 → インフラ費用が膨大 コスト削減でログ削除 → 調査不能 → 結局、中途半端な対策しかできない 実態:攻撃発見までの平均時間は一週間以上 従来型の「ログだけ」「エンドポイント防御だけ」の分断された基盤では、もはやセキュリティ運用を支えきれません。 2. Elasticが実現する「防御・検知・対応・調査」の統合基盤 Elasticは、 エンドポイント防御 + ログ基盤 + SIEM を単一プラットフォームで統合。攻撃のライフサイクル全体をカバーします。 理由① エンドポイントで攻撃を「入口」で止める、Elastic Defend (EDR) 攻撃者が侵入を試みる瞬間に対応 Elastic Defendは、Windows・macOS・Linuxの全端末に対して、次世代の防御機能を提供します: 多層防御の仕組み マルウェア防御 : 機械学習ベースのシグネチャレス検知 ランサムウェア防御 : 振る舞い分析+カナリーファイルで暗号化を事前検知 メモリ脅威防御 : シェルコードインジェクション等のメモリ攻撃を遮断 悪意ある振る舞い検知 : 権限昇格、不審なプロセス起動、ツール悪用を検知 即座に対応する自動アクション ✅ 脅威プロセスの自動停止 ✅ 端末のネットワーク隔離 ✅ 感染ファイルの自動隔離 ✅ セッション記録による詳細なフォレンジック   価値 : 攻撃が本格化する 前 に封じ込め、被害を最小化 理由② 端末からクラウドまで「すべて」を可視化🔍 環境全体を一望できる統合ビューで、セキュリティの抜け穴を作らない 従来の課題: ❌ EDRとログ基盤が別々 → 端末とネットワークの相関が見えない ❌ 調査時に複数ツールを往復 → 初動が遅れる Elasticの解決策: ✅ 単一プラットフォーム で端末・ネットワーク・クラウドを統合 ✅ 「端末で何が起きたか」→「どこに広がったか」→「いつ発覚したか」を一貫追跡 ✅ Attack Discoveryで複数のアラートを関連付け、攻撃チェーンを自動的に整理・可視化 理由③ フィールドレベルの厳格なアクセス制御 「必要な人が、必要な範囲だけアクセスできる」を実現 ※ 正しい設定・運用が前提です インデックスごと の権限分離 ドキュメントレベル のセキュリティ(条件付きアクセス) フィールドレベル のセキュリティ(機密情報のマスキング) 導入効果 ✅ 内部不正リスクを大幅低減 ✅ 監査対応の証跡管理が容易に ✅ GDPR、個人情報保護法への対応を強化 理由④ 通信・保存データの完全暗号化 データのライフサイクル全体を保護 TLSによるノード間/クライアント通信の暗号化 IPフィルタリングによるアクセス制限 at-rest(保存データ)暗号化のサポート オンプレ/クラウドを問わず統一ポリシーで運用可能 理由⑤ 誰が・いつ・何をしたかを完全記録 監査とコンプライアンス対応を支える証跡管理 設定変更・検索操作・認証試行の全記録 LDAP / Active Directory / SAML / OIDC との統合 監査ログそのものの保護機能 エンドポイントの動き、異常な振る舞い、対応履歴も含めて記録 こんな場面で威力を発揮 インシデント時の「何が起きたか」「何をしたか」の説明 内部統制の証跡提出 法令対応の監査対応 理由⑥ コストと速度を両立するデータティアリング 「高速アクセス」と「長期保管」を同時実現 ティア 特徴 主な用途 コストメリット Hot 最速アクセス リアルタイム監視、直近の調査 高性能が必要な範囲に集中投資 Warm 速度とコストのバランス 日常調査、数週〜数ヶ月前のログ 多くの調査で活用される期間を最適化 Cold 低コスト+実用速度 過去の大規模分析 大幅なコスト削減 Frozen Searchable Snapshot 法令対応の長期保管 環境により異なるが、導入事例では最大50%のコスト削減が報告されている ポイント : 古いログを「削除」するのではなく「適切なティアに移動」することで、 必要な時にすぐアクセスできる状態を保ちながらコスト最適化 を実現。 3. 攻撃の「前」「中」「後」すべてに対応、Elastic Securityの実力 攻撃前:異常を早期に検知 Elasticは1,300以上の事前構築ルールと70以上の機械学習ジョブを提供しており、以下を実現します: 多層的な検知の仕組み MITRE ATT&CK準拠の検知ルール(随時更新) 機械学習による時系列異常検知 新規用語検知、閾値検知、インジケーターマッチ UEBA(User and Entity Behavior Analytics) アカウント侵害の兆候 内部脅威の早期発見 異常な横展開の検知 結果 : 攻撃者の内部偵察や権限昇格を本格化する 前 に気づける     ※ 検知精度や可視化の範囲は、収集できるデータの種類や運用環境に依存します 攻撃中:リアルタイムで防御・封じ込め Elastic Defendによる即座の対応 マルウェア実行を検知した瞬間に 自動停止 ランサムウェアの暗号化動作を 事前遮断 侵害された端末を ネットワークから自動隔離 (Host Isolation) 攻撃の横展開を阻止 脅威ライフサイクルの短縮 従来:侵入 → 数週間の潜伏 → 発見時には全社感染 Elastic:侵入検知 → 封じ込め → 被害を最小化 攻撃後:迅速な初動調査と復旧 データティアリング × 高速検索 × エンドポイント記録で実現 数年分のログへの直ちにアクセス 端末での実行プロセス、ネットワーク接続を完全記録 複数システムの横断検索がスムーズ セッションリプレイで攻撃の全容を再現 監査証跡の抽出も高速化 Elasticの強み : 巨大データを前提に設計された 分散検索エンジン 。データが増えるほど、他製品との差が顕著に。 4. 【実績】なぜ業界リーダーが Elastic を選ぶのか 世界中の企業が選ぶプラットフォーム Fortune 500 の 54%以上 が 採用 50億回以上 の ダウンロード実績 1,500以上のグローバルパートナーとのエコシステム 300以上のターンキー統合で既存環境とシームレスに連携 NYSE上場企業(ティッカーシンボル: ESTC)としての信頼性 米国国防総省・情報機関でも採用される実戦 レベルの技術 EDR・SIEM・ログ管理・ML検知を単一プラットフォームで提供 オープンソースベース で 透明性が高く 、 拡張性に優れる 企業が得られる5つの価値 攻撃の入口で防御を可能にする設計 エンドポイントでの防御・検知・対応をリアルタイム実行 統合された可視性 端末・ネットワーク・クラウドを単一コンソールで管理 コスト効率の最適化 エージェント数無制限 データ使用量ベースの透明な料金体系 ティアリングで長期保管を現実的コストで実現 内部統制の強化 フィールドレベルの細かなアクセス制御+完全な監査証跡 投資対効果の説明力 「何が起きたか」「どう対応したか」を経営層に明確に説明可能 5. まとめ:「攻撃されることを前提」に設計された統合防御基盤 完全な防御は存在しません。重要なのは: ✅ 攻撃を入口(エンドポイント)で止めること ✅ 攻撃が本格化する前に気付けること ✅ 攻撃を受けた後、迅速に原因を特定できること Elastic Securityが統合する機能 レイヤー 機能 効果 エンドポイント防御 Elastic Defend (EDR) マルウェア・ランサムウェアを実行前に遮断 リアルタイム検知 1,300+ルール+ML 既知・未知の脅威を早期検知 振る舞い分析 UEBA 内部脅威・異常な振る舞いを分析 アクセス制御 フィールドレベルセキュリティ 内部不正リスク低減、監査対応強化 暗号化 通信・保存データ保護 セキュリティポリシーへの準拠 証跡管理 認証連携と監査ログ コンプライアンス対応 コスト最適化 データティアリング 高速アクセスと長期保管の両立 Elasticは、「分断された点の防御」から「統合された面の防御」へのパラダイムシフトを実現します。 6. 【次のステップ】SIOSテクノロジーにご相談ください こんなお悩みをお持ちの方へ 「エンドポイント防御とログ管理を統合したい」 「既存のEDR・SIEMからの移行を検討している」 「Elasticが自社に合うか知りたい」 「具体的な構築・運用支援が必要」 「コスト試算とROIを確認したい」 まずは無料相談から 弊社サイオステクノロジーはElasticsearchの国内初のディストリビューターです 。 お問い合わせフォームへ 💬 詳しく知る : Elastic公式サイト Elastic Security ソリューション Elastic Defend (EDR) Elastic公式ドキュメント Elastic Labs(ハンズオン環境) The post もう、攻撃後の「調査できない」は許されない、Elasticが実現する次世代セキュリティ基盤 first appeared on Elastic Portal .