エージェント型AI - Elasticsearch Labs

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

Alec Carpenter — Thu, 04 Jun 2026 00:00:00 GMT

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つのレイヤーがあります。

データインジェスト：Elasticsearchに送信されたGlobal Disaster Alert and Coordination System（GDACS）の災害イベント。
インジェストパイプライン：GeoJSONがインジェストされ、Elastic Common Schema（ECS）に正規化されます。
地理空間エンリッチメント：イベントの影響エリアのポリゴンがインデックス登録された軍事施設の境界と照合されます。
アラート：災害がいずれかのインストール環境と交差すると、Kibanaの検出ルールが作動します。
ワークフローの自動化：アラートによってKibanaワークフローがトリガーされ、AIエージェントの会話が開始されます。
AI推論：エージェントは、影響を受ける施設、その資産、および最寄りの支援施設をもとに推論を行い、すべての資産と人員の再配置を決定します。
メール通知：エージェントは、出入りする人員や資産について、すべての受信者にメールを送信します。

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

ステップ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配列を反復処理し、フォーマットされた避難通知または受入通知を送信します。

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

状況を評価する。アラートをパースし、影響を受ける施設を特定して、災害の範囲を判断します。
移行が必要な対象のインベントリを作成する。施設ごとの人員数、重要資産、住宅要件。
再配置先施設を見つける。影響を受ける各施設に対してmitra.nearest_facilityを呼び出し、危険区域内にある施設を除外します。
配分に関する決定を行う。単一施設ソリューションと複数施設ソリューションの比較検討、支店間の互換性、収容能力、資産サポートなどを考慮します。
調整メールを送信する。避難元施設に避難指示を、受入施設に受入通知を送信します。
サマリーレポートを作成する。影響を受けるすべての施設、総人員、移動した資産、再配置先施設、懸念事項の簡単なサマリーを作成し、確認のためにチャットに出力します。

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

最寄りの施設ツール

基盤となるワークフロークエリでは、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件の受入施設すべてに送信した。
以下のような、調整に関する詳細な概要を作成しました。

避難対象施設：

施設

人件費

ノーフォーク海軍基地

50,000

統合遠征基地リトルクリーク・フォートストーリー

18,000

オシアナ海軍航空基地

15,355

オシアナ海軍航空基地ダムネック別館

17,509

NG州立軍事基地キャンプ・ペンドルトン

9,707

ラングレー・ユースティス統合基地

15,000

ヨークタウン海軍兵器基地

11,801

受入施設：

施設

距離

避難受入人員

フォート・グレッグ・アダムズ

97 km

約40,000

クワンティコ海兵隊基地

148 km

約30,000

インディアン・ヘッド海軍支援施設

151 km

約30,000

アンドルーズ統合基地

180 km

約30,000

パタクセント・リバー海軍航空基地

141 km

約10,000

NG MTA キャンプ・バトナー

174 km

約5,000

NG Bethany Beach トレーニングサイト

209 km

約4,707

リバナステーション

140 km

約7,500

国防総合補給センター

22 km

約6,000

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

自動メール通知

エージェントが割り当て計画を確定すると、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の機能

緊急管理

避難所の場所をNWSの悪天候ポリゴンと照合する

geo_shapeエンリッチメント+Kibanaワークフロー

消防およびEMS

山火事の境界線に部隊の位置を重ね合わせる

地理空間ルーティング+最寄り施設クエリ

法執行機関

事件と学校区域および警察官の配置を関連付ける

位置情報に基づくアラートルール + 担当者の派遣

公立学校の安全

キャンパス境界に対する脅威フィードを監視する

検出ルール+自動通知

公衆衛生

危険区域を診療所の場所や物資拠点と照合する

セマンティック検索 + 地理空間エンリッチメント

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

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

MastraとElasticsearchを使用してエージェント型AIアプリケーションを構築する方法

Enrico Zimuel — Wed, 08 Apr 2026 00:00:00 GMT

この記事では、Mastra TypeScriptフレームワークを使用して、Elasticsearchと連携するエージェント型アプリケーションを構築する方法をご紹介します。

最近、mastra-ai/mastraオープンソースプロジェクトに、ベクトルデータベースとしてのElasticsearchのサポートを追加しました。この新機能により、MastraでElasticsearchをネイティブに使用して埋め込みを保存できます。ベクターに加えて、Elasticsearchはコンテキストエンジニアリングの要件を満たすための高度な機能群を提供します（例：ハイブリッド検索と再ランク付け）。

この記事では、Elasticsearchを使用したRetrieval-Augmented Generation（RAG）アーキテクチャを実装するエージェントの作成について詳しく説明します。エージェント的なアプローチを使用して、Elasticsearchに保存されているSF映画データのコーパスを操作するデモプロジェクトを紹介します。このプロジェクトはelastic/mastra-elasticsearch-exampleで入手できます。

Mastra

Mastraは、エージェント型AIアプリケーションを作成するためのTypeScriptフレームワークです。

Mastraのプロジェクト構造は以下のようになります：

src/ ├── mastra/ │ ├── agents/ │ │ └── weather-agent.ts │ ├── tools/ │ │ └── weather-tool.ts │ ├── workflows/ │ │ └── weather-workflow.ts │ ├── scorers/ │ │ └── weather-scorer.ts │ └── index.ts ├── .env.example ├── package.json └── tsconfig.json

Mastraでは、エージェント、ツール、ワークフロー、スコアを作成できます。

エージェントは、インプットとしてメッセージを受け取り、アウトプットとして回答を生成するクラスです。エージェントは、ツール、大規模言語モデル（LLM）、およびメモリを使用できます（図1）。

エージェントのツールは、「外部の世界」と対話することを可能にします。たとえば、ウェブAPIと通信したり、Elasticsearchにクエリを実行するような内部操作を行ったりします。メモリコンポーネントは、過去の入力と出力を含む会話の履歴を格納するために非常に重要です。この格納されたコンテキストにより、エージェントは過去の対話を活用して、将来の質問に対してより情報に基づいた関連性の高い回答を提供できます。

ワークフローを使用すると、単一のエージェントの推論に頼るのではなく、明確で構造化されたステップを使用して複雑なタスクのシーケンスを定義できます（図2）。タスクをどのように分割し、データをどのように移動させ、何をいつ実行するかを網羅的に制御できます。ワークフローは、デフォルトで組み込みの実行エンジンを使用して実行されますが、ワークフローランナーにデプロイすることもできます。

Mastraでは、スコアを定義することもできます。スコアは、モデル評価、ルールベース、統計的な方法を用いてエージェントの出力を評価する自動テストです。スコアラーはスコアを返します。これは、出力が評価基準をどれだけ満たしているかを定量化する数値（通常0から1の間）です。これらのスコアにより、パフォーマンスを客観的に追跡し、さまざまなアプローチを比較し、AIシステムの改善すべき分野を特定することができます。スコアラーは、独自のプロンプトやスコアリング関数でカスタマイズできます。

Elasticsearch

デモプロジェクトを実行するには、Elasticsearchインスタンスを実行する必要があります。Elastic Cloudで無料トライアルを有効化するか、start-localスクリプトを使ってローカルにインストールできます。

curl -fsSL https://elastic.co/start-local | sh

これにより、ElasticsearchとKibanaがコンピュータにインストールされ、Mastraインテグレーションの設定に使用するAPIキーが生成されます。

APIキーは前のコマンドの出力として表示され、elastic-start-localフォルダー内の.envファイルに保存されます。

デモをインストールして設定

デモプロジェクトのソースコードを含む elastic/mastra-elasticsearch-example リポジトリを作成しました。リポジトリに記載されている例は、Elasticsearchからドキュメントを取得するためのRAGアーキテクチャを実装したエージェントをMastraで作成する方法を示しています。

SF映画のデモ用データセットを提供しました。Kaggle上のIMDbデータセットから500本の映画を抽出しました。

最初のステップは、次のコマンドを使用してnpmでプロジェクトの依存関係をインストールします：

npm install

次に、設定内容を格納する.envファイルを構成する必要があります。以下のコマンドを使用して、 .env.exampleファイルの構造をコピーすることで、このファイルを生成できます。

cp .env.example .env

これで、.envを編集できるようになりました。不足している情報を追加します：

OPENAI_API_KEY= ELASTICSEARCH_URL= ELASTICSEARCH_API_KEY= ELASTICSEARCH_INDEX_NAME=scifi-movies

Elasticsearchインデックスの名称は scifi-moviesです。必要であれば、環境変数 ELASTICSEARCH_INDEX_NAMEを使って変更できます。

OpenAIを埋め込みサービスとして使用しました。これは、OPENAI_API_KEY環境変数にOpenAIのAPIキーを提供する必要があることを意味します。

例で使用されている埋め込みモデルは openai/text-embedding-3-small であり、埋め込み次元は1,536です。

最終的な答えを導き出すために、openai/gpt-5-nano モデルを使用してコストを削減しました。

RAGアーキテクチャでは、回答の妥当性を検証するという重労働は検索コンポーネント（この場合は Elasticsearch）が行うため、それほど強力ではない（そして一般的に安価な）最終的なLLMモデルを使用することができます。

小規模なLLMは主に2つのタスクを担当します：

クエリの言い換え/埋め込み：ユーザーの自然言語の質問をセマンティック検索用のベクトル埋め込みに変換します。
回答の合成：取得された関連性の高いコンテキストの断片（文書/動画）を取り出し、提示された指示に従って、首尾一貫した最終的な人間が読める回答に合成します。

RAGプロセスは回答に必要とされる正確な事実的文脈を提供するため、最終的なLLMは大規模または高度に複雑である必要はなく、必要な知識をすべて自らのパラメータ内に持つ必要もありません（それは大規模で高価なモデルが優れている領域です）。本質的には、本格的なナレッジベースとしてではなく、Elasticsearchが提供するコンテキストの洗練されたテキストサマライザーおよびフォーマッターとして機能します。これにより、コストやレイテンシーの最適化にgpt-5-nanoのようなモデルを活用できます。

.envファイルの設定後、次のコマンドで映画をElasticsearchに取り込むことができます。

npx tsx src/utility/store.ts

次のような出力が表示されるはずです。

scifi-moviesインデックスのマッピングには、次のフィールドが含まれています。

埋め込み、1536次元のdense_vector、コサイン類似度。
説明、映画の説明を含むテキスト。
監督、監督の名前を含むテキスト。
タイトル、映画のタイトルを含むテキスト。

タイトルとディスクリプションを使用して埋め込みを生成しました。タイトルとディスクリプションは2つの別個のフィールドであるため、両者を連結することで、結果として得られる埋め込みベクトルが、映画の具体的で独自の特徴（タイトル）と豊かな説明的コンテキスト（内容説明）の両方を捉えることができます。これにより、より正確で包括的なセマンティック検索結果が得られます。この結合されたインプットにより、埋め込みモデルは類似度マッチングに向けて、ドキュメントのコンテンツをより適切に単一のベクトル表現として捉えることができます。

デモを実行

次のコマンドでデモを実行できます：

npm run dev

このコマンドを実行するとlocalhost:4111でWebアプリケーションが起動し、Mastra Studioにアクセスできるようになります（図3）。

Mastra Studio はエージェントの構築とテストのためのインタラクティブなUIを提供し、さらにMastraアプリケーションをローカルサービスとして公開するREST APIも備えています。これにより、統合を気にせずにすぐに構築を始められます。

Elasticsearchを使ったセマンティック検索を実行するツールとして、MastraのcreateVectorQueryToolを使ったElasticsearch Agentを提供しました。このエージェントは、RAGアプローチを使用して関連文書（つまり映画）を検索し、ユーザーの質問に答えます。

このエージェントは以下のプロンプトを使用します：

You are a helpful assistant that answers questions based on the provided context. Follow these steps for each response: 1. First, carefully analyze the retrieved context chunks and identify key information. 2. Break down your thinking process about how the retrieved information relates to the query. 3. Draw conclusions based only on the evidence in the retrieved context. 4. If the retrieved chunks don't contain enough information, explicitly state what's missing. Format your response as: THOUGHT PROCESS: - Step 1: [Initial analysis of retrieved chunks] - Step 2: [Reasoning based on chunks] FINAL ANSWER: [Your concise answer based on the retrieved context] Important: When asked to answer a question, please base your answer only on the context provided in the tool. If the context doesn't contain enough information to fully answer the question, please state that explicitly and stop it. Do not add more information than what is present in the retrieved chunks. Remember: Explain how you're using the retrieved information to reach your conclusions.

Mastra Studio > AgentsメニューをクリックしてElasticsearch Agentを選択すると、チャットシステムを使用してエージェントをテストできます。たとえば、SF映画に関する情報を次のような質問で尋ねることができます。

UFOを題材にした映画またはテレビシリーズを5つ見つけてください。

エージェントがvectorQueryToolを実行することがわかります。起動したツールをクリックすると、入力と出力を確認できます。実行の最後に、LLMはElasticsearchのscifi-moviesインデックスから得られたコンテキストに基づいて、あなたの質問に回答します（図4）。

Mastraは内部で以下の手順を実行します：

ベクトル変換：ユーザーの質問「UFOに関する映画やテレビシリーズを5つ探して」は、OpenAIのopenai/text-embedding-3-smallモデルを使ってベクトル埋め込みに変換されます。
ベクトル検索：この埋め込みはその後、Elasticsearchに対してベクトル検索を用いてクエリを実行するために使用されます。
結果の取得：Elasticsearchは、クエリに非常に関連性の高い10本の映画（つまり、ユーザーのクエリベクトルに最も近いベクトルを持つ映画）を返します。
回答生成：取得された映画と元のユーザーの質問は、具体的にはopenai/gpt-5-nano LLM に送信されます。LLMはこの情報を処理し、最終的な回答を生成することで、ユーザーの5つの結果への要望を確実に満たします。

Elasticsearch エージェント

ここではElasticsearch Agentのソースコードを報告しました。

import { Agent } from "@mastra/core/agent"; import { ElasticSearchVector } from '@mastra/elasticsearch'; import { createVectorQueryTool } from '@mastra/rag'; import { ModelRouterEmbeddingModel } from "@mastra/core/llm"; import { Memory } from "@mastra/memory"; const es_url = process.env.ELASTICSEARCH_URL; const es_apikey = process.env.ELASTICSEARCH_API_KEY; const es_index_name = process.env.ELASTICSEARCH_INDEX_NAME; const prompt = 'insert here the previous prompt'; const esVector = new ElasticSearchVector({ id: 'elasticsearch-vector', url: es_url, auth: { apiKey : es_apikey } }); const vectorQueryTool = createVectorQueryTool({ vectorStore: esVector, indexName: es_index_name, model: new ModelRouterEmbeddingModel("openai/text-embedding-3-small") }); export const elasticsearchAgent = new Agent({ id: "elasticsearch-agent", name: "Elasticsearch Agent", instructions: prompt, model: 'openai/gpt-5-nano', tools: { vectorQueryTool }, memory: new Memory(), });

vectorQueryToolは、RAGの例における取得部分を実装するために呼び出されるツールです。MastraにElasticが提供したElasticSearchVector実装を使用しています。

エージェントは、vectorQueryTool、プロンプト、およびメモリを消費するエージェントクラスのオブジェクトです。ご覧のように、Elasticsearchをエージェントに接続するために必要なコードはごくわずかです。

まとめ

この記事では、ElasticsearchとMastraフレームワークを統合し、洗練されたエージェント型AIアプリケーションを構築することのシンプルさとパワーについて実証しました。具体的には、Elasticsearchでインデックス化されたSF映画データのコーパスに対してセマンティック検索を実行できるRAGエージェントの作成について説明しました。

重要なポイントは、ElasticがMastraのオープンソースプロジェクトに直接貢献し、ベクターストアとしてのElasticsearchをネイティブサポートしていることです。この統合により、導入時の障壁が大幅に低下します。これは、 Elasticsearch Agentのソースコードを見れば明らかです。ElasticSearchVectorとcreateVectorQueryToolを使用することで、Elasticsearchをエージェントに接続するための総合的なセットアップが、最小限の設定コード行数で済みます。

Elasticsearchは、結果の関連性を高めるためのいくつかの高度な機能を提供しています。例として、ハイブリッド検索は、語彙検索とベクトル検索を組み合わせることで、精度を大幅に向上させます。もう一つの興味深い機能は、ハイブリッド検索の最後に適用できる最新のJinaモデルを使用した再ランク付けです。これらの技術についてさらに詳しく知るには、Elasticsearch Labsの以下の記事を参照してください。

Elasticsearchのハイブリッド探索 by ヴァレンティン・クレっタス
Jinaモデル入門、その機能、Elasticsearchでの利用 by スコット・マーテンス

また、提供されている例を参考に、MastraとElasticsearchを使って独自のデータ駆動型エージェントを構築し始めることをお勧めします。Mastraについての詳細は、こちらのオフィシャルドキュメントをご覧ください。

TypeScriptを使用したElasticsearch MCPサーバーの作成

Jeffrey Rengifo — Fri, 27 Mar 2026 00:00:00 GMT

Elasticsearchで大規模なナレッジベースを扱う場合、情報を見つけるだけでは片手落ちです。エンジニアは複数の文書から結果を統合し、要約を作成し、回答を情報源にたどる必要があることが多いです。モデルコンテキストプロトコル（MCP）は、Elasticsearchと大規模言語モデル（LLM）アプリケーションを接続するための標準化された方法を提供します。ElasticはElastic Agent Builder（MCPエンドポイントを機能の一つに含む）のような公式ソリューションを提供していますが、カスタムMCPサーバーを構築することで、検索ロジック、結果のフォーマット、取得したコンテンツをLLMに渡して合成、要約、引用を行う方法などを完全に制御できます。

この記事では、カスタムElasticsearch MCPサーバーを構築するメリットを探り、ElasticsearchをLLM対応アプリケーションに接続するサーバーをTypeScriptで作成する方法を紹介します。

カスタムのElasticsearch MCPサーバーを構築する理由

ElasticはMCPサーバーのいくつかの代替手段を提供しています。

MCPサーバーとElasticsearchの連携方法をより細かく制御したい場合は、独自のカスタムサーバーを構築することで、ニーズに合わせて柔軟にカスタマイズできます。例えば、Agent BuilderのMCPエンドポイントはElasticsearchクエリ言語（ES|QL）クエリに限定されていますが、カスタムサーバーでは完全なクエリDSLを使用できます。また、LLMに渡される前に結果をどのようにフォーマットするかを制御でき、このチュートリアルで実装するOpenAIを利用した要約など、追加の処理ステップを統合することもできます。

この記事を読み終える頃には、Elasticsearchインデックスに保存されている情報を検索し、要約し、引用を提供するTypeScriptで記述されたMCPサーバーが完成しているでしょう。Elasticsearchを使用して情報を検索し、OpenAIのgpt-4o-miniモデルを用いて要約と引用を生成し、Claude DesktopをMCPクライアントおよびUIとして活用してユーザーのクエリを受け取り、応答を提供します。最終的には、エンジニアが組織内の技術文書全体からベストプラクティスを発見し、統合するのに役立つ内部ナレッジアシスタントが完成します。

要件：

Node.js 20 +
Elasticsearch
OpenAI APIキー
Claude Desktop

MCPとは何ですか？

MCPはAnthropicによって作成されたオープンスタンダードで、LLMとElasticsearchのような外部システムとの間で安全かつ双方向の接続を提供します。MCP の現状についてはこの記事で詳しく読むことができます。

MCPの環境は日々進化しており、多様なユースケースに対応したサーバーが利用可能です。さらに、この記事でご紹介するように、独自のカスタムMCPサーバーを簡単に構築することもできます。

MCPクライアント

利用可能なMCPクライアントは多数あり、それぞれに特徴や制限があります。簡便性と普及度を考慮し、今回はMCPクライアントとしてClaude Desktopを使用します。これは、ユーザーが自然言語で質問できるチャットインターフェースとして機能し、MCPサーバーが公開しているツールを自動的に呼び出して、文書を検索し、要約を生成します。

Elasticsearch MCPサーバーの作成

TypeScript SDKを使えば、ユーザーのクエリ入力に基づいてElasticsearchデータのクエリ方法を理解するサーバーを簡単に作成できます。

この記事では、Elasticsearch MCPサーバーとClaude Desktopクライアントを統合するための手順を説明します。

Elasticsearch MCPサーバーを設定してください

まず、Nodeアプリケーションを初期化します。

npm init -y

これで package.jsonファイルが作成され、このアプリケーションに必要な依存関係のインストールを開始できます。

npm install @elastic/elasticsearch @modelcontextprotocol/sdk openai zod && npm install --save-dev ts-node @types/node typescript

@elastic/elasticsearch はElasticsearchのNode.jsライブラリにアクセスするためのものです。
@modelcontextprotocol/sdkは、MCPサーバーの作成と管理、ツールの登録、MCPクライアントとの通信処理を行うためのコアツールを提供します。
openaiは、OpenAIのモデルと対話し、要約や自然言語による対応を生成することができます。
zodは、各ツールの入出力データの構造化スキーマの定義と検証に役立ちます。

ts-node、@types/node、 typescriptは開発中にコードの入力やスクリプトのコンパイルに使用されます。

データセットを設定

Claude DesktopがMCPサーバーを使用してクエリできるデータを提供するために、内部の模擬ナレッジベースデータセットを使用します。このデータセットから作成される文書は以下のような形式になります。

{ "id": 5, "title": "Logging Standards for Microservices", "content": "Consistent logging across microservices helps with debugging and tracing. Use structured JSON logs and include request IDs and timestamps. Avoid logging sensitive information. Centralize logs in Elasticsearch or a similar system. Configure log rotation to prevent storage issues and ensure logs are searchable for at least 30 days.", "tags": ["logging", "microservices", "standards"] }

データを取り込むために、Elasticsearchにインデックスを作成し、そこにデータセットをロードするスクリプトを用意しました。こちらでご覧いただけます。

MCPサーバー

index.tsというファイルを作成し、依存関係をインポートして環境変数を処理するための以下のコードを追加します。

// index.ts import { z } from "zod"; import { Client } from "@elastic/elasticsearch"; import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import OpenAI from "openai"; const ELASTICSEARCH_ENDPOINT = process.env.ELASTICSEARCH_ENDPOINT ?? "http://localhost:9200"; const ELASTICSEARCH_API_KEY = process.env.ELASTICSEARCH_API_KEY ?? ""; const OPENAI_API_KEY = process.env.OPENAI_API_KEY ?? ""; const INDEX = "documents";

また、ElasticsearchとOpenAIの呼び出しを処理するようにクライアントを初期化します。

const openai = new OpenAI({ apiKey: OPENAI_API_KEY, }); const _client = new Client({ node: ELASTICSEARCH_ENDPOINT, auth: { apiKey: ELASTICSEARCH_API_KEY, }, });

実装をより堅牢にし、構造化された入出力を保証するために、 zodを使用してスキーマを定義します。これにより、ランタイムでデータを検証し、エラーを早期に捕捉し、ツールの対応をプログラムで処理しやすくすることができます。

const DocumentSchema = z.object({ id: z.number(), title: z.string(), content: z.string(), tags: z.array(z.string()), }); const SearchResultSchema = z.object({ id: z.number(), title: z.string(), content: z.string(), tags: z.array(z.string()), score: z.number(), }); type Document = z.infer; type SearchResult = z.infer;

構造化出力の詳細については、こちらをご覧ください。

それでは、MCPサーバーを初期化しましょう。

const server = new McpServer({ name: "Elasticsearch RAG MCP", description: "A RAG server using Elasticsearch. Provides tools for document search, result summarization, and source citation.", version: "1.0.0", });

MCPツールの定義

すべての設定が完了したので、MCPサーバーによって公開されるツールの作成を開始できます。このサーバーは2つのツールを公開します。

search_docs：Elasticsearchで文書を全文検索で検索します。
summarize_and_cite：以前に取得した文書から情報を要約・統合し、ユーザーの質問に答えます。このツールは、出典となる文書を参照する引用も追加します。

これらのツールを組み合わせることで、シンプルな「検索してから要約」ワークフローが構築されます。一方のツールが関連文書を取得し、もう一方のツールがその文書を使用して要約と引用を含む回答を生成します。

ツールの応答形式

各ツールは任意の入力パラメータを受け入れることができますが、以下の構造で応答する必要があります。

Content： これは非構造化形式でのツールの応答です。このフィールドは通常、テキスト、画像、音声、リンク、または埋め込みを返すために使用されます。この用途では、ツールによって生成された情報を含む整形済みテキストを返すために使用されます。
structuredContent：これは、各ツールの結果を構造化された形式で提供するために使用されるオプションの戻り値です。これはプログラム上の目的に役立ちます。このMCPサーバーでは使用されていませんが、他のツールを開発したり、結果をプログラムで処理したりする場合に便利です。

その構造を念頭に置いて、各ツールについて詳しく見ていきましょう。

Search_docsツール

このツールは、Elasticsearchインデックスで全文検索を実行し、ユーザークエリに基づいて最も関連性の高いドキュメントを取得します。主要な一致をハイライトし、関連性スコアを素早くまとめてくれます。

server.registerTool( "search_docs", { title: "Search Documents", description: "Search for documents in Elasticsearch using full-text search. Returns the most relevant documents with their content, title, tags, and relevance score.", inputSchema: { query: z .string() .describe("The search query terms to find relevant documents"), max_results: z .number() .optional() .default(5) .describe("Maximum number of results to return"), }, outputSchema: { results: z.array(SearchResultSchema), total: z.number(), }, }, async ({ query, max_results }) => { if (!query) { return { content: [ { type: "text", text: "Query parameter is required", }, ], isError: true, }; } try { const response = await _client.search({ index: INDEX, size: max_results, query: { bool: { must: [ { multi_match: { query: query, fields: ["title^2", "content", "tags"], fuzziness: "AUTO", }, }, ], should: [ { match_phrase: { title: { query: query, boost: 2, }, }, }, ], }, }, highlight: { fields: { title: {}, content: {}, }, }, }); const results: SearchResult[] = response.hits.hits.map((hit: any) => { const source = hit._source as Document; return { id: source.id, title: source.title, content: source.content, tags: source.tags, score: hit._score ?? 0, }; }); const contentText = results .map( (r, i) => `[${i + 1}] ${r.title} (score: ${r.score.toFixed( 2, )})\n${r.content.substring(0, 200)}...`, ) .join("\n\n"); const totalHits = typeof response.hits.total === "number" ? response.hits.total : (response.hits.total?.value ?? 0); return { content: [ { type: "text", text: `Found ${results.length} relevant documents:\n\n${contentText}`, }, ], structuredContent: { results: results, total: totalHits, }, }; } catch (error: any) { console.log("Error during search:", error); return { content: [ { type: "text", text: `Error searching documents: ${error.message}`, }, ], isError: true, }; } } );

fuzziness: “AUTO” は 分析対象のトークンの長さに応じて誤字許容度を調整するように設定しています。また 、 タイトルフィールドで一致が発生したドキュメントのスコアを上げるtitle^2も設定しました。。

summarize_and_citeツール

このツールは、前回の検索で取得したドキュメントに基づいて要約を生成します。OpenAIの gpt-4o-miniモデルを使用して、ユーザーの質問に答えるために最も関連性の高い情報を統合し、検索結果に直接基づく回答を提供します。要約に加えて、使用したソースドキュメントの引用情報（メタデータ）も返します。

server.registerTool( "summarize_and_cite", { title: "Summarize and Cite", description: "Summarize the provided search results to answer a question and return citation metadata for the sources used.", inputSchema: { results: z .array(SearchResultSchema) .describe("Array of search results from search_docs"), question: z.string().describe("The question to answer"), max_length: z .number() .optional() .default(500) .describe("Maximum length of the summary in characters"), max_docs: z .number() .optional() .default(5) .describe("Maximum number of documents to include in the context"), }, outputSchema: { summary: z.string(), sources_used: z.number(), citations: z.array( z.object({ id: z.number(), title: z.string(), tags: z.array(z.string()), relevance_score: z.number(), }) ), }, }, async ({ results, question, max_length, max_docs }) => { if (!results || results.length === 0 || !question) { return { content: [ { type: "text", text: "Both results and question parameters are required, and results must not be empty", }, ], isError: true, }; } try { const used = results.slice(0, max_docs); const context = used .map( (r: SearchResult, i: number) => `[Document ${i + 1}: ${r.title}]\\n${r.content}` ) .join("\n\n---\n\n"); // Generate summary with OpenAI const completion = await openai.chat.completions.create({ model: "gpt-4o-mini", messages: [ { role: "system", content: "You are a helpful assistant that answers questions based on provided documents. Synthesize information from the documents to answer the user's question accurately and concisely. If the documents don't contain relevant information, say so.", }, { role: "user", content: `Question: ${question}\\n\\nRelevant Documents:\\n${context}`, }, ], max_tokens: Math.min(Math.ceil(max_length / 4), 1000), temperature: 0.3, }); const summaryText = completion.choices[0]?.message?.content ?? "No summary generated."; const citations = used.map((r: SearchResult) => ({ id: r.id, title: r.title, tags: r.tags, relevance_score: r.score, })); const citationText = citations .map( (c: any, i: number) => `[${i + 1}] ID: ${c.id}, Title: "${c.title}", Tags: ${c.tags.join( ", ", )}, Score: ${c.relevance_score.toFixed(2)}`, ) .join("\n"); const combinedText = `Summary:\\n\\n${summaryText}\\n\\nSources used (${citations.length}):\\n\\n${citationText}`; return { content: [ { type: "text", text: combinedText, }, ], structuredContent: { summary: summaryText, sources_used: citations.length, citations: citations, }, }; } catch (error: any) { return { content: [ { type: "text", text: `Error generating summary and citations: ${error.message}`, }, ], isError: true, }; } } );

最後に、stdioを使用してサーバーを起動する必要があります。つまり、MCPクライアントは、標準の入出力ストリームを読み書きすることでサーバーと通信します。stdioは最もシンプルな転送オプションで、クライアントによってサブプロセスとして立ち上げられるローカルMCPサーバーに適しています。ファイルの最後に以下のコードを追加します。

const transport = new StdioServerTransport(); server.connect(transport);

次に、以下のコマンドを使用してプロジェクトをコンパイルします。

npx tsc index.ts --target ES2022 --module node16 --moduleResolution node16 --outDir ./dist --strict --esModuleInterop

これによりdistフォルダが作成され、その中にindex.jsファイルが作成されます。

MCPサーバーをClaude Desktopにロード

Claude DesktopでMCPサーバーを設定するには、このガイドに従ってください。Claudeの設定ファイルでは、以下の値を設定する必要があります:

{ "mcpServers": { "elasticsearch-rag-mcp": { "command": "node", "args": [ "/Users/user-name/app-dir/dist/index.js" ], "env": { "ELASTICSEARCH_ENDPOINT": "your-endpoint-here", "ELASTICSEARCH_API_KEY": "your-api-key-here", "OPENAI_API_KEY": "your-openai-key-here" } } } }

args値は、 distフォルダ内のコンパイル済みファイルを指す必要があります。また、設定ファイル内の環境変数も、コード内で定義されているものと全く同じ名前で設定する必要があります。

試してみる

各ツールを実行する前に、「検索とツール」をクリックして、ツールが有効になっていることを確認します。ここでは、それぞれを有効または無効にすることもできます。

最後に、Claude DesktopのチャットからMCPサーバーをテストして、質問を始めましょう。

「認証方法とRBACに関する文書を検索する」という質問に対して、search_docs ツールが実行され、以下の結果が返されます。

Most Relevant Documents: Access Control and Role Management (highest relevance) - This document covers role-based access control (RBAC) principles, including ensuring users only have necessary permissions, regular auditing of user roles, revoking inactive accounts, and implementing just-in-time access for sensitive operations. User Authentication with OAuth 2.0 - This document explains OAuth 2.0 authentication, which enables secure delegated access without credential sharing. It covers configuring identity providers, token management with limited scope and lifetime, and secure storage of refresh tokens. Container Security Guidelines - While primarily about container security, this document touches on access control aspects like running containers as non-root users and avoiding embedded credentials. Incident Response Playbook - This mentions role assignment during incidents (incident commander, communications lead, etc.), which relates to access control in emergency scenarios. Logging Standards for Microservices - This document includes guidance on avoiding logging sensitive information, which is relevant to authentication security.

回答は「素晴らしい！認証方法とロールベースのアクセス制御に関する関連文書を5件見つけました。見つかった内容は以下のとおりです。」

ツール呼び出しは、対応ペイロードの一部としてソース文書を返します。これらの文書は、後に引用を生成するために使用されます。

また、複数のツールを一度のインタラクションで連結することも可能です。この場合、Claude Desktopはユーザーの質問を分析し、まずsearch_docsを呼び出して関連文書を取得し、次にその結果をsummarize_and_citeに渡して最終的な回答を生成する必要があると判断します。これらすべては、ユーザーからの個別のプロンプトを必要とせずに実行されます。

この場合、「システム全体の認証とアクセス制御を改善するための主な推奨事項は何ですか？参考文献を含めてください。」というクエリに対して、以下の結果が得られました。

Based on the documentation, here are the main recommendations to improve authentication and access control across your systems: Key Recommendations 1. Implement Role-Based Access Control (RBAC) Ensure users have only the permissions necessary for their job functions. This principle of least privilege minimizes security risks by limiting access to what's truly needed. [1] 2. Regular Access Audits Conduct regular audits of user roles and promptly revoke access for inactive accounts. This helps prevent unauthorized access from dormant or compromised accounts. [1] 3. Just-in-Time (JIT) Access Implement just-in-time access for sensitive operations, where permissions are granted only when needed and for a limited duration. This reduces the attack surface by minimizing standing privileges. [1] 4. OAuth 2.0 for Secure Authentication Use OAuth 2.0 to enable secure delegated access without sharing user credentials. This protocol allows third-party applications to access resources on behalf of users without exposing passwords. [2] 5. Token Security and Management Configure your identity provider to issue tokens with limited scope and lifetime Store refresh tokens securely Validate access tokens consistently to maintain security [2] References Access Control and Role Management (Tags: security, access-control) User Authentication with OAuth 2.0 (Tags: authentication, oauth) These recommendations work together to create a defense-in-depth approach, where multiple security layers protect your systems from unauthorized access.

前のステップと同様に、この質問に対する各ツールの回答を確認できます。

注：各ツールの使用を承認するかを確認するサブメニューが表示された場合は、「常に許可」または「一度だけ許可」を選択します。

まとめ

MCPサーバーは、ローカルとリモートの両方のアプリケーションのLLMツールの標準化に向けた重要な一歩です。完全な互換性の実現にはまだ取り組んでいますが、その方向へ急速に進んでいます。

この記事では、ElasticsearchをLLM搭載アプリケーションに接続するカスタムMCPサーバーをTypeScriptで構築する方法を学びました。当サーバーは2つのツールを提供しています。1つはQuery DSLを使用して関連文書を取得するためのツールsearch_docs、もう1つはOpenAIモデルとクライアントUIとしてのClaude Desktopを使用して引用付きの要約を生成するためのツールsummarize_and_citeです。

異なるクライアントとサーバープロバイダー間の互換性の将来は有望に見えます。次のステップは、エージェントにより多くの機能と柔軟性を加えることです。実用的な記事で、検索テンプレートを使用してクエリをパラメーター化し、精度と柔軟性を得る方法を学ぶことができます。

シェルツールはコンテキストエンジニアリングの万能薬ではありません

Leonie Monigatti — Wed, 25 Mar 2026 00:00:00 GMT

エージェントが備える最も重要なツールは、自前でコンテキストを構築するために使用できる検索ツールです。LlamaIndexとLangChainによる最近の投稿により、エージェントがコンテキストエンジニアリングに必要なのは、シェルツールとファイルシステムだけなのかという議論が巻き起こりました。残念ながら、この議論はすぐにファイルシステム対データベースという間違った方向に逸れてしまいました。

この投稿は、エージェントが独自のコンテキストを構築するために必要な、適切な検索インターフェースとは何かという問いに改めて焦点を当てるものです。まず、シェルツールと専用データベースツールのトレードオフについて論じます。それを基に、エージェントのニーズに合った適切なインターフェースを見つけるための実用的なフレームワークを提示します。

エージェントにとって「コンテキスト構築」が具体的に意味するもの

初期のRetrieval-Augmented Generation（RAG）パイプラインでは、開発者が肯定的な検索パイプラインを設計し、大規模言語モデル（LLM）はコンテキストを受動的に受け取るだけの存在でした。そしてこれが、根本的な制限となっていました。コンテキストは、必要かどうかにかかわらず、すべてのクエリで取得され、それが実際に役立つかどうかも確認されなかったのです。

エージェント型RAGへの移行により、エージェントは独自のコンテキストを構築するための一連の検索ツールを利用できるようになりました。たとえば、Claude Code [1]とCursor [2]は、タスクの必要に応じて、エージェントが異なる検索ツールを選択し、さらにはそれらを組み合わせてクエリーを連鎖的に実行することもできます。

コンテキストエンジニアリングに用いる検索インターフェースの種類

コンテキストは、ウェブ上、ローカルファイルシステム、データベースなど、さまざまな場所に存在します。エージェントは、これらのコンテキスト外の各データソースと、次のようなツールを通じてやり取りできます。

シェルツールはシェルコマンドを実行でき、ローカルファイルシステムにアクセスできます。組み込みシェルツールの例としては、Claude APIのbashツール、OpenClawのExecツール、LangChainのシェルツールがあります。
専用のデータベースツール、たとえばモデルコンテキストプロトコル（MCP）サーバー（例：Elastic Agent Builder MCPサーバー）やカスタムツール（例：run_esql(query)、db_list_index()）などは、データベースをクエリできます。
専用のファイル検索ツールは、ローカル（またはアップロードされた）ファイルを検索し、読み取ることができます（ただし、シェルに完全にアクセスする権限はありません）。組み込みファイル検索ツールの例としては、 Gemini APIのファイル検索ツールや OpenAIのファイル検索ツールがあります。
ウェブ検索ツールは、ウェブから情報を取得できます。
メモリツールは、長期記憶に保存し、長期記憶から呼び出します（保存方法は任意です）。

ご覧のとおり、シェルツールは用途が多彩で、以下のようなさまざまなデータソースからコンテキストを取得するために使用できます。

ファイルシステム：エージェントはディレクトリ構造を探索（ls、find）、関連コンテンツを検索（grep、cat）し、十分なコンテキストが構築されるまで繰り返します。
データベース：エージェントは、データベース用のコマンドラインインターフェース（CLI）ツール（例：elasticsearch-sql-cli）を使用したり、curl経由でのHTTP APIを呼び出たり、スクリプトを実行したりできます。これは、再利用可能な文書化した例をエージェントのコンテキストに挿入して、ツールを適切に使用できるようにするようなエージェントスキル（例：Elastic Agent Skills for Elasticsearch）と組み合わせると特に役立ちます。
ウェブ：エージェントは、検索プロバイダーのAPIを通じてcurlコマンドでウェブ検索を実行できます。

ただし、シェルツールはシステムに直接アクセスできるため、隔離されたサンドボックス環境での実行や、実行されたすべてのコマンドのログを取得するなどの安全対策が必要です。

いつ、どの検索インターフェースを使用すべきか

最適な検索インターフェースは、データ、クエリパターン、ユースケースによって異なります。このセクションは、実際に取りかかる際の出発点として役立ちます。

ファイルシステムによってデータベースが時代遅れになったわけではない

ファイルシステムかデータベースかという議論は、ストレージ層自体の話ではありません。たとえば、LangChainの説明によると、LangChainのメモリシステムでは、実のところファイルシステムにメモリを保存しているわけではありません。代わりに、メモリをデータベースに格納し、それをエージェントに対して一連のファイルとして提示します[3]。

ファイルシステムは、コーディングエージェントなど、ファイルを中心としたユースケースに最適です。また、一時的なスクラッチパッドや作業メモリとしても、同時実行が問題とならない単一ユーザーや単一エージェントのシナリオにも適しています。こうした場合、物理的なファイルシステム、またはデータをファイルシステムとして提示する方法により、目的に合わせてインターフェースを構築する前の段階において柔軟性を確保できます。

しかし、ファイルシステムストレージには、同時実行性、手動によるスキーマ適用、アトミックトランザクションなどの弱点があります。これらは、アプリケーションをスケールしたり、マルチエージェントシナリオに移行したりする必要がある場合に、いっそう顕著になります。これらの弱点を無視するならば、本番用データベースがすでに備えているような、トランザクションの安全性やアクセス制御を支える何十年もの技術的蓄積のない、劣化版のデータベースを苦労して再発明する羽目に陥ります。さらに、ほとんどのエンタープライズ環境では、データベースを使用するかどうかを選ぶ余地はありません。なぜなら、ビジネスクリティカルなデータを格納するデータベースはすでに存在しているからです。

シェルツール+ファイルシステム

ファイルシステム検索の出発点として、シェルツールは最適な選択肢です。現在、この分野において多くの発展を牽引しているのは、コーディングエージェントです。コーディングエージェントはローカルファイル内のコードを扱うため、必然的にファイル依存度の高いユースケースとなります。したがって、LLMはコーディングタスク用に、トレーニング後の段階で微調整されます。そのため、多くのLLMはコードを書くことだけでなく、シェルコマンドの使用やファイルシステム内の移動も得意です。

lsやgrepのような、組み込みCLIを備えたシェルツールでファイルを検索することは効果的です。grepでは「matplotlibをインポートしているすべてのファイルを検索」といったクエリを、高速かつ高精度に、しかも低コストで実行できます。しかし、エージェントが「アプリは失敗した認証をどのように処理しているか」といった概念的なクエリを処理する必要がある場合、grepによるパターンマッチングはすぐに限界に突き当たります。このギャップを埋めるために、jina-grepのような、コマンドラインにセマンティック検索機能をもたらす代替手段もいくつか登場しています。

ただしgrepと、その代替手段であるセマンティック検索の多くは、コーパス全体に対してO(n)で実行されます。コードベースを対象とするユースケースなら、これで問題ないかもしれません。しかし、データが増えるとレイテンシーが目立つようになります。この場合、パフォーマンスを維持するにはインデックス化されたデータストアが必要となります。

シェルツール+データベース

セマンティック検索やハイブリッド検索など、データに対する検索機能を追加する別の方法は、たとえばCursorのように、機能をデータベースに格納することです。さらに、データに複雑なリレーショナル結合や集計が必要な場合、データベースインターフェースは不可欠です。

データがファイルシステム上ではなくデータベース内にある場合、特定のユースケースでは、シェルツールを軽量なデータベースインターフェースとして利用できます。クエリがCLIやcurlコマンドで十分に実行できるほどシンプルな場合、専用のデータベースツールを使うとかえって不要な複雑さが増えることがあります。

このアプローチは、エージェントが実際にどのようなクエリパターンを生成するかまだわからない、初期の探索段階にも適しています。この場合、Agent Skillsは、目的に合わせて構築されたツールに頼ることなく、正しくクエリを実行するための十分な構造を提供できます。ただし、反復的なタスクについてデータベースへの適切なクエリを見つけ出すためにエージェントが何度も試行錯誤しなければならない場合、インターフェースとしてシェルツールを使うことによって生じる、トークンオーバーヘッドによるデメリットが、追加のツールを避けられるという単純性のメリットを上回ってしまいます。

専用のデータベースツール

特に、繰り返し現れるクエリパターンが構造化されていたり分析的なものであったりする場合は、専用のデータベースツールが必要になります。VercelとBraintrustのブログ記事では、カスタマーサポートチケットや営業電話の書き起こしなどの半構造化データに関する実際の検索タスクで、さまざまな検索ツールセットを持つエージェントを比較しました（「『セキュリティ』に言及している未解決の問題はいくつありますか？」や「バグが報告され、後に誰かがそれを修正したと主張するPRが提出された問題を検索してください」など）[4]。

その結果、専用のデータベースツールを使用するエージェントは、シェルツールとファイルシステムのみを使用するエージェントに比べて、トークンの使用数が少なく、処理速度が速く、ミスも少ないことが判明しました。ここから得られる教訓は、クエリが半構造化データに対する分析推論を必要とする場合、データベースを直接扱うツールが正しい選択肢であるということです。

検索インターフェースを組み合わせる

すべてのクエリを適切に処理できる単一の検索インターフェースはありません。たとえば、Cursorはシェルツール（grepによる検索用）とセマンティック検索ツールを組み合わせて、エージェントがユーザーのプロンプトに基づいて適切なツールを選択できるようにしています。Cursorによると、エージェントは特定のシンボルや文字列を照合するためにgrepを選択し、概念的または行動に関する質問にはセマンティック検索を選択し、探索的なタスクには両方を使用するとのことです。

Vercelの実験レポートでも同じ結果が報告されています。シェルツールと専用データベースツールの両方にアクセスできるハイブリッドエージェントが、まず専用のデータベースツールを使用し、次にファイルシステムをgrepで検索して結果を確認するという方法を用いることにより、テストした全エージェントの中で最高のパフォーマンスを達成しました。しかし、このアプローチでは、ツールの選択と検証について検討するためにより多くのトークンと時間がかかります。

どちらの例でもパターンは同じです。インターフェースを組み合わせればどんな単一のインターフェースにも勝りますが、コストと遅延の増加というトレードオフも伴うということです。

適切なツールセットを見つけるための実践的な推奨事項

適切な検索インターフェースの組み合わせとは、小さく、目的が明確で、エージェントの実際のクエリパターンに即したものです。現在のベストプラクティスは、エージェントが何百ものMCPツールを備えるのではなく、備えるツールの数を最低限に抑えるということです。これは、利用可能なすべてのツールを事前に開示すると、コンテキストウィンドウが肥大化し、エージェントが実際にどのツールを使用すべきか混乱してしまうからです。たとえば、Claude Codeが備えているツールは約20個にとどまると報告されています。

その代わりに、段階的開示の考え方では、最小限のツールセットから始め、必要になったときにのみエージェントが追加機能を探すようにします。Anthropic [5]とCursor [6]の研究によると、このアプローチで47%–85%のトークンを節約できます。たとえば、Claude Codeはこの方法を直接実装しているため、エージェントはLLMを呼び出すたびにコンテキストを消費することなく、APIやデータベースにクエリする方法を段階的に発見できます。

エージェントのクエリパターンを把握できたら、エージェントがデフォルトでアクセス可能な検索ツールセットを見直すと良いでしょう。採用すべきツールを決定するにあたり、のトレードオフを考えるのに便利なのが、「敷居を低く、限界を高く」という原則です。限界の高いツールはエージェントの可能性を制限しません。たとえば、汎用的なシェルツールを使用すると、エージェントは曖昧なものを含めて完全なデータベースクエリを作成できますが、推論オーバーヘッド、遅延の増加、そして信頼性の低下を伴います。

敷居の低いツールはその逆です。これは、特定のクエリをラップし、最小限の推論オーバーヘッドでエージェントに即座にアクセスできる専用のツールであり、低コストと高い信頼性を実現します。ただし、事前のエンジニアリングが必要で、あらゆるクエリをカバーできるわけではなく、エージェントが適切なツールを選びにくくなる可能性もあります。

それぞれのツールは一長一短です。敷居の低いツールは、エージェントが正しく使用するのは簡単ですが、適用範囲は限定的です。限界の高いツールは多用途ですが、使いこなすにはより多くの推論が必要となります。

ほとんどのエージェントは、さまざまな検索ツールを組み合わせる必要があります。ただし、どのツールも、追加するに見合うだけの価値が求められます。まずは汎用的な検索ツール（たとえば search_database()ツールやシェルツール）から始めることをお勧めします。そして、セキュリティ目的で既に保持しているコマンドログを活用して、ツールの呼び出し、再試行、およびユーザークエリごとの呼び出し回数などを含め、エージェントが実際に何をしているかを追跡しましょう。そして、あるクエリパターンが繰り返されたり失敗したりすることを把握できたなら、それが専用ツールを作るべき合図です。

まとめ

ファイルシステム対データベースという議論は、エンジニアが問うべき実際の問題から目をそらしています。「エージェントが独自のコンテキストを構築するために必要な、適切な検索インターフェースとは何か」という問いの答えはおそらく、「単一のものではない」でしょう。

シェルツールは、さまざまな文脈外の情報源とやり取りするための汎用性の高いツールであり、良い出発点となります。しかし、構造化された分析クエリを使用するユースケースでは、専用のデータベースツールほど効率的で正確ではありません。

目標は、エージェントの実際のクエリパターンをうまく処理できる最小限の検索ツールを見つけることです。まずはシェルツールから始めて、エージェントが実際に何をしているかをログに記録しましょう。繰り返している、または失敗しているクエリパターンを把握できたら、専用なツールを設計すべき時です。

参照資料

1. Thariq（Anthropic）。Lessons from Building Claude Code: Seeing like an Agen（2026年）。

2. Cursor：Documentation。セマンティック検索とエージェント検索（2026年）。

3. Harrison Chase (LangChain)。How we built Agent Builder’s memory system（2026年）。

4. Ankur Goyal（Braintrust）とAndrew Qu（Vercel）。Testing if "bash is all you need"（2026年）。

5. Anthropic。Introducing advanced tool use on the Claude Developer Platform（2025年）。

6. Cursor。動的コンテキスト検出（2026年）。

Elasticsearch Inference APIとHugging Faceモデルを組み合わせて使用

Jeffrey Rengifo — Mon, 23 Mar 2026 00:00:00 GMT

最近のアップデートで、ElasticsearchはHugging Face Inference Serviceでホストされているモデルに接続するためのネイティブ統合機能を導入しました。この記事では、この統合を構成し、大規模言語モデル（LLM）を使用して簡単なAPI呼び出しを通じて推論を実行する方法を探ります。リソース使用量と解答品質のバランスが取れた軽量汎用モデルであるSmolLM3-3Bを使用します。

要件

Elasticsearch 9.3またはElastic Cloud Serverless：これらの指示に従ってクラウド導入を作成することもできますし、start-localクイックスタートを使うこともできます。
Python 3.12：Pythonはこちらからダウンロードしてください。
Hugging Faceアクセストークン。

Hugging Face推論エンドポイントを使用したチャットの完了

まず、ElasticsearchをHugging Faceの推論エンドポイントに接続し、ブログ記事のコレクションからAIを活用したレコメンデーションを生成する実践的な例を作成します。アプリのナレッジベースには、会社のブログ記事のデータセットを使用します。これには価値のある情報が含まれていますが、多くの場合、見つけるのが困難です。

このエンドポイントでは、セマンティック検索が指定されたクエリに対して最も関連性の高い記事を取得し、Hugging Face LLMがそれらの結果に基づいて短いコンテキスト推奨を生成します。

これから構築する情報フローの概要を見ていきましょう。

この記事では、コンパクトなサイズと強力な多言語推論能力・ツール呼び出し能力を組み合わせたSmolLM3-3Bの性能を検証します。検索クエリに基づいて、一致するすべてのコンテンツ（英語とスペイン語）をLLMに送信し、検索クエリと結果に基づいたカスタムメイドの説明を含むおすすめ記事のリストを生成します。

AIによる推奨生成システムを備えた記事サイトのUIは次のようになります。

このアプリケーションの完全な実装は、リンク先のノートブックで確認できます。

Elasticsearch推論エンドポイントの構成

Elasticsearch Hugging Face推論エンドポイントを使用するには、2つの重要な要素（Hugging Face APIキーと実行中のHugging FaceエンドポイントURL）が必要です。下の画像のように表示されるはずです。

PUT _inference/chat_completions/hugging-face-smollm3-3b { "service": "hugging_face", "service_settings": { "api_key": "hugging-face-access-token", "url": "url-endpoint" } }

Hugging FaceのElasticsearchにおける推論エンドポイントは、 text_embedding, completion, chat_completion, と rerankの異なるタスクタイプをサポートしています。このブログ記事では、検索結果とシステムプロンプトに基づいて会話形式のレコメンデーションをモデルに生成させる必要があるため、chat_completion を使用します。このエンドポイントを使用すると、Elasticsearch APIを使用してElasticsearchから直接チャットの完了を簡単に実行できます。

POST _inference/chat_completion/hugging-face-smollm3-3b/_stream { "messages": [ { "role": "user", "content": "" } ] }

これはアプリケーションのコアとして機能し、モデルを通過するプロンプトと検索結果を受け取ります。理論について説明したので、アプリケーションの実装を始めましょう。

Hugging Faceでの推論エンドポイントの設定

Hugging Faceモデルをデプロイするために、モデルのエンドポイントをデプロイするための簡単で高速なサービスHugging Faceワンクリック導入を使用します。これは有料サービスであり、利用には追加料金が発生する可能性があることにご注意ください。このステップでは、記事の推奨を生成するために使うモデルインスタンスが作成されます。

ワンクリックカタログからモデルを選択できます。

SmolLM3-3Bモデルを選択します。

ここから、Hugging FaceのエンドポイントURLを取得します。

Elasticsearch Hugging Faceの推論エンドポイントのドキュメントで述べられているように、テキスト生成にはOpenAI APIと互換性のあるモデルが必要です。そのため、/v1/chat/completionsのサブパスをHugging FaceのエンドポイントURLに追加する必要があります。最終的な結果は次のようになります。

https://j2g31h0futopfkli.us-east-1.aws.endpoints.huggingface.cloud/v1/chat/completions

これで準備が整いましたので、Pythonノートブックでコーディングを開始できます。

Hugging Face APIキーの生成

Hugging Faceアカウントを作成し、以下の指示に従ってAPIトークンを取得してください。トークンの種類は、fine-grained（本番環境に推奨。特定のリソースへのアクセスのみを提供）、read（読み取り専用アクセス用）、write（読み取りおよび書き込みアクセス用）の3つから選択できます。このチュートリアルでは、推論エンドポイントを呼び出すだけでよいので、readトークンで十分です。次のステップのために、このキーを保存しておいてください。

Elasticsearch推論エンドポイントの設定

まず、Elasticsearch Pythonクライアントを宣言します。

os.environ["ELASTICSEARCH_API_KEY"] = "your-elasticsearch-api-key" os.environ["ELASTICSEARCH_URL"] = "https://xxxx.us-central1.gcp.cloud.es.io:443" es_client = Elasticsearch( os.environ["ELASTICSEARCH_URL"], api_key=os.environ["ELASTICSEARCH_API_KEY"] )

次に、Hugging Faceモデルを使用するElasticsearch推論エンドポイントを作成します。このエンドポイントを使用すると、ブログ記事とモデルに渡されたプロンプトに基づいて応答を生成できます。

INFERENCE_ENDPOINT_ID = "smollm3-3b-pnz" os.environ["HUGGING_FACE_INFERENCE_ENDPOINT_URL"] = ( "https://j2g31h0futopfkli.us-east-1.aws.endpoints.huggingface.cloud/v1/chat/completions" ) os.environ["HUGGING_FACE_API_KEY"] = "hf_xxxxx" resp = es_client.inference.put( task_type="chat_completion", inference_id=INFERENCE_ENDPOINT_ID, body={ "service": "hugging_face", "service_settings": { "api_key": os.environ["HUGGING_FACE_API_KEY"], "url": os.environ["HUGGING_FACE_INFERENCE_ENDPOINT_URL"], }, }, )

データセット

このデータセットには、クエリの対象となるブログ記事が含まれており、ワークフロー全体で使用される多言語コンテンツセットを表しています。

// Articles dataset document example: { "id": "6", "title": "Complete guide to the new API: Endpoints and examples", "author": "Tomas Hernandez", "date": "2025-11-06", "category": "tutorial", "content": "This guide describes in detail all endpoints of the new API v2. It includes code examples in Python, JavaScript, and cURL for each endpoint. We cover authentication, resource creation, queries, updates, and deletion. We also explain error handling, rate limiting, and best practices. Complete documentation is available on our developer portal." }

Elasticsearch マッピング

データセットが定義されたので、ブログ記事の構造に適切にフィットするデータスキーマを作成する必要があります。Elasticsearchにデータを格納するために以下のインデックスマッピングが使用されます。

INDEX_NAME = "blog-posts" mapping = { "mappings": { "properties": { "id": {"type": "keyword"}, "title": { "type": "object", "properties": { "original": { "type": "text", "copy_to": "semantic_field", "fields": {"keyword": {"type": "keyword"}}, }, "translated_title": { "type": "text", "fields": {"keyword": {"type": "keyword"}}, }, }, }, "author": {"type": "keyword", "copy_to": "semantic_field"}, "category": {"type": "keyword", "copy_to": "semantic_field"}, "content": {"type": "text", "copy_to": "semantic_field"}, "date": {"type": "date"}, "semantic_field": {"type": "semantic_text"}, } } } es_client.indices.create(index=INDEX_NAME, body=mapping)

ここで、データがどのように構造化されているかをより明確に見ることができます。セマンティック検索を使用して自然言語に基づいて結果を取得し、copy_toプロパティを使用してフィールドの内容をsemantic_textフィールドにコピーします。さらに、titleフィールドには2つのサブフィールドが含まれています。originalサブフィールドは、記事の元の言語に応じて英語またはスペイン語でタイトルを格納し、translated_titleサブフィールドはスペイン語の記事にのみ存在し、元のタイトルの英語訳が含まれています。

データの取り込み

以下のコードスニペットはbulk APIを使用してブログ投稿データセットをElasticsearchに取り込みます。

def build_data(json_file, index_name): with open(json_file, "r") as f: data = json.load(f) for doc in data: action = {"_index": index_name, "_source": doc} yield action try: success, failed = helpers.bulk( es_client, build_data("dataset.json", INDEX_NAME), ) print(f"{success} documents indexed successfully") if failed: print(f"Errors: {failed}") except Exception as e: print(f"Error: {str(e)}")

Elasticsearchに記事を取り込んだので、次にsemantic_textフィールドに対して検索できる関数を作成する必要があります:

def perform_semantic_search(query_text, index_name=INDEX_NAME, size=5): try: query = { "query": { "match": { "semantic_field": { "query": query_text, } } }, "size": size, } response = es_client.search(index=index_name, body=query) hits = response["hits"]["hits"] return hits except Exception as e: print(f"Semantic search error: {str(e)}") return []

推論エンドポイントを呼び出す関数も必要です。この場合、chat_completionタスクタイプを使用してエンドポイントを呼び出し、ストリーミング応答を取得します。

def stream_chat_completion(messages: list, inference_id: str = INFERENCE_ENDPOINT_ID): url = f"{ELASTICSEARCH_URL}/_inference/chat_completion/{inference_id}/_stream" payload = {"messages": messages} headers = { "Authorization": f"ApiKey {ELASTICSEARCH_API_KEY}", "Content-Type": "application/json", } try: response = requests.post(url, json=payload, headers=headers, stream=True) response.raise_for_status() for line in response.iter_lines(decode_unicode=True): if line: line = line.strip() if line.startswith("event:"): continue if line.startswith("data: "): data_content = line[6:] if not data_content.strip() or data_content.strip() == "[DONE]": continue try: chunk_data = json.loads(data_content) if "choices" in chunk_data and len(chunk_data["choices"]) > 0: choice = chunk_data["choices"][0] if "delta" in choice and "content" in choice["delta"]: content = choice["delta"]["content"] if content: yield content except json.JSONDecodeError as json_err: print(f"\nJSON decode error: {json_err}") print(f"Problematic data: {data_content}") continue except requests.exceptions.RequestException as e: yield f"Error: {str(e)}"

ここで、 chat_completions 推論エンドポイントと推薦エンドポイントを合わせてセマンティック検索関数を呼び出し、カードに割り当てられるデータを生成する関数を書くことができます。

def recommend_articles(search_query, index_name=INDEX_NAME, max_articles=5): print(f"\n{'='*80}") print(f"🔍 Search Query: {search_query}") print(f"{'='*80}\n") articles = perform_semantic_search(search_query, index_name, size=max_articles) if not articles: print("❌ No relevant articles found.") return None, None print(f"✅ Found {len(articles)} relevant articles\n") # Build context with found articles context = "Available blog articles:\n\n" for i, article in enumerate(articles, 1): source = article.get("_source", article) context += f"Article {i}:\n" context += f"- Title: {source.get('title', 'N/A')}\n" context += f"- Author: {source.get('author', 'N/A')}\n" context += f"- Category: {source.get('category', 'N/A')}\n" context += f"- Date: {source.get('date', 'N/A')}\n" context += f"- Content: {source.get('content', 'N/A')}\n\n" system_prompt = """You are an expert content curator that recommends blog articles. Write recommendations in a conversational style starting with phrases like: - "If you're interested in [topic], this article..." - "This post complements your search with..." - "For those looking into [topic], this article provides..." FORMAT REQUIREMENTS: - Return ONLY a JSON array - Each element must have EXACTLY these three fields: "article_number", "title", "recommendation" - If the original title is in spanish, use the "translated_title" subfield in the "title" field Keep each recommendation concise (2-3 sentences max) and focused on VALUE to the reader. EXAMPLE OF CORRECT FORMAT: [ {"article_number": 1, "title": "Article title in english", "recommendation": "If you are interested in [topic], this article provides..."}, {"article_number": 2, "title": "Article title in english", "recommendation": " for those looking into [topic], this article provides..."} ] Return ONLY the JSON array following this exact structure.""" user_prompt = f"""Search query: "{search_query}" Generate recommendations for the following articles: {context} """ messages = [ {"role": "system", "content": "/no_think"}, {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt}, ] # LLM generation print(f"{'='*80}") print("🤖 Generating personalized recommendations...\n") full_response = "" for chunk in stream_chat_completion(messages): print(chunk, end="", flush=True) full_response += chunk return context, articles, full_response

最後に、情報を抽出して出力できるようにフォーマットする必要があります。

def display_recommendation_cards(articles, recommendations_text): print("\n" + "=" * 100) print("📇 RECOMMENDED ARTICLES".center(100)) print("=" * 100 + "\n") # Parse JSON recommendations - clean tags and extract JSON recommendations_list = [] try: # Clean up tags cleaned_text = re.sub( r".*?", "", recommendations_text, flags=re.DOTALL ) # Remove markdown code blocks ( ... ``` or ``` ... ```) cleaned_text = re.sub(r"```(?:json)?", "", cleaned_text) cleaned_text = cleaned_text.strip() parsed = json.loads(cleaned_text) # Extract recommendations from list format for item in parsed: article_number = item.get("article_number") title = item.get("title", "") rec_text = item.get("recommendation", "") if article_number and rec_text: recommendations_list.append( { "article_number": article_number, "title": title, "recommendation": rec_text, } ) except json.JSONDecodeError as e: print(f"⚠️ Could not parse recommendations as JSON: {e}") return for i, article in enumerate(articles, 1): source = article.get("_source", article) # Card border print("┌" + "─" * 98 + "┐") # Find recommendation and title for this article number recommendation = None title = None for rec in recommendations_list: if rec.get("article_number") == i: recommendation = rec.get("recommendation") title = rec.get("title") break # Print title title_lines = textwrap.wrap(f"📌 {title}", width=94) for line in title_lines: print(f"│ {line}".ljust(99) + "│") # Card border print("├" + "─" * 98 + "┤") # Print recommendation if recommendation: recommendation_lines = textwrap.wrap(recommendation, width=94) for line in recommendation_lines: print(f"│ {line}".ljust(99) + "│") # Card bottom print("└" + "─" * 98 + "┘")

セキュリティブログの投稿について質問して、これをテストしてみましょう。

search_query = "Security and vulnerabilities" context, articles, recommendations = recommend_articles(search_query) print("\nElasticsearch context:\n", context) # Display visual cards display_recommendation_cards(articles, recommendations)

ここでは、ワークフローによって生成されたコンソール内のカードを確認できます。

すべてのヒットとLLMの対応を含む完全な結果をこのファイルでご覧いただけます。

「Security and vulnerabilities」に関連する記事をクエリしています。この質問は、Elasticsearchに保存されているドキュメントに対する検索クエリとして使用されます。取得された結果はモデルに渡され、モデルはその内容に基づいてレコメンデーションを生成します。ご覧の通り、このモデルは読者がクリックする動機付けとなる魅力的な短いテキストを非常にうまく生成しています。

まとめ

この例では、ElasticsearchとHugging Faceを組み合わせて、AIアプリケーション向けの高速で効率的な集中型システムを構築する方法を示します。Hugging Faceの豊富なモデルカタログにより、このアプローチでは手作業を削減し、柔軟性を確保できます。特にSmolLM3-3Bを使用すると、コンパクトな多言語モデルでも、セマンティック検索と組み合わせることで有意義な推論とコンテンツ生成を実現できることがわかります。これらのツールを組み合わせることで、インテリジェントなコンテンツ分析と多言語アプリケーションを構築するための、拡張性が高く効果的な基盤を提供できます。

ElasticsearchのGemini CLI拡張機能（ツールとスキル付き）

Walter Rafelsberger,Enrico Zimuel — Tue, 17 Mar 2026 00:00:00 GMT

GoogleのGemini CLI用のElastic拡張機能のリリースを発表できることを嬉しく思います。これにより、ElasticsearchとElastic Agent Builderのパワーを、AI開発ワークフローに直接組み込むことができます。この拡張機能には、Elasticsearchを操作するための最近開発されたエージェントスキルもいくつか用意されています。

この拡張機能はオープンソースプロジェクトとしてこちらから利用できます。

Gemini CLIの概要とインストール方法

Gemini CLI は、GoogleのGeminiモデルを直接コマンドラインに取り込むオープンソースのAIエージェントです。ターミナルからAIと対話することで、コードの生成、ファイルの編集、シェルコマンドの実行、ウェブからの情報の取得などのタスクを実行できます。

一般的なチャットインターフェースとは異なり、Gemini CLIはローカル開発環境と統合されます。つまり、プロジェクトのコンテキストを理解し、ファイルを変更し、ビルドやテストを実行し、ワークフローをターミナル内で直接自動化することができます。開発者、サイト信頼性エンジニア（SRE）、コマンドラインのワークフローを離れることなくAI支援のコーディングと自動化を求めるエンジニアにとって役立ちます。

Gemini CLIは複数のパッケージマネージャーを使ってインストール可能です。最も一般的な方法はnpm経由です。

npm install -g @google/gemini-cli

その他のインストール方法については、公式のインストールページを参照してください。

インストール後、以下のコマンドを実行してCLIを起動します。

gemini

図1に示すような画面が表示されます。

Elasticsearchを構成

Elasticsearchインスタンスを実行する必要があります。モデルコンテキストプロトコル（MCP）サーバーを使用するには、Kibana 9.3以降もインストールする必要があります。Elasticsearchクエリ言語 (ES|QL) スキル (esql) を使用するためにKibanaは必要ありません。

Elastic Cloudで無料トライアルを有効化するか、start-localスクリプトを使ってローカルにインストールできます。

curl -fsSL https://elastic.co/start-local | sh

これにより、ElasticsearchとKibanaがコンピュータにインストールされ、Gemini CLIの設定に使用するAPIキーが生成されます。

APIキーは前のコマンドの出力として表示され、 elastic-start-localフォルダ内の.envファイルに保存されます。

オンプレミスのElasticsearchを使用している場合（例えば、start-local）、MCPでElastic Agent Builderを使用するには、大規模言語モデル（LLM）を接続する必要があります。さまざまなオプションを理解するには、このドキュメントページをご覧ください。

Elastic Cloud（またはサーバーレス）を使用している場合は、LLM接続が事前構築されています。

Elasticsearch拡張機能をインストールしてください

次のコマンドを使用して、Gemini CLI用のElasticsearch拡張機能をインストールできます。

gemini extensions install https://github.com/elastic/gemini-cli-elasticsearch

Geminiを開き、以下のコマンドを実行することで、拡張機能が正常にインストールされたことを確認できます。

/extensions list

Elasticsearch拡張機能が利用可能になっているはずです。

MCP統合を使用するには、Elasticsearch 9.3以降のバージョンがインストールされている必要があります。KibanaからMCPサーバーのURLを取得する必要があります。

MCPサーバーのURLは、[エージェント] > [すべてのツールを表示] > [MCPの管理] > [MCPサーバーのURLをコピー] から取得できます。
URLは次のようになります：https://your-kibana-instance/api/agent_builder/mcp

ElasticsearchエンドポイントのURLが必要です。これは通常、Kibana Elasticsearchページの最上部に表示されます。Elasticsearchをstart-localで実行している場合、 start-local .envファイルのES_LOCAL_URLキーにエンドポイントが既に存在します。

APIキーも必要です。Elasticsearchをstart-localで実行している場合、 start-local .envファイルには既にES_LOCAL_API_KEYが含まれています。それ以外の場合は、こちらに記載されているように、Kibanaインターフェースを使用してAPIキーを作成できます。

Kibanaでは、[スタック管理] > [セキュリティ] > [APIキー] > [APIキーの作成] の順に操作します。
API キーには読み取り権限のみを設定し、ここに記載されているようにfeature_agentBuilder.read権限を有効にすることをお勧めします。
エンコードされたAPIキーの値をコピーしてください。

シェルで必要な環境変数を設定してください。

export ELASTIC_URL="your-elasticsearch-url" export ELASTIC_MCP_URL="your-elasticsearch-mcp-url" export ELASTIC_API_KEY="your-encoded-api-key"

サンプルデータセットをインストールする

Kibanaから入手可能なeCommerce ordersデータをインストールできます。このデータベースには、eコマースWebサイトからの4,675件の注文に関する情報を含むkibana_sample_data_ecommerceという単一のインデックスが含まれています。各注文について、次の情報があります。

顧客情報（名前、ID、生年月日、メールなど）。
注文日。
注文ID。
商品（価格、数量、ID、カテゴリー、割引、その他の詳細を含む全商品のリスト）
SKU。
合計金額（税抜、税込）。
合計数量。
地理情報（都市、国、大陸、場所、地域）。

サンプルデータをインストールするには、Kibanaの統合ページを開き（検索トップバーで「Integration」を検索）、Sample Dataをインストールしてください。詳細については、こちらのドキュメントを参照してください。

この記事の目的は、Gemini CLIをElasticsearchに接続し、kibana_sample_data_ecommerceインデックスとやり取りするのがいかに簡単かを示すことです。

Elasticsearch MCPの使用方法

Geminiで以下のコマンドを使用して接続状況を確認できます。

/mcp list

図2に示すように、 elastic-agent-builderが有効になっているはずです。

Elasticsearchはデフォルトのツールセットを提供しています。詳細はこちらをご覧ください。

これらのツールを使用して、Elasticsearchと対話し、次のような質問をすることができます。

Give me the list of all the indexes available in Elasticsearch.
How many customers are based in the USA in the kibana_sample_data_ecommerce index of Elasticsearch?

質問に応じて、Geminiは利用可能なツールの一つ以上を使って回答を試みます。

/elasticコマンド

Gemini CLIのElasticsearch拡張機能では、さらに/elasticコマンドを追加しました。

/helpコマンドを実行すると、利用可能なすべての/elasticオプション（図3）が表示されます。

これらのコマンドは、elastic-agent-builder MCPサーバーの特定のツールを直接実行したい場合に便利です。例えば、以下のコマンドを使用すると、 kibana_sample_data_ecommerceのマッピングを取得できます。

/elastic:get-mapping kibana_sample_data_ecommerce

これらのコマンドは、どのツールを呼び出すかをGeminiモデルに頼るのではなく、基本的に特定のツールを実行するためのショートカットです。

Elasticsearchスキルの使用方法

この拡張機能には、Elasticsearchで利用可能なElasticsearchクエリ言語であるES|QL用のエージェントスキルも付属しています。エージェントスキルは、Gemini CLIのようなAIコーディングエージェントに特定のタスクに合わせたカスタム指示を提供するオープンフォーマットです。段階的開示と呼ばれる概念を採用しており、最初のシステムプロンプトにスキルの簡単な説明のみを追加します。エージェントにElasticsearchへのクエリなどのタスクを実行するように依頼すると、リクエストが関連するスキルと照合され、詳細な指示が動的に読み込まれます。これは、トークン予算を効率的に管理すると同時に、AIが必要とする正確なコンテキストを提供する方法です。

esqlスキルは、Gemini CLIがES|QLクエリを直接クラスターに対して書き込み、実行するように設計されています。ES|QLは強力なパイプクエリ言語で、データ調査、ログ分析、アグリゲーションを非常に直感的に行うことができます。このスキルを有効にすると、ES|QLの構文を調べる必要はなくなり、Gemini CLIにデータについて自然言語で質問するだけであとはエージェントが処理します。

実行は、ターミナルで実行されるシンプルなcurlコマンドを使用して行われます。これは、Elasticsearchが豊富なREST APIを提供し、システムをあらゆるアーキテクチャに容易に統合できるためです。

esqlスキルが提供するもの：

インデックスとスキーマの検出：エージェントは、スキルに搭載されたツールを使用して、利用可能なインデックスを一覧表示し、フィールドマッピングを取得できます。例えば、eCommerce データセットのクエリを書く前に、エージェントは kibana_sample_data_ecommerce でスキーマチェックを実行して、taxful_total_price や category のような利用可能なフィールドを理解することができます。
シームレスな自然言語翻訳：スキルはエージェントに単なるリファレンスマニュアルにとどまらず、ユーザーの意図を解釈するための具体的なガイドを提供します。「サービス別にグループ化された平均応答時間を表示して」といった自然言語によるリクエストを入力すると、エージェントはスキルのバンドルされたパターンマッチングを使用して、入力された言葉を即座に正しいES|QLアグリゲーション、フィルタ、コマンドに変換します。
自動修正： クエリが失敗した場合（例：タイプミスマッチや構文エラーなど）、スキルは生成されたクエリとElasticsearchのエラーを正確に返します。これにより、エージェントは即座にクエリを修正して再試行でき、介入する必要がありません。

esqlスキルはelastic-agent-builder MCPサーバーのツールとしても利用できるため、このサーバーを一時的に無効にする必要があります。以下のコマンドを使用して無効にすることができます。

/mcp disable elastic-agent-builder

そうすれば、Gemini CLIに次のようなプロンプトを入力するだけで済みます。

Find the top 5 product categories by total sales revenue in the kibana_sample_data_ecommerce index

エージェントは以下を実行します：

esql スキルの必要性を認識します。
kibana_sample_data_ecommerceのスキーマを確認してください。
FROM kibana_sample_data_ecommerce | STATS total_revenue = SUM(taxful_total_price) BY category.keyword | SORT total_revenue DESC | LIMIT 5 のようなES|QLクエリを構築します。
Elasticsearch APIに対してクエリを実行します。
最終的な答えを端末に直接表示します。

ここでは、前回の質問に対するGeminiからの回答例を報告します。

─────────────────────────────────────────────────────────── > Find the top 5 product categories by total sales revenue in the kibana_sample_data_ecommerce index ─────────────────────────────────────────────────────────── ✓ Activate Skill "esql": Interact with Elasticsearch using ES|QL and curl. Use when querying, managing indices, … Skill esql activated. Resources loaded from /home/user/.gemini/extensions/elasticsearch/skills/esql: Showing up to 200 items (files + folders). /home/user/.gemini/extensions/elasticsearch/skills/esql/ ├───SKILL.md └───references/ ├───esql-reference.md ├───generation-tips.md └───query-patterns.md ✦ I will start by exploring the mapping of the kibana_sample_data_ecommerce index to identify the fields for product category and sales revenue. Then, I will construct and execute an ES|QL query to determine the top 5 product categories by total sales revenue. ✓ Shell curl -s "${ELASTIC_URL%/}/kibana_sample_data_ecommerce/_mapping" -H "Authorization: ApiKey $(printenv ELAS… { "kibana_sample_data_ecommerce": { "mappings": { "properties": { "category": { "type": "text", "fields": { "keyword": { "type": "keyword" } } }, "currency": { "type": "keyword" }, ✦ Okay, I have the mapping. The category is products.category.keyword and sales revenue is taxful_total_price. I'll now execute the ES|QL query to get the top 5 categories by revenue. ✓ Shell curl -s -X POST "${ELASTIC_URL%/}/_query" \ -H "Authorization: ApiKey $(printenv ELASTIC_API_KEY)" \ -H … { "took": 62, "is_partial": false, "completion_time_in_millis": 1772805644164, "documents_found": 4675, "values_loaded": 12084, "start_time_in_millis": 1772805644102, "expiration_time_in_millis": 1773237644087, "columns": [ { "name": "total_revenue", "type": "double" }, { "name": "products.category.keyword", ✦ The query for top 5 product categories by revenue was successful. I'll format the returned JSON values into a user-friendly list. ✓ Shell Top 5 product categories by total sales revenue: 1. Men's Clothing: 149393.91 2. Women's Clothing: 135099.91 3. Women's Shoes: 105479.17 4. Men's Shoes: 91797.92 5. Women's Accessories: 60830.31 ✦ I've found the answer; now I'll format it for clarity. ✓ Shell Here are the top 5 product categories by total sales revenue: | Rank | Category | Total Revenue | |------|-----------------------|---------------| | 1 | Men's Clothing | 149,393.91 | | 2 | Women's Clothing | 135,099.91 | | 3 | Women's Shoes | 105,479.17 | | 4 | Men's Shoes | 91,797.92 | | 5 | Women's Accessories | 60,830.31 | ✦ I've formatted and presented the answer. I'm finished. ───────────────────────────────────────────────────────────

Geminiモデルが最終的な応答を生成する際にどのような手順を踏むかは非常に興味深い点です。ここでは、モデルの推論プロセスにおけるスキルの影響が明確に見て取れます。モデルがスキルを使用する必要がある、またはシェルコマンドを実行する必要があると初めて認識したとき、ヒューマン・イン・ザ・ループ方式を使用して許可を要求します。

スキーマの発見、クエリの生成、実行といった面倒な作業をesqlスキルが処理することで、回答を得るための仕組みではなく、回答そのものに集中できるようになります。必要なデータが、適切な形式でターミナルに直接表示されます。構文を記述したり、別のアプリケーションに切り替えたりする必要は一切ありません。

まとめ

この記事では、最近リリースしたGemini CLI用のElasticsearch拡張機能を紹介しました。この拡張機能を使用すると、GeminiおよびElastic Agent Builderが提供するElasticsearch MCPサーバー（バージョン 9.3.0 以降で利用可能）と/elasticコマンドを使用してElasticsearchインスタンスとやり取りできます。

さらに、この拡張機能には、ユーザーの自然言語からのリクエストをES|QLに変換する esqlスキルも含まれています。このスキルは、MCPサーバーが使用できない場合に特に役立ちます。なぜなら、基本的な通信はターミナルで実行されるシンプルなcurlコマンドによって行われるためです。Elasticsearchは、あらゆるプロジェクトに簡単に統合できる豊富なREST APIセットを提供します。これは特にエージェント型AIアプリケーションの開発時に有用です。

Gemini CLI拡張機能の詳細についてはこちらのプロジェクトリポジトリをご覧ください。

ElasticのAgent Skills：AIエージェントをElasticのエキスパートに変換

Graham Hudgins,Matt Ryan — Mon, 16 Mar 2026 00:00:00 GMT

専用プラットフォームでAIコーディングエージェントを使用しようとした開発者、サイト信頼性エンジニア（SRE）、アナリストは皆、同じ壁にぶつかっています。エージェントにクエリの作成、アラートの設定、または調査を依頼すると、惜しいところまではいくものの、正しくない結果になるのです。Elasticにはこの点で優位性があります。10年以上にわたるドキュメント、ブログ記事、コミュニティからの回答によって、AIエージェントは既にほとんどのデータプラットフォームよりもElasticをよく理解しているのです。しかし、その深みにはノイズが伴います。非推奨のAPIが現行のAPIと並んで表示され、古いパターンがベストプラクティスと同じくらい高い評価を受けます。エージェントは、3バージョン前にうまくいったアプローチを自信を持って再現します。なぜなら、そのトレーニングデータでは成功したからです。その結果、修正のコストが発生します。ユーザーは手動でドキュメントをコンテキストにフィードし、ハルシネーションによる構文を修正し、エージェントと一緒に作業するのではなく、エージェントを回避して作業するようになるのです。さらに悪いことに、高度な機能が全く使用されていません。これは、ユーザーがこうした機能を必要としていないからではなく、エージェントがその存在を認識していないためです。

だからこそ、当社は、Elasticsearch、Kibana、Elastic Observability、Elastic Securityといったプラットフォームに関するネイティブな専門知識であるElastic Agent Skillsをオープンソースとして提供しています。これらのスキルをすでに使用しているエージェントランタイムにドロップすることで、エージェントを多くの構文を推測する「ジェネラリスト」から、Elasticのエンジニアリングチームが使用する多くのアーキテクチャ標準を活用できる「スペシャリスト」へと改善します。この最初のテクニカルプレビューリリースではElastic Cloud Serverlessとの最大限の互換性を備えたスキルに焦点を当てていますが、古いスタックリリースのサポートを強化するなど、急速に進化させる予定です。

さらに、Elasticはこの問題を両面から解決しようとしています。Elastic Platform上のエージェント向けにElastic Agent Builder（現在一般公開中）を利用して、データのアクセス制御を継承し、搭載の検索・分析ツールを使用し、ダッシュボード、アラート、調査と共にコンテキストで作業するAIエージェントを作成し、チャットすることができます。Elastic Platformで素晴らしいエージェント体験を実現するために懸命に取り組んでいますが、すべてのエージェントがElasticの中に存在するわけではありません。すでにCursor、Claude Codeなどのランタイムを使用されていると思いますが、それらのエージェントでもElasticが正しく動作する必要があります。そこで役立つのがAgent Skillsです。

エージェントが専門プラットフォームで苦労する理由

大規模言語モデル（LLM）は、非常に有能なジェネラリストです。豊富な事例を含むトレーニングデータを持つため、Pythonを記述したり、Kubernetesのマニフェストを説明したり、Reactコンポーネントをリファクタリングしたりすることができます。しかし、独自のクエリ言語、高度なAPIサーフェス、ドメイン固有のベストプラクティスなどを伴うプラットフォーム固有の作業となると、予測可能な形で不十分さを示します。

Elasticsearchの場合、そのギャップは具体的に現れます。

Elasticsearchクエリ言語（ES|QL）は新しい領域です。LLMはSQLに関するトレーニングを重点的に受けていますが、ES|QLは構文、機能、セマンティクスが異なるパイプ型クエリ言語です。エージェントは、一見もっともらしく見えるものの、解析できないクエリを頻繁に作成します。彼WHERE を | WHEREと混同し、存在しない関数を発明し、パイプベースの合成モデルを完全に見落としています。
APIサーフェスは広く深いものです。Elasticsearch、Kibana、Elastic Securityは、検索、インジェスト、アラート、検出ルール、ケース管理、ダッシュボードなど、何百ものAPIを公開しています。エージェントは、一般的なトレーニングデータのみを武器に、どのエンドポイントを呼び出すか、リクエスト本文がどのようなものか、そして応答をどのように処理するかを推測しなければなりません。予測ミスが頻繁に起こるため、信頼が損われることになります。
ベストプラクティスはトレーニングデータには含まれません。semantic_textとカスタム埋め込みパイプラインは、それぞれどのような場合に使い分けるべきでしょうか？10GBのCSVの取り込みパイプラインはどのように構築すべきでしょうか？MITRE ATT&CK技術の適切な検出ルール構文はどれですか？汎用エージェントには、デフォルトで厳選され、信頼性の高い構造化されたElastic固有の知識がロードされていません。エージェントはそうした知識を探し出さなければならず、たとえ見つけたとしても、生の文書には熟練した専門家が持つ判断やベストプラクティスが必ずしも反映されているとは限りません。

その結果、開発者は自分でコードを書くよりも、エージェントの出力を修正することに多くの時間を費やすことになります。予測していた結果とは言えません。

Agent Skills：Platformの知識をエージェント向けにパッケージ化

Agent Skillsとは、エージェントランタイムが動的に読み込むことができる、指示、スクリプト、およ参照資料を含む自己完結型のディレクトリです。スキルがアクティブな時、エージェントは適切なタイミングで適切なコンテキストにアクセスできます。クエリ構文、APIパターン、検証ロジック、実践例などを活用し、一回の試行でタスクを正しく完了できます。

各スキルは、オープンなagentskills.io仕様に準拠しています。メタデータと構造化された手順を含むSKILL.mdファイルを含むフォルダです。独自のフォーマットもロックインもありません。スキルは、Cursor、Claude Code、GitHub Copilot、Windsurf、Gemini CLI、Cline、Codexなど、さまざまなエージェントランタイムで動作します。

初期バージョンv0.1.0に含まれる内容

最初のスキルセットは、Elastic Stackの5つの分野にまたがっています。

Elasticsearch APIとのやり取り（検索、インデキシング、クラスター管理）
ダッシュボード、アラート、コネクターなどのKibanaコンテンツの構築と管理
Elastic Observabilityの専門知識
Elastic Securityの専門知識
Agent Builderで効果的なエージェントを作成

スキルは組み合わせ可能です

スキルはモノリシックではなく、モジュール式の設計になっています。エージェントは、目の前のタスクに関連するスキルのみを読み込みます。ES|QLクエリを作成中なら、ES|QLスキルが発動します。その結果からダッシュボードを作る必要があるなら、ダッシュボードのスキルを習得します。アプリケーションの健全性を評価したいなら、サービス健全性スキルが対応します。セキュリティアラートの調査の場合は、トリアージスキルが調査が進むにつれてケース管理と対応スキルに連鎖します。

こうしたこの構成可能性のおかげで、すべてを網羅しようとする単一の巨大なプロンプトは必要なくなります。それぞれのスキルは、その分野に必要な文脈を正確に保持しており、それ以上でもそれ以下でもありません。

検索やAIアプリケーションを開発する開発者向け

Elasticsearchにデータをロードしたり、クエリを作成したり、インデックスを移行したりする際に、十分なスキルがあれば、コードを生成してエラーが発生し、その原因をドキュメントで調べるという繰り返しのサイクルを短縮できます。

エージェントにCSVファイルの読み込みを依頼すると、バックプレッシャーを処理し、データからマッピングを推測するストリーミングインジェストツールが使用されます。これは、最初の大きなファイルでメモリ不足になるような、手作業で作成した_bulkループではありません。ES|QLでクエリを実行するように依頼すると、実際のインデックス名とフィールドスキーマを検出し、その後、正しい構文、適切なアグリゲーション、バージョン対応の機能選択を備えた有効なパイプ付きクエリを作成します。これは、3回ものデバッグが必要なSQL風の推測ではなく、正確な処理です。クラスター間での再インデックスを指示すると、完全な運用ワークフローに従います。明示的なマッピングで送信先を作成し、スループットに合わせて設定を調整し、ジョブを非同期で実行し、完了時には本番環境の設定を復元します。これは、経験豊富なオペレーターが従う半分のステップをスキップする単なる_reindex呼び出しではありません。

修正が必須となるそれらしい出発点を示すエージェントの代わりに、出力が実際に機能するための運用規律を組み込んだエージェントが手に入ります。

Elastic Agent Skillsの使用によるインパクトの例

Eval

スキルによる変更内容

es-監査-クエリ-失敗したログイン

一般的な検索の代わりにスキルの監査ログクエリパターンを使用

es-authz-role-mapping-ldap

正しいロールマッピングAPI呼び出し構造を出力

esql-basic-query

ES|QLパイプ構文をクエリDSL上に記述

esql-error-handling

フィールド名を推測する代わりにスキーマを先に設定

esql-schema-discovery

インデックス名を推測したことは一度もなし

es-ingest-csv-with-infer

--infer-mappingsのみを使用し、--source-format csvとの組み合わせは回避（組み合わせると空のインデックスがマッピングされるため）

es-ingest-json-file

大容量ファイルを処理できる堅牢なインジェスト方式を採用

es-reindex-local-async

まずレプリカ数0、更新間隔「-1」で宛先インデックスを作成し、その後非同期で再インデックスを実行、ベースラインはあらゆる準備をスキップ

es-security-403-privileges

一般的なアドバイスではなく、スキルの診断ワークフローに従って特権エラーを解決

セキュリティチーム向け

セキュリティチームは、アラートのトリアージ、検出ルールの調整、ケースの管理といった、同じ運用ワークフローを毎日繰り返しています。Agent Skillsは、AIエージェントがこれらのワークフローを正しく実行し、適切な順序で適切なフィールド名で適切なAPIを呼び出せるように、その手順知識をエンコードします。IDEを離れることなく、ゼロから完全に機能するElastic Security環境を構築するまでの手順を実際に確認するには、「AIエージェントからElastic Securityを使い始める」を参照してください。

オブザーバビリティおよび運用チーム向け

Elastic Observabilityのための新しいAgent Skillsは、複雑なシステムのインスツルメンテーション、SLOの管理、複雑なデータの選別、サービスの健全性の評価といった運用の手間を軽減します。ネイティブのElastic専門知識をAIエージェントに直接組み込むことで、チームはシンプルな自然言語を使用して複雑なオブザーバビリティワークフローを実行できます。これにより、SREと運用チームはインシデントをより迅速に解決し、信頼性の高いシステムをより簡単に保守できます。詳しくはこちらのブログ記事をご覧ください。

オープンソース、オープン仕様、コミュニティ主導

エージェントの知識はオープンであるべきだと当社は考えているため、Agent SkillsをApache 2.0ライセンスで公開しています。スキルが準拠するagentskills.ioの仕様はオープンスタンダードであり、Elastic独自のフォーマットではありません。スキルが閉鎖的な環境ではなく、コミュニティ全体の取り組みとなることを望んでいます。

より大きな全体像の一部

Agent Skillsは、Elasticsearchを最もエージェントにとって使いやすいデータプラットフォームにするための広範な取り組みの一環です。Elasticsearch Platform上で動作するエージェントの場合、Agent Builderは、データのアクセス制御と権限を継承し、検索と分析のための組み込みツールとカスタムツールを提供し、ユーザーがダッシュボード、アラート、調査と共にコンテキスト内でエージェントと対話できるようにすることで、さらに進化します。最後に、Agent Builderでのスキルのサポートが間もなく開始されます。これにより、開発者はElastic Agent Skillsやその他のソースのスキルを柔軟に活用して、Elasticsearchプラットフォームで安全でコンテキストが強化されたチャットと自動化を実現できます。

他の領域で動作するエージェントのために、以下のようにオープンエコシステムに投資しています。

モデルコンテキストプロトコル（MCP）サーバーの拡張：Agent BuilderのMCPエンドポイントを、現在の検索、ES|QL、インデックス操作以外のより多くのツールで拡張します。
認証機能の改善：エージェントが安全に接続しやすくすることで、APIキーの手動コピー＆ペーストを排除することを目指します。
LLMで読み取り可能なドキュメント：エージェントがElastic APIを独自に発見して理解できるように、 llms.txtファイルとAGENTS.mdファイルを公開します。
エージェントワークフロー用のコマンドラインインターフェース（CLI）：接続管理や一般的な操作をエージェントにとって使いやすいものにするコマンドラインツール。

スキルは本日からご利用いただけるレイヤーです。残りはこれから提供されます。

使用を開始

始める前に：AIコーディングエージェントは、実際の認証情報、実際のシェルアクセス、そして多くの場合、実行しているユーザーの完全な権限を使用して動作します。エージェントがセキュリティワークフローに向けられる場合、自動化されたシステムに検出ロジック、対応アクション、機密テレメトリへのアクセスを委ねることになり、リスクはより高くなります。すべての組織のリスクプロファイルは異なります。AIを活用したセキュリティワークフローを有効にする前に、エージェントがアクセスできるデータ、実行できるアクション、予期しない動作が発生した場合に何が起こるかを評価してください。

Elastic Agent Skillsをエージェントランタイムにインストールする：

npx skills add elastic/agent-skills

これにより、インストールされているエージェントランタイムが自動的に検出され、スキルが適切な構成ディレクトリに配置されます。そこからエージェントが自動的にそれらを拾います。

また、スキルカタログを直接ブラウズし、スキルフォルダをエージェントの設定ディレクトリにコピーして、個別に手動でスキルをインストールすることもできます。

まだElasticsearchクラスターをお持ちではありませんか？Elastic Cloudの無料トライアルを始めましょう。1分ほどで完全に構成された環境を構築できます。

プロジェクトを探索：

Common Expression Language（CEL）：CEL入力がElastic Agent統合におけるデータ収集を改善する方法

Chris Berkhout — Fri, 27 Feb 2026 00:00:00 GMT

Elastic Agent統合により、ユーザーは幅広いソースからデータをElasticsearchに取り込むことができます。コレクションロジック、取り込みパイプライン、ダッシュボード、その他のアーティファクトをパッケージにまとめ、Kibana Webインターフェースからインストールおよび管理できます。

統合では、データ収集を行うためにFilebeat入力を設定します。HTTP APIからデータを収集するために、私たちはしばしばHTTP JSON入力を使用してきました。しかし、基本的なリスティングAPIでさえ、細部において大きく異なることがあり、HTTP JSON入力のYAMLで構成された変換のモデルでは必要なコレクションロジックを表現するのが難しく、場合によっては不可能になることがあります。

Common Expression Language（CEL）入力は、HTTP APIとのより柔軟な相互作用を可能にするために導入されました。CELは、条件やデータ変換を高速、安全、かつ拡張性のある方法で表現するアプリケーションに組み込めるよう設計された言語です。CEL入力を使用すると、統合ビルダーは設定を読み取り、自身の状態を追跡し、リクエストを作成し、応答を処理し、最終的に取り込む準備が整ったイベントを返すことができる1つの式を記述できます。

この記事では、CELが他のプログラミング言語との違い、CEL入力用の拡張方法、そしてデータ収集ロジックを表現する上で提供するその柔軟性とパワーについて見ていきます。

CELと入力での動作の仕組み

CELは式言語で、ステートメントはありません。CELを記述する場合、ステートメントを記述して何を実行するかを指示するのではなく、式を記述してどのような値を生成するかを指示します。すべてのCEL式は値を生成し、小さな式を組み合わせて大きな式にすることで、より複雑なルールに従った結果を生成することができます。後ほど、他の言語のステートメントで記述できる内容に対して式を使用する方法について説明します。

CELは意図的に非チューリング完全言語であり、無限ループは許可されません。後ほど、マクロを使用してリストやマップを処理する方法を見ていきますが、無限ループを避けることで、この言語は個々の式に対して予測可能で制限された実行時間を保証します。

CEL入力は、CELプログラム（式）といくつかの初期状態で設定されます。状態はプログラムの入力として提供され、プログラムは出力状態を生成するために評価されます。出力状態にイベントのリストが含まれている場合、それらは削除されて公開されます。残りの出力状態は、次の評価の入力として使用されます。出力状態に1つ以上のイベントとフラグwant_more: trueが含まれている場合、次の評価はすぐに実行されます。それ以外の場合、設定された間隔の残りの時間スリープしてから続行します。以下は入力の制御フローの簡略的な図です。

各評価の出力は、入力が実行されている限り、次の評価への入力として順に渡されます。キー「cursor」下の出力データはディスクに永続化され、入力の再起動後に再ロードされますが、その他の状態は再起動をまたいで保存されません。

CEL言語自体は機能が制限されており、副作用を回避しますが、拡張可能です。cel-goの実装では、オプションの構文や型などの機能が追加されています。Mitoライブラリはcel-goを基盤とし、HTTPリクエストの機能を含むより多くの機能を追加しています。CEL入力はMito版のCELを使用しています。

Mitoの操作

CEL入力を使用して統合を構築またはデバッグする際、最も重要なことは、与えられた入力状態に対してCELプログラムがどのような出力状態を生成するかを理解することです。開発中は、完全なElasticスタックに囲まれた入力でCELプログラムを実行するのは面倒な場合があります。より高速なフィードバックループを実現する1つの方法は、Mitoのコマンドラインツールを使用することです。このツールを使用すると、CELプログラムを直接実行し、特定の入力に対して生成される出力を確認できます。

MitoはGoで記述されており、以下のようにインストールできます。

go install github.com/elastic/mito/cmd/mito@latest

MitoでCELプログラムを実行する場合、通常は2つのファイルを指定します。初期入力状態を含むJSONファイルと、CELプログラムのソースコードを含む別のファイルです。

mito -data state.json src.cel

コピー＆ペーストを容易にするため、この記事の例は、シェルが<(echo '...content...')で各ファイルの内容をラップして、その場で一時ファイルを作成する単一のコマンドとして記述されています。独自の開発では、実際のファイルを操作する方が簡単になります。

GitHubからイシューデータを取得

以下の例には、GitHub APIからイシューに関するデータを取得する完全なCELプログラムが含まれています。その初期入力状態には、APIエンドポイントのURLと、ページネーションをどのように処理すべきかについての情報が含まれています。CELプログラムは、入力状態のデータを使用してリクエストを生成します。対応をデコードし、そこからイベントを生成し、出力状態の一部として返します。

mito -data <(echo ' { "url": "https://api.github.com/repos/elastic/integrations/issues", "per_page": 3, "max_pages": 3 } ') <(echo ' int(state.?cursor.page.orValue(1)).as(page, ( state.url + "?" + { "state": ["all"], "sort": ["created"], "direction": ["asc"], "per_page": [string(state.per_page)], "page": [string(page)], }.format_query() ).as(full_url, request("GET", full_url).with({ "Header": { "Accept": ["application/vnd.github+json"], "X-GitHub-Api-Version": ["2022-11-28"], } }).do_request().as(resp, resp.Body.decode_json().as(data, state.with({ "events": data.map(i, { "html_url": i.html_url, "title": i.title, "created_at": i.created_at, }), "cursor": { "page": page + 1 }, "want_more": size(data) == state.per_page && page < state.max_pages, }) ) ) ) ) ')

その最初の評価は次の出力を生成します。

{ "cursor": { "page": 2 }, "events": [ { "created_at": "2018-09-14T09:47:35Z", "html_url": "https://github.com/elastic/integrations/issues/3250", "title": "Increase support of log formats in haproxy filebeat module" }, { "created_at": "2019-02-06T12:37:37Z", "html_url": "https://github.com/elastic/integrations/issues/487", "title": "ETCD Metricbeat module needs polishing and grooming" }, { "created_at": "2019-08-13T11:33:11Z", "html_url": "https://github.com/elastic/integrations/pull/1", "title": "Initial structure" } ], "max_pages": 3, "per_page": 3, "url": "https://api.github.com/repos/elastic/integrations/issues", "want_more": true }

イベントは削除され、CEL入力で実行されると、インジェストのために公開されます。残りの出力は、次のCELプログラム評価に入力状態として提供されます。

そのCELプログラムの仕組みを理解するために、いくつかの小さなCELの例で、CEL入力の仕組みについて詳しく説明します。

CELの基本

CEL言語にはステートメントはなく、式のみが存在します。成功したすべてのCEL式は最終値まで評価されます。以下は、記述できる最も小さなCEL式の1つと、その出力です。

mito <(echo ' "hello" + " " + "world" ')"hello world"

シンプルな表現は通常、直感的です。数学演算は同じタイプの値でのみサポートされます（例：int と int など）。そのため、必要に応じてタイプを変換します（ここでは int から double へ）。

mito <(echo ' double((1 + 2) * (3 + 4)) / 2.0 ')10.5

CEL言語には変数はありませんが、Mitoのasマクロを使用して、式に名前を付け、より大きな式で使用することができます。この例では、式(1 + 1)は値2に評価され、.as(n, ...)がその値に式"one plus one is "+string(n)で使用するための名前nを付けます。

mito <(echo ' (1 + 1).as(n, "one plus one is "+string(n)) ')"one plus one is 2"

また、withを使用して示したように、マップに情報を蓄積し、それを後で式の中で使用することも可能です。

mito <(echo ' { "key": "value" }.with({ "key2": "value2" }).as(data, { "data": data, "size": size(data), } ) '){ "data": { "key": "value", "key2": "value2" }, "size": 2 }

その例をもう一度見てみましょう。ネストされた部分({ "data": data, "size": size(data), })が最終値の形状を示すことに注意してください。これは"data"と"size"をキーとするマップです。これらのキーの値はdataに依存し、式の外側部分によって定義されます。CEL式を内側から外側まで読み取ると、何が返されるかをすぐに把握できるようになります。

CELにはifのような制御フロー文はありませんが、条件分岐は三項演算子で実行可能です。

mito <(echo ' 1 + 1 < 12 ? "few" : "many" ')"few"

CELはチューリング完全言語ではないため、無制限のループと再帰はサポートされていません。これにより、実行時間が予測可能になり、入力データのサイズと式の複雑さに比例するようになります。

個別のCEL式では無限ループはできませんが、mapのようなマクロを使ってリストやマップを処理できます。

mito <(echo ' [1, 2, 3].map(x, x * 2) ')[2, 4, 6]

このセクションでは、次の内容を説明しました。

文字列、数値、リスト、マップ。
文字列の連結。
数学演算。
タイプキャスティング。
条件文。
部分式の命名。
コレクションの処理。

次に、HTTPリクエストを行う方法を見ていきます。

リクエスト

MitoはCELを拡張してHTTPリクエストを行う機能を提供します。

mito <(echo ' get("https://example.com").as(resp, string(resp.Body)) ')"Example Domain..."

リクエストは実行前に明示的に構築することができます。これにより、さまざまなHTTPメソッドを使用したり、ヘッダーや本文を追加したりできるようになります。

この例では、 format_queryを使用してURLを構築し、リクエストにヘッダーを追加し、 decode_jsonを使用してレスポンス本文を解析します。-log_requestsオプションを指定すると、Mitoは各リクエストと対応に関する詳細情報をJSON形式でログに記録します。

mito -log_requests <(echo ' request("GET", "https://postman-echo.com/get?" + { "q": ["query value"] }.format_query() ).with({ "Header": { "Accept": ["application/json"] } }).do_request().as(resp, { "status": resp.StatusCode, "data": resp.Body.decode_json(), }) '){"time":"...","level":"INFO","msg":"HTTP request",...} {"time":"...","level":"INFO","msg":"HTTP response",...} { "data": { "args": { "q": "query value" }, "headers": { "accept": "application/json", "accept-encoding": "gzip, br", "host": "postman-echo.com", "user-agent": "Go-http-client/2.0", "x-forwarded-proto": "https" }, "url": "https://postman-echo.com/get?q=query+value" }, "status": 200 }

状態と評価の管理

ここまで、リクエストの作成方法と、目的の出力状態を生成するために必要なCELの基本について説明しました。次は、出力状態に何を入れるべきか、そしてそれによって後続の処理をどのように指示できるかについて詳しく見ていきましょう。

統合のCELプログラムでは、その出力状態が次の評価の入力として使用するのに適していることを確認する必要があります。構成では初期状態を設定し、適切な変更を加えて出力でそれを繰り返す必要があります。簡単な方法は state.with({ ... }) を使って、状態マップをオーバーライドして繰り返し表示することです。小規模プログラムの一般的なパターンは、state.with()でプログラム全体をラップすることです。これにより、出力データを生成する各分岐（例えば、成功、エラー）で状態の伝播を繰り返す必要がなくなります。

初期入力状態にハードコードされているのではなく、評価によって初期化される状態値がある場合、プログラムは初期値を設定する前に既存の値を確認する必要があります。これにはオプションの構文と型のサポートが役立ちます。マップキーのフィールド名の前に疑問符を使用すると、アクセスはオプションになります。値に解決される場合とされない場合がありますが、さらにオプションのアクセスが可能であり、値が存在しない場合にデフォルトを簡単に提供できます。

mito -data <(echo '{}') <(echo ' int(state.?counter.orValue(0)).as(counter, state.with({ "counter": counter + 1, "want_more": counter + 1 < 3, }) ) '){ "counter": 1, "want_more": true } { "counter": 2, "want_more": true } { "counter": 3, "want_more": false }

その例では、状態から読み取られたカウンター値はintにキャストされます。これは、JSONとJavaScriptのNumber型によって確立された規則に従って、状態内のすべての数値が浮動小数点数としてシリアライズされるためです。また、"want_more": trueはここでMitoによって尊重されますが、CEL入力で実行される場合、出力にもイベントが含まれている場合にのみ評価が繰り返されます。

CEL入力によって実行されるCELプログラムでは、出力マップに"events"キーを返すことが要件となります。その値はイベントマップのリスト、空のリスト、または単一のイベントマップである場合があります。単一イベントケースは通常、エラーに使用されます。イベントは入力によって公開されますが、その値もログに記録されます。error.message値が設定されている場合、その値は統合のFleetのヘルスステータスを更新するために使用されます。プログラムが単一の非エラーイベントを生成する場合は、それをリストにラップするのが最適です。

先ほどのGitHubイシュープログラムの出力をもう一度見てみましょう。

{ "url": "https://api.github.com/repos/elastic/integrations/issues", "per_page": 3, "max_pages": 3, "cursor": { "page": 2 }, "events": [ { ... }, { ... }, { ... } ], "want_more": true }

プログラムは次のようにして状態を効果的に管理しました。

url、per_page、max_pagesで初期状態値を繰り返します。
cursor.pageの再起動時に永続化されるべき状態を追加します。
eventsリストで公開する準備ができたイベントを返します。
want_more: trueで即時の再評価をリクエストしています。

オプションのアクセスと状態管理、CELの基本とHTTPリクエストを理解できたので、GitHubのイシュープログラム全体が読み取れるようになります。Mitoで実行し、いくつか変更を加えて実験してみてください。

レビューとリソース

この記事では、CEL言語とは何か、そしてそれがMitoライブラリでどのように拡張され、CEL入力で使用されるかを調べました。GitHub APIからイシュー情報を取得するサンプルプログラムでCELの柔軟性を確認し、初期状態での設定へのアクセス、HTTP APIとのやりとり、取り込むべきイベントのリターン、後のプログラム実行のための状態管理など、そのプログラムを理解するために必要なすべての詳細を説明しました。

CEL入力を使用してさらに学び、統合を構築ために役立つリソースは多数あります。

CEL入力を使用した統合を構築するための最も貴重なリソースは、GitHubで入手できる既存のElastic 統合のCELコードです。

cel.yml.hbs Elastic統合リポジトリ内のファイル - GitHub

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

Alexander Wert,Bill Easton,Gil Raphaelli,Graham Hudgins,Norrie Taylor — Thu, 22 Jan 2026 00:00:00 GMT

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

私たちは皆、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)ループでした。

{ "tool_name": "my_tool", "tool_arguments": "\{stringified json arguments\}" }

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

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

エージェントは、このJSONすべてをユーザーとの会話に直接吐き出します。
メッセージが会話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を返すことだけです。これにより、以下の簡単なワークフロー定義が得られます。

name: ai-tool-call enabled: true triggers: - type: manual inputs: - name: runner_id type: string - name: tool_calls type: string steps: - name: store_request type: elasticsearch.create with: index: distributed-tool-requests id: "{{inputs.runner_id}}_{{ execution.id }}" document: request_id: "{{ execution.id }}" runner_id: "{{inputs.runner_id}}" tool_call: "{{inputs.tool_calls}}" status: "unhandled" - name: output_result type: console with: message: "ツールが呼び出されました。実行ID: {{ execution.id }}. このIDを使用して結果をポーリングしてください。"

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

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

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

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

すべてを集約

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

Augmented Infrastructureのランナー：ターゲット環境（サーバー、Kubernetesクラスター、クラウドアカウント）内に軽量ランナーをデプロイしました。これらのランナーは、各ランナーだけが利用できる安全なエンドポイントとシークレットを使用して、Elasticに直接接続されています。
ES|QL検索：コパイロットはElasticのES|QLを使用してハイブリッド検索を行います。単に知識を検索するだけではなく、機能を検索します。接続されたランナーに問い合わせて利用可能なツールを確認します（例：list_ec2_instances, install_helm_chart）。
ワークフローの実行：エージェントが行動方針を決定すると、構造化されたワークフローを作成します。
フィードバックループ：ランナーはローカルでコマンドを実行し、その結果を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を設定します。
ランナーを起動すると、エージェントとそのツールが自動的に作成されます。
分散ランナーで推論、計画、およびアクションを実行できるエージェントとチャットしましょう。

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

Agent Builderが一般提供開始：コンテキスト駆動型エージェントを数分で出荷

Anish Mathur,Evan Castle — Thu, 22 Jan 2026 00:00:00 GMT

Elastic Cloud Serverlessおよび近日公開予定の9.3リリースで、Agent Builderが一般公開されることを発表できることを嬉しく思います。Agent Builderは、コンテキストエンジニアリングプラットフォームとしてElasticsearchの機能を活用し、コンテキストに基づいたデータ重視のAIエージェントを迅速に開発します。

エージェントは、効率性の向上と顧客体験の向上をもたらす可能性で注目を集めています。しかし実際には、乱雑で構造化されていないエンタープライズデータを扱う場合など、エージェントに適切なコンテキストを提供することは困難です。開発者は、ツール、プロンプト、状態、推論ロジック、モデルを管理し、ビジネスソースから関連するコンテキストを取得して正確な結果とアクションを提供する必要があります。Elastic Agent Builderは、これらのコアコンポーネントを提供して、安全で信頼性の高い、コンテキスト駆動型のエージェントを開発します。

Agent Builderのコア機能

Agent Builderは、検索の関連性とRetrieval-Augmented GenerationへのElasticの長期投資を活用し、Elasticsearchをコンテキストに応じたデータ重視のAIエージェントの開発を簡素化する最高のベクトルデータベースにすることを目指しています。

Agent Builderを使用すると、次のことが可能になります。

質問に答え、分析を実行し、Elasticsearch内のあらゆるデータに関する調査を推進できる組み込みの会話エージェントをすぐに使い始めることができます。
複雑な非構造化データから、設定ベースの開発エクスペリエンスを用いてカスタムエージェントへ迅速に移行します。
組み込みのES|QLまたはカスタムツールを通じてクラス最高のハイブリッド検索関連性を活用し、コンテキストの品質とエージェントの信頼性を向上させます。
複雑なワークフロー（プレビュー）を再利用可能なツールとして実行し、データを充実させ、レコードを更新し、メッセージを送信するなど、ルールベースの自動化を実現します。
ワークフローとMCPを使用してElasticsearch外のデータソースに接続し、エージェントのコンテキストを関連付けたり組み合わせたりします。
搭載のまたはカスタムツールをMCP経由で公開して、任意のエージェントまたはアプリケーションフレームワークと統合し、外部MCPに接続する機能（プレビュー）、A2Aのサポート、完全なAPIサポートを提供します。
LlamaIndexを使用した複雑な文書処理や、Arcade.devを使用した安全で構造化されたツールアクセスなどのサードパーティソリューションと統合して、Agent Builderの機能を拡張します。

Agent Builderの機能をさらに拡張するために、新しいルールベースの自動化機能であるElastic ワークフローを導入します。現在はテクニカルプレビュー段階です。組織のタスクでは、エージェントはルールベースのアクションの確実性と信頼性を必要とする場合があり、これは特定のビジネスロジックを実装するために不可欠となることがよくあります。Elastic Workflowsは、内部システムと外部システムを管理してアクションを実行し、データやコンテキストを収集して変換するためのシンプルで宣言的な方法をエージェントに提供します。ワークフローは完全にコンポーザブルで、イベント主導型かつ柔軟性があり、MCPを介してエージェントにツールとして公開できます。

わずか数分でデータからエージェントへ

エージェントの開発には、別々のデータストアを統合し、手動のパイプラインを構築し、クエリを調整し、複雑なオーケストレーションを管理するために、数週間の事前作業を要する場合があります。Agent Builderは、データストア、ベクトルデータベース、RAGパイプライン、検索レイヤー、クエリトランスレータ、ツールオーケストレータの必要性を排除することで、エージェントの開発時間を短縮し、エージェントのロジックとアプリケーションの提供に集中できるようにします。

Agent BuilderはElasticsearchプラットフォームのプリミティブをネイティブに統合して、エージェントの開発を迅速にします。

インデックス付けされたデータとすぐにチャットして推論できる組み込みの会話エージェントから始めましょう。
Kibana、API、またはMCPやA2Aを介したインタラクティブなアクセスにより、エージェントをアプリケーション、ダッシュボード、CI/CDシステムに統合します。
デフォルトのツールを使用してデータ構造を理解し、適切なインデックスを選択し、最適化されたハイブリッド、セマンティック、構造化クエリを生成し、自然言語プロンプトに基づいてES|QLを使用した設定可能な可視化を作成します。

さらに詳しく知りたい場合は、完全なハンズオンウォークスルーをお試しください。

コンテキストエンジニアリングのための完全なデータプラットフォームであるElasticsearch上に構築

AIエージェントにとって、コンテキストの品質は効果的な推論を提供し、ハルシネーションのリスクを軽減するために不可欠です。多くの企業のAIエージェントにとって、タスクを実行するために必要なビジネスデータは、最も重要なコンテキストです。拡張性に優れたデータ格納、ベクトルデータベース、そして関連性におけるリーダーとして、Elasticsearchはすでに多くの強力なコンテキストエンジニアリングプリミティブを提供しています。コンテキストエンジニアリングは、単なるRetrieval-Augmented Generationを超えて、データの取得、ランキング、フィルタリング、エージェントへの提示方法をカスタマイズ・スケールできるようにすることで、ノイズと曖昧さを減らすのに役立ちます。

Elasticsearchは、レキシカル検索、ベクトル検索、構造化フィルタリングを組み合わせたコンテキストエンジンを提供し、モデルが関連性のある正確なコンテキスト上で動作することを確実にすることで、LLMのパフォーマンスを大幅に向上させます。この機能は、エージェント検索、組み込みツール、適切なインデックスを自動的に選択し、自然言語をコンテキストに最適化されたクエリに変換する検索ロジックによってサポートされています。

Agent Builderでは、関連性とランキングを制御して、エージェントが最も役立つコンテキストを最初に受け取るようにして、スコアリング、ランキング、フィルタリングロジックを微調整できます。Elasticsearchを使用すると、不透明な検索動作に頼るのではなく、重要なこと、重要な理由、優先順位付け方法を制御できます。これらはすべて、テキスト、ベクトル、メタデータ、ログなどすべてのデータを1つのプラットフォームに保存・拡張できるスケーラブルなデータプラットフォームであるElasticsearchによって支えられており、エージェントのコンテキスト管理が容易になります。

複雑なワークフローを再利用可能なツールとして実行

AIエージェントは複雑なタスクの推論を可能にしますが、多くの自動化は、特定のビジネスロジックを強制するルールベースのアクションの確実な実行に依存しています。Elastic Workflowsは、内部および外部のシステムをオーケストレーションし、アクションを実行し、コンテキストやデータを収集し、エージェントの一部として統合するための、シンプルで宣言的な方法を提供します。YAMLで定義されているワークフローは完全にコンポーザブルで、ジョブに応じて単純にしたり複雑にしたりできます。これにより、エージェントはElasticsearchプラットフォームやソリューション、そしてサードパーティのアプリケーションに対して効率的にアクションを起こすことができます。

ワークフローをAgent Builderと統合するには、3つの手順を実行します（前提条件：ここに記載されている詳細を使用してワークフローを有効にします）

1. シンプルなYAMLベースのエディターを使用して、組み込みの自動入力とテスト機能付きで新しいワークフローを作成して保存します。

2. Agent Builderでタイプ「ワークフロー」の新しいツールを作成し、エージェントがワークフローツールをいつ使用するかを判断できるように説明を入力します。

3. ワークフローツールをカスタムエージェントに追加します。

4. 以上です！エージェントが会話内からワークフローを呼び出せるようになりました。

ニーズに合わせてエージェントを構築

Agent Builderは単一の開発パラダイムに限定されず、データ、関連性、モデル、相互運用性、セキュリティ、エージェント設計を完全に制御し、エージェントに対してオープンで柔軟な開発アプローチを可能にするように設計されています。

カスタムエージェント定義を使用すると、エージェントがアクセスできるツールを正確に選択したり、カスタムシステムプロンプトを埋め込んだり、エージェントの指示を調整したり、セキュリティ境界を定義したりできます。エージェントはモデルに依存しないため、単一のプロバイダーに縛られることなく、ネイティブとより広範なエコシステムの両方で、好みのLLMを柔軟に構成できます。

拡張可能なツールを構築し、ドメイン固有のロジック（例：特定のインデックスフィルター、ES|QL結合、分析パイプライン）をカプセル化し、それらを本番環境での安全な使用に制約します。APIの完全サポートで、モデルコンテキストプロトコル（MCP）のネイティブサポートにより、他のエージェントフレームワークとの相互運用が可能になります。A2A統合とは、Elastic Agentを他のフレームワークやサービス、クライアントアプリに公開し、同じデータやコンテキストエンジニアリングロジックを統合間で再利用できることを意味します。

Agent Builderは、柔軟でオープンな開発をサポートし、一般的なエージェントフレームワークやPlatformと簡単に統合できるように設計されています。これらの統合は効果的なエージェントを提供するために不可欠です。Arcade.devの共同創設者であるSam Partee氏は次のように述べています。

「今日のエージェントシステムが機能しないのは、AIをツールやデータに接続するのが難しいためです。Arcade.devのElastic Agent Builderは、エージェントがコンテキストを取得し、推論し、行動する方法を扱うための構造化されたセキュアな方法を開発者に提供します。」

Agent Builderは、複雑なデータを処理するためにElasticsearchの拡張性も活用します。LlamaIndexのCEOであるJerry Liu氏は次のように述べています。

「非構造化データソースから企業のコンテキストを解き放つことが、効果的なエージェントを構築する鍵となります。Elastic Agent BuilderとLlamaIndexの複雑なドキュメント処理を組み合わせることで、重要なコンテキストレイヤーが強化され、チームがデータを取得、処理、準備できるようになるため、エージェントはより正確に推論し、より良い結果を提供できるようになります。」

構築できるもの

Agent Builderはすでにさまざまなユースケースで使用されています。以下に、エージェントの使用を開始するためのいくつかの例とリファレンスアーキテクチャを示します。

インフラストラクチャーの自動化：サポートシナリオでは、エージェントは読み取り、思考、チャットに使用されてきましたが、これまでは、管理する必要があるインフラストラクチャにアクセスして操作することはできませんでした。Elasticのエンジニアリングチームは、ハッカソンの一環として自動インフラ管理エージェントを構築しました。このエージェントはアプリケーションインフラストラクチャの問題を積極的に調査し、自動アクションを実行します。インフラログをインテリジェントに理解し、ワークフローを使用して構成を最適化し、問題に対応し、リソースを拡張します。
セキュリティ脅威分析：Elastic Agent Builder、MCP、Elasticsearchを使用してセキュリティ脆弱性エージェントが開発されました。内部のセキュリティデータと外部の脅威インテリジェンスを相関させることにより、脅威分析を自動化します。エージェントは過去のインシデントと設定に対してセマンティック検索を実行し、結果をライブインターネットデータで強化し、LLMの推論を適用して環境の関連性を評価し、リスクを優先順位付けし、実行可能な修復策を生成します。リファレンスアーキテクチャを参照してください。
テクニカルカスタマーサポート：エージェントは、ケースの要約、問題の重複排除と作成、詳細な技術調査など、複数のサポートタスクを実行できます。Agent Builderを使用すると、多段階のハイブリッド検索が可能になり、最も関連性の高い問題、ソリューション、手順のみを見つけ、根本原因の仮説と改善計画を策定できます。Agent Builderは複雑なサポートシステムのアーキテクチャを簡素化し、提供までの時間を短縮できます。
製品とコンテンツの検出：Agent Builderは、会話型エクスペリエンスのための複雑な製品カタログを公開するプロセスを簡素化すると同時に、組織が独自のビジネスロジックと要件を組み込む柔軟性を維持できるようにします。
自分で構築：2026年1月22日から2月27日まで開催されるAgent Builder Hackathonに参加しましょう。コミュニティと協力して、検索、ワークフロー、ツール、推論を組み合わせた、コンテキスト駆動型のマルチステップAIエージェントを構築し、実世界のタスクを自動化できます。*

今すぐカスタムエージェントの構築を開始

まずはElastic Cloudトライアルから始めて、こちらのドキュメントをご覧ください。既存のお客様の場合、Agent BuilderはCloud Serverless、Elastic Cloud Hosted、セルフマネージドのエンタープライズティアでご利用いただけます。

* ハッカソンの利用規約と参加資格の詳細についてはこちらをクリックしてください。

Elastic Agent Builderで音声エージェントを構築

Kenneth Kreindler — Thu, 22 Jan 2026 00:00:00 GMT

AIはガラスの箱に閉じ込められています。コマンドを入力すると、テキストで応答が返されます。役には立ちますが、画面の向こうで誰かが動いているのを見ているような距離感があります。今年、2026年は、ビジネスがこのガラスの壁を打ち破り、AIエージェントを製品に導入し、真の価値を提供する年となるでしょう。

ガラスを砕く方法の1つは、人間の音声を認識し、コンピューター生成の音声を合成するAIエージェントである音声エージェントの採用によるものです。低遅延の文字起こし、高速な大規模言語モデル（LLM）、人間のように聞こえるテキスト読み上げモデルの登場により、これが可能になりました。

音声エージェントが真に価値あるものになるためには、ビジネスデータへのアクセスも必要です。このブログでは、音声エージェントの仕組みを学び、LiveKitとElastic Agent Builderを使って、架空のアウトドアスポーツ用品店であるElasticSport向けに音声エージェントを構築します。当社の音声エージェントはコンテキストを認識し、自前のデータを活用します。

プログラム概要

音声エージェントの世界には2つのパラダイムがあります。1つ目は音声合成（speech-to-speech）モデルを使用し、2つ目は音声テキスト変換、LLM、テキスト読み上げからなる音声パイプラインを使用します。音声合成には独自の利点がありますが、音声パイプラインは使用される技術やコンテキストの管理方法、エージェントの動作に対する制御をより柔軟にカスタマイズできます。ここでは音声パイプラインモデルに焦点を当てます。

主要コンポーネント

文字起こし（音声テキスト変換）

文字起こしは音声パイプラインの入口です。文字起こしコンポーネントは、生のオーディオフレームを入力として受け取り、音声をテキストに書き起こして、そのテキストを出力します。文字起こしされたテキストは、システムがユーザーの音声が終了したことを検出するまでバッファリングされます。その時点で、LLM生成が開始されます。さまざまなサードパーティプロバイダーが低遅延の文字起こしを提供しています。選択する際には、遅延と文字起こしの精度を考慮し、ストリーミング文字起こしをサポートしていることを確認してください。

サードパーティAPIの例：AssemblyAI、Deepgram、OpenAI、ElevenLabs

ターン検出

ターン検出は、話者が話し終わり、生成が開始されるべき時を検出するパイプラインのコンポーネントです。これを行う一般的な方法の一つは、Silero VADのような音声アクティビティ検出（VAD）モデルを利用することです。VADは、音声のエネルギーレベルを使用して、音声に発話が含まれるタイミングと発話が終了したタイミングを検出します。しかし、VADだけでは、一時停止と発話の終了の違いを識別することはできません。このため、中間トランスクリプトまたは生の音声に基づいて話者が話し終えたかどうかを予測する発話終了モデルと組み合わせられることがよくあります。

例 (Hugging Face): livekit/turn-detector, pipecat-ai/smart-turn-v3

エージェント

エージェントは音声パイプラインのコアです。意図を理解し、適切なコンテキストを収集し、テキスト形式で返信を作成する役割を担います。Elastic Agent Builderは、組み込まれた推論機能、ツールライブラリ、ワークフロー統合により、データ上で動作し、外部サービスとやり取りできるエージェントとなります。

LLM（テキストからテキスト）

Elastic Agent Builder用のLLMを選択する際には、主に、LLMの推論ベンチマークと、最初のトークンまでの時間（TTFT）の2つの特性を考慮する必要があります。

推論ベンチマークは、LLMがどの程度正しい応答を生成できるかを示します。検討すべきベンチマークは、MT-BenchやHumanity's Last Examデータセットなど、マルチターン会話の遵守とインテリジェンスベンチマークを評価するものです。

TTFTベンチマークは、モデルが最初の出力トークンを生成する速度を評価します。レイテンシのベンチマークには他にも種類がありますが、TTFTは音声エージェントにとって特に重要です。最初のトークンを受信するとすぐにオーディオ合成を開始できるため、ターン間のレイテンシが短縮され、自然な会話が実現します。

通常、高速モデルは推論ベンチマークでパフォーマンスが低下することが多いため、これら2つの特性は互いにトレードオフとなります。

例 (Hugging Face): openai/gpt-oss-20b, openai/gpt-oss-120b

合成（テキスト読み上げ）

パイプラインの最後の部分はテキスト読み上げモデルです。このコンポーネントは、LLMから出力されたテキストを可聴音声に変換する役割を担います。LLMと同様に、遅延はテキスト読み上げプロバイダーを選択する際に注意すべき特性です。テキスト読み上げの遅延は、最初のバイトまでの時間（TTFB）で測定されます。これは、最初のオーディオバイトが受信されるまでにかかる時間です。TTFBが低いほど、ターンの待ち時間も短縮されます。

例：ElevenLabs、Cartesia、Rime

音声パイプラインの構築

Elastic Agent Builderは、音声パイプラインに複数のレベルで統合できます。

Agent Builderツールのみ：音声テキスト変換 → LLM（Agent Builderツール使用）→ テキスト読み上げ
MCPとしてのAgent Builder：音声テキスト変換 → LLM（MCP 経由でAgent Builderにアクセス）→ テキスト読み上げ
Agent Builderをコアとして使用：音声テキスト変換 → Agent Builder →テキスト読み上げ

このプロジェクトでは、コアアプローチとしてAgent Builderを選択しました。このアプローチにより、Agent Builderとワークフローの全機能を使用できます。このプロジェクトでは、LiveKitを使用して音声テキスト変換、ターン検出、テキスト読み上げを管理する、Agent Builderと直接統合するカスタムLLMノードを実装しています。

Elasticサポート音声エージェント

ElasticSportという架空のスポーツショップ向けにカスタムサポート音声エージェントを構築します。顧客はヘルプラインに電話をかけ、製品の推奨を尋ねたり、製品の詳細を見つけたり、注文状況を確認したり、注文情報をテキストで送信してもらったりできるようになります。これを達成するために、まずカスタムエージェントを設定し、Elasticsearch Query Language（ES|QL）クエリとワークフローを実行するためのツールを作成する必要があります。

エージェントの構成

プロンプト

プロンプトは、エージェントがどのような性格を持ち、どのように応答するかを指示します。重要なのは、応答が適切に音声に合成され、誤解が適切に修復されることを保証する音声固有のプロンプトがいくつかあることです。

You are a Sales Assistant at ElasticSport, an outdoor sport shop specialized in hiking and winter equipment. [Profile] - name: Iva - company: ElasticSport - role: Sales Assistant - language: en-GB - description: ElasticSport virtual sales assistant [Context] - Ask clarifying questions to understand the context. - Use available tools to answer the user's question. - Use the knowledge base to retrieve general information [Style] - Be informative and comprehensive. - Maintain a professional, friendly and polite tone. - Mimic human behavior and speech patterns. - Be concise. Do not over explain initially [Response Guideline] - Present dates in spelled-out month date format (e.g., January fifteenth, two thousand and twenty-four). - Avoid the use of unpronounceable punctuation such as bullet points, tables, emojis. - Respond in plain text, avoid any formatting. - Spell out numbers as words for more natural-sounding speech. - Respond in short and concise sentences. Responses should be 1 or 2 sentences long. [ERROR RECOVERY] ### Misunderstanding Protocol 1. Acknowledge potential misunderstanding 2. Request specific clarification

ワークフロー

TwilioのメッセージングAPIを介してSMSを送信するための小さなワークフローを追加します。ワークフローはカスタムエージェントに対してツールとして公開され、エージェントが通話中に発信者にSMSを送信できるユーザーエクスペリエンスが実現されます。これにより、発信者は、「 Xについての詳細をテキストで送信できますか？」などと尋ねることができます。

name: send sms enabled: true triggers: - type: manual inputs: - name: message type: string description: The message to send to the phone number. - name: phone_number type: string description: The phone number to send the message to. consts: TWILIO_ACCOUNT: "****" BASIC_AUTH: "****" FROM_PHONE_NNUMBER: "****" steps: - name: http_step type: http with: url: https://api.twilio.com/2010-04-01/Accounts/{{consts.TWILIO_ACCOUNT}}/Messages.json method: POST headers: Content-Type: application/x-www-form-urlencoded Authorization: Basic {{consts.BASIC_AUTH | base64_encode}} body: From={{consts.FROM_PHONE_NNUMBER}}&To={{inputs.phone_number}}&Body={{inputs.message}} timeout: 30s

ES|QLツール

次のツールを使用すると、エージェントは実際のデータに基づいた適切な応答を提供できます。サンプルリポジトリには、製品、注文、ナレッジベースのデータセットでKibanaを初期化するためのセットアップスクリプトが含まれています。

Product.search

製品データセットには65種類の架空の製品が含まれています。これはサンプルドキュメントです。

{ "sku": "ort3M7k", "name": "Ortovox Free Rider 26 Backpack", "price": 189, "currency": "USD", "image": "https://via.placeholder.com/150", "description": "The Ortovox Free Rider 26 is a technical freeride backpack with a dedicated safety compartment and diagonal ski carry system. Perfect for backcountry missions.\n\nKey Features:\n- 26L capacity\n- Diagonal ski carry system\n- Safety equipment compartment\n- Helmet holder\n- Hydration system compatible", "category": "Accessories", "subCategory": "Backpacks", "brand": "Ortovox", "sizes": ["One Size"], "colors": ["Black", "Blue", "Orange"], "materials": ["Nylon", "Polyester"] }

名前と説明のフィールドは semantic_textとしてマップされており、LLMがES|QLを介してセマンティック検索を実行して関連製品を取得できるようになっています。ハイブリッド検索クエリは、両方のフィールド間でセマンティックマッチングを実行し、ブーストを使用して名前フィールドの一致によりわずかに高い重みを適用します。

クエリはまず、初期関連性スコアでランク付けされた上位20件の結果を取得します。これらの結果は、.rerank-v1-elasticsearch 推論モデルを使用して説明フィールドに基づいて再ランク付けされ、最後に最も関連性の高い上位 5 つの製品に絞り込まれます。

type: ES|QL toolId: products.search description: Use this tool to search through the product catalogue by keywords. query: | FROM products METADATA _score | WHERE MATCH(name, ?query, {"boost": 0.6}) OR MATCH(description, ?query, {"boost": 0.4}) | SORT _score DESC | LIMIT 20 | RERANK ?query ON description WITH {"inference_id": ".rerank-v1-elasticsearch"} | LIMIT 5 parameters: query: space separated keywords to search for in catalogue

Knowledgebase.search

ナレッジベースのデータセットには、以下の形式のドキュメントが含まれており、タイトルとコンテンツのフィールドはセマンティックテキストとして格納されます。

{ id: "8273645", createdAt: "2025-11-14", title: "International Orders", content: `International orders are processed through our international shipping partner. Below are the countries we ship to and average delivery times. Germany: 3-5 working days France: 3-5 working days Italy: 3-5 working days Spain: 3-5 working days United Kingdom: 3-5 working days United States: 3-5 working days Canada: 3-5 working days Australia: 3-5 working days New Zealand: 3-5 working days ` }

このツールは、 product.searchツールと同様のクエリを使用します。

type: "ES|QL" toolId: knowledgebase.search description: Use this tool to search the knowledgebase. query: | FROM knowledge_base METADATA _score | WHERE MATCH(title, ?query, {"boost": 0.6}) OR MATCH(content, ?query, {"boost": 0.4}) | SORT _score DESC | LIMIT 20 | RERANK ?query ON content WITH {"inference_id": ".rerank-v1-elasticsearch"} | LIMIT 5 parameters: query: space separated keywords or natural language phrase to semantically search for in the knowledge base

Orders.search

最後に追加するツールは、 order_idによる注文を取得するために使用されるツールです。

エージェントを設定し、これらのワークフローとES|QLツールをエージェントにアタッチした後、エージェントはKibana内でテストできます。

ElasticSportサポートエージェントの構築以外にも、エージェント、ワークフロー、ツールを、リード資格を審査する営業エージェント、住宅修理のサービスエージェント、レストランの予約、予約スケジュールエージェントなど、他のユースケースに合わせてカスタマイズできます。

最後の部分は、先ほど作成したエージェントをLiveKit、テキスト読み上げ、音声テキスト変換モデルと連携することです。このブログの最後にリンクされているリポジトリには、LiveKitで使用できるカスタムElastic Agent Builder LLMノードが含まれています。AGENT_IDを独自のものに置き換えて、Kibanaインスタンスにリンクするだけです。

はじめに

ここでコードをチェックして試してみてください。

Elasticsearchによるエージェントメモリの管理

Someshwaran Mohankumar — Fri, 16 Jan 2026 00:00:00 GMT

新興の分野であるコンテキストエンジニアリングでは、AIエージェントに適切なタイミングで適切な情報を提供することが極めて重要です。コンテキストエンジニアリングの最も重要な側面の1つは、AIのメモリを管理することです。人間と同じように、AIシステムは情報を思い出すために短期記憶と長期記憶の両方に依存しています。大規模言語モデル（LLM）エージェントに論理的な会話をさせたり、ユーザーの好みを覚えたり、以前の結果や対応に基づいて構築させたりしたい場合は、効果的な記憶メカニズムをエージェントに装備する必要があります。

結局のところ、コンテキスト内のすべてがAIの応答に影響を与えます。「ゴミを入れたらゴミが出てくる」は真実です。

この記事では、AIエージェントにとって短期記憶と長期記憶が何を意味するのか、具体的に紹介します。

短期記憶と長期記憶の違い。
Elasticsearchのようなベクトルデータベースを使用したRetrieval-Augmented Generation（RAG）手法との関係、そして慎重なメモリ管理が必要な理由。
コンテキストオーバーフローやコンテキストポイズニングなど、メモリを軽視することによるリスク。
エージェントのメモリを有用かつ安全に保つベストプラクティス（コンテキストのプルーニング、要約、関連するもののみの取得など）
最後に、Elasticsearchを使用してエージェントが混乱することなく協力できるように、マルチエージェントシステムでメモリを共有および伝播する方法について説明します。

AIエージェントにおける短期記憶と長期記憶の違い

AIエージェントの短期記憶は通常、直前の会話のコンテキストや状態を指します。本質的には、アクティブなセッションにおける現在のチャット履歴や最近のメッセージです。ユーザーの最新のクエリと最近のやり取りが含まれ、人が会話中に心に留めている情報と非常に似ています。

AIフレームワークは、エージェントの状態の一部としてこの一時的なメモリを保持することがよくあります（例えば、LangGraphのこの例のように、会話の状態を格納するためにチェックポインタを使用します）。短期記憶はセッション範囲に限定されます。つまり、短期記憶は単一の会話またはタスク内に存在し、明示的に他の場所に保存されない限り、そのセッションが終了するとリセットまたはクリアされます。セッションに縛られた短期記憶の例としては、ChatGPTで利用可能な一時的なチャットが挙げられます。

一方、長期記憶とは、会話やセッションを超えて持続する情報を指します。これは、エージェントが長期にわたって保持する知識、以前に学習した事実、ユーザーの選好、または永続的に覚えておくように指示されたデータです。

長期記憶は通常、ファイルやベクトルデータベースなどの即時コンテキストウィンドウの外部にある外部ソースに格納・取得することで実装されます。短期的なチャット履歴とは異なり、長期記憶はすべてのプロンプトに自動的に含まれるわけではありません。代わりに、特定のシナリオに基づいて、エージェントは関連するツールが呼び出されたときにそれを想起したり取得したりする必要があります。実際には、長期記憶にはユーザーのプロフィール情報、エージェントが生成した過去の回答や分析、またはエージェントがクエリを実行できるナレッジベースが含まれる可能性があります。

例えば、旅行プランナーエージェントの場合、短期メモリには現在の旅行の問い合わせの詳細（日付、目的地、予算）とそのチャットでのフォローアップの質問が格納され、長期メモリにはユーザーの一般的な旅行の好み、過去の旅程、および以前のセッションで共有されたその他の事実が格納されます。ユーザーが後で戻ってきたときに、エージェントはこの長期格納場所から情報を引き出すことができます（そのユーザーはビーチや山が好きで、平均予算はINR 100,000で、行きたい場所のリストがあり、子供向けのアトラクションよりも歴史や文化を体験することを好むなど）。そのため、エージェントは毎回ユーザーを白紙の状態として扱うことはありません。

短期記憶（チャット履歴）は即時のコンテキストと継続性を提供し、長期記憶はエージェントが必要なときに利用できるより広範なコンテキストを提供します。ほとんどの先進的なAIエージェントフレームワークは、その両方を可能にします。コンテキストを保守するために最近の対話を追跡し、かつより長期的なリポジトリに情報を検索または格納するメカニズムを提供します。短期記憶を管理することで、コンテキストウィンドウ内に留まることを確保し、長期記憶を管理することで、エージェントは過去のやり取りやペルソナに基づいて回答を裏付けることができます。

コンテキストエンジニアリングにおけるメモリとRAG

実際にAIエージェントに有用な長期記憶を与えるにはどうすればよいでしょうか？

長期記憶のための一つの顕著なアプローチはセマンティック記憶であり、しばしば検索拡張生成（RAG）を介して実装されます。これには、LLMを外部のナレッジストアやElasticsearchなどのベクトル対応データストアと結合することが含まれます。LLMは、プロンプトや組み込みのトレーニングの内容以外の情報を必要とする場合、Elasticsearchに対してセマンティック検索を実行し、最も関連性の高い結果をコンテキストとしてプロンプトに注入します。このように、モデルの効果的なコンテキストには、最近の会話（短期記憶）だけでなく、その場で得られた関連する長期的事実も含まれます。その後、LLMは、独自の推論と取得した情報の両方に基づいて回答を決定し、短期記憶と長期記憶を効果的に組み合わせて、より正確でコンテキストを意識した応答を生成します。

ElasticsearchはAIエージェントの長期記憶実装にも利用できます。長期記憶のためにElasticsearchからコンテキストを取得する方法の高次的な例を示します。

このように、エージェントはさまざまなリスクにつながる限られたプロンプト内にすべてを格納するのではなく、関連するデータを検索することによって「思い出し」ます。

RAGをElasticsearchや任意のベクトルストアで使用することで、多くの利点が得られます。

第一に、モデルのトレーニングのカットオフを超えて知識を拡張できます。エージェントは、LLMが知らない可能性のある最新の情報やドメイン固有のデータを取得できます。これは最近の出来事や専門的なトピックに関する質問に非常に重要です。

第二に、オンデマンドでコンテキストを取得することで、ハルシネーションを減らすことができます。特に、LLMはニッチなユースケースに関連する独自データや高度に専門化されたデータでトレーニングされていないため、ハルシネーションが発生する可能性が非常に高いです。LLMが評価によって推測や新しい情報を作り出すのではなく、最近のOpenAIの論文（Why Language Models Hallucinate）で指摘されているように、このモデルはElasticsearchの事実に基づく参照に基づいています。当然ながら、LLMはベクトルストアのデータの信頼性に依存しており、誤情報を確実に防御するために、コアの関連性指標に基づいて関連データが取得されます。

第三に、RAGを使用すると、エージェントはプロンプトに収めることができるものよりもはるかに大きなナレッジベースを扱うことができます。長い研究論文や政策文書のように、文書全体をコンテキストウィンドウに押し込んで過剰負荷や無関係な情報コンテキストがモデルの推論を損なうコンテキストポイズニングを招くことなく、RAGはチャンク化に依存します。大きな文書は意味的に意味のある小さな部分に分割され、システムはクエリに最も関連性の高い少数のチャンクのみを取得します。この方法では、モデルが知識豊富であることを示すために100万トークンのコンテキストを必要とせず、はるかに大規模なコーパスの適切なチャンクにアクセスするだけで済みます。

注目すべきは、LLMのコンテキストウィンドウが拡大し（一部のモデルは現在、数十万または数百万のトークンをサポート）、RAGの「終焉」についての議論が起きたことです。なぜすべてのデータをプロンプトに押し込まないのでしょうか。同じようにお考えなら、同僚のJeffrey RengifoとEduard Martinによるこの素晴らしい記事「コンテキストは長ければよいわけではない：RAGが引き続き重要な理由」を参照してください。これにより、「ゴミを入れればゴミが出てくる」問題を回避できます。LLMは、ノイズを処理するのではなく、重要な少数のチャンクに焦点を合わせ続けます。

とはいえ、Elasticsearchやその他のベクトルストアをAIエージェントのアーキテクチャに統合することで、長期記憶が可能になります。エージェントは知識を外部に格納し、必要に応じてメモリコンテキストとして取り込みます。これは、各ユーザークエリの後、エージェントがElasticsearchで関連情報を検索し、LLMを呼び出す前にプロンプトに上位の結果を追加するアーキテクチャとして実装することができます。応答に新しい有用な情報が含まれている場合、その応答は長期保存されることもあります（学習のフィードバックループが作成されます）。そのような検索ベースのメモリを使用することで、エージェントは、コンテキストウィンドウが100万トークンをサポートしている場合であっても、常に情報を得て最新の状態を保ちながら、すべての知識をすべてのプロンプトに詰め込む必要がなくなります。この技術は、情報検索と生成AIの強みを組み合わせたコンテキストエンジニアリングの基礎となるものです。

これは、セッション中の短期記憶にLangGraphのチェックポイントシステムを使用して管理されたメモリ内会話状態の例です。（当社のコンテキストエンジニアリングをサポートするアプリを参照してください。）

# Initialize chat memory (Note: This is in-memory only, not persistent) memory = MemorySaver() # Create a LangGraph agent langgraph_agent = create_react_agent(model=llm, tools=tools, checkpointer=memory) ... ... # Only process and display checkpoints if verbose mode is enabled if args.verbose: # List all checkpoints that match a given configuration checkpoints = memory.list({"configurable": {"thread_id": "1"}}) # Process the checkpoints process_checkpoints(checkpoints)

checkpointの格納方法は以下の通りです。

Checkpoint: Timestamp: 2025-12-30T09:19:41.691087+00:00 Checkpoint ID: 1f0e560a-c2fa-69ec-8001-14ee5373f9cf User: Hi I'm Som, how are you? (Message ID: ad0a8415-5392-4a58-85ad-84154875bbf2) Agent: Hi Som! I'm doing well, thank you! How about you? (Message ID: 56d31efb-14e3-4148-806e-24a839799ece) Agent: (Message ID: lc_run--019b6e8e-553f-7b52-8796-a8b1fbb206a4-0) Checkpoint: Timestamp: 2025-12-30T09:19:40.350507+00:00 Checkpoint ID: 1f0e560a-b631-6a08-8000-7796d108109a User: Hi I'm Som, how are you? (Message ID: ad0a8415-5392-4a58-85ad-84154875bbf2) Agent: Hi Som! I'm doing well, thank you! How about you? (Message ID: 56d31efb-14e3-4148-806e-24a839799ece) Checkpoint: Timestamp: 2025-12-30T09:19:40.349027+00:00 Checkpoint ID: 1f0e560a-b62e-6010-bfff-cbebe1d865f6

長期記憶については、Elasticsearchでセマンティック検索を実行し、チェックポイントを要約して Elasticsearchにインデックス付けした後、ベクトル埋め込みを使用して関連する以前の会話を取得する方法を次に示します。

Functions: retrieve_from_elasticsearch() # Enhanced Elasticsearch retrieval with rank_window and verbose display def retrieve_from_elasticsearch(query: str, k: int = 5, rank_window: int = None) -> tuple[List[Dict[str, Any]], str]: """ Retrieve context from Elasticsearch with score-based ranking Args: query: Search query k: Number of results to return rank_window: Number of candidates to retrieve before ranking (default: args.rank_window) Returns: Tuple of (retrieved_documents, formatted_context_string) """ if not es_client or not es_index_name: return [], "Elasticsearch is not available. Cannot search long-term memory." if rank_window is None: rank_window = args.rank_window try: # Check if index exists and has documents if not es_client.indices.exists(index=es_index_name): return [], "No previous conversations stored in long-term memory yet." # Get document count try: doc_count = es_client.count(index=es_index_name)["count"] if doc_count == 0: return [], "Long-term memory is empty. No previous conversations to search." except Exception as e: return [], f"Error checking memory: {str(e)}" # Generate embedding for the query try: query_embedding = embeddings.embed_query(query) except Exception as e: return [], f"Error generating embedding: {str(e)}" # Perform semantic search using kNN with rank_window try: search_body = { "knn": { "field": "vector", "query_vector": query_embedding, "k": k, "num_candidates": rank_window # Retrieve more candidates, then rank top k }, "_source": ["text", "content", "message_type", "timestamp", "thread_id"], "size": k } response = es_client.search(index=es_index_name, body=search_body) if not response.get("hits") or len(response["hits"]["hits"]) == 0: return [], "No relevant previous conversations found in long-term memory." # Extract documents with scores retrieved_docs = [] for hit in response["hits"]["hits"]: source = hit["_source"] score = hit["_score"] retrieved_docs.append({ "content": source.get("content", source.get("text", "")), "message_type": source.get("message_type", "unknown"), "timestamp": source.get("timestamp", "unknown"), "thread_id": source.get("thread_id", "unknown"), "score": score }) # Format context string context_parts = [] for i, doc in enumerate(retrieved_docs, 1): context_parts.append(doc["content"]) context_string = "\n\n".join(context_parts) # Verbose display if args.verbose: rich.print(f"\n[bold yellow]🔍 RETRIEVAL ANALYSIS[/bold yellow]") rich.print("="*80) rich.print(f"[blue]Query:[/blue] {query}") rich.print(f"[blue]Retrieved:[/blue] {len(retrieved_docs)} documents (from {rank_window} candidates)") rich.print(f"[blue]Total context length:[/blue] {len(context_string)} characters\n") for i, doc in enumerate(retrieved_docs, 1): rich.print(f"[cyan]📄 Document {i} | Score: {doc['score']:.4f} | Type: {doc['message_type']}[/cyan]") rich.print(f"[cyan] Timestamp: {doc['timestamp']} | Thread: {doc['thread_id']}[/cyan]") content_preview = doc['content'][:200] + "..." if len(doc['content']) > 200 else doc['content'] rich.print(f"[cyan] Content: {content_preview}[/cyan]") rich.print("-" * 80) return retrieved_docs, context_string except Exception as e: return [], f"Error searching memory: {str(e)}" except Exception as e: return [], f"Error accessing long-term memory: {str(e)}"

ElasticsearchのLangGraphのチェックポイントを使用して、短期記憶と長期記憶がどのようにインデックス化され、取得されるかを調べてきました。さて、少し時間を取って、会話全体をインデキシングしてダンプすることがなぜ危険なのかを理解しましょう。

コンテキストメモリを管理しないことのリスク

コンテキストエンジニアリング、短期記憶、長期記憶について詳しく説明しているので、エージェントのメモリとコンテキストを適切に管理しないと何が起こるかを理解しましょう。

残念ながら、AIのコンテキストが非常に長くなったり、悪い情報が含まれたりすると、多くの問題が発生する可能性があります。コンテキストウィンドウが大きくなるにつれて、次のような新しい障害モードが発生します。

コンテキストポイズニング
コンテキストの逸脱
コンテキストの混乱
コンテキストの衝突
コンテキスト漏洩と知識対立
ハルシネーションと誤情報

これらの問題や、不適切なコンテキスト管理から生じるその他のリスクを分解して見ていきましょう。

コンテキストポイズニング

コンテキストポイズニングとは、不正確または有害な情報がコンテキストに入り込み、モデルのその後の出力を「汚染」してしまうことを指します。よくある例としては、モデルによるハルシネーションが事実として扱われ、会話履歴に挿入されることがあります。モデルはその後、そのエラーを元に対応を構築し、誤りを複合化させることがあります。反復的なエージェントループでは、共有コンテキスト（エージェントの作業メモの要約など）に誤った情報が入ると、その情報が何度も強化されることがあります。

DeepMindの研究者は、Gemini 2.5レポート（概略はここをチェック）のリリース時に長年ポケモンをプレイしているエージェントでこれを観察しました。エージェントが間違ったゲーム状態のハルシネーションを起こし、それがそのコンテキスト（ゴールの記憶）に記録された場合、エージェントは不可能な目標に関する無意味な戦略を立て、行き詰まってしまいます。言い換えれば、汚染された記憶はエージェントを永久に誤った道へと導く可能性があるのです。

コンテキストポイズニングは、無意識のうちに（誤って）発生する可能性があるだけでなく、悪意を伴ってを発生する可能性もあります。例えば、プロンプトインジェクション攻撃では、ユーザーや第三者が隠れた指示や虚偽の事実を忍び込ませ、エージェントがそれを記憶し、従うようにします。

推奨される対策：

Wiz、Zerlo、Anthropicからの洞察に基づき、コンテキストポイズニングの対策は、LLMのプロンプト、コンテキストウィンドウ、検索パイプラインに悪い情報や誤解を招く情報が入らないようにすることに重点を置いています。主な手順は次のとおりです。

常にコンテキストを確認する：開始プロンプトだけでなく、不審な点や有害な点がないか、会話や検索されたテキストを監視します。
信頼できるソースを使用する：信頼性に基づいて文書にスコアを付けたりラベルを付けたりすることで、システムは信頼性の高い情報を優先し、スコアの低いデータを無視します。
異常なデータを見つける：奇妙なもの、場違いなもの、または操作されたコンテンツを検出するツールを使用し、モデルが使用する前に削除します。
入力と出力をフィルターする: 有害または誤解を招くテキストがシステムに簡単に入力されたり、モデルによって繰り返されたりしないようにガードレールを追加します。
モデルをクリーンなデータで最新の状態に保つ：検証済みの情報で定期的にシステムを更新して、流出してしまった不良データに対処します。
人間が関与する：重要な出力を人間が確認したり、既知の信頼できるソースと比較したりします。

長いチャットをリセットし、関連情報のみを共有し、複雑なタスクを小さなステップに分割し、モデル外で明確なメモを維持するなど、使用時のシンプルな習慣も役立ちます。

これらの対策を組み合わせることで、コンテキストポイズニングからLLMを保護し、出力の正確性と信頼性を維持する階層化された防御が実現します。

ここに記載されている対策を講じないと、エージェントは以前のガイドラインや攻撃者が挿入した些細な事実を無視するなどの指示を覚えてしまい、有害な出力につながることがあります。

コンテキストの逸脱

コンテキストの逸脱とは、コンテキストが長くなりすぎて、モデルがコンテキストに過度に集中し、トレーニング中に学習した内容を無視してしまうことです。極端な場合、これは壊滅的な忘却のようになります。この場合、モデルは基本的な知識を「忘れ」、目の前にある情報に過度に依存するようになります。過去の研究では、プロンプトが非常に長いとLLMが焦点を失うことが多いことが示されています。

例えば、Gemini 2.5エージェントは100万トークンのウィンドウをサポートしていましたが、そのコンテキストが特定のポイント（実験では約10万トークン）を超えると、新しいソリューションを思いつく代わりに、過去の行動を繰り返すことに固執し始めました。ある意味、エージェントはその長い歴史の囚人となったのです。基礎となるトレーニング知識を活用して斬新な戦略を考案するのではなく、以前の動作の長いログ（コンテキスト）を見てそれを真似し続けました。

これでは逆効果です。私たちは、モデルが思考能力を無効にするのではなく、推論を助けるために関連コンテキストを使用することを望んでいます。注目すべきは、巨大なウィンドウを持つモデルでさえ、トークンが追加されるにつれて、パフォーマンスが不均一に低下するというコンテキスト腐敗を示すことです。ここには注意予算が見られるようです。つまり、人間の作業記憶が限られているように、LLMがトークンに注意を払う能力も有限であり、その予算が限界に達すると、その精度と焦点が低下します。

緩和策として、チャンキング、適切な情報のエンジニアリング、定期的なコンテキストの要約、応答の正確性を測定するための評価とモニタリング技術を使用して、コンテキストの逸脱を防止できます。

これらの方法により、モデルは関連するコンテキストとその基礎となるトレーニングの両方に基盤を置くようになり、逸脱のリスクが軽減され、全体的な推論品質が向上します。

コンテキストの混乱

コンテキストの混乱とは、コンテキスト内の余分なコンテンツがモデルによって使用され、低品質の対応が生成されることです。代表的な例としては、エージェントが使用する可能性のある大量のツールやAPI定義をエージェントに提供することが挙げられます。それらのツールの多くが現在のタスクと無関係であっても、モデルはコンテキスト内に存在するという理由だけで、それらを不適切に使用しようとする可能性があります。実験によると、必要でないツールやドキュメントを多く提供すると、パフォーマンスが低下することがわかっています。エージェントは、間違った関数を呼び出したり、無関係なテキストを参照したりするなどの間違いを犯し始めます。

あるケースでは、小型のLlama 3.1 8Bモデルは、検討すべきツールが46個与えられたときにはタスクに失敗しましたが、19個のツールしか与えられなかったときには成功しました。コンテキストが長さ制限内であったにもかかわらず、追加のツールによって混乱が生じました。根本的な問題は、プロンプト内のすべての情報がモデルに処理されることです。何かを無視するべきことを認識していない場合、その何かが望ましくない方法で出力に影響を及ぼす可能性があります。無関係な部分がモデルの注意の一部を「奪い」、誤った方向に導くことがあります（無関係な文書によってエージェントが尋ねられた質問とは異なる質問に答えるなど）。コンテキストの混乱は、しばしばモデルが無関係なコンテキストを統合した低品質の応答を生成することとして現れます。研究論文「Less is More: Optimizing Function Calling for LLM Execution on Edge Devices.」を参照してください。

これは、特に関連性を重視して厳選されていない場合、コンテキストが多ければ多いほど良いとは限らないことを想起させます。

コンテキストの衝突

コンテキストの衝突は、コンテキストの部分が互いに矛盾し、モデルの推論を脱線させる内部不整合が発生するときに起こります。エージェントが矛盾する複数の情報を蓄積すると、衝突が発生することがあります。

例えば、あるエージェントが2つのソースからデータを取得したとします。1つは午後5時にA便が出発するというもので、もう1つは午後6時にA便が出発するというものです。両方の事実がコンテキスト内に存在する場合、貧弱なモデルではどちらが正しいのかを判断できず、混乱したり、不正確な回答や類似しない回答を生成したりする可能性があります。

コンテキストの衝突は、モデルの過去の回答の試みが、その後の洗練された情報とともにコンテキスト内に残っている、マルチターンの会話でも頻繁に発生します。

MicrosoftとSalesforceの研究によると、複雑なクエリを複数のチャットボットターンに分割して詳細を徐々に追加すると、単一のプロンプトですべての詳細を伝える場合と比べて、最終的な精度が大幅に低下することが示されています。なぜでしょうか。初期のターンにモデルからの部分的なまたは不正確な中間回答が含まれており、それらはコンテキスト内に残るためです。モデルが後ですべての情報を使用して回答しようとすると、そのメモリにはまだそれらの誤った試行が含まれており、修正された情報と矛盾して軌道から外れてしまいます。本質的に、会話のコンテキストが自己衝突しているのです。このモデルは、新しい情報が追加された後には適用されない古いコンテキスト（以前のターンからの）を誤って使用してしまう可能性があります。

エージェントが異なるツールやサブエージェントからの出力を組み合わせる可能性があるエージェントシステムでは、コンテキストの衝突は特に危険です。これらの出力が一致しない場合、集約された文脈は一貫性がありません。すると、エージェントは行き詰まったり、矛盾を調整しようとして無意味な結果を生成する可能性があります。コンテキストの衝突を防ぐには、コンテキストが新鮮で一貫していること、例えば、古い情報をクリアまたは更新し、一貫性がないソースを混ぜないことが重要です。

コンテキスト漏洩と知識対立

システムで複数のエージェントやユーザーがメモリストアを共有する場合、コンテキスト間で情報が漏れるリスクがあります。

例えば、適切なアクセス制御がないまま、2人の異なるユーザーのデータ埋め込みが同じベクトルデータベースに存在する場合、ユーザーAのクエリに応答するエージェントが、誤ってユーザーBのメモリの一部を取得する可能性があります。この クロスコンテキスト漏洩 は、個人情報を漏洩させたり、対応に混乱を生じさせたりする可能性があります。

OWASP Top 10 for LLM Applicationsによれば、マルチテナントベクトルデータベースは次のような漏洩を防ぐ必要があります。

LLM08:2025 Vector and Embedding Weaknessesによると、一般的なリスクの1つはコンテキストの漏洩です。

マルチテナント環境では、複数のクラスのユーザーやアプリケーションが同じベクトルデータベースを共有するため、ユーザーやクエリ間でコンテキストが漏洩するリスクがあります。データフェデレーション知識の矛盾エラーは、複数のソースからのデータが矛盾し合う場合に発生します。これは、LLMがトレーニング中に学習した古い知識を検索拡張からの新しいデータで置き換えることができない場合にも発生する可能性があります。

もう一つの側面は、LLMがメモリからの新しい情報で組み込まれた知識を上書きするのに苦労する可能性があることです。モデルが何らかの事実に基づいてトレーニングされていて、取得したコンテキストが逆の場合、モデルはどちらを信頼すべきか混乱する可能性があります。適切な設計がないと、エージェントがコンテキストを混同したり、古い知識を新しい証拠で更新できなかったりして、古くなった回答や間違った回答につながる可能性があります。

ハルシネーションと誤情報

ハルシネーション（LLM がもっともらしく聞こえるが誤った情報を生成すること）は、コンテキストが長くなくても既知の問題ですが、メモリ管理が不十分だと増幅される可能性があります。

エージェントのメモリに重要な事実が欠けている場合、モデルは単にその空白を推測で埋める可能性があり、その推測がコンテキストに入り込む（汚染）と、エラーが持続します。

OWASPのLLMセキュリティレポート（LLM09:2025 Misinformation）では、誤情報が主な脆弱性として強調されています。LLMは自信を持って虚偽の回答を生成する可能性があり、ユーザーはそれらを過度に信頼する可能性があります。長期記憶が不良または古くなっているエージェントは、その記憶が最新の状態に保たれていない限り、昨年は真実であったが現在は間違っていることを自信を持って引用する可能性があります。

（ループ内のユーザーまたはエージェント自体による）AIの出力への過度の依存は、この問題を悪化させる可能性があります。誰もメモリの情報を確認しなければ、エージェントは虚偽を蓄積してしまう可能性があります。RAGがハルシネーションを抑えるためによく使われるのはこのためです。信頼できる情報源を検索することで、モデルは事実を捏造する必要がなくなります。しかし、検索によって間違った文書（誤った情報が含まれている文書など）が取得されたり、初期のハルシネーションが除去されなかったりすると、システムはその誤った情報をその動作全体に伝播してしまう可能性があります。

肝心なことは、メモリの管理に失敗すると、不正確で誤解を招く出力につながる可能性があり、特にリスクが高い場合（金融や医療分野での誤ったアドバイスなど）には損害を与える可能性があります。エージェントには、コンテキスト内のあらゆるものを無条件に信頼するだけでなく、メモリの内容を検証または修正するためのメカニズムが必要です。

まとめると、成功の秘訣は、AIエージェントに無限に長いメモリを与えたり、ありとあらゆるものをそのコンテキストに放り込んだりすることではありません。

LLMアプリケーションにおけるメモリ管理のベストプラクティス

上記の陥穽を避けるために、開発者と研究者はAIシステムでコンテキストとメモリを管理するためのベストプラクティスをいくつか考案しました。これらのプラクティスは、AIの動作コンテキストを無駄なく、関連性があり、最新の状態に保つことを目的としています。ここでは、いくつかの重要な戦略と、それがどのように役立つかの例を示します。

RAG：ターゲットを絞ったコンテキストを使用する

RAGの大部分についてはすでに前のセクションで説明しましたので、このセクションは実用的な注意事項を簡潔にまとめたものです。

ターゲットを絞った検索を使用し、一括読み込みは避ける：全文書や会話の履歴全体をプロンプトにプッシュするのではなく、最も関連性の高い部分のみを取得します。
RAGをジャストインタイムのメモリ呼び出しとして扱う：ターンを超えてすべてを転送するのではなく、必要なときにのみコンテキストを取得します。
関連性に注意した検索戦略を優先する：トップkセマンティック検索、逆順位融合、ツールロードアウトフィルタリングなどのアプローチは、ノイズを減らし、グラウンディングを改善するのに役立ちます。
コンテキストウィンドウが大きくなってもRAGは必要：2つの非常に関連性の高い段落は、20の緩く関連したページよりもほとんど常に効果的です。

つまり、RAGではコンテキストを増やすことではなく、適切なコンテキストを追加することが重要なのです。

ツールのロードアウト

ツールのロードアウトとは、モデルにタスクに実際に必要なツールのみを与えることです。この用語はゲームに由来し、状況に合った装備を選ぶというものです。ツールが多すぎると作業が遅くなり、間違ったツールを使用すると失敗の原因になります。研究論文「Less is more」によると、LLMも同様に動作します。ツールが30個を超えると、説明が重複し始め、モデルが混乱します。ツールの数が約100個を超えると、失敗はほぼ確実です。これはコンテキストウィンドウの問題ではなく、コンテキストの混乱です。

シンプルで効果的な解決策となるのがRAG-MCPです。すべてのツールをプロンプトにダンプする代わりに、ツールの説明はベクトルデータベースに保存され、リクエストごとに最も関連性の高いものだけが取得されます。実際には、これにより、ロードアウトが小さく集中したものになり、プロンプトが大幅に短縮され、ツール選択の精度が最大3倍向上します。

小型モデルでは、この壁にぶつかるのがさらに早くなります。調査によると、8Bモデルは数十個のツールでは失敗しますが、ロードアウトを調整すると成功します。場合によっては最初にLLMを使用して、必要と思われるツールを動的に選択すると、パフォーマンスが44%向上し、電力使用量とレイテンシも削減されます。重要な点は、ほとんどのエージェントはわずかなツールしか必要としないものの、システムが成長するにつれて、ツールのロードアウトとRAG-MCPが第一の設計上の決定事項になるということです。

コンテキストのプルーニング：チャット履歴の長さを制限する

会話が何ターンも続くと、蓄積されたチャット履歴が大きすぎて収まらなくなり、コンテキストがオーバーフローしたり、モデルの注意が散漫になったりします。

トリミングとは、会話が長くなるにつれて、重要度の低い部分をプログラムで削除または短縮することを指します。単純な形式としては、一定の制限に達したときに会話の最も古いターンを削除し、最新のN件のメッセージのみを保持する方法があります。より高度なプルーニングにより、無関係な余談や不要になった以前の指示を削除することもあります。目標は、コンテキストウィンドウが古いニュースで煩雑にならないようにすることです。

例えば、エージェントが10ターン前にサブ問題を解決し、その後先に進んだ場合、コンテキストから履歴のその部分を（それ以上必要ないという前提で）削除することがあります。多くのチャットベースの実装では、最近のメッセージのローリングウィンドウを維持することでこれを実行します。

トリミングは、会話の最初の部分を、要約したり、無関係だと判断したりした後に「忘れる」という単純な作業である場合もあります。そうすることで、コンテキストオーバーフローエラーのリスクが軽減され、コンテキストの逸脱も軽減されるため、モデルが古いコンテンツやトピック外のコンテンツを見つけて脇道に逸れることがなくなります。このアプローチは、人間が1時間の講演のすべての単語を覚えているわけではないものの、重要な部分は覚えているということと非常によく似ています。

作者のDrew Breunigがここで強調しているように、コンテキストプルーニングについて混乱している場合は、質問応答用の軽量（1.75 GB）、効率的で正確なコンテキストプルーナーであるProvence（`naver/provence-reranker-debertav3-v1`）モデルを使用すると違いが出る可能性があります。大きな文書を特定のクエリに最も関連性の高いテキストだけに絞り、特定の間隔で呼び出すことができます。

コード内で`provence-reranker`モデルを呼び出してコンテキストをプルーニングする方法は次のとおりです。

# Context pruning with Provence def prune_with_provence(query: str, context: str, threshold: Optional[float] = None) -> str: """ Prune context using Provence reranker model Args: query: User's query/question context: Original context to prune threshold: Relevance threshold (0-1) for Provence reranker. If None, uses args.pruning_threshold. 0.1 = conservative (recommended, no performance drop) 0.3-0.5 = moderate to aggressive pruning Returns: Pruned context with only relevant sentences """ if provence_model is None: return context if threshold is None: threshold = args.pruning_threshold try: # Use Provence's process method provence_output = provence_model.process( question=query, context=context, threshold=threshold, always_select_title=False, enable_warnings=False ) # Extract pruned context from output pruned_context = provence_output.get('pruned_context', context) reranking_score = provence_output.get('reranking_score', 0.0) # Log statistics original_length = len(context) pruned_length = len(pruned_context) reduction_pct = ((original_length - pruned_length) / original_length * 100) if original_length > 0 else 0 if args.verbose: rich.print(f"[cyan]📊 Pruning stats: {pruned_length}/{original_length} chars ({reduction_pct:.1f}% reduction, threshold={threshold:.2f}, rerank_score={reranking_score:.3f})[/cyan]") return pruned_context if pruned_context else context except Exception as e: rich.print(f"[yellow]⚠️ Error in Provence pruning: {str(e)}[/yellow]") rich.print(f"[yellow]⚠️ Falling back to original context[/yellow]") return context

文の関連性のスコア付けにはProvenceリランカーモデル（`naver/provence-reranker-debertav3-v1`）を使用します。しきい値ベースのフィルタリングにより、関連性しきい値を超える文が保持されます。また、プルーニングが失敗した場合に元のコンテキストに戻るフォールバックメカニズムも導入します。最後に、統計ログが詳細モードで削減率を追跡します。

コンテキストの要約：古い情報を完全に削除するのではなく、要約する

要約はトリミングの相棒です。履歴やナレッジベースが大きくなりすぎた場合は、LLMを使用して重要なポイントの簡単な要約を作成し、上記のコードで実行したように、今後のコンテンツ全体の代わりにその要約を使用できます。

例えば、AIアシスタントが50ターンの会話を行った場合、51ターン目に50ターンすべてをモデルに送信するのではなく（おそらく収まりません）、システムは1ターン目から40ターン目までを取得し、モデルにそれらを段落に要約させてから、次のプロンプトでその要約と最後の10ターンのみを提供する可能性があります。こうすることで、モデルはすべての詳細を必要とせずに議論内容を把握できます。初期のチャットボットのユーザーは、「これまでの話を要約してくれますか？」と尋ね、要約した内容を新しいセッションで継続することで、これを手動で行っていました。今ではこれを自動化できます。要約はコンテキストウィンドウのスペースを節約するだけでなく、余分な詳細を削除して重要な事実だけを保持することでコンテキストの逸脱や混乱を減らすこともできます。

OpenAIのモデル（どんなLLMでも使用可能）を使って、すべての関連情報を保持しながらコンテキストを凝縮し、冗長性や重複を排除する方法を紹介します。

# Context summarization def summarize_context(query: str, context: str) -> str: """ Summarize context using LLM to reduce duplication and focus on relevant information Args: query: User's query/question context: Context to summarize Returns: Summarized context """ try: summary_prompt = f"""You are an expert at summarizing conversation context. Your task: Analyze the provided conversation context and produce a condensed summary that fully answers or supports the user's specific question. The summary must: 1. Preserve every fact, detail, and information that directly relates to the question 2. Eliminate redundancy and duplicate information 3. Maintain chronological flow when relevant 4. Focus on information that helps answer: "{query}" Context to summarize: {context} Provide a concise summary that preserves all relevant information:""" summary = llm.invoke(summary_prompt).content if args.verbose: original_length = len(context) summary_length = len(summary) reduction_pct = ((original_length - summary_length) / original_length * 100) if original_length > 0 else 0 rich.print(f"[cyan]📝 Summarization stats: {summary_length}/{original_length} chars ({reduction_pct:.1f}% reduction)[/cyan]") return summary except Exception as e: rich.print(f"[yellow]⚠️ Error in context summarization: {str(e)}[/yellow]") rich.print(f"[yellow]⚠️ Falling back to original context[/yellow]") return context

重要なのは、コンテキストを要約すると、モデルが些細な詳細や過去のエラーに圧倒されにくくなることです（要約が正確であれば）。

しかし、要約は慎重に行わなければなりません。悪い要約は重要な部分を省略したり、エラーを生じさせたりすることがあります。これは本質的にはモデルに対する別のプロンプト（「これを要約してください」）なので、ハルシネーションを起こしたり、ニュアンスが失われたりする可能性があります。ベストプラクティスとしては、段階的に要約し、一部の標準的な事実は要約しないままにしておくことが挙げられます。

それでも非常に有用であることが証明されています。Geminiエージェントのシナリオでは、約10万トークンごとにコンテキストを要約することが、モデルの繰り返し傾向に対抗する方法でした。要約は会話やデータの圧縮された記憶のように機能します。開発者としては、エージェントに会話履歴や長いドキュメントの要約機能（おそらく小さなLLMまたは専用ルーティン）を定期的に呼び出させることでこれを実装できます。結果の要約はプロンプト内の元のコンテンツに置き換えられます。この戦術は、コンテキストを制限内に保ち、情報を精査するために広く使用されています。

コンテキストの隔離：可能な限りコンテキストを隔離する

これは複雑なエージェントシステムや多段階のワークフローでより重要です。コンテキストセグメンテーションの考え方は、大きなタスクを、それぞれ独自のコンテキストを持つ小さな独立したタスクに分割し、すべてが含まれる1つの巨大なコンテキストが蓄積されないようにすることです。各サブエージェントまたはサブタスクは、焦点を絞ったコンテキストで問題の一部に取り組み、その後、上位レベルのエージェント、スーパーバイザー、またはコーディネーターが結果を統合します。

Anthropicの研究戦略はそれぞれが異なる質問の側面を調査し、それぞれのコンテキストウィンドウを持つ複数のサブエージェントと、そのサブエージェントから抽出された結果を読み取るリードエージェントを用います。この並列のモジュール方式のアプローチにより、単一のコンテキストウィンドウが肥大化することはありません。また、無関係な情報が混ざる可能性も減り、各スレッドはトピックに沿って進み（コンテキストの混乱がなく）、特定のサブ質問に答えるときに不必要な負担がかかりません。ある意味、それは思考プロセス全体ではなく、結果だけを共有する別々の思考スレッドを実行するようなものです。

マルチエージェントシステムでは、このアプローチは不可欠です。エージェントAがタスクAを処理し、エージェントBがタスクBを処理する場合、本当に必要な場合を除き、どちらのエージェントも他方のエージェントの完全なコンテキストを使用する理由はありません。代わりに、エージェントは必要な情報だけを交換できます。例えば、エージェントAは、その調査結果の統合された要約をスーパーバイザーエージェントを介してエージェントBに渡すことができますが、各サブエージェントは独自の専用コンテキストスレッドを維持します。この設定では、人間による介入は必要ありません。最小限かつ制御されたコンテキスト共有を備えたツールが有効になっているスーパーバイザーエージェントに依存します。

にもかかわらず、エージェントやツールが最小限の必要なコンテキストオーバーラップで動作するようにシステムを設計することで、明確さとパフォーマンスを大幅に向上させることができます。これをAI用のマイクロサービスと考えると、各コンポーネントがそれぞれのコンテキストを処理し、1 つのモノリシックなコンテキストではなく、制御された方法でコンポーネント間でメッセージを渡すことができます。これらのベストプラクティスは、多くの場合、組み合わせて使用されます。また、これにより、些細な履歴をトリミングしたり、重要な古いメッセージや会話を要約したり、長期的なコンテキストのために詳細なログをElasticsearchにオフロードしたり、必要なときに関連するものを取得して戻したりする柔軟性が得られます。

ここで述べたように、コンテキストは限られた貴重なリソースであるというのが基本原則です。プロンプト内のすべてのトークンがその価値を生むようにし、出力の品質に貢献させる必要があります。メモリ内の何かが役に立たない場合（さらに悪いことに、積極的に混乱を引き起こしている場合も）、そのメモリは削除、要約、削除する必要があります。

開発者として、現在の私たちは、コードをプログラムするのと同じようにコンテキストをプログラムし、含める情報、そのフォーマット方法、および省略または更新するタイミングを決定できます。これらのプラクティスに従うことで、LLMエージェントに、前述の障害モードの被害に遭うことなくタスクを実行するために必要なコンテキストを提供できます。その結果、エージェントは必要なことを記憶し、不要なことを忘れ、必要な情報を必要なタイミングで取得できるようになります。

まとめ

メモリはエージェントに追加するものではなく、設計するものです。短期メモリはエージェントの一時的な作業領域であり、長期メモリはその永続的な知識格納場所です。RAGは2つの間の架け橋であり、Elasticsearchのようなパッシブデータストアを、出力を接地してエージェントを最新の状態に保つことができるアクティブリコールメカニズムに変えます。

しかし、メモリは両刃の剣です。コンテキストを制御せずに放置すると、ポイズニング、逸脱、混乱、衝突を引き起こし、共有システムではデータ漏洩さえも招く可能性があります。だからこそ、メモリに関する最も重要な作業は「より多くを格納する」のではなく、「よりよくキュレーションする」ことです。選択的に取り出し、積極的にプルーニングし、慎重に要約し、タスクが真に要求する場合を除いて、無関係なコンテキストを混ぜ合わせることを避けます。

実際には、優れたコンテキストエンジニアリングは、優れたシステム設計のように見えます。具体的には、コンテキストが小さく十分であり、コンポーネント間のインターフェイスが制御され、モデルに実際に表示したい生の状態と精製された状態が明確に区別された状態です。適切に実行すれば、すべてを記憶するエージェントではなく、適切な理由で適切なタイミングで適切なことを記憶するエージェントが得られます。

Elastic Agent BuilderとStrands Agents SDKの使用を開始

Jonathan Simon — Mon, 15 Dec 2025 00:00:00 GMT

AIエージェントのアイデアをお持ちですか？おそらく、データを使って何かを行うことが関係しているでしょう。エージェントが有用なアクションを開始するには、決定を下す必要があり、正しい決定を下すには正しいデータが必要だからです。

Elastic Agent Builderは、データ接続型AIエージェントを簡単に構築できるようにします。このブログ記事でその方法を説明します。まず、Elasticに格納されているデータにアクセスするMCPツールを使ってエージェントを作成するのに必要なすべてのステップを見ていきましょう。次に、Strands Agents SDKとそのAgent2Agent（A2A）機能を使用してエージェントを操作します。Strands Agents SDKは、望む結果を得るために十分なコードでエージェント向けアプリを構築するマルチエージェントAI開発プラットフォームです。

AIエージェントを構築しましょう。このエージェントは、RPS+というゲームをプレイします。これは古典的な「じゃんけん」に追加のひねりを加えたもので、プレイヤーにいくつかの追加の選択肢を与えます。

要件

こちらのブログ記事の手順に従うために必要なものは次のとおりです。

ローカルコンピューターで実行されているテキストエディター
- このブログ記事の例ではVisual Studio Codeを使用します。
ローカルコンピューターで実行されているPython 3.10以上

Serverlessプロジェクトを作成する

最初に必要なのは、Elastic Agentビルダーを含むElasticsearch Serverlessプロジェクトです。

cloud.elastic.coに移動して新しいElasticsearch Serverlessプロジェクトを作成します。

インデックスを作成してデータを追加する

次に、Elasticsearchプロジェクトにデータを追加します。開発者ツールを開き、コマンドを実行して新しいインデックスを作成し、そこにデータを挿入します。トップレベルのナビゲーションメニューから「開発者向けツール」を選択します。

コピーして、以下のPUTコマンドを開発者向けツールコンソールのリクエストインプットエリアに貼り付けてください。この文は「game-docs」という名前のElasticsearchインデックスを作成します。

PUT /game-docs { "mappings": { "properties": { "title": { "type": "text" }, "content": { "type": "text" }, "filename": { "type": "keyword" }, "last_modified": { "type": "date" } } } }

開発者ツールのステートメントの右側に表示される [リクエストの送信] ボタンをクリックします。開発者向けツールの対応エリアにgame-docsインデックスが作成されたことを確認する通知が表示されるはずです。

game-docsという名前のインデックスは、作成中のゲームのデータを保存するのに最適な場所です。ゲームに必要なすべてのデータを含むこのインデックスに、rps+-mdという名前のドキュメントを配置しましょう。次のPUTコマンドをコピーして、開発者向けツールコンソールに貼り付けます。

PUT /game-docs/_doc/rps+-md { "title": "Rock Paper Scissors +", "content": " # Game Name RPS+ # Starting Prompt Let's play RPS+ ! --- What do you choose? # Game Objects 1. Rock 🪨 👊 2. Paper 📜 🖐 3. Scissors ✄ ✌️ 4. Light ☼ 👍 5. Dark Energy ☄ 🫱 # Judgement of Victory * Rock beats Scissors * because rocks break scissors * Paper beats Rock * because paper covers rock * Scissors beat Paper * because scissors cut paper * Rock beats Light * because you can build a rock structure to block out light * Paper beats Light * because knowledge stored in files and paper books helps us understand light * Light beats Dark Energy * because light enables humans to lighten up and laugh in the face of dark energy as it causes the eventual heat death of the universe * Light beats Scissors * because light is needed to use scissors safely * Dark Energy beats Rock * because dark energy rocks more than rocks. It rocks rocks and everything else in its expansion of the universe * Dark Energy beats Paper * because humans, with their knowledge stored in files and paper books, can't explain dark energy * Scissors beat Dark Energy * because a human running with scissors is darker than dark energy # Invalid Input I was hoping for an worthy opponent - but alas it appears that time has past - but alas there's little time for your todo list when [todo:fix this] is so vast # Cancel Game The future belongs to the bold. Goodbye.. ", "filename": "RPS+.md", "last_modified": "2025-11-25T12:00:00Z" }

ステートメントの横にある [リクエストの送信] ボタンをクリックして実行し、rps+-mdドキュメントをgame-docsのインデックスに追加してください。

クエリを実行するためのデータが用意されているはずです。Agent Builderを使用すると、クエリはこれまで以上に簡単になります。

トップレベルのナビゲーションメニューから [エージェント] を選択します。

あとは、デフォルトのElastic AI Agentに「どんなデータがありますか？」と聞くだけです。

Elastic AI Agentはデータを評価し、保有するデータの簡潔な説明を返します。

ツールを作成する

さて、Elasticにデータがいくつか入ったので、それを活用してみましょう。Agent Builderには、エージェントが必要なデータにアクセスし、タスクに適したコンテキストを得られるようにMCPツールを作成するための組み込みサポートが含まれています。ゲームデータを取得できるシンプルなツールを作りましょう。

Agent Builderのアクションメニューをクリックします。

メニューオプションから [すべてのツールを表示] を選択します。

[+ 新しいツール] をクリックします。

ツール作成フォームでES|QLを選択します。ツールタイプとして次の値を入力します。

ツールIDについて：

example.get_game_docs

説明について：

Get RPS+ doc from Elasticsearch game-docs index.

構成については、以下のクエリをES|QLクエリテキスト領域にします。

FROM game-docs | WHERE filename == "RPS+.md"

完了したツール作成フォームは次のようになります。ツールを作成するには、 [保存] をクリックします。

ツールラックに新しいツールが追加されました。ツールはラックに掛けておけばよいというものではなく、有効に活用されるべきものです。新しいカスタムツールを使用できるエージェントを作成しましょう。

エージェントを作成し、ツールを割り当てます。

Agent Builderを使えば、エージェントの作成は驚くほど簡単です。いくつかの詳細を記載したエージェントの指示を入力するだけで十分です。それではエージェントを作成しましょう。

[エージェントを管理] をクリックします。

[+ 新しいエージェント] をクリックします。

新しいエージェントフォームに次の情報を入力します。

エージェントIDには以下のテキストを入力します。

rps_plus_agent

カスタム指示テキスト領域には次の指示を入力します。

When prompted, if the prompt contains an integer, then select the corresponding numbered item in the list of "Game Objects" from your documents. Otherwise select a random game object. This is your chosen game object for a single round of the game. # General Game Rules * 2 players - the user: the person playing the game - you: the agent playing the game and serving as the game master * Each player chooses a game object which will be compared and cause them to tie, win or lose. # Start the game 1. This is the way each new game always starts. You make the first line of your response only the name of your chosen game object. 2. The remainder of your response should be the "Starting Prompt" text from your documents and generate a list of "Game Objects" for the person playing the game to choose a game object from. # End of Game: The game ends in one of the following three outcomes: 1. Invalid Input: If the player responds with an invalid game object choice, respond with variations of the "Invalid Input" text from your documents and then end the game. 2. Tie: The game ends in a tie if the user chooses the same game object as your game object choice. 3. Win or Lose: The game winner is decided based on the "Judgement of Victory" conditions from your documents. Compare the user's game object choice and your game object choice and determine who chose the winning game object. # Game conclusion Respond with a declaration of the winner of the game by outputting the corresponding text in the "Judgement of Victory" section of your documents.

表示名には以下のテキストを入力します。

RPS+ Agent

表示の説明には以下のテキストを入力します。

An agent that plays the game RPS+

[ツール] タブをクリックして、以前に作成したカスタムツールをエージェントに提供します。

先ほど作成したexample.get_game_docsツールのみを選択します。

[保存] をクリックして新しいエージェントを作成します。

新しいエージェントをテストしてみましょう。エージェントのリストから任意のエージェントとチャットを開始するための便利なリンクがあります。

「start game」と入力すると、ゲームが始まります。うまくいきました！

エージェントが応答の上部にゲームオブジェクトの選択を表示することがわかります。これは、エージェントの選択を確認し、ゲームが期待どおりに機能していることを確認できる点で便利です。しかし、自分が選択する前に相手の選択がわかっていると、じゃんけんゲームはあまり楽しくありません。ゲームを最終形に磨き上げるために、コードでエージェントを制御できるエージェントオーケストレーションプラットフォームを使用できます。

Strands Agents SDKがチャットに参加します。

Strands Agents SDK

新しいエージェント開発フレームワークを試してみたい場合は、Strands Agents SDKがおすすめです。Strands Agents SDKはAWSから2025年5月にオープンソースのPython実装としてリリースされ、現在はTypescript版もあります。

PythonでStrands Agents SDKの使用を開始

コーディングエンジンを起動して、Strandsエージェントを使用してA2Aプロトコル経由でRPS+エージェントを制御するサンプルアプリのクローン作成と実行のプロセスを早速実行してみましょう。RPS+ゲームの微調整バージョンを作成し、エージェントの選択がプレイヤーの選択後に明らかになるようにしてみましょう。結局のところ、じゃんけんのようなゲームを楽しいものにするのは推測と驚きの結果だからです。

ローカルコンピューターでVisual Studio Codeを開き、新しいターミナルを開きます。

新しく開いたターミナルで、以下のコマンドを実行してElasticsearch Labsリポジトリをクローンします。

git clone https://github.com/elastic/elasticsearch-labs

次のcdコマンドを実行して、ディレクトリをelasticsearch-labsディレクトリに変更します。

cd elasticsearch-labs

次に、次のコマンドを実行して、Visual Studio Codeでリポジトリを開きます。

code .

Visual Studio File Explorerで、supporting-blog-contentフォルダーとagent-builder-a2a-strands-agentsフォルダーを展開し、elastic_agent_builder_a2a_rps+.pyファイルを開きます。Visual Studio Codeで開いたファイルは次のようになります。

テキストエディターに表示されるelastic_agent_builder_a2a_rps+.pyの内容は次のとおりです。

import asyncio from dotenv import load_dotenv from uuid import uuid4 import httpx import os import random from a2a.client import A2ACardResolver, ClientConfig, ClientFactory from a2a.types import Message, Part, Role, TextPart DEFAULT_TIMEOUT = 60 # set request timeout to 1 minute def create_message(*, role: Role = Role.user, text: str, context_id=None) -> Message: return Message( kind="message", role="user", parts=[Part(TextPart(kind="text", text=text))], message_id=uuid4().hex, context_id=context_id, ) async def main(): load_dotenv() a2a_agent_host = os.getenv("ES_AGENT_URL") a2a_agent_key = os.getenv("ES_API_KEY") custom_headers = {"Authorization": f"ApiKey {a2a_agent_key}"} async with httpx.AsyncClient( timeout=DEFAULT_TIMEOUT, headers=custom_headers ) as httpx_client: # Get agent card resolver = A2ACardResolver(httpx_client=httpx_client, base_url=a2a_agent_host) agent_card = await resolver.get_agent_card( relative_card_path="/rps_plus_agent.json" ) # Create client using factory config = ClientConfig( httpx_client=httpx_client, streaming=True, ) factory = ClientFactory(config) client = factory.create(agent_card) # Use the client to communicate with the agent print("\nSending 'start game' message to Elastic A2A agent...") random_game_object = random.randint(1, 5) msg = create_message(text=f"start with game object {random_game_object}") async for event in client.send_message(msg): if isinstance(event, Message): context_id = event.context_id response_complete = event.parts[0].root.text # Get agent choice from the first line of the response parsed_response = response_complete.split("\n", 1) agent_choice = parsed_response[0] print(parsed_response[1]) # User choice sent for game results from the agent prompt = input("Your Choice : ") msg = create_message(text=prompt, context_id=context_id) async for event in client.send_message(msg): if isinstance(event, Message): print(f"Agent Choice : {agent_choice}") print(event.parts[0].root.text) if __name__ == "__main__": asyncio.run(main())

このコードで何が起きているのか見てみましょう。main()メソッドから始めて、コードはエージェントのURLとAPIキーの環境変数にアクセスすることから始まります。その値を用いてエージェントカードを取得するためのhttpx clientを作成します。次に、クライアントはエージェントカードの詳細を使用して、「start game」リクエストをエージェントに送信します。ここで注目すべき興味深い点は、 "start game"リクエストの一部としてrandom_game_object値が含まれていることです。この値は、Python の標準ライブラリのrandomモジュールで生成された乱数です。これを行う理由は、（AIエージェントを可能にする）強力なLLMがランダム性に関してはそれほど優れていないことが判明したためです。Pythonが助けてくれますので問題ありません。

コードの続きですが、エージェントが「start game」リクエストに応答すると、コードはエージェントのゲームオブジェクトセレクションを取り除き、agent_choice変数に保存します。対応の残りの部分は、エンドユーザーに対してテキストとして表示されます。次に、ユーザーはゲームオブジェクトの選択を入力するように求められ、それがエージェントに送信されます。次に、コードはエージェントのゲームオブジェクトの選択と、エージェントの最終的なゲーム結果の決定を表示します。

エージェントのURLとAPIキーを環境変数として設定する

サンプルアプリはローカルコンピュータ上で実行されるため、Agent Builderエージェントと通信するためには、Strands Agents SDKにエージェントのA2A URLとAPI Keyを提供する必要があります。この例のアプリは`.env`というファイルを使用してこれらの値を格納します。

env.exampleファイルのコピーを作成し、新しいファイル名を.envとします。

Elastic Agent Builderに戻りましょう。ここで必要な両方の値を取得できます。

ページの右上にあるAgent Builderアクションメニューから [すべてのツールを表示] を選択します。

ツールページ上部のMCPサーバードロップダウンをクリックし、[MCPサーバーURLをコピー] を選択してください。

MCPサーバーのURLを.envに貼り付けます。プレースホルダー値の代わりにファイルを使用します。ここで、URLを1箇所更新する必要があります。つまり、末尾のテキスト「mcp」を「a2a」に置き換えます。これは、Agent Strands SDKがElastic Agent Builderで実行されているエージェントと通信するために使用するプロトコルがA2Aプロトコルであるためです。

編集したURLは次のようになるはずです。

https://rps-game-project-12345a.kb.us-east-1.aws.elastic.cloud/api/agent_builder/a2a

Elastic Cloudで取得する必要があるもう1つの値は、APIキーです。最上位ナビゲーションでElasticsearchをクリックします。

[APIキーをコピー] ボタンをクリックして、APIキーをコピーします。

次に、Visual Studio Codeに戻り、.envファイルにAPIキーを貼り付けて、プレースホルダーテキストを置き換えます。.envファイルは次のようになります。

サンプルアプリを実行してください

Visual Studio Codeで新しいターミナルを開いてください。

まず、ターミナルで次のcdコマンドを実行します。

cd elasticsearch-labs/supporting-blog-content/agent-builder-a2a-strands-agents

次のコマンドを実行して、Python仮想環境を作成します。

python -m venv .venv

お使いのローカルコンピューターのオペレーティングシステムに応じて、以下のコマンドを実行して仮想環境を有効にしてください。

MacOS/Linux

source .venv/bin/activate

Windows

.venv\Scripts\activate

サンプルアプリはStrands Agents SDKを使用するため、このチュートリアルではこれをインストールする必要があります。以下のコマンドを実行して、Strands Agents SDKとその必要なPythonライブラリの依存関係をインストールします。

pip install -r requirements.txt

発射台を片付けてカウントダウンを開始する時間です。アプリを起動する準備ができました。後ろに下がってください。次のコマンドを使用して実行しましょう：

python elastic_agent_builder_a2a_rps+.py

RPS+のゲームに挑戦してみましょう。幸運を祈ります！

Google MCP Toolbox for DatabasesにElasticsearchサポートを導入

Enrico Zimuel,Laurent Saint-Félix — Fri, 12 Dec 2025 00:00:00 GMT

この記事では、Google MCP ToolboxとElasticsearchを併用し、Elasticsearchインデックスから情報を抽出する簡単なツールを構築する方法を解説します。

当社は最近、Google MCP Toolbox for Databasesのオープンソースプロジェクトに貢献し、Elasticsearchをデータベースとしてサポートしました。

この新しい機能により、Google MCP Toolboxを使用してElasticsearchに接続し、データと直接「会話」できるようになりました。

Elasticsearch

Elasticsearchインスタンスを実行する必要があります。Elastic Cloudで無料トライアルを有効化するか、start-localスクリプトを使ってローカルにインストールできます。

curl -fsSL https://elastic.co/start-local | sh

これにより、ElasticsearchとKibanaがコンピュータにインストールされ、Google MCP Toolboxの設定に使用するAPIキーが生成されます。

APIキーは前のコマンドの出力として表示され、elastic-start-localフォルダー内の.envファイルに保存されます。

サンプルデータセットをインストールする

インストール後、ユーザー名elasticとstart-localスクリプトによって生成されたパスワード（.envファイルに保存）を使用してKibanaにログインできます。

Kibanaから入手可能なeCommerce ordersデータをインストールできます。このデータベースには、eコマースWebサイトからの4,675件の注文に関する情報を含むkibana_sample_data_ecommerceという単一のインデックスが含まれています。各注文について、次の情報があります。

顧客情報（氏名、ID、生年月日、メールアドレスなど）
注文日
注文ID
商品（価格、数量、ID、カテゴリー、割引などを含む全商品のリスト）
SKU
合計金額（税抜、税込）
合計数量
地理情報（都市、国、大陸、場所、地域）

サンプルデータをインストールするには、Kibanaの統合ページを開き（検索トップバーで「Integration」を検索）、「Sample Data」をインストールしてください。詳細については、ドキュメントhttps://www.elastic.co/docs/explore-analyze/#gs-get-data-into-kibanaを参照してください。

この記事の目的は、Google MCP ToolboxがElasticsearchに接続し、自然言語でkibana_sample_data_ecommerceインデックスとやり取りするのがいかに簡単かを示すことです。

Google MCP Toolbox

Google MCP ToolboxはオープンソースのMCPサーバーで、アプリケーションやAIエージェントが安全かつ効率的にデータベースとやり取りできるように設計されています。以前は「GenAI Toolbox for Databases」と呼ばれていたこのプロジェクトは、モデルコンテキストプロトコル（MCP）との完全な互換性を採用した後に改名されました。その目的は、エージェントをデータベースに接続する際に従来必要とされていた接続プーリング、認証、オブザーバビリティ、その他の運用上の懸念をバックエンドで処理することで、重労働を排除することです。

Toolboxの本質は、開発者がデータベースのやり取りをカプセル化する再利用可能な高レベルのツールを定義できるようにすることです。これらのツールは、AIエージェントなどのMCP互換クライアントならどれでも起動できます。クライアントが低レベルのSQLクエリを実装したり、データベース接続を管理したりする必要はありません。このアプローチにより、データベース対応エージェントの構築に必要な定型コードの量が大幅に削減され、わずか数行のアプリケーションロジックに高度なデータ操作を統合できるようになります。ツールが定義されると、複数のエージェント、フレームワーク、言語間で共有できます（図1）。

Toolboxを使用する大きな利点は、組み込まれたセキュリティモデルです。OAuth2やOIDCなどの認証フローはネイティブにサポートされているため、開発者はデータベースの機密認証情報をエージェントで処理したり格納したりする必要がありません。このプラットフォームは、デバッグ、監視、本番環境への導入に不可欠な、OpenTelemetryによる指標やトレースなどの観測機能も提供します。全体として、MCP Toolboxは、あらゆるMCP対応システムのデータを操作するための、統一された安全で拡張可能なインターフェースとして機能します。

MCP Toolboxのインストール方法

MCP ToolboxサーバーをLinuxにインストールするには、次のコマンドを使用します。

export VERSION=0.21.0 curl -L -o toolbox https://storage.googleapis.com/genai-toolbox/v$VERSION/linux/amd64/toolbox chmod +x toolbox

macOSまたはWindowsにインストールする場合は、ここに記載されている手順に従ってください。

Elasticsearch向けにToolboxを構成する

Elasticsearch向けにMCP Toolboxを構成するには、次のようにtools.yamlファイルを作成する必要があります。

sources: my-cluster: kind: elasticsearch addresses: - http://localhost:9200 apikey: tools: customer-orders: kind: elasticsearch-esql source: my-cluster description: Get the orders made by a customer identified by name. query: | FROM kibana_sample_data_ecommerce | WHERE MATCH(customer_full_name, ?name, {"operator": "AND"}) parameters: - name: name type: string description: The customer name. toolsets: elasticsearch-tools: - customer-orders

値を有効なElasticsearch APIキーに置き換える必要があります。start-localを使用してElasticsearchをローカルで実行している場合は、start-localによって生成された.envファイルのES_LOCAL_API_KEY変数の下にAPIキーがあります。Elastic Cloudを使用している場合はここで説明した手順に従うことでAPIキーを生成できます。

前のツールには、Elasticsearch用の次のES|QLクエリが含まれています。

ES|QLに慣れていない方のために説明すると、ES|QLはSQLと同様にElasticが開発したクエリ言語で、1つ以上のインデックスを検索するために使用できます。ES|QLの詳細についてはこちらの公式ドキュメントをご覧ください。

上記のクエリは、kibana_sample_data_ecommerceインデックスに格納されている指定顧客名を含むすべての注文を?nameパラメーター（疑問符はパラメーターを示します）を用いて検索します。

顧客名は、以前のYAML設定で文字列型と「顧客名」という記述で定義されています。

このツールを使用すると、顧客の注文に関する質問に答えることができます。たとえば、「顧客Fooは2025年10月に何件の注文をしましたか？」

ツールとそのパラメーターの説明は、ユーザーの自然言語リクエストから関連情報を抽出するために不可欠です。この抽出は、大規模言語モデル（LLM）の関数呼び出し機能を使用して実行されます。実際には、LLMは、必要な情報を取得するためにどの機能（ツール）を実行する必要があるかを判断し、その機能に適したパラメーターも取得できます。

詳細については、Elasticsearchを使用したOpenAIの関数呼び出しに関するAshish Tiwariの記事を読むことをお勧めします。

Toolboxサーバーを実行する

次のコマンドで、以前のtools.yamlファイルを使用してMCPツールボックスを実行できます。

./toolbox --tools-file tools.yaml --ui

–uiパラメーターはhttp://127.0.0.1:5000/uiのウェブアプリケーションを実行します（図2）。

[ツール] > [customer-orders] を選択し、パラメータ名に顧客名（例：Gwen Sanders）を挿入して [ツールを実行] ボタンをクリックします。図3に示すように、JSON応答が表示されます。

セットアップが完了すると、MCP Toolboxはcustomer-ordersツールを実行してElasticsearchと通信し、ES|QLクエリを実行できるようになります。

Gemini CLIでのMCP Toolboxの使用

任意のMCPクライアントを使用して、MCP Toolbox for Databasesと通信できます。例えば、Gemini CLIというコマンドラインツールを使ってGeminiを使うことができます。Gemini CLIのインストールは、こちらの手順に従って行うことができます。

Gemini CLIは、MCP Toolbox用の事前設定された拡張機能を提供しており、gemini-cli-extensions/mcp-toolboxで入手できます。この拡張機能は次のコマンドを実行してインストールできます。

gemini extensions install https://github.com/gemini-cli-extensions/mcp-toolbox

インストール後、MCP Toolbox用のtools.yaml設定ファイルを格納したディレクトリに移動し、以下のようにGemini CLIを実行する必要があります（この手順は、Gemini CLIをMCP Toolboxで自動的に設定するために必要です）。

gemini

図4に示すように出力広告が表示されます。

次のコマンドを使用して、MCP Toolboxが接続されているかどうかを確認できます。

/mcp list

mcp_toolboxとcustomer-orders ツールが一覧に表示されているはずです（図5）。

MCP ToolboxがGemini CLI に接続されている場合は、「顧客Gwen Sandersの注文を教えてください」などの質問をいくつか試すことができます。Gemini CLIは、mcp_toolboxサーバーからcustomer-ordersツールを実行する許可を要求します（図6を参照）。

確認後、Gemini CLIはMCP Toolboxへのリクエストを実行し、結果としてJSON応答を取得し、それを使用して応答をフォーマットします（図7）。

Gemini CLIからの応答で、Gwen Sandersが2つの製品を1回の注文で、合計132ユーロの価格で購入したことがレポートされます。

MCP Toolbox SDKs

Google MCP Toolboxは、Go、Python、Javascriptで書かれたプログラムからすべての機能にアクセスするためのSDKも提供しています。

例えば、Python SDKはGithubの次のページhttps://github.com/googleapis/mcp-toolbox-sdk-pythonで入手可能です。

MCP Toolboxに接続するための簡単なエージェントを作成する必要があります。次のパッケージをインストールする必要があります。

pip install toolbox-core pip install google-adk

次のコマンドを使用して、新しいエージェントプロジェクトを作成します。

adk create my_agent

これにより、ファイルagent.pyを持つ新しいディレクトリがmy_agentとして作成されます。

Toolboxに接続するには、次の内容でmy_agent/agent.pyを更新します。

from google.adk import Agent from google.adk.apps import App from toolbox_core import ToolboxSyncClient client = ToolboxSyncClient("http://127.0.0.1:5000") root_agent = Agent( name='root_agent', model='gemini-2.5-flash', instruction="You are a helpful AI assistant designed to search information about a dataset of ecommerce orders.", tools=client.load_toolset(), ) app = App(root_agent=root_agent, name="my_agent")

Google APIキーを使用して.envファイルを作成します。

echo 'GOOGLE_API_KEY="YOUR_API_KEY"' > my_agent/.env

最後に、エージェントを実行して結果を確認します。エージェントを実行するには、次のコマンドを実行します。

adk run my_agent

または、Webインターフェース経由で提供することもできます。

adk web --port 8000

両方の場合において、Q&Aインターフェースを使用してMCP Toolboxと対話することができます。たとえば、先程の質問「顧客Gwen Sandersの注文を教えてください」をすることができます。

さまざまなSDKの詳細については、このドキュメントページをご参照ください。

まとめ

この記事では、Google MCP Toolbox for DatabasesのElasticsearch統合について説明しました。シンプルなYAML設定ファイルを使用して、自然言語の質問をES|QL言語を使用してElasticsearchクエリに変換する一連のツールを定義できます。

eコマースWebサイトからの注文を含むkibana_sample_data_ecommerceデータセットとの対話方法を示しました。この設定ファイルを使用すると、MCP Toolboxサーバーを簡単に実行し、任意のMCPクライアントから接続できます。

最後に、Gemini CLIをクライアントとして使用してMCP Toolbox for Databasesに接続し、Elasticsearchに保存されているeコマースデータをクエリする方法を示しました。特定の顧客の名前で識別された注文情報を取得するために自然言語クエリを実行しました。

MCPエコシステムが成長し続けるにつれて、このパターン（安全で本番環境ですぐに使えるインフラストラクチャーに裏打ちされた軽量なツール定義）は、最小限の労力で、ますます有能でデータを認識するエージェントを構築する新しい機会を生み出します。MCP Toolboxは、Elasticのサンプルデータセットを使ってローカルで実験する場合でも、大規模なアプリケーションに検索機能を統合する場合でも、自然言語を使ってElasticsearchのデータを操作するための、信頼性と拡張性に優れた基盤を提供します。

エージェントAIアプリケーションの開発の詳細については、Anish MathurとDana Juratoniによる記事「Elasticsearchを使用したAI エージェントワークフローの構築」をお読みください。

Google MCP Toolboxの詳細については、https://googleapis.github.io/genai-toolbox/getting-started/introduction/をご覧ください。

LangGraph.jsとElasticsearchを使用して金融AI検索ワークフローを構築

Jeffrey Rengifo — Fri, 05 Dec 2025 00:00:00 GMT

AI検索アプリケーションの構築では、多くの場合、複数のタスク、データ取得、データ抽出をシームレスなワークフローに調整する必要があります。LangGraphは、開発者がnodeベースの構造を使用してAIエージェントを管理することで、このプロセスを簡素化します。この記事では、LangGraph.jsを使用して金融ソリューションを構築します。

LangGraphの概要

LangGraphは、AIエージェントを構築し、ワークフロー内で管理してAI支援アプリケーションを作成するためのフレームワークです。LangGraphには、タスクを表す関数を宣言し、それらをワークフローのノードとして割り当てることができるノードアーキテクチャがあります。複数のノードが相互作用した結果がグラフになります。LangGraphは、モジュール式かつ構成可能なAIシステムを構築するためのツールを提供する、より広範なLangChainエコシステムの一部です。

LangGraphが有用である理由をより深く理解するために、LangGraphを使用して問題のある状況を解決してみましょう。

ソリューションの概要

ベンチャーキャピタル企業では、投資家は多くのフィルタリングオプションを備えた大規模なデータベースにアクセスできますが、基準を組み合わせたい場合には困難で時間がかかります。これにより、関連するスタートアップの一部が投資対象として見つからない可能性があります。その結果、最適な候補を見つけるために多くの時間を費やしたり、機会を逃したりすることになります。

LangGraphとElasticsearchを使用することで、自然言語を用いてフィルターで検索することが可能となり、ユーザーが手動で複雑なリクエストを何十ものフィルターで構築する必要がなくなります。柔軟性を高めるために、ワークフローはユーザーの入力に基づいて2つのクエリタイプを自動的に決定します。

投資に焦点を当てたクエリ：スタートアップ企業の財務および資金調達の側面を対象としており、資金調達ラウンド、バリュエーション、収益を含みます。例：「シリーズAまたはシリーズBの資金調達額が800万ドル～2,500万ドルで、月間収益が50万ドルを超えるスタートアップを探してください。」
市場重視のクエリ：業界分野、地理的市場、ビジネスモデルに重点を置き、特定のセクターまたは地域での機会の特定に役立ちます。例：「サンフランシスコ、ニューヨーク、ボストンのフィンテックおよびヘルスケアのスタートアップ企業を探してください」

クエリを強固に保つため、LLMに検索テンプレートを構築させ、完全なDSLクエリの代わりとします。このようにすれば、必要なクエリを常に取得でき、LLMは空白を埋めるだけで済み、毎回必要なクエリを構築する責任を負う必要がなくなります。

始めるために必要なもの

Elasticsearch APIキー
OpenAPI APIキー
Node 18以降

ステップ別のガイド

このセクションでは、アプリがどのように見えるかを見てみましょう。TypeScriptはJavaScriptのスーパーセットで、静的な型を追加することでコードの信頼性を高め、保守性を向上させ、エラーを早期に発見して安全性を高めます。既存のJavaScriptとの完全な互換性を保ちながら、これを実現します。

ノードのフローは次のようになります。

上記の画像はLangGraphによって生成されたもので、ノード間の実行順序と条件付きロジックを定義するワークフローを表しています。

decideStrategy：LLMを用いてユーザーのクエリを分析し、投資重視か市場重視の2つの専門的な検索戦略のどちらかを判断します。
prepareInvestmentSearch：クエリからフィルター値を抽出し、財務および資金調達関連のパラメータを強調した定義済みテンプレートを構築します。
prepareMarketSearch : フィルター値も抽出しますが、市場、業界、地理的コンテキストを重視したパラメータを動的に構築します。
executeSearch：検索テンプレートを使用して構築されたクエリをElasticsearchに送信し、一致するスタートアップドキュメントを取得します。
visualizeResults：最終結果を、資金、業界、収益などの主要なスタートアップ属性を示す明確で読みやすい要約にフォーマットします。

このフローには「if」ステートメントとして機能する条件分岐が含まれており、ユーザーの入力に基づいて投資検索パスを使用するか、市場検索パスを使用するかを決定します。LLMにより駆動されるこの意思決定ロジックにより、ワークフローは適応的でコンテキストに応じたものになります。このメカニズムについては次のセクションで詳しく説明します。

LangGraphの状態

各ノードを個別に見る前に、ノードがどのように通信し、データを共有するかを理解する必要があります。そのために、LangGraphではワークフローの状態を定義することができます。これはノード間で共有される状態を定義します。

状態は、ワークフロー全体の中間データを保存する共有コンテナとして機能します。ユーザーの自然言語クエリから始まり、選択された検索戦略、Elasticsearch用に準備されたパラメータ、取得された検索結果、最後にフォーマットされた出力が保持されます。

この構造により、すべてのノードが状態を読み取って更新できるようになり、ユーザー入力から最終的な視覚化までの一貫した情報の流れが保証されます。

const VCState = Annotation.Root({ input: Annotation(), // User's natural language query searchStrategy: Annotation(), // Search strategy chosen by LLM searchParams: Annotation(), // Prepared search parameters results: Annotation(), // Search results final: Annotation(), // Final formatted response });

アプリケーションをセットアップする

このセクションのすべてのコードはelasticsearch-labsリポジトリで見つけることができます。

アプリが置かれるフォルダーでターミナルを開き、以下のコマンドで Node.js アプリケーションを初期化します。

npm init -y

これで、このプロジェクトに必要な依存関係をインストールできます。

npm install @elastic/elasticsearch @langchain/langgraph @langchain/openai @langchain/core dotenv zod && npm install --save-dev @types/node tsx typescript

@elastic/elasticsearch: Elasticsearchのデータインジェストや検索などのリクエストを処理するのに役立ちます。
@langchain/langgraph: すべてのLangGraphツールを提供するためのJS依存関係。
@langchain/openai: LangChain用のOpenAI LLMクライアント。
@langchain/core：プロンプトテンプレートなど、LangChainアプリのコアとなる基本的な構成要素を提供します。
dotenv:JavaScriptで環境変数を使用するために必要な依存関係。
zod：型データへの依存関係。

@types/node tsx typescript により、TypeScriptコードを記述して実行できるようになります。

次に、以下のファイルを作成します。

elasticsearchSetup.ts: Elasticsearchのマッピングを作成し、JSONファイルからデータを取り込み、Elasticsearchにデータを取り込みます。
main.ts: LangGraphアプリケーションが含まれます。
.env：環境変数を格納するファイル

.envファイルに以下の環境変数を追加します。

ELASTICSEARCH_ENDPOINT="your-endpoint-here" ELASTICSEARCH_API_KEY="your-key-here" OPENAI_API_KEY="your-key-here"

OpenAPI APIKeyはコード上で直接使用されることはなく、ライブラリ@langchain/openaiによって内部的に使用されます。

マッピングの作成、検索テンプレートの作成、データセットのインジェストに関するすべてのロジックは、elasticsearchSetup.tsファイルにあります。次のステップでは、main.tsファイルに焦点を当てていきます。また、データセットをチェックして、 dataset.jsonでデータがどのように表示されるかをよりよく理解することもできます。

LangGraphアプリ

main.tsファイルで、LangGraphアプリを統合するために必要な依存関係をいくつかインポートしましょう。このファイルには、ノード関数と状態宣言も含める必要があります。グラフの宣言は、次のステップで main メソッドで行われます。elasticsearchSetup.tsファイルには、以降のステップでノード内で使用する Elasticsearch ヘルパーが含まれます。

import { writeFileSync } from "node:fs"; import { StateGraph, Annotation, START, END } from "@langchain/langgraph"; import { ChatOpenAI } from "@langchain/openai"; import { z } from "zod"; import { esClient, ingestDocuments, createSearchTemplates, INDEX_NAME, INVESTMENT_FOCUSED_TEMPLATE, MARKET_FOCUSED_TEMPLATE, createIndex, } from "./elasticsearchSetup.js"; const llm = new ChatOpenAI({ model: "gpt-4o-mini" });

前述のように、LLMクライアントは、ユーザーの質問に基づいてElasticsearch検索テンプレートパラメーターを生成するために使用されます。

async function saveGraphImage(app: any): Promise { try { const drawableGraph = app.getGraph(); const image = await drawableGraph.drawMermaidPng(); const arrayBuffer = await image.arrayBuffer(); const filePath = "./workflow_graph.png"; writeFileSync(filePath, new Uint8Array(arrayBuffer)); console.log(`📊 Workflow graph saved as: ${filePath}`); } catch (error: any) { console.log("⚠️ Could not save graph image:", error.message); } }

上記の方法はグラフ画像をpng形式で生成し、裏でMermaid.INK APIを利用しています。これは、スタイル設定された視覚化を使用してアプリノードがどのように相互作用するかを確認する場合に便利です。

LangGraphノード

次に、各ノードの詳細を見てみましょう。

decideSearchStrategyノード

decideSearchStrategyノードはユーザー入力を分析し、投資重視の検索を実行するか、市場重視の検索を実行するかを決定します。構造化された出力スキーマ（Zodで定義）を持つLLMを使用してクエリタイプを分類します。決定を下す前に、集計を使用してインデックスから利用可能なフィルターを取得し、モデルが業界、場所、資金調達データに関する最新のコンテキストを持っていることを確認します。

フィルタの可能な値を抽出してLLMに送信するために、集計クエリを使ってElasticsearchインデックスから直接値を取得してみましょう。このロジックはgetAvailableFiltersというメソッドに割り当てられます。

async function getAvailableFilters() { try { const response = await esClient.search({ index: INDEX_NAME, size: 0, aggs: { industries: { terms: { field: "industry", size: 100 }, }, locations: { terms: { field: "location", size: 100 }, }, funding_stages: { terms: { field: "funding_stage", size: 20 }, }, business_models: { terms: { field: "business_model", size: 10 }, }, lead_investors: { terms: { field: "lead_investor", size: 100 }, }, funding_amount_stats: { stats: { field: "funding_amount" }, }, }, }); return response.aggregations; } catch (error) { console.error("❌ Error getting available filters:", error); return {}; } }

上記の集約クエリを用いると、以下の結果が得られます。

{ "industries": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "logistics", "doc_count": 5 }, ... ] }, "locations": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "San Francisco, CA", "doc_count": 4 }, { "key": "New York, NY", "doc_count": 3 }, ... ] }, "funding_stages": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "Series A", "doc_count": 8 }, ... ] }, "business_models": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "B2B", "doc_count": 13 }, ... ] }, "lead_investors": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "Battery Ventures", "doc_count": 1 }, { "key": "Benchmark Capital", "doc_count": 1 }, ... ] }, "funding_amount_stats": { "count": 20, "min": 4500000, "max": 35000000, "avg": 14075000, "sum": 281500000 } }

すべての結果はこちらでご覧いただけます。

両方の戦略において、ハイブリッド検索を行うことにより、質問の構造化された部分（フィルター）とより主観的な部分（セマンティック）の両方を検出します。以下は検索テンプレートを使用した両方のクエリの例です。

await esClient.putScript({ id: INVESTMENT_FOCUSED_TEMPLATE, script: { lang: "mustache", source: `{ "size": 5, "retriever": { "rrf": { "retrievers": [ { "standard": { "query": { "semantic": { "field": "semantic_field", "query": "{{query_text}}" } } } }, { "standard": { "query": { "bool": { "filter": [ {"terms": {"funding_stage": {{#join}}{{#toJson}}funding_stage{{/toJson}}{{/join}}}}, {"range": {"funding_amount": {"gte": {{funding_amount_gte}}{{#funding_amount_lte}},"lte": {{funding_amount_lte}}{{/funding_amount_lte}}}}}, {"terms": {"lead_investor": {{#join}}{{#toJson}}lead_investor{{/toJson}}{{/join}}}}, {"range": {"monthly_revenue": {"gte": {{monthly_revenue_gte}}{{#monthly_revenue_lte}},"lte": {{monthly_revenue_lte}}{{/monthly_revenue_lte}}}}} ] } } } } ], "rank_window_size": 100, "rank_constant": 20 } } }`, }, });

elasticsearchSetup.tsファイルに詳細が記載されているクエリを確認します。次のノードでは、2つのクエリのどちらを使用するかが決定されます。

// Node 1: Decide search strategy using LLM async function decideSearchStrategy(state: typeof VCState.State) { // Zod schema for specialized search strategy decision const SearchDecisionSchema = z.object({ search_type: z .enum(["investment_focused", "market_focused"]) .describe("Type of specialized search strategy to use"), reasoning: z .string() .describe("Brief explanation of why this search strategy was chosen"), }); const decisionLLM = llm.withStructuredOutput(SearchDecisionSchema); // Get dynamic filters from Elasticsearch const availableFilters = await getAvailableFilters(); const prompt = `Query: "${state.input}" Available filters: ${JSON.stringify(availableFilters, null, 2)} Choose between two specialized search strategies: - investment_focused: For queries about funding stages, funding amounts, monthly revenue, lead investors, financial performance - market_focused: For queries about industries, locations, business models, market segments, geographic markets Analyze the query intent and choose the most appropriate strategy. `; try { const result = await decisionLLM.invoke(prompt); console.log( `🤔 Search strategy: ${result.search_type} - ${result.reasoning}` ); return { searchStrategy: result.search_type, }; } catch (error: any) { console.error("❌ Error in decideSearchStrategy:", error.message); return { searchStrategy: "investment_focused", }; } }

prepareInvestmentSearchノードとprepareMarketSearchノード

どちらのノードも共有ヘルパー関数extractFilterValuesを使用します。この関数はLLMを活用して、業界、場所、資金調達段階、ビジネスモデルなど、ユーザーの入力に記載されている関連フィルターを識別します。このスキーマを使用して検索テンプレートを構築します。

// Extract all possible filter values from user input async function extractFilterValues(input: string) { const FilterValuesSchema = z.object({ // Investment-focused filters funding_stage: z .array(z.string()) .default([]) .describe("Funding stage values mentioned in query"), funding_amount_gte: z .number() .default(0) .describe("Minimum funding amount in USD"), funding_amount_lte: z .number() .default(100000000) .describe("Maximum funding amount in USD"), lead_investor: z .array(z.string()) .default([]) .describe("Lead investor values mentioned in query"), monthly_revenue_gte: z .number() .default(0) .describe("Minimum monthly revenue in USD"), monthly_revenue_lte: z .number() .default(10000000) .describe("Maximum monthly revenue in USD"), industry: z .array(z.string()) .default([]) .describe("Industry values mentioned in query"), location: z .array(z.string()) .default([]) .describe("Location values mentioned in query"), business_model: z .array(z.string()) .default([]) .describe("Business model values mentioned in query"), }); const extractorLLM = llm.withStructuredOutput(FilterValuesSchema); const availableFilters = await getAvailableFilters(); const extractPrompt = `Extract ALL relevant filter values from: "${input}" Available options: ${JSON.stringify(availableFilters, null, 2)} Extract only values explicitly mentioned in the query. Leave fields empty if not mentioned.`; return await extractorLLM.invoke(extractPrompt); }

検出された意図に応じて、ワークフローは2つのパスのいずれかを選択します。

prepareInvestmentSearch：資金調達段階、資金調達額、投資家、更新情報などの財務指向の検索パラメータを構築します。クエリテンプレート全体はelasticsearchSetup.tsファイルで確認できます。

// Node 2A: Prepare Investment-Focused Search Parameters async function prepareInvestmentSearch(state: typeof VCState.State) { console.log( "💰 Preparing INVESTMENT-FOCUSED search parameters with financial emphasis..." ); try { // Extract all filter values from input const values = await extractFilterValues(state.input); let searchParams: any = { template_id: INVESTMENT_FOCUSED_TEMPLATE, query_text: state.input, ...values, }; return { searchParams }; } catch (error) { console.error("❌ Error preparing investment-focused params:", error); return { searchParams: {}, }; } }

prepareMarketSearch：業界、地域、ビジネスモデルに重点を置いた市場主導のパラメータを作成します。クエリ全文はelasticsearchSetup.tsファイルをご覧ください。

// Node 2B: Prepare Market-Focused Search Parameters async function prepareMarketSearch(state: typeof VCState.State) { console.log( "🔍 Preparing MARKET-FOCUSED search parameters with market emphasis..." ); try { // Extract all filter values from input const values = await extractFilterValues(state.input); let searchParams: any = { template_id: MARKET_FOCUSED_TEMPLATE, query_text: state.input, ...values, }; return { searchParams }; } catch (error) { console.error("❌ Error preparing market-focused params:", error); return {}; } }

executeSearchノード

このノードは、生成された検索パラメータを状態から取得し、最初にElasticsearchに送信します。次に、_render APIを使用してデバッグの目的でクエリを視覚化し、次に結果を取得するためのリクエストを送信します。

// Node 3: Execute Search async function executeSearch(state: typeof VCState.State) { const { searchParams } = state; try { // getting formed query from template for debugging const renderedTemplate = await esClient.renderSearchTemplate({ id: searchParams.template_id, params: searchParams, }); console.log( "📋 Complete query:", JSON.stringify(renderedTemplate.template_output, null, 2) ); const results = await esClient.searchTemplate({ index: INDEX_NAME, id: searchParams.template_id, params: searchParams, }); return { results: results.hits.hits.map((hit: any) => hit._source), }; } catch (error: any) { console.error(`❌ ${state.searchParams.search_type} search error:`, error); return { results: [] }; } }

visualizeResultsノード

最後に、このnodeはElasticsearchの結果を表示します。

// Node 4: Visualize results async function visualizeResults(state: typeof VCState.State) { const results = state.results || []; let formattedResults = `🎯 Found ${results.length} startups matching your criteria:\n\n`; results.forEach((startup: any, index: number) => { formattedResults += `${index + 1}. **${startup.company_name}**\n`; formattedResults += ` 📍 ${startup.location} | 🏢 ${startup.industry} | 💼 ${startup.business_model}\n`; formattedResults += ` 💰 ${startup.funding_stage} - $${( startup.funding_amount / 1000000 ).toFixed(1)}M\n`; formattedResults += ` 👥 ${startup.employee_count} employees | 📈 $${( startup.monthly_revenue / 1000 ).toFixed(0)}K MRR\n`; formattedResults += ` 🏦 Lead: ${startup.lead_investor}\n`; formattedResults += ` 📝 ${startup.description}\n\n`; }); return { final: formattedResults, }; }

プログラム的には、グラフ全体は次のようになります。

const workflow = new StateGraph(VCState) // Register nodes - these are the processing functions .addNode("decideStrategy", decideSearchStrategy) .addNode("prepareInvestment", prepareInvestmentSearch) .addNode("prepareMarket", prepareMarketSearch) .addNode("executeSearch", executeSearch) .addNode("visualizeResults", visualizeResults) // Define execution flow with conditional branching .addEdge(START, "decideStrategy") // Start with strategy decision .addConditionalEdges( "decideStrategy", (state: typeof VCState.State) => state.searchStrategy, // Conditional function { investment_focused: "prepareInvestment", // If investment focused -> RRF template preparation market_focused: "prepareMarket", // If market focused -> dynamic query preparation } ) .addEdge("prepareInvestment", "executeSearch") // Investment prep -> execute .addEdge("prepareMarket", "executeSearch") // Market prep -> execute .addEdge("executeSearch", "visualizeResults") // Execute -> visualize .addEdge("visualizeResults", END); // End workflow

ご覧のとおり、アプリが次にどの「パス」またはノードを実行するかを決定する条件付きエッジがあります。この特徴は、ワークフローに分岐ロジックが必要な場合、例えば複数のツールから選択する場合や、人間が関与するステップを含む場合に有用です。

LangGraph のコア機能を理解したら、コードが実行されるアプリケーションをセットアップできます。

すべてをmainメソッドで組み合わせ、ここではすべての要素をワークフロー変数下のグラフとして宣言します。

async function main() { await createIndex(); await createSearchTemplates(); await ingestDocuments(); // Create the workflow graph with shared state const workflow = new StateGraph(VCState) // Register nodes - these are the processing functions .addNode("decideStrategy", decideSearchStrategy) .addNode("prepareInvestment", prepareInvestmentSearch) .addNode("prepareMarket", prepareMarketSearch) .addNode("executeSearch", executeSearch) .addNode("visualizeResults", visualizeResults) // Define execution flow with conditional branching .addEdge(START, "decideStrategy") // Start with strategy decision .addConditionalEdges( "decideStrategy", (state: typeof VCState.State) => state.searchStrategy, // Conditional function { investment_focused: "prepareInvestment", // If investment focused -> RRF template preparation market_focused: "prepareMarket", // If market focused -> dynamic query preparation } ) .addEdge("prepareInvestment", "executeSearch") // Investment prep -> execute .addEdge("prepareMarket", "executeSearch") // Market prep -> execute .addEdge("executeSearch", "visualizeResults") // Execute -> visualize .addEdge("visualizeResults", END); // End workflow const app = workflow.compile(); await saveGraphImage(app); const query = "Find startups with Series A or Series B funding between $8M-$25M and monthly revenue above $500K"; const marketResult = await app.invoke({ input: query }); console.log(marketResult.final); }

クエリ変数は、仮想の検索バーに入力されたユーザー入力をシミュレートします。

「シリーズAまたはシリーズBの資金調達額が800万ドル～2,500万ドルで、月間収益が50万ドルを超えるスタートアップを探してください。」という自然言語フレーズから、すべてのフィルターが抽出されます。

最後にmainメソッドを呼び出します。

main().catch(console.error);

成果

🔍 Checking if index exists... 🏗️ Creating index... ✅ Index created successfully! Ingesting documents... ✅ Documents ingested successfully! ✅ Investment-focused template created successfully! ✅ Market-focused template created successfully! 📊 Workflow graph saved as: ./workflow_graph.png 🔍 Query: "Find startups with Series A or Series B funding between $8M-$25M and monthly revenue above $500K" 🤔 Search strategy: investment_focused - The query specifically seeks profitable fintech startups with defined funding amounts and high monthly revenue, which aligns closely with financial performance metrics and investment-related criteria. 💰 Preparing INVESTMENT-FOCUSED search parameters with financial emphasis... 📋 Complete query: { "size": 5, "retriever": { "rrf": { "retrievers": [ { "standard": { "query": { "semantic": { "field": "semantic_field", "query": "Find startups with Series A or Series B funding between $8M-$25M and monthly revenue above $500K" } } } }, { "standard": { "query": { "bool": { "filter": [ { "terms": { "funding_stage": [ "Series A", "Series B" ] } }, { "range": { "funding_amount": { "gte": 8000000, "lte": 25000000 } } }, { "terms": { "lead_investor": [] } }, { "range": { "monthly_revenue": { "gte": 500000, "lte": 0 } } } ] } } } } ], "rank_window_size": 100, "rank_constant": 20 } } } 🎯 Found 5 startups matching your criteria: 1. **TechFlow** 📍 San Francisco, CA | 🏢 logistics | 💼 B2B 💰 Series A - $8.0M 👥 45 employees | 📈 $500K MRR 🏦 Lead: Sequoia Capital 📝 TechFlow optimizes supply chain operations using AI-powered route optimization and real-time tracking. Founded in 2023, shows remarkable growth with $500K monthly revenue. 2. **DataViz** 📍 New York, NY | 🏢 enterprise software | 💼 B2B 💰 Series A - $10.0M 👥 42 employees | 📈 $450K MRR 🏦 Lead: Battery Ventures 📝 DataViz creates intuitive data visualization tools for enterprise customers. No-code platform allows business users to create dashboards without technical expertise. 3. **FinanceAI** 📍 San Francisco, CA | 🏢 fintech | 💼 B2C 💰 Series C - $25.0M 👥 120 employees | 📈 $1200K MRR 🏦 Lead: Tiger Global Management 📝 FinanceAI provides AI-powered investment advisory services to retail investors. Uses machine learning to analyze market trends with over 100,000 active users. 4. **UrbanMobility** 📍 New York, NY | 🏢 logistics | 💼 B2B2C 💰 Series B - $15.0M 👥 78 employees | 📈 $750K MRR 🏦 Lead: Kleiner Perkins 📝 UrbanMobility revolutionizes urban transportation through autonomous delivery drones and smart logistics hubs. Partners with major retailers for same-day delivery across Manhattan and Brooklyn. 5. **HealthTech Solutions** 📍 Boston, MA | 🏢 healthcare | 💼 B2B 💰 Series B - $18.0M 👥 95 employees | 📈 $900K MRR 🏦 Lead: General Catalyst 📝 HealthTech Solutions develops medical devices and software for remote patient monitoring. Comprehensive telehealth platform reducing hospital readmissions by 30%. ✨ Done in 18.80s.

送信された入力に対して、アプリケーションは投資に重点を置いたパスを選択し、その結果、ユーザー入力から値と範囲を抽出するLangGraphワークフローによって生成されたElasticsearchクエリを確認できます。また、抽出された値が適用された状態でElasticsearchに送信されたクエリと、最後にvisualizeResultsノードによって結果がフォーマットされた結果も確認できます。

次に、市場重視のノードを、クエリ「サンフランシスコ、ニューヨーク、ボストンのフィンテックおよびヘルスケアのスタートアップ企業を探してください」を使用してテストしてみましょう。

... 🔍 Query: Find fintech and healthcare startups in San Francisco, New York, or Boston 🤔 Search strategy: market_focused - The query is focused on finding fintech startups in San Francisco that are disrupting traditional banking and payment systems, which pertains to specific industries (fintech) and locations (San Francisco). Thus, a market-focused strategy is more appropriate. 🔍 Preparing MARKET-FOCUSED search parameters with market emphasis... 📋 Complete query: { "size": 5, "retriever": { "rrf": { "retrievers": [ { "standard": { "query": { "semantic": { "field": "semantic_field", "query": "Find fintech and healthcare startups in San Francisco, New York, or Boston" } } } }, { "standard": { "query": { "bool": { "filter": [ { "terms": { "industry": [ "fintech", "healthcare" ] } }, { "terms": { "location": [ "San Francisco, CA", "New York, NY", "Boston, MA" ] } }, { "terms": { "business_model": [] } } ] } } } } ], "rank_window_size": 50, "rank_constant": 10 } } } 🎯 Found 5 startups matching your criteria: 1. **FinanceAI** 📍 San Francisco, CA | 🏢 fintech | 💼 B2C 💰 Series C - $25.0M 👥 120 employees | 📈 $1200K MRR 🏦 Lead: Tiger Global Management 📝 FinanceAI provides AI-powered investment advisory services to retail investors. Uses machine learning to analyze market trends with over 100,000 active users. 2. **CryptoWallet** 📍 Miami, FL | 🏢 fintech | 💼 B2C 💰 Series B - $16.0M 👥 73 employees | 📈 $820K MRR 🏦 Lead: Coinbase Ventures 📝 CryptoWallet provides secure digital wallet solutions for cryptocurrency trading and storage. Multi-chain support with enterprise-grade security features. ... ✨ Done in 7.41s.

学び

執筆の過程で次のことを学びました。

LLMにフィルターの正確な値を表示する必要があります。そうしないと、ユーザーが正確な値を入力することになります。カーディナリティが低い場合はこのアプローチで問題ありませんが、カーディナリティが高い場合は結果をフィルタリングする何らかのメカニズムが必要です。
検索テンプレートを使用すると、LLMにElasticsearchクエリを記述させるよりも結果の一貫性が大幅に向上し、速度も速くなります。
条件付きエッジは、複数のバリアントと分岐パスを持つアプリケーションを構築するための強力なメカニズムです。
構造化された出力は、予測可能でタイプセーフな応答を強制するため、LLMを使用して情報を生成する場合に非常に役立ちます。これにより、信頼性が向上し、プロンプトの誤解が減少します。

ハイブリッド検索を通じてセマンティック検索と構造化検索を組み合わせることで、精度とコンテキスト理解のバランスを保ちながら、より適切で関連性の高い結果が生成されます。

まとめ

この例では、LangGraph.jsとElasticsearchを組み合わせて、自然言語クエリをElasticsearchで検索し、金融と市場のいずれかワークフローを焦点を当てた検索戦略をワークフローで決定できる動的なワークフローを作成します。このアプローチにより、手動クエリ作成の複雑さが軽減され、ベンチャーキャピタルアナリストの柔軟性と精度が向上します。

GitHubのイシューをElasticsearchでクエリするChatGPTコネクターの構築

Tomás Murúa — Mon, 01 Dec 2025 00:00:00 GMT

最近、OpenAIはPro/Business/EnterpriseおよびEduプラン向けにChatGPT向けのカスタムコネクター機能を発表しました。これは、Gmail、GitHub、Dropboxなどのデータを活用するためのすぐに使えるコネクターへの追加となります。MCPサーバーを使用してカスタムコネクターを作成できます。

カスタムコネクターを使用すると、既存のChatGPTコネクターをElasticsearchなどの追加のデータソースと組み合わせて、包括的な回答を得ることができます。

この記事では、内部のGitHubの課題とプルリクエストに関する情報を含むElasticsearchインデックスにChatGPTを接続するMCPサーバーを構築します。これにより、Elasticsearchデータを使用して自然言語クエリに回答できるようになります。

Google ColabのFastMCPとngrokを使ってMCPサーバーをデプロイし、ChatGPTが接続できる公開URLを取得し、複雑なインフラ構築の必要性を排除します。

MCPとそのエコシステムの包括的な概要については、MCPの現在の状態をご参照ください。

要件

始める前に必要なものは次のとおりです。

Elasticsearchクラスター（8.X以降）
インデックスへの読み取りアクセス権を持つ Elasticsearch APIキー
Googleアカウント（Google Colab用）
Ngrokアカウント（無料プランでも可）
Pro/Enterprise/BusinessまたはEduプランのChatGPTアカウント

ChatGPT MCPコネクターの要件を理解する

ChatGPT MCPコネクターには、searchとfetchの2つのツールを実装する必要があります。詳細については、OpenAIドキュメントをご覧ください。

検索ツール

ユーザークエリに基づいて、Elasticsearchインデックスから関連する結果のリストを返します。

受け取るもの：

ユーザーの自然言語クエリを含む単一の文字列。
例：「Elasticsearch移行に関連するイシューを見つけて」

返されるもの：

結果オブジェクトの配列を含むresultキーを持つオブジェクト。各結果には以下が含まれます。
- id - 一意の文書識別子
- title - イシューまたはPRタイトル
- url - イシュー/PRへのリンク

実装内容：

return { "results": [ { "id": "PR-612", "title": "Fix memory leak in WebSocket notification service", "url": "https://internal-git.techcorp.com/pulls/612" }, # ... more results ] }

フェッチ・ツール

特定の文書の完全な内容を取得します。

受け取るもの：

検索結果からElasticsearch文書IDを入力する単一の文字列
例：「PR-578の詳細を教えてください。」

返されるもの：

以下を含む完全な文書オブジェクト：
- id - 一意の文書識別子
- title - イシューまたはPRタイトル
- text - 完全なイシュー・PRの説明と詳細
- url - イシュー/PRへのリンク
- type - 文書の種類（issue, pull_request）
- status - 現在のステータス（open, in_progress, resolved）
- priority - 優先度レベル（low, medium, high, critical）
- assignee - イシュー/PRの担当者
- created_date - 作成された時期
- resolved_date - 解決された時期（該当する場合）
- labels 文書に関連するタグ
- related_pr - 関連するプルリクエストID

return { "id": "PR-578", "title": "Security hotfix: Patch SQL injection vulnerabilities", "text": "Description: CRITICAL SECURITY FIX for ISSUE-1889. Patches SQL...", "url": "https://internal-git.techcorp.com/pulls/578", "type": "pull_request", "status": "closed", "priority": "critical", "assignee": "sarah_dev", "created_date": "2025-09-19", "resolved_date": "2025-09-19", "labels": "security, hotfix, sql", "related_pr": null }

注：この例では、すべてのフィールドがルートレベルにあるフラット構造を使用しています。OpenAIの要件は柔軟で、ネストされたメタデータオブジェクトもサポートしています。

GitHubのデータセットとプルリクエストデータセット

このチュートリアルでは、イシューとプルリクエストを含む内部GitHubデータセットを使用します。これは、ChatGPTを通じてプライベートな内部データをクエリするシナリオを表しています。

データセットはこちらからご覧いただけます。そして、Bulk APIを使ってデータのインデックスを更新します。

このデータセットには以下が含まれます。

説明、ステータス、優先順位、担当者に関する問題
コード変更、レビュー、導入情報を含むプルリクエスト
イシューとPRの関係（例：PR-578がISSUE-1889を修正）
ラベル、日付、その他のメタデータ

インデックスマッピング

インデックスは、ELSERとのハイブリッド検索をサポートするために以下のマッピングを使用します。text_semanticはセマンティック検索に使用され、他のフィールドはキーワード検索を可能にします。

{ "mappings": { "properties": { "id": { "type": "keyword" }, "title": { "type": "text" }, "text": { "type": "text" }, "text_semantic": { "type": "semantic_text", "inference_id": ".elser-2-elasticsearch" }, "url": { "type": "keyword" }, "type": { "type": "keyword" }, "status": { "type": "keyword" }, "priority": { "type": "keyword" }, "assignee": { "type": "keyword" }, "created_date": { "type": "date", "format": "iso8601" }, "resolved_date": { "type": "date", "format": "iso8601" }, "labels": { "type": "keyword" }, "related_pr": { "type": "keyword" } } } }

MCPサーバーを構築する

当社のMCPサーバーは、OpenAI仕様に従って2つのツールを実装しています。ハイブリッド検索を使用してセマンティックマッチングとテキストマッチングを組み合わせることで、より良い結果が得られます。

検索ツール

RRF（相互ランク融合）を用いたハイブリッド検索を使用し、セマンティック検索とテキストマッチングを組み合わせています。

@mcp.tool() async def search(query: str) -> Dict[str, List[Dict[str, Any]]]: """ Search for internal issues and PRs using hybrid search (semantic + text with RRF). Returns list with id, title, and url per OpenAI spec. """ if not query or not query.strip(): return {"results": []} logger.info(f"Searching for: '{query}'") try: # Hybrid search with RRF (Reciprocal Rank Fusion) response = es_client.search( index=ELASTICSEARCH_INDEX, size=10, source=["id", "title", "url", "type", "priority"], retriever={ "rrf": { "retrievers": [ { # Semantic search with ELSER "standard": { "query": { "semantic": { "field": "text_semantic", "query": query } } } }, { # Text search (BM25) for keyword matching "standard": { "query": { "multi_match": { "query": query, "fields": [ "title^3", "text^2", "assignee^2", "type", "labels", "priority" ], "type": "best_fields", "fuzziness": "AUTO" } } } } ], "rank_window_size": 50, "rank_constant": 60 } } ) results = [] if response and 'hits' in response: for hit in response['hits']['hits']: source = hit['_source'] results.append({ "id": source.get('id', hit['_id']), "title": source.get('title', 'Unknown'), "url": source.get('url', '') }) logger.info(f"Found {len(results)} results") return {"results": results} except Exception as e: logger.error(f"Search error: {e}") raise ValueError(f"Search failed: {str(e)}")

主なポイント：

RRFを用いたハイブリッド検索： より良い結果を得るために、セマンティック検索（ELSER）とテキスト検索（BM25）を組み合わせます。
複数一致クエリ：ブースティングを使用して複数のフィールドを検索します（title^3, text^2, assignee^2）。キャレット記号（^）は関連性スコアを乗算し、コンテンツよりもタイトルの一致を優先します。
あいまい一致： fuzziness: AUTO は近似一致を許可することでタイプミスやスペルミスを処理します。
RRFのパラメーター調整：
- rank_window_size: 50 - マージする前に、各リトリーバー（セマンティックとテキスト）からの上位結果をいくつ考慮するかを指定します。
- rank_constant: 60 - この値は、個々の結果セット内の文書が最終的なランク付け結果にどの程度影響を与えるかを決定します。
必須フィールドのみを返す： id、title、urlはOpenAIの仕様に従い、追加のフィールドを不必要に公開しないようにします。

フェッチ・ツール

文書IDが存在する場合は、そのIDで文書の詳細を取得します。

@mcp.tool() async def fetch(id: str) -> Dict[str, Any]: """ Retrieve complete issue/PR details by ID. Returns id, title, text, url. """ if not id: raise ValueError("ID is required") logger.info(f"Fetching: {id}") try: # Search by the 'id' field (not _id) since IDs are stored as a field response = es_client.search( index=ELASTICSEARCH_INDEX, body={ "query": { "term": { "id": id # Search by your custom 'id' field } }, "size": 1 } ) if not response or not response['hits']['hits']: raise ValueError(f"Document with id '{id}' not found") hit = response['hits']['hits'][0] source = hit['_source'] result = { "id": source.get('id', id), "title": source.get('title', 'Unknown'), "text": source.get('text', ''), "url": source.get('url', ''), "type": source.get('type', ''), "status": source.get('status', ''), "priority": source.get('priority', ''), "assignee": source.get('assignee', ''), "created_date": source.get('created_date', ''), "resolved_date": source.get('resolved_date', ''), "labels": source.get('labels', ''), "related_pr": source.get('related_pr', '') } logger.info(f"Fetched: {result['title']}") return result except Exception as e: logger.error(f"Fetch error: {e}") raise ValueError(f"Failed to fetch '{id}': {str(e)}")

主なポイント：

文書IDのフィールドで検索：カスタム idフィールドに用語クエリを使用します
完全な文書を返す： すべてのコンテンツを含む完全なtextフィールドが含まれます
フラットな構造：すべてのフィールドがルートレベルにあり、Elasticsearchのドキュメント構造に一致します。

Google Colabにデプロイする

Google Colabを使用してMCPサーバーを実行し、ngrokで公開することで、ChatGPTが接続できるようにします。

ステップ1：Google Colabノートブックを開く

事前設定されたノートブックElasticsearch MCP for ChatGPTにアクセスします。

ステップ2：認証情報を設定する

次の3つの情報が必要になります。

Elasticsearch URL：お客様のElasticsearchクラスタリングURL。
Elasticsearch API キー：インデックスへの読み取りアクセス権を持つAPIキー。
Ngrok認証トークン：ngrokからの無料トークン。ngrokを使ってMCPのURLをインターネットに公開し、ChatGPTが接続できるようにします。

ngrokトークンの取得

ngrokで無料アカウントに登録します。
ngrokダッシュボードにアクセスします。
認証トークンをコピーします。

Google Colabにシークレットを追加する

Google Colabノートブック内で：

左側のサイドバーにあるキーアイコンをクリックして、シークレットを開きます。
次の3つのシークレットを追加します。

ELASTICSEARCH_URL=https://your-cluster.elastic.com:443 ELASTICSEARCH_API_KEY=your-api-key NGROK_TOKEN=your-ngrok-token

3. 各シークレットのノートブックアクセスを有効にします。

ステップ3：ノートブックを実行する

ランタイムをクリックし、次にすべて実行をクリックして、すべてのセルを実行します。
サーバーの起動を待ちます（約30秒）。
公開ngrok URLを示す出力を探します。

4. 出力は次のようになります。

ChatGPTに接続する

次に、MCPサーバーをあなたのChatGPTアカウントに接続します。

ChatGPTを開き、設定に移動します。
コネクターに移動します。Proアカウントを使用している場合は、コネクタで開発者モードをオンにする必要があります。

ChatGPT EnterpriseまたはBusinessを使用している場合は、コネクターを職場に公開する必要があります。

3. 作成をクリックします。

注：Business、Enterprise、Eduワークスペースでは、ワークスペースの所有者、管理者、およびそれぞれの設定が有効になっているユーザー（Enterprise/Eduの場合）のみがカスタムコネクターを追加できます。通常のメンバーロールのユーザーには、自分でカスタムコネクターを追加する権限がありません。

コネクターが所有者または管理者ユーザーによって追加され有効化されると、ワークスペースのすべてのメンバーが使用できるようになります。

4. 必要な情報と、/sse/で終わるngrokのURLを入力します。「sse」の後の「/」に注意してください。これがない場合、動作しません。

Name: Elasticsearch MCP
Description: GitHubの内部情報を検索および取得するためのカスタムMCP。

5. 作成を押してカスタムMCPを保存します。

サーバーが稼働していれば、接続は瞬時に完了します。追加の認証は不要で、Elasticsearch APIキーはサーバー上で設定されています。

MCPサーバーをテストする

質問する前に、ChatGPTが使用するコネクターを選択する必要があります。

プロンプト1：イシューを検索する

「Elasticsearchの移行に関連するイシューを見つけて」と質問し、アクションツールの呼び出しを確認します。

ChatGPT はクエリを使用してsearchツールを呼び出します。利用可能なツールを検索し、Elasticsearchツールを呼び出す準備をし、ツールに対して何らかのアクションを実行する前にユーザーに確認していることがわかります。

ツール呼び出しリクエスト：

{ "query": "Elasticsearch migration issues" }

ツールの応答：

{ "results": [ { "id": "PR-598", "title": "Elasticsearch 8.x migration - Application code changes", "url": "https://internal-git.techcorp.com/pulls/598" }, { "id": "ISSUE-1712", "title": "Migrate from Elasticsearch 7.x to 8.x", "url": "https://internal-git.techcorp.com/issues/1712" }, { "id": "RFC-045", "title": "Design Proposal: Microservices Migration Architecture", "url": "https://internal-git.techcorp.com/rfcs/045" } // ... 7 more results ] }

ChatGPTは結果を処理し、自然で会話的な形式で提示します。

仕組み

プロンプト：「Elasticsearch移行に関連するイシューを見つけて」

1. ChatGPTの呼び出し search(“Elasticsearch migration”)

2. Elasticsearchがハイブリッド検索を実行する

セマンティック検索は「アップグレード」や「バージョン互換性」などの概念を理解します。
テキスト検索で「Elasticsearch」と「migration」の完全一致を見つけます。
RRFは両方のアプローチの結果を組み合わせてランク付けします。

3. id、titleを含むトップ10のマッチングイベントを返します。 url

4. ChatGPTは「ISSUE-1712: migrate from Elasticsearch 7.x to 8.x」を最も関連性の高い結果として特定します。

プロンプト2：完全な詳細を取得する

質問：「ISSUE-1889の詳細を教えて」

ChatGPTは、あなたが特定のイシューに関する詳細な情報を求めていることを認識し、fetchツールを呼び出し、ツールに対して何らかのアクションを起こす前にユーザーに確認します。

ツール呼び出しリクエスト：

{ "id": "ISSUE-1889" }

ツールの応答：

{ "id": "ISSUE-1889", "title": "SQL injection vulnerability in search endpoint", "text": "Description: Security audit identified SQL injection vulnerability in /api/v1/search endpoint. User input from query parameter is not properly sanitized before being used in raw SQL query. Severity: HIGH - Immediate action required Affected Code: - File: services/search/query_builder.py - Line: 145-152 - Issue: String concatenation used instead of parameterized queries Investigation: - @security_team_alice: Confirmed exploitable with UNION-based injection - @sarah_dev: Checking all other endpoints for similar patterns - @john_backend: Found 3 more instances in legacy codebase Remediation: - Rewrite using SQLAlchemy ORM or parameterized queries - Add input validation and sanitization - Implement WAF rules as additional layer - Security regression tests Comments: - @tech_lead_mike: Stop all other work, this is P0 - @sarah_dev: PR-578 ready with fixes for all 4 vulnerable endpoints - @alex_devops: Deployed hotfix to production 2025-09-19 at 14:30 UTC - @security_team_alice: Verified fix, conducting full pentest next week Resolution: All vulnerable endpoints patched. Added pre-commit hooks to catch raw SQL queries. Security training scheduled for team.", "url": "https://internal-git.techcorp.com/issues/1889", "type": "issue", "status": "closed", "priority": "critical", "assignee": "sarah_dev", "created_date": "2025-09-18", "resolved_date": "2025-09-19", "labels": "security, vulnerability, bug, sql", "related_pr": "PR-578" }

ChatGPTは情報を統合し、明確に提示します。

仕組み

プロンプト：「ISSUE-1889の詳細を教えて」

ChatGPT呼び出し fetch(“ISSUE-1889”)
Elasticsearchが完全な文書を取得する
すべてのフィールドがルートレベルにある完全な文書を返す
ChatGPTは情報を統合し、適切な引用で回答する

まとめ

この記事では、専用の検索およびフェッチMCPツールを使用してChatGPTをElasticsearchに接続するカスタムMCPサーバーを構築し、プライベートデータに対する自然言語クエリを可能にしました。

このMCPパターンは、自然言語を使用してクエリしたい任意のElasticsearchインデックス、ドキュメント、製品、ログ、またはその他のデータで機能します。

LangChainとElasticsearchを使用したエージェントRAGアシスタントの開発

Kirti Sodhi — Fri, 28 Nov 2025 00:00:00 GMT

このブログ記事では、エージェント RAG ワークフローについて詳しく説明し、その主な機能と一般的な設計パターンについて説明します。さらに、Elasticsearch をベクターストアとして使用し、LangChain を使用してエージェント RAG フレームワークを構築する実践的な例を通じて、これらのワークフローを実装する方法を示します。最後に、この記事では、このようなアーキテクチャの設計と実装に関連するベストプラクティスと課題について簡単に説明します。このJupyter ノートブックに従って、シンプルなエージェント RAG パイプラインを作成できます。

エージェントRAGの紹介

検索拡張生成 ( RAG ) は LLM ベースのアプリケーションの基礎となり、モデルがユーザーのクエリに基づいて関連するコンテキストを取得することで最適な回答を提供できるようになりました。RAG システムは、事前にトレーニングされた LLM 知識に限定されるのではなく、API またはデータストアからの外部情報を利用することで、LLM 応答の精度とコンテキストを強化します。一方、AI エージェントは自律的に動作し、指定された目的を達成するために意思決定とアクションを実行します。

Agentic RAG は、検索強化生成とエージェント推論の両方の長所を統合したフレームワークです。RAG をエージェントの意思決定プロセスに統合することで、システムはデータソースを動的に選択し、クエリを改良してコンテキスト検索を改善し、より正確な応答を生成し、フィードバックループを適用して出力品質を継続的に向上できるようになります。

エージェントRAGの主な特徴

エージェント RAG フレームワークは、従来の RAG システムに比べて大きな進歩を遂げています。固定された検索プロセスに従うのではなく、結果をリアルタイムで計画、実行、最適化できる動的エージェントを活用します。

エージェント RAG パイプラインを区別する主な機能のいくつかを見てみましょう。

動的な意思決定: Agentic RAG は推論メカニズムを使用してユーザーの意図を理解し、各クエリを最も関連性の高いデータソースにルーティングして、正確でコンテキストに応じた応答を生成します。
包括的なクエリ分析: Agentic RAG は、サブ質問とその全体的な意図を含むユーザークエリを詳細に分析します。クエリの複雑さを評価し、最も関連性の高いデータソースを動的に選択して情報を取得し、正確で完全な応答を保証します。
多段階コラボレーション: このフレームワークは、専門エージェントのネットワークを通じて多段階コラボレーションを可能にします。各エージェントは、より大きな目標の特定の部分を担当し、一貫した結果を達成するために順次または同時に作業します。
自己評価メカニズム: エージェント RAG パイプラインは、自己反映を使用して、取得したドキュメントと生成された応答を評価します。取得した情報がクエリに完全に対応しているかどうかを確認し、出力の正確性、完全性、事実の一貫性を確認できます。
外部ツールとの統合: このワークフローは、外部 API、データベース、リアルタイム情報ソースと対話して、最新の情報を取り込み、進化するデータに動的に適応できます。

エージェントRAGのワークフローパターン

ワークフローパターンは、エージェント AI が LLM ベースのアプリケーションを信頼性と効率性をもって構築、管理、調整する方法を定義します。LangChain 、 LangGraph 、 CrewAI 、 LlamaIndexなどのいくつかのフレームワークとプラットフォームを使用して、これらのエージェントワークフローを実装できます。

順次取得チェーン: 順次ワークフローは、複雑なタスクを単純な順序付けられたステップに分割します。各ステップで次のステップの入力が改善され、より良い結果が得られます。たとえば、顧客プロファイルを作成する場合、1 人のエージェントが CRM から基本的な詳細を取得し、別のエージェントがトランザクションデータベースから購入履歴を取得し、最後のエージェントがこの情報を組み合わせて推奨事項やレポート用の完全なプロファイルを生成します。
ルーティング取得チェーン: このワークフローパターンでは、ルーターエージェントが入力を分析し、最も適切なプロセスまたはデータソースに送信します。このアプローチは、重複が最小限で複数の異なるデータソースが存在する場合に特に効果的です。たとえば、顧客サービスシステムでは、ルータエージェントが技術的な問題、払い戻し、苦情などの受信リクエストを分類し、適切な部門にルーティングして効率的に処理します。
並列検索チェーン: このワークフローパターンでは、複数の独立したサブタスクが同時に実行され、それらの出力が後で集約されて最終的な応答が生成されます。このアプローチにより、処理時間が大幅に短縮され、ワークフローの効率が向上します。たとえば、顧客サービスの並列ワークフローでは、1 人のエージェントが過去の同様のリクエストを取得し、別のエージェントが関連するナレッジベースの記事を参照します。アグリゲータはこれらの出力を組み合わせて包括的な解決策を生成します。
オーケストレーターワーカーチェーン: このワークフローは、独立したサブタスクを利用するため、並列化と類似点があります。ただし、重要な違いはオーケストレーターエージェントの統合にあります。このエージェントは、ユーザークエリを分析し、実行時にそれらをサブタスクに動的に分割し、正確な応答を作成するために必要な適切なプロセスまたはツールを識別する役割を担います。

エージェントRAGパイプラインをゼロから構築する

エージェント RAG の原理を説明するために、LangChain と Elasticsearch を使用してワークフローを設計してみましょう。このワークフローはルーティングベースのアーキテクチャを採用しており、複数のエージェントが連携してクエリを分析し、関連情報を取得し、結果を評価し、一貫した応答を生成します。この例に従うには、このJupyter ノートブックを参照してください。

ワークフローはルータエージェントから開始され、ルータエージェントはユーザーのクエリを分析して最適な取得方法 ( vectorstore 、 websearch 、またはcompositeのいずれかのアプローチ) を選択します。ベクターストアは従来の RAG ベースのドキュメント検索を処理し、Web 検索はベクターストアに保存されていない最新の情報を取得し、複合アプローチは複数のソースからの情報が必要な場合に両方を組み合わせます。

ドキュメントが適切であると判断された場合、要約エージェントは明確で文脈に適した応答を生成します。ただし、ドキュメントが不十分または無関係な場合、クエリ書き換えエージェントはクエリを再作成して検索を改善します。この修正されたクエリによりルーティングプロセスが再開され、システムは検索を絞り込み、最終出力を強化できるようになります。

要件

このワークフローは、例を効果的に実行するために次のコアコンポーネントに依存しています。

Python 3.10
Jupyterノートブック
Azure OpenAI
Elasticsearch
LangChain

続行する前に、この例に必要な次の環境変数のセットを構成するように求められます。

AZURE_OPENAI_ENDPOINT="Add your azure openai endpoint" AZURE_OPENAI_KEY="Add your azure openai key" AZURE_OPENAI_DEPLOYMENT="gpt-4.1" AZURE_OPENAI_API_VERSION="Add your azure openai api version" ES_ENDPOINT = "Add your Elasticsearch ENDPOINT" ES_API_KEY = "Add your Elasticsearch API KEY"

データソース

このワークフローは、AG ニュースデータセットのサブセットを使用して説明されています。このデータセットは、国際、スポーツ、ビジネス、科学技術など、さまざまなカテゴリのニュース記事で構成されています。

dataset = load_dataset("ag_news", split="train[:1000]") docs = [ Document( page_content=sample["text"], metadata={"category": sample["label"]} ) for sample in dataset ]

ElasticsearchStore モジュールは、 langchain_elasticsearchからベクターストアとして利用されます。検索には、Elastic 独自の埋め込みモデルであるELSERを採用した SparseVectorStrategy を実装します。ベクターストアを開始する前に、ELSER モデルが Elasticsearch 環境に正しくインストールされ、デプロイされていることを確認することが重要です。

elastic_vectorstore = ElasticsearchStore.from_documents( docs, es_url=ES_ENDPOINT, es_api_key=ES_API_KEY, index_name=index_name, strategy=SparseVectorStrategy(model_id=".elser_model_2"), ) elastic_vectorstore.client.indices.refresh(index=index_name)

Web 検索機能は、LangChain コミュニティツールのDuckDuckGoSearchRunを使用して実装されており、これによりシステムは Web からライブ情報を効率的に取得できます。より関連性の高い結果を提供できる他の検索 API の使用も検討できます。このツールは、API キーを必要とせずに検索できるため選択されました。

duckduckgo = DuckDuckGoSearchRun(description= "A custom DuckDuckGo search tool for finding latest news stories.", verbose=True) def websearch_retriever(query): results = duckduckgo.run(f"{query}") return results

複合リトリーバーは、ソースの組み合わせを必要とするクエリ用に設計されています。これは、Web からリアルタイムデータを取得すると同時に、ベクターストアから過去のニュースを参照することで、包括的かつ文脈的に正確な応答を提供するために使用されます。

def composite_retriever(query): related_docs = vectorstore_retriever(query) related_docs += websearch_retriever(query) return related_docs

エージェントの設定

次のステップでは、このワークフロー内で推論および意思決定機能を提供する LLM エージェントが定義されます。作成する LLM チェーンには、 router_chain 、 grade_docs_chain 、 rewrite_query_chain 、 summary_chainが含まれます。

ルータエージェントは LLM アシスタントを使用して、実行時に特定のクエリに最適なデータソースを決定します。グレーディングエージェントは、取得したドキュメントの関連性を評価します。ドキュメントが関連していると判断された場合、それらは要約エージェントに渡され、要約が生成されます。それ以外の場合、書き換えクエリエージェントはクエリを再作成し、別の取得を試行するためにルーティングプロセスに送り返します。すべてのエージェントの手順は、ノートブックの LLM チェーンセクションに記載されています。

class RouteQuery(BaseModel): datasource: Literal["vectorstore", "websearch", "composite"] = Field( ..., description="Choose to route the query to web search, vectorstore or composite." ) router_prompt = ChatPromptTemplate.from_template("""You are an assistant that decides the best data source for questions based on news articles. Choose one of the following options: - 'vectorstore': for general, background, or historical news articles. - 'websearch': for recent discoveries, 'latest', 'current', or '2025' type queries. - 'composite': when the question needs both historical and current knowledge on news articles. Question: {query} Return one word: 'vectorstore', 'websearch', or 'composite'. """) router_structured = llm.with_structured_output(RouteQuery) router_chain: RunnableSequence = router_prompt | router_structured

llm.with_structured_outputは、モデルの出力をRouteQueryクラスの BaseModel によって定義された定義済みスキーマに従うように制限し、結果の一貫性を保証します。2 行目は、 router_promptとrouter_structuredを接続してRunnableSequenceを構成し、入力プロンプトが言語モデルによって処理され、構造化されたスキーマ準拠の結果が生成されるパイプラインを形成します。

グラフノードを定義する

この部分では、システムのさまざまなコンポーネント間を流れるデータを表すグラフの状態を定義します。これらの状態を明確に指定することで、ワークフロー内の各ノードがアクセスおよび更新できる情報を確実に認識できるようになります。

class RAGState(TypedDict): query: str docs: List[Document] router: str summary: str self_reflection: bool retry_count: int = 0

状態が定義されたら、次のステップはグラフのノードを定義することです。ノードは、データに対して特定の操作を実行するグラフの機能単位のようなものです。パイプラインには 7 つの異なるノードがあります。

def router(state: RAGState): router = router_chain.invoke({'query': state["query"]}) logger.info(f"Router selected the datasource: {router.datasource}") logger.info(f"User query: {state['query']}") return {"router": router.datasource} def vectorstore(state: RAGState): return {"docs": vectorstore_retriever(state["query"])} def websearch(state: RAGState): return {"docs": websearch_retriever(state["query"])} def composite(state: RAGState): return {"docs": composite_retriever(state["query"])} def self_reflection(state: RAGState): evaluation = grade_docs_chain.invoke( {"query": state["query"], "docs": state["docs"]} ) if evaluation.binary_score: logger.info(f"Self-reflection passed -- binary_score={evaluation.binary_score}") else: logger.info(f"Self-reflection failed -- binary_score={evaluation.binary_score}") return { "self_reflection": evaluation.binary_score, } def query_rewriter(state: RAGState): retry_count = state.get("retry_count", 0) + 1 new_query = rewrite_query_chain.invoke({"query": state["query"]}) logger.info(f"Query rewritten: {new_query}, retry_count: {retry_count}") return { "query": new_query, "retry_count": retry_count, } def summarize(state: RAGState): summary = summarize_chain.run( query=state["query"], docs=state["docs"], ) return {"summary": summary}

query_rewriterノードはワークフロー内で 2 つの目的を果たします。まず、自己反省エージェントによって評価された文書が不十分または無関係であると判断された場合に、 rewrite_query_chainを使用してユーザークエリを書き換え、検索を改善します。2 番目に、クエリが書き換えられた回数を追跡するカウンターとして機能します。

ノードが呼び出されるたびに、ワークフロー状態に格納されているretry_countが増加します。このメカニズムにより、ワークフローが無限ループに陥るのを防ぎます。retry_countが事前定義されたしきい値を超えた場合、システムはエラー状態、デフォルトの応答、または選択したその他の定義済み条件にフォールバックできます。

グラフのコンパイル

最後のステップは、グラフのエッジを定義し、コンパイルする前に必要な条件を追加することです。すべてのグラフは、ワークフローのエントリポイントとして機能する指定された開始ノードから開始する必要があります。グラフ内のエッジはノード間のデータの流れを表し、次の 2 つのタイプがあります。

直線エッジ: 1 つのノードから別のノードへの直接的で無条件のフローを定義します。最初のノードがタスクを完了すると、ワークフローは直線に沿って次のノードに自動的に進みます。
条件付きエッジ: これにより、現在の状態またはノードの計算結果に基づいてワークフローを分岐できます。次のノードは、評価結果、ルーティングの決定、再試行回数などの条件に応じて動的に選択されます。

graph.add_edge(START, "router") def after_router(state: RAGState): route = state.get("router", None) if route == "vectorstore": return "vectorstore" elif route == "websearch": return "websearch" else: return "composite" def after_self_reflection(state: RAGState): if state["self_reflection"]: return "summarize" return "query_rewriter" def after_query_rewriter(state: RAGState): while state['retry_count'] <= 3: return "router" raise RuntimeError("Maximum retries (3) reached -- evaluation failed.") graph.add_conditional_edges( "router", after_router, { "vectorstore": "vectorstore", "websearch": "websearch", "composite": "composite" } ) graph.add_edge("vectorstore", "self_reflection") graph.add_edge("websearch", "self_reflection") graph.add_edge("composite", "self_reflection") graph.add_conditional_edges( "self_reflection", after_self_reflection, { "summarize": "summarize", "query_rewriter": "query_rewriter" } ) graph.add_conditional_edges("query_rewriter", after_query_rewriter, {"router": "router"}) graph.add_edge("summarize", END) agent=graph.compile()

これで、最初のエージェント RAG パイプラインの準備が整い、コンパイルされたエージェントを使用してテストできるようになります。

result = agent.invoke({"query": query1}) logger.info(f"\nFinal Summary:\n: {result['summary']}")

エージェントRAGパイプラインのテスト

次に、以下の 3 つの異なるタイプのクエリを使用してこのパイプラインをテストします。結果は異なる場合があり、以下に示す例は潜在的な結果の 1 つを示しているにすぎないことに注意してください。

query1="What are the latest AI models released this month?" query2="What technological innovations are discussed in Sci/Tech news?" query3="Compare a Sci/Tech article from the dataset with a current web article about AI trends."

最初のクエリでは、ルータはデータソースとしてwebsearchを選択します。クエリは自己反映評価に失敗し、出力に示されているように、その後クエリ書き換えステージにリダイレクトされます。

INFO | __main__:router:11 - Router selected the datasource: websearch INFO | __main__:router:12 - User query: What are the latest AI models released this month? Latest Singapore news, including the city state's relationships with Malaysia and Mahathir, China and Xi Jinping, and the rest of Southeast Asia. 3 days ago · The latest military news, insights and analysis from China. All the latest news, opinions and analysis on Hong Kong, China, Asia and around the world Latest news, in-depth features and opinion on Malaysia, covering politics, economy, society and the Asean member-nation's relationships with China, Singapore, and other Southeast Asian ... Oct 12, 2025 · Brics (an acronym for Brazil, Russia, India, China and South Africa) refers to an association of 10 leading emerging markets. The other member states are Egypt, Ethiopia, ... INFO | __main__:self_reflection:31 - Self-reflection failed -- binary_score=False INFO | __main__:query_rewriter:40 - Query rewritten: query='Which AI models have been officially released in June 2024?', retry_count: 1 INFO | __main__:router:11 - Router selected the datasource: websearch INFO | __main__:router:12 - User query: query='Which AI models have been officially released in June 2024?' Dream Machine is a text-to-video model created by Luma Labs and launched in June 2024 . It generates video output based on user prompts or still images. Dream Machine has been noted for its ability to realistically capture motion... Released in June 2023. In June 2024 , Baidu announced Ernie 4.0 Turbo. In April 2025, Ernie 4.5 Turbo and X1 Turbo were released . These models are optimized for faster response times and lower operational costs.[28][29]. The meaning of QUERY is question, inquiry. How to use query in a sentence. Synonym Discussion of Query. QUERY definition: 1. a question, often expressing doubt about something or looking for an answer from an authority.... Learn more. Query definition: a question; an inquiry.. See examples of QUERY used in a sentence. INFO | __main__:self_reflection:29 - Self-reflection passed -- binary_score=True INFO | __main__::2 - Final Summary: : In June 2024, two AI models were officially released: Dream Machine, a text-to-video model launched by Luma Labs, and Ernie 4.0 Turbo, announced by Baidu, which is optimized for faster response times and lower operational costs.

次に、2 番目のクエリで示されているように、 vectorstore検索が使用される例を調べます。

INFO | __main__:router:11 - Router selected the datasource: vectorstore INFO | __main__:router:12 - User query: What technological innovations are discussed in Sci/Tech news? INFO | __main__:self_reflection:29 - Self-reflection passed -- binary_score=True INFO | __main__::2 - Final Summary: : Recent Sci/Tech news highlights several technological innovations: NASA is collaborating with Silicon Valley firms to build a powerful Linux-based supercomputer to support theoretical research and shuttle engineering; new chromatin transfer techniques have enabled the cloning of cats; cybersecurity advancements are being discussed in relation to protecting personal technology; Princeton University scientists assert that existing technologies can be used immediately to stabilize global warming; and a set of GameBoy micro-games has been recognized for innovation in game design.

最後のクエリは、ベクターストアと Web 検索の両方を活用する複合検索に向けられます。

INFO | __main__:router:11 - Router selected the datasource: composite INFO | __main__:router:12 - User query: Compare a Sci/Tech article from the dataset with a current web article about AI trends. Atlas currently only available on macOS, built on Chromium with planned features like ad-blocking still in development. OpenAI's Atlas browser launched with bold promises of AI -powered web browsing, but early real-world testing reveals a different story. Career-long data are updated to end-of-2024 and single recent year data pertain to citations received during calendar year 2024. The selection is based on the top 100,000 scientists by c-score (with and without self-citations) or a percentile rank of 2% or above in the sub-field. In this article I list 45 AI tools across 21 different categories. After exploring all the available options in each category, I've carefully selected the best tools based on my personal experience. Reading a complex technical article ? Simply highlight confusing terminology and ask "what's this?" to receive instant explanations. compare browsers. Comparison showing traditional browser navigation versus OpenAI Atlas AI -powered workflows. After putting Gemini, ChatGPT, Grok, and DeepSeek through rigorous testing in October 2025, it's clear that there isn't one AI that reigns supreme across all categories. INFO | __main__:self_reflection:29 - Self-reflection passed -- binary_score=True INFO | __main__::2 - Final Summary: : A Sci/Tech article from the dataset highlights NASA's development of robust artificial intelligence software for planetary rovers, aiming to make them more self-reliant and capable of decision-making during missions. In contrast, a current web article about AI trends focuses on the proliferation of AI-powered tools across various categories, including browsers like OpenAI Atlas, and compares leading models such as Gemini, ChatGPT, Grok, and DeepSeek, noting that no single AI currently excels in all areas. While the NASA article emphasizes specialized AI applications for autonomous robotics in space exploration, the current trends article showcases the broadening impact of AI across consumer and professional technologies, with ongoing competition and rapid innovation among major AI platforms.

上記のワークフローでは、エージェント RAG は、ユーザークエリの情報を取得するときに使用するデータソースをインテリジェントに決定し、応答の精度と関連性を向上させます。追加の例を作成してエージェントをテストし、出力を確認して興味深い結果が得られるかどうかを確認できます。

エージェント型 RAG ワークフローを構築するためのベストプラクティス

エージェント RAG の仕組みがわかったので、次にこれらのワークフローを構築するためのベストプラクティスをいくつか見てみましょう。これらのガイドラインに従うことで、システムを効率的に維持し、保守を容易にすることができます。

フォールバックの準備: ワークフローのいずれかのステップが失敗するシナリオに備えて、事前にフォールバック戦略を計画します。これらには、デフォルトの回答を返すこと、エラー状態をトリガーすること、代替ツールを使用することなどが含まれます。これにより、全体的なワークフローを中断することなく、システムが障害を適切に処理できるようになります。
包括的なログ記録を実装する: 再試行、生成された出力、ルーティングの選択、クエリの書き換えなど、ワークフローの各段階でログ記録を実装してみます。これらのログは、透明性の向上、デバッグの容易化、プロンプト、エージェントの動作、および取得戦略の継続的な改善に役立ちます。
適切なワークフローパターンを選択する: ユースケースを調べて、ニーズに最適なワークフローパターンを選択します。ステップごとの推論には順次ワークフローを使用し、独立したデータソースには並列ワークフローを使用し、複数のツールや複雑なクエリにはオーケストレーターワーカーパターンを使用します。
評価戦略を組み込む: ワークフローのさまざまな段階で評価メカニズムを統合します。これらには、自己反省エージェント、取得したドキュメントの採点、自動品質チェックなどが含まれます。評価は、取得されたドキュメントが関連性があり、応答が正確であり、複雑なクエリのすべての部分が処理されていることを確認するのに役立ちます。

課題

エージェント RAG システムは、適応性、精度、動的推論の点で大きな利点を提供しますが、設計および実装の段階で対処する必要がある特定の課題も伴います。主な課題は次のとおりです。

複雑なワークフロー: エージェントと決定ポイントが追加されるにつれて、全体的なワークフローはますます複雑になります。これにより、実行時にエラーや障害が発生する可能性が高くなります。可能な限り、冗長なエージェントと不要な意思決定ポイントを排除して、合理化されたワークフローを優先します。
スケーラビリティ: 大規模なデータセットと大量のクエリを処理するためにエージェント RAG システムを拡張するのは難しい場合があります。効率的なインデックス作成、キャッシュ、分散処理戦略を組み込んで、大規模なパフォーマンスを維持します。
オーケストレーションと計算オーバーヘッド: 複数のエージェントによるワークフローの実行には、高度なオーケストレーションが必要です。これには、ボトルネックや競合を防ぐための慎重なスケジュール設定、依存関係の管理、エージェントの調整が含まれますが、これらはすべてシステム全体の複雑さを増大させます。
評価の複雑さ: これらのワークフローの評価には、各段階で異なる評価戦略が必要になるため、固有の課題が伴います。たとえば、RAG ステージでは、取得したドキュメントの関連性と完全性を評価する必要があり、生成された要約については品質と正確性をチェックする必要があります。同様に、クエリの再定式化の有効性には、書き換えられたクエリによって検索結果が改善されるかどうかを判断するための別の評価ロジックが必要です。

まとめ

このブログ投稿では、エージェント RAG の概念を紹介し、エージェント AI の自律機能を組み込むことで従来の RAG フレームワークをどのように強化するかについて説明しました。私たちは、エージェント RAG のコア機能を探り、Elasticsearch をベクターストアとして使用し、LangChain を使用してエージェントフレームワークを作成するニュースアシスタントを構築するという実践的な例を通じて、これらの機能を実演しました。

さらに、エージェント RAG パイプラインを設計および実装する際に考慮すべきベストプラクティスと主な課題についても説明しました。これらの洞察は、検索、推論、意思決定を効果的に組み合わせた、堅牢でスケーラブルかつ効率的なエージェントシステムを開発者が作成できるようにするためのものです。

次のステップ

私たちが構築したワークフローはシンプルで、改善と実験の余地が十分にあります。さまざまな埋め込みモデルを試し、検索戦略を改良することで、これを強化できます。さらに、検索されたドキュメントに優先順位を付ける再ランク付けエージェントを統合すると有益となる可能性があります。もう一つの調査領域は、エージェントフレームワークの評価戦略の開発、具体的にはさまざまな種類のフレームワークに適用可能な共通かつ再利用可能なアプローチの特定です。最後に、これらのフレームワークを大規模でより複雑なデータセットで実験します。

その間、同様の実験を共有していただける場合は、ぜひお聞かせください。お気軽にフィードバックをお寄せください。また、コミュニティの Slack チャンネルやディスカッションフォーラムを通じてご連絡いただくこともできます。

各種資料

Elastic Agent Builder と GPT-OSS を使用した HR 向け AI エージェントの構築

Tomás Murúa — Wed, 26 Nov 2025 00:00:00 GMT

はじめに

この記事では、GPT-OSSと Elastic Agent Builder を使用して HR 向けの AI エージェントを構築する方法を説明します。エージェントは、OpenAI、Anthropic、その他の外部サービスにデータを送信せずに質問に答えることができます。

LM Studio を使用して GPT-OSS をローカルで提供し、Elastic Agent Builder に接続します。

この記事を読み終える頃には、情報とモデルを完全に制御しながら、従業員データに関する自然言語の質問に答えることができるカスタム AI エージェントが完成しているはずです。

要件

この記事には以下が必要です:

Elastic Cloudホスト 9.2、サーバーレスまたはローカル展開
32GB RAM搭載マシンを推奨（GPT-OSS 20Bの場合は最低16GB）
LM Studioがインストール済み
Dockerデスクトップがインストール済み

GPT-OSS を使用する理由は何ですか?

ローカル LLM を使用すると、独自のインフラストラクチャに LLM を展開し、独自のニーズに合わせて微調整することができます。モデルと共有するデータの制御を維持しながら、これらすべてを実行できます。もちろん、外部プロバイダーにライセンス料を支払う必要はありません。

OpenAI は、オープンモデルエコシステムへの取り組みの一環として、2025 年 8 月 5 日にGPT-OSS をリリースしました。

20B パラメータモデルは以下を提供します。

ツール使用能力
効率的な推論
OpenAI SDK対応
エージェントワークフローと互換性あり

ベンチマーク比較:

ソリューションアーキテクチャ

アーキテクチャは完全にローカルマシン上で実行されます。Elastic (Docker で実行) は LM Studio を介してローカル LLM と直接通信し、Elastic Agent Builder はこの接続を使用して従業員データを照会できるカスタム AI エージェントを作成します。

詳細については、こちらのドキュメントを参照してください。

HR向けAIエージェントの構築：手順

実装は 5 つのステップに分けられます。

ローカルモデルでLMスタジオを構成する
DockerでローカルElasticをデプロイする
ElasticでOpenAIコネクタを作成する
従業員データをElasticsearchにアップロードする
AIエージェントを構築してテストする

ステップ1：LM StudioをGPT-OSS 20Bで構成する

LM Studio は、大規模な言語モデルをコンピュータ上でローカルに実行できるユーザーフレンドリーなアプリケーションです。OpenAI 互換の API サーバーを提供するため、複雑なセットアッププロセスなしで Elastic などのツールと簡単に統合できます。詳細については、 LM Studio ドキュメントを参照してください。

まず、公式サイトからLM Studioをダウンロードしてインストールします。インストールしたら、アプリケーションを開きます。

LM Studio インターフェースの場合:

検索タブに移動して「GPT-OSS」を検索します。
OpenAIからopenai/gpt-oss-20bを選択してください
ダウンロードをクリック

このモデルのサイズは約12.10 GBになります。インターネット接続によっては、ダウンロードに数分かかる場合があります。

モデルをダウンロードしたら:

ローカルサーバータブに移動します
openai/gpt-oss-20bを選択します
デフォルトのポート1234を使用する
右側のパネルで、 「ロード」に移動し、コンテキストの長さを40K以上に設定します。

5. サーバーの開始をクリック

サーバーが実行中の場合はこれが表示されます。

[LM STUDIO SERVER] Success! HTTP server listening on port 1234 [LM STUDIO SERVER] Supported endpoints: [LM STUDIO SERVER] -> GET http://localhost:1234/v1/models [LM STUDIO SERVER] -> POST http://localhost:1234/v1/responses [LM STUDIO SERVER] -> POST http://localhost:1234/v1/chat/completions [LM STUDIO SERVER] -> POST http://localhost:1234/v1/completions [LM STUDIO SERVER] -> POST http://localhost:1234/v1/embeddings Server started.

ステップ2: DockerでローカルElasticをデプロイする

ここで、Docker を使用して Elasticsearch と Kibana をローカルにセットアップします。Elastic は、セットアッププロセス全体を処理する便利なスクリプトを提供します。詳細については、公式ドキュメントを参照してください。

start-local スクリプトを実行する

ターミナルで次のコマンドを実行します。

curl -fsSL https://elastic.co/start-local | sh

このスクリプトは次のことを行います。

ElasticsearchとKibanaをダウンロードして設定する
Docker Composeを使用して両方のサービスを開始します
30日間のプラチナトライアルライセンスを自動的に有効化

期待される出力

次のメッセージが表示されるまで待ち、表示されるパスワードと API キーを保存します。これらは Kibana にアクセスするために必要になります。

🎉 Congrats, Elasticsearch and Kibana are installed and running in Docker! 🌐 Open your browser at http://localhost:5601 Username: elastic Password: KSUlOMNr 🔌 Elasticsearch API endpoint: http://localhost:9200 🔑 API key: cnJGX0pwb0JhOG00cmNJVklUNXg6cnNJdXZWMnM4bncwMllpQlFlUTlWdw== Learn more at https://github.com/elastic/start-local

Kibanaにアクセスする

ブラウザを開いて次の場所に移動します:

http://localhost:5601

ターミナル出力で取得した資格情報を使用してログインします。

エージェントビルダーを有効にする

Kibana にログインしたら、 [Management] > [AI] > [Agent Builder]に移動して、Agent Builder をアクティブ化します。

ステップ3: ElasticでOpenAIコネクタを作成する

ここで、ローカル LLM を使用するように Elastic を構成します。

アクセスコネクタ

キバナで
プロジェクト設定>管理に移動します
アラートとインサイトの下で、コネクタを選択します。
コネクタの作成をクリック

コネクタを構成する

コネクタのリストからOpenAI を選択します。LM Studio は OpenAI SDK を使用しているため、互換性があります。

次の値をフィールドに入力します。

コネクタ名: LM Studio - GPT-OSS 20B
OpenAIプロバイダーを選択:その他 (OpenAI互換サービス)
URL: http://host.docker.internal:1234/v1/chat/completions
デフォルトモデル: openai/gpt-oss-20b
API キー: testkey-123 (LM Studio Server では認証が不要なので、任意のテキストを使用できます。)

設定を完了するには、 「保存してテスト」をクリックします。

重要: 「ネイティブ関数の呼び出しを有効にする」をオンにします。これは、Agent Builder が正しく動作するために必要です。これを有効にしないと、 No tool calls found in the responseエラーが発生します。

接続をテストする

Elastic は自動的に接続をテストするはずです。すべてが正しく構成されている場合、次のような成功メッセージが表示されます。

対応：

{ "status": "ok", "data": { "id": "chatcmpl-flj9h0hy4wcx4bfson00an", "object": "chat.completion", "created": 1761189456, "model": "openai/gpt-oss-20b", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "Hello! 👋 How can I assist you today?", "reasoning": "Just greet.", "tool_calls": [] }, "logprobs": null, "finish_reason": "stop" } ], "usage": { "prompt_tokens": 69, "completion_tokens": 23, "total_tokens": 92 }, "stats": {}, "system_fingerprint": "openai/gpt-oss-20b" }, "actionId": "ee1c3aaf-bad0-4ada-8149-118f52dad757" }

ステップ4: 従業員データをElasticsearchにアップロードする

ここで、 HR 従業員データセットをアップロードして、エージェントが機密データをどのように処理するかを説明します。私はこの構造を持つ架空のデータセットを生成しました。

データセットの構造

{ "employee_id": "0f4dce68-2a09-4cb1-b2af-6bcb4821539b", "full_name": "Daffi Stiebler", "email": "lscutchings0@huffingtonpost.com", "date_of_birth": "1975-06-20T15:39:36Z", "hire_date": "2025-07-28T00:10:45Z", "job_title": "Physical Therapy Assistant", "department": "HR", "salary": "108455", "performance_rating": "Needs Improvement", "years_of_experience": 2, "skills": "Java", "education_level": "Master's Degree", "manager": "Carl MacGibbon", "emergency_contact": "Leigha Scutchings", "home_address": "5571 6th Park" }

マッピングを使用してインデックスを作成する

まず、適切なマッピングを使用してインデックスを作成します。一部のキーフィールドにsemantic_textフィールドを使用していることに注意してください。これにより、インデックスのセマンティック検索機能が有効になります。

PUT hr-employees { "mappings": { "properties": { "@timestamp": { "type": "date" }, "employee_id": { "type": "keyword" }, "full_name": { "type": "text", "copy_to": "employee_semantic" }, "email": { "type": "keyword" }, "date_of_birth": { "type": "date", "format": "iso8601" }, "hire_date": { "type": "date", "format": "iso8601" }, "job_title": { "type": "text", "copy_to": "employee_semantic" }, "department": { "type": "text", "copy_to": "employee_semantic" }, "salary": { "type": "double" }, "performance_rating": { "type": "text", "copy_to": "employee_semantic" }, "years_of_experience": { "type": "long" }, "skills": { "type": "text", "copy_to": "employee_semantic" }, "education_level": { "type": "text", "copy_to": "employee_semantic" }, "manager": { "type": "text", "copy_to": "employee_semantic" }, "emergency_contact": { "type": "keyword" }, "home_address": { "type": "keyword" }, "employee_semantic": { "type": "semantic_text" } } } }

Bulk APIを使用したインデックス

データセットをコピーして Kibana の開発ツールに貼り付け、実行します。

POST hr-employees/_bulk {"index": {}} {"employee_id": "57728b91-e5d7-4fa8-954a-2384040d3886", "full_name": "Filide Gane", "email": "vhallahan1@booking.com", "job_title": "Business Systems Development Analyst", "department": "Marketing", "salary": "$52330.27", "performance_rating": "Meets Expectations", "years_of_experience": 12, "skills": "Java", "education_level": "Bachelor's Degree", "date_of_birth": "2000-02-07T16:49:32Z", "hire_date": "2023-11-07T13:03:16Z", "manager": "Freedman Kings", "emergency_contact": "Vilhelmina Hallahan", "home_address": "75 Dennis Junction"} {"index": {}} {"employee_id": "...", ...}

データを検証する

クエリを実行して確認します。

GET hr-employees/_search

ステップ5: AIエージェントを構築してテストする

すべての設定が完了したら、Elastic Agent Builder を使用してカスタム AI エージェントを構築します。詳細については、 Elastic のドキュメントを参照してください。

コネクタを追加する

新しいエージェントを作成する前に、デフォルトのコネクタはElastic Managed LLMであるため、 LM Studio - GPT-OSS 20Bというカスタムコネクタを使用するようにエージェントビルダーを設定する必要があります。そのためには、 「プロジェクト設定」 > 「管理」 > 「GenAI 設定」に移動し、作成した設定を選択して「保存」をクリックします。

アクセスエージェントビルダー

エージェントへ
「新しいエージェントを作成」をクリックします

エージェントを構成する

新しいエージェントを作成するには、エージェント ID 、表示名、および表示手順が必須フィールドです。

ただし、システムプロンプトに似ていますが、カスタムエージェント用の、エージェントの動作やツールとの対話方法をガイドするカスタムインストラクションなど、さらに多くのカスタマイズオプションがあります。ラベルは、エージェント、アバターの色、アバターシンボルを整理するのに役立ちます。

データセットに基づいてエージェント用に選択したものは次のとおりです。 エージェントID: hr_assistant

カスタム指示:

You are an HR Analytics Assistant that helps answer questions about employee data. When responding to queries: - Provide clear, concise answers - Include relevant employee details (name, department, salary, skills) - Format monetary values with currency symbols - Be professional and maintain data confidentiality

ラベル: Human Resourcesおよび GPT-OSS

表示名： HR Analytics Assistant

表示の説明:

A specialized AI assistant for Human Resources that helps analyze employee data, compensation, performance metrics, and talent management. Ask questions about employees, departments, salaries, or performance analytics.

すべてのデータが入力されたら、新しいエージェントの「保存」をクリックします。

エージェントをテストする

従業員データについて自然言語で質問できるようになり、GPT-OSS 20B が意図を理解して適切な応答を生成します。

プロンプト：

Which employee is the one with the highest salary in the hr-employees index?

答え：

エージェントのプロセスは次のとおりです。

1. GPT-OSSコネクタを使用して質問を理解する

2. 適切なElasticsearchクエリを生成する（組み込みツールまたはカスタムES|QLを使用）

3. 一致する従業員レコードを取得する

4. 適切なフォーマットで自然言語で結果を提示する

従来の語彙検索とは異なり、GPT-OSS を搭載したエージェントは意図とコンテキストを理解するため、正確なフィールド名やクエリ構文を知らなくても情報を簡単に見つけることができます。エージェントの思考プロセスの詳細については、こちらの記事を参照してください。

まとめ

この記事では、Elastic の Agent Builder を使用してカスタム AI エージェントを構築し、ローカルで実行されている OpenAI GPT-OSS モデルに接続しました。このアーキテクチャでは、Elastic と LLM の両方をローカルマシンにデプロイすることで、外部サービスに情報を送信することなく、データに対する完全な制御を維持しながら生成 AI 機能を活用できます。

実験としてはGPT-OSS 20Bを使用しましたが、Elastic Agent Builderの公式推奨モデルはこちらを参考にしています。より高度な推論機能が必要な場合は、複雑なシナリオでより優れたパフォーマンスを発揮する120B パラメータバリアントもありますが、ローカルで実行するにはより高性能なマシンが必要です。詳細については、 OpenAI の公式ドキュメントを参照してください。

Cal Hacks 12.0 で取り上げた Elastic Agent Builder のトッププロジェクトと学習内容

JD Armada — Tue, 25 Nov 2025 00:00:00 GMT

数週間前、私たちは、世界中から 2,000 人を超える参加者が集まる最大規模の対面ハッカソンの 1 つであるCal Hacks 12.0 をスポンサーするという素晴らしい機会を得ました。Elastic Agent Builder on Serverless の最も優れた活用方法に専用の賞品トラックを設けましたが、反響は驚くほど大きかったです。わずか 36 時間で、山火事インテリジェンスツールの構築から StackOverflow バリデーターまで、Agent Builder を独創的な方法で使用した 29 件の応募を受け取りました。

Cal Hacks 12.0 での経験は、印象的なプロジェクト以外にも、同様に貴重なものをもたらしてくれました。それは、初めて当社のスタックに遭遇した開発者からの、迅速でフィルターされていないフィードバックです。ハッカソンは、厳しい期限、事前の知識ゼロ、そして予測不可能な障害（悪名高い WiFi の停止など）を伴う、ユニークなプレッシャーテストです。開発者エクスペリエンスが優れている点と、まだ改善が必要な点が正確に明らかになります。開発者が LLM 主導のワークフローを通じて新しい方法で Elastic Stack を操作することが増えているため、これは現在さらに重要になっています。このブログ投稿では、参加者が Agent Builder を使用して構築したものと、そのプロセスで学んだことについてさらに詳しく説明します。

受賞プロジェクト

1位: AgentOverflow

LLM およびエージェント時代に合わせて再構築された Stack Overflow。

AgentOverflow の詳細については、こちらをご覧ください。

AgentOverflow は、ほとんどの AI 開発者が遭遇する問題、つまり LLM が幻覚を起こし、チャット履歴が消え、開発者が同じ問題を再度解決するのに時間を無駄にする問題に対処します。

AgentOverflow は実際の問題と解決策のペアをキャプチャ、検証、再表示するため、開発者は幻覚スパイラルを打破し、より早く製品を出荷できます。

仕組み：

1. JSON（「ソリューションスキーマ」）を共有します。

Claude の共有から 1 回クリックすると、次の内容を含む構造化形式である Share Solution JSON がスクレイピング、抽出、組み立てられます。

問題
コンテクスト
コード
タグ
検証済みの解決手順。

バリデーター (LAVA) が構造をチェックして強制し、ユーザーが追加のコンテキストの行を追加すると、Elasticsearch 内に保存されてインデックスが作成されます。

2. 解決策を見つける

行き詰まったら、 Find Solutionをクリックすると、AgentOverflow が現在の会話をスクレイピングし、それを使用してクエリを作成し、ハイブリッド Elasticsearch 検索を実行して次の内容を表示します。

ランク付けされたコミュニティ検証済みの修正
当初問題を解決した正確なプロンプト

これにより、開発者は現在のセッションをすばやくコピー、貼り付け、ブロック解除できます。

3. MCP - LLMのコンテキスト注入

MCP (モデルコンテキストプロトコル) を介して Elasticsearch 内に保存された構造化ソリューションに接続することにより、LLM には実行時に余分なノイズなしで高度な信号コンテキスト (コード、ログ、構成、以前の修正) が供給されます。

AgentOverflow は、関連するコンテキストを LLM に挿入する構造化メモリレイヤーとして、Elasticsearch を備えた Agent Builder を使用します。これにより、受動的なチャットボットからコンテキストを認識した問題解決者へと変化します。

準優勝：マーケットマインド

6 つの Elastic Agent を活用した、市場エネルギーのリアルタイムの解釈可能なビュー。

MarketMindの詳細については、こちらをご覧ください。

MarketMind は、初心者トレーダーに、断片化された市場データを明確でリアルタイムなシグナルに変換するプラットフォームを提供することで、その地位を獲得しました。MarketMind は、さまざまなツール間で価格変動、ファンダメンタルズ、センチメント、ボラティリティを調整する代わりに、これらすべての情報を 1 つのプラットフォームに統合し、トレーダーが実用的な洞察を得られるよう支援します。このプロジェクトでは、エージェントの構築時に複雑な ES|QL クエリも使用しました。

仕組み：

1. リアルタイムの市場データを収集する

MarketMind は、Yahoo Finance から価格動向、ファンダメンタルズ、センチメント、ボラティリティ、リスク指標を取得します。このデータは複数の Elasticsearch インデックスに取り込まれ、整理されます。

2. 6人の専門エージェントが市場を分析

Agent Builder で構築された各エージェントは、市場の異なる層に焦点を当てています。これらは Elasticsearch インデックスから読み取り、独自のドメイン固有のメトリックを計算し、スコアと推論を含む標準化された JSON 出力を生成します。

3. シグナルを統合した「市場エネルギー」モデルに集約する

組み合わせた出力は各株の周囲に光るパルスとして表示され、勢いが高まっているのか、リスクが高まっているのか、感情が変化しているのかを示します。

4. 洞察を視覚化する

フロントエンドは、TypeScript、SVG 物理ベースのビジュアル、ライブローソク足チャート用の Chart.js を使用して、React と Next.js で構築されました。これにより、生の分析がリアルタイムで実用的なフィードバックに変換されます。

その他の興味深いプロジェクト:

スタックのさまざまな部分で Elastic を使用した他の有力な候補を次に示します。

私たちのトラックに提出されたプロジェクトの完全なリストは、こちらでご覧ください。

開発者から学んだこと

Agent Builder はユーザーフレンドリーです:

ほとんどのチームはこれまで Elastic を使用したことがありませんでしたが、それでもほとんどサポートなしでエージェントを迅速に構築できました。さらに詳しい指導が必要な人向けにワークショップを開催しましたが、ほとんどの人はデータを取り込み、そのデータに基づいてアクションを実行するエージェントを構築することができました。

LLM はkNNクエリに優れていますが、ES|QL の生成には依然としてガイダンスが必要です。

ChatGPT-5 に ES|QL クエリの生成を依頼すると、ES|QL と SQL が混在するなど、誤った情報が返されることがよくありました。LLM にマークダウンファイルでドキュメントを供給することは、実行可能な修正であるように思われました。

スナップショット専用の ES|QL 関数がドキュメントに漏洩しました:

今後登場するFIRSTおよびLAST集計関数が、意図せず ES|QL ドキュメントに紛れ込んでしまいました。これらのドキュメントを ChatGPT に渡したため、Serverless ではまだ利用できないにもかかわらず、モデルはこれらの関数を忠実に使用しました。グループからのフィードバックのおかげで、エンジニアリングはすぐに修正を公開し、マージして、公開されたドキュメントから関数を削除しました ( PR #137341 )。

サーバーレス固有のガイダンスが不足しています:

チームは、ルックアップモードで作成されなかったインデックスでLOOKUP JOIN有効にしようとしました。エラーメッセージにより、Serverless に存在しないコマンドが追跡されました。私たちはこれを製品チームに伝え、製品チームはすぐに Serverless 固有の実用的なメッセージの修正を開始しました。長期的には、再インデックスの複雑さを完全に隠すことがビジョンです (問題 #4838 )。

対面イベントの価値:

オンラインハッカソンは素晴らしいですが、ビルダーと肩を並べてデバッグしているときに得られる迅速なフィードバックループに匹敵するものはありません。私たちは、チームがさまざまなユースケースにわたって Agent Builder を統合する様子を観察し、ES|QL を使用した開発者エクスペリエンスを改善できる部分を見つけ、非同期チャネルで解決するよりもはるかに迅速に問題を修正しました。

まとめ

Cal Hacks 12.0 では、素晴らしいデモを週末にわたって披露するだけでなく、新しい開発者が Elastic Stack とどのように関わっているかについても理解することができました。わずか 36 時間で、チームは Agent Builder を導入し、Elasticsearch にデータを取り込み、マルチエージェントシステムを設計し、さまざまな方法で機能をテストするようになりました。このイベントは、対面イベントがなぜ重要なのかを私たちに思い出させてくれました。迅速なフィードバックループ、実際の会話、実践的なデバッグにより、現在の開発者のニーズを理解することができました。私たちが学んだことをエンジニアリングチームに還元できることを嬉しく思います。次回のハッカソンでお会いしましょう。

Elasticsearch で A2A プロトコルと MCP を使用して LLM エージェントニュースルームを作成する: パート II

Justin Castilla — Mon, 24 Nov 2025 00:00:00 GMT

A2AとMCP：コードの動作

これは、記事「Elasticsearch で A2A プロトコルと MCP を使用して LLM エージェントニュースルームを作成する」の補足記事です。この記事では、同じエージェント内に A2A と MCP の両方のアーキテクチャを実装して、両方のフレームワークの独自のメリットを最大限に活用するメリットについて説明しました。自分でデモを実行したい場合、リポジトリが利用可能です。

ニュースルームのエージェントが A2A と MCP の両方を使用して協力し、ニュース記事を作成する方法を見ていきましょう。エージェントの動作を確認するための付属リポジトリは、ここにあります。

ステップ1：ストーリーの割り当て

ニュースチーフ（クライアントとして行動）がストーリーを割り当てます。

{ "message_type": "task_request", "sender": "news_chief", "receiver": "reporter_agent", "payload": { "task_id": "story_renewable_energy_2024", "assignment": { "topic": "Renewable Energy Adoption in Europe", "angle": "Policy changes driving solar and wind expansion", "target_length": 1200, "deadline": "2025-09-30T18:00:00Z" } } }

ステップ2: 記者が調査を依頼する

レポーターエージェントは背景情報が必要であることを認識し、A2A を介してリサーチャーエージェントに委任します。

{ "message_type": "task_request", "sender": "reporter_agent", "receiver": "researcher_agent", "payload": { "task_id": "research_eu_renewable_2024", "parent_task_id": "story_renewable_energy_2024", "capability": "fact_gathering", "parameters": { "queries": [ "EU renewable energy capacity 2024", "Solar installations growth Europe", "Wind energy policy changes 2024" ], "depth": "comprehensive" } } }

ステップ3: 報告者がアーカイブエージェントに歴史的背景をリクエストする

レポーターエージェントは、歴史的背景が記事の内容を強めることを認識しています。A2A 経由でアーカイブエージェント( Elastic の A2A エージェントを搭載) に委任し、ニュースルームの Elasticsearch 搭載記事アーカイブを検索します。

{ "message_type": "task_request", "sender": "reporter_agent", "receiver": "archive_agent", "payload": { "task_id": "archive_search_renewable_2024", "parent_task_id": "story_renewable_energy_2024", "capability": "search_archive", "parameters": { "query": "European renewable energy policy changes and adoption trends over past 5 years", "focus_areas": ["solar", "wind", "policy", "Germany", "France"], "time_range": "2019-2024", "result_count": 10 } } }

ステップ4: アーカイブエージェントはMCPでElastic A2Aエージェントを使用する

アーカイブエージェントはElastic の A2A エージェントを使用し、A2A エージェントは MCP を使用して Elasticsearch ツールにアクセスします。これは、A2A がエージェントのコラボレーションを可能にし、MCP がツールアクセスを提供するハイブリッドアーキテクチャを示しています。

# Archive Agent using Elastic A2A Agent async def search_historical_articles(self, query_params): # The Archive Agent sends a request to Elastic's A2A Agent elastic_response = await self.a2a_client.send_request( agent="elastic_agent", capability="search_and_analyze", parameters={ "natural_language_query": query_params["query"], "index_pattern": "newsroom-articles-*", "filters": { "topics": query_params["focus_areas"], "date_range": query_params["time_range"] }, "analysis_type": "trend_analysis" } ) # Elastic's A2A Agent internally uses MCP tools: # - platform.core.search (to find relevant articles) # - platform.core.generate_esql (to analyze trends) # - platform.core.index_explorer (to identify relevant indices) return elastic_response

アーカイブエージェントはElastic の A2A エージェントから包括的な履歴データを受信し、それをレポーターに返します。

{ "message_type": "task_response", "sender": "archive_agent", "receiver": "reporter_agent", "payload": { "task_id": "archive_search_renewable_2024", "status": "completed", "archive_data": { "historical_articles": [ { "title": "Germany's Energiewende: Five Years of Solar Growth", "published": "2022-06-15", "key_points": [ "Germany added 7 GW annually 2020-2022", "Policy subsidies drove 60% of growth" ], "relevance_score": 0.94 }, { "title": "France Balances Nuclear and Renewables", "published": "2023-03-20", "key_points": [ "France increased renewable target to 40% by 2030", "Solar capacity doubled 2021-2023" ], "relevance_score": 0.89 } ], "trend_analysis": { "coverage_frequency": "EU renewable stories increased 150% since 2019", "emerging_themes": ["policy incentives", "grid modernization", "battery storage"], "coverage_gaps": ["Small member states", "offshore wind permitting"] }, "total_articles_found": 47, "search_confidence": 0.91 } } }

このステップでは、Elastic の A2A エージェントがニュースルームのワークフローにどのように統合されるかを示します。Archive Agent（ニュースルーム固有のエージェント）は、Elastic の A2A Agent（サードパーティの専門家）と連携して、Elasticsearch の強力な検索および分析機能を活用します。Elastic のエージェントは内部的に MCP を使用して Elasticsearch ツールにアクセスし、エージェント調整 (A2A) とツールアクセス (MCP) を明確に分離します。

ステップ5: 研究者はMCPサーバーを使用する

研究者エージェントは複数の MCP サーバーにアクセスして情報を収集します。

# Researcher Agent using MCP to access tools async def gather_facts(self, queries): results = [] # Use News API MCP Server news_data = await self.mcp_client.invoke_tool( server="news_api_mcp", tool="search_articles", parameters={ "query": queries[0], "date_range": "2024-01-01 to 2024-09-30", "sources": ["reuters", "bloomberg", "euractiv"] } ) # Use Statistics MCP Server stats_data = await self.mcp_client.invoke_tool( server="eurostat_mcp", tool="get_energy_statistics", parameters={ "metrics": ["solar_capacity_mw", "wind_capacity_mw"], "countries": ["EU27"], "year": 2024 } ) # Use Fact-Checking MCP Server verified_facts = await self.mcp_client.invoke_tool( server="factcheck_mcp", tool="verify_claims", parameters={ "claims": [ "EU solar capacity increased 40% in 2024", "Germany leads in wind installations" ] } ) return self._synthesize_research(news_data, stats_data, verified_facts)

ステップ6: 研究者が報告者にデータを返す

研究者エージェントは、包括的な研究を A2A 経由で返送します。

{ "message_type": "task_response", "sender": "researcher_agent", "receiver": "reporter_agent", "payload": { "task_id": "research_eu_renewable_2024", "status": "completed", "research_data": { "key_facts": [ { "claim": "EU solar capacity reached 260 GW in 2024", "source": "Eurostat Q3 2024 Report", "confidence": 0.95, "verified": true }, { "claim": "Germany installed 12 GW of wind capacity in 2024", "source": "German Federal Network Agency", "confidence": 0.92, "verified": true } ], "statistics": { "solar_growth_rate": "35%", "wind_growth_rate": "28%" }, "sources_count": 15 } } }

ステップ7：記者が記事を書く

Reporter Agent は、調査データと独自の LLM 機能を使用して記事を作成します。書き込み中、Reporter はスタイルとテンプレートに MCP サーバーを使用します。

# Reporter Agent writing with MCP assistance async def write_article(self, research_data, assignment): # Get style guidelines via MCP style_guide = await self.mcp_client.get_resource( server="newsroom_mcp", resource="style://editorial/ap_style_guide" ) # Get article template via MCP template = await self.mcp_client.get_resource( server="newsroom_mcp", resource="template://articles/news_story" ) # Generate article using LLM + research + style draft = await self.llm.generate( prompt=f""" Write a news article following these guidelines: {style_guide} Using this template: {template} Based on this research: {research_data} Assignment: {assignment} """ ) # Self-evaluate confidence in claims confidence_check = await self._evaluate_confidence(draft) return draft, confidence_check

ステップ8：自信が低い場合は再調査を促します

レポーターエージェントは下書きを評価し、1 つの主張の信頼性が低いことを発見しました。研究者エージェントに別のリクエストを送信します:

{ "message_type": "collaboration_request", "sender": "reporter_agent", "receiver": "researcher_agent", "payload": { "request_type": "fact_verification", "claims": [ { "text": "France's nuclear phase-down contributed to 15% increase in renewable capacity", "context": "Discussing policy drivers for renewable growth", "current_confidence": 0.45, "required_confidence": 0.80 } ], "urgency": "high" } }

研究者はファクトチェックMCPサーバーを使用して主張を検証し、更新された情報を返します。

{ "message_type": "collaboration_response", "sender": "researcher_agent", "receiver": "reporter_agent", "payload": { "verified_claims": [ { "original_claim": "France's nuclear phase-down contributed to 15% increase...", "verified_claim": "France's renewable capacity increased 18% in 2024, partially offsetting reduced nuclear output", "confidence": 0.88, "corrections": "Percentage was 18%, not 15%; nuclear phase-down is gradual, not primary driver", "sources": ["RTE France", "French Energy Ministry Report 2024"] } ] } }

ステップ9: 記者が修正して編集者に提出する

記者は検証された事実を組み込み、完成した原稿を A2A 経由で編集者エージェントに送信します。

{ "message_type": "task_request", "sender": "reporter_agent", "receiver": "editor_agent", "payload": { "task_id": "edit_renewable_story", "parent_task_id": "story_renewable_energy_2024", "content": { "headline": "Europe's Renewable Revolution: Solar and Wind Surge 30% in 2024", "body": "[Full article text...]", "word_count": 1185, "sources": [/* array of sources */] }, "editing_requirements": { "check_style": true, "check_facts": true, "check_seo": true } } }

ステップ10: MCPツールを使用した編集者のレビュー

エディターエージェントは複数の MCP サーバーを使用して記事をレビューします。

# Editor Agent using MCP for quality checks async def review_article(self, content): # Grammar and style check grammar_issues = await self.mcp_client.invoke_tool( server="grammarly_mcp", tool="check_document", parameters={"text": content["body"]} ) # SEO optimization check seo_analysis = await self.mcp_client.invoke_tool( server="seo_mcp", tool="analyze_content", parameters={ "headline": content["headline"], "body": content["body"], "target_keywords": ["renewable energy", "Europe", "solar", "wind"] } ) # Plagiarism check originality = await self.mcp_client.invoke_tool( server="plagiarism_mcp", tool="check_originality", parameters={"text": content["body"]} ) # Generate editorial feedback feedback = await self._generate_feedback( grammar_issues, seo_analysis, originality ) return feedback

編集者は記事を承認し、送信します。

{ "message_type": "task_response", "sender": "editor_agent", "receiver": "reporter_agent", "payload": { "status": "approved", "quality_score": 9.2, "minor_edits": [ "Changed 'surge' to 'increased' in paragraph 3 for AP style consistency", "Added Oxford comma in list of countries" ], "approved_content": "[Final edited article]" } }

ステップ11: パブリッシャーがCI/CD経由でパブリッシュする

最後に、プリンターエージェントは、CMS および CI/CD パイプラインの MCP サーバーを使用して承認された記事を公開します。

# Publisher Agent publishing via MCP async def publish_article(self, content, metadata): # Upload to CMS via MCP cms_result = await self.mcp_client.invoke_tool( server="wordpress_mcp", tool="create_post", parameters={ "title": content["headline"], "body": content["body"], "status": "draft", "categories": metadata["categories"], "tags": metadata["tags"], "featured_image_url": metadata["image_url"] } ) post_id = cms_result["post_id"] # Trigger CI/CD deployment via MCP deploy_result = await self.mcp_client.invoke_tool( server="cicd_mcp", tool="trigger_deployment", parameters={ "pipeline": "publish_article", "environment": "production", "post_id": post_id, "schedule": "immediate" } ) # Track analytics await self.mcp_client.invoke_tool( server="analytics_mcp", tool="register_publication", parameters={ "post_id": post_id, "publish_time": datetime.now().isoformat(), "story_id": metadata["story_id"] } ) return { "status": "published", "post_id": post_id, "url": f"https://newsroom.example.com/articles/{post_id}", "deployment_id": deploy_result["deployment_id"] }

出版社はA2Aを通じて出版を確認します。

{ "message_type": "task_complete", "sender": "printer_agent", "receiver": "news_chief", "payload": { "task_id": "story_renewable_energy_2024", "status": "published", "publication": { "url": "https://newsroom.example.com/articles/renewable-europe-2024", "published_at": "2025-09-30T17:45:00Z", "post_id": "12345" }, "workflow_metrics": { "total_time_minutes": 45, "agents_involved": ["reporter", "researcher", "archive", "editor", "printer"], "iterations": 2, "mcp_calls": 12 } } }

以下は、上記と同じエージェントを使用した付属のリポジトリ内の A2A ワークフローの完全なシーケンスです。

から

に

アクション

プロトコル

説明

ユーザー

ニュースチーフ

ストーリーの割り当て

HTTP ポスト

ユーザーがストーリーのトピックと角度を提出する

ニュースチーフ

内部

ストーリーを作成する

固有のIDを持つストーリーレコードを作成します

ニュースチーフ

記者

委任の割り当て

A2A

A2Aプロトコル経由でストーリー割り当てを送信します

記者

内部

割り当てを受け入れる

割り当てを内部に保存する

記者

MCP サーバー

アウトラインを生成

MCP/HTTP

記事のアウトラインと研究の質問を作成します

記者

研究者

調査依頼

A2A

質問を送信します（6bと並行）

記者

アーキビスト

アーカイブを検索

A2A JSONRPC

歴史的な記事を検索します（6aと並行）

研究者

MCP サーバー

研究上の質問

MCP/HTTP

MCP経由でAnthropicを使用して質問に答えます

研究者

記者

リターンリサーチ

A2A

調査の回答を返す

アーキビスト

Elasticsearch

検索インデックス

ES REST API

news_archiveインデックスをクエリ

アーキビスト

記者

アーカイブに戻る

A2A JSONRPC

過去の検索結果を返します

記者

MCP サーバー

記事を生成する

MCP/HTTP

研究/アーカイブの文脈で記事を作成する

記者

内部

ストアドラフト

下書きを内部に保存

記者

ニュースチーフ

下書きを送信

A2A

完成した草稿を提出する

ニュースチーフ

内部

ストーリーを更新

下書きを保存し、ステータスを「draft_submitted」に更新します

ニュースチーフ

エディタ

レビュー草稿

A2A

レビューのために編集者に自動ルーティング

エディタ

MCP サーバー

総説

MCP/HTTP

MCP経由でAnthropicを使用してコンテンツを分析します

エディタ

ニュースチーフ

返品レビュー

A2A

編集上のフィードバックと提案を送信します

ニュースチーフ

内部

ストアレビュー

編集者のフィードバックを保存

ニュースチーフ

記者

編集を適用

A2A

レビューのフィードバックをレポーターに転送する

記者

MCP サーバー

編集を適用

MCP/HTTP

フィードバックに基づいて記事を修正する

記者

内部

下書きの更新

修正を加えて下書きを更新する

記者

ニュースチーフ

返品修正

A2A

修正された記事を返す

ニュースチーフ

内部

ストーリーを更新

修正した下書きを保存し、ステータスを「修正済み」にする

ニュースチーフ

出版社

記事を公開する

A2A

パブリッシャーへの自動ルーティング

出版社

MCP サーバー

タグを生成する

MCP/HTTP

タグとカテゴリを作成する

出版社

Elasticsearch

インデックス記事

ES REST API

記事をnews_archiveインデックスにインデックスします

出版社

ファイルシステム

マークダウンを保存

ファイルI/O

記事を.mdとして保存します/articles内のファイル

出版社

ニュースチーフ

公開の確認

A2A

成功ステータスを返します

ニュースチーフ

内部

ストーリーを更新

ストーリーのステータスを「公開済み」に更新します

まとめ

A2A と MCP はどちらも、現代の拡張 LLM インフラストラクチャパラダイムにおいて重要な役割を果たします。A2A は複雑なマルチエージェントシステムに柔軟性を提供しますが、移植性が低くなり、運用が複雑になる可能性があります。MCP は、マルチエージェントオーケストレーションを処理するようには設計されていませんが、実装と保守がより簡単なツール統合のための標準化されたアプローチを提供します。

選択は二者択一ではありません。私たちのニュースルームの例で示されているように、最も洗練され効果的な LLM 対応システムは、多くの場合、両方のアプローチを組み合わせています。つまり、エージェントは A2A プロトコルを通じて調整と専門化を行いながら、MCP サーバーを通じてツールやリソースにアクセスします。このハイブリッドアーキテクチャは、MCP の標準化とエコシステムの利点に加えて、マルチエージェントシステムの組織上の利点も提供します。これは、選択する必要が全くないかもしれないことを示唆している。単に両方を標準的なアプローチとして使うだけでよい。

開発者またはアーキテクトとして、両方のソリューションの最適な組み合わせをテストして決定し、特定のユースケースに適した結果を生み出すのはあなた次第です。それぞれのアプローチの長所、制限、適切な適用を理解することで、より効果的で保守性と拡張性に優れた AI システムを構築できるようになります。

デジタルニュースルーム、顧客サービスプラットフォーム、リサーチアシスタント、またはその他の LLM を利用したアプリケーションを構築する場合でも、調整ニーズ (A2A) とツールアクセス要件 (MCP) を慎重に検討することで、成功への道が開かれます。

参考資料

Elasticsearch エージェントビルダー: https://www.elastic.co/docs/solutions/search/elastic-agent-builder
A2A仕様: https://a2a-protocol.org/latest/specification/
A2A と MCP の統合: https://a2a-protocol.org/latest/topics/a2a-and-mcp/
モデルコンテキストプロトコル: https://modelcontextprotocol.io

コンテキストエンジニアリングにおけるハイブリッド検索の威力 - パート3

Woody Walton — Thu, 20 Nov 2025 00:00:00 GMT

ハイブリッド検索 (パート I ) とコンテキストエンジニアリング (パート II ) の両方について説明しました。次に、RAG およびエージェント AI 操作にターゲットを絞ったコンテキストを提供する上で、これらがどのように連携して最大の効果を発揮するかについて詳しく見ていきましょう。

検索は死んでいない、ただ移動しただけだ

そのため、主にテキストボックスでコンテキストを検索し、返された情報 (コンテキスト) を使用して自分で回答を構築するという方法から、自然言語を使用してエージェントに必要なものを伝え、エージェントが自動的に回答を調査してまとめる方法へと移行しました。テクノロジー業界の多くの人々は、この変化を指摘し、「検索は死んだ」と主張しています（まあ、SEO とアドワーズの世界は確実に変化しています。GEOはどうですか？）。しかし、検索は依然として代理店の業務にとって絶対に不可欠です。ただ、現在では主にツールを介して目に見えない形で実行されているだけです。

以前は、主観的な関連性の主な判断者は人間でした。各ユーザーには検索を実行する独自の理由があり、個人的な経験が結果の相対的な正確性に影響を与えていました。エージェントが私たちと同じ（あるいはそれ以上の）結論に達することができると信頼するには、エージェントがアクセスできるコンテキスト情報が私たちの主観的な意図に可能な限り近いことを保証する必要があります。私たちはその目標に向けて、LLM に提供するコンテキストを設計する必要があります。

ハイブリッド検索によるコンテキストの生成

パート I でもう一度お伝えしましたが、Elastic のハイブリッド検索は、従来のキーワードベースの検索の強み (構文の柔軟性、キーワードの精度、関連性のスコアリング) とベクトル類似性検索の意味理解を組み合わせ、複数の再ランキング手法を提供します。この相乗効果（この言葉のより正確な使い方はこれまで見つかりませんでした！）クエリによってコンテンツをターゲットする方法がより細かく指定できるため、関連性の高い結果を得ることができます。主観的関連性を検索段階の1 つとして適用できるというだけでなく、実際には、第 1 段階の検索に関連性スコアリングを他のすべてのモードとともに一度に含めることができるのです。

優れた精度と効率

分散検索、取得、再ランク付け機能を備えたデータプラットフォームを主要なコンテキスト検索エンジンとして使用することは、非常に理にかなっています。高度なクエリ構文を使用して、主観的な意図の欠落したコンポーネントを追加し、返されるコンテキスト情報の価値を損なったり不明瞭にしたりする可能性のあるコンテンツを除外できます。利用可能な個々の構文オプションから選択することも、モダリティを単一の検索に組み合わせて、各データの種類を最もよく理解できる方法でターゲットにし、それらを再ランク付けして組み合わせたり並べ替えたりすることもできます。不要なデータを除外し、必要なフィールド/値のみが含まれるように応答をフィルタリングできます。エージェントにとって、このターゲティングの柔軟性により、コンテキストを非常に正確に取得できるツールを構築できます。

コンテキストの洗練（集約と非コンテンツシグナル）

集約は、ツールがコンテキストウィンドウに配信するコンテンツを形成する際に特に役立ちます。集計により、返されるコンテキストデータの形状に関する数値ベースの事実が自然に提供されるため、LLM による推論がより容易かつ正確になります。集計は階層的にネストできるため、LLM に複数レベルの詳細を追加して、より微妙な理解を深めることが簡単にできます。集計はコンテキストウィンドウのサイズの管理にも役立ちます。10 万件のドキュメントのクエリ結果を、集約された分析情報の数百トークンに簡単に減らすことができます。

非コンテンツシグナルは、データに内在する指標であり、見ているものの全体像を示します。つまり、人気、鮮度、地理的位置、カテゴリ、ホストの多様性、価格帯など、結果の追加特性です。これらの情報は、エージェントが受け取ったコンテキストの重要性をどのように評価するかをエージェントに通知するのに役立ちます。これを最もよく説明するために、いくつかの簡単な例を挙げます。

最近公開されたコンテンツや人気コンテンツの強化- 記事のナレッジベースがあると想像してください。ユーザーのクエリに関連する記事を見つけたいが、最近の記事であり、他のユーザーに役立つと判断された記事（「いいね」の数が多いなど）を優先したいとします。このシナリオでは、ハイブリッド検索を使用して関連する記事を見つけ、公開日と人気度の組み合わせに基づいて記事を再ランク付けすることができます。
売上と在庫調整を伴う電子商取引の検索- 電子商取引の設定では、検索語に一致する製品を顧客に表示したいだけでなく、売れ行きがよく在庫がある製品を宣伝したいとも考えます。顧客の不満を避けるために、在庫が少ない商品のランクを下げることもできます。
バグトラッカーで重大度の高い問題を優先する- ソフトウェア開発チームにとって、問題を検索する際には、重大度が高く、優先度が高く、最近更新された問題を最初に表示することが重要です。「重要度」や「最も議論されている」などの非シグナルを使用して、さまざまな要素を個別に評価し、最も重要で活発に議論されている問題が最上位に表示されるようにすることができます。

これらのサンプルクエリおよびその他の詳細は、付属の Elasticsearch Labsコンテンツページにあります。

セキュリティ強化

コンテキストエンジニアリングに Elastic のような検索を活用したスピードレイヤーを活用する重要な利点は、セキュリティフレームワークが組み込まれていることです。Elastic のプラットフォームは、きめ細かなロールベースのアクセス制御 (RBAC) と属性ベースのアクセス制御 (ABAC) を通じて、エージェントおよび生成 AI オペレーションに提供されるコンテキストが機密性の高い非公開情報を尊重して保護することを保証します。これは、クエリが効率的に処理されるだけでなく、エージェントまたはリクエストを開始したユーザーの特定の権限に応じて結果がフィルタリングされることを意味します。

エージェントは認証されたユーザーとして実行されるため、プラットフォームに組み込まれたセキュリティ機能を通じてセキュリティが暗黙的に適用されます。

きめ細かな権限:ドキュメント、フィールド、さらには用語レベルでアクセスを定義し、AI エージェントが表示を許可されているデータのみを受信するようにします。
ロールベースのアクセス制御 (RBAC):エージェントまたはユーザーにロールを割り当て、定義された責任に基づいて特定のデータセットまたは機能へのアクセスを許可します。
属性ベースのアクセス制御 (ABAC):データ、ユーザー、または環境の属性に基づいて動的なアクセスポリシーを実装し、適応性の高いコンテキスト認識型のセキュリティを実現します。
ドキュメントレベルのセキュリティ (DLS) とフィールドレベルのセキュリティ (FLS):これらの機能により、取得したドキュメント内でも許可された部分のみが表示されるようになり、機密情報の漏洩を防止できます。
エンタープライズセキュリティとの統合:既存の ID 管理システム (LDAP、SAML、OIDC など) とシームレスに統合し、組織全体で一貫したセキュリティポリシーを適用します。

これらのセキュリティ対策をコンテキスト取得メカニズムに直接統合することで、Elastic は安全なゲートキーパーとして機能し、AI エージェントが定義されたデータ境界内で動作し、不正なデータ公開を防ぎ、データプライバシー規制へのコンプライアンスを維持できるようにします。これは、機密情報や独自情報を扱うエージェント AI システムへの信頼を構築する上で非常に重要です。

追加のボーナスとして、エンタープライズデータソース上で統合されたデータスピードレイヤーを使用することで、エージェントツールによって作成されるリポジトリでの予期しないアドホッククエリ負荷を軽減できます。ほぼリアルタイムであらゆるものを検索できる単一の場所と、セキュリティとガバナンスの制御を適用できる単一の場所が提供されます。

ハイブリッド検索ベースのツール

Elastic プラットフォームには、コンテキストエンジニアリングの追求を加速させるコア機能がいくつかあります (今後もさらに増える予定です)。ここで重要なのは、このプラットフォームが、AI エコシステムの進化に合わせて方法を適応、変更、拡張できる柔軟性を備え、さまざまな達成方法を提供していることです。

エージェントビルダーの紹介

Elastic Agent Builder は、Elastic にすでに保存されているデータと対話するために構築されたエージェント AI ツールの領域への最初の進出です。Agent Builder は、ユーザーが Kibana 内で独自のエージェントとツールを作成および管理できるようにするチャットインターフェースを提供します。組み込みの MCP および A2A サーバー、プログラム API、Elasticsearch インデックスのクエリと探索、および自然言語からの ES|QL クエリの生成用の一連の構築済みシステムツールが付属しています。Agent Builder を使用すると、表現力豊かなES|QLクエリ構文を通じてエージェントに返されるコンテキストデータをターゲットにして整形するカスタムツールを作成できます。

ES|QL はハイブリッド検索をどのように実行するのでしょうか?コア機能は、 semantic_textフィールドタイプとFORK / FUSEコマンドの組み合わせによって実現されます (FUSE はデフォルトでRRFを使用して各フォークの結果をマージします)。架空の製品検索の簡単な例を次に示します。

上記の例の各 FORK ブランチに含まれるEVAL句は厳密には必須ではありません。これは、特定の結果がどの検索モダリティから返されたかを追跡する方法を示すためだけに含まれています。

検索テンプレート

独自の外部エージェントツールを Elastic デプロイメントにポイントするとします。また、ES|QL の代わりに、マルチステージリトリーバーを使用したり、開発した既存の DSL 構文を再利用したり、クエリが受け入れる入力、検索を実行するために使用される構文、および出力で返されるフィールドを制御できるようにしたいと考えています。検索テンプレートを使用すると、ユーザーは一般的な検索パターンの定義済み構造を定義できるため、データ取得の効率と一貫性が向上します。これは、定型コードの標準化と検索ロジックの高速な反復処理を可能にするため、検索 API と対話するエージェントツールにとって特に有益です。そして、これらの要素のいずれかを調整する必要がある場合は、検索テンプレートを更新するだけで、変更が実装されます。エージェントツールで実際に実行される検索テンプレートの例を探している場合は、Elasticsearch Labs のブログ「 MCP for intelligent search 」をご覧ください。このブログでは、外部 MCP サーバーからのツール呼び出しの背後で検索テンプレートが使用されています。

統合ワークフロー (最高!)

新しいエージェント AI の世界で最も扱いにくいことの 1 つは、半自律型で自己指向的な「推論」エージェントの非決定論的な性質です。コンテキストエンジニアリングは、エージェント AI にとって非常に重要な分野です。これは、エージェントが生成できる可能性のある結論を、私たちが知っている事実に絞り込むのに役立つ手法です。非常に正確で関連性の高いコンテキストウィンドウがあっても、(数値的事実の領域から外れると) エージェントの応答が完全に再現可能で信頼できるという安心感がまだ少し欠けています。

エージェントに対して同じリクエストを複数回実行すると、応答にわずかな違いがあるだけ で、回答は基本的に 同じになる可能性があります。これは通常、単純なクエリでは問題なく、ほとんど気づかれない程度で、コンテキストエンジニアリング手法を使用して出力を調整することができます。しかし、エージェントに要求するタスクが複雑になるにつれて、1 つ以上のサブタスクによって差異が生じ、最終結果がわずかに変わる可能性が高くなります。エージェント間のコミュニケーションにさらに依存するようになると、状況はさらに悪化し、差異が累積していくでしょう。これは、エージェントが対話するツールは、コンテキストデータを正確にターゲットにするために非常に柔軟かつ調整可能である必要があり、予期される出力形式で応答する必要があるという考えを再び示しています。また、多くのユースケースでは、エージェントとツールのやり取りを誘導する必要があることも示しています。ここでワークフローが登場します。

Elastic ではまもなく、プラットフォームの中核に完全にカスタマイズ可能なワークフローが組み込まれる予定です。これらのワークフローはエージェントやツールと双方向に操作できるため、ワークフローはエージェントやツールを呼び出すことができ、エージェントやツールはワークフローを呼び出すことができます。これらの機能が、すべてのデータが存在する同じ検索 AI プラットフォームに完全に統合されることで、ワークフローの可能性は大きく変化します。もうすぐ、もうすぐ登場です！

統合メモリバンクとしてのElastic

Elastic は、ほぼリアルタイムの検索向けに作られた分散データプラットフォームであるため、エージェント AI システムの長期メモリ機能を自然に実行します。組み込みの Agent Builder チャットエクスペリエンスにより、短期記憶とチャット履歴の追跡と管理も行えます。また、プラットフォーム全体が API ファーストであるため、エージェントのコンテキストウィンドウを圧倒する可能性のあるツールのコンテキスト出力を永続化するためのプラットフォームとして Elastic を利用する（そして後で参照できるようにする）ことは非常に簡単です。この手法は、コンテキストエンジニアリングの分野では「メモを取る」と呼ばれることもあります。

同じ検索プラットフォームに短期記憶と長期記憶の両方を持つことで、多くの本質的なメリットが生まれます。チャット履歴と永続的なコンテキスト応答を、将来のチャットのやり取りに対する意味的影響要因の一部として使用したり、脅威分析を実行したり、頻繁に繰り返されるツール呼び出しから自動的に生成される永続的なデータ製品を作成したりできるようになることを想像してみてください。可能性は無限です。

まとめ

大規模言語モデルの出現により、コンテンツを一致させる方法や、データを調査するために使用する手法が変化しました。私たちは、人間が自らの疑問に答えるために調査、状況の考慮、論理的推論を行う現在の世界から、それらのステップがエージェント AI によって大部分が自動化される世界へと急速に移行しつつあります。生成された回答を信頼するには、エージェントが応答を生成する際に最も関連性の高い 情報（主観的関連性の要素を含む）をすべて考慮したという保証が必要です。エージェント AI を信頼できるものにするための主な方法は、RAG とコンテキストエンジニアリング技術を通じて追加のコンテキストを取得するツールを基盤化することですが、それらのツールが最初の取得をどのように実行するかが応答の精度に非常に重要になる場合があります。

Elastic Search AI プラットフォームは、ハイブリッド検索の柔軟性と利点に加えて、エージェント AI の精度、パフォーマンス、スケーラビリティを向上させるいくつかの組み込み機能を提供します。つまり、Elastic はコンテキストエンジニアリングのさまざまな側面に対応する素晴らしいプラットフォームを実現します。検索プラットフォームを介したコンテキスト検索の標準化により、エージェントツールの操作がいくつかの面で簡素化されます。「速度を落としてスピードを上げる」という矛盾した表現と同様に、コンテキスト生成レイヤーの簡素化は、より高速で信頼性の高いエージェントAIを意味します。

コンテキストのためのYou Know - パートII：エージェントAIとコンテキストエンジニアリングの必要性

Woody Walton — Tue, 18 Nov 2025 00:00:00 GMT

LLM が情報検索の基本的なプロセスをどのように変えてきたかについての (かなり広範囲にわたる)背景を踏まえて、LLM がデータのクエリ方法をどのように変えてきたかを見てみましょう。

データと対話する新しい方法

ジェネレーティブ (genAI) AI とエージェント AI は、従来の検索とは異なる処理を行います。かつて私たちが情報を調べ始める方法は検索（「グーグルで検索してみます…」）でしたが、gen AI とエージェントの両方にとって、開始アクションは通常、チャットインターフェースに入力された自然言語を通じて行われます。チャットインターフェースは、意味理解を使用して質問を簡潔な回答、つまりあらゆる種類の情報に関する幅広い知識を持つ予言者から出されたような要約された応答に変換する LLM とのディスカッションです。本当に売れているのは、LLM が表面化した知識の断片をつなぎ合わせて首尾一貫した思慮深い文章を生成する能力です。たとえそれが不正確であったり完全に幻覚的であったりしても、そこには真実味があります。

私たちが使い慣れている古い検索バーは、私たち自身が推論エージェントであったときに使用した RAG エンジンと考えることができます。現在では、インターネット検索エンジンでさえ、使い古された「ハント・アンド・ペック」という語彙検索エクスペリエンスを、クエリに対する結果の要約で答える AI 主導の概要へと変えつつあり、ユーザーがクリックして個々の結果を自分で評価する必要がないようにしています。

生成AIとRAG

生成 AI は、世界の意味理解を活用してチャットリクエストを通じて表明された主観的な意図を解析し、推論能力を使用して専門的な回答を即座に作成します。生成 AI インタラクションにはいくつかの部分があります。ユーザーの入力/クエリから始まり、チャットセッションでの以前の会話が追加のコンテキストとして使用でき、LLM に推論方法と応答の構築手順を指示する指示プロンプトがあります。プロンプトは、「5 歳児に説明するように説明してください」という単純なタイプのガイダンスから、リクエストを処理する方法の完全な詳細へと進化しました。これらの内訳には、AI のペルソナ/役割、生成前の推論/内部思考プロセス、客観的な基準、制約、出力形式、対象者、および期待される結果を示すのに役立つ例の詳細を説明する個別のセクションが含まれることがよくあります。

ユーザーのクエリとシステムプロンプトに加えて、検索拡張生成 (RAG) は、「コンテキストウィンドウ」と呼ばれる追加のコンテキスト情報を提供します。RAG はアーキテクチャへの重要な追加機能であり、世界の意味理解において欠落している部分を LLM に通知するために使用します。

コンテキストウィンドウは、何を、どこに、どれだけ与えるかという点では、かなり細かい指定が必要になる場合があります。もちろん、どのコンテキストが選択されるかは非常に重要ですが、提供されたコンテキストの信号対雑音比やウィンドウの長さも重要です。

情報が少なすぎる

クエリ、プロンプト、またはコンテキストウィンドウに提供される情報が少なすぎると、LLM が応答を生成するための正しいセマンティックコンテキストを正確に判断できないため、幻覚が発生する可能性があります。また、ドキュメントチャンクサイズのベクトル類似性にも問題があります。つまり、短くて単純な質問は、ベクトル化された知識ベースにある豊富で詳細なドキュメントと意味的に一致しない可能性があります。Hypothetical Document Embeddings (HyDE)などのクエリ拡張手法が開発され、LLM を使用して、短いクエリよりも豊富で表現力豊かな仮説的な回答を生成します。もちろん、ここでの危険は、仮説文書自体が LLM を正しい文脈からさらに逸脱させる幻覚であるということです。

情報が多すぎる

私たち人間と同じように、コンテキストウィンドウに情報が多すぎると、LLM は重要な部分が何であるのかについて混乱し、圧倒されてしまう可能性があります。コンテキストオーバーフロー (または「コンテキストロット」) は、生成 AI 操作の品質とパフォーマンスに影響します。LLM の「注意予算」(作業メモリ) に大きな影響を与え、競合する多くのトークン間の関連性を薄めます。「コンテキスト腐敗」の概念には、LLM が位置の偏りを持つ傾向があるという観察も含まれます。つまり、LLM はコンテキストウィンドウの中央セクションのコンテンツよりも、コンテキストウィンドウの先頭または末尾のコンテンツを優先します。

気が散ったり矛盾したりする情報

コンテキストウィンドウが大きくなるほど、LLM が正しいコンテキストを選択して処理する妨げとなる余分な情報や矛盾した情報が含まれる可能性が高くなります。ある意味、これは「ガベージイン/ガベージアウト」の問題になります。つまり、ドキュメント結果セットをコンテキストウィンドウにダンプするだけで、LLM に処理すべき大量の情報が提供されます (多すぎる可能性があります)。ただし、コンテキストの選択方法によっては、矛盾した情報や無関係な情報が入り込む可能性が高くなります。

エージェント型AI

カバーすべき内容がたくさんあると言いましたが、ついにエージェント AI のトピックについて話すことができました。エージェント AI は、LLM チャットインターフェイスの非常にエキサイティングな新しい使用法であり、独自の知識とユーザーが提供するコンテキスト情報に基づいて応答を合成する生成 AI (すでに「レガシー」と呼んでもいいでしょうか?) の機能を拡張します。生成 AI が成熟するにつれて、当初は人間が簡単に確認/検証できる、面倒でリスクの低いアクティビティに限定されていた、一定レベルのタスク処理と自動化を LLM に実行させることができることに気付きました。短期間で、当初のスコープは拡大しました。LLM チャットウィンドウは、AI エージェントが自律的に計画、実行し、指定された目標を達成するためにその計画を反復的に評価および適応させるきっかけとなることができるようになりました。エージェントは、LLM 自身の推論、チャット履歴、思考メモリ (現状のまま) にアクセスでき、その目標達成に向けて活用できる特定のツールも利用できます。また、トップレベルのエージェントが、それぞれ独自のロジックチェーン、命令セット、コンテキスト、ツールを持つ複数のサブエージェントのオーケストレーターとして機能することを可能にするアーキテクチャも登場しています。

エージェントは、ほぼ自動化されたワークフローへのエントリポイントです。エージェントは自己主導型であり、ユーザーとチャットしてから「ロジック」を使用して、ユーザーの質問に答えるために使用できるツールを決定します。ツールは通常、エージェントに比べて受動的であると考えられており、1 種類のタスクを実行するために構築されています。ツールが実行できるタスクの種類はほぼ無限です (これは本当に素晴らしいことです!) が、ツールが実行する主なタスクは、エージェントがワークフローを実行する際に考慮するコンテキスト情報を収集することです。

技術としては、エージェント AI はまだ初期段階にあり、注意欠陥障害に相当する LLM になりがちです。つまり、指示されたことをすぐに忘れてしまい、指示にまったく含まれていない他の作業に走り出してしまうことがよくあります。一見魔法のように見えますが、LLM の「推論」機能は、シーケンス内で次に最も可能性の高いトークンを予測することに基づいています。推論（あるいは将来的には、汎用人工知能（AGI））が信頼できるものになるためには、正確で最新の情報が与えられたときに、私たちが期待する通りに推論してくれるか（そしておそらく、私たち自身では考えつかなかったようなちょっとした追加情報を提供してくれるか）を検証できなければなりません。これを実現するには、エージェントアーキテクチャに、明確に通信する機能 (プロトコル)、指定されたワークフローと制約を順守する機能 (ガードレール)、タスク内の位置を記憶する機能 (状態)、使用可能なメモリ領域を管理する機能、応答が正確でありタスクの基準を満たしていることを検証する機能が必要になります。

私に理解できる言語で話してください

新しい開発分野ではよくあることですが (特に LLM の世界ではそうです)、当初はエージェントとツール間の通信にはかなり多くのアプローチがありましたが、すぐにモデルコンテキストプロトコル (MCP) が事実上の標準として採用されました。モデルコンテキストプロトコルの定義はまさにその名前の通りで、 モデルが コンテキスト 情報を要求および受信するために使用する プロトコル です。MCP は、LLM エージェントが外部ツールやデータソースに接続するためのユニバーサルアダプタとして機能し、さまざまな LLM フレームワークやツールが簡単に相互運用できるように API を簡素化および標準化します。そのため、MCP は、エージェントが目的を達成するために自律的に実行するために与えられるオーケストレーションロジックとシステムプロンプトと、より分離された形式 (少なくとも開始エージェントに関しては分離された形式) で実行するためにツールに送信される操作との間の、一種のピボットポイントになります。

このエコシステムは非常に新しいため、あらゆる方向への拡大が新たなフロンティアのように感じられます。エージェント間のインタラクション（もちろんAgent2Agent (A2A) ）用の類似プロトコルのほか、エージェントの推論メモリを改善するプロジェクト（ ReasoningBank ）、手元のジョブに最適な MCP サーバーを選択するプロジェクト（ RAG-MCP ）、ゼロショット分類や入力と出力のパターン検出などのセマンティック分析をガードレールとして使用してエージェントが操作できる内容を制御するプロジェクトもあります。

これらの各プロジェクトの根本的な目的は、エージェント/genAI コンテキストウィンドウに返される情報の品質と制御を向上させることであることにお気づきでしょうか。エージェント AI エコシステムは、コンテキスト情報をより適切に処理する (制御、管理、操作する) 能力の開発を継続していますが、エージェントが処理するための最も関連性の高いコンテキスト情報を取得する必要性は常に存在します。

コンテキストエンジニアリングへようこそ!

生成 AI の用語に詳しい方なら、おそらく「プロンプトエンジニアリング」という言葉を聞いたことがあるでしょう。現時点では、プロンプトエンジニアリングはそれ自体がほぼ疑似科学となっています。プロンプトエンジニアリングは、LLM が応答を生成する際に使用する動作を積極的に記述するための最良かつ最も効率的な方法を見つけるために使用されます。「コンテキストエンジニアリング」は、「プロンプトエンジニアリング」の手法をエージェント側を超えて拡張し、MCP プロトコルのツール側で利用可能なコンテキストソースとシステムもカバーし、コンテキストの管理、処理、生成という幅広いトピックを扱います。

コンテキスト管理- 長時間実行される、またはより複雑なエージェントワークフロー全体で状態とコンテキストの効率を維持することに関連します。エージェントの目標を達成するために、タスクとツールの呼び出しを繰り返し計画、追跡、オーケストレーションします。エージェントが動作しなければならない「注意予算」は限られているため、コンテキスト管理は主に、コンテキストウィンドウを絞り込んでコンテキストの最大限の範囲と最も重要な部分 (精度と再現率) の両方をキャプチャするのに役立つ手法に関係しています。技術には、圧縮、要約、前のステップまたはツール呼び出しからのコンテキストを永続化して、後続のステップで追加のコンテキストのために作業メモリ内にスペースを確保することが含まれます。
コンテキスト処理- エージェントがすべてのコンテキストをある程度統一された方法で推論できるように、異なるソースから取得したコンテキストを統合、正規化、または調整するための論理的かつできればほとんどプログラム的な手順。基本的な作業は、すべてのソース (プロンプト、RAG、メモリなど) からのコンテキストを、エージェントが可能な限り効率的に使用できるようにすることです。
コンテキスト生成- コンテキスト処理が、取得したコンテキストをエージェントが使用できるようにすることであるならば、コンテキスト生成は、追加のコンテキスト情報を自由に、しかし制約付きで要求して受け取るための範囲をエージェントに提供します。

LLM チャットアプリケーションのさまざまな一時的な機能は、コンテキストエンジニアリングの高レベル機能に直接 (場合によっては重複して) マッピングされます。

指示 / システムプロンプト- プロンプトは、生成的 (またはエージェント的) AI アクティビティがユーザーの目標を達成するためにどのように思考を導くかを示す足場です。プロンプトはそれ自体がコンテキストです。単なる音声による指示ではなく、回答がユーザーの要求に完全に応えているかどうかを確認するために、応答する前に「段階的に考える」や「深呼吸する」などのタスク実行ロジックやルールも含まれることがよくあります。最近のテストでは、マークアップ言語はプロンプトのさまざまな部分を組み立てるのに非常に効果的であることが示されていますが、指示を曖昧になりすぎず、具体的になりすぎないように注意して調整する必要があります。LLM が適切なコンテキストを見つけるのに十分な指示を与える必要がありますが、予期しない洞察を見逃すほど規範的であってはなりません。
短期記憶(状態/履歴) - 短期記憶は、基本的にユーザーと LLM 間のチャットセッションのやり取りです。これらはライブセッションのコンテキストを絞り込むのに役立ち、将来の取得や続行のために保存できます。
長期記憶- 長期記憶は、複数のセッションにわたって役立つ情報で構成されている必要があります。また、RAG を通じてアクセスされるのはドメイン固有の知識ベースだけではありません。最近の研究では、以前のエージェント/生成 AI 要求の結果を使用して、現在のエージェントのやり取り内で学習および参照を行っています。長期記憶領域における最も興味深い革新のいくつかは、エージェントが中断したところから再開できるように、状態がどのように保存され、リンクされるかを調整することに関係しています。
構造化された出力- 認知には努力が必要なので、推論能力があっても、LLM が (人間と同じように) 考えるときにあまり努力を費やしたくないのは当然です。また、定義された API やプロトコルがない場合、ツール呼び出しから返されたデータを読み取る方法のマップ (スキーマ) を持つことは非常に役立ちます。構造化出力をエージェントフレームワークの一部として組み込むと、思考主導の解析の必要性が減り、マシン間のやり取りがより高速かつ信頼性が高くなるようになります。
利用可能なツール- ツールは、追加情報の収集 (エンタープライズデータリポジトリへの RAG クエリの発行、またはオンライン API 経由の RAG クエリの発行など) から、エージェントに代わって自動アクションを実行すること (エージェントからのリクエストの基準に基づいてホテルの部屋を予約するなど) まで、さまざまな処理を実行できます。ツールは、独自のエージェント処理チェーンを持つサブエージェントになることもできます。
検索拡張生成 (RAG) - RAG の「動的な知識統合」という説明がとても気に入っています。前述のように、RAG は LLM がトレーニング時にアクセスできなかった追加情報を提供するための手法であり、主観的なクエリに最も関連性の高い正しい答えを得るために最も重要だと考えられるアイデアを繰り返し述べたものです。

驚異的な宇宙のパワー、小さな居住空間！

エージェント AI には、探索すべき魅力的でエキサイティングな新しい領域が数多くあります。解決すべき従来のデータ検索および処理の問題はまだたくさんありますが、LLM の新時代に初めて日の目を見るようになったまったく新しい種類の課題もあります。私たちが現在取り組んでいる差し迫った問題の多くは、コンテキストエンジニアリング、つまり、LLM の限られた作業メモリ空間を圧迫することなく、必要な追加のコンテキスト情報を取得することに関係しています。

さまざまなツール (および他のエージェント) にアクセスできる半自律エージェントの柔軟性により、AI を実装するための非常に多くの新しいアイデアが生まれ、さまざまな方法でそれらを組み合わせることができるのかを推測するのは困難です。現在の研究のほとんどはコンテキストエンジニアリングの分野に属し、大量のコンテキストを処理および追跡できるメモリ管理構造の構築に重点を置いています。これは、LLM に解決してほしい深い思考の問題には、記憶することが極めて重要となる、複雑さが増し、実行時間が長く、多段階の思考ステップが含まれるためです。

この分野で現在行われている多くの実験では、エージェントの口を満たすための最適なタスク管理とツール構成を見つけようとしています。エージェントの推論チェーンにおける各ツール呼び出しは、そのツールの機能を実行するための計算と、制限されたコンテキストウィンドウへの影響の両方の点で累積的なコストを発生させます。LLM エージェントのコンテキストを管理する最新の技術の一部は、長時間実行されるタスクの蓄積されたコンテキストを圧縮/要約すると損失が 大きくなりすぎる「 コンテキストの崩壊」などの意図しない連鎖効果を引き起こしています。望ましい結果は、貴重なコンテキストウィンドウのメモリ領域に余分な情報が漏れることなく、簡潔で正確なコンテキストを返すツールです。

可能性が多すぎる

私たちはツール/コンポーネントを再利用するための柔軟性を備えた職務の分離を望んでいるため、特定のデータソースに接続するための専用のエージェントツールを作成することは完全に理にかなっています。各ツールは、1 つのタイプのリポジトリ、1 つのタイプのデータストリーム、または 1 つのユースケースのクエリに特化できます。しかし、注意してください。時間や費用を節約し、何かが可能であると証明しようとすると、LLM をフェデレーションツールとして使用する強い誘惑に駆られるでしょう... やめてください。私たちは以前にもその道を歩んだことがあります。フェデレーションクエリは、受信したクエリをリモートリポジトリが理解できる構文に変換する「ユニバーサルトランスレータ」のように機能し、その後、複数のソースからの結果を何らかの方法で合理化して一貫した応答を生成する必要があります。技術としてのフェデレーションは小規模では 問題なく 機能しますが、大規模で、特にデータがマルチモーダルである場合、フェデレーションは大きすぎるギャップを埋めようとします。

エージェントの世界では、エージェントがフェデレーターとなり、ツール (MCP 経由) がさまざまなリソースへの手動で定義された接続となります。専用のツールを使用して接続されていないデータソースにアクセスすることは、クエリごとにさまざまなデータストリームを動的に統合する強力な新しい方法のように思えるかもしれませんが、ツールを使用して複数のソースに同じ質問をすると、解決するよりも多くの問題が発生する可能性があります。これらのデータソースはそれぞれ、その下にある異なるタイプのリポジトリである可能性があり、それぞれが内部のデータを取得、ランク付け、保護するための独自の機能を備えています。もちろん、リポジトリ間のこうした差異、つまり「インピーダンスの不一致」により、処理負荷が増加します。また、矛盾する情報やシグナルが生じる可能性があり、スコアの不一致のように一見無害に見えるものでも、返されたコンテキストの重要性が大きく損なわれ、最終的に生成された応答の関連性に影響する可能性があります。

コンテキストスイッチはコンピュータにとっても難しい

エージェントを任務に送り出す場合、多くの場合、最初の任務はエージェントがアクセスできるすべての関連データを見つけることです。人間の場合と同様に、エージェントが接続する各データソースが類似していない分散した応答を返すと、取得したコンテンツから重要なコンテキストビットを抽出することに関連する認知負荷 (まったく同じ種類ではありませんが) が発生します。これには時間と計算がかかり、エージェントのロジックチェーンでは少しずつ蓄積されていきます。このことから、 MCPについて議論されているように、ほとんどのエージェントツールは、API (既知の入力と出力を持つ分離された関数で、さまざまな種類のエージェントのニーズをサポートするように調整された) のように動作する必要があるという結論に至ります。実際、 LLM にはコンテキストのためのコンテキストが必要であることにも気づき始めています。特に、自然言語を構造化構文に翻訳するようなタスクでは、参照できるスキーマがあれば、LLM は意味の点と点を結びつけるのがはるかに上手です (まさに RTFM!)。

7回裏ストレッチ！

ここでは、 LLM がデータの取得とクエリに与えた影響と、チャットウィンドウがエージェント AI エクスペリエンスへとどのように成熟しているかについて説明しました。これら 2 つのトピックを組み合わせて、最新の検索機能と取得機能を使用してコンテキストエンジニアリングの結果を改善する方法を見てみましょう。パート III へ進みます: コンテキストエンジニアリングにおけるハイブリッド検索の威力!

Elasticsearch で A2A プロトコルと MCP を使用して LLM エージェントニュースルームを作成する: パート I

Justin Castilla — Thu, 13 Nov 2025 00:00:00 GMT

はじめに

現在の LLM 対応システムは、単一モデルのアプリケーションから、専門のエージェントが連携して、現代のコンピューティングではこれまで不可能と思われていたタスクを達成する複雑なネットワークへと急速に進化しています。これらのシステムの複雑さが増すにつれて、エージェントの通信とツールへのアクセスを可能にするインフラストラクチャが開発の主な焦点になります。これらのニーズに対応するために、マルチエージェント調整用のAgent2Agent (A2A)プロトコルと、標準化されたツールおよびリソースアクセス用のModel Context Protocol (MCP) という2 つの補完的なアプローチが登場しました。

それぞれの機能をいつ、またいつ単独で、調和して使用するかを理解することは、アプリケーションのスケーラビリティ、保守性、および有効性に大きな影響を与える可能性があります。この記事では、専門の LLM エージェントが協力してニュース記事の調査、執筆、編集、公開を行うデジタルニュースルームの実際の例を通して、 A2Aの概念と実装について説明します。

付属のリポジトリはここにあります。セクション 5 の最後の方で、A2A の実際の動作の具体的な例を検討します。

要件

リポジトリは、A2A エージェントの Python ベースの実装で構成されています。Flask には API サーバーが用意されているほか、ログ記録や UI 更新のメッセージをルーティングする Event Hub というカスタム Python メッセージングサービスも用意されています。最後に、ニュースルームの機能をスタンドアロンで使用するための React UI が提供されます。実装を容易にするために、すべてが Docker イメージ内に含まれています。マシンで直接サービスを実行する場合は、次のテクノロジがインストールされていることを確認してください。

言語とランタイム

Python 13.12 - コアバックエンド言語
Node.js 18+ - オプションのReact UI

コアフレームワークと SDK:

A2A SDK 0.3.8 - エージェントの調整と通信
Anthropic SDK - AI生成のためのClaude統合
Uvicorn - エージェントを実行するためのASGIサーバー
FastMCP 2.12.5+ - MCP サーバーの実装
React 18.2 - フロントエンドUIフレームワーク

データと検索

Elasticsearch 9.1.1 以上- 記事のインデックス作成と検索

Docker のデプロイメント (オプションですが推奨)

Docker 28.5.1 以上

セクション 1: Agent2Agent (A2A) とは何ですか?

定義とコアコンセプト

Agent2Agent (A2A) は、独立した LLM エージェント間の相互作用のための標準化されたプロトコルです。A2A は、すべてのタスクを処理する単一のモノリシックシステムではなく、複数の専門エージェントが通信、調整、および連携して、単一のエージェントでは効率的に処理するのが困難、遅い、またはまったく不可能な複雑なワークフローを実現できるようにします。

公式仕様: https://a2a-protocol.org/latest/specification/

起源と進化

エージェント間通信、つまりマルチエージェントシステムの概念は、数十年前に遡る分散システム、マイクロサービス、およびマルチエージェントの研究に根ざしています。分散型人工知能の初期の研究は、交渉、調整、共同作業ができるエージェントの基盤を築きました。これらの初期のシステムは、大規模な社会シミュレーション、学術研究、電力網管理に特化していました。

LLM が利用可能になり、運用コストが削減されたことで、Google や AI 研究コミュニティ全体の支援を受けて、マルチエージェントシステムが「プロシューマー」市場で利用可能になりました。現在 Agent2Agent システムとして知られている A2A プロトコルの追加により、複数の大規模言語モデルが取り組みとタスクを調整する時代に合わせて特別に設計された最新の標準へと進化しました。

A2A プロトコルは、LLM が接続して通信するインタラクションポイントに一貫した標準と原則を適用することで、エージェント間のシームレスな通信と調整を保証します。この標準化により、異なる開発者のエージェントが、異なる基盤モデルを使用して、効果的に連携できるようになります。

通信プロトコルは新しいものではなく、インターネット上で行われるほぼすべてのデジタル取引に広く定着しています。https://www.elastic.co/search-labsと入力した場合この記事にアクセスするためにブラウザにログインすると、TCP/IP、HTTP トランスポート、DNS ルックアッププロトコルがすべて実行され、一貫したブラウジングエクスペリエンスが保証される可能性が高くなります。

主な特徴

A2A システムは、スムーズな通信を確保するためにいくつかの基本原則に基づいて構築されています。これらの原則に基づいて構築することで、異なる LLM、フレームワーク、プログラミング言語に基づくさまざまなエージェントがすべてシームレスに対話できるようになります。

主な原則は次の 4 つです。

メッセージパッシング: エージェントは、明確に定義されたプロパティとフォーマットを持つ構造化されたメッセージを通じて通信します。
調整: エージェントは、他のエージェントをブロックすることなく、タスクを互いに委任し、依存関係を管理することで、複雑なワークフローを調整します。
専門分野: 各エージェントは特定のドメインまたは機能に焦点を合わせ、その分野の専門家となり、そのスキルセットに基づいてタスクの完了を提供します。
分散状態: 状態と知識は集中化されるのではなくエージェント間に分散され、エージェントはタスクの状態と部分的な戻り値(成果物)の進捗状況を相互に更新する機能を持ちます。

ニュースルーム：実例

ジャーナリズムのさまざまな側面に特化した AI エージェントによって駆動されるデジタルニュースルームを想像してみてください。

ニュースチーフ（コーディネーター/クライアント）：ストーリーを割り当て、ワークフローを監督する
記者エージェント：調査やインタビューに基づいて記事を書く
研究エージェント: 事実、統計、背景情報を収集します
アーカイブエージェント: Elasticsearchを使用して過去の記事を検索し、傾向を特定します
エディターエージェント: 記事の品質、スタイル、SEO最適化をレビューします
パブリッシャーエージェント: 承認された記事をCI/CD経由でブログプラットフォームに公開します。

これらのエージェントは単独では機能しません。ニュースチーフが再生可能エネルギーの導入についての記事を割り当てる場合、記者は統計を収集する研究者、草稿を確認する編集者、そして最終記事を公開する発行者を必要とします。この調整は A2A プロトコルを通じて行われます。

セクション2: A2Aアーキテクチャの理解

クライアントエージェントとリモートエージェントの役割

A2A アーキテクチャでは、エージェントは主に 2 つの役割を担います。クライアントエージェントは、タスクを策定し、システム内の他のエージェントに伝達する役割を担います。リモートエージェントとその機能を識別し、この情報を使用してタスクの委任について十分な情報に基づいた決定を下します。クライアントエージェントはワークフロー全体を調整し、タスクが適切に分散され、システムが目標に向かって進行することを保証します。

対照的に、リモートエージェントは、クライアントによって委任されたタスクを実行します。リクエストに応じて情報を提供したり特定のアクションを実行したりしますが、独自にアクションを開始することはありません。リモートエージェントは、割り当てられた責任を果たすために必要に応じて他のリモートエージェントと通信し、特殊な機能の共同ネットワークを作成することもできます。

私たちのニュースルームでは、ニュースチーフがクライアントエージェントとして機能し、レポーター、リサーチャー、エディター、パブリッシャーはリクエストに応答し、互いに調整するリモートエージェントとして機能します。

コアA2A機能

A2A プロトコルは、マルチエージェントのコラボレーションを可能にするいくつかの機能を定義します。

1. 発見

A2A サーバーは、クライアントが特定のタスクにいつどのようにサーバーを利用できるかがわかるように、その機能をアナウンスする必要があります。これは、エージェントの能力、入力、出力を記述する JSON ドキュメントであるエージェントカードを通じて実現されます。エージェントカードは、一貫性のあるよく知られたエンドポイント (推奨される/.well-known/agent-card.jsonエンドポイントなど) で利用できるようになり、クライアントはコラボレーションを開始する前にエージェントの機能を検出して照会できるようになります。

以下は、Elastic のカスタムアーカイブエージェント「Archie Archivist」のエージェントカードの例です。Elastic などのソフトウェアプロバイダーは A2A エージェントをホストし、アクセス用の URL を提供していることに注意してください。

{ "name": "Archie Archivist", "description": "Helps find historical news documents in the Elasticsearch Index of archived news articles and content.", "url": "https://xxxxxxxxxxxxx-abc123.kb.us-central1.gcp.elastic.cloud/api/agent_builder/a2a/archive-agent", "provider": { "organization": "Elastic", "url": "https://elastic.co" }, "version": "0.1.0", "protocolVersion": "0.3.0", "preferred_transport": "JSONRPC", "documentationURL": "https://www.elastic.co/docs/solutions/search/agent-builder/a2a-server" "capabilities": { "streaming": false, "pushNotifications": false, "stateTransitionHistory": false }, "skills": [ { "id": "platform.core.search", "name": "platform.core.search", "description": "A powerful tool for searching and analyzing data within your Elasticsearch cluster.", "inputModes": ["text/plain", "application/json"], "outputModes": ["text/plain", "application/json"] }, { "id": "platform.core.index_explorer", "name": "platform.core.index_explorer", "description": "List relevant indices, aliases and datastreams based on a natural language query.", "inputModes": ["text/plain", "application/json"], "outputModes": ["text/plain", "application/json"] } ], "defaultInputModes": ["text/plain"], "defaultOutputModes": ["text/plain"] }

このエージェントカードでは、Elastic のアーカイブエージェントのいくつかの重要な側面について説明します。エージェントは自身を「Archie Archivist」と名乗り、Elasticsearch インデックス内の過去のニュース文書の検索を支援するという目的を明確に述べています。カードはプロバイダー (Elastic) とプロトコルバージョン (0.3.0) を指定し、他の A2A 準拠エージェントとの互換性を確保します。最も重要なのは、 skills配列が、強力な検索機能やインテリジェントなインデックス探索など、このエージェントが提供する特定の機能を列挙していることです。各スキルはサポートする入力モードと出力モードを定義し、クライアントがこのエージェントと通信する方法を正確に理解できるようにします。このエージェントは Elastic の Agent Builder サービスから派生したもので、データストアからデータを取得するだけでなく、データストアと対話するためのネイティブ LLM 対応ツールと API エンドポイントのスイートを提供します。Elasticsearch の A2A エージェントへのアクセスについては、こちらをご覧ください。

2. 交渉

クライアントとエージェントは、適切なユーザーインタラクションとデータ交換を確保するために、コミュニケーション方法 (インタラクションがテキスト、フォーム、iframe、またはオーディオ/ビデオを介して行われるかどうか) について合意する必要があります。このネゴシエーションはエージェントのコラボレーションの開始時に行われ、ワークフロー全体にわたるエージェントの相互作用を管理するプロトコルを確立します。たとえば、音声ベースのカスタマーサービスエージェントはオーディオストリーム経由での通信をネゴシエートする可能性がありますが、データ分析エージェントは構造化された JSON を好む可能性があります。交渉プロセスにより、両当事者がそれぞれの能力と現在のタスクの要件に適した形式で情報を効果的に交換できるようになります。

上記の JSON スニペットにリストされている機能にはすべて入力スキーマと出力スキーマがあり、これらによって、他のエージェントからこのエージェントと対話する方法の期待値が設定されます。

3. タスクと状態の管理

クライアントとエージェントには、タスク実行全体を通じてタスクのステータス、変更、依存関係を通信するためのメカニズムが必要です。これには、タスクの作成と割り当てから進捗状況の更新とステータスの変更までのタスクのライフサイクル全体の管理が含まれます。一般的なステータスには、保留中、進行中、完了、失敗などの状態が含まれます。また、システムは、依存タスクが開始する前に前提条件となる作業が完了していることを確認するために、タスク間の依存関係を追跡する必要があります。エラー処理と再試行ロジックも重要なコンポーネントであり、システムが障害から正常に回復し、主な目標に向かって前進し続けることを可能にします。

タスクメッセージの例:

{ "message_id": "msg_789xyz", "message_type": "task_request", "sender": "news_chief", "receiver": "researcher_agent", "timestamp": "2025-09-30T10:15:00Z", "payload": { "task_id": "task_456abc", "capability": "fact_gathering", "parameters": { "query": "renewable energy adoption rates in Europe 2024", "sources": ["eurostat", "iea", "ember"], "depth": "comprehensive" }, "context": { "story_id": "story_123", "deadline": "2025-09-30T18:00:00Z", "priority": "high" } } }

このサンプルタスクメッセージは、A2A 通信のいくつかの重要な側面を示しています。

メッセージ構造には、一意のメッセージ識別子、送信されるメッセージの種類、送信者と受信者の識別、追跡およびデバッグ用のタイムスタンプなどのメタデータが含まれます。
ペイロードには実際のタスク情報が含まれており、リモートエージェントで呼び出される機能を指定し、その機能を実行するために必要なパラメータを提供します。
コンテキストセクションでは、受信側エージェントが広範なワークフローを理解するのに役立つ追加情報が提供されます。これには、エージェントがリソースを割り当てて作業をスケジュールする方法を示す期限や優先度レベルなどが含まれます。

4. コラボレーション

クライアントとエージェントは、動的かつ構造化されたインタラクションをサポートし、エージェントがクライアント、他のエージェント、またはユーザーに説明、情報、またはサブアクションを要求できるようにする必要があります。これにより、エージェントが最初の指示が曖昧な場合にフォローアップの質問をしたり、より適切な決定を下すために追加のコンテキストを要求したり、より適切な専門知識を持つ他のエージェントにサブタスクを委任したり、完全なタスクに進む前にフィードバック用の中間結果を提供したりできる共同作業環境が作成されます。この多方向のコミュニケーションにより、エージェントは孤立して作業するのではなく、継続的な対話に参加してより良い結果を得ることができます。

分散型ピアツーピア通信

A2A は、エージェントが異なる組織によってホストされ、一部のエージェントが社内で管理され、他のエージェントがサードパーティのサービスによって提供される分散通信を可能にします。これらのエージェントは、複数のクラウドプロバイダーまたはオンプレミスのデータセンターにまたがる可能性のある、さまざまなインフラストラクチャで実行できます。エージェントによっては、GPT モデルを活用したエージェント、Claude を活用したエージェント、オープンソースの代替手段を活用したエージェントなど、基盤となる LLM が異なる場合があります。エージェントは、データ主権の要件に準拠したり、待ち時間を削減したりするために、異なる地理的領域にまたがって動作する場合もあります。この多様性にもかかわらず、すべてのエージェントは情報を交換するための共通の通信プロトコルに同意し、実装の詳細に関係なく相互運用性を保証します。この分散アーキテクチャにより、システムの構築と展開に柔軟性が提供され、組織は特定のニーズに合わせて最適なエージェントとインフラストラクチャを組み合わせることができます。

これはニュースルームアプリケーションの最終的なアーキテクチャです。

セクション3: モデルコンテキストプロトコル (MCP)

定義と目的

モデルコンテキストプロトコル (MCP) は、Anthropic によって開発された標準化されたプロトコルであり、ユーザー定義のツール、リソース、プロンプト、その他の補足的なコードベースの追加機能を使用して個々の LLM を強化および強化します。MCP は、言語モデルと、タスクを効果的に完了するために必要な外部リソースとの間のユニバーサルインターフェイスを提供します。この記事では、ユースケース、新たなトレンド、Elastic 独自の実装の例を挙げて、MCP の現状を概説します。

MCPのコアコンセプト

MCP は、次の 3 つの主要コンポーネントを持つクライアントサーバーアーキテクチャで動作します。

クライアント: MCP サーバーに接続してその機能にアクセスするアプリケーション (Claude Desktop やカスタム AI アプリケーションなど)。
サーバー: 言語モデルにリソース、ツール、プロンプトを公開するアプリケーション。各サーバーは、特定の機能またはデータソースへのアクセスを提供することに特化しています。
- ツール: モデルがデータベースの検索、外部APIの呼び出し、データに対する変換の実行などのアクションを実行するために呼び出すことができるユーザー定義関数
- リソース:モデルが読み取り可能なデータソース。動的または静的データが提供され、URI パターン (REST ルートに類似) 経由でアクセスされます。
- プロンプト:特定のタスクを実行するためにモデルをガイドする変数を含む再利用可能なプロンプトテンプレート。

リクエスト・レスポンスパターン

MCP は、REST API に似た、使い慣れた要求と応答の相互作用パターンに従います。クライアント (LLM) がリソースを要求するかツールを呼び出すと、MCP サーバーが要求を処理して結果を返します。LLM はこれを使用してタスクを続行します。周辺サーバーを備えたこの集中型モデルは、ピアツーピアのエージェント通信に比べて、よりシンプルな統合パターンを提供します。

ニュースルームのMCP

私たちのニュースルームの例では、個々のエージェントが MCP サーバーを使用して必要なツールとデータにアクセスします。

研究者エージェントは以下を使用します:
- ニュース API MCP サーバー (ニュースデータベースへのアクセス)
- ファクトチェックMCPサーバー（信頼できる情報源との照合による主張の検証）
- 学術データベース MCP サーバー (学術論文と研究)
レポーターエージェントは以下を使用します:
- スタイルガイド MCP サーバー (ニュースルームの執筆基準)
- テンプレート MCP サーバー (記事テンプレートとフォーマット)
- 画像ライブラリ MCP サーバー (ストック写真とグラフィック)
エディターエージェントは以下を使用します:
- 文法チェッカーMCPサーバー（言語品質ツール）
- 盗作検出MCPサーバー（独創性検証）
- SEO分析MCPサーバー（見出しとキーワードの最適化）
Publisher Agent は以下を使用します:
- CMS MCP サーバー (コンテンツ管理システム API)
- CI/CD MCP サーバー (デプロイメントパイプライン)
- Analytics MCP サーバー (追跡と監視)

セクション4: アーキテクチャの比較

A2Aを使用する場合

A2A アーキテクチャは、真のマルチエージェントコラボレーションを必要とするシナリオに優れています。調整を必要とする複数ステップのワークフローでは、特にタスクに複数の順次または並列ステップが含まれる場合、反復と改良が必要なワークフロー、およびチェックポイントと検証のニーズがあるプロセスの場合に、A2A から大きなメリットが得られます。私たちのニュースルームの例では、ストーリーのワークフローでは記者が記事を書く必要がありますが、特定の事実に対する信頼性が低い場合は研究者に繰り返し報告し、その後編集者に進み、最終的に発行者に渡す必要がある場合があります。

複数の領域にわたるドメイン固有の特化は、A2A のもう 1 つの強力な使用例です。より大きなタスクを達成するためにさまざまな分野の複数の専門家が必要であり、各エージェントがさまざまな側面に関する深いドメイン知識と専門的な推論機能を提供する場合、A2A はそれらの接続を行うために必要な調整フレームワークを提供します。ニュースルームはこれを完璧に例証しています。リサーチャーは情報収集、レポーターは執筆、編集者は品質管理を専門としており、それぞれが異なる専門知識を持っています。

自律的なエージェントの動作の必要性により、A2A は特に価値が高まります。独立した意思決定を行い、変化する状況に基づいて積極的な行動を示し、ワークフロー要件に動的に適応できるエージェントは、A2A アーキテクチャで成功します。特化された機能の水平スケーリングも重要な利点の 1 つです。単一の万能エージェントではなく、複数の特化エージェントが連携して動作し、同じエージェントの複数のインスタンスがサブタスクを非同期的に処理できます。たとえば、ニュースルームでニュース速報を取材しているとき、複数の記者エージェントが同時に同じニュースのさまざまな角度から取材することがあります。

最後に、真のマルチエージェントコラボレーションを必要とするタスクは A2A に最適です。これには、陪審員としての LLM 評価メカニズム、合意形成および投票システム、および最善の結果に到達するために複数の視点が必要となる共同問題解決が含まれます。

MCPを使用する場合

モデルコンテキストプロトコルは、単一の AI モデルの機能を拡張する場合に最適です。単一の AI モデルが複数のツールやデータソースにアクセスする必要がある場合、MCP は、集中型の推論と分散ツール、および簡単なツール統合を組み合わせた完璧なソリューションを提供します。私たちのニュースルームの例では、研究者エージェント (1 つのモデル) は、ニュース API、ファクトチェックサービス、学術データベースなど、標準化された MCP サーバーを介してアクセスされる複数のデータソースにアクセスする必要があります。

ツール統合の広範な共有と再利用性が重要になる場合は、標準化されたツール統合が優先されます。MCP は、一般的な統合の開発時間を大幅に短縮する、事前に構築された MCP サーバーのエコシステムを備えているため、この点で優れています。シンプルさと保守性が求められる場合、MCP の要求応答パターンは開発者に馴染みがあり、分散システムよりも理解やデバッグが容易で、運用上の複雑さも少なくなります。

最後に、MCP は、システムとのリモート通信を容易にするためにソフトウェアプロバイダーによって提供されることがよくあります。プロバイダーが提供するこれらの MCP サーバーは、独自のシステムへの標準化されたインターフェースを提供しながら、オンボーディングと開発時間を大幅に短縮し、カスタム API 開発よりも統合をはるかに簡単にします。

両方を使用する場合 (A2A ❤️ の MCP)

MCP 統合に関する A2A ドキュメントに記載されているように、多くの高度なシステムは A2A と MCP を組み合わせることでメリットを得られます。調整と標準化の両方を必要とするシステムは、ハイブリッドアプローチに最適です。A2A はエージェントの調整とワークフローオーケストレーションを処理し、MCP は個々のエージェントにツールアクセスを提供します。私たちのニュースルームの例では、エージェントは A2A を介して調整し、ワークフローは記者から研究者、編集者、そして発行者へと移行します。ただし、各エージェントは専用のツール用に MCP サーバーを使用するため、アーキテクチャが明確に分離されます。

ツールアクセスにそれぞれ MCP を使用する複数の特殊エージェントは、A2A によって処理されるエージェント調整レイヤーと、MCP によって管理されるツールアクセスレイヤーがある一般的なパターンを表します。このように関心事を明確に分離することで、システムの理解と保守が容易になります。

両方のアプローチを組み合わせることによる利点は非常に大きいです。特殊化、自律性、並列処理などのマルチエージェントシステムの組織的な利点が得られると同時に、ツールの統合やリソースアクセスなどの MCP の標準化とエコシステムの利点も享受できます。エージェント調整 (A2A) とリソースアクセス (MCP) は明確に区別されており、重要なのは、API アクセスなどの小規模なタスクのみには A2A は必要ないことです。MCP は、マルチエージェントオーケストレーションのオーバーヘッドなしで、これらのタスクを効率的に処理します。

FAQ: A2A vs. MCP - ユースケース

機能

エージェント2エージェント（A2A）

モデルコンテキストプロトコル（MCP）

ハイブリッド（A2A + MCP）

主な目標

マルチエージェント調整: 専門エージェントのチームが、複雑な複数ステップのワークフローで連携できるようにします。

単一エージェントの拡張: 外部ツール、リソース、およびデータを使用して、単一の LLM/エージェントの機能を拡張します。

組み合わせた強み: A2A がチームのワークフローを処理し、MCP が各チームメンバーにツールを提供します。

ニュースルームチームの例

ワークフローチェーン: ニュースチーフ → レポーター → リサーチャー → 編集者 → 発行者。これは調整レイヤーです。

個々のエージェントのツール: スタイルガイドサーバーとテンプレートサーバーにアクセスする Reporter Agent (MCP 経由)。これはツールアクセスレイヤーです。

完全なシステム: 記者は編集者 (A2A) と連携し、画像ライブラリ MCP サーバーを使用して記事のグラフィックを検索します。

いつどれを使うか

真のコラボレーション、反復、改良、または専門知識を複数のエージェントに分割する必要がある場合。

1 つのエージェントが複数のツールやデータソースにアクセスする必要がある場合、または独自のシステムとの標準化された統合が必要な場合。

マルチエージェントシステムの組織的利点と、MCP の標準化およびエコシステムの利点が必要な場合。

コアベネフィット

自律性とスケーリング: エージェントは独立して決定を下すことができ、システムは特殊な機能の水平スケーリングを可能にします。

シンプルさと標準化: 集中化された推論によりデバッグと保守が容易になり、リソースに対する汎用的なインターフェースが提供されます。

関心事の明確な分離: システムを理解しやすくなります: A2A = チームワーク、MCP = ツールアクセス。

まとめ

これは、データとツールへのサポートと外部アクセスを提供するために MCP サーバーで強化された A2A ベースのエージェントの実装を扱った 2 部構成の最初のセクションです。次の部分では、実際のコードを調べて、オンラインニュースルームのアクティビティをエミュレートするためにそれらが連携して動作する様子を示します。どちらのフレームワークも、それ自体で非常に有能で柔軟性に優れていますが、連携して動作することで、どれだけ互いを補完し合うかがわかります。

MastraとElasticsearchを使用してセマンティックリコールを備えた知識エージェントを構築する

JD Armada — Thu, 06 Nov 2025 00:00:00 GMT

コンテキストエンジニアリングは、信頼性の高い AI エージェントとアーキテクチャの構築においてますます重要になっています。モデルがどんどん良くなるにつれて、その有効性と信頼性はトレーニングされたデータに依存するのではなく、適切なコンテキストにどれだけ適切に基づいているかに依存するようになります。最も関連性の高い情報を適切なタイミングで取得して適用できるエージェントは、正確で信頼できる出力を生成する可能性がはるかに高くなります。

このブログでは、 Mastraを使用して、Elasticsearch をメモリおよび検索バックエンドとして使用し、ユーザーの発言を記憶し、後で関連情報を思い出すことができるナレッジエージェントを構築します。これと同じ概念を実際のユースケースに簡単に拡張できます。サポートエージェントが過去の会話や解決策を記憶し、特定のユーザーへの応答をカスタマイズしたり、以前のコンテキストに基づいてより迅速に解決策を提示したりできると考えてください。

ここから手順に従って、ステップごとに構築する方法を確認してください。迷ってしまったり、完成した例を実行したいだけの場合は、ここにあるリポジトリを確認してください。

マストラとは何ですか？

Mastra は、推論、メモリ、ツールの交換可能なパーツを備えた AI エージェントを構築するためのオープンソースの TypeScript フレームワークです。セマンティックリコール機能により、エージェントはメッセージをベクターデータベースに埋め込みとして保存することで、過去のやり取りを記憶して取り出すことができます。これにより、エージェントは長期的な会話のコンテキストと継続性を維持できます。Elasticsearch は効率的な高密度ベクトル検索をサポートしているため、この機能を有効にするのに最適なベクトルストアです。セマンティックリコールがトリガーされると、エージェントは関連する過去のメッセージをモデルのコンテキストウィンドウに引き出し、モデルが取得したコンテキストを推論と応答の基礎として使用できるようにします。

始めるために必要なもの

ノード v18+
Elasticsearch（バージョン8.15以降）
Elasticsearch APIキー
OpenAI APIキー

注: デモでは OpenAI プロバイダーを使用するため、これが必要になりますが、Mastra は他の AI SDK とコミュニティモデルプロバイダーをサポートしているため、設定に応じて簡単に交換できます。

Mastraプロジェクトの構築

プロジェクトの足場を提供するために、Mastra の組み込み CLI を使用します。次のコマンドを実行します。

npm create mastra@latest

次のような一連のプロンプトが表示されます。

1. プロジェクトに名前を付けます。

2. このデフォルト設定を維持することもできますし、空白のままにしておくこともできます。

3. このプロジェクトでは、OpenAI が提供するモデルを使用します。

4. すべての環境変数を、後のステップで設定する `.env` ファイルに保存するため、「今はスキップ」オプションを選択します。

5. このオプションをスキップすることもできます。

初期化が完了したら、次のステップに進むことができます。

依存関係のインストール

次に、いくつかの依存関係をインストールする必要があります。

npm install ai @ai-sdk/openai @elastic/elasticsearch dotenv

ai - JavaScript/TypeScript で AI モデル、プロンプト、ワークフローを管理するためのツールを提供するコア AI SDK パッケージ。Mastra は Vercel のAI SDK上に構築されているため、エージェントとのモデルのインタラクションを有効にするにはこの依存関係が必要です。
@ai-sdk/openai - AI SDK を OpenAI モデル (GPT-4、GPT-4o など) に接続し、OpenAI API キーを使用した API 呼び出しを可能にするプラグイン。
@elastic/elasticsearch - Node.js 用の公式 Elasticsearch クライアント、インデックス作成、検索、ベクター操作のために Elastic Cloud またはローカルクラスターに接続するために使用されます。
dotenv - .envから環境変数を読み込みますファイルをprocess.envにコピーし、API キーや Elasticsearch エンドポイントなどの資格情報を安全に挿入できるようになります。

環境変数の設定

プロジェクトのルートディレクトリに.envファイルが存在しない場合は作成します。あるいは、リポジトリに提供されている例.envをコピーして名前を変更することもできます。このファイルでは、次の変数を追加できます。

ELASTICSEARCH_ENDPOINT="your-endpoint-here" ELASTICSEARCH_API_KEY="your-key-here" OPENAI_API_KEY="your-key-here"

これで基本的な設定は完了です。ここから、エージェントの構築とオーケストレーションを開始できます。さらに一歩進んで、Elasticsearch をストアおよびベクター検索レイヤーとして追加します。

ベクターストアとしてElasticsearchを追加する

storesという新しいフォルダーを作成し、その中にこのファイルを追加します。Mastra と Elastic が公式の Elasticsearch ベクターストア統合を出荷する前に、 Abhi Aiyer (Mastra CTO) がElasticVectorと呼ばれるこの初期のプロトタイプクラスを共有しました。簡単に言えば、Mastra のメモリ抽象化を Elasticsearch の高密度ベクトル機能に接続することで、開発者はエージェントのベクトルデータベースとして Elasticsearch を導入できるようになります。

統合の重要な部分を詳しく見てみましょう。

Elasticsearchクライアントの取り込み

このセクションでは、 ElasticVectorクラスを定義し、標準デプロイメントとサーバーレスデプロイメントの両方をサポートする Elasticsearch クライアント接続を設定します。

export interface ElasticVectorConfig extends ClientOptions { /** * Explicitly specify if connecting to Elasticsearch Serverless. * If not provided, will be auto-detected on first use. */ isServerless?: boolean; /** * Maximum documents to count accurately when describing indices. * Higher values provide accurate counts but may impact performance on large indices. * * @default 10000 */ maxCountAccuracy?: number; } export class ElasticVector extends MastraVector { private client: Client; private isServerless: boolean | undefined; private deploymentChecked: boolean = false; private readonly maxCountAccuracy: number; constructor(config: ElasticVectorConfig) { super(); this.client = new Client(config); this.isServerless = config.isServerless; this.maxCountAccuracy = config.maxCountAccuracy ?? 10000; } }

ElasticVectorConfig extends ClientOptions: これにより、すべての Elasticsearch クライアントオプション ( node 、 auth 、 requestTimeoutなど) を継承し、カスタムプロパティを追加する新しい構成インターフェースが作成されます。つまり、ユーザーは、サーバーレス固有のオプションとともに、有効な Elasticsearch 構成を渡すことができるということです。
extends MastraVector: これにより、 ElasticVector 、すべてのベクターストア統合が準拠する共通インターフェースである Mastra の基本MastraVectorクラスから継承できるようになります。これにより、エージェントの観点から見ると、Elasticsearch は他の Mastra ベクターバックエンドと同じように動作するようになります。
private client: Client: これは、Elasticsearch JavaScript クライアントのインスタンスを保持するプライベートプロパティです。これにより、クラスはクラスターと直接通信できるようになります。
isServerless およびdeploymentChecked : これらのプロパティは連携して、サーバーレスまたは標準の Elasticsearch デプロイメントに接続されているかどうかを検出し、キャッシュします。この検出は最初の使用時に自動的に行われますが、明示的に構成することもできます。
constructor(config: ClientOptions): このコンストラクターは、構成オブジェクト (Elasticsearch の資格情報とオプションのサーバーレス設定を含む) を受け取り、それを使用してthis.client = new Client(config)行でクライアントを初期化します。
super(): これは Mastra の基本コンストラクターを呼び出すため、ログ記録、検証ヘルパー、およびその他の内部フックを継承します。

この時点で、Mastraは新しいベクターストアがあることを知っています。 ElasticVector

展開タイプの検出

インデックスを作成する前に、アダプターは標準の Elasticsearch を使用しているか Elasticsearch Serverless を使用しているかを自動的に検出します。サーバーレスデプロイメントでは手動でのシャード構成が許可されないため、これは重要です。

private async detectServerless(): Promise { // Return cached result if already detected if (this.deploymentChecked) { return this.isServerless ?? false; } // Use explicit configuration if provided if (this.isServerless !== undefined) { this.deploymentChecked = true; this.logger?.info( `Using explicit deployment type: ${this.isServerless ? 'Serverless' : 'Standard'}` ); return this.isServerless; } try { const info = await this.client.info(); // Primary detection: build flavor (most reliable) const isBuildFlavorServerless = info.version?.build_flavor === 'serverless'; // Secondary detection: tagline (fallback) const isTaglineServerless = info.tagline?.toLowerCase().includes('serverless') ?? false; this.isServerless = isBuildFlavorServerless || isTaglineServerless; this.deploymentChecked = true; this.logger?.info( `Auto-detected ${this.isServerless ? 'Serverless' : 'Standard'} Elasticsearch deployment`, { buildFlavor: info.version?.build_flavor, version: info.version?.number, detectionMethod: isBuildFlavorServerless ? 'build_flavor' : 'tagline' } ); return this.isServerless; } catch (error) { this.logger?.warn( 'Could not auto-detect deployment type, assuming Standard Elasticsearch. ' + 'Set isServerless: true explicitly in config if using Serverless.', { error: error instanceof Error ? error.message : String(error) } ); this.isServerless = false; this.deploymentChecked = true; return false; } }

何が起こっていますか：

まず、構成で明示的にisServerlessが設定されているかどうかを確認します (自動検出をスキップします)
Elasticsearch のinfo() API を呼び出してクラスター情報を取得します
build_flavor fieldをチェックします (サーバーレスデプロイメントはserverlessを返します)
ビルドフレーバーが利用できない場合はタグラインをチェックする
結果をキャッシュして、API 呼び出しの繰り返しを回避します。
検出に失敗した場合は標準展開をデフォルトとする

使用例:

// Option 1: Auto-detect (recommended) const vector = new ElasticVector({ node: 'https://your-cluster.es.cloud', auth: { apiKey: 'your-api-key' } }); // Detection happens automatically on first index operation // Option 2: Explicit configuration (faster startup) const vector = new ElasticVector({ node: 'https://your-serverless.es.cloud', auth: { apiKey: 'your-api-key' }, isServerless: true // Skips auto-detection });

Elasticsearchに「メモリ」ストアを作成する

以下の関数は、埋め込みを保存するための Elasticsearch インデックスを設定します。インデックスがすでに存在するかどうかを確認します。そうでない場合は、埋め込みとカスタム類似度メトリックを格納するためのdense_vectorフィールドを含む以下のマッピングを使用して作成します。

注意すべき点:

dimensionパラメータは各埋め込みベクトルの長さであり、使用している埋め込みモデルによって異なります。私たちの場合、サイズ1536のベクトルを出力する OpenAI のtext-embedding-3-smallモデルを使用して埋め込みを生成します。これをデフォルト値として使用します。
以下のマッピングで使用されるsimilarity変数は、ヘルパー関数 c onst similarity = this.mapMetricToSimilarity(metric)から定義されます。この関数は、 metricパラメータの値を受け取り、選択された距離メトリックの Elasticsearch 互換キーワードに変換します。
- たとえば、Mastra では、ベクトルの類似性を表すためにcosine 、 euclidean 、 dotproductなどの一般的な用語を使用します。メトリックeuclidean Elasticsearch マッピングに直接渡すと、Elasticsearch はキーワードl2_normがユークリッド距離を表すと想定するため、エラーが発生します。
サーバーレス互換性: サーバーレスデプロイメントのシャードとレプリカの設定は Elasticsearch Serverless によって自動的に管理されるため、コードでは自動的に省略されます。

async createIndex(params: CreateIndexParams): Promise { const { indexName, dimension = 1536, metric = 'cosine' } = params; try { const exists = await this.client.indices.exists({ index: indexName }); if (exists) { try { await this.validateExistingIndex(indexName, dimension, metric); this.logger?.info(`Index "${indexName}" already exists and is valid`); return; } catch (validationError) { throw new Error( `Index "${indexName}" exists but does not match the required configuration: ${ validationError instanceof Error ? validationError.message : String(validationError) }` ); } } const isServerless = await this.detectServerless(); const similarity = this.mapMetricToSimilarity(metric); const indexConfig: any = { index: indexName, mappings: { properties: { vector: { type: 'dense_vector', dims: dimension, index: true, similarity: similarity, }, metadata: { type: 'object', enabled: true, dynamic: true, // Allows flexible metadata structures }, }, }, }; // Only configure shards/replicas for non-serverless deployments // Serverless manages infrastructure automatically if (!isServerless) { indexConfig.settings = { number_of_shards: 1, number_of_replicas: 0, // Increase for production HA deployments }; } await this.client.indices.create(indexConfig); this.logger?.info( `Created ${isServerless ? 'Serverless' : 'Standard'} Elasticsearch index "${indexName}"`, { dimension, metric, similarity } ); } catch (error) { const errorMessage = error instanceof Error ? error.message : String(error); this.logger?.error(`Failed to create index "${indexName}": ${errorMessage}`); throw new Error(`Failed to create index "${indexName}": ${errorMessage}`); } }

やりとりの後に新しい記憶やメモを保存する

この関数は、各インタラクションの後に生成された新しい埋め込みをメタデータとともに取得し、Elastic のbulk API を使用してそれらをインデックスに挿入または更新します。bulk API は複数の書き込み操作を 1 つのリクエストにグループ化します。このインデックス作成パフォーマンスの向上により、エージェントのメモリが増加し続けても更新の効率が維持されます。

async upsert(params: UpsertVectorParams): Promise { const { indexName, vectors, metadata = [], ids } = params; try { // Generate unique IDs if not provided const vectorIds = ids || vectors.map((_, i) => `vec_${Date.now()}_${i}_${Math.random().toString(36).substr(2, 9)}` ); const operations = vectors.flatMap((vec, index) => [ { index: { _index: indexName, _id: vectorIds[index] } }, { vector: vec, metadata: metadata[index] || {}, }, ]); const response = await this.client.bulk({ refresh: true, operations, }); if (response.errors) { const erroredItems = response.items.filter((item: any) => item.index?.error); const erroredIds = erroredItems.map((item: any) => item.index?._id); const errorDetails = erroredItems.slice(0, 3).map((item: any) => ({ id: item.index?._id, error: item.index?.error?.reason || item.index?.error, type: item.index?.error?.type })); const errorMessage = `Failed to upsert ${erroredIds.length}/${vectors.length} vectors`; console.error(`${errorMessage}. Sample errors:`, JSON.stringify(errorDetails, null, 2)); this.logger?.error(errorMessage, { failedCount: erroredIds.length, totalCount: vectors.length, sampleErrors: errorDetails }); // Still return successfully inserted IDs const successfulIds = vectorIds.filter((id, idx) => !erroredIds.includes(id) ); if (successfulIds.length === 0) { throw new Error(`${errorMessage}. All operations failed. See logs for details.`); } return successfulIds; } this.logger?.info(`Successfully upserted ${vectors.length} vectors to "${indexName}"`); return vectorIds; } catch (error) { const errorMessage = error instanceof Error ? error.message : String(error); this.logger?.error(`Failed to upsert vectors to "${indexName}": ${errorMessage}`); throw new Error(`Failed to upsert vectors to "${indexName}": ${errorMessage}`); } }

意味的想起のための類似ベクトルのクエリ

この機能は、セマンティックリコール機能の中核です。エージェントはベクトル検索を使用して、インデックス内に保存されている類似の埋め込みを見つけます。

async query(params: QueryVectorParams): Promise { const { indexName, queryVector, topK = 10, filter, includeVector = false } = params; try { const knnQuery: any = { field: 'vector', query_vector: queryVector, k: topK, num_candidates: Math.max(topK * 10, 100), // Search more candidates for better recall }; // Apply metadata filters if provided if (filter) { knnQuery.filter = this.buildElasticFilter(filter); } const sourceFields = ['metadata']; if (includeVector) { sourceFields.push('vector'); } const response = await this.client.search({ index: indexName, knn: knnQuery, size: topK, _source: sourceFields, }); const results = response.hits.hits.map((hit: any) => ({ id: hit._id, score: hit._score || 0, metadata: hit._source?.metadata || {}, vector: includeVector ? hit._source?.vector : undefined, })); this.logger?.debug(`Query returned ${results.length} results from "${indexName}"`); return results; } catch (error) { const errorMessage = error instanceof Error ? error.message : String(error); this.logger?.error(`Failed to query vectors from "${indexName}": ${errorMessage}`); throw new Error(`Failed to query vectors from "${indexName}": ${errorMessage}`); } }

内部構造:

Elasticsearch のknn API を使用してkNN (k 近傍法) クエリを実行します。
入力クエリベクトルに類似する上位 K 個のベクトルを取得します。
オプションでメタデータフィルターを適用して結果を絞り込む (例: 特定のカテゴリまたは時間範囲内のみを検索する)
ドキュメント ID、類似度スコア、保存されたメタデータを含む構造化された結果を返します。

知識エージェントの作成

ElasticVector統合を通じて Mastra と Elasticsearch の接続を確認したので、次は Knowledge Agent 自体を作成しましょう。

フォルダーagents内に、 knowledge-agent.tsというファイルを作成します。まず、環境変数を接続し、Elasticsearch クライアントを初期化します。

import { Agent } from '@mastra/core/agent'; import { Memory } from '@mastra/memory'; import { openai } from '@ai-sdk/openai'; import { Client } from '@elastic/elasticsearch'; import { ElasticVector } from '../stores/elastic-store'; import dotenv from "dotenv"; dotenv.config(); const ELASTICSEARCH_ENDPOINT = process.env.ELASTICSEARCH_ENDPOINT; const ELASTICSEARCH_API_KEY = process.env.ELASTICSEARCH_API_KEY; //Error check for undefined credentials if (!ELASTICSEARCH_ENDPOINT || !ELASTICSEARCH_API_KEY) { throw new Error('Missing Elasticsearch credentials'); } //Check to see if a connection can be established const testClient = new Client({ node: ELASTICSEARCH_ENDPOINT, auth: { apiKey: ELASTICSEARCH_API_KEY }, }); try { await testClient.ping(); console.log('Connected to Elasticsearch successfully'); } catch (error: unknown) { if (error instanceof Error) { console.error('Failed to connect to Elasticsearch:', error.message); } else { console.error('Failed to connect to Elasticsearch:', error); } process.exit(1); } //Initialize the Elasticsearch vector store const vectorStore = new ElasticVector({ node: ELASTICSEARCH_ENDPOINT, auth: { apiKey: ELASTICSEARCH_API_KEY, }, //Optional: Explicitly set to true if using Elasticsearch Serverless to skip auto-detection and improve startup time //isServerless: true, });

ここでは、次の操作を行います。

dotenvを使用して、 .envファイルから変数を読み込みます。
Elasticsearch の資格情報が正しく挿入されているかどうかを確認し、クライアントへの接続を正常に確立できるかどうかを確認します。
Elasticsearch エンドポイントと API キーをElasticVectorコンストラクターに渡して、先ほど定義したベクターストアのインスタンスを作成します。
Elasticsearch Serverless を使用している場合は、オプションでisServerless: trueを指定します。これにより、自動検出手順がスキップされ、起動時間が短縮されます。省略した場合、アダプタは最初の使用時にデプロイメントタイプを自動的に検出します。

次に、Mastra のAgentクラスを使用してエージェントを定義します。

export const knowledgeAgent = new Agent({ name: 'KnowledgeAgent', instructions: 'You are a helpful knowledge assistant.', model: openai('gpt-4o'), memory: new Memory({ vector: vectorStore, //embedder used to create embeddings for each message embedder: 'openai/text-embedding-3-small', //set semantic recall options options: { semanticRecall: { topK: 3, // retrieve 3 similar messages messageRange: 2, // include 2 messages before/after each match scope: 'resource', }, }, }), });

定義できるフィールドは次のとおりです。

name そしてinstructions : アイデンティティと主な機能を与えます。
model: @ai-sdk/openaiパッケージを通じて OpenAI のgpt-4oを使用しています。
memory:
- vector: Elasticsearch ストアを指すので、埋め込みはそこから保存され、取得されます。
- embedder: 埋め込みを生成するためにどのモデルを使用するか
- semanticRecall オプションによってリコールの動作が決まります。
  - topK: 意味的に類似したメッセージを取得する数。
  - messageRange: 各マッチにどの程度の会話を含めるか。
  - scope: メモリの境界を定義します。

もうすぐ終わりです。新しく作成したエージェントを Mastra 構成に追加するだけです。index.tsというファイルで、ナレッジエージェントをインポートし、 agentsフィールドに挿入します。

export const mastra = new Mastra({ agents: { knowledgeAgent }, storage: new LibSQLStore({ // stores observability, scores, ... into memory storage, if it needs to persist, change to file:../mastra.db url: ":memory:", }), logger: new PinoLogger({ name: 'Mastra', level: 'info', }), telemetry: { // Telemetry is deprecated and will be removed in the Nov 4th release enabled: false, }, observability: { // Enables DefaultExporter and CloudExporter for AI tracing default: { enabled: true }, }, });

その他のフィールドには以下が含まれます。

storage: これは、実行履歴、観測性メトリック、スコア、キャッシュのための Mastra の内部データストアです。Mastra ストレージの詳細については、こちらをご覧ください。
logger: Mastra は、軽量の構造化 JSON ロガーであるPinoを使用します。エージェントの開始と停止、ツールの呼び出しと結果、エラー、LLM 応答時間などのイベントをキャプチャします。
observability: エージェントの AI トレースおよび実行の可視性を制御します。追跡対象:
- 各推論ステップの開始/終了。
- 使用されたモデルまたはツール。
- 入力と出力。
- スコアと評価

Mastra Studioでエージェントをテストする

おめでとうございます！ここまで到達したら、このエージェントを実行し、そのセマンティックリコール能力をテストする準備が整いました。幸いなことに、Mastra には組み込みのチャット UI が用意されているため、独自に構築する必要はありません。

Mastra 開発サーバーを起動するには、ターミナルを開いて次のコマンドを実行します。

npm run dev

サーバーの初期バンドルと起動が完了すると、Playground のアドレスが提供されるはずです。

このアドレスをブラウザに貼り付けると、Mastra Studio が表示されます。

knowledgeAgentのオプションを選択してチャットを開始してください。

すべてが正しく接続されているかどうかを確認するための簡単なテストでは、次のような情報を入力します。「チームは、主にエンタープライズ契約の更新により、10 月の売上実績が 12% 増加したと発表しました。次のステップは、中規模市場の顧客へのリーチを拡大することです。」次に、新しいチャットを開始して、「次に重点を置く必要があると言った顧客セグメントはどれですか?」などの質問をします。ナレッジエージェントは、最初のチャットで提供した情報を思い出せるはずです。次のような応答が表示されます。

このような応答が表示された場合、エージェントが以前のメッセージを Elasticsearch に埋め込みとして正常に保存し、後でベクトル検索を使用して取得したことを意味します。

エージェントの長期記憶ストアの検査

Mastra Studio のエージェント構成のmemoryタブに移動します。これにより、エージェントが時間の経過とともに何を学習したかを確認できます。Elasticsearch に埋め込まれて保存されるすべてのメッセージ、応答、およびやり取りは、この長期メモリの一部になります。過去のやり取りを意味的に検索して、エージェントが以前に学習した思い出の情報やコンテキストをすぐに見つけることができます。これは本質的には、エージェントがセマンティックリコール中に使用するメカニズムと同じものですが、ここではそれを直接検査できます。以下の例では、「sales」という用語を検索し、sales に関連する内容を含むすべてのインタラクションを取得しています。

まとめ

Mastra と Elasticsearch を接続することで、コンテキストエンジニアリングの重要なレイヤーであるメモリをエージェントに付与できます。セマンティックリコールを使用すると、エージェントは時間の経過とともにコンテキストを構築し、学習した内容に基づいて応答することができます。つまり、より正確で信頼性が高く、自然なやりとりが可能になります。

この早期の統合は単なる出発点にすぎません。ここで同じパターンを使用すると、過去のチケットを記憶しているサポートエージェント、関連ドキュメントを取得する内部ボット、会話の途中で顧客の詳細を思い出すことができる AI アシスタントなどが可能になります。当社は公式の Mastra 統合にも取り組んでおり、近い将来この組み合わせがさらにシームレスになる予定です。

次に何を構築するのか楽しみにしています。ぜひ試してみて、 Mastraとそのメモリ機能を調べ、発見したことをコミュニティと自由に共有してください。

Elastic MCP サーバー: あらゆる AI エージェントに Agent Builder ツールを公開

Jedr Blaszyk,Joe McElroy — Mon, 20 Oct 2025 00:00:00 GMT

Elastic Agent Builder は、Elasticsearch 内の独自のデータと深く統合されたツールとエージェントを作成するためのプラットフォームです。たとえば、内部ドキュメントに対してセマンティック検索を実行したり、観測ログを分析したり、セキュリティアラートを照会したりするツールを作成できます。

しかし、本当の魔法は、これらのカスタマイズされたデータ対応ツールを、ほとんどの時間を費やす環境に導入できたときに起こります。コードエディターエージェントが組織のプライベートナレッジベースに安全にアクセスできたらどうなるでしょうか?

ここで、モデルコンテキストプロトコル (MCP)が登場します。Elastic Agent Builder には、プラットフォーム内のツールへのアクセスを提供する組み込みの MCP サーバーが付属しています。

Elastic Agent Builder MCP サーバーを使用する理由は何ですか?

AI エージェントは非常に強力ですが、その知識は通常、トレーニングに使用されたデータとパブリックインターネット上でアクティブに検索できる情報に限定されます。彼らは、会社の内部設計ドキュメント、チーム固有のデプロイメントランブック、またはアプリケーションログの独自の構造については知りません。

課題は、AI アシスタントに必要な特殊なコンテキストを提供することです。これはまさに、MCP が解決するために設計された問題です。MCP は、AI モデルまたはエージェントが外部ツールを検出して使用できるようにするオープンスタンダードです。

これを実現するために、Elastic Agent Builder は組み込みの MCP サーバーを通じてカスタムツールをネイティブに公開します。つまり、 Cursor 、 VS Code 、 Claude Desktopなどの MCP 対応クライアントを、Elastic Agent Builder で構築した特殊なデータ対応ツールに簡単に接続できるということです。

MCP を使用する場合 (および使用しない場合)

Elastic Agent Builder には、さまざまな統合パターンをサポートするためのいくつかのプロトコルが含まれています。適切なものを選択することが、効果的な AI ワークフローを構築する鍵となります。

MCP を使用して 、専用のツールで AI エージェント ( Cursor や VS Code など) を拡張します。これは「独自のツールを持ち込む」アプローチであり、すでに使用しているアシスタントを強化して、プライベートデータに安全にアクセスできるようにします。MCP サーバーを通じて公開されるのはツールのみで、Elastic のエージェントはそれとは別です。
A2A プロトコルを 使用すると 、完全なカスタム Elastic Agent が他の自律エージェント ( Google の Gemini Enterprise など) と連携できるようになります。これはエージェント間の委任用であり、各エージェントは問題を解決するためにピアとして機能します。
カスタム アプリケーションを最初から構築するときに、完全なプログラム制御を行うには Agent Builder API を使用します。

IDE を離れずに社内ドキュメントから回答を得たい開発者にとって、MCP は最適です。

例: Agent Builder MCP サーバーを使用した Cursor のカスタムツール

私が日常的に使用している実際の例を見てみましょう。まず、社内のエンジニアリングドキュメントをクロールして、 elastic-dev-docsという Elasticsearch インデックスにインデックス付けしました。Agent Builder で使用できる汎用の組み込みツールを使用することもできますが、この特定のナレッジベースを照会するための独自のカスタムツールを作成します。

カスタムツールを構築する理由はシンプルです。制御と精度です。このアプローチにより、 elastic-dev-docsインデックスに対して高速でセマンティックなクエリを直接実行できるようになります。どのインデックスをターゲットにするか、データをどのように取得するかを完全に制御できます。

ここで、このカスタムナレッジベースを Cursor のような AI 搭載コードエディターで使用する方法を説明します。

ステップ1: Agent Builderでカスタムナレッジベースツールを作成する

まず、Agent Builder で新しいツールを作成します。明確で具体的なツールの説明は重要です。なぜなら、それが内部 Elastic Agent であれ、MCP 経由で接続する Cursor などの外部ツールであれ、あらゆる AI エージェントが適切なタスクのためにツールを検出し選択する方法だからです。

強力な説明は明確である必要があります。たとえば、「elastic-dev-docs インデックスでセマンティック検索を実行して、社内のエンジニアリングドキュメント、ランブック、リリース手順を検索します。」

これで、ツールは特定のインデックスに対してセマンティック検索を実行するように構成されます。保存すると、すぐに利用できるようになります。

外部に接続する前に、UI で直接テストできます。[テスト]ボタンをクリックするだけで、パラメータを手動で入力し、LLM の動作をエミュレートして、結果を検査し、すべてが正しく動作していることを確認します。

ステップ2: CursorをElastic MCPサーバーに接続する

Elastic Agent Builder は、安全な MCP エンドポイントを介して利用可能なすべてのツールを自動的に公開します。固有のサーバー URL は、Kibana 内のツール UI で見つけることができます。

Cursor に接続するには、この URL と認証用の Elastic API キー ( ES API キーの作成方法を参照) を構成ファイルに追加するだけです。認証には API キーを使用します。これにより、すべてのアクセス制御ルールを尊重し、ツールは付与した権限でのみ実行されるようになります。

カーソルの~/.cursor/mcp.json内の MCP 構成は次のようになります。

{ "mcpServers": { "elastic-agent-builder": { "command": "npx", "args": [ "mcp-remote", "https://your-kibana.kb.company.io/api/agent_builder/mcp", "--header", "Authorization:${AUTH_HEADER}" ], "env": { "AUTH_HEADER": "ApiKey " } } } }

設定が保存されると、Cursor で Elastic Agent Builder MCP サーバーツールが利用可能になります。

ステップ 3: どんどん質問しましょう!

接続が確立されると、カーソルエージェントはカスタムツールを呼び出して質問に答えたり、コード生成プロセスをガイドしたりできるようになります。

具体的な質問をしてみましょう。

「Elastic Search org のエンジニアリング内部ドキュメントからクローラーサービスをリリースするための手順を参照する」

舞台裏では魔法が起こります:

カーソルエージェントはあなたの質問に最もよく答える方法を決定し、 engineering_documentation_internal_search
自然言語クエリでツールを呼び出す
このツールは、 elastic-dev-docsインデックスに対してセマンティック検索を実行し、最も関連性の高い最新の手順を返します。

コードエディターを離れることなく、社内ドキュメントに基づいた正確で信頼できる回答が得られます。体験はシームレスかつ強力です。

あなたの番です

ここでは、Elastic Agent Builder に組み込まれている MCP サーバーを使用して、プライベートデータへの安全なアクセスを備えた AI アシスタントを拡張する方法を説明しました。モデルを本当に役立つものにするためには、独自の情報に基づいてモデルを構築することが鍵となります。

要約すると、主要な手順について説明しました。

ニーズに合った適切なプロトコルを選択する (MCP)。
カスタムナレッジベースツールを構築します。
そのツールを Cursor などの IDE アシスタントに接続します。

エージェントとツールを最も重要なコンテキストから切り離す必要がなくなりました。このガイドがより効果的でデータを考慮したワークフローの作成に役立つことを願っています。楽しい建築を！

AIエージェントの評価：Elasticによるエージェントフレームワークのテスト方法

Susan Chang,Abhimanyu Anand — Mon, 13 Oct 2025 00:00:00 GMT

はじめに

Elastic Stack には、 Agent Builderの近々リリースされる Elastic AI Agent (現在技術プレビュー) やAttack Discovery (8.18 および 9.0 以降でGA提供) など、LLM を利用したエージェントアプリケーションが多数あり、さらに多くのアプリケーションが開発中です。開発中、そして展開後でも、次の質問に答えることが重要です。

これらの AI アプリケーションの応答の品質をどのように評価するのでしょうか?
変更を加えた場合、その変更が本当に改善となり、ユーザーエクスペリエンスが低下しないことをどのように保証すればよいでしょうか。
これらの結果を繰り返し簡単にテストするにはどうすればよいでしょうか?

従来のソフトウェアテストとは異なり、生成 AI アプリケーションの評価には、統計的手法、微妙な定性的なレビュー、ユーザーの目標の深い理解が必要になります。

この記事では、Elastic 開発チームが評価を実施し、展開前に変更の品質を確保し、システムパフォーマンスを監視するために採用しているプロセスについて詳しく説明します。私たちは、あらゆる変更が証拠によって裏付けられ、信頼できる検証可能な結果につながるようにすることを目指しています。このプロセスの一部は Kibana に直接統合されており、オープンソース精神の一環として透明性への取り組みを反映しています。評価データと指標の一部を公開することで、コミュニティの信頼を育み、AI エージェントを開発したり当社の製品を利用したりするすべての人にとって明確なフレームワークを提供することを目指しています。

製品例

このドキュメントで使用した方法は、Attack Discovery や Elastic AI Agent などのソリューションを反復して改善する方法の基礎となりました。それぞれ2つの簡単な紹介:

Elastic Securityの攻撃検出

Attack Discovery は LLM を使用して、Elastic 内の攻撃シーケンスを識別および要約します。特定の期間（デフォルトでは 24 時間）内の Elastic Security アラートに基づいて、Attack Discovery のエージェントワークフローは、攻撃が発生したかどうかを自動的に検出するほか、どのホストまたはユーザーが侵害されたか、どのアラートが結論に寄与したかなどの重要な情報も検出します。

目標は、LLM ベースのソリューションが少なくとも人間と同等の出力を生成することです。

エラスティックAIエージェント

Elastic Agent Builder は、すべての検索機能を活用するコンテキスト認識型 AI エージェントを構築するための新しいプラットフォームです。この製品には、会話形式のやりとりを通じてユーザーがデータを理解し、データから回答を得られるよう設計された、あらかじめ構築された汎用エージェントであるElastic AI Agentが付属しています。

エージェントは、Elasticsearch または接続されたナレッジベース内の関連情報を自動的に識別し、事前に構築された一連のツールを活用してそれらと対話することでこれを実現します。これにより、Elastic AI Agent は、単一のドキュメントに関する単純な Q&A から、複数のインデックスにわたる集約や単一または複数ステップの検索を必要とする複雑なリクエストまで、さまざまなユーザークエリに応答できるようになります。

実験による改善の測定

AI エージェントのコンテキストでは、実験とは、明確に定義された次元 (有用性、正確性、遅延など) のパフォーマンスを向上させるように設計された、システムに対する構造化されたテスト可能な変更です。目標は、「この変更をマージした場合、それが真の改善であり、ユーザーエクスペリエンスを低下させないことを保証できますか?」という質問に明確に答えることです。

私たちが実施するほとんどの実験には、一般的に次のようなものが含まれます。

仮説:特定の、反証可能な主張。例: 「攻撃検出ツールへのアクセスを追加すると、セキュリティ関連のクエリの正確性が向上します。」
成功基準: 「成功」の意味を定義する明確なしきい値。例: 「セキュリティデータセットの正確性スコアが 5% 向上し、他の部分では低下は見られません。」
評価計画:成功の測定方法 (指標、データセット、比較方法)

成功した実験は体系的な調査プロセスです。小さなプロンプトの調整から大規模なアーキテクチャの変更まで、すべての変更は次の 7 つの手順に従い、結果が有意義かつ実用的なものになるようにします。

手順1：問題を特定する
ステップ2: 指標を定義する
ステップ3：明確な仮説を立てる
ステップ4: 評価データセットの準備
ステップ5: 実験を実行する
ステップ6: 結果の分析と反復
ステップ7：決定を下し、文書化する

これらのステップの例を図 1に示します。次のサブセクションでは各ステップについて説明します。各ステップの技術的な詳細については、今後のドキュメントで詳しく説明します。

実際の Elastic の例を使ったステップバイステップのウォークスルー

手順1：問題を特定する

この変更が解決しようとしている問題は正確には何でしょうか?

攻撃検出の例: 概要が不完全な場合や、無害なアクティビティが誤って攻撃としてフラグ付けされる (誤検知) 場合があります。

Elastic AI エージェントの例: 特に分析クエリの場合、エージェントのツール選択は最適ではなく一貫性がなく、間違ったツールが選択されてしまうことがよくあります。これにより、トークンのコストとレイテンシが増加します。

ステップ2: 指標を定義する

問題を測定可能にして、変化を現在の状態と比較できるようにします。

一般的な指標には、精度と再現率、意味的類似性、事実性などがあります。ユースケースに応じて、一致するアラート ID や正しく取得された URL などのメトリックを計算するためにコードチェックを使用したり、より自由形式の回答を得るために LLM-as-judge などの手法を使用したりします。

以下は、実験で使用されたメトリックの例です (網羅的ではありません)。

攻撃の検出

メトリック

説明

精度と再現率

実際の出力と予想される出力の間でアラート ID を一致させて、検出精度を測定します。

類似性

BERTScore を使用して、応答テキストの意味的類似性を比較します。

事実性

重要な IOC (侵害の兆候) は存在しますか?MITRE 戦術 (攻撃の業界分類) は正しく反映されていますか?

攻撃チェーンの一貫性

発見された数を比較して、攻撃の過剰報告または過少報告がないか確認します。

エラスティックAIエージェント

メトリック

説明

精度と再現率

ユーザーのクエリに回答するためにエージェントによって取得されたドキュメント/情報と、クエリに回答するために必要な実際の情報またはドキュメントを照合して、情報取得の精度を測定します。

事実性

ユーザーのクエリに回答するために必要な主要な事実は存在しますか?事実は手続き上のクエリに対して正しい順序になっていますか?

回答の関連性

応答には、ユーザーのクエリとは関連がない、または周辺的な情報が含まれていますか?

応答の完全性

応答はユーザークエリのすべての部分に答えていますか?応答にはグラウンドトゥルースに存在するすべての情報が含まれていますか?

ES|QL検証

生成された ES|QL は構文的に正しいですか?機能的にはグラウンドトゥルース ES|QL と同一ですか?

ステップ3：明確な仮説を立てる

上記で定義した問題と指標を使用して、明確な成功基準を確立します。

Elastic AI エージェントの例:

relevance_search および nl_search ツールの説明に変更を加え、それぞれの機能と使用例を明確に定義します。
ツールの呼び出し精度が 25% 向上する と予測しています。
他の指標に悪影響が及ばないことを保証し、これが純粋にプラスであることを確認します。事実性と完全性。
正確なツールの説明により、エージェントがさまざまなクエリタイプに最も適した検索ツールをより正確に選択して適用できるようになり、誤った適用が減り、全体的な検索の有効性が向上するため、この方法が効果的であると考えています。

ステップ4: 評価データセットの準備

システムのパフォーマンスを測定するために、現実世界のシナリオをキャプチャしたデータセットを使用します。

実施する評価の種類に応じて、LLMに供給される生データ（例：攻撃検出のための攻撃シナリオと予想される出力。アプリケーションがチャットボットの場合、入力はユーザークエリであり、出力は正しいチャットボット応答、取得されるべき正しいリンクなどになります。

攻撃検出の例:

10の斬新な攻撃シナリオ

Oh My Malware のエピソード 8 つ (ohmymalware.com)

4 つのマルチ攻撃シナリオ (最初の 2 つのカテゴリの攻撃を組み合わせて作成)

3つの良性のシナリオ

Elastic AI エージェント評価データセットの例 ( Kibana データセットリンク):

オープンソースデータセットを使用して KB 内の複数のソースをシミュレートする 14 のインデックス。

5 つのクエリタイプ (分析、テキスト検索、ハイブリッドなど)

7 つのクエリ意図タイプ（手続き型、事実型 - 分類型、調査型など）

ステップ5: 実験を実行する

評価データセットに対して既存のエージェントと修正バージョンの両方からの応答を生成して実験を実行します。事実性などの指標を計算します (手順 2 を参照)。

ステップ 2 で必要な指標に基づいて、さまざまな評価を組み合わせます。

ルールベースの評価（例：Python/TypeScriptを使用して.jsonが有効かどうかを確認します)
LLM が裁判官となる（回答が原文と事実上一致しているかどうかを別の LLM に尋ねる）
ニュアンス品質チェックのための人間によるレビュー

ステップ6: 結果の分析と反復

指標が得られたので、結果を分析します。結果がステップ 3 で定義された成功基準を満たしている場合でも、変更を本番環境にマージする前に人間によるレビューが行われます。結果が基準を満たしていない場合は、問題を反復して修正してから、新しい変更に対して評価を実行します。

マージする前に、最適な変更を見つけるために数回の反復が必要になると予想されます。コミットをプッシュする前にローカルソフトウェアテストを実行するのと同様に、オフライン評価はローカルの変更または複数の提案された変更で実行できます。分析を効率化するために、実験結果、複合スコア、視覚化の保存を自動化すると便利です。

ステップ7：決定を下し、文書化する

意思決定フレームワークと受け入れ基準に基づいて、変更のマージを決定し、実験を文書化します。意思決定は多面的であり、他のデータセットでの回帰シナリオの確認や、提案された変更の費用対効果の検討など、評価データセット以外の要素を考慮する場合があります。

例: いくつかの反復をテストして比較した後、最高スコアの変更を選択し、製品マネージャーやその他の関連する関係者に送信して承認を得ます。意思決定を支援するために、前の手順の結果を添付します。攻撃検出に関するその他の例については、「Elastic Security の生成 AI 機能の舞台裏」をご覧ください。

まとめ

このブログでは、実験ワークフローのエンドツーエンドのプロセスについて説明し、エージェントシステムの変更を Elastic ユーザーにリリースする前に評価およびテストする方法を説明しました。また、Elastic でのエージェントベースのワークフローの改善例もいくつか紹介しました。今後のブログ投稿では、適切なデータセットを作成する方法、信頼性の高いメトリックを設計する方法、複数のメトリックが関係する場合に意思決定を行う方法など、さまざまな手順の詳細を詳しく説明します。

A2Aプロトコルを介してElastic AgentsをGemini Enterpriseに接続する

Jedr Blaszyk,Valerio Arvizzigno,Joe McElroy — Thu, 09 Oct 2025 00:00:00 GMT

Elastic Agent Builder は、 Elasticsearch で直接データ駆動型の AI エージェントを作成するための機能セットです。このシリーズの以前の投稿では、カスタムエージェントに複雑なタスクを実行するツールを装備し、エージェントの動作をガイドする一連のカスタム指示を提供する方法を説明しました。

しかし、すでに使用しているアプリケーションや生産性ツールでカスタムエージェントを使用したい場合はどうすればよいでしょうか?

ここで、エージェント間 (A2A) プロトコルが登場します。A2A は相互運用性のためのオープンスタンダードであり、異なるプラットフォームのエージェント間の通信と共同作業を可能にします。そして、これを Elastic Agent Builder に直接組み込みました。

今日は、構築したカスタムエージェントを他のサービス、具体的にはGemini Enterprise (旧称 Agentspace) に公開する方法を紹介します。

オープンスタンダードの力：A2Aが重要な理由

ブログ記事「初めての Elastic Agent」では、市場データに安全にアクセスできるFinancial Assistantエージェントなどのカスタムエージェントの構築方法を説明しました。しかし、作業を再構築せずに、Gemini Enterprise などの他の環境でその洞察を利用できない場合、その価値は限られます。

この相互運用性の課題が、エージェント AI の実現を妨げているのです。エージェントはプラットフォーム間で通信するために共通言語を必要としますが、これがまさに A2A プロトコルの役割です。標準の通信レイヤーを提供することで、エージェントと直接対話できるだけでなく、組織全体の専門エージェントが連携して洞察を共有できる未来が開かれます。

これを実現するために、Elastic Agent Builder は、すべてのエージェントに対して 2 つの標準エンドポイントを通じて A2A プロトコルをネイティブにサポートしています。

エージェントカードエンドポイント ( GET {your-kibana-url}/api/agent_builder/a2a/{agentId}.json ) -これはカスタムエージェントの名刺として機能します。エージェントに関するメタデータ (名前、説明、機能など) を A2A 互換サービスに提供します。
A2A プロトコルエンドポイント ( POST {your-kibana-url}/api/agent_builder/a2a/{agentId} ) - これは通信チャネルです。他のエージェントはここにリクエストを送信し、エージェントはそれを処理して応答を返します。これらはすべてA2A プロトコル仕様に従って行われます。

A2Aインスペクターでエージェントをテストする

エージェントを本番システムに接続する前に、正しく通信していることを確認することをお勧めします。これを行う最も簡単な方法は、A2A 統合のテストとデバッグ専用に設計されたツールであるA2A Inspector を使用することです。

インスペクターを実行するのは簡単です。a2a-inspectorリポジトリのクローンを作成し、README の指示に従ってアプリケーションを実行できます。起動すると、UI はデフォルトでhttp://localhost:5001/で使用できるようになります。

A2A インスペクターをエージェントに接続するには、次の 2 つの重要な情報を提供する必要があります。

エージェントカード URL: これはエージェントを説明するエンドポイントです。前回の投稿の Financial Assistant エージェントの場合、この URL は{your-kibana-url}/api/agent_builder/a2a/financial_assistant.jsonになります。
認証ヘッダー: 認証には標準の API キーを使用します。

インスペクターの UI にこれらの詳細を入力すると、すぐにエージェントに接続してチャットを開始できます。

この簡単な検証により、エージェントが正しく構成され、次のステップの準備ができていることが保証されます。

ライブ配信しよう！Gemini Enterpriseのカスタムエージェント

次は、エキサイティングな部分です。カスタムファイナンシャルアドバイザーエージェントを Gemini Enterprise (旧 Agentspace) 内で実現します。この統合は、Google Cloud Marketplace で入手可能な Elastic AI Agentによって実現されています。

接続されると、Gemini Enterprise は A2A プロトコルを使用してエージェントと直接通信します。ここで相互運用性の真の威力が発揮されます。ユーザーは使い慣れた環境を離れることなく、カスタム Elasticsearch エージェントから得られる詳細なデータ駆動型の分析情報にアクセスできるようになります。エージェントリストにカスタム Elastic Agent が表示されます。

Gemini Enterprise のユーザーが次のように質問していると想像してください。

「市場のセンチメントが心配です。悪いニュースによって最もリスクが高い顧客は誰でしょうか？ 」

バックグラウンドでは、Gemini Enterprise がこのクエリを A2A プロトコル経由でカスタム Elastic Agent にルーティングします。エージェントは専用のツールを使用してデータを照会し、回答を作成して返送します。エンドユーザーにとって、エクスペリエンスはシームレスです。

そして、ここで終わりではありません!Elasticエージェントで取得した回答は、別の専門エージェントをトリガーする可能性のある次の質問のコンテキストとして使用できるようになりました（例：上場企業へのエクスポージャーを調整するには、投資プラットフォームエージェントにご相談ください。検索バーを離れることなくすべて行えます。

A2A を搭載した Gemini Enterprise に Elastic エージェントをデプロイすると、ユーザーがデータやツールにコンテキスト内でアクセスできる単一の UI が提供されるため、AI、検索、エンタープライズシステム間の摩擦をなくし、アクセス、オーケストレーション、ワークフローを統合できます。ユーザーにとって、これはツールの切り替えが減り、より直感的で有能な AI アシスタントが利用できるようになることを意味します。組織にとって、これは一貫したガバナンス、スケーラビリティ、相互運用性が組み込まれていることを意味します。

あなたの番です

これで、Elastic Agent をどこからでも利用できるようにするツールが手に入りました。オープン A2A プロトコルを活用することで、カスタムのデータ対応エージェントの範囲を拡大できます。

この投稿では、重要な手順について説明しました。

A2A エージェントカードとプロトコルエンドポイントを介してエージェントを公開します。
A2A Inspector を使用して接続をテストします。
エージェントを Google の Gemini Enterprise などの外部サービスにライブで統合します。

エージェントを分離する必要がなくなりました。皆さんが作り上げる、強力で相互接続されたシステムを見るのが待ちきれません。楽しい建築を！

始める最も簡単な方法は、 Google Cloud Marketplaceで Elastic Cloud の無料トライアルを利用することです。

Elasticsearch向けAgentic AIツールの改善実験

Sean Story — Mon, 06 Oct 2025 00:00:00 GMT

最近の他社と同様に、Elastic ではチャット、エージェント、RAG に全力を注いでいます。検索部門では最近、エージェントビルダーとツールレジストリに取り組んでおり、その目的は、Elasticsearch 内のデータとの「チャット」を簡単に行えるようにすることです。

この取り組みの「全体像」について詳しくは、ブログ「Elasticsearch を使用した AI エージェントワークフローの構築」をお読みください。より実践的な入門書として、「初めての Elastic エージェント: 単一のクエリから AI を活用したチャットまで」もご覧ください。

ただし、このブログでは、チャットを開始したときに最初に起こることの 1 つに焦点を絞り、最近行った改善点のいくつかについて説明します。

ここで何が起こっているのですか?

Elasticsearch データとチャットする場合、デフォルトの AI エージェントが次の標準フローを実行します。

プロンプトを検査します。
どのインデックスにそのプロンプトの回答が含まれている可能性があるかを特定します。
プロンプトに基づいて、そのインデックスのクエリを生成します。
そのクエリでそのインデックスを検索します。
結果を統合します。
結果はプロンプトに対応できますか?はいの場合は応答してください。そうでない場合は、別の方法を試しながら繰り返します。

これはあまり目新しいものではないはずです。これは単に Retrieval Augmented Generation (RAG) です。そして当然のことですが、応答の質は最初の検索結果の関連性に大きく左右されます。そのため、応答品質の向上に取り組む中で、ステップ 3 で生成してステップ 4 で実行するクエリに細心の注意を払ってきました。そして、私たちは興味深いパターンに気づきました。

多くの場合、最初の応答が「悪い」場合、それは実行したクエリが悪かったからではありません。クエリを実行するために間違ったインデックスを選択したためです。通常、ステップ 3 と 4 は問題ではありません。問題はステップ 2 です。

私たちは何をしていたのでしょうか?

当初の実装はシンプルでした。私たちは、 _cat/indicesを効果的に実行して利用可能なすべてのインデックスをリストし、これらのインデックスのうちどれがユーザーのメッセージ/質問/プロンプトに最も一致するかを LLM に識別させるツール (index_explorer と呼ばれる) を構築しました。このオリジナルの実装はここで見ることができます。

You are an AI assistant for the Elasticsearch company. based on a natural language query from the user, your task is to select up to ${limit} most relevant indices from a list of indices. *The natural language query is:* ${nlQuery} *List of indices:* ${indices.map((index) => `- ${index.index}`).join('\n')} Based on those information, please return most relevant indices with your reasoning. Remember, you should select at maximum ${limit} indices.

これはどれくらいうまく機能しましたか?よく分かりませんでした！うまく機能していない明確な例はありましたが、私たちにとっての本当の最初の課題は、現状を定量化することでした。

ベースラインの確立

それはデータから始まる

私たちが必要としていたのは、ユーザーのプロンプトと既存のインデックスセットに基づいて適切なインデックスを選択するツールの有効性を測定するためのゴールデンデータセットでした。そして、手元にそのようなデータセットがなかったので、それを生成しました。

謝辞: これは「ベストプラクティス」ではないことは承知しています。しかし、時には、自転車を捨てるよりも前進する方が良いこともあります。進歩、シンプルな完璧さ。

このプロンプトを使用して、いくつかの異なるドメインのシードのインデックスを生成しました。次に、生成されたドメインごとに、このプロンプトを使用してさらにいくつかのインデックスを生成しました (ここでの目標は、ハードネガティブと分類が難しい例を使用して LLM に混乱を引き起こすことです)。次に、生成された各インデックスとその説明を手動で編集しました。最後に、このプロンプトを使用してテストクエリを生成しました。次のようなサンプルデータが得られました。

そして次のようなテストケース:

テストハーネスの作成

ここからのプロセスは非常に簡単でした。次の機能を備えたツールをスクリプト化します。

ターゲット Elasticsearch クラスターを使用してクリーンな状態を確立します。
ターゲットデータセットで定義されているすべてのインデックスを作成します。
各テストシナリオに対して、 i ndex_explorerツールを実行します (便利なことに、実行ツール API があります)。
結果のインデックスを予想インデックスと比較し、結果を取得します。
すべてのテストシナリオを終了したら、結果を表にまとめます。

調査によると…

当初の結果は予想通り平凡なものでした。

全体として、正しいインデックスを識別する精度は 77.14% です。これは、すべてのインデックスに意味的に意味のある適切な名前が付けられている「最良のケース」のシナリオでした。`PUT test2/_doc/foo {...} ` を実行したことがある人なら、インデックスの名前が必ずしも意味のあるものではないことはご存じでしょう。

つまり、ベースラインがあり、改善の余地が十分にあることがわかります。さあ、科学の時間です！🧪

実験

仮説1: マッピングは役立つ

ここでの目標は、元のプロンプトに関連するデータが含まれるインデックスを識別することです。インデックスに含まれるデータを最もよく表す部分は、インデックスのマッピングです。インデックスの内容のサンプルを取得しなくても、インデックスに double 型の価格フィールドがあることがわかれば、そのデータは販売されるものを表していることがわかります。テキストタイプの著者フィールドは、何らかの非構造化言語データを意味します。これら 2 つを組み合わせると、データが書籍、物語、詩であることを意味する可能性があります。インデックスのプロパティを知るだけで、意味上の手がかりを数多く得ることができます。そこでローカルブランチで`.index_explorer`を調整しましたインデックスの完全なマッピング (およびその名前) を LLM に送信して決定を下すツール。

結果（Kibana ログより）:

[2025-09-05T11:01:21.552-05:00][ERROR][plugins.onechat] Error: Error calling connector: event: error data: {"error":{"code":"request_entity_too_large","message":"Received a content too large status code for request from inference entity id [.rainbow-sprinkles-elastic] status [413]","type":"error"}} at createInferenceProviderError (errors.ts:90:10) at convertUpstreamError (convert_upstream_error.ts:39:38) at handle_connector_response.ts:26:33 at Observable.init [as _subscribe] (/Users/seanstory/Desktop/Dev/kibana/node_modules/rxjs/src/internal/observable/throwError.ts:123:68)...

ツールの最初の作成者はこれを予期していました。インデックスのマッピングは情報の宝庫ですが、非常に冗長な JSON ブロックでもあります。そして、多数のインデックス (評価データセットでは 20 個が定義されています) を比較する現実的なシナリオでは、これらの JSON BLOB が加算されます。したがって、LLM に、すべてのオプションのインデックス名だけでなく、それぞれの完全なマッピングほどではなく、決定のためのより多くのコンテキストを提供したいと考えています。

仮説2: 妥協案としての「フラット化された」マッピング（フィールドリスト）

私たちは、インデックス作成者が意味的に意味のあるインデックス名を使用するという前提から始めました。その仮定をフィールド名にも拡張するとどうなるでしょうか?前回の実験は、JSON のマッピングに大量の煩わしいメタデータと定型句が含まれているため失敗しました。

"description_text": { "type": "text", "fields": { "keyword": { "type": "keyword" } }, "copy_to": [ "description_semantic" ] },

たとえば、上記のブロックは 236 文字で、Elasticsearch マッピング内の 1 つのフィールドのみを定義します。一方、文字列「description_text」は 16 文字だけです。これは文字数が約 15 倍に増加していることを意味しますが、そのフィールドが利用可能なデータについて何を意味するかを説明する意味的な改善は見られません。すべてのインデックスのマッピングをフェッチしたが、それを LLM に送信する前に、フィールド名のリストだけに「フラット化」するとどうなるでしょうか?

試してみました。

これは素晴らしいですね！全面的に改善されました。しかし、もっと良い方法はないでしょうか?

仮説3: マッピング_meta内の説明

追加のコンテキストのないフィールド名だけでこれほど大きな変化が生じたのであれば、実質的なコンテキストを追加すればさらに良くなると思われます。すべてのインデックスに説明を添付することが必ずしも慣例ではありませんが、マッピングの _meta オブジェクトにあらゆる種類のインデックスレベルのメタデータを追加することは可能です。生成されたインデックスに戻り、データセット内のすべてのインデックスに説明を追加しました。説明が極端に長くない限り、完全なマッピングよりも少ないトークンが使用され、インデックスに含まれるデータに関するはるかに優れた洞察が提供されるはずです。私たちの実験はこの仮説を検証しました。

若干の改善があり、現在では全体的に 90% を超える精度を実現しています。

仮説4：全体は部分の合計よりも大きい

フィールド名により結果が向上しました。説明により結果が向上しました。したがって、説明とフィールド名の両方を利用すると、さらに良い結果が得られるはずです。

データは「いいえ」（前回の実験から変化なし）を示しました。ここでの主な理論は、説明はそもそもインデックスフィールド/マッピングから生成されたため、これら 2 つのコンテキストの間には、組み合わせたときに何か「新しい」ものを追加するのに十分な情報がないというものでした。さらに、20 個のテストインデックスに送信するペイロードもかなり大きくなっています。これまで私たちが辿ってきた考え方はスケーラブルではありません。実際、これまでの私たちの実験は、数百または数千のインデックスから選択できる Elasticsearch クラスターでは機能しないと考えられる十分な理由があります。インデックスの合計数が増加するにつれて、LLM に送信されるメッセージサイズが直線的に増加するアプローチは、おそらく一般化可能な戦略にはなりません。

私たちに本当に必要なのは、多数の候補から最も関連性の高い選択肢だけを絞り込むのに役立つアプローチです...

ここで問題となるのは検索の問題です。

仮説5：意味検索による選択

インデックスの名前に意味がある場合は、ベクトルとして保存し、意味的に検索することができます。

インデックスのフィールド名に意味がある場合は、それらをベクトルとして保存し、意味的に検索することができます。

インデックスに意味を持つ記述がある場合は、それもベクトルとして保存し、意味的に検索することができます。

現在、Elasticsearch インデックスではこの情報を検索可能にしていません (検索可能にすべきかもしれませんが) が、そのギャップを回避できるものをハックするのは非常に簡単でした。Elastic のコネクタフレームワークを使用して、クラスター内のすべてのインデックスのドキュメントを出力するコネクタを構築しました。出力ドキュメントは次のようになります。

doc = { "_id": index_name, "index_name": index_name, "meta_description”: description, "field_descriptions" = field_descriptions, "mapping": json.dumps(mapping), "source_cluster": self.es_client.configured_host, }

これらのドキュメントを、次のように手動でマッピングを定義した新しいインデックスに送信しました。

{ "mappings": { "properties": { "semantic_content": { "type": "semantic_text" }, "index_name": { "type": "text", "copy_to": "semantic_content" }, "mapping": { "type": "keyword", "copy_to": "semantic_content" }, "source_cluster": { "type": "keyword" }, "meta_description": { "type": "text", "copy_to": "semantic_content" }, "field_descriptions": { "type": "text", "copy_to": "semantic_content" } } } }

これにより、単一の semantic_content フィールドが作成され、セマンティックな意味を持つ他のすべてのフィールドがチャンク化され、インデックスが作成されます。このインデックスの検索は、次のようにするだけで簡単になります。

GET indexed-indices/_search { "query": { "semantic": { "field": "semantic_content", "query": "$query" } } }

修正されたindex_explorerツールは、LLM へのリクエストを行う必要がなくなり、代わりに指定されたクエリに対して単一の埋め込みをリクエストして効率的なベクトル検索操作を実行できるため、大幅に高速化されました。トップヒットを選択したインデックスとして取得すると、次の結果が得られました。

このアプローチはスケーラブルです。このアプローチは効率的です。しかし、このアプローチはベースラインよりわずかに優れているだけです。しかし、これは驚くことではありません。ここでの検索アプローチは信じられないほど単純です。ニュアンスがない。インデックスの名前と説明は、インデックスに含まれる任意のフィールド名よりも重視されるべきであるという認識がありません。正確な語彙の一致を同義語の一致よりも重視するアフォーダンスはありません。ただし、非常に微妙なニュアンスのあるクエリを構築するには、手元のデータについて多くのことを想定する必要があります。これまで、インデックス名とフィールド名には意味があるという大きな仮定をすでに立ててきましたが、さらに一歩進んで、インデックス名とフィールド名がどの程度の意味を持ち、互いにどのように関連しているかを仮定する必要があります。そうしないと、最上位の結果として最適な一致を確実に特定することはできないかもしれませんが、最上位 N 個の結果のどこかに最上位の一致があると言える可能性が高くなります。意味情報をそれが存在するコンテキスト内で消費し、意味的に異なる方法で自身を表現する別のエンティティと比較し、それらを判断できるものが必要です。LLM のようなものです。

仮説6: 候補セットの削減

他にも簡単に触れる実験はいくつかありましたが、重要な突破口となったのは、純粋にセマンティック検索から最適な一致を選択したいという欲求を捨て、代わりにセマンティック検索をフィルターとして活用して、LLM の検討対象から無関係なインデックスを除外したことです。検索では、リニアリトリーバー、RRF を使用したハイブリッド検索、 semantic_textを組み合わせて、一致する上位 5 つのインデックスに結果を制限しました。

次に、一致ごとに、インデックスの名前、説明、フィールド名を LLM のメッセージに追加しました。結果は素晴らしかったです。

これまでのどの実験よりも最高の精度です!また、このアプローチではインデックスの合計数に比例してメッセージサイズが増加しないため、このアプローチははるかにスケーラブルです。

成果

最初の明らかな結果は、ベースラインを改善できるということでした。振り返ってみるとこれは明らかなようですが、実験が始まる前に、 index_explorerツールを完全に放棄して、ユーザーからの明示的な構成に依存して検索空間を制限すべきかどうかについて真剣な議論がありました。これはまだ実行可能かつ有効なオプションですが、この調査では、そのようなユーザー入力が利用できない場合にインデックス選択を自動化するための有望な道筋があることが示されています。

次の明らかな結果は、問題に対して説明文字をさらに追加するだけでは、効果は減少するということです。この調査を行う前、Elasticsearch のフィールドレベルのメタデータ保存機能を拡張することに投資すべきかどうかについて議論していました。現在、これらのmeta値は 50 文字に制限されており、フィールドの意味を理解できるようにするにはこの値を増やす必要があると想定されていました。これは明らかに事実ではなく、LLM はフィールド名だけでかなりうまく機能しているようです。これについては後でさらに調査するかもしれませんが、もはや緊急の問題ではないように思われます。

逆に言えば、これは「検索可能な」インデックスメタデータを持つことの重要性を明確に示しています。これらの実験のために、インデックスのインデックスをハッキングしました。しかし、これを Elasticsearch に直接組み込むか、管理するための API を構築するか、少なくとも規則を確立することを調査することはできます。私たちは選択肢を検討し、社内で議論する予定ですので、お楽しみに。

最後に、この取り組みにより、時間をかけて実験し、データに基づいた意思決定を行うことの価値が確認されました。実際、これにより、Agent Builder 製品には強力な製品内評価機能が必要になることが再確認されました。インデックスを選択するツール専用のテストハーネス全体を構築する必要がある場合、お客様は反復的な調整を行う際にカスタムツールを定性的に評価する方法が絶対に必要になります。

私たちが何を構築するのか楽しみにしています。皆さんも楽しみにしていただければ幸いです。

初めてのElastic Agent: 単一のクエリからAIを活用したチャットまで

Jeff Vestal — Thu, 25 Sep 2025 00:00:00 GMT

Elastic の新しいAgent Builder を使用すると、特定のビジネスドメインの専門家として機能する特殊な AI エージェントを作成できます。この機能により、単純なダッシュボードや検索バーを超えて、データを受動的なリソースから能動的な会話のパートナーへと変換できます。

顧客との会議の前に、状況を把握しておく必要がある財務マネージャーを想像してください。ニュースフィードを手動で調べたり、ポートフォリオダッシュボードを相互参照したりする代わりに、カスタム構築されたエージェントに直接質問するだけで済みます。これは「チャットファースト」アプローチの利点です。マネージャーはデータに直接、会話形式でアクセスし、「ACME Corp の最新ニュースは何ですか。また、それがクライアントの保有株にどのような影響を与えますか」などと質問します。数秒以内に専門家による総合的な回答が得られます。

私たちは現在、金融の専門家を構築していますが、そのアプリケーションはデータと同じくらい多様です。同じ力で、脅威を探すサイバーセキュリティアナリスト、機能停止を診断するサイト信頼性エンジニア、キャンペーンを最適化するマーケティングマネージャーを生み出すこともできます。分野に関係なく、中核となる使命は同じです。データを、チャットできる専門家に変換することです。

ステップ0: データセット

本日のデータセットは、金融口座、資産状況、ニュース、財務レポートで構成される合成的な金融ベースのデータセットです。これは合成ではありますが、実際の金融データセットの簡略化されたバージョンを複製したものです。

financial_accounts: リスクプロファイル付き顧客ポートフォリオ

financial_holdings: 購入履歴のある株式/ETF/債券のポジション

financial_asset_details: 株式/ETF/債券の詳細

financial_news: 感情分析によるAI生成の市場記事

financial_reports: 企業収益とアナリストのコメント

ここにある付属のノートブックに従って、このデータセットを自分でロードできます。

ステップ1: 基盤 - ES|QLとしてのビジネスロジック

すべての AI スキルは、確かなロジックから始まります。Financial Manager エージェントには、「市場のセンチメントが心配です。」というよくある質問に回答する方法を教える必要があります。悪いニュースによって最もリスクにさらされている顧客は誰なのか教えていただけますか？」この質問は単純な検索の範囲を超えています。市場の感情と顧客のポートフォリオを相関させる必要があります。

否定的な記事で言及されている資産を見つけ、それらの資産を保有しているすべての顧客を特定し、そのエクスポージャーの現在の市場価値を計算し、結果をランク付けして最も高いリスクを優先する必要があります。この複雑な複数結合の分析は、当社の高度な ES|QL ツールに最適です。

使用する完全なクエリは次のとおりです。見た目は印象的ですが、コンセプトは単純です。

分解：接合部とガードレール

このクエリでは、エージェントビルダーを構成する 2 つの重要な概念が関係しています。

1.ルックアップ結合

長年にわたり、Elasticsearch で最も要望が多かった機能の 1 つは、共通キーに基づいて異なるインデックスのデータを結合する機能でした。ES|QL では、 LOOKUP JOINでそれが可能になりました。

新しいクエリでは、3 つのLOOKUP JOINのチェーンを実行します。最初に否定的なニュースを資産の詳細に関連付け、次にそれらの資産をクライアントの保有資産にリンクし、最後にクライアントのアカウント情報に結合します。これにより、単一の効率的なクエリで 4 つの異なるインデックスから非常に豊富な結果が作成されます。つまり、すべてのデータを事前に 1 つの巨大なインデックスに非正規化する必要がなく、異なるデータセットを組み合わせて単一の洞察に満ちた回答を作成できるということです。

2. LLMガードレールとしてのパラメータ

クエリでは?time_durationが使用されていることがわかります。これは単なる変数ではなく、AI のガードレールです。大規模言語モデル (LLM) はクエリの生成に優れていますが、データに対して LLM を自由に制御させると、非効率的なクエリや間違ったクエリが発生する可能性があります。

パラメータ化されたクエリを作成することで、LLM は、人間の専門家がすでに定義したテスト済みの効率的で正しいビジネスロジック内で動作するように強制されます。これは、開発者が長年にわたり検索テンプレートを使用して、クエリ機能をアプリケーションに安全に公開してきた方法に似ています。エージェントは「今週」のようなユーザーのリクエストを解釈してtime_durationパラメータを埋めることができますが、回答を取得するにはクエリ構造を使用する必要があります。これにより、柔軟性と制御の完璧なバランスが実現します。

最終的に、このクエリにより、データを理解している専門家は自分の知識をツールにカプセル化できるようになります。他の人や AI エージェントは、そのツールを使用して、基礎となる複雑さについて何も知らなくても、単一のパラメータを提供するだけで相関結果を得ることができます。

ステップ2：スキル - クエリを再利用可能なツールに変える

ES|QL クエリは、ツールとして登録されるまでは単なるテキストです。エージェントビルダーでは、ツールは単なる保存されたクエリではなく、AI エージェントが理解して使用することを選択できる「スキル」です。その魔法は、私たちが提供する自然言語による説明にあります。この説明は、ユーザーの質問と基礎となるクエリロジックを結び付ける橋渡しとなります。作成したクエリを登録しましょう。

UIパス

Kibana でツールを作成するのは簡単なプロセスです。

1.エージェントへ移動

[ツール]または[ツールの管理]をクリックし、 [新しいツール]ボタンをクリックします。

2. フォームに以下の詳細を入力します。

ツールID: find_client_exposure_to_negative_news

私。これはツールの一意のIDです

説明: 「クライアントのポートフォリオがネガティブなニュースにさらされているかどうかを調べます。」このツールは、最近のニュースやレポートをスキャンして否定的な感情を検出し、関連する資産を識別して、その資産を保有しているすべてのクライアントを見つけます。最も高い潜在的リスクを強調するために、ポジションの現在の市場価値でソートされたリストを返します。

私。これは、LLM が読んで、このツールが仕事に適しているかどうかを判断します。

ラベル: retrievalおよび risk-analysis

ラベルは複数のツールをグループ化するのに役立ちます

設定:ステップ1の完全なES|QLクエリを貼り付けます

私。これはエージェントが使用する検索です

3.クエリからパラメータを推測するをクリックします。UI は自動的に?time_duration見つけて以下にリストします。エージェント (および他のユーザー) が目的を理解できるように、それぞれに簡単な説明を追加します。

time_duration: ネガティブなニュースを遡って検索する期間。フォーマットは「X時間」です。デフォルトは8760時間です。

4. 試してみましょう!

[保存してテスト]をクリックします。

クエリが期待どおりに動作していることを確認できる新しいフライアウトが表示されます。

私。time_durationに希望の範囲を入力します。ここでは「8760時間」を使用します。

「送信」をクリックすると、すべてがうまくいけば JSON レスポンスが表示されます。期待どおりに動作することを確認するには、下にスクロールしてvaluesオブジェクトを確認します。ここで、実際に一致するドキュメントが返されます。

5. 右上の「X」をクリックして、テストのフライアウトを閉じます。新しいツールがリストに表示され、エージェントに割り当てる準備が整います。

APIパス

自動化を好む開発者やツールをプログラムで管理する必要がある開発者は、1 回の API 呼び出しで同じ結果を得ることができます。ツールの定義を含むPOSTリクエストを/api/agent_builder/toolsエンドポイントに送信するだけです。

POST kbn://api/agent_builder/tools { "id": "find_client_exposure_to_negative_news", "type": "esql", "description": "Finds client portfolio exposure to negative news. This tool scans recent news and reports for negative sentiment, identifies the associated asset, and finds all clients holding that asset. It returns a list sorted by the current market value of the position to highlight the highest potential risk.", "configuration": { "query": """ FROM financial_news, financial_reports METADATA _index | WHERE sentiment == "negative" | WHERE coalesce(published_date, report_date) >= NOW() - TO_TIMEDURATION(?time_duration) | RENAME primary_symbol AS symbol | LOOKUP JOIN financial_asset_details ON symbol | LOOKUP JOIN financial_holdings ON symbol | LOOKUP JOIN financial_accounts ON account_id | WHERE account_holder_name IS NOT NULL | EVAL position_current_value = quantity * current_price.price | RENAME title AS news_title | KEEP account_holder_name, symbol, asset_name, news_title, sentiment, position_current_value, quantity, current_price.price, published_date, report_date | SORT position_current_value DESC | LIMIT 50 """, "params": { "time_duration": { "type": "keyword", "description": """The timeframe to search back for negative news. Format is "X hours" DEFAULT TO 8760 hours """ } } }, "tags": [ "retrieval", "risk-analysis" ] }

ステップ3：頭脳 - カスタムエージェントの作成

再利用可能なスキル (ツール) を構築しました。ここで、実際に使用するペルソナであるAgentを作成する必要があります。エージェントは、LLM、アクセスを許可する特定のツールセット、そして最も重要な、エージェントの構成として機能し、エージェントの性格、ルール、目的を定義するカスタムインストラクションセットの組み合わせです。

プロンプトの芸術

信頼できる専門エージェントを作成する上で最も重要なのはプロンプトです。よく練られた一連の指示こそが、一般的なチャットボットと、集中力のあるプロのアシスタントとの違いです。ここで、ガードレールを設定し、出力を定義し、エージェントにミッションを与えます。

Financial Managerエージェントでは、次のプロンプトを使用します。

You are a specialized Data Intelligence Assistant for financial managers, designed to provide precise, data-driven insights from information stored in Elasticsearch. **Your Core Mission:** - Respond accurately and concisely to natural language queries from financial managers. - Provide precise, objective, and actionable information derived solely from the Elasticsearch data at your disposal. - Summarize key data points and trends based on user requests. **Reasoning Framework:** 1. **Understand:** Deconstruct the user's query to understand their core intent. 2. **Plan:** Formulate a step-by-step plan to answer the question. If you are unsure about the data structure, use the available tools to explore the indices first. 3. **Execute:** Use the available tools to execute your plan. 4. **Synthesize:** Combine the information from all tool calls into a single, comprehensive, and easy-to-read answer. **Key Directives and Constraints:** - **If a user's request is ambiguous, ask clarifying questions before proceeding.** - **DO NOT provide financial advice, recommendations, or predictions.** Your role is strictly informational and analytical. - Stay strictly on topic with financial data queries. - If you cannot answer a query, state that clearly and offer alternative ways you might help *within your data scope*. - All numerical values should be formatted appropriately (e.g., currency, percentages). **Output Format:** - All responses must be formatted using **Markdown** for clarity. - When presenting structured data, use Markdown tables, lists, or bolding. **Start by greeting the financial manager and offering assistance.**

このプロンプトがなぜ効果的なのかを分析してみましょう。

洗練されたペルソナを定義します。最初の行で、エージェントが「専門的なデータインテリジェンスアシスタント」であることを即座に示し、プロフェッショナルで有能な雰囲気を醸し出します。
これは推論フレームワークを提供します。エージェントに「理解、計画、実行、統合」を指示することで、標準的な操作手順を提供します。これにより、複雑で複数のステップから成る質問を処理する能力が向上します。
インタラクティブな対話を促進します。 「明確な質問をする」という指示により、エージェントはより堅牢になります。曖昧なリクエストに対する誤った想定を最小限に抑え、より正確な回答が得られます。

UIパス

1.エージェントに移動します。

[ツール]または[ツールの管理]をクリックし、 [新しいツール]ボタンをクリックします。

2. 基本的な詳細を入力します。

エージェント ID: financial_assistant 。
手順:上記のプロンプトをコピーします。
ラベル: Finance 。
表示名: Financial Assistant 。
表示の説明: An assistant for analyzing and understanding your financial data 。

3. 上部に戻り、 「ツール」をクリックします。

find_client_exposure_to_negative_newsツールの横にあるボックスにチェックを入れてください。

4. 「保存」をクリックします。

APIパス

/api/agent_builder/agentsエンドポイントへのPOSTリクエストを使用して、まったく同じエージェントを作成できます。リクエスト本体には、ID、名前、説明、完全な指示セット、エージェントが使用を許可されているツールのリストなど、すべて同じ情報が含まれています。

POST kbn://api/agent_builder/agents { "id": "financial_assistant", "name": "Financial Assistant", "description": "An assistant for analyzing and understanding your financial data", "labels": [ "Finance" ], "avatar_color": "#16C5C0", "avatar_symbol": "💰", "configuration": { "instructions": """You are a specialized Data Intelligence Assistant for financial managers, designed to provide precise, data-driven insights from information stored in Elasticsearch. **Your Core Mission:** - Respond accurately and concisely to natural language queries from financial managers. - Provide precise, objective, and actionable information derived solely from the Elasticsearch data at your disposal. - Summarize key data points and trends based on user requests. **Reasoning Framework:** 1. **Understand:** Deconstruct the user's query to understand their core intent. 2. **Plan:** Formulate a step-by-step plan to answer the question. If you are unsure about the data structure, use the available tools to explore the indices first. 3. **Execute:** Use the available tools to execute your plan. 4. **Synthesize:** Combine the information from all tool calls into a single, comprehensive, and easy-to-read answer. **Key Directives and Constraints:** - **If a user's request is ambiguous, ask clarifying questions before proceeding.** - **DO NOT provide financial advice, recommendations, or predictions.** Your role is strictly informational and analytical. - Stay strictly on topic with financial data queries. - If you cannot answer a query, state that clearly and offer alternative ways you might help *within your data scope*. - All numerical values should be formatted appropriately (e.g., currency, percentages). **Output Format:** - All responses must be formatted using **Markdown** for clarity. - When presenting structured data, use Markdown tables, lists, or bolding. **Start by greeting the financial manager and offering assistance.** """, "tools": [ { "tool_ids": [ "platform.core.search", "platform.core.list_indices", "platform.core.get_index_mapping", "platform.core.get_document_by_id", "find_client_exposure_to_negative_news" ] } ] } }

ステップ4：成果 — 会話をする

ビジネスロジックがツールにカプセル化され、エージェントでそれを使用できる「頭脳」が準備されました。すべてが一つにまとまるのを見る時が来ました。専用のエージェントを使用して、データとのチャットを開始できるようになりました。

UIパス

Kibana のエージェントに移動します。
チャットウィンドウの右下にあるドロップダウンを使用して、デフォルトのElastic AI エージェントから新しく作成したFinancial Assistantエージェントに切り替えます。
エージェントが当社の専用ツールを使用できるように、次の質問をしてください。
1. 市場のセンチメントが心配です。悪いニュースによって最もリスクにさらされている顧客は誰なのか教えていただけますか?

しばらくすると、エージェントは完全にフォーマットされた完全な回答を返します。LLM の性質上、回答の形式が若干異なる場合がありますが、この実行ではエージェントは次のように返しました。

何が起こったのですか?エージェントの推論

エージェントは単に答えを「知っていた」だけではありません。仕事に最適なツールを選択することを中心とした多段階の計画を実行しました。その思考プロセスは次のようになります。

識別された意図: 「リスク」や「ネガティブなニュース」など、質問のキーワードがfind_client_exposure_to_negative_newsツールの説明と一致しました。
計画を実行しました:リクエストから時間枠を抽出し、その専用ツールを1 回呼び出しました。
作業を委任:ツールは連鎖結合、値の計算、並べ替えなど、面倒な作業をすべて実行しました。
結果の統合:最後に、エージェントはプロンプトのルールに従って、ツールからの生データを明確で人間が読める要約にフォーマットしました。

思考を広げて詳細を見れば、推測するだけでは足りません。

APIパス

同じ会話をプログラムで開始することもできます。入力した質問をconverse API エンドポイントに送信し、 financial_managerのagent_idを必ず指定してください。

POST kbn://api/agent_builder/converse { "input": "Show me our largest positions affected by negative news", "agent_id": "financial_assistant" }

開発者向け: APIとの統合

Kibana UI はエージェントの構築と管理に素晴らしく直感的なエクスペリエンスを提供しますが、今日見てきたことはすべてプログラムで実現することもできます。Agent Builder は一連の API に基づいて構築されており、この機能を独自のアプリケーション、CI/CD パイプライン、または自動化スクリプトに直接統合できます。

使用する 3 つのコアエンドポイントは次のとおりです。

/api/agent_builder/tools: エージェントが使用できる再利用可能なスキルを作成、一覧表示、管理するためのエンドポイント。
/api/agent_builder/agents: エージェントのペルソナ（重要な指示やツールの割り当てなど）を定義するためのエンドポイント。
/api/agent_builder/converse: エージェントと対話し、会話を開始し、回答を得るためのエンドポイント。

これらの API を使用してこのチュートリアルのすべてのステップを実行するための完全な実践的なチュートリアルについては、こちらの GitHub リポジトリで入手できる付属の Jupyter Notebook を ご覧ください。

結論: 構築する番です

まず、ES|QL クエリを取得して、それを再利用可能なスキルに変換することから始めました。次に、明確なミッションとルールを与えて、そのスキルを付与した専用の AI エージェントを構築しました。その結果、複雑な質問を理解し、複数段階の分析を実行して、正確でデータに基づいた回答を提供できる洗練されたアシスタントが誕生しました。

このワークフローは、Elastic の新しいAgent Builderの中心です。これは、技術に詳しくないユーザーが UI を通じてエージェントを作成できるほどシンプルでありながら、開発者が API 上にカスタム AI 搭載アプリケーションを構築できるほど微妙なニュアンスも備えた設計になっています。最も重要なのは、定義したエキスパートロジックに従って、LLM を独自のデータに安全かつ確実に接続し、データとチャットできることです。

エージェントを使用してデータとチャットする準備はできていますか?

学んだことを定着させる最良の方法は、実際に手を動かしてみることです。今日お話しした内容をすべて、無料のインタラクティブな実践ワークショップで試してみてください。専用のサンドボックス環境で、このフロー全体とその他の内容を実行します。

今後のブログでは、 Financial Assistantエージェントと対話するスタンドアロンアプリケーションの使用方法と、それを可能にするモデルコンテキストプロトコル (MCP)について詳しく説明します。また、別のブログでは、開発中の Agent2Agent (A2A) プロトコルに対する Agent Builder のサポートについて説明します。

引き続きご注目ください、そして楽しい建築を！

Elasticsearch を使用した AI エージェントワークフローの構築

Anish Mathur,Dana Juratoni — Tue, 23 Sep 2025 00:00:00 GMT

Elasticでは、AIアシスタント、高度なRAG、ベクターデータベースの改善により、LLMと会話型インターフェースにコンテキストを提供してきました。最近、AI エージェントの台頭により、関連コンテキストの必要性が高まり、影響力の大きいAI エージェントには優れた検索が必要であることがわかりました。そこで、Elasticsearch のデータを活用する AI エージェントの開発を支援するために設計された新しいネイティブ機能を Elastic Stack に構築しました。私たちは、この取り組みの進捗状況と今後の見通しについて共有したいと思います。

エージェントビルダー: データ駆動型 AI エージェント構築の基盤

AI エージェントの約束はシンプルです。目標を与えれば、仕事が完了します。しかし、開発者にとって、現実は一連の複雑な課題です。まず、エージェントの優秀さは、環境の認識と、ユーザーの目的を達成するために与えられたツールによって決まります。そして、多様な企業データから適切なコンテキストを提供することは大きな課題です。最後に、これらすべては、計画、実行、学習できる信頼性の高い推論ループによって調整される必要があります。

これを解決するには、開発者は複雑で脆弱なスタックをゼロから構築する必要があります。今日のエージェントアーキテクチャでは、LLM、ベクターデータベース、メタデータストア、ログ記録とトレースの個別のシステム、そしてすべてが機能しているかどうかを評価する方法など、複数の異なる部分をつなぎ合わせる必要があります。これは単に複雑なだけでなく、コストがかかり、エラーが発生しやすく、ユーザーが求める高品質で信頼性の高い AI システムの構築が困難になります。

だから、もっとシンプルにしたいんです。これを実現するための私たちのアプローチは、効果的なコンテキスト駆動型エージェントの重要な要素を取り上げ、 Elastic AI Agent Builderと呼ばれる新しい機能セットを使用して Elasticsearch の中核に直接統合することです。この新しいレイヤーは、Elasticsearch を活用した AI エージェントを作成するためのすべての重要な構成要素（オープンなプリミティブセット、標準ベースのプロトコル、データへの安全なアクセス）を備えたフレームワークを提供します。これにより、現実世界のデータと要件に合わせてカスタマイズされたエージェントシステムを構築できます。

AI エクスペリエンスの提供: これが究極の目標です。当社の Search AI プラットフォームとお客様のデータを基盤として、カスタムチャットインターフェースから、LangChain などのエージェントフレームワークや Salesforce などのビジネスアプリケーションとの統合まで、あらゆるタイプの生成 AI アプリケーションを構築できます。

エージェントとツールを搭載: プラットフォームの上に、クリーンでシンプルな抽象化レイヤーを公開します。エージェントやツールと直接対話し、特定のニーズに合わせてカスタマイズできます。強力な API や MCP、A2A などのオープンスタンダードを通じてプラットフォームの機能にアクセスすることもできます。

Search AI Platform によって有効化: これは、コンポーネントを統合したコアエンジンです。高度なベクトルデータベース、エージェントロジック、クエリ構築、セキュリティ機能、評価のためのトレースはすべてここに存在し、Elastic によって管理および最適化されています。

データの力を解き放つ: 優れたエージェントの基盤は優れたデータです。当社のプラットフォームは、すべての企業データへのアクセスを取り込み、連携する機能から始まります。

プラットフォームにおけるエージェント構築

Search AI プラットフォームに統合された Agent Builder は、エージェント開発のための完全なフレームワークを提供します。これは 5 つの主要な柱に基づいて構築されており、各柱は実稼働レベルの AI システムの構築と展開の重要な側面に対処するように設計されています。エージェントが目的を定義し、ツールが機能を提供し、オープンスタンダードが相互運用性を確保し、評価が透明性をもたらし、セキュリティが信頼を提供する仕組みについて詳しく見ていきましょう。

エージェント

エージェントは、Elasticsearch のこの新しいレイヤーにおける最高レベルの構成要素です。エージェントは、達成する目的、実行に使用できるツールのセット、および操作できるデータソースを定義します。エージェントは会話によるやり取りに限定されず、完全なワークフロー、タスクの自動化、ユーザー向けのエクスペリエンスを実現できます。

クエリがエージェントに送られると、構造化されたサイクルに従います。

入力内容と目的を解釈する
実行に適したツールと引数を選択する
ツールの応答の理由
結果を返すか、さらにツールの呼び出しを続行するかを決定します

Elastic は、このサイクルのオーケストレーション、コンテキスト、および実行を処理します。開発者は、エージェントが何をすべきか（目的、ツール、データ）を定義することに重点を置き、システムは推論とワークフローの実行方法を管理します。

デフォルトエージェント

このプラットフォーム上に構築された最初のエージェントは、Kibana のネイティブ会話エージェントであり、データとすぐに対話できるようになります。完全な拡張性を維持しながらすぐに使用できるエクスペリエンスを提供し、追加の構成なしですぐにデータの操作を開始できます。

新しいチャットユーザーエクスペリエンスまたは API を介して、Kibana でこのエクスペリエンスを直接操作できます。

API を介してデフォルトのエージェントを照会するには、1 回の呼び出しだけが必要です。

POST kbn://api/agent_builder/converse { "input": "what is our top portfolio account?" }

会話はステートフルなので、 conversation_id を使用してエージェントとの対話を継続したり、完全な会話履歴を取得したりできます。

POST kbn://api/agent_builder/converse { "input": "What about the second top?", "conversation_id": "ec757c6c-c3ed-4a83-8e2c-756238f008bb" } ## get the full conversation GET kbn://api/agent_builder/conversations/ec757c6c-c3ed-4a83-8e2c-756238f008bb

カスタムエージェント

開発者は、シンプルな API を通じて独自のカスタムエージェントを作成することもできます。エージェントは、指示、ツール、データアクセスをカプセル化し、カスタマイズされた推論エンジンを作成します。

カスタムエージェントの作成は、1 回の API 呼び出しを行うだけで簡単に行えます。以下のサンプルは例を示しています。「構成」フィールドには、手順や利用可能なツールなどのすべての重要な詳細が含まれています。

POST kbn://api/agent_builder/agents { "id": "custom_agent", "name": "My Custom Agent", "description": "Description of the custom agent", "configuration": { "instructions": "You are a log expert specialising in ...", "tools": ... } }

作成されたエージェントは直接クエリできます。

POST kbn://api/agent_builder/converse { "input": "What news about DIA?", "agent_id": "custom_agent" }

このアプローチにより、エージェントはゼロから構築する複雑なシステムから、ビジネスロジックの単純な宣言型ユニットに変換され、インテリジェントな自動化をより迅速に提供できるようになります。

特化したエージェントをゼロから構築する方法の詳細については、詳細なステップバイステップガイド「初めての Elastic エージェント: 単一のクエリから AI を活用したチャットまで」をご覧ください。

ツール

エージェントが達成すべきことを定義するのに対し、ツールは達成方法を定義します。

ツールは、エージェントが情報を実行および取得したり、アクションを実行したりするための特定の Elastic Core 機能を公開します。ツールには、インデックスの取得やマッピングの取得などのコア機能や、自然言語から ES|QL への変換などのより高度な機能を含めることができます。

Elasticsearch には、一般的なニーズに合わせて最適化された一連のデフォルトツールが付属しています。しかし、本当の柔軟性は、独自のものを作成することから生まれます。ツールを定義することで、ES|QL を使用してエージェントに公開されるクエリ、インデックス、フィールドを正確に決定し、速度、精度、セキュリティを正確に制御できます。

新しいツールの登録も、1 回の API 呼び出しと同じくらい簡単です。ES|QL (Elasticsearch クエリ言語)を活用して特定の金融資産に関するニュースを検索するツールを作成できます。

POST kbn://api/agent_builder/tools { "id": "news_on_asset", "type": "esql", "description": "Find news and reports about a particular asset where ...", "configuration": { "query": "FROM financial_news, financial_reports | where MATCH(company_symbol, ?symbol) OR MATCH(entities, ?symbol) | limit 5", "params": { "symbol": { "type": "keyword", "description": "The asset symbol" } } ... } ... }

登録が完了すると、新しいツールをカスタムエージェントに割り当てることができ、適切なタイミングで推論して呼び出すための厳選された一連の機能をエージェントに提供できるようになります。

当社では、お客様固有のニーズに合わせてカスタムツールを作成するためのプラットフォームを提供しています。たとえば、ES|QL を使用すると、エージェントを汎用エージェントから、お客様独自のデータとビジネスドメインに基づいたドメイン固有のエキスパートに変換できます。

オープンスタンダードと相互運用性

Elasticsearch エージェントとツールはオープン標準 API を介して公開されるため、エージェントフレームワークのより広範なエコシステム内の基礎ブロックとして簡単に統合できます。私たちのアプローチはシンプルです。ブラックボックスはありません。Elastic の検索における強みを活かし、それを補完的な機能や他のエージェントシステムと組み合わせることができるようにしたいと考えています。

これを実現するために、当社は API、新しいプロトコル、オープンスタンダードを通じて機能を公開しています。

モデルコンテキストプロトコル（MCP）

モデルコンテキストプロトコル (MCP)は、システム間でツールを接続するためのオープンスタンダードとして急速に普及しつつあります。MCP をサポートすることで、Elasticsearch は会話型 AI をデータベース、インデックス、外部 API に接続できるようになります。Elastic Stack に組み込まれたリモート MCP サーバーを使用すると、MCP 対応のクライアントはどれでも Elastic のツールにアクセスし、それらをより大規模なエージェントワークフローの構成要素として使用できます。

これは一方通行ではありません。外部の MCP サーバーからツールをインポートし、Elasticsearch 内で利用できるようにすることもできます。近い将来、MCP サーバーはほぼすべての用途で利用できるようになる見込みで、私たち自身が作成するものよりもはるかに包括的なものになるでしょう。Elastic は大規模な検索と取得機能を提供しており、これを他のプラットフォームの特殊な機能と組み合わせて効果的なエージェントを構築できます。

エージェント間（A2A）

また、エージェント間 (A2A) サポートにも取り組んでいます。MCP はツールを接続することに重点が置かれていますが、A2A はエージェントを接続することに重点が置かれています。A2A サーバーを使用すると、構築する Elastic エージェントは他のシステムのエージェントと直接通信して、コンテキストを共有したり、タスクを委任したり、ワークフローを調整したりできるようになります。

これを推論層における相互運用性と考えてください。Elastic エージェントは検索と取得を処理し、タスクを専門のサポートエージェントまたは IT エージェントに引き渡して、結果をシームレスに返すことができます。その結果、各エージェントが最善を尽くして協力するエコシステムが実現します。

最終的に、MCP と A2A を採用することで、Elasticsearch が第一級市民としての役割を担うという当社の取り組みが強化され、より広範なエージェントエコシステム全体でのオープンな統合が保証されます。

追跡と評価

検索がエージェントと統合されるにつれて、効果的な評価の課題が重要になります。実際の企業環境にエージェントを自信を持って導入するには、エージェントが正確であるだけでなく、効率的で信頼できるという保証が必要です。パフォーマンスを測定したり、悪い応答を診断したり、ベースラインを改善したりするにはどうすればよいですか?すべては可視性から始まります。

そのため、私たちはエージェント API を最初から透明性を重視して設計しました。次の単純なエージェントのやり取りを考えてみましょう。

POST kbn://api/agent_builder/converse { "input": "what is our top portfolio account?" }

応答には、最終的な回答だけでなく、エージェントが選択したツール、使用したパラメーター、各ステップの結果の詳細を含む完全な実行トレースが含まれます。

{ "conversation_id": "db5c0c8b-12bf-4928-a57e-d99129ad2fea", "steps": [ { "type": "tool_call", "tool_call_id": "tooluse_Nfqr3mwtR92HTRIsTcGXZQ", "tool_id": ".index_explorer", "params": { "query": "indices containing portfolio data" }, "results": [...] } // ... more steps ... ], "response": { "message": "Based on the information I've gathered...." } }

包括的なトレースとログ記録は継続的な改善ループに不可欠であり、まもなくこれらのエージェントトレースを Elasticsearch に直接保存して表示できるようになります。さらに、これらのトレースは OpenTelemetry プロトコルに基づいて構築されているため、標準化され、移植可能であり、選択した監視プラットフォームとの統合が可能です。

このレベルの詳細は、真の継続的改善ループの基礎となります。これにより、包括的なテストスイートを構築し、障害をデバッグし、障害モードを特定して回帰を防ぎ、成功パターンをキャプチャしてパフォーマンスを微調整できるようになります。最終的に、このデータ主導のアプローチは、有望なプロトタイプを製品レベルの信頼できる AI システムに変換するための鍵となります。

セキュリティ

エージェントとツールの性能が向上するにつれて、セキュリティはオプションではなく、基礎的なものになります。API を公開し、タスクやワークフローを自動化するには、エンタープライズシステムが信頼されている必要があります。特に、エージェントがより多くのワークフローを自動化し始めると、これらを保護し、企業の要件を満たしていることを確認する機能が不可欠になります。

上記の機能はすべて、API 呼び出しのロールベースのアクセス制御 (RBAC)や API キー管理など、現在 Elastic ですでに利用可能な制御を継承しています。同じ制御を MCP などの新しいプロトコルにも拡張しています。つまり、OAuth などの標準のサポートと、カスタム認証メカニズムをプラグインする機能を意味します。

私たちの目標は、組織が求めるセキュリティ、コンプライアンス、ガバナンスのレベルを維持しながら、エージェントとツールを実験する柔軟性を提供することです。

次に何が起こるか

機能を追加するだけではなく、エージェントコンテキストエンジニアリング向けに Elasticsearch を拡張しています。当社は、以下の理念に基づいて今後開発を進めていく予定です。

1. オープンソースと標準への取り組み

当社はオープンソースとオープンスタンダードに注力しており、これらの機能が外部のエージェントフレームワークと相互運用可能であることを保証します。データとワークフローを常に管理しながら、エコシステム全体でエージェントを接続、拡張、構成できるようになります。

2. 文脈の価値

AI エージェントのコンテキストは最大の資産です。エージェントが検索やワークフロー操作を実行するときにコンテキストを管理することは、難しいタスクになる可能性があります。私たちは Elastic の強みを活用してコンテキストエンジニアリングを解決し、エージェントが最も関連性の高い情報を常に利用できるようにしています。

3. エージェントデータストリームに焦点を当てる

今後、エージェントは、エージェントの出力 (生成されたドキュメント、レポート、視覚化) やエージェントの実行トレース (思考、ツールの呼び出し、メモリ/コンテキスト) など、ますます大きなデータソースになります。Elastic はこの種のデータの処理に適しており、私たちはこのデータを使用して分析、評価、自動改善を実行するための研究に取り組んでいます。

4. セキュリティと安全性を考慮した設計

AI エージェントは、セキュリティと安全性に関するまったく新しい一連の課題をもたらします。Elastic は常に安全なソリューションのリーダーであり、エンタープライズグレードのガードレール、アクセス制御、および「ゼロトラスト」原則の構築を継続しています。

5. プラットフォームに組み込む

AI エージェントを構築するための機能は、Elasticsearch プラットフォームに組み込まれています。つまり、トレース、評価、視覚化、分析などのプラットフォームレベルの機能はすべてエージェントに適用できます。エージェントの実行に基づいてダッシュボードを開発したい - それが組み込まれています。感情分析を使用して AI エージェントのパフォーマンスを評価したい場合、プラットフォームでそれが可能です。これにより、AI エクスペリエンスを中心とした完全なライフサイクルを構築できるようになります。

Elastic の目標は、データに完全に統合され、拡張可能で、データに基づいた会話型 AI と自動化されたワークフローを構築するためのインターフェースを提供することです。より詳しい技術的な詳細と進捗状況については、近日中に共有される予定です。

Agent Builder は現在、プライベートプレビューでご利用いただけます。アクセスをリクエストするには、当社にご連絡ください。ご質問やフィードバックはありますか?Slack ワークスペースまたはディスカッションフォーラムで開発者コミュニティとつながりましょう。

JavaScript、Mastra、Elasticsearch を使用したエージェント型 RAG アシスタントの構築

JD Armada — Tue, 01 Jul 2025 00:00:00 GMT

このアイデアは、白熱したハイリスクなファンタジーバスケットボールリーグの最中に思いつきました。私はこう考えました。 「毎週の対戦で優位に立つのに役立つ AI エージェントを構築できるだろうか？」もちろんです!

この記事では、 Mastraとそれと対話するための軽量 JavaScript Web アプリケーションを使用して、エージェント RAG アシスタントを構築する方法について説明します。このエージェントを Elasticsearch に接続することで、構造化されたプレイヤーデータへのアクセスとリアルタイムの統計集計の実行が可能になり、プレイヤー統計に基づいた推奨事項を提供できるようになります。GitHubリポジトリにアクセスして手順を確認してください。READMEには、アプリケーションを独自に複製して実行する方法が記載されています。

すべてをまとめると次のようになります。

注: このブログ投稿は、「 AI SDK と Elastic を使用した AI エージェントの構築」に基づいています。AI エージェント全般とその用途についてよく知らない場合は、まずそこから始めてください。

アーキテクチャの概要

システムの中核となるのは、エージェントの推論エンジン（脳）として機能する大規模言語モデル（LLM）です。ユーザー入力を解釈し、呼び出すツールを決定し、関連する応答を生成するために必要な手順を調整します。

エージェント自体は、JavaScript エコシステムのエージェントフレームワークである Mastra によって構築されます。Mastra は、LLM をバックエンドインフラストラクチャでラップし、それを API エンドポイントとして公開し、ツール、システムプロンプト、エージェントの動作を定義するためのインターフェイスを提供します。

フロントエンドでは、 Viteを使用して、エージェントにクエリを送信してその応答を受信するためのチャットインターフェイスを提供する React Web アプリケーションを迅速に構築します。

最後に、エージェントがクエリして集計できるプレーヤーの統計情報と対戦データを保存する Elasticsearch があります。

背景

いくつかの基本的な概念を確認してみましょう。

エージェントRAGとは何ですか？

AI エージェントは他のシステムと対話し、独立して動作し、定義されたパラメータに基づいてアクションを実行できます。Agentic RAG は、AI エージェントの自律性と検索拡張生成の原理を組み合わせ、LLM が応答を生成するために呼び出すツールとコンテキストとして使用するデータを選択できるようにします。RAG の詳細については、こちらをご覧ください。

フレームワークを選択する場合、なぜ AI-SDK を超えるのでしょうか?

利用可能な AI エージェントフレームワークは数多くあり、 CrewAI 、 AutoGen 、 LangGraphなどの人気のフレームワークについてはおそらく聞いたことがあるでしょう。これらのフレームワークのほとんどは、さまざまなモデルのサポート、ツールの使用、メモリ管理など、共通の機能セットを共有しています。

こちらは、Harrison Chase (LangChain CEO) によるフレームワーク比較シートです。

私が Mastra に興味を持ったのは、フルスタック開発者がエージェントをエコシステムに簡単に統合できるように構築された JavaScript ファーストのフレームワークであるという点です。Vercel の AI-SDK もこのほとんどを実行しますが、プロジェクトにさらに複雑なエージェントワークフローが含まれている場合は、Mastra が真価を発揮します。Mastra は AI-SDK によって設定された基本パターンを強化しており、このプロジェクトではそれらを連携して使用します。

フレームワークとモデル選択の考慮事項

これらのフレームワークは AI エージェントを迅速に構築するのに役立ちますが、考慮すべき欠点もいくつかあります。たとえば、AI エージェントや一般的な抽象化レイヤー以外のフレームワークを使用する場合、制御が少し失われます。LLM がツールを正しく使用しなかったり、望ましくないことを実行したりする場合、抽象化によってデバッグが難しくなります。それでも、私の意見では、特にこれらのフレームワークは勢いを増しており、継続的に反復されているため、このトレードオフは、構築時に得られる容易さとスピードの価値があります。

繰り返しになりますが、これらのフレームワークはモデルに依存しません。つまり、さまざまなモデルをプラグアンドプレイできます。モデルはトレーニングに使用されたデータセットによって異なり、その結果、モデルが提供する応答も異なることに注意してください。一部のモデルではツールの呼び出しすらサポートされていません。したがって、さまざまなモデルを切り替えてテストし、どのモデルが最適な応答を返すかを確認することは可能ですが、それぞれのシステムプロンプトを書き換える必要がある可能性が高いことに注意してください。例えば、Llama3.3を使用する場合GPT-4o よりも、必要な応答を得るために、より多くのプロンプトと具体的な指示が必要になります。

NBAファンタジーバスケットボール

ファンタジーバスケットボールでは、友達のグループでリーグを開始し (グループの競争力に応じて、友情のステータスに影響する可能性があります)、通常はいくらかのお金が賭けられます。その後、各自が 10 人のプレイヤーでチームを編成し、毎週交互に他の友達の 10 人のプレイヤーと対戦します。全体のスコアに加算されるポイントは、特定の週に各プレイヤーが対戦相手に対して行ったパフォーマンスです。

チームの選手が負傷したり、出場停止になったりした場合は、チームに追加できるフリーエージェント選手のリストが表示されます。ファンタジースポーツでは、選べる選手の数が限られており、誰もが常に最高の選手を選ぶために奔走しているため、ここで多くの難しい思考が生まれます。

これは、どの選手を選択するかをすぐに決定しなければならない状況で特に役立つ、NBA AI アシスタントの出番です。特定の対戦相手に対するプレーヤーのパフォーマンスを手動で調べる代わりに、アシスタントがそのデータをすばやく見つけて平均を比較し、情報に基づいた推奨事項を提供します。

エージェント RAG と NBA ファンタジーバスケットボールの基本がわかったので、実際に見てみましょう。

プロジェクトの構築

途中で行き詰まったり、最初から構築したくない場合は、リポジトリを参照してください。

取り上げる内容

プロジェクトの足場作り:
1. バックエンド (Mastra): npx create mastra@latest を使用してバックエンドをスキャフォールディングし、エージェントロジックを定義します。
2. フロントエンド (Vite + React): npm create vite@latest を使用して、エージェントと対話するためのフロントエンドチャットインターフェイスを構築します。
環境変数の設定
1. 環境変数を管理するには、dotenv をインストールします。
2. .envを作成するファイルを開き、必要な変数を指定します。
Elasticsearchの設定
1. Elasticsearch クラスターを起動します (ローカルまたはクラウド上)。
2. 公式 Elasticsearch クライアントをインストールします。
3. 環境変数にアクセスできることを確認します。
4. クライアントへの接続を確立します。
NBA データを Elasticsearch に一括取り込み
1. 集計を有効にするには、適切なマッピングを使用してインデックスを作成します。
2. プレイヤーのゲーム統計を CSV ファイルから Elasticsearch インデックスに一括取り込みます。
Elasticsearchの集計を定義する
1. 特定の対戦相手に対する過去の平均を計算するクエリ。
2. 特定の対戦相手に対するシーズン平均を計算するクエリ。
プレーヤー比較ユーティリティファイル
1. ヘルパー関数と Elasticsearch 集計を統合します。
エージェントの構築
1. エージェント定義とシステムプロンプトを追加します。
2. zod をインストールし、ツールを定義します。
3. CORS を処理するためのミドルウェア設定を追加します。
フロントエンドの統合
1. AI-SDK の useChat を使用してエージェントと対話します。
2. 適切にフォーマットされた会話を保持するための UI を作成します。
アプリケーションの実行
1. バックエンド (Mastra サーバー) とフロントエンド (React アプリ) の両方を起動します。
2. サンプルクエリと使用方法。
次はエージェントのさらなるインテリジェント化
1. セマンティック検索機能を追加して、より洞察力のある推奨を可能にします。
2. 検索ロジックを Elasticsearch MCP (Model Context Protocol) サーバーに移動することで、動的クエリを有効にします。

要件

Node.js と npm : バックエンドとフロントエンドの両方が Node 上で実行されます。Node 18+ と npm v9+ (Node 18+ にバンドルされています) がインストールされていることを確認してください。
Elasticsearch クラスター:ローカルまたはクラウド上のアクティブな Elasticsearch クラスター。
OpenAI API キー: OpenAI 開発者ポータルのAPI キーページで生成します。

プロジェクト構造

ステップ1：プロジェクトの足場作り

まず、nba-ai-assistant-js ディレクトリを作成し、次のコマンドを使用して内部に移動します。

mkdir nba-ai-assistant-js && cd nba-ai-assistant-js

バックエンド:

次のコマンドで Mastra 作成ツールを使用します。

npx create-mastra@latest

2. ターミナルにいくつかのプロンプトが表示されます。最初のプロンプトでは、プロジェクトに backend という名前を付けます。

3. 次に、Mastra ファイルを保存するためのデフォルトの構造を維持するため、 src/を入力します。

4. 次に、デフォルトの LLM プロバイダーとして OpenAI を選択します。

5. 最後に、OpenAI API キーの入力が求められます。ここでは、スキップするオプションを選択し、後で .envファイルで提供します。

フロントエンド：

ルートディレクトリに戻り、次のコマンドを使用してVite 作成ツールを実行します。 npm create vite@latest frontend -- --template react

これにより、React 専用のテンプレートを使用して、 frontendという名前の軽量 React アプリが作成されます。

すべてがうまくいけば、プロジェクトディレクトリ内に、Mastra コードを保持するバックエンドディレクトリと、React アプリを含むfrontendディレクトリが表示されるはずです。

ステップ2: 環境変数の設定

機密キーを管理するために、 dotenvパッケージを使用して.envから環境変数を読み込みます。ファイル。バックエンドディレクトリに移動してdotenvをインストールします。

cd backend npm install dotenv --save

2. バックエンドディレクトリでは、適切な変数を入力するための example.env ファイルが提供されます。独自に作成する場合は、次の変数を必ず含めてください。

# OpenAI Configuration OPENAI_API_KEY=your_openai_api_key_here # Elasticsearch Configuration ELASTIC_ENDPOINT=your_elasticsearch_endpoint_here ELASTIC_API_KEY=your_elasticsearch_api_key_here

注意: .env .gitignoreに追加して、このファイルがバージョン管理から除外されていることを確認してください。

ステップ3: Elasticsearchの設定

まず、アクティブな Elasticsearch クラスターが必要です。次の 2 つのオプションがあります。

オプションA: Elasticsearch Cloudを使用する
- Elastic Cloudにサインアップ
- 新しいデプロイメントを作成する
- エンドポイント URL と API キー（エンコード済み）を取得します
オプションB: Elasticsearchをローカルで実行する
- Elasticsearchをローカルにインストールして実行する
- エンドポイントとして http://localhost:9200 を使用します
- APIキーを生成する

バックエンドに Elasticsearch クライアントをインストールする:

まず、バックエンドディレクトリに公式 Elasticsearch クライアントをインストールします。

npm install @elastic/elasticsearch

2. 次に、再利用可能な関数を保持するディレクトリ lib を作成し、そこに移動します。

mkdir lib && cd lib

3. 内部にelasticClient.jsという新しいファイルを作成します。このファイルは Elasticsearch クライアントを初期化し、プロジェクト全体で使用できるように公開します。

4. ECMAScript モジュール (ESM) を使用しているため、 __dirname and __ファイル名は使用できません。環境変数が.envから正しく読み込まれていることを確認するにはバックエンドフォルダー内のファイルで、ファイルの先頭に次の設定を追加します。

import { config } from 'dotenv'; import { fileURLToPath } from 'url'; import { dirname, join } from 'path'; import { Client } from '@elastic/elasticsearch'; // Grab current directory and load .env from backend folder const __filename = fileURLToPath(import.meta.url); const __dirname = dirname(__filename); const envPath = join(__dirname, '../.env'); // Load environment variables from the correct path config({ path: envPath });

5. 次に、環境変数を使用して Elasticsearch クライアントを初期化し、接続を確認します。

//Elastic client Initialization, make sure environment variables are being loaded in correctly const config= { node: `${process.env.ELASTIC_ENDPOINT}`, auth: { apiKey: `${process.env.ELASTIC_API_KEY}`, }, }; export const elasticClient = new Client(config); //Check if the client is connected async function checkConnection() { try { const info = await elasticClient.info(); console.log('Elasticsearch is connected:', info); } catch (error) { console.error('Elasticsearch connection error:', error); } } checkConnection();

これで、このクライアントインスタンスを、Elasticsearch クラスターと対話する必要がある任意のファイルにインポートできます。

ステップ4: NBAデータをElasticsearchに一括取り込み

データセット:

このプロジェクトでは、リポジトリのbackend/dataディレクトリにあるデータセットを参照します。当社の NBA アシスタントは、このデータを知識ベースとして使用し、統計的な比較を実行し、推奨事項を生成します。

sample_player_game_stats.csv - サンプルプレーヤーのゲーム統計 (例: NBA キャリア全体におけるプレーヤーごとのゲームごとのポイント、リバウンド、スティールなど)。このデータセットを使用して集計を実行します。(注: これはデモ用に事前に生成された模擬データであり、公式 NBA ソースから取得されたものではありません。)
playerAndTeamInfo.js - 通常は API 呼び出しによって提供されるプレーヤーとチームのメタデータを置き換え、エージェントがプレーヤーとチームの名前を ID に一致できるようにします。サンプルデータを使用しているため、外部 API から取得する際のオーバーヘッドを避け、エージェントが参照できるいくつかの値をハードコードしました。

実装：

backend/libディレクトリで、 playerDataIngestion.jsという名前のファイルを作成します。
インポートを設定し、CSV ファイルパスを解決し、解析を設定します。ここでも、ESM を使用しているため、サンプル CSV へのパスを解決するには__dirnameを再構築する必要があります。また、 Node.jsの組み込みモジュールfsとreadlineを使用して、指定された CSV ファイルを行ごとに解析します。

import fs from 'fs'; import readline from 'readline'; import path from 'path'; import { fileURLToPath } from 'url'; import { elasticClient } from './elasticClient.js'; const indexName = 'sample-nba-player-data'; //Replace with your preferred index name //Since we are using ES modules __dirname and __filename don't exist, so this is a workaround that allows us to use the absolute file path for our sample data. const __filename = fileURLToPath(import.meta.url); const __dirname = path.dirname(__filename); const filePath = path.resolve(__dirname, '../data/sample_nba_data.csv');

これにより、一括取り込み手順で CSV を効率的に読み取って解析できるようになります。

3. 適切なマッピングを使用してインデックスを作成します。Elasticsearch は動的マッピングを使用してフィールドタイプを自動的に推測できますが、ここでは各統計が数値フィールドとして扱われるように明示的に指定します。これらのフィールドは後で集計に使用するため、これは重要です。また、ポイントやリバウンドなどの統計情報には、小数値が含まれるようにするために、タイプfloat を使用します。最後に、Elasticsearch が認識されないフィールドを動的にマッピングしないように、マッピングプロパティdynamic: 'strict'を追加します。

// Function to create an index with mappings async function createIndex() { try { // Check if the index already exists const exists = await elasticClient.indices.exists({ index: indexName }); if (exists) { console.log(`Index "${indexName}" already exists, deleting it now.`); await elasticClient.indices.delete({ index: indexName }); console.log(`Deleted index "${indexName}".`); } // Create the index with mappings const response = await elasticClient.indices.create({ index: indexName, body: { mappings: { dynamic: 'strict', // Prevent dynamic mapping properties: { game_id: { type: 'integer' }, game_date: { type: 'date' }, player_id: { type: 'integer' }, player_full_name: { type: 'text' }, player_team_id: { type: 'integer' }, player_team_name: { type: 'text' }, home_team: { type: 'boolean' }, opponent_team_id: { type: 'integer' }, opponent_team_name: { type: 'text' }, points: { type: 'float' }, rebounds: { type: 'float' }, assists: { type: 'float' }, steals: { type: 'float' }, blocks: { type: 'float' }, fg_percentage: { type: 'float' }, minutes_played: { type: 'float' }, }, }, }, }); console.log('Index created:', response); return true; } catch (error) { console.error('Error creating index:', error); return false; } }

4. CSV データを Elasticsearch インデックスに一括で取り込む機能を追加します。コードブロック内では、ヘッダー行をスキップします。次に、各行項目をコンマで分割し、ドキュメントオブジェクトにプッシュします。このステップでは、それらをクリーンアップし、適切なタイプであることを確認します。次に、ドキュメントをインデックス情報とともに bulkBody 配列にプッシュします。これは、Elasticsearch への一括取り込みのペイロードとして機能します。

async function bulkIngestCsv(filePath) { const readStream = fs.createReadStream(filePath); const rl = readline.createInterface({ input: readStream, crlfDelay: Infinity, }); const bulkBody = []; let lineNum = 0; //Skip the header line let headerLine = true; for await (const line of rl) { if (headerLine) { headerLine = false; continue; } lineNum++; // Split the line by comma and remove whitespace const [ game_id, game_date, player_id, player_full_name, player_team_id, player_team_name, home_team, opponent_team_id, opponent_team_name, points, rebounds, assists, steals, blocks, fg_percentage, minutes_played, ] = line.split(','); // Create a document object const document = { game_id: parseInt(game_id), game_date: game_date.trim(), player_id: parseInt(player_id), player_full_name: player_full_name.trim(), player_team_id: parseInt(player_team_id), player_team_name: player_team_name.trim(), home_team: home_team.trim() === 'True', // Converts True/False into a boolean opponent_team_id: parseInt(opponent_team_id), opponent_team_name: opponent_team_name.trim(), points: parseFloat(points), rebounds: parseFloat(rebounds), assists: parseFloat(assists), steals: parseFloat(steals), blocks: parseFloat(blocks), fg_percentage: parseFloat(fg_percentage), minutes_played: parseFloat(minutes_played), }; // Prepare the bulk operation format bulkBody.push({ index: { _index: indexName } }); bulkBody.push(document); } console.log(`Parsed ${lineNum} lines from CSV`);

5.次に、 elasticClient.bulk()で Elasticsearch のBulk API を使用して、1 回のリクエストで複数のドキュメントを取り込むことができます。以下のエラー処理は、取り込みに失敗したドキュメントの数と、取り込みに成功したドキュメントの数を示すように構成されています。

try { // Perform the bulk request const response = await elasticClient.bulk({ body: bulkBody }); if (response.errors) { console.log('Bulk Ingestion had some hiccups:'); // Count successful vs failed operations let successCount = 0; let errorCount = 0; const errorDetails = []; response.items.forEach((item, index) => { const operation = item.index || item.create || item.update || item.delete; if (operation.error) { errorCount++; errorDetails.push({ document: index + 1, error: operation.error, }); } else { successCount++; } }); console.log(`Successfully indexed: ${successCount} documents`); console.log(`Failed to index: ${errorCount} documents, here are the details`, errorDetails); } else { console.log(`Bulk Ingestion fully successful!`); } } catch (error) { console.error('Error performing bulk ingestion:', error); } }

6. 以下のmain()関数を実行して、 createIndex()関数とbulkIngestCsv()関数を順番に実行します。

// Run this function async function main() { const result = await createIndex(); if (!result) { console.error('Index setup failed. Aborting.'); return; } await bulkIngestCsv(filePath); console.log('Bulk ingestion completed!'); } main();

一括取り込みが成功したことを示すコンソールログが表示された場合は、Elasticsearch インデックスを簡単にチェックして、ドキュメントが実際に正常に取り込まれたかどうかを確認します。

ステップ5: Elasticsearchの集計の定義と統合

これらは、プレイヤーの統計を相互に比較するために AI エージェントのツールを定義するときに使用される主な関数になります。

1. backend/libディレクトリに移動し、 elasticAggs.jsというファイルを作成します。

2. 特定の対戦相手に対するプレイヤーの過去の平均を計算するには、以下のクエリを追加します。このクエリでは、2 つの条件（1 つはplayer_idに一致し、もう 1 つはopponent_team_idに一致する）を持つboolフィルターを使用して、関連するゲームのみを取得します。ドキュメントを返す必要はなく、集計のみを対象とするため、 size:0を設定します。aggsブロックでは、 points, rebounds, assists, steals, blocksやfg_percentageなどのフィールドに対して複数のメトリック集計を並行して実行し、平均値を計算します。LLM は計算で成功するか失敗するかのどちらかですが、このプロセスは Elasticsearch にオフロードされ、NBA AI アシスタントが正確なデータにアクセスできるようになります。

export async function getHistoricalAveragesAgainstOpponent(player_id, opponent_team_id) { try { //Query for Historical Averages const historicalQuery = await elasticClient.search({ index: 'sample-nba-player-data', size: 0, query: { bool: { must: [ { term: { player_id: { value: player_id, }, }, }, { term: { opponent_team_id: { value: opponent_team_id, }, }, }, ], }, }, aggs: { avg_points: { avg: { field: 'points' } }, avg_rebounds: { avg: { field: 'rebounds' } }, avg_assists: { avg: { field: 'assists' } }, avg_steals: { avg: { field: 'steals' } }, avg_blocks: { avg: { field: 'blocks' } }, avg_fg_percentage: { avg: { field: 'fg_percentage' } }, }, }); return { points: historicalQuery.aggregations.avg_points.value || 0, rebounds: historicalQuery.aggregations.avg_rebounds.value || 0, assists: historicalQuery.aggregations.avg_assists.value || 0, steals: historicalQuery.aggregations.avg_steals.value || 0, blocks: historicalQuery.aggregations.avg_blocks.value || 0, fgPercentage: historicalQuery.aggregations.avg_fg_percentage.value || 0, }; } catch (error) { console.error('Query error from getHistoricalAveragesAgainstOpponent function:', error); return { error: 'Queries failed in getting historical averages against opponent.' }; } }

3. 特定の対戦相手に対するプレーヤーのシーズン平均を計算するには、履歴クエリとほぼ同じクエリを使用します。このクエリの唯一の違いは、 boolフィルターにgame_dateの追加条件があることです。フィールドgame_dateは、現在の NBA シーズンの範囲内に収まる必要があります。この場合、範囲は2024-10-01から2025-06-30の間になります。以下の追加条件により、後続の集計で今シーズンのゲームのみが分離されることが保証されます。

{ range: { //Range for this season, change to match current season game_date: { gte: '2024-10-01', lte: '2025-06-30', }, },

ステップ6: プレーヤー比較ユーティリティ

コードをモジュール化して保守しやすい状態に保つために、メタデータヘルパー関数と Elasticsearch 集計を統合するユーティリティファイルを作成します。これにより、エージェントが使用するメインツールが強化されます。詳細は後述します。

1. backend/libディレクトリに新しいファイルcomparePlayers.jsを作成します。

2. 以下の関数を追加して、メタデータヘルパーと Elasticsearch 集約ロジックを、エージェントが使用するメインツールを強化する単一の関数に統合します。

import { playersByName } from '../data/playerAndTeamInfo.js'; import { teamsByName } from '../data/playerAndTeamInfo.js'; import { upcomingMatchups } from '../data/playerAndTeamInfo.js'; import { getHistoricalAveragesAgainstOpponent } from './elasticAggs.js'; import { getSeasonAveragesAgainstOpponent } from './elasticAggs.js'; //Simple helper functions to simulate API calls for player and team metadata. These reference the hardcoded values from playerAndTeamInfo.js in the data directory export function getPlayerInfo(playerFullName) { return playersByName[playerFullName]; } export function getTeamID(teamFullName) { return teamsByName[teamFullName]; } export function getUpcomingMatchups(teamId) { return upcomingMatchups[teamId]; } //Main function used by the 'playerComparisonTool' agent tool export async function comparePlayersForNextMatchup(player1Name, player2Name) { //Get Player Info const player1Info = getPlayerInfo(player1Name); const player2Info = getPlayerInfo(player2Name); //Get upcoming matchups const player1NextGame = getUpcomingMatchups(player1Info.team_id)[0]; const player2NextGame = getUpcomingMatchups(player2Info.team_id)[0]; //Get season and historical averages against next opponent for player 1 const player1SeasonAverages = await getSeasonAveragesAgainstOpponent( player1Info.player_id, player1NextGame.opponent_team_id ); const player1HistoricalAverages = await getHistoricalAveragesAgainstOpponent( player1Info.player_id, player1NextGame.opponent_team_id ); //Get season and historical averages against next opponent for player 2 const player2SeasonAverages = await getSeasonAveragesAgainstOpponent( player2Info.player_id, player2NextGame.opponent_team_id ); const player2HistoricalAverages = await getHistoricalAveragesAgainstOpponent( player2Info.player_id, player2NextGame.opponent_team_id ); const player1 = { name: player1Name, playerId: player1Info.player_id, teamId: player1Info.team_id, nextOpponent: { teamId: player1NextGame.opponent_team_id, teamName: player1NextGame.opponent_team_name, home: player1NextGame.home, }, stats: { seasonAverages: player1SeasonAverages, historicalAverages: player1HistoricalAverages, }, }; const player2 = { name: player2Name, playerId: player2Info.player_id, teamId: player2Info.team_id, nextOpponent: { teamId: player2NextGame.opponent_team_id, teamName: player2NextGame.opponent_team_name, home: player2NextGame.home, }, stats: { seasonAverages: player2SeasonAverages, historicalAverages: player2HistoricalAverages, }, }; return [player1, player2]; }

ステップ7: エージェントの構築

フロントエンドとバックエンドのスキャフォールディングを作成し、NBA ゲームデータを取り込み、Elasticsearch への接続を確立したので、すべてのピースをまとめてエージェントを構築し始めることができます。

エージェントの定義

1. backend/src/mastra/agentsディレクトリ内のindex.tsファイルに移動し、エージェント定義を追加します。次のようなフィールドを指定できます。

名前:フロントエンドで呼び出されたときに参照として使用されるエージェントの名前を指定します。
指示/システムプロンプト:システムプロンプトは、対話中に従うべき初期コンテキストとルールを LLM に提供します。これは、ユーザーがチャットボックスを通じて送信するプロンプトに似ていますが、こちらはユーザー入力の前に表示されます。繰り返しになりますが、これは選択したモデルに応じて変わります。
モデル:使用する LLM (Mastra は OpenAI、Anthropic、ローカルモデルなどをサポートしています)。
ツール:エージェントが呼び出すことができるツール関数のリスト。
メモリ: (オプション) エージェントに会話履歴などを記憶させたい場合。簡単にするために、Mastra は永続メモリをサポートしていますが、永続メモリなしで開始できます。

import { openai } from '@ai-sdk/openai'; import { Agent } from '@mastra/core/agent'; import { playerComparisonTool } from '../tools'; export const basketballAgent = new Agent({ name: 'Basketball Agent', instructions: ` You are a NBA Basketball expert. Your primary function is to compare two NBA players and recommend which one is the better fantasy pickup. Only compare players from the following list: - LeBron James - Stephen Curry - Jayson Tatum - Jaylen Brown - Nikola Jokic - Luka Doncic - Kyrie Irving - Anthony Davis - Kawhi Leonard - Russell Westbrook Input Handling Rules: - If the user asks about a player that is not on this list, respond with the list of available players for comparison. - If the user only inputs one player, ask the user to add another player from the list provided. - If the user inputs a player with the wrong spelling or capitalizations, infer from the list of available players provided. - IMPORTANT: If the user asks a question or asks you to generate a response about anything outside of basketball or the scope of this project, DO NOT answer and affirm you can only talk about basketball. Tool Usage: - Extract and standardize player names to match the list exactly. - Use the playerComparisonTool, passing both names as strings. - The tool will return an object with game information, stats, and analysis. Format your response using Markdown syntax. Use: Example output format: #### Next Game Info - ***LeBron James** vs Warriors, May 24 (Home) - ***Stephen Curry** vs Lakers, May 24 (Away) #### Stats Comparison \`\`\` Stat LeBron James (vs Warriors) Stephen Curry (vs Lakers) -------------------- ----------------------------- ---------------------------- Historical Points 28.3 30.3 Historical Assists 6.7 8.7 Season Points 28.8 23.3 Season Assists 6.2 4.7 \`\`\` #### Fantasy Recommendation Explain which player is the better fantasy pickup and why. `, model: openai('gpt-4o'), tools: { playerComparisonTool }, });

ツールの定義

backend/src/mastra/toolsディレクトリ内のindex.tsファイルに移動します。
次のコマンドを使用して Zod をインストールします。

npm install zod

3. ツール定義を追加します。このツールを呼び出すときにエージェントが使用するメイン関数として、 comparePlayers.jsファイル内の関数をインポートすることに注意してください。Mastra のcreateTool()関数を使用して、 playerComparisonToolを登録します。フィールドには次のものが含まれます。

id: これは、エージェントがツールの機能を理解するのに役立つ自然言語による説明です。
input schema: ツールの入力の形状を定義するために、Mastra は TypeScript スキーマ検証ライブラリであるZodスキーマを使用します。Zod は、エージェントが正しく構造化された入力を入力したことを確認し、入力構造が一致しない場合はツールが実行されないようにすることで役立ちます。
description: これは、エージェントがいつ電話をかけてツールを使用するかを理解するのに役立つ自然言語による説明です。
execute: ツールが呼び出されたときに実行されるロジック。私たちの場合、インポートしたヘルパー関数を使用してパフォーマンス統計を返します。

import { comparePlayersForNextMatchup } from '../../../lib/comparePlayers.js' import { createTool } from "@mastra/core/tools"; import { z } from "zod"; export const playerComparisonTool = createTool({ id: "Compare two NBA players", inputSchema: z.object({ player1:z.string(), player2:z.string() }), description: "Use this tool to compare two players given in the user prompt.", execute: async ({ context: { player1, player2 } }) => { return await comparePlayersForNextMatchup(player1, player2); }, })

CORSを処理するミドルウェアの追加

CORS を処理するために、Mastra サーバーにミドルウェアを追加します。人生には避けられないことが 3 つあると言われています。死、税金、そして Web 開発者にとっては CORS です。簡単に言うと、クロスオリジンリソース共有は、フロントエンドが別のドメインまたはポートで実行されているバックエンドにリクエストを送信するのをブロックするブラウザのセキュリティ機能です。バックエンドとフロントエンドの両方をローカルホストで実行しているにもかかわらず、それらは異なるポートを使用するため、CORS ポリシーがトリガーされます。バックエンドがフロントエンドからのリクエストを許可するように、 Mastra ドキュメントで指定されているミドルウェアを追加する必要があります。

1. backend/src/mastraディレクトリ内のindex.tsファイルに移動し、CORS の設定を追加します。

origin: ['http://localhost:5173']
- このアドレス（Vite のデフォルトアドレス）からのリクエストのみを許可します
allowMethods: ["GET", "POST"]
- 許可される HTTP メソッド。ほとんどの場合、POST が使用されます。
allowHeaders: ["Content-Type", "Authorization", "x-mastra-client-type, "x-highlight-request", "traceparent"],
- これらはリクエストで使用できるカスタムヘッダーを決定します

import { Mastra } from '@mastra/core/mastra'; import { basketballAgent } from './agents'; console.log('Starting Mastra server...'); export const mastra = new Mastra({ agents: { basketballAgent }, server:{ timeout: 10 * 60 * 1000, // 10 minutes cors: { origin: ['http://localhost:5173'], allowMethods: ["GET", "POST"], allowHeaders: [ "Content-Type", "Authorization", "x-mastra-client-type", "x-highlight-request", "traceparent", ], exposeHeaders: ["Content-Length", "X-Requested-With"], credentials: false, }, }, }); console.log('Mastra server configured.'); // Log after server configuration

ステップ8: フロントエンドの統合

この React コンポーネントは、 @ai-sdk/reactのuseChat()フックを使用して Mastra AI エージェントに接続するシンプルなチャットインターフェースを提供します。このフックを使用して、トークンの使用状況やツールの呼び出しを表示したり、会話をレンダリングしたりします。上記のシステムプロンプトでは、エージェントに応答をマークダウンで出力するように要求しているため、 react-markdownを使用して応答を適切にフォーマットします。

1.フロントエンドディレクトリにいる間に、useChat() フックを使用するために @ai-sdk/react パッケージをインストールします。

npm install @ai-sdk/react

2. 同じディレクトリで、React Markdown をインストールして、エージェントが生成する応答を適切にフォーマットできるようにします。

npm install react-markdown

3. useChat()を実装します。このフックは、フロントエンドと AI エージェントのバックエンド間のやり取りを管理します。メッセージの状態、ユーザー入力、ステータスを処理し、監視の目的でライフサイクルフックを提供します。渡すオプションは次のとおりです。

api: これは、Mastra AI エージェントのエンドポイントを定義します。デフォルトではポート 4111 に設定されており、ストリーミング応答をサポートするルートも追加する必要があります。
onToolCall: これは、エージェントがツールを呼び出すたびに実行されます。エージェントがどのツールを呼び出しているかを追跡するために使用します。
onFinish: エージェントが完全な応答を完了した後に実行されます。ストリーミングを有効にしても、 onFinish各チャンクの後ではなく、完全なメッセージが受信された後に実行されます。ここでは、トークンの使用状況を追跡するためにこれを使用しています。これは、LLM コストを監視して最適化するときに役立ちます。

4. 最後に、 frontend/componentsディレクトリのChatUI.jsxコンポーネントに移動して、会話を行うための UI を作成します。次に、エージェントからの応答を適切にフォーマットするために、応答をReactMarkdownコンポーネントでラップします。

import React, { useState } from 'react'; import { useChat } from '@ai-sdk/react'; import ReactMarkdown from 'react-markdown'; export default function ChatUI() { const [totalTokenUsage, setTotalTokenUsage] = useState(0); const [promptTokenUsage, setPromptTokenUsage] = useState(0); const [completionTokenUsage, setCompletionTokenUsage] = useState(0); const [toolsCalled, setToolsCalled] = useState([]); const { messages, input, handleInputChange, handleSubmit, status } = useChat({ api: 'http://localhost:4111/api/agents/basketballAgent/stream', //Replace with your own endpoint for your agent id: 'my-chat-session', //Optional parameter to check agent tool calls onToolCall: ({ toolCall }) => { setToolsCalled((prev) => [...prev, toolCall.toolName]); }, //Optional parameter to check token usages onFinish: (message, { usage }) => { setTotalTokenUsage((prev) => prev + usage.totalTokens); setPromptTokenUsage((prev) => prev + usage.promptTokens); setCompletionTokenUsage((prev) => prev + usage.completionTokens); }, //Optional parameter for error handling onError: (error) => { console.error('Agent error:', error); }, }); return (

What's My Agent Doing?

Tools Called:

{tool}
No tools called yet.

Prompt Token Usage: {promptTokenUsage}

Completion Token Usage: {completionTokenUsage}

Total Token Usage: {totalTokenUsage}

Conversation:

{messages.map((msg) => (

{msg.role === 'assistant' ? 'Basketbot' : 'You'}: {msg.content}

))}

); }

ステップ9: アプリケーションの実行

おめでとうございます！これでアプリケーションを実行する準備が整いました。バックエンドとフロントエンドの両方を起動するには、次の手順に従います。

ターミナルウィンドウで、ルートディレクトリからバックエンドディレクトリに移動し、Mastra サーバーを起動します。

cd backend npm run dev

2. 別のターミナルウィンドウで、ルートディレクトリからフロントエンドディレクトリに移動し、React アプリを起動します。

cd frontend npm run dev

3. ブラウザで次の場所に移動します。

http://localhost:5173

チャットインターフェースが表示されるはずです。次のサンプルプロンプトを試してみてください。

「レブロン・ジェームズとステフィン・カリーを比較」
「ジェイソン・テイタムとルカ・ドンチッチのどちらを選ぶべきでしょうか？」

次はエージェントのさらなるインテリジェント化

アシスタントをよりエージェント的にし、推奨事項をより洞察力のあるものにするために、次のイテレーションでいくつかの重要なアップグレードを追加する予定です。

NBAニュースのセマンティック検索

プレーヤーのパフォーマンスに影響を与える要因は数多くありますが、その多くは生の統計には表示されません。負傷報告、ラインナップの変更、さらには試合後の分析などは、ニュース記事でしか見つけることができません。この追加のコンテキストを捉えるために、エージェントが関連する NBA の記事を取得し、その内容を推奨事項に組み込めるよう、セマンティック検索機能を追加します。

Elasticsearch MCPサーバーによる動的検索

MCP (モデルコンテキストプロトコル) は、エージェントがデータソースに接続する方法の標準として急速に普及しつつあります。検索ロジックを Elasticsearch MCP サーバーに移行します。これにより、エージェントは、私たちが提供する定義済みの検索機能に頼るのではなく、動的にクエリを構築できるようになります。これにより、より自然な言語ワークフローを使用できるようになり、すべての検索クエリを手動で記述する必要性が軽減されます。Elasticsearch MCP サーバーとエコシステムの現在の状態の詳細については、こちらをご覧ください。

これらの変更はすでに進行中ですので、お楽しみに!

まとめ

このブログでは、JavaScript、Mastra、Elasticsearch を使用して、ファンタジーバスケットボールチームに合わせた推奨事項を提供するエージェント RAG アシスタントを構築しました。取り上げた内容:

エージェント RAG の基礎と、AI エージェントの自律性と RAG を効果的に使用するツールを組み合わせることで、より繊細で動的なエージェントを実現できる方法について説明します。
Elasticsearchとそのデータストレージ機能および強力なネイティブ集約により、それが LLM のナレッジベースとして優れたパートナーとなる理由について説明します。
Mastraフレームワークと、それが JavaScript エコシステムの開発者にとってこれらのエージェントの構築をどのように簡素化するかについて説明します。

あなたがバスケットボールの熱狂的なファンであっても、AI エージェントの構築方法を検討している方であっても、あるいは私のようにその両方であっても、このブログが、始めるための基礎を提供できれば幸いです。完全なリポジトリはGitHubで入手できます。自由にクローンして改良してください。さあ、ファンタジーリーグで優勝しましょう!

モデルコンテキストプロトコルを使用してエージェントをElasticsearchに接続する

Jedr Blaszyk,Joe McElroy — Fri, 28 Mar 2025 00:00:00 GMT

同僚とチャットするのと同じくらい簡単にデータとやりとりできたらどうでしょうか?「先月の 500 ドルを超えるすべての注文を表示してください」や「5 つ星のレビューを最も多く獲得した製品はどれですか」と尋ねるだけで、クエリを必要とせずに、即座に正確な回答が得られることを想像してみてください。

モデルコンテキストプロトコル (MCP) によりこれが可能になります。会話型 AI をデータベースや外部 API にシームレスに接続し、複雑なリクエストを自然な会話に変換します。現代の LLM は言語の理解に優れていますが、その真の可能性は現実世界のシステムと統合されたときに発揮されます。MCP は両者の間のギャップを埋め、データのやりとりをより直感的かつ効率的にします。

この投稿では、次の内容について説明します。

MCPアーキテクチャ – 内部の仕組み
Elasticsearchに接続されたMCPサーバーの利点
Elasticsearch を活用した MCP サーバーの構築

これからはエキサイティングな時代が来ます!MCP と Elastic スタックの統合により、情報の操作方法が変わり、複雑なクエリが日常会話と同じくらい直感的になります。

モデルコンテキストプロトコル

Anthropic が開発したモデルコンテキストプロトコル(MCP) は、安全な双方向チャネルを通じて AI モデルを外部データソースに接続するオープンスタンダードです。これは、会話のコンテキストを維持しながら外部システムにリアルタイムでアクセスするという、AI の主要な制限を解決します。

MCPアーキテクチャ

モデルコンテキストプロトコルアーキテクチャは、次の 2 つの主要コンポーネントで構成されます。

MCP クライアント– ユーザーに代わって情報を要求したりタスクを実行したりする AI アシスタントとチャットボット。
MCP サーバー– 関連情報を取得したり、要求されたアクション (外部 API の呼び出しなど) を実行したりするデータリポジトリ、検索エンジン、および API。

MCPサーバーは、クライアントに対して主に4つの機能を提供します。

リソース- LLM インタラクションのコンテキストとして取得および使用できる構造化されたデータ、ドキュメント、およびコンテンツ。これにより、AI アシスタントはデータベース、検索インデックス、その他のソースから関連情報にアクセスできるようになります。
ツール- LLM が外部システムと対話したり、計算を実行したり、実際のアクションを実行できるようにする実行可能関数。これらのツールは、テキスト生成を超えて AI 機能を拡張し、アシスタントがワークフローをトリガーしたり、API を呼び出したり、データを動的に操作したりできるようにします。
プロンプト- 一般的な LLM インタラクションを標準化して共有するための再利用可能なプロンプトテンプレートとワークフロー。
サンプリング- セキュリティとプライバシーを維持しながら、高度なエージェント動作を可能にするために、クライアントを通じて LLM 完了を要求します。

MCPサーバー + Elasticsearch

従来の検索拡張生成 (RAG) システムはユーザーのクエリに基づいてドキュメントを検索しますが、MCP はさらに一歩進んで、AI エージェントがリアルタイムでタスクを動的に構築して実行できるようにします。これにより、ユーザーは次のような自然言語の質問をすることができます。

「先月の 500 ドルを超える注文をすべて表示してください。」
「5 つ星のレビューを最も多く獲得した製品はどれですか?」

クエリを 1 つも書かなくても、即座に正確な回答が得られます。

MCP は以下を通じてこれを実現します。

動的なツール選択 - エージェントは、ユーザーの意図に基づいて、MCP サーバー経由で公開される適切なツールをインテリジェントに選択します。一般的に、「よりスマートな」LLM は、状況に応じて適切な議論に基づいて適切なツールを選択するのが得意です。
双方向通信 – エージェントとデータソースは情報をスムーズに交換し、必要に応じてクエリを絞り込みます（例：最初にインデックスマッピングを検索し、その後で ES クエリを構築します。
マルチツールオーケストレーション - ワークフローは複数の MCP サーバーのツールを同時に活用できます。
永続的なコンテキスト - エージェントは以前のやり取りを記憶し、会話全体の継続性を維持します。

Elasticsearch に接続された MCP サーバーは、強力なリアルタイム検索アーキテクチャを実現します。AI エージェントは、オンデマンドで Elasticsearch データを探索、クエリ、分析できます。シンプルなチャットインターフェースを通じてデータを検索できます。

MCP は、データの取得だけでなく、アクションも可能にします。他のツールと統合してワークフローをトリガーし、プロセスを自動化し、分析システムに洞察を提供します。MCP は、検索と実行を分離することで、AI を活用したアプリケーションの柔軟性と最新性を維持し、エージェントワークフローにシームレスに統合します。

ハンズオン: Elasticsearch データとチャットできる MCP サーバー

MCP サーバー経由で Elasticsearch と対話するには、少なくとも次の機能が必要です。

インデックスを取得する
マッピングを取得する
Elasticsearch のクエリ DSL を使用して検索を実行する

私たちのサーバーは TypeScript で記述されており、公式のMCP TypeScript SDKを使用します。セットアップには、MCP クライアントが組み込まれているため、Claude デスクトップアプリ (無料版で十分です) をインストールすることをお勧めします。当社の MCP サーバーは基本的に、MCP ツールを通じて公式のJavaScript Elasticsearch クライアントを公開します。

まず、Elasticsearch クライアントと MCP サーバーを定義します。

const esClient = new Client({ node: url, auth: { apiKey: apiKey, }, }); const server = new McpServer({ name: "elasticsearch-mcp-server", version: "0.1.0", });

Elasticsearch と対話できる次の MCP サーバーツールを使用します。

インデックスの一覧表示( list_indices ): このツールは、利用可能なすべての Elasticsearch インデックスを取得し、インデックス名、ヘルスステータス、ドキュメント数などの詳細を提供します。
マッピングの取得( get_mappings ): このツールは、指定された Elasticsearch インデックスのフィールドマッピングを取得し、ユーザーが保存されているドキュメントの構造とデータ型を理解するのに役立ちます。
検索( search ): このツールは、提供されたクエリ DSL を使用して Elasticsearch 検索を実行します。テキストフィールドのハイライトが自動的に有効になり、関連する検索結果を簡単に識別できるようになります。

完全な Elasticsearch MCP サーバーの実装は、elastic/mcp-server-elasticsearchリポジトリで入手できます。

インデックスとチャット

Elasticsearch MCP サーバーを設定して、「先月からの 500 ドルを超えるすべての注文を検索する」など、データに関する自然言語の質問をする方法を見てみましょう。

Claudeデスクトップアプリを構成する

Claudeデスクトップアプリを開く
設定 > 開発者 > MCP サーバーに移動します
「設定の編集」をクリックして、この設定をclaude_desktop_config.jsonに追加します。

{ "mcpServers": { "Elasticsearch MCP Server": { "command": "npx", "args": [ "-y", "@elastic/mcp-server-elasticsearch" ], "env": { "ES_URL": "", "ES_API_KEY": "" } } } }

注: このセットアップでは、Elastic が公開した@elastic/mcp-server-elasticsearch npm パッケージを利用します。ローカルで開発する場合は、Elasticsearch MCP サーバーの起動に関する詳細をこちらで確認できます。

Elasticseachインデックスを作成する

このデモの「注文」インデックスを作成するために、サンプルデータを使用できます。
これにより、「先月からの500ドル以上のすべての注文を検索する」などのクエリを試すことができます。

使い始める

Claudeデスクトップアプリで新しい会話を開く
MCPサーバーは自動的に接続します
Elasticsearch データについて質問してみましょう。

自然言語を使用して Elasticsearch データをクエリすることがいかに簡単かを確認するには、このデモをご覧ください。

これは次のように機能します。

「先月からの 500 ドルを超えるすべての注文を検索する」と要求されると、LLM は指定された制約を使用して Elasticsearch インデックスを検索する意図を認識します。効果的な検索を実行するために、エージェントは次のことを行います。

インデックス名を確認します。 orders
ordersインデックスのマッピングを理解する
インデックスマッピングと互換性のあるクエリDSLを構築し、最後に検索リクエストを実行します。

この相互作用は次のように表すことができます。

まとめ

モデルコンテキストプロトコルは、Elasticsearch データとのやり取りを強化し、複雑なクエリの代わりに自然言語による会話を可能にします。MCP は、AI 機能とデータを連携させることで、やり取り全体を通じてコンテキストを維持する、より直感的で効率的なワークフローを作成します。

Elasticsearch MCP サーバーはパブリック npm パッケージ ( @elastic/mcp-server-elasticsearch ) として利用できるため、開発者にとって統合が簡単になります。最小限のセットアップで、チームはデータの探索、ワークフローのトリガー、簡単な会話による分析情報の取得を開始できます。

自分で体験する準備はできましたか?今すぐElasticsearch MCP サーバーを試して、データとのチャットを始めましょう。

Elasticsearch Serverlessプロジェクトを管理するAIエージェント

Fram Souza — Tue, 04 Mar 2025 00:00:00 GMT

AIエージェントを使用してサーバーレスElasticsearchプロジェクトを管理する方法

リポジトリのクローンを作成します。 git clone https://github.com/elastic/elasticsearch-labs/supporting-blog-content/serverless-ai-agent aを使用して GitHub からツールのコードをダウンロードし、 cd serverless-ai-agentを使用してディレクトリに移動します。
環境の設定: python -m venv venvを使用して仮想環境 (オプション) を作成し、アクティブ化します (Windows の場合はsource venv/bin/activateまたはvenv\Scripts\activate )。次に、 pip install -r requirements.txtを使用して必要な Python パッケージをインストールします。
資格情報を構成する:プロジェクトルートに.envファイルを作成し、Elasticsearch API URL ( ES_URL )、API キー ( API_KEY )、リージョン ( REGION )、OpenAI API キー ( OPENAI_API_KEY ) を入力します。
ツールを実行します:ターミナルでpython main.pyを実行してツールを実行します。これにより、AI エージェントが起動し、コマンドのプロンプトが表示されます。
自然言語でプロジェクトを管理する: 「my\_project という名前のサーバーレスプロジェクトを作成する」、「my\_project という名前のサーバーレスプロジェクトのステータスを取得する」、「my\_project という名前のサーバーレスプロジェクトを削除する」などのわかりやすい英語のコマンドを使用してツールを操作します。AI はコマンドを解釈し、対応する機能を実行します。

背景

この小さなコマンドラインツールを使用すると、Serverless Elasticsearch プロジェクトをわかりやすい英語で管理できます。AI (この場合は OpenAI) と対話して、ユーザーの意図を理解し、LlamaIndex を使用して適切な関数を呼び出します。

Elasticsearch Serverless AIエージェントは何ができるのか

プロジェクトを作成する: 新しい Serverless Elasticsearch プロジェクトを起動します。
プロジェクトの削除: 既存のプロジェクトを削除します (削除後はクリーンアップされます)。
プロジェクトのステータスを取得: プロジェクトの進行状況を確認します。
プロジェクトの詳細を取得: プロジェクトに関するすべての重要な詳細を取得します。

GitHub でコードを確認してください。

Elasticsearch Serverless AIエージェントの仕組み

次のように入力すると:

「my_project という名前のサーバーレスプロジェクトを作成する」

…舞台裏ではこんなことが起こっています:

ユーザー入力とコンテキスト:自然言語コマンドが AI エージェントに送信されます。
関数の説明:詳細な説明が与えられているため、AI エージェントは、create_ess_project、delete_ess_project、get_ess_project_status、get_ess_project_details などのいくつかの関数についてすでに認識しています。これらの説明は、各関数が何を実行し、どのようなパラメータが必要かを AI に伝えます。
LLM 処理:クエリと関数情報が LLM に送信されます。つまり、AI は次のことを認識します。
- ユーザークエリ: わかりやすい英語での指示。
- 利用可能な機能と説明: 各ツールの機能の詳細により、適切なツールを選択できます。
- コンテキスト/履歴チャット情報: 会話なので、以前に話された内容を記憶します。
関数の呼び出しと応答: AI はどの関数を呼び出すかを判断し、適切なパラメーター (プロジェクト名など) を渡して、関数が実行されます。応答はわかりやすい形式で返されます。

つまり、自然言語クエリと詳細なツール説明のリストの両方を LLM に送信して、LLM がそれを「理解」し、リクエストに適したアクションを選択できるようにします。

AIエージェントを設定する

前提条件:

AI エージェントを実行する前に、次の設定がされていることを確認してください。

Python (v3.7 以降)がインストールされています。
Elastic Cloud にセットアップされたElasticsearch サーバーレスアカウント。
言語モデルと対話するためのOpenAI アカウント。

手順:

1. リポジトリをクローンします。

git clone https://github.com/elastic/elasticsearch-labs/supporting-blog-content/serverless-ai-agent cd serverless-ai-agent

2. 仮想環境を作成する (オプションですが推奨):環境関連の問題に直面している場合は、分離のために仮想環境を設定できます。

python -m venv venv source venv/bin/activate # On Windows, use venv\Scripts\activate

3. 依存関係をインストールします。次のコマンドを実行して、必要な依存関係がすべてインストールされていることを確認します。

pip install -r requirements.txt

4. 環境を設定する: .env を作成するプロジェクトルートに次の変数を含むファイルを作成します。以下に、役に立つサンプルの.env.exampleファイルを示します。

ES_URL=your_elasticsearch_api_url # The base URL for your Elasticsearch service (e.g., https://your-cluster-id.es.region.aws.elastic-cloud.com) API_KEY=your_elasticsearch_api_key # Your API key for Elasticsearch REGION=your_region # Example: aws-eu-west-1 OPENAI_API_KEY=your_openai_api_key # Your OpenAI API key

ES_URL 、 API_KEY 、 OPENAI_API_KEYの値が正しいことを確認してください。API キーはそれぞれのサービスダッシュボードで確認できます。

5. プロジェクトファイル:ツールは、 projects.jsonファイルを使用してプロジェクトマッピング (プロジェクト名とその詳細) を保存します。このファイルが存在しない場合は自動的に作成されます。

AIエージェントの実行

python main.py

次のようなプロンプトが表示されます。

Welcome to the Serverless Project AI Agent Tool! You can ask things like: - 'Create a serverless project named my_project' - 'Delete the serverless project named my_project' - 'Get the status of the serverless project named my_project' - 'Get the details of the serverless project named my_project'

コマンドを入力すると、AI エージェントが魔法のように動作します。完了したら、 exitまたはquitと入力して終了します。

さらに詳しい情報

LLM 統合: LLM には、クエリと利用可能な各機能の詳細な説明の両方が提供されます。これにより、コンテキストを理解し、たとえば、 create_ess_projectを呼び出すかdelete_ess_projectを呼び出すかを決定するのに役立ちます。
ツールの説明: 各関数ツール (FunctionTool.from_defaults を使用して作成)親切な説明があります。この説明は LLM に送信されるプロンプトに含まれているため、LLM は利用可能なアクションと各アクションで期待される内容を「認識」します。
永続性: プロジェクトとその詳細はprojects.jsonに保存されます。毎回情報を再入力する必要がなくなります。
詳細ログ: エージェントは詳細モードに設定されており、デバッグや、命令が関数呼び出しにどのように変換されるかを確認するのに最適です。

Elasticsearch AIエージェントの利用例

python main.py Welcome to the Serverless Project AI Agent Tool! You can ask things like: - 'Create a serverless project named my_project' - 'Delete the serverless project named my_project' - 'Get the status of the serverless project named my_project' - 'Get the details of the serverless project named my_project' User: Create a serverless project named my-february-test Added user message to memory: Create a serverless project named my-february-test === Calling Function === Calling function: create_ess_project with args: {"project_name":"my-february-test"} ======================== Agent: The serverless Elasticsearch project named "my-february-test" has been created successfully. Here are the details: - **Project ID:** <>> - **Elasticsearch Endpoint:** [https://my-february-test-ccc399.es.eu-west-1.aws.qa.elastic.cloud](https://my-february-test-ccc399.es.eu-west-1.aws.qa.elastic.cloud) - **Kibana Endpoint:** [https://my-february-test-ccc399.kb.eu-west-1.aws.qa.elastic.cloud](https://my-february-test-ccc399.kb.eu-west-1.aws.qa.elastic.cloud) User: get my-february-test status Added user message to memory: get my-february-test status === Calling Function === Calling function: get_ess_project_status with args: {"project_name":"my-february-test"} ======================== Agent: The status of the "my-february-test" project is currently **initializing**. User: get my-february-test info Added user message to memory: get my-february-test info === Calling Function === Calling function: get_ess_project_details with args: {"project_name":"my-february-test"} ======================== Agent: Here are the details for the "my-february-test" project: - **Project Name:** my-february-test - **Alias:** my-february-test-ccc399 - **Cloud ID:** "" - **Project ID:** "" - **Region ID:** aws-eu-west-1 - **Created At:** 2025-02-12T15:42:00.530177619Z - **Created By:** 571213384 - **Organization ID:** "" - **Type:** Elasticsearch - **Optimized For:** General Purpose - **Search Lake:** - **Boost Window:** 7 - **Search Power:** 100 - **Endpoints:** - **Elasticsearch:** https://my-february-test-ccc399.es.eu-west-1.aws.qa.elastic.cloud - **Kibana:** https://my-february-test-ccc399.kb.eu-west-1.aws.qa.elastic.cloud - **Credentials:** - **Username:** "" - **Password:** "" Please ensure to keep the credentials secure. User: please delete the my-february-test project Added user message to memory: please delete the my-february-test project === Calling Function === Calling function: delete_ess_project with args: {"project_name":"my-february-test"} ======================== Agent: The "my-february-test" project has been deleted successfully.