Elastic Workflowsはバージョン9.4で一般提供開始となりました。これはElasticに直接組み込まれた自動化レイヤーであり、セキュリティ、オブザーバビリティ、検索など、データが存在するあらゆる場所で実行されます。この記事ではセキュリティの詳細に焦点を当てていますが、同じワークフロー機能はすべてのソリューションに適用でき、別途プラットフォームを導入したり、データを移動したりする必要はありません。アラートが発生したり、スケジュールがトリガーされたりすると、ワークフローが実行されます。ワークフローでは、Elasticsearchへのクエリ実行、脅威インテリジェンスによるデータの拡充、ケースの作成、外部APIの呼び出し、およびチームへの通知が行われます。YAMLで定義するか、自然言語で記述すれば、AIがワークフローを生成してくれる。
Elastic 9.3 テクニカルプレビューでは、Elasticにおけるネイティブ自動化の基盤が導入されました。バージョン9.4では、本番環境での安定性と大幅に拡張された機能を備え、一般提供が開始されます。ケース管理には、ライフサイクル全体を網羅する 25 の専用の自動化ステップが用意されています。ヒューマン・イン・ザ・ループは、ワークフローにおける第一級の基本要素となる。自然言語によるオーサリング機能がテクニカルプレビュー版に移行しました。プラットフォームは、より多くのフロー制御プリミティブ（ while 、 switch 、反復制御）、コレクションを操作するためのデータ変換ステップ、 Agent Builderとのより深いAI統合、およびより広範なイベント駆動型トリガーを獲得します。Elastic製品全体にわたる、本番環境に対応した自動化ソリューション。
大規模なケース自動化
セキュリティチームにとって最大の追加機能は、ケース管理機能です。テクニカルプレビュー版では、ケースの操作は、作成、取得、更新、コメントという4つの一般的な手順で構成されていました。それ以上のことは、生のAPI呼び出しが必要だった。
現在、ライフサイクル全体を網羅する専用のステップが 25 cases.* 、作成、検索、類似の検索、更新、クローズ、割り当て、割り当て解除、アラートの追加、オブザーバブルの追加、コメントの追加、タグの追加、重要度の設定、ステータスの設定など、さまざまなステップがあります。各ステップは入力され、検証され、YAMLエディタのオートコンプリートに表示されるため、自然言語による作成でも正確に生成できます。
現実的なトリアージのワークフローは以下のようになります。警報が発令される。ワークフローは、このアラートに対して既にケースが存在するかどうかを確認します。そうでない場合は、アラートを作成し、アラートと観測対象を添付し、オンコールアナリストを割り当て、リスクスコアに基づいて重大度をルーティングします。
以下のコードは、YAMLを使用して記述されたワークフローの例を示しています。
name: Triage Workflow
enabled: true
triggers:
- type: alert
steps:
- name: check_existing
type: cases.getCasesByAlertId
with:
alert_id: "{{ event.alerts[0]._id }}"
- name: route
type: if
condition: "steps.check_existing.output : ''"
steps:
- name: update_existing
type: cases.addComment
with:
case_id: "{{ steps.check_existing.output[0].id }}"
comment: |
Correlated alert: {{ event.rule.name }}
Source: {{ event.alerts[0].source.ip | default: "unknown" }}
Risk score: {{ event.alerts[0].kibana.alert.risk_score }}
else:
- name: create_case
type: cases.createCase
with:
owner: securitySolution
title: "{{ event.rule.name }} - {{ event.alerts[0].host.name }}"
description: |
Auto-created from detection rule: {{ event.rule.name }}
Host: {{ event.alerts[0].host.name }}
Source IP: {{ event.alerts[0].source.ip | default: "N/A" }}
severity: high
tags:
- auto-triage
- "{{ event.rule.name }}"
- name: attach_evidence
type: cases.addAlerts
with:
case_id: "{{steps.create_case.output.case.id}}"
alerts:
- alertId: "{{ event.alerts[0]._id }}"
index: "{{ event.alerts[0]._index }}"
- name: add_observables
type: cases.addObservables
with:
case_id: "{{steps.create_case.output.case.id}}"
observables:
- typeKey: observable-type-ipv4
value: "{{ event.alerts[0].source.ip }}"
- typeKey: observable-type-file-hash
value: "{{ event.alerts[0].file.hash.sha256 }}"
on-failure:
continue: trueワークフローは、重複排除、証拠の添付、観測可能なデータの拡充、欠落フィールドの適切な処理、およびアナリストの割り当てを自動的に処理します。アナリストがKibanaを開くと、すべてのコンテキストが既に含まれたケースが表示される。
25 新しいcases.*ステップには、カスタム フィールド、ユーザー アクション、およびメトリックに対して、作成、検索、類似の検索、更新、閉じる、削除、割り当て、割り当て解除、アラートの追加/削除、オブザーバブルの追加/削除、コメントの追加/更新/削除、タグの追加/削除、重要度の設定、ステータスの設定、ID による取得、アラート ID による取得などが含まれます。各手順は入力され、検証されます。自然言語によるオーサリングを使用している場合、それらはスキーマの一部であるため、AIは正確に生成できます。
ワークフローが成熟するにつれて、検出ルールの管理、エンドポイントの応答アクション、脅威インテリジェンス運用など、ドメイン固有の手順が増えていきます。
自動化されたワークフローにおける人間のチェックポイント
ケース自動化は機械的な作業を担うが、すべての意思決定を完全に自動化する必要はない。AIはアラートを分類し、コンテキストを収集することはできるが、エスカレーションするかどうかはアナリストが判断する必要がある。問題は、彼らがその判断を下すまでにどれだけの機械的な作業が行われるかということだ。
waitForInput ワークフローを一時停止し、人間の判断を待つ。ワークフローは、調査を実行し、証拠を収集し、AIを使用してアラートを分類し、停止します。構造化された調査結果を提示し、結果を待つ。アナリストは内容を確認、承認、または転送し、メモを追加する。その後、アナリストの入力に基づいてワークフローが再開される。
次の図に示すように、自動化システムは調査を処理しますが、アナリストは自動化システムが実行する前に決定を下します。
受信したアラートをAIで分類し、アナリストによるレビューと承認のために一時停止し、承認されたケースのみを、モデルとアナリストの両方からのコンテキストを含む重大度の高いインシデントとしてエスカレーションします。
name: HITL Example
enabled: true
triggers:
- type: alert
steps:
- name: classify
type: ai.classify
connector-id: Anthropic-Claude-Sonnet-4-6
with:
includeRationale: true
input: ${{ event.alerts[0] }}
categories:
- true_positive
- false_positive
- needs_investigation
- name: approval_gate
type: waitForInput
with:
message: |
Alert: {{ event.rule.name }}
Classification: {{ steps.classify.output.category }}
Rationale: {{ steps.classify.output.rationale }}
Review the classification and approve to escalate.
schema:
type: object
properties:
approved:
type: boolean
title: Approve escalation
notes:
type: string
title: Analyst notes
required:
- approved
- name: escalate
type: if
condition: "steps.approval_gate.output.approved : true"
steps:
- name: create_escalated_case
type: cases.createCase
with:
owner: securitySolution
title: "[Escalated] {{ event.rule.name }}"
description: |
Escalated by analyst after AI classification.
Classification: {{ steps.classify.output.category }}
Notes: {{ steps.approval_gate.output.notes }}
severity: high
tags:
- escalated
- analyst-reviewed現在、 waitForInput Kibana実行ビューとREST APIを通じて動作します。Slack、Teams、およびメール配信チャネルが導入されることで、アナリストはコンテキストを切り替えることなくレビューと承認を行えるようになる。これは、エージェントビルダーでツールとして定義されているワークフローにとって特に重要です。エージェント主導の調査では、行動を起こす前に人間のチェックポイントがあることでメリットが得られます。
自然言語からワークフローを構築する
自動化パターンが確立されたら、次の課題はそれらを誰もが利用できるようにすることです。ワークフロー言語としてYAMLを選んだ理由は、宣言型であり、レビューしやすく、移植性が高いからです。しかし、それは戦略的な選択でもありました。YAMLは構造化テキストであり、大規模な言語モデルは構造化テキストの生成に非常に優れているからです。型付けが適切に行われたワークフロースキーマは、AIを活用したオーサリングにとって理想的な対象である。9.4では、その賭けが報われる。自然言語による文章作成機能は、テクニカルプレビュー版で利用可能です。
ワークフローエディタ内で、実行すべき処理を記述します。「マルウェアアラートが発生したら、ファイルのハッシュをVirusTotalでチェックし、重大度の高いケースを作成し、アラートと観測データを添付して、SOCチャネルに通知する。」AIアシスタントがYAMLファイルを生成します。レビュー、改良、そして展開を行います。
YAMLファイルは完全に検査および編集可能です。何が起こるべきかは分かっているが、YAMLのエキスパートではない場合、この方法を使えば、意図を実際のワークフローに落とし込むことができます。YAMLのエキスパートであれば、自然言語で記述を開始し、エディタで推敲することができます。
執筆体験は今後も進化し続けるでしょう。ビジュアル編集は補完的な手法である。Slackやチームが使用するその他のツールにも対応したコンテンツ作成機能。目標は、セキュリティチームがどこで働いていようとも、彼らと出会うことです。
構成可能なワークフロー
自動化ライブラリが大きくなるにつれて、整理整頓が非常に重要になってきます。セキュリティ自動化はすぐに複雑化する。最初は単一のトリアージワークフローから始めますが、アラートの種類によって調査手順が異なることに気づきます。条件分岐を追加し、さらに条件分岐を追加していくと、突然ワークフローは何百行にも及ぶネストされたロジックで構成され、理解しにくく、変更も困難になる。
workflow.execute 型付きの入力と出力を使用して、再利用可能なワークフローを構築できます。調査ロジックをすべて一箇所に埋め込むのではなく、特定のシナリオに特化したワークフローを作成し、それらを組み合わせて使用します。マルウェア調査ワークフローを一度更新すれば、それを呼び出すすべてのワークフローが恩恵を受けます。ロジックは整理されたまま維持され、変更は限定的に抑えられ、自動化は脆弱になることなく拡張できます。
実際にやってみると、こんな感じになります。アラートを分類し、脅威の種類に基づいて専用のワークフローにルーティングします。
steps:
- name: dispatch
type: switch
expression: "{{ steps.classify.output.category }}"
cases:
- match: malware
steps:
- name: run_malware
type: workflow.execute
with:
workflow-id: ${{ consts.malware_workflow_id }}
inputs:
alert: ${{ event.alerts[0] }}
- match: phishing
steps:
- name: run_phishing
type: workflow.execute
with:
workflow-id: ${{ consts.phishing_workflow_id }}
inputs:
alert: ${{ event.alerts[0] }}
default:
- name: run_generic
type: workflow.execute
with:
workflow-id: ${{ consts.generic_triage_id }}
inputs:
alert: ${{ event.alerts[0] }}各ワークフローは個別にテスト可能です。ほとんどのチームは、まず単一のワークフローから始め、パターンが現れるにつれてサブワークフローを抽出していく。作曲は、時間をかけて身につけていくものだ。
テンプレートライブラリは最終的に製品に統合され、Kibana内で事前に構築されたワークフローを直接検索してインストールできるようになります。
アナリストが既に働いている場所
ワークフローは、意思決定が行われる場所で利用できる場合に最も効果を発揮します。基本的な要素やパターンは揃っているが、自動化が真に価値を発揮するのは、アナリストがツールを切り替えることなく自動化にアクセスできる場合に限られる。私たちは、アラートテーブルと攻撃検出を皮切りに、セキュリティアナリストの業務全体を通してワークフローにアクセスしやすくするための投資を行っています。アナリストは、アラートや攻撃全体をワークフローに直接送信することで、現在の作業環境から離れることなく、構築済みの調査ロジックをトリガーできます。この統合は今後も拡大を続け、ワークフローの自動化がアナリストの日常業務にシームレスに組み込まれ、独立した作業ではなくなるようにしていく予定です。
アラートテーブルの「ワークフローの実行」では、アラートを右クリック（または複数選択）して、ワークフローを直接トリガーできます。アラートコンテキストは自動的に渡されます。
これは始まりに過ぎない。ワークフローはセキュリティ業務のより多くの部分に拡大し続け、アナリストが必要とする場所で自動化を利用できるようになるでしょう。
より優れた制御、より優れた柔軟性
主要な機能以外にも、ワークフロー言語自体の機能が向上しました。新しいフロー制御プリミティブにより、複雑なロジックをより簡潔に処理できるようになります。whileループを使用すると、条件をポーリングしたり、外部の状態変化を待ったりすることができます。switch多方向分岐を提供するため、ネストされた条件なしでカテゴリ別にアラートをルーティングできます。loop.breakとloop.continue標準的な反復制御を提供します。
ステップレベルのデータ変換ステップは、コレクションに対するフィルタリング、検索、集計、およびJSON操作を処理するため、カスタムスクリプトを作成することなく、アラートリスト、IOCルックアップ、およびエンリッチメントレスポンスを処理できます。
AIステップ（ ai.prompt 、 ai.classify 、 ai.summarize 、 ai.agent ）はより安定し、構造化された出力をサポートするようになったため、下流のワークフローロジックでAIが生成した分類と要約をより簡単に使用できるようになりました。
LiquidJSのテンプレート機能も拡張されました。変数を設定してワークフロー全体でアクセスできるようになったため、複数のステップにわたって計算値を参照することが容易になりました。
信頼性と生産管理
これらはすべて、信頼できる場合にのみ有用である。すべてのステップはon-failure構成をサポートしています。一時的な障害が発生した場合は再試行し、ステップが重要でない場合は続行し、後続のステップが結果に依存する場合は中止します。エラーの詳細については、 steps.<step-id>.errorを参照してください。エラーが発生した場合の回避策として役立ちます。
並行処理制御により、アラートの大量発生によって数百もの並列実行が生じるのを防ぎます。ループ状のガードレールは、暴走した処刑を防ぐ。構成の深さ制限により、無限再帰が防止されます。
Elastic 9.4 では、 workflows.failedから始まるイベント駆動型トリガーが導入されます。ワークフローの実行が失敗した場合、別のハンドラーワークフローがトリガーされることがあります。自動化システムがダウンした際にチームに通知するワークフローを構築しましょう。今後、ケースステータスの変更、アラート状態の遷移、検出ルールの更新など、より多くのトリガータイプが追加される予定です。これにより、ワークフローはセキュリティ環境全体で発生する事象に迅速に対応できるようになります。
すべての実行は、 waitForInputステップからのアナリストの決定を含む、ステップごとの結果とともに実行履歴に記録されます。これはデバッグツールであり、監査証跡でもあります。
ワークフロー機能は、エンタープライズライセンスをお持ちの場合、バージョン9.4でデフォルトで有効になっています。きめ細かなRBAC（ロールベースアクセス制御）により、ワークフローの作成、編集、実行、および閲覧を行うユーザーを制御できます。すべての管理操作は、セキュリティ監査ログに書き込まれます。インポート/エクスポート機能を使用すると、コネクタ参照を維持したまま、ワークフローを環境間で移動できます。
ライセンスと価格設定
Workflowsは、Elastic Cloud HostedおよびセルフマネージドデプロイメントではEnterpriseライセンスで利用可能であり、Elastic Cloud Serverless for SecurityプロジェクトではCompleteティアで利用可能です。
バージョン9.4では、すべての導入形態において、実行ベースの統一料金モデルが導入されます。
サーバーレス、エラスティッククラウドホスティング、セルフマネージドのいずれの形態においても、料金はワークフローの実行回数に基づいており、規模に応じてボリュームディスカウントが適用されます。毎月、請求対象外となるワークフロー実行の基準割り当てが含まれています。この割り当て量を超えた使用量については、実行ごとに課金され、使用量が増えるにつれてボリュームディスカウントが適用されます。
Elastic Cloud Serverless は、 5 月1 、 2026からこのモデルの適用を開始します。月間課金対象外の実行回数を超える利用については、実行回数ごとに課金されますが、利用回数が多いほど割引が適用されます。料金の詳細はこちらをご覧ください。
Elastic Cloudのホスト型デプロイメントとセルフマネージド型デプロイメントは同じ料金体系に従いますが、現在はプロモーション期間中のため、実行料金はまだ適用されていません。これにより、チームはワークフローを構築・実行し、利用パターンを確立し、将来のリリースにおける実行ベースの課金への移行に備えることができます。
今すぐ建設を始めましょう。現在作成されているワークフローは、価格設定が統合モデルに移行した後も引き続き実行されます。
開始する
ワークフローはバージョン9.4でデフォルトで有効になっています。Kibanaを開き、「ワークフロー」に移動して、構築を開始します。
ワークフローを初めて使用する場合は、テクニカルプレビューの記事で最初のトリアージワークフローの構築方法を解説しています。Chrysalis APTのワークフローは、 Agent Builderとの統合が実際にどのように機能するかを示しています。ドキュメントには、ステップタイプの完全なリファレンスが記載されています。Elastic Workflow Libraryには、すぐに使えるテンプレートが用意されています。
まずは、今週チームの時間を最も節約できるワークフローから始めましょう。言葉で説明できれば、何でも作れる。
本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。