JD Armada - Elasticsearch Labs

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 にデータを取り込み、マルチエージェントシステムを設計し、さまざまな方法で機能をテストするようになりました。このイベントは、対面イベントがなぜ重要なのかを私たちに思い出させてくれました。迅速なフィードバックループ、実際の会話、実践的なデバッグにより、現在の開発者のニーズを理解することができました。私たちが学んだことをエンジニアリングチームに還元できることを嬉しく思います。次回のハッカソンでお会いしましょう。

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とそのメモリ機能を調べ、発見したことをコミュニティと自由に共有してください。

Elasticsearchインデックスのフィールドを表示する方法

JD Armada — Wed, 06 Aug 2025 00:00:00 GMT

この記事では、Elasticsearch インデックスのフィールドを表示する方法について説明します。これは、データの構造を理解し、特定のフィールドを識別し、問題をトラブルシューティングするのに役立ちます。以下のトピックを取り上げます。

_mapping API を使用してフィールド情報を取得する
_search API を使用してフィールド値を表示する
サブフィールドの表示
Synthetic _source
ランタイムフィールド

1. _mapping APIを使用してフィールド情報を取得する

_mapping API を使用すると、1 つまたは複数のインデックスのマッピング定義を取得できます。これには、フィールド、そのデータ型、およびその他のプロパティに関する情報が含まれます。特定のインデックスのマッピングを取得するには、次のリクエストを使用します。

GET //_mapping

たとえば、 my_indexという名前のインデックスがある場合、次のリクエストでそのマッピングを取得できます。

GET /my_index/_mapping

応答には、フィールドとそのプロパティに関する情報を含むインデックスのマッピング定義が含まれます。

特定のフィールドのマッピングを取得することもできます。これは、マッピングが非常に大きく、特定のフィールドにのみ焦点を当てたい場合に便利です。特定のフィールドのマッピングを取得するには、次のリクエストを使用します。

GET /my_index/_mapping/field/my_field

次のリクエストのように、フィールド名をコンマで区切ることで、複数のフィールドのマッピングを取得することもできます。

GET /my_index/_mapping/field/my_field_1,my_field_2,my_field_3

2. _search APIを使用してフィールド値を表示する

Elasticsearch インデックス内のフィールドの値を表示するには、 _search API を使用できます。_search API では、返されるフィールドを制御する方法が複数用意されています。主な方法は次の 2 つです。

_source: _sourceフィールドには、取り込みパイプラインまたは前処理手順によって行われた変更も含め、インデックスが作成されたとおりの元の JSON ドキュメント本体が含まれます。ソースドキュメントの特定のフィールドを表示するには、以下に示すようにソースフィルタリングを実装します。
fields: fieldsパラメータを使用すると、インデックスマッピングに基づいて検索を実行するときにドキュメントから特定のフィールドを取得できます。_sourceとは異なり、 fields _sourceを参照せずに、保存されたフィールド、ドキュメント値、またはランタイムフィールドから値を返すこともできます。ただし、ドキュメント値や保存された設定のない標準フィールドの場合は、 _sourceにフォールバックします。これによって、後述するように、パフォーマンスなど多くの利点が得られます。

_source フィールドの使用

デフォルトでは、 _search API は、インデックスが作成された元の JSON ドキュメントを含む_sourceフィールドを返します。特定のフィールドを表示するには、検索リクエストの_source パラメータにフィルターを追加できます。これはソースフィルタリングと呼ばれます。

以下は、 my_indexインデックス内のドキュメントのtitle フィールドとauthorフィールドの値を返す検索要求の例です。

GET /my_index/_search { "query": { "match_all": {} }, "_source": ["title", "author"] }

この例では、 _sourceパラメータは返されるフィールドを指定します。

さらに詳細な制御が必要な場合は、 _sourceオブジェクトのincludesプロパティとexcludes プロパティを使用できます。たとえば、次のクエリは、トップレベルのtitleフィールドと、 author.descriptionを除くauthorのすべてのサブフィールドを返します。

GET /my_index/_search { "query": { "match_all": {} }, "_source": { “includes”: [“title”, “author.*], “excludes”: [“author.description”] } }

この例では、 author.* パターンを使用して、 author オブジェクトのすべての直接サブフィールドを取得します。次に、 author.description 明示的に除外して、他の著者フィールドのみが返されるようにします。ソース JSON を読み込んで解析する必要があるため、パフォーマンスは向上しませんが、ネットワーク経由で送信される応答のサイズは小さくなることに注意してください。

フィールドパラメータの使用

fieldsパラメータを使用して、検索応答で返されるフィールドをフィルタリングできます。_sourceではなくfieldsを使用すると、次のようないくつかの利点があります。

パフォーマンスの向上: fields 、 _source全体をロードせずに、保存されたフィールドまたはドキュメント値から直接値を返すことができるため、応答のペイロードサイズが小さくなります。
フォーマットされた出力:標準フィールドの場合、 fields値を取得するために_sourceにフォールバックすることがありますが、インデックスマッピングを参照して、フォーマットされた日付などの出力を適切にフォーマットし、集計や並べ替えに使用されるものと一貫性を保ちます。
ランタイムフィールドへのアクセス: fields 、元の_sourceには存在しないランタイムフィールドを返す場合があります。
さらに詳しい特典については、こちらをご覧ください。

たとえば、 my_indexインデックス内のtitleフィールドとauthorフィールドのみを返すには、次の検索リクエストを使用できます。

GET /my_index/_search { "query": { "match_all": {} }, "fields": ["title", "author"], "_source": false }

上記のクエリでは、 _source フィールドを false に設定して、ソースドキュメントを返さないようにします。これにより、応答のペイロードサイズを大幅に最小化できますが、これが機能するのは、フィールドtitleとauthorがkeyword フィールドタイプであり、デフォルトでdoc_values有効になっている場合のみであることに注意してください。フィールドでdoc_values有効になっておらず、 _sourceが false に設定されている場合、Elasticsearch はそれらを取得する方法がなく、応答でスキップされます。

fieldsレスポンスでは、値が 1 つしかない場合でも、常に各フィールドの値の配列が返されることに注意してください。これは、Elasticsearch に専用の配列タイプがなく、どのフィールドも複数の値を持つ可能性があるためです。Elasticsearch の配列の詳細については、ここをクリックしてください。

フィールドを取得する他の方法

_sourceまたはfieldsを使用してフィールドを取得する方法が推奨されますが、特定のユースケースでは次のような異なる方法も使用できます。

ドキュメント値フィールド: _source完全に回避したい場合は、 docvalue_fields パラメータを使用して検索できます。Doc 値は_sourceと同じフィールド値を、並べ替えと集計に最適化されたディスク上のデータ構造で保存します。

これは_sourceで保存された値とは別であるため、 _source全体をロードせずに特定のフィールドを要求できます。これは、大きなドキュメントをクエリしているが、ドキュメント値をサポートするいくつかの小さなフィールドのみが必要な場合に便利です。docvalue_fields 使用するもう 1 つのユースケースは、以下の例に示すように、 dateとnumericフィールドでカスタムフォーマットを使用する場合です。

これは、 doc_values有効にしたフィールド、またはkeyword 、 date 、数値型、 booleanなど、デフォルトで有効になっているフィールドタイプに対してのみ機能し、 textまたはannotated_textに対しては機能しないことに注意してください。

この例では、 docvalue_fieldsパラメータを使用して、 _sourceドキュメント全体をロードせずにtitle 、 author 、およびpublishedフィールドを取得します。

GET /my_index/_search { "query": { "match_all": {} }, "docvalue_fields": [ "title", "author", { "field": "published", "format": "epoch_millis" } ], "_source": false }

このクエリを実行すると、Elasticsearch は各ドキュメントの_source を参照するのではなく、ディスク上の列ストアから直接値を取得します。クエリに指定されたformatパラメータにより、 publishedフィールドはデフォルトの形式ではなくepoch_millis形式で返されます。

保存されたフィールド:特定のフィールドをマッピングに保存されているものとして明示的にマークした場合は、 stored_fieldsパラメータを使用してそれらのフィールドをフィルターできます。これは、特定のフィールドのみで簡単な応答が必要な場合や、後で検索するために意図的に保存したフィールドの場合に便利です。これは_sourceとは別に保存されるため、このメソッドは_sourceをロードする必要を回避するのにも役立ちます。

このオプションはデフォルトでオフになっており、通常は推奨されないことに注意することが重要です。代わりにソースフィルタリングを使用して、元のソースドキュメントの特定のサブセットを返します。

以下のサンプルクエリでは、 stored_fieldsパラメータを使用して、インデックスマッピング構成が「 store”: true 」であるsummaryフィールドを取得します。

GET /my_index/_search { "query": { "match_all": {} }, "stored_fields": ["summary"] }

このクエリが実行されると、Elasticsearch はこのフィールドが”store”: trueでマークされているかどうかを確認し、見つからない場合はフィールド全体をスキップします。

3. サブフィールドの表示

インデックスにサブフィールドが含まれている場合は、ドット表記を使用してfieldsパラメータでフィールドパスを指定できます。サブフィールドはネストされたフィールドタイプとは異なることに注意してください。たとえば、 address.cityという名前のサブフィールドがある場合、次のように検索応答に含めることができます。

GET /my_index/_search { "query": { "match_all": {} }, "fields": ["title", "author", "address.city"], "_source": false }

この例では、検索応答にはtitle 、 author 、およびaddress.cityフィールドの値が含まれます。

4. 合成_ソース

_sourceを使用する機能を維持しながらディスク領域を節約したい場合は、インデックスマッピングで合成_sourceを使用するオプションがあります。合成 _sourceは、 _sourceが無効になっている場合でも、Elasticsearch が保存されたフィールドやドキュメント値などの既存のデータから_sourceを再構築できるようにする機能です。これにより、再構築がオンザフライで行われるため、クエリ時の速度が若干低下しますが、多くのストレージスペースを節約できます。インデックス設定で以下の値を使用してこの機能を有効にします。

PUT idx { "settings": { "index": { "mapping": { "source": { "mode": "synthetic" } } } } }

合成_source を使用する利点としては、 _search API 使用時の完全なドキュメント表示、ソースフィルタリング、 _sourceが利用可能であると想定されている Kibana などの他の機能やツールとの互換性などが挙げられますが、これらはすべて、完全な_sourceドキュメントを保存する必要性を回避しながら実現できます。

5. ランタイムフィールド

ランタイムフィールドを使用すると、クエリ時またはランタイムブロックの下のインデックスマッピングでスクリプトフィールドを定義できます。これらのフィールドにはインデックスが付けられないため、ランタイムフィールドを追加してもインデックスサイズは増加しませんが、 _sourceには表示されません。マッピングで定義されたランタイムフィールドは永続的であり、すべてのクエリで使用できますが、クエリ時に定義されたランタイムフィールドは一時的であり、その検索要求でのみ使用できます。

ランタイムフィールドを使用する主な利点は、ドキュメントを取り込んだ後にフィールドを追加できるため、マッピングの決定が簡素化されることです。ランタイムフィールドは、文字列の書式設定やスコアの計算など、元のドキュメントには存在しないがスクリプトを使用して生成された値でドキュメントを充実させるのにも最適です。

また、結果セット内のすべてのドキュメントに対してスクリプトを実行する必要があるため、ランタイムフィールドはパフォーマンスに悪影響を与える可能性があることにも注意してください。ランタイムフィールドを取得するには、 _search API のfieldsパラメータを使用することもできます。

まとめ

Elasticsearch インデックスのフィールドの表示は、インデックスマッピングまたは_sourceを使用して単純に値を取得する方法から、 fields 、 docvalue_fields 、またはランタイムフィールドを使用して制御と効率性を高めるより高度な方法まで多岐にわたります。さまざまな方法間のトレードオフを理解することが、検索エクスペリエンスを最適化する鍵となります。ペイロードを最適化したり、ドキュメントを充実させたり、合成_sourceを使用してストレージを節約したりする場合でも、Elasticsearch は必要なデータを必要な方法で見つけるための複数のツールと機能を提供します。これらの手法は、データの構造を理解し、特定のフィールドを識別し、問題のトラブルシューティングを行うのに役立ちます。

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で入手できます。自由にクローンして改良してください。さあ、ファンタジーリーグで優勝しましょう!

MCP（モデルコンテキストプロトコル）の現状

JD Armada — Thu, 12 Jun 2025 00:00:00 GMT

最近、サンフランシスコで開催された MCP 開発者サミットに出席しましたが、モデルコンテキストプロトコル (MCP) が急速に AI エージェントとコンテキストリッチな AI アプリケーションの基礎となる構成要素になりつつあることは明らかでした。Elastic では、 Agent Builderから MCP サーバーを直接公開することでこの方向に傾き、Elasticsearch をあらゆる MCP 互換エージェントにとって第一級のコンテキストおよびツールプロバイダーにしています。この記事では、イベントからの主な最新情報、新しいユースケース、MCP の今後の展望、Agent Builder を使用して MCP 経由でエージェントが Elasticsearch を利用できるようにする方法について説明します。

モデルコンテキストプロトコル (MCP) とは何ですか?

ご存じない方のために説明すると、モデルコンテキストプロトコルは、AI モデルをさまざまなデータソースやツールに接続するための構造化された双方向の方法を提供し、より関連性の高い情報に基づいた応答を生成できるようにするオープンスタンダードです。一般的に「 AI アプリケーション用の USB-C ポート」と呼ばれています。

双方向の性質を強調したアーキテクチャ図を以下に示します。

これは AI 実践者にとって大きな変化です。AI アプリケーションを拡張する際の主な課題の 1 つは、新しいデータソースごとにカスタム統合を構築する必要があることです。MCP は、モデルにコンテキストを管理および提供するための持続可能で再利用可能なアーキテクチャを提供します。モデルやサーバーに依存せず、完全にオープンソースです。

MCP は、アプリケーション間の統合を標準化することを目指す一連の API 仕様の最新版です。これまで、RESTful サービスには OpenAPI、データクエリには GraphQL、マイクロサービス通信には gRPC を使用していました。MCP は、これらの古い仕様の構造化された厳密さを共有するだけでなく、それを生成 AI 設定に取り入れることで、カスタムコネクタなしでエージェントをさまざまなシステムに簡単に接続できるようになります。多くの点で、MCP は HTTP が Web に対して行ったことと同じことを AI エージェントに対して行うことを目指しています。HTTP がブラウザと Web サイト間の通信を標準化したのと同様に、MCP は AI エージェントが周囲のデータの世界と対話する方法を標準化することを目指しています。

MCPと他のエージェントプロトコルの比較

エージェントプロトコルの状況は急速に拡大しており、エージェントの相互作用方法を定義するために 12 を超える新しい標準が競合しています。LlamaIndex のLaurie Voss氏は、ほとんどのプロトコルを 2 つのタイプに分類できると説明しています。エージェント同士の対話に重点を置くエージェント間プロトコルと、構造化されたコンテキストを LLM に提供することに重点を置く MCP などのコンテキスト指向プロトコルです。

Google のA2A (Agent to Agent)、Cisco と IBM のACP (Agent Communication Protocol)、 Agoraなどの他の一般的なプロトコルは、エージェント間のネゴシエーション、連合の構築、さらには分散型 ID システムを可能にすることを目的としています。MCP は、エージェントがツールやデータにアクセスする方法に焦点を当てており、必ずしもエージェント同士が通信する方法に焦点を当てているわけではないため、もう少し実用的なアプローチを採用しています (ただし、MCP は将来的にさまざまな方法でそれを可能にすることもできます)。

現在、MCP が他と一線を画しているのは、その牽引力と勢いです。フロントエンドフレームワークの初期の React と同様に、MCP はニッチな問題から始まり、現在では実際に最も採用され、拡張可能なエージェントプロトコルの 1 つとなっています。

サミットのまとめ: MCP の優先事項の進化

サミットには、Anthropic、Okta、OpenAI、AWS、GitHub などの貢献者による講演者が登壇しました。講演では、コアプロトコルの強化から実際の実装まで幅広い話題が取り上げられ、短期的および長期的な優先事項が概説されました。これらの講演は、初期の実験や単純なツール呼び出しから、MCP を基盤として使用した信頼性が高く、スケーラブルでモジュール化された AI システムの構築への移行を反映していました。

何人かの講演者は、MCP が単なるプロトコル配管にとどまらず、AI ネイティブ Web の基盤となる将来を示唆しました。JavaScript によってユーザーが Web ページをクリックして操作できるのと同じように、MCP によってエージェントが私たちに代わって同じアクションを実行できるようになります。たとえば、電子商取引では、ユーザーが買い物をするために手動で Web サイトに移動するのではなく、エージェントにログインして特定の製品を見つけ、カートに追加してチェックアウトするように指示するだけで済みます。

これは単なる憶測や誇大宣伝ではありません。PayPal はサミットで、まさにこのエージェントによるコマース体験を可能にする新しいエージェントツールキットと MCP サーバーを披露しました。MCP はツールやデータソースへの安全で信頼性の高いアクセスを提供するため、エージェントは Web を読み取るだけでなく、それに基づいて行動できるようになります。現在、MCP はすでに大きな勢いを持つ強力な標準であり、将来的には Web 全体で AI を活用したユーザーインタラクションの標準になる可能性があります。

MCPプロジェクトの最新情報: トランスポート、抽出、構造化ツール

MCP のコア貢献者であるJerome Swannack 氏が、過去 6 か月間のプロトコル仕様の更新をいくつか共有しました。これらの変更の主な目的は次のとおりです。

ストリーミング可能なHTTPを追加してリモートMCPを有効にする
抽出とツール出力スキーマの追加により、より豊富なエージェントインタラクションモデルを可能にする

MCP はオープンソースであるため、開発者は Streamable HTTP などの変更を実装できる状態になっています。抽出およびツール出力スキーマは現在リリースされておらず、ドラフト段階にあり、進化する可能性があります。

ストリーミング可能な HTTP ( 2025 年 3 月 26 日リリース) :ストリーミング可能な HTTP が新しいトランスポートメカニズムとして導入されたことは、大きなインパクトのある技術更新でした。これにより、サーバー送信イベント (SSE) が、チャンク転送エンコーディングと単一の HTTP 接続を介したプログレッシブメッセージ配信をサポートする、よりスケーラブルな双方向モデルに置き換えられます。これにより、AWS Lambda などのクラウドインフラストラクチャに MCP サーバーを展開し、長時間の接続やポーリングを必要とせずにエンタープライズネットワークの制約をサポートできるようになります。

Elicitation ( 2025 年 6 月 18 日リリース) : Elicitation を使用すると、サーバーはクライアントからのコンテキストの構造化方法を指定するスキーマを定義できます。基本的に、サーバーは必要なものと期待する入力の種類を記述できます。これにはいくつかの意味があります。サーバービルダーにとっては、より複雑なエージェントのインタラクションを構築できます。クライアントビルダーは、これらのスキーマに適応する動的な UI を実装できます。ただし、ユーザーから機密情報や個人を特定できる情報を抽出するために、誘導法を使用するべきではありません。特に MCP が成熟するにつれて、開発者はベストプラクティスに従って、誘導プロンプトが安全かつ適切な状態を保つようにする必要があります。これは、この投稿の後半で説明する、より広範なセキュリティ上の懸念に関係しています。

ツール出力スキーマ( 2025 年 6 月 18 日リリース) :このコンセプトにより、クライアントと LLM はツール出力の形状を事前に知ることができます。ツール出力スキーマを使用すると、開発者はツールが返すことが予想される内容を記述できます。これらのスキーマは、コンテキストウィンドウの非効率的な使用という、直接ツール呼び出しの主な制限の 1 つに対処します。コンテキストウィンドウは、LLM を操作するときに最も重要なリソースの 1 つと考えられており、ツールを直接呼び出すと、LLM のコンテキストに完全にプッシュされる生のコンテンツが返されます。ツール出力スキーマを使用すると、MCP サーバーが構造化データを提供できるようになるため、トークンとコンテキストウィンドウをより有効に活用できるようになります。ここでは、ツール全般に関するベストプラクティスをいくつか紹介します。

これらの新しいアップデートと今後の追加により、MCP はよりモジュール化され、型付けされた、実稼働対応のエージェントプロトコルになります。

あまり使われていない強力な機能：サンプリングとルート

MCP 仕様では目新しいものではありませんが、基調講演ではサンプリングとルートの両方が強調されました。これら 2 つのプリミティブは現在見過ごされ、十分に調査されていませんが、エージェント間のより豊かで安全なインタラクションに大きく貢献する可能性があります。

サンプリング - サーバーはクライアントからの補完を要求できます。サンプリングにより、MCP サーバーはクライアント側の LLM から補完を要求できます。これにより、プロトコルの双方向性が強化され、サーバーはリクエストに応答するだけでなく、クライアントのモデルにプロンプトを出して応答を生成するように要求できるようになります。これにより、クライアントはコスト、セキュリティ、MCP サーバーが使用するモデルを完全に制御できます。したがって、事前構成されたモデルを備えた外部 MCP サーバーを使用する場合、サーバーはクライアントにすでに接続されているモデルを要求するだけでよいため、独自の API キーを提供したり、そのモデルに対する独自のサブスクリプションを構成したりする必要はありません。これにより、より複雑でインタラクティブなエージェントの動作が可能になります。

ルート - リソースへのスコープアクセス:ルートは、クライアントが関連するリソースと焦点を当てるワークスペースについてサーバーに通知する方法を提供するために設計されました。これは、サーバーが動作する範囲を設定するのに強力です。ルートは「情報提供のみを目的としており、厳密に強制するものではない」ことに注意することが重要です。つまり、MCP サーバーまたはエージェントの権限やアクセス許可を定義しないということです。つまり、サーバーまたはエージェントが特定のツールを実行したり書き込みアクションを実行したりするのを防ぐために、ルートだけに頼ることはできません。ルートの場合も、ユーザー承認のメカニズムを使用して、権限はクライアント側で処理する必要があります。また、開発者は、ルートによって設定された境界を尊重し、ベストプラクティスを使用するように設計されたサーバーの使用にも注意する必要があります。

エージェントの認証: OAuth 2.1 と保護されたメタデータ

このセクションでは、安全でないフローを排除し、ベストプラクティスを統合した OAuth 2.0 の最新バージョンである OAuth 2.1 に焦点を当てます。

OAuth サポートは、特にセキュリティとスケーラビリティが、MCP がエージェントをツールに接続するための標準となることを妨げる大きな障害であると考えられているため、非常に期待されていたトピックでした。Aaron Parecki 氏(Okta の OAuth 2.1 編集者兼 ID 標準専門家) は、サーバー開発者の複雑さのほとんどを軽減する、クリーンかつスケーラブルな OAuth フローを MCP がどのように採用できるかについて説明しました。公式の OAuth 2.1 認証仕様は、 2025 年 6 月 18 日の最新プロトコル改訂版で最近公開されました。

この実装では、OAuth の責任を MCP クライアントとサーバーの間で分割できます。認証フローの大部分は MCP クライアントによって開始および処理され、最後にサーバーが関与するのは安全なトークンの受信と検証のみです。この分割により、開発者がすべての接続を構成する必要なく、多くのツール間で認証を行うという重要なスケーリングの問題が解決され、MCP サーバー開発者が OAuth の専門家になる必要がなくなります。

講演の2つの重要なハイライト:

保護されたリソースメタデータ: MCP サーバーは、目的、エンドポイント、認証方法を記述した JSON ファイルを公開できます。これにより、クライアントはサーバー URL だけで OAuth フローを開始できるようになり、接続プロセスが簡素化されます。詳細: MCP で OAuth を修正しましょう
IDP と SSO のサポート: 企業は ID プロバイダーを統合してアクセスを集中管理できます。これは、ユーザーエクスペリエンスとセキュリティの両方にとってメリットとなります。ユーザーは 10 個の異なる同意画面をクリックする必要がなくなり、セキュリティチームは各接続を監視できるようになります。

OAuth ロジックをクライアントにプッシュし、サーバーからのメタデータに依存することで、MCP エコシステムは大きなボトルネックを回避します。これにより、MCP は、今日の運用環境で最新の API が保護される方法とより密接に連携するようになります。

追加の参考資料: OAuth 2 Simplified 。

コンポーザブルエコシステムにおけるセキュリティの課題

新たな開発には新たな攻撃対象領域も伴います。Cisco の Arjun Sambamoorthy 氏は、MCP 環境における主な脅威をいくつか挙げています。

脅威

説明

修復とベストプラクティス

迅速な注射とツールの中毒

LLM システムのコンテキストまたはツールの説明内に悪意のあるプロンプトを挿入し、LLM がファイルの読み取りやデータの漏洩などの意図しないアクションを実行するようにする方法。

MCP Scan などのツールを使用して、ツールのメタデータのチェックを実行します。説明とパラメータをプロンプトに含める前に検証します。最後に、リスクの高いツールに対してユーザー承認を実装することを検討してください。詳細については、表の下の追加の読書リストにある OWASP プロンプトインジェクションガイドを参照してください。

サンプリング攻撃

MCP のコンテキストでは、サンプリングにより、MCP サーバーが LLM に対してプロンプトインジェクション攻撃を実行できるようになります。

信頼できないサーバーのサンプリングを無効にし、サンプリング要求に人間による承認を追加することを検討してください。

悪意のあるMCPサーバー

現在の MCP サーバーのコレクションでは、安全性を確保するために各サーバーを検査するのは困難です。不正なサーバーは密かにデータを収集し、悪意のある人物に公開する可能性があります。

信頼できるレジストリまたは内部リストからのみ MCP サーバーに接続します。サンドボックス化されたコンテナ内でサードパーティのサーバーを実行します。

悪意のあるMCPインストールツール

コマンドラインインストーラーとスクリプトは、MCP サーバーまたはツールを迅速に実装するのに便利ですが、検証されていない侵害されたコードをインストールしてしまう可能性があります。

サンドボックス環境にインストールし、パッケージ署名を検証します。検証されていないソースからの自動更新は行わないでください。

この問題にさらに対抗するために、Arjun は、信頼できる MCP レジストリを使用してすべての検証を処理すること (これは最重要トピックです。詳細については、以下の読書リストの上位 2 項目を参照してください) と、このセキュリティチェックリストの使用を提案しています。

追加の参考資料:

次はレジストリ、ガバナンス、エコシステム

集中型の MCP レジストリが開発中であり、サミットで最も頻繁に議論されたトピックの 1 つでした。現在のサーバーエコシステムは、断片化、信頼性と発見可能性の低さに悩まされています。特にメタデータが不完全であったり偽装されたりする可能性がある分散型エコシステムでは、開発者が MCP サーバーを見つけ、その動作を検証し、安全にインストールすることは困難です。

集中型レジストリは、信頼できる真実のソースとして機能し、発見可能性を向上させ、サーバーメタデータの整合性を確保し、悪意のあるツールをインストールするリスクを軽減することで、これらの問題点に直接対処します。

MCP レジストリの目標は次のとおりです。

サーバーのメタデータ（サーバーが何をするか、どのように認証するか、インストールして呼び出すか）に関する唯一の真実の情報源を提供します。
不完全なサードパーティのレジストリと断片化を排除して、サーバーを登録するときに、インターネット上の他のすべてのレジストリを更新する必要がなくなります。
CLI ツールと、前述のメタデータを含む server.json ファイルを含むサーバー登録フローを提供します。

より広範な期待は、信頼できるレジストリがエコシステムを安全に拡張し、開発者が自信を持って新しいツールを構築して共有できるようにすることです。

ガバナンスは、Anthropic にとってもう一つの最重要課題でした。MCP はオープンかつコミュニティ主導であり続けるべきだと明言しましたが、ガバナンスモデルの拡張はまだ進行中です。彼らは現在、その分野での支援を求めており、オープンソースプロトコルのガバナンスの経験がある方は誰でも連絡を取るよう呼びかけています。これは私が言及したかったもう一つの話題につながります。イベント全体を通じて、講演者は、エコシステムはその内部の開発者の貢献によってのみ成長できると強調しました。MCP を新しい Web 標準にして、他の一般的なエージェントプロトコルと差別化するために、集中的な取り組みが必要です。

現実世界におけるMCP：ケーススタディとデモ

いくつかの組織は、MCP がすでに実際のアプリケーションでどのように使用されているかを共有しました。

PayPal - エージェンティックコマース向け MCP サーバー: PayPal は、ユーザーのショッピング体験を根本的に変えることができる新しいエージェントツールキットと MCP サーバーを展示しました。ユーザーは、ソーシャルメディアで商品を探したり、価格を比較したり、チェックアウトしたりする代わりに、PayPal MCP サーバーに接続してそれらのすべてのアクションを処理するエージェントとチャットできます。
EpicAI.pro - Jarvis: MCP の開発により、現実世界の Jarvis タイプのアシスタントの実現にますます近づいています。アイアンマン映画をご存じない方のために説明すると、Jarvis は自然言語を使用し、マルチモーダル入力に応答し、応答時に遅延がなく、ユーザーのニーズを積極的に予測し、統合を自動的に管理し、デバイスと場所の間でコンテキストを切り替えることができる AI アシスタントです。Jarvis を物理的なロボットアシスタントとして想像すると、MCP は Jarvis に「手」、つまり複雑なタスクを処理する能力を与えます。
Postman - MCP サーバージェネレーター: API リクエスト用のショッピングカートエクスペリエンスを提供します。さまざまな API リクエストを選択してバスケットに入れ、バスケット全体を MCP サーバーとしてダウンロードできます。
Bloomberg - Bloomberg は、エンタープライズ GenAI 開発における主要なボトルネックを解決しました。約 10,000 人のエンジニアを抱える同社では、チーム間でツールとエージェントを統合するための標準化された方法が必要でした。MCP を使用することで、社内ツールをモジュール式のリモートファーストコンポーネントに変換し、エージェントが統合インターフェースで簡単に呼び出すことができるようになりました。これにより、エンジニアは組織全体にツールを提供できるようになり、AI チームはカスタム統合ではなくエージェントの構築に集中できるようになりました。Bloomberg は現在、MCP エコシステムとの完全な相互運用性を実現する、スケーラブルで安全なエージェントワークフローをサポートしています。ブルームバーグは公開リソースへのリンクを一切提供していないが、これはサミットで彼らが公開した内容である。
Block – Block は MCP を使用して、従業員がエンジニアリング、営業、マーケティングなどのタスクを自動化できるようにする社内 AI エージェントであるGooseを強化しています。同社は、Git、Snowflake、Jira、Google Workspace などのツール用に 60 台以上の MCP サーバーを構築し、日常的に使用するシステムとの自然言語によるやり取りを可能にしました。Block 社の従業員は現在、Goose を使用してデータのクエリ、不正行為の検出、インシデントの管理、内部プロセスのナビゲートなどを行っており、これらはすべてコードを書かずに実行できます。MCP は、Block がわずか 2 か月で多くの職務にわたって AI の導入を拡大できるよう支援しました。
AWS - AWS MCP サーバー: AWS は、サイコロを振る動作をシミュレートし、過去のロールを追跡し、Streamable HTTP を使用して結果を返す、楽しいダンジョンズアンドドラゴンズをテーマにした MCP サーバーを発表しました。この軽量な例では、Lambda や Fargate などの AWS ツールとインフラストラクチャを使用して MCP サーバーを簡単に構築およびデプロイできることが強調されました。また、MCP サーバーと対話するマルチモーダルエージェントを構築するためのオープンソースツールキットであるStrands SDKも紹介されました。

Elastic Agent Builder での MCP サポート

Elastic Agent Builder を使用すると、今すぐ MCP の実験を始めることができます。これは、データ上に直接エージェントを構築する最も簡単な方法です。Agent Builder を使用すると、Elasticsearch を利用したツールを MCP 対応エージェントに公開できます。また、次のような強力な組み込みツールがすでに付属しています。

platform.core.search - 完全なElasticsearchクエリDSLを使用して検索を実行します
platform.core.list_indices - Elasticsearch 内で利用可能なすべてのインデックスを一覧表示します (エージェントがどのようなデータが存在するかを検出できるようにします)
platform.core.get_index_mapping - 特定のインデックスのフィールドマッピングを取得します (エージェントがデータの形状と種類を理解するのに役立ちます)
platform.core.get_document_by_id - IDで特定のドキュメントを取得します（正確な検索のため）

これらのツールを使用するだけで、信頼性の高い AI エージェントを構築するための中核となるエンタープライズレベルの検索と関連性をエージェントに装備できます。

Agent Builder をさらに強力にするのは、アプリケーションのニーズに合わせて独自のカスタムツールを定義し、公開できる機能です。これは、毎回そのロジックを再検出することなく、エージェントが特定のインデックスに対して特定のタイプの検索を実行するようにしたい、意見が強いワークフローや繰り返し可能なワークフローに特に役立ちます。同じ結論に到達するために計画と推論にトークンを費やす代わりに、その意図をツールに直接エンコードすることで、エージェントの速度、信頼性、コスト効率を高めることができます。

Agent Builder UI 内で、ES|QL を使用するカスタムツール定義の例を次に示します。

カスタムツールを定義したら、 Manage MCPのドロップダウンをクリックして MCP サーバー URL をコピーすることで、MCP を使用してカスタムツール (および組み込みのネイティブツール) を公開できます。

これで、この MCP エンドポイントを、MCP を使用する任意のクライアントにインポートして Agent Builder に接続し、利用可能なすべてのツールにアクセスできるようになります。詳細については、 Agent Builderの紹介をお読みください。

まとめ

MCP Dev Summit では、MCP がこれらの AI エージェント同士、そして周囲のデータの世界と対話する方法を形作っていることが明らかになりました。エージェントをエンタープライズデータに接続する場合でも、完全に自律的なエージェントを設計する場合でも、MCP は標準化された構成可能な統合方法を提供し、大規模な環境ですぐに役立つようになります。トランスポートプロトコルやセキュリティパターンからレジストリやガバナンスに至るまで、MCP エコシステムは急速に成熟しています。MCP は今後もオープンかつコミュニティ主導であり続けるため、今日の開発者には MCP の進化を形作るチャンスがあります。