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 .