Elasticで構築する次世代自律型ワークフロー ～ Agent Builderによるエージェント開発とWorkflowsによる統合管理 ～

AIエージェントは単体でも一定のタスクをこなせますが、1つのエージェントだけで解決できる範囲には限界があります。情報収集・分析・判断・実行といった複数の工程や専門性をまたぐ複雑なタスクに対応するには、役割の異なる複数のエージェントを協調・制御する「マルチエージェント・オーケストレーション」が不可欠です。

そして、その実装には高度な状態管理とプロセス設計が必要となります。Elasticでは、これを実現するための機能として「Elastic Workflows」を提供しています。また、そのオーケストレーションの構成要素となる「個々のエージェント」を開発するための機能として「Elastic Agent Builder」を提供しています。

本スライドでは、Elastic Workflows と Elastic Agent Builder を用いた AI エージェントの開発と、マルチエージェント・オーケストレーションの開発方法を徹底解説します。AI エージェントをどう作り、それをWorkflowsでどう束ねて制御するのか、アーキテクチャのベストプラクティスから想定ユースケースまで、次世代のAIアプリケーション開発に必須の知識を凝縮してお届けします。

Transcript

1. Elastic で構築する次世代自律型ワークフロー ～ Agent Builderによるエージェント開発とWorkflowsによる統合管理 ～ 2026/07/22 Principal Solution Architect (Search AI) 日山 雅之
2. コンテンツ Elastic で構築する次世代自律型ワークフロー 1. Elastic Agent Builder について 2. AI エージェント開発のキーポイント - エージェント定義のコツ - ツール定義のコツ - スキルの役割と定義のコツ 3. Elastic Workflows について 4. エージェントオーケストレーションのデザインパターンとキーポイント - どういうときに Workflows を使うべきか？ - ワークフローとエージェントの連携 - エージェントオーケストレーションパターン 5. Elastic Agent Builder / Workflows のユースケース - 利用事例 - Agents Builder / Workflows の主なユースケース
3. 本日お話しする内容 Elastic で構築する次世代自律型ワークフロー 1. Elastic Agent Builder について 2. AI エージェント開発のキーポイント - エージェント定義のコツ - ツール定義のコツ - スキルの役割と定義のコツ 3. Elastic Workflows について 4. エージェントオーケストレーションのデザインパターンとキーポイント - どういうときに Workflows を使うべきか？ - ワークフローとエージェントの連携 - エージェントオーケストレーションパターン 5. Elastic Agent Builder / Workflows のユースケース - 利用事例 - Agents Builder / Workflows の主なユースケース
4. Elastic Agent Builder とは Elasticsearch 上のデータを検索・分析しながら質問に答える AI エージェントを UI と設定だけで構築できる機能 - Elasticsearch 上のデータと対話する AI エージェントを構築できる機能 - 設定ベースの開発体験で、非構造化データからカスタムエージェントを迅速に構築 - LLM はモデル非依存で、好みのプロバイダーを自由に設定できる - MCP・A2A・API に対応し、外部のエージェントフレームワークとも連携可能 Elastic Agent Builder Kibana Agent との対話 UI AI Agent お客様のお気に入り Agent Elasticsearch Tool Agent のツール 自律的な推論, ツール操作, 回答 A2A でエージェント連携 検索インデックス ドキュメント検索 Tool MCP Server Agent のツール ⋯ MCPでツール連携 LLM 埋め込みモデル リランキングモデル Elastic Inference Service 外部ツール Elastic Workflows ワークフロー 定義された一連の処理
5. Elastic Agent Builder でのエージェントの定義のやり方 エージェント・ツール・スキル定義時に指定する主な項目 エージェント (Agents) ツール (Tools) スキル (Skills) Instruction (指示) Type (ツールタイプ) Name / Description エージェントの振る舞いの設計図となる指示 ツールがどうデータとやり取りするかの定義 エージェントが選択時に参照する短い説明 Tools (ツール割り当て) エージェントの行動能力を決めるツール選択 インデックス検索 ES|QL ワークフロー実行 MCP Instruction (指示) タスク遂行の具体的な手順の記述 Skills (スキル割り当て) Description (説明) Associted Tools 必要時だけ読み込まれるタスク別専門能力 エージェントのツール選択判断を導く記述 スキル発動中にエージェントが使えるツール群 - 目的を絞った専門エージェントほど性能・精度 が高い - 説明文の品質がツール選択の正確さを決定 - 説明文は常時コンテキストに載るため簡潔に - ツール数を最小限にしLLMの選択精度を保つ - ユースケースに合ったタイプを正しく選定 - 指示・ツール・参照情報を一体で設計 - トリガー条件とパラメータ制約を説明文に明記 - ライブラリで一元管理し複数エージェントで共 有 - 詳細な指示はスキルに移しエージェントへの指 示を軽く保つ
6. コンテンツ Elastic で構築する次世代自律型ワークフロー 1. Elastic Agent Builder について 2. AI エージェント開発のキーポイント - エージェント定義のコツ - ツール定義のコツ - スキルの役割と定義のコツ 3. Elastic Workflows について 4. エージェントオーケストレーションのデザインパターンとキーポイント - どういうときに Workflows を使うべきか？ - ワークフローとエージェントの連携 - エージェントオーケストレーションパターン 5. Elastic Agent Builder / Workflows のユースケース - 利用事例 - Agents Builder / Workflows の主なユースケース
7. エージェント定義のコツ エージェントは「単一目的 + 最小ツールセット」に絞る - 単一目的へ厳格にスコープ - Instruction と利用可能ツールの定義がすべて - 汎用アシスタント1つより、特化エキスパートを小さく作る - 指示 (Instructions) を構造化 - 「ペルソナ」「推論手順」「制約」「出力形式」の4セクションで記述 - 制約は「してはいけないこと」を明示 - 最小ツールセットに厳選 - 重複ツールは混乱 (tool confusion) の原因、1ツール1役割で厳選 - Llama 3.1 8bで46→19個に減らし性能向上させた実験結果あり - ツール付与＝公開範囲の決定 - 許可したツールがエージェントが触れる情報(インデックスなど)を決定 - この公開範囲の限定が、そのままセキュリティと信頼性を担保 AI Agent Builder: Creating specialized AI agents in Elasticsearch - Elasticsearch Labs What is context engineering? Components, techniques, and best practices - Elasticsearch Labs
8. ツール定義のコツ チームが行っている一連の作業手順・知識をエージェントの専門技能に変える - description の定義が最重要 - LLMがいつ・どうツールを使うかは、descriptionで決まる - 目的・使う/使わない場面・取得データ・制約を明記 - クエリは検証済みES|QLに固定 - クエリ本体は人間が作り込み、LLM はパラメータを埋めるだけにする - データを全件コンテキストに渡すと大半が失敗、集計を ES|QL に任せると成功率 100% (社内実験) - パラメータ数の最小化 - パラメータはLLMが埋める箇所。数を絞って設計 - 必須パラメータは5個未満、総数は10個未満が目安 - 返却値をKEEP/LIMITで絞り込み - KEEPで返すフィールドを厳選し、余計な情報を漏らさない、コンテキスト汚染となる - 全クエリ種別にLIMIT句で10〜20件の上限を設ける Database retrieval tools for context engineering - Elasticsearch Labs Relevance and its impact on context engineering - Elasticsearch Labs
9. スキルの役割と定義のコツ チームが行っている一連の作業手順・知識をエージェントの専門技能に変える - なぜスキルが必要か？ - エージェントの Instruction 内に、全タスクに対する詳細な指示を記述することは、望まれる動作をさせるために重要 - しかし Instruction が膨大となり、肥大化すると精度低下とコスト増に直結 - 各タスクへの詳細な指示は「スキル」として分離して定義、エージェントに該当タスクが来たときだけ読み込ませる - 何をスキルとして定義？ - 普段、AI エージェントにさせている、または人間が行っている一連の多段階のタスクを定義 - 特定タスクでのエージェントの動作方法 (作業手順, 出力形式 など) を構造化して記述 - 例: セキュリティのトリアージ手順、SREの根本原因分析の進め方 - スキル定義のコツ - すべてをカバーする巨大なスキルにせずタスク単位のモジュールに分割 - 各Skillにはそのドメインに必要なコンテキストだけを過不足なく持たせる (ES|QL用、ダッシュボード用など) エージェント (Agents) Instruction 利用可能ツール 必要に応じて呼び出す 疎結合で再利用しやすい スキル (Skills) ツール (Tools)
10. コンテンツ Elastic で構築する次世代自律型ワークフロー 1. Elastic Agent Builder について 2. AI エージェント開発のキーポイント - エージェント定義のコツ - ツール定義のコツ - スキルの役割と定義のコツ 3. Elastic Workflows について 4. エージェントオーケストレーションのデザインパターンとキーポイント - どういうときに Workflows を使うべきか？ - ワークフローとエージェントの連携 - エージェントオーケストレーションパターン 5. Elastic Agent Builder / Workflows のユースケース - 利用事例 - Agents Builder / Workflows の主なユースケース
11. Elastic Workflows とは Elasticsearch に組み込まれた YAML 定義の宣言的自動化エンジン - 概要 - 「ルールベースの自動化」と「AIによる生成と判断」の確実性と柔軟性 を兼ね備えたタスク自動化を実現 Trigger 手動 実行 スケジュール 実行 アラート 発生時 イベント 駆動 - AI エージェントオーケストレーション の実現 - 特徴 - 大きく「Trigger」「Steps」「Connectors」の３要素で構成 - Elastic Agent Builder や Slack/Jira 等コネクターと連携して活用 - 主な利用シーン - セキュリティ調査・オブザーバビリティの根本原因分析を効率化 - 定期的なデータ収集や ITシステムマネジメント業務の自動実行 - 料金 - 実行数課金 (1実行=約1.74円, 1万実行分は無料) Steps エージェント 実行 ワークフロー 実行 Elastic 検索 データ 変換 HTTP 呼び出し Connectors ・・・ フロー制御 if, switch, foreach, while, loop.break, look.continue / wait, human-in-the-loop Connectors ・・・
12. ワークフローの定義方法 YAML による確実性と柔軟性を兼ね備えたワークフロー定義 - 定義方法 - YAML で定義 - 「何をするか」だけ書く宣言型 - 実行・エラー処理・記録は基盤が担当 - 構成要素は３つだけ - トリガー: アラート・定期・手動 - インプット: 実行時パラメータ - ステップ: 順に実行する処理の列 - データの受け渡し - ステップ間は {{ }} で値を参照 - 前の出力を steps.名前.output で取得 - 記法は Liquid テンプレート
13. コンテンツ Elastic で構築する次世代自律型ワークフロー 1. Elastic Agent Builder について 2. AI エージェント開発のキーポイント - エージェント定義のコツ - ツール定義のコツ - スキルの役割と定義のコツ 3. Elastic Workflows について 4. エージェントオーケストレーションのデザインパターンとキーポイント - どういうときに Workflows を使うべきか？ - ワークフローとエージェントの連携 - エージェントオーケストレーションパターン 5. Elastic Agent Builder / Workflows のユースケース - 利用事例 - Agents Builder / Workflows の主なユースケース
14. どういうときに Workflows を使うべきか？ - 基本はエージェント単体でスタートし、探索や推論が中心のうちはそのまま運用 - 「同じ手順を確実に繰り返したい」「実行の監査証跡が欲しい」という要件が出てきた段階で、Workflows の導入を検討 エージェントすら不要 - 単一の検索・集計だけで答えが出る質問には、エージェントを介さず ES|QL クエリを直接実行すれば十分 - 「最もアクセスの多いページは？」のような、1回の集計で答えが確定する質問 ワークフローのみを使用（決定論的な自動化） - 手順が既知で「毎回同じように実行されるべき」プロセス、つまり監査可能性・再現性・信頼性が要件のケース - セキュリティのプライブック自動化、ケースのライフサイクル管理、インデックス運用、外部システム連携の提携処理 など エージェントのみを使用（探索的な推論） - 事前に手順を決められず、調べながら次の一手を判断する必要があるタスクは、エージェントに推論・探索させるのが適してる - 会話型のデータ探索・分析、脅威ハンティング/調査、エージェンティックなダッシュボード作成 など ワークフロー × エージェントを使用 - 推論はエージェント、実行はワークフローという責務分離で、判断の柔軟性と実行の安全性・監査証跡を両取りする構成 - SOCトリアージ自動化、自然言語からの決定論的アクション、プレイブック未定義シナリオのフォールバック など
15. ワークフローとエージェントの連携 エージェントか Workflows かではなく、両者を組み合わせる エージェントからワークフローを呼び出す Workflows as agent tools ワークフローからエージェントを呼び出す Agents as workflow steps - 対話起点が中心 (つまりチャットから呼び出す) - イベント起点が中心 (つまりアラート等をトリガに呼び出す) - 「何をすべきか」の判断は都度必要だが、「どうやるか」は既 知の反復可能な手順に従うべき時に採用 - フローの途中に「見つけた内容によって正しいアクションが変わ る」分析・判断の区間がある時に採用 - 判断と実行の分離により毎回同一手順・監査可能で、同じ ワークフローを複数エージェント・手動実行で再利用できる - 人手で行っていた初期分析・調査を自動化に組み込め、同 じロジックを複数トリガーから共用できる - 利用シーン - 利用シーン - IT リクエスト自動化 - 障害/セキュリティアラート対応の自動一次対応 - レストラン予約や修理手配などの対顧客手続き - LLM クエリルーティング - インシデント宣言・対応開始の定型化 - アラートやメトリクスの AI 要約 Building automation with Elastic Workflows - Elasticsearch Labs
16. エージェントオーケストレーションパターン 用途に合わせた AI エージェントの組み合わせパターンを選択する 逐次 / Sequential 並列 / Parallel 監督 / Supervisor 直列実行、前段の出力が次段の入力 同時実行して結果を集約 中央が指示・集約、ワーカーが実行 パイプライン処理 など 複数ソースの同時検索 など 複数ツール(別の役割)の並列実行の管理 など ルーティング / Routing 自己改善 / Reflection Agent-as-Tool 入力を分類して振り分け 生成 → 評価 → 修正の自己改善ループ 別エージェントをツールとして呼び出し クエリの意図別転送 など レポート生成(品質基準チェック付き) など 専門処理の委譲と再利用 など
17. コンテンツ Elastic で構築する次世代自律型ワークフロー 1. Elastic Agent Builder について 2. AI エージェント開発のキーポイント - エージェント定義のコツ - ツール定義のコツ - スキルの役割と定義のコツ 3. Elastic Workflows について 4. エージェントオーケストレーションのデザインパターンとキーポイント - どういうときに Workflows を使うべきか？ - ワークフローとエージェントの連携 - エージェントオーケストレーションパターン 5. Elastic Agent Builder / Workflows のユースケース - 利用事例 - Agents Builder / Workflows の主なユースケース
18. 利用事例: Visa 様 対象の業務 課題 世界最大の決済ネットワーク企業 - SOC におけるメインフレームの高リスク ID 検出アラートのトリアージ業務 - アラート発動のたびにアナリストがレガシー SIEM にログイン SOC 初の AI ワークフローを構築 メインフレーム検出のアラートトリアージ を10〜20分から数秒に短縮 - アラート発生後に IR チームが実施する、 端末からユーザーを特定するための2次ク エリーとコンテキスト収集作業 - 端末の直近ログインを調べる2次クエリー を手動で実行する必要があり、1件あたり 10〜20分のトリアージ時間が発生 - Visa SOCのメインフレーム高リスクID検出のトリアージを自動化 - 手動2次クエリーに毎回10〜20分かかり、 アナリストのスキル差で品質もばらつき - Elastic Workflows で 検出 → エンリッチメント → AI検証 → 配信の4段階パイプラインを構築 - 制約付きLLMで検証・要約し、 Webhookで IRチケットシステムへ自動配信 - トリアージが10〜20分から数秒に短縮され、品質も標準化 - メインフレームログへの習熟度がアナリスト ごとに異なり、トリアージの所要時間と品 質に大きなばらつき 導入内容 導入効果 - Elastic Workflows 上に、検出ES|QLク エリ、LLM による検証・要約、Webhook による IR チケットシステムへの配信、という パイプラインを構築 - アラートトリアージが10〜20分から数秒に 短縮 - エージェントには直近5〜15分のデータのみ を渡すコンテキストウィンドウ制御を適用、 自由形式の分析を排除して監査可能性 を確保 - IR チームは生シグナルの組み立て作業か ら解放され、意思決定の準備が整った文 脈付きチケットを即座に受け取れるように - 個人のスキル依存が排除され、トリアージ 品質が標準化されるとともに、同じ4段階 パターンが他の検出にも再利用可能に Visaの最初のElastic Workflowsが、制御されたヒューマンオンザループのAIステップにより、アラートのトリアージを10〜20分から数秒に短縮した方法 | Elastic Customers
19. 利用事例: Visa 様 Elastic Workflows で SOC 初の AI ワークフローを構築、メインフレーム検出のアラートトリアージを10〜20分から数秒に短縮 導入前 導入後 アラート管理 対象のユーザーを特定するために、 追跡調査を必要とする生イベント 意思決定の準備が整えられ、強化された、AIに よって要約されたチケットがIRに到達 運用コスト 2回目の検索作業およびメインフレームログの解析で、1回の アラートあたり10〜20分 全工程が秒単位 調査の流れ アラート後、別のツールで2次クエリーを実行 単一の連鎖したワークフローで検出、強化、検証、 提供 アナリストのスキル との依存関係 経験豊富なアナリストは迅速に対応できる一方、従来のク エリ言語とメインフレームのイベントコードにより、経験の浅い アナリストは処理が遅い 体系的な要約は、レガシークエリ言語への習熟 度依存を排除 ツールの限界 レガシーSIEMでのアラート、レガシーSIEMでのフォローアップ、 別のオーケストレーションツールでのチケット 検出、強化、検証、配信はすべてElasticにネイ ティブで、IRチケットシステムへのWebhookハンド オフも可能 アナリストの役割 手動コンテキスト収集、2回目の検索実行、メインフレームロ グの解釈 体系的なケースを読み、結果を判断し、エスカ レーションする Visaの最初のElastic Workflowsが、制御されたヒューマンオンザループのAIステップにより、アラートのトリアージを10〜20分から数秒に短縮した方法 | Elastic Customers
20. Agents Builder / Workflows の主なユースケース Elasticsearch LLM クエリルーティングによるコスト・レイテンシ最適化 - Workflow が検索結果のメタデータからクエリの複雑度を判定し、条件分岐で適切な LLM にルーティング - 条件分岐により単純クエリは Mistral Small、複合クエリは Claude Sonnet にルーティングしコストを最適化 - Agent Builder に Workflow をツールとして登録することで、API と会話 UI の両方から同じルーティングを利用可能に Observability Kubernetes Pod 障害の自動検出・分析・修復提案 - Agent Builder で ES|QL クエリをラップしたカスタムツール群を定義し、Pod 再起動・OOMKilled の検出やリソース分析を行う - エージェントの指示に閾値（60% 警告 / 80% 危険）を設定し、超過サービスへの修復ステップを自動提案させる - Workflow 化することでアラート発火時に人手なしで同じ分析・提案フローを自動実行できる Security APT 攻撃の自動確認・インシデント対応の高速化 - Workflow が Attack Discovery の発見をトリガーに自動起動し、確認フローを開始 - Agent Builder のエージェントが VirusTotal 照合・ES|QL ログ検索・脅威インテリジェンス突合を自律実行 - Security Labs の検証では、DLL サイドローディングの APT シナリオで従来 2〜6 時間の確認を 4 分以内に短縮 LLM query routing in Elasticsearch with Elastic Workflows - Elasticsearch Labs How to Troubleshoot Kubernetes Pod Restarts & OOMKilled Events with Agent Builder — Elastic Observability Labs Speeding APT Attack Confirmation with Attack Discovery, Workflows, and Agent Builder — Elastic Security Labs