チャットボックスを超えたエージェントビルダー：Augmented Infrastructureの導入

これは机上の空論ではなく、私たちはすでに行動しています。

私たちは皆、AIエージェントの台頭を見てきました。テキストを要約したり、コードスニペットを書いたり、ドキュメントに基づいて質問に答えたりするのが得意です。しかし、DevOpsやサイト信頼性エンジニアリング（SRE）に携わる者にとっては、もどかしい制限がありました。ほとんどのエージェントは、コールセンターのパラダイムに囚われています。つまり、読んだり、考えたり、チャットしたりすることはできても、手を伸ばして本来管理すべきインフラに触れることはできないのです。

最新のハッカソンプロジェクトでは、その制限を打ち破ることを目指しました。

私たちは、インフラのコパイロットであるAugmented Infrastructureを開発しました。これは、アドバイスを提供するだけでなく、稼働中の環境の構築、デプロイ、監視、および修正も行います。

問題点：コピー、再フォーマット、貼り付け

標準的なエージェントは、密閉空間で活動しています。アプリがダウンして会社に500万ドルの損害をもたらした場合、標準的なエージェントは、修正方法についての手順書を読み上げることができます。しかし、その作業を行うのがあなたであることは変わりません。コードをコピーして、自分の環境に合わせてフォーマットし直し、ターミナルに貼り付ける作業が残っています。

私たちは、Kubernetesについて話すことと、Kubernetesを設定することの違いを理解するエージェントが欲しいと考えていました。

エンジン：Elastic Agent Builderとは？

これを構築するにあたって、私たちはゼロから始めたわけではありません。Elastic Agent Builderを基盤として構築しました。Elastic Agent Builderをご存知ない方のために説明すると、これはエージェントを迅速に開発するために設計されたフレームワークであり、大規模言語モデル（LLM）（今回のデモではGoogle Geminiを使用）とElasticsearchに保存されているプライベートデータとの間の橋渡し役を果たします。

Agent Builderは、ドキュメントやログなどの内部データを基盤として、会話型AIに活用できます。しかし、最も強力な機能はツールを割り当てる機能です。これらのツールにより、LLMはチャットインターフェースに留まらず、特定のタスクを実行できます。この機能を可能な限り活用すれば、Agent Builderを自動化の強力なツールに変えることができることに気付きました。

成功のために：初期バージョンの構築

プロジェクトを開始した当初から、エージェントが外の世界を変えられるようにしたいと考えていました。私たちはあるアイデアを思いつきました。エージェントがホスト上で考えられる任意のコマンドを実行する「ランナー」ソフトウェアを構築したらどうなるでしょうか？そして、ランナーであるElastic Agent Builderとユーザーが三者通話をしていたらどうなるでしょうか？

まず、Augmented Infrastructure RunnersというPythonプロジェクトを構築しました。これは本質的に、Elastic Agent Builderの会話APIを毎秒クエリし、当社が作成した特別な構文があるかどうかを確認するwhile(true)ループでした。

次に、新しいツール呼び出し構文を認識させるために、プロンプトを更新しました。ビルはFastMCPのメンテナーです。FastMCPは、PythonでModel Context Protocol（MCP）サーバーを構築する目的において最も人気のあるフレームワークです。彼は、この新しいランナーソフトウェアとFastMCPクライアントを使用して、MCPサーバーをマウントし、ランナーがそのツールを利用できるようにするための作業に着手しました。エージェントがこれを確認するとツール呼び出しを実行し、結果をユーザーが送信したかのように会話に POST で返します。これがきっかけでLLMは結果に反応し、私たちの取り組みが加速したのです。

これは素晴らしい考えでしたが、主に2つの問題がありました。

1. エージェントは、このJSONすべてをユーザーとの会話に直接吐き出します。
2. メッセージが会話APIを通じて表示される最も早い時点は、会話ラウンドが完了したとき（つまり、LLMが応答したとき）でした。

そこで、これをバックグラウンドに移動させる方法を模索することにしました。

次に、エージェントに call_external_tool というツールを与え、tool_name と文字列化されたJSONツール引数の2つの引数を持たせるように変更しました。この外部ツール呼び出しは何も返しませんが、重要なのは会話APIへの GET リクエストで確認できることです。その後、ランナーにElasticsearchに直接ドキュメントを書き込む許可を与えました。Elastic Agent Builderのエージェントは必要に応じてそれを取得できました。エージェントは常にユーザーのメッセージに対応して動作しているため、結果を検索し、処理を続行するようにエージェントをユーザーのメッセージで起動させる必要があります。そこで、会話を再開するために、エージェントにチャットに短いメッセージを挿入させました。

これで、外部ツールの呼び出しが行われました。しかし、前述の2つ目の問題のため、最後のキックスタート部分を削除せざるを得ませんでした。それをしなければ、外部ツールを呼び出すたびに、結果を取得するためにもう一度会話をすべてやり直す必要があったためです。

優れたものにするために：ワークフローの導入

Elasticsearch Query Language（ES|QL）とインデックス検索ツールの呼び出しに加え、Agent BuilderエージェントはElasticのワークフローベースのツールを呼び出すことができます。Elasticのワークフローは、任意のアクションのシーケンスとロジックを実行するための柔軟で管理しやすい方法を提供します。私たちの目的では、ワークフローに必要なのは、Elasticsearchに外部ツールのリクエストを格納することと、結果をポーリングするためのIDを返すことだけです。これにより、以下の簡単なワークフロー定義が得られます。

それにより、会話に書き込まれるツール呼び出しリクエストに依存する代わりに、ランナーはElasticsearch distributed-tool-requestsインデックスをポーリングして新しい外部ツールリクエストを検索し、結果を指定されたexecution.idを使用して別のElasticsearchインデックスにレポートすることができます。

これにより、上記の2つの主な問題が解消されます。

1. 会話履歴に外部ツール呼び出しのペイロードが散乱することはなくなりました。
2. ランナーは会話履歴ではなくElasticsearchインデックスをポーリングしているため、外部ツールのリクエストが表示されるようになるまで、会話のラウンドが完了するのを待つ必要がなく、ブロックされることはありません。

2つ目の点には、外部ツール呼び出しの処理が（会話ラウンドが完了した後ではなく）エージェントの思考フェーズ内で開始されるという大きな利点があります。これにより、システムプロンプトでLLMに外部ツールの結果が利用可能になるまでポーリングするように指示できレガシ、キックスタートメッセージが不要になります。全体として、これにより会話がより自然に感じられるという良い効果があります。LLMは（ツールリクエストごとに1回の会話ラウンドを必要とするのではなく）1回の会話ラウンドで複数の外部ツールリクエストを処理できるため、より複雑なユーザーリクエストを一度に達成できます。

すべてを集約

LLMとサーバーラックの間のギャップを埋めるために、Agent Builderのツール機能を使用してある特定のアーキテクチャを開発しました。

1. Augmented Infrastructureのランナー：ターゲット環境（サーバー、Kubernetesクラスター、クラウドアカウント）内に軽量ランナーをデプロイしました。これらのランナーは、各ランナーだけが利用できる安全なエンドポイントとシークレットを使用して、Elasticに直接接続されています。
2. ES|QL検索：コパイロットはElasticのES|QLを使用してハイブリッド検索を行います。単に知識を検索するだけではなく、機能を検索します。接続されたランナーに問い合わせて利用可能なツールを確認します（例：list_ec2_instances、install_helm_chart）。
3. ワークフローの実行：エージェントが行動方針を決定すると、構造化されたワークフローを作成します。
4. フィードバックループ：ランナーはローカルでコマンドを実行し、その結果をElasticsearchにレポートします。コパイロットはインデックスの結果を読み取り、次のステップを決定します。

デモ：停止からオブザーバビリティへ

動画では、このアーキテクチャの影響力を示す2つの異なるシナリオを紹介しました。

シナリオ1：DevOpsの救出

私たちは、Kubernetesクラスター内の死角によって引き起こされた500万ドルの障害に関連してパニックに陥ったユーザーから取り組み始めました。

• リクエスト：「このようなことが二度と起こらないようにするにはどうすればよいでしょうか？」
• アクション：エージェントは単にチュートリアルを提供するだけではありませんでした。クラスターを識別し、必要な名前空間を作成し、Kubernetesシークレットを生成し、OpenTelemetry Operatorをインストールして、ライブAPMダッシュボードへのリンクを即座に提供しました。
• 結果：ユーザーがYAMLコードを一行も記述することなく、Kubernetesの網羅的なオブザーバビリティとアプリケーションの洞察を実現しました。

シナリオ2：セキュリティの引き継ぎ

インフラセキュリティの基本的なルールは、見えないものは守れないということです。DevOpsの救出を実行している際、エージェントは環境のセキュリティを向上させる機会を見出します。

前回のElastic Observability関連の調査から始まったアラートを受けて、セキュリティ担当者が自社のインフラストラクチャーと直接チャットする方法を示します。1つ目はクラウド環境内の資産とリソースを列挙すること、2つ目は環境のセキュリティを確保するために必要なツールをデプロイすることです。

• 発見：コパイロットはセキュリティ担当者のためにAWSリソースを列挙し、重要なギャップを特定しました。すなわち、Amazon Elastic Compute Cloud（EC2）インスタンスと、パブリックエンドポイントにエンドポイント保護がないAmazon Elastic Kubernetes Service（EKS）クラスターです。
• 対策：簡単な承認手続きで、コパイロットは脆弱な資産に対してElastic Securityの拡張検出および対応（XDR）とクラウド検出と対応（CDR）を展開し、環境をリアルタイムで保護しました。
• 結果：デプロイされたAWS資産とリソースを完全なランタイムセキュリティで保護します。

未来：あらゆるものが拡張される

このプロジェクトは、Elastic Agent Builderが分散運用の中心的な頭脳になり得ることを証明しています。インフラだけに留まらず、私たちのランナー技術は以下の影響力を発揮します。

• 拡張合成：グローバルランナー全体にわたるTLSエラーの診断。
• 拡張開発：プルリクエストの作成と、フロントエンドサービスへのCAPTCHAの実装。
• 拡張オペレーション：障害時にDNSリゾルバを自動的に再構成。

はじめましょう

私たちは、AIの未来は単なるチャットサポートだけではなく、拡張されたインフラストラクチャーにあると信じています。これは、ユーザーと共にデプロイ、修正、観察、そして保護できるパートナーを持つことです。

コードをご覧になり、GitHubの分散ランナーやElastic Cloud ServerlessのElastic Agent Builderをぜひ直接お試しください。

• Elastic Cloudでサーバーレスプロジェクトを作成してください。
• コードをランナーにデプロイしてください。
• ランナーをセットアップしてください。
• mcp.jsonを設定してください。
• ランナーを起動すると、エージェントとそのツールが自動的に作成されます。
• 分散ランナーで推論、計画、およびアクションを実行できるエージェントとチャットしましょう。

チーム： アレックス、ビル、ギル、グラハム、ノーリー