目次 はじめに 作ったもの 誰のための記事か 1. 完成形を先に見る 地名では検索できない。それは意図的です 2. GIS の言葉と Elastic の言葉 3. 設計の原則：数字と事実は Elasticsearch、言葉は LLM 4. 部品の紹介 5. 属性の引き継ぎの仕組み 5-1. まず「ツール」とは何か 5-2. ツール 1：質問に近い内容の碑を探す 5-3. 「構造化された属性」とは 5-4. ツール 2：選んだ種別で避難場所を探す 5-5. 全体の流れ 5-6. 属性を使う理由と、その限界 5-7. 二つのデータで種別の名前が違う場合 5-8. 普通の RAG と何が違うか 6. 地図で確かめる 8. ほかの業界での使い方 9.限界と、次の回 まとめ 出典 はじめに 近所を歩いていて、古い石碑の前を通り過ぎたことはありませんか。 その中には、昔その土地をおそった洪水や土砂崩れのことを刻んだ碑があります。「自然災害伝承碑」と呼ばれる碑で、国土地理院が全国の碑の位置と説明文を公開しています。「ここまで水が来た」「この斜面が崩れて、人が亡くなった」。その土地で実際に起きたことの記録です。 でも、碑の教えを知っただけでは、まだ半分です。同じ災害がもう一度起きたら、今いる場所からどこへ逃げればいいのか。そこまでつながって、はじめて自分の身を守る情報になります。 そこで、この 2 つを 1 回の質問でつなぐ AI エージェントを作ってみました。AI エージェントは、質問に答えるために、必要な検索を自分で選んで実行するチャットボットです。日本語で、たとえばこう聞きます。 大雨で斜面が崩れた教訓を伝える碑はどこにある？ その災害のとき、近くのどこへ逃げればいい？ エージェントは、まず教訓の内容から碑を探します。次に、見つけた碑のデータから災害の種類を読み取ります。そして、その種類に対応した避難場所を、現在地の近くから探して答えます。 このように、場所の情報と AI を組み合わせる考え方を GeoAI（ジオ AI）と呼びます。「近く」は距離を測れば分かります。でも「斜面が崩れた教訓」は、文章の意味を読まないと分かりません。GeoAI は、この 2 つを一緒に扱います。 今回のエージェントでは、1 つ目の検索で見つけた碑の「災害の種類」が、そのまま 2 つ目の検索の条件になります。 Elastic は、Elasticsearch という検索エンジンを中心にした製品です。Elasticsearch は、大量のデータを入れて、すばやく探すための仕組みです。Web サイトの検索のほか、システムの監視（オブザーバビリティ）や、セキュリティの分析にも使われています。Kibana は、そのデータを扱うためのWebベースのユーザーインターフェースです。グラフや地図を作ったり、AI エージェントを作ったりできます。今回のエージェントも、Kibana の中で動いています。なお、今回のエージェント環境には、インフラの構築や管理が不要な Elastic Serverless を使用しています。 今回 Elastic を使ったのは、自然言語で見つけた情報の構造化された属性を、そのまま次の地理空間検索の条件にできるからです。 もう 1 つの理由は、同じ基盤をほかの業務にも使えることです。GeoAI のために用意した Elastic の上で、システムの監視やセキュリティの分析もできます。1 つの目的のためだけの道具を増やさずに済みます。 作ったもの Kibana の中で動く、防災の AI エージェントです。利用者が日本語で質問すると、近くの「自然災害伝承碑」と「指定緊急避難場所」を探して答えます。 出典：国土地理院ウェブサイト ( https://www.gsi.go.jp/bousaichiri/denshouhi.html ) 自然災害伝承碑 は、はじめにで紹介した、昔の災害の様子や教訓を刻んだ石碑です。 指定緊急避難場所 は、市町村が災害の種類ごとに指定した避難先です。たとえば「洪水のときは使えるが、土砂災害のときは使えない」のように、施設ごとに対応する災害が決まっています。 検索の中心は、利用者の現在地です。現在地は、ブラウザの Chrome 拡張で取得して、チャットに渡します。はじめにの質問に答えるには、碑を探す検索と、避難場所を探す検索の 2 つが必要になります。そして、1 つ目の検索の結果を使って、2 つ目の検索の条件を決めます。この PoCで確かめたかったのは、このつなぎ目がうまく動くかどうかです。 誰のための記事か GeoAI に興味がある、いろいろな業界の方に読んでいただきたいと思っています。特に、次のような方です。 GeoAIという言葉は知らないけれど、店舗、物件、設備、防災など、場所に関わる課題をAIでなんとかできないかと考えている方 GeoAI は知っているけれど、Elastic でもできることは知らなかった方 防災は実例の一つです。同じ考え方は、ほかの業界でも使えます（7 節）。Elastic を初めて知る方にも読めるように、用語はそのつど説明します。 連載は2回です。 連載 テーマ 第1回（この記事） 考え方と全体像。自然言語の検索結果を、地理空間検索につなぐ 第2回 エージェントの中身と、現在地の渡し方。ES|QL のツール、semantic_text、意味の点数と並び順、現在地の 7 分の期限と削除 1. 完成形を先に見る 筆者は川口市内から現在地を送り、エージェントに次の質問をしました。 現在地から半径 30km 以内で、大雨で斜面が崩れて人が亡くなったという教訓を伝える碑を探してください。そのうえで、その碑の教訓に関係する災害に対応した指定緊急避難場所を、現在地から 5km 以内で教えてください。 エージェントの動きは、次の3段階でした。 意味で碑を探す。 「斜面が崩れて人が亡くなった」という言葉の意味に近い碑を探します。一番近くで見つかったのは「園部おまわりさんありがとうきねん碑」（東京都北区、現在地から約 7km）です。1958 年の狩野川台風の記録で、説明文には「大雨で区内の急斜面60数か所で土砂が崩れ、13名の命が奪われた」とあります。質問の「亡くなった」は、説明文では「命が奪われた」と書かれています。言葉が違っても、意味が見つかりました。 碑のデータから、災害の種類を読む。 この碑のデータには、災害の種類として「土砂災害」と「洪水」の 2 つが登録されています。エージェントは、質問（斜面が崩れた）に合う「土砂災害」を選びます。 その種類で、避難場所を絞る。 「土砂災害」に対応する指定緊急避難場所を、現在地から 5km 以内で、近い順に探します。 回答の中には、碑のデータを使って避難場所を探したことが、そのまま書かれていました。 1件目の碑の登録災害種別「土砂災害」を使って、現在地から半径5km以内の指定緊急避難場所を検索しました。 Agent Builderの画面 ここで大事なのは、2 段階目です。利用者の質問には「土砂災害」という言葉が入っていません。「土砂災害」は、1 つ目の検索で見つけた碑のデータから来ています。その値が、2 つ目の検索の条件になっています。この記事では、この流れを「 属性の引き継ぎ 」と呼びます。仕組みは 5 節でくわしく説明します。 地名では検索できない。それは意図的です このエージェントは、利用者の現在地だけを検索の中心にします。「赤羽付近で探して」「神戸の市役所の近くは？」のように地名を伝えても、検索はしません。地名や住所を座標（緯度・経度）に変える処理を ジオコーディング と言いますが、これを意図的に入れていません。理由は 3 つです。 地名は、1 つの点に決まらないことが多いからです。 「赤羽付近」は、どこを中心にするか決められません。同じ名前の地名も全国にあります。たとえば「中央区」は、東京都にも大阪市にもさいたま市にもあります。 中心を間違えると、間違った避難場所を案内してしまうからです。 しかも、利用者はその間違いに気づきにくいです。防災の道具では、これが一番危険です。 ジオコーディングの正しさを確かめること自体が、大きなテーマだからです。 筆者は以前、住所を座標に変える検証をしました（「[日本の住所の表記揺れをElasticsearchで検証しようとして、やめました](【URL を入れる】)」）。そのとき一番の壁になったのは、検索の仕組みではありませんでした。「どの座標が正しいか」を決める正解データを用意することでした。この記事の主題は属性の引き継ぎなので、ここは切り離しました。 現在地は、端末が測った緯度・経度をそのまま使います。そのため、中心がぶれず、記事の話もぶれません。 2. GIS の言葉と Elastic の言葉 地図のデータを扱う仕組みを、GIS（地理情報システム）と呼びます。GIS でよく使う言葉が、Elastic では何にあたるかを並べます。 GIS での言い方 Elastic での言い方 この記事での例 点のデータ geo_point 型のフィールド 碑や避難場所の位置 レイヤー、データセット インデックス 伝承碑のインデックス（表）、避難場所のインデックス（表） 属性 フィールド（表の列） 名称、災害種別、説明文 半径 n km 以内 ES|QL の ST_DISTANCE 現在地から 5km 以内 地図に重ねて表示 Kibana Maps のレイヤー 現在地、碑、避難場所の3レイヤー （GIS にはあまりない） semantic_text（意味検索） 碑の説明文を、意味の近さで探す 距離は、地球の丸みを考えた 2 点間の直線距離です。道路距離や徒歩距離ではありません。 最後の行の semantic_text は、文章を「意味を表す数字の並び（ベクトル）」に変えて保存する型です。これで、言葉が違っても意味が近い文章を探せます。Elastic では、 同じ表の中に「位置」「属性」「文章の意味」を一緒に持てます。 これが、この記事の話の土台です。 3. 設計の原則：数字と事実は Elasticsearch、言葉は LLM このエージェントは、LLMと Elasticsearch が役割を分けて動きます。 仕事 担当 碑や避難場所までの距離を計算し、指定した半径内か調べる Elasticsearch 避難場所に、指定した災害種別が登録されているか調べる Elasticsearch 質問と意味が近い碑を、回答の候補として探す Elasticsearch 候補の説明文を読み、質問に合う碑を選ぶ LLM 碑に災害種別が複数あるとき、質問に合うものを選ぶ LLM 足りない条件を聞き返し、検索結果を説明する LLM たとえば「大雨で斜面が崩れた教訓」を探すと、碑の候補に「土砂災害」と「洪水」の両方が登録されていることがあります。どちらを次の検索に使うかは、LLM が質問と碑の説明文を読んで選びます。選んだ「土砂災害」に対応する避難場所かどうか、現在地から 5km 以内かどうかは、Elasticsearch がデータを使って判定します。 LLM に自由に災害種別の名前を作らせると、データにない「がけ崩れ」などを検索条件にして、該当施設を見落とすおそれがあります。そこで、碑のデータに登録された種別から選ぶよう指示しています。碑と避難場所で名前が違う「火山災害」と「火山現象」だけは、指示文に書いた対応に従って置き換えます（5-7節）。利用者の質問や碑の説明から種別を選べない場合は、推測せずに聞き返します。 ただし、 LLM が選ぶこと自体に間違いの余地は残ります 。この PoC は、過去の災害の記録と、災害種別に対応して登録された避難場所を探すための実験です。避難の必要性や経路の安全を判定するものではありません。避難場所の開設状況も分からないため、その点を回答に添えています。 4. 部品の紹介 この仕組みは、4つの部品でできています。ここでは役目だけを紹介します。中身は第2回で説明します。 部品 このPoCでの役目 semantic_text 碑の説明文を意味で探せるようにする。インデックスの定義に書くだけで、ベクトルへの変換は Elastic 側が行う ES|QL Elasticsearch の問い合わせ言語。意味検索、属性の絞り込み、距離の計算を1本の問い合わせで書ける Agent Builder Kibana の中で AI エージェントを作る機能。ES|QL の検索を「ツール」として持たせ、日本語の質問に答えさせる Kibana Maps 検索の結果を地図に重ねて、位置関係を目で確かめる 現在地は、Chrome 拡張でブラウザから取得し、ローカルのサーバーを通して会話に添付します。現在地は伝承碑や避難場所のデータには保存しません。現在地には 7 分の有効期限を付け、期限を過ぎたら検索に使いません。また、ローカルのサーバーが動いている間は、取得から 7 分後に会話ごと削除を試みます。サーバーを止めていた場合は、会話を手で消す必要があります。詳しくは第2回で説明します。 5. 属性の引き継ぎの仕組み 冒頭で紹介した「大雨で斜面が崩れた碑と、その災害に対応する避難場所を探す」という質問を例に、二つの検索の間で何を渡したのかを見ていきます。 5-1. まず「ツール」とは何か この PoC では、検索の手順を ES|QL であらかじめ作り、Agent Builder にツールとして登録しました。エージェントは検索文を一から書くのではなく、質問や前の検索結果から必要な値を取り出して、ツールに渡します。 たとえば避難場所を探すツールには、次の値を渡します。 渡す値 例 出どころ 災害種別 土砂災害 先に見つけた碑の登録データ 半径 5km 利用者の質問 検索の中心 現在地の緯度・経度 会話に添付した現在地 ツールは、受け取った値を使って「災害種別が一致し、現在地から半径内にある避難場所を、近い順に最大10件返す」という、あらかじめ決めた検索を実行します。値を入れる場所を 引数 と呼びます。引数に何を入れるか、どのツールを使うかはLLMが決めます。距離の計算や、登録された種別との一致判定はElasticsearchが行います。 このエージェントには、自分で作った検索ツールが三つあります。ここでは、碑を意味で探す ツール1 と、避難場所を探す ツール2 を使います。碑を単純に近い順で探すツール3は、第2回で紹介します。 5-2. ツール 1：質問に近い内容の碑を探す 利用者は「現在地から半径30km以内で、大雨で斜面が崩れて人が亡くなったという教訓を伝える碑」と質問しました。ツール1には、次の値が渡されます。 引数 出どころ 値 query（探す内容） 利用者の質問から、碑についての部分を取り出す 大雨で斜面が崩れて人が亡くなったという教訓 radius_km（半径） 利用者の質問 30 latitude 、longitude（検索の中心） 会話に添付された位置情報 現在地 「そのうえで避難場所を教えてください」という後半は、碑の内容を探すための文には含めません。一方、「斜面が崩れて人が亡くなった」は「土砂災害」という一語に言い換えず、利用者の言葉をできるだけ保ちます。意味検索は、説明文に同じ単語がなくても、内容の近い碑を候補にできるからです。 ツール1は、現在地から30km以内にある碑のうち、質問に意味が近いものを最大10件返します。ここで返るのは 回答の候補 で、10件すべてが質問に合うという意味ではありません。今回の候補の一つは「園部おまわりさんありがとうきねん碑」でした。 データの項目 この碑に登録された内容の例 名称 園部おまわりさんありがとうきねん碑 説明文 「急斜面60数か所で土砂が崩れ、13名の命が奪われた」など 災害種別 土砂災害、洪水 現在地からの距離 約7km（公開用に1km単位へ丸めた値） 質問の「人が亡くなった」に対し、説明文は「命が奪われた」と書いています。この碑が質問に合うかどうかは、候補を受け取ったLLMが説明文を読んで判断します。 5-3. 「構造化された属性」とは 上の表には、性質の違う二つの情報があります。 説明文 は自由に書かれた文章です。一方、 災害種別 には「洪水」「地震」「土砂災害」など、データで決められた値が入っています。今回の碑には「土砂災害」と「洪水」の二つが登録されています。 このように、項目名と値が決まった形で保存されている情報を、ここでは 構造化された属性 と呼びます。LLMが説明文から新しい災害名を作ったわけではありません。この碑に登録されていた値を、次の検索に利用します。 5-4. ツール 2：選んだ種別で避難場所を探す 質問は「斜面が崩れた教訓」です。そのため、LLMは碑に登録された二つの値から「土砂災害」を選び、避難場所を探すツール2に渡しました。 引数 値 出どころ disaster_type（災害種別） 土砂災害 ツール1が返した碑の登録データから、LLMが選ぶ radius_km（半径） 5 利用者の質問 latitude 、longitude（検索の中心） 現在地 会話に添付された位置情報 ツール2は、 「土砂災害」が対応種別として登録されている避難場所 を、現在地から5km以内で探し、近い順に最大10件返します。距離の中心は碑ではなく、利用者の現在地です。災害種別は完全一致で調べるため、碑の説明文そのものを引数に渡しても、登録された種別とは一致しません。 5-5. 全体の流れ ここまでをまとめると、次のようになります。 利用者の質問（文章） │ LLM が「碑の中身」を切り出す ▼ ツール 1 query = 「大雨で斜面が崩れて人が亡くなったという教訓」 │ Elasticsearch が意味で碑を探す ▼ 碑のデータ disaster_types = ["土砂災害", "洪水"] ← 構造化された値 │ LLM が質問に合う「土砂災害」を選んで書き写す ▼ ツール 2 disaster_type = 「土砂災害」 │ Elasticsearch が種別の一致と距離で絞る ▼ 現在地から 5km 以内の、土砂災害に対応した避難場所 文章で始まった質問が、途中で「土砂災害」という決まった言葉に変わり、それが地理空間検索の条件になっています。これが「属性の引き継ぎ」です。 5-6. 属性を使う理由と、その限界 碑の説明文だけを読んでLLMに災害種別を自由に作らせると、避難場所のデータと名前が合わない場合があります。登録済みの種別から選べば、次の検索に使った値と出どころを確認できます。回答には、たとえば「碑の登録災害種別『土砂災害』を使って検索しました」と書けます。 ただし、 登録済みの値から選んでも、必ず正しい値を選べるわけではありません 。「土砂災害」と「洪水」のどちらが利用者の質問に合うかはLLMの判断です。決められない場合は聞き返すように指示しています。また、避難場所にその種別が登録されていても、今開設されていることや、そこへ安全に移動できることは分かりません。 意味検索が返すのは、質問に近い上位10件の候補です。その中に合う碑がなくても、地域内の全碑に該当するものがないとは言えません。一方、災害種別と距離だけで登録件数を調べれば、「このデータと範囲では登録が0件」と確認できます。 ES|QLにはデータを結び付ける`LOOKUP JOIN`もあります。しかし、今回の例では、まず二つある登録種別から質問に合う一つを選ぶ必要があります。その判断をエージェントが行い、選んだ値をツール2へ渡す設計にしました。ES|QLだけでは原理的に実現できない、という意味ではありません。 5-7. 二つのデータで種別の名前が違う場合 碑と避難場所は別々に公開されたデータです。多くの種別は同じ名前ですが、すべてが一致するわけではありません。 碑に登録された種別 避難場所のデータで使う種別 このPoCでの扱い 洪水、地震、土砂災害、津波、高潮 同じ名前 登録された値をそのまま使う 火山災害 火山現象 指示文に書いた対応に従って置き換える その他 対応する種別がない 避難場所の条件には使わない 避難場所側だけにある「大規模な火事」「内水氾濫」は、碑からは引き継ぎません。利用者が避難場所の種別として直接指定すれば、その種別で検索できます。 実際に「浅間山の噴火で亡くなった人を供養する碑」を探した例では、「信州浅間山噴火以来天災横死者供養塔」が見つかりました。登録種別は「その他」と「火山災害」です。エージェントは「火山災害」を選び、避難場所側の「火山現象」に置き換えて検索したことを回答に書きました。「その他」は対応する種別がないため使っていません。 この置き換えは、今はLLMへの指示文に書いてあります。LLMが対応を取り違える可能性は残るため、より厳密にするなら対応表をデータとして用意し、変換をプログラムで行う方法があります。 実際に、火山の碑で試しました。 現在地から半径 30km 以内で、浅間山の噴火で亡くなった人を供養する碑を探してください。そのうえで、その碑の教訓に関係する災害に対応した指定緊急避難場所を、現在地から 5km 以内で教えてください。 一番近い一致は「信州浅間山噴火以来天災横死者供養塔」（東京都墨田区）で、種別は「その他」と「火山災害」の 2 つでした。エージェントはこう答えました。 碑の登録災害種別に含まれる「火山災害」を使用し、避難場所の対応区分「火山現象」で検索しました（碑の「その他」区分には対応する避難場所種別がないため使用していません）。 5-8. 普通の RAG と何が違うか RAG（検索拡張生成）は、検索で見つけた文章を LLM に渡して、答えを書かせる仕組みです。今回もその一種です。 違いは、検索結果の 文章 だけでなく、 構造化された属性 を次の検索の条件に使っていることです。検索の条件に使う値は、データに登録された値です。LLM が考え出した値ではありません。LLM は、その値を選び、必要なときは対応表に従って置き換えます。 6. 地図で確かめる 検索の結果は、数字だけだと位置関係が分かりにくいです。そこで Kibana Maps に3つのレイヤーを重ねました。 現在地（●） 自然災害伝承碑（▲） 指定緊急避難場所（■） 伝承碑と避難場所のインデックスは、もともと geo_point 型の位置を持っています。そのため、そのまま地図のレイヤーにできます。 ただし、全部を描くと画面が避難場所で埋まります。そこで地図でも、災害種別という属性で絞ってから描きます。災害」で絞ると 146 件、「洪水」なら 498 件です。どの種別を引き継ぐかで、地図に出る避難場所が変わります。 ただし、この地図はチャットとは 連動していません 。エージェントが「土砂災害」を選んでも、地図は自動では切り替わりません。筆者が Kibana Maps の検索欄に disaster_types : “土砂災害” のように手で入れて、絞っています。また、地図に描かれるのは、エージェントが返した 10 件ではありません。インデックスの中で、その種別を持つ避難場所すべてです（画面に入る範囲）。 8. ほかの業界での使い方 防災の例を、一般的な形に直すと次のようになります。 自然言語で探す → 見つけたものの構造化属性を読む → その属性で地理空間検索をする 以下は、この形を当てはめたアイデアです。この PoC では検証していません。 業界 自然言語の質問 引き継ぐ属性 地理空間検索 不動産 子育てしやすい、静かな物件 物件の種別、設備のタグ 駅や学校からの距離 小売 雨の日のキャンプで使えるもの 商品カテゴリ 在庫がある近くの店舗 設備保守 ポンプから異音がするという報告 故障コード 対応できる近くの拠点 どの例でも、Elastic では「文章の意味」「属性」「位置」を同じインデックスに持てます。そのため、この形を1つの基盤で組めます。 9.限界と、次の回 この PoC で確認したのは、 碑の登録災害種別を次の検索条件に使えること です。一方で、次の限界があります。 LLM の判断は間違うことがあります。 質問に合う碑や、碑に複数ある災害種別のどれを使うかは、LLM が選びます。登録済みの値を使っても、選択の正しさは保証されません。 チャットと地図は連動しません。 地図上の災害種別は筆者が手動で切り替えました。チャットが返した10件を地図へ自動表示する機能は、今回作っていません。 回答には時間がかかります。 碑と避難場所を続けて探した例では、チャット画面の表示時間は51〜69秒でした。1回分のトレースでは、確認できた処理の中でLLMの呼び出しが最も長くなりました。処理時間の詳細は第2回で扱います。 また、検索の中心は利用者の現在地に限っています。地名や住所を指定した場所の検索は、この PoC の対象外です。 第2回では、三つの検索ツールをどう設定したか、意味検索の候補をどう扱うか、現在地を会話に渡して期限を管理する仕組みを説明します。 まとめ この PoC では、 自然言語で見つけた碑の登録災害種別を、現在地周辺の避難場所を探す次の条件に使いました。 これが、この記事でいう「属性の引き継ぎ」です。 「斜面が崩れた」という質問に合う碑を探すと、その碑には「土砂災害」と「洪水」が登録されていました。LLM は質問に合う「土砂災害」を選び、避難場所の検索ツールに渡します。Elasticsearch は、指定した種別との一致と現在地からの距離を調べ、条件に合う施設を返します。 検索に使った値の出どころを示せるのが、この方法の利点です。ただし、どの碑や種別を選ぶかというLLMの判断には誤りの余地があります。結果は過去の記録と登録された避難場所を調べるためのもので、現在の安全や避難の必要性を判定するものではありません。 出典 出典：国土地理院「 自然災害伝承碑データの提供について 」（2026年8月27日版を2026年9月5日に取得） 出典：国土地理院「 指定緊急避難場所データ 」（2026年9月5日に取得） 本記事の検索結果と地図は、上記データをもとに筆者が災害種別の整理、検索、集計、可視化を行って作成しました。掲載した結果は取得時点のデータと、このPoCの検索条件によるものです。 AI エージェントの「中で何が起きたか」を見える化する　 https://elastic.sios.jp/blog/visualizing-what-happens-inside-ai-agent/ The post 自然言語と位置情報をつなぐ、GeoAIエージェントの作り方 first appeared on Elastic Portal .

Logstashを用いたログ収集基盤において、フォーマット不整合によるパース失敗や、Elasticsearch側のマッピング衝突による書き込みエラーは避けて通れません。本記事では、運用負荷を下げるためのLogstashエラー処理設計パターンについて解説します。 目次 1. Logstashにおけるエラーの分類 2. フィルター処理でのエラーハンドリング（タグベースの分岐） タグを利用したエラーログの分離ルーティング 3. 主要 filter プラグインとデフォルトエラータグのマップ 4. まとめ：エラーを検知・退避し、再投入できる堅牢なパイプラインへ 1. Logstashにおけるエラーの分類 Logstashパイプラインで発生するエラーは、発生箇所と性質によって大きく2つに分類されます。 エラー種別 発生タイミング 主な原因 デフォルトの挙動 パース・データ変換エラー filter ステージ ログフォーマットの変更、型変換失敗 エラータグ（ “_grokparsefailure” 等）を付与してパイプラインを継続 データ書き込みエラー output ステージ ネットワーク障害（5xx/不通）、マッピング衝突（400/409） 接続障害は自動再試行。マッピング不整合などは破棄（デフォルト） ※本記事では、 「パース・データ変換エラー」のエラーハンドリング について解説します。（データ書き込みエラーのエラーハンドリングについては、別の機会に解説したいと思います。） 2. フィルター処理でのエラーハンドリング（タグベースの分岐） データ変換時の挙動について、まず理解しておくべき重要な原則があります。 grok や json フィルター等でパースに失敗しても Logstash はイベントを破棄せず、tags フィールドにエラー識別子タグを付与して後続処理へと渡します。 つまり、フィルター処理でパースに失敗したログも破棄されることなく output ステージへそのまま渡されます。そのため、適切な分岐処理を行わなければ、壊れたデータがそのままメインのインデックスに書き込まれてしまう点に注意が必要です。 Gemini Notebookによるイメージ図 タグを利用したエラーログの分離ルーティング 正常ログとエラーログを同一インデックスに混ぜないよう、 output ステージで条件分岐して退避インデックス（例：invalid-logs-blogs-%{+ YYYY.MM }）へ送る設定例です。 input { file { path => "/var/log/app/*.log" start_position => "beginning" } } filter { grok { match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:loglevel} %{GREEDYDATA:msg}" } } date { match => [ "timestamp", "ISO8601" ] remove_field => [ "timestamp" ] } } output { # パース失敗タグが含まれているかを判定 if "_grokparsefailure" in [tags] or "_dateparsefailure" in [tags] { elasticsearch { hosts => ["https://localhost:9200"] api_key => "${API_KEY_FOR_INVALID_LOGS}" data_stream => false index => "invalid-logs-blogs-%{+YYYY.MM}" } } else { elasticsearch { hosts => ["https://localhost:9200"] api_key => "${API_KEY}" data_stream => true data_stream_type => "logs" data_stream_dataset => "blogs" data_stream_namespace => "sample" } } } この設定により、正常なログのみをメインのデータストリームへ流し、フォーマットエラーを起こしたログを退避用インデックスに確実に分離・保管することができます。 Gemini Notebookによるイメージ図 3. 主要 filter プラグインとデフォルトエラータグのマップ エラーログを正しく捕捉・分離するためには、使用している filter プラグインが「どのエラータグを付与するのか」を正確に把握しておく必要があります。 以下は、処理中にエラーが発生した場合に tags フィールドにエラー情報を格納する代表的な filter プラグインの一覧です（2026年9月現在）。 カテゴリー filter プラグイン デフォルトのエラー用tag 主なエラー原因（推測） パース・変換系 date “_dateparsefailure” 日付フォーマットのパース失敗 de_dot “_de_dot_error” フィールド名のリネーム（ドット除去）処理失敗 dissect “_dissectfailure” 区切り文字ベースのパース失敗 grok “_grokparsefailure”, “_groktimeout” パターン不一致によるパース失敗、またはタイムアウト json “_jsonparsefailure” JSON形式のパース失敗 kv “_kv_filter_error”, “_kv_filter_timeout” Key-Valueペアの抽出失敗、またはタイムアウト mutate “_mutate_error” フィールド変換や置換などの処理失敗 ruby “_rubyexception” Rubyコード実行中の例外発生 urldecode “_urldecodefailure” URLデコード処理の失敗 外部通信・ルックアップ系 dns “_dnstimeout” DNS解決のタイムアウト elasticsearch “_elasticsearch_lookup_failure” Elasticsearchへのルックアップ失敗 geoip “_geoip_lookup_failure” IPアドレスからの位置情報取得失敗 memcached “_memcached_failure” Memcachedへのアクセスまたはルックアップ失敗 データベース系 jdbc_static “_jdbcstaticfailure” 静的データセットを用いたJDBCルックアップ失敗 jdbc_streaming “_jdbcstreamingfailure” 動的なクエリによるJDBCルックアップ失敗 これらの filter プラグインを利用する際は、意図しないフォーマットのログによってエラータグが付与されていないか注意し、 退避用インデックスの監視や失敗ログの再投入設計をあわせて検討しておくことをおすすめします。 4. まとめ：エラーを検知・退避し、再投入できる堅牢なパイプラインへ Logstashにおけるエラーハンドリングの基本は、 「エラータグを検知し、正常ログと分離して退避インデックスへルーティングすること」 です。 この設計を取り入れることで、メインインデックスの汚染やデータロストを防ぎ、運用負荷を大きく軽減できます。 パイプラインの構築・運用にあたっては、単にログを退避させるだけでなく、以下のポイントをあわせて検討することをおすすめします。 エラータグの特定 : 使用する filter プラグインが付与するタグを正確に把握する。 退避ルーティングの実装 : output ステージでタグ判定を行い、退避用インデックスに送る。 運用プロセスの確立 : 退避用インデックスの監視および失敗ログの再投入設計をあわせて検討・整理しておく。 あなたのLogstashパイプラインでは、パースエラーを起こしたログがどこへ向かっているか把握できていますか？ この機会にぜひ、現在のフィルター処理とエラーハンドリング設計を見直してみてください。 The post Logstash の filter プラグインにおけるエラー処理設計の最適化（タグ付け分岐） first appeared on Elastic Portal .

目次 誰の、どんな問題を解決する記事か トレースの基本構造 スパンの種類 どこに、どんな名前で保存されるか 準備 トレース収集の設定を確認する サンプルデータを入れる 四つの調査シナリオ シナリオ 1：ツールを使わない場合と使う場合の比較 シナリオ 2：複数ツールを使った処理の遅延調査 ツールの中で LLM が呼ばれている 入力トークンはラウンドの中でも増える 同じ質問をもう一度送ると シナリオ 3：ツールエラーの調査 シナリオ 4：長い会話のトークン増加調査 小さな注意：View Trace はすぐに開かない ダッシュボードで環境全体を見る 実務で使う ES|QL 3 本 ラウンド（トレース）ごとの集計 ツール別の呼び出し回数とエラー数 モデル別のトークン使用量 最初に作るアラート 2 つ 会話ごとのトークン上限 ツールの失敗 作るときの注意点と、応用の例 プライバシー設定とアクセス権 トレースと会話履歴は別の保存先 アクセス権は「インデックス単位」 参考資料 誰の、どんな問題を解決する記事か AI エージェントを PoC から運用に進めると、次のような場面に必ず出会います。 回答は返ってきたが、なぜ 30 秒もかかったのか分からない 検索したはずなのに、答えが実データと合わない トークンの消費が想定より多い。Agent の作り方の問題か、使い方の問題か判断できない この記事は、Elastic Agent Builder を使っていて、こうした「回答の裏側」を調べたいエンジニアのために書きました。この分野は Agent Observability（エージェントの可観測性） と呼ばれ、Splunk など他社も同じ名前で製品を出し始めています。求められていることは共通です。処理の流れを追って原因を突き止めること、トークンとコストを追うこと、異常を検知することです。 Elastic 9.5 では、Agent Builder の実行を OpenTelemetry（OTel）形式で記録する Agent Observability and Monitoring が Technical Preview として発表されました。LLM 呼び出し、ツール呼び出し、処理時間、トークン使用量を Elasticsearch に保存し、1 回の回答から環境全体の傾向まで確認できます。 この記事では、Kibana の標準サンプルデータ（Sample eCommerce orders）を使い、Agent Builder に質問して本物のトレースを作りました。その結果をもとに、 個別の調査 → 全体の監視 → 自動通知 の順で説明します。 トレースの基本構造（会話、ラウンド、スパン） 4 つの調査シナリオを View Trace で読む 環境全体を Overview ダッシュボード で見る 実務で使う ES|QL 3 本と、最初に作る アラート 2 つ 本番導入前に決める プライバシー設定と権限 トレースは普通の Elasticsearch データです。Discover や ES|QL の知識がそのまま使えます。 検証環境 : Elastic Cloud Serverless（検証日: 2026 年 9 月 16 日）。トレースに記録された Kibana のバージョンは 9.6.0 でした。Serverless は機能が順次提供されるため、画面や項目名がスタック版と異なる場合があります。 Agent Observability and Monitoring は、Elastic 9.5（2026 年 8 月 4 日発表）で Technical Preview として発表されました。 トレースの基本構造 Agent Builder のトレースは、 会話 > ラウンド > スパン の 3 段でできています。 段 意味 ID 会話（conversation） 1 つのチャット画面 gen_ai.conversation.id ラウンド（round） メッセージを 1 回送って、回答が 1 回返るまで trace_id（1 ラウンド = 1 トレース） スパン（span） ラウンドの中の 1 つの処理 span_id スパンの種類 スパンは主に 4 種類です。種類は attributes.elastic.inference.span.kind という属性に入っています。 スパン名の形 種類 何を表すか 主に確認できること invoke_agent <Agent 名> CHAIN ラウンド全体（一番外側の箱） 全体時間、成否 invoke_agent <Agent 名> AGENT Agent 1 回分の実行 Agent 単位の時間、成否 chat <モデル名> LLM LLM へのリクエスト モデル、プロバイダー、入力・出力トークン、時間 execute_tool <ツール名> TOOL 検索や ES|QL 実行などのツール どのツールか、時間、成功・失敗 invoke_agent は CHAIN と AGENT の 2 つの意味で使われます。区別するときは span.kind を見ます。このほかに generate_title（会話タイトルの生成）と generate_esql（自然言語から ES|QL を作る処理）というスパンも出てきます。どちらも中で LLM を呼びます。 どこに、どんな名前で保存されるか トレースは traces-agent_builder.otel-<Space ID> というデータストリームに保存されます。 Default Space なら traces-agent_builder.otel-default です。 隠しインデックスではなく、普通のデータストリーム なので、Discover、Lens、Dashboard、ES|QL、アラートルールがそのまま使えます。 属性の多くは、OpenTelemetry の GenAI セマンティック規約（ gen_ai.* ）に沿った名前です。今回の検証で確認できた主なものを挙げます。 属性 意味 実測の例 gen_ai.operation.name 処理の種類 chat、execute_tool、invoke_agent gen_ai.request.model / gen_ai.response.model モデル名 anthropic-claude-5-sonnet gen_ai.provider.name プロバイダー名 elastic gen_ai.usage.input_tokens / output_tokens 入力・出力トークン数（long 型） 17,154 / 84 gen_ai.conversation.id 会話の ID（既定では匿名化されたハッシュ） 399b6330a91f4697 gen_ai.tool.name / gen_ai.tool.type / gen_ai.tool.call.id ツール名、種類、呼び出し ID platform.core.execute_esql、extension gen_ai.input.messages / gen_ai.output.messages 入出力メッセージ プライバシー設定オフのため [] Elasticsearch の OTel データストリームでは、これらは attributes.gen_ai.request.model のように attributes. の下に入ります。スパン名は name フィールドで、 span.name はその別名（alias）です。時間は duration にナノ秒で入ります。 ただし、すべてが標準というわけではありません。 gen_ai.* の規約はまだ試験段階です（Elastic の公式ドキュメントでは Experimental、OTel のレジストリでは Development と表記されています）。また、a ttributes.elastic.inference.span.kind と CHAIN、AGENT、LLM、TOOL という分類は、 elastic.* で始まる Elastic 独自の拡張です。つまり、保存形式は OTel、属性名は OTel の規約、スパンの分類は Elastic 独自、という 3 層になっています。 準備 トレース収集の設定を確認する Stack Management → GenAI Settings → Agent Build er Traces を開きます。 Collect conversation traces （agentBuilder:tracing:enabled）は既定でオンです。オフになっていると View Trace アイコンが表示されません。 Advanced privacy settings は既定ですべてオフです。今回はオフのまま進めます。理由は第 8 章で説明します。 同じ画面の Install Dashboard から、 [Elastic] Agent Builder Overview ダッシュボードを導入します。ダッシュボードは自動では入りません。Space ごとに導入が必要です。 サンプルデータを入れる Integrations を開き、 Sample Data と検索して Sample eCommerce orders を Install data します。インデックス名は kibana_sample_data_ecommerce です。件数を Dev Tools で確認しておきます。 GET kibana_sample_data_ecommerce/_count 結果は 4,675 件でした。後で Agent の回答と比べるために、この数字を控えておきます。 四つの調査シナリオ ここからが本題です。カスタム Agent やカスタムツールは作らず、標準の Elastic AI Agent だけを使います。モデルはチャット画面の既定のまま（表示は「Anthropic Claude Sonnet 5」）です。目的は回答の内容を評価することではなく、 質問の種類を変えると、トレースがどう変わるか を比べることです。 シナリオ 調べること 使う質問 1 ツールを使わない場合と使う場合の比較 短い回答だけの質問と、件数を実データで調べる質問 2 複数ツールを使った処理の遅延調査 2 段階の集計 3 ツールエラーの調査 存在しないインデックスの検索 4 長い会話のトークン増加調査 同じ会話で 3 回質問 各質問の後、回答の下にある View Trace アイコンをクリックします。フライアウトのヘッダーに Trace ID、スパン数、合計時間 が表示され、その下にウォーターフォールが並びます。各行にスパンの種類と時間、LLM 呼び出しの行には入力・出力トークン数が出ます。 シナリオ 1：ツールを使わない場合と使う場合の比較 まず基準値を取ります。ツールを使わない短い回答です。 「トレース基本テスト成功」とだけ回答してください。ツールは使用しないでください。 次に、ツールを 1 回使わせます。 kibana_sample_data_ecommerce のドキュメント数を、Elasticsearch の実データを検索して確認してください。推測では答えず、必ず利用可能なツールを使ってください。最終回答には件数と、検索に成功したかどうかだけを書いてください。 項目 ツールなし ツール 1 回 スパン数（View Trace） 4 6 合計時間 4,579 ms 6,307 ms 回答を作る LLM 呼び出し 1 回（4,168 ms） 2 回（3,369 ms と 2,188 ms） ツール呼び出し 0 1 回（platform.core.execute_esql、31 ms） 入力／出力トークン（本体） 17,154 / 84 17,581 / 16 ステータス Ok Ok この比較から 3 つのことが分かります。 1 つ目は、短い質問でも入力トークンが約 17,000 ある ことです。入力トークンは画面に入力した文章だけではありません。Agent のシステム指示、利用できるツールやスキルの定義も LLM への入力に含まれます。この約 17,000 トークンは、いわば Agent の「基本料金」に近い部分です。この値は Agent の設定、有効なツールやスキルの数、製品のバージョンによって変わります。 2 つ目は、ツールの前後で LLM が呼ばれる ことです。今回は、1 回目の LLM 呼び出しで Agent が「どのツールを、どんな引数で使うか」を決め、ツールを実行した後、2 回目で結果を読んで回答を作りました。Agent が複数のツールをまとめて選んだり、結果を見てやり直したりすると、回数は増えます。時間の内訳を見ると、ツールの実行は 31 ms、LLM 呼び出しは合わせて 5,557 ms です。この質問では、時間のほぼ全部が LLM 待ちでした。 3 つ目は、頼んでいない generate_title スパンがある ことです。新しい会話の 1 ラウンド目には、会話のタイトルを自動で付ける処理が走ります。この処理は、回答を作るモデルとは別の軽いモデル（google-gemini-3.5-flash-lite、入力 249 / 出力 19 トークン）を使っていました。2 ラウンド目以降には出ません。 シナリオ 2：複数ツールを使った処理の遅延調査 kibana_sample_data_ecommerce で、最も注文数が多い商品カテゴリ（category）を調べてください。次に、そのカテゴリの注文の平均金額（taxful_total_price の平均）も調べてください。2 つの結果を、それぞれどのクエリで確認したかと一緒に答えてください。 回答は「Men’s Clothing（2,024 件）」と「平均 60.97（対象 908 件）」でした。 トレースは 18 スパン、34,707 ms です。シナリオ 1 より質問が複雑になっただけで、スパン数は 6 から 18 に、時間は 6 秒から 35 秒に増えました。内訳は、回答を作る chat が 6 回、ツールが 5 回（attachments.read、get_index_mapping、generate_esql、execute_esql 2 回）、そして generate_esql の中の chat が 2 回です。 ツールの中で LLM が呼ばれている ツリーを見ると、 execute_tool platform.core.generate_esql （2,553 ms）の下に generate_esql スパンがあり、その下に chat google-gemini-3.5-flash-lite が 2 つ入っています。「自然言語を ES|QL に変える」という仕事には、通常 LLM などの生成処理が必要です。Agent 本体（claude-sonnet）は「今は ES|QL が必要だ」と判断してツールを呼ぶだけで、実際のクエリ作成はツールの中の別のモデルに任せています。 つまり、ツールには 2 種類あります。ここでの「決定的」とは、同じ入力に対して基本的に同じ処理を行うという意味です。 ツールの種類 例 時間 決定的な処理を行うツール execute_esql（27 ms）、get_index_mapping（15 ms） Elasticsearch に問い合わせて結果を返す。速い 内部で LLM を呼ぶツール generate_esql（2,553 ms） 変換や生成のために LLM を呼ぶ。遅い 利用者の画面には tool: platform.core.generate_esql ran と 1 行出るだけです。その中で別のモデルが 2 回動いていたことは、トレースを見ないと分かりません。「ツールが遅い」と思っていたら、実は中の LLM が遅かった、という切り分けができます。 入力トークンはラウンドの中でも増える このラウンドの chat の入力トークンは、17,233 → 17,522 → 18,552 → 18,929 → 19,446 → 20,019 と増え続けました。ツールの結果が返るたびに、それが次の LLM 入力に追加されるためです。 なお、この実験では 1 回目の送信で画面に「Reasoning error: TypeError: network error」と表示されましたが、2回目に実行したら1回目と2回目の回答が無事に表示されました。問題は Agent の処理の外側（ブラウザへの配信経路のどこか）で起きたと考えられます。トレースは、記録された範囲で「Agent が何をしたか」を示しますが、「利用者の画面に何が起きたか」は範囲外です。 同じ質問をもう一度送ると 同じ会話で、同じ質問をもう一度送ってみました。今度は 3 スパン、9,915 ms、LLM 呼び出しは 1 回だけです。ツールは使っていません。Agent は「前回と同じ内容のご質問ですね」と答え、会話履歴から回答を作りました。入力トークンは 20,669 です。 「検索せずに履歴から答えた」ことが、ツールスパンが無いという形ではっきり見えます。回答が期待と違うときに、まず確認するべきポイントです。 シナリオ 3：ツールエラーの調査 Observability では、正常な処理だけでなく、 失敗した処理を見つけられること が重要です。存在しないインデックスを指定して、読み取りクエリを 1 回だけ実行させます。 利用可能な ES|QL 実行ツールで、次のクエリを変更せずに 1 回実行し、結果またはエラーを説明してください。 FROM trace-test-missing-index-v1 | LIMIT 1 別のインデックスには置き換えないでください。 Agent はクエリをそのまま実行し、 verification_exception: Unknown index [trace-test-missing-index-v1] というエラーを受け取りました。そして、インデックスが存在しないことが原因だと利用者に説明しました。 トレースは 7 スパン、14,610 ms です。execute_tool platform.core.execute_esql（14 ms）の status.code は Error でした。一方、ラウンド全体を表すルートの invoke_agent は Ok です。 ここで注目したいのは、 ツールの失敗と会話の失敗は別の概念 だという点です。ツールが失敗しても、Agent がそれを受け止めて説明できれば、会話としては成功です。監視するときは両方を見ます。ツールのエラー率は「壊れやすいツール」を見つけるため、Agent 実行のエラー率は「Agent が正常終了できなかった割合」を見るためです。 注意が 2 つあります。公式ドキュメントによると、execute_tool スパンの status.code が Error になるのは、主に引数やスキーマの検証エラーのときです。ツールの中でエラーを捕まえて、通常の結果として Agent に返した場合は Error になりません。今回の Unknown index は Elasticsearch が返した実行エラーでしたが Error として記録されました。ツールの実装によって扱いが違うので、 status.code だけですべてのツール失敗を拾えるとは考えないほうが安全です 。もう 1 つ、今回の設定（Include tool call details オフ）では、エラーの本文（Unknown index … という文字列）はトレースに保存されません。残るのは status.code = Error という事実だけです。 シナリオ 4：長い会話のトークン増加調査 新しい会話を 1 つ作り、その中で 3 回続けて質問しました。 kibana_sample_data_ecommerceにはどんなフィールドがありますか。主なものを10個だけ挙げてください。 そのうち、金額に関係するフィールドはどれですか。 その金額フィールドの中で、合計が一番大きいものはどれですか。実データで確認してください。 ラウンド 最初の chat の入力トークン ツール ラウンド全体の時間（ES|QL で集計） 1 17,167 get_index_mapping 14,667 ms 2 18,595 なし（履歴から回答） 9,913 ms 3 19,095 generate_esql、execute_esql 24,925 ms 入力トークンが 17,167 → 18,595 → 19,095 と、ラウンドを重ねるごとに増えています。 ラウンドを重ねると、過去の会話のコンテキストが入力に加わる ためです。なお、公式ドキュメントによると、Agent Builder は長い会話を圧縮（compaction）します。そのため、常に全履歴がそのまま送られるわけではありません。 シナリオ 2 の「ツール結果で増える」と合わせると、今回の実験で入力トークンが増えた主な理由は 2 つでした。会話が長くなること、そして 1 ラウンドの中でツールを何度も使うことです。このほかにも、システム指示の変更、有効なツールやスキルの変更、添付ファイル、会話の圧縮、モデルや製品バージョンの変更で入力トークンは変わります。トークンの監視では、1 回の呼び出しだけでなく、会話単位の合計を見ることが大切です。 小さな注意：View Trace はすぐに開かない 2 ラウンド目の直後に View Trace を開くと、「No spans found」と表示されました。少し待って開き直すと、3 スパンが表示されました。トレースの書き込みは非同期です。特に、ラウンド全体を表すルートの invoke_agent は、Agent の処理が終わった後に閉じられて書き込まれます。回答直後に開くと、このスパンや、終わったばかりのスパンがまだ入っていないことがあります。数字を記録するときは、少し待ってから ES|QL で数え直すのが確実です。 ダッシュボードで環境全体を見る 1 件の回答を詳しく調べるなら View Trace、複数の会話をまとめて監視するなら [Elastic] Agent Builder Overview ダッシュボードを使います。 ダッシュボードは 4 つのセクションに分かれています。今回の検証（会話ラウンド 10 回、約 19 分）の値を並べます。 セクション 確認できること 今回の値 Token Usage & Cost 入出力トークン合計、LLM リクエスト数、モデル別・プロバイダー別の内訳 入力 571,179、出力 11,067、リクエスト 40（sonnet 27、gemini 13） Conversation Volume & Latency 会話ラウンド数、平均・p95・最大の処理時間 10 ラウンド、平均 20.75 秒、p95 48.50 秒、最大 59.79 秒 Agent Execution Agent 別の実行回数と処理時間 elastic-ai-agent 10 回、平均 17.37 秒 Tool Call Frequency & Errors ツール呼び出し数、エラー数、成功率、平均時間、ツール別の内訳 17 回、エラー 1、成功率 94.1%、平均 2.78 秒 読み取れることが 3 つあります。 入力トークン 571,179 に対して、出力は 11,067 です。入力が出力の 50 倍以上あります。コストを考えるなら、入力側を見る必要があります。 Conversation（ラウンド全体）の平均 20.75 秒と Agent Execution の平均 17.37 秒には約 3.4 秒の差があります。ラウンドには、Agent の実行のほかに、タイトル生成や回答の保存といった処理が含まれるためです。 ツールの成功率 94.1% は黄色で表示されています。ダッシュボードの定義では、90% 未満が赤、90〜99% が黄、99% 以上が緑です。シナリオ 3 で意図的に起こした 1 回のエラーが、そのまま反映されています。 このダッシュボードは、すべてのパネルが ES|QL で作られています。データストリーム名が traces-agent_builder.otel-default と直接書かれているため、Space ごとに導入する必要があります。ダッシュボードは Elastic が管理する読み取り専用（Managed）です。自社向けに変えたいときは、 複製 してから編集します。パネルのクエリは、自分のダッシュボードを作るときの手本になります。 小さなコツを 1 つ。データが見えないときは、まず Time Picker を広げてください。既定の Last 15 minutes のままだと、少し前の会話は範囲外になります。 実務で使う ES|QL 3 本 トレースは普通のデータストリームです。ここでは、調査でよく使う 3 本のクエリと、その実測結果を紹介します。 ラウンド（トレース）ごとの集計 FROM traces-agent_builder.otel-default | WHERE @timestamp > NOW() - 3 hours | STATS spans = COUNT(*), llm_calls = COUNT(*) WHERE `span.name` LIKE "chat *", tool_calls = COUNT(*) WHERE `span.name` LIKE "execute_tool *", errors = COUNT(*) WHERE status.code == "Error", input_tokens = SUM(TO_LONG(attributes.gen_ai.usage.input_tokens)), output_tokens = SUM(TO_LONG(attributes.gen_ai.usage.output_tokens)), total_ms = MAX(duration) / 1000000, started = MIN(@timestamp) BY trace_id | SORT started ASC この 1 本のクエリで、ラウンドごとの違いが一目で分かります。 ポイントは 3 つです。span.name は name の別名で、公式ドキュメントに合わせてバッククォートで囲っています。duration の単位はナノ秒なので、1,000,000 で割ってミリ秒にしています。トークン数は公式ドキュメントに合わせて TO_LONG() で包んでいます。今回の環境では long 型だったので直接 SUM() もできましたが、型の違いに備えて公式例と同じ書き方にしています。 ツール別の呼び出し回数とエラー数 FROM traces-agent_builder.otel-default | WHERE @timestamp > NOW() - 3 hours AND `span.name` LIKE "execute_tool *" | EVAL duration_ms = duration / 1000000 | STATS calls = COUNT(*), errors = COUNT(*) WHERE status.code == "Error", avg_ms = AVG(duration_ms) BY `span.name` | SORT calls DESC モデル別のトークン使用量 FROM traces-agent_builder.otel-default | WHERE @timestamp > NOW() - 3 hours AND `span.name` LIKE "chat *" | STATS requests = COUNT(*), input_tokens = SUM(TO_LONG(attributes.gen_ai.usage.input_tokens)), output_tokens = SUM(TO_LONG(attributes.gen_ai.usage.output_tokens)) BY attributes.gen_ai.request.model, attributes.gen_ai.provider.name 最初に作るアラート 2 つ ES|QL が書けるということは、アラートも作れるということです。 Stack Management → Rules → Create rule で Elasticsearch query ルールを選び、クエリ言語に ES|QL を指定します。公式ドキュメントには 4 つの例がありますが、最初に必要なのは次の 2 つです。 会話ごとのトークン上限 1 つの会話の入出力トークン合計が上限を超えたら通知します。公式ドキュメントの例では 256,000 です。「Create an alert for each row」を選ぶと、会話ごとに 1 件のアラートになります。 FROM traces-agent_builder.otel-default | WHERE `span.name` LIKE "chat *" | STATS input_tokens = SUM(TO_LONG(attributes.gen_ai.usage.input_tokens)), output_tokens = SUM(TO_LONG(attributes.gen_ai.usage.output_tokens)) BY attributes.gen_ai.conversation.id | EVAL total_tokens = input_tokens + output_tokens | WHERE total_tokens > 256000 ツールの失敗 特定のツールの失敗が 5 回を超えたら通知します。シナリオ 3 のエラーは、この条件で拾えました。ただし、シナリオ 3 で書いたとおり、ツールの中で捕まえて通常の結果として返されたエラーは status.code に出ません。このアラートは一部のツール失敗を見逃す可能性があります。 FROM traces-agent_builder.otel-default | WHERE `span.name` LIKE "execute_tool *" AND status.code == "Error" | STATS failures = COUNT(*) BY `span.name` | WHERE failures > 5 作るときの注意点と、応用の例 公式の例を少し変えるだけで、運用に合わせた検知も作れます。たとえば、6-1 のクエリの BY を trace_id にして llm_calls = COUNT(*) を加えれば、「1 ラウンドで LLM 呼び出しが 15 回を超えた」という暴走の検知になります。また、今回の環境では attributes.user.hash （匿名化された利用者の識別子）がトレースに入っていたので、これで集計すれば「利用者ごとのトークン上限」も作れます。ただし、このフィールドは執筆時点の公式ドキュメントには載っていないため、使う前に GET traces-agent_builder.otel-default/_field_caps?fields=attributes.user.* で自分の環境を確認してください。 もう 1 つ、Elastic Workflows（決まった手順を自動で実行する機能）と組み合わせる使い方があります。Workflow から夜間に Agent を何十回も呼ぶような運用では、誰も画面を見ていません。トークンの使いすぎやツールの連続失敗をアラートで知らせる仕組みが必要になります。上の 2 つのアラートはそのまま使えます。Workflow ツールのスパン名や、Workflow から呼び出した Agent の記録単位は今回は検証していないので、次回の記事で確認します。 閾値は、ダッシュボードで 1 週間ほど傾向を見てから決めます。今回の検証では 19 分で約 58 万トークンでした。 プライバシー設定とアクセス権 Agent Builder のトレース収集は既定で有効です。ただし、 既定で保存するのは処理時間、モデル名、トークン数、ステータスといった構造的なメタデータ です。会話の内容を保存する Advanced privacy settings は、管理者が明示的にオンにしない限りオフです。 今回の環境では、Advanced privacy settings に 7 つの項目がありました。 設定 オンにすると保存されるもの 主なリスク Include user prompts in traces 利用者の質問 個人情報、顧客情報 Include LLM responses in traces Agent の回答 検索結果や機密情報の再保存 Include tool call details in traces ツールの引数と結果 クエリ、取得文書、外部 API の結果 Include system prompt in traces Agent のシステム指示 内部ルールやプロンプト設計の露出 Include real tool, agent, and conversation names in traces カスタム Agent・ツールの実名、会話タイトル 内部構成の特定 Include real conversation and workflow IDs in traces 実際の ID 会話や利用者との関連付け Include user data in traces 実際のユーザー ID とユーザー名 利用者の特定 執筆時点の公式ドキュメントとは 2 か所で違いがありました。5 番目の項目は、公式ドキュメントでは「Include real tool and agent names in traces」で、会話の名前については書かれていません。7 番目の「Include user data in traces」は、公式ドキュメント（6 項目）にはありません。画面の説明では、既定では実際のユーザー ID とユーザー名を省き、相関用の安定したハッシュ（user.hash）だけを残すとありました。どちらも Serverless の画面が先行している可能性があります。自分の環境の画面で確認してください。 匿名化の仕組みも押さえておきます。カスタムのツール、Agent、Workflow の名前は custom という文字に置き換わります。ID は 安定したハッシュ に置き換わるので、実名が分からなくても同じ会話のスパンをグループ化できます。Elastic 組み込みのツールと Agent は、常に実名で記録されます。 今回の検証では、7 項目すべてオフでした。この状態でも、処理時間、モデル、トークン数、ステータスは確認できました。一方、スパンの詳細では gen_ai.input.messages が []（空）になっています。これは不具合ではなく、設定が反映された結果です。 トレースと会話履歴は別の保存先 トレース側で利用者の入力を保存しなくても、Agent Builder の会話履歴には本文が残ります。個人情報を扱う場合は、トレースの設定だけでなく、会話の保持・共有・削除の方針も別に決める必要があります。 アクセス権は「インデックス単位」 Agent Builder のトレースは、 traces-agent_builder.otel-<Space ID>  というデータストリームに保存されます。通常の閲覧権限だけでは、「自分の会話のトレースだけを読む」ようには自動で分離されません。そのため、トレースを調査する担当者を決め、データへの権限をロールで管理できます。 Elastic Cloud Serverless では、Admin and settings → Custom roles → Create role を開きます。Index privileges の対象に  traces-agent_builder.otel-* 、権限に  read  と  view_index_metadata  を指定します。Discover やダッシュボードで調査する担当者には、Kibana 側で対象 Space の Discover: Read と Dashboard: Read も付けます。Agent Builder を利用させる必要がなければ、その機能の権限は None で構いません。 このロールを追加しても、担当者が別のロールから持っている広い権限は消えません。実際の閲覧範囲は、割り当て済みのロールを合わせて確認してください。また、トレースの生データにはプロジェクト名や ID などが含まれるため、社外に共有する際は確認とマスクが必要です。 参考資料 本記事は、以下の Elastic 公式ドキュメントと OpenTelemetry の仕様に基づいています。 Elastic 9.5: Columnar, VectorDB index mode & auto-calibration, and AI-driven alert triage（2026-08-04） https://www.elastic.co/blog/whats-new-elastic-9-5-0 Collect Elastic Agent Builder traces https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/collect-traces Elastic Agent Builder traces overview dashboard https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/agent-traces-dashboard Create alerts on Elastic Agent Builder trace data https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/create-alerts Monitor usage and costs for Elastic Agent Builder https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/monitor-usage Chat with Elastic Agent Builder agents（View Trace） https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/chat Permissions and access control in Elastic Agent Builder https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/permissions Elastic Agent Builder built-in skills reference（agent-builder-traces） https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/builtin-skills-reference Connect Elastic Agent Builder agents and Elastic Workflows https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/agents-and-workflows Elastic Agent Builder Kibana API（Converse API） https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/kibana-api Sample data https://www.elastic.co/docs/manage-data/ingest/sample-data OTel tracing for AI agents: token cost dashboards in Kibana（Elasticsearch Labs, 2026-07-28） https://www.elastic.co/search-labs/blog/opentelemetry-tracing-agent-builder OpenTelemetry Semantic Conventions for Generative AI https://github.com/open-telemetry/semantic-conventions-genai Elasticsearch OTel traces mapping（span.name alias、duration nanos） https://github.com/elastic/elasticsearch/blob/main/x-pack/plugin/otel-data/src/main/resources/component-templates/traces-otel@mappings.yaml Splunk Agent Observability（他社の Agent Observability の例として参照） https://www.splunk.com/en_us/products/agent-observability.html The post AI エージェントの「中で何が起きたか」を見える化する first appeared on Elastic Portal .

目次 1. はじめに 2. 動作環境 3. 以前のバージョンとの比較 4. シーケンス図（概略図） 5. 準備 6. MCPサーバーのURL の取得 6.1. Elasticsearch / Agent / Tool の画面の表示 6.2. すべてのツールを管理 6.3. MCPサーバーのURLをコピー 7. API Key の発行 7.1. APIキー作成画面の検索 7.2. APIキー作成画面への遷移 7.3. APIキーの作成 7.4. APIキーのコピー 8. LM Studio からの MCPサーバー への接続手順 8.1. Developer Mode 8.2. mcp.json の編集 9. LM Studio での Local LLM のロード 10. MCPサーバーとの接続 10.1. mcp/elastic-agent-builder との接続 10.2. 利用する tool の選択 11. 問い合わせの実行 11.1. 問い合わせの実行 11.2. 処理の継続 11.3. 回答の確認 12. 注意事項 13. 参考URL 1. はじめに 「Pythonコード不要？Elastic AI Agent と ES|QL で実現する超シンプルな次世代RAG」のブログ で Elastic AI Agent を使って、「柿之助」についての質問に答える RAG を作成しました。 その際、「柿之助」に関するコンテキストを取得する手段として ES|QL を用いた Elastic AI Agent Tool を作成・登録しました。 本記事では、この Tool を MCP (Model Context Protocol) サーバーとして公開し、LM Studio などの MCPクライアントから外部ツールとして呼び出せる環境を構築してみます。 ※一般的には MCPサーバーは多様な役割を担いますが、本稿では「柿之助のコンテキストを提供するデータソース」としてシンプルに活用しています。 Elastic AI Agent Tool （の集合）をMCP サーバーとして公開するメリット： Claude Desktop や LM Studio などの標準的な MCP クライアントから、自作の Elastic 検索ロジック（ES|QL）をコンテキスト提供ツールとしてシームレスに呼び出せるようになります。 2. 動作環境 Elastic Cloud Enterprise License (Elastic Integration Service (EIS) 用に必要) Docker 実行環境 (筆者はWindows用のRancher Desktop 1.24.0を利用) MCPクライアント : LM Studio 0.4.25 Local Chat LLM : google/gemma-4-e4b ※Elasticsearch 9.5.3 (Trial License) は、自動的にダウンロードされます。 ※今回、MCPクライアントには LM Studio を利用しました。MCPクライアントに Claude Desktop などを利用することも可能です。　→　参考URL: Claude DesktopにElastic Agent BuilderのMCPサーバーを追加する方法 3. 以前のバージョンとの比較 2025年1月に作成した RAG アプリケーションとの比較表です。 項目 2025年01月版 今回版(MCP利用版) ベースとなる Elasticsearch のバージョン v8.16.0 v9.5.3 index.mode standard vectordb_document Machine Learning Node 必須 不要 (代わりにEISを利用) クエリーの言語 Query DSL ES|QL 密ベクトル生成用のモデル .multilingual-e5-small_linux-x86_64 .jina-embeddings-v5-text-nano (EIS経由) セマンティックリランク用モデル なし .jina-reranker-v3.5 (EIS経由) MCPサーバー なし Elastic AI Agent Tool MCPクライアント なし LM Studio 質問回答用LLM Cohere Command R (2024年12月版) google/gemma-4-e4b UI Streamlit LM Studio 4. シーケンス図（概略図） 5. 準備 Pythonコード不要？Elastic AI Agent と ES|QL で実現する超シンプルな次世代RAG の準備作業の 1 ～ 5.4 までを行い、以下が完了している状態にします。 Elasticsearch / Kibana のセットアップ ES|QLを用いた AI Agent Tool (kakinosuke.get_contents) の登録 ※なお、Elastic 側の AI Agent の登録は今回は不要です。 6. MCPサーバーのURL の取得 ※ Kibana の Display language : 日本語 としています。 6.1. Elasticsearch / Agent / Tool の画面の表示 Kibana にログイン後、Home / Elasticsearch / エージェント / ツール の画面を表示します。 6.2. すべてのツールを管理 右上の すべてのツールを管理 をクリックします。 6.3. MCPサーバーのURLをコピー ツールライブラリ画面が表示されるので、右上の MCPを管理 から MCPサーバーのURLをコピー をクリックします。 MCPサーバーのURLがクリップボードにコピーされるので、メモ帳などに貼り付けて記録しておきます。 今回は Docker 上で、HTTP で動作させているため、下記のような URL になるはずです。 http://localhost:5601/api/agent_builder/mcp 7. API Key の発行 7.1. APIキー作成画面の検索 上部の検索窓に api と入力します。「セキュリティ / APIキー」が検索結果に表示されるのでクリックします。 7.2. APIキー作成画面への遷移 [(+) APIキーを作成] をクリックします。 既に他のAPIキーが存在する場合、表示される内容が異なりますが、その場合も [(+) APIキーを作成] をクリックしてください。 7.3. APIキーの作成 APIキー作成画面が表示されます。 名前に MCPサーバーへのアクセス用とわかる名前を入力し、右下の [APIキーを作成] をクリックします。 名前 : mcp_server_api_key (例) ※注 本番運用では、有効期限の設定や、セキュリティ権限の制御を行うことを推奨します。 7.4. APIキーのコピー APIキーが作成されると、APIキーの作成完了画面が表示されます。 エンコーディング済のAPIキーの値をコピーします。 コピーした APIキーは、メモ帳などに貼り付けて記録しておきます。 もしも、この値を忘れてしまったら、APIキーを再作成してください。 8. LM Studio からの MCPサーバー への接続手順 8.1. Developer Mode LM Studio を起動し、Developer Mode を選択します。 Developer Mode の画面から [mcp.json] をクリックします。 8.2. mcp.json の編集 mcp.json の編集画面になるので、下記を貼り付けます。貼り付けが終わったら、mcp.json を保存します。 ※既存の設定がある場合は、それらの設定を削除しないように貼り付けてください。 ※mcp-remote の次の行のURLには、6.3. でコピーしたMCPサーバーの URL を貼り付けます。 ※YOUR_API_KEY== のところには、7.4. でコピーした APIキーの値を貼り付けます。 { "mcpServers": { "elastic-agent-builder": { "command": "npx", "args": [ "-y", "mcp-remote", "http://localhost:5601/api/agent_builder/mcp", "--header", "Authorization:${AUTH_HEADER}" ], "env": { "AUTH_HEADER": "ApiKey YOUR_API_KEY==" } } } } 9. LM Studio での Local LLM のロード LM Studio で使いたい LLM を選択してロードします。ここでは、google/gemma-4-e4b を選択しています。 この状態では、まだ、Elastic AI Agent Tool の MCPサーバーとは接続できていません。 10. MCPサーバーとの接続 10.1. mcp/elastic-agent-builder との接続 LM Studio の画面の右側に Integrations メニューが表示されます。 そこから mcp/elastic-agent-builder の左のスイッチを ON にします。 MCPサーバー (Elastic AI Agent Tool) との接続が行われます（少し時間がかかります）。 10.2. 利用する tool の選択 MCPサーバー (Elastic AI Agent Tool) との接続に成功すると、tool の一覧が表示されます。 今回利用したい tool は、kakinosuke_get_contents のみなので、それ以外のチェックを外します。 ※ Elastic 側では、kakinosuke.get_contents として登録しましたが、LM Studio 側には kakinosuke_get_contents として表示されます。 なお、MCPサーバーへの接続に成功すると、LM Studio のチャット入力欄に elastic-agent-builder が追加されて表示されます。 11. 問い合わせの実行 11.1. 問い合わせの実行 LM Studio のチャット入力欄に次の内容を入力します。 あなたは柿之助についての質問に答えるエージェントです。 # 指示1 与えられた質問を query とし、次の tool を呼び出して、結果の 5 件のドキュメントを受け取りなさい。 受け取った5件のドキュメントを指示2に渡しなさい。 - tool : kakinosuke_get_contents # 指示2 指示1 で取得した 5 件のドキュメントを元に、与えられた質問 (query) に答えなさい。 # 質問 柿之助の3人の家来は誰? 11.2. 処理の継続 途中で、「処理を継続するか？」の確認を求められるので、処理の継続を選択します。 11.3. 回答の確認 回答が次のように返ってきます（下記は回答例です）。 ご提示いただいた資料に基づくと、柿之助の3人の家来は**猫**、**ゴリラ**、そして**鷹**です。 資料には「猫と、ゴリラと、鷹と、これで三にんまで、いい家来ができたので」といった記述や、「宝物をいっぱい積んだ車を、猫が先に立って引き出しました。鷹が綱を引いて、ゴリラがあとを押しました。」という描写から、この3体が一緒に行動していることが確認できます。 LM Studio から MCPサーバーとしての Elastic AI Agent Tool へ接続し、必要なコンテキストを取得して、Local LLM に回答させることに成功しました。 12. 注意事項 公開単位の仕様： Elasticsearch の MCPサーバーは、登録されている Elastic AI Agent Tool の「集合（ライブラリ全体）」を公開します。個別の Tool のみを個別に絞り込んで公開することはできません。 通信の暗号化 (HTTPS)： 本稿ではローカル検証のため、Kibana を HTTP で動作させていますが、本番運用時は必ず HTTPS (TLS) で保護してください。 スペースの分離： 今回は検証用に Kibana の Default スペースを使用しましたが、本番環境では公開専用のスペースを作成・整理して運用することを推奨します。 API Key の権限最小化： 今回発行した API Key は検証用に有効期限や権限を設定していません。本番環境では、必要最低限のロール設定および有効期限を設定してください。 13. 参考URL Pythonコード不要？Elastic AI Agent と ES|QL で実現する超シンプルな次世代RAG Claude DesktopにElastic Agent BuilderのMCPサーバーを追加する方法 GitHubリポジトリ The post 自作の Elastic AI Agent Tool をMCPサーバーとして公開してみる。 first appeared on Elastic Portal .

2026年9月16日、Elastic Cloud Serverless の Cross-Project Search（CPS：クロスプロジェクト検索） が正式提供（GA）になりました。 CPS を使うと、複数の Serverless プロジェクトをリンクできます。データを1か所に集約することなく、複数のプロジェクトを横断して検索できる機能です。 目次 Cross-Project Search の利点 設定はシンプル 仕組み：Origin Project と Linked Project GA で特に注目したいポイント Security では Central SOC の構成が可能に Origin Project は専用に作るのがおすすめ 日本で利用する場合 まとめ 参考資料 Cross-Project Search の利点 Elastic Cloud Serverless では、用途、組織、リージョンなどに応じて環境を複数の「プロジェクト」に分けます。たとえば、次のような構成です。 東京と海外リージョンでデータを分ける 顧客や部門ごとに Security プロジェクトを分離する 本番環境とステージング環境を分ける 環境を分ければ分離は保てます。しかし複数のプロジェクトをまとめて調査したいという場面では、それぞれのプロジェクトを個別に確認する必要がありました。CPS は、この課題を解決します。 設定はシンプル CPS は、Elastic Cloud の画面からプロジェクトをリンクして利用します。従来の Cross-Cluster Search（CCS）のように、接続先ごとの証明書やリモートクラスターを個別に設定する必要はありません。 Cloudのホーム画面 → OriginにしたいProjectの  Manage を選択します。 左サイドバーの Serverlessから Cross-project search をクリックし、Get started with cross-project search画面からLink projectsをクリックします。 リンクできる一覧が表示されますので選択したいプロジェクトのボックスにチェックを入れます。リンク後は、Discover、ES|QL、Dashboard、Alerting などから Linked Project のデータを検索できます。 仕組み：Origin Project と Linked Project CPS では、1つの Origin Project （起点となるプロジェクト ） から、複数の Linked Project を検索します。 リンクできるのは、同じ Elastic Cloud Organization 内の Serverless プロジェクトです。プロジェクト自体は、異なるリージョンやクラウドプロバイダーに配置されていても構いません。 この仕組みによって、データの配置や環境の分離を維持したまま、必要なときだけ横断して検索できます。 GA で特に注目したいポイント 今回の GA では、1つの Origin Project から標準で最大 100 の Linked Project を扱えるようになりました。 また、既存の Serverless プロジェクトを Origin Project として利用できます。機械学習と Agent Builder も Cross-Project Search に対応しました。 特に Agent Builder では、AI Agent が1つのプロジェクトだけを見るのではなく、複数の Serverless プロジェクトから必要なコンテキストを取得する構成が可能になります。たとえば、地域や部門ごとにログを別プロジェクトへ保存しながら、中央の AI Agent から横断的に調査する、といった使い方が考えられます。 Security では Central SOC の構成が可能に Security では、中央の Origin Project に Detection Rule を置き、複数の Linked Project にあるデータを対象として検知する構成が可能です。リージョンや組織ごとに Security プロジェクトを分離しながら、中央の SOC から横断的に監視・調査できます。 一方で、現時点ではすべての Security 機能が完全に横断化されるわけではありません。Linked Project 側の Detection Rule が独自に生成したアラートは、Origin Project の Alerts 画面には表示されません。Attack Discovery も、Origin Project で生成されたアラートを対象とします。 そのため Central SOC や MSSP のような構成では、どこでデータを保持するかだけでなく、どのプロジェクトで Detection Rule を実行し、アラートを生成するかまで含めた設計が重要になります。 Origin Project は専用に作るのがおすすめ GA では、既存の Serverless プロジェクトを Origin Project として利用できるようになりました。ただし Elastic の公式ドキュメントでは、多くの構成で 新しい空の Overview Project を作り、そこを Origin Project として利用する Hub-and-Spoke 型の構成 が推奨されています。 理由は、稼働中のプロジェクトを Origin にすると、そのプロジェクトですでに利用している Dashboard や Alerting Rule などが、Linked Project のデータまで対象にする可能性があるためです。特に Detection Rule では、意図していなかったデータまで評価されることで、誤検知が増える可能性があります。 複数プロジェクトを横断するための専用プロジェクトを用意する、と考えるとイメージしやすいでしょう。 日本で利用する場合 2026年9月時点で、Elastic Cloud Serverless では AWS の東京リージョン（ap-northeast-1）と GCP の東京リージョン（asia-northeast1）を利用できます。Microsoft Azure の Serverless については、現時点の提供リージョン一覧に日本リージョンは含まれていません。 また、Observability と Security のプロジェクトで Cross-Project Search を利用する場合は、 Complete tier が必要です。 まとめ Cross-Project Search のポイントは、「環境は分けたまま、必要なときだけ横断して検索できる」ことです。 リージョン、組織、顧客などの理由で Serverless プロジェクトを分離しながら、中央の SOC や Observability 環境、AI Agent から複数プロジェクトのデータを横断して利用できます。 Central SOC、複数リージョンの Observability 環境、分散したデータを参照する AI Agent を設計する際に、押さえておきたい Elastic Cloud Serverless の機能です。 参考資料 本記事では、Cross-Project Search の概要と、設計時に特に押さえておきたいポイントに絞って紹介しました。対応機能の詳細、設定手順、プロジェクトルーティング、アクセス制御、API、料金体系などについては、以下の Elastic 公式情報をご確認ください。 Elastic 公式ブログ「Elastic announces GA of cross-project search on Serverless」 GA で追加された機能や主なユースケース、料金の概要を確認できます。 https://www.elastic.co/blog/cross-project-search-elastic-serverless-ga Elastic 公式ドキュメント：Cross-Project Search の設定 Origin Project / Linked Project の構成、Security での制約、推奨アーキテクチャ、権限設定など、実際に利用する際の詳細を確認できます。 https://www.elastic.co/docs/deploy-manage/cross-project-search-config Elastic Cloud Serverless の提供リージョン AWS、Google Cloud、Microsoft Azure で利用可能な Serverless リージョンの最新情報を確認できます。 https://www.elastic.co/docs/deploy-manage/deploy/elastic-cloud/regions The post Elastic Cloud Serverless の Cross-Project Search がGAに first appeared on Elastic Portal .

目次 概要 主な変更点 できること 動作に必要な環境など シーケンス図（超概略図） 動かし方 1. 準備 1.1. GitHub リポジトリのダウンロード 1.2. .env ファイルに必要な情報を記載します。 2. ビルドおよびコンテナの起動 2.1. ビルド 2.2. コンテナの起動 3. EIS の設定 4. Elasticsearch へのデータ登録 4.1. 密ベクトル生成前のテキストデータの登録 4.2. インデックスの作成 4.3. マッピングの作成 4.4. _reindex 4.5. キーワード検索 4.6. セマンティック検索 4.7. ハイブリッド検索 4.8. セマンティックリランク 5. AI Agent 5.1. AI Agent の設定 5.2. AI Agent 用の Tool の追加 5.3. AI Agent 用の Tool の登録 Type Details Labels 5.4. 保存した AI Agent Tool のテスト 5.5. AI Agent の作成 5.6. AI Agent の登録 Settings タブ Tools タブ 5.7. AI Agent の実行準備 5.8. AI Agent の実行 6. Elastic Agent Tool の呼び出し回数などの集計 発展形 まとめ 無償トレーニングコースの紹介 参考URL 概要 2025年1月に公開した White Paper 用のプロジェクト（ 簡易RAGアプリケーション ）を、Elastic AI Agent 用にリニューアルしてみました。 結論から書くと、かなり簡単に実現できるようになっています。 主な変更点 項目 2025-01版 2026-09版 ベースとなる Elasticsearch のバージョン v8.16.0 v9.5.3 index.mode standard vectordb_document Machine Learning Node 必須 不要 (代わりにEISを利用) クエリーの言語 Query DSL ES|QL 密ベクトル生成用のモデル .multilingual-e5-small_linux-x86_64 .jina-embeddings-v5-text-nano セマンティックリランク用モデル なし .jina-reranker-v3.5 質問回答用LLM Cohere Command R (2024年12月版) Anthropic Claude 5 Sonnet (例) UI Streamlit Elastic AI Agent できること Elastic AI Agent を使って、サンプルデータ「柿之助」についての質問に答えてもらうことができます。 ※「柿之助」は、青空文庫からダウンロードした「桃太郎」を元に、改変したお話です（LLMが事前学習していないお話にするため）。 動作に必要な環境など Elastic Cloud Enterprise License （EIS 用に必要） Docker 実行環境 （筆者はWindows用のRancher Desktop 1.24.0を利用） 動作に必要な Dockerfile などは、下記に置いています。 ※Elasticsearch 9.5.3、Kibana 9.5.3 は、自動的にダウンロードされます。 https://github.com/SIOS-Technology-Inc/elastic-blogs/tree/main/2026-09-rag-by-ai-agent/README.md シーケンス図（超概略図） 動かし方 1. 準備 1.1. GitHub リポジトリのダウンロード 下記の URL から GitHub リポジトリをダウンロードします。 https://github.com/SIOS-Technology-Inc/elastic-blogs/ （方法はいくつかありますが、ここでは zip をダウンロードする手順を紹介します。） 1. Web ブラウザで、 https://github.com/SIOS-Technology-Inc/elastic-blogs/ にアクセスします。 2. [<>Code] から Download ZIP をクリックします。 3. ZIP ファイルを解凍し、2026-09-rag-by-ai-agent フォルダへ移動します。 1.2. .env ファイルに必要な情報を記載します。 env.sample.txt ファイルを .env にコピーします。 cp env.sample.txt .env .env ファイルを編集します。 ... ES_LOCAL_PASSWORD=... KIBANA_PASSWORD=... ... SAVEDOBJECTS_ENCRYPTIONKEY=... ... 2. ビルドおよびコンテナの起動 2.1. ビルド docker-compose.yml があるディレクトリで下記を実行します。 docker compose build Elasticsearch 9.5.3 および Kibana 9.5.3 のダウンロードが行われ、ビルドが行われます。 2.2. コンテナの起動 docker compose up -d Self-Managed の Elasticsearch および Kibana が起動します。 3. EIS の設定 下記のブログを参考にして Stack Management / Cloud Connect の設定を行います。 Elastic Inference Service (EIS) を使った「ベクトル検索」および「生成AIによる回答（RAG）」（準備編） ※Self-Managed の Elasticsearch 上で、EIS を経由して、密ベクトル生成用モデル、セマンティックリランク用モデル、問い合わせへの回答用モデルを利用できるようになります。 ※別途、利用料金がかかります。 4. Elasticsearch へのデータ登録 4.1. 密ベクトル生成前のテキストデータの登録 Kibana の Integration / Upload File 機能を使って下記の ndjson ファイルを kakinosuke_tmp インデックスへ登録します（DataView は不要です）。   https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-09-rag-by-ai-agent/data/kakinosuke_chunked.ndjson 4.2. インデックスの作成 下記の md ファイル内のリクエストを Kibana の Dev Tools から発行し、kakinosuke_202609 インデックスを作成します。 https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-09-rag-by-ai-agent/es_scripts/01_create_index.md 4.3. マッピングの作成 下記の md ファイル内のリクエストを Dev Tools から発行し、kakinosuke_202609 インデックスへ mapping を登録します。 https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-09-rag-by-ai-agent/es_scripts/02_put_mapping.md 4.4. _reindex 下記の md ファイル内のリクエストを Dev Tools から発行し、kakinosuke_tmp インデックス内のドキュメントを kakinosuke_202609 インデックスへコピーします。 https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-09-rag-by-ai-agent/es_scripts/03_reindex.md このとき、kakinosuke_202609 インデックスには密ベクトルデータや日本語形態素解析されたデータも生成されます。 4.5. キーワード検索 下記の md ファイル内のリクエストを Dev Tools から発行し、kakinosuke_202609 インデックスに対しキーワード検索を行います。 https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-09-rag-by-ai-agent/es_scripts/04_keyword_search.md （これは必須の操作ではありません。確認のための作業です。） 4.6. セマンティック検索 下記の md ファイル内のリクエストを Dev Tools から発行し、kakinosuke_202609 インデックスに対しセマンティック検索を行います。 https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-09-rag-by-ai-agent/es_scripts/05_semantic_search.md （これは必須の操作ではありません。確認のための作業です。） 4.7. ハイブリッド検索 下記の md ファイル内のリクエストを Dev Tools から発行し、kakinosuke_202609 インデックスに対しキーワード検索をとセマンティック検索のハイブリッド検索(RRF)を行います。 https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-09-rag-by-ai-agent/es_scripts/06_hybrid_search.md （これは必須の操作ではありません。確認のための作業です。） 4.8. セマンティックリランク 下記の md ファイル内のリクエストを Dev Tools から発行し、kakinosuke_202609 インデックスのハイブリッド検索後の検索結果に対しセマンティックリランクを行います。 https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-09-rag-by-ai-agent/es_scripts/07_semantic_rerank.md （これは必須の操作ではありません。確認のための作業です。） 5. AI Agent ※以降の画面は、Dispay Language : English で表示したものを添付しています。日本語で表示した場合には、画面イメージが多少異なります。 5.1. AI Agent の設定 Kibana の Elasticsearch / Agents から Elastic AI Agent 画面へ遷移します。 5.2. AI Agent 用の Tool の追加 さきほど作成したセマンティックリランク用のクエリーを AI Agent 用の Tool として追加します。 Elastic AI Agent の下の Tools をクリックします。Tools の画面が表示されるので、右上の [(+) Add tool] をクリックします。 さらに Create a tool をクリックします。 5.3. AI Agent 用の Tool の登録 参考:  https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-09-rag-by-ai-agent/es_scripts/08_ai_agent_tool.md Create new tool 画面が表示されるので、下記のように入力します。入力完了後、右下の [Save & test] をクリックします。 Type Type : ES|QL ES|QL Query : 以下のクエリーを入力 （4.8. のセマンティックリランク用 ES|QL をAI Agent Tool用に修正した内容です。） FROM kakinosuke_202609* METADATA _score, _id, _index | FORK (WHERE MATCH(content.semantic, ?query) | SORT _score DESC | LIMIT 10) (WHERE MATCH(content, ?query) | SORT _score DESC | LIMIT 10) | FUSE RRF | KEEP chunk_no, content, _score | SORT _score DESC | LIMIT 10 | RERANK ?query ON content WITH { "inference_id" : ".jina-reranker-v3.5" } | SORT _score DESC | LIMIT 5 ES|QL Parameters Infer parameter をクリックしてから、下記を入力します。 Name : query （自動表示されます） Description : 検索したい内容 Type : string （自動表示されます） Optional : false Details Tool ID : kakinosuke.get_contents Description : 下記を入力 kakinosuke_202609 インデックスに対して、キーワード検索とセマンティック検索を行い、RRFで結果を統合したあと、セマンティックリランクで質問に近い順に並べ直し、上位5件の本文チャンクを返す。 Labels Labels : kakinosuke 5.4. 保存した AI Agent Tool のテスト [Save & test] をクリックすると、Tool のテスト実行画面が表示されます。 query に、下記を入力した後、[→ Submit] をクリックします。 柿之助の3人の家来は? Response に5件の結果が表示されることを確認します。 5.5. AI Agent の作成 左上の Elastic AI Agent の [v] メニューをクリックします。さらに Available agents 一覧の [+ New agent] をクリックします。 5.6. AI Agent の登録 参考:  https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-09-rag-by-ai-agent/es_scripts/09_ai_agent.md New Agent 画面が表示されるので、以下の内容を登録していきます。 Settings タブ Agent ID : kakinosuke.agent Custom Instructions : 以下を入力します。 あなたは柿之助についての質問に答えるエージェントです。 # 指示1 与えられた質問を query とし、次の tool を呼び出して、結果の 5 件のドキュメントを受け取りなさい。 受け取った5件のドキュメントを指示2に渡しなさい。 - tool : kakinosuke.get_contents # 指示2 指示1 で取得した 5 件のドキュメントを元に、与えられた質問 (query) に答えなさい。 Enable Elastic capabilities : false Labels : kakinosuke Access control : Public Display name : Kakinosuke Agent Display description : 柿之助に関する質問に答える AI Agent です。 Workflows : なし Tools タブ 以下の手順で、kakinosuke.get_contents tool のみを利用するよう、設定します。 Tool list の右上の Show active only を on にします。 2. チェックがついている tool を全て off にします。 3. 再度、Show active only を off にしてから、検索欄に “kakinosuke” と入力します。 4. kakinosuke.get_contents が表示されるので、チェックを入れて、[Save] をクリックします。 5.7. AI Agent の実行準備 Stack Management / Model Management の Feature Settings をクリックします。 Feature settings 画面が表示されるので、Global model から利用したいモデルを選択します。 （モデルの利用料金が別途かかります。） 今回は、Feature specific models を Disabled に設定しておきます（全ての AI 機能で Global model が利用されます）。 モデルを選択後、右上の [Save settings] をクリックします。 （下記は、Anthropic Claude Sonnet 5 を選択した例です。） 5.8. AI Agent の実行 Home / Elasticsearch / Agents 画面を開きます。 Elastic AI Agent の右の [v] をクリックします。Available agents の中から Kakinosuke Agent を選択します。 画面中央のプロンプトに次のように入力し、[↑] をクリックします。 柿之助の3人の家来は? しばらく待つと以下のような回答が画面に表示されます。 回答の下の左から3番目のアイコンをクリックすると、LLM のトレースを表示することができます。 この回答の根拠 (reasoning) についても確認することができます。 回答内の 1 tool responded > で閉じられている部分を展開すると、以下のような内容が表示されます。 Found 5 results のリンクをクリックすると、根拠になった 5 件の結果も表示されます。 6. Elastic Agent Tool の呼び出し回数などの集計 Elastic Agent Tool の呼び出し回数、エラー回数、平均処理時間は、以下のクエリーで取得することが可能です。 FROM traces-agent_builder.otel-* | WHERE span.name LIKE "execute_tool *" | STATS calls = COUNT(*), errors = COUNT(*) WHERE status.code == "Error", avg_ms = ROUND(AVG(duration) / 1000000.0, 1) BY tool = attributes.gen_ai.tool.name | SORT calls DESC 発展形 今回は非常に小さいデータの検索でしたが、巨大なデータを検索する場合にはさらなる発展形として、以下のようなことも考えられます。 ツールの数を増やす（いろんな条件ごとに検索対象や検索ロジックを変える）。 検索時の重み付けを複数パターンにする（今回のサンプルでは、単純なキーワード検索とベクトル検索のRRFでのシンプルな重み付けのみ）。 条件に応じて複数ツールを呼び分けるよう Elastic AI Agent で制御する。 Elastic AI Agent の処理の前半で呼ぶツールと処理の後半で呼ぶツールとを分ける。 まとめ v8 のときの Python を使った場合よりも、v9 の Elastic AI Agent を使った方がかなり簡単に RAG を実現できるようになっています。 また、LLM の呼び出し時のトレースや、Reasoning の確認も簡単にできるようになっています。 Elastic AI Agent は、RAG 以外にも利用可能です（Observability や Security での異常発見後の処理など）。 さらに、Elastic Workflows と組み合わせて利用することも可能です。 その他、今回作成した Elastic AI Agent Tool を MCP Client から呼び出すことも可能です。 参考URL: Claude DesktopにElastic Agent BuilderのMCPサーバーを追加する方法 まずは、一度、Elastic AI Agent を動かしてみて、その凄さを体験していただければ、と思います。 無償トレーニングコースの紹介 2026年9月時点では、Elastic Cloud 上で受講できる AI Agent 関連の無償トレーニングコースとして以下のコースが用意されています。 Platform / Custom agents with Elastic Agent Builder for conversational search ※受講するには、Elastic Cloud へのユーザー登録（無料ユーザーで可）が必要です。 ※内容は英語で書かれています。 参考URL 2025年1月公開の簡易RAGアプリケーション GitHubリポジトリ Elastic Inference Service (EIS) を使った「ベクトル検索」および「生成AIによる回答（RAG）」（準備編） Claude DesktopにElastic Agent BuilderのMCPサーバーを追加する方法 Elastic の無償トレーニングコースの紹介(2026年9月時点) The post Pythonコード不要？Elastic AI Agent と ES|QL で実現する超シンプルな次世代RAG first appeared on Elastic Portal .

Elastic Cloud 上では、Elastic 関連の無償オンライントレーニングを受講することができます。不定期で新しいコースが追加されており、最新機能を実機環境で直接試すことも可能です。 目次 受講に必要なもの 無償トレーニングの入り口 elastic.co/training/ 受講可能なコース一覧（2026年9月時点） 受講手順 Elastic Cloud 内の Learning portal 受講手順 受講可能なコース一覧（2026年9月時点） Tips （日本語翻訳の小ワザ） おわりに 受講に必要なもの Web ブラウザ Elastic Cloud のアカウント（無償アカウントで受講可能。未登録の方はリンク先より Sign up ） 無償トレーニングの入り口 無償トレーニングコースは、2か所にあります。 elastic.co/training/ Elastic Cloud 内の Learning portal elastic.co/training/ 1つ目は、 https://www.elastic.co/training/ です。 こちらにアクセスすると、カテゴリー（Platform / Security / Search / Observability）ごとにトレーニングコースが表示されます。 受講可能なコース一覧（2026年9月時点） 下記をクリックすると、各カテゴリー内のコース一覧が表示されます。 Platform Data types and mappings Distributed datastore ECK essentials ECK Operator: Configuration and features Feature Highlight: Elastic Cloud Serverless Index basics Security Actions and escalate Advanced investigations with Timelines AI Assistant for Security Alerts and cases Attack Discovery Detection engine advanced Detection engine basics Elastic AI SOC Engine: EASE into Elastic Security ES|QL for security analysts Explorer: Hosts, Network, and Users in Elastic Security Focus and investigate Intro to Elastic Security Machine learning for anomaly detection Security alert triage Visualizing data with Elastic for security analysts Search Elastic Agent Builder: Tools, agents, and MCP GenAI Associate Accreditation Intro to MCP with Elasticsearch MCP Server RAG foundation Semantic search foundation Semantic search text embedding Observability APM with Elastic Elastic Agent ES|QL for observability Log analysis with Elastic machine learning Log essentials: Getting started Monitoring Kubernetes with Elastic Agent Monitoring Kubernetes with Elastic distributions of OpenTelemetry Synthetic monitoring with Elastic 受講手順 受講したいコースを選んで、示される手順に沿って操作してください（先へ進むと Elastic Cloud へのログインを求められるので、ログインしてください）。 Elastic Cloud 内の Learning portal もう一つのコースは、Elastic Cloud にログイン後に表示されるトレーニングコースです。 受講手順 Elastic Cloud よりログインします。 Home 画面下部の Training 内にある [Learning portal] をクリックします。 Elastic Learning Portal 画面が表示されたら、Explore On-Demand Modules の [VIEW CATALOGS] をクリックします。 カテゴリー（Platform / Security / Search / Observability）ごとに表示されるコース一覧から受講したいコースを選択します。 受講可能なコース一覧（2026年9月時点） 下記をクリックすると、各カテゴリー内のコース一覧が表示されます。 Platform Changing Data Custom agents with Elastic Agent Builder for conversational search Data Management Concepts Data Streams Data types and mappings Distributed datastore Distributed Operations ECK essentials ECK Operator Configuration and features Elastic Ecosystem and Technical Essentials Enriching Data Feature highlight: Elastic Cloud Serverless Getting started: Elastic Workflows Index basics Index Lifecycle Management Multi Cluster Operations Scaling Elasticsearch Searchable Snapshots Troubleshooting Understanding Shards Security Advanced ES | QL Operations for Security Analysts Advanced investigations with Timelines Aggregation Based Visualizations AI Assistant for Security Alerts and cases Attack Discovery Automating security operations with Elastic Workflows Detection engine advanced Discover Getting started with Kibana Elastic Defend Configuration ES QL for security analysts Event Query Language for Security Data Exploration Feature highlight: Elastic Common Schema for Security Analysts Feature highlight: Elastic Stack Overview Focus and investigate Getting Started: Elastic Security Machine Learning for anomaly detection Searching with Kibana Query Language and Lucene Security alert triage SIEM Capstones Visualizing data with Elastic for security analysts Search Combining Aggregations Combining Queries Full Text Queries GenAI Associate Accreditation Exam Metric and Bucket Aggregations Overview of Mappings Semantic search text embedding Strings in Elasticsearch Term Level Queries Types and Parameters Observability Adjust Visualizations APM with Elastic Collect Application Data Create Maps Create Visualizations Data Frame Analytics Discover and Data Visualizer Elastic Agent Extracting and Transforming Events Hello Dashboard Index Lifecycle Management for Observability Data Interactive Dashboards Introduction to Kibana KQL and Filters Log analysis with Elastic machine learning Logs Rules and Connectors Runtime Fields Sharing a Dashboard Spaces Tables （Platform と他のカテゴリーで同じコースが重複している分は、Platformのコースとして記載しています。） （また、一部のコースは、elastic.co/training/ 内のコースと重複しています。） 下記のコースは、比較的最近追加されたコースです（いずれも新機能に関するコース）。 Platform Custom agents with Elastic Agent Builder for conversational search Getting started: Elastic Workflows Tips （日本語翻訳の小ワザ） 本トレーニングは英語表記となっており、そのままではブラウザの自動翻訳が機能しない場合があります。日本語でスムーズに受講したい方は、こちらの Qiita の翻訳ノウハウ記事 に記載されている手法をご活用ください。 おわりに 「新機能をいち早く触ってみたい」「概念だけでなく実際の操作感を確かめたい」という方に最適なプログラムです。トレーニング進行中に不明点や理解しづらい点があれば、弊社の Elastic お問合せページ よりお気軽にご相談ください。 The post Elastic の無償トレーニングコースの紹介(2026年9月時点) first appeared on Elastic Portal .

2026年10月1日、サイバー対処能力強化法（いわゆる能動的サイバー防御法）の主要部分が施行されます。 届出と報告の義務がかかるのは、国に指定された基幹インフラ事業者（2026年7月1日時点で15分野258者）のうち、一定の重要システムを使う事業者だけです。 ただ、この記事を読んでいただきたいのは、その事業者だけではありません。 たとえば、こういう立場の方です。 基幹インフラ事業者に、システムやサービスを納めている 自社は指定されていないが、同じ業種で、規模だけが基準に届いていない 今回は対象外だが、次の改正で対象になりそうだ（医療分野は、すでに追加が決まりました） グループ会社に、指定された事業者がある 少しでも心当たりがあれば、ここから先はぜひ「自社の課題」としてお読みください。届出や報告の義務は課されません。しかし、説明を求められる側にはなる可能性があります。 ここで扱うのは、難しい条文の解説ではありません。実務において最も重要となる一点に絞ってお伝えします。それは、「いざ報告を求められたときに、提出できるログが手元に残っているかどうか」ということです。 目次 10月1日に何が変わるのか 対象外の会社にも、話は届きます いま、日本で実際に起きていること なぜ、攻撃側だけが有利なのか 「見えていない」理由は、能力ではなく構造です では、どう変えられるか 1. コスト:「絞る」必要をなくす 2. 見えない範囲:「全部残して、全部検索する」 3. 速度:「アラート」ではなく「調査結果」を受け取る 日本では、ここが最初の条件になります 「Elasticって、本当にセキュリティの会社なの？」と疑問に思われる方へ RFI・RFPに書くべき5項目 いまお使いのSIEMを、止める必要はありません まとめ 出典 10月1日に何が変わるのか 変わるのは「守り方」ではなく「説明責任」です。対象事業者にかかる主な義務は2つ。重要な機器の届出と、サイバー攻撃を受けたときの報告です。 報告で注目したいのは、対象が被害発生時だけではないことです。その原因となり得る事象を知ったときも、報告の対象になります。異常な認証、見慣れない通信、消えたログ。気づける状態になっていなければ、報告のしようがありません。 そして報告では、「どのシステムが影響を受けたのか」「どんな攻撃だったのか」「業務にどう影響したのか」を説明します。 これを説明する土台が、ログです 。 侵入経路も、活動が始まった時期も、横移動の有無も、後から確かめるにはログが要ります。残っていなければ、「わかりません」と書くことになります。 対象外の会社にも、話は届きます これは推測ではありません。政府の基本方針にそう書かれています。 本法に基づく措置は、特別社会基盤事業者はもとより、電子計算機の使用者に対する周知など中小企業も含めて広く様々な事業者が対象となり得るため、必要な周知・広報を行う。 （内閣府「サイバー対処能力強化法に基づく基本方針の概要」令和7年12月） 届け方は、大きく2つです。 1. 供給する側は、すでに制度の中にいます サイバーセキュリティ基本法 第7条第2項は、情報システムの供給者に対して、利用者の安全性に配慮した設計・開発と、維持管理に必要な情報の継続的な提供を求めています（努力義務）。経済産業省と内閣官房国家サイバー統括室は2026年3月31日に、こうした事業者を「サイバーインフラ事業者」と位置づけたガイドラインも策定しました。 さらに、経済安全保障推進法の枠組みでは、基幹インフラ事業者が重要設備を導入・委託する際の「導入等計画書」に、供給者だけでなく委託の相手方や再委託の相手方についても同等の事項を記載します。会社名だけでなく、代表者や役員の情報まで含まれます。 二次請けで入っているだけでも、すでに書類の中にいる可能性があるということです。 2. 報告のとき、ログを聞かれます 侵入経路が自社の提供したシステムだった場合、そこで何が起きたかを確認できるのは、ベンダー側だけということがあります。 「この時間帯の認証ログを見せてください」「この通信は正常ですか」、そうした確認を求められる可能性があります。そのときログが残っていなければ、「わかりません」と答えることになります。 ※ 制度の細部（対象事業者の範囲、届出内容、期限など）は、内閣官房・NISCおよび内閣府の公表資料で最新の内容をご確認ください。 いま、日本で実際に起きていること 現場の数字を見ておきます。すべて警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（令和8年3月公表）からの引用です。 ランサムウェア被害報告は226件。 高止まりが続いています。 被害企業の約6割は中小企業です。 「うちは狙われるほど大きくない」は成り立ちません。業種別では製造業が約4割。 感染経路について回答が得られた組織では、VPN機器からの侵入が6割を超えました。 メールの添付ファイルではありません。インターネットに露出した機器の未修正の脆弱性や、漏えいした認証情報から入られています。 復旧に総額1,000万円以上かかった組織が5割を超えています。 1か月未満で復旧できたのは5割強。約半数が1か月以上、影響を受け続けています。 なぜ、攻撃側だけが有利なのか 警察庁の報告書は、RaaS（Ransomware as a Service） を被害拡大の背景として明記しています。 RaaSは、一言でいうと**攻撃の「フランチャイズ」**です。開発・運営グループが実行役に道具一式を渡し、身代金の一部を受け取ります。 高度な技術的専門知識を有していない者であっても、ランサムウェア攻撃の実行が可能になるなど、攻撃者の裾野の広がりが見られている（警察庁） 狙っているのは、天才ハッカーとは限りません。道具を借りてきた加盟店かもしれない、ということです。 ここに非対称があります。攻撃側は道具代を一度払えば、何度でも試せます。一件成功すれば元が取れます。守る側は毎年払い続けても、「終わり」が来ません。 速度も違います。CrowdStrikeの2026年版Global Threat Reportによると、金銭目的の攻撃の平均ブレイクアウトタイムは29分（侵入から横移動を始めるまでの時間）。最短27秒という記録も報告されています。 侵入されてから隣のシステムへ移られるまで、30分ありません。この時計の差が、そのまま被害の大きさになります。 「見えていない」理由は、能力ではなく構造です ログが見えていないと聞くと、担当者のスキル不足を思い浮かべるかもしれません。でも実務では、原因はたいていそこではありません。 単年度予算がライセンス数を決める — 入れられなかった端末が、そのまま入口になる 取り込み量への課金 — 予算に収めるには、取り込むログを減らすしかない 保持期間が短い — ログが消えたあとに侵入が発覚すれば、見たい期間はもう手元にない 製品がつぎはぎ — 攻撃者は壁を破らず、製品と製品の 継ぎ目 を通る 「ログを取っていないのではありません。取れない値付けになっているだけです。」 取り込んでいないログは、検知もできないし、報告もできません。 では、どう変えられるか 1. コスト:「絞る」必要をなくす Elastic Cloud Hosted とセルフマネージドの構成では、使うリソース（ノードのメモリ量と稼働時間など）に対して課金されます。取り込んだデータ量そのものには課金されません。「取り込む量を増やすと、その分ライセンス費が上がる」という関係になりません。予算を理由にログソースを外す判断を、しにくくなります。 ※ Elastic Cloud Serverless の Security は取り込み量ベースの課金です（Essentials $0.09/GB〜、Complete $0.11/GB〜）。リソース課金なのは Hosted とセルフマネージドの構成です。 2. 見えない範囲:「全部残して、全部検索する」 Elasticの中核は検索エンジンです。古いデータを安いストレージ階層に置いたまま、復元作業なしでそのまま検索できます。「バックアップから戻すのに3日」がなくなります。 調査は必ず過去にさかのぼります。10月1日以降は、説明のためにもさかのぼります。 規模の目安として、米国カリフォルニア州雇用開発局（EDD）の事例があります。約14,000エンドポイント、月80,000件超のアラート、守っているレコードは 8,500億件 です。 3. 速度:「アラート」ではなく「調査結果」を受け取る Attack Discovery は、バラバラのアラートを1つの攻撃のストーリーにまとめる機能です。従来アナリストが手作業でつなげていた部分を、AIが先にやります。 「AIの判断を信じていいのか」という疑問は正しいです。Attack Discoveryでは、まとめの元になった関連アラートや元データをたどれます。アナリストが確認してから判断します。 大事なのは、AIが答えを出すことではありません。調査を始める場所を、早く見つけられることです。 日本では、ここが最初の条件になります 日本で必ず出る質問があります。「そのデータはどこに置かれますか」です。 Elasticは、クラウドだけでなく、セルフマネージドやオンプレミス、閉域環境でも動きます。AIの部分も選べます。Elastic Managed LLM のほか、 外部のLLMや、自社で管理するLLMを接続できます 。AIを使うために、必ずデータを外部のLLMサービスへ送らなければならない設計ではありません。 政府調達のISMAP、金融のFISC安全対策基準、医療の3省2ガイドライン。日本の要件はどれも「データの置き場所」と「説明できること」を問います。この2つは、機能の1つではなく 入口の条件 です。 ※ ISMAPへの登録有無は、ISMAPポータルの最新のクラウドサービスリストでご確認ください。ここでは要件の説明にとどめています。 「Elasticって、本当にセキュリティの会社なの？」と疑問に思われる方へ Elasticは検索エンジンの会社として知られています。この疑問は自然です。そこでElastic自身の主張ではなく、 第三者が公表した評価 を並べます。 評価レポート 公表 位置づけ Gartner® Magic Quadrant™ for SIEM 2025年10月 Visionary The Forrester Wave™: Security Analytics Platforms, Q2 2025 2025年6月 Leader （2回目）。14項目で最高点、Federated Searchでも最高スコア The Forrester Wave™: XDR Platforms, Q2 2026 2026年6月 Strong Performer IDC MarketScape: Worldwide SIEM 2026 （doc #US54126826） 2026年6月 Leader IDC MarketScape: Worldwide XDR Software 2025 （doc #US52997325） 2025年9月 Leader AV-Comparatives Business Security Test （2026年3〜6月期） 2026年7月 Malware Protection 100%（16製品中で唯一） 。Real-Worldも399/400（99.8%）で最高スコアに並ぶ 正確に書いておきたい点が2つあります。 Forrester XDRは Strong Performer です。 すべての評価で1位、ではありません。 AV-Comparativesの誤検知について。 一般的な業務ソフトを対象としたFalse Alarm Testは0件でしたが、Real-World Protection Testでは12件の誤検知が記録されています。「テスト全体で誤検知ゼロ」ではありません。 そしてもう1つ。 Elasticの検知ルールとエンドポイント保護は、GitHubで公開されています （elastic/detection-rules、elastic/protections-artifacts）。買う前に「どこまで検知できるのか」を自分の目で監査できます。閉じた製品では、これができません。 RFI・RFPに書くべき5項目 RFI（情報提供依頼書）とRFP（提案依頼書）は、製品を選ぶときにベンダーへ出す文書です。大事なのは、RFPに書いていない条件には、ベンダーは答えないということ。書けば全社が必ず答え、できる会社とできない会社がその場で分かれます。 以下は「Elasticの機能一覧」ではありません。どのベンダーを選ぶにしても、要件定義書に書いておくべき5項目です。 全量の取り込み — すべてのログソースを対象にできる。予算の都合で外す必要がない 全履歴の検索 — 数年分を1つのクエリで検索できる。復元作業を必要としない 開かれた文脈 — 他社製品のアラートやテレメトリーも含めてAIが推論できる 監査できるAI — 結論の元データをたどれる。アナリストにも監査部門にも説明できる 設置場所を選べる — クラウド、オンプレミス、閉域環境 第2項は、10月1日以降の説明責任に直結します。 第5項は、閉域要件があるだけで候補が数社に絞られます。 いまお使いのSIEMを、止める必要はありません 「既存のSIEMにすでに投資していて、簡単には変えられない」、ほとんどの組織で当てはまります。 EASE（Elastic AI SOC Engine） は、既存のSIEMやEDRの上で動くサーバーレスのパッケージです。撤去は不要で、既存環境からアラートを取り込み、Attack DiscoveryとAIアシスタントを使えます。大きな稟議を通す前に、自社のアラートで結果を確かめられます。 将来の移行には Automatic Migration があります。例えば、SplunkのSPLで書かれた検知ルールをES|QLに翻訳し、Elastic提供の1,300以上の検知ルールに対応付けます。ただし「部分的に翻訳」「翻訳できず」という状態もあり、手を入れてからでないと導入できないルールもあります。全部が自動で移るわけではありませんが、ゼロから書き直す手間はかなり減ります。 まとめ 1. 問われるのは、守れているかではなく、説明できるかです。 取り込んでいないログは、検知も説明もできません。 2. ログが見えていない理由は、能力ではなく構造です。 取り込み量への課金が、そのまま可視性の穴になっています。 3. 判断材料は、他社の事例より自社のアラートです。 既存のSIEMを止めずに検証できます。 10月1日、義務が始まるのは、ごく限られた事業者です。貴社ではないかもしれません。 ただ、その事業者が報告書を書くとき、材料を求められるのは外側の会社です。政府の基本方針も「広く様々な事業者が対象となり得る」と書いています。 義務がない側には、まだ準備する時間があります。 出典 統計・法制度 記載 出典 ランサムウェア226件、中小企業約6割、製造業約4割、VPN機器6割以上、復旧費1,000万円以上が5割超、1か月未満の復旧5割強、RaaS 警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（令和8年3月） https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf ブレイクアウトタイム29分、最短27秒 CrowdStrike「2026 Global Threat Report」 https://www.crowdstrike.com/en-us/global-threat-report/ 届出・報告義務、「広く様々な事業者が対象となり得る」の引用 内閣府「サイバー対処能力強化法に基づく基本方針の概要」令和7年12月 https://www.cao.go.jp/cybersecurity/pdf/kihonhoushin_gaiyou.pdf 15分野258者（2026年7月1日時点）、導入等計画書に委託・再委託の相手方も記載 内閣府「経済安全保障推進法における特定社会基盤役務の安定的な提供の確保に関する制度（説明会資料）」2026年7月7日 https://www.cao.go.jp/keizai_anzen_hosho/suishinhou/infra/doc/infra_setsumeikai.pdf 医療分野の追加 厚生労働省「基幹インフラ制度への医療分野の追加について」 https://www.mhlw.go.jp/content/10808000/001703605.pdf 供給者の努力義務、「サイバーインフラ事業者」ガイドライン（2026年3月31日） 経済産業省・内閣官房国家サイバー統括室 https://www.meti.go.jp/press/2025/03/20260331001/20260331001.html Elasticの製品・事例 記載 出典 8,500億件、約14,000エンドポイント、月80,000件超のアラート EDD導入事例 Attack Discoveryの元データ確認とアナリストによる検証 Elastic Docs: Attack discovery 外部LLM・自己管理LLMの接続 Elastic Docs: LLM connectors 1,300以上の検知ルール、部分翻訳・未翻訳の状態 Automatic Migration ／ Elastic Docs EASEが既存SIEM／EDRの上で動く Elastic AI SOC Engine 発表 Serverlessの取り込み課金、Hostedのリソース課金 Serverless ／ Cloud Hosted The post 2026年10月1日、基幹インフラに攻撃の報告義務。ログを聞かれるのは誰か、そしてその準備 first appeared on Elastic Portal .

こんな場面に心当たりはないでしょうか。 ログの保存コストを下げたい。件数の多いパターンから削りたいが、障害時に必要なログかもしれず、削っていいのか判断できない 検知ルールごとのアラート件数を見て、常時鳴っているルールと今日だけ鳴ったルールを区別できない サービスごとのエラー率は正常に見えるのに、どこかのバージョンだけ静かに悪化している気がする いずれも、合計や平均では答えが出ません。必要なのは「時間とともにどう動いたか」です。しかし数十行の結果に対して、1 行ずつグラフを作って確かめるわけにもいきません。 Elasticsearch 9.5 でテクニカルプレビューとして追加された SPARKLINE は、この隙間を埋めます。STATS … BY の各行に、その行の推移をミニグラフとして 1 列足してくれます。別の可視化を作る必要はありません。 この記事では、Kibana のフライトサンプルデータを使って動きを確認します。あわせて、従来の書き方と比べて何が変わるのか、実務ではどこで効くのかを見ていきます。 目次 構文 例 1：航空会社ごとの遅延の推移 SPARKLINE がなかったら、どう書いていたか 例 2：到着国ごとの平均運賃の推移 使うときの注意点 どんなときに向いているか 本命はログパターン分析 まとめ 参考資料 構文 SPARKLINE(集計式, 日付フィールド, バケット数, 開始, 終了) 集計式：COUNT(*)、SUM(bytes)、AVG(latency) など、y 軸にしたい値 日付フィールド：時間軸に使う日付フィールド バケット数：分割数の目安 開始／終了：対象期間。Kibana では時間ピッカーと連動する ?_tstart と ?_tend を使えます STATS の集計関数のひとつなので、新しい構文を覚える必要はありません。空のバケットは 0 で埋まるため、どの行も同じ時間軸で並び、形をそのまま見比べられます。 例 1：航空会社ごとの遅延の推移 サンプルデータ「Sample flight data」（kibana_sample_data_flights）で試します。遅延した便を航空会社ごとに数え、あわせて推移を出します。時間範囲は直近 7 日間にしました。 FROM kibana_sample_data_flights | WHERE FlightDelay == true | STATS delays = COUNT(*),         trend = SPARKLINE(COUNT(*), timestamp, 24, ?_tstart, ?_tend)     BY Carrier | SORT delays DESC 図 1: 遅延件数は 4 社 結果を見てください。遅延件数は 154 件、146 件、145 件、126 件です。数字だけ見れば「4 社とも似たようなもの」で終わってしまいます。 ところが trend の形は違います。どの社も日ごとに波打っていますが、山が立つ日と山の高さは社ごとにばらばらです。合計が近くても、どの日にどの社が跳ねたのかは別の話です。この違いが、クエリ 1 本で並んで見えます。 trendの形の違いを同じデータセットで過去２日間でも載せます。 SPARKLINE がなかったら、どう書いていたか 同じ情報を従来の書き方で出してみます。時間を BUCKET でグループに加える方法です。 FROM kibana_sample_data_flights | WHERE FlightDelay == true | STATS delays = COUNT(*)     BY Carrier, bucket = BUCKET(timestamp, 24, ?_tstart, ?_tend) | SORT Carrier, bucket 図 2: 同じ情報が 60 行に分かれる 結果は 60 行になりました。4 社 × 15 バケットです。例 1 は 4 行でしたから、15 倍に増えています。しかも 1 社分で 15 行を使うため、ES-Air の次の航空会社を見るにはスクロールが必要です。航空会社ごとの傾向を読むには、この表を目で束ね直すことになります。 ここで数字を突き合わせてみます。ES-Air の 15 行の値を合計すると、例 1 の ES-Air の遅延件数になります。つまり、例 1 のスパークラインは、この 15 個の数字を 1 行に畳んだものです。特別な計算をしているわけではありません。見慣れた時間バケットごとの集計を、行ではなく配列として返しているだけです。 なお、Kibana が自動生成するグラフは、時間ごとの積み上げ棒になります。合計は分かりますが、形を比べる用途には向きません。並べて比べたいなら、やはり別途グラフを作ることになります。 例 2：到着国ごとの平均運賃の推移 COUNT 以外の集計も使えます。平均運賃の動きを到着国ごとに並べてみます。 FROM kibana_sample_data_flights | STATS avg_price = AVG(AvgTicketPrice),         trend = SPARKLINE(AVG(AvgTicketPrice), timestamp, 20, ?_tstart, ?_tend)     BY DestCountry | SORT avg_price DESC | LIMIT 10 図 3: 上位の国はバケットが埋まっておらず、母数が少ないと分かる （Discover） ここでは、スパークラインが順位そのものを疑わせてくれます。平均運賃の 1 位はデンマーク（DK）で 799.45 です。しかし trend を見ると、棒が立っている区間がわずかしかありません。つまり、直近 7 日間で該当便が数便しかなく、その少数の便が平均を決めています。2 位のフィンランド（FI）も同じ傾向です。 一方、順位が下がるにつれて区間が埋まっていき、オーストラリア（AU）やロシア（RU）、イギリス（GB）はほとんどの区間にデータがあります。母数が安定しており、平均値も信頼できます。 「上位が本当に高いのか、それとも母数が少ないだけか」を、テーブルの中で判断できます。これは合計値や平均値の列だけでは分かりません。 使うときの注意点 実際に動かして分かった点も含めて、4 つ挙げます。 バケット数は目安です。 例 1 では 24 を指定しましたが、返ってきたのは 15 本でした。直近 7 日間という範囲に対して、12 時間刻みという切りのよい間隔が選ばれています。手元で試した限り、BUCKET 関数と同じ丸め方でした。正確な本数と値は、棒にカーソルを当てると確認できます。 空のバケットは 0 になります。 COUNT なら「その時間帯は 0 件」と読めるので自然です。しかし AVG では「データがなかった」と「平均が 0 だった」を区別できません。例 2 の DK のように棒が抜けている場合は、値が 0 なのではなく母数がないと読んでください。 ミニグラフになる条件があります。 返り値は数値の配列ですが、Kibana の ES|QL エディタで実行すると棒グラフとして描画されます。ただし、これはグループ表示のときだけです。グループ表示に切り替わるのは、BY に単一のフィールドか単一の CATEGORIZE を指定した場合です。BUCKET を併用したり、複数のフィールドでグループ化すると、通常のフラットな表に戻ります。前節の比較で表示が変わったのは、この仕様のためです。 テクニカルプレビューです。 Elasticsearch 9.5 で提供されています。仕様が変わる可能性があるため、本番のダッシュボードに組み込む前にバージョンを確認してください。 どんなときに向いているか 冒頭に挙げた場面に戻ります。共通しているのは次の 2 点です。 グループの数が多い（十数件から数百件） 合計や平均では判断が決まらず、時間ごとの形で判断が変わる 逆に、グループが数件なら素直に可視化を作れば済みます。ここまで見てきたフライトデータの例も 4 行なので、正直なところ SPARKLINE がなくてもさほど困りません。無理に使う理由はありません。 本命はログパターン分析 ここからは、実務でいちばん効く使い方です。順番に説明します。 ログは「同じ形の繰り返し」でできている アプリケーションのログを開くと、こんな行が延々と続いています。 Connected to backend 10.1.0.4 in 32ms Connected to backend 10.1.0.7 in 28ms Connected to backend 10.1.0.2 in 41ms 人間が見れば「同じ種類のログが 3 件」です。しかし IP アドレスと数値が違うため、文字列としては 3 つとも別物です。BY message でグループ化しても 3 行に分かれてしまい、集計になりません。 CATEGORIZE が「形」ごとにまとめる CATEGORIZE は、似た形式のメッセージを自動でひとつのカテゴリにまとめる関数です。イメージとしては、上の 3 件が「Connected to backend * in *ms」という 1 つのパターンになります。ここまでの例では BY Carrier のようにグループの軸を自分で決めていました。CATEGORIZE を使うと、軸を事前に決める必要がありません。「このインデックスには何種類のログが、それぞれ何件あるのか」を機械に数えさせることができます。 SPARKLINE を足すと、パターンごとの推移が並ぶ この 2 つを組み合わせたのが次のクエリです。ここだけデータを替えて、サンプルデータの Web ログ（kibana_sample_data_logs）を使います。フライトデータと同じ「Add sample data」画面からインストールできて、そのまま試せます。 FROM kibana_sample_data_logs | WHERE @timestamp >= ?_tstart AND @timestamp < ?_tend | STATS count = COUNT(*),         trend = SPARKLINE(COUNT(*), @timestamp, 40, ?_tstart, ?_tend)     BY pattern = CATEGORIZE(message) | SORT count DESC 結果はパターンごとに 1 行です。画面の仕組みはフライトの例とまったく同じで、違いはグループの軸を CATEGORIZE が自動で作っている点だけです。 図 4: 約 1,600 件のログが 7 つのパターンにまとまり、それぞれに推移が付く 実行すると、直近 7 日間の約 1,600 件のログが 7 つのパターンにまとまりました。行のタイトルには、検出されたパターンがトークン単位で強調表示されます。このデータでは、リクエストの共通部分に加えて、ブラウザーの種類（Firefox、MSIE、Chrome）ごとにパターンが分かれました。 ミニグラフを読んでみます。上位 3 パターン（616 件、464 件、429 件）は、どれも毎日同じリズムで波打つ形です。定常的なトラフィックだと分かります。4 番目の 104 件のパターンは棒がまばらで、断続的にしか現れません。残りの 3 行は 1 件だけの単発です。件数の列だけでは「多い順」しか分かりませんが、形が付くと「定常」「断続」「単発」の区別が一目で付きます。実際のアプリケーションログなら、この「定常」の中からコスト削減の候補を探し、「断続」や「単発」は中身を確かめる、という進め方になります。 なお、クエリを書かずにパターン分析を試す入り口もあります。Discover のクラシックモードで、結果テーブル上部の「View as」メニューを「Patterns」に切り替えると、テキストフィールドのパターン分析を画面操作だけで実行できます。ただし、これは CATEGORIZE とは別の実装です。同じデータで試したところ、Patterns 表示は 3 パターン、CATEGORIZE は 7 グループと、まとまり方が異なりました。まず雰囲気をつかむならこちら、集計やバケット数を自分で決めたくなったら ES|QL で、という使い分けです。 図 5: パターン分析オプション 何がうれしいのか 典型的な場面はログのコスト削減です。ログは取り込み量と保存量に応じて費用がかかるため、件数の多いパターンから削りたくなります。しかし、件数の多いパターンをどう扱うかは件数では決まりません。一日中平坦に流れているパターンは、ただのノイズです。ログレベルを落とすか、取り込み時に捨てるか、安価な保存階層に回せます。一方、障害時だけ跳ねるパターンは、件数が多くても消してはいけない情報です。この 2 つを分けられるのは形だけです。 削るための対処法そのものは単純です。難しいのは、対象を見つけることでした。SPARKLINE は、その発見にかかる時間を縮めます。 冒頭に挙げた残りの 2 つ、検知ルールごとのアラートや、バージョンごとのエラー率も、書き方は同じです。BY の対象をルール名やバージョンに変えるだけで応用できます。 なお CATEGORIZE は Platinum ライセンスが必要です。また、他の式の中では使えず、グループ化の最初に置く必要があります。データが大きい場合は、STATS の前に SAMPLE コマンドを置いて母数を間引くと速くなります。 まとめ クエリは 1 本、傾向は行数ぶん。SPARKLINE の価値は、行が多いときにいちばん出ます。今回は 4 社で 60 行が 4 行になりました。これが数十件のパターンやサービスであれば、差はさらに開きます。上から眺めて、「いま跳ねているのはどれか」「順位の上位は信用できるか」を数秒で絞り込めます。サンプルデータを入れたクラスターがあれば、上のクエリをそのまま貼って確認できます。 参考資料 Introducing SPARKLINE in ES|QL: Spot trends at a glance https://www.elastic.co/search-labs/blog/esql-sparkline-function ES|QL SPARKLINE function（公式リファレンス） https://www.elastic.co/docs/reference/query-languages/esql/functions-operators/aggregation-functions/sparkline Using ES|QL in Discover（グループ表示とパターンのスパークライン） https://www.elastic.co/docs/explore-analyze/discover/try-esql The post ES|QL の SPARKLINE で「ログやエラーの傾向」をひと目でつかむ first appeared on Elastic Portal .

ファイルサーバー等の検索システム構築において、事前に必要なストレージ容量を試算する際の手順を解説します。 今回は、FSCrawler (*1) を使って検索用ストレージサイズの概算見積りを行ってみたいと思います。 (*1) Elastic の正式な製品ではありませんが、ファイルを検索できるよう Elasticsearch に登録してくれるオープンソースです。 目次 1. 検証の概要 2. 環境 3. FSCrawler の初期化と設定 4. 検索用ファイルの配置 5. FSCrawlerの実行 6. 登録確認 7. インデックスサイズの確認 8. セマンティック検索：なしで再計測 9. セマンティック検索：「あり」と「なし」のストレージサイズの比較 10. 概算見積りの計算ポイントと影響要因 11. まとめ 12. 参考URL 1. 検証の概要 本記事では、サンプルファイルを FSCrawler で Elasticsearch に取り込み、作成されたインデックスの物理ストレージサイズを取得することで、 ストレージ容量の見積り倍率（元のファイルサイズに対するインデックスサイズの割合）を算出する手順を解説します。 2. 環境 Windows 11 Elasticsearch 9.5.2 (Self-Managed, Trial License) Elastic Cloud （セマンティック検索用） FSCrawler 3.0 Java 25.0.4.1 3. FSCrawler の初期化と設定 下記を参考にして FSCrawler をインストールします。 https://fscrawler.readthedocs.io/en/fscrawler-3.0/installation.html FSCrawler の初期設定を行います。 参考URL:  https://fscrawler.readthedocs.io/en/fscrawler-3.0/user/getting_started.html set JAVA_HOME=jdk-25.0.4.1のインストールフォルダ set FS_JAVA_OPTS=-Xmx2g -Xms2g bin\fscrawler.bat --setup C:\Users\username\.fscrawler\fscrawler\_settings.yaml ファイルが生成されるので、これを編集します。 （下記はあくまでもサンプルです。適宜修正してください。） name: "test" fs: url: "C:/tmp/es" update_rate: "15m" includes: - "**/*.pdf" - "**/*.docx" - "**/*.xlsx" - "**/*.pptx" excludes: - "**/*.bak" hash_algorithm: "SHA-256" raw_metadata: true ocr: enabled: false elasticsearch: urls: - "https://127.0.0.1:9200" index: "test_docs" index_folder: "test_folder" api_key: "YOUR_API_KEY" ca_certificate: "ca.crtファイルのパス" #pipeline: "my_pipeline" semantic_search: "true" 検索対象のフォルダを C:\tmp\es としておきます。 今回は、*.pdf, *.docx, *.xlsx, *.pptx ファイルを検索対象とします。 セマンティック検索：あり としておきます。 API_KEYは、Kibana 上で発行しておきます。 ※セマンティック検索を行う場合、EIS の設定を行っておくなど、Elasticsearch 側での事前準備が必要です。 4. 検索用ファイルの配置 C:\tmp\es フォルダ配下に検索対象となるテスト用ファイル（例: 合計 1 GB の PDF や Office 文書）を配置します。 ここでは、 東京都防災ホームページ  からダウンロードした 「東京都くらし防災」（全ページ） (13.5MBのpdf) を C:\tmp\es\pdf\kb2023-tokyo-all.pdf として配置します。 5. FSCrawlerの実行 FSCrawlerを実行してインデックス化を行います。 set JAVA_HOME=jdk-25.0.4.1のインストールフォルダ set FS_JAVA_OPTS=-Xmx2g -Xms2g bin\fscrawler.bat FSCrawlerの実行に成功すると、C:\Users\username\.fscrawler\test\_checkpoint.json ファイルが作成されます。 また、Elasticsearch の test_docs インデックスにドキュメントが登録されます。 6. 登録確認 Kibana の DevTool から下記のクエリを実行してみます（キーワード検索）。 GET /test_docs/_search { "query": { "match": { "content": "寝室での注意事項" } } } ドキュメントが返却されます。 続いて、下記のリクエストも実行してみます（セマンティック検索）。 GET /test_docs/_search { "query": { "match": { "content_semantic": "寝室での注意事項" } }, "highlight": { "fields": { "content_semantic": { "number_of_fragments": 2, "order": "score" } } } } こちらもドキュメントが返却されます。 7. インデックスサイズの確認 Kibana の Stack Management / Index Management の画面から test_docs インデックスのページを表示します。 プライマリインデックスのサイズが 568.65 KB, レプリカと合わせると 1.11 MB であることがわかります。 8. セマンティック検索：なしで再計測 content フィールドに対するセマンティック検索用データ（ベクトルデータ）を生成しないようにして再計測してみます。 また、content フィールドの analyzer をデフォルトの standard ではなく、日本語用の analyzer を使うよう設定しておきます。 ※ Elasticsearchに事前に analysis-icu, analysis-kuromoji のインストールが必要です。 登録先のインデックスを test2_docs とします。 下記のリクエストを Dev Tool から発行して test2_doc インデックスを作成しておきます。 PUT /test2_docs/ { "settings": { "index": { "number_of_replicas": 1 }, "analysis": { "char_filter": { "windows_separator": { "type": "mapping", "mappings": [ """\\ => /""" ] }, "ja_normalizer": { "type": "icu_normalizer", "name": "nfkc_cf", "mode": "compose" } }, "tokenizer": { "fscrawler_path": { "type": "path_hierarchy" }, "ja_kuromoji_tokenizer": { "mode": "search", "type": "kuromoji_tokenizer", "discard_compound_token": true, "user_dictionary_rules": [ ] } }, "filter": { "ja_search_synonym": { "type": "synonym_graph", "lenient": false, "updateable": false, "expand": true, "synonyms": [ ] } }, "analyzer": { "fscrawler_path": { "char_filter": [ "windows_separator" ], "tokenizer": "fscrawler_path" }, "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", "ja_search_synonym" ] } } } }, "mappings": { "dynamic_templates": [ { "raw_as_text": { "path_match": "meta.raw.*", "mapping": { "fields": { "keyword": { "ignore_above": 256, "type": "keyword" } }, "type": "text" } } } ], "properties": { "attachment": { "type": "binary" }, "attributes": { "properties": { "acl": { "properties": { "flags": { "type": "keyword" }, "permissions": { "type": "keyword" }, "principal": { "type": "keyword" }, "type": { "type": "keyword" } } }, "group": { "type": "keyword" }, "owner": { "type": "keyword" } } }, "content": { "type": "text", "analyzer": "ja_kuromoji_index_analyzer", "search_analyzer": "ja_kuromoji_search_analyzer" }, "file": { "properties": { "checksum": { "type": "keyword" }, "content_type": { "type": "keyword" }, "created": { "type": "date", "format": "date_optional_time" }, "extension": { "type": "keyword" }, "filename": { "type": "keyword", "store": true }, "filesize": { "type": "long" }, "indexed_chars": { "type": "long" }, "indexing_date": { "type": "date", "format": "date_optional_time" }, "last_accessed": { "type": "date", "format": "date_optional_time" }, "last_modified": { "type": "date", "format": "date_optional_time" }, "url": { "type": "keyword", "index": false } } }, "meta": { "properties": { "altitude": { "type": "text" }, "author": { "type": "text" }, "comments": { "type": "text" }, "contributor": { "type": "text" }, "coverage": { "type": "text" }, "created": { "type": "date", "format": "date_optional_time" }, "creator_tool": { "type": "keyword" }, "date": { "type": "date", "format": "date_optional_time" }, "description": { "type": "text" }, "format": { "type": "text" }, "identifier": { "type": "text" }, "keywords": { "type": "text" }, "language": { "type": "keyword" }, "latitude": { "type": "text" }, "longitude": { "type": "text" }, "metadata_date": { "type": "date", "format": "date_optional_time" }, "modifier": { "type": "text" }, "print_date": { "type": "date", "format": "date_optional_time" }, "publisher": { "type": "text" }, "rating": { "type": "byte" }, "relation": { "type": "text" }, "rights": { "type": "text" }, "source": { "type": "text" }, "title": { "type": "text" }, "type": { "type": "text" } } }, "path": { "properties": { "real": { "type": "keyword", "fields": { "fulltext": { "type": "text" }, "tree": { "type": "text", "analyzer": "fscrawler_path", "fielddata": true } } }, "root": { "type": "keyword" }, "virtual": { "type": "keyword", "fields": { "fulltext": { "type": "text" }, "tree": { "type": "text", "analyzer": "fscrawler_path", "fielddata": true } } } } } } } } 先ほど実行していた fscrawler.bat を Ctrl+C で停止させます。 C:\Users\username\.fscrawler\fscrawler\_settings.yaml ファイルを修正します。 name : test -> test2 index : test_docs -> test2_docs index_folder : test_folder -> test2_folder semantic_search : true -> false name: "test2" fs: url: "C:/tmp/es" update_rate: "15m" includes: - "**/*.pdf" - "**/*.docx" - "**/*.xlsx" - "**/*.pptx" excludes: - "**/*.bak" hash_algorithm: "SHA-256" raw_metadata: true ocr: enabled: false elasticsearch: urls: - "https://127.0.0.1:9200" index: "test2_docs" index_folder: "test2_folder" api_key: "YOUR_API_KEY" ca_certificate: "ca.crtファイルのパス" #pipeline: "my_pipeline" semantic_search: "false" fscrawler.bat を再実行します。 set JAVA_HOME=jdk-25.0.4.1のインストールフォルダ set FS_JAVA_OPTS=-Xmx2g -Xms2g bin\fscrawler.bat test2_docs インデックスへドキュメントが登録されます。 Kibana の Stack Management / Index Management の画面から test2_docs インデックスのページを表示します。 プライマリインデックスのサイズが 223.02 KB, レプリカと合わせると 446.04 KB となっています。 9. セマンティック検索：「あり」と「なし」のストレージサイズの比較 条件 元ファイルのサイズ プライマリインデックスのサイズ インデックスサイズ/元ファイルサイズの比率 セマンティック検索あり 13870.63 KB 568.65 KB 4.1% セマンティック検索なし 13870.63 KB 223.02 KB 1.6% セマンティック検索用のベクトルデータを生成しない分、ストレージサイズが減少したことがわかります。 ※この結果は、入力ファイルにより変動するので、実際に使用するファイルで試すことをお勧めします。 10. 概算見積りの計算ポイントと影響要因 実際の容量見積もりを行う際は、以下の要素を考慮して計算式を組み立てます。 テキスト抽出比率 : PDF や Office ファイル内のテキストデータ割合に依存します。スキャン画像主体の PDF ではインデックスサイズが小さくなり、テキスト主体の文書では大きくなります。 レプリカ数の乗算 : 本番環境で冗長化のためにレプリカ数を  1  に設定する場合、ストレージ要件は  プライマリサイズ × 2  になります。 要件に近い形でサンプルデータのインデックス登録を行い、ストレージサイズを取得します。 サンプルデータで算出した倍率を全体のファイルサーバー容量に掛け合わせることで、Elasticsearch 用ストレージの概算見積もりが可能となります。 想定ストレージサイズ = 対象ファイルの総容量 x 検証で得られたインデックス比率 x (1 + レプリカ数) ※注意 FSCrawler は、基本的に 1 ファイル = 1 ドキュメントとしてインデックスに登録します。 11. まとめ 今回は FSCrawler を活用し、サンプルファイルを用いて Elasticsearch の検索用ストレージサイズを概算見積もりする手順をご紹介しました。 今回の検証における主なポイントは以下の通りです。 セマンティック検索（ベクトルデータ）の影響 : セマンティック検索を有効にすると、テキストデータに加えてベクトルデータが保持されるため、ストレージサイズが大きくなります（今回の検証では元ファイル比で 1.6% から 4.1% に増加）。 実ファイルを用いた事前検証の重要性 : PDF や Office 文書内のテキスト抽出比率によってサイズが変動するため、本番環境に近いサンプルファイルで試算することが精度向上の鍵となります。 冗長化構成（レプリカ数）の考慮 : プライマリサイズだけでなく、本番環境のレプリカ設定（例: レプリカ 1 の場合はプライマリ × 2）を忘れずに計算式へ組み込む必要があります。 検索システムの新規構築や移行におけるクラスタ設計・キャパシティプランニングの際、ぜひ本記事の手順を参考に試算してみてください。 12. 参考URL https://qiita.com/daixque/items/83a04da18c51ba29324e https://fscrawler.readthedocs.io/en/fscrawler-3.0/ The post FSCrawler を使って検索用ストレージサイズの概算見積りを行う first appeared on Elastic Portal .

Logstash の転送先や Python 等のアプリケーションから指定する Elasticsearch の接続先 URL（endpoint URL）は、運用形態（Self-Managed、Elastic Cloud Hosted、Elastic Cloud Serverless）ごとに取得方法や基本形式が異なります。 この記事では、それぞれの運用形態における接続先 URL の取得・確認手順をまとめて解説します。 目次 Self-Managed の場合 URLの基本形式 取得・確認手順 Elastic Cloud Hosted の場合 URLの基本形式 取得手順 Elastic Cloud Serverless の場合 URLの基本形式 取得手順 Self-Managed の場合 オンプレミスや VM（AWS EC2 など）、Docker 等の独自環境で構築した Elasticsearch へ接続する場合は、サーバーの IP アドレス（またはホスト名）とポート番号を組み合わせて接続先を指定します。 URLの基本形式 https://<ホスト名またはIPアドレス>:9200 （※ Elasticsearch 8.0 以降はデフォルトで TLS/HTTPS が有効です。セキュリティの観点から HTTP 接続は推奨されません。） 取得・確認手順 Elasticsearch が稼働しているサーバーの IP アドレスまたは FQDN（ドメイン名）を確認します（ローカル開発環境の場合は  localhost  や  127.0.0.1 ）。 設定ファイル（ elasticsearch.yml ）内の  network.host  および  http.port （標準は  9200 ）を確認し、接続可能ポートとして開放されているか確認します。 Elastic Cloud Hosted の場合 Elastic Cloud Hosted の場合は、管理コンソール画面からエンドポイント URL を直接取得できます。 URLの基本形式 https://**.<region>.<cloud-provider>.**.io:443 （ ※ ポート番号は構成により、443や  9243  などが利用されます。） 取得手順 Elastic Cloud コンソール  にログインします。 接続したい  Deployment（デプロイメント）  を選択します。 左のメニューの  Getting started  アイコンをクリックします。 Get started with Elasticsearch. 画面の Elasticsearch endpoint: の右下にあるコピーアイコンをクリックします。 ※別ルートとして、Kibana 画面右上のヘルプアイコン（ ? ）＞  Connection details  からコピーすることも可能です。 Elastic Cloud Serverless の場合 Elastic Cloud Serverless を使用している場合も、プロジェクトごとに固有のエンドポイントが割り当てられます。 URLの基本形式 https://<project-id>.es.<region>.<cloud-provider>.elastic.cloud:443 （※標準ポート:443） 取得手順 Elastic Cloud コンソールから対象の  Serverless Project  にアクセスします。 Home 画面が表示されていることを確認します（表示されていない場合、左メニューの Home アイコンをクリックします）。 3. Home 画面の右上の Elasticsearch: の接続先URL の横にあるコピーアイコンをクリックします。 ※別ルートとして、Kibana 画面右上のヘルプアイコン（ ? ）＞  Connection details  からコピーすることも可能です。 運用形態によってポート番号（ 9200 ,  9243 ,  443 ）やプロトコル（HTTP / HTTPS）の設定ルールが微妙に異なるため、Logstash やアプリケーションのクライアント設定（ hosts  プロパティなど）に記述する際は指定する形式に注意してください。 The post Elasticsearch の 3形態ごとの接続先URLの取得方法をまとめてみた。 first appeared on Elastic Portal .

Kibanaの表示言語はこれまでサーバー単位の設定（ kibana.yml ）によって一括で決定されていましたが、 Kibana 9.5 からは  ユーザーごとに個別の表示言語を設定できる機能  がベータ版（Beta）として導入されました。 これにより、グローバルなチームや多言語環境でKibanaを運用している場合でも、各ユーザーが好みの言語でダッシュボードやUIを閲覧できるようになります。 本記事では、この表示言語の切り替え機能の概要と具体的な設定手順を解説します。 目次 検証環境 画面上での言語切り替え手順 1. User メニューの表示 2. User settings 画面への遷移 3. 表示言語の変更と保存 4. Reload page 画面表示の変化 切り替え前の Home 画面（英語表示） 切り替え後の Home 画面（日本語表示） 技術的な注意点・補足 対象範囲 機能ステータス おわりに 参考URL 検証環境 本記事の内容は以下の環境で確認しています。 Elasticsearch 9.5.0 (Self-Managed) Kibana 9.5.0 (Self-Managed) 画面上での言語切り替え手順 デフォルト（英語表示）の状態から日本語へ切り替える手順は以下の通りです。 1. User メニューの表示 画面右上のユーザーごとのアイコン（この例では (E) アイコン）をクリックします。 2. User settings 画面への遷移 展開されたメニューから Edit profile をクリックすると、User settings 画面に遷移します。 3. 表示言語の変更と保存 Language / Display language を希望する言語（例：日本語）に切り替え、右下の [Save changes] をクリックします。 4. Reload page 画面をリロードするよう促すダイアログが表示されるので、[Reload page] をクリックします。 画面表示の変化 切り替え前の Home 画面（英語表示） 切り替え後の Home 画面（日本語表示） 技術的な注意点・補足 対象範囲 本機能で変更されるのは Kibana の UI 表示言語（i18n）です。インデックスされているログやドキュメントなどのデータ内容が自動翻訳されるわけではありません。 機能ステータス Kibana 9.5 時点ではベータ版（Beta）機能です。本番運用環境への導入にあたっては、制限事項や今後の更新情報をご確認ください。 おわりに ユーザーごとの表示言語設定機能により、サーバー全体の設定を変更することなく、各自が使いやすい言語環境で Kibana を活用できるようになりました。 複数メンバーで同一環境を利用している場合は、ぜひ試してみてください。 参考URL PR #260835 The post Kibanaでユーザーごとの表示言語切り替えが可能に！新機能の概要と設定方法解説 first appeared on Elastic Portal .

Elastic Securityで生成AIを使うとき、どのLLMを選べばよいのでしょうか。 Elasticは、複数のLLMをElastic Securityのタスクで評価した「Large language model performance matrix」を公開しています。モデルを比較できる便利な資料ですが、Overall Score（総合点）の順位だけで選ぶと、使いたい機能に合わないモデルを選ぶ可能性があります。 本記事で使うモデル名、スコア、集計方法、「5以下はそのタスクに非推奨」という基準は、特記がない限り2026年8月26日時点のElastic公式性能表に基づきます。 [^1] モデルや評価値は更新される可能性があるため、導入時には最新の公式表をご確認ください。 目次 先に結論：モデル名ではなく、使いたい機能から選ぶ 性能表が評価する3つの能力 Overall Scoreだけでは判断できない 「自己デプロイ可能なモデルは使えない」は正確ではない なぜ一般的なLLMランキングと結果が違うのか Agent Builderは「実際に作業したか」も評価する Attack Discoveryは「攻撃を正しくまとめられるか」を評価する 自己デプロイ可能なモデルは、同じモデル名でも結果が変わる モデルファイルの容量と、実行に必要なメモリは同じではない 実際の選定手順 1. 使いたい機能を1つ決める 2. 対応するスコアを見る 3. 5以下を非推奨の目安にする 4. 自己デプロイ可能なモデルでは実行条件を記録する 5. 自社に近いデータでPoCする まとめ 補足：性能表の集計値を資料へ転記するときの注意 参考資料 先に結論：モデル名ではなく、使いたい機能から選ぶ LLMは、すべての仕事で同じ性能を発揮するわけではありません。 たとえば、あるモデルがAttack Discoveryに向かなくても、Automatic Migrationでは高い性能を示すことがあります。「このモデルは使える／使えない」と一括りにせず、 どの仕事に使えるか を見る必要があります。 性能表が評価する3つの能力 性能表の上位項目は、次の3つです。 能力 Elastic Securityで行う仕事 確認する場面 Agent Builder アラート分析、脅威ハンティング、検知ルールやワークフローの作成など SOC業務をAIエージェントに支援させたい Attack Discovery 複数のアラートを関連付け、攻撃のまとまりや流れとして示す 大量のアラートから優先調査対象を見つけたい Automatic Migration 他社SIEMの検知ルールをElastic向けに変換する Splunkなどからルールを移行したい Agent Builderは、さらに7つのサブ能力に分かれています。 Alert Analysis（アラート分析） Entity Analytics（ホストやユーザーの分析） Threat Hunting（脅威ハンティング） Detection Rules（検知ルール作成） Workflow Authoring（ワークフロー作成） Triggering Workflows（ワークフロー実行） Multi-Step Executions（複数ステップの実行） Agent Builderの平均点が高くても、自分が使いたいサブ能力の点が低い場合があります。用途が決まっているなら、平均点より個別のスコアを優先します。 Overall Scoreだけでは判断できない Overall Scoreは、次の3スコアの平均です。 Overall Agent Builder Score Attack Discovery Automatic Migration この数値は、Elastic SecurityのAI機能全体で広く高い性能を持つかを見るには便利です。しかし、異なる仕事の平均なので、特定機能への適性は隠れてしまいます。 参照日時点の主なモデルを例に見てみます。比較の基準として表全体でOverall Scoreが最も高いClaude Opus 4.7と、Overall Scoreが高くても機能ごとに差がある例としてGemini 2.5 Flashを掲載しました。 公式表は、利用者が自分でデプロイできるモデルを「Open-source models」に分類しています。ただし、各モデルのライセンス条件は同じではありません。そのため、本記事では誤解を避けるために 自己デプロイ可能なモデル と呼びます。下表の3モデルは、この分類でOverall Scoreが高い上位3件です。 モデル Agent Builder Attack Discovery Automatic Migration Overall Anthropic Claude Opus 4.7 8.29 9.70 9.70 9.23 Google Gemini 2.5 Flash 5.86 9.50 9.81 8.39 OpenAI GPT-OSS 120B 5.14 3.00 9.40 5.85 Gemma 4 31B IT 7.00 2.80 7.50 5.77 DeepSeek V4 Pro 5.86 8.30 3.10 5.75 Gemini 2.5 FlashはOverall Scoreが8.39と高い一方、Agent Builderは5.86です。さらにサブ能力を見ると、Alert AnalysisとDetection Rulesはどちらも5.00で、Elasticの基準ではそのタスクに非推奨です。Overall Scoreが個別の弱点を隠す問題は、モデルの提供形態に関係なく起こります。 また、3つの自己デプロイ可能なモデルは、Overall Scoreだけを見ると5.75〜5.85と近い値です。一方、得意分野は大きく異なります。 GPT-OSS 120BはAutomatic Migrationが9.40ですが、Attack Discoveryは3.00です。 Gemma 4 31B ITはAgent Builderが7.00、Automatic Migrationが7.50です。 DeepSeek V4 ProはAttack Discoveryが8.30ですが、Automatic Migrationは3.10です。 つまり、「自己デプロイ可能なモデルの中でOverall Scoreが最も高いもの」を選ぶ方法は適切ではありません。Attack Discoveryを使うならAttack Discoveryの列、SIEM移行ならAutomatic Migrationの列を見るのが基本です。 「自己デプロイ可能なモデルは使えない」は正確ではない 性能表から読み取れるのは、「すべての主要機能で安定して高得点を取る自己デプロイ可能なモデルは、掲載モデルの中には見当たらない」ということです。 一方で、用途別には有力な候補があります。 Automatic Migration：GPT-OSS 120Bは9.40 Agent Builder：Gemma 4 31B ITは7.00 Attack Discovery：DeepSeek V4 Proは8.30 そのため、「自己デプロイ可能なモデルは使い物にならない」ではなく、 用途による性能差が大きいため、機能ごとの選定が特に重要 と表現するほうが正確です。 なお、Elasticの基準は「5以下はそのタスクに非推奨」です。「絶対に動かない」「利用価値がない」という意味ではありません。原文は「5 or below」なので、5.0ちょうども非推奨に含まれます。 なぜ一般的なLLMランキングと結果が違うのか この性能表は、一般的な知識や文章作成能力を比べるLLMランキングではありません。Elasticは、模擬した侵入シナリオ、正解データ、ツール呼び出しを含む実行過程、モデル名を伏せたブラインド評価などを使い、Elastic Securityの業務における性能を評価しています。 [^2] Agent Builderは「実際に作業したか」も評価する Agent Builderの評価には「No tool call, no credit」という考え方があります。必要なツールを呼ばず、もっともらしい文章だけを返した場合は、根拠のない回答として10点中6点が上限になります。 たとえば、検知ルールやワークフローを作成するタスクでは、文面が正しそうかだけではなく、実際に作成、有効化、実行できたかまで確認します。 Attack Discoveryは「攻撃を正しくまとめられるか」を評価する Attack Discoveryは、関連するアラートを一つの攻撃ストーリーとしてまとめ、関係するユーザーやホスト、MITRE ATT&CKとの対応などを示す機能です。 [^3] 評価では、各モデルに同じ約95件のアラートを渡し、その中に含まれる8つの独立した侵入を発見できるかを確認します。主な評価軸は次の4つです。 網羅性：8つの侵入をどこまで見つけられたか 正確性：ホスト、マルウェア、攻撃の流れなどを正しく説明したか 相関の品質：関連するアラートを正しくまとめたか 実用性：調査に使えるタイトル、概要、優先度を示せたか Agent Builderとはタスクが異なるため、Attack Discoveryの評価ではツールを使いません。この違いも、同じモデルのスコアが機能ごとに大きく変わる理由の一つです。 自己デプロイ可能なモデルは、同じモデル名でも結果が変わる 性能表では、DeepSeek V4 ProがAttack Discoveryで8.30を記録しています。しかし、同じモデルを用意すれば、自社環境でも8.30を再現できるとは限りません。 結果には、次の条件も影響します。 確認項目 意味 結果への影響 モデルの配布形式 どの形式・精度でモデルを用意するか 精度、必要メモリ、対応ソフトウェアが変わる 量子化 重みを低い数値精度で保持する方法 必要メモリを減らせる一方、性能に影響する可能性がある 推論エンジン LLMの回答生成を実行するソフトウェア 応答速度、同時実行数、GPUメモリの使い方が変わる コンテキストウィンドウ 一度に扱える入力と出力の範囲 長いアラート情報を扱えるかが変わる 生成パラメーター temperatureやmax tokensなど 出力のばらつきや、回答が途中で切れる可能性が変わる ハードウェア GPU、VRAM、RAMなど 実行の可否、速度、同時実行数が変わる 生成パラメーターの仕組みはHugging Face Transformersの公式ドキュメント、推論時の調整はvLLMの公式ドキュメントで確認できます。 [^4][^5] 量子化の方式と対応ハードウェアはさまざまで、方式によって圧縮率や精度への影響が異なります。 [^6] Elasticは、自己デプロイ可能なモデルを運用する接続先として、本番環境またはエアギャップ環境ではvLLM、テスト環境ではLM Studioの手順を案内しています。エアギャップ環境とは、インターネットなどの外部ネットワークから分離した環境です。また、Attack Discoveryでは性能表に掲載されたモデルの利用を推奨しています。 [^7] モデルファイルの容量と、実行に必要なメモリは同じではない LLMは、学習で得た数値を「重み」としてモデルファイルに保持しています。モデルファイルの容量は、主に保存やダウンロードに必要なディスク容量を示します。 一方、実行時にはモデルの重みだけでなく、入力の長さや処理中のデータにもメモリを使います。そのため、「ファイルを保存できる」ことと「実用的な速度で安定して動かせる」ことは別です。モデルメモリの主な構成要素は、Hugging Faceの解説で確認できます。 [^8] たとえば、量子化モデルを公開しているUnslothのDeepSeek-V4-Pro-0813-GGUFでは、Unsloth Dynamic 2.0の4-bit量子化UD-Q4_K_XLが850GBです。GGUFは、モデルの重みや設定情報をまとめ、配布・実行しやすくするファイル形式です。 [^9] このモデルは総パラメーター数1.57兆で、1トークンの処理に使われるアクティブパラメーターは48B（480億）です。処理ごとに使う部分は一部でも、モデル全体の重みをファイルに保持するため、4-bitでも850GBになります。これは「850GBのディスクがあれば、そのまま実用的に動かせる」という意味ではありません。 Elasticの評価記事には、同じデータ、プロンプト、エージェント、スキル、ツールを使い、変更する変数をモデルだけにしたと説明されています。一方、モデルの数値精度、推論エンジン、ハードウェア、コンテキストウィンドウ、temperatureなど、各社の環境で結果を再現するための実行条件は記載されていません。 したがって、性能表のスコアは有力な候補を絞るために使い、最終的な判断は自社の実行構成とデータを使ったPoCで行います。 実際の選定手順 1. 使いたい機能を1つ決める 「Elastic SecurityでAIを使いたい」ではまだ広すぎます。まずは、次のように対象を1つに絞ります。 アラート分析を支援したい Attack Discoveryで優先調査対象を見つけたい Splunkの検知ルールをElasticに移行したい 2. 対応するスコアを見る Attack DiscoveryならAttack Discoveryの列、検知ルール移行ならAutomatic Migrationの列を見ます。Agent Builderを使う場合は、必要なサブ能力まで確認します。 3. 5以下を非推奨の目安にする これはモデル全体への評価ではなく、選んだタスクに対する目安です。別の機能で高得点なら、そちらの用途では候補に残せます。 4. 自己デプロイ可能なモデルでは実行条件を記録する モデル名だけでなく、配布形式、量子化、推論エンジン、コンテキストウィンドウ、生成パラメーター、ハードウェアを記録します。再テストやモデル間の公平な比較がしやすくなります。 5. 自社に近いデータでPoCする たとえばAttack Discoveryなら、関連するアラートと無関係なアラートを混ぜ、次の点を確認します。 関連するアラートを一つの攻撃としてまとめられるか 無関係なアラートを混ぜないか 攻撃の流れを正しく説明できるか 存在しない事実を追加しないか 同じテストを繰り返しても結果が安定するか スコアは「絶対的な正解」ではなく、候補を絞るための手がかりです。最終判断には、本番に近い入力、データ量、失敗パターンを使った確認が必要です。 まとめ Elastic SecurityのLLM性能表で最も大切なのは、ランキングではなく、 自分が使う機能の列を見ること です。 Overall Scoreは全体像をつかむ参考値ですが、特定タスクの最終判断には向きません。自己デプロイ可能なモデルでは、モデル名が同じでも実行条件によって結果が変わるため、構成を記録したうえでPoCを行います。 最初に、次の一文を決めると選定しやすくなります。 Elastic Securityのどの機能を、どのようなデータで使いたいのか。 この問いを決めてから、該当スコアと自社PoCの結果を確認することが、失敗の少ないLLM選定につながります。 補足：性能表の集計値を資料へ転記するときの注意 参照日時点の表には、集計方法の説明と一部の記載値が一致しないように見える行があります。 公式説明ではOverall Agent Builder Scoreは7つのサブ能力の平均です。しかし、表示されたサブスコアを単純平均すると、次の3モデルでは掲載値と一致しません。サブスコアの並びは、Alert Analysis / Entity Analytics / Threat Hunting / Detection Rules / Workflow Authoring / Triggering Workflows / Multi-Step Executionsの順です。 モデル 表示された7サブスコア 合計 単純平均 掲載値 GPT-OSS 120B 5, 4, 6, 7, 5, 8, 7 42 6.00 5.14 Gemma 4 31B IT 6, 6, 7, 6, 8, 8, 7 48 6.86 7.00 DeepSeek V4 Pro 5, 6, 6, 6, 9, 8, 7 47 6.71 5.86 一方、掲載されたAgent Builder、Attack Discovery、Automatic Migrationの3スコアからOverall Scoreを計算すると、3モデルとも表のOverall Scoreと一致します。ずれが確認できるのはAgent Builderの集計部分です。 差の大きさは同じではありません。Gemma 4 31B ITは合計で1点分の差ですが、GPT-OSS 120BとDeepSeek V4 Proはいずれも約6点分の差があり、表示値の単純な端数処理だけでは説明しにくい大きさです。 公開情報からは、この差の原因を特定できません。公式説明は「平均」としており、重み付けや表示前の数値に関する説明もありません。資料に転記する場合は、次のように扱うのが安全です。 参照日を付け、公式表へのリンクを掲載する 独自に再計算した値を公式スコアとして扱わない 意思決定には、利用する能力の個別スコアとPoC結果を使う また、未掲載モデルは「性能が低い」のではなく、「この表では確認できない」と扱います。 参考資料 [^1]: Large language model performance matrix for Elastic Security [^2]: Benchmarking the Agentic SOC: How we evaluate LLMs for security workflows [^3]: Attack Discovery [^4]: Generation [^5]: Optimization and Tuning [^6]: Quantization overview [^7]: Self-managed custom LLMs [^8]: GPU memory usage [^9]: DeepSeek-V4-Pro-0813-GGUF The post Elastic Securityで使うLLMはどう選ぶ？性能表の正しい読み方 first appeared on Elastic Portal .

Elastic Clous Serverless では、これまで Amazon Web Services の 東京リージョンを利用することができましたが、これに加えて、Google Cloud Platform (GCP) の東京リージョン（ asia-northeast1 ）も利用できるようになりました。 日本国内のワークロードにおいて、インフラ管理不要な検索・分析基盤を低レイテンシーで導入できるようになります。 目次 今回のアップデートのポイント 主な活用ユースケース はじめる手順 参考URL 今回のアップデートのポイント 低レイテンシーなアクセス 日本国内のユーザーや、GCP東京リージョン上に配置されたシステムからの通信遅延を最小限に抑えます。 データガバナンスの遵守 データを国内に保持・管理できるため、社内規定やコンプライアンス要件に適合しやすくなります。 主な活用ユースケース GCP上の生成AI・RAG（検索拡張生成）基盤 Gemini などのGoogle Cloudプロダクトと連携し、ベクトル検索やハイブリッド検索を活用した高精度なナレッジ検索基盤を低遅延で構築。 GCPワークロードのObservability（可視化・分析） Google Cloud上で稼働するアプリケーションやマイクロサービスのログ・メトリクス・トレースを統合管理。 はじめる手順 Elastic Cloud コンソール  にログインする。 Serverless projects の [Create serverless project] から Serverless プロジェクトの新規作成画面を開く。 Elasticsearch / Elastic for Observability / Elastic for Security のいずれかの type を選択する。 クラウドプロバイダーに  Google Cloud  を選択する。 リージョンに  Tokyo (asia-northeast1)  を指定してプロジェクトを作成する。 GCP東京リージョンの利用が可能になったことで、日本国内におけるクラウド構成の自由度とパフォーマンスがさらに向上します。サーバーレスの手軽さとElasticの強力な検索・分析能力をぜひ体験してみてください。 参考URL https://www.elastic.co/docs/release-notes/cloud-serverless#july-28-2026 The post Elastic Cloud ServerlessでGCP東京リージョンが利用可能になりました！ first appeared on Elastic Portal .

Elastic 9.5では、ログの保存方法、ベクトル検索、マルチモーダル検索、AIエージェントの運用、Prometheusからの移行など、幅広い領域に新機能が追加されました。 今回のポイントは、単に機能が増えたことではありません。これまでエンジニアが手作業で行っていた 保存方式の最適化、ベクトル検索の設定、PromQLの書き換え、AIエージェントの調査 を、Elastic側がより多く引き受ける方向へ進んだことです。 この記事では、Elastic 9.5の主要機能について、次の4点に絞って説明します。 何を解決する機能なのか 9.5で何が変わったのか どのような人や環境に役立つのか 導入前に何を注意すべきか 対象バージョン ：Elastic 9.5（2026年8月4日リリース） 想定読者 ：Elasticを利用しているエンジニア、導入を検討しているアーキテクト、運用担当者 目次 まず押さえたいGAとTech Preview Columnar Mode：ログを「検索中心」から「分析中心」へ 何を解決する機能か 9.5で何が変わったか なぜ役立つのか 注意点 VectorDB index modeとAuto-calibration：ベクトル検索の初期設定を簡単にする 何を解決する機能か VectorDB index mode DiskBBQとAuto-calibration 注意点 マルチモーダルsemanticフィールド：画像やPDFも意味で検索する 何を解決する機能か 9.5で何が変わったか 注意点 Agent Builder tracing：AIエージェントの処理を見えるようにする 何を解決する機能か 9.5で何が変わったか 具体例 プライバシー上の注意 PromQL GA：Prometheus資産をElasticで活用しやすくする 何を解決する機能か 9.5で何が変わったか 移行ツール メトリック 注意点 Workflows：作成しやすく、壊しても戻しやすくする バージョン管理 Visual Mode 自然言語オーサリング Human-in-the-loop Security：AIによる調査とルール運用を強化 AlertZeroは製品名ではない Attack Discoveryの変化 検知ルール変更履歴 注意点 その他のGA機能 Dashboards API Cases as Data どの機能から試すべきか GA機能で優先度が高いもの 検証環境で試すTech Preview まとめ 参考資料 まず押さえたいGAとTech Preview Elastic 9.5の機能は、すぐに本番利用を検討できる GA（正式提供）と、まず検証環境で試すべきTech Preview に分かれます。 機能 状態 一言でいうと PromQL対応 GA 多くの既存PromQLをElasticで実行できる Dashboards API GA ダッシュボードをコードとして管理できる Cases as Data GA ケース情報を分析用データとして利用できる Workflowsの自然言語オーサリング GA 自然文からWorkflowの初稿を生成できる Workflowsのバージョン管理 GA 変更履歴の確認、比較、復元ができる 検知ルール変更履歴 GA ルールの変更内容と変更者を追跡できる Columnar Mode / Columnar Logs Tech Preview ログの保存容量を減らし、分析向けに最適化する VectorDB index mode Tech Preview ベクトル検索向けの設定をまとめて適用する DiskBBQ Auto-calibration Tech Preview 実データに合わせてベクトル検索設定を自動調整する マルチモーダルsemanticフィールド Tech Preview テキスト、画像、音声、動画、PDFを意味で検索する Agent Builder tracing Tech Preview AIエージェントの処理をトレースとして確認する Tech Previewの機能は、将来のElasticの方向性を理解するうえで重要ですが、本番利用の前に機能制約、性能、ライセンスを確認する必要があります。 Columnar Mode：ログを「検索中心」から「分析中心」へ 状態：Tech Preview 対象：大量のログを長期間保存し、ダッシュボードや集計で利用する環境 何を解決する機能か 通常のElasticsearchでは、1つのフィールドを検索、範囲検索、集計、元データの保持など、複数の目的に合わせて保存します。これは高い検索性能を実現する一方、ログのようにフィールド数が多いデータでは、保存容量が大きくなります。 実際のログ運用では、すべてのフィールドを全文検索するわけではありません。多くのフィールドは、ダッシュボードでの絞り込みや集計に使われます。 9.5で何が変わったか Columnar Modeは、非テキストフィールドを主に列形式で保存し、転置インデックスや数値範囲検索用のBKDツリーを既定では作りません。 ログ向けのlogsdb_columnarでは、messageなどのテキストフィールドには全文検索用の転置インデックスを残し、それ以外の構造化フィールドは列形式を中心に保存します。 PUT logs-example {   "settings": {     "index.mode": "logsdb_columnar"   } } なぜ役立つのか 列形式では、クエリに必要なフィールドだけを読みやすく、同じ種類の値が並ぶため圧縮もしやすくなります。 例えば、次のようなログ基盤に向いています。 1日に大量のログを取り込む service.nameやlog.levelごとの集計が多い Kibana Dashboardで傾向を見ることが中心 保存コストのため保管期間を短くしている 注意点 すべての検索が速くなるわけではありません。trace.idやpod.uidのようなランダムな値を1件だけ探す検索や、数値の範囲検索は、通常のインデックスより遅くなる可能性があります。 また、index.modeは作成後に変更できません。既存データへ適用するには、ロールオーバーまたはreindexが必要です。現時点では一律の削減率も公表されていないため、自社データで比較することが重要です。 ドキュメントの更新、nestedデータ、特定ドキュメントの取得、全文検索の関連度評価が中心の場合は、従来のインデックスモードのほうが適しています。 要点 ：保存と分析を優先するログには有望ですが、ピンポイント検索が多い環境では事前検証が必要です。 VectorDB index modeとAuto-calibration：ベクトル検索の初期設定を簡単にする 状態：Tech Preview 対象：RAG、セマンティック検索、画像検索などをこれから構築するチーム 何を解決する機能か ベクトル検索では、文章や画像を数値の並びであるベクトルへ変換し、意味の近さを距離で検索します。 ただし、大量のベクトルを扱うには、圧縮方法、検索候補数、メモリの使い方など、多くの設定が必要です。最適な値はデータによって変わるため、従来は性能と精度を測りながら手作業で調整する必要がありました。 VectorDB index mode vectordb_documentを指定すると、ベクトル検索に適した複数の設定がまとめて適用されます。 PUT my-vector-index {   "settings": {     "index.mode": "vectordb_document"   } } 主な目的は次のとおりです。 ベクトルの保存容量を抑える ベクトルを_sourceへ重複保存しない 重いセグメントマージを効率化する 検索で頻繁に使う構造を先読みする 個別の内部設定をすべて理解しなくても、ベクトル検索向けの初期状態から検証を始められます。 DiskBBQとAuto-calibration DiskBBQは、検索に必要なデータの多くをディスクへ置き、メモリへ載せるデータを減らすための検索方式です。大量のベクトルを、限られたRAMで扱いたい環境に向いています。 Auto-calibrationを有効にすると、Elasticsearchが実際のベクトルを調べ、圧縮方法や検索候補数などを自動的に選びます。 "index_options": {   "type": "bbq_disk",   "auto_calibrate": true } 正しいパラメータ名はauto_calibrateです。 注意点 Auto-calibrationは、精度を100%保証する機能ではありません。検索品質、レイテンシ、取り込み性能は実データで確認する必要があります。 比較的検索しやすいデータでは圧縮を強くし、難しいデータでは情報を多く残すことで、容量と検索精度のバランスを自動調整します。 bbq_diskにはEnterpriseライセンスが必要です。また、index.modeやauto_calibrateはインデックス作成後に変更できないため、既存データへ適用する場合はreindexが必要です。 要点 ：ベクトル検索の専門的な初期設定を減らす機能です。ただし、最終的な品質確認まで自動化されるわけではありません。 マルチモーダルsemanticフィールド：画像やPDFも意味で検索する 状態：Tech Preview 対象：図面、商品画像、スキャン文書、音声、動画を検索したいチーム 何を解決する機能か これまでのsemantic_textは、主にテキストを対象とした機能でした。画像や音声を検索するには、データの種類ごとに別のモデルやパイプラインを作る必要がありました。 9.5で何が変わったか 新しいsemanticフィールドは、次のデータを扱えます。 テキスト 画像 音声 動画 PDF これらを同じ埋め込みモデルでベクトル化することで、異なる種類のデータを意味の近さで検索できます。 例えば、次のような検索が可能になります。 「赤い花柄のワンピース」という文章から商品画像を探す 画像をクエリにして似た画像を探す 自然文から関連するPDFや図面を探す 音声から意味の近い音声や説明文を探す "my_semantic_field": {   "type": "semantic",   "inference_id": ".jina-embeddings-v5-omni-small" } 注意点 非テキストデータはdata URL形式で投入します。入力サイズは既定で1MBで、Serverlessでは1MB固定です。また、PDFなどは自動的にページ単位へ分割されないため、細かく検索したい場合は事前の分割設計が必要です。 事前定義されたJinaモデルはElastic Inference Serviceを利用します。データの送信先、料金、ライセンス、データ主権もPoC前に確認してください。 ページ単位で検索したい場合は、事前にPDFをページごとに分割して投入します。 また、重要な制約として、semanticフィールドは 9.5以降に作成されたインデックスで使用する必要がある ため、既存インデックスではreindexが必要になる場合があります。 要点 ：検索対象をテキスト以外へ広げる機能です。実務では、ファイルサイズ、分割方法、推論コストが導入判断のポイントになります。 Agent Builder tracing：AIエージェントの処理を見えるようにする 状態：Tech Preview 対象：Agent BuilderをPoCまたは運用で利用しているチーム 何を解決する機能か AIエージェントは、1つの質問に対して複数回LLMを呼び出したり、ES|QLなどのツールを実行したりします。 そのため、応答が遅い、トークン消費が増えた、意図しないツールを呼んだといった問題が起きても、原因を特定しにくいという課題があります。 9.5で何が変わったか Agent Builderは、エージェントの実行内容をOpenTelemetry形式のトレースとして記録できるようになりました。 確認できる主な情報は次のとおりです。 LLMを何回呼び出したか 各処理にどのくらい時間がかかったか どのツールを実行したか 入力・出力トークン数 どの処理で失敗したか トレースはElasticsearchへ保存されるため、Discover、ES|QL、Lens、Dashboard、アラートなど、既存のElastic機能で分析できます。 具体例 あるエージェントの応答時間とトークン使用量が突然増えたとします。 トレースを確認すると、ES|QLツールが大量の結果を返し、その内容が後続のLLM呼び出しへ何度も渡されていたことが分かるかもしれません。原因が分かれば、クエリにLIMITを追加する、ツールの説明を修正するといった対応ができます。 プライバシー上の注意 トークン数やモデル名などの構造的な情報は記録されますが、ユーザーのプロンプト、LLMの回答、ツールの結果などは既定では記録されません。 詳細内容を記録するとデバッグには便利ですが、個人情報や機密情報が含まれる可能性があります。保存期間とアクセス権限を含めた設計が必要です。 要点 ：AIエージェントを通常のアプリケーションと同じように監視し、性能・コスト・失敗原因を調べるための機能です。 PromQL GA：Prometheus資産をElasticで活用しやすくする 状態：GA 対象：Prometheus、Grafana、OpenTelemetryメトリックを利用しているチーム 何を解決する機能か PrometheusからElasticへ移行するとき、大きな負担になるのはデータ転送だけではありません。既存のGrafana Dashboardやアラートルールに書かれたPromQLを、別のクエリ言語へ書き換える作業が必要でした。 9.5で何が変わったか ElasticはPrometheus互換HTTP APIと、ES|QLから利用できるPROMQLコマンドをGAとして提供します。 PROMQL sum by (service.name) (rate(http_requests_total[5m])) GrafanaからElasticのPrometheus互換APIを参照することで、多くの既存PromQLを変更せず利用できます。また、PromQLの結果をES|QLパイプラインで後処理することもできます。 移行ツール Observability Migration Platformは、GrafanaやDatadogのダッシュボードとアラートをKibanaへ移行するためのCLIです。 変換できないパネルを無理に作成するのではなく、手動確認が必要な箇所を示す設計になっています。移行前に検証する–validateオプションも用意されています。 メトリック 9.5ではメトリック用コーデックも改善され、Elasticの説明では、メトリックの保存容量が前バージョンからさらに約20%削減されています。PromQL対応だけでなく、保存効率も改善されています。 注意点 PromQLとPrometheusが完全互換になったわけではありません。and、unless、group_left、group_rightなど、一部の構文や動作には制限があります。既存のGrafana Dashboardやアラートは、移行前に実データで確認する必要があります。 要点 ：Prometheus/Grafanaの既存資産を活かしたまま、Elasticへ段階的に統合しやすくする機能です。 Workflows：作成しやすく、壊しても戻しやすくする 状態：GA （利用プランとAgent Builder／LLM設定の確認が必要） 対象：Elastic Workflowsで運用自動化を行うチーム バージョン管理 9.5では、Workflowの変更履歴を確認し、差分比較や過去バージョンへの復元ができるようになりました。 自動化は、一度動けば終わりではありません。条件や接続先を変更した結果、処理が動かなくなることがあります。変更者、変更日時、変更内容を追跡できることで、障害調査と監査が行いやすくなります。 自然言語によるWorkflow作成を利用するには、Agent BuilderへのアクセスとLLMの設定が必要です。 Visual Mode Workflowを、トリガー、ステップ、分岐を含む図として確認できます。ただし、9.5時点では読み取り専用です。ドラッグ＆ドロップでWorkflowを作成する機能ではありません。 自然言語オーサリング 「アラートが発生したら関連ログを取得し、AIで要約してSlackへ送る」といった指示から、WorkflowのYAML初稿を生成できます。 生成されたWorkflowは、人間が確認してから実行します。自然言語だけで安全な自動化が完成するわけではなく、作成作業のスタートを速くする機能と考えるべきです。 Human-in-the-loop Workflowを途中で止め、人間の入力や承認を待つステップも利用できます。AIや自動処理にすべてを任せず、重要な操作だけ人間が判断する設計に役立ちます。 要点 ：Workflowsは「作る機能」だけでなく、変更管理、レビュー、承認を含む運用基盤へ進化しています。 Security：AIによる調査とルール運用を強化 対象：Elastic Securityを利用するSOC、セキュリティ運用チーム AlertZeroは製品名ではない AlertZeroは、新しい製品や機能の名前ではありません。大量のアラートをそのまま人間へ渡すのではなく、AIと自動化によって優先順位を付け、アナリストが重要な脅威へ集中できる状態を表す考え方です。 Attack Discoveryの変化 従来のAttack Discoveryは、複数のアラートを関連付け、攻撃のまとまりとして説明する役割が中心でした。 9.5では、Agent BuilderとWorkflowsを利用し、次のような追加調査を行う方向へ拡張されています。 関連する生イベントを検索する ユーザーやホストのリスク情報を確認する アラート以外の証拠を探す 調査結果をまとめる 見逃していた活動からES|QLルールの案を作る 別のAlert Analysisワークフローでは、アラートを真陽性と誤検知に分類します。これにより、アナリストが低品質なアラートへ費やす時間を減らし、Attack Discoveryもより整理された対象を調査しやすくなります。 作成されたルール案は、人間がレビューし、承認するまで検知ルールとして追加されません。 検知ルール変更履歴 検知ルールの作成、編集、有効化、無効化、例外の追加などを履歴として確認できます。変更前後の差分表示と、過去状態への復元も可能です。 例えば、例外条件を広く設定しすぎてルールが発火しなくなった場合でも、どの変更が原因だったかを追いやすくなります。 注意点 Attack Discoveryのエージェント的な調査では、複数回のLLM呼び出しとツール実行が発生します。調査品質だけでなく、トークン費用、データ送信先、機密情報の扱いを確認してください。 また、AIが作成したES|QLルールは、構文が正しくても、自社のログに必要なフィールドが存在しない、誤検知が多いといった可能性があります。人間によるテストとレビューは必要です。 なお、Agent BuilderとWorkflowsを使った新しいAttack Discoveryの動作は、詳細設定で有効化する必要があり、9.5では既定でオフです。 要点 ：SecurityのAIは、アラートを説明する段階から、証拠を探して調査を支援する段階へ進もうとしています。 その他のGA機能 Dashboards API Kibana Dashboardを構造化されたJSONとして作成・更新できます。Gitでの差分管理、レビュー、CI/CDによる環境間展開が行いやすくなります。 ただし、すべてのパネルタイプをAPIだけで扱えるわけではありません。既存Dashboardをコード管理へ移す場合は、対応パネルを確認してください。 Cases as Data ケース情報を分析用インデックスへ同期し、Discover、Lens、ES|QL、Dashboardから分析できます。 これにより、ケース件数、クローズ率、対応時間、担当者ごとの負荷などを確認できます。更新はリアルタイムではなく、反映に時間差がある点に注意してください。 どの機能から試すべきか GA機能で優先度が高いもの 現在の課題 最初に確認する機能 PrometheusやGrafanaから移行したい PromQL対応と移行CLI Dashboardを環境間で管理したい Dashboards API SOCの対応時間や負荷を測りたい Cases as Data Workflowの変更が怖い バージョン管理 検知ルールの変更原因を追えない 検知ルール変更履歴 検証環境で試すTech Preview 現在の課題 検証する機能 ログの保存費用が高い Columnar Logs ベクトル検索の設定が難しい VectorDB index mode / Auto-calibration 画像やPDFを意味で検索したい semanticフィールド Agent Builderの遅延や費用が分からない Agent Builder tracing Tech Previewでは、既存環境を直接変更するのではなく、小さな新規インデックスや限定したデータセットで比較するのが安全です。 まとめ Elastic 9.5は、次の3つの方向へ進んだリリースと整理できます。 データ保存を効率化する Columnar Modeにより、大量ログを分析と長期保存へ最適化します。 検索とAIの構築作業を減らす VectorDB index mode、Auto-calibration、マルチモーダルsemanticフィールドにより、ベクトル検索の開始を簡単にします。 AIと自動化を運用できる形にする Agent Builder tracing、Workflowのバージョン管理、Human-in-the-loop、検知ルール変更履歴により、AIと自動化を監視・修正・監査しやすくします。 そのほかにも、KubernetesとAWSのオンボーディングでは、推奨されるOpenTelemetry経路を使ってセットアップが簡素化、APMのService Map改善、LLM ObservabilityのAnthropic対応が追加されています。Elastic Defendでは、脆弱なドライバーに対する予防的保護、Windows on ARM対応、エンドポイントのトラブルシューティングスキルが追加されました。Workflowsでは、Slackなどの外部ツールから承認することもできます。 GA機能は既存運用への適用を検討し、Tech Previewは将来の設計判断に向けて小さく検証するのがよいでしょう。 参考資料 Elastic 9.5公式リリースブログ Columnar Mode dense_vector field type semantic field type Agent Builder traces PromQL overview PromQL limitations Elastic Workflows Attack Discovery Detection rule changes history Cases as Data The post Elastic 9.5の新機能を速報解説：保存、ベクトル検索、AI運用はどう変わるのか first appeared on Elastic Portal .

目次 この記事でやりたいこと 使ったデータ:強震観測CSVが57行 ダッシュボードは3枚に分けた ダッシュボード1:活動概要・時間再生 ダッシュボード2:M7.1地震後の活動分析 記録は、M7.1の直後の数時間に集中していた 記録件数が少なくなった時間帯にも、比較的大きな地震が含まれていた ダッシュボード3:規模と観測された揺れ マグニチュードと「実際の揺れ」は別物 「強い揺れ」は、どの物差しで測るかで順位が変わる 正直に言うと:データには限界がある 可視化の先へ:継続監視と対応につなげる ライブ監視:データを「流し込み続ける」 機械学習:「予知」のためではなく「防災対応」のために アラートとケース:気づきを「対応」につなげる まとめ:可視化は入り口だった 参考資料 この記事でやりたいこと 2026年7月28日に熊本で発生したM7.1の地震(気象庁の正式名称は「令和8年熊本地震」)の観測データを取り込んでダッシュボードを作ってみました。 先に言っておくと、この記事で地震の専門的な話をするつもりはありません。やりたいのはその逆で、 Elasticという製品を、防災系のデータにどこまで使えるのかを実際に試してみる ことです。 題材に地震を選んだのは、過去に地震関連の仕事に関わった経験があるからです。ある程度知識や経験のある分野なら、「Elasticで可視化したときに、本当に何かが見えてくるのか」を自分の感覚で確かめられると思いました。 この記事では、次の2つをお伝えします。 小さなCSVでも、問いごとに可視化を組み立てることで、表を眺めるだけでは見つけにくい関係が見えてくること そして本当の価値は、その先のライブ監視・機械学習・アラート・情報共有にあること 使ったデータ:強震観測CSVが57行 使ったのは、防災科研の強震観測網(K-NET・KiK-net)の記録をまとめた、2026年7月分のCSVです。中身はこんな項目です。 地震の発生時刻 緯度・経度・震源の深さ マグニチュード 最大加速度(gal)・最大速度(cm/s)・最大計測震度 観測点数 全部で57件。Excelで開けるくらいの、ごく小さなデータです。 ひとつ大事な注意があります。 このCSVは熊本周辺で発生した全地震の一覧ではなく、強震観測データとして公開された地震をまとめたものです。 気象庁は7月30日15時時点で、M7.1の本震発生後、震度1以上を観測した地震が270回発生したと発表しています。この記事で「45件」「57件」と書くときは、すべて「このCSVに含まれる記録の件数」を指しています。 取り込みはKibanaのファイルアップロード機能を使いました。CSVをドラッグするとElasticが項目の型を推測してくれるので、修正したのは2か所だけです。IDの項目を検索用の型(keyword)に直したことと、緯度・経度から地図用のgeo_pointフィールドを作ったことです。 つまり、CSVの取り込みと初期マッピングでは、スクリプトを1行も書いていません。 ダッシュボードは3枚に分けた 熊本周辺(緯度・経度で四角く絞った範囲)の45件を、話の流れごとに3枚のダッシュボードに分けました。 活動概要・時間再生 — 全体像をつかみ、時間を追って再生する M7.1地震後の活動分析 — 記録が時間とともにどう変わったか 規模と観測された揺れ — マグニチュードと実際の揺れの関係 最初は1枚に全部詰め込んでいましたが、「1枚 = 1つの問い」に分けたほうが、見る人が迷いません。順番に紹介します。 ダッシュボード1:活動概要・時間再生 1枚目は、地図とタイムスライダーが主役です。 上の動画でご覧いただけるように、ダッシュボードの上段に「表示中の地震件数・最大マグニチュード・最大計測震度・最大加速度」のカードを並べ、タイムスライダーを動かすと、その時間帯の値と地図上の震源が連動して切り替わります。再生ボタンを押せば、M7.1の地震(7月28日16:27)のあと、記録がどこに現れていったかを、アニメーションのように追えます。 たとえばスライダーを3時間後の19時台に合わせると、カードは「5件・最大M4.2・最大計測震度3.8・90.5 gal」に変わります。M7.1の時間帯(計測震度6.3・1,667.4 gal)と見比べると、数時間で数字が大きく変わったことが分かります。 galのような専門用語は、隣にテキストパネルを置いて説明しています。ダッシュボードは「グラフ置き場」ではなく「読み物」として作る。これはブログに載せる前提だからこそ意識した点です。 動画のように時間を追って変化を見るのではなく、対象期間のすべての地震を最初から一度に表示した状態が以下の画面です。 ダッシュボード2:M7.1地震後の活動分析 2枚目は「時間の流れ」に注目した1枚です。ここで2つのことが見えてきました。 記録は、M7.1の直後の数時間に集中していた 今回使用した強震観測CSVに含まれる熊本周辺の45件を見ると、記録件数はM7.1の地震直後に集中し、その後は少なくなっていました。1時間ごとの棒グラフでは直後の17時台が最多の10件で、CSV内の累積記録数の折れ線も最初の数時間で一気に立ち上がり、その後はほぼ横ばいです。 念のため繰り返すと、少ないデータセットのためこれは「地震活動全体が急減した」という断定ではなく、「このデータセット上では減少して見えた」ということです。それでも、自分のデータで、自分の作ったグラフで傾向を確認できると、納得感がまったく違います。 記録件数が少なくなった時間帯にも、比較的大きな地震が含まれていた ここが一番おもしろかった発見です。 CSV内の記録件数が少なくなった約30時間後の時間帯にも、M7.1の地震の震央から約36km離れた場所で発生したM5.8という比較的大きな地震が含まれていました。 これは、記録件数の棒グラフに「1時間ごとの最大マグニチュード」の折れ線を重ねたことで見つけられました。件数だけを見ていた場合、このM5.8の地震を見落としていたかもしれません。 さらに、KibanaのVegaを使って「M7.1地震からの経過時間 × 震央からの距離」の散布図を作りました。この図から、M5.8の地震が本震から時間的にも距離的にも離れた位置にあることを確認できます。 ダッシュボード3:規模と観測された揺れ 3枚目は「規模(マグニチュード)と、観測された揺れは同じものなのか?」という問いの1枚です。ここでも2つのことが見えました。 マグニチュードと「実際の揺れ」は別物 マグニチュード(地震そのものの規模)と最大計測震度(観測された揺れの強さ)を散布図にすると、全体としては右肩上がりですが、同じM4前後でも計測震度は約1.2から4.0までばらついていました。 マグニチュードと最大加速度の散布図でも同じことが見えます。縦軸を対数(10倍ごとの目盛り)にすると、マグニチュードが上がるにつれて加速度がケタ違いに大きくなっていく傾向と、同じマグニチュードでの大きなばらつきが、両方読み取れます。 gal（ガル）とは？ 揺れの「瞬間的な勢い（加速度）」を表す単位です。1 galは「1秒間に秒速1センチ」スピードが変化することを意味します。 身近な例では、車の 急発進や急ブレーキ で体が前後に持っていかれるときの強い衝撃が 約600〜1,000 gal （0.6〜1.0G）です。今回のM7.1の記録（1,667.4 gal）は、日常で体験する急ブレーキ以上の暴力的な衝撃が、地面そのものから加わったことを示しています。 ここで、数値について正確に書いておきます。今回使用したK-NET・KiK-netのCSVでは、M7.1の地震の最大計測震度は6.3で、震度階級では6強に相当します。一方、気象庁が発表した最大震度は7です。観測網や観測地点が異なるため、最大値は必ずしも一致しません。 また、CSVには速報段階の震源深さ「約10km」が入っていますが、気象庁の暫定値では後に16kmへ更新されています。 「規模が同じでも揺れは同じではない」。教科書に書いてあることですが、散布図が一目でそれを語ってくれます。 「強い揺れ」は、どの物差しで測るかで順位が変わる CSVには最大加速度(揺れの鋭さ)と最大速度(揺れの動きの速さ)という、2つの「揺れの物差し」が入っています。この2つを両対数の散布図にすると、全体として右肩上がりの関係が見られます。 おもしろいのは、この全体的な傾向から外れる地震があることです。今回のデータでは、 M6.1の地震:加速度 312.6 gal、速度 21.6 cm/s M5.8の地震:加速度 554.3 gal、速度 6.0 cm/s M5.8のほうが加速度は約1.8倍大きいのに、速度は3分の1以下でした。このCSVに記録された最大値を比較すると、最大加速度ではM5.8が上ですが、最大速度ではM6.1が上でした。つまり、最大加速度と最大速度では、地震の並び順が逆転します。 ただし、最大値を記録した観測点は地震ごとに異なる可能性があるため、この数字だけで地震全体の揺れや被害の大きさを判断することはできません。 この違いの原因(揺れの周期や地盤など)を特定するのは専門家の仕事です。ただ、「傾向から外れた点がある」と気づくところまでは、散布図を作るだけで誰でもたどり着けます。 可視化の役割は答えを出すことではなく、良い問いを見つけることなのだと思います。 正直に言うと:データには限界がある 見えてきたことがある一方で、見えないこともあります。今回のデータは座標が0.1度単位です。震源の深さも公表用の丸められた値で、5km未満は「ごく浅い」、それ以外は「約10km」「約20km」という表現になります。そして先に書いたとおり、このCSVは全地震の一覧ではありません。なので「断層がどう動いたか」のような専門的な分析はできませんし、するべきでもありません。 大事なのは、可視化ツールは「分かること」と同時に「分からないこと」も教えてくれる、という点です。3枚のダッシュボードすべてに注意書きパネルを置いて、読み手が結論を出しすぎないようにしました。 可視化の先へ:継続監視と対応につなげる ここまでは1枚のCSVを可視化した話でした。正直、これだけならBIツールでもできます。 Elasticが本領を発揮するのはここからです。今回は静的なデータで試しましたが、同じ仕組みのまま、ライブ監視・機械学習・アラート・情報共有へ広げられます。 ライブ監視:データを「流し込み続ける」 今回は手動でCSVを入れましたが、Elasticは本来、ログやセンサーデータを絶え間なく受け取り続けるための製品です。同じフィールド構成で観測データを継続的に取り込めば、今回作ったダッシュボードを大きく作り直すことなく、「今起きていること」を映す画面として再利用できます。 過去の分析画面とリアルタイム監視画面がほぼ同じもの。ここがElasticの設計の気持ちよさです。 機械学習:「予知」のためではなく「防災対応」のために Elasticには異常検知(Anomaly Detection)という機械学習機能があります。データの「普段のパターン」を自動で学習し、そこから外れた動きを検知してくれます。先にはっきりさせておくと、目的は「地震を予知すること」ではありません。気象庁も、地震の時期・場所・規模を高い確度で予測することは現在の科学では困難だとしています。機械学習の役割は、観測されたデータの異常な変化を早く見つけて、防災対応を支援することです。 ただし正直に書くと、今回の45件・約54時間の記録だけでは、信頼できるモデルを作るには足りません。異常検知は「通常状態」を学習してこそ機能するので、通常時を含む十分な継続データが必要です(必要な期間は、データの頻度や周期性によって変わります)。 継続データがあれば、たとえば地震件数が普段より急増した時間帯の検知や、観測点からデータが届かなくなる「欠測」の検知に使える可能性があります。災害時に「異常がない」のか「観測できていないだけ」なのかを区別できるのは、防災上大きな意味があります。なお、毎分必ずデータが届くような固定周期のセンサーなら、まずは機械学習ではなく「データが来ていない」という単純なルールで監視するほうが安価で説明もしやすく、通常件数が大きく変動する場合に機械学習を検討する、という順番が現実的です。具体的な検知の設定は、別記事で紹介する予定です。 十分な過去データをElasticに蓄積すれば、まず深さや地域ごとに地震件数、平均マグニチュード、最大加速度などを集計し、「この地域では普段どのような記録が多いのか」を確認できます。 緯度・経度をElasticのgeo_pointとして保存しておけば、震源を地図に表示するだけでなく、特定地点からの距離や指定した地域で絞り込み、地域ごとの件数や平均値を比較できます。地図を格子状のエリアに分ければ、「この地域では浅い地震が多い」「この範囲では観測された揺れが比較的大きい」といった空間的な傾向も見つけやすくなります。 そのうえで機械学習を使うと、過去の傾向を通常状態として学習し、普段とは異なる件数の増加、値の変化、発生場所の変化などを検知できます。ただし、これは地震の発生を予知するものではなく、観測済みデータから通常とは異なる動きを早く見つけるためのものです。 ※機械学習や一部の通知機能の利用可否は、Elasticの契約プランやデプロイ方式によって異なります。 アラートとケース:気づきを「対応」につなげる 異常を検知したら、Elasticのルールでアラートを生成し、メールやSlackなどへの通知を自動実行できます。さらにKibanaのケース(Cases)機能を使えば、検知したイベントを起票して、関連するグラフやコメントを添えてチームで対応状況を追跡できます。「誰が何に気づいて、どう判断したか」が製品の中に残ります。 ダッシュボードは、開いていなければ変化に気づけません。一方、アラートなら、異常を検知したタイミングで担当者へ通知できます。ここまでつながって初めて、Elasticは単なる可視化ツールではなく、 異常発見から初動判断までの基盤 になります。 まとめ:可視化は入り口だった 今回は57行のCSVをElasticに取り込み、そのうち熊本周辺に絞った45件を3枚のダッシュボードで分析しました。それでも、このデータセットの範囲で、 記録はM7.1の直後の数時間に集中していた 記録件数が少なくなった時間帯にも、M5.8の比較的大きな地震が含まれていた 規模(マグニチュード)と観測された揺れは同じではない 「強い揺れ」の順位すら、測る物差しで変わる という4つのことが読み取れました。 そしてこの土台は、そのままライブ監視・異常検知・アラート・チームでの情報共有につながっています。地震を予知するためではなく、異常にいち早く気づき、防災対応を支援するための基盤として。 最後にもう一度だけ。可視化の役割は、答えを出すことではなく、良い問いを見つけることです。今回の3枚のダッシュボードも、答えを出してはいません。でも「なぜこの地震だけ加速度が大きいのか?」という、次に専門家へ持っていける問いを残してくれました。 もし手元に「数字の羅列のままになっているデータ」があれば、まずKibanaにドラッグしてみてください。最初の取り込みと基本的な可視化なら、プログラムを書かずに始められます。そこから必要に応じてVegaやES|QLへ広げられます。 参考資料 謝辞 本記事では、防災科学技術研究所が公開する強震観測網K-NET・KiK-netのデータを利用しました。 防災科学技術研究所（2019）「防災科研K-NET・KiK-net」DOI: 10.17598/NIED.0004　貴重な観測データをご提供いただき、感謝申し上げます。 気象庁 よくある質問「地震の予知はできるのですか」 https://www.jma.go.jp/jma/kishou/know/faq/faq24.html 令和8年熊本地震について（第5報） https://www.jma.go.jp/jma/press/2607/30a/kaisetsu202607301600.pdf Elastic公式ドキュメント:Kibanaのファイルアップロードとgeo_pointフィールドの作成　 https://www.elastic.co/docs/explore-analyze/visualize/maps/import-geospatial-data Elastic公式ドキュメント:Anomaly detectionのCount functions(high_count / low_count)　 https://www.elastic.co/docs/reference/machine-learning/ml-count-functions Elastic公式ドキュメント:Alerting(ルールからメール・Slackなどへ通知)　 https://www.elastic.co/docs/explore-analyze/alerting The post 2026年熊本地震の強震観測データを可視化して見えたこと first appeared on Elastic Portal .

Elastic Securityで検知ルールを有効にしたあと、こんな不安を感じたことはないでしょうか。 ルールはたくさん動いている。でも、これで本当に守れているのだろうか。 ルール一覧では、それぞれのルールを個別に確認できます。しかし、ルール全体が攻撃者のどのような行動を対象にしているのかを、ひと目で把握するのは簡単ではありません。 ここで使う道具が、MITRE ATT&CKです。Elastic Securityには、検知ルールをATT&CKという地図の上に並べて見せる「MITRE ATT&CK coverage」という画面があります。 この記事で扱うのは、次の内容です。 MITRE ATT&CKとは何か Tactic、Technique、Sub-techniqueの違い ATT&CK Matrixは攻撃の順番表ではないこと Elastic Securityの検知ルールとATT&CKの関係 coverage画面の読み方 画面の色が意味すること、意味しないこと 目次 MITRE ATT&CKとは何か ATT&CKが並べているのは「行動」 Tactic、Technique、Sub-technique ATT&CK Matrixは順番表ではない なぜElastic SecurityでATT&CKを使うのか Elastic SecurityのルールとATT&CKの関係 coverage画面の読み方 表示されないルールもある 色が意味すること、意味しないこと 例：Valid Accountsのセルに色が付いていても 補足：AIシステムの脅威にはMITRE ATLASも使われる まとめ 参考資料 MITRE ATT&CKとは何か MITRE ATT&CKは、実際の攻撃で観測された攻撃者の行動を整理したナレッジベースです。一言でいうと、攻撃者が何を目的に、どのような方法を使うのかをまとめた共通の地図です。 なぜ共通の地図が必要なのでしょうか。製品や組織が違うと、同じ攻撃を別の言葉で説明してしまうからです。ある製品は「不正ログイン」と呼び、別の製品は「アカウント悪用」と呼びます。話しているうちに、同じ話をしているのか違う話をしているのか分からなくなります。 ATT&CKを使うと、製品に依存しない共通の言葉で話せます。 攻撃者は、盗んだクラウドアカウントを使って環境へ侵入した。これは T1078.004: Cloud Accounts に関係する。 この T1078.004 のような番号を ATT&CK ID と呼びます。IDを使えば、チームや製品をまたいでも、同じ攻撃手法について正確に話せます。 なお、ATT&CKにはEnterprise、Mobile、ICS（Industrial Control Systems：工場などの産業制御システム）などの分野があります。この記事で扱うのは、企業のIT環境やクラウド環境を対象にしたEnterprise ATT&CKです。 ATT&CKが並べているのは「行動」 ATT&CKが整理している中心的な対象は、特定のハッシュ値やIPアドレスではなく、攻撃者が行った行動です。 補足として、攻撃者に行動そのものを変えさせるほうが、IPアドレスやハッシュ値を変更させるより難しい、という考え方があります。 Tactic、Technique、Sub-technique ATT&CKには階層があります。最初は、次の3つだけ覚えれば十分です。 階層 階層 例 Tactic（タクティクス） 攻撃者が達成したい目的。「なぜ行うか」 Initial Access Technique（テクニック） 目的を達成するための方法。「どうやるか」 T1078: Valid Accounts Sub-technique（サブテクニック） Techniqueをさらに具体化した方法 T1078.004: Cloud Accounts 具体例で見てみます。攻撃者が、盗んだクラウドアカウントを使って環境へ侵入したとします。 目的：環境へ侵入する → Initial Access 方法：正規のアカウントを悪用する → T1078: Valid Accounts 具体的な対象：クラウドアカウント → T1078.004: Cloud Accounts TacticはWhy、TechniqueはHow、Sub-techniqueはもっと具体的なHowだと考えると、区別しやすくなります。 ATT&CK Matrixは順番表ではない ATT&CK Matrixは、列がTacticになった表です。左から Reconnaissance、Resource Development、Initial Access と並ぶため、攻撃が左から右へ順番に進むように見えます。しかし、実際の攻撃はその順番では進みません。 一部の段階を飛ばす 前の段階へ戻る 同じTechniqueを別の目的で使う 1つのTechniqueが複数のTacticに関係する 例えば T1078: Valid Accounts は、侵入の入口としてのInitial Access、居座るためのPersistence、権限を上げるためのPrivilege Escalationなど、複数のTacticに関係します。同じ「正規アカウントの悪用」でも、攻撃者の目的が違えば置かれる列が変わるということです。 そのためMatrixは、攻撃の決まった手順書ではありません。攻撃者の行動を分類して並べた地図として読むのが適切です。 なぜElastic SecurityでATT&CKを使うのか 理由は、ルール一覧では見えにくいものが見えるようになるからです。ルール一覧はルールを1件ずつ確認する画面です。ATT&CKを使うと、同じルールを攻撃者の行動という軸で並べ替えられます。 セキュリティ運用では、次のような目的で使います。 現在の検知ルールが、どの攻撃手法を対象にしているか確認する 監視できていない領域を見つける 次に収集するログや、追加する検知を検討する ここで大事なのは、ATT&CKが「すべてのマスを埋めるための表」ではないことです。自社に関係する攻撃手法を選び、そこに必要なログ、検知、予防策を考えます。ATT&CKは、そのために使う道具です。 Elastic SecurityのルールとATT&CKの関係 Elastic Securityの検知ルールには、 Threatメタデータ を設定できます。これは、そのルールがどのTactic、Technique、Sub-techniqueに関係するかを示す情報です。 prebuilt rule（Elasticが提供する既製ルール）には、あらかじめATT&CKマッピングが設定されている Custom rule（自組織で作成したルール）には、作成・編集時にAdvanced settingsからマッピングを追加できる 例えば、次の行動を検知するルールがあるとします。 PowerShellを使って、Base64でエンコードされたコマンドを実行する。 このルールには、実際の検知条件（クエリ）だけでなく、関連するATT&CKのTacticやTechniqueも設定されています。Elastic Securityはこのマッピングを読み取り、各ルールをATT&CK Matrix上へ配置します。これが、coverage画面のしくみです。 coverage画面の読み方 Kibanaで次の画面を開きます。ナビゲーションメニューから探すほか、グローバル検索で「MITRE」と入力しても見つかります。 Security >> Detection rules (SIEM) >> MITRE ATT&CK coverage 画面は、大きく4つのパートに分かれています。 フィルター ：どのルールを集計に含めるかを決める 検索バー ：Tactic名、Technique名、Technique番号、ルール名で絞り込む Legend ：セルの色が何件のルールを表すかを示す凡例 グリッド ：Tacticの列と、Techniqueのセルが並ぶ本体 Elastic rules（prebuilt rule）、Custom rules（自組織で作成したルール）、またはその両方 ：Enabled rules（有効なルール）、Not enabled rules（未有効のルール）、またはその両方 基本的な読み方は次のとおりです。 列 ：Tactic セル ：Technique セルの濃さ ：現在のフィルター条件に一致し、そのTechniqueへマッピングされたルールの数 濃いセルには、条件に一致するルールが多くあります。白いセルには、条件に一致するルールがありません。色の基準は画面上部のLegendで確認できます。 出典：elasticの公式ドキュメント セルには、Technique名と、有効なルールがカバーするSub-techniqueの数が表示されます。Expand cellsを選ぶと、有効なルール数と未有効（Not enabled）のルール数も表示されます。セルをクリックすると、関連するルールやTechniqueの詳細を確認できます。 表示されないルールもある coverage画面に表示されるのは、次の条件を満たすルールだけです。 現在のKibana Space（Kibanaの中で設定を分離できる作業領域）にインストールされている ATT&CKへマッピングされている 画面のフィルター条件に一致している したがって、まだインストールしていないprebuilt ruleや、ATT&CKマッピングを設定していないCustom ruleは表示されません。 なお、coverage画面が参照するATT&CKのバージョンは、Elastic Securityのバージョンによって決まります。MITRE公式サイトとKibanaでTactic名が違って見える場合は、この差が原因です。表示不具合ではありません。 色が意味すること、意味しないこと ここが、この記事でいちばん伝えたい点です。冒頭の不安に戻ります。「セルに色が付いていれば安全なのか」。答えは、いいえです。 coverage画面は、ルールのATT&CKメタデータを使った配置図です。色が付いていても、次のことは何も証明されません。 必要なログが実際に届いている ルールが正常に動いている その攻撃を確実に検知できる 誤検知が少ない Technique全体を網羅している 自組織が安全である 例を挙げます。Windowsのログを必要とするルールをインストールして有効にすれば、対応するセルには色が付きます。しかし、その環境にWindowsログを取り込んでいなければ話は変わります。セルは色付きのままですが、必要なWindowsログが届いていないため、そのルールは期待したアラートを生成できません。 coverage画面から直接分かる中心的な情報は、次のとおりです。 「インストール済みのルールが、ATT&CK Matrixのどのセルに置かれているか。」 言い換えると、coverage画面が答えているのは「このルールは何を狙った検知か」という分類の問いです。「このルールは今ちゃんと動いているか」という実効性の問いには答えません。 反対側も同じです。白いセルは「現在の条件では、そのTechniqueへマッピングされた表示対象のルールがない」ことを示すだけです。ただちにセキュリティ上の欠陥を意味するものではありません。 例：Valid Accountsのセルに色が付いていても Techniqueは大きな分類です。そのため、同じTechniqueへマッピングされた複数のルールが、同じ攻撃を監視しているとは限りません。 T1078: Valid Accounts は、攻撃者が正規のアカウントを悪用するTechniqueです。ただし、正規アカウントの悪用にはさまざまな形があります。 Windowsアカウントで端末へログインする VPNアカウントで社内ネットワークへ接続する AWS IAMユーザーでコンソールへログインする Microsoft 365アカウントでメールへアクセスする これらはすべてValid Accountsに関係します。ただし、必要なログも検知条件もまったく異なります。 自組織が心配している攻撃を、次のように想定します。 → 海外の不審なIPアドレスから、Microsoft 365の管理者アカウントへログインされる。 一方、coverage画面で「Potential Account Takeover – Logon from New Source IP」というルールを見つけたとします。おおまかにいうと、このルールはWindows Security Event Logの成功ログオンを調べ、同じユーザーが普段とは別の送信元IPからログオンしたパターンを探します。 どちらもValid Accountsに関係します。しかし、監視している対象は違います。 確認項目 自組織が心配する攻撃 見つけたルール 対象 Microsoft 365の管理者アカウント Windowsアカウント 必要なログ Entra ID（旧Azure AD）などのサインインログ Windows Security Event Log 結論 クラウド用の検知が必要 Microsoft 365へのクラウドサインインは監視できない このルールをインストールして有効にすると、coverage画面のValid Accountsセルには色が付きます。 しかし、心配していたクラウドアカウントへの攻撃は監視できていません。このルールが見ているのは、Microsoft 365やEntra IDへのクラウドサインインではなく、Windows Security Event Logに記録されたログオンだからです。 そのためATT&CK IDは、関連するルールを探すための入口として使います。最終的な判断は、そのルールがどのログを読むか、どのプラットフォーム向けか、どの行動を怪しいと判断するかを見て行います。 補足：AIシステムの脅威にはMITRE ATLASも使われる MITRE ATLASは、AIや機械学習システムを狙う攻撃者の行動を整理したナレッジベースです。ATT&CKと同じように、攻撃者の目的や手法をTacticとTechniqueで整理しています。扱うのは、モデルの窃取、プロンプトインジェクション、モデルへの不正な操作など、AIシステム特有の脅威です。 Elastic Securityのprebuilt ruleには、ATLASに関連付けられたルールもあります。例えば「Potential Azure OpenAI Model Theft」というルールには Mitre Atlas: T0044 というタグが設定されています。このルールは、Azure OpenAIのモデルが不正に取得・複製される可能性のある操作を監視します。 ATT&CKとATLASの両方に関係するルールもあります。外部ネットワークからOllama APIへ接続されたことを検知するルールには、次の情報が設定されています。 MITRE ATT&CK：Initial Access、External Remote Services、Exploit Public-Facing Application MITRE ATLAS：T0040、T0044 AIシステムへの攻撃であっても、外部公開されたサービスへの侵入という従来のサイバー攻撃と、モデル窃取というAI固有の脅威が重なる場合があるためです。 Add Elastic rules画面でTagsを開き、atlas と検索すると、ATLASに関連するルールを絞り込めます。 まとめ MITRE ATT&CKの基本 ATT&CKは、攻撃者の行動を共通の言葉で整理した地図である TacticはWhy、TechniqueはHow、Sub-techniqueはその具体化を表す Matrixは順番表ではない。1つのTechniqueが複数のTacticに関係する Elastic Securityのcoverage画面 Elastic Securityは、検知ルールのThreatメタデータを読み、ルールをMatrix上へ配置する セルの濃さは、現在の条件に一致するルール数を示す 色が付いていても、必要なログの有無や検知の実効性は保証されない 白いセルは、現在の条件で表示対象のルールがないことを示すにすぎない 同じTechniqueでも、対象プラットフォームや必要なログは違う 冒頭の不安に、あらためて答えます。coverage画面は、守れているかどうかを判定してくれる画面ではありません。「うちの検知は、攻撃者のどのような行動を見ているのか」を共通の言葉で並べてくれる画面です。 まずは、この読み方に慣れることから始めてみてください。読めるようになると、次の一歩、つまりルールを有効にする手順や、白いセルを見つけたあとの確認へ進めます。 参考資料 本記事は、以下の公式ドキュメントに基づいています。 Elastic公式ドキュメント MITRE ATT&CK coverage https://www.elastic.co/docs/solutions/security/detect-and-alert/mitre-attack-coverage Prebuilt rule components https://www.elastic.co/docs/solutions/security/detect-and-alert/prebuilt-rule-components Install and manage Elastic prebuilt rules https://www.elastic.co/docs/solutions/security/detect-and-alert/install-prebuilt-rules MITRE MITRE ATT&CK 公式サイト https://attack.mitre.org/ Enterprise Tactics https://attack.mitre.org/tactics/enterprise/ Enterprise Techniques https://attack.mitre.org/techniques/enterprise/ T1078: Valid Accounts https://attack.mitre.org/techniques/T1078/ MITRE ATLAS https://atlas.mitre.org/ 関連内容 The Pyramid of Pain（David J. Bianco, 2013） https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html The post Elastic Securityを使い始めた人のためのMITRE ATT&CK入門 first appeared on Elastic Portal .

Elastic Stack（ELKスタック）を導入する際、多くのエンジニアが最初に頭を悩ませるのが「データの収集・加工（前処理）に何を使うか」という問題です。 かつては「前処理といえばLogstash」の一択でしたが、Elasticsearchに  Ingest Pipeline  が実装されて以降、その手軽さとパフォーマンスから強力な選択肢となっています。 本記事では、LogstashとIngest Pipelineのアーキテクチャの違い、機能面での優劣、そして「結局どちらを選ぶべきか」の判断基準を技術者視点で解説します。 目次 1. LogstashとIngest Pipelineの概要 Logstash とは？ Ingest Pipeline とは？ 2. 4つの軸で見る決定的な違い ① 入出力の柔軟性（Inputs & Outputs） ② データの加工・拡充能力（Transformation） ③ 耐障害性とバッファリング（Queueing） ④ インフラ構成と運用コスト 3. 【結論】どちらを選ぶべきか？ ユースケース別の推奨 ✅ Ingest Pipeline を選ぶべきケース ✅ Logstash を選ぶべきケース 💡 比較サマリー 💡 ハイブリッド構成（併用）という選択肢も まとめ 1. LogstashとIngest Pipelineの概要 比較に入る前に、それぞれの立ち位置を簡単におさらいしておきましょう。 Logstash とは？ データ処理パイプラインを構築するための独立した外部サーバー（コンポーネント）です。豊富なプラグイン（Input / Filter / Output）を備え、多様なデータソースからデータを吸い上げ、複雑な加工を施した上で、Elasticsearchをはじめとする様々な宛先にデータを送信できます。 Ingest Pipeline とは？ Elasticsearchのクラスタ内部（Ingestノード）で動作する  前処理機能です。データがElasticsearchにインデックス（格納）される直前に、JSON形式のドキュメントに対して「プロセッサ」と呼ばれる処理を数珠つなぎに適用してデータを加工します。 2. 4つの軸で見る決定的な違い 2つのコンポーネントの特性を、「入出力」「データ加工能力」「耐障害性」「運用コスト」の4つの軸で比較します。 ① 入出力の柔軟性（Inputs & Outputs） Logstash: 圧倒的な柔軟性を持ちます。HTTPやSyslogなどのPush型だけでなく、リレーショナルデータベース（JDBC）やメッセージキュー（Kafka, RabbitMQ）からデータを自発的に取得（Pull）できます。また、加工したデータをElasticsearchに送りつつ、同時にS3へ生ログをアーカイブする、といった マルチ出力 が可能です。 Ingest Pipeline: あくまですべての処理が「Elasticsearchにデータが書き込まれるタイミング」で動作するため、外部へデータを読みに行くことはできません。Beatsやアプリケーションからデータを「Push」してもらう必要があります。また、出力先もパイプラインが動いているElasticsearch自身に限定されます。 ② データの加工・拡充能力（Transformation） Logstash: 条件分岐（if-else）のネストや、Rubyプラグインを用いたコードレベルでの柔軟な記述が可能です。また、処理中に外部のファイルやデータベースを参照してデータを補完（エンリッチ）する処理も得意です。 Ingest Pipeline: Grok、GeoIP、JSONなどの主要なプロセッサが標準搭載されており、一般的なログ（Apache, Nginx, システムログなど）のパースであれば十分すぎる性能を持っています。 enrich  プロセッサを使えばElasticsearch内の別インデックスを参照したデータ拡充も可能ですが、Logstashほど外部システムと密に連携した複雑な加工はできません。 ③ 耐障害性とバッファリング（Queueing） Logstash: 永続的キュー（Persistent Queues）を内蔵しています。Elasticsearch側が一時的なスパイクやメンテナンスでデータを受け付けなくなっても、Logstashがローカルディスクにデータを安全にバッファリングし、データロストを防ぎます。 Ingest Pipeline: 自身にデータを溜めるディスクキューはありません。Elasticsearchのインデキシング負荷が高くなると、データ送信元（Beatsなど）に対して「これ以上送らないでくれ」というバックプレッシャーをかけます。送信元がバッファを持っていない場合、データロストの追跡や再送管理を送信元側で担保する必要があります。 ④ インフラ構成と運用コスト Logstash: 独立したプロセス（JVM）として動くため、メモリやCPUの設計、パッチ当て、監視などの運用コストが上乗せされます。ただし、データ処理の負荷をElasticsearchクラスタから完全に分離できるというメリットもあります。 Ingest Pipeline: 新たにサーバーを構築する必要がありません。KibanaのUIやREST APIからJSON定義を投入するだけで即座にデプロイ・変更が可能です。運用は非常にシンプルになりますが、重いパース処理（複雑なGrokなど）が大量に走ると、Elasticsearch自体のリソース（検索やインデックス性能）を圧迫するリスクがあります。 3. 【結論】どちらを選ぶべきか？ ユースケース別の推奨 システム要件や現在の構成に合わせて、インフラエンジニアは以下の基準で選択することをお勧めします。 ✅ Ingest Pipeline を選ぶべきケース 「シンプルさ」と「スピード」を最優先する場合 データソースが  Elastic Agent  や  Beats  に統一されており、直接ElasticsearchにデータをPushできる。 ログの加工要件が、タイムスタンプの整形や不要フィールドの削除、シンプルなGrokパース程度である。 これ以上、管理対象のサーバーやコンポーネント（ミドルウェア）を増やしたくない。 ✅ Logstash を選ぶべきケース 「複雑なパイプライン」や「大規模・多様な環境」を管理する場合 データベース（SQL）やKafka、サードパーティのAPIなど、 多種多様な場所からデータをPullで収集 する必要がある。 受け取ったデータをElasticsearchだけでなく、 S3や別のオブジェクトストレージにも同時にバックアップ したい。 パース処理が非常に複雑で、Elasticsearchの検索・インデックス性能に影響を与えたくない（負荷を分離したい）。 データの突発的なスパイクに備え、堅牢なディスクバッファリング（永続的キュー）が必須である。 💡 比較サマリー 比較項目 Logstash Ingest Pipeline 配置・アーキテクチャ 独立した外部サーバー（JVM） Elasticsearchクラスタの内部（Ingestノード） 入力（データ収集） 自由度：高 （Pull型、Push型、各種DB、MQ対応） 自由度：低 （ElasticsearchへのPushのみ） 出力（データ送信） マルチ出力対応 （ES、S3、Kafka、ファイル等） Elasticsearch内部のみ キュー・バッファリング 内蔵（Persistent Queuesによるデータロスト防止） なし（送信元にバックプレッシャーをかける） 加工・拡充の複雑さ 非常に複雑なロジック、Rubyコード、外部DB参照 単一ドキュメント内の処理、簡単なクラスタ内ルックアップ インフラ管理負荷 高（追加のサーバー管理やチューニングが必要） 低（Elasticsearchの設定としてAPI管理可能） 推奨ユースケース 多種多様なソースからのデータ収集、マルチ出力、複雑なパース処理、負荷分離、高堅牢性が求められる大規模環境。 シンプルさとスピードを優先する場合。Beats/Agent利用時、標準的なログパース、管理コンポーネントを増やしたくない場合。 💡 ハイブリッド構成（併用）という選択肢も 「Logstashで多様なデータソースから収集・バッファリングを行い、Elasticsearchに転送した後の細かいパースはElasticのIntegration（標準のIngest Pipeline）に任せる」という  Logstash ➔ Ingest Pipeline  のハイブリッド構成も、大規模環境では一般的です。 まとめ 手軽さ、運用のしやすさ、標準的なログパース  ➔  Ingest Pipeline マルチ入出力、複雑なロジック、高堅牢性・バッファリング  ➔  Logstash 現代のElastic Stack構築における王道アプローチは、以下の2ステップです。 まずは運用の手軽な  Ingest Pipeline  で要件を満たせるか検討する。 入出力の制限やパースの複雑さ、インフラ分離の必要性が出てきた段階で  Logstash  の導入、あるいは併用へとステップアップする。 自社のインフラ規模やログの特性に合わせて、最適なデータパイプラインを選択しましょう！ The post Elasticのデータ前処理、どっちを選ぶ？ Logstash vs Ingest Pipeline 徹底比較 first appeared on Elastic Portal .

Elasticsearchのデータ移行やバックアップを、スナップショット機能を使わずに「もっと手軽に、インデックス単位でサクッと行いたい」と思ったことはありませんか？ そんなエンジニアの強い味方になるのが、オープンソースのCLIツール  elasticsearch-dump  （通称：elasticdump）です。 今回は、このツールの基本的な使い方から、実務で役立つ一歩進んだテクニックまでを解説します。 Elasticsearch を運用していると、以下のようなシーンに直面することがよくあります。 開発環境（Develop）の特定のインデックスだけを、ステージング環境（Staging）にサクッとコピーしたい インデックスの「マッピング」や「アナライザー」の設定だけを抽出して使い回したい ローカルファイル（JSON/CSV）にデータを退避させたい これらをGUIや面倒なAPIリクエストなしに、 使い慣れたCLIコマンド一発で解決してくれる のが、今回紹介する elasticsearch-dump です。 目次 1. elasticsearch-dumpとは？ 2. クイックスタート：インストール方法 2.1. Node.js環境の用意 2.2. npmによるインストール 3. 基本的な使い方とユースケース 3.1. ユースケース①：開発環境からデータをダンプ 3.1.1. マッピング（構造定義）をダンプ 3.1.2. ドキュメントデータ（実データ）をダンプ 3.2. ユースケース②：特定のデータだけを絞り込んでダンプする（searchBody） 4. 知っておくと便利な一歩進んだ応用テクニック 4.1. データの移行中にオンザフライで変換をかける（–transform） 5. ダンプしたデータのリストア 5.1. マッピングの作成 5.1.1. ローカルで my_index_mapping.json を開く 5.1.2. インデックス名（ “my_index” ）の階層を除外してコピーする 5.1.3. Kibana Dev Tools (Console) で実行する 5.2. データの登録 5.2.1. _bulk 用の ndjson への変換 5.2.2. Kibana Dev Tools (Console) で実行する 6. まとめ：どんな時に使うべきか？ 7. 参考リンク 1. elasticsearch-dumpとは？ elasticsearch-dump  は、Elasticsearchのインデックスデータをインポート/エクスポートするためのNode.js製ツールです。[^1] 1 最大の特徴は、「 --input （入力元）から、 --output （出力先）へデータをストリーミングして送る」という極めてシンプルな設計にあります。 入力元と出力先には、ESのURLだけでなく、ローカルのJSON/CSVファイルや、標準入出力（stdin/stdout）、さらにはAWS S3なども直接指定できます。 2. クイックスタート：インストール方法 今回検証した環境は以下の通りです。 OS : Windows 11 (PowerShell) Node.js : v24.18.0 jq : 1.8.2 2.1. Node.js環境の用意 Node.js 公式サイト  よりインストーラーをダウンロードし、インストールします。 ※ホスト環境にNode.jsをインストールしたくない場合は、公式のDockerイメージを利用する方法もありますが、ここでは説明を割愛します。 2.2. npmによるインストール npmを使ってグローバル（またはローカル）にインストールします。 # グローバルインストール npm install elasticdump -g 💡  Windowsでのインストール先について  Windows環境でグローバルインストール（ -g ）した場合、一般的には下記のパス配下に配置されます。[^2] 2 C:\Users\<ユーザー名>\AppData\Roaming\npm 3. 基本的な使い方とユースケース elasticdump は主に「Analyzer（アナライザー）」「Mapping（マッピング）」「Data（ドキュメントデータ）」の3つのフェーズ（ --type ）に分けて処理を行います。 （ここでは Analyzer フェーズは省略します。また、–type には settings や policy, alias, template なども指定可能です。詳細は、公式ページを参照してください。） 3.1. ユースケース①：開発環境からデータをダンプ データを JSON 形式でダンプします。通常は「mapping ➔ data」の順にダンプします。 3.1.1. マッピング（構造定義）をダンプ # PowerShellでの実行例（改行は「`」を使用） elasticdump ` --input=http://elasticuser:elasticpassword@develop.es.com:9200/my_index ` --output=my_index_mapping.json ` --type=mapping ⚠️  HTTPS環境（自己署名証明書など）でTLSエラーが出る場合  ElasticsearchがHTTPSでリクエストを受け付けており、証明書エラーが発生する場合は、一時的にTLS検証を無視する環境変数を設定してからコマンドを実行してください。[^3] 3 # PowerShellでの実行例 $env:NODE_TLS_REJECT_UNAUTHORIZED="0" elasticdump ` --input=https://elasticuser:elasticpassword@develop.es.com:9200/my_index ` --output=my_index_mapping.json ` --type=mapping 3.1.2. ドキュメントデータ（実データ）をダンプ elasticdump ` --input=http://elasticuser:elasticpassword@develop.es.com:9200/my_index ` --output=my_index_data.json ` --type=data 💡  Note : 出力ファイルフォーマットは「行区切りのJSON（Line-delimited JSON / NDJSON）」です。ファイル全体が1つの巨大なJSON配列ではないため、ストリーム処理に適しており、メモリ消費を最小限に抑えられます。 3.2. ユースケース②：特定のデータだけを絞り込んでダンプする（searchBody） 「管理者のログだけを抽出したい」「特定の期間のデータだけをバックアップしたい」という場合は、 --searchBody  オプションにElasticsearchのクエリ（DSL）を指定できます。 elasticdump ` --input=http://elasticuser:elasticpassword@develop.es.com:9200/my_index ` --output=my_index_filtered_data.json ` --type=data ` --searchBody='{\"query\":{\"term\":{\"username\":\"admin\"}}}' ※クエリが複雑な場合は、別ファイル（例： search_body.json ）に切り出して、 @  接頭辞を用いて読み込ませることも可能です。 ./search_condition/search_body.json { "query": { "term": { "username": "admin" } } } elasticdump ` --input=http://elasticuser:elasticpassword@develop.es.com:9200/my_index ` --output=my_index_filtered_data.json ` --type=data ` --searchBody=@./search_condition/search_body.json 4. 知っておくと便利な一歩進んだ応用テクニック 4.1. データの移行中にオンザフライで変換をかける（–transform） 移行のタイミングで「特定の個人情報フィールドをマスクする」「新しいフィールドを追加する」といった簡易的なETL（Extract/Transform/Load）処理が可能です。 JavaScriptでドキュメントの操作関数を定義しておき、それを呼び出します。 ./transforms/anonymize.js module.exports = function (doc, options) { if (doc._source.email) { // メールアドレスのドメイン部分だけ残してマスクする例 doc._source.email = "anonymized@" + doc._source.email.split('@')[1]; } }; # トランスフォーム用スクリプトを指定して実行 elasticdump ` --input=http://elasticuser:elasticpassword@develop.es.com:9200/my_index ` --output=my_index_transformed_data.json ` --type=data ` --transform=@./transforms/anonymize.js 5. ダンプしたデータのリストア リストア先の環境で  elasticdump  や  curl  を利用できる場合は、それらを利用してリストアするのが簡単ですが、それらを利用できない場合には、ダンプした JSON ファイルを加工して、Dev Tools の Console からデータを投入します。 既存データを壊さないように、必ず  mapping ➔ data  の順でリストアします。 5.1. マッピングの作成 5.1.1. ローカルで my_index_mapping.json を開く エクスポートされたマッピングファイルは、一般的に以下のように「インデックス名」をルートキーに持つ構造になっています。 { "my_index": { "mappings": { "properties": { "title": { "type": "text" }, "price": { "type": "float" } } } } } 5.1.2. インデックス名（ “my_index” ）の階層を除外してコピーする Kibana Console でインデックスを新規作成する際、宛先インデックス名は URL パス（ PUT /<インデックス名> ）で指定するため、JSON 内の  "my_index": { ... }  という外枠（ラッパー）は不要です。 内側の  { "mappings": { ... } }  のブロックだけをコピーします。 5.1.3. Kibana Dev Tools (Console) で実行する Kibana の Dev Tools Console を開き、以下のようにリクエストを記述して実行（再生マークのボタンをクリック）します。 PUT /my_index { "mappings": { "properties": { "title": { "type": "text" }, "price": { "type": "float" } } } } 5.2. データの登録 5.2.1. _bulk 用の ndjson への変換 jq コマンドを jqのダウンロードサイト からダウンロードします。 jq コマンドをダウンロード後、my_index_data.json を _bulk  用の ndjson に加工します。 PowerShell と jq の文字コードの相性が悪いので、コマンドプロンプトを経由して jq を実行します。 （jqの実行ファイル名が jq-windows-amd64 の場合） cmd /c 'jqのインストールディレクトリ\jq-windows-amd64 -c "{\"index\":{\"_index\":\"my_index\",\"_id\":._id}}, ._source" my_index_data.json > bulk_formatted.ndjson' 5.2.2. Kibana Dev Tools (Console) で実行する Kibana Dev Toolsで以下のように  POST _bulk  を記述し、その後に続けて  bulk_formatted.ndjson  の内容を貼り付けて実行します。 POST _bulk { "index" : { "_index" : "my_index", "_id" : "1" } } { "title" : "...", "price" : ... } ... 6. まとめ：どんな時に使うべきか？ Elasticsearch公式のスナップショット機能（Snapshot/Restore）は非常に強力ですが、S3などの共有リポジトリの登録が必要だったり、クラスタ全体の移行になりがちで、少々「重厚」です。 それに対して、  elasticsearch-dump  は以下のようなシチュエーションで抜群の機動力を発揮します。 開発環境と検証環境間で、数万〜数百万件程度の特定データをパパッと持ち運びたい スキーマ定義（マッピング）だけを手元でバージョン管理したい スナップショットの設定権限がない（AWS OpenSearch Serverless など制限のある環境を含む） 手元の開発環境に一つ入れておくだけで、データ運用の生産性が劇的に向上するおすすめのツールです。ぜひ皆さんのプロダクト運用や開発プロセスにも組み込んでみてください！ 7. 参考リンク elasticsearch-dump GitHub公式リポジトリ 実行には事前に Node.js（npm）の実行環境が必要になります。 ↩︎ Windowsのユーザー環境によって、”AppData” フォルダは隠しフォルダになっている場合があるため、エクスプローラーの「表示」設定で「隠しファイル」にチェックを入れてアクセスしてください。 ↩︎ この設定はSSL/TLSの証明書検証を無効化するため、本番環境の公開ネットワーク等で実行する際はセキュリティリスクを考慮し、一時的な利用に留めてください。 ↩︎ The post 【保存版】elasticsearch-dumpで実現する、Elasticsearch の超柔軟なデータ移行・バックアップ手法 first appeared on Elastic Portal .

注意 本記事は、実際のSplunk本番環境を使った移行試験ではありません。Splunkのsaved searchエクスポートを想定したダミーJSONを使い、Automatic Migrationの仕組み、操作、結果の読み方を確認した検証です。 目次 はじめに 最初に知っておきたい用語 LLM ELSER ES|QLとEQL Splunk saved search Splunk CIMとElastic ECS 必要条件と検証環境 必要条件 Match to Elastic prebuilt rules」をOFFにすればML不要か 検証環境 始め方：画面操作の流れ Automatic Migrationの処理フロー 全体像 prebuilt rule matchingの仕組み LLM翻訳とdeterministic validation 検証用の3ルール Case A：PowerShell encoded command Case B：Multiple failed logins Case C：Proxy＋macro＋lookup アップロード：ファイル形式とmacro／lookupの検出 JSON配列では失敗し、NDJSONで成功 macroとlookupの不足を自動検出 実行と結果サマリー TranslateからStartまで 結果 Serverlessで発生したELSERエラーと切り分け 発生したエラー 切り分けの手順と結果 言えること、言えないこと 3つの結果を読み解く Case B：Failed Loginは既存Elastic ruleへ置き換わった Case A：PowerShellはcustom ES|QL ruleになった Case C：Proxy ruleはPartially translated Rule・Data source・Integration・ECSの関係 インストールからEnableまでのレビュー手順 本番移行前に棚卸しするSplunk資産 まとめ：Automatic Migrationの価値 参考資料 はじめに Splunkで運用してきた検知ルールをElastic Securityへ移すとき、大きな労力を占めるのがルールの書き直しです。Elastic Securityには、この作業をAIで支援するAutomatic Migrationという機能があります。 本記事では、性質の異なる3つのダミーSplunkルールを用意し、Automatic Migrationがそれぞれをどう処理するかを確認しました。読み終えると、次のことが分かります。 Automatic Migrationが裏側で何をしているか（意味検索、AI翻訳、構文検証） 翻訳結果（TranslatedやPartially translated）の正しい読み方 移行前に棚卸しすべきSplunk資産と、ルール有効化前のレビュー観点 Elastic側の用語は、本文中で順に説明します。では、始めましょう。 最初に知っておきたい用語 Automatic Migrationの画面には、SplunkとElasticの用語に加えて、AI／機械学習の用語も登場します。先に最低限の意味を整理します。 本文で繰り返し登場する2つのElastic用語を、最初に押さえておきましょう。 prebuilt rule ：Elasticがあらかじめ用意している検知ルールです。Elastic自身が作成・保守しているため、Elastic-authored ruleとも呼ばれます。本記事では、画面の表記に合わせて両方の呼び方を使います。 Elastic Integration ：データソースごとに用意された取り込みパッケージです。ログの収集設定、パース、後述するECSへのマッピング、ダッシュボードがひとまとめになっています。本記事では「このruleを動かすには、このIntegrationでデータを取り込む必要がある」という文脈で登場します。 LLM Large Language Model（大規模言語モデル）の略です。Automatic Migrationでは、Splunkルールの意図の理解、prebuilt rule候補の評価、SPLからES|QLへの翻訳、macroの展開、構文エラーの修正、CIMフィールドからECSフィールドへの対応づけを担当します。 今回のServerless環境では、事前設定済みのAnthropic Claude Sonnet 4.6が選択されていました。これは今回の環境で選ばれていたモデルであり、Automatic Migrationの必須モデルではありません。必要なのは、サポート対象の動作可能なLLM Connectorです。 ELSER ELSERはElastic Learned Sparse EncodeRの略で、Elasticが提供する意味検索用モデルです。 通常のキーワード検索は、同じ単語が含まれているかを重視します。意味検索は、表現が違っても「何を検知したいルールなのか」が近いものを探します。 Automatic Migrationでは、まずElastic prebuilt rules側をELSERで意味検索できる索引にしておきます。検索するときは、Splunkルールから抽出したキーワードをクエリとしてこの索引に投げ、意味の近いprebuilt rule候補を探します。つまり、索引化されるのはprebuilt rulesで、検索の起点になるのはSplunkルールです。 例を挙げます。 Splunk側：Multiple Failed Logins From Same User Elastic側：Potential External Linux SSH Brute Force Detected 名前は一致していませんが、どちらも認証失敗の繰り返しを扱います。Automatic Migrationは、このような候補を文字列の完全一致に頼らずに探せます。ただし、意味が近いことと検知ロジックが同じことは別です。今回も閾値や時間条件は大きく異なっていました（詳細は8.1節）。 ES|QLとEQL ES|QLはElasticsearch Query Languageの略です。パイプ（|）で処理をつなぎ、Elasticsearch内のデータを検索、絞り込み、集計、変換します。 FROM logs-* | WHERE event.category == "process" | KEEP @timestamp, host.name, process.name | SORT @timestamp DESC 上から順に、FROM（どのindex／data streamを検索するか）、WHERE（どの行を残すか）、KEEP（どの列を残すか）、SORT（どう並べるか）と読みます。ES|QL detection ruleでは、原則として最終結果テーブルの各行がアラート候補になります。 EQLはEvent Query Languageで、イベントの順序や連続した動きを表現するのに向いています。重要なのは、Automatic MigrationがすべてをES|QL ruleへ置き換えるわけではないことです。新しく生成するcustom ruleはES|QLになりますが、Elastic-authored ruleへマッピングした場合は、その既存ruleの種類（今回はEQL）をそのまま使います。 Splunk saved search Splunkで保存されたSPL検索です。単なる検索条件の保存だけでなく、定期実行するreport、条件一致時に通知するalert、Splunk Enterprise Securityのcorrelation searchにも使われます。Automatic Migrationの画面では、Splunk rulesをsaved searchesとしてエクスポートして持ち込みます。 Splunk CIMとElastic ECS CIMはCommon Information Modelの略です。ベンダーごとに異なるログのフィールド名を、Splunk内で共通のフィールド名やデータモデルへ正規化する考え方です。ECSはElastic Common Schemaの略で、同じ意味の情報をElastic全体で共通フィールドへそろえます。 Splunk側のフィールド Elastic ECS process_name process.name CommandLine process.command_line src_ip source.ip user user.name Automatic Migrationは、CIMに近いSplunkフィールドをECSへマッピングしようとします。適切なECSフィールドを判断できない場合は、元のフィールド名が残ることもあります。 必要条件と検証環境 必要条件 ルール移行の裏側では、主に3種類の処理が協力します。LLM（ルールの理解、SPLからES|QLへの翻訳、候補ruleの判断）、ELSER／Machine Learning（prebuilt ruleやIntegrationの意味検索）、Elasticsearchの構文検証（生成されたES|QLが文法上有効かの確認）です。 公式ドキュメントで案内されている主な条件は次のとおりです。 Security > SIEM migrationsに対するAll権限 Security > Rules, Alerts, and Exceptionsに対する少なくともRead権限 動作するLLM Connector ServerlessではSecurity Complete subscription Elastic StackではEnterprise subscription Elastic Stack／Elastic CloudではMachine Learningが有効であること Elastic CloudではML zoneあたり4GB RAM以上を推奨 今回、最初にローカルの小規模3ノード環境で試したところ、ELSERのdeploymentに必要なML容量を確保できませんでした。 Failed to populate ELSER indices Could not start deployment because no ML nodes with sufficient capacity were found そのため、MLインフラをElastic側が管理するServerlessへ移しました。 Match to Elastic prebuilt rules」をOFFにすればML不要か Match to Elastic prebuilt rulesをOFFにすると、各Splunk ruleは既存のprebuilt ruleへマッピングされず、新しいcustom ruleとして翻訳されます。公式ドキュメントにも、OFFの場合は各ruleをcustom ruleへ変換すると説明されています。 ただし、これを理由に「ELSERやMachine Learningが不要になる」とは断定できません。公式要件では、Elastic StackとElastic CloudでAutomatic Migrationを使うにはMachine Learningの有効化が必要です。また、公式の処理説明では、prebuilt rule matchingに加えて、翻訳対象ruleに必要なIntegration候補を探す処理でも意味検索を使います。 なお、今回の検証ではprebuilt rule matchingをONにしていたため、OFFにした場合の内部挙動は実測していません。ここは未検証です。 検証環境 項目 内容 Elastic環境 Elastic Security Serverless 機能／UI世代 9.4系相当（検証日：2026-07-14。Serverlessは継続更新のためバージョン固定なし） AI Provider Elastic提供の事前設定済みConnector 選択されたLLM Anthropic Claude Sonnet 4.6 ELSER .elser_model_2_linux-x86_64 Splunk環境 なし 入力データ saved searchエクスポートを想定したダミーNDJSON（1行1JSON形式。5章参照） ルール数 3 インストール方法 Install without enabling（無効状態でのインストール。10章参照） 始め方：画面操作の流れ 実際に検証で行った操作を、画面の順に示します。細かい意味は後の章で説明するので、まずは全体の流れをつかんでください。 Elastic SecurityのLaunchpadで、Migrations > Manage automatic migrations を開きます。上部の検索バーで「Automatic Migrations」と検索しても移動できます 2. Configure AI Provider でLLMを確認します。今回はElastic提供のconnector（Claude Sonnet 4.6）が事前設定済みで、Completedと表示されていました 3. Migrate your existing SIEM rules to Elastic を開き、Upload rules をクリックします 4. Select migration sourceを Splunk に設定します 5. Migration nameを入力します。自動生成されたデフォルト名のままでも進められます 6. Export rulesに表示されるクエリは、実環境でSplunkからsaved searchをエクスポートするためのものです。今回はSplunkを使わないため、ダミーのNDJSONをそのままアップロードします 7. アップロード後、macroとlookupの追加アップロードを求められます。今回は不足時の挙動を確認するため、あえてスキップしました 8. Translate を押すとMigrate rulesダイアログが開きます。AI connectorを確認し、 Match to Elastic prebuilt rules のトグルをオン（デフォルトでオン）のままTranslateをクリックします 9.「Preparing environment for the AI powered translation」という準備中の画面になります 10. 準備が終わると「Migration of 3 rules is created and ready to start.」と表示されるので、 Start を押します 11. もう一度同じダイアログが開きます。トグルをオンのままTranslateを押します 12. 再び準備中になり、翻訳処理が進みます 13. 今回はELSERエラーの表示が残ったものの、翻訳は完了し、Translation SummaryにTranslated 2件・Partially translated 1件と表示されました。 View rules から結果の一覧へ進みます エラーの切り分けは7章、結果の読み方は8章で説明します。 Automatic Migrationの処理フロー 全体像 Splunkからsaved search（rule本体）をエクスポート | v ruleをアップロード （macro、lookup、MITRE情報は別の資産。 　必要に応じて別途エクスポートし、追加アップロードする） | v 似たElastic-authored ruleを検索 | +-- 十分に近い候補あり | | | +--> 既存Elastic ruleへマッピング | +-- 適切な候補なし | +--> macroを展開 +--> lookupを取り込む +--> 必要なIntegrationを検索 +--> SPLをES|QLへ翻訳 +--> 構文検証 +--> CIM fieldをECS fieldへマッピング prebuilt rule matchingの仕組み Elasticの公式ブログでは、概ね次の流れが説明されています。 Elastic prebuilt rulesをELSERで意味検索可能な表現にする LLMがSplunkルールから重要なキーワードを生成する そのキーワードでprebuilt rulesを意味検索する 候補をLLMへ渡す LLMが、同一または非常に近いruleかを判断する 近い場合はElastic-authored ruleとして結果へ追加する 今回のSSH brute forceルールがマッピングされたことは、推測ではありません。詳細画面に次のメッセージが表示されました。 This rule was mapped to an Elastic authored rule. ただし、これは「元のルールと論理的に完全一致した」という意味ではありません。採用された候補を、元のSPLと横に並べて確認する必要があります。 LLM翻訳とdeterministic validation LLMは柔軟にクエリを生成できますが、常に正しい文法を出すとは限りません。そこでAutomatic Migrationは、生成したES|QLをElasticsearchの構文解析へ渡して検証します。 LLMがES|QLを生成 | v Elasticsearchが構文を検証 | +-- 正常 -> 翻訳結果として保存 | +-- エラー -> エラー内容とクエリをLLMへ返す | +--> LLMが修正して再試行 公式ブログでは、この修正ループを最大3回実行すると説明されています。ここでいうdeterministic（決定的）は、「別のAIが良さそうか判断する」という意味ではありません。LLMは同じ入力でも実行のたびに違う答えを返すことがあります。一方、構文検証を行うのは、ES|QLの文法規則を実装したプログラム（パーサー）です。コンパイラと同じで、同じクエリ文字列を渡せば何回実行しても同じ判定を返します。たとえば、存在しないコマンド名を書けば毎回同じ構文エラーが返り、列名の綴りを誤れば毎回同じ「Unknown column」エラーが返ります。この「同じ入力には毎回同じ判定」がdeterministicの意味です。 構文が正しくても、正しいindexを見ているか、必要なフィールドがあるか、閾値が適切かまでは保証されません。 検証用の3ルール 3種類の挙動を確認できるよう、性質の異なるルールを用意しました。 Case A：PowerShell encoded command {"preview":false,"offset":0,"result":{"id":"https://dummy-splunk.example.local:8089/servicesNS/nobody/search/saved/searches/Suspicious%20PowerShell%20Encoded%20Command","title":"Suspicious PowerShell Encoded Command","search":"index=windows sourcetype=WinEventLog:Security EventCode=4688 process_name=\"powershell.exe\" (CommandLine=\"*-enc*\" OR CommandLine=\"*-EncodedCommand*\")","description":"Detects suspicious PowerShell execution using encoded command options.","action.escu.eli5":"","action.correlationsearch.annotations":"","alert.severity":"4"}} 確認したいのは、SPLからES|QLへ変換できるか、SplunkフィールドがECSへ置き換わるか、Event ID 4688の前提が維持されるか、prebuilt ruleへマッピングされるかです。 Case B：Multiple failed logins {"preview":false,"offset":1,"result":{"id":"https://dummy-splunk.example.local:8089/servicesNS/nobody/search/saved/searches/Multiple%20Failed%20Logins%20From%20Same%20User","title":"Multiple Failed Logins From Same User","search":"index=auth sourcetype=linux_secure action=failure | stats count by user, src_ip | where count > 5","description":"Detects multiple failed login attempts from the same user and source IP.","action.escu.eli5":"","action.correlationsearch.annotations":"","alert.severity":"3"}} 確認したいのは、statsとwhereを含むSPLをどう扱うか、似たprebuilt ruleへマッピングされるか、元の閾値と時間条件が維持されるかです。 Case C：Proxy＋macro＋lookup {"preview":false,"offset":2,"result":{"id":"https://dummy-splunk.example.local:8089/servicesNS/nobody/search/saved/searches/Proxy%20Access%20To%20Suspicious%20Domains%20By%20Finance%20Users","title":"Proxy Access To Suspicious Domains By Finance Users","search":"index=proxy sourcetype=bluecoat:proxysg `suspicious_domains` | lookup internal_users user OUTPUT department | where department=\"finance\"","description":"Detects proxy access to suspicious domains by finance users.","action.escu.eli5":"","action.correlationsearch.annotations":"","alert.severity":"4"}} このルールには、Splunk固有の依存が2つあります。 macro ： suspicious_domains の部分です。Splunk search macroは再利用可能なSPLの断片で、バッククォートで囲んで参照します。ルール本文にはmacro名しかなく、実際の条件は別のmacro定義に保存されています。 lookup ： | lookup internal_users user OUTPUT department の部分です。Splunk lookupは、イベント内の値を外部表と照合し、追加フィールドを付けます。外部表にはCSVファイルのほか、KV Storeを使えます。KV StoreはSplunkに内蔵されたkey-value型のデータベースで、CSVより大きなデータや頻繁に更新するデータの保存先に向きます。 つまりこのルールは、文法だけでなく、別管理されている依存資産（macroの展開内容、lookup definitionと実データ）がないと意味を完全に解釈できません。 アップロード：ファイル形式とmacro／lookupの検出 JSON配列では失敗し、NDJSONで成功 最初は通常のJSON配列を作りましたが、今回のアップロードには失敗しました。Splunkの検索結果エクスポートに近い、1行1JSONのNDJSON形式へ変更すると成功しました。 {"preview":false,"offset":0,"result":{...}} {"preview":false,"offset":1,"result":{...}} {"preview":false,"offset":2,"result":{...}} これは「必ずNDJSONしか受け付けない」と断定する結果ではありません。今回のダミーデータでは、Splunkが出力する検索結果の構造へ近づける必要があった、という観測です。実環境では、Automatic Migration画面に表示されるSplunk用エクスポートクエリを使って結果をJSONで出力するのが安全です。対象が多い場合は、LLMのcontext window（一度に読み込める入力量の上限）を超えないよう複数ファイルへ分割できます。 macroとlookupの不足を自動検出 ruleファイルをアップロードすると、Automatic MigrationはCase Cのmacroとlookupを検出し、追加アップロードを求めました。不足したまま処理を続けることもできますが、その依存情報が必要なruleはPartially translatedになる可能性があります。 今回は不足時の挙動を見るため、あえて追加せずに進めました。実案件の視点では、これは重要な示唆です。saved searchだけでなく、macroやlookupも一緒に棚卸ししないと正確な移行は難しい、ということを画面が教えてくれます（ 11章 ）。 実行と結果サマリー TranslateからStartまで 9.4系相当の今回のUIでは、Upload画面でTranslate、Migration作成後にStartという2段階に見えました。Translateを押すと「Preparing environment for the AI powered translation」と表示され、数分後に次のメッセージが出ました。 Migration of 3 rules is created and ready to start. Startを押すと処理が始まります。公式ドキュメントでは操作がTranslateとしてまとめて説明される場合があります。UIのボタン名や段階はリリースで変わる可能性があるため、本記事では今回観測した画面を記録しています。 結果 合計実行時間は12分でした。3件だけでも初回準備を含めると時間がかかるため、本番の大量移行では事前検証とバッチ分割を考える必要があります。 Status 件数 Translated 2 Partially translated 1 Not translated 0 Failed 0 ここで重要なのは、Translatedに2種類の結果が含まれることです。公式ドキュメントでも、Translatedは「Elastic-authored ruleにマッピングされたルール」と「AIで新規翻訳されたルール」の両方を含むと定義されています。一覧のAuthor列で見分けられます。 Author 意味 Elastic Elastic-authored ruleへマッピング（自動更新の対象） Custom Automatic Migrationがcustom ruleを生成（利用者側で維持・調整） Integrations列は、ruleを動かすために必要と判断されたElastic Integration数を示します。0/1は、必要なIntegrationが1つあり、現在利用可能なものが0という読み方です。 Serverlessで発生したELSERエラーと切り分け 発生したエラー Startの後、次のエラーが表示されました。 Migration initialization failed. Error: Failed to populate ELSER indices. Make sure the ELSER model is deployed and running at Machine Learning > Trained Models. ConnectionError: Connection closed while reading the body ローカル環境ではML容量不足が原因でしたが、今回はServerlessです。Serverlessでは学習済みモデルのautoscalingが常に有効なため、単純な容量不足とは限りません。そこで順に切り分けました。 切り分けの手順と結果 Trained Modelsで確認 ：Machine Learning > Trained Modelsでは、ELSER（.elser_model_2_linux-x86_64）がDeployedでした。 Dev Toolsでdeploymentを確認 ：Dev Toolsは、KibanaからElasticsearchのAPIを直接実行できる画面です。 GET _ml/trained_models/.elser_model_2_linux-x86_64/_stats { "deployment_stats": { "deployment_id": ".elser-2-elasticsearch", "state": "started", "allocation_status": { "allocation_count": 1, "target_allocation_count": 1, "state": "fully_allocated" } } } deploymentはstartedで、allocationはfully_allocated、failure countは0でした。追加のStart deploymentを押す必要はありません。 ELSERへ直接推論 ： POST _ml/trained_models/.elser_model_2_linux-x86_64/_infer { "docs": [ { "text_field": "Suspicious PowerShell encoded command execution" } ] } 多数のtokenとweightが返り、ELSER単体の推論は成功しました。 言えること、言えないこと ここまでで言えるのは、ELSERモデルが存在しない問題ではないこと、deploymentが停止していたわけでもないこと、ELSER単体の推論は可能なことの3点です。 一方、どの時点で接続が閉じたか、ELSER index populationが何割完了したか、自動再試行があったかは、UIからは断定できません。実際には、赤いエラー表示が残った一方で、1件のprebuilt rule mappingを含む翻訳結果が生成されていました。エラー発生前に候補検索が完了していたのか、バックグラウンドで一部が完了したのか、UIに過去のエラーが残っただけなのかは、この検証だけでは確定できません。 同じエラーが繰り返される場合は、project名、migration名、実行時刻、完全なエラーメッセージ、ELSERのstats、直接推論の成否、変換結果の有無を記録して、Elastic Supportへ相談するのが現実的です。 3つの結果を読み解く Case B：Failed Loginは既存Elastic ruleへ置き換わった 変換前： index=auth sourcetype=linux_secure action=failure | stats count by user, src_ip | where count > 5 変換後： Potential External Linux SSH Brute Force Detected Author: Elastic Rule type: Event Correlation (EQL) 既存ruleへのマッピングにより、Elasticが作成した説明、MITRE ATT&CK（攻撃者の戦術・手法を整理した業界標準のフレームワーク）への対応づけ、Investigation guide、Setup guide、Related integrations、Required fields、severity／risk score、scheduleをそのまま利用できます。ゼロからruleを書くのではなく、Elasticが用意した運用情報を再利用できる点が大きな利点です。 ただし、検知ロジックは元ルールと大きく異なります。 比較項目 元のSplunkルール マッピング先Elastic rule 失敗回数 5回超 60回 時間窓 SPL内に明示なし 30秒 対象 一般的なauth failure Linux SSH 送信元 制限なし 外部IPに限定 grouping user, src_ip host.id, source.ip, user.name Rule type statsベース EQL sequence このマッピングの価値は「候補探しの自動化」にあります。実際の移行では、Elasticの多数のprebuilt rulesから人が1件ずつ似たruleを探すことになります。Automatic Migrationを使えば、ゼロからルールを探すのではなく、提示された候補が元ルールの目的を満たすかの比較から始められます。 インストール前の判断は、次のように整理できます。 判断 対応 目的と条件が十分近い Install without enabling → 実データで検証 → Enable 目的は近いが閾値が違う Install後にruleを調整し、テスト 目的が違う mappingを採用せず、prebuilt matchingをOFFにしてcustom translationを再実行、または手動作成 Case A：PowerShellはcustom ES|QL ruleになった 変換前： index=windows sourcetype=WinEventLog:Security EventCode=4688 process_name="powershell.exe" (CommandLine="*-enc*" OR CommandLine="*-EncodedCommand*") 変換後： FROM logs-endpoint.action.responses-*,logs-endpoint.actions-*,logs-endpoint.alerts-*,logs-endpoint.events.api-*,logs-endpoint.diagnostic.collection-*,logs-endpoint.events.device-*,logs-endpoint.events.file-*,logs-endpoint.heartbeat-*,logs-endpoint.events.library-*,logs-endpoint.events.network-*,logs-endpoint.events.process-*,logs-endpoint.events.registry-*,logs-endpoint.events.security-* | WHERE event.category == "process" AND event.type == "start" AND TO_LOWER(process.name) == "powershell.exe" AND (process.command_line LIKE "*-enc*" OR process.command_line LIKE "*-EncodedCommand*") | KEEP @timestamp, host.hostname, user.name, process.name, process.pid, process.command_line, process.executable, process.parent.name, process.parent.executable | SORT @timestamp DESC | LIMIT 100 event.categoryとevent.typeはどこから来たか ：ECSでは、イベントを大きな種類へ分類します。event.category == “process”はプロセスに関するイベント、event.type == “start”は開始イベントです。元SPLの文字をそのまま置換したのではなく、Elastic側のデータモデルに合わせて検知意図を表現し直しています。 なぜEvent ID 4688が消えたか ：変換後にはevent.code == “4688”がなく、FROMがlogs-endpoint.*を検索しています。これは、Windows Security Logの4688を探すruleから、Elastic Defendが収集するEndpointプロセスイベントを探すruleへ、意味的に書き換えられたことを示します。因果関係に注意してください。4688が消えたからElastic Defendが必要なのではありません。生成されたクエリのdata sourceがlogs-endpoint.*になったため、そのデータを出す候補としてElastic Defendが必要と判断され、結果として4688条件が使われなくなった、という順序です。 なお、Windows Security Event ID 4688は新しいプロセスの作成時に記録される監査イベントです。command lineを4688に含めるには、WindowsのInclude command line in process creation eventsポリシーを有効にする必要があり、デフォルトでは空になることがあります。 このES|QLをそのまま有効化してよいか ：修正と検証が必要です。確認すべき点は5つあります。 データソースの前提が変わった ：組織がWindows Security Logを取り込む設計なら、event.code == “4688”と実際のWindows data streamを使うruleの方が自然です。Elastic Defendを導入済みなら、この変換は合理的です。 LIKEはcase-sensitive ：ES|QLのLIKEは大文字・小文字を区別するため、-ENCを見逃す可能性があります。 TO_LOWER(process.command_line) LIKE "*-enc*" が改善候補です。-eや-enといったさらに短い省略形まで対象にするかは、検知方針と誤検知を見て決めます。 FROMが広い ：プロセスイベントだけが必要なら、 FROM logs-endpoint.events.process-* まで絞れます。実際に使うdata streamをDiscover（Kibanaでデータを対話的に検索・閲覧できる画面）で確認してから変更します。なお、data streamは時系列データを格納するElasticsearch側の保存先で、Kibanaのdata view（どのindex／data streamを画面に表示するかの定義）とは別の概念です。ES|QLのFROMに書くのはdata streamやindexの名前です。 LIMIT 100 ：ES|QL ruleでは各結果行がアラート候補です。LIMITとMax alerts per run（ルール実行1回あたりのアラート数上限の設定）では小さい方が上限になるため、大量発生時の101件目以降の扱いを検討します。LIMITの調整、検知条件の絞り込み、alert suppression、実行間隔の短縮が選択肢です。 MITRE ATT&CKがない ：元のダミーJSONでは action.correlationsearch.annotations が空でした。Automatic Migrationは、source assetが持つMITRE mappingを追加アップロードする仕組みを持ちますが、クエリ内容から新しいmappingを必ず推測・付与する機能だとは考えない方が安全です。レビュー候補はT1059.001（PowerShell）とT1027.010（Command Obfuscation）で、最終的には組織の検知意図に合わせて人が設定します。 また、KEEPで_idを結果から落とすと、アラートのdeduplicationに影響する可能性があります。現在の公式ドキュメントでは、非集約クエリにMETADATA _idが自動追加される場合でも、KEEPの内容によっては重複アラートの警告が出ると説明されています。保存時のwarningとExecution resultsを確認してください。 Case C：Proxy ruleはPartially translated 生成結果： FROM logs-proxysg.log-* | WHERE [macro:suspicious_domains] | LOOKUP JOIN internal_users ON user.name | WHERE department == "finance" | LIMIT 100 Partially translatedとはいえ、元のSPLの4つの構成要素は、それぞれ生成結果に引き継がれています。対応を並べると次のようになります。 元のSPL 生成されたES|QL 状態 index=proxy sourcetype=bluecoat:proxysg FROM logs-proxysg.log-* ProxySGログに相当するdata streamへ変換済み `suspicious_domains`（macro） WHERE [macro:suspicious_domains] 位置は維持。ただし中身は未展開のplaceholder | lookup internal_users user OUTPUT department | LOOKUP JOIN internal_users ON user.name lookupの意図はES|QL構文へ変換済み。ただし参照先のlookup indexは未作成 where department=”finance” WHERE department == “finance” 変換済み つまり「クエリの骨組みは全部できたが、2行目と3行目を動かすための実体（macroの中身とlookupデータ）が足りない」という状態です。[macro:suspicious_domains]は完成したES|QLではなく、macroの展開内容を入れるplaceholderです。LOOKUP JOIN internal_usersも、Elasticにinternal_usersというlookup indexが存在することを前提にしています。 ここで誤解しやすいのは、「Elasticにlookup機能がないから失敗した」のではない点です。不足しているのは、Splunk側のlookup資産と中身です。ElasticにはES|QLのLOOKUP JOINがあり、lookup modeのindexと検索結果を結合して追加フィールドを付けられます。Automatic Migrationの公式説明でも、lookupファイルをアップロードすればElasticsearchのlookup indexとして取り込みます。今回はアップロードしていないため、名前だけがクエリに残りました。 完成させる方法は2つあります。 方法A：不足資産を追加アップロード ：suspicious_domainsのmacro定義と、internal_usersのlookup definition／CSVをSplunkからエクスポートして追加し、再処理します。 方法B：Elastic側で手動実装 ： FROM logs-proxysg.log-* | WHERE url.domain IN ("evil.example", "malware.example") | LOOKUP JOIN internal_users ON user.name | WHERE department == "finance" その前に、internal_usersをindex.mode: lookupで作成し、userとdepartmentを登録します。join fieldの型も一致させる必要があります。 また、Automatic MigrationはIntegration候補としてBroadcom ProxySGを提案しました。クエリを完成させるだけでなく、そのクエリが検索するProxySGデータ自体を取り込む必要があります。 Rule・Data source・Integration・ECSの関係 この4つは別々の話ではありません。PowerShell ruleを例にすると、次の依存関係があります。 Rule process.name == "powershell.exe" を検索したい | v ECS field process.name / process.command_line が必要 | v Data source Endpointプロセスイベントが必要 | v Integration Elastic Defendがそのデータを収集しECSへ整形する Integrationが未導入だと、対象data streamが存在せず、必要なECS fieldも入りません。ruleはインストールできても一致するデータがなく、アラートは出ません。 Automatic MigrationのIntegration表示は、rule translationの合格／不合格ではありません。「Translated＝ruleの形が作られた」「Integration ready＝ruleを動かすデータが準備された」という別の状態を、分けて確認する必要があります。 インストールからEnableまでのレビュー手順 Translatedになった2件は、無効状態でインストールしました（Install without enabling）。安全な流れは次のとおりです。 Translate / Map     → Source ruleとElastic ruleを比較     → Install without enabling     → 実データでクエリを検証     → Rule settingsを調整     → Enable レビューの起点は、元の検知目的を一文で書くことです。たとえばCase Bなら「同一ユーザー・同一送信元IPからの短時間の連続ログイン失敗を検知する」です。この一文が書けないと、マッピング先や翻訳結果が目的を満たすかを判断する基準がありません。クエリの字面同士ではなく、この一文と比較します。 そのうえで、各段階の確認点は次の表のとおりです。いずれも今回の検証で実際に問題になった観点です。 段階 目的 主な確認点 Logic review（インストール前） 検知の意味が変わっていないか 閾値・時間窓・grouping・除外条件を「目的の一文」と比較する。マッピングの場合はsource queryとtranslated queryを横に並べる Data review ruleを動かすデータがあるか index／data streamの存在、Integrationの導入とデータ到着、必要なECS field、lookup index Query review クエリ自体が動くか DiscoverでのES|QL実行、LIKEのcase sensitivity、KEEPと_id、LIMITとMax alerts per run Rule setting review（インストール後） 運用設定が適切か severity／risk score、MITRE ATT&CK、schedule、alert suppression、exceptions、rule actions Validation（Enable前後） 実データで意図どおり動くか 既知イベントへの一致、Execution resultsのエラーとgap、アラート量とfalse positive 本番移行前に棚卸しするSplunk資産 今回のCase Cが示したとおり、rule本文だけをエクスポートしても依存情報が欠けます。本番移行前に、次の資産を棚卸ししてください。 資産 簡単な説明 移行で必要な理由 saved search 保存されたSPL。report、alert、correlation searchにも使う rule本体 macro definition SPLの再利用可能な断片 展開しないと完全な検索条件が分からない lookup file CSV／KV Storeの参照データ user、asset、domain情報の追加に必要 lookup definition lookup名とファイル／入出力fieldの対応 SPLのlookup名だけでは実体を特定できない data model CIMベースの論理的なデータ構造 tstatsやaccelerated data modelを使うruleに必要 sourcetype Splunkがログ形式を識別する分類 Elasticで対応Integration／datasetを選ぶ手掛かり field extraction 生ログからfieldを取り出す定義 Elastic側でpipelineやmappingを再現するため CIM mapping ベンダー固有fieldを共通fieldへ正規化する対応 ECS mappingを決めるため MITRE annotations tactic／techniqueのmetadata Elastic ruleのMITRE coverageを維持するため index／retention データの保存先と保存期間 Elasticのdata stream、ILM（index lifecycle management：保存期間の管理機能）、検索範囲を設計するため まとめ：Automatic Migrationの価値 今回の検証では、Splunk本体がなくても、saved searchエクスポートを模したダミーデータでAutomatic Migrationの主要な動きを確認できました。 3件をNDJSONでアップロードできた 1件はElastic-authored EQL ruleへマッピングされた 1件はcustom ES|QL ruleへ変換された 1件はmacro／lookup不足でPartially translatedになった 必要なIntegrationとしてElastic DefendとBroadcom ProxySGが示された ServerlessでもELSER index populationの接続エラーが発生したが、ELSERのdeploymentと直接推論は正常だった マッピング先のruleは、元SPLと閾値／時間窓／対象が異なっていた custom ES|QLも、data source、case sensitivity、LIMIT、MITRE、_idの確認が必要だった Automatic Migrationは、移行を完全自動で終わらせる魔法ではありません。より正確には、次の4つを自動化・可視化する機能です。 似たElastic ruleを探す SPLをES|QLのたたき台へ変換する 不足したmacro／lookupを発見する 必要なIntegrationを提案する この分類は工数見積もりにも使えます。たとえば1,000件のruleがある場合、「Mapped 300／Fully translated 450／Partially translated 180／Not translated 70」のように結果を分ければ、そのままレビューできる範囲、データやmacro／lookupの追加が必要な範囲、手動再設計が必要な範囲を分けて見積もれます。 移行の主役は依然として、検知目的を理解し、データと閾値を検証するエンジニアです。Automatic Migrationは、その出発点を「空のエディタ」から「レビュー可能なたたき台」へ引き上げてくれます。 参考資料 本記事は、以下のElastic公式情報に基づいています。 Automatic migration | Elastic Docs https://www.elastic.co/docs/solutions/security/get-started/automatic-migration Fast-track your switch from your current SIEM with Automatic Migration | Elastic Blog https://www.elastic.co/blog/automatic-migration-ai-rule-translation AI can do what now?! Accelerating SIEM migration | Elastic Blog https://www.elastic.co/blog/accelerating-siem-migration Potential External Linux SSH Brute Force Detected | Prebuilt detection rules reference https://www.elastic.co/guide/en/security/current/potential-external-linux-ssh-brute-force-detected.html ES|QL rules | Elastic Docs https://www.elastic.co/docs/solutions/security/detect-and-alert/esql The post Elastic Automatic MigrationをダミーSplunkルールで検証してみた first appeared on Elastic Portal .