2026年熊本地震の強震観測データを可視化して見えたこと

Tech Blog header: a laptop spews colorful shapes with Japanese title about visualizing 2026 Kumamoto earthquake data. BLOG

この記事でやりたいこと

2026年7月28日に熊本で発生したM7.1の地震(気象庁の正式名称は「令和8年熊本地震」)の観測データを取り込んでダッシュボードを作ってみました。

Elasticは、データの検索・分析・可視化を中核に、セキュリティ分析、オブザーバビリティ、生成AI活用までを同じデータ基盤上で支えるプラットフォームです。今回は、この仕組みを防災系のデータにどこまで活用できるのか、実際に試しました。

この記事では地震の専門的な分析をするのではなく、観測データを可視化することで、どのような傾向や新しい問いが見えてくるのかを紹介します。

題材に地震を選んだのは、過去に地震関連の仕事に関わった経験があるからです。ある程度知識や経験のある分野なら、「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枚のダッシュボードに分けました。

  1. 活動概要・時間再生 — 全体像をつかみ、時間を追って再生する
  2. M7.1地震後の活動分析 — 記録が時間とともにどう変わったか
  3. 規模と観測された揺れ — マグニチュードと実際の揺れの関係

最初は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枚のダッシュボードで分析しました。それでも、このデータセットの範囲で、

  1. 記録はM7.1の直後の数時間に集中していた
  2. 記録件数が少なくなった時間帯にも、M5.8の比較的大きな地震が含まれていた
  3. 規模(マグニチュード)と観測された揺れは同じではない
  4. 「強い揺れ」の順位すら、測る物差しで変わる

という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