137,000人、人間の判断はゼロ：Elasticsearchによるエージェンティックな災害対応

Agent Builderは、現在一般提供でご利用いただけます。Elastic Cloud トライアルを開始し、こちらでAgent Builderのドキュメントを確認してください。

Elastic社は、7つの基地にまたがる13万7000人の軍関係者の自動避難を、人間の介入なしに調整しました。カテゴリー4のハリケーンがハンプトン・ローズの海岸線を直撃します。Elasticsearchの地理空間エンリッチメントにより、インデックス作成時に影響区域内のすべての施設が特定され、Kibanaの検出ルールがトリガーされ、ワークフローがAIエージェントの会話を開始します。エージェントは収容能力、距離、拠点の適合性を分析した上で、1回の処理で16件の避難および受け入れ通知を送信します。未加工のGDACSイベントから連携アクションまで、すべて自動で実行されます。

毎年、自然災害によって、緊急事態管理者、軍司令官、公安当局者は、限られた時間の中で重大な決断を迫られることになります。従来、こうした意思決定は、緊急連絡網やスプレッドシート、そして何十人もの人々に分散した組織的知識に依存しています。調整にかかる手間だけでも、貴重な時間が奪われます。

本記事では、脅威を検知し、ロジスティクスを推論して自動的にアクションを実行する災害対応向けの即応性に優れたエージェント型連携システムをElasticがどのように提供できるかをご紹介します。具体例として、シミュレーションを構築しました。ハンプトン・ローズの海岸線を脅かす架空のカテゴリー4のハリケーンによって、7つの軍事施設にわたる137,000人以上の要員の自動再配置がトリガーされるというものです。

免責事項：これはデモンストレーション目的で作成された完全に架空のシナリオです。 ハリケーンELARA-26は実在しません。施設の所在地は、公開されている実際の地理データ（米国国防総省［DoD］のMilitary Installations, Ranges, and Training Areas［MIRTA］データセット）に基づいたものですが、人員数、収容可能人数、資産、連絡先メールアドレス、ミッションプロファイルなどの運用データはすべて完全に架空のものです。このデモに含まれる内容は、実際の軍事的な即応態勢、能力、または運用手順を反映したものではありません。

自動化された災害対応に地理空間とエージェント型の連携が必要な理由

自然災害によって重要なインフラが脅かされると、次のような調整の課題が直ちに発生します。

• 影響ゾーンにある施設はどれですか？

• 何人の人員を移動させる必要があるか？

• どこに行けばいいのか、そしてそれらの施設には収容能力があるか？

• 今すぐ連絡する必要があるのは誰か？

これらの質問は待ってくれません。 その答えも同様です。

パイプラインのデプロイ：要件とセットアップ

サンプルリポジトリのこちらにある手順に従って、Cloud Connectを介してElastic Inference Service（EIS）を使用するローカルElasticクラスターをデプロイします。

Elasticsearchのエージェント型災害対応パイプラインの仕組み

このパイプラインには、エンドツーエンドで連携して機能する7つのレイヤーがあります。

1. データインジェスト：Elasticsearchに送信されたGlobal Disaster Alert and Coordination System（GDACS）の災害イベント。

2. インジェストパイプライン：GeoJSONがインジェストされ、Elastic Common Schema（ECS）に正規化されます。

3. 地理空間エンリッチメント：イベントの影響エリアのポリゴンがインデックス登録された軍事施設の境界と照合されます。

4. アラート：災害がいずれかのインストール環境と交差すると、Kibanaの検出ルールが作動します。

5. ワークフローの自動化：アラートによってKibanaワークフローがトリガーされ、AIエージェントの会話が開始されます。

6. AI推論：エージェントは、影響を受ける施設、その資産、および最寄りの支援施設をもとに推論を行い、すべての資産と人員の再配置を決定します。

7. メール通知：エージェントは、出入りする人員や資産について、すべての受信者にメールを送信します。

各レイヤーを見てみましょう。

ステップ1：地理的境界に基づいて軍事施設をインデックス化

基盤となるのは、source.coop/seerai/hifldのDoD MIRTAデータセットです。このデータセットは、各施設に対してPointタイプのgeo_shapeを提供します。これは完全な境界ポリゴンではなく、重心座標となります。

mitra-facilitiesインデックス内の各インストールドキュメントは、MIRTAが提供する内容に加えて、運用プロファイルデータ（すべて架空のもの）でエンリッチされています。

{
  "entity_name": "Naval Station Norfolk",
  "branch_of_service": "Navy",
  "mission_function_type": "fleet_support",
  "personnel_count": 50000,
  "housing_capacity": 55000,
  "temporary_housing_capacity": 10000,
  "logistics_capabilities": ["fuel", "airlift", "sealift", "medical"],
  "available_assets": [
    { "type": "helicopters", "count": 24 },
    { "type": "transport_vehicles", "count": 150 }
  ],
  "contact_email": "norfolk.ops@navy.mil.gov.fake",
  "operational_status": "act",
  "is_joint_base": false,
  "entity_geo_location": { "type": "polygon", "coordinates": [...] }
}

このリッチなインデックスによって、AIエージェントは単に「近くに基地がある」というだけでなく、「収容能力があり、任務の種類が適合し、到着する資産を受け入れるための物流を備えた基地がある」という、インテリジェントな割り当て決定を下すことが可能になります。

ステップ2：GDACSイベントの取り込みと正規化

GDACSは、地震、熱帯低気圧、洪水、山火事、火山、干ばつに関するリアルタイムのGeoJSONを公開しています。このフィードをデータストリーム（logs-gdacs.events-*）に取り込み、生のGeoJSONをECSフィールドに正規化するカスタム取り込みパイプラインを使用します。

GDACS取り込みパイプラインは、注目すべきいくつかの処理を実行します。

ジオメトリ抽出：重心はマップ表示用にgeo_pointとして格納され、影響ポリゴンはgdacs.affected_areaにgeo_shapeとして格納されます。これは、後で交差クエリに使用されるフィールドです。

重大度の正規化：災害の種類ごとに、重大度のスケールが異なります。熱帯低気圧は風速（km/h）で、地震はリヒター・マグニチュードで測定されます。パイプラインはそれらすべてを正規化された0～100のスコアにマッピングします。

// 取り込みパイプラインからの簡単なスニペット
if (type == 'TC') {
  norm = Math.min(100.0, Math.max(0.0, (val - 40.0) / 2.6));
} else if (type == 'EQ') {
  norm = Math.min(100.0, Math.max(0.0, (val - 4.0) * 20.0));
}

正規化された深刻度スコアはその後、検出ルールのアラート深刻度マッピングで使用されるseverity_levelラベル（low、medium、high、critical）にマッピングされます。

ECSとの整合性：event.kind: alert、event.category: threat、event.start/event.endにマッピングされたタイムスタンプ、重複排除のための安定したフィンガープリントベースの_id。

ステップ3：地理空間エンリッチメント：インデックス作成時に影響を受ける施設を特定する

Elasticsearchのgeo_matchエンリッチポリシーは、インデックス時に災害ポリゴンを各施設の境界と照合するため、クエリ時の結合は不要です。検索時にクエリを実行する代わりに、取り込みパイプラインでエンリッチプロセッサーを使用して、ドキュメントのインデックス時に災害の影響ポリゴンを各施設の境界と照合します。

エンリッチポリシーはgeo_matchポリシーです。

{
  "geo_match": {
    "indices": "mitra-facilities",
    "match_field": "entity_geo_location",
    "enrich_fields": [
      "entity_name",
      "entity_type",
      "entity_station_number",
      "entity_geo_city_name",
      "entity_geo_region_name"
    ]
  }
}

プロセッサーは取り込みパイプラインの最後で実行されます。

{
  "enrich": {
    "policy_name": "facilities-geo",
    "field": "gdacs.affected_area",
    "target_field": "affected_facilities",
    "shape_relation": "INTERSECTS",
    "max_matches": 128
  }
}

INTERSECTSは、境界線が災害ポリゴンに接しているか重複しているすべての施設や、部分的な交差さえも検出します。その結果、すべてのGDACSイベントドキュメントは、どの施設が影響区域内にあるかを正確に示すaffected_facilitiesネスト配列とともに格納されます。結合クエリは不要です。

ステップ4：検出ルール：施設への影響に関するアラート

Kibanaの検出ルールは、logs-gdacs.events-*データストリームを監視し、GDACSイベントが少なくとも1つの影響を受けた施設でエンリッチされたときにトリガーされます。

クエリ：affected_facilities: { entity_name: * }

このルールは1時間ごとのスケジュールで実行され（現在から1時間前までの期間を対象）、動的な重大度マッピングを使用します。取り込みパイプラインによって計算されるgdacs.severity_levelフィールドが、アラートの重大度を自動的に決定します。

アラートの深刻度も、フィールドマッピングを通じてリスクスコアに影響を与えます。

"risk_score_mapping": [
  {
    "field": "gdacs.normalized_severity",
    "operator": "equals",
    "value": ""
  }
]

ルールがトリガーされると、設置名、タイプ、場所を含むエンリッチされたaffected_facilities配列を含む完全なアラートコンテキストが、ダウンストリームのKibanaワークフローに渡されます。

ステップ5：ワークフローの自動化：アラートからエージェントへの橋渡し

Kibanaワークフローは、検出から対応への引き継ぎを処理します。自然災害対応ワークフローは、以下のアラートによって開始されます。

triggers:
  - type: alert
steps:
  - name: start_convo
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      body:
        agent_id: "mitra.response"
        input: "New Natural Disaster Alert: {{ event.alerts | json }}"

アラートのペイロード全体（災害の種類、重大度、被災地域、影響を受けた設備の一覧）が、初期コンテキストとしてAIエージェントに転送されます。そこから先はエージェントが処理を引き継ぎます。

ステップ6：AIエージェント：データから連携したアクションへ

mitra.responseエージェントは、アラートペイロード全体を受け取り、単一のエージェントループで対象範囲を評価し、受け入れ施設を特定し、人員を割り当て、避難通知と受け入れ通知を送信します。これらはすべて、人間の介入なしで行われます。

エージェントには2つのツールが用意されています。

• mitra.nearest_facilityは、geo_shapeクエリを使用してmitra-facilitiesインデックスにクエリを実行し、指定された座標からの距離で並べ替えて、利用可能な収容能力を持つ周辺のアクティブな施設を最大50件返します。

• mitra.send_emailは、施設オブジェクトのJSON配列を反復処理し、フォーマットされた避難通知または受入通知を送信します。

エージェントの指示セットは、明確なワークフローを定義します。

1. 状況を評価する。アラートをパースし、影響を受ける施設を特定して、災害の範囲を判断します。

2. 移行が必要な対象のインベントリを作成する。施設ごとの人員数、重要資産、住宅要件。

3. 再配置先施設を見つける。影響を受ける各施設に対してmitra.nearest_facilityを呼び出し、危険区域内にある施設を除外します。

4. 配分に関する決定を行う。単一施設ソリューションと複数施設ソリューションの比較検討、支店間の互換性、収容能力、資産サポートなどを考慮します。

5. 調整メールを送信する。避難元施設に避難指示を、受入施設に受入通知を送信します。

6. サマリーレポートを作成する。影響を受けるすべての施設、総人員、移動した資産、再配置先施設、懸念事項の簡単なサマリーを作成し、確認のためにチャットに出力します。

エージェントの割り当てロジックは、現実世界の制約に従います。住宅収容能力を超えないこと、可能な場合は同一部隊内での移転を優先すること、複数部隊にまたがる移転の場合は共同拠点を使用すること、そして移動時間を最小限に抑えるために距離を優先することなどが含まれます。

最寄りの施設ツール

基盤となるワークフロークエリでは、circleフィルター付きのgeo_shapeと_geo_distanceソートを使用します。

"query": {
  "bool": {
    "filter": [
      {
        "geo_shape": {
          "entity_geo_location": {
            "shape": {
              "type": "circle",
              "coordinates": [{{ inputs.lon }}, {{ inputs.lat }}],
              "radius": "5000km"
            },
            "relation": "intersects"
          }
        }
      },
      { "term": { "operational_status.keyword": "act" } }
    ]
  }
},
"sort": [
  {
    "_geo_distance": {
      "entity_geo_point": { "lat": {{ inputs.lat }}, "lon": {{ inputs.lon }} },
      "order": "asc",
      "unit": "km"
    }
  }
],
"script_fields": {
  "available_capacity": {
    "script": {
      "source": "Math.max(0, doc['housing_capacity'].value - doc['personnel_count'].value)"
    }
  }
}

利用可能な収容人数は、収容可能人数から現在の人員数を差し引くスクリプトフィールドを介して、クエリ実行時に計算されます。エージェントは、上限を超えないように、これを使用してデスティネーション間で人員を割り当てます。

ハリケーンELARA-26：137,000人の人員をエンドツーエンドでエージェント的に調整

ハリケーン「ELARA-26」は、バージニア州のハンプトン・ローズ地域に上陸すると予測されているカテゴリー4の暴風雨（最大風速213 km/h）です。GDACSイベントが取り込まれると、影響を受けるエリアのポリゴンは、この地域にある7つの主要な軍事施設と交差します。検出ルールがトリガーされます。ワークフローによってエージェントの会話が開始されます。

単一のエージェントループ内で、エージェントは以下を行いました。

• 影響エリア内の7つの施設（合計137,372名の人員）を特定しました。

• 嵐の進路外にある受け入れ施設を見つけるために、mitra.nearest_facilityを呼び出しました。

• 利用可能な収容能力と距離に基づいて、9つの受入施設に人員を分散配置しました。

• 影響を受けた7つの施設すべてに避難指示を生成して送信しました。

• 受入通知を作成し、9件の受入施設すべてに送信した。

• 以下のような、調整に関する詳細な概要を作成しました。

避難対象施設：

受入施設：

再配置された資産には、輸送車両、ヘリコプター、パトロール艇、医療ユニット、工作車両、発電機、給水トレーラー、シェルターキット、通信システムが含まれます。

自動メール通知

エージェントが割り当て計画を確定すると、mitra.send_emailを呼び出し、1回の処理で16通のメールを送信しました。つまり、影響を受けた7つの施設すべてへの避難指示と、受け入れ先となる9つの施設すべてへの受け入れ通知です。各メッセージには、受入先施設、到着する人員数、移動する資産、調整担当の連絡先が含まれていました。以前であれば電話連絡網に何時間もかかっていた作業が、エージェントによる推論が完了した瞬間に自動的に完了しました。

RAGとポリシーグラウンディングによるエージェント型災害対応の拡張

このデモは、収容能力の数値、距離、稼働状況などの構造化データのみに基づいています。Elasticのセマンティック検索およびRetrieval-Augmented Generation（RAG）機能に2つの要素を追加することで、エージェントを大幅にスマートにすることができます。

過去の対応検索：過去の事後レポート、連邦緊急事態管理庁（FEMA）のインシデント概要、災害対応記録をベクトル埋め込みとしてインデックス化します。新しいイベントが発生すると、エージェントは類似のイベントがどのように対応されたかをセマンティックに検索し、単なるキャパシティの計算だけでなく組織の知識を活用して割り当ての意思決定を行うことができます。

ポリシーとドクトリンの根拠付け：国防総省（DoD）の緊急事態管理指令、施設の業務継続計画（COOP）、司令官のガイダンスをインデックス化します。エージェントは対応を規定する実際のポリシーを取得して引用できるため、すべての決定が推論ではなくドクトリンに基づいていることを保証できます。

どちらも同じElasticネイティブのアプローチに従います。推論パイプラインがインデックス作成時に埋め込みを生成し、セマンティック検索ツールがエージェントに公開されます。 調整パイプラインは同じままです。エージェントはさらに賢くなります。

公共部門のエージェント型対応にElasticsearchが最適なプラットフォームである理由

これはチャットボットではなく、ダッシュボードでもありません。脅威を検知し、複雑なロジスティクス問題を推論して、人間の介在なしに137,000人の移転を調整した、応答性の高いエージェント型ワークフローシステムです。このような成果が可能になるのは、依存するすべての機能が単一の統合プラットフォームに集約されているからです。

Elasticsearchの地理空間サポート（geo_point、geo_shape、エンリッチメントポリシー、距離ベースの並べ替え）は、交差検出や施設検索の大規模な実行を可能にする空間推論を処理します。セマンティック検索とベクトル埋め込みによりエージェントを事実にグラウンディングさせ、AIの推論がハルシネーションによる推測ではなく、データに実際に存在する情報に基づくようにします。Kibanaの検出エンジン、Workflows、Agent Builder、Agent Builderツールにより、外部の連携コードを必要とすることなく、未加工のイベントから連携したアクションへと至るパイプラインとしてこれらすべてが統合されます。

Elasticのようにこれらを統合できるプラットフォームは他にありません。リアルタイムのインデキシング、地理空間の精度、セマンティック検索、エージェンティックオーケストレーションのすべてを1つのスタックに統合し、エンタープライズグレードのセキュリティとオブザーバビリティが組み込まれていることこそが、これらのうち1つには優れていても残りは自分たちでつなぎ合わせる必要があるツールと、Elasticを一線を画す存在にしている理由です。

緊急事態管理、消防、法執行、公衆衛生のためのエージェント型地理空間対応

人、施設、リアルタイムイベントが交差するあらゆる場所に、同じアーキテクチャーが適用されます。特定のデータは変更され、パイプラインは変わりません。

緊急事態管理：FEMAや州の緊急事態管理局は、避難所の位置、集結地域、脆弱な人々を、到来する米国国立気象局（NWS）の悪天候ポリゴンと照らし合わせて地図化し、嵐が上陸する前にリソースの事前配置を自動的に開始できます。

消防・救急医療サービス：消防署は、部隊の位置や対応ゾーンを山火事の境界線や建物火災のクラスターに重ね合わせ、適切な装備を備えた最も近くの対応可能な部隊へ相互応援要請を自動的にルーティングできます。

法執行機関：機関は、進行中のインシデントの位置を学校区域、重要インフラ、警察官の位置と関連付け、手動でのトリアージを待たずに、位置情報を考慮したロックダウン通知やリソースの派遣をトリガーできます。

公立学校の安全対策：学区は、キャンパスの敷地境界に対するリアルタイムの脅威フィードを監視できます。脅威が学校の敷地境界に差し掛かった場合、ディスパッチャーが電話を取る前に、エージェントは直ちに管理者に通知し、ロックダウンの連絡を開始し、法執行機関の対応を調整できます。

公衆衛生：保健機関は、疾病監視データや環境有害区域を診療所の所在地、人口密度レイヤー、供給拠点の在庫と照合し、最も必要とされている場所にリソースを配分できます。

データはシナリオごとに異なります。取り込み、インデックス作成時のエンリッチメント、交差の検出、自律的な対応のトリガー、そしてアクションという根本的なパターンはすべて同じです。Elasticは、公共機関が一度構築すればどこでも適用できるプラットフォームを提供します。

本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。